Re: [PATCH v8 01/12] clk: pwm: Use 64-bit division function

[Guru Das Srinagesh <gurus@codeaurora.org>]

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.

Thanks for the explanation. 

> I think you divide by 'fixed_rate' a bit later on - better not be zero.

Good point, but this issue exists with or without this patch, and fixing
it is beyond this patch's scope.

Just to check if this patch can be dropped, I tested out compilation
with this patch reverted and there were no errors, so I'm leaning
towards dropping this patch unless you have any further comments on how
to proceed.

Thank you.

Guru Das.