Driver for MaxLinear/Exar USB (UART) Serial adapters.

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

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@linuxfoundation.org> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html