From: Hans de Goede <hdegoede@redhat.com> To: Paul Kocialkowski <contact@paulk.fr>, Rob Herring <robherring2@gmail.com> Cc: devicetree <devicetree@vger.kernel.org>, Ian Campbell <ijc@hellion.org.uk>, U-Boot <u-boot@lists.denx.de> Subject: Re: serial atag tag in devicetree ? Date: Thu, 26 Mar 2015 09:53:58 +0100 [thread overview] Message-ID: <5513C926.1010708@redhat.com> (raw) In-Reply-To: <1427322910.26627.15.camel@collins> Hi, On 25-03-15 23:35, Paul Kocialkowski wrote: > Le mardi 24 mars 2015 à 09:01 +0100, Hans de Goede a écrit : >> Hi, >> >> On 24-03-15 00:12, Rob Herring wrote: >>> On Mon, Mar 23, 2015 at 6:30 AM, Hans de Goede <hdegoede@redhat.com> wrote: >>>> Hi, >>>> >>>> >>>> On 22-03-15 22:01, Rob Herring wrote: >> >> <snip> >> >>>>> There is already "serial-number" (a string) which exists for >>>>> OpenFirmware. Also, "copyright" corresponds to vendor/manufacturer >>>>> string. Both of these are supported by lshw already. >>>> >>>> >>>> Ok, so if I understand you correctly then you're saying that we >>>> should set a "serial-number" string property at the dt root level >>>> and that this may contain pretty much anything, e.g. in the >>>> sunxi case the full 128 bit SID in hex. >>> >>> Right. >>> >>>> Is the use of the "serial-number" string property already documented >>>> somewhere? If not I'll submit a kernel patch to document it. >>> >>> Not that I'm aware of. It is something that predates our documentation >>> requirements. It could be in OpenFirmware specs. Documenting it in the >>> DT bindings does not hurt. >> >> Ok. >> >>>> And for older kernels we should not set any serial atag (u-boot >>>> always sets it, so this leaves it at 0) and old kernel users are >>>> out of luck wrt getting to the serial ? >>> >>> If there is sufficient reason to support this on old kernels you could. >> >> One problem with supporting this for older kernels is that if a non 0 >> serial gets shown in /proc/cpuinfo with older atag booted kernels, we >> should really show the same number in /proc/cpuinfo which means adding >> code to the kernel to get the devicetree "serial-number" string property >> and somehow put that into the 64 bits which we have in /proc/cpuinfo, >> but given that the "serial-number" string could be hex or decimal or >> what ever and > 64 bits that will likely require a platform specific >> solution. All doable, but the question then becomes is this worth the >> effort ? > > After investigating a bit more, I found out that the USB serial number > is expected to be a string of 32 bytes, so a 128 bit numeric serial > doesn't fit (it takes 32 bytes for the hex representation of 128 bits, > so there is no room left for the terminating null byte), hence it makes > sense to keep a 64 bit limitation for the serial number, if users are > going to rely on it as USB serial string. Moreover, it seems that > Android devices are mostly used 64 bit numbers for serial numbers/ > > I was initially going to suggest that we set it in stone that serial > must be 64 numeric bits (as it was in the ATAGs days) and that > bootloaders would pass it that way to the kernel through device tree > (with two 32 bits numeric integers), but Hans talked me out of it. > I just want to expose the situation (especially the USB and Android > thing) here to double-check that everyone still is convinced that a > string approach in device tree is best (which is fine with me). There are already existing users of the serial-number property in devicetree, and these already use a free-format string, so AFAICT we have no choice but to do the same as the existing users. But Rob is the expert here, so lets see what Rob has to say. > This way, users that still want to use the serial passed through device > tree as a USB serial number will have to use a string of 32 bits, > including the null terminating byte (which is what I'll suggest for > sunxi by using only 64 bits for the serial number). > > Also, I suggest that we show that serial-number string as-is in cpuinfo > as well We cannot do that because we must guarantee that the serial shown in cpu info is a 64 bits / 16 hex values (0 padded) number, anything else would break the kernel <-> userspace API and potentially break userspace apps. So we must do the devicetree -> serialnumber low/high -> /proc/cpinfo version to guarantee that this format does not change. And as discussed before if you want a non 0 serial in cpuinfo then the devicetree -> serialnumber low/high should be done in sunxi specific kernel code, as on sunxi we will know that the string in devicetree will be a hex value, but we've no such guarantee for other platforms, so we cannot simply have a generic function to populate erialnumber low/high from the devicetree serial-number string. > and instead make a string out of the serial ATAG in the kernel > prior to showing it in cpuinfo (as opposed to translating the string > coming from device tree to a numeric value that cpuinfo will end up > showing as a string at the end of the day). Thus, the serial number > coming from device tree will still be shown in cpuinfo as well and no > ABI gets broken. You're forgetting the userspace <-> kernel ABI here, the serial line in /proc/cpuinfo is not a free form string it is a 64 bit int shown as 0 padded hex, and we cannot change that as changing that would be an ABI break. > If you're all okay with this, I'll be sending patches to both U-Boot and > Linux to start documenting/implementing this. Thanks for your work on this, lets first hash out to few remaining unclear details and then I'm looking forward to your patch set for this. Regards, Hans _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
WARNING: multiple messages have this Message-ID (diff)
From: Hans de Goede <hdegoede@redhat.com> To: u-boot@lists.denx.de Subject: [U-Boot] serial atag tag in devicetree ? Date: Thu, 26 Mar 2015 09:53:58 +0100 [thread overview] Message-ID: <5513C926.1010708@redhat.com> (raw) In-Reply-To: <1427322910.26627.15.camel@collins> Hi, On 25-03-15 23:35, Paul Kocialkowski wrote: > Le mardi 24 mars 2015 ? 09:01 +0100, Hans de Goede a ?crit : >> Hi, >> >> On 24-03-15 00:12, Rob Herring wrote: >>> On Mon, Mar 23, 2015 at 6:30 AM, Hans de Goede <hdegoede@redhat.com> wrote: >>>> Hi, >>>> >>>> >>>> On 22-03-15 22:01, Rob Herring wrote: >> >> <snip> >> >>>>> There is already "serial-number" (a string) which exists for >>>>> OpenFirmware. Also, "copyright" corresponds to vendor/manufacturer >>>>> string. Both of these are supported by lshw already. >>>> >>>> >>>> Ok, so if I understand you correctly then you're saying that we >>>> should set a "serial-number" string property at the dt root level >>>> and that this may contain pretty much anything, e.g. in the >>>> sunxi case the full 128 bit SID in hex. >>> >>> Right. >>> >>>> Is the use of the "serial-number" string property already documented >>>> somewhere? If not I'll submit a kernel patch to document it. >>> >>> Not that I'm aware of. It is something that predates our documentation >>> requirements. It could be in OpenFirmware specs. Documenting it in the >>> DT bindings does not hurt. >> >> Ok. >> >>>> And for older kernels we should not set any serial atag (u-boot >>>> always sets it, so this leaves it at 0) and old kernel users are >>>> out of luck wrt getting to the serial ? >>> >>> If there is sufficient reason to support this on old kernels you could. >> >> One problem with supporting this for older kernels is that if a non 0 >> serial gets shown in /proc/cpuinfo with older atag booted kernels, we >> should really show the same number in /proc/cpuinfo which means adding >> code to the kernel to get the devicetree "serial-number" string property >> and somehow put that into the 64 bits which we have in /proc/cpuinfo, >> but given that the "serial-number" string could be hex or decimal or >> what ever and > 64 bits that will likely require a platform specific >> solution. All doable, but the question then becomes is this worth the >> effort ? > > After investigating a bit more, I found out that the USB serial number > is expected to be a string of 32 bytes, so a 128 bit numeric serial > doesn't fit (it takes 32 bytes for the hex representation of 128 bits, > so there is no room left for the terminating null byte), hence it makes > sense to keep a 64 bit limitation for the serial number, if users are > going to rely on it as USB serial string. Moreover, it seems that > Android devices are mostly used 64 bit numbers for serial numbers/ > > I was initially going to suggest that we set it in stone that serial > must be 64 numeric bits (as it was in the ATAGs days) and that > bootloaders would pass it that way to the kernel through device tree > (with two 32 bits numeric integers), but Hans talked me out of it. > I just want to expose the situation (especially the USB and Android > thing) here to double-check that everyone still is convinced that a > string approach in device tree is best (which is fine with me). There are already existing users of the serial-number property in devicetree, and these already use a free-format string, so AFAICT we have no choice but to do the same as the existing users. But Rob is the expert here, so lets see what Rob has to say. > This way, users that still want to use the serial passed through device > tree as a USB serial number will have to use a string of 32 bits, > including the null terminating byte (which is what I'll suggest for > sunxi by using only 64 bits for the serial number). > > Also, I suggest that we show that serial-number string as-is in cpuinfo > as well We cannot do that because we must guarantee that the serial shown in cpu info is a 64 bits / 16 hex values (0 padded) number, anything else would break the kernel <-> userspace API and potentially break userspace apps. So we must do the devicetree -> serialnumber low/high -> /proc/cpinfo version to guarantee that this format does not change. And as discussed before if you want a non 0 serial in cpuinfo then the devicetree -> serialnumber low/high should be done in sunxi specific kernel code, as on sunxi we will know that the string in devicetree will be a hex value, but we've no such guarantee for other platforms, so we cannot simply have a generic function to populate erialnumber low/high from the devicetree serial-number string. > and instead make a string out of the serial ATAG in the kernel > prior to showing it in cpuinfo (as opposed to translating the string > coming from device tree to a numeric value that cpuinfo will end up > showing as a string at the end of the day). Thus, the serial number > coming from device tree will still be shown in cpuinfo as well and no > ABI gets broken. You're forgetting the userspace <-> kernel ABI here, the serial line in /proc/cpuinfo is not a free form string it is a 64 bit int shown as 0 padded hex, and we cannot change that as changing that would be an ABI break. > If you're all okay with this, I'll be sending patches to both U-Boot and > Linux to start documenting/implementing this. Thanks for your work on this, lets first hash out to few remaining unclear details and then I'm looking forward to your patch set for this. Regards, Hans
next prev parent reply other threads:[~2015-03-26 8:53 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-03-22 11:26 serial atag tag in devicetree ? Hans de Goede 2015-03-22 11:26 ` [U-Boot] " Hans de Goede 2015-03-22 21:01 ` Rob Herring 2015-03-22 21:01 ` [U-Boot] " Rob Herring 2015-03-23 11:30 ` Hans de Goede 2015-03-23 11:30 ` [U-Boot] " Hans de Goede [not found] ` <550FF971.407-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2015-03-23 23:12 ` Rob Herring 2015-03-23 23:12 ` Rob Herring [not found] ` <CAL_JsqLev+DeWCzvhF7bwYk3URxpgaQDR+6OmwWHjJ2nx=HijQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-03-24 8:01 ` Hans de Goede 2015-03-24 8:01 ` Hans de Goede 2015-03-25 22:35 ` Paul Kocialkowski 2015-03-25 22:35 ` [U-Boot] " Paul Kocialkowski 2015-03-26 8:53 ` Hans de Goede [this message] 2015-03-26 8:53 ` Hans de Goede 2015-03-26 9:11 ` Paul Kocialkowski 2015-03-26 9:11 ` [U-Boot] " Paul Kocialkowski 2015-03-26 9:16 ` Paul Kocialkowski 2015-03-26 9:16 ` Paul Kocialkowski 2015-03-27 4:30 ` Rob Herring 2015-03-27 4:30 ` Rob Herring 2015-03-27 8:36 ` Hans de Goede 2015-03-27 8:36 ` [U-Boot] " Hans de Goede 2015-03-27 10:23 ` Paul Kocialkowski 2015-03-27 10:23 ` [U-Boot] " Paul Kocialkowski
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=5513C926.1010708@redhat.com \ --to=hdegoede@redhat.com \ --cc=contact@paulk.fr \ --cc=devicetree@vger.kernel.org \ --cc=ijc@hellion.org.uk \ --cc=robherring2@gmail.com \ --cc=u-boot@lists.denx.de \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.