linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Johan Hovold <johan@kernel.org>, linux-usb@vger.kernel.org
Subject: Re: [PATCH] USB: serial: ftdi_sio: Helpful error on GPIO attempt
Date: Tue, 01 Dec 2020 15:01:11 +0000	[thread overview]
Message-ID: <43d788c69a0f4fe3caf578b98ae72395@kernel.org> (raw)
In-Reply-To: <20201201141048.1461042-1-linus.walleij@linaro.org>

Hi Linus,

On 2020-12-01 14:10, Linus Walleij wrote:
> The FTDI adapters present all potentially available GPIO
> lines to userspace, and they are often also visibly
> available on things like breakout boards. These are
> appetizing targets for random GPIO tinkering such as
> bit-banging or other industrial control over USB.
> 
> When a user attempts to use one of the GPIO lines, they
> can get the opaque error -ENODEV, because the flashed
> configuration says that the line is not in GPIO mode
> but another alternative function.
> 
> We had one user run into this, debug and finally fix the
> problem using ftx-prog.

Well, you gave me 2/3 of the solution ;-). How about adding
a pointer to this tool? [1]

> 
> Give the user some more helpful dmesg text and a pointer
> to ftx-prog when the error occurs.
> 
> Reported-by: Marc Zyngier <maz@kernel.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
>  drivers/usb/serial/ftdi_sio.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/serial/ftdi_sio.c 
> b/drivers/usb/serial/ftdi_sio.c
> index e0f4c3d9649c..405fec78f2fc 100644
> --- a/drivers/usb/serial/ftdi_sio.c
> +++ b/drivers/usb/serial/ftdi_sio.c
> @@ -1841,8 +1841,11 @@ static int ftdi_gpio_request(struct gpio_chip
> *gc, unsigned int offset)
>  	struct ftdi_private *priv = usb_get_serial_port_data(port);
>  	int result;
> 
> -	if (priv->gpio_altfunc & BIT(offset))
> +	if (priv->gpio_altfunc & BIT(offset)) {
> +		dev_err(&port->dev, "FTDI firmware says line is not in GPIO 
> mode\n");
> +		dev_err(&port->dev, "if you really know what you're doing the flash
> can be reconfigured using ftx-prog\n");
>  		return -ENODEV;
> +	}
> 
>  	mutex_lock(&priv->gpio_lock);
>  	if (!priv->gpio_used) {

It occurs to me that since the driver already knows which of the CBUS
pins are unusable, we should maybe find a way to expose the line as
"reserved", one way or another? Generic tools such as gpioinfo would
(or should?) be able to display the status of the pin to the user.

enum gpio_v2_line_flag doesn't have a "reserved" flag, so maybe
GPIO_V2_LINE_FLAG_USED is an adequate way to mark the line as
being unavailable for userspace?

Thanks,

         M.

[1] https://github.com/richardeoin/ftx-prog
-- 
Jazz is not dead. It just smells funny...

  reply	other threads:[~2020-12-01 15:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-01 14:10 [PATCH] USB: serial: ftdi_sio: Helpful error on GPIO attempt Linus Walleij
2020-12-01 15:01 ` Marc Zyngier [this message]
2020-12-02 18:13   ` Marc Zyngier
2020-12-08  8:39     ` Linus Walleij
2020-12-08  9:02       ` 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=43d788c69a0f4fe3caf578b98ae72395@kernel.org \
    --to=maz@kernel.org \
    --cc=johan@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-usb@vger.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).