summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/stackcollapse.py
diff options
context:
space:
mode:
authorSean Anderson <sean.anderson@linux.dev>2025-07-07 15:58:03 -0400
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2025-07-24 08:58:35 +0200
commit75e1b2079ef0653a2f7aa69be515d86b7faf1908 (patch)
treefe460d7e215e60ad9138bc5065d450ee08b0cede /tools/perf/scripts/python/stackcollapse.py
parent67a167a6b8b45607bc34aa541d1c75097d18d460 (diff)
downloadkernel-75e1b2079ef0653a2f7aa69be515d86b7faf1908.tar.gz
net: phy: Don't register LEDs for genphy
[ Upstream commit f0f2b992d8185a0366be951685e08643aae17d6d ] If a PHY has no driver, the genphy driver is probed/removed directly in phy_attach/detach. If the PHY's ofnode has an "leds" subnode, then the LEDs will be (un)registered when probing/removing the genphy driver. This could occur if the leds are for a non-generic driver that isn't loaded for whatever reason. Synchronously removing the PHY device in phy_detach leads to the following deadlock: rtnl_lock() ndo_close() ... phy_detach() phy_remove() phy_leds_unregister() led_classdev_unregister() led_trigger_set() netdev_trigger_deactivate() unregister_netdevice_notifier() rtnl_lock() There is a corresponding deadlock on the open/register side of things (and that one is reported by lockdep), but it requires a race while this one is deterministic. Generic PHYs do not support LEDs anyway, so don't bother registering them. Fixes: 01e5b728e9e4 ("net: phy: Add a binding for PHY LEDs") Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Link: https://patch.msgid.link/20250707195803.666097-1-sean.anderson@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions