[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c0213cae-5e63-4fd7-81e7-37803806bde4@intel.com>
Date: Wed, 31 Jul 2024 09:48:07 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Jakub Kicinski <kuba@...nel.org>, 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 7/30/2024 6:58 AM, Jakub Kicinski wrote:
> On Tue, 30 Jul 2024 12:51:21 +0200 Wojciech Drewek wrote:
>> ETH_RESET_MAC - ICE_RESET_CORER
>
> Core doesn't really sound like MAC, what is it?
> And does PF reset reset mostly PCIe side or more?
> My knee jerk mapping would be to map Core to dedicated
> and PF to DMA.
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.)
Powered by blists - more mailing lists