[PATCH v1 0/2] userspace-consumer: adding is_shared flag

[PATCH v1 0/2] userspace-consumer: adding is_shared flag

[Daniel Okazaki]

Hi,

Currently this userspace regulator driver requires exclusive control
of the regulator to operate. This patch adds an optional flag to
remove that constraint, and allow the regulator to be shared by other
modules. This allows for userspace to share control over a regulator
with kernel space.

There is a boot time behavior change when this flag is set.
Before, if the gpio was enabled before this driver probes, it would
stay enabled. This change allows regulator_init_complete_work
to disable the regulator on completion.

The regulator state reported by this driver is changed from the
absolute state to the local state of the driver. This abstracts
away the regulator state of other consumers from this driver.

Daniel Okazaki (2):
  regulator: Add regulator-output is_shared property
  regulator: userspace-consumer add shared supply functionality

 .../bindings/regulator/regulator-output.yaml  |  5 +++
 drivers/regulator/userspace-consumer.c        | 39 ++++++++++++-------
 2 files changed, 29 insertions(+), 15 deletions(-)

-- 
2.49.0.1204.g71687c7c1d-goog

[PATCH v1 1/2] regulator: Add regulator-output is_shared property

[Daniel Okazaki]

The existence of this flag removes the exclusive requirement
for the supply.

Signed-off-by: Daniel Okazaki <dtokazaki@google.com>
---
 .../devicetree/bindings/regulator/regulator-output.yaml      | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/regulator/regulator-output.yaml b/Documentation/devicetree/bindings/regulator/regulator-output.yaml
index 078b37a1a71a..9bc4c68b9978 100644
--- a/Documentation/devicetree/bindings/regulator/regulator-output.yaml
+++ b/Documentation/devicetree/bindings/regulator/regulator-output.yaml
@@ -25,6 +25,11 @@ properties:
     description:
       Phandle of the regulator supplying the output.
 
+  is_shared:
+    description:
+      Indicates that the regulator is shared and should not take exclusive control.
+    type: boolean
+
 required:
   - compatible
   - vout-supply
-- 
2.49.0.1204.g71687c7c1d-goog

[PATCH v1 2/2] regulator: userspace-consumer add shared supply functionality

[Daniel Okazaki]

Add is_shared flag to indictae that regulator control is not
exclusive to this module.

Signed-off-by: Daniel Okazaki <dtokazaki@google.com>
---
 drivers/regulator/userspace-consumer.c | 39 ++++++++++++++++----------
 1 file changed, 24 insertions(+), 15 deletions(-)

diff --git a/drivers/regulator/userspace-consumer.c b/drivers/regulator/userspace-consumer.c
index 72bb5ffb49a8..4ab316d528fb 100644
--- a/drivers/regulator/userspace-consumer.c
+++ b/drivers/regulator/userspace-consumer.c
@@ -26,6 +26,7 @@ struct userspace_consumer_data {
 	struct mutex lock;
 	bool enabled;
 	bool no_autoswitch;
+	bool is_shared;
 
 	int num_supplies;
 	struct regulator_bulk_data *supplies;
@@ -156,8 +157,14 @@ static int regulator_userspace_consumer_probe(struct platform_device *pdev)
 
 	mutex_init(&drvdata->lock);
 
-	ret = devm_regulator_bulk_get_exclusive(&pdev->dev, drvdata->num_supplies,
-						drvdata->supplies);
+	drvdata->is_shared = of_property_read_bool(pdev->dev.of_node, "is_shared");
+	if (drvdata->is_shared) {
+		ret = devm_regulator_bulk_get(&pdev->dev, drvdata->num_supplies,
+					      drvdata->supplies);
+	} else {
+		ret = devm_regulator_bulk_get_exclusive(&pdev->dev, drvdata->num_supplies,
+							drvdata->supplies);
+	}
 	if (ret)
 		return dev_err_probe(&pdev->dev, ret, "Failed to get supplies\n");
 
@@ -167,22 +174,24 @@ static int regulator_userspace_consumer_probe(struct platform_device *pdev)
 	if (ret != 0)
 		return ret;
 
-	if (pdata->init_on && !pdata->no_autoswitch) {
-		ret = regulator_bulk_enable(drvdata->num_supplies,
-					    drvdata->supplies);
-		if (ret) {
-			dev_err(&pdev->dev,
-				"Failed to set initial state: %d\n", ret);
-			goto err_enable;
+	if (!drvdata->is_shared) {
+		if (pdata->init_on && !pdata->no_autoswitch) {
+			ret = regulator_bulk_enable(drvdata->num_supplies,
+						    drvdata->supplies);
+			if (ret) {
+				dev_err(&pdev->dev,
+					"Failed to set initial state: %d\n", ret);
+				goto err_enable;
+			}
 		}
-	}
 
-	ret = regulator_is_enabled(pdata->supplies[0].consumer);
-	if (ret < 0) {
-		dev_err(&pdev->dev, "Failed to get regulator status\n");
-		goto err_enable;
+		ret = regulator_is_enabled(pdata->supplies[0].consumer);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "Failed to get regulator status\n");
+			goto err_enable;
+		}
+		drvdata->enabled = !!ret;
 	}
-	drvdata->enabled = !!ret;
 
 	return 0;
 
-- 
2.49.0.1204.g71687c7c1d-goog

Re: [PATCH v1 0/2] userspace-consumer: adding is_shared flag

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

On Wed, May 28, 2025 at 05:44:23PM +0000, Daniel Okazaki wrote:

> Currently this userspace regulator driver requires exclusive control
> of the regulator to operate. This patch adds an optional flag to
> remove that constraint, and allow the regulator to be shared by other
> modules. This allows for userspace to share control over a regulator
> with kernel space.

What is the use case here?  This is a debug tool intended mainly for
when you're developing a regulator driver and have something like a
development board with no consumers at all.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v1 0/2] userspace-consumer: adding is_shared flag

[Daniel Okazaki]

> What is the use case here?
The request is for a regulator to be controlled by two different
subsystems. One is a userspace HAL and the other is
a kernel driver.

Alternatively I could expose sysfs nodes in the kernel driver
for the HAL layer to connect to, but it would add coupling
between userspace and the kernel driver that might not
otherwise be necessary. The userspace regulator driver
would add some abstraction between the actual hardware
and the sysfs interface.


On Wed, May 28, 2025 at 11:16 AM Mark Brown <broonie@kernel.org> wrote:
>
> On Wed, May 28, 2025 at 05:44:23PM +0000, Daniel Okazaki wrote:
>
> > Currently this userspace regulator driver requires exclusive control
> > of the regulator to operate. This patch adds an optional flag to
> > remove that constraint, and allow the regulator to be shared by other
> > modules. This allows for userspace to share control over a regulator
> > with kernel space.
>
> What is the use case here?  This is a debug tool intended mainly for
> when you're developing a regulator driver and have something like a
> development board with no consumers at all.

Re: [PATCH v1 0/2] userspace-consumer: adding is_shared flag

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]

On Wed, May 28, 2025 at 11:32:19AM -0700, Daniel Okazaki wrote:

Please don't top post, reply in line with needed context.  This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.

> > What is the use case here?

> The request is for a regulator to be controlled by two different
> subsystems. One is a userspace HAL and the other is
> a kernel driver.

> Alternatively I could expose sysfs nodes in the kernel driver
> for the HAL layer to connect to, but it would add coupling
> between userspace and the kernel driver that might not
> otherwise be necessary. The userspace regulator driver
> would add some abstraction between the actual hardware
> and the sysfs interface.

Presumably the HAL is working through some driver since otherwise it
would have no access to the hardware, that driver should extend it's
interface to cover managing the supplies.  This coupling seems
desirable, we end up with one kernel thing which knows about the whole
device and the firmware description is not dependent on the fact that
there's a HAL.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v1 0/2] userspace-consumer: adding is_shared flag

[Daniel Okazaki]

On Wed, May 28, 2025 at 12:20 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Wed, May 28, 2025 at 11:32:19AM -0700, Daniel Okazaki wrote:
>
> Please don't top post, reply in line with needed context.  This allows
> readers to readily follow the flow of conversation and understand what
> you are talking about and also helps ensure that everything in the
> discussion is being addressed.
>
> > > What is the use case here?
>
> > The request is for a regulator to be controlled by two different
> > subsystems. One is a userspace HAL and the other is
> > a kernel driver.
>
> > Alternatively I could expose sysfs nodes in the kernel driver
> > for the HAL layer to connect to, but it would add coupling
> > between userspace and the kernel driver that might not
> > otherwise be necessary. The userspace regulator driver
> > would add some abstraction between the actual hardware
> > and the sysfs interface.
>
> Presumably the HAL is working through some driver since otherwise it
> would have no access to the hardware, that driver should extend it's
> interface to cover managing the supplies.

The HAL communicates directly with another subsystem via a mailbox
interface and doesn't have a kernel driver.

> This coupling seems
> desirable, we end up with one kernel thing which knows about the whole
> device and the firmware description is not dependent on the fact that
> there's a HAL.

I see, I can make a local sysfs node from the kernel driver to be
exposed to the system.