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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMcHhXpVKaWX8guog_M+5wHfJ+6uxBteNnV1xCjcDJuGFWOCkg@mail.gmail.com>
Date: Mon, 9 Jun 2025 22:32:38 +0200
From: Aleksandrs Vinarskis <alex.vinarskis@...il.com>
To: Mark Brown <broonie@...nel.org>
Cc: linux-kernel@...r.kernel.org, devicetree@...r.kernel.org, 
	Liam Girdwood <lgirdwood@...il.com>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	jens.glathe@...schoolsolutions.biz, konrad.dybcio@....qualcomm.com
Subject: Re: [RFC PATCH v1 0/2] Introduce dummy regulator consumer

On Mon, 9 Jun 2025 at 00:33, Mark Brown <broonie@...nel.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/