mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced 2026-11-13 07:31:07 +00:00
net: phy: dp83867: restore LED configuration after a soft reset
The LED configuration lives in LEDCR1 (the per-LED function nibble) and LEDCR2 (per-LED driver enable/value and polarity). The driver programs it through the LED class callbacks -- dp83867_led_brightness_set(), dp83867_led_hw_control_set() and dp83867_led_polarity_set() -- either once from device tree at probe, or at runtime from sysfs and the netdev trigger. dp83867_phy_reset(), the .soft_reset callback, issues a global software reset (CTRL SW_RESET), which the datasheet defines as resetting all registers, including the extended registers, to their defaults. phy_init_hw() runs .soft_reset before .config_init on every attach and resume -- phy_attach_direct(), mdio_bus_phy_resume() and MAC drivers -- so the LED configuration is wiped from the first attach onward and never restored. A device-tree polarity is lost, a manually driven LED goes dark, and an LED offloaded to the netdev trigger whose link stays down after a resume keeps the reset-default function until the next link event. Shadow what the LED callbacks program, as a value and a written-bits mask per register, and replay it from config_init(), which runs right after the soft reset. Only bits the driver actually set are restored. The callbacks run under phydev->lock, but config_init() must not take it: the cable-test abort path in phy_state_machine() already holds phydev->lock when it reaches phy_init_hw(), so config_init() taking it would deadlock. Serialize the shadow and its replay with a dedicated lock instead. Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com> Link: https://patch.msgid.link/20260908235740.120112-1-donggeunyoo.kernel@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This commit is contained in:
parent
1f20151408
commit
043777e948
1 changed files with 98 additions and 13 deletions
Loading…
Add table
Add a link
Reference in a new issue