On Mon, Jun 09, 2025 at 11:15:09PM +0200, Aleksandrs Vinarskis wrote:

On Mon, 9 Jun 2025 at 22:50, Mark Brown [off-list ref] wrote:

quoted

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.

quoted

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.

quoted

quoted

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.

quoted

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.