Messages in this thread | | | From | Jose Marinho <> | Subject | RE: [PATCH 2/2] firmware: smccc: Add ARCH_SOC_ID support | Date | Thu, 28 May 2020 13:05:16 +0000 |
| |
> 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
| |