linux-kernel - Re: [PATCH 3/4] arm64: dts: qcom: Add HAMOA-IOT-SOM platform

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: <39deebf4-79cd-42a0-b49e-01d556e6d1e3@oss.qualcomm.com>
Date: Wed, 23 Jul 2025 15:53:13 +0800
From: Yijie Yang <yijie.yang@....qualcomm.com>
To: Stephan Gerhold <stephan.gerhold@...aro.org>,
        Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: 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
Subject: Re: [PATCH 3/4] arm64: dts: qcom: Add HAMOA-IOT-SOM platform



On 2025-07-18 04:14, Stephan Gerhold wrote:
> On Thu, Jul 17, 2025 at 10:10:05PM +0200, Konrad Dybcio wrote:
>> On 7/17/25 6:14 PM, Stephan Gerhold wrote:
>>> On Wed, Jul 16, 2025 at 05:08:41PM +0800, Yijie Yang wrote:
>>>> The HAMOA-IOT-SOM is a compact computing module that integrates a System
>>>> on Chip (SoC) — specifically the x1e80100 — along with essential
>>>> components optimized for IoT applications. It is designed to be mounted on
>>>> carrier boards, enabling the development of complete embedded systems.
>>>>
>>>> This change enables and overlays the following components:
>>>> - Regulators on the SOM
>>>> - Reserved memory regions
>>>> - PCIe6a and its PHY
>>>> - PCIe4 and its PHY
>>>> - USB0 through USB6 and their PHYs
>>>> - ADSP, CDSP
>>>> - WLAN, Bluetooth (M.2 interface)
>>
>> [...]
>>
>>>> +&usb_mp_hsphy0 {
>>>> +	vdd-supply = <&vreg_l2e_0p8>;
>>>> +	vdda12-supply = <&vreg_l3e_1p2>;
>>>> +
>>>> +	status = "okay";
>>>> +};
>>>> +
>>>> +&usb_mp_hsphy1 {
>>>> +	vdd-supply = <&vreg_l2e_0p8>;
>>>> +	vdda12-supply = <&vreg_l3e_1p2>;
>>>> +
>>>> +	status = "okay";
>>>> +};
>>>> +
>>>> +&usb_mp_qmpphy0 {
>>>> +	vdda-phy-supply = <&vreg_l3e_1p2>;
>>>> +	vdda-pll-supply = <&vreg_l3c_0p8>;
>>>> +
>>>> +	status = "okay";
>>>> +};
>>>> +
>>>> +&usb_mp_qmpphy1 {
>>>> +	vdda-phy-supply = <&vreg_l3e_1p2>;
>>>> +	vdda-pll-supply = <&vreg_l3c_0p8>;
>>>> +
>>>> +	status = "okay";
>>>> +};
>>>>
>>>
>>> Assuming the USB ports are located on the carrier board and not the
>>> SoM(?):
>>>
>>> Are carrier boards required to make use of all these USB
>>> ports/interfaces? In my experience it's not unusual that embedded
>>> carrier boards use only the functionality that they need. Maybe this
>>> should just set the common properties and enabling individual ports for
>>> PCIe and USB should be up to the carrier boards.
>>
>> The PHYs are on the SoC and if the kernel is told they're "disabled",
>> they may possibly be left dangling from the bootloader
>>
> 
> How is this different from any of the laptops we have upstream? If we're
> worried about firmware keeping unused PHYs on, then we should probably
> enable all the PHY nodes by default in the SoC .dtsi?

Per my understanding, the SoM may be used with various types of 
firmware, some of which might fully initialize all USB PHYs. In 
contrast, laptop platforms typically rely on fixed firmware that only 
initializes what's necessary for boot.

> 
> Thanks,
> Stephan

-- 
Best Regards,
Yijie