[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+h21hqcz=QF8bq285JjdOn+gsOGvGSnDiWzDOS5-XGAGGGr9w@mail.gmail.com>
Date: Fri, 3 Jan 2020 21:13:07 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Matthew Wilcox <willy@...radead.org>, yu kuai <yukuai3@...wei.com>,
klassert@...nel.org, "David S. Miller" <davem@...emloft.net>,
Heiner Kallweit <hkallweit1@...il.com>,
Jakub Kicinski <jakub.kicinski@...ronome.com>,
hslester96@...il.com, mst@...hat.com, yang.wei9@....com.cn,
netdev <netdev@...r.kernel.org>,
lkml <linux-kernel@...r.kernel.org>, yi.zhang@...wei.com,
zhengbin13@...wei.com
Subject: Re: [PATCH] net: 3com: 3c59x: remove set but not used variable 'mii_reg1'
Hi Andrew,
On Fri, 3 Jan 2020 at 19:54, Andrew Lunn <andrew@...n.ch> wrote:
>
> I fully agree about the general case. However, reading the MII_BMSR
> should not have any side affects. It would be an odd Ethernet PHY if
> it did.
This is not really correct. As far as I know the clause 22 spec
requires the link status bit in BMSR to be latching low, so that
momentary losses of link can be caught post-facto.
In fact, even genphy_update_link treats this case:
/* The link state is latched low so that momentary link
* drops can be detected. Do not double-read the status
* in polling mode to detect such short link drops.
*/
if (!phy_polling_mode(phydev)) {
status = phy_read(phydev, MII_BMSR);
if (status < 0)
return status;
else if (status & BMSR_LSTATUS)
goto done;
}
So no, reading BMSR generally is not without side effects, and that
does not make the PHY odd.
Whether clearing the latching-low status bits is of any relevance to
the 3com 3c59x driver bookkeeping, that I have not clue.
>
> Andrew
Regards,
-Vladimir
Powered by blists - more mailing lists