From: Greg Kroah-Hartman Date: Thu, 23 Jun 2022 16:17:36 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v4.9.320~6 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=26ade790494fe5785a6d21394e775690515ea687;p=thirdparty%2Fkernel%2Fstable-queue.git 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 index 00000000000..ae386120ddb --- /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 +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 + +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 +Cc: Christoph Hellwig +Cc: Robin Murphy +Cc: Russell King +Cc: +Link: https://lore.kernel.org/r/20220606152150.GA31568@willie-the-truck +Signed-off-by: Will Deacon +Reviewed-by: Ard Biesheuvel +Link: https://lore.kernel.org/r/20220610151228.4562-2-will@kernel.org +Signed-off-by: Catalin Marinas +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 00000000000..bed8d131a43 --- /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 +Date: Sun, 23 Jan 2022 05:21:14 +0100 +Subject: serial: core: Initialize rs485 RTS polarity already on probe + +From: Lukas Wunner + +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 +Cc: Su Bao Cheng +Signed-off-by: Lukas Wunner +Link: https://lore.kernel.org/r/2d2acaf3a69e89b7bf687c912022b11fd29dfa1e.1642909284.git.lukas@wunner.de +Signed-off-by: Greg Kroah-Hartman +--- + 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 c7f6b6bf1a5..ebcfdb33045 100644 --- 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