[PATCH 0/2] rust: regulator: relax a few constraints on Regulator<T>

[PATCH 0/2] rust: regulator: relax a few constraints on Regulator<T>

[Daniel Almeida]

This series implement two related changes to address a bit of an oversight
on my end on the initial patch for the Regulator abstraction. Note that
this is not a fix, as it just relaxes the constraints on the previous code
as it is safe to do so.

Patch 1 removes some needless &mut self for functions that already provide
their own locking on the C side.

Patch 2 implements Send and Sync. In particular, there is no reason for
Regulator<T> not to be Send, and as discussed above, it is naturally Sync.

This is based on linux-next for now, I am waiting for 6.17-rc1 to be out in
order to rebase.

---
Daniel Almeida (2):
      rust: regulator: remove needless &mut from member functions
      rust: regulator: implement Send and Sync for Regulator<T>

 rust/kernel/regulator.rs | 26 +++++++++++++++++---------
 1 file changed, 17 insertions(+), 9 deletions(-)
---
base-commit: 54efec8782214652b331c50646013f8526570e8d
change-id: 20250729-regulator-send-sync-94d4a7a61eff

Best regards,
-- 
Daniel Almeida <daniel.almeida@collabora.com>

[PATCH 1/2] rust: regulator: remove needless &mut from member functions

[Daniel Almeida]

Regulator functions like "regulator_enable()" and "regulator_disable()"
already provide their own locking through "regulator_lock_dependent()", so
we can safely call the Rust API with a shared reference.

This was already the case with Regulator::set_voltage() on the Rust side,
but it was forgotten for Regulator::enable() and Regulator::disable().

Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
---
 rust/kernel/regulator.rs | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/rust/kernel/regulator.rs b/rust/kernel/regulator.rs
index 65f3a125348f2d821898188b4ac6a0b593f18bf2..d56aa229e838c45258a27cea742a693dd71e8e40 100644
--- a/rust/kernel/regulator.rs
+++ b/rust/kernel/regulator.rs
@@ -203,20 +203,20 @@ pub struct Error<State: RegulatorState> {
 /// // A fictictious probe function that obtains a regulator and sets it up.
 /// fn probe(dev: &Device) -> Result<PrivateData> {
 ///     // Obtain a reference to a (fictitious) regulator.
-///     let mut regulator = Regulator::<Dynamic>::get(dev, c_str!("vcc"))?;
+///     let regulator = Regulator::<Dynamic>::get(dev, c_str!("vcc"))?;
 ///
 ///     Ok(PrivateData { regulator })
 /// }
 ///
 /// // A fictictious function that indicates that the device is going to be used.
-/// fn open(dev: &Device, data: &mut PrivateData) -> Result {
+/// fn open(dev: &Device, data: &PrivateData) -> Result {
 ///     // Increase the `enabled` reference count.
 ///     data.regulator.enable()?;
 ///
 ///     Ok(())
 /// }
 ///
-/// fn close(dev: &Device, data: &mut PrivateData) -> Result {
+/// fn close(dev: &Device, data: &PrivateData) -> Result {
 ///     // Decrease the `enabled` reference count.
 ///     data.regulator.disable()?;
 ///
@@ -289,12 +289,12 @@ fn get_internal(dev: &Device, name: &CStr) -> Result<Regulator<T>> {
         })
     }
 
-    fn enable_internal(&mut self) -> Result {
+    fn enable_internal(&self) -> Result {
         // SAFETY: Safe as per the type invariants of `Regulator`.
         to_result(unsafe { bindings::regulator_enable(self.inner.as_ptr()) })
     }
 
-    fn disable_internal(&mut self) -> Result {
+    fn disable_internal(&self) -> Result {
         // SAFETY: Safe as per the type invariants of `Regulator`.
         to_result(unsafe { bindings::regulator_disable(self.inner.as_ptr()) })
     }
@@ -310,7 +310,7 @@ pub fn get(dev: &Device, name: &CStr) -> Result<Self> {
     pub fn try_into_enabled(self) -> Result<Regulator<Enabled>, Error<Disabled>> {
         // We will be transferring the ownership of our `regulator_get()` count to
         // `Regulator<Enabled>`.
-        let mut regulator = ManuallyDrop::new(self);
+        let regulator = ManuallyDrop::new(self);
 
         regulator
             .enable_internal()
@@ -339,7 +339,7 @@ pub fn get(dev: &Device, name: &CStr) -> Result<Self> {
     pub fn try_into_disabled(self) -> Result<Regulator<Disabled>, Error<Enabled>> {
         // We will be transferring the ownership of our `regulator_get()` count
         // to `Regulator<Disabled>`.
-        let mut regulator = ManuallyDrop::new(self);
+        let regulator = ManuallyDrop::new(self);
 
         regulator
             .disable_internal()
@@ -366,12 +366,12 @@ pub fn get(dev: &Device, name: &CStr) -> Result<Self> {
     }
 
     /// Increases the `enabled` reference count.
-    pub fn enable(&mut self) -> Result {
+    pub fn enable(&self) -> Result {
         self.enable_internal()
     }
 
     /// Decreases the `enabled` reference count.
-    pub fn disable(&mut self) -> Result {
+    pub fn disable(&self) -> Result {
         self.disable_internal()
     }
 }

-- 
2.50.0

[PATCH 2/2] rust: regulator: implement Send and Sync for Regulator<T>

[Daniel Almeida]

Sending a &Regulator<T> to another thread is safe, as the regulator core
will properly handle the locking for us. Additionally, there are no
restrictions that prevents sending a Regulator<T> to another thread.

Given these two facts, implement Send and Sync.

Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
---
 rust/kernel/regulator.rs | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/rust/kernel/regulator.rs b/rust/kernel/regulator.rs
index d56aa229e838c45258a27cea742a693dd71e8e40..704147e18bfc9c993a00f7a187105360ad1d4956 100644
--- a/rust/kernel/regulator.rs
+++ b/rust/kernel/regulator.rs
@@ -398,6 +398,14 @@ fn drop(&mut self) {
     }
 }
 
+// SAFETY: It is safe to send a `Regulator<T>` across threads. In particular, a
+// Regulator<T> can be dropped from any thread.
+unsafe impl<T: RegulatorState> Send for Regulator<T> {}
+
+// SAFETY: It is safe to send a &Regulator<T> across threads because the C side
+// handles its own locking.
+unsafe impl<T: RegulatorState> Sync for Regulator<T> {}
+
 /// A voltage.
 ///
 /// This type represents a voltage value in microvolts.

-- 
2.50.0

Re: [PATCH 0/2] rust: regulator: relax a few constraints on Regulator<T>

[Alice Ryhl]

On Tue, Jul 29, 2025 at 02:31:39PM -0300, Daniel Almeida wrote:
> This series implement two related changes to address a bit of an oversight
> on my end on the initial patch for the Regulator abstraction. Note that
> this is not a fix, as it just relaxes the constraints on the previous code
> as it is safe to do so.
> 
> Patch 1 removes some needless &mut self for functions that already provide
> their own locking on the C side.
> 
> Patch 2 implements Send and Sync. In particular, there is no reason for
> Regulator<T> not to be Send, and as discussed above, it is naturally Sync.
> 
> This is based on linux-next for now, I am waiting for 6.17-rc1 to be out in
> order to rebase.
> 
> ---
> Daniel Almeida (2):
>       rust: regulator: remove needless &mut from member functions
>       rust: regulator: implement Send and Sync for Regulator<T>
> 
>  rust/kernel/regulator.rs | 26 +++++++++++++++++---------
>  1 file changed, 17 insertions(+), 9 deletions(-)

Reviewed-by: Alice Ryhl <aliceryhl@google.com>

Re: [PATCH 0/2] rust: regulator: relax a few constraints on Regulator<T>

[Alexandre Courbot]

On Wed Jul 30, 2025 at 2:31 AM JST, Daniel Almeida wrote:
> This series implement two related changes to address a bit of an oversight
> on my end on the initial patch for the Regulator abstraction. Note that
> this is not a fix, as it just relaxes the constraints on the previous code
> as it is safe to do so.
>
> Patch 1 removes some needless &mut self for functions that already provide
> their own locking on the C side.
>
> Patch 2 implements Send and Sync. In particular, there is no reason for
> Regulator<T> not to be Send, and as discussed above, it is naturally Sync.
>
> This is based on linux-next for now, I am waiting for 6.17-rc1 to be out in
> order to rebase.

FWIW,

Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>

Re: [PATCH 0/2] rust: regulator: relax a few constraints on Regulator<T>

[Mark Brown]

On Tue, 29 Jul 2025 14:31:39 -0300, Daniel Almeida wrote:
> This series implement two related changes to address a bit of an oversight
> on my end on the initial patch for the Regulator abstraction. Note that
> this is not a fix, as it just relaxes the constraints on the previous code
> as it is safe to do so.
> 
> Patch 1 removes some needless &mut self for functions that already provide
> their own locking on the C side.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next

Thanks!

[1/2] rust: regulator: remove needless &mut from member functions
      commit: f7fbf3091f4cc4133574852f655593e1613d1af0
[2/2] rust: regulator: implement Send and Sync for Regulator<T>
      commit: 9a200cbdb54349909a42b45379e792e4b39dd223

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark