[PATCH v2 0/1] Introduce Monaco EVK Interface Plus Mezzanine

[PATCH v2 0/1] Introduce Monaco EVK Interface Plus Mezzanine

[Umang Chheda]

Introduce device tree support for the Interface Plus [IFP] Mezzanine expansion
card used with the Qualcomm Monaco Evaluation Kit (EVK).

The Monaco IFP Mezzanine is an additional add-on card which can be stacked
on top of monaco-evk board to extend peripheral capabilities of
monaco-evk used for industrial applications.

It connects via expansion headers on the monaco-evk and provides
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 connect M.2 B-key connector for connecting cellular modems.
   - 3rd DSP with support for Dual Ethernet ports.
- EEPROM.
- LVDS Display.
- 2*mini DP.

---
Changelog

v2:
- Change the DT filename to "monaco-evk-ifp-mezzanine.dtso", also
  update commit text and cover letter text to reflect this change - Konrad.
- Remove "status=okay" property from i2c15 node - Bjorn.
- Remove "power-source", "input-disable" and "output-enable" properties
  from tc9563_resx_n node and add "output-high" property instead to
  align with TLMM supported bindings - Bjorn.
- Remove extra '\n' from tc9563_resx_n node - Konrad.
- v1-link: [1]

[1] https://lore.kernel.org/lkml/20260210103821.4169-1-umang.chheda@oss.qualcomm.com/

---

Umang Chheda (1):
  arm64: dts: qcom: monaco-evk: Add Mezzanine

 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

--
2.34.1

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

[Umang Chheda]

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@oss.qualcomm.com> - PCIe
    Monish Chunara <monish.chunara@oss.qualcomm.com> - EEPROM.

Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
 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 {
+		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 {
+		compatible = "regulator-fixed";
+		regulator-name = "VREG_4P2";
+
+		regulator-min-microvolt = <4200000>;
+		regulator-max-microvolt = <4200000>;
+		regulator-always-on;
+		regulator-boot-on;
+
+		vin-supply = <&vreg_sys_pwr>;
+	};
+
+	vreg_sys_pwr: regulator-vreg-sys-pwr {
+		compatible = "regulator-fixed";
+		regulator-name = "VREG_SYS_PWR";
+
+		regulator-min-microvolt = <24000000>;
+		regulator-max-microvolt = <24000000>;
+		regulator-always-on;
+		regulator-boot-on;
+	};
+};
+
+&i2c15 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	eeprom1: eeprom@52 {
+		compatible = "giantec,gt24c256c", "atmel,24c256";
+		reg = <0x52>;
+		pagesize = <64>;
+
+		nvmem-layout {
+			compatible = "fixed-layout";
+			#address-cells = <1>;
+			#size-cells = <1>;
+		};
+	};
+};
+
+&pcie0 {
+	iommu-map = <0x0   &pcie_smmu 0x0 0x1>,
+		    <0x100 &pcie_smmu 0x1 0x1>,
+		    <0x208 &pcie_smmu 0x2 0x1>,
+		    <0x210 &pcie_smmu 0x3 0x1>,
+		    <0x218 &pcie_smmu 0x4 0x1>,
+		    <0x300 &pcie_smmu 0x5 0x1>,
+		    <0x400 &pcie_smmu 0x6 0x1>,
+		    <0x500 &pcie_smmu 0x7 0x1>,
+		    <0x501 &pcie_smmu 0x8 0x1>;
+};
+
+&pcieport0 {
+	#address-cells = <3>;
+	#size-cells = <2>;
+
+	pcie@0,0 {
+		compatible = "pci1179,0623";
+		reg = <0x10000 0x0 0x0 0x0 0x0>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+
+		device_type = "pci";
+		ranges;
+		bus-range = <0x2 0xff>;
+
+		vddc-supply = <&vreg_0p9>;
+		vdd18-supply = <&vreg_1p8>;
+		vdd09-supply = <&vreg_0p9>;
+		vddio1-supply = <&vreg_1p8>;
+		vddio2-supply = <&vreg_1p8>;
+		vddio18-supply = <&vreg_1p8>;
+
+		i2c-parent = <&i2c15 0x77>;
+
+		resx-gpios = <&tlmm 124 GPIO_ACTIVE_LOW>;
+
+		pinctrl-0 = <&tc9563_resx_n>;
+		pinctrl-names = "default";
+
+		pcie@1,0 {
+			reg = <0x20800 0x0 0x0 0x0 0x0>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			device_type = "pci";
+			ranges;
+			bus-range = <0x3 0xff>;
+		};
+
+		pcie@2,0 {
+			reg = <0x21000 0x0 0x0 0x0 0x0>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			device_type = "pci";
+			ranges;
+			bus-range = <0x4 0xff>;
+		};
+
+		pcie@3,0 {
+			reg = <0x21800 0x0 0x0 0x0 0x0>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+			device_type = "pci";
+			ranges;
+			bus-range = <0x5 0xff>;
+
+			pci@0,0 {
+				reg = <0x50000 0x0 0x0 0x0 0x0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				device_type = "pci";
+				ranges;
+			};
+
+			pci@0,1 {
+				reg = <0x50100 0x0 0x0 0x0 0x0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				device_type = "pci";
+				ranges;
+			};
+		};
+	};
+};
+
+&tlmm {
+	tc9563_resx_n: tc9563-resx-state {
+		pins = "gpio124";
+		function = "gpio";
+		bias-disable;
+		output-high;
+	};
+};
--
2.34.1

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

[Dmitry Baryshkov]

On Sun, Feb 22, 2026 at 11:05:45PM +0530, 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.

Nit: routed to? Is that M.2 only suitable for WLANs? What is "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.

If there is an onboard USB hub, please describe it here. Also, what is
the story of mini DP ports? If they are to be enabled later, please
mention, why.

> 
> Written with inputs from :
>     Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> - PCIe
>     Monish Chunara <monish.chunara@oss.qualcomm.com> - EEPROM.
> 
> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
>  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 {

Are all these regulators a part of the mezzanine?

> +		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 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "VREG_4P2";
> +
> +		regulator-min-microvolt = <4200000>;
> +		regulator-max-microvolt = <4200000>;
> +		regulator-always-on;
> +		regulator-boot-on;
> +
> +		vin-supply = <&vreg_sys_pwr>;
> +	};
> +
> +	vreg_sys_pwr: regulator-vreg-sys-pwr {
> +		compatible = "regulator-fixed";
> +		regulator-name = "VREG_SYS_PWR";
> +
> +		regulator-min-microvolt = <24000000>;
> +		regulator-max-microvolt = <24000000>;
> +		regulator-always-on;
> +		regulator-boot-on;

... supplied from what?

> +	};
> +};
> +
> +&i2c15 {
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	eeprom1: eeprom@52 {
> +		compatible = "giantec,gt24c256c", "atmel,24c256";
> +		reg = <0x52>;
> +		pagesize = <64>;
> +
> +		nvmem-layout {
> +			compatible = "fixed-layout";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +		};
> +	};
> +};
> +
> +&pcie0 {
> +	iommu-map = <0x0   &pcie_smmu 0x0 0x1>,
> +		    <0x100 &pcie_smmu 0x1 0x1>,
> +		    <0x208 &pcie_smmu 0x2 0x1>,
> +		    <0x210 &pcie_smmu 0x3 0x1>,
> +		    <0x218 &pcie_smmu 0x4 0x1>,
> +		    <0x300 &pcie_smmu 0x5 0x1>,
> +		    <0x400 &pcie_smmu 0x6 0x1>,
> +		    <0x500 &pcie_smmu 0x7 0x1>,
> +		    <0x501 &pcie_smmu 0x8 0x1>;
> +};
> +
> +&pcieport0 {
> +	#address-cells = <3>;
> +	#size-cells = <2>;
> +
> +	pcie@0,0 {
> +		compatible = "pci1179,0623";
> +		reg = <0x10000 0x0 0x0 0x0 0x0>;
> +		#address-cells = <3>;
> +		#size-cells = <2>;
> +
> +		device_type = "pci";
> +		ranges;
> +		bus-range = <0x2 0xff>;
> +
> +		vddc-supply = <&vreg_0p9>;
> +		vdd18-supply = <&vreg_1p8>;
> +		vdd09-supply = <&vreg_0p9>;
> +		vddio1-supply = <&vreg_1p8>;
> +		vddio2-supply = <&vreg_1p8>;
> +		vddio18-supply = <&vreg_1p8>;
> +
> +		i2c-parent = <&i2c15 0x77>;
> +
> +		resx-gpios = <&tlmm 124 GPIO_ACTIVE_LOW>;
> +
> +		pinctrl-0 = <&tc9563_resx_n>;
> +		pinctrl-names = "default";
> +
> +		pcie@1,0 {
> +			reg = <0x20800 0x0 0x0 0x0 0x0>;
> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +
> +			device_type = "pci";
> +			ranges;
> +			bus-range = <0x3 0xff>;
> +		};
> +
> +		pcie@2,0 {
> +			reg = <0x21000 0x0 0x0 0x0 0x0>;
> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +
> +			device_type = "pci";
> +			ranges;
> +			bus-range = <0x4 0xff>;
> +		};
> +
> +		pcie@3,0 {
> +			reg = <0x21800 0x0 0x0 0x0 0x0>;
> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +			device_type = "pci";
> +			ranges;
> +			bus-range = <0x5 0xff>;
> +
> +			pci@0,0 {
> +				reg = <0x50000 0x0 0x0 0x0 0x0>;
> +				#address-cells = <3>;
> +				#size-cells = <2>;
> +				device_type = "pci";
> +				ranges;
> +			};
> +
> +			pci@0,1 {
> +				reg = <0x50100 0x0 0x0 0x0 0x0>;
> +				#address-cells = <3>;
> +				#size-cells = <2>;
> +				device_type = "pci";
> +				ranges;
> +			};
> +		};
> +	};
> +};
> +
> +&tlmm {
> +	tc9563_resx_n: tc9563-resx-state {
> +		pins = "gpio124";
> +		function = "gpio";
> +		bias-disable;
> +		output-high;
> +	};
> +};
> --
> 2.34.1
> 

-- 
With best wishes
Dmitry

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

[Umang Chheda]

Hello Dmitry,

On 2/22/2026 11:57 PM, Dmitry Baryshkov wrote:
> On Sun, Feb 22, 2026 at 11:05:45PM +0530, 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.
> Nit: routed to? Is that M.2 only suitable for WLANs? What is "WLAN
> endpoints"?

> routed to?
If I understand correctly - you mean change string "connects M.2 E-Key connector" to 
"routed to M.2 E-Key connector" ?
 

> Is that M.2 only suitable for WLANs?
Yes, this is suitable only for the WLAN module.

> What is "WLAN endpoints"?

I Agree this is misleading - will change this to "WLAN module"

>
>>    - 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.
> If there is an onboard USB hub, please describe it here. Also, what is
> the story of mini DP ports? If they are to be enabled later, please
> mention, why.

> If there is an onboard USB hub, please describe it here.

Ack, Since there are no DT changes required to enable USB Hub I did not mention.

will mention it here in the next patch.

> Also, what is the story of mini DP ports?
There is a H/W issue being is being debugged for mini DP ports - Hence did not mention.

> If they are to be enabled later, please mention, why.

Ack

>
>> Written with inputs from :
>>     Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> - PCIe
>>     Monish Chunara <monish.chunara@oss.qualcomm.com> - EEPROM.
>>
>> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>> ---
>>  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 {
> Are all these regulators a part of the mezzanine?
Yes, all these regulators are part of mezzanine board.
>
>> +		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 {
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "VREG_4P2";
>> +
>> +		regulator-min-microvolt = <4200000>;
>> +		regulator-max-microvolt = <4200000>;
>> +		regulator-always-on;
>> +		regulator-boot-on;
>> +
>> +		vin-supply = <&vreg_sys_pwr>;
>> +	};
>> +
>> +	vreg_sys_pwr: regulator-vreg-sys-pwr {
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "VREG_SYS_PWR";
>> +
>> +		regulator-min-microvolt = <24000000>;
>> +		regulator-max-microvolt = <24000000>;
>> +		regulator-always-on;
>> +		regulator-boot-on;
> ... supplied from what?
This regulator is supplied directly from the DC Power adapter.
>
>> +	};
>> +};
>> +
>> +&i2c15 {
>> +	#address-cells = <1>;
>> +	#size-cells = <0>;
>> +
>> +	eeprom1: eeprom@52 {
>> +		compatible = "giantec,gt24c256c", "atmel,24c256";
>> +		reg = <0x52>;
>> +		pagesize = <64>;
>> +
>> +		nvmem-layout {
>> +			compatible = "fixed-layout";
>> +			#address-cells = <1>;
>> +			#size-cells = <1>;
>> +		};
>> +	};
>> +};
>> +
>> +&pcie0 {
>> +	iommu-map = <0x0   &pcie_smmu 0x0 0x1>,
>> +		    <0x100 &pcie_smmu 0x1 0x1>,
>> +		    <0x208 &pcie_smmu 0x2 0x1>,
>> +		    <0x210 &pcie_smmu 0x3 0x1>,
>> +		    <0x218 &pcie_smmu 0x4 0x1>,
>> +		    <0x300 &pcie_smmu 0x5 0x1>,
>> +		    <0x400 &pcie_smmu 0x6 0x1>,
>> +		    <0x500 &pcie_smmu 0x7 0x1>,
>> +		    <0x501 &pcie_smmu 0x8 0x1>;
>> +};
>> +
>> +&pcieport0 {
>> +	#address-cells = <3>;
>> +	#size-cells = <2>;
>> +
>> +	pcie@0,0 {
>> +		compatible = "pci1179,0623";
>> +		reg = <0x10000 0x0 0x0 0x0 0x0>;
>> +		#address-cells = <3>;
>> +		#size-cells = <2>;
>> +
>> +		device_type = "pci";
>> +		ranges;
>> +		bus-range = <0x2 0xff>;
>> +
>> +		vddc-supply = <&vreg_0p9>;
>> +		vdd18-supply = <&vreg_1p8>;
>> +		vdd09-supply = <&vreg_0p9>;
>> +		vddio1-supply = <&vreg_1p8>;
>> +		vddio2-supply = <&vreg_1p8>;
>> +		vddio18-supply = <&vreg_1p8>;
>> +
>> +		i2c-parent = <&i2c15 0x77>;
>> +
>> +		resx-gpios = <&tlmm 124 GPIO_ACTIVE_LOW>;
>> +
>> +		pinctrl-0 = <&tc9563_resx_n>;
>> +		pinctrl-names = "default";
>> +
>> +		pcie@1,0 {
>> +			reg = <0x20800 0x0 0x0 0x0 0x0>;
>> +			#address-cells = <3>;
>> +			#size-cells = <2>;
>> +
>> +			device_type = "pci";
>> +			ranges;
>> +			bus-range = <0x3 0xff>;
>> +		};
>> +
>> +		pcie@2,0 {
>> +			reg = <0x21000 0x0 0x0 0x0 0x0>;
>> +			#address-cells = <3>;
>> +			#size-cells = <2>;
>> +
>> +			device_type = "pci";
>> +			ranges;
>> +			bus-range = <0x4 0xff>;
>> +		};
>> +
>> +		pcie@3,0 {
>> +			reg = <0x21800 0x0 0x0 0x0 0x0>;
>> +			#address-cells = <3>;
>> +			#size-cells = <2>;
>> +			device_type = "pci";
>> +			ranges;
>> +			bus-range = <0x5 0xff>;
>> +
>> +			pci@0,0 {
>> +				reg = <0x50000 0x0 0x0 0x0 0x0>;
>> +				#address-cells = <3>;
>> +				#size-cells = <2>;
>> +				device_type = "pci";
>> +				ranges;
>> +			};
>> +
>> +			pci@0,1 {
>> +				reg = <0x50100 0x0 0x0 0x0 0x0>;
>> +				#address-cells = <3>;
>> +				#size-cells = <2>;
>> +				device_type = "pci";
>> +				ranges;
>> +			};
>> +		};
>> +	};
>> +};
>> +
>> +&tlmm {
>> +	tc9563_resx_n: tc9563-resx-state {
>> +		pins = "gpio124";
>> +		function = "gpio";
>> +		bias-disable;
>> +		output-high;
>> +	};
>> +};
>> --
>> 2.34.1
Thanks,
Umang

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

[Konrad Dybcio]

On 2/23/26 10:47 AM, Umang Chheda wrote:
> Hello Dmitry,
> 
> On 2/22/2026 11:57 PM, Dmitry Baryshkov wrote:
>> On Sun, Feb 22, 2026 at 11:05:45PM +0530, 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.
>> Nit: routed to? Is that M.2 only suitable for WLANs? What is "WLAN
>> endpoints"?
> 
>> routed to?
> If I understand correctly - you mean change string "connects M.2 E-Key connector" to 
> "routed to M.2 E-Key connector" ?
>  
> 
>> Is that M.2 only suitable for WLANs?
> Yes, this is suitable only for the WLAN module.

If I remove that WLAN module and insert an SSD through an adapter, will
the board spontaneously explode?

"intended for" is less ominous..

Konrad

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

[Umang Chheda]

On 2/23/2026 3:29 PM, Konrad Dybcio wrote:
> On 2/23/26 10:47 AM, Umang Chheda wrote:
>> Hello Dmitry,
>>
>> On 2/22/2026 11:57 PM, Dmitry Baryshkov wrote:
>>> On Sun, Feb 22, 2026 at 11:05:45PM +0530, 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.
>>> Nit: routed to? Is that M.2 only suitable for WLANs? What is "WLAN
>>> endpoints"?
>>> routed to?
>> If I understand correctly - you mean change string "connects M.2 E-Key connector" to 
>> "routed to M.2 E-Key connector" ?
>>  
>>
>>> Is that M.2 only suitable for WLANs?
>> Yes, this is suitable only for the WLAN module.
> If I remove that WLAN module and insert an SSD through an adapter, will
> the board spontaneously explode?
>
> "intended for" is less ominous..


Hmm Yes I agree -- will re-phrase the above statement to something like below :

"The first downstream port (DSP) is routed to an M.2 E‑Key connector, intended for WLAN modules.”

>
> Konrad


Thanks,
Umang

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

[Konrad Dybcio]

On 2/23/26 11:36 AM, Umang Chheda wrote:
> 
> On 2/23/2026 3:29 PM, Konrad Dybcio wrote:
>> On 2/23/26 10:47 AM, Umang Chheda wrote:
>>> Hello Dmitry,
>>>
>>> On 2/22/2026 11:57 PM, Dmitry Baryshkov wrote:
>>>> On Sun, Feb 22, 2026 at 11:05:45PM +0530, 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.
>>>> Nit: routed to? Is that M.2 only suitable for WLANs? What is "WLAN
>>>> endpoints"?
>>>> routed to?
>>> If I understand correctly - you mean change string "connects M.2 E-Key connector" to 
>>> "routed to M.2 E-Key connector" ?
>>>  
>>>
>>>> Is that M.2 only suitable for WLANs?
>>> Yes, this is suitable only for the WLAN module.
>> If I remove that WLAN module and insert an SSD through an adapter, will
>> the board spontaneously explode?
>>
>> "intended for" is less ominous..
> 
> 
> Hmm Yes I agree -- will re-phrase the above statement to something like below :
> 
> "The first downstream port (DSP) is routed to an M.2 E‑Key connector, intended for WLAN modules.”

Sounds good, thanks!

Konrad

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

[Dmitry Baryshkov]

On Mon, Feb 23, 2026 at 03:17:11PM +0530, Umang Chheda wrote:
> Hello Dmitry,
> 
> On 2/22/2026 11:57 PM, Dmitry Baryshkov wrote:
> > On Sun, Feb 22, 2026 at 11:05:45PM +0530, 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.
> > Nit: routed to? Is that M.2 only suitable for WLANs? What is "WLAN
> > endpoints"?
> 
> > routed to?
> If I understand correctly - you mean change string "connects M.2 E-Key connector" to 
> "routed to M.2 E-Key connector" ?
>  
> 
> > Is that M.2 only suitable for WLANs?
> Yes, this is suitable only for the WLAN module.
> 
> > What is "WLAN endpoints"?
> 
> I Agree this is misleading - will change this to "WLAN module"
> 
> >
> >>    - 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.
> > If there is an onboard USB hub, please describe it here. Also, what is
> > the story of mini DP ports? If they are to be enabled later, please
> > mention, why.
> 
> > If there is an onboard USB hub, please describe it here.
> 
> Ack, Since there are no DT changes required to enable USB Hub I did not mention.
> 
> will mention it here in the next patch.

That's not what I meant. Please describe the USB hub in DT.

> 
> >> +
> >> +	vreg_0p9: regulator-vreg-0p9 {
> > Are all these regulators a part of the mezzanine?
> Yes, all these regulators are part of mezzanine board.
> >
> >> +		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 {
> >> +		compatible = "regulator-fixed";
> >> +		regulator-name = "VREG_4P2";
> >> +
> >> +		regulator-min-microvolt = <4200000>;
> >> +		regulator-max-microvolt = <4200000>;
> >> +		regulator-always-on;
> >> +		regulator-boot-on;
> >> +
> >> +		vin-supply = <&vreg_sys_pwr>;
> >> +	};
> >> +
> >> +	vreg_sys_pwr: regulator-vreg-sys-pwr {
> >> +		compatible = "regulator-fixed";
> >> +		regulator-name = "VREG_SYS_PWR";
> >> +
> >> +		regulator-min-microvolt = <24000000>;
> >> +		regulator-max-microvolt = <24000000>;
> >> +		regulator-always-on;
> >> +		regulator-boot-on;
> > ... supplied from what?
> This regulator is supplied directly from the DC Power adapter.

Is there a physical regulator which outputs to VREG_SYS_PWR? Is it a
part of the mezzanine?

> >
> >> +
> >> +&tlmm {
> >> +	tc9563_resx_n: tc9563-resx-state {
> >> +		pins = "gpio124";
> >> +		function = "gpio";
> >> +		bias-disable;
> >> +		output-high;

Please add a comment, why is it out high.

> >> +	};
> >> +};
> >> --
> >> 2.34.1
> Thanks,
> Umang

-- 
With best wishes
Dmitry

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

[Umang Chheda]

On 2/24/2026 12:26 AM, Dmitry Baryshkov wrote:
> On Mon, Feb 23, 2026 at 03:17:11PM +0530, Umang Chheda wrote:
>> Hello Dmitry,
>>
>> On 2/22/2026 11:57 PM, Dmitry Baryshkov wrote:
>>> On Sun, Feb 22, 2026 at 11:05:45PM +0530, 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.
>>> Nit: routed to? Is that M.2 only suitable for WLANs? What is "WLAN
>>> endpoints"?
>>> routed to?
>> If I understand correctly - you mean change string "connects M.2 E-Key connector" to 
>> "routed to M.2 E-Key connector" ?
>>  
>>
>>> Is that M.2 only suitable for WLANs?
>> Yes, this is suitable only for the WLAN module.
>>
>>> What is "WLAN endpoints"?
>> I Agree this is misleading - will change this to "WLAN module"
>>
>>>>    - 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.
>>> If there is an onboard USB hub, please describe it here. Also, what is
>>> the story of mini DP ports? If they are to be enabled later, please
>>> mention, why.
>>>  If there is an onboard USB hub, please describe it here.
>> Ack, Since there are no DT changes required to enable USB Hub I did not mention.
>>
>> will mention it here in the next patch.
> That's not what I meant. Please describe the USB hub in DT.


The dependent changes for enabling USB hub on monaco-evk are In-progress and not yet upstreamed

will post the patch to enable USB hub for IFP-mezzanine once it is upstreamed for monaco-evk core-kit.

I will update the commit text of this patch to indicate the same.

>
>>>> +
>>>> +	vreg_0p9: regulator-vreg-0p9 {
>>> Are all these regulators a part of the mezzanine?
>> Yes, all these regulators are part of mezzanine board.
>>>> +		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 {
>>>> +		compatible = "regulator-fixed";
>>>> +		regulator-name = "VREG_4P2";
>>>> +
>>>> +		regulator-min-microvolt = <4200000>;
>>>> +		regulator-max-microvolt = <4200000>;
>>>> +		regulator-always-on;
>>>> +		regulator-boot-on;
>>>> +
>>>> +		vin-supply = <&vreg_sys_pwr>;
>>>> +	};
>>>> +
>>>> +	vreg_sys_pwr: regulator-vreg-sys-pwr {
>>>> +		compatible = "regulator-fixed";
>>>> +		regulator-name = "VREG_SYS_PWR";
>>>> +
>>>> +		regulator-min-microvolt = <24000000>;
>>>> +		regulator-max-microvolt = <24000000>;
>>>> +		regulator-always-on;
>>>> +		regulator-boot-on;
>>> ... supplied from what?
>> This regulator is supplied directly from the DC Power adapter.
> Is there a physical regulator which outputs to VREG_SYS_PWR? Is it a
> part of the mezzanine?


Basically - we have added  VREG_SYS_PWR to describe the DC power input. This is nothing but

the direct 24V DC Power Input and have added this as parent for "vreg_4p2" power supply.

>
>>>> +
>>>> +&tlmm {
>>>> +	tc9563_resx_n: tc9563-resx-state {
>>>> +		pins = "gpio124";
>>>> +		function = "gpio";
>>>> +		bias-disable;
>>>> +		output-high;
> Please add a comment, why is it out high.


Ack

>
>>>> +	};
>>>> +};
>>>> --
>>>> 2.34.1
>> Thanks,
>> Umang


Thanks,
Umang

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

[Krzysztof Kozlowski]

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@oss.qualcomm.com> - PCIe
>     Monish Chunara <monish.chunara@oss.qualcomm.com> - EEPROM.
> 
> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
>  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.

> +		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).

> +		compatible = "regulator-fixed";
> +		regulator-name = "VREG_4P2";
> +
> +		regulator-min-microvolt = <4200000>;
> +		regulator-max-microvolt = <4200000>;
> +		regulator-always-on;
> +		regulator-boot-on;
> +
> +		vin-supply = <&vreg_sys_pwr>;
> +	};
> +
> +	vreg_sys_pwr: regulator-vreg-sys-pwr {

What is the point of this regulator? It is not used by anything (another
dummy is not considered an user).

> +		compatible = "regulator-fixed";
> +		regulator-name = "VREG_SYS_PWR";
> +
> +		regulator-min-microvolt = <24000000>;
> +		regulator-max-microvolt = <24000000>;
> +		regulator-always-on;
> +		regulator-boot-on;
> +	};
> +};
> +


Best regards,
Krzysztof

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

[Bjorn Andersson]

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@oss.qualcomm.com> - PCIe
> >     Monish Chunara <monish.chunara@oss.qualcomm.com> - EEPROM.
> > 
> > Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
> > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > ---
> >  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.

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.

I guess the preferred name, per the binding, is to not have multiple
3.3V regulators in your design?

> > +		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.


So I presume what you're saying is that we should at most declare one
level of non-controlled fixed regulators?

Regards,
Bjorn

> > +		compatible = "regulator-fixed";
> > +		regulator-name = "VREG_4P2";
> > +
> > +		regulator-min-microvolt = <4200000>;
> > +		regulator-max-microvolt = <4200000>;
> > +		regulator-always-on;
> > +		regulator-boot-on;
> > +
> > +		vin-supply = <&vreg_sys_pwr>;
> > +	};
> > +
> > +	vreg_sys_pwr: regulator-vreg-sys-pwr {
> 
> What is the point of this regulator? It is not used by anything (another
> dummy is not considered an user).
> 
> > +		compatible = "regulator-fixed";
> > +		regulator-name = "VREG_SYS_PWR";
> > +
> > +		regulator-min-microvolt = <24000000>;
> > +		regulator-max-microvolt = <24000000>;
> > +		regulator-always-on;
> > +		regulator-boot-on;
> > +	};
> > +};
> > +
> 
> 
> Best regards,
> Krzysztof

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

[Krzysztof Kozlowski]

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@oss.qualcomm.com> - PCIe
>>>     Monish Chunara <monish.chunara@oss.qualcomm.com> - EEPROM.
>>>
>>> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>> ---
>>>  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.




Best regards,
Krzysztof

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@oss.qualcomm.com> - PCIe
> >>>     Monish Chunara <monish.chunara@oss.qualcomm.com> - EEPROM.
> >>>
> >>> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
> >>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> >>> ---
> >>>  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

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

[Krzysztof Kozlowski]

On 23/02/2026 20:02, Dmitry Baryshkov wrote:
>>>
>>> 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.

These are not end-user regulators. These are fixed things which no one
touches and no one needs. There is no single purpose for user-space to
see them.

Why do you not insist on defining all of such external oscilators, rest
of regulators, all possible little ICs?

Best regards,
Krzysztof

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

[Dmitry Baryshkov]

On Mon, Feb 23, 2026 at 09:37:53PM +0100, Krzysztof Kozlowski wrote:
> On 23/02/2026 20:02, Dmitry Baryshkov wrote:
> >>>
> >>> 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.
> 
> These are not end-user regulators. These are fixed things which no one
> touches and no one needs. There is no single purpose for user-space to
> see them.
> 
> Why do you not insist on defining all of such external oscilators, rest
> of regulators, all possible little ICs?

So, where is the boundary from you point of view? Do we define fixed
regulators powering DRM bridges / USB hubs and other similar devices?
Or do we do it only if the bindings require us to do it?


-- 
With best wishes
Dmitry

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

[Umang Chheda]

Hello Krzysztof,

On 2/24/2026 3:39 AM, Dmitry Baryshkov wrote:
> On Mon, Feb 23, 2026 at 09:37:53PM +0100, Krzysztof Kozlowski wrote:
>> On 23/02/2026 20:02, Dmitry Baryshkov wrote:
>>>>> 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.
>> These are not end-user regulators. These are fixed things which no one
>> touches and no one needs. There is no single purpose for user-space to
>> see them.
>>
>> Why do you not insist on defining all of such external oscilators, rest
>> of regulators, all possible little ICs?
> So, where is the boundary from you point of view? Do we define fixed
> regulators powering DRM bridges / USB hubs and other similar devices?
> Or do we do it only if the bindings require us to do it?

Can you help share your point of view on the above query from Dmitry ? In this case to adhere to  bindings requirements

Is it okay if we define fixed regulators like A - > B - > device ? Instead of defining all the intermediate regulators.

>

Thanks,
Umang

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

[Krzysztof Kozlowski]

On 27/02/2026 10:50, Umang Chheda wrote:
> Hello Krzysztof,
> 
> On 2/24/2026 3:39 AM, Dmitry Baryshkov wrote:
>> On Mon, Feb 23, 2026 at 09:37:53PM +0100, Krzysztof Kozlowski wrote:
>>> On 23/02/2026 20:02, Dmitry Baryshkov wrote:
>>>>>> 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.
>>> These are not end-user regulators. These are fixed things which no one
>>> touches and no one needs. There is no single purpose for user-space to
>>> see them.
>>>
>>> Why do you not insist on defining all of such external oscilators, rest
>>> of regulators, all possible little ICs?
>> So, where is the boundary from you point of view? Do we define fixed
>> regulators powering DRM bridges / USB hubs and other similar devices?
>> Or do we do it only if the bindings require us to do it?
> 
> Can you help share your point of view on the above query from Dmitry ? In this case to adhere to  bindings requirements

I already replied in this thread. No point to repeat in multiple places.

Best regards,
Krzysztof

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

[Bjorn Andersson]

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@oss.qualcomm.com> - PCIe
> >>>     Monish Chunara <monish.chunara@oss.qualcomm.com> - EEPROM.
> >>>
> >>> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
> >>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> >>> ---
> >>>  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.
> 

I do agree with it being redundant, but it has provided clear direction
for dts authors of how to construct the node name (take name from
schematics, adopt DT naming rules, prefix it with "regulator-").

> 
> > 
> > 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.
> 

And "purpose" here means "it's a regulator providing 0.9V"?

> > 
> > 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.
> 

I agree on the "vreg" part being redundant, but you're telling us that
all fixed regulators should be named "regulator-[0-9]v[0-9]".

Are you saying that "regulator-edp-3p3", "regulator-misc-3p3", and
"regulator-nvme" (examples from x1-crd.dtsi), should all be named
"regulator-3v3"? Or is your feedback limited to those regulators that
are trivially named in the schematics?

Regards,
Bjorn


> > 
> >>> +		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>;
> >>> +	};

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

[Krzysztof Kozlowski]

On 24/02/2026 05:29, Bjorn Andersson wrote:
>>
>>>
>>> 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.
>>
> 
> And "purpose" here means "it's a regulator providing 0.9V"?

The purpose is regulator, so I was in general in favor of
regulator-[0-9] with the number being index. The convention/schema asks
now for a more specific suffix, which still is just a suffix to
differentiate multiple nodes.

> 
>>>
>>> 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.
>>
> 
> I agree on the "vreg" part being redundant, but you're telling us that
> all fixed regulators should be named "regulator-[0-9]v[0-9]".

Yes, I am fine with some meaningful suffixes.

> 
> Are you saying that "regulator-edp-3p3", "regulator-misc-3p3", and
> "regulator-nvme" (examples from x1-crd.dtsi), should all be named

First, I would not change existing names just to match the convention.
Really not.

Second, this is not the case here. I talk about patch here. The patch
did not need additional suffixes but added the "vreg" useless
suffix/middlefix.

Third, if these are controllable regulators for a new source code, then
they should follow the convention with optional suffix. Whether the
suffix is numerical or name, I don't care.

> "regulator-3v3"? Or is your feedback limited to those regulators that
> are trivially named in the schematics?



Best regards,
Krzysztof

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

[Umang Chheda]

Hello Krzysztof,

On 2/24/2026 12:25 PM, Krzysztof Kozlowski wrote:
> On 24/02/2026 05:29, Bjorn Andersson wrote:
>>>> 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.
>>>
>> And "purpose" here means "it's a regulator providing 0.9V"?
> The purpose is regulator, so I was in general in favor of
> regulator-[0-9] with the number being index. The convention/schema asks
> now for a more specific suffix, which still is just a suffix to
> differentiate multiple nodes.
>
>>>> 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.
>>>
>> I agree on the "vreg" part being redundant, but you're telling us that
>> all fixed regulators should be named "regulator-[0-9]v[0-9]".
> Yes, I am fine with some meaningful suffixes.
>
>> Are you saying that "regulator-edp-3p3", "regulator-misc-3p3", and
>> "regulator-nvme" (examples from x1-crd.dtsi), should all be named
> First, I would not change existing names just to match the convention.
> Really not.
>
> Second, this is not the case here. I talk about patch here. The patch
> did not need additional suffixes but added the "vreg" useless
> suffix/middlefix.
>
> Third, if these are controllable regulators for a new source code, then
> they should follow the convention with optional suffix. Whether the
> suffix is numerical or name, I don't care.


Ack, will change regulator node names as suggested above. Thanks for the feedback.

>
>> "regulator-3v3"? Or is your feedback limited to those regulators that
>> are trivially named in the schematics?
>
>
> Best regards,
> Krzysztof

Thanks,
Umang