[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aCTAFY5USLIchVWL@finisterre.sirena.org.uk>
Date: Wed, 14 May 2025 18:08:53 +0200
From: Mark Brown <broonie@...nel.org>
To: Benno Lossin <lossin@...nel.org>
Cc: Daniel Almeida <daniel.almeida@...labora.com>,
Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>,
Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <benno.lossin@...ton.me>,
Andreas Hindborg <a.hindborg@...nel.org>,
Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
Danilo Krummrich <dakr@...nel.org>,
Boris Brezillon <boris.brezillon@...labora.com>,
Sebastian Reichel <sebastian.reichel@...labora.com>,
Liam Girdwood <lgirdwood@...il.com>, linux-kernel@...r.kernel.org,
rust-for-linux@...r.kernel.org
Subject: Re: [PATCH v3] rust: regulator: add a bare minimum regulator
abstraction
On Wed, May 14, 2025 at 06:05:11PM +0200, Benno Lossin wrote:
> Gotcha. So calling `regulator_enable` twice on the same regulator is
> fine?
Yes, absolutely. You might potentially see this with a multi-function
device where multiple functions on the device need the same supply in
order to help reduce coordination requirements.
> If that is the case -- and after re-reading the functions exposed on
> both types `EnabledRegulator` and `Regulator` -- I am confused why we
> even need two different type states? Both expose the same functions
> (except `enable` and `disable`) and I don't otherwise see the purpose of
> having two types.
IIUC the point is to allow Rust's type system to keep track of the
reference on the regulator, otherwise the user code has to keep track of
the number of enables it's done like it currently does in C code.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists