Thread (1 message) 1 message, 1 author, 2010-02-04

Re: [PATCH] Input: ads7846: add regulator support

From: Mark Brown <hidden>
Date: 2010-02-04 18:59:04
Also in: linux-omap

On 4 Feb 2010, at 18:08, Dmitry Torokhov [off-list ref]  
wrote:
On Thu, Feb 04, 2010 at 04:21:55PM +0000, Mark Brown wrote:
quoted
On Thu, Feb 04, 2010 at 04:52:26PM +0200, Grazvydas Ignotas wrote:
quoted
On Thu, Feb 4, 2010 at 4:24 PM, Mark Brown
quoted
quoted
The updates to fix up the boards that need this are fairly
straightforward and given that it's fairly easy to identify systems
which are using the driver in mainline so I'd really prefer not  
to go
down the route of trying to carry on in the face of error, it  
papers
over stuff now but is not robust in the face of future changes.
quoted
What about warning and continuing only on ENODEV then? I really  
don't
want to be responsible for potentially breaking touchscreen on ~30
boards, where I have no idea about how things are wired up and how  
the
regulators should be set up.
I'm really not terribly enthusiastic about that approach - like I  
say,
it just moves the problem about a bit and postpones the breakage in a
potentially more obscure fashion.
Maybe we should rely on platform data to tell us whether we need to  
plug
into regulator framework and in this case fail hard on any error?
That doesn't really help - it requres per driver code for the platform  
data and for conditionalising all the regulator API calls, results in  
inconsistent behaviour between drivers (does this driver have a no  
regulator switch?) and is looking a bit like the situation where  
you're passing around the regulator name to match device and supply.  
It seems like more work overall for users. 
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help