mbox series

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

Message ID 1630187910-22252-1-git-send-email-michael.chan@broadcom.com (mailing list archive)
Headers show
Series bnxt_en: Implement new driver APIs to send FW messages | expand

Message

Michael Chan Aug. 28, 2021, 9:58 p.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.  All callers are then updated to use the new APIs.

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     | 2129 ++++++++---------
 drivers/net/ethernet/broadcom/bnxt/bnxt.h     |  101 +-
 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   |  457 ++--
 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, 2901 insertions(+), 1997 deletions(-)
 create mode 100644 drivers/net/ethernet/broadcom/bnxt/bnxt_hwrm.c
 create mode 100644 drivers/net/ethernet/broadcom/bnxt/bnxt_hwrm.h

Comments

Andrew Lunn Aug. 28, 2021, 10:07 p.m. UTC | #1 
On Sat, Aug 28, 2021 at 05:58:19PM -0400, Michael Chan 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.
> 
> This patchset intoduces the new driver APIs to address the above
> shortcomings.  All callers are then updated to use the new APIs.

Hi Michael

Does the firmware already support this? Or is a firmware upgrade also
required.

	Andrew
Michael Chan Aug. 28, 2021, 10:58 p.m. UTC | #2 
On Sat, Aug 28, 2021 at 3:07 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Sat, Aug 28, 2021 at 05:58:19PM -0400, Michael Chan 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.
> >
> > This patchset intoduces the new driver APIs to address the above
> > shortcomings.  All callers are then updated to use the new APIs.
>
> Hi Michael
>
> Does the firmware already support this? Or is a firmware upgrade also
> required.
>

These changes are compatible with new and old firmware.  With newer
firmware, the code introduced in patch 11 will take advantage of the
deferred firmware responses for commands that take longer to complete.
The APIs will then allow another command to be sent to the firmware.

Thanks.