linux-kernel - Re: [PATCH V2 0/3] regulator: dt: add policy to match regulator with prop "regulator-compatible"

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: <4FE1F918.1040909@wwwdotorg.org>
Date:	Wed, 20 Jun 2012 10:23:52 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	Linus Walleij <linus.walleij@...aro.org>,
	Laxman Dewangan <ldewangan@...dia.com>,
	devicetree-discuss@...ts.ozlabs.org, grant.likely@...retlab.ca,
	rob.herring@...xeda.com, arnd@...db.de, lrg@...com,
	lee.jones@...aro.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2 0/3] regulator: dt: add policy to match regulator with
 prop "regulator-compatible"

On 06/20/2012 04:00 AM, Mark Brown wrote:
> On Wed, Jun 20, 2012 at 10:59:32AM +0200, Linus Walleij wrote:
> 
>> If I had today deployed the device trees generated prior to this
>> patch, and try to boot kernels after this patch with the same
>> device tree, would they still work as expected?
> 
>> I don't know it it's an issue right now, but at some point we
>> need to realize that people will expect old device trees to work
>> on newer kernels.
> 
> I don't think anyone's taking that idea terribly seriously right
> now for ARM, lots of the core SoC bindings are still in flux or not
> there.
> 
> Even for PowerPC where this has apparently been achieved I've still
> had to push back on new mandatory properties being added :/

For Tegra bindings at least, I had historically tried to be extremely
hard-and-fast on binding changes, based on this compatibility requirement.

However, at Linaro Connect Q1 I think, Grant made the point that he
considers the current binding definitions a work-in-progress in
general since as you say, everything is so new. So, I've backed off on
the 100% compatibility requirement until things are more solidified.
It's better to fix broken stuff that force any historical binding bugs
not be fixed.

Related to this, I wonder if we need some scheme to tag individual
bindings as under-development vs. final, and some way to promote
bindings between those states (a bindings review board?!). Do binding
definitions need versions? This perhaps might be coupled with the
binding documentation (even .dts files?) moving out of the kernel tree
to some other repository. To be honest, until/unless the source and
.dts files or binding docs are separated, it's slightly hard to argue
that the bindings ever need to be static, since the idea appears to be
to always use the .dts file that shipped with the kernel you built,
and upgrade them both at once.
--
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/