While auditing the SAFETY comments of Rust abstractions against their C
callers, and confirming the result with Clang's context analysis [1], it
turned out that PHYLIB calls `soft_reset` and `match_phy_device` both
with and without `phy_device->lock`, while the Rust side assumes it is
held.
No driver is affected, but it seems better for the abstraction to tell
the two cases apart. Patch 1 makes `Device` generic over a lock context,
as `device::Device` is, and patch 2 gives these two callbacks the
`MaybeLocked` one.
The audit, the patches and their changelogs were done with an AI coding
assistant (Claude Code, Claude Opus 5.5); the lock-less paths were then
checked with Clang 23 context analysis as described in patch 2.
[1] https://docs.kernel.org/dev-tools/context-analysis.html
---
SeungJong Ha (2):
rust: net: phy: make Device generic over a lock context
rust: net: phy: pass a MaybeLocked device to soft_reset and match_phy_device
drivers/net/phy/ax88796b_rust.rs | 8 +-
rust/kernel/net/phy.rs | 183 ++++++++++++++++++++++++++++-----------
rust/kernel/net/phy/reg.rs | 17 ++--
3 files changed, 145 insertions(+), 63 deletions(-)
---
base-commit: 2d916a8c307c31b433318509bf0311d52d509f09
change-id: 20261110-exp-phy-rs-maybelocked-ddc59993efba
Best regards,
--
SeungJong Ha [off-list ref]