On Wed, Nov 13, 2024 at 5:24 PM Andi Shyti <andi.shyti@xxxxxxxxxx> wrote: > > Hi Jiasheng, > > On Thu, Nov 07, 2024 at 09:14:28PM +0000, Jiasheng Jiang wrote: > > Add check for the return value of clk_enable() in order to catch the > > potential exception. Moreover, convert the return type of > > It's more an "unlikely exception" rather than a "potential > exeption". > > > rk3x_i2c_adapt_div() into int and add the check. > > ... > > > 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. -Jiasheng > > > > + if (ret) > > + goto err_clk_notifier; > > + > > ret = i2c_add_adapter(&i2c->adap); > > if (ret < 0) > > goto err_clk_notifier; > > -- > > 2.25.1 > >