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