All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Baruch Siach <baruch@tkos.co.il>
Cc: "kernel test robot" <lkp@intel.com>,
	"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, 8 Feb 2022 11:47:57 -0700	[thread overview]
Message-ID: <YgK63cI177ZeF5v1@dev-arch.archlinux-ax161> (raw)
In-Reply-To: <87ee4ddejv.fsf@tarshish>

Hi Baruch,

On Tue, Feb 08, 2022 at 08:51:40AM +0200, Baruch Siach wrote:
> 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?

As far as I am aware, casting to unsigned long long would be an
appropriate way to fix this warning, as has been done in the following
patches in mainline:

c9ae8eed4463 ("media: omap3isp: avoid warnings at IS_OUT_OF_BOUNDS()")
4853396f03c3 ("memstick: avoid out-of-range warning")
7ff4034e910f ("staging: vc04_services: shut up out-of-range warning")
a2fa9e57a68c ("ARM: mvebu: avoid clang -Wtautological-constant warning")

The below diff fixes the warning for me with ARCH=hexagon allyesconfig:

diff --git a/drivers/pwm/pwm-ipq.c b/drivers/pwm/pwm-ipq.c
index 994027290bcb..7ea29468e76e 100644
--- a/drivers/pwm/pwm-ipq.c
+++ b/drivers/pwm/pwm-ipq.c
@@ -119,7 +119,7 @@ static int ipq_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	 * period_ns is 1G or less. As long as rate is less than 16 GHz,
 	 * period_rate does not overflow. Make that explicit.
 	 */
-	if (rate > 16ULL * GIGA)
+	if ((unsigned long long)rate > 16ULL * GIGA)
 		return -EINVAL;
 	period_rate = period_ns * rate;
 	best_pre_div = IPQ_PWM_MAX_DIV;

Alternatively, you could widen rate to unsigned long long / u64 but I
don't know what kind of implications that has in this function but it
has been done in other places:

95c58291ee70 ("drm/msm/submit: fix overflow check on 64-bit architectures")
cfd6fb45cfaf ("crypto: ccree - avoid out-of-range warnings from clang")
335aea75b0d9 ("drm/amdgpu: fix warning for overflow check")
844b85dda2f5 ("ARM: keystone: fix integer overflow warning")

While the warning is currently under W=1, I think it is one that we
would like to turn on at some point so fixing instances as they come up
helps us get closer to that goal.

Cheers,
Nathan

> > 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 -
> 

WARNING: multiple messages have this Message-ID (diff)
From: Nathan Chancellor <nathan@kernel.org>
To: kbuild-all@lists.01.org
Subject: Re: [PATCH 1/3] pwm: driver for qualcomm ipq6018 pwm block
Date: Tue, 08 Feb 2022 11:47:57 -0700	[thread overview]
Message-ID: <YgK63cI177ZeF5v1@dev-arch.archlinux-ax161> (raw)
In-Reply-To: <87ee4ddejv.fsf@tarshish>

[-- Attachment #1: Type: text/plain, Size: 6213 bytes --]

Hi Baruch,

On Tue, Feb 08, 2022 at 08:51:40AM +0200, Baruch Siach wrote:
> 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?

As far as I am aware, casting to unsigned long long would be an
appropriate way to fix this warning, as has been done in the following
patches in mainline:

c9ae8eed4463 ("media: omap3isp: avoid warnings at IS_OUT_OF_BOUNDS()")
4853396f03c3 ("memstick: avoid out-of-range warning")
7ff4034e910f ("staging: vc04_services: shut up out-of-range warning")
a2fa9e57a68c ("ARM: mvebu: avoid clang -Wtautological-constant warning")

The below diff fixes the warning for me with ARCH=hexagon allyesconfig:

diff --git a/drivers/pwm/pwm-ipq.c b/drivers/pwm/pwm-ipq.c
index 994027290bcb..7ea29468e76e 100644
--- a/drivers/pwm/pwm-ipq.c
+++ b/drivers/pwm/pwm-ipq.c
@@ -119,7 +119,7 @@ static int ipq_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	 * period_ns is 1G or less. As long as rate is less than 16 GHz,
 	 * period_rate does not overflow. Make that explicit.
 	 */
-	if (rate > 16ULL * GIGA)
+	if ((unsigned long long)rate > 16ULL * GIGA)
 		return -EINVAL;
 	period_rate = period_ns * rate;
 	best_pre_div = IPQ_PWM_MAX_DIV;

Alternatively, you could widen rate to unsigned long long / u64 but I
don't know what kind of implications that has in this function but it
has been done in other places:

95c58291ee70 ("drm/msm/submit: fix overflow check on 64-bit architectures")
cfd6fb45cfaf ("crypto: ccree - avoid out-of-range warnings from clang")
335aea75b0d9 ("drm/amdgpu: fix warning for overflow check")
844b85dda2f5 ("ARM: keystone: fix integer overflow warning")

While the warning is currently under W=1, I think it is one that we
would like to turn on at some point so fixing instances as they come up
helps us get closer to that goal.

Cheers,
Nathan

> > 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(a)lists.01.org
> 
> 
> -- 
>                                                      ~. .~   Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
>    - baruch(a)tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
> 

  reply	other threads:[~2022-02-08 18:48 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-07  9:30 [PATCH 1/3] pwm: driver for qualcomm ipq6018 pwm block Baruch Siach
2022-02-07  9:30 ` Baruch Siach
2022-02-07  9:30 ` [PATCH 2/3] dt-bindings: pwm: add IPQ6018 binding Baruch Siach
2022-02-07  9:30   ` Baruch Siach
2022-02-24 19:48   ` Bjorn Andersson
2022-02-24 19:48     ` Bjorn Andersson
2022-02-07  9:30 ` [PATCH 3/3] arm64: dts: ipq6018: add pwm node Baruch Siach
2022-02-07  9:30   ` Baruch Siach
2022-02-07 20:22 ` [PATCH 1/3] pwm: driver for qualcomm ipq6018 pwm block kernel test robot
2022-02-07 20:22   ` kernel test robot
2022-02-08  6:51   ` Baruch Siach
2022-02-08  6:51     ` Baruch Siach
2022-02-08 18:47     ` Nathan Chancellor [this message]
2022-02-08 18:47       ` Nathan Chancellor
2023-09-15  6:25 ` Devi Priya
2023-09-15  6:25   ` Devi Priya
2023-09-15  6:36   ` Baruch Siach
2023-09-15  6:36     ` Baruch Siach
2023-09-20  4:58     ` Devi Priya
2023-09-20  4:58       ` Devi Priya
2023-09-22  6:00     ` Devi Priya
2023-09-22  6:00       ` Devi Priya
2023-09-22  8:35       ` Baruch Siach
2023-09-22  8:35         ` Baruch Siach
2023-09-22 10:56         ` Devi Priya
2023-09-22 10:56           ` Devi Priya
  -- strict thread matches above, loose matches on Subject: below --
2021-05-19  7:48 Baruch Siach
2021-05-19  7:48 ` Baruch Siach
2021-05-22 21:35 ` Uwe Kleine-König
2021-05-22 21:35   ` Uwe Kleine-König
2021-05-23 15:54   ` Baruch Siach
2021-05-23 15:54     ` Baruch Siach
2021-05-22 21:37 ` Uwe Kleine-König
2021-05-22 21:37   ` Uwe Kleine-König

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=YgK63cI177ZeF5v1@dev-arch.archlinux-ax161 \
    --to=nathan@kernel.org \
    --cc=agross@kernel.org \
    --cc=baruch@tkos.co.il \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.