Message-ID: <20240307160940.6484ef8d@bootlin.com>
Date: Thu, 7 Mar 2024 16:09:40 +0100
From: Herve Codina <herve.codina@...tlin.com>
To: Rob Herring <robh@...nel.org>
Cc: Mark Rutland <mark.rutland@....com>, Will Deacon <will@...nel.org>,
 Stephen Boyd <sboyd@...nel.org>, linux-kernel@...r.kernel.org,
 patches@...ts.linux.dev, linux-um@...ts.infradead.org,
 linux-arm-kernel@...ts.infradead.org, kunit-dev@...glegroups.com,
 linux-kselftest@...r.kernel.org, devicetree@...r.kernel.org, Frank Rowand
 <frowand.list@...il.com>, Catalin Marinas <catalin.marinas@....com>, Thomas
 Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v4 5/7] arm64: Unconditionally call
 unflatten_device_tree()

Hi,

On Wed, 28 Feb 2024 10:26:47 -0600
Rob Herring <robh@...nel.org> wrote:

..
> > > 
> > > 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.  
> 
> Why add to the test matrix if we don't have to?
> 
> > Putting the selftests aside, why do we need to do this? Is there any other
> > reason to enable this?  
> 
> See my Plumbers talk...
> 
> Or in short, there's 3 main usecases:
> 
> - PCI FPGA card with devices instantiated in it 
> - SoCs which expose their peripherals via a PCI endpoint.
> - Injecting test devices with QEMU (testing, but not what this series 
>   does. Jonathan Cameron's usecase)
> 
> In all cases, drivers already exist for the devices, and they often only 
> support DT. DT overlays is the natural solution for this, and there's 
> now kernel support for it (dynamically generating PCI DT nodes when they 
> don't exist). The intent is to do the same thing on ACPI systems.
> 
> I don't see another solution other than 'go away, you're crazy'. There's 
> ACPI overlays, but that's only a debug feature. Also, that would 
> encourage more of the DT bindings in ACPI which I find worse than this 
> mixture. There's swnodes, but that's just board files and platform_data 
> 2.0.
> 
> I share the concerns with mixing, but I don't see a better solution. The 
> scope of what's possible is contained enough to avoid issues.
> 

I tested on a x86 system.
My use case is 'SoCs which expose their peripherals via a PCI endpoint'
described by Rob.
Indeed, I have a Microchip Lan9662 board (the one mentioned by Rob in his
Plumbers talk) and the root DT node creation is obviously needed.

I have previously used Frank Rowan's patches [1] that did this DT root node
creation. This series perfectly replace them and the root DT node is successfully
created.

Tested-by: Herve Codina <herve.codina@...tlin.com>

[1]: https://lore.kernel.org/all/20230317053415.2254616-1-frowand.list@gmail.com/

Best regards,
Hervé Codina
-- 
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Powered by blists - more mailing lists