On Fri, 6 Oct 2023 14:54:43 +0200
Andrew Lunn [off-list ref] wrote:

On Fri, Oct 06, 2023 at 06:49:08PM +0900, FUJITA Tomonori wrote:

quoted

This patchset adds Rust abstractions for network PHY drivers. It
doesn't fully cover the C APIs for PHY drivers yet but I think that
it's already useful. I implement two PHY drivers (Asix AX88772A PHYs
and Realtek Generic FE-GE). Seems they work well with real hardware.

One of the conventions for submitting patches for netdev is to include
the tree in the Subject.

[PATCH net-next v2 1/3] rust: core abstractions for network PHY drivers

This is described here, along with other useful hits for working with
netdev.

https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html

This tag helps patchworks decide which tree to apply your patches to
and then run build tests on it:

https://patchwork.kernel.org/project/netdevbpf/patch/20231006094911.3305152-4-fujita.tomonori@gmail.com/

I don't know if it made the wrong decision based on the missing tag,
or it simply does not know what to do with Rust yet.

Thanks, I didn't know how tags and patchworks works.

There is also the question of how we merge this. Does it all come
through netdev? Do we split the patches, the abstraction merged via
rust and the rest via netdev? Is the Kconfig sufficient that if a tree
only contains patches 2 and 3 it does not allow the driver to be
enabled?

A tree only that contains patches 2 and 3 allow the driver to be
enabled, I think. The driver depends on CONFIG_RUST, which might
doesn't have PHY bindings support (the first patch).

So I think that merging the patchset through a single tree is easier;
netdev or rust.

Miguel, how do you prefer to merge the patchset?