public inbox for rust-for-linux@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Daniel Almeida <daniel.almeida@collabora.com>
Cc: lgirdwood@gmail.com, sebastian.reichel@collabora.com,
	sjoerd.simons@collabora.co.uk, ojeda@kernel.org,
	alex.gaynor@gmail.com, boqun.feng@gmail.com, gary@garyguo.net,
	bjorn3_gh@protonmail.com, a.hindborg@kernel.org,
	benno.lossin@proton.me, aliceryhl@google.com, tmgross@umich.edu,
	dakr@kernel.org, rust-for-linux@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rust: regulator: add a bare minimum regulator abstraction
Date: Thu, 20 Feb 2025 01:37:04 +0000	[thread overview]
Message-ID: <Z7aHQBYXZ5jlGRte@finisterre.sirena.org.uk> (raw)
In-Reply-To: <5E354BB7-9CD5-4615-8EAF-98B9F498713A@collabora.com>

[-- Attachment #1: Type: text/plain, Size: 2443 bytes --]

On Wed, Feb 19, 2025 at 08:35:47PM -0300, Daniel Almeida wrote:
> > On 19 Feb 2025, at 20:05, Mark Brown <broonie@kernel.org> wrote:

> > If you're going to support both enable and disable (and all things
> > considered you probably should TBH) it would be better to just reference
> > count the enables like the C code does and then complain about it if
> > someone tries to free the regulator object without underwinding their
> > enables, or just possibly just clean them up.  Silently ignoring
> > duplicate enables or overflowing disables doesn't seem like it plays
> > well with the safety goals that Rust has, it's asking for bugs - a big
> > part of the reason the C API does things the way it does is that it will
> > notice if the enables and disables aren't joined up.  You can easily
> > wind up with one part of the code disabling the regulator underneath
> > another part that's still trying to use the hardware and things tend not
> > to go well when that happens.

> I thought about that, something like:

> ```
>   fn drop(&mut self) {
> 

> 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.

> > 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?

> previous email. Having a single type “Regulator” is probably much saner than “Regulator”
> and “EnabledRegulator”.

OK.  It's a bit of a shame that there's not an idiomatic way to help
with the reference counting here.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2025-02-20  1:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-19 16:25 [PATCH] rust: regulator: add a bare minimum regulator abstraction Daniel Almeida
2025-02-19 16:28 ` Alice Ryhl
2025-02-19 17:10   ` Daniel Almeida
2025-02-20 12:09     ` Mark Brown
2025-02-20 13:48       ` Daniel Almeida
2025-02-20 14:14         ` Mark Brown
2025-02-23  7:58     ` Boqun Feng
2025-03-04 15:36     ` Alice Ryhl
2025-02-19 23:05 ` Mark Brown
2025-02-19 23:35   ` Daniel Almeida
2025-02-20  1:37     ` Mark Brown [this message]
2025-02-20  9:42       ` Daniel Almeida
2025-02-20 11:58         ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z7aHQBYXZ5jlGRte@finisterre.sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=gary@garyguo.net \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=sebastian.reichel@collabora.com \
    --cc=sjoerd.simons@collabora.co.uk \
    --cc=tmgross@umich.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox