linux-kernel - Re: [PATCH] regulator: Provide a check for dummy 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]

Message-ID: <CAJe_ZhdKv_7fTj9ZhJE0JzmuhxEZn-JmSbHu615YMXoWZUei9A@mail.gmail.com>
Date:	Fri, 20 Apr 2012 17:59:42 +0530
From:	Jassi Brar <jaswinder.singh@...aro.org>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	linux-kernel@...r.kernel.org, lrg@...com
Subject: Re: [PATCH] regulator: Provide a check for dummy regulator

On 20 April 2012 17:16, Mark Brown <broonie@...nsource.wolfsonmicro.com> wrote:
> On Fri, Apr 20, 2012 at 01:02:06PM +0530, Jassi Brar wrote:
>
>> Say, an audio CODEC chip has a simple PLL1 run by main voltage
>> domain(Vmain). PLL1 can only support 11025x sample rates.
>> Another PLL2 on the chip, powered by optional supply Vaux, could
>> provide 8000x sample rates. Obviously low-end platforms could choose
>> to not provide Vaux.
>
>> The platform has some other drivers that need to have dummy regulator
>> support enabled.
>
>> How is the CODEC driver supposed to know if 'vaux' is actually present?
>> Because if it isn't present, the driver wouldn't declare support for
>> 8000x  rates.
>> regulator_get() would always succeed, and regulator_is_enabled() would
>> always return 1, even if the vaux is not supplied.
>
> This is just one of those cases that won't ever work well with dummy
> regulators
>
That's what I have been trying to fix. My example might be fictitious but
I have a real scenario with omap_hsmmc (I was avoiding getting into that).

The dummy not just provide a place holder data structure for missing definition
of an available supply, but it also masks the fact that there might indeed be no
supply at all on the given machine.

As I said, atm the only option for a consumer is to know it via PD/DT.

We can avoid requiring this 'oob' info by simply letting the consumer driver
know that  "The platform didn't provide the supply, but here is a dummy
one in case you don't strictly require your supplies be completely defined
by all platforms".
Which can be achieved by simply adding that regulator_is_dummy() call.

The benefit is magnified by the fact that, for a given circuit, at
least theoretically,
there is no limit to the number/combination of supplies that could be controlled
by inserting a regulator. And that could lead to a very noisy PD/DT.

Thanks,
-Jassi
--
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/