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] [day] [month] [year] [list]

Message-ID: <6fcbedb3-eb41-449f-9b6d-10699153c9dc@sirena.org.uk>
Date: Tue, 10 Jun 2025 14:51:36 +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 11:15:09PM +0200, Aleksandrs Vinarskis wrote:
> On Mon, 9 Jun 2025 at 22:50, Mark Brown <broonie@...nel.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.

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