[PATCH 0/19] lpfc 10.4.8000.0: Update lpfc version to driver version 10.4.8000.0

[PATCH 0/19] lpfc 10.4.8000.0: Update lpfc version to driver version 10.4.8000.0

[James Smart]

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


Signed-off-by: James Smart <james.smart@emulex.com>
Signed-off-by: Dick Kennedy <dick.kennedy@emulex.com>

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(-)

-- 
1.7.11.7

Re: [PATCH 0/19] lpfc 10.4.8000.0: Update lpfc version to driver version 10.4.8000.0

[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
 - 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.

Re: [PATCH 0/19] lpfc 10.4.8000.0: Update lpfc version to driver version 10.4.8000.0

[James Smart]

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

although - I do have a couple of questions.


On 9/5/2014 1:35 AM, Christoph Hellwig wrote:
> 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


>   - 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.


>   - 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.


>
> 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

Re: [PATCH 0/19] lpfc 10.4.8000.0: Update lpfc version to driver version 10.4.8000.0

[James Bottomley]

On Fri, 2014-09-05 at 09:31 -0400, James Smart wrote:
> On 9/5/2014 1:35 AM, Christoph Hellwig wrote:
> >   - 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