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 EFD04C433F5 for ; Wed, 19 Jan 2022 12:04:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tSxsaWbgdZ259/mAFucSCENjOJyBfHyDo4OSxfzavGc=; b=n2rKW993q6Q4aY Uh3DkPpD6S02kLfKfbCBohIEquMbfhbrtmp8jGbE9qwkpUOA8HSqrFxtLl0osxHIGPDv5hOyB2VGc 1qaIB93gJX0sqKRPmfRQyEkM+36q4yxAhb3Sy02/0muEmbFdVrI1W+Ke1jclyMHFP1LF/T9jVw/Lc P83XiufezxLwsOUI68+3GS+MSVNTGfO50lWjozw2netqr5L9EoHYRi05Uw3goLlOsyajzgZXxMCGJ hGTL7JObLps/gCchg1QNH18aJ9JDdrzg3LljaB67LDUCP75j4PN5OW0RdBpjcE2JMYXHZ0sKX29h+ 46gNQjluKyNtHyzSCLcw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nA9fq-005Iex-UU; Wed, 19 Jan 2022 12:02:47 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nA9fm-005IeI-MN for linux-arm-kernel@lists.infradead.org; Wed, 19 Jan 2022 12:02:44 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E39FDED1; Wed, 19 Jan 2022 04:02:41 -0800 (PST) Received: from FVFF77S0Q05N (unknown [10.57.3.112]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0A64D3F73D; Wed, 19 Jan 2022 04:02:40 -0800 (PST) Date: Wed, 19 Jan 2022 12:02:38 +0000 From: Mark Rutland To: Andre Przywara Cc: Vladimir Murzin , linux-arm-kernel@lists.infradead.org, Jaxson Han Subject: Re: [boot-wrapper PATCH v2 9/9] avoid dtc warnings on re-compiling DTB Message-ID: References: <20211222181607.1203191-1-andre.przywara@arm.com> <20211222181607.1203191-10-andre.przywara@arm.com> <706471d8-a0fd-35fb-4fa0-380bfb1b78e7@arm.com> <20220113195051.7100b066@slackpad.fritz.box> <9eb63797-b313-a39a-6b9c-0f8ac447b85a@arm.com> <20220114120931.36488dfe@donnerap.cambridge.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220114120931.36488dfe@donnerap.cambridge.arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220119_040242_852496_8B58AAB1 X-CRM114-Status: GOOD ( 43.72 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jan 14, 2022 at 12:09:31PM +0000, Andre Przywara wrote: > On Fri, 14 Jan 2022 10:44:55 +0000 > Mark Rutland wrote: > > > On Fri, Jan 14, 2022 at 08:35:06AM +0000, Vladimir Murzin wrote: > > > Hi Andre, > > > > > > On 1/13/22 7:50 PM, Andre Przywara wrote: > > > > On Thu, 13 Jan 2022 18:42:50 +0000 > > > > Vladimir Murzin wrote: > > > > > > > > Hi Vladimir, > > > > > > > >> On 12/22/21 6:16 PM, Andre Przywara wrote: > > > >>> When we add the PSCI nodes to the provided DTB, we use dtc to de-compile > > > >>> the blob first, then re-compile it with our nodes and properties added. > > > >>> > > > >>> In our input DTB the proper phandle references have already been lost, > > > >>> all we see in the DTB is phandle properties in the target node, and some > > > >>> numbers in the clocks and gpios properties: > > > >>> =========== > > > >>> clk24mhz { > > > >>> compatible = "fixed-clock"; > > > >>> #clock-cells = <0x00>; > > > >>> clock-frequency = <0x16e3600>; > > > >>> clock-output-names = "v2m:clk24mhz"; > > > >>> -> phandle = <0x05>; > > > >>> }; > > > >>> ... > > > >>> serial@90000 { > > > >>> compatible = "arm,pl011", "arm,primecell"; > > > >>> reg = <0x90000 0x1000>; > > > >>> interrupts = <0x05>; > > > >>> -> clocks = <0x05 0x05>; > > > >>> clock-names = "uartclk", "apb_pclk"; > > > >>> }; > > > >>> =========== > > > >>> dtc warns that those numbers might be wrong: > > > >>> ========= > > > >>> :177.6-27: Warning (clocks_property): > > > >>> /bus@8000000/motherboard-bus@8000000/iofpga-bus@300000000/serial@90000: > > > >>> clocks: cell 0 is not a phandle reference > > > >>> .... > > > >>> ========= > > > >>> The proper solution would be to use references (&v2m_clk24mhz) instead, > > > >>> as there are in the source .dts file, but we don't have that information > > > >>> anymore, and cannot easily recover it. > > > >>> > > > >>> To avoid the lengthy list of warnings, just drop those checks from the > > > >>> dtc compilation run. This disables more checks than we want or need, but > > > >>> we somewhat trust in the original DTB to be sane, so that should be > > > >>> fine. > > > >>> > > > >>> Signed-off-by: Andre Przywara > > > >>> --- > > > >>> Makefile.am | 2 +- > > > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > > > >>> > > > >>> diff --git a/Makefile.am b/Makefile.am > > > >>> index 3d8128f..430b4a9 100644 > > > >>> --- a/Makefile.am > > > >>> +++ b/Makefile.am > > > >>> @@ -160,7 +160,7 @@ model.lds: $(LD_SCRIPT) Makefile > > > >>> $(CPP) $(CPPFLAGS) -ansi -DPHYS_OFFSET=$(PHYS_OFFSET) -DMBOX_OFFSET=$(MBOX_OFFSET) -DKERNEL_OFFSET=$(KERNEL_OFFSET) -DFDT_OFFSET=$(FDT_OFFSET) -DFS_OFFSET=$(FS_OFFSET) $(XEN) -DXEN_OFFSET=$(XEN_OFFSET) -DKERNEL=$(KERNEL_IMAGE) -DFILESYSTEM=$(FILESYSTEM) -DTEXT_LIMIT=$(TEXT_LIMIT) -P -C -o $@ $< > > > >>> > > > >>> fdt.dtb: $(KERNEL_DTB) Makefile > > > >>> - ( $(DTC) -O dts -I dtb $(KERNEL_DTB) ; echo "/ { $(CHOSEN_NODE) $(PSCI_NODE) }; $(CPU_NODES)" ) | $(DTC) -O dtb -o $@ - > > > >>> + ( $(DTC) -O dts -I dtb $(KERNEL_DTB) ; echo "/ { $(CHOSEN_NODE) $(PSCI_NODE) }; $(CPU_NODES)" ) | $(DTC) -O dtb -o $@ -Wno-clocks_property -Wno-gpios_property - > > > >>> > > > >>> # The filesystem archive might not exist if INITRD is not being used > > > >>> .PHONY: all clean $(FILESYSTEM) > > > >>> > > > >> > > > >> dtc 1.4.1 complains > > > > > > > > Which distro ships this version? (distrowatch doesn't list dtc) > > > > > > > > tag v1.4.1 > > > > Tagger: David Gibson > > > > Date: Wed Nov 12 14:31:44 2014 +1100 > > > > > > > > Any chance it's just you and you can update this? It looks like the > > > > first version to support it is 1.4.5, as shipped for instance with > > > > Ubuntu 18.04. > > > > > > It is shipped as LSF module. I can try to ask for an update, but I thought > > > that other people may run into it as well... > > > > > > > > > > >> FATAL ERROR: Unrecognized check name "clocks_property" > > > > > > > > Sigh, thanks for the heads up. I don't know if we want to blow up the > > > > Makefile with a feature test? > > > > > > I dunno, TBH. It look like warning used to be less evil than error... > > Yeah, that's what I meant: Either revert it or extend the Makefile. > > > I agree. > > > > My preference would be to revert that for now, and consider the problem afresh. > > Andre, are you ok with that? > > Sure, I don't want to break the build for people. > I think kvmtool has some lightweight feature tests in its Makefile, I can > try to steal some of it, and see how evil it looks. Or wait for half a > year to see those older dtcs flushed out and try it again ;-) FWIW, the feature test idea doesn't sound bad, though I beleive that for licensing reasons we cannot take that from kvmtool and would have to grow our own. Another option would be to extend FDT.pm to do the manipulation and drop the dtc dependency entirely. That would require more work, but might make it easier to do other DTB manipulation in future. For now I've applied a revert, with a link to this thread and some wording that we can reconsider this in future. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel