From: Cynthia Huang cynthia@andestech.com

[ Upstream commit 04850819c65c8242072818655d4341e70ae998b5 ]

The kernel does not provide sys_futex() on 32-bit architectures that do not support 32-bit time representations, such as riscv32.

As a result, glibc cannot define SYS_futex, causing compilation failures in tests that rely on this syscall. Define SYS_futex as SYS_futex_time64 in such cases to ensure successful compilation and compatibility.

Signed-off-by: Cynthia Huang cynthia@andestech.com Signed-off-by: Ben Zong-You Xie ben717@andestech.com Signed-off-by: Thomas Gleixner tglx@linutronix.de Reviewed-by: Muhammad Usama Anjum usama.anjum@collabora.com Link: https://lore.kernel.org/all/20250710103630.3156130-1-ben717@andestech.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

This commit should be backported to stable kernel trees for the following reasons:

1. **Fixes a real compilation failure bug**: The commit addresses a build failure in kernel selftests on 32-bit architectures with 64-bit time_t, specifically riscv32. This prevents the futex selftests from compiling on these architectures, which is a functional bug that affects testing infrastructure.

2. **Simple and contained fix**: The change is minimal - it only adds a conditional preprocessor definition that maps `SYS_futex` to `SYS_futex_time64` when the former is not defined but the latter is. The fix is: ```c #if !defined(SYS_futex) && defined(SYS_futex_time64) #define SYS_futex SYS_futex_time64 #endif ```

3. **No risk of regression**: The change is guarded by preprocessor conditionals that only activate when `SYS_futex` is not defined AND `SYS_futex_time64` is defined. This means it has zero impact on architectures where `SYS_futex` is already defined, ensuring no regressions on existing systems.

4. **Affects kernel testing infrastructure**: While this is in the selftests directory and not core kernel code, having working selftests is critical for kernel stability and quality assurance. The futex selftests are important for validating futex functionality across different architectures.

5. **Addresses Y2038 compatibility**: This fix is part of the broader Y2038 compatibility effort where 32-bit architectures are transitioning to 64-bit time_t. As more 32-bit architectures adopt 64-bit time_t, this fix becomes increasingly important.

6. **Clear problem and solution**: The commit message clearly explains the issue (glibc cannot define SYS_futex on certain architectures) and provides a clean solution that maintains compatibility.

The fix follows stable kernel rules by being a minimal change that fixes an important bug without introducing new features or architectural changes. It's confined to the testing infrastructure and has clear boundaries with no side effects beyond enabling compilation of the futex selftests on affected architectures.

tools/testing/selftests/futex/include/futextest.h | 11 +++++++++++ 1 file changed, 11 insertions(+)

diff --git a/tools/testing/selftests/futex/include/futextest.h b/tools/testing/selftests/futex/include/futextest.h index ddbcfc9b7bac..7a5fd1d5355e 100644 --- a/tools/testing/selftests/futex/include/futextest.h +++ b/tools/testing/selftests/futex/include/futextest.h @@ -47,6 +47,17 @@ typedef volatile u_int32_t futex_t; FUTEX_PRIVATE_FLAG) #endif

+/* + * SYS_futex is expected from system C library, in glibc some 32-bit + * architectures (e.g. RV32) are using 64-bit time_t, therefore it doesn't have + * SYS_futex defined but just SYS_futex_time64. Define SYS_futex as + * SYS_futex_time64 in this situation to ensure the compilation and the + * compatibility. + */ +#if !defined(SYS_futex) && defined(SYS_futex_time64) +#define SYS_futex SYS_futex_time64 +#endif + /** * futex() - SYS_futex syscall wrapper * @uaddr: address of first futex

From: Romain Gantois romain.gantois@bootlin.com

[ Upstream commit d511206dc7443120637efd9cfa3ab06a26da33dd ]

The regulator_set_voltage() function may exhibit unexpected behavior if the target regulator has a maximum voltage step constraint. With such a constraint, the regulator core may clamp the requested voltage to a lesser value, to ensure that the voltage delta stays under the specified limit.

This means that the resulting regulator voltage depends on the current voltage, as well as the requested range, which invalidates the assumption that a repeated request for a specific voltage range will amount to a noop.

Considering the case of a regulator with a maximum voltage step constraint of 1V:

initial voltage: 2.5V

consumer requests 4V expected result: 3.5V resulting voltage: 3.5V

consumer requests 4V again expected result: 4V actual result: 3.5V

Correct this by repeating attempts to balance the regulator voltage until the result converges.

Signed-off-by: Romain Gantois romain.gantois@bootlin.com Link: https://patch.msgid.link/20250718-regulator-stepping-v2-1-e28c9ac5d54a@bootl... Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

This commit fixes a legitimate bug in the voltage regulator subsystem that affects users with stepped voltage regulators. Here's my extensive analysis:

## Bug Description and Impact

The commit addresses a bug where regulators with `max_uV_step` constraints fail to reach their target voltage when the same voltage range is requested multiple times. The bug manifests as follows:

1. When a regulator has a maximum voltage step constraint (e.g., 1V), the core limits each voltage change to stay within this step 2. The optimization at line 3814 (`if (voltage->min_uV == min_uV && voltage->max_uV == max_uV) goto out;`) assumes repeated requests are no-ops 3. This creates a situation where requesting 4V twice from 2.5V only reaches 3.5V, not the desired 4V

## Code Analysis

The fix adds a retry mechanism specifically for stepped regulators:

1. **New helper function** `regulator_get_voltage_delta()` (lines 3800-3808): Calculates the absolute difference between current and target voltage 2. **Retry loop** (lines 3865-3893): After the initial voltage setting, if `max_uV_step` is configured, it: - Checks if we've reached the target voltage (delta > 0) - Repeatedly calls `regulator_balance_voltage()` until convergence - Includes convergence protection to avoid infinite loops (line 3888)

## Why This Is a Good Backport Candidate

1. **Fixes a real bug**: Users with stepped voltage regulators cannot reach target voltages, potentially causing system instability or device malfunction 2. **Minimal invasive changes**: The fix is well-contained within `regulator_set_voltage_unlocked()` and only affects regulators with `max_uV_step` constraints 3. **No API/ABI changes**: Only internal implementation changes, no external interfaces modified 4. **Clear regression potential**: Low risk as the new code only executes for regulators with `max_uV_step` set 5. **Safety checks included**: The convergence check prevents infinite loops (`if (new_delta - delta > rdev->constraints->max_uV_step)`)

## Specific Code References

- The bug is in the optimization at drivers/regulator/core.c:3814-3815 - The fix adds retry logic at drivers/regulator/core.c:3865-3893 - Only affects regulators where `rdev->constraints->max_uV_step > 0` - The existing `regulator_limit_voltage_step()` function already handles the step limiting logic

This is exactly the type of fix that belongs in stable: it addresses a specific functional bug without introducing new features or architectural changes.

drivers/regulator/core.c | 43 +++++++++++++++++++++++++++++++++++++++- 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 18f13b9601b5..5e5d04dddcc1 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -3721,6 +3721,16 @@ static int _regulator_do_set_suspend_voltage(struct regulator_dev *rdev, return 0; }

+static int regulator_get_voltage_delta(struct regulator_dev *rdev, int uV) +{ + int current_uV = regulator_get_voltage_rdev(rdev); + + if (current_uV < 0) + return current_uV; + + return abs(current_uV - uV); +} + static int regulator_set_voltage_unlocked(struct regulator *regulator, int min_uV, int max_uV, suspend_state_t state) @@ -3728,8 +3738,8 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator, struct regulator_dev *rdev = regulator->rdev; struct regulator_voltage *voltage = &regulator->voltage[state]; int ret = 0; + int current_uV, delta, new_delta; int old_min_uV, old_max_uV; - int current_uV;

/* If we're setting the same range as last time the change * should be a noop (some cpufreq implementations use the same @@ -3776,6 +3786,37 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator, voltage->max_uV = old_max_uV; }

+ if (rdev->constraints->max_uV_step > 0) { + /* For regulators with a maximum voltage step, reaching the desired + * voltage might take a few retries. + */ + ret = regulator_get_voltage_delta(rdev, min_uV); + if (ret < 0) + goto out; + + delta = ret; + + while (delta > 0) { + ret = regulator_balance_voltage(rdev, state); + if (ret < 0) + goto out; + + ret = regulator_get_voltage_delta(rdev, min_uV); + if (ret < 0) + goto out; + + new_delta = ret; + + /* check that voltage is converging quickly enough */ + if (new_delta - delta > rdev->constraints->max_uV_step) { + ret = -EWOULDBLOCK; + goto out; + } + + delta = new_delta; + } + } + out: return ret; }

From: Jay Chen shawn2000100@gmail.com

[ Upstream commit f72b9aa821a2bfe4b6dfec4be19f264d0673b008 ]

There is a subtle contradiction between sections of the xHCI 1.2 spec regarding the initialization of Input Endpoint Context fields. Section 4.8.2 ("Endpoint Context Initialization") states that all fields should be initialized to 0. However, Section 6.2.3 ("Endpoint Context", p.453) specifies that the Average TRB Length (avg_trb_len) field shall be greater than 0, and explicitly notes (p.454): "Software shall set Average TRB Length to '8' for control endpoints."

Strictly setting all fields to 0 during initialization conflicts with the specific recommendation for control endpoints. In practice, setting avg_trb_len = 0 is not meaningful for the hardware/firmware, as the value is used for bandwidth calculation.

Motivation: Our company is developing a custom Virtual xHC hardware platform that strictly follows the xHCI spec and its recommendations. During validation, we observed that enumeration fails and a parameter error (TRB Completion Code = 5) is reported if avg_trb_len for EP0 is not set to 8 as recommended by Section 6.2.3. This demonstrates the importance of assigning a meaningful, non-zero value to avg_trb_len, even in virtualized or emulated environments.

This patch explicitly sets avg_trb_len to 8 for EP0 in xhci_setup_addressable_virt_dev(), as recommended in Section 6.2.3, to prevent potential issues with xHCI host controllers that enforce the spec strictly.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=220033 Signed-off-by: Jay Chen shawn2000100@gmail.com Signed-off-by: Mathias Nyman mathias.nyman@linux.intel.com Link: https://lore.kernel.org/r/20250717073107.488599-4-mathias.nyman@linux.intel.... Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

Based on my analysis of the commit and code, here's my assessment:

**Backport Status: YES**

This commit should be backported to stable kernel trees for the following reasons:

1. **Fixes a real bug**: The commit addresses a specification compliance issue where setting `avg_trb_len = 0` for EP0 (control endpoint) violates the xHCI 1.2 specification. Section 6.2.3 explicitly states that Average TRB Length shall be greater than 0 and specifically recommends setting it to 8 for control endpoints.

2. **Small and contained fix**: The change is minimal - just adding a single line: ```c ep0_ctx->tx_info = cpu_to_le32(EP_AVG_TRB_LENGTH(8)); ``` This sets the average TRB length field to 8 as recommended by the spec.

3. **Prevents hardware failures**: The commit message indicates this causes actual enumeration failures with parameter errors (TRB Completion Code = 5) on hardware that strictly follows the xHCI specification. This means real devices can fail to enumerate without this fix.

4. **No architectural changes**: This is a simple initialization fix that doesn't change any architectural aspects of the driver. It only ensures proper initialization of a field that was previously left at 0.

5. **Low regression risk**: Setting avg_trb_len to 8 for control endpoints follows the xHCI specification recommendation. Existing hardware that doesn't strictly check this value will continue to work, while hardware that does enforce the spec will now work correctly.

6. **Clear bug with clear fix**: The contradiction between spec sections is well-documented in the commit message, and the fix directly addresses this by following the more specific recommendation for control endpoints.

The commit fixes a specification compliance bug that can cause real hardware failures during USB device enumeration. The fix is minimal, follows the xHCI specification, and has very low risk of causing regressions, making it an ideal candidate for stable backporting.

drivers/usb/host/xhci-mem.c | 2 ++ 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c index 149128b89100..43cbaadf933d 100644 --- a/drivers/usb/host/xhci-mem.c +++ b/drivers/usb/host/xhci-mem.c @@ -1209,6 +1209,8 @@ int xhci_setup_addressable_virt_dev(struct xhci_hcd *xhci, struct usb_device *ud ep0_ctx->deq = cpu_to_le64(dev->eps[0].ring->first_seg->dma | dev->eps[0].ring->cycle_state);

+ ep0_ctx->tx_info = cpu_to_le32(EP_AVG_TRB_LENGTH(8)); + trace_xhci_setup_addressable_virt_device(dev);

/* Steps 7 and 8 were done in xhci_alloc_virt_device() */

From: Bartosz Golaszewski bartosz.golaszewski@linaro.org

[ Upstream commit ff0f0d7c6587e38c308be9905e36f86e98fb9c1f ]

regmap_update_bits() can fail so check its return value in wcd_gpio_direction_output() for consistency with the rest of the code and propagate any errors.

Link: https://lore.kernel.org/r/20250709-gpiochip-set-rv-gpio-remaining-v1-2-b8950... Signed-off-by: Bartosz Golaszewski bartosz.golaszewski@linaro.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

Based on my analysis, here's my determination:

**YES**

This commit should be backported to stable kernel trees for the following reasons:

1. **It fixes a real bug**: The `wcd_gpio_direction_output()` function in drivers/gpio/gpio-wcd934x.c was not checking the return value of the first `regmap_update_bits()` call (lines 50-51 in the original code). This could lead to silent failures where the GPIO direction register update fails, but the function continues to update the value register, potentially leaving the GPIO in an inconsistent state.

2. **The fix is minimal and contained**: The change is very small - it only adds 4 lines of code to check the return value and propagate the error. This minimizes the risk of introducing regressions.

3. **Consistency with the rest of the driver**: Looking at the code, other functions in the same driver already properly check regmap operation return values: - `wcd_gpio_get_direction()` checks the return value of `regmap_read()` at line 27-29 - `wcd_gpio_direction_input()` already returns the result of `regmap_update_bits()` directly

4. **Consistency with other GPIO drivers**: My examination of other GPIO drivers (gpio-lp87565.c, gpio-lp873x.c, gpio-tps65912.c, gpio- adp5585.c) shows that properly checking return values from regmap operations in `direction_output` functions is the standard practice.

5. **Potential for real-world impact**: The WCD934x is an audio codec used in Qualcomm SoCs like SDM845. A failure to properly set GPIO direction could cause issues with audio functionality or other peripherals connected through these GPIOs. The bug could manifest as intermittent failures that are hard to debug.

6. **No architectural changes**: The commit doesn't introduce new features or change any APIs. It's purely a bug fix that adds proper error handling.

7. **Clear bug pattern**: The pattern of not checking the first regmap operation but checking (returning) the second one suggests this was an oversight rather than intentional behavior.

The commit follows stable kernel rules by being a clear bug fix that addresses a potential reliability issue without introducing new functionality or making architectural changes.

drivers/gpio/gpio-wcd934x.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-wcd934x.c b/drivers/gpio/gpio-wcd934x.c index 97e6caedf1f3..c00968ce7a56 100644 --- a/drivers/gpio/gpio-wcd934x.c +++ b/drivers/gpio/gpio-wcd934x.c @@ -45,9 +45,12 @@ static int wcd_gpio_direction_output(struct gpio_chip *chip, unsigned int pin, int val) { struct wcd_gpio_data *data = gpiochip_get_data(chip); + int ret;

- regmap_update_bits(data->map, WCD_REG_DIR_CTL_OFFSET, - WCD_PIN_MASK(pin), WCD_PIN_MASK(pin)); + ret = regmap_update_bits(data->map, WCD_REG_DIR_CTL_OFFSET, + WCD_PIN_MASK(pin), WCD_PIN_MASK(pin)); + if (ret) + return ret;

return regmap_update_bits(data->map, WCD_REG_VAL_CTL_OFFSET, WCD_PIN_MASK(pin),

From: Alexander Kochetkov al.kochet@gmail.com

[ Upstream commit 7cdb433bb44cdc87dc5260cdf15bf03cc1cd1814 ]

In order to bring up secondary CPUs main CPU write trampoline code to SRAM. The trampoline code is written while secondary CPUs are powered on (at least that true for RK3188 CPU). Sometimes that leads to kernel hang. Probably because secondary CPU execute trampoline code while kernel doesn't expect.

The patch moves SRAM initialization step to the point where all secondary CPUs are powered down.

That fixes rarely hangs on RK3188: [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchip_smp_prepare_cpus: ncores 4

Signed-off-by: Alexander Kochetkov al.kochet@gmail.com Link: https://lore.kernel.org/r/20250703140453.1273027-1-al.kochet@gmail.com Signed-off-by: Heiko Stuebner heiko@sntech.de Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

Based on my analysis of the commit and the code context, here's my determination:

**Backport Status: YES**

This commit should be backported to stable kernel trees for the following reasons:

1. **Fixes a real bug affecting users**: The commit explicitly mentions that it "fixes rarely hangs on RK3188" during SMP initialization. This is a critical boot-time issue that prevents the system from functioning properly.

2. **Small and contained fix**: The change is minimal - it only moves the SRAM initialization code (`rockchip_smp_prepare_sram()`) to execute after all secondary CPUs are powered down. The code movement is straightforward: - Lines 281-285 (old location) are moved to lines 321-325 (new location) - The fix is contained within a single function (`rockchip_smp_prepare_cpus()`)

3. **Clear root cause**: The commit message explains the race condition clearly - secondary CPUs may execute trampoline code while it's being written to SRAM, causing unpredictable behavior and hangs.

4. **No architectural changes**: This is purely a timing/ordering fix that doesn't introduce new features or change the architecture of the code.

5. **Critical subsystem**: SMP initialization is a critical kernel subsystem. A hang during boot makes the system unusable, which is a severe issue for affected users.

6. **Platform-specific fix**: The change only affects Rockchip ARM platforms (specifically those with Cortex-A9 CPUs like RK3188), limiting the scope of potential regressions.

7. **Follows stable tree rules**: The fix addresses an important bug (boot hang), is small and self-contained, has minimal risk of regression, and doesn't introduce new features.

The key insight from the code analysis is that the original code had a clear race condition where: 1. Secondary CPUs were powered on (lines 287-288 in the original) 2. Trampoline code was written to SRAM (line 282 in the original) 3. Secondary CPUs could potentially execute incomplete/corrupted trampoline code

The fix ensures all secondary CPUs are powered down (lines 321-323) before writing the trampoline code to SRAM (lines 321-325 in the new version), eliminating the race condition.

arch/arm/mach-rockchip/platsmp.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-rockchip/platsmp.c b/arch/arm/mach-rockchip/platsmp.c index d60856898d97..17aee4701e81 100644 --- a/arch/arm/mach-rockchip/platsmp.c +++ b/arch/arm/mach-rockchip/platsmp.c @@ -279,11 +279,6 @@ static void __init rockchip_smp_prepare_cpus(unsigned int max_cpus) }

if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) { - if (rockchip_smp_prepare_sram(node)) { - of_node_put(node); - return; - } - /* enable the SCU power domain */ pmu_set_power_domain(PMU_PWRDN_SCU, true);

@@ -316,11 +311,19 @@ static void __init rockchip_smp_prepare_cpus(unsigned int max_cpus) asm ("mrc p15, 1, %0, c9, c0, 2\n" : "=r" (l2ctlr)); ncores = ((l2ctlr >> 24) & 0x3) + 1; } - of_node_put(node);

/* Make sure that all cores except the first are really off */ for (i = 1; i < ncores; i++) pmu_set_power_domain(0 + i, false); + + if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) { + if (rockchip_smp_prepare_sram(node)) { + of_node_put(node); + return; + } + } + + of_node_put(node); }

static void __init rk3036_smp_prepare_cpus(unsigned int max_cpus)

From: Shubhrajyoti Datta shubhrajyoti.datta@amd.com

[ Upstream commit b1dc7f097b78eb8d25b071ead2384b07a549692b ]

Clear the ECC error and counter registers during initialization/probe to avoid reporting stale errors that may have occurred before EDAC registration.

For that, unify the Zynq and ZynqMP ECC state reading paths and simplify the code.

[ bp: Massage commit message. Fix an -Wsometimes-uninitialized warning as reported by Reported-by: kernel test robot lkp@intel.com Closes: https://lore.kernel.org/oe-kbuild-all/202507141048.obUv3ZUm-lkp@intel.com ]

Signed-off-by: Shubhrajyoti Datta shubhrajyoti.datta@amd.com Signed-off-by: Borislav Petkov (AMD) bp@alien8.de Link: https://lore.kernel.org/20250713050753.7042-1-shubhrajyoti.datta@amd.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

This commit is suitable for backporting to stable kernel trees based on the following analysis:

## Bug Fix Nature The commit fixes a clear bug where the EDAC driver could report stale ECC errors from before the driver was initialized. This is evident from the commit message: "Clear the ECC error and counter registers during initialization/probe to avoid reporting stale errors that may have occurred before EDAC registration."

## Code Changes Analysis

1. **Problem Being Fixed**: - The driver wasn't clearing ECC error counters during initialization - This could lead to false error reports from pre-boot or pre-driver- load errors - Users could see incorrect ECC error counts that don't reflect actual runtime errors

2. **Solution Implementation**: - The patch consolidates the ECC state checking into a single `get_ecc_state()` function - Adds counter clearing logic for both Zynq and ZynqMP platforms: ```c // For Zynq: clearval = ECC_CTRL_CLR_CE_ERR | ECC_CTRL_CLR_UE_ERR; writel(clearval, priv->baseaddr + ECC_CTRL_OFST); writel(0x0, priv->baseaddr + ECC_CTRL_OFST);

// For ZynqMP: clearval = readl(priv->baseaddr + ECC_CLR_OFST) | ECC_CTRL_CLR_CE_ERR | ECC_CTRL_CLR_CE_ERRCNT | ECC_CTRL_CLR_UE_ERR | ECC_CTRL_CLR_UE_ERRCNT; writel(clearval, priv->baseaddr + ECC_CLR_OFST); ```

3. **Scope and Risk Assessment**: - Changes are confined to the synopsys_edac driver - No API changes or interface modifications - The refactoring simplifies code by removing duplicate `zynq_get_ecc_state()` and `zynqmp_get_ecc_state()` functions - Adds platform type enum for cleaner platform identification - Risk is minimal as it only affects initialization path

4. **Stable Tree Criteria Compliance**: - ✓ Fixes a real bug (stale error reporting) - ✓ Small and contained changes (~150 lines) - ✓ No new features added - ✓ No architectural changes - ✓ Low regression risk - ✓ Clear fix for a specific problem

5. **Additional Evidence**: - The maintainer (Borislav Petkov) accepted and massaged the patch - Fixed a compiler warning caught by kernel test robot - The bug could affect production systems by showing false ECC errors

This is a textbook example of a stable-worthy patch: it fixes a specific bug (stale ECC error reporting) with minimal, focused changes that don't introduce new functionality or risk.

drivers/edac/synopsys_edac.c | 97 +++++++++++++++++------------------- 1 file changed, 46 insertions(+), 51 deletions(-)

diff --git a/drivers/edac/synopsys_edac.c b/drivers/edac/synopsys_edac.c index e8ddb029f10d..cbc40f57b27b 100644 --- a/drivers/edac/synopsys_edac.c +++ b/drivers/edac/synopsys_edac.c @@ -346,20 +346,26 @@ struct synps_edac_priv { #endif };

+enum synps_platform_type { + ZYNQ, + ZYNQMP, + SYNPS, +}; + /** * struct synps_platform_data - synps platform data structure. + * @platform: Identifies the target hardware platform * @get_error_info: Get EDAC error info. * @get_mtype: Get mtype. * @get_dtype: Get dtype. - * @get_ecc_state: Get ECC state. * @get_mem_info: Get EDAC memory info * @quirks: To differentiate IPs. */ struct synps_platform_data { + enum synps_platform_type platform; int (*get_error_info)(struct synps_edac_priv *priv); enum mem_type (*get_mtype)(const void __iomem *base); enum dev_type (*get_dtype)(const void __iomem *base); - bool (*get_ecc_state)(void __iomem *base); #ifdef CONFIG_EDAC_DEBUG u64 (*get_mem_info)(struct synps_edac_priv *priv); #endif @@ -734,51 +740,38 @@ static enum dev_type zynqmp_get_dtype(const void __iomem *base) return dt; }

-/** - * zynq_get_ecc_state - Return the controller ECC enable/disable status. - * @base: DDR memory controller base address. - * - * Get the ECC enable/disable status of the controller. - * - * Return: true if enabled, otherwise false. - */ -static bool zynq_get_ecc_state(void __iomem *base) +static bool get_ecc_state(struct synps_edac_priv *priv) { + u32 ecctype, clearval; enum dev_type dt; - u32 ecctype; - - dt = zynq_get_dtype(base); - if (dt == DEV_UNKNOWN) - return false;

- ecctype = readl(base + SCRUB_OFST) & SCRUB_MODE_MASK; - if ((ecctype == SCRUB_MODE_SECDED) && (dt == DEV_X2)) - return true; - - return false; -} - -/** - * zynqmp_get_ecc_state - Return the controller ECC enable/disable status. - * @base: DDR memory controller base address. - * - * Get the ECC enable/disable status for the controller. - * - * Return: a ECC status boolean i.e true/false - enabled/disabled. - */ -static bool zynqmp_get_ecc_state(void __iomem *base) -{ - enum dev_type dt; - u32 ecctype; - - dt = zynqmp_get_dtype(base); - if (dt == DEV_UNKNOWN) - return false; - - ecctype = readl(base + ECC_CFG0_OFST) & SCRUB_MODE_MASK; - if ((ecctype == SCRUB_MODE_SECDED) && - ((dt == DEV_X2) || (dt == DEV_X4) || (dt == DEV_X8))) - return true; + if (priv->p_data->platform == ZYNQ) { + dt = zynq_get_dtype(priv->baseaddr); + if (dt == DEV_UNKNOWN) + return false; + + ecctype = readl(priv->baseaddr + SCRUB_OFST) & SCRUB_MODE_MASK; + if (ecctype == SCRUB_MODE_SECDED && dt == DEV_X2) { + clearval = ECC_CTRL_CLR_CE_ERR | ECC_CTRL_CLR_UE_ERR; + writel(clearval, priv->baseaddr + ECC_CTRL_OFST); + writel(0x0, priv->baseaddr + ECC_CTRL_OFST); + return true; + } + } else { + dt = zynqmp_get_dtype(priv->baseaddr); + if (dt == DEV_UNKNOWN) + return false; + + ecctype = readl(priv->baseaddr + ECC_CFG0_OFST) & SCRUB_MODE_MASK; + if (ecctype == SCRUB_MODE_SECDED && + (dt == DEV_X2 || dt == DEV_X4 || dt == DEV_X8)) { + clearval = readl(priv->baseaddr + ECC_CLR_OFST) | + ECC_CTRL_CLR_CE_ERR | ECC_CTRL_CLR_CE_ERRCNT | + ECC_CTRL_CLR_UE_ERR | ECC_CTRL_CLR_UE_ERRCNT; + writel(clearval, priv->baseaddr + ECC_CLR_OFST); + return true; + } + }

return false; } @@ -948,18 +941,18 @@ static int setup_irq(struct mem_ctl_info *mci, }

static const struct synps_platform_data zynq_edac_def = { + .platform = ZYNQ, .get_error_info = zynq_get_error_info, .get_mtype = zynq_get_mtype, .get_dtype = zynq_get_dtype, - .get_ecc_state = zynq_get_ecc_state, .quirks = 0, };

static const struct synps_platform_data zynqmp_edac_def = { + .platform = ZYNQMP, .get_error_info = zynqmp_get_error_info, .get_mtype = zynqmp_get_mtype, .get_dtype = zynqmp_get_dtype, - .get_ecc_state = zynqmp_get_ecc_state, #ifdef CONFIG_EDAC_DEBUG .get_mem_info = zynqmp_get_mem_info, #endif @@ -971,10 +964,10 @@ static const struct synps_platform_data zynqmp_edac_def = { };

static const struct synps_platform_data synopsys_edac_def = { + .platform = SYNPS, .get_error_info = zynqmp_get_error_info, .get_mtype = zynqmp_get_mtype, .get_dtype = zynqmp_get_dtype, - .get_ecc_state = zynqmp_get_ecc_state, .quirks = (DDR_ECC_INTR_SUPPORT | DDR_ECC_INTR_SELF_CLEAR #ifdef CONFIG_EDAC_DEBUG | DDR_ECC_DATA_POISON_SUPPORT @@ -1406,10 +1399,6 @@ static int mc_probe(struct platform_device *pdev) if (!p_data) return -ENODEV;

- if (!p_data->get_ecc_state(baseaddr)) { - edac_printk(KERN_INFO, EDAC_MC, "ECC not enabled\n"); - return -ENXIO; - }

layers[0].type = EDAC_MC_LAYER_CHIP_SELECT; layers[0].size = SYNPS_EDAC_NR_CSROWS; @@ -1429,6 +1418,12 @@ static int mc_probe(struct platform_device *pdev) priv = mci->pvt_info; priv->baseaddr = baseaddr; priv->p_data = p_data; + if (!get_ecc_state(priv)) { + edac_printk(KERN_INFO, EDAC_MC, "ECC not enabled\n"); + rc = -ENODEV; + goto free_edac_mc; + } + spin_lock_init(&priv->reglock);

mc_init(mci, pdev);

From: David Collins david.collins@oss.qualcomm.com

[ Upstream commit f8e157ff2df46ddabd930815d196895976227831 ]

Certain TEMP_ALARM GEN2 PMIC peripherals need over-temperature stage 2 automatic PMIC partial shutdown. This will ensure that in the event of reaching the hotter stage 3 over-temperature threshold, repeated faults will be avoided during the automatic PMIC hardware full shutdown. Modify the stage 2 shutdown control logic to ensure that stage 2 shutdown is enabled on all affected PMICs. Read the digital major and minor revision registers to identify these PMICs.

Signed-off-by: David Collins david.collins@oss.qualcomm.com Signed-off-by: Anjelique Melendez anjelique.melendez@oss.qualcomm.com Link: https://lore.kernel.org/r/20250710224555.3047790-2-anjelique.melendez@oss.qu... Signed-off-by: Daniel Lezcano daniel.lezcano@linaro.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

This commit should be backported to stable kernel trees. Here's my detailed analysis:

## Key Reasons for Backporting:

### 1. **Fixes a Hardware Safety Issue** The commit addresses a critical hardware protection mechanism where certain PMIC peripherals require stage 2 automatic partial shutdown to prevent "repeated faults" during stage 3 over-temperature events. Without this fix, affected hardware could experience repeated thermal faults during critical temperature conditions, potentially leading to system instability or hardware damage.

### 2. **Targeted Hardware-Specific Fix** The code changes identify specific PMIC revisions that require this protection: ```c switch (dig_revision) { case 0x0001: case 0x0002: case 0x0100: case 0x0101: chip->require_stage2_shutdown = true; break; } ``` This shows it's a targeted fix for known hardware issues, not a general enhancement.

### 3. **Small and Contained Change** The fix is minimal and self-contained: - Adds reading of DIG_MINOR register - Adds a `require_stage2_shutdown` flag to the chip structure - Modifies the logic in `qpnp_tm_update_critical_trip_temp()` to respect this flag - Total change is about 30 lines of code with clear boundaries

### 4. **Low Risk of Regression** - The change only affects specific PMIC revisions (0x0001, 0x0002, 0x0100, 0x0101) - For other hardware, behavior remains unchanged - The modification is purely additive - it doesn't alter existing functionality for unaffected devices

### 5. **Prevents Hardware Malfunction** The commit message explicitly states this fix is needed to "avoid potential repeated faults upon reaching over-temperature stage 3." This indicates a real hardware malfunction scenario that users could encounter without this patch.

### 6. **Follows Stable Tree Rules** According to stable kernel rules, this qualifies because it: - Fixes a real bug (hardware protection failure) - Is not a new feature - Has minimal changes - Addresses a specific hardware issue that affects users

### Technical Analysis: The key change is in the `qpnp_tm_update_critical_trip_temp()` function where the condition is modified from: ```c if (disable_s2_shutdown) reg |= SHUTDOWN_CTRL1_OVERRIDE_S2; ``` to: ```c if (disable_stage2_shutdown && !chip->require_stage2_shutdown) reg |= SHUTDOWN_CTRL1_OVERRIDE_STAGE2; ```

This ensures that for the affected PMIC revisions, stage 2 shutdown is never disabled, providing the necessary hardware protection against thermal events.

Given that this fixes a hardware-specific thermal protection issue that could lead to system instability or damage, and the fix is minimal with low regression risk, this commit is an excellent candidate for stable backporting.

drivers/thermal/qcom/qcom-spmi-temp-alarm.c | 43 ++++++++++++++++----- 1 file changed, 34 insertions(+), 9 deletions(-)

diff --git a/drivers/thermal/qcom/qcom-spmi-temp-alarm.c b/drivers/thermal/qcom/qcom-spmi-temp-alarm.c index 1037de19873a..f466bbfa128d 100644 --- a/drivers/thermal/qcom/qcom-spmi-temp-alarm.c +++ b/drivers/thermal/qcom/qcom-spmi-temp-alarm.c @@ -1,6 +1,7 @@ // SPDX-License-Identifier: GPL-2.0-only /* * Copyright (c) 2011-2015, 2017, 2020, The Linux Foundation. All rights reserved. + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries. */

#include <linux/bitops.h> @@ -17,6 +18,7 @@

#include "../thermal_core.h"

+#define QPNP_TM_REG_DIG_MINOR 0x00 #define QPNP_TM_REG_DIG_MAJOR 0x01 #define QPNP_TM_REG_TYPE 0x04 #define QPNP_TM_REG_SUBTYPE 0x05 @@ -32,7 +34,7 @@ #define STATUS_GEN2_STATE_MASK GENMASK(6, 4) #define STATUS_GEN2_STATE_SHIFT 4

-#define SHUTDOWN_CTRL1_OVERRIDE_S2 BIT(6) +#define SHUTDOWN_CTRL1_OVERRIDE_STAGE2 BIT(6) #define SHUTDOWN_CTRL1_THRESHOLD_MASK GENMASK(1, 0)

#define SHUTDOWN_CTRL1_RATE_25HZ BIT(3) @@ -80,6 +82,7 @@ struct qpnp_tm_chip { /* protects .thresh, .stage and chip registers */ struct mutex lock; bool initialized; + bool require_stage2_shutdown;

struct iio_channel *adc; const long (*temp_map)[THRESH_COUNT][STAGE_COUNT]; @@ -222,13 +225,13 @@ static int qpnp_tm_update_critical_trip_temp(struct qpnp_tm_chip *chip, { long stage2_threshold_min = (*chip->temp_map)[THRESH_MIN][1]; long stage2_threshold_max = (*chip->temp_map)[THRESH_MAX][1]; - bool disable_s2_shutdown = false; + bool disable_stage2_shutdown = false; u8 reg;

WARN_ON(!mutex_is_locked(&chip->lock));

/* - * Default: S2 and S3 shutdown enabled, thresholds at + * Default: Stage 2 and Stage 3 shutdown enabled, thresholds at * lowest threshold set, monitoring at 25Hz */ reg = SHUTDOWN_CTRL1_RATE_25HZ; @@ -243,12 +246,12 @@ static int qpnp_tm_update_critical_trip_temp(struct qpnp_tm_chip *chip, chip->thresh = THRESH_MAX - ((stage2_threshold_max - temp) / TEMP_THRESH_STEP); - disable_s2_shutdown = true; + disable_stage2_shutdown = true; } else { chip->thresh = THRESH_MAX;

if (chip->adc) - disable_s2_shutdown = true; + disable_stage2_shutdown = true; else dev_warn(chip->dev, "No ADC is configured and critical temperature %d mC is above the maximum stage 2 threshold of %ld mC! Configuring stage 2 shutdown at %ld mC.\n", @@ -257,8 +260,8 @@ static int qpnp_tm_update_critical_trip_temp(struct qpnp_tm_chip *chip,

skip: reg |= chip->thresh; - if (disable_s2_shutdown) - reg |= SHUTDOWN_CTRL1_OVERRIDE_S2; + if (disable_stage2_shutdown && !chip->require_stage2_shutdown) + reg |= SHUTDOWN_CTRL1_OVERRIDE_STAGE2;

return qpnp_tm_write(chip, QPNP_TM_REG_SHUTDOWN_CTRL1, reg); } @@ -372,8 +375,8 @@ static int qpnp_tm_probe(struct platform_device *pdev) { struct qpnp_tm_chip *chip; struct device_node *node; - u8 type, subtype, dig_major; - u32 res; + u8 type, subtype, dig_major, dig_minor; + u32 res, dig_revision; int ret, irq;

node = pdev->dev.of_node; @@ -428,6 +431,11 @@ static int qpnp_tm_probe(struct platform_device *pdev) return ret; }

+ ret = qpnp_tm_read(chip, QPNP_TM_REG_DIG_MINOR, &dig_minor); + if (ret < 0) + return dev_err_probe(&pdev->dev, ret, + "could not read dig_minor\n"); + if (type != QPNP_TM_TYPE || (subtype != QPNP_TM_SUBTYPE_GEN1 && subtype != QPNP_TM_SUBTYPE_GEN2)) { dev_err(&pdev->dev, "invalid type 0x%02x or subtype 0x%02x\n", @@ -441,6 +449,23 @@ static int qpnp_tm_probe(struct platform_device *pdev) else chip->temp_map = &temp_map_gen1;

+ if (chip->subtype == QPNP_TM_SUBTYPE_GEN2) { + dig_revision = (dig_major << 8) | dig_minor; + /* + * Check if stage 2 automatic partial shutdown must remain + * enabled to avoid potential repeated faults upon reaching + * over-temperature stage 3. + */ + switch (dig_revision) { + case 0x0001: + case 0x0002: + case 0x0100: + case 0x0101: + chip->require_stage2_shutdown = true; + break; + } + } + /* * Register the sensor before initializing the hardware to be able to * read the trip points. get_temp() returns the default temperature

From: Bartosz Golaszewski bartosz.golaszewski@linaro.org

[ Upstream commit a0b2a6bbff8c26aafdecd320f38f52c341d5cafa ]

regmap_update_bits() can fail, check its return value like we do elsewhere in the driver.

Link: https://lore.kernel.org/r/20250707-gpiochip-set-rv-gpio-round4-v1-2-35668aaa... Signed-off-by: Bartosz Golaszewski bartosz.golaszewski@linaro.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

This commit should be backported to stable kernel trees for the following reasons:

1. **Bug Fix with Real Impact**: The commit fixes a bug where the return value of `regmap_update_bits()` in `tps65912_gpio_direction_output()` is not checked (line 54-55 in the original code). This could lead to silent failures where the GPIO initial value is not set correctly, but the function continues to configure the direction, potentially leaving the GPIO in an inconsistent state.

2. **Consistency with Driver Pattern**: The driver already checks return values of `regmap_update_bits()` in other functions: - `tps65912_gpio_direction_input()` (line 44) properly returns the result - The second `regmap_update_bits()` call in `tps65912_gpio_direction_output()` (line 57) also returns the result - `tps65912_gpio_get_direction()` checks the return value of `regmap_read()`

3. **Small and Contained Fix**: The patch is minimal - it only adds: - An `int ret` variable declaration - Captures the return value of the first `regmap_update_bits()` call - Adds an error check that returns early if the operation failed

4. **No Side Effects**: This change doesn't introduce any new functionality or alter the existing behavior when operations succeed. It only adds proper error handling that was missing.

5. **Hardware Communication Reliability**: The TPS65912 is a PMIC (Power Management IC) that communicates over I2C/SPI. Hardware communication can fail due to various reasons (bus errors, device issues), and not checking return values can lead to incorrect GPIO states which could affect system stability or connected peripherals.

6. **Follows Kernel Best Practices**: The kernel coding standards require checking return values of functions that can fail, especially for hardware operations. This fix brings the code in line with those standards.

The commit message clearly indicates this is a bug fix ("regmap_update_bits() can fail, check its return value like we do elsewhere in the driver"), making it a perfect candidate for stable backporting as it improves driver reliability without any risk of regression.

drivers/gpio/gpio-tps65912.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-tps65912.c b/drivers/gpio/gpio-tps65912.c index fab771cb6a87..bac757c191c2 100644 --- a/drivers/gpio/gpio-tps65912.c +++ b/drivers/gpio/gpio-tps65912.c @@ -49,10 +49,13 @@ static int tps65912_gpio_direction_output(struct gpio_chip *gc, unsigned offset, int value) { struct tps65912_gpio *gpio = gpiochip_get_data(gc); + int ret;

/* Set the initial value */ - regmap_update_bits(gpio->tps->regmap, TPS65912_GPIO1 + offset, - GPIO_SET_MASK, value ? GPIO_SET_MASK : 0); + ret = regmap_update_bits(gpio->tps->regmap, TPS65912_GPIO1 + offset, + GPIO_SET_MASK, value ? GPIO_SET_MASK : 0); + if (ret) + return ret;

return regmap_update_bits(gpio->tps->regmap, TPS65912_GPIO1 + offset, GPIO_CFG_MASK, GPIO_CFG_MASK);

From: "Masami Hiramatsu (Google)" mhiramat@kernel.org

[ Upstream commit a089bb2822a49b0c5777a8936f82c1f8629231fb ]

Since commit c5b6ababd21a ("locking/mutex: implement mutex_trylock_nested") makes mutex_trylock() as an inlined function if CONFIG_DEBUG_LOCK_ALLOC=y, we can not use mutex_trylock() for testing the glob filter of ftrace.

Use mutex_unlock instead.

Link: https://lore.kernel.org/r/175151680309.2149615.9795104805153538717.stgit@mhi... Signed-off-by: Masami Hiramatsu (Google) mhiramat@kernel.org Acked-by: Steven Rostedt (Google) rostedt@goodmis.org Signed-off-by: Shuah Khan skhan@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

## Backport Status: YES

This commit should be backported to stable kernel trees for the following reasons:

1. **It fixes a test regression**: The commit c5b6ababd21a changed mutex_trylock() from being a regular function to an inline macro when CONFIG_DEBUG_LOCK_ALLOC=y. This broke the ftrace glob filter selftest that was trying to match functions with the pattern `mutex*try*`. Since mutex_trylock is no longer a regular function symbol in certain configurations, the test would fail.

2. **Simple and contained fix**: The change is minimal - it simply replaces the test pattern from `mutex*try*` to `mutex*unl*` on line 32. This is a one-line change that: - Changes the glob pattern from matching mutex_trylock functions to mutex_unlock functions - Maintains the same test logic and purpose (testing glob pattern matching) - mutex_unlock remains a regular function symbol regardless of CONFIG_DEBUG_LOCK_ALLOC

3. **No functional changes to kernel code**: This only affects a selftest, not any kernel functionality. The risk of regression is zero for normal kernel operation.

4. **Test reliability**: Without this fix, the ftrace selftest suite would fail on kernels built with CONFIG_DEBUG_LOCK_ALLOC=y after commit c5b6ababd21a is applied. This could: - Cause false test failures in CI/CD pipelines - Make it harder to detect real ftrace issues - Confuse developers running the test suite

5. **Clear dependency**: The commit message explicitly states this is needed "Since commit c5b6ababd21a" which indicates this is a direct fix for a known regression introduced by that specific commit.

The change is exactly the type that stable rules recommend: it fixes a clear bug (test regression), is minimal in scope, has no risk of breaking functionality, and maintains test coverage for an important kernel feature (ftrace glob filtering).

.../testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc index 4b994b6df5ac..ed81eaf2afd6 100644 --- a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc +++ b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc @@ -29,7 +29,7 @@ ftrace_filter_check 'schedule*' '^schedule.*$' ftrace_filter_check '*pin*lock' '.*pin.*lock$'

# filter by start*mid* -ftrace_filter_check 'mutex*try*' '^mutex.*try.*' +ftrace_filter_check 'mutex*unl*' '^mutex.*unl.*'

# Advanced full-glob matching feature is recently supported. # Skip the tests if we are sure the kernel does not support it.

From: "Rafael J. Wysocki" rafael.j.wysocki@intel.com

[ Upstream commit 89d9cec3b1e9c49bae9375a2db6dc49bc7468af0 ]

Clear power.needs_force_resume in pm_runtime_reinit() in case it has been set by pm_runtime_force_suspend() invoked from a driver remove callback.

Suggested-by: Ulf Hansson ulf.hansson@linaro.org Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Reviewed-by: Ulf Hansson ulf.hansson@linaro.org Link: https://patch.msgid.link/9495163.CDJkKcVGEf@rjwysocki.net Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

This commit is a clear bugfix that should be backported to stable kernel trees for the following reasons:

1. **It fixes a real bug**: The commit addresses a specific issue where `power.needs_force_resume` flag is not cleared in `pm_runtime_reinit()` when a device is removed. If a driver calls `pm_runtime_force_suspend()` from its remove callback (which sets `needs_force_resume = 1`), this flag remains set even after the device is removed and potentially re-probed.

2. **The fix is minimal and contained**: The change adds just 5 lines of code (including comments) to clear a single flag. The modification is: ```c dev->power.needs_force_resume = false; ``` This is a very low-risk change that only affects the specific condition being fixed.

3. **It prevents state leakage**: Looking at the code flow: - `pm_runtime_force_suspend()` sets `dev->power.needs_force_resume = 1` (line in runtime.c) - When a driver is removed, `pm_runtime_remove()` calls `pm_runtime_reinit()` - Without this fix, if the device is re-probed, it would still have `needs_force_resume = 1` from the previous instance - This could lead to incorrect PM runtime behavior where `pm_runtime_force_resume()` would incorrectly think it needs to resume a device that was never suspended in the current probe cycle

4. **Related to previous stable fixes**: The git history shows a previous commit `c745253e2a69` ("PM: runtime: Fix unpaired parent child_count for force_resume") was already marked for stable (4.16+), indicating that issues with the `needs_force_resume` flag have been problematic enough to warrant stable backports.

5. **Clear bug scenario**: The commit message describes a specific scenario where this happens - when `pm_runtime_force_suspend()` is called from a driver remove callback. This is a legitimate use case where drivers want to ensure devices are suspended before removal.

6. **No architectural changes**: This is purely a bugfix that clears a flag that should have been cleared during reinitialization. It doesn't introduce new features or change any APIs.

The fix ensures proper PM runtime state management across device removal and re-probing cycles, which is important for system stability and correct power management behavior.

drivers/base/power/runtime.c | 5 +++++ 1 file changed, 5 insertions(+)

diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c index 35e1a090ef90..26ea7f5c8d42 100644 --- a/drivers/base/power/runtime.c +++ b/drivers/base/power/runtime.c @@ -1714,6 +1714,11 @@ void pm_runtime_reinit(struct device *dev) pm_runtime_put(dev->parent); } } + /* + * Clear power.needs_force_resume in case it has been set by + * pm_runtime_force_suspend() invoked from a driver remove callback. + */ + dev->power.needs_force_resume = false; }

/**

From: tuhaowen tuhaowen@uniontech.com

[ Upstream commit 4266e8fa56d3d982bf451d382a410b9db432015c ]

When the computer enters sleep status without a monitor connected, the system switches the console to the virtual terminal tty63(SUSPEND_CONSOLE).

If a monitor is subsequently connected before waking up, the system skips the required VT restoration process during wake-up, leaving the console on tty63 instead of switching back to tty1.

To fix this issue, a global flag vt_switch_done is introduced to record whether the system has successfully switched to the suspend console via vt_move_to_console() during suspend.

If the switch was completed, vt_switch_done is set to 1. Later during resume, this flag is checked to ensure that the original console is restored properly by calling vt_move_to_console(orig_fgconsole, 0).

This prevents scenarios where the resume logic skips console restoration due to incorrect detection of the console state, especially when a monitor is reconnected before waking up.

Signed-off-by: tuhaowen tuhaowen@uniontech.com Link: https://patch.msgid.link/20250611032345.29962-1-tuhaowen@uniontech.com Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

This commit should be backported to stable kernel trees. Here's my extensive analysis:

**1. Bug Fix Nature:** The commit fixes a clear user-visible bug - a black screen issue that occurs when: - A computer enters sleep without a monitor connected - A monitor is connected while the system is asleep - Upon wake, the console remains on tty63 (SUSPEND_CONSOLE) instead of returning to tty1

This is a functional regression that impacts user experience, making the system appear unresponsive or broken after resume.

**2. Small and Contained Fix:** The fix is minimal and well-contained: - Adds a single `static bool vt_switch_done` flag - Modifies only two functions: `pm_prepare_console()` and `pm_restore_console()` - Total change is just 6 lines of code (excluding whitespace) - The logic is straightforward: track whether VT switch happened during suspend, and ensure restoration happens during resume

**3. Low Risk of Side Effects:** The change has minimal risk: - The new flag (`vt_switch_done`) is only set when `vt_move_to_console()` succeeds - The restoration logic preserves existing behavior when `pm_vt_switch()` returns true - The fix only adds an additional condition `!vt_switch_done` to ensure restoration happens even when `pm_vt_switch()` returns false during resume - No architectural changes or new features are introduced

**4. Critical Subsystem but Safe Change:** While this touches the PM/console subsystem (critical for suspend/resume), the change is safe: - It doesn't modify the core VT switching mechanism - It only ensures the existing restoration path is executed when needed - The file has been stable since 2013 (last major change was f43f627d2f17e)

**5. Clear Problem Description:** The commit message clearly describes: - The specific scenario that triggers the bug - The root cause (skipped VT restoration) - The solution (tracking VT switch state)

**6. Follows Stable Rules:** This aligns perfectly with stable tree criteria: - Fixes a real bug affecting users - Minimal change (6 lines) - No new features - Clear fix for a specific problem - Low regression risk

The commit addresses a real-world scenario where users connecting monitors to sleeping systems experience black screens upon wake - a frustrating issue that makes systems appear broken. The fix is surgical, adding only the minimum tracking needed to ensure proper console restoration.

kernel/power/console.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/kernel/power/console.c b/kernel/power/console.c index fcdf0e14a47d..19c48aa5355d 100644 --- a/kernel/power/console.c +++ b/kernel/power/console.c @@ -16,6 +16,7 @@ #define SUSPEND_CONSOLE (MAX_NR_CONSOLES-1)

static int orig_fgconsole, orig_kmsg; +static bool vt_switch_done;

static DEFINE_MUTEX(vt_switch_mutex);

@@ -136,17 +137,21 @@ void pm_prepare_console(void) if (orig_fgconsole < 0) return;

+ vt_switch_done = true; + orig_kmsg = vt_kmsg_redirect(SUSPEND_CONSOLE); return; }

void pm_restore_console(void) { - if (!pm_vt_switch()) + if (!pm_vt_switch() && !vt_switch_done) return;

if (orig_fgconsole >= 0) { vt_move_to_console(orig_fgconsole, 0); vt_kmsg_redirect(orig_kmsg); } + + vt_switch_done = false; }

From: Sarthak Garg quic_sartgarg@quicinc.com

[ Upstream commit db58532188ebf51d52b1d7693d9e94c76b926e9f ]

Many mobile phones feature multi-card tray designs, where the same tray is used for both SD and SIM cards. If the SD card is placed at the outermost location in the tray, the SIM card may come in contact with SD card power-supply while removing the tray, possibly resulting in SIM damage.

To prevent that, make sure the SD card is really inserted by reading the Card Detect pin state. If it's not, turn off the power in sdhci_msm_check_power_status() and also set the BUS_FAIL power state on the controller as part of pwr_irq handling for BUS_ON request.

Signed-off-by: Sarthak Garg quic_sartgarg@quicinc.com Acked-by: Adrian Hunter adrian.hunter@intel.com Link: https://lore.kernel.org/r/20250701100659.3310386-1-quic_sartgarg@quicinc.com Signed-off-by: Ulf Hansson ulf.hansson@linaro.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

This commit should be backported to stable kernel trees for the following reasons:

1. **Hardware Damage Prevention**: This is a critical safety fix that prevents potential hardware damage to SIM cards. The commit message clearly describes a real-world scenario where SD card power can damage SIM cards in multi-card tray designs when the tray is removed. This is a serious hardware safety issue that affects end users' devices.

2. **Bug Fix Nature**: The commit fixes a specific bug where SD card power remains ON even when the card is physically removed. The code changes show two key additions: - In `sdhci_msm_check_power_status()`: Added check at lines 1625-1629 that turns off power (writes 0 to SDHCI_POWER_CONTROL) when card is not detected (`!mmc->ops->get_cd(mmc)`) - In `sdhci_msm_handle_pwr_irq()`: Added check at lines 1689-1694 that sets BUS_FAIL state when attempting to power on the bus while card is not present

3. **Small and Contained Fix**: The changes are minimal and well- contained: - Only 13 lines of actual code changes - Changes are localized to the sdhci-msm driver - No architectural changes or new features - Simple logic additions that check card presence before power operations

4. **Low Risk of Regression**: The fix adds defensive checks that only activate when: - A card is physically not present (detected via get_cd) - Power operations are being performed - This doesn't affect normal operation when cards are properly inserted

5. **Platform-Specific Critical Fix**: This affects Qualcomm MSM-based devices which are widely used in mobile phones. The multi-card tray design mentioned is common in many smartphones, making this a widespread potential issue.

6. **Clear Problem and Solution**: The commit has a clear problem statement (SIM damage from SD power) and a straightforward solution (turn off power when card is removed). This makes it easy to verify the fix is correct.

The commit follows stable tree rules perfectly - it's a important bugfix that prevents hardware damage, has minimal code changes, doesn't introduce new features, and has very low regression risk. This is exactly the type of safety-critical fix that stable kernels should include.

drivers/mmc/host/sdhci-msm.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c index 4b727754d8e3..8fb2ba20e221 100644 --- a/drivers/mmc/host/sdhci-msm.c +++ b/drivers/mmc/host/sdhci-msm.c @@ -1560,6 +1560,7 @@ static void sdhci_msm_check_power_status(struct sdhci_host *host, u32 req_type) { struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host); struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host); + struct mmc_host *mmc = host->mmc; bool done = false; u32 val = SWITCHABLE_SIGNALING_VOLTAGE; const struct sdhci_msm_offset *msm_offset = @@ -1617,6 +1618,12 @@ static void sdhci_msm_check_power_status(struct sdhci_host *host, u32 req_type) "%s: pwr_irq for req: (%d) timed out\n", mmc_hostname(host->mmc), req_type); } + + if ((req_type & REQ_BUS_ON) && mmc->card && !mmc->ops->get_cd(mmc)) { + sdhci_writeb(host, 0, SDHCI_POWER_CONTROL); + host->pwr = 0; + } + pr_debug("%s: %s: request %d done\n", mmc_hostname(host->mmc), __func__, req_type); } @@ -1675,6 +1682,13 @@ static void sdhci_msm_handle_pwr_irq(struct sdhci_host *host, int irq) udelay(10); }

+ if ((irq_status & CORE_PWRCTL_BUS_ON) && mmc->card && + !mmc->ops->get_cd(mmc)) { + msm_host_writel(msm_host, CORE_PWRCTL_BUS_FAIL, host, + msm_offset->core_pwrctl_ctl); + return; + } + /* Handle BUS ON/OFF*/ if (irq_status & CORE_PWRCTL_BUS_ON) { pwr_state = REQ_BUS_ON;

From: Eliav Farber farbere@amazon.com

[ Upstream commit 6bca1e955830808dc90e0506b2951b4256b81bbb ]

The interrupt handler in pps_gpio_probe() is registered after calling pps_register_source() using devm_request_irq(). However, in the corresponding remove function, pps_unregister_source() is called before the IRQ is freed, since devm-managed resources are released after the remove function completes.

This creates a potential race condition where an interrupt may occur after the PPS source is unregistered but before the handler is removed, possibly leading to a kernel panic.

To prevent this, switch from devm-managed IRQ registration to manual management by using request_irq() and calling free_irq() explicitly in the remove path before unregistering the PPS source. This ensures the interrupt handler is safely removed before deactivating the PPS source.

Signed-off-by: Eliav Farber farbere@amazon.com Link: https://lore.kernel.org/r/20250527053355.37185-1-farbere@amazon.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

Based on my analysis of the commit and the surrounding context, here is my assessment:

**Backport Status: YES**

This commit should be backported to stable kernel trees for the following reasons:

1. **Fixes a Real Bug**: The commit addresses a genuine race condition where an interrupt can occur after the PPS source is unregistered but before the IRQ handler is freed. This can lead to a kernel panic - a serious stability issue that affects users.

2. **Clear Race Condition Pattern**: The code shows the problematic ordering: - In probe: `pps_register_source()` → `devm_request_irq()` - In remove: `pps_unregister_source()` → (implicit devm cleanup frees IRQ)

This creates a window where the hardware can generate an interrupt after the PPS source is gone but before the handler is removed, causing the handler to access freed memory.

3. **Minimal and Contained Fix**: The change is small and focused: - Changes `devm_request_irq()` to `request_irq()` - Adds explicit `free_irq()` call before `pps_unregister_source()` - Only 3 lines of functional code changes - No new features or architectural changes

4. **Similar to Other Stable Fixes**: This follows a common pattern seen in other drivers where devm resource ordering causes issues in removal paths. The kernel has many similar fixes for CAN drivers, network drivers, and other subsystems that have been backported to stable.

5. **Low Risk of Regression**: The change is straightforward and doesn't modify the driver's functionality - it only fixes the resource cleanup ordering. The manual IRQ management is a well-established pattern.

6. **Affects User-Visible Stability**: A kernel panic during device removal/module unload is a serious issue that can affect system stability, especially in environments where PPS devices might be dynamically added/removed or during system shutdown.

The commit message clearly describes the problem, the root cause, and the solution. The fix is conservative and follows established kernel patterns for fixing devm ordering issues. This is exactly the type of bug fix that stable kernel rules recommend for backporting.

drivers/pps/clients/pps-gpio.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/pps/clients/pps-gpio.c b/drivers/pps/clients/pps-gpio.c index bf3b6f1aa984..41e1fdbcda16 100644 --- a/drivers/pps/clients/pps-gpio.c +++ b/drivers/pps/clients/pps-gpio.c @@ -206,8 +206,8 @@ static int pps_gpio_probe(struct platform_device *pdev) }

/* register IRQ interrupt handler */ - ret = devm_request_irq(dev, data->irq, pps_gpio_irq_handler, - get_irqf_trigger_flags(data), data->info.name, data); + ret = request_irq(data->irq, pps_gpio_irq_handler, + get_irqf_trigger_flags(data), data->info.name, data); if (ret) { pps_unregister_source(data->pps); dev_err(dev, "failed to acquire IRQ %d\n", data->irq); @@ -224,6 +224,7 @@ static int pps_gpio_remove(struct platform_device *pdev) { struct pps_gpio_device_data *data = platform_get_drvdata(pdev);

+ free_irq(data->irq, data); pps_unregister_source(data->pps); del_timer_sync(&data->echo_timer); /* reset echo pin in any case */

From: Ulf Hansson ulf.hansson@linaro.org

[ Upstream commit 47a255f7d2eabee06cfbf5b1c2379749442fd01d ]

In the error path of sd_set_power_mode() we don't update host->power_mode, which could lead to an imbalance of the runtime PM usage count. Fix this by always updating host->power_mode.

Reviewed-by: Avri Altman avri.altman@sandisk.com Signed-off-by: Ulf Hansson ulf.hansson@linaro.org Acked-by: Ricky Wu ricky_wu@realtek.com Link: https://lore.kernel.org/r/20250610111633.504366-2-ulf.hansson@linaro.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

**YES**

This commit should be backported to stable kernel trees. Here's my extensive analysis:

## Bug Analysis

The commit fixes a **runtime PM reference counting bug** in the `sd_set_power_mode()` function. The issue is in the error handling path:

### Original Code Problem: ```c if (power_mode == MMC_POWER_OFF) { err = sd_power_off(host); pm_runtime_put_noidle(sdmmc_dev(host)); } else { pm_runtime_get_noresume(sdmmc_dev(host)); err = sd_power_on(host); }

if (!err) host->power_mode = power_mode; // Only updated on success ```

### The Bug: 1. When transitioning to `MMC_POWER_OFF`, the code calls `pm_runtime_put_noidle()` **regardless** of whether `sd_power_off()` succeeded 2. When transitioning to `MMC_POWER_ON`, the code calls `pm_runtime_get_noresume()` **before** calling `sd_power_on()` 3. However, `host->power_mode` is only updated if there's no error

This creates a **runtime PM reference count imbalance** because: - If `sd_power_off()` fails, the runtime PM reference is still decremented, but `host->power_mode` remains at its previous value (likely `MMC_POWER_ON`) - If `sd_power_on()` fails, the runtime PM reference is still incremented, but `host->power_mode` remains at its previous value (likely `MMC_POWER_OFF`) - The early return check `if (power_mode == host->power_mode)` at the beginning of the function will prevent future attempts to fix the power state, leaving the runtime PM count permanently imbalanced

## Why This Is Suitable for Stable:

1. **Fixes a real bug**: Runtime PM reference count imbalances can lead to: - Device staying powered when it should be suspended - Device being suspended when it should be active - Power management failures - Potential system hangs or crashes

2. **Minimal change**: The fix is a simple one-liner that always updates `host->power_mode` regardless of error status

3. **Low regression risk**: - The change doesn't introduce new functionality - It doesn't alter the control flow - It simply ensures state consistency

4. **Clear bug fix**: This is not a feature addition or optimization - it's fixing incorrect error handling that violates runtime PM rules

5. **Affects users**: This bug can manifest in real-world scenarios when SD card power operations fail, particularly with flaky hardware or during system stress

6. **Subsystem contained**: The fix is limited to a single MMC host driver and doesn't affect core kernel infrastructure

The commit follows stable kernel rules by being a minimal, targeted fix for a real bug that can affect system stability and power management.

drivers/mmc/host/rtsx_usb_sdmmc.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c b/drivers/mmc/host/rtsx_usb_sdmmc.c index 1be3a355f10d..ab7023d956eb 100644 --- a/drivers/mmc/host/rtsx_usb_sdmmc.c +++ b/drivers/mmc/host/rtsx_usb_sdmmc.c @@ -1032,9 +1032,7 @@ static int sd_set_power_mode(struct rtsx_usb_sdmmc *host, err = sd_power_on(host); }

- if (!err) - host->power_mode = power_mode; - + host->power_mode = power_mode; return err; }

From: Mark Brown broonie@kernel.org

[ Upstream commit c4ca928a6db1593802cd945f075a7e21dd0430c1 ]

We currently log parse failures for ELD data and some disconnection events as errors without rate limiting. These log messages can be triggered very frequently in some situations, especially ELD parsing when there is nothing connected to a HDMI port which will generate:

hdmi-audio-codec hdmi-audio-codec.1.auto: HDMI: Unknown ELD version 0

While there's doubtless work that could be done on reducing the number of connection notification callbacks it's possible these may be legitimately generated by poor quality physical connections so let's use rate limiting to mitigate the log spam for the parse errors and lower the severity for disconnect logging to debug level.

Signed-off-by: Mark Brown broonie@kernel.org Link: https://patch.msgid.link/20250613-asoc-hdmi-eld-logging-v1-1-76d64154d969@ke... Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

This commit is a good candidate for backporting to stable kernel trees for the following reasons:

1. **Fixes a real user-facing bug**: The commit addresses log spam issues that can fill system logs with repeated error messages. When no HDMI display is connected, the driver continuously logs "HDMI: Unknown ELD version 0" errors, which can consume disk space and make logs difficult to analyze.

2. **Small and contained fix**: The changes are minimal and focused: - Changes `dev_err()` to `dev_err_ratelimited()` in two locations within `hdac_hdmi_parse_eld()` (lines 1233-1234 and 1242-1243) - Changes `dev_err()` to `dev_dbg()` for disconnect messages in `hdac_hdmi_present_sense()` (lines 1302-1303) - Total of just 3 logging statement modifications

3. **No functional changes**: The commit only modifies logging behavior without changing any driver logic, state management, or hardware interaction. This minimizes regression risk.

4. **Affects a common use case**: The issue occurs when HDMI ports are unconnected, which is a normal operating condition for many systems. Users may have HDMI ports they never use, or may frequently plug/unplug monitors.

5. **No architectural changes**: The fix doesn't introduce new features or modify the driver's architecture. It simply rate-limits existing error messages and downgrades one message's severity.

6. **Clear problem and solution**: The commit message clearly describes the issue (log spam from ELD parsing failures) and the straightforward solution (rate limiting and severity adjustment).

The specific code changes show: - In `hdac_hdmi_parse_eld()`: Rate-limiting prevents flooding logs when ELD data is invalid/unavailable - In `hdac_hdmi_present_sense()`: Downgrading disconnect messages from error to debug level is appropriate since disconnection is a normal event, not an error condition

This meets the stable kernel criteria of being a simple fix for an annoying bug that affects users without introducing new risks.

sound/soc/codecs/hdac_hdmi.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/sound/soc/codecs/hdac_hdmi.c b/sound/soc/codecs/hdac_hdmi.c index 1acd82f81ba0..bafdaedbee86 100644 --- a/sound/soc/codecs/hdac_hdmi.c +++ b/sound/soc/codecs/hdac_hdmi.c @@ -1230,7 +1230,8 @@ static int hdac_hdmi_parse_eld(struct hdac_device *hdev, >> DRM_ELD_VER_SHIFT;

if (ver != ELD_VER_CEA_861D && ver != ELD_VER_PARTIAL) { - dev_err(&hdev->dev, "HDMI: Unknown ELD version %d\n", ver); + dev_err_ratelimited(&hdev->dev, + "HDMI: Unknown ELD version %d\n", ver); return -EINVAL; }

@@ -1238,7 +1239,8 @@ static int hdac_hdmi_parse_eld(struct hdac_device *hdev, DRM_ELD_MNL_MASK) >> DRM_ELD_MNL_SHIFT;

if (mnl > ELD_MAX_MNL) { - dev_err(&hdev->dev, "HDMI: MNL Invalid %d\n", mnl); + dev_err_ratelimited(&hdev->dev, + "HDMI: MNL Invalid %d\n", mnl); return -EINVAL; }

@@ -1297,8 +1299,8 @@ static void hdac_hdmi_present_sense(struct hdac_hdmi_pin *pin,

if (!port->eld.monitor_present || !port->eld.eld_valid) {

- dev_err(&hdev->dev, "%s: disconnect for pin:port %d:%d\n", - __func__, pin->nid, port->id); + dev_dbg(&hdev->dev, "%s: disconnect for pin:port %d:%d\n", + __func__, pin->nid, port->id);

/* * PCMs are not registered during device probe, so don't

From: Peter Ujfalusi peter.ujfalusi@linux.intel.com

[ Upstream commit 2d91cb261cac6d885954b8f5da28b5c176c18131 ]

snd_soc_remove_pcm_runtime() might be called with rtd == NULL which will leads to null pointer dereference. This was reproduced with topology loading and marking a link as ignore due to missing hardware component on the system. On module removal the soc_tplg_remove_link() would call snd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored, no runtime was created.

Signed-off-by: Peter Ujfalusi peter.ujfalusi@linux.intel.com Reviewed-by: Bard Liao yung-chuan.liao@linux.intel.com Reviewed-by: Ranjani Sridharan ranjani.sridharan@linux.intel.com Reviewed-by: Liam Girdwood liam.r.girdwood@intel.com Reviewed-by: Kai Vehmanen kai.vehmanen@linux.intel.com Link: https://patch.msgid.link/20250619084222.559-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

**YES**

This commit should be backported to stable kernel trees. The analysis reveals this is a critical NULL pointer dereference fix that prevents kernel crashes.

**Key reasons for backporting:**

1. **Fixes a Real Crash**: The commit adds a NULL check to prevent a kernel panic that occurs when `snd_soc_remove_pcm_runtime()` is called with `rtd == NULL`. The code change shows this clearly: ```c + if (!rtd) + return; ``` Without this check, the subsequent line `snd_soc_card_remove_dai_link(card, rtd->dai_link)` would dereference NULL.

2. **Minimal and Safe Fix**: The change is extremely small (3 lines) and defensive - it simply adds a NULL check with early return. This follows the stable kernel rule of minimal, contained fixes.

3. **Affects Production Systems**: The commit message indicates this occurs during topology loading when hardware components are missing - a real-world scenario. The issue manifests on module removal when `soc_tplg_remove_link()` calls the function with NULL.

4. **Well-Reviewed**: The commit has 5 Reviewed-by tags from Intel ASoC maintainers, indicating thorough review and consensus on the fix.

5. **No Side Effects**: The fix has no architectural changes or new features - it purely adds defensive programming to prevent crashes. The function already had EXPORT_SYMBOL_GPL, indicating it's part of the kernel API that could be called from various contexts.

This is exactly the type of commit stable trees want: a small, obvious fix for a real crash scenario with no risk of regression.

sound/soc/soc-core.c | 3 +++ 1 file changed, 3 insertions(+)

diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 1c4d8b96f77b..d28261ef1d4c 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -959,6 +959,9 @@ static int soc_dai_link_sanity_check(struct snd_soc_card *card, void snd_soc_remove_pcm_runtime(struct snd_soc_card *card, struct snd_soc_pcm_runtime *rtd) { + if (!rtd) + return; + lockdep_assert_held(&client_mutex);

/* release machine specific resources */

From: Oliver Neukum oneukum@suse.com

[ Upstream commit 503bbde34cc3dd2acd231f277ba70c3f9ed22e59 ]

Checking for the endpoint type is no reason for a WARN, as that can cause a reboot. A driver not checking the endpoint type must not cause a reboot, as there is just no point in this. We cannot prevent a device from doing something incorrect as a reaction to a transfer. Hence warning for a mere assumption being wrong is not sensible.

Signed-off-by: Oliver Neukum oneukum@suse.com Acked-by: Alan Stern stern@rowland.harvard.edu Link: https://lore.kernel.org/r/20250612122149.2559724-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

Based on my analysis of this commit, here is my determination:

**Backport Status: YES**

This commit should be backported to stable kernel trees for the following reasons:

1. **Fixes a real issue that affects users**: The commit addresses a problem where a `dev_WARN()` can cause system reboots when `panic_on_warn` is enabled. This is a serious issue because a driver bug (not checking endpoint types properly) should not be able to crash the entire system.

2. **Small and contained fix**: The change is minimal - it only replaces `dev_WARN()` with `dev_warn_once()` on line 503 of drivers/usb/core/urb.c. This is a one-line change that doesn't affect any other functionality.

3. **Clear side effects**: The only behavioral change is that: - The warning will no longer trigger a kernel panic when `panic_on_warn` is set - The warning will only be printed once instead of potentially multiple times - No backtrace will be generated

4. **No architectural changes**: This is a simple logging level change that doesn't modify any USB subsystem architecture or functionality.

5. **Affects critical kernel subsystem**: While USB is a critical subsystem, this change actually makes it more stable by preventing potential system crashes.

6. **Follows stable tree rules**: This is clearly a bugfix that improves system stability. The commit message explicitly states that "A driver not checking the endpoint type must not cause a reboot" - this is a stability improvement that prevents denial-of-service scenarios.

7. **Similar fixes in the kernel**: There's precedent for this type of fix, as shown by commit 281cb9d65a95 ("bnxt_en: Make PTP timestamp HWRM more silent") which made a similar conversion from `netdev_WARN_ONCE()` to `netdev_warn_once()` for the same reason.

The key insight from the code is that `dev_WARN()` calls `WARN()` which can trigger a kernel panic if `panic_on_warn` is set. This means a malicious or buggy USB device could potentially crash the system just by triggering this warning. Converting to `dev_warn_once()` maintains the diagnostic value while removing the crash risk.

drivers/usb/core/urb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c index 33d62d7e3929..201f8519d9d6 100644 --- a/drivers/usb/core/urb.c +++ b/drivers/usb/core/urb.c @@ -499,7 +499,7 @@ int usb_submit_urb(struct urb *urb, gfp_t mem_flags)

/* Check that the pipe's type matches the endpoint's type */ if (usb_pipe_type_check(urb->dev, urb->pipe)) - dev_WARN(&dev->dev, "BOGUS urb xfer, pipe %x != type %x\n", + dev_warn_once(&dev->dev, "BOGUS urb xfer, pipe %x != type %x\n", usb_pipetype(urb->pipe), pipetypes[xfertype]);

/* Check against a simple/standard policy */

From: "Gautham R. Shenoy" gautham.shenoy@amd.com

[ Upstream commit cda7ac8ce7de84cf32a3871ba5f318aa3b79381e ]

In the function mperf_start(), mperf_monitor snapshots the time, tsc and finally the aperf,mperf MSRs. However, this order of snapshotting in is reversed in mperf_stop(). As a result, the C0 residency (which is computed as delta_mperf * 100 / delta_tsc) is under-reported on CPUs that is 100% busy.

Fix this by snapshotting time, tsc and then aperf,mperf in mperf_stop() in the same order as in mperf_start().

Link: https://lore.kernel.org/r/20250612122355.19629-2-gautham.shenoy@amd.com Signed-off-by: Gautham R. Shenoy gautham.shenoy@amd.com Signed-off-by: Shuah Khan skhan@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

This commit should be backported to stable kernel trees for the following reasons:

1. **Clear bug fix with user impact**: The commit fixes a calculation bug in the cpupower tool where C0 residency (processor active time) is under-reported on 100% busy CPUs. This directly affects users monitoring CPU performance and power states.

2. **Simple and contained fix**: The change is minimal - it only reorders three function calls in `mperf_stop()` to match the order in `mperf_start()`: - Before: `mperf_measure_stats()` → `mperf_get_tsc()` → `clock_gettime()` - After: `clock_gettime()` → `mperf_get_tsc()` → `mperf_measure_stats()`

3. **Low risk of regression**: The fix simply ensures consistent snapshot ordering between start and stop measurements. This is a logical correction that aligns the measurement methodology without introducing new functionality.

4. **Clear root cause**: The bug occurs because the reversed snapshot order causes timing skew in the C0 residency calculation (`delta_mperf * 100 / delta_tsc`). When snapshots are taken in different orders at start vs stop, the time windows don't align properly, leading to incorrect calculations.

5. **Affects monitoring tool accuracy**: While this is a userspace tool bug rather than a kernel bug, cpupower is an important diagnostic tool shipped with the kernel. Incorrect C0 residency reporting could mislead system administrators and developers analyzing CPU performance.

6. **No architectural changes**: The fix doesn't change any data structures, APIs, or fundamental behavior - it simply corrects the measurement sequence.

The commit meets stable tree criteria as it fixes a real bug affecting users, is minimal in scope, and has very low risk of introducing new issues.

tools/power/cpupower/utils/idle_monitor/mperf_monitor.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/power/cpupower/utils/idle_monitor/mperf_monitor.c b/tools/power/cpupower/utils/idle_monitor/mperf_monitor.c index 08a399b0be28..6ab9139f16af 100644 --- a/tools/power/cpupower/utils/idle_monitor/mperf_monitor.c +++ b/tools/power/cpupower/utils/idle_monitor/mperf_monitor.c @@ -240,9 +240,9 @@ static int mperf_stop(void) int cpu;

for (cpu = 0; cpu < cpu_count; cpu++) { - mperf_measure_stats(cpu); - mperf_get_tsc(&tsc_at_measure_end[cpu]); clock_gettime(CLOCK_REALTIME, &time_end[cpu]); + mperf_get_tsc(&tsc_at_measure_end[cpu]); + mperf_measure_stats(cpu); }

return 0;

From: Tomasz Michalec tmichalec@google.com

[ Upstream commit 8866f4e557eba43e991f99711515217a95f62d2e ]

If cros_typec_probe is called before EC device is registered, cros_typec_probe will fail. It may happen when cros-ec-typec.ko is loaded before EC bus layer module (e.g. cros_ec_lpcs.ko, cros_ec_spi.ko).

Return -EPROBE_DEFER when cros_typec_probe doesn't get EC device, so the probe function can be called again after EC device is registered.

Signed-off-by: Tomasz Michalec tmichalec@google.com Reviewed-by: Abhishek Pandit-Subedi abhishekpandit@chromium.org Link: https://lore.kernel.org/r/20250610153748.1858519-1-tmichalec@google.com Signed-off-by: Tzung-Bi Shih tzungbi@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

This commit should be backported to stable kernel trees for the following reasons:

1. **Fixes a real user-facing bug**: The commit addresses a module loading race condition where `cros_ec_typec.ko` can fail to probe if loaded before the EC bus layer modules (`cros_ec_lpcs.ko`, `cros_ec_spi.ko`). This causes the Type-C functionality to completely fail on affected systems.

2. **Small and contained fix**: The change is minimal - only 2 lines of actual code changes: - Changes `dev_err()` to `dev_warn()` (cosmetic improvement) - Changes return value from `-ENODEV` to `-EPROBE_DEFER`

3. **Follows established kernel patterns**: The fix uses the standard `-EPROBE_DEFER` mechanism which is the proper way to handle driver dependencies in the Linux kernel. The driver already uses `-EPROBE_DEFER` in another location (line 1289) for a similar EC device check.

4. **No architectural changes**: This is a simple probe deferral fix that doesn't introduce new features or change any existing functionality. It merely allows the driver to retry probing later when dependencies are satisfied.

5. **Minimal regression risk**: Returning `-EPROBE_DEFER` instead of `-ENODEV` is a safe change that only affects the probe retry behavior. The driver will still fail eventually if the EC device never appears.

6. **Fixes a regression**: Looking at commit ffebd9053272 ("platform/chrome: cros_ec_typec: Check for EC device"), the check for parent EC device was added to handle older Chromebooks. However, it inadvertently broke systems where module loading order could vary, creating a race condition.

7. **Similar pattern in the subsystem**: Other Chrome platform drivers already use `-EPROBE_DEFER` for similar dependency handling (as seen in commit 13aba1e532f0).

The fix properly handles the asynchronous nature of driver loading in modern Linux systems where module loading order is not guaranteed, making it an important fix for system reliability.

drivers/platform/chrome/cros_ec_typec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c index c065963b9a42..6f3fdd38c393 100644 --- a/drivers/platform/chrome/cros_ec_typec.c +++ b/drivers/platform/chrome/cros_ec_typec.c @@ -1110,8 +1110,8 @@ static int cros_typec_probe(struct platform_device *pdev)

typec->ec = dev_get_drvdata(pdev->dev.parent); if (!typec->ec) { - dev_err(dev, "couldn't find parent EC device\n"); - return -ENODEV; + dev_warn(dev, "couldn't find parent EC device\n"); + return -EPROBE_DEFER; }

platform_set_drvdata(pdev, typec);

From: Christophe Leroy christophe.leroy@csgroup.eu

[ Upstream commit 92f59aeb13252265c20e7aef1379a8080c57e0a2 ]

At the time being recalculate_boundary() is implemented with a loop which shows up as costly in a perf profile, as depicted by the annotate below:

0.00 : c057e934: 3d 40 7f ff lis r10,32767 0.03 : c057e938: 61 4a ff ff ori r10,r10,65535 0.21 : c057e93c: 7d 49 50 50 subf r10,r9,r10 5.39 : c057e940: 7d 3c 4b 78 mr r28,r9 2.11 : c057e944: 55 29 08 3c slwi r9,r9,1 3.04 : c057e948: 7c 09 50 40 cmplw r9,r10 2.47 : c057e94c: 40 81 ff f4 ble c057e940 <snd_pcm_ioctl+0xee0>

Total: 13.2% on that simple loop.

But what the loop does is to multiply the boundary by 2 until it is over the wanted border. This can be avoided by using fls() to get the boundary value order and shift it by the appropriate number of bits at once.

This change provides the following profile:

0.04 : c057f6e8: 3d 20 7f ff lis r9,32767 0.02 : c057f6ec: 61 29 ff ff ori r9,r9,65535 0.34 : c057f6f0: 7d 5a 48 50 subf r10,r26,r9 0.23 : c057f6f4: 7c 1a 50 40 cmplw r26,r10 0.02 : c057f6f8: 41 81 00 20 bgt c057f718 <snd_pcm_ioctl+0xf08> 0.26 : c057f6fc: 7f 47 00 34 cntlzw r7,r26 0.09 : c057f700: 7d 48 00 34 cntlzw r8,r10 0.22 : c057f704: 7d 08 38 50 subf r8,r8,r7 0.04 : c057f708: 7f 5a 40 30 slw r26,r26,r8 0.35 : c057f70c: 7c 0a d0 40 cmplw r10,r26 0.13 : c057f710: 40 80 05 f8 bge c057fd08 <snd_pcm_ioctl+0x14f8> 0.00 : c057f714: 57 5a f8 7e srwi r26,r26,1

Total: 1.7% with that loopless alternative.

Signed-off-by: Christophe Leroy christophe.leroy@csgroup.eu Link: https://patch.msgid.link/4836e2cde653eebaf2709ebe30eec736bb8c67fd.1749202237... Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

Based on my analysis of this commit, here's my determination:

**Backport Status: YES**

## Extensive Explanation:

This commit should be backported to stable kernel trees for the following reasons:

### 1. **Clear Performance Fix** The commit addresses a significant performance issue in the `recalculate_boundary()` function. The profiling data shows: - Original implementation: 13.2% CPU time spent in the loop - New implementation: 1.7% CPU time (a ~7.7x improvement)

This is a substantial performance improvement for a function that's called during PCM ioctl operations.

### 2. **Small and Contained Change** The code change is minimal and well-contained: - Only modifies one function (`recalculate_boundary()`) - Adds only `#include <linux/bitops.h>` as a dependency - The new implementation is mathematically equivalent to the old one - Total change is about 20 lines of code

### 3. **Low Risk of Regression** The change replaces a simple loop with bit manipulation operations: - Old: Loop multiplying by 2 until boundary exceeds a limit - New: Uses `__fls()` (find last set bit) to calculate the shift amount directly - The logic is preserved: find the largest power-of-2 multiple of buffer_size that fits within the 32-bit boundary

### 4. **Affects User-Facing Performance** This function is called from `snd_pcm_ioctl_sync_ptr_compat()`, which is invoked during: - 32-bit compatibility ioctl operations (`__SNDRV_PCM_IOCTL_SYNC_PTR32`) - Audio playback/capture operations on 32-bit applications running on 64-bit kernels - These are common operations that directly impact audio latency and performance

### 5. **No Architectural Changes** The commit: - Doesn't change any APIs or data structures - Doesn't modify the function's behavior or return values - Only optimizes the algorithm used internally - Maintains the same boundary calculation logic

### 6. **Well-Tested Code Path** The `recalculate_boundary()` function has been stable since its introduction for 32-bit compatibility. The mathematical equivalence of the new implementation ensures the same boundaries are calculated, just more efficiently.

### 7. **Follows Stable Tree Rules** This commit aligns with stable kernel criteria: - Fixes a real performance bug affecting users - Is obviously correct and well-tested - Has minimal risk of introducing new issues - Doesn't add new features

The only minor consideration is that this is a performance optimization rather than a correctness fix, but the significant performance impact (13.2% → 1.7% CPU usage) in a commonly used code path makes it a valuable backport candidate for stable kernels.

sound/core/pcm_native.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index d6169fee5ea0..fdd3f293c439 100644 --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -24,6 +24,7 @@ #include <sound/minors.h> #include <linux/uio.h> #include <linux/delay.h> +#include <linux/bitops.h>

#include "pcm_local.h"

@@ -3114,13 +3115,23 @@ struct snd_pcm_sync_ptr32 { static snd_pcm_uframes_t recalculate_boundary(struct snd_pcm_runtime *runtime) { snd_pcm_uframes_t boundary; + snd_pcm_uframes_t border; + int order;

if (! runtime->buffer_size) return 0; - boundary = runtime->buffer_size; - while (boundary * 2 <= 0x7fffffffUL - runtime->buffer_size) - boundary *= 2; - return boundary; + + border = 0x7fffffffUL - runtime->buffer_size; + if (runtime->buffer_size > border) + return runtime->buffer_size; + + order = __fls(border) - __fls(runtime->buffer_size); + boundary = runtime->buffer_size << order; + + if (boundary <= border) + return boundary; + else + return boundary / 2; }

static int snd_pcm_ioctl_sync_ptr_compat(struct snd_pcm_substream *substream,

From: Jonathan Santos Jonathan.Santos@analog.com

[ Upstream commit 7e54d932873d91a55d1b89b7389876d78aeeab32 ]

The SYNC_IN pulse width must be at least 1.5 x Tmclk, corresponding to ~2.5 µs at the lowest supported MCLK frequency. Add a 3 µs delay to ensure reliable synchronization timing even for the worst-case scenario.

Signed-off-by: Jonathan Santos Jonathan.Santos@analog.com Reviewed-by: David Lechner dlechner@baylibre.com Reviewed-by: Andy Shevchenko andriy.shevchenko@linux.intel.com Link: https://patch.msgid.link/d3ee92a533cd1207cf5c5cc4d7bdbb5c6c267f68.1749063024... Signed-off-by: Jonathan Cameron Jonathan.Cameron@huawei.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

This commit should be backported to stable kernel trees. Here's my extensive analysis:

**1. Bug Fix Nature:** The commit fixes a timing violation bug where the SYNC_IN pulse width was not meeting the hardware's minimum timing requirement. According to the datasheet (as noted in the commit), the SYNC_IN pulse must be at least 1.5 × Tmclk (MCLK period). Without the proper delay, the synchronization pulse may be too short, especially at lower MCLK frequencies, causing unreliable synchronization.

**2. Specific Code Analysis:**

The original code had a critical timing issue: ```c gpiod_set_value(st->gpio_sync_in, 1); gpiod_set_value(st->gpio_sync_in, 0); ```

This creates a pulse with essentially zero width (just the GPIO toggle time), which violates the hardware specification. The fix adds: - A new dedicated function `ad7768_send_sync_pulse()` that ensures proper timing - Uses `gpiod_set_value_cansleep()` instead of `gpiod_set_value()` for better reliability - Adds a 3 µs delay using `fsleep(3)` to guarantee the minimum pulse width

**3. Impact Analysis:** - **User Impact**: Without this fix, users may experience unreliable ADC synchronization, particularly when changing filter decimation rates or when operating at lower MCLK frequencies (0.6 MHz) - **Worst Case**: At 0.6 MHz, Tmclk = 1.67 µs, requiring a minimum pulse width of 2.5 µs. The original code provides essentially 0 µs - **Data Integrity**: Improper synchronization can lead to incorrect ADC readings or timing issues in multi-device setups

**4. Risk Assessment:** - **Low Risk**: The change is minimal and contained - it only adds a 3 µs delay and switches to the cansleep GPIO variant - **No API Changes**: The fix is internal to the driver with no external interface changes - **Conservative Fix**: The 3 µs delay provides margin above the 2.5 µs worst-case requirement

**5. Stable Kernel Criteria:** ✓ Fixes a real bug that affects users (timing violation) ✓ Small, contained change (adds one function, modifies one call site) ✓ No new features or architectural changes ✓ Minimal risk of regression ✓ Clear hardware specification violation being fixed

**6. Supporting Evidence:** - The driver has had multiple previous fixes backported (as seen in git log with "Fixes:" tags) - Similar timing-related fixes are commonly backported for hardware drivers - The AD7768-1 is an active production part used in data acquisition systems where reliability is critical

The commit meets all stable kernel criteria for backporting - it's a clear bug fix for a hardware timing violation that could cause unreliable operation, implemented with minimal changes and low regression risk.

drivers/iio/adc/ad7768-1.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/adc/ad7768-1.c b/drivers/iio/adc/ad7768-1.c index e240fac8b6b3..c518aeb35c70 100644 --- a/drivers/iio/adc/ad7768-1.c +++ b/drivers/iio/adc/ad7768-1.c @@ -203,6 +203,24 @@ static int ad7768_spi_reg_write(struct ad7768_state *st, return spi_write(st->spi, st->data.d8, 2); }

+static int ad7768_send_sync_pulse(struct ad7768_state *st) +{ + /* + * The datasheet specifies a minimum SYNC_IN pulse width of 1.5 × Tmclk, + * where Tmclk is the MCLK period. The supported MCLK frequencies range + * from 0.6 MHz to 17 MHz, which corresponds to a minimum SYNC_IN pulse + * width of approximately 2.5 µs in the worst-case scenario (0.6 MHz). + * + * Add a delay to ensure the pulse width is always sufficient to + * trigger synchronization. + */ + gpiod_set_value_cansleep(st->gpio_sync_in, 1); + fsleep(3); + gpiod_set_value_cansleep(st->gpio_sync_in, 0); + + return 0; +} + static int ad7768_set_mode(struct ad7768_state *st, enum ad7768_conv_mode mode) { @@ -288,10 +306,7 @@ static int ad7768_set_dig_fil(struct ad7768_state *st, return ret;

/* A sync-in pulse is required every time the filter dec rate changes */ - gpiod_set_value(st->gpio_sync_in, 1); - gpiod_set_value(st->gpio_sync_in, 0); - - return 0; + return ad7768_send_sync_pulse(st); }

static int ad7768_set_freq(struct ad7768_state *st,