All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Biju Das <biju.das.jz@bp.renesas.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	"biju.das.au" <biju.das.au@gmail.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Ovidiu Panait <ovidiu.panait.rb@renesas.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	"linux-renesas-soc@vger.kernel.org"
	<linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH net-next] net: phy: call phy_init_hw() in phy resume path
Date: Sat, 11 Apr 2026 00:49:14 +0100	[thread overview]
Message-ID: <admMethCSjOQhu8g@shell.armlinux.org.uk> (raw)
In-Reply-To: <TY3PR01MB11346B6680E5952BD7B7078CA86592@TY3PR01MB11346.jpnprd01.prod.outlook.com>

On Fri, Apr 10, 2026 at 04:41:08PM +0000, Biju Das wrote:
> Hi Andrew,
> 
> > -----Original Message-----
> > From: Andrew Lunn <andrew@lunn.ch>
> > Sent: 10 April 2026 16:15
> > Subject: Re: [PATCH net-next] net: phy: call phy_init_hw() in phy resume path
> > 
> > > Apart from that, looks fine to me - it seems some paths call
> > > phy_init_hw() can be called with or without phydev->lock held, and
> > > this one will call it with the lock held which seems to be okay.
> > 
> > Haven't we had deadlocks in this area before?
> > 
> > Please test with CONFIG_PROVE_LOCKING enabled.
> 
> I have n't faced any issue with micrel phy. But my collegue
> got the below issue with Microsemi phy. It doesn't finish the boot.
> 
> drivers/net/phy/mscc/mscc_main.c 

Looking at this driver, I'm wondering why it's taking phydev->lock
in vsc85xx_edge_rate_cntl_set()... phy_modify_paged() is already
a fully locked atomic operation (it takes the bus lock) and taking
phydev->lock gains nothing.

vsc85xx_mac_if_set() is a different matter, and this _should_ be
using phy_modify() to atomically change MSCC_PHY_EXT_PHY_CNTL_1.
phydev->lock doesn't guarantee that e.g. userspace won't access
the register behind this code's back.

vsc8531_pre_init_seq_set() is a repeat of vsc85xx_edge_rate_cntl_set()
except with phy_select_page()..phy_restore_page() which does the
necessary bus locking to ensure the entire sequence is done atomically.
Ditto vsc85xx_eee_init_seq_set().

So, I question whether any of the functions in this driver actually
have a valid reason to take phydev->lock - looks to me like a not
very well written driver.

In cases like this, I don't think we should make things more
difficult in the core just because we have a lockdep splat when that
can be avoided by killing off unnecessary locking.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

  reply	other threads:[~2026-04-10 23:49 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-10 14:29 [PATCH net-next] net: phy: call phy_init_hw() in phy resume path Biju
2026-04-10 14:51 ` Russell King (Oracle)
2026-04-10 14:55   ` Russell King (Oracle)
2026-04-10 17:27     ` Biju Das
2026-04-10 23:51       ` Russell King (Oracle)
2026-04-10 15:15   ` Andrew Lunn
2026-04-10 15:22     ` Russell King (Oracle)
2026-04-10 15:38       ` Biju Das
2026-04-10 16:00       ` Andrew Lunn
2026-04-10 16:41     ` Biju Das
2026-04-10 23:49       ` Russell King (Oracle) [this message]
2026-04-11 13:50         ` Andrew Lunn
2026-04-11 14:32           ` Biju Das
2026-04-11 16:46           ` Russell King (Oracle)
2026-04-12 12:05             ` Biju Das
2026-04-12 12:55               ` Russell King (Oracle)
2026-04-10 17:00   ` Florian Fainelli

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=admMethCSjOQhu8g@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew@lunn.ch \
    --cc=biju.das.au@gmail.com \
    --cc=biju.das.jz@bp.renesas.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=geert+renesas@glider.be \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=ovidiu.panait.rb@renesas.com \
    --cc=pabeni@redhat.com \
    --cc=prabhakar.mahadev-lad.rj@bp.renesas.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.