[PATCH 1/2] Documentation: devicetree: root node serial-number property documentation

[Paul Kocialkowski]

Le jeudi 16 avril 2015 à 13:54 -0500, Kumar Gala a écrit :
> > On Apr 16, 2015, at 1:14 PM, Paul Kocialkowski <contact at paulk.fr> wrote:
> > 
> > Le jeudi 16 avril 2015 à 10:53 -0500, Kumar Gala a écrit :
> >>> On Apr 16, 2015, at 10:45 AM, Paul Kocialkowski <contact at paulk.fr> wrote:
> >>> 
> >>> Le jeudi 16 avril 2015 à 10:23 -0500, Kumar Gala a écrit :
> >>>>> On Apr 16, 2015, at 9:36 AM, Rob Herring <robherring2 at gmail.com> wrote:
> >>>>> 
> >>>>> On Thu, Apr 16, 2015 at 4:10 AM, Paul Kocialkowski <contact at 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 at paulk.fr>
> >>>>>>> 
> >>>>>>> I think this is a worthwhile standardization.
> >>>>>>> 
> >>>>>>> Acked-by: Stefan Agner <stefan at 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 at 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.
> >> 
> >> 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.
> 
> Lets go with device instead of board.
> 
> > 
> >> I’m just saying when someone reads this 6 months or a year later and
> >> tries to figure out what the purpose of the property is they don’t
> >> really have enough info.  Putting some examples in the commit message
> >> of what possibly usages is I think a reasonable thing.
> > 
> > Okay, that would make sense. Still, the purpose of this is to pass the
> > serial number string from the bootloader to userspace. All of the
> > discussion about where to grab the serial from and what it should look
> > like is not relevant to the kernel. Instead, it's up to the bootloader
> > that is in charge of generating the serial string, so the discussion
> > should happen there.
> 
> Again, I’ve got no issues with the property and its purpose to be used
> by user space, just saying we need to convey more of the intent via
> commit message or updating the doc.

Okay so I'll go with "device" and mention a few use cases and what the
serial numbers look like for those. Is that satisfying to you?

> - k

-------------- 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/840d6ef4/attachment.sig>