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: <0d63bddf-7a88-4c59-8ba3-6655e7a8854e@oss.qualcomm.com>
Date: Mon, 1 Dec 2025 13:55:38 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Casey Connolly <casey.connolly@...aro.org>, david@...t.cz,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>
Cc: linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, phone-devel@...r.kernel.org
Subject: Re: [PATCH] arm64: dts: qcom: sdm845-oneplus: labibb is not used on
 OnePlus 6/6T

On 12/1/25 1:50 PM, Casey Connolly wrote:
> 
> 
> On 01/12/2025 13:48, Konrad Dybcio wrote:
>> On 11/30/25 1:08 AM, David Heidelberg via B4 Relay wrote:
>>> From: David Heidelberg <david@...t.cz>
>>>
>>> The lab and ibb regulators aren't used here. Disable them.
>>>
>>> Removes following warnings:
>>> qcom-lab-ibb-regulator c440000.spmi:pmic@3:labibb: Failed to create device link (0x180) with supplier c440000.spmi for /soc@...pmi@...0000/pmic@...abibb/lab
>>> qcom-lab-ibb-regulator c440000.spmi:pmic@3:labibb: Failed to create device link (0x180) with supplier c440000.spmi for /soc@...pmi@...0000/pmic@...abibb/ibb
>>
>> These are only vaguely related, as there's nothing to be wary about that's
>> specific to these devices - it's just devlink being grumpy
>>
>>> Fixes: 288ef8a42612 ("arm64: dts: sdm845: add oneplus6/6t devices")
>>> Signed-off-by: David Heidelberg <david@...t.cz>
>>> ---
>>> I assume this is right approach, as OLEDs on both devices are driven by
>>> different regulators.
>>>
>>> Question is, if should be labibb nodes enabled by default?
>>
>> They're onboard. I'd rather keep them predictably parked than left in
>> whatever (potentially ON) state the bootloader may leave them at
> 
> Shouldn't they be default disabled in the pmic dtsi and only enabled on
> the devices that actually use them? Many SDM845 devices with OLED panels
> don't use these regulators.

As I said, I wouldn't be surprised if they were enabled by the bootloader
as part of some reference/common routine and left hanging. Linux will
switch them off if they're never used and I'm fairly sure the users won't
mind the odd couple dozen bytes of runtime kernel memory usage (which if
we go that route probably balance out with the added couple characters for
status=disabled in the resulting DTB)

Konrad

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ