From: Andrew Lunn <andrew@lunn.ch>
To: Benno Lossin <benno.lossin@proton.me>
Cc: FUJITA Tomonori <fujita.tomonori@gmail.com>,
netdev@vger.kernel.org, rust-for-linux@vger.kernel.org,
miguel.ojeda.sandonis@gmail.com, greg@kroah.com,
tmgross@umich.edu
Subject: Re: [PATCH net-next v3 1/3] rust: core abstractions for network PHY drivers
Date: Mon, 9 Oct 2023 15:02:31 +0200 [thread overview]
Message-ID: <4ced711a-009c-4e57-a758-1d13d97e18d2@lunn.ch> (raw)
In-Reply-To: <1aea7ddb-73b7-8228-161e-e2e4ff5bc98d@proton.me>
On Mon, Oct 09, 2023 at 12:19:54PM +0000, Benno Lossin wrote:
> > +impl Device {
> > + /// Creates a new [`Device`] instance from a raw pointer.
> > + ///
> > + /// # Safety
> > + ///
> > + /// For the duration of the lifetime 'a, the pointer must be valid for writing and nobody else
> > + /// may read or write to the `phy_device` object.
> > + pub unsafe fn from_raw<'a>(ptr: *mut bindings::phy_device) -> &'a mut Self {
> > + unsafe { &mut *ptr.cast() }
>
> Missing `SAFETY` comment.
Hi Benno
It is normal on Linux kernel mailing lists to trim the text to what is
just relevant to the reply. Comments don't get lost that way.
> > + /// Returns true if the link is up.
> > + pub fn get_link(&mut self) -> bool {
>
> I would call this function `is_link_up`.
Please read the discussion on the previous versions of this patch. If
you still want to change the name, please give a justification.
> > + /// Reads a given C22 PHY register.
> > + pub fn read(&mut self, regnum: u16) -> Result<u16> {
> > + let phydev = self.0.get();
> > + // SAFETY: `phydev` is pointing to a valid object by the type invariant of `Self`.
> > + // So an FFI call with a valid pointer.
> > + let ret = unsafe {
> > + bindings::mdiobus_read((*phydev).mdio.bus, (*phydev).mdio.addr, regnum.into())
> > + };
>
> Just a general question, all of these unsafe calls do not have
> additional requirements? So aside from the pointers being
> valid, there are no timing/locking/other safety requirements
> for calling the functions?
Locking has been discussed a number of times already. What do you mean
by timing?
> > +// SAFETY: `Registration` does not expose any of its state across threads.
> > +unsafe impl Send for Registration {}
>
> Question: is it ok for two different threads to call `phy_drivers_register`
> and `phy_drivers_unregister`? If no, then `Send` must not be implemented.
The core phy_drivers_register() is thread safe. It boils down to a
driver_register() which gets hammered every kernel boot, so locking
issues would soon be found there.
> > +macro_rules! module_phy_driver {
> > + (@replace_expr $_t:tt $sub:expr) => {$sub};
> > +
> > + (@count_devices $($x:expr),*) => {
> > + 0usize $(+ $crate::module_phy_driver!(@replace_expr $x 1usize))*
> > + };
> > +
> > + (@device_table [$($dev:expr),+]) => {
> > + #[no_mangle]
> > + static __mod_mdio__phydev_device_table: [
>
> Shouldn't this have a unique name? If we define two different
> phy drivers with this macro we would have a symbol collision?
I assume these are the equivalent of C static. It is not visible
outside the scope of this object file. The kernel has lots of tables
and they are mostly of very limited visibility scope, because only the
method registering/unregistering the table needs to see it.
Andrew
next prev parent reply other threads:[~2023-10-09 13:02 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-09 1:39 [PATCH net-next v3 0/3] Rust abstractions for network PHY drivers FUJITA Tomonori
2023-10-09 1:39 ` [PATCH net-next v3 1/3] rust: core " FUJITA Tomonori
2023-10-09 3:17 ` Trevor Gross
2023-10-09 12:19 ` Benno Lossin
2023-10-09 13:02 ` Andrew Lunn [this message]
2023-10-09 13:56 ` Benno Lossin
2023-10-09 14:13 ` Andrew Lunn
2023-10-11 14:16 ` FUJITA Tomonori
2023-10-09 12:59 ` Miguel Ojeda
2023-10-09 13:49 ` FUJITA Tomonori
2023-10-09 14:32 ` Miguel Ojeda
2023-10-09 15:15 ` FUJITA Tomonori
2023-10-09 15:19 ` Miguel Ojeda
2023-10-09 15:11 ` Greg KH
2023-10-09 15:24 ` FUJITA Tomonori
2023-10-09 15:39 ` Miguel Ojeda
2023-10-09 15:50 ` FUJITA Tomonori
2023-10-11 9:59 ` Miguel Ojeda
2023-10-11 23:18 ` FUJITA Tomonori
2023-10-13 11:59 ` Miguel Ojeda
2023-10-13 15:15 ` FUJITA Tomonori
2023-10-13 18:33 ` Miguel Ojeda
2023-10-14 12:31 ` FUJITA Tomonori
2023-10-14 16:19 ` Miguel Ojeda
2023-10-12 0:29 ` FUJITA Tomonori
2023-10-09 21:07 ` Trevor Gross
2023-10-09 21:21 ` Andrew Lunn
2023-10-11 7:04 ` FUJITA Tomonori
2023-10-09 13:54 ` Andrew Lunn
2023-10-09 14:48 ` Miguel Ojeda
2023-10-09 17:04 ` Andrew Lunn
2023-10-12 3:59 ` FUJITA Tomonori
2023-10-12 4:43 ` Trevor Gross
2023-10-12 7:09 ` FUJITA Tomonori
2023-10-11 18:29 ` Boqun Feng
2023-10-12 5:58 ` FUJITA Tomonori
2023-10-12 6:34 ` Boqun Feng
2023-10-12 6:44 ` FUJITA Tomonori
2023-10-12 7:02 ` FUJITA Tomonori
2023-10-12 7:13 ` Boqun Feng
2023-10-12 7:32 ` Trevor Gross
2023-10-12 7:58 ` FUJITA Tomonori
2023-10-12 9:10 ` Benno Lossin
2023-10-13 4:17 ` Boqun Feng
2023-10-13 5:45 ` FUJITA Tomonori
2023-10-13 7:56 ` Benno Lossin
2023-10-13 9:53 ` FUJITA Tomonori
2023-10-13 10:03 ` Benno Lossin
2023-10-13 10:53 ` FUJITA Tomonori
2023-10-14 7:47 ` Benno Lossin
2023-10-14 21:55 ` Andrew Lunn
2023-10-14 22:18 ` Benno Lossin
2023-10-14 22:33 ` Andrew Lunn
2023-10-14 4:11 ` Boqun Feng
2023-10-14 11:59 ` Miguel Ojeda
2023-10-12 7:07 ` Boqun Feng
2023-10-09 1:39 ` [PATCH net-next v3 2/3] MAINTAINERS: add Rust PHY abstractions to the ETHERNET PHY LIBRARY FUJITA Tomonori
2023-10-09 1:39 ` [PATCH net-next v3 3/3] net: phy: add Rust Asix PHY driver FUJITA Tomonori
2023-10-09 3:22 ` Trevor Gross
2023-10-09 7:23 ` Jiri Pirko
2023-10-09 10:58 ` Miguel Ojeda
2023-10-09 11:41 ` FUJITA Tomonori
2023-10-09 12:32 ` Andrew Lunn
2023-10-09 14:01 ` Miguel Ojeda
2023-10-09 14:31 ` Andrew Lunn
2023-10-09 15:27 ` Miguel Ojeda
2023-10-09 15:35 ` Miguel Ojeda
2023-10-09 16:09 ` Andrew Lunn
2023-10-09 10:10 ` Greg KH
2023-10-12 11:57 ` FUJITA Tomonori
2023-10-09 12:42 ` Benno Lossin
2023-10-09 13:15 ` Andrew Lunn
2023-10-09 13:45 ` Benno Lossin
2023-10-09 12:48 ` [PATCH net-next v3 0/3] Rust abstractions for network PHY drivers Andrew Lunn
2023-10-09 12:53 ` Miguel Ojeda
2023-10-09 13:06 ` Greg KH
2023-10-09 14:13 ` Miguel Ojeda
2023-10-09 14:52 ` Greg KH
2023-10-09 15:06 ` Miguel Ojeda
2023-10-09 15:14 ` Greg KH
2023-10-09 15:15 ` Miguel Ojeda
2023-10-09 13:24 ` Andrew Lunn
2023-10-09 13:36 ` Miguel Ojeda
2023-10-09 14:21 ` Andrea Righi
2023-10-09 14:22 ` Miguel Ojeda
2023-10-09 14:56 ` Andrew Lunn
2023-10-09 15:04 ` Greg KH
2023-10-09 15:10 ` Miguel Ojeda
2023-10-09 15:15 ` Miguel Ojeda
2023-10-09 14:56 ` Greg KH
2023-10-09 15:09 ` Andrea Righi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ced711a-009c-4e57-a758-1d13d97e18d2@lunn.ch \
--to=andrew@lunn.ch \
--cc=benno.lossin@proton.me \
--cc=fujita.tomonori@gmail.com \
--cc=greg@kroah.com \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).