Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <d32ac7da-f460-6d7a-5f7f-9c9d873bf393@intel.com>
Date:   Mon, 31 Jan 2022 12:51:07 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 Thunderbird/91.5.0
Subject: Re: [PATCH net] net: e1000e: Recover at least in-memory copy of NVM
 checksum
Content-Language: en-US
To:     Thomas Bogendoerfer <tbogendoerfer@suse.de>,
        Jesse Brandeburg <jesse.brandeburg@intel.com>,
        Tony Nguyen <anthony.l.nguyen@intel.com>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        <intel-wired-lan@lists.osuosl.org>, <netdev@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>,
        "Fuxbrumer, Devora" <devora.fuxbrumer@intel.com>,
        "Ruinskiy, Dima" <dima.ruinskiy@intel.com>,
        "Neftin, Sasha" <sasha.neftin@intel.com>
References: <20220127150807.26448-1-tbogendoerfer@suse.de>
From:   "Neftin, Sasha" <sasha.neftin@intel.com>
In-Reply-To: <20220127150807.26448-1-tbogendoerfer@suse.de>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VEFnMk9UODFLRVZxNmdsWnVBdFJTdEhycEhwZEErQTg3OEdNTUpoUS9WbXo2?=
 =?utf-8?B?Q01TS0k0NDl3eUtNTEo4dFVGaktCOU9qLzcwRk9JcStsajlrVUMzcG9CcnNS?=
 =?utf-8?B?bGZMYm1PY2NDQkpBKzB0TVJQM3VOM0F6NnFRbnpsWlk3QXZpRlFqTmJRR2t0?=
 =?utf-8?B?dkFFb1FsOVM1SUJSTUtaREJNY1VHZXo2dnYrQktFMnQrZy8yZEs3RjlvNkpX?=
 =?utf-8?B?QkdsYXh1dExBVHd6QURscGMxZDNyVWVEOHpoUy9qSEliMkhDWStNaElIb3hu?=
 =?utf-8?B?UGVRNUNjQXlJZm5Ub1RYalV0VjVxTzlhWUh0ZHlnODNBTTFYNXE1bndjWVhh?=
 =?utf-8?B?OGpSZS83NDhKa0h5NVRYTEgrZDBtbkd3dHl5T1d6TUZvcnpwdW1TYjRhbTJQ?=
 =?utf-8?B?U3dWOFBkQUpOSXo0Q2dRUlRrNGl3SGMvWnNJS005SkpnamVtNFdqMFhwODRm?=
 =?utf-8?B?QnVmMFNEUUNEMmtqQ3hxcGhWSHBZdE1RTW5jVjYyZ2haWllVV1lxd0o0TVBL?=
 =?utf-8?B?MUtFdUFxSjQ4RHhaM0k5dy9NcjgyK0xsQWYwVWlBZWZHblFxeWo2VXplWEQw?=
 =?utf-8?B?TVZpQUVjelFMY0FkYWFWdGlBWGJnUHdITDBxQ2R3eXd4c3ZFcExOZzAyS3kw?=
 =?utf-8?B?cDN0M0ovQk5KUDQxbjRDY3Q2TStYd0lzdXg0ZzdYNHE1U1JISVQzQUNrQUdl?=
 =?utf-8?B?bjF4OThFS0JPOVVJc2JVa2NwTXdXMXhHaW1nNVBCU1ViTlVDNjBLb013ZktL?=
 =?utf-8?B?blZ6UmlXZTg1cjkzRzgwZEhEaXJvYXdabzQ4RU1GcnBiZGpWaU1aRlFLVE1r?=
 =?utf-8?B?ckFISXFidys0b3ZqT3daUWszT1hqUjFRaHRGTG5EZ2pWUEdDRElQNkE2SEw0?=
 =?utf-8?B?NzMzc0FLSHVRcHVVa1Z0b1VIVExJVmtkU1kvbVlMUkFMbFA3dGVsdExPTW12?=
 =?utf-8?B?TkVLVk1HbkhMK2NGOWEvdjFJZkI1NkVFa0NhZU5sWFBtVDZJMkxjS0FOcUtv?=
 =?utf-8?B?K1FKVXQveTFlaVgxRDVzY3lremJTNE9VenBDaGhkRGxibVFmMW9MdUdyb054?=
 =?utf-8?B?Y21nTUgxbm9hU0VzeHpqcm1qVUhqY0N5aFB4Mm0wd1pPU3lRMXpUeHhkUi9D?=
 =?utf-8?B?VEt4VW15R0xBRzcrVUQrcTYwUUlyK1hJTUlhSHVWSmhqSW81eEVRdnhJdmlt?=
 =?utf-8?B?ZldOaW9wZ21rMFFKTDFsYjM3aFB3b0w0aEVvM2FreG1Meld1Qk1LR1VJSHdj?=
 =?utf-8?B?ajdNbjROSGdKQ0JoenliWjNXck1KNEFNbWlkTjRTSUphQU1pYXNyYUxwWHdB?=
 =?utf-8?B?c1c2WHlCN2dlajdnWmYvMnpML2RtMlNZUWhsTjJtVkEwS1Ftd3o2T1FzaEJz?=
 =?utf-8?B?NWdYdkt2bFREQzVxaEh4RUVCZEdsV2hlWjMrdGdrTloxbzBZSkRlTkd4WEg1?=
 =?utf-8?B?aXMrM2JnUGFCNTZHS2gxcGYxdGdocUZQczA2LytMZnpoNHNKeU5vQitFcDli?=
 =?utf-8?B?c011V0hhbXFyc2ErRVJXQmJEVjBQOVlGVDVqNTkzTmhXYy9kUlh2QWgrQ09w?=
 =?utf-8?B?eVBsb1pIWWFVWGNnMFN1b09yY3hDeExpVjRIb0tXZGdIdXBlb3UvdTJjNjlm?=
 =?utf-8?B?OG5vWmc3WXJFMjZ2WkVGYVhwTjB5R010UU43V2pSN2FIbHVjNHNObDdVRmg5?=
 =?utf-8?B?UXdGMDA2VElMTk1JaU15SVQvbFpXSERJbFFkRTZtTHE3SEVnZUwrTHcydk9Y?=
 =?utf-8?B?MUx5Zi93Z2x0MFFxY20vVlRwV1RaYlVsN3V6NTNsb0pGRld1VDRxQU5OR0FJ?=
 =?utf-8?B?cStSN0RENXkxRGpPNkFzZWlmRWFRZHV0b3lCMURodUJ1QjF5VlFjN1poM0E5?=
 =?utf-8?B?SnQ0S1J6MlAvc3hUZkpNTkVPdVE4cFVxOVBOSXFpZTlsYXc4R0tITFRiTFJy?=
 =?utf-8?B?dC9vUzFjekJxK2ZGYThrYlVNWXo5TVJIZmhGQ2l4TWVnZFgwQTVNcjllYnZu?=
 =?utf-8?B?SGdvVjdEYXpYdHRJenJ1OC9GZ2FUSllibkxLMEVCU3FSY1R1V1BKdUg4VGFE?=
 =?utf-8?B?R0RVUmNGR25nYzBaN2NVL2dSeUkyY25Ebzd1SmZlQ3dHcm03UmVZUUhyOC9P?=
 =?utf-8?B?T2Rkbkc1L0hmdS9McXRzS0JtaE9WSWx6aE16ZjBvT2xvcHlxSTErMU5zcm1E?=
 =?utf-8?Q?CXV1l+BJN3cmQU5wOwxKWpc=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: f70da9c0-dde7-437a-3369-08d9e4a79b0d
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4787.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2022 10:51:16.5234
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: k+Aju8c0NJkTAF7rsVyfKJKZ5iNMJajfYHnCu6SNZ4aShfa4hoZMMo2B/4w/n/93ZhahKyQBHyrQ7KWkBJ+l/A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4393
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 1/27/2022 17:08, Thomas Bogendoerfer wrote:
> Commit 4051f68318ca ("e1000e: Do not take care about recovery NVM
> checksum") causes a regression for systems with a broken NVM checksum
> and hardware which is not able to update the NVM. Before the change the
> in-memory copy was correct even the NVM update doesn't work, which is
> good enough for the driver to work again.
> 
> See
> 
> https://bugzilla.opensuse.org/show_bug.cgi?id=1191663
> 
> for more details.
> 
> This patch reverts the change and moves the check for hardware without
> NVM update capability right before the real flash update.
> 
> Fixes: 4051f68318ca ("e1000e: Do not take care about recovery NVM checksum")
> Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
> ---
>   drivers/net/ethernet/intel/e1000e/ich8lan.c | 21 ++++++++++-----------
>   1 file changed, 10 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
> index 5e4fc9b4e2ad..613a60f24ba6 100644
> --- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
> +++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
> @@ -3808,6 +3808,9 @@ static s32 e1000_update_nvm_checksum_spt(struct e1000_hw *hw)
>   	if (nvm->type != e1000_nvm_flash_sw)
>   		goto out;
>   
> +	if (hw->mac.type >= e1000_pch_cnp)
> +		goto out;
> +
>   	nvm->ops.acquire(hw);
>   
>   	/* We're writing to the opposite bank so if we're on bank 1,
> @@ -4136,17 +4139,13 @@ static s32 e1000_validate_nvm_checksum_ich8lan(struct e1000_hw *hw)
>   		return ret_val;
>   
>   	if (!(data & valid_csum_mask)) {
> -		e_dbg("NVM Checksum Invalid\n");
> -
> -		if (hw->mac.type < e1000_pch_cnp) {
I meant: change hw->mac.type < e1000_pch_cnp to hw->mac.type < e1000_pch_tgp
> -			data |= valid_csum_mask;
> -			ret_val = e1000_write_nvm(hw, word, 1, &data);
> -			if (ret_val)
> -				return ret_val;
> -			ret_val = e1000e_update_nvm_checksum(hw);
> -			if (ret_val)
> -				return ret_val;
> -		}
Hello Thomas,
For security reasons starting from the TGL platform SPI controller will 
be locked for SW access. I've double-checked with our HW architect, not 
from SPT, from TGP. So, first, we can change the mac type e1000_pch_cnp 
to e1000_pch_tgp (as fix for initial patch)
Do we want (second) to allow HW initialization with the "wrong" NVM 
checksum? It could cause unexpected (HW) behavior in the future. Even if 
you will "recover" check in shadow RAM - there is no guarantee that NVM 
is good.
> +		data |= valid_csum_mask;
> +		ret_val = e1000_write_nvm(hw, word, 1, &data);
> +		if (ret_val)
> +			return ret_val;
> +		ret_val = e1000e_update_nvm_checksum(hw);
> +		if (ret_val)
> +			return ret_val;
>   	}
>   
>   	return e1000e_validate_nvm_checksum_generic(hw);
Thanks,
Sasha