LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Doug Berger <opendmb@gmail.com>
To: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Gregory Fong <gregory.0xf0@gmail.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	bcm-kernel-feedback-list@broadcom.com,
	linux-gpio <linux-gpio@vger.kernel.org>,
	arm-soc <linux-arm-kernel@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V2] gpio: brcmstb: support gpio-line-names property
Date: Wed, 11 Mar 2020 12:02:54 -0700	[thread overview]
Message-ID: <7fcc5cb2-5fdb-d1cf-e55b-c0f2d407e072@gmail.com> (raw)
In-Reply-To: <CAMpxmJXNQQTxRWZSP0RZTUuefAk3+AeDMVeVkgERy7f9X=CBsA@mail.gmail.com>

On 3/11/20 5:44 AM, Bartosz Golaszewski wrote:
> pon., 9 mar 2020 o 20:02 Doug Berger <opendmb@gmail.com> napisał(a):
>>
>> The default handling of the gpio-line-names property by the
>> gpiolib-of implementation does not work with the multiple
>> gpiochip banks per device structure used by the gpio-brcmstb
>> driver.
>>
>> This commit adds driver level support for the device tree
>> property so that GPIO lines can be assigned friendly names.
>>
>> Signed-off-by: Doug Berger <opendmb@gmail.com>
>> ---
>>  drivers/gpio/gpio-brcmstb.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 44 insertions(+)
>>
>> diff --git a/drivers/gpio/gpio-brcmstb.c b/drivers/gpio/gpio-brcmstb.c
>> index 05e3f99ae59c..fcfc1a1f1a5c 100644
>> --- a/drivers/gpio/gpio-brcmstb.c
>> +++ b/drivers/gpio/gpio-brcmstb.c
>> @@ -603,6 +603,49 @@ static const struct dev_pm_ops brcmstb_gpio_pm_ops = {
>>         .resume_noirq = brcmstb_gpio_resume,
>>  };
>>
>> +static void brcmstb_gpio_set_names(struct device *dev,
>> +                                  struct brcmstb_gpio_bank *bank)
>> +{
>> +       struct device_node *np = dev->of_node;
>> +       const char **names;
>> +       int nstrings, base;
>> +       unsigned int i;
>> +
>> +       base = bank->id * MAX_GPIO_PER_BANK;
>> +
>> +       nstrings = of_property_count_strings(np, "gpio-line-names");
>> +       if (nstrings <= base)
>> +               /* Line names not present */
>> +               return;
>> +
>> +       names = devm_kcalloc(dev, MAX_GPIO_PER_BANK, sizeof(*names),
>> +                            GFP_KERNEL);
>> +       if (!names)
>> +               return;
>> +
>> +       /*
>> +        * Make sure to not index beyond the end of the number of descriptors
>> +        * of the GPIO device.
>> +        */
>> +       for (i = 0; i < bank->width; i++) {
>> +               const char *name;
>> +               int ret;
>> +
>> +               ret = of_property_read_string_index(np, "gpio-line-names",
>> +                                                   base + i, &name);
>> +               if (ret) {
>> +                       if (ret != -ENODATA)
>> +                               dev_err(dev, "unable to name line %d: %d\n",
>> +                                       base + i, ret);
>> +                       break;
>> +               }
> 
> This bit is confusing to me. If we can't read the property we break
> the loop and leave the remaining line names null but at the same time
> it isn't considered a probe failure? Would you mind at least
> commenting on this in the code?
> 
> Bart
> 
The label names are viewed as a convenience for the user and are not
necessary for the proper functionality of the driver and device, so we
don't want to prevent the driver from succeeding at probe due to an
error in the gpio-line-names property. The bank->gc.names member is
still made non-NULL which is what we really care about to prevent the
misapplication of label names by devprop_gpiochip_set_names().

In fact, it is expected that the device-tree will only include label
strings up to the last GPIO of interest so the ENODATA error is
considered a valid result to terminate any further labeling so there is
no need for an error message in that case.

Other error results are unexpected so an error message indicating the
consequence of the error is appropriate here.

I'm not sure which aspect is confusing to you, so it's not clear to me
how best to comment the code. I can hazard a guess, but if you have a
suggestion I'm happy to submit a v3.

Thanks for taking the time to review this,
    Doug

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

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-09 19:02 Doug Berger
2020-03-09 20:01 ` Gregory Fong
2020-03-11 12:44 ` Bartosz Golaszewski
2020-03-11 19:02   ` Doug Berger [this message]
2020-03-12  8:22     ` Bartosz Golaszewski
2020-03-11 15:32 ` Linus Walleij
2020-03-11 18:38   ` Doug Berger
2020-03-11 20:59 ` Florian Fainelli
2020-03-25 23:01 ` Linus Walleij

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=7fcc5cb2-5fdb-d1cf-e55b-c0f2d407e072@gmail.com \
    --to=opendmb@gmail.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=f.fainelli@gmail.com \
    --cc=gregory.0xf0@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: [PATCH V2] gpio: brcmstb: support gpio-line-names property' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).