[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220210100944.ebkiezfablofqitj@pengutronix.de>
Date: Thu, 10 Feb 2022 11:09:44 +0100
From: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To: David Laight <David.Laight@...LAB.COM>
Cc: Qing Wang <wangqing@...o.com>,
Thierry Reding <thierry.reding@...il.com>,
Lee Jones <lee.jones@...aro.org>,
"linux-pwm@...r.kernel.org" <linux-pwm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] pwm: use div64_u64() instead of do_div()
On Thu, Feb 10, 2022 at 09:48:44AM +0000, David Laight wrote:
> From: Uwe Kleine-König
> > Sent: 09 February 2022 15:26
> ...
> > > - do_div(cycles, period_ns);
> > > + div64_u64(cycles, period_ns);
> >
> > This is wrong, div64_u64() has a different calling convention than do_div().
> >
> > The issue however is real. Please add
>
> Not really although I can't see a check I'd assume that period_ns
> is expected to be much less than a second - so well under 32 bits
> There is certainly a general expectation that multiplying by
> other 'largish' values won't exceed 64 bits.
I'd consider such expectations a bug and hope to catch this type of
problem for new drivers. However I'm not surprised if you can point out
several such problems in the code base. Please fix at will :-)
> Plausible the pwm 'period' should actually be a u32.
> But then care would be needed to ensure the multiplies have
> 64bit results.
There are definitely consumers expecting to be able to set bigger
periods, see a9d887dc1c60ed67f2271d66560cdcf864c4a578.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists