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.
Give the user some more helpful dmesg text and a pointer
to ftx-prog when the error occurs.
Reported-by: Marc Zyngier <maz@xxxxxxxxxx>
Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxx>
---
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) {
--
2.26.2
