All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Uwe Kleine-König" <uwe@kleine-koenig.org>,
	"Ajit Pal Singh" <ajitpal.singh@st.com>,
	linux-pwm@vger.kernel.org
Subject: Re: [PATCH] pwm: sti: fix error handling
Date: Wed, 11 Nov 2020 20:28:23 +0100	[thread overview]
Message-ID: <20201111192823.GD6125@ulmo> (raw)
In-Reply-To: <20201106102908.GC2063125@dell>

[-- Attachment #1: Type: text/plain, Size: 4798 bytes --]

On Fri, Nov 06, 2020 at 10:29:08AM +0000, Lee Jones wrote:
> On Fri, 06 Nov 2020, Uwe Kleine-König wrote:
> 
> > Hello Lee,
> > 
> > On Fri, Nov 06, 2020 at 08:29:14AM +0000, Lee Jones wrote:
> > > On Tue, 13 Oct 2020, Uwe Kleine-König wrote:
> > > 
> > > > This commit fixes several faults:
> > > > 
> > > >  - Iff a clk was returned by of_clk_get_by_name() it must be dereferenced
> > > >    by calling clk_put().
> > > >  - A clk that was prepared must be unprepared.
> > > >  - The .remove callback isn't supposed to call pwm_disable().
> > > >  - The necessary resources needed by the PWM must not be freed before
> > > >    pwmchip_remove() was called.
> > > > 
> > > > Fixes: 378fe115d19d ("pwm: sti: Add new driver for ST's PWM IP")
> > > > Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
> > > > ---
> > > >  drivers/pwm/pwm-sti.c | 49 ++++++++++++++++++++++++++++++++-----------
> > > >  1 file changed, 37 insertions(+), 12 deletions(-)
> > > 
> > > Sorry for the delay, this ended up in spam.
> > > 
> > > > diff --git a/drivers/pwm/pwm-sti.c b/drivers/pwm/pwm-sti.c
> > > > index 1508616d794c..f89f8cbdfdfc 100644
> > > > --- a/drivers/pwm/pwm-sti.c
> > > > +++ b/drivers/pwm/pwm-sti.c
> > > > @@ -605,7 +605,7 @@ static int sti_pwm_probe(struct platform_device *pdev)
> > > >  	ret = clk_prepare(pc->pwm_clk);
> > > >  	if (ret) {
> > > >  		dev_err(dev, "failed to prepare clock\n");
> > > > -		return ret;
> > > > +		goto err_pwm_clk_prepare;
> > > 
> > > I would prefer these to indicate the intention, rather than were they
> > > were called from.  So err_put_cpt_clk for this one, etc.
> > 
> > This might be subjective, but I like it better the way I did it. My
> > pattern is:
> > 
> > 	ret = get_resource_A();
> > 	if (ret)
> > 		goto err_A;
> > 
> > 	ret = get_resource_B();
> > 	if (ret)
> > 		goto err_B;
> > 
> > 	...
> > 
> > 	put_resource_B();
> > err_B:
> > 	
> > 	put_resource_A();
> > err_A:
> > 
> > 	return ret;
> > 
> > This way just looking at on get_resource_$X block it is obvious that the
> > picked label is right and in the error handling blocks that's obvious,
> > too.
> > 
> > However with the (admittedly more common) style you prefer it is:
> > 
> > 	ret = get_resource_A();
> > 	if (ret)
> > 		goto return_ret; // or just: return ret
> > 
> > 	ret = get_resource_B();
> > 	if (ret)
> > 		goto put_A;
> > 
> > 	...
> > 
> > put_B:
> > 	put_resource_B();
> > 
> > put_A:
> > 	put_resource_A();
> > 
> > return_ret:
> > 	return ret;
> > 
> > You have to check the previous block to see that put_A is right for
> > the error path of get_resource_B(). In this trivial example you have to
> > look back 6 instead of 2 lines. For more complex stuff it tends to be
> > 3 lines for my approach (one more for the error message, and so still in
> > the same logical block) but might be considerably bigger for the common
> > approach. The usual amount of context in patches is 3 lines. And if you
> > add another resource allocation between A and B you have to adapt the
> > error path in B which is somewhat unrelated. So a patch adding A2 looks
> > for my approach:
> > 
> > @@ ...
> >  	if (ret)
> >  		goto err_A;
> >  
> > +	ret = get_resource_A2();
> > +	if (ret)
> > +		goto err_A2;
> > +
> >  	ret = get_resource_B();
> >  	if (ret)
> >  		goto err_B;
> > @@ ...
> >  	put_resource_B();
> >  err_B:
> >  	
> > +	put_resource_A2();
> > +err_A2:
> > +
> >  	put_resource_A()
> >  err_A:
> >  
> > Here you see that the right error label is used in the new error path
> > and that it is placed correctly between err_B and err_A.
> > 
> > For your preferred approach the patch looks as follows:
> > 
> > @@ ...
> >  	if (ret)
> >  		goto return_ret;
> >  
> > +	ret = get_resource_A2();
> > +	if (ret)
> > +		goto put_A;
> > +
> >  	ret = get_resource_B();
> >  	if (ret)
> > -		goto put_A;
> > +		goto put_A2;
> >  
> >  	...
> > @@ ...
> >  put_B: 
> >  	put_resource_B();
> >  
> > +put_A2:
> > +	put_resource_A2;
> > +
> >  put_A:
> >  	put_resource_A();
> >  
> > Note you cannot see by just looking at the patch that goto put_A is
> > right. (Well, if you assume that the old code is correct see that just
> > before put_A B is freed which matches what just happens after your new
> > get_resource_A2, but that's considerably more complicated.) Also you
> > have to modify the goto for B.
> > 
> > This is in my eyes ugly enough to justify my preference.
> 
> Wow, you sure put a lot of effort into that. :)
> 
> I'll leave it up to ST and Thierry to have the final say.

I agree with Lee on this one, so I've applied the patch and touched up
the label names while at it.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-11-11 19:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-13  8:15 [PATCH] pwm: sti: fix error handling Uwe Kleine-König
2020-11-06  8:29 ` Lee Jones
2020-11-06  9:34   ` Uwe Kleine-König
2020-11-06 10:29     ` Lee Jones
2020-11-11 19:28       ` Thierry Reding [this message]
2020-11-11 19:43         ` Uwe Kleine-König
2020-11-11 19:52           ` Thierry Reding
2020-11-11 20:39             ` Uwe Kleine-König
2020-11-11 21:16               ` Thierry Reding

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=20201111192823.GD6125@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=ajitpal.singh@st.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=u.kleine-koenig@pengutronix.de \
    --cc=uwe@kleine-koenig.org \
    /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.