mbox series

[v2,00/26] qedf: Misc fixes for the driver.

Message ID 20190326073858.26792-1-skashyap@marvell.com (mailing list archive)
Headers show
Series qedf: Misc fixes for the driver. | expand

Message

Saurav Kashyap March 26, 2019, 7:38 a.m. UTC
Hi Martin,

This series has misc bug fixes and code enchancements in flush routine,
abort and TMF path.

Kindly apply this series to scsi-queue at your earliest convenience.

Changes from v1 -> v2
- Fix sparse warning for patch #4

Thanks,
~Saurav
 

Andrew Vasquez (1):
  qedf: Correct the memory barriers in qedf_ring_doorbell.

Chad Dupuis (10):
  qedf: Do not retry ELS request if qedf_alloc_cmd fails.
  qedf: Correct xid range overlap between offloaded requests and libfc
    requests.
  qedf: Add missing return in qedf_post_io_req() in the fcport offload
    check.
  qedf: Simplify s/g list mapping.
  qedf: Use a separate completion for cleanup commands.
  qedf: Add missing fc_disc_init call after allocating lport.
  qedf: Add additional checks for io_req->sc_cmd validity.
  qedf: Wait for upload and link down processing during soft ctx reset.
  qedf: Add missing return in qedf_scsi_done().
  qedf: Check both the FCF and fabric ID before servicing clear virtual
    link.

Hannes Reinecke (4):
  qedf: missing kref_put in qedf_xmit()
  qedf: fixup locking in qedf_restart_rport()
  qedf: fixup bit operations.
  qedf: fc_rport_priv reference counting fixes

Saurav Kashyap (7):
  qedf: Modify abort and tmf handler to handle edge condition and flush.
  qedf: Check for link state before processing LL2 packets and send
    fipvlan retries.
  qedf: Don't send ABTS for under run scenario.
  qedf: Check for tm_flags instead of cmd_type during cleanup.
  qedf: Correctly handle refcounting of rdata.
  qedf: Fix lport may be used uninitialezed warning.
  qedf: Update the driver version to 8.37.25.19.

Shyam Sundar (4):
  qedf: Modify flush routine to handle all I/Os and TMF.
  qedf: Don't queue anything if upload is in progress.
  qedf: Add a flag to help debugging io_req which could not be cleaned.
  qedf: Cleanup rrq_work after QEDF_CMD_OUTSTANDING is cleared.

 drivers/scsi/qedf/qedf.h         |  51 ++-
 drivers/scsi/qedf/qedf_debugfs.c |   2 -
 drivers/scsi/qedf/qedf_els.c     |  72 +++-
 drivers/scsi/qedf/qedf_fip.c     |  76 ++--
 drivers/scsi/qedf/qedf_io.c      | 736 ++++++++++++++++++++++++++++++---------
 drivers/scsi/qedf/qedf_main.c    | 249 +++++++++----
 drivers/scsi/qedf/qedf_version.h |   8 +-
 7 files changed, 903 insertions(+), 291 deletions(-)

Comments

Martin K. Petersen March 28, 2019, 2:13 a.m. UTC | #1
Saurav,

> This series has misc bug fixes and code enchancements in flush
> routine, abort and TMF path.

Applied to 5.2/scsi-queue, thanks.

Next time please try to submit your work in smaller batches.

It is inconceivable that somebody would volunteer to review a series of
25+ patches. It is hard enough to find reviewers for a single patch!

You have a 4-6 week submission window for each kernel release. I would
much prefer to see 2-3 smaller series scattered throughout those
weeks. With the bigger, more intrusive changes coming in at the
beginning of the window, of course.
Saurav Kashyap April 2, 2019, 4:04 a.m. UTC | #2
Hi Martin,
We will take care from next time, thanks for the support.

Thanks,
~Saurav

-----Original Message-----
From: "Martin K. Petersen" <martin.petersen@oracle.com>
Organization: Oracle Corporation
Date: Thursday, 28 March 2019 at 7:43 AM
To: Saurav Kashyap <skashyap@marvell.com>
Cc: "martin.petersen@oracle.com" <martin.petersen@oracle.com>, "QLogic-Storage-Upstream@cavium.com" <QLogic-Storage-Upstream@cavium.com>, "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: [EXT] Re: [PATCH v2 00/26] qedf: Misc fixes for the driver.

    External Email
    
    ----------------------------------------------------------------------
    
    Saurav,
    
    > This series has misc bug fixes and code enchancements in flush
    > routine, abort and TMF path.
    
    Applied to 5.2/scsi-queue, thanks.
    
    Next time please try to submit your work in smaller batches.
    
    It is inconceivable that somebody would volunteer to review a series of
    25+ patches. It is hard enough to find reviewers for a single patch!
    
    You have a 4-6 week submission window for each kernel release. I would
    much prefer to see 2-3 smaller series scattered throughout those
    weeks. With the bigger, more intrusive changes coming in at the
    beginning of the window, of course.
    
    -- 
    Martin K. Petersen	Oracle Linux Engineering