linux-kernel - Re: Doubt about Regulator Framework and VBAT use case

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:	Mon, 30 Nov 2009 11:45:15 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Eduardo Valentin <eduardo.valentin@...ia.com>
Cc:	"Hogander Jouni (Nokia-D/Tampere)" <jouni.hogander@...ia.com>,
	"De-Schrijver Peter (Nokia-D/Helsinki)" 
	<Peter.De-Schrijver@...ia.com>,
	"Keski-Saari Juha.1 (EXT-Teleca/Helsinki)" 
	<ext-juha.1.keski-saari@...ia.com>,
	LKML <linux-kernel@...r.kernel.org>, lrg@...mlogic.co.uk
Subject: Re: Doubt about Regulator Framework and VBAT use case

On Mon, Nov 30, 2009 at 12:41:02PM +0200, Eduardo Valentin wrote:

> I'm writing to ask about VBAT use case. What is the expected
> way to use regulator framework in case of rail coming from battery?
> Should it be added to the regulator framework at all?

...

> However, drivers for devices on that rail would require their regulator anyway.
> And I guess the point would be that drivers should not be aware that they are on VBAT
> or any other rail.

I'd add it as a fixed voltage regulator and either not specify the
voltage or specify the nominal voltage.

> - Should drivers fail nicely if a regulator_get fail? And continue even if one fails.
> - Should drivers disable regfw usage completely in the driver if regulator_get doesn't
> give valid regulator ?

These are reasonable approaches if the supply is an optional one that
the device does not need - the driver shouldn't be failing if it doesn't
need to.

> - or Should a fake fixed regulator be added for vbat so drivers can still get a valid
> regulator with regulator_get.

That's the way to do it, yes.

> The last options seams to be the one that does not require much changes on drivers.
> But it will be adding a regulator that does basically nothing in the system.

It's not quite doing nothing, it's mapping out the supply on the board.
Otherwise there's no good way to tell the difference between a supply
not being available because the regulator failed to initialise and the
supply not being available because it's provided by some other invisible 
means.

If the regulator API starts getting a lot of usage on boards that have
primarily fixed regulators we may want to have some support in the core
for automatically faking up supplies if requested by the board but
there's not been much demand for that yet and there's risks.
--
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/