Re: [linux-usb-devel] autosuspend for HID devices, take #4
On Wed, 23 May 2007, Oliver Neukum wrote: I will debug. Maybe just this particular keyboard is clumsy. I will try with various different hardware. But if there are lots of HID hardware out there which expose this broken behavior, it would be bad. No, I cannot replicate this. I see all keys. I suspect it is keyboard-dependent. For example, the keyboard's internal buffer might be able to hold no more than one event, because the designers expected the host to poll frequently. Since the polling can't occur during the wakeup interval, multiple events from that time will get lost. It wouldn't be surprising to find lots of USB HID devices suffering from this kind of problem. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] anchors and their use
On Wed, 23 May 2007, Oliver Neukum wrote:
OK, these are fixed and the timeout given in milliseconds, as David
recommended.
I looked into the inlining issue and the inlined version wins in terms
of size.
@@ -1270,6 +1287,11 @@ extern struct urb *usb_get_urb(struct ur
extern int usb_submit_urb(struct urb *urb, gfp_t mem_flags);
extern int usb_unlink_urb(struct urb *urb);
extern void usb_kill_urb(struct urb *urb);
+extern void usb_kill_anchored_urbs(struct usb_anchor *anchor);
+extern void usb_anchor_urb(struct urb *urb, struct usb_anchor *anchor);
+extern void usb_unanchor_urb(struct urb *urb);
+extern int usb_wait_anchor_empty_timeout
+(struct usb_anchor *anchor, unsigned long timeout);
Suspicious line break.
+int usb_wait_anchor_empty_timeout(struct usb_anchor *anchor, unsigned long
timeout)
+{
+ int res;
+
+ res = wait_event_timeout(anchor-wait, list_empty(anchor-urb_list),
timeout * HZ / 1000);
What's wrong with msecs_to_jiffies()?
Ironically, it wants its argument to be an unsigned int!
Alan Stern
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for HID devices, take #2
On Wed, 23 May 2007, Oliver Neukum wrote: That gives me an idea. Resumption of a device has to be done in task context. So if I allocate a private freezable work queue for HID resumption, the freezer would guard against illicit resumptions, wouldn't it? You can use the ksuspend_usb_wq workqueue. It already exists, is freezable, and is used for suspending and resuming USB devices. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] anchors and their use
On Wed, 23 May 2007, Oliver Neukum wrote: +extern int usb_wait_anchor_empty_timeout +(struct usb_anchor *anchor, unsigned long timeout); Suspicious line break. This is what I get when I want to keep the 80 column limit. I would write it like this: extern int usb_wait_anchor_empty_timeout(struct usb_anchor *anchor, unsigned long timeout); Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for HID devices, take #4
On Wed, 23 May 2007, Jiri Kosina wrote: On Wed, 23 May 2007, Alan Stern wrote: I suspect it is keyboard-dependent. For example, the keyboard's internal buffer might be able to hold no more than one event, because the designers expected the host to poll frequently. Since the polling can't occur during the wakeup interval, multiple events from that time will get lost. Hi Alan, in such situation, I'd however expect the first N events to be lost, but the last events to arrive without problem. What I am experiencing, however, is that the missing events are usually the middle ones. It depends on how the buffer is implemented. It might work this way: The first keystroke is detected, goes into the buffer, and causes a remote wakeup request to be sent. Later keystrokes can't go into the buffer because the buffer is still full, so they are dropped. When the resume sequence is complete, the host reads the original keystroke and the buffer is once again empty. Hence any further keystrokes are processed as usual. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.22-rc2-mm1
On Wed, 23 May 2007, Andrew Morton wrote: This is intermittently getting resume-from-RAM failures. It is not sufficiently repeatable to be able to bisect. [ 1381.119362] PM: Preparing system for mem sleep [ 2331.798452] Stopping tasks ... [ 2351.760431] Stopping kernel threads timed out after 20 seconds (2 tasks refusing to freeze): [ 2351.762385] ksuspend_usbd [ 2351.764374] khubd [ 2351.766338] Restarting tasks ... done. Hmm, that seems to be related to usb-fix-suspend-to-ram.patch (probably one of the threads is waiting for a completion by some other thread that has been frozen already). Is it possible to get an Alt-SysRq-T stack trace during those 20 seconds? Knowing what those threads are waiting for would be a big help. The trace is at http://userweb.kernel.org/~akpm/tasks.txt. Interesting bits are [ 144.201264] khubd D 0045 0 160 2 (L-TLB) [ 144.204358]c207fe78 0046 90399a85 0045 0246 c207fe60 c25b0cc4 c206f4cc [ 144.204539]0286 769e4cea 004a 90399a85 0045 c32713c0 c207fed4 [ 144.207754]0001 c207fe94 c207febc c02e8e1b [ 144.210934] Call Trace: [ 144.217012] [c02e8e1b] wait_for_completion+0x68/0x91 [ 144.220090] [c011824f] default_wake_function+0x0/0x9 [ 144.223158] [c0127a41] flush_cpu_workqueue+0x4d/0x55 [ 144.226223] [c0127a69] wq_barrier_func+0x0/0x8 [ 144.229269] [c026343d] usb_release_dev+0x28/0x63 [ 144.232340] [c0233011] device_release+0x37/0x7c [ 144.235431] [c01cb6c7] kobject_cleanup+0x3d/0x54 [ 144.238520] [c01cb6de] kobject_release+0x0/0x8 [ 144.241631] [c01cc2a7] kref_put+0x75/0x82 [ 144.244699] [c0265482] hub_thread+0x376/0xa74 [ 144.247768] [c01180c2] pick_next_task_fair+0xf2/0x12a [ 144.250815] [c0116af1] __wake_up_common+0x31/0x4f [ 144.253864] [c012a259] autoremove_wake_function+0x0/0x35 [ 144.256902] [c026510c] hub_thread+0x0/0xa74 [ 144.259944] [c012a102] kthread+0x36/0x5c [ 144.262891] [c012a0cc] kthread+0x0/0x5c [ 144.265757] [c010464b] kernel_thread_helper+0x7/0x10 [ 144.268716] === [ 144.137704] ksuspend_usbd D 0045 0 157 2 (L-TLB) [ 144.140830]c2085f18 0046 9072767a 0045 c20626f0 c010449b c3182118 c206288c [ 144.141011]c3182120 c3182120 76d728df 004a 9072767a 0045 c3271200 c3182118 [ 144.144263]c3182120 0246 c20626f0 c02ea1c9 [ 144.147576] Call Trace: [ 144.153929] [c010449b] common_interrupt+0x23/0x28 [ 144.157245] [c02ea1c9] __down+0xba/0xc6 [ 144.160528] [c011824f] default_wake_function+0x0/0x9 [ 144.163832] [c02664fc] hcd_resume_work+0x0/0x43 [ 144.167126] [c02e9fd3] __down_failed+0x7/0xc [ 144.170372] [c0266518] hcd_resume_work+0x1c/0x43 [ 144.173603] [c01278cf] run_workqueue+0x6d/0xdf [ 144.176780] [c0127b4c] worker_thread+0x0/0xd0 [ 144.179885] [c0127b4c] worker_thread+0x0/0xd0 [ 144.182930] [c0127c12] worker_thread+0xc6/0xd0 [ 144.185964] [c012a259] autoremove_wake_function+0x0/0x35 [ 144.189056] [c012a102] kthread+0x36/0x5c [ 144.192118] [c012a0cc] kthread+0x0/0x5c [ 144.195153] [c010464b] kernel_thread_helper+0x7/0x10 Okay, it's clear that the two threads are in deadlock. It's not clear how the deadlock arose to begin with -- apparently there was a remote wakeup request for a root hub at the same time as a device below that root hub was disconnected, which doesn't make much sense. Anyway, this looks like a good place to use cancel_work_sync(). The patch below is highly untested, so Andrew, you're the guinea pig. :-) If it seems to help, I'll submit it with a proper Changelog entry. 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 @@ -1294,6 +1294,7 @@ void usb_disconnect(struct usb_device ** *pdev = NULL; spin_unlock_irq(device_state_lock); +#ifdef CONFIG_USB_SUSPEND /* Synchronize with the ksuspend thread to prevent any more * autosuspend requests from being submitted, and decrement * the parent's count of unsuspended children. @@ -1303,6 +1304,10 @@ void usb_disconnect(struct usb_device ** usb_autosuspend_device(udev-parent); usb_pm_unlock(udev); + cancel_delayed_work(udev-autosuspend); + cancel_work_sync(udev-autosuspend.work); +#endif + put_device(udev-dev); } 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 @@ -184,10 +184,6 @@ static void usb_release_dev(struct devic udev = to_usb_device(dev); -#ifdef CONFIG_USB_SUSPEND
Re: [linux-usb-devel] 2.6.22-rc2-mm1
On Wed, 23 May 2007, Oleg Nesterov wrote:
On 05/23, Alan Stern wrote:
Okay, it's clear that the two threads are in deadlock. It's not clear
how the deadlock arose to begin with -- apparently there was a remote
wakeup request for a root hub at the same time as a device below that
root hub was disconnected, which doesn't make much sense.
Please note that this flush_workqueue() was not safe anyway. We are freezing
tasks, and ksuspend_usb_wq is freezeable. So, it could be frozen before
khubd task, and we have another deadlock.
Correct. I was planning to replace the flush_workqueue() anyway for
that very reason; this is a good excuse to do it.
Anyway, this looks like a good place to use cancel_work_sync(). The
Could you use cancel_rearming_delayed_work() ? (It should be renamed to
cancel_delayed_work_sync()).
Good idea. Here's a revised patch.
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
@@ -1228,6 +1228,30 @@ static void release_address(struct usb_d
}
}
+#ifdef CONFIG_USB_SUSPEND
+
+static void usb_stop_pm(struct usb_device *udev)
+{
+ /* Synchronize with the ksuspend thread to prevent any more
+* autosuspend requests from being submitted, and decrement
+* the parent's count of unsuspended children.
+*/
+ usb_pm_lock(udev);
+ if (udev-parent !udev-discon_suspended)
+ usb_autosuspend_device(udev-parent);
+ usb_pm_unlock(udev);
+
+ /* Stop any autosuspend requests already submitted */
+ cancel_rearming_delayed_work(udev-autosuspend);
+}
+
+#else
+
+static inline void usb_stop_pm(struct usb_device *udev)
+{ }
+
+#endif
+
/**
* usb_disconnect - disconnect a device (usbcore-internal)
* @pdev: pointer to device being disconnected
@@ -1294,14 +1318,7 @@ void usb_disconnect(struct usb_device **
*pdev = NULL;
spin_unlock_irq(device_state_lock);
- /* Synchronize with the ksuspend thread to prevent any more
-* autosuspend requests from being submitted, and decrement
-* the parent's count of unsuspended children.
-*/
- usb_pm_lock(udev);
- if (udev-parent !udev-discon_suspended)
- usb_autosuspend_device(udev-parent);
- usb_pm_unlock(udev);
+ usb_stop_pm(udev);
put_device(udev-dev);
}
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
@@ -184,10 +184,6 @@ static void usb_release_dev(struct devic
udev = to_usb_device(dev);
-#ifdef CONFIG_USB_SUSPEND
- cancel_delayed_work(udev-autosuspend);
- flush_workqueue(ksuspend_usb_wq);
-#endif
usb_destroy_configuration(udev);
usb_put_hcd(bus_to_hcd(udev-bus));
kfree(udev-product);
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
@@ -1683,7 +1683,7 @@ void usb_remove_hcd(struct usb_hcd *hcd)
spin_unlock_irq (hcd_root_hub_lock);
#ifdef CONFIG_PM
- flush_workqueue(ksuspend_usb_wq);
+ cancel_work_sync(hcd-wakeup_work);
#endif
mutex_lock(usb_bus_list_lock);
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] USB: prevent char device open/deregister race
This patch (as908) adds central protection in usbcore for the
prototypical race between opening and unregistering a char device.
The spinlock used to protect the minor-numbers array is replaced with
an rwsem, which can remain locked across a call to a driver's open()
method. This guarantees that open() and deregister() will be mutually
exclusive.
The private locks currently used in several individual drivers for
this purpose are no longer necessary, and the patch removes them. The
following USB drivers are affected: usblcd, idmouse, auerswald,
legousbtower, sisusbvga/sisusb, ldusb, adutux, iowarrior, and
usb-skeleton.
As a side effect of this change, usb_deregister_dev() must not be
called while holding a lock that is acquired by open(). Unfortunately
a number of drivers do this, but luckily the solution is simple: call
usb_deregister_dev() before acquiring the lock.
In addition to these changes (and their consequent code
simplifications), the patch fixes a use-after-free bug in adutux and a
race between open() and release() in iowarrior.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Index: usb-2.6/drivers/usb/core/file.c
===
--- usb-2.6.orig/drivers/usb/core/file.c
+++ usb-2.6/drivers/usb/core/file.c
@@ -16,15 +16,15 @@
*/
#include linux/module.h
-#include linux/spinlock.h
#include linux/errno.h
+#include linux/rwsem.h
#include linux/usb.h
#include usb.h
#define MAX_USB_MINORS 256
static const struct file_operations *usb_minors[MAX_USB_MINORS];
-static DEFINE_SPINLOCK(minor_lock);
+static DECLARE_RWSEM(minor_rwsem);
static int usb_open(struct inode * inode, struct file * file)
{
@@ -33,14 +33,11 @@ static int usb_open(struct inode * inode
int err = -ENODEV;
const struct file_operations *old_fops, *new_fops = NULL;
- spin_lock (minor_lock);
+ down_read(minor_rwsem);
c = usb_minors[minor];
- if (!c || !(new_fops = fops_get(c))) {
- spin_unlock(minor_lock);
- return err;
- }
- spin_unlock(minor_lock);
+ if (!c || !(new_fops = fops_get(c)))
+ goto done;
old_fops = file-f_op;
file-f_op = new_fops;
@@ -52,6 +49,8 @@ static int usb_open(struct inode * inode
file-f_op = fops_get(old_fops);
}
fops_put(old_fops);
+ done:
+ up_read(minor_rwsem);
return err;
}
@@ -166,7 +165,7 @@ int usb_register_dev(struct usb_interfac
if (class_driver-fops == NULL)
goto exit;
- spin_lock (minor_lock);
+ down_write(minor_rwsem);
for (minor = minor_base; minor MAX_USB_MINORS; ++minor) {
if (usb_minors[minor])
continue;
@@ -176,7 +175,7 @@ int usb_register_dev(struct usb_interfac
retval = 0;
break;
}
- spin_unlock (minor_lock);
+ up_write(minor_rwsem);
if (retval)
goto exit;
@@ -197,9 +196,9 @@ int usb_register_dev(struct usb_interfac
intf-usb_dev = device_create(usb_class-class, intf-dev,
MKDEV(USB_MAJOR, minor), %s, temp);
if (IS_ERR(intf-usb_dev)) {
- spin_lock (minor_lock);
+ down_write(minor_rwsem);
usb_minors[intf-minor] = NULL;
- spin_unlock (minor_lock);
+ up_write(minor_rwsem);
retval = PTR_ERR(intf-usb_dev);
}
exit:
@@ -236,9 +235,9 @@ void usb_deregister_dev(struct usb_inter
dbg (removing %d minor, intf-minor);
- spin_lock (minor_lock);
+ down_write(minor_rwsem);
usb_minors[intf-minor] = NULL;
- spin_unlock (minor_lock);
+ up_write(minor_rwsem);
snprintf(name, BUS_ID_SIZE, class_driver-name, intf-minor -
minor_base);
device_destroy(usb_class-class, MKDEV(USB_MAJOR, intf-minor));
@@ -247,5 +246,3 @@ void usb_deregister_dev(struct usb_inter
destroy_usb_class();
}
EXPORT_SYMBOL(usb_deregister_dev);
-
-
Index: usb-2.6/drivers/usb/misc/auerswald.c
===
--- usb-2.6.orig/drivers/usb/misc/auerswald.c
+++ usb-2.6/drivers/usb/misc/auerswald.c
@@ -2040,12 +2040,12 @@ static void auerswald_disconnect (struct
if (!cp)
return;
- down (cp-mutex);
- info (device /dev/%s now disconnecting, cp-name);
-
/* give back our USB minor number */
usb_deregister_dev(intf, auerswald_class);
+ down (cp-mutex);
+ info (device /dev/%s now disconnecting, cp-name);
+
/* Stop the interrupt endpoint */
auerswald_int_release (cp);
Index: usb-2.6/drivers/usb/misc/idmouse.c
===
--- usb-2.6.orig/drivers/usb/misc/idmouse.c
+++ usb-2.6/drivers/usb/misc/idmouse.c
@@ -119,9 +119,6 @@ static struct usb_driver
[linux-usb-devel] [PATCH] USB: make the autosuspend workqueue thread freezable
This patch (as881b) makes the ksuspend_usb_wq workqueue freezable. We
don't want a rogue workqueue thread running around, unexpectedly
suspending or resuming USB devices in the middle of a system sleep
transition.
This fixes Bugzilla #8498.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Greg:
Please revert the existing
usb-make-the-autosuspend-workqueue-thread-freezable.patch
and apply this one in its place. And don't forget to send it on to
Linus soon!
Alan Stern
Index: 2.6.22-rc2/drivers/usb/core/usb.c
===
--- 2.6.22-rc2.orig/drivers/usb/core/usb.c
+++ 2.6.22-rc2/drivers/usb/core/usb.c
@@ -205,7 +205,11 @@ struct device_type usb_device_type = {
static int ksuspend_usb_init(void)
{
- ksuspend_usb_wq = create_singlethread_workqueue(ksuspend_usbd);
+ /* This workqueue is supposed to be both freezable and
+* singlethreaded. Its job doesn't justify running on more
+* than one CPU.
+*/
+ ksuspend_usb_wq = create_freezeable_workqueue(ksuspend_usbd);
if (!ksuspend_usb_wq)
return -ENOMEM;
return 0;
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] USB Core hub.c
On Tue, 22 May 2007, Pandita, Vikram wrote:
From: Alan Stern [mailto:[EMAIL PROTECTED]
On Mon, 21 May 2007, David Brownell wrote:
On Monday 21 May 2007, Vikram Pandita wrote:
---
diff -purN -X ./dontdiff a/drivers/usb/core/hub.c
b/drivers/usb/core/hub.c
--- a/drivers/usb/core/hub.c2007-05-13 14:24:43.0 +0530
+++ b/drivers/usb/core/hub.c2007-05-21 13:19:07.0 +0530
@@ -2571,7 +2571,7 @@ loop:
ep0_reinit(udev);
release_address(udev);
usb_put_dev(udev);
- if (status == -ENOTCONN)
+ if ((status == -ENOTCONN) || (status == -ENODEV))
break;
}
This is wrong. -ENOTCONN means what it says, that nothing is connected
to the port. So when it occurs we really do want to break out of the
loop.
On the other hand, -ENODEV means that there is a device but it doesn't
match our preconceptions (maybe its speed has somehow changed or some
other aspect is different). Since there still is a device connected to
the port, we don't want to break out of the loop.
Did you notice any particular example where the port was unconnected
and the code still tried to enumerate three times?
Yes. This is to fix the OTG HNP case.
In OTG enabled environment when the b-device attached is not supported
by host (is_targeted() returns Zero), the host suspends to give chance
to device to become b-host. If this fix is not in place, then the host
tries to enumerate the attached device SET_CONFIG_TRIES times which is
not required.
Following is the snippet of the code already in place that does the HNP
and returns the error code to stop re-enumerations and the proposed
patch checks for this error code:
if (!is_targeted(udev)) {
/* Maybe it can talk to us, though we can't talk to it.
* (Includes HNP test device.)
*/
if (udev-bus-b_hnp_enable || udev-bus-is_b_host) {
err = __usb_port_suspend(udev,
udev-bus-otg_port);
if (err 0)
dev_dbg(udev-dev, HNP fail, %d\n,
err);
}
err = -ENODEV;
goto fail;
}
I understand.
The problem is that hub_port_init() also returns -ENODEV under some
circumstances where we don't want to break out of the loop. So either
you should change the code shown above to return something else (for
example -EBADE) or else you should change hub_port_init().
Alan Stern
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Issues with start_frame
On Mon, 21 May 2007, Steve Calfee wrote: Hi Alan, About EHCI frame numbers. From the EHCI manual section 2.3.4: quote ... /quote That's alright; I have a copy of the spec. You don't need to include a lengthy extract, just put a reference to a section number. So FRINDEX does count microframes, but the bus only sees bits d13 to d3. In fact what Linux can respond in 125 microseconds? On a 2-GHz system that's enough time for 250,000 cycles, which is more than a few instructions. I should think a good deal could be done. Realistically, very few systems can respond in 1ms to use the frame number. So worrying about giving an exact microframe number some unknown amount of time in the past is not very useful. But this affects more than the software running on the host; it affects the functioning of the device as well. You will agree that devices can easily implement latencies much smaller than those of Linux? So it's conceivable that a driver really might need to arrange for a particular packet to be sent during a particular microframe. Guaranteeing taking a scheduling value 1 second is the worst possible case, but really a system should somehow know what its worst latency is, and use that as the minimum. I don't see what this has to do with latency -- a driver might want to schedule a transfer for 2 hours in the future! Obviously we don't need to support anything as large as that, but the principle is the same no matter what the delay value is. If we allow drivers to schedule transfers for a particular time, then we must guarantee that submissions will accepted anywhere up to X milliseconds into the future, where X is some reasonable but fixed number. At the least, the size of the periodic table is the (useful) worst case -(which is 256, 512 or 1024 ms). As I said to Dave, 256 ms is a perfectly reasonable minimum. Assuming we agree to support this at all. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for HID devices, take #2
On Tue, 22 May 2007, Oliver Neukum wrote: - Alan, do you have strong feelings about putting all conditions for failing to suspend into one condition? I consider it conceptually cleaner to have seperate branches for wanting to check for failure It looks like you've got two conditions for failing to suspend: The driver is still busy doing something like error recovery when the autosuspend timer expires; I/O in progress or on the queue takes too long to complete. Those are sufficiently different in nature that it makes sense to have separate branches. On the other hand, I still think you'd be better off with only one spin_lock_irq() call in hid_suspend(). After all, you always have to synchronize with the error handler, no matter what kind of suspend it is. In addition there would be nothing really wrong with calling usbhid_wait_io() for an autosuspend, since it should return right away. If you follow this advice, you'll find that the two branches share quite a lot more code than they do now. TODO - pre/post_reset is currently broken, it can no longer be a parasite on suspend/resume Why not? The only difference I can see is that you're allowed to fail a suspend but not a pre_reset. In fact, failing a non-auto suspend is not a good idea. You could easily end up preventing somebody's laptop from hibernating when they close the lid and put it in their knapsack. - adapt to hibernate What adaptations are needed? There is a principal issue. What is to be done with output requests? Starting the queue as soon as one arrives seems the safest thing to do, but it is fatal in a subset of situations, that is, it must not be done during snapshotting and when going for system suspend. The freezer is insufficient to prevent new requests from coming in. Because new requests are generated as a result of interrupt processing. But if you kill the interrupt URB then there will be no more inputs and hence nothing to generate any more output. Thus, when suspending you should kill the inputs and wait for the outputs to drain (or else explicitly plug the output queue). Then it will be safe to autoresume whenever a new output queue entry arrives. Come to think of it, it would be safest to have an explicit way of plugging the queues. But those details are up to you. Alan, are you going to scream and leap with talons extended if I suggest yet another pair of methods for USB devices to facilitate that? Probably. Besides, it's not just a USB problem. Other drivers -- and also some kernel threads -- will need to know when a hibernation is about to start. Isn't there going to be a notifier chain added for this? Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] anchors and their use
On Tue, 22 May 2007, Oliver Neukum wrote: Am Mittwoch, 16. Mai 2007 17:30 schrieb Alan Stern: This won't build because you forgot to export usb_unanchor_urb(). You could make usb_init_anchor() non-inline. I'm not sure where tradeoff lies, but you might be over the limit. I don't like the way you combined the error handling in usb-skeleton with the anchor stuff. Better to keep the two things in separate patches. Hi, I hope this version addresses your concerns Very good. I did notice two more things: Timeouts are specified in jiffies, so your timeout argument should be long or unsigned long, not int. There's a race if two threads call usb_unanchor_urb() for the same URB at the same time. You need to recheck while holding the anchor's spinlock that urb-anchor is still equal to anchor. You might also want to add WARN_ON(urb-anchor != NULL); to usb_anchor_urb(), just as a precaution. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Is usb_buffer_alloc a generic URB buffer allocator ? (was Split Bulk Transfers)
On Tue, 22 May 2007, Laurent Pinchart wrote: If not overly difficult, it might be interesting to implement transparent s-g, where the URB submission handler would cut buffers in pieces if needed. That way buffers could be allocated with kmalloc/get_free_pages for small buffers used infrequently, with usb_buffer_alloc for small buffers used in data bulk/isochronous streaming or with vmalloc for big buffers. Isn't that basically what I said Pete had done? Except that it wasn't transparent -- you had to call the library routine explicitly. Besides, can vmalloc be used for allocating DMA buffers? AFAIK it doesn't have any mechanism for respecting DMA memory location requirements (the DMA mask). Thinking about it, scatter-gathering buffers transparently would make it difficult to allocate coherent DMA mappings for data streaming. It would make life easier for driver writers, but performances might be impacted. It isn't the streaming as such which makes coherent DMA mappings attractive; it's the constant re-use of existing buffers. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Tue, 22 May 2007, Laurent Pinchart wrote: The usb_buffer_alloc name is misleading. Many USB driver developers believe it is a generic purpose buffer allocator. I'd like to change usb_buffer_alloc to make it a general purpose allocator. A parameter would tell the function to just allocate memory (default behaviour) or to allocate a DMA coherent mapping as well. We could even pass the URB pointer to the function to set the URB_TRANSFER_NO_DMA_MAP automatically (although usb_buffer_alloc can be used to allocate the setup buffer, so the API might have to be a little different). It would be simpler and less objectionable to just change the name of the routine. If it were called usb_alloc_coherent_DMA_buffer() then people wouldn't be tempted to think it was a general-purpose allocator. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] USB: handle errors in power/level attribute
This patch (as906) improves the error handling for the USB power/level
attribute file. If an error occurs, the original power-level settings
will be restored.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Index: usb-2.6/drivers/usb/core/sysfs.c
===
--- usb-2.6.orig/drivers/usb/core/sysfs.c
+++ usb-2.6/drivers/usb/core/sysfs.c
@@ -232,12 +232,15 @@ set_level(struct device *dev, struct dev
int len = count;
char *cp;
int rc = 0;
+ int old_autosuspend_disabled, old_autoresume_disabled;
cp = memchr(buf, '\n', count);
if (cp)
len = cp - buf;
usb_lock_device(udev);
+ old_autosuspend_disabled = udev-autosuspend_disabled;
+ old_autoresume_disabled = udev-autoresume_disabled;
/* Setting the flags without calling usb_pm_lock is a subject to
* races, but who cares...
@@ -263,6 +266,10 @@ set_level(struct device *dev, struct dev
} else
rc = -EINVAL;
+ if (rc) {
+ udev-autosuspend_disabled = old_autosuspend_disabled;
+ udev-autoresume_disabled = old_autoresume_disabled;
+ }
usb_unlock_device(udev);
return (rc 0 ? rc : count);
}
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] USB: rework C++-style comments
This patch (as911) replaces some C++-style commented-out debugging
lines in driver.c with a new verbose debugging macro. It makes the
code look cleaner, and it's easier to turn the debugging on or off.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Index: usb-2.6/drivers/usb/core/driver.c
===
--- usb-2.6.orig/drivers/usb/core/driver.c
+++ usb-2.6/drivers/usb/core/driver.c
@@ -28,6 +28,14 @@
#include hcd.h
#include usb.h
+#define VERBOSE_DEBUG 0
+
+#if VERBOSE_DEBUG
+#define dev_vdbg dev_dbg
+#else
+#define dev_vdbg(dev, fmt, args...)do { } while (0)
+#endif
+
#ifdef CONFIG_HOTPLUG
/*
@@ -811,8 +819,8 @@ static int usb_suspend_device(struct usb
}
status = udriver-suspend(udev, msg);
-done:
- // dev_dbg(udev-dev, %s: status %d\n, __FUNCTION__, status);
+ done:
+ dev_vdbg(udev-dev, %s: status %d\n, __FUNCTION__, status);
if (status == 0)
udev-dev.power.power_state.event = msg.event;
return status;
@@ -837,8 +845,8 @@ static int usb_resume_device(struct usb_
udriver = to_usb_device_driver(udev-dev.driver);
status = udriver-resume(udev);
-done:
- // dev_dbg(udev-dev, %s: status %d\n, __FUNCTION__, status);
+ done:
+ dev_vdbg(udev-dev, %s: status %d\n, __FUNCTION__, status);
if (status == 0) {
udev-autoresume_disabled = 0;
udev-dev.power.power_state.event = PM_EVENT_ON;
@@ -876,8 +884,8 @@ static int usb_suspend_interface(struct
mark_quiesced(intf);
}
-done:
- // dev_dbg(intf-dev, %s: status %d\n, __FUNCTION__, status);
+ done:
+ dev_vdbg(intf-dev, %s: status %d\n, __FUNCTION__, status);
return status;
}
@@ -915,8 +923,8 @@ static int usb_resume_interface(struct u
mark_active(intf);
}
-done:
- // dev_dbg(intf-dev, %s: status %d\n, __FUNCTION__, status);
+ done:
+ dev_vdbg(intf-dev, %s: status %d\n, __FUNCTION__, status);
return status;
}
@@ -1078,7 +1086,7 @@ static int usb_suspend_both(struct usb_d
}
done:
- // dev_dbg(udev-dev, %s: status %d\n, __FUNCTION__, status);
+ dev_vdbg(udev-dev, %s: status %d\n, __FUNCTION__, status);
return status;
}
@@ -1175,7 +1183,7 @@ static int usb_resume_both(struct usb_de
}
done:
- // dev_dbg(udev-dev, %s: status %d\n, __FUNCTION__, status);
+ dev_vdbg(udev-dev, %s: status %d\n, __FUNCTION__, status);
return status;
}
@@ -1242,8 +1250,8 @@ void usb_autosuspend_device(struct usb_d
int status;
status = usb_autopm_do_device(udev, -1);
- // dev_dbg(udev-dev, %s: cnt %d\n,
- // __FUNCTION__, udev-pm_usage_cnt);
+ dev_vdbg(udev-dev, %s: cnt %d\n,
+ __FUNCTION__, udev-pm_usage_cnt);
}
/**
@@ -1262,8 +1270,8 @@ void usb_autosuspend_device(struct usb_d
void usb_try_autosuspend_device(struct usb_device *udev)
{
usb_autopm_do_device(udev, 0);
- // dev_dbg(udev-dev, %s: cnt %d\n,
- // __FUNCTION__, udev-pm_usage_cnt);
+ dev_vdbg(udev-dev, %s: cnt %d\n,
+ __FUNCTION__, udev-pm_usage_cnt);
}
/**
@@ -1290,8 +1298,8 @@ int usb_autoresume_device(struct usb_dev
int status;
status = usb_autopm_do_device(udev, 1);
- // dev_dbg(udev-dev, %s: status %d cnt %d\n,
- // __FUNCTION__, status, udev-pm_usage_cnt);
+ dev_vdbg(udev-dev, %s: status %d cnt %d\n,
+ __FUNCTION__, status, udev-pm_usage_cnt);
return status;
}
@@ -1363,8 +1371,8 @@ void usb_autopm_put_interface(struct usb
int status;
status = usb_autopm_do_interface(intf, -1);
- // dev_dbg(intf-dev, %s: status %d cnt %d\n,
- // __FUNCTION__, status, intf-pm_usage_cnt);
+ dev_vdbg(intf-dev, %s: status %d cnt %d\n,
+ __FUNCTION__, status, intf-pm_usage_cnt);
}
EXPORT_SYMBOL_GPL(usb_autopm_put_interface);
@@ -1407,8 +1415,8 @@ int usb_autopm_get_interface(struct usb_
int status;
status = usb_autopm_do_interface(intf, 1);
- // dev_dbg(intf-dev, %s: status %d cnt %d\n,
- // __FUNCTION__, status, intf-pm_usage_cnt);
+ dev_vdbg(intf-dev, %s: status %d cnt %d\n,
+ __FUNCTION__, status, intf-pm_usage_cnt);
return status;
}
EXPORT_SYMBOL_GPL(usb_autopm_get_interface);
@@ -1429,8 +1437,8 @@ int usb_autopm_set_interface(struct usb_
int status;
status = usb_autopm_do_interface(intf, 0);
- // dev_dbg(intf-dev, %s: status %d cnt %d\n,
- // __FUNCTION__, status, intf-pm_usage_cnt);
+ dev_vdbg(intf-dev, %s: status %d cnt %d\n,
+ __FUNCTION__, status, intf-pm_usage_cnt);
return status;
}
EXPORT_SYMBOL_GPL
[linux-usb-devel] [PATCH] USB: fix ratelimit call semantics
This patch (as910) fixes a ratelimit modification so that the
original error-handling path will be followed even when the log-rate
limitation kicks in.
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
@@ -2351,10 +2351,10 @@ static void hub_port_connect_change(stru
if (portchange USB_PORT_STAT_C_CONNECTION) {
status = hub_port_debounce(hub, port1);
- if (status 0 printk_ratelimit()) {
- dev_err (hub_dev,
- connect-debounce failed, port %d disabled\n,
- port1);
+ if (status 0) {
+ if (printk_ratelimit())
+ dev_err (hub_dev, connect-debounce failed,
+ port %d disabled\n, port1);
goto done;
}
portstatus = status;
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB Suspend issue/(feature?)
On Tue, 22 May 2007, Steev Klimaszewski wrote: I have a Motorola KRZR phone, which by default when you plug it in to the usb slot charges the phones battery. When I enable usb suspend, after about 3 seconds, instead of continuing charging the phone, the usb port goes into suspend. While this isn't a showstopper, I was more wondering if this was a bug, or working as intended. I am at work currently, and forgot my usb cable, so I can't plug the phone in to get fresh output of what happens, unfortunately. But I am more than willing to provide any more info that anyone requests. This is working as intended. You can prevent the device from being automatically suspended in a couple of ways: If you set the autosuspend module parameter for usbcore to 0, then by default no subsequently plugged-in devices will be suspended. Or if you do echo 0 /sys/bus/usb/devices/.../power/autosuspend (fill in the device's address) then that device will not be suspended automatically. If the device has already been suspended and you want to wake it up, just run lsusb. Note that in the 2.6.22 kernel, you need to use -1 instead of 0 for these values. Or you can use a simpler approach: echo on /sys/bus/usb/devices/.../power/level If the device has already been suspended, this will wake it up. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Question regarding short transfers
On Tue, 22 May 2007, Curran, Dominic wrote: Hi I have two questions regarding short transfers. My questions are best illustrated by a scenario: Lets say the Hosts Mass Storage driver wants to READ 12K: I believe that the Host Controller driver (e.g. ehci_hcd) might see something like this coming from usbcore: 1) BULK OUT urb (31 bytes) [Contains READ10 command] 2) BULK IN urb (4K) [data] 3) BULK IN urb (8K) [data] 4) BULK IN urb (13 bytes) [status] Correct. However 1) must complete before 2) and 3) are submitted, and 3) must complete before 4) is submitted. This is not a fundamental limitation; it's just the way usb-storage currently works. I have two questions regarding what happens when the transfer gets terminated early: 1) What happens if the device terminates the transfer after the 4KB (with a zero-length packet)? Does the HC driver... - set status to 0 in the 4K urb ( actual_length=4096) and Yes. - flush all other queued urbs for that EP (in this case the 8K urb) by completing them with an error status ? If so what is the status ? Not exactly. The 8K URB completes with an error status -EREMOTEIO. However if there were any other URBs in the endpoint queue at that time, the HCD would not flush them. The flushing would be done by the completion handler for the 8K URB; it would call usb_unlink_urb() for all the remaining URBs. 2) What happens if the device terminates the transfer during the 4KB (after say 3700 bytes received, with a short packet)? Thus: urb-transfer_buffer_length = 4096 urb-actual_length = 3700 I believe that the HC driver should do the following test: if( (urb-actual_length urb-transfer_buffer_length) (urb-transfer_flags URB_SHORT_NOT_OK) ) urb-status = -EREMOTEIO; So if URB_SHORT_NOT_OK is set then -EREMOTEIO will be returned And if URB_SHORT_NOT_OK is not set the 0 will be returned. Is this correct ? Yes. The same thing would happen to the 8K URB in your first question. Again I assume that the 8K urb should be completed immediately ? If so with what status ? No. The 4K URB's completion handler would see the -EREMOTEIO error and would unlink the 8K URB, which would then complete with status -ECONNRESET. I'm having trouble understand the EHCI code; In the EHCI driver where are these situation handled ? qh_completions() ? Part of your trouble is because some of these situations are handled outside the EHCI driver. Take a look at the usb_sg_* routines in drivers/usb/core/message.c. Also read the kerneldoc comments in drivers/usb/core/urb.c and read Documentation/usb/error-codes.txt. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb debug query
On Tue, 22 May 2007, jonghne wrote: hi, my problem is system cannot find usb when usb is insered into UHP linux version is 2.6.15(or 2.6.21). I had tried old_param_scheme, there was error too. message is : usb 1-2: new low speed USB device using at91rm9200-ohci and address 2 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 usb 1-2: new low speed USB device using at91rm9200-ohci and address 3 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 usb 1-2: new low speed USB device using at91rm9200-ohci and address 4 usb 1-2: device not accepting address 4, error -110 I wanna print out data linux send to USB device and data linux received from USB device, especially when usb device is inserted into port, but I don't know where to add printk() and where the data is stored in. is there a function in usb driver waiting for usb device inserted then calling probe (for example) function? what is it? please give me some instructions, thank you. It would be a lot easier to read your email if you used line breaks and paragraph breaks. You can use usbmon to print out the data sent to the device. Instructions are in the kernel source file Documentation/usb/usbmon.txt. You won't see any data received from the device, because the computer didn't receive any data. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for HID devices, take #2
On Tue, 22 May 2007, Oliver Neukum wrote: TODO - pre/post_reset is currently broken, it can no longer be a parasite on suspend/resume Why not? The only difference I can see is that you're allowed to fail a suspend but not a pre_reset. Yes, but if you are in pre_reset, chances are something is wrong with the devices. Outright slaughter of all outstanding URBs is better than waiting for them to complete. Fair enough. I wouldn't call post_reset broken, though. In fact, failing a non-auto suspend is not a good idea. You could easily end up preventing somebody's laptop from hibernating when they close the lid and put it in their knapsack. Yes, and I don't. That's one reason I want to separate the auto and system cases. What happens if usbhid_wait_io() times out? - adapt to hibernate What adaptations are needed? Do I need to kill remote wakeup? No. It should be handled at a higher level. (Right now we don't really handle it properly; this is partly the fault of the PM core.) There is a principal issue. What is to be done with output requests? Starting the queue as soon as one arrives seems the safest thing to do, but it is fatal in a subset of situations, that is, it must not be done during snapshotting and when going for system suspend. The freezer is insufficient to prevent new requests from coming in. Because new requests are generated as a result of interrupt processing. Yes. But if you kill the interrupt URB then there will be no more inputs and hence nothing to generate any more output. Thus, when suspending you should kill the inputs and wait for the outputs to drain (or else explicitly plug the output queue). Then it will be safe to autoresume whenever a new output queue entry arrives. Nope. Devices share LED status. Now think of the case of having two keyboards, one already processed and the other still active. Yes, I had forgotten. Then you will have to rely on plugging. Come to think of it, it would be safest to have an explicit way of plugging the queues. But those details are up to you. What tells me when to do so? The best you can do is to plug the queues whenever you do a non-auto suspend. But that won't help if the device is already autosuspended when a hibernate begins. This is a good question; we should bring it to the attention of the PM people. Alan, are you going to scream and leap with talons extended if I suggest yet another pair of methods for USB devices to facilitate that? Probably. Besides, it's not just a USB problem. Other drivers -- and also some kernel threads -- will need to know when a hibernation is about to start. Isn't there going to be a notifier chain added for this? I have no idea. Should I ask on the pm list? Go ahead. It's connected to the previous question. Be sure to include enough details to make the nature of the problem clear to everyone, even people not familiar with the input subsystem. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for HID devices, take #2
On Tue, 22 May 2007, Alan Stern wrote: - adapt to hibernate What adaptations are needed? Do I need to kill remote wakeup? No. It should be handled at a higher level. (Right now we don't really handle it properly; this is partly the fault of the PM core.) This isn't is bad as it may sound. Our handling of remote wakeup isn't truly _bad_ -- it just doesn't quite match the USB spec. There's no danger of a remote wakeup request accidentally activating a device in the middle of snapshotting, or even in the middle of preparing for the snapshot, since khubd will already be frozen. The USB spec puts pretty stringent limitations on how long a host is allowed to ignore a remote wakeup request. In fact, the limit is 1 ms (TURSM; see 7.1.7.7). If a device does send a wakeup request during snapshotting, we will almost certainly violate that limit. The correct approach is to disable remote wakeup before starting the snapshot, but we don't currently do this. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Question regarding short transfers
On Tue, 22 May 2007, David Brownell wrote: 2) What happens if the device terminates the transfer during the 4KB (after say 3700 bytes received, with a short packet)? Thus: urb-transfer_buffer_length = 4096 urb-actual_length = 3700 I believe that the HC driver should do the following test: if( (urb-actual_length urb-transfer_buffer_length) (urb-transfer_flags URB_SHORT_NOT_OK) ) urb-status = -EREMOTEIO; So if URB_SHORT_NOT_OK is set then -EREMOTEIO will be returned And if URB_SHORT_NOT_OK is not set the 0 will be returned. Is this correct ? Yes. The same thing would happen to the 8K URB in your first question. Again I assume that the 8K urb should be completed immediately ? If so with what status ? No. The 4K URB's completion handler would see the -EREMOTEIO error and TYPO -- 8K, not 4K ... Look again -- the question assumes that the first 4K URB comes up short and then asks what would happen to the 8K URB. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] anchors and their use
On Mon, 21 May 2007, Oliver Neukum wrote: I don't like the way you combined the error handling in usb-skeleton with the anchor stuff. Better to keep the two things in separate patches. Problems with the packaging or the code? Just the packaging. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Patches still in the queue
On Mon, 21 May 2007, Oliver Neukum wrote: reset_resume will happen only because of the quirk. But when it happens during an autoresume, we cannot unbind the driver because we don't own the device lock. So what do you want to do then? This would need a separate thread. Yes. Along with all the complications of keeping track of references and making sure the thread gets flushed at the right time. How to avoid it? If the original driver fails, I see no alternative but to yield to other drivers and usbfs. Well, you don't really want to yield to other drivers and usbfs. Remember, we're talking about situations where the only problem is that the device has been reset and the driver doesn't know what to do about it. If the driver was working okay with the device before then it should be kept, not replaced by some other driver which might not work as well. So we should do unbind followed immediately by rebind, as in the patch I sent a week or so back. But maybe we can avoid having to use a separate thread. Like you said, disallowing autosuspend for quirky devices whose driver doesn't support reset_resume should eliminate the locking difficulty. But if a driver does not support reset_resume() and a device is quirky, why would you autosuspend in the first place? You would autosuspend a quirky device for the same reason you autosuspend a normal device: to save power. The fact that it needs a reset to resume isn't necessarily a drawback. You don't autosuspend a device unless the driver explicitely supports autosuspend. You do if the driver isn't bound to the device. :-) That's what happened with the quirky Philips audio thing. During bootup the system was very busy with other things, and the hotplug manager took a long time to load the usb-audio driver module. During that time the device was autosuspended. Then when the driver was finally loaded and the device was resumed so that probe() could be called, the device stopped working. Of course, in this situation we wouldn't need to call the driver's reset_resume method (if it had one) because at resume time the driver wasn't yet bound to the interface. It seems to me that this issue arises only if reset_resume() returns an error. Is there a reason to treat this differently from resume() failing? On a system resume, we can unbind. The only reason to treat it differently is because it occurs in a different context. System resume is different from autoresume, most especially because autoresume is often invoked by the driver itself. When that happens, trying to unbind could lead to deadlock. Let's disallow drivers failing during autoresume. reset_resume() methods will return void. Normal resume methods do return a status code, but we ignore it. So we should be okay. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for hid
On Mon, 21 May 2007, Oliver Neukum wrote:
Am Mittwoch, 16. Mai 2007 17:20 schrieb Alan Stern:
@@ -592,8 +604,21 @@ static int hid_get_class_descriptor(stru
int usbhid_open(struct hid_device *hid)
{
struct usbhid_device *usbhid = hid-driver_data;
+ int res;
- hid-open++;
+ mutex_lock(hid_open_mut);
+ if (!hid-open++) {
+ res = usb_autopm_get_interface(usbhid-intf);
+ /* the device must be awake to reliable request remote
wakeup */
+ if (res 0) {
+ hid-open--;
+ mutex_unlock(hid_open_mut);
+ return -EIO;
+ }
+ usbhid-intf-needs_remote_wakeup = 1;
+ usb_autopm_put_interface(usbhid-intf);
+ }
+ mutex_unlock(hid_open_mut);
if (hid_start_in(hid))
hid_io_error(hid);
return 0;
Don't you need to do usb_autopm_get_interface() before hid_start_in()?
hid_start_in() takes the spinlock and checks for a suspension. In the
unlikely case that the device already has been suspended, remote
wakeup must be active and resume() will call hid_start_in() again.
But this code runs whenever a process opens the device file. If the
device is suspended at that time, there might not be a remote wakeup
request pending. So you'd run into trouble unless you did an
autoresume before calling hid_start_in().
@@ -1154,13 +1184,26 @@ static int hid_suspend(struct usb_interf
struct usbhid_device *usbhid = hid-driver_data;
struct usb_device *udev = interface_to_usbdev(intf);
-
- spin_lock_irq(usbhid-inlock);
- set_bit(HID_REPORTED_IDLE, usbhid-iofl);
- spin_unlock_irq(usbhid-inlock);
- if (usbhid_wait_io(hid) 0)
- return -EIO;
-
+ if (udev-auto_pm) {
+ spin_lock_irq(usbhid-inlock); /* Sync with error handler
*/
+ if (!test_bit(HID_RESET_PENDING, usbhid-iofl)
+ !test_bit(HID_CLEAR_HALT, usbhid-iofl)
+ !test_bit(HID_OUT_RUNNING, usbhid-iofl)
+ !test_bit(HID_CTRL_RUNNING, usbhid-iofl))
+ {
+ set_bit(HID_REPORTED_IDLE, usbhid-iofl);
+ spin_unlock_irq(usbhid-inlock);
+ } else {
+ spin_unlock_irq(usbhid-inlock);
+ return -EBUSY;
+ }
+ } else {
+ spin_lock_irq(usbhid-inlock);
+ set_bit(HID_REPORTED_IDLE, usbhid-iofl);
+ spin_unlock_irq(usbhid-inlock);
+ if (usbhid_wait_io(hid) 0)
+ return -EIO;
+ }
del_timer(usbhid-io_retry);
usb_kill_urb(usbhid-urbin);
flush_scheduled_work();
This might be simpler if you inverted the order of the tests. That is,
first get the spinlock, then test for
udev-auto_pm (test_bit() || test_bit() || ...)
But that would put code needlessly under lock.
A single test of udev-auto_pm! I think it would be worthwhile for the
improvements in comprehensibility and code size.
to see if you need to fail right away. You probably don't even need to
check udev-auto_pm again before calling usbhid_wait_io.
@@ -1175,6 +1218,7 @@ static int hid_resume(struct usb_interfa
int status;
clear_bit(HID_REPORTED_IDLE, usbhid-iofl);
+ usbhid_mark_busy(usbhid);
usbhid-retry_delay = 0;
status = hid_start_in(hid);
usbhid_restart_queues(usbhid);
Again, don't you need to call usb_autopm_get_interface() before
hid_start_in()?
resume() and suspend() have mutual exclusion, don't they? So
the device must be awake while resume() is running.
Oh, yes. My mistake.
One last thing, about the race between a last-minute URB completion and
autosuspend. The USB autosuspend core routine doesn't check the
last_busy value after suspending the interface drivers and before
suspending the device. Do we need to?
As the lock is per device, the resume() call would wait and proceed
immediately after suspend() drops the lock. I see no problem.
I guess it's just a theoretical problem. The whole point of the
last_busy field is to prevent autosuspend too soon after any I/O. So
if an URB does complete and nevertheless the device is suspended a few
milliseconds later, then last_busy hasn't fulfilled its role. Like
this:
The autosuspend timer expires.
last_busy is sufficiently old.
hid_suspend() is called.
The interrupt URB completes.
last_busy is set to jiffies.
hid_suspend() kills the
interrupt URB and returns.
usbcore doesn't notice that
last_busy has been changed.
usbcore suspends
Re: [linux-usb-devel] Patches still in the queue
On Mon, 21 May 2007, Oliver Neukum wrote: Am Montag, 21. Mai 2007 17:15 schrieb Alan Stern: On Mon, 21 May 2007, Oliver Neukum wrote: How to avoid it? If the original driver fails, I see no alternative but to yield to other drivers and usbfs. Well, you don't really want to yield to other drivers and usbfs. What else do you do if you cannot resume ? This method needs to carry out IO to restore the state. Hence it may fail. Remember, we're talking about situations where the only problem is that the device has been reset and the driver doesn't know what to do about Who tells you that? Any IO might fail. The original context for this discussion has been cropped... We were talking about what to do when a driver doesn't have a reset_resume method. So when the core resets a device instead of resuming it, obviously the core knows there's something wrong when it sees the reset_resume method pointer is NULL. it. If the driver was working okay with the device before then it should be kept, not replaced by some other driver which might not work If the method fails, we know that the previous driver is not working. No. We are discussing what to do when the method doesn't exist, not what to do when it fails. In this situation we must assume the driver was working fine and it simply can't cope with a device reset. In that case pseudo continuity cannot be preserved. Either the device is zombified or renumerated. Which third option exists? [..] reset_resume() methods will return void. Normal resume methods do return a status code, but we ignore it. So we should be okay. That is simply wrong and should not be allowed to infiltrate other methods. You have raised a separate question (what to do when an interface driver's resume method or post_reset method fails) and it should be discussed in a separate email thread. If you're suggesting that the post_reset and reset_resume methods should return a status, that's okay with me. For the time being we will ignore that status, just as we ignore the status from a normal resume. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for hid
On Mon, 21 May 2007, Oliver Neukum wrote: I guess it's just a theoretical problem. The whole point of the last_busy field is to prevent autosuspend too soon after any I/O. So if an URB does complete and nevertheless the device is suspended a few milliseconds later, then last_busy hasn't fulfilled its role. Like this: The autosuspend timer expires. last_busy is sufficiently old. hid_suspend() is called. The interrupt URB completes. last_busy is set to jiffies. hid_suspend() kills the interrupt URB and returns. usbcore doesn't notice that last_busy has been changed. usbcore suspends the device. It's not actually _wrong_, but it isn't optimal. Yes, the race exists. The original version scheduled work to reawake the device in this case. Pete spotted the last vestige of that. Should I put it back in? It seemed a pointless waste of perfection on a heuristics that can't be perfect. No, don't put it back in. My question was whether usbcore should look to see whether last_busy had changed. But it is, after all, a race -- and like you say, we'll never be perfect. So there's probably no point in worrying too much about it. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] USB Core hub.c
On Mon, 21 May 2007, David Brownell wrote: On Monday 21 May 2007, you wrote: Hi David Can you check the following patch that may be needed in hub.c Prevent un-necessary enumeration of 3 times when device is not there. Signed-off-by: Vikram Pandita [EMAIL PROTECTED] Looks sane to me, but this would be better sent to the linux-usb list... --- diff -purN -X ./dontdiff a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c --- a/drivers/usb/core/hub.c2007-05-13 14:24:43.0 +0530 +++ b/drivers/usb/core/hub.c2007-05-21 13:19:07.0 +0530 @@ -2571,7 +2571,7 @@ loop: ep0_reinit(udev); release_address(udev); usb_put_dev(udev); - if (status == -ENOTCONN) + if ((status == -ENOTCONN) || (status == -ENODEV)) break; } This is wrong. -ENOTCONN means what it says, that nothing is connected to the port. So when it occurs we really do want to break out of the loop. On the other hand, -ENODEV means that there is a device but it doesn't match our preconceptions (maybe its speed has somehow changed or some other aspect is different). Since there still is a device connected to the port, we don't want to break out of the loop. Did you notice any particular example where the port was unconnected and the code still tried to enumerate three times? Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Root hubs and finish_port_resume, __usb_port_suspend
Dave: Do we really need to call finish_port_resume() for root hubs? It doesn't do much for them except to set the device state, which could just as easily be done in hcd_bus_resume(). The same question applies to root hubs and __usb_port_suspend(). In fact, it would be very easy to change the usb_generic driver so that it called usb_port_suspend() and usb_port_resume() only for non-root devices. Then those routines would never be invoked for devices with no upstream port, allowing us to save a few tests. Unless they get used for OTG? There is a funny-looking call to __usb_port_suspend in the OTG part of usb_new_device. (I'm not clear on why it doesn't call usb_port_suspend instead.) But it still isn't trying to suspend a root hub, so the proposed changes should be okay. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Issues with start_frame
Dave: The situation with regard to start_frame is a mess. Although the name and the documentation refer to frame numbers, for high speed devices the value stored there is a microframe number instead. Clearly anyone who's interested in the value will want to know the full microframe number. But on the other hand, the value returned from ehci_get_frame() actually _is_ a frame number, so there's no way for drivers to learn the current microframe. Thus we have several related problems: How to tell whether you're dealing with frames or microframes and when to use each. Any suggestions on how to solve them? Also, it seems to me that drivers ought to be able to take the current (micro)frame value, add a small amount to it, and specify the result as the start frame for an URB. But such behavior is not documented as always workable, and we don't have any firm standard for how big the small amount can be. My feeling is that all HCDs should guarantee that anything up to 1 second will be acceptable. What do you think? Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [Bug 8498], [Bug 8510], and Re: Can't s2ram 22-rc2
On Sat, 19 May 2007, Greg KH wrote:
On Sat, May 19, 2007 at 11:16:44AM -0400, Alan Stern wrote:
Greg:
The patch in $SUBJECT (already in your development tree) fixes a problem
with system suspend in 2.6.22-rc1, as described in
http://bugzilla.kernel.org/show_bug.cgi?id=8498
(For people on the PM development list, it's worth pointing out that all
the patch does is make a particular kernel thread freezable.)
Can you please expedite getting it sent up to Linus?
Will do, I have a number of USB bugfixes to go to Linus, just been
traveling too much. Next week I'll be able to get to it...
On Sun, 20 May 2007, Andrey Borzenkov wrote:
No. Unfortunately. Here is dmesg with patch and USB_DEBUG
swsusp: Marking nosave pages: 0009f000 - 0010
swsusp: Basic memory bitmaps created
Stopping tasks ... done.
Shrinking memory... done (61536 pages freed)
Freed 246144 kbytes in 1.99 seconds (123.69 MB/s)
Suspending console(s)
hub 1-0:1.0: hub_suspend
ohci_hcd :00:02.0: suspend root hub
usb usb1: usb suspend
usb usb1: usb resume
usb usb1: finish resume
hub 1-0:1.0: hub_resume
ohci_hcd :00:02.0: wakeup root hub
sd 0:0:0:0: [sda] Synchronizing SCSI cache
pnp: Device 00:09 disabled.
Trying to free already-free IRQ 11
ACPI: PCI interrupt for device :00:06.0 disabled
ACPI: Unable to derive IRQ for device :00:04.0
pci_device_suspend(): usb_hcd_pci_suspend+0x0/0x230 [usbcore]() returns -16
suspend_device(): pci_device_suspend+0x0/0x70() returns -16
Could not suspend device :00:02.0: error -16
On Mon, 21 May 2007, Rafael J. Wysocki wrote:
pci_device_suspend(): usb_hcd_pci_suspend+0x0/0x170() returns -16
suspend_device(): pci_device_suspend+0x0/0x60() returns -16
Could not suspend device :00:1d.0: error -16
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1
(rev 02)
lspci/dmesg are in this mail:
http://marc.info/?l=linux-kernelm=117973679209855w=2
Well, I think Alan should have a look at this too.
It turns out that the patch I originally wrote to fix this is in
conflict with one of Raphael's patches (make freezeable workqueues
singlethread) already added to 2.6.22-rc2. So here's an updated
version for that kernel.
Andrey, Soeren, and Avuton: Please try this patch with 2.6.22-rc2 or
later and see if it fixes your problems.
Greg, if this works then I'll send it in the proper form for a patch,
and you can use it to replace
usb-make-the-autosuspend-workqueue-thread-freezable.patch
Alan Stern
Index: 2.6.22-rc2/drivers/usb/core/usb.c
===
--- 2.6.22-rc2.orig/drivers/usb/core/usb.c
+++ 2.6.22-rc2/drivers/usb/core/usb.c
@@ -205,7 +205,7 @@ struct device_type usb_device_type = {
static int ksuspend_usb_init(void)
{
- ksuspend_usb_wq = create_singlethread_workqueue(ksuspend_usbd);
+ ksuspend_usb_wq = create_freezeable_workqueue(ksuspend_usbd);
if (!ksuspend_usb_wq)
return -ENOMEM;
return 0;
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Issues with start_frame
On Mon, 21 May 2007, David Brownell wrote: On Monday 21 May 2007, Alan Stern wrote: Dave: The situation with regard to start_frame is a mess. Although the name and the documentation refer to frame numbers, for high speed devices the value stored there is a microframe number instead. Clearly anyone who's interested in the value will want to know the full microframe number. But on the other hand, the value returned from ehci_get_frame() actually _is_ a frame number, so there's no way for drivers to learn the current microframe. Thus we have several related problems: How to tell whether you're dealing with frames or microframes and when to use each. Any suggestions on how to solve them? Simplest notion: define new primitives that always work in terms of microframes, convert to using them exclusively. Full speed ISO would ignore the LSBs. Phase out the old primitives; it's not as if anyone can rely on them much right now ... Alternatively, do that but make the old primitives work right and don't phase them out. At least, not for a year or two; this would help if anyone actually uses those primitives right now. The start_frame values actually do get used by a few drivers: drivers/media/video/usbvideo/konicawc.c drivers/usb/misc/stimulus/stimulus.c sound/usb/usx2y/usbusx2yaudio.c sound/usb/usx2y/usx2yhwdeppcm.c They test start_frame in various hacky ways, and some even try to set urb-start_frame before submission. So it would seem to be best to keep the get_frame() value as a frame number. When people need higher precision we can add it. (By the way, there may be another minor problem with ehci_get_frame. I don't completely understand the EHCI spec, but it says that the frame boundaries reported by the controller register differ by 125 us from the frame boundaries transmitted on the bus. See sections 2.3.4 and 4.5. Should this be corrected for?) Long term -- as you probably guessed, I'd rather just see a single programming interface for such stuff. Easier to test, document, and maintain. Me too. But what happens when USB 3.0 comes out and we have to deal with super-high-speed (or ultra-speed or hyper-speed or whatever they decide to call it) buses? -- I know, it's not possible to give a reasonable answer at this time. Also, it seems to me that drivers ought to be able to take the current (micro)frame value, add a small amount to it, and specify the result as the start frame for an URB. But such behavior is not documented as always workable, In fact it's documented as barely supported. Only UHCI attempts to do that, AFAIK. and we don't have any firm standard for how big the small amount can be. My feeling is that all HCDs should guarantee that anything up to 1 second will be acceptable. What do you think? First, do we even want to support that please use this start frame mechanism? I'm not sure we do. We can't have many users that care about it right now, so removing it should be cheap... I wouldn't mind removing it. Presumably when a driver starts up an iso stream, the exact starting time doesn't matter. But what if the new stream needs to be in a prescribed phase relationship with an already-existing iso stream? Or should we just not worry about this? (And if we do remove it, there won't be any reason to keep USB_ISO_ASAP, will there? HCDs would behave the same whether or not the flag was turned on.) Second, if we were to want to support it, I think that kind of absolute limit is inadvisable. EHCI uses 1/4 second scheduling horizons whenever it can, because of performance issues (cache trashing on some PPCs) with the larger 1 second horizon. Some controllers would need to emulate that in software by having a second we didn't yet tell the hardware about it schedule. Better to have the HCD export what it can handle. If we do support it, I think there should be some minimum figure for drivers to rely on. Otherwise you're just shifting the burden from the HCDs to the drivers. I'm okay with 1/4 second. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Patches still in the queue
On Mon, 21 May 2007, Oliver Neukum wrote: No. We are discussing what to do when the method doesn't exist, not what to do when it fails. In this situation we must assume the driver was working fine and it simply can't cope with a device reset. Ok, this narrowly put, my answer is: - don't autosuspend - on resume, disconnect the driver And then rebind the same driver back again? Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Patches still in the queue
On Mon, 21 May 2007, Oliver Neukum wrote: Am Montag, 21. Mai 2007 23:16 schrieben Sie: On Mon, 21 May 2007, Oliver Neukum wrote: No. We are discussing what to do when the method doesn't exist, not what to do when it fails. In this situation we must assume the driver was working fine and it simply can't cope with a device reset. Ok, this narrowly put, my answer is: - don't autosuspend - on resume, disconnect the driver And then rebind the same driver back again? Essentially yes. Simply use the standard probe logic, no need for special casing. But what if the current driver got there in the first place by some sort of special casing? For that matter, what if the current driver is usbfs, by way of USBDEVFS_CLAIMINTERFACE? Hmmm, maybe the usbfs driver will need to have a reset_resume method; at the moment it doesn't even have suspend or resume. (But I don't know what any of them could do...) Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.22-rc2 built on ppc
On Sun, 20 May 2007, David Brownell wrote: On Sunday 20 May 2007, Elimar Riesebieter wrote: Hi, FYI, building the kernel modules with gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7) on my powerbook (PPC) gives: ... drivers/usb/gadget/net2280.c: In function 'net2280_probe': erivers/usb/gadget/net2280.c:2967: warning: ignoring return value of 'pci_set_mwi', declared with attribute warn_unused_result ... Someone stupidly declared that as must-check. The correct response to an error there is to ignore it. Perhaps you would like to submit a patch removing the __warn_unused_result attribute from pci_set_mwi(), so this warning doesn't bother anyone else in the future? Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 0/6] Composite Gadget Support
On Sat, 19 May 2007, Ragner Magalhaes wrote: The following series implements USB Composite Gadget Support. [PATCH 1/6] USB gadget driver. [PATCH 2/6] Composite gadget driver. [PATCH 3/6] Composite gadget driver upgrade. [PATCH 4/6] Kconfig modifications for USB Composite gadget support. [PATCH 5/6] Composite File Storage gadget support. [PATCH 6/6] Composite Ether gadget support. The Composite Gadget can handle one or two configurations. When the first usb_function modprobe'ed has two configurations the Composite Gadget will have two configurations, for the other functions modprobe'ed after will be used the selected or standard configuration only, their interfaces will be part of the Composite's Configurations. Then exchanging configs in the Composite will only affect the first function. In case the first modprobe'ed function has only one configure, the Composite Gadget WILL have only one configuration. This behavior is useful when modprobe'ing g_ether as the first usb_function due to the RNDIS and CDC Configurations. How does this patchset differ from your earlier versions? Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.22-rc2: regression: STD fails with pci_device_suspend(): usb_hcd_pci_suspend+0x0/0x160 [usbcore]() returns -16
On Sat, 19 May 2007, Andrey Borzenkov wrote: This works just fine up to and including 2.6.21. unfortunatelt dmesg got truncated; if required I can rebuild with larger buffer; the part around suspend is swsusp: Marking nosave pages: 0009f000 - 0010 swsusp: Basic memory bitmaps created Stopping tasks ... done. Shrinking memory... done (14553 pages freed) Freed 58212 kbytes in 0.30 seconds (194.04 MB/s) Suspending console(s) sd 0:0:0:0: [sda] Synchronizing SCSI cache pnp: Device 00:09 disabled. ACPI: PCI interrupt for device :00:0a.0 disabled Trying to free already-free IRQ 11 ACPI: PCI interrupt for device :00:06.0 disabled ACPI: Unable to derive IRQ for device :00:04.0 pci_device_suspend(): usb_hcd_pci_suspend+0x0/0x160 [usbcore]() returns -16 suspend_device(): pci_device_suspend+0x0/0x70() returns -16 Could not suspend device :00:02.0: error -16 Please turn on CONFIG_USB_DEBUG and post the resulting dmesg log. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] usb-make-the-autosuspend-workqueue-thread-freezable.patch
Greg: The patch in $SUBJECT (already in your development tree) fixes a problem with system suspend in 2.6.22-rc1, as described in http://bugzilla.kernel.org/show_bug.cgi?id=8498 (For people on the PM development list, it's worth pointing out that all the patch does is make a particular kernel thread freezable.) Can you please expedite getting it sent up to Linus? Thanks, Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Is usb_buffer_alloc a generic URB buffer allocator ? (was Split Bulk Transfers)
On Sat, 19 May 2007, jidong xiao wrote: The length of any entry should be greater than a page?I think only if each buffer's size is divisible by page size, could it start at a page boundary and end at a page boundary. Let's use the word buffer to refer to the region of memory described by the entire scatter-gather list. Let's use the word sub-buffer to refer to that portion of the buffer which is described by a single scatterlist entry. Note that each entry corresponds to a group of pages (or a single page), only part of which might be contained in the sub-buffer. If the sub-buffer begins at the start of the group of pages and ends at the end of the group of pages then its length will indeed be a multiple of the page size. Each sub-buffer (except possibly the first one) will begin at the start of the page group. And each sub-buffer (except possibly the last one) will end at the end of the page group. Another way to describe this is as follows: For each scatterlist entry after the first, we should always have .offset = 0. For each scatterlist entry before the last, we should always have (.offset + .length) is a multiple of the page size. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Sat, 19 May 2007, David Brownell wrote: Absolutely right, I'm being an idiot here. I think I looked at root hub code in the rush to the FreedomHEC preparations. We do not have local_irq_save in the giveback routine. So, when Alan wrote USB callbacks cannot be interrupted, he meant normal no-reentrancy guarantees, and not that the interrupts are disabled. No, I really meant that interrupts are disabled. It's possible that I was wrong... And by normal no-reentrancy you mean the normal guarantee that each IRQ handler won't be re-entered while it's running. I observe that we don't register PCI IRQ handlers with IRQF_DISABLED, so it's possible that some *other* IRQ happens while it's running; but most of the non-PCI irq handlers are registered with that flag set. That seems potentially buglike to me; it's legit for any IRQ handler to submit an URB. Which would then cause them to try grabbing the spinlock held by the HCD's IRQ handler, if that other IRQ handler happened to fire when the HCD's IRQ handler was running. So maybe we should always register with IRQF_DISABLED, unattractive though that could be in terms of latencies ... or, somehow try to define a rule whereby URBs can't be submitted in certain IRQ contexts. Or better still, always acquire the HCD's spinlock with spin_lock_irqsave(). That's what uhci-hcd does, even though ehci-hcd and ohci-hcd don't. Of course, if we don't use IRQF_DISABLED then we would have to verify that none of the callbacks rely on interrupts being disabled. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [Bugme-new] [Bug 8510] New: OHCI constantly attempts suspending root hub on ALi motherboard
On Sun, 20 May 2007, Andrey Borzenkov wrote: On Sunday 20 May 2007, David Brownell wrote: On Saturday 19 May 2007, David Brownell wrote: On Saturday 19 May 2007, Andrew Morton wrote: On Sat, 19 May 2007 10:08:40 -0700 [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8510 A regression. From 2.6.16, yes... this has been around for a while, but nobody came up with a patch. I suggest someone with the hardware just provide an update to the drivers/usb/host/ohci-pci.c file using the PCI_DEVICE(PCI_VENDOR_ID_ITE, 0x8152), quirk table entry as a model. Grr, better yet: find out why the existing quirk entry for this particular laptop doesn't trigger. Because it is usig wrong subvendor. Runtime tested: Does this fix the regression described in your email 2.6.22-rc2: regression: STD fails with pci_device_suspend(): usb_hcd_pci_suspend+0x0/0x160 [usbcore]() returns -16 ? Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch] berry_charge.c updated with Blackberry Pearl support, and other bugfixes
On Thu, 17 May 2007, Chris Frey wrote:
Hi,
Below is a patch with the following changes to the berry_charge.c module:
1) kzalloc() is called, but memory is never freed
Is this a memory leak? I'm not sure, but the buffer is only
a dummy buffer to hold return data that is never used,
so I suspect a stack variable will suffice.
Are you aware that stack-based DMA buffers don't work on all systems?
@@ -105,6 +128,28 @@
/* turn the power on */
magic_charge(udev);
+ /* change modes if device is a Pearl */
+ if (udev-descriptor.idProduct == PEARL)
+ magic_pearl(udev);
+
+ /* set configuration and reset to activate change */
+ dbg(udev-dev, Calling set_configuration\n);
+ retval = usb_driver_set_configuration(udev, 1);
+ if (retval) {
+ dev_err(udev-dev, Set Configuration failed :%d.\n, retval);
+ return retval;
+ }
Apparently you don't understand how usb_driver_set_configuration()
works. It doesn't set the configuration immediately; in fact the
Set-Config doesn't happen until after your driver returns.
Note that if the config you are changing to is the same as the current
config then there's no need to use usb_driver_set_configuration(). You
can call usb_reset_configuration() instead -- it sends a Set-Config
request for the current configuration number.
Furthermore, if the device has changed its set of available
configurations then at some point you _must_ call usb_reset_device().
Otherwise the kernel will be unaware of the new configs.
+ /* reset is required by the Pearl */
+ retval = usb_reset_configuration(udev);
+ if (retval) {
+ dev_err(udev-dev, Configuration reset failed: %d.\n,
retval);
+ return retval;
+ }
usb_reset_configuration() doesn't do a device reset; it does a
Set-Config. Is that what you want? Or do you want to call
usb_reset_device()?
Alan Stern
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] problem with EHCI port status register
On Fri, 18 May 2007, Tomohiro Kusumi wrote: Hi I'm using HP storageworks USB DAT device on RHEL4 (based on kernel 2.6.9). It works okay most of the times, but sometimes the driver does not detect the device (about 1 out of 10 times). No other USB devices are used on the system. Let me explain some details. I turned on the CONFIG_USB_DEBUG option and put some orignal debug printk into the EHCI and core driver code. I found out that the ehci_hub_status_data() returns 0 when the DAT device is not detected. As a result the URB is not given back to the URB's complete function which is hub_irq(). If the function returns non zero, khubd is woken up as a sequence of hub_irq() and the setup control packets will be sent to the newly detected device. Am I right? The reason why ehci_hub_status_data() returns 0 is because the EHCI's port status register for the DAT is 0x1005 (PORT_POWER | PORT_PE | PORT_CONNECT), although it should be something like 0x1803 if the device is detected properly. As far as I know, the port status becomes 0x1005 only after the device is detected. Since the port status is 0x1005 when ehci_hub_status_data() is executed, the driver assumes that the device has already been detected, so it does not try to detect it as I mentioned above. Have any of you ever seen the same situation before? Or is there any way to fix this issue regarding the port status? Any suggestions would be helpful. This could be a problem with the BIOS. You might try going through the BIOS setup and turning off support for Legacy USB or anything else which might cause the BIOS to interfere with USB operations. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Does kernel 2.6 has some trick on Context Switch
On Fri, 18 May 2007, Pu Jiangbo wrote: Dear all, I've used LMBench to benchmark context switch between 2.4 and 2.6, and found an interesting thing that when the thread size is between 0~1024KByte, the switching time increased as everyone predicted, however, when bigger than 2M, it sharply decreased, like this: 256Kbyte/4 Processes: 47.3 ms 512Kbyte/4 Processes: 140.97 ms 1MByte/4 Processes: 142.63 ms 2MByte/4 Processes: 17.88 ms 4M: 17.25 ms 8M: 10.00 ms when at a Linux 2.4 in the same PC: 512K/4P: 155.06 ms 1M/4P:153.09 ms 2M/4P:74.71 ms 4M/4P:132.84 ms 8M/4P:809.36 ms I'm very comfused at this result, could anyone know something about that? Thank you very much! Just out of curiosity, I wonder why you sent a message about kernel context-switching performance to the USB development mailing list? Don't you realize it is completely Off-Topic? Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Fri, 18 May 2007, Hans Petter Selasky wrote: Hi, If you are interested, the files are: http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_compat_linux.c http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_compat_linux.h It is almost finished now. And it is not very much code. It occurred to me last night that you could accomplish what you want without any change to the Linux drivers at all. Just change the FreeBSD stack so that it preallocates one or two transfers for every endpoint at the time the endpoint is enabled -- that is, whenever the stack sends a Set-Configuration or Set-Interface request. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Problems with /pub/linux/kernel/people/gregkh/gregkh-2.6
Greg: It looks like your development directory has gotten a little out of sync with itself. Look at this sublisting: gregkh-01-driver/17-May-2007 14:55- gregkh-02-i2c/ 10-May-2007 14:41- gregkh-02-pci/ 17-May-2007 14:56- gregkh-03-pci/ 10-May-2007 14:41- gregkh-03-usb/ 17-May-2007 14:56- gregkh-04-driver-class/ 17-May-2007 14:56- gregkh-04-usb/ 10-May-2007 14:41- gregkh-05-driver-class/ 10-May-2007 14:41- Apparently adding or removing i2c threw all the higher numbers off by one. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Fri, 18 May 2007, Hans Petter Selasky wrote: It occurred to me last night that you could accomplish what you want without any change to the Linux drivers at all. Just change the FreeBSD stack so that it preallocates one or two transfers for every endpoint at the time the endpoint is enabled -- that is, whenever the stack sends a Set-Configuration or Set-Interface request. That is correct. But where do I get information about the buffer-size to use? Choosing the wrong buffer size can limit performance or waste memory. Yes, that is a problem. It's made even worse by the fact that the drivers themselves frequently do not know in advance the buffer sizes they will use. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch] berry_charge.c updated with Blackberry Pearl support, and other bugfixes
On Fri, 18 May 2007, Chris Frey wrote: Apparently you don't understand how usb_driver_set_configuration() works. It doesn't set the configuration immediately; in fact the Set-Config doesn't happen until after your driver returns. Thank you for the explanation. If I understand correctly, the ssleep() I added is really just delaying the actual set-config (if it actually happens). Are most of these usb function calls queued like this? No; usb_driver_set_configuration() is an exception. If you think about it, you'll realize that it has to work this way. Imagine what would happen if your driver could call usb_set_configuration() directly (it can't because the routine isn't exported, but never mind). When the call ran, in addition to sending the Set-Config message to the device it would have to destroy the old config settings in the host and install the new ones. Part of the old settings are the set of registered interfaces and the bindings between interfaces and drivers. Among other things, this means it would try to unregister your interface while it was still in the process of being registered, and it would call your driver's disconnect() routine while the probe() routine was still running. The best you could hope for would be a deadlock. Not a good thing to try. usb_reset_configuration() doesn't do a device reset; it does a Set-Config. Is that what you want? Or do you want to call usb_reset_device()? I wanted reset_device. If I call usb_reset_device(), and there is a pending usb_set_configuration(), will it still happen in that order? It's a tricky situation. The reset would definitely occur first because your probe() routine is called by the core while holding the device lock, and set_config needs to acquire the same lock. But after the reset, the device would end up having a different set of descriptors, right? At least, it should if everything works correctly. As a result, the reset routine would cause the device to be logically disconnected and re-enumerated. The delayed set-config call would then fail because the original device instance would no longer be active. So the USB core would pick some default configuration and install it. If it picked the wrong one and your driver was probed again, then at that point you could call usb_driver_set_configuration(). I'll work up a new patch. Interestingly, I did test this, and it worked, even with the wrong call. It could have just been the device I was testing with. I once had a Pearl that definitely needed a reset from userspace, but I don't have it to test with anymore. Be sure to test with CONFIG_USB_DEBUG turned on, and watch the dmesg log closely to see how everything behaves. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Is usb_buffer_alloc a generic URB buffer allocator ? (was Split Bulk Transfers)
On Sat, 19 May 2007, jidong xiao wrote: By the way,I remember in drivers/usb/storage/scsiglue.c, there is a chunk of comments about scatter-gather buffers. Regarding this, I have one question: except at the beginning and the end, scatter-gather buffers follow page boundaries, why? i.e. Is there any specific reason that sg buffers should follow page boundaries? Then why the beinging and the end are exceptions? The buffers follow page boundaries because they are allocated as groups of pages. At least, that's how the kernel allocates them. A buffer can also be created to map data in userspace, and a buffer occupying contiguous user (or virtual) addresses will in general end up lying in a discontiguous set of pages -- because virtual memory is managed in units of pages. The end might not lie on a page boundary because the total amount of data might not fill out all of the last page. The beginning is subject only to the alignment specified by the blk_queue_dma_alignment() setting. Hence it might not lie on a page boundary. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Is usb_buffer_alloc a generic URB buffer allocator ? (was Split Bulk Transfers)
On Fri, 18 May 2007, David Brownell wrote: On Friday 18 May 2007, jidong xiao wrote: Regarding this, I have one question: except at the beginning and the end, scatter-gather buffers follow page boundaries, why? i.e. Is there any specific reason that sg buffers should follow page boundaries? Then why the beinging and the end are exceptions? You should ask the person who wrote that comment; I can't make sense of it myself. What's follow etc. I wrote it. Stating it more verbosely: Each entry in a scatter-gather list maps a group of physically contiguous pages. The buffer itself occupies only a portion of those pages, as given by the .offset and .length fields in the entry. For each entry in the list (except possibly the first), .offset is 0 and hence the buffer starts at a page boundary. For each entry in the list (except possibly the last), .offset + .length is equal to the total size of the pages mapped by the entry, and hence the buffer ends at a page boundary. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb_control_msg() returns timeout !!
On Thu, 17 May 2007, Jayaprakash Shanmugam wrote: Hello Group, I have two devices connected to a host. I periodically read bulk data from first device and pass it on to the second device via EP-2. Apart from this periodic data, the host sends some vendor commands through EP-0 of first device. Though these vendor commands are received successfully by the device, usb_control_msg() returns -ETIMEDOUT error sometimes. If I stop sending the periodic bulk data, no -ETIMEDOUT is seen for the usb_control_msg(). Are you sure about that? If you stop sending the bulk data to the second device, then the control messages to the first device start working? Even though you continue to read the bulk data periodically from the first device? I traced out the message.c file and it looks like the URB times out to call the timeout_kill() function. I even tried with a higher timeout, but no improvement is seen. Any pointers on what could have gone wrong ? I observed the same with both EHCI and OHCI drivers. The device is Cypress based, capable of USB2.0. The host runs 2.6.11 on MPC8270 with PCI-USB ISP1561. What happens with a different host? What happens with a later version of the kernel on the host? 2.6.11 is quite old... Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thu, 17 May 2007, Hans Petter Selasky wrote: If you need to do Async stuff, then you have to do it in a separate thread or in a so-called task-queue. Else you are in for great trouble! That was the big sin in the old USB stack on FreeBSD: Calling synchronous USB callbacks from everywhere, like ioctl/read/write - callbacks. Is that a problem on Linux also? It's hard to answer; your use of terminology is peculiar. The word synchronous does not mean capable of blocking; it means that the routine waits until a result is received. It is not directly related to whether the routine runs in a process context (which can sleep) vs. an atomic context (one which isn't allowed to sleep). Referring to a callback as synchronous doesn't make sense. A callback doesn't send a message -- it _receives_ a message -- and hence it doesn't need to wait for any result. In Linux, the USB callbacks are generally atomic. Does that answer your question? On Linux I see no locks used in the USB drivers, so they are solely protected by interrupt-level mechanisms. That's an awfully strange thing to say. No locks used in the USB drivers? Good lord, they are full of locks! Semaphores, mutexes, spinlocks -- you name it, it's in there. My rule is that: Synchronous or blocking calls _must_ happen in a config thread that you can wait for. Else asynchronous calls on pre-allocated transfers can happen anywhere. What distinguishes a config thread from any other kind of thread? What distingishes threads you can wait for from threads you can't wait for? What's wrong with a config thread that you can't wait for making a blocking call? Who cares if you can't wait for it? -- the thread will still carry out the call okay. The problem clearly appears on Linux SMP because: What problem? Or should I say, Which problem? a) No locks are in the USB drivers (then they must be all so-called Giant locked) You must be living in some sort of fantasy land if you really believe this. Or else you're looking at a version of Linux from 8 years ago. b) You don't pre-allocate transfers, resulting in synchronous/blocking calls everywhere, and no-one thinks about what can happen then :-) Your reasoning is illogical. Why does allocation have to be blocking? In code paths which can't block, we do non-blocking late allocation. And we do think about what can happen. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thu, 17 May 2007, Hans Petter Selasky wrote: In Linux, the USB callbacks are generally atomic. Does that answer your question? Yes. So you protect the callback with a lock to make it atomic? No, you don't understand. The callback is atomic because it is not allowed to sleep. That's what atomic means. It has nothing to do with locking or protection. b) You don't pre-allocate transfers, resulting in synchronous/blocking calls everywhere, and no-one thinks about what can happen then :-) Your reasoning is illogical. Why does allocation have to be blocking? Memory allocation is blocking in that way it might have to flush out memory pages to a harddisk, before those pages can be allocated by something in the kernel. Of course there exists no-wait options that you can pass to malloc, but I wouldn't rely too much on those flags You _can_ rely on the no-wait option to prevent the allocation from sleeping or flushing pages to a disk... unless you are allocating from a pre-defined memory pool, where you know that there is memory reserved for you. ... and you can't rely on no-wait to succeed unless, as you say, you already know there is memory available. But that's also true for early, blocking allocations; there's nothing special about late, non-blocking malloc. With pre-allocation you might fail at the beginning, and with late allocation you might fail in the middle. Either way, you fail. So what's the big deal? Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] rx errors reported by usbnet
On Thu, 17 May 2007, Yum Rayan wrote: Hi, I have a bunch of USB devices configured for ethernet over USB connected to my machine. The host is running a 2.6.16 based kernel and I notice that rx errors reported via /proc/net/dev keep increasing infinitely. Initially the device responds without any problems, but at some random time, eventually the device and USB subsystem seem to lock up, i.e. commands like lsusb begin to fail. The USB device itself is also running a 2.6.9 based kernel, but during the time the RX errors are seen there is no TX or RX from the device side. Neither are any errors reported via /proc/net/dev on the USB side. After some debug statements, I see that the RX errors are due to -71 EPROTO errors. Any help appreciated in understanding what is happening here. Here are the related messages (the messages keep repeating): ohci_hcd :00:04.0: urb c7881c60 path 2 ep1in 6d16 cc 6 -- status -71 mydev3: rx throttle -71 mydev3: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c3a33ce0 path 2 ep1in 6d16 cc 6 -- status -71 mydev3: rx throttle -71 mydev3: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c3a33e00 path 1 ep1in 6d16 cc 6 -- status -71 mydev1: rx throttle -71 mydev1: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c7881cc0 path 2 ep1in 6d16 cc 6 -- status -71 mydev3: rx throttle -71 ohci_hcd :00:04.0: urb c3a33da0 path 1 ep1in 6d16 cc 6 -- status -71 mydev1: rx throttle -71 mydev3: rxqlen 3 -- 4 mydev1: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c7881d20 path 1 ep1in 6d16 cc 6 -- status -71 mydev1: rx throttle -71 mydev1: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c7881c00 path 2 ep1in 6d16 cc 6 -- status -71 mydev3: rx throttle -71 mydev3: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c3a33d40 path 1 ep1in 6d16 cc 6 -- status -71 mydev1: rx throttle -71 mydev1: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c7881c60 path 2 ep1in 6d16 cc 6 -- status -71 mydev3: rx throttle -71 These error codes indicate low-level USB communication problems. There may be something wrong with the USB cable, or the device's USB interface may have stopped running. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thu, 17 May 2007, Hans Petter Selasky wrote: Hi, On Thursday 17 May 2007 19:03, Alan Stern wrote: On Thu, 17 May 2007, Hans Petter Selasky wrote: In Linux, the USB callbacks are generally atomic. Does that answer your question? Yes. So you protect the callback with a lock to make it atomic? No, you don't understand. The callback is atomic because it is not allowed to sleep. That's what atomic means. It has nothing to do with locking or protection. And it cannot be interrupted either? Some atomic routines can be interrupted and some can't. If an interrupt does occur then the interrupt handler is also atomic (by definition), so no problem will arise. As it happens, USB callbacks cannot be interrupted. That's a somewhat artificial restriction; in theory there's no reason we couldn't allow interrupts. With pre-allocation you might fail at the beginning, and with late allocation you might fail in the middle. Either way, you fail. So what's the big deal? There is a greater chance of successing with pre-allocation if you use the wait flag when you malloc? Right? Certainly. But turn it around: With pre-allocation you force other parts of the system to have a higher chance of failing, because you already own the memory they want (even though you may not be using it). Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thu, 17 May 2007, Pete Zaitcev wrote: On Thu, 17 May 2007 14:26:18 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: As it happens, USB callbacks cannot be interrupted. That's a somewhat artificial restriction; in theory there's no reason we couldn't allow interrupts. Do you remember why we're doing this? I did not touch that part since the attempt to keep usb-lock across the callback (read: years back). I think it's pretty much just legacy. Nobody wants to audit all the callback routines to see which ones really need interrupts to be disabled. I think we should remove those local_irq_save's, and leave just the guarantee that it won't be re-entered (currently such a guarantee is inherited from the Linux's interrupt handling, and we'll only need to make it explicit if any HCDs start using softirq when calling the giveback routine). I'm poking your memory in case there's actually a good reason for it which I forgot. None that I can recall. Even without the interrupt handling guarantee, the HCDs are (or should be) written so that callbacks won't occur recursively. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thu, 17 May 2007, Laurent Pinchart wrote: A user of the Linux UVC driver unfortunately reported such a failure. The driver allocates 5 bulk URBs, and the device asked for a 2.7MB buffer. The system had been used for quite some time, and the user reported that allocating such an amount of contiguous memory made the box swap out and become very slow. Obviously the driver should be smart enough not to try and get such a large buffer. It should allocate several smaller buffers instead. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Is usb_buffer_alloc a generic URB buffer allocator ? (was Split Bulk Transfers)
On Tue, 15 May 2007, Laurent Pinchart wrote: Hi everybody, following the discussion about the split bulk transfers, Alan Stern and David Brownell told me I shouldn't use usb_buffer_alloc as a generic purpose URB buffer allocated. However, Documentation/usb/dma.txt contradicts this. Should the documentation be fixed, or can/should usb_buffer_alloc be used to allocate URB buffers ? It's difficult to give general advice, since the performance will vary according to the platform and the usage. If a buffer is going to be used once and then thrown away, I think there's not much advantage to usb_buffer_alloc(). Although on some odd platforms that may not be true, it should be true on the vast majority. If a buffer is going to be used many times, then usb_buffer_alloc() might give improved performance. Again, that depends on the platform and the type of memory accesses involved. The tradeoffs are hard to assess because they involve a lot of variables: How responsive is the IOMMU, does the cache do bus-snooping, will there be many accesses to uncached memory, and so on. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Patches still in the queue
On Wed, 16 May 2007, Oliver Neukum wrote: Am Dienstag, 15. Mai 2007 23:49 schrieb Alan Stern: On Tue, 15 May 2007, Oliver Neukum wrote: I think we're getting off the point here. Suppose the usbhid driver gets a powerloss_resume call for a mouse. What do you want it to do that we aren't already doing? Nothing. My point was that powerloss_resume() would be a benefit for every driver. Only that some drivers can't implement it. Okay. In very many cases it should be true that drivers won't try to verify a device's identify in powerloss_resume, since there isn't much they can check that the core hasn't checked already. In these cases powerloss_resume and reset_resume would do exactly the same things. Now consider cases where the driver does perform an identity check. Combine this with a previous remark you made: Devices with the reset_resume quirk are quite rare. Hence such drivers won't stand to lose much if they also do the identify check in reset_resume. Sure it would be unnecessary, but it wouldn't cost much and it would hardly ever happen. In other words, there's never any real reason for powerloss_resume and reset_resume to do different things. So there's no reason to have two separate methods. reset_resume will happen only because of the quirk. But when it happens during an autoresume, we cannot unbind the driver because we don't own the device lock. So what do you want to do then? This would need a separate thread. Yes. Along with all the complications of keeping track of references and making sure the thread gets flushed at the right time. But if a driver does not support reset_resume() and a device is quirky, why would you autosuspend in the first place? You would autosuspend a quirky device for the same reason you autosuspend a normal device: to save power. The fact that it needs a reset to resume isn't necessarily a drawback. I could add a check to prevent autosuspend for quirky devices with a driver that doesn't support reset_resume. Is this really needed? It seems to me that this issue arises only if reset_resume() returns an error. Is there a reason to treat this differently from resume() failing? On a system resume, we can unbind. The only reason to treat it differently is because it occurs in a different context. System resume is different from autoresume, most especially because autoresume is often invoked by the driver itself. When that happens, trying to unbind could lead to deadlock. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007, Pete Zaitcev wrote:
What I would suggest is that when you allocate an URB and DMA'able memory,
you
have to specify which pipe {CONTROL, BULK, INTERRUPT or ISOC} it belongs to.
What do you think?
Just a side note, we are trying to move away from the pipe as a concept,
because it turned out to be ficticious despite being spelled out in the
spec. The real object to which you talk in the device turned out to
be the endpoint, and the spec is deceiptive. So, let's assume that you
want a kind of per-endpoint preallocation.
It's worth pointing out that there already are drivers which
preallocate URBs and memory buffers and then share them among multiple
endpoints. One example is usb-storage.
We have discussed in the past the notion of making URB allocation
per-bus. That would have less impact; not too many drivers share URBs
among different devices (although I think the Bluetooth driver does).
The advantage is that the allocation could then automatically
incorporate an HCD-private area; currently this has to be allocated
separately every time an URB is submitted.
The reason is that in the new USB stack on FreeBSD, the USB transfer
descriptors are allocated along with the data-buffer, so that when you
unsetup an USB transfer, absolutely all memory related to a transfer is
freed. This also has a security implication in that when you have
pre-allocated all buffers and all USB host controller descriptors, you will
never get in the situation of not being able to allocate transfer
descriptors
on the fly, like done on Linux.
It might make more sense to dedicate the transfer descriptors to the
endpoint and not to any particular transfer. This can be done entirely
within the HCD code. However it would not completely solve the problem
of needing to allocate descriptors on the fly, although it would reduce
the impact.
The requirement for massive on-the-fly allocations is a part of Linux
stack that bothered me for a long time. This is especially annoying
for block devices when pressure builds up in the VM, and dirty data
has to be written out to a block storage device attached by USB.
This is somewhat analogous to the problem which exists with NFS.
I don't see how either of these scenarios would be affected. Whether
you do all the other allocations when the URB and its buffers are
allocated or you wait until the URB is submitted, the memory pressure
would still be just as bad.
I suppose we could do one last effort:
- redefine usb_buffer_alloc to allow for endpoint argument
- implement methods in HCDs to allocate and free QPs and xxx_priv
- spell out in documentation very clearly that drivers should
NOT use these facilities by default and only use them when
memory pressure invokes these URBs
This is something which, I think, only Greg Kroah can decide on doing
or not doing.
I am not in favor of such a large change.
Alan Stern
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for hid
On Wed, 16 May 2007, Oliver Neukum wrote:
Here's part #2, the core autosuspend.
@@ -230,12 +239,14 @@ static void hid_irq_in(struct urb *urb)
switch (urb-status) {
case 0: /* success */
+ usbhid_mark_busy(usbhid);
usbhid-retry_delay = 0;
hid_input_report(urb-context, HID_INPUT_REPORT,
urb-transfer_buffer,
urb-actual_length, 1);
break;
case -EPIPE:/* stall */
+ usbhid_mark_busy(usbhid);
clear_bit(HID_IN_RUNNING, usbhid-iofl);
set_bit(HID_CLEAR_HALT, usbhid-iofl);
schedule_work(usbhid-reset_work);
@@ -249,6 +260,7 @@ static void hid_irq_in(struct urb *urb)
case -EPROTO: /* protocol error or unplug */
case -ETIME:/* protocol error or unplug */
case -ETIMEDOUT:/* Should never happen, but... */
+ usbhid_mark_busy(usbhid);
clear_bit(HID_IN_RUNNING, usbhid-iofl);
hid_io_error(hid);
return;
At first I thought it would be easier to call usbhid_mark_busy() at
every URB completion. But obviously you don't want to do it when an
URB is unlinked.
@@ -592,8 +604,21 @@ static int hid_get_class_descriptor(stru
int usbhid_open(struct hid_device *hid)
{
struct usbhid_device *usbhid = hid-driver_data;
+ int res;
- hid-open++;
+ mutex_lock(hid_open_mut);
+ if (!hid-open++) {
+ res = usb_autopm_get_interface(usbhid-intf);
+ /* the device must be awake to reliable request remote wakeup */
+ if (res 0) {
+ hid-open--;
+ mutex_unlock(hid_open_mut);
+ return -EIO;
+ }
+ usbhid-intf-needs_remote_wakeup = 1;
+ usb_autopm_put_interface(usbhid-intf);
+ }
+ mutex_unlock(hid_open_mut);
if (hid_start_in(hid))
hid_io_error(hid);
return 0;
Don't you need to do usb_autopm_get_interface() before hid_start_in()?
@@ -1154,13 +1184,26 @@ static int hid_suspend(struct usb_interf
struct usbhid_device *usbhid = hid-driver_data;
struct usb_device *udev = interface_to_usbdev(intf);
-
- spin_lock_irq(usbhid-inlock);
- set_bit(HID_REPORTED_IDLE, usbhid-iofl);
- spin_unlock_irq(usbhid-inlock);
- if (usbhid_wait_io(hid) 0)
- return -EIO;
-
+ if (udev-auto_pm) {
+ spin_lock_irq(usbhid-inlock); /* Sync with error handler */
+ if (!test_bit(HID_RESET_PENDING, usbhid-iofl)
+ !test_bit(HID_CLEAR_HALT, usbhid-iofl)
+ !test_bit(HID_OUT_RUNNING, usbhid-iofl)
+ !test_bit(HID_CTRL_RUNNING, usbhid-iofl))
+ {
+ set_bit(HID_REPORTED_IDLE, usbhid-iofl);
+ spin_unlock_irq(usbhid-inlock);
+ } else {
+ spin_unlock_irq(usbhid-inlock);
+ return -EBUSY;
+ }
+ } else {
+ spin_lock_irq(usbhid-inlock);
+ set_bit(HID_REPORTED_IDLE, usbhid-iofl);
+ spin_unlock_irq(usbhid-inlock);
+ if (usbhid_wait_io(hid) 0)
+ return -EIO;
+ }
del_timer(usbhid-io_retry);
usb_kill_urb(usbhid-urbin);
flush_scheduled_work();
This might be simpler if you inverted the order of the tests. That is,
first get the spinlock, then test for
udev-auto_pm (test_bit() || test_bit() || ...)
to see if you need to fail right away. You probably don't even need to
check udev-auto_pm again before calling usbhid_wait_io.
@@ -1175,6 +1218,7 @@ static int hid_resume(struct usb_interfa
int status;
clear_bit(HID_REPORTED_IDLE, usbhid-iofl);
+ usbhid_mark_busy(usbhid);
usbhid-retry_delay = 0;
status = hid_start_in(hid);
usbhid_restart_queues(usbhid);
Again, don't you need to call usb_autopm_get_interface() before
hid_start_in()?
One last thing, about the race between a last-minute URB completion and
autosuspend. The USB autosuspend core routine doesn't check the
last_busy value after suspending the interface drivers and before
suspending the device. Do we need to?
Alan Stern
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form
Re: [linux-usb-devel] anchors and their use
On Wed, 16 May 2007, Oliver Neukum wrote: Hi Alan, list, here's the patch to introduce anchors for use with fire-and-forget techniques and a modification for the skeleton driver to use them. This should make implementing pre/post_reset and suspend/resume much easier. This won't build because you forgot to export usb_unanchor_urb(). You could make usb_init_anchor() non-inline. I'm not sure where tradeoff lies, but you might be over the limit. I don't like the way you combined the error handling in usb-skeleton with the anchor stuff. Better to keep the two things in separate patches. There's no need for the version of skel_draw_down() which acquires the mutex. You use it only in skel_flush(), so you might as well acquire the mutex in the caller. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007, David Brownell wrote: I have never, ever, seen USB stack deplete the atomic pool completely either, if this is what you are talking about. So, you're quite right about that. I was referring to the dma_pool allocations ... those don't need to be atomic. OHCI or EHCI tend to allocate a page or so for each type of descriptor seen by the hardware, and usually won't need more than that. UHCI uses more pages; TD-per-packet requirements from the hardware, ISTR (instead of multiple-pages-per-TD). If dma_pool allocation isn't atomic, does that mean it could block for I/O? If yes, then it doesn't belong on the usb-storage I/O path. I have come to think that ub does not dramatically alter the pressure on the atomic pool. It allocates the same QHs and TDs. It's the thread which is the main problem, because it allows for interesting scenarios of deadlocks between kswapd, scsi_eh_0, and usb-storage helper. I am thinking about taking the ub concept and integrating it into usb-storage as some kind of threadless option. If only I could get rid of the SCSI error handling... Agreed, all those threads make things complex ... probably more so than is really needed. I wonder... ub does away with thread complexity by using a complex state machine. Ultimately the complexity lies in the USB mass-storage protocol and in error handling; we can't get away from it no matter how we try. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007, Pete Zaitcev wrote: On Wed, 16 May 2007 10:57:04 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: It's worth pointing out that there already are drivers which preallocate URBs and memory buffers and then share them among multiple endpoints. One example is usb-storage. This is for CBI transport, right? Honestly, I forgot about that. But aren't control transfers short, just commands and replies? Their buffers can be dealiased, *if* need arises. It's also true for bulk-only; the same URB and buffer get used for the IN and the OUT endpoints (CSW and CDB). Yes, we could dealias them if necessary. We have discussed in the past the notion of making URB allocation per-bus. That would have less impact; not too many drivers share URBs among different devices (although I think the Bluetooth driver does). The advantage is that the allocation could then automatically incorporate an HCD-private area; currently this has to be allocated separately every time an URB is submitted. Right. Per-endpoint with a size limits also allows TDs to be preallocated. With a large potential waste of memory! UHCI is so inefficient that the TDs use up almost as much memory as the data to be transferred (within a factor of 2). Do we really want to keep those things around when they're not being used? I don't see how either of these scenarios would be affected. Whether you do all the other allocations when the URB and its buffers are allocated or you wait until the URB is submitted, the memory pressure would still be just as bad. If URB, hcd_priv, and TDs are preallocated, the allocation happens when there's no pressure, and not when all of your memory is dirtied. It can also happen on a process context. At the cost of wasting the memory for the URBs and the TDs when they aren't needed. And this wastage would have to be multiplied by the number of the USB mass-storage devices attached to the system. I suppose we could do one last effort: - redefine usb_buffer_alloc to allow for endpoint argument - implement methods in HCDs to allocate and free QPs and xxx_priv - spell out in documentation very clearly that drivers should NOT use these facilities by default and only use them when memory pressure invokes these URBs This is something which, I think, only Greg Kroah can decide on doing or not doing. I am not in favor of such a large change. Yeah... I mentioned in my reply to David that I would like to explore more narrow approaches, like a threadless ub-like usb-storage. This won't help Hans in any way, though. It's possible that we have moved too far in one direction. Even though you might not want to preallocate things all the time, it would be nice if you had the ability to do it when you wanted to. But of course, it would add code and debugging complexity. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007, Hans Petter Selasky wrote: It is very clear to me that non-blocking memory allocation at the point of starting an USB transfer will require extra error handling in the USB device driver code! It's not so clear to me. My usbd_transfer_start() returns void. Your usb_submit_urb() returns int. URB submission has other failure possibilities than lack of memory. Those other things have to be checked for regardless. Pre-allocating everything you need simply saves code, hence you only check once if you got the memory or not. It doesn't save code. You need to check for the memory when you allocate it, no matter when that is done. One allocation = one check. The total code size is the same if you do the allocation early and only once or if you do it late and many times. It does save execution time. But that's a different matter; it also wastes data space. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007, Hans Petter Selasky wrote: It's also true for bulk-only; the same URB and buffer get used for the IN and the OUT endpoints (CSW and CDB). Yes, we could dealias them if necessary. I would says it is a specification design fault that read and write endpoints are not used at the same time. It's not a specification design fault; the specification says nothing about whether the endpoints are or are not used at the same time. It's a design limitation of the usb-storage driver. With a large potential waste of memory! UHCI is so inefficient that the TDs use up almost as much memory as the data to be transferred (within a factor of 2). Do we really want to keep those things around when they're not being used? That depends largely on wMaxPacketSize. With UHCI, wMaxPacketSize for bulk endpoints is almost always 64, and that's what I was talking about. If wMaxPacketSize is smaller then the ratio is even worse. All devices need to allocate some memory, even if they are not used. That is just the way it is. If you want to save memory, then USB has the advantage that you can unplug the device and save resources. Of course all devices need memory. But there's a big difference between preallocating 4 KB and preallocating 512 KB. And if you start telling people they can save memory by unplugging their USB devices, they'll just laugh at you. Saving memory is the OS's job, not the user's. Most likely I will end up with 16Kbyte buffers on every bulk/interrupt/control endpoint. That should give a maximum transfer rate of approximately 16MB/sec, which is not so bad for ordinary USB gadgets. No doubt you would reduce that amount for hubs, keyboards, and mice. It's not so bad, as you say. Although for mass-storage devices people would want higher transfer rates. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007, Hans Petter Selasky wrote: On Wednesday 16 May 2007 18:25, Alan Stern wrote: On Wed, 16 May 2007, Hans Petter Selasky wrote: It is very clear to me that non-blocking memory allocation at the point of starting an USB transfer will require extra error handling in the USB device driver code! It's not so clear to me. In my new USB stack, I pass all endpoint and buffer size information to usbd_transfer_setup() at attach time: For example: Irrelevant. This doesn't affect the need for error handling later on. My usbd_transfer_start() returns void. Your usb_submit_urb() returns int. URB submission has other failure possibilities than lack of memory. Those other things have to be checked for regardless. Yes, but that is because you allow too many parameters in the URB to be changed between USB transfers. No; it's because unforeseen events can occur. For example, the device may have been unplugged or suspended. Pre-allocating everything you need simply saves code, hence you only check once if you got the memory or not. It doesn't save code. You need to check for the memory when you allocate it, no matter when that is done. Yes, but it is a difference doing it once at attach or doing it every time you start a transfer. Above you said it saves code. That is wrong. One allocation = one check. The total code size is the same if you do the allocation early and only once or if you do it late and many times. It does save execution time. But that's a different matter; it also wastes data space. Yes, it wastes some memory, but that is just how it is. Get used to it :-) I have some times been thinking that USB endpoint descriptors should have supplied some information on the maximum bandwidth supported, so that the USB devices can allocate appropriate buffers. The manufacturers would probably get it wrong anyway. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Patches still in the queue
On Tue, 15 May 2007, Oliver Neukum wrote: Am Montag, 14. Mai 2007 22:09 schrieb Alan Stern: On Mon, 14 May 2007, Oliver Neukum wrote: Am Montag, 14. Mai 2007 20:14 schrieb Alan Stern: On Mon, 14 May 2007, Oliver Neukum wrote: Worse. A driver may _lack_ a post_reset() method. In which case its resume() method gets called, in lieu of anything better. Drivers like that are in trouble whenever their device gets reset, whether it is related to hibernation or not. Well, disconnect() No, it should be up to the driver. Some drivers may not mind if a reset comes along. Yes, and it seems to me that persist should have its own method. Those drivers that don't define it, don't support it. It could have its own method. The method would be nearly identical to post_reset(), since they have to do exactly the same thing as far as the device is concerned. In fact, it probably would call post_reset(). The difference arises because is a reset is expected to be fairly quick, whereas a suspend followed by reset-resume can leave the device idle for a long time. And it's probably better to have a separate method than to pass a flag indicating whether a particular call is really for post_reset or for reset-resume. So I will add a new method pointer. I'm not sure what you want to do with drivers that don't define a reset_resume method. To say they don't support it is like saying they don't support regular resume; it may be true but it doesn't help. We don't unbind drivers with no resume method and we don't unbind drivers with no post_reset method, so why should we unbind drivers with no reset_resume method? Another reason for not doing it is because there's a certain amount of fragility involved in unbinding drivers during a reset-resume (or during any kind of suspend or resume, for that matter). These events can occur without the device lock being held; this happens with autosuspend and autoresume. Hence the unbind would have to be deferred to a different thread -- as in that usb_rebind_interface() patch I wrote. I don't like that approach; it adds too much additional complexity. On the other hand, if a driver doesn't support autosuspend then its device will never be autosuspended or autoresumed. Hence suspend, resume, and reset calls will always occur with the device lock held. In this case it would be safe to allow for rebinding in lieu of resume, post_reset, or reset_resume. What do you think? Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for hid
On Tue, 15 May 2007, Oliver Neukum wrote: Hi, this is autosuspend for HID devices. It uses the new last_busy facility for USB devices. And for a few functions the pm counter. The main problem implementing this is LEDs. HID has the very though property of initiating output to them without user space's involvement from interrupt context to all attached devices. Doing this with suspended devices is problematic. Output requests now go through different code paths depending on whether the device they are intended for is asleep or not. In the suspended case they are merely queued and the queue processed on resume. Upon every input recieved, whether faulty or not, the device is marked busy. The race with output requests is handled with a spinlock. The suspend handler will report a failure if autosuspend wins the race against output, thus solving the problem. Can you break this up into two patches? If the first adds the queuing code and the second adds autosuspend support, it will be much easier to appraise and test them. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Fingerprint reader with CONFIG_USB_SUSPEND
On Mon, 14 May 2007, Ben Gamari wrote: Hey, Here is the output of a similar test to the last with CONFIG_USB_DEBUG. I have also found that if I run watch -n1 lsusb in the background, the device remains stable and I can use the driver. Perhaps it just has some strange transient behavior at startup that takes a while to settle out. Hope this helps. Thanks again, It isn't transient behavior. The fingerprint reader includes an embedded hub, and apparently that hub dies whenever the reader is resumed from a suspend. More precisely, attached to that embedded hub are: a Biometric Coprocessor made by STMicroelectronics (a removable connection), and an O2Micro CCID SC Reader made by O2 (non-removable). The second one looks like the fingerprint reader; I don't know what the first one is. Maybe you can try unplugging it. The second device resumes okay, but the hub dies whenever it tries to resume the first one. That's what the log seems to say. More precise information can be obtained by using the usbmon facility for your usb3 bus (instructions are in the kernel source file Documentation/usb/usbmon.txt). Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Patches still in the queue
On Tue, 15 May 2007, Oliver Neukum wrote: Firstly, perhaps we should unbind if there's no post_reset(). Perhaps so. Secondly, we are asking drivers to do something outside the spec. It's not against the spec, but by no means inside. There is a way to handle power failure in the spec, that is to reenumerate. This is somewhat questionable. I can't find anything in the USB 2.0 spec that directly addresses this situation (maybe the OTG spec has something). But I do agree that it is contrary to the spirit of the spec. In any case, the reset-resume code _does_ reenumerate. So the situation is perhaps not as bad as you think. Thirdly, in some error cases, you _will_ need to reenumerate anyway, eg. firmware gone, configuration cannot be restord, etc... As I said, usb_reset_device() does reenumerate. It handles the examples you mention properly. Fourthly, some drivers cannot do it in principal, because they cannot restore a device's state, eg. printer, scanner, ... Yes. Conversely, some drivers don't care about it at all because they don't maintain any state in the device. Another reason for not doing it is because there's a certain amount of fragility involved in unbinding drivers during a reset-resume (or during any kind of suspend or resume, for that matter). These events can occur without the device lock being held; this happens with You surely want to do this in single threaded manner before user space is unfrozen, don't you? If we're talking about resuming from a system sleep, yes. But the same code paths get used in other circumstances. For example, you may remember the Philips audio device which needs to be reset because it can't resume -- it would get a reset_resume call during normal autoresume processing. Resets can occur whenever userspace requests them via usbfs, just as userspace can force a device to be suspended and resumed. So in any context we may face the possibility of a driver without a resume(), reset_resume(), or post_reset() method. I think that locking matters only for autosuspend/resume. For pre/post_reset the caller initiating the reset should be responsible for locking the device. I don't see your line of reasoning here. Could you elaborate? You are correct that autosuspend and autoresume are the only paths in which the device might not be locked. Hence rebinding a driver would be troublesome only in cases where the driver sets .supports_autosuspend and yet doesn't define both a resume() and a reset_resume() method. In such cases we could skip the rebinding. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Patches still in the queue
On Tue, 15 May 2007, Oliver Neukum wrote: Am Dienstag, 15. Mai 2007 20:40 schrieb Alan Stern: On Tue, 15 May 2007, Oliver Neukum wrote: Fourthly, some drivers cannot do it in principal, because they cannot restore a device's state, eg. printer, scanner, ... Yes. Conversely, some drivers don't care about it at all because they don't maintain any state in the device. That I doubt. There's always the relationship with open files. Usually eg. with mice you don't care because you use /dev/input/mice, but if for any reason you use a specific mouse, you care. That relationship isn't stored in the device! Even if you use a specific mouse, you don't care if the mouse gets reset -- the usbhid driver won't need to restore any of the mouse's state. (Actually that's not quite true, because usbhid uses a set-idle request to prevent the device from sending updates when nothing has changed. The set-idle has to be repeated by the reset_resume method. But you know what I mean...) I think you are mixing things that shouldn't be. Recovery from a loss of power is different from getting reset for resume. In the latter case identity is not in doubt. So then do you want to add _two_ new methods: one for reset_resume and the other for powerloss_resume? If we do, reset_resume will be used only for devices with the USB_QUIRK_RESET_RESUME flag set. A driver that does not resume() but autosuspend is buggy. Plain and simple. reset_resume() method. In such cases we could skip the rebinding. Indeed. But if we do that we must unbind. We can't have undead devices. Not at all -- we should fix the driver! If it claims to support autosuspend then it should also be able to handle reset_resume without any need for rebinding. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] USB: don't try to kzalloc 0 bytes
This patch (as907) prevents us from trying to allocate 0 bytes
when an interface has no endpoint descriptors.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
On Tue, 15 May 2007, Andrew Morton wrote:
Guys, can we teach USB to avoid the zero-sized kmalloc in
usb_get_configuration()
please?
Does this help?
Alan Stern
Index: usb-2.6/drivers/usb/core/config.c
===
--- usb-2.6.orig/drivers/usb/core/config.c
+++ usb-2.6/drivers/usb/core/config.c
@@ -185,10 +185,12 @@ static int usb_parse_interface(struct de
num_ep = USB_MAXENDPOINTS;
}
- len = sizeof(struct usb_host_endpoint) * num_ep;
- alt-endpoint = kzalloc(len, GFP_KERNEL);
- if (!alt-endpoint)
- return -ENOMEM;
+ if (num_ep 0) { /* Can't allocate 0 bytes */
+ len = sizeof(struct usb_host_endpoint) * num_ep;
+ alt-endpoint = kzalloc(len, GFP_KERNEL);
+ if (!alt-endpoint)
+ return -ENOMEM;
+ }
/* Parse all the endpoint descriptors */
n = 0;
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 14/16] USB: Add usbfs ioctl to get the frame number
On Tue, 15 May 2007, Laurent Pinchart wrote: I was just wondering if the USB host controller issued an interrupt when sending an SOF token. If so, it would be quite easy to store the current host timestamp there. If not, I'll live with it. It can if you want it to. Most of the time we don't want it. Imagine trying to live with an interrupt request each and every millisecond! (Or 8 interrupts every millisecond for high-speed.) Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Patches still in the queue
On Tue, 15 May 2007, Oliver Neukum wrote: Yes. Conversely, some drivers don't care about it at all because they don't maintain any state in the device. That I doubt. There's always the relationship with open files. Usually eg. with mice you don't care because you use /dev/input/mice, but if for any reason you use a specific mouse, you care. That relationship isn't stored in the device! Even if you use a The physical identity of the device determines it. specific mouse, you don't care if the mouse gets reset -- the usbhid driver won't need to restore any of the mouse's state. But I do care about my device still being my device. A loss of power does affect that. I think we're getting off the point here. Suppose the usbhid driver gets a powerloss_resume call for a mouse. What do you want it to do that we aren't already doing? Not at all -- we should fix the driver! If it claims to support autosuspend then it should also be able to handle reset_resume without any need for rebinding. Why? Or rather which kind? Quirky devices are very rare. Why would all drivers need to handle that? As for powerloss, a printer driver can never do that, as it cannot restore the printer's setting. Likewise anything claimed by usbfs. There are other examples. Two separate issues: reset_resume will happen only because of the quirk. But when it happens during an autoresume, we cannot unbind the driver because we don't own the device lock. So what do you want to do then? powerloss_resume will happen only when waking up from a system sleep, and since it won't be an autoresume we will own the device lock. Hence we will be able to rebind drivers. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Patches still in the queue
On Mon, 14 May 2007, Oliver Neukum wrote: I agree. Hibernation with a mounted fs on usb sucks, no matter what you do. Don't forget that persistence applies to network interfaces just as much as to block devices. Yes, but it is not problematic, as you run no additional risk. The worst thing that could happen is that you assign an IP to the wrong interface. But if the driver can't tell apart devices, neither can udev. So you've got nothing to lose and a lot to gain. A driver has more information available to it than usbcore does. With a network interface, the driver might be able to distinguish two devices based on their MAC addresses, even when usbcore can't tell them apart. (I really should add Serial Number string checking to the config_descriptors_changed() routine...) However I admit it's hard to think up a scenario where this would matter significantly. I suggest a setting per interface in sysfs. That approach isn't feasible. For one thing, persistence applies to entire devices, not to interfaces. For another, we can't make a device persistent unless we also make all its ancestor hubs persistent. (If a hub disappears during resume then its children are destroyed too.) Well, we have again a distinction between device and interface persistance. Some drivers and therefore interfaces will be unable to support persistance. It must be possible to resurrect only some interfaces of a device. In other words, it must be possible for a driver's post_reset() method to fail. That's a separate email thread. On the core side persistance is asked for if a devices's interface or a device lower in the tree want persistance. While a per-device flag might be workable, I think the most straightforward approach is a single system-wide On/Off setting. Why? Treating a hard drive differently than a floppy seems very reasonable to me. Maybe so, but you're putting a burden on both the core and the user. The core would have to check, when resuming a hub, whether _any_ of the hub's descendants want to be persistent. It can be done but it's messy. And then the user has to decide, for every device that gets attached, whether or not it should be persistent. You know, this problem isn't even unique to USB. Suppose you have an IDE CDROM drive, with a disc loaded and mounted, when you hibernate. Suppose a different disc gets put in the drive before you resume -- then what happens to your mounted filesystem? It's a general problem and it needs to be handled at the filesystem layer. Adding USB persistence doesn't really make it any worse. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Error -28 from usb_submit_urb function.
On Mon, 14 May 2007, Marek Brudka wrote: Hi, The problem was that each webcam application reported :no space left on device. After some experiments I found out that camera works when Bus 002 Device 006: ID 1131:1001 Integrated System Solution Corp. KY-BT100 Bluetooth Adapter is unplugged. It seems that this bluetooth adapter reserves too much bandwidth. Too much is a subjective term. Maybe the webcam reserves too much bandwidth. Quite strange as bluetooth does not usually need too much bandwith. What to do next ? Rmmod the Bluetooth driver (or shut it down some other way, or unplug the device) when you want to use the camera. Or plug the camera into a different USB controller from the Bluetooth device. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Patches still in the queue
On Mon, 14 May 2007, Oliver Neukum wrote: Am Montag, 14. Mai 2007 16:16 schrieb Alan Stern: Well, we have again a distinction between device and interface persistance. Some drivers and therefore interfaces will be unable to support persistance. It must be possible to resurrect only some interfaces of a device. In other words, it must be possible for a driver's post_reset() method to fail. That's a separate email thread. Worse. A driver may _lack_ a post_reset() method. In which case its resume() method gets called, in lieu of anything better. Drivers like that are in trouble whenever their device gets reset, whether it is related to hibernation or not. Maybe so, but you're putting a burden on both the core and the user. The core would have to check, when resuming a hub, whether _any_ of the hub's descendants want to be persistent. It can be done but it's messy. And then the user has to decide, for every device that gets attached, whether or not it should be persistent. It is the same tree logic used to decide whether a hub can be suspended. I suggest solving it the same way. This feature _is_ dangerous. It will be simpler to add a persist attribute for non-hub devices and always assume it is enabled for hubs. I don't think there's any downside to making hubs persistent. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Patches still in the queue
On Mon, 14 May 2007, Oliver Neukum wrote: Am Montag, 14. Mai 2007 20:14 schrieb Alan Stern: On Mon, 14 May 2007, Oliver Neukum wrote: Worse. A driver may _lack_ a post_reset() method. In which case its resume() method gets called, in lieu of anything better. Drivers like that are in trouble whenever their device gets reset, whether it is related to hibernation or not. Well, disconnect() No, it should be up to the driver. Some drivers may not mind if a reset comes along. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 14/16] USB: Add usbfs ioctl to get the frame number
On Sat, 12 May 2007, Pete Zaitcev wrote: On Sat, 12 May 2007 15:40:45 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: timestamp, which would not depend on HC implementing SOF number as a monotonously increasing counter (I think, it's not guaranteed). The frame numbers are guaranteed to be monotonically increasing until they roll over from 2047 to 0 (see 8.3.3, 8.4.3, and 10.2.3 in the USB spec). I see, you're right, of course. I only looked at 8.4.3, and it was somewhat vague. The 10.2.3 places stronger restrictions on the way numbers are generated, although oddly enough it alows a host to keep wider counters than are needed. Indeed, the spec includes this puzzling language: The current (micro)frame number as returned by the host (Host Controller or HCD) is at least 32 bits, although the Host Controller itself is not required to maintain more than 11 bits when operating with full-speed devices or 14 bits when operating with high-speed devices. It's not at all clear what this is supposed to mean. Does it refer to a register in the host controller hardware, or is it talking about the value returned from a driver's subroutine? Does it mean that a 32-bit value is returned, of which only the lowest 11 (or 14) need to be valid? Or does it mean that the driver should maintain a full 32-bit (minimum) counter, where the lowest bits always agree with the value reported by the hardware? Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Patches still in the queue
On Sun, 13 May 2007, Oliver Neukum wrote: Am Samstag, 12. Mai 2007 21:26 schrieb Alan Stern: It could be controlled by both a Kconfig option and a writable module parameter. I'm not sure that would satisfy everybody. But maybe there _is_ no way to satisfy everyone... I agree. Hibernation with a mounted fs on usb sucks, no matter what you do. Don't forget that persistence applies to network interfaces just as much as to block devices. I suggest a setting per interface in sysfs. That approach isn't feasible. For one thing, persistence applies to entire devices, not to interfaces. For another, we can't make a device persistent unless we also make all its ancestor hubs persistent. (If a hub disappears during resume then its children are destroyed too.) While a per-device flag might be workable, I think the most straightforward approach is a single system-wide On/Off setting. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Error -28 from usb_submit_urb function.
On Sun, 13 May 2007, Marek Brudka wrote: Hi, I have a problem with my sn9c102 webcam. After some debugging with Luca Ricolia (see below), Luca recognized that the problem comes from usb_submit_urb function, and probably was introduced recently Um, what was the actual problem? Is it the Error -28 in your Subject line? -28 is -ENOSPC (which explains the error message for your cat command). It means the driver is trying to overcommit the available bandwidth. If you build a kernel with CONFIG_USB_DEBUG turned on, you'll probably see some warning messages in the dmesg log when the error occurs. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Patches still in the queue
On Fri, 11 May 2007, Greg KH wrote: Can you suggest a better way of packaging it to help support the distros? I'm perfectly willing to change the way USB-persist gets enabled, to insure that people don't turn it on unless they really mean to. Is there any way to turn it on at run-time? That would be better for everyone involved so that the feature will always be present and no rebuilding of kernels is needed. Ha! When I first started working on this stuff, it was controlled by a module parameter. Dave Brownell objected then because there was no way for distros to turn it off! It could be controlled by both a Kconfig option and a writable module parameter. I'm not sure that would satisfy everybody. But maybe there _is_ no way to satisfy everyone... Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 14/16] USB: Add usbfs ioctl to get the frame number
On Sat, 12 May 2007, Pete Zaitcev wrote: On Fri, 11 May 2007 23:23:18 -0700, Greg KH [EMAIL PROTECTED] wrote: I thought that you needed to do something with this value pretty quickly, and that by the time you were able to send something back into the kernel, the value would be not correct anymore. But if this is really just like a timestamp, then ok, I have no objection other than it needs to be correct for all host controllers. Greg, I'm sorry if I'm wrong, but it looks you missed the funny part. Danny's device remembers the value that HC circulated in the SOF frame. It then supplies that value alongside some data it returns. By reading the current frame number from HC, Danny's application can tell how many frames back, approximately, these data were generated (this is not the time when it was transferred across USB). The gettimeofday or other kernel-known timestamp is not good enough, because the device does not know it. Actually, I think that a clever design would set an interrupt-out transfer with software initiated timestamp, which would not depend on HC implementing SOF number as a monotonously increasing counter (I think, it's not guaranteed). Oh well. In fact the USB spec does anticipate that people will want to use the SOF values for timing and synchronization, and it goes to great length explaining ways in which that can be done. Timing of the SOF is more reliable than interrupt URBs, because the SOF is guaranteed to be the first transaction in each frame (and also because interrupt-out transfers will be retried in another frame if they fail). The frame numbers are guaranteed to be monotonically increasing until they roll over from 2047 to 0 (see 8.3.3, 8.4.3, and 10.2.3 in the USB spec). Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] EP-0 returns timeout even when data is received by the device.
On Sat, 12 May 2007, Jayaprakash Shanmugam wrote: Hi All, I have a EHCI host connected to 4 USB devices (dev1, dev2, dev3 and dev4). I have two processes that make use of these devices through a kernel object. I have some vendor commands (through EP-0) to all the devices. Apart from this, dev1 has EP2 ( in ) bulk, dev2 has EP2 ( in ) interrupt and dev4 has EP6 ( out ) bulk. There are 3 processes in our system. From Process1, I read EP2 from dev1 periodically (for every 30 ms) and send it to EP6 of dev4. The other process Process2, reads the EP2 interrupt endpoint of dev2 periodically. The last process Process3, tries to write to dev4 EP-0 quite frequently (every 3 seconds). Sometimes, the usb_control_msg() receives timeout error. I am not able to understand why it should return timeout error intermittently. 1) When the control endpoint and bulk endpoint are used in a device, Can I not use both of them simultaneously ? The Linux host software allows it. However the device itself might have some restrictions (although it shouldn't). 2) When I tried to write to EP-0 of a device, the other process who sends periodic data to EP-2 of the same device How can that be? You said above that on both dev1 and dev2, ep2 is in, not out. receives the error message - ep0out timeout error. Why should the process receive this debug message (from the timeout handler in the usb_submit_urb() ) Most likely you misunderstood what happened. Please provide logs demonstrating the problem. 3) When I tried to write to EP-0 of a device (while the other process sending data to EP-2 of the same device periodically), the device received the data succesfully. But, the host says the request is timeout. Does it mean that the ACK for the EP-0 packet is received by the URB who waits for ACK for the Bulk transfer. ep0 transfers involve several packets, so it doesn't make sense to talk about the ACK for the EP-0 packet. If the device receives the data correctly and the host reports a timeout, it means that the device continues to send NAK packets even after it has received the data. This mail may be huge. Since I am not able to understand the behavior I wanted to give the full details of the issue. Note: I am running Linux 2.6 on MPC 8270 with Philips PCI - USB converter 2.6.what? Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] converting appletouch to usb autosuspend...
On Sat, 12 May 2007, Soeren Sonnenburg wrote: Dear all, I've realized using the great powertop ( http://www.linuxpowertop.org/ ) that loading the appletouch driver (and touching it once) makes consumes about 0.3 W even when not touching the pad. As rmmod'ing appletouch fixes this I wonder why the driver does not do this alone. So my question is what does one have to do to convert a driver (such as appletouch) to make use of usb autosuspend except for .supports_autosuspend = 1 One has to add appropriate calls to usb_autopm_get_interface() and usb_autopm_put_interface(), or equally well, to usb_autopm_enable() and usb_autopm_disable(). One might also need to set intf-needs_remote_wakeup to 1 in the probe routine. While we are at it usb related powerhogs on this macbook pro are uhci_hcd (usb keyboard) and usb_hcd_poll_rh_status (rh_timer_func) too... They would use less power if the UHCI host controller were suspended. But obviously it cannot be suspended while devices attached to it (such as the USB keyboard and the appletouch device) remain active. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 14/16] USB: Add usbfs ioctl to get the frame number
On Thu, 10 May 2007, Greg KH wrote: On Fri, May 04, 2007 at 11:56:18AM -0400, Alan Stern wrote: From: Danny Budik [EMAIL PROTECTED] This patch (as899) adds a new ioctl to usbfs: USBDEVFS_GETFRAMENUM. It allows user programs to obtain the current Start-Of-Frame number on a USB bus. Note that the values returned by the get_frame method in the various host controller drivers are not consistent. They should be adjusted so that they provide the actual frame number as it appears on the bus; that is, a number incrementing by one every millisecond, ranging from 0 to 2047. That will have to be done separately; it interacts with the start_frame values used for submitting Isochronous URBs. Signed-off-by: Alan Stern [EMAIL PROTECTED] As this value will be wrong, and will be out-of-date due to timing issues going to userspace and back, I still don't see the use of adding this to our kernel at this point in time. Okay, I'll fix up the HCDs and make them return consistent values first. Then I'll resubmit the patch. The argument about the value being out-of-date because of timing issues doesn't hold water. The same argument applies to gettimeofday(2), but Unix systems have supported that call for a very long time. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Patches still in the queue
On Thu, 10 May 2007, Greg KH wrote: On Thu, May 10, 2007 at 02:10:07PM -0400, Alan Stern wrote: Greg: You have applied most of the patches I sent, but not the USB-persist ones. Any particular reason? The main reason is that I'm still on the road, and I really want to spend the time and test those patches, as I'm still not sure about the use of them. I'm scared because this is not an option that a distro can enable in their releases, and that bad things can happen to people's data if they are not careful. Also I feel that the number of legit users for such a thing is so small that I wonder if it is really worth it. Can you suggest a better way of packaging it to help support the distros? I'm perfectly willing to change the way USB-persist gets enabled, to insure that people don't turn it on unless they really mean to. It's surprising to hear you bring up the small number of legit users! You're on record as saying that the kernel includes code and drivers which exist to support only one or two machines in the whole world. :-) So these are still in my queue, I just want to give them some serious scrutiny. Okay. Suggestions for improvements are welcome. The infrastructure added for USB-persist is also used for a new type of quirks entry (devices which need to be reset when they resume). Would you prefer it if I separate out that common infrastructure and send it along with the quirks code first? Then adding USB-persist on top would be a relatively small change. Sure, if you want to rework it that way, I was holding off applying those other patches as the dependancy was there. If by doing that, we get that new feature in sooner, it would probably be much better. I'll repackage it and resubmit just the infrastructure and quirks part, leaving the rest for later. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] USB: remove short initial timeout for device descriptor fetch
This patch (as905) removes a micro-optimization from the hub port
initialization code. Previously we had been using a short timeout on
the first attempt the read the device descriptor; now we will use the
standard timeout length.
It's not clear that the short timeout ever provided any benefit. And
now we know of one case where it actually hurts: The device can't meet
the short timeout and then it gets terminally confused.
This fixes Bugzilla #8444.
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
@@ -2219,14 +2219,9 @@ hub_port_init (struct usb_hub *hub, stru
continue;
}
- /* Use a short timeout the first time through,
-* so that recalcitrant full-speed devices with
-* 8- or 16-byte ep0-maxpackets won't slow things
-* down tremendously by NAKing the unexpectedly
-* early status stage. Also, retry on all errors;
-* some devices are flakey.
-* 255 is for WUSB devices, we actually need to use 512.
-* WUSB1.0[4.8.1].
+ /* Retry on all errors; some devices are flakey.
+* 255 is for WUSB devices, we actually need to use
+* 512 (WUSB1.0[4.8.1]).
*/
for (j = 0; j 3; ++j) {
buf-bMaxPacketSize0 = 0;
@@ -2234,7 +2229,7 @@ hub_port_init (struct usb_hub *hub, stru
USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
USB_DT_DEVICE 8, 0,
buf, GET_DESCRIPTOR_BUFSIZE,
- (i ? USB_CTRL_GET_TIMEOUT : 1000));
+ USB_CTRL_GET_TIMEOUT);
switch (buf-bMaxPacketSize0) {
case 8: case 16: case 32: case 64: case 255:
if (buf-bDescriptorType ==
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] the usb persist feature
On Fri, 11 May 2007, Oliver Neukum wrote: Hi, it seems to me that you have to allow for drivers failling to restore their devices' state. The obvious way would be to let post_reset() return an error code and treat failure as unplug. To begin with, you don't want to trait failure as unplug. There might be other drivers bound to other interfaces still working perfectly well; there's no reason to mess them up. You might want to treat it as unbind. However I'm not so sure. Failure to restore a device's state is only one of the things that can go wrong with a driver. Lots of other errors can arise too; it doesn't seem right to single one of them out for special treatment by the core. If a device encounters an error, it can simply refuse to do any more work. Return failure for all I/O requests. Or it can try to continue as best it can, probably getting lots of device errors along the way. Now perhaps you would like to add a subroutine to the core, which a driver could call to request that it be unbound. This could be done, although to be safe you'd probably want the actual unbind to occur in a different process context. But I doubt that such a routine would get used. So far nobody seems to have needed it. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] suspend/resume for usb serial devices
On Fri, 11 May 2007, James Graves wrote: Hello Everyone, We've started out testing of suspend / resume support for the Sierra Wireless modem driver. For the testing, we're just putting the laptop into hibernate mode. Suse 10.2 with the 2.6.21 kernel from kernel.org. This is not a good way to test USB suspend/resume code. In hibernate mode it's almost always the case that all USB devices get disconnected, because systems do not provide suspend current to the host controllers. You should use suspend-to-RAM instead. However, upon resume, the system appears to be completely disconnecting the modem, which isn't exactly what we want. As I said. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] the usb persist feature
On Fri, 11 May 2007, Oliver Neukum wrote: You are asking drivers to do something what some of them cannot do in principle. To restore state from scratch you need to know the state the device was in. Many drivers cannot know that. Now perhaps you would like to add a subroutine to the core, which a driver could call to request that it be unbound. This could be done, although to be safe you'd probably want the actual unbind to occur in a different process context. But I doubt that such a routine would get used. So far nobody seems to have needed it. On the contrary. This propblem usually occurs during probe() where it is handled exactly this way. You return an error. The situations aren't parallel. During probe() the driver is supposed to test the device to make sure it really can manage it. Hence it makes sense to return an error. But post_reset() informs the driver that the device has finished being reset. The driver isn't asked to do anything, so it shouldn't return anything. If you wish, I will write a usb_rebind_interface() routine -- provided you can give an example of a driver (other than usb-skeleton) which will use it! Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] the usb persist feature
On Fri, 11 May 2007, Oliver Neukum wrote: Am Freitag, 11. Mai 2007 20:15 schrieb Alan Stern: On the contrary. This propblem usually occurs during probe() where it is handled exactly this way. You return an error. The situations aren't parallel. During probe() the driver is supposed to test the device to make sure it really can manage it. Hence it makes sense to return an error. But post_reset() informs the driver that the device has finished being reset. The driver isn't asked to do anything, so it shouldn't return anything. Ehm, how do you suppose any serial adaptor to handle this without restoring, eg. baud rate, or the network adapters without restoring IP, etc... ? By keeping track of those values in their private data structures. Maybe they don't bother to do so; I'm not familiar with those drivers. So all right, I'll write the routine for you. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] usb_rebind_interface()
On Fri, 11 May 2007, Alan Stern wrote:
Maybe they don't bother to do so; I'm not familiar with those drivers. So
all right, I'll write the routine for you.
And here you go. Better check with Greg to see if there's any objection
to exporting driver_probe_device() from the driver core.
I haven't tested this, but it compiles.
Alan Stern
Index: usb-2.6/drivers/base/base.h
===
--- usb-2.6.orig/drivers/base/base.h
+++ usb-2.6/drivers/base/base.h
@@ -25,7 +25,6 @@ extern int bus_add_driver(struct device_
extern void bus_remove_driver(struct device_driver *);
extern void driver_detach(struct device_driver * drv);
-extern int driver_probe_device(struct device_driver *, struct device *);
extern void sysdev_shutdown(void);
extern int sysdev_suspend(pm_message_t state);
Index: usb-2.6/drivers/base/dd.c
===
--- usb-2.6.orig/drivers/base/dd.c
+++ usb-2.6/drivers/base/dd.c
@@ -200,6 +200,7 @@ int driver_probe_device(struct device_dr
done:
return ret;
}
+EXPORT_SYMBOL_GPL(driver_probe_device);
static int __device_attach(struct device_driver * drv, void * data)
{
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
@@ -1634,6 +1634,73 @@ int usb_driver_set_configuration(struct
}
EXPORT_SYMBOL_GPL(usb_driver_set_configuration);
+struct rebind_interface_request {
+ struct usb_device *udev;
+ struct usb_interface*intf;
+ struct device_driver*driver;
+ struct work_struct work;
+};
+
+/* Worker routine for usb_rebind_interface() */
+static void rebind_interface_work(struct work_struct *work)
+{
+ struct rebind_interface_request *req =
+ container_of(work, struct rebind_interface_request, work);
+ struct device *dev = req-intf-dev;
+
+ if (req-udev-state == USB_STATE_NOTATTACHED)
+ goto done;
+
+ usb_lock_device(req-udev);
+ down(dev-sem);
+ if (device_is_registered(dev) dev-driver == req-driver) {
+ device_release_driver(dev);
+ driver_probe_device(req-driver, dev);
+ }
+ up(dev-sem);
+ usb_unlock_device(req-udev);
+ done:
+ put_driver(req-driver);
+ usb_put_intf(req-intf);
+ usb_put_dev(req-udev);
+ kfree(req);
+}
+
+/**
+ * usb_rebind_interface - Unbind a driver from and then rebind it to an
interface
+ * @intf: the interface whose driver should be unbound and rebound
+ * Context: In process context, must be able to sleep
+ *
+ * If a device interface driver finds itself in a deep hole with no way to
+ * get out (for example, if its post_reset() method is unable to restore
+ * the device's state because the driver doesn't know what that state
+ * should be), it can call this routine. The driver will be unbound and
+ * then rebound, giving it a fresh start at managing the interface.
+ *
+ * The unbind and rebind calls are made from a workqueue, so that the driver's
+ * disconnect() method can run without fear of deadlock.
+ *
+ * Returns 0 if the request was succesfully queued, error code otherwise.
+ * The caller has no way to know whether the queued request will eventually
+ * succeed.
+ */
+int usb_rebind_interface(struct usb_interface *intf)
+{
+ struct rebind_interface_request *req;
+
+ req = kmalloc(sizeof(*req), GFP_KERNEL);
+ if (!req)
+ return -ENOMEM;
+ req-udev = usb_get_dev(interface_to_usbdev(intf));
+ req-intf = usb_get_intf(intf);
+ req-driver = get_driver(intf-dev.driver);
+ INIT_WORK(req-work, rebind_interface_work);
+
+ schedule_work(req-work);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_rebind_interface);
+
// synchronous request completion model
EXPORT_SYMBOL(usb_control_msg);
EXPORT_SYMBOL(usb_bulk_msg);
Index: usb-2.6/include/linux/device.h
===
--- usb-2.6.orig/include/linux/device.h
+++ usb-2.6/include/linux/device.h
@@ -530,6 +530,7 @@ extern void device_release_driver(struct
extern int __must_check device_attach(struct device * dev);
extern int __must_check driver_attach(struct device_driver *drv);
extern int __must_check device_reprobe(struct device *dev);
+extern int driver_probe_device(struct device_driver *, struct device *);
/*
* Easy functions for dynamically creating devices on the fly
Index: usb-2.6/include/linux/usb.h
===
--- usb-2.6.orig/include/linux/usb.h
+++ usb-2.6/include/linux/usb.h
@@ -1322,8 +1322,9 @@ extern int usb_clear_halt(struct usb_dev
extern int usb_reset_configuration(struct usb_device *dev);
extern int usb_set_interface(struct usb_device *dev, int ifnum, int alternate);
-/* this request isn't
Re: [linux-usb-devel] [PROBLEM] ueagle-atm modem and usb mouse
On Wed, 9 May 2007, Stanislaw Gruszka wrote: Can you please provide the dmesg log from the Pentium-2 machine with UHCI and with CONFIG_USB_DEBUG set? Show what happens when you connect the mouse and then plug in the ueagle-atm device. Ok, in dmesk.2 the modem is connected when there is open /dev/input/mouse file (for about 1 second). I can read data until close file and open it again. This looks like it's all working properly. When the mouse device is opened it reserves 93 us of bandwidth. When the ueagle-atm driver puts the modem into the highest-speed setting, it tries to allocate 36 + 794 us, for a total of 923 us. This is more than the 900 us maximum bandwidth allowed by the USB spec for periodic transfers, so the attempt fails. In this situation the ueagle-atm driver ought to fall back to a slower setting. Conversely, if the modem is already running (and using 830 us of bandwidth) when you open the mouse device file, the mouse driver won't be able to allocate its 93 us. But if you would close the mouse device file and turn off the modem, then the next time you open the mouse file it ought to work. You shouldn't need to unplug the mouse. Can you try doing that experiment? If it doesn't work then send the dmesg log. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] driver-core: don't free devt_attr till the device is released
On Thu, 10 May 2007, Tejun Heo wrote: Currently, devt_attr for the dev file is freed immediately on device removal, but if the dev sysfs file is open when a device is removed, sysfs will access its attribute structure for further access including close resulting in jumping to garbled address. Fix it by postponing freeing devt_attr to device release time. Note that devt_attr for class_device is already freed on release. This bug is reported by Chris Rankin as bugzilla bug#8198. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Chris Rankin [EMAIL PROTECTED] --- Applies well to 2.6.20 and 21. As sysfs-immediate-disconnect doesn't seem to be included in 2.6.22, this should be included in linus#master too (applies well there as well). Although sysfs-immediate-disconnect may not be included in 2.6.22, the old attribute-orphan code by Oliver Neukum is present there and also in 2.6.21. Shouldn't that suffice? Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] USB: Fix up bogus bInterval values in endpoint descriptors
This patch (as904) adds code to check for endpoint descriptor bInterval
values outside the legal limits. Illegal values are set to 32 ms, which
seems like a reasonable default.
This fixes Bugzilla #8432.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Index: usb-2.6/drivers/usb/core/config.c
===
--- usb-2.6.orig/drivers/usb/core/config.c
+++ usb-2.6/drivers/usb/core/config.c
@@ -1,4 +1,5 @@
#include linux/usb.h
+#include linux/usb/ch9.h
#include linux/module.h
#include linux/init.h
#include linux/slab.h
@@ -49,7 +50,7 @@ static int usb_parse_endpoint(struct dev
unsigned char *buffer0 = buffer;
struct usb_endpoint_descriptor *d;
struct usb_host_endpoint *endpoint;
- int n, i;
+ int n, i, j;
d = (struct usb_endpoint_descriptor *) buffer;
buffer += d-bLength;
@@ -84,6 +85,45 @@ static int usb_parse_endpoint(struct dev
memcpy(endpoint-desc, d, n);
INIT_LIST_HEAD(endpoint-urb_list);
+ /* If the bInterval value is outside the legal range,
+* set it to a default value: 32 ms */
+ i = 0; /* i = min, j = max, n = default */
+ j = 255;
+ if (usb_endpoint_xfer_int(d)) {
+ i = 1;
+ switch (to_usb_device(ddev)-speed) {
+ case USB_SPEED_HIGH:
+ n = 9; /* 32 ms = 2^(9-1) uframes */
+ j = 16;
+ break;
+ default:/* USB_SPEED_FULL or _LOW */
+ /* For low-speed, 10 ms is the official minimum.
+* But some overclocked devices might want faster
+* polling so we'll allow it. */
+ n = 32;
+ break;
+ }
+ } else if (usb_endpoint_xfer_isoc(d)) {
+ i = 1;
+ j = 16;
+ switch (to_usb_device(ddev)-speed) {
+ case USB_SPEED_HIGH:
+ n = 9; /* 32 ms = 2^(9-1) uframes */
+ break;
+ default:/* USB_SPEED_FULL */
+ n = 6; /* 32 ms = 2^(6-1) frames */
+ break;
+ }
+ }
+ if (d-bInterval i || d-bInterval j) {
+ dev_warn(ddev, config %d interface %d altsetting %d
+ endpoint 0x%X has an invalid bInterval %d,
+ changing to %d\n,
+ cfgno, inum, asnum,
+ d-bEndpointAddress, d-bInterval, n);
+ endpoint-desc.bInterval = n;
+ }
+
/* Skip over any Class Specific or Vendor Specific descriptors;
* find the next endpoint or interface descriptor */
endpoint-extra = buffer;
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Patches still in the queue
Greg: You have applied most of the patches I sent, but not the USB-persist ones. Any particular reason? The infrastructure added for USB-persist is also used for a new type of quirks entry (devices which need to be reset when they resume). Would you prefer it if I separate out that common infrastructure and send it along with the quirks code first? Then adding USB-persist on top would be a relatively small change. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
