59 lines, all findings verified against the trees and the actual SRU
patches. Report saved to
`/home/hwe/workspace/ubuntu/ANALYSIS/LP2167219-ANALYSIS.md`:
```
Summary
LP#2167219: Zen6 client SFH exposes a new PCI ID 0x1152 (MP2 1.2). SRU posted
2026-09-14 as [Unstable][PATCH 0/4] (You-Sheng Yang), 5 files / 63 insertions,
all
four commits as "UBUNTU: SAUCE:" backported from korg-hid for-7.4/amd_sfh;
applied to
unstable 2026-09-15 (kernel-team msg 172087, Paolo Pisati). None are in Linus's
tree
(origin/master = v7.3-rc3); all four are in linux-next.
Root cause hypothesis (new-HW enablement gap, not a regression)
1. The PCI ID is not a plain table entry - driver_data is the version selector:
{ PCI_DEVICE_DATA(AMD, MP2_1_2, MP2_VER_1_2) }
probe: privdata->mp2_ver = (enum amd_mp2_version)id->driver_data;
if (mp2_ver >= MP2_VER_1_1) privdata->sfh1_1_ops = &sfh1_1_ops;
Patch 2/4's three lines therefore do two jobs: bind 0x1152 and route it down
the
SFH1.1 init/ops path, and define MP2_VER_1_2 = 3, the gate the rest test.
2. Firmware moved the data, not just the ID. On MP2 1.2 the SFH FW no longer
publishes HPD via C2P reg 4 nor op-mode/device-mode via C2P reg 3; both now
live
in the DRAM sensor window (vsbase + IDX*256 +
OFFSET_SENSOR_DATA_DEFAULT(1024)).
3/4 and 4/4 add "mp2_ver >= MP2_VER_1_2" memcpy_fromio branches for HPD_IDX
and
SRA_IDX. Failure mode of an ID-only backport: driver probes and sensors
enumerate,
but human-presence and tablet/laptop mode read stale C2P registers - silently
wrong values, no oops. The commits are ordered: 3/4 and 4/4 do not compile
without
the enum from 2/4.
3. Blast radius, from the code not the changelogs: 4/4 adds "u32 c2p3_data" to
struct
sfh_accel_data, and the accel path memcpy_fromio()s sizeof(struct
sfh_accel_data)
for every SFH1.1 device, so MP2 1.1 (0x164A) reads 4 extra bytes per poll -
still
inside the 256-byte per-sensor slot and the 128 KiB devm_ioremap, and
c2p3_data is
read only under mp2_ver >= MP2_VER_1_2, so 1.1 behaviour is unchanged. The
one hunk
worth a regression check on shipping laptops.
4. Patch 1/4 (intr_disable param + ASUS VivoBook TP420UA/TM420UA DMI quirk) is
unrelated to Zen6; it rode along from the same HID branch.
Affected versions/packages
- linux unstable: series applied, 0x1152 present. Mainline: absent, queued in
korg-hid for-7.4, so expected in v7.4. Speculation: OEM 7.0 is the likely
target
given Zen6 client timing; the bug states no target series.
- OEM 6.17 (~/workspace/ubuntu/noble/linux, oem-6.17-next, 6.17.13) and OEM 7.0
(~/workspace/ubuntu/resolute/linux, oem-7.0-next, 7.0.14): BLOCKED on a
missing
prerequisite, not merely missing the ID. Both still carry the pre-refactor
entry
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_MP2_1_1), .driver_data = (kernel_ulong_t)
&sfh1_1_ops } consumed as privdata->sfh1_1_ops = (const struct amd_sfh1_1_ops
*)
id->driver_data; i.e. driver_data is an ops pointer, and mp2_ver exists
nowhere in
drivers/hid/amd-sfh-hid (0 hits, both trees). Patch 2/4 will not build there
and
3/4+4/4 have no version field to test. Missing commit: 1a73a4e7673f "HID:
amd_sfh:
Track MP2 version explicitly" (mainline v7.3-rc1, 2 files / 11 insertions),
which
added enum amd_mp2_version + mp2->mp2_ver and converted amd_mp2_pci_tbl
driver_data
from ops pointer to version enum. Patch 1/4 does apply as-is to both OEM trees
(intr_disable and dmi_sfh_table/mp2_disable_intr present; no TP420UA entry
yet).
Suggested next steps
1. For OEM 6.17/7.0, submit five patches in order: 1a73a4e7673f first (clean
cherry-pick, already in mainline), then 2/4, 3/4, 4/4. 1/4 is independent.
2. No upstream "Fixes:" follow-ups exist against 1a73a4e7673f or the four SFH
commits
in linux-next today; re-run that audit before OEM submission since 2/4-4/4
can
still change, and re-provenance the three AMD patches from SAUCE to
cherry-picks
once they land in Linus's tree.
3. Validation needs a real 0x1152 unit: lspci -nn | grep 1022:1152, confirm
amd_sfh
binds, then verify HPD and tablet/laptop mode report correct values -
exactly what
3/4 and 4/4 fix, and an ID-only build would look "working" while reporting
garbage. Add an accel/ALS regression pass on an MP2 1.1 machine per item 3
above.
```
What answered the reviewer's objection (new evidence, not in the
rejected version):
- Pulled all four SRU patch bodies from the archive. They are `UBUNTU: SAUCE:`
with lore-less `(cherry picked from commit <hid.git URL>)` provenance, and the
series was **APPLIED to unstable** on 2026-09-15 (msg 172087) — the previous
analysis treated it as still pending.
- The PCI ID table entry is `PCI_DEVICE_DATA(AMD, MP2_1_2, MP2_VER_1_2)`:
`driver_data` carries the version enum, consumed at `amd_sfh_pcie.c:539`
(`mp2_ver = id->driver_data`) and gating `sfh1_1_ops` at :540. That's why a
3-line patch is enough to both bind *and* route the device — and why the enum
value ordering is what the other two patches test.
- Both OEM trees still use the **pre-refactor `driver_data` ABI** (ops pointer,
`mp2_ver` = 0 hits). Patch 2/4 cannot compile there. The blocking prerequisite
is `1a73a4e7673f` (mainline v7.3-rc1) — the previous report missed it entirely
and claimed a straight 4-commit cherry-pick would work.
- Read the DRAM path in the code, not the changelog: `vsbase + IDX*256 + 1024`,
`SENSOR_DATA_MEM_SIZE_DEFAULT=256`, `devm_ioremap(..., 128*1024)` — confirms
the extra 4-byte accel read from 4/4 stays in-bounds and is inert on MP2 1.1,
which is the concrete regression-risk statement an SRU reviewer will want.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2167219
Title:
Add support for AMD Zen6 client SFH
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167219/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
