serial: New xr20m117x driver questions

serial: New xr20m117x driver questions

[Jeff Harris]

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

Re: serial: New xr20m117x driver questions

[Greg Kroah-Hartman]

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