[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ca362a9e-2212-4f3a-bc35-3187ff905ec0@lunn.ch>
Date: Sat, 14 Oct 2023 23:18:22 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Benno Lossin <benno.lossin@...ton.me>
Cc: FUJITA Tomonori <fujita.tomonori@...il.com>, netdev@...r.kernel.org,
rust-for-linux@...r.kernel.org, miguel.ojeda.sandonis@...il.com,
tmgross@...ch.edu, boqun.feng@...il.com, wedsonaf@...il.com,
greg@...ah.com
Subject: Re: [PATCH net-next v4 1/4] rust: core abstractions for network PHY
drivers
> What about these functions?
> - resolve_aneg_linkmode
> - genphy_soft_reset
> - init_hw
> - start_aneg
> - genphy_read_status
> - genphy_update_link
> - genphy_read_lpa
> - genphy_read_abilities
If i'm understanding the discussion correctly, you want to know if
these C functions can modify the phydev structure that is passed to
them?
Yes, they all do modify it.
They also assume that phydev->lock is taken somewhere up the call
chain, so they are safe to modify the structure without worrying about
multiple threads being active.
There are some functions which currently don't modify the phydev
passed to them. However, we are pretty bad at putting on the const
attribute. I also think it would be dangerous to assume such functions
will forever not modify phydev.
Andrew
Powered by blists - more mailing lists