Le jeudi 16 avril 2015 à 13:54 -0500, Kumar Gala a écrit : > > On Apr 16, 2015, at 1:14 PM, Paul Kocialkowski <contact@xxxxxxxx> wrote: > > > > Le jeudi 16 avril 2015 à 10:53 -0500, Kumar Gala a écrit : > >>> On Apr 16, 2015, at 10:45 AM, Paul Kocialkowski <contact@xxxxxxxx> wrote: > >>> > >>> Le jeudi 16 avril 2015 à 10:23 -0500, Kumar Gala a écrit : > >>>>> On Apr 16, 2015, at 9:36 AM, Rob Herring <robherring2@xxxxxxxxx> wrote: > >>>>> > >>>>> On Thu, Apr 16, 2015 at 4:10 AM, Paul Kocialkowski <contact@xxxxxxxx> 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@xxxxxxxx> > >>>>>>> > >>>>>>> I think this is a worthwhile standardization. > >>>>>>> > >>>>>>> Acked-by: Stefan Agner <stefan@xxxxxxxx> > >>>>>> > >>>>>> 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@xxxxxxxxxx> > >>> > >>> [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
Attachment:
signature.asc
Description: This is a digitally signed message part
