Re: [PATCH net-next v2 12/14] gpio: tc956x: add TC956x/QPS615 support

On Thu, Jul 16, 2026 at 11:24:15AM -0500, Alex Elder wrote:

On 7/16/26 2:02 AM, Manivannan Sadhasivam wrote:

quoted

On Thu, Jun 04, 2026 at 08:00:19PM -0500, Alex Elder wrote:

quoted

Toshiba TC956x is an Ethernet-AVB/TSN bridge and is essentially
a small and highly-specialized SoC.  TC956x includes a GPIO block that
can be accessed, alongside several other peripherals, via two PCIe
endpoint functions.  The PCIe function driver creates an auxiliary
device for the GPIO block, and that device gets bound to this auxiliary
device driver.

This driver is implemented using the generic regmap-based GPIO driver.

While the regmap over the switch BAR works for GPIO access post-enumeration,
there is a blocker in using these GPIOs to control the power to endpoints.

We're aware of the power control driver and its use of these GPIOs.

I think the point you're making is not about the specific way we
are using GPIOs, but that someone could try to use this GPIO
controller in a way that would lead to a circular dependency
(between the controller and the PCIe device it depends on).

This not a future problem, but a present one :)

And you suggest a GPIO driver that uses I2C (and would be
used by the pwrctrl driver as well), and I think it's a pretty
reasonable suggestion.

quoted

We have a design [1] where the GPIOs from the switch are used to control power
and PERST# signals to the EP. With this current design, during the initial PCI
bus scan, the switch will get enumerated, but the EP will not. Because, power to
the EP depends on the GPIO Aux driver that will get probed only after the switch
enumeration.

Yes, on the RB3gen2 platform, reset signals (PERST#) for two of
the TC9563 PCIe switch ports (downstream 1 and downstream 2) are
managed by the GPIO controller that resides within the TC9563
itself.  The pwrctl driver takes special care to ensure the GPIO
controller is functional (powered) before trying to use it.

The TC9563 *chip* gets powered when its embedded PCIe switch is
probed--that is, when its upstream port begins its enumeration.
(It's a little unclear to me which of the supplies are required
for the various non-PCIe components on the chip, including I2C
and GPIO, to be functional.)

Well, the TC9563 should get powered ON when its pwrctrl driver gets probed and
the pci_pwrctrl_power_on_device() is called. There is no dependency with the
upstream port enumeration AFAIK.

And so until the switch gets probed (and its pwrctl driver used),
the GPIO controller can't work.  So nothing internal to the TC956x should be
dependent on any of the GPIOs supplied by this controller.
(Except the pwrctrl driver, which enables power before using GPIO.)


Two things to note:
- We are working with TC9564 (and there are other successors in
  the TC956x series).
- Downstream port 3 (which we are using) on the switch does not
  have such a distinct controlled reset line.

quoted

But this creates a chicken-and-egg problem with the PCI Pwrctrl design.
pcie-qcom driver uses the Pwrctrl framework to power on the PCI endpoints before
the initial PCI bus scan. It calls pci_pwrctrl_create_devices() and
pci_pwrctrl_power_on_devices() APIs to create the platform device for all PCI
devices defined in DT (that require pwrctrl support), waits for their respective
pwrctrl drivers to get probed and then power ON all of them.

The way I understood it was that certain parameters for the PCIe
links needed to be set before using them, and the pwrctrl framework
made that possible.  (I summarize what that driver does at the end
of this message.)

Yeah, it does handle both power ON and some configuration for stable operation.

 This step is

quoted

required because in DT platforms, many Root Ports are not hotplug capable and
also BIOS doesn't assign bridge windows during boot. So all the devices has to
appear during the initial PCI bus scan so that the PCI core can allocate the
resources properly.

This part I didn't know before.  Yes, the bridge windows are
allocated by Linux rather than by firmware.  And if this host
bridge doesn't support hotplug, then yes, to correctly assign
address space, all PCIe devices must be available to report
their required memory space.

Are you saying that "setting those parameters" wouldn't be
needed if this particular root port supported hotplug?  (I'm
just curious; it's not relevant to the point you're making.)

Yeah, more or less. If the Root Port is hotplug capable, PCI core will allocate
more resources like bridge windows and bus numbers in anticipation of devices
getting attached to it after boot. But that also sometimes becomes insufficient
if a resource hungry device like GPU gets plugged in later, as the PCI core can
only guess the memory for hotplug capable Root Port.
 

quoted

Now the issue with this Aux driver design is that, if an EP makes use of the
switch GPIO for PERST# or power, like:

	tc9563: pcie@0,0 {
		compatible = "pci1179,0623";
		reg = <0x10000 0x0 0x0 0x0 0x0>;
		...

		pcie@1,0 {
			compatible = "pciclass,0604";
			reg = <0x20800 0x0 0x0 0x0 0x0>;
			#address-cells = <3>;
			#size-cells = <2>;

			device_type = "pci";
			ranges;
			bus-range = <0x3 0xff>;

			reset-gpios = <&tc9563 5 GPIO_ACTIVE_LOW>;
		};
	...

	};

Then the pwrctrl driver (pci/pwrctrl/generic.c) will try to acquire the GPIO
controller during its probe, but will fail with -EPROBE_DEFER as the GPIO
controller won't be available at that time. So the whole PCIe instance will
probe defer as the driver requires all pwrctrl drivers to be probed before
starting the initial bus scan.

The only GPIOs we're using are for asserting reset on the two
Ethernet PHYs.  That doesn't occur until after the embedded
endpoint functions are probed, so this should be OK.

However you're right, the lines on this GPIO controller should
be restricted to avoid this circular dependency.

quoted

So we need to make sure that the GPIO controller driver is available before
enumerating the switch device. One way to achieve is by creating the GPIO Aux
device in the pci/pwrctrl/pci-pwrctrl-tc9563.c driver and let the GPIO
controller driver use I2C communication for setting up the GPIOs. Thankfully,
the switch allows both I2C and BAR MMIO configurations for internal GPIOs.

Daniel and I have talked about this solution exactly, but opted
not to propose using it just yet (not unless someone like you
suggested it...).  Our solution for now was just to have the
(PCIe BAR-based) GPIO driver reserve the two GPIO lines used by
the pwrctrl driver, and rely on the fact that the pwrctrl driver
will only touch those shared registers at times the "real" GPIO
driver does not.

Yeah. If those GPIO lines are not used to power up any endpoint devices, then
there should be no issues. But this is something we cannot control as the board
designers can do whatever they want.

We could instead implement a "proper" I2C-based GPIO controller
driver.  This would be used by the pwrctrl driver (rather than
that driver just updating the registers directly), as well as
the Ethernet PHY for reset control, and for any other uses on
future platforms.

Sounds like a plan.

All uses so far are for managing resets, so the higher I2C
latency wouldn't be much of an issue.

quoted

With this change, the GPIO driver will get probed by the time the pwrctrl
generic driver acquires the 'reset-gpios' and will turn ON the EP.

One thing I'll point out is that the next version of this
code will define "pci-ep-bus" nodes, and will not use the
auxiliary bus model.  However the issue you raise remains
in that model too.

Please do CC me on the upcoming versions as well.

Thank you very much for raising this Mani.  Please see my
questions a little further below.

					-Alex

quoted

Let me know your thoughts!

- Mani

[1] https://lore.kernel.org/linux-pci/e2inl7k5gsjj6oomv2k5ximuzpb3gfiz66ufet3b4hvov7zqt4@qz4pifbos7yf/ (local)

Here's what the pwrctrl driver does:

In drivers/pci/pwrctrl/pci-pwrctrl-tc9563.c, the registers at
offset 0x1208 and 0x1210 from the base of the "SFR" address space
are updated to assert/deassert these two reset signals.  It does
so using the I2C interface--out of band from access via PCI BARs.
The reset signals are GPIO02 (for downstream endpoint 1 on the
switch) and GPIO03 (for endpoint 2), which are controlled by
bits 2 and 3 in the two registers, respectively.

The pwrctrl driver enables a set of regulators defined in the
devicetree node for the upstream port of the TC9564 embedded
PCIe switch.  It then asserts the main RESX (chip) reset signal,
and after a short delay asserts these other two resets.

At that point it uses properties defined in devicetree to
configure five "ports":  upstream, downstream 1-3, and Ethernet.
(I have some questions related to this--but I put them below.)
The properties configured are:  ASPM L0s entry delay; ASP L1 entry
delay; TX amplitude; Number of Fast Training Sequences (NTFS); and Decision
Feedback Equalization (DFE).

The driver confuses between ports and endpoint. TC9563_ETHERNET is not a port,
but an integrated endpoint. I've identified some issues while reviewing it now.
Will try to fix them asap.

Finally, the two resets and the main RESX reset are deasserted,
and the driver reports that the device is now ready, with:
  devm_pci_pwrctrl_device_set_ready();



Questions related to the "ports" configured by the pwrctrl driver:
- Given that downstream port 3 connects to the internal, embedded
  PCIe endpoint, does it still require these settings programmed?

Not all of the settings are applicable to all ports. Only ASPM and N_FTS are
applicable to all ports and endpoints, but the rest are optional. But the driver
treats all properties mandatory for all ports/endpoint, and safeguards itself by
having some absurd checks. This is something I'm going to fix.

The driver assumes only one endpoint, but the binding lists 2. So the driver is
not complying with its own binding now :/

So technically, the driver supports 2 integrated endpoints.

- Why is "Ethernet" configured like the PCIe ports, *in addition*
  to the downstream port 3 that it sits behind?

Both ASPM and N_FTS properties are applicable to ports and integrated endpoints
as well. But other 2, DFE and Tx Amplitude are only applicable to ports only,
excluding DSP3.

- Mani

-- 
மணிவண்ணன் சதாசிவம்