linux-kernel - Re: Driver lis3lv02d_i2c not working on Nokia RX-51

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20130326170841.GG18316@opensource.wolfsonmicro.com>
Date:	Tue, 26 Mar 2013 17:08:41 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Pali Rohár <pali.rohar@...il.com>,
	Eric Piel <eric.piel@...mplin-utc.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Aaro Koskinen <aaro.koskinen@....fi>,
	Tony Lindgren <tony@...mide.com>
Subject: Re: Driver lis3lv02d_i2c not working on Nokia RX-51

On Tue, Mar 26, 2013 at 09:08:08AM -0700, Linus Torvalds wrote:

> This is a regression, and it needs to be fixed. The "device needs

This isn't a regression, the commit they're complaining about (ec400c)
was added in October 2011 with a note about all the in-tree users having
been looked after and then the commit adding the registration of the
device (3b511201) was added in May 2012 - the device has just never,
ever worked in mainline on this board as far as I can tell.  It's not
like this was even two commits going in in the same release cycle.

As far as I can tell what's happened here is that someone got round to
testing what was sent upstream for the board and noticed that it never
worked.

> power" crap is just that - crap. Nobody cares. OF COURSE all devices
> need power, but that is totally irrelevant for a driver. The SSD in my
> system "needs power", but I have absolutely zero regulator information
> for it NOR DO I F*CKING NEED ANY!

Right, and this is why the core provides facilities for stubbing things
out.  There's no point in every single driver going and implementing the
same code for handling this stuff, it's repetitive at best.

> I'm going to revert that commit unless you can fix it some other way
> (dummy regulators when you can't find a real one or whatever). The

That's pretty much what I'm telling them to do - put the stub regulators
in if they don't know how things are connected on their board (there's
helpers to make this easier).

There is also an existing Kconfig option to just stub out any missing
regulator which people can use but it's not recommended for production
since it confuses things that may really have optional supplies and want
to handle that.

> notion that you have to have regulator information in order to use
> some random device is insanity. I don't understand how you can even
> start to make excuses like that. It's so obviously bogus that it's not
> even funny.

There's definitely room for improving the stubs, I would like to see
something which lets boards say "these specific regulators are mapped,
these supplies don't exist and stub anything else out with a dummy", but
users like rx51 should be well enough catered for at the minute.

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