From: swarren@wwwdotorg•org (Stephen Warren)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH V2 5/5] ARM: remove #gpio-ranges-cells property
Date: Tue, 16 Jul 2013 20:58:19 -0600 [thread overview]
Message-ID: <51E6084B.30500@wwwdotorg.org> (raw)
In-Reply-To: <CAL_JsqJ7CYUieGbvAZtQDEYsUKdM3yYBHSu871jUqOLeASc08g@mail.gmail.com>
On 07/16/2013 07:50 PM, Rob Herring wrote:
> On Tue, Jul 16, 2013 at 6:30 PM, Stephen Warren <swarren@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@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.
next prev parent reply other threads:[~2013-07-17 2:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-15 18:40 [PATCH V2 1/5] gpio: clean up gpio-ranges documentation Stephen Warren
2013-07-15 18:40 ` [PATCH V2 2/5] of: move documentation of of_parse_phandle_with_args Stephen Warren
2013-07-15 18:40 ` [PATCH V2 3/5] of: introduce of_parse_phandle_with_fixed_args Stephen Warren
2013-07-15 18:59 ` Sergei Shtylyov
2013-07-15 23:06 ` Stephen Warren
2013-07-15 18:40 ` [PATCH V2 4/5] gpio: implement gpio-ranges binding document fix Stephen Warren
2013-07-15 18:40 ` [PATCH V2 5/5] ARM: remove #gpio-ranges-cells property Stephen Warren
2013-07-15 19:34 ` Rob Herring
2013-07-15 23:02 ` Stephen Warren
2013-07-16 23:30 ` Stephen Warren
2013-07-17 1:50 ` Rob Herring
2013-07-17 2:58 ` Stephen Warren [this message]
2013-07-18 1:35 ` Laurent Pinchart
2013-07-22 22:31 ` [PATCH V2 1/5] gpio: clean up gpio-ranges documentation Linus Walleij
2013-07-23 16:14 ` Stephen Warren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51E6084B.30500@wwwdotorg.org \
--to=swarren@wwwdotorg$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox