From: Guru Das Srinagesh <gurus@codeaurora.org>
To: David Laight <David.Laight@ACULAB.COM>
Cc: "'Arnd Bergmann'" <arnd@arndb.de>,
"Linux PWM List" <linux-pwm@vger.kernel.org>,
"Thierry Reding" <thierry.reding@gmail.com>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Subbaraman Narayanamurthy" <subbaram@codeaurora.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Michael Turquette" <mturquette@baylibre.com>,
"Stephen Boyd" <sboyd@kernel.org>,
linux-clk <linux-clk@vger.kernel.org>
Subject: Re: [PATCH v11 11/12] clk: pwm: Assign u64 divisor to unsigned int before use
Date: Mon, 6 Apr 2020 19:40:13 -0700 [thread overview]
Message-ID: <20200407024013.GB7019@codeaurora.org> (raw)
In-Reply-To: <9943d663c74046d798f4614343f25187@AcuMS.aculab.com>
On Fri, Mar 20, 2020 at 06:42:39PM +0000, David Laight wrote:
> From: Arnd Bergmann
> > Sent: 20 March 2020 17:01
> > On Fri, Mar 20, 2020 at 2:42 AM Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> > >
> > > Since the PWM framework is switching struct pwm_args.period's datatype
> > > to u64, prepare for this transition by assigning the 64-bit divisor to
> > > an unsigned int variable to use as the divisor. This is being done
> > > because the divisor is a 32-bit constant and the quotient will be zero
> > > if the divisor exceeds 2^32.
Correction: The quotient will be zero when the denominator exceeds the
numerator, i.e. NSECS_PER_SEC, and not U32_MAX. For this to happen, the
property "clock-frequency" must be specified to be more than
NSEC_PER_SEC, i.e. 1 GHz. Just observed that currently in the device
tree, all instances of this driver (compatible string "pwm-clock") are
setting this property to values within that limit.
> > >
> > > Cc: Michael Turquette <mturquette@baylibre.com>
> > > Cc: Stephen Boyd <sboyd@kernel.org>
> > > Cc: linux-clk@vger.kernel.org
> > > Cc: David Laight <David.Laight@ACULAB.COM>
> > >
> > > Reported-by: kbuild test robot <lkp@intel.com>
> > > Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> > > ---
> > > drivers/clk/clk-pwm.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
> > > index 87fe0b0e..c0b5da3 100644
> > > --- a/drivers/clk/clk-pwm.c
> > > +++ b/drivers/clk/clk-pwm.c
> > > @@ -72,6 +72,7 @@ static int clk_pwm_probe(struct platform_device *pdev)
> > > struct pwm_device *pwm;
> > > struct pwm_args pargs;
> > > const char *clk_name;
> > > + unsigned int period;
> > > int ret;
> > >
> > > clk_pwm = devm_kzalloc(&pdev->dev, sizeof(*clk_pwm), GFP_KERNEL);
> > > @@ -88,8 +89,9 @@ static int clk_pwm_probe(struct platform_device *pdev)
> > > return -EINVAL;
> > > }
> > >
> > > + period = pargs.period;
> > > if (of_property_read_u32(node, "clock-frequency", &clk_pwm->fixed_rate))
> > > - clk_pwm->fixed_rate = NSEC_PER_SEC / pargs.period;
> > > + clk_pwm->fixed_rate = NSEC_PER_SEC / period;
> > >
> > > if (pargs.period != NSEC_PER_SEC / clk_pwm->fixed_rate &&
> > > pargs.period != DIV_ROUND_UP(NSEC_PER_SEC, clk_pwm->fixed_rate)) {
> >
> > Doesn't this one need a check for "pargs.period>UINT_MAX" or
> > "pargs.period > NSEC_PER_SEC"?
> >
With the assignment of period to unsigned int, wouldn't doing
s/pargs.period/period suffice?
Also, will add a check to ensure that clk_pwm->fixed_rate is non-zero. If it
is zero, fail probe.
> > It looks like truncating the 64-bit value to a 32-bit type can result in
> > unexpected behavior.
>
> I also suspect the last two lines ought to use the 32bit copy.
> And there is a chance that the division will explode.
The check mentioned above will ensure that the division will not
explode.
What do you guys think?
Thank you.
Guru Das.
next prev parent reply other threads:[~2020-04-07 2:40 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1584667964.git.gurus@codeaurora.org>
2020-03-20 1:41 ` [PATCH v11 01/12] drm/i915: Use 64-bit division macro Guru Das Srinagesh
2020-03-20 1:41 ` [PATCH v11 02/12] hwmon: pwm-fan: " Guru Das Srinagesh
2020-03-20 1:41 ` [PATCH v11 03/12] ir-rx51: " Guru Das Srinagesh
2020-03-20 1:41 ` [PATCH v11 04/12] pwm: clps711x: Cast period to u32 before use as divisor Guru Das Srinagesh
2020-03-20 17:11 ` Arnd Bergmann
2020-04-07 0:26 ` Guru Das Srinagesh
2020-03-20 1:41 ` [PATCH v11 05/12] pwm: pwm-imx-tpm: Use 64-bit division macro Guru Das Srinagesh
2020-03-20 1:41 ` [PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function Guru Das Srinagesh
2020-03-20 17:09 ` Arnd Bergmann
2020-03-30 20:43 ` Guru Das Srinagesh
2020-03-31 15:24 ` Arnd Bergmann
2020-03-31 20:20 ` Guru Das Srinagesh
2020-03-31 20:49 ` Thierry Reding
2020-04-02 20:16 ` Guru Das Srinagesh
2020-04-02 20:55 ` Guru Das Srinagesh
2020-04-02 21:16 ` Arnd Bergmann
2020-04-03 17:37 ` Guru Das Srinagesh
2020-04-03 19:13 ` Arnd Bergmann
2020-03-20 1:41 ` [PATCH v11 07/12] pwm: sifive: Use 64-bit division macro Guru Das Srinagesh
2020-03-20 1:41 ` [PATCH v11 08/12] pwm: stm32-lp: Use %llu format specifier for period Guru Das Srinagesh
2020-03-20 10:45 ` Joe Perches
2020-03-30 19:30 ` Guru Das Srinagesh
2020-03-20 1:41 ` [PATCH v11 09/12] pwm: sun4i: Use 64-bit division function Guru Das Srinagesh
2020-03-20 17:02 ` Arnd Bergmann
2020-03-20 1:41 ` [PATCH v11 10/12] backlight: pwm_bl: " Guru Das Srinagesh
2020-03-20 13:31 ` Lee Jones
2020-03-24 11:07 ` Lee Jones
2020-03-24 12:57 ` Uwe Kleine-König
2020-03-24 13:04 ` Daniel Thompson
2020-03-24 14:24 ` Lee Jones
2020-03-24 14:43 ` Uwe Kleine-König
2020-04-15 9:26 ` Lee Jones
2020-03-20 1:41 ` [PATCH v11 11/12] clk: pwm: Assign u64 divisor to unsigned int before use Guru Das Srinagesh
2020-03-20 17:00 ` Arnd Bergmann
2020-03-20 18:42 ` David Laight
2020-04-07 2:40 ` Guru Das Srinagesh [this message]
2020-03-20 1:41 ` [PATCH v11 12/12] pwm: core: Convert period and duty cycle to u64 Guru Das Srinagesh
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=20200407024013.GB7019@codeaurora.org \
--to=gurus@codeaurora.org \
--cc=David.Laight@ACULAB.COM \
--cc=arnd@arndb.de \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=sboyd@kernel.org \
--cc=subbaram@codeaurora.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;
as well as URLs for NNTP newsgroup(s).