linux-kernel - Re: serial: New xr20m117x driver questions

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <Yy6qOmuuzIffRQGC@kroah.com>
Date:   Sat, 24 Sep 2022 08:56:58 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Jeff Harris <jefftharris@...il.com>
Cc:     Jiri Slaby <jirislaby@...nel.org>, linux-serial@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: serial: New xr20m117x driver questions

On Fri, Sep 23, 2022 at 11:29:52AM -0400, Jeff Harris wrote:
> I have a driver for the MaxLinear XR20M117x family of UARTs that I'd like
> to contribute but have a couple questions.  The driver is heavily based on
> the existing sc16is7xx driver.  The driver started with the sample driver
> from MaxLinear for Linux 3.x.x, but as the integration of their driver
> proceeded into our 4.4 kernel, there were features and fixes missing that
> were present in the current sc16is7xx driver.
> 
> The register set is similar, but there are a few places where the behavior
> is different.  Would it be best to create a new driver or add the XR20M117x
> UARTs to the sc16is7xx driver with a flag to choose one behavior or the
> other?

Probably a flag, but let's see the patch to be sure.

> I have developed and tested the driver as a back-port of the mainline
> sc16is7xx driver to the 4.4 kernel used on our embedded platform.  I don't
> have a ready method to test the driver with a newer kernel (other than
> ensuring compilation success).  Is that a concern for accepting the driver?

Please don't use any new devices with the obsolete and insecure and
out-of-date 4.4 kernel tree, that's going to be a regulatory nightmare
when you realize how broken it is.

Anyway, it has to work in the latest kernel tree for us to be able to
accept it as we can't go back in time and do new development on old
kernels :)

thanks,

greg k-h