On Mon, May 09, 2022 at 06:09:17PM +0200, Clément Léger wrote: > Le Mon, 9 May 2022 10:56:36 -0500, > Frank Rowand <frowand.list@xxxxxxxxx> a écrit : ... > > On the surface, it appears that your need might be well met by having > > a base devicetree that describes all of the pcie nodes, but with each > > node having a status of "disabled" so that they will not be used. > > Have a devicetree overlay describing the pcie card (as you proposed), > > where the overlay also includes a status of "ok" for the pcie node. > > Applying the overlay, with a method of redirecting the target to a > > specific pcie node would change the status of the pcie node to enable > > its use. (You have already proposed a patch to modify > > of_overlay_fdt_apply() to allow a modified target, so not a new > > concept from me.) My suggestion is to apply the overlay devicetree > > to the base devicetree before the combined FDT devicetree is passed > > to the kernel at boot. The overlay apply could be done by several > > different entities. It could be before the bootloader executes, it > > could be done by the bootloader, it could be done by a shim between > > the bootloader and the kernel. This method avoids all of the issues > > of applying an overlay to a running system that I find problematic. > > It is also a method used by the U-boot bootloader, as an example. > > Ok, that is actually possible on a system that is given a device-tree > by the bootloader. But on a system that is desrcibed using ACPI (such > as the x86), this is much more difficult (at least to my knowledge)... > We want this feature to be easy to use for the end user. Adding such > configuration which also differs between various architecture is > clearly not so easy to setup. > > Moreover, since the PCI is meant to be "Plug and Play", such > configuration would completely break that. If the user switches the > PCIe card from one slot to another, the bootloader configuration will > need to be modified. This seems a big no way for me (and for the user). The main problem here is that Linux does not support hotplugging for the devices behind non-hotpluggable buses. You need to develop something to say that the device tree (in terms of hardware) can morph at run-time transparently to the user. I think the closest one is what FPGA does, or at least should do. > > The other big issue is mixing ACPI and devicetree on a single system. > > Historically, the Linux devicetree community has not been receptive > > to the ides of that mixture. Your example might be a specific case > > where the two can be isolated from each other, or maybe not. (For > > disclosure, I am essentially ACPI ignorant.) I suspect that mixing > > ACPI and devicetree is a recipe for disaster in the general case. > > Agreed, on that fact, it did raised some eyebrows, and it was for that > specific concern that initially, I proposed the fwnode solution. > Honestly, the fwnode conversion represent a lot of work (hundreds of > lines easily) + requires a conversion of all the subsystem that are not > fwnode ready (spoiler: almost all of them are not ready). In either case you need to provide a format that would be suitable for DT-based as well as ACPI-based platforms. -- With Best Regards, Andy Shevchenko
