lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ