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

Mark Brown
2025-06-10T13:51:41Z

[-- 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 --]