On 05.01.2019 18:33, Andrew Lunn wrote:
> 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.faine...@gmail.com>
>> Signed-off-by: Heiner Kallweit <hkallwe...@gmail.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.
>
The only caller of get_phy_id() is get_phy_device() which translates
a PHY ID of 0xffffffff back to -ENODEV. So this should be safe and
it avoids some overhead. But right, this is more net-next stuff.
Regarding net vs. net-next:
Quite a few of the latest net commits don't meet the strict criteria
for a fix (as documented). Means: The risk that a problem could
occur isn't sufficient, at least one user has to actually face a
problem. So it seems net vs. net-next criteria is somewhat flexible.
Therefore I wasn't sure in this case.
>> +
>> + /* 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?
>
Indeed, in a worst case scenario this could happen, provided that:
- there's no mask of MDIO addresses to probe
- the MDIO bus read operation returns 0xffff in case of an error instead
of a proper errno. To mitigate this we could treat 0xffff as failure
because normally BMCR can never have this value.
> Thanks
> Andrew
>
Heiner
