From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Subject: Re: serial atag tag in devicetree ? Date: Fri, 27 Mar 2015 09:36:21 +0100 Message-ID: <55151685.3060404@redhat.com> 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: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 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 , Paul Kocialkowski Cc: devicetree , Ian Campbell , Russell King - ARM Linux , U-Boot List-Id: devicetree@vger.kernel.org SGksCgpPbiAyNy0wMy0xNSAwNTozMCwgUm9iIEhlcnJpbmcgd3JvdGU6Cj4gT24gVGh1LCBNYXIg MjYsIDIwMTUgYXQgNDoxMSBBTSwgUGF1bCBLb2NpYWxrb3dza2kgPGNvbnRhY3RAcGF1bGsuZnI+ IHdyb3RlOgo+PiBMZSBqZXVkaSAyNiBtYXJzIDIwMTUgw6AgMDk6NTMgKzAxMDAsIEhhbnMgZGUg R29lZGUgYSDDqWNyaXQgOgo+Pj4gSGksCj4+Pgo+Pj4gT24gMjUtMDMtMTUgMjM6MzUsIFBhdWwg S29jaWFsa293c2tpIHdyb3RlOgo+Pj4+IExlIG1hcmRpIDI0IG1hcnMgMjAxNSDDoCAwOTowMSAr MDEwMCwgSGFucyBkZSBHb2VkZSBhIMOpY3JpdCA6Cj4+Pj4+IEhpLAo+Pj4+Pgo+Pj4+PiBPbiAy NC0wMy0xNSAwMDoxMiwgUm9iIEhlcnJpbmcgd3JvdGU6Cj4+Pj4+PiBPbiBNb24sIE1hciAyMywg MjAxNSBhdCA2OjMwIEFNLCBIYW5zIGRlIEdvZWRlIDxoZGVnb2VkZUByZWRoYXQuY29tPiB3cm90 ZToKPj4+Pj4+PiBIaSwKPj4+Pj4+Pgo+Pj4+Pj4+Cj4+Pj4+Pj4gT24gMjItMDMtMTUgMjI6MDEs IFJvYiBIZXJyaW5nIHdyb3RlOgo+Pj4+Pgo+Pj4+PiA8c25pcD4KPj4+Pj4KPj4+Pj4+Pj4gVGhl cmUgaXMgYWxyZWFkeSAic2VyaWFsLW51bWJlciIgKGEgc3RyaW5nKSB3aGljaCBleGlzdHMgZm9y Cj4+Pj4+Pj4+IE9wZW5GaXJtd2FyZS4gQWxzbywgImNvcHlyaWdodCIgY29ycmVzcG9uZHMgdG8g dmVuZG9yL21hbnVmYWN0dXJlcgo+Pj4+Pj4+PiBzdHJpbmcuIEJvdGggb2YgdGhlc2UgYXJlIHN1 cHBvcnRlZCBieSBsc2h3IGFscmVhZHkuCj4+Pj4+Pj4KPj4+Pj4+Pgo+Pj4+Pj4+IE9rLCBzbyBp ZiBJIHVuZGVyc3RhbmQgeW91IGNvcnJlY3RseSB0aGVuIHlvdSdyZSBzYXlpbmcgdGhhdCB3ZQo+ Pj4+Pj4+IHNob3VsZCBzZXQgYSAic2VyaWFsLW51bWJlciIgc3RyaW5nIHByb3BlcnR5IGF0IHRo ZSBkdCByb290IGxldmVsCj4+Pj4+Pj4gYW5kIHRoYXQgdGhpcyBtYXkgY29udGFpbiBwcmV0dHkg bXVjaCBhbnl0aGluZywgZS5nLiBpbiB0aGUKPj4+Pj4+PiBzdW54aSBjYXNlIHRoZSBmdWxsIDEy OCBiaXQgU0lEIGluIGhleC4KPj4+Pj4+Cj4+Pj4+PiBSaWdodC4KPj4+Pj4+Cj4+Pj4+Pj4gSXMg dGhlIHVzZSBvZiB0aGUgInNlcmlhbC1udW1iZXIiIHN0cmluZyBwcm9wZXJ0eSBhbHJlYWR5IGRv Y3VtZW50ZWQKPj4+Pj4+PiBzb21ld2hlcmU/IElmIG5vdCBJJ2xsIHN1Ym1pdCBhIGtlcm5lbCBw YXRjaCB0byBkb2N1bWVudCBpdC4KPj4+Pj4+Cj4+Pj4+PiBOb3QgdGhhdCBJJ20gYXdhcmUgb2Yu IEl0IGlzIHNvbWV0aGluZyB0aGF0IHByZWRhdGVzIG91ciBkb2N1bWVudGF0aW9uCj4+Pj4+PiBy ZXF1aXJlbWVudHMuIEl0IGNvdWxkIGJlIGluIE9wZW5GaXJtd2FyZSBzcGVjcy4gRG9jdW1lbnRp bmcgaXQgaW4gdGhlCj4+Pj4+PiBEVCBiaW5kaW5ncyBkb2VzIG5vdCBodXJ0Lgo+Pj4+Pgo+Pj4+ PiBPay4KPj4+Pj4KPj4+Pj4+PiBBbmQgZm9yIG9sZGVyIGtlcm5lbHMgd2Ugc2hvdWxkIG5vdCBz ZXQgYW55IHNlcmlhbCBhdGFnICh1LWJvb3QKPj4+Pj4+PiBhbHdheXMgc2V0cyBpdCwgc28gdGhp cyBsZWF2ZXMgaXQgYXQgMCkgYW5kIG9sZCBrZXJuZWwgdXNlcnMgYXJlCj4+Pj4+Pj4gb3V0IG9m IGx1Y2sgd3J0IGdldHRpbmcgdG8gdGhlIHNlcmlhbCA/Cj4+Pj4+Pgo+Pj4+Pj4gSWYgdGhlcmUg aXMgc3VmZmljaWVudCByZWFzb24gdG8gc3VwcG9ydCB0aGlzIG9uIG9sZCBrZXJuZWxzIHlvdSBj b3VsZC4KPj4+Pj4KPj4+Pj4gT25lIHByb2JsZW0gd2l0aCBzdXBwb3J0aW5nIHRoaXMgZm9yIG9s ZGVyIGtlcm5lbHMgaXMgdGhhdCBpZiBhIG5vbiAwCj4+Pj4+IHNlcmlhbCBnZXRzIHNob3duIGlu IC9wcm9jL2NwdWluZm8gd2l0aCBvbGRlciBhdGFnIGJvb3RlZCBrZXJuZWxzLCB3ZQo+Pj4+PiBz aG91bGQgcmVhbGx5IHNob3cgdGhlIHNhbWUgbnVtYmVyIGluIC9wcm9jL2NwdWluZm8gd2hpY2gg bWVhbnMgYWRkaW5nCj4+Pj4+IGNvZGUgdG8gdGhlIGtlcm5lbCB0byBnZXQgdGhlIGRldmljZXRy ZWUgInNlcmlhbC1udW1iZXIiIHN0cmluZyBwcm9wZXJ0eQo+Pj4+PiBhbmQgc29tZWhvdyBwdXQg dGhhdCBpbnRvIHRoZSA2NCBiaXRzIHdoaWNoIHdlIGhhdmUgaW4gL3Byb2MvY3B1aW5mbywKPj4+ Pj4gYnV0IGdpdmVuIHRoYXQgdGhlICJzZXJpYWwtbnVtYmVyIiBzdHJpbmcgY291bGQgYmUgaGV4 IG9yIGRlY2ltYWwgb3IKPj4+Pj4gd2hhdCBldmVyIGFuZCA+IDY0IGJpdHMgdGhhdCB3aWxsIGxp a2VseSByZXF1aXJlIGEgcGxhdGZvcm0gc3BlY2lmaWMKPj4+Pj4gc29sdXRpb24uIEFsbCBkb2Fi bGUsIGJ1dCB0aGUgcXVlc3Rpb24gdGhlbiBiZWNvbWVzIGlzIHRoaXMgd29ydGggdGhlCj4+Pj4+ IGVmZm9ydCA/Cj4+Pj4KPj4+PiBBZnRlciBpbnZlc3RpZ2F0aW5nIGEgYml0IG1vcmUsIEkgZm91 bmQgb3V0IHRoYXQgdGhlIFVTQiBzZXJpYWwgbnVtYmVyCj4+Pj4gaXMgZXhwZWN0ZWQgdG8gYmUg YSBzdHJpbmcgb2YgMzIgYnl0ZXMsIHNvIGEgMTI4IGJpdCBudW1lcmljIHNlcmlhbAo+Pj4+IGRv ZXNuJ3QgZml0IChpdCB0YWtlcyAzMiBieXRlcyBmb3IgdGhlIGhleCByZXByZXNlbnRhdGlvbiBv ZiAxMjggYml0cywKPj4+PiBzbyB0aGVyZSBpcyBubyByb29tIGxlZnQgZm9yIHRoZSB0ZXJtaW5h dGluZyBudWxsIGJ5dGUpLCBoZW5jZSBpdCBtYWtlcwo+Pj4+IHNlbnNlIHRvIGtlZXAgYSA2NCBi aXQgbGltaXRhdGlvbiBmb3IgdGhlIHNlcmlhbCBudW1iZXIsIGlmIHVzZXJzIGFyZQo+Pj4+IGdv aW5nIHRvIHJlbHkgb24gaXQgYXMgVVNCIHNlcmlhbCBzdHJpbmcuIE1vcmVvdmVyLCBpdCBzZWVt cyB0aGF0Cj4+Pj4gQW5kcm9pZCBkZXZpY2VzIGFyZSBtb3N0bHkgdXNlZCA2NCBiaXQgbnVtYmVy cyBmb3Igc2VyaWFsIG51bWJlcnMvCj4+Pj4KPj4+PiBJIHdhcyBpbml0aWFsbHkgZ29pbmcgdG8g c3VnZ2VzdCB0aGF0IHdlIHNldCBpdCBpbiBzdG9uZSB0aGF0IHNlcmlhbAo+Pj4+IG11c3QgYmUg NjQgbnVtZXJpYyBiaXRzIChhcyBpdCB3YXMgaW4gdGhlIEFUQUdzIGRheXMpIGFuZCB0aGF0Cj4+ Pj4gYm9vdGxvYWRlcnMgd291bGQgcGFzcyBpdCB0aGF0IHdheSB0byB0aGUga2VybmVsIHRocm91 Z2ggZGV2aWNlIHRyZWUKPj4+PiAod2l0aCB0d28gMzIgYml0cyBudW1lcmljIGludGVnZXJzKSwg YnV0IEhhbnMgdGFsa2VkIG1lIG91dCBvZiBpdC4KPj4+PiBJIGp1c3Qgd2FudCB0byBleHBvc2Ug dGhlIHNpdHVhdGlvbiAoZXNwZWNpYWxseSB0aGUgVVNCIGFuZCBBbmRyb2lkCj4+Pj4gdGhpbmcp IGhlcmUgdG8gZG91YmxlLWNoZWNrIHRoYXQgZXZlcnlvbmUgc3RpbGwgaXMgY29udmluY2VkIHRo YXQgYQo+Pj4+IHN0cmluZyBhcHByb2FjaCBpbiBkZXZpY2UgdHJlZSBpcyBiZXN0ICh3aGljaCBp cyBmaW5lIHdpdGggbWUpLgo+Pj4KPj4+IFRoZXJlIGFyZSBhbHJlYWR5IGV4aXN0aW5nIHVzZXJz IG9mIHRoZSBzZXJpYWwtbnVtYmVyIHByb3BlcnR5IGluIGRldmljZXRyZWUsCj4+PiBhbmQgdGhl c2UgYWxyZWFkeSB1c2UgYSBmcmVlLWZvcm1hdCBzdHJpbmcsIHNvIEFGQUlDVCB3ZSBoYXZlIG5v IGNob2ljZQo+Pj4gYnV0IHRvIGRvIHRoZSBzYW1lIGFzIHRoZSBleGlzdGluZyB1c2Vycy4KPj4+ Cj4+PiBCdXQgUm9iIGlzIHRoZSBleHBlcnQgaGVyZSwgc28gbGV0cyBzZWUgd2hhdCBSb2IgaGFz IHRvIHNheS4KPj4+Cj4+Pj4gVGhpcyB3YXksIHVzZXJzIHRoYXQgc3RpbGwgd2FudCB0byB1c2Ug dGhlIHNlcmlhbCBwYXNzZWQgdGhyb3VnaCBkZXZpY2UKPj4+PiB0cmVlIGFzIGEgVVNCIHNlcmlh bCBudW1iZXIgd2lsbCBoYXZlIHRvIHVzZSBhIHN0cmluZyBvZiAzMiBiaXRzLAo+Pj4+IGluY2x1 ZGluZyB0aGUgbnVsbCB0ZXJtaW5hdGluZyBieXRlICh3aGljaCBpcyB3aGF0IEknbGwgc3VnZ2Vz dCBmb3IKPj4+PiBzdW54aSBieSB1c2luZyBvbmx5IDY0IGJpdHMgZm9yIHRoZSBzZXJpYWwgbnVt YmVyKS4KPj4+Pgo+Pj4+IEFsc28sIEkgc3VnZ2VzdCB0aGF0IHdlIHNob3cgdGhhdCBzZXJpYWwt bnVtYmVyIHN0cmluZyBhcy1pcyBpbiBjcHVpbmZvCj4+Pj4gYXMgd2VsbAo+Pj4KPj4+IFdlIGNh bm5vdCBkbyB0aGF0IGJlY2F1c2Ugd2UgbXVzdCBndWFyYW50ZWUgdGhhdCB0aGUgc2VyaWFsIHNo b3duCj4+PiBpbiBjcHUgaW5mbyBpcyBhIDY0IGJpdHMgLyAxNiBoZXggdmFsdWVzICgwIHBhZGRl ZCkgbnVtYmVyLCBhbnl0aGluZwo+Pj4gZWxzZSB3b3VsZCBicmVhayB0aGUga2VybmVsIDwtPiB1 c2Vyc3BhY2UgQVBJIGFuZCBwb3RlbnRpYWxseSBicmVhawo+Pj4gdXNlcnNwYWNlIGFwcHMuIFNv IHdlIG11c3QgZG8gdGhlIGRldmljZXRyZWUgLT4gc2VyaWFsbnVtYmVyIGxvdy9oaWdoCj4+PiAt PiAvcHJvYy9jcGluZm8gdmVyc2lvbiB0byBndWFyYW50ZWUgdGhhdCB0aGlzIGZvcm1hdCBkb2Vz IG5vdCBjaGFuZ2UuCj4+Pgo+Pj4gQW5kIGFzIGRpc2N1c3NlZCBiZWZvcmUgaWYgeW91IHdhbnQg YSBub24gMCBzZXJpYWwgaW4gY3B1aW5mbyB0aGVuCj4+PiB0aGUgZGV2aWNldHJlZSAtPiBzZXJp YWxudW1iZXIgbG93L2hpZ2ggc2hvdWxkIGJlIGRvbmUgaW4gc3VueGkKPj4+IHNwZWNpZmljIGtl cm5lbCBjb2RlLCBhcyBvbiBzdW54aSB3ZSB3aWxsIGtub3cgdGhhdCB0aGUgc3RyaW5nIGluCj4+ PiBkZXZpY2V0cmVlIHdpbGwgYmUgYSBoZXggdmFsdWUsIGJ1dCB3ZSd2ZSBubyBzdWNoIGd1YXJh bnRlZSBmb3IKPj4+IG90aGVyIHBsYXRmb3Jtcywgc28gd2UgY2Fubm90IHNpbXBseSBoYXZlIGEg Z2VuZXJpYyBmdW5jdGlvbiB0bwo+Pj4gcG9wdWxhdGUgZXJpYWxudW1iZXIgbG93L2hpZ2ggZnJv bSB0aGUgZGV2aWNldHJlZSBzZXJpYWwtbnVtYmVyCj4+PiBzdHJpbmcuCj4+Pgo+Pj4gICA+IGFu ZCBpbnN0ZWFkIG1ha2UgYSBzdHJpbmcgb3V0IG9mIHRoZSBzZXJpYWwgQVRBRyBpbiB0aGUga2Vy bmVsCj4+Pj4gcHJpb3IgdG8gc2hvd2luZyBpdCBpbiBjcHVpbmZvIChhcyBvcHBvc2VkIHRvIHRy YW5zbGF0aW5nIHRoZSBzdHJpbmcKPj4+PiBjb21pbmcgZnJvbSBkZXZpY2UgdHJlZSB0byBhIG51 bWVyaWMgdmFsdWUgdGhhdCBjcHVpbmZvIHdpbGwgZW5kIHVwCj4+Pj4gc2hvd2luZyBhcyBhIHN0 cmluZyBhdCB0aGUgZW5kIG9mIHRoZSBkYXkpLiBUaHVzLCB0aGUgc2VyaWFsIG51bWJlcgo+Pj4+ IGNvbWluZyBmcm9tIGRldmljZSB0cmVlIHdpbGwgc3RpbGwgYmUgc2hvd24gaW4gY3B1aW5mbyBh cyB3ZWxsIGFuZCBubwo+Pj4+IEFCSSBnZXRzIGJyb2tlbi4KPj4+Cj4+PiBZb3UncmUgZm9yZ2V0 dGluZyB0aGUgdXNlcnNwYWNlIDwtPiBrZXJuZWwgQUJJIGhlcmUsIHRoZSBzZXJpYWwgbGluZQo+ Pj4gaW4gL3Byb2MvY3B1aW5mbyBpcyBub3QgYSBmcmVlIGZvcm0gc3RyaW5nIGl0IGlzIGEgNjQg Yml0IGludCBzaG93bgo+Pj4gYXMgMCBwYWRkZWQgaGV4LCBhbmQgd2UgY2Fubm90IGNoYW5nZSB0 aGF0IGFzIGNoYW5naW5nIHRoYXQgd291bGQgYmUKPj4+IGFuIEFCSSBicmVhay4KPj4KPj4gSU1I TyB0aGlzIHJlYWxseSBpcyBhbGwgYWJvdXQgaW50ZXJwcmV0YXRpb24uIElmIHlvdSBjb25zaWRl ciB0aGF0IHRoZQo+PiBzZXJpYWwgaXMgYWxyZWFkeSBhICpzdHJpbmcqIGFuZCBub3QgYSBoZXgt cmVwcmVzZW50YXRpb24gb2YgYSBudW1iZXIKPj4gKHdoaWNoIGl0IGlzIHdoZW4gdXNpbmcgQVRB R3MsIGJ1dCBoYXMgbm8gcmVhc29uIHRvIGJlIGluIGdlbmVyYWwpLCB0aGVuCj4+IG15IHN1Z2dl c3Rpb24gd2lsbCBpbnRyb2R1Y2Ugbm8gQUJJIGJyZWFrLgo+Pgo+PiBHZW5lcmFsbHkgc3BlYWtp bmcsIEkgZm91bmQgbm8gZG9jdW1lbnRhdGlvbiB0aGF0IGluZGljYXRlcyB0aGF0IHRoZQo+PiBz ZXJpYWwgaGFzIHRvIGJlIGluIHRoYXQgZm9ybWF0LiBJdCBqdXN0IGhhcHBlbnMgdG8gYmUgdGhl IGNhc2Ugd2hlbgo+PiB1c2luZyBBVEFHcy4KPj4KPj4gQWxzbywgSSBmb3VuZCBhbiBlbWFpbCBm cm9tIFJvYiBzdWdnZXN0aW5nIGhlIHdvdWxkIGJlIGZpbmUgd2l0aCB3aXJpbmcKPj4gdGhlIGR0 cyBzZXJpYWwtbnVtYmVyIHN0cmluZyB0byBjcHVpbmZvOgo+PiBodHRwOi8vbGttbC5pdS5lZHUv aHlwZXJtYWlsL2xpbnV4L2tlcm5lbC8xNDEyLjAvMDI5NzUuaHRtbAo+Pgo+PiBJIHRoaW5rIGl0 J3MgdGhlIG1vc3QgZmxleGlibGUgc29sdXRpb24gYW5kIHdlIGNhbiB0aGluayBvZiBpdCBhcyBh bgo+PiBleHRlbnNpb24gb2YgdGhlIGN1cnJlbnQgc2NoZW1lOiB0aGUgc2VyaWFsIHN0cmluZyB3 aWxsIG5vIGxvbmdlciBiZQo+PiBsaW1pdGVkIHRvIGEgaGV4IHJlcHJlc2VudGF0aW9uIG9mIGEg bnVtYmVyIGJ1dCBjYW4gYmVjb21lIGFueSBzdHJpbmcuCj4+Cj4+IE5vdyBJIHdvdWxkIGFwcHJl Y2lhdGUgaXQgaWYgUm9iIGNvdWxkIHdlaWdoLWluIGFuZCBzdGF0ZSB3aGV0aGVyIGhlCj4+IGNo YW5nZWQgaGlzIG1pbmQgb24gdGhpcyBvciBub3QuCj4KPiBUaGUgb25seSBBQkkgaXMgb24gcGxh dGZvcm1zIHRoYXQgdXNlZCBBVEFHUyBhcyBhbnkgRFQgb25seSBwbGF0Zm9ybQo+IGhhcyBzbyBm YXIgaGFkIGEgc2VyaWFsIyBpbiBjcHVpbmZvIG9mIDE2IDAncy4gV2l0aCBhIHZhcmlhYmxlIGxl bmd0aAo+IHN0cmluZyB3ZSBjYW4gc3RpbGwgaGF2ZSBhIGZpeGVkIDE2IGNoYXIgaGV4IHNlcmlh bCBudW1iZXIgdGhhdCBpcwo+IGNvbXBhdGlibGUgd2l0aCBBVEFHUy4gSSBjYW4ndCBpbWFnaW5l IHRoYXQgd2UgaGF2ZSB1c2Vyc3BhY2UgdGhhdAo+IGNhcmVzIGFib3V0IHRoZSBsZW5ndGggYW5k IHlldCBkb2Vzbid0IGNhcmUgdGhlIHZhbHVlIGlzIGFsd2F5cyAwJ3MKPiBzaW5jZSBjb252ZXJ0 aW5nIHRvIERULiBBcyBsb25nIGFzIHdlIGtlZXAgMTYgMCdzIGFzIHRoZSBkZWZhdWx0IEkKPiBk b24ndCBzZWUgYW4gaXNzdWUgd2l0aCBhbGxvd2luZyBvdGhlciBsZW5ndGhzLgoKVGhlcmUgYXJl IDIgcHJvYmxlbXMgd2l0aCBwbGF5aW5nIGFyb3VuZCB3aXRoIHRoZSBzZXJpYWwgbGluZSBpbgov cHJvYy9jcHVpbmZvOgoKMSkgTGVuZ3RoLCBjdXJyZW50bHkgaXQgaXMgYWx3YXlzIDE2IGNoYXJz LCBtYWtpbmcgaXQgZWl0aGVyIHNob3J0ZXIKb3IgbG9uZ2VyIG1heSBicmVhayBzb21lIHVzZXJz cGFjZSBwYXJzaW5nIGNvZGUgZm9yIGl0LgoKMikgQ29udGVudHMsIGN1cnJlbnRseSBpdCBpcyBh bHdheXMgaW4gaGV4LCBzbyB3ZSBjYW5ub3Qgc2ltcGx5CmNvcHkgYSBzdHJpbmcgZnJvbSBkZXZp Y2V0cmVlIGluIHRoZXJlIHdpdGhvdXQgdmVyaWZ5aW5nIHRoYXQgdGhhdApzdHJpbmcgY29udGFp bnMgaGV4LgoKTm93IGlmIHdlIHdlcmUgdG8gYWRkIGNvZGUgdG86CjEpIFZlcmlmeSB0aGF0IHRo ZSBzZXJpYWwgZnJvbSBkZXZpY2V0cmVlIGlzIGhleAoyKSBUcnVuY2F0ZSBpdCB0byAxNiBjaGFy cyBtYXgKClRoYXQgd291bGQgd29yaywgdGhlIGVhc2llc3Qgd2F5IHRvIGdldCB0aGVyZSBpcyB0 byBzaW1wbHkgc3RvcmUKdGhlIHNlcmlhbCBmcm9tIGRldmljZXRyZWUgaW4gdGhlIGV4aXN0aW5n IHNlcmlhbCBsb3cgYW5kIGhpZ2gKMzIgYml0IGludHMuCgo+IEl0IGlzIG9ubHkgYW4gQUJJIGlm IHNvbWVvbmUgbm90aWNlcyBhbmQgaWYgd2UgZmluZCBhbiBBQkkgaXNzdWUgbGF0ZXIKPiB3ZSBj YW4gYWx3YXlzIGZpeCBpdC4KCkVybSwgbm8gaXQgaXMgYW4gQUJJIG9uY2UgaXQgaGFzIHNoaXBw ZWQsIGFuZCB3ZSBjYW5ub3QgYWx3YXlzIGZpeCBpdCBsYXRlcgpiZWNhdXNlIGluIHRoZSBtZWFu IHRpbWUgb3RoZXIgYXBwcyBtYXkgaGF2ZSBzdGFydGVkIGRlcGVuZGluZyBvbiB0aGUgbmV3CkFC SSBhbmQgdGhlbiB3ZSd2ZSBhIGJpZyBwcm9ibGVtLgoKVGhlcmUgYXJlIHBsZW50eSBvZiBleGFt cGxlcyBvZiAiaW5ub2NlbnQiIGNoYW5nZXMgdG8gZmlsZXMgaW4gL3Byb2MKYnJlYWtpbmcgc3R1 ZmYsIHNvIHdlIHJlYWxseSByZWFsbHkgc2hvdWxkIGJlIGNhcmVmdWwgaGVyZS4KCkFsc28gSSBk b24ndCBzZWUgd2h5IHRoaXMgaXMgdGhhdCBpbXBvcnRhbnQgYXQgYWxsLCB3ZSBjYW4gbGltaXQK dGhpbmdzIHRvIG5vdCBicmVhayB0aGUgQUJJIGFuZCBhcHBzIHdobyB3YW50IHRoZSBmdWxsIHNl cmlhbCBpbgp0aGUgb3JpZ2luYWwgc3RyaW5nIGZvcm1hdCBjYW4gYWx3YXlzIGdldCBpdCBmcm9t Cgovc3lzL2Zpcm13YXJlL2RldmljZXRyZWUvYmFzZS9zZXJpYWwtbnVtYmVyCgpSZWdhcmRzLAoK SGFucwoKCgo+Cj4gUm9iCj4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KVS1Cb290IG1haWxpbmcgbGlzdApVLUJvb3RAbGlzdHMuZGVueC5kZQpodHRwOi8v bGlzdHMuZGVueC5kZS9tYWlsbWFuL2xpc3RpbmZvL3UtYm9vdAo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Date: Fri, 27 Mar 2015 09:36:21 +0100 Subject: [U-Boot] serial atag tag in devicetree ? In-Reply-To: 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> Message-ID: <55151685.3060404@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 27-03-15 05:30, Rob Herring wrote: > On Thu, Mar 26, 2015 at 4:11 AM, Paul Kocialkowski wrote: >> Le jeudi 26 mars 2015 ? 09:53 +0100, Hans de Goede a ?crit : >>> 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. >> >> 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), then >> 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. > > 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. There are 2 problems with playing around with the serial line in /proc/cpuinfo: 1) Length, currently it is always 16 chars, making it either shorter or longer may break some userspace parsing code for it. 2) Contents, currently it is always in hex, so we cannot simply copy a string from devicetree in there without verifying that that string contains hex. Now if we were to add code to: 1) Verify that the serial from devicetree is hex 2) Truncate it to 16 chars max That would work, the easiest way to get there is to simply store the serial from devicetree in the existing serial low and high 32 bit ints. > It is only an ABI if someone notices and if we find an ABI issue later > we can always fix it. Erm, no it is an ABI once it has shipped, and we cannot always fix it later because in the mean time other apps may have started depending on the new ABI and then we've a big problem. There are plenty of examples of "innocent" changes to files in /proc breaking stuff, so we really really should be careful here. Also I don't see why this is that important at all, we can limit things to not break the ABI and apps who want the full serial in the original string format can always get it from /sys/firmware/devicetree/base/serial-number Regards, Hans > > Rob >