[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <af4fa39e31a6275a07c577cb3d7fa5f114bdda05.camel@microchip.com>
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;
> +}
> +
> +
>
Powered by blists - more mailing lists