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

From: Alex Elder

Date: Thu May 07 2026 - 14:37:45 EST


On 5/7/26 9:12 AM, Bjorn Andersson wrote:
On Fri, May 01, 2026 at 10:54:16AM -0500, Alex Elder wrote:
diff --git a/Documentation/devicetree/bindings/net/toshiba,tc956x-dwmac.yaml b/Documentation/devicetree/bindings/net/toshiba,tc956x-dwmac.yaml
[..]
+
+ gpio-controller: true

I don't have any concern with the use of a proper gpio driver to model
the implementation, but if I understand correctly this relationship
between gpio controller and gpio consumer is strictly internal to "the
PCI device".

(I think you're already cool with this but I still wanted to respond.)

That is not correct. These GPIO lines are used two ways for the
RB3gen2:
- drivers/pci/pwrctrl/pci-pwrctrl-tc9563.c uses GPIOs 2 and 3 to
assert/deassert the reset lines associated with the two exposed
downstream PCIe ports on the PCIe switch within the TC956x.

- Each of the Ethernet PHYs has a reset GPIO. On the RB3gen2, the
GPIOs used for the purpose come from the GPIO controller embedded
in the TC9564 (00 and 01).

These are therefore "exposed" (they are *not* strictly internal).

Is this connection variable or is the link merely expressed in
DeviceTree to mitigate the fact that you choose to implement the
responsibilities of the two parts split into two device drivers?

It is variable. These resets might be implemented by other GPIO
controllers on other platforms.

Are there other consumers of these TC956x gpios which would result in a
board designer (and hence dts author) to ever reference this
gpio-controller in a different way?

They could. Nine of these GPIOs are exposed by the TC956x pins
(GPIO00-06, GPIO12, GPIO35 and GPIO36). The RB3gen2 uses 00-03
(and possibly 04 but that's for a PHY we haven't tested yet).

-Alex

Regards,
Bjorn