[9fans] pc/ether8169.c vs Realtek released driver

[9fans] pc/ether8169.c vs Realtek released driver

[tlaronde]

I have a candidate hardware with a Realtek RTL8125 2.5Gb Ethernet
Controller PCI-E that is, generally, bundled with the 8169 and al.
family.

Realtek publish drivers for various systems, so I retrieved the code
for FreeBSD to give it a look and try to add this new card to the
(9front) pc/ether8169.c driver:

https://www.realtek.com/Download/List?cate_id=584

But there are discrepancies between the 9front driver and the Realtek
FreeBSD modified one.

For example, when retrieving the macver, the Plan9 driver uses a
mask of:

HwveridMASK     = 0x7C800000

while the Realtek driver uses 0xFC800000

Since I'm discovering the code and this kind of task (adding a new
device to a driver), I may not grasp at first some technical reason
for doing so. Hence the question: is the mask different on purpose?
-- 
        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/T832e366730c74bfa-M12ddef863bae40e85be76599
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: pc/ether8169.c vs Realtek released driver

[tlaronde]

On Thu, Mar 06, 2025 at 09:07:46PM +0100, tlaronde wrote:
> I have a candidate hardware with a Realtek RTL8125 2.5Gb Ethernet
> Controller PCI-E that is, generally, bundled with the 8169 and al.
> family.
> 
> Realtek publish drivers for various systems, so I retrieved the code
> for FreeBSD to give it a look and try to add this new card to the
> (9front) pc/ether8169.c driver:
> 
> https://www.realtek.com/Download/List?cate_id=584
> 
> But there are discrepancies between the 9front driver and the Realtek
> FreeBSD modified one.
> 
> For example, when retrieving the macver, the Plan9 driver uses a
> mask of:
> 
> HwveridMASK     = 0x7C800000
> 
> while the Realtek driver uses 0xFC800000
> 

To be more precise: the Realtek driver uses 0xFC800000 for macver, and
uses 0x7CF00000 for Hardware revision.
-- 
        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/T832e366730c74bfa-M065dfdaff6da356dac2900bf
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] pc/ether8169.c vs Realtek released driver

[Aidan K. Wiggins via 9fans]

Hi Thierry,

I too have this chip, and have been attempting to add some preliminary
support for it in ether8169.c. I have a (WIP) patch hosted at
http://oneiri.one/ether8169.patch. It's a bit of a mess right now. I
have added some nominal support for other cards with the same register
set, but have not tested these other chips, have you been able to
tease out the exact version id for your model?

Regarding hwvid masks, I encountered this too when adding support. If
you look in the linux driver, they use a lookup table where each card
has a specific mask (either 7c8 or 7cf). In general, they use the 7cf
mask when they need to be more discerning about which card to match on
(e.g. RTL8125D and ... another slightly different RTL8125D). I didn't
want to break compatibility for older cards by outright using the more
restrictive mask, so my change attempts to use the restrictive mask
first, and then more lenient one if that fails.

The drivers for these newer nics are muddied with (mostly) nameless
registers and values to set, so it was a bit difficult figuring out
which pieces to pull together. The BSD's also include microcode in
lieu of firmware, which is actually the vendor driver's default. I
found that I didn't actually need to set them in my case, but we'll
see how it works out overtime, and with other chips.

Aidan

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T832e366730c74bfa-Medc81e0f9f623d225a3861fb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: pc/ether8169.c vs Realtek released driver

[Aidan K. Wiggins via 9fans]

Hrm,

I see what you mean, I think their usage of 0xFC800000 is to catch the
higher bits in older cards, looking specifically at the definitions
for the 8110 family in the linux driver. It seems that up to this
point all the cards defined in our driver can be recognized with
0x7C[8F]00000, but if someone walks along with hwverid 0x98000000, I
think we safely use 0xFC[8F]00000. Or is that we have instead been
using Macv05 == 0x98000000 & 0x7C800000 == 0x18000000 (as opposed to
the right mask & and the right value)?

Aidan

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T832e366730c74bfa-M6403cd1a89c90dc67ed109ce
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: pc/ether8169.c vs Realtek released driver

[ori]

Quoth tlaronde@kergis.com:
> On Thu, Mar 06, 2025 at 09:07:46PM +0100, tlaronde wrote:
> > I have a candidate hardware with a Realtek RTL8125 2.5Gb Ethernet
> > Controller PCI-E that is, generally, bundled with the 8169 and al.
> > family.
> > 
> > Realtek publish drivers for various systems, so I retrieved the code
> > for FreeBSD to give it a look and try to add this new card to the
> > (9front) pc/ether8169.c driver:
> > 
> > https://www.realtek.com/Download/List?cate_id=584
> > 
> > But there are discrepancies between the 9front driver and the Realtek
> > FreeBSD modified one.
> > 
> > For example, when retrieving the macver, the Plan9 driver uses a
> > mask of:
> > 
> > HwveridMASK     = 0x7C800000
> > 
> > while the Realtek driver uses 0xFC800000
> > 
> 
> To be more precise: the Realtek driver uses 0xFC800000 for macver, and
> uses 0x7CF00000 for Hardware revision.

FWIW, our macver numbers/ids were grabbed from linux, as far as I can tell.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T832e366730c74bfa-M1d35df6268d8e11c099a8588
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] pc/ether8169.c vs Realtek released driver

[tlaronde]

Hello Aidan,

On Thu, Mar 06, 2025 at 01:23:40PM -0800, Aidan K. Wiggins via 9fans wrote:
> Hi Thierry,
> 
> I too have this chip, and have been attempting to add some preliminary
> support for it in ether8169.c. I have a (WIP) patch hosted at
> http://oneiri.one/ether8169.patch. It's a bit of a mess right now. I
> have added some nominal support for other cards with the same register
> set, but have not tested these other chips, have you been able to
> tease out the exact version id for your model?
> 

Thank you for the link. I will give it a look this week-end and will
go back to you during the next week. Hopefully, joining our efforts,
we should manage to get the cards working.
 
> Regarding hwvid masks, I encountered this too when adding support. If
> you look in the linux driver, they use a lookup table where each card
> has a specific mask (either 7c8 or 7cf). In general, they use the 7cf
> mask when they need to be more discerning about which card to match on
> (e.g. RTL8125D and ... another slightly different RTL8125D). I didn't
> want to break compatibility for older cards by outright using the more
> restrictive mask, so my change attempts to use the restrictive mask
> first, and then more lenient one if that fails.
> 

From a cursory look, there are two distinct uses: one mask to match a
macver, and another mask to select a revision, with both setting
divergent things. In our present drivers, it seems the two cases are
more or less mixed---once again: I'm just starting to discover the
whole thing, so I may be wrong.

> The drivers for these newer nics are muddied with (mostly) nameless
> registers and values to set, so it was a bit difficult figuring out
> which pieces to pull together. The BSD's also include microcode in
> lieu of firmware, which is actually the vendor driver's default. I
> found that I didn't actually need to set them in my case, but we'll
> see how it works out overtime, and with other chips.

Yes, the 8125 specially has a bunch of hard coded commands, given by
Realtek, and no explanations. This could have something to do with the
mixed support for 10Mb, 100Mb, 1Gb and 2.5Gb. But when it comes to
explanations, there are almost none...


I will get back to you after doing some work on the stuff.
-- 
        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/T832e366730c74bfa-M99e22d248608b7847b54575b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: pc/ether8169.c vs Realtek released driver

[tlaronde]

On Thu, Mar 06, 2025 at 05:13:14PM -0500, ori@eigenstate.org wrote:
> Quoth tlaronde@kergis.com:
> > On Thu, Mar 06, 2025 at 09:07:46PM +0100, tlaronde wrote:
> > > I have a candidate hardware with a Realtek RTL8125 2.5Gb Ethernet
> > > Controller PCI-E that is, generally, bundled with the 8169 and al.
> > > family.
> > > 
> > > Realtek publish drivers for various systems, so I retrieved the code
> > > for FreeBSD to give it a look and try to add this new card to the
> > > (9front) pc/ether8169.c driver:
> > > 
> > > https://www.realtek.com/Download/List?cate_id=584
> > > 
> > > But there are discrepancies between the 9front driver and the Realtek
> > > FreeBSD modified one.
> > > 
> > > For example, when retrieving the macver, the Plan9 driver uses a
> > > mask of:
> > > 
> > > HwveridMASK     = 0x7C800000
> > > 
> > > while the Realtek driver uses 0xFC800000
> > > 
> > 
> > To be more precise: the Realtek driver uses 0xFC800000 for macver, and
> > uses 0x7CF00000 for Hardware revision.
> 
> FWIW, our macver numbers/ids were grabbed from linux, as far as I can tell.

I will work with the FreeBSD driver, the Linux driver, and the UEFI
driver (for this one, because I fear the AMD IOMMU could come in the
picture, and the card once "working", what was seen with usbxhci may
reproduce itself with the ethernet card; since the UEFI driver works---probably
in a suboptimal mode or speed---this would give a hint about what to do to have
it at least basically working).
-- 
        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/T832e366730c74bfa-M4cd6aa5554af0d7e087bc480
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] pc/ether8169.c vs Realtek released driver

[Aidan K. Wiggins via 9fans]

Hi Thierry,

> Thank you for the link. I will give it a look this week-end and will
> go back to you during the next week. Hopefully, joining our efforts,
> we should manage to get the cards wortking.

Excellent! It will be good to have more work/hardware when it comes to
these Realtek chips. Overtime, I will be updating the linked file of
any bugs/cleanups I find, which I have also now moved to
http://oneiri.one/9front/ether8169.patch for the time being. (One
problem I have encountered is losing Rx after unplugging the cable for
a couple of seconds, but this looks well evidenced in commits relating
to the setting of something called "aldps", which I'll try to get
going tonight.)

>  From a cursory look, there are two distinct uses: one mask to match a
> macver, and another mask to select a revision, with both setting
> divergent things. In our present drivers, it seems the two cases are
> more or less mixed---once again: I'm just starting to discover the
> whole thing, so I may be wrong.

Yes this is right, and we do mix them. We (like Linux), are just
making it so that the Mac version _and_ the revision ID identify the
card (Macv |= RevID); thus having the mask of 0x[7F]CF000000 lets us
differentiate between tested cards by switching on Macv[0-9]+, like
the two RTL8125D versions (as opposed to sub-switching elsewhere in
the code for every time we test for a 8125D).

> Yes, the 8125 specially has a bunch of hard coded commands, given by
> Realtek, and no explanations. This could have something to do with the
> mixed support for 10Mb, 100Mb, 1Gb and 2.5Gb. But when it comes to
> explanations, there are almost none...

Yes :). This is going to be fun.

> I will get back to you after doing some work on the stuff.

I wish you good fortune.

Thank you,
Aidan

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T832e366730c74bfa-Mbc3c254b625811711fd897d7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] pc/ether8169.c vs Realtek released driver

[tlaronde]

Hello Aidan,

I have started to look more closely at the various implementations
(Realtek provided, NetBSD --- indirectly from OpenBSD --- and Linux)
and your patch and I think we are on the same tracks.

Realtek uses the two masks for the macver: 0xFCF00000 to do what is
done (limitedly) with the macver on the current driver, and to set the
MACFG (MAC firmware conFiG?) type. The second mask 0x7C800000 is used
to refine with subconfiguration. I think we should do the same: the
general matching first; and handling the special cases, apart, after
without looping again.

One finds this for debugging in the Realtek driver:

sc->re_8169_MacVersion = (CSR_READ_4(sc, RE_TXCFG)&0x7c800000)>>25;
        /* Get bit 26~30        */      
sc->re_8169_MacVersion |= ((CSR_READ_4(sc, RE_TXCFG)&0x00800000)!=0 ? 1: 0);
     /* Get bit 23           */      
DBGPRINT1(sc->re_unit,"8169 Mac Version %d",sc->re_8169_MacVersion);  

So all are considered variants of the 8169, and I don't think we
should bother to continue trying to spot a version with enumerations
like:

Macv01          = 0x00000000,   /* RTL8169 */
Macv02          = 0x00800000,   /* RTL8169S/8110S */
Macv03          = 0x04000000,   /* RTL8169S/8110S */
...

but instead use, in a header, the MACFG_[0-9][0-9] used in the Realtek
driver and to let the hardcoded macver as is in a switch, simply
setting a type member in the Ctlr structure. This doesn't add any
complexity and this push the code nearer to what Realtek release, so
it will be more easy to read for people coming after us on the driver.

I think we agree that all the specific "black box" instructions for
the 8125 should be severed from the code. It is not binary firmware
(but in the spirit, it is), so we could put this in the header to keep the
C file humanly understandable (the Realtek if_re.c is almost 2MB in size!).

Since I'm on it, I will add also the 8126, even if I
don't have one, and add the variants:

enum {                                          /* Variants */
        Rtl8100e        = (0x8136<<16)|0x10EC,  /* RTL810[01]E: pci -e */
        Rtl8169c        = (0x0116<<16)|0x16EC,  /* RTL8169C+ (USR997902) */
        Rtl8125         = (0x8125<<16)|0x10EC,  /* RTL8125 pci-e */
        Rtl8126         = (0x8126<<16)|0x10EC,  /* RTL8126 pci-e */
        Rtl8129         = (0x8129<<16)|0x10EC,  /* RTL8129 */
        Rtl8139         = (0x8139<<16)|0x10EC,  /* RTL8139 */
        Rtl8111b        = (0x8161<<16)|0x10EC,  /* RTL8111/8168/8411: pci-e */
        Rtl8168kb       = (0x8162<<16)|0x10EC,  /* RTL8168KB */
        Rtl8169sc       = (0x8167<<16)|0x10EC,  /* RTL8169SC */
        Rtl8168b        = (0x8168<<16)|0x10EC,  /* RTL8168B: pci-e */
        Rtl8169         = (0x8169<<16)|0x10EC,  /* RTL8169 */
};
 

What I'm unclear about at the moment is the Wifi support. 

More generally, wouldn't it be more clear to use PCI_VENDOR_ID, PCI_DEVICE_ID,
etc. from a header instead of the hardcoded values? (that may be hard
to grep to find if support is there or not---I missed at first that
there is a U.S. Robotics card with a Realtek chip in the list since
the vendor id is 0x16EC, to be compared with Realtek 0x10EC.)

What do you, and what do other think about this?

I think I will have to "steal" a couple of hours this week every day
to come with something testable at the end of the week.

Best,

T. Laronde


On Fri, Mar 07, 2025 at 09:08:45PM -0800, Aidan K. Wiggins via 9fans wrote:
> Hi Thierry,
> 
> > Thank you for the link. I will give it a look this week-end and will
> > go back to you during the next week. Hopefully, joining our efforts,
> > we should manage to get the cards wortking.
> 
> Excellent! It will be good to have more work/hardware when it comes to
> these Realtek chips. Overtime, I will be updating the linked file of
> any bugs/cleanups I find, which I have also now moved to
> http://oneiri.one/9front/ether8169.patch for the time being. (One
> problem I have encountered is losing Rx after unplugging the cable for
> a couple of seconds, but this looks well evidenced in commits relating
> to the setting of something called "aldps", which I'll try to get
> going tonight.)
> 
> >  From a cursory look, there are two distinct uses: one mask to match a
> > macver, and another mask to select a revision, with both setting
> > divergent things. In our present drivers, it seems the two cases are
> > more or less mixed---once again: I'm just starting to discover the
> > whole thing, so I may be wrong.
> 
> Yes this is right, and we do mix them. We (like Linux), are just
> making it so that the Mac version _and_ the revision ID identify the
> card (Macv |= RevID); thus having the mask of 0x[7F]CF000000 lets us
> differentiate between tested cards by switching on Macv[0-9]+, like
> the two RTL8125D versions (as opposed to sub-switching elsewhere in
> the code for every time we test for a 8125D).
> 
> > Yes, the 8125 specially has a bunch of hard coded commands, given by
> > Realtek, and no explanations. This could have something to do with the
> > mixed support for 10Mb, 100Mb, 1Gb and 2.5Gb. But when it comes to
> > explanations, there are almost none...
> 
> Yes :). This is going to be fun.
> 
> > I will get back to you after doing some work on the stuff.
> 
> I wish you good fortune.
> 
> Thank you,
> Aidan

-- 
        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/T832e366730c74bfa-M3e6548281ab075d38be62ef2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] pc/ether8169.c vs Realtek released driver

[ori]

Quoth tlaronde@kergis.com:
> 
> More generally, wouldn't it be more clear to use PCI_VENDOR_ID, PCI_DEVICE_ID,
> etc. from a header instead of the hardcoded values? (that may be hard
> to grep to find if support is there or not---I missed at first that
> there is a U.S. Robotics card with a Realtek chip in the list since
> the vendor id is 0x16EC, to be compared with Realtek 0x10EC.)
> 
> What do you, and what do other think about this?

It's far clearer, in my books, to have:

        switch(did){
        case 0x8169:    /* Rtl8169 */
                ...
        }
        

in the one place that it's used, than to have it hidden in
a header somewhere. All of our drivers are currently self
contained, and use this pattern. Let's not break that.



------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T832e366730c74bfa-M45b2fce46acb2a1c83d73a14
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] pc/ether8169.c vs Realtek released driver

[tlaronde]

On Sun, Mar 09, 2025 at 03:00:46PM -0400, ori@eigenstate.org wrote:
> Quoth tlaronde@kergis.com:
> > 
> > More generally, wouldn't it be more clear to use PCI_VENDOR_ID, PCI_DEVICE_ID,
> > etc. from a header instead of the hardcoded values? (that may be hard
> > to grep to find if support is there or not---I missed at first that
> > there is a U.S. Robotics card with a Realtek chip in the list since
> > the vendor id is 0x16EC, to be compared with Realtek 0x10EC.)
> > 
> > What do you, and what do other think about this?
> 
> It's far clearer, in my books, to have:
> 
>         switch(did){
>         case 0x8169:    /* Rtl8169 */
>                 ...
>         }
>         
> 
> in the one place that it's used, than to have it hidden in
> a header somewhere. All of our drivers are currently self
> contained, and use this pattern. Let's not break that.
> 

Would you accept at least, in the very file, defines:

#define REALTEK_VID 0x10EC
#define USROBOTICS_VID 0x16EC

so that one can write:

        Rtl8100e        = (0x8136<<16)|REALTEK_VID,     /* RTL810[01]E: pci -e */
        Rtl8169c        = (0x0116<<16)|USROBOTICS_VID,  /* RTL8169C+ (USR997902) */

that is far easier to catch instead of 0x10EC vs 0x16EC, one above the
other (I thought it was a typo before consulting the PCI databases).

-- 
        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/T832e366730c74bfa-M4e199640c27164a0b32e7411
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] pc/ether8169.c vs Realtek released driver

[Aidan K. Wiggins via 9fans]

Hi Thierry,

> Realtek uses the two masks for the macver: 0xFCF00000 to do what is
> done (limitedly) with the macver on the current driver, and to set the
> MACFG (MAC firmware conFiG?) type. The second mask 0x7C800000 is used
> to refine with subconfiguration. I think we should do the same: the
> general matching first; and handling the special cases, apart, after
> without looping again.

I think I understand what you're getting at here: instead of having an
enum constant for every little card, we should be using the MACFG
values as indicated by the result of ANDing with 0xFCF000000, as seen
in re_check_mac_version() of Realtek's BSD source. I think there is
merit in this approach, but it would require changing more of the code
than I thought immediately necessary, which is partially why I just
decided to follow suit in borrowing values from Linux (esp. with it's
large userbase included). With looping in our vetmacv(), I was
attempting to keep some level of guaranteed backwards compatibility,
since I wasn't sure if a more specific (0xFCF) mask would tease out a
new Macv value from an older card that was otherwise previously
supported under the mask 0x7C800000.

> What I'm unclear about at the moment is the Wifi support. 

Can you expand on this?

> More generally, wouldn't it be more clear to use PCI_VENDOR_ID, PCI_DEVICE_ID,
> etc. from a header instead of the hardcoded values? (that may be hard
> to grep to find if support is there or not---I missed at first that
> there is a U.S. Robotics card with a Realtek chip in the list since
> the vendor id is 0x16EC, to be compared with Realtek 0x10EC.)

I agree with Ori's approach here, the device IDs are so specific that
they really only need inclusion in their respective drivers. We do,
however, have some vendor IDs in pci.h, so you could have:

        #define PCIdev(vid, did)        ((vid)<<16|(did))
        enum{
        Rtl8169 = PCIdev(Vrealtek, 0x8169),
        Rtl8169c= PCIdev(0x16ec, 0x0116)
        ...
        }

        switch(PCIdev(p->vid, p->did)){
        ...
        }

If it weren't for these non-realtek chips, I think we would just use
switch(did){}.

> I think I will have to "steal" a couple of hours this week every day
> to come with something testable at the end of the week.

Sounds good :)

Aidan

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T832e366730c74bfa-M1845e8001ee31b4a83f624ab
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] pc/ether8169.c vs Realtek released driver

[tlaronde]

On Sun, Mar 09, 2025 at 12:46:55PM -0700, Aidan K. Wiggins via 9fans wrote:
> Hi Thierry,
> 
> > Realtek uses the two masks for the macver: 0xFCF00000 to do what is
> > done (limitedly) with the macver on the current driver, and to set the
> > MACFG (MAC firmware conFiG?) type. The second mask 0x7C800000 is used
> > to refine with subconfiguration. I think we should do the same: the
> > general matching first; and handling the special cases, apart, after
> > without looping again.
> 
> I think I understand what you're getting at here: instead of having an
> enum constant for every little card, we should be using the MACFG
> values as indicated by the result of ANDing with 0xFCF000000, as seen
> in re_check_mac_version() of Realtek's BSD source. I think there is
> merit in this approach, but it would require changing more of the code
> than I thought immediately necessary, which is partially why I just
> decided to follow suit in borrowing values from Linux (esp. with it's
> large userbase included). With looping in our vetmacv(), I was
> attempting to keep some level of guaranteed backwards compatibility,
> since I wasn't sure if a more specific (0xFCF) mask would tease out a
> new Macv value from an older card that was otherwise previously
> supported under the mask 0x7C800000.
> 

The 8125 will add so much code that I think we can depart for some
things from the current state. Since the first test is about the PCI
device ID, before verifying the macver, the problems should be unlikely.

But my mind is not set for now about the style. What I want to find is
something both small and clear enough for anyone having to work with
the driver to understand rapidly what is done. The Linux team seems to
be working to some extend with the hardware producers, so I will, too,
keep also the Linux driver as a guide---but I give a kind of priority
to the Realtek provided one because they are supposed to know what
they do produce ;-)

One could also define flags and have a struct with the hardware
version and a definition of the corresponding flags, with the
initialization simply done if the flag if set.

> > What I'm unclear about at the moment is the Wifi support. 
> 
> Can you expand on this?
> 

My card at least, has a RJ45 but provides wireless connection too. I have
to find if the distinction is the device ID, or the function (or a 
revision), and if the Realtek driver has some parts dedicated to wireless
configuration.

So the question: are the wireless features mixed with this and should
be done "here", or can be postpone being supposedly dealt with by
another driver?

> > More generally, wouldn't it be more clear to use PCI_VENDOR_ID, PCI_DEVICE_ID,
> > etc. from a header instead of the hardcoded values? (that may be hard
> > to grep to find if support is there or not---I missed at first that
> > there is a U.S. Robotics card with a Realtek chip in the list since
> > the vendor id is 0x16EC, to be compared with Realtek 0x10EC.)
> 
> I agree with Ori's approach here, the device IDs are so specific that
> they really only need inclusion in their respective drivers. We do,
> however, have some vendor IDs in pci.h, so you could have:
> 
>         #define PCIdev(vid, did)        ((vid)<<16|(did))
>         enum{
>         Rtl8169 = PCIdev(Vrealtek, 0x8169),
>         Rtl8169c= PCIdev(0x16ec, 0x0116)
>         ...
>         }
> 
>         switch(PCIdev(p->vid, p->did)){
>         ...
>         }

Yep, I like it more this way!

> 
> If it weren't for these non-realtek chips, I think we would just use
> switch(did){}.
> 

The problem is that there is two "alien" cards: the US ROBOTICS, set
in the enum, and one hard coded in the switch (to fall back to the
Rtl8169 case):

                case (0xC107<<16)|0x1259:       /* Corega CG-LAPCIGT */

(These are the exceptions that we will have to verify we are not dropping
by inadvertence.)

-- 
        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/T832e366730c74bfa-M7c40e88b71cc8ae8dd406a0a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] pc/ether8169.c vs Realtek released driver

[ori]

Quoth Aidan K. Wiggins via 9fans <9fans@9fans.net>:
> If it weren't for these non-realtek chips, I think we would just use
> switch(did){}.

Ugh. yes. I figure it'd be fine to add

        enum {
                /*
                 * Some realtek chips are sold with
                 * the US robotics vendor id.
                 */
                VRtl = 0x10EC,
                VUsr = 0x16EC,
        };

Usually, we'd just check the vendor and
switch on the device id.

(these realtek cards are a pain; a ton of
odd special cases...)


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T832e366730c74bfa-M8f1600a2bbcbb03367923327
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] pc/ether8169.c vs Realtek released driver

[tlaronde]

This is still a WIP and I have tried to modify the way things are
handled in order to clarify a bit.

For reference the file is there:

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

but I haven't tried to compile it (because I have to fix my 9front
installation after moving a disk and this will be for another thread).

What I have done:

To clarify, the 8169 is the "order"; in this order, there are
8 "families": 

        Rtl8101E
        Rtl8111
        Rtl8129
        Rtl8139C
        Rtl8168
        Rtl8169
        Rtl8125
        Rtl8126

corresponding to 17 PCI devices (vid:did) devices

from 6 distinct vendors:

        Realtek
        Ncube
        D-LINK
        Allied Telesis Inc
        USRobotics
        Linksys

and... 82! Mac species.

In order to know what is there and how to configure, we first match
a PCI device to its family (and "gender" in the family by setting
flags).

Then we get the hardware revision to identify the "specie", adding to
flags, defining the MTU (some cards can have 4k, 6k, 7k or 9k jumbo
frames), a cardinal defining the Macfg, and an initial magic value for
the configuration (rxcfg_val).

For the moment (in the code: neither compiled nor tested), all the
tentative devices, families, genders and species (I use these words
for explanation; only "family" is used in the code) are recognized but
the Rtl8125 and Rtl8216 are not handled yet (this will be added in
collaboration with Aidan once we agree on the structures and way to
handle the things).

I have kept, for now, the low level config done matching what I have
called Mii version---the name is very probably incorrect---so that as
a first step the driver should drive more devices belonging to the
already handled families (not the Rtl8125 and Rtl8126) without
breaking things.

What I need to clarify further:

- In the Realtek driver, there is a magic value sent first as the
value for the rcr (receive configuration register). I'm unclear if
this is all that has to be sent or if once sent, other configurations
can follow (the present driver is sending custom configurations) or if
the initial value must be ORed with custom ones;

- Some registers used in the driver are even not present in the
Realtek driver (I have completed the enumeration from Aidan patch
correlating with the Realtek driver);

- The speeds (additional ones being present in Aidan's patch) should
probably be handled setting flags (as for PCIE and various
capabilities);

- In other kernels, the MII is segregated from the "higher" level,
while in our driver things are mixed; I need to untangle things
too---an unknown MII should just lead to basic handling without
giving up; but the problem is to identify it correctly.

IMHO, once the present driver will be cleaned to extend support for,
if not all, at least this wider range of compatible with present handled
families devices, the support for Rlt8125 and Rtl8126 will be added,
placing the huge Rtl8125 idiosynchrasies (firmware) in a separated
file in order to keep the logics of the driver understandable.

On Sun, Mar 09, 2025 at 09:22:50PM +0100, tlaronde@kergis.com wrote:
> On Sun, Mar 09, 2025 at 12:46:55PM -0700, Aidan K. Wiggins via 9fans wrote:
> > Hi Thierry,
> > 
> > > Realtek uses the two masks for the macver: 0xFCF00000 to do what is
> > > done (limitedly) with the macver on the current driver, and to set the
> > > MACFG (MAC firmware conFiG?) type. The second mask 0x7C800000 is used
> > > to refine with subconfiguration. I think we should do the same: the
> > > general matching first; and handling the special cases, apart, after
> > > without looping again.
> > 
> > I think I understand what you're getting at here: instead of having an
> > enum constant for every little card, we should be using the MACFG
> > values as indicated by the result of ANDing with 0xFCF000000, as seen
> > in re_check_mac_version() of Realtek's BSD source. I think there is
> > merit in this approach, but it would require changing more of the code
> > than I thought immediately necessary, which is partially why I just
> > decided to follow suit in borrowing values from Linux (esp. with it's
> > large userbase included). With looping in our vetmacv(), I was
> > attempting to keep some level of guaranteed backwards compatibility,
> > since I wasn't sure if a more specific (0xFCF) mask would tease out a
> > new Macv value from an older card that was otherwise previously
> > supported under the mask 0x7C800000.
> > 
> 
> The 8125 will add so much code that I think we can depart for some
> things from the current state. Since the first test is about the PCI
> device ID, before verifying the macver, the problems should be unlikely.
> 
> But my mind is not set for now about the style. What I want to find is
> something both small and clear enough for anyone having to work with
> the driver to understand rapidly what is done. The Linux team seems to
> be working to some extend with the hardware producers, so I will, too,
> keep also the Linux driver as a guide---but I give a kind of priority
> to the Realtek provided one because they are supposed to know what
> they do produce ;-)
> 
> One could also define flags and have a struct with the hardware
> version and a definition of the corresponding flags, with the
> initialization simply done if the flag if set.
> 
> > > What I'm unclear about at the moment is the Wifi support. 
> > 
> > Can you expand on this?
> > 
> 
> My card at least, has a RJ45 but provides wireless connection too. I have
> to find if the distinction is the device ID, or the function (or a 
> revision), and if the Realtek driver has some parts dedicated to wireless
> configuration.
> 
> So the question: are the wireless features mixed with this and should
> be done "here", or can be postpone being supposedly dealt with by
> another driver?
> 
> > > More generally, wouldn't it be more clear to use PCI_VENDOR_ID, PCI_DEVICE_ID,
> > > etc. from a header instead of the hardcoded values? (that may be hard
> > > to grep to find if support is there or not---I missed at first that
> > > there is a U.S. Robotics card with a Realtek chip in the list since
> > > the vendor id is 0x16EC, to be compared with Realtek 0x10EC.)
> > 
> > I agree with Ori's approach here, the device IDs are so specific that
> > they really only need inclusion in their respective drivers. We do,
> > however, have some vendor IDs in pci.h, so you could have:
> > 
> >         #define PCIdev(vid, did)        ((vid)<<16|(did))
> >         enum{
> >         Rtl8169 = PCIdev(Vrealtek, 0x8169),
> >         Rtl8169c= PCIdev(0x16ec, 0x0116)
> >         ...
> >         }
> > 
> >         switch(PCIdev(p->vid, p->did)){
> >         ...
> >         }
> 
> Yep, I like it more this way!
> 
> > 
> > If it weren't for these non-realtek chips, I think we would just use
> > switch(did){}.
> > 
> 
> The problem is that there is two "alien" cards: the US ROBOTICS, set
> in the enum, and one hard coded in the switch (to fall back to the
> Rtl8169 case):
> 
> case (0xC107<<16)|0x1259:       /* Corega CG-LAPCIGT */
> 
> (These are the exceptions that we will have to verify we are not dropping
> by inadvertence.)
> 
> --
> 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/T832e366730c74bfa-M4bf94372d942fa9eca8ec522
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] pc/ether8169.c vs Realtek released driver

[tlaronde]

Thanks to Jacob Moody, I have fixed my 9front installed so has
compiled the file. The version present now here:

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

has been cleared of the trivial typos. It compiles (not tested, and
not totally clean for the first step: extending support while
reorganizing for Rtl8125 and Rtl8126 support).
 
On Mon, Mar 17, 2025 at 10:48:19AM +0100, tlaronde@kergis.com wrote:
> This is still a WIP and I have tried to modify the way things are
> handled in order to clarify a bit.
> 
> For reference the file is there:
> 
> http://downloads.kergis.com/misc/9front/ether8169.c
> 
> but I haven't tried to compile it (because I have to fix my 9front
> installation after moving a disk and this will be for another thread).
> 
> What I have done:
> 
> To clarify, the 8169 is the "order"; in this order, there are
> 8 "families": 
> 
>         Rtl8101E
>         Rtl8111
>         Rtl8129
>         Rtl8139C
>         Rtl8168
>         Rtl8169
>         Rtl8125
>         Rtl8126
> 
> corresponding to 17 PCI devices (vid:did) devices
> 
> from 6 distinct vendors:
> 
>         Realtek
>         Ncube
>         D-LINK
>         Allied Telesis Inc
>         USRobotics
>         Linksys
> 
> and... 82! Mac species.
> 
> In order to know what is there and how to configure, we first match
> a PCI device to its family (and "gender" in the family by setting
> flags).
> 
> Then we get the hardware revision to identify the "specie", adding to
> flags, defining the MTU (some cards can have 4k, 6k, 7k or 9k jumbo
> frames), a cardinal defining the Macfg, and an initial magic value for
> the configuration (rxcfg_val).
> 
> For the moment (in the code: neither compiled nor tested), all the
> tentative devices, families, genders and species (I use these words
> for explanation; only "family" is used in the code) are recognized but
> the Rtl8125 and Rtl8216 are not handled yet (this will be added in
> collaboration with Aidan once we agree on the structures and way to
> handle the things).
> 
> I have kept, for now, the low level config done matching what I have
> called Mii version---the name is very probably incorrect---so that as
> a first step the driver should drive more devices belonging to the
> already handled families (not the Rtl8125 and Rtl8126) without
> breaking things.
> 
> What I need to clarify further:
> 
> - In the Realtek driver, there is a magic value sent first as the
> value for the rcr (receive configuration register). I'm unclear if
> this is all that has to be sent or if once sent, other configurations
> can follow (the present driver is sending custom configurations) or if
> the initial value must be ORed with custom ones;
> 
> - Some registers used in the driver are even not present in the
> Realtek driver (I have completed the enumeration from Aidan patch
> correlating with the Realtek driver);
> 
> - The speeds (additional ones being present in Aidan's patch) should
> probably be handled setting flags (as for PCIE and various
> capabilities);
> 
> - In other kernels, the MII is segregated from the "higher" level,
> while in our driver things are mixed; I need to untangle things
> too---an unknown MII should just lead to basic handling without
> giving up; but the problem is to identify it correctly.
> 
> IMHO, once the present driver will be cleaned to extend support for,
> if not all, at least this wider range of compatible with present handled
> families devices, the support for Rlt8125 and Rtl8126 will be added,
> placing the huge Rtl8125 idiosynchrasies (firmware) in a separated
> file in order to keep the logics of the driver understandable.
> 
> On Sun, Mar 09, 2025 at 09:22:50PM +0100, tlaronde@kergis.com wrote:
> > On Sun, Mar 09, 2025 at 12:46:55PM -0700, Aidan K. Wiggins via 9fans wrote:
> > > Hi Thierry,
> > > 
> > > > Realtek uses the two masks for the macver: 0xFCF00000 to do what is
> > > > done (limitedly) with the macver on the current driver, and to set the
> > > > MACFG (MAC firmware conFiG?) type. The second mask 0x7C800000 is used
> > > > to refine with subconfiguration. I think we should do the same: the
> > > > general matching first; and handling the special cases, apart, after
> > > > without looping again.
> > > 
> > > I think I understand what you're getting at here: instead of having an
> > > enum constant for every little card, we should be using the MACFG
> > > values as indicated by the result of ANDing with 0xFCF000000, as seen
> > > in re_check_mac_version() of Realtek's BSD source. I think there is
> > > merit in this approach, but it would require changing more of the code
> > > than I thought immediately necessary, which is partially why I just
> > > decided to follow suit in borrowing values from Linux (esp. with it's
> > > large userbase included). With looping in our vetmacv(), I was
> > > attempting to keep some level of guaranteed backwards compatibility,
> > > since I wasn't sure if a more specific (0xFCF) mask would tease out a
> > > new Macv value from an older card that was otherwise previously
> > > supported under the mask 0x7C800000.
> > > 
> > 
> > The 8125 will add so much code that I think we can depart for some
> > things from the current state. Since the first test is about the PCI
> > device ID, before verifying the macver, the problems should be unlikely.
> > 
> > But my mind is not set for now about the style. What I want to find is
> > something both small and clear enough for anyone having to work with
> > the driver to understand rapidly what is done. The Linux team seems to
> > be working to some extend with the hardware producers, so I will, too,
> > keep also the Linux driver as a guide---but I give a kind of priority
> > to the Realtek provided one because they are supposed to know what
> > they do produce ;-)
> > 
> > One could also define flags and have a struct with the hardware
> > version and a definition of the corresponding flags, with the
> > initialization simply done if the flag if set.
> > 
> > > > What I'm unclear about at the moment is the Wifi support. 
> > > 
> > > Can you expand on this?
> > > 
> > 
> > My card at least, has a RJ45 but provides wireless connection too. I have
> > to find if the distinction is the device ID, or the function (or a 
> > revision), and if the Realtek driver has some parts dedicated to wireless
> > configuration.
> > 
> > So the question: are the wireless features mixed with this and should
> > be done "here", or can be postpone being supposedly dealt with by
> > another driver?
> > 
> > > > More generally, wouldn't it be more clear to use PCI_VENDOR_ID, PCI_DEVICE_ID,
> > > > etc. from a header instead of the hardcoded values? (that may be hard
> > > > to grep to find if support is there or not---I missed at first that
> > > > there is a U.S. Robotics card with a Realtek chip in the list since
> > > > the vendor id is 0x16EC, to be compared with Realtek 0x10EC.)
> > > 
> > > I agree with Ori's approach here, the device IDs are so specific that
> > > they really only need inclusion in their respective drivers. We do,
> > > however, have some vendor IDs in pci.h, so you could have:
> > > 
> > >         #define PCIdev(vid, did)        ((vid)<<16|(did))
> > >         enum{
> > >         Rtl8169 = PCIdev(Vrealtek, 0x8169),
> > >         Rtl8169c= PCIdev(0x16ec, 0x0116)
> > >         ...
> > >         }
> > > 
> > >         switch(PCIdev(p->vid, p->did)){
> > >         ...
> > >         }
> > 
> > Yep, I like it more this way!
> > 
> > > 
> > > If it weren't for these non-realtek chips, I think we would just use
> > > switch(did){}.
> > > 
> > 
> > The problem is that there is two "alien" cards: the US ROBOTICS, set
> > in the enum, and one hard coded in the switch (to fall back to the
> > Rtl8169 case):
> > 
> > case (0xC107<<16)|0x1259:       /* Corega CG-LAPCIGT */
> > 
> > (These are the exceptions that we will have to verify we are not dropping
> > by inadvertence.)
> > 
> > --
> > 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

-- 
        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/T832e366730c74bfa-M8d93e808f1b432362423e797
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription