Re: [PATCH v4 7/7] firmware: smccc: Add ARCH_SOC_ID support

From: Sudeep Holla <sudeep.holla@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Steven Price <steven.price@arm.com>,
	harb@amperecomputing.com, Sudeep Holla <sudeep.holla@arm.com>,
	Will Deacon <will@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 7/7] firmware: smccc: Add ARCH_SOC_ID support
Date: Thu, 21 May 2020 08:07:38 +0100	[thread overview]
Message-ID: <20200521061228.GA1131@bogus> (raw)
In-Reply-To: <CAK8P3a3bOEL5wYFc1Fjg1vAT51NumzO0iUSroHQLSUt8WpZL7g@mail.gmail.com>

On Wed, May 20, 2020 at 11:51:47PM +0200, Arnd Bergmann wrote:
> On Mon, May 18, 2020 at 1:55 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
> >
> > On Mon, May 18, 2020 at 11:30:21AM +0200, Arnd Bergmann wrote:
> > > On Mon, May 18, 2020 at 11:12 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> > >
> > > > +static ssize_t
> > > > +jep106_cont_bank_code_show(struct device *dev, struct device_attribute *attr,
> > > > +                          char *buf)
> > > > +{
> > > > +       return sprintf(buf, "0x%02x\n", JEP106_BANK_CONT_CODE(soc_id_version));
> > > > +}
> > > > +
> > > > +static DEVICE_ATTR_RO(jep106_cont_bank_code);
> > > > +
> > > > +static ssize_t
> > > > +jep106_identification_code_show(struct device *dev,
> > > > +                               struct device_attribute *attr, char *buf)
> > > > +{
> > > > +       return sprintf(buf, "0x%02x\n", JEP106_ID_CODE(soc_id_version));
> > > > +}
> > >
> > > I think we should try hard to avoid nonstandard attributes for the soc device.
> > >
> >
> > I agree with that in general but this is bit different for below mentioned
> > reason.
> >
> > > Did you run into a problem with finding one of the existing attributes
> > > that can be used to hold the fields?
> > >
> >
> > Not really! The 2 JEP106 codes can be used to derive the manufacturer which
> > could match one of the existing attributes. However doing so might require
> > importing the huge JEP106 list as it needs to be maintained and updated
> > in the kernel. Also that approach will have the compatibility issue and
> > that is the reason for introducing these attributes representing raw
> > values for userspace.
>
> I was thinking they codes could just be part of the normal strings rather
> than get translated. Can you give an example what they would look like
> with your current code?
>

Sure. Couple of example:
Cont Code   Identifier       Manufacturer
0		0x1		AMD
0		0x0e		Freescale (Motorola)
4		0x3b		ARM

I initially thought of value like "jep106-0-1" for AMD "jep-4-3b" for
ARM,..etc for the standard attribute family or machine. But I was not
convinced fully on that approach as it will be deviation from normal
values in those attributes. Further this represents the vendor name
rather than the family or machine.

> If  you think they should be standard attributes, how about adding them
> to the default list, and hardcoding them in the other soc device drivers
> based on the information we have available there?
>

That may be possible, I can take a look at the existing drivers and
check if that is feasible(which I think should be). Thanks for that
suggestion.

--
Regards,
Sudeep

[1] https://github.com/skottler/memtest86/blob/master/jedec_id.h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel