[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALNs47v7rVp2jFGBuG_UBEpTTfp6aKOts4A1hBP0rohw5=q_QA@mail.gmail.com>
Date: Sun, 8 Oct 2023 23:07:51 -0400
From: Trevor Gross <tmgross@...ch.edu>
To: FUJITA Tomonori <fujita.tomonori@...il.com>
Cc: andrew@...n.ch, netdev@...r.kernel.org, rust-for-linux@...r.kernel.org,
miguel.ojeda.sandonis@...il.com, greg@...ah.com
Subject: Re: [PATCH v2 1/3] rust: core abstractions for network PHY drivers
On Sun, Oct 8, 2023 at 10:28 AM FUJITA Tomonori
<fujita.tomonori@...il.com> wrote:
> > Fujita - since this doesn't get exposed, could this be pub(crate)?)
>
> Device? I don't think so. If we make Device pub(crate), we need to
> make trait Driver pub(crate) too.
Not `Device`, just `pub fn from_raw`. I think it is fine as-is (I see
you sent a new version)
> > Fujita, I think we started doing comments when we know that
> > lossy/bitwise `as` casts are correct. Maybe just leave the code as-is
> > but add
> >
> > // CAST: the C side verifies devnum < 32
>
> Ok. As I commented on the RFC reviewing, I don't think that we
> need try_from conversion for values from PHYLIB. Implementing bindings
> for untrusted stuff doesn't make sense.
>
> https://lore.kernel.org/all/20230926.101928.767176570707357116.fujita.tomonori@gmail.com/
>
> On the other hand, I think that it might worth to use try_from for
> set_speed() because its about the bindings and Rust PHY drivers.
> However, I leave it alone since likely setting a wrong value doesn't
> break anything.
Agreed, thanks for the followup
Powered by blists - more mailing lists