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

Aleksandrs Vinarskis
2025-06-09T20:32:52Z

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/