linux-kernel - Re: [PATCH v2 0/7] Add support for the other MaxLinear/Exar UARTs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YGM3KqV7t6wblXYM@hovoldconsulting.com>
Date:   Tue, 30 Mar 2021 16:35:22 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Oliver Neukum <oneukum@...e.com>, linux-kernel@...r.kernel.org,
        linux-usb@...r.kernel.org
Subject: Re: [PATCH v2 0/7] Add support for the other MaxLinear/Exar UARTs

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