On 20.10.23 21:50, Andrew Lunn wrote:

quoted

I will try to explain things a bit more.

So this case is a bit difficult to figure out, because what is
going on is not really a pattern that is used in Rust.

It is however a reasonably common pattern in the kernel. It stems from
driver writers often don't understand locking. So the core does the
locking, leaving the driver writers to just handle the problems of the
hardware.

I have seen this pattern the first time here, I am sure more experienced
members such as Miguel and Wedson have seen it before.

I am not saying that it is incompatible with Rust, just that it
wouldn't be done like this if it were purely Rust.

Rust maybe makes locking more of a visible issue, but if driver
writers don't understand locking, the language itself does not make
much difference.

I think Rust will make a big difference:
- you cannot access data protected by a lock without locking the
   lock beforehand.
- you cannot forget to unlock a lock.

quoted

We already have exclusive access to the `phy_device`, so in Rust
you would not need to lock anything to also have exclusive access to the
embedded `mii_bus`.

I would actually say its not the PHY drivers problem at all. The
mii_bus is a property of the MDIO layers, and it is the MDIO layers
problem to impose whatever locking it needs for its properties.

Since the MDIO layer would provide its own serialization, in Rust
we would not protect the `mdio_device` with a lock. In this case
it could just be a coincidence that both locks are locked, since
IIUC `phy_device` is locked whenever callbacks are called.

Also, mii_bus is not embedded. Its a pointer to an mii_bus. The phy
lock protects the pointer. But its the MDIO layer which needs to
protect what the pointer points to.

Oh I overlooked the `*`. Then it depends what type of pointer that is,
is the `mii_bus` unique or is it shared? If it is shared, then Rust
would also need another lock there.

-- 
Cheers,
Benno