Re: [PATCH net-next 08/12] dt-bindings: net: toshiba,tc965x-dwmac: add TC956x Ethernet bridge

Alex Elder
2026-05-03T02:22:42Z

On 5/1/26 12:38 PM, Andrew Lunn wrote:
> Your ASCII art of the chip might be useful here as documentation.
>
>> + # We can't allOf reference Ethernet-controller.yaml because we end up with
>> + # contradictory $nodename rules (`ethernet@` versus `pci@`). Happily only a
>> + # small number of the properties are useful on TC956x so we can just reference
>> + # what we need.
>
> Why not add an subnodes for the ethernet interfaces?

I'm going to wait to respond to this until I've had a chance
to discuss it with Daniel. (It might be Tuesday.)

>
>> +examples:
>> + - |
>> + pcie {
>> + #address-cells = <3>;
>> + #size-cells = <2>;
>> +
>> + tc956x_emac0: pci@0,0 {
>> + compatible = "pci1179,0220";
>> + reg = <0x50000 0x0 0x0 0x0 0x0>;
>> + #address-cells = <3>;
>> + #size-cells = <2>;
>> + device_type = "pci";
>> + ranges;
>> +
>> + gpio-controller;
>> + #gpio-cells = <2>;
>
> I've not got to the GPIO driver patch yet...
>
> Is the GPIO part of the ethernet device, or part of the chip? The
> hierarchy here should match the hierarchy of the hardware.

The GPIO is part of the TC9564 chip, and is a separate IP
within it. Within this chip there is one GPIO controller
(as well as a UART and so on), independent of the eMACs.

>> + phy-mode = "10gbase-r";
>> + phy-handle = <&tc956x_emac0_phy>;
>> +
>> + mdio {
>> + compatible = "snps,dwmac-mdio";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + tc956x_emac0_phy: ethernet-phy@1c {
>> + compatible = "ethernet-phy-id311c.1c12";
>> + reg = <0x1c>;
>> + };
>> + };
>> + };
>> + pci@0,1 {
>> + compatible = "pci1179,0220";
>> + reg = <0x50100 0x0 0x0 0x0 0x0>;
>> + #address-cells = <3>;
>> + #size-cells = <2>;
>> + device_type = "pci";
>> + ranges;
>> +
>
> You second ethernet does not have a gpio controller?

Basically, no. We made the decision to create a "chip"
abstraction that is responsible for managing these other
shared IP blocks (of which only the GPIO controller has
a separate driver).

Both of the PCIe endpoints are able to manipulate the
registers for the GPIO, but we made it the responsibility
of function 0--not function 1--to handle that.

It's possible that some platforms won't use the built-in
GPIO controller to manage PHY resets. So we used this
property to signal that it was required.

So *if* the gpio-controller (and #gpio-cells) property is
present, then function 0 creates an auxiliary device for
the GPIO controller. Otherwise something else supplies the
GPIO lines managing PHY resets.

-Alex

>
> Andrew