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: <Z1Mm8nBR_sYyzBUh@shell.armlinux.org.uk>
Date: Fri, 6 Dec 2024 16:31:46 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Lei Wei <quic_leiwei@...cinc.com>
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 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().

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ