Re: [PATCH net-next v2 10/14] dt-bindings: net: toshiba,tc9654-dwmac: add TC9564 Ethernet bridge
From: Alex Elder
Date: Tue Jun 09 2026 - 17:32:44 EST
On 6/5/26 9:40 AM, Rob Herring wrote:
On Thu, Jun 04, 2026 at 08:00:17PM -0500, Alex Elder wrote:
From: Daniel Thompson <daniel@xxxxxxxxxxxx>
Add devicetree bindings for the Toshiba TC956x family of Ethernet-AVB/TSN
bridges.
The TC9564 contains a PCIe switch with one upstream and three downstream
PCIe ports. The third PCIe downstream port has an attached embedded PCIe
endpoint, and that endpoint implements two PCIe functions. Each internal
PCIe function has a Synopsys XGMAC Ethernet interface capable of 10 Gbps
operation.
The TC9564 also implements an embedded GPIO controller, which exposes
10 lines externally. Some platforms use these GPIO lines, so this
GPIO controller is managed by a separate driver. Other embedded
peripherals (like a microcontroller, SRAM, and UART) are currently
unused.
The GPIO controller is managed by registers accessed via MMIO on an
internal PCIe function's registers.
Signed-off-by: Daniel Thompson <daniel@xxxxxxxxxxxx>
Signed-off-by: Alex Elder <elder@xxxxxxxxxxxx>
---
.../bindings/net/toshiba,tc9564-dwmac.yaml | 120 ++++++++++++++++++
MAINTAINERS | 6 +
2 files changed, 126 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/toshiba,tc9564-dwmac.yaml
diff --git a/Documentation/devicetree/bindings/net/toshiba,tc9564-dwmac.yaml b/Documentation/devicetree/bindings/net/toshiba,tc9564-dwmac.yaml
new file mode 100644
index 0000000000000..6e7a63dfcf86a
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/toshiba,tc9564-dwmac.yaml
@@ -0,0 +1,120 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/toshiba,tc9564-dwmac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toshiba TC956x Ethernet-AVB/TSN Controller
+
+maintainers:
+ - Alex Elder <elder@xxxxxxxxxxxx>
+ - Daniel Thompson <daniel@xxxxxxxxxxxx>
+
+description: |
+ The Toshiba TC9564 (and more generally, TC956x) incorporates a PCIe
+ gen 3 switch with one upstream and three downstream ports. The first
+ two downstream ports are exposed externally, while the third is used
+ by an internal PCIe endpoint. The PCIe endpoint implements two PCIe
+ functions, and attached to each of these is a 10 Gbps capable Synopsys
+ Ethernet controller.
+
+ The TC956x additionally implements other internal IP blocks, and in
+ particular it implements a GPIO controller. Ten of the 35 GPIO lines
+ implemented are exposed externally and are usable by the platform.
+ It is platform-dependent whether the GPIO function must be exposed,
+ and if it is, PCIe function 0 supplies it.
+
+ ----------------------------------
+ | Host |
+ ------+...+----------+........+---
+ |i2c| | PCIe |
+ ----------------+...+----------+........+------
+ | TC956x |I2C| |upstream| |
+ | ----- --+--------+--- |
+ | ----- ------ ------- | PCIe switch | |
+ | |SPI| |GPIO| |reset| | | |
+ | ----- ------ |clock| | DS3 DS2 DS1 | |
+ | ------- ---++--++--++-- |
+ | ----- ------ downstream// \\ \\ | downstream
+ | |MCU| |SRAM| /==========/ \\ \===== PCIe port 1
+ | ----- ------ //PCIe port 3 \\ |
+ | || \======= downstream
+ | ----+-----------++-----------+---- | PCIe port 2
+ | | M | internal PCIe endpoint | M | |
+ | | S |------------------------| S | ------ |
+ | | I | PCIe | | PCIe | I | |UART| |
+ | | G |function 0| |function 1| G | ------ |
I don't see nodes for these PCI functions. Boot this platform with
CONFIG_PCI_DYNAMIC_OF_NODES enabled and use the resulting DT node
structure. Anything else is wrong. This will give you the DTS:
dtc -O dts /proc/device-tree
The ethernet nodes should be just these PCI function nodes. You need to
make the DWMAC PCI driver (stmmac_pci.c) bind to those 2 PCI devices.
And really, a DT node for them should be completely optional (unless
there's some power on ctrl needed).
Everything else like SPI, GPIO, UART, etc. should be under the PCIe
switch upstream node in a pci-ep-bus.
I unfortunately hadn't looked closely enough at pci-ep-bus
before. It really looks like what we should use. It's a
simple bus, and we'll use platform drivers and compatible
strings to match the devices on the bus.
I'll work toward converting things over to use this model.
+ | | E |----++----| |----++----| E | |
+ | | N | eMAC 0 | | eMAC 1 | N | |
+ --------+.......+------+.....+-----------------
+ |USXGMII| |SGMII|
+ --+.......+-- --+.....+--
+ | ARQ113C | | QEP8121 |
+ | PHY | | PHY |
+ ------------- -----------
+
+properties:
+ compatible:
+ enum:
+ - pci1179,0220 # Toshiba TC9564 (a.k.a. Qualcomm QPS615)
+
+ gpio:
+ type: object
+ description: Embedded GPIO controller
+ $ref: /schemas/gpio/gpio.yaml#
gpio.yaml alone does not define a GPIO controller. How many #gpio-cells
needs to be defined.
Is there no address associated with the controller?
+
+ ethernet:
+ type: object
+ description: XGMAC Ethernet controller
+ $ref: /schemas/net/ethernet-controller.yaml#
+ properties:
+ mdio:
+ $ref: snps,dwmac.yaml#/properties/mdio
Either all of snps,dwmac.yaml should apply or none of it. Generally, we
only reference whole schema files (OF graph being a notable exception).
OK.
+ required:
+ - mdio
+
+required:
+ - compatible
+
+allOf:
+ - $ref: /schemas/pci/pci-device.yaml#
+ - $ref: /schemas/pci/pci-bus-common.yaml#
These 2 are just pci-pci-bridge.yaml.
OK.
-Alex
Rob