Re: [PATCH iwl-net] e1000e: Add additional systems to disable K1 list

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

On 13/10/2026 20:33, Mark Pearson wrote:
> 
> 
> On Tue, Oct 13, 2026, at 1:16 AM, Paul Menzel wrote:
>> [Cc: +Mark Pearson for Lenovo to maybe fix firmware to support K1]
>>
>> Dear Dima,
>>
>>
>> Thank you for your patch.
>>
>> Am 12.10.26 um 23:41 schrieb Dima Ruinskiy:
>>> On some Lenovo laptops performance issues were reported with K1 enabled.
>>
>> I’d make one commit per device, so the device can be mentioned in the
>> summary/title, and it can be reverted more easily. It also helps
>> reverting commits in case of problems for just one device. Should you
>> stay with one commit, please at least mention the devices in the commit
>> message.
>>
>> Commit messages should also be self-contained, so describing the
>> performance issue would be great. Having the firmware versions directly
>> in the commit message would also help me.
>>
>>> Add them to the list of systems where K1 is disabled by default.
>>>
>>> Cc: stable@vger.kernel.org
>>> Fixes: 578294b8b60d ("e1000e: Reconfigure PLL clock gate timeout and re-enable K1 on Meteor Lake")
>>> Reported-by: Christoph Groth <christoph@grothesque.org>
>>> Link: https://lore.kernel.org/intel-wired-lan/87v77ial45.fsf@grothesque.org/
>>> Reported-by: ghrafn <ghrafn@proton.me>
>>> Link: https://lore.kernel.org/intel-wired-lan/_kB6DUeC6oOmJnK0FobVVJHADewewO3wzeFw_GrempgMu6s5CUwHpkT16Bwn8tXRq0k_CN4b2NY6API37M6mVciEpH6DKbTqK7f13KMpmgI=@proton.me/
>>> Signed-off-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
>>> ---
>>>    drivers/net/ethernet/intel/e1000e/netdev.c | 14 ++++++++++++++
>>>    1 file changed, 14 insertions(+)
>>>
>>> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
>>> index 834a5b8883df..35c729368684 100644
>>> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
>>> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
>>> @@ -74,6 +74,20 @@ static const struct dmi_system_id disable_k1_list[] = {
>>>    			DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad P14s Gen 5"),
>>>    		},
>>>    	},
>>> +	{
>>> +		.ident = "Lenovo ThinkPad P14s Gen 6",
>>> +		.matches = {
>>> +			DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>>> +			DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad P14s Gen 6"),
>>> +		},
>>> +	},
>>> +	{
>>> +		.ident = "Lenovo ThinkPad T14 Gen 6",
>>> +		.matches = {
>>> +			DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>>> +			DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T14 Gen 6"),
>>> +		},
>>> +	},
>>>    	{}
>>>    };
>>
>> The diff looks good. With my comments addressed, please feel free to add:
>>
>> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
>>
>>
>> Kind regards,
>>
>> Paul
>>
>>
>> PS: As far as I can see, it’s not logged, when K1 is disabled by the
>> quirk list.
> 
> Using the Product version is probably not a good idea as you'll be picking up both ARL and LNL versions of the T14 G6. Do you know if the LNL's are impacted? I'll see if I can reproduce on my system here.
> 
> I would recommend using the BOARD_NAME codes, as is done in thinkpad_acpi: https://github.com/torvalds/linux/blob/24a19b953e2a3d0ea5a8c4951a0ab8f32720c907/drivers/platform/x86/lenovo/thinkpad_acpi.c#L4244-L4245
> It's a bit more annoying as there are two codes per platform - but it's safer in scope (these codes are fixed and won't change):
> T14 G6 ARL: 21QC and 21QH
> P14s G6 ARL: 21QT and 21QU
> T14 G6 LNL: 21QD and 21QG
> 
> I've created internal ticket LO-4707 to get input from the FW team on if we can do a FW fix for this. I'm not sure how this passed our certification and QA with this issue. If you don't mind holding off a week or two while we investigate the patch might not be needed.
> 
> Mark

Hi Mark,
Have you had any feedback from the Lenovo FW team? Basically the two 
questions are - has it been seen on LNL systems, and can it be fixed in FW?

My gut feeling is to make the disable quirk broad rather than narrow. 
Hardware-wise - the issue may definitely impact LNL systems, and since 
previous generations have been affected as well (e.g., P14s Gen 5), it 
feels "safer". The power increase from K1 disabling in nominal operation 
would be less dramatic than users experiencing significant packet loss.

Thoughts?
--Dima