From: Alex Elder <elder@riscstar.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com,
maxime.chevallier@bootlin.com, rmk+kernel@armlinux.org.uk,
andersson@kernel.org, konradybcio@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, linusw@kernel.org,
brgl@kernel.org, arnd@arndb.de, gregkh@linuxfoundation.org,
daniel@riscstar.com, mohd.anwar@oss.qualcomm.com,
a0987203069@gmail.com, alexandre.torgue@foss.st.com,
ast@kernel.org, boon.khai.ng@altera.com, chenchuangyu@xiaomi.com,
chenhuacai@kernel.org, daniel@iogearbox.net, hawk@kernel.org,
hkallweit1@gmail.com, inochiama@gmail.com,
john.fastabend@gmail.com, julianbraha@gmail.com,
livelycarpet87@gmail.com, matthew.gerlach@altera.com,
mcoquelin.stm32@gmail.com, me@ziyao.cc,
prabhakar.mahadev-lad.rj@bp.renesas.com,
richardcochran@gmail.com, rohan.g.thomas@altera.com,
sdf@fomichev.me, siyanteng@cqsoftware.com.cn,
weishangjuan@eswincomputing.com, wens@kernel.org,
netdev@vger.kernel.org, bpf@vger.kernel.org,
linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 09/12] gpio: tc956x: add TC956x/QPS615 support
Date: Wed, 6 May 2026 15:25:54 -0500 [thread overview]
Message-ID: <79684efa-4ba9-4144-a99b-dab935007a2f@riscstar.com> (raw)
In-Reply-To: <7d7b6b89-3ef4-4891-a794-c8b11f39db34@lunn.ch>
On 5/6/26 2:43 PM, Andrew Lunn wrote:
>>> ----------------------------------
>>> | 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 | ------ |
>>> | | E |----++----| |----++----| E | |
>>> | | N | eMAC 0 | | eMAC 1 | N | |
>>> --------+.......+------+.....+-----------------
>>> |USXGMII| |SGMII|
>>> --+.......+-- --+.....+--
>>> | ARQ113C | | QEP8121 |
>>> | PHY | | PHY |
>>> ------------- -----------
>>>
>
>
>> Because the internal endpoint won't operate until the PCIe
>> power controller has enabled power, this GPIO driver and
>> the PCIe power control driver won't interfere with each
>> other's access to the shared registers.
>
> What i find interesting is that there are two GPIOs, and two external
> downstream PCIe ports. A naive way of looking at this is that each
> external PCIe port has one GPIO. And the internal PCIe port does not
> have one. Hence the internal port might well work without any
> additional setup? That was my thinking.
I see what you're saying. I don't actually know what effect those
two reset signals have on the internal PCIe endpoint or its port.
Here is what the power control driver does:
- asserts those two reset signals (via direct register writes)
- for every port on the switch:
- disables the port (which programs a sequence of values to
specific addresses)
- sets several PCIe configuration options
- l0s_entry_delay
- l1_entry_delay
- TX amplitude
- NFTS
- disable DFE
- Finally deasserts those two reset signals again.
And "every port on the switch" is:
- USP (upstream port)
- DSP 1, 2, 3 (downstream ports, including the embedded one)
- Ethernet (which tells me maybe we need to update that driver
to support two eMACs?)
The whole point of this power control driver is that it doesn't
actually power up the PCIe switch at all until *after* this
configuration step is complete. So I believe the internal
endpoint and its two functions aren't powered until after the
power control driver finishes probing.
The GPIO controller is obviously alive when the power control
driver runs though.
> But you are saying it is not as simple as this, and two GPIOs affect
> three ports? Do you have any idea what they actually do?
To be honest, for the most part we haven't looked closely at
the PCIe power control driver--though it's relatively simple
and I understand how the code works...
So I don't know the answer, but I expect with some work I
might be able to find out.
To be clear, the reason you're asking is that you're suggesting
we might want to model the GPIO controller differently, correct?
I.e., model it as *not* associated with the embedded PCIe
functions. Then we need to think about what its parent device
would be (the power control device, which I think somehow
duplicates the switch device?).
-Alex
> Andrew
next prev parent reply other threads:[~2026-05-06 20:25 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-01 15:54 [PATCH net-next 00/12] net: enable TC956x support Alex Elder
2026-05-01 15:54 ` [PATCH net-next 01/12] net: pcs: pcs-xpcs-regmap: support XPCS memory-mapped MDIO bus via regmap Alex Elder
2026-05-01 15:54 ` [PATCH net-next 02/12] net: pcs: pcs-xpcs: select operating mode for 10G-baseR capable PCS Alex Elder
2026-05-01 16:50 ` Andrew Lunn
2026-05-01 18:07 ` Alex Elder
2026-05-05 15:58 ` Daniel Thompson
2026-05-01 15:54 ` [PATCH net-next 03/12] net: pcs: pcs-xpcs: Preserve BMCR_ANENBLE during link up Alex Elder
2026-05-01 17:06 ` Andrew Lunn
2026-05-06 9:46 ` Daniel Thompson
2026-05-01 15:54 ` [PATCH net-next 04/12] net: stmmac: dma: create a separate dma_device pointer Alex Elder
2026-05-01 17:13 ` Andrew Lunn
2026-05-01 18:06 ` Alex Elder
2026-05-01 20:55 ` Andrew Lunn
2026-05-04 13:36 ` Alex Elder
2026-05-01 15:54 ` [PATCH net-next 05/12] net: stmmac: dwxgmac2: Add multi MSI interrupt mode Alex Elder
2026-05-01 17:21 ` Andrew Lunn
2026-05-01 15:54 ` [PATCH net-next 06/12] net: stmmac: dwxgmac2: Add XGMAC 3.01a support Alex Elder
2026-05-01 15:54 ` [PATCH net-next 07/12] net: stmmac: dwxgmac2: export symbols for XGMAC 3.01a DMA Alex Elder
2026-05-01 15:54 ` [PATCH net-next 08/12] dt-bindings: net: toshiba,tc965x-dwmac: add TC956x Ethernet bridge Alex Elder
2026-05-01 17:38 ` Andrew Lunn
2026-05-03 2:22 ` Alex Elder
2026-05-04 11:00 ` Krzysztof Kozlowski
2026-05-04 13:34 ` Alex Elder
2026-05-01 15:54 ` [PATCH net-next 09/12] gpio: tc956x: add TC956x/QPS615 support Alex Elder
2026-05-01 18:36 ` Andrew Lunn
2026-05-03 1:45 ` Alex Elder
2026-05-03 2:48 ` Andrew Lunn
2026-05-03 3:05 ` Andrew Lunn
2026-05-06 18:21 ` Alex Elder
2026-05-06 19:43 ` Andrew Lunn
2026-05-06 20:25 ` Alex Elder [this message]
2026-05-06 21:43 ` Andrew Lunn
2026-05-06 22:41 ` Alex Elder
2026-05-03 3:42 ` Julian Braha
2026-05-06 18:51 ` Alex Elder
2026-05-04 12:46 ` Bartosz Golaszewski
2026-05-04 13:07 ` Alex Elder
2026-05-01 15:54 ` [PATCH net-next 10/12] net: stmmac: " Alex Elder
2026-05-01 19:04 ` Andrew Lunn
2026-05-05 16:38 ` Mohd Ayaan Anwar
2026-05-05 16:46 ` Alex Elder
2026-05-06 2:30 ` Xilin Wu
2026-05-06 17:44 ` Alex Elder
2026-05-06 12:59 ` Xilin Wu
2026-05-06 14:19 ` Andrew Lunn
2026-05-06 14:35 ` Xilin Wu
2026-05-06 14:45 ` Andrew Lunn
2026-05-06 15:38 ` Xilin Wu
2026-05-06 15:39 ` Daniel Thompson
2026-05-06 15:44 ` Xilin Wu
2026-05-06 15:56 ` Andrew Lunn
2026-05-06 16:00 ` Xilin Wu
2026-05-06 15:28 ` Daniel Thompson
2026-05-06 19:52 ` Andrew Lunn
2026-05-01 15:54 ` [PATCH net-next 11/12] misc: tc956x_pci: " Alex Elder
2026-05-01 21:07 ` Andrew Lunn
2026-05-03 2:06 ` Alex Elder
2026-05-02 16:45 ` Jakub Kicinski
2026-05-03 2:06 ` Alex Elder
2026-05-03 2:14 ` Jakub Kicinski
2026-05-03 2:23 ` Alex Elder
2026-05-01 15:54 ` [PATCH net-next 12/12] arm64: dts: qcom: qcs6490-rb3gen2: enable TC9564 with a single QCS8081 phy Alex Elder
2026-05-01 21:09 ` Andrew Lunn
2026-05-05 16:25 ` Daniel Thompson
2026-05-05 16:42 ` Mohd Ayaan Anwar
2026-05-05 16:46 ` Alex Elder
2026-05-02 16:47 ` [PATCH net-next 00/12] net: enable TC956x support Jakub Kicinski
2026-05-03 2:07 ` Alex Elder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=79684efa-4ba9-4144-a99b-dab935007a2f@riscstar.com \
--to=elder@riscstar.com \
--cc=a0987203069@gmail.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andersson@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=arnd@arndb.de \
--cc=ast@kernel.org \
--cc=boon.khai.ng@altera.com \
--cc=bpf@vger.kernel.org \
--cc=brgl@kernel.org \
--cc=chenchuangyu@xiaomi.com \
--cc=chenhuacai@kernel.org \
--cc=conor+dt@kernel.org \
--cc=daniel@iogearbox.net \
--cc=daniel@riscstar.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=hawk@kernel.org \
--cc=hkallweit1@gmail.com \
--cc=inochiama@gmail.com \
--cc=john.fastabend@gmail.com \
--cc=julianbraha@gmail.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=livelycarpet87@gmail.com \
--cc=matthew.gerlach@altera.com \
--cc=maxime.chevallier@bootlin.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=me@ziyao.cc \
--cc=mohd.anwar@oss.qualcomm.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
--cc=richardcochran@gmail.com \
--cc=rmk+kernel@armlinux.org.uk \
--cc=robh@kernel.org \
--cc=rohan.g.thomas@altera.com \
--cc=sdf@fomichev.me \
--cc=siyanteng@cqsoftware.com.cn \
--cc=weishangjuan@eswincomputing.com \
--cc=wens@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox