On 9/23/26 2:25 AM, Krzysztof Kozlowski wrote:
I think nothing behind PCI EP should be described in DT, because everything is internal to the device and implied by compatible (or vid/pid). We do describe internals of devices in DT usually for complex devices (like some display blocks with multiple subblocks) or when they are used outside of that device. That's why I asked how are all these clocks and resets exposed to the host. If the syscon is used only by the device itself, I don't quite get the benefits of describing it in DT.
You say you think "nothing behind PCI EP should be described in DT". However the mere existence of the PCI endpoint bus as an option contradicts that statement, by providing a means of doing *exactly* that: using devicetree to describe things behind a PCI endpoint. This is the model we are using. In June we switched over to using the pci-ep-bus model based on a suggestion from Rob Herring (and Mani Sadhasivam). Rob felt our previous auxiliary device approach wasn't right for the peripherals found within the SoC, given we were accessing them via PCI BARs. https://lore.kernel.org/lkml/[email protected]/ We found that using pci-ep-bus provided a very natural and familiar way of representing the organization of the TC9564 SoC, and used it to represent all of the peripherals (including XGMAC). It nicely partitions the hardware design, as well as providing a well-understood connection with the software. The switch involved quite a bit of work, and the result is a set of basically independent platform drivers that are modular and easily reviewed. I really would rather not go back to to what we had before. Do you have criteria for what in a chip/SoC is sufficiently "complex" to warrant allowing devicetree to describe some of its internal details? I believe the TC9564 *is* such a "complex" SoC. And in any case, anywhere pci-ep-bus is used, it implies that some chip internals would be described using devicetree. Would incorporating the chip internals in a devicetree *overlay* have any effect on your opinion on this? I.e., the "main" devicetree nodes would simply define the PCI device hierarchy, but anything behind an endpoint would be described in an overlay. This way, pci-ep-bus on a PCI endpoint just provides an external interface onto which a very complex device could be "mounted" (and described in an overlay). I'd like to continue to move ahead with upstreaming support for this SoC, but to me it seems you have basic doubts about pci-ep-bus and I'd like to get past that. Thanks. -Alex
