On 07.12.23 21:44, Mark Brown wrote: > There is a specific API for exclusive regulators which the driver is not > using, and it's unconditionally doing the disable/enable cycle here. > That is right, I will call regulator_get_exclusive() instead. > The driver needs to be explicitly configured for this and have separate > code paths for normal operation and operation where the supply can be > bounced like this. In neither code path should the supply be optional. > Right now we don't have a mechanism for discovering optionally exclusive > and enable/disablable supplies which is what the device needs, we could > potentially add that since this does seem like a viable use case and we > already have enough information in the DT to say if the supply matches > the constraints. Probably the two properties queryable separately. If > that API were added then the driver would do a normal regulator_get() > then check if it has the capabilities it needs and either keep the > supply on all the time (or possibly just during measurements?) or enable > the alarm functionality. In that case I will split the driver development into two steps. First I will stick to the existing API and implement only the code path where an exclusive regulator is required i.e. not optional, which will simplify the review process considerably. When the driver makes it through and all other issues are also solved, I will work on the optional exclusive regulator. This is probably an edge case and it will increase complexity to actually use half of the device capabilities to save the exclusive regulator, but at some point I would like to offer that as well. Thank you again and best regards, Javier Carrasco
