From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3BF6DC02199 for ; Fri, 7 Feb 2025 13:32:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type: Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date :Subject:Cc:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=vR4zx2oagS+efqUKCMvK1ATS53EuOoZopH8YM7RNxZc=; b=MCIhKkv4y89qtAxjpK48KzIIET Bou1rbWiqM69zdOhgEEARzRK9QqQX53uCnvWzw4F/+7TOapL4IL217hzYNOb8ReFGzeFm/7FNjJs+ yq2Xof4nJOHwkRstgCIaVsTX6meLjOg7elJcKZPpEF56+ruzWFZmW+8uI4a+npqNotaEVArXOH4C5 UzNukAA0qu/t8JwvvSPDg51cKF8nOO+DW31u5PaMGQ2q/ztzhtTcsmmw05q/EQbMMgjx8LEj0K6he WjGwonOJbgizMC9j0q3qHgucF2sX5CtZFTQMsQu7YQHjKXjQDeql6iIc8s37jbqSEqUAFtB8bqIJk CJVxKVJQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tgOTB-00000009fBf-3bg3; Fri, 07 Feb 2025 13:32:33 +0000 Received: from gloria.sntech.de ([185.11.138.130]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tgOQP-00000009eTf-3rM5; Fri, 07 Feb 2025 13:29:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sntech.de; s=gloria202408; h=Content-Type:Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=vR4zx2oagS+efqUKCMvK1ATS53EuOoZopH8YM7RNxZc=; b=c1tr/tnr9J63Np3nDQff6K5sYk lDzbECFZwUg9b2y0xew+9b3UrLzYEOO6oXoearPTxuMmY1OP7l8As5gHXUojvp9a6rhPXqBVGR7pX ItkLub/6K8cCaeF9t4nwbXN6vTk9HGT0yptexL9sgYCsTnO4HV9sxocFmXogbZ3wWX1nblcEi9rZ/ u5LwAPny7Dza9oe5m4VYVvQlU+asCdfF/wP91b+PYazWHb7sVL52a3XG9LpuEZKCz5LRWSplBUaK3 cBN/P0ffld06H6AQwE0MAMJl9U7rOLG8XbrF/LGIJ+QMFTBC04qalsHbhaVctUr/VlFlmvLXGsv2n 685ABR7Q==; Received: from i53875bc0.versanet.de ([83.135.91.192] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tgOQE-0005vs-AZ; Fri, 07 Feb 2025 14:29:30 +0100 From: Heiko =?UTF-8?B?U3TDvGJuZXI=?= To: Dragan Simic , Quentin Schulz Cc: Quentin Schulz , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Jagan Teki , Niklas Cassel , Michael Riesch , Jonas Karlman , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, Krzysztof Kozlowski Subject: Re: [PATCH v4 3/4] arm64: dts: rockchip: add overlay tests for Rock 5B PCIe overlays Date: Fri, 07 Feb 2025 14:29:29 +0100 Message-ID: <4044639.44csPzL39Z@diego> In-Reply-To: <110a35c5-9450-47fb-9d5f-0ba73e290bf5@cherry.de> References: <20250131-pre-ict-jaguar-v4-0-c971e2852e8d@cherry.de> <110a35c5-9450-47fb-9d5f-0ba73e290bf5@cherry.de> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250207_052941_977297_2D680F93 X-CRM114-Status: GOOD ( 40.03 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Am Donnerstag, 6. Februar 2025, 12:07:21 MEZ schrieb Quentin Schulz: > Hi Dragan, >=20 > On 2/4/25 2:35 PM, Dragan Simic wrote: > > Hello Quentin, > >=20 > > On 2025-02-04 13:20, Quentin Schulz wrote: > >> On 2/4/25 12:22 PM, Dragan Simic wrote: > >>> > On 2025-01-31 11:40, Quentin Schulz wrote: >=20 > Not discussing CONFIG_OF_ALL_DTBS relevancy wrt hiding overlay tests=20 > behind, unrelated to this series I believe :) >=20 > [...] >=20 > >>> With the above-proposed changes in place, and with CONFIG_OF_ALL_DTBS > >>> selected, the relevant part of the "make dtbs" output looks like this: > >>> > >>> DTC arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dtb > >>> DTC arch/arm64/boot/dts/rockchip/rk3588-rock-5b-pcie-ep.dtbo > >>> DTC arch/arm64/boot/dts/rockchip/rk3588-rock-5b-pcie-srns.dtbo > >>> OVL arch/arm64/boot/dts/rockchip/rk3588-rock-5b-pcie-ep.dtb > >>> OVL arch/arm64/boot/dts/rockchip/rk3588-rock-5b-pcie-srns.dtb > >>> > >>> No more "phony targets" in the produced output. :) > >> > >> Funnily enough, I would prefer to see OVL for overlays rather than > >> DTC, but I guess it's just one more occurrence of developers > >> disagreeing on how to name things :) > >=20 > > I actually agree with that, just like I prefer to see .dtbo files > > as additions to dtb-$(CONFIG_ARCH_XYZ). It's all about the overlays, > > so they should be both specified and echoed back. > >=20 > > Moreover, we currently also have additional .dtb files with applied > > overlays left after the build and installed afterwards, which doesn't > > make much sense to me. To me, those additional .dtb files should be > > deleted as build artefacts and not installed. > >=20 >=20 > I **think** it could be useful for systems without overlay support. Then= =20 > you have a dtb which is the result of an overlay applied on top of the=20 > base dtb and you can replace your previous dtb with that one, and voil=C3= =A0. >=20 > What I don't like is that it's difficult to differentiate them from the=20 > "normal" base DTB or even from the DTBO (simple base DTB + overlay test=20 > is usually named after the overlay, and in the case of the Rock 5B test:= =20 > rk3588-rock-5b-pcie-srns.dtbo and=20 > arch/arm64/boot/dts/rockchip/rk3588-rock-5b-pcie-srns.dtb), easy to pick= =20 > the wrong one. Though that is on **me** as I could pick another name for= =20 > the overlay test and e.g. prepend "test-ovl_" to the filename for example. >=20 > [...] >=20 > >> I won't be too difficult to convince here, just want some "authority" > >> or a piece of history about CONFIG_OF_ALL_DTBS that would go your > >> direction, before doing the change. I believe automated build tests > >> without needing to enable a symbol, and that taking DTB and DTBO from > >> the build output and apply DTBO on top of DTB works without having to > >> go through some length to get the symbols, are good reasons to keep it > >> the way it is in this patch series. > >=20 > > I'd like the most to perform the above-proposed "divorcing" of the DT > > overlay tests from CONFIG_OF_ALL_DTBS, so we don't have to enable any > > additional options to have the overlay tests run automatically, but > > to keep .dtbo filenames in dtb-$(CONFIG_ARCH_XYZ). I think that would > > bring the best of both worlds, so to speak. > >=20 >=20 > So, just to recap: >=20 > dtb-$(CONFIG_ARCH_ROCKCHIP) +=3D rk3568-wolfvision-pf5.dtb > dtb-$(CONFIG_ARCH_ROCKCHIP) +=3D rk3568-wolfvision-pf5-display-vz.dtbo > dtb-$(CONFIG_ARCH_ROCKCHIP) +=3D rk3568-wolfvision-pf5-io-expander.dtbo >=20 > stays and I add: >=20 > dtb-$(CONFIG_ARCH_ROCKCHIP) +=3D rk3568-wolfvision-pf5-vz-2-uhd.dtb > rk3568-wolfvision-pf5-vz-2-uhd-dtbs :=3D rk3568-wolfvision-pf5.dtb \ > rk3568-wolfvision-pf5-display-vz.dtbo \ > rk3568-wolfvision-pf5-io-expander.dtbo >=20 > at the bottom of the Makefile. I specifically do NOT want to make this=20 > depend on CONFIG_OF_ALL_DTBS (by using dtb- like in ti/), so that the=20 > base DTB will always have the symbols in, regardless of CONFIG_OF_ALL_DTB= S. >=20 > I think the redundancy is unnecessary but I guess it's worth getting=20 > away from implicit rules. >=20 > I can compromise on that :) >=20 > @Heiko does this work for you? Yes, I do like the variant of _not_ limiting these builds to CONFIG_OF_ALL_DTBS. From reading up on it, it's supposed to build all dtbs - even from non-selected architectures? So on a rockchip-only-build I'd still want to build the dtb+dtbo combination nevertheless. zynq, renesas, qcom and more are doing this like Quentin proposed, where only ti is not.