From nobody Wed Sep 10 01:51:21 2025 Received: from sender4-pp-f112.zoho.com (sender4-pp-f112.zoho.com [136.143.188.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C421F3002C1; Mon, 8 Sep 2025 23:11:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.188.112 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757373093; cv=pass; b=pexgP6Gk3kJ21zOLRlUsbFe1bEvSbS4+JNlpaQ+504O5n7hN3BmFCaL4QUmR4c8byhXMhLG1lz8ECRHsoqh7sKPzk/AZM6lYyy0n/IwZbMx6JUVUA2sq+75GVIbMo6wGx0CvhtMWyCem91Lc48yTFBajXdhx211zvJKscSfvaJg= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757373093; c=relaxed/simple; bh=zFj+R5kTMjlxnrXEQAAUt9knfjTPtUoGGaJzG8DXwYM=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=l5fmFD3cfckwVjZHUE+nlWcTdFtveu8hh7XWM176miTs7Y2EwS9sJJwS4iD5yja6SGC/B2N3Cz7GjFvWu7iOwfzx6XNzQk4K9HNu9f0iZnPI8hjIf5/jMTSWu0m50a+kRWj0PyLe/r1RN5QTOETGXD8dx94DJjpEXcTs+l8bEYg= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (1024-bit key) header.d=collabora.com header.i=daniel.almeida@collabora.com header.b=UeNxlRIN; arc=pass smtp.client-ip=136.143.188.112 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=collabora.com header.i=daniel.almeida@collabora.com header.b="UeNxlRIN" ARC-Seal: i=1; a=rsa-sha256; t=1757373068; cv=none; d=zohomail.com; s=zohoarc; b=h+h//70dPUnXpLLKTaqcH2jhbcykiNLD++xMHKoBmZUzadXZ2OFUEbneR8LsQ9DCq36jZQ0YG20GeshQ0/B9KvYCHiZJVEZc/I2Dxut7Au9ryjsWtEEcLHLZZ/bVJq4NyDreC6YtZKWmdXL6SQAIBZRalqQXmlAQ6LAiRRgTML0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1757373068; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=euykHIurjP2M1+RFqd36amnFZDpKkvGFVANwdFCrkgY=; b=PwEvKmWAxFOAwWa+xZT5rKlKsbpEf872gyJt5c59A80uML55d63BTvP4Hdvh/uKYL4hp/bKZNqIYTUFLbLCneDBK8hoLJrqzbyMGUeIzKabGPHPUGXLD0Hi8XYNNPOtnpeIS4JmHM33W/uDfYjRRlhRcrpb78qmGULADMbqYWrs= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=collabora.com; spf=pass smtp.mailfrom=daniel.almeida@collabora.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1757373068; s=zohomail; d=collabora.com; i=daniel.almeida@collabora.com; h=From:From:Date:Date:Subject:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Message-Id:References:In-Reply-To:To:To:Cc:Cc:Reply-To; bh=euykHIurjP2M1+RFqd36amnFZDpKkvGFVANwdFCrkgY=; b=UeNxlRINvntO2gd64gnP3PwYMTzzmbt+GQZ1YWQV8aZyFnQDDtJcM94Jj5sdG0fP yHEJp+jCsDbW8jJ7eS/W3acQTHkk0SYYMg7Nq6Vuvmj+dwmagCSrnSq5gknBuwqQWcp bhY5BqJKPz46hmh+HSiYcCV0/ouxDA7enDlGlPb0= Received: by mx.zohomail.com with SMTPS id 1757373065445225.16639343576207; Mon, 8 Sep 2025 16:11:05 -0700 (PDT) From: Daniel Almeida Date: Mon, 08 Sep 2025 20:10:27 -0300 Subject: [PATCH v2 1/2] rust: regulator: remove Regulator Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250908-regulator-remove-dynamic-v2-1-e575ae2cde6a@collabora.com> References: <20250908-regulator-remove-dynamic-v2-0-e575ae2cde6a@collabora.com> In-Reply-To: <20250908-regulator-remove-dynamic-v2-0-e575ae2cde6a@collabora.com> To: Liam Girdwood , Mark Brown , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Danilo Krummrich Cc: linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, Daniel Almeida , Alexandre Courbot X-Mailer: b4 0.14.2 X-ZohoMailClient: External After some experimenting and further discussion, it is starting to look like Regulator might be a footgun. It turns out that one can get the same behavior by correctly using just Regulator and Regulator, so there is no need to directly expose the manual refcounting ability of Regulator to clients. Remove it while we do not have any other users. Suggested-by: Danilo Krummrich Reviewed-by: Alice Ryhl Reviewed-by: Danilo Krummrich Reviewed-by: Alexandre Courbot Signed-off-by: Daniel Almeida --- rust/kernel/regulator.rs | 88 +-------------------------------------------= ---- 1 file changed, 1 insertion(+), 87 deletions(-) diff --git a/rust/kernel/regulator.rs b/rust/kernel/regulator.rs index 34bb24ec8d4d436437d92a344c61fc3a46de0b5d..5ea2307f02df4a10c1c8c07b3b8= c134d13519b69 100644 --- a/rust/kernel/regulator.rs +++ b/rust/kernel/regulator.rs @@ -30,7 +30,6 @@ pub trait Sealed {} =20 impl Sealed for super::Enabled {} impl Sealed for super::Disabled {} - impl Sealed for super::Dynamic {} } =20 /// A trait representing the different states a [`Regulator`] can be in. @@ -50,13 +49,6 @@ pub trait RegulatorState: private::Sealed + 'static { /// own an `enable` reference count, but the regulator may still be on. pub struct Disabled; =20 -/// A state that models the C API. The [`Regulator`] can be either enabled= or -/// disabled, and the user is in control of the reference count. This is a= lso -/// the default state. -/// -/// Use [`Regulator::is_enabled`] to check the regulator's current state. -pub struct Dynamic; - impl RegulatorState for Enabled { const DISABLE_ON_DROP: bool =3D true; } @@ -65,14 +57,9 @@ impl RegulatorState for Disabled { const DISABLE_ON_DROP: bool =3D false; } =20 -impl RegulatorState for Dynamic { - const DISABLE_ON_DROP: bool =3D false; -} - /// A trait that abstracts the ability to check if a [`Regulator`] is enab= led. pub trait IsEnabled: RegulatorState {} impl IsEnabled for Disabled {} -impl IsEnabled for Dynamic {} =20 /// An error that can occur when trying to convert a [`Regulator`] between= states. pub struct Error { @@ -183,64 +170,13 @@ pub struct Error { /// } /// ``` /// -/// ## Using [`Regulator`] -/// -/// This example mimics the behavior of the C API, where the user is in -/// control of the enabled reference count. This is useful for drivers that -/// might call enable and disable to manage the `enable` reference count at -/// runtime, perhaps as a result of `open()` and `close()` calls or whatev= er -/// other driver-specific or subsystem-specific hooks. -/// -/// ``` -/// # use kernel::prelude::*; -/// # use kernel::c_str; -/// # use kernel::device::Device; -/// # use kernel::regulator::{Regulator, Dynamic}; -/// struct PrivateData { -/// regulator: Regulator, -/// } -/// -/// // A fictictious probe function that obtains a regulator and sets it u= p. -/// fn probe(dev: &Device) -> Result { -/// // Obtain a reference to a (fictitious) regulator. -/// let regulator =3D Regulator::::get(dev, c_str!("vcc"))?; -/// -/// Ok(PrivateData { regulator }) -/// } -/// -/// // A fictictious function that indicates that the device is going to b= e used. -/// fn open(dev: &Device, data: &PrivateData) -> Result { -/// // Increase the `enabled` reference count. -/// data.regulator.enable()?; -/// -/// Ok(()) -/// } -/// -/// fn close(dev: &Device, data: &PrivateData) -> Result { -/// // Decrease the `enabled` reference count. -/// data.regulator.disable()?; -/// -/// Ok(()) -/// } -/// -/// fn remove(dev: &Device, data: PrivateData) -> Result { -/// // `PrivateData` is dropped here, which will drop the -/// // `Regulator` in turn. -/// // -/// // The reference that was obtained by `regulator_get()` will be -/// // released, but it is up to the user to make sure that the number= of calls -/// // to `enable()` and `disabled()` are balanced before this point. -/// Ok(()) -/// } -/// ``` -/// /// # Invariants /// /// - `inner` is a non-null wrapper over a pointer to a `struct /// regulator` obtained from [`regulator_get()`]. /// /// [`regulator_get()`]: https://docs.kernel.org/driver-api/regulator.html= #c.regulator_get -pub struct Regulator +pub struct Regulator where State: RegulatorState, { @@ -351,28 +287,6 @@ pub fn try_into_disabled(self) -> Result, Error> { } } =20 -impl Regulator { - /// Obtains a [`Regulator`] instance from the system. The current stat= e of - /// the regulator is unknown and it is up to the user to manage the en= abled - /// reference count. - /// - /// This closely mimics the behavior of the C API and can be used to - /// dynamically manage the enabled reference count at runtime. - pub fn get(dev: &Device, name: &CStr) -> Result { - Regulator::get_internal(dev, name) - } - - /// Increases the `enabled` reference count. - pub fn enable(&self) -> Result { - self.enable_internal() - } - - /// Decreases the `enabled` reference count. - pub fn disable(&self) -> Result { - self.disable_internal() - } -} - impl Regulator { /// Checks if the regulator is enabled. pub fn is_enabled(&self) -> bool { --=20 2.51.0 From nobody Wed Sep 10 01:51:21 2025 Received: from sender4-pp-f112.zoho.com (sender4-pp-f112.zoho.com [136.143.188.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D6AE62E92B4; Mon, 8 Sep 2025 23:11:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.188.112 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757373089; cv=pass; b=HdnZpDdxximNucbM9lhijclRVLPdd22zHaNQT+bFTvU5j9u62yiIjqCcjOxXmV01FuLXjaK/2h4/OqGaTTgOPVy3+85b6XQsbbxT/1D7LWFRIpVFSzqvzd2iCyEY/S2SaEd3VJOu8h2cr2+JQbbzAUj/Oa9M0qN7SXnWZawVsa8= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757373089; c=relaxed/simple; bh=4P3O0JRDIogtTwLhR0MOXt5MOdne0MxiEfPUX45wK8A=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=SoXTpwMx+ii48wsoAeIDuvx3kwK2mMY8e7xCm+W5vRqykn8XNHaGOOEZvaXN5szDXZHmHsHMpWt+m7UUSPqpTH/QEYKK6JKAYklZbXk1moVrrWLAWA1XoAYpZVLCQ+ZLC+MTV5ii3CQrzwKYd1iPuW0M+vQ3n9UlSV31T4hwGFg= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (1024-bit key) header.d=collabora.com header.i=daniel.almeida@collabora.com header.b=RY+kqgKB; arc=pass smtp.client-ip=136.143.188.112 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=collabora.com header.i=daniel.almeida@collabora.com header.b="RY+kqgKB" ARC-Seal: i=1; a=rsa-sha256; t=1757373072; cv=none; d=zohomail.com; s=zohoarc; b=B2YfTwVJ/Sm3kNvDmkHGHyUJzOETFJYTvywSs4B0lYw27ZxNT10erh7dXvy1dYIbNUuoOM7A3zpmk0wHT7jGGEU4OmwRC0gCMC1wudGYx+8v56Fp+TugboqLrFV1pnQFrZ+ieAL5U1fwOZZ/Ninzt871vdLwi1QlL8Kt5sEk1t4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1757373072; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=mZds/sNDo5RWYI6EE4Y1XLgDCxsgfuOfTXpd1zdFTJ8=; b=LrKlQZW33/mneUr86crIQaq3+Pc30duGLY+b4Wx3KX0H11IILscg3pMxbzou1kt4FHUyh509hftqaaCdWiKtCdF2ptunYbYq1JCcthNLx3XJoSM5tn+LUXalfxFhkh4G8TCcHGwCV9ksgHAAXvyFvx2frWerGoNB4aZsKfWi21o= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=collabora.com; spf=pass smtp.mailfrom=daniel.almeida@collabora.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1757373072; s=zohomail; d=collabora.com; i=daniel.almeida@collabora.com; h=From:From:Date:Date:Subject:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Message-Id:References:In-Reply-To:To:To:Cc:Cc:Reply-To; bh=mZds/sNDo5RWYI6EE4Y1XLgDCxsgfuOfTXpd1zdFTJ8=; b=RY+kqgKBszygPjbVeDZDL92r8W2+ViEkb/sUYTZEJDDyiaFzRUqOAWB+KHr2J4H9 tqaWIRHYYaVqN+5TLXFOzclH2QZHL0W4EpUcHzEulwF9Q8l1rwgTP36Dx6NVxis+Nhf WJY3zqcnpmdv8FZ1sZAAlj7ujCcQ9s0jlXzW3xIM= Received: by mx.zohomail.com with SMTPS id 1757373069537564.0170375580834; Mon, 8 Sep 2025 16:11:09 -0700 (PDT) From: Daniel Almeida Date: Mon, 08 Sep 2025 20:10:28 -0300 Subject: [PATCH v2 2/2] rust: regulator: add devm_enable and devm_enable_optional Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250908-regulator-remove-dynamic-v2-2-e575ae2cde6a@collabora.com> References: <20250908-regulator-remove-dynamic-v2-0-e575ae2cde6a@collabora.com> In-Reply-To: <20250908-regulator-remove-dynamic-v2-0-e575ae2cde6a@collabora.com> To: Liam Girdwood , Mark Brown , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Danilo Krummrich Cc: linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, Daniel Almeida X-Mailer: b4 0.14.2 X-ZohoMailClient: External A lot of drivers only care about enabling the regulator for as long as the underlying Device is bound. This can be easily observed due to the extensive use of `devm_regulator_get_enable` and `devm_regulator_get_enable_optional` throughout the kernel. Therefore, make this helper available in Rust. Also add an example noting how it should be the default API unless the driver needs more fine-grained control over the regulator. Suggested-by: Danilo Krummrich Signed-off-by: Daniel Almeida Reviewed-by: Alexandre Courbot Reviewed-by: Danilo Krummrich --- rust/helpers/regulator.c | 10 +++++++++ rust/kernel/regulator.rs | 58 ++++++++++++++++++++++++++++++++++++++++++++= +++- 2 files changed, 67 insertions(+), 1 deletion(-) diff --git a/rust/helpers/regulator.c b/rust/helpers/regulator.c index cd8b7ba648ee33dd14326c9242fb6c96ab8e32a7..11bc332443bd064f4b5afd350ff= c045badff9076 100644 --- a/rust/helpers/regulator.c +++ b/rust/helpers/regulator.c @@ -40,4 +40,14 @@ int rust_helper_regulator_is_enabled(struct regulator *r= egulator) return regulator_is_enabled(regulator); } =20 +int rust_helper_devm_regulator_get_enable(struct device *dev, const char *= id) +{ + return devm_regulator_get_enable(dev, id); +} + +int rust_helper_devm_regulator_get_enable_optional(struct device *dev, con= st char *id) +{ + return devm_regulator_get_enable_optional(dev, id); +} + #endif diff --git a/rust/kernel/regulator.rs b/rust/kernel/regulator.rs index 5ea2307f02df4a10c1c8c07b3b8c134d13519b69..d1c8c7308cdd9ae398883ddac52= ff093b97764cd 100644 --- a/rust/kernel/regulator.rs +++ b/rust/kernel/regulator.rs @@ -18,7 +18,7 @@ =20 use crate::{ bindings, - device::Device, + device::{Bound, Device}, error::{from_err_ptr, to_result, Result}, prelude::*, }; @@ -70,6 +70,39 @@ pub struct Error { pub regulator: Regulator, } =20 +/// Enables a regulator whose lifetime is tied to the lifetime of `dev` th= rough +/// [`devres`]. +/// +/// This calls `regulator_disable()` and `regulator_put()` automatically on +/// driver detach. +/// +/// This API is identical to `devm_regulator_get_enable()`, and should be +/// preferred if the caller only cares about the regulator being on. +/// +/// [`devres`]: https://docs.kernel.org/driver-api/driver-model/devres.html +pub fn devm_enable(dev: &Device, name: &CStr) -> Result { + // SAFETY: `dev` is a valid and bound device, while `name` is a valid C + // string. + to_result(unsafe { bindings::devm_regulator_get_enable(dev.as_raw(), n= ame.as_ptr()) }) +} + +/// Same as [`devm_enable`], but calls `devm_regulator_get_enable_optional` +/// instead. +/// +/// This enables a regulator whose lifetime is tied to the lifetime of `de= v` +/// through [`devres`], but does not print a message nor provides a dummy = if the +/// regulator is not found. +/// +/// This calls `regulator_disable()` and `regulator_put()` automatically on +/// driver detach. +/// +/// [`devres`]: https://docs.kernel.org/driver-api/driver-model/devres.html +pub fn devm_enable_optional(dev: &Device, name: &CStr) -> Result { + // SAFETY: `dev` is a valid and bound device, while `name` is a valid C + // string. + to_result(unsafe { bindings::devm_regulator_get_enable_optional(dev.as= _raw(), name.as_ptr()) }) +} + /// A `struct regulator` abstraction. /// /// # Examples @@ -146,6 +179,29 @@ pub struct Error { /// } /// ``` /// +/// If a driver only cares about the regulator being on for as long it is = bound +/// to a device, then it should use [`devm_enable`] or [`devm_enable_optio= nal`]. +/// This should be the default use-case unless they need more fine-grained +/// control over the regulator's state. +/// +/// [`devm_enable`]: crate::regulator::devm_enable +/// [`devm_optional`]: crate::regulator::devm_enable_optional +/// +/// ``` +/// # use kernel::prelude::*; +/// # use kernel::c_str; +/// # use kernel::device::{Bound, Device}; +/// # use kernel::regulator; +/// fn enable(dev: &Device) -> Result { +/// // Obtain a reference to a (fictitious) regulator and enable it. T= his +/// // call only returns whether the operation succeeded. +/// regulator::devm_enable(dev, c_str!("vcc"))?; +/// +/// // The regulator will be disabled and put when `dev` is unbound. +/// Ok(()) +/// } +/// ``` +/// /// ## Disabling a regulator /// /// ``` --=20 2.51.0