From: Andrew Lunn <andrew@lunn.ch>
To: Trevor Gross <tmgross@umich.edu>
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
Subject: Re: [PATCH v2 3/3] net: phy: add Rust Asix PHY driver
Date: Sat, 7 Oct 2023 17:35:08 +0200 [thread overview]
Message-ID: <d824a34f-7290-477e-8198-c16164e34861@lunn.ch> (raw)
In-Reply-To: <CALNs47syMxiZBUwKLk3vKxzmCbX0FS5A37FjwUzZO9Fn-iPaoA@mail.gmail.com>
On Sat, Oct 07, 2023 at 03:19:20AM -0400, Trevor Gross wrote:
> On Fri, Oct 6, 2023 at 5:49 AM FUJITA Tomonori
> <fujita.tomonori@gmail.com> wrote:
>
> > diff --git a/drivers/net/phy/ax88796b_rust.rs b/drivers/net/phy/ax88796b_rust.rs
> > new file mode 100644
> > index 000000000000..d11c82a9e847
> > --- /dev/null
> > +++ b/drivers/net/phy/ax88796b_rust.rs
>
> Maybe want to link to the C version, just for the crossref?
>
> > + fn read_status(dev: &mut phy::Device) -> Result<u16> {
> > + dev.genphy_update_link()?;
> > + if !dev.get_link() {
> > + return Ok(0);
> > + }
>
> Looking at this usage, I think `get_link()` should be renamed to just
> `link()`. `get_link` makes me think that it is performing an action
> like calling `genphy_update_link`, just `link()` sounds more like a
> static accessor.
Naming is hard, and i had the exact opposite understanding.
The rust binding seems to impose getter/setters on members of
phydev. So my opinion was, using get_/set_ makes it clear this is just
a dumb getter/setter, and nothing more.
> Or maybe it's worth replacing `get_link` with a `get_updated_link`
> that calls `genphy_update_link` and then returns `link`, the user can
> store it if they need to reuse it. This seems somewhat less accident
> prone than someone calling `.link()`/`.get_link()` repeatedly and
> wondering why their phy isn't coming up.
You have to be very careful with reading the link state. It is latched
low. Meaning if the link is dropped and then comes back again, the
first read of the link will tell you it went away, and the second read
will give you current status. The core expects the driver to read the
link state only once, when asked what is the state of the link, so it
gets informed about this short link down events.
> In any case, please make the docs clear about what behavior is
> executed and what the preconditions are, it should be clear what's
> going to wait for the bus vs. simple field access.
>
> > + if ret as u32 & uapi::BMCR_SPEED100 != 0 {
> > + dev.set_speed(100);
> > + } else {
> > + dev.set_speed(10);
> > + }
>
> Speed should probably actually be an enum since it has defined values.
> Something like
>
> #[non_exhaustive]
> enum Speed {
> Speed10M,
> Speed100M,
> Speed1000M,
> // 2.5G, 5G, 10G, 25G?
> }
This beings us back to how do you make use of C #defines. All the
values defined here are theoretically valid:
https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/ethtool.h#L1887
#define SPEED_10 10
#define SPEED_100 100
#define SPEED_1000 1000
#define SPEED_2500 2500
#define SPEED_5000 5000
#define SPEED_10000 10000
#define SPEED_14000 14000
#define SPEED_20000 20000
#define SPEED_25000 25000
#define SPEED_40000 40000
#define SPEED_50000 50000
#define SPEED_56000 56000
#define SPEED_100000 100000
#define SPEED_200000 200000
#define SPEED_400000 400000
#define SPEED_800000 800000
and more speeds keep getting added.
Also, the kAPI actually would allow the value 42, not that any
hardware i know of actually supports that.
> > + fn link_change_notify(dev: &mut phy::Device) {
> > + // Reset PHY, otherwise MII_LPA will provide outdated information.
> > + // This issue is reproducible only with some link partner PHYs.
> > + if dev.state() == phy::DeviceState::NoLink {
> > + let _ = dev.init_hw();
> > + let _ = dev.start_aneg();
> > + }
> > + }
> > +}
>
> Is it worth doing anything with these errors? I know that the C driver doesn't.
You could do a phydev_err(). But if these fail, the hardware is dead,
and there is not much you can do about that.
Andrew
next prev parent reply other threads:[~2023-10-07 15:35 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-06 9:49 [PATCH v2 0/3] Rust abstractions for network PHY drivers FUJITA Tomonori
2023-10-06 9:49 ` [PATCH v2 1/3] rust: core " FUJITA Tomonori
2023-10-07 5:06 ` Trevor Gross
2023-10-07 10:58 ` FUJITA Tomonori
2023-10-07 11:17 ` Greg KH
2023-10-07 11:23 ` FUJITA Tomonori
2023-10-07 11:30 ` Greg KH
2023-10-07 22:33 ` FUJITA Tomonori
2023-10-08 6:19 ` Trevor Gross
2023-10-08 7:49 ` FUJITA Tomonori
2023-10-08 8:54 ` Trevor Gross
2023-10-08 9:02 ` FUJITA Tomonori
2023-10-08 9:58 ` Trevor Gross
2023-10-07 23:26 ` Trevor Gross
2023-10-07 14:47 ` Andrew Lunn
2023-10-08 5:41 ` Trevor Gross
2023-10-07 15:13 ` Andrew Lunn
2023-10-08 6:07 ` Trevor Gross
2023-10-08 14:28 ` FUJITA Tomonori
2023-10-09 3:07 ` Trevor Gross
2023-10-06 9:49 ` [PATCH v2 2/3] MAINTAINERS: add Rust PHY abstractions to the ETHERNET PHY LIBRARY FUJITA Tomonori
2023-10-06 9:49 ` [PATCH v2 3/3] net: phy: add Rust Asix PHY driver FUJITA Tomonori
2023-10-06 10:31 ` Greg KH
2023-10-06 13:53 ` FUJITA Tomonori
2023-10-06 14:12 ` Greg KH
2023-10-06 14:30 ` FUJITA Tomonori
2023-10-06 14:37 ` Greg KH
2023-10-06 14:40 ` Andrew Lunn
2023-10-06 14:35 ` Andrew Lunn
2023-10-06 15:26 ` FUJITA Tomonori
2023-10-06 15:57 ` Andrew Lunn
2023-10-06 16:21 ` FUJITA Tomonori
2023-10-06 16:55 ` Andrew Lunn
2023-10-06 23:54 ` FUJITA Tomonori
2023-10-07 0:20 ` Andrew Lunn
2023-10-07 7:41 ` FUJITA Tomonori
2023-10-07 7:19 ` Trevor Gross
2023-10-07 12:07 ` FUJITA Tomonori
2023-10-07 15:39 ` Andrew Lunn
2023-10-08 7:11 ` Trevor Gross
2023-10-07 15:35 ` Andrew Lunn [this message]
2023-10-08 7:17 ` Trevor Gross
2023-10-06 12:54 ` [PATCH v2 0/3] Rust abstractions for network PHY drivers Andrew Lunn
2023-10-06 14:09 ` FUJITA Tomonori
2023-10-06 14:47 ` Andrew Lunn
2023-10-06 23:37 ` Trevor Gross
2023-10-07 3:26 ` FUJITA Tomonori
2023-10-09 12:39 ` Miguel Ojeda
2023-10-07 0:42 ` Trevor Gross
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=d824a34f-7290-477e-8198-c16164e34861@lunn.ch \
--to=andrew@lunn.ch \
--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).