[net-next,v2,00/11] bnxt_en: Implement new driver APIs to send FW messages

Message

Michael Chan Aug. 29, 2021, 7:34 a.m. UTC

The current driver APIs to send messages to the firmware allow only one
outstanding message in flight.  There is only one buffer for the firmware
response for each firmware channel.  To send a firmware message, all
callers must take a mutex and it is released after the firmware response
has been read.  This scheme does not allow multiple firmware messages
in flight.  Firmware may take a long time to respond to some messages
(e.g. NVRAM related ones) and this causes the mutex to be held for
a long time, blocking other callers.

This patchset intoduces the new driver APIs to address the above
shortcomings.  The new APIs are compatible with new and old firmware.
But the new deferred firmware response mechanism will require newer
firmware in order to allow multiple outstanding firmware commands.

All callers are updated to use the new APIs.

v2: Patch 4 and patch 9 updated to fix issues reported by test robot

Edwin Peer (11):
  bnxt_en: remove DMA mapping for KONG response
  bnxt_en: Refactor the HWRM_VER_GET firmware calls
  bnxt_en: move HWRM API implementation into separate file
  bnxt_en: introduce new firmware message API based on DMA pools
  bnxt_en: discard out of sequence HWRM responses
  bnxt_en: add HWRM request assignment API
  bnxt_en: add support for HWRM request slices
  bnxt_en: use link_lock instead of hwrm_cmd_lock to protect link_info
  bnxt_en: update all firmware calls to use the new APIs
  bnxt_en: remove legacy HWRM interface
  bnxt_en: support multiple HWRM commands in flight

 drivers/net/ethernet/broadcom/bnxt/Makefile   |    2 +-
 drivers/net/ethernet/broadcom/bnxt/bnxt.c     | 2133 ++++++++---------
 drivers/net/ethernet/broadcom/bnxt/bnxt.h     |  105 +-
 drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c |  185 +-
 .../net/ethernet/broadcom/bnxt/bnxt_devlink.c |   81 +-
 .../net/ethernet/broadcom/bnxt/bnxt_ethtool.c |  548 +++--
 .../net/ethernet/broadcom/bnxt/bnxt_hwrm.c    |  763 ++++++
 .../net/ethernet/broadcom/bnxt/bnxt_hwrm.h    |  145 ++
 drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c |  130 +-
 .../net/ethernet/broadcom/bnxt/bnxt_sriov.c   |  455 ++--
 drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c  |  264 +-
 drivers/net/ethernet/broadcom/bnxt/bnxt_ulp.c |   31 +-
 drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.c |   62 +-
 13 files changed, 2906 insertions(+), 1998 deletions(-)
 create mode 100644 drivers/net/ethernet/broadcom/bnxt/bnxt_hwrm.c
 create mode 100644 drivers/net/ethernet/broadcom/bnxt/bnxt_hwrm.h

Comments

[e-mail] Aug. 30, 2021, 8:50 a.m. UTC | #1

Hello:

This series was applied to netdev/net-next.git (refs/heads/master):

On Sun, 29 Aug 2021 03:34:55 -0400 you wrote:
> The current driver APIs to send messages to the firmware allow only one
> outstanding message in flight.  There is only one buffer for the firmware
> response for each firmware channel.  To send a firmware message, all
> callers must take a mutex and it is released after the firmware response
> has been read.  This scheme does not allow multiple firmware messages
> in flight.  Firmware may take a long time to respond to some messages
> (e.g. NVRAM related ones) and this causes the mutex to be held for
> a long time, blocking other callers.
> 
> [...]

Here is the summary with links:
  - [net-next,v2,01/11] bnxt_en: remove DMA mapping for KONG response
    https://git.kernel.org/netdev/net-next/c/6c172d59ad79
  - [net-next,v2,02/11] bnxt_en: Refactor the HWRM_VER_GET firmware calls
    https://git.kernel.org/netdev/net-next/c/7b370ad77392
  - [net-next,v2,03/11] bnxt_en: move HWRM API implementation into separate file
    https://git.kernel.org/netdev/net-next/c/3c8c20db769c
  - [net-next,v2,04/11] bnxt_en: introduce new firmware message API based on DMA pools
    https://git.kernel.org/netdev/net-next/c/f9ff578251dc
  - [net-next,v2,05/11] bnxt_en: discard out of sequence HWRM responses
    https://git.kernel.org/netdev/net-next/c/02b9aa106868
  - [net-next,v2,06/11] bnxt_en: add HWRM request assignment API
    https://git.kernel.org/netdev/net-next/c/ecddc29d928d
  - [net-next,v2,07/11] bnxt_en: add support for HWRM request slices
    https://git.kernel.org/netdev/net-next/c/213808170840
  - [net-next,v2,08/11] bnxt_en: use link_lock instead of hwrm_cmd_lock to protect link_info
    https://git.kernel.org/netdev/net-next/c/3c10ed497fa8
  - [net-next,v2,09/11] bnxt_en: update all firmware calls to use the new APIs
    https://git.kernel.org/netdev/net-next/c/bbf33d1d9805
  - [net-next,v2,10/11] bnxt_en: remove legacy HWRM interface
    https://git.kernel.org/netdev/net-next/c/b34695a894b8
  - [net-next,v2,11/11] bnxt_en: support multiple HWRM commands in flight
    https://git.kernel.org/netdev/net-next/c/68f684e257d7

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html