Re: [PATCH 0/4] USB: ftdio_sio: GPIO validity fixes

From: Marc Zyngier
Date: Mon Dec 07 2020 - 09:42:03 EST


On 2020-12-07 14:01, Johan Hovold wrote:
On Fri, Dec 04, 2020 at 04:47:35PM +0000, Marc Zyngier wrote:
Having recently tried to use the CBUS GPIOs that come thanks to the
ftdio_sio driver, it occurred to me that the driver has a couple of
usability issues:

- it advertises potential GPIOs that are reserved to other uses (LED
control, or something else)

Consider the alternative, that the gpio offsets (for CBUS0, CBUS1, CBUS2
or CBUS4) varies depending on how the pins have been muxed. Hardly very
user friendly.

That's not what I suggest. If you want fixed GPIO offsets, fine by me.
But telling the user "these are GPIOs you can use", and then
"on second though, you can't" is not exactly consistent.

- it returns an odd error (-ENODEV), instead of the expected -EINVAL
when a line is unavailable, leading to a difficult diagnostic

Hmm, maybe. Several gpio driver return -ENODEV when trying to request
reserved pins. Even gpiolib returns -ENODEV when a pins is not yet
available due to probe deferal.

-ENODEV really means "no GPIOchip" in this context. The fact that
other drivers return -ENODEV for reserved pins looks like a bug to me.

-EBUSY could also be an alternative, but that's used to indicate that a
line is already in use as a gpio.

Or something else. Which is exactly the case, as it's been allocated
to another function.

We address the issues in a number of ways:

- Stop reporting invalid GPIO lines as valid to userspace. It
definitely seems odd to do so. Instead, report the line as being
used, making the userspace interface a bit more consistent.

- Implement the init_valid_mask() callback in the ftdi_sio driver,
allowing it to report which lines are actually valid.

- As suggested by Linus, give an indication to the user of why some of
the GPIO lines are unavailable, and point them to a useful tool
(once per boot). It is a bit sad that there next to no documentation
on how to use these CBUS pins.

Don't be sad, Marc; write some documentation. ;)

I sure will, right after I have fixed the rest of the kernel bugs
I have introduced. With a bit of luck, that's right after I finally
kick the bucket.

M.
--
Jazz is not dead. It just smells funny...