From mboxrd@z Thu Jan 1 00:00:00 1970 From: arend@broadcom.com (Arend van Spriel) Date: Sat, 27 Jul 2013 12:24:24 +0200 Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?] In-Reply-To: <2007664.vYsECFSKrV@flatron> References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com> <20130727050406.GB4221@netboy> <2007664.vYsECFSKrV@flatron> Message-ID: <51F39FD8.6080808@broadcom.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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