Am Tue, 19 Nov 2024 15:10:23 +0200 schrieb Roger Quadros <rogerq@xxxxxxxxxx>: > Hi, > > On 13/11/2024 23:16, Karol Przybylski wrote: > > clk_prepare() is called in usbtll_omap_probe to fill clk array. > > Return code is not checked, leaving possible error condition unhandled. > > > > Added variable to hold return value from clk_prepare() and dev_dbg statement > > when it's not successful. > > > > Found in coverity scan, CID 1594680 > > > > Signed-off-by: Karol Przybylski <karprzy7@xxxxxxxxx> > > --- > > drivers/mfd/omap-usb-tll.c | 11 +++++++---- > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c > > index 0f7fdb99c809..2e9319ee1b74 100644 > > --- a/drivers/mfd/omap-usb-tll.c > > +++ b/drivers/mfd/omap-usb-tll.c > > @@ -202,7 +202,7 @@ static int usbtll_omap_probe(struct platform_device *pdev) > > struct device *dev = &pdev->dev; > > struct usbtll_omap *tll; > > void __iomem *base; > > - int i, nch, ver; > > + int i, nch, ver, err; > > > > dev_dbg(dev, "starting TI HSUSB TLL Controller\n"); > > > > @@ -248,10 +248,13 @@ static int usbtll_omap_probe(struct platform_device *pdev) > > "usb_tll_hs_usb_ch%d_clk", i); > > tll->ch_clk[i] = clk_get(dev, clkname); > > > > - if (IS_ERR(tll->ch_clk[i])) > > + if (IS_ERR(tll->ch_clk[i])) { > > dev_dbg(dev, "can't get clock : %s\n", clkname); if you want dev_err() later, then why not here? > > - else > > - clk_prepare(tll->ch_clk[i]); > > + } else { > > + err = clk_prepare(tll->ch_clk[i]); > > + if (err) > > + dev_dbg(dev, "clock prepare error for: %s\n", clkname); > > dev_err()? > So why do you want a different return handling here? (I doubt there is any clock having a real prepare() involved here) As said in an earlier incarnation of this patch, the real question is whether having partial clocks available is a valid operating scenario. If yes, then the error should be ignored. If no, then bailing out early is a good idea. clk_prepare() errors are catched by failing clk_enable() later, ch_clk[i] is checked later, too. > I think we should return the error in this case. > (after unpreparing the prepared clocks and clk_put()) > and pm_runtime_put_sync(dev) Regards, Andreas