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 14:21:49 +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 On 04/23/2012 01:05 PM, Mark Brown wrote: > On Mon, Apr 23, 2012 at 12:52:05PM +0200, Ulf Hansson wrote: > >> 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!? > > To be honest I don't entirely understand what your goal is at the system > level - the current idea is that either the regulator will be marked as > always_on or it should be enabled by a consumer. What is the scenario > in which neither of these is sufficient? The consumer do not want to enable the regulator directly from its device probe routine, it is handled through a scheduled work. Moreover the regulator shall not be switched off unless the consumer work decides that this is OK. So, we actually will have a race were the work _might_ be able to preventing the late_init_call (regulator_init_complete) from disabling the regulator if has reached the point were it has enabled the regulator. Hopes this clarifies the background a bit more. 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