June 2024 - Linux-stable-mirror

FAILED: patch "[PATCH] cifs: fix typo in module parameter enable_gcm_256" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 8bf0287528da1992c5e49d757b99ad6bbc34b522 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024062411-ipad-conical-35fb@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 8bf0287528da1992c5e49d757b99ad6bbc34b522 Mon Sep 17 00:00:00 2001 From: Steve French <stfrench(a)microsoft.com> Date: Wed, 19 Jun 2024 14:46:48 -0500 Subject: [PATCH] cifs: fix typo in module parameter enable_gcm_256 enable_gcm_256 (which allows the server to require the strongest encryption) is enabled by default, but the modinfo description incorrectly showed it disabled by default. Fix the typo. Cc: stable(a)vger.kernel.org Fixes: fee742b50289 ("smb3.1.1: enable negotiating stronger encryption by default") Signed-off-by: Steve French <stfrench(a)microsoft.com> diff --git a/fs/smb/client/cifsfs.c b/fs/smb/client/cifsfs.c index bb86fc0641d8..6397fdefd876 100644 --- a/fs/smb/client/cifsfs.c +++ b/fs/smb/client/cifsfs.c @@ -134,7 +134,7 @@ module_param(enable_oplocks, bool, 0644); MODULE_PARM_DESC(enable_oplocks, "Enable or disable oplocks. Default: y/Y/1"); module_param(enable_gcm_256, bool, 0644); -MODULE_PARM_DESC(enable_gcm_256, "Enable requesting strongest (256 bit) GCM encryption. Default: n/N/0"); +MODULE_PARM_DESC(enable_gcm_256, "Enable requesting strongest (256 bit) GCM encryption. Default: y/Y/0"); module_param(require_gcm_256, bool, 0644); MODULE_PARM_DESC(require_gcm_256, "Require strongest (256 bit) GCM encryption. Default: n/N/0");

6 months, 1 week

1
0
0 0

FAILED: patch "[PATCH] net: stmmac: Assign configured channel value to EXTTS event" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 8851346912a1fa33e7a5966fe51f07313b274627 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024062402-reabsorb-plausible-88b5@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 8851346912a1 ("net: stmmac: Assign configured channel value to EXTTS event") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 8851346912a1fa33e7a5966fe51f07313b274627 Mon Sep 17 00:00:00 2001 From: Oleksij Rempel <o.rempel(a)pengutronix.de> Date: Tue, 18 Jun 2024 09:38:21 +0200 Subject: [PATCH] net: stmmac: Assign configured channel value to EXTTS event Assign the configured channel value to the EXTTS event in the timestamp interrupt handler. Without assigning the correct channel, applications like ts2phc will refuse to accept the event, resulting in errors such as: ... ts2phc[656.834]: config item end1.ts2phc.pin_index is 0 ts2phc[656.834]: config item end1.ts2phc.channel is 3 ts2phc[656.834]: config item end1.ts2phc.extts_polarity is 2 ts2phc[656.834]: config item end1.ts2phc.extts_correction is 0 ... ts2phc[656.862]: extts on unexpected channel ts2phc[658.141]: extts on unexpected channel ts2phc[659.140]: extts on unexpected channel Fixes: f4da56529da60 ("net: stmmac: Add support for external trigger timestamping") Cc: stable(a)vger.kernel.org Signed-off-by: Oleksij Rempel <o.rempel(a)pengutronix.de> Reviewed-by: Wojciech Drewek <wojciech.drewek(a)intel.com> Link: https://lore.kernel.org/r/20240618073821.619751-1-o.rempel@pengutronix.de Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c index f05bd757dfe5..5ef52ef2698f 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c @@ -218,6 +218,7 @@ static void timestamp_interrupt(struct stmmac_priv *priv) { u32 num_snapshot, ts_status, tsync_int; struct ptp_clock_event event; + u32 acr_value, channel; unsigned long flags; u64 ptp_time; int i; @@ -243,12 +244,15 @@ static void timestamp_interrupt(struct stmmac_priv *priv) num_snapshot = (ts_status & GMAC_TIMESTAMP_ATSNS_MASK) >> GMAC_TIMESTAMP_ATSNS_SHIFT; + acr_value = readl(priv->ptpaddr + PTP_ACR); + channel = ilog2(FIELD_GET(PTP_ACR_MASK, acr_value)); + for (i = 0; i < num_snapshot; i++) { read_lock_irqsave(&priv->ptp_lock, flags); get_ptptime(priv->ptpaddr, &ptp_time); read_unlock_irqrestore(&priv->ptp_lock, flags); event.type = PTP_CLOCK_EXTTS; - event.index = 0; + event.index = channel; event.timestamp = ptp_time; ptp_clock_event(priv->ptp_clock, &event); }

6 months, 1 week

1
0
0 0

FAILED: patch "[PATCH] locking/atomic: scripts: fix ${atomic}_sub_and_test()" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x f92a59f6d12e31ead999fee9585471b95a8ae8a3 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024061810-overflow-president-399a@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: f92a59f6d12e ("locking/atomic: scripts: fix ${atomic}_sub_and_test() kerneldoc") 6dfee110c6cc ("locking/atomic: scripts: Clarify ordering of conditional atomics") e01cc1e8c2ad ("locking/atomic: Add generic support for sync_try_cmpxchg() and its fallback") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f92a59f6d12e31ead999fee9585471b95a8ae8a3 Mon Sep 17 00:00:00 2001 From: Carlos Llamas <cmllamas(a)google.com> Date: Wed, 15 May 2024 13:37:10 +0000 Subject: [PATCH] locking/atomic: scripts: fix ${atomic}_sub_and_test() kerneldoc For ${atomic}_sub_and_test() the @i parameter is the value to subtract, not add. Fix the typo in the kerneldoc template and generate the headers with this update. Fixes: ad8110706f38 ("locking/atomic: scripts: generate kerneldoc comments") Suggested-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Carlos Llamas <cmllamas(a)google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Acked-by: Mark Rutland <mark.rutland(a)arm.com> Reviewed-by: Kees Cook <keescook(a)chromium.org> Cc: stable(a)vger.kernel.org Link: https://lkml.kernel.org/r/20240515133844.3502360-1-cmllamas@google.com diff --git a/include/linux/atomic/atomic-arch-fallback.h b/include/linux/atomic/atomic-arch-fallback.h index 956bcba5dbf2..2f9d36b72bd8 100644 --- a/include/linux/atomic/atomic-arch-fallback.h +++ b/include/linux/atomic/atomic-arch-fallback.h @@ -2242,7 +2242,7 @@ raw_atomic_try_cmpxchg_relaxed(atomic_t *v, int *old, int new) /** * raw_atomic_sub_and_test() - atomic subtract and test if zero with full ordering - * @i: int value to add + * @i: int value to subtract * @v: pointer to atomic_t * * Atomically updates @v to (@v - @i) with full ordering. @@ -4368,7 +4368,7 @@ raw_atomic64_try_cmpxchg_relaxed(atomic64_t *v, s64 *old, s64 new) /** * raw_atomic64_sub_and_test() - atomic subtract and test if zero with full ordering - * @i: s64 value to add + * @i: s64 value to subtract * @v: pointer to atomic64_t * * Atomically updates @v to (@v - @i) with full ordering. @@ -4690,4 +4690,4 @@ raw_atomic64_dec_if_positive(atomic64_t *v) } #endif /* _LINUX_ATOMIC_FALLBACK_H */ -// 14850c0b0db20c62fdc78ccd1d42b98b88d76331 +// b565db590afeeff0d7c9485ccbca5bb6e155749f diff --git a/include/linux/atomic/atomic-instrumented.h b/include/linux/atomic/atomic-instrumented.h index debd487fe971..9409a6ddf3e0 100644 --- a/include/linux/atomic/atomic-instrumented.h +++ b/include/linux/atomic/atomic-instrumented.h @@ -1349,7 +1349,7 @@ atomic_try_cmpxchg_relaxed(atomic_t *v, int *old, int new) /** * atomic_sub_and_test() - atomic subtract and test if zero with full ordering - * @i: int value to add + * @i: int value to subtract * @v: pointer to atomic_t * * Atomically updates @v to (@v - @i) with full ordering. @@ -2927,7 +2927,7 @@ atomic64_try_cmpxchg_relaxed(atomic64_t *v, s64 *old, s64 new) /** * atomic64_sub_and_test() - atomic subtract and test if zero with full ordering - * @i: s64 value to add + * @i: s64 value to subtract * @v: pointer to atomic64_t * * Atomically updates @v to (@v - @i) with full ordering. @@ -4505,7 +4505,7 @@ atomic_long_try_cmpxchg_relaxed(atomic_long_t *v, long *old, long new) /** * atomic_long_sub_and_test() - atomic subtract and test if zero with full ordering - * @i: long value to add + * @i: long value to subtract * @v: pointer to atomic_long_t * * Atomically updates @v to (@v - @i) with full ordering. @@ -5050,4 +5050,4 @@ atomic_long_dec_if_positive(atomic_long_t *v) #endif /* _LINUX_ATOMIC_INSTRUMENTED_H */ -// ce5b65e0f1f8a276268b667194581d24bed219d4 +// 8829b337928e9508259079d32581775ececd415b diff --git a/include/linux/atomic/atomic-long.h b/include/linux/atomic/atomic-long.h index 3ef844b3ab8a..f86b29d90877 100644 --- a/include/linux/atomic/atomic-long.h +++ b/include/linux/atomic/atomic-long.h @@ -1535,7 +1535,7 @@ raw_atomic_long_try_cmpxchg_relaxed(atomic_long_t *v, long *old, long new) /** * raw_atomic_long_sub_and_test() - atomic subtract and test if zero with full ordering - * @i: long value to add + * @i: long value to subtract * @v: pointer to atomic_long_t * * Atomically updates @v to (@v - @i) with full ordering. @@ -1809,4 +1809,4 @@ raw_atomic_long_dec_if_positive(atomic_long_t *v) } #endif /* _LINUX_ATOMIC_LONG_H */ -// 1c4a26fc77f345342953770ebe3c4d08e7ce2f9a +// eadf183c3600b8b92b91839dd3be6bcc560c752d diff --git a/scripts/atomic/kerneldoc/sub_and_test b/scripts/atomic/kerneldoc/sub_and_test index d3760f7749d4..96615e50836b 100644 --- a/scripts/atomic/kerneldoc/sub_and_test +++ b/scripts/atomic/kerneldoc/sub_and_test @@ -1,7 +1,7 @@ cat <<EOF /** * ${class}${atomicname}() - atomic subtract and test if zero with ${desc_order} ordering - * @i: ${int} value to add + * @i: ${int} value to subtract * @v: pointer to ${atomic}_t * * Atomically updates @v to (@v - @i) with ${desc_order} ordering.

6 months, 1 week

3
2
0 0

[PATCH 5.15] serial: stm32: rework RX over DMA

by Dario Binacchi

From: Erwan Le Ray <erwan.leray(a)foss.st.com> commit 33bb2f6ac3088936b7aad3cab6f439f91af0223c upstream. This patch reworks RX support over DMA to improve reliability: - change dma buffer cyclic configuration by using 2 periods. DMA buffer data are handled by a flip-flop between the 2 periods in order to avoid risk of data loss/corruption - change the size of dma buffer to 4096 to limit overruns - add rx errors management (breaks, parity, framing and overrun). When an error occurs on the uart line, the dma request line is masked at HW level. The SW must 1st clear DMAR (dma request line enable), to handle the error, then re-enable DMAR to recover. So, any correct data is taken from the DMA buffer, before handling the error itself. Then errors are handled from RDR/ISR/FIFO (e.g. in PIO mode). Last, DMA reception is resumed. - add a condition on DMA request line in DMA RX routines in order to switch to PIO mode when no DMA request line is disabled, even if the DMA channel is still enabled. When the UART is wakeup source and is configured to use DMA for RX, any incoming data that wakes up the system isn't correctly received. At data reception, the irq_handler handles the WUF irq, and then the data reception over DMA. As the DMA transfer has been terminated at suspend, and will be restored by resume callback (which has no yet been called by system), the data can't be received. The wake-up data has to be handled in PIO mode while suspend callback has not been called. Signed-off-by: Valentin Caron <valentin.caron(a)foss.st.com> Signed-off-by: Erwan Le Ray <erwan.leray(a)foss.st.com> Link: https://lore.kernel.org/r/20211020150332.10214-3-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> [ dario: fix conflicts for backport to v5.15. From the [1] series, only the first patch was applied to the v5.15 branch. This caused a regression in character reception, which can be fixed by applying the second patch. The patch has been tested on the stm32f469-disco board. [1] https://lore.kernel.org/all/20211020150332.10214-1-erwan.leray@foss.st.com/. ] Signed-off-by: Dario Binacchi <dario.binacchi(a)amarulasolutions.com> --- drivers/tty/serial/stm32-usart.c | 206 ++++++++++++++++++++++++------- drivers/tty/serial/stm32-usart.h | 12 +- 2 files changed, 165 insertions(+), 53 deletions(-) diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c index 3b7d4481edbe..c20f8917ebff 100644 --- a/drivers/tty/serial/stm32-usart.c +++ b/drivers/tty/serial/stm32-usart.c @@ -220,66 +220,60 @@ static int stm32_usart_init_rs485(struct uart_port *port, return uart_get_rs485_mode(port); } -static int stm32_usart_pending_rx(struct uart_port *port, u32 *sr, - int *last_res, bool threaded) +static bool stm32_usart_rx_dma_enabled(struct uart_port *port) { struct stm32_port *stm32_port = to_stm32_port(port); const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs; - enum dma_status status; - struct dma_tx_state state; - *sr = readl_relaxed(port->membase + ofs->isr); + if (!stm32_port->rx_ch) + return false; - if (threaded && stm32_port->rx_ch) { - status = dmaengine_tx_status(stm32_port->rx_ch, - stm32_port->rx_ch->cookie, - &state); - if (status == DMA_IN_PROGRESS && (*last_res != state.residue)) - return 1; - else - return 0; - } else if (*sr & USART_SR_RXNE) { - return 1; + return !!(readl_relaxed(port->membase + ofs->cr3) & USART_CR3_DMAR); +} + +/* Return true when data is pending (in pio mode), and false when no data is pending. */ +static bool stm32_usart_pending_rx_pio(struct uart_port *port, u32 *sr) +{ + struct stm32_port *stm32_port = to_stm32_port(port); + const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs; + + *sr = readl_relaxed(port->membase + ofs->isr); + /* Get pending characters in RDR or FIFO */ + if (*sr & USART_SR_RXNE) { + /* Get all pending characters from the RDR or the FIFO when using interrupts */ + if (!stm32_usart_rx_dma_enabled(port)) + return true; + + /* Handle only RX data errors when using DMA */ + if (*sr & USART_SR_ERR_MASK) + return true; } - return 0; + + return false; } -static unsigned long stm32_usart_get_char(struct uart_port *port, u32 *sr, - int *last_res) +static unsigned long stm32_usart_get_char_pio(struct uart_port *port) { struct stm32_port *stm32_port = to_stm32_port(port); const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs; unsigned long c; - if (stm32_port->rx_ch) { - c = stm32_port->rx_buf[RX_BUF_L - (*last_res)--]; - if ((*last_res) == 0) - *last_res = RX_BUF_L; - } else { - c = readl_relaxed(port->membase + ofs->rdr); - /* apply RDR data mask */ - c &= stm32_port->rdr_mask; - } + c = readl_relaxed(port->membase + ofs->rdr); + /* Apply RDR data mask */ + c &= stm32_port->rdr_mask; return c; } -static void stm32_usart_receive_chars(struct uart_port *port, bool irqflag) +static void stm32_usart_receive_chars_pio(struct uart_port *port) { - struct tty_port *tport = &port->state->port; struct stm32_port *stm32_port = to_stm32_port(port); const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs; - unsigned long c, flags; + unsigned long c; u32 sr; char flag; - if (irqflag) - spin_lock_irqsave(&port->lock, flags); - else - spin_lock(&port->lock); - - while (stm32_usart_pending_rx(port, &sr, &stm32_port->last_res, - irqflag)) { + while (stm32_usart_pending_rx_pio(port, &sr)) { sr |= USART_SR_DUMMY_RX; flag = TTY_NORMAL; @@ -298,7 +292,7 @@ static void stm32_usart_receive_chars(struct uart_port *port, bool irqflag) writel_relaxed(sr & USART_SR_ERR_MASK, port->membase + ofs->icr); - c = stm32_usart_get_char(port, &sr, &stm32_port->last_res); + c = stm32_usart_get_char_pio(port); port->icount.rx++; if (sr & USART_SR_ERR_MASK) { if (sr & USART_SR_ORE) { @@ -332,6 +326,94 @@ static void stm32_usart_receive_chars(struct uart_port *port, bool irqflag) continue; uart_insert_char(port, sr, USART_SR_ORE, c, flag); } +} + +static void stm32_usart_push_buffer_dma(struct uart_port *port, unsigned int dma_size) +{ + struct stm32_port *stm32_port = to_stm32_port(port); + struct tty_port *ttyport = &stm32_port->port.state->port; + unsigned char *dma_start; + int dma_count, i; + + dma_start = stm32_port->rx_buf + (RX_BUF_L - stm32_port->last_res); + + /* + * Apply rdr_mask on buffer in order to mask parity bit. + * This loop is useless in cs8 mode because DMA copies only + * 8 bits and already ignores parity bit. + */ + if (!(stm32_port->rdr_mask == (BIT(8) - 1))) + for (i = 0; i < dma_size; i++) + *(dma_start + i) &= stm32_port->rdr_mask; + + dma_count = tty_insert_flip_string(ttyport, dma_start, dma_size); + port->icount.rx += dma_count; + if (dma_count != dma_size) + port->icount.buf_overrun++; + stm32_port->last_res -= dma_count; + if (stm32_port->last_res == 0) + stm32_port->last_res = RX_BUF_L; +} + +static void stm32_usart_receive_chars_dma(struct uart_port *port) +{ + struct stm32_port *stm32_port = to_stm32_port(port); + unsigned int dma_size; + + /* DMA buffer is configured in cyclic mode and handles the rollback of the buffer. */ + if (stm32_port->rx_dma_state.residue > stm32_port->last_res) { + /* Conditional first part: from last_res to end of DMA buffer */ + dma_size = stm32_port->last_res; + stm32_usart_push_buffer_dma(port, dma_size); + } + + dma_size = stm32_port->last_res - stm32_port->rx_dma_state.residue; + stm32_usart_push_buffer_dma(port, dma_size); +} + +static void stm32_usart_receive_chars(struct uart_port *port, bool irqflag) +{ + struct tty_port *tport = &port->state->port; + struct stm32_port *stm32_port = to_stm32_port(port); + const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs; + enum dma_status rx_dma_status; + unsigned long flags; + u32 sr; + + if (irqflag) + spin_lock_irqsave(&port->lock, flags); + else + spin_lock(&port->lock); + + if (stm32_usart_rx_dma_enabled(port)) { + rx_dma_status = dmaengine_tx_status(stm32_port->rx_ch, + stm32_port->rx_ch->cookie, + &stm32_port->rx_dma_state); + if (rx_dma_status == DMA_IN_PROGRESS) { + /* Empty DMA buffer */ + stm32_usart_receive_chars_dma(port); + sr = readl_relaxed(port->membase + ofs->isr); + if (sr & USART_SR_ERR_MASK) { + /* Disable DMA request line */ + stm32_usart_clr_bits(port, ofs->cr3, USART_CR3_DMAR); + + /* Switch to PIO mode to handle the errors */ + stm32_usart_receive_chars_pio(port); + + /* Switch back to DMA mode */ + stm32_usart_set_bits(port, ofs->cr3, USART_CR3_DMAR); + } + } else { + /* Disable RX DMA */ + dmaengine_terminate_async(stm32_port->rx_ch); + stm32_usart_clr_bits(port, ofs->cr3, USART_CR3_DMAR); + /* Fall back to interrupt mode */ + dev_dbg(port->dev, "DMA error, fallback to irq mode\n"); + stm32_usart_receive_chars_pio(port); + } + } else { + stm32_usart_receive_chars_pio(port); + } if (irqflag) uart_unlock_and_check_sysrq_irqrestore(port, irqflag); @@ -373,6 +455,13 @@ static void stm32_usart_tx_interrupt_enable(struct uart_port *port) stm32_usart_set_bits(port, ofs->cr1, USART_CR1_TXEIE); } +static void stm32_usart_rx_dma_complete(void *arg) +{ + struct uart_port *port = arg; + + stm32_usart_receive_chars(port, true); +} + static void stm32_usart_tc_interrupt_enable(struct uart_port *port) { struct stm32_port *stm32_port = to_stm32_port(port); @@ -588,7 +677,12 @@ static irqreturn_t stm32_usart_interrupt(int irq, void *ptr) pm_wakeup_event(tport->tty->dev, 0); } - if ((sr & USART_SR_RXNE) && !(stm32_port->rx_ch)) + /* + * rx errors in dma mode has to be handled ASAP to avoid overrun as the DMA request + * line has been masked by HW and rx data are stacking in FIFO. + */ + if (((sr & USART_SR_RXNE) && !stm32_usart_rx_dma_enabled(port)) || + ((sr & USART_SR_ERR_MASK) && stm32_usart_rx_dma_enabled(port))) stm32_usart_receive_chars(port, false); if ((sr & USART_SR_TXE) && !(stm32_port->tx_ch)) { @@ -597,7 +691,7 @@ static irqreturn_t stm32_usart_interrupt(int irq, void *ptr) spin_unlock(&port->lock); } - if (stm32_port->rx_ch) + if (stm32_usart_rx_dma_enabled(port)) return IRQ_WAKE_THREAD; else return IRQ_HANDLED; @@ -903,9 +997,11 @@ static void stm32_usart_set_termios(struct uart_port *port, stm32_port->cr1_irq = USART_CR1_RTOIE; writel_relaxed(bits, port->membase + ofs->rtor); cr2 |= USART_CR2_RTOEN; - /* Not using dma, enable fifo threshold irq */ - if (!stm32_port->rx_ch) - stm32_port->cr3_irq = USART_CR3_RXFTIE; + /* + * Enable fifo threshold irq in two cases, either when there is no DMA, or when + * wake up over usart, from low power until the DMA gets re-enabled by resume. + */ + stm32_port->cr3_irq = USART_CR3_RXFTIE; } cr1 |= stm32_port->cr1_irq; @@ -968,8 +1064,16 @@ static void stm32_usart_set_termios(struct uart_port *port, if ((termios->c_cflag & CREAD) == 0) port->ignore_status_mask |= USART_SR_DUMMY_RX; - if (stm32_port->rx_ch) + if (stm32_port->rx_ch) { + /* + * Setup DMA to collect only valid data and enable error irqs. + * This also enables break reception when using DMA. + */ + cr1 |= USART_CR1_PEIE; + cr3 |= USART_CR3_EIE; cr3 |= USART_CR3_DMAR; + cr3 |= USART_CR3_DDRE; + } if (rs485conf->flags & SER_RS485_ENABLED) { stm32_usart_config_reg_rs485(&cr1, &cr3, @@ -1298,9 +1402,9 @@ static int stm32_usart_of_dma_rx_probe(struct stm32_port *stm32port, return -ENODEV; } - /* No callback as dma buffer is drained on usart interrupt */ - desc->callback = NULL; - desc->callback_param = NULL; + /* Set DMA callback */ + desc->callback = stm32_usart_rx_dma_complete; + desc->callback_param = port; /* Push current DMA transaction in the pending queue */ ret = dma_submit_error(dmaengine_submit(desc)); @@ -1464,6 +1568,7 @@ static int stm32_usart_serial_remove(struct platform_device *pdev) struct stm32_port *stm32_port = to_stm32_port(port); const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs; int err; + u32 cr3; pm_runtime_get_sync(&pdev->dev); err = uart_remove_one_port(&stm32_usart_driver, port); @@ -1474,7 +1579,12 @@ static int stm32_usart_serial_remove(struct platform_device *pdev) pm_runtime_set_suspended(&pdev->dev); pm_runtime_put_noidle(&pdev->dev); - stm32_usart_clr_bits(port, ofs->cr3, USART_CR3_DMAR); + stm32_usart_clr_bits(port, ofs->cr1, USART_CR1_PEIE); + cr3 = readl_relaxed(port->membase + ofs->cr3); + cr3 &= ~USART_CR3_EIE; + cr3 &= ~USART_CR3_DMAR; + cr3 &= ~USART_CR3_DDRE; + writel_relaxed(cr3, port->membase + ofs->cr3); if (stm32_port->tx_ch) { stm32_usart_of_dma_tx_remove(stm32_port, pdev); diff --git a/drivers/tty/serial/stm32-usart.h b/drivers/tty/serial/stm32-usart.h index ad6335155de2..852573e1a690 100644 --- a/drivers/tty/serial/stm32-usart.h +++ b/drivers/tty/serial/stm32-usart.h @@ -109,7 +109,7 @@ struct stm32_usart_info stm32h7_info = { /* USART_SR (F4) / USART_ISR (F7) */ #define USART_SR_PE BIT(0) #define USART_SR_FE BIT(1) -#define USART_SR_NF BIT(2) +#define USART_SR_NE BIT(2) /* F7 (NF for F4) */ #define USART_SR_ORE BIT(3) #define USART_SR_IDLE BIT(4) #define USART_SR_RXNE BIT(5) @@ -126,7 +126,8 @@ struct stm32_usart_info stm32h7_info = { #define USART_SR_SBKF BIT(18) /* F7 */ #define USART_SR_WUF BIT(20) /* H7 */ #define USART_SR_TEACK BIT(21) /* F7 */ -#define USART_SR_ERR_MASK (USART_SR_ORE | USART_SR_FE | USART_SR_PE) +#define USART_SR_ERR_MASK (USART_SR_ORE | USART_SR_NE | USART_SR_FE |\ + USART_SR_PE) /* Dummy bits */ #define USART_SR_DUMMY_RX BIT(16) @@ -246,9 +247,9 @@ struct stm32_usart_info stm32h7_info = { #define STM32_SERIAL_NAME "ttySTM" #define STM32_MAX_PORTS 8 -#define RX_BUF_L 200 /* dma rx buffer length */ -#define RX_BUF_P RX_BUF_L /* dma rx buffer period */ -#define TX_BUF_L 200 /* dma tx buffer length */ +#define RX_BUF_L 4096 /* dma rx buffer length */ +#define RX_BUF_P (RX_BUF_L / 2) /* dma rx buffer period */ +#define TX_BUF_L RX_BUF_L /* dma tx buffer length */ struct stm32_port { struct uart_port port; @@ -273,6 +274,7 @@ struct stm32_port { bool wakeup_src; int rdr_mask; /* receive data register mask */ struct mctrl_gpios *gpios; /* modem control gpios */ + struct dma_tx_state rx_dma_state; }; static struct stm32_port stm32_ports[STM32_MAX_PORTS]; -- 2.43.0

6 months, 1 week

2
1
0 0

FAILED: patch "[PATCH] mm: fix race between __split_huge_pmd_locked() and GUP-fast" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x 3a5a8d343e1cf96eb9971b17cbd4b832ab19b8e7 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024061320-handcart-crook-0519@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: 3a5a8d343e1c ("mm: fix race between __split_huge_pmd_locked() and GUP-fast") 4f83145721f3 ("mm: avoid unnecessary flush on change_huge_pmd()") c9fe66560bf2 ("mm/mprotect: do not flush when not required architecturally") 4a18419f71cd ("mm/mprotect: use mmu_gather") e346e6688c4a ("mm: thp: skip make PMD PROT_NONE if THP migration is not supported") f0953a1bbaca ("mm: fix typos in comments") e2db1a9aa381 ("kasan, mm: optimize kmalloc poisoning") 928501344fc6 ("kasan, mm: don't save alloc stacks twice") 2b8305260fb3 ("kfence, kasan: make KFENCE compatible with KASAN") 0ce20dd84089 ("mm: add Kernel Electric-Fence infrastructure") 41139aa4c3a3 ("mm/filemap: add mapping_seek_hole_data") a1ba9da8f0f9 ("mm/hugetlb.c: fix unnecessary address expansion of pmd sharing") 611806b4bf8d ("kasan: fix bug detection via ksize for HW_TAGS mode") 027b37b552f3 ("kasan: move _RET_IP_ to inline wrappers") 573a48092313 ("kasan: add match-all tag tests") f00748bfa024 ("kasan: prefix global functions with kasan_") dbf53f7597be ("mm/mprotect.c: optimize error detection in do_mprotect_pkey()") 96667f8a4382 ("mm: Close race in generic_access_phys") 97593cad003c ("kasan: sanitize objects when metadata doesn't fit") 1ef3133bd3b8 ("kasan: simplify assign_tag and set_tag calls") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 3a5a8d343e1cf96eb9971b17cbd4b832ab19b8e7 Mon Sep 17 00:00:00 2001 From: Ryan Roberts <ryan.roberts(a)arm.com> Date: Wed, 1 May 2024 15:33:10 +0100 Subject: [PATCH] mm: fix race between __split_huge_pmd_locked() and GUP-fast __split_huge_pmd_locked() can be called for a present THP, devmap or (non-present) migration entry. It calls pmdp_invalidate() unconditionally on the pmdp and only determines if it is present or not based on the returned old pmd. This is a problem for the migration entry case because pmd_mkinvalid(), called by pmdp_invalidate() must only be called for a present pmd. On arm64 at least, pmd_mkinvalid() will mark the pmd such that any future call to pmd_present() will return true. And therefore any lockless pgtable walker could see the migration entry pmd in this state and start interpretting the fields as if it were present, leading to BadThings (TM). GUP-fast appears to be one such lockless pgtable walker. x86 does not suffer the above problem, but instead pmd_mkinvalid() will corrupt the offset field of the swap entry within the swap pte. See link below for discussion of that problem. Fix all of this by only calling pmdp_invalidate() for a present pmd. And for good measure let's add a warning to all implementations of pmdp_invalidate[_ad](). I've manually reviewed all other pmdp_invalidate[_ad]() call sites and believe all others to be conformant. This is a theoretical bug found during code review. I don't have any test case to trigger it in practice. Link: https://lkml.kernel.org/r/20240501143310.1381675-1-ryan.roberts@arm.com Link: https://lore.kernel.org/all/0dd7827a-6334-439a-8fd0-43c98e6af22b@arm.com/ Fixes: 84c3fc4e9c56 ("mm: thp: check pmd migration entry in common path") Signed-off-by: Ryan Roberts <ryan.roberts(a)arm.com> Reviewed-by: Zi Yan <ziy(a)nvidia.com> Reviewed-by: Anshuman Khandual <anshuman.khandual(a)arm.com> Acked-by: David Hildenbrand <david(a)redhat.com> Cc: Andreas Larsson <andreas(a)gaisler.com> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Aneesh Kumar K.V <aneesh.kumar(a)kernel.org> Cc: Borislav Petkov (AMD) <bp(a)alien8.de> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Christian Borntraeger <borntraeger(a)linux.ibm.com> Cc: Christophe Leroy <christophe.leroy(a)csgroup.eu> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: "David S. Miller" <davem(a)davemloft.net> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Naveen N. Rao <naveen.n.rao(a)linux.ibm.com> Cc: Nicholas Piggin <npiggin(a)gmail.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Sven Schnelle <svens(a)linux.ibm.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Will Deacon <will(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/Documentation/mm/arch_pgtable_helpers.rst b/Documentation/mm/arch_pgtable_helpers.rst index 2466d3363af7..ad50ca6f495e 100644 --- a/Documentation/mm/arch_pgtable_helpers.rst +++ b/Documentation/mm/arch_pgtable_helpers.rst @@ -140,7 +140,8 @@ PMD Page Table Helpers +---------------------------+--------------------------------------------------+ | pmd_swp_clear_soft_dirty | Clears a soft dirty swapped PMD | +---------------------------+--------------------------------------------------+ -| pmd_mkinvalid | Invalidates a mapped PMD [1] | +| pmd_mkinvalid | Invalidates a present PMD; do not call for | +| | non-present PMD [1] | +---------------------------+--------------------------------------------------+ | pmd_set_huge | Creates a PMD huge mapping | +---------------------------+--------------------------------------------------+ @@ -196,7 +197,8 @@ PUD Page Table Helpers +---------------------------+--------------------------------------------------+ | pud_mkdevmap | Creates a ZONE_DEVICE mapped PUD | +---------------------------+--------------------------------------------------+ -| pud_mkinvalid | Invalidates a mapped PUD [1] | +| pud_mkinvalid | Invalidates a present PUD; do not call for | +| | non-present PUD [1] | +---------------------------+--------------------------------------------------+ | pud_set_huge | Creates a PUD huge mapping | +---------------------------+--------------------------------------------------+ diff --git a/arch/powerpc/mm/book3s64/pgtable.c b/arch/powerpc/mm/book3s64/pgtable.c index 83823db3488b..2975ea0841ba 100644 --- a/arch/powerpc/mm/book3s64/pgtable.c +++ b/arch/powerpc/mm/book3s64/pgtable.c @@ -170,6 +170,7 @@ pmd_t pmdp_invalidate(struct vm_area_struct *vma, unsigned long address, { unsigned long old_pmd; + VM_WARN_ON_ONCE(!pmd_present(*pmdp)); old_pmd = pmd_hugepage_update(vma->vm_mm, address, pmdp, _PAGE_PRESENT, _PAGE_INVALID); flush_pmd_tlb_range(vma, address, address + HPAGE_PMD_SIZE); return __pmd(old_pmd); diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h index 2cb2a2e7b34b..558902edbfec 100644 --- a/arch/s390/include/asm/pgtable.h +++ b/arch/s390/include/asm/pgtable.h @@ -1769,8 +1769,10 @@ static inline pmd_t pmdp_huge_clear_flush(struct vm_area_struct *vma, static inline pmd_t pmdp_invalidate(struct vm_area_struct *vma, unsigned long addr, pmd_t *pmdp) { - pmd_t pmd = __pmd(pmd_val(*pmdp) | _SEGMENT_ENTRY_INVALID); + pmd_t pmd; + VM_WARN_ON_ONCE(!pmd_present(*pmdp)); + pmd = __pmd(pmd_val(*pmdp) | _SEGMENT_ENTRY_INVALID); return pmdp_xchg_direct(vma->vm_mm, addr, pmdp, pmd); } diff --git a/arch/sparc/mm/tlb.c b/arch/sparc/mm/tlb.c index 19642f7ffb52..8648a50afe88 100644 --- a/arch/sparc/mm/tlb.c +++ b/arch/sparc/mm/tlb.c @@ -249,6 +249,7 @@ pmd_t pmdp_invalidate(struct vm_area_struct *vma, unsigned long address, { pmd_t old, entry; + VM_WARN_ON_ONCE(!pmd_present(*pmdp)); entry = __pmd(pmd_val(*pmdp) & ~_PAGE_VALID); old = pmdp_establish(vma, address, pmdp, entry); flush_tlb_range(vma, address, address + HPAGE_PMD_SIZE); diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c index 94767c82fc0d..93e54ba91fbf 100644 --- a/arch/x86/mm/pgtable.c +++ b/arch/x86/mm/pgtable.c @@ -631,6 +631,8 @@ int pmdp_clear_flush_young(struct vm_area_struct *vma, pmd_t pmdp_invalidate_ad(struct vm_area_struct *vma, unsigned long address, pmd_t *pmdp) { + VM_WARN_ON_ONCE(!pmd_present(*pmdp)); + /* * No flush is necessary. Once an invalid PTE is established, the PTE's * access and dirty bits cannot be updated. diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 08e4f3343bcd..ccdcff73284a 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -2430,32 +2430,11 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd, return __split_huge_zero_page_pmd(vma, haddr, pmd); } - /* - * Up to this point the pmd is present and huge and userland has the - * whole access to the hugepage during the split (which happens in - * place). If we overwrite the pmd with the not-huge version pointing - * to the pte here (which of course we could if all CPUs were bug - * free), userland could trigger a small page size TLB miss on the - * small sized TLB while the hugepage TLB entry is still established in - * the huge TLB. Some CPU doesn't like that. - * See http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf, Erratum - * 383 on page 105. Intel should be safe but is also warns that it's - * only safe if the permission and cache attributes of the two entries - * loaded in the two TLB is identical (which should be the case here). - * But it is generally safer to never allow small and huge TLB entries - * for the same virtual address to be loaded simultaneously. So instead - * of doing "pmd_populate(); flush_pmd_tlb_range();" we first mark the - * current pmd notpresent (atomically because here the pmd_trans_huge - * must remain set at all times on the pmd until the split is complete - * for this pmd), then we flush the SMP TLB and finally we write the - * non-huge version of the pmd entry with pmd_populate. - */ - old_pmd = pmdp_invalidate(vma, haddr, pmd); - - pmd_migration = is_pmd_migration_entry(old_pmd); + pmd_migration = is_pmd_migration_entry(*pmd); if (unlikely(pmd_migration)) { swp_entry_t entry; + old_pmd = *pmd; entry = pmd_to_swp_entry(old_pmd); page = pfn_swap_entry_to_page(entry); write = is_writable_migration_entry(entry); @@ -2466,6 +2445,30 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd, soft_dirty = pmd_swp_soft_dirty(old_pmd); uffd_wp = pmd_swp_uffd_wp(old_pmd); } else { + /* + * Up to this point the pmd is present and huge and userland has + * the whole access to the hugepage during the split (which + * happens in place). If we overwrite the pmd with the not-huge + * version pointing to the pte here (which of course we could if + * all CPUs were bug free), userland could trigger a small page + * size TLB miss on the small sized TLB while the hugepage TLB + * entry is still established in the huge TLB. Some CPU doesn't + * like that. See + * http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf, Erratum + * 383 on page 105. Intel should be safe but is also warns that + * it's only safe if the permission and cache attributes of the + * two entries loaded in the two TLB is identical (which should + * be the case here). But it is generally safer to never allow + * small and huge TLB entries for the same virtual address to be + * loaded simultaneously. So instead of doing "pmd_populate(); + * flush_pmd_tlb_range();" we first mark the current pmd + * notpresent (atomically because here the pmd_trans_huge must + * remain set at all times on the pmd until the split is + * complete for this pmd), then we flush the SMP TLB and finally + * we write the non-huge version of the pmd entry with + * pmd_populate. + */ + old_pmd = pmdp_invalidate(vma, haddr, pmd); page = pmd_page(old_pmd); folio = page_folio(page); if (pmd_dirty(old_pmd)) { diff --git a/mm/pgtable-generic.c b/mm/pgtable-generic.c index 4fcd959dcc4d..a78a4adf711a 100644 --- a/mm/pgtable-generic.c +++ b/mm/pgtable-generic.c @@ -198,6 +198,7 @@ pgtable_t pgtable_trans_huge_withdraw(struct mm_struct *mm, pmd_t *pmdp) pmd_t pmdp_invalidate(struct vm_area_struct *vma, unsigned long address, pmd_t *pmdp) { + VM_WARN_ON_ONCE(!pmd_present(*pmdp)); pmd_t old = pmdp_establish(vma, address, pmdp, pmd_mkinvalid(*pmdp)); flush_pmd_tlb_range(vma, address, address + HPAGE_PMD_SIZE); return old; @@ -208,6 +209,7 @@ pmd_t pmdp_invalidate(struct vm_area_struct *vma, unsigned long address, pmd_t pmdp_invalidate_ad(struct vm_area_struct *vma, unsigned long address, pmd_t *pmdp) { + VM_WARN_ON_ONCE(!pmd_present(*pmdp)); return pmdp_invalidate(vma, address, pmdp); } #endif

6 months, 1 week

3
2
0 0

Re: Patch "netfilter: Remove the now superfluous sentinel elements from ctl_table array" has been added to the 6.6-stable tree

by Joel Granados

On Sat, Jun 22, 2024 at 07:45:37PM -0400, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > netfilter: Remove the now superfluous sentinel elements from ctl_table array > > to the 6.6-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > netfilter-remove-the-now-superfluous-sentinel-elemen.patch > and it can be found in the queue-6.6 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. I don't understand why we are putting these in stable. IMO, they should not go there and this is why: 1. This is not a fix. The main motivation for doing these sentinel removals is to avoid bloat in the boot and compiled image (read more in cover letters for [1,2,3,4,5,6]) in future kernel versions. This makes no sense in stable IMO. 2. There are lots of moving parts and no "bang for the buck" If you are going to bring one of them, you need to bring all of them. This means brining in the preparation [7], the intermediate [1,2,3,4,5,6] and the final patch [8]. This is not only prone to error, but there is no real reason to do that in stable. If I'm missing something, please let me know. Best Joel [1] https://git.kernel.org/pub/scm/linux/kernel/git/joel.granados/linux.git/log… [2] https://git.kernel.org/pub/scm/linux/kernel/git/joel.granados/linux.git/log… [3] https://git.kernel.org/pub/scm/linux/kernel/git/joel.granados/linux.git/log… [4] https://git.kernel.org/pub/scm/linux/kernel/git/joel.granados/linux.git/log… [5] https://git.kernel.org/pub/scm/linux/kernel/git/joel.granados/linux.git/log… [6] https://git.kernel.org/pub/scm/linux/kernel/git/joel.granados/linux.git/log… [7] https://lore.kernel.org/20230731071728.3493794-1-j.granados@samsung.com [8] https://lore.kernel.org/20240604-jag-sysctl_remset-v1-0-2df7ecdba0bd@samsun…

6 months, 1 week

2
1
0 0

[PATCH] arm64: defconfig: enable the vf610 gpio driver

by Fabio Estevam

From: Martin Kaiser <martin(a)kaiser.cx> commit a73bda63a102a5f1feb730d4d809de098a3d1886 upstream. The vf610 gpio driver is used in i.MX8QM, DXL, ULP and i.MX93 chips. Enable it in arm64 defconfig. (vf610 gpio used to be enabled by default for all i.MX chips. This was changed recently as most i.MX chips don't need this driver.) Cc: <stable(a)vger.kernel.org> # 6.6.x Signed-off-by: Martin Kaiser <martin(a)kaiser.cx> Signed-off-by: Shawn Guo <shawnguo(a)kernel.org> Signed-off-by: Fabio Estevam <festevam(a)gmail.com> --- Hi, This fixes a boot regression on imx93-evk running 6.6.32. Please apply it to the 6.6.y stable tree. arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 24f395d9ce2a36..9f82eb906a8a34 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -632,6 +632,7 @@ CONFIG_GPIO_SYSCON=y CONFIG_GPIO_UNIPHIER=y CONFIG_GPIO_VISCONTI=y CONFIG_GPIO_WCD934X=m +CONFIG_GPIO_VF610=y CONFIG_GPIO_XGENE=y CONFIG_GPIO_XGENE_SB=y CONFIG_GPIO_MAX732X=y

6 months, 1 week

2
2
0 0

FAILED: patch "[PATCH] kbuild: Remove support for Clang's ThinLTO caching" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x aba091547ef6159d52471f42a3ef531b7b660ed8 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024061340-troubling-automated-9989@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: aba091547ef6 ("kbuild: Remove support for Clang's ThinLTO caching") 1db773da58df ("kbuild: remove old Rust docs output path") 7ea01d3169a2 ("rust: delete rust-project.json when running make clean") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From aba091547ef6159d52471f42a3ef531b7b660ed8 Mon Sep 17 00:00:00 2001 From: Nathan Chancellor <nathan(a)kernel.org> Date: Wed, 1 May 2024 15:55:25 -0700 Subject: [PATCH] kbuild: Remove support for Clang's ThinLTO caching MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit There is an issue in clang's ThinLTO caching (enabled for the kernel via '--thinlto-cache-dir') with .incbin, which the kernel occasionally uses to include data within the kernel, such as the .config file for /proc/config.gz. For example, when changing the .config and rebuilding vmlinux, the copy of .config in vmlinux does not match the copy of .config in the build folder: $ echo 'CONFIG_LTO_NONE=n CONFIG_LTO_CLANG_THIN=y CONFIG_IKCONFIG=y CONFIG_HEADERS_INSTALL=y' >kernel/configs/repro.config $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 clean defconfig repro.config vmlinux ... $ grep CONFIG_HEADERS_INSTALL .config CONFIG_HEADERS_INSTALL=y $ scripts/extract-ikconfig vmlinux | grep CONFIG_HEADERS_INSTALL CONFIG_HEADERS_INSTALL=y $ scripts/config -d HEADERS_INSTALL $ make -kj"$(nproc)" ARCH=x86_64 LLVM=1 vmlinux ... UPD kernel/config_data GZIP kernel/config_data.gz CC kernel/configs.o ... LD vmlinux ... $ grep CONFIG_HEADERS_INSTALL .config # CONFIG_HEADERS_INSTALL is not set $ scripts/extract-ikconfig vmlinux | grep CONFIG_HEADERS_INSTALL CONFIG_HEADERS_INSTALL=y Without '--thinlto-cache-dir' or when using full LTO, this issue does not occur. Benchmarking incremental builds on a few different machines with and without the cache shows a 20% increase in incremental build time without the cache when measured by touching init/main.c and running 'make all'. ARCH=arm64 defconfig + CONFIG_LTO_CLANG_THIN=y on an arm64 host: Benchmark 1: With ThinLTO cache Time (mean ± σ): 56.347 s ± 0.163 s [User: 83.768 s, System: 24.661 s] Range (min … max): 56.109 s … 56.594 s 10 runs Benchmark 2: Without ThinLTO cache Time (mean ± σ): 67.740 s ± 0.479 s [User: 718.458 s, System: 31.797 s] Range (min … max): 67.059 s … 68.556 s 10 runs Summary With ThinLTO cache ran 1.20 ± 0.01 times faster than Without ThinLTO cache ARCH=x86_64 defconfig + CONFIG_LTO_CLANG_THIN=y on an x86_64 host: Benchmark 1: With ThinLTO cache Time (mean ± σ): 85.772 s ± 0.252 s [User: 91.505 s, System: 8.408 s] Range (min … max): 85.447 s … 86.244 s 10 runs Benchmark 2: Without ThinLTO cache Time (mean ± σ): 103.833 s ± 0.288 s [User: 232.058 s, System: 8.569 s] Range (min … max): 103.286 s … 104.124 s 10 runs Summary With ThinLTO cache ran 1.21 ± 0.00 times faster than Without ThinLTO cache While it is unfortunate to take this performance improvement off the table, correctness is more important. If/when this is fixed in LLVM, it can potentially be brought back in a conditional manner. Alternatively, a developer can just disable LTO if doing incremental compiles quickly is important, as a full compile cycle can still take over a minute even with the cache and it is unlikely that LTO will result in functional differences for a kernel change. Cc: stable(a)vger.kernel.org Fixes: dc5723b02e52 ("kbuild: add support for Clang LTO") Reported-by: Yifan Hong <elsk(a)google.com> Closes: https://github.com/ClangBuiltLinux/linux/issues/2021 Reported-by: Masami Hiramatsu <mhiramat(a)kernel.org> Closes: https://lore.kernel.org/r/20220327115526.cc4b0ff55fc53c97683c3e4d@kernel.or… Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> Signed-off-by: Masahiro Yamada <masahiroy(a)kernel.org> diff --git a/Makefile b/Makefile index 026971f9f6bc..12e1a792b8de 100644 --- a/Makefile +++ b/Makefile @@ -942,7 +942,6 @@ endif ifdef CONFIG_LTO_CLANG ifdef CONFIG_LTO_CLANG_THIN CC_FLAGS_LTO := -flto=thin -fsplit-lto-unit -KBUILD_LDFLAGS += --thinlto-cache-dir=$(extmod_prefix).thinlto-cache else CC_FLAGS_LTO := -flto endif @@ -1480,7 +1479,7 @@ endif # CONFIG_MODULES # Directories & files removed with 'make clean' CLEAN_FILES += vmlinux.symvers modules-only.symvers \ modules.builtin modules.builtin.modinfo modules.nsdeps \ - compile_commands.json .thinlto-cache rust/test \ + compile_commands.json rust/test \ rust-project.json .vmlinux.objs .vmlinux.export.c # Directories & files removed with 'make mrproper' @@ -1787,7 +1786,7 @@ PHONY += compile_commands.json clean-dirs := $(KBUILD_EXTMOD) clean: rm-files := $(KBUILD_EXTMOD)/Module.symvers $(KBUILD_EXTMOD)/modules.nsdeps \ - $(KBUILD_EXTMOD)/compile_commands.json $(KBUILD_EXTMOD)/.thinlto-cache + $(KBUILD_EXTMOD)/compile_commands.json PHONY += prepare # now expand this into a simple variable to reduce the cost of shell evaluations

6 months, 1 week

3
4
0 0

Re: Patch "ACPI: EC: Install address space handler at the namespace root" has been added to the 6.6-stable tree

by Wysocki, Rafael J

On 6/21/2024 5:47 PM, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > ACPI: EC: Install address space handler at the namespace root For this, you need https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/… too (here and for 6.9). Thanks! > to the 6.6-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > acpi-ec-install-address-space-handler-at-the-namespa.patch > and it can be found in the queue-6.6 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit ee44236dfbf5541d5fbcb52db961616292c84c0d > Author: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> > Date: Wed May 15 21:40:54 2024 +0200 > > ACPI: EC: Install address space handler at the namespace root > > [ Upstream commit 60fa6ae6e6d09e377fce6f8d9b6f6a4d88769f63 ] > > It is reported that _DSM evaluation fails in ucsi_acpi_dsm() on Lenovo > IdeaPad Pro 5 due to a missing address space handler for the EC address > space: > > ACPI Error: No handler for Region [ECSI] (000000007b8176ee) [EmbeddedControl] (20230628/evregion-130) > > This happens because if there is no ECDT, the EC driver only registers > the EC address space handler for operation regions defined in the EC > device scope of the ACPI namespace while the operation region being > accessed by the _DSM in question is located beyond that scope. > > To address this, modify the ACPI EC driver to install the EC address > space handler at the root of the ACPI namespace for the first EC that > can be found regardless of whether or not an ECDT is present. > > Note that this change is consistent with some examples in the ACPI > specification in which EC operation regions located outside the EC > device scope are used (for example, see Section 9.17.15 in ACPI 6.5), > so the current behavior of the EC driver is arguably questionable. > > Reported-by: webcaptcha <webcapcha(a)gmail.com> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=218789 > Link: https://uefi.org/specs/ACPI/6.5/09_ACPI_Defined_Devices_and_Device_Specific… > Link: https://lore.kernel.org/linux-acpi/Zi+0whTvDbAdveHq@kuha.fi.intel.com > Suggested-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> > Reviewed-by: Hans de Goede <hdegoede(a)redhat.com> > Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com> > Reviewed-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c > index a59c11df73754..0795f92d8927d 100644 > --- a/drivers/acpi/ec.c > +++ b/drivers/acpi/ec.c > @@ -1482,13 +1482,14 @@ static bool install_gpio_irq_event_handler(struct acpi_ec *ec) > static int ec_install_handlers(struct acpi_ec *ec, struct acpi_device *device, > bool call_reg) > { > + acpi_handle scope_handle = ec == first_ec ? ACPI_ROOT_OBJECT : ec->handle; > acpi_status status; > > acpi_ec_start(ec, false); > > if (!test_bit(EC_FLAGS_EC_HANDLER_INSTALLED, &ec->flags)) { > acpi_ec_enter_noirq(ec); > - status = acpi_install_address_space_handler_no_reg(ec->handle, > + status = acpi_install_address_space_handler_no_reg(scope_handle, > ACPI_ADR_SPACE_EC, > &acpi_ec_space_handler, > NULL, ec); > @@ -1497,11 +1498,10 @@ static int ec_install_handlers(struct acpi_ec *ec, struct acpi_device *device, > return -ENODEV; > } > set_bit(EC_FLAGS_EC_HANDLER_INSTALLED, &ec->flags); > - ec->address_space_handler_holder = ec->handle; > } > > if (call_reg && !test_bit(EC_FLAGS_EC_REG_CALLED, &ec->flags)) { > - acpi_execute_reg_methods(ec->handle, ACPI_ADR_SPACE_EC); > + acpi_execute_reg_methods(scope_handle, ACPI_ADR_SPACE_EC); > set_bit(EC_FLAGS_EC_REG_CALLED, &ec->flags); > } > > @@ -1553,10 +1553,13 @@ static int ec_install_handlers(struct acpi_ec *ec, struct acpi_device *device, > > static void ec_remove_handlers(struct acpi_ec *ec) > { > + acpi_handle scope_handle = ec == first_ec ? ACPI_ROOT_OBJECT : ec->handle; > + > if (test_bit(EC_FLAGS_EC_HANDLER_INSTALLED, &ec->flags)) { > if (ACPI_FAILURE(acpi_remove_address_space_handler( > - ec->address_space_handler_holder, > - ACPI_ADR_SPACE_EC, &acpi_ec_space_handler))) > + scope_handle, > + ACPI_ADR_SPACE_EC, > + &acpi_ec_space_handler))) > pr_err("failed to remove space handler\n"); > clear_bit(EC_FLAGS_EC_HANDLER_INSTALLED, &ec->flags); > } > @@ -1595,14 +1598,18 @@ static int acpi_ec_setup(struct acpi_ec *ec, struct acpi_device *device, bool ca > { > int ret; > > - ret = ec_install_handlers(ec, device, call_reg); > - if (ret) > - return ret; > - > /* First EC capable of handling transactions */ > if (!first_ec) > first_ec = ec; > > + ret = ec_install_handlers(ec, device, call_reg); > + if (ret) { > + if (ec == first_ec) > + first_ec = NULL; > + > + return ret; > + } > + > pr_info("EC_CMD/EC_SC=0x%lx, EC_DATA=0x%lx\n", ec->command_addr, > ec->data_addr); > > diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h > index 866c7c4ed2331..6db1a03dd5399 100644 > --- a/drivers/acpi/internal.h > +++ b/drivers/acpi/internal.h > @@ -167,7 +167,6 @@ enum acpi_ec_event_state { > > struct acpi_ec { > acpi_handle handle; > - acpi_handle address_space_handler_holder; > int gpe; > int irq; > unsigned long command_addr;

6 months, 1 week

2
1
0 0

Re: Patch "ASoC: Intel: sof_cs42l42: rename BT offload quirk" has been added to the 6.9-stable tree

by Mark Brown

On Fri, Jun 21, 2024 at 11:42:01AM -0400, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > ASoC: Intel: sof_cs42l42: rename BT offload quirk This is not obvious stable material. > > Reviewed-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> > Signed-off-by: Brent Lu <brent.lu(a)intel.com> > Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> > Link: https://msgid.link/r/20240325221059.206042-7-pierre-louis.bossart@linux.int… > Signed-off-by: Mark Brown <broonie(a)kernel.org> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> I'm also not seeing any stable-dep-of r anything in here.

6 months, 1 week

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2024