ice(4): Do not leave device non-functional if Tx scheduler config fails

[pawel.sobczyk_intel.com]

Summary

The ice_cfg_tx_topo function attempts to apply Tx scheduler topology
configuration based on NVM parameters, selecting either a 5 or 9 layer
topology. As part of this flow, the driver acquires the "Global Configuration Lock",
which is a hardware resource associated with programming the DDP package
to the device. This "lock" is implemented by firmware as a way to
guarantee that only one PF can program the DDP for a device. Unlike a
traditional lock, once a PF has acquired this lock, no other PF will be
able to acquire it again (including that PF) until a CORER of the device.
However, if configuration of the Tx topology fails, (i.e.
ice_get_set_tx_topo returns an error code), the driver exits
ice_cfg_tx_topo() immediately, and fails to trigger CORER.
While the global configuration lock is held, the firmware rejects most
AdminQ commands, as it is waiting for the DDP package download (or Tx
scheduler topology programming) to occur.
Refactor ice_cfg_tx_topo() to always trigger a CORER after acquiring the
global lock, regardless of success or failure of the topology
configuration.
We need to re-initialize the HW structure when we trigger the CORER.
Previously, this was the responsibility of the core driver to cleanup after
the CORER. Instead, make it the responsibility of this function. This
avoids needless re-initialization for the cases where no reset occurred.

Authored-by: Jacob Keller <[e-mail]>
Co-Authored-by: Pawel Sobczyk <[e-mail]>
Signed-off-by: Sobczyk, Pawel <[e-mail]>