On 07/27/2013 12:24 PM, Arend van Spriel wrote:
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.
Oh, and the reason for my tinkering on dts is here:
http://mid.gmane.org/51e7aa24.6080...@broadcom.com
Happily using Pandaboard for my driver testing and than *kaboom*.
board-omap4panda.c is gone although the device tree does not provide the
same functionality. Of course, this is not about DT bindings.
Regards,
Arend
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
