[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6aac66e0-9cbd-4a7b-91e6-ea429dbe6831@lunn.ch>
Date: Fri, 6 Oct 2023 14:54:43 +0200
From: Andrew Lunn <andrew@...n.ch>
To: FUJITA Tomonori <fujita.tomonori@...il.com>
Cc: netdev@...r.kernel.org, rust-for-linux@...r.kernel.org,
miguel.ojeda.sandonis@...il.com, greg@...ah.com
Subject: Re: [PATCH v2 0/3] Rust abstractions for network PHY drivers
On Fri, Oct 06, 2023 at 06:49:08PM +0900, FUJITA Tomonori wrote:
> 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.
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?
Andrew
Powered by blists - more mailing lists