On Thu, 24 Oct 2013, David Woodhouse wrote: > > > > > On Thu, 2013-10-24 at 13:10 +0000, David Woodhouse wrote: > > > >> Note that you are not describing a normal "DT scenario" here. You are > >> describing a case in which we screwed up > > > > AKA "real world" > > No. Absolutely not. That was a screwup, and it needs to be *rare*. The > excuses you present for it are crappy and uunacceptable. Let's get real please. It is just too easy for DT reviewers in their ivory tower to shot down submissions because the bindings are not to their liking. The world out there is not stable. Things change. Hardware is revised all the time. Software change to cope. And even when the hardware is stable, new software solutions come about to improve things. That's the point of _soft_ware, isn't it? Flexibility is needed in order to scale. "DT only describe the hardware" is often brought up as if that was the ultimate argument for its "stability". But descriptions, even hardware descriptions, may be subjective i.e. two humans might describe it differently. Incidentally DT bindings are created by humans and are therefore imperfect and suboptimal most of the time. We used to have very lenient reviews on new DT bindings. Sure some of them were bad. The recent reaction to that was to go 180 degrees and accept only near perfect bindings. But the cure is now hurting more than the initial problem. Sure, the world would be so much better if DT bindings could be optimal on the first shot. But asking that DT bindings remain stable when the world around them is not is asking for the impossible. So IMHO the failure with DT right now is actually the expectations that come with it. Those expectations are not realistic. Special cases are the norm, whether you like it or not. In fact we all hate special cases because they make what would otherwise be a very straight forward and elegant process rather messy. This is why a process needs to concern itself with special cases since this is where a process is even more helpful. So instead of trying to enforce even more stability in the DT bindings with stricter rules, I think that the process should instead concern itself with better ways to _allow_ and _facilitate_ binding updates. This is much more likely to scale, and result in a better system in the end. And since there is so many changes one can bring to ultimately describe some piece of hardware, the DT bindings will naturally reach a stable state eventually. But that cannot be known in advance when that will be. Nicolas -- 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
