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

[Daniel Almeida]

Hi Mark,

> 
>> I asked for a few opinions privately and was told that “if the C API prefers not to do that
>> why should you?”
> 
> Well, the C API also doesn't ignore either enable or disable attempts...
> the theory is that if the consumer messed up it's safer to not power the
> hardware off suddenly when something might not have been cleaned up.
> The general approach the API takes is to only take actions it's been
> explicitly asked to do, that way we're not hard coding anything that
> causes trouble for consumers and since we need constraints to enable any
> action that gets taken we're less likely to have default behaviour
> causing hardware damage somehow.  If we think we've lost track of the
> reference counting we just scream about it but don't try to take
> corrective action.

So, are you OK with this approach? i.e.:

> ```
>  fn drop(&mut self) {
> 
>    while self.enabled_count > 0 {
> 
>            if let Err(e) = self.disable() {
>              break;
>            }
>        }
>  }
> ```

Where `enable()` increments self.enable_count and `disable()` decrements it.

>>> Perhaps an enable should be an object that's allocated and carried about
>>> by whatever's holding the reference, I don't know if that plays nicely
>>> with how Rust likes to ensure safety with this stuff?
> 
>> As I said, this doesn’t work very well, unless someone corrects my reasoning on a
> 
> I don't think I saw the previous mail?

You didn’t get this?

https://lore.kernel.org/rust-for-linux/Z7aHQBYXZ5jlGRte@xxxxxxxxxxxxxxxxxxxxxxxx/T/#m9348ad4fdc056d7f6d0bfec6529d4c80afdcd335


— Daniel