net: phy: switch to lockdep_assert_held in phylib

PATCH In review Heiner Kallweit 3 participants 3 messages Nov 12, 2018 – Nov 13, 2018

Subsystems (3)

Networking Network drivers Ethernet PHY

lore

Share & tools

lore

Heiner Kallweit

author maintainer

2018-11-12 07:23 UTC #0 lore raw

PATCH 1/1 net: phy: switch to lockdep_assert_held in phylib

These checks are relevant during development / testing only, therefore switch to lockdep_assert_held and friends.

Signed-off-by Heiner Kallweit <[email protected]>

---
 drivers/net/phy/mdio_bus.c   | 4 ++--
 drivers/net/phy/phy.c        | 2 +-
 drivers/net/phy/phy_device.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

drivers/net/phy/mdio_bus.c +2 -2

index 2e59a8419..5cb06f021 100644
@@ -541,7 +541,7 @@ int __mdiobus_read(struct mii_bus *bus, int addr, u32 regnum)
 {
 	int retval;
 
-	WARN_ON_ONCE(!mutex_is_locked(&bus->mdio_lock));
+	lockdep_assert_held_once(&bus->mdio_lock);
 
 	retval = bus->read(bus, addr, regnum);

@@ -566,7 +566,7 @@ int __mdiobus_write(struct mii_bus *bus, int addr, u32 regnum, u16 val)
 {
 	int err;
 
-	WARN_ON_ONCE(!mutex_is_locked(&bus->mdio_lock));
+	lockdep_assert_held_once(&bus->mdio_lock);
 
 	err = bus->write(bus, addr, regnum, val);

drivers/net/phy/phy.c +1 -1

index 083977d2f..b0b3c9ac4 100644
@@ -514,7 +514,7 @@ static int phy_check_link_status(struct phy_device *phydev)
 {
 	int err;
 
-	WARN_ON(!mutex_is_locked(&phydev->lock));
+	lockdep_assert_held(&phydev->lock);
 
 	err = phy_read_status(phydev);
 	if (err)

drivers/net/phy/phy_device.c +1 -1

index 0f56d408b..1c20a0df3 100644
@@ -1340,7 +1340,7 @@ int __phy_resume(struct phy_device *phydev)
 	struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver);
 	int ret = 0;
 
-	WARN_ON(!mutex_is_locked(&phydev->lock));
+	lockdep_assert_held(&phydev->lock);
 
 	if (phydev->drv && phydrv->resume)
 		ret = phydrv->resume(phydev);

Signature · 1 line

2.19.1

I don't think there is a clear right/wrong here. This is not hot path code. The cost for checking the lock is held is very small compared to the actual MDIO transaction. So i don't think we really need to optimise this. I do sometimes build with lockdep on, but not always. So it is good to know when locking is broken on normal builds.

Florian, what do you think?

Andrew

Florian Fainelli

2018-11-13 04:53 UTC #2 lore raw

Quoted 14 lines · Andrew Lunn

drivers/net/phy/mdio_bus.c int __mdiobus_read(struct mii_bus *bus, int addr, u32 regnum) · line 544
Quoted 10 lines · Heiner Kallweit
drivers/net/phy/mdio_bus.c +1 -1
index 2e59a8419..5cb06f021 100644
@@ -541,7 +541,7 @@ int __mdiobus_read(struct mii_bus *bus, int addr, u32 regnum)
 {
 	int retval;
 
-	WARN_ON_ONCE(!mutex_is_locked(&bus->mdio_lock));
+	lockdep_assert_held_once(&bus->mdio_lock);
Hi Heiner

Quoted 7 lines

I don't think there is a clear right/wrong here. This is not hot path code. The cost for checking the lock is held is very small compared to the actual MDIO transaction. So i don't think we really need to optimise this. I do sometimes build with lockdep on, but not always. So it is good to know when locking is broken on normal builds.
Florian, what do you think?

lockdep_assert_held_once() also looks at debug_locks (global variable) so it sounds like in that regard, it would be superior in that it allows an user-configurable, general debugging facility to behave consistently as opposed to always having opt-in debugging within the mdio_bus.c file, but that also has a lot of value. I have to admit debugging MDIO bus locking issues is not particularly fun, so I would probably stick with the current code in that regard.

Signature · 1 line

Florian