1. 22 6月, 2006 1 次提交
  2. 29 10月, 2005 2 次提交
    • A
      [PATCH] PATCH: usb-storage: allocate separate sense buffer · bbafa466
      Alan Stern 提交于
      This patch is from Alan Stern (as560).  It has been rediffed against a
      current tree.
      
      This patch allocates a separate buffer for usb-storage to use when
      auto-sensing.  Up to now we have been using the sense buffer embedded in a
      scsi_cmnd struct, which is dangerous on hosts that (a) don't do
      cache-coherent DMA or (b) have DMA alignment restrictions.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NMatthew Dharm <mdharm-usb@one-eyed-alien.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      bbafa466
    • A
      [PATCH] PATCH: usb-storage: move GetMaxLUN later in time · b876aef7
      Alan Stern 提交于
      This patch is originally from Alan Stern (as557).  It has been re-diffed
      against a current tree, and I also corrected a minor merging error.
      
      Some time ago we introduced a delay before device scanning, because many
      devices do not like to receive SCSI commands right after enumeration.
      Now it turns out there's a device that doesn't like to receive
      Get-Max-LUN right after enumeration either.  Accordingly this patch
      delays the Get-Max-LUN request until the beginning of the scanning
      procedure.  This fixes Bugzilla entry #5010.
      
      Three things are worth noting.  First, I removed the locking code from
      usb_stor_acquire_resources.  It's not needed, because the locking is to
      protect against disconnect events and acquire_resources is only called
      during probe (so the disconnect routine can't be called).  Second, I
      initialized to 0 the buffer used for the Get-Max-LUN response.  It's not
      really necessary, but it will prevent random values from showing up in
      the debugging log when the request fails.  Third, I added a test against
      the SINGLE_LUN flag.  This will allow us to use the flag to indicate
      Bulk-only devices that can't handle Get-Max-LUN.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NMatthew Dharm <mdharm-usb@one-eyed-alien.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b876aef7
  3. 09 9月, 2005 2 次提交
    • A
      [PATCH] USB: URB_ASYNC_UNLINK flag removed from the kernel · b375a049
      Alan Stern 提交于
      29 July 2005, Cambridge, MA:
      
      This afternoon Alan Stern submitted a patch to remove the URB_ASYNC_UNLINK
      flag from the Linux kernel.  Mr. Stern explained, "This flag is a relic
      from an earlier, less-well-designed system.  For over a year it hasn't
      been used for anything other than printing warning messages."
      
      An anonymous spokesman for the Linux kernel development community
      commented, "This is exactly the sort of thing we see happening all the
      time.  As the kernel evolves, support for old techniques and old code can
      be jettisoned and replaced by newer, better approaches.  Proprietary
      operating systems do not have the freedom or flexibility to change so
      quickly."
      
      Mr. Stern, a staff member at Harvard University's Rowland Institute who
      works on Linux only as a hobby, noted that the patch (labelled as548) did
      not update two files, keyspan.c and option.c, in the USB drivers' "serial"
      subdirectory.  "Those files need more extensive changes," he remarked.
      "They examine the status field of several URBs at times when they're not
      supposed to.  That will need to be fixed before the URB_ASYNC_UNLINK flag
      is removed."
      
      Greg Kroah-Hartman, the kernel maintainer responsible for overseeing all
      of Linux's USB drivers, did not respond to our inquiries or return our
      calls.  His only comment was "Applied, thanks."
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b375a049
    • M
      [PATCH] USB Storage: remove dependency on SCSI-provided serial/tag number · 0f64e078
      Matthew Dharm 提交于
      This patch started life as as531 from Alan Stern.  It has been rediffed
      against the latest tree.
      
      The SCSI people have deprecated the use of scsi_cmnd.serial_number for
      anything other than printk.  Worse than that, the SCSI core doesn't
      always increment the number (when the error handler is running, for
      example).  So this patch creates a locally-stored value for use in
      bulk-only tags.  The net result is a simplification, since we no longer
      have to save & restore the serial_number value while autosensing.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NMatthew Dharm <mdharm-usb@one-eyed-alien.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0f64e078
  4. 28 6月, 2005 2 次提交
  5. 19 4月, 2005 1 次提交
    • P
      [PATCH] Fix GO_SLOW delay · e4334fa4
      Phil Dibowitz 提交于
      This patch changes the delay for the US_FL_GO_SLOW patch from 110us to 125.
      Some delays need this extra delay includign Jan De Luyck's drive which spawned
      the original increase from 110 to 110us. 125 is a microframe, so this delay
      seems to make sense more than just be a random delay (thanks to David Brownell
      for pointing that out after my original patch).
      Signed-off-by: NPhil Dibowitz <phil@ipom.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      
      Index: gregkh-2.6/drivers/usb/storage/transport.c
      ===================================================================
      e4334fa4
  6. 17 4月, 2005 1 次提交
    • 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