From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Subject: Re: serial atag tag in devicetree ? Date: Thu, 26 Mar 2015 09:53:58 +0100 Message-ID: <5513C926.1010708@redhat.com> References: <550EA6D8.3090702@redhat.com> <550FF971.407@redhat.com> <551119F1.2060002@redhat.com> <1427322910.26627.15.camel@collins> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <1427322910.26627.15.camel@collins> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" To: Paul Kocialkowski , Rob Herring Cc: devicetree , Ian Campbell , U-Boot List-Id: devicetree@vger.kernel.org SGksCgpPbiAyNS0wMy0xNSAyMzozNSwgUGF1bCBLb2NpYWxrb3dza2kgd3JvdGU6Cj4gTGUgbWFy ZGkgMjQgbWFycyAyMDE1IMOgIDA5OjAxICswMTAwLCBIYW5zIGRlIEdvZWRlIGEgw6ljcml0IDoK Pj4gSGksCj4+Cj4+IE9uIDI0LTAzLTE1IDAwOjEyLCBSb2IgSGVycmluZyB3cm90ZToKPj4+IE9u IE1vbiwgTWFyIDIzLCAyMDE1IGF0IDY6MzAgQU0sIEhhbnMgZGUgR29lZGUgPGhkZWdvZWRlQHJl ZGhhdC5jb20+IHdyb3RlOgo+Pj4+IEhpLAo+Pj4+Cj4+Pj4KPj4+PiBPbiAyMi0wMy0xNSAyMjow MSwgUm9iIEhlcnJpbmcgd3JvdGU6Cj4+Cj4+IDxzbmlwPgo+Pgo+Pj4+PiBUaGVyZSBpcyBhbHJl YWR5ICJzZXJpYWwtbnVtYmVyIiAoYSBzdHJpbmcpIHdoaWNoIGV4aXN0cyBmb3IKPj4+Pj4gT3Bl bkZpcm13YXJlLiBBbHNvLCAiY29weXJpZ2h0IiBjb3JyZXNwb25kcyB0byB2ZW5kb3IvbWFudWZh Y3R1cmVyCj4+Pj4+IHN0cmluZy4gQm90aCBvZiB0aGVzZSBhcmUgc3VwcG9ydGVkIGJ5IGxzaHcg YWxyZWFkeS4KPj4+Pgo+Pj4+Cj4+Pj4gT2ssIHNvIGlmIEkgdW5kZXJzdGFuZCB5b3UgY29ycmVj dGx5IHRoZW4geW91J3JlIHNheWluZyB0aGF0IHdlCj4+Pj4gc2hvdWxkIHNldCBhICJzZXJpYWwt bnVtYmVyIiBzdHJpbmcgcHJvcGVydHkgYXQgdGhlIGR0IHJvb3QgbGV2ZWwKPj4+PiBhbmQgdGhh dCB0aGlzIG1heSBjb250YWluIHByZXR0eSBtdWNoIGFueXRoaW5nLCBlLmcuIGluIHRoZQo+Pj4+ IHN1bnhpIGNhc2UgdGhlIGZ1bGwgMTI4IGJpdCBTSUQgaW4gaGV4Lgo+Pj4KPj4+IFJpZ2h0Lgo+ Pj4KPj4+PiBJcyB0aGUgdXNlIG9mIHRoZSAic2VyaWFsLW51bWJlciIgc3RyaW5nIHByb3BlcnR5 IGFscmVhZHkgZG9jdW1lbnRlZAo+Pj4+IHNvbWV3aGVyZT8gSWYgbm90IEknbGwgc3VibWl0IGEg a2VybmVsIHBhdGNoIHRvIGRvY3VtZW50IGl0Lgo+Pj4KPj4+IE5vdCB0aGF0IEknbSBhd2FyZSBv Zi4gSXQgaXMgc29tZXRoaW5nIHRoYXQgcHJlZGF0ZXMgb3VyIGRvY3VtZW50YXRpb24KPj4+IHJl cXVpcmVtZW50cy4gSXQgY291bGQgYmUgaW4gT3BlbkZpcm13YXJlIHNwZWNzLiBEb2N1bWVudGlu ZyBpdCBpbiB0aGUKPj4+IERUIGJpbmRpbmdzIGRvZXMgbm90IGh1cnQuCj4+Cj4+IE9rLgo+Pgo+ Pj4+IEFuZCBmb3Igb2xkZXIga2VybmVscyB3ZSBzaG91bGQgbm90IHNldCBhbnkgc2VyaWFsIGF0 YWcgKHUtYm9vdAo+Pj4+IGFsd2F5cyBzZXRzIGl0LCBzbyB0aGlzIGxlYXZlcyBpdCBhdCAwKSBh bmQgb2xkIGtlcm5lbCB1c2VycyBhcmUKPj4+PiBvdXQgb2YgbHVjayB3cnQgZ2V0dGluZyB0byB0 aGUgc2VyaWFsID8KPj4+Cj4+PiBJZiB0aGVyZSBpcyBzdWZmaWNpZW50IHJlYXNvbiB0byBzdXBw b3J0IHRoaXMgb24gb2xkIGtlcm5lbHMgeW91IGNvdWxkLgo+Pgo+PiBPbmUgcHJvYmxlbSB3aXRo IHN1cHBvcnRpbmcgdGhpcyBmb3Igb2xkZXIga2VybmVscyBpcyB0aGF0IGlmIGEgbm9uIDAKPj4g c2VyaWFsIGdldHMgc2hvd24gaW4gL3Byb2MvY3B1aW5mbyB3aXRoIG9sZGVyIGF0YWcgYm9vdGVk IGtlcm5lbHMsIHdlCj4+IHNob3VsZCByZWFsbHkgc2hvdyB0aGUgc2FtZSBudW1iZXIgaW4gL3By b2MvY3B1aW5mbyB3aGljaCBtZWFucyBhZGRpbmcKPj4gY29kZSB0byB0aGUga2VybmVsIHRvIGdl dCB0aGUgZGV2aWNldHJlZSAic2VyaWFsLW51bWJlciIgc3RyaW5nIHByb3BlcnR5Cj4+IGFuZCBz b21laG93IHB1dCB0aGF0IGludG8gdGhlIDY0IGJpdHMgd2hpY2ggd2UgaGF2ZSBpbiAvcHJvYy9j cHVpbmZvLAo+PiBidXQgZ2l2ZW4gdGhhdCB0aGUgInNlcmlhbC1udW1iZXIiIHN0cmluZyBjb3Vs ZCBiZSBoZXggb3IgZGVjaW1hbCBvcgo+PiB3aGF0IGV2ZXIgYW5kID4gNjQgYml0cyB0aGF0IHdp bGwgbGlrZWx5IHJlcXVpcmUgYSBwbGF0Zm9ybSBzcGVjaWZpYwo+PiBzb2x1dGlvbi4gQWxsIGRv YWJsZSwgYnV0IHRoZSBxdWVzdGlvbiB0aGVuIGJlY29tZXMgaXMgdGhpcyB3b3J0aCB0aGUKPj4g ZWZmb3J0ID8KPgo+IEFmdGVyIGludmVzdGlnYXRpbmcgYSBiaXQgbW9yZSwgSSBmb3VuZCBvdXQg dGhhdCB0aGUgVVNCIHNlcmlhbCBudW1iZXIKPiBpcyBleHBlY3RlZCB0byBiZSBhIHN0cmluZyBv ZiAzMiBieXRlcywgc28gYSAxMjggYml0IG51bWVyaWMgc2VyaWFsCj4gZG9lc24ndCBmaXQgKGl0 IHRha2VzIDMyIGJ5dGVzIGZvciB0aGUgaGV4IHJlcHJlc2VudGF0aW9uIG9mIDEyOCBiaXRzLAo+ IHNvIHRoZXJlIGlzIG5vIHJvb20gbGVmdCBmb3IgdGhlIHRlcm1pbmF0aW5nIG51bGwgYnl0ZSks IGhlbmNlIGl0IG1ha2VzCj4gc2Vuc2UgdG8ga2VlcCBhIDY0IGJpdCBsaW1pdGF0aW9uIGZvciB0 aGUgc2VyaWFsIG51bWJlciwgaWYgdXNlcnMgYXJlCj4gZ29pbmcgdG8gcmVseSBvbiBpdCBhcyBV U0Igc2VyaWFsIHN0cmluZy4gTW9yZW92ZXIsIGl0IHNlZW1zIHRoYXQKPiBBbmRyb2lkIGRldmlj ZXMgYXJlIG1vc3RseSB1c2VkIDY0IGJpdCBudW1iZXJzIGZvciBzZXJpYWwgbnVtYmVycy8KPgo+ IEkgd2FzIGluaXRpYWxseSBnb2luZyB0byBzdWdnZXN0IHRoYXQgd2Ugc2V0IGl0IGluIHN0b25l IHRoYXQgc2VyaWFsCj4gbXVzdCBiZSA2NCBudW1lcmljIGJpdHMgKGFzIGl0IHdhcyBpbiB0aGUg QVRBR3MgZGF5cykgYW5kIHRoYXQKPiBib290bG9hZGVycyB3b3VsZCBwYXNzIGl0IHRoYXQgd2F5 IHRvIHRoZSBrZXJuZWwgdGhyb3VnaCBkZXZpY2UgdHJlZQo+ICh3aXRoIHR3byAzMiBiaXRzIG51 bWVyaWMgaW50ZWdlcnMpLCBidXQgSGFucyB0YWxrZWQgbWUgb3V0IG9mIGl0Lgo+IEkganVzdCB3 YW50IHRvIGV4cG9zZSB0aGUgc2l0dWF0aW9uIChlc3BlY2lhbGx5IHRoZSBVU0IgYW5kIEFuZHJv aWQKPiB0aGluZykgaGVyZSB0byBkb3VibGUtY2hlY2sgdGhhdCBldmVyeW9uZSBzdGlsbCBpcyBj b252aW5jZWQgdGhhdCBhCj4gc3RyaW5nIGFwcHJvYWNoIGluIGRldmljZSB0cmVlIGlzIGJlc3Qg KHdoaWNoIGlzIGZpbmUgd2l0aCBtZSkuCgpUaGVyZSBhcmUgYWxyZWFkeSBleGlzdGluZyB1c2Vy cyBvZiB0aGUgc2VyaWFsLW51bWJlciBwcm9wZXJ0eSBpbiBkZXZpY2V0cmVlLAphbmQgdGhlc2Ug YWxyZWFkeSB1c2UgYSBmcmVlLWZvcm1hdCBzdHJpbmcsIHNvIEFGQUlDVCB3ZSBoYXZlIG5vIGNo b2ljZQpidXQgdG8gZG8gdGhlIHNhbWUgYXMgdGhlIGV4aXN0aW5nIHVzZXJzLgoKQnV0IFJvYiBp cyB0aGUgZXhwZXJ0IGhlcmUsIHNvIGxldHMgc2VlIHdoYXQgUm9iIGhhcyB0byBzYXkuCgo+IFRo aXMgd2F5LCB1c2VycyB0aGF0IHN0aWxsIHdhbnQgdG8gdXNlIHRoZSBzZXJpYWwgcGFzc2VkIHRo cm91Z2ggZGV2aWNlCj4gdHJlZSBhcyBhIFVTQiBzZXJpYWwgbnVtYmVyIHdpbGwgaGF2ZSB0byB1 c2UgYSBzdHJpbmcgb2YgMzIgYml0cywKPiBpbmNsdWRpbmcgdGhlIG51bGwgdGVybWluYXRpbmcg Ynl0ZSAod2hpY2ggaXMgd2hhdCBJJ2xsIHN1Z2dlc3QgZm9yCj4gc3VueGkgYnkgdXNpbmcgb25s eSA2NCBiaXRzIGZvciB0aGUgc2VyaWFsIG51bWJlcikuCj4KPiBBbHNvLCBJIHN1Z2dlc3QgdGhh dCB3ZSBzaG93IHRoYXQgc2VyaWFsLW51bWJlciBzdHJpbmcgYXMtaXMgaW4gY3B1aW5mbwo+IGFz IHdlbGwKCldlIGNhbm5vdCBkbyB0aGF0IGJlY2F1c2Ugd2UgbXVzdCBndWFyYW50ZWUgdGhhdCB0 aGUgc2VyaWFsIHNob3duCmluIGNwdSBpbmZvIGlzIGEgNjQgYml0cyAvIDE2IGhleCB2YWx1ZXMg KDAgcGFkZGVkKSBudW1iZXIsIGFueXRoaW5nCmVsc2Ugd291bGQgYnJlYWsgdGhlIGtlcm5lbCA8 LT4gdXNlcnNwYWNlIEFQSSBhbmQgcG90ZW50aWFsbHkgYnJlYWsKdXNlcnNwYWNlIGFwcHMuIFNv IHdlIG11c3QgZG8gdGhlIGRldmljZXRyZWUgLT4gc2VyaWFsbnVtYmVyIGxvdy9oaWdoCi0+IC9w cm9jL2NwaW5mbyB2ZXJzaW9uIHRvIGd1YXJhbnRlZSB0aGF0IHRoaXMgZm9ybWF0IGRvZXMgbm90 IGNoYW5nZS4KCkFuZCBhcyBkaXNjdXNzZWQgYmVmb3JlIGlmIHlvdSB3YW50IGEgbm9uIDAgc2Vy aWFsIGluIGNwdWluZm8gdGhlbgp0aGUgZGV2aWNldHJlZSAtPiBzZXJpYWxudW1iZXIgbG93L2hp Z2ggc2hvdWxkIGJlIGRvbmUgaW4gc3VueGkKc3BlY2lmaWMga2VybmVsIGNvZGUsIGFzIG9uIHN1 bnhpIHdlIHdpbGwga25vdyB0aGF0IHRoZSBzdHJpbmcgaW4KZGV2aWNldHJlZSB3aWxsIGJlIGEg aGV4IHZhbHVlLCBidXQgd2UndmUgbm8gc3VjaCBndWFyYW50ZWUgZm9yCm90aGVyIHBsYXRmb3Jt cywgc28gd2UgY2Fubm90IHNpbXBseSBoYXZlIGEgZ2VuZXJpYyBmdW5jdGlvbiB0bwpwb3B1bGF0 ZSBlcmlhbG51bWJlciBsb3cvaGlnaCBmcm9tIHRoZSBkZXZpY2V0cmVlIHNlcmlhbC1udW1iZXIK c3RyaW5nLgoKID4gYW5kIGluc3RlYWQgbWFrZSBhIHN0cmluZyBvdXQgb2YgdGhlIHNlcmlhbCBB VEFHIGluIHRoZSBrZXJuZWwKPiBwcmlvciB0byBzaG93aW5nIGl0IGluIGNwdWluZm8gKGFzIG9w cG9zZWQgdG8gdHJhbnNsYXRpbmcgdGhlIHN0cmluZwo+IGNvbWluZyBmcm9tIGRldmljZSB0cmVl IHRvIGEgbnVtZXJpYyB2YWx1ZSB0aGF0IGNwdWluZm8gd2lsbCBlbmQgdXAKPiBzaG93aW5nIGFz IGEgc3RyaW5nIGF0IHRoZSBlbmQgb2YgdGhlIGRheSkuIFRodXMsIHRoZSBzZXJpYWwgbnVtYmVy Cj4gY29taW5nIGZyb20gZGV2aWNlIHRyZWUgd2lsbCBzdGlsbCBiZSBzaG93biBpbiBjcHVpbmZv IGFzIHdlbGwgYW5kIG5vCj4gQUJJIGdldHMgYnJva2VuLgoKWW91J3JlIGZvcmdldHRpbmcgdGhl IHVzZXJzcGFjZSA8LT4ga2VybmVsIEFCSSBoZXJlLCB0aGUgc2VyaWFsIGxpbmUKaW4gL3Byb2Mv Y3B1aW5mbyBpcyBub3QgYSBmcmVlIGZvcm0gc3RyaW5nIGl0IGlzIGEgNjQgYml0IGludCBzaG93 bgphcyAwIHBhZGRlZCBoZXgsIGFuZCB3ZSBjYW5ub3QgY2hhbmdlIHRoYXQgYXMgY2hhbmdpbmcg dGhhdCB3b3VsZCBiZQphbiBBQkkgYnJlYWsuCgo+IElmIHlvdSdyZSBhbGwgb2theSB3aXRoIHRo aXMsIEknbGwgYmUgc2VuZGluZyBwYXRjaGVzIHRvIGJvdGggVS1Cb290IGFuZAo+IExpbnV4IHRv IHN0YXJ0IGRvY3VtZW50aW5nL2ltcGxlbWVudGluZyB0aGlzLgoKVGhhbmtzIGZvciB5b3VyIHdv cmsgb24gdGhpcywgbGV0cyBmaXJzdCBoYXNoIG91dCB0byBmZXcgcmVtYWluaW5nIHVuY2xlYXIK ZGV0YWlscyBhbmQgdGhlbiBJJ20gbG9va2luZyBmb3J3YXJkIHRvIHlvdXIgcGF0Y2ggc2V0IGZv ciB0aGlzLgoKUmVnYXJkcywKCkhhbnMKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KVS1Cb290IG1haWxpbmcgbGlzdApVLUJvb3RAbGlzdHMuZGVueC5kZQpo dHRwOi8vbGlzdHMuZGVueC5kZS9tYWlsbWFuL2xpc3RpbmZvL3UtYm9vdAo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Date: Thu, 26 Mar 2015 09:53:58 +0100 Subject: [U-Boot] serial atag tag in devicetree ? In-Reply-To: <1427322910.26627.15.camel@collins> References: <550EA6D8.3090702@redhat.com> <550FF971.407@redhat.com> <551119F1.2060002@redhat.com> <1427322910.26627.15.camel@collins> Message-ID: <5513C926.1010708@redhat.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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/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