Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set

["Lifshits, Vitaly" <vitaly.lifshits@intel.com>]

On 4/24/2025 7:24 PM, Simon Horman wrote:
> On Tue, Apr 22, 2025 at 09:43:01AM +0200, Jacek Kowalski wrote:
>> Some Dell Tiger Lake systems have incorrect NVM checksum. These also
>> have a bitmask that indicates correct checksum set to "invalid".
>>
>> Because it is impossible to determine whether the NVM write would finish
>> correctly or hang (see https://bugzilla.kernel.org/show_bug.cgi?id=213667)
>> it makes sense to skip the validation completely under these conditions.
It is not completely accurate. All the NVMs starting from Tiger Lake are 
locked for writes, so NVM writes will always result in a failure.

Perhaps something like this:
"
All the NVMs starting from Tiger Lake are locked for writes, so NVM 
writes will always result in a failure. Since tgp devices were the first 
to have this lock, some manufacturers didn't create a correct image 
resulting in this wrong checksum issue. Therefore, it makes these 
devices as a transition period, skip updating the checksum if the bit 
wasn't set.
"
>>
>> Signed-off-by: Jacek Kowalski <Jacek@jacekk.info>
>> Fixes: 4051f68318ca9 ("e1000e: Do not take care about recovery NVM checksum")
> I think that while the commit cited above relates to this problem,
> this bug actually dates back to the patch I'm citing immediately below.
> And I think we should cite that commit here. IOW, I'm suggesting:
>
> Fixes: fb776f5d57ee ("e1000e: Add support for Tiger Lake")
>
>> Cc: stable@vger.kernel.org
> That not withstanding, based on the commit message,
> and the use of e1000_pch_tgp in another Tiger Lake fix [1],
> I think this patch looks good.
>
> Reviewed-by: Simon Horman <horms@kernel.org>
>
> [1] commit ffd24fa2fcc7 ("e1000e: Correct NVM checksum verification flow")
>