Received: by 2002:a05:7208:9594:b0:7e:5202:c8b4 with SMTP id gs20csp2069605rbb; Tue, 27 Feb 2024 09:38:17 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXKZHcemwkdFGQOhvb1/z8OSLZwgFUQAG4IzDIP+c9xY/5W9atniJmvoBy0VnPEcZEZtMXa1zMZBTmtA7nnIhyzZAaQPBLwh14pA/5hsg== X-Google-Smtp-Source: AGHT+IErn/hrkz7LyyjDy8OwAa2sadYDkdv0rvk4PXS0jKMHvwbwTZVjK6jIqy/KNkwQ+0dEHdQ1 X-Received: by 2002:a05:6a20:5519:b0:1a0:cb49:60a0 with SMTP id ko25-20020a056a20551900b001a0cb4960a0mr2040285pzb.36.1709055497673; Tue, 27 Feb 2024 09:38:17 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709055497; cv=pass; d=google.com; s=arc-20160816; b=AiJ1pkxbOh6kX942xKQRqWmtTZa8qAw60KmOe9r9Fbkdw3ElAkRYXuz/0Y9cKaZa96 vg9w1kfP9ihwCszbtvVOL7UIA63LWrXWqcc9D4AIjNnZGAjRe/ShdDvAs9dNSWu7aezR JMSZ2PpU5yLxSVRe1YGVecyexbJJVUpPEbTYxOS/O+ZC3cY0ZQ8H1bxM3uXVPtHxd4Mj ykWDayY14lXrGVCGP21BA9v6d0hfVauNmrpH4WpXIJX48rge0QruPD3Y3vQRNPV9BbuR FdGCacB80HdBVhsw3nYbGza2JjpHjXwsSGGjDPcl52fl26MSJAlqnNEyIID7Jka+94bf rU8w== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:subject:cc:to:from:date; bh=TPKPFDOL+Th5zpWtuhCgNu82ydg+ZTD0lvhOkSebkt4=; fh=V+dpOJMxKN5yGbVkBM1avvC9g68STB08idP72UVk1cE=; b=b6ITZ6gnapR/NCPJa2wvEmr/Ivr2MZQtlQoodKXFFaIa9d4D+mXj/Fy++M3Bg7zIsw f6U8N9EA26dfrTaru33ddHATGcf5TshITRfYZKmZe+p7XYnsMIAzBBbh8b5onIj7nwzI kxqATld8rbacTT2NoP0QZtVP2ynlrtzUkbKCMP/sDEgXyrzqWFWpxBC9JpipPZ22cSwq mDQheFK/ejTNAiy0zfqqAifoldUiQlhNlEvojYCntTjRcwFHisYudAfO16dOH/2ECW9n PBvmYOOJT+weE69uebgXIS68sI6MIQUcyIr2/nbd1SoyowDSEAUH760J9ylbKsBzxP5A 1ymg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-83736-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-83736-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id q13-20020a63e94d000000b005dc89319b58si5674912pgj.682.2024.02.27.09.38.17 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Feb 2024 09:38:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-83736-linux.lists.archive=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; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-83736-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-83736-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com 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 9E81528AB35 for ; Tue, 27 Feb 2024 17:36:29 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D2D144F1E0; Tue, 27 Feb 2024 17:35:08 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A775F4C63D; Tue, 27 Feb 2024 17:35:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709055308; cv=none; b=DdiVwXecPb1BEJKXSCRR5Tey4wsZdmXEy1ImsLELcnclY5aLwLe4kopKXO0lxYGVvXzgylRLj6KSnaeM5fayY6xG0cAWar1XBocuxEA1CPPA9Sy8B0Y1s+XlxmyQdMmwYu7FG1qSFoN0tzcYWOYwr+xIN4bKhWZirGrMcYN5e0U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709055308; c=relaxed/simple; bh=hQ2ryKGeq/r38RlaFN/f0EoXXlr9M7MA/Gh4pDclvGs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JPxDP0Q/IDEwbooYMwHJdaAAsf9oC6PEGWQnIIoD0hBHzPmZCyMpPjaVz62PQPjeCJP9aal/6QVlAXB2OqmD7HqzkKCux080q9tPihuhggZnQ2MQoya+ZrFAgpDro2yNl+W6DIx7Y4526Mpoz97iFCA1XA8/SCMcQ7C3+7g8dvI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 6984ADA7; Tue, 27 Feb 2024 09:35:43 -0800 (PST) Received: from FVFF77S0Q05N.cambridge.arm.com (FVFF77S0Q05N.cambridge.arm.com [10.1.28.137]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DFCFE3F73F; Tue, 27 Feb 2024 09:35:02 -0800 (PST) Date: Tue, 27 Feb 2024 17:34:58 +0000 From: Mark Rutland To: Rob Herring Cc: Will Deacon , Stephen Boyd , 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 Subject: Re: [PATCH v4 5/7] arm64: Unconditionally call unflatten_device_tree() Message-ID: References: <20240217010557.2381548-1-sboyd@kernel.org> <20240217010557.2381548-6-sboyd@kernel.org> <20240223000317.GA3835346-robh@kernel.org> <20240223102345.GA10274@willie-the-truck> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Fri, Feb 23, 2024 at 11:17:02AM -0700, Rob Herring wrote: > On Fri, Feb 23, 2024 at 3:23 AM Will Deacon wrote: > > > > On Thu, Feb 22, 2024 at 05:03:17PM -0700, Rob Herring wrote: > > > On Fri, Feb 16, 2024 at 05:05:54PM -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. > > > > When ACPI is in use, unflatten_device_tree() ignores the > > > > 'initial_boot_params' pointer so the live DT on those systems won't be > > > > whatever that's pointing to. Similarly, when kexec copies the DT data > > > > the previous kernel to the new one on ACPI systems, > > > > of_kexec_alloc_and_setup_fdt() will ignore the live DT (the empty root > > > > one) and copy the 'initial_boot_params' data. > > > > > > > > Cc: Rob Herring > > > > Cc: Frank Rowand > > > > Cc: Catalin Marinas > > > > Cc: Will Deacon > > > > Cc: Mark Rutland > > > > Cc: > > > > Signed-off-by: Stephen Boyd > > > > --- > > > > arch/arm64/kernel/setup.c | 3 +-- > > > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > > > Catalin, Will, Can I get an ack on this so I can take the series via the > > > DT tree. > > > > Mark had strong pretty strong objections to this in version one: > > Yes, I had concerns with it as well. > > > https://lore.kernel.org/all/ZaZtbU9hre3YhZam@FVFF77S0Q05N/ > > > > and this patch looks the same now as it did then. Did something else > > change? > > Yes, that version unflattened the bootloader passed DT. Now within > unflatten_devicetree(), the bootloader DT is ignored if ACPI is > enabled and we unflatten an empty tree. That will prevent the kernel > getting 2 h/w descriptions if/when a platform does such a thing. Also, > kexec still uses the bootloader provided DT as before. That avoids the main instance of my concern, and means that this'll boot without issue, but IIUC this opens the door to dynamically instantiating DT devices atop an ACPI base system, which I think in general is something that's liable to cause more problems than it solves. I understand that's desireable for the selftests, though I still don't believe it's strictly necessary -- there are plenty of other things that only work if the kernel is booted in a specific configuration. Putting the selftests aside, why do we need to do this? Is there any other reason to enable this? Mark.