Date:   Mon,  6 Jun 2022 13:03:57 +0300
From:   Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To:     linux-serial@...r.kernel.org, Greg KH <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>
Cc:     Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
        alexandre.belloni@...tlin.com, alexandre.torgue@...s.st.com,
        andriy.shevchenko@...ux.intel.com,
        bcm-kernel-feedback-list@...adcom.com,
        claudiu.beznea@...rochip.com, corbet@....net, festevam@...il.com,
        f.fainelli@...il.com, kernel@...gutronix.de,
        linux-arm-kernel@...ts.infradead.org, linux@...linux.org.uk,
        linux-doc@...r.kernel.org, linux-imx@....com,
        linux-kernel@...r.kernel.org, linux-rpi-kernel@...ts.infradead.org,
        linux-stm32@...md-mailman.stormreply.com,
        mcoquelin.stm32@...il.com, nicolas.ferre@...rochip.com,
        nsaenz@...nel.org, richard.genoud@...il.com, rjui@...adcom.com,
        sbranden@...adcom.com, s.hauer@...gutronix.de, shawnguo@...nel.org,
        vz@...ia.com
Subject: [PATCH 00/36] RS485 serial_rs485 sanitization

This series adds sanitization to serial_rs485 struct before passing it
to driver's rs485_config. This takes the work Lino Sanfilippo started
(0ed12afa5655^..60efd0513916) a bit further. By moving sanitization of
the rs485 struct into the serial core, per driver rs485_config() is
more into the point, that is, setting up the hw to realize RS485.

The other benefit is that with the sanitization, the other drivers no
longer need to care when new things are added to serial_rs485 as serial
core handles them on the other drivers' behalf. The addressing mode
changes I'll submit separately will take advantage of this. The
addressing mode changes were the main motivator for doing the changes,
however, I believe these changes stand on their feet even w/o
considering the addressing mode changes.

The series is long because per driver changes are split into two
different stages. The key objectives here for the split have been to
keep things bisect safe and to do changes per driver rather than in one
large block. This required 4 stages:

  1) Add datastructure entries & other preps (01-03)
  2) Per driver rs485_supported (04-21)
  3) Sanitization, core taking advantage of rs485_supported (22-24)
  4) Cleanup per driver custom sanitization code (25-36)

As you can see, the downside of this split is that the per driver code
is split to 2+4 patches which makes some things moving less obvious.
Merging them is only possible if the stages 2-4 are done in one large
change (little bits here and there could be left out from it but not
much).

In stage 3 patches, there are a few userspace interface impacting
changes with userspace api regression potential:

  a) Some drivers have not cleared flags/fields in per driver code while
     other drivers have. The old behavior is inconsistent. Now the bits
     will get cleaned up by serial core. I don't believe it's going to
     cause issues.

  b) Init path now sanitizes configuration if rs485_config is being
     called from the init path (mainly coming from dt). It attempts to
     repair some incorrect configurations which seems ok.

     However, if RS485 mode is not enabled at boot, serial_rs485 struct
     gets cleared in order for it to match what the port is configured
     with (RS232). Such clearing implies losing values that were
     configured through dt and that could perhaps be seen as unwanted
     side-effect from having consistent serial_rs485?

     There is also impact for the ioctl path from this clearing of
     serial_rs485 when RS485 is disabled but impact seems minor at most.

  c) Returning -EINVAL for non-legacy flags. This also affects setting
     bits that were previously padding (that is, all flags bits
     currently not defined in include/uapi/linux/serial.h). It was
     possible to put garbage into them earlier but no more. I guess
     this is not very likely a big issue. No non-legacy flags are
     added in this series (the addressing mode changes submitted
     separately will add new flags).

Cc: alexandre.belloni@...tlin.com
Cc: alexandre.torgue@...s.st.com
Cc: andriy.shevchenko@...ux.intel.com
Cc: bcm-kernel-feedback-list@...adcom.com
Cc: claudiu.beznea@...rochip.com
Cc: corbet@....net
Cc: festevam@...il.com
Cc: f.fainelli@...il.com
Cc: kernel@...gutronix.de
Cc: linux-arm-kernel@...ts.infradead.org
Cc: linux@...linux.org.uk
Cc: linux-doc@...r.kernel.org
Cc: linux-imx@....com
Cc: linux-kernel@...r.kernel.org
Cc: linux-rpi-kernel@...ts.infradead.org
Cc: linux-stm32@...md-mailman.stormreply.com
Cc: mcoquelin.stm32@...il.com
Cc: nicolas.ferre@...rochip.com
Cc: nsaenz@...nel.org
Cc: richard.genoud@...il.com
Cc: rjui@...adcom.com
Cc: sbranden@...adcom.com
Cc: s.hauer@...gutronix.de
Cc: shawnguo@...nel.org
Cc: vz@...ia.com

Ilpo Järvinen (36):
  serial: Add uart_rs485_config()
  serial: Move serial_rs485 sanitization into separate function
  serial: Add rs485_supported to uart_port
  serial: 8250: Create serial8250_em485_supported for em485 users
  serial: 8250_bcm2835aux: Use serial8250_em485_supported
  serial: 8250_dwlib: Fill in rs485_supported
  serial: 8250_exar: Fill in rs485_supported
  serial: 8250_fintek: Fill in rs485_supported
  serial: 8250_lpc18cc: Fill in rs485_supported
  serial: 8250_of: Use serial8250_em485_supported
  serial: 8250_pci: Fill in rs485_supported for pci_fintek
  serial: pl011: Fill in rs485_supported
  serial: ar933x: Fill in rs485_supported
  serial: atmel: Fill in rs485_supported
  serial: fsl_lpuart: Fill in rs485_supported
  serial: imx: Fill in rs485_supported
  serial: max310x: Fill in rs485_supported
  serial: mcf: Fill in rs485_supported
  serial: omap: Fill in rs485_supported
  serial: sc16is7xx: Fill in rs485_supported
  serial: stm32: Fill in rs485_supported
  serial: Sanitize rs485_struct
  serial: Clear rs485 struct when non-RS485 mode is set
  serial: return -EINVAL for non-legacy RS485 flags
  serial: 8250_dwlib: Remove serial_rs485 sanitization
  serial: 8250_fintek: Remove serial_rs485 sanitization
  serial: 8250: lpc18xx: Remove serial_rs485 sanitization
  serial: 8250_pci: Remove serial_rs485 sanitization
  serial: pl011: Remove serial_rs485 sanitization
  serial: fsl_lpuart: Call core's sanitization and remove custom one
  serial: imx: Remove serial_rs485 sanitization
  serial: max310x: Remove serial_rs485 sanitization
  serial: 8250_exar: Remove serial_rs485 assignment
  serial: mcf: Remove serial_rs485 assignment
  serial: sc16is7xx: Remove serial_rs485 assignment
  serial: 8250: Remove serial_rs485 sanitization from em485

 .../driver-api/serial/serial-rs485.rst        |  12 +-
 drivers/tty/serial/8250/8250.h                |   1 +
 drivers/tty/serial/8250/8250_bcm2835aux.c     |   1 +
 drivers/tty/serial/8250/8250_core.c           |   1 +
 drivers/tty/serial/8250/8250_dwlib.c          |  17 +--
 drivers/tty/serial/8250/8250_exar.c           |  14 +-
 drivers/tty/serial/8250/8250_fintek.c         |  29 +++--
 drivers/tty/serial/8250/8250_lpc18xx.c        |  20 +--
 drivers/tty/serial/8250/8250_of.c             |   1 +
 drivers/tty/serial/8250/8250_pci.c            |  24 +---
 drivers/tty/serial/8250/8250_port.c           |  28 ++--
 drivers/tty/serial/amba-pl011.c               |  13 +-
 drivers/tty/serial/ar933x_uart.c              |   7 +
 drivers/tty/serial/atmel_serial.c             |   7 +
 drivers/tty/serial/fsl_lpuart.c               |  25 +---
 drivers/tty/serial/imx.c                      |  19 ++-
 drivers/tty/serial/max310x.c                  |   9 +-
 drivers/tty/serial/mcf.c                      |   7 +-
 drivers/tty/serial/omap-serial.c              |   8 ++
 drivers/tty/serial/sc16is7xx.c                |   8 +-
 drivers/tty/serial/serial_core.c              | 120 ++++++++++++++----
 drivers/tty/serial/stm32-usart.c              |   8 ++
 include/linux/serial_core.h                   |   2 +
 23 files changed, 247 insertions(+), 134 deletions(-)

-- 
2.30.2

Powered by blists - more mailing lists