From mboxrd@z Thu Jan 1 00:00:00 1970 From: stefan@agner.ch (Stefan Agner) Date: Fri, 17 Apr 2015 00:05:23 +0200 Subject: [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation In-Reply-To: <1429214815.2563.21.camel@collins> References: <1427564371-26039-1-git-send-email-contact@paulk.fr> <1429175421.2483.1.camel@collins> <1429199145.2563.9.camel@collins> <1429208077.2563.14.camel@collins> <97473e9075df185ab3024db70c471f53@agner.ch> <1429214815.2563.21.camel@collins> Message-ID: <6b259907e5f700ca0e49544f34620455@agner.ch> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 2015-04-16 22:06, Paul Kocialkowski wrote: > 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 wrote: >> >> > >> >> > Le jeudi 16 avril 2015 ? 10:23 -0500, Kumar Gala a ?crit : >> >> >>> On Apr 16, 2015, at 9:36 AM, Rob Herring wrote: >> >> >>> >> >> >>> On Thu, Apr 16, 2015 at 4:10 AM, Paul Kocialkowski 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 >> >> >>>>> >> >> >>>>> I think this is a worthwhile standardization. >> >> >>>>> >> >> >>>>> Acked-by: Stefan Agner >> >> >>>> >> >> >>>> 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 >> >> > >> >> > [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. For that ID the soc_id attribute is actually much more appropriate. But if anybody wants to use that as serial-number, fine. I'm not saying we should prohibit that. > 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. That is actually exactly my concern. We (Toradex) are a ARM module provider which populate SoC's of different vendors. However, we would like to keep consistency across modules. If a SoC vendor mandates to use the field for the SoC serial number, we end up with different serial numbers in that field. IMHO, the top level serial-number should be used for the board/device. But if you don't like to define that, it is ok for me. But maybe we could just mention soc_id as a possible alternative for SoC serial numbers in the documentation? -- Stefan From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Agner Subject: Re: [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation Date: Fri, 17 Apr 2015 00:05:23 +0200 Message-ID: <6b259907e5f700ca0e49544f34620455@agner.ch> References: <1427564371-26039-1-git-send-email-contact@paulk.fr> <1429175421.2483.1.camel@collins> <1429199145.2563.9.camel@collins> <1429208077.2563.14.camel@collins> <97473e9075df185ab3024db70c471f53@agner.ch> <1429214815.2563.21.camel@collins> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <1429214815.2563.21.camel@collins> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Paul Kocialkowski Cc: Kumar Gala , Mark Rutland , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Russell King , Pawel Moll , Ian Campbell , Hans De Goede , Rob Herring , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: devicetree@vger.kernel.org On 2015-04-16 22:06, Paul Kocialkowski wrote: > Le jeudi 16 avril 2015 =C3=A0 21:40 +0200, Stefan Agner a =C3=A9crit = : >> On 2015-04-16 20:14, Paul Kocialkowski wrote: >> > Le jeudi 16 avril 2015 =C3=A0 10:53 -0500, Kumar Gala a =C3=A9crit= : >> >> > On Apr 16, 2015, at 10:45 AM, Paul Kocialkowski wrote: >> >> > >> >> > Le jeudi 16 avril 2015 =C3=A0 10:23 -0500, Kumar Gala a =C3=A9c= rit : >> >> >>> On Apr 16, 2015, at 9:36 AM, Rob Herring wrote: >> >> >>> >> >> >>> On Thu, Apr 16, 2015 at 4:10 AM, Paul Kocialkowski wrote: >> >> >>>> Le jeudi 16 avril 2015 =C3=A0 09:56 +0200, Stefan Agner a =C3= =A9crit : >> >> >>>>> On 2015-03-28 18:39, Paul Kocialkowski wrote: >> >> >>>>>> Signed-off-by: Paul Kocialkowski >> >> >>>>> >> >> >>>>> I think this is a worthwhile standardization. >> >> >>>>> >> >> >>>>> Acked-by: Stefan Agner >> >> >>>> >> >> >>>> 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 >> >> > >> >> > [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 labe= ling on >> >> >> a board or case? Is this meant to be used by the kernel at al= l? >> >> > >> >> > 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 ma= de >> >> > available to userspace through cpuinfo. >> >> > >> >> > Now if there is a particular use for this in user-space, it wou= ld 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 (incl= uding 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 somewher= e else. >> >> > In any case, it doesn't really matter and is not up to the kern= el 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 =E2=80=98board=E2=80=99 in the patch, since it could b= e SoC specific, we >> >> should probably clean up the wording a bit. >> > >> > It really doesn't matter where the string comes from, what it cont= ains >> > or whether some SoCs have provisions to generate one. >> > I think board is one the most common words that we can use to desc= ribe >> > 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_i= d, >> see >> Documentation/ABI/testing/sysfs-devices-soc >> >> So I would rather prefer that this is more reserved for device/board >> serial number... >=20 > Again, I don't wish to define what the number represents in the kerne= l. >=20 > It's whatever string the bootloader sends. I know that e.g. on an oma= p3 > device, I'll be using this with the ID bits provided by the SoC (mayb= e > 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 els= e > (e.g. some serial number stored in an external eeprom), it's up to yo= u > to decide and in any case, that will be decided at bootloader stage. =46or that ID the soc_id attribute is actually much more appropriate.=20 But if anybody wants to use that as serial-number, fine. I'm not saying we should prohibit that. > 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 f= or > Allwinner (sunxi) devices, in U-Boot. That is actually exactly my concern. We (Toradex) are a ARM module provider which populate SoC's of different vendors. However, we would like to keep consistency across modules. If a SoC vendor mandates to us= e the field for the SoC serial number, we end up with different serial numbers in that field. IMHO, the top level serial-number should be used for the board/device. But if you don't like to define that, it is ok for me. But maybe we could just mention soc_id as a possible alternative for SoC serial numbers in the documentation? -- Stefan -- To unsubscribe from this list: send the line "unsubscribe devicetree" i= n the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html