1. 04 11月, 2007 1 次提交
  2. 15 7月, 2007 1 次提交
  3. 20 6月, 2007 1 次提交
  4. 18 4月, 2007 1 次提交
    • M
      [SCSI] modalias for scsi devices · d7b8bcb0
      Michael Tokarev 提交于
      The following patch adds support for sysfs/uevent modalias
      attribute for scsi devices (like disks, tapes, cdroms etc),
      based on whatever current sd.c, sr.c, st.c and osst.c drivers
      supports.
      
      The modalias format is like this:
      
       scsi:type-0x04
      
      (for TYPE_WORM, handled by sr.c now).
      
      Several comments.
      
      o This hexadecimal type value is because all TYPE_XXX constants
        in include/scsi/scsi.h are given in hex, but __stringify() will
        not convert them to decimal (so it will NOT be scsi:type-4).
        Since it does not really matter in which format it is, while
        both modalias in module and modalias attribute match each other,
        I descided to go for that 0x%02x format (and added a comment in
        include/scsi/scsi.h to keep them that way), instead of changing
        them all to decimal.
      
      o There was no .uevent routine for SCSI bus.  It might be a good
        idea to add some more ueven environment variables in there.
      
      o osst.c driver handles tapes too, like st.c, but only SOME tapes.
        With this setup, hotplug scripts (or whatever is used by the
        user) will try to load both st and osst modules for all SCSI
        tapes found, because both modules have scsi:type-0x01 alias).
        It is not harmful, but one extra module is no good either.
        It is possible to solve this, by exporting more info in
        modalias attribute, including vendor and device identification
        strings, so that modalias becomes something like
          scsi:type-0x12:vendor-Adaptec LTD:device-OnStream Tape Drive
        and having that, match for all 3 attributes, not only device
        type.  But oh well, vendor and device strings may be large,
        and they do contain spaces and whatnot.
        So I left them for now, awaiting for comments first.
      Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      d7b8bcb0
  5. 21 3月, 2007 1 次提交
    • T
      [SCSI] sd: implement START/STOP management · c3c94c5a
      Tejun Heo 提交于
      Implement SBC START/STOP management.  sdev->mange_start_stop is added.
      When it's set to one, sd STOPs the device on suspend and shutdown and
      STARTs it on resume.  sdev->manage_start_stop defaults is in sdev
      instead of scsi_disk cdev to allow ->slave_config() override the
      default configuration but is exported under scsi_disk sysfs node as
      sdev->allow_restart is.
      
      When manage_start_stop is zero (the default value), this patch doesn't
      introduce any behavior change.
      Signed-off-by: NTejun Heo <htejun@gmail.com>
      
      Rejections fixed and
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      c3c94c5a
  6. 12 3月, 2007 1 次提交
  7. 17 2月, 2007 1 次提交
  8. 12 10月, 2006 1 次提交
    • M
      [SCSI] Add ability to scan scsi busses asynchronously · 3e082a91
      Matthew Wilcox 提交于
      Since it often takes around 20-30 seconds to scan a scsi bus, it's
      highly advantageous to do this in parallel with other things.  The bulk
      of this patch is ensuring that devices don't change numbering, and that
      all devices are discovered prior to trying to start init.  For those
      who build SCSI as modules, there's a new scsi_wait_scan module that will
      ensure all bus scans are finished.
      
      This patch only handles drivers which call scsi_scan_host.  Fibre Channel,
      SAS, SATA, USB and Firewire all need additional work.
      Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      3e082a91
  9. 01 10月, 2006 1 次提交
  10. 28 9月, 2006 1 次提交
  11. 20 3月, 2006 1 次提交
  12. 15 3月, 2006 1 次提交
  13. 28 2月, 2006 3 次提交
  14. 27 1月, 2006 1 次提交
    • B
      [SCSI] Prevent scsi_execute_async from guessing cdb length · bb1d1073
      brking@us.ibm.com 提交于
      When the scsi_execute_async interface was added it ended up reducing
      the flexibility of userspace to send arbitrary scsi commands through
      sg using SG_IO. The SG_IO interface allows userspace to specify the
      CDB length. This is now ignored in scsi_execute_async and it is
      guessed using the COMMAND_SIZE macro, which is not always correct,
      particularly for vendor specific commands. This patch adds a cmd_len
      parameter to the scsi_execute_async interface to allow the caller
      to specify the length of the CDB.
      Signed-off-by: NBrian King <brking@us.ibm.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      bb1d1073
  15. 15 12月, 2005 1 次提交
    • M
      [SCSI] Convert SCSI mid-layer to scsi_execute_async · 6e68af66
      Mike Christie 提交于
      Add scsi helpers to create really-large-requests and convert
      scsi-ml to scsi_execute_async().
      
      Per Jens's previous comments, I placed this function in scsi_lib.c.
      I made it follow all the queue's limits - I think I did at least :), so
      I removed the warning on the function header.
      
      I think the scsi_execute_* functions should eventually take a request_queue
      and be placed some place where the dm-multipath hw_handler can use them
      if that failover code is going to stay in the kernel. That conversion
      patch will be sent in another mail though.
      Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      6e68af66
  16. 14 12月, 2005 1 次提交
  17. 29 10月, 2005 2 次提交
  18. 26 9月, 2005 1 次提交
  19. 11 9月, 2005 1 次提交
  20. 29 8月, 2005 3 次提交
  21. 15 7月, 2005 1 次提交
  22. 14 7月, 2005 1 次提交
    • J
      [SCSI] add int_to_scsilun() function · 2f4701d8
      James.Smart@Emulex.Com 提交于
      One of the issues we had was reverting the midlayers lun value
      into the 8byte lun value that we wanted to send to the device.
      Historically, there's been some combination of byte swapping,
      setting high/low, etc. There's also been no common thread between
      how our driver did it and others.  I also got very confused as
      to why byteswap routines were being used.
      
      Anyway, this patch is a LLDD-callable function that reverts the
      midlayer's lun value, stored in an int, to the 8-byte quantity
      (note: this is not the real 8byte quantity, just the same amount
      that scsilun_to_int() was able to convert and store originally).
      
      This also solves the dilemma of the thread:
      http://marc.theaimsgroup.com/?l=linux-kernel&m=112116767118981&w=2
      
      A patch for the lpfc driver to use this function will be along
      in a few days (batched with other patches).
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      2f4701d8
  23. 26 5月, 2005 1 次提交
  24. 19 4月, 2005 1 次提交
  25. 17 4月, 2005 3 次提交
    • updates for CFQ oops fix · c2a9331c
      提交于
      - add a comment to the device structure that the device_busy field
        is now protected by the request_queue->queue_lock
      - null out sdev->request_queue after the queue is released to trap
        any (and there shouldn't be any) use after the queue is freed.
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      c2a9331c
    • [PATCH] fix NMI lockup with CFQ scheduler · 152587de
      提交于
      The current problem seen is that the queue lock is actually in the
      SCSI device structure, so when that structure is freed on device
      release, we go boom if the queue tries to access the lock again.
      
      The fix here is to move the lock from the scsi_device to the queue.
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      152587de
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4