linux-kernel - 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-next>] [day] [month] [year] [list]

Message-ID: <CAGMfbUO=Zy_nXJ9wKV5r2xRBuK7_X3kL2TvM1jWB_hTPUvhnbw@mail.gmail.com>
Date:   Fri, 23 Sep 2022 11:29:52 -0400
From:   Jeff Harris <jefftharris@...il.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: serial: New xr20m117x driver questions

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?

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?

Part link:
https://www.maxlinear.com/product/interface/uarts/i2c-spi-uarts/xr20m1172

Thanks,
Jeff