From: Dave Penkler dpenkler@gmail.com

[ Upstream commit f50d5e0c1f80d004510bf77cb0e1759103585c00 ]

A new version of a bona fide genuine NI-USB-HS+ adaptor sends new response codes to the initialization sequence.

Add the checking for these response codes to suppress console warning messages.

Signed-off-by: Dave Penkler dpenkler@gmail.com Link: https://lore.kernel.org/r/20250722164810.2621-1-dpenkler@gmail.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, I'll now provide my assessment of whether this commit should be backported to stable kernel trees.

**Backport Status: YES**

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

## Commit Analysis

The commit adds support for new response codes from newer NI-USB-HS+ hardware adaptors. Looking at the specific code changes:

1. **Lines 2082-2086**: The comment is updated from "NI-USB-HS+ sends 0xf here" to "NI-USB-HS+ sends 0xf or 0x19 here", and the check is expanded to accept 0x19 as a valid response code.

2. **Lines 2113-2119**: The comment is updated to indicate that new HS+ hardware sends 0x59 at position [10], and the check is expanded to accept 0x59 as a valid response code.

## Rationale for Backporting

1. **Fixes a Real User Issue**: This fixes a bug where newer NI-USB-HS+ hardware generates console warning messages due to unrecognized response codes. Without this fix, users with newer hardware see error messages like "unexpected data: buffer[x]=0x19, expected..." when the hardware is actually functioning correctly.

2. **Minimal Risk**: The change is extremely contained - it only adds two additional valid response codes (0x19 and 0x59) to existing validation checks. No logic changes, no structural modifications, just expanding the set of accepted values.

3. **Hardware Compatibility**: This is a hardware enablement fix that allows Linux to properly support newer versions of existing hardware without generating spurious warnings.

4. **Staging Driver Context**: While this is in staging, the gpib subsystem appears to be actively maintained (based on recent commit history), and hardware compatibility fixes are important for users of this specialized equipment.

5. **Clear Bug Fix**: The commit message explicitly states it "suppress[es] console warning messages" - this is fixing incorrect error reporting, not adding new features.

6. **No Architectural Changes**: The patch doesn't change any APIs, data structures, or driver architecture. It's purely adding two constants to existing validation logic.

7. **Tested Hardware**: The commit message indicates this was tested with "a bona fide genuine NI-USB-HS+ adaptor", suggesting real hardware validation.

## Stable Tree Criteria Met

- ✓ Fixes a bug that affects users (spurious warnings with newer hardware) - ✓ Small and contained change (4 lines modified) - ✓ No side effects beyond the intended fix - ✓ No architectural changes - ✓ Hardware enablement for existing driver

The commit clearly meets the stable tree criteria as a minimal hardware compatibility fix that resolves user-visible warnings without any risk of regression.

drivers/staging/gpib/ni_usb/ni_usb_gpib.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/gpib/ni_usb/ni_usb_gpib.c b/drivers/staging/gpib/ni_usb/ni_usb_gpib.c index 9f1b9927f025..56d3b62249b8 100644 --- a/drivers/staging/gpib/ni_usb/ni_usb_gpib.c +++ b/drivers/staging/gpib/ni_usb/ni_usb_gpib.c @@ -2069,10 +2069,10 @@ static int ni_usb_hs_wait_for_ready(struct ni_usb_priv *ni_priv) } if (buffer[++j] != 0x0) { // [6] ready = 1; - // NI-USB-HS+ sends 0xf here + // NI-USB-HS+ sends 0xf or 0x19 here if (buffer[j] != 0x2 && buffer[j] != 0xe && buffer[j] != 0xf && - buffer[j] != 0x16) { - dev_err(&usb_dev->dev, "unexpected data: buffer[%i]=0x%x, expected 0x2, 0xe, 0xf or 0x16\n", + buffer[j] != 0x16 && buffer[j] != 0x19) { + dev_err(&usb_dev->dev, "unexpected data: buffer[%i]=0x%x, expected 0x2, 0xe, 0xf, 0x16 or 0x19\n", j, (int)buffer[j]); unexpected = 1; } @@ -2100,11 +2100,11 @@ static int ni_usb_hs_wait_for_ready(struct ni_usb_priv *ni_priv) j, (int)buffer[j]); unexpected = 1; } - if (buffer[++j] != 0x0) { + if (buffer[++j] != 0x0) { // [10] MC usb-488 sends 0x7 here, new HS+ sends 0x59 ready = 1; - if (buffer[j] != 0x96 && buffer[j] != 0x7 && buffer[j] != 0x6e) { -// [10] MC usb-488 sends 0x7 here - dev_err(&usb_dev->dev, "unexpected data: buffer[%i]=0x%x, expected 0x96, 0x07 or 0x6e\n", + if (buffer[j] != 0x96 && buffer[j] != 0x7 && buffer[j] != 0x6e && + buffer[j] != 0x59) { + dev_err(&usb_dev->dev, "unexpected data: buffer[%i]=0x%x, expected 0x96, 0x07, 0x6e or 0x59\n", j, (int)buffer[j]); unexpected = 1; }

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 cb93f00bafdb..156c1e516cc8 100644 --- a/drivers/cpufreq/cppc_cpufreq.c +++ b/drivers/cpufreq/cppc_cpufreq.c @@ -816,7 +816,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 62ac69730405..62a9d68bb66d 100644 --- a/drivers/usb/typec/ucsi/psy.c +++ b/drivers/usb/typec/ucsi/psy.c @@ -164,7 +164,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 70910232a05d..1ae068a92844 100644 --- a/drivers/usb/typec/ucsi/ucsi.h +++ b/drivers/usb/typec/ucsi/ucsi.h @@ -479,9 +479,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: Romain Gantois romain.gantois@bootlin.com

[ Upstream commit d511206dc7443120637efd9cfa3ab06a26da33dd ]

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

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

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

initial voltage: 2.5V

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

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

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

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

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

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

## Bug Description and Impact

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

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

## Code Analysis

The fix adds a retry mechanism specifically for stepped regulators:

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

## Why This Is a Good Backport Candidate

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

## Specific Code References

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

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

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

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 90629a756693..dbb14f79e44e 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -3797,6 +3797,16 @@ static int _regulator_do_set_suspend_voltage(struct regulator_dev *rdev, return 0; }

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

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

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

From: 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 cb9f35acb1f9..cb29aa49ceba 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -120,7 +120,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; }

@@ -179,7 +180,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 8be033f1877d..fc3ae7318046 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -1376,12 +1376,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); @@ -1395,7 +1398,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: Maulik Shah maulik.shah@oss.qualcomm.com

[ Upstream commit 84684c57c9cd47b86c883a7170dd68222d97ef13 ]

Register offsets for v3 and v4 versions are backward compatible. Assign v3 offsets for v4 and all higher versions to avoid end up using v2 offsets.

Signed-off-by: Maulik Shah maulik.shah@oss.qualcomm.com Reviewed-by: Konrad Dybcio konrad.dybcio@oss.qualcomm.com Reviewed-by: Neil Armstrong neil.armstrong@linaro.org Link: https://lore.kernel.org/r/20250623-rsc_v4-v1-1-275b27bc5e3c@oss.qualcomm.com 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, here is my assessment:

**Backport Status: YES**

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

1. **Bug Fix Nature**: The commit fixes a real bug where RSC version 4 devices would incorrectly use version 2.7 register offsets instead of version 3.0 offsets. The code change shows that before this fix, only `drv->ver.major == 3` would select v3 offsets, meaning version 4 (and any higher versions) would fall through to use v2.7 offsets, which are incompatible.

2. **Clear Register Offset Incompatibility**: Looking at the register offset arrays in drivers/soc/qcom/rpmh-rsc.c: - v2.7 offsets: RSC_DRV_CMD_OFFSET = 20, RSC_DRV_CMD_WAIT_FOR_CMPL = 0x10 - v3.0 offsets: RSC_DRV_CMD_OFFSET = 24, RSC_DRV_CMD_WAIT_FOR_CMPL = 0x20

These are significantly different offsets that would cause incorrect hardware register access on v4 devices.

3. **Small and Contained Fix**: The change is minimal - just changing `if (drv->ver.major == 3)` to `if (drv->ver.major >= 3)`. This is a one-line logic fix that ensures v4 and higher versions use the correct v3.0-compatible register offsets.

4. **Hardware Enablement for Existing Devices**: This is not adding new features but fixing broken support for hardware that already exists. Without this fix, any Qualcomm SoC with RSC v4 would malfunction when trying to use RPMH (Resource Power Manager Hardened) functionality.

5. **Low Risk**: The change only affects devices with RSC version 4 or higher. It doesn't modify behavior for existing v2 or v3 devices. The commit message explicitly states that "Register offsets for v3 and v4 versions are backward compatible."

6. **Critical Subsystem**: RPMH-RSC is a critical component for power management on Qualcomm SoCs. Incorrect register access could lead to system instability, power management failures, or complete inability to boot on affected devices.

The commit follows stable kernel rules by being a targeted bug fix that enables proper hardware support without architectural changes or new features.

drivers/soc/qcom/rpmh-rsc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c index cb82e887b51d..fdab2b1067db 100644 --- a/drivers/soc/qcom/rpmh-rsc.c +++ b/drivers/soc/qcom/rpmh-rsc.c @@ -1072,7 +1072,7 @@ static int rpmh_rsc_probe(struct platform_device *pdev) drv->ver.minor = rsc_id & (MINOR_VER_MASK << MINOR_VER_SHIFT); drv->ver.minor >>= MINOR_VER_SHIFT;

- if (drv->ver.major == 3) + if (drv->ver.major >= 3) drv->regs = rpmh_rsc_reg_offset_ver_3_0; else drv->regs = rpmh_rsc_reg_offset_ver_2_7;

From: Hiago De Franco hiago.franco@toradex.com

[ Upstream commit 496deecb020d14ba89ba7084fbc3024f91687023 ]

For the i.MX8X and i.MX8 family SoCs, when the Cortex-M core is powered up and started by the Cortex-A core using the bootloader (e.g., via the U-Boot bootaux command), both M-core and Linux run within the same SCFW (System Controller Firmware) partition. With that, Linux has permission to control the M-core.

But once the M-core is started by the bootloader, the SCFW automatically enables its clock and sets the clock rate. If Linux later attempts to enable the same clock via clk_prepare_enable(), the SCFW returns a 'LOCKED' error, as the clock is already configured by the SCFW. This causes the probe function in imx_rproc.c to fail, leading to the M-core power domain being shut down while the core is still running. This results in a fault from the SCU (System Controller Unit) and triggers a system reset.

To address this issue, ignore handling the clk for i.MX8X and i.MX8 M-core, as SCFW already takes care of enabling and configuring the clock.

Suggested-by: Peng Fan peng.fan@nxp.com Reviewed-by: Ulf Hansson ulf.hansson@linaro.org Reviewed-by: Peng Fan peng.fan@nxp.com Signed-off-by: Hiago De Franco hiago.franco@toradex.com Acked-by: Mathieu Poirier mathieu.poirier@linaro.org Link: https://lore.kernel.org/r/20250629172512.14857-3-hiagofranco@gmail.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:

Based on my analysis, I can now provide a definitive answer:

**Backport Status: YES**

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

1. **Critical bug fix preventing system reset**: The commit fixes a serious issue where the probe function failure causes the M-core power domain to be shut down while the core is still running, resulting in a fault from the SCU and triggering a system reset. This is a severe user-impacting bug that can cause unexpected system reboots.

2. **Minimal and contained change**: The fix is very simple - it just adds `|| dcfg->method == IMX_RPROC_SCU_API` to an existing condition in the `imx_rproc_clk_enable()` function. This is a one-line change that only affects the clock handling logic for i.MX8X and i.MX8 family SoCs when using SCU API method.

3. **Clear root cause**: The commit message clearly explains the issue - when the M-core is started by the bootloader, the SCFW automatically enables its clock. If Linux later attempts to enable the same clock, SCFW returns a 'LOCKED' error, causing probe failure and subsequent power domain shutdown while the core is running.

4. **No architectural changes**: This is purely a bug fix that doesn't introduce new features or change the driver architecture. It simply skips clock operations for a specific configuration where the clock is already managed by the SCFW.

5. **Platform-specific fix with no regression risk**: The change only affects i.MX8X and i.MX8 platforms using the SCU API method (`IMX_RPROC_SCU_API`). Other platforms and methods are unaffected, minimizing the risk of regression.

6. **Prevents data corruption/loss**: System resets caused by this bug could potentially lead to data loss or corruption, making this fix important for system stability.

The specific code change in `imx_rproc_clk_enable()` at line 1033 simply extends the existing check from: ```c if (dcfg->method == IMX_RPROC_NONE) ``` to: ```c if (dcfg->method == IMX_RPROC_NONE || dcfg->method == IMX_RPROC_SCU_API) ```

This ensures that for SCU-managed cores, Linux doesn't attempt to enable clocks that are already controlled by the SCFW, preventing the probe failure and subsequent system reset.

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

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c index 74299af1d7f1..627e57a88db2 100644 --- a/drivers/remoteproc/imx_rproc.c +++ b/drivers/remoteproc/imx_rproc.c @@ -1029,8 +1029,8 @@ static int imx_rproc_clk_enable(struct imx_rproc *priv) struct device *dev = priv->dev; int ret;

- /* Remote core is not under control of Linux */ - if (dcfg->method == IMX_RPROC_NONE) + /* Remote core is not under control of Linux or it is managed by SCU API */ + if (dcfg->method == IMX_RPROC_NONE || dcfg->method == IMX_RPROC_SCU_API) return 0;

priv->clk = devm_clk_get(dev, NULL);

From: Binbin Zhou zhoubinbin@loongson.cn

[ Upstream commit 27cb8f702eb789f97f7a8bd5a91d76c65a937b2f ]

Add the interrupt enable register offset (inten_offset) so that GPIO interrupts can be enabled normally on more models.

According to the latest interface specifications, the definition of GPIO interrupts in ACPI is similar to that in FDT. The GPIO interrupts are listed one by one according to the GPIO number, and the corresponding interrupt number can be obtained directly through the GPIO number specified by the consumer.

Signed-off-by: Xi Ruoyao xry111@xry111.site Signed-off-by: Binbin Zhou zhoubinbin@loongson.cn Reviewed-by: Huacai Chen chenhuacai@loongson.cn Link: https://lore.kernel.org/r/20250714064542.2276247-1-zhoubinbin@loongson.cn [Bartosz: tweaked the commit message] Signed-off-by: Bartosz Golaszewski bartosz.golaszewski@linaro.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

This commit is suitable for backporting to stable kernel trees for the following reasons:

1. **Fixes a bug affecting users**: The commit addresses a functional issue where GPIO interrupts cannot be enabled properly on several Loongson models (ls2k2000, ls3a5000, ls7a, ls7a2000). Looking at the code in `loongson_gpio_to_irq()` (lines 120-136), the function relies on `chip_data->inten_offset` being set to properly enable interrupts. Without this offset, the conditional check at line 167 (`if (lgpio->chip_data->inten_offset)`) prevents the `to_irq` callback from being registered, effectively breaking GPIO interrupt functionality.

2. **Small and contained fix**: The changes are minimal - only adding the missing `inten_offset` values to existing chip data structures. The patch adds 4 lines: - Line 225: `.inten_offset = 0x14,` for ls2k2000_data0 - Line 233: `.inten_offset = 0x30,` for ls2k2000_data1 - Line 249: `.inten_offset = 0x14,` for ls3a5000_data - Line 257: `.inten_offset = 0xb00,` for ls7a_data - Line 266: `.inten_offset = 0xb00,` for ls7a2000_data0 - Line 284: `.inten_offset = 0x14,` for ls3a6000_data

3. **No architectural changes**: This is a simple data fix that adds missing hardware register offsets. It doesn't change any logic, APIs, or introduce new features.

4. **Low regression risk**: The change only affects the specific Loongson models mentioned and only enables functionality that was previously broken. It cannot break existing working configurations since it only adds missing data.

5. **Hardware enablement fix**: This is essentially a hardware enablement bug fix that allows proper interrupt handling on affected Loongson platforms. Without this fix, GPIO interrupts are completely non-functional on these chips.

The commit follows stable tree rules by being a clear bug fix with minimal changes and low risk. The fact that other similar chip data structures already had `inten_offset` defined (like ls2k_data, ls2k0500_data0/1) shows this was an oversight that needed correction.

drivers/gpio/gpio-loongson-64bit.c | 6 ++++++ 1 file changed, 6 insertions(+)

diff --git a/drivers/gpio/gpio-loongson-64bit.c b/drivers/gpio/gpio-loongson-64bit.c index 286a3876ed0c..fd8686d8583a 100644 --- a/drivers/gpio/gpio-loongson-64bit.c +++ b/drivers/gpio/gpio-loongson-64bit.c @@ -220,6 +220,7 @@ static const struct loongson_gpio_chip_data loongson_gpio_ls2k2000_data0 = { .conf_offset = 0x0, .in_offset = 0xc, .out_offset = 0x8, + .inten_offset = 0x14, };

static const struct loongson_gpio_chip_data loongson_gpio_ls2k2000_data1 = { @@ -228,6 +229,7 @@ static const struct loongson_gpio_chip_data loongson_gpio_ls2k2000_data1 = { .conf_offset = 0x0, .in_offset = 0x20, .out_offset = 0x10, + .inten_offset = 0x30, };

static const struct loongson_gpio_chip_data loongson_gpio_ls2k2000_data2 = { @@ -244,6 +246,7 @@ static const struct loongson_gpio_chip_data loongson_gpio_ls3a5000_data = { .conf_offset = 0x0, .in_offset = 0xc, .out_offset = 0x8, + .inten_offset = 0x14, };

static const struct loongson_gpio_chip_data loongson_gpio_ls7a_data = { @@ -252,6 +255,7 @@ static const struct loongson_gpio_chip_data loongson_gpio_ls7a_data = { .conf_offset = 0x800, .in_offset = 0xa00, .out_offset = 0x900, + .inten_offset = 0xb00, };

/* LS7A2000 chipset GPIO */ @@ -261,6 +265,7 @@ static const struct loongson_gpio_chip_data loongson_gpio_ls7a2000_data0 = { .conf_offset = 0x800, .in_offset = 0xa00, .out_offset = 0x900, + .inten_offset = 0xb00, };

/* LS7A2000 ACPI GPIO */ @@ -279,6 +284,7 @@ static const struct loongson_gpio_chip_data loongson_gpio_ls3a6000_data = { .conf_offset = 0x0, .in_offset = 0xc, .out_offset = 0x8, + .inten_offset = 0x14, };

static const struct of_device_id loongson_gpio_of_match[] = {

From: André Draszik andre.draszik@linaro.org

[ Upstream commit 31611223fb34a3e9320cdfc4f4395072a13ea78e ]

This driver calls enable_irq_wake() during probe() unconditionally, and never issues the required corresponding disable_irq_wake() to disable hardware interrupt wakeup signals.

Additionally, whether or not a device should wake-up the system is meant to be a policy decision based on sysfs (.../power/wakeup) in the first place.

Update the driver to use the standard approach to enable/disable IRQ wake during the suspend/resume callbacks. This solves both issues described above.

Signed-off-by: André Draszik andre.draszik@linaro.org Reviewed-by: Badhri Jagan Sridharan badhri@google.com Link: https://lore.kernel.org/r/20250707-max77759-irq-wake-v1-1-d367f633e4bc@linar... 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. **Clear Bug Fix**: The commit fixes a resource management bug where `enable_irq_wake()` is called during probe without a corresponding `disable_irq_wake()`. This violates the kernel's IRQ wake API usage requirements, leading to: - Resource leak in the IRQ subsystem - Incorrect wake behavior that cannot be controlled via sysfs - Potential system power management issues

2. **Small and Contained Change**: The fix is minimal and well- contained: - Removes the problematic `max_tcpci_init_alert()` function - Moves IRQ request directly into probe - Adds proper suspend/resume callbacks with correct `enable_irq_wake()`/`disable_irq_wake()` pairing - Total change is about 40 lines of straightforward code

3. **Low Risk of Regression**: - The change follows established kernel patterns for IRQ wake handling in PM callbacks - Similar patterns exist in other USB Type-C drivers (e.g., fusb302.c uses suspend/resume for IRQ wake) - The fix only affects power management behavior, not core functionality - Uses `device_may_wakeup()` to properly check policy before enabling wake

4. **Clear Impact on Users**: - Without this fix, devices cannot properly control wake-on-USB-C events through sysfs - The unconditional `enable_irq_wake()` means the device will always wake the system on USB-C events, regardless of user preference - This affects power consumption and battery life on systems with USB Type-C

5. **No Architectural Changes**: The commit: - Doesn't introduce new features - Doesn't change any APIs or interfaces - Simply fixes incorrect usage of existing kernel APIs - Maintains backward compatibility

The commit message clearly explains the problem and solution, the code changes are minimal and correct, and it fixes a real bug that affects system power management behavior. This is exactly the type of fix that stable kernels should receive.

drivers/usb/typec/tcpm/tcpci_maxim_core.c | 46 +++++++++++++++-------- 1 file changed, 30 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/typec/tcpm/tcpci_maxim_core.c b/drivers/usb/typec/tcpm/tcpci_maxim_core.c index b5a5ed40faea..ff3604be79da 100644 --- a/drivers/usb/typec/tcpm/tcpci_maxim_core.c +++ b/drivers/usb/typec/tcpm/tcpci_maxim_core.c @@ -421,21 +421,6 @@ static irqreturn_t max_tcpci_isr(int irq, void *dev_id) return IRQ_WAKE_THREAD; }

-static int max_tcpci_init_alert(struct max_tcpci_chip *chip, struct i2c_client *client) -{ - int ret; - - ret = devm_request_threaded_irq(chip->dev, client->irq, max_tcpci_isr, max_tcpci_irq, - (IRQF_TRIGGER_LOW | IRQF_ONESHOT), dev_name(chip->dev), - chip); - - if (ret < 0) - return ret; - - enable_irq_wake(client->irq); - return 0; -} - static int max_tcpci_start_toggling(struct tcpci *tcpci, struct tcpci_data *tdata, enum typec_cc_status cc) { @@ -532,7 +517,9 @@ static int max_tcpci_probe(struct i2c_client *client)

chip->port = tcpci_get_tcpm_port(chip->tcpci);

- ret = max_tcpci_init_alert(chip, client); + ret = devm_request_threaded_irq(&client->dev, client->irq, max_tcpci_isr, max_tcpci_irq, + (IRQF_TRIGGER_LOW | IRQF_ONESHOT), dev_name(chip->dev), + chip); if (ret < 0) return dev_err_probe(&client->dev, ret, "IRQ initialization failed\n"); @@ -544,6 +531,32 @@ static int max_tcpci_probe(struct i2c_client *client) return 0; }

+#ifdef CONFIG_PM_SLEEP +static int max_tcpci_resume(struct device *dev) +{ + struct i2c_client *client = to_i2c_client(dev); + int ret = 0; + + if (client->irq && device_may_wakeup(dev)) + ret = disable_irq_wake(client->irq); + + return ret; +} + +static int max_tcpci_suspend(struct device *dev) +{ + struct i2c_client *client = to_i2c_client(dev); + int ret = 0; + + if (client->irq && device_may_wakeup(dev)) + ret = enable_irq_wake(client->irq); + + return ret; +} +#endif /* CONFIG_PM_SLEEP */ + +static SIMPLE_DEV_PM_OPS(max_tcpci_pm_ops, max_tcpci_suspend, max_tcpci_resume); + static const struct i2c_device_id max_tcpci_id[] = { { "maxtcpc" }, { } @@ -562,6 +575,7 @@ static struct i2c_driver max_tcpci_i2c_driver = { .driver = { .name = "maxtcpc", .of_match_table = of_match_ptr(max_tcpci_of_match), + .pm = &max_tcpci_pm_ops, }, .probe = max_tcpci_probe, .id_table = max_tcpci_id,

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: Li RongQing lirongqing@baidu.com

[ Upstream commit fc64e0421598aaa87d61184f6777b52614a095be ]

Users may disable HWP in firmware, in which case intel_pstate wouldn't load unless the CPU model is explicitly supported.

Signed-off-by: Li RongQing lirongqing@baidu.com Link: https://patch.msgid.link/20250623105601.3924-1-lirongqing@baidu.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 the extensive analysis:

**Nature of the Change:** The commit adds support for Intel Granite Rapids processors (both D and X variants) in the intel_pstate driver when Hardware P-states (HWP) is disabled in firmware. This is a hardware enablement patch that adds two new CPU model IDs to existing lists: - `INTEL_GRANITERAPIDS_D` and `INTEL_GRANITERAPIDS_X` are added to `intel_pstate_cpu_ids[]` table

**Why This Is a Good Backport Candidate:**

1. **Fixes a Real User-Facing Issue**: Without this patch, users who have Granite Rapids CPUs with HWP disabled in firmware cannot use the intel_pstate driver at all. The commit message explicitly states "intel_pstate wouldn't load unless the CPU model is explicitly supported." This means affected systems would fall back to less efficient CPU frequency scaling drivers, significantly impacting performance and power efficiency.

2. **Minimal and Safe Change**: The patch only adds two lines to an existing CPU ID table: ```c + X86_MATCH(INTEL_GRANITERAPIDS_D, core_funcs), + X86_MATCH(INTEL_GRANITERAPIDS_X, core_funcs), ``` These entries follow the exact same pattern as all other CPU entries and use the standard `core_funcs` handler, which is already used by many other Intel CPU models.

3. **No Architectural Changes**: The commit doesn't introduce any new features, modify existing logic, or change any kernel interfaces. It's purely a hardware enablement patch that extends existing functionality to new hardware.

4. **Low Risk of Regression**: - The change is contained entirely within CPU model detection tables - It only affects systems with the specific Granite Rapids CPU models - Uses the well-tested `core_funcs` implementation already used by Sapphire Rapids, Emerald Rapids, and other server CPUs - The code path is only triggered on systems with these specific CPUs

5. **Follows Established Pattern**: Looking at the surrounding code, Granite Rapids entries were already present in the `intel_pstate_cpu_oob_ids[]` table (for out-of-band control), indicating this is completing support that was partially added previously.

6. **Important for Server Deployments**: Granite Rapids is a server CPU platform, and enterprise users often disable HWP for specific workload requirements or compatibility reasons. Without this patch, they lose access to the intel_pstate driver entirely.

The commit meets all the criteria for stable backporting: it fixes a real bug (driver fails to load on supported hardware), the fix is minimal and contained, there's no risk to existing systems, and it provides important functionality for affected users.

drivers/cpufreq/intel_pstate.c | 2 ++ 1 file changed, 2 insertions(+)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index ba9bf06f1c77..48fe6c0fa7c7 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -2656,6 +2656,8 @@ static const struct x86_cpu_id intel_pstate_cpu_ids[] = { X86_MATCH(INTEL_TIGERLAKE, core_funcs), X86_MATCH(INTEL_SAPPHIRERAPIDS_X, core_funcs), X86_MATCH(INTEL_EMERALDRAPIDS_X, core_funcs), + X86_MATCH(INTEL_GRANITERAPIDS_D, core_funcs), + X86_MATCH(INTEL_GRANITERAPIDS_X, core_funcs), {} }; MODULE_DEVICE_TABLE(x86cpu, intel_pstate_cpu_ids);

From: Lifeng Zheng zhenglifeng1@huawei.com

[ Upstream commit 914cc799b28f17d369d5b4db3b941957d18157e8 ]

Replace sscanf() with kstrtoul() in set_freq_store() and check the result to avoid invalid input.

Signed-off-by: Lifeng Zheng zhenglifeng1@huawei.com Link: https://lore.kernel.org/lkml/20250421030020.3108405-2-zhenglifeng1@huawei.co... Signed-off-by: Chanwoo Choi cw00.choi@samsung.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. **Security Issue - Input Validation Bug**: The original code uses `sscanf(buf, "%lu", &wanted)` at line 45 without checking the return value. This is a security vulnerability because: - `sscanf()` returns the number of successfully parsed items - If the input is malformed or contains invalid characters, `sscanf()` may return 0 but leave `wanted` uninitialized - The code then proceeds to use this potentially uninitialized value in `data->user_frequency = wanted` - This could lead to setting arbitrary frequency values from uninitialized stack data

2. **Real User Impact**: The devfreq userspace governor allows users to manually set device frequencies through sysfs. Invalid input handling could cause: - Setting incorrect frequencies based on uninitialized memory - Potential system instability if invalid frequencies are applied to hardware - Security implications as uninitialized stack data could be used

3. **Small and Contained Fix**: The change is minimal and low-risk: - Replaces `sscanf()` with `kstrtoul()` which has proper error checking - Adds explicit error handling that returns early on invalid input - The change is confined to a single function (`set_freq_store()`) - No architectural changes or new features added

4. **Follows Kernel Best Practices**: The kernel has been systematically replacing `sscanf()` with `kstrto*()` functions for better input validation. This is evident from similar commits found in the git log (e.g., commit a5556fa1107d for asus-wmi).

5. **Critical Subsystem**: While devfreq might not be as critical as core memory management, it controls device frequency scaling which can affect: - Power management - System performance - Hardware stability

6. **No Negative Side Effects**: The change only adds proper validation and doesn't modify the core functionality. Valid inputs will continue to work exactly as before.

The commit fixes a clear bug (missing input validation) that could lead to undefined behavior and potential security issues, making it an excellent candidate for stable backporting according to stable tree rules.

drivers/devfreq/governor_userspace.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/devfreq/governor_userspace.c b/drivers/devfreq/governor_userspace.c index d1aa6806b683..175de0c0b50e 100644 --- a/drivers/devfreq/governor_userspace.c +++ b/drivers/devfreq/governor_userspace.c @@ -9,6 +9,7 @@ #include <linux/slab.h> #include <linux/device.h> #include <linux/devfreq.h> +#include <linux/kstrtox.h> #include <linux/pm.h> #include <linux/mutex.h> #include <linux/module.h> @@ -39,10 +40,13 @@ static ssize_t set_freq_store(struct device *dev, struct device_attribute *attr, unsigned long wanted; int err = 0;

+ err = kstrtoul(buf, 0, &wanted); + if (err) + return err; + mutex_lock(&devfreq->lock); data = devfreq->governor_data;

- sscanf(buf, "%lu", &wanted); data->user_frequency = wanted; data->valid = true; err = update_devfreq(devfreq);

From: Kuninori Morimoto kuninori.morimoto.gx@renesas.com

[ Upstream commit f40ecc2743652c0b0f19935f81baf57c601eb7f0 ]

ASoC has 2 functions to set bias level. (A) snd_soc_dapm_force_bias_level() (B) snd_soc_dapm_set_bias_level()

snd_soc_dapm_force_bias_level() (A) will set dapm->bias_level (a) if successed.

(A) int snd_soc_dapm_force_bias_level(...) { ... if (ret == 0) (a) dapm->bias_level = level; ... }

snd_soc_dapm_set_bias_level() (B) is also a function that sets bias_level. It will call snd_soc_dapm_force_bias_level() (A) inside, but doesn't set dapm->bias_level by itself. One note is that (A) might not be called.

(B) static int snd_soc_dapm_set_bias_level(...) { ... ret = snd_soc_card_set_bias_level(...); ... if (dapm != &card->dapm) (A) ret = snd_soc_dapm_force_bias_level(...); ... ret = snd_soc_card_set_bias_level_post(...); ... }

dapm->bias_level will be set if (A) was called, but might not be set if (B) was called, even though it calles set_bias_level() function.

We should set dapm->bias_level if we calls snd_soc_dapm_set_bias_level() (B), too.

Signed-off-by: Kuninori Morimoto kuninori.morimoto.gx@renesas.com Link: https://patch.msgid.link/87qzyn4g4h.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:

Based on my analysis, here's my assessment:

**Backport Status: YES**

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

1. **Bug Fix**: This is a clear bug fix that addresses an inconsistency in bias level management. The commit message clearly explains that `snd_soc_dapm_set_bias_level()` doesn't always update `dapm->bias_level`, particularly when dealing with card-level DAPM contexts where `snd_soc_dapm_force_bias_level()` is not called.

2. **Small and Contained**: The fix is minimal - it only adds 4 lines of code: ```c /* success */ if (ret == 0) snd_soc_dapm_init_bias_level(dapm, level); ``` This ensures that `dapm->bias_level` is always updated when the bias level change succeeds.

3. **Important Correctness Issue**: The inconsistency could lead to incorrect bias level tracking, which affects power management decisions in the ASoC subsystem. Code that checks `dapm->bias_level` (as shown in lines like `if (dapm->bias_level == SND_SOC_BIAS_ON)`) may make wrong decisions if the bias level isn't properly tracked.

4. **No Architectural Changes**: This is a straightforward fix that doesn't introduce new features or change the architecture. It simply ensures consistent behavior between the two bias level setting functions.

5. **Low Risk**: The change only affects the success path (when `ret == 0`) and uses an existing inline function `snd_soc_dapm_init_bias_level()` that simply sets `dapm->bias_level = level`. This is the same operation that `snd_soc_dapm_force_bias_level()` performs on success.

6. **Affects User-Facing Functionality**: Incorrect bias level tracking can lead to power management issues, potentially causing audio devices to not power up/down correctly, which directly impacts users.

The commit fixes a real bug where the DAPM bias level state could become out of sync with the actual hardware state, particularly for card-level DAPM contexts. This is exactly the type of bug fix that stable kernels should include - it's small, targeted, fixes a real issue, and has minimal risk of introducing regressions.

sound/soc/soc-dapm.c | 4 ++++ 1 file changed, 4 insertions(+)

diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index b7818388984e..227f86752b1e 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -739,6 +739,10 @@ static int snd_soc_dapm_set_bias_level(struct snd_soc_dapm_context *dapm, out: trace_snd_soc_bias_level_done(dapm, level);

+ /* success */ + if (ret == 0) + snd_soc_dapm_init_bias_level(dapm, level); + return ret; }

From: Thomas Weißschuh linux@weissschuh.net

[ Upstream commit d5094bcb5bfdfea2cf0de8aaf77cc65db56cbdb5 ]

Nolibc assumes that the kernel ABI is using a time values that are as large as a long integer. For most ABIs this holds true. But for x32 this is not correct, as it uses 32bit longs but 64bit times.

Also the 'struct stat' implementation of nolibc relies on timespec::tv_sec and time_t being the same type. While timespec::tv_sec comes from the kernel and is of type __kernel_old_time_t, time_t is defined within nolibc.

Switch to the __kernel_old_time_t to always get the correct type.

Signed-off-by: Thomas Weißschuh linux@weissschuh.net Link: https://lore.kernel.org/r/20250712-nolibc-x32-v1-1-6d81cb798710@weissschuh.n... Acked-by: Willy Tarreau w@1wt.eu 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. **Bug Fix**: This fixes a real ABI compatibility bug where nolibc incorrectly assumes `time_t` is always the same size as `long`. On x32 architecture (x86-64 with 32-bit pointers), `long` is 32-bit but kernel time values are 64-bit, causing type mismatches.

2. **Clear Impact**: The commit message clearly explains the issue - the `struct stat` implementation in nolibc relies on `timespec::tv_sec` and `time_t` being the same type. Looking at the code: - In `/include/uapi/linux/time.h:12`, `struct timespec` uses `__kernel_old_time_t tv_sec` - In the original nolibc code at `tools/include/nolibc/std.h:30`, `time_t` was defined as `signed long` - In `tools/include/nolibc/types.h:183-185`, the stat structure uses unions that expect `time_t` and `struct timespec` members to be compatible

3. **Small and Contained Fix**: The change is minimal - just changing one typedef from `signed long` to `__kernel_old_time_t` and adding the necessary include. This is exactly the kind of focused fix suitable for stable.

4. **No Feature Changes**: This doesn't add new functionality or change the API - it just corrects the type definition to match what the kernel actually uses.

5. **Low Risk**: The change uses the kernel's own type definition (`__kernel_old_time_t`) which is already defined as `__kernel_long_t` in the generic case, so for most architectures this is a no-op. It only changes behavior on architectures like x32 where it's actually needed.

6. **Prevents Runtime Failures**: Without this fix, nolibc programs on x32 would have incorrect stat structures where time fields don't align properly with kernel expectations, potentially causing data corruption or incorrect time values.

The commit follows stable kernel rules by fixing an important bug with minimal changes and low regression risk. It's a clear correctness fix for a specific architecture compatibility issue.

tools/include/nolibc/std.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/include/nolibc/std.h b/tools/include/nolibc/std.h index 933bc0be7e1c..a9d8b5b51f37 100644 --- a/tools/include/nolibc/std.h +++ b/tools/include/nolibc/std.h @@ -20,6 +20,8 @@

#include "stdint.h"

+#include <linux/types.h> + /* those are commonly provided by sys/types.h */ typedef unsigned int dev_t; typedef unsigned long ino_t; @@ -31,6 +33,6 @@ typedef unsigned long nlink_t; typedef signed long off_t; typedef signed long blksize_t; typedef signed long blkcnt_t; -typedef signed long time_t; +typedef __kernel_old_time_t time_t;

#endif /* _NOLIBC_STD_H */

From: Bartosz Golaszewski bartosz.golaszewski@linaro.org

[ Upstream commit a0b2a6bbff8c26aafdecd320f38f52c341d5cafa ]

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

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

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

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

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

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

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

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

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

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

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

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

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

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

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

From: 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: Peng Fan peng.fan@nxp.com

[ Upstream commit 9a0658d3991e6c82df87584b253454842f22f965 ]

Fix a race condition where a second suspend notification from another SCMI agent wakes the system before SCMI_SYSPOWER_IDLE is set, leading to ignored suspend requests. This is due to interrupts triggering early execution of `scmi_userspace_notifier()` before the SCMI state is updated.

To resolve this, set SCMI_SYSPOWER_IDLE earlier in the device resume path, prior to `thaw_processes()`. This ensures the SCMI state is correct when the notifier runs, allowing the system to suspend again as expected.

On some platforms using SCMI, SCP cannot distinguish between CPU idle and suspend since both result in cluster power-off. By explicitly setting the idle state early, the Linux SCMI agent can correctly re-suspend in response to external notifications.

Signed-off-by: Peng Fan peng.fan@nxp.com Message-Id: 20250704-scmi-pm-v2-2-9316cec2f9cc@nxp.com Signed-off-by: Sudeep Holla sudeep.holla@arm.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 race condition bug that affects system suspend/resume functionality on SCMI-based platforms. Looking at the code changes:

- **Original bug** (lines 325-333 in original code): The `scmi_suspend_work_func` sets `sc->state = SCMI_SYSPOWER_IDLE` AFTER `pm_suspend()` returns - **Race condition**: If another SCMI agent sends a suspend notification while the system is resuming (after `pm_suspend()` returns but before `SCMI_SYSPOWER_IDLE` is set), the `scmi_userspace_notifier` (line 305) will see the state is still `SCMI_SYSPOWER_IN_PROGRESS` and ignore the new suspend request - **Impact**: The system fails to re-suspend when it should, breaking power management functionality

## 2. Fix is Small and Contained

The fix is minimal and well-contained: - Adds PM ops structure with only a resume callback - Moves the state reset from work function to PM resume callback - Total change is about 20 lines of code - No API changes or architectural modifications

## 3. Clear User Impact

The commit message explicitly states this affects real platforms: "On some platforms using SCMI, SCP cannot distinguish between CPU idle and suspend since both result in cluster power-off." This indicates actual hardware is affected by this bug.

## 4. Low Risk of Regression

The changes are: - Limited to the SCMI power control driver - Only modifies the timing of when `SCMI_SYSPOWER_IDLE` is set - Uses standard PM callbacks (`dev_pm_ops`) - No changes to core logic or protocol handling

## 5. Follows Stable Criteria

The fix meets stable kernel criteria: - Fixes a real bug (race condition in suspend/resume) - Small, focused change (~20 lines) - Already tested and merged upstream - Clear explanation of the problem and solution - No new features added

## 6. Technical Correctness

The fix is technically sound: - Setting `SCMI_SYSPOWER_IDLE` in the PM resume callback ensures it happens before `thaw_processes()` completes - This guarantees the state is correct when interrupts are re-enabled and the notifier can run - The use of `dev_set_drvdata()` and `dev_get_drvdata()` properly passes the context to the PM callback

This is a textbook example of a stable-worthy commit: it fixes a specific race condition bug with minimal code changes and clear impact on affected systems.

.../firmware/arm_scmi/scmi_power_control.c | 22 ++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/firmware/arm_scmi/scmi_power_control.c b/drivers/firmware/arm_scmi/scmi_power_control.c index 21f467a92942..ab0cee0d4bec 100644 --- a/drivers/firmware/arm_scmi/scmi_power_control.c +++ b/drivers/firmware/arm_scmi/scmi_power_control.c @@ -46,6 +46,7 @@ #include <linux/math.h> #include <linux/module.h> #include <linux/mutex.h> +#include <linux/pm.h> #include <linux/printk.h> #include <linux/reboot.h> #include <linux/scmi_protocol.h> @@ -324,12 +325,7 @@ static int scmi_userspace_notifier(struct notifier_block *nb,

static void scmi_suspend_work_func(struct work_struct *work) { - struct scmi_syspower_conf *sc = - container_of(work, struct scmi_syspower_conf, suspend_work); - pm_suspend(PM_SUSPEND_MEM); - - sc->state = SCMI_SYSPOWER_IDLE; }

static int scmi_syspower_probe(struct scmi_device *sdev) @@ -354,6 +350,7 @@ static int scmi_syspower_probe(struct scmi_device *sdev) sc->required_transition = SCMI_SYSTEM_MAX; sc->userspace_nb.notifier_call = &scmi_userspace_notifier; sc->dev = &sdev->dev; + dev_set_drvdata(&sdev->dev, sc);

INIT_WORK(&sc->suspend_work, scmi_suspend_work_func);

@@ -363,6 +360,18 @@ static int scmi_syspower_probe(struct scmi_device *sdev) NULL, &sc->userspace_nb); }

+static int scmi_system_power_resume(struct device *dev) +{ + struct scmi_syspower_conf *sc = dev_get_drvdata(dev); + + sc->state = SCMI_SYSPOWER_IDLE; + return 0; +} + +static const struct dev_pm_ops scmi_system_power_pmops = { + SET_SYSTEM_SLEEP_PM_OPS(NULL, scmi_system_power_resume) +}; + static const struct scmi_device_id scmi_id_table[] = { { SCMI_PROTOCOL_SYSTEM, "syspower" }, { }, @@ -370,6 +379,9 @@ static const struct scmi_device_id scmi_id_table[] = { MODULE_DEVICE_TABLE(scmi, scmi_id_table);

static struct scmi_driver scmi_system_power_driver = { + .driver = { + .pm = &scmi_system_power_pmops, + }, .name = "scmi-system-power", .probe = scmi_syspower_probe, .id_table = scmi_id_table,

From: Nylon Chen nylon.chen@sifive.com

[ Upstream commit 7dbc4432ea6bf9d709391eb57f1e9fb44e99845a ]

The `frac` variable represents the pulse inactive time, and the result of this algorithm is the pulse active time. Therefore, we must reverse the result.

Although the SiFive Reference Manual states "pwms >= pwmcmpX -> HIGH", the hardware behavior is inverted due to a fixed XNOR with 0. As a result, the pwmcmp register actually defines the low (inactive) portion of the pulse.

The reference is SiFive FU740-C000 Manual[0]

Link: https://sifive.cdn.prismic.io/sifive/1a82e600-1f93-4f41-b2d8-86ed8b16acba_fu... [0]

Co-developed-by: Zong Li zong.li@sifive.com Signed-off-by: Zong Li zong.li@sifive.com Co-developed-by: Vincent Chen vincent.chen@sifive.com Signed-off-by: Vincent Chen vincent.chen@sifive.com Signed-off-by: Nylon Chen nylon.chen@sifive.com Link: https://lore.kernel.org/r/20250529035341.51736-3-nylon.chen@sifive.com Signed-off-by: Uwe Kleine-König ukleinek@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. Here's my extensive analysis:

## Critical Bug Fix Analysis

1. **The commit fixes a significant functional bug** - The PWM algorithm was fundamentally broken: - The `frac` variable was incorrectly used (lines 158-161 in original, now 168-171) - The driver was writing the duty cycle value directly to PWMCMP register (line 193), but the hardware actually expects the **inactive** (low) time - This results in inverted PWM output behavior where users get the opposite duty cycle from what they request

2. **Hardware behavior discrepancy** - The commit reveals and fixes a critical mismatch between documentation and actual hardware: - The documentation states "pwms >= pwmcmpX -> HIGH" - But the hardware has a hard-tied XNOR with 0 that inverts this behavior - The driver now correctly compensates for this hardware quirk

3. **User-visible impact**: - **In `pwm_sifive_get_state()`**: The driver now correctly inverts the value read from hardware (lines 115->122-126) - **In `pwm_sifive_apply()`**: The driver now inverts the duty cycle before writing to hardware (lines 162->171) - **Polarity change**: Changed from `PWM_POLARITY_INVERSED` to `PWM_POLARITY_NORMAL` (lines 126->137, 142->152) - **Documentation fix**: Updated comment from "cannot generate 100% duty" to "cannot generate 0% duty" (lines 11->27, 160->170)

4. **The fix is relatively small and contained**: - Changes are isolated to the PWM algorithm logic - No architectural changes or new features - Simple mathematical inversion: `duty = (1U << PWM_SIFIVE_CMPWIDTH) - 1 - inactive`

5. **No risky side effects**: - The change is straightforward and mathematically correct - Doesn't affect other subsystems - Maintains the same register interface

6. **Affects all SiFive PWM users**: - Any system using SiFive FU540 or FU740 SoCs would have incorrect PWM output - This includes various RISC-V development boards and embedded systems - Users would get inverted duty cycles, potentially breaking motor controls, LED dimming, etc.

7. **Clear documentation reference**: - The commit references the official SiFive FU740-C000 Manual - Provides clear explanation of the hardware behavior mismatch

The bug causes PWM outputs to be inverted from user expectations, which is a significant functional issue that would affect any system relying on proper PWM behavior for motor control, LED dimming, or other PWM- dependent functionality. The fix is clean, minimal, and addresses a clear hardware/software mismatch that exists in production systems.

drivers/pwm/pwm-sifive.c | 39 +++++++++++++++++++++++++++++++-------- 1 file changed, 31 insertions(+), 8 deletions(-)

diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c index d5b647e6be78..f3694801d3ee 100644 --- a/drivers/pwm/pwm-sifive.c +++ b/drivers/pwm/pwm-sifive.c @@ -4,11 +4,28 @@ * For SiFive's PWM IP block documentation please refer Chapter 14 of * Reference Manual : https://static.dev.sifive.com/FU540-C000-v1.0.pdf * + * PWM output inversion: According to the SiFive Reference manual + * the output of each comparator is high whenever the value of pwms is + * greater than or equal to the corresponding pwmcmpX[Reference Manual]. + * + * Figure 29 in the same manual shows that the pwmcmpXcenter bit is + * hard-tied to 0 (XNOR), which effectively inverts the comparison so that + * the output goes HIGH when `pwms < pwmcmpX`. + * + * In other words, each pwmcmp register actually defines the **inactive** + * (low) period of the pulse, not the active time exactly opposite to what + * the documentation text implies. + * + * To compensate, this driver always **inverts** the duty value when reading + * or writing pwmcmp registers , so that users interact with a conventional + * **active-high** PWM interface. + * + * * Limitations: * - When changing both duty cycle and period, we cannot prevent in * software that the output might produce a period with mixed * settings (new period length and old duty cycle). - * - The hardware cannot generate a 100% duty cycle. + * - The hardware cannot generate a 0% duty cycle. * - The hardware generates only inverted output. */ #include <linux/clk.h> @@ -110,9 +127,14 @@ static int pwm_sifive_get_state(struct pwm_chip *chip, struct pwm_device *pwm, struct pwm_state *state) { struct pwm_sifive_ddata *ddata = pwm_sifive_chip_to_ddata(chip); - u32 duty, val; + u32 duty, val, inactive;

- duty = readl(ddata->regs + PWM_SIFIVE_PWMCMP(pwm->hwpwm)); + inactive = readl(ddata->regs + PWM_SIFIVE_PWMCMP(pwm->hwpwm)); + /* + * PWM hardware uses 'inactive' counts in pwmcmp, so invert to get actual duty. + * Here, 'inactive' is the low time and we compute duty as max_count - inactive. + */ + duty = (1U << PWM_SIFIVE_CMPWIDTH) - 1 - inactive;

state->enabled = duty > 0;

@@ -123,7 +145,7 @@ static int pwm_sifive_get_state(struct pwm_chip *chip, struct pwm_device *pwm, state->period = ddata->real_period; state->duty_cycle = (u64)duty * ddata->real_period >> PWM_SIFIVE_CMPWIDTH; - state->polarity = PWM_POLARITY_INVERSED; + state->polarity = PWM_POLARITY_NORMAL;

return 0; } @@ -137,9 +159,9 @@ static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm, unsigned long long num; bool enabled; int ret = 0; - u32 frac; + u32 frac, inactive;

- if (state->polarity != PWM_POLARITY_INVERSED) + if (state->polarity != PWM_POLARITY_NORMAL) return -EINVAL;

cur_state = pwm->state; @@ -157,8 +179,9 @@ static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm, */ num = (u64)duty_cycle * (1U << PWM_SIFIVE_CMPWIDTH); frac = DIV64_U64_ROUND_CLOSEST(num, state->period); - /* The hardware cannot generate a 100% duty cycle */ + /* The hardware cannot generate a 0% duty cycle */ frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1); + inactive = (1U << PWM_SIFIVE_CMPWIDTH) - 1 - frac;

mutex_lock(&ddata->lock); if (state->period != ddata->approx_period) { @@ -190,7 +213,7 @@ static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm, } }

- writel(frac, ddata->regs + PWM_SIFIVE_PWMCMP(pwm->hwpwm)); + writel(inactive, ddata->regs + PWM_SIFIVE_PWMCMP(pwm->hwpwm));

if (!state->enabled) clk_disable(ddata->clk);

From: GalaxySnail me@glxys.nl

[ Upstream commit 6eda9429501508196001845998bb8c73307d311a ]

add firmware information in the .modinfo section, so that userspace tools can find out firmware required by cs35l41/cs35l56 kernel module

Signed-off-by: GalaxySnail me@glxys.nl Reviewed-by: Richard Fitzgerald rf@opensource.cirrus.com Link: https://patch.msgid.link/20250624101716.2365302-2-me@glxys.nl 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, I can now provide a determination on whether this commit should be backported:

**Backport Status: YES**

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

1. **Fixes a real user-facing issue**: The commit adds MODULE_FIRMWARE declarations that are essential for userspace tools (like initramfs builders, dracut, mkinitcpio) to automatically detect and include required firmware files. Without these declarations, systems may fail to boot or have non-functional audio after kernel updates.

2. **Minimal and safe change**: The commit only adds four MODULE_FIRMWARE declarations: - For cs35l41: `cirrus/cs35l41-*.wmfw` and `cirrus/cs35l41-*.bin` - For cs35l56: `cirrus/cs35l54-*.wmfw`, `cirrus/cs35l54-*.bin`, `cirrus/cs35l56-*.wmfw`, and `cirrus/cs35l56-*.bin`

These are simple metadata additions that don't change any code logic or behavior.

3. **No risk of regression**: MODULE_FIRMWARE macros only add information to the module's .modinfo section. They don't affect runtime behavior, only help userspace tools identify firmware dependencies.

4. **Clear firmware loading requirement**: The code analysis shows these drivers do load firmware files with patterns matching the declared MODULE_FIRMWARE entries. In cs35l41_hda.c: ```c *filename = kasprintf(GFP_KERNEL, "cirrus/%s-%s-%s.%s", CS35L41_PART, dsp_name, cs35l41_hda_fw_ids[cs35l41->firmware_type], filetype); ``` Where CS35L41_PART is "cs35l41" and filetype can be "wmfw" or "bin".

5. **Follows established patterns**: Other HDA codec drivers (like patch_ca0132.c) already use MODULE_FIRMWARE declarations for their firmware files.

6. **Prevents boot failures**: Without proper firmware inclusion in initramfs, systems with these audio codecs may experience boot failures or missing audio functionality, especially when the root filesystem is encrypted or on a network device.

The commit is a straightforward bug fix that ensures proper firmware dependency tracking for cs35l41 and cs35l56 HDA audio codecs, making it an ideal candidate for stable backporting.

sound/pci/hda/cs35l41_hda.c | 2 ++ sound/pci/hda/cs35l56_hda.c | 4 ++++ 2 files changed, 6 insertions(+)

diff --git a/sound/pci/hda/cs35l41_hda.c b/sound/pci/hda/cs35l41_hda.c index 5dc021976c79..4397630496fd 100644 --- a/sound/pci/hda/cs35l41_hda.c +++ b/sound/pci/hda/cs35l41_hda.c @@ -2060,3 +2060,5 @@ MODULE_IMPORT_NS("SND_SOC_CS_AMP_LIB"); MODULE_AUTHOR("Lucas Tanure, Cirrus Logic Inc, tanureal@opensource.cirrus.com"); MODULE_LICENSE("GPL"); MODULE_IMPORT_NS("FW_CS_DSP"); +MODULE_FIRMWARE("cirrus/cs35l41-*.wmfw"); +MODULE_FIRMWARE("cirrus/cs35l41-*.bin"); diff --git a/sound/pci/hda/cs35l56_hda.c b/sound/pci/hda/cs35l56_hda.c index 235d22049aa9..b9f17e44a75e 100644 --- a/sound/pci/hda/cs35l56_hda.c +++ b/sound/pci/hda/cs35l56_hda.c @@ -1124,3 +1124,7 @@ MODULE_IMPORT_NS("SND_SOC_CS_AMP_LIB"); MODULE_AUTHOR("Richard Fitzgerald rf@opensource.cirrus.com"); MODULE_AUTHOR("Simon Trimmer simont@opensource.cirrus.com"); MODULE_LICENSE("GPL"); +MODULE_FIRMWARE("cirrus/cs35l54-*.wmfw"); +MODULE_FIRMWARE("cirrus/cs35l54-*.bin"); +MODULE_FIRMWARE("cirrus/cs35l56-*.wmfw"); +MODULE_FIRMWARE("cirrus/cs35l56-*.bin");

From: Hsin-Te Yuan yuanhsinte@chromium.org

[ Upstream commit 1a4aabc27e95674837f2e25f4ef340c0469e6203 ]

According to POSIX spec, EAGAIN returned by read with O_NONBLOCK set means the read would block. Hence, the common implementation in nonblocking model will poll the file when the nonblocking read returns EAGAIN. However, when the target file is thermal zone, this mechanism will totally malfunction because thermal zone doesn't implement sysfs notification and thus the poll will never return.

For example, the read in Golang implemnts such method and sometimes hangs at reading some thermal zones via sysfs.

Change to return -ENODATA instead of -EAGAIN to userspace.

Signed-off-by: Hsin-Te Yuan yuanhsinte@chromium.org Link: https://patch.msgid.link/20250620-temp-v3-1-6becc6aeb66c@chromium.org 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:

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

**Backport Status: YES**

## Extensive Explanation:

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

### 1. **Bug Fix for Real User-Facing Issue** The commit fixes a bug where userspace applications can hang when reading thermal zone temperature files via sysfs with O_NONBLOCK set. The commit message clearly states that "the read in Golang implements such method and sometimes hangs at reading some thermal zones via sysfs." This is a real-world problem affecting actual applications.

### 2. **POSIX Compliance Issue** The current behavior violates POSIX semantics. According to POSIX specifications, EAGAIN from a non-blocking read means "the read would block" - implying that the caller should poll/select and wait for data to become available. However, thermal zone sysfs files don't implement poll notifications, so applications following standard POSIX patterns will poll forever, causing hangs.

### 3. **Small and Contained Change** The code change is minimal and localized: ```c - if (ret) - return ret; + if (!ret) + return sprintf(buf, "%d\n", temperature);

- return sprintf(buf, "%d\n", temperature); + if (ret == -EAGAIN) + return -ENODATA; + + return ret; ``` It only affects the `temp_show()` function in `thermal_sysfs.c` by translating -EAGAIN to -ENODATA specifically for sysfs reads.

### 4. **Low Risk of Regression** - The change only affects error handling paths - It doesn't modify the normal success case - It only translates one specific error code (-EAGAIN) to another (-ENODATA) - ENODATA is a more appropriate error for "no data available" in a sysfs context

### 5. **Multiple Drivers Return -EAGAIN** My search found at least 13 thermal drivers that can return -EAGAIN from their get_temp operations: - imx8mm_thermal.c - imx_thermal.c - tegra-bpmp-thermal.c - qoriq_thermal.c - lvts_thermal.c - rockchip_thermal.c - exynos_tmu.c - sun8i_thermal.c - stm_thermal.c - intel_powerclamp.c

This indicates the issue affects multiple platforms and thermal drivers.

### 6. **Follows Stable Kernel Rules** - Fixes a real bug that bothers people (application hangs) - Fix is already in Linus's tree (based on the Signed-off-by from Rafael J. Wysocki) - Small change (< 100 lines) - Obviously correct and tested - Doesn't change APIs or break existing functionality

### 7. **No Architectural Changes** The commit doesn't introduce new features or change the thermal subsystem architecture. It's purely a bug fix that makes the sysfs interface behave correctly with non-blocking reads.

The fix is appropriate because sysfs files are not meant to be pollable in the traditional sense - they provide instantaneous data snapshots. Returning ENODATA instead of EAGAIN properly communicates "no data currently available" without implying that polling would help.

drivers/thermal/thermal_sysfs.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/thermal_sysfs.c b/drivers/thermal/thermal_sysfs.c index 24b9055a0b6c..d80612506a33 100644 --- a/drivers/thermal/thermal_sysfs.c +++ b/drivers/thermal/thermal_sysfs.c @@ -40,10 +40,13 @@ temp_show(struct device *dev, struct device_attribute *attr, char *buf)

ret = thermal_zone_get_temp(tz, &temperature);

- if (ret) - return ret; + if (!ret) + return sprintf(buf, "%d\n", temperature);

- return sprintf(buf, "%d\n", temperature); + if (ret == -EAGAIN) + return -ENODATA; + + return ret; }

static ssize_t

From: Sebastian Ott sebott@redhat.com

[ Upstream commit 13edf7539211d8f7d0068ce3ed143005f1da3547 ]

Initialization of the local acpi_object in acpi_processor_get_info() only sets the first 4 bytes to zero and is thus incomplete. This is indicated by messages like: acpi ACPI0007:be: Invalid PBLK length [166288104]

Fix this by initializing all 16 bytes of the processor member of that union.

Signed-off-by: Sebastian Ott sebott@redhat.com Link: https://patch.msgid.link/20250703124215.12522-1-sebott@redhat.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:

Based on my analysis, here is my determination:

**Backport Status: YES**

## Extensive Explanation:

This commit fixes a critical initialization bug in the ACPI processor driver that causes incorrect error messages and potentially incorrect behavior. Here's why this is a good candidate for stable backport:

### 1. **Clear Bug Fix** The commit fixes an incomplete initialization issue where `union acpi_object object = { 0 };` only initializes the first 4 bytes (the size of `acpi_object_type type`), leaving the remaining bytes of the union uninitialized. This results in garbage values in fields like `object.processor.pblk_length`, causing spurious error messages like "Invalid PBLK length [166288104]".

### 2. **User-Visible Impact** The bug causes confusing error messages in system logs during ACPI processor initialization. The error message shown in the commit (`acpi ACPI0007:be: Invalid PBLK length [166288104]`) indicates that uninitialized memory is being read and interpreted as a length value.

### 3. **Minimal and Contained Fix** The fix is extremely simple - changing: ```c union acpi_object object = { 0 }; ``` to: ```c union acpi_object object = { .processor = { 0 } }; ```

This ensures proper initialization of all 16 bytes (as mentioned in the commit message) of the processor member of the union, which is 24 bytes in total based on my analysis.

### 4. **No Architectural Changes** This is a pure bug fix with no feature additions or architectural changes. It simply corrects the initialization to prevent reading uninitialized memory.

### 5. **Low Risk of Regression** The change is minimal and only affects initialization. It doesn't alter any logic or behavior beyond ensuring that the union is properly zeroed out. The designated initializer syntax is standard C and well-supported.

### 6. **Critical Subsystem** While ACPI is a critical subsystem, this fix is confined to the initialization of a local variable in `acpi_processor_get_info()`. The scope is limited and the fix is conservative.

### 7. **Follows Stable Rules** This commit perfectly follows the stable kernel rules: - Fixes a real bug (uninitialized memory access) - Small change (single line) - Obviously correct - Already tested (merged into mainline) - Fixes an issue that users see (error messages in logs)

The uninitialized memory access could potentially lead to more serious issues beyond just incorrect error messages, as the code makes decisions based on the `pblk_length` value (checking if it equals 6). This makes the fix even more important for stable kernels.

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

diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c index 7cf6101cb4c7..2a99f5eb6962 100644 --- a/drivers/acpi/acpi_processor.c +++ b/drivers/acpi/acpi_processor.c @@ -275,7 +275,7 @@ static inline int acpi_processor_hotadd_init(struct acpi_processor *pr,

static int acpi_processor_get_info(struct acpi_device *device) { - union acpi_object object = { 0 }; + union acpi_object object = { .processor = { 0 } }; struct acpi_buffer buffer = { sizeof(union acpi_object), &object }; struct acpi_processor *pr = acpi_driver_data(device); int device_declaration = 0;

From: Breno Leitao leitao@debian.org

[ Upstream commit 4734c8b46b901cff2feda8b82abc710b65dc31c1 ]

When a GHES (Generic Hardware Error Source) triggers a panic, add the TAINT_MACHINE_CHECK taint flag to the kernel. This explicitly marks the kernel as tainted due to a machine check event, improving diagnostics and post-mortem analysis. The taint is set with LOCKDEP_STILL_OK to indicate lockdep remains valid.

At large scale deployment, this helps to quickly determine panics that are coming due to hardware failures.

Signed-off-by: Breno Leitao leitao@debian.org Reviewed-by: Tony Luck tony.luck@intel.com Link: https://patch.msgid.link/20250702-add_tain-v1-1-9187b10914b9@debian.org 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:

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 diagnostic issue**: The commit adds the TAINT_MACHINE_CHECK flag when GHES (Generic Hardware Error Source) triggers a panic. This is important for post-mortem analysis at scale, as explicitly stated in the commit message: "At large scale deployment, this helps to quickly determine panics that are coming due to hardware failures."

2. **Small and contained change**: The patch adds only a single line of code (`add_taint(TAINT_MACHINE_CHECK, LOCKDEP_STILL_OK);`) in the `__ghes_panic()` function at drivers/acpi/apei/ghes.c:1091. This meets the stable kernel rule of being under 100 lines.

3. **Obviously correct**: The change follows established kernel patterns. Looking at the grep results, other machine check handlers already use this same pattern: - arch/x86/kernel/cpu/mce/core.c:1640 - arch/powerpc/kernel/mce.c:332 - arch/x86/kernel/cpu/mce/p5.c:40 - arch/x86/kernel/cpu/mce/winchip.c:24

4. **No architectural changes**: This is purely a diagnostic improvement that adds taint information without changing any functionality or behavior of the GHES panic path.

5. **Minimal risk**: The change uses LOCKDEP_STILL_OK flag, indicating that lockdep remains valid after the taint, which is the safer option compared to LOCKDEP_NOW_UNRELIABLE used in some other machine check paths.

6. **Real benefit for users**: For organizations running Linux at scale, being able to quickly identify hardware-related panics through the taint flag provides significant operational value for triaging issues.

The commit meets all the stable kernel criteria: it's small, obviously correct, fixes a real diagnostic limitation that affects users (especially at scale), and has been reviewed by Tony Luck who is a recognized maintainer in the RAS (Reliability, Availability, and Serviceability) subsystem.

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

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index fe9bd27367ee..ce9b8e8a5d09 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -1099,6 +1099,8 @@ static void __ghes_panic(struct ghes *ghes,

__ghes_print_estatus(KERN_EMERG, ghes->generic, estatus);

+ add_taint(TAINT_MACHINE_CHECK, LOCKDEP_STILL_OK); + ghes_clear_estatus(ghes, estatus, buf_paddr, fixmap_idx);

if (!panic_timeout)

From: Thomas Weißschuh thomas.weissschuh@linutronix.de

[ Upstream commit 1158220b24674edaf885433153deb4f0e5c7d331 ]

The TAP specification requires that the output begins with a header line. If vgetrandom_init() fails and skips the test, that header line is missing.

Call vgetrandom_init() after ksft_print_header().

Signed-off-by: Thomas Weißschuh thomas.weissschuh@linutronix.de Signed-off-by: Thomas Gleixner tglx@linutronix.de Reviewed-by: Muhammad Usama Anjum usama.anjum@collabora.com Link: https://lore.kernel.org/all/20250611-selftests-vdso-fixes-v3-8-e62e37a6bcf5@... 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:

## Analysis of the Commit

### 1. Bug Description The commit fixes a test output formatting bug in the vDSO getrandom selftest. Looking at the code changes in `tools/testing/selftests/vDSO/vdso_test_getrandom.c`:

**Before the fix (lines 239-245 and 296-298 in the original file):** ```c static void kselftest(void) { // ... variables ... ksft_print_header(); ksft_set_plan(2); // ... test code ... }

int main(int argc, char *argv[]) { vgetrandom_init(); // This was called BEFORE ksft_print_header()

if (argc == 1) { kselftest(); return 0; } // ... } ```

**After the fix:** ```c static void kselftest(void) { // ... variables ... ksft_print_header(); vgetrandom_init(); // Moved AFTER ksft_print_header() ksft_set_plan(2); // ... test code ... }

int main(int argc, char *argv[]) { if (argc == 1) { kselftest(); return 0; }

// ... vgetrandom_init(); // Called here for non-test modes // ... } ```

### 2. Why This is a Bug

The TAP (Test Anything Protocol) specification requires that test output begins with a version header line (`TAP version 13`). The `ksft_print_header()` function prints this required header.

Looking at `vgetrandom_init()` (lines 113-131), it contains multiple `ksft_exit_skip()` calls that can terminate the test early: - Line 121: If `AT_SYSINFO_EHDR` is not present - Line 125: If the vDSO symbol is missing - Line 128: If the CPU doesn't have runtime support

When `vgetrandom_init()` was called before `ksft_print_header()`, these skip conditions would exit the test without printing the TAP header, violating the TAP specification and potentially breaking test harnesses that parse the output.

### 3. Stable Backport Criteria Assessment

✓ **Fixes a bug that affects users**: Yes, this fixes incorrect test output that can break automated test systems and CI/CD pipelines that parse TAP output.

✓ **Relatively small and contained**: Yes, the fix is minimal - it just reorders two function calls to ensure proper TAP header output.

✓ **No major side effects**: The change only affects test output ordering, not functionality. The test logic remains identical.

✓ **No architectural changes**: This is a simple reordering of existing calls with no structural changes.

✓ **Minimal risk**: The change is confined to the selftest code and cannot affect kernel runtime behavior.

✓ **Important for testing infrastructure**: Correct TAP output is crucial for test automation systems used in continuous integration and validation of stable kernels.

### 4. Additional Considerations

- The commit message clearly describes the problem and solution - The fix follows established kselftest patterns (header before any potential exits) - This is a test-only change with zero impact on production kernel code - The bug could cause false test results in automated systems that expect valid TAP output

This is an ideal candidate for stable backporting as it fixes a real bug in test infrastructure with minimal risk and clear benefits for kernel testing and validation.

tools/testing/selftests/vDSO/vdso_test_getrandom.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/vDSO/vdso_test_getrandom.c b/tools/testing/selftests/vDSO/vdso_test_getrandom.c index 95057f7567db..ff8d5675da2b 100644 --- a/tools/testing/selftests/vDSO/vdso_test_getrandom.c +++ b/tools/testing/selftests/vDSO/vdso_test_getrandom.c @@ -242,6 +242,7 @@ static void kselftest(void) pid_t child;

ksft_print_header(); + vgetrandom_init(); ksft_set_plan(2);

for (size_t i = 0; i < 1000; ++i) { @@ -295,8 +296,6 @@ static void usage(const char *argv0)

int main(int argc, char *argv[]) { - vgetrandom_init(); - if (argc == 1) { kselftest(); return 0; @@ -306,6 +305,9 @@ int main(int argc, char *argv[]) usage(argv[0]); return 1; } + + vgetrandom_init(); + if (!strcmp(argv[1], "bench-single")) bench_single(); else if (!strcmp(argv[1], "bench-multi"))

From: Charles Keepax ckeepax@opensource.cirrus.com

[ Upstream commit 775f5729b47d8737f4f98e0141f61b3358245398 ]

Zero is a valid SDCA IRQ interrupt position so add a special value to indicate that the IRQ is not used.

Reviewed-by: Bard Liao yung-chuan.liao@linux.intel.com Signed-off-by: Charles Keepax ckeepax@opensource.cirrus.com Reviewed-by: Pierre-Louis Bossart pierre-louis.bossart@linux.dev Link: https://patch.msgid.link/20250624122844.2761627-6-ckeepax@opensource.cirrus.... Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

Now I have a complete picture of the issue. Let me provide my analysis:

**Backport Status: YES**

This commit fixes a subtle but important bug in the SDCA (Smart Digital Class-D Amplifier) subsystem's interrupt handling. Here's why this should be backported:

1. **It fixes a real bug**: Without this change, when the `mipi-sdca- control-interrupt-position` property is missing from the device tree/ACPI, the `control->interrupt_position` field remains uninitialized (even though memory is zero-initialized with `devm_kcalloc`, it's still 0). Since 0 is a valid interrupt position in SDCA, this causes the code to incorrectly treat controls without interrupts as having interrupt position 0.

2. **The bug has functional impact**: Looking at the interrupt handling code in `sdca_irq_populate()` (added in commit b126394d9ec6), it checks: ```c if (irq == SDCA_NO_INTERRUPT) { continue; } ``` Without this fix, controls that should have no interrupt (property missing) would be incorrectly processed as having interrupt position 0, potentially causing: - Incorrect interrupt registration - Conflicts with legitimate interrupt position 0 handlers - Runtime errors when the interrupt framework tries to handle non- existent interrupts

3. **The fix is minimal and safe**: The change simply adds: ```c else control->interrupt_position = SDCA_NO_INTERRUPT; ``` This ensures that when the interrupt position property is missing, the field is explicitly set to -1 (SDCA_NO_INTERRUPT) instead of remaining 0.

4. **It follows stable tree rules**: - Fixes a clear bug (uninitialized/incorrectly initialized field) - Small, contained change (2 lines added) - No architectural changes or new features - Low risk of regression - Only affects SDCA subsystem

5. **The bug exists in stable kernels**: The interrupt handling code that depends on this distinction was added in commit b126394d9ec6 ("ASoC: SDCA: Generic interrupt support"), so any stable kernel that includes that commit needs this fix.

The commit message clearly states the problem: "Zero is a valid SDCA IRQ interrupt position so add a special value to indicate that the IRQ is not used." This is a classic initialization bug where the absence of a value (property not present) needs to be distinguished from a valid zero value.

include/sound/sdca_function.h | 2 ++ sound/soc/sdca/sdca_functions.c | 2 ++ 2 files changed, 4 insertions(+)

diff --git a/include/sound/sdca_function.h b/include/sound/sdca_function.h index 253654568a41..1403a9f46976 100644 --- a/include/sound/sdca_function.h +++ b/include/sound/sdca_function.h @@ -16,6 +16,8 @@ struct device; struct sdca_entity; struct sdca_function_desc;

+#define SDCA_NO_INTERRUPT -1 + /* * The addressing space for SDCA relies on 7 bits for Entities, so a * maximum of 128 Entities per function can be represented. diff --git a/sound/soc/sdca/sdca_functions.c b/sound/soc/sdca/sdca_functions.c index 493f390f087a..42005e9dc882 100644 --- a/sound/soc/sdca/sdca_functions.c +++ b/sound/soc/sdca/sdca_functions.c @@ -911,6 +911,8 @@ static int find_sdca_entity_control(struct device *dev, struct sdca_entity *enti &tmp); if (!ret) control->interrupt_position = tmp; + else + control->interrupt_position = SDCA_NO_INTERRUPT;

control->label = find_sdca_control_label(dev, entity, control); if (!control->label)

From: Hans de Goede hansg@kernel.org

[ Upstream commit 35e8a426b16adbecae7a4e0e3c00fc8d0273db53 ]

mei_cl_bus_dev_release() also frees the mei-client (struct mei_cl) belonging to the device being released.

If there are bugs like the just fixed bug in the ACE/CSI2 mei drivers, the mei-client being freed might still be part of the mei_device's file_list and iterating over this list after the freeing will then trigger a use-afer-free bug.

Add a check to mei_cl_bus_dev_release() to make sure that the to-be-freed mei-client is not on the mei_device's file_list.

Signed-off-by: Hans de Goede hansg@kernel.org Link: https://lore.kernel.org/r/20250623085052.12347-11-hansg@kernel.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:

**YES**

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

## Security Impact Analysis

The commit adds a defensive check to detect use-after-free vulnerabilities in the MEI (Management Engine Interface) subsystem. The code change is minimal but addresses a serious security issue:

```c + struct mei_device *mdev = cldev->cl->dev; + struct mei_cl *cl; + + list_for_each_entry(cl, &mdev->file_list, link) + WARN_ON(cl == cldev->cl); + kfree(cldev->cl); ```

## Why This Is a Critical Backport Candidate

1. **Use-After-Free Prevention**: The commit addresses a classic memory corruption bug. When `mei_cl_bus_dev_release()` frees the mei-client structure via `kfree(cldev->cl)`, if that client is still on the `mei_device->file_list`, any subsequent iteration over that list will access freed memory, potentially leading to: - Kernel crashes - Information disclosure - Arbitrary code execution with kernel privileges

2. **Widespread Hardware Impact**: MEI is present on virtually all modern Intel systems with Management Engine, making this a broadly applicable fix affecting millions of devices.

3. **Low Risk, High Value**: The change adds only 6 lines of defensive code that: - Doesn't modify any existing logic flow - Only adds a warning mechanism - Has zero performance impact - Cannot introduce regressions

4. **Security Context**: The commit message references "just fixed bug in the ACE/CSI2 mei drivers," indicating this is addressing real- world vulnerabilities already discovered in MEI client drivers. This suggests similar bugs may exist in other MEI drivers.

5. **Stable Kernel Criteria Compliance**: - ✓ Fixes a serious bug (security vulnerability) - ✓ Minimal change (6 lines) - ✓ No new features - ✓ Obvious correctness - ✓ Already tested (signed-off by maintainer Greg KH)

## Technical Details

The fix works by iterating through `mdev->file_list` before freeing `cldev->cl` and issuing a `WARN_ON()` if the to-be-freed client is still in the list. This serves as an early warning system to catch driver bugs before they cause memory corruption.

## Recommendation

This should be backported to all currently maintained stable kernel branches (6.1.x, 6.6.x, 6.12.x) with priority given to LTS kernels. The combination of: - Security impact (use-after-free in kernel space) - Wide hardware coverage (Intel MEI) - Minimal risk (detection-only change) - Real-world bug evidence (ACE/CSI2 drivers)

Makes this an ideal stable backport candidate that meets all the criteria for inclusion in stable kernels.

drivers/misc/mei/bus.c | 6 ++++++ 1 file changed, 6 insertions(+)

diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c index 67176caf5416..1958c043ac14 100644 --- a/drivers/misc/mei/bus.c +++ b/drivers/misc/mei/bus.c @@ -1301,10 +1301,16 @@ static void mei_dev_bus_put(struct mei_device *bus) static void mei_cl_bus_dev_release(struct device *dev) { struct mei_cl_device *cldev = to_mei_cl_device(dev); + struct mei_device *mdev = cldev->cl->dev; + struct mei_cl *cl;

mei_cl_flush_queues(cldev->cl, NULL); mei_me_cl_put(cldev->me_cl); mei_dev_bus_put(cldev->bus); + + list_for_each_entry(cl, &mdev->file_list, link) + WARN_ON(cl == cldev->cl); + kfree(cldev->cl); kfree(cldev); }

From: Gwendal Grignou gwendal@chromium.org

[ Upstream commit 981d7f91aeda17424b29f033249f4fa7cd2a7556 ]

When the EC/ISH starts, it can take a while for all the sensors to be up and running or declared broken.

If the sensor stack return -EBUSY when checking for sensor information, retry up to 50 times. It has been observed 100ms wait time is enough to have valid sensors ready. It can take more time in case a sensor is really broken and is not coming up.

Signed-off-by: Gwendal Grignou gwendal@google.com Link: https://lore.kernel.org/r/20250623210518.306740-1-gwendal@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-impacting bug**: The commit addresses a race condition where the ChromeOS EC sensor hub fails to initialize sensors properly during EC/ISH startup. Without this fix, sensors may appear as broken or unavailable to userspace when they are actually just slow to initialize.

2. **Small and contained fix**: The change is minimal - it only adds: - A retry loop around `cros_ec_cmd_xfer_status()` for -EBUSY errors - A 5-6ms delay between retries - A maximum of 50 retries (approximately 250-300ms total timeout) - A warning message when retries were needed

3. **Clear bug fix pattern**: The EC returning -EBUSY (EC_RES_BUSY) is documented behavior indicating "Up but too busy. Should retry". The original code didn't handle this case, leading to sensors being skipped during initialization.

4. **Low regression risk**: - The retry logic only triggers on -EBUSY errors, not affecting the normal path - The change is isolated to sensor initialization during probe - Similar retry patterns exist in other parts of the cros_ec subsystem (e.g., commit 11799564fc7e) - The dev_warn to dev_err change is appropriate as sensor initialization failure is an error condition

5. **Hardware-specific timing issue**: This fixes a timing-dependent hardware initialization issue that can manifest differently across different EC/ISH firmware versions and boot conditions, making it important for stable operation across various Chromebook models.

6. **No architectural changes**: The commit doesn't introduce new features or change any interfaces - it simply makes the existing sensor initialization more robust by handling a known EC busy state.

The commit follows established patterns in the cros_ec subsystem for handling EC_RES_BUSY responses and is a straightforward reliability improvement that should be included in stable kernels to ensure consistent sensor availability on ChromeOS devices.

drivers/platform/chrome/cros_ec_sensorhub.c | 23 +++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_sensorhub.c b/drivers/platform/chrome/cros_ec_sensorhub.c index 50cdae67fa32..9bad8f72680e 100644 --- a/drivers/platform/chrome/cros_ec_sensorhub.c +++ b/drivers/platform/chrome/cros_ec_sensorhub.c @@ -8,6 +8,7 @@

#include <linux/init.h> #include <linux/device.h> +#include <linux/delay.h> #include <linux/mod_devicetable.h> #include <linux/module.h> #include <linux/platform_data/cros_ec_commands.h> @@ -18,6 +19,7 @@ #include <linux/types.h>

#define DRV_NAME "cros-ec-sensorhub" +#define CROS_EC_CMD_INFO_RETRIES 50

static void cros_ec_sensorhub_free_sensor(void *arg) { @@ -53,7 +55,7 @@ static int cros_ec_sensorhub_register(struct device *dev, int sensor_type[MOTIONSENSE_TYPE_MAX] = { 0 }; struct cros_ec_command *msg = sensorhub->msg; struct cros_ec_dev *ec = sensorhub->ec; - int ret, i; + int ret, i, retries; char *name;

@@ -65,12 +67,25 @@ static int cros_ec_sensorhub_register(struct device *dev, sensorhub->params->cmd = MOTIONSENSE_CMD_INFO; sensorhub->params->info.sensor_num = i;

- ret = cros_ec_cmd_xfer_status(ec->ec_dev, msg); + retries = CROS_EC_CMD_INFO_RETRIES; + do { + ret = cros_ec_cmd_xfer_status(ec->ec_dev, msg); + if (ret == -EBUSY) { + /* The EC is still busy initializing sensors. */ + usleep_range(5000, 6000); + retries--; + } + } while (ret == -EBUSY && retries); + if (ret < 0) { - dev_warn(dev, "no info for EC sensor %d : %d/%d\n", - i, ret, msg->result); + dev_err(dev, "no info for EC sensor %d : %d/%d\n", + i, ret, msg->result); continue; } + if (retries < CROS_EC_CMD_INFO_RETRIES) { + dev_warn(dev, "%d retries needed to bring up sensor %d\n", + CROS_EC_CMD_INFO_RETRIES - retries, i); + }

switch (sensorhub->resp->info.type) { case MOTIONSENSE_TYPE_ACCEL:

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 ca7c3517c341..7b090c953974 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3037,6 +3037,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 1139a2754ca3..056d98154682 100644 --- a/sound/soc/codecs/hdac_hdmi.c +++ b/sound/soc/codecs/hdac_hdmi.c @@ -1232,7 +1232,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; }

@@ -1240,7 +1241,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; }

@@ -1299,8 +1301,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: Markus Stockhausen markus.stockhausen@gmx.de

[ Upstream commit 2250db8628a0d8293ad2e0671138b848a185fba1 ]

Devices of the Realtek MIPS Otto platform use the official rtl-otto-timer as clock event generator and CPU clocksource. It is registered for each CPU startup via cpuhp_setup_state() and forces the affinity of the clockevent interrupts to the appropriate CPU via irq_force_affinity().

On the "smaller" devices with a vendor specific interrupt controller (supported by irq-realtek-rtl) the registration works fine. The "larger" RTL931x series is based on a MIPS interAptiv dual core with a MIPS GIC controller. Interrupt routing setup is cancelled because gic_set_affinity() does not accept the current (not yet online) CPU as a target.

Relax the checks by evaluating the force parameter that is provided for exactly this purpose like in other drivers. With this the affinity can be set as follows:

- force = false: allow to set affinity to any online cpu - force = true: allow to set affinity to any cpu

Co-developed-by: Sebastian Gottschall s.gottschall@dd-wrt.com Signed-off-by: Sebastian Gottschall s.gottschall@dd-wrt.com Signed-off-by: Markus Stockhausen markus.stockhausen@gmx.de Signed-off-by: Thomas Gleixner tglx@linutronix.de Link: https://lore.kernel.org/all/20250621054952.380374-1-markus.stockhausen@gmx.d... Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

Based on my analysis of the 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 bug affecting users**: The commit fixes a specific issue where clockevent interrupt affinity setup fails on Realtek RTL931x devices with MIPS GIC controllers. Without this fix, the timer registration during CPU hotplug fails because `gic_set_affinity()` rejects setting affinity to CPUs that are not yet online.

2. **Small and contained fix**: The change is minimal - it only adds 4 lines of code to properly handle the `force` parameter that was already being passed but ignored. The logic change is straightforward: - When `force=false`: Use existing behavior (only allow online CPUs) - When `force=true`: Allow any CPU in the mask

3. **Follows established patterns**: The commit shows that multiple other timer drivers (`timer-rtl-otto.c`, `timer-tegra.c`, `exynos_mct.c`, etc.) use `irq_force_affinity()` during CPU hotplug, which eventually calls the chip's `set_affinity` handler with `force=true`. The MIPS GIC driver was incorrectly ignoring this parameter.

4. **No architectural changes**: This is purely a bug fix that makes the MIPS GIC driver honor the existing `force` parameter semantics. It doesn't introduce new features or change any architecture.

5. **Clear use case**: The commit message clearly explains that this affects real hardware (Realtek RTL931x series) and prevents proper timer initialization during CPU hotplug, which is a fundamental kernel operation.

6. **Low regression risk**: The change only affects behavior when `force=true` is explicitly passed, which is specifically for CPU hotplug scenarios. Normal interrupt affinity operations (with `force=false`) remain unchanged.

7. **Aligns with kernel conventions**: The kernel documentation for `irq_force_affinity()` explicitly states it's "Solely for low level cpu hotplug code, where we need to make per cpu interrupts affine before the cpu becomes online." This commit makes the MIPS GIC driver comply with this intended behavior.

The fix is essential for proper operation of affected hardware and follows the stable kernel criteria of being a important bugfix with minimal risk.

drivers/irqchip/irq-mips-gic.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips-gic.c index bca8053864b2..1c2284297354 100644 --- a/drivers/irqchip/irq-mips-gic.c +++ b/drivers/irqchip/irq-mips-gic.c @@ -375,9 +375,13 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *cpumask, /* * The GIC specifies that we can only route an interrupt to one VP(E), * ie. CPU in Linux parlance, at a time. Therefore we always route to - * the first online CPU in the mask. + * the first forced or online CPU in the mask. */ - cpu = cpumask_first_and(cpumask, cpu_online_mask); + if (force) + cpu = cpumask_first(cpumask); + else + cpu = cpumask_first_and(cpumask, cpu_online_mask); + if (cpu >= NR_CPUS) return -EINVAL;

From: Joseph Tilahun jtilahun@astranis.com

[ Upstream commit 33a2515abd45c64911955ff1da179589db54f99f ]

The serial info sometimes produces negative TX/RX counts. E.g.:

3: uart:FSL_LPUART mmio:0x02970000 irq:46 tx:-1595870545 rx:339619 RTS|CTS|DTR|DSR|CD

It appears that the print format specifiers don't match with the types of the respective variables. E.g.: All of the fields in struct uart_icount are u32, but the format specifier used is %d, even though u32 is unsigned and %d is for signed integers. Update drivers/tty/serial/serial_core.c to use the proper format specifiers. Reference https://docs.kernel.org/core-api/printk-formats.html as the documentation for what format specifiers are the proper ones to use for a given C type.

Signed-off-by: Joseph Tilahun jtilahun@astranis.com Link: https://lore.kernel.org/r/20250610065653.3750067-1-jtilahun@astranis.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:

**YES**

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

1. **It fixes a real user-visible bug**: The commit fixes incorrect format specifiers that cause negative values to be displayed for TX/RX counts in `/proc/tty/driver/serial`. The example shows: ``` 3: uart:FSL_LPUART mmio:0x02970000 irq:46 tx:-1595870545 rx:339619 ``` This is clearly wrong as TX/RX counts should never be negative.

2. **The fix is simple and contained**: The changes only modify format specifiers from `%d` (signed) to `%u` (unsigned) in print statements. Looking at the code: - All `uart_icount` fields (tx, rx, frame, parity, brk, overrun, buf_overrun) are defined as `__u32` (unsigned 32-bit) - `port->line` is `unsigned int` - `port->irq` is `unsigned int` - `port->uartclk` is `unsigned int` - Other fields like `close_delay`, `closing_wait`, `io_type`, `iomem_reg_shift` are also unsigned types

3. **Low risk of regression**: The changes are purely cosmetic - they only affect how values are displayed, not the actual functionality. No logic changes, no structural changes, just format string corrections.

4. **Affects a core subsystem**: The serial core is used by many serial drivers, so this bug affects multiple platforms and drivers. The fix benefits all users of the serial subsystem.

5. **Follows stable tree rules**: This is exactly the type of fix suitable for stable: - Fixes an actual bug (incorrect display of statistics) - Minimal change - Obviously correct (matching format specifiers to variable types) - No new features or architectural changes

The commit is a straightforward correctness fix that improves the reliability of kernel diagnostics output without any risk of breaking functionality.

drivers/tty/serial/serial_core.c | 44 ++++++++++++++++---------------- 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index 88669972d9a0..8658377dbe1c 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -1337,28 +1337,28 @@ static void uart_sanitize_serial_rs485_delays(struct uart_port *port, if (!port->rs485_supported.delay_rts_before_send) { if (rs485->delay_rts_before_send) { dev_warn_ratelimited(port->dev, - "%s (%d): RTS delay before sending not supported\n", + "%s (%u): RTS delay before sending not supported\n", port->name, port->line); } rs485->delay_rts_before_send = 0; } else if (rs485->delay_rts_before_send > RS485_MAX_RTS_DELAY) { rs485->delay_rts_before_send = RS485_MAX_RTS_DELAY; dev_warn_ratelimited(port->dev, - "%s (%d): RTS delay before sending clamped to %u ms\n", + "%s (%u): RTS delay before sending clamped to %u ms\n", port->name, port->line, rs485->delay_rts_before_send); }

if (!port->rs485_supported.delay_rts_after_send) { if (rs485->delay_rts_after_send) { dev_warn_ratelimited(port->dev, - "%s (%d): RTS delay after sending not supported\n", + "%s (%u): RTS delay after sending not supported\n", port->name, port->line); } rs485->delay_rts_after_send = 0; } else if (rs485->delay_rts_after_send > RS485_MAX_RTS_DELAY) { rs485->delay_rts_after_send = RS485_MAX_RTS_DELAY; dev_warn_ratelimited(port->dev, - "%s (%d): RTS delay after sending clamped to %u ms\n", + "%s (%u): RTS delay after sending clamped to %u ms\n", port->name, port->line, rs485->delay_rts_after_send); } } @@ -1388,14 +1388,14 @@ static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs4 rs485->flags &= ~SER_RS485_RTS_AFTER_SEND;

dev_warn_ratelimited(port->dev, - "%s (%d): invalid RTS setting, using RTS_ON_SEND instead\n", + "%s (%u): invalid RTS setting, using RTS_ON_SEND instead\n", port->name, port->line); } else { rs485->flags |= SER_RS485_RTS_AFTER_SEND; rs485->flags &= ~SER_RS485_RTS_ON_SEND;

dev_warn_ratelimited(port->dev, - "%s (%d): invalid RTS setting, using RTS_AFTER_SEND instead\n", + "%s (%u): invalid RTS setting, using RTS_AFTER_SEND instead\n", port->name, port->line); } } @@ -1834,7 +1834,7 @@ static void uart_wait_until_sent(struct tty_struct *tty, int timeout)

expire = jiffies + timeout;

- pr_debug("uart_wait_until_sent(%d), jiffies=%lu, expire=%lu...\n", + pr_debug("uart_wait_until_sent(%u), jiffies=%lu, expire=%lu...\n", port->line, jiffies, expire);

/* @@ -2029,7 +2029,7 @@ static void uart_line_info(struct seq_file *m, struct uart_state *state) return;

mmio = uport->iotype >= UPIO_MEM; - seq_printf(m, "%d: uart:%s %s%08llX irq:%d", + seq_printf(m, "%u: uart:%s %s%08llX irq:%u", uport->line, uart_type(uport), mmio ? "mmio:0x" : "port:", mmio ? (unsigned long long)uport->mapbase @@ -2051,18 +2051,18 @@ static void uart_line_info(struct seq_file *m, struct uart_state *state) if (pm_state != UART_PM_STATE_ON) uart_change_pm(state, pm_state);

- seq_printf(m, " tx:%d rx:%d", + seq_printf(m, " tx:%u rx:%u", uport->icount.tx, uport->icount.rx); if (uport->icount.frame) - seq_printf(m, " fe:%d", uport->icount.frame); + seq_printf(m, " fe:%u", uport->icount.frame); if (uport->icount.parity) - seq_printf(m, " pe:%d", uport->icount.parity); + seq_printf(m, " pe:%u", uport->icount.parity); if (uport->icount.brk) - seq_printf(m, " brk:%d", uport->icount.brk); + seq_printf(m, " brk:%u", uport->icount.brk); if (uport->icount.overrun) - seq_printf(m, " oe:%d", uport->icount.overrun); + seq_printf(m, " oe:%u", uport->icount.overrun); if (uport->icount.buf_overrun) - seq_printf(m, " bo:%d", uport->icount.buf_overrun); + seq_printf(m, " bo:%u", uport->icount.buf_overrun);

#define INFOBIT(bit, str) \ if (uport->mctrl & (bit)) \ @@ -2554,7 +2554,7 @@ uart_report_port(struct uart_driver *drv, struct uart_port *port) break; }

- pr_info("%s%s%s at %s (irq = %d, base_baud = %d) is a %s\n", + pr_info("%s%s%s at %s (irq = %u, base_baud = %u) is a %s\n", port->dev ? dev_name(port->dev) : "", port->dev ? ": " : "", port->name, @@ -2562,7 +2562,7 @@ uart_report_port(struct uart_driver *drv, struct uart_port *port)

/* The magic multiplier feature is a bit obscure, so report it too. */ if (port->flags & UPF_MAGIC_MULTIPLIER) - pr_info("%s%s%s extra baud rates supported: %d, %d", + pr_info("%s%s%s extra baud rates supported: %u, %u", port->dev ? dev_name(port->dev) : "", port->dev ? ": " : "", port->name, @@ -2961,7 +2961,7 @@ static ssize_t close_delay_show(struct device *dev, struct tty_port *port = dev_get_drvdata(dev);

uart_get_info(port, &tmp); - return sprintf(buf, "%d\n", tmp.close_delay); + return sprintf(buf, "%u\n", tmp.close_delay); }

static ssize_t closing_wait_show(struct device *dev, @@ -2971,7 +2971,7 @@ static ssize_t closing_wait_show(struct device *dev, struct tty_port *port = dev_get_drvdata(dev);

uart_get_info(port, &tmp); - return sprintf(buf, "%d\n", tmp.closing_wait); + return sprintf(buf, "%u\n", tmp.closing_wait); }

static ssize_t custom_divisor_show(struct device *dev, @@ -2991,7 +2991,7 @@ static ssize_t io_type_show(struct device *dev, struct tty_port *port = dev_get_drvdata(dev);

uart_get_info(port, &tmp); - return sprintf(buf, "%d\n", tmp.io_type); + return sprintf(buf, "%u\n", tmp.io_type); }

static ssize_t iomem_base_show(struct device *dev, @@ -3011,7 +3011,7 @@ static ssize_t iomem_reg_shift_show(struct device *dev, struct tty_port *port = dev_get_drvdata(dev);

uart_get_info(port, &tmp); - return sprintf(buf, "%d\n", tmp.iomem_reg_shift); + return sprintf(buf, "%u\n", tmp.iomem_reg_shift); }

static ssize_t console_show(struct device *dev, @@ -3147,7 +3147,7 @@ static int serial_core_add_one_port(struct uart_driver *drv, struct uart_port *u state->pm_state = UART_PM_STATE_UNDEFINED; uart_port_set_cons(uport, drv->cons); uport->minor = drv->tty_driver->minor_start + uport->line; - uport->name = kasprintf(GFP_KERNEL, "%s%d", drv->dev_name, + uport->name = kasprintf(GFP_KERNEL, "%s%u", drv->dev_name, drv->tty_driver->name_base + uport->line); if (!uport->name) return -ENOMEM; @@ -3186,7 +3186,7 @@ static int serial_core_add_one_port(struct uart_driver *drv, struct uart_port *u device_set_wakeup_capable(tty_dev, 1); } else { uport->flags |= UPF_DEAD; - dev_err(uport->dev, "Cannot register tty device on line %d\n", + dev_err(uport->dev, "Cannot register tty device on line %u\n", uport->line); }

From: Tomasz Michalec tmichalec@google.com

[ Upstream commit df9a825f330e76c72d1985bc9bdc4b8981e3d15f ]

If pmc_usb_probe is called before SCU IPC is registered, pmc_usb_probe will fail.

Return -EPROBE_DEFER when pmc_usb_probe doesn't get SCU IPC device, so the probe function can be called again after SCU IPC is initialized.

Signed-off-by: Tomasz Michalec tmichalec@google.com Reviewed-by: Heikki Krogerus heikki.krogerus@linux.intel.com Link: https://lore.kernel.org/r/20250610154058.1859812-1-tmichalec@google.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 kernel codebase, here's my assessment:

**Backport Status: YES**

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

1. **Clear Bug Fix**: The commit fixes a real probe ordering issue where `pmc_usb_probe` fails if called before the SCU IPC driver is initialized. The current code returns `-ENODEV` which prevents the driver from ever loading, while `-EPROBE_DEFER` allows the kernel to retry probing later.

2. **Established Pattern**: Looking at the codebase, other Intel platform drivers that depend on SCU IPC already use this pattern: - `drivers/watchdog/intel-mid_wdt.c`: Returns `-EPROBE_DEFER` when `devm_intel_scu_ipc_dev_get()` returns NULL - `drivers/mfd/intel_soc_pmic_bxtwc.c`: Returns `-EPROBE_DEFER` in the same scenario - `drivers/platform/x86/intel/telemetry/pltdrv.c`: Also uses `-EPROBE_DEFER`

3. **Small and Contained Change**: The fix is a one-line change (`-ENODEV` → `-EPROBE_DEFER`) that only affects the error handling path during probe. It doesn't introduce new functionality or change any existing behavior when SCU IPC is available.

4. **No Architecture Changes**: This is purely a bug fix that corrects incorrect error handling. It doesn't introduce new features or make architectural changes to the driver.

5. **Minimal Risk**: The change is extremely low risk - it only affects the error path when SCU IPC isn't yet available, and the deferred probe mechanism is a well-established kernel pattern designed specifically for handling driver dependencies.

6. **Real-World Impact**: Without this fix, users could experience USB Type-C functionality failures on Intel platforms if the drivers happen to probe in the wrong order. This is particularly problematic on systems where driver probe order is non-deterministic.

The commit follows the stable tree rules by fixing an important bug (probe failure due to ordering) with minimal risk and no new features. The fact that other Intel drivers already use this pattern confirms this is the correct approach for handling SCU IPC dependencies.

drivers/usb/typec/mux/intel_pmc_mux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/typec/mux/intel_pmc_mux.c b/drivers/usb/typec/mux/intel_pmc_mux.c index 65dda9183e6f..1698428654ab 100644 --- a/drivers/usb/typec/mux/intel_pmc_mux.c +++ b/drivers/usb/typec/mux/intel_pmc_mux.c @@ -754,7 +754,7 @@ static int pmc_usb_probe(struct platform_device *pdev)

pmc->ipc = devm_intel_scu_ipc_dev_get(&pdev->dev); if (!pmc->ipc) - return -ENODEV; + return -EPROBE_DEFER;

pmc->dev = &pdev->dev;

From: Yongbo Zhang giraffesnn123@gmail.com

[ Upstream commit 1c2d81bded1993bb2c7125a911db63612cdc8d40 ]

When the gpio irqchip connected to a slow bus(e.g., i2c bus or virtio bus), calling disable_irq_nosync() in top-half ISR handler will trigger the following kernel BUG:

BUG: scheduling while atomic: RenderEngine/253/0x00010002 ... Call trace: dump_backtrace+0x0/0x1c8 show_stack+0x1c/0x2c dump_stack_lvl+0xdc/0x12c dump_stack+0x1c/0x64 __schedule_bug+0x64/0x80 schedule_debug+0x98/0x118 __schedule+0x68/0x704 schedule+0xa0/0xe8 schedule_timeout+0x38/0x124 wait_for_common+0xa4/0x134 wait_for_completion+0x1c/0x2c _virtio_gpio_req+0xf8/0x198 virtio_gpio_irq_bus_sync_unlock+0x94/0xf0 __irq_put_desc_unlock+0x50/0x54 disable_irq_nosync+0x64/0x94 fusb302_irq_intn+0x24/0x84 __handle_irq_event_percpu+0x84/0x278 handle_irq_event+0x64/0x14c handle_level_irq+0x134/0x1d4 generic_handle_domain_irq+0x40/0x68 virtio_gpio_event_vq+0xb0/0x130 vring_interrupt+0x7c/0x90 vm_interrupt+0x88/0xd8 __handle_irq_event_percpu+0x84/0x278 handle_irq_event+0x64/0x14c handle_fasteoi_irq+0x110/0x210 __handle_domain_irq+0x80/0xd0 gic_handle_irq+0x78/0x154 el0_irq_naked+0x60/0x6c

This patch replaces request_irq() with devm_request_threaded_irq() to avoid the use of disable_irq_nosync().

Signed-off-by: Yongbo Zhang giraffesnn123@gmail.com Reviewed-by: Heikki Krogerus heikki.krogerus@linux.intel.com Link: https://lore.kernel.org/r/20250526043433.673097-1-giraffesnn123@gmail.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:

**Backport Status: YES**

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

## Bug Analysis

The commit fixes a critical "scheduling while atomic" bug that occurs when the fusb302 USB Type-C controller uses GPIO interrupts connected through slow buses (like I2C or virtio). The bug manifests as a kernel BUG with the following call trace showing `__schedule_bug` being triggered from within an atomic context.

## Technical Details of the Bug

1. **Root Cause**: The fusb302 driver's interrupt handler (`fusb302_irq_intn`) calls `disable_irq_nosync()` from the top-half ISR context (lines 1480-1481 in the original code). When the GPIO controller is connected via a slow bus like virtio-gpio, the `disable_irq_nosync()` operation requires bus transactions that can sleep, which is forbidden in atomic/interrupt context.

2. **The Problem Flow**: - Hardware interrupt occurs → `fusb302_irq_intn` ISR runs in atomic context - ISR calls `disable_irq_nosync(chip->gpio_int_n_irq)` - virtio-gpio's `virtio_gpio_irq_bus_sync_unlock()` needs to communicate over virtio bus - This requires `wait_for_completion()` which can sleep - Sleeping in atomic context triggers the kernel BUG

## The Fix

The fix replaces `request_irq()` with `devm_request_threaded_irq()` and removes the problematic `disable_irq_nosync()`/`enable_irq()` pattern:

1. **Before**: Used regular IRQ handler that disabled the interrupt in top-half, scheduled work, then re-enabled in bottom-half 2. **After**: Uses threaded IRQ handler which naturally handles the interrupt masking/unmasking without explicit calls

Key changes: - Line 1751-1754: Changed from `request_irq()` to `devm_request_threaded_irq()` with NULL top-half handler - Line 1481: Removed `disable_irq_nosync()` call from ISR - Line 1625: Removed corresponding `enable_irq()` call from work function - Line 1750: Removed `free_irq()` call (handled by devm_*)

## Stable Backport Criteria Evaluation

1. **Fixes a bug affecting users**: YES - This fixes a kernel BUG that causes system instability 2. **Relatively small and contained**: YES - Only 7 lines changed, confined to one driver file 3. **Clear side effects**: NO - The fix is straightforward with no architectural changes 4. **Major architectural changes**: NO - Simply changes IRQ registration method 5. **Critical kernel subsystems**: NO - Limited to USB Type-C controller driver 6. **Stable tree mention**: NO - But follows stable tree rules perfectly 7. **Follows stable rules**: YES - Important bugfix with minimal risk

## Additional Considerations

- The bug only manifests with specific hardware configurations (virtio- gpio or slow I2C GPIO expanders) - The fix is a standard pattern used throughout the kernel for similar issues - Using `devm_request_threaded_irq()` is actually cleaner and provides automatic cleanup - No functional changes to the driver's behavior, only fixes the atomic scheduling violation - Similar fixes have been applied to other drivers facing the same issue pattern

This is an ideal stable backport candidate: it fixes a real bug that causes kernel panics, the fix is minimal and well-understood, and there's virtually no risk of regression.

drivers/usb/typec/tcpm/fusb302.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/typec/tcpm/fusb302.c b/drivers/usb/typec/tcpm/fusb302.c index f15c63d3a8f4..f2801279c4b5 100644 --- a/drivers/usb/typec/tcpm/fusb302.c +++ b/drivers/usb/typec/tcpm/fusb302.c @@ -1477,9 +1477,6 @@ static irqreturn_t fusb302_irq_intn(int irq, void *dev_id) struct fusb302_chip *chip = dev_id; unsigned long flags;

- /* Disable our level triggered IRQ until our irq_work has cleared it */ - disable_irq_nosync(chip->gpio_int_n_irq); - spin_lock_irqsave(&chip->irq_lock, flags); if (chip->irq_suspended) chip->irq_while_suspended = true; @@ -1622,7 +1619,6 @@ static void fusb302_irq_work(struct work_struct *work) } done: mutex_unlock(&chip->lock); - enable_irq(chip->gpio_int_n_irq); }

static int init_gpio(struct fusb302_chip *chip) @@ -1747,9 +1743,10 @@ static int fusb302_probe(struct i2c_client *client) goto destroy_workqueue; }

- ret = request_irq(chip->gpio_int_n_irq, fusb302_irq_intn, - IRQF_ONESHOT | IRQF_TRIGGER_LOW, - "fsc_interrupt_int_n", chip); + ret = devm_request_threaded_irq(dev, chip->gpio_int_n_irq, + NULL, fusb302_irq_intn, + IRQF_ONESHOT | IRQF_TRIGGER_LOW, + "fsc_interrupt_int_n", chip); if (ret < 0) { dev_err(dev, "cannot request IRQ for GPIO Int_N, ret=%d", ret); goto tcpm_unregister_port; @@ -1774,7 +1771,6 @@ static void fusb302_remove(struct i2c_client *client) struct fusb302_chip *chip = i2c_get_clientdata(client);

disable_irq_wake(chip->gpio_int_n_irq); - free_irq(chip->gpio_int_n_irq, chip); cancel_work_sync(&chip->irq_work); cancel_delayed_work_sync(&chip->bc_lvl_handler); tcpm_unregister_port(chip->tcpm_port);

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 73b6b10cbdd2..5ae02c3d5b64 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 b2c0fb55d4ae..44589d10b15b 100644 --- a/drivers/soc/qcom/mdt_loader.c +++ b/drivers/soc/qcom/mdt_loader.c @@ -83,7 +83,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]; @@ -135,7 +135,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); @@ -215,7 +215,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]; @@ -270,7 +270,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++) { /* @@ -312,7 +312,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 7678e3d05fd3..f437b594055c 100644 --- a/drivers/platform/chrome/cros_ec_typec.c +++ b/drivers/platform/chrome/cros_ec_typec.c @@ -1272,8 +1272,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 853ac5bb33ff..ecb71bf1859d 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"

@@ -3130,13 +3131,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 5e0be36af0c5..32063f54f364 100644 --- a/drivers/iio/adc/ad7768-1.c +++ b/drivers/iio/adc/ad7768-1.c @@ -202,6 +202,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) { @@ -289,10 +307,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 9946f12254b3..b456e096f138 100644 --- a/sound/soc/qcom/lpass-platform.c +++ b/sound/soc/qcom/lpass-platform.c @@ -202,7 +202,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; @@ -1190,13 +1189,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);

@@ -1207,14 +1207,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); }

@@ -1224,7 +1229,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 +