Re: [linux-usb-devel] imx21-hcd bugs, device descriptor read/64, error -110
On Mon, 13 Aug 2007, David Brownell wrote: On Monday 13 August 2007, Midhun Agnihotram wrote: Hi All, We are have a development kit on which we are trying to run USB host port. The drivers are from the vendor. The kernel recognizes the USB host controller. But as soon as we insert a USB flash drive, the kernel hangs with the following error: usb 1-2: device descriptor read/64, error -110 I'm not surprised the system gets hung up. The urb_dequeue method doesn't do anything! Does the vendor have any help to offer you? How well do they say it should work? Can they report that it runs for a week with all the tests listed in http://www.linux-usb.org/usbtest/ which apply to host side drivers? With lockdep and memory poisoning enabled? Good questions. With something like this, it really is up to the vendor to make sure the driver works properly with their hardware. This version of the source code is clearly preliminary and experimental. It shouldn't be expected to work perfectly. Alan Stern - 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
[linux-usb-devel] Change to ed_halted in ohci-q.c
Dave:
Could you please do a sanity check on this patch? It looks okay to me
and it seems to work, but there's no substitute for having a
knowledgeable pair of eyeballs look at it.
The idea is that when an URB gets an error, there's no need to put all
the TDs after the one that failed through the done list. They can be
removed right away, and then the URB can be given back as soon as the
failed TD is reached.
Thanks,
Alan Stern
Index: usb-2.6/drivers/usb/host/ohci-q.c
===
--- usb-2.6.orig/drivers/usb/host/ohci-q.c
+++ usb-2.6/drivers/usb/host/ohci-q.c
@@ -795,10 +795,10 @@ static void td_done (struct ohci_hcd *oh
/*-*/
-static inline struct td *
-ed_halted (struct ohci_hcd *ohci, struct td *td, int cc, struct td *rev)
+static void ed_halted(struct ohci_hcd *ohci, struct td *td, int cc)
{
struct urb *urb = td-urb;
+ urb_priv_t *urb_priv = urb-hcpriv;
struct ed *ed = td-ed;
struct list_head*tmp = td-td_list.next;
__hc32 toggle = ed-hwHeadP cpu_to_hc32 (ohci, ED_C);
@@ -810,13 +810,12 @@ ed_halted (struct ohci_hcd *ohci, struct
wmb ();
ed-hwHeadP = ~cpu_to_hc32 (ohci, ED_H);
- /* put any later tds from this urb onto the donelist, after 'td',
-* order won't matter here: no errors, and nothing was transferred.
-* also patch the ed so it looks as if those tds completed normally.
+ /* Get rid of all later tds from this urb. We don't have
+* to be careful: no errors and nothing was transferred.
+* Also patch the ed so it looks as if those tds completed normally.
*/
while (tmp != ed-td_list) {
struct td *next;
- __hc32 info;
next = list_entry (tmp, struct td, td_list);
tmp = next-td_list.next;
@@ -831,14 +830,9 @@ ed_halted (struct ohci_hcd *ohci, struct
* then we need to leave the control STATUS packet queued
* and clear ED_SKIP.
*/
- info = next-hwINFO;
- info |= cpu_to_hc32 (ohci, TD_DONE);
- info = ~cpu_to_hc32 (ohci, TD_CC);
- next-hwINFO = info;
-
- next-next_dl_td = rev;
- rev = next;
+ list_del(next-td_list);
+ urb_priv-td_cnt++;
ed-hwHeadP = next-hwNextTD | toggle;
}
@@ -864,8 +858,6 @@ ed_halted (struct ohci_hcd *ohci, struct
hc32_to_cpu (ohci, td-hwINFO),
cc, cc_to_error [cc]);
}
-
- return rev;
}
/* replies to the request have to be on a FIFO basis so
@@ -902,7 +894,7 @@ static struct td *dl_reverse_done_list (
*/
if (cc != TD_CC_NOERROR
(td-ed-hwHeadP cpu_to_hc32 (ohci, ED_H)))
- td_rev = ed_halted (ohci, td, cc, td_rev);
+ ed_halted(ohci, td, cc);
td-next_dl_td = td_rev;
td_rev = td;
-
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] USB-Core, fix cardreader not found during init
On Mon, 13 Aug 2007, Steffen Koepf wrote:
From: Steffen Koepf [EMAIL PROTECTED]
There is a USB-Device Init-Problem with the Apacer AE161 USB-Cardreader,
which contains the Chip AU6375. The Cardreader init fails in about 50%
of system boots, with the following lines:
usb 1-6: unable to read config index 0 descriptor/all
usb 1-6: can't read configurations, error -71
hub 1-0:1.0: Cannot enable port 6. Maybe the USB cable is bad?
The patch let's the kernel stay in the loop if a usb_control_msg() fails,
the cardreader is detected properly and the loop is never executed more
than two times. The second call of usb_control_msg succeeds always. Maybe
it was the developer's goal of the loop to fix such things?
Kernel: 2.6.22.2
Signed-off-by: Steffen Koepf [EMAIL PROTECTED]
---
--- linux-2.6.22.2/drivers/usb/core/message.c.origMon Aug 13 22:12:34 2007
+++ linux-2.6.22.2/drivers/usb/core/message.c Mon Aug 13 22:12:52 2007
@@ -634,6 +634,8 @@ int usb_get_descriptor(struct usb_device
result = -EPROTO;
continue;
}
+ if (result 0)
+ continue;
break;
}
return result;
This patch is the wrong way to do it. You should try this patch
instead.
Alan Stern
Index: 2.6.22/drivers/usb/core/message.c
===
--- 2.6.22.orig/drivers/usb/core/message.c
+++ 2.6.22/drivers/usb/core/message.c
@@ -623,12 +623,12 @@ int usb_get_descriptor(struct usb_device
memset(buf,0,size); // Make sure we parse really received data
for (i = 0; i 3; ++i) {
- /* retry on length 0 or stall; some devices are flakey */
+ /* retry on length 0 or error; some devices are flakey */
result = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
(type 8) + index, 0, buf, size,
USB_CTRL_GET_TIMEOUT);
- if (result == 0 || result == -EPIPE)
+ if (result = 0)
continue;
if (result 1 ((u8 *)buf)[1] != type) {
result = -EPROTO;
-
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] USB-Core, fix cardreader not found during init
On Mon, 13 Aug 2007, Alan Stern wrote:
This patch is the wrong way to do it. You should try this patch
instead.
Alan Stern
Index: 2.6.22/drivers/usb/core/message.c
===
--- 2.6.22.orig/drivers/usb/core/message.c
+++ 2.6.22/drivers/usb/core/message.c
@@ -623,12 +623,12 @@ int usb_get_descriptor(struct usb_device
memset(buf,0,size); // Make sure we parse really received data
for (i = 0; i 3; ++i) {
- /* retry on length 0 or stall; some devices are flakey */
+ /* retry on length 0 or error; some devices are flakey */
result = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
(type 8) + index, 0, buf, size,
USB_CTRL_GET_TIMEOUT);
- if (result == 0 || result == -EPIPE)
+ if (result = 0)
continue;
On further thought, perhaps we shouldn't retry on -ETIMEDOUT errors.
- if (result == 0 || result == -EPIPE)
+ if (result = 0 result != -ETIMEDOUT)
Alan Stern
-
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] Disable autosuspend for scanners/printers
On Sun, 12 Aug 2007, Oliver Neukum wrote: Am Donnerstag 09 August 2007 schrieb Alan Stern: Oliver and Pete: Is it possible to replace all those USB_QUIRK_NO_AUTOSUSPEND entries for scanners with a single class-wide entry? Which class? It would have to blanket all vendor specific devices. This is a rather broad swipe. I was hoping there would be a specific device class for scanners. Oh well. I'm beginning to agree with Matthew Garrett that autosuspend should be disabled by default except for known-good devices and device classes... What about printers? Just remove the autosuspend support from the driver if you really want to do this. Is that good enough? If a printer is plugged in when the system boots, the delay between enumerating the device and loading the driver can be long enough for the device to get autosuspended. Would a USB_QUIRK_RESET_RESUME entry suffice or do we really need NO_AUTOSUSPEND? Having no way to test, I am conservative. Besides, is RESET_RESUME the right thing to do for a device driven by usbfs? It would turn close() into an operation that can cause a reset as a side effect. There's nothing wrong with that. The kernel makes no guarantees about what happens to a device driven by usbfs while its file is closed. The next program to open the file can't depend on finding the device in any particular state; this has always been true. Alan Stern - 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] Disable autosuspend for scanners/printers
On Sun, 12 Aug 2007, Oliver Neukum wrote: I'm beginning to agree with Matthew Garrett that autosuspend should be disabled by default except for known-good devices and device classes... We could simply revert to enabling autosuspend only for those devices whose driver requests it. Most problems are with devices accessed through usbfs. That's not the point. We're okay with drivers that don't support autosuspend and we're mostly okay with drivers that do. The problems seem to fall into two classes: 1. Devices with no driver. 2. Devices that can't suspend but whose driver requests autosuspend. Case 1 includes usbfs. However all devices -- other than hubs -- can fall into case 1 temporarily, if it takes longer than a few seconds to load their driver module. (Note that usbfs doesn't support autosuspend. Hence any device claimed by usbfs won't autosuspend until the device file is closed.) If a device has no driver then it's logical to assume the kernel knows nothing about how the device will behave (unless the device belongs to a known-good class). The safest course is to leave autosuspend disabled by default and let userspace enable it if desired. This leaves open the question of what to do when the first driver binds to the device or the last driver unbinds. Case 2 is harder; it includes the troublesome printers. For them we may rely on the quirks list or change the printer driver. Is that good enough? If a printer is plugged in when the system boots, the delay between enumerating the device and loading the driver can be long enough for the device to get autosuspended. How many devices truely crash? I don't know. Weren't you the person who added all those entries to the quirks list? One of the RedHat Bugzilla reports includes a usbmon log from a printer, showing that the printer disconnects itself whenever it gets a resume (and then reconnects a little later). That's almost as bad as crashing. Alan Stern - 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] OHCI suspend/resume issue.
On Fri, 10 Aug 2007, David Brownell wrote: The code in ohci-hcd isn't very sophisticated about checking for interference from the firmware. Maybe because there are so many different implementations of OHCI floating around, it's hard to know what approach will work on all of them. And maybe because there aren't many settings which can be checked. On the contrary ... it's relatively sophisticated, precisely since there ARE so many different hardware variations. Relatively sophisticated? All it does is check if the firmware owns the controller or the controller is in a reset state. There's nothing like a Configured flag to check. I'd say that makes it less sophisticated than ehci-hcd or uhci-hcd. Alan Stern - 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 2/8] NIKON D50 is an unusual device
On Fri, 10 Aug 2007 [EMAIL PROTECTED] wrote: From: Milinevsky Dmitry [EMAIL PROTECTED] This short patch allows NIKON D50 to be mounted as UMS[unusual device] on Linux niam 2.6.22-rc7-cfs-v18 #2 PREEMPT Tue Jul 3 22:35:53 EEST 2007 i686 Intel(R) Celeron(R) M processor 1.50GHz GenuineIntel GNU/Linux, some previous kernels... diff -puN drivers/usb/storage/unusual_devs.h~nikon-d50-is-an-unusual-device drivers/usb/storage/unusual_devs.h --- a/drivers/usb/storage/unusual_devs.h~nikon-d50-is-an-unusual-device +++ a/drivers/usb/storage/unusual_devs.h @@ -327,6 +327,13 @@ UNUSUAL_DEV( 0x04b0, 0x0409, 0x0100, 0x US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_FIX_CAPACITY), +/* Reported by Milinevsky Dmitry [EMAIL PROTECTED] */ +UNUSUAL_DEV( 0x04b0, 0x0409, 0x0100, 0x0100, + NIKON, + NIKON DSC D50, + US_SC_DEVICE, US_PR_DEVICE, NULL, + US_FL_FIX_CAPACITY), + /* Reported by Andreas Bockhold [EMAIL PROTECTED] */ UNUSUAL_DEV( 0x04b0, 0x0405, 0x0100, 0x0100, NIKON, If I'm reading this correctly, the patch adds a duplicate entry. And the two entries aren't even in the right place since 0x0409 should come after 0x0405, not before. Alan Stern - 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 2/8] NIKON D50 is an unusual device
On Sat, 11 Aug 2007, [EMAIL PROTECTED] wrote: On my system(2.6.22) I don't have @@ -327,6 +327,13 @@ UNUSUAL_DEV( 0x04b0, 0x0409, 0x0100, 0x US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_FIX_CAPACITY), 2 Alan Stern: sorry for duplication - forgot to add 'cc'. Best regards, Dima. Maybe you don't have it on your system but it sure seems to be present in the -mm tree already, judging from the context information in the patch. Perhaps someone else added the same thing at about the same time. Andrew, could you please check whether the UNUSUAL_DEV( 0x04b0, 0x0409, 0x0100, 0x0100, entry is present twice in drivers/usb/storage/unusual_devs.h? Alan Stern - 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] Disable autosuspend for scanners/printers
On Fri, 10 Aug 2007, Sam Liddicott wrote: From: Greg KH [EMAIL PROTECTED] Sent: 10/08/07 04:30 =There's no way we could ever get a list of all good or all bad printers, =so no matter what we do, we'd miss some :( But better to miss suspend on some than miss working altogether on others surely? I never heard an outcry on lack if suspend that compares to that from those whose USB devices stopped working when their distro upgraded the kernel. Even if we don't handle printers right now, it would help to cover all scanners with a single class-wide quirks entry instead of lots of individual device entries. Alan Stern - 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] Question about hub_thread
On Fri, 10 Aug 2007, jidong xiao wrote:
Here are the piece of code from 2.6.22.1,
2817 static int hub_thread(void *__unused)
2818 {
2819 do {
2820 hub_events();
2821 wait_event_interruptible(khubd_wait,
2822 !list_empty(hub_event_list) ||
2823 kthread_should_stop());
2824 try_to_freeze();
2825 } while (!kthread_should_stop() ||
!list_empty(hub_event_list));
2826
2827 pr_debug(%s: khubd exiting\n, usbcore_name);
2828 return 0;
2829 }
I have a question.
try_to_freeze should be the only way for this thread to go suspended.
If we have already gone sleeping via wait_event_interruptible(), then
if there is signal to wakeup this thread and ask it to go to
suspended,then wait_event_interruptible will return and
try_to_freeze() will be invoked and hence this thread will go into
refrigerator.
But if we are still running inside hub_events(),then if we received
any signal, what will happen?still try_to_freeze will be executed?why?
Nothing will happen. The thread will continue to run inside
hub_events() and it won't freeze until hub_events() returns.
Alan Stern
-
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] USB: make HCDs responsible for managing endpoint queues
On Fri, 10 Aug 2007, Yoshihiro Shimoda wrote: Hi, Alan Please test the changes to your respective drivers. I don't have the necessary hardware. I applied this patch. I tested USB testing driver and some usb device and I confirmed it is working. Good. Thank you for testing. Alan Stern - 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] OHCI suspend/resume issue.
On Fri, 10 Aug 2007, Zephaniah E. Hull wrote: After you get up :-), check udev-state at the end of usb_suspend_device(). It should be USB_STATE_SUSPENDED, and nothing should change it until usb_resume_device() runs. Are you maybe seeing ohci_rh_resume() get called twice in a row? Got side tracked while tracking down the issue below. We are not calling ohci_rh_resume twice, and in usb_hcd_pci_suspend we are in USB_STATE_CONFIGURED. Throwing in a few more debugging statements to figure out if we ever set to USB_STATE_SUSPENDED, and if so, where we unset it. udev-state is supposed to get set to USB_STATE_SUSPENDED in hcd_bus_suspend() in core/hcd.c. (This is before usb_hcd_pci_suspend() gets called.) Does something go wrong there? I now have a better idea of what we are currently doing on resume. I don't have a good idea of what we should be doing on resume. When the OLPC comes up from suspend, a small bit of Open Firmware code gets run, this writes 1 to HcCommandStatus, resetting the OHCI chip into Suspend mode, then writes into HcRhDescriptorB and HcRhPortStatus*, bringing up the power to the USB ports. After that the OS gets started, so by the time the Linux OHCI code sees things, we're already in suspend mode and the power to the ports is on, but otherwise we're fresh from chip power on. However since the chip isn't actually in reset, ohci_rh_resume doesn't jump through the right hoops. This is a problem. The code in ohci-hcd isn't very sophisticated about checking for interference from the firmware. Maybe because there are so many different implementations of OHCI floating around, it's hard to know what approach will work on all of them. And maybe because there aren't many settings which can be checked. Changing what OFW does on resume is possible, if it's flatly not doing what it should. But a driver fix would be preferred in some ways. Any thoughts? I'd say OFW is flatly not doing what it should. In fact, from your description it goes out of its way to fool Linux into thinking the controller was powered on the whole time when in fact it wasn't. Because the power was off the controller has just gone through a hardware reset; there's absolutely no need to pile a software reset on top of that. Of course you can always work around this by making an OLPC-specific change to the driver. I can't think of any general way to detect this sort of thing that would be suitable for the standard kernel, however. Alan Stern - 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
[linux-usb-devel] [RFC] Accept single-byte Device Status responses
I've seen two reports of devices that wrongly send a 1-byte reply to
Get-Device-Status requests instead of a 2-byte reply. One was a
printer and the other a mass-storage device.
This bug causes problems during USB resume, because
finish_port_resume() checks the device status and concludes that
something has gone wrong if it doesn't get a proper 2-byte reply.
When autosuspend starts kicking in and at each autoresume the kernel
thinks the device has gone away, obviously we're heading for trouble.
In theory, lack of the second byte shouldn't matter much. According to
the USB 2.0 spec it must always be equal to 0. So maybe we don't
need to be such sticklers about insisting that it always be present.
Does anybody object to the patch below? (Note that usb_get_status()
returns the actual_length of the reply.) If there's no response, I'll
submit it to Greg after a few days.
Dave, you might want to try this with your printers. It might
enable some of them to work with autosuspend.
Alan Stern
Index: usb-2.6/drivers/usb/core/hub.c
===
--- usb-2.6.orig/drivers/usb/core/hub.c
+++ usb-2.6/drivers/usb/core/hub.c
@@ -1764,9 +1764,10 @@ static int finish_port_resume(struct usb
* and device drivers will know about any resume quirks.
*/
if (status == 0) {
+ devstatus = 0;
status = usb_get_status(udev, USB_RECIP_DEVICE, 0, devstatus);
if (status = 0)
- status = (status == 2 ? 0 : -ENODEV);
+ status = (status 0 ? 0 : -ENODEV);
}
if (status) {
-
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] [usb-storage] schedule_timeout: wrong timeout value c1a95554
On Thu, 9 Aug 2007, Mariusz Kozlowski wrote: Hello, Happens every time I reattach usb pen drive. usb 1-2: new high speed USB device using ehci_hcd and address 10 usb 1-2: configuration #1 chosen from 1 choice scsi6 : SCSI emulation for USB Mass Storage devices usb 1-2: new device found, idVendor=13fe, idProduct=1a00 usb 1-2: new device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-2: Product: GEIL USB DISK usb 1-2: Manufacturer: usb-storage: device found at 10 usb-storage: waiting for device to settle before scanning schedule_timeout: wrong timeout value c1a95554 [c010456a] show_trace_log_lvl+0x1a/0x30 [c010508d] show_trace+0x12/0x14 [c01051e0] dump_stack+0x15/0x17 [c04174d1] schedule_timeout+0x8c/0xa2 [c032aeec] usb_stor_scan_thread+0x100/0x160 [c0127f2e] kthread+0x36/0x58 [c0104233] kernel_thread_helper+0x7/0x14 === scsi 6:0:0:0: Direct-Access GEIL USB DISK2.0 PQ: 0 ANSI: 0 CCS sd 6:0:0:0: [sda] 1007616 512-byte hardware sectors (516 MB) sd 6:0:0:0: [sda] Write Protect is off sd 6:0:0:0: [sda] Mode Sense: 23 00 00 00 sd 6:0:0:0: [sda] Assuming drive cache: write through sd 6:0:0:0: [sda] 1007616 512-byte hardware sectors (516 MB) sd 6:0:0:0: [sda] Write Protect is off sd 6:0:0:0: [sda] Mode Sense: 23 00 00 00 sd 6:0:0:0: [sda] Assuming drive cache: write through sda: sda1 sd 6:0:0:0: [sda] Attached SCSI removable disk sd 6:0:0:0: Attached scsi generic sg0 type 0 usb-storage: device scan complete This is a known problem. See http://marc.info/?l=linux-kernelm=118641424414399w=2 Rafael, has this been fixed yet? Alan Stern - 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] msleep() with hrtimers
On Thu, 9 Aug 2007, Andrew Morton wrote: This failed the Vaio test. I guess it triggered a USB bug. With this patch applied, when I hotplug my wireless mouse, the little LED on the mouse comes on for a second or so then goes out and no pointy clicky for me. It says: [ 152.481522] usb 1-1: new low speed USB device using uhci_hcd and address 2 Without this patch applied, I get [ 195.935445] usb 2-1: new low speed USB device using uhci_hcd and address 2 [ 196.116183] usb 2-1: configuration #1 chosen from 1 choice [ 196.198362] input: Microsoft Microsoft Wireless Optical Mouse 1.00 as /class/input/input7 [ 196.223724] input: USB HID v1.11 Mouse [Microsoft Microsoft Wireless Optical Mouse 1.00] on usb-:00:1d.1-1 [ 196.224570] usb 2-1: new device found, idVendor=045e, idProduct=00e1 [ 196.224579] usb 2-1: new device strings: Mfr=1, Product=2, SerialNumber=0 [ 196.224585] usb 2-1: Product: Microsoft Wireless Optical Mouse 1.00 [ 196.224590] usb 2-1: Manufacturer: Microsoft and lots of pointy clickiness. I would assume that there is some msleep() in USB which is too short, and the present wild rounding-up which msleep() does covered up the incorrectly-chosen sleep duration. I'm using HZ=250 (http://userweb.kernel.org/~akpm/config-sony.txt) and it could well be that the mouse would fail just by going to HZ=1000, but I didn't bother testing that. Could one of the USB developers please suggest which msleep()(s) I should start looking at? It could be one of the calls in drivers/usb/core/hub.c, however almost all of them are at least 10 ms already. There's a 0-ms msleep near the start of hub_port_wait_reset() which might cause problems. It will be easier to pin down the culprit if you turn on CONFIG_USB_DEBUG. Alan Stern - 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] OHCI suspend/resume issue.
On Thu, 9 Aug 2007, Zephaniah E. Hull wrote:
OHCI isn't coming back on the OLPC after resume.
After a bit of testing, the problem seems to have come down to two points.
The first is that ohci_pci_resume is not forcing the root hub to be resumed
properly, that's a fairly trivial and obviously correct patch.
Can you be more specific? What exactly goes wrong?
Note that ohci_pci_resume() isn't _supposed_ to force the root hub to
be resumed. ohci_rh_resume() runs at a later time, after
ohci_pci_resume().
It would be appropriate to detect loss of VBUS power in
ohci_pci_resume() and set the controller's state accordingly, as the
comment in that routine indicates. But I don't know the best way of
doing so.
The second is trickier, ohci_rh_resume is getting called in a state that it
thinks is an indication that it's coming back from a SUSPEND where it did not
lose power.
You mean ohci-regs-control doesn't contain OHCI_USB_RESET in the
appropriate bits? What does it contain? And why?
I've patched it, and hopefully there won't be any false positives, but I don't
have another machine to do suspend/resume testing on, so while it works for
me,
I can't guarantee that it won't cause problems for others.
In any case, USB 1.1 devices directly plugged into the machine didn't work
after resume before this, and do now.
Signed-off-by: Zephaniah E. Hull [EMAIL PROTECTED]
diff --git a/drivers/usb/host/ohci-hub.c b/drivers/usb/host/ohci-hub.c
index bb9cc59..3660dcc 100644
--- a/drivers/usb/host/ohci-hub.c
+++ b/drivers/usb/host/ohci-hub.c
@@ -165,6 +165,12 @@ static int ohci_rh_resume (struct ohci_hcd *ohci)
}
} else switch (ohci-hc_control OHCI_CTRL_HCFS) {
case OHCI_USB_SUSPEND:
+ /* FIXME: we should try to detect loss of VBUS better. */
+ if (!autostopped) {
+ ohci_dbg (ohci, resume root hub -- lost power\n);
+ status = -EBUSY;
+ break;
+ }
This is definitely not the right thing to do. We should be in the
default (reset) case, not here. The correct approach is to find out
why we aren't and fix it up.
And this certainly _will_ generate false positives on other machines.
ohci-hc_control = ~(OHCI_CTRL_HCFS|OHCI_SCHED_ENABLES);
ohci-hc_control |= OHCI_USB_RESUME;
ohci_writel (ohci, ohci-hc_control, ohci-regs-control);
diff --git a/drivers/usb/host/ohci-pci.c b/drivers/usb/host/ohci-pci.c
index 48de318..ae1ecb2 100644
--- a/drivers/usb/host/ohci-pci.c
+++ b/drivers/usb/host/ohci-pci.c
@@ -282,7 +282,9 @@ static int ohci_pci_resume (struct usb_hcd *hcd)
prepare_for_handover(hcd);
/* Force the PM core to resume the root hub */
- hcd_to_bus(hcd)-root_hub-dev.power.prev_state.event = PM_EVENT_ON;
+ usb_root_hub_lost_power(hcd-self.root_hub);
+
+ hcd-state = HC_STATE_SUSPENDED;
Again, the wrong thing to do. For one thing, there's no reason to call
usb_root_hub_lost_power() here since it will get called later on in
ohci_rh_resume(). For another, there's no reason to set hcd-state to
HC_STATE_SUSPENDED, since usb_hcd_pci_resume() in
drivers/usb/core/hcd-pci.c has already verified that it has that value.
return 0;
}
Alan Stern
-
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] OHCI suspend/resume issue.
On Thu, 9 Aug 2007, Zephaniah E. Hull wrote: I'll try to keep this making sense, but I'm going to have to reply to things slightly out of order. Thanks for the detailed reply. On Thu, Aug 09, 2007 at 11:27:02AM -0400, Alan Stern wrote: On Thu, 9 Aug 2007, Zephaniah E. Hull wrote: OHCI isn't coming back on the OLPC after resume. After a bit of testing, the problem seems to have come down to two points. The first is that ohci_pci_resume is not forcing the root hub to be resumed properly, that's a fairly trivial and obviously correct patch. Can you be more specific? What exactly goes wrong? The first problem is pretty noticeable, ohci_rh_resume never gets called. The chain roughly goes usb_resume_both - usb_resume_device - generic_resume (some indirection here) - hcd_bus_resume - ohci_rh_resume (some indirection here too). usb_resume_device has an interesting check, if udev-state != USB_STATE_SUSPENED or if udev-reset_resume is false, then it silently -^ That's an , not an ||. Unless somehow it got changed in your version of the code... decides not to pass things down the chain, without a failure. (Note that udev is usb_device, the joy of confusing naming.) This is quite possibly a bug, It certainly would be a bug if somebody changed it from and to or. Is that the cause of your problem? since a few lines down in the same function it checks for a quirk, USB_QUIRK_RESET_RESUME, and sets reset_resume to 1 if it's there. This code has no impact, since it's never reached if reset_resume isn't already 1. Go back and look at the routine again. Maybe you just misread the first test. The second is trickier, ohci_rh_resume is getting called in a state that it thinks is an indication that it's coming back from a SUSPEND where it did not lose power. You mean ohci-regs-control doesn't contain OHCI_USB_RESET in the appropriate bits? What does it contain? And why? ohci-hc_control OHCI_CTRL_HCFS == OHCI_USB_SUSPEND, and I honestly don't have the foggiest clue how or why it has that after coming back from the chip being powered off. My best guess is that somewhere else in the resume path we're resetting it, but that's only a guess and I have no idea why anything would do that. Nothing should. You might want to add a debugging printk to ohci_pci_resume() or prepare_for_handover() to see what the value is at the start of the resume. Maybe the firmware sets it incorrectly before the driver does anything. Infact, grepping through the source tree, the only thing setting OHCI_USB_SUSPEND is ohci_rh_suspend, which would have happened prior to turning off the device. My guess is that something is blindly restoring from ohci-hc_control without first reading in the value. Maybe, but nothing capable of doing that should get called before ohci_rh_resume(). Alan Stern - 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] disabling interrupts
On Thu, 9 Aug 2007, Gabriel Maganis wrote: Hello, Why is it that I can still succesfully execute a usb_control_msg() even if disable interrupts i.e. save_flags(flags); cli(); usb_control_msg(); restore_flags(flags); Is the usb subsystem checking for it and re-enabling interrupts somehow? No. But the scheduler does. Alan Stern - 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] OHCI suspend/resume issue.
On Thu, 9 Aug 2007, Zephaniah E. Hull wrote: Urgh, I definitely need some sleep, yes, it's a . Which, from the debugging statements from previous failed runs, we have something odder. reset_resume == 0, udev-state == USB_STATE_CONFIGURED. This is an even more bizarre state then I thought. After you get up :-), check udev-state at the end of usb_suspend_device(). It should be USB_STATE_SUSPENDED, and nothing should change it until usb_resume_device() runs. Are you maybe seeing ohci_rh_resume() get called twice in a row? Nothing should. You might want to add a debugging printk to ohci_pci_resume() or prepare_for_handover() to see what the value is at the start of the resume. Maybe the firmware sets it incorrectly before the driver does anything. Perhaps, we seem to have a lot of very odd state at the time that we try to resume the OHCI root hub. Agreed. Alan Stern - 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
[linux-usb-devel] Disable autosuspend for scanners/printers
Oliver and Pete: Is it possible to replace all those USB_QUIRK_NO_AUTOSUSPEND entries for scanners with a single class-wide entry? What about printers? Would a USB_QUIRK_RESET_RESUME entry suffice or do we really need NO_AUTOSUSPEND? If these devices really can't handle being suspended then it has to be prevented within the kernel; we can't rely on udev or other userspace programs to take care of it. But we could allow udev to enable autosuspend for known-good devices in these classes. Alan Stern - 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.23-rc1: USB hard disk broken
On Sunday 05 August 2007, David Brownell wrote: 2007-08-05_10:30:27.75572 kern.err: ehci_hcd :00:1d.7: dev 6 ep1in scatterlist error 0/-121 That's rather strange since it means a *success* (urb-status 0) was reported after a short read (scatterlist status -120, -EREMOTEIO). I'm baffled by that also. It should never happen. The hardware should have stopped queue processing after the short read, because of how qtd-hw_alt_next gets set up ... at least, that's how I remember it, these many years after writing that code. It might be that because of the issue noted below, it was wrongly restarted by the software. 2007-08-05_10:30:27.86576 kern.info: usb 1-6: reset high speed USB device using \ ehci_hcd and address 5 2007-08-05_10:30:55.95293 kern.info: usb 1-6: USB \ disconnect, address 5 2007-08-05_10:30:55.95300 kern.err: ehci_hcd :00:1d.7: dev 6 ep1in scatterlist error -108/-108 That one just means nobody updated that test to recognize that the -ESHUTDOWN (-108) triggered after disconnect is a clean failure like the ones triggered by unlinking. However it also indicates that something changed in the unlink code paths, since I see the *expected* code (-ECONNRESET) is no longer being set by usbcore during unlinks ... What do you mean? Normal async unlinks still use that error value. Look at the usb_unlink_urb() routine in core/urb.c. it's not quite clear to me what else that change will have broken. Including whether that might not explain how the hardware queue got wrongly restarted after the short read above. Could there have been a change in the unlink or completion code in ehci-hcd? Alan Stern - 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] send data on packet level
On Tue, 7 Aug 2007, Gabriel Maganis wrote: I see. So the most I have access to from software are on the transaction level like you described before i.e. a SETUP transaction which is actually a SETUP packet followed by a DATA packet then an ACK packet? And I can't even do so unless I hack the host controller drivers? Right. However you haven't given any reason for wanting to do even that much. For all reasonable purposes the usual URB-related functions are perfectly fine. What good is sending just a Setup transaction? The device will expect more to follow. Alan Stern - 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
[linux-usb-devel] [PATCH] USB: make HCDs responsible for managing endpoint queues
This patch (as954) implements a suggestion of David Brownell's. Now
the host controller drivers are responsible for linking and unlinking
URBs to/from their endpoint queues. This eliminates the possiblity of
strange situations where usbcore thinks an URB is linked but the HCD
thinks it isn't. It also means HCDs no longer have to check for URBs
being dequeued before they were fully enqueued.
In addition to the core changes, this requires changing every host
controller driver and the root-hub URB handler. For the most part the
required changes are fairly small; drivers have to call
usb_hcd_link_urb_to_ep() in their urb_enqueue method,
usb_hcd_check_unlink_urb() in their urb_dequeue method, and
usb_hcd_unlink_urb_from_ep() before giving URBs back. A few HCDs make
matters more complicated by the way they split up the flow of control.
In addition some method interfaces get changed. The endpoint argument
for urb_enqueue is now redundant so it is removed. The unlink status
is required by usb_hcd_check_unlink_urb(), so it has been added to
urb_dequeue.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
CC: David Brownell [EMAIL PROTECTED]
CC: Olav Kongas [EMAIL PROTECTED]
CC: Tony Olech [EMAIL PROTECTED]
CC: Yoshihiro Shimoda [EMAIL PROTECTED]
---
Olav, Tony, and Yoshihiro:
Please test the changes to your respective drivers. I don't have the
necessary hardware.
Alan Stern
Index: usb-2.6/drivers/usb/core/hcd.h
===
--- usb-2.6.orig/drivers/usb/core/hcd.h
+++ usb-2.6/drivers/usb/core/hcd.h
@@ -189,11 +189,10 @@ struct hc_driver {
int (*get_frame_number) (struct usb_hcd *hcd);
/* manage i/o requests, device state */
- int (*urb_enqueue) (struct usb_hcd *hcd,
- struct usb_host_endpoint *ep,
- struct urb *urb,
- gfp_t mem_flags);
- int (*urb_dequeue) (struct usb_hcd *hcd, struct urb *urb);
+ int (*urb_enqueue)(struct usb_hcd *hcd,
+ struct urb *urb, gfp_t mem_flags);
+ int (*urb_dequeue)(struct usb_hcd *hcd,
+ struct urb *urb, int status);
/* hw synch, freeing endpoint resources that urb_dequeue can't */
void(*endpoint_disable)(struct usb_hcd *hcd,
@@ -211,6 +210,11 @@ struct hc_driver {
/* Needed only if port-change IRQs are level-triggered */
};
+extern int usb_hcd_link_urb_to_ep(struct usb_hcd *hcd, struct urb *urb);
+extern int usb_hcd_check_unlink_urb(struct usb_hcd *hcd, struct urb *urb,
+ int status);
+extern void usb_hcd_unlink_urb_from_ep(struct usb_hcd *hcd, struct urb *urb);
+
extern int usb_hcd_submit_urb (struct urb *urb, gfp_t mem_flags);
extern int usb_hcd_unlink_urb (struct urb *urb, int status);
extern void usb_hcd_giveback_urb (struct usb_hcd *hcd, struct urb *urb);
Index: usb-2.6/drivers/usb/core/hcd.c
===
--- usb-2.6.orig/drivers/usb/core/hcd.c
+++ usb-2.6/drivers/usb/core/hcd.c
@@ -356,11 +356,17 @@ static int rh_call_control (struct usb_h
const u8*bufp = tbuf;
int len = 0;
int patch_wakeup = 0;
- int status = 0;
+ int status;
int n;
might_sleep();
+ spin_lock_irq(hcd_root_hub_lock);
+ status = usb_hcd_link_urb_to_ep(hcd, urb);
+ spin_unlock_irq(hcd_root_hub_lock);
+ if (status)
+ return status;
+
cmd = (struct usb_ctrlrequest *) urb-setup_packet;
typeReq = (cmd-bRequestType 8) | cmd-bRequest;
wValue = le16_to_cpu (cmd-wValue);
@@ -525,10 +531,9 @@ error:
/* any errors get returned through the urb completion */
spin_lock_irq(hcd_root_hub_lock);
- spin_lock(urb-lock);
if (urb-status == -EINPROGRESS)
urb-status = status;
- spin_unlock(urb-lock);
+ usb_hcd_unlink_urb_from_ep(hcd, urb);
/* This peculiar use of spinlocks echoes what real HC drivers do.
* Avoiding calls to local_irq_disable/enable makes the code
@@ -571,26 +576,21 @@ void usb_hcd_poll_rh_status(struct usb_h
spin_lock_irqsave(hcd_root_hub_lock, flags);
urb = hcd-status_urb;
if (urb) {
- spin_lock(urb-lock);
- if (urb-status == -EINPROGRESS) {
- hcd-poll_pending = 0;
- hcd-status_urb = NULL;
- urb-status = 0;
- urb-hcpriv = NULL;
- urb-actual_length = length;
- memcpy(urb-transfer_buffer, buffer, length);
- } else /* urb has been unlinked
[linux-usb-devel] [PATCH] USB: don't touch sysfs stuff when altsetting is unchanged
This patch (as955) prevents the interface-related sysfs files and endpoint pseudo-devices from being deleted and recreated when a call to usb_set_interface() specifies the current altsetting. Since the altsetting doesn't get changed, there's no need to do anything. Furthermore, avoiding changes to the endpoint devices will be necessary in the future. This code is called from usb_reset_device(), which gets invoked for reset-resume processing, but upcoming changes to the PM and driver cores will make it impossible to register devices while a suspend/resume transition is in progress. Since we don't need to re-register those endpoint devices anyhow, it's best to skip the whole thing. Signed-off-by: Alan Stern [EMAIL PROTECTED] --- Index: usb-2.6/drivers/usb/core/message.c === --- usb-2.6.orig/drivers/usb/core/message.c +++ usb-2.6/drivers/usb/core/message.c @@ -1173,6 +1173,7 @@ int usb_set_interface(struct usb_device struct usb_host_interface *alt; int ret; int manual = 0; + int changed; if (dev-state == USB_STATE_SUSPENDED) return -EHOSTUNREACH; @@ -1212,7 +1213,8 @@ int usb_set_interface(struct usb_device */ /* prevent submissions using previous endpoint settings */ - if (device_is_registered(iface-dev)) + changed = (iface-cur_altsetting != alt); + if (changed device_is_registered(iface-dev)) usb_remove_sysfs_intf_files(iface); usb_disable_interface(dev, iface); @@ -1249,7 +1251,7 @@ int usb_set_interface(struct usb_device * (Likewise, EP0 never halts on well designed devices.) */ usb_enable_interface(dev, iface); - if (device_is_registered(iface-dev)) + if (changed device_is_registered(iface-dev)) usb_create_sysfs_intf_files(iface); return 0; - 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] USB: don't touch sysfs stuff when altsetting is unchanged
On Wed, 8 Aug 2007, Greg KH wrote: On Wed, Aug 08, 2007 at 11:59:18AM -0400, Alan Stern wrote: This patch (as955) prevents the interface-related sysfs files and endpoint pseudo-devices from being deleted and recreated when a call to usb_set_interface() specifies the current altsetting. Since the altsetting doesn't get changed, there's no need to do anything. Is this something that should go into 2.6.23? It's not necessary for 2.6.23. The PM core isn't going to change overnight. :-) Alan Stern - 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] [3/3] 2.6.23-rc2: known regressions v2
On Wed, 8 Aug 2007, Michal Piotrowski wrote: USB Subject : 2.6.23-rc1: uhci_hcd. irq 4: nobody cared References : http://lkml.org/lkml/2007/7/29/75 Last known good : ? Submitter : Mark Hindley [EMAIL PROTECTED] Caused-By : ? Handled-By : Alan Stern [EMAIL PROTECTED] Status : unknown Mark has determined that this is not a regression but rather an already-existing problem, caused by invoking kexec from within an xterm window. See http://marc.info/?l=linux-usb-usersm=118648557203179w=2 Of course, this means there's liable to be something wrong with the way kexec interacts with uhci-hcd or the other drivers sharing the same IRQ. Failure to call the shutdown() method could cause the problem. But I don't see why using an xterm should make any difference (unless the only device being used was a mouse, and it was not in use while X wasn't running). Alan Stern - 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
[linux-usb-devel] [PATCH] USB: cleanups for g_file_storage
This patch (as957) makes some minor cleanups to the g_file_storage
driver:
Update the copyright date and version string;
Uniformize the logging macros for the gadget and the LUNs;
Remove inline markers -- nowadays we rely on the compiler
to decide which routines are best inlined;
Use the print_hex_dump() library routines;
Remove some unnecessary assignments within conditionals
and fix some close-brace indenting levels;
Fix some column-80 violations.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Note that without the hex_dump patch adding const qualifiers (posted
on LKML a few minutes ago), this will generate compiler warnings. But
it will work okay.
Index: usb-2.6/drivers/usb/gadget/file_storage.c
===
--- usb-2.6.orig/drivers/usb/gadget/file_storage.c
+++ usb-2.6/drivers/usb/gadget/file_storage.c
@@ -1,7 +1,7 @@
/*
* file_storage.c -- File-backed USB Storage Gadget, for USB development
*
- * Copyright (C) 2003-2005 Alan Stern
+ * Copyright (C) 2003-2007 Alan Stern
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -218,7 +218,7 @@
/* #define VERBOSE_DEBUG */
-#undef DUMP_MSGS
+/* #define DUMP_MSGS */
#include linux/blkdev.h
@@ -249,7 +249,7 @@
#define DRIVER_DESCFile-backed Storage Gadget
#define DRIVER_NAMEg_file_storage
-#define DRIVER_VERSION 28 November 2005
+#define DRIVER_VERSION 7 August 2007
static const char longname[] = DRIVER_DESC;
static const char shortname[] = DRIVER_NAME;
@@ -275,12 +275,9 @@ MODULE_LICENSE(Dual BSD/GPL);
/*-*/
-#define yprintk(l,level,fmt,args...) \
- dev_printk(level , (l)-dev , fmt , ## args)
-
#ifdef DEBUG
#define LDBG(lun,fmt,args...) \
- yprintk(lun , KERN_DEBUG , fmt , ## args)
+ dev_dbg((lun)-dev , fmt , ## args)
#define MDBG(fmt,args...) \
printk(KERN_DEBUG DRIVER_NAME : fmt , ## args)
#else
@@ -300,11 +297,11 @@ MODULE_LICENSE(Dual BSD/GPL);
#endif /* VERBOSE_DEBUG */
#define LERROR(lun,fmt,args...) \
- yprintk(lun , KERN_ERR , fmt , ## args)
+ dev_err((lun)-dev , fmt , ## args)
#define LWARN(lun,fmt,args...) \
- yprintk(lun , KERN_WARNING , fmt , ## args)
+ dev_warn((lun)-dev , fmt , ## args)
#define LINFO(lun,fmt,args...) \
- yprintk(lun , KERN_INFO , fmt , ## args)
+ dev_info((lun)-dev , fmt , ## args)
#define MINFO(fmt,args...) \
printk(KERN_INFO DRIVER_NAME : fmt , ## args)
@@ -558,7 +555,7 @@ struct lun {
#define backing_file_is_open(curlun) ((curlun)-filp != NULL)
-static inline struct lun *dev_to_lun(struct device *dev)
+static struct lun *dev_to_lun(struct device *dev)
{
return container_of(dev, struct lun, dev);
}
@@ -692,13 +689,13 @@ struct fsg_dev {
typedef void (*fsg_routine_t)(struct fsg_dev *);
-static int inline exception_in_progress(struct fsg_dev *fsg)
+static int exception_in_progress(struct fsg_dev *fsg)
{
return (fsg-state FSG_STATE_IDLE);
}
/* Make bulk-out requests be divisible by the maxpacket size */
-static void inline set_bulk_out_req_length(struct fsg_dev *fsg,
+static void set_bulk_out_req_length(struct fsg_dev *fsg,
struct fsg_buffhd *bh, unsigned int length)
{
unsigned intrem;
@@ -724,50 +721,36 @@ static void close_all_backing_files(stru
static void dump_msg(struct fsg_dev *fsg, const char *label,
const u8 *buf, unsigned int length)
{
- unsigned intstart, num, i;
- charline[52], *p;
-
- if (length = 512)
- return;
- DBG(fsg, %s, length %u:\n, label, length);
-
- start = 0;
- while (length 0) {
- num = min(length, 16u);
- p = line;
- for (i = 0; i num; ++i) {
- if (i == 8)
- *p++ = ' ';
- sprintf(p, %02x, buf[i]);
- p += 3;
- }
- *p = 0;
- printk(KERN_DEBUG %6x: %s\n, start, line);
- buf += num;
- start += num;
- length -= num;
+ if (length 512) {
+ DBG(fsg, %s, length %u:\n, label, length);
+ print_hex_dump(KERN_DEBUG, , DUMP_PREFIX_OFFSET,
+ 16, 1, buf, length, 0);
}
}
-static void inline dump_cdb(struct fsg_dev *fsg)
+static void dump_cdb(struct fsg_dev *fsg)
{}
#else
-static void inline dump_msg(struct fsg_dev *fsg, const char *label,
+static void dump_msg(struct fsg_dev *fsg, const char *label,
const u8 *buf, unsigned int length)
{}
-static void inline dump_cdb(struct fsg_dev *fsg)
-{
- int i;
- charcmdbuf[3
[linux-usb-devel] [PATCH] USB: remove DEBUG definition from dummy_hcd
This patch (as958) removes an unneeded and unwanted #define line from dummy_hcd. Signed-off-by: Alan Stern [EMAIL PROTECTED] --- It would be nice to see this in 2.6.23. Index: usb-2.6/drivers/usb/gadget/dummy_hcd.c === --- usb-2.6.orig/drivers/usb/gadget/dummy_hcd.c +++ usb-2.6/drivers/usb/gadget/dummy_hcd.c @@ -34,8 +34,6 @@ * bypassing some hardware (and driver) issues. UML could help too. */ -#define DEBUG - #include linux/module.h #include linux/kernel.h #include linux/delay.h - 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] send data on packet level
On Wed, 8 Aug 2007, Gabriel Maganis wrote: Correct. I was hoping disabling preemption can keep those things somewhat constant but looking at the list you gave, it seems the time to travel over the cable is negligible. I am trying to see if a USB extension cable can increase the time from my computer to the device. Is that unlikely to be visible from a kernel module even if I use the TSC? No, it's not going to be visible at all. You might be able to see it with an oscilloscope or bus analyzer. IIRC the propagation speed of these signals is about 1/3 the speed of light, or roughly 10 ns per meter. In theory this is within the resolution of the TSC, but with all the other confounding factors you'd never be able to dig it out. Alan Stern - 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] send data on packet level
On Mon, 6 Aug 2007, Gabriel Maganis wrote: Hello, How could one communicate with usb devices on the packet level i.e. chapter 8 of the usb spec instead of the device requests in chapter 9? I'd like to be able to send SETUP packets or DATA0 packets and get the ACK coming from the devices versus a GET_DESCRIPTOR request over the control pipe thru usb_control_msg. It depends on what you mean. Individual packets in USB don't form a complete communication; not much below the level of a transaction is meaningful. If that's good enough for you (a Setup transaction followed by an IN or OUT transaction for instance), you can do it by hacking the host controller drivers. If you really want control at the level of single packets, you will have to build your own hardware. Normal host controllers don't provide that capability. But why would you want to do this? What's wrong with the existing facilities? I don't see any point in, say, just sending a SETUP packet. You won't know whether the device has processed it without going through the remainder of the control transfer (data stage and status stage). And if you're going to go through all that anyway, then why not let the existing drivers take care of the details for you? Alan Stern - 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] USB BIOS early handoff only when the we the driver is configured
On Tue, 7 Aug 2007, David Engraf wrote: You said your Intel board has also problems with the handoff. Could you try the follwing patch, because the EHCI documentation says that the OS must set the EHCI_USBLEGSUP_OS bit and then wait until EHCI_USBLEGSUP_BIOS is cleared. The kernel never uses the EHCI_USBLEGSUP_OS flag at the moment. Yes it does. Maybe not by that name, but it does set the bit. On my system there is no change, but maybe this patch works on your system. Thanks David Engraf linux-2.6.22.1 diff -puN drivers/usb/host/pci-quirks_orig.c drivers/usb/host/pci-quirks.c --- drivers/usb/host/pci-quirks_orig.c2007-07-10 20:56:30.0 +0200 +++ drivers/usb/host/pci-quirks.c2007-08-07 10:38:33.0 +0200 @@ -268,6 +268,8 @@ static void __devinit quirk_usb_disable_ * handoff.. */ pci_write_config_byte(pdev, offset + 3, 1); + +pci_write_config_byte(pdev, offset, cap | EHCI_USBLEGSUP_OS); This patch is definitely wrong (besides being line-wrapped). Note that EHCI_USBLEGSUP_OS is equal to (1 24) -- it makes no sense to use it as an argument for a byte-sized write. Also note that the two low-order bytes in the USBLEGSUP register are read-only; you shouldn't try to write them at all. It looks like you are simply attempting to do what the previous line of code already does. Alan Stern - 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] Reseting USB HCD
On Tue, 7 Aug 2007, Felipe Balbi wrote: Hello all, Is there a way of reseting USB HCD from userspace without removing the kernel module? No. I can see there's a method for reseting the controller (ehci_reset in my case) but it's called only when the device is first probed or as an error recovery method, am I right? Not quite. It isn't used for error recovery; when an error occurs it is called to insure the controller is quiescent. The driver doesn't really try to recover from errors. What's wrong with removing the kernel module to reset the driver? Alan Stern - 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] send data on packet level
On Tue, 7 Aug 2007, Gabriel Maganis wrote: On 8/7/07, Alan Stern [EMAIL PROTECTED] wrote: On Mon, 6 Aug 2007, Gabriel Maganis wrote: Hello, How could one communicate with usb devices on the packet level i.e. chapter 8 of the usb spec instead of the device requests in chapter 9? I'd like to be able to send SETUP packets or DATA0 packets and get the ACK coming from the devices versus a GET_DESCRIPTOR request over the control pipe thru usb_control_msg. It depends on what you mean. Individual packets in USB don't form a complete communication; not much below the level of a transaction is meaningful. If that's good enough for you (a Setup transaction followed by an IN or OUT transaction for instance), you can do it by hacking the host controller drivers. If you really want control at the level of single packets, you will have to build your own hardware. Normal host controllers don't provide that capability. But why would you want to do this? What's wrong with the existing facilities? I don't see any point in, say, just sending a SETUP packet. You won't know whether the device has processed it without going through the remainder of the control transfer (data stage and status stage). And if you're going to go through all that anyway, then why not let the existing drivers take care of the details for you? Alan Stern Hello Alan, My goal is to be able to examine the fields they talk about in chapter 8 of the usb spec like the SYNC field and such. Is there a way to look at those from a usb_control_msg? or, at leat usb_submit_urb? [Please use Reply-to-All.] Not only is there no way to look at the SYNC and related fields from usb_control_msg() or usb_submit_urb() -- there is no way to look at them in software at all! The hardware strips those fields out before storing the data in the computer's memory. If you have an oscilloscope or USB bus analyzer, you can monitor the USB data lines and see the fields directly. Otherwise it's impossible. Alan Stern - 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.23-rc1-mm2 + cpufreq patch + hot-fixes -- [f8ea528f] usb_stor_scan_thread+0xbd/0x15a [usb_storage]
On Sat, 4 Aug 2007, Miles Lane wrote: Initializing USB Mass Storage driver... usb-storage 4-3:1.0: usb_probe_interface usb-storage 4-3:1.0: usb_probe_interface - got id scsi2 : SCSI emulation for USB Mass Storage devices usbcore: registered new interface driver usb-storage usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning schedule_timeout: wrong timeout value f8ea51d2 [c01080ab] show_trace_log_lvl+0x12/0x25 [c0108a9e] show_trace+0xd/0x10 [c0108bac] dump_stack+0x16/0x18 [c031e31e] schedule_timeout+0x2c/0x8b [f8ea528f] usb_stor_scan_thread+0xbd/0x15a [usb_storage] [c0139d64] kthread+0x3b/0x63 [c0107c63] kernel_thread_helper+0x7/0x10 === Does this happen repeatably? Did you set usb-storage's delay_use parameter to something peculiar? Alan Stern - 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 1/7] wusb: teach choose_address() about wireless devices
On Fri, 3 Aug 2007, Inaky Perez-Gonzalez wrote:
+/*
+ * WUSB devices are simple: they have no hubs behind, so the mapping
+ * device - virtual port number becomes 1:1. Why? to simplify the
+ * life of the device connection logic in
+ * drivers/usb/wusbcore/devconnect.c. When we do the initial secret
+ * handshake we need to assign a temporary address in the unauthorized
+ * space. For simplicity we use the first virtual port number found to
+ * be free [drivers/usb/wusbcore/devconnect.c:wusbhc_devconnect_ack()]
+ * and that becomes it's address [X 128] or its unauthorized address
+ * [X | 0x80].
+ *
+ * We add 2 as an offset for two reasons: (1) dev addr 0 is reserved
+ * by USB for default address; (2) Linux's USB stack uses always #1 for
+ * the root hub of the controller. So port 0 has address #2.
This comment is a little confusing since the code really adds 1, not 2:
+ if (udev-wusb) {
+ devnum = udev-portnum + 1;
See? Besides, the USB specs I've run across define port numbers
starting at 1, not 0. Maybe the WUSB spec is different.
Alan Stern
-
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 3/7] usb: add usb_dev_reset_delayed
On Fri, 3 Aug 2007, Inaky Perez-Gonzalez wrote:
+static
+void usb_dev_reset_delayed_task(struct work_struct *ws)
+{
+ struct usb_dev_reset_ctx *reset_ctx =
+ container_of(ws, struct usb_dev_reset_ctx, ws);
+ struct usb_device *usb_dev = reset_ctx-usb_dev;
+ struct device *dev = usb_dev-dev;
+ int had_to_lock;
+ int result = 0;
+
+ if (usb_dev == NULL) {
+ WARN_ON(1);
+ goto release;
+ }
This can never happen; there's no reason to test for it.
+void usb_dev_reset_delayed(struct usb_device *usb_dev)
+{
+ struct usb_dev_reset_ctx *reset_ctx;
+ struct device *dev = usb_dev-dev;
+ reset_ctx = kmalloc(sizeof(*reset_ctx), GFP_ATOMIC);
+ if (reset_ctx == NULL) {
+ if (printk_ratelimit())
+ dev_err(dev, USB: cannot allocate memory for
+ delayed device reset\n);
+ return;
+ }
+ if (try_module_get(THIS_MODULE) == 0)
+ goto error_module_get;
+ usb_get_dev(usb_dev);
+ if (usb_dev-delayed_reset)
+ goto error_pending;
+ usb_dev-delayed_reset = 1;
+ reset_ctx-usb_dev = usb_dev;
+ INIT_WORK(reset_ctx-ws, usb_dev_reset_delayed_task);
+ schedule_work(reset_ctx-ws);
+ return;
+
+error_pending:
+ usb_put_dev(usb_dev);
You forgot to call module_put().
+error_module_get:
+ kfree(reset_ctx);
+ return;
+}
+EXPORT_SYMBOL_GPL(usb_dev_reset_delayed);
Alan Stern
-
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] USB BIOS early handoff only when the we the driver is configured
On Fri, 3 Aug 2007, David Engraf wrote: So we have hardware which has problems when we are not doing the handoff, and hardware which has problems when we are doing the handoff... What hardware has problems when we do the handoff? Your system and mine experience a delay, but it doesn't break anything. What is the best way to solve the problem? Maybe a kernel parameter, a config flag or an automatic hardware dependent check of the system? In fact it is hard to find a solution which works for both as long as the hardware has this bugs. If we really need it, I say we should use a Kconfig flag. Alan Stern - 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] ehci problem triggerable by storage
On Fri, 3 Aug 2007, Oliver Neukum wrote: Well, I've thought a bit about this. I know a hub is to blame. Even if I did learn what causes this specific error, it wouldn't help in the other cases. These sorts of problems tend to be _very_ hardware dependent. That very same hub might work perfectly with someone else's computer or with a different USB drive. IMHO improving error handling is better than avoiding this fault. You mean error recovery. It's not clear that we _can_ do anything other than what we are doing. Longer recovery delays, perhaps. Maybe we need to reset the hub instead of the storage device. But that is an unpleasant solution, especially if other devices are plugged into the hub. Do you have any other ideas? Alan Stern - 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] USB: Only enable autosuspend by default on certain device classes
On Fri, 3 Aug 2007, Matthew Garrett wrote: Windows will autosuspend hubs, bluetooth devices, HID devices and CDC devices, so I think we're safe suspending those by default. And we know that we're not safe suspending scanners and many printers by default. But that leaves plenty of other device classes unaccounted for. I'm not so enthusiastic about the Increase the timeout case - it doesn't avoid any races, just makes them less likely. USB is likely to get loaded in the initramfs, but we may not have a full set of udev rules until the root fs is up and that can take an effectively arbitrarily large amount of time. If it takes longer than 15 minutes, something is wrong. At that point the user will have worse things to worry about than whether some USB devices got suspended. And 15 minutes is a perfectly reasonable autosuspend timeout for devices that might be plugged in all day long. Alan Stern - 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] USB: Only enable autosuspend by default on certain device classes
On Fri, 3 Aug 2007, Matthew Garrett wrote: This patch is exactly that - a way of getting most of the benefits of autosuspend without any real probability of breaking hardware. If you mean Are the distributions willing to pop up dialogs asking users to start caring about obscure aspects of the USB spec, then I don't think that's actually making things better. Quite aside from issues involving desktop ease-of-use and distribution intentions, there is a technical matter to consider. With the default autosuspend timeout set to 2 seconds, as it is now, it can often happen that userspace isn't able to respond in time to prevent a device from being suspended. At bootup especially, the system is so busy running lots of tasks that response to a newly-detected device can be delayed for tens of seconds. Even loading the device driver's module can take so long that the device gets autosuspended first. There are two possible solutions, both involving the kernel (since userspace can't respond in time). One is to change the default timeout to something larger, or even disable it completely. Then people would need to rely on userspace tools to enable autosuspend on known-good devices. The other possibility is to have a fairly reliable blacklist or whitelist and again rely on userspace to manage edge cases. This is of course more flexible than a blanket default setting, but it's still pretty rigid. On the other hand, a blacklist can't be changed without rebuilding the kernel whereas the default timeout can be adjusted on the boot command line. I don't know what the best approach is, but I can't see any alternative to these two. Furthermore, whatever approach we settle on _has_ to be able to handle devices which simply die upon being suspended. Alan Stern - 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] USB: Only enable a utosuspend by default on certain device classes
On Fri, 3 Aug 2007, Jiri Kosina wrote: What I have been seeing with both these keyboards was: if connected to UHCI controller, root hub not auto-suspended, as soon as they got autosuspended, and keys were pressed on them rapidly, very often some keypressess got lost. I didn't experience this on OHCI, but I remember Alan saying that he triggered it on OHCI too, right? Seemed like a timing issue - by lowering the polling timeout we were able to make things much better, but that of course costs us more power etc. and it's even not sure if it is an ultimate solution. Jiri and I ran a few tests at OLS, and we each did additional testing on our own. We looked at a small selection of keyboards; the ones I tested were by Apple and HP. Some keyboards had embedded hubs and others didn't. Some of our testing was with the keyboard behind an external hub. Sometimes only the keyboard controller was suspended, sometimes the controller and the embedded hub were, sometimes the external hub and everything downstream of it were, and sometimes the root hub was. We tested with both UHCI and OHCI -- I may even have done some tests with EHCI and a high-speed hub, I don't remember now. The end result was that some scenarios worked more reliably than others. There were lots of variables and it was hard to tie overall behavior with system settings. It did seem that in situations where the topmost suspended device was plugged into a UHCI root hub, increasing the the root hub's polling rate helped. But it didn't always help, and in any case we certainly don't want to change a kernel timer from 250 ms to 32 ms whenever a device is suspended! The bad behavior we observed, as Jiri described, was that rapid typing on a suspended keyboard would often cause one or more of the keystrokes to be lost. The probability of this happening varied with the circumstances, but I don't think I ever found a combination that was 100% reliable. It could well be a timing issue, or buffering -- there's no real way to know. An additional drawback to autosuspend for keyboards is the fact that the NumLock, CapsLock, etc. LEDs go out. We didn't test any mice (at least, I didn't). However it has been reported that while some suspended mice will send wakeup requests when they are moved, others won't. Certainly an optical mouse won't. All in all, it appears that the simplest and most user-friendly approach is just not to autosuspend keyboards and mice. Alan Stern - 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] USB: Only enable autosuspend by default on certain device classes
On Fri, 3 Aug 2007, Oliver Neukum wrote: Devices rarely simply crash. It's rare, but it does happen. I've seen a device get so messed up by suspend that it needed a reset; it wouldn't be surprising to find other devices requiring a power cycle. Alan Stern - 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] USB: Only enable autosuspend by default on certain device classes
On Fri, 3 Aug 2007, Dave Jones wrote: here's a head start for you. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243038 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246713 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243953 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242359 That's just the ones that were handy.. The last report appears to be related more to the EHCI-cpufreq problem, for which a patch was recently posted. Alan Stern - 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.23-rc1-mm2
On Thu, 2 Aug 2007, Mariusz Kozlowski wrote: === uhci_hcd :00:0c.0: dma_pool_free buffer-32, 6b6b6b6b/6b6b6b6b (bad dma) Mariusz, I guess the patch below (which I have just added to my tree) fixes that, right? Thanks. Yes - that's correct. This patch fixes the bug. Thanks. Does it also fix the dma_pool_free error? Alan Stern - 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] Can't unload uhci_hcd module with 2.6.22 -- also oops
On Wed, 1 Aug 2007, Alan Stern wrote:
Okay, good work. Thanks to your careful experiments, plus the hints
from Oliver and Tejun, I figured out the problem. In short, the
attribute files were registered on the control interface but the driver
tried to delete them from the data interface. I'll post a patch
tomorrow morning.
And here it is. You can remove the earlier diagnostic patches; this
one by itself should fix everything.
Alan Stern
Index: 2.6.22/drivers/usb/class/cdc-acm.c
===
--- 2.6.22.orig/drivers/usb/class/cdc-acm.c
+++ 2.6.22/drivers/usb/class/cdc-acm.c
@@ -919,6 +919,10 @@ skip_normal_probe:
return -EINVAL;
}
}
+
+ /* Accept probe requests only for the control interface */
+ if (intf != control_interface)
+ return -ENODEV;
if (usb_interface_claimed(data_interface)) { /* valid in this context */
dev_dbg(intf-dev,The data interface isn't available);
@@ -1107,10 +,12 @@ static void acm_disconnect(struct usb_in
return;
}
if (acm-country_codes){
- device_remove_file(intf-dev, dev_attr_wCountryCodes);
- device_remove_file(intf-dev, dev_attr_iCountryCodeRelDate);
+ device_remove_file(acm-control-dev,
+ dev_attr_wCountryCodes);
+ device_remove_file(acm-control-dev,
+ dev_attr_iCountryCodeRelDate);
}
- device_remove_file(intf-dev, dev_attr_bmCapabilities);
+ device_remove_file(acm-control-dev, dev_attr_bmCapabilities);
acm-dev = NULL;
usb_set_intfdata(acm-control, NULL);
usb_set_intfdata(acm-data, NULL);
-
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] USB BIOS early handoff only when the we the driver is configured
On Thu, 2 Aug 2007, David Engraf wrote: This would be solution too, but what if someone uses the uhci controller and don't want the ehci. So a single Kconfig flag wouldn't be enough, we have to add 3 flags for uchi, ohci and ehci. I think this maybe a little bit difficult when configuring the kernel. The best solution would be when we could use the CONFIG_USB__HCD flag, but it seems that some hardware has problems when we disable the handoff and let the BIOS control the usb controller. Do you know any of this hardware? The email messages are hidden in the depths of the linux-usb-devel archives. Maybe you can find them by checking the Git history for drivers/usb/host/pci-quirks.c, finding the dates for patches that affected the handoff code, and then searching through the archives near those dates. IIRC the problems arose on some MIPS machines. And I don't think the problem involved letting the firmware manage the USB controller; I think the problem came when the controller driver tried to do the handoff later on. Alan Stern - 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 2.6.23-rc1-git 5/6] file storage gadget cleanups
On Thu, 2 Aug 2007, David Brownell wrote: Clean up the file storage gadget, using newer APIs and conventions: - gadget_is_dualspeed() and gadget_is_otg() ... #ifdef removal - Remove many now-needless #includes - Use the DEBUG (from Kconfig+Makefile) and VERBOSE_DEBUG conventions. - Remove some sparse warnings (it still dislikes the __user annotations) This gave only a minor object code shrinkage. I'd rather expect to see a minor increase in object code size, since a few data structures and lines of code are now compiled in that previously would have been #ifdef'ed out. Why do you think the code size shrank? Signed-off-by: David Brownell [EMAIL PROTECTED] Cc: Alan Stern [EMAIL PROTECTED] --- drivers/usb/gadget/file_storage.c | 118 ++ 1 file changed, 45 insertions(+), 73 deletions(-) --- g26.orig/drivers/usb/gadget/file_storage.c2007-08-01 23:16:10.0 -0700 +++ g26/drivers/usb/gadget/file_storage.c 2007-08-01 23:29:00.0 -0700 @@ -289,57 +275,51 @@ MODULE_LICENSE(Dual BSD/GPL); /*-*/ -#define xprintk(f,level,fmt,args...) \ - dev_printk(level , (f)-gadget-dev , fmt , ## args) #define yprintk(l,level,fmt,args...) \ dev_printk(level , (l)-dev , fmt , ## args) Is there any particular reason you expanded xprintk inline but not yprintk? Despite these questions, ACK. Alan Stern - 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
[linux-usb-devel] [PATCH] cdc-acm: fix sysfs attribute registration bug
This patch (as950) fixes a bug in the cdc-acm driver. It doesn't keep
track of which interface (control or data) the sysfs attributes get
registered for, and as a result, during disconnect it will sometimes
attempt to remove the attributes from the wrong interface. The
left-over attributes can cause a crash later on, particularly if the driver
module has been unloaded.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
CC: Oliver Neukum [EMAIL PROTECTED]
---
The same patch applies with a small offset to 2.6.22. Although the bug
has been present all along, only the recent changes to the sysfs
infrastructure have caused it to manifest.
Alan Stern
Index: usb-2.6/drivers/usb/class/cdc-acm.c
===
--- usb-2.6.orig/drivers/usb/class/cdc-acm.c
+++ usb-2.6/drivers/usb/class/cdc-acm.c
@@ -921,6 +921,10 @@ skip_normal_probe:
return -EINVAL;
}
}
+
+ /* Accept probe requests only for the control interface */
+ if (intf != control_interface)
+ return -ENODEV;
if (usb_interface_claimed(data_interface)) { /* valid in this context */
dev_dbg(intf-dev,The data interface isn't available);
@@ -1109,10 +1113,12 @@ static void acm_disconnect(struct usb_in
return;
}
if (acm-country_codes){
- device_remove_file(intf-dev, dev_attr_wCountryCodes);
- device_remove_file(intf-dev, dev_attr_iCountryCodeRelDate);
+ device_remove_file(acm-control-dev,
+ dev_attr_wCountryCodes);
+ device_remove_file(acm-control-dev,
+ dev_attr_iCountryCodeRelDate);
}
- device_remove_file(intf-dev, dev_attr_bmCapabilities);
+ device_remove_file(acm-control-dev, dev_attr_bmCapabilities);
acm-dev = NULL;
usb_set_intfdata(acm-control, NULL);
usb_set_intfdata(acm-data, NULL);
-
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
[linux-usb-devel] [PATCH 0/3] USB core URB handling updates
Greg: The following short patch series includes the following: Various cleanups suggested for the previous patches; Rework the spinlock usage in the root-hub URB code; Separate out endpoint queue management and transfer-buffer DMA mapping into their own subroutines. These are all relatively small changes, although that might not be evident from looking at the patch files. Still to come is a somewhat larger change, in which the new endpoint queue routines are called from the HCDs instead of from usbcore. I have the changes broken up by driver -- one for each HCD plus one for the core -- so they can be applied independently. The intermediate stages will compile (with warnings) but they won't run correctly. So what's the best way to submit that stuff? Since the individual patches all affect different files, it would be easy to concatenate them into a single large (not huge, about 50 KB) patch. Or would it be better to submit them as 9 smaller patches? Alan Stern P.S.: Pete, I see what you mean about simplifying usbmon. The part for accessing setup-packet DMA buffers could be removed completely. In addition there seems to be a fair amount of duplicated code, but perhaps you prefer to keep it that way because of the user interface requirements. - 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
[linux-usb-devel] [PATCH 1/3] USB: cleanup for previous patches
This patch (as951) cleans up a few loose ends from earlier patches.
Redundant checks for non-NULL urb-dev are removed, as are checks of
urb-dev-bus (which can never be NULL). Conversely, a check for
non-NULL urb-ep is added to the unlink paths.
A homegrown round-down-to-power-of-2 loop is simplified by using the
ilog2 routine. The comparison in usb_urb_dir_in() is made more
transparent.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Index: usb-2.6/drivers/usb/core/hcd.c
===
--- usb-2.6.orig/drivers/usb/core/hcd.c
+++ usb-2.6/drivers/usb/core/hcd.c
@@ -1141,11 +1141,6 @@ int usb_hcd_unlink_urb (struct urb *urb,
struct list_head*tmp;
int retval;
- if (!urb)
- return -EINVAL;
- if (!urb-dev || !urb-dev-bus)
- return -ENODEV;
-
/*
* we contend for urb-status with the hcd core,
* which changes it while returning the urb.
Index: usb-2.6/drivers/usb/core/urb.c
===
--- usb-2.6.orig/drivers/usb/core/urb.c
+++ usb-2.6/drivers/usb/core/urb.c
@@ -3,6 +3,7 @@
#include linux/bitops.h
#include linux/slab.h
#include linux/init.h
+#include linux/log2.h
#include linux/usb.h
#include linux/wait.h
#include hcd.h
@@ -441,10 +442,8 @@ int usb_submit_urb(struct urb *urb, gfp_
default:
return -EINVAL;
}
- /* power of two? */
- while (max urb-interval)
- max = 1;
- urb-interval = max;
+ /* Round down to a power of 2, no more than max */
+ urb-interval = min(max, 1 ilog2(urb-interval));
}
return usb_hcd_submit_urb(urb, mem_flags);
@@ -513,8 +512,10 @@ int usb_unlink_urb(struct urb *urb)
{
if (!urb)
return -EINVAL;
- if (!(urb-dev urb-dev-bus))
+ if (!urb-dev)
return -ENODEV;
+ if (!urb-ep)
+ return -EIDRM;
return usb_hcd_unlink_urb(urb, -ECONNRESET);
}
@@ -541,7 +542,7 @@ int usb_unlink_urb(struct urb *urb)
void usb_kill_urb(struct urb *urb)
{
might_sleep();
- if (!(urb urb-dev urb-dev-bus))
+ if (!(urb urb-dev urb-ep))
return;
spin_lock_irq(urb-lock);
++urb-reject;
Index: usb-2.6/include/linux/usb.h
===
--- usb-2.6.orig/include/linux/usb.h
+++ usb-2.6/include/linux/usb.h
@@ -1402,7 +1402,7 @@ extern int usb_wait_anchor_empty_timeout
*/
static inline int usb_urb_dir_in(struct urb *urb)
{
- return (urb-transfer_flags URB_DIR_MASK) != URB_DIR_OUT;
+ return (urb-transfer_flags URB_DIR_MASK) == URB_DIR_IN;
}
/**
-
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
[linux-usb-devel] [PATCH 2/3] USB: update spinlock usage for root-hub URBs
This patch (as952) adjusts the spinlock usage in the root-hub
emulation part of usbcore, to make it match more closely the pattern
used by regular host controller drivers. To wit: The private lock
(usb_hcd_root_hub_lock) is held throughout the important parts, and it
is dropped temporarily without re-enabling interrupts around the call
to usb_hcd_giveback_urb().
A nice side effect is that the code now avoids calling
local_irq_save(), thereby becoming more RT-friendly.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Index: usb-2.6/drivers/usb/core/hcd.c
===
--- usb-2.6.orig/drivers/usb/core/hcd.c
+++ usb-2.6/drivers/usb/core/hcd.c
@@ -356,10 +356,11 @@ static int rh_call_control (struct usb_h
const u8*bufp = tbuf;
int len = 0;
int patch_wakeup = 0;
- unsigned long flags;
int status = 0;
int n;
+ might_sleep();
+
cmd = (struct usb_ctrlrequest *) urb-setup_packet;
typeReq = (cmd-bRequestType 8) | cmd-bRequest;
wValue = le16_to_cpu (cmd-wValue);
@@ -523,13 +524,21 @@ error:
}
/* any errors get returned through the urb completion */
- local_irq_save (flags);
- spin_lock (urb-lock);
+ spin_lock_irq(hcd_root_hub_lock);
+ spin_lock(urb-lock);
if (urb-status == -EINPROGRESS)
urb-status = status;
- spin_unlock (urb-lock);
- usb_hcd_giveback_urb (hcd, urb);
- local_irq_restore (flags);
+ spin_unlock(urb-lock);
+
+ /* This peculiar use of spinlocks echoes what real HC drivers do.
+* Avoiding calls to local_irq_disable/enable makes the code
+* RT-friendly.
+*/
+ spin_unlock(hcd_root_hub_lock);
+ usb_hcd_giveback_urb(hcd, urb);
+ spin_lock(hcd_root_hub_lock);
+
+ spin_unlock_irq(hcd_root_hub_lock);
return 0;
}
@@ -559,8 +568,7 @@ void usb_hcd_poll_rh_status(struct usb_h
if (length 0) {
/* try to complete the status urb */
- local_irq_save (flags);
- spin_lock(hcd_root_hub_lock);
+ spin_lock_irqsave(hcd_root_hub_lock, flags);
urb = hcd-status_urb;
if (urb) {
spin_lock(urb-lock);
@@ -574,16 +582,16 @@ void usb_hcd_poll_rh_status(struct usb_h
} else /* urb has been unlinked */
length = 0;
spin_unlock(urb-lock);
+
+ spin_unlock(hcd_root_hub_lock);
+ usb_hcd_giveback_urb(hcd, urb);
+ spin_lock(hcd_root_hub_lock);
} else
length = 0;
- spin_unlock(hcd_root_hub_lock);
- /* local irqs are always blocked in completions */
- if (length 0)
- usb_hcd_giveback_urb (hcd, urb);
- else
+ if (length = 0)
hcd-poll_pending = 1;
- local_irq_restore (flags);
+ spin_unlock_irqrestore(hcd_root_hub_lock, flags);
}
/* The USB 2.0 spec says 256 ms. This is close enough and won't
@@ -651,25 +659,23 @@ static int usb_rh_urb_dequeue (struct us
{
unsigned long flags;
+ spin_lock_irqsave(hcd_root_hub_lock, flags);
if (usb_endpoint_num(urb-ep-desc) == 0) {/* Control URB */
; /* Do nothing */
} else {/* Status URB */
if (!hcd-uses_new_polling)
del_timer (hcd-rh_timer);
- local_irq_save (flags);
- spin_lock (hcd_root_hub_lock);
if (urb == hcd-status_urb) {
hcd-status_urb = NULL;
urb-hcpriv = NULL;
- } else
- urb = NULL; /* wasn't fully queued */
- spin_unlock (hcd_root_hub_lock);
- if (urb)
- usb_hcd_giveback_urb (hcd, urb);
- local_irq_restore (flags);
- }
+ spin_unlock(hcd_root_hub_lock);
+ usb_hcd_giveback_urb(hcd, urb);
+ spin_lock(hcd_root_hub_lock);
+ }
+ }
+ spin_unlock_irqrestore(hcd_root_hub_lock, flags);
return 0;
}
-
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
[linux-usb-devel] [PATCH 3/3] USB: separate out endpoint queue management and DMA mapping routines
This patch (as953) separates out three key portions from
usb_hcd_submit_urb(), usb_hcd_unlink_urb(), and usb_hcd_giveback_urb()
and puts them in separate functions of their own. In the next patch,
these functions will be called directly by host controller drivers
while holding their private spinlocks, which will remove the
possibility of some unpleasant races.
The code responsible for mapping and unmapping DMA buffers is also
placed into a couple of separate subroutines, for the sake of
cleanliness and consistency.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Index: usb-2.6/drivers/usb/core/hcd.c
===
--- usb-2.6.orig/drivers/usb/core/hcd.c
+++ usb-2.6/drivers/usb/core/hcd.c
@@ -981,99 +981,117 @@ EXPORT_SYMBOL (usb_calc_bus_time);
/*-*/
-static void urb_unlink(struct usb_hcd *hcd, struct urb *urb)
+static int usb_hcd_link_urb_to_ep(struct usb_hcd *hcd, struct urb *urb)
{
- unsigned long flags;
+ unsigned long flags;
+ int rc = 0;
- /* clear all state linking urb to this dev (and hcd) */
spin_lock_irqsave(hcd_urb_list_lock, flags);
- list_del_init (urb-urb_list);
- spin_unlock_irqrestore(hcd_urb_list_lock, flags);
- if (hcd-self.uses_dma !is_root_hub(urb-dev)) {
- if (usb_endpoint_xfer_control(urb-ep-desc)
-!(urb-transfer_flags URB_NO_SETUP_DMA_MAP))
- dma_unmap_single (hcd-self.controller, urb-setup_dma,
- sizeof (struct usb_ctrlrequest),
- DMA_TO_DEVICE);
- if (urb-transfer_buffer_length != 0
-!(urb-transfer_flags URB_NO_TRANSFER_DMA_MAP))
- dma_unmap_single (hcd-self.controller,
- urb-transfer_dma,
- urb-transfer_buffer_length,
- usb_urb_dir_in(urb)
- ? DMA_FROM_DEVICE
- : DMA_TO_DEVICE);
+ /* Check that the URB isn't being killed */
+ if (unlikely(urb-reject)) {
+ rc = -EPERM;
+ goto done;
}
-}
-/* may be called in any context with a valid urb-dev usecount
- * caller surrenders ownership of urb
- * expects usb_submit_urb() to have sanity checked and conditioned all
- * inputs in the urb
- */
-int usb_hcd_submit_urb (struct urb *urb, gfp_t mem_flags)
-{
- int status;
- struct usb_hcd *hcd = bus_to_hcd(urb-dev-bus);
- unsigned long flags;
-
- if (!hcd)
- return -ENODEV;
-
- usbmon_urb_submit(hcd-self, urb);
+ if (unlikely(!urb-ep-enabled)) {
+ rc = -ENOENT;
+ goto done;
+ }
/*
-* Atomically queue the urb, first to our records, then to the HCD.
-* Access to urb-status is controlled by urb-lock ... changes on
-* i/o completion (normal or fault) or unlinking.
+* Check the host controller's state and add the URB to the
+* endpoint's queue.
*/
-
- // FIXME: verify that quiescing hc works right (RH cleans up)
-
- spin_lock_irqsave(hcd_urb_list_lock, flags);
- if (unlikely(!urb-ep-enabled))
- status = -ENOENT;
- else if (unlikely (urb-reject))
- status = -EPERM;
- else switch (hcd-state) {
+ switch (hcd-state) {
case HC_STATE_RUNNING:
case HC_STATE_RESUMING:
- list_add_tail (urb-urb_list, urb-ep-urb_list);
- status = 0;
+ list_add_tail(urb-urb_list, urb-ep-urb_list);
break;
default:
- status = -ESHUTDOWN;
- break;
+ rc = -ESHUTDOWN;
+ goto done;
}
+ done:
spin_unlock_irqrestore(hcd_urb_list_lock, flags);
- if (status) {
- INIT_LIST_HEAD (urb-urb_list);
- usbmon_urb_submit_error(hcd-self, urb, status);
- return status;
- }
+ return rc;
+}
- /* increment urb's reference count as part of giving it to the HCD
-* (which now controls it). HCD guarantees that it either returns
-* an error or calls giveback(), but not both.
+static int usb_hcd_check_unlink_urb(struct usb_hcd *hcd, struct urb *urb,
+ int status)
+{
+ unsigned long flags;
+ struct list_head*tmp;
+ int rc = 0;
+
+ /*
+* we contend for urb-status with the hcd core,
+* which changes it while returning the urb.
+*
+* Caller guaranteed that the urb pointer hasn't been freed, and
+* that it was submitted
Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes
On Fri, 3 Aug 2007, Matthew Garrett wrote: On Thu, Aug 02, 2007 at 06:15:05PM -0700, Greg KH wrote: Well, if you do this, then you can pretty much delete the whole quirk table we have, right? At the moment, yes. And personally, I want to do better than Windows XP when it comes to power management. This patch is only going to suspend a very tiny subset of devices, including a whole bunch of ones that do not even have drivers in Linux, causing our power footprint to be bigger than needed. I agree. I'd much rather see us suspending devices whenever possible - it's just that I have concerns over the scalability of the blacklist, given the number of devices that seem to have issues. While I agree in general, perhaps a different approach would work better. For instance, we could blacklist a few known-bad device classes (maybe even using the existing blacklist) rather than whitelisting a few known-good ones -- or trying to blacklist each member of the bad classes! Also, building something this sweeping into a kernel driver feels like a mistake. It ought to be more easily configurable from userspace, say via a sysfs file. Although this wouldn't be so important if we take the blacklist-classes route. Alan Stern - 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] [usb-storage] Large USB storage devices cause df to hang and cpu load reaches 100%
On Tue, 31 Jul 2007, Matthew Dharm wrote: What the heck happened to your logs? It looks like about 75% of the data is being lost from the log file... With all the USB I/O activity going on, syslogd must not be getting enough CPU time to capture all the kernel log data. If more detail is needed you can use usbmon. (Instructions are in the kernel source file documentation/usb/usbmon.txt.) Alan Stern - 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%
On Tue, 31 Jul 2007, Kostas Peletidis wrote: Branden Sletteland wrote: I have also noticed this delay and have through instrumenting code have found that every block in the device gets read in. I never checked if it was something in the df, filesystem, SCSI, or USB subsystems that was causing this. I am usually doing df on USB storage devices formated as FAT 32 w/ and w/o LBA. Branden Thanks for your reply Branden. This explains why df would delay for a whole minute to terminate normally with a 500GB usb disk attached and only for a second or two with a 512MB usb stick attached. Btw both are vfat. This brings another question though: Why read every single block during the first run of df after the partition is mounted? Obviously buffering 500GB for fast access is currently out of the question so could it be the case that some sanity check was going on? Nothing in the df, SCSI, or USB code would cause this. That seems to leave the filesystem or block layers as the most likely candidates. Alan Stern - 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] USB BIOS early handoff only when the we the driver is configured
On Wed, 1 Aug 2007, David Engraf wrote: At the moment I have a Jetway/VIA Mainboard which seems to have a problem with the handoff. Even when I wait about 20 seconds the EHCI_USBLEGSUP_BIOS flag is not cleared. I think this is a BIOS bug and I will have to talk to Jetway/VIA. I have the same problem on my Intel motherboard. Which is surprising, considering that Intel invented the BIOS-handoff technique. On the other hand, I don't need the EHCI controller in my kernel, so I think the kernel shouldn't take the handover for the EHCI controller like other OS which do not have an usb driver and so don't know that there is a EHCI_USBLEGSUP_BIOS flag which should be cleared. There ought to be a solution to satisfy everybody. For instance, you could add a Kconfig flag for enabling USB handoff, and make it be selected automatically if any of the PCI USB drivers are configured. Alan Stern - 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] Can't unload uhci_hcd module with 2.6.22 -- also oops
On Tue, 31 Jul 2007, A. Kalten wrote:
The kernel 2.6.22 was patched and recompiled.
It shouldn't make a difference but the problem occurs
only if I load the modules _before_ plugging in the external
modem. If I load the modules _after_ plugging in the modem,
the problem disappears. (At least this is what happens with
the patched kernel. I'll revert back to the unpatched and
see if this is still the case.)
This shouldn't make any difference. Your later message was
self-contradictory; you wrote that the oops occurred only if the
modules were loaded before the modem was plugged in, and that it also
occurred if the modules were loaded after the modem was plugged in.
If you unplug the modem without unloading anything, does the error
occur?
Here's an additional patch for 2.6.22, to be applied along with the
previous patch. Let's see what it shows.
Alan Stern
Index: 2.6.22/drivers/usb/core/message.c
===
--- 2.6.22.orig/drivers/usb/core/message.c
+++ 2.6.22/drivers/usb/core/message.c
@@ -18,6 +18,8 @@
#include hcd.h /* for usbcore internals */
#include usb.h
+extern int attrtest;
+
static void usb_api_blocking_completion(struct urb *urb)
{
complete((struct completion *)urb-context);
@@ -1056,8 +1058,10 @@ void usb_disable_device(struct usb_devic
continue;
dev_dbg (dev-dev, unregistering interface %s\n,
interface-dev.bus_id);
+if (dev-parent) attrtest = 1;
usb_remove_sysfs_intf_files(interface);
device_del (interface-dev);
+attrtest = 0;
}
/* Now that the interfaces are unbound, nobody should
@@ -1574,6 +1578,7 @@ free_interfaces:
adding %s (config #%d, interface %d)\n,
intf-dev.bus_id, configuration,
intf-cur_altsetting-desc.bInterfaceNumber);
+if (dev-parent) attrtest = 1;
ret = device_add (intf-dev);
if (ret != 0) {
dev_err(dev-dev, device_add(%s) -- %d\n,
@@ -1581,6 +1586,7 @@ free_interfaces:
continue;
}
usb_create_sysfs_intf_files (intf);
+attrtest = 0;
}
usb_autosuspend_device(dev);
Index: 2.6.22/fs/sysfs/file.c
===
--- 2.6.22.orig/fs/sysfs/file.c
+++ 2.6.22/fs/sysfs/file.c
@@ -13,6 +13,9 @@
#include sysfs.h
+int attrtest;
+EXPORT_SYMBOL(attrtest);
+
#define to_sattr(a) container_of(a,struct subsys_attribute, attr)
/*
@@ -466,6 +469,8 @@ int sysfs_create_file(struct kobject * k
{
BUG_ON(!kobj || !kobj-dentry || !attr);
+if (attrtest) printk(%s: create file %p %s\n, kobject_name(kobj), attr,
+attr-name);
return sysfs_add_file(kobj-dentry, attr, SYSFS_KOBJ_ATTR);
}
@@ -576,6 +581,7 @@ EXPORT_SYMBOL_GPL(sysfs_chmod_file);
void sysfs_remove_file(struct kobject * kobj, const struct attribute * attr)
{
+if (attrtest) printk(%s: remove file %p\n, kobject_name(kobj), attr);
sysfs_hash_and_remove(kobj-dentry, attr-name);
}
Index: 2.6.22/fs/sysfs/group.c
===
--- 2.6.22.orig/fs/sysfs/group.c
+++ 2.6.22/fs/sysfs/group.c
@@ -17,6 +17,7 @@
#include asm/semaphore.h
#include sysfs.h
+extern int attrtest;
static void remove_files(struct dentry * dir,
const struct attribute_group * grp)
@@ -24,8 +25,10 @@ static void remove_files(struct dentry *
struct attribute *const* attr;
for (attr = grp-attrs; *attr; attr++)
+{if (attrtest) printk(Remove %p\n, *attr);
sysfs_hash_and_remove(dir,(*attr)-name);
}
+}
static int create_files(struct dentry * dir,
const struct attribute_group * grp)
@@ -34,6 +37,7 @@ static int create_files(struct dentry *
int error = 0;
for (attr = grp-attrs; *attr !error; attr++) {
+if (attrtest) printk(Add %p %s\n, *attr, (*attr)-name);
error = sysfs_add_file(dir, *attr, SYSFS_KOBJ_ATTR);
}
if (error)
@@ -56,6 +60,7 @@ int sysfs_create_group(struct kobject *
return error;
} else
dir = kobj-dentry;
+if (attrtest) printk(%s: create group %p\n, kobject_name(kobj), grp);
dir = dget(dir);
if ((error = create_files(dir,grp))) {
if (grp-name)
@@ -78,6 +83,7 @@ void sysfs_remove_group(struct kobject *
else
dir = dget(kobj-dentry);
+if (attrtest) printk(%s: remove group %p\n, kobject_name(kobj), grp);
remove_files(dir,grp);
if (grp-name)
sysfs_remove_subdir(dir);
-
This SF.net email is sponsored by: Splunk Inc.
Still
Re: [linux-usb-devel] Large USB storage devices cause df to hang and cpu load reaches 100%
On Wed, 1 Aug 2007, Sergey Vlasov wrote: On Tue, Jul 31, 2007 at 11:08:37PM +0100, Kostas Peletidis wrote: Branden Sletteland wrote: I have also noticed this delay and have through instrumenting code have found that every block in the device gets read in. I never checked if it was something in the df, filesystem, SCSI, or USB subsystems that was causing this. I am usually doing df on USB storage devices formated as FAT 32 w/ and w/o LBA. Branden Thanks for your reply Branden. This explains why df would delay for a whole minute to terminate normally with a 500GB usb disk attached and only for a second or two with a 512MB usb stick attached. Btw both are vfat. This brings another question though: Why read every single block during the first run of df after the partition is mounted? Obviously buffering 500GB for fast access is currently out of the question so could it be the case that some sanity check was going on? Probably the commit 28ec039c21839914389975b896160a815ffd8b83 is the culprit: fat: don't use free_clusters for fat32 It seems that the recent Windows changed specification, and it's undocumented. Windows doesn't update -free_clusters correctly. This patch doesn't use -free_clusters by default. (instead, add usefree for forcing to use it) Signed-off-by: OGAWA Hirofumi [EMAIL PROTECTED] Cc: Juergen Beisert [EMAIL PROTECTED] Cc: Andreas Schwab [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] You can add usefree to mount options - it will restore the old behavior (which can apparently lead to wrong free space reports after the disk has been used by some Windows versions). Without usefree the vfat code in 2.6.22 will read the whole FAT to count free clusters on the filesystem. But reading the whole FAT is very different from reading the entire partition. Alan Stern - 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%
On Wed, 1 Aug 2007, Sergey Vlasov wrote: But reading the whole FAT is very different from reading the entire partition. Reading the entire 500GB in one minute? I would really like to have such disk :) Most likely every block here really means a large sequential read. Not sure what cluster size would be used for a 500GB FAT32 partition, but with 4KB clusters the FAT size would be about 500MB - reading it over USB could probably take about a minute. Yes, that sounds right. We can consider this problem solved. :-) Alan Stern - 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] Can't unload uhci_hcd module with 2.6.22 -- also oops
On Wed, 1 Aug 2007, A. Kalten wrote: On Wed, 1 Aug 2007 11:55:25 -0400 (EDT) Alan Stern [EMAIL PROTECTED] wrote: This shouldn't make any difference. Your later message was self-contradictory; you wrote that the oops occurred only if the modules were loaded before the modem was plugged in, and that it also occurred if the modules were loaded after the modem was plugged in. Sorry about the confusion. At first I just assumed that the kernel oops occured under all conditions, but on closer inspection I found that it only occurs when the modules are loaded before the modem is plugged in. So, to get things straight: 1) plug in modem 2) load modules 3) unload modules No kernel oops 1) load modules 2) plug in modem 3) unload modules kernel oops Okay, I understand. Here's an additional patch for 2.6.22, to be applied along with the previous patch. Let's see what it shows. 2.6.22 has been patched with this and the previous patch. Here is the kernel log containing the oops. It results from the following sequence (I included the time as well): There's some useful information here but still not enough. I've got a third patch for you to add in; hopefully we are zeroing in on the correct spot. For this test you don't have to run the non-oopsing scenarios. Alan Stern Index: 2.6.22/drivers/base/core.c === --- 2.6.22.orig/drivers/base/core.c +++ 2.6.22/drivers/base/core.c @@ -24,6 +24,8 @@ #include base.h #include power/power.h +extern int attrtest; + int (*platform_notify)(struct device * dev) = NULL; int (*platform_notify_remove)(struct device * dev) = NULL; @@ -926,7 +928,10 @@ void device_del(struct device * dev) up(dev-class-sem); } } +attrtest = 1; +printk(%s: before remove uevent\n, dev-bus_id); device_remove_file(dev, dev-uevent_attr); +printk(after remove uevent\n); device_remove_attrs(dev); bus_remove_device(dev); @@ -945,7 +950,9 @@ void device_del(struct device * dev) if (dev-bus) blocking_notifier_call_chain(dev-bus-bus_notifier, BUS_NOTIFY_DEL_DEVICE, dev); +printk(%s: before remove power\n, dev-bus_id); device_pm_remove(dev); +printk(after remove power\n); kobject_uevent(dev-kobj, KOBJ_REMOVE); kobject_del(dev-kobj); if (parent) - 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] Can't unload uhci_hcd module with 2.6.22 -- also oops
On Wed, 1 Aug 2007, A. Kalten wrote: The patch was applied (along with the previous two patches) and 2.6.22 was recompiled. Then after a reboot, I performed the same sequence to generate the oops: modprobe uhci-hcd modprobe cdc-acm mount -t usbfs none /proc/bus/usb Plug in external modem umount /proc/bus/usb rmmod cdc-acm rmmod uhci-hcd Here is the kernel log: Okay, good work. Thanks to your careful experiments, plus the hints from Oliver and Tejun, I figured out the problem. In short, the attribute files were registered on the control interface but the driver tried to delete them from the data interface. I'll post a patch tomorrow morning. Alan Stern - 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 1/7] USB: add urb-ep
On Mon, 30 Jul 2007, Pete Zaitcev wrote: I am afraid that drivers call unlink left and right, even on URBs which were not submitted and thus have -ep == NULL. But on the other hand, maybe we want to catch them... That's a good point. I'll add a test to one of the upcoming patches to check for !urb-ep. To some extent drivers have to take responsibility for using usb_unlink_urb() correctly. For example, calling it long after the URB has completed and the device has been unplugged is liable to cause problems because of the stale device pointer. I don't think there's much the core can do about this. Alan Stern - 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] Can't unload uhci_hcd module with 2.6.22 -- also oops
On Mon, 30 Jul 2007, A. Kalten wrote: On Mon, 30 Jul 2007 18:09:23 -0400 (EDT) Alan Stern [EMAIL PROTECTED] wrote: Does this patch help? http://article.gmane.org/gmane.linux.kernel/556682/raw I cannot apply that patch to the 2.6.22 source: [linux-2.6.22]# patch -p1 kernel.patch patching file fs/sysfs/symlink.c Hunk #1 FAILED at 86. Quite right -- I hadn't noticed that you were using 2.6.22. That patch is meant for 2.6.23-rc1. Can you try running 2.6.23-rc1 plus the patch and see if together they fix the problem? Alan Stern - 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 3/7] USB: add direction bit to urb-transfer_flags
On Mon, 30 Jul 2007, Pete Zaitcev wrote:
On Mon, 30 Jul 2007 17:06:16 -0400 (EDT), Alan Stern [EMAIL PROTECTED]
wrote:
--- usb-2.6.orig/drivers/usb/core/urb.c
+++ usb-2.6/drivers/usb/core/urb.c
@@ -309,7 +309,21 @@ int usb_submit_urb(struct urb *urb, gfp_
xfertype = usb_endpoint_type(ep-desc);
- is_out = usb_pipeout(urb-pipe);
+ if (xfertype == USB_ENDPOINT_XFER_CONTROL) {
+ struct usb_ctrlrequest *setup =
+ (struct usb_ctrlrequest *) urb-setup_packet;
+
+ if (!setup)
+ return -ENOEXEC;
I welcome this. I should be able to rip some code out of usbmon now.
The comment in usb.h says:
* (Note
* that transfer_buffer and setup_packet must still be set because not all
* host controllers use DMA, nor do virtual root hubs).
But in case of data, this happens when a driver attempts to set up DMA
with a highmem page without doing a kmap first. I think we never enforced
the above comment.
It is enforced only for host controllers that use PIO, and only in
the most rudimentary way -- the driver crashes if the field isn't set!
And I think that I managed to oops usbmon by dereferencing
garbage in transfer_buffer before but I may not remember right.
But the setup packet should be mapped to be used, right? There's no
good reason for setup_packet not to be mapped, right?
Not that I can think of. Nobody ever sends setup packet contents
through scatter-gather buffers.
Alan Stern
P.S.: I appreciate the critical review!
-
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] vfs_read problem in g_file_storage
On Tue, 31 Jul 2007, Rajesh Srinivasan wrote: Thanks for the response alan, That sounds sensible, but thing is, vfs fails in the very first read of sector 0 (offset 0), and when i do a ls -l , the file shows a good 8MB (which i created with dd ) any suggestions? I have no idea what could be wrong. If you can read the file contents from the command line (with dd, for example) then the driver should be able to read it equally well. Alan Stern - 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 1/7] USB: add urb-ep
On Mon, 30 Jul 2007, David Brownell wrote: On Monday 30 July 2007, Alan Stern wrote: /* power of two? */ - while (temp urb-interval) - temp = 1; - urb-interval = temp; + while (max urb-interval) + max = 1; + urb-interval = max; #include linux/log2.h if (urb-interval max) urb-interval = max else urb-interval = ilog2(urb-interval); or somesuch? That previous code is a bit opaque, and the loop can often be replaced by a single instruction. That's a good suggestion. I'll put it in a cleanup patch. Related: consider making urb-interval and its neighbors be u32 or maybe even u16. Hmmm... maybe. It's not clear the space savings would matter much; I doubt that terribly many URBs ever get allocated at the same time. And while it's true that the values should never be negative, there's not much incentive to change the type to unsigned. Alan Stern - 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 3/7] USB: add direction bit to urb-transfer_flags
On Mon, 30 Jul 2007, David Brownell wrote:
On Monday 30 July 2007, Alan Stern wrote:
+static inline int usb_urb_dir_in(struct urb *urb)
+{
+ return (urb-transfer_flags URB_DIR_MASK) != URB_DIR_OUT;
+}
Clearer would be: == URB_DIR_IN ... or does that generate bad code?
I didn't actually check the generated code before submitting the patch.
A quick test with gcc 4.1.2 on x86 shows that the two sources give rise
to identical objects. I guess the same will probably be true on other
architectures too.
Okay, I'll change it.
Alan Stern
-
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] USB BIOS early handoff only when the we the driver is configured
On Tue, 31 Jul 2007, David Engraf wrote: When CONFIG_USB_UHCI_HCD, CONFIG_USB_OHCI_HCD or CONFIG_USB_EHCI_HCD is not configured we don't need to call the quirk_usb_handoff_ function in driver/usb/host/pci_quiks.c. I think the kernel shouldn't take the control over the usb controller when we don't have the driver for it, so with this patch the kernel takes the control only when the driver is configured. Have you found a system where this really improves behavior or is it just theoretical? There _is_ a theoretical reason for running the handoff routines even when the corresponding driver isn't configured. Namely, at startup the controller will be in some undetermined state as a result of usage by the firmware. Resetting it to a known idle state is a good idea. Bear in mind that on some systems, not performing the handoff has caused interrupt storms during startup. Alan Stern - 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] autosuspend for asix driver
On Tue, 31 Jul 2007, Oliver Neukum wrote: --- a/drivers/net/usb/usbnet.c2007-07-30 14:27:40.0 +0200 +++ b/drivers/net/usb/usbnet.c2007-07-31 11:07:51.0 +0200 @@ -1143,6 +1157,7 @@ usbnet_probe (struct usb_interface *udev dev = netdev_priv(net); dev-udev = xdev; + dev-intf = udev; dev-driver_info = info; dev-driver_name = name; dev-msg_enable = netif_msg_init (msg_level, NETIF_MSG_DRV --- a/drivers/net/usb/asix.c 2007-07-30 14:18:38.0 +0200 +++ b/drivers/net/usb/asix.c 2007-07-30 16:04:45.0 +0200 @@ -844,6 +844,7 @@ static int ax88172_bind(struct usbnet *d dev-mii.phy_id_mask = 0x3f; dev-mii.reg_num_mask = 0x1f; dev-mii.phy_id = asix_get_phy_addr(dev); + dev-intf = intf; dev-net-do_ioctl = asix_ioctl; dev-net-set_multicast_list = ax88172_set_multicast; You assign dev-intf in both the usbnet framework driver and the subdriver. Could the subdriver's assignment be removed? Alan Stern - 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 1/7] USB: add urb-ep
On Tue, 31 Jul 2007, David Brownell wrote: On Tuesday 31 July 2007, Alan Stern wrote: Related: consider making urb-interval and its neighbors be u32 or maybe even u16. Hmmm... maybe. It's not clear the space savings would matter much; I doubt that terribly many URBs ever get allocated at the same time. I don't follow. Space savings are more often an accumulation of small improvements than any single big thing. That may be. But shrinking fields like this can cause code size to increase, because the instructions needed for accessing the smaller fields tend to be longer (and slower!) than the instructions for accessing a normal word. There needs to be a balance. And allocating many at once vs the same number over time doesn't matter, either ... the same amount of memory would be saved. Not so. If you allocated 100 URBs at the same time, the space savings would be multiplied by a factor of 100. But if you allocated 10 URBs and deallocated them, then allocated another 10 and deallocated them, and so on 10 times, the space savings would be multiplied by a factor of only 10, not 100. And while it's true that the values should never be negative, there's not much incentive to change the type to unsigned. I'll just disagree. Code written so that it's not *possible* to have a class of errors is better than similar code which could misbehave. I agree. But in this case the code has already been written and you're suggesting a change -- which might introduce its own bugs. In this case, you agree should never be negative, but evidently think there might be some benefit to letting those values become negative so that algorithms could execute with data outside of the intended and tested ranges ... really, I can't follow that logic. Well, consider this example. urb-actual_length is naturally non-negative, right? But uhci-hcd initializes it to -8 for control URBs, so that the effect of accumulating the transfer size of the setup packet is automatically taken into account. There's a little extra code to prevent negative values from ever becoming visible to drivers in cases where the setup packet isn't transmitted; that extra code would become buggy if actual_length were changed to an unsigned type. Sure, it could be fixed. The point is that without careful checking, merely changing a signed integer to unsigned can introduce bugs. So let's put it like this: If _you_ would like to change those fields, I won't stand in your way. I'll even go through uhci-hcd and dummy-hcd to make sure there are no ill effects. An even better change would be to remove urb-error_count. IIRC it is used only in a couple of drivers, and there just for debug log messages. Alan Stern - 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] Can't unload uhci_hcd module with 2.6.22 -- also oops
On Tue, 31 Jul 2007, A. Kalten wrote: On Tue, 31 Jul 2007 13:00:38 -0400 A. Kalten [EMAIL PROTECTED] wrote: But after compiling 2.6.23-rc1 and undergoing the same steps with the usb modem as before, the problem remains. The only difference is that the command rmmod uhci-hcd now reports the message Killed instead of Device busy. For whatever it's worth.I should point out that this problem only occurs when using the USB Abstract Control Model driver for USB modems (i.e. the cdc_acm module). When using my USB scanner or USB printer I can unload the uhci-hcd module without any problem using the equivalent procedure. Hmmm. So if you stop before the modprobe cdc-acm step there's no trouble with rmmod uhcd-hcd. What about if you do load cdc-acm but don't run the fax program? Alan Stern - 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 UPS APC Back-UPS CS 650
On Tue, 31 Jul 2007, Boris Losev wrote: This error indicates that the computer is unable to communicate with the device. Are the cables okay? Don't forget to check any cables inside the computer case, connecting the motherboard to the ports. Does your computer work with other USB devices? Does the UPS device work with other computers? Alan Stern I've connected the UPS to my laptop with Windows XP. The UPS was successfully recognized by OS. Does the laptop recognize the UPS device when you run Linux on the laptop? Alan Stern - 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] Can't unload uhci_hcd module with 2.6.22 -- also oops
On Tue, 31 Jul 2007, Oliver Neukum wrote:
Am Dienstag 31 Juli 2007 schrieb A. Kalten:
On Tue, 31 Jul 2007 13:00:38 -0400
A. Kalten [EMAIL PROTECTED] wrote:
But after compiling 2.6.23-rc1 and undergoing the same steps
with the usb modem as before, the problem remains. The only
difference is that the command rmmod uhci-hcd now reports
the message Killed instead of Device busy.
For whatever it's worth.I should point out that this problem
only occurs when using the USB Abstract Control Model driver
for USB modems (i.e. the cdc_acm module). When using my
USB scanner or USB printer I can unload the uhci-hcd module
without any problem using the equivalent procedure.
acm uses two interfaces for one driver which is pretty rare and explains
that a refcounting problem is not seen with other drivers.
But shouldn't the same problem affect other people?
Here's a diagnotic patch to try under 2.6.22. It should add some
interesting information to the kernel log, starting from the point
where the modem gets plugged in.
Alan Stern
Index: 2.6.22/drivers/usb/core/sysfs.c
===
--- 2.6.22.orig/drivers/usb/core/sysfs.c
+++ 2.6.22/drivers/usb/core/sysfs.c
@@ -530,6 +530,7 @@ int usb_create_sysfs_intf_files(struct u
struct usb_host_interface *alt = intf-cur_altsetting;
int retval;
+ dev_info(dev, Create sysfs intf files\n);
retval = sysfs_create_group(dev-kobj, intf_attr_grp);
if (retval)
return retval;
@@ -546,6 +547,7 @@ void usb_remove_sysfs_intf_files(struct
{
struct device *dev = intf-dev;
+ dev_info(dev, Remove sysfs intf files\n);
usb_remove_intf_ep_files(intf);
device_remove_file(dev, dev_attr_interface);
sysfs_remove_group(dev-kobj, intf_attr_grp);
-
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%
On Tue, 31 Jul 2007, Kostas Peletidis wrote: Hi Alan, I enabled CONFIG_USB_DEBUG and reproduced the problem but didn't see any messages in the dmesg output. To ensure that the debug code was indeed built in I unplugged the disk then plugged it back in. I got quite a few messages, here are the last of them: I see most of these messages at boot time even with older 2.6 kernels. Yes, they are normal. The problem appears after the device scan complete message is traced. The patch that caused this issue was added between the 2.6.21.5 and 2.6.22 releases. The only patch that led to 2.6.21.6 had to do with nf_conntrack_h323 so this leaves us with the patches between 2.6.21.6 and 2.6.22. There are quite a few usb changes in that changelog so I was hoping that someone might recognise/remember something relevant. I'd guess that this was caused by a change somewhere else in the kernel, not in the USB stack. My advice now is the same as Matt's was: turn on CONFIG_USB_STORAGE_DEBUG and see what you get. Alan Stern - 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] vfs_read problem in g_file_storage
On Mon, 30 Jul 2007, Rajesh Srinivasan wrote: Hi, Have anyone come across this problem? Can you give me any pointers.. in file_storage, vfs_read (during READ-10) returns 0 bytes read. No Errors, but No datas read either. That's normal behavior when a read encounters end-of-file. Of course, with g-file-storage this should never happen -- unless somehow the backing file managed to shrink. Thanks Regards Rajesh *** Aricent-Private *** DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. Please note: This sort of disclaimer is completely inappropriate for email sent to a public mailing list. In theory it means that I should not have been allowed to send a reply. Alan Stern - 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] software unplug
On Mon, 30 Jul 2007, Lucio Crusca wrote: Hello *, I have a problem with bluetooth USB dongles. Scenario: a number of unattended systems have a USB bluetooth dongle that send files to nearby bluetooth devices. The systems are built on top of Debian GNU/Linux Etch i386 and use obexftp 0.19 to send files. Sometimes it happens that something between bluez and the hardware stops working, so in such cases my script issue hciconfig hci0 reset to recover and everything comes back ok. More rarely the reset method seems to be insufficient, because the device disappears even from lsusb output. The only solution I've found in such cases is to unplug and replug the dongle (even a few reboot cycles aren't enough). However that solution is not acceptable for me, since the systems should run unattended. Do you know how could I simulate unplug/replug events from software? Or any other solution that can run unattended? There is no way to simulate unplug/replug from software for devices attached directly to the computer. However it is possible for devices plugged into some brands of hub. See this web page: http://www.gniibe.org/ac-power-by-usb/ac-power-control.html Alan Stern - 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] software unplug
On Mon, 30 Jul 2007, Felipe Balbi wrote: Hi, On 7/30/07, Alan Stern [EMAIL PROTECTED] wrote: On Mon, 30 Jul 2007, Lucio Crusca wrote: There is no way to simulate unplug/replug from software for devices attached directly to the computer. However it is possible for devices plugged into some brands of hub. See this web page: Wouldn't cutting the power force a disconnect interrupt?? Lucio's problem is that the device has _already_ disconnected. Getting an additional disconnect interrupt won't make any difference. Maybe if he echo'es correctly on sysfs, he could achieve this... Nope. You cannot turn off the USB bus power on the computer's USB ports no matter what you do; the hardware doesn't permit it. Alan Stern - 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 UPS APC Back-UPS CS 650
On Mon, 30 Jul 2007, Boris Losev wrote: Hi All! I've got the APC Back-UPS CS 650 and Debian Etch with the kernel 2.6.18-4-686. I've tried to connect my UPS to PC via USB cable and got the errors: usb 2-1: new low speed USB device using ohci_hcd and address 14 usb 2-1: device not accepting address 14, error -71 usb 2-1: new low speed USB device using ohci_hcd and address 15 usb 2-1: device not accepting address 15, error -71 usb 2-1: new low speed USB device using ohci_hcd and address 16 usb 2-1: device descriptor read/64, error -71 usb 2-1: device descriptor read/64, error -71 usb 2-1: new low speed USB device using ohci_hcd and address 17 usb 2-1: device descriptor read/64, error -71 usb 2-1: device not accepting address 17, error -71 [EMAIL PROTECTED]:~$ lsmod |grep usb usb_storage71840 0 ide_core 110504 4 usb_storage,ide_cd,amd74xx,generic usbcore 112644 5 usb_storage,ohci_hcd,uhci_hcd,ehci_hcd scsi_mod 124168 3 usb_storage,sd_mod,libata I've mixed modules ohci_hcd,uhci_hcd,ehci_hcd in the different combinations, but it didn't help. My motheboard is Epox EP-AGF6110-M with integrated USB. Could you help me with my problem ? This error indicates that the computer is unable to communicate with the device. Are the cables okay? Don't forget to check any cables inside the computer case, connecting the motherboard to the ports. Does your computer work with other USB devices? Does the UPS device work with other computers? Alan Stern - 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] drivers/usb/gadget/dummy_hcd.c - DEBUG redefined warnings
On Mon, 30 Jul 2007, Gabriel C wrote: Hi, I noticed the following warnings with a randconfig ( http://194.231.229.228/git-current/randconfig-auto-34 ): ... CC [M] drivers/usb/gadget/dummy_hcd.o drivers/usb/gadget/dummy_hcd.c:37:1: warning: DEBUG redefined command-line: warning: this is the location of the previous definition CC drivers/scsi/scsi_transport_sas.o CC drivers/usb/core/notify.o CC drivers/usb/core/generic.o drivers/usb/gadget/dummy_hcd.c:37:1: warning: DEBUG redefined command-line: warning: this is the location of the previous definition ... Line 37 is #define DEBUG , is that really needed ? No it isn't -- that's a mistake. Thanks for pointing it out. Alan Stern - 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] software unplug
On Mon, 30 Jul 2007, Felipe Balbi wrote: On 7/30/07, Alan Stern [EMAIL PROTECTED] wrote: On Mon, 30 Jul 2007, Felipe Balbi wrote: Lucio's problem is that the device has _already_ disconnected. Getting an additional disconnect interrupt won't make any difference. yeah... off course :-p Maybe if he echo'es correctly on sysfs, he could achieve this... Nope. You cannot turn off the USB bus power on the computer's USB ports no matter what you do; the hardware doesn't permit it. and what about: echo suspend /sys/class/usb_device/usbdevX.Y/device/power/level ??? where X is the bus number and Y is the device number, without the 00 in the beginning... Ain't I cutting off power on that port?? No. It forces the port into suspend mode but the power is still on. Alan Stern - 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] EHCI and OHCI port numbering?
On Mon, 30 Jul 2007, Alex Chiang wrote: Hello, How are ports numbered/ordered in the case of an EHCI controller with a companion controller? Example: N_PORTS = 6 AND N_CC = 2 N_PCC = 3 ORPORTROUTE[] = 1,1,1,2,2,2 Would give a routing configuration of: EHCI port 1 = OHCI1 port 1 (not 2 or 3) EHCI port 2 = OHCI1 port 2 (not 1 or 3) EHCI port 3 = OHCI1 port 3 (not 1 or 2) EHCI port 4 = OHCI2 port 1etc. EHCI port 5 = OHCI2 port 2 EHCI port 6 = OHCI2 port 3 Is this assumption correct? Yes. Except that the companion controllers might not be OHCI-1 and OHCI-2 -- they might be OHCI-3 and OHCI-4. In fact, something like that is certain to happen if you have more than one EHCI controller. The broader context of this question is, on ia64 systems, certain EFI drivers only support 1.1. So imagine a scenario where one might have two USB cdroms attached to the system, but only want to boot off of one (or maybe something more plausible, a USB hard drive and a USB cdrom, and are booting off the CD). When the bootloader hands off to the kernel and says use the device attached to OHCI controller N, port M will the value of M change when the EHCI driver takes over? There's no way for the bootloader to tell the kernel that. The most it can do is something like root=/dev/sr0. It's up to the udev scripts in the kernel's initramfs to make sure that the correct device is mapped by /dev/sr0. Alan Stern - 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
[linux-usb-devel] [PATCH 0/7] Move away from urb-pipe
It seems to happen quite often that trying to make one change ends up requiring changes to a whole bunch of other things first. That's my situation now. Ultimately I want to remove references to urb-status from the HCDs and usbcore. This turned out to be complicated by the need to unlink URBs reliably. That will be taken care of by moving responsibility for adding and removing URBs from endpoint queues out of usbcore, into the HCDs. This in turn makes it necessary to add an endpoint pointer into the URB structure. But as long as the ep pointer is available, we don't really need the pipe and there's no good reason to keep it. Hence this first collection of patches is aimed at removing urb-pipe. To remove it completely would require a far-reaching API change, one that would affect every USB driver. I haven't gone that far; the pipe is still present. Instead these patches reduce the core's dependence on the pipe; references to it have been changed into references to the endpoint. Of course there's still a need for making similar changes to the HCDs and then all the other drivers. That can be done in time; it will be a large and error-prone job. This merely represents the first step. Until then urb-pipe and urb-ep can coexist peacefully. After this series will come some more patches for endpoint queue management and eventually the patches for urb-status. Some of those are written already but they aren't all finished yet. In the meantime, these patches are relatively small and self-contained. Alan Stern - 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
[linux-usb-devel] [PATCH 1/7] USB: add urb-ep
This patch (as943) prepares the way for eliminating urb-pipe by
introducing an endpoint pointer into struct urb. For now urb-ep
is set by usb_submit_urb() from the pipe value; eventually drivers
will set it themselves and we will remove urb-pipe completely.
The patch also adds new inline routines to retrieve an endpoint
descriptor's number and transfer type, essentially as replacements for
usb_pipeendpoint and usb_pipetype.
usb_submit_urb(), usb_hcd_submit_urb(), and usb_hcd_unlink_urb() are
converted to use the new field and new routines. Other parts of
usbcore will be converted in later patches.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Index: usb-2.6/include/linux/usb.h
===
--- usb-2.6.orig/include/linux/usb.h
+++ usb-2.6/include/linux/usb.h
@@ -562,6 +562,29 @@ static inline int usb_make_path (struct
/*-*/
/**
+ * usb_endpoint_num - get the endpoint's number
+ * @epd: endpoint to be checked
+ *
+ * Returns @epd's number: 0 to 15.
+ */
+static inline int usb_endpoint_num(const struct usb_endpoint_descriptor *epd)
+{
+ return epd-bEndpointAddress USB_ENDPOINT_NUMBER_MASK;
+}
+
+/**
+ * usb_endpoint_type - get the endpoint's transfer type
+ * @epd: endpoint to be checked
+ *
+ * Returns one of USB_ENDPOINT_XFER_{CONTROL, ISOC, BULK, INT} according
+ * to @epd's transfer type.
+ */
+static inline int usb_endpoint_type(const struct usb_endpoint_descriptor *epd)
+{
+ return epd-bmAttributes USB_ENDPOINT_XFERTYPE_MASK;
+}
+
+/**
* usb_endpoint_dir_in - check if the endpoint has IN direction
* @epd: endpoint to be checked
*
@@ -1044,6 +1067,8 @@ typedef void (*usb_complete_t)(struct ur
* @urb_list: For use by current owner of the URB.
* @anchor_list: membership in the list of an anchor
* @anchor: to anchor URBs to a common mooring
+ * @ep: Points to the endpoint's data structure. Will eventually
+ * replace @pipe.
* @pipe: Holds endpoint number, direction, type, and more.
* Create these values with the eight macros available;
* usb_{snd,rcv}TYPEpipe(dev,endpoint), where the TYPE is ctrl
@@ -1219,6 +1244,7 @@ struct urb
struct list_head anchor_list; /* the URB may be anchored by the
driver */
struct usb_anchor *anchor;
struct usb_device *dev; /* (in) pointer to associated device */
+ struct usb_host_endpoint *ep; /* (internal) pointer to endpoint
struct */
unsigned int pipe; /* (in) pipe information */
int status; /* (return) non-ISO status */
unsigned int transfer_flags;/* (in) URB_SHORT_NOT_OK | ...*/
Index: usb-2.6/drivers/usb/core/urb.c
===
--- usb-2.6.orig/drivers/usb/core/urb.c
+++ usb-2.6/drivers/usb/core/urb.c
@@ -277,9 +277,10 @@ EXPORT_SYMBOL_GPL(usb_unanchor_urb);
*/
int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
{
- int pipe, temp, max;
- struct usb_device *dev;
- int is_out;
+ int xfertype, max;
+ struct usb_device *dev;
+ struct usb_host_endpoint*ep;
+ int is_out;
if (!urb || urb-hcpriv || !urb-complete)
return -EINVAL;
@@ -291,30 +292,34 @@ int usb_submit_urb(struct urb *urb, gfp_
|| dev-state == USB_STATE_SUSPENDED)
return -EHOSTUNREACH;
+ /* For now, get the endpoint from the pipe. Eventually drivers
+* will be required to set urb-ep directly and we will eliminate
+* urb-pipe.
+*/
+ ep = (usb_pipein(urb-pipe) ? dev-ep_in : dev-ep_out)
+ [usb_pipeendpoint(urb-pipe)];
+ if (!ep)
+ return -ENOENT;
+
+ urb-ep = ep;
urb-status = -EINPROGRESS;
urb-actual_length = 0;
/* Lots of sanity checks, so HCDs can rely on clean data
* and don't need to duplicate tests
*/
- pipe = urb-pipe;
- temp = usb_pipetype(pipe);
- is_out = usb_pipeout(pipe);
+ xfertype = usb_endpoint_type(ep-desc);
+ is_out = usb_pipeout(urb-pipe);
- if (!usb_pipecontrol(pipe) dev-state USB_STATE_CONFIGURED)
+ if (xfertype != USB_ENDPOINT_XFER_CONTROL
+ dev-state USB_STATE_CONFIGURED)
return -ENODEV;
- /* FIXME there should be a sharable lock protecting us against
-* config/altsetting changes and disconnects, kicking in here.
-* (here == before maxpacket, and eventually endpoint type,
-* checks get made.)
-*/
-
- max = usb_maxpacket(dev, pipe, is_out);
+ max = le16_to_cpu(ep-desc.wMaxPacketSize);
if (max = 0) {
dev_dbg(dev-dev
[linux-usb-devel] [PATCH 2/7] USB: add ep-enable
This patch (as944) adds an explicit enabled field to the
usb_host_endpoint structure and uses it in place of the current
mechanism. This is merely a time-space tradeoff; it makes checking
whether URBs may be submitted to an endpoint simpler. The existing
mechanism is efficient when converting urb-pipe to an endpoint
pointer, but it's not so efficient when urb-ep is used instead.
As a side effect, the procedure for enabling an endpoint is now a
little more complicated. The ad-hoc inline code in usb.c and hub.c
for enabling ep0 is now replaced with calls to usb_enable_endpoint,
which is no longer static.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Index: usb-2.6/include/linux/usb.h
===
--- usb-2.6.orig/include/linux/usb.h
+++ usb-2.6/include/linux/usb.h
@@ -52,6 +52,7 @@ struct ep_device;
* @ep_dev: ep_device for sysfs info
* @extra: descriptors following this endpoint in the configuration
* @extralen: how many bytes of extra are valid
+ * @enabled: URBs may be submitted to this endpoint
*
* USB requests are always queued to a given endpoint, identified by a
* descriptor within an active interface in a given USB configuration.
@@ -64,6 +65,7 @@ struct usb_host_endpoint {
unsigned char *extra; /* Extra descriptors */
int extralen;
+ int enabled;
};
/* host-side wrapper for one interface setting's parsed descriptors */
Index: usb-2.6/drivers/usb/core/hcd.c
===
--- usb-2.6.orig/drivers/usb/core/hcd.c
+++ usb-2.6/drivers/usb/core/hcd.c
@@ -1010,7 +1010,6 @@ int usb_hcd_submit_urb (struct urb *urb,
{
int status;
struct usb_hcd *hcd = bus_to_hcd(urb-dev-bus);
- struct usb_host_endpoint *ep;
unsigned long flags;
if (!hcd)
@@ -1027,9 +1026,7 @@ int usb_hcd_submit_urb (struct urb *urb,
// FIXME: verify that quiescing hc works right (RH cleans up)
spin_lock_irqsave(hcd_urb_list_lock, flags);
- ep = (usb_pipein(urb-pipe) ? urb-dev-ep_in : urb-dev-ep_out)
- [usb_pipeendpoint(urb-pipe)];
- if (unlikely(ep != urb-ep))
+ if (unlikely(!urb-ep-enabled))
status = -ENOENT;
else if (unlikely (urb-reject))
status = -EPERM;
Index: usb-2.6/drivers/usb/core/message.c
===
--- usb-2.6.orig/drivers/usb/core/message.c
+++ usb-2.6/drivers/usb/core/message.c
@@ -1006,8 +1006,10 @@ void usb_disable_endpoint(struct usb_dev
ep = dev-ep_in[epnum];
dev-ep_in[epnum] = NULL;
}
- if (ep dev-bus)
+ if (ep) {
+ ep-enabled = 0;
usb_hcd_endpoint_disable(dev, ep);
+ }
}
/**
@@ -1089,23 +1091,21 @@ void usb_disable_device(struct usb_devic
* Resets the endpoint toggle, and sets dev-ep_{in,out} pointers.
* For control endpoints, both the input and output sides are handled.
*/
-static void
-usb_enable_endpoint(struct usb_device *dev, struct usb_host_endpoint *ep)
+void usb_enable_endpoint(struct usb_device *dev, struct usb_host_endpoint *ep)
{
- unsigned int epaddr = ep-desc.bEndpointAddress;
- unsigned int epnum = epaddr USB_ENDPOINT_NUMBER_MASK;
- int is_control;
-
- is_control = ((ep-desc.bmAttributes USB_ENDPOINT_XFERTYPE_MASK)
- == USB_ENDPOINT_XFER_CONTROL);
- if (usb_endpoint_out(epaddr) || is_control) {
+ int epnum = usb_endpoint_num(ep-desc);
+ int is_out = usb_endpoint_dir_out(ep-desc);
+ int is_control = usb_endpoint_xfer_control(ep-desc);
+
+ if (is_out || is_control) {
usb_settoggle(dev, epnum, 1, 0);
dev-ep_out[epnum] = ep;
}
- if (!usb_endpoint_out(epaddr) || is_control) {
+ if (!is_out || is_control) {
usb_settoggle(dev, epnum, 0, 0);
dev-ep_in[epnum] = ep;
}
+ ep-enabled = 1;
}
/*
Index: usb-2.6/drivers/usb/core/hub.c
===
--- usb-2.6.orig/drivers/usb/core/hub.c
+++ usb-2.6/drivers/usb/core/hub.c
@@ -1996,7 +1996,7 @@ static void ep0_reinit(struct usb_device
{
usb_disable_endpoint(udev, 0 + USB_DIR_IN);
usb_disable_endpoint(udev, 0 + USB_DIR_OUT);
- udev-ep_in[0] = udev-ep_out[0] = udev-ep0;
+ usb_enable_endpoint(udev, udev-ep0);
}
#define usb_sndaddr0pipe() (PIPE_CONTROL 30)
Index: usb-2.6/drivers/usb/core/usb.c
===
--- usb-2.6.orig/drivers/usb/core/usb.c
+++ usb-2.6/drivers/usb/core/usb.c
@@ -271,7 +271,7 @@ usb_alloc_dev(struct usb_device *parent,
dev-ep0.desc.bLength = USB_DT_ENDPOINT_SIZE;
dev-ep0.desc.bDescriptorType = USB_DT_ENDPOINT;
/* ep0 maxpacket
[linux-usb-devel] [PATCH 3/7] USB: add direction bit to urb-transfer_flags
This patch (as945) adds a bit to urb-transfer_flags for recording the
direction of the URB. The bit is set/cleared automatically in
usb_submit_urb() so drivers don't have to worry about it (although as
a result, it isn't valid until the URB has been submitted). Inline
routines are added for easily checking an URB's direction. They
replace calls to usb_pipein in the DMA-mapping parts of hcd.c.
For non-control endpoints, the direction is determined directly from
the endpoint descriptor. However control endpoints are
bi-directional; for them the direction is determined from the
bRequestType byte and the wLength value in the setup packet.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Index: usb-2.6/include/linux/usb.h
===
--- usb-2.6.orig/include/linux/usb.h
+++ usb-2.6/include/linux/usb.h
@@ -1028,6 +1028,8 @@ extern int usb_disabled(void);
/*
* urb-transfer_flags:
+ *
+ * Note: URB_DIR_IN/OUT is automatically set in usb_submit_urb().
*/
#define URB_SHORT_NOT_OK 0x0001 /* report short reads as errors */
#define URB_ISO_ASAP 0x0002 /* iso-only, urb-start_frame
@@ -1040,6 +1042,10 @@ extern int usb_disabled(void);
* needed */
#define URB_FREE_BUFFER0x0100 /* Free transfer buffer with
the URB */
+#define URB_DIR_IN 0x0200 /* Transfer from device to host */
+#define URB_DIR_OUT0
+#define URB_DIR_MASK URB_DIR_IN
+
struct usb_iso_packet_descriptor {
unsigned int offset;
unsigned int length;/* expected length */
@@ -1387,6 +1393,30 @@ extern void usb_unanchor_urb(struct urb
extern int usb_wait_anchor_empty_timeout(struct usb_anchor *anchor,
unsigned int timeout);
+/**
+ * usb_urb_dir_in - check if an URB describes an IN transfer
+ * @urb: URB to be checked
+ *
+ * Returns 1 if @urb describes an IN transfer (device-to-host),
+ * otherwise 0.
+ */
+static inline int usb_urb_dir_in(struct urb *urb)
+{
+ return (urb-transfer_flags URB_DIR_MASK) != URB_DIR_OUT;
+}
+
+/**
+ * usb_urb_dir_out - check if an URB describes an OUT transfer
+ * @urb: URB to be checked
+ *
+ * Returns 1 if @urb describes an OUT transfer (host-to-device),
+ * otherwise 0.
+ */
+static inline int usb_urb_dir_out(struct urb *urb)
+{
+ return (urb-transfer_flags URB_DIR_MASK) == URB_DIR_OUT;
+}
+
void *usb_buffer_alloc (struct usb_device *dev, size_t size,
gfp_t mem_flags, dma_addr_t *dma);
void usb_buffer_free (struct usb_device *dev, size_t size,
Index: usb-2.6/drivers/usb/core/urb.c
===
--- usb-2.6.orig/drivers/usb/core/urb.c
+++ usb-2.6/drivers/usb/core/urb.c
@@ -309,7 +309,21 @@ int usb_submit_urb(struct urb *urb, gfp_
* and don't need to duplicate tests
*/
xfertype = usb_endpoint_type(ep-desc);
- is_out = usb_pipeout(urb-pipe);
+ if (xfertype == USB_ENDPOINT_XFER_CONTROL) {
+ struct usb_ctrlrequest *setup =
+ (struct usb_ctrlrequest *) urb-setup_packet;
+
+ if (!setup)
+ return -ENOEXEC;
+ is_out = !(setup-bRequestType USB_DIR_IN) ||
+ !setup-wLength;
+ } else {
+ is_out = usb_endpoint_dir_out(ep-desc);
+ }
+
+ /* Cache the direction for later use */
+ urb-transfer_flags = (urb-transfer_flags ~URB_DIR_MASK) |
+ (is_out ? URB_DIR_OUT : URB_DIR_IN);
if (xfertype != USB_ENDPOINT_XFER_CONTROL
dev-state USB_STATE_CONFIGURED)
@@ -363,7 +377,7 @@ int usb_submit_urb(struct urb *urb, gfp_
/* enforce simple/standard policy */
allowed = (URB_NO_TRANSFER_DMA_MAP | URB_NO_SETUP_DMA_MAP |
- URB_NO_INTERRUPT);
+ URB_NO_INTERRUPT | URB_DIR_MASK);
switch (xfertype) {
case USB_ENDPOINT_XFER_BULK:
if (is_out)
Index: usb-2.6/drivers/usb/core/hcd.c
===
--- usb-2.6.orig/drivers/usb/core/hcd.c
+++ usb-2.6/drivers/usb/core/hcd.c
@@ -995,7 +995,7 @@ static void urb_unlink(struct usb_hcd *h
dma_unmap_single (hcd-self.controller,
urb-transfer_dma,
urb-transfer_buffer_length,
- usb_pipein (urb-pipe)
+ usb_urb_dir_in(urb)
? DMA_FROM_DEVICE
: DMA_TO_DEVICE);
}
@@ -1081,7 +1081,7 @@ int usb_hcd_submit_urb (struct urb *urb,
hcd-self.controller,
urb
[linux-usb-devel] [PATCH 4/7] USB: avoid using urb-pipe in usbcore
This patch (as946) eliminates many of the uses of urb-pipe in
usbcore. Unfortunately there will have to be a significant API
change, affecting all USB drivers, before we can remove it entirely.
This patch contents itself with changing only the interface to
usb_buffer_map_sg() and friends: The pipe argument is replaced with a
direction flag. That can be done easily because those routines get
used in only one place.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Index: usb-2.6/drivers/usb/core/hcd.c
===
--- usb-2.6.orig/drivers/usb/core/hcd.c
+++ usb-2.6/drivers/usb/core/hcd.c
@@ -635,9 +635,9 @@ static int rh_queue_status (struct usb_h
static int rh_urb_enqueue (struct usb_hcd *hcd, struct urb *urb)
{
- if (usb_pipeint (urb-pipe))
+ if (usb_endpoint_xfer_int(urb-ep-desc))
return rh_queue_status (hcd, urb);
- if (usb_pipecontrol (urb-pipe))
+ if (usb_endpoint_xfer_control(urb-ep-desc))
return rh_call_control (hcd, urb);
return -EINVAL;
}
@@ -651,7 +651,7 @@ static int usb_rh_urb_dequeue (struct us
{
unsigned long flags;
- if (usb_pipeendpoint(urb-pipe) == 0) { /* Control URB */
+ if (usb_endpoint_num(urb-ep-desc) == 0) {/* Control URB */
; /* Do nothing */
} else {/* Status URB */
@@ -985,7 +985,7 @@ static void urb_unlink(struct usb_hcd *h
spin_unlock_irqrestore(hcd_urb_list_lock, flags);
if (hcd-self.uses_dma !is_root_hub(urb-dev)) {
- if (usb_pipecontrol (urb-pipe)
+ if (usb_endpoint_xfer_control(urb-ep-desc)
!(urb-transfer_flags URB_NO_SETUP_DMA_MAP))
dma_unmap_single (hcd-self.controller, urb-setup_dma,
sizeof (struct usb_ctrlrequest),
@@ -1068,7 +1068,7 @@ int usb_hcd_submit_urb (struct urb *urb,
* unless it uses pio or talks to another transport.
*/
if (hcd-self.uses_dma) {
- if (usb_pipecontrol (urb-pipe)
+ if (usb_endpoint_xfer_control(urb-ep-desc)
!(urb-transfer_flags URB_NO_SETUP_DMA_MAP))
urb-setup_dma = dma_map_single (
hcd-self.controller,
@@ -1268,11 +1268,13 @@ rescan:
spin_lock(hcd_urb_list_lock);
list_for_each_entry (urb, ep-urb_list, urb_list) {
int tmp;
+ int is_in;
/* the urb may already have been unlinked */
if (urb-status != -EINPROGRESS)
continue;
usb_get_urb (urb);
+ is_in = usb_urb_dir_in(urb);
spin_unlock(hcd_urb_list_lock);
spin_lock (urb-lock);
@@ -1283,19 +1285,25 @@ rescan:
/* kick hcd unless it's already returning this */
if (tmp == -EINPROGRESS) {
- tmp = urb-pipe;
unlink1 (hcd, urb);
dev_dbg (hcd-self.controller,
- shutdown urb %p pipe %08x ep%d%s%s\n,
- urb, tmp, usb_pipeendpoint (tmp),
- (tmp USB_DIR_IN) ? in : out,
- ({ char *s; \
-switch (usb_pipetype (tmp)) { \
-case PIPE_CONTROL: s = ; break; \
-case PIPE_BULK:s = -bulk; break; \
-case PIPE_INTERRUPT: s = -intr; break; \
-default: s = -iso; break; \
- }; s;}));
+ shutdown urb %p ep%d%s%s\n,
+ urb, usb_endpoint_num(ep-desc),
+ is_in ? in : out,
+ ({ char *s;
+
+ switch (usb_endpoint_type(ep-desc)) {
+ case USB_ENDPOINT_XFER_CONTROL:
+ s = ; break;
+ case USB_ENDPOINT_XFER_BULK:
+ s = -bulk; break;
+ case USB_ENDPOINT_XFER_INT:
+ s = -intr; break;
+ default:
+ s = -iso; break;
+ };
+ s;
+ }));
}
usb_put_urb (urb);
Index: usb-2.6/drivers/usb/core/message.c
===
--- usb-2.6.orig/drivers/usb/core/message.c
+++ usb-2.6
[linux-usb-devel] [PATCH 5/7] USB: address-0 handling during device initialization
This patch (as947) changes the device initialization and enumeration
code in hub.c; now udev-devnum will be set to 0 while the device is
being accessed at address 0. Until now this wasn't needed because the
address value was passed as part of urb-pipe; without that field the
device address must be stored elsewhere.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Index: usb-2.6/drivers/usb/core/hub.c
===
--- usb-2.6.orig/drivers/usb/core/hub.c
+++ usb-2.6/drivers/usb/core/hub.c
@@ -1479,6 +1479,7 @@ static int hub_port_reset(struct usb_hub
case 0:
/* TRSTRCY = 10 ms; plus some extra */
msleep(10 + 40);
+ udev-devnum = 0; /* Device now at address 0 */
/* FALL THROUGH */
case -ENOTCONN:
case -ENODEV:
@@ -2002,20 +2003,21 @@ static void ep0_reinit(struct usb_device
#define usb_sndaddr0pipe() (PIPE_CONTROL 30)
#define usb_rcvaddr0pipe() ((PIPE_CONTROL 30) | USB_DIR_IN)
-static int hub_set_address(struct usb_device *udev)
+static int hub_set_address(struct usb_device *udev, int devnum)
{
int retval;
- if (udev-devnum == 0)
+ if (devnum = 1)
return -EINVAL;
if (udev-state == USB_STATE_ADDRESS)
return 0;
if (udev-state != USB_STATE_DEFAULT)
return -EINVAL;
retval = usb_control_msg(udev, usb_sndaddr0pipe(),
- USB_REQ_SET_ADDRESS, 0, udev-devnum, 0,
+ USB_REQ_SET_ADDRESS, 0, devnum, 0,
NULL, 0, USB_CTRL_SET_TIMEOUT);
if (retval == 0) {
+ udev-devnum = devnum; /* Device now using proper address */
usb_set_device_state(udev, USB_STATE_ADDRESS);
ep0_reinit(udev);
}
@@ -2042,6 +2044,7 @@ hub_port_init (struct usb_hub *hub, stru
unsigneddelay = HUB_SHORT_RESET_TIME;
enum usb_device_speed oldspeed = udev-speed;
char*speed, *type;
+ int devnum = udev-devnum;
/* root hub ports have a slightly longer reset period
* (from USB 2.0 spec, section 7.1.7.5)
@@ -2071,7 +2074,7 @@ hub_port_init (struct usb_hub *hub, stru
goto fail;
}
oldspeed = udev-speed;
-
+
/* USB 2.0 section 5.5.3 talks about ep0 maxpacket ...
* it's fixed size except for full speed devices.
* For Wireless USB devices, ep0 max packet is always 512 (tho
@@ -2112,7 +2115,7 @@ hub_port_init (struct usb_hub *hub, stru
dev_info (udev-dev,
%s %s speed %sUSB device using %s and address %d\n,
(udev-config) ? reset : new, speed, type,
- udev-bus-controller-driver-name, udev-devnum);
+ udev-bus-controller-driver-name, devnum);
/* Set up TT records, if needed */
if (hdev-tt) {
@@ -2199,7 +2202,7 @@ hub_port_init (struct usb_hub *hub, stru
}
for (j = 0; j SET_ADDRESS_TRIES; ++j) {
- retval = hub_set_address(udev);
+ retval = hub_set_address(udev, devnum);
if (retval = 0)
break;
msleep(200);
@@ -2207,7 +2210,7 @@ hub_port_init (struct usb_hub *hub, stru
if (retval 0) {
dev_err(udev-dev,
device not accepting address %d, error %d\n,
- udev-devnum, retval);
+ devnum, retval);
goto fail;
}
@@ -2260,8 +2263,10 @@ hub_port_init (struct usb_hub *hub, stru
retval = 0;
fail:
- if (retval)
+ if (retval) {
hub_port_disable(hub, port1, 0);
+ udev-devnum = devnum; /* for disconnect processing */
+ }
mutex_unlock(usb_address0_mutex);
return retval;
}
Index: usb-2.6/drivers/usb/core/urb.c
===
--- usb-2.6.orig/drivers/usb/core/urb.c
+++ usb-2.6/drivers/usb/core/urb.c
@@ -284,9 +284,7 @@ int usb_submit_urb(struct urb *urb, gfp_
if (!urb || urb-hcpriv || !urb-complete)
return -EINVAL;
- if (!(dev = urb-dev) ||
- (dev-state USB_STATE_DEFAULT) ||
- (!dev-bus) || (dev-devnum = 0))
+ if (!(dev = urb-dev) || dev-state USB_STATE_DEFAULT)
return -ENODEV;
if (dev-bus-controller-power.power_state.event != PM_EVENT_ON
|| dev-state == USB_STATE_SUSPENDED)
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log
[linux-usb-devel] [PATCH 6/7] USB: avoid urb-pipe in usbfs
This patch (as948) removes most of the references to urb-pipe from
the usbfs routines in devio.c. The one tricky aspect is in
snoop_urb(), which can be called before the URB is submitted and which
uses usb_urb_dir_in(). For this to work properly, the URB's direction
flag must be set manually in proc_do_submiturb().
The patch also fixes a minor bug; the wValue, wIndex, and wLength
fields were snooped in proc_do_submiturb() without conversion from
le16 to CPU-byte-ordering.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Index: usb-2.6/drivers/usb/core/devio.c
===
--- usb-2.6.orig/drivers/usb/core/devio.c
+++ usb-2.6/drivers/usb/core/devio.c
@@ -289,10 +289,8 @@ static void snoop_urb(struct urb *urb, v
if (!usbfs_snoop)
return;
- if (urb-pipe USB_DIR_IN)
- dev_info(urb-dev-dev, direction=IN\n);
- else
- dev_info(urb-dev-dev, direction=OUT\n);
+ dev_info(urb-dev-dev, direction=%s\n,
+ usb_urb_dir_in(urb) ? IN : OUT);
dev_info(urb-dev-dev, userurb=%p\n, userurb);
dev_info(urb-dev-dev, transfer_buffer_length=%d\n,
urb-transfer_buffer_length);
@@ -910,6 +908,7 @@ static int proc_do_submiturb(struct dev_
struct usb_ctrlrequest *dr = NULL;
unsigned int u, totlen, isofrmlen;
int ret, ifnum = -1;
+ int is_in;
if (uurb-flags ~(USBDEVFS_URB_ISO_ASAP|USBDEVFS_URB_SHORT_NOT_OK|
URB_NO_FSBR|URB_ZERO_PACKET))
@@ -924,16 +923,18 @@ static int proc_do_submiturb(struct dev_
if ((ret = checkintf(ps, ifnum)))
return ret;
}
- if ((uurb-endpoint USB_ENDPOINT_DIR_MASK) != 0)
- ep = ps-dev-ep_in [uurb-endpoint USB_ENDPOINT_NUMBER_MASK];
- else
- ep = ps-dev-ep_out [uurb-endpoint
USB_ENDPOINT_NUMBER_MASK];
+ if ((uurb-endpoint USB_ENDPOINT_DIR_MASK) != 0) {
+ is_in = 1;
+ ep = ps-dev-ep_in[uurb-endpoint USB_ENDPOINT_NUMBER_MASK];
+ } else {
+ is_in = 0;
+ ep = ps-dev-ep_out[uurb-endpoint USB_ENDPOINT_NUMBER_MASK];
+ }
if (!ep)
return -ENOENT;
switch(uurb-type) {
case USBDEVFS_URB_TYPE_CONTROL:
- if ((ep-desc.bmAttributes USB_ENDPOINT_XFERTYPE_MASK)
- != USB_ENDPOINT_XFER_CONTROL)
+ if (!usb_endpoint_xfer_control(ep-desc))
return -EINVAL;
/* min 8 byte setup packet, max 8 byte setup plus an arbitrary
data stage */
if (uurb-buffer_length 8 || uurb-buffer_length (8 +
MAX_USBFS_BUFFER_SIZE))
@@ -952,23 +953,32 @@ static int proc_do_submiturb(struct dev_
kfree(dr);
return ret;
}
- uurb-endpoint = (uurb-endpoint ~USB_ENDPOINT_DIR_MASK) |
(dr-bRequestType USB_ENDPOINT_DIR_MASK);
uurb-number_of_packets = 0;
uurb-buffer_length = le16_to_cpup(dr-wLength);
uurb-buffer += 8;
- if (!access_ok((uurb-endpoint USB_DIR_IN) ? VERIFY_WRITE :
VERIFY_READ, uurb-buffer, uurb-buffer_length)) {
+ if ((dr-bRequestType USB_DIR_IN) uurb-buffer_length) {
+ is_in = 1;
+ uurb-endpoint |= USB_DIR_IN;
+ } else {
+ is_in = 0;
+ uurb-endpoint = ~USB_DIR_IN;
+ }
+ if (!access_ok(is_in ? VERIFY_WRITE : VERIFY_READ,
+ uurb-buffer, uurb-buffer_length)) {
kfree(dr);
return -EFAULT;
}
snoop(ps-dev-dev, control urb: bRequest=%02x
bRrequestType=%02x wValue=%04x
wIndex=%04x wLength=%04x\n,
- dr-bRequest, dr-bRequestType, dr-wValue,
- dr-wIndex, dr-wLength);
+ dr-bRequest, dr-bRequestType,
+ __le16_to_cpup(dr-wValue),
+ __le16_to_cpup(dr-wIndex),
+ __le16_to_cpup(dr-wLength));
break;
case USBDEVFS_URB_TYPE_BULK:
- switch (ep-desc.bmAttributes USB_ENDPOINT_XFERTYPE_MASK) {
+ switch (usb_endpoint_type(ep-desc)) {
case USB_ENDPOINT_XFER_CONTROL:
case USB_ENDPOINT_XFER_ISOC:
return -EINVAL;
@@ -977,7 +987,8 @@ static int proc_do_submiturb(struct dev_
uurb-number_of_packets = 0;
if (uurb-buffer_length MAX_USBFS_BUFFER_SIZE)
return -EINVAL;
- if (!access_ok((uurb-endpoint USB_DIR_IN) ? VERIFY_WRITE :
VERIFY_READ, uurb-buffer, uurb-buffer_length
[linux-usb-devel] [PATCH 7/7] USB: avoid urb-pipe in usbmon
This patch (as949) changes the usbmon driver to use the new urb-ep
field rather than urb-pipe.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
cc: Pete Zaitcev [EMAIL PROTECTED]
---
Index: usb-2.6/drivers/usb/mon/mon_bin.c
===
--- usb-2.6.orig/drivers/usb/mon/mon_bin.c
+++ usb-2.6/drivers/usb/mon/mon_bin.c
@@ -354,7 +354,7 @@ static inline char mon_bin_get_setup(uns
const struct urb *urb, char ev_type)
{
- if (!usb_pipecontrol(urb-pipe) || ev_type != 'S')
+ if (!usb_endpoint_xfer_control(urb-ep-desc) || ev_type != 'S')
return '-';
if (urb-dev-bus-uses_dma
@@ -410,7 +410,7 @@ static void mon_bin_event(struct mon_rea
if (length = rp-b_size/5)
length = rp-b_size/5;
- if (usb_pipein(urb-pipe)) {
+ if (usb_urb_dir_in(urb)) {
if (ev_type == 'S') {
length = 0;
data_tag = '';
@@ -440,10 +440,22 @@ static void mon_bin_event(struct mon_rea
*/
memset(ep, 0, PKT_SIZE);
ep-type = ev_type;
- ep-xfer_type = usb_pipetype(urb-pipe);
- /* We use the fact that usb_pipein() returns 0x80 */
- ep-epnum = usb_pipeendpoint(urb-pipe) | usb_pipein(urb-pipe);
- ep-devnum = usb_pipedevice(urb-pipe);
+ switch (usb_endpoint_type(urb-ep-desc)) {
+ case USB_ENDPOINT_XFER_CONTROL:
+ ep-xfer_type = PIPE_CONTROL;
+ break;
+ case USB_ENDPOINT_XFER_BULK:
+ ep-xfer_type = PIPE_BULK;
+ break;
+ case USB_ENDPOINT_XFER_INT:
+ ep-xfer_type = PIPE_INTERRUPT;
+ break;
+ default:
+ ep-xfer_type = PIPE_ISOCHRONOUS;
+ break;
+ }
+ ep-epnum = urb-ep-desc.bEndpointAddress;
+ ep-devnum = urb-dev-devnum;
ep-busnum = urb-dev-bus-busnum;
ep-id = (unsigned long) urb;
ep-ts_sec = ts.tv_sec;
@@ -500,10 +512,22 @@ static void mon_bin_error(void *data, st
memset(ep, 0, PKT_SIZE);
ep-type = 'E';
- ep-xfer_type = usb_pipetype(urb-pipe);
- /* We use the fact that usb_pipein() returns 0x80 */
- ep-epnum = usb_pipeendpoint(urb-pipe) | usb_pipein(urb-pipe);
- ep-devnum = usb_pipedevice(urb-pipe);
+ switch (usb_endpoint_type(urb-ep-desc)) {
+ case USB_ENDPOINT_XFER_CONTROL:
+ ep-xfer_type = PIPE_CONTROL;
+ break;
+ case USB_ENDPOINT_XFER_BULK:
+ ep-xfer_type = PIPE_BULK;
+ break;
+ case USB_ENDPOINT_XFER_INT:
+ ep-xfer_type = PIPE_INTERRUPT;
+ break;
+ default:
+ ep-xfer_type = PIPE_ISOCHRONOUS;
+ break;
+ }
+ ep-epnum = urb-ep-desc.bEndpointAddress;
+ ep-devnum = urb-dev-devnum;
ep-busnum = urb-dev-bus-busnum;
ep-id = (unsigned long) urb;
ep-status = error;
Index: usb-2.6/drivers/usb/mon/mon_main.c
===
--- usb-2.6.orig/drivers/usb/mon/mon_main.c
+++ usb-2.6/drivers/usb/mon/mon_main.c
@@ -154,8 +154,8 @@ static void mon_complete(struct usb_bus
* This should not happen.
* At this point we do not even know the bus number...
*/
- printk(KERN_ERR TAG : Null mon bus in URB, pipe 0x%x\n,
- urb-pipe);
+ printk(KERN_ERR TAG : Null mon bus in URB, address %p\n,
+ urb);
return;
}
Index: usb-2.6/drivers/usb/mon/mon_text.c
===
--- usb-2.6.orig/drivers/usb/mon/mon_text.c
+++ usb-2.6/drivers/usb/mon/mon_text.c
@@ -50,10 +50,12 @@ struct mon_iso_desc {
struct mon_event_text {
struct list_head e_link;
int type; /* submit, complete, etc. */
- unsigned int pipe; /* Pipe */
unsigned long id; /* From pointer, most of the time */
unsigned int tstamp;
+ int xfertype;
int busnum;
+ int devnum;
+ int epnum;
int length; /* Depends on type: xfer length or act length */
int status;
int interval;
@@ -61,6 +63,7 @@ struct mon_event_text {
int error_count;
char setup_flag;
char data_flag;
+ char is_in;
int numdesc;/* Full number */
struct mon_iso_desc isodesc[ISODESC_MAX];
unsigned char setup[SETUP_MAX];
@@ -121,7 +124,7 @@ static inline char mon_text_get_setup(st
struct urb *urb, char ev_type, struct mon_bus *mbus)
{
- if (!usb_pipecontrol(urb-pipe) || ev_type != 'S')
+ if (ep-xfertype != USB_ENDPOINT_XFER_CONTROL || ev_type != 'S')
return '-';
if (urb-dev-bus-uses_dma
@@ -138,14 +141,12 @@ static inline char mon_text_get_setup(st
static
Re: [linux-usb-devel] Can't unload uhci_hcd module with 2.6.22 -- also oops
On Mon, 30 Jul 2007, Gabriel C wrote: A. Kalten wrote: [ added usb peoples to CC ] Hello, To send a fax using an external usb modem, I do the following: modprobe uhci-hcd modprobe cdc-acm mount -t usbfs none /proc/bus/usb Then I send the fax. However, when I attempt to unload the modules by reversing the above steps, then uhci_hcd module will not unload: [/]# rmmod uhci-hcd ERROR: Removing 'uhci_hcd': Device or resource busy Using lsof to list all open files gives the following: ksuspend_ 766 root cwd DIR8,1 456 2 / ksuspend_ 766 root rtd DIR8,1 456 2 / ksuspend_ 766 root txt unknown /proc/766/exe khubd 769 root cwd DIR8,1 456 2 / khubd 769 root rtd DIR8,1 456 2 / khubd 769 root txt unknown /proc/769/exe I cannot terminate these processes. You're not supposed to be able to terminate them. Also, the kernel log shows an oops: kernel: usbcore: deregistering interface driver cdc_acm kernel: uhci_hcd :00:1d.3: remove, state 1 kernel: usb usb4: USB disconnect, address 1 kernel: uhci_hcd :00:1d.3: USB bus 4 deregistered kernel: ACPI: PCI interrupt for device :00:1d.3 disabled kernel: uhci_hcd :00:1d.2: remove, state 1 kernel: usb usb3: USB disconnect, address 1 kernel: uhci_hcd :00:1d.2: USB bus 3 deregistered kernel: ACPI: PCI interrupt for device :00:1d.2 disabled kernel: uhci_hcd :00:1d.1: remove, state 1 kernel: usb usb2: USB disconnect, address 1 kernel: usb 2-2: USB disconnect, address 2 kernel: Unable to handle kernel paging request at 88040440 RIP: kernel: [sysfs_get_name+46/65] sysfs_get_name+0x2e/0x41 kernel: PGD 203067 PUD 205063 PMD 7a6b2067 PTE 0 kernel: Oops: [1] SMP kernel: CPU 1 kernel: Modules linked in: uhci_hcd usbcore af_packet skge bitrev crc32 kernel: Pid: 1123, comm: rmmod Not tainted 2.6.22 #3 kernel: RIP: 0010:[sysfs_get_name+46/65] [sysfs_get_name+46/65] sysfs_get_name+0x2e/0x41 kernel: RSP: 0018:81006edd5ce0 EFLAGS: 00010246 kernel: RAX: 88040440 RBX: 81006fbb68e0 RCX: kernel: RDX: 0004 RSI: 80423b38 RDI: 81006fbb6b88 kernel: RBP: 81006fbb6b88 R08: R09: 8000 kernel: R10: 0080 R11: 80330606 R12: 81006fbb6b90 kernel: R13: 81006f414c78 R14: 80423b38 R15: 8803b940 kernel: FS: 2b93765b76f0() GS:810002f4d140() knlGS: kernel: CS: 0010 DS: ES: CR0: 8005003b kernel: CR2: 88040440 CR3: 6f5e5000 CR4: 06e0 kernel: Process rmmod (pid: 1123, threadinfo 81006edd4000, task 81006e48ae40) kernel: Stack: 8029b6dd 81006fbb0420 81006fbb05a0 8100784a9800 kernel: 81006fbb0510 8100784a9888 80330986 81006fbb0400 kernel: 81006fbb0400 81006fbb0420 80330b95 81006fbb0400 kernel: Call Trace: kernel: [sysfs_hash_and_remove+104/295] sysfs_hash_and_remove+0x68/0x127 kernel: [device_remove_file+37/58] device_remove_file+0x25/0x3a kernel: [device_del+375/704] device_del+0x177/0x2c0 kernel: [_end+129064639/2131730856] :usbcore:usb_disable_device+0x8c/0x106 kernel: [_end+129049073/2131730856] :usbcore:usb_disconnect+0x98/0xee kernel: [_end+129049053/2131730856] :usbcore:usb_disconnect+0x84/0xee kernel: [_end+129057037/2131730856] :usbcore:usb_remove_hcd+0x85/0xe1 kernel: [_end+129097874/2131730856] :usbcore:usb_hcd_pci_remove+0x1d/0x89 kernel: [pci_device_remove+36/77] pci_device_remove+0x24/0x4d kernel: [__device_release_driver+130/184] __device_release_driver+0x82/0xb8 kernel: [driver_detach+252/261] driver_detach+0xfc/0x105 kernel: [bus_remove_driver+122/157] bus_remove_driver+0x7a/0x9d kernel: [pci_unregister_driver+16/129] pci_unregister_driver+0x10/0x81 kernel: [_end+129186684/2131730856] :uhci_hcd:uhci_hcd_cleanup+0x10/0x2c kernel: [sys_delete_module+319/444] sys_delete_module+0x13f/0x1bc kernel: [__up_write+29/318] __up_write+0x1d/0x13e kernel: [system_call+126/131] system_call+0x7e/0x83 kernel: kernel: kernel: Code: 48 8b 00 c3 83 fa 20 74 f7 31 c0 0f 1f 00 c3 0f 0b eb fe 41 kernel: RIP [sysfs_get_name+46/65] sysfs_get_name+0x2e/0x41 kernel: RSP 81006edd5ce0 kernel: CR2: 88040440 My system is Intel Pentium D dual core with Asus P5WD2 motherboard. Does this patch help? http://article.gmane.org/gmane.linux.kernel/556682/raw Alan Stern - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find
Re: [linux-usb-devel] Large USB storage devices cause df to hang and cpu load reaches 100%
On Mon, 30 Jul 2007, 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. Turn on CONFIG_USB_DEBUG and then check the output from dmesg after running the df program. If it shows something peculiar then you should try using usbmon. Instructions are in the kernel source file Documentation/usb/usbmon.txt. If all else fails, you can install Git and use bisection on the set of kernel versions between 2.6.21 and 2.6.22, to find which patch caused the odd behavior to start. Alan Stern - 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] ehci problem triggerable by storage
On Sat, 28 Jul 2007, David Brownell wrote: On Friday 27 July 2007, Alan Stern wrote: stressing a flash disk I rapidly get this error: Jul 27 12:35:00 oenone kernel: ehci_hcd :00:02.2: devpath 3.4 ep1in 3strikes Jul 27 12:35:00 oenone kernel: usb-storage: Status code -71; transferred 8192/122880 Is there a way I can enable more debugging about this cause of -EPROTO? dbg_qh() and friends ... but it probably won't say anything much. If it's that reproducible, I suggest you get some kind of USB analyser and throw it at the problem. Notice how it happened rather promptly at the start of a new page; and likely at the start of a new qTD. Yep. That seems to be common among these errors, which is a little odd since you might expect them to occur at arbitrary 512-byte packet boundaries unless they were caused by a problem in the host controller hardware. But maybe device controllers also divide the data stream up into 4-KB chunks... In my experience this sort of thing tends to be caused by low-level hardware communications errors. Noise in the USB data lines or a missing handshake packet, stuff like that. Not much extra debugging can be done; the 3strikes indication comes directly from the controller hardware. Well, that's one theory. In a few cases it has been positively proven. Thing is, this kind of problem happens more often than it should. True. In many other cases nobody was ever able to determine the cause of the problem. In fact, it wouldn't be surprising if there were many different causes. No matter what causes it, it'd be better to recover from it ... or prevent it from happening. My theory has been different: that some USB peripherals get deeply confused if Linux talks to them too fast (i.e. probably anything faster than MS-Windows). Notice how the recovery that followed involved a device reset. The device reset is the normal recovery procedure used by usb-storage. It would occur regardless of what caused the -EPROTO error; it doesn't give any direct information about what has happened inside the device. However it is possible to test the too fast theory to some extent. All that's needed is an unusual_devs entry with the US_FL_GO_SLOW flag. But -- never actually having had both a highspeed USB sniffer *AND* hardware exhibiting this problem in the same place -- I've not been able to test that theory. It sure would be good if somebody could do this. But high-speed USB analyzers aren't easy to come by, alas. Alan Stern - 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] usb-storage autosuspend bug?
On Fri, 27 Jul 2007, Oliver Neukum wrote: Am Donnerstag 26 Juli 2007 schrieb Greg KH: Alan and Oliver, was this caused by the autosuspend changes for usb-storage? The oops itself looks like refcounting. What caused the initial io error does not become clear from the log. It is possible that the device cannot stand suspension. But there's no evidence from that. On the contrary, these devices usually do an unplug/plug cycle, which is not in the log. I don't think it's a refcounting problem. My guess is that the underlying cause is the bug in your urb-status removal patch for usb_start_wait_urb() -- the one I fixed here: http://marc.info/?l=linux-usb-develm=118531582013355w=2 Of course, my guess could be wrong. I haven't tried to recreate Linus's bug with that patch reverted. But with the patch present I was not able to duplicate the bug. Alan Stern - 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] About current state of supporting USB selective suspend feature
On Fri, 27 Jul 2007, gutian abei wrote: Dear All: I am trying to develop a USB device driver in Linux platform. I want to know the current state of supporting USB selective suspend feature of Linux USB core. This feature is described by USB specification 2.0. The USB core supports selective suspend (also known as runtime suspend or autosuspend). However individual USB device drivers must also include support, which means the driver must implement at least a suspend() and a resume() method, and it must set the .supports_autosuspend flag in its usb_driver structure. It also must call usb_autopm_get_interface() and usb_autopm_put_interface() at the appropriate times. There's a lot of documention in the comments in drivers/usb/core/driver.c. Alan Stern - 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] ehci problem triggerable by storage
On Fri, 27 Jul 2007, Oliver Neukum wrote: Hi, stressing a flash disk I rapidly get this error: Jul 27 12:35:00 oenone kernel: ehci_hcd :00:02.2: devpath 3.4 ep1in 3strikes Jul 27 12:35:00 oenone kernel: usb-storage: Status code -71; transferred 8192/122880 Is there a way I can enable more debugging about this cause of -EPROTO? In my experience this sort of thing tends to be caused by low-level hardware communications errors. Noise in the USB data lines or a missing handshake packet, stuff like that. Not much extra debugging can be done; the 3strikes indication comes directly from the controller hardware. It's possible that a CPU speed transition could interfere with DMA during a transfer. You could see if disabling CPU_FREQ makes any difference. Alan Stern - 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] force USB_SPEED_FULL for device
On Fri, 27 Jul 2007, Gabriel Maganis wrote: On 7/27/07, Pete Zaitcev [EMAIL PROTECTED] wrote: On Fri, 27 Jul 2007 11:29:07 -0700, Gabriel Maganis [EMAIL PROTECTED] wrote: Thanks for the help below. I am trying to answer what will the keyboard send me if I send it a packet configured over USB_SPEED_FULL?. Simply setting usb_device-speed to USB_SPEED_FULL doesn't work as the packet does not even get sent by the subsystem/hcd. How do you know that the packet is not sent? The EPROTO you are getting is what happens when packet IS sent and gets no reply. -- Pete P.S. Gmail is not a valid excuse for top-posting. I have one of those protocol analyzers in between and it doesn't see anything. I tried to look for where the EPROTO is being returned from but grep -r doesn give me relevant results. I also looked at the sanity checks in submit_urb but I don't think any are doing anything about the speed. Would you know which file would contain the lowest level routine that sends the packets? A more important question is: Why do you want to change usb_device-speed from USB_SPEED_LOW to USB_SPEED_FULL? Was there something wrong with the USB_SPEED_LOW setting? Alan Stern - 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] force USB_SPEED_FULL for device
On Fri, 27 Jul 2007, Gabriel Maganis wrote: A more important question is: Why do you want to change usb_device-speed from USB_SPEED_LOW to USB_SPEED_FULL? Was there something wrong with the USB_SPEED_LOW setting? Alan Stern Hello Alan, I would just like to know what response (if at all, garbage, or meaningful) it would give me if I send it a packet at USB_SPEED_FULL. Do I also need to change some fields in the usb_device structure? I tried changing the ep0.desc.wMaxPacketSize to match a device configured at full speed but it didn't work also. But why? If you have a low-speed device like a keyboard and you send it a packet at full-speed, the device won't be able to receive the packet. Hence it won't send a reply, at any speed. There's no need to actually do a test; it can't possibly work. Alan Stern - 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] force USB_SPEED_FULL for device
On Fri, 27 Jul 2007, Gabriel Maganis wrote: Hello Alan, I guess I'm trying to bypass the code that makes it so it can't possibly work. I'm trying not to say what it is I'm trying to do in general I guess :). But I really would just like to be able to send that packet. Would you know if the code I might look at is in usbcore or should I look at the HCD code? I've tried grepping around quite a bit but I'm not sure what it is really I should look for. It isn't code at all -- it won't work because of the hardware! The low-speed keyboard's USB interface hardware is looking for signals at 1.5 MHz. If the computer starts sending full-speed data, it will be modulated at 12 MHz. Furthermore, at low-speed a 0 is indicated by a high voltage on the D- line whereas at full-speed a 0 is indicated by a high voltage on the D+ line. (Or maybe I have them reversed, but one is definitely the opposite of the other.) The keyboard's hardware can't possible cope with that. Alan Stern - 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] Usb serial gadget driver bug?
On Thu, 26 Jul 2007 [EMAIL PROTECTED] wrote: 1. SET_LINE_CODING handling in gs_setup_class() copies req-buf to its port_line_coding struct but data stage has not been reached yet. Have you considered mentioning this to the author or maintainer of that driver? 2. generic question on setup handling by gadget drivers: You mean Control transfer handling. Your question is about the Status stage, not the Setup stage. For setup-data-ack sequence, is ack to be generated by the controller driver always? No; only if the request is valid and is carried out successfully. What if it is data-out and the settings cannot be supported by the gadget for whatever reason, how does it inform the controller driver? You can set the Halt feature on ep0 in the data-out completion routine. (See 8.5.3.1 and Table 8-7 in the USB 2.0 spec.) Some controller drivers might not support this, though. Alan Stern - 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
