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!
