From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2722E1E1C11; Sat, 14 Feb 2026 00:58:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771030719; cv=none; b=GfhoBd18sMIptrVF4NVmnMIwMKHp/FDfmgcEuZ2kKbU3sZXdxz2102lnBoEvnYt6mmVmhRcpoagMFh8IQzdKIN15clmmdChWocIZ/RwpBtUzmsHSOY/gi1LVKToWnEAivc8Lj58+ecD0jxT+RaJHuIFxH0XblW+CST67yMX0NQE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771030719; c=relaxed/simple; bh=SI5tPEIi2XpojYmcpwPvxI6NXx7gMV9FgZ80i7WZjxQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XXRHfNRn8ngm819LzWfZDuXRx02DG86lXRnm7vZpkpiRg008HcnINI2JlJeihAelNX0I/C4vNVPCI+Moi1J13CvUYaRDfQH8aUqA+ZXpmDP2gnEjVXCXHyh8JHT5ihn6Fi+MqeIdvk94PU3e0WcZzFuL53elwsCe0lxfBaNA9HI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=c6ZqmCHg; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="c6ZqmCHg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 00628C16AAE; Sat, 14 Feb 2026 00:58:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771030718; bh=SI5tPEIi2XpojYmcpwPvxI6NXx7gMV9FgZ80i7WZjxQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=c6ZqmCHgiSDkzRkPHEc26nS4WHfucuvsAXd3BNQcCrZxlOIgaeHvLMia2U9qMBTqU MV1vqBuUvpKHWz2pZTyqYtNN+Wj9EjlpmOGH0NZJhSEWqsey0pMz3WPQa8GnIPr1DR vhJKiRfW4xcMiPSTj/eIMRLKxDkwdq2OuFrgcSxJfTDq77YgOLVBA2ews0oflZwKff MIHduld//GLG/AnLFwCiMhd1dCNQO83vd6wyXWEuYKzyxcOmV+10d2Vr/YDj8oQj54 OjBhyinYaq52tKwEMCUgJIIreuqX27vD3VWw9RbDpST8VqQ5TeNgy9wCZMJw7ha+gk WRMR6rSmNBkAQ== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Qiuxu Zhuo , Tony Luck , Jianfeng Gao , Sasha Levin , bp@alien8.de, linux-edac@vger.kernel.org Subject: [PATCH AUTOSEL 6.19-6.18] EDAC/igen6: Add two Intel Amston Lake SoCs support Date: Fri, 13 Feb 2026 19:58:12 -0500 Message-ID: <20260214005825.3665084-6-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260214005825.3665084-1-sashal@kernel.org> References: <20260214005825.3665084-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-edac@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.19 Content-Transfer-Encoding: 8bit From: Qiuxu Zhuo [ 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 Signed-off-by: Tony Luck Tested-by: Jianfeng Gao Link: https://patch.msgid.link/20251124065457.3630949-2-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin --- 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