Re: [PATCH v2 1/1] arm64: dts: qcom: monaco-evk: Add Interface Plus Mezzanine

[Dmitry Baryshkov]

On Mon, Feb 23, 2026 at 04:36:56PM +0100, Krzysztof Kozlowski wrote:
> On 23/02/2026 16:12, Bjorn Andersson wrote:
> > On Mon, Feb 23, 2026 at 02:12:05PM +0100, Krzysztof Kozlowski wrote:
> >> On 22/02/2026 18:35, Umang Chheda wrote:
> >>> The Interface Plus [IFP] Mezzanine is an hardware expansion add-on
> >>> board designed to be stacked on top of Monaco EVK.
> >>>
> >>> It has following peripherals :
> >>>
> >>> - 4x Type A USB ports in host mode.
> >>> - TC9563 PCIe switch, which has following three downstream ports (DSP) :
> >>>    - 1st DSP connects M.2 E-key connector for connecting WLAN endpoints.
> >>>    - 2nd DSP connects M.2 B-key connector for connecting cellular
> >>>      modems.
> >>>    - 3rd DSP with support for Dual Ethernet ports.
> >>> - EEPROM.
> >>> - LVDS Display.
> >>> - 2*mini DP.
> >>>
> >>> Add support for following peripherals :
> >>> - TC9563 PCIe Switch.
> >>> - EEPROM.
> >>>
> >>> Written with inputs from :
> >>>     Krishna Chaitanya Chundru <krishna.chundru@xxxxxxxxxxxxxxxx> - PCIe
> >>>     Monish Chunara <monish.chunara@xxxxxxxxxxxxxxxx> - EEPROM.
> >>>
> >>> Signed-off-by: Umang Chheda <umang.chheda@xxxxxxxxxxxxxxxx>
> >>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxxxxxxxx>
> >>> ---
> >>>  arch/arm64/boot/dts/qcom/Makefile             |   4 +
> >>>  .../dts/qcom/monaco-evk-ifp-mezzanine.dtso    | 184 ++++++++++++++++++
> >>>  2 files changed, 188 insertions(+)
> >>>  create mode 100644 arch/arm64/boot/dts/qcom/monaco-evk-ifp-mezzanine.dtso
> >>>
> >>> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> >>> index f80b5d9cf1e8..9d298e7e8a90 100644
> >>> --- a/arch/arm64/boot/dts/qcom/Makefile
> >>> +++ b/arch/arm64/boot/dts/qcom/Makefile
> >>> @@ -45,6 +45,10 @@ lemans-evk-el2-dtbs := lemans-evk.dtb lemans-el2.dtbo
> >>>  dtb-$(CONFIG_ARCH_QCOM)	+= lemans-evk-el2.dtb
> >>>  dtb-$(CONFIG_ARCH_QCOM)	+= milos-fairphone-fp6.dtb
> >>>  dtb-$(CONFIG_ARCH_QCOM)	+= monaco-evk.dtb
> >>> +
> >>> +monaco-evk-ifp-mezzanine-dtbs	:= monaco-evk.dtb monaco-evk-ifp-mezzanine.dtbo
> >>> +
> >>> +dtb-$(CONFIG_ARCH_QCOM)	+= monaco-evk-ifp-mezzanine.dtb
> >>>  dtb-$(CONFIG_ARCH_QCOM)	+= msm8216-samsung-fortuna3g.dtb
> >>>  dtb-$(CONFIG_ARCH_QCOM)	+= msm8916-acer-a1-724.dtb
> >>>  dtb-$(CONFIG_ARCH_QCOM)	+= msm8916-alcatel-idol347.dtb
> >>> diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-ifp-mezzanine.dtso b/arch/arm64/boot/dts/qcom/monaco-evk-ifp-mezzanine.dtso
> >>> new file mode 100644
> >>> index 000000000000..f0572647200c
> >>> --- /dev/null
> >>> +++ b/arch/arm64/boot/dts/qcom/monaco-evk-ifp-mezzanine.dtso
> >>> @@ -0,0 +1,184 @@
> >>> +// SPDX-License-Identifier: BSD-3-Clause
> >>> +/*
> >>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> >>> + */
> >>> +
> >>> +/dts-v1/;
> >>> +/plugin/;
> >>> +
> >>> +#include <dt-bindings/gpio/gpio.h>
> >>> +
> >>> +&{/} {
> >>> +	model = "Qualcomm Technologies, Inc. Monaco-EVK IFP Mezzanine";
> >>> +
> >>> +	vreg_0p9: regulator-vreg-0p9 {
> >>
> >> Please use name for all fixed regulators which matches current format
> >> recommendation: 'regulator-[0-9]v[0-9]'
> >>
> >> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml
> >>
> >> Duplicating regulator name (regulator-reg(ulator)) is pointless.
> >>
> > 
> > "pointless" is a strong word IMO.
> 
> Pointless meaning it has no point, because the "vreg" is just redundant.
> It gives no new information.
> 
> 
> > 
> > The recommendation that has been communicated is to based label, name
> > and regulator-name of the schematics, but prefix the node name with
> > regulator- to achieve sensible sort order.
> > 
> > 
> > In fact naming these regulator-0v9, regulator-1v8, and regulator-3v3
> > make the name useless. We further have plenty of designs where there are
> > multiple regulator-1v8 and regulator-3v3.
> 
> The regulator-name is to match schematics. Node name should follow DT
> spec expectations to show the purpose of the node.
> 
> > 
> > I guess the preferred name, per the binding, is to not have multiple
> > 3.3V regulators in your design?
> 
> I don't see what you are proving here. The "vreg" middle name addon is
> not differentiating multiple 3.3V regulators. It changes nothing in the
> problem of this duplication.
> 
> > 
> >>> +		compatible = "regulator-fixed";
> >>> +		regulator-name = "VREG_0P9";
> >>> +
> >>> +		regulator-min-microvolt = <900000>;
> >>> +		regulator-max-microvolt = <900000>;
> >>> +		regulator-always-on;
> >>> +		regulator-boot-on;
> >>> +
> >>> +		vin-supply = <&vreg_3p3>;
> >>> +	};
> >>> +
> >>> +	vreg_1p8: regulator-vreg-1p8 {
> >>> +		compatible = "regulator-fixed";
> >>> +		regulator-name = "VREG_1P8";
> >>> +
> >>> +		regulator-min-microvolt = <1800000>;
> >>> +		regulator-max-microvolt = <1800000>;
> >>> +		regulator-always-on;
> >>> +		regulator-boot-on;
> >>> +
> >>> +		vin-supply = <&vreg_4p2>;
> >>> +	};
> >>> +
> >>> +	vreg_3p3: regulator-vreg-3p3 {
> >>> +		compatible = "regulator-fixed";
> >>> +		regulator-name = "VREG_3P3";
> >>> +
> >>> +		regulator-min-microvolt = <3300000>;
> >>> +		regulator-max-microvolt = <3300000>;
> >>> +		regulator-always-on;
> >>> +		regulator-boot-on;
> >>> +
> >>> +		vin-supply = <&vreg_4p2>;
> >>> +	};
> >>> +
> >>> +	vreg_4p2: regulator-vreg-4p2 {
> >>
> >> Unused node (other dummies don't really count).
> >>
> > 
> > I'm pretty sure this is a direct result of previous review feedback
> > requiring these to be added. I do agree that they don't add any value
> > in a system were we don't control the entire power grid anyways.
> 
> Maybe, I guess, but I am pretty certain none of DT maintainers ever
> asked for such nodes.
> 
> > 
> > 
> > So I presume what you're saying is that we should at most declare one
> > level of non-controlled fixed regulators?
> 
> In general, non-controller fixed regulators should not be there at all,
> except when they serve certain purpose, like fulfill the binding
> requirement. It's their only point.
> 
> And a chain of:
> 
> A -> B -> C -> device
> 
> is completely redundant if all A+B+C are non-controlled.

I think that came from me. I don't consider that to be completely
redundant. It helps in reviews and in some understanding of the board
logic. I'm not asking to implement all the intermediate regulators, but
to implement the meaningful relationship between end-user regulators.


> 
> 
> 
> Best regards,
> Krzysztof

-- 
With best wishes
Dmitry