RE: [PATCH 2/2] firmware: smccc: Add ARCH_SOC_ID support

From: Jose Marinho <Jose.Marinho@arm.com>
To: Arnd Bergmann <arnd@arndb.de>, Sudeep Holla <Sudeep.Holla@arm.com>
Cc: Mark Rutland <Mark.Rutland@arm.com>,
	Francois Ozog <francois.ozog@linaro.org>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Harb Abdulhamid \(harb@amperecomputing.com\)"
	<harb@amperecomputing.com>, nd <nd@arm.com>,
	Will Deacon <will@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: RE: [PATCH 2/2] firmware: smccc: Add ARCH_SOC_ID support
Date: Thu, 28 May 2020 13:05:16 +0000	[thread overview]
Message-ID: <AM6PR08MB4311A937BE505BAE0CDF9106888E0@AM6PR08MB4311.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <CAK8P3a1+jjgOyJcRQm60RULjwtvWzvYK1QwrjOX_aRAbDGKuJg@mail.gmail.com>

> On Sat, May 23, 2020 at 7:27 PM Sudeep Holla <sudeep.holla@arm.com>
> wrote:
> > On Fri, May 22, 2020 at 08:41:59PM +0200, Arnd Bergmann wrote:
> > > On Fri, May 22, 2020 at 6:54 PM Sudeep Holla <sudeep.holla@arm.com>
> wrote:
> >
> > > jep106:5678 (the IMP_DEF_SOC_ID field in my example) would probably
> > > be sufficient to not conflict with a another soc_device driver, but
> > > is quite likely to clash with an ID used by another manufacturer.
> > >
> >
> > IIUC, you are fine with "jep106:1234:5678" where 1234 is jep106
> manufacture
> > id code and 5678 is soc_id as it may avoid all the conflicts across
> > the manufacture namespaces.
> 
> I think either jep106:5678 or jep106:1234:5678 (or some variation with
> different field separators if you prefer) would be fine here.
> 
> > > jep106:1234 (the manufacturer ID) in turn seems too broad from
> > > the soc_id field, as that would include every chip made by one
> > > company.
> > >
> >
> > I understand, and IIUC you prefer this to be embedded with soc_id
> > especially to avoid namespace conflicts which makes sense.
> >
> > Thanks for all the discussion and valuable inputs. I am now bit nervous
> > to add SoC info from SMCCC ARCH_SOC_ID to sysfs yet as we need more
> info
> > especially "machine" and "serial_number" for elsewhere(OEM firmware
> mostly
> > from DT or ACPI).
> 
> I probably wouldn't mix those in with the same driver. If machine and
> serial_number have no smccc interface, then they should be left out,
> but there could be a separate soc_device that gets that information
> by other means, usually using one of the existing hardware id register
> drivers.
> 
> > TBH, the mix might be bit of a mess as there are soc drivers that rely
> > on DT completely today. Anyways, this SOC_ID can be added as library that
> > can be used by a *generic* soc driver once we define a standard way to
> > fetch other information("machine" and "serial_number"). I am happy to
> > get suggestions on that front especially from you and Francois as you
> > have got some context already.
> 
> Well, I suppose we could have the entire data from the smccc interface
> in a central place somewhere, such as (to stay with my example)
> "1234:5678:9abcdef0" in an attribute of any soc_device driver that
> adds a call to a library function for the jep106 ID, or possibly in
> /sys/firmware or even a field added to /proc/cpuinfo.

I think this is a great way to expose the SoC ID info. It's important to have the SoC ID as a whole in a sysfs (or somewhere where it's easy to obtain and parse from user-space).
The information provided by SoC ID should be listed in this form jep106:1234:5678, that is jep106:<manufacturer ID>:<SoC ID> .

Regards,

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