All of lore.kernel.org
 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 3/4] USB: serial: ftdi_sio: Log the CBUS GPIO validity
Date: Mon, 7 Dec 2020 15:29:01 +0100	[thread overview]
Message-ID: <X848LXNv3GRmmSXA@localhost> (raw)
In-Reply-To: <20201204164739.781812-4-maz@kernel.org>

On Fri, Dec 04, 2020 at 04:47:38PM +0000, Marc Zyngier wrote:
> The validity of the ftdi CBUS GPIO is pretty hidden so far,
> and finding out *why* some GPIOs don't work is sometimes
> hard to identify. So let's help the user by displaying the
> map of the CBUS pins that are valid for a GPIO.
> 
> Also, tell the user about the magic ftx-prog tool that can
> make GPIOs appear: https://github.com/richardeoin/ftx-prog
> 
> Suggested-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
>  drivers/usb/serial/ftdi_sio.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
> index 13e575f16bcd..b9d3b33891fc 100644
> --- a/drivers/usb/serial/ftdi_sio.c
> +++ b/drivers/usb/serial/ftdi_sio.c
> @@ -2012,6 +2012,15 @@ static int ftdi_gpio_init_valid_mask(struct gpio_chip *gc,
>  
>  	bitmap_complement(valid_mask, &map, ngpios);
>  
> +	if (bitmap_empty(valid_mask, ngpios))
> +		dev_warn(&port->dev, "No usable GPIO\n");

This isn't an error of any kind, and certainly not something that
deserves a warning in the system log on every probe. Not everyone cares
about the GPIO interface.

> +	else
> +		dev_info(&port->dev, "Enabling CBUS%*pbl for GPIO\n",
> +			 ngpios, valid_mask);

And while printing this mask has some worth I'm still reluctant to be
spamming the logs with it. Just like gpolib has a dev_dbg() for
registering chips, this should probably be demoted to KERN_DEBUG as
well.

> +
> +	if (!bitmap_full(valid_mask, ngpios))
> +		dev_warn_once(&port->dev, "Consider using a tool such as ftx-prog to enable GPIOs if required\n");
> +

And again, this is not something that belongs in the logs of just about
every system with an attached ftdi device.

While not possible to combine with the valid_mask approach, this is
something which we could otherwise add to the request() callback for the
first request that fails due to the mux configuration.

>  	return 0;
>  }

Johan

  reply	other threads:[~2020-12-07 14:29 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
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 [this message]
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=X848LXNv3GRmmSXA@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 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.