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: <b481298e-319f-41ce-8a56-e3f78b8649ff@sirena.org.uk>
Date: Mon, 9 Jun 2025 21:50:08 +0100
From: Mark Brown <broonie@...nel.org>
To: Aleksandrs Vinarskis <alex.vinarskis@...il.com>
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, 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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)