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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2c28f9c2-c555-422d-8d57-6a555f03e6f7@quicinc.com>
Date: Tue, 10 Dec 2024 21:25:09 +0800
From: Lei Wei <quic_leiwei@...cinc.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
CC: "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet
	<edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni
	<pabeni@...hat.com>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski
	<krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>, Andrew Lunn
	<andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>, <netdev@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <quic_kkumarcs@...cinc.com>, <quic_suruchia@...cinc.com>,
        <quic_pavir@...cinc.com>, <quic_linchen@...cinc.com>,
        <quic_luoj@...cinc.com>, <srinivas.kandagatla@...aro.org>,
        <bartosz.golaszewski@...aro.org>, <vsmuthu@....qualcomm.com>,
        <john@...ozen.org>, <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH net-next v2 4/5] net: pcs: qcom-ipq9574: Add USXGMII
 interface mode support



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.