Re: [PATCH net-next v2 4/5] net: pcs: qcom-ipq9574: Add USXGMII interface mode support

Lei Wei
2024-12-10T13:25:34Z

On 12/7/2024 12:31 AM, Russell King (Oracle) wrote:
> On Sat, Dec 07, 2024 at 12:20:57AM +0800, Lei Wei wrote:
>> On 12/4/2024 11:38 PM, Russell King (Oracle) wrote:
>>> On Wed, Dec 04, 2024 at 10:43:56PM +0800, Lei Wei wrote:
>>>> +static int ipq_pcs_link_up_config_usxgmii(struct ipq_pcs *qpcs, int speed)
>>>> +{
>>> ...
>>>> + /* USXGMII only support full duplex mode */
>>>> + val |= XPCS_DUPLEX_FULL;
>>>
>>> Again... this restriction needs to be implemented in .pcs_validate() by
>>> knocking out the half-duplex link modes when using USXGMII mode.
>>>
>>> .pcs_validate() needs to be implemented whenever the PCS has
>>> restrictions beyond what is standard for the PHY interface mode.
>>>
>>
>> Currently, it seems there is no phylink_validate() call in
>> phylink_resolve(), to validate the resolved duplex/speed which is notified
>> by phydev when the PHY is linked up. So I am thinking to add this duplex
>> check in this link_up op, and return an appropriate error in case of
>> half-duplex. (Kindly correct me if I am wrong).
>
> Doing validation at that point is way too late.
>
> We don't want the PHY e.g. even advertising a half-duplex link mode if
> the system as a whole can not support half-duplex modes. If the system
> can't support half-duplex, then trying to trap it out at resolve time
> would be way too late - the media has already negotiated a half-duplex
> link, and that's that.
>
> Instead, phylink takes the approach of restricting the media
> advertisement according to the properties of the system, thereby
> preventing invalid configurations _way_ before we get to autoneg
> completion and calling phylink_resolve().
>

Yes, understand. I will avoid advertising half-duplex in the
pcs_validate() method for USXGMII. Thanks for the suggestion.