Message ID | 20230906200024.5305-1-wsa+renesas@sang-engineering.com |
---|---|
Headers | show |
Series | i2c: clock calculation cleanups for Renesas devices | expand |
Hi Wolfram Sang, > Subject: [PATCH 5/5] i2c: riic: avoid potential division by zero > > Value comes from DT, so it could be 0. Unlikely, but could be. > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > --- > drivers/i2c/busses/i2c-riic.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/i2c/busses/i2c-riic.c b/drivers/i2c/busses/i2c-riic.c > index f0ee8871d5ae..e43ff483c56e 100644 > --- a/drivers/i2c/busses/i2c-riic.c > +++ b/drivers/i2c/busses/i2c-riic.c > @@ -313,7 +313,7 @@ static int riic_init_hw(struct riic_dev *riic, struct > i2c_timings *t) > * frequency with only 62 clock ticks max (31 high, 31 low). > * Aim for a duty of 60% LOW, 40% HIGH. > */ > - total_ticks = DIV_ROUND_UP(rate, t->bus_freq_hz); > + total_ticks = DIV_ROUND_UP(rate, t->bus_freq_hz ?: 1); Not sure clamping function min_t/min(t->bus_freq_hz, 1) Or ternary condition is good in this case for avoiding potential division by 0? Cheers, Biju > > for (cks = 0; cks < 7; cks++) { > /* > -- > 2.35.1
> Subject: RE: [PATCH 5/5] i2c: riic: avoid potential division by zero > > Hi Wolfram Sang, > > > Subject: [PATCH 5/5] i2c: riic: avoid potential division by zero > > > > Value comes from DT, so it could be 0. Unlikely, but could be. > > > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > > --- > > drivers/i2c/busses/i2c-riic.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/i2c/busses/i2c-riic.c > > b/drivers/i2c/busses/i2c-riic.c index f0ee8871d5ae..e43ff483c56e > > 100644 > > --- a/drivers/i2c/busses/i2c-riic.c > > +++ b/drivers/i2c/busses/i2c-riic.c > > @@ -313,7 +313,7 @@ static int riic_init_hw(struct riic_dev *riic, > > struct i2c_timings *t) > > * frequency with only 62 clock ticks max (31 high, 31 low). > > * Aim for a duty of 60% LOW, 40% HIGH. > > */ > > - total_ticks = DIV_ROUND_UP(rate, t->bus_freq_hz); > > + total_ticks = DIV_ROUND_UP(rate, t->bus_freq_hz ?: 1); > > Not sure clamping function min_t/min(t->bus_freq_hz, 1) Typo min->max.
> > - total_ticks = DIV_ROUND_UP(rate, t->bus_freq_hz); > > + total_ticks = DIV_ROUND_UP(rate, t->bus_freq_hz ?: 1); > > Not sure clamping function min_t/min(t->bus_freq_hz, 1) > Or ternary condition is good in this case for avoiding potential division by 0? Both work. I chose the ternary because I believe it involves less computation and a tad tighter syntax.
On Wed, 6 Sep 2023, Wolfram Sang wrote: > Kernel functions goto somewhere on error conditions. Using goto for the > default path is irritating. Let's bail out on error instead and use a > proper retval. > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Wed, 6 Sep 2023, Wolfram Sang wrote: > Value comes from DT, so it could be 0. Unlikely, but could be. > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Wed, Sep 06, 2023 at 10:00:18PM +0200, Wolfram Sang wrote: > While implementing FastMode+ support for the R-Car IP core, I noticed > potential for other cleanups. It turned out that it makes sense to apply > them first, so here is the series. Tested on a Renesas Falcon board with > an R-Car V3U. The calculated values are identical for 100 and 400kHz. > The RIIC patch is build tested only. > > Looking forward to comments! > > > Wolfram Sang (5): > i2c: rcar: avoid non-standard use of goto > i2c: rcar: properly format a debug output > i2c: rcar: calculate divider instead of brute-forcing it > i2c: rcar: remove open coded DIV_ROUND_CLOSEST > i2c: riic: avoid potential division by zero > Applied to for-next, thanks!