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 43750C47258 for ; Mon, 15 Jan 2024 17:57:49 +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=WOi6XOxgkN8IuE5oe2XmSzTz2kMEZb/qY+hFlJxK9WM=; b=ke2LdRQ4f19G6m lANFN2OKpM8p85roSxNoOFa9wuMemB7Y2IRPzihEQySX8H4fmBi91QuaAs5ajzxO6M+bsIrnJZf0X 3e0V96Q99JHcKuA3q0U96GoXz9WJocdcpVSG/XkMZa/6fz6hijz7tXNiMbT/hxlf7jNNV3exfuzAH /LYPaZE6fv/SFSD920MfzWeT2Ip45ADVYK7ohJlRHXGCNbflEgl3IDMwDX7432S/afsPgKU4e5h9u CM2yztntqSaXMchCi427WnaIsZDdhKaSahH+MZ5XJErDJHysFxrvlE0XY+P4qH87b+ukswFQTKNS6 FMlqCcLWqhRB53GFNQYg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rPRDD-009rSu-2A; Mon, 15 Jan 2024 17:57:27 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rPRDA-009rRI-01; Mon, 15 Jan 2024 17:57:26 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 7B7CC60FAB; Mon, 15 Jan 2024 17:57:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E7B96C433C7; Mon, 15 Jan 2024 17:57:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1705341443; bh=thBhnHt9jZFGQePPNqkyQjdjPMKZmxdsMlzWKPj8+Jc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=p35Gl/yrY53OdCBI06PlYbOCPu8PAdffbIyGPu1B+JJ8LCI4uLoO8zCBoPhEbZDLS 2IuoXD/t8k77ozhb8mPOLhbNFyEP4GY8mx1XWU4y7yBIbDXxNC5TLZcXn4YQydXZb+ ihr5kYCGinap2g3Ra56/Q9Wdrh9KoWNBTljTqqTGVPXMUstYfVTqYHhmmbvqbuBaqQ R0D0wrr1HgN2cQjEjJrRRpn7IK2XvNg/wtd9MvHtZWsxwRCZJ8BWJdfLf157zF8Ife iEtCOl9+pCW2cWVL5OumkEzSAdDC5KxaFB7NfQJIEp+JhKI5bT6ZCPEyvbkuFrYfyK obT1KF8SeUyhQ== Date: Mon, 15 Jan 2024 11:57:20 -0600 From: Rob Herring To: Stephen Boyd Cc: linux-kernel@vger.kernel.org, patches@lists.linux.dev, linux-um@lists.infradead.org, linux-arm-kernel@lists.infradead.org, kunit-dev@googlegroups.com, linux-kselftest@vger.kernel.org, devicetree@vger.kernel.org, Frank Rowand , Catalin Marinas , Will Deacon Subject: Re: [PATCH 1/6] arm64: Unconditionally call unflatten_device_tree() Message-ID: <20240115175720.GA1017185-robh@kernel.org> References: <20240112200750.4062441-1-sboyd@kernel.org> <20240112200750.4062441-2-sboyd@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240112200750.4062441-2-sboyd@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240115_095724_120344_FD7C7157 X-CRM114-Status: GOOD ( 17.05 ) 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 12, 2024 at 12:07:44PM -0800, Stephen Boyd wrote: > Call this function unconditionally so that we can populate an empty DTB > on platforms that don't boot with a firmware provided or builtin DTB. > There's no harm in calling unflatten_device_tree() unconditionally. If > there isn't a valid initial_boot_params dtb then unflatten_device_tree() > returns early. There's always a valid DTB because that's the boot params even for ACPI systems. This does also create a userspace visible change that /proc/device-tree will be populated. I don't see an issue with that. There was worry when ACPI was added that systems would pass both DT and ACPI tables and that the kernel must only use ACPI. That was more to force ACPI adoption, but I'm not sure if that actually exists in any early system. I think we're past forcing adoption now. > Cc: Rob Herring > Cc: Frank Rowand > Cc: Catalin Marinas > Cc: Will Deacon > Cc: > Signed-off-by: Stephen Boyd > --- > arch/arm64/kernel/setup.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c > index 417a8a86b2db..ede3d59dabf0 100644 > --- a/arch/arm64/kernel/setup.c > +++ b/arch/arm64/kernel/setup.c > @@ -351,8 +351,7 @@ void __init __no_sanitize_address setup_arch(char **cmdline_p) > /* Parse the ACPI tables for possible boot-time configuration */ > acpi_boot_table_init(); > > - if (acpi_disabled) > - unflatten_device_tree(); > + unflatten_device_tree(); > > bootmem_init(); > > -- > https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/ > https://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi.git > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel