From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sekhar Nori Subject: Re: [PATCH v3 1/2] rtc: omap: update of_device_id to reflect latest ip revisions Date: Fri, 23 Aug 2013 14:20:44 +0530 Message-ID: <52172264.3070000@ti.com> References: <1376653017-21935-1-git-send-email-gururaja.hebbar@ti.com> <1376653017-21935-2-git-send-email-gururaja.hebbar@ti.com> <520E341D.4080206@baylibre.com> <520E482A.1070504@ti.com> <520E5444.1000700@baylibre.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <520E5444.1000700-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: Errors-To: davinci-linux-open-source-bounces-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org To: Benoit Cousson Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org, a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org, davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org, rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org, rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org, grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: linux-omap@vger.kernel.org SGkgQmVub2l0LAoKRGlkIHlvdSBnZXQgYSBjaGFuY2UgdG8gdGhpbmsgYWJvdXQgdGhpcywgSSBo YXZlIHByb3ZpZGVkIHNvbWUgcmVwbGllcwpiZWxvdy4KCk9uIEZyaWRheSAxNiBBdWd1c3QgMjAx MyAxMDowMyBQTSwgQmVub2l0IENvdXNzb24gd3JvdGU6Cj4gSGkgU2VraGFyLAo+IAo+IE9uIDE2 LzA4LzIwMTMgMTc6NDEsIFNla2hhciBOb3JpIHdyb3RlOgo+Pgo+PiBPbiA4LzE2LzIwMTMgNzo0 NSBQTSwgQmVub2l0IENvdXNzb24gd3JvdGU6Cj4+PiBIaSBHdXJ1cmFqYSwKPj4+Cj4+PiBPbiAx Ni8wOC8yMDEzIDEzOjM2LCBIZWJiYXIsIEd1cnVyYWphIHdyb3RlOgo+Pj4+IFRoZSBzeW50YXgg b2YgY29tcGF0aWJsZSBwcm9wZXJ0eSBpbiBEVCBpcyB0byBtZW50aW9uIHRoZSBNb3N0IHNwZWNp ZmljCj4+Pj4gbWF0Y2ggdG8gbW9zdCBnZW5lcmljIG1hdGNoLgo+Pj4+Cj4+Pj4gU2luY2UgQU0z MzV4IGlzIHRoZSBwbGF0Zm9ybSB3aXRoIGxhdGVzdCBJUCByZXZpc2lvbiwgYWRkIGl0IDFzdCBp bgo+Pj4+IHRoZSBkZXZpY2UgaWQgdGFibGUuCj4+Pgo+Pj4gSSBkb24ndCB1bmRlcnN0YW5kIHdo eT8gVGhlIG9yZGVyIHNob3VsZCBub3QgbWF0dGVyIGF0IGFsbC4KPj4KPj4gWWVzLCBpdCBzaG91 bGQgbm90LiBXZSBhcmUgdHJ5aW5nIHRvIHdvcmsgYXJvdW5kIGEgYnVnIGluIHRoZSBrZXJuZWwK Pj4gd2hlcmUgdGhlIGNvbXBhdGlibGUgb3JkZXIgaXMgbm90IGhvbm9yZWQgKGluc3RlYWQgdGhl IG9yZGVyIGluCj4+IG9mX21hdGNoW10gYXJyYXkgbWF0dGVycykuIFRoZXJlIHdlcmUgcGF0Y2hl cyBiZWluZyBkaXNjdXNzZWQgdG8gZml4IHRoaXMuCj4+Cj4+Pgo+Pj4gSSd2ZSB0cmllZCB0byBm b2xsb3cgdGhlIHRocmVhZCB5b3UgaGFkIHdpdGggTWFyayBvbiB0aGUgdjIsIGJ1dCBBRkFJSywK Pj4+IHlvdSd2ZSBuZXZlciBhbnN3ZXJlZCB0byBoaXMgbGF0ZXN0IHF1ZXN0aW9uLgo+Pj4KPj4+ IE1vcmVvdmVyLCBjaGVja2luZyB0aGUgZGlmZmVyZW5jZXMgYmV0d2VlbiB0aGUgRGF2aW5jaSBh bmQgdGhlIGFtMzM1Mgo+Pj4gUlRDIElQLCBJIHdvdWxkIG5vdCBjbGFpbSB0aGF0IGJvdGggYXJl IGNvbXBhdGlibGUuCj4+Pgo+Pj4gU3VyZSB5b3UgY2FuIHVzZSB0aGUgYW0zMzUyIHdpdGggdGhl IERhdmluY2kgZHJpdmVyLCBidXQgeW91IHdpbGwgbG9zZQo+Pj4gdGhlIHdha2V1cCBmdW5jdGlv bmFsaXR5IHdpdGhvdXQgZXZlbiBiZWluZyBub3RpZnkgYWJvdXQgdGhhdC4KPj4KPj4gV2hlbiB0 aGUga2VybmVsIGlzIGZpeGVkIGZvciB0aGUgYnVnIHBvaW50ZWQgb3V0IGFib3ZlLCB0aGlzIHNo b3VsZCBub3QKPj4gaGFwcGVuIHdpdGggcHJvcGVybHkgZGVmaW5lZCBjb21wYXRpYmxlIHByb3Bl cnR5Lgo+Pgo+Pj4KPj4+IEZvciBteSBwb2ludCBvZiB2aWV3LCBjb21wYXRpYmxlIG1lYW4gdGhh dCB0aGUgSFcgd2lsbCBzdGlsbCBiZSBmdWxseQo+Pj4gZnVuY3Rpb25hbCB3aXRoIGJvdGggdmVy c2lvbnMgb2YgdGhlIGRyaXZlciwgd2hpY2ggaXMgbm90IHRoZSBjYXNlIGhlcmUuCj4+Cj4+IEkg ZG8gbm90IHRoaW5rIHRoYXQncyB0aGUgaW50ZXJwcmV0YXRpb24gb2YgY29tcGF0aWJsZS4gSXRz IGdvZXMgZnJvbQo+PiBtb3N0IHNwZWNpZmljIHRvIG1vc3QgZ2VuZXJpYyBwZXIgdGhlIGVQQVBS IHNwZWMuIFRoYXQgaW4gaXRzZWxmIHNheXMKPj4gdGhhdCAxMDAlIGZ1bmN0aW9uYWxpdHkgaXMg bm90IGV4cGVjdGVkIGlmIHlvdSBkb24ndCBmaW5kIGEgbWF0Y2ggZm9yCj4+IHRoZSBtb3JlIHNw ZWNpZmljIHByb3BlcnR5Lgo+IAo+IFdlbGwsIHRvIGJlIGhvbmVzdCBJIGNoZWNrZWQgYXMgd2Vs bCB0aGUgb2ZmaWNpYWwgZG9jdW1lbnRhdGlvbiwgYW5kIHRoaXMgaXMgZmFyIGZyb20gYmVpbmcg Y2xlYXI6Cj4gCj4gcGFnZSAyMSBvZiB0aGUgZVBBUFI6Cj4gCj4gIgo+IFByb3BlcnR5OiBjb21w YXRpYmxlCj4gVmFsdWUgdHlwZTogPHN0cmluZ2xpc3Q+Cj4gCj4gRGVzY3JpcHRpb246Cj4gIFRo ZSBjb21wYXRpYmxlIHByb3BlcnR5IHZhbHVlIGNvbnNpc3RzIG9mIG9uZSBvciBtb3JlIHN0cmlu Z3MgdGhhdCBkZWZpbmUgdGhlIHNwZWNpZmljIAo+ICBwcm9ncmFtbWluZyBtb2RlbCBmb3IgdGhl IGRldmljZS4gVGhpcyBsaXN0IG9mIHN0cmluZ3Mgc2hvdWxkIGJlIHVzZWQgYnkgYSBjbGllbnQg cHJvZ3JhbSBmb3IKPiAgZGV2aWNlIGRyaXZlciBzZWxlY3Rpb24uIFRoZSBwcm9wZXJ0eSB2YWx1 ZSBjb25zaXN0cyBvZiBhIGNvbmNhdGVuYXRlZCBsaXN0IG9mIG51bGwgdGVybWluYXRlZAo+ICBz dHJpbmdzLCBmcm9tIG1vc3Qgc3BlY2lmaWMgdG8gbW9zdCBnZW5lcmFsLiBUaGV5IGFsbG93IGEg ZGV2aWNlIHRvIGV4cHJlc3MgaXRzIGNvbXBhdGliaWxpdHkKPiAgd2l0aCBhIGZhbWlseSBvZiBz aW1pbGFyIGRldmljZXMsIHBvdGVudGlhbGx5IGFsbG93aW5nIGEgc2luZ2xlIGRldmljZSBkcml2 ZXIgdG8gbWF0Y2ggYWdhaW5zdAo+ICBzZXZlcmFsIGRldmljZXMuCj4gIAo+ICBUaGUgcmVjb21t ZW5kZWQgZm9ybWF0IGlzIOKAnG1hbnVmYWN0dXJlcixtb2RlbOKAnSwgd2hlcmUgbWFudWZhY3R1 cmVyIGlzIGEKPiAgc3RyaW5nIGRlc2NyaWJpbmcgdGhlIG5hbWUgb2YgdGhlIG1hbnVmYWN0dXJl ciAoc3VjaCBhcyBhIHN0b2NrIHRpY2tlciBzeW1ib2wpLCBhbmQgbW9kZWwKPiAgc3BlY2lmaWVz IHRoZSBtb2RlbCBudW1iZXIuCj4gCj4gRXhhbXBsZToKPiAgY29tcGF0aWJsZSA9IOKAnGZzbCxt cGM4NjQxLXVhcnTigJ0sIOKAnG5zMTY1NTAiOwo+ICBJbiB0aGlzIGV4YW1wbGUsIGFuIG9wZXJh dGluZyBzeXN0ZW0gd291bGQgZmlyc3QgdHJ5IHRvIGxvY2F0ZSBhIGRldmljZSBkcml2ZXIgdGhh dCBzdXBwb3J0ZWQKPiAgZnNsLG1wYzg2NDEtdWFydC4gSWYgYSBkcml2ZXIgd2FzIG5vdCBmb3Vu ZCwgaXQgd291bGQgdGhlbiB0cnkgdG8gbG9jYXRlIGEgZHJpdmVyIHRoYXQgc3VwcG9ydGVkCj4g IHRoZSBtb3JlIGdlbmVyYWwgbnMxNjU1MCBkZXZpY2UgdHlwZS4KPiAiCj4gCj4gSW4gdGhpcyBl eGFtcGxlLCB0aGUgZ2VuZXJpYyB2cyBzcGVjaWZpYyBpcyBqdXN0IGFib3V0IHRoZSBkcml2ZXIu IFlvdSBjb3VsZCBoYXZlIG9uZSBkcml2ZXIgdGhhdCBtYW5hZ2UgMTAgZGlmZmVyZW50IFVBUlRz IG9yIGEgc3BlY2lmaWMgb25lIHRoYXQgbWFuYWdlIG9ubHkgeW91ciBIVy4gCgpSaWdodCwgdGhl IGFzc3VtcHRpb24gaXMgdGhhdCBhIHNwZWNpZmljIGRyaXZlciBpcyB3cml0dGVuIGJlY2F1c2Ug dGhlcmUKYXJlIHBhcnRzIG9mIHRoZSBoYXJkd2FyZSB0aGF0IGNhbm5vdCBiZSBzZXJ2aWNlZCBi eSBnZW5lcmljIGRyaXZlci4gU28KdWx0aW1hdGVseSBpdHMgYWxsIGRyaXZlbiBieSBjaGFuZ2Vz IGluIGhhcmR3YXJlLgoKPiAKPiBUaGVyZSBpcyBubyBhc3N1bXB0aW9uIGFib3V0IHRoZSBsb3N0 IG9mIGZ1bmN0aW9uYWxpdHkgYnkgdXNpbmcgdGhlIGdlbmVyaWMgdmVyc2lvbiBvZiB0aGUgZHJp dmVyLiBIb3cgdGhlIHVzZXIgaXMgc3VwcG9zZWQgdG8ga25vdyB0aGUgYW1vdW50IG9mIGZ1bmN0 aW9uYWxpdHkgaGUgd2lsbCBsb3NlLCBhbmQgaWYgdGhpcyBpcyBhY2NlcHRhYmxlIHRvIGhpbS4K Ckkgc3VwcG9zZSB0aGUgZ2VuZXJpYyBkcml2ZXIgd291bGQgcmV0dXJuIHNvbWUgZXJyb3IgY29k ZSBsaWtlIC1FTk9UU1VQCmZvciB0aGUgZnVuY3Rpb25hbGl0eSBpdCBjYW5ub3QgcHJvdmlkZS4K Cj4gSSdkIHJhdGhlciBoYXZlIGFuIGVycm9yIGF0IGJvb3Qgc2F5aW5nIHRoYXQgdGhlIGRyaXZl ciBpcyBub3QgY29tcGF0aWJsZSB3aXRoIHRoZSBIVyBhbmQgdGh1cyBJIHdpbGwgaGF2ZSB0byB1 cGdyYWRlIHRoZSBrZXJuZWwsIHRoYW4gYm9vdGluZyBhIGtlcm5lbCB0aGF0IHdpbGwgbm90IHdv cmsgYXMgZXhwZWN0ZWQgYmVjYXVzZSBzb21lIGZ1bmN0aW9uYWxpdHkgYXJlIG1pc3NpbmcgZm9y IHRoYXQgc3BlY2lmaWMgSFcuCgpJZiB5b3UgaGF2ZSBhbiB1cGRhdGUgYXZhaWxhYmxlLCB5b3Ug Y2FuIGFsd2F5cyB1cGdyYWRlIHRvIGl0LiBCdXQgd2hhdAppZiB0aGVyZSBpcyBubyB1cGRhdGUg YXZhaWxhYmxlPyBXb3VsZCB5b3UgcmF0aGVyIG5vdCBoYXZlIHRoZSB1c2VyIHVzZQp0aGUgYXZh aWxhYmxlIGZ1bmN0aW9uYWxpdHkgaW4gdGhlIG1lYW53aGlsZSB3aGlsZSBoZSB3YWl0cyBmb3Ig dGhlCmtlcm5lbCBzdXBwb3J0IHRvIGJlIGRldmVsb3BlZC4KCj4gCj4gQ2xhaW1pbmcgdGhhdCBh IHBpZWNlIG9mIEhXIGlzIGNvbXBhdGlibGUgd2l0aCBhbiBvdGhlciBvbmUgdGhhdCBpcyBqdXN0 IGEgc3Vic2V0IGluIHRlcm0gb2YgZnVuY3Rpb25hbGl0eSBpcyB3cm9uZy4gWW91IGNhbiBjbGFp bSB0aGF0IHRoZSB0aSxkYTgzMC1ydGMgaXMgY29tcGF0aWJsZSB3aXRoIHRoZSB0aSxhbTMzNTIt cnRjIGRyaXZlciwgYnV0IG5vdCB0aGUgb3Bwb3NpdGUuCgpJZiB0aGlzIGlzIHdyb25nLCB0aGVu IHdoYXQgaXMgdGhlIHVzZSBvZiBjb21wYXRpYmxlIHByb3BlcnR5PyBXaHkgd291bGQKc29tZW9u ZSB3cml0ZSBhIGRyaXZlciBzdXBwb3J0aW5nIOKAnGZzbCxtcGM4NjQxLXVhcnTigJ0gaWYgMTAw JSBvZiBpdHMKaGFyZHdhcmUgZmVhdHVyZXMgYXJlIGFsc28gc3VwcG9ydGVkIGJ5IOKAnG5zMTY1 NTAiIGRyaXZlcj8KCj4+PiBhbTMzNTIgRFRTIG11c3QgdXNlIHRoZSB0aSxhbTMzNTItcnRjIHRv IGhhdmUgdGhlIGV4cGVjdGVkIGJlaGF2aW9yLgo+Pgo+PiBZZXMsIHRoYXQncyB3aGF0IHBhdGNo IDIvMiBkb2VzLgo+Pgo+Pj4gVXNpbmcgdGhlIHRpLGRhODMwLXJ0YyB2ZXJzaW9uIHdpbGwgbm90 IG1ha2UgdGhlIGJvYXJkIHdvcmtpbmcgYXMKPj4+IGV4cGVjdGVkLiBTbyB3ZSBjYW5ub3QgY2xh aW0gdGhlIGNvbXBhdGliaWxpdHkuCj4+Cj4+IElkZWFsbHksIHRoZSBEVCBmaWxlIHdhcyAqYWx3 YXlzKiB3cml0dGVuIGFzCj4+Cj4+IAljb21wYXRpYmxlID0gInRpLGFtMzM1Mi1ydGMiLCAidGks ZGE4MzAtcnRjIjsKPj4KPj4gZXZlbiB3aGVuIHRoZXJlIHdhcyBubyBrZXJuZWwgc3VwcG9ydCBm b3IgQU0zMzUyIFJUQy4KPiAKPiBZb3UgY291bGQgZG8gdGhhdCBvbmx5IGZvciB0aGUgZGF2aW5j aSBEVFMsIGJlY2F1c2UgaXQgaXMgYSBzdWJzZXQgb2YgdGhlIGFtMzM1MiBidXQgeW91IGNhbm5v dCBkbyB0aGF0IGZvciB0aGUgYW0zMzUyIGFzIGV4cGxhaW5lZCBiZWZvcmUuCgpEYVZpbmNpIERU UyB3aWxsIHVzZSBjb21wYXRpYmxlID0gInRpLGRhODMwLXJ0YyI7IFRoYXRzIG5vdCBjaGFuZ2lu Zwp3aXRoIHRoaXMgcGF0Y2hzZXQuCgo+IAo+PiBUaGF0IHdheSwgdGhlcmUgaXMgbm8gbmVlZCB0 byB1cGRhdGUgdGhlIC5kdHNbaV0gZmlsZS4gQXMga2VybmVsIGdhaW5zCj4+IGZ1bmN0aW9uYWxp dHksIG1vcmUgZmVhdHVyZXMgKGxpa2UgcnRjIHdha2UpIGlzIGF2YWlsYWJsZSB0byB1c2Vycy4K PiAKPiBXZWxsLCB5b3UgY2Fubm90IGFudGljaXBhdGUgdGhlIEhXIGV2b2x1dGlvbiBhbnl3YXkg YW5kIHlvdSBkaWQgbm90IGtub3cgd2hlbiBEYXZpbmNpIERUUyB3YXMgZG9uZSB0aGF0IGFuIGFt MzM1MiB3aWxsIGV4aXN0IGluIHRoZSBmdXR1cmUgYW5kIHJldXNlIHRoZSBzYW1lIElQLgoKWWVh aCwgSSBhbSBub3QgY2xhaW1pbmcgRGFWaW5jaSBEVFMgc2hvdWxkIGJlIHVwZGF0ZWQuIEJ1dCB3 aGVuCmFtMzM1eC5kdHNpIHdhcyB3cml0dGVuLCB0aGVyZSB3YXMga25vd2xlZGdlIHRoYXQgYSAo cG90ZW50aWFsbHkpIG5ldwp2ZXJzaW9uIG9mIFJUQyBJUCBpcyBhdmFpbGFibGUgYW5kIHRoZXJl Zm9yZSB0aGUgLmR0c2kgc2hvdWxkIGhhdmUgYmVlbgp3cml0dGVuIGFzCgoJY29tcGF0aWJsZSA9 ICJ0aSxhbTMzNTItcnRjIiwgInRpLGRhODMwLXJ0YyI7CgppbnN0ZWFkIG9mCgoJY29tcGF0aWJs ZSA9ICJ0aSxkYTgzMC1ydGMiOwoKdGhhdCBpdCBpcyB0b2RheS4gVGhpbmcgaXMsIHlvdSBjYW4g bmV2ZXIga25vdyBpZiB0aGUgSVAgbmVlZHMgYW55CmFkZGl0aW9uYWwgaGFuZGxpbmcgZXZlbiBh ZnRlciByZWFkaW5nIHRoZSBzcGVjLiBXZSBrZWVwIGRpc2NvdmVyaW5nIG5ldwpmZWF0dXJlcy9x dWlya3MuIFNvLCB3aGVuIHdyaXRpbmcgPG5ldy1zb2M+LmR0c2kgaXRzIHNhZmVyIHRvIGFsd2F5 cyB1c2UKCgljb21wYXRpYmxlID0gInRpLDxuZXctc29jPi1ydGMiLCAidGksPGNvbXBhdGlibGUt c29jPi1ydGMiOwoKZXZlbiB0aG91Z2ggX3RvZGF5XyB5b3UgbWF5IG5vdCBoYXZlIGNvZGUgdGhh dCBzcGVjaWZpY2FsbHkgaGFuZGxlcwoidGksPG5ldy1zb2M+LXJ0YyIuCgo+IE1vcmVvdmVyIERU IGlzIGEgQUJJLCBzbyBleHRlbmRpbmcgaXQgYWNjb3JkaW5nIHRvIHRoZSBIVyBmZWF0dXJlIGV2 b2x1dGlvbiBpcyBhYnNvbHV0ZWx5IG5vcm1hbC4KCllvdSBtZWFuIHRoZSBEVCBiaW5kaW5ncyBh bmQgbm90IHNwZWNpZmljYWxseSB0aGUgLmR0c1tpXSwgcmlnaHQ/IFRoZW4gSQphZ3JlZS4gSWRl YWxseSB0aGUgLmR0c1tpXSBpcyB3cml0dGVuIG9uY2UgcGVyIGhhcmR3YXJlLiBJIGtub3cgaXRz CmFsbW9zdCBpbXBvc3NpYmxlIHRvIGdldCB0aGF0IHJpZ2h0LgoKPiAKPiBFdmVyeSBTb0MgdGhh dCBhcmUgdXNpbmcgYSBSVEMgd2l0aCB0aGUgc2FtZSBwcm9ncmFtaW5nIG1vZGVsIHRoYW4gdGhl IGRhODMwIGNhbiBjbGFpbSB0aGUgY29tcGF0aWJpbGl0eS4gQSBTb0MgdGhhdCBpcyB1c2luZyBh IG5ld2VyIHZlcnNpb24gb2YgdGhlIElQIHdpdGggYW4gZXh0ZW5kZWQgcHJvZ3JhbW1pbmcgbW9k ZWwgY2Fubm90IGNsYWltIHRoYXQuCgpXZSBkaWZmZXIgaGVyZS4gQXMgbG9uZyBhcyBwcm9ncmFt bWluZyBtb2RlbCBpcyBfZXh0ZW5kZWRfLCBuZXcgSVAgaXMKc3RpbGwgY29tcGF0aWJsZSB3aXRo IG9sZC4gSWYgdGhlIHByb2dyYW1taW5nIG1vZGVsIGlzIF9jaGFuZ2VkXyB0aGVuCml0cyBub3Qu Cgo+IAo+PiBPdGhlcndpc2UgdGhleSBnZXQgcGxhaW4gUlRDIGZ1bmN0aW9uYWxpdHkgLSBidXQg YXQgbGVhc3QgdGhleSBnZXQKPj4gc29tZXRoaW5nIGluc3RlYWQgb2Ygbm8gUlRDLgo+IAo+IEJl Y2F1c2UgeW91IGFzc3VtZSB0aGF0IHRoaXMgZmVhdHVyZSBpcyBub3QgaW1wb3J0YW50IGFuZCB0 aHVzIHlvdSBjYW4gdXNlIHRoZSBwbGFpbiBSVEMsIGJ1dCB3aGF0IGlmIHNvbWVvbmUgaXMgYnV5 aW5nIHRoYXQgSFcgYmVjYXVzZSBvZiB0aGlzIG5ldyBmZWF0dXJlLiBXaXRob3V0IHRoYXQgZmVh dHVyZSBoaXMgc3lzdGVtIHdpbGwganVzdCBub3Qgd29yayBwcm9wZXJseS4KClJpZ2h0LCBidXQg dGhhdHMgbm90IGEgcHJvYmxlbSBEVCBjYW4gc29sdmUuIEhlL3NoZSBuZWVkcyB0byBoYXNzbGUg VEkKZm9yIHVwZGF0ZWQgZHJpdmVycy4gQnV0IHRoZXJlIGNvdWxkIGJlIDEwIG90aGVyIGN1c3Rv bWVycyB3aG8gYXJlIGp1c3QKb2theSB3aXRoIHBsYWluIFJUQy4gU28gdGlsbCB0aGUgdGltZSBk cml2ZXIgaXMgdXBkYXRlZCB0byB1c2UKdGksYW0zMzUyLXJ0YyIsIGFyZSB5b3Ugc2F5aW5nIG5v IG9uZSBzaG91bGQgYmUgYWJsZSB0byB1c2UgdGhlIFJUQyBvbgp0aGUgU29DIGF0IGFsbCBldmVu IHRob3VnaCA5MCUgZmVhdHVyZXMgYXJlIGF2YWlsYWJsZT8KCj4gU2F5aW5nIHRoYXQgdGhpcyBp cyBjb21wYXRpYmxlIHdoZXJlYXMgeW91IGxvc3QgZnVuY3Rpb25hbGl0eSBpcyBseWluZyB0byB0 aGUgY3VzdG9tZXIgZm9yIG15IHBvaW50IG9mIHZpZXcuCgpJZiAxMDAlIGZ1bmN0aW9uYWxpdHkg aXMgcmVxdWlyZWQgZm9yIGNvbXBhdGliaWxpdHkgdGhlbiBJIGFtIGFmcmFpZAp0aGVyZSBpcyBu b3RoaW5nIGxpa2UgImNvbXBhdGliaWxpdHkiLiBUaGVyZSBhcmUganVzdCBkaWZmZXJlbnQgaXNv bGF0ZWQKdmVyc2lvbnMuCgpUaGFua3MsClNla2hhcgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwpEYXZpbmNpLWxpbnV4LW9wZW4tc291cmNlIG1haWxpbmcg bGlzdApEYXZpbmNpLWxpbnV4LW9wZW4tc291cmNlQGxpbnV4LmRhdmluY2lkc3AuY29tCmh0dHA6 Ly9saW51eC5kYXZpbmNpZHNwLmNvbS9tYWlsbWFuL2xpc3RpbmZvL2RhdmluY2ktbGludXgtb3Bl bi1zb3VyY2UK From mboxrd@z Thu Jan 1 00:00:00 1970 From: nsekhar@ti.com (Sekhar Nori) Date: Fri, 23 Aug 2013 14:20:44 +0530 Subject: [PATCH v3 1/2] rtc: omap: update of_device_id to reflect latest ip revisions In-Reply-To: <520E5444.1000700@baylibre.com> References: <1376653017-21935-1-git-send-email-gururaja.hebbar@ti.com> <1376653017-21935-2-git-send-email-gururaja.hebbar@ti.com> <520E341D.4080206@baylibre.com> <520E482A.1070504@ti.com> <520E5444.1000700@baylibre.com> Message-ID: <52172264.3070000@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Benoit, Did you get a chance to think about this, I have provided some replies below. On Friday 16 August 2013 10:03 PM, Benoit Cousson wrote: > Hi Sekhar, > > On 16/08/2013 17:41, Sekhar Nori wrote: >> >> On 8/16/2013 7:45 PM, Benoit Cousson wrote: >>> Hi Gururaja, >>> >>> On 16/08/2013 13:36, Hebbar, Gururaja wrote: >>>> The syntax of compatible property in DT is to mention the Most specific >>>> match to most generic match. >>>> >>>> Since AM335x is the platform with latest IP revision, add it 1st in >>>> the device id table. >>> >>> I don't understand why? The order should not matter at all. >> >> Yes, it should not. We are trying to work around a bug in the kernel >> where the compatible order is not honored (instead the order in >> of_match[] array matters). There were patches being discussed to fix this. >> >>> >>> I've tried to follow the thread you had with Mark on the v2, but AFAIK, >>> you've never answered to his latest question. >>> >>> Moreover, checking the differences between the Davinci and the am3352 >>> RTC IP, I would not claim that both are compatible. >>> >>> Sure you can use the am3352 with the Davinci driver, but you will lose >>> the wakeup functionality without even being notify about that. >> >> When the kernel is fixed for the bug pointed out above, this should not >> happen with properly defined compatible property. >> >>> >>> For my point of view, compatible mean that the HW will still be fully >>> functional with both versions of the driver, which is not the case here. >> >> I do not think that's the interpretation of compatible. Its goes from >> most specific to most generic per the ePAPR spec. That in itself says >> that 100% functionality is not expected if you don't find a match for >> the more specific property. > > Well, to be honest I checked as well the official documentation, and this is far from being clear: > > page 21 of the ePAPR: > > " > Property: compatible > Value type: > > Description: > The compatible property value consists of one or more strings that define the specific > programming model for the device. This list of strings should be used by a client program for > device driver selection. The property value consists of a concatenated list of null terminated > strings, from most specific to most general. They allow a device to express its compatibility > with a family of similar devices, potentially allowing a single device driver to match against > several devices. > > The recommended format is ?manufacturer,model?, where manufacturer is a > string describing the name of the manufacturer (such as a stock ticker symbol), and model > specifies the model number. > > Example: > compatible = ?fsl,mpc8641-uart?, ?ns16550"; > In this example, an operating system would first try to locate a device driver that supported > fsl,mpc8641-uart. If a driver was not found, it would then try to locate a driver that supported > the more general ns16550 device type. > " > > In this example, the generic vs specific is just about the driver. You could have one driver that manage 10 different UARTs or a specific one that manage only your HW. Right, the assumption is that a specific driver is written because there are parts of the hardware that cannot be serviced by generic driver. So ultimately its all driven by changes in hardware. > > There is no assumption about the lost of functionality by using the generic version of the driver. How the user is supposed to know the amount of functionality he will lose, and if this is acceptable to him. I suppose the generic driver would return some error code like -ENOTSUP for the functionality it cannot provide. > I'd rather have an error at boot saying that the driver is not compatible with the HW and thus I will have to upgrade the kernel, than booting a kernel that will not work as expected because some functionality are missing for that specific HW. If you have an update available, you can always upgrade to it. But what if there is no update available? Would you rather not have the user use the available functionality in the meanwhile while he waits for the kernel support to be developed. > > Claiming that a piece of HW is compatible with an other one that is just a subset in term of functionality is wrong. You can claim that the ti,da830-rtc is compatible with the ti,am3352-rtc driver, but not the opposite. If this is wrong, then what is the use of compatible property? Why would someone write a driver supporting ?fsl,mpc8641-uart? if 100% of its hardware features are also supported by ?ns16550" driver? >>> am3352 DTS must use the ti,am3352-rtc to have the expected behavior. >> >> Yes, that's what patch 2/2 does. >> >>> Using the ti,da830-rtc version will not make the board working as >>> expected. So we cannot claim the compatibility. >> >> Ideally, the DT file was *always* written as >> >> compatible = "ti,am3352-rtc", "ti,da830-rtc"; >> >> even when there was no kernel support for AM3352 RTC. > > You could do that only for the davinci DTS, because it is a subset of the am3352 but you cannot do that for the am3352 as explained before. DaVinci DTS will use compatible = "ti,da830-rtc"; Thats not changing with this patchset. > >> That way, there is no need to update the .dts[i] file. As kernel gains >> functionality, more features (like rtc wake) is available to users. > > Well, you cannot anticipate the HW evolution anyway and you did not know when Davinci DTS was done that an am3352 will exist in the future and reuse the same IP. Yeah, I am not claiming DaVinci DTS should be updated. But when am335x.dtsi was written, there was knowledge that a (potentially) new version of RTC IP is available and therefore the .dtsi should have been written as compatible = "ti,am3352-rtc", "ti,da830-rtc"; instead of compatible = "ti,da830-rtc"; that it is today. Thing is, you can never know if the IP needs any additional handling even after reading the spec. We keep discovering new features/quirks. So, when writing .dtsi its safer to always use compatible = "ti,-rtc", "ti,-rtc"; even though _today_ you may not have code that specifically handles "ti,-rtc". > Moreover DT is a ABI, so extending it according to the HW feature evolution is absolutely normal. You mean the DT bindings and not specifically the .dts[i], right? Then I agree. Ideally the .dts[i] is written once per hardware. I know its almost impossible to get that right. > > Every SoC that are using a RTC with the same programing model than the da830 can claim the compatibility. A SoC that is using a newer version of the IP with an extended programming model cannot claim that. We differ here. As long as programming model is _extended_, new IP is still compatible with old. If the programming model is _changed_ then its not. > >> Otherwise they get plain RTC functionality - but at least they get >> something instead of no RTC. > > Because you assume that this feature is not important and thus you can use the plain RTC, but what if someone is buying that HW because of this new feature. Without that feature his system will just not work properly. Right, but thats not a problem DT can solve. He/she needs to hassle TI for updated drivers. But there could be 10 other customers who are just okay with plain RTC. So till the time driver is updated to use ti,am3352-rtc", are you saying no one should be able to use the RTC on the SoC at all even though 90% features are available? > Saying that this is compatible whereas you lost functionality is lying to the customer for my point of view. If 100% functionality is required for compatibility then I am afraid there is nothing like "compatibility". There are just different isolated versions. Thanks, Sekhar From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755023Ab3HWIzg (ORCPT ); Fri, 23 Aug 2013 04:55:36 -0400 Received: from comal.ext.ti.com ([198.47.26.152]:36813 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752553Ab3HWIzd (ORCPT ); Fri, 23 Aug 2013 04:55:33 -0400 Message-ID: <52172264.3070000@ti.com> Date: Fri, 23 Aug 2013 14:20:44 +0530 From: Sekhar Nori User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Benoit Cousson CC: "Hebbar, Gururaja" , , , , , , , , , , , , , , , Subject: Re: [PATCH v3 1/2] rtc: omap: update of_device_id to reflect latest ip revisions References: <1376653017-21935-1-git-send-email-gururaja.hebbar@ti.com> <1376653017-21935-2-git-send-email-gururaja.hebbar@ti.com> <520E341D.4080206@baylibre.com> <520E482A.1070504@ti.com> <520E5444.1000700@baylibre.com> In-Reply-To: <520E5444.1000700@baylibre.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Benoit, Did you get a chance to think about this, I have provided some replies below. On Friday 16 August 2013 10:03 PM, Benoit Cousson wrote: > Hi Sekhar, > > On 16/08/2013 17:41, Sekhar Nori wrote: >> >> On 8/16/2013 7:45 PM, Benoit Cousson wrote: >>> Hi Gururaja, >>> >>> On 16/08/2013 13:36, Hebbar, Gururaja wrote: >>>> The syntax of compatible property in DT is to mention the Most specific >>>> match to most generic match. >>>> >>>> Since AM335x is the platform with latest IP revision, add it 1st in >>>> the device id table. >>> >>> I don't understand why? The order should not matter at all. >> >> Yes, it should not. We are trying to work around a bug in the kernel >> where the compatible order is not honored (instead the order in >> of_match[] array matters). There were patches being discussed to fix this. >> >>> >>> I've tried to follow the thread you had with Mark on the v2, but AFAIK, >>> you've never answered to his latest question. >>> >>> Moreover, checking the differences between the Davinci and the am3352 >>> RTC IP, I would not claim that both are compatible. >>> >>> Sure you can use the am3352 with the Davinci driver, but you will lose >>> the wakeup functionality without even being notify about that. >> >> When the kernel is fixed for the bug pointed out above, this should not >> happen with properly defined compatible property. >> >>> >>> For my point of view, compatible mean that the HW will still be fully >>> functional with both versions of the driver, which is not the case here. >> >> I do not think that's the interpretation of compatible. Its goes from >> most specific to most generic per the ePAPR spec. That in itself says >> that 100% functionality is not expected if you don't find a match for >> the more specific property. > > Well, to be honest I checked as well the official documentation, and this is far from being clear: > > page 21 of the ePAPR: > > " > Property: compatible > Value type: > > Description: > The compatible property value consists of one or more strings that define the specific > programming model for the device. This list of strings should be used by a client program for > device driver selection. The property value consists of a concatenated list of null terminated > strings, from most specific to most general. They allow a device to express its compatibility > with a family of similar devices, potentially allowing a single device driver to match against > several devices. > > The recommended format is “manufacturer,model”, where manufacturer is a > string describing the name of the manufacturer (such as a stock ticker symbol), and model > specifies the model number. > > Example: > compatible = “fsl,mpc8641-uart”, “ns16550"; > In this example, an operating system would first try to locate a device driver that supported > fsl,mpc8641-uart. If a driver was not found, it would then try to locate a driver that supported > the more general ns16550 device type. > " > > In this example, the generic vs specific is just about the driver. You could have one driver that manage 10 different UARTs or a specific one that manage only your HW. Right, the assumption is that a specific driver is written because there are parts of the hardware that cannot be serviced by generic driver. So ultimately its all driven by changes in hardware. > > There is no assumption about the lost of functionality by using the generic version of the driver. How the user is supposed to know the amount of functionality he will lose, and if this is acceptable to him. I suppose the generic driver would return some error code like -ENOTSUP for the functionality it cannot provide. > I'd rather have an error at boot saying that the driver is not compatible with the HW and thus I will have to upgrade the kernel, than booting a kernel that will not work as expected because some functionality are missing for that specific HW. If you have an update available, you can always upgrade to it. But what if there is no update available? Would you rather not have the user use the available functionality in the meanwhile while he waits for the kernel support to be developed. > > Claiming that a piece of HW is compatible with an other one that is just a subset in term of functionality is wrong. You can claim that the ti,da830-rtc is compatible with the ti,am3352-rtc driver, but not the opposite. If this is wrong, then what is the use of compatible property? Why would someone write a driver supporting “fsl,mpc8641-uart” if 100% of its hardware features are also supported by “ns16550" driver? >>> am3352 DTS must use the ti,am3352-rtc to have the expected behavior. >> >> Yes, that's what patch 2/2 does. >> >>> Using the ti,da830-rtc version will not make the board working as >>> expected. So we cannot claim the compatibility. >> >> Ideally, the DT file was *always* written as >> >> compatible = "ti,am3352-rtc", "ti,da830-rtc"; >> >> even when there was no kernel support for AM3352 RTC. > > You could do that only for the davinci DTS, because it is a subset of the am3352 but you cannot do that for the am3352 as explained before. DaVinci DTS will use compatible = "ti,da830-rtc"; Thats not changing with this patchset. > >> That way, there is no need to update the .dts[i] file. As kernel gains >> functionality, more features (like rtc wake) is available to users. > > Well, you cannot anticipate the HW evolution anyway and you did not know when Davinci DTS was done that an am3352 will exist in the future and reuse the same IP. Yeah, I am not claiming DaVinci DTS should be updated. But when am335x.dtsi was written, there was knowledge that a (potentially) new version of RTC IP is available and therefore the .dtsi should have been written as compatible = "ti,am3352-rtc", "ti,da830-rtc"; instead of compatible = "ti,da830-rtc"; that it is today. Thing is, you can never know if the IP needs any additional handling even after reading the spec. We keep discovering new features/quirks. So, when writing .dtsi its safer to always use compatible = "ti,-rtc", "ti,-rtc"; even though _today_ you may not have code that specifically handles "ti,-rtc". > Moreover DT is a ABI, so extending it according to the HW feature evolution is absolutely normal. You mean the DT bindings and not specifically the .dts[i], right? Then I agree. Ideally the .dts[i] is written once per hardware. I know its almost impossible to get that right. > > Every SoC that are using a RTC with the same programing model than the da830 can claim the compatibility. A SoC that is using a newer version of the IP with an extended programming model cannot claim that. We differ here. As long as programming model is _extended_, new IP is still compatible with old. If the programming model is _changed_ then its not. > >> Otherwise they get plain RTC functionality - but at least they get >> something instead of no RTC. > > Because you assume that this feature is not important and thus you can use the plain RTC, but what if someone is buying that HW because of this new feature. Without that feature his system will just not work properly. Right, but thats not a problem DT can solve. He/she needs to hassle TI for updated drivers. But there could be 10 other customers who are just okay with plain RTC. So till the time driver is updated to use ti,am3352-rtc", are you saying no one should be able to use the RTC on the SoC at all even though 90% features are available? > Saying that this is compatible whereas you lost functionality is lying to the customer for my point of view. If 100% functionality is required for compatibility then I am afraid there is nothing like "compatibility". There are just different isolated versions. Thanks, Sekhar