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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <201303261602.40219@pali>
Date:	Tue, 26 Mar 2013 16:02:39 +0100
From:	Pali Rohár <pali.rohar@...il.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Eric Piel <eric.piel@...mplin-utc.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	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 Monday 25 March 2013 00:04:37 Mark Brown wrote:
> On Sun, Mar 24, 2013 at 11:44:59PM +0100, Pali Rohár wrote:
> > On Sunday 24 March 2013 23:14:46 Mark Brown wrote:
> > > Well, you should seek support from the board vendor then.
> > 
> > Not possible. Nokia is already using Windows Phones and life
> > cycle for Nokia N900 phone is at the end. And Nokia never
> > released any HW documentations to community...
> 
> There may well still be people with the required information,
> though in general this sort of thing is always going to be a
> hazard when working on undocumented hardware.
> 
> > Another question: what was reason for that commit
> > ec400c9fab99d16a491cea17d27d0c6a5780b97c
> > "lis3lv02d: make regulator API usage unconditional" ?
> 
> Failing to provide power to a device is typically a very
> serious problem for device operation but the code that was
> there handles such errors by ignoring them.  This isn't a
> robust way forwards and such code should never have been
> merged in the first place, as the changelog says the
> regulator core provides a number of facilities for stubbing
> itself out when it is not required which boards should use.
> 
> Handling the possibility that supplies may not be there not
> only creates needless repetitive complexity in device drivers
> but also decreases the robustness of the system since error
> handling for access to powered down devices often isn't very
> pretty and other drivers or the core may disrupt the
> operation of the device by for example powering it down due
> to not thinking it's in use.
> 
> > I think that for N900 support is reverting above commit
> > needed, I do not see other solution...
> 
> If you're convinced that the regulator is kept on for some
> reason you could always just provide a fake supply, though
> obviously it would be better to hook up the real regulator
> since this may break if at some point the kernel decides that
> whatever is actually providing the supply is unused and can
> be turned off.

CCing Aaro and Tony. Look at this thread on: 
https://lkml.org/lkml/2013/2/16/152

What do you think how to fix this problem? I do not know about any 
HW regulator for n900 accelerometer and possible solutions could 
be revert that commit or adding fake regulator to board code...

-- 
Pali Rohár
pali.rohar@...il.com

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