All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boqun Feng <boqun.feng@gmail.com>
To: Daniel Almeida <daniel.almeida@collabora.com>
Cc: Alice Ryhl <aliceryhl@google.com>,
	lgirdwood@gmail.com, broonie@kernel.org,
	sebastian.reichel@collabora.com, sjoerd.simons@collabora.co.uk,
	ojeda@kernel.org, alex.gaynor@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: Sat, 22 Feb 2025 23:58:03 -0800	[thread overview]
Message-ID: <Z7rVC-V-4QxGwMAy@Mac.home> (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 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`
> ``` 

You can introduce an enum:

	pub enum WaitForAGoodName {
		Regulator(Regulator),
		Enabled(EnableRegulator),
	}

for this case, and `my_regulator` is this type (or you can use
`kernel::types::Either`). The eventual code generation will probably use
a byte flag somewhere, but it only needs the byte flag for such a case.
In other cases, for example, the driver knows the regulator is always
enabled, you save the byte flag and the complexity of impl Regulator.

Regards,
Boqun

> 
> I am sure we can find ways around that, but a simple `bool` here seems to fix this problem.
> 
> Now you only have to store `Regulator`. If you need another part of your code to also keep
> the regulator enabled, you store a `Regulator` there and enable that as well. All calls to
> enable and disable will be automatically balanced for all instances of `Regulator` by
> virtue of the `enabled` bool as well.
> 
> - Daniel
> 

  parent reply	other threads:[~2025-02-23  7:58 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 [this message]
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
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=Z7rVC-V-4QxGwMAy@Mac.home \
    --to=boqun.feng@gmail.com \
    --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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.