[PATCH 3/5] ARM: vexpress: Add DT support in v2m

[Rob Herring]

On 11/16/2011 10:37 AM, Pawel Moll wrote:
> On Wed, 2011-11-16 at 16:26 +0000, Rob Herring wrote:
>> On 11/16/2011 09:44 AM, Dave Martin wrote:
>>> On Fri, Nov 11, 2011 at 06:27:04PM +0000, Pawel Moll wrote:
>>>> This patch provides hooks for DT-based tile machine implementations
>>>> and adds Device Tree description for the motherboard.
>>>>
>>>> Signed-off-by: Pawel Moll <pawel.moll at arm.com>
>>>> ---
>>>>  Documentation/devicetree/bindings/arm/vexpress    |   92 ++++++++++
>>>>  arch/arm/boot/dts/vexpress-v2m-legacy.dtsi        |  190 +++++++++++++++++++++
>>>>  arch/arm/mach-vexpress/Kconfig                    |    4 +
>>>>  arch/arm/mach-vexpress/core.h                     |    9 +
>>>>  arch/arm/mach-vexpress/include/mach/motherboard.h |    8 +
>>>>  arch/arm/mach-vexpress/v2m.c                      |  140 +++++++++++++++-
>>>>  6 files changed, 442 insertions(+), 1 deletions(-)
>>>>  create mode 100644 Documentation/devicetree/bindings/arm/vexpress
>>>>  create mode 100644 arch/arm/boot/dts/vexpress-v2m-legacy.dtsi
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/vexpress b/Documentation/devicetree/bindings/arm/vexpress
>>>
>>> [...]
>>>
>>>> +Required properties in the root node:
>>>> +- compatible value:
>>>> +  - for motherboard in "legacy" mode:
>>>> +	compatible = "arm,vexpress-<model>", "arm,vexpress-legacy", "arm-vexpress";
>>>> +  - for motherboard in "RS1" mode:
>>>> +	compatible = "arm,vexpress-<model>", "arm-vexpress";
>>>
>>> So, we have:
>>>
>>> arm,vexpress-* implies arm,vexpress
>>> arm,vexpress-* may imply arm,vexpress-legacy
>>> arm,vexpress-legacy implies arm,vexpress
>>>
>>> This means we have no bounded test for RS1-only features:
>>> the needed test is
>>> "compatible(node, "arm,vexpress") && !compatible(node, "arm,vexpress-legacy")
>>>
>>> Unfortunately, if there is someday an "rs2" memory map, that will also match
>>> the above.  Using "inverse compatibility" in this way feels dangerous,
>>> because the condition will pass for an arbitrary set of future conditions
>>> that we haven't imagined yet.
>>>
>>> This means it's, impossible even in principle to panic the kernel cleanly if
>>> presented with a device tree for a platform variant which is too new for the
>>> kernel to support.
>>>
>>>
>>> Can we instead have a specific "arm,vexpress-rs1"?
>>>
>>> 	compatible = "arm,vexpress-<model>", "arm-vexpress-rs1", "arm-vexpress";
>>>
>>> Then, we can be exact about compatibility: universal features are compatible
>>> with "arm,vexpress"; memory-map-specific features are compatible with either
>>> "arm,vexpress-legacy" or "arm,vexpress-rs1".
>>
>> Really, legacy is a bad name. 
> 
> http://en.wikipedia.org/wiki/De_gustibus_non_est_disputandum ;-)
> 
> This is de-facto name we use in ARM. See:
> http://infocenter.arm.com/help/topic/com.arm.doc.dui0447e/ch04s02s01.html
> 

It has nothing to do with taste and obviously documentation changes over
time. I'm going to start naming everything with legacy because someday
it all will be...

It's about how you create compatible strings. They should not be
generic, but specific to particular hardware version. If you happen to
be compatible with older h/w then you can claim compatibility with that
older h/w.

>> If you defined the property when the
>> original vexpress was designed, it never would have had legacy in the
>> name. Generally speaking you never change bindings on old platforms.
>>
>> So I would have "arm,vexpress" mean legacy and "arm,vexpress-rs1" be the
>> new memory map.
> 
> I'd rather second Dave's idea of having
> 
>>> 	compatible = "arm,vexpress-<model>", "arm-vexpress-rs1", "arm-vexpress";
> 
> and
> 
>>> +	compatible = "arm,vexpress-<model>", "arm,vexpress-legacy", "arm-vexpress";

If arm,vexpress-ca9 is the only legacy platform, then just drop
arm,vexpress-legacy altogether.

Rob