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: <20120420114602.GB3259@opensource.wolfsonmicro.com>
Date:	Fri, 20 Apr 2012 12:46:02 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Jassi Brar <jaswinder.singh@...aro.org>
Cc:	linux-kernel@...r.kernel.org, lrg@...com
Subject: Re: [PATCH] regulator: Provide a check for dummy regulator

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 - the whole reason you're supposed to actually specify the
supplies accurately and not use them is that we've got no way of telling
if the supply there or not from consumer drivers as we just
unconditionally claim that the supply is there.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)