Hi Andi, On Tue, Nov 19, 2024 at 5:03 PM Andi Shyti <andi.shyti@xxxxxxxxxx> 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
