[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190105173347.GA30438@lunn.ch>
Date: Sat, 5 Jan 2019 18:33:47 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Heiner Kallweit <hkallweit1@...il.com>
Cc: Florian Fainelli <f.fainelli@...il.com>,
David Miller <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net] net: phy: ensure PHY is powered up when reading ID
registers
On Sat, Jan 05, 2019 at 02:21:03PM +0100, Heiner Kallweit wrote:
> During a bug analysis we came across the fact that there's no guarantee
> that reading from the ID registers returns a valid value if PHY is
> powered down. When reading invalid values we may load no or the wrong
> PHY driver. Therefore let's play safe and power up the PHY before
> reading the ID registers in case PHY is powered down.
>
> Suggested-by: Florian Fainelli <f.fainelli@...il.com>
> Signed-off-by: Heiner Kallweit <hkallweit1@...il.com>
> ---
> drivers/net/phy/phy_device.c | 23 +++++++++++++----------
> 1 file changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 9560a2b84..d4702313d 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -754,19 +754,22 @@ static int get_phy_id(struct mii_bus *bus, int addr, u32 *phy_id,
> if (is_c45)
> return get_phy_c45_ids(bus, addr, phy_id, c45_ids);
Hi Heiner
>
> + phy_reg = mdiobus_read(bus, addr, MII_BMCR);
> + if (phy_reg < 0)
> + /* returning -ENODEV allows to continue bus-scanning */
> + return (phy_reg == -EIO || phy_reg == -ENODEV) ? -ENODEV : -EIO;
It would be better to copy the code verbatim. I know we have had
issues with scanning depending on the return value. So changing the
return value should be in a separate patch. I would also not make it a
fix, but something for net-next, so it gets more testing.
> +
> + /* PHY may be powered down and ID registers invalid */
> + if (phy_reg & BMCR_PDOWN) {
> + mdiobus_write(bus, addr, MII_BMCR, phy_reg & ~BMCR_PDOWN);
> + /* give the PHY some time to resume */
> + msleep(100);
> + }
> +
Is this potentially slowing the scan down to 100ms * 32, if the read
of MII_BMCR always returns 0xffff?
Thanks
Andrew
Powered by blists - more mailing lists