rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benno Lossin <benno.lossin@proton.me>
To: Andrew Lunn <andrew@lunn.ch>
Cc: FUJITA Tomonori <fujita.tomonori@gmail.com>,
	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: Wed, 17 Apr 2024 08:20:25 +0000	[thread overview]
Message-ID: <92b60274-6b32-4dfd-9e46-d447184572d2@proton.me> (raw)
In-Reply-To: <f908e54a-b0e6-49d5-b4ff-768072755a78@lunn.ch>

On 17.04.24 00:30, Andrew Lunn wrote:
>> 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)?;
> 
> I don't know how well that will work out in practice. The addressing
> schemes for C22 and C45 are different.
> 
> C22 simply has 32 registers, numbered 0-31.
> 
> C45 has 32 MDIO manageable devices (MMD) each with 65536 registers.
> 
> All of the 32 C22 registers have well defined names, which are listed
> in mii.h. Ideally we want to keep the same names. The most of the MMD
> also have defined names, listed in mdio.h. Many of the registers are
> also named in mdio.h, although vendors do tend to add more vendor
> proprietary registers.
> 
> Your R::Index would need to be a single value for C22 and a tuple of
> two values for C45.

Yes that was my idea:

    enum C22Index {
        // The unique 32 names of the C22 registers...
    }

    impl Register for C22 {
        type Index = C22Index;
        type Value = u16;
    }

    impl Register for C45 {
        type Index = (u8, u16); // We could also create a newtype that wraps this and give it a better name.
        type Value = u16;
    }

You can then do:

    let val = dev.read_register::<C45>((4, 406))?;
    dev.write_register::<C22>(4, val)?;

If you only have these two registers types, then I would say this is
overkill, but I assumed that there are more.

> There is nothing like `C45OrC22`. A register is either in C22
> namespace, or in the C45 namespace.

I see, I got this idea from:

> [...] 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. [...]

Is this not accessing a C45 register via C22 and letting phylib decide?

> Where it gets interesting is that there are two methods to access the
> C45 register namespace. The PHY driver should not care about this, it
> is the MDIO bus driver and the PHYLIB core which handles the two
> access mechanisms.

If the driver shouldn't be concerned with how the access gets handled,
why do we even have a naming problem?

-- 
Cheers,
Benno


  reply	other threads:[~2024-04-17  8:20 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
2024-04-16 22:30             ` Andrew Lunn
2024-04-17  8:20               ` Benno Lossin [this message]
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=92b60274-6b32-4dfd-9e46-d447184572d2@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).