net: an RTL8139 driver, and the e1000 stops refusing the PCIe parts

Two NICs, and unlike the RTL8111 last commit, QEMU emulates both -- so both
are tested rather than reasoned about.

**RTL8139** is its own driver and not a mode of the 8169, because it is its own
chip. No descriptor rings: the receiver is one circular buffer the chip writes
packets into back to back behind four-byte headers, and the transmitter is four
fixed slots. Putting both programming models behind one set of function
pointers is how a mode flag ends up threaded through every path.

Three details are the whole driver. CAPR runs sixteen bytes behind the true
read position -- a quirk of the part, not an off-by-one. WRAP means the chip
runs a packet past the end of the buffer rather than splitting it, so the 8 KB
buffer is allocated as 8 KB + 16 + one maximum frame; getting that wrong is a
chip writing past its allocation at line rate. And a length field of 0xFFF0
means "still writing this one", so treating it as a length copies a partial
packet and loses the alignment for everything after it.

**The e1000 now matches the PCIe 8257x parts.** Its header refused them, with
a note saying they "differ in NVM access and initialisation, and claiming a
device this driver has not been shown to initialise is worse than not claiming
it". That was right, and the second half is answerable: QEMU emulates the
82574L, so it can be *shown* to initialise.

What differs turned out to be one register. EERD moved its address field from
bits 8-15 to bits 2-15 and its done bit from 4 to 1; the rings, RCTL, TCTL and
ICR are identical. So there is a per-instance flag for the NVM layout and seven
more ids -- not a second copy of four hundred lines of ring code. The wrong
pair of constants fails silently, reading the wrong word or waiting for a bit
that never sets, and the MAC comes out as zeroes; that is why it is named in
the header rather than papered over.

Still refused: the ICH/PCH parts (82562, 82577-82579, I217-I219), which put the
PHY behind a MAC-PHY interconnect and need a different bring-up nothing here
can test.

Tested, each booted alone: rtl8139 (10ec:8139) and 82574L (8086:10d3) both bind,
read a real MAC, complete DHCP and ping 4 of 4 with no loss. The classic
82540EM does the same, which is the regression that mattered for the NVM
change. Both supported display configurations: one boot each, no traps, no
panics, socktest and memfdtest green.

Also recorded: the Chromebox CN62 carries an RTL8111, not an Intel part, so
last commit's driver covers it too.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

kernel/drivers/net/e1000/e1000.h

@@ -26,11 +26,23 @@
 // the sort of second-hand hardware a system like this actually gets run on.
 // These are the cards in every desktop and server of that generation.
 //
-// Deliberately *not* included: the PCIe 8257x parts (82571-82574) and anything
-// newer. They present a similar register map but differ in NVM access and
-// initialisation, and claiming a device this driver has not been shown to
-// initialise is worse than not claiming it -- the card binds, reports a MAC of
-// nonsense, and nothing works for reasons that look nothing like the cause.
+// The PCIe 8257x parts used to be excluded here, on the argument that they
+// "differ in NVM access and initialisation, and claiming a device this driver
+// has not been shown to initialise is worse than not claiming it". That
+// argument was right and the second half of it is now answerable: QEMU
+// emulates the 82574L, so the part can be *shown* to initialise rather than
+// assumed to.
+//
+// What actually differs turned out to be one register's layout. EERD moved its
+// address field and its done bit between the two generations, and everything
+// else this driver touches -- the descriptor rings, RCTL, TCTL, the interrupt
+// cause register -- is the same. So the 8257x parts are matched, with the NVM
+// difference named below and handled, rather than a second copy of four
+// hundred lines of ring code.
+//
+// Still *not* included: the ICH/PCH parts (82562, 82577-82579, I217-I219).
+// Those put the PHY behind a MAC-PHY interconnect and need a genuinely
+// different bring-up, and nothing here can test one.
 #define E1000_DEV_82540EM            0x100E
 #define E1000_DEV_82540EM_LOM        0x1015
 #define E1000_DEV_82540EP_LOM        0x1016
@@ -57,6 +69,17 @@
 #define E1000_DEV_82546GB_COPPER     0x1079
 #define E1000_DEV_82546GB_FIBER      0x107A
 #define E1000_DEV_82546GB_SERDES     0x107B
+// The PCIe generation. 82574L is the one QEMU emulates and therefore the one
+// this driver has been shown to bring up; its siblings share the register map
+// and the NVM layout.
+#define E1000_DEV_82571EB_COPPER     0x105E
+#define E1000_DEV_82572EI_COPPER     0x107D
+#define E1000_DEV_82572EI            0x10B9
+#define E1000_DEV_82573E             0x108B
+#define E1000_DEV_82573L             0x109A
+#define E1000_DEV_82574L             0x10D3
+#define E1000_DEV_82583V             0x150C
+
 #define E1000_DEV_82547EI            0x1019
 
 // --- registers, byte offsets into BAR 0 ------------------------------------
@@ -96,12 +119,21 @@
 // STATUS
 #define E1000_STATUS_LU     (1 << 1)    // link up
 
-// EERD
+// EERD, and the one thing that is not the same across the two generations.
+//
+// On the 8254x the address goes in bits 8-15 and the chip answers with bit 4.
+// On the PCIe 8257x the address is in bits 2-15 and the answer is bit 1. Using
+// the wrong pair does not fail loudly: it reads the wrong word, or waits for a
+// bit that will never be set, and the MAC ends up as zeroes or as somebody
+// else's address.
 #define E1000_EERD_START    (1 << 0)
 #define E1000_EERD_DONE     (1 << 4)
 #define E1000_EERD_ADDR_SHIFT 8
 #define E1000_EERD_DATA_SHIFT 16
 
+#define E1000_EERD_DONE_8257X    (1 << 1)
+#define E1000_EERD_ADDR_SHIFT_8257X 2
+
 // RCTL
 #define E1000_RCTL_EN       (1 << 1)    // receiver enable
 #define E1000_RCTL_SBP      (1 << 2)    // store bad packets