Re: [linux-usb-devel] autosuspend for hid
Oliver Neukum schrieb: Am Dienstag, 15. Mai 2007 16:43 schrieb Robert Marquardt: Oliver Neukum schrieb: 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. Is that setting the keyboard LEDs? That I've tested it with. But the HID spec is very versatile. Other devices can use it, too. Regards Oliver Writing reports to a device from kernel? Why would that be needed? I even see no reason to do it at all. The virtual keyboard should live at the border to user mode or even fully in user mode. There should only two system devices (like in Windows) mouse and keyboard. Only keyboards are writable at all (mice may be writable, but not from the virtual mouse point of view). - 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 about EHCI PCI/platform drivers
David Brownell wrote: On Sunday 13 May 2007, Tzachi Perelstein wrote: Hello, I'm working on EHCI HC glue port for Marvell Orion SoC. The Orion has a PCI/PCIE interfaces as well as an integrated USB controller. While looking at ehci-hcd.c it looks like there's some kind of dependency between PCI_DRIVER and PLATFORM_DRIVER. I saw some previous threads about the ehci-fsl.c regarding this issue, but I'm not sure I understand, for example, why in module_init if pci_register_driver fails the platform driver is unregistered? Shouldn't these two types of drivers be independent? If the platform has PCI but you can't register a PCI driver, it's quite broken. How broken must a platform be before you fix those bugs, rather than expect drivers to work around them? I have no problem with my PCI, it works just fine! Who said anything about bugs workaround??? I was just wondering if there is a _real_ reason why *if* pci_register_driver fails then the platform driver will be unregistered. Theoretically it could be that PCI will fail but platform driver will work ok, so why unregistering it?? Why not just dumping an error message and continuing?? - 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 2.6.21] Usb Serial Keyspan: add support for USA-49WG USA-28XG
On Tue, May 15, 2007 at 03:32:18PM -0700, Lucy McCoy wrote: Add support for Keyspan adapters: USA-49WG and USA-28XG Yeah! Thanks for doing this, I was beginning to wonder about these devices as I had a few users ask about them recently. Signed-off-by: Lucy P. McCoy [EMAIL PROTECTED] --- diff -uprN -X linux-2.6.21-vanilla/Documentation/dontdiff linux-2.6.21-vanilla/drivers/usb/serial/keyspan.c linux-2.6.21-lpm/drivers/usb/serial/keyspan.c --- linux-2.6.21-vanilla/drivers/usb/serial/keyspan.c2007-04-25 20:08:32.0 -0700 +++ linux-2.6.21-lpm/drivers/usb/serial/keyspan.c2007-05-04 13:35:23.0 -0700 Ugh, somehow your email client word-wrapped everything and stripped out all of the tabs from your patch :( Can you try resending this to me, and in worse case, as an attachment? thanks, greg k-h - 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
Am Mittwoch, 16. Mai 2007 08:41 schrieb Robert Marquardt: Oliver Neukum schrieb: Am Dienstag, 15. Mai 2007 16:43 schrieb Robert Marquardt: Oliver Neukum schrieb: 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. Is that setting the keyboard LEDs? That I've tested it with. But the HID spec is very versatile. Other devices can use it, too. Regards Oliver Writing reports to a device from kernel? Why would that be needed? It is in my experience mainly needed for setting and clearing the LEDs. But I don't claim to know all input devices in the kernel tree. I even see no reason to do it at all. The virtual keyboard should live at the border to user mode or even fully in user mode. There should only two system devices (like in Windows) mouse and keyboard. Only keyboards The mouse is not a system device in that sense. are writable at all (mice may be writable, but not from the virtual mouse point of view). Preserving the LEDs working under the worst circumstances is important. I am not sure whether it is a good thing that all keyboards share CAPS LOCK, etc... , but that's a wider issue. Regards Oliver - 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
Oliver Neukum schrieb: Writing reports to a device from kernel? Why would that be needed? It is in my experience mainly needed for setting and clearing the LEDs. But I don't claim to know all input devices in the kernel tree. Does hat really have to be handled on low-level? It should be possible to forbid such interactions on the lower levels without getting regressions. Preserving the LEDs working under the worst circumstances is important. I am not sure whether it is a good thing that all keyboards share CAPS LOCK, etc... , but that's a wider issue. If handled at higher levels there are two way to handle suspended keyboard. Either first wake it up or decide to not write to it. I do know about special keyboards which do not have a concept of CAPS LOCK, SCROLL LOCK or NUM LOCK at all for the simple reason of not having the corresponding keys. Personally i do not think the keyboards should be held in sync (aka having a single virtual keyboard). - 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
Am Mittwoch, 16. Mai 2007 10:24 schrieb Robert Marquardt: Oliver Neukum schrieb: Writing reports to a device from kernel? Why would that be needed? It is in my experience mainly needed for setting and clearing the LEDs. But I don't claim to know all input devices in the kernel tree. Does hat really have to be handled on low-level? It should be possible to forbid such interactions on the lower levels without getting regressions. Where would you put it? To make things easier it would have to be on a work queue and thus subject to kernel threads being scheduled. Preserving the LEDs working under the worst circumstances is important. I am not sure whether it is a good thing that all keyboards share CAPS LOCK, etc... , but that's a wider issue. If handled at higher levels there are two way to handle suspended keyboard. Either first wake it up or decide to not write to it. Yes, but we cannot drop the LEDs if CAPS_LOCK is common to all keyboards. I do know about special keyboards which do not have a concept of CAPS LOCK, SCROLL LOCK or NUM LOCK at all for the simple reason of not having the corresponding keys. Personally i do not think the keyboards should be held in sync (aka having a single virtual keyboard). That is a whole new debate. Feel free to start it on the input list. Regards Oliver - 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, Robert Marquardt wrote: Writing reports to a device from kernel? Why would that be needed? It is in my experience mainly needed for setting and clearing the LEDs. But I don't claim to know all input devices in the kernel tree. Does hat really have to be handled on low-level? It should be possible to forbid such interactions on the lower levels without getting regressions. Hi Robert, first, why did you remove me from CC when responding? Anyway, what would be your proposal here? Currently the output reports (for changing the keyboard LEDs, for example) are being submitted as soon as the corresponding input event occurs (on different keyboard), which makes sense. Could you be more elaborate on what are the exact drawbacks you see here, and what would your proposal be? (postponing it into workqueue? why?). Thanks. If handled at higher levels there are two way to handle suspended keyboard. Either first wake it up or decide to not write to it. If you decide not to write to it, it will get out of sync with all other keyboards attached to the system once it is woken up. I do know about special keyboards which do not have a concept of CAPS LOCK, SCROLL LOCK or NUM LOCK at all for the simple reason of not having the corresponding keys. Personally i do not think the keyboards should be held in sync (aka having a single virtual keyboard). If you think so, please raise this on linux-input mailing list (and CC at least me and Dmitry). Thanks, -- Jiri Kosina - 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: this is autosuspend for HID devices. It uses the new last_busy facility for USB devices. And for a few functions the pm counter. Hi Oliver, just a quick immediate note - I just tested it on my testing box, and it doesn't seem to work for me - the USB keyboard still seems to be awake (leds are on), even if I echo 0 into 'autosuspend' file in sysfs in order to suspend it immediately. I will investigate. Thanks, -- Jiri Kosina SUSE Labs - 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
Jiri Kosina schrieb: first, why did you remove me from CC when responding? Sorry, on too many lists with widely varying reply rules. Just goofed. Anyway, what would be your proposal here? Currently the output reports (for changing the keyboard LEDs, for example) are being submitted as soon as the corresponding input event occurs (on different keyboard), which makes sense. Could you be more elaborate on what are the exact drawbacks you see here, and what would your proposal be? (postponing it into workqueue? why?). The basic problem is the difference between CAPS LOCK event and CAPS LOCK state. The state may be in user space only. Windows even has it on a per process base (At least theoretically. It is not very well documented what the difference between GetKeyState and GetAsyncKeyState is). I do know about special keyboards which do not have a concept of CAPS LOCK, SCROLL LOCK or NUM LOCK at all for the simple reason of not having the corresponding keys. Personally i do not think the keyboards should be held in sync (aka having a single virtual keyboard). If you think so, please raise this on linux-input mailing list (and CC at least me and Dmitry). When i find time (yet another list to subscribe to). - 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
Am Mittwoch, 16. Mai 2007 11:24 schrieb Jiri Kosina: On Tue, 15 May 2007, Oliver Neukum wrote: this is autosuspend for HID devices. It uses the new last_busy facility for USB devices. And for a few functions the pm counter. Hi Oliver, just a quick immediate note - I just tested it on my testing box, and it doesn't seem to work for me - the USB keyboard still seems to be awake (leds are on), even if I echo 0 into 'autosuspend' file in sysfs in order to suspend it immediately. I will investigate. You have compiled it with CONFIG_USB_SUSPEND, haven't you? Regards Oliver - 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, Robert Marquardt wrote: Anyway, what would be your proposal here? Currently the output reports (for changing the keyboard LEDs, for example) are being submitted as soon as the corresponding input event occurs (on different keyboard), which makes sense. Could you be more elaborate on what are the exact drawbacks you see here, and what would your proposal be? (postponing it into workqueue? why?). The basic problem is the difference between CAPS LOCK event and CAPS LOCK state. The state may be in user space only. Windows even has it on We have the LEDs states per-terminal. I do not think that changing this is going to happen. If you think so, please raise this on linux-input mailing list (and CC at least me and Dmitry). When i find time (yet another list to subscribe to). You don't have to be subscribed to post into this mailinglist. Thanks, -- Jiri Kosina - 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
Am Mittwoch, 16. Mai 2007 11:24 schrieb Jiri Kosina: just a quick immediate note - I just tested it on my testing box, and it doesn't seem to work for me - the USB keyboard still seems to be awake (leds are on), even if I echo 0 into 'autosuspend' file in sysfs in order to suspend it immediately. I will investigate. And as a sanity check, please check with lsusb whether your keyboard can do remote wakeup. I've never seen one that doesn't but it is within spec. Regards Oliver -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) This signature is a legal requirement - 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: just a quick immediate note - I just tested it on my testing box, and it doesn't seem to work for me - the USB keyboard still seems to be awake (leds are on), even if I echo 0 into 'autosuspend' file in sysfs in order to suspend it immediately. I will investigate. You have compiled it with CONFIG_USB_SUSPEND, haven't you? I have, of course :) Otherwise I won't even have the 'autosuspend' file in sysfs, for example. -- Jiri Kosina SUSE Labs - 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: And as a sanity check, please check with lsusb whether your keyboard can do remote wakeup. I've never seen one that doesn't but it is within spec. Suspending of this keyboard used to work with older versions of your patches you sent me some weeks/months ago. -- Jiri Kosina SUSE Labs - 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
Jiri Kosina schrieb: just a quick immediate note - I just tested it on my testing box, and it doesn't seem to work for me - the USB keyboard still seems to be awake (leds are on), even if I echo 0 into 'autosuspend' file in sysfs in order to suspend it immediately. Ah, that was nagging me. Is it at all possible to suspend a keyboard if you want to have the LEDs always in sync with their state? A suspended bus-powered USB device cannot drive LEDs so suspending an USB keyboard with CAPS LOCK on means it gets out of sync. - 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, Robert Marquardt wrote: just a quick immediate note - I just tested it on my testing box, and it doesn't seem to work for me - the USB keyboard still seems to be awake (leds are on), even if I echo 0 into 'autosuspend' file in sysfs in order to suspend it immediately. Ah, that was nagging me. Is it at all possible to suspend a keyboard if you want to have the LEDs always in sync with their state? A suspended bus-powered USB device cannot drive LEDs so suspending an USB keyboard with CAPS LOCK on means it gets out of sync. I don't think that there is a better approach than what Oliver's code is currently doing - i.e. if the keyboard goes to sleep, queue the output reports which would change the state of the leds, and send them either when the keyboard wakes up, or when the queue is too long. Or we can simply just make any output report wake the device up. So this is going to make the leds state consistent as soon as the keyboard is woken up. This is also a reason why this is not going to fly with PID devices - we really want the force feedback to happen immediately, for example. -- Jiri Kosina SUSE Labs - 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
Am Mittwoch, 16. Mai 2007 11:41 schrieb Jiri Kosina: On Wed, 16 May 2007, Oliver Neukum wrote: And as a sanity check, please check with lsusb whether your keyboard can do remote wakeup. I've never seen one that doesn't but it is within spec. Suspending of this keyboard used to work with older versions of your patches you sent me some weeks/months ago. Yes, then it should keep working. My keyboard does suspend. Could you post your syslog? Regards Oliver PS: Sorry about the stupid questions. I've just seen to many things go stupidly wrong - 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
Am Mittwoch, 16. Mai 2007 11:40 schrieb Robert Marquardt: Jiri Kosina schrieb: just a quick immediate note - I just tested it on my testing box, and it doesn't seem to work for me - the USB keyboard still seems to be awake (leds are on), even if I echo 0 into 'autosuspend' file in sysfs in order to suspend it immediately. Ah, that was nagging me. Is it at all possible to suspend a keyboard if you want to have the LEDs always in sync with their state? The current code will resync when the keyboard is resumed. It should do so automatically if too many output requests are queued. That doesn't work yet and I am hunting that bug. A suspended bus-powered USB device cannot drive LEDs so suspending an USB keyboard with CAPS LOCK on means it gets out of sync. How much power does an LED need? You have 2mA in suspended mode. Regards Oliver -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) This signature is a legal requirement - 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
Am Mittwoch, 16. Mai 2007 11:48 schrieb Jiri Kosina: On Wed, 16 May 2007, Robert Marquardt wrote: just a quick immediate note - I just tested it on my testing box, and it doesn't seem to work for me - the USB keyboard still seems to be awake (leds are on), even if I echo 0 into 'autosuspend' file in sysfs in order to suspend it immediately. Ah, that was nagging me. Is it at all possible to suspend a keyboard if you want to have the LEDs always in sync with their state? A suspended bus-powered USB device cannot drive LEDs so suspending an USB keyboard with CAPS LOCK on means it gets out of sync. I don't think that there is a better approach than what Oliver's code is currently doing - i.e. if the keyboard goes to sleep, queue the output reports which would change the state of the leds, and send them either when the keyboard wakes up, or when the queue is too long. Or we can simply just make any output report wake the device up. Actually, there's currently a race in the code that can trigger if you have multiple keyboards. Suppose the system is going to hibernate. One keyboard is suspended and the other is not yet. You hit a key causing an LED message and the queue reaches the threshold. You'd have active DMA while a snapshot is done. So this is going to make the leds state consistent as soon as the keyboard is woken up. This is also a reason why this is not going to fly with PID devices - we really want the force feedback to happen immediately, for example. It is my understanding that a PID effect can be active long after the message went out to the device. Is that correct? Regards Oliver - 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
Oliver Neukum schrieb: Am Mittwoch, 16. Mai 2007 11:40 schrieb Robert Marquardt: Jiri Kosina schrieb: just a quick immediate note - I just tested it on my testing box, and it doesn't seem to work for me - the USB keyboard still seems to be awake (leds are on), even if I echo 0 into 'autosuspend' file in sysfs in order to suspend it immediately. Ah, that was nagging me. Is it at all possible to suspend a keyboard if you want to have the LEDs always in sync with their state? The current code will resync when the keyboard is resumed. It should do so automatically if too many output requests are queued. That doesn't work yet and I am hunting that bug. A suspended bus-powered USB device cannot drive LEDs so suspending an USB keyboard with CAPS LOCK on means it gets out of sync. How much power does an LED need? You have 2mA in suspended mode. A standard LED uses about 20 mA and you have 3 of them for a keyboard. That is the reason why wireless keyboard do not have LEDs. So in suspend the keyboard must switch off the LEDs which in turn means either keyboards cannot autosuspend at all or you have to allow that the LEDs obn the keyboard are sometimes not in sync with their state. BTW is the keyboard not required restore the the LEDs on its own when resuming? - 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: Actually, there's currently a race in the code that can trigger if you It is my understanding that a PID effect can be active long after the message went out to the device. Is that correct? Yes, I am afraid you can't assume that the effect playback has been already completed. -- Jiri Kosina SUSE Labs - 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
Am Dienstag, 15. Mai 2007 16:37 schrieb Alan Stern:
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.
Here's part #2, the core autosuspend.
Regards
Oliver
--
--- linux-2.6.22-rc1/drivers/hid/usbhid/hid-core.c 2007-05-16
12:23:26.0 +0200
+++ linux-2.6.22-rc1-autosuspend/drivers/hid/usbhid/hid-core.c 2007-05-15
19:22:13.0 +0200
@@ -64,6 +64,8 @@ MODULE_PARM_DESC(quirks, Add/modify USB
/*
* Input submission and I/O error handler.
*/
+static DEFINE_MUTEX(hid_open_mut);
+
static void hid_io_error(struct hid_device *hid);
static int hid_submit_out(struct hid_device *hid);
static int hid_submit_ctrl(struct hid_device *hid);
@@ -180,6 +182,13 @@ done:
spin_unlock_irqrestore(usbhid-inlock, flags);
}
+static void usbhid_mark_busy(struct usbhid_device *usbhid)
+{
+ struct usb_interface *intf = usbhid-intf;
+
+ usb_mark_last_busy(interface_to_usbdev(intf));
+}
+
static int usbhid_restart_out_queue(struct usbhid_device *usbhid)
{
struct hid_device *hid = usb_get_intfdata(usbhid-intf);
@@ -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;
@@ -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;
@@ -603,10 +628,13 @@ void usbhid_close(struct hid_device *hid
{
struct usbhid_device *usbhid = hid-driver_data;
+ mutex_lock(hid_open_mut);
if (!--hid-open) {
usb_kill_urb(usbhid-urbin);
flush_scheduled_work();
+ usbhid-intf-needs_remote_wakeup = 0;
}
+ mutex_unlock(hid_open_mut);
}
/*
@@ -730,7 +758,9 @@ static void __usbhid_restart_queues(stru
struct usbhid_device *usbhid =
container_of(work, struct usbhid_device, restart_work);
+ usb_autopm_get_interface(usbhid-intf);
usbhid_restart_queues(usbhid);
+ usb_autopm_put_interface(usbhid-intf);
}
static void hid_free_buffers(struct usb_device *dev, struct hid_device *hid)
@@ -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
Re: [linux-usb-devel] autosuspend for hid
Am Mittwoch, 16. Mai 2007 12:01 schrieb Robert Marquardt: A suspended bus-powered USB device cannot drive LEDs so suspending an USB keyboard with CAPS LOCK on means it gets out of sync. How much power does an LED need? You have 2mA in suspended mode. A standard LED uses about 20 mA and you have 3 of them for a keyboard. That is the reason why wireless keyboard do not have LEDs. That's useful info. So in suspend the keyboard must switch off the LEDs which in turn means either keyboards cannot autosuspend at all or you have to allow that the LEDs obn the keyboard are sometimes not in sync with their state. Yes. The same way a blanked screen is not in sync with X's view of screen content. BTW is the keyboard not required restore the the LEDs on its own when resuming? The keyboard's view of the status might be outdated. Regards Oliver - 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] anchors and their use
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.
Regards
Oliver
--
--- a/include/linux/usb.h 2007-05-04 10:50:18.0 +0200
+++ b/include/linux/usb.h 2007-05-08 12:47:27.0 +0200
@@ -958,11 +958,26 @@ struct usb_iso_packet_descriptor {
struct urb;
+struct usb_anchor {
+ struct list_head urb_list;
+ wait_queue_head_t wait;
+ spinlock_t lock;
+};
+
+static inline void init_usb_anchor(struct usb_anchor *anchor)
+{
+ INIT_LIST_HEAD(anchor-urb_list);
+ init_waitqueue_head(anchor-wait);
+ spin_lock_init(anchor-lock);
+}
+
typedef void (*usb_complete_t)(struct urb *);
/**
* struct urb - USB Request Block
* @urb_list: For use by current owner of the URB.
+ * @anchor_list: membership in the list of an anchor
+ * @anchor: to anchor URBs to a common mooring
* @pipe: Holds endpoint number, direction, type, and more.
* Create these values with the eight macros available;
* usb_{snd,rcv}TYPEpipe(dev,endpoint), where the TYPE is ctrl
@@ -1135,6 +1150,8 @@ struct urb
/* public: documented fields in the urb that can be used by drivers */
struct list_head urb_list; /* list head for use by the urb's
* current owner */
+ struct list_head anchor_list; /* the URB may be anchored by the
driver */
+ struct usb_anchor *anchor;
struct usb_device *dev; /* (in) pointer to associated device */
unsigned int pipe; /* (in) pipe information */
int status; /* (return) non-ISO status */
@@ -1270,6 +1287,10 @@ 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, int
timeout);
void *usb_buffer_alloc (struct usb_device *dev, size_t size,
gfp_t mem_flags, dma_addr_t *dma);
--- a/drivers/usb/core/hcd.c2007-05-04 12:04:29.0 +0200
+++ b/drivers/usb/core/hcd.c2007-05-07 15:19:01.0 +0200
@@ -1408,6 +1408,8 @@ void usb_hcd_giveback_urb (struct usb_hc
}
usbmon_urb_complete (hcd-self, urb);
+ usb_unanchor_urb(urb);
+
/* pass ownership to the completion handler */
urb-complete (urb);
atomic_dec (urb-use_count);
--- a/drivers/usb/core/urb.c2007-05-04 10:53:14.0 +0200
+++ b/drivers/usb/core/urb.c2007-05-16 11:32:15.0 +0200
@@ -4,6 +4,7 @@
#include linux/slab.h
#include linux/init.h
#include linux/usb.h
+#include linux/wait.h
#include hcd.h
#define to_urb(d) container_of(d, struct urb, kref)
@@ -11,6 +12,7 @@
static void urb_destroy(struct kref *kref)
{
struct urb *urb = to_urb(kref);
+
kfree(urb);
}
@@ -34,6 +36,7 @@ void usb_init_urb(struct urb *urb)
memset(urb, 0, sizeof(*urb));
kref_init(urb-kref);
spin_lock_init(urb-lock);
+ INIT_LIST_HEAD(urb-anchor_list);
}
}
@@ -100,8 +103,55 @@ struct urb * usb_get_urb(struct urb *urb
kref_get(urb-kref);
return urb;
}
-
-
+
+/**
+ * usb_anchor_urb - anchors an URB while it is processed
+ * @urb: pointer to the urb to anchor
+ * @anchor: pointer to the anchor
+ *
+ * This can be called to have access to URBs which are to be executed
+ * without bothering to track them
+ */
+
+void usb_anchor_urb(struct urb *urb, struct usb_anchor *anchor)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(anchor-lock, flags);
+ usb_get_urb(urb);
+ list_add_tail(urb-anchor_list, anchor-urb_list);
+ urb-anchor = anchor;
+ spin_unlock_irqrestore(anchor-lock, flags);
+}
+
+/**
+ * usb_unanchor_urb - unanchors an URB
+ * @urb: pointer to the urb to anchor
+ *
+ * Call this to stop the system keeping track of this URB
+ */
+
+void usb_unanchor_urb(struct urb *urb)
+{
+ unsigned long flags;
+ struct usb_anchor *anchor;
+
+ if (!urb)
+ return;
+
+ anchor = urb-anchor;
+ if (!anchor)
+ return;
+
+ spin_lock_irqsave(anchor-lock, flags);
+ urb-anchor = NULL;
+ list_del(urb-anchor_list);
+ spin_unlock_irqrestore(anchor-lock, flags);
+ usb_put_urb(urb);
+ if (list_empty(anchor-urb_list))
+ wake_up(anchor-wait);
+}
+
/*---*/
/**
@@ -477,12 +527,56 @@ void
[linux-usb-devel] [patch]quirky dongle for hci_usb
Hi,
here's an additional device with the reset quirk.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
--
--- a/drivers/bluetooth/hci_usb.c 2007-05-15 14:09:55.0 +0200
+++ b/drivers/bluetooth/hci_usb.c 2007-05-16 07:50:16.0 +0200
@@ -142,6 +142,9 @@ static struct usb_device_id blacklist_id
/* Frontline ComProbe Bluetooth Sniffer */
{ USB_DEVICE(0x16d3, 0x0002), .driver_info = HCI_SNIFFER },
+ /* Broadcom Corp - BCM2045 */
+ { USB_DEVICE(0x413c, 0x8126), .driver_info = HCI_RESET },
+
{ } /* Terminating entry */
};
-
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]quirky dongle for hci_usb
Hi Oliver,
here's an additional device with the reset quirk.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
that patch doesn't apply since we already have this:
/* Dell laptop with Broadcom chip */
{ USB_DEVICE(0x413c, 0x8126), .driver_info = HCI_WRONG_SCO_MTU },
Why do you think HCI_RESET is needed? Did Dell switched to using a HID
proxy dongle or what?
Regards
Marcel
-
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]quirky dongle for hci_usb
Am Mittwoch, 16. Mai 2007 13:50 schrieb Marcel Holtmann:
Hi Oliver,
here's an additional device with the reset quirk.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
that patch doesn't apply since we already have this:
/* Dell laptop with Broadcom chip */
{ USB_DEVICE(0x413c, 0x8126), .driver_info = HCI_WRONG_SCO_MTU },
Why do you think HCI_RESET is needed? Did Dell switched to using a HID
proxy dongle or what?
A user reported that his dongle needs a reset to work. A manual reset, the
module option and that patch solved the issue.
Regards
Oliver
-
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]quirky dongle for hci_usb
Hi Oliver,
here's an additional device with the reset quirk.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
that patch doesn't apply since we already have this:
/* Dell laptop with Broadcom chip */
{ USB_DEVICE(0x413c, 0x8126), .driver_info = HCI_WRONG_SCO_MTU },
Why do you think HCI_RESET is needed? Did Dell switched to using a HID
proxy dongle or what?
A user reported that his dongle needs a reset to work. A manual reset, the
module option and that patch solved the issue.
an manual reset is not possible. The HCI_RESET quirk only end up sending
HCI Reset as the first command. This actually only resets the Bluetooth
chip and nothing on the USB bus. Only in cases of Broadcom HID proxy it
triggers the HID to HCI switch.
I am simply not convinced that this is a HID proxy adapter and thus this
patch is not needed at all.
Regards
Marcel
-
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]quirky dongle for hci_usb
A user reported that his dongle needs a reset to work. A manual reset, the module option and that patch solved the issue. an manual reset is not possible. The HCI_RESET quirk only end up sending HCI Reset as the first command. This actually only resets the Bluetooth chip and nothing on the USB bus. Only in cases of Broadcom HID proxy it triggers the HID to HCI switch. I am simply not convinced that this is a HID proxy adapter and thus this patch is not needed at all. Well, have a look yourself: https://bugzilla.novell.com/show_bug.cgi?id=257303 Regards Oliver - 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]quirky dongle for hci_usb
Hi Oliver,
A user reported that his dongle needs a reset to work. A manual reset, the
module option and that patch solved the issue.
an manual reset is not possible. The HCI_RESET quirk only end up sending
HCI Reset as the first command. This actually only resets the Bluetooth
chip and nothing on the USB bus. Only in cases of Broadcom HID proxy it
triggers the HID to HCI switch.
I am simply not convinced that this is a HID proxy adapter and thus this
patch is not needed at all.
Well,
have a look yourself:
https://bugzilla.novell.com/show_bug.cgi?id=257303
I think that it is a userspace bug which we were dealing with for quite
some time, but it is safe to send HCI Reset. So lets do that for all
Broadcom based dongles.
Regards
Marcel
diff --git a/drivers/bluetooth/hci_usb.c b/drivers/bluetooth/hci_usb.c
index 406af57..caf9a3b 100644
--- a/drivers/bluetooth/hci_usb.c
+++ b/drivers/bluetooth/hci_usb.c
@@ -115,24 +115,24 @@ static struct usb_device_id blacklist_ids[] = {
{ USB_DEVICE(0x0a5c, 0x2009), .driver_info = HCI_BCM92035 },
/* IBM/Lenovo ThinkPad with Broadcom chip */
- { USB_DEVICE(0x0a5c, 0x201e), .driver_info = HCI_WRONG_SCO_MTU },
- { USB_DEVICE(0x0a5c, 0x2110), .driver_info = HCI_WRONG_SCO_MTU },
+ { USB_DEVICE(0x0a5c, 0x201e), .driver_info = HCI_RESET | HCI_WRONG_SCO_MTU },
+ { USB_DEVICE(0x0a5c, 0x2110), .driver_info = HCI_RESET | HCI_WRONG_SCO_MTU },
/* ANYCOM Bluetooth USB-200 and USB-250 */
{ USB_DEVICE(0x0a5c, 0x2111), .driver_info = HCI_RESET },
/* HP laptop with Broadcom chip */
- { USB_DEVICE(0x03f0, 0x171d), .driver_info = HCI_WRONG_SCO_MTU },
+ { USB_DEVICE(0x03f0, 0x171d), .driver_info = HCI_RESET | HCI_WRONG_SCO_MTU },
/* Dell laptop with Broadcom chip */
- { USB_DEVICE(0x413c, 0x8126), .driver_info = HCI_WRONG_SCO_MTU },
+ { USB_DEVICE(0x413c, 0x8126), .driver_info = HCI_RESET | HCI_WRONG_SCO_MTU },
/* Microsoft Wireless Transceiver for Bluetooth 2.0 */
{ USB_DEVICE(0x045e, 0x009c), .driver_info = HCI_RESET },
/* Kensington Bluetooth USB adapter */
{ USB_DEVICE(0x047d, 0x105d), .driver_info = HCI_RESET },
- { USB_DEVICE(0x047d, 0x105e), .driver_info = HCI_WRONG_SCO_MTU },
+ { USB_DEVICE(0x047d, 0x105e), .driver_info = HCI_RESET | HCI_WRONG_SCO_MTU },
/* ISSC Bluetooth Adapter v3.1 */
{ USB_DEVICE(0x1131, 0x1001), .driver_info = HCI_RESET },
@@ -142,8 +142,8 @@ static struct usb_device_id blacklist_ids[] = {
{ USB_DEVICE(0x0400, 0x080a), .driver_info = HCI_BROKEN_ISOC },
/* Belkin F8T012 and F8T013 devices */
- { USB_DEVICE(0x050d, 0x0012), .driver_info = HCI_WRONG_SCO_MTU },
- { USB_DEVICE(0x050d, 0x0013), .driver_info = HCI_WRONG_SCO_MTU },
+ { USB_DEVICE(0x050d, 0x0012), .driver_info = HCI_RESET | HCI_WRONG_SCO_MTU },
+ { USB_DEVICE(0x050d, 0x0013), .driver_info = HCI_RESET | HCI_WRONG_SCO_MTU },
/* Digianswer devices */
{ USB_DEVICE(0x08fd, 0x0001), .driver_info = HCI_DIGIANSWER },
-
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] New USB stack on FreeBSD w/Linux emulation layer coming
Hi,
I'm currently working on a Linux USB emulation layer for FreeBSD. In that
regard I have some issues that makes the stack peform non-optimal due to its
API design.
The main issue is that DMA'able memory is allocated per USB host controller on
Linux and not per USB host controller and pipe combination. Due to that I
have to pre-allocate memory for all pipes to avoid blocking behaviour when
one submits an URB. Further I have to split all large transfers into a fixed
buffer size. If the fixed buffer is too large I will waste memory. If it is
too small I will get lousy performance.
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?
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.
--HPS
-
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: Suspending of this keyboard used to work with older versions of your patches you sent me some weeks/months ago. Yes, then it should keep working. My keyboard does suspend. Could you post your syslog? I have had also one very strange (and broken in many ways) usb mouse attached in a situation when things didn't suspend. After unplugging it, it seems to work. I will look at it in more detail now, thanks. -- Jiri Kosina SUSE Labs - 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 07:37:04 +0200, Oliver Neukum [EMAIL PROTECTED] wrote: + /* Task context for reporting idleness */ + struct work_struct idle_work; This does not seem to be used anywhere. I did not verify the function in detail, but the patch looks sane at a quick glance. -- Pete - 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, Pete Zaitcev wrote: I did not verify the function in detail, but the patch looks sane at a quick glance. Hi Pete and Oliver, (BTW, why was I again dropped from CC? :) ) I consider the things below crucial before this could be merged: - what to do with devices with force feedback? (or PID devices in general). The effect could have up to infinite duration (until it is stopped by appropriate stop method), and we definitely absolutely must not autosuspend a device that is currently in a process of playback. - think again about the output reports queuing. I am now inclined to think that we should simply wake the device up once the output report is to be delivered to it. There might be different situations other than just keyboard LEDs (there can be simply any kind of exotic HID device being controlled through hiddev and userspace could want to deliver the output report to it immediately, without any queuing) - (and of course coding style) Thanks, -- Jiri Kosina - 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 14:49:37 +0200, Hans Petter Selasky [EMAIL PROTECTED]
wrote:
I'm currently working on a Linux USB emulation layer for FreeBSD. In that
regard I have some issues that makes the stack peform non-optimal due to its
API design.
I think that what you described is largely inevitable if such a significant
difference exists in stack's architectures, but please see below.
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.
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.
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.
So, in my drivers I leaned heavily towards the kind of preallocation
which you are discussing. However, as you know we never had complete
end-to-end preallocatin facilities, so this never was bulletproof.
Attempts to do this also run against the paucity of IOMMU resources.
We have tons of unnecessary allocations made with usb_buffer_alloc,
of which I'm trying to rid us now. This happened because people
somehow think that it's necessary to use such allocations whenever
USB is involved.
So, recently there was a backlash and giving up on this. Instead,
we are moving to the model which the networking stack uses. This
means, away from you. If anything, you're going to see less use
of usb_buffer_alloc across Linux kernel.
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.
The core issue is, as far as I can tell, in vast majority of cases
the end-to-end preallocation is unnecessary. If used, it adds enormous
complexity, hurts performance, and eats IOMMU. We do not want it
used routinely. So, to implement truly useful preallocations, we
have to have two paths or two chunks of code, one is smaller, less
complex, less buggy, used commonly, and another far more complex,
only used by usb-storage. Personally, I don't see it flying.
-- Pete
-
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
Hi,
Interesting reading.
On Wednesday 16 May 2007 16:08, Pete Zaitcev wrote:
On Wed, 16 May 2007 14:49:37 +0200, Hans Petter Selasky [EMAIL PROTECTED]
wrote:
I'm currently working on a Linux USB emulation layer for FreeBSD. In that
regard I have some issues that makes the stack peform non-optimal due to
its API design.
I think that what you described is largely inevitable if such a significant
difference exists in stack's architectures, but please see below.
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.
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.
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.
So, in my drivers I leaned heavily towards the kind of preallocation
which you are discussing. However, as you know we never had complete
end-to-end preallocatin facilities, so this never was bulletproof.
Attempts to do this also run against the paucity of IOMMU resources.
We have tons of unnecessary allocations made with usb_buffer_alloc,
of which I'm trying to rid us now. This happened because people
somehow think that it's necessary to use such allocations whenever
USB is involved.
So, recently there was a backlash and giving up on this. Instead,
we are moving to the model which the networking stack uses. This
means, away from you. If anything, you're going to see less use
of usb_buffer_alloc across Linux kernel.
Well, that is not so far away from me. What I plan, but have not implemented
yet is the ability to set a custom buffer on a transfer.
My idea is that you have to specify the maximum transfer length. Then you
allocate descriptors enough to handle that. Then you can do transfers of any
size less than or equal to the maximum. All of the DMA memory allocation is
done allocating single memory pages at a time. I use the scatter and gather
capabilities available on the EHCI/OHCI controllers. There are no multi-page
contiguous allocations.
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.
The core issue is, as far as I can tell, in vast majority of cases
the end-to-end preallocation is unnecessary. If used, it adds enormous
complexity, hurts performance, and eats IOMMU.
No, there is not very much extra complexity added to using end-to-end
pre-allocation. Actually it makes the code simpler, once you first have
overcome the first barriers.
http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/
If you have a look in my ehci.c and the function ehci_xfer_setup(). This
functions allocates both the so-called URB, the required DMA buffer, a
virtually linear buffer if wanted, and all required USB host controller
descriptors.
Then look at ehci_setup_standard_chain(). This function builds the
descriptor chain. It is straight forward and fast.
http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/ehci.c
We do not want it
used routinely. So, to implement truly useful preallocations, we
have to have two paths or two chunks of code, one is smaller, less
complex, less buggy, used commonly, and another far more complex,
only used by usb-storage. Personally, I don't see it flying.
I would recommend that you split large USB-storage transfers into smaller
pieces multiplies of wMaxPacketSize.
http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/umass.c
See the function umass_t_bbb_data_write_callback() for example.
--HPS
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wednesday 16 May 2007, Hans Petter Selasky wrote:
Hi,
I'm currently working on a Linux USB emulation layer for FreeBSD. In that
regard I have some issues that makes the stack peform non-optimal due to its
API design.
...
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?
Riddle me this: When should Linux choose to adopt a design mistake
made by a non-Linux driver stack?
The reason is that in the new USB stack on FreeBSD, the USB transfer
descriptors are allocated along with the data-buffer,
Whereas on Linux, data buffers are not normally bound to a particular
driver stack (such as USB). That matches normal hardware usage, and
provides a less restrictive system which minimizes routine requirements
to copy data. (And thus, structural performance limits.)
so that when you
unsetup an USB transfer, absolutely all memory related to a transfer is
freed. This also has a security implication
Calling this security seems like quite a stretch to me. Systems
that don't behave when buffers are exhausted are buggy, sure. And
marginal behavior is always hard to test and debug; and bugs are
always a potential home for exploits (including DOS). But this has
no more security implications than any other tradeoff.
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.
That's not a failure mode that's been often observed on Linux. (Never,
in my own experience... which I admit has not focussed on that particular
type of stress load.) So it's hard to argue that it should motivate a
redesign of core APIs.
Transfer descriptors are an artifact of one kind of host controller;
it'd be wrong to assume all HCDs use them.
The related issue that's been discussed is how to shrink submit paths,
giving lower overhead.
Submitting URBs directly to endpoints would remove lots of dispatch
logic. Pre-allocating some TDs would remove logic too, but implies
changing the URB lifecycle. The peripheral/gadget API allows for
both of those optimizations, but adopting them on the host side would
not be particularly easy because of the how to migrate all drivers
problem. I'd expect submit-to-endpoints to be adopted more easily,
since the low level HCD primitives already work that way.
- Dave
-
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 Wednesday 16 May 2007, Oliver Neukum wrote: Am Mittwoch, 16. Mai 2007 11:40 schrieb Robert Marquardt: A suspended bus-powered USB device cannot drive LEDs so suspending an USB keyboard with CAPS LOCK on means it gets out of sync. How much power does an LED need? You have 2mA in suspended mode. Correction: more like 0.5mA in suspended mode. For a high-power device, it can be more ... but most keyboards aren't. - Dave - 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 Tuesday 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 ? I think the doc should be fixed ... avoid using it as a general purpose allocator. We've learned better since that doc was first written. :) It *can* be used to allocate buffers, in cases where the DMA map/unmap overhead of the more typical usage would excessive. So it's not going to vanish. - Dave - 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 Wednesday 16 May 2007 16:41, David Brownell wrote:
On Wednesday 16 May 2007, Hans Petter Selasky wrote:
Hi,
I'm currently working on a Linux USB emulation layer for FreeBSD. In that
regard I have some issues that makes the stack peform non-optimal due to
its API design.
...
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?
Riddle me this: When should Linux choose to adopt a design mistake
made by a non-Linux driver stack?
The reason is that in the new USB stack on FreeBSD, the USB transfer
descriptors are allocated along with the data-buffer,
Whereas on Linux, data buffers are not normally bound to a particular
driver stack (such as USB). That matches normal hardware usage, and
provides a less restrictive system which minimizes routine requirements
to copy data. (And thus, structural performance limits.)
On the BSD platform there is something called BUS-DMA. Memory is allocated
according to PCI device capabilities. This is because sometimes the PCI
device is not capable of addressing the complete memory. Also you need to
sync memory, like on the SUN architecture. Then you need to send specific
commands to the PCI-bridge, for example pshyco. From what I see your model
will not work in all cases.
so that when you
unsetup an USB transfer, absolutely all memory related to a transfer is
freed. This also has a security implication
Calling this security seems like quite a stretch to me. Systems
that don't behave when buffers are exhausted are buggy, sure. And
marginal behavior is always hard to test and debug; and bugs are
always a potential home for exploits (including DOS). But this has
no more security implications than any other tradeoff.
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.
That's not a failure mode that's been often observed on Linux. (Never,
in my own experience... which I admit has not focussed on that particular
type of stress load.) So it's hard to argue that it should motivate a
redesign of core APIs.
That's not the real motiviation for my design. It is just a by-product.
Transfer descriptors are an artifact of one kind of host controller;
it'd be wrong to assume all HCDs use them.
As long as the core information is not in the header of an USB transfer, like
IP-packets have an header, you cannot ignore this.
The related issue that's been discussed is how to shrink submit paths,
giving lower overhead.
Submitting URBs directly to endpoints would remove lots of dispatch
logic. Pre-allocating some TDs would remove logic too, but implies
changing the URB lifecycle. The peripheral/gadget API allows for
both of those optimizations, but adopting them on the host side would
not be particularly easy because of the how to migrate all drivers
problem. I'd expect submit-to-endpoints to be adopted more easily,
since the low level HCD primitives already work that way.
It was hard enough to rewrite the FreeBSD USB drivers. On Linux it will
probably be more difficult, hence you have more supported drivers.
--HPS
-
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] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007 07:41:26 -0700, David Brownell [EMAIL PROTECTED] wrote: 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. That's not a failure mode that's been often observed on Linux. (Never, in my own experience... which I admit has not focussed on that particular type of stress load.) So it's hard to argue that it should motivate a redesign of core APIs. 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. However, the usb-storage worker thread can get stuck sleeping for allocations. We try to deal with it by using GFP_NOIO carefuly, but this is a palliative. I continue to hear from my users with systems locking up when they mount ext3 on winchesters in USB enclosures and use a simple cp. Switching from usb-storage to ub fixes the issue (which is why we continue to ship it). It's not a commonplace concern, but it persists. Sometimes it involves scsi_eh_0. 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... -- Pete - 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 Wednesday 16 May 2007, Hans Petter Selasky wrote: On the BSD platform there is something called BUS-DMA. Memory is allocated according to PCI device capabilities. This is because sometimes the PCI device is not capable of addressing the complete memory. Also you need to sync memory, like on the SUN architecture. Then you need to send specific commands to the PCI-bridge, for example pshyco. From what I see your model will not work in all cases. Those issues are handled by the DMA framework, transparently to USB. Transfer descriptors are an artifact of one kind of host controller; it'd be wrong to assume all HCDs use them. As long as the core information is not in the header of an USB transfer, like IP-packets have an header, you cannot ignore this. Strange how it seems to work already though, having factored the problem differently ... I think that word (cannot) doesn't mean what you think it means!! - Dave - 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] New USB stack on FreeBSD w/Linux emulation layer coming
On Wednesday 16 May 2007, Pete Zaitcev wrote: On Wed, 16 May 2007 07:41:26 -0700, David Brownell [EMAIL PROTECTED] wrote: 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. That's not a failure mode that's been often observed on Linux. (Never, in my own experience... which I admit has not focussed on that particular type of stress load.) So it's hard to argue that it should motivate a redesign of core APIs. 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). However, the usb-storage worker thread can get stuck sleeping for allocations. Might be good to look at removing that worker thread sometime. We try to deal with it by using GFP_NOIO carefuly, but this is a palliative. I continue to hear from my users with systems locking up when they mount ext3 on winchesters in USB enclosures and use a simple cp. Switching from usb-storage to ub fixes the issue (which is why we continue to ship it). It's not a commonplace concern, but it persists. Sometimes it involves scsi_eh_0. SCSI EH causes lots of strangeness. :( 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. - Dave - 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, 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 16:52:53 +0200, Hans Petter Selasky [EMAIL PROTECTED] wrote: [...] Then you need to send specific commands to the PCI-bridge, for example pshyco. From what I see your model will not work in all cases. USB through Psycho/Schizo is fully supported on Linux. Heck it works better than the equivalent on x86_64, because there's no address range limitation. The key is to set IOMMU at transfer time. Solaris defers DMA setup as well (for what they call streaming transfers). -- Pete - 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 about EHCI PCI/platform drivers
On Tuesday 15 May 2007, Tzachi Perelstein wrote: David Brownell wrote: On Sunday 13 May 2007, Tzachi Perelstein wrote: Hello, I'm working on EHCI HC glue port for Marvell Orion SoC. The Orion has a PCI/PCIE interfaces as well as an integrated USB controller. While looking at ehci-hcd.c it looks like there's some kind of dependency between PCI_DRIVER and PLATFORM_DRIVER. I saw some previous threads about the ehci-fsl.c regarding this issue, but I'm not sure I understand, for example, why in module_init if pci_register_driver fails the platform driver is unregistered? Shouldn't these two types of drivers be independent? If the platform has PCI but you can't register a PCI driver, it's quite broken. How broken must a platform be before you fix those bugs, rather than expect drivers to work around them? I have no problem with my PCI, it works just fine! Who said anything about bugs workaround??? You -- by asking why a bug (pci_register_driver fails) should be handled differently (working around the failure). I was just wondering if there is a _real_ reason why *if* pci_register_driver fails then the platform driver will be unregistered. Theoretically it could be that PCI will fail but platform driver will work ok, so why unregistering it?? Why not just dumping an error message and continuing?? No; theoretically pci_register_driver() has no reason to fail on a correctly working system. - Dave - 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 11:38:47 -0400 (EDT), Alan Stern [EMAIL PROTECTED] 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. AFAIK, the definition is, GFP_NOIO can block, but it cannot wait for a writeout. If it cannot be satisfied without writing dirty data, it will fail. -- Pete - 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 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. 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. 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. 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. 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. -- Pete - 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 Wednesday 16 May 2007, Alan Stern wrote: 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. dma_pool_alloc() takes gfp_flags, and (looking at the code) tests only for __GFP_WAIT. So if you don't pass that flag, it won't wait... 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. Tradeoffs, tradeoffs... yeah, proponents of threads always like to point out the seeming (micro-) simplicity. It's not clear to me that any resulting macro-complexity is a win in all cases. Sometimes it's clearly not. In this case, I said probably because the macro-complexity of USB-storage gets multiplied by the macro-complexity of SCSI. (I think!) Error paths are where the rubber meets the road... Sometimes you can almost understand why people would choose to live in a fantasy-based world, not the reality-based one. Of course, folk making that choice have no business making decisions affecting the real world (including kernel code). :) - Dave - 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] ark3116: receive returns negative
Hello, I seem to have problems with the ark3116 driver from 2.6.18.8. This is a USB-RS232 cable. Just opening the /dev/ttyUSB0 device gives (this is the debug output enabled by `modprobe ark3116 debug=1`). The lines that look suspicious are /serial/ark3116.c: 124 1 bytes [0xFFB0] and /serial/ark3116.c: ark3116_ioctl cmd 0x5401 not supported I have also seen things like id here -62 [0x10], which would indicate that usb_control_msg() returned something very negative (-ETIME!?). Issuing a write() on an open fd to ttyUSB does not generate any further debug output. Is the driver even complete/functional? I do not know where to go from here, please advise. Full output: /serial/ark3116.c: ark3116_open - port 0 /serial/ark3116.c: 111 1 bytes [0x03] /serial/ark3116.c: 112 ok /serial/ark3116.c: 113 ok /serial/ark3116.c: 114 ok /serial/ark3116.c: 115 ok /serial/ark3116.c: 116 1 bytes [0x03] /serial/ark3116.c: 117 ok /serial/ark3116.c: 118 1 bytes [0x02] /serial/ark3116.c: 119 ok /serial/ark3116.c: 120 1 bytes [0x00] /serial/ark3116.c: 121 ok /serial/ark3116.c: 122 1 bytes [0x01] /serial/ark3116.c: 123 ok /serial/ark3116.c: 124 1 bytes [0xFFB0] /serial/ark3116.c: ark3116_set_termios - port 0 /serial/ark3116.c: setting CS8 /serial/ark3116.c: setting parity to NONE /serial/ark3116.c: setting 1 stop bit /serial/ark3116.c: 000 1 bytes [0x02] /serial/ark3116.c: setting baudrate to 9600 (-reg=312) /serial/ark3116.c: 147 ok /serial/ark3116.c: 148 ok /serial/ark3116.c: 149 ok /serial/ark3116.c: 150 ok /serial/ark3116.c: 151 1 bytes [0x03] /serial/ark3116.c: 152 ok /serial/ark3116.c: updating bit count, stop bit or parity (cfg=0x03) /serial/ark3116.c: 153 1 bytes [0x00] /serial/ark3116.c: 154 ok /serial/ark3116.c: ark3116_ioctl cmd 0x5401 not supported Jan -- - 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 Wednesday 16 May 2007 18:00, David Brownell wrote: On Wednesday 16 May 2007, Alan Stern wrote: 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. dma_pool_alloc() takes gfp_flags, and (looking at the code) tests only for __GFP_WAIT. So if you don't pass that flag, it won't wait... 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! My usbd_transfer_start() returns void. Your usb_submit_urb() returns int. Pre-allocating everything you need simply saves code, hence you only check once if you got the memory or not. --HPS - 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 Wednesday 16 May 2007, Alan Stern wrote: On Wed, 16 May 2007, Pete Zaitcev wrote: Right. Per-endpoint with a size limits also allows TDs to be preallocated. With a large potential waste of memory! Which is the general down-side of preallocation... 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? Not really ... considering most endpoints are idle most of the time. Also, remember that the number of TDs required for a buffer isn't strictly a function of buffer size, but also of alignment. EHCI, for one example, can handle up to 20 KB if the buffer is nicely aligned, but maybe only 16 KB otherwise. So if the size limit is 20 KB per URB (I've seen usb-storage regularly want 64 KB though, when memory isn't very fragmented), does that imply one TD or two? - Dave - 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 Wednesday 16 May 2007 18:21, Alan Stern wrote: 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. You first send a control request of size 8 bytes. Afterwards you receive or transmit data as indicated by the length field in the control request. 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. Allocating one buffer for each of the endoints is not a waste of memory. 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? That depends largely on wMaxPacketSize. 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. 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. 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. 1) Even though you might not want to preallocate things all the time, 2) 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. 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. --HPS - 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 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:
static const struct usbd_config umodem_config_data[UMODEM_N_DATA_TRANSFER] = {
[0] = {
.type = UE_BULK,
.endpoint = -1, /* any */
.direction = UE_DIR_OUT,
.bufsize = UMODEM_BUF_SIZE,
.flags = 0,
.callback = umodem_write_callback,
},
[1] = {
.type = UE_BULK,
.endpoint = -1, /* any */
.direction = UE_DIR_IN,
.bufsize = UMODEM_BUF_SIZE,
.flags = USBD_SHORT_XFER_OK,
.callback = umodem_read_callback,
},
[2] = {
.type = UE_CONTROL,
.endpoint = 0x00, /* Control pipe */
.direction = -1,
.bufsize = sizeof(usb_device_request_t),
.callback = umodem_write_clear_stall_callback,
.timeout = 1000, /* 1 second */
},
[3] = {
.type = UE_CONTROL,
.endpoint = 0x00, /* Control pipe */
.direction = -1,
.bufsize = sizeof(usb_device_request_t),
.callback = umodem_read_clear_stall_callback,
.timeout = 1000, /* 1 second */
},
};
error = usbd_transfer_setup(uaa-device, sc-sc_data_iface_index,
sc-sc_xfer_data, umodem_config_data,
UMODEM_N_DATA_TRANSFER,
sc, Giant);
if (error) {
goto detach;
}
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.
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.
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.
--HPS
-
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] New USB stack on FreeBSD w/Linux emulation layer coming
Hi, On Wednesday 16 May 2007 19:38, Alan Stern wrote: 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. On FreeBSD it will never happen that you call the equivalent of usb_submit_urb() after that the device has detached! It must be something terribly wrong in the Linux USB stack if the callbacks are alive after that you have detached a USB device. Therefore you don't have to check anything when starting or stopping a USB transfer on FreeBSD [new stack]. 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. Yes, probably. --HPS - 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 18:11:35 +0200, Hans Petter Selasky [EMAIL PROTECTED] wrote: My usbd_transfer_start() returns void. Your usb_submit_urb() returns int. We (ok, I) don't like this scheme. In Linux only SCSI uses it, primarily because that's how Eric Youngdale defined it in 1992. See, there may be other reasons why a transfer would fail, outside of memory allocation failure. In such case, an error has to be reported. In your design, error is reported through a callback, and if the error is detected during the submission, it is reported on the context which is submitting. Thus, you cannot hold any locks across the submission which the callback is likely to take. It's a real pain on SMP and with a multithreaded system. -- Pete - 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
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. On FreeBSD it will never happen that you call the equivalent of usb_submit_urb() after that the device has detached! It must be something terribly wrong in the Linux USB stack if the callbacks are alive after that you have detached a USB device. How does that work then ... driver must grab a lock, check whether the device has disconnected, then submit the request and drop the lock? Sounds like needless slowdowns. Because if there's no lock against async disconnect events, then it's trivial to have the disconnect logic underway on one CPU while another CPU does real work, submitting an I/O request. - Dave p.s. You mentioned 16 MB/sec bulk transfer rates. Folk often get over twice that on Linux, and a few years back there were measurements of around 50 MByte/sec ... limitations seeming to come from hardware not the driver stack. - 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 19:49:57 +0200, Hans Petter Selasky [EMAIL PROTECTED] wrote: No; it's because unforeseen events can occur. For example, the device may have been unplugged or suspended. On FreeBSD it will never happen that you call the equivalent of usb_submit_urb() after that the device has detached! It must be something terribly wrong in the Linux USB stack if the callbacks are alive after that you have detached a USB device. I'm so blogging this. -- Pete - 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
Hi,
On Wednesday 16 May 2007 20:20, David Brownell wrote:
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.
On FreeBSD it will never happen that you call the equivalent
of usb_submit_urb() after that the device has detached! It must be
something terribly wrong in the Linux USB stack if the callbacks are
alive after that you have detached a USB device.
How does that work then ... driver must grab a lock, check
whether the device has disconnected, then submit the request
and drop the lock? Sounds like needless slowdowns.
Each USB device has its own lock. There are some tricks there.
1) usbd_transfer_start() is always called like this:
usbd_transfer_start(sc-sc_xfer[x]);
2) sc-sc_xfer[x] is set to zero at detach holding the private lock of the USB
device driver. All subsequent calls to usbd_transfer_start(), if any, will
fail.
3) usbd_transfer_start() is always non-blocking. In other words a single lock
is held across the call.
This is how it looks until further:
As you can see, no other locks are locked unless you want to submit a transfer
to the USB host controller. Then you have to aquire usb_mtx which is per
USB host controller.
void
usbd_transfer_start(struct usbd_xfer *xfer)
{
if (xfer == NULL) {
/* transfer is gone */
return;
}
mtx_assert(xfer-priv_mtx, MA_OWNED);
if(!(xfer-flags USBD_DEV_OPEN))
{
xfer-flags |= USBD_DEV_OPEN;
/*
* open transfer
*/
mtx_lock(xfer-usb_mtx);
(xfer-pipe-methods-open)(xfer);
mtx_unlock(xfer-usb_mtx);
}
/* USBD_DEV_TRANSFERRING is only changed
* when priv_mtx is locked
*/
if(!(xfer-flags (USBD_DEV_TRANSFERRING)))
{
/* call callback */
__usbd_callback(xfer);
cut away
}
return;
}
Because if there's no lock against async disconnect events,
then it's trivial to have the disconnect logic underway on
one CPU while another CPU does real work, submitting an I/O
request.
We solve this in one of two ways:
1) Using a mutex. At detach we lock the mutex stopping all transfers.
2) Using a thread. At detach we teardown and wait for the thread to exit.
- Dave
p.s. You mentioned 16 MB/sec bulk transfer rates. Folk often
get over twice that on Linux, and a few years back there
were measurements of around 50 MByte/sec ... limitations
seeming to come from hardware not the driver stack.
Yes, hardware and price :-)
--HPS
-
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 Wednesday 16 May 2007 20:20, Pete Zaitcev wrote:
On Wed, 16 May 2007 18:11:35 +0200, Hans Petter Selasky [EMAIL PROTECTED]
wrote:
My usbd_transfer_start() returns void. Your usb_submit_urb()
returns int.
We (ok, I) don't like this scheme. In Linux only SCSI uses it,
primarily because that's how Eric Youngdale defined it in 1992.
See, there may be other reasons why a transfer would fail, outside
of memory allocation failure. In such case, an error has to be
reported. In your design, error is reported through a callback,
and if the error is detected during the submission, it is reported
on the context which is submitting. Thus, you cannot hold any
locks across the submission which the callback is likely to take.
It's a real pain on SMP and with a multithreaded system.
The lock that you are holding during submission is the same lock that is
protecting the callback. Actually you can end up calling the
__usbd_callback() prematurely in my new USB stack, but that is handled just
fine, through some recurse bits:
void
__usbd_callback(struct usbd_xfer *xfer)
{
mtx_assert(xfer-priv_mtx, MA_OWNED);
/* check first recurse flag */
if(!(xfer-flags USBD_DEV_RECURSED_1))
{
do {
/* set both recurse flags */
xfer-flags |= (USBD_DEV_RECURSED_2|
USBD_DEV_RECURSED_1);
/* call processing routine */
(xfer-callback)(xfer);
/* check second recurse flag */
} while(!(xfer-flags USBD_DEV_RECURSED_2));
/* clear first recurse flag */
xfer-flags = ~USBD_DEV_RECURSED_1;
}
else
{
/* clear second recurse flag */
xfer-flags = ~USBD_DEV_RECURSED_2;
}
return;
}
Those recurse bits solve the problem if you call urb_submit() from the
callback and you want to return an error.
Two flies have been smacked into one. There is only one error check, and that
is when the transfer fails. Therefore there is no need to return an error
by usbd_transfer_start().
--HPS
-
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 2.6.21] Usb Serial Keyspan: add support for USA-49WG USA-28XG
Add support for Keyspan adapters: USA-49WG and USA-28XG Signed-off-by: Lucy P. McCoy [EMAIL PROTECTED] --- Sorry about the attachment but I can't get it to format correctly on my email client. keyspan_patch.2.6.21.gz Description: application/gzip - 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] Remove duplicate IDs from option card driver
Cc: Matthias Urlichs [EMAIL PROTECTED]
Cc: linux-usb-devel@lists.sourceforge.net
Signed-off-by: Ben Collins [EMAIL PROTECTED]
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 8c3f55b..89f067d 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -165,7 +165,6 @@ static struct usb_device_id option_ids[] = {
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1410) }, /* Novatel U740 */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1420) }, /* Novatel EU870 */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1430) }, /* Novatel Merlin
XU870 HSDPA/3G */
- { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1430) }, /* Novatel XU870 */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x2100) }, /* Novatel EV620
CDMA/EV-DO */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x2110) }, /* Novatel Merlin
ES620 / Merlin ES720 / Ovation U720 */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x2130) }, /* Novatel Merlin
ES620 SM Bus */
--
Ubuntu : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/
-
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] Remove duplicate ID in ipaq driver
Cc: Ganesh Varadarajan [EMAIL PROTECTED]
Cc: linux-usb-devel@lists.sourceforge.net
Signed-off-by: Ben Collins [EMAIL PROTECTED]
diff --git a/drivers/usb/serial/ipaq.c b/drivers/usb/serial/ipaq.c
index 4df0ec7..7c85be4 100644
--- a/drivers/usb/serial/ipaq.c
+++ b/drivers/usb/serial/ipaq.c
@@ -92,7 +92,6 @@ static void ipaq_destroy_lists(struct usb_serial_port *port);
static struct usb_device_id ipaq_id_table [] = {
/* The first entry is a placeholder for the insmod-specified device */
- { USB_DEVICE(0x049F, 0x0003) },
{ USB_DEVICE(0x0104, 0x00BE) }, /* Socket USB Sync */
{ USB_DEVICE(0x03F0, 0x1016) }, /* HP USB Sync */
{ USB_DEVICE(0x03F0, 0x1116) }, /* HP USB Sync 1611 */
--
Ubuntu : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/
-
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] Remove duplicate ID in ipaq driver
/* The first entry is a placeholder for the insmod-specified device */
-{ USB_DEVICE(0x049F, 0x0003) },
Is it obvious why this patch is correct? Especially given the
comment just before the line you delete, and the code
if (vendor) {
ipaq_id_table[0].idVendor = vendor;
ipaq_id_table[0].idProduct = product;
}
in ipaq_init()?
- R.
-
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] Remove duplicate ID in ipaq driver
Ben Collins napsal(a):
Cc: Ganesh Varadarajan [EMAIL PROTECTED]
Cc: linux-usb-devel@lists.sourceforge.net
Signed-off-by: Ben Collins [EMAIL PROTECTED]
diff --git a/drivers/usb/serial/ipaq.c b/drivers/usb/serial/ipaq.c
index 4df0ec7..7c85be4 100644
--- a/drivers/usb/serial/ipaq.c
+++ b/drivers/usb/serial/ipaq.c
@@ -92,7 +92,6 @@ static void ipaq_destroy_lists(struct usb_serial_port
*port);
static struct usb_device_id ipaq_id_table [] = {
/* The first entry is a placeholder for the insmod-specified device */
I wonder if the people ever read the comments? ^
It's used for parameter from command line when modprobing. See ipaq_init.
- { USB_DEVICE(0x049F, 0x0003) },
{ USB_DEVICE(0x0104, 0x00BE) }, /* Socket USB Sync */
{ USB_DEVICE(0x03F0, 0x1016) }, /* HP USB Sync */
{ USB_DEVICE(0x03F0, 0x1116) }, /* HP USB Sync 1611 */
regards,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
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] Remove duplicate ID in ipaq driver
On Wed, 2007-05-16 at 13:59 -0700, Roland Dreier wrote:
/* The first entry is a placeholder for the insmod-specified device */
- { USB_DEVICE(0x049F, 0x0003) },
Is it obvious why this patch is correct? Especially given the
comment just before the line you delete, and the code
if (vendor) {
ipaq_id_table[0].idVendor = vendor;
ipaq_id_table[0].idProduct = product;
}
in ipaq_init()?
My mistake, quick on the patching going through this dupe list.
Might I add that this is terrible use of the device table, though.
Clutters userspace, and adds processing to module-init-tools programs.
--
Ubuntu : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/
-
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 Wednesday 16 May 2007, Hans Petter Selasky wrote: Hi, On Wednesday 16 May 2007 20:20, David Brownell wrote: 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. On FreeBSD it will never happen that you call the equivalent of usb_submit_urb() after that the device has detached! It must be something terribly wrong in the Linux USB stack if the callbacks are alive after that you have detached a USB device. How does that work then ... driver must grab a lock, check whether the device has disconnected, then submit the request and drop the lock? Sounds like needless slowdowns. Each USB device has its own lock. There are some tricks there. 1) usbd_transfer_start() is always called like this: usbd_transfer_start(sc-sc_xfer[x]); 2) sc-sc_xfer[x] is set to zero at detach holding the private lock of the USB device driver. All subsequent calls to usbd_transfer_start(), if any, will fail. So there's a race on SMP, where sc-sc_xfer[x] may be referenced on one CPU while another is nulling it. The lock you showed is inside usbd_transfer_start(), where it can't do any good. 3) usbd_transfer_start() is always non-blocking. In other words a single lock is held across the call. Like usb_submit_urb() then, except that the disconnect race is handled by being buggy rather than by reporting a fault at submit time... ... Because if there's no lock against async disconnect events, then it's trivial to have the disconnect logic underway on one CPU while another CPU does real work, submitting an I/O request. We solve this in one of two ways: 1) Using a mutex. At detach we lock the mutex stopping all transfers. 2) Using a thread. At detach we teardown and wait for the thread to exit. But there's that race above, so it's not solved. - Dave - 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
