Re: [RFC PATCH net v1] net: phy: aquantia: Set phy speed to 2.5gbps for AQR115c

["Abhishek Chauhan (ABC)" <quic_abchauha@quicinc.com>]

On 9/17/2024 1:57 PM, Abhishek Chauhan (ABC) wrote:
> 
> 
> On 9/17/2024 2:31 AM, Russell King (Oracle) wrote:
>> On Fri, Sep 13, 2024 at 06:35:17PM +0200, Andrew Lunn wrote:
>>> On Fri, Sep 13, 2024 at 09:12:13AM -0700, Abhishek Chauhan (ABC) wrote:
>>>> On 9/13/2024 1:01 AM, Maxime Chevallier wrote:
>>>>> Hi,
>>>>>
>>>>> On Thu, 12 Sep 2024 18:16:35 -0700
>>>>> Abhishek Chauhan <quic_abchauha@quicinc.com> wrote:
>>>>>
>>>>>> Recently we observed that aquantia AQR115c always comes up in
>>>>>> 100Mbps mode. AQR115c aquantia chip supports max speed up to
>>>>>> 2.5Gbps. Today the AQR115c configuration is done through
>>>>>> aqr113c_config_init which internally calls aqr107_config_init.
>>>>>> aqr113c and aqr107 are both capable of 10Gbps. Whereas AQR115c
>>>>>> supprts max speed of 2.5Gbps only.
>>>>>>
>>>>>> Fixes: 0ebc581f8a4b ("net: phy: aquantia: add support for aqr115c")
>>>>>> Signed-off-by: Abhishek Chauhan <quic_abchauha@quicinc.com>
>>>>>> ---
>>>>>>  drivers/net/phy/aquantia/aquantia_main.c | 7 +++++++
>>>>>>  1 file changed, 7 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/net/phy/aquantia/aquantia_main.c b/drivers/net/phy/aquantia/aquantia_main.c
>>>>>> index e982e9ce44a5..9afc041dbb64 100644
>>>>>> --- a/drivers/net/phy/aquantia/aquantia_main.c
>>>>>> +++ b/drivers/net/phy/aquantia/aquantia_main.c
>>>>>> @@ -499,6 +499,12 @@ static int aqr107_config_init(struct phy_device *phydev)
>>>>>>  	if (!ret)
>>>>>>  		aqr107_chip_info(phydev);
>>>>>>  
>>>>>> +	/* AQR115c supports speed up to 2.5Gbps */
>>>>>> +	if (phydev->interface == PHY_INTERFACE_MODE_2500BASEX) {
>>>>>> +		phy_set_max_speed(phydev, SPEED_2500);
>>>>>> +		phydev->autoneg = AUTONEG_ENABLE;
>>>>>> +	}
>>>>>> +
>>>>>
>>>>> If I get your commit log right, the code above will also apply for
>>>>> ASQR107, AQR113 and so on, don't you risk breaking these PHYs if they
>>>>> are in 2500BASEX mode at boot?
>>>>>
>>>>
>>>> I was thinking of the same. That this might break something here for other Phy chip. 
>>>> As every phy shares the same config init. Hence the reason for RFC. 
>>>>
>>>>> Besides that, if the PHY switches between SGMII and 2500BASEX
>>>>> dynamically depending on the link speed, it could be that it's
>>>>> configured by default in SGMII, hence this check will be missed.
>>>>>
>>>>>
>>>> I think the better way is to have AQR115c its own config_init which sets 
>>>> the max speed to 2.5Gbps and then call aqr113c_config_init . 
>>>
>>> phy_set_max_speed(phydev, SPEED_2500) is something a MAC does, not a
>>> PHY. It is a way for the MAC to say is supports less than the PHY. I
>>> would say the current aqcs109_config_init() is doing this wrong.
>>
>> Agreed on two points:
>>
>> 1) phy_set_max_speed() is documented as a function that the MAC will
>> call.
>>
>> 2) calling phy_set_max_speed() in .config_init() is way too late for
>> phylink. .config_init() is called from phy_init_hw(), which happens
>> after the PHY has been attached. However, phylink needs to know what
>> the PHY supports _before_ that, especially for any PHY that is on a
>> SFP, so it can determine what interface to use for the PHY.
>>
>> So, as Andrew says, the current aqcs109_config_init(), and it seems
>> aqr111_config_init() are both broken.
>>
>> The PHY driver needs to indicate to phylib what is supported by the
>> PHY no later than the .get_features() method.
>>
> 
> Noted!. Makes sense. thanks for your review, Russell. 
> We are in the process of figuring out what the phy chip is reporting as 
> its features. Once done i will raise a clean patch for upstream review. 
> 

Russell and Andrew 

we added prints and understood what the phy is reporting as part of the 
genphy_c45_pma_read_abilities 

[   12.041576] MDIO_STAT2: 0xb301


[   12.050722] MDIO_PMA_EXTABLE: 0x40fc

From the PMA extensible register we see that the phy is reporting that it supports

#define MDIO_PMA_EXTABLE_10GBT		0x0004	/* 10GBASE-T ability */
#define MDIO_PMA_EXTABLE_10GBKX4	0x0008	/* 10GBASE-KX4 ability */
#define MDIO_PMA_EXTABLE_10GBKR		0x0010	/* 10GBASE-KR ability */
#define MDIO_PMA_EXTABLE_1000BT		0x0020	/* 1000BASE-T ability */
#define MDIO_PMA_EXTABLE_1000BKX	0x0040	/* 1000BASE-KX ability */
#define MDIO_PMA_EXTABLE_100BTX		0x0080	/* 100BASE-TX ability */
#define MDIO_PMA_EXTABLE_NBT		0x4000  /* 2.5/5GBASE-T ability */

[   12.060265] MDIO_PMA_NG_EXTABLE: 0x3

/* 2.5G/5G Extended abilities register. */
#define MDIO_PMA_NG_EXTABLE_2_5GBT	0x0001	/* 2.5GBASET ability */
#define MDIO_PMA_NG_EXTABLE_5GBT	0x0002	/* 5GBASET ability */

I feel that the phy here is incorrectly reporting all these abilities as 
AQR115c supports speeds only upto 2.5Gbps 
https://www.marvell.com/content/dam/marvell/en/public-collateral/transceivers/marvell-phys-transceivers-aqrate-gen4-product-brief.pdf

AQR115C / AQR115 Single port, 2.5Gbps / 1Gbps / 100Mbps / 10Mbps 7 x 7 mm / 7 x 11 mm

I feel like get_features for AQR115c is reporting wrong modes and hence the 
link is coming up and is negotiated at 100Mbps. (Misbehavior from AQR115c)

From the MAC perspective we have ensure our max capabilities are 2.5 Gbps 
by setting the below from stmmac driver 
phylink_limit_mac_speed(config, 2500);

I am thinking of solving this problem by having 
custom .get_features in the AQR115c driver to only set supported speeds 
upto 2.5gbps 

let me know what you think ? 
 

>> Thanks.
>>