[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1708311020340.3243@hadrien>
Date: Thu, 31 Aug 2017 10:23:19 +0200 (CEST)
From: Julia Lawall <julia.lawall@...6.fr>
To: Alexandre Belloni <alexandre.belloni@...e-electrons.com>
cc: Christophe JAILLET <christophe.jaillet@...adoo.fr>, perex@...ex.cz,
tiwai@...e.com, arvind.yadav.cs@...il.com,
nicolas.ferre@...rochip.com, broonie@...nel.org,
garsilva@...eddedor.com, andriy.shevchenko@...ux.intel.com,
bhumirks@...il.com, alsa-devel@...a-project.org,
kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [alsa-devel] [PATCH] ALSA: ac97c: Fix an error handling path in
'atmel_ac97c_probe()'
On Thu, 31 Aug 2017, Alexandre Belloni wrote:
> On 31/08/2017 at 06:40:42 +0200, Christophe JAILLET wrote:
> > If 'clk_prepare_enable()' fails, we must release some resources before
> > returning. Add a new label in the existing error handling path and 'goto'
> > there.
> >
> > Fixes: 260ea95cc027 ("ASoC: atmel: ac97c: Handle return value of clk_prepare_enable.")
> > Signed-off-by: Christophe JAILLET <christophe.jaillet@...adoo.fr>
>
> And here is the fallout of the stupid, brainless "fixing" of issues
> reported by static analysis tools.
>
> This clk_prepare_enable will never fail. If it was going to fail, the
> platform would never boot to a point were it is able to execute that
> code. It is really annoying to have so much churn for absolutely 0
> benefit.
Would it be more productive to put the code back like it was before, ie no
return value and no check, and add a comment to the definition of
clk_prepare_enable indicating that there are many case where the call
cannot fail? Grepping through the code suggests that it is about 50-50 on
checking the return value or not doing so, which might suggest that
checking the value is often not required.
julia
>
> Anyway,
> Acked-by: Alexandre Belloni <alexandre.belloni@...e-electrons.com>
>
> > ---
> > sound/atmel/ac97c.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/sound/atmel/ac97c.c b/sound/atmel/ac97c.c
> > index 30c64ab210d9..5ffefac2fa8f 100644
> > --- a/sound/atmel/ac97c.c
> > +++ b/sound/atmel/ac97c.c
> > @@ -785,7 +785,7 @@ static int atmel_ac97c_probe(struct platform_device *pdev)
> > }
> > retval = clk_prepare_enable(pclk);
> > if (retval)
> > - return retval;
> > + goto err_prepare_enable;
> >
> > retval = snd_card_new(&pdev->dev, SNDRV_DEFAULT_IDX1,
> > SNDRV_DEFAULT_STR1, THIS_MODULE,
> > @@ -881,6 +881,7 @@ static int atmel_ac97c_probe(struct platform_device *pdev)
> > snd_card_free(card);
> > err_snd_card_new:
> > clk_disable_unprepare(pclk);
> > +err_prepare_enable:
> > clk_put(pclk);
> > return retval;
> > }
> > --
> > 2.11.0
> >
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@...a-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Powered by blists - more mailing lists