Message ID | 20240112200750.4062441-2-sboyd@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-25014-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2614:b0:101:6a76:bbe3 with SMTP id mm20csp417047dyc; Fri, 12 Jan 2024 12:15:16 -0800 (PST) X-Google-Smtp-Source: AGHT+IG79lThUOrZJZucGq8rfoDUIyk5K09x4YAmw1RWbWR3ryEmDfuIvUcsGkKZw2K3akHQxosJ X-Received: by 2002:a17:90a:e2d3:b0:28b:16e3:fe71 with SMTP id fr19-20020a17090ae2d300b0028b16e3fe71mr1782914pjb.30.1705090516682; Fri, 12 Jan 2024 12:15:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1705090516; cv=none; d=google.com; s=arc-20160816; b=fV9AfYiFG5ztzf12A+IWwOKIbEdRd9asJWfJpaQdweeiKzgY5MwNohrrC5Tn0SJFxB f+Ry7gyZFPodwsVTqe4nvkDCBm2ltTMMQVX7HCD4dw0ZRFAo9S818jNdG7UCGuZdSrq/ PRP0xLK8M4ubhtbb0Q4rjIgqOR8CAmMpDyzMQjkNwn2CQ02ovYaod0/DbGpGS4HEC5K0 6mJh6YCkyYkl7aaFNSv/0YaiXswfD1Eho5FgPLE2PSPbi+d9OSludznfQIT5dhVs/kFr AQrsdBdFQK2usyysn9a4WtTRXmkbN4pLR158/XnMtrArgePTqCsHzOCQ3bhwcdDEbtGZ V8TQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=CqOU6E/fmILrxzO1+PqTUQ2BhTLfjR8U6sXhToy/ht4=; fh=z5DSQ+Di/n6S5JDKA9oYSYT6aAQl62IgbZZELXMyeNI=; b=Aysxl+CUhLhbGqQrPw9CeC5tOmNG5QtZ4cju4LhEwdRuTv4HB6mmOxMMUt2ulsMNVF IibBJngIRDahHRFwnzC3A95vQ6ftyShLQwWS+XLBXZJ+LjT5kd0PvcPdHuTRd60vDoX7 oubMxQXLO3J3GFU2BJySlKwLKEy5e4V4uYbMkDRUy+TAU6JnlBAPSOZL3/CrsJ7635Bh CyuGf+DeTD6r32KsObX1wS3j5v+U5h7T1uDzS6NmFVWCttp89fa0ocbboqFcrVhWmtOO hzGpCC80Rh+RiGC6tkiCIKH5ruoNWn2sRVYyAQz/mzaDS8Y2EAAST5IbNo88wdtwoDwy zYdQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="nGnzveG/"; spf=pass (google.com: domain of linux-kernel+bounces-25014-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-25014-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id k11-20020a170902694b00b001d5385d7624si3774210plt.65.2024.01.12.12.15.16 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jan 2024 12:15:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-25014-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="nGnzveG/"; spf=pass (google.com: domain of linux-kernel+bounces-25014-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-25014-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id D157D2893C0 for <ouuuleilei@gmail.com>; Fri, 12 Jan 2024 20:08:51 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E938D171D7; Fri, 12 Jan 2024 20:07:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nGnzveG/" 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 4573216419; Fri, 12 Jan 2024 20:07:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6629AC43390; Fri, 12 Jan 2024 20:07:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1705090072; bh=Ftr3BKZw8coGMgoBGEKihNEJ4LajJ+HPG/Va2fa5Q/U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nGnzveG/zSlluWPqK50MsRXFZgcqSqsT+b/j0PKAXVP7ZtdQyKAg1m3guf/d+IBVA 07pgc33Sbuh8cKPwsn4TbkcS4oenSfh3ljankCMJg+3KSR3xYKkq/FmivEMPbadwki Gnq+l6slqsgHmDwxM4NPuJLHDFpi9gubCjnjUfdn8Sxy8LDYoDjOakf6QcAqDVrAdr MDEBQQjx5CgxrWGB2llxj/Yj47M6+dU6XpmzgIP+dv/eye+gmUbhi9gVZJmKU4tJND 6j9+++zKYkaAyoMnCs8uOcZrzTy3AjyU8ipiPD0bw/T6SgAUz0oA+ED7fSzqWiE2Uf xFRtahWLY3/DA== From: Stephen Boyd <sboyd@kernel.org> To: Rob Herring <robh+dt@kernel.org> 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 <frowand.list@gmail.com>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org> Subject: [PATCH 1/6] arm64: Unconditionally call unflatten_device_tree() Date: Fri, 12 Jan 2024 12:07:44 -0800 Message-ID: <20240112200750.4062441-2-sboyd@kernel.org> X-Mailer: git-send-email 2.43.0.275.g3460e3d667-goog In-Reply-To: <20240112200750.4062441-1-sboyd@kernel.org> References: <20240112200750.4062441-1-sboyd@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1787916993547802328 X-GMAIL-MSGID: 1787916993547802328 |
Series |
of: populate of_root node if bootloader doesn't
|
|
Commit Message
Stephen Boyd
Jan. 12, 2024, 8:07 p.m. UTC
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.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: <linux-arm-kernel@lists.infradead.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
---
arch/arm64/kernel/setup.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Comments
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 <robh+dt@kernel.org> > Cc: Frank Rowand <frowand.list@gmail.com> > Cc: Catalin Marinas <catalin.marinas@arm.com> > Cc: Will Deacon <will@kernel.org> > Cc: <linux-arm-kernel@lists.infradead.org> > Signed-off-by: Stephen Boyd <sboyd@kernel.org> > --- > 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 >
Hi Stephen, 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. For better or worse, that's not true: there are systems the provide both a DTB *and* ACPI tables, and we must not consume both at the same time as those can clash and cause all sorts of problems. In addition, we don't want people being "clever" and describing disparate portions of their system in ACPI and DT. It is a very deliberate choice to not unflatten the DTB when ACPI is in use, and I don't think we want to reopen this can of worms. Given that, I'm afraid I must NAK this patch. Thanks Mark. > If there isn't a valid initial_boot_params dtb then unflatten_device_tree() > returns early. > > Cc: Rob Herring <robh+dt@kernel.org> > Cc: Frank Rowand <frowand.list@gmail.com> > Cc: Catalin Marinas <catalin.marinas@arm.com> > Cc: Will Deacon <will@kernel.org> > Cc: <linux-arm-kernel@lists.infradead.org> > Signed-off-by: Stephen Boyd <sboyd@kernel.org> > --- > 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 > >
Hi Mark, On Tue, Jan 16, 2024 at 12:51 PM Mark Rutland <mark.rutland@arm.com> wrote: > 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. > > For better or worse, that's not true: there are systems the provide both a DTB > *and* ACPI tables, and we must not consume both at the same time as those can > clash and cause all sorts of problems. In addition, we don't want people being > "clever" and describing disparate portions of their system in ACPI and DT. We'd get to the latter anyway, when plugging in a USB device where the circuitry on/behind the USB device is described in DT. Gr{oetje,eeting}s, Geert
Quoting Mark Rutland (2024-01-16 03:51:14) > Hi Stephen, > > 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. > > For better or worse, that's not true: there are systems the provide both a DTB > *and* ACPI tables, and we must not consume both at the same time as those can > clash and cause all sorts of problems. In addition, we don't want people being > "clever" and describing disparate portions of their system in ACPI and DT. > > It is a very deliberate choice to not unflatten the DTB when ACPI is in use, > and I don't think we want to reopen this can of worms. Hmm ok. I missed this part. Can we knock out the initial_boot_params in this case so that we don't unflatten a DTB when ACPI is in use?
On Tue, Jan 16, 2024 at 05:27:18PM -0800, Stephen Boyd wrote: > Quoting Mark Rutland (2024-01-16 03:51:14) > > Hi Stephen, > > > > 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. > > > > For better or worse, that's not true: there are systems the provide both a DTB > > *and* ACPI tables, and we must not consume both at the same time as those can > > clash and cause all sorts of problems. In addition, we don't want people being > > "clever" and describing disparate portions of their system in ACPI and DT. > > > > It is a very deliberate choice to not unflatten the DTB when ACPI is in use, > > and I don't think we want to reopen this can of worms. > > Hmm ok. I missed this part. Can we knock out the initial_boot_params in > this case so that we don't unflatten a DTB when ACPI is in use? You mean so we don't unflatten the boot DTB, but instead unflatten the empty one, right? That sounds fine. Another thing to check is kexec because it will still need the original DTB I think. Though if you are doing ACPI boot and kexec'ing, kexec may write out everything needed by the next kernel and the empty DTB would work just fine. Of course those users booting with ACPI and then kexec'ing to DT boot will be broken. Perhaps that's a feature... Rob
Quoting Rob Herring (2024-01-17 09:54:48) > On Tue, Jan 16, 2024 at 05:27:18PM -0800, Stephen Boyd wrote: > > Quoting Mark Rutland (2024-01-16 03:51:14) > > > Hi Stephen, > > > > > > 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. > > > > > > For better or worse, that's not true: there are systems the provide both a DTB > > > *and* ACPI tables, and we must not consume both at the same time as those can > > > clash and cause all sorts of problems. In addition, we don't want people being > > > "clever" and describing disparate portions of their system in ACPI and DT. > > > > > > It is a very deliberate choice to not unflatten the DTB when ACPI is in use, > > > and I don't think we want to reopen this can of worms. > > > > Hmm ok. I missed this part. Can we knock out the initial_boot_params in > > this case so that we don't unflatten a DTB when ACPI is in use? > > You mean so we don't unflatten the boot DTB, but instead unflatten the > empty one, right? That sounds fine. Yes. Note, I don't have any ACPI arm64 system on hand to test anything with :-( > > Another thing to check is kexec because it will still need the original > DTB I think. Though if you are doing ACPI boot and kexec'ing, kexec may > write out everything needed by the next kernel and the empty DTB would > work just fine. Yeah, it looks like dt_is_stub() will keep doing its thing there. The empty DTB will have nothing in it and so kexec with ACPI and the empty DTB will continue to use ACPI, and then the empty DTB will be added in again. > Of course those users booting with ACPI and then > kexec'ing to DT boot will be broken. Perhaps that's a feature... I don't know how this part works. If you kexec to DT boot won't you run through startup again and initial_boot_params will have a non-empty DTB in it? I'd think this would keep working.
On Tue, Jan 16, 2024 at 03:13:42PM +0100, Geert Uytterhoeven wrote: > Hi Mark, > > On Tue, Jan 16, 2024 at 12:51 PM Mark Rutland <mark.rutland@arm.com> wrote: > > 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. > > > > For better or worse, that's not true: there are systems the provide both a DTB > > *and* ACPI tables, and we must not consume both at the same time as those can > > clash and cause all sorts of problems. In addition, we don't want people being > > "clever" and describing disparate portions of their system in ACPI and DT. > > We'd get to the latter anyway, when plugging in a USB device where the > circuitry on/behind the USB device is described in DT. I don't understand what you mean there; where is the DT description of the USB device coming from if the DTB hasn't been unflattened? Mark.
On Tue, Jan 16, 2024 at 05:27:18PM -0800, Stephen Boyd wrote: > Quoting Mark Rutland (2024-01-16 03:51:14) > > Hi Stephen, > > > > 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. > > > > For better or worse, that's not true: there are systems the provide both a DTB > > *and* ACPI tables, and we must not consume both at the same time as those can > > clash and cause all sorts of problems. In addition, we don't want people being > > "clever" and describing disparate portions of their system in ACPI and DT. > > > > It is a very deliberate choice to not unflatten the DTB when ACPI is in use, > > and I don't think we want to reopen this can of worms. > > Hmm ok. I missed this part. Can we knock out the initial_boot_params in > this case so that we don't unflatten a DTB when ACPI is in use? Why is that better than just not calling unflatten_device_tree(), as we do today? The cover letter says this is all so that we can run DT tests for the clk framework; why can't that just depend on the system being booted with DT rather than ACPI? We have other tests which are architecture and/or configuration dependent... Mark.
Hi Mark, On Thu, Jan 18, 2024 at 4:23 PM Mark Rutland <mark.rutland@arm.com> wrote: > On Tue, Jan 16, 2024 at 03:13:42PM +0100, Geert Uytterhoeven wrote: > > On Tue, Jan 16, 2024 at 12:51 PM Mark Rutland <mark.rutland@armcom> wrote: > > > 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. > > > > > > For better or worse, that's not true: there are systems the provide both a DTB > > > *and* ACPI tables, and we must not consume both at the same time as those can > > > clash and cause all sorts of problems. In addition, we don't want people being > > > "clever" and describing disparate portions of their system in ACPI and DT. > > > > We'd get to the latter anyway, when plugging in a USB device where the > > circuitry on/behind the USB device is described in DT. > > I don't understand what you mean there; where is the DT description of the USB > device coming from if the DTB hasn't been unflattened? Either stored in (FLASH) ROM on the USB device, or loaded from /lib/firmware/. In both cases that would be handled by the USB driver for the device. Gr{oetje,eeting}s, Geert
Hi Mark, On Thu, Jan 18, 2024 at 4:27 PM Mark Rutland <mark.rutland@arm.com> wrote: > On Tue, Jan 16, 2024 at 05:27:18PM -0800, Stephen Boyd wrote: > > Quoting Mark Rutland (2024-01-16 03:51:14) > > > 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. > > > > > > For better or worse, that's not true: there are systems the provide both a DTB > > > *and* ACPI tables, and we must not consume both at the same time as those can > > > clash and cause all sorts of problems. In addition, we don't want people being > > > "clever" and describing disparate portions of their system in ACPI and DT. > > > > > > It is a very deliberate choice to not unflatten the DTB when ACPI is in use, > > > and I don't think we want to reopen this can of worms. > > > > Hmm ok. I missed this part. Can we knock out the initial_boot_params in > > this case so that we don't unflatten a DTB when ACPI is in use? > > Why is that better than just not calling unflatten_device_tree(), as we do > today? > > The cover letter says this is all so that we can run DT tests for the clk > framework; why can't that just depend on the system being booted with DT rather > than ACPI? We have other tests which are architecture and/or configuration > dependent... There is definitely a merit in running (platform-independent) DT tests on any platform, whether the platform actually uses DT to boot or not. Gr{oetje,eeting}s, Geert
On Thu, Jan 18, 2024 at 03:26:43PM +0000, Mark Rutland wrote: > On Tue, Jan 16, 2024 at 05:27:18PM -0800, Stephen Boyd wrote: > > Quoting Mark Rutland (2024-01-16 03:51:14) > > > Hi Stephen, > > > > > > 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. > > > > > > For better or worse, that's not true: there are systems the provide both a DTB > > > *and* ACPI tables, and we must not consume both at the same time as those can > > > clash and cause all sorts of problems. In addition, we don't want people being > > > "clever" and describing disparate portions of their system in ACPI and DT. > > > > > > It is a very deliberate choice to not unflatten the DTB when ACPI is in use, > > > and I don't think we want to reopen this can of worms. > > > > Hmm ok. I missed this part. Can we knock out the initial_boot_params in > > this case so that we don't unflatten a DTB when ACPI is in use? > > Why is that better than just not calling unflatten_device_tree(), as we do > today? > > The cover letter says this is all so that we can run DT tests for the clk > framework; why can't that just depend on the system being booted with DT rather > than ACPI? Because then the tests can never run on x86 and some people still use those systems. It's no different than why do we compile !x86 drivers on x86. It is convenient. > We have other tests which are architecture and/or configuration > dependent... There's another usecase of non-discoverable devices behind discoverable devices. See my LPC session slides for more details. For this we will need some base DT to apply overlays to on DT AND ACPI systems. This is what Geert was getting at. Yes, it could be done with some other code path, but the DT unittest has done that hack for years and this series is getting rid of it. Rob
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();