linux-kernel - Re: [PATCH v2] Input: Make ADS7846 independent on regulator

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]

Date:	Wed, 6 Oct 2010 10:01:10 +0200
From:	Linus Walleij <linus.ml.walleij@...il.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Igor Grinberg <grinberg@...pulab.co.il>,
	Marek Vasut <marek.vasut@...il.com>,
	linux-arm-kernel@...ts.infradead.org, vapier@...too.org,
	khilman@...prootsystems.com, linux-kernel@...r.kernel.org,
	pavel@....cz, linux-input@...r.kernel.org, eric.y.miao@...il.com,
	akpm@...ux-foundation.org
Subject: Re: [PATCH v2] Input: Make ADS7846 independent on regulator

2010/10/6 Mark Brown <broonie@...nsource.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/