Uwe Kleine-König wrote: > Do you want to continue looking after the issue?
Thanks for the poke. Unfortunately I'm stumped and won't be able to pursue this anymore. I looked over the kernel.org Bugzilla, git log for relevant driver changes, likewise for linux-firmware repo, and searched for reports online of users having problems with the same hardware, and had no luck. On a different tangent, I looked into Realtek's driver which is currently in the non-free section and it is actually wholly licensed under the GNU GPL, but not included in main because it contains tables of random-looking bytes that are assumed to be firmware patches of some kind. However the mainline kernel driver is similar (even more so recently) which feels like a double standard. I was surprised to see that even Linux-libre doesn't remove that, so I sent the attached mail to them to learn more for the sake of curiosity. I don't know that we have a firm stance in Debian about "magic blobs" that are inline with the kernel source which aren't firmware (in the linux-firmware.git conventional sense).
--- Begin Message ---Hi, While researching a related issue for Debian, I found that the kernel's in-tree driver for these Realtek Ethernet NICs has many tables of magic numbers that are opaque and seem to have been crafted with internal information at Realtek. See drivers/net/ethernet/realtek/r8169_main.c for example, and look for the definition of the rtl_enable_ltr() function around line 3000, as well as "fix-up" code in rtl8411b_fix_phy_down(). Inside the rtl_hw_start_8411_2() function there's even this concession: > /* The following Realtek-provided magic fixes an issue with the RX unit > * getting confused after the PHY having been powered-down. > */ > r8168_mac_ocp_write(tp, 0xFC28, 0x0000); > r8168_mac_ocp_write(tp, 0xFC2A, 0x0000); > r8168_mac_ocp_write(tp, 0xFC2C, 0x0000); > r8168_mac_ocp_write(tp, 0xFC2E, 0x0000); Much of this is in code added fairly recently, as in rtl_hw_start_8125_common(). This is present in Linux-libre; how do we feel about this sort of thing? I want to make sure it wasn't missed and its inclusion is intentional. For some NICs though (I think I have an RTL8168 handy?) I don't think the firmware is necessary, so this driver is still useful but is complicated by the fact that it supports both very old and very new NICs. If the secret numbers are only needed for the new generation, maybe the tables can be zeroed out in anticipation that older NICS will never reach the code.
signature.asc
Description: This is a digitally signed message part_______________________________________________ linux-libre mailing list [email protected] http://www.fsfla.org/cgi-bin/mailman/listinfo/linux-libre
--- End Message ---
signature.asc
Description: This is a digitally signed message part
