[PATCH V2 5/5] ARM: remove #gpio-ranges-cells property

[Stephen Warren]

On 07/16/2013 07:50 PM, Rob Herring wrote:
> On Tue, Jul 16, 2013 at 6:30 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 07/15/2013 05:02 PM, Stephen Warren wrote:
>>> On 07/15/2013 01:34 PM, Rob Herring wrote:
>>>> On 07/15/2013 01:40 PM, Stephen Warren wrote:
>>>>> From: Stephen Warren <swarren at nvidia.com>
>>>>>
>>>>> This property is no longer required by the GPIO binding. Remove it.
>>>>
>>>> Won't this break compatibility with older kernel? It is one thing to
>>>> deprecate, but removal is another. If the relevant maintainers don't
>>>> care, then I guess it is fine.
>>>
>>> Yes.
>>>
>>> I had originally hoped this could sneak in late for 3.11, but I suppose
>>> it's too late now. vf610.dtsi is a new file in 3.11 so has no legacy to
>>> protect.
>>>
>>> Admittedly, the #gpio-cells property was added into the SPEAr files in 3.10.
>>
>> One more thought here:
>>
>> I know DT bindings are supposed to evolve so that a new kernel will
>> support arbitrary old DTs. I'll call that backwards-compatibility for
>> the DT parsing code.
> 
> That is the more common case.
> 
>> However, this situation is the reverse; this patch would prevent a new
>> DT running on an older kernel. I'll call that forwards-compatibility.
>> I'm not sure if the intent is to support this or not? It's certainly the
>> first I explicitly thought about compatibility in this direction...
> 
> So you would be okay if your computer stopped booting a kernel after a
> BIOS update? It's the same deal. It's both forwards and backwards
> compatibility that is needed.

I would strongly hope the BIOS/bootloader/... would have nothing to do
with the DT content. There's a reason that Grant asserted early on that
DTBs shouldn't be part of the BIOS/bootloader, but rather stored
separately, so the DTB could be updated without updating firmware, just
like the kernel. And I see no real problem with a new DTB requiring a
new kernel or even vice-versa to be honest.