On 10/10/22 03:42, Clément Léger wrote: > Le Tue, 13 Sep 2022 12:41:28 -0500, > Frank Rowand <frowand.list@xxxxxxxxx> a écrit : > >>>> I am not positive what part of what I wrote above is correct and would appreciate >>>> some confirmation of what is correct or incorrect. >>> >>> There are 2 series devices rely on this patch: >>> >>> 1) Xilinx Alveo Accelerator cards (FPGA based device) >>> >>> 2) lan9662 PCIe card >>> >>> please see: https://lore.kernel.org/lkml/20220427094502.456111-1-clement.leger@xxxxxxxxxxx/ >> >> Thanks. Please include this information in future versions of the patch series. >> >> For device 2 I have strongly recommended using pre-boot apply of the overlay to the base >> device tree. I realize that this suggestion is only a partial solution if one wants to >> use hotplug to change system configuration (as opposed to using hotplug only to replace >> an existing device (eg a broken device) with another instance of the same device). I >> also realize that this increased the system administration overhead. On the other hand >> an overlay based solution is likely to be fragile and possibly flaky. > > Again, applying overlays pre-boot is not an acceptable solution. Some > systems are not based on device-tree (x86 platforms with ACPI based > description, and I'm not even sure this is doable by modifying ACPI > tables). PCI is meant to be plug-and-play, so patching the ACPI > tables or device-tree pre-boot is likely not the correct answer to this > problem. > > This would also require two different descriptions of the same card > (for ACPI and device-tree) and would require the final user to create a > specific overlay for its device based on the PCI slots the card is > plugged in. One of the many missing pieces of overlay support. There have been several discussion of how to describe a "socket" in a device tree that a device could be plugged into, where a single device tree subtree .dtb could be relocated to one or more different socket locations. Thus in this case a single overlay could be relocated to various PCI slots. I don't expect be getting involved in any future efforts around sockets (see my following comment for why). > > The solution we proposed (Lizhi and I) allows to overcome these > problems and is way easier to use. Fixing the potential bugs that might > exists in the overlay layer seems a way better idea that just pushing It is not potential bugs. The current run time overlay implementation is proof of concept quality and completeness. It is not production ready. I got an opportunity for early retirement a couple of weeks ago. My first inclination was to continue the same level of device tree maintainership, but I am quickly realizing that there are other activities that I would like to devote my time and energy to. I will continue to support Rob with minor patch reviews and testing, and potentially finishing up some improvements to unittest. On the other hand, bringing run time overlay support to product quality would be a major investment of my time that I am not willing to continue. So I am leaving major overlay issues in the capable hands of Rob. I may chime in from time to time when I can do so without requiring too much of my time. -Frank > that away to the bootloader level. Moreover, this kind of devices is > likely to be more common with the increasing popularity of FPGA and a > proper solution must be found. >
