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: Thu, 09 Oct 2014 23:56:59 +0200 From: Javier Martinez Canillas <javier.martinez@...labora.co.uk> To: Mark Brown <broonie@...nel.org> CC: Krzysztof Kozlowski <k.kozlowski@...sung.com>, Doug Anderson <dianders@...omium.org>, Chanwoo Choi <cw00.choi@...sung.com>, Olof Johansson <olof@...om.net>, Chris Zhong <zyw@...k-chips.com>, Abhilash Kesavan <kesavan.abhilash@...il.com>, linux-samsung-soc@...r.kernel.org, linux-kernel@...r.kernel.org, devicetree@...r.kernel.org Subject: Re: [PATCH 3/5] regulator: dt-bindings: Add regulator-initial-mode support On 10/09/2014 09:01 PM, Mark Brown wrote: > On Thu, Oct 09, 2014 at 05:04:35PM +0200, Javier Martinez Canillas wrote: > >> Agree, Mark also pointed out that there is a difference between changing >> how the regulator will behave on runtime vs changing how the regulator >> will behave during system suspend. AFAIU from his explanation, the modes >> defined in consumer.h only applies to the former and conceptually there >> should be a difference between those two cases even when the Maxim PMIC >> seems to mix it both in the data-sheet and by using the same field. > > No, that's not accurate at all - you're still not getting the concepts > of modes or suspend handling in the regulator API. I really think you > need to take a step back and try to understand what's currently there > before trying to make changes here. We've got a set of operations we > can use to change the regulator configuration, if you look at the > existing driver interface you'll see that these are matched with > equivalent operations for setting the behaviour when in suspend > (including a set_suspend_mode() operation). > I tried to say that there is a difference between the need to change within the kernel a regulator configuration (e.g: change opmode from normal to low power) when the system is going to enter in suspend state vs setting a register at probe time that will force the PMIC to change the regulator to low power mode on suspend without kernel intervention. > Like I keep saying abstractions are really important to making sure the > code is maintainable. > Agree, I'll try to come up with a more sensible solution by using the existing abstractions from the regulator framework. Best regards, Javier -- 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