[PATCH net-next v2 10/14] dt-bindings: net: toshiba,tc9654-dwmac: add TC9564 Ethernet bridge
Alex Elder
elder at riscstar.com
Tue Jun 9 14:31:48 PDT 2026
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 at riscstar.com>
>>
>> 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 at riscstar.com>
>> Signed-off-by: Alex Elder <elder at riscstar.com>
>> ---
>> .../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 at riscstar.com>
>> + - Daniel Thompson <daniel at riscstar.com>
>> +
>> +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
More information about the linux-arm-kernel
mailing list