From mboxrd@z Thu Jan 1 00:00:00 1970 From: swarren@wwwdotorg.org (Stephen Warren) Date: Fri, 09 Aug 2013 13:14:47 -0600 Subject: [PATCH v2] ARM: DT: binding fixup to align with vendor-prefixes.txt In-Reply-To: References: <1375482479-15732-1-git-send-email-csd@broadcom.com> <51FFCC42.6040300@wwwdotorg.org> <5200407A.4010407@broadcom.com> <520079DB.5090309@wwwdotorg.org> <52016D44.7060808@broadcom.com> <520514C4.5020007@wwwdotorg.org> Message-ID: <52053FA7.5010809@wwwdotorg.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 08/09/2013 12:49 PM, Christian Daudt wrote: > [resend in plain-text] > > > On 2013-08-09 9:11 AM, "Stephen Warren" 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.