On Mon, Mar 17, 2014 at 02:00:58PM +0000, Linus Walleij wrote: > On Mon, Mar 17, 2014 at 11:01 AM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > On 14 March 2014 11:58, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > >> On Fri, Mar 14, 2014 at 8:27 AM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > >>> On 13 March 2014 18:47, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > > >>>> NAK. These bindings have been documented as being there since March > >>>> 14th 2012, and therefore need to be supported for ever by the driver. > >>>> You can _augment_ the bindings with the generic ones, and change the > >>>> DT files, but you can't remove the parsing of the old property names. > >>> > >>> I was kind of expecting this response. :-) > >>> > >>> So, since we made a mistake about adding these DT bindings we are now > >>> unable to remove them, is there really no way back? > >>> > >>> In this particular case, I am confident that it should be safe to > >>> remove them, but I guess this is more matter of principle, right? Basically, yes. Our default position is to not break existing DTBs. In general that's beneficial, ensures stability, and keeps people in the right mindset. Sticking to the position even where we could be a little softer is a way of keeping people honest -- practically everyone has a binding (or seventy) which they hate and would love to change, sticking to the rules (even when painful) saves us from endless churn for little benefit. In this case the binding isn't broken; it provides the information we need, but just not with our preferred names. As Russell has pointed out, we can support the more standard names in addition to the current ones (which we can deprecate for new DTs). Forcibly breaking existing DTBs is not necessary, and I'm not sure if it's worthwhile for the sake of a few bytes. There are bindings out there which are fundamentally broken, which are always reliant on platform data or just don't currently work. Those are what we need to focus on fixing to ensure long-term support. We also need a strategy for binding deprecation, which we do not have currently. There was talk of unstable bindings at the last mini-summit to allow people to tinker without committing to long-term support of bindings, but nothing seems to have happened on that front. It would be nice to have a plan for dealing with all these vestigal bits long term. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
