[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20251009155752.773732-16-sashal@kernel.org>
Date: Thu, 9 Oct 2025 11:54:42 -0400
From: Sasha Levin <sashal@...nel.org>
To: patches@...ts.linux.dev,
stable@...r.kernel.org
Cc: Bryan Brattlof <bb@...com>,
Nishanth Menon <nm@...com>,
Sasha Levin <sashal@...nel.org>,
linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org
Subject: [PATCH AUTOSEL 6.17-6.16] soc: ti: k3-socinfo: Add information for AM62L SR1.1
From: Bryan Brattlof <bb@...com>
[ Upstream commit 037e496038f6e4cfb3642a0ffc2db19838d564dd ]
The second silicon revision for the AM62L was mainly a ROM revision
and therefore this silicon revision is labeled SR1.1
Add a new decode array to properly identify this revision as SR1.1
Signed-off-by: Bryan Brattlof <bb@...com>
Link: https://patch.msgid.link/20250908-62l-chipid-v1-1-9c7194148140@ti.com
Signed-off-by: Nishanth Menon <nm@...com>
Signed-off-by: Sasha Levin <sashal@...nel.org>
---
LLM Generated explanations, may be completely bogus:
YES
- The patch teaches `k3_chipinfo_variant_to_sr()` how to decode AM62Lx
silicon variant 0/1 into the correct revision strings by adding
`am62lx_rev_string_map[] = {"1.0","1.1"}` and a dedicated `case
JTAG_ID_PARTNO_AM62LX` (drivers/soc/ti/k3-socinfo.c:65,
drivers/soc/ti/k3-socinfo.c:92). Without it, the existing default
branch (drivers/soc/ti/k3-socinfo.c:98) blindly prints `SR<x>.0`, so
the new SR1.1 silicon shows up as “SR2.0”—a clear mis-identification
bug.
- That revision string is what gets registered in
`/sys/devices/soc0/revision` and is what subsystem code keys on via
`soc_device_match()`. We already rely on that mechanism for other K3
parts (e.g. the AM62Px SR1.1 quirk in
drivers/mmc/host/sdhci_am654.c:896), so shipping incorrect data
prevents present and future AM62Lx-specific fixes or workarounds from
triggering and can mislead userspace diagnostics.
- The change is tightly scoped to string decoding, has no architectural
side effects, and mirrors the precedent set for J721E SR2.0 support
(drivers/soc/ti/k3-socinfo.c:65-103 history). Risk is minimal while
correcting real user-visible behaviour for existing hardware.
- Ensure the earlier ID-enabling commit (`soc: ti: k3-socinfo: Add JTAG
ID for AM62LX`, c62bc66d53de) is in the target stable branch; with
that prerequisite met, this bug-fix-style decode update is safe to
pick up.
drivers/soc/ti/k3-socinfo.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/soc/ti/k3-socinfo.c b/drivers/soc/ti/k3-socinfo.c
index d716be113c84f..50c170a995f90 100644
--- a/drivers/soc/ti/k3-socinfo.c
+++ b/drivers/soc/ti/k3-socinfo.c
@@ -66,6 +66,10 @@ static const char * const j721e_rev_string_map[] = {
"1.0", "1.1", "2.0",
};
+static const char * const am62lx_rev_string_map[] = {
+ "1.0", "1.1",
+};
+
static int
k3_chipinfo_partno_to_names(unsigned int partno,
struct soc_device_attribute *soc_dev_attr)
@@ -92,6 +96,12 @@ k3_chipinfo_variant_to_sr(unsigned int partno, unsigned int variant,
soc_dev_attr->revision = kasprintf(GFP_KERNEL, "SR%s",
j721e_rev_string_map[variant]);
break;
+ case JTAG_ID_PARTNO_AM62LX:
+ if (variant >= ARRAY_SIZE(am62lx_rev_string_map))
+ goto err_unknown_variant;
+ soc_dev_attr->revision = kasprintf(GFP_KERNEL, "SR%s",
+ am62lx_rev_string_map[variant]);
+ break;
default:
variant++;
soc_dev_attr->revision = kasprintf(GFP_KERNEL, "SR%x.0",
--
2.51.0
Powered by blists - more mailing lists