Message ID | 20240130004508.1700335-2-sboyd@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-43685-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2087:b0:106:209c:c626 with SMTP id gs7csp920364dyb; Mon, 29 Jan 2024 16:46:11 -0800 (PST) X-Google-Smtp-Source: AGHT+IFDq1kJQkA4PFNOY2xcbizmQ41epD+qm5o8kWms9STS+PtGgDbGKBMNzBMqbUnzm2dZaQ9l X-Received: by 2002:a05:6358:882c:b0:178:7954:bc9f with SMTP id hv44-20020a056358882c00b001787954bc9fmr2040796rwb.60.1706575571160; Mon, 29 Jan 2024 16:46:11 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706575571; cv=pass; d=google.com; s=arc-20160816; b=F0VbZV+aVnlkR/qBa6Leq3AWHcncbDxxSiiLNy3k2YqBUWGSIprALuB9A2H7DOH+fP WMkPe7ViGUQRSJdhGP9pVh1x7ststdwydsF4EXN4M+XhuDHCWAq4WsN5rZak2CyXDOcm K3s5M9SfpL9rRAXNNaVZQSuyUoP2ELd+CKm5mDooN/OB76At8rMvIBrehiXlvOW64T94 7QFY9jPMjzSKvu6UHRNWPfEv/KKaD/7K/YZqLKW5qQG5R+1chY2/Cp6kt/AJJEiJc3ii YKapEBDIixBegv5R7CjwTBt1JSYfB0co4hn+/BmNVZr8zUSI9+m14G+K79Hl/vBNQv97 gY7w== ARC-Message-Signature: i=2; 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=4qfvAxKYQwmas7ZTwKJIX5GnmiEr5J1LW/P09XlO4Hw=; fh=9xLTKyG5LLeWwVhC/s1cfm3V7bFxJkLIOBVCvZG8d5Q=; b=cZP3vHSmH96o5gADKQR/y8PfAqXvnkQIrHGqhGJf0ZtK+mIhhmSfLCyeVAIfzZwQHU GjLR/lzs/rlCaNJhgpoCADS+U7D+pR10EUROb4gCpwLR+i/l2wcO8ei5iO5USNSzh8S2 PvpLxK6oGe8KtnvWJsiy4YEg7opkhezFAPxTADF0pNerynrVQTvRE1n1M+6KgzbnNZjm puB8rcNy6e28X1lQ5vV9nBAZZ3tUxp14mK2I8FNrIv18vyN2TXUjIUqiKScusL1+gc2+ PUonnj+eDtlZemyzATKC28xkAXZE959nQH7VD+1c3hBq6efwTawR31r9qdE7SBVyFl/N z4Tg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=HXXuBRXI; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-43685-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-43685-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 f15-20020a65628f000000b005d8b6a84416si4578864pgv.534.2024.01.29.16.46.11 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jan 2024 16:46:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-43685-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=HXXuBRXI; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-43685-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-43685-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 E450A285E9F for <ouuuleilei@gmail.com>; Tue, 30 Jan 2024 00:46:10 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8D65A36AE5; Tue, 30 Jan 2024 00:45:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HXXuBRXI" 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 D2974208C6; Tue, 30 Jan 2024 00:45:11 +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=1706575512; cv=none; b=QIgOTOip6OvZ6L1p+rrvP/PdZI65C6/L8vxpy6aNiSUdm0LvqKFFeZL3b6Z0haXMGNfbAACkIsddwMJMB7/RygScRwo4yBsJ10Pq2PwMQykHk+nD1z5dSk4upI3KV3ONcfvo1dYDwbnv+Rx5ZZUnvzA62qKt/on55F4QEEacRb4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706575512; c=relaxed/simple; bh=VXgzDqWTdPwPLTS+PDtQWtuCy7mpsGpCkHXI8WBQloU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Nhy/rI5rCxedljbzEJRjE7NYdt3h9MO0SknzAP+pLOtDs9JTKGwPcx8xcU79u8ZMS/qO88AQPW5/Bf+pYTX7D8Q0FfYLuQjTHmxfo3Z4eSfXN24dn33dLpEXlzOwb0P/XozLXZn8zL36LWtmeHVURl9JMhJthwaT4zB2IWh3Qdg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HXXuBRXI; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id D15EFC43399; Tue, 30 Jan 2024 00:45:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1706575511; bh=VXgzDqWTdPwPLTS+PDtQWtuCy7mpsGpCkHXI8WBQloU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HXXuBRXIKUnxuty7JtrN6gOE8EGXiTS/vVocrxqVOHD9u8eXJPZNAcWujnPKBxo1e VxixGTBUgU4e8M27QVG7vbXDPLdWyZaI2WBJ0ie6g+nRygM6aoSBqy9s3cPhVrF80A 8e+ipwBOhmcCAq5w1f5FrzEifL/zkRxhhz1IOxIVxIqv/LbCD5pKRoRECjmsxnJtXD sEpg7dYiG5yiHGRPRji5Q1tD2vIC8GqNjBHLc+xPsuJe4rNQHxIBu+qlp+KZuRPmx8 /9ZHH+fgKf7RppPgtpnyzdafGQ5MHgepOcTqIXjk+DAG6R0tsKb3gAD8EnkA9cxhuV v0+sc6RClMpTA== 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>, Mark Rutland <mark.rutland@arm.com> Subject: [PATCH v2 1/7] arm64: Unconditionally call unflatten_device_tree() Date: Mon, 29 Jan 2024 16:45:00 -0800 Message-ID: <20240130004508.1700335-2-sboyd@kernel.org> X-Mailer: git-send-email 2.43.0.429.g432eaa2c6b-goog In-Reply-To: <20240130004508.1700335-1-sboyd@kernel.org> References: <20240130004508.1700335-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: 1789474186112135585 X-GMAIL-MSGID: 1789474186112135585 |
Series |
of: populate of_root node if bootloader doesn't
|
|
Commit Message
Stephen Boyd
Jan. 30, 2024, 12:45 a.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.
Override 'initial_boot_params' to NULL when ACPI is in use but the
bootloader has loaded a DTB so that we don't allow both ACPI and DT to
be used during boot. If there isn't a valid initial_boot_params dtb then
unflatten_device_tree() returns early so this is fine.
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: Mark Rutland <mark.rutland@arm.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
---
arch/arm64/kernel/setup.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
Comments
On Mon, Jan 29, 2024 at 04:45:00PM -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. > Override 'initial_boot_params' to NULL when ACPI is in use but the > bootloader has loaded a DTB so that we don't allow both ACPI and DT to > be used during boot. If there isn't a valid initial_boot_params dtb then > unflatten_device_tree() returns early so this is fine. > > 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: Mark Rutland <mark.rutland@arm.com> > Cc: <linux-arm-kernel@lists.infradead.org> > Signed-off-by: Stephen Boyd <sboyd@kernel.org> > --- > arch/arm64/kernel/setup.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c > index 417a8a86b2db..ffb1942724ae 100644 > --- a/arch/arm64/kernel/setup.c > +++ b/arch/arm64/kernel/setup.c > @@ -351,8 +351,11 @@ 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(); > + /* Don't use the FDT from boot if ACPI is in use */ > + if (!acpi_disabled) > + initial_boot_params = NULL; I still think this is a problem for kexec. See of_kexec_alloc_and_setup_fdt(). You see it uses initial_boot_params. At first glance it looks like it would just write out everything we need. But for UEFI boot, I think we need all the chosen properties like linux,uefi-mmap-start preserved from the current boot for the next kernel we kexec. I think you'll have to check acpi_disabled in unflatten_device_tree() and unflatten the empty tree leaving initial_boot_params alone. That means our FDT and unflattened tree will be different DTs, but I think that's fine. Rob
Quoting Rob Herring (2024-01-31 12:54:05) > On Mon, Jan 29, 2024 at 04:45:00PM -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. > > Override 'initial_boot_params' to NULL when ACPI is in use but the > > bootloader has loaded a DTB so that we don't allow both ACPI and DT to > > be used during boot. If there isn't a valid initial_boot_params dtb then > > unflatten_device_tree() returns early so this is fine. > > > > 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: Mark Rutland <mark.rutland@arm.com> > > Cc: <linux-arm-kernel@lists.infradead.org> > > Signed-off-by: Stephen Boyd <sboyd@kernel.org> > > --- > > arch/arm64/kernel/setup.c | 7 +++++-- > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c > > index 417a8a86b2db..ffb1942724ae 100644 > > --- a/arch/arm64/kernel/setup.c > > +++ b/arch/arm64/kernel/setup.c > > @@ -351,8 +351,11 @@ 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(); > > + /* Don't use the FDT from boot if ACPI is in use */ > > + if (!acpi_disabled) > > + initial_boot_params = NULL; > > I still think this is a problem for kexec. See > of_kexec_alloc_and_setup_fdt(). You see it uses initial_boot_params. At > first glance it looks like it would just write out everything we need. > But for UEFI boot, I think we need all the chosen properties like > linux,uefi-mmap-start preserved from the current boot for the next > kernel we kexec. Ok, got it. > > I think you'll have to check acpi_disabled in unflatten_device_tree() > and unflatten the empty tree leaving initial_boot_params alone. That > means our FDT and unflattened tree will be different DTs, but I think > that's fine. It's sort of scary given that 'initial_boot_params' is an exported global. Maybe that should be hidden away and accessed with a function instead so that this mismatch doesn't break something later on?
On Wed, Jan 31, 2024 at 02:59:53PM -0800, Stephen Boyd wrote: > Quoting Rob Herring (2024-01-31 12:54:05) > > On Mon, Jan 29, 2024 at 04:45:00PM -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. > > > Override 'initial_boot_params' to NULL when ACPI is in use but the > > > bootloader has loaded a DTB so that we don't allow both ACPI and DT to > > > be used during boot. If there isn't a valid initial_boot_params dtb then > > > unflatten_device_tree() returns early so this is fine. > > > > > > 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: Mark Rutland <mark.rutland@arm.com> > > > Cc: <linux-arm-kernel@lists.infradead.org> > > > Signed-off-by: Stephen Boyd <sboyd@kernel.org> > > > --- > > > arch/arm64/kernel/setup.c | 7 +++++-- > > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > > > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c > > > index 417a8a86b2db..ffb1942724ae 100644 > > > --- a/arch/arm64/kernel/setup.c > > > +++ b/arch/arm64/kernel/setup.c > > > @@ -351,8 +351,11 @@ 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(); > > > + /* Don't use the FDT from boot if ACPI is in use */ > > > + if (!acpi_disabled) > > > + initial_boot_params = NULL; > > > > I still think this is a problem for kexec. See > > of_kexec_alloc_and_setup_fdt(). You see it uses initial_boot_params. At > > first glance it looks like it would just write out everything we need. > > But for UEFI boot, I think we need all the chosen properties like > > linux,uefi-mmap-start preserved from the current boot for the next > > kernel we kexec. > > Ok, got it. > > > > > I think you'll have to check acpi_disabled in unflatten_device_tree() > > and unflatten the empty tree leaving initial_boot_params alone. That > > means our FDT and unflattened tree will be different DTs, but I think > > that's fine. > > It's sort of scary given that 'initial_boot_params' is an exported > global. Maybe that should be hidden away and accessed with a function > instead so that this mismatch doesn't break something later on? What you see now is after I did a pass of minimizing the number of users. BTW, I've now got another use for unconditionally calling unflatten_device_tree() with this[1]. Rob [1] https://lore.kernel.org/all/20240201194653.GA1328565-robh@kernel.org/
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c index 417a8a86b2db..ffb1942724ae 100644 --- a/arch/arm64/kernel/setup.c +++ b/arch/arm64/kernel/setup.c @@ -351,8 +351,11 @@ 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(); + /* Don't use the FDT from boot if ACPI is in use */ + if (!acpi_disabled) + initial_boot_params = NULL; + + unflatten_device_tree(); bootmem_init();