Re: [RFC PATCH net-next] net: phy: rust: add experimental Davicom PHY driver
From: Muchamad Coirul Anwar <hidden>
Date: 2026-03-11 02:44:20
Also in:
lkml, rust-for-linux
Hi Andrew, Thank you for the response and for reviewing this RFC. On Tue, Mar 10, 2026 at 10:52 PM Andrew Lunn [off-list ref] wrote:
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?
I sincerely apologize for the ambiguity in my commit message. There is actually no specific QEMU emulation for the Davicom PHY. By "verified via QEMU", I only meant that I booted the compiled `bzImage` in a generic x86_64 QEMU VM to ensure the module initialization did not cause any kernel panics or memory issues.
Does QEMU have the scrambler? What happens if you wrongly configure the scrambler. 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?
Because there is no actual hardware emulation, I unfortunately cannot test these specific hardware behaviors. The logic in this RFC was strictly a 1:1 blind translation of the existing `davicom.c` to see where the Rust compiler and current PHY abstractions would stop me.
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.
I completely agree with your policy on untested code and avoiding C/Rust duplication. My primary goal with this RFC was exactly what you offered: to highlight the missing bindings (like `config_intr`, `config_init`, etc.) so the Rust API could be expanded. I will gladly take your advice, drop this Davicom port, and look for a new/unsupported PHY chip to write a proper Rust driver for. If you or the netdev team have any specific upcoming or unsupported PHY chips in mind that would be a good target for a first Rust driver, please let me know. I would be more than happy to purchase the hardware and work on it. Thanks again for your time and guidance! Best regards, Muchamad Coirul Anwar