All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Kemnade <andreas@kemnade.info>
To: Roger Quadros <rogerq@kernel.org>
Cc: Karol P <karprzy7@gmail.com>,
	aaro.koskinen@iki.fi, khilman@baylibre.com, tony@atomide.com,
	lee@kernel.org, linux-omap@vger.kernel.org,
	linux-kernel@vger.kernel.org, skhan@linuxfoundation.org
Subject: Re: [PATCH] mfd: omap-usb-tll: handle clk_prepare return code in usbtll_omap_probe
Date: Mon, 11 Nov 2024 20:57:08 +0100	[thread overview]
Message-ID: <20241111205708.562abb1c@akair> (raw)
In-Reply-To: <cd915c18-7230-4c38-a860-d2a777223147@kernel.org>

Am Mon, 11 Nov 2024 16:41:47 +0200
schrieb Roger Quadros <rogerq@kernel.org>:

> Hi,
> 
> On 10/11/2024 01:29, Andreas Kemnade wrote:
> > Am Thu, 7 Nov 2024 12:12:52 +0100
> > schrieb Karol P <karprzy7@gmail.com>:
> >   
> >> On Thu, 7 Nov 2024 at 00:15, Andreas Kemnade <andreas@kemnade.info> wrote:  
> >>>
> >>> Am Wed,  6 Nov 2024 23:33:24 +0100
> >>> schrieb Karol Przybylski <karprzy7@gmail.com>:
> >>>    
> >>>> 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 return statement
> >>>> when it's not successful.
> >>>>
> >>>> Found in coverity scan, CID 1594680
> >>>>
> >>>> Signed-off-by: Karol Przybylski <karprzy7@gmail.com>
> >>>> ---
> >>>>  drivers/mfd/omap-usb-tll.c | 8 ++++++--
> >>>>  1 file changed, 6 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
> >>>> index 0f7fdb99c809..28446b082c85 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");
> >>>>
> >>>> @@ -251,7 +251,11 @@ static int usbtll_omap_probe(struct platform_device *pdev)
> >>>>               if (IS_ERR(tll->ch_clk[i]))
> >>>>                       dev_dbg(dev, "can't get clock : %s\n", clkname);    
> >>>
> >>> if you add more intensive error checking, then why is this error
> >>> ignored and not returned?    
> >>
> >> Thank you for the feedback. It does seem that elevated error checking
> >> is not the way
> >> to go in this case.   
> > 
> > As far as I can see everything checks ch_clk[i] for validity before
> > usage. Also clk_enable() called later is checked which would catch
> > clk_prepare() failures, if there were even possible here.
> > 
> > So the only question which I am not 100% sure about is whether having
> > ch_clk sparsly populated is normal operation. If that is the case, then
> > more error checking is not useful. If not, then it might let us better
> > sleep. As said as far as I can see errors are catched later.
> > 
> > @Roger: what is your opintion towards this?  
> 
> I don't see usb_tll_hs_usb_ch?_clk in any of the OMAP device trees.
> Could it be that they are optional?
> If so then we could convert it to devm_clk_get_optional()?
> 
They live in drivers/clk/ti/clk-[54]4xx.c
But nothing about omap3. So apparently we can have valid use cases
where these clocks are not available. So no real need more anything
more than dev_dbg output here. 

Regards,
Andreas

  reply	other threads:[~2024-11-11 19:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-06 22:33 [PATCH] mfd: omap-usb-tll: handle clk_prepare return code in usbtll_omap_probe Karol Przybylski
2024-11-06 23:03 ` Shuah Khan
2024-11-06 23:15 ` Andreas Kemnade
2024-11-07 11:12   ` Karol P
2024-11-09 23:29     ` Andreas Kemnade
2024-11-11 14:41       ` Roger Quadros
2024-11-11 19:57         ` Andreas Kemnade [this message]
2024-11-12 11:59           ` Karol P

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241111205708.562abb1c@akair \
    --to=andreas@kemnade.info \
    --cc=aaro.koskinen@iki.fi \
    --cc=karprzy7@gmail.com \
    --cc=khilman@baylibre.com \
    --cc=lee@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=rogerq@kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.