Re: [linux-usb-devel] Problem with 2GB card using USB SD card reader
Perhaps this is something that the file storage gadget can help us figure out? matt On Sun, Aug 05, 2007 at 12:59:57PM -0700, Jason LeBrun wrote: I've not yet completed Matthew Dharm's request to enable USB_STORAGE_VERBOSE_DEBUG. I'll do that today. I did zero out the partition table (and then some :-)) using dd: dd if=/dev/zero of=/dev/sdd bs=1024 count=1000 To verify, I fired up fdisk, and got this message: Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel Building a new DOS disklabel. Changes will remain in memory only, until you decide to write them. After that, of course, the previous content won't be recoverable. Warning: invalid flag 0x of partition table 4 will be corrected by w(rite) Ok, great, definitely no partition table, anymore! After closing fdisk without doing anything, I popped the card into my Windows XP machine. It instantly appears in the Disk Management applet as a healthy 1.92GB unformatted device. Cheers, Jason On 8/5/07, Sam Liddicott [EMAIL PROTECTED] wrote: H... I think Windows is using the information from the partitions to compute the size, not from the CSD. I think so. If the poster uses d and /dev/null to Ero the start of the card, and then checks how windows deals with it, we will soon know. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver We can customize our colonels. -- Tux User Friendly, 12/1/1998 pgpmf7yJjS0Oa.pgp Description: PGP signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Problem with 2GB card using USB SD card reader
Can you do the following: 1) Dump the partition table with fdisk, and send it to us 2) Turn on USB_STORAGE_VERBOSE_DEBUG, capture the log from inserting the card and capacity scan, and send it to us Matt On Sat, Aug 04, 2007 at 12:10:07PM -0700, Jason LeBrun wrote: Hi there, I'm using a Kingston 2.0GB SD card with a unbranded card reader (model number UCR-61). When I insert the card, it's detected as device using 512-byte sector sizes, and therefore it only shows up with about 1GB. I've poked around the mailing list, and I've found that a few other people have mentioned this problem, and the responses to date seems to imply that it's a hardware combination problem rather than a driver problem. http://marc.info/?l=linux-usb-develm=117043511923949w=2 I understand that one of the issues is that certain readers can not properly handle 1024-byte block sizes, but I don't think this is the case here. If I use the same reader-card combination on a Windows machine, the card is recognized as a 2GB device. The device uses usb-storage and libusual modules. Just wanted to report this behavior, that's all! - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver NYET! The evil stops here! -- Pitr User Friendly, 6/22/1998 pgpAr8FTsyQ1T.pgp Description: PGP signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Large USB storage devices cause df to hang and cpu load reaches 100%
It would be interesting to turn on CONFIG_USB_STORAGE_DEBUG and capture the debugging output. Matt On Tue, Jul 31, 2007 at 08:37:31PM +0100, Kostas Peletidis wrote: Matthew Dharm wrote: Did you change any USB-related compile options between the two builds? Do you have usb device suspend enabled? Can you tell (via top) where the 100% CPU usage is coming from (i.e. df, usb-storage thread, syswait, etc)? Matt Hi Matt, The most relevant USB configuration option I changed seems to be CONFIG_USB_DEVICE_CLASS=y. I have also added module support for CONFIG_USB_USBNET but I don't think this is related. Please find attached the kernel configuration. USB suspend is disabled (# CONFIG_USB_SUSPEND is not set) and when I run top and press Shift+P I see that df is at the top of the list, followed by Xorg and usb-storage. The load average reaches 1.17. Interestingly enough, when df is at the top of the list I see roughly 90%wa which I presume means the CPU spends most of the time waiting. Here are the times derived from time df: real1m4.612s user0m0.006s sys 0m2.867s It is worth mentioning that the problem happens only the first time I run df. Subsequent runs of df work normally. If I unmount the disk and remount it I see the same problem. Regards, Kostas - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver NYET! The evil stops here! -- Pitr User Friendly, 6/22/1998 pgpt1Fk7SqFOo.pgp Description: PGP signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Large USB storage devices cause df to hang and cpu load reaches 100%
What the heck happened to your logs? It looks like about 75% of the data is being lost from the log file... Matt On Tue, Jul 31, 2007 at 10:47:40PM +0100, Kostas Peletidis wrote: Matthew Dharm wrote: It would be interesting to turn on CONFIG_USB_STORAGE_DEBUG and capture the debugging output. Matt On Tue, Jul 31, 2007 at 08:37:31PM +0100, Kostas Peletidis wrote: Matthew Dharm wrote: Did you change any USB-related compile options between the two builds? Do you have usb device suspend enabled? Can you tell (via top) where the 100% CPU usage is coming from (i.e. df, usb-storage thread, syswait, etc)? Matt Hi Matt, The most relevant USB configuration option I changed seems to be CONFIG_USB_DEVICE_CLASS=y. I have also added module support for CONFIG_USB_USBNET but I don't think this is related. Please find attached the kernel configuration. USB suspend is disabled (# CONFIG_USB_SUSPEND is not set) and when I run top and press Shift+P I see that df is at the top of the list, followed by Xorg and usb-storage. The load average reaches 1.17. Interestingly enough, when df is at the top of the list I see roughly 90%wa which I presume means the CPU spends most of the time waiting. Here are the times derived from time df: real1m4.612s user0m0.006s sys 0m2.867s It is worth mentioning that the problem happens only the first time I run df. Subsequent runs of df work normally. If I unmount the disk and remount it I see the same problem. Regards, Kostas - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel I enabled usb storage debugging and now I get a lot of messages. It seems to me that part of the traced information is lost e.g. there is a message kernel: [ 125.105000] usb-stora transfer result 0x0 which seems to have some characters missing. I noticed that now top shows roughly 33%us and 67%sy usage(no waiting percentage this time, however the problem is still there) probably because the debugging code uses a lot of cpu time.Apart from that I see quite a lot of usb-storage: Attempting to get CSW... messages. I don't know what to look for so perhaps I missed some more important messages. Can you please have a look at the attached file? Thank you. Regards, Kostas - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver NYET! The evil stops here! -- Pitr User Friendly, 6/22/1998 pgpTVhJ0h4UJi.pgp Description: PGP signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Large USB storage devices cause df to hang and cpu load reaches 100%
Did you change any USB-related compile options between the two builds? Do you have usb device suspend enabled? Can you tell (via top) where the 100% CPU usage is coming from (i.e. df, usb-storage thread, syswait, etc)? Matt On Mon, Jul 30, 2007 at 11:24:27PM +0100, Kostas Peletidis wrote: Hi all, I would like to report a problem I have noticed since linux-2.6.22 that most likely has to do with the USB subsystem. I have tried both kernel versions 2.6.22 and 2.6.22.1(configured with make oldconfig) and in both cases whenever I plug in a fairly large(500GB) MyBook usb2 hard disk df stops producing output and hangs for about a minute when it reaches the usb disk. Interestingly enough the disk's directory tree can be accessed immediately. It is only df and Thunar, the xfce window manager, that slow down. During this temporary hang the cpu load fluctuates and reaches 100% several times. When I plugged in a small(512MB) usb2 memory stick, instead of the disk, df paused only momentarily before terminating normally. This suggests to me that the size of the device affects the duration of the delay. The modules I use, apart from usb_storage, are ehci_hcd and uhci_hcd. With linux-2.6.21.5 both usb devices work fine. I don't know how to proceed from here. Please let me know if you need additional information or if I need to contact someone else. Thank you. Regards, Kostas Peletidis - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver NYET! The evil stops here! -- Pitr User Friendly, 6/22/1998 pgplDFveOan22.pgp Description: PGP signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2.6 patch] usbat_check_status(): fix check-after-use
Signed-off-by: Matthew Dharm [EMAIL PROTECTED] On Tue, Jul 31, 2007 at 12:28:22AM +0200, Adrian Bunk wrote: The Coverity checker spotted that we have already oops'ed if us was NULL. Since us can't be NULL in the only caller this patch removes the NULL check. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- --- linux-2.6.23-rc1-mm1/drivers/usb/storage/shuttle_usbat.c.old 2007-07-30 16:56:34.0 +0200 +++ linux-2.6.23-rc1-mm1/drivers/usb/storage/shuttle_usbat.c 2007-07-30 16:57:24.0 +0200 @@ -190,9 +190,6 @@ static int usbat_check_status(struct us_ unsigned char *reply = us-iobuf; int rc; - if (!us) - return USB_STOR_TRANSPORT_ERROR; - rc = usbat_get_status(us, reply); if (rc != USB_STOR_XFER_GOOD) return USB_STOR_TRANSPORT_FAILED; -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I need a computer? -- Customer User Friendly, 2/19/1998 pgpHpMPUGq6Yf.pgp Description: PGP signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] patch to shift memory allocations to usb_alloc_urb()
On Mon, Jul 02, 2007 at 10:34:18AM -0400, Alan Stern wrote: In theory we could stream the commands and statuses as well, which would reduce the overhead somewhat. Doing this would complicate usb-storage a fair amount, and it wouldn't be surprising if a lot of devices couldn't handle the higher rates, so I'm not in favor. (Sorry, I just got back from vacation...) Streaming commands/data/status together is a bad idea. I used to get e-mail pretty regularly from people who were trying this, only to discover that the devices couldn't handle it. Technically, it's spec-legal. Practically, it's a dead duck. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I'm just trying to think of a way to say up yours without getting fired. -- Stef User Friendly, 10/8/1998 pgpwVrpNx4UGZ.pgp Description: PGP signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] patch to shift memory allocations to usb_alloc_urb()
On Mon, Jul 02, 2007 at 09:15:03AM +0200, Oliver Neukum wrote: Am Montag, 2. Juli 2007 schrieb Alan Stern: If you look at usbmon logs of real usb-storage data transfers you'll see that multi-page sg elements occur quite frequently. (Of course, that doesn't prevent us from transferring only one page per URB.) OK, but the storage driver allocates the URBs on the fly. If we change that to preallocation we need to have enough URBs for the worst case. Of course, in the storage case we control the worst-case. By adjusting the parameter which controls how long a sg list the SCSI core will send us, we can effectively limit the worst-case number of URBs needed. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I want my GPFs!!! -- Stef User Friendly, 11/9/1998 pgphApX1ILhNk.pgp Description: PGP signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] patch to shift memory allocations to usb_alloc_urb()
On Thu, Jul 05, 2007 at 04:57:53PM -0400, Alan Stern wrote: On Thu, 5 Jul 2007, Matthew Dharm wrote: On Mon, Jul 02, 2007 at 09:15:03AM +0200, Oliver Neukum wrote: Am Montag, 2. Juli 2007 schrieb Alan Stern: If you look at usbmon logs of real usb-storage data transfers you'll see that multi-page sg elements occur quite frequently. (Of course, that doesn't prevent us from transferring only one page per URB.) OK, but the storage driver allocates the URBs on the fly. If we change that to preallocation we need to have enough URBs for the worst case. Of course, in the storage case we control the worst-case. By adjusting the parameter which controls how long a sg list the SCSI core will send us, we can effectively limit the worst-case number of URBs needed. But we don't control max_sectors, so we can't effectively limit the total transfer size. While I agree that it would be nice to preallocate enough URBs and memory that only one IRQ would be needed, I don't see anything wrong with preallocating a reasonably large amount and re-using it as needed. So we might get 3 or 4 times as many IRQs for particularly large transfers; that doesn't seem too bad. It's a justifiable time-space tradeoff. A reasonably large amount might be enough for a 32 KB transfer at full speed or a 120 KB transfer (the default maximum) at high speed. Or we might want to take into account the actual storage requirements of the HCDs; UHCI is much the worst in that regard. After digging out from all the vacation e-mail, I'm relatively convinced that just about anything discussed would be better than what we have now. If that's a fallback to a single pre-allocated URB, or a pre-allocated small pool of URBs, or a pre-allocated large pool of URBs, it's all better. Right now, we just choke in OOM situations. And that's just horrific. I'm guessing that the best thing to do now would be to implement the fallback to one URB at a time algorithm in a -ENOMEM situation. That's going to provide awful performance in OOM conditions, but at least it won't crash. If it's done with some forward-looking to a pool approach (i.e. a pool of size = 1), then playing with pools of size 1, 5, or 500 would be something we could experiment with. Once we have something like that in place, it will probably be easier to look at the space/time tradeoffs in more real terms. Eventually, that tradeoff will probably be an adjustable constant (parameter?) which will be relatively large for desktop/server users, and easily turned to something small for embedded systems. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver But where are the THEMES?! How do you expect me to use an OS without themes?! -- Stef User Friendly, 10/9/1998 pgpC65rTqnkh5.pgp Description: PGP signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] patch to shift memory allocations to usb_alloc_urb()
On Sun, Jul 01, 2007 at 11:00:43AM +0200, Oliver Neukum wrote: My goals are: - guarantee the storage driver a fallback path without memory allocation What about avoiding allocation of memory during a usb-storage transfer completely? Does anyone know if the SCSI core actually follows the sg_tablesize parameter in the struct scsi_host_template ? Right now, it's set to SG_ALL, which means unlimited number of sg elements, but any other non-zero value is supposed to be the maximum number of segments that the SCSI core sends to usb-storage. If it does, then we could advertise some maximum sg list size in that. We could then use that same limit to pre-allocate all the URBs that usb_sg_init would need. Thus, we wouldn't need a fallback path without memory allocation. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver God, root, what is difference? -- Pitr User Friendly, 11/11/1999 pgp0D0VszC68w.pgp Description: PGP signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Active Huawei E220 devs
On Tue, Jun 26, 2007 at 04:06:38PM +0800, linlei 60022748 wrote: diff -urN -X linux-2.6.21.1-vanilla/Documentation/dontdiff linux-2.6.21.1-vanilla/drivers/usb/storage/initializers.h linux-2.6.21.1/drivers/usb/storage/initializers.h --- linux-2.6.21.1-vanilla/drivers/usb/storage/initializers.h 2007-04-28 05:49:26.0 +0800 +++ linux-2.6.21.1/drivers/usb/storage/initializers.h 2007-06-25 23:01:18.0 +0800 @@ -47,3 +47,6 @@ /* This function is required to activate all four slots on the UCR-61S2B * flash reader */ int usb_stor_ucr61s2b_init(struct us_data *us); + +/* This places the HUAWEI E220 devices in multi-port mode */ +int usb_stor_switch_ports_init(struct us_data *us); Generally, these functions are named to refer to the devices they are used for (i.e. the ucr61s2b in the previous function). diff -urN -X linux-2.6.21.1-vanilla/Documentation/dontdiff linux-2.6.21.1-vanilla/drivers/usb/storage/unusual_devs.h linux-2.6.21.1/drivers/usb/storage/unusual_devs.h --- linux-2.6.21.1-vanilla/drivers/usb/storage/unusual_devs.h 2007-04-28 05:49:26.0 +0800 +++ linux-2.6.21.1/drivers/usb/storage/unusual_devs.h 2007-06-25 23:01:18.0 +0800 @@ -1371,14 +1371,15 @@ US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_IGNORE_RESIDUE ), -/* This prevents the kernel from detecting the virtual cd-drive with the - * Windows drivers. [EMAIL PROTECTED] +/* This tells the usb driver to place the HUAWEI E220 devices into multi-port mode + * Reported by fangxiaozhi [EMAIL PROTECTED] + * and by linlei [EMAIL PROTECTED] */ -UNUSUAL_DEV( 0x12d1, 0x1003, 0x, 0x, +UNUSUAL_DEV( 0x12d1, 0x1003, 0x, 0x, Do you really want a device range from 0 to 0? Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver M: No, Windows doesn't have any nag screens. C: Then what are those blue and white screens I get every day? -- Mike and Cobb User Friendly, 1/4/1999 pgphYigwkoP90.pgp Description: PGP signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] ehci memory allocation question
On Fri, Jun 15, 2007 at 04:08:57PM +0200, Oliver Neukum wrote: Am Freitag, 15. Juni 2007 schrieb Alan Stern: But you're much better off avoiding partially executed requests if you can avoid it. It would be preferable to transmit the data one packet at a time: slower but more likely to succeed. Why is that better? The problem is unlikely to be unique to USB and should therefore be handled in common code if possible. Actually, it seems that the opposite is true. The SCSI layer seems to make some implicit assumptions that HCDs generally pre-allocate their overhead memory. I'm pretty sure the sbp2 folks (SCSI over IEEE1394) had to go through a similar exercise to what we're doing now in order to make it robust. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 pgpO2YJLt1Rxu.pgp Description: PGP signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Onetouch - switch to using input_dev-dev.parent
I won't pretend to know anything about the input subsystem. But, from a
storage point of view, this looks fine.
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
Matt
On Tue, May 08, 2007 at 12:31:30AM -0400, Dmitry Torokhov wrote:
In preparation for struct class_device - struct device input
core conversion, switch to using input_dev-dev.parent when
specifying device position in sysfs tree.
Also, do not access input_dev-private directly, use helpers.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/usb/storage/onetouch.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
Index: work/drivers/usb/storage/onetouch.c
===
--- work.orig/drivers/usb/storage/onetouch.c
+++ work/drivers/usb/storage/onetouch.c
@@ -84,7 +84,7 @@ resubmit:
static int usb_onetouch_open(struct input_dev *dev)
{
- struct usb_onetouch *onetouch = dev-private;
+ struct usb_onetouch *onetouch = input_get_drvdata(dev);
onetouch-is_open = 1;
onetouch-irq-dev = onetouch-udev;
@@ -98,7 +98,7 @@ static int usb_onetouch_open(struct inpu
static void usb_onetouch_close(struct input_dev *dev)
{
- struct usb_onetouch *onetouch = dev-private;
+ struct usb_onetouch *onetouch = input_get_drvdata(dev);
usb_kill_urb(onetouch-irq);
onetouch-is_open = 0;
@@ -185,13 +185,14 @@ int onetouch_connect_input(struct us_dat
input_dev-name = onetouch-name;
input_dev-phys = onetouch-phys;
usb_to_input_id(udev, input_dev-id);
- input_dev-cdev.dev = udev-dev;
+ input_dev-dev.parent = udev-dev;
set_bit(EV_KEY, input_dev-evbit);
set_bit(ONETOUCH_BUTTON, input_dev-keybit);
clear_bit(0, input_dev-keybit);
- input_dev-private = onetouch;
+ input_set_drvdata(input_dev, onetouch);
+
input_dev-open = usb_onetouch_open;
input_dev-close = usb_onetouch_close;
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
P: How about Web Designer?
DP: I'd like a name that people won't laugh at.
-- Pitr and Dust Puppy
User Friendly, 12/6/1997
pgpoLpPPkRC4Z.pgp
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Problem with Sony USB card reader
Can you use fdisk to read the partition table of the card in either case? Matt On Wed, Apr 11, 2007 at 10:00:33PM +0100, [EMAIL PROTECTED] wrote: I have a VGP-MCA20 Memory Card Adapter that fits in the ExpressCard slot of a Vaio SZ3. When I insert a 1GB SD card into the adapter, it is not detected correctly, whereas it does work in a Shuttle card reader attached to an SN41G. Here are the messages when the adapter is inserted: usb 5-4: new high speed USB device using ehci_hcd and address 6 usb 5-4: configuration #1 chosen from 1 choice scsi3 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 6 usb-storage: waiting for device to settle before scanning scsi 3:0:0:0: Direct-Access Sony USB HS-CARD4.52 PQ: 0 ANSI: 0 sd 3:0:0:0: Attached scsi removable disk sdb sd 3:0:0:0: Attached scsi generic sg1 type 0 usb-storage: device scan complete /sbin/lspci: 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02) 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02) 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 02) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02) 06:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) 07:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8036 PCI-E Fast Ethernet Controller (rev 15) 09:04.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller 09:04.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller 09:04.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD) /sbin/lsusb: Bus 001 Device 001: ID : Bus 003 Device 001: ID : Bus 003 Device 002: ID 0483:2016 SGS Thomson Microelectronics Fingerprint Reader Bus 005 Device 006: ID 054c:0281 Sony Corp. Bus 005 Device 001: ID : Bus 005 Device 004: ID 05ca:1830 Ricoh Co., Ltd Bus 004 Device 002: ID 044e:300c Alps Electric Co., Ltd Bus 004 Device 001: ID : Bus 002 Device 001: ID : These are the messages when the SD card is inserted: Apr 9 23:21:04 morel kernel: SCSI device sdb: 1984000 512-byte hdwr sectors (1016 MB) Apr 9 23:21:04 morel kernel: sdb: Write Protect is off Apr 9 23:21:04 morel kernel: sdb: assuming drive cache: write through Apr 9 23:21:04 morel kernel: SCSI device sdb: 1984000 512-byte hdwr sectors (1016 MB) Apr 9 23:21:04 morel kernel: sdb: Write Protect is off Apr 9 23:21:04 morel kernel: sdb: assuming drive cache: write through Apr 9 23:21:10 morel kernel: sdb:6sdb: Current: sense key: No Sense Apr 9 23:21:10 morel kernel: Additional sense: No additional sense information Apr 9 23:21:16 morel kernel: sdb: Current: sense key: No Sense Apr 9 23:21:16 morel kernel: Additional sense: No additional sense information Apr 9 23:21:16 morel kernel: unknown partition table Apr 9 23:21:22 morel kernel: sdb: Current: sense key: No Sense Apr 9 23:21:22 morel kernel: Additional sense: No additional sense information Apr 9 23:21:28 morel kernel: sdb: Current: sense key: No Sense Apr 9 23:21:28 morel kernel: Additional sense: No additional sense information Adam -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver S: Another stupid question? G: There's no such thing as a stupid question, only stupid people. -- Stef and Greg User Friendly
Re: [linux-usb-devel] Problem with Sony USB card reader
On Thu, Apr 12, 2007 at 12:49:29AM +0100, [EMAIL PROTECTED] wrote: It doesn't work with the Sony reader. Having said that, testing it just now I found it was detected if I removed and reinserted the card reader. Something strange going on... Sounds like a bug in the card reader firmware. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Sir, for the hundreth time, we do NOT carry 600-round boxes of belt-fed suction darts! -- Salesperson to Greg User Friendly, 12/30/1997 pgpg114Cjpwas.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [usb-storage] Again about UFI with one LUN
On Thu, Jan 04, 2007 at 04:01:19PM -0800, Pete Zaitcev wrote: But it seems that I found a case when this does not work. It happens with Sun's virtual floppy, which returns a seemingly normal INQUIRY data (this is CBI, LUN set to 1, and device simply ignores it, most likely): 81003f5575c0 1779789944 S Co:004:00 s 21 00 000c 12 = 1220 2400 81003f5575c0 1779792226 C Co:004:00 0 12 8100374c2980 1779792240 S Bi:004:01 -115 36 8100374c2980 1779795215 C Bi:004:01 0 36 = 0081 1f00 414d4920 20202020 56697274 75616c20 466c6f70 70792020 81003f5575c0 1779795226 S Ii:004:03 -115 2 81003f5575c0 1779821221 C Ii:004:03 0 2 = What exactly happens? I would assume that an error response to an INQUIRY for LUN 1 would Do the Right Thing. So this got me wondering, why do we use such curiously complicated way of trimming LUNs instead of something like this: --- linux-2.6.18-1.2769.el5/drivers/usb/storage/usb.c 2006-09-19 20:42:06.0 -0700 +++ linux-2.6.18-1.2769.el5-ufi/drivers/usb/storage/usb.c 2007-01-03 17:57:24.0 -0800 @@ -692,6 +692,7 @@ static int get_protocol(struct us_data * case US_SC_UFI: us-protocol_name = Uniform Floppy Interface (UFI); us-proto_handler = usb_stor_ufi_command; + us-max_lun = 0; break; #ifdef CONFIG_USB_STORAGE_ISD200 I verified this to work and solve my problem, whereas backporting the code from 2.6.20-rc2 did not work. Have anyone ever seen a multi-headed USB floppy? I've seen floppy/CF and floppy/CD-ROM combinations on multiple LUNs. I've gotten e-mail from people with multiple-head floppies. I've never seen one, personally. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Your lips are twitching. You're playing Quake aren't you. -- Stef to Greg User Friendly, 8/11/1998 pgpQ8PqoQWL8s.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Problem Ejecting iPod
The whole wait a few minutes thing bothers me. I wonder if you have something like hald running in the background which is causing the problems. Can you repeat the test in single user mode? Matt On Wed, Dec 27, 2006 at 09:09:21PM -0500, Carlos Moffat wrote: On Wed, 2006-12-27 at 17:55 -0800, Matthew Dharm wrote: Please clarify -- Are you saying that this sequence generates and error: 1) Attach iPod 2) eject /dev/sda Whereas this one does NOT generate errors: 1) Attach iPod 2) fdisk -l 3) eject /dev/sda Matt That's it. In either situation, though, if I eject right after attaching the ipod, eject works. If I wait a few minutes, the first situation generates an error. Cheers, Carlos On Wed, Dec 27, 2006 at 08:07:28PM -0500, Carlos Moffat wrote: Hi, I'm seeing an strange problem when trying to eject my ipod. To try to isolate the problem, I've done the following in single-mode and with USB_STORAGE_DEBUG (dmesg attached). I couldn't figure out how to start the logging, so the attached is the latest output I got. Anyways, I'm trying to simply connect the iPod and then eject it, without even mounting it. When I connect it, it correctly shows up in /dev/sda1 and /dev/sda2 (the second being the important one). If I do: eject /dev/sda immediately, or within a minute or so, the iPod is ejected correctly (at least it thinks so :) ). If I wait a few minutes, a get 4 or so usb 4-4: reset high speed USB device using ehci_hcd and address 4 before sd 2:0:0:0: scsi: Device offlined - not ready after error recovery Now, if after waiting a few minutes, I don't do eject immediately but instead do 'fdisk -l' first, the iPod is ejected properly. Any ideas? Thanks, Carlos usb-storage: queuecommand called usb-storage: *** thread awakened. usb-storage: Command TEST_UNIT_READY (6 bytes) usb-storage: 00 00 00 00 00 00 usb-storage: Bulk Command S 0x43425355 T 0x42 L 0 F 0 Trg 0 LUN 0 CL 6 usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes usb-storage: Status code 0; transferred 31/31 usb-storage: -- transfer complete usb-storage: Bulk command transfer result=0 usb-storage: Attempting to get CSW... usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes usb-storage: Status code 0; transferred 13/13 usb-storage: -- transfer complete usb-storage: Bulk status result = 0 usb-storage: Bulk Status S 0x53425355 T 0x42 R 0 Stat 0x0 usb-storage: scsi cmd done, result=0x0 usb-storage: *** thread sleeping. usb-storage: queuecommand called usb-storage: *** thread awakened. usb-storage: Command ALLOW_MEDIUM_REMOVAL (6 bytes) usb-storage: 1e 00 00 00 01 00 usb-storage: Bulk Command S 0x43425355 T 0x43 L 0 F 0 Trg 0 LUN 0 CL 6 usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes usb-storage: Status code 0; transferred 31/31 usb-storage: -- transfer complete usb-storage: Bulk command transfer result=0 usb-storage: Attempting to get CSW... usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes usb-storage: Status code 0; transferred 13/13 usb-storage: -- transfer complete usb-storage: Bulk status result = 0 usb-storage: Bulk Status S 0x53425355 T 0x43 R 0 Stat 0x0 usb-storage: scsi cmd done, result=0x0 usb-storage: *** thread sleeping. usb-storage: queuecommand called usb-storage: *** thread awakened. usb-storage: Command START_STOP (6 bytes) usb-storage: 1b 00 00 00 02 00 usb-storage: Bulk Command S 0x43425355 T 0x44 L 0 F 0 Trg 0 LUN 0 CL 6 usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes usb-storage: Status code 0; transferred 31/31 usb-storage: -- transfer complete usb-storage: Bulk command transfer result=0 usb-storage: Attempting to get CSW... usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes usb-storage: Status code 0; transferred 13/13 usb-storage: -- transfer complete usb-storage: Bulk status result = 0 usb-storage: Bulk Status S 0x53425355 T 0x44 R 0 Stat 0x1 usb-storage: -- transport indicates command failure usb-storage: Issuing auto-REQUEST_SENSE usb-storage: Bulk Command S 0x43425355 T 0x45 L 18 F 128 Trg 0 LUN 0 CL 6 usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes usb-storage: Status code 0; transferred 31/31 usb-storage: -- transfer complete usb-storage: Bulk command transfer result=0 usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes usb-storage: Status code 0; transferred 18/18 usb-storage: -- transfer complete usb-storage: Bulk data transfer result 0x0 usb-storage: Attempting to get CSW... usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes usb-storage: Status code 0; transferred 13/13 usb-storage: -- transfer complete usb-storage: Bulk status result = 0 usb-storage: Bulk Status S 0x53425355 T 0x45 R 0 Stat 0x0 usb-storage: -- Result from auto-sense
Re: [linux-usb-devel] usb 4-3: usb_sg_cancel, unlink -- -19
) Dec 27 07:51:21 eggnog kernel: sda: Write Protect is off Dec 27 07:51:21 eggnog kernel: sda: Mode Sense: 68 00 00 08 Dec 27 07:51:21 eggnog kernel: sda: assuming drive cache: write through Dec 27 07:51:21 eggnog kernel: sda: sda1 sda2 Dec 27 07:51:21 eggnog kernel: sd 0:0:0:0: Attached scsi removable disk sda Dec 27 08:06:42 eggnog kernel: usb 4-3: USB disconnect, address 3 Dec 27 08:07:12 eggnog kernel: usb 4-3: usb_sg_cancel, unlink -- -19 Dec 27 08:07:12 eggnog last message repeated 22 times My other USB device is an APC UPS, which has been connected without incident for a few weeks now. Contents of /proc/interrupts: CPU0 0: 817401XT-PIC-XTtimer 1: 8429XT-PIC-XTi8042 2: 0XT-PIC-XTcascade 5: 111834XT-PIC-XTehci_hcd:usb4 6: 3XT-PIC-XTfloppy 7: 6626XT-PIC-XTuhci_hcd:usb2 8: 4XT-PIC-XTrtc 9: 0XT-PIC-XTacpi 10: 12636XT-PIC-XTuhci_hcd:usb3, VIA8233 11: 201540XT-PIC-XTuhci_hcd:usb1, eth0, fglrx 12: 49584XT-PIC-XTi8042 14: 72597XT-PIC-XTide0 15: 31XT-PIC-XTide1 NMI: 0 LOC: 0 ERR: 0 MIS: 0 Would enabling USB debugging be a smart thing to do with all of this i/o going on? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver M: No, Windows doesn't have any nag screens. C: Then what are those blue and white screens I get every day? -- Mike and Cobb User Friendly, 1/4/1999 pgp1e4ldB4s1o.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Problem Ejecting iPod
://lists.sourceforge.net/lists/listinfo/linux-usb-devel -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver How would you like this tie wrapped around your hairy round head? -- Greg User Friendly, 9/2/1998 pgpPFq0xBXEB3.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usb-storage: fix Kconfig comments
Do we want to make those comments depend on USB !USB_STORAGE ? Matt On Tue, Dec 05, 2006 at 08:04:44PM -0800, Randy Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] USB_STORAGE was changed from select SCSI to depends on SCSI at some point, so change the comment text to match that. Also make comments depend on USB so that they are all presented or not presented. Make all comments fit in an 80-column term for menuconfig. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- drivers/usb/storage/Kconfig |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) --- linux-2.6.19-git7.orig/drivers/usb/storage/Kconfig +++ linux-2.6.19-git7/drivers/usb/storage/Kconfig @@ -2,8 +2,11 @@ # USB Storage driver configuration # -comment NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' -comment may also be needed; see USB_STORAGE Help for more information +comment NOTE: USB_STORAGE requires SCSI support; + depends on USB +comment 'SCSI disk support' may also be needed; + depends on USB +comment see USB_STORAGE Help for more information depends on USB config USB_STORAGE --- -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver But where are the THEMES?! How do you expect me to use an OS without themes?! -- Stef User Friendly, 10/9/1998 pgp28pVUwtlKf.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usb-storage: fix Kconfig comments
Looks good to me. Matt Signed-off-by: Matthew Dharm [EMAIL PROTECTED] On Wed, Dec 06, 2006 at 12:47:18PM -0800, Randy Dunlap wrote: On Wed, 6 Dec 2006 10:14:41 -0800 Matthew Dharm wrote: Do we want to make those comments depend on USB !USB_STORAGE ? I don't think that it matters very much, but I changed tested it anyway. --- From: Randy Dunlap [EMAIL PROTECTED] USB_STORAGE was changed from select SCSI to depends on SCSI at some point, so change the comment text to match that. Also make comments depend on USB so that they are all presented or not presented. Make all comments fit in an 80-column term for menuconfig. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- drivers/usb/storage/Kconfig |9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- linux-2.6.19-git7.orig/drivers/usb/storage/Kconfig +++ linux-2.6.19-git7/drivers/usb/storage/Kconfig @@ -2,9 +2,12 @@ # USB Storage driver configuration # -comment NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' -comment may also be needed; see USB_STORAGE Help for more information - depends on USB +comment NOTE: USB_STORAGE requires SCSI support; + depends on USB USB_STORAGE=n +comment + 'SCSI disk support' may also be needed; + depends on USB USB_STORAGE=n +comment + see USB_STORAGE Help for more information + depends on USB USB_STORAGE=n config USB_STORAGE tristate USB Mass Storage support -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Okay, this isn't funny anymore! Let me down! I'll tell Bill on you!! -- Microsoft Salesman User Friendly, 4/1/1998 pgpSFGq3UHf1M.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Fw: garbled usb storage scsi vendor model in 2.6.19-rc1
On Tue, Oct 24, 2006 at 02:43:22PM -0700, Phil Dibowitz wrote: Alan Stern wrote: There's a comment about this in the source code, asking what should be done if the INQUIRY response is too short (as it is here). Maybe the best approach would be always to assume the first 36 bytes are valid, even when the device says they aren't. It ought to solve your problem, and it's no worse than what we're doing now. The patch is below. This replaces the patch I sent earlier. Perhaps a better approach might be to set the product and vendor to some specific string if the device says it isn't providing one? In the new model, can't we still have the chance of showing garbage if the device really isn't setting anything useful? So what if we show Unknown and Unknown or something similar in the event that the device sets the 'invalid' bit? US_FL_FIX_INQUIRY used to do this; I don't remember what it does currently. Regardless, the SCSI core should probably blank those data buffers before deciding if any data is going to be copied into them. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver C: Like the Furby? DP: He gives me the creeps. Think the SPCA will take him? -- Cobb and Dust Puppy User Friendly, 1/2/1999 pgpEVE3wpvzjl.pgp Description: PGP signature - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Mitsumi USB FDD 061M: UNUSUAL_DEV multilun fix
On Sun, Oct 08, 2006 at 12:14:17PM -0700, Pete Zaitcev wrote: On Sun, 8 Oct 2006 21:03:49 +0200, Tobias Lorenz [EMAIL PROTECTED] wrote: this fixes multiple lun detection on the new Mitsumi USB Floppy drive. This looks good, but whatever has happened to making all devices with UFI-protocol to report 1 LUN? I checked 2.6.18, and that code doesn't seem to be present. In the absense of it, the patch looks good (only in the future please make it with -p1 nesting, Tobias) I think the code to support UFI's mechanism for indicating LUN not present is pending merge right now. I believe I saw it go into Greg's tree. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I need a computer? -- Customer User Friendly, 2/19/1998 pgpFIbLWLwQiG.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [Linux-usb-users] USB Mass storage copy giving resets
On Sun, Sep 24, 2006 at 10:01:39AM +0530, Rupesh Kumar wrote: It is possible that an earlier error in the device left the bulk-in endpoint in a STALL condition (which is persistent). What was the result of last transaction to the bulk-in endpoint before this exchange you describe below? Matt Thanks for the response. There were BULK IN Transactions followed by a CSW Status which was proper. Is it necessary to ask CSW after STALL Why cant we expect Data after sending the Clear Feature. The specification is clear on this point. The STALL indicates an error on a transfer with data-in, and the device is required to give a CSW after the Clear Feature. The device is clearly broken. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver THEY CASTRATED MY QUAKE BITS! I WANT THEM BACK -- Greg User Friendly, 3/27/1998 pgpi8AzrRxU6I.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB Mass storage copy giving resets
This sounds like the device is getting out of sync (commonly known as phase error). The host sent a command, but the device was not prepared to send data at the proper time, and indicated an error with a STALL. The proper response to a STALL at this point is to attempt to retrieve status, which is what happens. However, the device responds with data (not status). It is possible that an earlier error in the device left the bulk-in endpoint in a STALL condition (which is persistent). What was the result of last transaction to the bulk-in endpoint before this exchange you describe below? Matt On Sun, Sep 24, 2006 at 01:11:36AM +0530, Rupesh Kumar wrote: Hi All, I am having an embedded EHCI USB host controller on which i am using linux-2.6.14 When i am doing bulk file copys between many devices i am facing the following problem. The following scenario is observed on the USB BUS Analyzer. 1. Bulk Out Transaction with (31 Bytes USBC Command) for some endpoint. I am requesting 4K Data from device. 2. Then There are lot of Bulk IN/ Bulk OUTs to some other endpoints(Other Devices). 3. Then When i am giving a IN to the first end point (For which we transmitted a BULK OUT 31 Bytes) device is responding with a STALL.. 4. After Clearing the HALT On the endpoint. with a clear feature command 5. Then driver is asking for the CSW Status for which the device is responding with 512 Bytes of Data. This is Causing a BABBLE Error (Expecting 13 Bytes of CSW but the device responded with 512 bytes). Then the driver is issuing RESET to the device. Is it an acceptable condition. who is the culprit for the RESET. Regards Kumar. -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver G: Let me guess, you started on the 'net with AOL, right? C: WOW! d00d! U r leet! -- Greg and Customer User Friendly, 2/12/1999 pgppiOGAEO7yl.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB Mass storage copy giving resets
I forgot to mention -- once a phase error is detected, the USB specification requires the host to issue a RESET to the device. Matt On Sat, Sep 23, 2006 at 02:53:05PM -0700, Matthew Dharm wrote: This sounds like the device is getting out of sync (commonly known as phase error). The host sent a command, but the device was not prepared to send data at the proper time, and indicated an error with a STALL. The proper response to a STALL at this point is to attempt to retrieve status, which is what happens. However, the device responds with data (not status). It is possible that an earlier error in the device left the bulk-in endpoint in a STALL condition (which is persistent). What was the result of last transaction to the bulk-in endpoint before this exchange you describe below? Matt On Sun, Sep 24, 2006 at 01:11:36AM +0530, Rupesh Kumar wrote: Hi All, I am having an embedded EHCI USB host controller on which i am using linux-2.6.14 When i am doing bulk file copys between many devices i am facing the following problem. The following scenario is observed on the USB BUS Analyzer. 1. Bulk Out Transaction with (31 Bytes USBC Command) for some endpoint. I am requesting 4K Data from device. 2. Then There are lot of Bulk IN/ Bulk OUTs to some other endpoints(Other Devices). 3. Then When i am giving a IN to the first end point (For which we transmitted a BULK OUT 31 Bytes) device is responding with a STALL.. 4. After Clearing the HALT On the endpoint. with a clear feature command 5. Then driver is asking for the CSW Status for which the device is responding with 512 Bytes of Data. This is Causing a BABBLE Error (Expecting 13 Bytes of CSW but the device responded with 512 bytes). Then the driver is issuing RESET to the device. Is it an acceptable condition. who is the culprit for the RESET. Regards Kumar. -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver G: Let me guess, you started on the 'net with AOL, right? C: WOW! d00d! U r leet! -- Greg and Customer User Friendly, 2/12/1999 -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver C: Like the Furby? DP: He gives me the creeps. Think the SPCA will take him? -- Cobb and Dust Puppy User Friendly, 1/2/1999 pgppaKsdJY2ub.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb-storage bad device...
On Thu, Aug 17, 2006 at 11:24:51AM -0700, Greg KH wrote: I've got access to a new phone for a few hours here, and it doesn't seem to want to play nice with the usb-storage driver (imagine that...) Here's the dmesg of the device without debugging turned on, I'll enable it and send that log next. Any hints on how to determine which flags to add to the unusual_devs list? [ 125.718000] SCSI device sda: 4294967294 512-byte hdwr sectors (2199023 MB) [ 125.721000] sda: Write Protect is off [ 125.721000] sda: Mode Sense: 10 00 00 00 [ 125.721000] sda: assuming drive cache: write through Did you notice that the number of sectors being reported looks very close to MAXLONG? And I'm pretty sure your phone does not have 2.2TB of storage. As usual, I would suggest turning on usb-storage debug, but I highly doubt there is a flag which will fix this problem. I've never seen a device report a -totally- bogus size... Some of the later errors are from trying to access sectors at the reported end of the device Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I don't have a left mouse button. I only have one mouse and it's on my right. -- Customer User Friendly, 2/13/1999 pgpQtSPGyatFu.pgp Description: PGP signature - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb-storage bad device...
On Thu, Aug 17, 2006 at 03:57:52PM -0400, Alan Stern wrote: P.S.: There's one good thing about the phone: It always sets a correct value for the Residue! Lots of devices don't. It also appears to be framing the commands and responses properly, which is good. That is, status messages come when status messages are expected; there's no evidence of any sort of phase error. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver How would you like this tie wrapped around your hairy round head? -- Greg User Friendly, 9/2/1998 pgpH30ggyFwxq.pgp Description: PGP signature - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] add rio karma eject support
This changeset from Keith Bennett (via Bob Copeland) moves the Karma
initializer to its own file and adds trapping of the START_STOP command to
enable eject of the device.
Greg, please apply.
Matt
Signed-off-by: Keith Bennett [EMAIL PROTECTED]
Signed-off-by: Bob Copeland [EMAIL PROTECTED]
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
---
drivers/usb/storage/Kconfig| 12 ++
drivers/usb/storage/Makefile |1
drivers/usb/storage/initializers.c | 73 -
drivers/usb/storage/initializers.h |1
drivers/usb/storage/karma.c| 155 +
drivers/usb/storage/karma.h|7 +
drivers/usb/storage/unusual_devs.h |2
drivers/usb/storage/usb.c | 11 ++
include/linux/usb_usual.h |3
9 files changed, 190 insertions(+), 75 deletions(-)
Index: linux/drivers/usb/storage/initializers.c
===
--- linux.orig/drivers/usb/storage/initializers.c 2006-08-11
13:01:05.0 -0400
+++ linux/drivers/usb/storage/initializers.c2006-08-11 13:10:59.0
-0400
@@ -45,12 +45,6 @@
#include debug.h
#include transport.h
-#define RIO_MSC 0x08
-#define RIOP_INIT RIOP\x00\x01\x08
-#define RIOP_INIT_LEN 7
-#define RIO_SEND_LEN 40
-#define RIO_RECV_LEN 0x200
-
/* This places the Shuttle/SCM USB-SCSI bridge devices in multi-target
* mode */
int usb_stor_euscsi_init(struct us_data *us)
@@ -97,70 +91,3 @@
return (res ? -1 : 0);
}
-
-/* Place the Rio Karma into mass storage mode.
- *
- * The initialization begins by sending 40 bytes starting
- * RIOP\x00\x01\x08\x00, which the device will ack with a 512-byte
- * packet with the high four bits set and everything else null.
- *
- * Next, we send RIOP\x80\x00\x08\x00. Each time, a 512 byte response
- * must be read, but we must loop until byte 5 in the response is 0x08,
- * indicating success. */
-int rio_karma_init(struct us_data *us)
-{
- int result, partial;
- char *recv;
- unsigned long timeout;
-
- // us-iobuf is big enough to hold cmd but not receive
- if (!(recv = kmalloc(RIO_RECV_LEN, GFP_KERNEL)))
- goto die_nomem;
-
- US_DEBUGP(Initializing Karma...\n);
-
- memset(us-iobuf, 0, RIO_SEND_LEN);
- memcpy(us-iobuf, RIOP_INIT, RIOP_INIT_LEN);
-
- result = usb_stor_bulk_transfer_buf(us, us-send_bulk_pipe,
- us-iobuf, RIO_SEND_LEN, partial);
- if (result != USB_STOR_XFER_GOOD)
- goto die;
-
- result = usb_stor_bulk_transfer_buf(us, us-recv_bulk_pipe,
- recv, RIO_RECV_LEN, partial);
- if (result != USB_STOR_XFER_GOOD)
- goto die;
-
- us-iobuf[4] = 0x80;
- us-iobuf[5] = 0;
- timeout = jiffies + msecs_to_jiffies(3000);
- for (;;) {
- US_DEBUGP(Sending init command\n);
- result = usb_stor_bulk_transfer_buf(us, us-send_bulk_pipe,
- us-iobuf, RIO_SEND_LEN, partial);
- if (result != USB_STOR_XFER_GOOD)
- goto die;
-
- result = usb_stor_bulk_transfer_buf(us, us-recv_bulk_pipe,
- recv, RIO_RECV_LEN, partial);
- if (result != USB_STOR_XFER_GOOD)
- goto die;
-
- if (recv[5] == RIO_MSC)
- break;
- if (time_after(jiffies, timeout))
- goto die;
- msleep(10);
- }
- US_DEBUGP(Karma initialized.\n);
- kfree(recv);
- return 0;
-
-die:
- kfree(recv);
-die_nomem:
- US_DEBUGP(Could not initialize karma.\n);
- return USB_STOR_TRANSPORT_FAILED;
-}
-
Index: linux/drivers/usb/storage/initializers.h
===
--- linux.orig/drivers/usb/storage/initializers.h 2006-08-11
13:01:05.0 -0400
+++ linux/drivers/usb/storage/initializers.h2006-08-11 13:10:59.0
-0400
@@ -48,4 +48,3 @@
/* This function is required to activate all four slots on the UCR-61S2B
* flash reader */
int usb_stor_ucr61s2b_init(struct us_data *us);
-int rio_karma_init(struct us_data *us);
Index: linux/drivers/usb/storage/karma.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux/drivers/usb/storage/karma.c 2006-08-11 13:13:48.0 -0400
@@ -0,0 +1,155 @@
+/* Driver for Rio Karma
+ *
+ * (c) 2006 Bob Copeland [EMAIL PROTECTED]
+ * (c) 2006 Keith Bennett [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even
Re: [linux-usb-devel] [usb-storage] [PATCH] usb-storage: Add ZD1211 USB-WLAN support
Looks fine to me. The difference between this patch and the last one is a
6 of one, half-dozen of the other to me, but I see the benefits of this
approach.
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
Matt
On Mon, Jul 24, 2006 at 10:46:17PM +0100, Daniel Drake wrote:
Alan Stern wrote:
In general the idea looks okay to me, but I would change the details in
storage/usb.c. Check for US_FL_IGNORE_DEVICE in the get_device_info()
routine, and make that routine return int instead of void. If the flag is
present you can simply return -ENODEV. Then in storage_probe(), you check
the return code and jump to BadDevice if it's nonzero, just like with all
the following subroutine calls.
Thanks, that is a bit cleaner.
Matt?
diff --git a/drivers/usb/storage/unusual_devs.h
b/drivers/usb/storage/unusual_devs.h
index 543244d..f01a3f8 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -1074,7 +1074,15 @@ UNUSUAL_DEV( 0x0a17, 0x006, 0x, 0xff
Optio S/S4,
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_FIX_INQUIRY ),
-
+
+/* This is a virtual windows driver CD, which the zd1211rw driver
automatically
+ * converts into a WLAN device. */
+UNUSUAL_DEV( 0x0ace, 0x2011, 0x0101, 0x0101,
+ZyXEL,
+G-220F USB-WLAN Install,
+US_SC_DEVICE, US_PR_DEVICE, NULL,
+US_FL_IGNORE_DEVICE ),
+
#ifdef CONFIG_USB_STORAGE_ISD200
UNUSUAL_DEV( 0x0bf6, 0xa001, 0x0100, 0x0110,
ATI,
diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
index e232c7c..04cd0e6 100644
--- a/drivers/usb/storage/usb.c
+++ b/drivers/usb/storage/usb.c
@@ -479,7 +479,7 @@ static struct us_unusual_dev *find_unusu
}
/* Get the unusual_devs entries and the string descriptors */
-static void get_device_info(struct us_data *us, const struct usb_device_id
*id)
+static int get_device_info(struct us_data *us, const struct usb_device_id
*id)
{
struct usb_device *dev = us-pusb_dev;
struct usb_interface_descriptor *idesc =
@@ -496,6 +496,11 @@ static void get_device_info(struct us_da
unusual_dev-useTransport;
us-flags = USB_US_ORIG_FLAGS(id-driver_info);
+ if (us-flags US_FL_IGNORE_DEVICE) {
+ printk(KERN_INFO USB_STORAGE device ignored\n);
+ return -ENODEV;
+ }
+
/*
* This flag is only needed when we're in high-speed, so let's
* disable it if we're in full-speed
@@ -535,6 +540,8 @@ static void get_device_info(struct us_da
idesc-bInterfaceProtocol,
msgs[msg]);
}
+
+ return 0;
}
/* Get the transport settings */
@@ -961,7 +968,9 @@ static int storage_probe(struct usb_inte
* of the match from the usb_device_id table, so we can find the
* corresponding entry in the private table.
*/
- get_device_info(us, id);
+ result = get_device_info(us, id);
+ if (result)
+ goto BadDevice;
/* Get the transport, protocol, and pipe settings */
result = get_transport(us);
diff --git a/include/linux/usb_usual.h b/include/linux/usb_usual.h
index 608487a..4cf3bf1 100644
--- a/include/linux/usb_usual.h
+++ b/include/linux/usb_usual.h
@@ -43,6 +43,8 @@ #define US_DO_ALL_FLAGS
\
/* Need delay after Command phase */\
US_FLAG(NO_WP_DETECT, 0x0200) \
/* Don't check for write-protect */ \
+ US_FLAG(IGNORE_DEVICE, 0x0400) \
+ /* Don't claim device */
#define US_FLAG(name, value) US_FL_##name = value ,
enum { US_DO_ALL_FLAGS };
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
YOU SEE!!?? It's like being born with only one nipple!
-- Erwin
User Friendly, 10/19/1998
pgprGs4h77sFL.pgp
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [usb-storage] [PATCH] usb-storage: Add ZD1211 USB-WLAN support
On Tue, Jul 18, 2006 at 05:01:32PM +0100, Daniel Drake wrote: Alan Stern wrote: Wouldn't it be easy enough to write a user program to send the necessary command URB via usbfs? That seems more reasonable. That aside, it's not something that really makes sense to do in userspace - the zd1211rw driver doesn't require any zd1211-specific software, and it wouldn't be realistic to do something like this inside iwconfig. The quirk is simple and it allows the kernel to actually provide a wireless device after a wireless adapter is plugged in. I'm happy to consider alternative approaches though - perhaps we could just get usb-storage to ignore it, and have another standalone driver perform the quirk or something like that? I think that is a better approach than your patch. Perhaps the zd1211rw driver could know the VID/PID of the fake CD-ROM to attach to it and send the fake eject command. The usb-storage (and probably ub) would just have to ignore the device. Regardless, dealing with this device is very much outside the scope of usb-storage. That is, unless you want to fix usb-storage so that it works with the poor-quality CD-ROM emulation mode. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver E: You run this ship with Windows?! YOU IDIOT! L: Give me a break, it came bundled with the computer! -- ESR and Lan Solaris User Friendly, 12/8/1998 pgpYGhLsQCvnn.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [usb-storage] [PATCH pd44] Uname in PR/SC Unneeded message
On Sat, Jun 24, 2006 at 05:27:54PM -0700, Phil Dibowitz wrote: This patch adds the kernel version to the usb-storage Protocol/SubClass unneeded message in order to help us troubleshoot such problems. Signed-off-by: Phil Dibowitz [EMAIL PROTECTED] This looks good. Greg, please apply. Matt Signed-off-by: Matthew Dharm [EMAIL PROTECTED] -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It's not that hard. No matter what the problem is, tell the customer to reinstall Windows. -- Nurse User Friendly, 3/22/1998 pgpNs3ezZfBW8.pgp Description: PGP signature Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [usb-storage] [PATCH pd43] US_FL_MAX_SECTORS_64 flag
On Sat, Jun 24, 2006 at 05:27:10PM -0700, Phil Dibowitz wrote: This patch adds a US_FL_MAX_SECTORS_64 and removes the Genesys special-cases for this that were in scsiglue.c. It also adds the flag to other devices reported to need it. Signed-off-by: Phil Dibowitz [EMAIL PROTECTED] This looks good. Greg, please apply. Matt Signed-off-by: Matthew Dharm [EMAIL PROTECTED] -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver A: The most ironic oxymoron wins ... DP: Microsoft Works A: Uh, okay, you win. -- A.J. Dust Puppy User Friendly, 1/18/1998 pgp4hYYb0GyWy.pgp Description: PGP signature Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH] usb-storage: get rid of the timer during URB submission
Looks good to me. Greg, please apply.
Matt
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
On Wed, May 24, 2006 at 04:57:28PM +0200, Franck Bui-Huu wrote:
This patch uses completion timeout instead of a timer to implement
a timeout when submitting an URB.
It also put the task in interruptible state instead of an
uninterruptible one while waiting for the completion.
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED]
---
drivers/usb/storage/transport.c | 38 ++
1 files changed, 10 insertions(+), 28 deletions(-)
5d53ca36e71b3854ac8c86165ea0543c218c1c54
diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
index 7ca896a..038f458 100644
--- a/drivers/usb/storage/transport.c
+++ b/drivers/usb/storage/transport.c
@@ -115,19 +115,6 @@ static void usb_stor_blocking_completion
complete(urb_done_ptr);
}
-
-/* This is the timeout handler which will cancel an URB when its timeout
- * expires.
- */
-static void timeout_handler(unsigned long us_)
-{
- struct us_data *us = (struct us_data *) us_;
-
- if (test_and_clear_bit(US_FLIDX_URB_ACTIVE, us-flags)) {
- US_DEBUGP(Timeout -- cancelling URB\n);
- usb_unlink_urb(us-current_urb);
- }
-}
/* This is the common part of the URB message submission code
*
@@ -138,7 +125,7 @@ static void timeout_handler(unsigned lon
static int usb_stor_msg_common(struct us_data *us, int timeout)
{
struct completion urb_done;
- struct timer_list to_timer;
+ long timeleft;
int status;
/* don't submit URBs during abort/disconnect processing */
@@ -185,22 +172,17 @@ static int usb_stor_msg_common(struct us
}
}
- /* submit the timeout timer, if a timeout was requested */
- if (timeout 0) {
- init_timer(to_timer);
- to_timer.expires = jiffies + timeout;
- to_timer.function = timeout_handler;
- to_timer.data = (unsigned long) us;
- add_timer(to_timer);
- }
-
/* wait for the completion of the URB */
- wait_for_completion(urb_done);
- clear_bit(US_FLIDX_URB_ACTIVE, us-flags);
+ timeleft = wait_for_completion_interruptible_timeout(
+ urb_done, timeout ? : MAX_SCHEDULE_TIMEOUT);
- /* clean up the timeout timer */
- if (timeout 0)
- del_timer_sync(to_timer);
+ clear_bit(US_FLIDX_URB_ACTIVE, us-flags);
+
+ if (timeleft = 0) {
+ US_DEBUGP(%s -- cancelling URB\n,
+ timeleft == 0 ? Timeout : Signal);
+ usb_unlink_urb(us-current_urb);
+ }
/* return the URB status */
return us-current_urb-status;
--
1.3.3.g8701
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
You were using cheat codes too. You guys suck.
-- Greg to General Studebaker
User Friendly, 12/16/1997
pgpwKo4vI2rtu.pgp
Description: PGP signature
Re: [linux-usb-devel] Re: [PATCH] usb-storage: get rid of the timer during URB submission
On Mon, May 22, 2006 at 10:53:40AM -0400, Alan Stern wrote: On Mon, 22 May 2006, Franck Bui-Huu wrote: and use completion timeout instead. Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED] This looks okay to me, although you might as go ahead and use wait_for_completion_interruptible_timeout so that the time spent waiting will be properly accounted as I/O. Definately. Also, what is the value of MAX_SCHEDULE_TIMEOUT, and is it a sane value? Also you should get approval from Matt Dharm, the usb-storage maintainer. Other than the above change and comment, it looks good to me. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver A female who groks UNIX? My universe is collapsing. -- Mike User Friendly, 10/11/1998 pgpQYq927sFiM.pgp Description: PGP signature
Re: [linux-usb-devel] Re: [PATCH] usb-storage: get rid of the timer during URB submission
On Mon, May 22, 2006 at 10:20:58AM -0700, Matthew Dharm wrote: On Mon, May 22, 2006 at 10:53:40AM -0400, Alan Stern wrote: On Mon, 22 May 2006, Franck Bui-Huu wrote: and use completion timeout instead. Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED] This looks okay to me, although you might as go ahead and use wait_for_completion_interruptible_timeout so that the time spent waiting will be properly accounted as I/O. Definately. Also, what is the value of MAX_SCHEDULE_TIMEOUT, and is it a sane value? Now that I think about it some more, why use MAX_SCHEDULE_TIMEOUT at all? You're imposing a timeout where none existed before... Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 pgpy7da4pgJrl.pgp Description: PGP signature
[linux-usb-devel] Re: [usb-storage] Re: RFC - Let ub handle iPods
On Mon, May 01, 2006 at 11:33:09PM -0700, Pete Zaitcev wrote: On Mon, 01 May 2006 23:00:52 -0700, Phil Dibowitz [EMAIL PROTECTED] wrote: So what criteria did you use to decide whether to set it to USB_US_TYPE_STOR or 0? I'm assuming 0 means usb-storage? No, zero means runtime-selectable. The ub only works with 8/6/50 devices, so this disqualifies anything that - uses 8070, 8020, RBC, etc. - uses UFI, even over bulk - uses CB or CBI for transport - needs any initialization function Also, a bunch of devices use unknown protocols, because they only have SC_DEVICE and PR_DEVICE listed. So, in the end almost everything has to be locked to usb-storage. My only objection is that the above bit of knowledge should be spelled out somewhere very clearly in ub, libusual, and usb-storage so that people wondering the same thing can find it no matter where they look. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver YOU SEE!!?? It's like being born with only one nipple! -- Erwin User Friendly, 10/19/1998 pgphdlXOLngD4.pgp Description: PGP signature
[linux-usb-devel] Re: RFC - Let ub handle iPods
On Sat, Apr 29, 2006 at 11:48:16AM -0400, Alan Stern wrote: On Sat, 29 Apr 2006, Phil Dibowitz wrote: Tangential question - you're making the decision for the user here, so more so than Why does Pete want to drive his iPod with ub, why does this make sense for everyone who uses Linux? Phil, I think you have misunderstood the point of this patch. It doesn't make any decisions for the user. Just the opposite. The way libusual currently works is that every entry in unusual_devs.h is automatically directed to usb-storage, not to ub. The patch adds a way to specify that a particular entry should be directed according to the user's preference, by coding such entries with the UNUSUAL_DEV2 macro instead of UNUSUAL_DEV. Why just certain entries? Why not everything? It seems inconsistent (and an invitation for a zillion little patches) to only apply this to a select few devices which Pete happens to have. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver SP: I sell software for Microsoft. Can you set me free? DP: Natural Selection says I shouldn't. -- MS Salesman and Dust Puppy User Friendly, 4/2/1998 pgpDBMXqxyss9.pgp Description: PGP signature
Re: [linux-usb-devel] [USB Storage] Problem on first mount after replug
-storage: -- code: 0x70, key: 0x6, ASC: 0x28, ASCQ: 0x0 usb-storage: Unit Attention: not ready to ready transition usb-storage: scsi cmd done, result=0x2 usb-storage: *** thread sleeping. I/O error: dev 08:01, sector 0 FAT: unable to read boot sector usb-storage: queuecommand() called usb-storage: *** thread awakened. usb-storage: Command START_STOP (6 bytes) usb-storage: 1b 00 00 00 01 00 00 00 28 00 00 00 usb-storage: Bulk command S 0x43425355 T 0x5d Trg 0 LUN 0 L 0 F 0 CL 6 usb-storage: Bulk command transfer result=0 usb-storage: Attempting to get CSW... usb-storage: Bulk status result = 0 usb-storage: Bulk status Sig 0x53425355 T 0x5d R 0 Stat 0x0 usb-storage: scsi cmd done, result=0x0 usb-storage: *** thread sleeping. VFS: Disk change detected on device sd(8,1) usb-storage: queuecommand() called usb-storage: *** thread awakened. usb-storage: Command TEST_UNIT_READY (6 bytes) usb-storage: 00 00 00 00 00 00 00 00 00 00 5d de usb-storage: Bulk command S 0x43425355 T 0x5e Trg 0 LUN 0 L 0 F 0 CL 6 usb-storage: Bulk command transfer result=0 usb-storage: Attempting to get CSW... usb-storage: Bulk status result = 0 usb-storage: Bulk status Sig 0x53425355 T 0x5e R 0 Stat 0x0 usb-storage: scsi cmd done, result=0x0 usb-storage: *** thread sleeping. usb-storage: queuecommand() called usb-storage: *** thread awakened. usb-storage: Command READ_CAPACITY (10 bytes) usb-storage: 25 00 00 00 00 00 00 00 00 00 5d de usb-storage: Bulk command S 0x43425355 T 0x5f Trg 0 LUN 0 L 8 F 128 CL 10 usb-storage: Bulk command transfer result=0 usb-storage: usb_stor_transfer_partial(): xfer 8 bytes usb-storage: usb_stor_bulk_msg() returned 0 xferred 8/8 usb-storage: usb_stor_transfer_partial(): transfer complete usb-storage: Bulk data transfer result 0x0 usb-storage: Attempting to get CSW... usb-storage: Bulk status result = 0 usb-storage: Bulk status Sig 0x53425355 T 0x5f R 0 Stat 0x0 usb-storage: scsi cmd done, result=0x0 usb-storage: *** thread sleeping. SCSI device sda: 251904 512-byte hdwr sectors (129 MB) usb-storage: queuecommand() called usb-storage: *** thread awakened. usb-storage: Command MODE_SENSE (6 bytes) usb-storage: 1a 00 3f 00 ff 00 00 00 00 00 5d de usb-storage: Bulk command S 0x43425355 T 0x60 Trg 0 LUN 0 L 255 F 128 CL 6 usb-storage: Bulk command transfer result=0 usb-storage: usb_stor_transfer_partial(): xfer 255 bytes usb-storage: usb_stor_bulk_msg() returned 0 xferred 36/255 usb-storage: Bulk data transfer result 0x1 usb-storage: Attempting to get CSW... usb-storage: Bulk status result = 0 usb-storage: Bulk status Sig 0x53425355 T 0x60 R 0 Stat 0x0 usb-storage: scsi cmd done, result=0x0 usb-storage: *** thread sleeping. sda: Write Protect is off sda:7usb-storage: queuecommand() called usb-storage: *** thread awakened. usb-storage: Command READ_10 (10 bytes) usb-storage: 28 00 00 00 00 00 00 00 08 00 5d de usb-storage: Bulk command S 0x43425355 T 0x61 Trg 0 LUN 0 L 4096 F 128 CL 10 usb-storage: Bulk command transfer result=0 usb-storage: usb_stor_transfer_partial(): xfer 4096 bytes usb-storage: usb_stor_bulk_msg() returned 0 xferred 4096/4096 usb-storage: usb_stor_transfer_partial(): transfer complete usb-storage: Bulk data transfer result 0x0 usb-storage: Attempting to get CSW... usb-storage: Bulk status result = 0 usb-storage: Bulk status Sig 0x53425355 T 0x61 R 0 Stat 0x0 usb-storage: scsi cmd done, result=0x0 usb-storage: *** thread sleeping. sda1 Thanks in advance for any information about this behavior. Regards, Patrick Agrain --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I'm a pink gumdrop! How can anything be worse?!! -- Erwin User Friendly, 10/4/1998 pgpqjHsBzAe4J.pgp Description: PGP signature
[linux-usb-devel] Re: [usb-storage] Multi-interface devices
On Thu, Feb 23, 2006 at 10:22:55AM -0800, Pete Zaitcev wrote: This is a 2.4 question with a patch. I am having a deja-vu about it. Please look at this and let me know if it prompts any associations: It feels vaguely as if we discussed this, but I cannot find anything. About 3 years ago we had a single complaint about this problem from one vendor, who then stopped communicating with us about it. And, by that time, we had already decided to dump the remember-and-match behavior. So, it was just never a priority for fix in 2.4. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Department of Justice agent. I have come to purify the flock. -- DOJ agent User Friendly, 5/22/1998 pgp4BR3nLVz3l.pgp Description: PGP signature
Re: [linux-usb-devel] Re: 2.6.15: usb storage device not detected
On Sat, Feb 18, 2006 at 10:49:24PM -0800, Pete Zaitcev wrote: I see... This is a device which dislikes the stall clear when called after a stall on the control pipe. I knew this was inevitable ever since Wolfgang pointed me at it when we debugged Martin's Elitegroup K7S5A. I'm going to send the attached patch to Greg to get it into 2.6.17 (this way it will be separated from all the reset machinery which goes into 2.6.16). I have tested it on my honest to goodness ZIP-100, and yes, it stalls the control pipe at the GetMaxLUN, and yes, it works after that. Here's the hope that it is some kind of an urban legend. It's not an urban legend. There are several different devices which were all marketed as ZIP-100. The early generation ones had this problem. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver E: You run this ship with Windows?! YOU IDIOT! L: Give me a break, it came bundled with the computer! -- ESR and Lan Solaris User Friendly, 12/8/1998 pgpULMgCQ1qv6.pgp Description: PGP signature
Re: [linux-usb-devel] Re: [PATCH] Adaptec USBXchange and USB2Xchange support
So how do you address a multi-LUN device with the USB2Xchange?
Matt
On Mon, Jan 30, 2006 at 07:04:15PM +0100, Ren? Rebe wrote:
Hi,
finally - I got multi target (that is a SCSI device other than ID = 0 and
more than than one) working
with the USB2Xchange. But it needs two ugly changes in transport.c:
The first one is only encoding the ID, no LUN:
--- ../linux-2.6.15/drivers/usb/storage/transport.c 2006-01-03
04:21:10.0 +0100
+++ drivers/usb/storage/transport.c 2006-01-30 18:49:25.172317000 +0100
@@ -983,7 +983,7 @@
bcb-Tag = ++us-tag;
bcb-Lun = srb-device-lun;
if (us-flags US_FL_SCM_MULT_TARG)
- bcb-Lun |= srb-device-id 4;
+ bcb-Lun = srb-device-id;
bcb-Length = srb-cmd_len;
/* copy the command payload */
Would it be ok when special case that one only for the Adaptec device, for
now?
Or define a whole new 2nd MULTI_TARG(2) quirk?
And furthermore the device does not respond to request other than the
attached targets,
this might be needed:
@@ -1069,6 +1069,19 @@
US_DEBUGP(Bulk Status S 0x%x T 0x%x R %u Stat 0x%x\n,
le32_to_cpu(bcs-Signature), bcs-Tag,
residue, bcs-Status);
+
+ if (bcs-Status US_BULK_STAT_FAIL) {
+ /* Adaptec USB2XCHANGE */
+ if (us-pusb_dev-descriptor.idVendor == 0x03f3
+ us-pusb_dev-descriptor.idProduct == 0x2003) {
+
+ /* This device will send bcs-Status == 0x8a for unused
targets and
+== 0x02 for SRB's that require SENSE. */
+ bcs-Status = US_BULK_STAT_OK;
+ fake_sense = 1;
+ US_DEBUGP(Patched Bulk status to %d.\n, bcs-Status);
+ }
+ }
if (bcs-Tag != us-tag || bcs-Status US_BULK_STAT_PHASE) {
US_DEBUGP(Bulk logical error\n);
return USB_STOR_TRANSPORT_ERROR;
Yours,
--
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://www.exactcode.de | http://www.t2-project.org
+49 (0)30 255 897 45
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
NYET! The evil stops here!
-- Pitr
User Friendly, 6/22/1998
pgpgqROm0hIrx.pgp
Description: PGP signature
Re: [linux-usb-devel] Re: [PATCH] Adaptec USBXchange and USB2Xchange support
So how do you address a multi-LUN target if you don't encode the LUN?
Matt
On Mon, Jan 30, 2006 at 07:04:15PM +0100, Ren? Rebe wrote:
Hi,
finally - I got multi target (that is a SCSI device other than ID = 0 and
more than than one) working
with the USB2Xchange. But it needs two ugly changes in transport.c:
The first one is only encoding the ID, no LUN:
--- ../linux-2.6.15/drivers/usb/storage/transport.c 2006-01-03
04:21:10.0 +0100
+++ drivers/usb/storage/transport.c 2006-01-30 18:49:25.172317000 +0100
@@ -983,7 +983,7 @@
bcb-Tag = ++us-tag;
bcb-Lun = srb-device-lun;
if (us-flags US_FL_SCM_MULT_TARG)
- bcb-Lun |= srb-device-id 4;
+ bcb-Lun = srb-device-id;
bcb-Length = srb-cmd_len;
/* copy the command payload */
Would it be ok when special case that one only for the Adaptec device, for
now?
Or define a whole new 2nd MULTI_TARG(2) quirk?
And furthermore the device does not respond to request other than the
attached targets,
this might be needed:
@@ -1069,6 +1069,19 @@
US_DEBUGP(Bulk Status S 0x%x T 0x%x R %u Stat 0x%x\n,
le32_to_cpu(bcs-Signature), bcs-Tag,
residue, bcs-Status);
+
+ if (bcs-Status US_BULK_STAT_FAIL) {
+ /* Adaptec USB2XCHANGE */
+ if (us-pusb_dev-descriptor.idVendor == 0x03f3
+ us-pusb_dev-descriptor.idProduct == 0x2003) {
+
+ /* This device will send bcs-Status == 0x8a for unused
targets and
+== 0x02 for SRB's that require SENSE. */
+ bcs-Status = US_BULK_STAT_OK;
+ fake_sense = 1;
+ US_DEBUGP(Patched Bulk status to %d.\n, bcs-Status);
+ }
+ }
if (bcs-Tag != us-tag || bcs-Status US_BULK_STAT_PHASE) {
US_DEBUGP(Bulk logical error\n);
return USB_STOR_TRANSPORT_ERROR;
Yours,
--
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://www.exactcode.de | http://www.t2-project.org
+49 (0)30 255 897 45
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
A female who groks UNIX? My universe is collapsing.
-- Mike
User Friendly, 10/11/1998
pgp2q95GKDaAz.pgp
Description: PGP signature
[linux-usb-devel] Re: 2.6.15: usb storage device not detected
Turn off CONFIG_BLK_DEV_UB Matt On Tue, Jan 10, 2006 at 12:05:50AM +1100, CaT wrote: Device works on two other linux boxes (an nvidia2 chipset and an intel bx laptop chipset) aswell as windows boxes without extra drivers. On this VIA based box: :00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 80) :00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 80) :00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 80) :00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) I get (from two inserts): kernel: [ 111.330762] usb 1-5: new high speed USB device using ehci_hcd and address 3 kernel: [ 112.180267] ub(1.3): Stall at GetMaxLUN, using 1 LUN kernel: [ 151.843141] usb 1-5: USB disconnect, address 3 kernel: [ 154.547011] usb 1-5: new high speed USB device using ehci_hcd and address 4 kernel: [ 155.395524] ub(1.4): Stall at GetMaxLUN, using 1 LUN kernel: [ 177.073446] usb 1-5: USB disconnect, address 4 and no device (I expect /dev/sda1). .config, dmesg and lspci -vv output for the usb bits attached. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby # # Automatically generated make config: don't edit # Linux kernel version: 2.6.15 # Mon Jan 9 23:29:49 2006 # CONFIG_X86_32=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_INITRAMFS_SOURCE= # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # # CONFIG_MODULES is not set # # Block layer # CONFIG_LBD=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y CONFIG_X86_TSC=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y # CONFIG_X86_MCE_P4THERMAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set CONFIG_SELECT_MEMORY_MODEL=y
[linux-usb-devel] Re: [Linux-usb-users] How to mount USB devices via hub - mknod parameters
sde1 should be 8 65, not 8 1. Matt On Mon, Jan 09, 2006 at 12:31:05PM +0100, [EMAIL PROTECTED] wrote: Hi, I'm using 3ports hub/card reader(4 slots) - system recognize it properly. When I plug flash drive, system report that it is sde1 (depends on port) I configured sde1 as follows: mknod /dev/sde1 b 8 1 but while mounting I get No medium found error (when I connect flash directly - without hub - wokrs fine with sda1) How should I configure dev nodes? I plan to connect up to 7 devices via hub so I need node configuration fro sda ... sdg. Is there any good docu describing mknod with parameters for different devices? -- Jack --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Way to go, lava boy. -- Stef to Greg User Friendly, 3/26/1998 pgpAFevjn8nsK.pgp Description: PGP signature
[linux-usb-devel] [PATCH] usb-storage: Add support for Rio Karma
This patch from Bob Copeland adds support for the Rio Karma portable
digital audio player to the usb-storage driver. The only thing needed to
support this device is a one-time (per plugin) init command which is sent
to the device.
Greg, please apply.
Matt
Signed-off-by: Bob Copeland [EMAIL PROTECTED]
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
initializers.c | 73 +
initializers.h |1
unusual_devs.h |5 +++
3 files changed, 79 insertions(+)
diff --git a/drivers/usb/storage/initializers.c
b/drivers/usb/storage/initializers.c
index 5b06f92..85e1cb0 100644
--- a/drivers/usb/storage/initializers.c
+++ b/drivers/usb/storage/initializers.c
@@ -45,6 +45,12 @@
#include debug.h
#include transport.h
+#define RIO_MSC 0x08
+#define RIOP_INIT RIOP\x00\x01\x08
+#define RIOP_INIT_LEN 7
+#define RIO_SEND_LEN 40
+#define RIO_RECV_LEN 0x200
+
/* This places the Shuttle/SCM USB-SCSI bridge devices in multi-target
* mode */
int usb_stor_euscsi_init(struct us_data *us)
@@ -91,3 +97,70 @@ int usb_stor_ucr61s2b_init(struct us_dat
return (res ? -1 : 0);
}
+
+/* Place the Rio Karma into mass storage mode.
+ *
+ * The initialization begins by sending 40 bytes starting
+ * RIOP\x00\x01\x08\x00, which the device will ack with a 512-byte
+ * packet with the high four bits set and everything else null.
+ *
+ * Next, we send RIOP\x80\x00\x08\x00. Each time, a 512 byte response
+ * must be read, but we must loop until byte 5 in the response is 0x08,
+ * indicating success. */
+int rio_karma_init(struct us_data *us)
+{
+ int result, partial;
+ char *recv;
+ unsigned long timeout;
+
+ // us-iobuf is big enough to hold cmd but not receive
+ if (!(recv = kmalloc(RIO_RECV_LEN, GFP_KERNEL)))
+ goto die_nomem;
+
+ US_DEBUGP(Initializing Karma...\n);
+
+ memset(us-iobuf, 0, RIO_SEND_LEN);
+ memcpy(us-iobuf, RIOP_INIT, RIOP_INIT_LEN);
+
+ result = usb_stor_bulk_transfer_buf(us, us-send_bulk_pipe,
+ us-iobuf, RIO_SEND_LEN, partial);
+ if (result != USB_STOR_XFER_GOOD)
+ goto die;
+
+ result = usb_stor_bulk_transfer_buf(us, us-recv_bulk_pipe,
+ recv, RIO_RECV_LEN, partial);
+ if (result != USB_STOR_XFER_GOOD)
+ goto die;
+
+ us-iobuf[4] = 0x80;
+ us-iobuf[5] = 0;
+ timeout = jiffies + msecs_to_jiffies(3000);
+ for (;;) {
+ US_DEBUGP(Sending init command\n);
+ result = usb_stor_bulk_transfer_buf(us, us-send_bulk_pipe,
+ us-iobuf, RIO_SEND_LEN, partial);
+ if (result != USB_STOR_XFER_GOOD)
+ goto die;
+
+ result = usb_stor_bulk_transfer_buf(us, us-recv_bulk_pipe,
+ recv, RIO_RECV_LEN, partial);
+ if (result != USB_STOR_XFER_GOOD)
+ goto die;
+
+ if (recv[5] == RIO_MSC)
+ break;
+ if (time_after(jiffies, timeout))
+ goto die;
+ msleep(10);
+ }
+ US_DEBUGP(Karma initialized.\n);
+ kfree(recv);
+ return 0;
+
+die:
+ kfree(recv);
+die_nomem:
+ US_DEBUGP(Could not initialize karma.\n);
+ return USB_STOR_TRANSPORT_FAILED;
+}
+
diff --git a/drivers/usb/storage/initializers.h
b/drivers/usb/storage/initializers.h
index 7372386..fa9a2ff 100644
--- a/drivers/usb/storage/initializers.h
+++ b/drivers/usb/storage/initializers.h
@@ -52,3 +52,4 @@ int sddr09_init(struct us_data *us);
/* This function is required to activate all four slots on the UCR-61S2B
* flash reader */
int usb_stor_ucr61s2b_init(struct us_data *us);
+int rio_karma_init(struct us_data *us);
diff --git a/drivers/usb/storage/unusual_devs.h
b/drivers/usb/storage/unusual_devs.h
index 0a9858f..0cdfebf 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -145,6 +145,11 @@ UNUSUAL_DEV( 0x0451, 0x5416, 0x0100, 0x
US_SC_DEVICE, US_PR_BULK, NULL,
US_FL_NEED_OVERRIDE ),
+UNUSUAL_DEV( 0x045a, 0x5210, 0x0101, 0x0101,
+ Rio,
+ Rio Karma,
+ US_SC_SCSI, US_PR_BULK, rio_karma_init, 0),
+
/* Patch submitted by Philipp Friedrich [EMAIL PROTECTED] */
UNUSUAL_DEV( 0x0482, 0x0100, 0x0100, 0x0100,
Kyocera,
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
Why am I talking to a toilet brush?
-- CEO
User Friendly, 4/30/1998
pgp0Behjpmyng.pgp
Description: PGP signature
Re: [linux-usb-devel] [PATCH] Force starget-scsi_level in usb-storage scsiglue.c
I thought I saw this merged into the -mm tree already... so I figured it was taken care of. Matt On Sun, Dec 18, 2005 at 10:06:08PM -0500, Alan Stern wrote: Matt Greg: At the end of November Paul Walmsley submitted this patch: http://marc.theaimsgroup.com/?l=linux-usb-develm=113331727523045w=2 I think it's important that this be merged before 2.6.15 is released. Otherwise a bunch of people are going to be annoyed when their USB disks stop working. Alan Stern -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 pgp1G5E9s2vxd.pgp Description: PGP signature
Re: [linux-usb-devel] Question concerning message sequence to usb storage
It sounds like you should be looking at Dazuko (www.dazuko.org) which allows you to trap exactly such events. Matt On Sat, Dec 17, 2005 at 02:51:12PM -0800, gary clark wrote: Hi Randy, I wanted to know the sequence of drivers and calls that are involved when a cp is performed to a usb device. Alan Stern gave of course an excellent response on this. Seems like there are a few more actors in this than I thought. I have been asked to log all files that are copied to a usb device. They dont want me to add the complete change in user space. I was hoping that when a cp is performed that I can map eg /dev/sdb1 to a usb device descriptor and log that cp request. They are doing this on Windows so of course they want it on Linux. Thanks, Garyc --- Randy.Dunlap [EMAIL PROTECTED] wrote: On Sat, 17 Dec 2005 14:12:42 -0800 (PST) gary clark wrote: Hi Randy, Much appreciate the read snippet. However I'm a little unsure how a write maps to say those functions in /usr/include/usb.h. What kind of maps do you mean here? Are they independant of each other? If the snippet you provided will put me on the right track. I thought maybe a sys_write on a usb device would map to a request in usb.h? A 'write' sycall will go to a driver's write routine. It's up to the driver, depending on the device type that is attached, to determine what kind of USB 'messages' must be sent to the device. Maybe if you tell us what problem you are trying to solve we would be able to help a bit more. and please don't top-post. and please keep the discussion on the mailing list so that everyone can benefit from it. Thanks, Garyc --- Randy.Dunlap [EMAIL PROTECTED] wrote: On Sat, 17 Dec 2005 12:49:35 -0800 (PST) gary clark wrote: Hello, I want to trace what happens when a file is copied to a usb storage device. The linux cp command will perform an open on the path given and obtain the inode which is used to access the usb device. Can somebody tell me what driver is used that has the write function or an ioctl call to the driver? Is it in usb_storage? I'm assuming that there is a write function in the driver module. Basically I want to understand what happens when a write is made to a usb device and the drivers involved. If someone could point me to a document with this info that would be great. Here's a Linux 2.4 version, using an IDE device instead of USB, but it may help you some. http://www.win.tue.nl/~aeb/linux/vfs/trail.html --- ~Randy --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver We can customize our colonels. -- Tux User Friendly, 12/1/1998 pgpDadPstnrmW.pgp Description: PGP signature
[linux-usb-devel] Re: [PATCH 2.6.14] usb-storage: sat passthru sense size compatibility
Ugh. Is there no way to convince the SCSI people to add an autosense
request size field to the SRB?
History has told us that doing much of anything based on cmnd[0] is a
good way to get bitten very badly...
Matt
On Mon, Dec 05, 2005 at 03:55:56PM -0800, Timothy Thelin wrote:
The sense data length for auto-sense behavior is now determined in a
separate function that is aware of SAT passthru returning 22 bytes of
sense data instead of the normal 18. 22 bytes is used only if the
device is SCSI/RBC and the previous command was a sat passthru command.
Signed-off-by: Timothy Thelin [EMAIL PROTECTED]
---
diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
index 7ca896a..10d1b49 100644
--- a/drivers/usb/storage/transport.c
+++ b/drivers/usb/storage/transport.c
@@ -521,6 +521,14 @@ int usb_stor_bulk_transfer_sg(struct us_
* Transport routines
***/
+static inline unsigned usb_stor_sense_data_len(struct scsi_cmnd *srb, struct
us_data *us)
+{
+ if ((us-subclass == US_SC_RBC || us-subclass == US_SC_SCSI)
+ (srb-cmnd[0] == ATA_12 || srb-cmnd[0] == ATA_16))
+ return 22;
+ return 18;
+}
+
/* Invoke the transport and basic error-handling/recovery methods
*
* This is used by the protocol layers to actually send the message to
@@ -611,9 +619,13 @@ void usb_stor_invoke_transport(struct sc
unsigned char old_cmd_len;
unsigned char old_cmnd[MAX_COMMAND_SIZE];
int old_resid;
+ unsigned sense_data_len;
US_DEBUGP(Issuing auto-REQUEST_SENSE\n);
+ /* get the length before the srb is changed */
+ sense_data_len = usb_stor_sense_data_len(srb, us);
+
/* save the old command */
memcpy(old_cmnd, srb-cmnd, MAX_COMMAND_SIZE);
old_cmd_len = srb-cmd_len;
@@ -622,7 +634,7 @@ void usb_stor_invoke_transport(struct sc
memset(srb-cmnd, 0, MAX_COMMAND_SIZE);
srb-cmnd[0] = REQUEST_SENSE;
srb-cmnd[1] = old_cmnd[1] 0xE0;
- srb-cmnd[4] = 18;
+ srb-cmnd[4] = sense_data_len;
/* FIXME: we must do the protocol translation here */
if (us-subclass == US_SC_RBC || us-subclass == US_SC_SCSI)
@@ -640,7 +652,7 @@ void usb_stor_invoke_transport(struct sc
/* set the buffer length for transfer */
old_request_bufflen = srb-request_bufflen;
- srb-request_bufflen = US_SENSE_SIZE;
+ srb-request_bufflen = sense_data_len;
/* set up for no scatter-gather use */
old_sg = srb-use_sg;
diff --git a/drivers/usb/storage/usb.h b/drivers/usb/storage/usb.h
index 98b0971..80e3a22 100644
--- a/drivers/usb/storage/usb.h
+++ b/drivers/usb/storage/usb.h
@@ -117,7 +117,7 @@ enum { US_DO_ALL_FLAGS };
*/
#define US_IOBUF_SIZE64 /* Size of the DMA-mapped I/O
buffer */
-#define US_SENSE_SIZE18 /* Size of the autosense data
buffer */
+#define US_SENSE_SIZE22 /* Size of the autosense data
buffer */
typedef int (*trans_cmnd)(struct scsi_cmnd *, struct us_data*);
typedef int (*trans_reset)(struct us_data*);
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
E: You run this ship with Windows?! YOU IDIOT!
L: Give me a break, it came bundled with the computer!
-- ESR and Lan Solaris
User Friendly, 12/8/1998
pgpi5Jr1FZs3x.pgp
Description: PGP signature
[linux-usb-devel] PATCH as593: make OneTouch PM-aware
The OneTouch subdriver submits its own interrupt URB for notifications
about button presses. Consequently it needs to know about suspend and
resume events, so it can cancel or restart the URB.
This patch (as593) adds a hook to struct us_data, to be used for notifying
subdrivers about Power Management events, and it implements the hook in
the OneTouch driver.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Signed-off-by: Nick Sillik [EMAIL PROTECTED]
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
Greg, please apply.
Matt
Index: usb-2.6/drivers/usb/storage/usb.c
===
--- usb-2.6.orig/drivers/usb/storage/usb.c
+++ usb-2.6/drivers/usb/storage/usb.c
@@ -188,6 +188,8 @@ static int storage_suspend(struct usb_in
down(us-dev_semaphore);
US_DEBUGP(%s\n, __FUNCTION__);
+ if (us-suspend_resume_hook)
+ (us-suspend_resume_hook)(us, US_SUSPEND);
iface-dev.power.power_state.event = message.event;
/* When runtime PM is working, we'll set a flag to indicate
@@ -204,6 +206,8 @@ static int storage_resume(struct usb_int
down(us-dev_semaphore);
US_DEBUGP(%s\n, __FUNCTION__);
+ if (us-suspend_resume_hook)
+ (us-suspend_resume_hook)(us, US_RESUME);
iface-dev.power.power_state.event = PM_EVENT_ON;
up(us-dev_semaphore);
Index: usb-2.6/drivers/usb/storage/usb.h
===
--- usb-2.6.orig/drivers/usb/storage/usb.h
+++ usb-2.6/drivers/usb/storage/usb.h
@@ -93,7 +93,11 @@ struct us_unusual_dev {
typedef int (*trans_cmnd)(struct scsi_cmnd *, struct us_data*);
typedef int (*trans_reset)(struct us_data*);
typedef void (*proto_cmnd)(struct scsi_cmnd*, struct us_data*);
-typedef void (*extra_data_destructor)(void *); /* extra data destructor */
+typedef void (*extra_data_destructor)(void *); /* extra data destructor */
+typedef void (*pm_hook)(struct us_data *, int);/* power management
hook */
+
+#define US_SUSPEND 0
+#define US_RESUME 1
/* we allocate one of these for every device that we remember */
struct us_data {
@@ -149,6 +153,9 @@ struct us_data {
/* subdriver information */
void*extra; /* Any extra data */
extra_data_destructor extra_destructor;/* extra data destructor */
+#ifdef CONFIG_PM
+ pm_hook suspend_resume_hook;
+#endif
};
/* Convert between us_data and the corresponding Scsi_Host */
Index: usb-2.6/drivers/usb/storage/onetouch.c
===
--- usb-2.6.orig/drivers/usb/storage/onetouch.c
+++ usb-2.6/drivers/usb/storage/onetouch.c
@@ -52,6 +52,7 @@ struct usb_onetouch {
struct urb *irq;/* urb for interrupt in report */
unsigned char *data;/* input data */
dma_addr_t data_dma;
+ unsigned int is_open:1;
};
static void usb_onetouch_irq(struct urb *urb, struct pt_regs *regs)
@@ -89,6 +90,7 @@ static int usb_onetouch_open(struct inpu
{
struct usb_onetouch *onetouch = dev-private;
+ onetouch-is_open = 1;
onetouch-irq-dev = onetouch-udev;
if (usb_submit_urb(onetouch-irq, GFP_KERNEL)) {
err(usb_submit_urb failed);
@@ -103,8 +105,30 @@ static void usb_onetouch_close(struct in
struct usb_onetouch *onetouch = dev-private;
usb_kill_urb(onetouch-irq);
+ onetouch-is_open = 0;
}
+#ifdef CONFIG_PM
+static void usb_onetouch_pm_hook(struct us_data *us, int action)
+{
+ struct usb_onetouch *onetouch = (struct usb_onetouch *) us-extra;
+
+ if (onetouch-is_open) {
+ switch (action) {
+ case US_SUSPEND:
+ usb_kill_urb(onetouch-irq);
+ break;
+ case US_RESUME:
+ if (usb_submit_urb(onetouch-irq, GFP_KERNEL) != 0)
+ err(usb_submit_urb failed);
+ break;
+ default:
+ break;
+ }
+ }
+}
+#endif /* CONFIG_PM */
+
int onetouch_connect_input(struct us_data *ss)
{
struct usb_device *udev = ss-pusb_dev;
@@ -185,6 +209,9 @@ int onetouch_connect_input(struct us_dat
ss-extra_destructor = onetouch_release_input;
ss-extra = onetouch;
+#ifdef CONFIG_PM
+ ss-suspend_resume_hook = usb_onetouch_pm_hook;
+#endif
input_register_device(onetouch-dev);
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
Ye gods! I have feet??!
-- Dust Puppy
User Friendly, 12/4/1997
pgpnrQqVfwmWl.pgp
Description: PGP signature
[linux-usb-devel] PATCH as594: cleanups of sddr09
This is the first of three patches to prepare the sddr09 subdriver for
conversion to the Sim-SCSI framework. This patch (as594) straightens out
the initialization procedures and headers:
Some ugly code from usb.c was moved into sddr09.c.
Set-up of the private data structures was moved into the
initialization routine.
The connection between the dpcm version and the standalone
version was clarified.
A private declaration was moved from a header file into the
subdriver's .c file.
Greg, please apply.
Matt
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Acked-by: Andries Brouwer [EMAIL PROTECTED]
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
---
Index: usb-2.6/drivers/usb/storage/unusual_devs.h
===
--- usb-2.6.orig/drivers/usb/storage/unusual_devs.h
+++ usb-2.6/drivers/usb/storage/unusual_devs.h
@@ -283,14 +283,14 @@ UNUSUAL_DEV( 0x04e6, 0x0002, 0x0100, 0x
UNUSUAL_DEV( 0x04e6, 0x0003, 0x, 0x,
Sandisk,
ImageMate SDDR09,
- US_SC_SCSI, US_PR_EUSB_SDDR09, NULL,
- US_FL_SINGLE_LUN ),
+ US_SC_SCSI, US_PR_EUSB_SDDR09, usb_stor_sddr09_init,
+ 0),
/* This entry is from [EMAIL PROTECTED] */
UNUSUAL_DEV( 0x04e6, 0x0005, 0x0100, 0x0208,
SCM Microsystems,
eUSB SmartMedia / CompactFlash Adapter,
- US_SC_SCSI, US_PR_DPCM_USB, sddr09_init,
+ US_SC_SCSI, US_PR_DPCM_USB, usb_stor_sddr09_dpcm_init,
0),
#endif
@@ -680,8 +680,8 @@ UNUSUAL_DEV( 0x0644, 0x, 0x0100, 0x
UNUSUAL_DEV( 0x066b, 0x0105, 0x0100, 0x0100,
Olympus,
Camedia MAUSB-2,
- US_SC_SCSI, US_PR_EUSB_SDDR09, NULL,
- US_FL_SINGLE_LUN ),
+ US_SC_SCSI, US_PR_EUSB_SDDR09, usb_stor_sddr09_init,
+ 0),
#endif
/* Reported by Darsen Lu [EMAIL PROTECTED] */
@@ -751,8 +751,8 @@ UNUSUAL_DEV( 0x0781, 0x0100, 0x0100, 0x
UNUSUAL_DEV( 0x0781, 0x0200, 0x, 0x,
Sandisk,
ImageMate SDDR-09,
- US_SC_SCSI, US_PR_EUSB_SDDR09, NULL,
- US_FL_SINGLE_LUN ),
+ US_SC_SCSI, US_PR_EUSB_SDDR09, usb_stor_sddr09_init,
+ 0),
#endif
#ifdef CONFIG_USB_STORAGE_FREECOM
Index: usb-2.6/drivers/usb/storage/sddr09.c
===
--- usb-2.6.orig/drivers/usb/storage/sddr09.c
+++ usb-2.6/drivers/usb/storage/sddr09.c
@@ -214,6 +214,20 @@ static void nand_store_ecc(unsigned char
* The actual driver starts here.
*/
+struct sddr09_card_info {
+ unsigned long capacity; /* Size of card in bytes */
+ int pagesize; /* Size of page in bytes */
+ int pageshift; /* log2 of pagesize */
+ int blocksize; /* Size of block in pages */
+ int blockshift; /* log2 of blocksize */
+ int blockmask; /* 2^blockshift - 1 */
+ int *lba_to_pba;/* logical to physical map */
+ int *pba_to_lba;/* physical to logical map */
+ int lbact; /* number of available pages */
+ int flags;
+#defineSDDR09_WP 1 /* write protected */
+};
+
/*
* On my 16MB card, control blocks have size 64 (16 real control bytes,
* and 48 junk bytes). In reality of course the card uses 16 control bytes,
@@ -1342,27 +1356,51 @@ sddr09_card_info_destructor(void *extra)
kfree(info-pba_to_lba);
}
-static void
-sddr09_init_card_info(struct us_data *us) {
- if (!us-extra) {
- us-extra = kmalloc(sizeof(struct sddr09_card_info), GFP_NOIO);
- if (us-extra) {
- memset(us-extra, 0, sizeof(struct sddr09_card_info));
- us-extra_destructor = sddr09_card_info_destructor;
- }
- }
+static int
+sddr09_common_init(struct us_data *us) {
+ int result;
+
+ /* set the configuration -- STALL is an acceptable response here */
+ if (us-pusb_dev-actconfig-desc.bConfigurationValue != 1) {
+ US_DEBUGP(active config #%d != 1 ??\n, us-pusb_dev
+ -actconfig-desc.bConfigurationValue);
+ return -EINVAL;
+ }
+
+ result = usb_reset_configuration(us-pusb_dev);
+ US_DEBUGP(Result of usb_reset_configuration is %d\n, result);
+ if (result == -EPIPE) {
+ US_DEBUGP(-- stall on control interface\n);
+ } else if (result != 0) {
+ /* it's not a stall, but another error -- time to bail */
+ US_DEBUGP(-- Unknown error. Rejecting device\n);
+ return -EINVAL;
+ }
+
+ us-extra = kzalloc(sizeof(struct sddr09_card_info), GFP_NOIO
[linux-usb-devel] PATCH as595: sddr09 cleanups
This is the second of three patches to prepare the sddr09 subdriver for
conversion to the Sim-SCSI framework. This patch (as595) updates the code
to use standard error values for return codes instead of our
special-purpose USB_STOR_TRANSPORT_... codes. The reverse update is then
needed in the transport routine, but with the Sim-SCSI framework that
routine will go away.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Acked-by: Andries Brouwer [EMAIL PROTECTED]
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
Greg, please apply.
Matt
Index: usb-2.6/drivers/usb/storage/sddr09.c
===
--- usb-2.6.orig/drivers/usb/storage/sddr09.c
+++ usb-2.6/drivers/usb/storage/sddr09.c
@@ -274,8 +274,11 @@ sddr09_send_command(struct us_data *us,
rc = usb_stor_ctrl_transfer(us, pipe, request, requesttype,
0, 0, xfer_data, xfer_len);
- return (rc == USB_STOR_XFER_GOOD ? USB_STOR_TRANSPORT_GOOD :
- USB_STOR_TRANSPORT_ERROR);
+ switch (rc) {
+ case USB_STOR_XFER_GOOD:return 0;
+ case USB_STOR_XFER_STALLED: return -EPIPE;
+ default:return -EIO;
+ }
}
static int
@@ -322,20 +325,12 @@ sddr09_request_sense(struct us_data *us,
command[4] = buflen;
result = sddr09_send_scsi_command(us, command, 12);
- if (result != USB_STOR_TRANSPORT_GOOD) {
- US_DEBUGP(request sense failed\n);
+ if (result)
return result;
- }
result = usb_stor_bulk_transfer_buf(us, us-recv_bulk_pipe,
sensebuf, buflen, NULL);
- if (result != USB_STOR_XFER_GOOD) {
- US_DEBUGP(request sense bulk in failed\n);
- return USB_STOR_TRANSPORT_ERROR;
- } else {
- US_DEBUGP(request sense worked\n);
- return USB_STOR_TRANSPORT_GOOD;
- }
+ return (result == USB_STOR_XFER_GOOD ? 0 : -EIO);
}
/*
@@ -383,7 +378,7 @@ sddr09_readX(struct us_data *us, int x,
result = sddr09_send_scsi_command(us, command, 12);
- if (result != USB_STOR_TRANSPORT_GOOD) {
+ if (result) {
US_DEBUGP(Result for send_control in sddr09_read2%d %d\n,
x, result);
return result;
@@ -395,9 +390,9 @@ sddr09_readX(struct us_data *us, int x,
if (result != USB_STOR_XFER_GOOD) {
US_DEBUGP(Result for bulk_transfer in sddr09_read2%d %d\n,
x, result);
- return USB_STOR_TRANSPORT_ERROR;
+ return -EIO;
}
- return USB_STOR_TRANSPORT_GOOD;
+ return 0;
}
/*
@@ -511,7 +506,7 @@ sddr09_erase(struct us_data *us, unsigne
result = sddr09_send_scsi_command(us, command, 12);
- if (result != USB_STOR_TRANSPORT_GOOD)
+ if (result)
US_DEBUGP(Result for send_control in sddr09_erase %d\n,
result);
@@ -569,7 +564,7 @@ sddr09_writeX(struct us_data *us,
result = sddr09_send_scsi_command(us, command, 12);
- if (result != USB_STOR_TRANSPORT_GOOD) {
+ if (result) {
US_DEBUGP(Result for send_control in sddr09_writeX %d\n,
result);
return result;
@@ -581,9 +576,9 @@ sddr09_writeX(struct us_data *us,
if (result != USB_STOR_XFER_GOOD) {
US_DEBUGP(Result for bulk_transfer in sddr09_writeX %d\n,
result);
- return USB_STOR_TRANSPORT_ERROR;
+ return -EIO;
}
- return USB_STOR_TRANSPORT_GOOD;
+ return 0;
}
/* erase address, write same address */
@@ -647,7 +642,7 @@ sddr09_read_sg_test_only(struct us_data
result = sddr09_send_scsi_command(us, command, 4*nsg+3);
- if (result != USB_STOR_TRANSPORT_GOOD) {
+ if (result) {
US_DEBUGP(Result for send_control in sddr09_read_sg %d\n,
result);
return result;
@@ -655,7 +650,7 @@ sddr09_read_sg_test_only(struct us_data
buf = (unsigned char *) kmalloc(bulklen, GFP_NOIO);
if (!buf)
- return USB_STOR_TRANSPORT_ERROR;
+ return -ENOMEM;
result = usb_stor_bulk_transfer_buf(us, us-recv_bulk_pipe,
buf, bulklen, NULL);
@@ -663,10 +658,10 @@ sddr09_read_sg_test_only(struct us_data
if (result != USB_STOR_XFER_GOOD) {
US_DEBUGP(Result for bulk_transfer in sddr09_read_sg %d\n,
result);
- return USB_STOR_TRANSPORT_ERROR;
+ return -EIO;
}
- return USB_STOR_TRANSPORT_GOOD;
+ return 0;
}
#endif
@@ -695,14 +690,13 @@ sddr09_read_status(struct us_data *us, u
command[1] = LUNBITS;
result
[linux-usb-devel] PATCH as596: sddr09 cleanups
This is the third of three patches to prepare the sddr09 subdriver for
conversion to the Sim-SCSI framework. This patch (as596) moves the
computation of the LBA to the start of the read/write routines, so that
addresses completely beyond the end of the device can be detected and
reported differently from transfers that are partially within the
device's capacity.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Acked-by: Andries Brouwer [EMAIL PROTECTED]
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
Greg, please apply.
Matt
Index: usb-2.6/drivers/usb/storage/sddr09.c
===
--- usb-2.6.orig/drivers/usb/storage/sddr09.c
+++ usb-2.6/drivers/usb/storage/sddr09.c
@@ -711,6 +711,13 @@ sddr09_read_data(struct us_data *us,
unsigned int len, index, offset;
int result;
+ // Figure out the initial LBA and page
+ lba = address info-blockshift;
+ page = (address info-blockmask);
+ maxlba = info-capacity (info-pageshift + info-blockshift);
+ if (lba = maxlba)
+ return -EIO;
+
// Since we only read in one block at a time, we have to create
// a bounce buffer and move the data a piece at a time between the
// bounce buffer and the actual transfer buffer.
@@ -722,11 +729,6 @@ sddr09_read_data(struct us_data *us,
return -ENOMEM;
}
- // Figure out the initial LBA and page
- lba = address info-blockshift;
- page = (address info-blockmask);
- maxlba = info-capacity (info-pageshift + info-blockshift);
-
// This could be made much more efficient by checking for
// contiguous LBA's. Another exercise left to the student.
@@ -928,13 +930,20 @@ sddr09_write_data(struct us_data *us,
unsigned int sectors) {
struct sddr09_card_info *info = (struct sddr09_card_info *) us-extra;
- unsigned int lba, page, pages;
+ unsigned int lba, maxlba, page, pages;
unsigned int pagelen, blocklen;
unsigned char *blockbuffer;
unsigned char *buffer;
unsigned int len, index, offset;
int result;
+ // Figure out the initial LBA and page
+ lba = address info-blockshift;
+ page = (address info-blockmask);
+ maxlba = info-capacity (info-pageshift + info-blockshift);
+ if (lba = maxlba)
+ return -EIO;
+
// blockbuffer is used for reading in the old data, overwriting
// with the new data, and performing ECC calculations
@@ -961,10 +970,6 @@ sddr09_write_data(struct us_data *us,
return -ENOMEM;
}
- // Figure out the initial LBA and page
- lba = address info-blockshift;
- page = (address info-blockmask);
-
result = 0;
index = offset = 0;
@@ -975,6 +980,14 @@ sddr09_write_data(struct us_data *us,
pages = min(sectors, info-blocksize - page);
len = (pages info-pageshift);
+ /* Not overflowing capacity? */
+ if (lba = maxlba) {
+ US_DEBUGP(Error: Requested lba %u exceeds
+ maximum %u\n, lba, maxlba);
+ result = -EIO;
+ break;
+ }
+
// Get the data from the transfer buffer
usb_stor_access_xfer_buf(buffer, len, us-srb,
index, offset, FROM_XFER_BUF);
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
But where are the THEMES?! How do you expect me to use an OS without
themes?!
-- Stef
User Friendly, 10/9/1998
pgpiWMFXREmNc.pgp
Description: PGP signature
[linux-usb-devel] PATCH: add alauda support
This patch adds another usb-storage subdriver, which supports two fairly
old dual-XD/SmartMedia reader-writers (USB1.1 devices).
This driver was written by Daniel Drake [EMAIL PROTECTED] -- he notes that
he wrote this driver without specs, however a vendor-supplied GPL driver
for the previous generation of products (sma03) did prove to be quite
useful, as did the sddr09 driver which also has to deal with low-level
physical block layout on SmartMedia.
The original patch has been reformed by me, as it clashed with the libusual
patches.
We really need to consolidate some of this common SmartMedia code, and get
together with the MTD guys to share it with them as well.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
Greg, please apply.
Matt
Index: linux-2.6.15-rc2/drivers/usb/storage/alauda.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.15-rc2/drivers/usb/storage/alauda.c 2005-12-04
13:53:40.0 -0800
@@ -0,0 +1,1119 @@
+/*
+ * Driver for Alauda-based card readers
+ *
+ * Current development and maintenance by:
+ * (c) 2005 Daniel Drake [EMAIL PROTECTED]
+ *
+ * The 'Alauda' is a chip manufacturered by RATOC for OEM use.
+ *
+ * Alauda implements a vendor-specific command set to access two media reader
+ * ports (XD, SmartMedia). This driver converts SCSI commands to the commands
+ * which are accepted by these devices.
+ *
+ * The driver was developed through reverse-engineering, with the help of the
+ * sddr09 driver which has many similarities, and with some help from the
+ * (very old) vendor-supplied GPL sma03 driver.
+ *
+ * For protocol info, see http://alauda.sourceforge.net
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include scsi/scsi.h
+#include scsi/scsi_cmnd.h
+#include scsi/scsi_device.h
+
+#include usb.h
+#include transport.h
+#include protocol.h
+#include debug.h
+#include alauda.h
+
+#define short_pack(lsb,msb) ( ((u16)(lsb)) | ( ((u16)(msb))8 ) )
+#define LSB_of(s) ((s)0xFF)
+#define MSB_of(s) ((s)8)
+
+#define MEDIA_PORT(us) us-srb-device-lun
+#define MEDIA_INFO(us) ((struct alauda_info *)us-extra)-port[MEDIA_PORT(us)]
+
+#define PBA_LO(pba) ((pba 0xF) 5)
+#define PBA_HI(pba) (pba 3)
+#define PBA_ZONE(pba) (pba 11)
+
+/*
+ * Media handling
+ */
+
+struct alauda_card_info {
+ unsigned char id; /* id byte */
+ unsigned char chipshift;/* 1cs bytes total capacity */
+ unsigned char pageshift;/* 1ps bytes in a page */
+ unsigned char blockshift; /* 1bs pages per block */
+ unsigned char zoneshift;/* 1zs blocks per zone */
+};
+
+static struct alauda_card_info alauda_card_ids[] = {
+ /* NAND flash */
+ { 0x6e, 20, 8, 4, 8}, /* 1 MB */
+ { 0xe8, 20, 8, 4, 8}, /* 1 MB */
+ { 0xec, 20, 8, 4, 8}, /* 1 MB */
+ { 0x64, 21, 8, 4, 9}, /* 2 MB */
+ { 0xea, 21, 8, 4, 9}, /* 2 MB */
+ { 0x6b, 22, 9, 4, 9}, /* 4 MB */
+ { 0xe3, 22, 9, 4, 9}, /* 4 MB */
+ { 0xe5, 22, 9, 4, 9}, /* 4 MB */
+ { 0xe6, 23, 9, 4, 10}, /* 8 MB */
+ { 0x73, 24, 9, 5, 10}, /* 16 MB */
+ { 0x75, 25, 9, 5, 10}, /* 32 MB */
+ { 0x76, 26, 9, 5, 10}, /* 64 MB */
+ { 0x79, 27, 9, 5, 10}, /* 128 MB */
+ { 0x71, 28, 9, 5, 10}, /* 256 MB */
+
+ /* MASK ROM */
+ { 0x5d, 21, 9, 4, 8}, /* 2 MB */
+ { 0xd5, 22, 9, 4, 9}, /* 4 MB */
+ { 0xd6, 23, 9, 4, 10}, /* 8 MB */
+ { 0x57, 24, 9, 4, 11}, /* 16 MB */
+ { 0x58, 25, 9, 4, 12}, /* 32 MB */
+ { 0,}
+};
+
+static struct alauda_card_info *alauda_card_find_id(unsigned char id) {
+ int i;
+
+ for (i = 0; alauda_card_ids[i].id != 0; i++)
+ if (alauda_card_ids[i].id == id)
+ return (alauda_card_ids[i]);
+ return NULL;
+}
+
+/*
+ * ECC computation.
+ */
+
+static unsigned char parity[256];
+static unsigned char ecc2[256];
+
+static void nand_init_ecc(void) {
+ int i, j, a;
+
+ parity[0] = 0;
+ for (i = 1; i 256; i++)
+ parity[i] = (parity[i(i-1)] ^ 1);
+
+ for (i = 0; i 256; i++) {
+ a = 0;
+ for (j = 0; j 8; j++) {
+ if (i
[linux-usb-devel] PATCH: update MAINTAINERS
Someone recently pointed out to me that the MAINTAINERS entry for usb-storage was, perhaps, in need of changing. Signed-off-by: Matthew Dharm [EMAIL PROTECTED] Greg, please apply. Matt Index: linux-2.6.15-rc2/MAINTAINERS === --- linux-2.6.15-rc2.orig/MAINTAINERS 2005-11-27 11:29:34.0 -0800 +++ linux-2.6.15-rc2/MAINTAINERS2005-12-04 21:50:29.0 -0800 @@ -2629,7 +2629,7 @@ P: Matthew Dharm M: [EMAIL PROTECTED] L: linux-usb-users@lists.sourceforge.net -L: linux-usb-devel@lists.sourceforge.net +L: [EMAIL PROTECTED] S: Maintained W: http://www.one-eyed-alien.net/~mdharm/linux-usb/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver NYET! The evil stops here! -- Pitr User Friendly, 6/22/1998 pgpnIBC6bmo9t.pgp Description: PGP signature
[linux-usb-devel] Re: HP iLO needs FSBR
continuously retries transfers regarless of how long they're taking. It also appears (from uhci_inc_fsbr) that FSBR isn't turned on for URBs that request NO_FSBR, but if some other URB turns on FSBR, urbs that didn't request it seem to benefit from it. I'm not sure if this is the behavior the developer had in mind (not enough comments to read programmer intent), but it looks like that's how it works. In any case, by requesting NO_FSBR in the urbs from the storage driver, it appears that we prevent stall_callback from breaking the cycle in the work-to-do list, thus keeping the controller busy with our slow-to-respond transfers from iLO. If the uhci driver does break the cycle in the work-to-do list, then our slow-to-respond transfers suffer their normal slowness plus the additional end-of-frame idle time (e.g. the UHCI controller hits the terminate bit and idles out the rest of the frame). --- The patch appears safe from regressions, but I was unable to find a box to test it, so I'm taking HP word that it actually cures the symptoms. I would like to have it accepted. But also, I am curious if we have some performance anomalies in uhci-hcd. They claim that 2.4 worked. What actually worked was probably usb-uhci, because that was default in RHL RHEL. -- Pete -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver A: The most ironic oxymoron wins ... DP: Microsoft Works A: Uh, okay, you win. -- A.J. Dust Puppy User Friendly, 1/18/1998 pgpOEgYQTB35i.pgp Description: PGP signature
[linux-usb-devel] PATCH: usb-storage: move GetMaxLUN later in time
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 [EMAIL PROTECTED]
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
Index: usb-2.6/drivers/usb/storage/transport.c
===
--- usb-2.6.orig/drivers/usb/storage/transport.c
+++ usb-2.6/drivers/usb/storage/transport.c
@@ -923,6 +923,7 @@ int usb_stor_Bulk_max_lun(struct us_data
int result;
/* issue the command */
+ us-iobuf[0] = 0;
result = usb_stor_control_msg(us, us-recv_ctrl_pipe,
US_BULK_GET_MAX_LUN,
USB_DIR_IN | USB_TYPE_CLASS |
Index: usb-2.6/drivers/usb/storage/usb.c
===
--- usb-2.6.orig/drivers/usb/storage/usb.c
+++ usb-2.6/drivers/usb/storage/usb.c
@@ -747,25 +747,13 @@
return -ENOMEM;
}
- /* Lock the device while we carry out the next two operations */
- down(us-dev_semaphore);
-
- /* For bulk-only devices, determine the max LUN value */
- if (us-protocol == US_PR_BULK) {
- p = usb_stor_Bulk_max_lun(us);
- if (p 0) {
- up(us-dev_semaphore);
- return p;
- }
- us-max_lun = p;
- }
-
/* Just before we start our control thread, initialize
* the device if it needs initialization */
- if (us-unusual_dev-initFunction)
- us-unusual_dev-initFunction(us);
-
- up(us-dev_semaphore);
+ if (us-unusual_dev-initFunction) {
+ p = us-unusual_dev-initFunction(us);
+ if (p)
+ return p;
+ }
/* Start up our control thread */
p = kernel_thread(usb_stor_control_thread, us, CLONE_VM);
@@ -909,6 +894,14 @@ retry:
/* If the device is still connected, perform the scanning */
if (!test_bit(US_FLIDX_DISCONNECTING, us-flags)) {
+
+ /* For bulk-only devices, determine the max LUN value */
+ if (us-protocol == US_PR_BULK
+ !(us-flags US_FL_SINGLE_LUN)) {
+ down(us-dev_semaphore);
+ us-max_lun = usb_stor_Bulk_max_lun(us);
+ up(us-dev_semaphore);
+ }
scsi_scan_host(us_to_host(us));
printk(KERN_DEBUG usb-storage: device scan complete\n);
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
Stef, you just got beaten by a ball of DIRT.
-- Greg
User Friendly, 12/7/1997
pgp8RLFRmLDTQ.pgp
Description: PGP signature
[linux-usb-devel] PATCH: usb-storage: allocate separate sense buffer
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.
Greg, please apply.
Matt
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
Index: usb-2.6/drivers/usb/storage/usb.h
===
--- usb-2.6.orig/drivers/usb/storage/usb.h
+++ usb-2.6/drivers/usb/storage/usb.h
@@ -117,6 +117,7 @@ enum { US_DO_ALL_FLAGS };
*/
#define US_IOBUF_SIZE 64 /* Size of the DMA-mapped I/O buffer */
+#define US_SENSE_SIZE 18 /* Size of the autosense data buffer */
typedef int (*trans_cmnd)(struct scsi_cmnd *, struct us_data*);
typedef int (*trans_reset)(struct us_data*);
@@ -168,6 +169,7 @@ struct us_data {
struct usb_ctrlrequest *cr; /* control requests */
struct usb_sg_request current_sg; /* scatter-gather req. */
unsigned char *iobuf; /* I/O buffer */
+ unsigned char *sensebuf; /* sense data buffer*/
dma_addr_t cr_dma; /* buffer DMA addresses */
dma_addr_t iobuf_dma;
Index: usb-2.6/drivers/usb/storage/transport.c
===
--- usb-2.6.orig/drivers/usb/storage/transport.c
+++ usb-2.6/drivers/usb/storage/transport.c
@@ -636,11 +636,11 @@ void usb_stor_invoke_transport(struct sc
/* use the new buffer we have */
old_request_buffer = srb-request_buffer;
- srb-request_buffer = srb-sense_buffer;
+ srb-request_buffer = us-sensebuf;
/* set the buffer length for transfer */
old_request_bufflen = srb-request_bufflen;
- srb-request_bufflen = 18;
+ srb-request_bufflen = US_SENSE_SIZE;
/* set up for no scatter-gather use */
old_sg = srb-use_sg;
@@ -652,6 +652,7 @@ void usb_stor_invoke_transport(struct sc
temp_result = us-transport(us-srb, us);
/* let's clean up right away */
+ memcpy(srb-sense_buffer, us-sensebuf, US_SENSE_SIZE);
srb-resid = old_resid;
srb-request_buffer = old_request_buffer;
srb-request_bufflen = old_request_bufflen;
Index: usb-2.6/drivers/usb/storage/usb.c
===
--- usb-2.6.orig/drivers/usb/storage/usb.c
+++ usb-2.6/drivers/usb/storage/usb.c
@@ -462,6 +462,12 @@ static int associate_dev(struct us_data
US_DEBUGP(I/O buffer allocation failed\n);
return -ENOMEM;
}
+
+ us-sensebuf = kmalloc(US_SENSE_SIZE, GFP_KERNEL);
+ if (!us-sensebuf) {
+ US_DEBUGP(Sense buffer allocation failed\n);
+ return -ENOMEM;
+ }
return 0;
}
@@ -807,6 +813,8 @@ static void dissociate_dev(struct us_dat
{
US_DEBUGP(-- %s\n, __FUNCTION__);
+ kfree(us-sensebuf);
+
/* Free the device-related DMA-mapped buffers */
if (us-cr)
usb_buffer_free(us-pusb_dev, sizeof(*us-cr), us-cr,
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
G: Money isn't everything, A.J.
AJ: Who convinced you of that?
G: The Chief, at my last salary review.
-- Mike and Greg
User Friendly, 11/3/1998
pgpgc29kkIVS2.pgp
Description: PGP signature
[linux-usb-devel] PATCH: usb-storage: implement minimal PM
This patch from Alan Stern started as as568. It has been rediffed against
a current tree.
This patch adds minimal suspend/resume support to usb-storage. Just enough
for it to qualify as PM-aware.
Greg, please apply.
Matt
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
Index: usb-2.6/drivers/usb/storage/usb.c
===
--- usb-2.6.orig/drivers/usb/storage/usb.c
+++ usb-2.6/drivers/usb/storage/usb.c
@@ -111,11 +111,6 @@ static atomic_t total_threads = ATOMIC_I
static DECLARE_COMPLETION(threads_gone);
-static int storage_probe(struct usb_interface *iface,
-const struct usb_device_id *id);
-
-static void storage_disconnect(struct usb_interface *iface);
-
/* The entries in this table, except for final ones here
* (USB_MASS_STORAGE_CLASS and the empty entry), correspond,
* line for line with the entries of us_unsuaul_dev_list[].
@@ -233,13 +228,40 @@ static struct us_unusual_dev us_unusual_
{ NULL }
};
-static struct usb_driver usb_storage_driver = {
- .owner =THIS_MODULE,
- .name = usb-storage,
- .probe =storage_probe,
- .disconnect = storage_disconnect,
- .id_table = storage_usb_ids,
-};
+
+#ifdef CONFIG_PM /* Minimal support for suspend and resume */
+
+static int storage_suspend(struct usb_interface *iface, pm_message_t message)
+{
+ struct us_data *us = usb_get_intfdata(iface);
+
+ /* Wait until no command is running */
+ down(us-dev_semaphore);
+
+ US_DEBUGP(%s\n, __FUNCTION__);
+ iface-dev.power.power_state.event = message.event;
+
+ /* When runtime PM is working, we'll set a flag to indicate
+* whether we should autoresume when a SCSI request arrives. */
+
+ up(us-dev_semaphore);
+ return 0;
+}
+
+static int storage_resume(struct usb_interface *iface)
+{
+ struct us_data *us = usb_get_intfdata(iface);
+
+ down(us-dev_semaphore);
+
+ US_DEBUGP(%s\n, __FUNCTION__);
+ iface-dev.power.power_state.event = PM_EVENT_ON;
+
+ up(us-dev_semaphore);
+ return 0;
+}
+
+#endif /* CONFIG_PM */
/*
* fill_inquiry_response takes an unsigned char array (which must
@@ -1038,6 +1060,18 @@ static void storage_disconnect(struct us
* Initialization and registration
***/
+static struct usb_driver usb_storage_driver = {
+ .owner =THIS_MODULE,
+ .name = usb-storage,
+ .probe =storage_probe,
+ .disconnect = storage_disconnect,
+#ifdef CONFIG_PM
+ .suspend = storage_suspend,
+ .resume = storage_resume,
+#endif
+ .id_table = storage_usb_ids,
+};
+
static int __init usb_stor_init(void)
{
int retval;
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
G: Baaap booop BAHHHP.
Mir: 9600 Baud?
Mik: No, no! 9600 goes baap booop, not booop bahhhp!
-- Greg, Miranda and Mike
User Friendly, 12/31/1998
pgpeC3e3W0W0v.pgp
Description: PGP signature
[linux-usb-devel] PATCH: usb-storage: use kthread API
This patch is originally from Alan Stern (as569). It has been rediffed
against a current tree.
This patch converts usb-storage to use the kthread API for creating its
control and scanning threads. The new code doesn't use kthread_stop
because the threads need (or will need in the future) to exit
asynchronously.
Greg, please apply.
Matt
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
Index: usb-2.6/drivers/usb/storage/usb.h
===
--- usb-2.6.orig/drivers/usb/storage/usb.h
+++ usb-2.6/drivers/usb/storage/usb.h
@@ -160,9 +160,6 @@ struct us_data {
struct scsi_cmnd*srb;/* current srb */
unsigned inttag; /* current dCBWTag */
- /* thread information */
- int pid; /* control thread */
-
/* control and bulk communications data */
struct urb *current_urb;/* USB requests */
struct usb_ctrlrequest *cr; /* control requests */
Index: usb-2.6/drivers/usb/storage/usb.c
===
--- usb-2.6.orig/drivers/usb/storage/usb.c
+++ usb-2.6/drivers/usb/storage/usb.c
@@ -54,6 +54,7 @@
#include linux/module.h
#include linux/init.h
#include linux/slab.h
+#include linux/kthread.h
#include scsi/scsi.h
#include scsi/scsi_cmnd.h
@@ -310,22 +311,7 @@ static int usb_stor_control_thread(void
struct us_data *us = (struct us_data *)__us;
struct Scsi_Host *host = us_to_host(us);
- lock_kernel();
-
- /*
-* This thread doesn't need any user-level access,
-* so get rid of all our resources.
-*/
- daemonize(usb-storage);
current-flags |= PF_NOFREEZE;
- unlock_kernel();
-
- /* acquire a reference to the host, so it won't be deallocated
-* until we're ready to exit */
- scsi_host_get(host);
-
- /* signal that we've started the thread */
- complete((us-notify));
for(;;) {
US_DEBUGP(*** thread sleeping.\n);
@@ -762,6 +748,7 @@ static int get_pipes(struct us_data *us)
static int usb_stor_acquire_resources(struct us_data *us)
{
int p;
+ struct task_struct *th;
us-current_urb = usb_alloc_urb(0, GFP_KERNEL);
if (!us-current_urb) {
@@ -790,17 +777,19 @@ static int usb_stor_acquire_resources(st
up(us-dev_semaphore);
/* Start up our control thread */
- p = kernel_thread(usb_stor_control_thread, us, CLONE_VM);
- if (p 0) {
+ th = kthread_create(usb_stor_control_thread, us, usb-storage);
+ if (IS_ERR(th)) {
printk(KERN_WARNING USB_STORAGE
Unable to start control thread\n);
- return p;
+ return PTR_ERR(th);
}
- us-pid = p;
- atomic_inc(total_threads);
- /* Wait for the thread to start */
- wait_for_completion((us-notify));
+ /* Take a reference to the host for the control thread and
+* count it among all the threads we have launched. Then
+* start it up. */
+ scsi_host_get(us_to_host(us));
+ atomic_inc(total_threads);
+ wake_up_process(th);
return 0;
}
@@ -894,21 +883,6 @@ static int usb_stor_scan_thread(void * _
{
struct us_data *us = (struct us_data *)__us;
- /*
-* This thread doesn't need any user-level access,
-* so get rid of all our resources.
-*/
- lock_kernel();
- daemonize(usb-stor-scan);
- unlock_kernel();
-
- /* Acquire a reference to the host, so it won't be deallocated
-* until we're ready to exit */
- scsi_host_get(us_to_host(us));
-
- /* Signal that we've started the thread */
- complete((us-notify));
-
printk(KERN_DEBUG
usb-storage: device found at %d\n, us-pusb_dev-devnum);
@@ -945,6 +919,7 @@ static int storage_probe(struct usb_inte
struct us_data *us;
const int id_index = id - storage_usb_ids;
int result;
+ struct task_struct *th;
US_DEBUGP(USB Mass Storage device detected\n);
@@ -1025,17 +1000,21 @@ static int storage_probe(struct usb_inte
}
/* Start up the thread for delayed SCSI-device scanning */
- result = kernel_thread(usb_stor_scan_thread, us, CLONE_VM);
- if (result 0) {
+ th = kthread_create(usb_stor_scan_thread, us, usb-stor-scan);
+ if (IS_ERR(th)) {
printk(KERN_WARNING USB_STORAGE
Unable to start the device-scanning thread\n);
quiesce_and_remove_host(us);
+ result = PTR_ERR(th);
goto BadDevice;
}
- atomic_inc(total_threads);
- /* Wait for the thread to start */
- wait_for_completion((us-notify
[linux-usb-devel] Re: [usb-storage] usb: drivers/usb/storage/libusual
On Sat, Oct 08, 2005 at 02:01:32PM -0700, Pete Zaitcev wrote: This patch adds a shim driver libusual, which routes devices between usb-storage and ub according to the common table, based on unusual_devs.h. The help and example syntax is in Kconfig. Signed-off-by: Pete Zaitcev [EMAIL PROTECTED] --- I think libusual is ready for Andrew's tree now. I realize that the use of request_module is an inkblot in this copybook, so maybe it's not the time for Linus' tree yet. Another concern I have is if we have any races with hotplug, udev, and HAL. I haven't heard from Adrian yet, but I suppose it's a good sign. No word from Matt Dharm either, which is not so good... But I do have Alan Stern's buy-in. Well, I guess it's time for me to comment, then. I have been watching with great interest. I have to say, I totally agree that this is a problem that needs solving. The current situation is a mess But, I'm not sure this is much better. It's certainly different, but I fear that we're going to spend a lot of time explaining to end-users a new and less-than-totally-obvious system. Technically, this is much better than what we have. I'm just not sure about the end user experience. And I think I'm totally convinced now that request_module() needs some serious help. Either it needs to go away entirely, or be replaced by a helper, such that request_module() gets a module loaded, but module binding to a device is controlled via another mechanism. Overall, send it to Andrew's tree. But I'd really like to see it live there for an extended period of time before going to Linus. And I'd also like to see some ideas for the final solution, which would apply to HID devices with the same problem. I hate solving problems twice. It creates twice as much work for everyone, including distro folks and end-users. Let's figure this out as a more generic driver-binding problem for all drivers once and for all. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver How would you like this tie wrapped around your hairy round head? -- Greg User Friendly, 9/2/1998 pgpffdZgEGeVA.pgp Description: PGP signature
Re: [linux-usb-devel] Usb storage devices auto-promoted to scsi2 spec issue
On Wed, Sep 14, 2005 at 10:45:37AM -0700, Timothy Thelin wrote: I was curious about the reasoning behind this decision and how to fix an issue that came up because of it. The reasoning goes something like this: There are lots of devices which report 0, but need the SCSI-II 10-byte commands to work. I have some time to help in solving the above. But what do people think the solution should be? Here are some ideas floating in my head: 1) Promote the scsi0 device to scsi3 (instead of scsi2) since it most likely follows scsi3 forms of commands that it happens to support That's not going to fly. Lots of devices report 0 and follow 2, not 3. SCSI 3 triggers new and exciting behavior from SCSI core. 2) Leave the scsi0 device as scsi0, and make sure the scsi stack is aware of scsi0 devices (i.e. don't stick LUN info into cdb[ 1 ] ) That will break all the devices which report 0 but need 10-bit commands ala SCSI-II. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I need a computer? -- Customer User Friendly, 2/19/1998 pgp9ekCM0vzjI.pgp Description: PGP signature
Re: [linux-usb-devel] Usb storage devices auto-promoted to scsi2 spec issue
On Wed, Sep 14, 2005 at 08:29:19PM +0200, Christian Iversen wrote: On Wednesday 14 September 2005 19:45, Timothy Thelin wrote: I was curious about the reasoning behind this decision and how to fix an issue that came up because of it. ... (1) Is easy to do, but is it going to cause other issues? I'd imagine any *usb storage* device that reports scsi0 really implements the scsi3 form of the commands that it happens to support. (2) Is more invasive, but is probably more of a correct solution. This will require a larger effort involving multiple groups coordinating the efforts. I can't really comment on the rest of your mail, even though the points seem well thought-out, but I would like to offer just a single comment: Why would a usb-storage device ever report itself as scsi0 if it actually supports scsi3? Is it because the USB/ATA bridge spec doesn't support asking the device it self, so the usb-subsystem just makes an (un? ;)-educated guess? Or is it because it is possible, but the devices can't be trusted to tell the truth? It's the last one. Lots and lots of devices lie outright about this. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver S: Another stupid question? G: There's no such thing as a stupid question, only stupid people. -- Stef and Greg User Friendly, 7/15/1998 pgpiVVElJ7d18.pgp Description: PGP signature
Re: [linux-usb-devel] Usb storage devices auto-promoted to scsi2 spec issue
On Wed, Sep 14, 2005 at 12:19:39PM -0700, Timothy Thelin wrote: Why would a usb-storage device ever report itself as scsi0 if it actually supports scsi3? Is it because the USB/ATA bridge spec doesn't support asking the device it self, so the usb-subsystem just makes an (un? ;)-educated guess? Or is it because it is possible, but the devices can't be trusted to tell the truth? It's the last one. Lots and lots of devices lie outright about this. Matt I don't suppose you might have an alternative solution for allowing scsi0 devices to accept things like the SCSI-ATA passthru cdb unmangled by LUN info then? What's the command source? If you're coming in via the SG interface, there's a command flag to set which prevents LUN info from being imposed on the CDB. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver NYET! The evil stops here! -- Pitr User Friendly, 6/22/1998 pgpuTGGnNzQtW.pgp Description: PGP signature
Re: [linux-usb-devel] Usb storage devices auto-promoted to scsi2 spec issue
On Wed, Sep 14, 2005 at 01:18:52PM -0700, Timothy Thelin wrote: It ought to be possible to add a flag that would prevent the SCSI midlayer from overlaying the LUN bits on top of cdb[1]. Then we could still set the revision number to 2 and you would be happy. Sounds plausable, but i'm not an expert on the Linux scsi stack to know where the flag would exist. One idea is to add the flag to SG_IO, since both vendor and SCSI-ATA passthru cdb's would use this mechanism (most likely). The purpose of the flag could be to say don't modify the cdb in any way, a solution more general than just don't add LUN info That flag already exists. SG_FLAG_LUN_INHIBIT -- see sg.torque.net for details. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver YOU SEE!!?? It's like being born with only one nipple! -- Erwin User Friendly, 10/19/1998 pgpOt1e1IzeTv.pgp Description: PGP signature
[linux-usb-devel] Re: [usb-storage] Creating two disks from a usb-storage subdriver
On Thu, Sep 08, 2005 at 11:33:04PM +0100, Daniel Drake wrote: Hi, I am developing a usb-storage subdriver for a non-standard device which has a SmartMedia port and an XD media port. I'm at the stage where I'd like the driver to support both ports simultaneously, i.e. creating /dev/sda and /dev/sdb, one for each port. How can I instruct my driver to create two disks? I tried setting max_lun to 1 in usb.c:get_transport but that didn't make any difference, even with CONFIG_SCSI_MULTI_LUN in the kernel. This is the right way to go. I also tried adding the US_FL_SCM_MULT_TARG flag to my device in unusual_devs.h. That resulted in 8 scsi disks appearing, no matter what the setting of max_lun is. Each disk was on lun 0 and had device numbers from 0-7. No, this flag is for something else entirely. If you set max_lun to 1 and compile with SCSI_MULTI_LUN, are you seeing the SCSI scan for multiple LUNs? What your subdriver needs to do is to decode the lun field of the SRB to decide how to handle the device. As long as SCSI sees responses to INQUIRY commands with lun=0 and lun=1, you'll get two devices. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver God, root, what is difference? -- Pitr User Friendly, 11/11/1999 pgp8fXox3Cm4F.pgp Description: PGP signature
Re: [linux-usb-devel] Genesys USB 2.0 enclosures
On Sat, Sep 03, 2005 at 09:53:19PM -0400, Alan Stern wrote: On Sat, 3 Sep 2005, Jan De Luyck wrote: I've posted in the past about problems with these enclosures - increasing the delay seems to fix it, albeit temporarily. The further you go in using the disk in such an enclosure, the higher the udelay() had to be - atleast that's what I'm seeing here (I've got two of these now :/ ) One permanent fix is adding a powered USB-hub in between the drive enclosures and the computer. Since I've done that, I've no longer seen any of the problems (i've attached the 'fault' log). Weird but true, since the drives come with their own powersupply. Hope this helps anyone in the future running into the same problem. This one certainly goes into the Bizarro file. Just out of curiosity -- when you use the powered hub, does the drive work even if you remove that delay completely? Aren't USB 2.0 hubs more intelligent as part of the requirement to support 1.1 and 2.0 devices? I wonder if it's really a 2.0 drive, and if the timing is different enough with the hub to make a difference. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver THEY CASTRATED MY QUAKE BITS! I WANT THEM BACK -- Greg User Friendly, 3/27/1998 pgp5qykU1gpXL.pgp Description: PGP signature
[linux-usb-devel] [EMAIL PROTECTED]: [PATCH as550] Fix messed-up locking]
This is patch as550 from Alan Stern.
Apparently someone changed the SCSI core so that it no longer holds the
host lock when doing a device or bus reset. usb-storage was updated at
the time, but the change was done carelessly. Some of the code depends on
that lock being held.
This patch reintroduces the host lock where needed and tries to clarify
the comments explaining why the lock is necessary. It also moves the code
that clears the TIMED_OUT and ABORTING bitflags so that it executes as
soon as the timed-out command has completed (and while the host lock is
held).
Greg, please apply.
Matt
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
Index: usb-2.6/drivers/usb/storage/scsiglue.c
===
--- usb-2.6.orig/drivers/usb/storage/scsiglue.c
+++ usb-2.6/drivers/usb/storage/scsiglue.c
@@ -227,42 +227,42 @@ static int queuecommand(struct scsi_cmnd
***/
/* Command timeout and abort */
-/* This is always called with scsi_lock(host) held */
static int command_abort(struct scsi_cmnd *srb)
{
struct us_data *us = host_to_us(srb-device-host);
US_DEBUGP(%s called\n, __FUNCTION__);
+ /* us-srb together with the TIMED_OUT, RESETTING, and ABORTING
+* bits are protected by the host lock. */
+ scsi_lock(us_to_host(us));
+
/* Is this command still active? */
if (us-srb != srb) {
+ scsi_unlock(us_to_host(us));
US_DEBUGP (-- nothing to abort\n);
return FAILED;
}
/* Set the TIMED_OUT bit. Also set the ABORTING bit, but only if
* a device reset isn't already in progress (to avoid interfering
-* with the reset). To prevent races with auto-reset, we must
-* stop any ongoing USB transfers while still holding the host
-* lock. */
+* with the reset). Note that we must retain the host lock while
+* calling usb_stor_stop_transport(); otherwise it might interfere
+* with an auto-reset that begins as soon as we release the lock. */
set_bit(US_FLIDX_TIMED_OUT, us-flags);
if (!test_bit(US_FLIDX_RESETTING, us-flags)) {
set_bit(US_FLIDX_ABORTING, us-flags);
usb_stor_stop_transport(us);
}
+ scsi_unlock(us_to_host(us));
/* Wait for the aborted command to finish */
wait_for_completion(us-notify);
-
- /* Reacquire the lock and allow USB transfers to resume */
- clear_bit(US_FLIDX_ABORTING, us-flags);
- clear_bit(US_FLIDX_TIMED_OUT, us-flags);
return SUCCESS;
}
/* This invokes the transport reset mechanism to reset the state of the
* device */
-/* This is always called with scsi_lock(host) held */
static int device_reset(struct scsi_cmnd *srb)
{
struct us_data *us = host_to_us(srb-device-host);
@@ -279,7 +279,6 @@ static int device_reset(struct scsi_cmnd
}
/* Simulate a SCSI bus reset by resetting the device's USB port. */
-/* This is always called with scsi_lock(host) held */
static int bus_reset(struct scsi_cmnd *srb)
{
struct us_data *us = host_to_us(srb-device-host);
@@ -291,7 +290,6 @@ static int bus_reset(struct scsi_cmnd *s
result = usb_stor_port_reset(us);
up((us-dev_semaphore));
- /* lock the host for the return */
return result 0 ? FAILED : SUCCESS;
}
Index: usb-2.6/drivers/usb/storage/usb.c
===
--- usb-2.6.orig/drivers/usb/storage/usb.c
+++ usb-2.6/drivers/usb/storage/usb.c
@@ -392,11 +392,16 @@ SkipForAbort:
/* If an abort request was received we need to signal that
* the abort has finished. The proper test for this is
* the TIMED_OUT flag, not srb-result == DID_ABORT, because
-* a timeout/abort request might be received after all the
-* USB processing was complete. */
- if (test_bit(US_FLIDX_TIMED_OUT, us-flags))
+* the timeout might have occurred after the command had
+* already completed with a different result code. */
+ if (test_bit(US_FLIDX_TIMED_OUT, us-flags)) {
complete((us-notify));
+ /* Allow USB transfers to resume */
+ clear_bit(US_FLIDX_ABORTING, us-flags);
+ clear_bit(US_FLIDX_TIMED_OUT, us-flags);
+ }
+
/* finished working on this command */
us-srb = NULL;
scsi_unlock(host);
- End forwarded message -
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
Oh BAY-bee.
-- Dust Puppy to Greg
User Friendly, 12/13/1997
Re: [linux-usb-devel] Re: [PATCH] USB: Fix HP8200 detection in shuttle_usbat
I just saw a It's still not perfect message on linux-usb-users regarding this patch... Should we hold off for a little longer? I'm thinking so... Matt On Wed, Aug 10, 2005 at 06:30:04PM +0100, Daniel Drake wrote: Adding flash-device support to the shuttle_usbat driver in 2.6.11 introduced the need to detect which type of device we are dealing with: CDRW drive, or flash media reader. The detection routine used turned out to not work for HP8200 CDRW users, who saw their devices being detected as a flash disk. This patch (which has been tested on both flash and cdrom) removes some unnecessary code, moves device detection to much later during initialization, and introduces a new detection routine which appears to work. If acceptable, please include in 2.6.13. Signed-off-by: Daniel Drake [EMAIL PROTECTED] -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Sir, for the hundreth time, we do NOT carry 600-round boxes of belt-fed suction darts! -- Salesperson to Greg User Friendly, 12/30/1997 pgpIBtobzxIYj.pgp Description: PGP signature
[linux-usb-devel] Re: [Linux-usb-users] Looking for users to test Onetouch driver with more Maxtor Onetouch productIDs
On Fri, Jul 29, 2005 at 02:31:17AM -0400, Nick Sillik wrote: I have written a driver that adds usability to the OneTouch Button on Maxtor External USB Hard Drives. Using an unusual device entry it declares an extra init function which claims the interrupt endpoint associated with this button. Currently it only supporst the vendorID:productID 0d49:7010. I'd be interested in adding new entries to the unusual_devs.h file to support more of the drives. (The productID number changes according to the size of the drive) If you have a different product ID than this please send me an e-mail so I can send you a patch to test. Also, Greg KH and Matt Dharm: this is the best way to go about doing this, n'est pas? Oui. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Hi. I have my back hairs caught in my computer fan. -- Customer User Friendly, 8/20/1998 pgp9VQ4FioHiz.pgp Description: PGP signature
[linux-usb-devel] PATCH: remove dependency on SCSI-provided serial/tag number
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.
Greg, please apply.
Matt
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
Index: usb-2.6/drivers/usb/storage/usb.h
===
--- usb-2.6.orig/drivers/usb/storage/usb.h
+++ usb-2.6/drivers/usb/storage/usb.h
@@ -158,6 +158,7 @@ struct us_data {
/* SCSI interfaces */
struct scsi_cmnd*srb;/* current srb */
+ unsigned inttag; /* current dCBWTag */
/* thread information */
int pid; /* control thread */
Index: usb-2.6/drivers/usb/storage/transport.c
===
--- usb-2.6.orig/drivers/usb/storage/transport.c
+++ usb-2.6/drivers/usb/storage/transport.c
@@ -611,7 +611,6 @@ void usb_stor_invoke_transport(struct sc
unsigned char old_sc_data_direction;
unsigned char old_cmd_len;
unsigned char old_cmnd[MAX_COMMAND_SIZE];
- unsigned long old_serial_number;
int old_resid;
US_DEBUGP(Issuing auto-REQUEST_SENSE\n);
@@ -648,10 +647,6 @@ void usb_stor_invoke_transport(struct sc
old_sg = srb-use_sg;
srb-use_sg = 0;
- /* change the serial number -- toggle the high bit*/
- old_serial_number = srb-serial_number;
- srb-serial_number ^= 0x8000;
-
/* issue the auto-sense command */
old_resid = srb-resid;
srb-resid = 0;
@@ -662,7 +657,6 @@ void usb_stor_invoke_transport(struct sc
srb-request_buffer = old_request_buffer;
srb-request_bufflen = old_request_bufflen;
srb-use_sg = old_sg;
- srb-serial_number = old_serial_number;
srb-sc_data_direction = old_sc_data_direction;
srb-cmd_len = old_cmd_len;
memcpy(srb-cmnd, old_cmnd, MAX_COMMAND_SIZE);
@@ -985,7 +979,7 @@ int usb_stor_Bulk_transport(struct scsi_
bcb-Signature = cpu_to_le32(US_BULK_CB_SIGN);
bcb-DataTransferLength = cpu_to_le32(transfer_length);
bcb-Flags = srb-sc_data_direction == DMA_FROM_DEVICE ? 1 7 : 0;
- bcb-Tag = srb-serial_number;
+ bcb-Tag = ++us-tag;
bcb-Lun = srb-device-lun;
if (us-flags US_FL_SCM_MULT_TARG)
bcb-Lun |= srb-device-id 4;
@@ -1074,7 +1068,7 @@ int usb_stor_Bulk_transport(struct scsi_
US_DEBUGP(Bulk Status S 0x%x T 0x%x R %u Stat 0x%x\n,
le32_to_cpu(bcs-Signature), bcs-Tag,
residue, bcs-Status);
- if (bcs-Tag != srb-serial_number || bcs-Status US_BULK_STAT_PHASE)
{
+ if (bcs-Tag != us-tag || bcs-Status US_BULK_STAT_PHASE) {
US_DEBUGP(Bulk logical error\n);
return USB_STOR_TRANSPORT_ERROR;
}
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
It was a new hope.
-- Dust Puppy
User Friendly, 12/25/1998
pgpp2tGkhu6Xj.pgp
Description: PGP signature
[linux-usb-devel] PATCH: close a race condition in disconnect near probe
This patch started life as as533, and has been re-diffed against the
current tree.
Disconnect processing in usb-storage naturally divides into two parts: one
to quiesce the driver (make sure no commands are executing or queued) and
remove the host, and the other to deallocate all the USB and non-USB
resources. This patch creates two subroutines to handle those two parts.
Mostly it's just code movement, but there is one significant change. If
the scsi-scanning thread fails to initialize but the host has successfully
been added, we need to quiesce the driver before removing the host.
After all, it's possible that scanning could have been initiated from
somewhere else, such as userspace -- very low probability, but it's easily
handled by calling the new subroutine.
Greg, please apply.
Matt
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
Index: linux-2.6.13-rc3/drivers/usb/storage/usb.c
===
--- linux-2.6.13-rc3.orig/drivers/usb/storage/usb.c 2005-07-12
21:46:46.0 -0700
+++ linux-2.6.13-rc3/drivers/usb/storage/usb.c 2005-07-24 21:40:46.0
-0700
@@ -786,6 +786,7 @@
* any more commands.
*/
US_DEBUGP(-- sending exit command to thread\n);
+ set_bit(US_FLIDX_DISCONNECTING, us-flags);
up(us-sema);
/* Call the destructor routine, if it exists */
@@ -816,6 +817,36 @@
usb_set_intfdata(us-pusb_intf, NULL);
}
+/* First stage of disconnect processing: stop all commands and remove
+ * the host */
+static void quiesce_and_remove_host(struct us_data *us)
+{
+ /* Prevent new USB transfers, stop the current command, and
+* interrupt a SCSI-scan or device-reset delay */
+ set_bit(US_FLIDX_DISCONNECTING, us-flags);
+ usb_stor_stop_transport(us);
+ wake_up(us-delay_wait);
+
+ /* It doesn't matter if the SCSI-scanning thread is still running.
+* The thread will exit when it sees the DISCONNECTING flag. */
+
+ /* Wait for the current command to finish, then remove the host */
+ down(us-dev_semaphore);
+ up(us-dev_semaphore);
+ scsi_remove_host(us_to_host(us));
+}
+
+/* Second stage of disconnect processing: deallocate all resources */
+static void release_everything(struct us_data *us)
+{
+ usb_stor_release_resources(us);
+ dissociate_dev(us);
+
+ /* Drop our reference to the host; the SCSI core will free it
+* (and us along with it) when the refcount becomes 0. */
+ scsi_host_put(us_to_host(us));
+}
+
/* Thread to carry out delayed SCSI-device scanning */
static int usb_stor_scan_thread(void * __us)
{
@@ -956,7 +987,7 @@
if (result 0) {
printk(KERN_WARNING USB_STORAGE
Unable to start the device-scanning thread\n);
- scsi_remove_host(host);
+ quiesce_and_remove_host(us);
goto BadDevice;
}
atomic_inc(total_threads);
@@ -969,10 +1000,7 @@
/* We come here if there are any problems */
BadDevice:
US_DEBUGP(storage_probe() failed\n);
- set_bit(US_FLIDX_DISCONNECTING, us-flags);
- usb_stor_release_resources(us);
- dissociate_dev(us);
- scsi_host_put(host);
+ release_everything(us);
return result;
}
@@ -982,28 +1010,8 @@
struct us_data *us = usb_get_intfdata(intf);
US_DEBUGP(storage_disconnect() called\n);
-
- /* Prevent new USB transfers, stop the current command, and
-* interrupt a SCSI-scan or device-reset delay */
- set_bit(US_FLIDX_DISCONNECTING, us-flags);
- usb_stor_stop_transport(us);
- wake_up(us-delay_wait);
-
- /* It doesn't matter if the SCSI-scanning thread is still running.
-* The thread will exit when it sees the DISCONNECTING flag. */
-
- /* Wait for the current command to finish, then remove the host */
- down(us-dev_semaphore);
- up(us-dev_semaphore);
- scsi_remove_host(us_to_host(us));
-
- /* Wait for everything to become idle and release all our resources */
- usb_stor_release_resources(us);
- dissociate_dev(us);
-
- /* Drop our reference to the host; the SCSI core will free it
-* (and us along with it) when the refcount becomes 0. */
- scsi_host_put(us_to_host(us));
+ quiesce_and_remove_host(us);
+ release_everything(us);
}
/***
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
We can customize our colonels.
-- Tux
User Friendly, 12/1/1998
pgpV8H0B3y5gk.pgp
Description: PGP signature
[linux-usb-devel] PATCH: add support for Maxtor One-Touch button
This patch is originally from Nick Sillik, and has been rediffed against
the latest tree.
This patch adds usability to the OneTouch Button on Maxtor
External USB Hard Drives. Using an unusual device entry it declares an
extra init function which claims the interrupt endpoint associated with
this button. The button is connected to the input system.
Greg, please apply.
Matt
Signed-off-by: Nick Sillik [EMAIL PROTECTED]
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
diff -urN -x linux-2.6.13-rc1-mm1/Documentation/dontdiff
linux-2.6.13-rc1-mm1/drivers/usb/storage/Kconfig
linux-2.6.13-rc1-mm1-onetouch/drivers/usb/storage/Kconfig
--- linux-2.6.13-rc1-mm1/drivers/usb/storage/Kconfig2005-07-04
21:20:51.0 -0400
+++ linux-2.6.13-rc1-mm1-onetouch/drivers/usb/storage/Kconfig 2005-07-04
21:24:31.0 -0400
@@ -111,3 +111,15 @@
Say Y here to include additional code to support the Lexar Jumpshot
USB CompactFlash reader.
+
+config USB_STORAGE_ONETOUCH
+ bool Support OneTouch Button on Maxtor Hard Drives (EXPERIMENTAL)
+ depends on USB_STORAGE INPUT_EVDEV EXPERIMENTAL
+ help
+ Say Y here to include additional code to support the Maxtor OneTouch
+ USB hard drive's onetouch button.
+
+ This code registers the button on the front of Maxtor OneTouch USB
+ hard drive's as an input device. An action can be associated with
+ this input in any keybinding software. (e.g. gnome's keyboard short-
+ cuts)
diff -urN -x linux-2.6.13-rc1-mm1/Documentation/dontdiff
linux-2.6.13-rc1-mm1/drivers/usb/storage/Makefile
linux-2.6.13-rc1-mm1-onetouch/drivers/usb/storage/Makefile
--- linux-2.6.13-rc1-mm1/drivers/usb/storage/Makefile 2005-07-04
21:20:51.0 -0400
+++ linux-2.6.13-rc1-mm1-onetouch/drivers/usb/storage/Makefile 2005-07-04
21:24:39.0 -0400
@@ -18,6 +18,7 @@
usb-storage-obj-$(CONFIG_USB_STORAGE_ISD200) += isd200.o
usb-storage-obj-$(CONFIG_USB_STORAGE_DATAFAB) += datafab.o
usb-storage-obj-$(CONFIG_USB_STORAGE_JUMPSHOT) += jumpshot.o
+usb-storage-obj-$(CONFIG_USB_STORAGE_ONETOUCH) += onetouch.o
usb-storage-objs :=scsiglue.o protocol.o transport.o usb.o \
initializers.o $(usb-storage-obj-y)
diff -urN -x linux-2.6.13-rc1-mm1/Documentation/dontdiff
linux-2.6.13-rc1-mm1/drivers/usb/storage/onetouch.c
linux-2.6.13-rc1-mm1-onetouch/drivers/usb/storage/onetouch.c
--- linux-2.6.13-rc1-mm1/drivers/usb/storage/onetouch.c 1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13-rc1-mm1-onetouch/drivers/usb/storage/onetouch.c
2005-07-14 21:28:09.0 -0400
@@ -0,0 +1,205 @@
+/*
+ * Support for the Maxtor OneTouch USB hard drive's button
+ *
+ * Current development and maintenance by:
+ * Copyright (c) 2005 Nick Sillik [EMAIL PROTECTED]
+ *
+ * Initial work by:
+ * Copyright (c) 2003 Erik Thyrén [EMAIL PROTECTED]
+ *
+ * Based on usbmouse.c (Vojtech Pavlik) and xpad.c (Marko Friedemann)
+ *
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include linux/config.h
+#include linux/kernel.h
+#include linux/input.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/usb.h
+#include usb.h
+#include onetouch.h
+#include debug.h
+
+void onetouch_release_input(void *onetouch_);
+
+struct usb_onetouch {
+ char name[128];
+ char phys[64];
+ struct input_dev dev; /* input device interface */
+ struct usb_device *udev;/* usb device */
+
+ struct urb *irq;/* urb for interrupt in report */
+ unsigned char *data;/* input data */
+ dma_addr_t data_dma;
+};
+
+static void usb_onetouch_irq(struct urb *urb, struct pt_regs *regs)
+{
+ struct usb_onetouch *onetouch = urb-context;
+ signed char *data = onetouch-data;
+ struct input_dev *dev = onetouch-dev;
+ int status;
+
+ switch (urb-status) {
+ case 0: /* success */
+ break;
+ case -ECONNRESET: /* unlink */
+ case -ENOENT:
+ case -ESHUTDOWN:
+ return;
+ /* -EPIPE: should clear the halt */
+ default:/* error */
+ goto resubmit;
+ }
+
+ input_regs(dev, regs);
+
+ input_report_key
[linux-usb-devel] PATCH: wedge SCSI revision at 2 for usb-storage devices
This patch started life as as479b, and has been rediffed. Please note the order of submission of this latest patch series -- even tho this has an older original number, it is the last patch I'll be sending today. This patch changes the reported SCSI revision level to 2 for all disk-type devices. This is needed in a few cases because the device reports a level of 3 or higher but then crashes when given a REPORT LUNS command (for which support is supposed to be mandatory at those levels). This shouldn't harm us, since it only matters for sparse LUNs and we have separate ways of coping with that. Greg, please apply. Matt Signed-off-by: Alan Stern [EMAIL PROTECTED] Signed-off-by: Matthew Dharm [EMAIL PROTECTED] Index: usb-2.6/drivers/usb/storage/scsiglue.c === --- usb-2.6.orig/drivers/usb/storage/scsiglue.c +++ usb-2.6/drivers/usb/storage/scsiglue.c @@ -156,6 +156,14 @@ static int slave_configure(struct scsi_d if (us-flags US_FL_FIX_CAPACITY) sdev-fix_capacity = 1; + /* Some devices report a SCSI revision level above 2 but are +* unable to handle the REPORT LUNS command (for which +* support is mandatory at level 3). Since we already have +* a Get-Max-LUN request, we won't lose much by setting the +* revision level down to 2. The only devices that would be +* affected are those with sparse LUNs. */ + sdev-scsi_level = SCSI_2; + /* USB-IDE bridges tend to report SK = 0x04 (Non-recoverable * Hardware Error) when any low-level error occurs, * recoverable or not. Setting this flag tells the SCSI -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I think the problem is there's a nut loose on your keyboard. -- Greg to Customer User Friendly, 1/5/1999 pgpn0RP85JAd0.pgp Description: PGP signature
[linux-usb-devel] Re: [RESEND PATCH] Add usability for the OneTouch Button on Maxtor OneTouch Hard Drives
It's in the queue. I'm hoping for this week to send it upstream. Matt On Mon, Jul 25, 2005 at 05:14:25PM -0400, Nick Sillik wrote: Please take a look at this patch, it has been tested as thoroughly as possible as I an having only one arch at my disposal (x86) although I see no reason why it wouldn't work with others. To get it tested a little better I would like if it would be merged with -mm. I added all fixes Alan mentioned (kcalloc instead of kalloc and no kfree(onetouch)) I've included the final diff for the device. Description: This patch adds usability to the OneTouch Button on Maxtor External USB Hard Drives. Using an unusual device entry it declares an extra init function which claims the interrupt endpoint associated with this button. Signed-Off-By: Nick Sillik [EMAIL PROTECTED] -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver A female who groks UNIX? My universe is collapsing. -- Mike User Friendly, 10/11/1998 pgpPt0bdly5fa.pgp Description: PGP signature
[linux-usb-devel] Re: USB flash drive is not working sometimes
CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_RTCTIMER=m CONFIG_SND_MPU401_UART=m CONFIG_SND_AC97_CODEC=m CONFIG_SND_INTEL8X0=m CONFIG_SND_INTEL8X0M=m CONFIG_SND_VIA82XX=m CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB=m CONFIG_USB_DEBUG=y CONFIG_USB_DEVICEFS=y CONFIG_USB_EHCI_HCD=m CONFIG_USB_OHCI_HCD=m CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=m CONFIG_USB_STORAGE=m CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y CONFIG_USB_HID=m CONFIG_USB_HIDINPUT=y CONFIG_USB_MON=m CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_JBD=y CONFIG_FS_MBCACHE=y CONFIG_REISERFS_FS=y CONFIG_REISERFS_PROC_INFO=y CONFIG_FS_POSIX_ACL=y CONFIG_MINIX_FS=y CONFIG_ROMFS_FS=y CONFIG_DNOTIFY=y CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=m CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=y CONFIG_UDF_FS=m CONFIG_UDF_NLS=y CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET=iso8859-1 CONFIG_NTFS_FS=m CONFIG_NTFS_RW=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y CONFIG_DEVFS_FS=y CONFIG_TMPFS=y CONFIG_TMPFS_XATTR=y CONFIG_TMPFS_SECURITY=y CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_RAMFS=y CONFIG_CRAMFS=y CONFIG_UFS_FS=m CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFS_V4=y CONFIG_NFSD=m CONFIG_NFSD_V3=y CONFIG_NFSD_V4=y CONFIG_NFSD_TCP=y CONFIG_ROOT_NFS=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_SUNRPC=y CONFIG_SUNRPC_GSS=y CONFIG_RPCSEC_GSS_KRB5=y CONFIG_SMB_FS=m CONFIG_CIFS=y CONFIG_CIFS_STATS=y CONFIG_MSDOS_PARTITION=y CONFIG_NLS=y CONFIG_NLS_DEFAULT=iso8859-1 CONFIG_NLS_CODEPAGE_437=m CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_ISO8859_8=m CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ASCII=m CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m CONFIG_PROFILING=y CONFIG_OPROFILE=m CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y CONFIG_LOG_BUF_SHIFT=15 CONFIG_SCHEDSTATS=y CONFIG_DEBUG_SPINLOCK_SLEEP=y CONFIG_DEBUG_FS=y CONFIG_FRAME_POINTER=y CONFIG_EARLY_PRINTK=y CONFIG_DEBUG_STACKOVERFLOW=y CONFIG_KPROBES=y CONFIG_DEBUG_STACK_USAGE=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_DES=y CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES_586=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_CRC32C=m CONFIG_CRYPTO_TEST=m CONFIG_CRYPTO_DEV_PADLOCK=m CONFIG_CRYPTO_DEV_PADLOCK_AES=y CONFIG_CRC_CCITT=y CONFIG_CRC32=y CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver God, root, what is difference? -- Pitr User Friendly, 11/11/1999 pgpN6msqTrraK.pgp Description: PGP signature
[linux-usb-devel] PATCH: endpoint toggles and reset delays
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.
Greg, please apply.
Matt
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
= drivers/usb/storage/transport.c 1.166 vs edited =
--- 1.166/drivers/usb/storage/transport.c 2005-03-14 00:33:16 -05:00
+++ edited/drivers/usb/storage/transport.c 2005-03-30 16:33:19 -05:00
@@ -266,8 +266,9 @@
NULL, 0, 3*HZ);
/* reset the endpoint toggle */
- usb_settoggle(us-pusb_dev, usb_pipeendpoint(pipe),
- usb_pipeout(pipe), 0);
+ if (result = 0)
+ usb_settoggle(us-pusb_dev, usb_pipeendpoint(pipe),
+ usb_pipeout(pipe), 0);
US_DEBUGP(%s: result = %d\n, __FUNCTION__, result);
return result;
@@ -1124,7 +1125,7 @@
* It's handy that every transport mechanism uses the control endpoint for
* resets.
*
- * Basically, we send a reset with a 20-second timeout, so we don't get
+ * Basically, we send a reset with a 5-second timeout, so we don't get
* jammed attempting to do the reset.
*/
static int usb_stor_reset_common(struct us_data *us,
@@ -1145,13 +1146,9 @@
clear_bit(US_FLIDX_ABORTING, us-flags);
scsi_unlock(us_to_host(us));
- /* A 20-second timeout may seem rather long, but a LaCie
-* StudioDrive USB2 device takes 16+ seconds to get going
-* following a powerup or USB attach event.
-*/
result = usb_stor_control_msg(us, us-send_ctrl_pipe,
request, requesttype, value, index, data, size,
- 20*HZ);
+ 5*HZ);
if (result 0) {
US_DEBUGP(Soft reset failed: %d\n, result);
goto Done;
@@ -1173,8 +1170,10 @@
US_DEBUGP(Soft reset: clearing bulk-out endpoint halt\n);
result2 = usb_stor_clear_halt(us, us-send_bulk_pipe);
- /* return a result code based on the result of the control message */
- if (result 0 || result2 0) {
+ /* return a result code based on the result of the clear-halts */
+ if (result = 0)
+ result = result2;
+ if (result 0) {
US_DEBUGP(Soft reset failed\n);
goto Done;
}
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
NYET! The evil stops here!
-- Pitr
User Friendly, 6/22/1998
pgpntZ1izrN5M.pgp
Description: PGP signature
[linux-usb-devel] PATCH: port reset on transport error
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.
Greg, please apply.
Matt
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
= drivers/usb/storage/scsiglue.c 1.103 vs edited =
Index: linux-2.6.12-rc5/drivers/usb/storage/scsiglue.c
===
--- linux-2.6.12-rc5.orig/drivers/usb/storage/scsiglue.c2005-06-05
21:49:55.0 -0700
+++ linux-2.6.12-rc5/drivers/usb/storage/scsiglue.c 2005-06-05
21:50:16.0 -0700
@@ -259,57 +259,29 @@
/* lock the device pointers and do the reset */
down((us-dev_semaphore));
- if (test_bit(US_FLIDX_DISCONNECTING, us-flags)) {
- result = FAILED;
- US_DEBUGP(No reset during disconnect\n);
- } else
- result = us-transport_reset(us);
+ result = us-transport_reset(us);
up((us-dev_semaphore));
/* lock the host for the return */
scsi_lock(us_to_host(us));
- return result;
+ return result 0 ? FAILED : SUCCESS;
}
-/* This resets the device's USB port. */
-/* It refuses to work if there's more than one interface in
- * the device, so that other users are not affected. */
+/* Simulate a SCSI bus reset by resetting the device's USB port. */
/* This is always called with scsi_lock(host) held */
static int bus_reset(struct scsi_cmnd *srb)
{
struct us_data *us = host_to_us(srb-device-host);
- int result, rc;
+ int result;
US_DEBUGP(%s called\n, __FUNCTION__);
scsi_unlock(us_to_host(us));
- /* The USB subsystem doesn't handle synchronisation between
-* a device's several drivers. Therefore we reset only devices
-* with just one interface, which we of course own. */
-
down((us-dev_semaphore));
- if (test_bit(US_FLIDX_DISCONNECTING, us-flags)) {
- result = -EIO;
- US_DEBUGP(No reset during disconnect\n);
- } else if (us-pusb_dev-actconfig-desc.bNumInterfaces != 1) {
- result = -EBUSY;
- US_DEBUGP(Refusing to reset a multi-interface device\n);
- } else {
- rc = usb_lock_device_for_reset(us-pusb_dev, us-pusb_intf);
- if (rc 0) {
- US_DEBUGP(unable to lock device for reset: %d\n, rc);
- result = rc;
- } else {
- result = usb_reset_device(us-pusb_dev);
- if (rc)
- usb_unlock_device(us-pusb_dev);
- US_DEBUGP(usb_reset_device returns %d\n, result);
- }
- }
+ result = usb_stor_port_reset(us);
up((us-dev_semaphore));
- /* lock the host for the return */
scsi_lock(us_to_host(us));
return result 0 ? FAILED : SUCCESS;
}
@@ -329,6 +301,14 @@
}
}
+/* Report a driver-initiated bus reset to the SCSI layer.
+ * Calling this for a SCSI-initiated reset is unnecessary but harmless.
+ * The caller must own the SCSI host lock. */
+void usb_stor_report_bus_reset(struct us_data *us)
+{
+ scsi_report_bus_reset(us_to_host(us), 0);
+}
+
/***
* /proc/scsi/ functions
***/
Index: linux-2.6.12-rc5/drivers/usb/storage/scsiglue.h
===
--- linux-2.6.12-rc5.orig/drivers/usb/storage/scsiglue.h2005-06-05
21:49:44.0 -0700
+++ linux-2.6.12-rc5/drivers/usb/storage/scsiglue.h 2005-06-05
21:50:09.0 -0700
@@ -42,6 +42,7 @@
#define _SCSIGLUE_H_
extern void usb_stor_report_device_reset(struct us_data *us);
+extern void usb_stor_report_bus_reset(struct us_data *us);
extern unsigned char usb_stor_sense_invalidCDB[18];
extern struct scsi_host_template usb_stor_host_template;
Index: linux-2.6.12-rc5/drivers/usb/storage/transport.c
===
--- linux-2.6.12-rc5.orig/drivers/usb/storage/transport.c 2005-06-05
21:50:08.0 -0700
+++ linux-2.6.12-rc5/drivers/usb/storage/transport.c2005-06-05
21:50:09.0 -0700
@@ -541,15 +541,15 @@
*/
if (test_bit(US_FLIDX_TIMED_OUT, us-flags)) {
US_DEBUGP(-- command was aborted\n);
- goto Handle_Abort;
+ srb-result = DID_ABORT 16;
+ goto Handle_Errors;
}
/* if there is a transport error, reset and don't auto-sense */
if (result == USB_STOR_TRANSPORT_ERROR) {
US_DEBUGP(-- transport indicates error, resetting\n
[linux-usb-devel] PATCH: retry hard errors
This patch started life as as527, and was rediffed by me.
Since the IDE interface doesn't convey much information about types of
errors, many USB-IDE adapters report all low-level errors with SK = 0x04,
which is supposed to be used only for non-recoverable errors. As a result
the SCSI midlayer doesn't retry the command. But quite often a retry
would succeed, whereas an unnecessary retry doesn't really hurt anything.
This patch uses a recently-implemented flag to tell the SCSI midlayer that
such hardware errors should be retried.
Greg, please apply.
Matt
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
Index: linux-2.6.12-rc5/drivers/usb/storage/scsiglue.c
===
--- linux-2.6.12-rc5.orig/drivers/usb/storage/scsiglue.c2005-06-05
21:49:14.0 -0700
+++ linux-2.6.12-rc5/drivers/usb/storage/scsiglue.c 2005-06-05
21:49:44.0 -0700
@@ -155,6 +155,15 @@
* If this device makes that mistake, tell the sd driver. */
if (us-flags US_FL_FIX_CAPACITY)
sdev-fix_capacity = 1;
+
+ /* USB-IDE bridges tend to report SK = 0x04 (Non-recoverable
+* Hardware Error) when any low-level error occurs,
+* recoverable or not. Setting this flag tells the SCSI
+* midlayer to retry such commands, which frequently will
+* succeed and fix the error. The worst this can lead to
+* is an occasional series of retries that will all fail. */
+ sdev-retry_hwerror = 1;
+
} else {
/* Non-disk-type devices don't need to blacklist any pages
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
A: The most ironic oxymoron wins ...
DP: Microsoft Works
A: Uh, okay, you win.
-- A.J. Dust Puppy
User Friendly, 1/18/1998
pgpKElso3g4oK.pgp
Description: PGP signature
[linux-usb-devel] PATCH: fix compile error
Here is patch md.git001 -- it's my first patch submission from a GIT archive. Now that we have diff-tree-helper, things are much better... There's probably a better way to do this, but until I get a hold of more people's super-slick GIT scripts, this will have to do. This patch fixes a compiler error caused by a missing prototype. It should apply directly to Greg KH's usb-2.6.git tree. Greg, please apply. Signed-off-by: Matthew Dharm [EMAIL PROTECTED] --- k/drivers/usb/storage/debug.c +++ l/drivers/usb/storage/debug.c @@ -47,6 +47,7 @@ #include linux/cdrom.h #include scsi/scsi.h #include scsi/scsi_cmnd.h +#include scsi/scsi_dbg.h #include debug.h #include scsi.h -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver G: Let me guess, you started on the 'net with AOL, right? C: WOW! d00d! U r leet! -- Greg and Customer User Friendly, 2/12/1999 pgptkHw7N7oti.pgp Description: PGP signature
Re: [linux-usb-devel] Re: [PATCH] Driver to Add Usability for Maxtor External Drives
The SCSI messages bother me a little bit... They indicate to me that you're accessing the disk (mount, etc.) when you yank the cable. But, you don't mention that you are... so I'm wondering what's going on. Clarification? Matt On Thu, Mar 31, 2005 at 07:09:28PM -0500, Nick Sillik wrote: When I unplugged the drive again all I got was this: Mar 31 18:55:03 localhost kernel: ehci_hcd :00:02.2: GetStatus port 1 status 001002 POWER sig=se0 CSC Mar 31 18:55:03 localhost kernel: usb 3-1: USB disconnect, address 6 Mar 31 18:55:03 localhost kernel: usb 3-1: unlink qh32-0001/ddc8b100 start 31 [7/0 us] Mar 31 18:55:04 localhost kernel: scsi3 (0:0): rejecting I/O to dead device Mar 31 18:55:04 localhost kernel: printk: 25 messages suppressed. Mar 31 18:55:04 localhost kernel: Buffer I/O error on device sda1, logical block 0 Mar 31 18:55:04 localhost kernel: lost page write due to I/O error on sda1 Any ideas? It seems like if I diconnect the drive, or plug it back in, very quickly before doing the opposite that I have hangs... Is it possible that there is bad data being written to one of my structures? Nick Sillik [EMAIL PROTECTED] -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver You were using cheat codes too. You guys suck. -- Greg to General Studebaker User Friendly, 12/16/1997 pgpENGWRINgJr.pgp Description: PGP signature
Re: [linux-usb-devel] Re: [PATCH] Driver to Add Usability for Maxtor External Drives
On Thu, Mar 31, 2005 at 09:35:44PM -0500, Nick Sillik wrote: Matthew Dharm wrote: The SCSI messages bother me a little bit... They indicate to me that you're accessing the disk (mount, etc.) when you yank the cable. But, you don't mention that you are... so I'm wondering what's going on. Clarification? Matt Yeah, this has always concerned me, I saw these message well before I started working on this driver so I don't think that is the problem, although, it may be contributing to it. But I'm relatively sure that this isn't the only cause of the hangs. The only thing that is being done to the drive is being auto-mounted by gnome 2.10.0 . Well, at least we know what's causing one set of error messages. I would strongly suggest turning off the automounter until we have a better handle on what's going on. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Hey Chief. We've figured out how to save the technical department. We need to be committed. -- The Techs User Friendly, 1/22/1998 pgpfU4vGfhfox.pgp Description: PGP signature
Re: [linux-usb-devel] Re: [PATCH] Driver to Add Usability for Maxtor External Drives
Well, let's start with the obvious: Remove the line of code you mention, and instead do: snprintf(onetouch-name, 128, Maxtor Test String); If that doesn't fix the problem, then it's not the culprit and you need to keep looking. If that is the problem, then my guess is more that this is a udev-related issue than anything else, as the two strings you're sourcing data from are coming from udev. I would be interested in seeing what your debug printouts show at detach time, to see if you're really disconnecting the device properly. That plus the USB Storage debugging should be telling. Matt On Thu, Mar 24, 2005 at 08:19:51PM -0500, Nick Sillik wrote: Okay, I have a serious problem. Everything goes fine when the device is unplugged. When the device is plugged back in however, everything goes bad, then the system hangs. The only change that I can recall happening in the interim is that us_data no loger has a manufacturer or product feild, and I have to use this: snprintf(onetouch-name, 128, %s %s, udev-manufacturer, udev-product); I may be missing something huge, but that doesn't seem like it should hang the system. I put all sorts of printks in the onetouch_release_input and the onetouch_close functions. From what I can tell all of the code is being run. After reinserting the drive however. It doesn't even get as far as telling me that a device has been plugged in. (using tail -f /var/log/kern.log) I'm at a loss. I've compared the working code to the new, non-working code, and I'm unable to find anything that would cause this. Nick Sillik [EMAIL PROTECTED] Alan Stern wrote: On Mon, 21 Mar 2005, Nick Sillik wrote: I changed it to use the unusual devs code. Now I get this error when insmodding. usb-storage: This device (0d49,7010,0200 S 06 P 50) has an unneeded SubClass entry in unusual_devs.h Please send a copy of this message to linux-usb-devel@lists.sourceforge.net hmmm? You probably didn't specify US_SC_DEVICE in your unusual_devs entry. Anyway, that message isn't an error -- it's just informational. Alan Stern P.S.: Did you also make the other changes I recommended? --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 pgpyBvhzk2aLG.pgp Description: PGP signature
[linux-usb-devel] PATCH: remove RW_DETECT from being a config option
This patch started life as as454b from Alan Stern. It has been rediffed against the tip, including updates for the way unusual_devs flags are defined. This patch removes the Kconfig option USB_STORAGE_RW_DETECT. That option was used to enable/supress the attempt to detect if a device was write protected. It seems that the vast majority of devices properly respond to the latest algorithm for making that determination. So now we move to excluding only those devices that can't handle it. We accomplish this via the unusual_devs.h list. Greg, please apply. Signed-off-by: Alan Stern [EMAIL PROTECTED] Signed-off-by: Matthew Dharm [EMAIL PROTECTED] Matt # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/21 00:36:29-08:00 [EMAIL PROTECTED] # as454b # # drivers/usb/storage/usb.h # 2005/03/21 00:35:43-08:00 [EMAIL PROTECTED] +2 -0 # as454b # # drivers/usb/storage/unusual_devs.h # 2005/03/21 00:35:43-08:00 [EMAIL PROTECTED] +8 -1 # as454b # # drivers/usb/storage/scsiglue.c # 2005/03/21 00:35:43-08:00 [EMAIL PROTECTED] +10 -8 # as454b # # drivers/usb/storage/Kconfig # 2005/03/21 00:35:43-08:00 [EMAIL PROTECTED] +0 -22 # as454b # diff -Nru a/drivers/usb/storage/Kconfig b/drivers/usb/storage/Kconfig --- a/drivers/usb/storage/Kconfig 2005-03-21 00:40:36 -08:00 +++ b/drivers/usb/storage/Kconfig 2005-03-21 00:40:36 -08:00 @@ -31,28 +31,6 @@ Say Y here in order to have the USB Mass Storage code generate verbose debugging messages. -config USB_STORAGE_RW_DETECT - bool USB Mass Storage Write-Protected Media Detection (EXPERIMENTAL) - depends on USB_STORAGE EXPERIMENTAL - help - Say Y here in order to have the USB Mass Storage code indicate to - the SCSI layer that using MODE SENSE(6) and MODE SENSE(10) to - determine if the media is write-protected is a good thing to do. - - Many devices have historically had trouble with these commands, - hence the default 2.6.x behavior has been to suppress their use. - 2.4.x used these commands with (at best) mixed results, often - crashing the firmware of the device. However, the SCSI layer now - issues these commands in a manner more consistent with other - popular OSes, in an attempt to improve compatibility. - - Saying Y here allows these commands to be sent to a USB device. - If you find a device this doesn't work for, switch to N and let - us know at [EMAIL PROTECTED] - - If you say N here, the kernel will assume that all disk-like USB - devices are write-enabled. - config USB_STORAGE_DATAFAB bool Datafab Compact Flash Reader support (EXPERIMENTAL) depends on USB_STORAGE EXPERIMENTAL diff -Nru a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c --- a/drivers/usb/storage/scsiglue.c2005-03-21 00:40:36 -08:00 +++ b/drivers/usb/storage/scsiglue.c2005-03-21 00:40:36 -08:00 @@ -136,17 +136,19 @@ * 192 bytes (that's what Windows uses). */ sdev-use_192_bytes_for_3f = 1; + /* Some devices don't like MODE SENSE with page=0x3f, +* which is the command used for checking if a device +* is write-protected. Now that we tell the sd driver +* to do a 192-byte transfer with this command the +* majority of devices work fine, but a few still can't +* handle it. The sd driver will simply assume those +* devices are write-enabled. */ + if (us-flags US_FL_NO_WP_DETECT) + sdev-skip_ms_page_3f = 1; + /* A number of devices have problems with MODE SENSE for * page x08, so we will skip it. */ sdev-skip_ms_page_8 = 1; - -#ifndef CONFIG_USB_STORAGE_RW_DETECT - /* Some devices may not like MODE SENSE with page=0x3f. -* Now that we're using 192-byte transfers this may no -* longer be a problem. So this will be a configuration -* option. */ - sdev-skip_ms_page_3f = 1; -#endif /* Some disks return the total number of blocks in response * to READ CAPACITY rather than the highest block number. diff -Nru a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h --- a/drivers/usb/storage/unusual_devs.h2005-03-21 00:40:36 -08:00 +++ b/drivers/usb/storage/unusual_devs.h2005-03-21 00:40:36 -08:00 @@ -349,7 +349,7 @@ Sony, DSC-S30/S70/S75/505V/F505/F707/F717/P8, US_SC_SCSI, US_PR_DEVICE, NULL, - US_FL_SINGLE_LUN | US_FL_NOT_LOCKABLE ), + US_FL_SINGLE_LUN | US_FL_NOT_LOCKABLE | US_FL_NO_WP_DETECT ), /* This entry is needed because the device reports Sub=ff */ UNUSUAL_DEV( 0x054c, 0x0010, 0x0500, 0x0500
Re: [linux-usb-devel] Re: [PATCH] Driver to Add Usability for Maxtor External Drives
Change US_SC_SCSI to US_SC_DEVICE. In fact, it's probably a good idea to change US_PR_CBI to US_PR_DEVICE. Especially since the device is advertising US_PR_BULK, which is very different from US_PR_CBI. Matt On Mon, Mar 21, 2005 at 07:53:17PM -0500, Nick Sillik wrote: Nick Sillik wrote: I changed it to use the unusual devs code. Now I get this error when insmodding. usb-storage: This device (0d49,7010,0200 S 06 P 50) has an unneeded SubClass entry in unusual_devs.h Please send a copy of this message to linux-usb-devel@lists.sourceforge.net hmmm? Nick Sillik [EMAIL PROTECTED] By the way, here is my entry in unusual_devs.h /* Submitted by: Nick Sillik [EMAIL PROTECTED] * Needed for OneTouch extension to usb-storage * */ #ifdef CONFIG_USB_STORAGE_ONETOUCH UNUSUAL_DEV( 0x0d49, 0x7010, 0x, 0x, Maxtor, OneTouch External Harddrive, US_SC_SCSI, US_PR_CBI, onetouch_connect_input, 0), #endif --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I don't have a left mouse button. I only have one mouse and it's on my right. -- Customer User Friendly, 2/13/1999 pgpRfC3gs8Lj6.pgp Description: PGP signature
[linux-usb-devel] PATCH: make usb-storage structures refcounted by SCSI
This patch started life as as474 from Alan Stern. It's been rediffed
against the tip, tho that is now several days old.
This patch changes the way our private struct us_data is allocated; now it
gets stored at the end of the Scsi_Host rather than separately. That's
what the hostdata field is intended for, and this is how other low-level
host drivers operate. In order to convert between us_data and the
corresponding Scsi_Host I added two new inline routines: us_to_host and
host_to_us. (The conversion actually should be quicker than before by a
microscopic amount, because now it only involves adding an offset whereas
before it involved dereferencing a pointer.)
The main advantage is that the host is refcounted, so now our us_data
automatically is too. Although that doesn't matter at the moment, it will
matter later on when the control thread may need to outlive the disconnect
callback.
Greg, please apply.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
Matt
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/03/06 17:53:19-08:00 [EMAIL PROTECTED]
# as474
#
# drivers/usb/storage/usb.h
# 2005/03/06 17:52:59-08:00 [EMAIL PROTECTED] +8 -1
# as474
#
# drivers/usb/storage/usb.c
# 2005/03/06 17:52:58-08:00 [EMAIL PROTECTED] +23 -32
# as474
#
# drivers/usb/storage/transport.c
# 2005/03/06 17:52:58-08:00 [EMAIL PROTECTED] +2 -2
# as474
#
# drivers/usb/storage/scsiglue.c
# 2005/03/06 17:52:58-08:00 [EMAIL PROTECTED] +24 -27
# as474
#
diff -Nru a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
--- a/drivers/usb/storage/scsiglue.c2005-03-13 21:33:54 -08:00
+++ b/drivers/usb/storage/scsiglue.c2005-03-13 21:33:54 -08:00
@@ -82,7 +82,7 @@
static int slave_configure(struct scsi_device *sdev)
{
- struct us_data *us = (struct us_data *) sdev-host-hostdata[0];
+ struct us_data *us = host_to_us(sdev-host);
/* Scatter-gather buffers (all but the last) must have a length
* divisible by the bulk maxpacket size. Otherwise a data packet
@@ -172,14 +172,13 @@
}
/* queue a command */
-/* This is always called with scsi_lock(srb-host) held */
+/* This is always called with scsi_lock(host) held */
static int queuecommand(struct scsi_cmnd *srb,
void (*done)(struct scsi_cmnd *))
{
- struct us_data *us = (struct us_data *)srb-device-host-hostdata[0];
+ struct us_data *us = host_to_us(srb-device-host);
US_DEBUGP(%s called\n, __FUNCTION__);
- srb-host_scribble = (unsigned char *)us;
/* check for state-transition errors */
if (us-srb != NULL) {
@@ -209,11 +208,10 @@
***/
/* Command timeout and abort */
-/* This is always called with scsi_lock(srb-host) held */
-static int command_abort(struct scsi_cmnd *srb )
+/* This is always called with scsi_lock(host) held */
+static int command_abort(struct scsi_cmnd *srb)
{
- struct Scsi_Host *host = srb-device-host;
- struct us_data *us = (struct us_data *) host-hostdata[0];
+ struct us_data *us = host_to_us(srb-device-host);
US_DEBUGP(%s called\n, __FUNCTION__);
@@ -233,13 +231,13 @@
set_bit(US_FLIDX_ABORTING, us-flags);
usb_stor_stop_transport(us);
}
- scsi_unlock(host);
+ scsi_unlock(us_to_host(us));
/* Wait for the aborted command to finish */
wait_for_completion(us-notify);
/* Reacquire the lock and allow USB transfers to resume */
- scsi_lock(host);
+ scsi_lock(us_to_host(us));
clear_bit(US_FLIDX_ABORTING, us-flags);
clear_bit(US_FLIDX_TIMED_OUT, us-flags);
return SUCCESS;
@@ -247,15 +245,15 @@
/* This invokes the transport reset mechanism to reset the state of the
* device */
-/* This is always called with scsi_lock(srb-host) held */
+/* This is always called with scsi_lock(host) held */
static int device_reset(struct scsi_cmnd *srb)
{
- struct us_data *us = (struct us_data *)srb-device-host-hostdata[0];
+ struct us_data *us = host_to_us(srb-device-host);
int result;
US_DEBUGP(%s called\n, __FUNCTION__);
- scsi_unlock(srb-device-host);
+ scsi_unlock(us_to_host(us));
/* lock the device pointers and do the reset */
down((us-dev_semaphore));
@@ -267,22 +265,22 @@
up((us-dev_semaphore));
/* lock the host for the return */
- scsi_lock(srb-device-host);
+ scsi_lock(us_to_host(us));
return result;
}
/* This resets the device's USB port. */
/* It refuses to work if there's more than one interface in
* the device, so that other users are not affected. */
-/* This is always called with scsi_lock(srb-host) held */
+/* This is always called with scsi_lock(host) held */
static int bus_reset(struct scsi_cmnd *srb)
{
- struct us_data *us
[linux-usb-devel] PATCH: combine waitqueues
This patch started life as as476, and has been rediffed against the tip.
However, that was a few days ago.
This patch combines the two separate waitqueue heads used by the
scsi-scanning thread and the device-reset routine into one. After all,
until the scanning thread is through waiting there will be no SCSI
devices and hence no device resets.
Once the scanning thread is done waiting, the waitqueue can be used by the
reset logic -- so even if the act of scanning produces resets, we're fine.
Greg, please apply.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
Matt
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/03/06 18:05:27-08:00 [EMAIL PROTECTED]
# as477
#
# drivers/usb/storage/usb.h
# 2005/03/06 18:04:58-08:00 [EMAIL PROTECTED] +3 -5
# as477
#
# drivers/usb/storage/usb.c
# 2005/03/06 18:04:58-08:00 [EMAIL PROTECTED] +6 -8
# as477
#
# drivers/usb/storage/transport.c
# 2005/03/06 18:04:58-08:00 [EMAIL PROTECTED] +1 -1
# as477
#
diff -Nru a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
--- a/drivers/usb/storage/transport.c 2005-03-13 21:33:16 -08:00
+++ b/drivers/usb/storage/transport.c 2005-03-13 21:33:16 -08:00
@@ -1158,7 +1158,7 @@
/* Give the device some time to recover from the reset,
* but don't delay disconnect processing. */
- wait_event_interruptible_timeout(us-dev_reset_wait,
+ wait_event_interruptible_timeout(us-delay_wait,
test_bit(US_FLIDX_DISCONNECTING, us-flags),
HZ*6);
if (test_bit(US_FLIDX_DISCONNECTING, us-flags)) {
diff -Nru a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
--- a/drivers/usb/storage/usb.c 2005-03-13 21:33:16 -08:00
+++ b/drivers/usb/storage/usb.c 2005-03-13 21:33:16 -08:00
@@ -844,7 +844,7 @@
printk(KERN_DEBUG usb-storage: waiting for device
to settle before scanning\n);
retry:
- wait_event_interruptible_timeout(us-scsi_scan_wait,
+ wait_event_interruptible_timeout(us-delay_wait,
test_bit(US_FLIDX_DISCONNECTING, us-flags),
delay_use * HZ);
if (current-flags PF_FREEZE) {
@@ -893,9 +893,7 @@
init_MUTEX((us-dev_semaphore));
init_MUTEX_LOCKED((us-sema));
init_completion((us-notify));
- init_waitqueue_head(us-dev_reset_wait);
- init_waitqueue_head(us-scsi_scan_wait);
- init_completion(us-scsi_scan_done);
+ init_waitqueue_head(us-delay_wait);
/* Associate the us_data structure with the USB device */
result = associate_dev(us, intf);
@@ -988,13 +986,13 @@
US_DEBUGP(storage_disconnect() called\n);
/* Prevent new USB transfers, stop the current command, and
-* interrupt a device-reset delay */
+* interrupt a SCSI-scan or device-reset delay */
set_bit(US_FLIDX_DISCONNECTING, us-flags);
usb_stor_stop_transport(us);
- wake_up(us-dev_reset_wait);
+ wake_up(us-delay_wait);
- /* Interrupt the SCSI-device-scanning thread's time delay */
- wake_up(us-scsi_scan_wait);
+ /* It doesn't matter if the SCSI-scanning thread is still running.
+* The thread will exit when it sees the DISCONNECTING flag. */
/* Wait for the current command to finish, then remove the host */
down(us-dev_semaphore);
diff -Nru a/drivers/usb/storage/usb.h b/drivers/usb/storage/usb.h
--- a/drivers/usb/storage/usb.h 2005-03-13 21:33:16 -08:00
+++ b/drivers/usb/storage/usb.h 2005-03-13 21:33:16 -08:00
@@ -169,11 +169,9 @@
dma_addr_t iobuf_dma;
/* mutual exclusion and synchronization structures */
- struct semaphoresema;/* to sleep thread on */
- struct completion notify; /* thread begin/end */
- wait_queue_head_t dev_reset_wait; /* wait during reset*/
- wait_queue_head_t scsi_scan_wait; /* wait before scanning */
- struct completion scsi_scan_done; /* scan thread end */
+ struct semaphoresema;/* to sleep thread on */
+ struct completion notify; /* thread begin/end*/
+ wait_queue_head_t delay_wait; /* wait during scan, reset */
/* subdriver information */
void*extra; /* Any extra data */
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
Sir, for the hundreth time, we do NOT carry 600-round boxes of belt-fed
suction darts!
-- Salesperson to Greg
User Friendly, 12/30/1997
pgpkTNQkgeMwo.pgp
Description: PGP signature
[linux-usb-devel] PATCH: allow disconnect to complete faster
This patch started life as as476 from Alan Stern. It has been rediffed
against the tip, tho that was a few days ago.
This patch makes the disconnect() routine not wait for the control and
scanning threads to exit. This may not seem important now, but it will
become important later: We would end up with a deadlock if disconnect()
(which is called with the device locked) was waiting for the control
thread to exit, while the control thread was waiting to lock the device so
it could do an autosuspend.
It's necessary to make sure that the host and us_data structures aren't
deallocated before the control and scanning threads are through with them.
This is done by calling scsi_host_get and scsi_host_put at the start and
end of each thread, before signalling that the threads are running. Since
the probe() and disconnect() routines cannot run concurrently (guaranteed
to us by the USB core), this method will guarantee the structures are not
deallocated too soon.
While there's nothing wrong with leaving the threads alive after
disconnect() returns, there would be a real problem if the threads were
still alive when usb_stor_exit returned! So now usb_stor_exit has to wait
to make sure all the threads have died. Apparently the only safe way for
one thread to signal another while exiting is to use complete_and_exit,
which we've been doing. So the patch adds a new driver-wide struct
completion, named threads_gone, and each thread signals it while exiting.
usb_stor_exit must call wait_for_completion the appropriate number of
times, and that number is stored in a new counter named total_threads.
Greg, please apply.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Signed-off-by: Matthew Dharm [EMAIL PROTECTED]
Matt
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/03/06 18:02:01-08:00 [EMAIL PROTECTED]
# as476
#
# drivers/usb/storage/usb.c
# 2005/03/06 18:01:40-08:00 [EMAIL PROTECTED] +41 -7
# as476
#
diff -Nru a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
--- a/drivers/usb/storage/usb.c 2005-03-13 21:33:29 -08:00
+++ b/drivers/usb/storage/usb.c 2005-03-13 21:33:29 -08:00
@@ -102,6 +102,13 @@
MODULE_PARM_DESC(delay_use, seconds to delay before using a new device);
+/* These are used to make sure the module doesn't unload before all the
+ * threads have exited.
+ */
+static atomic_t total_threads = ATOMIC_INIT(0);
+static DECLARE_COMPLETION(threads_gone);
+
+
static int storage_probe(struct usb_interface *iface,
const struct usb_device_id *id);
@@ -286,11 +293,13 @@
* so get rid of all our resources.
*/
daemonize(usb-storage);
-
current-flags |= PF_NOFREEZE;
-
unlock_kernel();
+ /* acquire a reference to the host, so it won't be deallocated
+* until we're ready to exit */
+ scsi_host_get(host);
+
/* signal that we've started the thread */
complete((us-notify));
@@ -394,6 +403,8 @@
up((us-dev_semaphore));
} /* for (;;) */
+ scsi_host_put(host);
+
/* notify the exit routine that we're actually exiting now
*
* complete()/wait_for_completion() is similar to up()/down(),
@@ -408,7 +419,7 @@
* This is important in preemption kernels, which transfer the flow
* of execution immediately upon a complete().
*/
- complete_and_exit((us-notify), 0);
+ complete_and_exit(threads_gone, 0);
}
/***
@@ -757,6 +768,7 @@
return p;
}
us-pid = p;
+ atomic_inc(total_threads);
/* Wait for the thread to start */
wait_for_completion((us-notify));
@@ -817,6 +829,13 @@
daemonize(usb-stor-scan);
unlock_kernel();
+ /* Acquire a reference to the host, so it won't be deallocated
+* until we're ready to exit */
+ scsi_host_get(us_to_host(us));
+
+ /* Signal that we've started the thread */
+ complete((us-notify));
+
printk(KERN_DEBUG
usb-storage: device found at %d\n, us-pusb_dev-devnum);
@@ -838,9 +857,12 @@
if (!test_bit(US_FLIDX_DISCONNECTING, us-flags)) {
scsi_scan_host(us_to_host(us));
printk(KERN_DEBUG usb-storage: device scan complete\n);
+
+ /* Should we unbind if no devices were detected? */
}
- complete_and_exit(us-scsi_scan_done, 0);
+ scsi_host_put(us_to_host(us));
+ complete_and_exit(threads_gone, 0);
}
@@ -941,6 +963,10 @@
scsi_remove_host(host);
goto BadDevice;
}
+ atomic_inc(total_threads);
+
+ /* Wait for the thread to start */
+ wait_for_completion((us-notify));
return 0;
@@ -967,10 +993,8 @@
usb_stor_stop_transport(us);
wake_up(us-dev_reset_wait);
- /* Interrupt the SCSI-device-scanning
[linux-usb-devel] Re: [PATCH] Driver to Add Usability for Maxtor External Drives
);
+ list_for_each_entry(entry, onetouch_list, list) {
+ if (entry-udev == udev) {
+ onetouch = entry;
+ list_del(onetouch-list);
+ break;
+ }
+ }
+ spin_unlock(onetouch_list_lock);
+
+ if (onetouch) {
+US_DEBUGP(device found: %s. Releasing\n,
+ onetouch-phys);
+ usb_unlink_urb(onetouch-irq);
+ input_unregister_device(onetouch-dev);
+ usb_free_urb(onetouch-irq);
+ usb_buffer_free(onetouch-udev, ONETOUCH_PKT_LEN,
+ onetouch-data, onetouch-data_dma);
+ kfree(onetouch);
+ }
+
+
+ return 0; /* Should not return anything else (yet)
*/
+ /* FIXME: In the future this should return something like EBUSY */
+ /* If the things being freed here are being used currently */
+}
diff -urN -X dontdiff linux-2.6.11/drivers/usb/storage/onetouch.h
linux-2.6.11mod/drivers/usb/storage/onetouch.h
--- linux-2.6.11/drivers/usb/storage/onetouch.h 1969-12-31
19:00:00.0 -0500
+++ linux-2.6.11mod/drivers/usb/storage/onetouch.h2005-03-11
14:00:01.0 -0500
@@ -0,0 +1,16 @@
+#ifndef _ONETOUCH_H_
+#define _ONETOUCH_H_
+
+#include linux/config.h
+#include linux/input.h
+#include usb.h
+
+#define ONETOUCH_PKT_LEN0x02
+#define ONETOUCH_BUTTON KEY_PROG1
+#define VENDOR_MAXTOR 0x0d49
+#define PRODUCT_ONETOUCH0x7010
+
+int onetouch_connect_input(struct us_data *ss);
+int onetouch_release_input(struct us_data *ss);
+
+#endif
diff -urN -X dontdiff linux-2.6.11/drivers/usb/storage/usb.c
linux-2.6.11mod/drivers/usb/storage/usb.c
--- linux-2.6.11/drivers/usb/storage/usb.c2005-03-02 02:37:50.0
-0500
+++ linux-2.6.11mod/drivers/usb/storage/usb.c 2005-03-11 18:22:11.0
-0500
@@ -87,7 +87,13 @@
#ifdef CONFIG_USB_STORAGE_JUMPSHOT
#include jumpshot.h
#endif
-
+#ifdef CONFIG_USB_STORAGE_ONETOUCH
+#include onetouch.h
+#endif
+#ifndef CONFIG_USB_STORAGE_ONETOUCH
+static inline int onetouch_connect_input (struct us_data *ss) { return 0; }
+static inline int onetouch_release_input (struct us_data *ss) { return 0; }
+#endif
#include linux/module.h
#include linux/init.h
@@ -799,6 +805,14 @@
/* Set the hostdata to prepare for scanning */
us-host-hostdata[0] = (unsigned long) us;
+/* Attempt to connect the onetouch urb to the device */
+ /* Note: If the CONFIG_USB_STORAGE_ONETOUCH is not set */
+ /* onetouch_connect_input(us) will always return 0 */
+ if (onetouch_connect_input(us) != 0) {
+ printk(KERN_WARNING USB_STORAGE
+ Unable to allocate onetouch urb\n);
+ }
+
/* Start up our control thread */
p = kernel_thread(usb_stor_control_thread, us, CLONE_VM);
if (p 0) {
@@ -819,6 +833,14 @@
{
US_DEBUGP(-- %s\n, __FUNCTION__);
+/* Attempt to connect the onetouch urb to the device */
+ /* Note: If the CONFIG_USB_STORAGE_ONETOUCH is not set */
+ /* onetouch_connect_input(us) will always return 0 */
+ if (onetouch_realese_input(us) != 0) {
+ printk(KERN_WARNING USB_STORAGE
+ Unable to allocate onetouch urb\n);
+ }
+
/* Kill the control thread. The SCSI host must already have been
* removed so it won't try to queue any more commands.
*/
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
I'm just trying to think of a way to say up yours without getting fired.
-- Stef
User Friendly, 10/8/1998
pgpu2GPnc60VB.pgp
Description: PGP signature
[linux-usb-devel] PATCH: Header reorganization
This patch started life as as471 from Alan Stern, and has been regenerated against the current tip. This patch cleans up the use of header files. Primarily it makes sure that usb.h is included before any of the other local headers. It also removes some unnecessary declarations of struct us_data and struct scsi_cmnd, and it moves the inclusion of scsi/scsi_host to usb.h where it will be needed by a later patch. Greg, please apply. Signed-off-by: Alan Stern [EMAIL PROTECTED] Signed-off-by: Matthew Dharm [EMAIL PROTECTED] Matt # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/06 17:19:49-08:00 [EMAIL PROTECTED] # as471 # # drivers/usb/storage/usb.h # 2005/03/06 17:18:14-08:00 [EMAIL PROTECTED] +1 -0 # as471 # # drivers/usb/storage/usb.c # 2005/03/06 17:18:14-08:00 [EMAIL PROTECTED] +3 -4 # as471 # # drivers/usb/storage/transport.h # 2005/03/06 17:18:14-08:00 [EMAIL PROTECTED] +0 -3 # as471 # # drivers/usb/storage/transport.c # 2005/03/06 17:18:13-08:00 [EMAIL PROTECTED] +1 -1 # as471 # # drivers/usb/storage/shuttle_usbat.c # 2005/03/06 17:18:13-08:00 [EMAIL PROTECTED] +1 -1 # as471 # # drivers/usb/storage/sddr55.c # 2005/03/06 17:18:13-08:00 [EMAIL PROTECTED] +1 -1 # as471 # # drivers/usb/storage/sddr09.c # 2005/03/06 17:18:13-08:00 [EMAIL PROTECTED] +1 -1 # as471 # # drivers/usb/storage/scsiglue.h # 2005/03/06 17:18:13-08:00 [EMAIL PROTECTED] +0 -5 # as471 # # drivers/usb/storage/scsiglue.c # 2005/03/06 17:18:13-08:00 [EMAIL PROTECTED] +1 -2 # as471 # # drivers/usb/storage/protocol.h # 2005/03/06 17:18:13-08:00 [EMAIL PROTECTED] +0 -3 # as471 # # drivers/usb/storage/protocol.c # 2005/03/06 17:18:13-08:00 [EMAIL PROTECTED] +2 -1 # as471 # # drivers/usb/storage/jumpshot.c # 2005/03/06 17:18:13-08:00 [EMAIL PROTECTED] +1 -1 # as471 # # drivers/usb/storage/isd200.c # 2005/03/06 17:18:13-08:00 [EMAIL PROTECTED] +1 -1 # as471 # # drivers/usb/storage/initializers.c # 2005/03/06 17:18:13-08:00 [EMAIL PROTECTED] +2 -0 # as471 # # drivers/usb/storage/freecom.c # 2005/03/06 17:18:12-08:00 [EMAIL PROTECTED] +1 -1 # as471 # # drivers/usb/storage/dpcm.c # 2005/03/06 17:18:12-08:00 [EMAIL PROTECTED] +1 -1 # as471 # # drivers/usb/storage/debug.h # 2005/03/06 17:18:12-08:00 [EMAIL PROTECTED] +0 -2 # as471 # # drivers/usb/storage/datafab.c # 2005/03/06 17:18:12-08:00 [EMAIL PROTECTED] +1 -1 # as471 # diff -Nru a/drivers/usb/storage/datafab.c b/drivers/usb/storage/datafab.c --- a/drivers/usb/storage/datafab.c 2005-03-13 21:34:34 -08:00 +++ b/drivers/usb/storage/datafab.c 2005-03-13 21:34:34 -08:00 @@ -57,9 +57,9 @@ #include scsi/scsi.h #include scsi/scsi_cmnd.h +#include usb.h #include transport.h #include protocol.h -#include usb.h #include debug.h #include datafab.h diff -Nru a/drivers/usb/storage/debug.h b/drivers/usb/storage/debug.h --- a/drivers/usb/storage/debug.h 2005-03-13 21:34:34 -08:00 +++ b/drivers/usb/storage/debug.h 2005-03-13 21:34:34 -08:00 @@ -47,8 +47,6 @@ #include linux/config.h #include linux/kernel.h -struct scsi_cmnd; - #define USB_STORAGE usb-storage: #ifdef CONFIG_USB_STORAGE_DEBUG diff -Nru a/drivers/usb/storage/dpcm.c b/drivers/usb/storage/dpcm.c --- a/drivers/usb/storage/dpcm.c2005-03-13 21:34:34 -08:00 +++ b/drivers/usb/storage/dpcm.c2005-03-13 21:34:34 -08:00 @@ -34,9 +34,9 @@ #include scsi/scsi_cmnd.h #include scsi/scsi_device.h +#include usb.h #include transport.h #include protocol.h -#include usb.h #include debug.h #include dpcm.h #include sddr09.h diff -Nru a/drivers/usb/storage/freecom.c b/drivers/usb/storage/freecom.c --- a/drivers/usb/storage/freecom.c 2005-03-13 21:34:34 -08:00 +++ b/drivers/usb/storage/freecom.c 2005-03-13 21:34:34 -08:00 @@ -34,9 +34,9 @@ #include scsi/scsi.h #include scsi/scsi_cmnd.h +#include usb.h #include transport.h #include protocol.h -#include usb.h #include debug.h #include freecom.h diff -Nru a/drivers/usb/storage/initializers.c b/drivers/usb/storage/initializers.c --- a/drivers/usb/storage/initializers.c2005-03-13 21:34:34 -08:00 +++ b/drivers/usb/storage/initializers.c2005-03-13 21:34:34 -08:00 @@ -39,6 +39,8 @@ #include linux/sched.h #include linux/errno.h + +#include usb.h #include initializers.h #include debug.h #include transport.h diff -Nru a/drivers/usb/storage/isd200.c b/drivers/usb/storage/isd200.c --- a/drivers/usb/storage/isd200.c 2005-03-13 21:34:34 -08:00 +++ b/drivers/usb/storage/isd200.c 2005-03-13 21:34:34 -08:00 @@ -54,9 +54,9 @@ #include scsi/scsi_cmnd.h #include scsi/scsi_device.h +#include usb.h #include transport.h #include protocol.h -#include usb.h #include debug.h #include scsiglue.h #include isd200.h diff -Nru a/drivers/usb/storage/jumpshot.c b/drivers/usb/storage/jumpshot.c --- a/drivers/usb/storage/jumpshot.c2005-03-13 21:34:34 -08:00 +++ b/drivers/usb/storage/jumpshot.c2005
[linux-usb-devel] PATCH: remove unneeded NULL tests
This patch started life as as472 from Alan Stern, and has been rediffed against the current tip. This patch simply removes some unnecessary NULL checking before kfree() calls. Greg, please apply. Signed-off-by: Alan Stern [EMAIL PROTECTED] Signed-off-by: Matthew Dharm [EMAIL PROTECTED] Matt # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/06 17:42:07-08:00 [EMAIL PROTECTED] # as472 # # drivers/usb/storage/usb.c # 2005/03/06 17:41:46-08:00 [EMAIL PROTECTED] +2 -5 # as472 # diff -Nru a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c --- a/drivers/usb/storage/usb.c 2005-03-13 21:34:20 -08:00 +++ b/drivers/usb/storage/usb.c 2005-03-13 21:34:20 -08:00 @@ -829,11 +829,8 @@ scsi_host_put(us-host); /* Free the extra data and the URB */ - if (us-extra) - kfree(us-extra); - if (us-current_urb) - usb_free_urb(us-current_urb); - + kfree(us-extra); + usb_free_urb(us-current_urb); } /* Dissociate from the USB device */ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver P: How about Web Designer? DP: I'd like a name that people won't laugh at. -- Pitr and Dust Puppy User Friendly, 12/6/1997 pgpdTMU2xEM7C.pgp Description: PGP signature
Re: [linux-usb-devel] [PATCH] Add US_FL_GO_SLOW flag, and associated entries
On Thu, Feb 17, 2005 at 10:13:03PM -0800, Phil Dibowitz wrote: So I decided to try to take a leap into BK. It took some fiddling to get it to make a patch, so this *should* work, but I make no promises. I haven't figured out how to test this since I haven't figured out how to get the whole thing. I.e., it's all checked in, and 'bk get' doesn't seem to be recursive. Without the whole thing, I can't copy a .config in there and compile. But it's based on the latest greg-kh tree. The recursive version is: bk -r get Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Somebody call an exorcist! -- Dust Puppy User Friendly, 5/16/1998 pgpF7wog4mb50.pgp Description: PGP signature
Re: [linux-usb-devel] Error with usb storage
: usb_stor_control_msg: rq=01 rqtype=02 value= index=01 len=0 usb-storage: usb_stor_clear_halt: result = 0 usb-storage: Soft reset done usb-storage: queuecommand called usb-storage: *** thread awakened. usb-storage: Command TEST_UNIT_READY (6 bytes) usb-storage: 00 00 00 00 00 00 usb-storage: Bulk Command S 0x43425355 T 0x1 L 0 F 0 Trg 0 LUN 0 CL 6 usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes usb-storage: Status code 0; transferred 31/31 usb-storage: -- transfer complete usb-storage: Bulk command transfer result=0 usb-storage: Attempting to get CSW... usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes usb-storage: Status code 0; transferred 13/13 usb-storage: -- transfer complete usb-storage: Bulk status result = 0 usb-storage: Bulk Status S 0x53425300 T 0x1 R 0 Stat 0x0 usb-storage: Bulk logical error usb-storage: -- transport indicates error, resetting usb-storage: usb_stor_Bulk_reset called usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value= index=00 len=0 usb-storage: Soft reset: clearing bulk-in endpoint halt usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value= index=81 len=0 usb-storage: usb_stor_clear_halt: result = 0 usb-storage: Soft reset: clearing bulk-out endpoint halt usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value= index=01 len=0 usb-storage: usb_stor_clear_halt: result = 0 usb-storage: Soft reset done usb-storage: scsi cmd done, result=0x7 usb-storage: *** thread sleeping. usb-storage: bus_reset called usb 1-2: reset full speed USB device using uhci_hcd and address 2 usb-storage: usb_reset_device returns 0 usb-storage: queuecommand called usb-storage: *** thread awakened. usb-storage: Command TEST_UNIT_READY (6 bytes) usb-storage: 00 00 00 00 00 00 usb-storage: Bulk Command S 0x43425355 T 0x1 L 0 F 0 Trg 0 LUN 0 CL 6 usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes usb-storage: Status code 0; transferred 31/31 usb-storage: -- transfer complete usb-storage: Bulk command transfer result=0 usb-storage: Attempting to get CSW... usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes usb-storage: Status code 0; transferred 13/13 usb-storage: -- transfer complete usb-storage: Bulk status result = 0 usb-storage: Bulk Status S 0x53425300 T 0x1 R 0 Stat 0x0 usb-storage: Bulk logical error usb-storage: -- transport indicates error, resetting usb-storage: usb_stor_Bulk_reset called usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value= index=00 len=0 usb-storage: Soft reset: clearing bulk-in endpoint halt usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value= index=81 len=0 usb-storage: usb_stor_clear_halt: result = 0 usb-storage: Soft reset: clearing bulk-out endpoint halt usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value= index=01 len=0 usb-storage: usb_stor_clear_halt: result = 0 usb-storage: Soft reset done usb-storage: scsi cmd done, result=0x7 usb-storage: *** thread sleeping. scsi: Device offlined - not ready after error recovery: host 0 channel 0 id 0 lun 0 usb-storage: queuecommand called usb-storage: *** thread awakened. usb-storage: Bad target number (1:0) usb-storage: scsi cmd done, result=0x4 usb-storage: *** thread sleeping. usb-storage: queuecommand called usb-storage: *** thread awakened. usb-storage: Bad target number (2:0) usb-storage: scsi cmd done, result=0x4 usb-storage: *** thread sleeping. usb-storage: queuecommand called usb-storage: *** thread awakened. usb-storage: Bad target number (3:0) usb-storage: scsi cmd done, result=0x4 usb-storage: *** thread sleeping. usb-storage: queuecommand called usb-storage: *** thread awakened. usb-storage: Bad target number (4:0) usb-storage: scsi cmd done, result=0x4 usb-storage: *** thread sleeping. usb-storage: queuecommand called usb-storage: *** thread awakened. usb-storage: Bad target number (5:0) usb-storage: scsi cmd done, result=0x4 usb-storage: *** thread sleeping. usb-storage: queuecommand called usb-storage: *** thread awakened. usb-storage: Bad target number (6:0) usb-storage: scsi cmd done, result=0x4 usb-storage: *** thread sleeping. usb-storage: queuecommand called usb-storage: *** thread awakened. usb-storage: Bad target number (7:0) usb-storage: scsi cmd done, result=0x4 usb-storage: *** thread sleeping. usb-storage: device scan complete --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux
Re: [linux-usb-devel] write protection handling on usb-storage devices
On Wed, Feb 09, 2005 at 11:49:42AM -0500, Alan Stern wrote: On Wed, 2 Feb 2005, Matthew Dharm wrote: On Wed, Feb 02, 2005 at 11:57:57AM -0500, Alan Stern wrote: Below is a patch for 2.6.11-rc2 that makes write-protect detection into a module parameter. Matt Dharm has considered doing this in the past; I don't remember if he came to a final decision. Is there a place where we can keep all that useful descriptive text? I really don't want to throw it away, just to be bombarded by what's this parameter for questions... Considering that only a small number of devices are unable to handle write-protect detection (I've seen reports for no more than two), maybe we should just make it into another unusual_devs flag? That way there's nothing to configure either during a build or at runtime. I think this is valid only if many people are setting CONFIG_USB_STORAGE_RW_DETECT. Do you think that's a valid assumption? I'm not sure... Originally we made it a config option because it caused trouble so often. But now that we always request a 192-byte transfer, it almost never fails. Changing it to a device flag would be the simplest approach. If most people are already setting the option, then this is probably a good idea. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver You suck Stef. -- Greg User Friendly, 11/29/97 pgpANhlAYslI7.pgp Description: PGP signature
Re: [linux-usb-devel] Re: [PATCH as447] Re: [ak@suse.de: [PATCH] Fix EHCI boot oops on AMD 8111]
On Tue, Feb 08, 2005 at 10:03:47AM +0100, Andi Kleen wrote: On Mon, Feb 07, 2005 at 04:02:44PM -0800, Matthew Dharm wrote: On Tue, Feb 08, 2005 at 12:19:19AM +0100, Andi Kleen wrote: Remove useless AMD 8111 EHCI USB 2.0 errata check. The BIOS disable it anyways when needed, and when not then the hardware works. This cleans up the EHCI driver a bit which shouldn't need to know about such Erratas. Signed-off-by: Andi Kleen [EMAIL PROTECTED] This is not a valid assertion. The IBM 970FX Evaluation Platform (aka Maple-D) has an 8111 but does _not_ have an x86 BIOS. So the device tree is built from a normal PCI-scan (unlike x86 BIOS which passes an explicit tree). That device tree therefore shows the device. That sounds like a firmware bug then. Perhaps it would be better to fix the firmware than to add these workarounds to Linux code? We've tried. AMD tells us that there is no way to physically disable the controller. So, Linux will see it when it does a PCI scan. There's nothing the firmware can do about this. The patch was actually constructed to account for this case and all derivative designs of the 970FX technology. Just apparently nobody tested it because it didn't work at all and caused a oops at boot. Therefore this code cannot be too useful, otherwise all these 970FX users would have noticed the failure. When the patch was created, it worked just fine. These OOPSes only started happening well after that patch was merged. That patch is quite old now -- it was created in the 2.6.9 timeframe. And, as I understand it, the problem isn't specific to that patch -- that patch just forces us down an error-handling code-path by returing -EIO, and you can get to that code paths in other ways. So the proper thing to do is fix the usage of the driver core (which, as I seem to recall, a patch has been available to do for weeks). BTW EHCI works, you just shouldn't use any USB 2.0 devices. But there are valid reasons in some cases to want to have EHCI even on a 8111, e.g. if you want to use the debug port. It's annoying to have to fight against such dumb code in the kernel then. The official errata from AMD says don't use EHCI. There's no indication that it works under any circumstances. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver C: Like the Furby? DP: He gives me the creeps. Think the SPCA will take him? -- Cobb and Dust Puppy User Friendly, 1/2/1999 pgpWlhiMSfSWu.pgp Description: PGP signature
Re: [linux-usb-devel] Re: [PATCH as447] Re: [ak@suse.de: [PATCH] Fix EHCI boot oops on AMD 8111]
On Tue, Feb 08, 2005 at 04:34:01PM +0100, Andi Kleen wrote: So how does one use EHCI on an 8111, if the BIOS disables it anyway when needed? E.g., on an IBM IntelliStation A Pro Type 6224? There's a bit somewhere in the southbridge (sorry would need to look it up in the datasheet and you can do that as well yourself ;-) I'm looking at the July 2004 datasheet from AMD's web site now. I don't see this bit anywhere. I've also checked the errata list (April 2004) and there's nothing there, either. If you know where this magic bit is, then please share it with us. I would love to fix this in the firmware, and this piece of knowledge is the only thing keeping us from doing so. Of course, that still doesn't change the fact that we've got a bug that can be hit by other types of probing errors that will cause an OOPS. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Your lips are twitching. You're playing Quake aren't you. -- Stef to Greg User Friendly, 8/11/1998 pgppnSUhUdZY3.pgp Description: PGP signature
Re: [linux-usb-devel] Re: [PATCH as447] Re: [ak@suse.de: [PATCH] Fix EHCI boot oops on AMD 8111]
On Tue, Feb 08, 2005 at 05:40:00PM -0800, Randy.Dunlap wrote: I wrote code to turn off the 0x80 bit at PCI config space offset 0x47 in DevB, or at least I think I did, but it's not working. Is it being done too late? The patch is attached. Matt, did you try this? working for you? I haven't tried it yet... But, you probably need to use lspci with -H1, or it will just read the kernel's (effectively) cached copy of the data the BIOS passed to it originally. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver THEY CASTRATED MY QUAKE BITS! I WANT THEM BACK -- Greg User Friendly, 3/27/1998 pgphk0Oi17aAX.pgp Description: PGP signature
Re: [linux-usb-devel] Re: [PATCH as447] Re: [ak@suse.de: [PATCH] Fix EHCI boot oops on AMD 8111]
On Tue, Feb 08, 2005 at 05:46:02PM -0800, Matthew Dharm wrote: On Tue, Feb 08, 2005 at 05:40:00PM -0800, Randy.Dunlap wrote: I wrote code to turn off the 0x80 bit at PCI config space offset 0x47 in DevB, or at least I think I did, but it's not working. Is it being done too late? The patch is attached. Matt, did you try this? working for you? I haven't tried it yet... But, you probably need to use lspci with -H1, or it will just read the kernel's (effectively) cached copy of the data the BIOS passed to it originally. Going in via a debug mechanism on the 970 designs, I can verify that setting this bit at least makes the VID/PID disappear. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 pgpWYSSWh1flR.pgp Description: PGP signature
Re: [linux-usb-devel] Re: [PATCH as447] Re: [ak@suse.de: [PATCH] Fix EHCI boot oops on AMD 8111]
On Tue, Feb 08, 2005 at 12:19:19AM +0100, Andi Kleen wrote: Remove useless AMD 8111 EHCI USB 2.0 errata check. The BIOS disable it anyways when needed, and when not then the hardware works. This cleans up the EHCI driver a bit which shouldn't need to know about such Erratas. Signed-off-by: Andi Kleen [EMAIL PROTECTED] This is not a valid assertion. The IBM 970FX Evaluation Platform (aka Maple-D) has an 8111 but does _not_ have an x86 BIOS. So the device tree is built from a normal PCI-scan (unlike x86 BIOS which passes an explicit tree). That device tree therefore shows the device. The patch was actually constructed to account for this case and all derivative designs of the 970FX technology. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver M: No, Windows doesn't have any nag screens. C: Then what are those blue and white screens I get every day? -- Mike and Cobb User Friendly, 1/4/1999 pgpohhyhM6DHM.pgp Description: PGP signature
Re: [linux-usb-devel] [PATCH] To add extra usability for the Maxtor Onetouch External Hard-drives
On Thu, Feb 03, 2005 at 07:34:31PM -0500, Nick Sillik wrote: I have taken all of the suggestions the list has given me, and I have here, for you a single patch for the kernel to allow usb-stoarge to recognize the Maxtor OneTouch's 'onetouch' button. The diff for the 2.6.10 vanilla kernel follows: Signed-Off-By: Nicholas M. Sillik [EMAIL PROTECTED] Your patch got line-wrapped by your mailer. You need to fix this and resend. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 pgp8dhAXTj42y.pgp Description: PGP signature
