This represents the usual assortment of driver updates (bnx2i, zfcp,
qla, lpfc, ipr ..) plus several libfc and fcoe updates and a partial bfa
cleanup.

The patch is available here:

master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git

The short changelog is:

Brian King (2):
      ibmvfc: Handle Virtual I/O Server reboot
      ibmvfc: Log link up/down events

Christof Schmitt (12):
      zfcp: Remove scsi_cmnd->serial_number from debug traces
      zfcp: Remove duplicated code from zfcp_ccw_set_online
      zfcp: Move ACL/CFDC code to zfcp_cfdc.c
      zfcp: Reorder FCP I/O and task management handler functions
      zfcp: Change spin_lock_bh to spin_lock_irq to fix lockdep warning
      zfcp: Allow midlayer to scan for LUNs when running in NPIV mode
      zfcp: Use SCSI device data zfcp_scsi_dev instead of zfcp_unit
      zfcp: Allow running unit/LUN shutdown without acquiring reference
      zfcp: Remove ZFCP_SYSFS_FAILED macro and implement fcp_lun_show without macro
      zfcp: Move code for managing zfcp_unit devices to new file
      zfcp: Add zfcp private struct as SCSI device driver data
      zfcp: Reorder registration of initial SCSI device

Dan Carpenter (2):
      pm8001: handle allocation failures
      lpfc: change spin_lock_irq() to spin_lock()

Darrick J. Wong (1):
      libsas: Don't issue commands to devices that have been hot-removed

David Milburn (1):
      libsas: fix NCQ mixing with non-NCQ

Eddie Wai (5):
      bnx2i: Updated version to bnx2i-2.1.3
      bnx2i: Added chip cleanup for the remove module path
      bnx2i: Recouple the CFC delete cleanup with cm_abort/close completion
      bxn2i: Added support for other TMFs besides ABORT_TASK
      bnx2i: Fixed a protocol violation on nopout responses

Giridhar Malavali (6):
      qla2xxx: Increase SG table size to support large IO size per scsi command.
      qla2xxx: Clear local references of rport on device loss timeout notification from FC transport.
      qla2xxx: ...
[ message continues ]

On Fri, Oct 22, 2010 at 9:27 AM, James Bottomley

Why do you say "bfa cleanup"?

There's a _single_ commit that looks like this:

 220 files changed, 34823 insertions(+), 43478 deletions(-)

and which apparently rewrites the whole f*cking driver, with no
explanations, no nothing. Why should anything like this be considered
acceptable?

I'm going to pull it this once, because let's face it, nobody sane
cares about that idiotic driver to begin with (and it does remove a
lot more lines than it adds). But really, if I see something like that
again, I will just tell you to go away and not send me crap like this
again.

If it's that kind of crap, it should go into staging, or it shouldn't
have been merged into the kernel in the first place.

Seriously. You need to start showing better taste. I realize that most
of SCSI is crazy specialty hardware that is used by just a few people,
but if you don't start pushing back on those vendors and make them do
proper changes in small pieces and with actual commentary, then _I_ am
going to push back at you. Hard. By simply not pulling crap.

This is not the first time I've been disgusted with the SCSI tree. And
quite frankly, drivers like BFA are so totally irrelevant to anything,
that I will have absolutely no problems with just saying "screw it, if
they can't behave, they get removed from the kernel".

And don't blame it on bad vendors that won't do a good job. If they
don't do a good job, then STOP TAKING THEIR CRAP. Make them understand
that they need to work with the process, not do some kind of random
"change everything, with no actual explanations". Blame me if you
can't grow the balls to stand up to them. Tell them that I simply
won't take it unless they clean up their act.

Because I really won't.

                        Linus
--

[ message continues ]

> There's a _single_ commit that looks like this:
 > 
 >  220 files changed, 34823 insertions(+), 43478 deletions(-)

Hey, you're not using git properly... if I use '-M' to show moved
files, I see:

 212 files changed, 30007 insertions(+), 38662 deletions(-)

which is a lot nicer.

 - R.
--

[ message continues ]

It really doesn't make any difference what-so-ever. Lookie here:

  wc $(git ls-files drivers/scsi/bfa/)
  ...
  42946  114109 1118020 total

IOW, that driver only has 42k lines to begin with (well, it does now,
it used to have a few more). Whether there were a couple of files that
were similar enough after the fact to count as renames or not is
totally immaterial. The driver was basically rewritten or re-indented
or whatever, AND THE CHANGELOG DOESN'T EVEN _BEGIN_ TO EXPLAIN IT!

It's a two-line changelog, which isn't even accurate!

Two lines of explanation! For 70 _thousand_ lines of changes? The fact
that Bottomley signed off on that kind of crap, and then sent it on to
me with a oneline "cleanup" commentary should say something. And what
it says to me is "Never again". If I get stuff like this again, I stop
pulling. Those SCSI drivers might as well be outside the kernel tree,
there's no point having them in the tree if they are just code-drops.
It really isn't as if they have enough users to merit being there
anyway.

Because that kind of shit is simply not acceptable in the kernel. We
don't just do random undocumented code-drops. And dammit, James should
have known better.

                        Linus
--

[ message continues ]

> >  > There's a _single_ commit that looks like this:
 > >  >
 > >  >  220 files changed, 34823 insertions(+), 43478 deletions(-)
 > >
 > > Hey, you're not using git properly... if I use '-M' to show moved
 > > files, I see:
 > >
 > >  212 files changed, 30007 insertions(+), 38662 deletions(-)
 > >
 > > which is a lot nicer.
 > 
 > It really doesn't make any difference what-so-ever. Lookie here:

Sorry to set you off ... I was being a bit sarcastic, and playing off
your tendency to show off git's ability to track moves.  Being serious,
obviously even after the -M, the commit is ludicrously impossible to
review.

Too dryly,
  Roland
--

[ message continues ]

OK, so message received and understood.   The warning has already been
conveyed to the bfa maintainers (over a month ago). All of us appreciate
the one time grace.  I think this driver will finally start moving in
the right direction.

James


--

[ message continues ]