From: swarren@wwwdotorg•org (Stephen Warren)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v2] ARM: DT: binding fixup to align with vendor-prefixes.txt
Date: Fri, 09 Aug 2013 13:14:47 -0600 [thread overview]
Message-ID: <52053FA7.5010809@wwwdotorg.org> (raw)
In-Reply-To: <CAA-5wcAEUkX=n-WAi28JFUxQ44cuyUKW3b1PGVpukyqKRF9bDg@mail.gmail.com>
On 08/09/2013 12:49 PM, Christian Daudt wrote:
> [resend in plain-text]
>
>
> On 2013-08-09 9:11 AM, "Stephen Warren" <swarren@wwwdotorg•org> wrote:
>>
>> On 08/06/2013 03:40 PM, Christian Daudt wrote:
>>> On 13-08-05 09:21 PM, Stephen Warren wrote:
>>>>>>> Required root node property:
>>>>>>> -compatible = "bcm,bcm11351";
>>>>>>> +compatible = "brcm,bcm11351";
>>>>>> In a patch of mine that deprecated a property, Mark wondered if it
>>>>>> would
>>>>>> make sense to mention the old deprecated DT content simply to document
>>>>>> that it existed, so that old DTs would still make sense when checking
>>>>>> the documentation. I wonder if the same argument applies to this patch?
>>>>> I would think the opposite. Deprecated items should be dropped from
>>>>> documentation. They are in the code (for a holdover period) but clearly
>>>>> marked as deprecated. No one should be extending the life of these, and
>>>>> adding documentation on it is a step in the wrong direction of making it
>>>>> easier for it to linger beyond what it should.
>>>> The deprecated stuff will have to be fully documented once the DT schema
>>>> validation is in place...
>>>>
>>> This deprecated code should be short lived, given that in actual fact it
>>> is actually quite unnecessary since no boards exist that rely on it.
>>
>> Is this patch for v3.11-rc* or v3.12?
>>
> I'm guessing it's too late for 3.11 at this point.
>
>> If it's for v3.12, then I see that v3.11 will be released with a variety
>> of users of the old compatible values, hence the old compatible value is
>> an ABI, and hence we should continue to support and document it (as
>> deprecated).
>>
> I think whether bindings automatically become ABI at kernel release is
> still an open topic. And as I mentioned in this case we are the only
> ones affected and we don't have a problem with the change.
> But if that's the case then there's no point to this patch. I'll just
> add bcm to vendor-prefixes and be done with it.
> I'm okay either way. Just need to know what direction to take asap so
> I can stop telling devs to keep changing back and forth...
I think it's fine to fix the issue; we should just do so in the trivial
way that maintains backwards-compatibility, and allows people who
compare the binding document to old DTs to understand how the correlate
to each-other.
next prev parent reply other threads:[~2013-08-09 19:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-02 22:27 [PATCH v2] ARM: DT: binding fixup to align with vendor-prefixes.txt Christian Daudt
2013-08-05 16:01 ` Stephen Warren
2013-08-06 0:16 ` Christian Daudt
2013-08-06 4:21 ` Stephen Warren
2013-08-06 21:40 ` Christian Daudt
2013-08-09 16:11 ` Stephen Warren
[not found] ` <CAA-5wcDOv+ru+4QiDbEZr-SP90xHSh1bq+ifdVxOsOnid1komg@mail.gmail.com>
2013-08-09 18:49 ` Christian Daudt
2013-08-09 19:14 ` Stephen Warren [this message]
2013-08-10 19:56 ` Christian Daudt
2013-08-08 22:56 ` Christian Daudt
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=52053FA7.5010809@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