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: <8e452e51-3a95-49e6-91e3-53aa46fcfe2e@oss.qualcomm.com>
Date: Thu, 9 Oct 2025 11:22:08 +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 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

> 
> 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()

Konrad

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ