From: Alice Ryhl <aliceryhl@google.com>
To: Daniel Almeida <daniel.almeida@collabora.com>
Cc: lgirdwood@gmail.com, broonie@kernel.org,
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,
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: Tue, 4 Mar 2025 15:36:18 +0000 [thread overview]
Message-ID: <Z8cd8taTQbIJOdsp@google.com> (raw)
In-Reply-To: <E24A1EA3-DC87-4A33-AD93-1E3B307942E8@collabora.com>
On Wed, Feb 19, 2025 at 02:10:24PM -0300, Daniel Almeida wrote:
> Hi Alice,
> > On 19 Feb 2025, at 13:28, Alice Ryhl <aliceryhl@google.com> wrote:
> >
> > I wonder if enabled vs disabled should be two different types?
> >
> > Alice
> I thought about having two types too, but I think it complicates the
> design.
> ```
> let foo: Regulator = Regulator::get(/*…*/)?;
> let foo_enabled: EnabledRegulator = foo.enable()?:
> ```
> Let’s first agree that `Regulator::drop` is the right place to have
> `regulator_put`, since
> `Regulator::get()` acquired the reference in the first place.
> This means that now, `EnabledRegulator` has to depend on `Regulator`
> somehow to ensure
> a proper drop order. Otherwise you might have an enabled regulator for
> which you don’t own
> the refcount. Furthermore, if Regulator drops while EnabledRegulator is
> alive, you get a splat.
> In a driver, you now have to store both Regulator - for the refcount -
> and EnabledRegulator
> - as a way to tell the system you need that regulator to be active.
> If EnabledRegulator is a guard type, this doesn’t work, as it creates a
> self-reference - on top
> of being extremely clunky.
You definitely do not want a guard type.
> You can then have EnabledRegulator consume Regulator, but this assumes
> that the regulator
> will be on all the time, which is not true. A simple pattern of
> ```
> regulator_enable()
> do_fancy_stuff()
> regulator_disable()
> ```
> Becomes a pain when one type consumes the other:
> ```
> self.my_regulator.enable() // error, moves out of `&self`
> ```
> I am sure we can find ways around that, but a simple `bool` here seems to
> fix this problem.
What I meant to suggest is two types:
pub struct DisabledRegulator {
inner: NonNull<bindings::regulator>,
}
pub struct EnabledRegulator {
inner: DisabledRegulator,
}
impl Drop for EnabledRegulator {
fn drop(&mut self) {
unsafe { bindings::regulator_disable(self.inner.as_ptr()) };
// Destructor of DisabledRegulator runs now since it's a
// field of EnabledRegulator.
}
}
impl Drop for DisabledRegulator {
fn drop(&mut self) {
unsafe { bindings::regulator_put(self.inner.as_ptr()) };
}
}
This gives the right behavior. For devices where the regulator is always
going to be enabled, you just store an EnabledRegulator. If you need to
dynamically switch between them, you store an enum like Boqun suggested.
Alice
next prev parent reply other threads:[~2025-03-04 15:36 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 [this message]
2025-02-19 23:05 ` Mark Brown
2025-02-19 23:35 ` Daniel Almeida
2025-02-20 1:37 ` Mark Brown
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=Z8cd8taTQbIJOdsp@google.com \
--to=aliceryhl@google.com \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=broonie@kernel.org \
--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