bnxt_en: fix ethtool_reset_flags ABI violations
authorEdwin Peer <edwin.peer@broadcom.com>
Mon, 4 May 2020 08:50:33 +0000 (04:50 -0400)
committerDavid S. Miller <davem@davemloft.net>
Mon, 4 May 2020 17:44:10 +0000 (10:44 -0700)
commit7a13240e371891d90cd51e3ea55ea04f4b2065dc
tree992ee7e57c9e413b269fc697a9b095ed1579f169
parent94f17e89c956553606d5c7cf4f40ce6012529d48
bnxt_en: fix ethtool_reset_flags ABI violations

The ethtool ABI specifies that the reset operation should only clear
the flags that were actually reset. Setting the flags to zero after
a chip reset violates this because it does not include resetting the
application processor complex. Similarly, components that are not yet
defined are also not necessarily being reset.

The fact that chip reset does not cover the AP also means that it is
inappropriate to treat these two components exclusively of one another.
The ABI provides a mechanism to report a failure to reset independent
components via the returned bitmask, so it is also wrong to fail hard
if one of a set of independent resets is not possible.

It is incorrect to rely on the passed by reference flags in bnxt_reset(),
which are being updated as components are reset. The initially requested
value should be used instead so that hard errors do not propagate if any
earlier components could have been reset successfully.

Note, AP and chip resets are global in nature. Dedicated resets are
thus not currently supported.

Signed-off-by: Edwin Peer <edwin.peer@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.h