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: <fbccc241-f957-43cf-9aa2-120e192cad55@oldschoolsolutions.biz>
Date: Sat, 28 Jun 2025 08:14:24 +0200
From: Jens Glathe <jens.glathe@...schoolsolutions.biz>
To: Mark Brown <broonie@...nel.org>,
 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>, konrad.dybcio@....qualcomm.com
Subject: Re: [RFC PATCH v1 0/2] Introduce dummy regulator consumer

Hi there,

On 10.06.25 15:51, Mark Brown wrote:
> On Mon, Jun 09, 2025 at 11:15:09PM +0200, Aleksandrs Vinarskis wrote:
>> 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.

Just like dummy-regulator is an (undesired, but apparently life-saving) 
solution to the issue of not having enough info to correctly specify the 
power supply, it is in this use case, so to speak. You found the enable 
pin to make the peripheral work, you make an educated guess and define 
it as a regulator. For power management to handle it, you need a 
consumer. For all this its nearly irrelevant what the device id is (USB 
discovery runs via the USB host controller in this camera case) nor is 
it really relevant what the voltage is (also an educated guess what 
stand-alone USB devices would get via the bus).

Of course, it would be better to get the correct info and describe it 
accordingly. But more often than not, reality bites.

On that note, another example. I replaced the WLAN and NIC m.2 cards on 
the Snapdragon Dev Kit with an Intel i226v m.2 card that fits into the A 
slot where the WCN7850 was. To reliably enable it, I had to:

- either keep the whole pmu-wcn7850 definition (with wcn7850 consumer 
description, regulators apparently on the card and all) in the tree

- or "wire up" the vreg_wcn_3p3 so that it is activated and accepts any 
consumer.

This didn't go well.

vddpe-3v3-supply on the pcie slot: works, but no USB-A for whatever reason.

Dummy consumer for the regulator like this

     lan {
         compatible = "regulator-dummy-consumer";

         vdd-supply = <&vreg_wcn_3p3>;
     };

This works, reliably. The i226v card doesn't have a node, nor does it 
need one. The driver for this card (igc) seems to be at odds with power 
management, so you need additional kernel parameters anyway.

I'm in favor of having a driver like dummy-consumer to make things work 
when the info for a better definition isn't there. Like dummy-regulator.

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

Exacerbating power consumption when suspended.

with best regards

Jens