Re: [RFC PATCH net-next] net: phy: rust: add experimental Davicom PHY driver

[Andrew Lunn]

On Tue, Mar 10, 2026 at 10:19:35PM +0700, Muchamad Coirul Anwar wrote:
> This is an experimental Rust port of the legacy Davicom PHY driver
> (davicom.c) to explore the boundaries of the current PHY abstractions.
> 
> During the porting process, a few limitations in the current
> `net::phy::Driver` trait were observed:
> 1. Callbacks for `config_init`, `config_intr`, and `handle_interrupt`
>    are not yet exposed.
> 2. `bindings::genphy_config_aneg` is not yet wrapped.
> 
> In this RFC, the logic for these missing callbacks is implemented
> and marked with `#[allow(dead_code)]` to demonstrate the required
> hardware logic. Additionally, `unsafe` blocks are used as a temporary
> workaround for `genphy_config_aneg` and interface checking.
> 
> Note: I don't have access to the physical Davicom hardware.
> This patch is compile-tested and verified via QEMU only. It is
> submitted as an RFC to share findings regarding the missing
> abstractions and gather feedback on the Rust PHY usage.

How good is the QEMU emulation of this PHY? What features does it
support, compared to the real thing?

Adding support for interrupts to the Rust API seems useful, but does
the QEMU emulator support it? What emulated board are you using with
this PHY? Does that board have interrupts wired up? Can you triggering
interrupts by changing the link state?

> +/// Register 0x10: Scrambler Control Register (SCR)
> +const SCR: C22 = C22::vendor_specific::<0x10>();
> +const SCR_INIT: u16 = 0x0610;
> +const SCR_RMII: u16 = 0x0100;

Does QEMU have the scrambler? What happens if you wrongly configure
the scrambler.

> +/// Configures PHY Auto-Negotiation.
> +///
> +/// Isolates the PHY during configuration, then calls the generic `genphy_config_aneg`
> +/// via unsafe C bindings because Rust abstractions don't expose it directly yet.
> +fn dm9161_config_aneg(dev: &mut phy::Device) -> Result {
> +    dev.write(C22::BMCR, bindings::BMCR_ISOLATE as u16)?;

What does the emulation do if you don't isolate the PHY? Is there an
errata for this PHY which tells you why it needs isolating?

I don't want to add code which cannot be tested. Ideally, it should be
tested on real hardware. We also are pushing back on duplicate C and
Rust. So if you want to write a Rust PHY driver, i suggest you find
some hardware which does not have a C driver, and add support for it
using Rust. Then i would be happy to expand the Rust binding as
needed.

    Andrew

---
pw-bot: cr