I read over the FreeBSD 4.x em driver pretty thoroughly a year or so back.

That driver is built on top of a large, OS-independent Intel "library"
ffor for the Pro/1000 hardware. The line-count for if_em_hw.c includes
a lot of link-autonegotiaton machinery for OSes that lack (for
example, NetBSD's MII layer. If you're going to count all the lines of
code to drive PHYs and handle cable polarity quirks, then you should
also count corresponding lines from the NetBSD sys/dev/mii.
(Or just not count the PHY lines, if they're not acutally used.)

if_em_hw.c also has some really verbose, heavily-commented code for
reading and writing the EEPROms, and for driving the LEDs on three or
four different hardware chip generations in a fashion that (looking at
LEDs from outside the case), looks consistent across the family.

As best I recall, relatively little of that code actually had to do
with hardware tuning; that was mostly the software FSM that
implemented link-layer flow-control, and flow-control backoff.
(I agree it would be nice to pull in. )

Newer versions have some goop for TDR-like tuning of the Marvel M88
PHYs; if we want that we should pull it into makphy so that all
devices using the makphy can benefit.