* [GIT PULL] final scsi updates for 2.6.34-rc1
@ 2010-03-10 17:36 James Bottomley
2010-03-10 20:00 ` [PATCH 1/2 resend] scsi: fix/convert scsi_scan.c kernel-doc Randy Dunlap
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: James Bottomley @ 2010-03-10 17:36 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: linux-scsi, linux-kernel
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 logic
bfa: Replace bfa_get_attr() with specific APIs
bfa: New portlog entries for events (FIP/FLOGI/FDISC/LOGO).
bfa: Rename pport to fcport in BFA FCS.
bfa: IOC fixes, check for IOC down condition.
bfa: In MSIX mode, ignore spurious RME interrupts when FCoE ports are in FW mismatch state.
bfa: Fix Command Queue (CPE) full condition check and ack CPE interrupt.
bfa: IOC recovery fix in fcmode.
bfa: AEN and byte alignment fixes.
bfa: Introduce a link notification state machine.
bfa: Added firmware save clear feature for BFA driver.
bfa: FCS authentication related changes.
bfa: PCI VPD, FIP and include file changes.
bfa: Fix to copy fpma MAC when requested by user space application.
bfa: RPORT state machine: direct attach mode fix.
bfa: Replace bfa_assert() with bfa_sm_fault()
bfa: Clear LL_HALT and PSS_ERR bit when IOC crashes.
bfa: IOC changes: Support faster recovery and split bfa_ioc.c into ASIC specific code.
bfa: Resume BFA operations after firmware mismatch is resolved.
bfa: Fix to allow creation of only 190 vports on CNA.
bfa: New interface to handle firmware upgrade scenario
bfa: Changes to support FDMI Driver Parameter
bfa: Enable new halt interrupt in BFA.
bfa: Enable IOC auto-recovery and IOC type fix.
bfa: Defined a new LPS event to clear virtual link on a vport
bfa: Added separate MSI-X module parameters.
Martin K. Petersen (1):
sd: Fix VPD buffer allocations
Mike Miller (1):
hpsa: remove scan thread
Stephen M. Cameron (8):
hpsa: remove unused members next, prev, and retry_count from command list structure.
hpsa: Increase the number of scatter gather elements supported.
hpsa: Clarify calculation of padding for commandlist structure
hpsa: mark hpsa_pci_init as __devinit
hpsa: return -ENOMEM, not -1
hpsa: fix scsi status mis-shift
hpsa: fix firmwart typo
hpsa: allow modifying device queue depth.
Wayne Boyer (9):
ipr: adds PCI ID definitions for new adapters
ipr: add support for new IOASCs
ipr: add support for multiple stages of initialization
ipr: implement shutdown changes and remove obsolete write cache parameter
ipr: add hardware assisted smart dump functionality
ipr: add error handling updates for the next generation chip
ipr: update the configuration table code for the next generation chip
ipr: define new offsets to registers for the next generation chip
ipr: add support for new adapter command structures for the next generation chip
The diffstat is:
drivers/infiniband/ulp/iser/iscsi_iser.c | 2
drivers/scsi/Kconfig | 6
drivers/scsi/be2iscsi/be_cmds.c | 7
drivers/scsi/be2iscsi/be_iscsi.c | 4
drivers/scsi/be2iscsi/be_main.c | 201 +-
drivers/scsi/be2iscsi/be_main.h | 11
drivers/scsi/be2iscsi/be_mgmt.c | 14
drivers/scsi/be2iscsi/be_mgmt.h | 8
drivers/scsi/bfa/Makefile | 8
drivers/scsi/bfa/bfa_core.c | 19
drivers/scsi/bfa/bfa_fcport.c | 1709 +++++++++++---------
drivers/scsi/bfa/bfa_fcs.c | 63
drivers/scsi/bfa/bfa_fcs_lport.c | 75
drivers/scsi/bfa/bfa_fcs_port.c | 11
drivers/scsi/bfa/bfa_fcs_uf.c | 8
drivers/scsi/bfa/bfa_hw_cb.c | 13
drivers/scsi/bfa/bfa_hw_ct.c | 9
drivers/scsi/bfa/bfa_intr.c | 111 -
drivers/scsi/bfa/bfa_ioc.c | 762 ++-------
drivers/scsi/bfa/bfa_ioc.h | 57
drivers/scsi/bfa/bfa_ioc_cb.c | 274 +++
drivers/scsi/bfa/bfa_ioc_ct.c | 423 +++++
drivers/scsi/bfa/bfa_iocfc.c | 24
drivers/scsi/bfa/bfa_iocfc.h | 3
drivers/scsi/bfa/bfa_ioim.c | 22
drivers/scsi/bfa/bfa_itnim.c | 30
drivers/scsi/bfa/bfa_lps.c | 134 +
drivers/scsi/bfa/bfa_module.c | 4
drivers/scsi/bfa/bfa_modules_priv.h | 2
drivers/scsi/bfa/bfa_port_priv.h | 57
drivers/scsi/bfa/bfa_priv.h | 2
drivers/scsi/bfa/bfa_rport.c | 26
drivers/scsi/bfa/bfa_trcmod_priv.h | 62
drivers/scsi/bfa/bfa_tskim.c | 14
drivers/scsi/bfa/bfad.c | 208 +-
drivers/scsi/bfa/bfad_attr.c | 76
drivers/scsi/bfa/bfad_attr.h | 9
drivers/scsi/bfa/bfad_drv.h | 35
drivers/scsi/bfa/bfad_im.c | 53
drivers/scsi/bfa/bfad_im.h | 5
drivers/scsi/bfa/bfad_intr.c | 11
drivers/scsi/bfa/fabric.c | 59
drivers/scsi/bfa/fcbuild.h | 6
drivers/scsi/bfa/fcpim.c | 51
drivers/scsi/bfa/fcs_fabric.h | 2
drivers/scsi/bfa/fcs_fcpim.h | 5
drivers/scsi/bfa/fcs_lport.h | 7
drivers/scsi/bfa/fcs_port.h | 3
drivers/scsi/bfa/fcs_rport.h | 3
drivers/scsi/bfa/fcs_uf.h | 3
drivers/scsi/bfa/fcs_vport.h | 8
drivers/scsi/bfa/fdmi.c | 79
drivers/scsi/bfa/include/aen/bfa_aen.h | 50
drivers/scsi/bfa/include/bfa.h | 22
drivers/scsi/bfa/include/bfa_svc.h | 101 -
drivers/scsi/bfa/include/bfa_timer.h | 2
drivers/scsi/bfa/include/bfi/bfi.h | 4
drivers/scsi/bfa/include/bfi/bfi_cbreg.h | 16
drivers/scsi/bfa/include/bfi/bfi_ctreg.h | 26
drivers/scsi/bfa/include/bfi/bfi_ioc.h | 2
drivers/scsi/bfa/include/bfi/bfi_lps.h | 8
drivers/scsi/bfa/include/bfi/bfi_pport.h | 172 --
drivers/scsi/bfa/include/cna/bfa_cna_trcmod.h | 4
drivers/scsi/bfa/include/cs/bfa_log.h | 2
drivers/scsi/bfa/include/cs/bfa_plog.h | 9
drivers/scsi/bfa/include/cs/bfa_sm.h | 8
drivers/scsi/bfa/include/defs/bfa_defs_aen.h | 10
drivers/scsi/bfa/include/defs/bfa_defs_auth.h | 22
drivers/scsi/bfa/include/defs/bfa_defs_cee.h | 14
drivers/scsi/bfa/include/defs/bfa_defs_driver.h | 3
drivers/scsi/bfa/include/defs/bfa_defs_ethport.h | 1
drivers/scsi/bfa/include/defs/bfa_defs_fcport.h | 94 +
drivers/scsi/bfa/include/defs/bfa_defs_im_common.h | 32
drivers/scsi/bfa/include/defs/bfa_defs_im_team.h | 72
drivers/scsi/bfa/include/defs/bfa_defs_ioc.h | 3
drivers/scsi/bfa/include/defs/bfa_defs_iocfc.h | 12
drivers/scsi/bfa/include/defs/bfa_defs_lport.h | 4
drivers/scsi/bfa/include/defs/bfa_defs_mfg.h | 111 +
drivers/scsi/bfa/include/defs/bfa_defs_port.h | 19
drivers/scsi/bfa/include/defs/bfa_defs_pport.h | 151 +
drivers/scsi/bfa/include/defs/bfa_defs_status.h | 17
drivers/scsi/bfa/include/fcb/bfa_fcb_fcpim.h | 1
drivers/scsi/bfa/include/fcs/bfa_fcs.h | 5
drivers/scsi/bfa/include/fcs/bfa_fcs_lport.h | 8
drivers/scsi/bfa/include/log/bfa_log_hal.h | 6
drivers/scsi/bfa/include/log/bfa_log_linux.h | 16
drivers/scsi/bfa/include/protocol/fc.h | 5
drivers/scsi/bfa/include/protocol/pcifw.h | 75
drivers/scsi/bfa/loop.c | 2
drivers/scsi/bfa/lport_api.c | 5
drivers/scsi/bfa/ms.c | 29
drivers/scsi/bfa/ns.c | 36
drivers/scsi/bfa/rport.c | 91 -
drivers/scsi/bfa/rport_api.c | 2
drivers/scsi/bfa/rport_ftrs.c | 12
drivers/scsi/bfa/scn.c | 10
drivers/scsi/bfa/vport.c | 86 -
drivers/scsi/bnx2i/bnx2i_iscsi.c | 2
drivers/scsi/cxgb3i/cxgb3i_iscsi.c | 2
drivers/scsi/device_handler/scsi_dh_emc.c | 6
drivers/scsi/hpsa.c | 330 +--
drivers/scsi/hpsa.h | 7
drivers/scsi/hpsa_cmd.h | 20
drivers/scsi/ibmvscsi/ibmvfc.c | 27
drivers/scsi/ibmvscsi/ibmvscsi.c | 19
drivers/scsi/ibmvscsi/ibmvscsi.h | 1
drivers/scsi/ibmvscsi/iseries_vscsi.c | 6
drivers/scsi/ibmvscsi/rpa_vscsi.c | 13
drivers/scsi/ipr.c | 1756 ++++++++++++++++-----
drivers/scsi/ipr.h | 467 ++++-
drivers/scsi/iscsi_tcp.c | 2
drivers/scsi/libiscsi.c | 23
drivers/scsi/lpfc/lpfc.h | 10
drivers/scsi/lpfc/lpfc_attr.c | 7
drivers/scsi/lpfc/lpfc_bsg.c | 332 +++
drivers/scsi/lpfc/lpfc_bsg.h | 12
drivers/scsi/lpfc/lpfc_crtn.h | 7
drivers/scsi/lpfc/lpfc_els.c | 142 +
drivers/scsi/lpfc/lpfc_hbadisc.c | 527 ++++--
drivers/scsi/lpfc/lpfc_init.c | 277 ++-
drivers/scsi/lpfc/lpfc_logmsg.h | 1
drivers/scsi/lpfc/lpfc_mbox.c | 8
drivers/scsi/lpfc/lpfc_scsi.c | 49
drivers/scsi/lpfc/lpfc_sli.c | 413 ++++
drivers/scsi/lpfc/lpfc_sli.h | 1
drivers/scsi/lpfc/lpfc_sli4.h | 38
drivers/scsi/lpfc/lpfc_version.h | 2
drivers/scsi/lpfc/lpfc_vport.c | 7
drivers/scsi/osd/osd_initiator.c | 4
drivers/scsi/raid_class.c | 2
drivers/scsi/scsi_transport_fc.c | 24
drivers/scsi/sd.c | 4
include/scsi/libiscsi.h | 3
133 files changed, 7204 insertions(+), 3525 deletions(-)
James
^ permalink raw reply [flat|nested] 10+ messages in thread* [PATCH 1/2 resend] scsi: fix/convert scsi_scan.c kernel-doc 2010-03-10 17:36 [GIT PULL] final scsi updates for 2.6.34-rc1 James Bottomley @ 2010-03-10 20:00 ` Randy Dunlap 2010-03-10 20:00 ` [PATCH 2/2 resend] scsi: update drivers & tools URL references Randy Dunlap 2010-03-12 18:10 ` [GIT PULL] final scsi updates for 2.6.34-rc1 Linus Torvalds 2 siblings, 0 replies; 10+ messages in thread From: Randy Dunlap @ 2010-03-10 20:00 UTC (permalink / raw) To: scsi, torvalds; +Cc: Andrew Morton, James Bottomley 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 that points to the host adapter itself. - * - * Arguments: SHpnt - Host that needs a scsi_device +/** + * scsi_free_host_dev - Free a scsi_device that points to the host adapter itself + * @sdev: Host device to be freed * * Lock status: None assumed. * * Returns: Nothing - * - * Notes: */ void scsi_free_host_dev(struct scsi_device *sdev) { ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH 2/2 resend] scsi: update drivers & tools URL references 2010-03-10 17:36 [GIT PULL] final scsi updates for 2.6.34-rc1 James Bottomley 2010-03-10 20:00 ` [PATCH 1/2 resend] scsi: fix/convert scsi_scan.c kernel-doc Randy Dunlap @ 2010-03-10 20:00 ` Randy Dunlap 2010-03-12 18:10 ` [GIT PULL] final scsi updates for 2.6.34-rc1 Linus Torvalds 2 siblings, 0 replies; 10+ messages in thread From: Randy Dunlap @ 2010-03-10 20:00 UTC (permalink / raw) To: torvalds, scsi; +Cc: Andrew Morton, James Bottomley 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 http://www.torque.net/sg + For a full changelog see http://sg.danny.cz/sg/index.html Map of SG verions to the Linux kernels in which they appear: ---------- ---------------------------------- @@ -44,28 +44,29 @@ Major new features in SG 3.x driver (cf ** N.B. To use direct IO 'echo 1 > /proc/scsi/sg/allow_dio' or 'echo 1 > /sys/module/sg/parameters/allow_dio' is needed. That attribute is 0 by default. ** - - Historical note: this SCSI pass-through driver has been known as "sg" for + + Historical note: this SCSI pass-through driver has been known as "sg" for a decade. In broader kernel discussions "sg" is used to refer to scatter gather techniques. The context should clarify which "sg" is referred to. Documentation ============= A web site for the SG device driver can be found at: - http://www.torque.net/sg [alternatively check the MAINTAINERS file] + http://sg.danny.cz/sg/index.html + [alternatively check the MAINTAINERS file] The documentation for the sg version 3 driver can be found at: - http://www.torque.net/sg/p/sg_v3_ho.html + http://sg.danny.cz/sg/p/scsi-generic_v3.txt This is a rendering from DocBook source [change the extension to "sgml" or "xml"]. There are renderings in "ps", "pdf", "rtf" and "txt" (soon). The SG_IO ioctl is now found in other parts kernel (e.g. the block layer). - For more information see http://www.torque.net/sg/sg_io.html + For more information see http://sg.danny.cz/sg/sg_io.html The older, version 2 documents discuss the original sg interface in detail: - http://www.torque.net/sg/p/scsi-generic.txt - http://www.torque.net/sg/p/scsi-generic_long.txt + http://sg.danny.cz/sg/p/scsi-generic.txt + http://sg.danny.cz/sg/p/scsi-generic_long.txt Also available: <kernel_source>/Documentation/scsi/scsi-generic.txt - Utility and test programs are available at the sg web site. They are + Utility and test programs are available at the sg web site. They are packaged as sg3_utils (for the lk 2.4 and 2.6 series) and sg_utils (for the lk 2.2 series). */ --- linux-2.6.33-rc4-git2.orig/drivers/scsi/Kconfig +++ linux-2.6.33-rc4-git2/drivers/scsi/Kconfig @@ -1594,8 +1594,8 @@ config SCSI_DEBUG each with multiple dummy SCSI devices (disks). It defaults to one host adapter with one dummy SCSI disk. Each dummy disk uses kernel RAM as storage (i.e. it is a ramdisk). To save space when multiple - dummy disks are simulated, they share the same kernel RAM for - their storage. See <http://www.torque.net/sg/sdebug.html> for more + dummy disks are simulated, they share the same kernel RAM for + their storage. See <http://sg.danny.cz/sg/sdebug26.html> for more information. This driver is primarily of use to those testing the SCSI and block subsystems. If unsure, say N. --- linux-2.6.33-rc4-git2.orig/drivers/scsi/scsi_debug.c +++ linux-2.6.33-rc4-git2/drivers/scsi/scsi_debug.c @@ -12,7 +12,7 @@ * SAS disks. * * - * For documentation see http://www.torque.net/sg/sdebug26.html + * For documentation see http://sg.danny.cz/sg/sdebug26.html * * D. Gilbert (dpg) work for Magneto-Optical device test [20010421] * dpg: work for devfs large number of disks [20010809] --- linux-2.6.33-rc4-git2.orig/Documentation/DocBook/scsi.tmpl +++ linux-2.6.33-rc4-git2/Documentation/DocBook/scsi.tmpl @@ -393,7 +393,7 @@ </para> <para> For documentation see - <ulink url='http://www.torque.net/sg/sdebug26.html'>http://www.torque.net/sg/sdebug26.html</ulink> + <ulink url='http://sg.danny.cz/sg/sdebug26.html'>http://sg.danny.cz/sg/sdebug26.html</ulink> </para> <!-- !Edrivers/scsi/scsi_debug.c --> </sect2> --- linux-2.6.33-rc4-git2.orig/Documentation/scsi/scsi.txt +++ linux-2.6.33-rc4-git2/Documentation/scsi/scsi.txt @@ -4,38 +4,38 @@ The Linux Documentation Project (LDP) ma the SCSI subsystem in the Linux kernel (lk) 2.4 series. See: http://www.tldp.org/HOWTO/SCSI-2.4-HOWTO . The LDP has single and multiple page HTML renderings as well as postscript and pdf. -It can also be found at http://www.torque.net/scsi/SCSI-2.4-HOWTO . +It can also be found at http://sg.danny.cz/scsi/SCSI-2.4-HOWTO/index.html . Notes on using modules in the SCSI subsystem ============================================ -The scsi support in the linux kernel can be modularized in a number of +The scsi support in the linux kernel can be modularized in a number of different ways depending upon the needs of the end user. To understand your options, we should first define a few terms. -The scsi-core (also known as the "mid level") contains the core of scsi +The scsi-core (also known as the "mid level") contains the core of scsi support. Without it you can do nothing with any of the other scsi drivers. The scsi core support can be a module (scsi_mod.o), or it can be built into -the kernel. If the core is a module, it must be the first scsi module -loaded, and if you unload the modules, it will have to be the last one +the kernel. If the core is a module, it must be the first scsi module +loaded, and if you unload the modules, it will have to be the last one unloaded. In practice the modprobe and rmmod commands (and "autoclean") will enforce the correct ordering of loading and unloading modules in the SCSI subsystem. -The individual upper and lower level drivers can be loaded in any order +The individual upper and lower level drivers can be loaded in any order once the scsi core is present in the kernel (either compiled in or loaded as a module). The disk driver (sd_mod.o), cdrom driver (sr_mod.o), -tape driver ** (st.o) and scsi generics driver (sg.o) represent the upper -level drivers to support the various assorted devices which can be -controlled. You can for example load the tape driver to use the tape drive, +tape driver ** (st.o) and scsi generics driver (sg.o) represent the upper +level drivers to support the various assorted devices which can be +controlled. You can for example load the tape driver to use the tape drive, and then unload it once you have no further need for the driver (and release the associated memory). The lower level drivers are the ones that support the individual cards that are supported for the hardware platform that you are running under. Those individual cards are often called Host Bus Adapters (HBAs). For example the -aic7xxx.o driver is used to control all recent SCSI controller cards from -Adaptec. Almost all lower level drivers can be built either as modules or +aic7xxx.o driver is used to control all recent SCSI controller cards from +Adaptec. Almost all lower level drivers can be built either as modules or built into the kernel. --- linux-2.6.33-rc4-git2.orig/Documentation/scsi/scsi_mid_low_api.txt +++ linux-2.6.33-rc4-git2/Documentation/scsi/scsi_mid_low_api.txt @@ -5,7 +5,7 @@ Introduction ============ This document outlines the interface between the Linux SCSI mid level and -SCSI lower level drivers. Lower level drivers (LLDs) are variously called +SCSI lower level drivers. Lower level drivers (LLDs) are variously called host bus adapter (HBA) drivers and host drivers (HD). A "host" in this context is a bridge between a computer IO bus (e.g. PCI or ISA) and a single SCSI initiator port on a SCSI transport. An "initiator" port @@ -24,8 +24,8 @@ directory). For example, the aic7xxx LLD controls Adaptec SCSI parallel interface (SPI) controllers based on that company's 7xxx chip series. The aic7xxx LLD can be built into the kernel or loaded as a module. There can only be -one aic7xxx LLD running in a Linux system but it may be controlling many -HBAs. These HBAs might be either on PCI daughter-boards or built into +one aic7xxx LLD running in a Linux system but it may be controlling many +HBAs. These HBAs might be either on PCI daughter-boards or built into the motherboard (or both). Some aic7xxx based HBAs are dual controllers and thus represent two hosts. Like most modern HBAs, each aic7xxx host has its own PCI device address. [The one-to-one correspondence between @@ -39,20 +39,20 @@ This version of the document roughly mat Documentation ============= -There is a SCSI documentation directory within the kernel source tree, +There is a SCSI documentation directory within the kernel source tree, typically Documentation/scsi . Most documents are in plain -(i.e. ASCII) text. This file is named scsi_mid_low_api.txt and can be -found in that directory. A more recent copy of this document may be found -at http://www.torque.net/scsi/scsi_mid_low_api.txt.gz . +(i.e. ASCII) text. This file is named scsi_mid_low_api.txt and can be +found in that directory. + Many LLDs are documented there (e.g. aic7xxx.txt). The SCSI mid-level is -briefly described in scsi.txt which contains a url to a document -describing the SCSI subsystem in the lk 2.4 series. Two upper level -drivers have documents in that directory: st.txt (SCSI tape driver) and +briefly described in scsi.txt which contains a url to a document +describing the SCSI subsystem in the lk 2.4 series. Two upper level +drivers have documents in that directory: st.txt (SCSI tape driver) and scsi-generic.txt (for the sg driver). Some documentation (or urls) for LLDs may be found in the C source code or in the same directory as the C source code. For example to find a url -about the USB mass storage driver see the +about the USB mass storage driver see the /usr/src/linux/drivers/usb/storage directory. The Linux kernel source Documentation/DocBook/scsidrivers.tmpl file @@ -67,7 +67,7 @@ the drivers/scsi directory. For example, file "xyz.h" and a source file "xyz.c". [Actually there is no good reason why this couldn't all be in one file; the header file is superfluous.] Some drivers that have been ported to several operating systems have more than -two files. For example the aic7xxx driver has separate files for generic +two files. For example the aic7xxx driver has separate files for generic and OS-specific code (e.g. FreeBSD and Linux). Such drivers tend to have their own directory under the drivers/scsi directory. @@ -85,7 +85,7 @@ to be hot plugged (and unplugged) during be referred to as the "hotplug" initialization model. The newer model is preferred as it can handle both traditional SCSI equipment that is permanently connected as well as modern "SCSI" devices (e.g. USB or -IEEE 1394 connected digital cameras) that are hotplugged. Both +IEEE 1394 connected digital cameras) that are hotplugged. Both initialization models are discussed in the following sections. An LLD interfaces to the SCSI subsystem several ways: @@ -103,9 +103,9 @@ supplied functions" below. Those functions in group b) are listed in a section entitled "Interface functions" below. Their function pointers are placed in the members of "struct scsi_host_template", an instance of which is passed to -scsi_host_alloc() ** . Those interface functions that the LLD does not -wish to supply should have NULL placed in the corresponding member of -struct scsi_host_template. Defining an instance of struct +scsi_host_alloc() ** . Those interface functions that the LLD does not +wish to supply should have NULL placed in the corresponding member of +struct scsi_host_template. Defining an instance of struct scsi_host_template at file scope will cause NULL to be placed in function pointer members not explicitly initialized. @@ -115,7 +115,7 @@ that are shared with the mid level and o All functions defined within an LLD and all data defined at file scope should be static. For example the slave_alloc() function in an LLD -called "xxx" could be defined as +called "xxx" could be defined as "static int xxx_slave_alloc(struct scsi_device * sdev) { /* code */ }" ** the scsi_host_alloc() function is a replacement for the rather vaguely @@ -143,7 +143,7 @@ aware of an LLD when that LLD registers At some later time, the LLD becomes aware of an HBA and what follows is a typical sequence of calls between the LLD and the mid level. -This example shows the mid level scanning the newly introduced HBA for 3 +This example shows the mid level scanning the newly introduced HBA for 3 scsi devices of which only the first 2 respond: HBA PROBE: assume 2 SCSI devices found in scan @@ -184,7 +184,7 @@ scsi_remove_host() ---------+ slave_destroy() scsi_host_put() ------------------------------------------------------------ - + It may be useful for a LLD to keep track of struct Scsi_Host instances (a pointer is returned by scsi_host_alloc()). Such instances are "owned" by the mid-level. struct Scsi_Host instances are freed from @@ -296,7 +296,7 @@ exit_this_scsi_driver() ----+ release() --> scsi_unregister() ------------------------------------------------------------ -An LLD need not define slave_destroy() (i.e. it is optional). +An LLD need not define slave_destroy() (i.e. it is optional). The shortcoming of the "passive initialization model" is that host registration and de-registration are (typically) tied to LLD initialization @@ -317,7 +317,7 @@ where they do. There are 3 reference counting functions of interest associated with struct Scsi_Host: - - scsi_host_alloc(): returns a pointer to new instance of struct + - scsi_host_alloc(): returns a pointer to new instance of struct Scsi_Host which has its reference count ^^ set to 1 - scsi_host_get(): adds 1 to the reference count of the given instance - scsi_host_put(): decrements 1 from the reference count of the given @@ -341,12 +341,12 @@ in parallel by these functions. Conventions =========== First, Linus Torvalds's thoughts on C coding style can be found in the -Documentation/CodingStyle file. +Documentation/CodingStyle file. -Next, there is a movement to "outlaw" typedefs introducing synonyms for +Next, there is a movement to "outlaw" typedefs introducing synonyms for struct tags. Both can be still found in the SCSI subsystem, but the typedefs have been moved to a single file, scsi_typedefs.h to -make their future removal easier, for example: +make their future removal easier, for example: "typedef struct scsi_cmnd Scsi_Cmnd;" Also, most C99 enhancements are encouraged to the extent they are supported @@ -364,7 +364,7 @@ and Adaptec have their own coding conven Mid level supplied functions ============================ These functions are supplied by the SCSI mid level for use by LLDs. -The names (i.e. entry points) of these functions are exported +The names (i.e. entry points) of these functions are exported so an LLD that is a module can access them. The kernel will arrange for the SCSI mid level to be loaded and initialized before any LLD is initialized. The functions below are listed alphabetically and their @@ -387,7 +387,7 @@ Summary: scsi_remove_host - detach and remove all SCSI devices owned by host scsi_report_bus_reset - report scsi _bus_ reset observed scsi_scan_host - scan SCSI bus - scsi_track_queue_full - track successive QUEUE_FULL events + scsi_track_queue_full - track successive QUEUE_FULL events scsi_unblock_requests - allow further commands to be queued to given host scsi_unregister - [calls scsi_host_put()] @@ -419,7 +419,7 @@ void scsi_activate_tcq(struct scsi_devic * @id: target id number * @lun: logical unit number * - * Returns pointer to new struct scsi_device instance or + * Returns pointer to new struct scsi_device instance or * ERR_PTR(-ENODEV) (or some other bent pointer) if something is * wrong (e.g. no lu responds at given address) * @@ -434,7 +434,7 @@ void scsi_activate_tcq(struct scsi_devic * * Defined in: drivers/scsi/scsi_scan.c **/ -struct scsi_device * scsi_add_device(struct Scsi_Host *shost, +struct scsi_device * scsi_add_device(struct Scsi_Host *shost, unsigned int channel, unsigned int id, unsigned int lun) @@ -483,7 +483,7 @@ int scsi_add_host(struct Scsi_Host *shos * Defined in: drivers/scsi/scsi.c [see source code for more notes] * **/ -void scsi_adjust_queue_depth(struct scsi_device * sdev, int tagged, +void scsi_adjust_queue_depth(struct scsi_device * sdev, int tagged, int tags) @@ -546,7 +546,7 @@ void scsi_deactivate_tcq(struct scsi_dev * * Notes: When this call returns to the LLD, the SCSI bus scan on * this host has _not_ yet been done. - * The hostdata array (by default zero length) is a per host scratch + * The hostdata array (by default zero length) is a per host scratch * area for the LLD's exclusive use. * Both associated refcounting objects have their refcount set to 1. * Full registration (in sysfs) and a bus scan are performed later when @@ -624,7 +624,7 @@ int scsi_partsize(unsigned char *buf, un * * Notes: When this call returns to the LLD, the SCSI bus scan on * this host has _not_ yet been done. - * The hostdata array (by default zero length) is a per host scratch + * The hostdata array (by default zero length) is a per host scratch * area for the LLD. * * Defined in: drivers/scsi/hosts.c . @@ -644,7 +644,7 @@ struct Scsi_Host * scsi_register(struct * Notes: If an LLD becomes aware that a scsi device (lu) has * been removed but its host is still present then it can request * the removal of that scsi device. If successful this call will - * lead to the slave_destroy() callback being invoked. sdev is an + * lead to the slave_destroy() callback being invoked. sdev is an * invalid pointer after this call. * * Defined in: drivers/scsi/scsi_sysfs.c . @@ -661,7 +661,7 @@ int scsi_remove_device(struct scsi_devic * Might block: yes * * Notes: Should only be invoked if the "hotplug initialization - * model" is being used. It should be called _prior_ to + * model" is being used. It should be called _prior_ to * scsi_unregister(). * * Defined in: drivers/scsi/hosts.c . @@ -679,8 +679,8 @@ int scsi_remove_host(struct Scsi_Host *s * Might block: no * * Notes: This only needs to be called if the reset is one which - * originates from an unknown location. Resets originated by the - * mid level itself don't need to call this, but there should be + * originates from an unknown location. Resets originated by the + * mid level itself don't need to call this, but there should be * no harm. The main purpose of this is to make sure that a * CHECK_CONDITION is properly treated. * @@ -718,7 +718,7 @@ void scsi_scan_host(struct Scsi_Host *sh * Might block: no * * Notes: LLDs may call this at any time and we will do "The Right - * Thing"; interrupt context safe. + * Thing"; interrupt context safe. * * Defined in: drivers/scsi/scsi.c . **/ @@ -765,7 +765,7 @@ Interface functions are supplied (define pointers are placed in an instance of struct scsi_host_template which is passed to scsi_host_alloc() [or scsi_register() / init_this_scsi_driver()]. Some are mandatory. Interface functions should be declared static. The -accepted convention is that driver "xyz" will declare its slave_configure() +accepted convention is that driver "xyz" will declare its slave_configure() function as: static int xyz_slave_configure(struct scsi_device * sdev); and so forth for all interface functions listed below. @@ -794,7 +794,7 @@ Summary: proc_info - supports /proc/scsi/{driver_name}/{host_no} queuecommand - queue scsi command, invoke 'done' on completion release - release all resources associated with given host - slave_alloc - prior to any commands being sent to a new device + slave_alloc - prior to any commands being sent to a new device slave_configure - driver fine tuning for given device after attach slave_destroy - given device is about to be shut down @@ -803,14 +803,14 @@ Details: /** * bios_param - fetch head, sector, cylinder info for a disk - * @sdev: pointer to scsi device context (defined in + * @sdev: pointer to scsi device context (defined in * include/scsi/scsi_device.h) * @bdev: pointer to block device context (defined in fs.h) * @capacity: device size (in 512 byte sectors) * @params: three element array to place output: * params[0] number of heads (max 255) * params[1] number of sectors (max 63) - * params[2] number of cylinders + * params[2] number of cylinders * * Return value is ignored * @@ -820,7 +820,7 @@ Details: * * Notes: an arbitrary geometry (based on READ CAPACITY) is used * if this function is not provided. The params array is - * pre-initialized with made up values just in case this function + * pre-initialized with made up values just in case this function * doesn't output anything. * * Optionally defined in: LLD @@ -842,7 +842,7 @@ Details: * * Notes: First function called from the SCSI mid level on this * driver. Upper level drivers (e.g. sd) may not (yet) be present. - * For each host found, this method should call scsi_register() + * For each host found, this method should call scsi_register() * [see hosts.c]. * * Defined in: LLD (required if "passive initialization mode" is used, @@ -942,10 +942,10 @@ Details: * Calling context: kernel thread * * Notes: Invoked from scsi_eh thread. No other commands will be - * queued on current host during eh. - * With the default eh_strategy in place, if none of the _abort_, - * _device_reset_, _bus_reset_ or this eh handler function are - * defined (or they all return FAILED) then the device in question + * queued on current host during eh. + * With the default eh_strategy in place, if none of the _abort_, + * _device_reset_, _bus_reset_ or this eh handler function are + * defined (or they all return FAILED) then the device in question * will be set offline whenever eh is invoked. * * Optionally defined in: LLD @@ -968,7 +968,7 @@ Details: * * Notes: Often supplies PCI or ISA information such as IO addresses * and interrupt numbers. If not supplied struct Scsi_Host::name used - * instead. It is assumed the returned information fits on one line + * instead. It is assumed the returned information fits on one line * (i.e. does not included embedded newlines). * The SCSI_IOCTL_PROBE_HOST ioctl yields the string returned by this * function (or struct Scsi_Host::name if this function is not @@ -1039,7 +1039,7 @@ Details: * * Optionally defined in: LLD **/ - int proc_info(char * buffer, char ** start, off_t offset, + int proc_info(char * buffer, char ** start, off_t offset, int length, int host_no, int writeto1_read0) @@ -1093,22 +1093,22 @@ Details: * Calling context: in interrupt (soft irq) or process context * * Notes: This function should be relatively fast. Normally it will - * not wait for IO to complete. Hence the 'done' callback is invoked + * not wait for IO to complete. Hence the 'done' callback is invoked * (often directly from an interrupt service routine) some time after - * this function has returned. In some cases (e.g. pseudo adapter + * this function has returned. In some cases (e.g. pseudo adapter * drivers that manufacture the response to a SCSI INQUIRY) * the 'done' callback may be invoked before this function returns. * If the 'done' callback is not invoked within a certain period * the SCSI mid level will commence error processing. * If a status of CHECK CONDITION is placed in "result" when the - * 'done' callback is invoked, then the LLD driver should + * 'done' callback is invoked, then the LLD driver should * perform autosense and fill in the struct scsi_cmnd::sense_buffer * array. The scsi_cmnd::sense_buffer array is zeroed prior to * the mid level queuing a command to an LLD. * * Defined in: LLD **/ - int queuecommand(struct scsi_cmnd * scp, + int queuecommand(struct scsi_cmnd * scp, void (*done)(struct scsi_cmnd *)) @@ -1123,7 +1123,7 @@ Details: * Calling context: process * * Notes: Invoked from scsi_module.c's exit_this_scsi_driver(). - * LLD's implementation of this function should call + * LLD's implementation of this function should call * scsi_unregister(shp) prior to returning. * Only needed for old-style host templates. * @@ -1134,7 +1134,7 @@ Details: /** - * slave_alloc - prior to any commands being sent to a new device + * slave_alloc - prior to any commands being sent to a new device * (i.e. just prior to scan) this call is made * @sdp: pointer to new device (about to be scanned) * @@ -1266,7 +1266,7 @@ of interest: (if any). FC and SPI transports currently supported. sh_list - a double linked list of pointers to all struct Scsi_Host instances (currently ordered by ascending host_no) - my_devices - a double linked list of pointers to struct scsi_device + my_devices - a double linked list of pointers to struct scsi_device instances that belong to this host. hostdata[0] - area reserved for LLD at end of struct Scsi_Host. Size is set by the second argument (named 'xtr_bytes') to @@ -1340,7 +1340,7 @@ Members of interest: underruns (overruns should be rare). If possible an LLD should set 'resid' prior to invoking 'done'. The most interesting case is data transfers from a SCSI target - device device (i.e. READs) that underrun. + device device (i.e. READs) that underrun. underflow - LLD should place (DID_ERROR << 16) in 'result' if actual number of bytes transferred is less than this figure. Not many LLDs implement this check and some that @@ -1353,8 +1353,8 @@ The scsi_cmnd structure is defined in in Locks ===== -Each struct Scsi_Host instance has a spin_lock called struct -Scsi_Host::default_lock which is initialized in scsi_host_alloc() [found in +Each struct Scsi_Host instance has a spin_lock called struct +Scsi_Host::default_lock which is initialized in scsi_host_alloc() [found in hosts.c]. Within the same function the struct Scsi_Host::host_lock pointer is initialized to point at default_lock. Thereafter lock and unlock operations performed by the mid level use the struct Scsi_Host::host_lock @@ -1368,13 +1368,13 @@ Autosense (or auto-sense) is defined in automatic return of sense data to the application client coincident with the completion of a SCSI command" when a status of CHECK CONDITION occurs. LLDs should perform autosense. This should be done when the LLD -detects a CHECK CONDITION status by either: +detects a CHECK CONDITION status by either: a) instructing the SCSI protocol (e.g. SCSI Parallel Interface (SPI)) to perform an extra data in phase on such responses b) or, the LLD issuing a REQUEST SENSE command itself Either way, when a status of CHECK CONDITION is detected, the mid level -decides whether the LLD has performed autosense by checking struct +decides whether the LLD has performed autosense by checking struct scsi_cmnd::sense_buffer[0] . If this byte has an upper nibble of 7 (or 0xf) then autosense is assumed to have taken place. If it has another value (and this byte is initialized to 0 before each command) then the mid level will @@ -1388,7 +1388,7 @@ to perform autosense. Changes since lk 2.4 series =========================== -io_request_lock has been replaced by several finer grained locks. The lock +io_request_lock has been replaced by several finer grained locks. The lock relevant to LLDs is struct Scsi_Host::host_lock and there is one per SCSI host. @@ -1396,9 +1396,9 @@ The older error handling mechanism has b LLD interface functions abort() and reset() have been removed. The struct scsi_host_template::use_new_eh_code flag has been removed. -In the 2.4 series the SCSI subsystem configuration descriptions were -aggregated with the configuration descriptions from all other Linux -subsystems in the Documentation/Configure.help file. In the 2.6 series, +In the 2.4 series the SCSI subsystem configuration descriptions were +aggregated with the configuration descriptions from all other Linux +subsystems in the Documentation/Configure.help file. In the 2.6 series, the SCSI subsystem now has its own (much smaller) drivers/scsi/Kconfig file that contains both configuration and help information. @@ -1413,7 +1413,7 @@ Credits The following people have contributed to this document: Mike Anderson <andmike at us dot ibm dot com> James Bottomley <James dot Bottomley at hansenpartnership dot com> - Patrick Mansfield <patmans at us dot ibm dot com> + Patrick Mansfield <patmans at us dot ibm dot com> Christoph Hellwig <hch at infradead dot org> Doug Ledford <dledford at redhat dot com> Andries Brouwer <Andries dot Brouwer at cwi dot nl> --- linux-2.6.33-rc4-git2.orig/Documentation/scsi/scsi-generic.txt +++ linux-2.6.33-rc4-git2/Documentation/scsi/scsi-generic.txt @@ -18,7 +18,7 @@ and examples. Major versions of the sg driver =============================== There are three major versions of sg found in the linux kernel (lk): - - sg version 1 (original) from 1992 to early 1999 (lk 2.2.5) . + - sg version 1 (original) from 1992 to early 1999 (lk 2.2.5) . It is based in the sg_header interface structure. - sg version 2 from lk 2.2.6 in the 2.2 series. It is based on an extended version of the sg_header interface structure. @@ -29,28 +29,28 @@ There are three major versions of sg fou Sg driver documentation ======================= The most recent documentation of the sg driver is kept at the Linux -Documentation Project's (LDP) site: +Documentation Project's (LDP) site: http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO This describes the sg version 3 driver found in the lk 2.4 series. The LDP renders documents in single and multiple page HTML, postscript and pdf. This document can also be found at: -http://www.torque.net/sg/p/sg_v3_ho.html +http://sg.danny.cz/sg/p/sg_v3_ho.html Documentation for the version 2 sg driver found in the lk 2.2 series can -be found at http://www.torque.net/sg/p/scsi-generic.txt . A larger version -is at: http://www.torque.net/sg/p/scsi-generic_long.txt . +be found at http://sg.danny.cz/sg/p/scsi-generic.txt . A larger version +is at: http://sg.danny.cz/sg/p/scsi-generic_long.txt . The original documentation for the sg driver (prior to lk 2.2.6) can be -found at http://www.torque.net/sg/p/original/SCSI-Programming-HOWTO.txt +found at http://sg.danny.cz/sg/p/original/SCSI-Programming-HOWTO.txt and in the LDP archives. A changelog with brief notes can be found in the -/usr/src/linux/include/scsi/sg.h file. Note that the glibc maintainers copy -and edit this file (removing its changelog for example) before placing it -in /usr/include/scsi/sg.h . Driver debugging information and other notes +/usr/src/linux/include/scsi/sg.h file. Note that the glibc maintainers copy +and edit this file (removing its changelog for example) before placing it +in /usr/include/scsi/sg.h . Driver debugging information and other notes can be found at the top of the /usr/src/linux/drivers/scsi/sg.c file. -A more general description of the Linux SCSI subsystem of which sg is a +A more general description of the Linux SCSI subsystem of which sg is a part can be found at http://www.tldp.org/HOWTO/SCSI-2.4-HOWTO . @@ -60,8 +60,8 @@ There are two packages of sg utilities: - sg3_utils for the sg version 3 driver found in lk 2.4 - sg_utils for the sg version 2 (and original) driver found in lk 2.2 and earlier -Both packages will work in the lk 2.4 series however sg3_utils offers more -capabilities. They can be found at: http://www.torque.net/sg and +Both packages will work in the lk 2.4 series; however, sg3_utils offers more +capabilities. They can be found at: http://sg.danny.cz/sg/index.html and freshmeat.net Another approach is to look at the applications that use the sg driver. @@ -73,14 +73,14 @@ Mapping of Linux kernel versions to sg d Here is a list of linux kernels in the 2.4 series that had new version of the sg driver: lk 2.4.0 : sg version 3.1.17 - lk 2.4.7 : sg version 3.1.19 + lk 2.4.7 : sg version 3.1.19 lk 2.4.10 : sg version 3.1.20 ** - lk 2.4.17 : sg version 3.1.22 + lk 2.4.17 : sg version 3.1.22 ** There were 3 changes to sg version 3.1.20 by third parties in the next six linux kernel versions. -For reference here is a list of linux kernels in the 2.2 series that had +For reference here is a list of linux kernels in the 2.2 series that had new version of the sg driver: lk 2.2.0 : original sg version [with no version number] lk 2.2.6 : sg version 2.1.31 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] final scsi updates for 2.6.34-rc1 2010-03-10 17:36 [GIT PULL] final scsi updates for 2.6.34-rc1 James Bottomley 2010-03-10 20:00 ` [PATCH 1/2 resend] scsi: fix/convert scsi_scan.c kernel-doc Randy Dunlap 2010-03-10 20:00 ` [PATCH 2/2 resend] scsi: update drivers & tools URL references Randy Dunlap @ 2010-03-12 18:10 ` Linus Torvalds 2010-03-12 18:27 ` James Bottomley 2 siblings, 1 reply; 10+ messages in thread From: Linus Torvalds @ 2010-03-12 18:10 UTC (permalink / raw) To: James Bottomley; +Cc: Andrew Morton, linux-scsi, linux-kernel On Wed, 10 Mar 2010, James Bottomley wrote: > > 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 ...). 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] final scsi updates for 2.6.34-rc1 2010-03-12 18:10 ` [GIT PULL] final scsi updates for 2.6.34-rc1 Linus Torvalds @ 2010-03-12 18:27 ` James Bottomley 2010-03-12 18:34 ` Linus Torvalds 2010-03-13 19:35 ` Ray Lee 0 siblings, 2 replies; 10+ messages in thread From: James Bottomley @ 2010-03-12 18:27 UTC (permalink / raw) To: Linus Torvalds; +Cc: Andrew Morton, linux-scsi, linux-kernel On Fri, 2010-03-12 at 10:10 -0800, Linus Torvalds wrote: > > On Wed, 10 Mar 2010, James Bottomley wrote: > > > > 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 ...). > > 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. 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] final scsi updates for 2.6.34-rc1 2010-03-12 18:27 ` James Bottomley @ 2010-03-12 18:34 ` Linus Torvalds 2010-03-12 18:40 ` Linus Torvalds 2010-03-13 19:35 ` Ray Lee 1 sibling, 1 reply; 10+ messages in thread From: Linus Torvalds @ 2010-03-12 18:34 UTC (permalink / raw) To: James Bottomley; +Cc: Andrew Morton, linux-scsi, linux-kernel On Fri, 12 Mar 2010, James Bottomley wrote: > > I'm not objecting to a shorter merge window, just the unpredictability > of all of this. 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] final scsi updates for 2.6.34-rc1 2010-03-12 18:34 ` Linus Torvalds @ 2010-03-12 18:40 ` Linus Torvalds 0 siblings, 0 replies; 10+ messages in thread From: Linus Torvalds @ 2010-03-12 18:40 UTC (permalink / raw) To: James Bottomley; +Cc: Andrew Morton, linux-scsi, linux-kernel On Fri, 12 Mar 2010, Linus Torvalds wrote: > > 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! 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] final scsi updates for 2.6.34-rc1 2010-03-12 18:27 ` James Bottomley 2010-03-12 18:34 ` Linus Torvalds @ 2010-03-13 19:35 ` Ray Lee 2010-03-13 20:16 ` Douglas Gilbert 1 sibling, 1 reply; 10+ messages in thread From: Ray Lee @ 2010-03-13 19:35 UTC (permalink / raw) To: James Bottomley; +Cc: Linus Torvalds, Andrew Morton, linux-scsi, linux-kernel On Fri, Mar 12, 2010 at 10:27 AM, James Bottomley wrote: > I do always have a tree ready in the first days of the merge window. It > was, in fact, here: [...] > 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. 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. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] final scsi updates for 2.6.34-rc1 2010-03-13 19:35 ` Ray Lee @ 2010-03-13 20:16 ` Douglas Gilbert 0 siblings, 0 replies; 10+ messages in thread From: Douglas Gilbert @ 2010-03-13 20:16 UTC (permalink / raw) To: Ray Lee Cc: James Bottomley, Linus Torvalds, Andrew Morton, linux-scsi, linux-kernel Ray Lee wrote: > On Fri, Mar 12, 2010 at 10:27 AM, James Bottomley wrote: >> I do always have a tree ready in the first days of the merge window. It >> was, in fact, here: > > [...] > >> 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. > > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [GIT PULL] final scsi updates for 2.6.34-rc1
@ 2010-03-16 17:11 James Bottomley
0 siblings, 0 replies; 10+ messages in thread
From: James Bottomley @ 2010-03-16 17:11 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: linux-scsi, linux-kernel
OK, I think we've got understanding that this is the *second* pull
request from SCSI ... it's just all the changes that got flushed out
during the merge window, so I'm resubmitting it.
Going forwards, we're going to try to send in our last pull at the 11th
day, which means it needs to be in my scsi-misc tree by the 8th day of
the merge window (to get sufficient a work out in linux-next). We're
also going to try to move as much stuff as we can from the second pull
to the first one, so this practice will be acceptable only if the second
pull is a lot smaller than the first one.
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 logic
bfa: Replace bfa_get_attr() with specific APIs
bfa: New portlog entries for events (FIP/FLOGI/FDISC/LOGO).
bfa: Rename pport to fcport in BFA FCS.
bfa: IOC fixes, check for IOC down condition.
bfa: In MSIX mode, ignore spurious RME interrupts when FCoE ports are in FW mismatch state.
bfa: Fix Command Queue (CPE) full condition check and ack CPE interrupt.
bfa: IOC recovery fix in fcmode.
bfa: AEN and byte alignment fixes.
bfa: Introduce a link notification state machine.
bfa: Added firmware save clear feature for BFA driver.
bfa: FCS authentication related changes.
bfa: PCI VPD, FIP and include file changes.
bfa: Fix to copy fpma MAC when requested by user space application.
bfa: RPORT state machine: direct attach mode fix.
bfa: Replace bfa_assert() with bfa_sm_fault()
bfa: Clear LL_HALT and PSS_ERR bit when IOC crashes.
bfa: IOC changes: Support faster recovery and split bfa_ioc.c into ASIC specific code.
bfa: Resume BFA operations after firmware mismatch is resolved.
bfa: Fix to allow creation of only 190 vports on CNA.
bfa: New interface to handle firmware upgrade scenario
bfa: Changes to support FDMI Driver Parameter
bfa: Enable new halt interrupt in BFA.
bfa: Enable IOC auto-recovery and IOC type fix.
bfa: Defined a new LPS event to clear virtual link on a vport
bfa: Added separate MSI-X module parameters.
Martin K. Petersen (1):
sd: Fix VPD buffer allocations
Mike Miller (1):
hpsa: remove scan thread
Stephen M. Cameron (8):
hpsa: remove unused members next, prev, and retry_count from command list structure.
hpsa: Increase the number of scatter gather elements supported.
hpsa: Clarify calculation of padding for commandlist structure
hpsa: mark hpsa_pci_init as __devinit
hpsa: return -ENOMEM, not -1
hpsa: fix scsi status mis-shift
hpsa: fix firmwart typo
hpsa: allow modifying device queue depth.
Wayne Boyer (9):
ipr: adds PCI ID definitions for new adapters
ipr: add support for new IOASCs
ipr: add support for multiple stages of initialization
ipr: implement shutdown changes and remove obsolete write cache parameter
ipr: add hardware assisted smart dump functionality
ipr: add error handling updates for the next generation chip
ipr: update the configuration table code for the next generation chip
ipr: define new offsets to registers for the next generation chip
ipr: add support for new adapter command structures for the next generation chip
The diffstat is:
drivers/infiniband/ulp/iser/iscsi_iser.c | 2
drivers/scsi/Kconfig | 6
drivers/scsi/be2iscsi/be_cmds.c | 7
drivers/scsi/be2iscsi/be_iscsi.c | 4
drivers/scsi/be2iscsi/be_main.c | 201 +-
drivers/scsi/be2iscsi/be_main.h | 11
drivers/scsi/be2iscsi/be_mgmt.c | 14
drivers/scsi/be2iscsi/be_mgmt.h | 8
drivers/scsi/bfa/Makefile | 8
drivers/scsi/bfa/bfa_core.c | 19
drivers/scsi/bfa/bfa_fcport.c | 1709 +++++++++++---------
drivers/scsi/bfa/bfa_fcs.c | 63
drivers/scsi/bfa/bfa_fcs_lport.c | 75
drivers/scsi/bfa/bfa_fcs_port.c | 11
drivers/scsi/bfa/bfa_fcs_uf.c | 8
drivers/scsi/bfa/bfa_hw_cb.c | 13
drivers/scsi/bfa/bfa_hw_ct.c | 9
drivers/scsi/bfa/bfa_intr.c | 111 -
drivers/scsi/bfa/bfa_ioc.c | 762 ++-------
drivers/scsi/bfa/bfa_ioc.h | 57
drivers/scsi/bfa/bfa_ioc_cb.c | 274 +++
drivers/scsi/bfa/bfa_ioc_ct.c | 423 +++++
drivers/scsi/bfa/bfa_iocfc.c | 24
drivers/scsi/bfa/bfa_iocfc.h | 3
drivers/scsi/bfa/bfa_ioim.c | 22
drivers/scsi/bfa/bfa_itnim.c | 30
drivers/scsi/bfa/bfa_lps.c | 134 +
drivers/scsi/bfa/bfa_module.c | 4
drivers/scsi/bfa/bfa_modules_priv.h | 2
drivers/scsi/bfa/bfa_port_priv.h | 57
drivers/scsi/bfa/bfa_priv.h | 2
drivers/scsi/bfa/bfa_rport.c | 26
drivers/scsi/bfa/bfa_trcmod_priv.h | 62
drivers/scsi/bfa/bfa_tskim.c | 14
drivers/scsi/bfa/bfad.c | 208 +-
drivers/scsi/bfa/bfad_attr.c | 76
drivers/scsi/bfa/bfad_attr.h | 9
drivers/scsi/bfa/bfad_drv.h | 35
drivers/scsi/bfa/bfad_im.c | 53
drivers/scsi/bfa/bfad_im.h | 5
drivers/scsi/bfa/bfad_intr.c | 11
drivers/scsi/bfa/fabric.c | 59
drivers/scsi/bfa/fcbuild.h | 6
drivers/scsi/bfa/fcpim.c | 51
drivers/scsi/bfa/fcs_fabric.h | 2
drivers/scsi/bfa/fcs_fcpim.h | 5
drivers/scsi/bfa/fcs_lport.h | 7
drivers/scsi/bfa/fcs_port.h | 3
drivers/scsi/bfa/fcs_rport.h | 3
drivers/scsi/bfa/fcs_uf.h | 3
drivers/scsi/bfa/fcs_vport.h | 8
drivers/scsi/bfa/fdmi.c | 79
drivers/scsi/bfa/include/aen/bfa_aen.h | 50
drivers/scsi/bfa/include/bfa.h | 22
drivers/scsi/bfa/include/bfa_svc.h | 101 -
drivers/scsi/bfa/include/bfa_timer.h | 2
drivers/scsi/bfa/include/bfi/bfi.h | 4
drivers/scsi/bfa/include/bfi/bfi_cbreg.h | 16
drivers/scsi/bfa/include/bfi/bfi_ctreg.h | 26
drivers/scsi/bfa/include/bfi/bfi_ioc.h | 2
drivers/scsi/bfa/include/bfi/bfi_lps.h | 8
drivers/scsi/bfa/include/bfi/bfi_pport.h | 172 --
drivers/scsi/bfa/include/cna/bfa_cna_trcmod.h | 4
drivers/scsi/bfa/include/cs/bfa_log.h | 2
drivers/scsi/bfa/include/cs/bfa_plog.h | 9
drivers/scsi/bfa/include/cs/bfa_sm.h | 8
drivers/scsi/bfa/include/defs/bfa_defs_aen.h | 10
drivers/scsi/bfa/include/defs/bfa_defs_auth.h | 22
drivers/scsi/bfa/include/defs/bfa_defs_cee.h | 14
drivers/scsi/bfa/include/defs/bfa_defs_driver.h | 3
drivers/scsi/bfa/include/defs/bfa_defs_ethport.h | 1
drivers/scsi/bfa/include/defs/bfa_defs_fcport.h | 94 +
drivers/scsi/bfa/include/defs/bfa_defs_im_common.h | 32
drivers/scsi/bfa/include/defs/bfa_defs_im_team.h | 72
drivers/scsi/bfa/include/defs/bfa_defs_ioc.h | 3
drivers/scsi/bfa/include/defs/bfa_defs_iocfc.h | 12
drivers/scsi/bfa/include/defs/bfa_defs_lport.h | 4
drivers/scsi/bfa/include/defs/bfa_defs_mfg.h | 111 +
drivers/scsi/bfa/include/defs/bfa_defs_port.h | 19
drivers/scsi/bfa/include/defs/bfa_defs_pport.h | 151 +
drivers/scsi/bfa/include/defs/bfa_defs_status.h | 17
drivers/scsi/bfa/include/fcb/bfa_fcb_fcpim.h | 1
drivers/scsi/bfa/include/fcs/bfa_fcs.h | 5
drivers/scsi/bfa/include/fcs/bfa_fcs_lport.h | 8
drivers/scsi/bfa/include/log/bfa_log_hal.h | 6
drivers/scsi/bfa/include/log/bfa_log_linux.h | 16
drivers/scsi/bfa/include/protocol/fc.h | 5
drivers/scsi/bfa/include/protocol/pcifw.h | 75
drivers/scsi/bfa/loop.c | 2
drivers/scsi/bfa/lport_api.c | 5
drivers/scsi/bfa/ms.c | 29
drivers/scsi/bfa/ns.c | 36
drivers/scsi/bfa/rport.c | 91 -
drivers/scsi/bfa/rport_api.c | 2
drivers/scsi/bfa/rport_ftrs.c | 12
drivers/scsi/bfa/scn.c | 10
drivers/scsi/bfa/vport.c | 86 -
drivers/scsi/bnx2i/bnx2i_iscsi.c | 2
drivers/scsi/cxgb3i/cxgb3i_iscsi.c | 2
drivers/scsi/device_handler/scsi_dh_emc.c | 6
drivers/scsi/hpsa.c | 330 +--
drivers/scsi/hpsa.h | 7
drivers/scsi/hpsa_cmd.h | 20
drivers/scsi/ibmvscsi/ibmvfc.c | 27
drivers/scsi/ibmvscsi/ibmvscsi.c | 19
drivers/scsi/ibmvscsi/ibmvscsi.h | 1
drivers/scsi/ibmvscsi/iseries_vscsi.c | 6
drivers/scsi/ibmvscsi/rpa_vscsi.c | 13
drivers/scsi/ipr.c | 1756 ++++++++++++++++-----
drivers/scsi/ipr.h | 467 ++++-
drivers/scsi/iscsi_tcp.c | 2
drivers/scsi/libiscsi.c | 23
drivers/scsi/lpfc/lpfc.h | 10
drivers/scsi/lpfc/lpfc_attr.c | 7
drivers/scsi/lpfc/lpfc_bsg.c | 332 +++
drivers/scsi/lpfc/lpfc_bsg.h | 12
drivers/scsi/lpfc/lpfc_crtn.h | 7
drivers/scsi/lpfc/lpfc_els.c | 142 +
drivers/scsi/lpfc/lpfc_hbadisc.c | 527 ++++--
drivers/scsi/lpfc/lpfc_init.c | 277 ++-
drivers/scsi/lpfc/lpfc_logmsg.h | 1
drivers/scsi/lpfc/lpfc_mbox.c | 8
drivers/scsi/lpfc/lpfc_scsi.c | 49
drivers/scsi/lpfc/lpfc_sli.c | 413 ++++
drivers/scsi/lpfc/lpfc_sli.h | 1
drivers/scsi/lpfc/lpfc_sli4.h | 38
drivers/scsi/lpfc/lpfc_version.h | 2
drivers/scsi/lpfc/lpfc_vport.c | 7
drivers/scsi/osd/osd_initiator.c | 4
drivers/scsi/raid_class.c | 2
drivers/scsi/scsi_transport_fc.c | 24
drivers/scsi/sd.c | 4
include/scsi/libiscsi.h | 3
133 files changed, 7204 insertions(+), 3525 deletions(-)
James
^ permalink raw reply [flat|nested] 10+ messages in threadend of thread, other threads:[~2010-03-16 17:11 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-03-10 17:36 [GIT PULL] final scsi updates for 2.6.34-rc1 James Bottomley 2010-03-10 20:00 ` [PATCH 1/2 resend] scsi: fix/convert scsi_scan.c kernel-doc Randy Dunlap 2010-03-10 20:00 ` [PATCH 2/2 resend] scsi: update drivers & tools URL references Randy Dunlap 2010-03-12 18:10 ` [GIT PULL] final scsi updates for 2.6.34-rc1 Linus Torvalds 2010-03-12 18:27 ` James Bottomley 2010-03-12 18:34 ` Linus Torvalds 2010-03-12 18:40 ` Linus Torvalds 2010-03-13 19:35 ` Ray Lee 2010-03-13 20:16 ` Douglas Gilbert -- strict thread matches above, loose matches on Subject: below -- 2010-03-16 17:11 James Bottomley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).