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
