Messages in this thread | | | Date | Fri, 30 Sep 2022 12:29:40 -0700 | Subject | Re: [PATCH RFC 0/2] Generate device tree node for pci devices | From | Sonal Santan <> |
| |
On 9/26/22 15:44, Rob Herring wrote: > On Fri, Sep 16, 2022 at 6:15 PM Frank Rowand <frowand.list@gmail.com> wrote: >> >> On 8/29/22 16:43, Lizhi Hou wrote: >>> This patch series introduces OF overlay support for PCI devices which >>> primarily addresses two use cases. First, it provides a data driven method >>> to describe hardware peripherals that are present in a PCI endpoint and >>> hence can be accessed by the PCI host. An example device is Xilinx/AMD >>> Alveo PCIe accelerators. Second, it allows reuse of a OF compatible >>> driver -- often used in SoC platforms -- in a PCI host based system. An >>> example device is Microchip LAN9662 Ethernet Controller. >>> >>> This patch series consolidates previous efforts to define such an >>> infrastructure: >>> https://lore.kernel.org/lkml/20220305052304.726050-1-lizhi.hou@xilinx.com/ >>> https://lore.kernel.org/lkml/20220427094502.456111-1-clement.leger@bootlin.com/ >>> >>> Normally, the PCI core discovers PCI devices and their BARs using the >>> PCI enumeration process. However, the process does not provide a way to >>> discover the hardware peripherals that are present in a PCI device, and >>> which can be accessed through the PCI BARs. Also, the enumeration process >>> does not provide a way to associate MSI-X vectors of a PCI device with the >>> hardware peripherals that are present in the device. PCI device drivers >>> often use header files to describe the hardware peripherals and their >>> resources as there is no standard data driven way to do so. This patch> series proposes to use flattened device tree blob to describe the >>> peripherals in a data driven way. >> >>> Based on previous discussion, using >>> device tree overlay is the best way to unflatten the blob and populate >>> platform devices. >> >> I still do not agree with this statement. The device tree overlay >> implementation is very incomplete and should not be used until it >> becomes more complete. No need to debate this right now, but I don't want >> to let this go unchallenged. > > Then we should remove overlay support. The only way it becomes more > complete is having actual users. > > But really, whether this is the right solution to the problem is > independent of the state of kernel overlay support. > >> If there is no base system device tree on an ACPI based system, then I >> am not convinced that a mixed ACPI / device tree implementation is >> good architecture. > > Most/all of this series is needed for a DT system in which the PCI > devices are not populated in the DT. > >> I might be more supportive of using a device tree >> description of a PCI device in a detached device tree (not linked to >> the system device tree, but instead freestanding). Unfortunately the >> device tree functions assume a single system devicetree, with no concept >> of a freestanding tree (eg, if a NULL device tree node is provided to >> a function or macro, it often defaults to the root of the system device >> tree). I need to go look at whether the flag OF_DETACHED handles this, >> or if it could be leveraged to do so. > > Instead of worrying about a theoretical problem, we should see if > there is an actual problem for a user. > > I'm not so worried about DT functions themselves, but places which > have 'if ACPI ... else (DT) ...' paths. >
Bringing this thread back into focus. Any thoughts on how to move forward?
-Sonal
> Rob
| |