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

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

On Mon May 19, 2025 at 12:52 PM CEST, Daniel Almeida wrote:
>> I just mean the cases where users will want to enable and disable the
>> regulator more frequently than just enabling it at probe time.
>
> This is already possible through kernel::types::Either. 
>
> i.e.: the current design - or the proposed typestate one - can already switch
> back and forth between Regulator and EnabledRegulator. Using Either makes it
> just work, because you can change the variant at runtime without hassle. This
> lets you consume self in an ergonomic way.

Have you tried to write such a use-case using `Either`? My personal
experience with `Either` was pretty horrible, since you always have to
match on it before you can do anything to the values. It's not really
ergonomic.

I think we should remove it, as it also doesn't have any users at the
moment. Anyone that needs it should define a custom enum for their
use-case.

And effectively an `Either<Regulator, EnabledRegulator>` is just a
`Regulator<Switch>` in Alexandre's proposal if I understood it
correctly.

> By the way, the reason I'm pushing back slightly here is because you seem
> (IIUC) to be trying to reintroduce the pattern we had to move away from in v1.
>
> i.e.: we explicitly had to move away from trying to match enables and disables
> in Rust, because it was hard to get this right.
>
> The current design is a simplification that apparently works, because at best
> you have +1 on the count and that is encoded in the type itself, so there is
> nothing to actually "track" or "balance" within a given instance. Multiple
> calls to _get() or _enable() on the same instance are simply forbidden.
>
> Can you add some pseudocode that shows how this doesn't work (or is otherwise
> unergonomic) in Nova? I think it will make your point clearer.

+1 on actual code examples :)

---
Cheers,
Benno