[REGRESSION] e1000e: heavy packet loss on Lenovo ThinkPad P14s Gen 5 (I219-LM, Meteor Lake) after K1 re-enable; fixed by disable-k1

Hi,

Since commit 578294b8b60d ("e1000e: Reconfigure PLL clock gate timeout and
re-enable K1 on Meteor Lake") the integrated I219-LM in a Lenovo ThinkPad
P14s Gen 5 (Intel variant, Core Ultra 9 185H) shows constant packet loss
and erratic latency on the wired link. Wi-Fi and a USB-C RTL8152 adapter on
the same cable, switch and router are fine, so the network itself is not
the problem.

Setting the private flag "disable-k1" fixes it immediately, so this looks
like another system where the PLL clock gate reconfiguration is not enough
and the DMI quirk table introduced by that commit should be extended.

System
------
  Laptop:          Lenovo ThinkPad P14s Gen 5 (Intel)
  DMI sys_vendor:  LENOVO
  DMI product_name:    21G2CTO1WW
  DMI product_version: ThinkPad P14s Gen 5
  DMI board_name:  21G2CTO1WW
  BIOS:            R2DET43W (1.28), 2026-06-22
  CPU:             Intel(R) Core(TM) Ultra 9 185H (Meteor Lake)
  NIC:             00:1f.6 Ethernet Connection (18) I219-LM [8086:550a] (rev 20)
  dmesg:           MAC: 16, PHY: 12, PBA No: FFFFFF-0FF
  Kernel:          7.2.3-arch1-3 (Arch Linux)
  e1000e:          version 7.2.3-arch1-3, firmware-version 1.1-4
  Link:            1000 Mbps Full Duplex, Flow Control: Rx/Tx
  Link partner:    consumer GbE switch/router at 192.168.10.1

Reproduction
------------
Plug the cable and ping the default gateway on the LAN. No suspend/resume
involved, machine freshly booted and on AC power. Nothing e1000e-related in
dmesg apart from the link up/down messages; no "Hardware Unit Hang".

Default (K1 enabled):

  $ ping -c 30 192.168.10.1
  --- 192.168.10.1 ping statistics ---
  30 packets transmitted, 18 received, 40% packet loss, time 29734ms
  rtt min/avg/max/mdev = 0.211/0.315/0.384/0.046 ms

The lost packets are spread over the run (seq 6, 8, 9, 11, 13, 14, 16, 19,
20, 24, 25, 30), not a single burst. DHCP on this link also takes 1-2
minutes to get a lease, consistent with incoming packets being dropped.

With K1 disabled at runtime:

  # ethtool --set-priv-flags enp0s31f6 disable-k1 on
  $ ethtool --show-priv-flags enp0s31f6
  Private flags for enp0s31f6:
  s0ix-enabled: on
  disable-k1  : on

  $ ping -c 30 192.168.10.1
  --- 192.168.10.1 ping statistics ---
  30 packets transmitted, 30 received, 0% packet loss, time 29713ms
  rtt min/avg/max/mdev = 0.169/0.251/0.468/0.054 ms

  $ ping -c 30 192.168.10.1
  --- 192.168.10.1 ping statistics ---
  30 packets transmitted, 30 received, 0% packet loss, time 29677ms
  rtt min/avg/max/mdev = 0.101/0.222/0.360/0.064 ms

The result is stable across repeated runs and survives link down/up. I am
currently working around it with a udev rule that sets the flag on device
add.

Suggested change
----------------
Add the machine to disable_k1_list. Lenovo encodes the model in
DMI_PRODUCT_VERSION (product_name is the per-configuration machine type
21G2CTO1WW), so matching on that is more robust:

{
.ident = "Lenovo ThinkPad P14s Gen 5",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad P14s Gen 5"),
},
},

Only the Intel variant (machine types 21G2/21G3) has an I219-LM, so the
match cannot hit the AMD version of the same model.

I am happy to test patches or collect more data (register dumps, ethtool
-S, different link partners) if useful.

#regzbot introduced: 578294b8b60d

Thanks,
Javier Herrera