Andy Shevchenko wrote: > As I read this I think of the pins used as GPIOs. Viewing my repurposed DTR & RTS outputs as GPIOs is a valid way to look at them. The target application has one 8-wire UART, a secondary 2-wire UART, and two GPIO (really GPO, output-only) controls. Because no major USB-to-X chip vendor makes a chip that goes from one USB to this combination of two UARTs plus GPIO (there are some that may seem to qualify at first glance, such as CP2105, but that one and others I know of have other issues that preclude their use), I took the next most practical route: I used FT2232D, and repurposed its otherwise unused Channel B DTR & RTS outputs to be GPOs. > So, sounds like what > we need instead is to list the pins that are used for (dedicated) > GPIOs and pass this information to serial mctrl layer and perhaps > prepare that layer to handle exclusions like these. What you are describing would be quite easy to implement for *my* device, and the implementation would be entirely contained in the ftdi_sio driver. My particular FTDI chip (FT2232D) doesn't have any pins that are officially regarded as GPIOs, but other FTDI chips do (single-channel FT232H, FT232R and FT-X), and Linux ftdi_sio driver already has support for presenting FT232H/R/FT-X CBUS pins to gpiolib as a gpio_chip. It would be fairly easy to implement a second kind of gpio_chip within ftdi_sio, made out of an otherwise-serial channel's DTR and RTS outputs - but here is the big BUT: I don't know how to conditionalize enabling of this special mode (stealing DTR & RTS from the ttyUSBx device and handing them over to gpiolib control instead) other than by keying on specific USB VID:PID codes. The latter approach would work great for my application, but I keep being told that the solution must work for "everyone", whatever that global specifier could mean in this context. However, this idea of moving an FTDI device's DTR & RTS outputs to gpiolib control at the ftdi_sio driver level will not help anyone who has an old-fashioned RS-232 (not USB-serial) device in which DTR and/or RTS have been repurposed in a way that does not tolerate automatic unconditional assertion of these signals on open. I don't know whether or not any such devices exist: there aren't any in _my_ world, but I keep being told to think generically, outside of my own repertoire of use cases. At this point I need to ask the maintainers with decision-making powers: which approach would be more acceptable? The two approaches which I see as feasible are: Option 1: implement a special mode for all serial ports, both "hard" and USB-serial, that suppresses automatic assertion of DTR & RTS on open - but allows them to be controlled with TIOCMBIS and TIOCMBIC. Yes, the signals are really GPIOs in this case, but just how would one go about turning UART signals into true Linux GPIOs on any arbitrary serial port, whenever an end user decides to connect a particular RS-232 device that needs special handling? Option 2: implement a VID:PID-keyed solution in the ftdi_sio driver, stealing DTR & RTS completely from the tty device and handing them over to gpiolib control. This solution would work for my specific USB device, and if anyone else builds anything similar, they could reuse the same ftdi_sio driver quirk - but this solution provides no help at all to RS-232 tinkerers, if any exist. M~
