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.

Linux does not add an API without a user. If something is unused, it
is a pointless Maintenance burden.

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.

That is not really how Linux works. The Maintainers don't go out
searching for hardware which should be supported. Developers come to
us with patches.

One place you might look is Openwrt. They often have drivers for
hardware which never make it upstream to Mainline. Take such a driver,
buy the hardware, and port it to Rust. But please make sure it is
really a new device, not just a variant of an existing family of
devices which already has a driver.

	Andrew