archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <>
To: Patong Yang <>
Subject: Driver for MaxLinear/Exar USB (UART) Serial adapters.
Date: Fri, 6 Apr 2018 16:45:24 +0200	[thread overview]
Message-ID: <> (raw)

On Thu, Apr 05, 2018 at 08:42:57PM -0700, Patong Yang wrote:
> On Wed, Apr 4, 2018 at 11:26 PM, Greg KH <> 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
> > > 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
More majordomo info at

             reply	other threads:[~2018-04-06 14:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-06 14:45 Greg Kroah-Hartman [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-08-16 10:05 Driver for MaxLinear/Exar USB (UART) Serial Adapters Greg Kroah-Hartman
2018-08-16  8:28 Patong Yang
2018-08-16  8:26 Oliver Neukum
2018-08-16  6:34 Greg Kroah-Hartman
2018-08-16  5:56 Patong Yang
2018-07-26 10:57 Greg Kroah-Hartman
2018-07-25  7:38 Oliver Neukum
2018-07-24 22:36 Patong Yang
2018-04-05  7:38 Driver for MaxLinear/Exar USB (UART) Serial adapters Oliver Neukum
2018-04-05  6:26 Greg Kroah-Hartman
2018-04-04  8:00 Greg Kroah-Hartman
2018-04-04  7:59 Greg Kroah-Hartman
2018-04-04  7:38 Oliver Neukum
2018-04-04  7:06 Patong Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).