Skip to contentSkip to conversation

lpfc 10.4.8000.0: Update lpfc version to driver version 10.4.8000.0

PATCH Applied James Smart 3 participants 4 messages Sep 3, 2014 – Sep 5, 2014 SCSI

lore
Share & tools
lore
#0 lore raw

cover lpfc 10.4.8000.0: Update lpfc version to driver version 10.4.8000.0

Update lpfc version to driver version 10.4.8000.0

This patch set updates the lpfc driver to revision 10.4.8000.0

The patches for 10.4.8000.0 contain:
- Incorporate patches posted to linux-scsi
- Mark functions as static in lpfc/lpfc_sli.c
- Mark functions as static in lpfc/lpfc_hbadisc.c
- Mark functions as static in lpfc/lpfc_init.c
- Mark functions as static in lpfc/lpfc_scsi.c
- Mark function as static in lpfc/lpfc_bsg.c
- Use time_after()
- Use dma_zalloc_coherent
- random32: do not feed jiffies as seed from lpfc driver
- Use pci_enable_msix_range() instead of pci_enable_msix()
- Fix discovery timeout during nameserver login
- Fix quarantined XRI recovery qualifier state in link bounce
- Fix IP Reset processing - wait for RDY before proceeding
- Fix race between LOGO/PLOGI handling causing NULL pointer
- Fix locking issues with abort data paths
- Fixed crash from page fault caused by use after rport delete
- Fixed High priority issues from lpfc given by fortify source code scan.
- Fixed Low priority issues from lpfc given by fortify source code scan.
- Fix for handling unmapped ndlp in target reset handler
- Update lpfc version to driver version 10.4.8000.0

The patches were cut against Christoph's scsi-queue.git, branch "drivers-for-3.18".

-- james s

James Smart (19):

 drivers/scsi/lpfc/lpfc_attr.c      |   2 +-
 drivers/scsi/lpfc/lpfc_bsg.c       |  20 ++-
 drivers/scsi/lpfc/lpfc_crtn.h      |   1 -
 drivers/scsi/lpfc/lpfc_ct.c        |  14 ++-
 drivers/scsi/lpfc/lpfc_debugfs.c   |   4 +-
 drivers/scsi/lpfc/lpfc_disc.h      |   6 +-
 drivers/scsi/lpfc/lpfc_els.c       |  33 +++--
 drivers/scsi/lpfc/lpfc_hbadisc.c   |  53 +++++---
 drivers/scsi/lpfc/lpfc_init.c      | 225 ++++++++++++++++-----------------
 drivers/scsi/lpfc/lpfc_mbox.c      |   6 +-
 drivers/scsi/lpfc/lpfc_nportdisc.c |   2 +
 drivers/scsi/lpfc/lpfc_scsi.c      |  34 +++--
 drivers/scsi/lpfc/lpfc_sli.c       | 247 ++++++++++++++++++-------------------
 drivers/scsi/lpfc/lpfc_sli.h       |   1 +
 drivers/scsi/lpfc/lpfc_sli4.h      |  20 +--
 drivers/scsi/lpfc/lpfc_version.h   |   2 +-
 16 files changed, 351 insertions(+), 319 deletions(-)
Signature · 1 line
1.7.11.7
#1 lore raw

I've applied the series, but for next time can you make sure to follow the proper format:

- remove the version number in every subject line
- patches you resend from an original author should be unchanged, except that the From: lines moves into the mail body
- patches that you send on with your maintainer hat on should be signed off by you, not just reviewed.

not strictly required, but making my life a lot easier would be if all patches are sent by reply to the original mail. git-send-email does this, and it seems like the Emulex division supporting be2scsi has found a way to use it with the corporate email servers.

#2 lore raw

no problem, although if these rules were published, I would have tried to do so earlier.

although - I do have a couple of questions.

Quoted 4 lines · Christoph Hellwig

I've applied the series, but for next time can you make sure to follow the proper format:

- remove the version number in every subject line

yeah - it's long

Quoted 2 lines

- patches you resend from an original author should be unchanged, except that the From: lines moves into the mail body

So.. you do not want me to resolve merge conflicts or fuzz before posting ?

note: content did not change - only merged into my git tree and re-cut them.

Quoted 2 lines

- patches that you send on with your maintainer hat on should be signed off by you, not just reviewed.

ok - but I guess I had a different interpretation of the meaning for signed-by. I thought it conveyed an ownership and originality of authorship of the content posted. As such, if I didn't contribute anything in the patch, I shouldn't give anything other than a reviewed-by indicating approval.

Quoted 5 lines

not strictly required, but making my life a lot easier would be if all patches are sent by reply to the original mail. git-send-email does this, and it seems like the Emulex division supporting be2scsi has found a way to use it with the corporate email servers.

yep - although different countries have different logistics. But, I should be able to get around this.

-- james

maintainer
#3 lore raw
Quoted 9 lines · James Smart
Quoted 2 lines · Christoph Hellwig

- patches that you send on with your maintainer hat on should be signed off by you, not just reviewed.

ok - but I guess I had a different interpretation of the meaning for signed-by. I thought it conveyed an ownership and originality of authorship of the content posted. As such, if I didn't contribute anything in the patch, I shouldn't give anything other than a reviewed-by indicating approval.

No, this is a DCO thing;the Signed-off-by: tag is the certification under the DCO:

http://developercertificate.org/

It follows the chain of transmission, whether you alter the patch or not, so it needs your Signed-off-by for any patch you send on behalf of another (whether or not you alter it). By convention, you also append your alterations to the change log in square brackets, but you don't have to bother if it's trivial.

James