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 21:47:15 +0530 Message-ID: <52178B0B.7090303@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> <52172264.3070000@ti.com> <52177B6C.2080406@baylibre.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <52177B6C.2080406-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 T24gOC8yMy8yMDEzIDg6NDAgUE0sIEJlbm9pdCBDb3Vzc29uIHdyb3RlOgoKPj4+IFRoZXJlIGlz IG5vIGFzc3VtcHRpb24gYWJvdXQgdGhlIGxvc3Qgb2YgZnVuY3Rpb25hbGl0eSBieSB1c2luZyB0 aGUKPj4+IGdlbmVyaWMgdmVyc2lvbiBvZiB0aGUgZHJpdmVyLiBIb3cgdGhlIHVzZXIgaXMgc3Vw cG9zZWQgdG8ga25vdyB0aGUKPj4+IGFtb3VudCBvZiBmdW5jdGlvbmFsaXR5IGhlIHdpbGwgbG9z ZSwgYW5kIGlmIHRoaXMgaXMgYWNjZXB0YWJsZSB0bwo+Pj4gaGltLgo+Pgo+PiBJIHN1cHBvc2Ug dGhlIGdlbmVyaWMgZHJpdmVyIHdvdWxkIHJldHVybiBzb21lIGVycm9yIGNvZGUgbGlrZQo+PiAt RU5PVFNVUCBmb3IgdGhlIGZ1bmN0aW9uYWxpdHkgaXQgY2Fubm90IHByb3ZpZGUuCj4gCj4gV2Vs bCwgSSBndWVzcyBpdCBkZXBlbmRzIG9mIHRoZSBhZGRlZCBmdW5jdGlvbmFsaXR5IGFkZCBob3cg ZmFyIHRoZSBJUAo+IHZlcnNpb24gaXMgZm9yd2FyZCBjb21wYXRpYmxlIHdpdGggdGhlIG9sZCBk cml2ZXIuIElmIHRoZSBuZXcgSVAgdmVyc2lvbgo+IGlzIGp1c3QgaW1wcm92aW5nIHRoZSBwZXJm b3JtYW5jZSBieSBhZGRpbmcgYSBETUEgbW9kZSBpbnN0ZWFkIG9mIHRoZQo+IFBJTywgdGhlbiB0 aGUgZHJpdmVyIEFQSSBjYW4gcmVtYWluIHRoZSBzYW1lLgo+IEJ1dCBpZiB5b3UgYWRkIGEgbmV3 IGZ1bmN0aW9uYWxpdHkgdGhhdCB3aWxsIHJlcXVpcmUgYW4gZXh0ZW5kZWQgQVBJLAo+IHRoZXJl IGlzIG5vIHdheSB5b3UgY2FuIHJlcG9ydCBzdWNoIGVycm9yLiBFeGNlcHQgaWYgdGhlIEFQSSBp dHNlbGYgaXMKPiBkb25lIHdpdGggYSBnb29kIGZvcndhcmQgY29tcGF0aWJpbGl0eSBzdXBwb3J0 Lgo+IAo+IEFuZCBpZiB0aGUgbmV3IGZ1bmN0aW9uYWxpdHkgaXMgbWFuZGF0b3J5IHRvIG1ha2Ug dGhlIG5ldyBzeXN0ZW0KPiBvcGVyYXRpb25hbCwgcmV0dXJuaW5nIGFuIGVycm9yIG1pZ2h0IGp1 c3QgbWFrZSB0aGUgc3lzdGVtIG5vdCB3b3JraW5nCj4gYXQgYWxsLgoKSWYgdGhlIGRyaXZlciBj YW5ub3Qgd29yayBhdCBhbGwsIHRoZW4geWVzLCBJIHdvdWxkIG5vdCBjbGFpbQpjb21wYXRpYmls aXR5LiBBdCBsZWFzdCBhIHN1YnNldCBvZiBmdW5jdGlvbmFsaXR5IHNob3VsZCB3b3JrLgoKPiAK Pj4gV2h5Cj4+IHdvdWxkIHNvbWVvbmUgd3JpdGUgYSBkcml2ZXIgc3VwcG9ydGluZyDigJxmc2ws bXBjODY0MS11YXJ04oCdIGlmIDEwMCUgb2YKPj4gaXRzIGhhcmR3YXJlIGZlYXR1cmVzIGFyZSBh bHNvIHN1cHBvcnRlZCBieSDigJxuczE2NTUwIiBkcml2ZXI/Cj4gCj4gVGhhdCdzIHN0aWxsIGRv YWJsZSwgaWYgeW91IHdhbnQgdG8gcmVkdWNlIHRoZSBzaXplIG9mIGEgYmlnIGdlbmVyaWMKPiBk cml2ZXIgaW50byBhIHNtYWxsZXIgc3BlY2lmaWMgZHJpdmVyLiBUaGUgcG9pbnQgaXMgdGhhdCB0 aGUgY29tcGF0aWJsZQoKVGhhdHMgcGxhdXNpYmxlLiBBbHRob3VnaCBJIGhhdmUgdG8gYWRtaXQg SSBoYXZlIG5ldmVyIHNlZW4gYSBuZXcgZHJpdmVyCmJlaW5nIHdyaXR0ZW4ganVzdCBiZWNhdXNl IGFub3RoZXIgZXhpc3RpbmcgZHJpdmVyIGlzIGJsb2F0ZWQuCgo+IHZhbHVlIGRvZXMgbm90IGhh dmUgYW55IGFzc3VtcHRpb24gYWJvdXQgdGhlIGRyaXZlciB0aGF0IHdpbGwgaGFuZGxlIGl0LgoK UmlnaHQuIEl0cyBhbGwgZHJpdmVuIGJ5IGhhcmR3YXJlIGNoYW5nZXMuCgo+IAo+IFRoZSBvdGhl ciBpc3N1ZSBpcyB0aGF0IHdlIGFyZSBzdXBwb3NlZCB0byBhbHdheXMgdXNlIHRoZSBsYXRlc3Qg U29DCj4gdmVyc2lvbiBldmVuIGlmIHRoZSBJUCBpcyAxMDAlIHRoZSBzYW1lLiBMaWtlCj4gCj4g b21hcDUtdGltZXIgewo+ICAgICBjb21wYXRpYmxlID0gIm9tYXA1LXRpbWVyIiwgIm9tYXA0LXRp bWVyIjsKPiB9Cj4gCj4gU28gaG93IGFyZSB5b3Ugc3VwcG9zZSB0byBkaWZmZXJlbnRpYXRlIHRo ZSBzYW1lIElQLCBhbmQgYSBjb21wYXRpYmxlIElQPz8/Cj4gCj4gVGhhdCdzIHdoYXQgSSBkb24n dCBsaWtlIGluIHRoYXQgY29tcGF0aWJsZSBzdHJpbmcgZGVmaW5pdGlvbi4gWW91IGRvCj4gbm90 IG5lY2Vzc2FyaWx5IGtub3cgdGhlIGFtb3VudCBvZiBjb21wYXRpYmlsaXR5IHlvdSBhcmUgdGFs a2luZyBhYm91dC4KClRoYXQncyBjb3JyZWN0LiBUaGUgc3RyaW5ncyB0aGVtc2VsdmVzIHRlbGwg dmVyeSBsaXR0bGUgaG93IG11Y2ggT01BUDUKdGltZXIgd29ya3Mgd2hlbiBjb21wYXRpYmxlID0g Im9tYXA0LXRpbWVyIiBpcyBwYXNzZWQuIFNvbWUga25vd24KbGltaXRhdGlvbnMgY2FuIHBlcmhh cHMgYmUgZG9jdW1lbnRlZCBpbiBiaW5kaW5nIGRlZmluaXRpb24uCgo+PiB0aGF0IGl0IGlzIHRv ZGF5LiBUaGluZyBpcywgeW91IGNhbiBuZXZlciBrbm93IGlmIHRoZSBJUCBuZWVkcyBhbnkKPj4g YWRkaXRpb25hbCBoYW5kbGluZyBldmVuIGFmdGVyIHJlYWRpbmcgdGhlIHNwZWMuIFdlIGtlZXAg ZGlzY292ZXJpbmcKPj4gbmV3IGZlYXR1cmVzL3F1aXJrcy4gU28sIHdoZW4gd3JpdGluZyA8bmV3 LXNvYz4uZHRzaSBpdHMgc2FmZXIgdG8KPj4gYWx3YXlzIHVzZQo+Pgo+PiBjb21wYXRpYmxlID0g InRpLDxuZXctc29jPi1ydGMiLCAidGksPGNvbXBhdGlibGUtc29jPi1ydGMiOwo+Pgo+PiBldmVu IHRob3VnaCBfdG9kYXlfIHlvdSBtYXkgbm90IGhhdmUgY29kZSB0aGF0IHNwZWNpZmljYWxseSBo YW5kbGVzCj4+ICJ0aSw8bmV3LXNvYz4tcnRjIi4KPiAKPiBXZWxsLCB3ZSBjYW4gZG8gdGhhdCwg YnV0IGhvbmVzdGx5LCBJIGRvIG5vdCBzZWUgdGhlIG5lZWQuIFlvdSBjYW4KPiBhbHdheXMgdXBk YXRlIHRoZSBkdHMgbGF0ZXIuIFdoeSB3b3VsZCB3ZSBhZGQgaHVuZHJlZHMgbW9yZSBjb21wYXRp YmxlCj4gc3RyaW5ncyBqdXN0IGluIGNhc2UgZmV3IGRldmljZXMgd2lsbCBuZWVkIHNwZWNpYWwg aGFuZGxpbmcuIFRoYXQncwo+IG92ZXJraWxsLgo+IElmIHdhcyBtYXliZSBlYXN5IGFuZCBoYXJt bGVzcyBpbiB0aGUgZ29vZCBvbGQgUFBDIHRpbWUgd2hlbiB0aGUgRFRTCj4gZmlsZXMgd2VyZSBy ZWxhdGl2ZWx5IHNtYWxsLCBidXQgdGhlIEFSTSBEVFMgZmlsZXMgYXJlIG11Y2ggYmlnZ2VyLgo+ IAo+IEluIHRoZSBuYW1lIG9mIHRoZSBLZWVwIEl0IFNpbXBsZSBQcmluY2lwbGUsIEkgd291bGQg anVzdCBhdm9pZCBhZGRpbmcKPiBzb21ldGhpbmcganVzdCBiZWNhdXNlIGl0IG1pZ2h0IGJlIHVz ZWZ1bCBpbiA1ICUgb2YgdGhlIGNhc2VzLgoKSXQgY2VydGFpbmx5IHNlZW1zIG92ZXJraWxsIHRv ZGF5LiBJZiBhbmQgd2hlbiB0aGUgLmR0c1tpXSBmaWxlcyBhcmUKbWFpbnRhaW5lZCBhcyBhIHNl cGFyYXRlIHByb2plY3QgaXQgd2lsbCBiZWNvbWUgcGFpbmZ1bCB0byBrZWVwIGtlcm5lbAphbmQg LmR0YiBpbiBzeW5jLiBUaGlzIHdpbGwgdGhlbiBiZWNvbWUgaW1wb3J0YW50LCBhcyBib290bG9h ZGVyCmluZGVwZW5kZW5jZSB0b2RheSBpcy4KCj4+Pj4gT3RoZXJ3aXNlIHRoZXkgZ2V0IHBsYWlu IFJUQyBmdW5jdGlvbmFsaXR5IC0gYnV0IGF0IGxlYXN0IHRoZXkKPj4+PiBnZXQgc29tZXRoaW5n IGluc3RlYWQgb2Ygbm8gUlRDLgo+Pj4KPj4+IEJlY2F1c2UgeW91IGFzc3VtZSB0aGF0IHRoaXMg ZmVhdHVyZSBpcyBub3QgaW1wb3J0YW50IGFuZCB0aHVzIHlvdQo+Pj4gY2FuIHVzZSB0aGUgcGxh aW4gUlRDLCBidXQgd2hhdCBpZiBzb21lb25lIGlzIGJ1eWluZyB0aGF0IEhXCj4+PiBiZWNhdXNl IG9mIHRoaXMgbmV3IGZlYXR1cmUuIFdpdGhvdXQgdGhhdCBmZWF0dXJlIGhpcyBzeXN0ZW0gd2ls bAo+Pj4ganVzdCBub3Qgd29yayBwcm9wZXJseS4KPj4KPj4gUmlnaHQsIGJ1dCB0aGF0cyBub3Qg YSBwcm9ibGVtIERUIGNhbiBzb2x2ZS4gSGUvc2hlIG5lZWRzIHRvIGhhc3NsZQo+PiBUSSBmb3Ig dXBkYXRlZCBkcml2ZXJzLiBCdXQgdGhlcmUgY291bGQgYmUgMTAgb3RoZXIgY3VzdG9tZXJzIHdo byBhcmUKPj4ganVzdCBva2F5IHdpdGggcGxhaW4gUlRDLiBTbyB0aWxsIHRoZSB0aW1lIGRyaXZl ciBpcyB1cGRhdGVkIHRvIHVzZQo+PiB0aSxhbTMzNTItcnRjIiwgYXJlIHlvdSBzYXlpbmcgbm8g b25lIHNob3VsZCBiZSBhYmxlIHRvIHVzZSB0aGUgUlRDCj4+IG9uIHRoZSBTb0MgYXQgYWxsIGV2 ZW4gdGhvdWdoIDkwJSBmZWF0dXJlcyBhcmUgYXZhaWxhYmxlPwo+IAo+IEFnYWluLCBpZiBpdCB3 aWxsIG5vdCBwcmV2ZW50IHRoZSBzeXN0ZW0gdG8gd29yayBwcm9wZXJseSwgdGhlbiBpdCBpcwo+ IGZpbmUuIEJ1dCBsZXQncyBhc3N1bWUgdGhhdCB3aXRob3V0IHRoZSB3YWtldXAgUlRDIGZ1bmN0 aW9uYWxpdHksIHlvdQo+IGp1c3QgY2Fubm90IHdha2V1cCBmcm9tIHN1c3BlbmQgYW4gYW0zMzUy IGJvYXJkLiBUaGVuIHlvdSBlbmQgdXAgd2l0aCBhCj4gbm9uIGZ1bmN0aW9uYWwgc3lzdGVtIGZv ciB0aGUgUE0gcG9pbnQgb2Ygdmlldy4KCkNvcnJlY3QsIGJ1dCB0aGlzIGlzIGJlY2F1c2Ugb2Yg bGFjayBvZiBrZXJuZWwgc3VwcG9ydCBmb3IgYSBmZWF0dXJlLgpOb3QgYmVjYXVzZSBvZiB0aGUg d2F5IGNvbXBhdGlibGUgaXMgd3JpdHRlbi4KCj4gU29tZW9uZSB3aG8gaXMgbm90IGF3YXJlIHRo YXQgdGhlIGNvbXBhdGlibGUgUlRDIGlzIG5vdCBzdXBwb3J0aW5nIHRoYXQKPiBmZWF0dXJlIG1p Z2h0IHNwZW5kIHNvbWUgdGltZSBmaWd1cmluZyBvdXQgd2h5IGhlIGNhbm5vdCB3YWtldXAgZnJv bQo+IHN1c3BlbmQgb24gYSBSVEMgYWxhcm0uCgpSaWdodC4gRFQvY29tcGF0aWJsZSBkb2VzIG5v dCBtYWtlIHRoaXMgcHJvYmxlbSBiZXR0ZXIgb3Igd29yc2UuIEV2ZW4KdXNpbmcgcGxhdGZvcm0g ZGV2aWNlIG1vZGVsLCB5b3Ugd291bGQgc3RpbGwgZW5kIHVwIHdpdGggYSBwYXJ0aWFsbHkKd29y a2luZyBzeXN0ZW0uCgo+Pj4gU2F5aW5nIHRoYXQgdGhpcyBpcyBjb21wYXRpYmxlIHdoZXJlYXMg eW91IGxvc3QgZnVuY3Rpb25hbGl0eSBpcwo+Pj4gbHlpbmcgdG8gdGhlIGN1c3RvbWVyIGZvciBt eSBwb2ludCBvZiB2aWV3Lgo+Pgo+PiBJZiAxMDAlIGZ1bmN0aW9uYWxpdHkgaXMgcmVxdWlyZWQg Zm9yIGNvbXBhdGliaWxpdHkgdGhlbiBJIGFtIGFmcmFpZAo+PiB0aGVyZSBpcyBub3RoaW5nIGxp a2UgImNvbXBhdGliaWxpdHkiLiBUaGVyZSBhcmUganVzdCBkaWZmZXJlbnQKPj4gaXNvbGF0ZWQg dmVyc2lvbnMuCj4gCj4gSSBndWVzcyB5b3UgYXJlIHJpZ2h0Lgo+IAo+IEJvdHRvbS1saW5lLCBJ J20gcmVhbGx5IGRpc2FwcG9pbnRlZCBidXQgdGhhdCBsYWNrIG9mIGFjY3VyYWN5IGluIHRoZQo+ IGNvbXBhdGlibGUgc3RyaW5nLCBidXQgSSBndWVzcywgaXQgd2FzIGRvbmUgZm9yIHdoYXQgeW91 IGd1eXMgYXJlIGRvaW5nLgo+IEFuZCBtYXliZSwgaXQgaXMgc29tZXRoaW5nIHRoYXQgc2hvdWxk IGp1c3QgYmUgd2VsbCBkb2N1bWVudGVkIGluIHRoZQo+IGJpbmRpbmdzIHRvIGF2b2lkIGNvbmZ1 c2luZyB0aGUgdXNlcnMuCgpPa2F5LiBDYW4geW91IHBsZWFzZSBzZWUgaWYgeW91IGNhbiB0YWtl IDIvMiBmb3IgdjMuMTI/IEl0IGNhbiBiZSB0YWtlbgppbmRlcGVuZGVudGx5IG9mIDEvMiAod2hp Y2ggSSBndWVzcyBha3BtIHdpbGwgcGljayB1cCkuCgpUaGFua3MsClNla2hhcgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpEYXZpbmNpLWxpbnV4LW9wZW4t c291cmNlIG1haWxpbmcgbGlzdApEYXZpbmNpLWxpbnV4LW9wZW4tc291cmNlQGxpbnV4LmRhdmlu Y2lkc3AuY29tCmh0dHA6Ly9saW51eC5kYXZpbmNpZHNwLmNvbS9tYWlsbWFuL2xpc3RpbmZvL2Rh dmluY2ktbGludXgtb3Blbi1zb3VyY2UK From mboxrd@z Thu Jan 1 00:00:00 1970 From: nsekhar@ti.com (Sekhar Nori) Date: Fri, 23 Aug 2013 21:47:15 +0530 Subject: [PATCH v3 1/2] rtc: omap: update of_device_id to reflect latest ip revisions In-Reply-To: <52177B6C.2080406@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> <52172264.3070000@ti.com> <52177B6C.2080406@baylibre.com> Message-ID: <52178B0B.7090303@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 8/23/2013 8:40 PM, Benoit Cousson wrote: >>> 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. > > Well, I guess it depends of the added functionality add how far the IP > version is forward compatible with the old driver. If the new IP version > is just improving the performance by adding a DMA mode instead of the > PIO, then the driver API can remain the same. > But if you add a new functionality that will require an extended API, > there is no way you can report such error. Except if the API itself is > done with a good forward compatibility support. > > And if the new functionality is mandatory to make the new system > operational, returning an error might just make the system not working > at all. If the driver cannot work at all, then yes, I would not claim compatibility. At least a subset of functionality should work. > >> Why >> would someone write a driver supporting ?fsl,mpc8641-uart? if 100% of >> its hardware features are also supported by ?ns16550" driver? > > That's still doable, if you want to reduce the size of a big generic > driver into a smaller specific driver. The point is that the compatible Thats plausible. Although I have to admit I have never seen a new driver being written just because another existing driver is bloated. > value does not have any assumption about the driver that will handle it. Right. Its all driven by hardware changes. > > The other issue is that we are supposed to always use the latest SoC > version even if the IP is 100% the same. Like > > omap5-timer { > compatible = "omap5-timer", "omap4-timer"; > } > > So how are you suppose to differentiate the same IP, and a compatible IP??? > > That's what I don't like in that compatible string definition. You do > not necessarily know the amount of compatibility you are talking about. That's correct. The strings themselves tell very little how much OMAP5 timer works when compatible = "omap4-timer" is passed. Some known limitations can perhaps be documented in binding definition. >> 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". > > Well, we can do that, but honestly, I do not see the need. You can > always update the dts later. Why would we add hundreds more compatible > strings just in case few devices will need special handling. That's > overkill. > If was maybe easy and harmless in the good old PPC time when the DTS > files were relatively small, but the ARM DTS files are much bigger. > > In the name of the Keep It Simple Principle, I would just avoid adding > something just because it might be useful in 5 % of the cases. It certainly seems overkill today. If and when the .dts[i] files are maintained as a separate project it will become painful to keep kernel and .dtb in sync. This will then become important, as bootloader independence today is. >>>> 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? > > Again, if it will not prevent the system to work properly, then it is > fine. But let's assume that without the wakeup RTC functionality, you > just cannot wakeup from suspend an am3352 board. Then you end up with a > non functional system for the PM point of view. Correct, but this is because of lack of kernel support for a feature. Not because of the way compatible is written. > Someone who is not aware that the compatible RTC is not supporting that > feature might spend some time figuring out why he cannot wakeup from > suspend on a RTC alarm. Right. DT/compatible does not make this problem better or worse. Even using platform device model, you would still end up with a partially working system. >>> 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. > > I guess you are right. > > Bottom-line, I'm really disappointed but that lack of accuracy in the > compatible string, but I guess, it was done for what you guys are doing. > And maybe, it is something that should just be well documented in the > bindings to avoid confusing the users. Okay. Can you please see if you can take 2/2 for v3.12? It can be taken independently of 1/2 (which I guess akpm will pick up). 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 S1755515Ab3HWQSG (ORCPT ); Fri, 23 Aug 2013 12:18:06 -0400 Received: from devils.ext.ti.com ([198.47.26.153]:44882 "EHLO devils.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754145Ab3HWQSE (ORCPT ); Fri, 23 Aug 2013 12:18:04 -0400 Message-ID: <52178B0B.7090303@ti.com> Date: Fri, 23 Aug 2013 21:47:15 +0530 From: Sekhar Nori User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 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> <52172264.3070000@ti.com> <52177B6C.2080406@baylibre.com> In-Reply-To: <52177B6C.2080406@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 On 8/23/2013 8:40 PM, Benoit Cousson wrote: >>> 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. > > Well, I guess it depends of the added functionality add how far the IP > version is forward compatible with the old driver. If the new IP version > is just improving the performance by adding a DMA mode instead of the > PIO, then the driver API can remain the same. > But if you add a new functionality that will require an extended API, > there is no way you can report such error. Except if the API itself is > done with a good forward compatibility support. > > And if the new functionality is mandatory to make the new system > operational, returning an error might just make the system not working > at all. If the driver cannot work at all, then yes, I would not claim compatibility. At least a subset of functionality should work. > >> Why >> would someone write a driver supporting “fsl,mpc8641-uart” if 100% of >> its hardware features are also supported by “ns16550" driver? > > That's still doable, if you want to reduce the size of a big generic > driver into a smaller specific driver. The point is that the compatible Thats plausible. Although I have to admit I have never seen a new driver being written just because another existing driver is bloated. > value does not have any assumption about the driver that will handle it. Right. Its all driven by hardware changes. > > The other issue is that we are supposed to always use the latest SoC > version even if the IP is 100% the same. Like > > omap5-timer { > compatible = "omap5-timer", "omap4-timer"; > } > > So how are you suppose to differentiate the same IP, and a compatible IP??? > > That's what I don't like in that compatible string definition. You do > not necessarily know the amount of compatibility you are talking about. That's correct. The strings themselves tell very little how much OMAP5 timer works when compatible = "omap4-timer" is passed. Some known limitations can perhaps be documented in binding definition. >> 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". > > Well, we can do that, but honestly, I do not see the need. You can > always update the dts later. Why would we add hundreds more compatible > strings just in case few devices will need special handling. That's > overkill. > If was maybe easy and harmless in the good old PPC time when the DTS > files were relatively small, but the ARM DTS files are much bigger. > > In the name of the Keep It Simple Principle, I would just avoid adding > something just because it might be useful in 5 % of the cases. It certainly seems overkill today. If and when the .dts[i] files are maintained as a separate project it will become painful to keep kernel and .dtb in sync. This will then become important, as bootloader independence today is. >>>> 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? > > Again, if it will not prevent the system to work properly, then it is > fine. But let's assume that without the wakeup RTC functionality, you > just cannot wakeup from suspend an am3352 board. Then you end up with a > non functional system for the PM point of view. Correct, but this is because of lack of kernel support for a feature. Not because of the way compatible is written. > Someone who is not aware that the compatible RTC is not supporting that > feature might spend some time figuring out why he cannot wakeup from > suspend on a RTC alarm. Right. DT/compatible does not make this problem better or worse. Even using platform device model, you would still end up with a partially working system. >>> 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. > > I guess you are right. > > Bottom-line, I'm really disappointed but that lack of accuracy in the > compatible string, but I guess, it was done for what you guys are doing. > And maybe, it is something that should just be well documented in the > bindings to avoid confusing the users. Okay. Can you please see if you can take 2/2 for v3.12? It can be taken independently of 1/2 (which I guess akpm will pick up). Thanks, Sekhar