lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-Id: <20231006.230936.1469709863025123979.fujita.tomonori@gmail.com> Date: Fri, 06 Oct 2023 23:09:36 +0900 (JST) From: FUJITA Tomonori <fujita.tomonori@...il.com> To: andrew@...n.ch, miguel.ojeda.sandonis@...il.com Cc: fujita.tomonori@...il.com, netdev@...r.kernel.org, rust-for-linux@...r.kernel.org, greg@...ah.com Subject: Re: [PATCH v2 0/3] Rust abstractions for network PHY drivers On Fri, 6 Oct 2023 14:54:43 +0200 Andrew Lunn <andrew@...n.ch> wrote: > 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. 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?
Powered by blists - more mailing lists