[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yg1MfpK5PwiAbGfU@lunn.ch>
Date: Wed, 16 Feb 2022 20:11:58 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Alvin Šipraga <ALSI@...g-olufsen.dk>
Cc: Luiz Angelo Daros de Luca <luizluca@...il.com>,
Alvin Šipraga <alvin@...s.dk>,
Linus Walleij <linus.walleij@...aro.org>,
Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
Vladimir Oltean <olteanv@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Michael Rasmussen <MIR@...g-olufsen.dk>,
Arınç ÜNAL <arinc.unal@...nc9.com>,
"open list:NETWORKING DRIVERS" <netdev@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 0/2] net: dsa: realtek: fix PHY register read
corruption
> Hmm OK. Actually I'm a bit confused about the mdio_lock: can you explain
> what it's guarding against, for someone unfamiliar with MDIO?
The more normal use case for MDIO is for PHYs, not switches. There can
be multiple PHYs on one MDIO bus. And these PHYs each have there own
state machine in phylib. At any point in time, that state machine can
request the driver to do something, like poll the PHY status, does it
have link? To prevent two PHY drivers trying to use the MDIO bus at
the same time, there is an MDIO lock. At the beginning of an MDIO
transaction, the lock is taken. And the end of the transaction,
reading or writing one register of a device on the bus, the lock is
released.
So the MDIO lock simply ensures there is only one user of the MDIO bus
at one time, for a single read or write.
For PHYs this is sufficient. For switches, sometimes you need
additional protection. The granularity of an access might not be a
single register read or a write. It could be you need to read or write
a few registers in an atomic way. If that is the case, you need a lock
at a higher level.
Andrew
Powered by blists - more mailing lists