linux-kernel - Re: [PATCH 2/5] arm64: dts: qcom: qcm6490-fairphone-fp5: Add VTOF_LDO

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] [day] [month] [year] [list]

Message-ID: <36928f42-3603-4e01-a31d-8f9e60f54009@oss.qualcomm.com>
Date: Mon, 20 Oct 2025 14:08:05 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Luca Weiss <luca.weiss@...rphone.com>,
        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>,
        Marijn Suijten <marijn.suijten@...ainline.org>
Cc: ~postmarketos/upstreaming@...ts.sr.ht, phone-devel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/5] arm64: dts: qcom: qcm6490-fairphone-fp5: Add
 VTOF_LDO_2P8 regulator

On 10/9/25 12:10 PM, Luca Weiss wrote:
> On Thu Oct 9, 2025 at 11:22 AM CEST, Konrad Dybcio wrote:
>> On 10/9/25 11:16 AM, Luca Weiss wrote:
>>> Hi Konrad,
>>>
>>> On Wed Oct 1, 2025 at 10:30 AM CEST, Konrad Dybcio wrote:
>>>> On 9/30/25 3:57 PM, Luca Weiss wrote:
>>>>> Describe yet another regulator-fixed on this board, powering the ToF
>>>>> sensor.
>>>>>
>>>>> Signed-off-by: Luca Weiss <luca.weiss@...rphone.com>
>>>>> ---
>>>>>  arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 13 +++++++++++++
>>>>>  1 file changed, 13 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
>>>>> index 36d5750584831d66b4c2faf6042e4cbb3274eca7..0a64e5721e092d1f3e4bb7329335704eee567761 100644
>>>>> --- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
>>>>> +++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
>>>>> @@ -195,6 +195,19 @@ vreg_usb_redrive_1v8: regulator-usb-redrive-1v8 {
>>>>>  		pinctrl-names = "default";
>>>>>  	};
>>>>>  
>>>>> +	vreg_vtof_ldo_2p8: regulator-vtof-ldo-2p8 {
>>>>> +		compatible = "regulator-fixed";
>>>>> +		regulator-name = "VTOF_LDO_2P8";
>>>>> +		regulator-min-microvolt = <2800000>;
>>>>> +		regulator-max-microvolt = <2800000>;
>>>>> +		regulator-enable-ramp-delay = <233>;
>>>>> +
>>>>> +		gpio = <&tlmm 141 GPIO_ACTIVE_HIGH>;
>>>>
>>>> You may want to define the pincfg/mux config for this gpio too
>>>
>>> While I wouldn't say it's not good to have it, there's plenty of GPIOs
>>> that have no pinctrl for it. Downstream doesn't set anything for gpio141
>>> either.
>>>
>>> I honestly wouldn't even know what the 'default' for a GPIO is in the
>>> first place, or could I query the runtime state from the kernel? Is
>>> /sys/kernel/debug/pinctrl/f100000.pinctrl/pinconf-groups trustworthy to
>>> solidify this in the dts?
>>
>> I normally use /sys/kernel/debug/gpios
> 
> Oh, if that works at least the path is a bit more memorable. I needed to
> check quite some files in this directory to find the correct one.
> 
>>
>>>
>>> 141 (gpio141): input bias disabled, output drive strength (2 mA), output enabled, pin output (0 level)
>>
>> but this seems to be formatted very similarly if not identically
>>
>> Generally it reads out HW state, via (among other things)
>> msm_config_group_get()
> 
> So, you recommend setting a pinctrl for every single GPIO that's
> referenced in the dts? Shall I send a patch to add all the missing ones?

That would make the state always deterministic and it's probably
desirable yeah

Konrad