On 2020-12-07 14:29, Johan Hovold wrote:
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@xxxxxxxxxx>
Signed-off-by: Marc Zyngier <maz@xxxxxxxxxx>
---
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.
Fine by me, this patch can be dropped without issue. After all,
I now know how to deal with these chips.
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.
That was Linus' initial suggestion. But I think a consistent user
API is more important than free advise in the kernel log.
Thanks,
M.
--
Jazz is not dead. It just smells funny...