Re: [PATCH] clk: shmobile: div6: Avoid division by zero in .round_rate()

[Mike Turquette]

Quoting Laurent Pinchart (2015-02-05 09:19:14)
> Hi Sergei,
> 
> On Thursday 05 February 2015 01:14:46 Sergei Shtylyov wrote:
> > On 02/05/2015 01:04 AM, Sergei Shtylyov wrote:
> > >>>>> Anyone may call clk_round_rate() with a zero rate value, so we have to
> > >>>>> protect against that.
> > >>>>> 
> > >>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
> > >>>> 
> > >>>> Acked-by: Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx>
> > >>>> 
> > >>>> I agree that this should not be fixed in the core because the fixup is
> > >>>> really driver dependant.
> > >>>> 
> > >>> Dunno, zero frequency seems generally insane to me.
> > >> 
> > >> It is useful to find the lowest frequency a clock can support. Basically
> > >> it is a search for the floor frequency.
> > >> 
> > > Why not just use 1? Or are you assuming that some hardware could actually
> > > support 0 Hz?
> > 
> > Replying to myself: yes, this has happened to me, when I forgot to override
> > the EXTAL frequency in the board .dts file (default was 0).
> 
> So it was a good thing that the driver crashed, it let you find a bug ;-)
> 
> Jokes aside, a zero frequency is the usual way to find the lowest frequency, 
> but I agree that there aren't many integers between 0 and 1. Mike, do you have 
> an opinion ?

Yes, I think we should support passing a zero rate for two reasons:

1) it's crazy to not sanitize a value that is passed into a function and
used as a divisor. This is not really a shortcoming of the framework.

2) during the fractional divider discussion there was the idea of making
unsigned long rate into something like millihertz. E.g. rate = 1000 is
1Hz. If we start cheating by passing a rate of 1 into .round_rate, then
we've just created a bug for ourselves if we ever move to millihertz.

Regards,
Mike

> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/