final SCSI pieces for the merge window

This should be the final SCSI updates; it's mainly just a few accessor completion updates and two driver merges (sym2 and qla2xxx) we also secured DaveM's agreement to remove fcal/fc4, which explains the high removal line count.

The patch is available here:

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

The short changelog is:

Adrian Bunk (3):
gdth: __init fixes
aic7xxx_old: fix accidental logic reversal
lpfc: lpfc_debugfs.c: fix typo

Alan Cox (1):
initio: Fix merge fallout

Andrew Morton (1):
qla2xxx: printk fixes

Andrew Vasquez (8):
qla2xxx: Update version number to 8.02.00-k5.
qla2xxx: Correct display of ISP serial-number.
qla2xxx: Correct residual-count handling discrepancies during UNDERRUN han
qla2xxx: Make driver (mostly) legacy I/O port free.
qla2xxx: Fix issue where final flash-segment updates were falling into the
qla2xxx: Handle unaligned sector writes during NVRAM/VPD updates.
qla2xxx: Defer explicit interrupt-polling processing to init-time scenario
qla2xxx: Resync with latest HBA SSID specification -- 2.2u.

Hannes Reinecke (3):
aic7xxx: Fix firmware build
aic7xxx: Update Maintainer information
aic7xxx: Add suspend/resume support

HighPoint Linux Team (1):
hptiop: avoid buffer overflow when returning sense data

James Bottomley (2):
make supported_mode default to initiator.
include linux/scatterlist.h in scsi_eh.h

Johannes Dickgreber (2):
qla1280: eliminate wasted space in request and response ring
qla1280: uses wrong failure path after failed pci_set_dma_mask

Kai Makisara (1):
sym53c8xx: Work around 53c896 erratum

Linas Vepstas (1):
sym53c8xx: PCI Error Recovery support

Matthew Wilcox (16):
sym53c8xx: Remove sym_xpt_async_sent_bdr
sym53c8xx: Remove pci_dev pointer from sym_shcb
sym53c8xx: Make interrupt handler capable of returning IRQ_NONE
sym53c8xx: Get rid of IRQ_FMT and IRQ_PRM
sym53c8xx: Use scmd_printk where appropriate
sym53c8xx: Simplify DAC DMA handling
sym53c8xx: Remove tag_ctrl module parameter
sym53c8xx: Remove io_ws, mmio_ws and ram_ws elements
sym53c8xx: Remove ->device_id
sym53c8xx: Use pdev->revision
sym53c8xx: Stop overriding scsi_done
sym53c8xx: Don't disable interrupts in the interrupt handler
sym53c8xx: Remove unnecessary check in queuecommand
sym53c8xx: Remove data_mapping and data_mapped
sym53c8xx: Use pci_dev irq number
fc4: remove this and all associated drivers

and the diffstat:

 b/Documentation/scsi/sym53c8xx_2.txt              |   21 
 b/MAINTAINERS                                     |    6 
 b/arch/sparc64/Kconfig                            |    2 
 b/drivers/Makefile                                |    1 
 b/drivers/scsi/Makefile                           |    2 
 b/drivers/scsi/aic7xxx/aic7770.c                  |   16 
 b/drivers/scsi/aic7xxx/aic79xx.h                  |   11 
 b/drivers/scsi/aic7xxx/aic79xx_core.c             |    7 
 b/drivers/scsi/aic7xxx/aic79xx_osm.c              |    4 
 b/drivers/scsi/aic7xxx/aic79xx_osm_pci.c          |   50 
 b/drivers/scsi/aic7xxx/aic79xx_pci.c              |   27 
 b/drivers/scsi/aic7xxx/aic7xxx.h                  |   11 
 b/drivers/scsi/aic7xxx/aic7xxx_osm.c              |    4 
 b/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c          |   46 
 b/drivers/scsi/aic7xxx/aic7xxx_pci.c              |   16 
 b/drivers/scsi/aic7xxx/aicasm/aicasm_macro_scan.l |    3 
 b/drivers/scsi/aic7xxx_old.c                      |    2 
 b/drivers/scsi/gdth.c                             |    6 
 b/drivers/scsi/hosts.c                            |    6 
 b/drivers/scsi/hptiop.c                           |    5 
 b/drivers/scsi/initio.c                           |    6 
 b/drivers/scsi/lpfc/lpfc_debugfs.c                |    2 
 b/drivers/scsi/qla1280.c                          |    4 
 b/drivers/scsi/qla1280.h                          |    4 
 b/drivers/scsi/qla2xxx/qla_attr.c                 |    9 
 b/drivers/scsi/qla2xxx/qla_def.h                  |    1 
 b/drivers/scsi/qla2xxx/qla_devtbl.h               |    7 
 b/drivers/scsi/qla2xxx/qla_iocb.c                 |    2 
 b/drivers/scsi/qla2xxx/qla_isr.c                  |    8 
 b/drivers/scsi/qla2xxx/qla_mbx.c                  |    2 
 b/drivers/scsi/qla2xxx/qla_os.c                   |   50 
 b/drivers/scsi/qla2xxx/qla_sup.c                  |   30 
 b/drivers/scsi/qla2xxx/qla_version.h              |    2 
 b/drivers/scsi/scsi_error.c                       |    1 
 b/drivers/scsi/scsi_sysfs.c                       |   10 
 b/drivers/scsi/sym53c8xx_2/sym53c8xx.h            |    1 
 b/drivers/scsi/sym53c8xx_2/sym_fw.c               |   18 
 b/drivers/scsi/sym53c8xx_2/sym_fw.h               |    2 
 b/drivers/scsi/sym53c8xx_2/sym_glue.c             |  581 +++++------
 b/drivers/scsi/sym53c8xx_2/sym_glue.h             |   16 
 b/drivers/scsi/sym53c8xx_2/sym_hipd.c             |  159 +--
 b/drivers/scsi/sym53c8xx_2/sym_hipd.h             |   22 
 b/drivers/scsi/sym53c8xx_2/sym_nvram.c            |    2 
 b/include/scsi/scsi_eh.h                          |    2 
 drivers/fc4/Kconfig                               |   81 -
 drivers/fc4/Makefile                              |    9 
 drivers/fc4/fc-al.h                               |   27 
 drivers/fc4/fc.c                                  | 1146 ----------------------
 drivers/fc4/fc.h                                  |  230 ----
 drivers/fc4/fc_syms.c                             |   30 
 drivers/fc4/fcp.h                                 |   94 -
 drivers/fc4/fcp_impl.h                            |  164 ---
 drivers/fc4/soc.c                                 |  764 --------------
 drivers/fc4/soc.h                                 |  301 -----
 drivers/fc4/socal.c                               |  904 -----------------
 drivers/fc4/socal.h                               |  314 ------
 drivers/scsi/fcal.c                               |  317 ------
 drivers/scsi/fcal.h                               |   27 
 drivers/scsi/pluto.c                              |  349 ------
 drivers/scsi/pluto.h                              |   47 
 60 files changed, 675 insertions(+), 5316 deletions(-)

James

I guess I have the go-ahead to merge the end-CDROM-polling async notification work you've been repeatedly ignoring?

Jeff

I haven't been ignoring it ... it just needs quite a bit of work; the best way to accelerate it seems to be simply to do it (add the supported/trigger event bitmasks and expand the infrastructure). I just haven't had the time within the merge window.

James

James, things cannot get bottlenecked like this. You have had MONTHS to say something like this. The code was ready BEFORE the merge window.

I really think you have the knowledge to be SCSI maintainer, but not the time.

Jeff

From: Jeff Garzik <[email protected]>
Date: Tue, 23 Oct 2007 18:06:51 -0400

Unfortunately, I think this is an important point.

Developers depend strongly upon a subsystem maintainer to "make time" for these things so that work integration does not get delayed past the merge window if at all possible.

Not being able to "make time" to do these things is a great way to lose contributers.

James, whilst there is no doubt in my mind that skill-wise you are probably the most capable scsi maintainer, your "lack of time" is sounding like a broken record and harming the development process.

OK, so it's no secret that I'm the last of the subsystem maintainers whose day job isn't working on the linux kernel. If you want a full time person, who did you have in mind?

James

I'm willing to take on the role of scsi git-monkey. Alternatively, we could split the scsi maintainer role the same way that Dave and Jeff do for net where Dave handles the core and Jeff handles the drivers. Or we can negotiate some other arrangement.

Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

That would be great. Maybe my aic7xxx debloating patches which were submitted four times already (IIRC) will be looked at at last.
--
vda

For the record, lots of subsystem maintainers are privateers.

<goes through the git trees>

I am not aware that these guys:

Mauro Chehab, Dmitry Torokhov, Sam Ravnborg, Pierre Ossman, Mark Hoffman, Thomas Gleixner, David Airlie, Richard Purdie, Peter Anvin, Kyle McMartin, Francois Romieu, Artem Bityutskiy, Erez Zadok, Josef Sipek, Anton Altaparmakov, Eric Van Hensbergen, Latchesar Ionkov, Wim Van Sebroeck, Antonino Daplas.

do it with any compensation.

Quite frankly, at least for me personally, what I would rather have (in
general: this is really not at all SCSI-specific in any way, shape, or form, and not directed at James!) is a less rigid maintainership structure.

Let's face it, we are *all* likely to be overworked at different times, and even when not overworked, it's just the fact that people need to take a breather etc. And there is seldom - if ever - a very strong argument for having one person per subsystem.

I think git is excellent for trying to spreading the "joy" of maintainership, but even without something like that, I think it's much better to try to find people you can trust, rather than strict maintainership boundaries. For example, Andrew certainly seems to be very productive as a kernel maintainer, and it has nothing to do with git, and everything to do with trust.

So I'd rather have less recriminations about "xyz is holding up abc", and have people more open to just trying to help out even across strict borders. And I don't mean that in a "two fighting people" kind of way where there are two or more people who maintain things _despite_ each other, but more in a

"Hey we know each other, and we trust each other, and no, we won't
guarantee that we always agree, but we can work on things, and if it turns out that one person merged somethign that the other person _really_ doesn't like, we'll revert it and/or work it out some other way".

I've personally always been against _strict_ maintainer lines, so I've always taken stuff "past" the maintainer anyway (and sometimes maintainers have complained, because they feel like they "own" their subsystem, and I either tell them to stuff it, or say "my bad", depending on whether they had a valid _technical_ complaint or not).

So rather than getting into a pissing match of "ok, who would be the best maintainer", I'd much *much* prefer to take this as another "we really don't need or even _want_ to have strict maintainer rules" opportunity.

Now, the most important part here is the trust part. I need to be able to trust maintainers, but when you have multiple people in the same "box", those people need to trust each other even more than usual, because you *are* going to get disagreements. And the only way it can work is if you acknowledge that disagreements will happen, and that any situation is not a "my way or the highway" kind of thing - the trust also implies a certain give and take.

And this really *is* an issue that cuts across subsystem boundaries. Anybody who thinks that SCSI is "unique" in this kind of issues is sadly mistaken. We've had the exact same thing come up in every single subsystem over time, and at every single level of maintainership (from individual drivers all the way right up to me) over time.

So I *really* don't want to throw any stones in a glass house here. Quite the reverse. I'd like to get rid of some of the glass, and replace it with padding. Because you all know we'd all fit better in a padded room than a glass house..

Are there any such people that think there s a sufficient mutual trust with James that you think a blurring of maintainership lines could work out? Or in any other subsystem, for that matter? Hmm?

Linus

Am OK with all of that, but with a rider. It would make my life even more miserable if there was a (say) git-scsi-tweedledee and a git-scsi-tweedledum. We already have too much out-of-scope code turning up in the git trees and having two trees explicitly modifying the same subsystem would hurt. It's also bad from an engineering POV: there's a decent chance that when combined, they just won't work.

So Tweedledee and Tweedledum should both commit to the same tree, please.

Jeff,
If only I had a dollar (Canadian unit please) for each day some of my libata patches were queued up to you before you accepted them.

Remember MODE SELECT ...

On a more serious note, it looks like the job of the SCSI maintainer is getting larger and more onerous. Perhaps some folks should check if James has been provided with the appropriate resources.

Doug Gilbert

You're darned right, I've screwed up in the past. Sat on stuff "until I get time to rewrite it" and that sort of thing. My colleagues give me lumps for it too :)

We talked about this issue at the Kernel Summit -- collectively we need to stop holding on to useful, working stuff for months on end. It serves nobody.

We have to rediscover our roots: "release early, release often"

Jeff

The patch in question is an interface to user space. The problem with those is that you can't put them in and refine them because the user visible interface changes when you do that.

The pot is calling the kettle black here, since libata was supposed to have moved out of SCSI about three years ago by helping us move the shared elements up to block. As far as I can tell, the only progress we've made in this area is me adding the odd API shift.

James

Post August, this user space interface patch has received (a) silence or (b) this vague general worry about changing user space interfaces. All the while it is working and was revised according to comment at the time.

At some point you gotta stop waiting for perfection or that mythical "when I get a round tuit" and actually DO something.

When I see the new patch to end CD-ROM polling grow moldy for two months while rewrites to ancient SCSI drivers go in, I throw up my hands in wonderment. Poor Andrew is constantly resending -mm patches to you -- some stick, some vanish into the ether without comment. For months.

You're talking about long term directions, I'm talking about actually getting day-to-day work accomplished.

Jeff