Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we havepeople interested in device tree janitoring / cleanup?]

[Arend van Spriel]

On 07/27/2013 11:51 AM, Tomasz Figa wrote:
> On Saturday 27 of July 2013 07:04:08 Richard Cochran wrote:
> > On Fri, Jul 26, 2013 at 08:49:43AM -0700, Olof Johansson wrote:
> > > Long term, final goal is likely to be close to what Russell is saying
> >
> > Why is this a long term goal? Start today.
> >
> > > -- nothing should go into the kernel tree unless the binding is in a
> > > fully stable state. However, we have a transitional period between now
> > > and then, and even when we're at the final state there will be need to
> > > have some sort of sandbox for development and test of future bindings.
> >
> > Why not just set up a git tree right away?
> >
> > > Dealing with all that, as well as the actual process for locking in
> > > bindings, is what needs to be sorted out.
> > >
> > > I think we're all in agreement that bindings that change over time are
> > > nothing but pain, but we're arguing that in circles anyway.
> >
> > No.
> >
> > I keep saying, the bindings must be stable ABI, *today*.
> >
> > You keep saying, maybe later, but until then we will make things up as
> > we go along.
>
> We have currently a lot of broken bindings, because people didn't know how
> to define ones and those they defined have not been properly reviewed. Do
> you really want such broken ABI in the kernel?
>
> Sure, there are many existing bindings that can be just made stable and
> well they probably are already de facto stable. This is mostly about
> subsystem bindings and whatever already has many users, both made them get
> more thought when designing and more review before merging.
>
> Still, a lot of device and platform-specific bindings are simply broken.
> Take max8925 backlight driver, that Olof started this whole discussion
> with, as an example. We need to sort them out before they can be
> stabilized.

That is a nice summary of how we got from null to now and Richard seems 
to be simply saying: let's stop mucking about and make this a project 
with a well-defined process of dealing with staging and stable bindings 
and keep stable bindings stable. Whether it should be within the kernel 
repo as a separate subsystem or in an entire different repo is a trivial 
decision, but still a decision that needs to be made.

Apart from stable DT bindings I would love to see a DT compiler that 
that next to DT syntax detects mistakes in properties used for the 
selfish reason that I spent hours debugging regulator code, because I 
typed vmmc_supply iso vmmc-supply. I did not go through all the 
bindings, but this may require a more formal description so it could be 
compiled/read in the DT compiler.

Regards,
Arend

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/