netdev - Re: [Intel-wired-lan] [PATCH iwl-next] ice: Implement ethtool reset support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240731164716.63f3b5b7@kernel.org>
Date: Wed, 31 Jul 2024 16:47:16 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jacob Keller <jacob.e.keller@...el.com>, Wojciech Drewek
 <wojciech.drewek@...el.com>
Cc: <netdev@...r.kernel.org>, <edumazet@...gle.com>,
 <anthony.l.nguyen@...el.com>, <simon.horman@...igine.com>,
 <intel-wired-lan@...ts.osuosl.org>, <pabeni@...hat.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next] ice: Implement ethtool reset
 support

On Wed, 31 Jul 2024 14:08:20 +0200 Wojciech Drewek wrote:
> Quick summary our reset types:
> PF reset reinitialize the resources/data path for PF and its VFs.
> It has no impact on other PF/VFs.
> Core Reset reinitialize all functions and shared parts of the
> device except PHY/MAC units, EMP and PCI Interface.
> Global Reset is Core Reset + PHY/MAC units reset (including External PHY)
> Because Global Reset is a extended Core it makes sense to map it to all.
> PF reset mapping makes sense to me since it is dedicated to a single physical function.

On Wed, 31 Jul 2024 09:48:07 -0700 Jacob Keller wrote:
> PF reset only affects the single PCI function, and does not affect the
> whole adapter. I don't know how it relates to PCIe resets precisely.
> 
> CORE reset affects the whole adapter, and the other functions are
> notified of the impending reset via their miscellaneous interrupt vector
> in combination with some hardware registers.
> 
> GLOBAL reset is similar to the CORE reset, (in that it affects the
> entire device), but it is more invasive in the hardware. I cannot
> remember offhand the differences between CORE and GLOBAL.
> 
> There is also an EMP reset, which is the only reset that completely
> reloads the EMP firmware. It is currently used by the device flash
> update logic, via devlink reload and is only available if the new
> firmware image can be reloaded without issue. (Reloading when the new
> firmware could impact PCIe config space is likely to produce undesirable
> behavior because the PCIe config space is not reloaded except by power
> cycling, so you end up with some weird mismatches.)

Note that the reset is controlled using individual bits which can be
combined:

	ETH_RESET_MGMT		= 1 << 0,	/* Management processor */
	ETH_RESET_IRQ		= 1 << 1,	/* Interrupt requester */
	ETH_RESET_DMA		= 1 << 2,	/* DMA engine */
	ETH_RESET_FILTER	= 1 << 3,	/* Filtering/flow direction */
	ETH_RESET_OFFLOAD	= 1 << 4,	/* Protocol offload */
	ETH_RESET_MAC		= 1 << 5,	/* Media access controller */
	ETH_RESET_PHY		= 1 << 6,	/* Transceiver/PHY */
	ETH_RESET_RAM		= 1 << 7,	/* RAM shared between
						 * multiple components */
	ETH_RESET_AP		= 1 << 8,	/* Application processor */

	ETH_RESET_DEDICATED	= 0x0000ffff,	/* All components dedicated to
						 * this interface */
	ETH_RESET_ALL		= 0xffffffff,	/* All components used by this
						 * interface, even if shared */

Note that ethtool CLI defines "shared" version of all bits as bits
shifted up by 16. And it is forward compatible (accepts raw "flags")
if we need to define new bits.

I guess in your case EMP == MGMT? So if these resets don't reset EMP
I presume we shouldn't use any option that includes MGMT..

Could you express your resets in the correct combination of these bits
instead of picking a single one?