From: Baruch Siach <baruch@tkos.co.il>
To: kernel test robot <lkp@intel.com>
Cc: "Thierry Reding" <thierry.reding@gmail.com>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Andy Gross" <agross@kernel.org>,
"Bjorn Andersson" <bjorn.andersson@linaro.org>,
llvm@lists.linux.dev, kbuild-all@lists.01.org,
"Balaji Prakash J" <bjagadee@codeaurora.org>,
"Rob Herring" <robh+dt@kernel.org>,
"Robert Marko" <robert.marko@sartura.hr>,
"Kathiravan T" <kathirav@codeaurora.org>,
linux-pwm@vger.kernel.org
Subject: Re: [PATCH 1/3] pwm: driver for qualcomm ipq6018 pwm block
Date: Tue, 08 Feb 2022 08:51:40 +0200 [thread overview]
Message-ID: <87ee4ddejv.fsf@tarshish> (raw)
In-Reply-To: <202202080410.R0qwqtXx-lkp@intel.com>
Hi test robot,
Thanks for testing and reporting.
On Tue, Feb 08 2022, kernel test robot wrote:
[snip]
>>> drivers/pwm/pwm-ipq.c:122:11: warning: result of comparison of constant 16000000000 with expression of type 'unsigned long' is always false [-Wtautological-constant-out-of-range-compare]
> if (rate > 16ULL * GIGA)
> ~~~~ ^ ~~~~~~~~~~~~
> 1 warning generated.
This clang warning is only enabled with W=1 (see commit
afe956c577b). Not sure how to avoid it.
Is there a way to express this condition without making clang warn on
platforms where ULONG_MAX == 2^32? Maybe cast to unsigned long long? Or
should we just ignore this W=1 warning?
baruch
> vim +122 drivers/pwm/pwm-ipq.c
>
> 99
> 100 static int ipq_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> 101 const struct pwm_state *state)
> 102 {
> 103 struct ipq_pwm_chip *ipq_chip = ipq_pwm_from_chip(chip);
> 104 unsigned int pre_div, pwm_div, best_pre_div, best_pwm_div;
> 105 unsigned long rate = clk_get_rate(ipq_chip->clk);
> 106 u64 period_ns, duty_ns, period_rate;
> 107 u64 min_diff;
> 108
> 109 if (state->polarity != PWM_POLARITY_NORMAL)
> 110 return -EINVAL;
> 111
> 112 if (state->period < DIV64_U64_ROUND_UP(NSEC_PER_SEC, rate))
> 113 return -ERANGE;
> 114
> 115 period_ns = min(state->period, IPQ_PWM_MAX_PERIOD_NS);
> 116 duty_ns = min(state->duty_cycle, period_ns);
> 117
> 118 /*
> 119 * period_ns is 1G or less. As long as rate is less than 16 GHz,
> 120 * period_rate does not overflow. Make that explicit.
> 121 */
> > 122 if (rate > 16ULL * GIGA)
> 123 return -EINVAL;
> 124 period_rate = period_ns * rate;
> 125 best_pre_div = IPQ_PWM_MAX_DIV;
> 126 best_pwm_div = IPQ_PWM_MAX_DIV;
> 127 /*
> 128 * We don't need to consider pre_div values smaller than
> 129 *
> 130 * period_rate
> 131 * pre_div_min := ------------------------------------
> 132 * NSEC_PER_SEC * (IPQ_PWM_MAX_DIV + 1)
> 133 *
> 134 * because pre_div = pre_div_min results in a better
> 135 * approximation.
> 136 */
> 137 pre_div = div64_u64(period_rate,
> 138 (u64)NSEC_PER_SEC * (IPQ_PWM_MAX_DIV + 1));
> 139 min_diff = period_rate;
> 140
> 141 for (; pre_div <= IPQ_PWM_MAX_DIV; pre_div++) {
> 142 u64 remainder;
> 143
> 144 pwm_div = div64_u64_rem(period_rate,
> 145 (u64)NSEC_PER_SEC * (pre_div + 1), &remainder);
> 146 /* pwm_div is unsigned; the check below catches underflow */
> 147 pwm_div--;
> 148
> 149 /*
> 150 * Swapping values for pre_div and pwm_div produces the same
> 151 * period length. So we can skip all settings with pre_div >
> 152 * pwm_div which results in bigger constraints for selecting
> 153 * the duty_cycle than with the two values swapped.
> 154 */
> 155 if (pre_div > pwm_div)
> 156 break;
> 157
> 158 /*
> 159 * Make sure we can do 100% duty cycle where
> 160 * hi_dur == pwm_div + 1
> 161 */
> 162 if (pwm_div > IPQ_PWM_MAX_DIV - 1)
> 163 continue;
> 164
> 165 if (remainder < min_diff) {
> 166 best_pre_div = pre_div;
> 167 best_pwm_div = pwm_div;
> 168 min_diff = remainder;
> 169
> 170 if (min_diff == 0) /* bingo */
> 171 break;
> 172 }
> 173 }
> 174
> 175 /* config divider values for the closest possible frequency */
> 176 config_div_and_duty(pwm, best_pre_div, best_pwm_div,
> 177 rate, duty_ns, state->enabled);
> 178
> 179 return 0;
> 180 }
> 181
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
next prev parent reply other threads:[~2022-02-08 7:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <17dd231f496d09ed8502bdd505eaa77bb6637e4b.1644226245.git.baruch@tkos.co.il>
2022-02-07 20:22 ` [PATCH 1/3] pwm: driver for qualcomm ipq6018 pwm block kernel test robot
2022-02-08 6:51 ` Baruch Siach [this message]
2022-02-08 18:47 ` Nathan Chancellor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ee4ddejv.fsf@tarshish \
--to=baruch@tkos.co.il \
--cc=agross@kernel.org \
--cc=bjagadee@codeaurora.org \
--cc=bjorn.andersson@linaro.org \
--cc=kathirav@codeaurora.org \
--cc=kbuild-all@lists.01.org \
--cc=linux-pwm@vger.kernel.org \
--cc=lkp@intel.com \
--cc=llvm@lists.linux.dev \
--cc=robert.marko@sartura.hr \
--cc=robh+dt@kernel.org \
--cc=thierry.reding@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox