Re: [Intel-wired-lan] [PATCH iwl-net v2 1/1] e1000e: reconfigure PLL clock gate value and re-enable K1 on Meteor Lake

["Ruinskiy, Dima" <dima.ruinskiy@intel.com>]

On 12/02/2026 11:15, Timo Teras wrote:

> Is there other PLL timeout value to test?

Some preliminary calculations we did suggest that raising the value a 
bit further - from 0x1D5 to 0x226 - might be worthwhile. Beyond that you 
may run into other issues.

If you can try it on your machine and report back, that would be great. 
Currently, the only similar system I have is a Pro Max 16 with a U9-285H 
CPU. It is the same SoC generation, but many components are different, 
and I cannot even get the original issue to reproduce there.

> There was also never reply to the question on how likely / large issue
> the potential Rx packet drop is? How many units it may affect?
> 
>  From the earlier discussion we know that the "network does not work
> after cable unplug/plug" issue this causes is affecting multiple different
> vendors and is a *major* problem.

I do not have exact numbers, but it is definitely true that multiple 
system from different vendors have suffered from it.

> If you end up changing K1 default, please add a mechanism to add
> quirks on how to disable it on affected systems without needing user
> space configuration. I find it unacceptable that userspace needs to
> be modified to fix kernel driver behavior on known bad devices.

I have been pondering something like a DMI quirk. These have been 
proposed before for various issues, e.g.:

https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20200319052629.7282-1-kai.heng.feng@canonical.com/

Back then we found a better solution, so this approach was dropped. The 
basic idea can be used as a mechanism for a table of "known bad" 
devices, which the driver can check against to determine the default value.

However, I do not have the capacity to maintain the table itself, or 
even validate every device someone might want to add to it.

At one point there was a proposition to introduce such a table of quirks 
to a Realtek network driver, which was also ultimately rejected from 
upstream (note specifically the comments at the end of the thread):

https://patchew.org/linux/20241208191039.2240-1-guyc.linux.patches@gmail.com/

Thanks!
--Dima