[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <176fe839-7142-49be-9fba-1e105dc8d4de@lunn.ch>
Date: Thu, 18 Apr 2024 16:42:33 +0200
From: Andrew Lunn <andrew@...n.ch>
To: FUJITA Tomonori <fujita.tomonori@...il.com>
Cc: gregkh@...uxfoundation.org, netdev@...r.kernel.org,
rust-for-linux@...r.kernel.org, tmgross@...ch.edu
Subject: Re: [PATCH net-next v1 4/4] net: phy: add Applied Micro QT2025 PHY
driver
> >> + if i == 0x4000 {
> >
> > What does 0x4000 mean here?
> >
> >> + a = MDIO_MMD_PHYXS;
> >> + j = 0x8000;
> >
> > What does 0x8000 mean here?
> >
> >> + }
> >> + dev.c45_write(a, j, (*val).into())?;
> >> +
> >> + j += 1;
> >> + }
> >> + dev.c45_write(MDIO_MMD_PCS, 0xe854, 0x0040)?;
> >
> > Lots of magic values in this driver, is that intentional?
>
> The original driver uses lots of magic values. I simply use them. As
> Andrew wrote, we could infer some. I'll try to comment these.
When you start from a Vendor crap driver, part of the process of
getting it into Mainline is getting it up to Mainline quality. If this
was C code, i would be trying to replace as many of the magic numbers
with #define. And then add comments about the best guess what things
are doing, based on the datasheet. The data sheet however does not
explain all the bits, nor give every register a name. But you should
use as much information as possible from the datasheet to make the
code as readable as possible.
Andrew
Powered by blists - more mailing lists