All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali.rohar@gmail.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Eric Piel <eric.piel@tremplin-utc.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	Aaro Koskinen <aaro.koskinen@iki.fi>,
	Tony Lindgren <tony@atomide.com>
Subject: Re: Driver lis3lv02d_i2c not working on Nokia RX-51
Date: Tue, 26 Mar 2013 16:02:39 +0100	[thread overview]
Message-ID: <201303261602.40219@pali> (raw)
In-Reply-To: <20130324230435.GE18316@opensource.wolfsonmicro.com>

[-- Attachment #1: Type: Text/Plain, Size: 2385 bytes --]

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@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2013-03-26 15:02 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-16 23:46 Driver lis3lv02d_i2c not working on Nokia RX-51 Pali Rohár
2013-02-17 16:25 ` Mark Brown
2013-02-17 16:40   ` Pali Rohár
2013-02-17 18:17     ` Mark Brown
2013-03-24 14:50       ` Pali Rohár
2013-03-24 21:21         ` Mark Brown
2013-03-24 21:27           ` Pali Rohár
2013-03-24 22:14             ` Mark Brown
2013-03-24 22:44               ` Pali Rohár
2013-03-24 23:04                 ` Mark Brown
2013-03-26 15:02                   ` Pali Rohár [this message]
2013-03-26 15:44                     ` Mark Brown
2013-03-26 16:08                       ` Linus Torvalds
2013-03-26 17:08                         ` Mark Brown
2013-03-26 20:53                     ` Aaro Koskinen
2013-03-26 21:19                       ` Mark Brown
2013-03-28 14:11                       ` Pali Rohár

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201303261602.40219@pali \
    --to=pali.rohar@gmail.com \
    --cc=aaro.koskinen@iki.fi \
    --cc=akpm@linux-foundation.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=eric.piel@tremplin-utc.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony@atomide.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.