| 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
| ||
|
Message-ID: <aHoU7MnweSHGPwxp@linaro.org>
Date: Fri, 18 Jul 2025 11:33:32 +0200
From: Stephan Gerhold <stephan.gerhold@...aro.org>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
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, 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.
Thanks,
Stephan
Powered by blists - more mailing lists