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, 8 May 2017 15:51:02 +0530 From: Viresh Kumar <viresh.kumar@...aro.org> To: Mark Brown <broonie@...nel.org>, Liam Girdwood <lgirdwood@...il.com> Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, "Nayak, Rajendra" <rnayak@...eaurora.org>, Stephen Boyd <sboyd@...eaurora.org>, Vincent Guittot <vincent.guittot@...aro.org>, Serge Broslavsky <serge.broslavsky@...aro.org> Subject: [RFC] regulator: Shared regulators (configured by bootloader) Hi Mark/Liam, I am looking to solve a problem faced by some of the Qualcomm platforms and want your suggestions on how should we fix it. One of my ex-colleague tried to solve [1] this problem but that thread never concluded (and I don't really agree with the solution it offered). Problem statement A regulator is shared by multiple devices and their drivers can get probed in any order. The regulator is configured (with constraints suitable for one or more devices) by the bootloader (i.e. regulator was ON at kernel boot). While the drivers get probed, they may choose to disable or reconfigure the regulator. And that is of course the right thing to do for those drivers. But this might not be ideal for other devices which share the regulator and are currently using it (but haven't been probed yet). A typical use case in cell phones is to put up a simple splash screen in the bootloader and replace that screen when userspace is running (typically with the home screen). If a shared regulator is enabled in the bootloader to power the screen and left on during kernel initialization, it's possible that a non-screen driver may disable or reconfigure the regulator from its probe() and that would generate a glitch at the screen, which wouldn't be nice. Solution(s) There is no way for us to know when the kernel has done booting, specially with the drivers compiled as modules, as they can be inserted anytime. For example, if the LCD driver is never inserted to the kernel, then we should never allow to regulator to get disabled (Even if that results in loss of energy). I was wondering if we should add some DT properties to consumer devices to list down such constraints and create "proxy" regulators for them as soon as possible during the kernel boot (maybe from regulator_register()). Of course that would require us to traverse all DT nodes containing such properties, as the device drivers shouldn't be up by then. And finally once the drivers are probed and try to get regulator for the device, we remove these proxy regulators (only after creating the real ones). If driver for some proxy regulator doesn't get probed, then that regulator stays ON for ever. Suggestions ? Take your time to reply, I know that the merge window has just started. -- viresh [1] https://lkml.org/lkml/2016/5/9/64
Powered by blists - more mailing lists