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

[Muchamad Coirul Anwar]

Hi Andrew,

Thank you for the response and for reviewing this RFC.

On Tue, Mar 10, 2026 at 10:52 PM Andrew Lunn <andrew@xxxxxxx> 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