1. 22 7月, 2008 1 次提交
  2. 15 7月, 2008 1 次提交
  3. 14 7月, 2008 1 次提交
    • S
      scsi: sd: optionally set power condition in START STOP UNIT · d2886ea3
      Stefan Richter 提交于
      Adds a new scsi_device flag, start_stop_pwr_cond:  If enabled, the sd
      driver will not send plain START STOP UNIT commands but ones with the
      power condition field set to 3 (standby) or 1 (active) respectively.
      
      Some FireWire disk firmwares do not stop the motor if power condition is
      zero.  Or worse, they become unresponsive after a START STOP UNIT with
      power condition = 0 and start = 0.
      
      http://lkml.org/lkml/2008/4/29/704
      
      This patch only adds the necessary code to sd_mod but doesn't activate
      it.  Follow-up patches to the FireWire drivers will add detection of
      affected devices and enable the code for them.
      
      I did not add power condition values to scsi_error.c::scsi_eh_try_stu()
      for now.  The three firmwares which suffer from above mentioned problems
      do not need START STOP UNIT in the error handler, and they are not
      adversely affected by START STOP UNIT with power condition = 0 and start
      = 1 (like scsi_eh_try_stu() sends it if scsi_device.allow_restart is
      enabled).
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      Tested-by: NTino Keitel <tino.keitel@gmx.de>
      d2886ea3
  4. 12 7月, 2008 20 次提交
  5. 05 6月, 2008 1 次提交
  6. 03 5月, 2008 1 次提交
  7. 02 5月, 2008 1 次提交
    • B
      [SCSI] Let scsi_cmnd->cmnd use request->cmd buffer · 64a87b24
      Boaz Harrosh 提交于
       - struct scsi_cmnd had a 16 bytes command buffer of its own.
         This is an unnecessary duplication and copy of request's
         cmd. It is probably left overs from the time that scsi_cmnd
         could function without a request attached. So clean that up.
      
       - Once above is done, few places, apart from scsi-ml, needed
         adjustments due to changing the data type of scsi_cmnd->cmnd.
      
       - Lots of drivers still use MAX_COMMAND_SIZE. So I have left
         that #define but equate it to BLK_MAX_CDB. The way I see it
         and is reflected in the patch below is.
         MAX_COMMAND_SIZE - means: The longest fixed-length (*) SCSI CDB
                            as per the SCSI standard and is not related
                            to the implementation.
         BLK_MAX_CDB.     - The allocated space at the request level
      
       - I have audit all ISA drivers and made sure none use ->cmnd in a DMA
         Operation. Same audit was done by Andi Kleen.
      
      (*)fixed-length here means commands that their size can be determined
         by their opcode and the CDB does not carry a length specifier, (unlike
         the VARIABLE_LENGTH_CMD(0x7f) command). This is actually not exactly
         true and the SCSI standard also defines extended commands and
         vendor specific commands that can be bigger than 16 bytes. The kernel
         will support these using the same infrastructure used for VARLEN CDB's.
         So in effect MAX_COMMAND_SIZE means the maximum size command
         scsi-ml supports without specifying a cmd_len by ULD's
      Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      64a87b24
  8. 30 4月, 2008 1 次提交
  9. 23 4月, 2008 1 次提交
    • J
      [SCSI] rework scsi_target allocation · 643eb2d9
      James Bottomley 提交于
      The current target allocation code registeres each possible target
      with sysfs; it will be deleted again if no useable LUN on this target
      was found. This results in a string of 'target add/target remove' uevents.
      
      Based on a patch by Hannes Reinecke <hare@suse.de> this patch reworks
      the target allocation code so that only uevents for existing targets
      are sent. The sysfs registration is split off from the existing
      scsi_target_alloc() into a in a new scsi_add_target() function, which
      should be called whenever an existing target is found. Only then a
      uevent is sent, so we'll be generating events for existing targets
      only.
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      643eb2d9
  10. 20 4月, 2008 1 次提交
  11. 19 4月, 2008 2 次提交
  12. 08 4月, 2008 6 次提交
  13. 06 3月, 2008 1 次提交
  14. 24 2月, 2008 1 次提交
  15. 12 2月, 2008 1 次提交
    • J
      [SCSI] update SG_ALL to avoid causing chaining · 4660c8ed
      James Bottomley 提交于
      Since the sg chaining patches went in, our current value of 255 for
      SG_ALL excites chaining on some drivers which cannot support it (and
      would thus oops).  Redefine SG_ALL to mean no sg table size
      preference, but use the single allocation (non chained) limit.  This
      also helps for drivers that use it to size an internal table.
      
      We'll do an opt in system later where truly chaining supporting
      drivers can define their sg_tablesize to be anything up to
      SCSI_MAX_SG_CHAIN_ELEMENTS.
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      4660c8ed