Re: [PATCH v4 2/3] misc: tc9564: introduce base PCI driver

[Alex Elder <elder@riscstar.com>]

On 9/24/26 10:56 AM, Herve Codina wrote:
> Hi Alex, Bjorn,
> 
> On Fri, 18 Sep 2026 12:49:53 -0500
> Alex Elder <elder@riscstar.com> wrote:
> 
>> On 9/18/26 12:30 PM, Bjorn Helgaas wrote:
>>> [+cc Andrea, Herve, Lizhi for of_pci_make_dev_node() quirks]
>>>
>>> On Fri, Sep 18, 2026 at 10:26:57AM -0500, Alex Elder wrote:
>>>> The Toshiba TC9564 is small and highly-specialized SoC that implements
>>>> a PCIe switch as well as an Ethernet AVB/TSN bridge.  In addition to
>>>> these, the SoC implements other functions, including a reset and clock
>>>> controller, an address translation unit, and a few other devices.  PCIe
>>>> BARs provide access to registers that manage these IP blocks, and the
>>>> SoC is modeled using a PCI endpoint bus in devicetree.  This allows the
>>>> IP blocks to be bound to platform drivers that do MMIO via the PCI BARs.
>>>>
>>>> Create a new PCI driver under drivers/misc that binds with the embedded
>>>> PCI endpoint functions within the TC9564 SoC.  Because these functions
>>>> will use devicetree pci-ep-bus to provide access to other IP blocks
>>>> within the TC9564 chip, the main purpose of this driver is to do basic
>>>> PCI initialization, then call of_platform_default_populate() to scan for
>>>> the any endpoint bus children, and probe all devices defined therein.
>>>>
>>>> Because we're using pci-ep-bus, we need to use the PCI quirks mechanism
>>>> to have of_pci_make_dev_node() be called for each endpoint device in
>>>> pci_bus_add_device() (via pci_fixup_device(pci_fixup_final, dev)).
>>>>
>>>> Co-developed-by: Daniel Thompson <daniel@riscstar.com>
>>>> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
>>>> Signed-off-by: Alex Elder <elder@riscstar.com>
>>>
>>> Acked-by: Bjorn Helgaas <bhelgaas@google.com>	# quirks.c
>>>
>>> Not an issue for this patch, but I'm not sure the quirk mechanism is
>>> the best mechanism for doing this.  It's not working around a device
>>> defect like most quirks do.
>>
>> I pretty much agree with you.  I think I mentioned this before
>> (though it might have been in a private conversation) that it
>> is an intentional act to call of_pci_make_dev_node() for an
>> endpoint (and not just a bridge).  And that's different from
>> a hardware quirk.  You only need to do it if there's a pci-ep-bus
>> sub-node on the endpoint.  (I'd have to verify this on the other
>> users of this approach to be 100% sure though.)
> 
> I agree, a quirk is not the best way to trig the of_pci_make_dev_node()
> call. An allow-list seems better.

We're talking about calling of_pci_make_dev_node() on
non-bridge nodes in pci_bus_add_device().

A separate series I've been posting is updating that code path
so it updates the ranges property even for (endpoint) nodes
that have a non-null devicetree node pointer.  I use the same
quirk to cause this to occur.  But now I realize the quirk
might be intended to create a *new* node, so I may have to
re-think it a bit.
   https://lore.kernel.org/lkml/20260924222444.1351466-1-elder@riscstar.com/


Are there any cases other than a PCI endpoint having a pci-ep-bus
sub-node where of_pci_make_dev_node() needs to be called on an
endpoint?

Could we simply call of_pci_make_dev_node() unconditionally in
pci_bus_add_device(), and have of_pci_make_dev_node() only
proceed for endpoints that have such a child node?

(I haven't chased down all of the PCI quirks that call
of_pci_make_dev_node() yet.  Do the XILINX examples use
pci-ep-bus?)

> Alex, on LAN966x, the pci-ep-bus is not present. The OF node must be
> created (call to of_pci_make_dev_node()) and the lan966x_pci driver
> will apply an overlay on this OF node created at run-time.
Understood.  But the overlay does contain it.

After applying the overlay, the driver parses the node
(using of_platform_default_populate()).  And because of
the PCI quirk, of_pci_make_dev_node() gets called for the
PCI endpoint, right?


So again, is calling of_pci_make_dev_node() on a PCI endpoint
*only* related to the endpoint having a pci-ep-bus sub-node?
When else does a PCI endpoint need a devicetree node?

					-Alex
> The pci-ep-bus is described in the OF overlay [1].
> 
> [1] https://elixir.bootlin.com/linux/v7.3-rc3/source/drivers/misc/lan966x_pci.dtso#L50
> 
> Best regards,
> Hervé