mbox series

[v2,0/7] Add support for the other MaxLinear/Exar UARTs

Message ID cover.1616571453.git.mchehab+huawei@kernel.org (mailing list archive)
Headers show
Series Add support for the other MaxLinear/Exar UARTs | expand

Message

Mauro Carvalho Chehab March 24, 2021, 7:41 a.m. UTC
The current version of the xr_serial driver handles one one of the several
MaxLinear/Exar UARTs and UART bridges. There are currently 12 such
models. Only one is currently supported.

They were tested only on  XR21B1410 and  XR21B1424 models,
although I'm pretty much confident that the other models will also
work, as they're very close to either one of those.

Patch 1 is just a cleanup for the registers namespace. It removes
the model number from registers that are used on multiple versions
of the chipset.

Patch 2 adds a table to be used to map the register for each specific
variant of this chipset;

Patch 3 adds support for XR21B1412 and XR21B1414. The only
difference on those devices is that they support multiple UART ports.

Patch 4 adds support for  XR21B142X, which uses a mix of data and
control interfaces to setup the line discipline.

Patch 5 adds support for  XR21B1410 variant. This one is identical
to  XR21B1411, except that it uses a different register set;

Patch 6 adds support for XR2280X devices:
	https://www.maxlinear.com/product/interface/bridges/usb-ethernet-bridges/xr22800

Such devices are compound devices that are similar to the USB
UARTs from programming PoV. The only difference is the register
set.

Patch 7 updates the CDC ignore list.

After this series, all MaxLinear USB UARTs described at:
	https://www.maxlinear.com/products/interface/uarts/usb-uarts

Should be supported, except for XR21B1421. This one have just a control
interface, and uses standard HID protocol. No idea how to support it. Also,
I don't have such device to test ;-)

In order to write this patch series, I used the datasheets, plus the Linux
driver source code, available at MaxLinear, and a previous port made by
Patong Yang:

   https://lore.kernel.org/linux-usb/20180404070634.nhspvmxcjwfgjkcv@advantechmxl-desktop

---
v2:
  - rebased on the top of next-20210323;
  - free port_priv before calling usb_set_serial_data.

Mauro Carvalho Chehab (7):
  USB: serial: xr: simplify its namespace
  USB: serial: xr: use a table for device-specific settings
  USB: serial: xr: add support for multi-port XR21V141X variants
  USB: serial: xr: add support for XR21B142X devices
  USB: serial: xr: add support for XR21B1411
  USB: serial: xr: add support for XR2280X devices
  USB: cdc-acm: add other non-standard xr_serial models to ignore list

 drivers/usb/class/cdc-acm.c    |  17 +-
 drivers/usb/serial/xr_serial.c | 694 +++++++++++++++++++++++++--------
 2 files changed, 556 insertions(+), 155 deletions(-)

Comments

Johan Hovold March 30, 2021, 2:35 p.m. UTC | #1
On Wed, Mar 24, 2021 at 08:41:04AM +0100, Mauro Carvalho Chehab wrote:
> The current version of the xr_serial driver handles one one of the several
> MaxLinear/Exar UARTs and UART bridges. There are currently 12 such
> models. Only one is currently supported.

As I mentioned earlier, proper handling of the CDC devices requires
support in USB serial core, which I've now implemented.

With that and by parsing the Union descriptor to determine the interface
layout, probing can also be cleaned up quite a bit.

Looking at this series I found a few things that have been overlooked,
such as the device types having different register widths (and one even
differing register address widths), the custom driver flag not being set
and a memory leak. I'll comment on some of these separately.

It also seems the type abstraction can be handled better by using a
more structured approach, which also allows getting rid of some of the
type conditionals spread throughout the code.

Another key observation here is that it's the currently supported type
which is the one that stands out from the rest. And while all four types
supports CDC requests, it's only the SET_LINE_CODING one which is
actually required to be used (by the three new types). This also allows
for a cleaner implementation.

I ended up implementing support myself in order to make sense of all the
ways these device types differ while digging through the datasheets and
thinking about how best to implement this.

I'll be posting a fix and two series while keeping you on CC. Would you
mind giving it a spin with your XR21B142X?

Johan