Re: [PATCH 1/4] dt-bindings: mfd: introduce the TC9564 config syscon

[Daniel Thompson <daniel@riscstar.com>]

On Thu, Oct 29, 2026 at 02:54:35PM +0100, Krzysztof Kozlowski wrote:
> On 28/09/2026 16:52, Alex Elder wrote:
> > On 9/23/26 2:25 AM, Krzysztof Kozlowski wrote:
> > 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.
>
> Well, Rob might understand this better, so maybe review from him will
> solve these questions.

To aid whichever of the DT maintainers can help with review, I'd
like to offer a little more background on the "TC9564 is a complex
device" thread.

Hopefully it doesn't contradict what you've been discussing with Alex,
but it will perhaps give a different perspective.

My thoughts neatly divide into three parts:

1. The TC956x-series form a complex enough family of multi-function
   devices. We will need some way to describe it's structure (both
   external *and* internal).

2. There are multiple ways to describe a device's connectivity but
   devicetree is great for this job making it an excellent technical
   solution.

3. We have done sufficient thought experiments (and real-world
   experiments) to be confident that our solution is not in conflict
   with treating the QPS615 as a regular PCIe card.

Having offered the summary above because I now need to spend a lot of
words to back up the above. I'm afraid I have to go a long way past
the syscon bindings perimeter!

## Why I think the QPS615 is "complex"

I hope I don't have to rehash the multi-function part too much. The TC9564
included comms peripherals (UART, I2C, SPI, GPIO), some very common SoC-ish
management peripherals (reset, clock, interrupt controller), a Cortex-M3
controller (with access to pretty much everything) and some licensed
peripherals with well established devicetree bindings (2x Designware XGMAC).

It should be noted that TC9564 does also include a PCIe switch. However the
switch is *upstream* of the PCIe endpoint we use to control most of the other
TC9564 peripherals so you won't see it any any bindings that have come from
Alex and me.

Another factor that makes describing TC9564 complex is the presence or
absence of side channels that give the host SoC mechanisms to communicate with
the TC9564 without using PCIe.

 * On RB3gen2 there are host GPIOs that control TC9564 peripherals such as the
   ethernet phys (used for power control). Additionally there is an I2C side
   channel that is used to control the TC9564 GPIOs. This is needed
   to solve a chicken-and-egg problem related to the PCIe #PERST signals
   in the PCIe switch but also ends up being used to reset the ethernet phys.

 * On a real PCIe card there will be no side channels, which means the TC9564
   GPIO peripheral would suddenly become `status = "okay"` on the PCIe bus
   instead of the I2C bus (in this case we know that there is no
   chicken-and-egg... if there were then the card won't work electrically).

Thus, even with one part number, we already have some fairly significant
connectivity difference depending on the board design.

Finally, the TC956x is a family and we'd like to reuse as much as possible
across the part numbers that will come. Having a convenient way to
reuse common subsystems is is very valuable.

## Why devicetree is a great technical solution

Clearly we *could* rely on a big pile of what is essentially platform
bus code in the PCIe driver to describe the connectivity and familial
difference. Renaming it to auxiliary bus code doesn't stop the results
from feeling like fifteen-year old platform bus code.

For that reason we view devicetree as a better solution to model the
hardware. DT already has idiomatic ways to describe the connectivity of
the device.

Most of the non-discoverable baseboard <-> TC9564 connections are for the
MAC and using devicetree simplifies the binding there since we add only a
few essentials over the existing stmmac bindings (there are existing
stmmac PCIe cards but I believe many are for MACs with a smaller
feature set than TC9564 which makes things easier).

You are correct that for several other peripherals we only describe
internal connectivity. Ultimately we are copying prior art from the
Raspberry Pi RP1. RP1 is also a complex MFD that exposes its functions
in a similar way to what we propose for TC9564 (and on Raspberry Pi 5
is it soldered down just like it is on RB3gen2). FWIW I'd note that I
think the RP1 bindings describe peripherals with no external
connectivity.

So, it's not that the card can't come alive if we use open-coded C to
describe the connectivity. It can. We've been there and done it. Instead
the argument is that *not* using DT to describe TC956x family parts in
their various baseboards is a missed opportunity!

## Using TC9564 as a PCIe card

Currently our work only supports QPS615 soldered onto an RB3gen2 with all it's
sidebands. Here we settled on a static devicetree (no overlay) similar to
Raspberry Pi RP1. We tried overlays, the resulting DTs were fragmented and hard
to read. Ultimately we felt embedded developers would find working with a static
DT easier.

If you feel super strongly that the syscon bindings (which is what this
thread is about) should not appear in a static device tree, we maybe we
could discuss overlaying the discoverable-from-PID-VID parts as an
"embedded TC9564" overlay. Personally I really dislike this approach
because it's hard to read. Also it wouldn't actually impact the DT
bindings so perhaps isn't in scope yet anyway!

For real PCIe cards I definitely think DT overlay is the answer. Here
there are no sidebands meaning there will be no phandles linking the
overlay to the base DT (if there is one). That resolved the concerns
about readability of the overlay. If we actually had a PCIe card today
then I'm confident we'd be able to reuse almost all the driver work
Alex has posted so far and that we'd be able to run it on a system
using ACPI as its primary hardware model.

There are still some warts related to PCIe card identification but they are
unrelated to the DT bindings. TC9564 has a fixed VID/PID so, when there
is no static DT to help us, we must dynamically interrogate the card
from the pcie driver to discover what it actually is and figure out *which*
overlay to load. This is another reason I view devicetree as
an excellent technical solution. Having an easy way to describe each PCIe
card form its schematic is a great property to have.

In short, the TC9564 on a real removable PCIe card has been an
important thought experiment for me throughout this work. It's also
been a real experiment: we did implement dynamic overlay for RB3gen2
and have it working. The thing that moved us back to static DT
for this board was the sidebands and these don't exist for a real PCIe
card.

## That's all folks!

In short, for zany embedded designs with nasty (and mandatory) side
channels, we'd like to use the DT bindings we have proposed from static DT.
This should be comfortable and ergonomic for embedded developers who
are accustomed to slinging DTs around.

For sensible grown up designs that need to cooperate with both DT and
ACPI, we'd like to use DT overlay. This essentially makes the use of DT
an implementation detail that reduces maintenance by avoiding reinvention.



Daniel.