On Thu, Apr 05, 2018 at 08:42:57PM -0700, Patong Yang wrote: > On Wed, Apr 4, 2018 at 11:26 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > 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? > > Sorry, I am a kernel newbie and was not aware of the GPIO support. I found > and read through the documentation. It's unclear to me how to map the > GPIOs of the USB UART so that I can access them using the APIs. That is up to you to figure out how that works for your device. > Can someone point me to an example of how that can be done? Would the > support be added in the xrusb_serial driver or in a separate driver? Probably in this driver, but look around at the current examples in the kernel for other ideas. > I also went through the documentation for the standard API for RS485 > support. I can use the standard IOCTLs for enabling RS485 half-duplex > control with the RTS pin. However, is there a way to specify a > different pin? Some of the Exar USB UARTs can use a different pin for > that function. Why would they want to use a different pin? Anyway, propose a standard tty ioctl for that and we can take it from there. > There is a custom IOCTL for enabling the "wide mode" feature in the Exar > USB UARTs that inserts an additional byte in the RX FIFO that reports > the parity, framing, parity and break error status for every data byte > received. This is the equivalent of reading LSR and RHR in 16550 > UARTs, and is useful for multidrop/9-bit mode applications. I don't > think any other USB UART has this function so there's no standard > IOCTL for it. Can I use a custom IOCTL for this or is there a better > approach? Isn't there already an option for that for other UARTs that do this? > Also, as I mentioned in my original patch submission, the driver checks for > a port_config file at startup and loads the appropriate settings. The > driver was creating the port_config file in the /etc/ directory when > some of the custom IOCTLs were called to store the settings for the > next time that the driver was loaded. Without the custom IOCTLs, I > was thinking that the user would just create those files in the /etc/ > directory if they wanted the driver to load/store the port > configurations. Do you see any issues with doing that? No Linux kernel driver can ever read a file from a disk. That's not how Linux works at all, sorry. Configuration comes from userspace programs when they want to configure things, not when the kernel finds a device. The kernel does notify userspace when devices are found, so you can run your program at that point in time. Hope this helps, 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
