Hi,

On Wed, 28 Feb 2024 10:26:47 -0600
Rob Herring [off-list ref] wrote:

...

quoted

quoted

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?

quoted

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@bootlin.com>

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

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel