[PATCH v2] Input: Make ADS7846 independent on regulator

[Linus Walleij]

2010/10/6 Mark Brown <broonie at opensource.wolfsonmicro.com>:

> On Wed, Oct 06, 2010 at 12:09:39AM +0200, Linus Walleij wrote:
>
>> This wrapper function will accept non-existing regulators and
>> not treat them as errors. Consumers will have to NULL-check their
>> regulators.
>
> No, this is actively unhelpful.  If consumers can null check their
> regulators then they can just as well do an IS_ERR() check

.. and wrap all enable/disable/ etc into conditional statements
that depend on whether we could locate a regulator or not.

And yes, this is what I'm already doing in drivers like
drivers/mmc/host/mmci.c, where I check for the regulator
holder in the mmci state struct to be NULL (another way
would be to have a boolean .has_regulator but you get the
idea).

I think what Alan requested is that it be made more seamless.
The patches try to make regulator support less hairy in these
cases, a non-existing regulator will be a NULL pointer (no error
and the runtime functions will act as the compile-time stubs.

> The existing dummy regulator support already does all this in a manner
> which is much less invasive for the core.

Correct me if I'm wrong but the dummy regulators are something
different which appear when you choose to compile out regulator
support altogether.

This was not what Alan was asking about I believe, the usecase
to addressed is partial regulator support, where regulator framework
*is* compiled in, but a driver *may* not get a regulator from the
framework.

The patch makes the runtime functions with partial regulator
support for a NULL regulator behave exactly like the
compile-time stubs.

If I read your answer right, your stance is that the regulator
framework shall not help out in situations like this, instead
the driver shall recognice -ENODEV from regulator_get() and
avoid doing any regulator calls after that. Is this correct?

Yours,
Linus Walleij