On Mon, May 9, 2022 at 10:36 PM Frank Rowand <frowand.list@xxxxxxxxx> wrote: > > On 5/9/22 12:00, Andy Shevchenko wrote: > > 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. > > That is something I was not aware of yet. Is the card in question a > hotpluggable card? Do the systems that you anticipate plugging the > card into support hotplug? Any PCIe card is potentially hotpluggable (seems nobody actually cares in 90%+ drivers in the Linux kernel). But what I have heard in a thread (not this one IIRC) is that the card may have pluggable modules and it would be nice to change configuration and notify OS somehow. I might be mistaken if it's the case here or not. -- With Best Regards, Andy Shevchenko
