On Sat, Jul 15, 2023 at 1:27 AM Andrew Lunn <andrew@xxxxxxx> wrote: > > On Fri, Jul 14, 2023 at 09:09:14AM +0300, Alexandru Ardelean wrote: > > On Thu, Jul 13, 2023 at 11:35 PM Andrew Lunn <andrew@xxxxxxx> wrote: > > > > > > > +set_reg: > > > > + mutex_lock(&phydev->lock); > > > > + rc = phy_modify_paged(phydev, MSCC_PHY_PAGE_EXTENDED_GPIO, > > > > + VSC8531_CLKOUT_CNTL, mask, set); > > > > + mutex_unlock(&phydev->lock); > > > > > > What is this mutex protecting? > > > > This was inspired by vsc85xx_edge_rate_cntl_set(). > > Which has the same format. Good news. Removing this mutex works on a 5.10 kernel, with no issues. > > phy_modify_paged() locks the MDIO bus while it swaps the page, so > nothing else can use it. That also protects the read/modify/write. > > Nothing is modifying phydev, so the lock is not needed for that > either. I remembered what I was doing wrong in that version that had issues with the lock. I was doing some manual page changes, with phy_base_read/()phy_base_write() functions, which are in this file. These functions have a warning + dump_stack() for when the "phydev->mdio.bus->mdio_lock" is not held). That threw me off initially. > > > I'll re-test with this lock removed. > > I may be misremembering (or maybe I did something silly at some > > point), but there was a weird stack-trace warning before adding this > > lock there. > > This was with a 5.10.116 kernel version. > > This patch is for net-next, please test there. I've been testing on a Renesas board CIP project. Kernel version (on our board is actually 5.10.83 ; I get them confused since 5.10.xxx seems to be used here-n-there). The kernel is here: https://github.com/renesas-rz/rz_linux-cip/tree/rz-5.10-cip3 I'm trying to backport some ARCH patches, so that the board boots up. I "think" I'm half way there; now the kernel prints something to console and then stops (that's progress from no prints). Let's see if we get a different consensus on Rob't suggestion; this patch may require a different V3 :) > > When testing for locking issues, and when doing development in > general, it is a good idea to turn on CONFIG_PROVE_LOCKING and > CONFIG_DEBUG_ATOMIC_SLEEP. > > Andrew
