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:	Tue, 17 Jul 2012 16:20:01 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Lee Jones <lee.jones@...aro.org>
Cc:	Wolfram Sang <w.sang@...gutronix.de>,
	Linus Walleij <linus.walleij@...aro.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Olof Johansson <olof@...om.net>, Arnd Bergmann <arnd@...db.de>,
	linux-arm-kernel@...ts.infradead.org, linux-next@...r.kernel.org,
	linux-kernel@...r.kernel.org, Alessandro Rubini <rubini@...dd.com>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	Stephen Warren <swarren@...dotorg.org>,
	Deepak Saxena <dsaxena@...aro.org>,
	devicetree-discuss@...ts.ozlabs.org,
	Grant Likely <grant.likely@...retlab.ca>
Subject: Re: linux-next: manual merge of the arm-soc tree with the
 i2c-embedded tree

On Tue, Jul 17, 2012 at 03:52:10PM +0100, Lee Jones wrote:

> I think it would be okay to take the 3 patches due for the v3.6
> merge window, which target the nmk-i2c driver. If any consolidation
> happens in the mean-time/future I will personally do the work to
> bring the nmk-i2c into line to use any generic bindings which
> result.

> No one else is ever going to use these vendor specific bindings, so
> I'm sure no issues will arise. It also means that we have a fully
> enabled driver which is capable of receiving a new configuration via
> minor changes to the dts, which is important for the current (only)
> user of this driver for an upcoming project.

So, this is pretty much what vendors always say about this stuff...

Looking at what's specified in the platform data in the current kernel
it seems like there's a mixture of things in there that are board and
silicon specific.  We've got parameters like the the speed mode and
timeout which are reasonably board specific but we've also got things
like the FIFO sizes which shouldn't be at all board specific and slsu
which really looks like it's something that that the driver ought to be
able to figure out for itself.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ