1. 30 Aug, 2021 5 commits
    • Edwin Peer's avatar
      bnxt_en: discard out of sequence HWRM responses · 02b9aa10
      Edwin Peer authored
      During firmware crash recovery, it is possible for firmware to respond
      to stale HWRM commands that have already timed out. Because response
      buffers may be reused, any out of sequence responses need to be ignored
      and only the matching seq_id should be accepted.
      
      Also, READ_ONCE should be used for the reads from the DMA buffer to
      ensure that the necessary loads are scheduled.
      Reviewed-by: default avatarScott Branden <scott.branden@broadcom.com>
      Signed-off-by: default avatarEdwin Peer <edwin.peer@broadcom.com>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      02b9aa10
    • Edwin Peer's avatar
      bnxt_en: introduce new firmware message API based on DMA pools · f9ff5782
      Edwin Peer authored
      This change constitutes a major step towards supporting multiple
      firmware commands in flight by maintaining a separate response buffer
      for the duration of each request. These firmware commands are also
      known as Hardware Resource Manager (HWRM) commands.  Using separate
      response buffers requires an API change in order for callers to be
      able to free the buffer when done.
      
      It is impossible to keep the existing APIs unchanged.  The existing
      usage for a simple HWRM message request such as the following:
      
              struct input req = {0};
              bnxt_hwrm_cmd_hdr_init(bp, &req, REQ_TYPE, -1, -1);
              rc = hwrm_send_message(bp, &req, sizeof(req), HWRM_CMD_TIMEOUT);
              if (rc)
                      /* error */
      
      changes to:
      
               struct input *req;
               rc = hwrm_req_init(bp, req, REQ_TYPE);
               if (rc)
                       /* error */
               rc = hwrm_req_send(bp, req); /* consumes req */
               if (rc)
                       /* error */
      
      The key changes are:
      
      1. The req is no longer allocated on the stack.
      2. The caller must call hwrm_req_init() to allocate a req buffer and
         check for a valid buffer.
      3. The req buffer is automatically released when hwrm_req_send() returns.
      4. If the caller wants to check the firmware response, the caller must
         call hwrm_req_hold() to take ownership of the response buffer and
         release it afterwards using hwrm_req_drop().  The caller is no longer
         required to explicitly hold the hwrm_cmd_lock mutex to read the
         response.
      5. Because the firmware commands and responses all have different sizes,
         some safeguards are added to the code.
      
      This patch maintains legacy API compatibiltiy, implementing the old
      API in terms of the new.  The follow-on patches will convert all
      callers to use the new APIs.
      
      v2: Fix redefined writeq with parisc .config
          Fix "cast from pointer to integer of different size" warning in
      hwrm_calc_sentinel()
      Signed-off-by: default avatarEdwin Peer <edwin.peer@broadcom.com>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f9ff5782
    • Edwin Peer's avatar
      bnxt_en: move HWRM API implementation into separate file · 3c8c20db
      Edwin Peer authored
      Move all firmware messaging functions and definitions to new
      bnxt_hwrm.[ch].  The follow-on patches will make major modifications
      to these APIs.
      Signed-off-by: default avatarEdwin Peer <edwin.peer@broadcom.com>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3c8c20db
    • Edwin Peer's avatar
      bnxt_en: Refactor the HWRM_VER_GET firmware calls · 7b370ad7
      Edwin Peer authored
      Refactor the code so that __bnxt_hwrm_ver_get() does not call
      bnxt_hwrm_do_send_msg() directly.  The new APIs will not expose this
      internal call.  Add a new bnxt_hwrm_poll() to poll the HWRM_VER_GET
      firmware call silently.  The other bnxt_hwrm_ver_get() function will
      send the HWRM_VER_GET message directly with error logs enabled.
      Signed-off-by: default avatarEdwin Peer <edwin.peer@broadcom.com>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7b370ad7
    • Edwin Peer's avatar
      bnxt_en: remove DMA mapping for KONG response · 6c172d59
      Edwin Peer authored
      The additional response buffer serves no useful purpose. There can
      be only one firmware command in flight due to the hwrm_cmd_lock mutex,
      which is taken for the entire duration of any command completion,
      KONG or otherwise. It is thus safe to share a single DMA buffer.
      
      Removing the code associated with the additional mapping will simplify
      matters in the next patch, which allocates response buffers from DMA
      pools on a per request basis.
      Signed-off-by: default avatarEdwin Peer <edwin.peer@broadcom.com>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6c172d59
  2. 29 Aug, 2021 30 commits
  3. 28 Aug, 2021 5 commits