From: Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org>
To: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
Hans De Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation
Date: Thu, 16 Apr 2015 22:06:55 +0200 [thread overview]
Message-ID: <1429214815.2563.21.camel@collins> (raw)
In-Reply-To: <97473e9075df185ab3024db70c471f53-XLVq0VzYD2Y@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4030 bytes --]
Le jeudi 16 avril 2015 à 21:40 +0200, Stefan Agner a écrit :
> On 2015-04-16 20:14, Paul Kocialkowski wrote:
> > Le jeudi 16 avril 2015 à 10:53 -0500, Kumar Gala a écrit :
> >> > On Apr 16, 2015, at 10:45 AM, Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org> wrote:
> >> >
> >> > Le jeudi 16 avril 2015 à 10:23 -0500, Kumar Gala a écrit :
> >> >>> On Apr 16, 2015, at 9:36 AM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >>>
> >> >>> On Thu, Apr 16, 2015 at 4:10 AM, Paul Kocialkowski <contact@paulk.fr> wrote:
> >> >>>> Le jeudi 16 avril 2015 à 09:56 +0200, Stefan Agner a écrit :
> >> >>>>> On 2015-03-28 18:39, Paul Kocialkowski wrote:
> >> >>>>>> Signed-off-by: Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org>
> >> >>>>>
> >> >>>>> I think this is a worthwhile standardization.
> >> >>>>>
> >> >>>>> Acked-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
> >> >>>>
> >> >>>> Thanks! I should also add a commit message in v2 mentioning that this is
> >> >>>> already used in open firmware and reported by lshw.
> >> >>>
> >> >>> With that,
> >> >>>
> >> >>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >> >
> >> > [snip]
> >> >
> >> >> I feel like this is a little lite either in the doc or commit message.
> >> >> Is the string completely arbitrary? Is it meant to match labeling on
> >> >> a board or case? Is this meant to be used by the kernel at all?
> >> >
> >> > I guess it doesn't really matter what it is, as long as it's a string.
> >> > The kernel does not suggest any use for it either, it's just made
> >> > available to userspace through cpuinfo.
> >> >
> >> > Now if there is a particular use for this in user-space, it would have
> >> > to match some standards. For instance, it Android, ro.serialno is
> >> > usually a 16-bytes (plus one null byte) representation of a 64 bit
> >> > number. For USB, I recall it is usually a 32 bytes string (including the
> >> > null byte), but may be extended to more.
> >> >
> >> > What the string actually represents depends and some SOCs have serial
> >> > number bytes (I know that omap and sunxi have some for instance, that
> >> > are usually used) while other devices may take it from somewhere else.
> >> > In any case, it doesn't really matter and is not up to the kernel anyway
> >> > since it is just passed through from the bootloader.
> >> >
> >> > Thus, I don't think it's very relevant to mention it in either the
> >> > documentation or the commit message.
> >>
> >> So you say ‘board’ in the patch, since it could be SoC specific, we
> >> should probably clean up the wording a bit.
> >
> > It really doesn't matter where the string comes from, what it contains
> > or whether some SoCs have provisions to generate one.
> > I think board is one the most common words that we can use to describe
> > devices. "devices" is also fine, I could go with it if you prefer, but I
> > don't really see what it changes.
>
> There is already something related for SoC's in SoC bus called soc_id,
> see
> Documentation/ABI/testing/sysfs-devices-soc
>
> So I would rather prefer that this is more reserved for device/board
> serial number...
Again, I don't wish to define what the number represents in the kernel.
It's whatever string the bootloader sends. I know that e.g. on an omap3
device, I'll be using this with the ID bits provided by the SoC (maybe
only part of them, there are 128 bits available and I like to have 64
bit serial numbers). But if you want your device to use something else
(e.g. some serial number stored in an external eeprom), it's up to you
to decide and in any case, that will be decided at bootloader stage.
Perhaps it would make sense to provide consistency for this among a
particular family of devices (say, devices from the same manufacture or
devices using the same SoC). We have already set up such a standard for
Allwinner (sunxi) devices, in U-Boot.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-04-16 20:06 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-28 17:39 [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation Paul Kocialkowski
[not found] ` <1427564371-26039-1-git-send-email-contact-W9ppeneeCTY@public.gmane.org>
2015-03-28 17:39 ` [PATCH 2/2] arch: arm: Show the serial number from devicetree in cpuinfo Paul Kocialkowski
[not found] ` <1427564371-26039-2-git-send-email-contact-W9ppeneeCTY@public.gmane.org>
2015-04-16 9:46 ` Russell King - ARM Linux
[not found] ` <20150416094623.GX12732-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2015-04-16 10:23 ` Paul Kocialkowski
2015-04-16 14:37 ` Rob Herring
2015-04-16 16:05 ` Russell King - ARM Linux
2015-04-14 14:31 ` [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation Paul Kocialkowski
2015-04-16 7:56 ` Stefan Agner
[not found] ` <f6f4f862c78fa626e7f94bde51eec5b1-XLVq0VzYD2Y@public.gmane.org>
2015-04-16 9:10 ` Paul Kocialkowski
2015-04-16 14:36 ` Rob Herring
[not found] ` <CAL_JsqKdHQZL5Z6hKgquKihFykX0ZiCDQfeHOfOZWOh2NMg4Rw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-04-16 15:23 ` Kumar Gala
[not found] ` <CFEF8F54-7A3E-482C-B295-6A6BC5D837C8-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2015-04-16 15:45 ` Paul Kocialkowski
2015-04-16 15:53 ` Kumar Gala
[not found] ` <F4D05489-ACF0-44BB-AEC7-7E8FB83FAE4C-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2015-04-16 18:14 ` Paul Kocialkowski
2015-04-16 18:54 ` Kumar Gala
[not found] ` <B1128C28-AC17-47F6-A64A-FD3197112751-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2015-04-16 19:15 ` Paul Kocialkowski
2015-04-16 19:40 ` Stefan Agner
[not found] ` <97473e9075df185ab3024db70c471f53-XLVq0VzYD2Y@public.gmane.org>
2015-04-16 20:06 ` Paul Kocialkowski [this message]
2015-04-16 22:05 ` Stefan Agner
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=1429214815.2563.21.camel@collins \
--to=contact-w9ppeneecty@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=pawel.moll-5wv7dgnIgG8@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=stefan-XLVq0VzYD2Y@public.gmane.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).