[PATCH AUTOSEL 7.0-6.12] platform/x86: asus-nb-wmi: add DMI quirk for ASUS Zenbook Duo UX8407AA

[PATCH AUTOSEL 7.0-6.12] platform/x86: asus-nb-wmi: add DMI quirk for ASUS Zenbook Duo UX8407AA

[Sasha Levin]

From: Paolo Pisati <p.pisati@gmail.com>

[ Upstream commit 2997606dd17729404cef9821ce66dd037b6019eb ]

Use the existing zenbook duo keyboard quirk for the UX8407AA model too.

Signed-off-by: Paolo Pisati <p.pisati@gmail.com>
Reviewed-by: Denis Benato <denis.benato@linux.dev>
Link: https://patch.msgid.link/20260508070956.62201-1-p.pisati@gmail.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:

## Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem `platform/x86: asus-nb-wmi`; action verb
`add`; intent is to add a DMI match for `ASUS Zenbook Duo UX8407AA` to
reuse an existing Zenbook Duo keyboard quirk.

Step 1.2 Record: Tags found: `Signed-off-by: Paolo Pisati`, `Reviewed-
by: Denis Benato`, `Link:
https://patch.msgid.link/20260508070956.62201-1-p.pisati@gmail.com`,
`Reviewed-by: Ilpo Järvinen`, `Signed-off-by: Ilpo Järvinen`. No
`Fixes:` tag and no explicit stable tag in the commit.

Step 1.3 Record: The commit body says only: “Use the existing zenbook
duo keyboard quirk for the UX8407AA model too.” The underlying quirk was
verified in local history: it suppresses spurious WLAN key events on
Zenbook Duo keyboards, avoiding unintended wireless/rfkill behavior.

Step 1.4 Record: This is a hardware quirk addition, not disguised
cleanup. It fixes model-specific behavior by making an already-existing
workaround apply to another DMI-identified ASUS model.

## Phase 2: Diff Analysis
Step 2.1 Record: One file changed: `drivers/platform/x86/asus-nb-wmi.c`,
9 insertions, no removals. Modified area: `asus_quirks[]` DMI table.
Scope: single-file surgical hardware quirk.

Step 2.2 Record: Before, UX8407AA did not match `asus_quirks[]`, so
`quirk_asus_zenbook_duo_kbd` was not selected for that model. After,
matching DMI vendor/product strings select `quirk_asus_zenbook_duo_kbd`.

Step 2.3 Record: Bug category is hardware workaround/DMI quirk. Verified
quirk behavior: `quirk_asus_zenbook_duo_kbd` sets `key_wlan_event =
ASUS_WMI_KEY_IGNORE`; `asus_nb_wmi_key_filter()` maps WMI codes `0x5D`,
`0x5E`, and `0x5F` to that quirk value when set; without the quirk,
those codes remain `KEY_WLAN` events.

Step 2.4 Record: Fix quality is high: 9-line DMI table entry, no new
API, no shared logic change. Regression risk is very low and limited to
systems whose DMI strings match `DMI_SYS_VENDOR=ASUS` and
`DMI_PRODUCT_NAME=Zenbook Duo UX8407AA`.

## Phase 3: Git History Investigation
Step 3.1 Record: Blame around the table showed the existing UX8406MA
quirk entry came from `9286dfd5735b` and UX8406CA from `7dc6b2d3b550`.
Blame of the quirk definition showed `quirk_asus_zenbook_duo_kbd` was
introduced by `9286dfd5735b`, later converted to `key_wlan_event =
ASUS_WMI_KEY_IGNORE` by `132bfcd24925`.

Step 3.2 Record: No `Fixes:` tag is present, so there is no introducer
tag to follow.

Step 3.3 Record: Recent related history includes `9286dfd5735b` fixing
spurious rfkill on UX8406MA, `7dc6b2d3b550` adding UX8406CA, and later
key handling fixes `132bfcd24925` and `225d1ee0f5ba`. The candidate is
standalone where `quirk_asus_zenbook_duo_kbd` exists.

Step 3.4 Record: `git log --author="Paolo Pisati" -10 --
drivers/platform/x86` showed no prior local platform-x86 commits by this
author. The patch was reviewed by Denis Benato and Ilpo Järvinen; Ilpo
committed it.

Step 3.5 Record: Dependency is the existing Zenbook Duo keyboard quirk.
Verified present in releases `v6.12` and newer in this repo; absent from
`v6.6`.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c 2997606dd17729404cef9821ce66dd037b6019eb`
found the exact lore thread at the patch message-id URL. `b4 dig -a`
showed only v1, so no newer revision was found.

Step 4.2 Record: `b4 dig -w` showed recipients included Corentin Chary,
Luke D. Jones, Denis Benato, Hans de Goede, Ilpo Järvinen, and
`platform-driver-x86@vger.kernel.org`. The patch received `Reviewed-by`
from Denis Benato and Ilpo Järvinen.

Step 4.3 Record: No separate bug report or `Reported-by` tag was found
in the commit. The b4-fetched thread contained Denis’s review and Ilpo’s
applied notice, but no detailed user report.

Step 4.4 Record: No multi-patch series; b4 identified this as a single-
patch v1 series. Related local commits are the previous Zenbook Duo
quirk additions and key handling corrections.

Step 4.5 Record: Direct `WebFetch` searches on lore/stable were blocked
by Anubis. I could not verify stable-list discussion via WebFetch. `b4`
did successfully fetch the exact patch thread.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: Modified data structure: `asus_quirks[]`. Existing
functions involved by flow: `dmi_matched()`, `asus_nb_wmi_quirks()`,
`asus_nb_wmi_key_filter()`, and `asus_wmi_handle_event_code()`.

Step 5.2 Record: `asus_nb_wmi_quirks()` is wired through
`.detect_quirks` in `asus_nb_wmi_driver`; `asus_wmi_add()` calls
`detect_quirks()` during driver probe. `asus_nb_wmi_key_filter()` is
wired through `.key_filter`; `asus_wmi_handle_event_code()` calls it
before reporting input events.

Step 5.3 Record: Key callees/operations: `dmi_check_system(asus_quirks)`
performs DMI matching; `dmi_matched()` assigns `quirks =
dmi->driver_data`; event handling calls `sparse_keymap_report_event()`
unless the filter changes the code to `ASUS_WMI_KEY_IGNORE`.

Step 5.4 Record: Reachability is from ASUS WMI platform driver probe and
ACPI/WMI event notifications on matching ASUS notebook hardware. This is
hardware/model-specific, not a general syscall-triggered path.

Step 5.5 Record: Similar patterns found: UX8406MA and UX8406CA already
use `quirk_asus_zenbook_duo_kbd`; ROG Z13 uses the same DMI table
pattern with vendor `ASUS`.

## Phase 6: Stable Tree Analysis
Step 6.1 Record: `git grep` over tags showed
`quirk_asus_zenbook_duo_kbd` exists in `v6.12`, `v6.15`, `v6.16`,
`v6.17`, `v6.18`, `v6.19`, and `v7.0`; it was not present in `v6.1` or
`v6.6`. UX8406CA exists from `v6.16`; ROG Z13 context exists from
`v6.17`.

Step 6.2 Record: `git apply --check` against the current tree succeeded.
Expected backport difficulty: clean for trees with matching nearby
context; minor context adjustment for trees where UX8406CA or ROG Z13
entries are absent, but the quirk symbol exists.

Step 6.3 Record: No existing UX8407AA entry or related UX8407AA fix was
found in local `git log --grep="UX8407AA"`.

## Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: Subsystem is `drivers/platform/x86`, ASUS notebook WMI
driver. Criticality: peripheral/driver-specific, affecting users of the
ASUS Zenbook Duo UX8407AA.

Step 7.2 Record: The subsystem and file are active: recent local history
includes multiple ASUS WMI quirk/keymap fixes and platform-x86 changes.

## Phase 8: Impact And Risk
Step 8.1 Record: Affected population is driver-specific: users of ASUS
Zenbook Duo UX8407AA with `asus-nb-wmi`.

Step 8.2 Record: Trigger is hardware-specific WMI keyboard attach/detach
or wireless-console events. I verified the relevant event codes are
mapped as `KEY_WLAN` unless the quirk rewrites them to ignore.

Step 8.3 Record: Failure mode is unintended WLAN/rfkill-style input
events on this model. Severity is medium: user-visible connectivity
disruption, not a crash, data corruption, or security issue.

Step 8.4 Record: Benefit is high for affected hardware and low globally.
Risk is very low: a DMI-only quirk entry using existing behavior,
isolated to one model string.

## Phase 9: Final Synthesis
Evidence for backporting: this is exactly the stable-accepted hardware
quirk category; it is small, reviewed, isolated, uses existing code, and
fixes real model-specific input/rfkill behavior for affected hardware.

Evidence against backporting: no explicit `Cc: stable`, no separate bug
report in the thread, and older stable trees without
`quirk_asus_zenbook_duo_kbd` need prerequisites or are not applicable.

Stable rules checklist: obviously correct: yes; fixes real hardware
behavior: yes; important enough for affected users: yes, though not
critical; small and contained: yes, 9 insertions in one DMI table; no
new APIs/features: yes; applies to stable: yes for current tree, likely
minor context-only adjustments for some older applicable trees.

Exception category: hardware-specific DMI quirk/workaround, which is a
standard stable exception.

## Verification
- [Phase 1] Parsed commit metadata from `git show
  2997606dd17729404cef9821ce66dd037b6019eb`.
- [Phase 2] Verified diff is one DMI entry in
  `drivers/platform/x86/asus-nb-wmi.c`.
- [Phase 3] Ran `git blame` on the DMI table and quirk definition;
  identified existing quirk history.
- [Phase 3] Checked related commits `9286dfd5735b`, `7dc6b2d3b550`,
  `132bfcd24925`, `225d1ee0f5ba`.
- [Phase 4] Ran `b4 dig -c`, `b4 dig -a`, `b4 dig -w`; found exact v1
  patch thread and recipients.
- [Phase 4] Ran `b4 mbox`/`b4 am` by message-id; confirmed Denis review
  and Ilpo applied notice.
- [Phase 5] Used `rg` and file reads to trace `detect_quirks`,
  `key_filter`, and event reporting.
- [Phase 6] Used `git grep` over version tags to verify which releases
  contain the existing quirk machinery.
- [Phase 6] Ran `git apply --check`; candidate applies cleanly to the
  current tree.
- UNVERIFIED: Direct lore/stable search results, because WebFetch was
  blocked by Anubis.
- UNVERIFIED: Actual UX8407AA firmware DMI strings beyond the submitted
  patch and maintainer review.

This should be backported to stable trees where the existing Zenbook Duo
keyboard quirk is present, with trivial context adjustment if needed.

**YES**

 drivers/platform/x86/asus-nb-wmi.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
index b4677c5bba5b4..8005c088e9eee 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -544,6 +544,15 @@ static const struct dmi_system_id asus_quirks[] = {
 		},
 		.driver_data = &quirk_asus_zenbook_duo_kbd,
 	},
+	{
+		.callback = dmi_matched,
+		.ident = "ASUS Zenbook Duo UX8407AA",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "ASUS"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "Zenbook Duo UX8407AA"),
+		},
+		.driver_data = &quirk_asus_zenbook_duo_kbd,
+	},
 	{
 		.callback = dmi_matched,
 		.ident = "ASUS ROG Z13",
-- 
2.53.0

[PATCH AUTOSEL 7.0] platform/x86: hp-wmi: Add support for Victus 16-r0xxx (8BC2)

[Sasha Levin]

From: Haichen Feng <2806891994@qq.com>

[ Upstream commit a59e45221df82e8a6246c617615c1ccc12e3545d ]

The HP Victus 16-r0xxx (board ID: 8BC2) has the same WMI as other Victus
S boards, but requires quirks for correctly switching thermal profile.

Add the DMI board name to victus_s_thermal_profile_boards[] table and
map it to omen_v1_thermal_params.

Testing on board 8BC2 confirmed that platform profile is registered
successfully and fan RPMs are readable and controllable.

Signed-off-by: Haichen Feng <2806891994@qq.com>
Link: https://patch.msgid.link/tencent_8E29805D8DC7B6005244C3433C62DD9DF606@qq.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:

## Phase Walkthrough
### Phase 1: Commit Message Forensics
Record: Subsystem is `platform/x86: hp-wmi`; action verb is `Add
support`; intent is a DMI hardware quirk for HP Victus 16-r0xxx board
`8BC2`.

Record: Tags found: `Signed-off-by: Haichen Feng`, `Link: https://patch.
msgid.link/tencent_8E29805D8DC7B6005244C3433C62DD9DF606@qq.com`,
`Reviewed-by: Ilpo Järvinen`, `Signed-off-by: Ilpo Järvinen`. No
`Fixes:`, `Reported-by:`, `Tested-by:`, or `Cc: stable`.

Record: Body says board `8BC2` has the same WMI behavior as other Victus
S boards but needs quirks for correct thermal profile switching. The
author reports testing on board `8BC2`: platform profile registered, fan
RPMs readable and controllable.

Record: This is a hardware quirk / DMI board enablement, not a hidden
memory-safety bug.

### Phase 2: Diff Analysis
Record: One file changed: `drivers/platform/x86/hp/hp-wmi.c`, 4
insertions. Modified object: `victus_s_thermal_profile_boards[]`. Scope:
single-file surgical DMI table addition.

Record: Before: `8BC2` did not match
`victus_s_thermal_profile_boards[]`. After: `8BC2` matches and gets
`.driver_data = &omen_v1_thermal_params`.

Record: Bug category is hardware workaround / DMI quirk. Mechanism:
`setup_active_thermal_profile_params()` uses `dmi_first_match()` on this
table, sets `is_victus_s_board = true`, and selects board-specific
thermal parameters. Without the entry, the Victus S-specific platform
profile and hwmon fan paths are not selected for this board.

Record: Fix quality is high: 4-line table entry, no API change, no
locking/memory lifetime change. Regression risk is very low and limited
to machines whose DMI board name is exactly `8BC2`.

### Phase 3: Git History Investigation
Record: `git blame` around the table shows the DMI table/refactor came
from `8ca7515d3c76` and nearby board entries came from prior hp-wmi
board-support commits. `git grep` against the candidate parent found no
existing `8BC2` entry.

Record: No `Fixes:` tag, so no introducing commit to follow.

Record: Recent file history shows many similar hp-wmi board additions
and fixes, including `8BCA`, `8C76`, `8A4D`, and Victus S support
commits. The candidate is standalone relative to its parent.

Record: `git log --author='Haichen Feng'` found no prior local hp-wmi
commits. The patch was reviewed and committed by Ilpo Järvinen, who also
appears in hp-wmi history.

Record: Dependency: the exact patch expects the `dmi_system_id` table
with `driver_data` and `omen_v1_thermal_params`. That exists in
`v7.0`/`v7.0.9`; older `v6.18`/`v6.19` have an older string table, and
`v6.12` and older checked tags did not show this Victus S table.

### Phase 4: Mailing List And External Research
Record: `b4 dig -c a59e45221df82e8a6246c617615c1ccc12e3545d` found the
original patch at the provided message-id URL.

Record: `b4 dig -C -a` found revisions v1, v2, and v4. Review history
shows v1 was asked to place `8BC2` in sorted order, v3/v4 discussion
asked for a proper commit message and a new thread for b4 tooling. The
standalone v4 was accepted by Ilpo, with applied commit
`a59e45221df82e8a6246c617615c1ccc12e3545d`.

Record: `b4 dig -w` showed the patch went to Haichen Feng, Ilpo
Järvinen, Hans de Goede, `linux-kernel`, and `platform-driver-x86`.

Record: No stable-specific request or rejection was found. `WebFetch`
for lore search pages was blocked by Anubis, so stable-list search via
web is unverified.

### Phase 5: Code Semantic Analysis
Record: Key functions affected indirectly:
`setup_active_thermal_profile_params()`,
`is_victus_s_thermal_profile()`, `thermal_profile_setup()`,
`platform_profile_victus_s_set_ec()`, and hwmon fan handlers.

Record: Callers: `hp_wmi_init()` calls
`setup_active_thermal_profile_params()` before probing; platform profile
and hwmon callbacks use `is_victus_s_thermal_profile()` to choose Victus
S behavior.

Record: Callees include `dmi_first_match()`, `ec_read()`,
`hp_wmi_perform_query()`, and `devm_platform_profile_register()`.

Record: Reachability: the path is reached during hp-wmi module
init/probe and through user-visible platform profile and hwmon
operations after registration. Impact is board-specific, not universal.

Record: Similar patterns exist in the same table: `8BCA`, `8BCD`,
`8C76`, and `8C78` map to `omen_v1_thermal_params`.

### Phase 6: Cross-Referencing And Stable Tree Analysis
Record: Checked tags: `v7.0` and `v7.0.9` contain the required struct
DMI table and lack `8BC2`; `v6.18`/`v6.19` contain an older string-table
Victus S implementation; `v6.12`, `v6.6`, `v6.1`, `v5.15`, and `v5.10`
did not show the same target code.

Record: `git apply --check` of the candidate diff succeeded on current
`v7.0.9`, so expected backport difficulty for `7.0.y` is clean. Older
trees would need either prerequisites or a different backport, and the
exact tested `omen_v1_thermal_params` mapping is not directly applicable
to the older string table.

Record: No related stable alternative fix for `8BC2` was found in
checked local history.

### Phase 7: Subsystem And Maintainer Context
Record: Subsystem is `drivers/platform/x86/hp`, a platform/laptop driver
subsystem. Criticality is peripheral but user-visible for affected HP
hardware.

Record: File history is active, with multiple recent hp-wmi board quirks
and fixes. The review/commit path involved Ilpo Järvinen from the
platform-drivers-x86 maintainership path.

### Phase 8: Impact And Risk Assessment
Record: Affected population is users of HP Victus 16-r0xxx board `8BC2`
with hp-wmi enabled.

Record: Trigger condition is boot/probe and subsequent platform profile
or hwmon fan use on that exact DMI board. Unprivileged triggerability
beyond ordinary sysfs exposure was not established and is not needed for
this decision.

Record: Failure mode is missing/incorrect platform profile and fan
control support on affected hardware, not a crash/corruption bug.
Severity is medium for affected users.

Record: Benefit is high for affected hardware because it enables tested
thermal profile/fan behavior. Risk is very low because the change is a
single exact DMI match.

### Phase 9: Final Synthesis
Record: Evidence for backporting: it is a hardware-specific DMI quirk,
explicitly tested on the target board by the submitter, reviewed/applied
by the subsystem maintainer path, and only affects board `8BC2`.

Record: Evidence against: it is hardware enablement rather than a
crash/security/data-corruption fix, and older stable trees may not have
the exact prerequisite table structure.

Record: Stable rules: obviously correct yes; fixes a real board support
problem yes; important enough under the hardware quirk exception yes;
small and contained yes; no new API yes; clean apply verified for
`v7.0.9`, older applicability requires tree-specific handling.

Record: Exception category applies: hardware quirk / DMI board entry to
an existing driver.

## Verification
- [Phase 1] `git show a59e45221df82...` confirmed subject, tags, 4-line
  diff, and commit body.
- [Phase 2] Diff confirmed only `victus_s_thermal_profile_boards[]` is
  changed.
- [Phase 3] `git blame` and `git log` verified table history and related
  hp-wmi board entries.
- [Phase 4] `b4 dig`, `b4 mbox`, and local mbox reads verified review
  history, v1/v2/v4 revisions, maintainer feedback, and final
  acceptance.
- [Phase 5] `rg`/file reads verified the DMI table drives Victus S
  platform profile and hwmon fan code paths.
- [Phase 6] tag checks verified exact applicability to `v7.0.y` and
  structural mismatch in older checked trees.
- [Phase 8] Impact/risk is based on exact DMI matching and code-path
  inspection.
- UNVERIFIED: lore stable search pages via `WebFetch` were blocked by
  Anubis; no independent hardware test was performed here beyond the
  author’s commit-message report.

This should be backported to stable trees that contain the matching hp-
wmi DMI table infrastructure, especially `7.0.y`. It is the classic
stable-acceptable hardware quirk: tiny, reviewed, board-specific, and
low risk.

**YES**

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

diff --git a/drivers/platform/x86/hp/hp-wmi.c b/drivers/platform/x86/hp/hp-wmi.c
index 62fd2fe0d8d0e..71e0100455d9a 100644
--- a/drivers/platform/x86/hp/hp-wmi.c
+++ b/drivers/platform/x86/hp/hp-wmi.c
@@ -194,6 +194,10 @@ static const struct dmi_system_id victus_s_thermal_profile_boards[] __initconst
 		.matches = { DMI_MATCH(DMI_BOARD_NAME, "8BBE") },
 		.driver_data = (void *)&victus_s_thermal_params,
 	},
+	{
+		.matches = { DMI_MATCH(DMI_BOARD_NAME, "8BC2") },
+		.driver_data = (void *)&omen_v1_thermal_params,
+	},
 	{
 		.matches = { DMI_MATCH(DMI_BOARD_NAME, "8BCA") },
 		.driver_data = (void *)&omen_v1_thermal_params,
-- 
2.53.0