[PATCH AUTOSEL 6.17-5.10] platform/x86: huawei-wmi: add keys for HONOR models

[PATCH AUTOSEL 6.17-5.10] platform/x86: huawei-wmi: add keys for HONOR models

[Sasha Levin]

From: Jia Ston <ston.jia@outlook.com>

[ Upstream commit 5c72329716d0858621021193330594d5d26bf44d ]

HONOR MagicBook X16/X14 models produced in 2025 cannot use the Print
Screen and YOYO keys properly, with the system reporting them as
unknown key presses (codes: 0x028b and 0x028e).

To resolve this, a key_entry is added for both the HONOR Print Screen
key and the HONOR YOYO key, ensuring they function correctly on these
models.

Signed-off-by: Ston Jia <ston.jia@outlook.com>
Link: https://patch.msgid.link/20251029051804.220111-1-ston.jia@outlook.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

### Comprehensive Analysis

1. **Commit Message and Issue Analysis**
  The commit addresses a functional hardware defect on HONOR MagicBook
  X16/X14 laptops (2025 models). The "Print Screen" and "YOYO" keys do
  not generate input events, instead triggering "Unknown key pressed"
  warning logs with scancodes `0x028b` and `0x028e`. This means users
  cannot use these hardware features, which constitutes a real-world bug
  for owners of these devices.

2. **Code Review and Mechanism**
  The fix is a surgical addition to the `huawei_wmi_keymap` array in
  `drivers/platform/x86/huawei-wmi.c`.
    - **Mechanism:** The driver uses `sparse_keymap_entry_from_scancode`
      to translate WMI events into input events. Without these entries,
      the lookup fails, and the driver drops the event.
    - **Change:** Two lines are added:
      ```c
      { KE_KEY,    0x28b, { KEY_NOTIFICATION_CENTER } },
      { KE_KEY,    0x28e, { KEY_PRINT } },
      ```
    - **Dependencies:** `KEY_NOTIFICATION_CENTER` was introduced in
      Linux 5.10. This patch is suitable for stable trees 5.10, 5.15,
      6.1, and 6.6 without modification. Older LTS versions (4.19, 5.4)
      would require a minor adjustment (using a different keycode or
      backporting the definition), but the patch remains conceptually
      valid for them.

3. **Stable Kernel Rules Assessment**
    - **Exception Category:** This commit falls squarely under the
      **"QUIRKS and WORKAROUNDS"** and **"TRIVIAL SUBSYSTEM-SPECIFIC
      ADDITIONS"** exceptions defined in stable kernel rules. Adding
      keymap entries is functionally identical to adding PCI/USB IDs: it
      enables hardware that is currently present but non-functional.
    - **Feature vs. Fix:** While the commit says "add keys," it is
      fixing broken hardware support. The keys physically exist but do
      not work; enabling them is a fix, not a new software feature.
    - **New Hardware on Stable:** While the hardware is from 2025, it is
      common for users to run Long Term Support (LTS) kernels (e.g.,
      Ubuntu LTS, RHEL, or community LTS kernels like 6.6.y) on new
      hardware. Refusing to backport hardware enablement forces these
      users to run bleeding-edge kernels or suffer broken functionality.

4. **Risk vs. Benefit**
    - **Regression Risk:** **Negligible.** The change adds data to a
      static array. It only affects the handling of two specific
      scancodes (`0x28b`, `0x28e`) which previously resulted in an error
      log. It cannot affect existing key mappings or other hardware.
    - **Benefit:** Restores functionality for the "Print Screen" key
      (essential for workflows) and the specific "YOYO" key on supported
      laptops.

5. **Conclusion**
  Although the commit lacks a "Cc: stable" tag, it meets all objective
  criteria for a stable backport. It is an obviously correct, low-risk,
  hardware-enabling fix that fits the "Quirks" exception. It should be
  included to ensure this hardware works correctly on supported LTS
  releases.

### TODO Items
- No further investigation required.

**YES**

 drivers/platform/x86/huawei-wmi.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/platform/x86/huawei-wmi.c b/drivers/platform/x86/huawei-wmi.c
index c3772df34679f..8a4c54089ace3 100644
--- a/drivers/platform/x86/huawei-wmi.c
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -81,6 +81,10 @@ static const struct key_entry huawei_wmi_keymap[] = {
 	{ KE_KEY,    0x289, { KEY_WLAN } },
 	// Huawei |M| key
 	{ KE_KEY,    0x28a, { KEY_CONFIG } },
+	// HONOR YOYO key
+	{ KE_KEY,    0x28b, { KEY_NOTIFICATION_CENTER } },
+	// HONOR print screen
+	{ KE_KEY,    0x28e, { KEY_PRINT } },
 	// Keyboard backlit
 	{ KE_IGNORE, 0x293, { KEY_KBDILLUMTOGGLE } },
 	{ KE_IGNORE, 0x294, { KEY_KBDILLUMUP } },
-- 
2.51.0

[PATCH AUTOSEL 6.17] platform/x86: intel-uncore-freq: Add additional client processors

[Sasha Levin]

From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>

[ Upstream commit a229809c18926e79aeca232d5b502157beb0dec3 ]

Add Intel uncore frequency driver support for Pantherlake, Wildcatlake
and Novalake processors.

Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Link: https://patch.msgid.link/20251022211733.3565526-1-sathyanarayanan.kuppuswamy@linux.intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

### 1. COMPREHENSIVE ANALYSIS

- **Commit Message Analysis:**
    - **Subject:** "platform/x86: intel-uncore-freq: Add additional
      client processors"
    - **Intent:** The commit explicitly adds support for Intel
      Pantherlake, Wildcatlake, and Novalake processors to the uncore
      frequency driver.
    - **Tags:** No "Fixes:" or "Cc: stable" tags are present. This is
      common for device ID additions, which are often picked up by
      stable maintainers automatically or upon request.

- **Code Inspection:**
    - **File:** `drivers/platform/x86/intel/uncore-frequency/uncore-
      frequency.c`
    - **Change:** Adds 4 entries to the `intel_uncore_cpu_ids[]` array
      using the `X86_MATCH_VFM` macro.
    - **Mechanism:** The driver uses this table to decide whether to
      load. Currently, on these new processors, the driver returns
      `-ENODEV`. This patch allows the driver to initialize
      successfully.
    - **Complexity:** Trivial. It is a data-only change with no logic
      modification.

- **Stable Rules & Exceptions:**
    - **General Rule:** "No new features."
    - **Exception:** "NEW DEVICE IDs (Very Common)". The rules
      explicitly allow adding IDs (PCI, USB, ACPI, etc.) to existing
      drivers to enable hardware support. In the context of x86 platform
      drivers, CPU Vendor-Family-Model (VFM) IDs serve the exact same
      purpose as PCI device IDs.
    - **Applicability:** This commit fits squarely within the Device ID
      exception. It enables an existing driver on new hardware variants
      without changing the driver's core behavior.

- **Risk Assessment:**
    - **Regression Risk:** Negligible. The change is confined to the
      device match table. It does not alter the code path for currently
      supported processors.
    - **Consequence of Failure:** If the IDs are incorrect, the driver
      simply fails to load on the new hardware, preserving the status
      quo.
    - **Dependencies:** The patch uses `X86_MATCH_VFM` and constants
      like `INTEL_NOVALAKE`.
        - *Critical Technical Note:* The `X86_MATCH_VFM` infrastructure
          was introduced to support CPU families beyond Family 6 (Nova
          Lake is Family 18). Target stable trees must have this
          infrastructure and the corresponding
          `arch/x86/include/asm/intel-family.h` definitions. For very
          old stable trees (pre-VFM infrastructure), backporting would
          be complex; for modern stable trees (like 6.6.y or the
          hypothetical 6.17.y), this is straightforward.

### 2. DETAILED EXPLANATION

This commit is a strong candidate for backporting based on the "New
Device IDs" exception in the stable kernel rules.

**Problem Solved:**
Users running stable kernels on newer Intel hardware (Pantherlake,
Wildcatlake, Novalake) currently have no access to uncore frequency
controls because the driver does not recognize their CPUs. This limits
power management and performance tuning capabilities that are standard
on older platforms.

**Stable Kernel Rules Compliance:**
1. **Exception Category:** This falls under **Exception 1: NEW DEVICE
   IDs**. While technically a "feature" (enablement), the stable rules
   explicitly permit adding IDs to existing drivers to support new
   hardware, provided the driver itself isn't being rewritten.
2. **Obviously Correct:** The change adds four lines of data to a match
   table. It is minimal and surgical.
3. **Low Risk:** There is zero risk to existing users. The code path for
   supported CPUs remains identical. The new entries only activate on
   the specific new CPU models.

**Caveats & Dependencies:**
- **VFM Infrastructure:** The patch relies on the `X86_MATCH_VFM` macro.
  Ensure the target stable tree supports this macro (introduced to
  handle non-Family-6 CPUs like Nova Lake).
- **Header Definitions:** The target tree must have the updated
  `arch/x86/include/asm/intel-family.h` containing
  `INTEL_PANTHERLAKE_L`, `INTEL_NOVALAKE`, etc. These are typically
  backported, but verify their existence before applying this patch.

**Conclusion:**
This is a standard, low-risk hardware enablement patch that provides
necessary functionality for users on new platforms without endangering
existing setups.

**YES**

 .../platform/x86/intel/uncore-frequency/uncore-frequency.c    | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency.c b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency.c
index 2a6897035150c..0dfc552b28024 100644
--- a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency.c
+++ b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency.c
@@ -256,6 +256,10 @@ static const struct x86_cpu_id intel_uncore_cpu_ids[] = {
 	X86_MATCH_VFM(INTEL_ARROWLAKE, NULL),
 	X86_MATCH_VFM(INTEL_ARROWLAKE_H, NULL),
 	X86_MATCH_VFM(INTEL_LUNARLAKE_M, NULL),
+	X86_MATCH_VFM(INTEL_PANTHERLAKE_L, NULL),
+	X86_MATCH_VFM(INTEL_WILDCATLAKE_L, NULL),
+	X86_MATCH_VFM(INTEL_NOVALAKE, NULL),
+	X86_MATCH_VFM(INTEL_NOVALAKE_L, NULL),
 	{}
 };
 MODULE_DEVICE_TABLE(x86cpu, intel_uncore_cpu_ids);
-- 
2.51.0

[PATCH AUTOSEL 6.17-6.6] platform/x86/amd/pmc: Add spurious_8042 to Xbox Ally

[Sasha Levin]

From: Antheas Kapenekakis <lkml@antheas.dev>

[ Upstream commit c0ddc54016636dd8dedfaf1a3b482a95058e1db2 ]

The Xbox Ally features a Van Gogh SoC that has spurious interrupts
during resume. We get the following logs:

atkbd_receive_byte: 20 callbacks suppressed
atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.

So, add the spurious_8042 quirk for it. It does not have a keyboard, so
this does not result in any functional loss.

Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4659
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20251024152152.3981721-3-lkml@antheas.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### 1. Commit Message Analysis
The commit addresses a specific hardware issue on the "Xbox Ally" (ASUS
ROG Ally) equipped with the Van Gogh SoC.
- **Problem:** The device experiences spurious interrupts from the 8042
  controller (keyboard) during resume, causing log spam
  ("atkbd_receive_byte: 20 callbacks suppressed", "Spurious ACK...").
- **Solution:** Add the device to the `fwbug_list` with the
  `quirk_spurious_8042` quirk.
- **Context:** The device is a handheld gaming PC without a physical
  keyboard, so disabling keyboard wakeup has no functional downside.
- **Tags:** Includes "Closes:" linking to a bug report and "Reviewed-
  by:". It lacks a "Cc: stable" tag, but this is likely an oversight
  given the nature of the patch.

### 2. Deep Code Research
- **Code Change:** The patch adds a single `dmi_system_id` entry to
  `drivers/platform/x86/amd/pmc/pmc-quirks.c`.
- **Mechanism:**
  - The new entry matches the DMI data for "ASUSTeK COMPUTER INC." /
    "RC73YA".
  - It assigns `driver_data = &quirk_spurious_8042`.
  - In `amd_pmc_quirks_init()`, this quirk sets
    `dev->disable_8042_wakeup = true`.
  - During suspend, `amd_pmc_suspend_handler()` checks this flag and
    calls `amd_pmc_wa_irq1()`, which disables the IRQ1 wakeup source.
  - This prevents the firmware bug (spurious IRQ1 assertion) from
    triggering during resume.
- **Dependencies:** The quirk infrastructure (`quirk_spurious_8042`) was
  introduced in late 2023 and is present in all currently supported
  stable kernels (6.1.y and newer). The change is self-contained.

### 3. Historical Context & Precedent
This file (`pmc-quirks.c`) serves as a central registry for AMD PMC
firmware bugs. There is a strong established pattern of backporting new
entries for this specific issue:
- Commit `12a3dd4d2cd92` ("Add Stellaris Slim Gen6 AMD...")
- Commit `8822e8be86d40` ("Add MECHREVO Yilong15Pro...")
- Commit `c96f86217bb28` ("Add TUXEDO IB Pro Gen10...")
All of these were backported to stable trees. This commit follows the
exact same pattern.

### 4. Stable Kernel Rules Compliance
This commit falls strictly under the **"QUIRKS and WORKAROUNDS"**
exception in the stable kernel rules:
- **Rule:** "Hardware-specific quirks for broken/buggy devices" are
  allowed.
- **Compliance:** The patch fixes broken behavior (spurious interrupts)
  on specific hardware using an existing workaround mechanism.
- **Constraint Check:** It introduces no new features, APIs, or
  architectural changes. It is a data-only change (adding a struct
  entry).

### 5. Risk Assessment
- **Severity:** Medium. The issue causes log spam and potential resume
  quirks, which degrades the user experience on this specific device.
- **Regression Risk:** **Extremely Low**.
  - The change is guarded by a specific DMI match, ensuring it affects
    *only* the ROG Ally RC73YA.
  - The mitigation (disabling keyboard wakeup) is safe because the
    device physically lacks a keyboard.
  - The underlying logic is well-tested on other AMD platforms (Renoir,
    Cezanne, etc.).

### Conclusion
This is a textbook candidate for stable backporting. It is a surgical,
hardware-specific fix that uses existing infrastructure to resolve a
real-world issue (log spam/resume behavior) on a production device. It
carries negligible risk and aligns perfectly with the "Device Quirks"
exception of the stable kernel rules.

**YES**

 drivers/platform/x86/amd/pmc/pmc-quirks.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/platform/x86/amd/pmc/pmc-quirks.c b/drivers/platform/x86/amd/pmc/pmc-quirks.c
index 0fadcf5f288ac..404e62ad293a9 100644
--- a/drivers/platform/x86/amd/pmc/pmc-quirks.c
+++ b/drivers/platform/x86/amd/pmc/pmc-quirks.c
@@ -122,6 +122,14 @@ static const struct dmi_system_id fwbug_list[] = {
 			DMI_MATCH(DMI_PRODUCT_NAME, "21A1"),
 		}
 	},
+	{
+		.ident = "ROG Xbox Ally RC73YA",
+		.driver_data = &quirk_spurious_8042,
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER INC."),
+			DMI_MATCH(DMI_BOARD_NAME, "RC73YA"),
+		}
+	},
 	/* https://bugzilla.kernel.org/show_bug.cgi?id=218024 */
 	{
 		.ident = "V14 G4 AMN",
-- 
2.51.0

[PATCH AUTOSEL 6.17] platform/x86/amd/pmc: Add support for Van Gogh SoC

[Sasha Levin]

From: Antheas Kapenekakis <lkml@antheas.dev>

[ Upstream commit db4a3f0fbedb0398f77b9047e8b8bb2b49f355bb ]

The ROG Xbox Ally (non-X) SoC features a similar architecture to the
Steam Deck. While the Steam Deck supports S3 (s2idle causes a crash),
this support was dropped by the Xbox Ally which only S0ix suspend.

Since the handler is missing here, this causes the device to not suspend
and the AMD GPU driver to crash while trying to resume afterwards due to
a power hang.

Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4659
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://patch.msgid.link/20251024152152.3981721-2-lkml@antheas.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

### Comprehensive Analysis

1. **Commit Message Analysis**
    - **Issue:** Devices using the AMD Van Gogh SoC (specifically
      mentioned is the "ROG Xbox Ally") fail to suspend properly. The
      system suffers a "power hang" and the AMD GPU driver crashes upon
      resume attempts.
    - **Cause:** The `amd_pmc` platform driver lacks the necessary
      identifiers and handlers for this specific SoC model.
    - **Context:** This is a bug fix for broken hardware functionality
      (suspend/resume), despite the subject line saying "Add support".
    - **External References:** Links to a specific bug report on GitLab
      (#4659).

2. **Code Changes & Technical Deep Dive**
    - **The Bug Mechanism:** The current stable driver is missing the
      PCI Device ID `0x1645` (Van Gogh). Consequently, `pci_match_id()`
      in `amd_pmc_probe` fails, and the driver never loads. Even if
      forced, `amd_pmc_get_os_hint()` would return `-EINVAL`, causing
      `amd_pmc_s2idle_prepare()` to fail or send incorrect messages to
      the System Management Unit (SMU).
    - **The Fix:**
        - Adds `AMD_CPU_ID_VG` (0x1645) to `pmc.h`.
        - Adds the ID to `pmc_pci_ids[]` table, allowing the driver to
          bind.
        - Adds cases to `amd_pmc_get_ip_info` and `amd_pmc_get_os_hint`
          to treat Van Gogh identically to Renoir (RN) and Yellow Carp
          (YC) SoCs.
    - **Scope:** The changes are extremely localized (approx. 5 lines of
      code added). It uses existing, proven code paths.

3. **Stable Kernel Rules Compliance**
    - **Criterion:** "It must NOT introduce new features".
    - **Exception:** **NEW DEVICE IDs**. The stable rules explicitly
      allow "Adding PCI IDs... to existing drivers" to enable hardware
      support. This commit falls squarely into this category.
    - **Criterion:** "It must fix a real bug".
    - **Met:** Yes, it fixes a system crash/hang on suspend.
    - **Criterion:** "It must be obviously correct".
    - **Met:** Yes, it simply maps a new ID to existing logic verified
      on similar hardware.

4. **Risk vs. Benefit**
    - **Benefit:** High. Fixes a critical usability issue (unable to
      suspend/resume) and prevents kernel crashes for users of popular
      handheld gaming devices.
    - **Risk:** Extremely Low. The change is guarded by the specific CPU
      ID. It does not alter logic for any currently supported hardware.
    - **Dependencies:** None. The driver structure and constants
      (`soc15_ip_blk`, `MSG_OS_HINT_RN`) are already present in stable
      trees (e.g., 6.1, 6.6).

5. **Conclusion**
  This is a textbook candidate for stable backporting. It addresses a
  hardware-specific crash by adding a missing PCI ID and routing it
  through existing driver logic, which is a permitted exception to the
  "no new features" rule.

**YES**

 drivers/platform/x86/amd/pmc/pmc.c | 3 +++
 drivers/platform/x86/amd/pmc/pmc.h | 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/platform/x86/amd/pmc/pmc.c b/drivers/platform/x86/amd/pmc/pmc.c
index bd318fd02ccf4..cae3fcafd4d7b 100644
--- a/drivers/platform/x86/amd/pmc/pmc.c
+++ b/drivers/platform/x86/amd/pmc/pmc.c
@@ -106,6 +106,7 @@ static void amd_pmc_get_ip_info(struct amd_pmc_dev *dev)
 	switch (dev->cpu_id) {
 	case AMD_CPU_ID_PCO:
 	case AMD_CPU_ID_RN:
+	case AMD_CPU_ID_VG:
 	case AMD_CPU_ID_YC:
 	case AMD_CPU_ID_CB:
 		dev->num_ips = 12;
@@ -517,6 +518,7 @@ static int amd_pmc_get_os_hint(struct amd_pmc_dev *dev)
 	case AMD_CPU_ID_PCO:
 		return MSG_OS_HINT_PCO;
 	case AMD_CPU_ID_RN:
+	case AMD_CPU_ID_VG:
 	case AMD_CPU_ID_YC:
 	case AMD_CPU_ID_CB:
 	case AMD_CPU_ID_PS:
@@ -717,6 +719,7 @@ static const struct pci_device_id pmc_pci_ids[] = {
 	{ PCI_DEVICE(PCI_VENDOR_ID_AMD, AMD_CPU_ID_RV) },
 	{ PCI_DEVICE(PCI_VENDOR_ID_AMD, AMD_CPU_ID_SP) },
 	{ PCI_DEVICE(PCI_VENDOR_ID_AMD, AMD_CPU_ID_SHP) },
+	{ PCI_DEVICE(PCI_VENDOR_ID_AMD, AMD_CPU_ID_VG) },
 	{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_1AH_M20H_ROOT) },
 	{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_1AH_M60H_ROOT) },
 	{ }
diff --git a/drivers/platform/x86/amd/pmc/pmc.h b/drivers/platform/x86/amd/pmc/pmc.h
index 62f3e51020fdf..fe3f53eb59558 100644
--- a/drivers/platform/x86/amd/pmc/pmc.h
+++ b/drivers/platform/x86/amd/pmc/pmc.h
@@ -156,6 +156,7 @@ void amd_mp2_stb_deinit(struct amd_pmc_dev *dev);
 #define AMD_CPU_ID_RN			0x1630
 #define AMD_CPU_ID_PCO			AMD_CPU_ID_RV
 #define AMD_CPU_ID_CZN			AMD_CPU_ID_RN
+#define AMD_CPU_ID_VG			0x1645
 #define AMD_CPU_ID_YC			0x14B5
 #define AMD_CPU_ID_CB			0x14D8
 #define AMD_CPU_ID_PS			0x14E8
-- 
2.51.0

[PATCH AUTOSEL 6.17] platform/x86/intel/hid: Add Nova Lake support

[Sasha Levin]

From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>

[ Upstream commit ddf5ffff3a5fe95bed178f5554596b93c52afbc9 ]

Add ACPI ID for Nova Lake.

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://patch.msgid.link/20251110235041.123685-1-srinivas.pandruvada@linux.intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

1. **COMMIT MESSAGE ANALYSIS**
   - The subject "platform/x86/intel/hid: Add Nova Lake support" and
     body "Add ACPI ID for Nova Lake" clearly identify this as a
     hardware enablement patch.
   - There are no "Fixes:" or "Cc: stable@" tags. While this often
     signals a feature, simple device ID additions are frequently
     backported without these tags under specific stable rule
     exceptions.
   - The change is signed off by the subsystem maintainer.

2. **DEEP CODE RESEARCH**
   - **File:** `drivers/platform/x86/intel/hid.c`
   - **Mechanism:** The `intel_hid` driver relies on an ACPI device ID
     table (`intel_hid_ids`) to bind to the underlying platform
     firmware. When the ACPI subsystem enumerates devices, it checks
     this table.
   - **The Change:** The commit adds a single line `{ "INTC10F2" }` to
     this array. This ID corresponds to the Nova Lake platform.
   - **Impact:** Without this ID, the kernel will fail to load this
     driver on Nova Lake laptops. Users would experience broken
     functionality for hotkeys (brightness, volume, WiFi toggle) and
     5-button array features (common on 2-in-1s/tablets).
   - **Context:** The diff shows the immediate predecessor `{ "INTC10F1"
     }` (Wildcat Lake), confirming that this driver is mature and
     regularly updated for new Intel generations via this exact
     mechanism.

3. **STABLE KERNEL RULES ALIGNMENT**
   - **General Rule:** Usually, new hardware support is not appropriate
     for stable.
   - **Exception Check (CRITICAL):** However, the *Stable Kernel Rules*
     (Documentation/process/stable-kernel-rules.rst) contain a specific
     exception for **"NEW DEVICE IDs"**. It explicitly states that
     adding ACPI IDs to existing drivers is allowed.
   - **Compliance:**
     - Does the driver exist in stable? **Yes**, `intel/hid.c` is a
       long-standing driver.
     - Is the change minimal? **Yes**, it is a one-line data addition.
     - Is it obviously correct? **Yes**, it strictly follows the pattern
       of previous platforms.

4. **RISK VS BENEFIT ASSESSMENT**
   - **Regression Risk:** **Negligible**. The change effectively only
     executes when the specific ACPI ID `INTC10F2` is present in the
     system firmware. Existing systems (with different IDs) will skip
     this entry in the match table, resulting in zero change in behavior
     for current users.
   - **Benefit:** High for users of new hardware. It allows enterprise
     and LTS distributions (which rely on stable kernels) to function
     correctly on upcoming Nova Lake devices without requiring a full
     kernel upgrade.

5. **CONCLUSION**
  This commit is a textbook example of the "New Device ID" exception. It
  provides necessary hardware enablement for stable kernel users with
  zero risk of regression for existing users. While it lacks a stable
  tag, it qualifies for backporting based on the documented rules and
  the trivial nature of the change.

**YES**

 drivers/platform/x86/intel/hid.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/intel/hid.c b/drivers/platform/x86/intel/hid.c
index f25a427cccdac..9c07a7faf18fe 100644
--- a/drivers/platform/x86/intel/hid.c
+++ b/drivers/platform/x86/intel/hid.c
@@ -55,6 +55,7 @@ static const struct acpi_device_id intel_hid_ids[] = {
 	{ "INTC10CB" },
 	{ "INTC10CC" },
 	{ "INTC10F1" },
+	{ "INTC10F2" },
 	{ }
 };
 MODULE_DEVICE_TABLE(acpi, intel_hid_ids);
-- 
2.51.0

[PATCH AUTOSEL 6.17-5.4] platform/x86: acer-wmi: Ignore backlight event

[Sasha Levin]

From: Armin Wolf <W_Armin@gmx.de>

[ Upstream commit 444a9256f8d106e08a6bc2dc8ef28a8699e4b3ba ]

On the Acer Nitro AN515-58, the event 4 - 0 is send by the ACPI
firmware when the backlight up/down keys are pressed. Ignore this
event to avoid spamming the kernel log with error messages, as the
acpi-video driver already handles brightness up/down events.

Reported-by: Bugaddr <Bugaddr@protonmail.com>
Closes: https://bugaddr.tech/posts/2025-11-16-debugging-the-acer-nitro-5-an515-58-fn-f10-keyboard-backlight-bug-on-linux/#wmi-interface-issues
Tested-by: Bugaddr <Bugaddr@protonmail.com>
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20251117155938.3030-1-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

1. COMMIT MESSAGE ANALYSIS
   - **Problem:** On the Acer Nitro AN515-58, pressing brightness keys
     triggers WMI event `0x4`. The driver does not recognize this event,
     causing it to fall through to the default handler which spams the
     kernel log with "Unknown function number" errors.
   - **Fix:** The commit adds `WMID_BACKLIGHT_EVENT` (0x4) to the event
     enum and adds a specific case in `acer_wmi_notify` to ignore it.
   - **Reasoning:** The commit explains that the `acpi-video` driver
     already handles the actual backlight changes, making this WMI event
     redundant. Ignoring it explicitly silences the false-positive
     warnings.
   - **Tags:** Contains `Reported-by`, `Closes`, `Tested-by`, and
     `Reviewed-by`. While it lacks a `Cc: stable` tag, the fix addresses
     a regression in usability for supported hardware.

2. DEEP CODE RESEARCH
   - **Context:** The driver `drivers/platform/x86/acer-wmi.c` has a
     switch statement to handle WMI events. Unknown events trigger a
     `pr_warn`, creating log noise.
   - **History:** Support for the Acer Nitro AN515-58 was added in
     commit `549fcf58cf58`. Once that commit landed, the driver began
     binding to this hardware, exposing this unhandled event issue.
   - **Mechanism:** The patch is a trivial suppression. It defines the
     event ID and creates a no-op path for it.
     ```c
     case WMID_BACKLIGHT_EVENT:
     /* Already handled by acpi-video */
     break;
     ```
   - **Precedent:** This driver has a history of similar fixes (e.g.,
     ignoring AC events that are handled elsewhere) which have been
     backported to stable to keep logs clean.

3. STABLE KERNEL CRITERIA ASSESSMENT
   - **Fixes a real bug?** Yes. While not a crash, excessive log spam is
     a valid bug; it fills disk space, masks legitimate kernel warnings,
     and degrades the user experience.
   - **Fits stable rules?** Yes. This falls under the **Hardware Quirks
     and Workarounds** exception. It adapts the driver to specific
     hardware behavior (firmware sending redundant events).
   - **Small and Contained?** Yes. The change is extremely small (adding
     an enum and a case statement) and localized to one file.
   - **No New Features?** Yes. It strictly suppresses an error; it adds
     no new user-visible functionality.
   - **Regression Risk?** Extremely Low. The change only affects event
     `0x4`. Previously, this event triggered a warning and did nothing
     else. Now, it triggers no warning and does nothing else. Functional
     behavior remains identical.

4. CONCLUSION
  This commit is a textbook candidate for a stable backport under the
  "Quirks and Workarounds" category. It fixes a tangible annoyance (log
  spam) for users of supported hardware without introducing any risk or
  complexity. It should be backported to all stable trees that contain
  the initial support for the Acer Nitro AN515-58.

**YES**

 drivers/platform/x86/acer-wmi.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index 13eb22b35aa8f..d848afc91f87d 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -102,6 +102,7 @@ MODULE_ALIAS("wmi:676AA15E-6A47-4D9F-A2CC-1E6D18D14026");
 
 enum acer_wmi_event_ids {
 	WMID_HOTKEY_EVENT = 0x1,
+	WMID_BACKLIGHT_EVENT = 0x4,
 	WMID_ACCEL_OR_KBD_DOCK_EVENT = 0x5,
 	WMID_GAMING_TURBO_KEY_EVENT = 0x7,
 	WMID_AC_EVENT = 0x8,
@@ -2369,6 +2370,9 @@ static void acer_wmi_notify(union acpi_object *obj, void *context)
 			sparse_keymap_report_event(acer_wmi_input_dev, scancode, 1, true);
 		}
 		break;
+	case WMID_BACKLIGHT_EVENT:
+		/* Already handled by acpi-video */
+		break;
 	case WMID_ACCEL_OR_KBD_DOCK_EVENT:
 		acer_gsensor_event();
 		acer_kbd_dock_event(&return_value);
-- 
2.51.0

[PATCH AUTOSEL 6.17-6.6] platform/x86/amd: pmc: Add Lenovo Legion Go 2 to pmc quirk list

[Sasha Levin]

From: Antheas Kapenekakis <lkml@antheas.dev>

[ Upstream commit f945afe01c6768dcfed7868c671a26e1164c2284 ]

The Lenovo Legion Go 2 takes a long time to resume from suspend.
This is due to it having an nvme resume handler that interferes
with IOMMU mappings. It is a common issue with older Lenovo
laptops. Adding it to that quirk list fixes this issue.

Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4618
Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20251008135057.731928-1-lkml@antheas.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Comprehensive Analysis

### 1. Commit Message Analysis
The commit "platform/x86/amd: pmc: Add Lenovo Legion Go 2 to pmc quirk
list" addresses a specific hardware issue on the Lenovo Legion Go 2. The
device experiences long resume times from suspend due to an NVMe resume
handler interfering with IOMMU mappings. This is identified as a
firmware bug common to several Lenovo laptops. The fix explicitly closes
a reported issue on GitLab (#4618) and includes `Reviewed-by` tags from
subsystem maintainers.

### 2. Deep Code Research & Mechanism
**Code Change:**
The commit modifies `drivers/platform/x86/amd/pmc/pmc-quirks.c` by
adding two new entries to the `fwbug_list` array. These entries target
the "Lenovo Legion Go 2" with product IDs `83N0` and `83N1`.

**Mechanism:**
The entries are associated with `quirk_s2idle_bug`.
- **The Bug:** On certain AMD platforms, the firmware executes a System
  Management Interrupt (SMI) handler during the resume transition (D3 ->
  D0). If IOMMU is enabled, this handler triggers page faults or
  timeouts, resulting in the "long time to resume" symptom.
- **The Fix:** The `quirk_s2idle_bug` callback triggers the
  `amd_pmc_skip_nvme_smi_handler` function. This function performs a
  specific MMIO write (typically to the FCH PM scratch register) to
  disable the problematic SMI handler during the resume phase, bypassing
  the conflict.

**Infrastructure Context:**
This uses existing quirk infrastructure (`quirk_s2idle_bug` and
`amd_pmc_skip_nvme_smi_handler`) which was introduced in kernel v6.6.
The change itself is purely data—adding IDs to an existing table—rather
than introducing new logic.

### 3. Stable Kernel Rules Compliance
This commit falls squarely under the **"QUIRKS and WORKAROUNDS"**
exception category, which is explicitly allowed in stable trees.
- **Criteria Check:**
    - **Obviously correct:** It strictly adds DMI matches to a table
      using an existing, proven handler.
    - **Fixes real bug:** Addresses a significant usability regression
      (broken/slow suspend) for end users.
    - **No new features:** It is a hardware enablement/fix, not a
      feature addition.
    - **Small scope:** Touch is limited to 17 lines of data addition in
      one file.

### 4. Risk Assessment
- **Regression Risk:** **Extremely Low**. The change is guarded by
  specific DMI matches (Vendor "LENOVO", Product "83N0"/"83N1"). It will
  only trigger on the exact hardware specified. It cannot negatively
  impact other devices.
- **User Impact:** High for owners of the device. Without this fix,
  suspend/resume is effectively broken or frustratingly slow.

### 5. Dependencies and Backporting
- **Dependencies:** The commit depends on the AMD PMC quirk
  infrastructure (`quirk_s2idle_bug`). This infrastructure is present in
  current stable branches like 6.6.y, 6.12.y, and 6.1.y (where the
  driver has been updated).
- **Applicability:** It should apply cleanly to any stable tree
  containing the `drivers/platform/x86/amd/pmc/pmc-quirks.c` file and
  the associated quirk definitions.

### Conclusion
This is a textbook stable backport candidate. It is a low-risk,
hardware-specific quirk that fixes a real user-visible bug using
established kernel infrastructure. It perfectly matches the exception
for hardware workarounds.

**YES**

 drivers/platform/x86/amd/pmc/pmc-quirks.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/platform/x86/amd/pmc/pmc-quirks.c b/drivers/platform/x86/amd/pmc/pmc-quirks.c
index d63aaad7ef599..0fadcf5f288ac 100644
--- a/drivers/platform/x86/amd/pmc/pmc-quirks.c
+++ b/drivers/platform/x86/amd/pmc/pmc-quirks.c
@@ -204,6 +204,23 @@ static const struct dmi_system_id fwbug_list[] = {
 			DMI_MATCH(DMI_PRODUCT_NAME, "82ND"),
 		}
 	},
+	/* https://gitlab.freedesktop.org/drm/amd/-/issues/4618 */
+	{
+		.ident = "Lenovo Legion Go 2",
+		.driver_data = &quirk_s2idle_bug,
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "83N0"),
+		}
+	},
+	{
+		.ident = "Lenovo Legion Go 2",
+		.driver_data = &quirk_s2idle_bug,
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "83N1"),
+		}
+	},
 	/* https://gitlab.freedesktop.org/drm/amd/-/issues/2684 */
 	{
 		.ident = "HP Laptop 15s-eq2xxx",
-- 
2.51.0