All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gregory Fong <gregory.0xf0@gmail.com>
To: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Cc: linux-gpio@vger.kernel.org, linus.walleij@linaro.org,
	bgolaszewski@baylibre.com, f.fainelli@gmail.com,
	matthias.bgg@gmail.com, opensource@vdorst.com,
	andy.shevchenko@gmail.com, git@johnthomson.fastmail.com.au,
	neil@brown.name, hofrat@osadl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] gpiolib: convert 'devprop_gpiochip_set_names' to support multiple gpiochip baks per device
Date: Mon, 19 Jul 2021 00:57:23 -0700	[thread overview]
Message-ID: <20210719075723.GA8818@kessel> (raw)
In-Reply-To: <20210708070429.31871-2-sergio.paracuellos@gmail.com>

Hi Sergio,

On Thu, Jul 08, 2021 at 09:04:27AM +0200, Sergio Paracuellos wrote:
> The default gpiolib-of implementation does not work with the multiple
> gpiochip banks per device structure used for example by the gpio-mt7621
> and gpio-brcmstb drivers. To fix these kind of situations driver code
> is forced to fill the names to avoid the gpiolib code to set names
> repeated along the banks. Instead of continue with that antipattern
> fix the gpiolib core function to get expected behaviour for every
> single situation adding a field 'offset' in the gpiochip structure.
> Doing in this way, we can assume this offset will be zero for normal
> driver code where only one gpiochip bank per device is used but
> can be set explicitly in those drivers that really need more than
> one gpiochip.

This is a nice improvement, thanks for putting this together!  A few
remarks below:

> 
> Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
> ---
>  drivers/gpio/gpiolib.c      | 34 ++++++++++++++++++++++++++++------
>  include/linux/gpio/driver.h |  4 ++++
>  2 files changed, 32 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 27c07108496d..f3f45b804542 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -382,11 +382,16 @@ static int devprop_gpiochip_set_names(struct gpio_chip *chip)
>  	if (count < 0)
>  		return 0;
>  
> -	if (count > gdev->ngpio) {
> -		dev_warn(&gdev->dev, "gpio-line-names is length %d but should be at most length %d",
> -			 count, gdev->ngpio);
> -		count = gdev->ngpio;
> -	}
> +	/*
> +	 * When offset is set in the driver side we assume the driver internally
> +	 * is using more than one gpiochip per the same device. We have to stop
> +	 * setting friendly names if the specified ones with 'gpio-line-names'
> +	 * are less than the offset in the device itself. This means all the
> +	 * lines are not present for every single pin within all the internal
> +	 * gpiochips.
> +	 */
> +	if (count <= chip->offset)
> +		return 0;

This case needs a descriptive warning message.  Silent failure to assign
names here will leave someone confused about what they're doing wrong.

>  
>  	names = kcalloc(count, sizeof(*names), GFP_KERNEL);
>  	if (!names)
> @@ -400,8 +405,25 @@ static int devprop_gpiochip_set_names(struct gpio_chip *chip)
>  		return ret;
>  	}
>  
> +	/*
> +	 * When more that one gpiochip per device is used, 'count' can
> +	 * contain at most number gpiochips x chip->ngpio. We have to
> +	 * correctly distribute all defined lines taking into account
> +	 * chip->offset as starting point from where we will assign
> +	 * the names to pins from the 'names' array. Since property
> +	 * 'gpio-line-names' cannot contains gaps, we have to be sure
> +	 * we only assign those pins that really exists since chip->ngpio
> +	 * can be different of the chip->offset.
> +	 */
> +	count = (count > chip->offset) ? count - chip->offset : count;
> +	if (count > chip->ngpio) {

In the multiple gpiochip case, if there are 3+ gpiochips this seems like
it will yield an invalid warning. For example, if there are 3 gpiochips
(banks 0, 1, and 2), and all gpios are given names in gpio-line-names,
isn't this condition going to always evaluate to true for bank 1,
resulting in an invalid warning?  In that case I would think setting
count to chip->ngpio is the *expected* behavior.

Since that's a "normal" behavior in the multiple gpiochip case, I'm not
sure there's a simple way to detect an over-long gpio-line-names here
in this function anymore.

> +		dev_warn(&gdev->dev, "gpio-line-names is length %d but
> should be at most length %d", +			 count,
> chip->ngpio);
> +		count = chip->ngpio; +	} + for (i = 0; i < count; i++)
> -		gdev->descs[i].name = names[i]; +
> gdev->descs[i].name = names[chip->offset + i];
>  
>  	kfree(names);
>  
> [snip]

Best regards,
Gregory

  reply	other threads:[~2021-07-19  7:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-08  7:04 [PATCH 0/3] gpiolib: convert 'devprop_gpiochip_set_names' to support multiple gpiochip per device Sergio Paracuellos
2021-07-08  7:04 ` [PATCH 1/3] gpiolib: convert 'devprop_gpiochip_set_names' to support multiple gpiochip baks " Sergio Paracuellos
2021-07-19  7:57   ` Gregory Fong [this message]
2021-07-19  8:31     ` Sergio Paracuellos
2021-07-27  7:39       ` Gregory Fong
2021-07-27 11:42         ` Sergio Paracuellos
2021-07-08  7:04 ` [PATCH 2/3] gpio: mt7621: support gpio-line-names property Sergio Paracuellos
2021-07-08  7:04 ` [PATCH 3/3] gpio: brcmstb: remove custom 'brcmstb_gpio_set_names' Sergio Paracuellos
2021-07-19  7:59   ` Gregory Fong
2021-07-08  8:02 ` [PATCH 0/3] gpiolib: convert 'devprop_gpiochip_set_names' to support multiple gpiochip per device Andy Shevchenko
2021-07-08  8:40   ` Sergio Paracuellos
2021-07-27  6:02 ` Sergio Paracuellos
2021-07-27 11:35   ` Bartosz Golaszewski
2021-07-27 11:40     ` Sergio Paracuellos

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=20210719075723.GA8818@kessel \
    --to=gregory.0xf0@gmail.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=f.fainelli@gmail.com \
    --cc=git@johnthomson.fastmail.com.au \
    --cc=hofrat@osadl.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=neil@brown.name \
    --cc=opensource@vdorst.com \
    --cc=sergio.paracuellos@gmail.com \
    /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.