Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Message-ID: <fef2ab86-ccd7-4693-8a7e-2dac2c80fd53@quicinc.com>
Date:   Mon, 20 Nov 2023 16:49:59 +0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 3/6] net: phy: at803x: add QCA8084 ethernet phy support
To:     Andrew Lunn <andrew@lunn.ch>,
        "Russell King (Oracle)" <linux@armlinux.org.uk>
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>
Content-Language: en-US
From:   Jie Luo <quic_luoj@quicinc.com>
In-Reply-To: <eee39816-b0b8-475c-aa4a-8500ba488a29@lunn.ch>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 11/19/2023 4:19 AM, Andrew Lunn wrote:
>> 10G_QXGMII is defined in the Cisco USXGMII multi-port document as one
>> of several possibilities for a USXGMII-M link. The Cisco document can
>> be a little confusing beause it states that 10G_QXGMII supports 10M,
>> 100M, 1G and 2.5G, and then only talks about a 10G and 100M/1G MAC.
>>
>> For 10G_QXGMII, there are 4 MAC interfaces. These are connected to a
>> rate "adaption" through symbol replication block, and then on to a
>> clause 49 PCS block.
>>
>> There is then a port MUX and framing block, followed by the PMA
>> serdes which communicates with the remote end over a single pair of
>> transmit/receive serdes lines.
>>
>> Each interface also has its own clause 37 autoneg block.
>>
>> So, for an interface to operate in SGMII mode, it would have to be
>> muxed to a different path before being presented to the USXGMII-M
>> block since each interface does not have its own external data lane
>> - thus that's out of scope of USXGMII-M as documented by Cisco.
> 
> Hi Russell
> 
> I think it helps.
> 
> Where i'm having trouble is deciding if this is actually an interface
> mode. Interface mode is a per PHY property. Where as it seems
> 10G_QXGMII is a property of the USXGMII-M link? Should we be
> representing the package with 4 PHYs in it, and specify the package
> has a PMA which is using 10G_QXGMII over USXGMII-M? The PHY interface
> mode is then internal? Its just the link between the PHY and the MUX?
> 
> By saying the interface mode is 10G_QXGMII and not describing the PMA
> mode, are we setting ourselves up for problems in the future? Could
> there be a PMA interface which could carry different PHY interface
> modes?
> 
> If we decide we do want to use 10G_QXGMII as an interface made, i
> think the driver should be doing some validation. If asked to do
> anything else, it should return -EINVAL.
> 
> And i don't yet understand how it can also do 1000BaseX and 2500BaseX
> and SGMII?
> 
>      Andrew

Hi Andrew,
The interface mode 10G_QXGMII is a type of USXGMII-M, the other modes
such as 20G-QXGMII, 20G-OXGMII...

As for the interface mode 10G-QXGMII, there is a multiplexer for 4 PHYs,
then do 66bit/68bit encode in xpcs and pass to PMA, the link topology:
quad PHY --- multiplexer ---XPCS --- PMA.
the 10G-QXGMII interface block includes multiplexer, XPCS and PMA.

when the PHY works on SGMII mode, then there is no xpcs, the only fourth
PHY of qca8084 can work on SGMII mode, the link topology:
the fourth PHY --- PCS --- PMA, the SGMII block includes PCS and PMA.

Either 10G-QXGMII or SGMII block of qca8084 connects with the interface
block(10G-QXGMII or SGMII) in MAC side.

Here is a problem as Russell mentioned earlier, we need to know which 
PHY device is changing the link status when the 10G-QXGMII mode is used,
since there are 4 PHYs, when one of them has the link change, there is 
no PHY device information passed to the PHYLINK, so the PCS driver don't
which PHY is changing link status and 10G-QXGMII mode don't know which
channel(mapped to PHY) should be configured.

would we add a field such as (int channel) in the struct phy_device?
so we can pass this information to PCS driver when the PHY link changed.

Thanks,