kernel/drivers/net/ethernet/pensando/ionic/ionic_dev.c, branch linux-6.2.y

ionic: missed doorbell workaround

2023-02-04T03:58:53Z

In one version of the HW there is a remote possibility that it will miss the doorbell ring. This adds a bit of protection to be sure we don't stall a queue from a missed doorbell. Fixes: 0f3154e6bcb3 ("ionic: Add Tx and Rx handling") Signed-off-by: Allen Hubbe Signed-off-by: Shannon Nelson Signed-off-by: Jakub Kicinski

ionic: new ionic device identity level and VF start control

2022-10-28T03:34:13Z

A new ionic dev_cmd is added to the interface in ionic_if.h, with a new capabilities field in the ionic device identity to signal its availability in the FW. The identity level code is incremented to '2' to show support for this new capabilities bitfield. If the driver has indicated with the new identity level that it has the VF_CTRL command, newer FW will wait for the start command before starting the VFs after a FW update or crash recovery. This patch updates the driver to make use of the new VF start control in fw_up path to be sure that the PF has set the user attributes on the VF before the FW allows the VFs to restart. Signed-off-by: Shannon Nelson Signed-off-by: Jakub Kicinski

ionic: no transition while stopping

2022-02-28T11:42:45Z

Make sure we don't try to transition the fw_status_ready while we're still in the FW_STOPPING state, else we can get stuck in limbo waiting on a transition that already happened. While we're here we can remove a superfluous check on the lif pointer. Signed-off-by: Shannon Nelson Signed-off-by: David S. Miller

ionic: catch transition back to RUNNING with fw_generation 0

2022-02-19T04:37:14Z

In some graceful updates that get initially triggered by the RESET event, especially with older firmware, the fw_generation bits don't change but the fw_status is seen to go to 0 then back to 1. However, the driver didn't perform the restart, remained waiting for fw_generation to change, and got left in limbo. This is because the clearing of idev->fw_status_ready to 0 didn't happen correctly as it was buried in the transition trigger: since the transition down was triggered not here but in the RESET event handler, the clear to 0 didn't happen, so the transition back to 1 wasn't detected. Fix this particular case by bringing the setting of idev->fw_status_ready back out to where it was before. Fixes: 398d1e37f960 ("ionic: add FW_STOPPING state") Signed-off-by: Shannon Nelson Signed-off-by: Jakub Kicinski

ionic: replace set_vf data with union

2022-01-25T11:15:09Z

This (ab)use of a data buffer made some static code checkers rather itchy, so we replace the a generic data buffer with the union in the struct ionic_vf_setattr_cmd. Fixes: fbb39807e9ae ("ionic: support sr-iov operations") Signed-off-by: Shannon Nelson Signed-off-by: David S. Miller

ionic: stretch heartbeat detection

2022-01-25T11:15:09Z

The driver can be premature in detecting stalled firmware when the heartbeat is not updated because the firmware can occasionally take a long time (more than 2 seconds) to service a request, and doesn't update the heartbeat during that time. The firmware heartbeat is not necessarily a steady 1 second periodic beat, but better described as something that should progress at least once in every DECVMD_TIMEOUT period. The single-threaded design in the FW means that if a devcmd or adminq request launches a large internal job, it is stuck waiting for that job to finish before it can get back to updating the heartbeat. Since all requests are "guaranteed" to finish within the DEVCMD_TIMEOUT period, the driver needs to less aggressive in checking the heartbeat progress. We change our current 2 second window to something bigger than DEVCMD_TIMEOUT which should take care of most of the issue. We stop checking for the heartbeat while waiting for a request, as long as we're still watching for the FW status. Lastly, we make sure our FW status is up to date before running a devcmd request. Once we do this, we need to not check the heartbeat on DEV commands because it may be stalled while we're on the fw_down path. Instead, we can rely on the is_fw_running check. Fixes: b2b9a8d7ed13 ("ionic: avoid races in ionic_heartbeat_check") Signed-off-by: Brett Creeley Signed-off-by: Shannon Nelson Signed-off-by: David S. Miller

ionic: Query FW when getting VF info via ndo_get_vf_config

2022-01-25T11:15:09Z

Currently when an administrator configures a VF via ndo_set_vf*, the driver will send the set command to FW and then update the cached value. The cached value is then used when reporting VF info via ndo_get_vf_config. A problem is that the VF info may have been updated between the last ndo_set_vf* and ndo_get_vf_info commands via some other method, i.e. a VF changes its MAC address (assuming it's allowed to do so) and since this is all managed by the FW, this new value won't be reflected in the PF's cache of values. To fix this, update the driver to always get the latest VF information by making use of the IONIC_CMD_VF_GETATTR dev command. The FW may not support getting all the attributes for IONIC_CMD_VF_GETATTR, so the driver will only update the cached VF config members if their associated IONIC_CMD_VF_GETATTR was successful. Otherwise the cached VF config members will remain the same as what was set in ndo_set_vf*. Fixes: fbb39807e9ae ("ionic: support sr-iov operations") Signed-off-by: Brett Creeley Signed-off-by: Shannon Nelson Signed-off-by: David S. Miller

ionic: better handling of RESET event

2022-01-25T11:15:08Z

When IONIC_EVENT_RESET is received, we only need to start the fw_down process if we aren't already down, and we need to be sure to set the FW_STOPPING state on the way. If this is how we noticed that FW was stopped, it is most likely from a FW update, and we'll see a new FW generation. The update happens quickly enough that we might not see fw_status==0, so we need to be sure things get restarted when we see the fw_generation change. Fixes: d2662072c094 ("ionic: monitor fw status generation") Signed-off-by: Shannon Nelson Signed-off-by: David S. Miller

ionic: add FW_STOPPING state

2022-01-25T11:15:08Z

Between fw running and fw actually stopped into reset, we need a fw_stopping concept to catch and block some actions while we're transitioning to FW_RESET state. This will help to be sure the fw_up task is not scheduled until after the fw_down task has completed. On some rare occasion timing, it is possible for the fw_up task to try to run before the fw_down task, then not get run after the fw_down task has run, leaving the device in a down state. This is possible if the watchdog goes off in between finding the down transition and starting the fw_down task, where the later watchdog sees the FW is back up and schedules a fw_up task. Fixes: c672412f6172 ("ionic: remove lifs on fw reset") Signed-off-by: Shannon Nelson Signed-off-by: David S. Miller

ionic: Don't send reset commands if FW isn't running

2022-01-25T11:15:08Z

It's possible the FW is already shutting down while the driver is being removed and/or when the driver is going through reset. This can cause unexpected/unnecessary errors to be printed: eth0: DEV_CMD IONIC_CMD_PORT_RESET (12) error, IONIC_RC_ERROR (29) failed eth1: DEV_CMD IONIC_CMD_RESET (3) error, IONIC_RC_ERROR (29) failed Fix this by checking the FW status register before issuing the reset commands. Also, since err may not be assigned in ionic_port_reset(), assign it a default value of 0, and remove an unnecessary log message. Fixes: fbfb8031533c ("ionic: Add hardware init and device commands") Signed-off-by: Brett Creeley Signed-off-by: Shannon Nelson Signed-off-by: David S. Miller