linux-kernel - Re: [PATCH v5 3/6] net: phy: at803x: add QCA8084 ethernet phy support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d123cc36-f467-40b4-b792-98fd2104c878@quicinc.com>
Date:   Tue, 21 Nov 2023 19:15:08 +0800
From:   Jie Luo <quic_luoj@...cinc.com>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>,
        Andrew Lunn <andrew@...n.ch>
CC:     <davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
        <pabeni@...hat.com>, <robh+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>,
        <hkallweit1@...il.com>, <corbet@....net>, <netdev@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v5 3/6] net: phy: at803x: add QCA8084 ethernet phy support



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.