linux-kernel - Re: [PATCH 2/2] soc: ti: k3-socinfo: Add support for AM62P variants via NVMEM

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d04fbaeb-1801-4987-bada-5f99018aa2bd@ti.com>
Date: Fri, 6 Feb 2026 10:50:19 -0600
From: Andrew Davis <afd@...com>
To: Judith Mendez <jm@...com>, Nishanth Menon <nm@...com>, Vignesh Raghavendra
	<vigneshr@...com>, Tero Kristo <kristo@...nel.org>, Rob Herring
	<robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
	<conor+dt@...nel.org>, Santosh Shilimkar <ssantosh@...nel.org>
CC: <linux-arm-kernel@...ts.infradead.org>, <devicetree@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] soc: ti: k3-socinfo: Add support for AM62P variants
 via NVMEM

On 2/5/26 6:38 PM, Judith Mendez wrote:
> Andrew,
> 
> On 2/4/26 3:54 PM, Andrew Davis wrote:
>> On 2/4/26 3:37 PM, Judith Mendez wrote:
>>> Add support for detecting AM62P silicon revisions.
>>>
>>> On AM62P, silicon revision is discovered with GP_SW1 register instead
>>> of JTAGID register. Use the NVMEM framework to read GP_SW1 from the
>>> gpsw-efuse nvmem provider to determine SoC revision.
>>>
>>> Signed-off-by: Judith Mendez <jm@...com>
>>> ---
>>>   drivers/soc/ti/k3-socinfo.c | 48 ++++++++++++++++++++++++++++++++++---
>>>   1 file changed, 45 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/soc/ti/k3-socinfo.c b/drivers/soc/ti/k3-socinfo.c
>>> index 42275cb5ba1c8..4b6947a9ceb4d 100644
>>> --- a/drivers/soc/ti/k3-socinfo.c
>>> +++ b/drivers/soc/ti/k3-socinfo.c
>>> @@ -6,6 +6,7 @@
>>>    */
>>>   #include <linux/mfd/syscon.h>
>>> +#include <linux/nvmem-consumer.h>
>>>   #include <linux/of.h>
>>>   #include <linux/of_address.h>
>>>   #include <linux/regmap.h>
>>> @@ -25,6 +26,9 @@
>>>   #define CTRLMMR_WKUP_JTAGID_VARIANT_SHIFT    (28)
>>>   #define CTRLMMR_WKUP_JTAGID_VARIANT_MASK    GENMASK(31, 28)
>>> +#define GP_SW1_VALID_BIT            BIT(4)
>>> +#define GP_SW1_ADR_MASK            GENMASK(3, 0)
>>> +
>>>   #define CTRLMMR_WKUP_JTAGID_PARTNO_SHIFT    (12)
>>>   #define CTRLMMR_WKUP_JTAGID_PARTNO_MASK        GENMASK(27, 12)
>>> @@ -70,6 +74,29 @@ static const char * const am62lx_rev_string_map[] = {
>>>       "1.0", "1.1",
>>>   };
>>> +static const char * const am62p_gpsw_rev_string_map[] = {
>>> +    "1.0", "1.1", "1.2",
>>> +};
>>> +
>>> +static int
>>> +k3_chipinfo_get_gpsw_variant(struct platform_device *pdev)
>>> +{
>>> +    struct device *dev = &pdev->dev;
>>> +    u32 gpsw_val, adr_val = 0;
>>> +    int ret;
>>> +
>>> +    ret = nvmem_cell_read_u32(dev, "gpsw1", &gpsw_val);
>>> +    if (ret)
>>> +        return ret;
>>> +
>>> +    if (!(gpsw_val & GP_SW1_VALID_BIT))
>>> +        return 0;
>>
>> Return -1 here so you will get the warning message about setting default SR1.0.
> 
> Actually, thinking about this some more... If valid bit is zero, that
> means that we have detected SR1.0.

To me a valid bit set to zero means the register is not valid.. If you are
saying that bit actually signals SR1.0 then that bit is not well named.

Although if the whole register is simply all zeros for SR1.0 then do you
actually need this check at all? When you do extract the revision from
the lowest bits (gpsw_val & GP_SW1_ADR_MASK) the result will also be 0,
which is the SR1.0 value anyway.

Andrew

> Id rather return zero instead of
> printing an error to the user and overwriting with zero. What do you
> think?
> 
> ~ Judith