Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35;
Message-ID: <d123cc36-f467-40b4-b792-98fd2104c878@quicinc.com>
Date:   Tue, 21 Nov 2023 19:15:08 +0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 3/6] net: phy: at803x: add QCA8084 ethernet phy support
Content-Language: en-US
To:     "Russell King (Oracle)" <linux@armlinux.org.uk>,
        Andrew Lunn <andrew@lunn.ch>
CC:     <davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>,
        <pabeni@redhat.com>, <robh+dt@kernel.org>,
        <krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>,
        <hkallweit1@gmail.com>, <corbet@lwn.net>, <netdev@vger.kernel.org>,
        <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <linux-doc@vger.kernel.org>
References: <20231118062754.2453-1-quic_luoj@quicinc.com>
 <20231118062754.2453-4-quic_luoj@quicinc.com>
 <1eb60a08-f095-421a-bec6-96f39db31c09@lunn.ch>
 <ZVkRkhMHWcAR37fW@shell.armlinux.org.uk>
 <eee39816-b0b8-475c-aa4a-8500ba488a29@lunn.ch>
 <fef2ab86-ccd7-4693-8a7e-2dac2c80fd53@quicinc.com>
 <1d4d7761-6b42-48ec-af40-747cb4b84ca5@lunn.ch>
 <ZVuGv2005eaw+R6u@shell.armlinux.org.uk>
From:   Jie Luo <quic_luoj@quicinc.com>
In-Reply-To: <ZVuGv2005eaw+R6u@shell.armlinux.org.uk>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


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.