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

[Sudeep Holla <sudeep.holla@arm.com>]

(+ Jose (SMCCC Spec author))

On Fri, May 22, 2020 at 04:46:12PM +0200, Arnd Bergmann wrote:
> On Fri, May 22, 2020 at 2:50 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
> > +
> > +       soc_id_rev = res.a0;
> > +
> > +       soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
> > +       if (!soc_dev_attr)
> > +               return -ENOMEM;
> > +
> > +       sprintf(soc_id_str, "0x%04x", IMP_DEF_SOC_ID(soc_id_version));
> > +       sprintf(soc_id_rev_str, "0x%08x", soc_id_rev);
> > +       sprintf(soc_id_jep106_id_str, "0x%02x%02x",
> > +               JEP106_BANK_CONT_CODE(soc_id_version),
> > +               JEP106_ID_CODE(soc_id_version));
> > +
> > +       soc_dev_attr->soc_id = soc_id_str;
> > +       soc_dev_attr->revision = soc_id_rev_str;
> > +       soc_dev_attr->jep106_id = soc_id_jep106_id_str;
>
> Ok, let me try to understand how this maps the 64-bit ID into the
> six strings in user space:
>
> For a chip that identifies as
>
> JEP106_BANK_CONT_CODE = 12
> JEP106_ID_CODE = 34
> IMP_DEF_SOC_ID = 5678
> soc_id_rev = 9abcdef0
>
> the normal sysfs attributes contain these strings:
>
> machine = ""
> family = ""
> revision = "0x9abcdef0
> serial_number = ""
> soc_id = "0x5678"
>
> and the new attribute is
>
> jep106_identification_code = "0x1234"
>
> This still looks like a rather poorly designed interface to me, with a
> number of downsides:
>
> - Nothing in those strings identifies the numbers as using jep106
>   numbers rather than some something else that might use strings
>   with hexadecimal numbers.
>

Not sure if I understand your concerns completely here.

Anyways I wanted to clarify that the jep106 encoding is applicable only
for manufacturer's id and not for SoC ID or revision. Not sure if that
changes anything about your concerns.

> - I think we should have something unique in "family" just because
>   existing scripts can use that as the primary indentifier
>

I agree with your idea of combining attributes, not sure exactly which
ones yet.

> - It seems odd that there is no way to read the serial number through
>   the same interface and publish it the usual way.

Valid concern and I will pass this to interface authors.

>   Francois Ozog
>   recently asked for a generic way to find out a serial number for
>   inventory management, and this would be the obvious place to have it.

Agreed, but not sure what author(s) have to say. I have cc-ed one of them.

>   It can of course be added later when the next revision of the spec
>   is there, it just seems like a surprising omission.
>

Yes, definitely. Good to get feedback.

> How about making the contents:
>
> machine = "" /* could be a future addition, but board specific */
> family = "jep106:1234"

But this just indicates manufacturer id and nothing related to SoC family.
If it is jep106:043b, all it indicates is Arm Ltd and assigning it to
family doesn't sound right to me.

I had requests for both of the above during the design of interface but
I was told vendors were happy with the interface. I will let the authors
speak about that.

> revision = "0x9abcdef0
> serial_number = "0xfedcba987654321" /* to be implemented later */

Sure.

> soc_id = "jep106:1234:5678" /* duplicates family but makes it unique*/

Not sure again.
>
> That would work without any new properties, dropping the other patch,
> and be easier to use for identification from user space.
>

OK, I agree on ease part. But for me, we don't have any property in the
list to indicate the vendor/manufacturer's name. I don't see issue adding
one, name can be fixed as jep106_identification_code is too specific.

How about manufacturer with the value in the format "jep106:1234" if
it is not normal string but jep106 encoding.

--
Regards,
Sudeep

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