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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAMcHhXoioEJH+KnLYbXmnt5eyGT-tXg0-CzLQpvj=8Jy5sGXuw@mail.gmail.com>
Date: Mon, 9 Jun 2025 23:15:09 +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 22:50, Mark Brown <broonie@...nel.org> wrote:
>
> 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.

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
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?

>
> 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>;
};
```

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>;
};
```

The problem I am trying to solve is to avoid adding entries to various
USB drivers every time one would like to add a new DT for a new
platform (variant). Proposed solution is a device-agnostic regulator
consumer with PM capabilities, for devices that otherwise do not need
a driver. If there is an even simpler and/or more neat solution that I
missed that would be of course preferred, this was the simplest way I
could solve it.

>
> > 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.

[1] https://lore.kernel.org/all/20250607-tb16-dt-v6-2-61a31914ee72@oldschoolsolutions.biz/