Hi Mark, On 05.06.2020 12:20, Mark Brown wrote: > On Fri, Jun 05, 2020 at 08:37:24AM +0200, Marek Szyprowski wrote: > >> Balancing of the 'boot-on' coupled regulators must wait until the clients >> set their constraints, otherwise the balancing code might change the > No, this is not what boot-on means at all. It is there for cases where > we can't read the enable status from the hardware. Trying to infer > *anything* about the runtime behaviour from it being present or absent > is very badly broken. Okay, what about the 'always-on' property? I don't think that we need another property for annotating this behavior, as in my opinion this is just an implementation issue on the Linux kernel and regulator framework. Alternatively I can drop the property check, but then it won't be possible to have a regulator without a consumer, which follows the other one (although we still don't have a real use case for it). If you don't like this idea at all, I will try to move this logic to the custom coupler again, although it would mean some code copying. > Saravana (CCed) was working on some patches which tried to deal with > some stuff around this for enables using the sync_state() callback. > Unfortunately there's quite a few problems with the current approach > (the biggest one from my point of view being that it's implemented so > that it requires every single consumer of every device on the PMIC to > come up but there's others at more of an implementation level). I'm not sure if we really need such complex solution for this... Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
