aboutsummaryrefslogtreecommitdiff
path: root/drivers/usb/storage/transport.c
AgeCommit message (Collapse)Author
2005-10-28[PATCH] PATCH: usb-storage: allocate separate sense bufferAlan 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: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-28[PATCH] PATCH: usb-storage: move GetMaxLUN later in timeAlan 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: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-08[PATCH] USB: URB_ASYNC_UNLINK flag removed from the kernelAlan 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: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-08[PATCH] USB Storage: remove dependency on SCSI-provided serial/tag numberMatthew 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: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-06-27[PATCH] USB Storage: port reset on transport errorMatthew Dharm
This patch causes a port reset whenever there's a transport error or abort. If that fails it reverts back to doing a mass-storage device reset. It started life as as497 and was rediffed by me. This makes error recovery a lot quicker and more reliable. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-06-27[PATCH] USB Storage: endpoint toggles and reset delaysMatthew Dharm
This patch does two things to help reset recovery. It started life as as496 and was rediffed by me. First, the patch checks the result of a CLEAR_HALT request and doesn't reset the endpoint's data toggle unless the request succeeded. Second, it reduces the timeout for a device reset from 20 seconds to 5 seconds. If all goes well, then I've finally figured quilt out and this patch should apply cleanly. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-04-18[PATCH] Fix GO_SLOW delayPhil 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: Phil Dibowitz <phil@ipom.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Index: gregkh-2.6/drivers/usb/storage/transport.c ===================================================================
2005-04-16Linux-2.6.12-rc2Linus 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!