All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: "Enric Balletbo Serra" <eballetbo@gmail.com>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	"Mark Brown" <broonie@kernel.org>,
	"Matti Vaittinen" <mazziesaccount@gmail.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
	"Sebastian Reichel" <sre@kernel.org>,
	chenjh@rock-chips.com,
	"Andrey Smirnov" <andrew.smirnov@gmail.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Kate Stewart" <kstewart@linuxfoundation.org>,
	"Heiko Stübner" <heiko@sntech.de>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	sboyd@kernel.org, linux-clk@vger.kernel.org,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-input@vger.kernel.org, mikko.mutanen@fi.rohmeurope.com,
	heikki.haikola@fi.rohmeurope.com
Subject: Re: [PATCH v8 1/2] mfd: bd71837: mfd driver for ROHM BD71837 PMIC
Date: Wed, 4 Jul 2018 13:34:30 +0300	[thread overview]
Message-ID: <20180704103430.GA13087@localhost.localdomain> (raw)
In-Reply-To: <20180704101102.GA496@dell>

On Wed, Jul 04, 2018 at 11:11:02AM +0100, Lee Jones wrote:
> On Wed, 04 Jul 2018, Matti Vaittinen wrote:
> 
> > On Wed, Jul 04, 2018 at 11:39:11AM +0300, Matti Vaittinen wrote:
> > > On Tue, Jul 03, 2018 at 11:26:00AM +0200, Enric Balletbo Serra wrote:
> > > > Missatge de Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> del
> > > > dia dv., 29 de juny 2018 a les 11:47:
> > > > 
> > > > Now that you use devm calls and you don't need to unwind things I
> > > > think is better to use plain returns. So,
> > > > 
> > > > return -ENOMEM;
> > > 
> > > I have never really understood why use of gotos in error handling is
> > > discouraged.
> 
> They're not.
> 
> > > Personally I would always choose single point of exit from
> > > a function when it is simple enough to achieve (like in this case). I've
> > > written and fixed way too many functions which leak resources or
> > > accidentally keep a lock when exiting from error branches. But I know
> > > many colleagues like you who prefer not to have gotos but  in place returns
> > > instead. So I guess I'll leave the final call on this to the one who is
> > > maintainer for this code. And it is true there is no things to unwind
> > > now - which does not mean that next updater won't add such. But as I
> > > said, I know plenty of people share your view - and even though I rather
> > > maintain code with only one exit the final call is on subsystem maintainer
> > > here.
> 
> Please use gotos in the error path.
> 
> IMO, it's the nicest way to unwind (as you call it).

I'll keep the gotos but clean other stuff for patch v9 then.
> 
> > Actually, If it was completely my call the probe would look something
> > like this:
> > 
> > +static int bd71837_i2c_probe(struct i2c_client *i2c,
> > +                           const struct i2c_device_id *id)
> > +{
> > +       struct bd71837 *bd71837;
> > +       struct bd71837_board *board_info;
> > +       int gpio_intr = 0;
> > +
> > +       const char *errstr = "No IRQ configured";
> > +       int ret = -EINVAL;
> > +
> > +       bd71837 = devm_kzalloc(&i2c->dev, sizeof(struct bd71837), GFP_KERNEL);
> > +
> > +       if (bd71837 == NULL)
> > +               return -ENOMEM;
> > +
> > +       board_info = dev_get_platdata(&i2c->dev);
> > +
> > +       if (!board_info)
> > +               gpio_intr = i2c->irq;
> > +       else
> > +               gpio_intr = board_info->gpio_intr;
> > +
> > +       if (!gpio_intr)
> > +               goto err_out;
> > +
> > +       i2c_set_clientdata(i2c, bd71837);
> > +       bd71837->dev = &i2c->dev;
> > +       bd71837->i2c_client = i2c;
> > +       bd71837->chip_irq = gpio_intr;
> > +
> > +       errstr = "regmap initialization failed";
> > +
> > +       bd71837->regmap = devm_regmap_init_i2c(i2c, &bd71837_regmap_config);
> > +       ret = PTR_ERR(bd71837->regmap);
> > +       if (IS_ERR(bd71837->regmap))
> > +               goto err_out;
> > +
> > +       errstr = "Read BD71837_REG_DEVICE failed";
> > +       ret = bd71837_reg_read(bd71837, BD71837_REG_REV);
> > +       if (ret < 0)
> > +               goto err_out;
> > +
> > +       errstr = "Failed to add irq_chip";
> > +       ret = devm_regmap_add_irq_chip(&i2c->dev, bd71837->regmap,
> > +                                      bd71837->chip_irq, IRQF_ONESHOT, 0,
> > +                                      &bd71837_irq_chip, &bd71837->irq_data);
> > +       if (ret < 0)
> > +               goto err_out;
> > +
> > +       errstr = "Failed to configure button short press timeout";
> > +       ret = regmap_update_bits(bd71837->regmap,
> > +                                BD71837_REG_PWRONCONFIG0,
> > +                                BD718XX_PWRBTN_PRESS_DURATION_MASK,
> > +                                BD718XX_PWRBTN_SHORT_PRESS_10MS);
> > +       if (ret < 0)
> > +               goto err_out;
> > +
> > +       /* According to BD71847 datasheet the HW default for long press
> > +        * detection is 10ms. So lets change it to 10 sec so we can actually
> > +        * get the short push and allow gracefull shut down
> > +        */
> > +       ret = regmap_update_bits(bd71837->regmap,
> > +                                BD71837_REG_PWRONCONFIG1,
> > +                                BD718XX_PWRBTN_PRESS_DURATION_MASK,
> > +                                BD718XX_PWRBTN_LONG_PRESS_10S);
> > +
> > +       errstr = "Failed to configure button long press timeout";
> > +       if (ret < 0)
> > +               goto err_out;
> > +
> > +       btns[0].irq = regmap_irq_get_virq(bd71837->irq_data,
> > +                                         BD71837_INT_PWRBTN_S);
> > +
> > +       errstr = "Failed to get the IRQ";
> > +       ret = btns[0].irq;
> > +       if (btns[0].irq < 0)
> > +               goto err_out;
> > +
> > +       errstr = "Failed to create subdevices";
> > +       ret = devm_mfd_add_devices(bd71837->dev, PLATFORM_DEVID_AUTO,
> > +                                  bd71837_mfd_cells,
> > +                                  ARRAY_SIZE(bd71837_mfd_cells), NULL, 0,
> > +                                  regmap_irq_get_domain(bd71837->irq_data));
> > +       if (ret) {
> > +err_out:
> > +               if (errstr)
> > +                       dev_err(&i2c->dev, "%s (%d)\n", errstr, ret);
> > +       }
> > +
> > +       return ret;
> > +}
> > 
> > What do you think of this? To my eye it is nice. It keeps single point of
> > exit and introduces only simple if-statements without the need of curly
> > brackets. And finally the error prints string works as a comment too.
> > I've seen bunch of constructs like this on the networking side but I
> > have no idea if this is frowned on this subsystem =) Oh, and probe abowe
> > is just to illustrate the idea, I did not even try compiling it yet.
> 
> That is horrible.  I nearly vomited on my keyboard. 

Note to self: Never to buy second hand keyboard from Lee =)

> It doesn't flow
> anywhere nearly as nicely has sorting out all of the error handling
> *after* it has been detected.  You're sacrificing readability to save
> a single line and do not save any *actual* lines of code, only a brace.

I was expecting something like this comment =) But the truth is that one
gets used to reading this quickly. Well, this still sounds like I should
not try convincing you - so you can stay heretic ;)
> 
> Landing a goto in the middle of a statement is messy and unsightly.

This is another thing one gets used to. I've actually seen plenty of
code using

	if (0) {
error_label:
	....
	}

for error handling. But again - you can keep your view and I'll adopt to
it here =)

> What happens when you have some resources to free?  The last few lines
> will become very messy, very quickly.

One can just build the usual clean-up sequence inside the last if (ret)
using different goto lables. Eg:

	if (ret) {
err_unwind_X:
		undo_x();
err_unwind_Y:
		undo_y();
err_out:
		dev_err(...);
	}
> 
> Nit: "something == NULL" is better written as "!something".

Oh, I personally liked the !foo more as Enric - but I will write the
NULL in case it won't make line too long. This is not a big deal to me.

> Nit: Please use proper multi-line comments as per the Coding Style.

Will do.

Thanks for quick reply! I will send new version today or tomorrow.

Best Regards
    Matti Vaittinen

WARNING: multiple messages have this Message-ID (diff)
From: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: "Enric Balletbo Serra" <eballetbo@gmail.com>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	"Mark Brown" <broonie@kernel.org>,
	"Matti Vaittinen" <mazziesaccount@gmail.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
	"Sebastian Reichel" <sre@kernel.org>,
	chenjh@rock-chips.com,
	"Andrey Smirnov" <andrew.smirnov@gmail.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Kate Stewart" <kstewart@linuxfoundation.org>,
	"Heiko Stübner" <heiko@sntech.de>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	sboyd@kernel.org, linux-clk@vger.kernel.org,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v8 1/2] mfd: bd71837: mfd driver for ROHM BD71837 PMIC
Date: Wed, 4 Jul 2018 13:34:30 +0300	[thread overview]
Message-ID: <20180704103430.GA13087@localhost.localdomain> (raw)
In-Reply-To: <20180704101102.GA496@dell>

On Wed, Jul 04, 2018 at 11:11:02AM +0100, Lee Jones wrote:
> On Wed, 04 Jul 2018, Matti Vaittinen wrote:
> 
> > On Wed, Jul 04, 2018 at 11:39:11AM +0300, Matti Vaittinen wrote:
> > > On Tue, Jul 03, 2018 at 11:26:00AM +0200, Enric Balletbo Serra wrote:
> > > > Missatge de Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> del
> > > > dia dv., 29 de juny 2018 a les 11:47:
> > > > 
> > > > Now that you use devm calls and you don't need to unwind things I
> > > > think is better to use plain returns. So,
> > > > 
> > > > return -ENOMEM;
> > > 
> > > I have never really understood why use of gotos in error handling is
> > > discouraged.
> 
> They're not.
> 
> > > Personally I would always choose single point of exit from
> > > a function when it is simple enough to achieve (like in this case). I've
> > > written and fixed way too many functions which leak resources or
> > > accidentally keep a lock when exiting from error branches. But I know
> > > many colleagues like you who prefer not to have gotos but  in place returns
> > > instead. So I guess I'll leave the final call on this to the one who is
> > > maintainer for this code. And it is true there is no things to unwind
> > > now - which does not mean that next updater won't add such. But as I
> > > said, I know plenty of people share your view - and even though I rather
> > > maintain code with only one exit the final call is on subsystem maintainer
> > > here.
> 
> Please use gotos in the error path.
> 
> IMO, it's the nicest way to unwind (as you call it).

I'll keep the gotos but clean other stuff for patch v9 then.
> 
> > Actually, If it was completely my call the probe would look something
> > like this:
> > 
> > +static int bd71837_i2c_probe(struct i2c_client *i2c,
> > +                           const struct i2c_device_id *id)
> > +{
> > +       struct bd71837 *bd71837;
> > +       struct bd71837_board *board_info;
> > +       int gpio_intr = 0;
> > +
> > +       const char *errstr = "No IRQ configured";
> > +       int ret = -EINVAL;
> > +
> > +       bd71837 = devm_kzalloc(&i2c->dev, sizeof(struct bd71837), GFP_KERNEL);
> > +
> > +       if (bd71837 == NULL)
> > +               return -ENOMEM;
> > +
> > +       board_info = dev_get_platdata(&i2c->dev);
> > +
> > +       if (!board_info)
> > +               gpio_intr = i2c->irq;
> > +       else
> > +               gpio_intr = board_info->gpio_intr;
> > +
> > +       if (!gpio_intr)
> > +               goto err_out;
> > +
> > +       i2c_set_clientdata(i2c, bd71837);
> > +       bd71837->dev = &i2c->dev;
> > +       bd71837->i2c_client = i2c;
> > +       bd71837->chip_irq = gpio_intr;
> > +
> > +       errstr = "regmap initialization failed";
> > +
> > +       bd71837->regmap = devm_regmap_init_i2c(i2c, &bd71837_regmap_config);
> > +       ret = PTR_ERR(bd71837->regmap);
> > +       if (IS_ERR(bd71837->regmap))
> > +               goto err_out;
> > +
> > +       errstr = "Read BD71837_REG_DEVICE failed";
> > +       ret = bd71837_reg_read(bd71837, BD71837_REG_REV);
> > +       if (ret < 0)
> > +               goto err_out;
> > +
> > +       errstr = "Failed to add irq_chip";
> > +       ret = devm_regmap_add_irq_chip(&i2c->dev, bd71837->regmap,
> > +                                      bd71837->chip_irq, IRQF_ONESHOT, 0,
> > +                                      &bd71837_irq_chip, &bd71837->irq_data);
> > +       if (ret < 0)
> > +               goto err_out;
> > +
> > +       errstr = "Failed to configure button short press timeout";
> > +       ret = regmap_update_bits(bd71837->regmap,
> > +                                BD71837_REG_PWRONCONFIG0,
> > +                                BD718XX_PWRBTN_PRESS_DURATION_MASK,
> > +                                BD718XX_PWRBTN_SHORT_PRESS_10MS);
> > +       if (ret < 0)
> > +               goto err_out;
> > +
> > +       /* According to BD71847 datasheet the HW default for long press
> > +        * detection is 10ms. So lets change it to 10 sec so we can actually
> > +        * get the short push and allow gracefull shut down
> > +        */
> > +       ret = regmap_update_bits(bd71837->regmap,
> > +                                BD71837_REG_PWRONCONFIG1,
> > +                                BD718XX_PWRBTN_PRESS_DURATION_MASK,
> > +                                BD718XX_PWRBTN_LONG_PRESS_10S);
> > +
> > +       errstr = "Failed to configure button long press timeout";
> > +       if (ret < 0)
> > +               goto err_out;
> > +
> > +       btns[0].irq = regmap_irq_get_virq(bd71837->irq_data,
> > +                                         BD71837_INT_PWRBTN_S);
> > +
> > +       errstr = "Failed to get the IRQ";
> > +       ret = btns[0].irq;
> > +       if (btns[0].irq < 0)
> > +               goto err_out;
> > +
> > +       errstr = "Failed to create subdevices";
> > +       ret = devm_mfd_add_devices(bd71837->dev, PLATFORM_DEVID_AUTO,
> > +                                  bd71837_mfd_cells,
> > +                                  ARRAY_SIZE(bd71837_mfd_cells), NULL, 0,
> > +                                  regmap_irq_get_domain(bd71837->irq_data));
> > +       if (ret) {
> > +err_out:
> > +               if (errstr)
> > +                       dev_err(&i2c->dev, "%s (%d)\n", errstr, ret);
> > +       }
> > +
> > +       return ret;
> > +}
> > 
> > What do you think of this? To my eye it is nice. It keeps single point of
> > exit and introduces only simple if-statements without the need of curly
> > brackets. And finally the error prints string works as a comment too.
> > I've seen bunch of constructs like this on the networking side but I
> > have no idea if this is frowned on this subsystem =) Oh, and probe abowe
> > is just to illustrate the idea, I did not even try compiling it yet.
> 
> That is horrible.  I nearly vomited on my keyboard. 

Note to self: Never to buy second hand keyboard from Lee =)

> It doesn't flow
> anywhere nearly as nicely has sorting out all of the error handling
> *after* it has been detected.  You're sacrificing readability to save
> a single line and do not save any *actual* lines of code, only a brace.

I was expecting something like this comment =) But the truth is that one
gets used to reading this quickly. Well, this still sounds like I should
not try convincing you - so you can stay heretic ;)
> 
> Landing a goto in the middle of a statement is messy and unsightly.

This is another thing one gets used to. I've actually seen plenty of
code using

	if (0) {
error_label:
	....
	}

for error handling. But again - you can keep your view and I'll adopt to
it here =)

> What happens when you have some resources to free?  The last few lines
> will become very messy, very quickly.

One can just build the usual clean-up sequence inside the last if (ret)
using different goto lables. Eg:

	if (ret) {
err_unwind_X:
		undo_x();
err_unwind_Y:
		undo_y();
err_out:
		dev_err(...);
	}
> 
> Nit: "something == NULL" is better written as "!something".

Oh, I personally liked the !foo more as Enric - but I will write the
NULL in case it won't make line too long. This is not a big deal to me.

> Nit: Please use proper multi-line comments as per the Coding Style.

Will do.

Thanks for quick reply! I will send new version today or tomorrow.

Best Regards
    Matti Vaittinen

  reply	other threads:[~2018-07-04 10:34 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-29  8:20 [PATCH v8 0/2] mfd/regulator/clk/input: bd71837: ROHM BD71837 PMIC driver Matti Vaittinen
2018-06-29  8:21 ` [PATCH v8 1/2] mfd: bd71837: mfd driver for ROHM BD71837 PMIC Matti Vaittinen
2018-07-03  9:26   ` Enric Balletbo Serra
2018-07-03  9:26     ` Enric Balletbo Serra
2018-07-04  8:39     ` Matti Vaittinen
2018-07-04  8:39       ` Matti Vaittinen
2018-07-04  9:52       ` Matti Vaittinen
2018-07-04  9:52         ` Matti Vaittinen
2018-07-04 10:11         ` Lee Jones
2018-07-04 10:11           ` Lee Jones
2018-07-04 10:34           ` Matti Vaittinen [this message]
2018-07-04 10:34             ` Matti Vaittinen
2018-07-04 10:53             ` Lee Jones
2018-07-04 10:53               ` Lee Jones
2018-06-29  8:23 ` [PATCH v8 2/2] mfd: bd71837: Devicetree bindings " Matti Vaittinen
2018-06-29  8:26   ` Matti Vaittinen

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=20180704103430.GA13087@localhost.localdomain \
    --to=matti.vaittinen@fi.rohmeurope.com \
    --cc=andrew.smirnov@gmail.com \
    --cc=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=chenjh@rock-chips.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=eballetbo@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.haikola@fi.rohmeurope.com \
    --cc=heiko@sntech.de \
    --cc=kstewart@linuxfoundation.org \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mazziesaccount@gmail.com \
    --cc=mikko.mutanen@fi.rohmeurope.com \
    --cc=mturquette@baylibre.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=sre@kernel.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.