Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3;
Date:   Wed, 13 Sep 2023 06:28:23 -0500
From:   Nishanth Menon <nm@ti.com>
To:     Neha Malcom Francis <n-francis@ti.com>
CC:     Thejasvi Konduru <t-konduru@ti.com>,
        <linux-kernel@vger.kernel.org>,
        <linux-arm-kernel@lists.infradead.org>,
        Santosh Shilimkar <ssantosh@kernel.org>,
        Tero Kristo <t-kristo@ti.com>,
        Grygorii Strashko <grygorii.strashko@ti.com>,
        Lokesh Vutla <lokeshvutla@ti.com>,
        Apurva Nandan <a-nandan@ti.com>, Udit Kumar <u-kumar1@ti.com>
Subject: Re: [PATCH] soc: ti: k3-socinfo: Fix the silicon revision misprint
Message-ID: <20230913112823.prv5dmasvv4nt6qv@nuclear>
References: <20230607080349.26671-1-t-konduru@ti.com>
 <20230607104304.iengykppptr3fxe6@reflected>
 <d50e7612-0b17-0f65-872f-90e08bed9948@ti.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <d50e7612-0b17-0f65-872f-90e08bed9948@ti.com>
Precedence: bulk

On 12:07-20230912, Neha Malcom Francis wrote:

[...]

> > > +void
> > > +k3_chipinfo_silicon_rev(unsigned int variant,
> > > +			struct soc_device_attribute *soc_dev_attr)
> > > +{
> > > +	const char *family_name = soc_dev_attr->family;
> > > +	int j721e_lookup_arr_size = ARRAY_SIZE(soc_revision_j721e);
> > > +
> > > +	if (!strcmp(family_name, "J721E") && variant < j721e_lookup_arr_size) {
> > > +		soc_dev_attr->revision = kasprintf(GFP_KERNEL, "SR%s", soc_revision_j721e[variant]);
> > > +	} else {
> > > +		variant++;
> > > +		soc_dev_attr->revision = kasprintf(GFP_KERNEL, "SR%x.0", variant);
> > > +	}
> > 
> > I am not comfortable with if else here. Why not extend k3_soc_id
> > structure to include the variant LuT? Are there exceptions to this rule
> > (Say AM65x?), those would make sense to handle with a compare against
> > the partno?
> > 
> 
> Trying to revive this patch, I see what you are saying is similar to the way
> detection has already been implemented in U-Boot (drivers/soc/soc_ti_k3.c)
> if I'm not mistaken.

Yes.

> 
> But I can't find any existing exception to this "family --> version" rule
> that forces us to use "partno --> version". Checked through all AM65x device
> TRMs available in ti.com; all seem to use common partno. So maybe I am not
> on the same page, did you mean something else?

https://www.ti.com/lit/ug/spruid7e/spruid7e.pdf
CTRLMMR_WKUP_JTAGID:: VARIANT field: SR2.0: 1h SR1.0: 0h
Latest data sheet: https://www.ti.com/lit/ds/symlink/am6548.pdf
indicates SR 2.1

How is this detected?

What I indicated is a LUT table similar to
https://git.ti.com/cgit/k3conf/k3conf/tree/common/socinfo.c#n382

This allows a switch statement to handle custom SR handling schemes or
use LUT with variants that use VARIANT field to handle things properly.

[...]
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D