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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
