Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8;
Message-ID: <cde29373-b341-454a-867c-f6bed051ca95@quicinc.com>
Date:   Tue, 21 Nov 2023 19:01:02 +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>
CC:     Andrew Lunn <andrew@lunn.ch>, <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>
 <ZVsnFWzi6KMXpJOj@shell.armlinux.org.uk>
From:   Jie Luo <quic_luoj@quicinc.com>
In-Reply-To: <ZVsnFWzi6KMXpJOj@shell.armlinux.org.uk>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 11/20/2023 5:29 PM, Russell King (Oracle) wrote:
> On Mon, Nov 20, 2023 at 04:49:59PM +0800, Jie Luo wrote:
>>
>>
>> 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.
> 
> Note that phylink_pcs does *not* cover any PCS on the PHY device side
> of the link. It only covers a PCS on the MAC side.

Ok, even there is only one XPCS multiplex with 4 MACs, we should create
4 PCS instances for 4 MACs.

> 
>> 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.
> 
> Nothing in phylink nor phylib is setup to deal with "channels" within
> a PHY. The model assumes that a network interface consists of exactly
> one MAC associated with one active PHY.
> 
> As there are 4 PHYs, phylib will expect there to be four PHY devices,
> and there will be expected to be four phylink instances.
> 
make sense, thanks Russell.