Re: [PATCH v3] rust: regulator: add a bare minimum regulator abstraction

["Benno Lossin" <lossin@kernel.org>]

On Sun May 18, 2025 at 2:20 PM CEST, Mark Brown wrote:
> On Sun, May 18, 2025 at 05:14:41PM +0900, Alexandre Courbot wrote:
>
>> The initial proposal does such clamping by design, but I also suspect
>> the C API behave like it does for good reasons (which I am not familiar
>> enough to be aware of unfortunately).
>
> It's so that if you have multiple logical users within the device (eg,
> an interrupt handler and code for normal operation) they can work
> independently of each other.  You could also request the regulator
> multiple times but that's often not idiomatic.
>
> Originally we didn't actually refcount within the individual consumers
> at all and only refcounted on the underlying regulator, the per consumer
> reference count is mainly there for debugging purposes.

I'm not sure if I understand correctly, so I'll just try to echo it and
see if it's correct :)

The `enable`/`disable` functions change a refcount on the underlying
regulator that tracks if the regulator actually is enabled/disabled.
Asking the hardware to enable or disable a regulator can fail, but if we
already know that it is enabled, only the refcount is incremented.
    It's okay to leak this enabled-refcount, since when the regulators
actual refcount (so the one adjusted by `_get` & `_put`) hits zero, we
can also disable the regulator. So the enabled-refcount is essentially a
weak refcount that only does something while the regulator exists.

In that case, we can use any API for enabling/disabling, since all of
them will be safe. Just a question of which gives the required
expressiveness and makes misusing it hard.

---
Cheers,
Benno