From: Ben Hutchings Date: Mon, 2 Jul 2012 22:37:40 +0000 (+0100) Subject: sfc: Explain why efx_mcdi_exit_assertion() ignores result of efx_mcdi_rpc() X-Git-Url: https://git.stricted.de/?a=commitdiff_plain;h=0f1e54ae52b950ed79074ae794d027d6c97fd34e;p=GitHub%2FLineageOS%2Fandroid_kernel_motorola_exynos9610.git sfc: Explain why efx_mcdi_exit_assertion() ignores result of efx_mcdi_rpc() Fix CID 113952 in Coverity report on Linux. This is the one instance where we don't, and shouldn't, check the return code from efx_mcdi_rpc(). It wasn't immediately obvious to me why we didn't, so I think an explanation is in order. Signed-off-by: Ben Hutchings --- diff --git a/drivers/net/ethernet/sfc/mcdi.c b/drivers/net/ethernet/sfc/mcdi.c index 17b6463e459c..fc5e7bbcbc9e 100644 --- a/drivers/net/ethernet/sfc/mcdi.c +++ b/drivers/net/ethernet/sfc/mcdi.c @@ -1001,12 +1001,17 @@ static void efx_mcdi_exit_assertion(struct efx_nic *efx) { u8 inbuf[MC_CMD_REBOOT_IN_LEN]; - /* Atomically reboot the mcfw out of the assertion handler */ + /* If the MC is running debug firmware, it might now be + * waiting for a debugger to attach, but we just want it to + * reboot. We set a flag that makes the command a no-op if it + * has already done so. We don't know what return code to + * expect (0 or -EIO), so ignore it. + */ BUILD_BUG_ON(MC_CMD_REBOOT_OUT_LEN != 0); MCDI_SET_DWORD(inbuf, REBOOT_IN_FLAGS, MC_CMD_REBOOT_FLAGS_AFTER_ASSERTION); - efx_mcdi_rpc(efx, MC_CMD_REBOOT, inbuf, MC_CMD_REBOOT_IN_LEN, - NULL, 0, NULL); + (void) efx_mcdi_rpc(efx, MC_CMD_REBOOT, inbuf, MC_CMD_REBOOT_IN_LEN, + NULL, 0, NULL); } int efx_mcdi_handle_assertion(struct efx_nic *efx)