[RFC PATCH v1 0/2] Introduce dummy regulator consumer

[RFC PATCH v1 0/2] Introduce dummy regulator consumer

[Aleksandrs Vinarskis]

Introduce a very simple dummy consumer driver. Designed to consume
a single regulator 'vdd', the driver will power-on on probe and PM
suspend (if supported), power-off on remove and PM resume (if enabled).

There are two main reasons for this driver:
1. Create a pseudo-consumer in place of real devices which are not or
   cannot be described in the device-tree. Examples would be integrated
   USB UVC camera (present on some arm64 laptops) or dedicated keyboard
   backlight regulator (hypothetical). Instead of leaving regulator
   without consumer and `regulator-always-on` property, one could bind
   to dummy consumer to save some power during suspend.
2. A great development tool.

Tested on Asus Zenbook A14 with webcamera indicator LED imitating vreg
enable pin.

Aleksandrs Vinarskis (2):
  regulator: Add dummy regulator consumer binding
  regulator: Introduce dummy regulator consumer driver

 .../bindings/regulator/dummy-consumer.yaml    | 39 +++++++++
 drivers/regulator/Kconfig                     |  9 ++
 drivers/regulator/Makefile                    |  1 +
 drivers/regulator/dummy-consumer.c            | 85 +++++++++++++++++++
 4 files changed, 134 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/dummy-consumer.yaml
 create mode 100644 drivers/regulator/dummy-consumer.c

-- 
2.45.2

[RFC PATCH v1 1/2] regulator: Add dummy regulator consumer binding

[Aleksandrs Vinarskis]

Add the devicetree binding for the upcoming driver.

Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
---
 .../bindings/regulator/dummy-consumer.yaml    | 39 +++++++++++++++++++
 1 file changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/dummy-consumer.yaml

diff --git a/Documentation/devicetree/bindings/regulator/dummy-consumer.yaml b/Documentation/devicetree/bindings/regulator/dummy-consumer.yaml
new file mode 100644
index 000000000000..efe8cccab080
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/dummy-consumer.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/dummy-consumer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dummy regulator consumer
+
+maintainers:
+  - Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
+
+description: |
+  Simple dummy regulator consumer node for devices which are not/cannot be
+  described in the devicetree, and do not need to be powered on during
+  suspend. A power-friendly alternative to leaving regulator without
+  consumer with 'regulator-always-on' property.
+
+properties:
+  compatible:
+    enum:
+      - regulator-dummy-consumer
+
+  vdd-supply:
+    description: Regulator to control
+    $ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+  - compatible
+  - vdd-supply
+
+additionalProperties: false
+
+examples:
+  - |
+    integrated-usb-camera {
+      compatible = "regulator-dummy-consumer";
+
+      vdd-supply = <&vdd>;
+    };
-- 
2.45.2

Re: [RFC PATCH v1 1/2] regulator: Add dummy regulator consumer binding

[Rob Herring (Arm)]

On Sat, 07 Jun 2025 23:25:38 +0200, Aleksandrs Vinarskis wrote:
> Add the devicetree binding for the upcoming driver.
> 
> Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
> ---
>  .../bindings/regulator/dummy-consumer.yaml    | 39 +++++++++++++++++++
>  1 file changed, 39 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/regulator/dummy-consumer.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/regulator/dummy-consumer.yaml: properties:vdd-supply: '$ref' is not one of ['description', 'deprecated']
	from schema $id: http://devicetree.org/meta-schemas/core.yaml#

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250607212654.126412-2-alex.vinarskis@gmail.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

[RFC PATCH v1 2/2] regulator: Introduce dummy regulator consumer driver

[Aleksandrs Vinarskis]

Introduce a very simple dummy consumer driver. Designed to consume
a single regulator 'vdd', the driver will power-on on probe and PM
suspend (if supported), power-off on remove and PM resume (if enabled).

Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
---
 drivers/regulator/Kconfig          |  9 ++++
 drivers/regulator/Makefile         |  1 +
 drivers/regulator/dummy-consumer.c | 85 ++++++++++++++++++++++++++++++
 3 files changed, 95 insertions(+)
 create mode 100644 drivers/regulator/dummy-consumer.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 6d8988387da4..eb907ecbcbe8 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -30,6 +30,15 @@ config REGULATOR_DEBUG
 	help
 	  Say yes here to enable debugging support.
 
+config REGULATOR_DUMMY_CONSUMER
+	tristate "Dummy regulator consumer support"
+	help
+	  This driver provides a dummy consumer for a device behind an
+	  USB phy (for example) that needs power supplies, but has no
+	  own device node since it's enumerated by USB.
+
+	  If unsure, say no.
+
 config REGULATOR_FIXED_VOLTAGE
 	tristate "Fixed voltage regulator support"
 	help
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index c0bc7a0f4e67..e1d1029fd87a 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -5,6 +5,7 @@
 
 
 obj-$(CONFIG_REGULATOR) += core.o dummy.o fixed-helper.o helpers.o devres.o irq_helpers.o
+obj-$(CONFIG_REGULATOR_DUMMY_CONSUMER) += dummy-consumer.o
 obj-$(CONFIG_REGULATOR_NETLINK_EVENTS) += event.o
 obj-$(CONFIG_OF) += of_regulator.o
 obj-$(CONFIG_REGULATOR_FIXED_VOLTAGE) += fixed.o
diff --git a/drivers/regulator/dummy-consumer.c b/drivers/regulator/dummy-consumer.c
new file mode 100644
index 000000000000..813c7abce660
--- /dev/null
+++ b/drivers/regulator/dummy-consumer.c
@@ -0,0 +1,85 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2025, Aleksandrs Vinarskis
+ */
+
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm.h>
+#include <linux/regulator/consumer.h>
+
+struct dummy_consumer_data {
+	struct regulator *regulator;
+};
+
+static int dummy_consumer_probe(struct platform_device *pdev)
+{
+	struct dummy_consumer_data *data;
+	int ret;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	data->regulator = devm_regulator_get(&pdev->dev, "vdd");
+	if (IS_ERR(data->regulator)) {
+		dev_err(&pdev->dev, "Failed to get regulator\n");
+		return PTR_ERR(data->regulator);
+	}
+
+	ret = regulator_enable(data->regulator);
+	if (ret) {
+		dev_err(&pdev->dev, "Failed to enable regulator: %d\n", ret);
+		return ret;
+	}
+
+	platform_set_drvdata(pdev, data);
+
+	dev_dbg(&pdev->dev, "Dummy regulator consumer initialized\n");
+	return 0;
+}
+
+static void dummy_consumer_remove(struct platform_device *pdev)
+{
+	struct dummy_consumer_data *data = platform_get_drvdata(pdev);
+
+	regulator_disable(data->regulator);
+}
+
+static int dummy_consumer_resume(struct device *dev)
+{
+	struct dummy_consumer_data *data = dev_get_drvdata(dev);
+
+	return regulator_enable(data->regulator);
+}
+
+static int dummy_consumer_suspend(struct device *dev)
+{
+	struct dummy_consumer_data *data = dev_get_drvdata(dev);
+
+	return regulator_disable(data->regulator);
+}
+
+static DEFINE_SIMPLE_DEV_PM_OPS(dummy_consumer_pm, dummy_consumer_suspend, dummy_consumer_resume);
+
+static const struct of_device_id dummy_consumer_of_match[] = {
+	{ .compatible = "regulator-dummy-consumer", },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, dummy_consumer_of_match);
+
+static struct platform_driver dummy_consumer_driver = {
+	.driver = {
+		.name = "regulator-dummy-consumer",
+		.of_match_table = dummy_consumer_of_match,
+		.pm = pm_sleep_ptr(&dummy_consumer_pm),
+	},
+	.probe = dummy_consumer_probe,
+	.remove = dummy_consumer_remove,
+};
+module_platform_driver(dummy_consumer_driver);
+
+MODULE_AUTHOR("Aleksandrs Vinarskis <alex.vinarskis@gmail.com>");
+MODULE_DESCRIPTION("Dummy regulator consumer driver");
+MODULE_LICENSE("GPL");
-- 
2.45.2

Re: [RFC PATCH v1 0/2] Introduce dummy regulator consumer

[Mark Brown]

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

On Sat, Jun 07, 2025 at 11:25:37PM +0200, Aleksandrs Vinarskis wrote:

> There are two main reasons for this driver:
> 1. Create a pseudo-consumer in place of real devices which are not or
>    cannot be described in the device-tree. Examples would be integrated
>    USB UVC camera (present on some arm64 laptops) or dedicated keyboard
>    backlight regulator (hypothetical). Instead of leaving regulator
>    without consumer and `regulator-always-on` property, one could bind
>    to dummy consumer to save some power during suspend.

Those examples both seem like physical things that exist and can have DT
bindings written for them, why not do that?

> 2. A great development tool.

That's what the userspace consumer is there for...

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

Re: [RFC PATCH v1 0/2] Introduce dummy regulator consumer

[Aleksandrs Vinarskis]

On Mon, 9 Jun 2025 at 00:33, Mark Brown <broonie@kernel.org> wrote:
>
> On Sat, Jun 07, 2025 at 11:25:37PM +0200, Aleksandrs Vinarskis wrote:
>
> > There are two main reasons for this driver:
> > 1. Create a pseudo-consumer in place of real devices which are not or
> >    cannot be described in the device-tree. Examples would be integrated
> >    USB UVC camera (present on some arm64 laptops) or dedicated keyboard
> >    backlight regulator (hypothetical). Instead of leaving regulator
> >    without consumer and `regulator-always-on` property, one could bind
> >    to dummy consumer to save some power during suspend.
>
> Those examples both seem like physical things that exist and can have DT
> bindings written for them, why not do that?

Hi,

Thanks for your feedback. Yes, you are right, they _can_ have DT
bindings for them. And typically that's the way to go for _embedded_
devices that are eg. soldered on the motherboard. In this case of the
webcam on Lenovo Thinbook 16 [1] the proposed option was to utilize
the existing "onboard USB" driver, since it already has bindings and
can be used for that [2]. The issue with this approach is that being a
USB UVC device it is plug & play by definition, it does not need a
dedicated driver, yet we want to bind it to a vreg to avoid having it
always on. Thus, adding VID/PID to a driver just for controlling the
regulator is not very scalable.

Having to add VID/PID for every device that does not in fact need a
dedicated driver has another issue - it was just confirmed that Lenovo
Ideapad 5 uses a similar setup with USB UVC webcam, but of course
VID/PID are different. That would require yet another driver change.
Moreover, manufacturers are known for using multiple SKUs of parts,
especially in these budget laptops we sometimes see as high as 3
versions of touchpad models  listed in DSDT on the same machine. Being
a USB device, the VID/PID are not even listed in DSDT, hence even if
one were to use 'onboard USB' or any other dedicated driver/binding to
hardcode _this_ camera's VID/PID, we cannot be sure whether another
unit of the same laptop model will have the same camera and thus will
work or not.

My initial thought was like you suggest to create a USB camera driver
with a binding instead of using VID/PID matching to be used for vreg
control. Thinking one step further, this in fact has nothing to do
with USB cameras, but rather any device that does not need to be
described in DT as such, but we would want to have its vreg
controlled.

>
> > 2. A great development tool.
>
> That's what the userspace consumer is there for...

Fair point.

Alex

[1] https://lore.kernel.org/all/20250607-tb16-dt-v6-0-61a31914ee72@oldschoolsolutions.biz/
[2] https://lore.kernel.org/all/20250607-tb16-dt-v6-2-61a31914ee72@oldschoolsolutions.biz/

Re: [RFC PATCH v1 0/2] Introduce dummy regulator consumer

[Mark Brown]

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

On Mon, Jun 09, 2025 at 10:32:38PM +0200, Aleksandrs Vinarskis wrote:

> Thanks for your feedback. Yes, you are right, they _can_ have DT
> bindings for them. And typically that's the way to go for _embedded_
> devices that are eg. soldered on the motherboard. In this case of the
> webcam on Lenovo Thinbook 16 [1] the proposed option was to utilize
> the existing "onboard USB" driver, since it already has bindings and
> can be used for that [2]. The issue with this approach is that being a
> USB UVC device it is plug & play by definition, it does not need a
> dedicated driver, yet we want to bind it to a vreg to avoid having it
> always on. Thus, adding VID/PID to a driver just for controlling the
> regulator is not very scalable.

I don't see why not, and this can also be approached from the controller
side - it's providing a USB bus which includes power as part of the
specification.  That's just a question of where the binding happens
though.

I'm also not clear what the relevance is here?  If we have a dummy
consumer we're still going to need to work out how to instantiate it -
that's the same problem no matter what's getting instantiated.  A dummy
consumer is a userspace interface, not a firmware interface.

> Having to add VID/PID for every device that does not in fact need a
> dedicated driver has another issue - it was just confirmed that Lenovo
> Ideapad 5 uses a similar setup with USB UVC webcam, but of course
> VID/PID are different. That would require yet another driver change.

We already need relatively large sets of quirks because laptops have
firmwares built for Windows which is happy to enumerate things based on
DMI information even when there is a perfectly good enumerable interface
that could describe things directly, never mind the bits that aren't
enumerable.  This doesn't seem particularly different.

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

Re: [RFC PATCH v1 0/2] Introduce dummy regulator consumer

[Aleksandrs Vinarskis]

On Mon, 9 Jun 2025 at 22:50, Mark Brown <broonie@kernel.org> wrote:
>
> On Mon, Jun 09, 2025 at 10:32:38PM +0200, Aleksandrs Vinarskis wrote:
>
> > Thanks for your feedback. Yes, you are right, they _can_ have DT
> > bindings for them. And typically that's the way to go for _embedded_
> > devices that are eg. soldered on the motherboard. In this case of the
> > webcam on Lenovo Thinbook 16 [1] the proposed option was to utilize
> > the existing "onboard USB" driver, since it already has bindings and
> > can be used for that [2]. The issue with this approach is that being a
> > USB UVC device it is plug & play by definition, it does not need a
> > dedicated driver, yet we want to bind it to a vreg to avoid having it
> > always on. Thus, adding VID/PID to a driver just for controlling the
> > regulator is not very scalable.
>
> I don't see why not, and this can also be approached from the controller
> side - it's providing a USB bus which includes power as part of the
> specification.  That's just a question of where the binding happens
> though.

That would be another option. Could you elaborate on this, please?
If I understand you correctly, you mean to extend controller binding
(and driver) to take in an additional supply? If yes - I'm afraid that
will be hard to justify to USB controller folks - as per my
understanding bindings (and device's driver) shall describe the
physical specification of the device, and in this case the root
controller does not in fact provide powered rail(s), nor a way to
control it - its an external addition controlled by SoC's GPIO for a
specific device, so it shall be described as such. Perhaps Konrad
could share his view on this?

>
> I'm also not clear what the relevance is here?  If we have a dummy
> consumer we're still going to need to work out how to instantiate it -
> that's the same problem no matter what's getting instantiated.  A dummy
> consumer is a userspace interface, not a firmware interface.

Ah perhaps I should have shared more examples, my bad.
Currently suggested solution, which in my opinion is not scalable:
* Add VID/PID (of every camera, iff known) to onboard usb driver [1]
* Define in DT as:
```
camera {
  compatible = "usb5986,1198";

  vdd-supply = <&vreg_cam_5p0>;
};
```

Proposed solution with dummy regulator consumer:
* No need to explicitly set VID/PID. Define in DT as:
```
camera {
  compatible = "regulator-dummy-consumer";

  vdd-supply = <&vreg_cam_5p0>;
};
```

The problem I am trying to solve is to avoid adding entries to various
USB drivers every time one would like to add a new DT for a new
platform (variant). Proposed solution is a device-agnostic regulator
consumer with PM capabilities, for devices that otherwise do not need
a driver. If there is an even simpler and/or more neat solution that I
missed that would be of course preferred, this was the simplest way I
could solve it.

>
> > Having to add VID/PID for every device that does not in fact need a
> > dedicated driver has another issue - it was just confirmed that Lenovo
> > Ideapad 5 uses a similar setup with USB UVC webcam, but of course
> > VID/PID are different. That would require yet another driver change.
>
> We already need relatively large sets of quirks because laptops have
> firmwares built for Windows which is happy to enumerate things based on
> DMI information even when there is a perfectly good enumerable interface
> that could describe things directly, never mind the bits that aren't
> enumerable.  This doesn't seem particularly different.

But how would we approach the lack of particular information, in this
case all possible VID/PID for an embedded camera? VID/PID was
identified by checking the actual device, which does not rule out OEM
switching camera SKU on the next batch, same way they do with other
peripherals.

[1] https://lore.kernel.org/all/20250607-tb16-dt-v6-2-61a31914ee72@oldschoolsolutions.biz/

Re: [RFC PATCH v1 0/2] Introduce dummy regulator consumer

[Mark Brown]

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

On Mon, Jun 09, 2025 at 11:15:09PM +0200, Aleksandrs Vinarskis wrote:
> On Mon, 9 Jun 2025 at 22:50, Mark Brown <broonie@kernel.org> wrote:

> > I don't see why not, and this can also be approached from the controller
> > side - it's providing a USB bus which includes power as part of the
> > specification.  That's just a question of where the binding happens
> > though.

> That would be another option. Could you elaborate on this, please?
> If I understand you correctly, you mean to extend controller binding
> (and driver) to take in an additional supply? If yes - I'm afraid that

Yes.

> will be hard to justify to USB controller folks - as per my
> understanding bindings (and device's driver) shall describe the
> physical specification of the device, and in this case the root
> controller does not in fact provide powered rail(s), nor a way to
> control it - its an external addition controlled by SoC's GPIO for a
> specific device, so it shall be described as such. Perhaps Konrad
> could share his view on this?

There's also the potential that there isn't a single 5V supply for the
bus, depending on the system design.

> > I'm also not clear what the relevance is here?  If we have a dummy
> > consumer we're still going to need to work out how to instantiate it -
> > that's the same problem no matter what's getting instantiated.  A dummy
> > consumer is a userspace interface, not a firmware interface.

> Ah perhaps I should have shared more examples, my bad.
> Currently suggested solution, which in my opinion is not scalable:
> * Add VID/PID (of every camera, iff known) to onboard usb driver [1]
> * Define in DT as:
> ```
> camera {
>   compatible = "usb5986,1198";
> 
>   vdd-supply = <&vreg_cam_5p0>;
> };

That's what I'd understood.

> Proposed solution with dummy regulator consumer:
> * No need to explicitly set VID/PID. Define in DT as:
> ```
> camera {
>   compatible = "regulator-dummy-consumer";
> 
>   vdd-supply = <&vreg_cam_5p0>;
> };
> ```

This is clearly not describing the hardware and therefore not a good fit
for DT.

> > > Having to add VID/PID for every device that does not in fact need a
> > > dedicated driver has another issue - it was just confirmed that Lenovo
> > > Ideapad 5 uses a similar setup with USB UVC webcam, but of course
> > > VID/PID are different. That would require yet another driver change.

> > We already need relatively large sets of quirks because laptops have
> > firmwares built for Windows which is happy to enumerate things based on
> > DMI information even when there is a perfectly good enumerable interface
> > that could describe things directly, never mind the bits that aren't
> > enumerable.  This doesn't seem particularly different.

> But how would we approach the lack of particular information, in this
> case all possible VID/PID for an embedded camera? VID/PID was
> identified by checking the actual device, which does not rule out OEM
> switching camera SKU on the next batch, same way they do with other
> peripherals.

I'm not saying this a particularly great or pleasant solution, just that
it's where things are at.  You're trying to solve an OS problem with a
firmware description which is a bit of a mismatch, ideally the firmware
descriptions would be better but that's just not how ACPI laptops work
unfortunately.

It does seem a lot easier to just mark the supplies as always on if
there's no integration with an actual client driver TBH.

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

Re: [RFC PATCH v1 0/2] Introduce dummy regulator consumer

[Jens Glathe]

Hi there,

On 10.06.25 15:51, Mark Brown wrote:
> On Mon, Jun 09, 2025 at 11:15:09PM +0200, Aleksandrs Vinarskis wrote:
>> But how would we approach the lack of particular information, in this
>> case all possible VID/PID for an embedded camera? VID/PID was
>> identified by checking the actual device, which does not rule out OEM
>> switching camera SKU on the next batch, same way they do with other
>> peripherals.
> I'm not saying this a particularly great or pleasant solution, just that
> it's where things are at.  You're trying to solve an OS problem with a
> firmware description which is a bit of a mismatch, ideally the firmware
> descriptions would be better but that's just not how ACPI laptops work
> unfortunately.

Just like dummy-regulator is an (undesired, but apparently life-saving) 
solution to the issue of not having enough info to correctly specify the 
power supply, it is in this use case, so to speak. You found the enable 
pin to make the peripheral work, you make an educated guess and define 
it as a regulator. For power management to handle it, you need a 
consumer. For all this its nearly irrelevant what the device id is (USB 
discovery runs via the USB host controller in this camera case) nor is 
it really relevant what the voltage is (also an educated guess what 
stand-alone USB devices would get via the bus).

Of course, it would be better to get the correct info and describe it 
accordingly. But more often than not, reality bites.

On that note, another example. I replaced the WLAN and NIC m.2 cards on 
the Snapdragon Dev Kit with an Intel i226v m.2 card that fits into the A 
slot where the WCN7850 was. To reliably enable it, I had to:

- either keep the whole pmu-wcn7850 definition (with wcn7850 consumer 
description, regulators apparently on the card and all) in the tree

- or "wire up" the vreg_wcn_3p3 so that it is activated and accepts any 
consumer.

This didn't go well.

vddpe-3v3-supply on the pcie slot: works, but no USB-A for whatever reason.

Dummy consumer for the regulator like this

     lan {
         compatible = "regulator-dummy-consumer";

         vdd-supply = <&vreg_wcn_3p3>;
     };

This works, reliably. The i226v card doesn't have a node, nor does it 
need one. The driver for this card (igc) seems to be at odds with power 
management, so you need additional kernel parameters anyway.

I'm in favor of having a driver like dummy-consumer to make things work 
when the info for a better definition isn't there. Like dummy-regulator.

> It does seem a lot easier to just mark the supplies as always on if
> there's no integration with an actual client driver TBH.

Exacerbating power consumption when suspended.

with best regards

Jens

Re: [RFC PATCH v1 0/2] Introduce dummy regulator consumer

[Konrad Dybcio]

On 6/28/25 8:14 AM, Jens Glathe wrote:
> Hi there,
> 
> On 10.06.25 15:51, Mark Brown wrote:
>> On Mon, Jun 09, 2025 at 11:15:09PM +0200, Aleksandrs Vinarskis wrote:
>>> But how would we approach the lack of particular information, in this
>>> case all possible VID/PID for an embedded camera? VID/PID was
>>> identified by checking the actual device, which does not rule out OEM
>>> switching camera SKU on the next batch, same way they do with other
>>> peripherals.
>> I'm not saying this a particularly great or pleasant solution, just that
>> it's where things are at.  You're trying to solve an OS problem with a
>> firmware description which is a bit of a mismatch, ideally the firmware
>> descriptions would be better but that's just not how ACPI laptops work
>> unfortunately.
> 
> Just like dummy-regulator is an (undesired, but apparently life-saving) solution to the issue of not having enough info to correctly specify the power supply, it is in this use case, so to speak. You found the enable pin to make the peripheral work, you make an educated guess and define it as a regulator. For power management to handle it, you need a consumer. For all this its nearly irrelevant what the device id is (USB discovery runs via the USB host controller in this camera case) nor is it really relevant what the voltage is (also an educated guess what stand-alone USB devices would get via the bus).
> 
> Of course, it would be better to get the correct info and describe it accordingly. But more often than not, reality bites.
> 
> On that note, another example. I replaced the WLAN and NIC m.2 cards on the Snapdragon Dev Kit with an Intel i226v m.2 card that fits into the A slot where the WCN7850 was. To reliably enable it, I had to:
> 
> - either keep the whole pmu-wcn7850 definition (with wcn7850 consumer description, regulators apparently on the card and all) in the tree
> 
> - or "wire up" the vreg_wcn_3p3 so that it is activated and accepts any consumer.
> 
> This didn't go well.
> 
> vddpe-3v3-supply on the pcie slot: works, but no USB-A for whatever reason.
> 
> Dummy consumer for the regulator like this
> 
>     lan {
>         compatible = "regulator-dummy-consumer";
> 
>         vdd-supply = <&vreg_wcn_3p3>;
>     };

In this case, it's more or less easy because the 3v3 supply should
probably be bound to the PCIe port (+Mani)

Konrad

> 
> This works, reliably. The i226v card doesn't have a node, nor does it need one. The driver for this card (igc) seems to be at odds with power management, so you need additional kernel parameters anyway.
> 
> I'm in favor of having a driver like dummy-consumer to make things work when the info for a better definition isn't there. Like dummy-regulator.
> 
>> It does seem a lot easier to just mark the supplies as always on if
>> there's no integration with an actual client driver TBH.
> 
> Exacerbating power consumption when suspended.
> 
> with best regards
> 
> Jens
> 

Re: [RFC PATCH v1 0/2] Introduce dummy regulator consumer

[Mark Brown]

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

On Sat, Jun 28, 2025 at 04:35:32PM +0200, Konrad Dybcio wrote:
> On 6/28/25 8:14 AM, Jens Glathe wrote:

> > Just like dummy-regulator is an (undesired, but apparently
> > life-saving) solution to the issue of not having enough info to

Konrad, looks like your MUA has reflowed all of Jens' reply to remove
the line breaks.

> > vddpe-3v3-supply on the pcie slot: works, but no USB-A for whatever reason.

> In this case, it's more or less easy because the 3v3 supply should
> probably be bound to the PCIe port (+Mani)

Right, the DT should describe the board and the board has a PCIe slot.
If something is plugged in and needs mapping that should happen through
the slot.  

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