From: Andrew Lunn <andrew@lunn.ch>
To: "Alvin Šipraga" <ALSI@bang-olufsen.dk>
Cc: "Luiz Angelo Daros de Luca" <luizluca@gmail.com>,
"Alvin Šipraga" <alvin@pqrs.dk>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Vivien Didelot" <vivien.didelot@gmail.com>,
"Florian Fainelli" <f.fainelli@gmail.com>,
"Vladimir Oltean" <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
"Jakub Kicinski" <kuba@kernel.org>,
"Michael Rasmussen" <MIR@bang-olufsen.dk>,
"Arınç ÜNAL" <arinc.unal@arinc9.com>,
"open list:NETWORKING DRIVERS" <netdev@vger.kernel.org>,
"open list" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next 0/2] net: dsa: realtek: fix PHY register read corruption
Date: Thu, 17 Feb 2022 14:32:11 +0100 [thread overview]
Message-ID: <Yg5OW03cPFTMhcmw@lunn.ch> (raw)
In-Reply-To: <877d9tr66o.fsf@bang-olufsen.dk>
> If you have the patience to answer a few more questions:
>
> 1. You mentioned in an earlier mail that the mdio_lock is used mostly by
> PHY drivers to synchronize their access to the MDIO bus, for a single
> read or write. You also mentioned that for switches which have a more
> involved access pattern (for instance to access switch management
> registers), a higher lock is required. In realtek-mdio this is the case:
> we do a couple of reads and writes over the MDIO bus to access the
> switch registers. Moreover, the mdio_lock is held for the duration of
> these MDIO bus reads/writes. Do you mean to say that one should rather
> take a higher-level lock and only lock/unlock the mdio_lock on a
> per-read or per-write basis? Put another way, should this:
>
> static int realtek_mdio_read(void *ctx, u32 reg, u32 *val)
> {
> /* ... */
>
> mutex_lock(&bus->mdio_lock);
>
> bus->write(bus, priv->mdio_addr, ...);
It would be better to use __mdiobus_write()
> bus->write(bus, priv->mdio_addr, ...);
> bus->write(bus, priv->mdio_addr, ...);
> bus->read(bus, priv->mdio_addr, ...);
__mdiobus_read()
> /* ... */
>
> mutex_unlock(&bus->mdio_lock);
>
> return ret;
> }
You can do this.
> rather look like this?:
>
> static int realtek_mdio_read(void *ctx, u32 reg, u32 *val)
> {
> /* ... */
>
> mutex_lock(&my_realtek_driver_lock); /* synchronize concurrent realtek_mdio_{read,write} */
>
> mdiobus_write(bus, priv->mdio_addr, ...); /* mdio_lock locked/unlocked here */
> mdiobus_write(bus, priv->mdio_addr, ...); /* ditto */
> mdiobus_write(bus, priv->mdio_addr, ...); /* ditto */
> mdiobus_read(bus, priv->mdio_addr, ...); /* ditto */
>
> /* ... */
>
> mutex_unlock(&my_realtek_driver_lock);
>
> return ret;
> }
This would also work. The advantage of this is when you have multiple
switches on one MDIO bus, you can allow parallel operations on those
switches. Also, if there are PHYs on the MDIO bus as well as the
switch, the PHYs can be accessed as well. If you are only doing 3
writes and read, it probably does not matter. If you are going to do a
lot of accesses, maybe read all the MIB values, allowing access to the
PHYs at the same time would be nice.
> 2. Is the nested locking only relevant for DSA switches which offer
> another MDIO bus? Or should all switch drivers do this, on the basis
> that, feasibly, one could connect my Realtek switch to the MDIO bus of a
> mv88e6xxx switch? In that case, and assuming the latter form of
> raeltek_mdio_read above, should one use the mdiobus_{read,write}_nested
> functions instead?
I would suggest you start with plain mdiobus_{read,write}. Using the
_nested could potentially hide a deadlock. If somebody does build
hardware with this sort of chaining, we can change to the _nested
calls.
Andrew
next prev parent reply other threads:[~2022-02-17 13:32 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-16 16:04 [PATCH net-next 0/2] net: dsa: realtek: fix PHY register read corruption Alvin Šipraga
2022-02-16 16:04 ` [PATCH net-next 1/2] net: dsa: realtek: allow subdrivers to externally lock regmap Alvin Šipraga
2022-02-16 16:05 ` [PATCH net-next 2/2] net: dsa: realtek: rtl8365mb: serialize indirect PHY register access Alvin Šipraga
2022-02-16 23:39 ` Vladimir Oltean
2022-02-17 3:01 ` Luiz Angelo Daros de Luca
2022-02-17 8:16 ` Alvin Šipraga
2022-02-22 0:18 ` Luiz Angelo Daros de Luca
2022-02-17 7:41 ` Alvin Šipraga
2022-02-17 11:17 ` Vladimir Oltean
2022-02-17 12:51 ` Alvin Šipraga
2022-02-21 14:50 ` Alvin Šipraga
2022-02-21 17:15 ` Vladimir Oltean
2022-02-21 18:10 ` Alvin Šipraga
2022-02-16 17:57 ` [PATCH net-next 0/2] net: dsa: realtek: fix PHY register read corruption Luiz Angelo Daros de Luca
2022-02-16 18:23 ` Alvin Šipraga
2022-02-16 19:11 ` Andrew Lunn
2022-02-16 19:26 ` Alvin Šipraga
2022-02-17 12:12 ` Andrew Lunn
2022-02-17 13:09 ` Alvin Šipraga
2022-02-17 13:32 ` Andrew Lunn [this message]
2022-02-17 4:28 ` Luiz Angelo Daros de Luca
2022-02-17 7:53 ` Alvin Šipraga
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yg5OW03cPFTMhcmw@lunn.ch \
--to=andrew@lunn.ch \
--cc=ALSI@bang-olufsen.dk \
--cc=MIR@bang-olufsen.dk \
--cc=alvin@pqrs.dk \
--cc=arinc.unal@arinc9.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luizluca@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=vivien.didelot@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).