2 files changed, 74 insertions, 64 deletions

diff --git a/drivers/ieee1394/Kconfig b/drivers/ieee1394/Kconfig
index 545663ef820b..95f45f9b8e5e 100644
--- a/drivers/ieee1394/Kconfig
+++ b/drivers/ieee1394/Kconfig
@@ -4,7 +4,7 @@ menu "IEEE 1394 (FireWire) support"
 source "drivers/firewire/Kconfig"
 
 config IEEE1394
-        tristate "IEEE 1394 (FireWire) support"
+        tristate "Stable FireWire stack"
         depends on PCI || BROKEN
         help
           IEEE 1394 describes a high performance serial bus, which is also
@@ -19,30 +19,45 @@ config IEEE1394
           To compile this driver as a module, say M here: the
           module will be called ieee1394.
 
-comment "Subsystem Options"
-        depends on IEEE1394
-
-config IEEE1394_VERBOSEDEBUG
-        bool "Excessive debugging output"
-        depends on IEEE1394
+config IEEE1394_OHCI1394
+        tristate "OHCI-1394 controllers"
+        depends on PCI && IEEE1394
         help
-          If you say Y here, you will get very verbose debugging logs from
-          the subsystem which includes a dump of the header of every sent
-          and received packet.  This can amount to a high amount of data
-          collected in a very short time which is usually also saved to
-          disk by the system logging daemons.
+          Enable this driver if you have an IEEE 1394 controller based on the
+          OHCI-1394 specification. The current driver is only tested with OHCI
+          chipsets made by Texas Instruments and NEC. Most third-party vendors
+          use one of these chipsets.  It should work with any OHCI-1394
+          compliant card, however.
 
-          Say Y if you really want or need the debugging output, everyone
-          else says N.
+          To compile this driver as a module, say M here: the
+          module will be called ohci1394.
 
-comment "Controllers"
-        depends on IEEE1394
+          NOTE:
 
-comment "Texas Instruments PCILynx requires I2C"
+          You should only build either ohci1394 or the new firewire-ohci driver,
+          but not both.  If you nevertheless want to install both, you should
+          configure them only as modules and blacklist the driver(s) which you
+          don't want to have auto-loaded.  Add either
+
+              blacklist firewire-ohci
+          or
+              blacklist ohci1394
+              blacklist video1394
+              blacklist dv1394
+
+          to /etc/modprobe.conf or /etc/modprobe.d/* and update modprobe.conf
+          depending on your distribution.  The latter two modules should be
+          blacklisted together with ohci1394 because they depend on ohci1394.
+
+          If you have an old modprobe which doesn't implement the blacklist
+          directive, use "install modulename /bin/true" for the modules to be
+          blacklisted.
+
+comment "PCILynx controller requires I2C"
         depends on IEEE1394 && I2C=n
 
 config IEEE1394_PCILYNX
-        tristate "Texas Instruments PCILynx support"
+        tristate "PCILynx controller"
         depends on PCI && IEEE1394 && I2C
         select I2C_ALGOBIT
         help
@@ -57,35 +72,11 @@ config IEEE1394_PCILYNX
           PowerMacs G3 B&W contain the PCILynx controller.  Therefore
           almost everybody can say N here.
 
-config IEEE1394_OHCI1394
-        tristate "OHCI-1394 support"
-        depends on PCI && IEEE1394
-        help
-          Enable this driver if you have an IEEE 1394 controller based on the
-          OHCI-1394 specification. The current driver is only tested with OHCI
-          chipsets made by Texas Instruments and NEC. Most third-party vendors
-          use one of these chipsets.  It should work with any OHCI-1394
-          compliant card, however.
-
-          To compile this driver as a module, say M here: the
-          module will be called ohci1394.
-
-comment "Protocols"
-        depends on IEEE1394
-
-config IEEE1394_VIDEO1394
-        tristate "OHCI-1394 Video support"
-        depends on IEEE1394 && IEEE1394_OHCI1394
-        help
-          This option enables video device usage for OHCI-1394 cards.  Enable
-          this option only if you have an IEEE 1394 video device connected to
-          an OHCI-1394 card.
-
 comment "SBP-2 support (for storage devices) requires SCSI"
         depends on IEEE1394 && SCSI=n
 
 config IEEE1394_SBP2
-        tristate "SBP-2 support (Harddisks etc.)"
+        tristate "Storage devices (SBP-2 protocol)"
         depends on IEEE1394 && SCSI
         help
           This option enables you to use SBP-2 devices connected to an IEEE
@@ -127,24 +118,47 @@ config IEEE1394_ETH1394
 
           The module is called eth1394 although it does not emulate Ethernet.
 
+config IEEE1394_RAWIO
+        tristate "raw1394 userspace interface"
+        depends on IEEE1394
+        help
+          This option adds support for the raw1394 device file which enables
+          direct communication of user programs with IEEE 1394 devices
+          (isochronous and asynchronous).  Almost all application programs
+          which access FireWire require this option.
+
+          To compile this driver as a module, say M here: the module will be
+          called raw1394.
+
+config IEEE1394_VIDEO1394
+        tristate "video1394 userspace interface"
+        depends on IEEE1394 && IEEE1394_OHCI1394
+        help
+          This option adds support for the video1394 device files which enable
+          isochronous communication of user programs with IEEE 1394 devices,
+          especially video capture or export.  This interface is used by all
+          libdc1394 based programs and by several other programs, in addition to
+          the raw1394 interface.  It is generally not required for DV capture.
+
+          To compile this driver as a module, say M here: the module will be
+          called video1394.
+
 config IEEE1394_DV1394
-        tristate "OHCI-DV I/O support (deprecated)"
+        tristate "dv1394 userspace interface (deprecated)"
         depends on IEEE1394 && IEEE1394_OHCI1394
         help
           The dv1394 driver is unsupported and may be removed from Linux in a
           future release.  Its functionality is now provided by raw1394 together
           with libraries such as libiec61883.
 
-config IEEE1394_RAWIO
-        tristate "Raw IEEE1394 I/O support"
+config IEEE1394_VERBOSEDEBUG
+        bool "Excessive debugging output"
         depends on IEEE1394
         help
-          This option adds support for the raw1394 device file which enables
-          direct communication of user programs with the IEEE 1394 bus and thus
-          with the attached peripherals.  Almost all application programs which
-          access FireWire require this option.
+          If you say Y here, you will get very verbose debugging logs from the
+          ieee1394 drivers, including sent and received packet headers.  This
+          will quickly result in large amounts of data sent to the system log.
 
-          To compile this driver as a module, say M here: the module will be
-          called raw1394.
+          Say Y if you really need the debugging output.  Everyone else says N.
 
 endmenu
diff --git a/drivers/ieee1394/sbp2.c b/drivers/ieee1394/sbp2.c
index 16b9d0ad154e..a5ceff287a28 100644
--- a/drivers/ieee1394/sbp2.c
+++ b/drivers/ieee1394/sbp2.c
@@ -1539,15 +1539,13 @@ static void sbp2_prep_command_orb_sg(struct sbp2_command_orb *orb,
 
 static void sbp2_create_command_orb(struct sbp2_lu *lu,
                                     struct sbp2_command_info *cmd,
-                                    unchar *scsi_cmd,
-                                    unsigned int scsi_use_sg,
-                                    unsigned int scsi_request_bufflen,
-                                    struct scatterlist *sg,
-                                    enum dma_data_direction dma_dir)
+                                    struct scsi_cmnd *SCpnt)
 {
         struct sbp2_fwhost_info *hi = lu->hi;
         struct sbp2_command_orb *orb = &cmd->command_orb;
         u32 orb_direction;
+        unsigned int scsi_request_bufflen = scsi_bufflen(SCpnt);
+        enum dma_data_direction dma_dir = SCpnt->sc_data_direction;
 
         /*
          * Set-up our command ORB.
@@ -1580,13 +1578,14 @@ static void sbp2_create_command_orb(struct sbp2_lu *lu,
                 orb->data_descriptor_lo = 0x0;
                 orb->misc |= ORB_SET_DIRECTION(1);
         } else
-                sbp2_prep_command_orb_sg(orb, hi, cmd, scsi_use_sg, sg,
+                sbp2_prep_command_orb_sg(orb, hi, cmd, scsi_sg_count(SCpnt),
+                                         scsi_sglist(SCpnt),
                                          orb_direction, dma_dir);
 
         sbp2util_cpu_to_be32_buffer(orb, sizeof(*orb));
 
-        memset(orb->cdb, 0, 12);
-        memcpy(orb->cdb, scsi_cmd, COMMAND_SIZE(*scsi_cmd));
+        memset(orb->cdb, 0, sizeof(orb->cdb));
+        memcpy(orb->cdb, SCpnt->cmnd, SCpnt->cmd_len);
 }
 
 static void sbp2_link_orb_command(struct sbp2_lu *lu,
@@ -1669,16 +1668,13 @@ static void sbp2_link_orb_command(struct sbp2_lu *lu,
 static int sbp2_send_command(struct sbp2_lu *lu, struct scsi_cmnd *SCpnt,
                              void (*done)(struct scsi_cmnd *))
 {
-        unchar *scsi_cmd = (unchar *)SCpnt->cmnd;
         struct sbp2_command_info *cmd;
 
         cmd = sbp2util_allocate_command_orb(lu, SCpnt, done);
         if (!cmd)
                 return -EIO;
 
-        sbp2_create_command_orb(lu, cmd, scsi_cmd, scsi_sg_count(SCpnt),
-                                scsi_bufflen(SCpnt), scsi_sglist(SCpnt),
-                                SCpnt->sc_data_direction);
+        sbp2_create_command_orb(lu, cmd, SCpnt);
         sbp2_link_orb_command(lu, cmd);
 
         return 0;