From: Sudeep Holla <sudeep.holla@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Rutland <mark.rutland@arm.com>,
Francois Ozog <francois.ozog@linaro.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Jose.Marinho@arm.com,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
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 2/2] firmware: smccc: Add ARCH_SOC_ID support
Date: Fri, 22 May 2020 17:54:22 +0100 [thread overview]
Message-ID: <20200522165422.GA18810@bogus> (raw)
In-Reply-To: <CAK8P3a1t6BrB_Gti138VDRbmaiR_TjwR9d6qMstLBFDWxZ1kjQ@mail.gmail.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
next prev parent reply other threads:[~2020-05-22 16:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-22 12:49 [PATCH 0/2] base: soc: Add JEP106 manufacturer's identification code Sudeep Holla
2020-05-22 12:49 ` [PATCH 1/2] base: soc: Add JEDEC JEP106 manufacturer's identification code attribute Sudeep Holla
2020-05-22 12:49 ` [PATCH 2/2] firmware: smccc: Add ARCH_SOC_ID support Sudeep Holla
2020-05-22 14:46 ` Arnd Bergmann
2020-05-22 16:54 ` Sudeep Holla [this message]
2020-05-22 17:13 ` Sudeep Holla
2020-05-22 18:41 ` Arnd Bergmann
2020-05-23 17:27 ` Sudeep Holla
2020-05-23 19:40 ` Arnd Bergmann
2020-05-28 13:05 ` Jose Marinho
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200522165422.GA18810@bogus \
--to=sudeep.holla@arm.com \
--cc=Jose.Marinho@arm.com \
--cc=arnd@arndb.de \
--cc=francois.ozog@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=harb@amperecomputing.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mark.rutland@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).