linux-kernel - Re: linux-next: manual merge of the arm-soc tree with the i2c-embedded tree

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: <20120718111226.GH22739@opensource.wolfsonmicro.com>
Date:	Wed, 18 Jul 2012 12:12:26 +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 Wed, Jul 18, 2012 at 08:35:21AM +0100, Lee Jones wrote:

Fix your mailer to word wrap within paragraphs.  I've reformatted your
mail for legibility.

> I agree, but in this instance it really does stand to reason.

> 1. No unified bindings currently exist.
> 2. I don't have time to create them.
> 3. It will probably take quite a bit of time for someone else to get
>    round to creating them.
> 4. The bindings I'm proposing are siloed by vendor and driver, so will
>    cause no harm.

Right, this is just a restatement of the standard vendor line.

If the issue is purely about having generic bindings quite frankly it's
very hard to see how it could take much time or effort to handle the
generic bits for I2C, it's basically just the maximum bus frequency and
possibly also the various fast modes (though to a good approximation it
seems reasonable to just infer them from the bus frequency and then see
if we need any more).  One thing I frequently find is that people say
any sort of generic work is hard without explaining why, if there are
complex issues that's one thing but that's often not the case.

BTW, looking at the platform data again it seems like i2c_freq_mode it
seems very odd that it's driver specific?

> 5. I've already volunteered to move them over to the unified ones once
>    created.
> 6. These allow support for the driver to work with DT, at the moment
>    it does not.

> Personally, I think there is more to be gained by applying the
> (working) vendor specific bindings to the vendor specific driver until
> some more consolidated ones appear.

Again, vendors always make great promises about how they're going to
keep everything up to date...

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