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
| ||
|
Date: Mon, 23 Apr 2012 12:52:05 +0200 From: Ulf Hansson <ulf.hansson@...ricsson.com> To: Mark Brown <broonie@...nsource.wolfsonmicro.com> Cc: Liam Girdwood <lrg@...mlogic.co.uk>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Mattias WALLIN <mattias.wallin@...ricsson.com>, Jonas ABERG <jonas.aberg@...ricsson.com>, Lee Jones <lee.jones@...aro.org> Subject: Re: [PATCH] regulator: core: Keep boot_on regulators powered during init Hi Mark, Thanks for a quick reply. On 04/23/2012 12:18 PM, Mark Brown wrote: > On Mon, Apr 23, 2012 at 11:37:53AM +0200, Ulf Hansson wrote: > >> Regulators which has boot_on constraints set, will now remain >> powered after regulator_init_complete is done. > > This would be a bug. All boot_on means is that the regulator was turned > on during boot, the regulator is free to vary after that. The idea is to prevent the late_init_call "regulator_init_complete" from disabling a regulator that "recently" were enabled due to it's boot_on constraints. > >> In this case we leave the enable->disable operation to be >> handled by the regulator consumer instead. > > Which would be a bug if the consumer wasn't the thing that took the > reference to the regulator in the first place. Remember, regulators can > be shared so the consumer can't disable a regulator it didn't enable in > the first place (unless it used regulator_get_exclusive() but the use > cases for that are a little suspicious so it'd be worth taking a careful > look before using it). A consumer can't tell if the regulator was left > enabled by the firmware on boot or if it has been enabled by another > consumer. I realize that using boot_on, which has been around for quite some time could have problems. If not using the existing boot_on constraint, do you have an idea of how to accomplish what I want? Should I invent a new constraint option to be used in regulator_init_complete!? Kind regards Ulf Hansson -- 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/
Powered by blists - more mailing lists