Sashiko's review of this patch was sent off-list [1], so I am replying
here.
Can calling genphy_soft_reset() on a Device<MaybeLocked> cause a data race
on struct phy_device fields and bitfields when a Device<Locked> callback
runs concurrently?
The race comes from the caller, not from this series. PHYLIB calls
soft_reset without `phydev->lock` on some paths, and on those paths
`genphy_soft_reset()` and `phy_init_hw()` itself touch these fields the same
way for every C driver. This series does not change what runs there; it
makes the Rust interface match that contract, so a soft_reset
implementation no longer gets a `&mut Device<Locked>` and cannot call the
methods that rely on the lock. Before it, the callback could do strictly
more on the same path.
Should the methods in impl<Ctx: PhyContext> Device<Ctx>, Deref::deref(),
AsRef::as_ref(), and the Register::read() and Register::write()
implementations [...] have #[inline] annotations?
The moved methods did not have `#[inline]` before. This patch only moves them.
I can add it in v2 if that is preferred.
[1] https://sashiko.dev/#/patchset/20261110-exp-phy-rs-maybelocked-v1-0-3023cc9055e9@gmail.com?part=1