linux-kselftest.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Boyd <sboyd@kernel.org>,
	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: Re: [PATCH 1/6] arm64: Unconditionally call unflatten_device_tree()
Date: Fri, 19 Jan 2024 17:10:36 -0600	[thread overview]
Message-ID: <20240119231036.GA1247053-robh@kernel.org> (raw)
In-Reply-To: <ZalDM90KoQ2Il0j7@FVFF77S0Q05N.cambridge.arm.com>

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

  parent reply	other threads:[~2024-01-19 23:10 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-12 20:07 [PATCH 0/6] of: populate of_root node if bootloader doesn't Stephen Boyd
2024-01-12 20:07 ` [PATCH 1/6] arm64: Unconditionally call unflatten_device_tree() Stephen Boyd
2024-01-15 17:57   ` Rob Herring
2024-01-16 11:51   ` Mark Rutland
2024-01-16 14:13     ` Geert Uytterhoeven
2024-01-18 15:23       ` Mark Rutland
2024-01-18 16:22         ` Geert Uytterhoeven
2024-01-17  1:27     ` Stephen Boyd
2024-01-17 17:54       ` Rob Herring
2024-01-17 23:00         ` Stephen Boyd
2024-01-18 15:26       ` Mark Rutland
2024-01-18 16:23         ` Geert Uytterhoeven
2024-01-19 23:10         ` Rob Herring [this message]
2024-01-12 20:07 ` [PATCH 2/6] um: " Stephen Boyd
2024-01-12 20:07 ` [PATCH 3/6] of: Always unflatten in unflatten_and_copy_device_tree() Stephen Boyd
2024-01-12 20:07 ` [PATCH 4/6] of: Create of_root if no dtb provided by firmware Stephen Boyd
2024-01-15 20:32   ` Rob Herring
2024-01-17  1:18     ` Stephen Boyd
2024-01-17 17:41       ` Rob Herring
2024-01-18  8:45         ` Geert Uytterhoeven
2024-01-18 13:44           ` Rob Herring
2024-01-12 20:07 ` [PATCH 5/6] of: unittest: treat missing of_root as error instead of fixing up Stephen Boyd
2024-01-12 20:07 ` [PATCH 6/6] of: Add KUnit test to confirm DTB is loaded Stephen Boyd
2024-01-16  5:03   ` David Gow
2024-01-22 22:48     ` Stephen Boyd
2024-01-24  7:25       ` David Gow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240119231036.GA1247053-robh@kernel.org \
    --to=robh@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-um@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=patches@lists.linux.dev \
    --cc=sboyd@kernel.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).