From: Benno Lossin <benno.lossin@proton.me>
To: FUJITA Tomonori <fujita.tomonori@gmail.com>, andrew@lunn.ch
Cc: netdev@vger.kernel.org, rust-for-linux@vger.kernel.org,
tmgross@umich.edu
Subject: Re: [PATCH net-next v1 2/4] rust: net::phy support C45 helpers
Date: Tue, 16 Apr 2024 22:07:26 +0000 [thread overview]
Message-ID: <b03584c7-205e-483f-96f0-dde533cf0536@proton.me> (raw)
In-Reply-To: <20240416.222119.1989306221012409360.fujita.tomonori@gmail.com>
On 16.04.24 15:21, FUJITA Tomonori wrote:
> Hi,
>
> On Tue, 16 Apr 2024 14:38:11 +0200
> Andrew Lunn <andrew@lunn.ch> wrote:
>
>>> If I correctly understand the original driver code, C45 bus protocol
>>> is used. Adding functions for C45 bus protocol read/write would be
>>> enough for this driver, I guess.
>>
>> Now i've read more of the patches, i can see that the MDIO bus master
>> is C45 only. At least, that is all that is implemented in the
>> driver. So for this combination of MAC and PHY, forcing C45 register
>> access using C45 bus protocol will work.
>
> Thanks a lot!
>
>> However, can you combine this PHY with some other MDIO bus master,
>> which does not support C45? Then C45 over C22 would need to be used?
>> Looking at the data sheet i found online, there is no suggestion it
>> does support C22 bus protocol. All the diagrams/tables only show C45
>> bus protocol.
>
> qt2025_ds3014.pdf?
>
>> So this PHY is a special case. So you can use wrapper methods which
>> force C45 bus protocol, and ignore phylib support for performing C45
>> over C22 when needed. However, while doing this:
>>
>> 1: Clearly document that these helpers are not generic, they force C45
>> register access using C45 bus protocol, and should only by used PHY
>> drivers which know the PHY device does not support C45 over C22
>>
>> 2: Think about naming. At some point we are going to add the generic
>> helpers for accessing C45 registers which leave the core to decide
>> if to perform a C45 bus protocol access or C45 over C22. Those
>> generic helpers need to have the natural name for accessing a C45
>> register since 99% of drivers will be using them. The helpers you
>> add now need to use a less common name.
>
> Sounds like we should save the names of c45_read and c45_write.
>
> read_with_c45_bus_protocol and write_with_c45_bus_protocol?
>
> They call mdiobus_c45_*, right?
I think we could also do a more rusty solution. For example we could
have these generic functions for `phy::Device`:
fn read_register<R: Register>(&mut self, which: R::Index) -> Result<R::Value>;
fn write_register<R: Register>(&mut self, which: R::Index, value: R::Value) -> Result;
That way we can support many different registers without polluting the
namespace. We can then have a `C45` register and a `C22` register and a
`C45OrC22` (maybe we should use `C45_OrC22` instead, since I can read
that better, but let's bikeshed when we have the actual patch).
Calling those functions would look like this:
let value = dev.read_register::<C45>(reg1)?;
dev.write_register::<C45>(reg2, value)?;
--
Cheers,
Benno
next prev parent reply other threads:[~2024-04-16 22:07 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-15 10:46 [PATCH net-next v1 0/4] net: phy: add Applied Micro QT2025 PHY driver FUJITA Tomonori
2024-04-15 10:46 ` [PATCH net-next v1 1/4] rust: net::phy support config_init driver callback FUJITA Tomonori
2024-04-15 10:46 ` [PATCH net-next v1 2/4] rust: net::phy support C45 helpers FUJITA Tomonori
2024-04-15 14:20 ` Andrew Lunn
2024-04-16 11:40 ` FUJITA Tomonori
2024-04-16 12:38 ` Andrew Lunn
2024-04-16 13:21 ` FUJITA Tomonori
2024-04-16 22:07 ` Benno Lossin [this message]
2024-04-16 22:30 ` Andrew Lunn
2024-04-17 8:20 ` Benno Lossin
2024-04-17 13:34 ` Andrew Lunn
2024-04-18 12:47 ` Benno Lossin
2024-04-18 14:32 ` Andrew Lunn
2024-04-18 13:15 ` FUJITA Tomonori
2024-04-16 3:25 ` Trevor Gross
2024-05-27 2:00 ` FUJITA Tomonori
2024-04-15 10:47 ` [PATCH net-next v1 3/4] rust: net::phy support Firmware API FUJITA Tomonori
2024-04-15 11:10 ` Greg KH
2024-04-18 12:51 ` FUJITA Tomonori
2024-04-18 13:05 ` Greg KH
2024-04-18 13:07 ` Greg KH
2024-04-18 13:35 ` FUJITA Tomonori
2024-04-15 13:30 ` Andrew Lunn
2024-04-15 15:45 ` Danilo Krummrich
2024-04-18 13:10 ` FUJITA Tomonori
2024-04-15 10:47 ` [PATCH net-next v1 4/4] net: phy: add Applied Micro QT2025 PHY driver FUJITA Tomonori
2024-04-15 11:15 ` Greg KH
2024-04-18 13:00 ` FUJITA Tomonori
2024-04-18 13:10 ` Greg KH
2024-04-18 13:22 ` FUJITA Tomonori
2024-04-18 14:42 ` Andrew Lunn
2024-04-15 13:48 ` Andrew Lunn
2024-04-15 16:53 ` Andrew Lunn
2024-04-16 4:34 ` Trevor Gross
2024-04-16 6:58 ` Benno Lossin
2024-04-16 11:16 ` FUJITA Tomonori
2024-04-16 12:08 ` Andrew Lunn
2024-05-24 1:50 ` FUJITA Tomonori
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=b03584c7-205e-483f-96f0-dde533cf0536@proton.me \
--to=benno.lossin@proton.me \
--cc=andrew@lunn.ch \
--cc=fujita.tomonori@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).