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 10:11:48 -0600 [thread overview]
Message-ID: <520514C4.5020007@wwwdotorg.org> (raw)
In-Reply-To: <52016D44.7060808@broadcom.com>
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?
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).
>From v3.11-rc4:
> arch/arm/boot/dts/bcm11351-brt.dts:20: compatible = "bcm,bcm11351-brt", "bcm,bcm11351";
> arch/arm/boot/dts/bcm11351.dtsi:21: compatible = "bcm,bcm11351";
> arch/arm/boot/dts/bcm11351.dtsi:38: compatible = "bcm,bcm11351-smc", "bcm,kona-smc";
> arch/arm/boot/dts/bcm11351.dtsi:43: compatible = "bcm,bcm11351-dw-apb-uart", "snps,dw-apb-uart";
> arch/arm/boot/dts/bcm11351.dtsi:53: compatible = "bcm,bcm11351-a2-pl310-cache";
While I admit that some bindings perhaps should be considered
unstable/experimental, I don't think that would apply here, since it's
simply a rename of an existing sane property value. Other DT maintainers
feel free to chime in if you disagree though.
If the patch is applied for v3.11-rc*, I think it'd be fine since the
old binding would never have been in a released kernel. But, I think
it's far too late in the rc cycle to apply this kind of change.
next prev parent reply other threads:[~2013-08-09 16:11 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 [this message]
[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
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=520514C4.5020007@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