From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E42D2277029; Mon, 23 Feb 2026 15:37:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771861022; cv=none; b=IDku8i2F/9b9H9O+1mAXa8VsjvUs1sw65BsateY04YBFQubpQAVFukpuC8hogbteFlBwN03PhYVmDnep/vYwZpUKRCvXRgomEJjHNU4pu4HWmZTP6cp7m6x4D2R8JVZR4s8wft05Sddk2woHM/VU1UVQlPuH2VMpR7DAgvzK75k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771861022; c=relaxed/simple; bh=hQ/tWXLIoqCm4fc+NxbTvtv/C3x5RENTRl/CSjZbZhw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=JVaUncEOcewieAoUUbhndLoC7e7muynzPl3F8JZu6BNK3VrSEvw6lr0a60V8VmGTjn4t4uU3YzcoR/kYfiGm2Mcem7lVBKb7tUYaxF4soRCsBIMh8iHHxfS/kHay95sa3YA79rLEIhNPWE2+GMhy9YAk6DVmDnK4nJ02a7N7PjA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nKLJgr+p; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nKLJgr+p" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 98992C116D0; Mon, 23 Feb 2026 15:36:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771861021; bh=hQ/tWXLIoqCm4fc+NxbTvtv/C3x5RENTRl/CSjZbZhw=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=nKLJgr+plbMVllHGKxkdncgg2eQf7VvLFtDUjrwLNRRDUzDDK7Gy6udURC5XeOM3h 9+3MAby9HtF1zm//a3ANUlZcxVwPqw5fQNVy7TxD33sloGzRiGGtYP5T2BoIsdFJOa RfMxtBV7pDi4deX1a1CC5fjOlc5Ig+LP7EjDQzPOzppuXnbnu1SJK1GBq3695aoBbm 6+Wlg1FoEwebNHd4OH87ewGk3Pi62O4IvoDzMD2aZxwnffcjTZMHlTGUPjRC3KPhbI nRPIxCHQ7gDyd9Wit3TaPYV4zvyMxzdfs1EnWRKnVsFBCyUV9aWYsR3eo1AP3EAzf1 LWs+gvv2Arptw== Message-ID: <87e3de23-cee9-4789-87ca-e85826af7760@kernel.org> Date: Mon, 23 Feb 2026 16:36:56 +0100 Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/1] arm64: dts: qcom: monaco-evk: Add Interface Plus Mezzanine To: Bjorn Andersson Cc: Umang Chheda , konradybcio@kernel.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, richardcochran@gmail.com, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, mohd.anwar@oss.qualcomm.com, krishna.chundru@oss.qualcomm.com, monish.chunara@oss.qualcomm.com, Dmitry Baryshkov References: <20260222173545.3627478-1-umang.chheda@oss.qualcomm.com> <20260222173545.3627478-2-umang.chheda@oss.qualcomm.com> From: Krzysztof Kozlowski Content-Language: en-US Autocrypt: addr=krzk@kernel.org; keydata= xsFNBFVDQq4BEAC6KeLOfFsAvFMBsrCrJ2bCalhPv5+KQF2PS2+iwZI8BpRZoV+Bd5kWvN79 cFgcqTTuNHjAvxtUG8pQgGTHAObYs6xeYJtjUH0ZX6ndJ33FJYf5V3yXqqjcZ30FgHzJCFUu JMp7PSyMPzpUXfU12yfcRYVEMQrmplNZssmYhiTeVicuOOypWugZKVLGNm0IweVCaZ/DJDIH gNbpvVwjcKYrx85m9cBVEBUGaQP6AT7qlVCkrf50v8bofSIyVa2xmubbAwwFA1oxoOusjPIE J3iadrwpFvsZjF5uHAKS+7wHLoW9hVzOnLbX6ajk5Hf8Pb1m+VH/E8bPBNNYKkfTtypTDUCj NYcd27tjnXfG+SDs/EXNUAIRefCyvaRG7oRYF3Ec+2RgQDRnmmjCjoQNbFrJvJkFHlPeHaeS BosGY+XWKydnmsfY7SSnjAzLUGAFhLd/XDVpb1Een2XucPpKvt9ORF+48gy12FA5GduRLhQU vK4tU7ojoem/G23PcowM1CwPurC8sAVsQb9KmwTGh7rVz3ks3w/zfGBy3+WmLg++C2Wct6nM Pd8/6CBVjEWqD06/RjI2AnjIq5fSEH/BIfXXfC68nMp9BZoy3So4ZsbOlBmtAPvMYX6U8VwD TNeBxJu5Ex0Izf1NV9CzC3nNaFUYOY8KfN01X5SExAoVTr09ewARAQABzSVLcnp5c3p0b2Yg S296bG93c2tpIDxrcnprQGtlcm5lbC5vcmc+wsGVBBMBCgA/AhsDBgsJCAcDAgYVCAIJCgsE FgIDAQIeAQIXgBYhBJvQfg4MUfjVlne3VBuTQ307QWKbBQJoF1BKBQkWlnSaAAoJEBuTQ307 QWKbHukP/3t4tRp/bvDnxJfmNdNVn0gv9ep3L39IntPalBFwRKytqeQkzAju0whYWg+R/rwp +r2I1Fzwt7+PTjsnMFlh1AZxGDmP5MFkzVsMnfX1lGiXhYSOMP97XL6R1QSXxaWOpGNCDaUl ajorB0lJDcC0q3xAdwzRConxYVhlgmTrRiD8oLlSCD5baEAt5Zw17UTNDnDGmZQKR0fqLpWy 786Lm5OScb7DjEgcA2PRm17st4UQ1kF0rQHokVaotxRM74PPDB8bCsunlghJl1DRK9s1aSuN hL1Pv9VD8b4dFNvCo7b4hfAANPU67W40AaaGZ3UAfmw+1MYyo4QuAZGKzaP2ukbdCD/DYnqi tJy88XqWtyb4UQWKNoQqGKzlYXdKsldYqrLHGoMvj1UN9XcRtXHST/IaLn72o7j7/h/Ac5EL 8lSUVIG4TYn59NyxxAXa07Wi6zjVL1U11fTnFmE29ALYQEXKBI3KUO1A3p4sQWzU7uRmbuxn naUmm8RbpMcOfa9JjlXCLmQ5IP7Rr5tYZUCkZz08LIfF8UMXwH7OOEX87Y++EkAB+pzKZNNd hwoXulTAgjSy+OiaLtuCys9VdXLZ3Zy314azaCU3BoWgaMV0eAW/+gprWMXQM1lrlzvwlD/k whyy9wGf0AEPpLssLVt9VVxNjo6BIkt6d1pMg6mHsUEVzsFNBFVDXDQBEADNkrQYSREUL4D3 Gws46JEoZ9HEQOKtkrwjrzlw/tCmqVzERRPvz2Xg8n7+HRCrgqnodIYoUh5WsU84N03KlLue MNsWLJBvBaubYN4JuJIdRr4dS4oyF1/fQAQPHh8Thpiz0SAZFx6iWKB7Qrz3OrGCjTPcW6ei OMheesVS5hxietSmlin+SilmIAPZHx7n242u6kdHOh+/SyLImKn/dh9RzatVpUKbv34eP1wA GldWsRxbf3WP9pFNObSzI/Bo3kA89Xx2rO2roC+Gq4LeHvo7ptzcLcrqaHUAcZ3CgFG88CnA 6z6lBZn0WyewEcPOPdcUB2Q7D/NiUY+HDiV99rAYPJztjeTrBSTnHeSBPb+qn5ZZGQwIdUW9 YegxWKvXXHTwB5eMzo/RB6vffwqcnHDoe0q7VgzRRZJwpi6aMIXLfeWZ5Wrwaw2zldFuO4Dt 91pFzBSOIpeMtfgb/Pfe/a1WJ/GgaIRIBE+NUqckM+3zJHGmVPqJP/h2Iwv6nw8U+7Yyl6gU BLHFTg2hYnLFJI4Xjg+AX1hHFVKmvl3VBHIsBv0oDcsQWXqY+NaFahT0lRPjYtrTa1v3tem/ JoFzZ4B0p27K+qQCF2R96hVvuEyjzBmdq2esyE6zIqftdo4MOJho8uctOiWbwNNq2U9pPWmu 4vXVFBYIGmpyNPYzRm0QPwARAQABwsF8BBgBCgAmAhsMFiEEm9B+DgxR+NWWd7dUG5NDfTtB YpsFAmgXUF8FCRaWWyoACgkQG5NDfTtBYptO0w//dlXJs5/42hAXKsk+PDg3wyEFb4NpyA1v qmx7SfAzk9Hf6lWwU1O6AbqNMbh6PjEwadKUk1m04S7EjdQLsj/MBSgoQtCT3MDmWUUtHZd5 RYIPnPq3WVB47GtuO6/u375tsxhtf7vt95QSYJwCB+ZUgo4T+FV4hquZ4AsRkbgavtIzQisg Dgv76tnEv3YHV8Jn9mi/Bu0FURF+5kpdMfgo1sq6RXNQ//TVf8yFgRtTUdXxW/qHjlYURrm2 H4kutobVEIxiyu6m05q3e9eZB/TaMMNVORx+1kM3j7f0rwtEYUFzY1ygQfpcMDPl7pRYoJjB dSsm0ZuzDaCwaxg2t8hqQJBzJCezTOIkjHUsWAK+tEbU4Z4SnNpCyM3fBqsgYdJxjyC/tWVT AQ18NRLtPw7tK1rdcwCl0GFQHwSwk5pDpz1NH40e6lU+NcXSeiqkDDRkHlftKPV/dV+lQXiu jWt87ecuHlpL3uuQ0ZZNWqHgZoQLXoqC2ZV5KrtKWb/jyiFX/sxSrodALf0zf+tfHv0FZWT2 zHjUqd0t4njD/UOsuIMOQn4Ig0SdivYPfZukb5cdasKJukG1NOpbW7yRNivaCnfZz6dTawXw XRIV/KDsHQiyVxKvN73bThKhONkcX2LWuD928tAR6XMM2G5ovxLe09vuOzzfTWQDsm++9UKF a/A= In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 - PCIe >>> Monish Chunara - EEPROM. >>> >>> Signed-off-by: Umang Chheda >>> Reviewed-by: Dmitry Baryshkov >>> --- >>> 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 >>> + >>> +&{/} { >>> + 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