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] [day] [month] [year] [list]

Message-ID: <20101006151446.GA2803@opensource.wolfsonmicro.com>
Date:	Wed, 6 Oct 2010 08:14:47 -0700
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Linus Walleij <linus.ml.walleij@...il.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

On Wed, Oct 06, 2010 at 10:01:10AM +0200, Linus Walleij wrote:
> 2010/10/6 Mark Brown <broonie@...nsource.wolfsonmicro.com>:

> > 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.

This is a totally different use case to that being discussed in this
thread - the use case being discussed in this thread is for things like
core power supplies which are critical to the operation of the device.
The expected error handling if these supplies are missing would be to
abort.

For users that can reasonably do optional supplies I'd expect that there
would be other code which also needs to be conditional which relies on
some action having being taken on the regulator and would also need to
be bypassed so it'd be a bit surprising if things didn't get caught up
in a bigger conditional block.

> I think what Alan requested is that it be made more seamless.

I'm fairly sure he's talking about the use case above, though I'm not
100% sure how familiar with the API Alan is.  Note also that the way
you've done this with things returning success for nonexistant supplies
means that things are less seamless than they might be.

> > 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.

No, they're a feature of the compiled in regulator API (which happen to
behave in the same manner as the stubs you get if the API is disbled).

> 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.

He's looking for something that can be used for supplies that are
critical to device operation on random devices on the board, something
that says that all unconfigured supplies are actually provided by
non-specific fixed voltage regulators.  This is different from the case
where some supplies may be missing because they really are not present
(in that the supplies are there, we've just not told the system how
they're provided).  Alan and Marek need boards to be able to say that
every device on the board has a supply even if it's not explicitly
configured while you want to be able to more easily ignore failures with
specific supplies.

> 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?

Pretty much for your use case, though if enough things like MMC have
cases where supplies truly can just be omitted with no effect on the
operation of the system at all then I guess a consumer initiated way to
request a dummy could be in order.  I'd worry that people will just end
up randomly using it for all supplies, though.
--
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/