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, tlaro...@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
