Re: [PATCH 0/2] FTDI CBUS GPIO support

[Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

On Sun, Jun 21, 2015 at 12:12:55AM +0200, Stefan Agner wrote:
> Yet another FTDI GPIO patchset. Yet somewhat different to previous
> implementations...
> 
> There are three GPIO modes supported by FTDI devices:
> 1. Asynchronous Bit Bang Mode (used in Sacha's patch)
> 2. Synchronous Bit Bang Mode (used in Philipp's patch)
> 3. CBUS Bit Bang Mode (used in Philipp's patch and this patchset)
> 
> Previous implementations:
> - Philipp Hachtmann (https://lkml.org/lkml/2014/5/31/181)
> - Sascha Silbe (https://lkml.org/lkml/2014/6/9/406)
> 
> The first two modes allow to control the serial pins and use the USB
> standard data transfer (write/read) to set the GPIO output values. Hence
> these modes interference with the standard serial mode of the devices,
> but are fast. The third option uses the USB control transfer to set
> GPIOs (which makes bit banging slower), and allows to control only 4
> pins. The controllable pins are predefined per device type (in FT232R
> CBUS0-3, in FT232H ACBUS5-9) and are not required for standard
> UART/serial communication. However, the default configuration is set to
> auxiliary functions such as TX/RXLED. Hence to make use of them in CBUS
> Bit Bang mode, the pins need to be reprogrammed to I/O mode first
> (EEPROM). All three modes are supported from userspace by libftdi afaik.

Is there a way to retrieve the settings from eeprom and only register
the gpio chip based on the configuration?

> In my use case I would like to use the additional GPIOs to control an
> embedded board (power off/reset etc.) and use the serial communication
> alongside. Using libftdi to use the CBUS Bit Bang mode is cumbersome,
> since libftdi requires to detach the kernel driver to get access to the
> device. The user needs then to reconnect the serial terminal every time
> a GPIO has been used. Hence, if any of these modes, I see most value in
> supporting the CBUS mode through the kernel's gpiolib API. However,
> since some functions are shared (e.g. set_bitmode to enable the
> different bit modes), this patchset is does some ground work for the
> other modes too, in case anybody wants to do further work on them.

I agree, the usb-serial driver should only provide access to the four
cbus pins if available (and use gpiolib).

> This patchset currently supports FT232R type of devices and has been
> tested using a FT232RL device. I think the FT232H (and probably later)
> types of devices should work too (at least the Table 3.5 in the FT232H
> data sheet mentions the ACBUS Signal Option "I/O mode"). However, I
> don't have such a device to test at my disposal.
> 
> On the implementation side, I created a distinct GPIO driver in
> drivers/gpio and create that platform device directly from within the
> ftdi_sio driver. I understand that the mfd subsystem would be the way to
> go, however it seems to me quite a big change... At least all USB device
> IDs would need to be moved to the mfd core device since the mfd device
> would be registered as a USB driver. I guess the ftdi_sio driver would
> become a platform device and still live under drivers/usb/serial/...?
> 
> I just saw that recent discussion by Grant and Linus did not approve
> this approach...?

Using the platform bus -- directly as you do or via MFD -- allows for
some (arguably contrived) abstraction but I think we should avoid it
nonetheless. USB (serial) does not use it as you already noted, and
there's not much to gain from creating a single-cell-mfd child device to
the USB interface.

Instead, hang the gpio chip directly off the usb interface (not the
port), add a new config option, and keep the gpio implementation under
drivers/usb/serial (possibly in its own file ftdi_sio-gpio.c).

Note that your current implementation fails to remove the gpio chip on
device disconnect, leaks resources in error paths, and lacks locking for
the gpio state.

Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in