netdev - Re: [PATCH net-next v5 02/23] net: phy: add genphy_c45_read_eee

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, 6 Feb 2023 14:46:19 +0000
From:   <Arun.Ramadoss@...rochip.com>
To:     <olteanv@...il.com>, <UNGLinuxDriver@...rochip.com>,
        <vivien.didelot@...il.com>, <andrew@...n.ch>,
        <f.fainelli@...il.com>, <kuba@...nel.org>, <wei.fang@....com>,
        <edumazet@...gle.com>, <pabeni@...hat.com>,
        <o.rempel@...gutronix.de>, <Woojung.Huh@...rochip.com>,
        <davem@...emloft.net>, <hkallweit1@...il.com>
CC:     <linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>,
        <intel-wired-lan@...ts.osuosl.org>, <kernel@...gutronix.de>
Subject: Re: [PATCH net-next v5 02/23] net: phy: add
 genphy_c45_read_eee_abilities() function

Hi Oleksij,

On Mon, 2023-02-06 at 14:50 +0100, Oleksij Rempel wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
> 
> Add generic function for EEE abilities defined by IEEE 802.3
> specification. For now following registers are supported:
> - IEEE 802.3-2018 45.2.3.10 EEE control and capability 1 (Register
> 3.20)
> - IEEE 802.3cg-2019 45.2.1.186b 10BASE-T1L PMA status register
>   (Register 1.2295)
> 
> Since I was not able to find any flag signaling support of these
> registers, we should detect link mode abilities first and then based
> on
> these abilities doing EEE link modes detection.
> 
> Results of EEE ability detection will be stored into new variable
> phydev->supported_eee.
> 
> Signed-off-by: Oleksij Rempel <o.rempel@...gutronix.de>
> ---
>  drivers/net/phy/phy-c45.c    | 70
> ++++++++++++++++++++++++++++++++++++
>  drivers/net/phy/phy_device.c | 16 +++++++++
>  include/linux/mdio.h         | 26 ++++++++++++++
>  include/linux/phy.h          |  5 +++
>  4 files changed, 117 insertions(+)
> 
> diff --git a/drivers/net/phy/phy-c45.c b/drivers/net/phy/phy-c45.c
> index 9f9565a4819d..3ae642d3ae14 100644
> --- a/drivers/net/phy/phy-c45.c
> +++ b/drivers/net/phy/phy-c45.c
> @@ -661,6 +661,76 @@ int genphy_c45_read_mdix(struct phy_device
> *phydev)
>  }
>  EXPORT_SYMBOL_GPL(genphy_c45_read_mdix);
> 
> +/**
> + * genphy_c45_read_eee_cap1 - read supported EEE link modes from
> register 3.20
> + * @phydev: target phy_device struct
> + */
> +static int genphy_c45_read_eee_cap1(struct phy_device *phydev)
> +{
> +       int val;
> +
> +       /* IEEE 802.3-2018 45.2.3.10 EEE control and capability 1
> +        * (Register 3.20)
> +        */
> +       val = phy_read_mmd(phydev, MDIO_MMD_PCS, MDIO_PCS_EEE_ABLE);
> +       if (val < 0)
> +               return val;
> +
> +       /* The 802.3 2018 standard says the top 2 bits are reserved
> and should
> +        * read as 0. Also, it seems unlikely anybody will build a
> PHY which
> +        * supports 100GBASE-R deep sleep all the way down to
> 100BASE-TX EEE.
> +        * If MDIO_PCS_EEE_ABLE is 0xffff assume EEE is not
> supported.
> +        */
> +       if (val == GENMASK(15, 0))

nit: Magic number can be replaced by macro.

> +               return 0;
> +
> +       mii_eee_cap1_mod_linkmode_t(phydev->supported_eee, val);
> +
> +       /* Some buggy devices indicate EEE link modes in
> MDIO_PCS_EEE_ABLE
> +        * which they don't support as indicated by BMSR, ESTATUS
> etc.
> +        */
> +       linkmode_and(phydev->supported_eee, phydev->supported_eee,
> +                    phydev->supported);
> +
> +       return 0;
> +}
> +
> +
>