Re: [PATCH v14 28/38] phy: core: add notifier infrastructure
flat view
From: sashiko-bot@kernel.org
Date: 2026-08-14 05:14:54
Also in:
linux-devicetree
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] AB-BA lock inversion deadlock between PHY consumer state locks and phy->mutex via synchronous notifier. --
--- Patch [28]: [PATCH v14 28/38] phy: core: add notifier infrastructure ---commit 140d5ba0c3927a01cec06534c2dc22cf14579ba0 Author: Sebastian Reichel [off-list ref] phy: core: add notifier infrastructure This commit introduces a notifier API for PHY devices, allowing consumer drivers to hook into PHY reset events. This provides a mechanism for consumers to gracefully handle the PHY going down during configuration or orientation changes.
quoted hunk ↗ jump to hunk
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c index 21aaf2f76e53e..51d261daae7a9 100644 --- a/drivers/phy/phy-core.c +++ b/drivers/phy/phy-core.c
[ ... ]
quoted hunk ↗ jump to hunk
@@ -542,6 +542,70 @@ int phy_notify_state(struct phy *phy, union phy_notify state)
[ ... ]
quoted hunk ↗ jump to hunk
+/** + * phy_notify_reset() - notify consumers of a PHY reset event + * @phy: the phy that is being reset + * @event: the notification event (PRE_RESET or POST_RESET) + * + * Called by PHY providers to notify consumers that the PHY is about to + * be reset or has completed a reset. This allows consumers to quiesce + * hardware before the PHY becomes unavailable. + * + * This may be called from within PHY provider callbacks (e.g. set_mode, + * power_on) where phy->mutex is held. Consumer notification handlers must + * therefore NOT call back into the PHY framework (e.g. phy_power_off, + * phy_exit) on the same PHY, as this would result in a deadlock. + * + * Returns: %0 if successful or no notifiers registered, a negative error + * code if a notifier returns an error (for PRE_RESET only) + */ +int phy_notify_reset(struct phy *phy, enum phy_notification event) +{ + int ret; + + if (!phy) + return 0; + + ret = blocking_notifier_call_chain(&phy->notifier, event, phy);
[Severity: High] Does this synchronous notification under phy->mutex introduce an AB-BA lock inversion risk with consumer driver state locks? For example, if a multi-port PHY has multiple consumers (like DP and USB), Consumer A could acquire its driver state lock (e.g., dp_lock) and call phy_power_on(phy), blocking on phy->mutex. Concurrently, if Consumer B triggers a phy_set_mode(phy) call, the PHY core acquires phy->mutex and invokes the provider's callback, which in turn calls phy_notify_reset(). This synchronously invokes Consumer A's notifier callback via blocking_notifier_call_chain(). If Consumer A attempts to acquire its state lock (dp_lock) within the notifier callback to safely quiesce its hardware, it will deadlock. Is it safe to execute this blocking notifier chain while holding phy->mutex?
quoted hunk ↗ jump to hunk
+ return notifier_to_errno(ret); +} +EXPORT_SYMBOL_GPL(phy_notify_reset);
-- Sashiko AI review · https://sashiko.dev/#/patchset/20260813-rockchip-usbdp-cleanup-v14-0-b5ad9c68fa11@collabora.com?part=28 -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy