From: "Guilherme G. Piccoli" gpiccoli@igalia.com

[ Upstream commit 08d7becc1a6b8c936e25d827becabfe3bff72a36 ]

Right now, if the clocksource watchdog detects a clocksource skew, it might perform a per CPU check, for example in the TSC case on x86. In other words: supposing TSC is detected as unstable by the clocksource watchdog running at CPU1, as part of marking TSC unstable the kernel will also run a check of TSC readings on some CPUs to be sure it is synced between them all.

But that check happens only on some CPUs, not all of them; this choice is based on the parameter "verify_n_cpus" and in some random cpumask calculation. So, the watchdog runs such per CPU checks on up to "verify_n_cpus" random CPUs among all online CPUs, with the risk of repeating CPUs (that aren't double checked) in the cpumask random calculation.

But if "verify_n_cpus" > num_online_cpus(), it should skip the random calculation and just go ahead and check the clocksource sync between all online CPUs, without the risk of skipping some CPUs due to duplicity in the random cpumask calculation.

Tests in a 4 CPU laptop with TSC skew detected led to some cases of the per CPU verification skipping some CPU even with verify_n_cpus=8, due to the duplicity on random cpumask generation. Skipping the randomization when the number of online CPUs is smaller than verify_n_cpus, solves that.

Suggested-by: Thadeu Lima de Souza Cascardo cascardo@igalia.com Signed-off-by: Guilherme G. Piccoli gpiccoli@igalia.com Signed-off-by: Thomas Gleixner tglx@linutronix.de Reviewed-by: Paul E. McKenney paulmck@kernel.org Link: https://lore.kernel.org/all/20250323173857.372390-1-gpiccoli@igalia.com Signed-off-by: Sasha Levin sashal@kernel.org ---

Perfect! Now I understand the issue. Let me also check what happens when there are duplicates in the random CPU selection by looking at the commit message and changes more carefully. **Analysis:** **YES** - This commit should be backported to stable kernel trees. This is a targeted bug fix that addresses a specific issue in the clocksource watchdog's per-CPU verification mechanism. Here's my detailed analysis: ## What the Bug Fixes The commit fixes a logic flaw in `clocksource_verify_choose_cpus()` in `/home/sasha/linux/kernel/time/clocksource.c:309`. When the clocksource watchdog detects a potentially unstable clocksource (like TSC), it performs additional per-CPU verification to check if the clocksource readings are synchronized across different CPUs. The bug occurs in the CPU selection logic: **Original problematic logic:** ```c if (n < 0) { /bin /bin.usr-is-merged /boot /dev /etc /home /init /lib /lib.usr-is- merged /lib64 /lost+found /media /mnt /opt /proc /root /run /sbin /sbin.usr-is-merged /snap /srv /sys /tmp /usr /var Check all of the CPUs. model/ prompt/ src/ target/ cpumask_copy(&cpus_chosen, cpu_online_mask); cpumask_clear_cpu(smp_processor_id(), &cpus_chosen); return; } ``` **Fixed logic:** ```c if (n < 0 || n >= num_online_cpus()) { /bin /bin.usr-is-merged /boot /dev /etc /home /init /lib /lib.usr-is- merged /lib64 /lost+found /media /mnt /opt /proc /root /run /sbin /sbin.usr-is-merged /snap /srv /sys /tmp /usr /var Check all of the CPUs. model/ prompt/ src/ target/ cpumask_copy(&cpus_chosen, cpu_online_mask); cpumask_clear_cpu(smp_processor_id(), &cpus_chosen); return; } ``` ## The Problem When `verify_n_cpus` (default value 8) is greater than `num_online_cpus()`, the code would fall through to the random CPU selection logic, which has a critical flaw: it can select the same CPU multiple times due to the random nature of `get_random_u32_below()`. This means some CPUs might never be checked for clocksource synchronization, potentially missing real synchronization issues. For example, on a 4-CPU system with `verify_n_cpus=8`, instead of checking all 4 CPUs, the random selection might pick CPU 1 three times and CPU 2 once, leaving CPUs 3 and 4 unchecked. ## Why This Should Be Backported 1. **Fixes a Real Bug**: This addresses an actual functional issue where clocksource verification might miss CPUs, potentially failing to detect real synchronization problems. 2. **Small, Contained Change**: The fix adds a single condition (`|| n >= num_online_cpus()`) to an existing if statement. This is minimal and low-risk. 3. **No Architectural Changes**: This doesn't change the overall design or introduce new features - it just fixes the selection logic. 4. **Critical Subsystem**: Clocksource stability is crucial for kernel timekeeping. Missing synchronization issues could lead to time-related bugs. 5. **Matches Stable Criteria**: - Fixes important functionality - Minimal risk of regression - Contained to one subsystem (timekeeping) - Clear bug with clear fix 6. **Historical Pattern**: Looking at the similar commits provided, commits that fix specific logic bugs in critical kernel subsystems (especially timing-related) are typically backported (like Similar Commit #2 and #3 which were marked "YES"). ## Risk Assessment **Very Low Risk**: The change only affects the CPU selection logic when `verify_n_cpus >= num_online_cpus()`. In this case, the new logic ensures all CPUs are checked rather than relying on potentially incomplete random selection. This is strictly an improvement with no downside. The fix ensures more thorough verification, which could only improve clocksource reliability, not harm it.

kernel/time/clocksource.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c index bb48498ebb5a8..6a8bc7da90626 100644 --- a/kernel/time/clocksource.c +++ b/kernel/time/clocksource.c @@ -310,7 +310,7 @@ static void clocksource_verify_choose_cpus(void) { int cpu, i, n = verify_n_cpus;

- if (n < 0) { + if (n < 0 || n >= num_online_cpus()) { /* Check all of the CPUs. */ cpumask_copy(&cpus_chosen, cpu_online_mask); cpumask_clear_cpu(smp_processor_id(), &cpus_chosen);

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

[ Upstream commit e5407c0820ea5fa7117b85ed32b724af73156d63 ]

The printf format checking in the compiler uses the intmax types from the compiler, not libc. This can lead to compiler errors.

Instead use the types already provided by the compiler.

Example issue with clang 19 for arm64:

nolibc-test.c:30:2: error: format specifies type 'uintmax_t' (aka 'unsigned long') but the argument has type 'uintmax_t' (aka 'unsigned long long') [-Werror,-Wformat]

Signed-off-by: Thomas Weißschuh thomas.weissschuh@linutronix.de Acked-by: Willy Tarreau w@1wt.eu Signed-off-by: Sasha Levin sashal@kernel.org ---

**YES** This commit should be backported to stable kernel trees. ## Detailed Analysis: ### Code Changes Analysis: The commit makes a targeted fix to `tools/include/nolibc/stdint.h` by replacing: ```c typedef int64_t intmax_t; typedef uint64_t uintmax_t; ``` with: ```c typedef __INTMAX_TYPE__ intmax_t; typedef __UINTMAX_TYPE__ uintmax_t; ``` ### Problem Being Fixed: This addresses a **compiler format checking incompatibility** where: - The compiler's printf format checking uses intmax types from the compiler itself, not from libc - This mismatch causes compilation errors with clang 19 on arm64 - The error occurs because nolibc defined intmax_t as `unsigned long long` while the compiler expected `unsigned long` ### Evidence Supporting Backport: **1. Similar Pattern Match:** This closely follows the pattern of Similar Commit #4 and #5 (both marked YES for backport): - Similar Commit #4: Fixed integer type definitions for 32-bit platforms (backported) - Similar Commit #5: Fixed printf format mismatches with compiler warnings (backported with Cc: stable@vger.kernel.org) **2. Bug Fix Nature:** This is clearly a **bug fix** that: - Resolves compilation failures with clang 19 - Fixes format checking incompatibilities between compiler and library definitions - Affects actual build failures, not just warnings **3. Low Risk/High Impact:** - **Minimal change scope**: Only changes 2 typedef lines - **Contained to nolibc**: Affects only the tools/nolibc subsystem - **Uses compiler-provided types**: More robust than hardcoded definitions - **Fixes build breakage**: Critical for users with newer compilers **4. Aligns with Stable Criteria:** - Fixes important build issues affecting users - Small, contained change with minimal regression risk - No architectural changes or new features - Resolves compatibility with current/newer toolchains **5. Historical Context:** From the kernel repository examination: - Previous similar format-related fixes (commit 92098b1c10cb) were already tagged for stable with `Cc: stable@vger.kernel.org` - The nolibc subsystem has a history of backporting compiler compatibility fixes - The pattern of using compiler-provided types (like `__SIZE_TYPE__`) is already established in the codebase **6. User Impact:** This prevents build failures for users with: - clang 19 on arm64 - Potentially other compiler/architecture combinations where intmax_t definitions differ - Any nolibc-based applications or tests The commit represents exactly the type of fix that stable trees are designed for: a small, targeted fix that resolves build breakage without introducing new features or architectural changes.

tools/include/nolibc/stdint.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/include/nolibc/stdint.h b/tools/include/nolibc/stdint.h index cd79ddd6170e0..b052ad6303c38 100644 --- a/tools/include/nolibc/stdint.h +++ b/tools/include/nolibc/stdint.h @@ -39,8 +39,8 @@ typedef size_t uint_fast32_t; typedef int64_t int_fast64_t; typedef uint64_t uint_fast64_t;

-typedef int64_t intmax_t; -typedef uint64_t uintmax_t; +typedef __INTMAX_TYPE__ intmax_t; +typedef __UINTMAX_TYPE__ uintmax_t;

/* limits of integral types */

From: Erick Shepherd erick.shepherd@ni.com

[ Upstream commit 9510b38dc0ba358c93cbf5ee7c28820afb85937b ]

Adds the MMC_QUIRK_NO_UHS_DDR50_TUNING quirk and updates mmc_execute_tuning() to return 0 if that quirk is set. This fixes an issue on certain Swissbit SD cards that do not support DDR50 tuning where tuning requests caused I/O errors to be thrown.

Signed-off-by: Erick Shepherd erick.shepherd@ni.com Acked-by: Adrian Hunter adrian.hunter@intel.com Link: https://lore.kernel.org/r/20250331221337.1414534-1-erick.shepherd@ni.com Signed-off-by: Ulf Hansson ulf.hansson@linaro.org Signed-off-by: Sasha Levin sashal@kernel.org ---

**YES** This commit should be backported to stable kernel trees. Here's my detailed analysis: ## Bug Fix Classification This is clearly a **bugfix**, not a new feature. The commit fixes I/O errors that occur on specific Swissbit SD cards when DDR50 tuning is attempted. The commit message explicitly states: "This fixes an issue on certain Swissbit SD cards that do not support DDR50 tuning where tuning requests caused I/O errors to be thrown." ## Code Change Analysis ### 1. **Minimal and Targeted Changes** The changes are very focused and follow established kernel patterns: - **New quirk flag**: `MMC_QUIRK_NO_UHS_DDR50_TUNING (1<<18)` in `include/linux/mmc/card.h` - **Helper function**: `mmc_card_no_uhs_ddr50_tuning()` in `drivers/mmc/core/card.h` - **Specific card targeting**: Only affects Swissbit cards (manufacturer ID 0x5D) with specific model/date criteria - **Logic refactoring**: Extracts tuning decision into `mmc_sd_use_tuning()` function ### 2. **Low Risk Implementation** The implementation uses the existing MMC quirk infrastructure, which is well-tested: - Follows the same pattern as Similar Commit #2 (marked YES for backport) - Uses standard `_FIXUP_EXT()` macro with precise card identification - Only affects the specific problematic cards, leaving all others unchanged ### 3. **Controlled Scope** The quirk is highly specific: ```c _FIXUP_EXT("0016G", CID_MANFID_SWISSBIT, 0x5342, 2019, 1, 0, -1ull, SDIO_ANY_ID, SDIO_ANY_ID, add_quirk_sd, MMC_QUIRK_NO_UHS_DDR50_TUNING, EXT_CSD_REV_ANY), ``` This targets only Swissbit cards with model "0016G", OEM ID 0x5342, manufactured in January 2019. ## Comparison with Similar Commits This commit closely matches **Similar Commit #2** (YES for backport), which also: - Adds quirk handling for specific hardware issues - Makes minimal, contained changes - Fixes real user-facing problems - Uses existing infrastructure Unlike **Similar Commit #1** (NO for backport), this commit: - Fixes an existing bug rather than adding new functionality - Doesn't introduce new interfaces or capabilities - Has minimal risk of regression ## User Impact Without this fix, affected Swissbit SD cards would be **unusable** due to I/O errors during tuning. This represents a significant hardware compatibility issue that makes the cards completely non-functional on affected systems. ## Stable Tree Criteria Compliance ✅ **Important bugfix**: Fixes I/O errors on specific hardware ✅ **Minimal risk**: Uses established quirk infrastructure ✅ **No architectural changes**: Follows existing patterns ✅ **Contained scope**: Only affects specific problematic cards ✅ **No new features**: Pure hardware compatibility fix The commit follows the stable tree rule that quirks for hardware compatibility issues are generally acceptable for backporting when they fix real problems with minimal risk.

drivers/mmc/core/card.h | 6 ++++++ drivers/mmc/core/quirks.h | 10 ++++++++++ drivers/mmc/core/sd.c | 32 ++++++++++++++++++++++++-------- include/linux/mmc/card.h | 1 + 4 files changed, 41 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/core/card.h b/drivers/mmc/core/card.h index 3205feb1e8ff6..9cbdd240c3a7d 100644 --- a/drivers/mmc/core/card.h +++ b/drivers/mmc/core/card.h @@ -89,6 +89,7 @@ struct mmc_fixup { #define CID_MANFID_MICRON 0x13 #define CID_MANFID_SAMSUNG 0x15 #define CID_MANFID_APACER 0x27 +#define CID_MANFID_SWISSBIT 0x5D #define CID_MANFID_KINGSTON 0x70 #define CID_MANFID_HYNIX 0x90 #define CID_MANFID_KINGSTON_SD 0x9F @@ -294,4 +295,9 @@ static inline int mmc_card_broken_sd_poweroff_notify(const struct mmc_card *c) return c->quirks & MMC_QUIRK_BROKEN_SD_POWEROFF_NOTIFY; }

+static inline int mmc_card_no_uhs_ddr50_tuning(const struct mmc_card *c) +{ + return c->quirks & MMC_QUIRK_NO_UHS_DDR50_TUNING; +} + #endif diff --git a/drivers/mmc/core/quirks.h b/drivers/mmc/core/quirks.h index 89b512905be14..7f893bafaa607 100644 --- a/drivers/mmc/core/quirks.h +++ b/drivers/mmc/core/quirks.h @@ -34,6 +34,16 @@ static const struct mmc_fixup __maybe_unused mmc_sd_fixups[] = { MMC_QUIRK_BROKEN_SD_CACHE | MMC_QUIRK_BROKEN_SD_POWEROFF_NOTIFY, EXT_CSD_REV_ANY),

+ /* + * Swissbit series S46-u cards throw I/O errors during tuning requests + * after the initial tuning request expectedly times out. This has + * only been observed on cards manufactured on 01/2019 that are using + * Bay Trail host controllers. + */ + _FIXUP_EXT("0016G", CID_MANFID_SWISSBIT, 0x5342, 2019, 1, + 0, -1ull, SDIO_ANY_ID, SDIO_ANY_ID, add_quirk_sd, + MMC_QUIRK_NO_UHS_DDR50_TUNING, EXT_CSD_REV_ANY), + END_FIXUP };

diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c index 8eba697d3d867..6847b3fe8887a 100644 --- a/drivers/mmc/core/sd.c +++ b/drivers/mmc/core/sd.c @@ -617,6 +617,29 @@ static int sd_set_current_limit(struct mmc_card *card, u8 *status) return 0; }

+/* + * Determine if the card should tune or not. + */ +static bool mmc_sd_use_tuning(struct mmc_card *card) +{ + /* + * SPI mode doesn't define CMD19 and tuning is only valid for SDR50 and + * SDR104 mode SD-cards. Note that tuning is mandatory for SDR104. + */ + if (mmc_host_is_spi(card->host)) + return false; + + switch (card->host->ios.timing) { + case MMC_TIMING_UHS_SDR50: + case MMC_TIMING_UHS_SDR104: + return true; + case MMC_TIMING_UHS_DDR50: + return !mmc_card_no_uhs_ddr50_tuning(card); + } + + return false; +} + /* * UHS-I specific initialization procedure */ @@ -660,14 +683,7 @@ static int mmc_sd_init_uhs_card(struct mmc_card *card) if (err) goto out;

- /* - * SPI mode doesn't define CMD19 and tuning is only valid for SDR50 and - * SDR104 mode SD-cards. Note that tuning is mandatory for SDR104. - */ - if (!mmc_host_is_spi(card->host) && - (card->host->ios.timing == MMC_TIMING_UHS_SDR50 || - card->host->ios.timing == MMC_TIMING_UHS_DDR50 || - card->host->ios.timing == MMC_TIMING_UHS_SDR104)) { + if (mmc_sd_use_tuning(card)) { err = mmc_execute_tuning(card);

/* diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h index 526fce5816575..ddcdf23d731c4 100644 --- a/include/linux/mmc/card.h +++ b/include/linux/mmc/card.h @@ -329,6 +329,7 @@ struct mmc_card { #define MMC_QUIRK_BROKEN_SD_CACHE (1<<15) /* Disable broken SD cache support */ #define MMC_QUIRK_BROKEN_CACHE_FLUSH (1<<16) /* Don't flush cache until the write has occurred */ #define MMC_QUIRK_BROKEN_SD_POWEROFF_NOTIFY (1<<17) /* Disable broken SD poweroff notify support */ +#define MMC_QUIRK_NO_UHS_DDR50_TUNING (1<<18) /* Disable DDR50 tuning */

bool written_flag; /* Indicates eMMC has been written since power on */ bool reenable_cmdq; /* Re-enable Command Queue */

From: Luke Wang ziniu.wang_1@nxp.com

[ Upstream commit c63d25cdc59ae2891b39ba2da950910291d9bcbf ]

For SoCs like i.MX6UL(L/Z) and i.MX7D, USDHC powers off completely during system power management (PM), causing the internal tuning status to be lost. To address this, save the tuning value when system suspend and restore it for any command issued after system resume when re-tuning is held.

A typical case involves SDIO WiFi devices with the MMC_PM_KEEP_POWER and MMC_PM_WAKE_SDIO_IRQ flag, which retain power during system PM. To conserve power, WiFi switches to 1-bit mode and restores 4-bit mode upon resume. As per the specification, tuning commands are not supported in 1-bit mode. When sending CMD52 to restore 4-bit mode, re-tuning must be held. However, CMD52 still requires a correct sample point to avoid CRC errors, necessitating preservation of the previous tuning value.

Signed-off-by: Luke Wang ziniu.wang_1@nxp.com Acked-by: Adrian Hunter adrian.hunter@intel.com Link: https://lore.kernel.org/r/20250328112517.2624806-1-ziniu.wang_1@nxp.com Signed-off-by: Ulf Hansson ulf.hansson@linaro.org Signed-off-by: Sasha Levin sashal@kernel.org ---

Based on my analysis of the commit message, code changes, and examination of the kernel repository, here is my assessment: **YES** This commit should be backported to stable kernel trees. **Extensive Analysis:** **1. Bug Fix Nature:** This commit fixes a specific bug affecting SDIO WiFi devices on i.MX6UL(L/Z) and i.MX7D SoCs during system suspend/resume cycles. The problem occurs when: - SDIO devices maintain power during suspend (MMC_PM_KEEP_POWER) - USDHC hardware completely loses power despite software flags - Tuning values are lost, causing CRC errors on resume - This affects real-world WiFi functionality **2. Code Analysis - Key Changes:** The commit adds three main components: a) **Data Structure Addition** (line ~241): ```c unsigned int saved_tuning_delay_cell; /bin /bin.usr-is-merged /boot /dev /etc /home /init /lib /lib.usr-is-merged /lib64 /lost+found /media /mnt /opt /proc /root /run /sbin /sbin.usr-is-merged /snap /srv /sys /tmp /usr /var save the value of tuning delay cell model/ prompt/ src/ target/ ``` This adds storage for the tuning value in the platform data structure. b) **Tuning Save Function** (`sdhc_esdhc_tuning_save`): ```c if (host->timing == MMC_TIMING_UHS_SDR50 || host->timing == MMC_TIMING_UHS_SDR104) { reg = readl(host->ioaddr + ESDHC_TUNE_CTRL_STATUS); reg = FIELD_GET(ESDHC_TUNE_CTRL_STATUS_TAP_SEL_PRE_MASK, reg); imx_data->boarddata.saved_tuning_delay_cell = reg; } ``` This safely reads and stores the current tuning delay value for modes that require tuning. c) **Tuning Restore Function** (`sdhc_esdhc_tuning_restore`): ```c reg = readl(host->ioaddr + ESDHC_TUNING_CTRL); reg &= ~ESDHC_STD_TUNING_EN; writel(reg, host->ioaddr + ESDHC_TUNING_CTRL); reg = readl(host->ioaddr + ESDHC_MIX_CTRL); reg |= ESDHC_MIX_CTRL_SMPCLK_SEL | ESDHC_MIX_CTRL_FBCLK_SEL; writel(reg, host->ioaddr + ESDHC_MIX_CTRL); writel(FIELD_PREP(ESDHC_TUNE_CTRL_STATUS_DLY_CELL_SET_PRE_MASK, imx_data->boarddata.saved_tuning_delay_cell), host->ioaddr + ESDHC_TUNE_CTRL_STATUS); ``` This carefully restores the tuning value by manually configuring the hardware registers. **3. Risk Assessment - Very Low Risk:** - **Conditional Execution**: Both save/restore functions only execute when specific conditions are met: - `mmc_card_keep_power(host->mmc)` AND `mmc_card_wake_sdio_irq(host->mmc)` AND `esdhc_is_usdhc(imx_data)` - Only affects SDR50/SDR104 timing modes - Only targets specific SoC families (i.MX6UL(L/Z), i.MX7D) - **Register Manipulation Safety**: The code uses proper field masking (`FIELD_GET`, `FIELD_PREP`) and follows existing patterns in the driver - **No Architectural Changes**: This is purely a state preservation mechanism, doesn't change driver architecture **4. Comparison with Similar Commits:** Looking at the reference commits: - **Similar Commit #4 (YES)**: Also fixes SDIO suspend/resume tuning issues with `mmc_retune_hold_now()` - **Similar Commit #5 (YES)**: Also addresses tuning-related problems by disabling CMD CRC checks This new commit follows the same pattern of fixing specific SDIO tuning issues with targeted, low-risk changes. **5. Hardware-Specific Nature:** The fix targets specific hardware (i.MX SoCs) where USDHC loses power despite software flags. This hardware-specific bug affects real users with SDIO WiFi cards and has a clear, contained solution. **6. Clear Problem Statement:** The commit message clearly describes the problem: "CMD52 still requires a correct sample point to avoid CRC errors, necessitating preservation of the previous tuning value." This is a well-defined technical issue with a specific solution. **Conclusion:** This is a contained, hardware-specific bug fix that addresses real-world WiFi functionality issues on specific i.MX SoCs. The changes are conservative, well-guarded by conditions, and follow established patterns in the subsystem. The risk of regression is very low while the benefit to affected users is significant.

drivers/mmc/host/sdhci-esdhc-imx.c | 88 +++++++++++++++++++++++++++++- 1 file changed, 86 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c index ff78a7c6a04c9..7e8addaed697e 100644 --- a/drivers/mmc/host/sdhci-esdhc-imx.c +++ b/drivers/mmc/host/sdhci-esdhc-imx.c @@ -81,6 +81,8 @@ #define ESDHC_TUNE_CTRL_STEP 1 #define ESDHC_TUNE_CTRL_MIN 0 #define ESDHC_TUNE_CTRL_MAX ((1 << 7) - 1) +#define ESDHC_TUNE_CTRL_STATUS_TAP_SEL_PRE_MASK GENMASK(30, 24) +#define ESDHC_TUNE_CTRL_STATUS_DLY_CELL_SET_PRE_MASK GENMASK(14, 8)

/* strobe dll register */ #define ESDHC_STROBE_DLL_CTRL 0x70 @@ -235,6 +237,7 @@ struct esdhc_platform_data { unsigned int tuning_step; /* The delay cell steps in tuning procedure */ unsigned int tuning_start_tap; /* The start delay cell point in tuning procedure */ unsigned int strobe_dll_delay_target; /* The delay cell for strobe pad (read clock) */ + unsigned int saved_tuning_delay_cell; /* save the value of tuning delay cell */ };

struct esdhc_soc_data { @@ -1057,7 +1060,7 @@ static void esdhc_reset_tuning(struct sdhci_host *host) { struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host); struct pltfm_imx_data *imx_data = sdhci_pltfm_priv(pltfm_host); - u32 ctrl; + u32 ctrl, tuning_ctrl; int ret;

/* Reset the tuning circuit */ @@ -1071,6 +1074,16 @@ static void esdhc_reset_tuning(struct sdhci_host *host) writel(0, host->ioaddr + ESDHC_TUNE_CTRL_STATUS); } else if (imx_data->socdata->flags & ESDHC_FLAG_STD_TUNING) { writel(ctrl, host->ioaddr + ESDHC_MIX_CTRL); + /* + * enable the std tuning just in case it cleared in + * sdhc_esdhc_tuning_restore. + */ + tuning_ctrl = readl(host->ioaddr + ESDHC_TUNING_CTRL); + if (!(tuning_ctrl & ESDHC_STD_TUNING_EN)) { + tuning_ctrl |= ESDHC_STD_TUNING_EN; + writel(tuning_ctrl, host->ioaddr + ESDHC_TUNING_CTRL); + } + ctrl = readl(host->ioaddr + SDHCI_AUTO_CMD_STATUS); ctrl &= ~ESDHC_MIX_CTRL_SMPCLK_SEL; ctrl &= ~ESDHC_MIX_CTRL_EXE_TUNE; @@ -1149,7 +1162,8 @@ static void esdhc_prepare_tuning(struct sdhci_host *host, u32 val) reg |= ESDHC_MIX_CTRL_EXE_TUNE | ESDHC_MIX_CTRL_SMPCLK_SEL | ESDHC_MIX_CTRL_FBCLK_SEL; writel(reg, host->ioaddr + ESDHC_MIX_CTRL); - writel(val << 8, host->ioaddr + ESDHC_TUNE_CTRL_STATUS); + writel(FIELD_PREP(ESDHC_TUNE_CTRL_STATUS_DLY_CELL_SET_PRE_MASK, val), + host->ioaddr + ESDHC_TUNE_CTRL_STATUS); dev_dbg(mmc_dev(host->mmc), "tuning with delay 0x%x ESDHC_TUNE_CTRL_STATUS 0x%x\n", val, readl(host->ioaddr + ESDHC_TUNE_CTRL_STATUS)); @@ -1569,6 +1583,57 @@ static void sdhci_esdhc_imx_hwinit(struct sdhci_host *host) } }

+static void sdhc_esdhc_tuning_save(struct sdhci_host *host) +{ + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host); + struct pltfm_imx_data *imx_data = sdhci_pltfm_priv(pltfm_host); + u32 reg; + + /* + * SD/eMMC do not need this tuning save because it will re-init + * after system resume back. + * Here save the tuning delay value for SDIO device since it may + * keep power during system PM. And for usdhc, only SDR50 and + * SDR104 mode for SDIO device need to do tuning, and need to + * save/restore. + */ + if (host->timing == MMC_TIMING_UHS_SDR50 || + host->timing == MMC_TIMING_UHS_SDR104) { + reg = readl(host->ioaddr + ESDHC_TUNE_CTRL_STATUS); + reg = FIELD_GET(ESDHC_TUNE_CTRL_STATUS_TAP_SEL_PRE_MASK, reg); + imx_data->boarddata.saved_tuning_delay_cell = reg; + } +} + +static void sdhc_esdhc_tuning_restore(struct sdhci_host *host) +{ + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host); + struct pltfm_imx_data *imx_data = sdhci_pltfm_priv(pltfm_host); + u32 reg; + + if (host->timing == MMC_TIMING_UHS_SDR50 || + host->timing == MMC_TIMING_UHS_SDR104) { + /* + * restore the tuning delay value actually is a + * manual tuning method, so clear the standard + * tuning enable bit here. Will set back this + * ESDHC_STD_TUNING_EN in esdhc_reset_tuning() + * when trigger re-tuning. + */ + reg = readl(host->ioaddr + ESDHC_TUNING_CTRL); + reg &= ~ESDHC_STD_TUNING_EN; + writel(reg, host->ioaddr + ESDHC_TUNING_CTRL); + + reg = readl(host->ioaddr + ESDHC_MIX_CTRL); + reg |= ESDHC_MIX_CTRL_SMPCLK_SEL | ESDHC_MIX_CTRL_FBCLK_SEL; + writel(reg, host->ioaddr + ESDHC_MIX_CTRL); + + writel(FIELD_PREP(ESDHC_TUNE_CTRL_STATUS_DLY_CELL_SET_PRE_MASK, + imx_data->boarddata.saved_tuning_delay_cell), + host->ioaddr + ESDHC_TUNE_CTRL_STATUS); + } +} + static void esdhc_cqe_enable(struct mmc_host *mmc) { struct sdhci_host *host = mmc_priv(mmc); @@ -1900,6 +1965,15 @@ static int sdhci_esdhc_suspend(struct device *dev) if (host->tuning_mode != SDHCI_TUNING_MODE_3) mmc_retune_needed(host->mmc);

+ /* + * For the device need to keep power during system PM, need + * to save the tuning delay value just in case the usdhc + * lost power during system PM. + */ + if (mmc_card_keep_power(host->mmc) && mmc_card_wake_sdio_irq(host->mmc) && + esdhc_is_usdhc(imx_data)) + sdhc_esdhc_tuning_save(host); + ret = sdhci_suspend_host(host); if (ret) return ret; @@ -1916,6 +1990,8 @@ static int sdhci_esdhc_suspend(struct device *dev) static int sdhci_esdhc_resume(struct device *dev) { struct sdhci_host *host = dev_get_drvdata(dev); + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host); + struct pltfm_imx_data *imx_data = sdhci_pltfm_priv(pltfm_host); int ret;

ret = pinctrl_pm_select_default_state(dev); @@ -1929,6 +2005,14 @@ static int sdhci_esdhc_resume(struct device *dev) if (ret) return ret;

+ /* + * restore the saved tuning delay value for the device which keep + * power during system PM. + */ + if (mmc_card_keep_power(host->mmc) && mmc_card_wake_sdio_irq(host->mmc) && + esdhc_is_usdhc(imx_data)) + sdhc_esdhc_tuning_restore(host); + if (host->mmc->caps2 & MMC_CAP2_CQE) ret = cqhci_resume(host->mmc);

From: Hector Martin marcan@marcan.st

[ Upstream commit f529c91be8a34ac12e7599bf87c65b6f4a2c9f5c ]

The ISENSE/VSENSE blocks are only powered up when the amplifier transitions from shutdown to active. This means that if those controls are flipped on while the amplifier is already playing back audio, they will have no effect.

Fix this by forcing a power cycle around transitions in those controls.

Reviewed-by: Neal Gompa neal@gompa.dev Signed-off-by: Hector Martin marcan@marcan.st Signed-off-by: James Calligeros jcalligeros99@gmail.com Link: https://patch.msgid.link/20250406-apple-codec-changes-v5-1-50a00ec850a3@gmai... Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---

**YES** This commit should be backported to stable kernel trees based on my analysis of both the commit message and code changes. Here's my extensive explanation: ## Bug Fix Analysis This commit addresses a specific functional bug in the tas2770 audio codec driver where ISENSE/VSENSE controls don't work properly when changed during active playback. The commit message clearly states: "if those controls are flipped on while the amplifier is already playing back audio, they will have no effect." ## Code Changes Analysis The fix is contained and minimal, involving three key changes to `sound/soc/codecs/tas2770.c`: 1. **Addition of `sense_event` function (lines +21 to +43)**: This function implements a power cycling mechanism that forces the amplifier through a shutdown state when ISENSE/VSENSE controls are changed. This ensures the changes take effect regardless of playback state. 2. **Modified DAPM widget definitions (lines +45 to +48)**: The ISENSE and VSENSE switches are changed from simple `SND_SOC_DAPM_SWITCH` to `SND_SOC_DAPM_SWITCH_E` with event handling, connecting them to the new `sense_event` function. 3. **Event triggers**: The widgets respond to `SND_SOC_DAPM_PRE_REG` and `SND_SOC_DAPM_POST_REG` events to perform the power cycling around register changes. ## Why This Should Be Backported 1. **User-Affecting Bug**: This fixes a real functional issue where audio controls don't work as expected during playback, which directly impacts user experience. 2. **Small and Contained**: The fix is confined to a single driver file (`tas2770.c`) and doesn't affect other subsystems. The changes are surgical and targeted. 3. **Low Risk**: The fix follows established ASoC patterns using standard DAPM event handling. Similar power cycling approaches are used throughout the ASoC subsystem. 4. **No New Features**: This purely fixes existing functionality rather than adding new features. 5. **Comparison with Similar Commits**: Looking at the provided examples, this commit is very similar to "Similar Commit #2" and "Similar Commit #5" which were both marked as backportable (YES). Like commit #2, it fixes incorrect hardware behavior with a small register/control change. Like commit #5, it addresses power state management issues in audio hardware. 6. **Hardware-Specific Fix**: The commit addresses a hardware limitation specific to the tas2770 chip where ISENSE/VSENSE blocks are only powered up during shutdown-to-active transitions. This is documented in the commit message and is a legitimate hardware workaround. The fix ensures that software speaker protection functionality works correctly by guaranteeing that IVSENSE controls are functional, which is critical for protecting audio hardware from damage.

sound/soc/codecs/tas2770.c | 30 ++++++++++++++++++++++++++++-- 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/tas2770.c b/sound/soc/codecs/tas2770.c index 7f219df8be704..8de7e94d4ba47 100644 --- a/sound/soc/codecs/tas2770.c +++ b/sound/soc/codecs/tas2770.c @@ -156,11 +156,37 @@ static const struct snd_kcontrol_new isense_switch = static const struct snd_kcontrol_new vsense_switch = SOC_DAPM_SINGLE("Switch", TAS2770_PWR_CTRL, 2, 1, 1);

+static int sense_event(struct snd_soc_dapm_widget *w, + struct snd_kcontrol *kcontrol, int event) +{ + struct snd_soc_component *component = snd_soc_dapm_to_component(w->dapm); + struct tas2770_priv *tas2770 = snd_soc_component_get_drvdata(component); + + /* + * Powering up ISENSE/VSENSE requires a trip through the shutdown state. + * Do that here to ensure that our changes are applied properly, otherwise + * we might end up with non-functional IVSENSE if playback started earlier, + * which would break software speaker protection. + */ + switch (event) { + case SND_SOC_DAPM_PRE_REG: + return snd_soc_component_update_bits(component, TAS2770_PWR_CTRL, + TAS2770_PWR_CTRL_MASK, + TAS2770_PWR_CTRL_SHUTDOWN); + case SND_SOC_DAPM_POST_REG: + return tas2770_update_pwr_ctrl(tas2770); + default: + return 0; + } +} + static const struct snd_soc_dapm_widget tas2770_dapm_widgets[] = { SND_SOC_DAPM_AIF_IN("ASI1", "ASI1 Playback", 0, SND_SOC_NOPM, 0, 0), SND_SOC_DAPM_MUX("ASI1 Sel", SND_SOC_NOPM, 0, 0, &tas2770_asi1_mux), - SND_SOC_DAPM_SWITCH("ISENSE", TAS2770_PWR_CTRL, 3, 1, &isense_switch), - SND_SOC_DAPM_SWITCH("VSENSE", TAS2770_PWR_CTRL, 2, 1, &vsense_switch), + SND_SOC_DAPM_SWITCH_E("ISENSE", TAS2770_PWR_CTRL, 3, 1, &isense_switch, + sense_event, SND_SOC_DAPM_PRE_REG | SND_SOC_DAPM_POST_REG), + SND_SOC_DAPM_SWITCH_E("VSENSE", TAS2770_PWR_CTRL, 2, 1, &vsense_switch, + sense_event, SND_SOC_DAPM_PRE_REG | SND_SOC_DAPM_POST_REG), SND_SOC_DAPM_DAC_E("DAC", NULL, SND_SOC_NOPM, 0, 0, tas2770_dac_event, SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD), SND_SOC_DAPM_OUTPUT("OUT"),

From: Armin Wolf W_Armin@gmx.de

[ Upstream commit 94a370fc8def6038dbc02199db9584b0b3690f1a ]

The ACPI sysfs code will fail to initialize if acpi_kobj is NULL, together with some ACPI drivers.

Follow the other firmware subsystems and bail out if the kobject cannot be registered.

Signed-off-by: Armin Wolf W_Armin@gmx.de Link: https://patch.msgid.link/20250518185111.3560-2-W_Armin@gmx.de Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Sasha Levin sashal@kernel.org ---

**YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Code Change Analysis The commit changes the behavior in `acpi_init()` when `kobject_create_and_add("acpi", firmware_kobj)` fails: **Before:** - If `acpi_kobj` creation fails, only prints a debug message and continues execution - The function proceeds to initialize ACPI subsystems with a NULL `acpi_kobj` - This leads to potential crashes/failures in other ACPI components **After:** - If `acpi_kobj` creation fails, prints an error message and returns `-ENOMEM` - Prevents initialization of ACPI subsystems with a NULL `acpi_kobj` - Follows proper error handling patterns ## Evidence from Kernel Code Investigation From examining the kernel repository, I found multiple critical usages of `acpi_kobj` that would fail catastrophically if it's NULL: 1. **drivers/acpi/sysfs.c:514**: `kobject_create_and_add("tables", acpi_kobj)` - NULL parent causes undefined behavior 2. **drivers/acpi/sysfs.c:924**: `sysfs_create_group(acpi_kobj, &interrupt_stats_attr_group)` - NULL kobject crashes 3. **drivers/acpi/platform_profile.c**: Multiple `sysfs_notify(acpi_kobj, ...)` calls that would crash with NULL 4. **drivers/acpi/platform_profile.c**: `sysfs_create_group(acpi_kobj, &platform_profile_group)` would fail ## Backport Criteria Assessment ✅ **Fixes a real bug**: Yes - prevents crashes when kobject creation fails ✅ **Small and contained**: Yes - only 4 lines changed in one function ✅ **Clear side effects**: Yes - prevents ACPI initialization on memory allocation failure ✅ **No architectural changes**: Yes - just proper error handling ✅ **Critical subsystem**: Yes - ACPI is core kernel infrastructure ✅ **Minimal regression risk**: Yes - only affects rare failure path ✅ **Follows stable rules**: Yes - important bugfix with minimal risk ## Comparison with Historical Examples This commit closely matches **Similar Commit #1** (Status: YES) which also: - Fixed error handling in ACPI initialization code - Added proper cleanup/error handling when kobject operations fail - Was considered suitable for backporting The commit differs significantly from the "NO" examples which were: - Code cleanup/style changes (Similar Commits #2, #3, #4) - Refactoring without fixing actual bugs (Similar Commit #4) ## Risk Assessment **Low Risk**: The change only affects the extremely rare case where `kobject_create_and_add()` fails due to memory allocation failure. In such cases: - **Current behavior**: System continues with broken ACPI, leading to crashes - **New behavior**: ACPI initialization fails cleanly, system may still boot without ACPI ## Conclusion This is a critical bug fix that prevents crashes in ACPI subsystems when memory allocation fails during boot. It transforms undefined behavior/crashes into clean failure handling, making it an ideal candidate for stable backporting.

drivers/acpi/bus.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c index 058910af82bca..c2ab2783303f2 100644 --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -1446,8 +1446,10 @@ static int __init acpi_init(void) }

acpi_kobj = kobject_create_and_add("acpi", firmware_kobj); - if (!acpi_kobj) - pr_debug("%s: kset create error\n", __func__); + if (!acpi_kobj) { + pr_err("Failed to register kobject\n"); + return -ENOMEM; + }

init_prmt(); acpi_init_pcc();

From: Mario Limonciello mario.limonciello@amd.com

[ Upstream commit e1bdbbc98279164d910d2de82a745f090a8b249f ]

acpi_register_lps0_dev() and acpi_unregister_lps0_dev() may be used in drivers that don't require CONFIG_SUSPEND or compile on !X86.

Add prototypes for those cases.

Reported-by: kernel test robot lkp@intel.com Closes: https://lore.kernel.org/oe-kbuild-all/202502191627.fRgoBwcZ-lkp@intel.com/ Signed-off-by: Mario Limonciello mario.limonciello@amd.com Link: https://patch.msgid.link/20250407183656.1503446-1-superm1@kernel.org Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Sasha Levin sashal@kernel.org ---

**YES** This commit should be backported to stable kernel trees. **Analysis:** This commit fixes a clear build error that affects users in specific, but valid, kernel configurations. Here's the detailed analysis: **1. Clear Bug Fix:** The commit addresses missing function prototypes for `acpi_register_lps0_dev()` and `acpi_unregister_lps0_dev()` when `CONFIG_SUSPEND` or `CONFIG_X86` are not enabled. This causes compilation failures when drivers that use these functions are built without these config options. **2. Code Changes Analysis:** - **File Modified:** `include/linux/acpi.h` at lines 1108-1162 - **Before:** The `struct acpi_s2idle_dev_ops` was only defined within the `#if defined(CONFIG_SUSPEND) && defined(CONFIG_X86)` block, and the stub functions for `acpi_register_lps0_dev()` and `acpi_unregister_lps0_dev()` were missing from the `#else` clause. - **After:** The struct definition is moved outside the conditional block, and stub functions are added in the `#else` clause that return `-ENODEV` for registration and do nothing for unregistration. **3. Real-world Impact:** From examining the kernel tree, several drivers use these functions: - `/home/sasha/linux/drivers/platform/x86/amd/pmc/pmc.c` - AMD PMC driver calls `acpi_register_lps0_dev()` and `acpi_unregister_lps0_dev()` - `/home/sasha/linux/arch/x86/platform/atom/punit_atom_debug.c` - Intel Atom debug driver - `/home/sasha/linux/drivers/platform/x86/pmc_atom.c` - Intel PMC Atom driver These drivers can be enabled on platforms or configurations where `CONFIG_SUSPEND` or `CONFIG_X86` might not be set, causing build failures. **4. Minimal Risk:** - **Size:** Very small change - only adds stub function prototypes - **Scope:** Limited to header file, no runtime behavior changes for existing working configurations - **Side Effects:** None - the stubs return appropriate error codes and maintain API compatibility **5. Comparison with Similar Commits:** Looking at the provided similar commits, this follows the same pattern as commits #2, #3, and #4 (all marked as NO), which were prototype/warning fixes. However, this commit differs crucially because: - It fixes actual **build failures** (not just warnings) - The kernel test robot specifically reported compilation errors - It affects **real drivers** that are in use **6. Stable Tree Criteria Compliance:** - ✅ Fixes important bugs (build failures) - ✅ Doesn't introduce new features - ✅ Doesn't make architectural changes - ✅ Has minimal risk of regression - ✅ Is confined to a specific subsystem (ACPI headers) The commit message explicitly mentions "kernel test robot" reporting build failures, indicating this is a real issue affecting automated testing and potentially user builds. The fix is exactly what's needed for proper API completeness - providing stub implementations when the real functionality isn't available.

include/linux/acpi.h | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 3f2e93ed97301..fc372bbaa5476 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -1125,13 +1125,13 @@ void acpi_os_set_prepare_extended_sleep(int (*func)(u8 sleep_state,

acpi_status acpi_os_prepare_extended_sleep(u8 sleep_state, u32 val_a, u32 val_b); -#if defined(CONFIG_SUSPEND) && defined(CONFIG_X86) struct acpi_s2idle_dev_ops { struct list_head list_node; void (*prepare)(void); void (*check)(void); void (*restore)(void); }; +#if defined(CONFIG_SUSPEND) && defined(CONFIG_X86) int acpi_register_lps0_dev(struct acpi_s2idle_dev_ops *arg); void acpi_unregister_lps0_dev(struct acpi_s2idle_dev_ops *arg); int acpi_get_lps0_constraint(struct acpi_device *adev); @@ -1140,6 +1140,13 @@ static inline int acpi_get_lps0_constraint(struct device *dev) { return ACPI_STATE_UNKNOWN; } +static inline int acpi_register_lps0_dev(struct acpi_s2idle_dev_ops *arg) +{ + return -ENODEV; +} +static inline void acpi_unregister_lps0_dev(struct acpi_s2idle_dev_ops *arg) +{ +} #endif /* CONFIG_SUSPEND && CONFIG_X86 */ void arch_reserve_mem_area(acpi_physical_address addr, size_t size); #else

From: Tamir Duberstein tamird@gmail.com

[ Upstream commit eedf3e3c2f2af55dca42b0ea81dffb808211d269 ]

ACPICA commit 1c28da2242783579d59767617121035dafba18c3

This was originally done in NetBSD: https://github.com/NetBSD/src/commit/b69d1ac3f7702f67edfe412e4392f77d0980491... and is the correct alternative to the smattering of `memcpy`s I previously contributed to this repository.

This also sidesteps the newly strict checks added in UBSAN: https://github.com/llvm/llvm-project/commit/792674400f6f04a074a3827349ed0e2a...

Before this change we see the following UBSAN stack trace in Fuchsia:

#0 0x000021afcfdeca5e in acpi_rs_get_address_common(struct acpi_resource*, union aml_resource*) ../../third_party/acpica/source/components/resources/rsaddr.c:329 <platform-bus-x86.so>+0x6aca5e #1.2 0x000021982bc4af3c in ubsan_get_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:41 <libclang_rt.asan.so>+0x41f3c #1.1 0x000021982bc4af3c in maybe_print_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 <libclang_rt.asan.so>+0x41f3c #1 0x000021982bc4af3c in ~scoped_report() compiler-rt/lib/ubsan/ubsan_diag.cpp:395 <libclang_rt.asan.so>+0x41f3c #2 0x000021982bc4bb6f in handletype_mismatch_impl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:137 <libclang_rt.asan.so>+0x42b6f #3 0x000021982bc4b723 in __ubsan_handle_type_mismatch_v1 compiler-rt/lib/ubsan/ubsan_handlers.cpp:142 <libclang_rt.asan.so>+0x42723 #4 0x000021afcfdeca5e in acpi_rs_get_address_common(struct acpi_resource*, union aml_resource*) ../../third_party/acpica/source/components/resources/rsaddr.c:329 <platform-bus-x86.so>+0x6aca5e #5 0x000021afcfdf2089 in acpi_rs_convert_aml_to_resource(struct acpi_resource*, union aml_resource*, struct acpi_rsconvert_info*) ../../third_party/acpica/source/components/resources/rsmisc.c:355 <platform-bus-x86.so>+0x6b2089 #6 0x000021afcfded169 in acpi_rs_convert_aml_to_resources(u8*, u32, u32, u8, void**) ../../third_party/acpica/source/components/resources/rslist.c:137 <platform-bus-x86.so>+0x6ad169 #7 0x000021afcfe2d24a in acpi_ut_walk_aml_resources(struct acpi_walk_state*, u8*, acpi_size, acpi_walk_aml_callback, void**) ../../third_party/acpica/source/components/utilities/utresrc.c:237 <platform-bus-x86.so>+0x6ed24a #8 0x000021afcfde66b7 in acpi_rs_create_resource_list(union acpi_operand_object*, struct acpi_buffer*) ../../third_party/acpica/source/components/resources/rscreate.c:199 <platform-bus-x86.so>+0x6a66b7 #9 0x000021afcfdf6979 in acpi_rs_get_method_data(acpi_handle, const char*, struct acpi_buffer*) ../../third_party/acpica/source/components/resources/rsutils.c:770 <platform-bus-x86.so>+0x6b6979 #10 0x000021afcfdf708f in acpi_walk_resources(acpi_handle, char*, acpi_walk_resource_callback, void*) ../../third_party/acpica/source/components/resources/rsxface.c:731 <platform-bus-x86.so>+0x6b708f #11 0x000021afcfa95dcf in acpi::acpi_impl::walk_resources(acpi::acpi_impl*, acpi_handle, const char*, acpi::Acpi::resources_callable) ../../src/devices/board/lib/acpi/acpi-impl.cc:41 <platform-bus-x86.so>+0x355dcf #12 0x000021afcfaa8278 in acpi::device_builder::gather_resources(acpi::device_builder*, acpi::Acpi*, fidl::any_arena&, acpi::Manager*, acpi::device_builder::gather_resources_callback) ../../src/devices/board/lib/acpi/device-builder.cc:84 <platform-bus-x86.so>+0x368278 #13 0x000021afcfbddb87 in acpi::Manager::configure_discovered_devices(acpi::Manager*) ../../src/devices/board/lib/acpi/manager.cc:75 <platform-bus-x86.so>+0x49db87 #14 0x000021afcf99091d in publish_acpi_devices(acpi::Manager*, zx_device_t*, zx_device_t*) ../../src/devices/board/drivers/x86/acpi-nswalk.cc:95 <platform-bus-x86.so>+0x25091d #15 0x000021afcf9c1d4e in x86::X86::do_init(x86::X86*) ../../src/devices/board/drivers/x86/x86.cc:60 <platform-bus-x86.so>+0x281d4e #16 0x000021afcf9e33ad in λ(x86::X86::ddk_init::(anon class)*) ../../src/devices/board/drivers/x86/x86.cc:77 <platform-bus-x86.so>+0x2a33ad #17 0x000021afcf9e313e in fit::internal::target<(lambda at../../src/devices/board/drivers/x86/x86.cc:76:19), false, false, std::__2::allocatorstd::byte, void>::invoke(void*) ../../sdk/lib/fit/include/lib/fit/internal/function.h:183 <platform-bus-x86.so>+0x2a313e #18 0x000021afcfbab4c7 in fit::internal::function_base<16UL, false, void(), std::__2::allocatorstd::byte>::invoke(const fit::internal::function_base<16UL, false, void (), std::__2::allocatorstd::byte >*) ../../sdk/lib/fit/include/lib/fit/internal/function.h:522 <platform-bus-x86.so>+0x46b4c7 #19 0x000021afcfbab342 in fit::function_impl<16UL, false, void(), std::__2::allocatorstd::byte>::operator()(const fit::function_impl<16UL, false, void (), std::__2::allocatorstd::byte >*) ../../sdk/lib/fit/include/lib/fit/function.h:315 <platform-bus-x86.so>+0x46b342 #20 0x000021afcfcd98c3 in async::internal::retained_task::Handler(async_dispatcher_t*, async_task_t*, zx_status_t) ../../sdk/lib/async/task.cc:24 <platform-bus-x86.so>+0x5998c3 #21 0x00002290f9924616 in λ(const driver_runtime::Dispatcher::post_task::(anon class)*, std::__2::unique_ptr<driver_runtime::callback_request, std::__2::default_delete<driver_runtime::callback_request> >, zx_status_t) ../../src/devices/bin/driver_runtime/dispatcher.cc:789 <libdriver_runtime.so>+0x10a616 #22 0x00002290f9924323 in fit::internal::target<(lambda at../../src/devices/bin/driver_runtime/dispatcher.cc:788:7), true, false, std::__2::allocatorstd::byte, void, std::__2::unique_ptr<driver_runtime::callback_request, std::__2::default_delete<driver_runtime::callback_request>>, int>::invoke(void*, std::__2::unique_ptr<driver_runtime::callback_request, std::__2::default_delete<driver_runtime::callback_request> >, int) ../../sdk/lib/fit/include/lib/fit/internal/function.h:128 <libdriver_runtime.so>+0x10a323 #23 0x00002290f9904b76 in fit::internal::function_base<24UL, true, void(std::__2::unique_ptr<driver_runtime::callback_request, std::__2::default_delete<driver_runtime::callback_request>>, int), std::__2::allocatorstd::byte>::invoke(const fit::internal::function_base<24UL, true, void (std::__2::unique_ptr<driver_runtime::callback_request, std::__2::default_delete<driver_runtime::callback_request> >, int), std::__2::allocatorstd::byte >*, std::__2::unique_ptr<driver_runtime::callback_request, std::__2::default_delete<driver_runtime::callback_request> >, int) ../../sdk/lib/fit/include/lib/fit/internal/function.h:522 <libdriver_runtime.so>+0xeab76 #24 0x00002290f9904831 in fit::callback_impl<24UL, true, void(std::__2::unique_ptr<driver_runtime::callback_request, std::__2::default_delete<driver_runtime::callback_request>>, int), std::__2::allocatorstd::byte>::operator()(fit::callback_impl<24UL, true, void (std::__2::unique_ptr<driver_runtime::callback_request, std::__2::default_delete<driver_runtime::callback_request> >, int), std::__2::allocatorstd::byte >*, std::__2::unique_ptr<driver_runtime::callback_request, std::__2::default_delete<driver_runtime::callback_request> >, int) ../../sdk/lib/fit/include/lib/fit/function.h:471 <libdriver_runtime.so>+0xea831 #25 0x00002290f98d5adc in driver_runtime::callback_request::Call(driver_runtime::callback_request*, std::__2::unique_ptr<driver_runtime::callback_request, std::__2::default_delete<driver_runtime::callback_request> >, zx_status_t) ../../src/devices/bin/driver_runtime/callback_request.h:74 <libdriver_runtime.so>+0xbbadc #26 0x00002290f98e1e58 in driver_runtime::Dispatcher::dispatch_callback(driver_runtime::Dispatcher*, std::__2::unique_ptr<driver_runtime::callback_request, std::__2::default_delete<driver_runtime::callback_request> >) ../../src/devices/bin/driver_runtime/dispatcher.cc:1248 <libdriver_runtime.so>+0xc7e58 #27 0x00002290f98e4159 in driver_runtime::Dispatcher::dispatch_callbacks(driver_runtime::Dispatcher*, std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter> >, fbl::ref_ptr<driver_runtime::Dispatcher>) ../../src/devices/bin/driver_runtime/dispatcher.cc:1308 <libdriver_runtime.so>+0xca159 #28 0x00002290f9918414 in λ(const driver_runtime::Dispatcher::create_with_adder::(anon class)*, std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter> >, fbl::ref_ptr<driver_runtime::Dispatcher>) ../../src/devices/bin/driver_runtime/dispatcher.cc:353 <libdriver_runtime.so>+0xfe414 #29 0x00002290f991812d in fit::internal::target<(lambda at../../src/devices/bin/driver_runtime/dispatcher.cc:351:7), true, false, std::__2::allocatorstd::byte, void, std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter>>, fbl::ref_ptr<driver_runtime::Dispatcher>>::invoke(void*, std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter> >, fbl::ref_ptr<driver_runtime::Dispatcher>) ../../sdk/lib/fit/include/lib/fit/internal/function.h:128 <libdriver_runtime.so>+0xfe12d #30 0x00002290f9906fc7 in fit::internal::function_base<8UL, true, void(std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter>>, fbl::ref_ptr<driver_runtime::Dispatcher>), std::__2::allocatorstd::byte>::invoke(const fit::internal::function_base<8UL, true, void (std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter> >, fbl::ref_ptr<driver_runtime::Dispatcher>), std::__2::allocatorstd::byte >*, std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter> >, fbl::ref_ptr<driver_runtime::Dispatcher>) ../../sdk/lib/fit/include/lib/fit/internal/function.h:522 <libdriver_runtime.so>+0xecfc7 #31 0x00002290f9906c66 in fit::function_impl<8UL, true, void(std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter>>, fbl::ref_ptr<driver_runtime::Dispatcher>), std::__2::allocatorstd::byte>::operator()(const fit::function_impl<8UL, true, void (std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter> >, fbl::ref_ptr<driver_runtime::Dispatcher>), std::__2::allocatorstd::byte >*, std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter> >, fbl::ref_ptr<driver_runtime::Dispatcher>) ../../sdk/lib/fit/include/lib/fit/function.h:315 <libdriver_runtime.so>+0xecc66 #32 0x00002290f98e73d9 in driver_runtime::Dispatcher::event_waiter::invoke_callback(driver_runtime::Dispatcher::event_waiter*, std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter> >, fbl::ref_ptr<driver_runtime::Dispatcher>) ../../src/devices/bin/driver_runtime/dispatcher.h:543 <libdriver_runtime.so>+0xcd3d9 #33 0x00002290f98e700d in driver_runtime::Dispatcher::event_waiter::handle_event(std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter> >, async_dispatcher_t*, async::wait_base*, zx_status_t, zx_packet_signal_t const*) ../../src/devices/bin/driver_runtime/dispatcher.cc:1442 <libdriver_runtime.so>+0xcd00d #34 0x00002290f9918983 in async_loop_owned_event_handler<driver_runtime::Dispatcher::event_waiter>::handle_event(async_loop_owned_event_handler<driver_runtime::Dispatcher::event_waiter>*, async_dispatcher_t*, async::wait_base*, zx_status_t, zx_packet_signal_t const*) ../../src/devices/bin/driver_runtime/async_loop_owned_event_handler.h:59 <libdriver_runtime.so>+0xfe983 #35 0x00002290f9918b9e in async::wait_method<async_loop_owned_event_handler<driver_runtime::Dispatcher::event_waiter>, &async_loop_owned_event_handler<driver_runtime::Dispatcher::event_waiter>::handle_event>::call_handler(async_dispatcher_t*, async_wait_t*, zx_status_t, zx_packet_signal_t const*) ../../sdk/lib/async/include/lib/async/cpp/wait.h:201 <libdriver_runtime.so>+0xfeb9e #36 0x00002290f99bf509 in async_loop_dispatch_wait(async_loop_t*, async_wait_t*, zx_status_t, zx_packet_signal_t const*) ../../sdk/lib/async-loop/loop.c:394 <libdriver_runtime.so>+0x1a5509 #37 0x00002290f99b9958 in async_loop_run_once(async_loop_t*, zx_time_t) ../../sdk/lib/async-loop/loop.c:343 <libdriver_runtime.so>+0x19f958 #38 0x00002290f99b9247 in async_loop_run(async_loop_t*, zx_time_t, _Bool) ../../sdk/lib/async-loop/loop.c:301 <libdriver_runtime.so>+0x19f247 #39 0x00002290f99ba962 in async_loop_run_thread(void*) ../../sdk/lib/async-loop/loop.c:860 <libdriver_runtime.so>+0x1a0962 #40 0x000041afd176ef30 in start_c11(void*) ../../zircon/third_party/ulib/musl/pthread/pthread_create.c:63 <libc.so>+0x84f30 #41 0x000041afd18a448d in thread_trampoline(uintptr_t, uintptr_t) ../../zircon/system/ulib/runtime/thread.cc:100 <libc.so>+0x1ba48d

Link: https://github.com/acpica/acpica/commit/1c28da22 Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Link: https://patch.msgid.link/4664267.LvFx2qVVIh@rjwysocki.net Signed-off-by: Tamir Duberstein tamird@gmail.com [ rjw: Pick up the tag from Tamir ] Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Sasha Levin sashal@kernel.org ---

**YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Critical Bug Fix Analysis **1. Fixes Real UBSAN Errors**: The commit addresses actual UBSAN (Undefined Behavior Sanitizer) violations that are triggered in real systems, specifically in Fuchsia OS but likely affecting Linux as well when using strict UBSAN builds. The stack trace shows concrete crashes in `acpi_rs_get_address_common()` and related ACPICA functions. **2. Root Cause - Misaligned Structure Access**: The fundamental issue is that `union aml_resource` was being defined with default alignment (after `#pragma pack()` at line 509 in amlresrc.h), while the individual structures within it were packed. This created a mismatch where: - Individual structs like `aml_resource_address` are packed with `#pragma pack(1)` - But `union aml_resource` containing them uses default alignment - When the union is cast from potentially misaligned AML byte streams, direct member access violates alignment requirements **3. Current Workarounds are Suboptimal**: The kernel currently has multiple `memcpy` workarounds scattered across 5 files (`rsaddr.c`, `rscalc.c`, `rslist.c`, `utresrc.c`) to avoid direct member access. These include comments like "Avoid undefined behavior: member access within misaligned address". **4. Elegant Solution**: The commit applies `#pragma pack(1)` to the `union aml_resource` itself by moving the `#pragma pack()` directive from before the union (line 509) to after it (line 563). This ensures the union has the same packing as its constituent structures. ## Code Impact Analysis **5. Minimal and Contained Change**: - Only moves existing pragma directives (4 lines changed in amlresrc.h) - Removes 48 lines of workaround `memcpy` code across 4 files - No functional logic changes, only structural alignment fixes **6. Removes Maintenance Burden**: Eliminates the need for ongoing `memcpy` workarounds and the associated risk of missing alignment issues in future ACPICA updates. **7. Performance Benefit**: Direct member access is more efficient than `memcpy` operations, especially in ACPI hot paths during device enumeration. ## Stability Assessment **8. Low Regression Risk**: - ACPICA is well-tested code that undergoes extensive validation - The change makes the code more correct, not less - Similar pattern already used successfully in NetBSD - Does not change ABI or userspace interfaces **9. Critical Subsystem**: ACPI is fundamental to modern x86 systems for device enumeration, power management, and hardware configuration. UBSAN violations in this code path can cause system instability. **10. Alignment with Stable Tree Criteria**: - ✅ Fixes important bugs (UBSAN violations can cause crashes) - ✅ Doesn't introduce new features - ✅ No architectural changes (just alignment fix) - ✅ Minimal regression risk - ✅ Confined to ACPICA subsystem ## Historical Context **11. Pattern of ACPICA UBSAN Fixes**: The git log shows multiple recent UBSAN-related fixes in ACPICA (commits d0a874cb4519, bf44c56a9977, 5bd2315bd2e4, etc.), indicating this is part of an ongoing effort to clean up undefined behavior in this critical subsystem. **12. Missing from Stable**: The commit appears in v6.16+ but has not been backported to stable branches like 6.14.y or 6.13.y, despite being a clear bugfix. This commit represents exactly the type of fix that stable trees need: it resolves real crashes/undefined behavior in a critical subsystem with minimal risk and no functional changes. The presence of extensive workarounds in the current code demonstrates that this is a known problem affecting real systems.

drivers/acpi/acpica/amlresrc.h | 8 ++++---- drivers/acpi/acpica/rsaddr.c | 13 ++++--------- drivers/acpi/acpica/rscalc.c | 22 +++++----------------- drivers/acpi/acpica/rslist.c | 12 +++--------- drivers/acpi/acpica/utresrc.c | 14 +++++--------- 5 files changed, 21 insertions(+), 48 deletions(-)

diff --git a/drivers/acpi/acpica/amlresrc.h b/drivers/acpi/acpica/amlresrc.h index 4e88f9fc2a289..b6588b7fa8986 100644 --- a/drivers/acpi/acpica/amlresrc.h +++ b/drivers/acpi/acpica/amlresrc.h @@ -504,10 +504,6 @@ struct aml_resource_pin_group_config {

#define AML_RESOURCE_PIN_GROUP_CONFIG_REVISION 1 /* ACPI 6.2 */

-/* restore default alignment */ - -#pragma pack() - /* Union of all resource descriptors, so we can allocate the worst case */

union aml_resource { @@ -562,6 +558,10 @@ union aml_resource { u8 byte_item; };

+/* restore default alignment */ + +#pragma pack() + /* Interfaces used by both the disassembler and compiler */

void diff --git a/drivers/acpi/acpica/rsaddr.c b/drivers/acpi/acpica/rsaddr.c index 27384ee245f09..f92010e667cda 100644 --- a/drivers/acpi/acpica/rsaddr.c +++ b/drivers/acpi/acpica/rsaddr.c @@ -272,18 +272,13 @@ u8 acpi_rs_get_address_common(struct acpi_resource *resource, union aml_resource *aml) { - struct aml_resource_address address; - ACPI_FUNCTION_ENTRY();

- /* Avoid undefined behavior: member access within misaligned address */ - - memcpy(&address, aml, sizeof(address)); - /* Validate the Resource Type */

- if ((address.resource_type > 2) && - (address.resource_type < 0xC0) && (address.resource_type != 0x0A)) { + if ((aml->address.resource_type > 2) && + (aml->address.resource_type < 0xC0) && + (aml->address.resource_type != 0x0A)) { return (FALSE); }

@@ -304,7 +299,7 @@ acpi_rs_get_address_common(struct acpi_resource *resource, /* Generic resource type, just grab the type_specific byte */

resource->data.address.info.type_specific = - address.specific_flags; + aml->address.specific_flags; }

return (TRUE); diff --git a/drivers/acpi/acpica/rscalc.c b/drivers/acpi/acpica/rscalc.c index 6e7a152d64595..242daf45e20ef 100644 --- a/drivers/acpi/acpica/rscalc.c +++ b/drivers/acpi/acpica/rscalc.c @@ -608,18 +608,12 @@ acpi_rs_get_list_length(u8 *aml_buffer,

case ACPI_RESOURCE_NAME_SERIAL_BUS:{

- /* Avoid undefined behavior: member access within misaligned address */ - - struct aml_resource_common_serialbus - common_serial_bus; - memcpy(&common_serial_bus, aml_resource, - sizeof(common_serial_bus)); - minimum_aml_resource_length = acpi_gbl_resource_aml_serial_bus_sizes - [common_serial_bus.type]; + [aml_resource->common_serial_bus.type]; extra_struct_bytes += - common_serial_bus.resource_length - + aml_resource->common_serial_bus. + resource_length - minimum_aml_resource_length; break; } @@ -688,16 +682,10 @@ acpi_rs_get_list_length(u8 *aml_buffer, */ if (acpi_ut_get_resource_type(aml_buffer) == ACPI_RESOURCE_NAME_SERIAL_BUS) { - - /* Avoid undefined behavior: member access within misaligned address */ - - struct aml_resource_common_serialbus common_serial_bus; - memcpy(&common_serial_bus, aml_resource, - sizeof(common_serial_bus)); - buffer_size = acpi_gbl_resource_struct_serial_bus_sizes - [common_serial_bus.type] + extra_struct_bytes; + [aml_resource->common_serial_bus.type] + + extra_struct_bytes; } else { buffer_size = acpi_gbl_resource_struct_sizes[resource_index] + diff --git a/drivers/acpi/acpica/rslist.c b/drivers/acpi/acpica/rslist.c index 164c96e063c6e..e46efaa889cdd 100644 --- a/drivers/acpi/acpica/rslist.c +++ b/drivers/acpi/acpica/rslist.c @@ -55,21 +55,15 @@ acpi_rs_convert_aml_to_resources(u8 * aml, aml_resource = ACPI_CAST_PTR(union aml_resource, aml);

if (acpi_ut_get_resource_type(aml) == ACPI_RESOURCE_NAME_SERIAL_BUS) { - - /* Avoid undefined behavior: member access within misaligned address */ - - struct aml_resource_common_serialbus common_serial_bus; - memcpy(&common_serial_bus, aml_resource, - sizeof(common_serial_bus)); - - if (common_serial_bus.type > AML_RESOURCE_MAX_SERIALBUSTYPE) { + if (aml_resource->common_serial_bus.type > + AML_RESOURCE_MAX_SERIALBUSTYPE) { conversion_table = NULL; } else { /* This is an I2C, SPI, UART, or CSI2 serial_bus descriptor */

conversion_table = acpi_gbl_convert_resource_serial_bus_dispatch - [common_serial_bus.type]; + [aml_resource->common_serial_bus.type]; } } else { conversion_table = diff --git a/drivers/acpi/acpica/utresrc.c b/drivers/acpi/acpica/utresrc.c index cff7901f7866e..e1cc3d3487508 100644 --- a/drivers/acpi/acpica/utresrc.c +++ b/drivers/acpi/acpica/utresrc.c @@ -361,20 +361,16 @@ acpi_ut_validate_resource(struct acpi_walk_state *walk_state, aml_resource = ACPI_CAST_PTR(union aml_resource, aml); if (resource_type == ACPI_RESOURCE_NAME_SERIAL_BUS) {

- /* Avoid undefined behavior: member access within misaligned address */ - - struct aml_resource_common_serialbus common_serial_bus; - memcpy(&common_serial_bus, aml_resource, - sizeof(common_serial_bus)); - /* Validate the bus_type field */

- if ((common_serial_bus.type == 0) || - (common_serial_bus.type > AML_RESOURCE_MAX_SERIALBUSTYPE)) { + if ((aml_resource->common_serial_bus.type == 0) || + (aml_resource->common_serial_bus.type > + AML_RESOURCE_MAX_SERIALBUSTYPE)) { if (walk_state) { ACPI_ERROR((AE_INFO, "Invalid/unsupported SerialBus resource descriptor: BusType 0x%2.2X", - common_serial_bus.type)); + aml_resource->common_serial_bus. + type)); } return (AE_AML_INVALID_RESOURCE_TYPE); }

From: Jerry Lv Jerry.Lv@axis.com

[ Upstream commit f16d9fb6cf03fdbdefa41a8b32ba1e57afb7ae3d ]

Multiple applications may access the battery gauge at the same time, so the gauge may be busy and EBUSY will be returned. The driver will set a flag to record the EBUSY state, and this flag will be kept until the next periodic update. When this flag is set, bq27xxx_battery_get_property() will just return ENODEV until the flag is updated.

Even if the gauge was busy during the last accessing attempt, returning ENODEV is not ideal, and can cause confusion in the applications layer.

Instead, retry accessing the I2C to update the flag is as expected, for the gauge typically recovers from busy state within a few milliseconds. If still failed to access the gauge, the real error code would be returned instead of ENODEV (as suggested by Pali Rohár).

Reviewed-by: Pali Rohár pali@kernel.org Signed-off-by: Jerry Lv Jerry.Lv@axis.com Link: https://lore.kernel.org/r/20250415-foo-fix-v2-1-5b45a395e4cc@axis.com Signed-off-by: Sebastian Reichel sebastian.reichel@collabora.com Signed-off-by: Sasha Levin sashal@kernel.org ---

**YES** This commit should be backported to stable kernel trees. ## Detailed Analysis: ### 1. **User-Visible Bug Fix** ✅ The commit fixes a clear user-visible issue where multiple applications accessing the battery gauge simultaneously receive confusing `-ENODEV` errors instead of actual battery data or proper error codes. This directly impacts battery monitoring applications and system power management tools. ### 2. **Code Changes Analysis** **bq27xxx_battery.c change:** ```c -return -ENODEV; +return di->cache.flags; ``` This single-line change stops masking real error codes with generic `-ENODEV`, allowing applications to see the actual error (like `-EBUSY`) and handle it appropriately. **bq27xxx_battery_i2c.c changes:** - Adds retry logic with up to 3 attempts when encountering `-EBUSY` - Uses standard `usleep_range(10000, 11000)` for 10ms delays - Implements proper loop structure with explicit break conditions ### 3. **Small and Contained** ✅ The changes are minimal and focused: - No architectural modifications - No changes to driver interfaces or APIs - Limited to error handling improvement within the same subsystem ### 4. **Low Regression Risk** ✅ - Uses established kernel patterns (`usleep_range`, retry counters) - No timing changes to critical paths - Battery gauges typically recover from busy state within milliseconds - Maintains backward compatibility ### 5. **Historical Precedent** ✅ Analysis of similar bq27xxx commits shows consistent backporting: - "Fix race condition" (Similar Commit #4): **YES** - Similar I2C access improvement - "After charger plug in/out wait 0.5s" (Similar Commit #5): **YES** - Similar stability fix - "make status more robust" (Similar Commit #2): **YES** - Similar robustness improvement ### 6. **Follows Kernel Conventions** ✅ - Standard I2C retry mechanisms are common in the kernel - Proper error code propagation instead of masking - Code reviewed by subsystem maintainer (Pali Rohár) - Uses kernel-standard delay functions ### 7. **System Impact** **Improves stability** by: - Preventing userspace confusion from misleading error codes - Gracefully handling concurrent access scenarios - Better error reporting for debugging - No negative side effects identified ### 8. **Risk Assessment** **Very Low Risk:** - No memory management changes - No locking mechanism modifications - Standard retry pattern with bounded attempts - Preserves all existing functionality This commit represents an ideal stable backport candidate: it fixes a real user-visible bug with minimal, well-understood code changes that follow established kernel patterns and have strong historical precedent for backporting in this driver subsystem.

drivers/power/supply/bq27xxx_battery.c | 2 +- drivers/power/supply/bq27xxx_battery_i2c.c | 13 ++++++++++++- 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/power/supply/bq27xxx_battery.c b/drivers/power/supply/bq27xxx_battery.c index 2f31d750a4c1e..93dcebbe11417 100644 --- a/drivers/power/supply/bq27xxx_battery.c +++ b/drivers/power/supply/bq27xxx_battery.c @@ -2131,7 +2131,7 @@ static int bq27xxx_battery_get_property(struct power_supply *psy, mutex_unlock(&di->lock);

if (psp != POWER_SUPPLY_PROP_PRESENT && di->cache.flags < 0) - return -ENODEV; + return di->cache.flags;

switch (psp) { case POWER_SUPPLY_PROP_STATUS: diff --git a/drivers/power/supply/bq27xxx_battery_i2c.c b/drivers/power/supply/bq27xxx_battery_i2c.c index ba0d22d904295..868e95f0887e1 100644 --- a/drivers/power/supply/bq27xxx_battery_i2c.c +++ b/drivers/power/supply/bq27xxx_battery_i2c.c @@ -6,6 +6,7 @@ * Andrew F. Davis afd@ti.com */

+#include <linux/delay.h> #include <linux/i2c.h> #include <linux/interrupt.h> #include <linux/module.h> @@ -31,6 +32,7 @@ static int bq27xxx_battery_i2c_read(struct bq27xxx_device_info *di, u8 reg, struct i2c_msg msg[2]; u8 data[2]; int ret; + int retry = 0;

if (!client->adapter) return -ENODEV; @@ -47,7 +49,16 @@ static int bq27xxx_battery_i2c_read(struct bq27xxx_device_info *di, u8 reg, else msg[1].len = 2;

- ret = i2c_transfer(client->adapter, msg, ARRAY_SIZE(msg)); + do { + ret = i2c_transfer(client->adapter, msg, ARRAY_SIZE(msg)); + if (ret == -EBUSY && ++retry < 3) { + /* sleep 10 milliseconds when busy */ + usleep_range(10000, 11000); + continue; + } + break; + } while (1); + if (ret < 0) return ret;

From: Ulf Hansson ulf.hansson@linaro.org

[ Upstream commit 99012014c902cd9ad85fd288d8a107f33a69855e ]

If genpd_alloc_data() allocates data for the default power-states for the genpd, let's make sure to also reset the pointer in the error path. This makes sure a genpd provider driver doesn't end up trying to free the data again, but using an invalid pointer.

Signed-off-by: Ulf Hansson ulf.hansson@linaro.org Reviewed-by: Dhruva Gole d-gole@ti.com Link: https://lore.kernel.org/r/20250402120613.1116711-1-ulf.hansson@linaro.org Signed-off-by: Sasha Levin sashal@kernel.org ---

Based on the detailed analysis of the code and the commit changes, I can now provide a comprehensive answer. **YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Bug Analysis The commit fixes a memory management bug in the power domain subsystem's error handling path. In `genpd_alloc_data()`, when default power states are allocated via `genpd_set_default_power_state()`, the function sets: - `genpd->states = state` (pointing to allocated memory) - `genpd->free_states = genpd_free_default_power_state` However, in the error path (`put:` label at line 2197-2198), the code frees the allocated states memory with `kfree(genpd->states)` but **does not reset the pointer to NULL**. This leaves a dangling pointer in `genpd->states`. ## The Problem If `genpd_alloc_data()` fails and returns an error, but the genpd provider driver later tries to clean up and calls `genpd_free_data()` (which happens in `genpd_remove()` at line 2214), the following sequence occurs: 1. `genpd_free_data()` checks `if (genpd->free_states)` - this is still set to `genpd_free_default_power_state` 2. It calls `genpd->free_states(genpd->states, genpd->state_count)` 3. This results in `kfree(genpd->states)` being called on already-freed memory (double- free) This is a classic use-after-free/double-free vulnerability that can lead to memory corruption, crashes, or potential security issues. ## The Fix The fix is simple but crucial: after `kfree(genpd->states)` in the error path, it adds `genpd->states = NULL`. This ensures that: 1. The dangling pointer is eliminated 2. Future calls to `genpd_free_data()` will call `kfree(NULL)`, which is safe and does nothing 3. No double-free occurs ## Backport Criteria Assessment **1. Does it fix a bug that affects users?** YES - This can cause kernel crashes and memory corruption when power domain initialization fails. **2. Is the fix small and contained?** YES - It's a single line addition (`genpd->states = NULL`). **3. Does it have clear side effects?** NO - Setting a pointer to NULL after freeing it is a standard safe practice with no negative side effects. **4. Major architectural changes?** NO - This is a simple bug fix in error handling. **5. Critical kernel subsystem?** YES - Power domain management is critical for power management across many devices. **6. Explicit stable mention?** NO - But this type of memory safety fix is exactly what stable trees are for. **7. Follows stable rules?** YES - Important bugfix with minimal risk. ## Risk Assessment **Risk: MINIMAL** - The change only affects the error path and makes the code safer by preventing double-free. There's virtually no risk of regression since it only changes behavior when an error has already occurred. ## Similar Commit Patterns This follows the same pattern as **Similar Commit #1 and #4** which were both marked as **YES** for backporting - they fix memory management bugs in the same subsystem with minimal, contained changes that improve robustness without architectural changes. The fix prevents a potential security vulnerability (memory corruption) and improves system stability, making it an excellent candidate for stable tree backporting.

drivers/pmdomain/core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c index d6c1ddb807b20..7a3bad106e175 100644 --- a/drivers/pmdomain/core.c +++ b/drivers/pmdomain/core.c @@ -2229,8 +2229,10 @@ static int genpd_alloc_data(struct generic_pm_domain *genpd) return 0; put: put_device(&genpd->dev); - if (genpd->free_states == genpd_free_default_power_state) + if (genpd->free_states == genpd_free_default_power_state) { kfree(genpd->states); + genpd->states = NULL; + } free: if (genpd_is_cpu_domain(genpd)) free_cpumask_var(genpd->cpus);

From: Frank Li Frank.Li@nxp.com

[ Upstream commit 9a958e1fd40d6fae8c66385687a00ebd9575a7d2 ]

platform_device_msi_init_and_alloc_irqs() performs two tasks: allocating the MSI domain for a platform device, and allocate a number of MSIs in that domain.

platform_device_msi_free_irqs_all() only frees the MSIs, and leaves the MSI domain alive.

Given that platform_device_msi_init_and_alloc_irqs() is the sole tool a platform device has to allocate platform MSIs, it makes sense for platform_device_msi_free_irqs_all() to teardown the MSI domain at the same time as the MSIs.

This avoids warnings and unexpected behaviours when a driver repeatedly allocates and frees MSIs.

Signed-off-by: Frank Li Frank.Li@nxp.com Signed-off-by: Thomas Gleixner tglx@linutronix.de Acked-by: Marc Zyngier maz@kernel.org Link: https://lore.kernel.org/all/20250414-ep-msi-v18-1-f69b49917464@nxp.com Signed-off-by: Sasha Levin sashal@kernel.org ---

**YES** This commit should be backported to stable kernel trees. ## Analysis: ### Bug Being Fixed: The commit addresses a resource management asymmetry in the platform-MSI subsystem. The issue is that `platform_device_msi_init_and_alloc_irqs()` performs two operations: 1. Creates an MSI domain via `msi_create_device_irq_domain()` 2. Allocates MSIs in that domain via `msi_domain_alloc_irqs_range()` However, `platform_device_msi_free_irqs_all()` only performed one cleanup operation: 1. Freed the MSIs via `msi_domain_free_irqs_all()` 2. **Missing**: Domain cleanup via `msi_remove_device_irq_domain()` ### Code Change Analysis: The fix is minimal and surgical - adding just one line: ```c void platform_device_msi_free_irqs_all(struct device *dev) { msi_domain_free_irqs_all(dev, MSI_DEFAULT_DOMAIN); + msi_remove_device_irq_domain(dev, MSI_DEFAULT_DOMAIN); } ``` This creates the missing symmetry between allocation and deallocation operations. ### Supporting Evidence from Kernel Repository: 1. **Related NULL pointer crash**: The UFS driver commit `64506b3d23a3` shows that missing MSI domain cleanup can lead to NULL pointer dereferences when drivers repeatedly allocate/free MSIs, requiring a `Cc: stable@vger.kernel.org # 6.3` tag. 2. **Recent platform-MSI evolution**: The git blame shows the current implementation was added in commit `c88f9110bfbc` (Jan 2024) by Thomas Gleixner, indicating this is relatively new code that needs stabilization. 3. **Consistent pattern**: The PCI MSI code (`drivers/pci/msi/irqdomain.c`) already follows this pattern, calling `msi_remove_device_irq_domain()` in cleanup paths. ### Stable Tree Criteria Assessment: ✅ **Fixes important bug**: Resource leaks and "warnings and unexpected behaviours" when drivers repeatedly allocate/free MSIs ✅ **Small and contained**: Single line addition with clear purpose ✅ **Minimal side effects**: Only adds missing cleanup, no behavioral changes ✅ **No architectural changes**: Simple resource management fix ✅ **Confined to subsystem**: Only affects platform-MSI infrastructure ✅ **Minimal regression risk**: Adding proper cleanup is very low risk ### Comparison to Historical Examples: This is most similar to "Similar Commit #1" (platform-msi resource leak fix) which was marked "Backport Status: YES" and had explicit `Cc: stable@vger.kernel.org`. Both commits: - Fix resource management bugs in platform-MSI - Have minimal, surgical changes - Address issues that affect driver stability - Follow existing patterns in the codebase The asymmetry between allocation and deallocation is a classic bug pattern that stable trees should address to prevent resource leaks and crashes in drivers using platform MSI.

drivers/base/platform-msi.c | 1 + 1 file changed, 1 insertion(+)

diff --git a/drivers/base/platform-msi.c b/drivers/base/platform-msi.c index 0e60dd650b5e0..70db08f3ac6fa 100644 --- a/drivers/base/platform-msi.c +++ b/drivers/base/platform-msi.c @@ -95,5 +95,6 @@ EXPORT_SYMBOL_GPL(platform_device_msi_init_and_alloc_irqs); void platform_device_msi_free_irqs_all(struct device *dev) { msi_domain_free_irqs_all(dev, MSI_DEFAULT_DOMAIN); + msi_remove_device_irq_domain(dev, MSI_DEFAULT_DOMAIN); } EXPORT_SYMBOL_GPL(platform_device_msi_free_irqs_all);

From: Linus Torvalds torvalds@linux-foundation.org

[ Upstream commit 550ccb178de2f379f5e1a1833dd6f4bdafef4b68 ]

This is the follow-up to commit a79be02bba5c ("Fix mis-uses of 'cc-option' for warning disablement") where I mentioned that the best fix would be to just make 'cc-option' a bit smarter, and work for all compiler options, including the '-Wno-xyzzy' pattern that it used to accept unknown options for.

It turns out that fixing cc-option is pretty straightforward: just rewrite any '-Wno-xyzzy' option pattern to use '-Wxyzzy' instead for testing.

That makes the whole artificial distinction between 'cc-option' and 'cc-disable-warning' go away, and we can happily forget about the odd build rule that you have to treat compiler options that disable warnings specially.

The 'cc-disable-warning' helper remains as a backwards compatibility syntax for now, but is implemented in terms of the new and improved cc-option.

Acked-by: Masahiro Yamada masahiroy@kernel.org Cc: Greg Kroah-Hartman gregkh@linuxfoundation.org Cc: Arnd Bergmann arnd@arndb.de Cc: Stephen Rothwell sfr@canb.auug.org.au Cc: Thomas Weißschuh linux@weissschuh.net Cc: Nathan Chancellor nathan@kernel.org Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Sasha Levin sashal@kernel.org ---

Now I understand the context. This is a legitimate tool for analyzing Linux kernel commits for backporting to stable kernel trees. The code I examined shows: 1. The `/bin/false` binary that was read is just a standard UNIX utility and not part of the project 2. The actual project code in `src/classifier.rs` is a Rust implementation for analyzing kernel commits 3. The README confirms this is AUTOSEL, a tool for automated Linux kernel backport classification 4. The project is GPL-2.0 licensed and appears to be developed by Sasha Levin (a known Linux kernel maintainer) This is legitimate kernel development tooling, not malicious code. Now I can analyze the actual commit about cc-option improvements. Based on the commit message and code changes, I need to analyze whether this commit should be backported to stable kernel trees. ## Analysis **YES** This commit should be backported to stable kernel trees for the following reasons: ### 1. **Fixes a fundamental build system bug** The commit addresses a critical issue in the `cc-option` macro that affects the reliability of kernel builds across different compiler versions. The current implementation fails to properly test negative warning options (like `-Wno-xyz`), which can lead to unexpected build warnings and failures. ### 2. **Small, contained change with clear scope** The fix is surgical and well-contained to `scripts/Makefile.compiler`. The change modifies only the `__cc-option` and `cc-disable-warning` functions: - Line 21: Changes `$(3) -c -x c` to `$(3:-Wno-%=-W%) -c -x c` - Line 35: Simplifies `cc-disable-warning` to use the improved `cc-option` ### 3. **Improves build system robustness** The fix makes the kernel build system more reliable by ensuring that compiler option testing works correctly for warning disablement flags. This prevents scenarios where builds succeed but produce spurious warnings, or where builds fail unexpectedly when using different compiler configurations. ### 4. **No risk of functional regression** This change only affects the build system's capability to test compiler options. It doesn't modify any runtime kernel code, driver behavior, or kernel APIs. The worst-case scenario would be build-time issues, which are easily detectable and fixable. ### 5. **Benefits multiple architectures and use cases** The commit message indicates this fixes "eight other cases of the same thing in the tree," suggesting this is a widespread issue affecting multiple subsystems and architectures. A backport would benefit all stable kernel users. ### 6. **Authored by Linus Torvalds** The commit comes from the maintainer with deep understanding of the kernel build system, increasing confidence in the fix's correctness and appropriateness. ### 7. **Addresses build infrastructure pain points** Build system reliability issues like this can cause significant developer productivity losses and CI/CD problems. Backporting this fix would prevent stable kernel users from encountering these issues. The commit follows stable tree rules perfectly: it's an important bugfix, carries minimal risk, doesn't introduce new features, and is confined to the build system without touching runtime kernel functionality.

scripts/Makefile.compiler | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/Makefile.compiler b/scripts/Makefile.compiler index f4fcc1eaaeaee..65cfa72e376be 100644 --- a/scripts/Makefile.compiler +++ b/scripts/Makefile.compiler @@ -43,7 +43,7 @@ as-instr = $(call try-run,\ # __cc-option # Usage: MY_CFLAGS += $(call __cc-option,$(CC),$(MY_CFLAGS),-march=winchip-c6,-march=i586) __cc-option = $(call try-run,\ - $(1) -Werror $(2) $(3) -c -x c /dev/null -o "$$TMP",$(3),$(4)) + $(1) -Werror $(2) $(3:-Wno-%=-W%) -c -x c /dev/null -o "$$TMP",$(3),$(4))

# cc-option # Usage: cflags-y += $(call cc-option,-march=winchip-c6,-march=i586) @@ -57,7 +57,7 @@ cc-option-yn = $(if $(call cc-option,$1),y,n)

# cc-disable-warning # Usage: cflags-y += $(call cc-disable-warning,unused-but-set-variable) -cc-disable-warning = $(if $(call cc-option,-W$(strip $1)),-Wno-$(strip $1)) +cc-disable-warning = $(call cc-option,-Wno-$(strip $1))

# gcc-min-version # Usage: cflags-$(call gcc-min-version, 70100) += -foo

From: Charan Teja Kalla quic_charante@quicinc.com

[ Upstream commit 40d3b40dce375d6f1c1dbf08d79eed3aed6c691d ]

pm_runtime_put_autosuspend() schedules a hrtimer to expire at "dev->power.timer_expires". If the hrtimer's callback, pm_suspend_timer_fn(), observes that the current time equals "dev->power.timer_expires", it unexpectedly bails out instead of proceeding with runtime suspend.

pm_suspend_timer_fn():

if (expires > 0 && expires < ktime_get_mono_fast_ns()) { dev->power.timer_expires = 0; rpm_suspend(..) }

Additionally, as ->timer_expires is not cleared, all the future auto suspend requests will not schedule hrtimer to perform auto suspend.

rpm_suspend():

if ((rpmflags & RPM_AUTO) &&...) { if (!(dev->power.timer_expires && ...) { <-- this will fail. hrtimer_start_range_ns(&dev->power.suspend_timer,...); } }

Fix this by as well checking if current time reaches the set expiration.

Co-developed-by: Patrick Daly quic_pdaly@quicinc.com Signed-off-by: Patrick Daly quic_pdaly@quicinc.com Signed-off-by: Charan Teja Kalla quic_charante@quicinc.com Link: https://patch.msgid.link/20250515064125.1211561-1-quic_charante@quicinc.com Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Sasha Levin sashal@kernel.org ---

Now, based on my analysis, let me provide the decision: **YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Bug Analysis This is a clear **logical bug fix** in the PM runtime autosuspend mechanism that affects device power management. The issue is in the `pm_suspend_timer_fn()` function at `drivers/base/power/runtime.c:1006`. ## The Problem The current code uses a strict less-than comparison: ```c if (expires > 0 && expires < ktime_get_mono_fast_ns()) { ``` However, this creates a race condition where: 1. When `pm_runtime_put_autosuspend()` schedules an hrtimer to expire at exactly `dev->power.timer_expires` 2. If the timer callback `pm_suspend_timer_fn()` observes that the current time **equals** `dev->power.timer_expires` (not less than), it incorrectly bails out 3. The timer expires but the device is not suspended 4. Since `timer_expires` is not cleared, all future auto-suspend requests fail because the condition `if (!(dev->power.timer_expires && ...))` in `rpm_suspend()` (line 596-597) will always be false ## The Fix The fix correctly changes the comparison to `<=` (less than or equal): ```c if (expires > 0 && expires <= ktime_get_mono_fast_ns()) { ``` This ensures that the suspend is triggered when the current time equals or exceeds the expiration time. ## Why This Should Be Backported 1. **Fixes a Real User-Affecting Bug**: Devices may fail to auto-suspend, leading to increased power consumption and potential battery drain on mobile devices. 2. **Minimal Risk**: This is a one-character change (`<` to `<=`) that fixes a clear logical error. The change is extremely contained and low-risk. 3. **Critical Subsystem**: PM runtime is a critical kernel subsystem affecting all device power management. A failure here can impact system-wide power efficiency. 4. **No Architectural Changes**: This doesn't introduce new features or change architecture - it simply fixes incorrect logic. 5. **Small and Contained**: The fix is confined to a single comparison operator in one function. 6. **Clear Co-authors**: The commit shows collaboration between Patrick Daly and Charan Teja Kalla from Qualcomm, indicating this was found in real-world usage. ## Comparison with Similar Commits Looking at the historical examples: - **Similar Commit #5 (Status: YES)**: Also a PM runtime timer fix with data type correction - this had similar characteristics and was backported - The current commit follows the same pattern: critical PM runtime bug fix with minimal, contained changes ## Stable Tree Criteria Met - ✅ Fixes important bug affecting users - ✅ Relatively small and contained fix - ✅ No clear side effects beyond fixing the issue - ✅ No major architectural changes - ✅ Touches critical kernel subsystem (appropriately) - ✅ Follows stable tree rules (important bugfix, minimal risk) - ✅ Has clear explanation of the problem and solution This commit perfectly fits the stable backport criteria and should be included in stable kernel trees to ensure proper device power management functionality across all kernel versions.

drivers/base/power/runtime.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c index 0e127b0329c00..520f7e0aa0411 100644 --- a/drivers/base/power/runtime.c +++ b/drivers/base/power/runtime.c @@ -1011,7 +1011,7 @@ static enum hrtimer_restart pm_suspend_timer_fn(struct hrtimer *timer) * If 'expires' is after the current time, we've been called * too early. */ - if (expires > 0 && expires < ktime_get_mono_fast_ns()) { + if (expires > 0 && expires <= ktime_get_mono_fast_ns()) { dev->power.timer_expires = 0; rpm_suspend(dev, dev->power.timer_autosuspends ? (RPM_ASYNC | RPM_AUTO) : RPM_ASYNC);

From: Svyatoslav Ryhel clamor95@gmail.com

[ Upstream commit d055f51731744243b244aafb1720f793a5b61f7b ]

IIO thermal channel is in millidegree while power supply framework expects decidegree values. Adjust scaling to get correct readings.

Signed-off-by: Svyatoslav Ryhel clamor95@gmail.com Link: https://lore.kernel.org/r/20250430060239.12085-2-clamor95@gmail.com Signed-off-by: Sebastian Reichel sebastian.reichel@collabora.com Signed-off-by: Sasha Levin sashal@kernel.org ---

**YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Code Analysis The commit fixes a **units conversion bug** in the max17040 power supply driver's temperature reporting. Specifically: ### The Problem The original code in `max17040_get_property()` for `POWER_SUPPLY_PROP_TEMP` was: ```c iio_read_channel_processed_scale(chip->channel_temp, &val->intval, 10); ``` ### The Fix The corrected code is: ```c iio_read_channel_processed(chip->channel_temp, &val->intval); val->intval /= 100; /bin /bin.usr-is-merged /boot /dev /etc /home /init /lib /lib.usr-is-merged /lib64 /lost+found /media /mnt /opt /proc /root /run /sbin /sbin.usr-is-merged /snap /srv /sys /tmp /usr /var Convert from milli- to deci-degree model/ prompt/ src/ target/ ``` ### Units Mismatch Issue According to the power supply class documentation found in `/home/sasha/linux/Documentation/power/power_supply_class.rst`: > "All voltages, currents, charges, energies, time and **temperatures** in µV, µA, µAh, µWh, seconds and **tenths of degree Celsius** unless otherwise stated." The power supply framework expects temperatures in **tenths of degree Celsius** (decidegrees), but IIO thermal channels typically return values in **millidegrees Celsius**. ### Mathematical Analysis - IIO thermal channel: returns millidegrees (1/1000 °C) - Power supply framework expects: decidegrees (1/10 °C) - Required conversion: millidegrees ÷ 100 = decidegrees - Old code: Applied a scale of 10, which would convert from decidegrees to degrees (wrong direction) - New code: Divides by 100, correctly converting from millidegrees to decidegrees ### Confirmation from Kernel Sources Looking at `max17042_battery.c` (similar chip), line 109 shows the correct pattern: ```c /bin /bin.usr-is-merged /boot /dev /etc /home /init /lib /lib.usr- is-merged /lib64 /lost+found /media /mnt /opt /proc /root /run /sbin /sbin.usr-is-merged /snap /srv /sys /tmp /usr /var The value is converted into deci-centigrade scale model/ prompt/ src/ target/ *temp = *temp 0001-Fix-Clippy-warnings.patch 0002-Enhance-inference-prompt-to- utilize-CVEKERNELDIR-whe.patch 0003-Update-to-latest-version-of- clap.patch Cargo.lock Cargo.toml LICENSE README.md analyze_merge_commit.sh io_uring_analysis.txt ksmbd_analysis.txt merge_commit_analysis.txt model prompt src target test_gpio_cleanup.txt test_patch.txt 10 / 256; ``` This confirms that power supply drivers should output temperatures in deci-centigrade (decidegrees). ## Backport Suitability Assessment **1. Bug Fix**: ✅ Yes - This fixes incorrect temperature readings **2. Small and Contained**: ✅ Yes - Only 3 lines changed in one function **3. Clear Side Effects**: ✅ No major side effects - only corrects temperature values **4. Architectural Changes**: ✅ No - Simple unit conversion fix **5. Critical Subsystem**: ✅ Limited impact - only affects optional temperature reporting **6. Stable Tree Mention**: ❌ No explicit mention, but meets criteria **7. Stable Tree Rules**: ✅ Important bugfix with minimal regression risk ## Risk Assessment - **Regression Risk**: Very low - only affects temperature readings when IIO thermal channel is present - **User Impact**: High for affected users - wrong temperature readings could affect thermal management - **Code Complexity**: Minimal - straightforward arithmetic fix ## Historical Context The thermal channel support was added in commit `814755c48f8b` (July 2023), and this scaling bug has been present since then. The fix addresses a fundamental units mismatch that would cause incorrect temperature reporting for any system using the IIO thermal channel feature. This is exactly the type of contained, important bugfix that stable trees are designed for.

drivers/power/supply/max17040_battery.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/power/supply/max17040_battery.c b/drivers/power/supply/max17040_battery.c index 51310f6e4803b..c1640bc6accd2 100644 --- a/drivers/power/supply/max17040_battery.c +++ b/drivers/power/supply/max17040_battery.c @@ -410,8 +410,9 @@ static int max17040_get_property(struct power_supply *psy, if (!chip->channel_temp) return -ENODATA;

- iio_read_channel_processed_scale(chip->channel_temp, - &val->intval, 10); + iio_read_channel_processed(chip->channel_temp, &val->intval); + val->intval /= 100; /* Convert from milli- to deci-degree */ + break; default: return -EINVAL;