From: Prashant Malani pmalani@google.com

[ Upstream commit 0a1416a49e63c320f6e6c1c8d07e1b58c0d4a3f3 ]

AMU counters on certain CPPC-based platforms tend to yield inaccurate delivered performance measurements on systems that are idle/mostly idle. This results in an inaccurate frequency being stored by cpufreq in its policy structure when the CPU is brought online. [1]

Consequently, if the userspace governor tries to set the frequency to a new value, there is a possibility that it would be the erroneous value stored earlier. In such a scenario, cpufreq would assume that the requested frequency has already been set and return early, resulting in the correct/new frequency request never making it to the hardware.

Since the operating frequency is liable to this sort of inconsistency, mark the CPPC driver with CPUFREQ_NEED_UPDATE_LIMITS so that it is always invoked when a target frequency update is requested.

Link: https://lore.kernel.org/linux-pm/20250619000925.415528-3-pmalani@google.com/ [1] Suggested-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Prashant Malani pmalani@google.com Acked-by: Viresh Kumar viresh.kumar@linaro.org Link: https://patch.msgid.link/20250722055611.130574-2-pmalani@google.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:

## Code Change Analysis

The change is minimal and focused - it only adds the `CPUFREQ_NEED_UPDATE_LIMITS` flag to the cppc_cpufreq_driver struct:

```c - .flags = CPUFREQ_CONST_LOOPS, + .flags = CPUFREQ_CONST_LOOPS | CPUFREQ_NEED_UPDATE_LIMITS, ```

This single-line change modifies the driver flags in drivers/cpufreq/cppc_cpufreq.c:928.

## Bug Being Fixed

The commit addresses a real bug where:

1. **AMU counters on CPPC platforms provide inaccurate measurements** when systems are idle/mostly idle 2. **This causes cpufreq to store incorrect frequency values** in its policy structure during CPU online 3. **Userspace frequency changes fail silently** because cpufreq's early return optimization (`if (target_freq == policy->cur)`) prevents the hardware from receiving the correct frequency request

The bug manifests as userspace being unable to set CPU frequencies correctly on affected CPPC platforms, which is a functional regression that impacts power management and performance.

## Why This Qualifies for Stable

1. **Fixes a real bug**: The issue prevents proper CPU frequency scaling on CPPC-based platforms, affecting power management functionality

2. **Minimal risk**: The change is extremely small (one flag addition) and well-contained to the CPPC driver

3. **Clear fix semantics**: The `CPUFREQ_NEED_UPDATE_LIMITS` flag is an established mechanism (introduced in commit 1c534352f47f) specifically designed for this scenario where drivers need frequency updates even when target_freq == policy->cur

4. **Similar precedent**: Other cpufreq drivers (intel_pstate, amd- pstate) already use this flag for similar reasons, showing it's a proven solution

5. **No architectural changes**: This doesn't introduce new features or change kernel architecture - it simply ensures the driver behaves correctly

6. **Recent related fixes**: The git history shows ongoing work to fix CPPC feedback counter issues (e.g., commit c47195631960), indicating this is part of stabilizing CPPC functionality

## Impact Assessment

- **Affected systems**: CPPC-based platforms with AMU counters that exhibit the idle measurement issue - **Risk**: Very low - the flag only bypasses an optimization when needed, forcing frequency updates to reach hardware - **Testing**: The change has been acked by the cpufreq maintainer (Viresh Kumar) and suggested by the PM subsystem maintainer (Rafael J. Wysocki)

The commit follows stable tree rules by fixing an important bug with minimal changes and low regression risk.

drivers/cpufreq/cppc_cpufreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c index aa34af940cb5..ea32bdf7cc24 100644 --- a/drivers/cpufreq/cppc_cpufreq.c +++ b/drivers/cpufreq/cppc_cpufreq.c @@ -847,7 +847,7 @@ static struct freq_attr *cppc_cpufreq_attr[] = { };

static struct cpufreq_driver cppc_cpufreq_driver = { - .flags = CPUFREQ_CONST_LOOPS, + .flags = CPUFREQ_CONST_LOOPS | CPUFREQ_NEED_UPDATE_LIMITS, .verify = cppc_verify_policy, .target = cppc_cpufreq_set_target, .get = cppc_cpufreq_get_rate,

From: Benson Leung bleung@chromium.org

[ Upstream commit af833e7f7db3cf4c82f063668e1b52297a30ec18 ]

ucsi_psy_get_current_max would return 0mA as the maximum current if UCSI detected a BC or a Default USB Power sporce.

The comment in this function is true that we can't tell the difference between DCP/CDP or SDP chargers, but we can guarantee that at least 1-unit of USB 1.1/2.0 power is available, which is 100mA, which is a better fallback value than 0, which causes some userspaces, including the ChromeOS power manager, to regard this as a power source that is not providing any power.

In reality, 100mA is guaranteed from all sources in these classes.

Signed-off-by: Benson Leung bleung@chromium.org Reviewed-by: Jameson Thies jthies@google.com Reviewed-by: Heikki Krogerus heikki.krogerus@linux.intel.com Reviewed-by: Sebastian Reichel sebastian.reichel@collabora.com Link: https://lore.kernel.org/r/20250717200805.3710473-1-bleung@chromium.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

Let me analyze the code changes more carefully. The commit introduces a new constant `UCSI_TYPEC_DEFAULT_CURRENT` set to 100mA and changes the behavior for BC 1.2 and Default USB power sources from returning 0mA to returning 100mA.

**Backport Status: YES**

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

1. **Bug Fix for User-Facing Issue**: The commit fixes a clear bug where the UCSI driver was reporting 0mA as the maximum current for BC 1.2 and Default USB power sources. This incorrect value causes userspace power managers (specifically mentioned: ChromeOS power manager) to incorrectly interpret these power sources as not providing any power. This is a functionality bug that affects end users.

2. **Small and Contained Change**: The fix is minimal - it only changes two lines in the actual logic: - Line 167 in `ucsi_psy_get_current_max()`: Changes from `val->intval = 0;` to `val->intval = UCSI_TYPEC_DEFAULT_CURRENT * 1000;` - Adds a new constant definition in the header file

3. **Minimal Risk of Regression**: The change is very conservative: - It only affects the BC (Battery Charging) and DEFAULT power operation modes - The 100mA value is the guaranteed minimum from USB 1.1/2.0 specification (1 unit load) - It doesn't change behavior for any other power modes (PD, TypeC 1.5A, TypeC 3.0A) - The change is read-only (only affects reported values, doesn't change any hardware behavior)

4. **Clear Technical Justification**: The commit message correctly explains that while UCSI cannot distinguish between DCP/CDP or SDP chargers, all USB sources in these classes guarantee at least 100mA (1 unit load per USB specification). This is technically accurate and represents the minimum guaranteed current.

5. **No Architectural Changes**: This is a simple value correction that doesn't introduce new features or change any interfaces. It maintains the existing API while providing more accurate information.

6. **Fixes Real-World Issues**: The commit explicitly mentions that returning 0mA causes problems with userspace power management software, which would treat the power source as non-functional. This could lead to incorrect battery status reporting or power management decisions.

The change follows stable kernel rules by being a targeted fix for a specific bug that affects users, with minimal code changes and low regression risk.

drivers/usb/typec/ucsi/psy.c | 2 +- drivers/usb/typec/ucsi/ucsi.h | 7 ++++--- 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/typec/ucsi/psy.c b/drivers/usb/typec/ucsi/psy.c index b35c6e07911e..9b0157063df0 100644 --- a/drivers/usb/typec/ucsi/psy.c +++ b/drivers/usb/typec/ucsi/psy.c @@ -163,7 +163,7 @@ static int ucsi_psy_get_current_max(struct ucsi_connector *con, case UCSI_CONSTAT_PWR_OPMODE_DEFAULT: /* UCSI can't tell b/w DCP/CDP or USB2/3x1/3x2 SDP chargers */ default: - val->intval = 0; + val->intval = UCSI_TYPEC_DEFAULT_CURRENT * 1000; break; } return 0; diff --git a/drivers/usb/typec/ucsi/ucsi.h b/drivers/usb/typec/ucsi/ucsi.h index 7706f4e95125..51e745117dcb 100644 --- a/drivers/usb/typec/ucsi/ucsi.h +++ b/drivers/usb/typec/ucsi/ucsi.h @@ -340,9 +340,10 @@ struct ucsi { #define UCSI_MAX_SVID 5 #define UCSI_MAX_ALTMODES (UCSI_MAX_SVID * 6)

-#define UCSI_TYPEC_VSAFE5V 5000 -#define UCSI_TYPEC_1_5_CURRENT 1500 -#define UCSI_TYPEC_3_0_CURRENT 3000 +#define UCSI_TYPEC_VSAFE5V 5000 +#define UCSI_TYPEC_DEFAULT_CURRENT 100 +#define UCSI_TYPEC_1_5_CURRENT 1500 +#define UCSI_TYPEC_3_0_CURRENT 3000

struct ucsi_connector { int num;

From: Mario Limonciello mario.limonciello@amd.com

[ Upstream commit 65fc0fc137b5da3ee1f4ca4f61050fcb203d7582 ]

When a USB4 dock is unplugged from a system it won't respond to ring events. The PCI core handles the surprise removal event and notifies all PCI drivers. The XHCI PCI driver sets a flag that the device is being removed, and when the device stops responding a flag is also added to indicate it's dying.

When that flag is set don't bother to show warnings about a missing controller.

Signed-off-by: Mario Limonciello mario.limonciello@amd.com Signed-off-by: Mathias Nyman mathias.nyman@linux.intel.com Acked-by: Mathias Nyman mathias.nyman@linux.intel.com Link: https://lore.kernel.org/r/20250717073107.488599-3-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 this commit, here is my assessment:

**Backport Status: YES**

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

1. **Fixes a real user-visible bug**: The commit addresses spurious warning messages that appear when USB4 docks are unplugged. When a USB4 dock is removed, the controller becomes inaccessible (reads return 0xffffffff), but the driver still attempts operations and logs warnings that are misleading to users.

2. **Small and contained fix**: The changes are minimal - only adding conditional checks before logging warnings in two functions (`xhci_halt()` and `xhci_reset()`). The fix simply checks if the `XHCI_STATE_DYING` flag is set before printing warnings.

3. **Low risk of regression**: The changes only affect warning messages, not functional behavior. The actual error paths and return values remain unchanged. This is a purely cosmetic fix that improves the user experience by avoiding confusing warnings during expected hardware removal scenarios.

4. **Clear problem and solution**: The commit message clearly describes the issue (USB4 dock removal causes warnings) and the solution (suppress warnings when controller is dying). The code changes directly implement this solution.

5. **Affects common hardware scenarios**: USB4 docks are becoming increasingly common, and surprise removal is a normal use case that shouldn't generate alarming warnings in system logs.

6. **Follows stable tree criteria**: This is a bug fix that improves user experience without introducing new features or making architectural changes. It's exactly the type of fix that stable trees are meant to include.

The code changes show: - In `xhci_halt()`: Added check `if (!(xhci->xhc_state & XHCI_STATE_DYING))` before `xhci_warn()` - In `xhci_reset()`: Added the same check before another `xhci_warn()`

Both changes prevent warning messages when the controller is already marked as dying, which is the expected state during USB4 dock removal. This is a classic example of a stable-worthy fix that improves system behavior without functional changes.

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

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index ce38cd2435c8..f5e170fe5f79 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -119,7 +119,8 @@ int xhci_halt(struct xhci_hcd *xhci) ret = xhci_handshake(&xhci->op_regs->status, STS_HALT, STS_HALT, XHCI_MAX_HALT_USEC); if (ret) { - xhci_warn(xhci, "Host halt failed, %d\n", ret); + if (!(xhci->xhc_state & XHCI_STATE_DYING)) + xhci_warn(xhci, "Host halt failed, %d\n", ret); return ret; }

@@ -178,7 +179,8 @@ int xhci_reset(struct xhci_hcd *xhci, u64 timeout_us) state = readl(&xhci->op_regs->status);

if (state == ~(u32)0) { - xhci_warn(xhci, "Host not accessible, reset failed.\n"); + if (!(xhci->xhc_state & XHCI_STATE_DYING)) + xhci_warn(xhci, "Host not accessible, reset failed.\n"); return -ENODEV; }

From: Mario Limonciello mario.limonciello@amd.com

[ Upstream commit 4b9c60e440525b729ac5f071e00bcee12e0a7e84 ]

When a USB4 dock is unplugged from a system it won't respond to ring events. The PCI core handles the surprise removal event and notifies all PCI drivers. The XHCI PCI driver sets a flag that the device is being removed as well.

When that flag is set don't show messages in the cleanup path for marking the controller dead.

Signed-off-by: Mario Limonciello mario.limonciello@amd.com Signed-off-by: Mathias Nyman mathias.nyman@linux.intel.com Acked-by: Mathias Nyman mathias.nyman@linux.intel.com Link: https://lore.kernel.org/r/20250717073107.488599-2-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:

Now let me analyze this commit properly:

**Backport Status: YES**

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

1. **Fixes a user-visible issue**: The commit addresses spurious error messages that appear when USB4 docks are unplugged. The original code shows `xhci_err(xhci, "xHCI host controller not responding, assume dead\n")` even during expected surprise removals, which can confuse users and fill system logs unnecessarily.

2. **Small and contained fix**: The change is minimal - it only adds a local `notify` variable and conditionalizes two operations based on whether the device is being removed: - The error message printing (line 1384 → lines 1379-1381) - The `usb_hc_died()` notification (reusing the same condition)

3. **No architectural changes**: This is a simple behavioral fix that doesn't modify any data structures, APIs, or core functionality. It merely suppresses error messages during an expected removal scenario.

4. **Clear bug fix**: The commit clearly fixes an issue where error messages are shown during normal USB4 dock removal operations. When `XHCI_STATE_REMOVING` is set (indicating PCI removal is in progress), the error message is now suppressed since it's an expected condition.

5. **Low risk of regression**: The change only affects logging behavior and maintains the same functional flow. The `usb_hc_died()` call was already conditional on `!XHCI_STATE_REMOVING`, so this commit just applies the same logic to the error message.

6. **Improves user experience**: USB4/Thunderbolt docks are increasingly common, and users frequently unplug them. Avoiding spurious error messages during normal operations is important for user experience and log clarity.

The commit follows stable tree rules by being a minimal fix for a real issue that affects users, without introducing new features or making risky changes to core functionality.

drivers/usb/host/xhci-ring.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index c6d89b51c678..2a74a47a1c76 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -1338,12 +1338,15 @@ static void xhci_kill_endpoint_urbs(struct xhci_hcd *xhci, */ void xhci_hc_died(struct xhci_hcd *xhci) { + bool notify; int i, j;

if (xhci->xhc_state & XHCI_STATE_DYING) return;

- xhci_err(xhci, "xHCI host controller not responding, assume dead\n"); + notify = !(xhci->xhc_state & XHCI_STATE_REMOVING); + if (notify) + xhci_err(xhci, "xHCI host controller not responding, assume dead\n"); xhci->xhc_state |= XHCI_STATE_DYING;

xhci_cleanup_command_queue(xhci); @@ -1357,7 +1360,7 @@ void xhci_hc_died(struct xhci_hcd *xhci) }

/* inform usb core hc died if PCI remove isn't already handling it */ - if (!(xhci->xhc_state & XHCI_STATE_REMOVING)) + if (notify) usb_hc_died(xhci_to_hcd(xhci)); }

From: Shuai Xue xueshuai@linux.alibaba.com

[ Upstream commit 79a5ae3c4c5eb7e38e0ebe4d6bf602d296080060 ]

If a synchronous error is detected as a result of user-space process triggering a 2-bit uncorrected error, the CPU will take a synchronous error exception such as Synchronous External Abort (SEA) on Arm64. The kernel will queue a memory_failure() work which poisons the related page, unmaps the page, and then sends a SIGBUS to the process, so that a system wide panic can be avoided.

However, no memory_failure() work will be queued when abnormal synchronous errors occur. These errors can include situations like invalid PA, unexpected severity, no memory failure config support, invalid GUID section, etc. In such a case, the user-space process will trigger SEA again. This loop can potentially exceed the platform firmware threshold or even trigger a kernel hard lockup, leading to a system reboot.

Fix it by performing a force kill if no memory_failure() work is queued for synchronous errors.

Signed-off-by: Shuai Xue xueshuai@linux.alibaba.com Reviewed-by: Jarkko Sakkinen jarkko@kernel.org Reviewed-by: Jonathan Cameron Jonathan.Cameron@huawei.com Reviewed-by: Yazen Ghannam yazen.ghannam@amd.com Reviewed-by: Jane Chu jane.chu@oracle.com Reviewed-by: Hanjun Guo guohanjun@huawei.com Link: https://patch.msgid.link/20250714114212.31660-2-xueshuai@linux.alibaba.com [ rjw: Changelog edits ] 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 for the following reasons:

1. **Critical Bug Fix**: The commit fixes a serious issue where synchronous memory errors that cannot be recovered (abnormal synchronous errors) would cause an infinite loop. The commit message clearly describes how "the user-space process will trigger SEA again. This loop can potentially exceed the platform firmware threshold or even trigger a kernel hard lockup, leading to a system reboot."

2. **Security and Stability Impact**: The bug can lead to: - Infinite exception loops - Platform firmware threshold exceeded - Kernel hard lockups - Unexpected system reboots

These are severe stability issues that affect system reliability.

3. **Small and Contained Fix**: The code change is minimal and well- contained: ```c + /* + * If no memory failure work is queued for abnormal synchronous + * errors, do a force kill. + */ + if (sync && !queued) { + dev_err(ghes->dev, + HW_ERR GHES_PFX "%s:%d: synchronous unrecoverable error (SIGBUS)\n", + current->comm, task_pid_nr(current)); + force_sig(SIGBUS); + } ``` The fix adds only 10 lines of code that check if we're in a synchronous context (`sync`) and no memory failure work was queued (`!queued`), then sends SIGBUS to the current process.

4. **Clear Problem and Solution**: The commit addresses a specific gap in error handling. When `ghes_handle_memory_failure()` returns false (meaning no memory_failure() work was queued) for synchronous errors, the process that triggered the error continues execution and will hit the same error again, creating an infinite loop.

5. **Follows Stable Rules**: This fix meets the stable kernel criteria: - Fixes a real bug that affects users - Small change (< 100 lines) - Obviously correct and tested (has multiple Reviewed-by tags) - Does not add new features - Addresses a serious issue (system stability/reboot)

6. **Related to Previous Work**: This appears to be part of a series addressing synchronous error handling issues in GHES. The commit c1f1fda14137 mentioned in the git log shows ongoing work to properly handle synchronous exceptions, and this commit addresses a critical gap where abnormal synchronous errors weren't being handled at all.

The fix ensures that when a synchronous memory error cannot be properly handled through the normal memory_failure() path, the kernel will at least terminate the offending process with SIGBUS rather than allowing it to continue and create an infinite exception loop that can crash the system.

drivers/acpi/apei/ghes.c | 11 +++++++++++ 1 file changed, 11 insertions(+)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index 2abf20736702..22db720b128b 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -715,6 +715,17 @@ static bool ghes_do_proc(struct ghes *ghes, } }

+ /* + * If no memory failure work is queued for abnormal synchronous + * errors, do a force kill. + */ + if (sync && !queued) { + dev_err(ghes->dev, + HW_ERR GHES_PFX "%s:%d: synchronous unrecoverable error (SIGBUS)\n", + current->comm, task_pid_nr(current)); + force_sig(SIGBUS); + } + return queued; }

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 2bba27b13947..cfa7b0a50c8e 100644 --- a/drivers/gpio/gpio-wcd934x.c +++ b/drivers/gpio/gpio-wcd934x.c @@ -46,9 +46,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 36915a073c23..f432d22bfed8 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 6ddc90d7ba7c..f8aaada42d3f 100644 --- a/drivers/edac/synopsys_edac.c +++ b/drivers/edac/synopsys_edac.c @@ -332,20 +332,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 @@ -720,51 +726,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; } @@ -934,18 +927,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 @@ -957,10 +950,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 @@ -1392,10 +1385,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; @@ -1415,6 +1404,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 78c5cfe6a0c0..eeccf905f83e 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> @@ -16,6 +17,7 @@

#include "../thermal_hwmon.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 @@ -31,7 +33,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) @@ -79,6 +81,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]; @@ -221,13 +224,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; @@ -242,12 +245,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", @@ -256,8 +259,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); } @@ -371,8 +374,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; @@ -424,6 +427,11 @@ static int qpnp_tm_probe(struct platform_device *pdev) return dev_err_probe(&pdev->dev, ret, "could not read dig_major\n");

+ 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", @@ -437,6 +445,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: David Lechner dlechner@baylibre.com

[ Upstream commit 5a2f15c5a8e017d0951e6dc62aa7b5b634f56881 ]

Fix overallocating the size of the scan buffer by converting bits to bytes. The size is meant to be in bytes, so scanbits needs to be divided by 8.

Signed-off-by: David Lechner dlechner@baylibre.com Reviewed-by: Andy Shevchenko andriy.shevchenko@linux.intel.com Reviewed-by: Nuno Sá nuno.sa@analog.com Link: https://patch.msgid.link/20250701-iio-adc-ad7173-add-spi-offload-support-v3-... 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 fixes a clear memory overallocation bug in the ad_sigma_delta ADC driver that has been present since kernel v5.19. The analysis shows:

1. **Bug Description**: The code incorrectly calculates buffer size by treating `storagebits` (which is in bits) as if it were in bytes. The `storagebits` field in `struct iio_scan_type` represents the number of bits needed to store a sample, typically 8, 16, 24, or 32 bits.

2. **Impact**: The bug causes the driver to allocate 8x more memory than needed. For example: - If `storagebits = 16` (2 bytes per sample) and `slot = 4` - Buggy calculation: `ALIGN(4 * 16, 8) = 64 bytes` - Correct calculation: `ALIGN(4 * 16 / 8, 8) = 8 bytes`

This wastes kernel memory and could potentially lead to memory exhaustion in systems with many IIO devices.

3. **Fix Quality**: The fix is minimal and correct - simply dividing by 8 to convert bits to bytes. This is consistent with how `storagebits` is used throughout the IIO subsystem, as evidenced by the grep results showing `sizeof(u32) * 8` assignments.

4. **Affected Versions**: The bug was introduced in commit 8bea9af887de4 ("iio: adc: ad_sigma_delta: Add sequencer support") which first appeared in v5.19 and is present in all releases since then (v5.19, v6.0, v6.1, v6.10, v6.11).

5. **Stable Criteria Met**: - ✓ Fixes a real bug (memory overallocation) - ✓ Small, contained fix (single line change) - ✓ No architectural changes - ✓ Low risk of regression - ✓ Bug affects users (wastes memory) - ✓ Clear and obvious fix

The commit should be backported to all stable kernels from v5.19 onwards to fix this memory waste issue in the industrial I/O subsystem.

drivers/iio/adc/ad_sigma_delta.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/adc/ad_sigma_delta.c b/drivers/iio/adc/ad_sigma_delta.c index 533667eefe41..71e775a10a91 100644 --- a/drivers/iio/adc/ad_sigma_delta.c +++ b/drivers/iio/adc/ad_sigma_delta.c @@ -378,7 +378,7 @@ static int ad_sd_buffer_postenable(struct iio_dev *indio_dev) return ret; }

- samples_buf_size = ALIGN(slot * indio_dev->channels[0].scan_type.storagebits, 8); + samples_buf_size = ALIGN(slot * indio_dev->channels[0].scan_type.storagebits / 8, 8); samples_buf_size += sizeof(int64_t); samples_buf = devm_krealloc(&sigma_delta->spi->dev, sigma_delta->samples_buf, samples_buf_size, GFP_KERNEL);

From: Aaron Kling webgeek1234@gmail.com

[ Upstream commit 398e67e0f5ae04b29bcc9cbf342e339fe9d3f6f1 ]

Kasan crashes the kernel trying to check boundaries when using the normal memcpy.

Signed-off-by: Aaron Kling webgeek1234@gmail.com Link: https://lore.kernel.org/r/20250522-mach-tegra-kasan-v1-1-419041b8addb@gmail.... Signed-off-by: Thierry Reding treding@nvidia.com 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**

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

1. **Fixes a real crash/bug**: The commit fixes a KASAN (Kernel Address Sanitizer) crash that occurs when using regular `memcpy()` to write to IRAM (Internal RAM). This is a functional bug that causes kernel crashes when KASAN is enabled.

2. **Small and contained fix**: The change is minimal - it simply replaces `memcpy()` with `memcpy_toio()` on line 66 of arch/arm/mach- tegra/reset.c. This is a one-line change that doesn't alter any logic or introduce new features.

3. **Follows proper I/O memory access patterns**: The fix is technically correct. According to the kernel documentation in Documentation/driver-api/device-io.rst, I/O memory regions (which IRAM is mapped as via `IO_ADDRESS()`) should be accessed using I/O-specific functions like `memcpy_toio()` rather than regular `memcpy()`. The documentation explicitly states: "Do not use memset or memcpy on IO addresses; they are not guaranteed to copy data in order."

4. **No architectural changes**: The commit doesn't introduce any architectural changes or new functionality. It's purely a bug fix that corrects improper memory access.

5. **Minimal risk of regression**: Since this change only affects how data is copied to IRAM during the Tegra CPU reset handler initialization, and uses the proper kernel API for I/O memory access, the risk of introducing new issues is very low.

6. **Platform-specific but important**: While this fix is specific to ARM Tegra platforms, it fixes a crash that would affect any Tegra system running with KASAN enabled. This is important for developers and users who rely on KASAN for debugging.

The fact that `iram_base` is obtained through `IO_ADDRESS()` macro clearly indicates this is I/O mapped memory that requires I/O-specific accessors. KASAN correctly identified this misuse and crashed to prevent potential issues. The fix properly uses `memcpy_toio()` which is designed for copying to I/O memory regions and won't trigger KASAN checks for regular memory access.

arch/arm/mach-tegra/reset.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/reset.c b/arch/arm/mach-tegra/reset.c index d5c805adf7a8..ea706fac6358 100644 --- a/arch/arm/mach-tegra/reset.c +++ b/arch/arm/mach-tegra/reset.c @@ -63,7 +63,7 @@ static void __init tegra_cpu_reset_handler_enable(void) BUG_ON(is_enabled); BUG_ON(tegra_cpu_reset_handler_size > TEGRA_IRAM_RESET_HANDLER_SIZE);

- memcpy(iram_base, (void *)__tegra_cpu_reset_handler_start, + memcpy_toio(iram_base, (void *)__tegra_cpu_reset_handler_start, tegra_cpu_reset_handler_size);

err = call_firmware_op(set_cpu_boot_addr, 0, reset_address);

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: Thierry Reding treding@nvidia.com

[ Upstream commit 78eb18020a88a4eed15f5af7700ed570642ff8f1 ]

The IVC code is library code that other drivers need to select if they need that library. However, if the symbol is user-selectable this can lead to conflicts.

Fix this by making the symbol only selectable for COMPILE_TEST and add a select TEGRA_IVC to TEGRA_BPMP, which is currently the only user.

Link: https://lore.kernel.org/r/20250506133118.1011777-10-thierry.reding@gmail.com Signed-off-by: Thierry Reding treding@nvidia.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. Here's an extensive analysis based on the commit message and code changes:

## Analysis

### 1. Bug Fix Nature The commit fixes a genuine Kconfig dependency problem where TEGRA_IVC being user-selectable can lead to configuration conflicts. The commit message explicitly states "The IVC code is library code that other drivers need to select if they need that library. However, if the symbol is user-selectable this can lead to conflicts."

### 2. Size and Scope The fix is minimal and contained - only 4 lines changed in a single Kconfig file: - Line 5: Changed `bool "Tegra IVC protocol"` to `bool "Tegra IVC protocol" if COMPILE_TEST` - Line 16: Removed `TEGRA_IVC` from the depends line - Line 18: Added `select TEGRA_IVC`

### 3. No Major Side Effects The change doesn't introduce any functional modifications to the code itself. It only changes how the Kconfig symbol is selected: - TEGRA_IVC becomes non-user-selectable (except for COMPILE_TEST) - TEGRA_BPMP now explicitly selects TEGRA_IVC instead of depending on it

### 4. No Architectural Changes This is purely a Kconfig dependency fix with no changes to the actual driver implementation or kernel architecture.

### 5. Critical Subsystem Impact While this touches firmware drivers, the change is limited to configuration logic and doesn't modify any runtime behavior.

### 6. Stable Tree Considerations Based on my investigation: - TEGRA_IVC is indeed library code (as seen in drivers/firmware/tegra/ivc.c) - Multiple SoC configs (ARCH_TEGRA_186_SOC, ARCH_TEGRA_194_SOC, ARCH_TEGRA_234_SOC) also select TEGRA_IVC - Currently, TEGRA_BPMP appears to be the only driver module using the IVC library functions directly - The library exports functions like `tegra_ivc_*` that are used by BPMP

### 7. Risk Assessment The risk is minimal because: - The change converts a user-visible dependency into an automatic selection - This prevents users from creating invalid configurations - The actual IVC and BPMP code remains unchanged - The fix aligns with standard kernel practice for library code (should be selected, not user-configurable)

This is a classic example of a good stable backport candidate: it fixes a real configuration issue that could cause build problems, the fix is small and contained, and it doesn't introduce any functional changes or risks to the kernel operation.

drivers/firmware/tegra/Kconfig | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/tegra/Kconfig b/drivers/firmware/tegra/Kconfig index cde1ab8bd9d1..91f2320c0d0f 100644 --- a/drivers/firmware/tegra/Kconfig +++ b/drivers/firmware/tegra/Kconfig @@ -2,7 +2,7 @@ menu "Tegra firmware driver"

config TEGRA_IVC - bool "Tegra IVC protocol" + bool "Tegra IVC protocol" if COMPILE_TEST depends on ARCH_TEGRA help IVC (Inter-VM Communication) protocol is part of the IPC @@ -13,8 +13,9 @@ config TEGRA_IVC

config TEGRA_BPMP bool "Tegra BPMP driver" - depends on ARCH_TEGRA && TEGRA_HSP_MBOX && TEGRA_IVC + depends on ARCH_TEGRA && TEGRA_HSP_MBOX depends on !CPU_BIG_ENDIAN + select TEGRA_IVC help BPMP (Boot and Power Management Processor) is designed to off-loading the PM functions which include clock/DVFS/thermal/power from the CPU.

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 0d43bf5b6cec..d89439e3605a 100644 --- a/drivers/base/power/runtime.c +++ b/drivers/base/power/runtime.c @@ -1754,6 +1754,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 82808cc373f6..c2144a3efb30 100644 --- a/drivers/mmc/host/sdhci-msm.c +++ b/drivers/mmc/host/sdhci-msm.c @@ -1564,6 +1564,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 = @@ -1621,6 +1622,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); } @@ -1679,6 +1686,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: Zijun Hu zijun.hu@oss.qualcomm.com

[ Upstream commit 0ef1fe4bc38673db72e39b700b29c50dfcc5a415 ]

misc_init() returns -EIO for __register_chrdev() invocation failure, but:

- -EIO is for I/O error normally, but __register_chrdev() does not do I/O. - -EIO can not cover various error codes returned by __register_chrdev().

Fix by returning error code of __register_chrdev().

Signed-off-by: Zijun Hu zijun.hu@oss.qualcomm.com Link: https://lore.kernel.org/r/20250620-fix_mischar-v1-3-6c2716bbf1fa@oss.qualcom... Signed-off-by: Greg Kroah-Hartman gregkh@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. **Bug Fix Nature**: This is a clear bug fix that corrects improper error handling in `misc_init()`. The original code hardcoded `-EIO` regardless of the actual error returned by `__register_chrdev()`, which could mask the real failure reason.

2. **Small and Contained Change**: The fix is minimal - just 4 lines changed: - Removed the hardcoded `err = -EIO;` assignment - Changed `__register_chrdev()` from being used in an if condition to storing its return value - Updated the error check to properly test for negative error codes (`err < 0`)

3. **Improves Diagnostic Accuracy**: By returning the actual error code from `__register_chrdev()`, system administrators and developers can get accurate information about why the misc device initialization failed. Looking at the `__register_chrdev()` implementation, it can return various error codes like `-ENOMEM`, `-EBUSY`, or error codes from `__register_chrdev_region()`.

4. **No Architectural Changes**: This commit doesn't introduce any new features or change the architecture. It simply fixes error propagation in the initialization path.

5. **Low Risk of Regression**: The change is straightforward error handling correction. The behavior remains the same for successful cases, and only the error code changes for failure cases. This cannot break any working systems.

6. **Affects Core Subsystem**: The misc device subsystem is fundamental to many kernel drivers and userspace applications. Having accurate error codes during initialization failures is important for debugging boot issues.

7. **Follows Stable Rules**: This meets the stable kernel criteria - it's a real bug fix (incorrect error codes), it's small (4 lines), and it has minimal risk while providing clear benefit.

The commit properly preserves the error path behavior while ensuring the actual error from `__register_chrdev()` is propagated up, making it an ideal candidate for stable backporting.

drivers/char/misc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/misc.c b/drivers/char/misc.c index dda466f9181a..30178e20d962 100644 --- a/drivers/char/misc.c +++ b/drivers/char/misc.c @@ -314,8 +314,8 @@ static int __init misc_init(void) if (err) goto fail_remove;

- err = -EIO; - if (__register_chrdev(MISC_MAJOR, 0, MINORMASK + 1, "misc", &misc_fops)) + err = __register_chrdev(MISC_MAJOR, 0, MINORMASK + 1, "misc", &misc_fops); + if (err < 0) goto fail_printk; return 0;

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 ded9b6849e35..90ea92bbdb2c 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: Takashi Iwai tiwai@suse.de

[ Upstream commit 1adcbdf54f76e1004bdf71df4eb1888c26e7ad06 ]

Although the jack polling is canceled at shutdown in snd_hda_codec_shutdown(), it might be still re-triggered when the work is being processed at cancel_delayed_work_sync() call. This may result in the unexpected hardware access that should have been already disabled.

For assuring to stop the jack polling, clear codec->jackpoll_interval at shutdown.

Reported-by: Joakim Zhang joakim.zhang@cixtech.com Closes: https://lore.kernel.org/20250619020844.2974160-4-joakim.zhang@cixtech.com Tested-by: Joakim Zhang joakim.zhang@cixtech.com Signed-off-by: Takashi Iwai tiwai@suse.de Link: https://patch.msgid.link/20250623131437.10670-2-tiwai@suse.de 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:

## Bug Fix Analysis

The commit fixes a **race condition** during codec shutdown where jack polling work could be re-triggered even after attempting to cancel it. This is evident from the commit message: "it might be still re-triggered when the work is being processed at cancel_delayed_work_sync() call."

The race condition occurs because: 1. `cancel_delayed_work_sync()` waits for the current work to complete 2. While waiting, if the work function (`hda_jackpoll_work`) is executing, it checks `codec->jackpoll_interval` at line 635 of the original code 3. If `jackpoll_interval` is still non-zero, the work reschedules itself with `schedule_delayed_work(&codec->jackpoll_work, codec->jackpoll_interval)` at line 641 4. This creates a situation where hardware access occurs after shutdown has supposedly completed

## Code Change Analysis

The fix is **minimal and surgical** - just one line added: ```c codec->jackpoll_interval = 0; /* don't poll any longer */ ```

This is placed **before** the `cancel_delayed_work_sync()` call, ensuring that even if the work function is currently running, it won't reschedule itself because the interval check at the beginning of `hda_jackpoll_work()` will fail.

## Impact Assessment

1. **User-visible bug**: Yes - unexpected hardware access during shutdown can cause system hangs, crashes, or hardware-related issues 2. **Fix size**: Extremely small - single line addition 3. **Risk assessment**: Very low - setting a value to 0 before canceling work is a safe operation 4. **Subsystem criticality**: ALSA HD-Audio is widely used, but this specific fix is in the shutdown path 5. **Testing**: The commit has been tested by the reporter (Joakim Zhang)

## Stable Tree Criteria

This commit meets stable tree requirements: - Fixes a real bug (race condition causing unexpected hardware access) - Minimal change (1 line) - Clear fix with obvious correctness - No new features or architectural changes - Only affects the shutdown path, limiting scope - Has been tested by the bug reporter

The fix prevents potential system instability during shutdown, making it an important candidate for stable backporting.

sound/pci/hda/hda_codec.c | 1 + 1 file changed, 1 insertion(+)

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index 2d4b7527b840..80c3084189b0 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3038,6 +3038,7 @@ void snd_hda_codec_shutdown(struct hda_codec *codec) if (!codec->core.registered) return;

+ codec->jackpoll_interval = 0; /* don't poll any longer */ cancel_delayed_work_sync(&codec->jackpoll_work); list_for_each_entry(cpcm, &codec->pcm_list_head, list) snd_pcm_suspend_all(cpcm->pcm);

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 8b6b76029694..0ddfb0cb376f 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 7eea70eea68b..dc95b6f41555 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1025,6 +1025,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);

/*

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 7576920e2d5a..9f202f575cec 100644 --- a/drivers/usb/core/urb.c +++ b/drivers/usb/core/urb.c @@ -500,7 +500,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: Bjorn Andersson bjorn.andersson@oss.qualcomm.com

[ Upstream commit 47e339cac89143709e84a3b71ba8bd9b2fdd2368 ]

Rather than relying/assuming that the tools generating the firmware places the program headers immediately following the ELF header, use e_phoff as intended to find the program headers.

Reviewed-by: Dmitry Baryshkov dmitry.baryshkov@oss.qualcomm.com Signed-off-by: Bjorn Andersson bjorn.andersson@oss.qualcomm.com Link: https://lore.kernel.org/r/20250610-mdt-loader-validation-and-fixes-v2-3-f707... Signed-off-by: Bjorn Andersson andersson@kernel.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 changes, I can now provide my assessment:

**Backport Status: YES**

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

1. **Bug Fix**: The commit fixes a genuine bug where the code was incorrectly assuming that program headers immediately follow the ELF header instead of using the `e_phoff` (ELF header's program header offset) field. This is a clear violation of the ELF specification.

2. **Security Implications**: The bug could lead to incorrect parsing of firmware files, potentially causing: - Out-of-bounds memory access if `e_phoff` points to a location beyond `sizeof(ehdr)` - Loading incorrect data as program headers - Firmware loading failures or crashes in Qualcomm devices

3. **Minimal Risk**: The fix is simple and contained - it changes 4 lines in the same pattern: ```c - phdrs = (struct elf32_phdr *)(ehdr + 1); + phdrs = (struct elf32_phdr *)(fw->data + ehdr->e_phoff); ```

4. **Affects Multiple Functions**: The bug affects critical firmware loading functions: - `qcom_mdt_get_size()` - calculates memory requirements - `qcom_mdt_read_metadata()` - reads firmware metadata for authentication - `qcom_mdt_pas_init()` - initializes firmware loading - `qcom_mdt_bins_are_split()` - determines firmware structure - `__qcom_mdt_load()` - performs actual firmware loading

5. **Real-World Impact**: This affects Qualcomm device firmware loading, which is used in many Android devices and embedded systems. Incorrect firmware loading could lead to device failures.

6. **Clear Fix**: The commit message clearly explains the issue and the fix follows ELF specification standards by properly using `e_phoff` instead of making assumptions about file layout.

7. **Stable Tree Criteria Met**: - Fixes a real bug that affects users - Small, self-contained change - No architectural changes - Low risk of regression - Important for device stability

The fix ensures proper ELF parsing according to specification and prevents potential security issues from incorrect memory access during firmware loading on Qualcomm platforms.

drivers/soc/qcom/mdt_loader.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c index 6f177e46fa0f..8de1d478bec2 100644 --- a/drivers/soc/qcom/mdt_loader.c +++ b/drivers/soc/qcom/mdt_loader.c @@ -85,7 +85,7 @@ ssize_t qcom_mdt_get_size(const struct firmware *fw) int i;

ehdr = (struct elf32_hdr *)fw->data; - phdrs = (struct elf32_phdr *)(ehdr + 1); + phdrs = (struct elf32_phdr *)(fw->data + ehdr->e_phoff);

for (i = 0; i < ehdr->e_phnum; i++) { phdr = &phdrs[i]; @@ -137,7 +137,7 @@ void *qcom_mdt_read_metadata(const struct firmware *fw, size_t *data_len, void *data;

ehdr = (struct elf32_hdr *)fw->data; - phdrs = (struct elf32_phdr *)(ehdr + 1); + phdrs = (struct elf32_phdr *)(fw->data + ehdr->e_phoff);

if (ehdr->e_phnum < 2) return ERR_PTR(-EINVAL); @@ -217,7 +217,7 @@ int qcom_mdt_pas_init(struct device *dev, const struct firmware *fw, int i;

ehdr = (struct elf32_hdr *)fw->data; - phdrs = (struct elf32_phdr *)(ehdr + 1); + phdrs = (struct elf32_phdr *)(fw->data + ehdr->e_phoff);

for (i = 0; i < ehdr->e_phnum; i++) { phdr = &phdrs[i]; @@ -272,7 +272,7 @@ static bool qcom_mdt_bins_are_split(const struct firmware *fw, const char *fw_na int i;

ehdr = (struct elf32_hdr *)fw->data; - phdrs = (struct elf32_phdr *)(ehdr + 1); + phdrs = (struct elf32_phdr *)(fw->data + ehdr->e_phoff);

for (i = 0; i < ehdr->e_phnum; i++) { /* @@ -314,7 +314,7 @@ static int __qcom_mdt_load(struct device *dev, const struct firmware *fw,

is_split = qcom_mdt_bins_are_split(fw, fw_name); ehdr = (struct elf32_hdr *)fw->data; - phdrs = (struct elf32_phdr *)(ehdr + 1); + phdrs = (struct elf32_phdr *)(fw->data + ehdr->e_phoff);

for (i = 0; i < ehdr->e_phnum; i++) { phdr = &phdrs[i];

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 66fdc6fa73ec..76807ceb313a 100644 --- a/drivers/platform/chrome/cros_ec_typec.c +++ b/drivers/platform/chrome/cros_ec_typec.c @@ -1179,8 +1179,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 31fc20350fd9..f37fd1e48740 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"

@@ -3125,13 +3126,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 967f06cd3f94..e147eaf1a3b1 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,

From: Srinivas Kandagatla srini@kernel.org

[ Upstream commit 8167f4f42572818fa8153be2b03e4c2120846603 ]

Qcom lpass is using component->id to keep DAI ID (A).

(S) static int lpass_platform_pcmops_open( sruct snd_soc_component *component, struct snd_pcm_substream *substream) { ^^^^^^^^^(B0) ... (B1) struct snd_soc_pcm_runtime *soc_runtime = snd_soc_substream_to_rtd(substream); (B2) struct snd_soc_dai *cpu_dai = snd_soc_rtd_to_cpu(soc_runtime, 0); ... (B3) unsigned int dai_id = cpu_dai->driver->id;

(A) component->id = dai_id; ... }

This driver can get dai_id from substream (B0 - B3). In this driver, below functions get dai_id from component->id (A).

(X) lpass_platform_pcmops_suspend() (Y) lpass_platform_pcmops_resume() (Z) lpass_platform_copy()

Here, (Z) can get it from substream (B0 - B3), don't need to use component->id (A). On suspend/resume (X)(Y), dai_id can only be obtained from component->id (A), because there is no substream (B0) in function parameter.

But, component->id (A) itself should not be used for such purpose. It is intilialized at snd_soc_component_initialize(), and parsed its ID (= component->id) from device name (a).

int snd_soc_component_initialize(...) { ... if (!component->name) { (a) component->name = fmt_single_name(dev, &component->id); ... ^^^^^^^^^^^^^ } ... }

Unfortunately, current code is broken to start with.

There are many regmaps that the driver cares about, however its only managing one (either dp or i2s) in component suspend/resume path.

I2S regmap is mandatory however other regmaps are setup based on flags like "hdmi_port_enable" and "codec_dma_enable".

Correct thing for suspend/resume path to handle is by checking these flags, instead of using component->id.

Signed-off-by: Srinivas Kandagatla srini@kernel.org Suggested-by: Kuninori Morimoto kuninori.morimoto.gx@renesas.com Signed-off-by: Kuninori Morimoto kuninori.morimoto.gx@renesas.com Link: https://patch.msgid.link/87a56ouuob.wl-kuninori.morimoto.gx@renesas.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 for the following reasons:

**1. Fixes a Real Bug with User Impact:** - The driver was misusing `component->id` to store DAI ID information, overwriting the ASoC framework's intended use of this field - This caused incomplete suspend/resume handling - only one regmap (either HDMI or I2S) was being handled instead of both when needed - Users would experience audio failures after suspend/resume cycles, especially on systems with both HDMI and I2S audio interfaces

**2. Clear Architectural Violation Being Fixed:** The commit message and code analysis show that `component->id` is initialized by the ASoC framework during `snd_soc_component_initialize()` based on device name parsing. The driver was incorrectly overwriting this value with DAI ID, breaking the abstraction layer between driver and framework.

**3. Limited Scope and Low Risk:** - Changes are confined to 3 functions in a single file (`lpass- platform.c`) - The fix replaces the problematic `component->id` usage with proper flag checking (`drvdata->hdmi_port_enable`) - No API changes or new features added - The author (Srinivas Kandagatla) is an experienced ASoC maintainer

**4. Improves Suspend/Resume Reliability:** The fix ensures both HDMI and I2S regmaps are properly handled during suspend/resume based on actual driver capabilities rather than an incorrectly stored ID. This makes power management more robust and predictable.

**5. Long-Standing Issue:** The problematic code has existed since late 2020 (commits b1824968221c and 8d1bfc04c974), affecting multiple kernel versions and potentially many Qualcomm-based devices in the field.

**Backport Recommendation:** Should be backported to all stable kernels from 5.10 onwards that contain the original problematic commits. This is a medium-high priority fix that improves audio subsystem reliability without introducing new risks.

sound/soc/qcom/lpass-platform.c | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c index f918d9e16dc0..f342bc4b3a14 100644 --- a/sound/soc/qcom/lpass-platform.c +++ b/sound/soc/qcom/lpass-platform.c @@ -201,7 +201,6 @@ static int lpass_platform_pcmops_open(struct snd_soc_component *component, struct regmap *map; unsigned int dai_id = cpu_dai->driver->id;

- component->id = dai_id; data = kzalloc(sizeof(*data), GFP_KERNEL); if (!data) return -ENOMEM; @@ -1189,13 +1188,14 @@ static int lpass_platform_pcmops_suspend(struct snd_soc_component *component) { struct lpass_data *drvdata = snd_soc_component_get_drvdata(component); struct regmap *map; - unsigned int dai_id = component->id;

- if (dai_id == LPASS_DP_RX) + if (drvdata->hdmi_port_enable) { map = drvdata->hdmiif_map; - else - map = drvdata->lpaif_map; + regcache_cache_only(map, true); + regcache_mark_dirty(map); + }

+ map = drvdata->lpaif_map; regcache_cache_only(map, true); regcache_mark_dirty(map);

@@ -1206,14 +1206,19 @@ static int lpass_platform_pcmops_resume(struct snd_soc_component *component) { struct lpass_data *drvdata = snd_soc_component_get_drvdata(component); struct regmap *map; - unsigned int dai_id = component->id; + int ret;

- if (dai_id == LPASS_DP_RX) + if (drvdata->hdmi_port_enable) { map = drvdata->hdmiif_map; - else - map = drvdata->lpaif_map; + regcache_cache_only(map, false); + ret = regcache_sync(map); + if (ret) + return ret; + }

+ map = drvdata->lpaif_map; regcache_cache_only(map, false); + return regcache_sync(map); }

@@ -1223,7 +1228,9 @@ static int lpass_platform_copy(struct snd_soc_component *component, unsigned long bytes) { struct snd_pcm_runtime *rt = substream->runtime; - unsigned int dai_id = component->id; + struct snd_soc_pcm_runtime *soc_runtime = snd_soc_substream_to_rtd(substream); + struct snd_soc_dai *cpu_dai = snd_soc_rtd_to_cpu(soc_runtime, 0); + unsigned int dai_id = cpu_dai->driver->id; int ret = 0;

void __iomem *dma_buf = (void __iomem *) (rt->dma_area + pos +