[PATCH v3 3/3] i2c: rk3x: Add check for clk_enable()

[Jiasheng Jiang]

Hi Andi,

On Tue, Nov 19, 2024 at 5:03 PM Andi Shyti <andi.shyti at kernel.org> wrote:
>
> Hi Jiasheng,
>
> > > >  static u32 rk3x_i2c_func(struct i2c_adapter *adap)
> > > > @@ -1365,9 +1389,12 @@ static int rk3x_i2c_probe(struct platform_device *pdev)
> > > >       }
> > > >
> > > >       clk_rate = clk_get_rate(i2c->clk);
> > > > -     rk3x_i2c_adapt_div(i2c, clk_rate);
> > > > +     ret = rk3x_i2c_adapt_div(i2c, clk_rate);
> > > >       clk_disable(i2c->clk);
> > >
> > > you can't disable a clock that has failed to enable, right?
> > >
> > > BTW, although I like this patch (or at least I don't dislike), I
> > > still want to check whether it's wanted or not.
> > >
> > > Andi
> > >
> >
> > Thank you for your advice. I have carefully reviewed the patch.
> > There are two clocks: "i2c->clk" and "i2c->pclk".
> > The "i2c->clk" is enabled and disabled in rk3x_i2c_probe(),
> > while the "i2c->pclk" is managed within rk3x_i2c_adapt_div().
> > Thus, the "i2c->clk" has already been enabled at this point.
>
> yes, that's correct, that's a fast review and anyway your patch
> doesn't have anything to do with this.
>
> BTW, did you have real failure experience here or is it just
> speculation?

Currently, I have no idea how to trigger this failure.
In fact, I only identified it through static analysis.
However, I believe adding a check here will enhance the
robustness of the code.

-Jiasheng