Thread (4 messages) 4 messages, 4 authors, 2016-07-04

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

From: Arnd Bergmann <arnd@arndb.de>
Date: 2016-07-04 08:55:19
Also in: linux-arm-kernel, linux-devicetree

On Monday, July 4, 2016 10:41:20 AM CEST Arend Van Spriel wrote:
On 2-7-2016 23:30, Arnd Bergmann wrote:
quoted
On Saturday, July 2, 2016 8:20:35 PM CEST Arend Van Spriel wrote:
quoted
quoted
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: <string>
Description:
The model property value is a <string> 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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help