[PATCH AUTOSEL 6.19-6.18] EDAC/igen6: Add two Intel Amston Lake SoCs support

[PATCH AUTOSEL 6.19-6.18] EDAC/igen6: Add two Intel Amston Lake SoCs support

[Sasha Levin]

From: Qiuxu Zhuo <qiuxu.zhuo@intel.com>

[ Upstream commit 41ca2155d62b0b0d217f59e1bce18362d0c2446f ]

Intel Amston Lake SoCs with IBECC (In-Band ECC) capability share the same
IBECC registers as Alder Lake-N SoCs. Add two new compute die IDs for
Amston Lake SoC products to enable EDAC support.

Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Tested-by: Jianfeng Gao <jianfeng.gao@intel.com>
Link: https://patch.msgid.link/20251124065457.3630949-2-qiuxu.zhuo@intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a complete analysis. Here is
my detailed assessment:

---

## Detailed Analysis: EDAC/igen6: Add two Intel Amston Lake SoCs support

### 1. Commit Message Analysis

The commit adds two new PCI compute die IDs (`DID_ASL_SKU2 = 0x4646`,
`DID_ASL_SKU3 = 0x4652`) for Intel Amston Lake SoC products to the
`igen6_edac` driver. The commit message explicitly states these SoCs
share the same IBECC registers as Alder Lake-N, meaning they reuse the
existing `adl_n_cfg` configuration structure.

- **Author**: Qiuxu Zhuo (Intel) - the primary maintainer and original
  author of this driver
- **Signed-off-by**: Tony Luck (Intel RAS maintainer) - trusted
  subsystem maintainer
- **Tested-by**: Jianfeng Gao (Intel) - hardware tested on actual Amston
  Lake devices

### 2. Code Change Analysis

The diff is minimal - exactly **4 lines added** across a single file:

1. **Two `#define` additions** (lines after existing `DID_ASL_SKU1`):
   - `#define DID_ASL_SKU2 0x4646`
   - `#define DID_ASL_SKU3 0x4652`

2. **Two PCI device table entries** (in `igen6_pci_tbl[]`):
   - `{ PCI_VDEVICE(INTEL, DID_ASL_SKU2), (kernel_ulong_t)&adl_n_cfg }`
   - `{ PCI_VDEVICE(INTEL, DID_ASL_SKU3), (kernel_ulong_t)&adl_n_cfg }`

Both new entries use the already-existing `adl_n_cfg` configuration,
which has been in the kernel since v6.8 (commit `c4a5398991fd2`). No new
code paths, no new functions, no behavioral changes. This is a pure PCI
device ID addition.

### 3. Classification: New Device IDs (Explicitly Allowed Exception)

This is a textbook **new device ID addition** to an existing driver. The
stable kernel rules documentation explicitly allows this:

> "Adding PCI IDs, USB IDs, ACPI IDs, etc. to existing drivers - These
are trivial one-line additions that enable hardware support"

The pattern is identical to many prior device ID additions to this
driver:
- Arizona Beach (`b804d7c59aea0`) - single PCI ID using `adl_n_cfg`
- Alder Lake-N extra SKU (`65c441ec58224`) - single PCI ID using
  `adl_n_cfg`
- Arrow Lake-U/H (`88150cd9501b9`) - PCI IDs using `mtl_p_cfg`

### 4. Scope and Risk Assessment

- **Lines changed**: 4 added, 0 deleted
- **Files touched**: 1 (`drivers/edac/igen6_edac.c`)
- **Complexity**: Near-zero - just PCI ID defines and table entries
- **Risk of regression**: Effectively zero. The new PCI IDs will only
  match hardware that has those specific device IDs. If no such hardware
  is present, the entries are completely inert. If the hardware IS
  present, it uses the well-tested `adl_n_cfg` path that Alder Lake-N,
  Arizona Beach, and Amston Lake SKU1 all use.

### 5. User Impact

Intel Amston Lake SoCs are described as "tailored for edge computing
needs" in the original Amston Lake commit. EDAC (Error Detection and
Correction) is critical for:
- **Edge computing and embedded systems** - where these SoCs are
  deployed
- **Reliability-critical environments** - where memory error detection
  prevents silent data corruption
- **Enterprise/industrial applications** - Amston Lake targets this
  market segment

Without these device IDs, users with Amston Lake SKU2/SKU3 hardware get
**no IBECC EDAC support** - meaning memory errors go undetected, which
can lead to silent data corruption.

### 6. Stability Indicators

- Written by the driver's original author (Qiuxu Zhuo at Intel)
- Signed-off by the RAS subsystem maintainer (Tony Luck)
- Hardware-tested by Intel engineer (Jianfeng Gao)
- The same `adl_n_cfg` config is already used by 12+ Alder Lake-N SKUs,
  Arizona Beach, and ASL_SKU1 - extremely well-tested code path

### 7. Dependency Check

This commit depends on commit `099d2db3625b3` ("EDAC/igen6: Add Intel
Amston Lake SoCs support") which introduced `DID_ASL_SKU1` and the
Amston Lake comment section. That commit landed in v6.16-rc1. Both
commits would need to be backported together to stable trees that have
`adl_n_cfg` (v6.8+). This is straightforward - both are trivial device
ID additions.

The `adl_n_cfg` configuration exists since v6.8 (commit
`c4a5398991fd2`), so active stable trees 6.8.y, 6.12.y would have the
necessary infrastructure. For 6.6.y, the `adl_n_cfg` is also present
since it was added in v6.8-rc1 which branched after 6.6 - actually let
me verify:

The `adl_n_cfg` was introduced by `c4a5398991fd2` which is tagged at
`v6.8-rc1~209^2~8`. This means it's in v6.8+. Active stable trees like
6.12.y and 6.6.y need to be checked individually, but 6.6.y would NOT
have `adl_n_cfg` since it predates v6.8. Stable trees 6.8+ would have
it.

### Summary

| Criterion | Assessment |
|---|---|
| Fixes real issue? | Yes - enables EDAC on Amston Lake SKU2/SKU3
hardware |
| Obviously correct? | Yes - trivial PCI ID addition |
| Small and contained? | Yes - 4 lines, 1 file |
| New features? | No - enables existing functionality on new hardware |
| Risk? | Near-zero |
| Tested? | Yes (Tested-by tag from Intel) |
| Category | New Device IDs - explicitly allowed in stable |

This commit is a clear-cut example of the "new device ID" exception to
stable kernel rules. It enables EDAC support for real Intel hardware
(Amston Lake edge computing SoCs) with zero risk of regression. The
change is trivial, authored and tested by Intel engineers, and follows
the exact same pattern as numerous prior device ID additions to this
driver.

**YES**

 drivers/edac/igen6_edac.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/edac/igen6_edac.c b/drivers/edac/igen6_edac.c
index 839b6dd3629e9..f2c9270c1893c 100644
--- a/drivers/edac/igen6_edac.c
+++ b/drivers/edac/igen6_edac.c
@@ -246,6 +246,8 @@ static struct work_struct ecclog_work;
 
 /* Compute did IDs for Amston Lake with IBECC */
 #define DID_ASL_SKU1	0x464a
+#define DID_ASL_SKU2	0x4646
+#define DID_ASL_SKU3	0x4652
 
 /* Compute die IDs for Raptor Lake-P with IBECC */
 #define DID_RPL_P_SKU1	0xa706
@@ -628,6 +630,8 @@ static struct pci_device_id igen6_pci_tbl[] = {
 	{ PCI_VDEVICE(INTEL, DID_ADL_N_SKU12), (kernel_ulong_t)&adl_n_cfg },
 	{ PCI_VDEVICE(INTEL, DID_AZB_SKU1), (kernel_ulong_t)&adl_n_cfg },
 	{ PCI_VDEVICE(INTEL, DID_ASL_SKU1), (kernel_ulong_t)&adl_n_cfg },
+	{ PCI_VDEVICE(INTEL, DID_ASL_SKU2), (kernel_ulong_t)&adl_n_cfg },
+	{ PCI_VDEVICE(INTEL, DID_ASL_SKU3), (kernel_ulong_t)&adl_n_cfg },
 	{ PCI_VDEVICE(INTEL, DID_RPL_P_SKU1), (kernel_ulong_t)&rpl_p_cfg },
 	{ PCI_VDEVICE(INTEL, DID_RPL_P_SKU2), (kernel_ulong_t)&rpl_p_cfg },
 	{ PCI_VDEVICE(INTEL, DID_RPL_P_SKU3), (kernel_ulong_t)&rpl_p_cfg },
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.18] EDAC/igen6: Add more Intel Panther Lake-H SoCs support

[Sasha Levin]

From: Lili Li <lili.li@intel.com>

[ Upstream commit 4c36e6106997b6ad8f4a279b4bdbca3ed6f53c6c ]

Add more Intel Panther Lake-H SoC compute die IDs for EDAC support.

Signed-off-by: Lili Li <lili.li@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Link: https://patch.msgid.link/20251124131537.3633983-1-qiuxu.zhuo@intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have a comprehensive picture. Let me summarize my analysis.

## Detailed Analysis

### 1. Commit Message Analysis

The commit subject is "EDAC/igen6: Add more Intel Panther Lake-H SoCs
support" and the body says "Add more Intel Panther Lake-H SoC compute
die IDs for EDAC support." This is purely a **new device ID addition**
to an existing driver. The commit is authored by Intel employees (Lili
Li, Qiuxu Zhuo) who maintain this specific EDAC driver, and reviewed by
the same team.

### 2. Code Change Analysis

The diff is straightforward and mechanical:

**Part 1 - Macro definitions** (lines ~280-290): Adds 10 new `#define`
constants:
- `DID_PTL_H_SKU4` through `DID_PTL_H_SKU13` with PCI device IDs
  `0xb003`, `0xb004`, `0xb005`, `0xb008`, `0xb011`, `0xb014`, `0xb015`,
  `0xb028`, `0xb029`, `0xb02a`

**Part 2 - PCI device table** (lines ~675-695): Adds 10 new
`PCI_VDEVICE` entries, all pointing to the existing `mtl_p_cfg`
configuration structure — the same configuration used by the 3 initial
PTL-H SKUs.

This is a textbook **PCI device ID addition**. No new logic, no new
config structures, no new functions. Every new entry uses the identical
`mtl_p_cfg` configuration as the existing PTL-H SKUs.

### 3. Classification

This falls squarely into the **"New Device IDs" exception** for stable
trees:
- The driver (`igen6_edac`) already exists in stable trees
- The PTL-H configuration (`mtl_p_cfg`) and initial PTL-H support
  already exist (since v6.13)
- Only new PCI IDs are being added — enabling additional hardware
  variants of the same SoC family

### 4. Scope and Risk Assessment

- **Lines changed**: ~20 (10 `#define`s + 10 PCI table entries)
- **Files touched**: 1 (`drivers/edac/igen6_edac.c`)
- **Risk**: Extremely low. The PCI device table is a static array of ID-
  to-config mappings. The new entries only match hardware with those
  specific PCI IDs. If the hardware isn't present, the entries are
  completely inert. Zero risk to existing functionality.
- **Complexity**: Trivial — pure data addition with no logic changes.

### 5. Dependency Check

This commit has one critical dependency:
- **Initial PTL-H support commit** (`0be9f1af39022`): "EDAC/igen6: Add
  Intel Panther Lake-H SoCs support" — landed in **v6.13**. This commit
  defined `DID_PTL_H_SKU1`-`SKU3` and the usage of `mtl_p_cfg` for
  PTL-H.

Therefore:
- **v6.1 LTS, v6.6 LTS, v6.12 stable**: The prerequisite commit is NOT
  present. Backporting here would require first backporting the initial
  PTL-H support.
- **v6.13+ stable** (v6.13.y, v6.14.y, etc.): The prerequisite IS
  present, so this patch can apply cleanly.

### 6. User Impact

EDAC (Error Detection And Correction) is critical infrastructure for
detecting and reporting memory errors. Without these device IDs, users
with Intel Panther Lake-H SoCs with these specific compute die IDs will
get **no EDAC/ECC error reporting** — meaning memory errors could go
undetected, leading to potential silent data corruption on affected
hardware. This is exactly the kind of hardware enablement that stable
users (particularly enterprise/embedded users) need.

### 7. Stability Indicators

- Reviewed by Intel's EDAC team member (Qiuxu Zhuo)
- Signed off by the RAS maintainer (Tony Luck)
- Same pattern as dozens of prior device ID additions to this driver,
  all of which have been successfully backported to stable trees (Arrow
  Lake, Meteor Lake-P/PS, Raptor Lake-P, Alder Lake-N, etc.)

### 8. Verdict

This is a classic, textbook device ID addition:
- Purely mechanical addition of PCI device IDs
- Uses existing infrastructure (no new code paths)
- Enables EDAC support on additional Panther Lake-H hardware variants
- Extremely low risk — inert on systems without matching hardware
- The only concern is dependency on initial PTL-H support (v6.13+), but
  this is manageable

The commit matches the stable kernel rules for device ID additions
perfectly. It's small, contained, obviously correct, and enables real
hardware support for real users.

**YES**

 drivers/edac/igen6_edac.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/edac/igen6_edac.c b/drivers/edac/igen6_edac.c
index 553c31a2d9226..839b6dd3629e9 100644
--- a/drivers/edac/igen6_edac.c
+++ b/drivers/edac/igen6_edac.c
@@ -274,6 +274,16 @@ static struct work_struct ecclog_work;
 #define DID_PTL_H_SKU1	0xb000
 #define DID_PTL_H_SKU2	0xb001
 #define DID_PTL_H_SKU3	0xb002
+#define DID_PTL_H_SKU4	0xb003
+#define DID_PTL_H_SKU5	0xb004
+#define DID_PTL_H_SKU6	0xb005
+#define DID_PTL_H_SKU7	0xb008
+#define DID_PTL_H_SKU8	0xb011
+#define DID_PTL_H_SKU9	0xb014
+#define DID_PTL_H_SKU10	0xb015
+#define DID_PTL_H_SKU11	0xb028
+#define DID_PTL_H_SKU12	0xb029
+#define DID_PTL_H_SKU13	0xb02a
 
 /* Compute die IDs for Wildcat Lake with IBECC */
 #define DID_WCL_SKU1	0xfd00
@@ -636,6 +646,16 @@ static struct pci_device_id igen6_pci_tbl[] = {
 	{ PCI_VDEVICE(INTEL, DID_PTL_H_SKU1), (kernel_ulong_t)&mtl_p_cfg },
 	{ PCI_VDEVICE(INTEL, DID_PTL_H_SKU2), (kernel_ulong_t)&mtl_p_cfg },
 	{ PCI_VDEVICE(INTEL, DID_PTL_H_SKU3), (kernel_ulong_t)&mtl_p_cfg },
+	{ PCI_VDEVICE(INTEL, DID_PTL_H_SKU4), (kernel_ulong_t)&mtl_p_cfg },
+	{ PCI_VDEVICE(INTEL, DID_PTL_H_SKU5), (kernel_ulong_t)&mtl_p_cfg },
+	{ PCI_VDEVICE(INTEL, DID_PTL_H_SKU6), (kernel_ulong_t)&mtl_p_cfg },
+	{ PCI_VDEVICE(INTEL, DID_PTL_H_SKU7), (kernel_ulong_t)&mtl_p_cfg },
+	{ PCI_VDEVICE(INTEL, DID_PTL_H_SKU8), (kernel_ulong_t)&mtl_p_cfg },
+	{ PCI_VDEVICE(INTEL, DID_PTL_H_SKU9), (kernel_ulong_t)&mtl_p_cfg },
+	{ PCI_VDEVICE(INTEL, DID_PTL_H_SKU10), (kernel_ulong_t)&mtl_p_cfg },
+	{ PCI_VDEVICE(INTEL, DID_PTL_H_SKU11), (kernel_ulong_t)&mtl_p_cfg },
+	{ PCI_VDEVICE(INTEL, DID_PTL_H_SKU12), (kernel_ulong_t)&mtl_p_cfg },
+	{ PCI_VDEVICE(INTEL, DID_PTL_H_SKU13), (kernel_ulong_t)&mtl_p_cfg },
 	{ PCI_VDEVICE(INTEL, DID_WCL_SKU1), (kernel_ulong_t)&wcl_cfg },
 	{ },
 };
-- 
2.51.0