From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mout.kundenserver.de ([217.72.192.75]:57827 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750895AbcGDIxU convert rfc822-to-8bit (ORCPT ); Mon, 4 Jul 2016 04:53:20 -0400 From: Arnd Bergmann To: Arend Van Spriel Cc: Jonas Gorski , Hans de Goede , Kalle Valo , Priit Laes , "John W . Linville" , Arend van Spriel , Maxime Ripard , Chen-Yu Tsai , "linux-wireless@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , devicetree , linux-sunxi@googlegroups.com Subject: Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property Date: Mon, 04 Jul 2016 10:55:19 +0200 Message-ID: <5756670.9hMGo8oEyl@wuerfel> (sfid-20160704_105324_907498_87F30EC3) In-Reply-To: References: <1467209074-15634-1-git-send-email-hdegoede@redhat.com> <7975990.MvNRQ06u39@wuerfel> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Sender: linux-wireless-owner@vger.kernel.org List-ID: On Monday, July 4, 2016 10:41:20 AM CEST Arend Van Spriel wrote: > On 2-7-2016 23:30, Arnd Bergmann wrote: > > On Saturday, July 2, 2016 8:20:35 PM CEST Arend Van Spriel wrote: > >>> If you want a separate property, then I repeat my very first > >>> suggestion, the well defined model property. > >>> e.g. > >>> > >>> brcmf@0 { > >>> model = "ampak,ap6210"; > >>> compatible = "brcm,bcm4329-fmac"; > >>> ... > >>> }; > >>> > >>> All device nodes may have a model property, not just the top "machine" one. > >> > >> I heard you the first time I just was not sure what the implications > >> would be to use it. Hence I suggested a vendor specific property. > >> However, looking up and reading the definition in ePAPRv1.1 I suppose it > >> is fine to use the model property: > >> > >> Property: model > >> Value type: > >> Description: > >> The model property value is a that specifies the manufacturer’s > >> model number of the device. > >> > >> 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. > > > > The model property is very similar to compatible, except that there is > > only one entry rather than a list of entries from most specific to > > most generic. > > They seem very similar, but I think there is a conceptual difference. > The compatible property is mainly used to select the appropriate driver > and as such the property is typically ignored by device drivers. > Probably there are exceptions to be found. > > > I think by writing the above example as > > > > compatible = "ampak,ap6210", "brcm,bcm4329-fmac"; > > > > we can provide the same functionality in a slightly simpler way, the driver > > then just goes on to look for the nvram file for each entry in sequence until > > it finds one. > > Not sure why this would be simpler. Why would traversing the compatible > string be simpler than handling the model property if present and > otherwise fallback to the default nvram naming. Because you have to walk the list anyway to find the other firmware files: when you have a specialization of a device that requires listing both values as compatible, the driver has no idea which of the entries to use, unless you add a lookup table that adds more complexity. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Mon, 04 Jul 2016 10:55:19 +0200 Subject: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm, nvram_file_name dt property In-Reply-To: References: <1467209074-15634-1-git-send-email-hdegoede@redhat.com> <7975990.MvNRQ06u39@wuerfel> Message-ID: <5756670.9hMGo8oEyl@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Monday, July 4, 2016 10:41:20 AM CEST Arend Van Spriel wrote: > On 2-7-2016 23:30, Arnd Bergmann wrote: > > On Saturday, July 2, 2016 8:20:35 PM CEST Arend Van Spriel wrote: > >>> If you want a separate property, then I repeat my very first > >>> suggestion, the well defined model property. > >>> e.g. > >>> > >>> brcmf at 0 { > >>> model = "ampak,ap6210"; > >>> compatible = "brcm,bcm4329-fmac"; > >>> ... > >>> }; > >>> > >>> All device nodes may have a model property, not just the top "machine" one. > >> > >> I heard you the first time I just was not sure what the implications > >> would be to use it. Hence I suggested a vendor specific property. > >> However, looking up and reading the definition in ePAPRv1.1 I suppose it > >> is fine to use the model property: > >> > >> Property: model > >> Value type: > >> Description: > >> The model property value is a that specifies the manufacturer?s > >> model number of the device. > >> > >> 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. > > > > The model property is very similar to compatible, except that there is > > only one entry rather than a list of entries from most specific to > > most generic. > > They seem very similar, but I think there is a conceptual difference. > The compatible property is mainly used to select the appropriate driver > and as such the property is typically ignored by device drivers. > Probably there are exceptions to be found. > > > I think by writing the above example as > > > > compatible = "ampak,ap6210", "brcm,bcm4329-fmac"; > > > > we can provide the same functionality in a slightly simpler way, the driver > > then just goes on to look for the nvram file for each entry in sequence until > > it finds one. > > Not sure why this would be simpler. Why would traversing the compatible > string be simpler than handling the model property if present and > otherwise fallback to the default nvram naming. Because you have to walk the list anyway to find the other firmware files: when you have a specialization of a device that requires listing both values as compatible, the driver has no idea which of the entries to use, unless you add a lookup table that adds more complexity. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm, nvram_file_name dt property Date: Mon, 04 Jul 2016 10:55:19 +0200 Message-ID: <5756670.9hMGo8oEyl@wuerfel> References: <1467209074-15634-1-git-send-email-hdegoede@redhat.com> <7975990.MvNRQ06u39@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Arend Van Spriel Cc: devicetree , Priit Laes , linux-sunxi@googlegroups.com, "linux-wireless@vger.kernel.org" , "John W . Linville" , Hans de Goede , Chen-Yu Tsai , "linux-arm-kernel@lists.infradead.org" , Jonas Gorski , Arend van Spriel , Maxime Ripard , Kalle Valo List-Id: devicetree@vger.kernel.org T24gTW9uZGF5LCBKdWx5IDQsIDIwMTYgMTA6NDE6MjAgQU0gQ0VTVCBBcmVuZCBWYW4gU3ByaWVs IHdyb3RlOgo+IE9uIDItNy0yMDE2IDIzOjMwLCBBcm5kIEJlcmdtYW5uIHdyb3RlOgo+ID4gT24g U2F0dXJkYXksIEp1bHkgMiwgMjAxNiA4OjIwOjM1IFBNIENFU1QgQXJlbmQgVmFuIFNwcmllbCB3 cm90ZToKPiA+Pj4gSWYgeW91IHdhbnQgYSBzZXBhcmF0ZSBwcm9wZXJ0eSwgdGhlbiBJIHJlcGVh dCBteSB2ZXJ5IGZpcnN0Cj4gPj4+IHN1Z2dlc3Rpb24sIHRoZSB3ZWxsIGRlZmluZWQgbW9kZWwg cHJvcGVydHkuCj4gPj4+IGUuZy4KPiA+Pj4KPiA+Pj4gYnJjbWZAMCB7Cj4gPj4+ICAgICAgICAg bW9kZWwgPSAiYW1wYWssYXA2MjEwIjsKPiA+Pj4gICAgICAgICBjb21wYXRpYmxlID0gImJyY20s YmNtNDMyOS1mbWFjIjsKPiA+Pj4gICAgICAgICAuLi4KPiA+Pj4gfTsKPiA+Pj4KPiA+Pj4gQWxs IGRldmljZSBub2RlcyBtYXkgaGF2ZSBhIG1vZGVsIHByb3BlcnR5LCBub3QganVzdCB0aGUgdG9w ICJtYWNoaW5lIiBvbmUuCj4gPj4KPiA+PiBJIGhlYXJkIHlvdSB0aGUgZmlyc3QgdGltZSAgSSBq dXN0IHdhcyBub3Qgc3VyZSB3aGF0IHRoZSBpbXBsaWNhdGlvbnMKPiA+PiB3b3VsZCBiZSB0byB1 c2UgaXQuIEhlbmNlIEkgc3VnZ2VzdGVkIGEgdmVuZG9yIHNwZWNpZmljIHByb3BlcnR5Lgo+ID4+ IEhvd2V2ZXIsIGxvb2tpbmcgdXAgYW5kIHJlYWRpbmcgdGhlIGRlZmluaXRpb24gaW4gZVBBUFJ2 MS4xIEkgc3VwcG9zZSBpdAo+ID4+IGlzIGZpbmUgdG8gdXNlIHRoZSBtb2RlbCBwcm9wZXJ0eToK PiA+Pgo+ID4+IFByb3BlcnR5OiBtb2RlbAo+ID4+IFZhbHVlIHR5cGU6IDxzdHJpbmc+Cj4gPj4g RGVzY3JpcHRpb246Cj4gPj4gVGhlIG1vZGVsIHByb3BlcnR5IHZhbHVlIGlzIGEgPHN0cmluZz4g dGhhdCBzcGVjaWZpZXMgdGhlIG1hbnVmYWN0dXJlcuKAmXMKPiA+PiBtb2RlbCBudW1iZXIgb2Yg dGhlIGRldmljZS4KPiA+Pgo+ID4+IFRoZSByZWNvbW1lbmRlZCBmb3JtYXQgaXM6IOKAnG1hbnVm YWN0dXJlcixtb2RlbOKAnSwgd2hlcmUgbWFudWZhY3R1cmVyIGlzIGEKPiA+PiBzdHJpbmcgZGVz Y3JpYmluZyB0aGUgbmFtZSBvZiB0aGUgbWFudWZhY3R1cmVyIChzdWNoIGFzIGEgc3RvY2sgdGlj a2VyCj4gPj4gc3ltYm9sKSwgYW5kIG1vZGVsIHNwZWNpZmllcyB0aGUgbW9kZWwgbnVtYmVyLgo+ ID4gCj4gPiBUaGUgbW9kZWwgcHJvcGVydHkgaXMgdmVyeSBzaW1pbGFyIHRvIGNvbXBhdGlibGUs IGV4Y2VwdCB0aGF0IHRoZXJlIGlzCj4gPiBvbmx5IG9uZSBlbnRyeSByYXRoZXIgdGhhbiBhIGxp c3Qgb2YgZW50cmllcyBmcm9tIG1vc3Qgc3BlY2lmaWMgdG8KPiA+IG1vc3QgZ2VuZXJpYy4KPiAK PiBUaGV5IHNlZW0gdmVyeSBzaW1pbGFyLCBidXQgSSB0aGluayB0aGVyZSBpcyBhIGNvbmNlcHR1 YWwgZGlmZmVyZW5jZS4KPiBUaGUgY29tcGF0aWJsZSBwcm9wZXJ0eSBpcyBtYWlubHkgdXNlZCB0 byBzZWxlY3QgdGhlIGFwcHJvcHJpYXRlIGRyaXZlcgo+IGFuZCBhcyBzdWNoIHRoZSBwcm9wZXJ0 eSBpcyB0eXBpY2FsbHkgaWdub3JlZCBieSBkZXZpY2UgZHJpdmVycy4KPiBQcm9iYWJseSB0aGVy ZSBhcmUgZXhjZXB0aW9ucyB0byBiZSBmb3VuZC4KPiAKPiA+IEkgdGhpbmsgYnkgd3JpdGluZyB0 aGUgYWJvdmUgZXhhbXBsZSBhcwo+ID4gCj4gPiAgICAgICBjb21wYXRpYmxlID0gImFtcGFrLGFw NjIxMCIsICJicmNtLGJjbTQzMjktZm1hYyI7Cj4gPiAKPiA+IHdlIGNhbiBwcm92aWRlIHRoZSBz YW1lIGZ1bmN0aW9uYWxpdHkgaW4gYSBzbGlnaHRseSBzaW1wbGVyIHdheSwgdGhlIGRyaXZlcgo+ ID4gdGhlbiBqdXN0IGdvZXMgb24gdG8gbG9vayBmb3IgdGhlIG52cmFtIGZpbGUgZm9yIGVhY2gg ZW50cnkgaW4gc2VxdWVuY2UgdW50aWwKPiA+IGl0IGZpbmRzIG9uZS4KPiAKPiBOb3Qgc3VyZSB3 aHkgdGhpcyB3b3VsZCBiZSBzaW1wbGVyLiBXaHkgd291bGQgdHJhdmVyc2luZyB0aGUgY29tcGF0 aWJsZQo+IHN0cmluZyBiZSBzaW1wbGVyIHRoYW4gaGFuZGxpbmcgdGhlIG1vZGVsIHByb3BlcnR5 IGlmIHByZXNlbnQgYW5kCj4gb3RoZXJ3aXNlIGZhbGxiYWNrIHRvIHRoZSBkZWZhdWx0IG52cmFt IG5hbWluZy4KCkJlY2F1c2UgeW91IGhhdmUgdG8gd2FsayB0aGUgbGlzdCBhbnl3YXkgdG8gZmlu ZCB0aGUgb3RoZXIgZmlybXdhcmUgZmlsZXM6CndoZW4geW91IGhhdmUgYSBzcGVjaWFsaXphdGlv biBvZiBhIGRldmljZSB0aGF0IHJlcXVpcmVzIGxpc3RpbmcgYm90aCB2YWx1ZXMKYXMgY29tcGF0 aWJsZSwgdGhlIGRyaXZlciBoYXMgbm8gaWRlYSB3aGljaCBvZiB0aGUgZW50cmllcyB0byB1c2Us IHVubGVzcwp5b3UgYWRkIGEgbG9va3VwIHRhYmxlIHRoYXQgYWRkcyBtb3JlIGNvbXBsZXhpdHku CgoJQXJuZAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K bGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZy YWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGlu dXgtYXJtLWtlcm5lbAo=