On 17 March 2014 17:15, Mark Rutland <mark.rutland@xxxxxxx> wrote: > 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. I get the idea, let's keep the bindings then. > > 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. I suppose adding a comment about a binding being deprecated in the documentation - is the best we can do for now? Thanks for your response Mark! Kind regards Ulf Hansson > > 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
