netdev - Re: [PATCH 1/4] net: phy: aquantia: Enable Tx/Rx pause frame support in aquantia PHY

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]
Date: Mon, 24 Jul 2023 12:47:18 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Revanth Kumar Uppala <ruppala@...dia.com>
Cc: Andrew Lunn <andrew@...n.ch>,
	"hkallweit1@...il.com" <hkallweit1@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	Narayan Reddy <narayanr@...dia.com>
Subject: Re: [PATCH 1/4] net: phy: aquantia: Enable Tx/Rx pause frame support
 in aquantia PHY

On Mon, Jul 24, 2023 at 11:29:18AM +0000, Revanth Kumar Uppala wrote:
> 
> 
> > -----Original Message-----
> > From: Andrew Lunn <andrew@...n.ch>
> > Sent: Wednesday, June 28, 2023 7:17 PM
> > To: Russell King (Oracle) <linux@...linux.org.uk>
> > Cc: Revanth Kumar Uppala <ruppala@...dia.com>; hkallweit1@...il.com;
> > netdev@...r.kernel.org; linux-tegra@...r.kernel.org; Narayan Reddy
> > <narayanr@...dia.com>
> > Subject: Re: [PATCH 1/4] net: phy: aquantia: Enable Tx/Rx pause frame support
> > in aquantia PHY
> > 
> > External email: Use caution opening links or attachments
> > 
> > 
> > On Wed, Jun 28, 2023 at 02:30:48PM +0100, Russell King (Oracle) wrote:
> > > On Wed, Jun 28, 2023 at 06:13:23PM +0530, Revanth Kumar Uppala wrote:
> > > > From: Narayan Reddy <narayanr@...dia.com>
> > > >
> > > > Enable flow control support using pause frames in aquantia phy driver.
> > > >
> > > > Signed-off-by: Narayan Reddy <narayanr@...dia.com>
> > > > Signed-off-by: Revanth Kumar Uppala <ruppala@...dia.com>
> > >
> > > I think this is over-complex.
> > >
> > > >  #define MDIO_PHYXS_VEND_IF_STATUS          0xe812
> > > >  #define MDIO_PHYXS_VEND_IF_STATUS_TYPE_MASK        GENMASK(7, 3)
> > > >  #define MDIO_PHYXS_VEND_IF_STATUS_TYPE_KR  0 @@ -583,6 +585,17
> > @@
> > > > static int aqr107_config_init(struct phy_device *phydev)
> > > >     if (!ret)
> > > >             aqr107_chip_info(phydev);
> > > >
> > > > +   /* Advertize flow control */
> > > > +   linkmode_set_bit(ETHTOOL_LINK_MODE_Pause_BIT, phydev-
> > >supported);
> > > > +   linkmode_set_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT, phydev-
> > >supported);
> > > > +   linkmode_copy(phydev->advertising, phydev->supported);
> > >
> > > This is the wrong place to be doing this, since pause support depends
> > > not only on the PHY but also on the MAC. There are phylib interfaces
> > > that MACs should call so that phylib knows that the MAC supports pause
> > > frames.
> > >
> > > Secondly, the PHY driver needs to tell phylib that the PHY supports
> > > pause frames, and that's done through either setting the .features
> > > member in the PHY driver, or by providing a .get_features
> > > implementation.
> > >
> > > Configuration of the pause advertisement should already be happening
> > > through the core phylib code.
> > 
> > I really should do a LPC netdev talk "Everybody gets pause wrong..."
> > 
> > genphy_c45_an_config_aneg() will configure pause advertisement. The PHY
> > driver does not need to configure it, if the PHY follows the standard and has the
> > configuration in the correct place. As Russell said, please check the PHYs ability
> > to advertise pause is being reported correctly, by .get_features, of the default
> > implementation of .get_features if that is being used. And then check your MAC
> > driver is also indicating it supports pause.
> From .get_features, it is not possible to check PHY's ability to advertise pause is being reported as there is no such register present for AQR PHY to check capabilities in its datasheet.
> Hence, we are directly configuring the pause frames from  aqr107_config_init().

... and thus creating a trashy implementation... so NAK.

The first thing to get straight is that in "normal" non-rate adapting
setups, pause frames are no different from normal Ethernet frames as
far as a PHY is concerned. The PHY should be doing absolutely nothing
special with pause frames - it should merely forward them to the MAC,
and it's the MAC that deals with pause frames.

The only thing that a non-rate adapting baseT PHY has to deal with is
the media advertisement and nothing else.

So, whether pause frames are supported has more to do with the MAC
than the PHY.

The way phylib works is that when a PHY is probed, phy_probe() will
set the Pause and Asym_Pause bits in the ->supported bitmap. It is
then up to the MAC driver (or phylink) to call phy_support_asym_pause()
or phy_support_sym_pause() to tell phylib what the MAC supports.

PHY drivers must *not* override this in their config_init() function,
and most certainly must not copy the supported bitmap to the advertising
bitmap there either.

If you need pause-mode rate adaption, this has nothing to do with the
media side, and ->supported and ->advertising are not relevant for
that. Non-phylink based MAC drivers have to use phy_get_rate_matching()
to find out whether the PHY will be using rate adaption and act
accordingly. phylink based MAC drivers have this dealt with for them
and as long as they do what phylink tells them to do, everything
should be fine.

So, basically, do not mess with setting bits in the ->supported bitmap
nor the ->advertising bitmap in config_init. It is wrong, and we will
NAK it.

Thanks.

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