On 11/21/2023 12:18 AM, Russell King (Oracle) wrote:
On Mon, Nov 20, 2023 at 04:34:55PM +0100, Andrew Lunn wrote:
Are you saying there is a USXGMII-M level link change status? The link
between the SoC and the PHY package is up/down? If it is down, all
four MAC-PHY links are down. If it is up, it is possible to carry
frames between the SoC and the PHY package, but maybe the PHYs
themselves are down?
It shouldn't do. Each "channel" in the USXGMII-M link has its own
autoneg block at both ends, each conveys link status independently.
The MAC side structure is:
+----------+ +-----+
.-XGMII-> Rate | PCS | |
MAC1 <-MDI-> PHY <-+ | Adaption <--> Clause 49 <-> |
`-GMII--> | | |
+-----^----+ | |
| | |
+-----v---- + | |
| Autoneg | | |
| Clause 37 | | |
+-----------+ | |
| Mux <--> PMA <-->
| |
....... USXGMII-M
<------------------------------------------------------>
These blocks are repeated for each channel
The spec goes on to state that there must be a USXGMII enable bit that
defaults to disabled and the PHY should assume normal XGMII/XFI
operation. When enabled, autoneg follows a slight modification of
clause 37-6.
As far as the USXGMII-M link, I believe 2.7.8 in the USXGMII-M
documentation covers this, which is "hardware autoneg programming
sequence". It states that "if 10G link is lost or regained, the
software is expected to disable autoneg and re-enable autoneg". I
think "10G link" refers to the USXGMII-M connection, which means
the loss of that link shold cause software to intervene in each
of the PCS autoneg blocks. It is, however, rather unclear.
The link status of PHY is updated, software should do the corresponding
QXGMII mode configuration per channel for this PHY.
The PCS QXGMII configuration reflects the current link status of the
connected PHY.
