netdev - RE: [PATCH net-next 1/2] net: phy: aquantia: add rate

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:   Thu, 23 Jan 2020 07:38:23 +0000
From:   "Madalin Bucur (OSS)" <madalin.bucur@....nxp.com>
To:     Florian Fainelli <f.fainelli@...il.com>,
        "Madalin Bucur (OSS)" <madalin.bucur@....nxp.com>,
        "davem@...emloft.net" <davem@...emloft.net>
CC:     "andrew@...n.ch" <andrew@...n.ch>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "ykaukab@...e.de" <ykaukab@...e.de>
Subject: RE: [PATCH net-next 1/2] net: phy: aquantia: add rate_adaptation
 indication

> -----Original Message-----
> From: Florian Fainelli <f.fainelli@...il.com>
> Sent: Wednesday, January 22, 2020 7:58 PM
> To: Madalin Bucur (OSS) <madalin.bucur@....nxp.com>; davem@...emloft.net
> Cc: andrew@...n.ch; hkallweit1@...il.com; netdev@...r.kernel.org;
> ykaukab@...e.de
> Subject: Re: [PATCH net-next 1/2] net: phy: aquantia: add rate_adaptation
> indication
> 
> On 1/22/20 5:59 AM, Madalin Bucur wrote:
> > The AQR PHYs are able to perform rate adaptation between
> > the system interface and the line interfaces. When such
> > a PHY is deployed, the ethernet driver should not limit
> > the modes supported or advertised by the PHY. This patch
> > introduces the bit that allows checking for this feature
> > in the phy_device structure and its use for the Aquantia
> > PHYs.
> >
> > Signed-off-by: Madalin Bucur <madalin.bucur@....nxp.com>
> > ---
> >  drivers/net/phy/aquantia_main.c | 3 +++
> >  include/linux/phy.h             | 3 +++
> >  2 files changed, 6 insertions(+)
> >
> > diff --git a/drivers/net/phy/aquantia_main.c
> b/drivers/net/phy/aquantia_main.c
> > index 975789d9349d..36fdd523b758 100644
> > --- a/drivers/net/phy/aquantia_main.c
> > +++ b/drivers/net/phy/aquantia_main.c
> > @@ -209,6 +209,9 @@ static int aqr_config_aneg(struct phy_device
> *phydev)
> >  	u16 reg;
> >  	int ret;
> >
> > +	/* add here as this is called for all devices */
> > +	phydev->rate_adaptation = 1;
> 
> How about introducing a new PHY_SUPPORTS_RATE_ADAPTATION flag and you
> set that directly from the phy_driver entry? using the "flags" bitmask
> instead of adding another structure member to phy_device?

I've looked at the phydev->dev_flags use, it seemed to me that mostly it
is used to convey configuration options towards the PHY. Another problem
is that it's meaning seems to be opaque,  PHY specific. I wanted to avoid
trampling on a certain PHY hardcoded value and I turned my attention to
the bit fields in the phy_device. I noticed that there are already 12 bits
so due to alignment, the added bit is not adding extra size to the struct.
 
> > +
> >  	if (phydev->autoneg == AUTONEG_DISABLE)
> >  		return genphy_c45_pma_setup_forced(phydev);
> >
> > diff --git a/include/linux/phy.h b/include/linux/phy.h
> > index dd4a91f1feaa..2a5c202333fc 100644
> > --- a/include/linux/phy.h
> > +++ b/include/linux/phy.h
> > @@ -387,6 +387,9 @@ struct phy_device {
> >  	/* Interrupts are enabled */
> >  	unsigned interrupts:1;
> >
> > +	/* Rate adaptation in the PHY */
> > +	unsigned rate_adaptation:1;
> > +
> >  	enum phy_state state;
> >
> >  	u32 dev_flags;
> >
> 
> 
> --
> Florian