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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51F3A238.3020505@broadcom.com>
Date:	Sat, 27 Jul 2013 12:34:32 +0200
From:	"Arend van Spriel" <arend@...adcom.com>
To:	"Tomasz Figa" <tomasz.figa@...il.com>
cc:	"Richard Cochran" <richardcochran@...il.com>,
	"Olof Johansson" <olof@...om.net>,
	"Mark Brown" <broonie@...nel.org>,
	"Mark Rutland" <mark.rutland@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"ksummit-2013-discuss@...ts.linuxfoundation.org" 
	<ksummit-2013-discuss@...ts.linuxfoundation.org>,
	"Russell King - ARM Linux" <linux@....linux.org.uk>,
	"Ian Campbell" <ian.campbell@...rix.com>,
	"Pawel Moll" <Pawel.Moll@....com>,
	"Stephen Warren" <swarren@...dotorg.org>,
	"Domenico Andreoli" <cavokz@...il.com>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Jason Gunthorpe" <jgunthorpe@...idianresearch.com>,
	"Dave P Martin" <Dave.Martin@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]

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.6080600@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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/