public inbox for linux-pwm@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox