Re: [PATCH 1/2] dt-bindings: misc: introduce pci1179,0220.yaml

[Alex Elder <elder@riscstar.com>]

On 8/17/26 1:18 AM, Krzysztof Kozlowski wrote:
> On 14/08/2026 18:55, Alex Elder wrote:
>> On 8/14/26 2:01 AM, Krzysztof Kozlowski wrote:
>>> On Thu, Aug 13, 2026 at 05:29:41PM -0500, Alex Elder wrote:
>>>> Define the binding for the Toshiba TC9564 PCI endpoint function device.
>>>> The third downstream PCIe switch port within this chip has an embedded
>>>> PCIe controller, and that implements two of these PCIe functions.
>>>>
>>>> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
>>>> Signed-off-by: Alex Elder <elder@riscstar.com>
>>>> ---
>>>>    .../bindings/misc/pci1179,0220.yaml           | 150 ++++++++++++++++++
>>>>    MAINTAINERS                                   |   6 +
>>>>    2 files changed, 156 insertions(+)
>>>>    create mode 100644 Documentation/devicetree/bindings/misc/pci1179,0220.yaml
>>>>
>>>
>>> There are no properties in the binding except standard PCIe ones, so why
>>> do you need it in DT in the first place? We do not describe PCI devices
>>> in DT by default, so you are doing something unusual. Commit msg should
>>> explain that.
>>
>> Maybe because it's using pci-ep-bus?  I'm not sure I can answer your
>> question though.
> 
> What is pcie-ep bus? If a device is a PCI device (so not the host
> bridge), we do not need to define it in DT except a few cases and this
> does not look like one.

It's a weird case because PCI has its own enumeration method,
so there should no need to involve devicetree.

Nevertheless the pci-ep-bus model *is* a devicetree thing
related to PCI, describing devices accessible via PCI BARs.
   Documentation/devicetree/bindings/pci/pci-ep-bus.yaml

It is used for the LAN966x SoC, however that driver loads
the devicetree content dynamically using an overlay, and
its overlay source is found under drivers/misc:
   drivers/misc/lan966x_pci.c
   drivers/misc/lan966x_pci.dtso

This use of the LAN966x has no devicetree binding.

The Raspberry Pi RP1 also uses pci-ep-bus.  It, however
does have a binding:
   Documentation/devicetree/bindings/misc/pci1de4,1.yaml
>> An earlier version used auxiliary devices.  This time the PCI device
>> sort of stands by itself as provider of the endpoint buses that are
>> used by other devices within the SoC.  There is otherwise no single
>> driver (e.g., for an Ethernet interface) that is implemented as a
>> PCI driver to bind with the hardware.  The SoC drivers will all be
>> platform drivers.
> 
> All this is driver explanation, so does not really answer my questions.
> Whether something is using platform bus or auxiliary devices it
> absolutely does not matter for the DT. It cannot even matter for DT.

I understand what you're saying, and I do agree with you.

Still, this is a strange case where the devicetree language
is used to describe devices and properties that are not
discoverable, using this pci-ep-bus devicetree *technique*.

The core PCI functionality gets discovered in the usual PCI
way (enumeration).  But this allows additional hardware to
be described.


I think that if the devicetree language is used to describe
hardware, having a binding to explain what's valid for that
hardware description makes sense.


As I understand it, for the LAN966x, the original use of the
SoC used an internal processor to run Linux.  So platform
drivers for the devices within the SoC were created that
matched with compatible strings, etc.

Then in another mode, LAN966x is used as a PCI add-in card,
and the pci-ep-bus allowed all of those other drivers to be
used, unmodified.


So anyway, pci-ep-bus is an odd situation.

If the answer is "don't create a binding for this stuff,
even if it gets defined in the devicetree file" then
I'll accept that.

But my instinct is that it's good to use a binding to
describe what the DTS describing the hardware should look
like (despite it being accessed using what amounts to a
logical bus).

					-Alex

> 
> Best regards,
> Krzysztof