On Wed, Apr 04, 2018 at 12:03:51PM -0700, Patong Yang wrote: > Thanks for the quick reply and feedback. This needs to be a different > driver because although the USB UARTs can work with the CDC-ACM driver, > there are limitations in the CDC-ACM spec and therefore the driver that > prevents it from fully functioning as a standard serial port (ie. status of > CTS pin, ability to enable/disable flow control). Therefore, the USB UARTs > also support custom USB Vendor requests so that it can behave as a standard > serial port and support other device features such as GPIO control and the > automatic direction control feature typically used in RS-485 and RS-422 > designs. The GPIO stuff needs to be a separate interface, using the kernel's GPIO api, not custom ioctls. > The USB device can describe itself properly. The SMBIOS function is a > requirement from our customer who designed a board using our device where > their CPU reads from a specific BIOS location and initializes GPIOs based > on the settings. These GPIOs set the mode of the transceiver (LOOPBACK, > RS232, RS485, or RS422). Therefore, the driver also reads the same > settings from the BIOS, so that it can enable the appropriate mode. That logic can be done in userspace, no need to do that within the kernel, right? > This same customer is designing a new board to support the same transceiver > configurations. Instead of using the BIOS settings, they would like to use > a user-space application to configure the additional GPIOs in a newer USB > UART to set the transceiver modes, however, there are no standard APIs to > support setting different modes, hence the custom IOCTLs. What is wrong with the current GPIO Linux api? Doesn't that support everything you need here? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
