linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Marc Zyngier <maz@kernel.org>
Cc: linux-usb@vger.kernel.org, linux-gpio@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Johan Hovold <johan@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	kernel-team@android.com
Subject: Re: [PATCH 1/4] gpiolib: cdev: Flag invalid GPIOs as used
Date: Mon, 7 Dec 2020 15:16:50 +0100	[thread overview]
Message-ID: <X845UohmzGM7+FPu@localhost> (raw)
In-Reply-To: <20201204164739.781812-2-maz@kernel.org>

On Fri, Dec 04, 2020 at 04:47:36PM +0000, Marc Zyngier wrote:
> When reporting the state of a GPIO to userspace, we never check
> for the actual validity of the line, meaning we report invalid
> lines as being usable. A subsequent request will fail though,
> which is an inconsistent behaviour from a userspace perspective.
> 
> Instead, let's check for the validity of the line and report it
> as used if it is invalid. This allows a tool such as gpioinfo
> to report something sensible:
> 
> gpiochip3 - 4 lines:
> 	line   0:      unnamed       unused   input  active-high
> 	line   1:      unnamed       kernel   input  active-high [used]
> 	line   2:      unnamed       kernel   input  active-high [used]
> 	line   3:      unnamed       unused   input  active-high
> 
> In this example, lines 1 and 2 are invalid, and cannot be used by
> userspace.
> 
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
>  drivers/gpio/gpiolib-cdev.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
> index e9faeaf65d14..a0fcb4ccaa02 100644
> --- a/drivers/gpio/gpiolib-cdev.c
> +++ b/drivers/gpio/gpiolib-cdev.c
> @@ -1910,6 +1910,7 @@ static void gpio_desc_to_lineinfo(struct gpio_desc *desc,
>  	    test_bit(FLAG_USED_AS_IRQ, &desc->flags) ||
>  	    test_bit(FLAG_EXPORT, &desc->flags) ||
>  	    test_bit(FLAG_SYSFS, &desc->flags) ||
> +	    !gpiochip_line_is_valid(gc, info->offset) ||
>  	    !ok_for_pinctrl)
>  		info->flags |= GPIO_V2_LINE_FLAG_USED;

So this is somewhat separate from the rest of the series in case it
applies also to gpio chips with reserved ranges (e.g.
"gpio-reserved-ranges" devicetree property). Are they currently reported
as available?

Looks like this will work well also for USB gpio controllers with static
muxing configured in EEPROM, especially as that is how we already report
pins reported as unavailable by pinctrl (i.e. ok_for_pinctrl).

Johan

  reply	other threads:[~2020-12-07 14:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-04 16:47 [PATCH 0/4] USB: ftdio_sio: GPIO validity fixes Marc Zyngier
2020-12-04 16:47 ` [PATCH 1/4] gpiolib: cdev: Flag invalid GPIOs as used Marc Zyngier
2020-12-07 14:16   ` Johan Hovold [this message]
2020-12-07 14:59     ` Marc Zyngier
2020-12-09  9:25   ` Linus Walleij
2020-12-04 16:47 ` [PATCH 2/4] USB: serial: ftdi_sio: Report the valid GPIO lines to gpiolib Marc Zyngier
2020-12-09  9:28   ` Linus Walleij
2020-12-04 16:47 ` [PATCH 3/4] USB: serial: ftdi_sio: Log the CBUS GPIO validity Marc Zyngier
2020-12-07 14:29   ` Johan Hovold
2020-12-07 15:00     ` Marc Zyngier
2020-12-07 15:19       ` Johan Hovold
2020-12-09  9:35         ` Linus Walleij
2020-12-09 17:05           ` Johan Hovold
2020-12-09 17:39             ` Johan Hovold
2020-12-04 16:47 ` [PATCH 4/4] USB: serial: ftdi_sio: Drop GPIO line checking dead code Marc Zyngier
2020-12-07  9:55 ` [PATCH 0/4] USB: ftdio_sio: GPIO validity fixes Andy Shevchenko
2020-12-07 14:01 ` Johan Hovold
2020-12-07 14:41   ` Marc Zyngier
2020-12-07 15:08     ` Johan Hovold
2020-12-07 15:34       ` Marc Zyngier
2020-12-07 15:49         ` Johan Hovold
2020-12-09  9:20           ` Linus Walleij
2020-12-09 15:42             ` Johan Hovold

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=X845UohmzGM7+FPu@localhost \
    --to=johan@kernel.org \
    --cc=bgolaszewski@baylibre.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-team@android.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=maz@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 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).