From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Kocialkowski Subject: Re: serial atag tag in devicetree ? Date: Fri, 27 Mar 2015 11:23:37 +0100 Message-ID: <1427451817.2390.1.camel@collins> References: <550EA6D8.3090702@redhat.com> <550FF971.407@redhat.com> <551119F1.2060002@redhat.com> <1427322910.26627.15.camel@collins> <5513C926.1010708@redhat.com> <1427361114.2342.7.camel@collins> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0548985261==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" To: Rob Herring Cc: U-Boot , Ian Campbell , Russell King - ARM Linux , devicetree List-Id: devicetree@vger.kernel.org --===============0548985261== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-j8Ba0fUa99ROReTdYq6R" --=-j8Ba0fUa99ROReTdYq6R Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le jeudi 26 mars 2015 =C3=A0 23:30 -0500, Rob Herring a =C3=A9crit : > On Thu, Mar 26, 2015 at 4:11 AM, Paul Kocialkowski wro= te: > > Le jeudi 26 mars 2015 =C3=A0 09:53 +0100, Hans de Goede a =C3=A9crit : > >> Hi, > >> > >> On 25-03-15 23:35, Paul Kocialkowski wrote: > >> > Le mardi 24 mars 2015 =C3=A0 09:01 +0100, Hans de Goede a =C3=A9crit= : > >> >> Hi, > >> >> > >> >> On 24-03-15 00:12, Rob Herring wrote: > >> >>> On Mon, Mar 23, 2015 at 6:30 AM, Hans de Goede wrote: > >> >>>> Hi, > >> >>>> > >> >>>> > >> >>>> On 22-03-15 22:01, Rob Herring wrote: > >> >> > >> >> > >> >> > >> >>>>> There is already "serial-number" (a string) which exists for > >> >>>>> OpenFirmware. Also, "copyright" corresponds to vendor/manufactur= er > >> >>>>> 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 documen= ted > >> >>>> somewhere? If not I'll submit a kernel patch to document it. > >> >>> > >> >>> Not that I'm aware of. It is something that predates our documenta= tion > >> >>> 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 c= ould. > >> >> > >> >> 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 add= ing > >> >> code to the kernel to get the devicetree "serial-number" string pro= perty > >> >> and somehow put that into the 64 bits which we have in /proc/cpuinf= o, > >> >> but given that the "serial-number" string could be hex or decimal o= r > >> >> what ever and > 64 bits that will likely require a platform specifi= c > >> >> solution. All doable, but the question then becomes is this worth t= he > >> >> effort ? > >> > > >> > After investigating a bit more, I found out that the USB serial numb= er > >> > 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 bit= s, > >> > so there is no room left for the terminating null byte), hence it ma= kes > >> > sense to keep a 64 bit limitation for the serial number, if users ar= e > >> > 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 devi= cetree, > >> and these already use a free-format string, so AFAICT we have no choic= e > >> 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 dev= ice > >> > 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 cpui= nfo > >> > 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 n= o > >> > 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. > > > > IMHO this really is all about interpretation. If you consider that the > > serial is already a *string* and not a hex-representation of a number > > (which it is when using ATAGs, but has no reason to be in general), the= n > > my suggestion will introduce no ABI break. > > > > Generally speaking, I found no documentation that indicates that the > > serial has to be in that format. It just happens to be the case when > > using ATAGs. > > > > Also, I found an email from Rob suggesting he would be fine with wiring > > the dts serial-number string to cpuinfo: > > http://lkml.iu.edu/hypermail/linux/kernel/1412.0/02975.html > > > > I think it's the most flexible solution and we can think of it as an > > extension of the current scheme: the serial string will no longer be > > limited to a hex representation of a number but can become any string. > > > > Now I would appreciate it if Rob could weigh-in and state whether he > > changed his mind on this or not. >=20 > The only ABI is on platforms that used ATAGS as any DT only platform > has so far had a serial# in cpuinfo of 16 0's. With a variable length > string we can still have a fixed 16 char hex serial number that is > compatible with ATAGS. I can't imagine that we have userspace that > cares about the length and yet doesn't care the value is always 0's > since converting to DT. As long as we keep 16 0's as the default I > don't see an issue with allowing other lengths. >=20 > It is only an ABI if someone notices and if we find an ABI issue later > we can always fix it. Alright then, I think that all makes sense. I have a first proposal in that direction ready then. Russell, I'll just wait for your ack and start sending this to both the U-Boot and ARM kernel lists. --=20 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/ --=-j8Ba0fUa99ROReTdYq6R Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJVFS+pAAoJEIT9weqP7pUMmukP/2bbbcf0a9HH+HoIuk6wSXTJ uqFUOr1cwSmi53qIEzM5FPhkRtRl0cohtfIqlcJg17qtygqJ+kAeqzliOqdaWAso Mk/afdcAdqMB6BqohN+Sm0f80zUMOSfmtzaecvVPd2gj7IkeTlel2ovkSDb4XqMF mkuOAjr3X1bNUUuq64tM98Kr1JHtOjVygki8h33ecM/gH0oCdS+zU82UqvitcO7Z GQDJ39vPoY5wqqC8NTqsICj5LTmabFi5zdyqqZgDsJy0WsfnbUGaWPDAuUvSyczH MLPElZFpiISXi3YHRAKBiq1F2BzcKEk77KPCsRwncRUFPre1nR3CyhckKyAj/yBP EI4B8FemuuBH4E0oZqzfgtvHKzyZopEkYUFp66s4g/LY2B8MnndEIRNLCefcaGco eJAdkWLBpDGLE9AAhV0nKaVq41RY3ZEb610R8OWws9pDrVElFEcqnv77wTsSxcWm 4JcyzXisYoKv5FOhQ/MMV+ugsfv5ei3HAXUjHQWXXdhTczASs9/W33DvpqIphpq2 mNGa5/OE3NU6a8BwEBrpJapmPLQd6wpgLwt5ZYKHwyehCrs4ASUjzmUZpm/GCmYG DNmx15uVllaBLXDX8QQZ4/X6WDD+SeLg88X3nbMKnemNYVbIgupLWLllRASS1+TG VSYqqUS3uJ2AhE9cIDEP =yWiB -----END PGP SIGNATURE----- --=-j8Ba0fUa99ROReTdYq6R-- --===============0548985261== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot --===============0548985261==--