lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 8 Apr 2020 19:40:45 -0700 From: Guru Das Srinagesh <gurus@...eaurora.org> To: David Laight <David.Laight@...LAB.COM> Cc: "linux-pwm@...r.kernel.org" <linux-pwm@...r.kernel.org>, Thierry Reding <thierry.reding@...il.com>, Uwe Kleine-König <uwe@...ine-koenig.org>, Subbaraman Narayanamurthy <subbaram@...eaurora.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Michael Turquette <mturquette@...libre.com>, Stephen Boyd <sboyd@...nel.org>, "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org> Subject: Re: [PATCH v8 01/12] clk: pwm: Use 64-bit division function On Thu, Mar 12, 2020 at 09:14:09AM +0000, David Laight wrote: > From: Guru Das Srinagesh > > Sent: 12 March 2020 02:10 > > On Wed, Mar 11, 2020 at 04:58:24PM +0000, David Laight wrote: > > > From: Guru Das Srinagesh > > > > Sent: 11 March 2020 01:41 > > > > > > > > Since the PWM framework is switching struct pwm_args.period's datatype > > > > to u64, prepare for this transition by using div64_u64 to handle a > > > > 64-bit divisor. > > > > > ... > > > > --- a/drivers/clk/clk-pwm.c > > > > +++ b/drivers/clk/clk-pwm.c > > > > @@ -89,7 +89,7 @@ static int clk_pwm_probe(struct platform_device *pdev) > > > > } > > > > > > > > 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 = div64_u64(NSEC_PER_SEC, pargs.period); > > > > > > That cannot be needed, a 32 bit division is fine. > > > > Could you please explain why? I think the use of this function is > > warranted in order to handle the division properly with a 64-bit > > divisor. > ... > > > I'd assign pargs.period to an 'unsigned int' variable > > > prior to the division (I hate casts - been bitten by them in the past.). > > > > Wouldn't this truncate the 64-bit value? The intention behind this patch > > is to allow the processing of 64-bit values in full. > > You are dividing a 32bit constant by a value. > If pargs.period is greater than 2^32 the result is zero. Correction: if pargs.period is greater than NSEC_PER_SEC, not 2^32. > I think you divide by 'fixed_rate' a bit later on - better not be zero. I am adding an explicit check in v12 to ensure fixed_rate is not zero. If during the calculation it is found to be zero, probing will fail. I think with this modification, this v8 version of this change makes sense to use. Thank you. Guru Das.
Powered by blists - more mailing lists