On 08/16/2013 04:17 AM, Benoit Cousson wrote:
> Hi Afzal,
>
> On 12/08/2013 08:48, Afzal Mohammed wrote:
>> Hi Mark,
>>
>> On Saturday 10 August 2013 07:53 PM, Mark Rutland wrote:
>>
>>>>>> + mac: ethernet@4a100000 {
>>>>>> + compatible = "ti,am4372-cpsw","ti,cpsw";
>>
>>> One point worth mentioning is that the "ti,am4372-cpsw" string isn't
>>> documented. Will the "ti,am4372-cpsw" binding definitely be a superset
>>> of the "ti,cpsw" binding, and if you were to take the DT as of this
>>> patch, and attempt to use it with a future kernel, can you guarantee
>>> it'll work?
>>
>> "ti,am4372-cpsw" was not documented as OMAP DT maintainer didn't prefer
>> documenting only for a new compatible.
>
> My point was more that creating a new compatible for the exact same
> version of the IP is pointeless and could lead to tons of compatible
> strings that would never be used since this is always the exact same IP.
Well, there are two aspects: Version of the IP block, and the
integration into the SoC. We need an entry in compatible for any/all of
these. If the IP block doesn't have some standalone versioning scheme
because the design flow isn't IP-block-centric, the SoC name makes a
reasonable substitute.
...
> My second point is, even if we want to differentiate the IPs in various
> SoCs, using the name of the SoC in the IP compatible string is not a
> very good practice anyway.
There may be integration-specific issues, so even if SoC A and B use the
exact same IP block version, there should still be compatible values for
the SoC as well as the IP block version, so you can quirk on those later.
... although I suppose it might not be too bad if the IP block
compatible value only contained the IP block version, and if any
integration-specific quirks were needed, they could be triggered off
entries in the top-level node's compatible value? That only works for
on-Soc modules, and not complex MFD-like modules, unless you have an
easy way to find the DT node for the top-level of the MFD...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
