[9fans] pc/ether8169.c: a point

[9fans] pc/ether8169.c: a point

[tlaronde]

For the curious, I have updated my take on the pc/ether8169.c driver,
to add support for all the families in the RTL8169 "order":

http://downloads.kergis.com/misc/9front/ether8169.c

I'm not ignoring Aidan's work: I'm matching what is in the Realtek's
published (FreeBSD) driver and what he has done and I'm trying to
organize the Realtek's driver and to simplify.

In a nutshell, the mac version leads to a record of specifications,
with size of the MTU, flags and initial magic code.

After matching the PCI (vid, did), we look for the macv to match a
specification. If there is none (it should be the complete list), the
device is dropped at least by this driver.

If this was not enough, even with a macv, in some cases exceptions
have to be taken into account (there are no Macfg_74 and Macfg_75 in
the array, because these are subcases of Macfg_69 and are detected
later).

The initialization is done following the order given in th Realtek
driver, with some general initializations, then the idiosynchrasies
(magic code written for the MAC), followed by configuring the PHY.

Contrary to what I thought would be better first, the idiosynchrasies
are not segregated in another file, but put last in the very file, so
that, as much as possible, the logics can be grasped, while the
details (and, de facto, the black magic because one can wonder what
the code does...) are exiled after.

The work is not finished because I have still to entangle what
concerns the PHY and I have to give a look to the interrupts (Aidan
has added some code) and about the clock.

I didn't know anything about the stuff before starting, so have
downloaded the 802.3 spec (> 7000 pages...), so, obviously, I will
continue ignoring a majority of this stuff. But from what I gathered,
we will do nothing about MDIO, but stick to MII (the question being:
will this be sufficient with a frequency >= 2.5Ghz ?).

We will do nothing concerning Management, Administration and so on
either.

As is my method, I write and didn't try to compile anything before I
judge I have reached a working state. I will try to compile only when
it's ready to there can be blunders (I'm playing Dr Frankenstein
taking pieces here and there and accommodating the whole by sewing;
this will not be a work of art and this is why I'm exiling the ugly
bits in the end of the file).

But this is not vaporware: this is progressing as one can see
using the link given above.
-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T58f306392c5b4ca9-Mc900dfd8273247bb5ca1df6f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] pc/ether8169.c: a point

[Aidan K. Wiggins via 9fans]

Hi Thierry,

Thanks for this work!

I think I agree that it's the right thing to do to shove all those
undocumented bits to the bottom of the file. I noticed that the file's
changed a bit since I last looked (e.g. +rtl8169getintr()), so it
looks like it's coming together well. I'll try and get to your patch
tonight; 2.5G operation doesn't work on my nic, so it very well could
be that these phy specific bits do just that!

Re: the mii bits.. I'll have to test around with the code a bit, but I
would like to make use of the recent mii() changes incorporating some
of Clause 45 of the 802.3 into the code. That should give us status
(though we can already do this through Realtek's registers), and
autonegotiation for 2.5G/5G (which is maybe what's missing).

Aidan

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T58f306392c5b4ca9-M00d3801255dba53270d44450
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] pc/ether8169.c: a point

[tlaronde]

Hello Aidan,

On Sun, Apr 20, 2025 at 11:07:44AM -0700, Aidan K. Wiggins via 9fans wrote:
> Hi Thierry,
> 
> Thanks for this work!
> 
> I think I agree that it's the right thing to do to shove all those
> undocumented bits to the bottom of the file. I noticed that the file's
> changed a bit since I last looked (e.g. +rtl8169getintr()), so it
> looks like it's coming together well. I'll try and get to your patch
> tonight; 2.5G operation doesn't work on my nic, so it very well could
> be that these phy specific bits do just that!
> 

I have continued to modify the file (I have added 500MF, 1500MF and
500MF_LITE speed flags---that Realtek sets to 1000, 1000 and 2500! I
had a spurious rtl8168phycfg() that I suppressed; the
rtl8168macmcucfg() has to go in attach, and not in init, as well as
rtl8169hwinit() etc.).

So I plan to finish today and publish the version tonight (I just
updated at the date of this email what I have for now, but it will
evolve a bit once I understand where and how should go the Cmdplus
stuff for example).

> Re: the mii bits.. I'll have to test around with the code a bit, but I
> would like to make use of the recent mii() changes incorporating some
> of Clause 45 of the 802.3 into the code. That should give us status
> (though we can already do this through Realtek's registers), and
> autonegotiation for 2.5G/5G (which is maybe what's missing).
> 

This is also the part I have to look at today. For the 2.5G and 5G,
you may perhaps get the speed flags I have added for 5000MF_LITE, that
has to set speed to 2500! Your problem is perhaps that the incorrect
flag is passed in the the phy status.

Best,
-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T58f306392c5b4ca9-Maa6b16b0a02e2626321230c6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] pc/ether8169.c: done

[tlaronde]

I have "finished" writing the driver, at least for what I consider mandatory.

I have worked with the released Realtek driver (the FreeBSD flavor)
and have compared with what Aidan has found.

I have tried to organize a little the Realtek provided driver, putting
as parameters what is spread, all along, in daunting switches.

Not all the capabilities are used but at least almost all the cards
should be recognized (correctly drived is another matter).

I have verified that the driver compiles but have done strictly no
testing for the moment. As far as I'm concerned, I will first verify (later)
that the present cards (I have "old" Realtek ones) still work; and then
will switch to the Nix dedicated hardware (this was, for me, the
aim of the exercice) to see if the 8125 works and to try to make it
work starting from this.

I will let Aidan give a look at what I have written, since his work
has been quite a help when diving in the Realtek driver (there are
bits that I will have missed if I had not had his work as a guide).
The present driver incorporates main parts of his work (except what is
the Realtek black magic that I have taken from the Realtek source).

There are slight differences between what he has found and what I
found in the Realtek driver, so I have privileged the Realtek
implementation (example: addresses shifted left by 15, while Realtek
divides by 2 (translated as shifting right by 1), and then shifts left
by 16; this is not exactly the same, so I have written things
according to Realtek ((ra >>1) << 16). There are other such slight
discrepancies but mainly one finds similar treatments.

The latest version is here:

http://downloads.kergis.com/misc/9front/ether8169.c

(not a diff, since the modifications are so huge that it will make no
sense)

I suggest to make it work before speaking about style, function names
and so on.

On Mon, Apr 21, 2025 at 08:58:43AM +0200, tlaronde@kergis.com wrote:
> Hello Aidan,
> 
> On Sun, Apr 20, 2025 at 11:07:44AM -0700, Aidan K. Wiggins via 9fans wrote:
> > Hi Thierry,
> > 
> > Thanks for this work!
> > 
> > I think I agree that it's the right thing to do to shove all those
> > undocumented bits to the bottom of the file. I noticed that the file's
> > changed a bit since I last looked (e.g. +rtl8169getintr()), so it
> > looks like it's coming together well. I'll try and get to your patch
> > tonight; 2.5G operation doesn't work on my nic, so it very well could
> > be that these phy specific bits do just that!
> > 
> 
> I have continued to modify the file (I have added 500MF, 1500MF and
> 500MF_LITE speed flags---that Realtek sets to 1000, 1000 and 2500! I
> had a spurious rtl8168phycfg() that I suppressed; the
> rtl8168macmcucfg() has to go in attach, and not in init, as well as
> rtl8169hwinit() etc.).
> 
> So I plan to finish today and publish the version tonight (I just
> updated at the date of this email what I have for now, but it will
> evolve a bit once I understand where and how should go the Cmdplus
> stuff for example).
> 
> > Re: the mii bits.. I'll have to test around with the code a bit, but I
> > would like to make use of the recent mii() changes incorporating some
> > of Clause 45 of the 802.3 into the code. That should give us status
> > (though we can already do this through Realtek's registers), and
> > autonegotiation for 2.5G/5G (which is maybe what's missing).
> > 
> 
> This is also the part I have to look at today. For the 2.5G and 5G,
> you may perhaps get the speed flags I have added for 5000MF_LITE, that
> has to set speed to 2500! Your problem is perhaps that the incorrect
> flag is passed in the the phy status.
> 
> Best,
> --
> Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
>              http://www.kergis.com/
>             http://kertex.kergis.com/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6dcd1a43b39b723d-Mfc3ec3a2b8f2792fa086adc4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription