On 4 Feb 2010, at 18:08, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
wrote:
On Thu, Feb 04, 2010 at 04:21:55PM +0000, Mark Brown wrote:
On Thu, Feb 04, 2010 at 04:52:26PM +0200, Grazvydas Ignotas wrote:
On Thu, Feb 4, 2010 at 4:24 PM, Mark Brown
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.
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
