linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: contact@paulk.fr (Paul Kocialkowski)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation
Date: Thu, 16 Apr 2015 17:45:45 +0200	[thread overview]
Message-ID: <1429199145.2563.9.camel@collins> (raw)
In-Reply-To: <CFEF8F54-7A3E-482C-B295-6A6BC5D837C8@codeaurora.org>

Le jeudi 16 avril 2015 ? 10:23 -0500, Kumar Gala a ?crit :
> > On Apr 16, 2015, at 9:36 AM, Rob Herring <robherring2@gmail.com> 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@paulk.fr>
> >>> 
> >>> I think this is a worthwhile standardization.
> >>> 
> >>> Acked-by: Stefan Agner <stefan@agner.ch>
> >> 
> >> 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@kernel.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.

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150416/4fa14dc4/attachment.sig>

  reply	other threads:[~2015-04-16 15:45 UTC|newest]

Thread overview: 18+ 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
2015-03-28 17:39 ` [PATCH 2/2] arch: arm: Show the serial number from devicetree in cpuinfo Paul Kocialkowski
2015-04-16  9:46   ` Russell King - ARM Linux
2015-04-16 10:23     ` Paul Kocialkowski
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
2015-04-16  9:10   ` Paul Kocialkowski
2015-04-16 14:36     ` Rob Herring
2015-04-16 15:23       ` Kumar Gala
2015-04-16 15:45         ` Paul Kocialkowski [this message]
2015-04-16 15:53           ` Kumar Gala
2015-04-16 18:14             ` Paul Kocialkowski
2015-04-16 18:54               ` Kumar Gala
2015-04-16 19:15                 ` Paul Kocialkowski
2015-04-16 19:40               ` Stefan Agner
2015-04-16 20:06                 ` Paul Kocialkowski
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=1429199145.2563.9.camel@collins \
    --to=contact@paulk.fr \
    --cc=linux-arm-kernel@lists.infradead.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).