linux-kernel - Re: [PATCH v11 4/4] arm64: dts: qcom: Add base HAMOA-IOT-EVK board

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: <03fe6810-fd37-4883-8fd3-f4919dec1b8d@oss.qualcomm.com>
Date: Tue, 16 Sep 2025 13:00:10 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Yingying Tang <quic_yintang@...cinc.com>,
        Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Stephan Gerhold <stephan.gerhold@...aro.org>,
        Yijie Yang <yijie.yang@....qualcomm.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>, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Yingying Tang <yingying.tang@....qualcomm.com>,
        Shuai Zhang <shuaz@....qualcomm.com>, zhichen@....qualcomm.com
Subject: Re: [PATCH v11 4/4] arm64: dts: qcom: Add base HAMOA-IOT-EVK board

On 9/16/25 12:39 PM, Yingying Tang wrote:
> 
> 
> On 9/16/2025 6:36 PM, Konrad Dybcio wrote:
>> On 9/16/25 12:29 PM, Yingying Tang wrote:
>>>
>>>
>>> On 9/16/2025 6:14 PM, Dmitry Baryshkov wrote:
>>>> On Tue, Sep 16, 2025 at 09:42:26AM +0800, Yingying Tang wrote:
>>>>>
>>>>>
>>>>> On 9/12/2025 5:00 PM, Stephan Gerhold wrote:
>>>>>> On Wed, Sep 10, 2025 at 05:02:12PM +0800, Yijie Yang wrote:
>>>>>>> The HAMOA-IOT-EVK is an evaluation platform for IoT products, composed of
>>>>>>> the Hamoa IoT SoM and a carrier board. Together, they form a complete
>>>>>>> embedded system capable of booting to UART.
>>>>>>>
>>>>>>> Make the following peripherals on the carrier board enabled:
>>>>>>> - UART
>>>>>>> - On-board regulators
>>>>>>> - USB Type-C mux
>>>>>>> - Pinctrl
>>>>>>> - Embedded USB (EUSB) repeaters
>>>>>>> - NVMe
>>>>>>> - pmic-glink
>>>>>>> - USB DisplayPorts
>>>>>>> - Bluetooth
>>>>>>> - WLAN
>>>>>>> - Audio
>>>>>>>
>>>>>>> Written in collaboration with Quill Qi (Audio) <le.qi@....qualcomm.com>,
>>>>>>> Jie Zhang (Graphics) <quic_jiezh@...cinc.com>, Shuai Zhang (Bluetooth)
>>>>>>> <quic_shuaz@...cinc.com>, Yingying Tang (WLAN) <quic_yintang@...cinc.com>,
>>>>>>> and Yongxing Mou (USB DisplayPorts) <quic_yongmou@...cinc.com>.
>>>>>>
>>>>>> This looks like you should have Co-developed-by: tags together with
>>>>>> their Signed-off-by: tags.
>>>>>>
>>>>>>>
>>>>>>> Signed-off-by: Yijie Yang <yijie.yang@....qualcomm.com>
>>>>>>> ---
>>>>>>>  arch/arm64/boot/dts/qcom/Makefile          |    1 +
>>>>>>>  arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 1221 ++++++++++++++++++++++++++++
>>>>>>>  2 files changed, 1222 insertions(+)
>>>>>>>
>>>>>>> +
>>>>>>> +	vreg_wcn_3p3: regulator-wcn-3p3 {
>>>>>>> +		compatible = "regulator-fixed";
>>>>>>> +
>>>>>>> +		regulator-name = "VREG_WCN_3P3";
>>>>>>> +		regulator-min-microvolt = <3300000>;
>>>>>>> +		regulator-max-microvolt = <3300000>;
>>>>>>> +
>>>>>>> +		gpio = <&tlmm 214 GPIO_ACTIVE_HIGH>;
>>>>>>> +		enable-active-high;
>>>>>>> +
>>>>>>> +		pinctrl-0 = <&wcn_sw_en>;
>>>>>>> +		pinctrl-names = "default";
>>>>>>> +
>>>>>>
>>>>>> regulator-boot-on?
>>>>>
>>>>> It shoulde be regulator-always-on
>>>>
>>>> Why it's not boot-on and always-on?
>>>>
>>> As I described before, connectivity power is voted by UEFI in boot phase.So PCIe link between connetivity card and RC4 is established once RC4 is on.
>>> If we set this node as "regulator-boot-on", connectivity power will be down first then up. That cause PCIe link down and the link can't be trained again unless you reboot board.
>>> So we can't set it to "regulator-boot-on"
>>
>> Surely gpio-regulator.c implements .get_voltage which reads the pin
>> state though? Did you test this, or are you theorycrafting?
>>
> Yes we tested this case many times, "regulator-boot-on" causes PCIe link down. No any issue with "regulator-always-on"

We didn't ask you to remove 'always-on'. That makes sense because
it avoids an extra call to (re-)assert the GPIO if both are
specified

Konrad