5.10-stable patches

added patches:
	arm64-mm-don-t-invalidate-from_device-buffers-at-start-of-dma-transfer.patch
	serial-core-initialize-rs485-rts-polarity-already-on-probe.patch

diff --git a/queue-5.10/arm64-mm-don-t-invalidate-from_device-buffers-at-start-of-dma-transfer.patch b/queue-5.10/arm64-mm-don-t-invalidate-from_device-buffers-at-start-of-dma-transfer.patch
new file mode 100644 (file)
index 0000000..ae38612
--- /dev/null
+++ b/queue-5.10/arm64-mm-don-t-invalidate-from_device-buffers-at-start-of-dma-transfer.patch
@@ -0,0 +1,56 @@
+From c50f11c6196f45c92ca48b16a5071615d4ae0572 Mon Sep 17 00:00:00 2001
+From: Will Deacon <will@kernel.org>
+Date: Fri, 10 Jun 2022 16:12:27 +0100
+Subject: arm64: mm: Don't invalidate FROM_DEVICE buffers at start of DMA transfer
+
+From: Will Deacon <will@kernel.org>
+
+commit c50f11c6196f45c92ca48b16a5071615d4ae0572 upstream.
+
+Invalidating the buffer memory in arch_sync_dma_for_device() for
+FROM_DEVICE transfers
+
+When using the streaming DMA API to map a buffer prior to inbound
+non-coherent DMA (i.e. DMA_FROM_DEVICE), we invalidate any dirty CPU
+cachelines so that they will not be written back during the transfer and
+corrupt the buffer contents written by the DMA. This, however, poses two
+potential problems:
+
+  (1) If the DMA transfer does not write to every byte in the buffer,
+      then the unwritten bytes will contain stale data once the transfer
+      has completed.
+
+  (2) If the buffer has a virtual alias in userspace, then stale data
+      may be visible via this alias during the period between performing
+      the cache invalidation and the DMA writes landing in memory.
+
+Address both of these issues by cleaning (aka writing-back) the dirty
+lines in arch_sync_dma_for_device(DMA_FROM_DEVICE) instead of discarding
+them using invalidation.
+
+Cc: Ard Biesheuvel <ardb@kernel.org>
+Cc: Christoph Hellwig <hch@lst.de>
+Cc: Robin Murphy <robin.murphy@arm.com>
+Cc: Russell King <linux@armlinux.org.uk>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20220606152150.GA31568@willie-the-truck
+Signed-off-by: Will Deacon <will@kernel.org>
+Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
+Link: https://lore.kernel.org/r/20220610151228.4562-2-will@kernel.org
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/mm/cache.S |    2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/arch/arm64/mm/cache.S
++++ b/arch/arm64/mm/cache.S
+@@ -228,8 +228,6 @@ SYM_FUNC_END_PI(__dma_flush_area)
+  *    - dir   - DMA direction
+  */
+ SYM_FUNC_START_PI(__dma_map_area)
+-      cmp     w2, #DMA_FROM_DEVICE
+-      b.eq    __dma_inv_area
+       b       __dma_clean_area
+ SYM_FUNC_END_PI(__dma_map_area)
+ 

diff --git a/queue-5.10/serial-core-initialize-rs485-rts-polarity-already-on-probe.patch b/queue-5.10/serial-core-initialize-rs485-rts-polarity-already-on-probe.patch
new file mode 100644 (file)
index 0000000..bed8d13
--- /dev/null
+++ b/queue-5.10/serial-core-initialize-rs485-rts-polarity-already-on-probe.patch
@@ -0,0 +1,120 @@
+From 2dd8a74fddd21b95dcc60a2d3c9eaec993419d69 Mon Sep 17 00:00:00 2001
+From: Lukas Wunner <lukas@wunner.de>
+Date: Sun, 23 Jan 2022 05:21:14 +0100
+Subject: serial: core: Initialize rs485 RTS polarity already on probe
+
+From: Lukas Wunner <lukas@wunner.de>
+
+commit 2dd8a74fddd21b95dcc60a2d3c9eaec993419d69 upstream.
+
+RTS polarity of rs485-enabled ports is currently initialized on uart
+open via:
+
+tty_port_open()
+  tty_port_block_til_ready()
+    tty_port_raise_dtr_rts()  # if (C_BAUD(tty))
+      uart_dtr_rts()
+        uart_port_dtr_rts()
+
+There's at least three problems here:
+
+First, if no baud rate is set, RTS polarity is not initialized.
+That's the right thing to do for rs232, but not for rs485, which
+requires that RTS is deasserted unconditionally.
+
+Second, if the DeviceTree property "linux,rs485-enabled-at-boot-time" is
+present, RTS should be deasserted as early as possible, i.e. on probe.
+Otherwise it may remain asserted until first open.
+
+Third, even though RTS is deasserted on open and close, it may
+subsequently be asserted by uart_throttle(), uart_unthrottle() or
+uart_set_termios() because those functions aren't rs485-aware.
+(Only uart_tiocmset() is.)
+
+To address these issues, move RTS initialization from uart_port_dtr_rts()
+to uart_configure_port().  Prevent subsequent modification of RTS
+polarity by moving the existing rs485 check from uart_tiocmget() to
+uart_update_mctrl().
+
+That way, RTS is initialized on probe and then remains unmodified unless
+the uart transmits data.  If rs485 is enabled at runtime (instead of at
+boot) through a TIOCSRS485 ioctl(), RTS is initialized by the uart
+driver's ->rs485_config() callback and then likewise remains unmodified.
+
+The PL011 driver initializes RTS on uart open and prevents subsequent
+modification in its ->set_mctrl() callback.  That code is obsoleted by
+the present commit, so drop it.
+
+Cc: Jan Kiszka <jan.kiszka@siemens.com>
+Cc: Su Bao Cheng <baocheng.su@siemens.com>
+Signed-off-by: Lukas Wunner <lukas@wunner.de>
+Link: https://lore.kernel.org/r/2d2acaf3a69e89b7bf687c912022b11fd29dfa1e.1642909284.git.lukas@wunner.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/serial_core.c |   34 ++++++++++++----------------------
+ 1 file changed, 12 insertions(+), 22 deletions(-)
+
+--- a/drivers/tty/serial/serial_core.c
++++ b/drivers/tty/serial/serial_core.c
+@@ -144,6 +144,11 @@ uart_update_mctrl(struct uart_port *port
+       unsigned long flags;
+       unsigned int old;
+ 
++      if (port->rs485.flags & SER_RS485_ENABLED) {
++              set &= ~TIOCM_RTS;
++              clear &= ~TIOCM_RTS;
++      }
++
+       spin_lock_irqsave(&port->lock, flags);
+       old = port->mctrl;
+       port->mctrl = (old & ~clear) | set;
+@@ -157,23 +162,10 @@ uart_update_mctrl(struct uart_port *port
+ 
+ static void uart_port_dtr_rts(struct uart_port *uport, int raise)
+ {
+-      int rs485_on = uport->rs485_config &&
+-              (uport->rs485.flags & SER_RS485_ENABLED);
+-      int RTS_after_send = !!(uport->rs485.flags & SER_RS485_RTS_AFTER_SEND);
+-
+-      if (raise) {
+-              if (rs485_on && RTS_after_send) {
+-                      uart_set_mctrl(uport, TIOCM_DTR);
+-                      uart_clear_mctrl(uport, TIOCM_RTS);
+-              } else {
+-                      uart_set_mctrl(uport, TIOCM_DTR | TIOCM_RTS);
+-              }
+-      } else {
+-              unsigned int clear = TIOCM_DTR;
+-
+-              clear |= (!rs485_on || RTS_after_send) ? TIOCM_RTS : 0;
+-              uart_clear_mctrl(uport, clear);
+-      }
++      if (raise)
++              uart_set_mctrl(uport, TIOCM_DTR | TIOCM_RTS);
++      else
++              uart_clear_mctrl(uport, TIOCM_DTR | TIOCM_RTS);
+ }
+ 
+ /*
+@@ -1116,11 +1108,6 @@ uart_tiocmset(struct tty_struct *tty, un
+               goto out;
+ 
+       if (!tty_io_error(tty)) {
+-              if (uport->rs485.flags & SER_RS485_ENABLED) {
+-                      set &= ~TIOCM_RTS;
+-                      clear &= ~TIOCM_RTS;
+-              }
+-
+               uart_update_mctrl(uport, set, clear);
+               ret = 0;
+       }
+@@ -2429,6 +2416,9 @@ uart_configure_port(struct uart_driver *
+                */
+               spin_lock_irqsave(&port->lock, flags);
+               port->mctrl &= TIOCM_DTR;
++              if (port->rs485.flags & SER_RS485_ENABLED &&
++                  !(port->rs485.flags & SER_RS485_RTS_AFTER_SEND))
++                      port->mctrl |= TIOCM_RTS;
+               port->ops->set_mctrl(port, port->mctrl);
+               spin_unlock_irqrestore(&port->lock, flags);
+ 

diff --git a/queue-5.10/series b/queue-5.10/series
index c7f6b6bf1a58c80dc66a33d24b816ed382f5821e..ebcfdb33045434c83d0edba7117de958e8c4dd57 100644 (file)
--- a/queue-5.10/series
+++ b/queue-5.10/series
@@ -7,3 +7,5 @@ tcp-add-small-random-increments-to-the-source-port.patch
 tcp-dynamically-allocate-the-perturb-table-used-by-source-ports.patch
 tcp-increase-source-port-perturb-table-to-2-16.patch
 tcp-drop-the-hash_32-part-from-the-index-calculation.patch
+serial-core-initialize-rs485-rts-polarity-already-on-probe.patch
+arm64-mm-don-t-invalidate-from_device-buffers-at-start-of-dma-transfer.patch