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]
Date:	Mon, 10 Sep 2012 10:13:16 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Lee Jones <lee.jones@...aro.org>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	STEricsson_nomadik_linux@...t.st.com, linus.walleij@...ricsson.com
Subject: Re: [PATCH 00/19] First HREF Device Tree enablement patch-set

On Monday 10 September 2012, Linus Walleij wrote:
> Basically that was at a point when we were changing a lot of
> subsystem trees with DT patches that were merged in out-of-order
> fashion.
> 
> Then it's better to have the DT changes to be pushed
> separately at the end of the merge window after all subtrees
> with dependent changes are merged. (Or even in the next merge
> window if there is no hurry, but we always seem to be in a hurry...)
> 
> If all the changes are in the same subtree (like ARM SoC with
> ACKs from all over the place where needed) you can do it
> this way instead, and I agree it looks better.

I think we're talking about different things:

I think it's fine to do the device driver conversion separately
from the platform changes, but doing that properly means that the
platform changes should only go in after the drivers have changed.

Inside of the platform code, I absolutely think we should change the
board file and the dts file simultaneously. When the driver offers
two ways of probing a device, this lets us change from one way to
the other without going through a phase where we use neither of them
or (worse) both at the same time.

	Arnd
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ