Skip to content

Commit b87ecbc

Browse files
danielalmeida-collaborabroonie
authored andcommitted
rust: regulator: remove Regulator<Dynamic>
After some experimenting and further discussion, it is starting to look like Regulator<Dynamic> might be a footgun. It turns out that one can get the same behavior by correctly using just Regulator<Enabled> and Regulator<Disabled>, so there is no need to directly expose the manual refcounting ability of Regulator<Dynamic> to clients. Remove it while we do not have any other users. Suggested-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://patch.msgid.link/20250910-regulator-remove-dynamic-v3-1-07af4dfa97cc@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
1 parent 5bad164 commit b87ecbc

1 file changed

Lines changed: 1 addition & 87 deletions

File tree

rust/kernel/regulator.rs

Lines changed: 1 addition & 87 deletions
Original file line numberDiff line numberDiff line change
@@ -30,7 +30,6 @@ mod private {
3030

3131
impl Sealed for super::Enabled {}
3232
impl Sealed for super::Disabled {}
33-
impl Sealed for super::Dynamic {}
3433
}
3534

3635
/// A trait representing the different states a [`Regulator`] can be in.
@@ -50,13 +49,6 @@ pub struct Enabled;
5049
/// own an `enable` reference count, but the regulator may still be on.
5150
pub struct Disabled;
5251

53-
/// A state that models the C API. The [`Regulator`] can be either enabled or
54-
/// disabled, and the user is in control of the reference count. This is also
55-
/// the default state.
56-
///
57-
/// Use [`Regulator::is_enabled`] to check the regulator's current state.
58-
pub struct Dynamic;
59-
6052
impl RegulatorState for Enabled {
6153
const DISABLE_ON_DROP: bool = true;
6254
}
@@ -65,14 +57,9 @@ impl RegulatorState for Disabled {
6557
const DISABLE_ON_DROP: bool = false;
6658
}
6759

68-
impl RegulatorState for Dynamic {
69-
const DISABLE_ON_DROP: bool = false;
70-
}
71-
7260
/// A trait that abstracts the ability to check if a [`Regulator`] is enabled.
7361
pub trait IsEnabled: RegulatorState {}
7462
impl IsEnabled for Disabled {}
75-
impl IsEnabled for Dynamic {}
7663

7764
/// An error that can occur when trying to convert a [`Regulator`] between states.
7865
pub struct Error<State: RegulatorState> {
@@ -183,64 +170,13 @@ pub struct Error<State: RegulatorState> {
183170
/// }
184171
/// ```
185172
///
186-
/// ## Using [`Regulator<Dynamic>`]
187-
///
188-
/// This example mimics the behavior of the C API, where the user is in
189-
/// control of the enabled reference count. This is useful for drivers that
190-
/// might call enable and disable to manage the `enable` reference count at
191-
/// runtime, perhaps as a result of `open()` and `close()` calls or whatever
192-
/// other driver-specific or subsystem-specific hooks.
193-
///
194-
/// ```
195-
/// # use kernel::prelude::*;
196-
/// # use kernel::c_str;
197-
/// # use kernel::device::Device;
198-
/// # use kernel::regulator::{Regulator, Dynamic};
199-
/// struct PrivateData {
200-
/// regulator: Regulator<Dynamic>,
201-
/// }
202-
///
203-
/// // A fictictious probe function that obtains a regulator and sets it up.
204-
/// fn probe(dev: &Device) -> Result<PrivateData> {
205-
/// // Obtain a reference to a (fictitious) regulator.
206-
/// let regulator = Regulator::<Dynamic>::get(dev, c_str!("vcc"))?;
207-
///
208-
/// Ok(PrivateData { regulator })
209-
/// }
210-
///
211-
/// // A fictictious function that indicates that the device is going to be used.
212-
/// fn open(dev: &Device, data: &PrivateData) -> Result {
213-
/// // Increase the `enabled` reference count.
214-
/// data.regulator.enable()?;
215-
///
216-
/// Ok(())
217-
/// }
218-
///
219-
/// fn close(dev: &Device, data: &PrivateData) -> Result {
220-
/// // Decrease the `enabled` reference count.
221-
/// data.regulator.disable()?;
222-
///
223-
/// Ok(())
224-
/// }
225-
///
226-
/// fn remove(dev: &Device, data: PrivateData) -> Result {
227-
/// // `PrivateData` is dropped here, which will drop the
228-
/// // `Regulator<Dynamic>` in turn.
229-
/// //
230-
/// // The reference that was obtained by `regulator_get()` will be
231-
/// // released, but it is up to the user to make sure that the number of calls
232-
/// // to `enable()` and `disabled()` are balanced before this point.
233-
/// Ok(())
234-
/// }
235-
/// ```
236-
///
237173
/// # Invariants
238174
///
239175
/// - `inner` is a non-null wrapper over a pointer to a `struct
240176
/// regulator` obtained from [`regulator_get()`].
241177
///
242178
/// [`regulator_get()`]: https://docs.kernel.org/driver-api/regulator.html#c.regulator_get
243-
pub struct Regulator<State = Dynamic>
179+
pub struct Regulator<State>
244180
where
245181
State: RegulatorState,
246182
{
@@ -351,28 +287,6 @@ impl Regulator<Enabled> {
351287
}
352288
}
353289

354-
impl Regulator<Dynamic> {
355-
/// Obtains a [`Regulator`] instance from the system. The current state of
356-
/// the regulator is unknown and it is up to the user to manage the enabled
357-
/// reference count.
358-
///
359-
/// This closely mimics the behavior of the C API and can be used to
360-
/// dynamically manage the enabled reference count at runtime.
361-
pub fn get(dev: &Device, name: &CStr) -> Result<Self> {
362-
Regulator::get_internal(dev, name)
363-
}
364-
365-
/// Increases the `enabled` reference count.
366-
pub fn enable(&self) -> Result {
367-
self.enable_internal()
368-
}
369-
370-
/// Decreases the `enabled` reference count.
371-
pub fn disable(&self) -> Result {
372-
self.disable_internal()
373-
}
374-
}
375-
376290
impl<T: IsEnabled> Regulator<T> {
377291
/// Checks if the regulator is enabled.
378292
pub fn is_enabled(&self) -> bool {

0 commit comments

Comments
 (0)