linux-kernel - Re: [PATCH 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: <CAO9ioeWZYht=oJHKeHqwpPmOyJkDE5H2hxh-+Ppp0V=OPv7bJw@mail.gmail.com>
Date: Fri, 18 Jul 2025 14:46:52 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Stephan Gerhold <stephan.gerhold@...aro.org>
Cc: 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
Subject: Re: [PATCH 4/4] arm64: dts: qcom: Add base HAMOA-IOT-EVK board

On Fri, 18 Jul 2025 at 12:33, Stephan Gerhold
<stephan.gerhold@...aro.org> wrote:
>
> On Fri, Jul 18, 2025 at 12:27:34PM +0300, Dmitry Baryshkov wrote:
> > On Fri, Jul 18, 2025 at 04:19:13PM +0800, Yijie Yang wrote:
> > > On 2025-07-18 00:37, Stephan Gerhold wrote:
> > > > On Wed, Jul 16, 2025 at 05:08:42PM +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.
> > > > >
> > > > > This change enables and overlays the following peripherals on the carrier
> > > > > board:
> > > > > - UART
> > > > > - On-board regulators
> > > > > - USB Type-C mux
> > > > > - Pinctrl
> > > > > - Embedded USB (EUSB) repeaters
> > > > > - NVMe
> > > > > - pmic-glink
> > > > >
> > > > > Written with contributions from Shuai Zhang (added Bluetooth).
> > > > >
> > > > > 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 | 835 +++++++++++++++++++++++++++++
> > > > >   2 files changed, 836 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > > > > index 4bfa926b6a0850c3c459bcba28129c559d50a7cf..c5994b75d3e56e74ffb64b2389ee1bcc086f3065 100644
> > > > > --- a/arch/arm64/boot/dts/qcom/Makefile
> > > > > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > > > > @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_QCOM)       += apq8039-t2.dtb
> > > > >   dtb-$(CONFIG_ARCH_QCOM)       += apq8094-sony-xperia-kitakami-karin_windy.dtb
> > > > >   dtb-$(CONFIG_ARCH_QCOM)       += apq8096-db820c.dtb
> > > > >   dtb-$(CONFIG_ARCH_QCOM)       += apq8096-ifc6640.dtb
> > > > > +dtb-$(CONFIG_ARCH_QCOM)        += hamoa-iot-evk.dtb
> > > > >   dtb-$(CONFIG_ARCH_QCOM)       += ipq5018-rdp432-c2.dtb
> > > > >   dtb-$(CONFIG_ARCH_QCOM)       += ipq5018-tplink-archer-ax55-v1.dtb
> > > > >   dtb-$(CONFIG_ARCH_QCOM)       += ipq5332-rdp441.dtb
> > > > > diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> > > > > new file mode 100644
> > > > > index 0000000000000000000000000000000000000000..843f39c9d59286a9303a545411b2518d7649a059
> > > > > --- /dev/null
> > > > > +++ b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> > > > > [...]
> > > > > +       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;
> > > > > +       };
> > > > > +
> > > > > +       /*
> > > > > +        * TODO: These two regulators are actually part of the removable M.2
> > > > > +        * card and not the CRD mainboard. Need to describe this differently.
> > > > > +        * Functionally it works correctly, because all we need to do is to
> > > > > +        * turn on the actual 3.3V supply above.
> > > > > +        */
> > > > > +       vreg_wcn_0p95: regulator-wcn-0p95 {
> > > > > +               compatible = "regulator-fixed";
> > > > > +
> > > > > +               regulator-name = "VREG_WCN_0P95";
> > > > > +               regulator-min-microvolt = <950000>;
> > > > > +               regulator-max-microvolt = <950000>;
> > > > > +
> > > > > +               vin-supply = <&vreg_wcn_3p3>;
> > > > > +       };
> > > > > +
> > > > > +       vreg_wcn_1p9: regulator-wcn-1p9 {
> > > > > +               compatible = "regulator-fixed";
> > > > > +
> > > > > +               regulator-name = "VREG_WCN_1P9";
> > > > > +               regulator-min-microvolt = <1900000>;
> > > > > +               regulator-max-microvolt = <1900000>;
> > > > > +
> > > > > +               vin-supply = <&vreg_wcn_3p3>;
> > > > > +       };
> > > >
> > > > Like the TODO comment already says, regulators located on a M.2 card
> > > > shouldn't be described as part of the device DT. We need a proper
> > > > solution for modelling the M.2 slots together with the standard power
> > > > supplies (3.3V and 1.8V) and hook this up to the pwrseq subsystem. This
> > > > is also the reason why the CRD does not have Bluetooth enabled upstream
> > > > yet, this needs to be solved first.
> > > >
> > > > As far as I know, there is no one actively working on addressing this at
> > > > the moment. Perhaps you can assign someone at QC to work on solving this
> > > > upstream.
> > >
> > > This power section is now managed by UEFI, rendering these regulator nodes
> > > unnecessary. Therefore, I will remove them in the next version.
> >
> > No. The regulators for the M.2 slot should be present here so that Linux
> > doesn't disable them. Which triggers a question: how are they
> > controlled? I don't see a GPIO line there.
> >
>
> The 0.95V and 1.9V regulators are located on the inserted M.2 *card* and
> get automatically enabled by the 3.3V supply of the M.2 *slot*. If you
> remove the card or insert a different one, they won't be present. This
> is why they shouldn't be part of the DT. The M.2 slot only has a 3.3V
> supply and a 1.8V supply.
>
> The only reason why they are here is that the current bindings for the
> WCN7850 require describing the whole PMU and internal regulators of the
> M.2 card. Ideally, we should have a generic description for the M.2
> slot/connector instead.

Agree.


-- 
With best wishes
Dmitry