OK, I know this is a bit late, but no-one told me the merge window was
going to close early, but even if they had I'd have been unable to do
anything about it, since I've been in transit from India all this week
so far (don't ask ...).
The only commit added on Monday is a bug fix (vport sync issue), so I
plead this tree was ready to roll on Sunday. The tree contains five
driver updates (lpfc, bfa, ipr, hpsa and be2iscsi) plus an assortment of
bug fixes.
The tree is available here:
master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
The short changelog is:
Boaz Harrosh (1):
libosd: Fix unchecked err return found by smatch
Brian King (2):
ibmvfc: Add suspend/resume support
ibmvscsi: Add suspend/resume support
Gal Rosen (1):
scsi_transport_fc: Fix synchronization issue while deleting vport
Hannes Reinecke (1):
scsi_dh_emc: fix mode select request setup
James Bottomley (1):
raid_attrs: fix dependency problems
James Smart (7):
lpfc 8.3.10: Update Driver version to 8.3.10
lpfc 8.3.10: Added round robin FCF failover
lpfc 8.3.10: Fix Discovery issues
lpfc 8.3.10: Added management for LP21000 through BSG.
lpfc 8.3.10: Update SLI interface areas
lpfc 8.3.10: Fix user interface issues
lpfc 8.3.10: Fix Initialization issues
Jayamohan Kallickal (7):
be2iscsi: Alloc only one EQ if intr mode
be2iscsi: Fixing memory allocation for connection
be2iscsi: Remove debug code
be2iscsi: cleans up abort handling
be2iscsi: Fix for a possible udelay while holding lock
be2iscsi: Cleanup of resets for device and target
libiscsi: Make iscsi_eh_target_reset start with session reset
Krishna Gudipati (30):
bfa: Update the driver version to 2.1.2.1.
bfa: Remove unused header files and did some cleanup.
bfa: Handle SCSI IO underrun case.
bfa: FCS and include file changes.
bfa: Modified the portstats get/clear ...From: Randy Dunlap <randy.dunlap@oracle.com>
scsi_scan.c: fix incorrectly formatted kernel-doc notation
& convert documentation of 2 functions into kernel-doc.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/scsi/scsi_scan.c | 26 +++++++++-----------------
1 file changed, 9 insertions(+), 17 deletions(-)
--- linux-2.6.33-rc8-git6.orig/drivers/scsi/scsi_scan.c
+++ linux-2.6.33-rc8-git6/drivers/scsi/scsi_scan.c
@@ -1220,7 +1220,7 @@ static void scsi_sequential_lun_scan(str
}
/**
- * scsilun_to_int: convert a scsi_lun to an int
+ * scsilun_to_int - convert a scsi_lun to an int
* @scsilun: struct scsi_lun to be converted.
*
* Description:
@@ -1252,7 +1252,7 @@ int scsilun_to_int(struct scsi_lun *scsi
EXPORT_SYMBOL(scsilun_to_int);
/**
- * int_to_scsilun: reverts an int into a scsi_lun
+ * int_to_scsilun - reverts an int into a scsi_lun
* @lun: integer to be reverted
* @scsilun: struct scsi_lun to be set.
*
@@ -1874,12 +1874,9 @@ void scsi_forget_host(struct Scsi_Host *
spin_unlock_irqrestore(shost->host_lock, flags);
}
-/*
- * Function: scsi_get_host_dev()
- *
- * Purpose: Create a scsi_device that points to the host adapter itself.
- *
- * Arguments: SHpnt - Host that needs a scsi_device
+/**
+ * scsi_get_host_dev - Create a scsi_device that points to the host adapter itself
+ * @shost: Host that needs a scsi_device
*
* Lock status: None assumed.
*
@@ -1892,7 +1889,7 @@ void scsi_forget_host(struct Scsi_Host *
*
* Note - this device is not accessible from any high-level
* drivers (including generics), which is probably not
- * optimal. We can add hooks later to attach
+ * optimal. We can add hooks later to attach.
*/
struct scsi_device *scsi_get_host_dev(struct Scsi_Host *shost)
{
@@ -1919,18 +1916,13 @@ struct scsi_device *scsi_get_host_dev(st
}
EXPORT_SYMBOL(scsi_get_host_dev);
-/*
- * Function: scsi_free_host_dev()
- *
- * Purpose: Free a scsi_device ...From: Randy Dunlap <randy.dunlap@oracle.com> Change torque.net references for SCSI drivers & tools to their current locations (sg.danny.cz/sg). Remove whitespace at ends of lines. Same could be done for parport references at torque.net except that those files don't seem to have a home now. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Douglas Gilbert <dgilbert@interlog.com> --- .mailmap | 2 Documentation/DocBook/scsi.tmpl | 2 Documentation/scsi/scsi-generic.txt | 30 ++--- Documentation/scsi/scsi.txt | 22 +-- Documentation/scsi/scsi_mid_low_api.txt | 130 +++++++++++----------- MAINTAINERS | 2 drivers/scsi/Kconfig | 4 drivers/scsi/scsi_debug.c | 2 include/scsi/sg.h | 19 +-- 9 files changed, 107 insertions(+), 106 deletions(-) --- linux-2.6.33-rc4-git2.orig/.mailmap +++ linux-2.6.33-rc4-git2/.mailmap @@ -34,7 +34,7 @@ David Brownell <david-b@pacbell.net> David Woodhouse <dwmw2@shinybook.infradead.org> Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Domen Puncer <domen@coderock.org> -Douglas Gilbert <dougg@torque.net> +Douglas Gilbert <dgilbert@interlog.com> Ed L. Cashin <ecashin@coraid.com> Evgeniy Polyakov <johnpol@2ka.mipt.ru> Felipe W Damasio <felipewd@terra.com.br> --- linux-2.6.33-rc4-git2.orig/MAINTAINERS +++ linux-2.6.33-rc4-git2/MAINTAINERS @@ -4705,7 +4705,7 @@ F: drivers/scsi/sr* SCSI SG DRIVER M: Doug Gilbert <dgilbert@interlog.com> L: linux-scsi@vger.kernel.org -W: http://www.torque.net/sg +W: http://sg.danny.cz/sg/index.html S: Maintained F: drivers/scsi/sg.c F: include/scsi/sg.h --- linux-2.6.33-rc4-git2.orig/include/scsi/sg.h +++ linux-2.6.33-rc4-git2/include/scsi/sg.h @@ -16,7 +16,7 @@ Version 2 and 3 extensions to driver: Version: 3.5.34 (20060920) This version is for 2.6 series kernels. - For a full changelog see ...
I'm not going to pull. The whole "a few days early" was literally aimed at you and some similar people who _always_ send the pull request late, literally the last days. I'm fed up with it. The damn thing should have been ready when the merge window _opened_, not just before closing. And now there _is_ a tree waiting for me for the next merge window. Goodie. Linus --
I do always have a tree ready in the first days of the merge window. It
was, in fact, here:
commit 654451748b779b28077d9058442d0f354251870d
Merge: 64d497f 77c9cfc
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri Feb 26 16:55:27 2010 -0800
Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6
The slight problem is that I accumulate updates (like almost everyone
else) from the few days before the merge window opened up until about
the middle of the second week. That's what goes into the final pull,
plus assorted bug fixes that showed up during the window.
I'm not objecting to a shorter merge window, just the unpredictability
of all of this. The reason I delay the second pull until the last days
of the merge window is so that the proposed changes get the maximum
amount of shake down in linux-next ... and that usually means I close
down the inclusion window about three days before the pull request goes
out.
Personally, I do like the two week merge window, because it shakes out
contributors to me who should have got their act together but didn't.
If you don't like the way this works, fine ... I just need to know what
the parameters are to adjust accordingly, so what is it now? A 10 day
merge window?
James
--
If you read the 2.6.33 release notes, the unpredictability WAS THE WHOLE F*CKING POINT! I'm tired of people being able to predict exactly when the merge window closes, and then using that to make the last days of the merge window be hell on me, and sending all the merges within about 24 hours of the closing. So I'm not doing it. If you had the major changes ready when the merge window opened, you should damn well have sent it in _then_. End of story. I've told people before. The merge window is for _merging_, not for doing development. If you send me something the last day, then there is no "window" any more. And It is _really_ annoying to have fifty pull requests on the last day. I'm not going to take it any more. And the thing is, all your explanations make things WORSE. You're basically saying that you're working exactly the way that I'm not going to accept. So you're now going to get to wait six or seven weeks, because I refuse to work the way you have worked me for the last two years. I gave people a heads-up, and I probably shouldn't have. Some people noticed. And other people didn't even care, because they never gamed the system in the first place. And some people - like you - both gamed the system, and didn't read the release notes, and now you complain. Tough. And the fact that you complain about the very fact that you were gaming the system and now you can't because it's not predictable enough to game is what just proves my f*cking point! Linus --
Btw, just to clarify for next time: I'm not even going to mention in the release notes how long the merge window is going to be. Maybe I'll say "that's enough" after just one week, because the good people did what they do, and sent me a lot of merges early, there were no problems, and I might as well cut an -rc1 early since I have enough and I'd like to occasionally get a _shorter_ release cycle not just because the merge window was shorter, but because hopefully merging less might result in an easier stabilization cycle too. Or maybe I'll be busy for a few days, and extend it past the two weeks just because I was in the middle of another flame war and needed a few extra days to catch up with real work. Who knows? The point being that being predictable has caused problems. People have decided that they have an extra two weeks, and that the merge window isn't a window at all, it's just a day when -rc1 gets done. Linus --
You appear to being using git as a sort of baroque CVS. Fixes that arrive after the beginning of the merge window should be put into a separate branch other than the one ready for submission. Features that arrive after the beginning of the merge window should be placed into yet another branch destined for the next merge window. --
Ray, I'm sure that James will appreciate your insightful advice. And Alan Cox is probably waiting for your thoughts on the design of serial device drivers. Amazing that after yet another Linus rant, people crawl out of the woodwork to attack the victim. Doug Gilbert --
