arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 8 ++++++++ 1 file changed, 8 insertions(+)
From: David Heidelberg <david@ixit.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@0/spmi@c440000/pmic@3/labibb/lab
qcom-lab-ibb-regulator c440000.spmi:pmic@3:labibb: Failed to create device link (0x180) with supplier c440000.spmi for /soc@0/spmi@c440000/pmic@3/labibb/ibb
Fixes: 288ef8a42612 ("arm64: dts: sdm845: add oneplus6/6t devices")
Signed-off-by: David Heidelberg <david@ixit.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?
---
arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
index db6dd04c51bb5..78a835bdfe3b4 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
@@ -419,6 +419,10 @@ rmi4_f12: rmi4-f12@12 {
};
};
+&ibb {
+ status = "disabled";
+};
+
&ipa {
qcom,gsi-loader = "self";
memory-region = <&ipa_fw_mem>;
@@ -426,6 +430,10 @@ &ipa {
status = "okay";
};
+&lab {
+ status = "disabled";
+};
+
&mdss {
status = "okay";
};
---
base-commit: 7d31f578f3230f3b7b33b0930b08f9afd8429817
change-id: 20251130-oneplus-labibb-05bdd6d6d2b1
Best regards,
--
David Heidelberg <david@ixit.cz>
On 11/30/25 1:08 AM, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.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@0/spmi@c440000/pmic@3/labibb/lab
> qcom-lab-ibb-regulator c440000.spmi:pmic@3:labibb: Failed to create device link (0x180) with supplier c440000.spmi for /soc@0/spmi@c440000/pmic@3/labibb/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@ixit.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
Konrad
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@ixit.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@0/spmi@c440000/pmic@3/labibb/lab
>> qcom-lab-ibb-regulator c440000.spmi:pmic@3:labibb: Failed to create device link (0x180) with supplier c440000.spmi for /soc@0/spmi@c440000/pmic@3/labibb/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@ixit.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.
>
> Konrad
--
// Casey (she/her)
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@ixit.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@0/spmi@c440000/pmic@3/labibb/lab
>>> qcom-lab-ibb-regulator c440000.spmi:pmic@3:labibb: Failed to create device link (0x180) with supplier c440000.spmi for /soc@0/spmi@c440000/pmic@3/labibb/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@ixit.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
On 01/12/2025 13:55, Konrad Dybcio wrote:
> 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@ixit.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@0/spmi@c440000/pmic@3/labibb/lab
>>>> qcom-lab-ibb-regulator c440000.spmi:pmic@3:labibb: Failed to create device link (0x180) with supplier c440000.spmi for /soc@0/spmi@c440000/pmic@3/labibb/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@ixit.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)
Ahh yeah I understand, the DT node has to be enabled for the driver to
load and actually turn off the regulators if they're unused. Makes sense.
Thanks,>
> Konrad
--
// Casey (she/her)
© 2016 - 2025 Red Hat, Inc.