Re: [linux-usb-devel] [patch 2.6.14-rc1, 3/5] remove usb_suspend_device() parameter
On Tue, 13 Sep 2005, David Brownell wrote:
The parameter isn't needed, or even usable, without the recursion
removed in the previous patch.
These patches look great, and I intend to go through them carefully. At
first glance, there appears to be a small problem in the pm-usbsusp patch:
static int usb_generic_suspend(struct device *dev, pm_message_t message)
{
struct usb_interface*intf;
struct usb_driver *driver;
int status;
- if (dev-driver == usb_generic_driver)
- return usb_suspend_device (to_usb_device(dev), message);
+ /* USB devices enter SUSPEND state through their hubs, but can be
+* marked for FREEZE as soon as their children are already idled.
+*/
+ if (dev-driver == usb_generic_driver) {
+ if (dev-power.power_state.event == message.event)
+ return 0;
+ /* we need to rule out bogus requests through sysfs */
+ status = device_for_each_child(dev, NULL, verify_suspended);
+ if (status)
+ return status;
+ if (message.event == PM_EVENT_FREEZE) {
+ dev-power.power_state = message;
+ return 0;
+ }
+ return usb_suspend_device (to_usb_device(dev));
+ }
You skip calling usb_suspend_device for FREEZE events. That's good for
external devices, but it's not good for root hubs. They really do need to
be suspended even for FREEZE events, since FREEZE requires no interrupts
or DMA. This will be easy to fix, of course.
Bringing up this next point may be a mistake, but bear with me... Now
that we're switching to a model where the recursion for sleep transitions
is handled entirely by the PM core (and recursion for runtime PM is
handled by some as-yet unspecified means), there appears to be no longer
any need for the locktree protocol. Do you agree?
Alan Stern
---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42 plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
___
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] fix pxa2xx_udc compile warnings
I saw this when compiling the pxa25x_udc driver in the lastest linus git
kernel. I've included a patch below as one way of cleaning this up.
CC drivers/usb/gadget/pxa2xx_udc.o
drivers/usb/gadget/pxa2xx_udc.c: In function `write_ep0_fifo':
drivers/usb/gadget/pxa2xx_udc.c:532: warning: passing arg 1 of `write_packet'
from incompatible pointer type
drivers/usb/gadget/pxa2xx_udc.c: At top level:
drivers/usb/gadget/pxa2xx_udc.c:2175: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2176: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2190: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2191: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2204: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2205: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2206: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2220: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2221: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2234: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2235: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2236: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2249: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2250: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2264: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2265: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2278: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2279: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2280: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2293: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2294: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2307: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2308: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2309: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2322: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2323: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2337: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2338: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2351: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2352: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2353: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2366: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2367: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2380: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2381: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2382: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2395: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2396: warning: initialization from incompatible
pointer type
drivers/usb/gadget/pxa2xx_udc.c:2639: warning: initialization from incompatible
pointer type
LD drivers/usb/gadget/built-in.o
This patch fixes several types in the PXA25x udc driver and hence fixes
several compiler warnings.
Signed-Off-By: Richard Purdie [EMAIL PROTECTED]
Index: git/drivers/usb/gadget/pxa2xx_udc.c
===
--- git.orig/drivers/usb/gadget/pxa2xx_udc.c2005-09-14 10:08:27.0
+0100
+++ git/drivers/usb/gadget/pxa2xx_udc.c 2005-09-14 15:44:47.0 +0100
@@ -422,7 +422,7 @@
}
static int
-write_packet(volatile u32 *uddr, struct pxa2xx_request *req, unsigned max)
+write_packet(volatile unsigned long *uddr, struct pxa2xx_request *req,
unsigned max)
{
u8 *buf;
unsignedlength, count;
@@ -2602,7 +2602,7 @@
* VBUS IRQs should probably be ignored so that the PXA device just acts
* dead to USB hosts until system resume.
*/
-static int pxa2xx_udc_suspend(struct device
[linux-usb-devel] Re: [patch 2.6.14-rc1, 3/5] remove usb_suspend_device() parameter
The parameter isn't needed, or even usable, without the recursion removed in the previous patch. These patches look great, and I intend to go through them carefully. At first glance, there appears to be a small problem in the pm-usbsusp patch: Not with that patch ... it's actually in the CURRENT kernel unless it's got CONFIG_USB_SUSPEND set! Notice the FIXME added by pm-config.patch; it's part of the underlying issue ... which by my reading isn't in this routine (yet). (And it's unrelated to any usb_suspend_device parameter; $SUBJECT is irrelevant other than patch.) This seems related to two OHCI regressions I noticed, by the way. In one case, resume-via-reset seems broken without CONFIG_USB_SUSPEND; the root hub timer doesn't restart correctly. (It tries to resubmit the URB while the hub is suspended, fails, then dies.) In the other, wakeup is broken since khubd never notices USB_PORT_STAT_C_SUSPEND; as if the root hub timer stopped (new behavior?) and didn't restart. You skip calling usb_suspend_device for FREEZE events. That's good for external devices, but it's not good for root hubs. They really do need to be suspended even for FREEZE events, since FREEZE requires no interrupts or DMA. Remember that HCDs consist of two hardware interfaces, which can normally be managed somewhat separately: - Root hub, which is the down-stream link. These are managed through calls into the HCD: hub_suspend(), hub_resume(), the code handling control requests, status polling, and so on. - Controller, the upstream link. Sometimes controllers support lower power modes than even root hub suspended (like off, or even just clock off), or they're like PCI (or PCMCIA) and have additional control protocols to follow. Now, the FIXME that I mentioned is basically that suspend/resume linkage to the root hubs needs reworking. Today, it's completely unused unless CONFIG_USB_SUSPEND is set ... so all the HCDs have code inside the controller suspend/resume calls to cope with that. That is: root hubs currently never see FREEZE except indirectly through the upstream link ... except with the non-default CONFIG_USB_SUSPEND. I suspect the right fix will involve adding to the code which you quoted, by calling hcd-hub_suspend(); similarly on resume. That'll be a nice step towards shrinking what CONFIG_USB_SUSPEND covers, and removing bugs associated with the other setting of that option. This will be easy to fix, of course. Just changing all the HCDs, the remote wakeup support, and the normal suspend/resume paths ... and retesting them all both with and without CONFIG_USB_SUSPEND, root hub timers, etc. Not easy enough to be 2.6.14 material, I suspect!! Bringing up this next point may be a mistake, but bear with me... Now that we're switching to a model where the recursion for sleep transitions is handled entirely by the PM core (and recursion for runtime PM is handled by some as-yet unspecified means), there appears to be no longer any need for the locktree protocol. Do you agree? Not at first glance. It's that unspecified means thing; we'll still need to be able to resume devices, and hence possibly their parents and up the tree to the root hub. Maybe it could be replaced later by something similar though. :) - Dave --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ 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.14-rc1] sl811-hcd minor fixes
Nothing earth-shattering, these came up from people reading
the code not real-world error reports.
- Dave
Three minor sl811-hcd fixes:
- Elminate memory leak on one (rare) disable/shutdown path.
- For periodic transfers that don't need to be scheduled, update
urb-start_frame to represent the transfer phase correctly.
- Report the (single) port as removable, by default.
Since no drivers yet use start_frame or that part of the hub descriptor,
only that leak is likely to ever matter.
Signed-off-by: David Brownell [EMAIL PROTECTED]
--- g26.orig/drivers/usb/host/sl811-hcd.c 2005-09-10 16:08:28.0 -0700
+++ g26/drivers/usb/host/sl811-hcd.c 2005-09-11 12:25:52.0 -0700
@@ -782,6 +782,9 @@ retry:
/* usb 1.1 says max 90% of a frame is available for periodic transfers.
* this driver doesn't promise that much since it's got to handle an
* IRQ per packet; irq handling latencies also use up that time.
+ *
+ * NOTE: the periodic schedule is a sparse tree, with the load for
+ * each branch minimized. see fig 3.5 in the OHCI spec for example.
*/
#define MAX_PERIODIC_LOAD 500 /* out of 1000 usec */
@@ -843,6 +846,7 @@ static int sl811h_urb_enqueue(
if (!(sl811-port1 (1 USB_PORT_FEAT_ENABLE))
|| !HC_IS_RUNNING(hcd-state)) {
retval = -ENODEV;
+ kfree(ep);
goto fail;
}
@@ -911,8 +915,16 @@ static int sl811h_urb_enqueue(
case PIPE_ISOCHRONOUS:
case PIPE_INTERRUPT:
urb-interval = ep-period;
- if (ep-branch PERIODIC_SIZE)
+ if (ep-branch PERIODIC_SIZE) {
+ /* NOTE: the phase is correct here, but the value
+ * needs offsetting by the transfer queue depth.
+ * All current drivers ignore start_frame, so this
+ * is unlikely to ever matter...
+ */
+ urb-start_frame = (sl811-frame (PERIODIC_SIZE - 1))
+ + ep-branch;
break;
+ }
retval = balance(sl811, ep-period, ep-load);
if (retval 0)
@@ -1122,7 +1134,7 @@ sl811h_hub_descriptor (
desc-wHubCharacteristics = (__force __u16)cpu_to_le16(temp);
/* two bitmaps: ports removable, and legacy PortPwrCtrlMask */
- desc-bitmap[0] = 1 1;
+ desc-bitmap[0] = 0 1;
desc-bitmap[1] = ~0;
}
[linux-usb-devel] Usb storage devices auto-promoted to scsi2 spec issue
I was curious about the reasoning behind this decision and how to fix an issue that came up because of it. Here is the issue found: 1) Some USB storage peripherals identify themselves as following scsi spec 0 (i.e. we don't follow a spec, we just kinda magically work with some of the commands formatted in a scsi sort of way). There are various reasons for this, such as they don't follow all of scsi3 and just support enough basic commands like reads and writes. 2) The USB storage stack auto-promotes these spec 0 devices to spec 2 3) The SCSI stack, now thinking these are spec 2 devices, maskes in LUN info into cdb[ 1 ] 4) Some raw commands (vendor specific and others) on these USB storage devices don't work because cdb[ 1 ] has those 3 bits changed. A more concrete example: 1) USB storage device supports SCSI-ATA cdb passthru (SAT spec at www.t10.org) but reports it follows spec 0 2) Anytime you issue a passthru cdb, cdb[ 1 ] gets mangled, corrupting bits that are inmportant in the cdb I have some time to help in solving the above. But what do people think the solution should be? Here are some ideas floating in my head: 1) Promote the scsi0 device to scsi3 (instead of scsi2) since it most likely follows scsi3 forms of commands that it happens to support 2) Leave the scsi0 device as scsi0, and make sure the scsi stack is aware of scsi0 devices (i.e. don't stick LUN info into cdb[ 1 ] ) (1) Is easy to do, but is it going to cause other issues? I'd imagine any *usb storage* device that reports scsi0 really implements the scsi3 form of the commands that it happens to support. (2) Is more invasive, but is probably more of a correct solution. This will require a larger effort involving multiple groups coordinating the efforts. Any thoughts? Thanks for your time, Tim Thelin --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Usb storage devices auto-promoted to scsi2 spec issue
On Wednesday 14 September 2005 19:45, Timothy Thelin wrote: I was curious about the reasoning behind this decision and how to fix an issue that came up because of it. ... (1) Is easy to do, but is it going to cause other issues? I'd imagine any *usb storage* device that reports scsi0 really implements the scsi3 form of the commands that it happens to support. (2) Is more invasive, but is probably more of a correct solution. This will require a larger effort involving multiple groups coordinating the efforts. I can't really comment on the rest of your mail, even though the points seem well thought-out, but I would like to offer just a single comment: Why would a usb-storage device ever report itself as scsi0 if it actually supports scsi3? Is it because the USB/ATA bridge spec doesn't support asking the device it self, so the usb-subsystem just makes an (un? ;)-educated guess? Or is it because it is possible, but the devices can't be trusted to tell the truth? -- Regards, Christian Iversen --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ 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] Fw: [Bugme-new] [Bug 5250] New: Cannot find USB devices on 2.6.13.1, on ICH4m chipset
A regression. Begin forwarded message: Date: Wed, 14 Sep 2005 07:13:56 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bugme-new] [Bug 5250] New: Cannot find USB devices on 2.6.13.1, on ICH4m chipset http://bugzilla.kernel.org/show_bug.cgi?id=5250 Summary: Cannot find USB devices on 2.6.13.1, on ICH4m chipset --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Usb storage devices auto-promoted to scsi2 spec issue
On Wed, Sep 14, 2005 at 10:45:37AM -0700, Timothy Thelin wrote: I was curious about the reasoning behind this decision and how to fix an issue that came up because of it. The reasoning goes something like this: There are lots of devices which report 0, but need the SCSI-II 10-byte commands to work. I have some time to help in solving the above. But what do people think the solution should be? Here are some ideas floating in my head: 1) Promote the scsi0 device to scsi3 (instead of scsi2) since it most likely follows scsi3 forms of commands that it happens to support That's not going to fly. Lots of devices report 0 and follow 2, not 3. SCSI 3 triggers new and exciting behavior from SCSI core. 2) Leave the scsi0 device as scsi0, and make sure the scsi stack is aware of scsi0 devices (i.e. don't stick LUN info into cdb[ 1 ] ) That will break all the devices which report 0 but need 10-bit commands ala SCSI-II. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I need a computer? -- Customer User Friendly, 2/19/1998 pgp9ekCM0vzjI.pgp Description: PGP signature
Re: [linux-usb-devel] Usb storage devices auto-promoted to scsi2 spec issue
On Wed, Sep 14, 2005 at 08:29:19PM +0200, Christian Iversen wrote: On Wednesday 14 September 2005 19:45, Timothy Thelin wrote: I was curious about the reasoning behind this decision and how to fix an issue that came up because of it. ... (1) Is easy to do, but is it going to cause other issues? I'd imagine any *usb storage* device that reports scsi0 really implements the scsi3 form of the commands that it happens to support. (2) Is more invasive, but is probably more of a correct solution. This will require a larger effort involving multiple groups coordinating the efforts. I can't really comment on the rest of your mail, even though the points seem well thought-out, but I would like to offer just a single comment: Why would a usb-storage device ever report itself as scsi0 if it actually supports scsi3? Is it because the USB/ATA bridge spec doesn't support asking the device it self, so the usb-subsystem just makes an (un? ;)-educated guess? Or is it because it is possible, but the devices can't be trusted to tell the truth? It's the last one. Lots and lots of devices lie outright about this. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver S: Another stupid question? G: There's no such thing as a stupid question, only stupid people. -- Stef and Greg User Friendly, 7/15/1998 pgpiVVElJ7d18.pgp Description: PGP signature
RE: [linux-usb-devel] Usb storage devices auto-promoted to scsi2 spec issue
On Wednesday 14 September 2005 19:45, Timothy Thelin wrote: I was curious about the reasoning behind this decision and how to fix an issue that came up because of it. ... (1) Is easy to do, but is it going to cause other issues? I'd imagine any *usb storage* device that reports scsi0 really implements the scsi3 form of the commands that it happens to support. (2) Is more invasive, but is probably more of a correct solution. This will require a larger effort involving multiple groups coordinating the efforts. I can't really comment on the rest of your mail, even though the points seem well thought-out, but I would like to offer just a single comment: Why would a usb-storage device ever report itself as scsi0 if it actually supports scsi3? Is it because the USB/ATA bridge spec doesn't support asking the device it self, so the usb-subsystem just makes an (un? ;)-educated guess? Or is it because it is possible, but the devices can't be trusted to tell the truth? The reason they don't report scsi3 is because they don't claim to follow scsi3. They just *happen* to work with some cdbs that are formatted in a scsi way (probably scsi3 since these devices are newer). Since USB storage devices are getting made as cheaply as possible, they seem to do the minimal job necessary to support scsi commands; you can do your standard commands like inquiry, read, write, and some mode pages but they don't support the whole spec. So in consequence some (many?) of these devices say they support scsi spec 0. Which if you look at the scsi3 spec, 0 is a legitimate (not deprecated, reserved, or obsolete) value stating I don't claim to follow any scsi spec So the devices simply *happen* to work with the basic scsi commands. (Note: the above two paragraphs are my understanding of the issue after talking with people about these scsi0 devices that are appearing. It could be more complicated than the above, because each vendor has his reasons, but it doesn't stop the fact that these scsi0 devices exist) And so the issue is that the USB stack is auto-promoting these scsi0 devices to scsi2, and in turn the scsi stack adds LUN info to cdb[ 1 ] as per the scsi2 spec. So with the above in mind, here are the motivations behind those 2 solution proposals: Now since these devices were made recently with the scsi3 form of the spec in full-swing, I'd reason the form of the commands they *happen* to support are the scsi3 version since they need some sort of compatibility with the OS. This is the motivation behind the proposal to promote scsi0 USB storage devices to scsi3 devices. The question is are there scsi0 USB storage devices that don't support scsi3 commands enough? On the other hand, the more correct solution is to not promote at all and make the scsi stack aware of scsi0 devices. Basically this would mean the scsi stack would not auto-doing-anything since it does not know if the device needs it (i.e. adding in LUN info to cdb[ 1 ] ). This seems more correct of a solution, it's a lot more work and involves modifying both usb-storage and the scsi stack. Now granted the BEST solution would be for these USB storage devices to actually implement scsi3 like they should be doing, but they won't and so the software stacks need to take this into account somehow. Regards, Tim Thelin --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
RE: [linux-usb-devel] Usb storage devices auto-promoted to scsi2 spec issue
On Wed, Sep 14, 2005 at 10:45:37AM -0700, Timothy Thelin wrote: I was curious about the reasoning behind this decision and how to fix an issue that came up because of it. The reasoning goes something like this: There are lots of devices which report 0, but need the SCSI-II 10-byte commands to work. I have some time to help in solving the above. But what do people think the solution should be? Here are some ideas floating in my head: 1) Promote the scsi0 device to scsi3 (instead of scsi2) since it most likely follows scsi3 forms of commands that it happens to support That's not going to fly. Lots of devices report 0 and follow 2, not 3. hmm then I guesss the information I got is off. Thanks for the clarification. SCSI 3 triggers new and exciting behavior from SCSI core. 2) Leave the scsi0 device as scsi0, and make sure the scsi stack is aware of scsi0 devices (i.e. don't stick LUN info into cdb[ 1 ] ) That will break all the devices which report 0 but need 10-bit commands ala SCSI-II. Yeah I was wondering how much breakage would occur. I guess that kills that idea. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
RE: [linux-usb-devel] Usb storage devices auto-promoted to scsi2 spec issue
Why would a usb-storage device ever report itself as scsi0 if it actually supports scsi3? Is it because the USB/ATA bridge spec doesn't support asking the device it self, so the usb-subsystem just makes an (un? ;)-educated guess? Or is it because it is possible, but the devices can't be trusted to tell the truth? It's the last one. Lots and lots of devices lie outright about this. Matt I don't suppose you might have an alternative solution for allowing scsi0 devices to accept things like the SCSI-ATA passthru cdb unmangled by LUN info then? Tim --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
RE: [linux-usb-devel] Usb storage devices auto-promoted to scsi2 spec issue
On Wed, 14 Sep 2005, Timothy Thelin wrote: SCSI 3 triggers new and exciting behavior from SCSI core. Note that usb-storage even sets the version number for SCSI-3 devices back to 2. That's because a lot of them report SCSI-3 and then crash when asked to carry out a REPORT LUNS command. It ought to be possible to add a flag that would prevent the SCSI midlayer from overlaying the LUN bits on top of cdb[1]. Then we could still set the revision number to 2 and you would be happy. Are these vendor-specific commands, the ones that need those bits, available in devices that use other SCSI transports as well as SCSI-over-USB? Alan Stern --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ 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] Fw: [Bugme-new] [Bug 5253] New: usb storage disappears after hotplug
A regression wrt 2.6.11. Begin forwarded message: Date: Wed, 14 Sep 2005 11:04:54 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bugme-new] [Bug 5253] New: usb storage disappears after hotplug http://bugzilla.kernel.org/show_bug.cgi?id=5253 Summary: usb storage disappears after hotplug Kernel Version: 2.6.13.1 --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
RE: [linux-usb-devel] Usb storage devices auto-promoted to scsi2 spec issue
It ought to be possible to add a flag that would prevent the SCSI midlayer from overlaying the LUN bits on top of cdb[1]. Then we could still set the revision number to 2 and you would be happy. Sounds plausable, but i'm not an expert on the Linux scsi stack to know where the flag would exist. One idea is to add the flag to SG_IO, since both vendor and SCSI-ATA passthru cdb's would use this mechanism (most likely). The purpose of the flag could be to say don't modify the cdb in any way, a solution more general than just don't add LUN info Thoughts? Are these vendor-specific commands, the ones that need those bits, available in devices that use other SCSI transports as well as SCSI-over-USB? I don't have enough exposure to the scsi-world to know. However I found the issue on a cypress USB bridge: http://www.cypress.com/portal/server.pt?space=CommunityPagecontrol=SetCommu nityCommunityID=209PageID=259fid=14rpn=CY7C68320 (or one of its siblings) Page 13 of its datasheet describes a 16-byte ata passthru cdb that does not work under Linux because of the auto-LUN behavior (the bridge reports scsi0 on inquiry). The issue also theoretically applies to any device implementing the SCSI-ATA passthru cdb. Thanks, Tim Thelin --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [patch 2.6.14-rc1, 3/5] remove usb_suspend_device() parameter
On Wed, 14 Sep 2005, David Brownell wrote:
The parameter isn't needed, or even usable, without the recursion
removed in the previous patch.
These patches look great, and I intend to go through them carefully. At
first glance, there appears to be a small problem in the pm-usbsusp patch:
Not with that patch ... it's actually in the CURRENT kernel unless it's
got CONFIG_USB_SUSPEND set!
Notice the FIXME added by pm-config.patch; it's part of the underlying
issue ... which by my reading isn't in this routine (yet). (And it's
unrelated to any usb_suspend_device parameter; $SUBJECT is irrelevant
other than patch.)
(Yes, sorry about the $SUBJECT -- I replied to the message containing the
objectionable patch instead of the 0/5 summary message.)
There are in fact two distinct but related problems here. One is the
problem you mention, in which usbcore doesn't call the root-hub-suspend
methods if CONFIG_USB_SUSPEND isn't set. But I was talking about a
different problem. Even when CONFIG_USB_SUSPEND is set, your patch will
prevent usbcore from suspending root hubs during FREEZE events. The
patch should have said something more like this:
+ udev = to_usb_device(dev);
+ if (message.event == PM_EVENT_FREEZE udev-parent) {
+ dev-power.power_state = message;
+ return 0;
+ }
+ return usb_suspend_device (udev);
This seems related to two OHCI regressions I noticed, by the way.
In one case, resume-via-reset seems broken without CONFIG_USB_SUSPEND;
the root hub timer doesn't restart correctly. (It tries to resubmit
the URB while the hub is suspended, fails, then dies.) In the other,
wakeup is broken since khubd never notices USB_PORT_STAT_C_SUSPEND;
as if the root hub timer stopped (new behavior?) and didn't restart.
It looks like the first problem is a logical error in the USB resume code:
Device states are set back to USB_STATE_CONFIGURED _after_ the devices are
resumed. Naturally, URBs can complete as soon as the physical resume is
done, and completion handlers may try to resubmit -- but they will fail
until the state is set back. Clearly the state needs to be changed
_before_ the resume is done.
I don't understand the second problem. Why would you expect wakeup to
work when CONFIG_USB_SUSPEND isn't set? Why should it have to work at
all in that case?
You skip calling usb_suspend_device for FREEZE events. That's good for
external devices, but it's not good for root hubs. They really do need to
be suspended even for FREEZE events, since FREEZE requires no interrupts
or DMA.
Remember that HCDs consist of two hardware interfaces, which can normally
be managed somewhat separately:
- Root hub, which is the down-stream link. These are managed through
calls into the HCD: hub_suspend(), hub_resume(), the code handling
control requests, status polling, and so on.
- Controller, the upstream link. Sometimes controllers support
lower power modes than even root hub suspended (like off, or
even just clock off), or they're like PCI (or PCMCIA) and have
additional control protocols to follow.
Now, the FIXME that I mentioned is basically that suspend/resume linkage
to the root hubs needs reworking. Today, it's completely unused unless
CONFIG_USB_SUSPEND is set ... so all the HCDs have code inside the
controller suspend/resume calls to cope with that.
That is: root hubs currently never see FREEZE except indirectly through
the upstream link ... except with the non-default CONFIG_USB_SUSPEND.
Right. And with your new patch they won't see FREEZE at all, since that
indirect upstream link gets used only when CONFIG_USB_SUSPEND isn't set.
(At least, that's how uhci-hcd works; maybe other HCDs are different.)
I suspect the right fix will involve adding to the code which you quoted,
by calling hcd-hub_suspend(); similarly on resume. That'll be a nice
step towards shrinking what CONFIG_USB_SUSPEND covers, and removing bugs
associated with the other setting of that option.
If we just got rid of CONFIG_USB_SUSPEND entirely, this wouldn't be an
issue... :-)
Maybe a better fix for this problem would be to make the non-USB_SUSPEND
version of usb_suspend_device more than just an empty placeholder. If the
device is a root hub, do perform the hcd-hub_suspend call. And likewise
for usb_resume_device, of course. Then all that special indirect upstream
stuff could be removed from the HCDs.
This will be easy to fix, of course.
Just changing all the HCDs, the remote wakeup support, and the normal
suspend/resume paths ... and retesting them all both with and without
CONFIG_USB_SUSPEND, root hub timers, etc.
Not easy enough to be 2.6.14 material, I suspect!!
I meant that the alteration to your pm-usbsusp patch (given above) was
easy.
Bringing up this next point may be a mistake, but bear with me... Now
that
[linux-usb-devel] [RFC PATCH] USB: add endpoint information to sysfs
Any objections to me adding this to mainline after 2.6.14 comes out?
I think we now have all of the information that is in
/proc/bus/usb/devices in sysfs. Or does anyone know of anything we are
missing?
And yes, it's a huge pain to dynamically create sysfs attributes and
attribute groups on the fly, but I couldn't think of any other way to do
this. Any suggestions?
This also takes advantage of the ability to do create a different type
of attribute, and use it from within the sysfs callback, something that
I don't think people really realize is now possible.
thanks,
greg k-h
--
This patch adds endpoint information for both devices and interfaces to
sysfs. Previously it was only possible to get the endpoint information
from usbfs, and never possible to get any information on endpoint 0.
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
drivers/usb/core/sysfs.c | 195 ++-
include/linux/usb.h |4
2 files changed, 197 insertions(+), 2 deletions(-)
--- gregkh-2.6.orig/drivers/usb/core/sysfs.c2005-08-28 16:41:01.0
-0700
+++ gregkh-2.6/drivers/usb/core/sysfs.c 2005-09-14 15:02:43.0 -0700
@@ -22,6 +22,174 @@
#include usb.h
+/* endpoint stuff */
+struct endpoint_attribute {
+ struct device_attribute dev_attr;
+ struct usb_endpoint_descriptor *endpoint;
+ struct usb_device *udev;
+};
+#define to_endpoint_attr(_dev_attr) \
+ container_of(_dev_attr, struct endpoint_attribute, dev_attr)
+
+#define usb_ep_attr(field, format_string)
\
+static ssize_t show_ep_##field(struct device *dev, struct device_attribute
*attr, \
+ char *buf)
\
+{
\
+ struct endpoint_attribute *endpoint_attr = to_endpoint_attr(attr);
\
+
\
+ return sprintf(buf, format_string, endpoint_attr-endpoint-field);
\
+}
+usb_ep_attr(bLength, %02x\n)
+usb_ep_attr(bDescriptorType, %02x\n)
+usb_ep_attr(bEndpointAddress, %02x\n)
+usb_ep_attr(bmAttributes, %02x\n)
+usb_ep_attr(bInterval, %02x\n)
+
+static ssize_t show_ep_wMaxPacketSize(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct endpoint_attribute *endpoint_attr = to_endpoint_attr(attr);
+
+ return sprintf(buf, %04x\n,
+ le16_to_cpu(endpoint_attr-endpoint-wMaxPacketSize)
0x07ff);
+}
+
+static ssize_t show_ep_type(struct device *dev, struct device_attribute *attr,
char *buf)
+{
+ struct endpoint_attribute *endpoint_attr = to_endpoint_attr(attr);
+ char *type = unknown;
+
+ switch (endpoint_attr-endpoint-bmAttributes
USB_ENDPOINT_XFERTYPE_MASK) {
+ case USB_ENDPOINT_XFER_CONTROL:
+ type = Control;
+ break;
+ case USB_ENDPOINT_XFER_ISOC:
+ type = Isoc;
+ break;
+ case USB_ENDPOINT_XFER_BULK:
+ type = Bulk;
+ break;
+ case USB_ENDPOINT_XFER_INT:
+ type = Interrupt;
+ break;
+ }
+ return sprintf(buf, %s\n, type);
+}
+
+static ssize_t show_ep_interval(struct device *dev, struct device_attribute
*attr, char *buf)
+{
+ struct endpoint_attribute *endpoint_attr = to_endpoint_attr(attr);
+ struct usb_device *udev = endpoint_attr-udev;
+ struct usb_endpoint_descriptor *endpoint = endpoint_attr-endpoint;
+ char unit;
+ unsigned interval = 0;
+ unsigned in;
+
+ in = (endpoint-bEndpointAddress USB_DIR_IN);
+
+ switch (endpoint-bmAttributes USB_ENDPOINT_XFERTYPE_MASK) {
+ case USB_ENDPOINT_XFER_CONTROL:
+ if (udev-speed == USB_SPEED_HIGH) /* uframes per NAK */
+ interval = endpoint-bInterval;
+ break;
+ case USB_ENDPOINT_XFER_ISOC:
+ interval = 1 (endpoint-bInterval - 1);
+ break;
+ case USB_ENDPOINT_XFER_BULK:
+ if (udev-speed == USB_SPEED_HIGH !in) /* uframes per
NAK */
+ interval = endpoint-bInterval;
+ break;
+ case USB_ENDPOINT_XFER_INT:
+ if (udev-speed == USB_SPEED_HIGH) {
+ interval = 1 (endpoint-bInterval - 1);
+ } else
+ interval = endpoint-bInterval;
+ break;
+ }
+ interval *= (udev-speed == USB_SPEED_HIGH) ? 125 : 1000;
+ if (interval % 1000)
+ unit = 'u';
+ else {
+ unit = 'm';
+ interval /= 1000;
+ }
+
+ return sprintf(buf, %d%cs\n, interval, unit);
+}
+
+static ssize_t show_ep_direction(struct device *dev, struct device_attribute
*attr, char *buf)
+{
+
[linux-usb-devel] Re: High speed device initialization
I haven't been able to understand why the transfers fail under Linux whereas it works fine under Windows (note that I am using the same Windows driver in Linux, albeit with ndiswrapper). All URBs exchanged until the failed URB seem to be identical. The URB that fails is 2400 bytes long bulk IN URB. I am wondering if the timeout is due to large(?) buffer, considering it is running as full speed device and not high speed device (see earlier post about initialization issues). That is, if Windows driver asks to read 2400 bytes, would it help to split it as two URB requests, each of length 1200 bytes and when second URB is completed, copy both buffers back into Windows driver's buffer. This makes ndiswrapper more complicated, especially with error processing, but I will try at least as a first cut to see if this helps. Please let me know if you have any suggestions/ideas to fix this issue. Thanks, Giri --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Usb storage devices auto-promoted to scsi2 spec issue
On Wed, Sep 14, 2005 at 12:19:39PM -0700, Timothy Thelin wrote: Why would a usb-storage device ever report itself as scsi0 if it actually supports scsi3? Is it because the USB/ATA bridge spec doesn't support asking the device it self, so the usb-subsystem just makes an (un? ;)-educated guess? Or is it because it is possible, but the devices can't be trusted to tell the truth? It's the last one. Lots and lots of devices lie outright about this. Matt I don't suppose you might have an alternative solution for allowing scsi0 devices to accept things like the SCSI-ATA passthru cdb unmangled by LUN info then? What's the command source? If you're coming in via the SG interface, there's a command flag to set which prevents LUN info from being imposed on the CDB. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver NYET! The evil stops here! -- Pitr User Friendly, 6/22/1998 pgpuTGGnNzQtW.pgp Description: PGP signature
Re: [linux-usb-devel] Usb storage devices auto-promoted to scsi2 spec issue
On Wed, Sep 14, 2005 at 01:18:52PM -0700, Timothy Thelin wrote: It ought to be possible to add a flag that would prevent the SCSI midlayer from overlaying the LUN bits on top of cdb[1]. Then we could still set the revision number to 2 and you would be happy. Sounds plausable, but i'm not an expert on the Linux scsi stack to know where the flag would exist. One idea is to add the flag to SG_IO, since both vendor and SCSI-ATA passthru cdb's would use this mechanism (most likely). The purpose of the flag could be to say don't modify the cdb in any way, a solution more general than just don't add LUN info That flag already exists. SG_FLAG_LUN_INHIBIT -- see sg.torque.net for details. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver YOU SEE!!?? It's like being born with only one nipple! -- Erwin User Friendly, 10/19/1998 pgpOt1e1IzeTv.pgp Description: PGP signature
Re: [linux-usb-devel] application's close function call
On Wed, Sep 14, 2005 at 09:57:59AM +0530, Savita H. Neelannava wrote: Hi All, I am wrtting USB scanner driver is 2.6.11 kernel. The usb scanner driver has been removed from the 2.6 kernel tree a while ago. Please use usbfs instead for this, you do not need a kernel driver for it. thanks, greg k-h --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ 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] nitpick in hub.c:usb_new_device()
Hi All, While working on a driver for an in-house built usb board, I found that even when the board failed to register the id strings were printed out. This ended up confusing me for a short while as I expected the strings to only show up if the device registered successfully. What about moving the getstring/showstring sequences to after the usb_set_configuration if bracket? This would ensure that the device id strings print out only if the usb_new_device registered the client successfully. What does everyone think? Bill Rees Nascar Silicon Motor Speedway, perfect line --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
RE: [linux-usb-devel] Usb storage devices auto-promoted to scsi2 spec issue
That flag already exists. SG_FLAG_LUN_INHIBIT -- see sg.torque.net for details. Matt Thanks, I somehow missed that. It should solve my problem. Tim --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ 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] Testing the USB host controller on linux 2.6.12
From: Conio sandiago [EMAIL PROTECTED] Date: Tue, 13 Sep 2005 10:12:09 +0200 Hi all I have a USB host controller on a application board. The OS is Linux kernel 2.6.12 Now i want to test the USB host controller. Please explain Start with http://www.linux-usb.org/usbtest/ and make sure you pass all those tests ... you should be able to leave them running for a week or more and not see any problems. - Dave --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ 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] High-speed host controller testing for 2.4 kernel
From: Nishant Kamat [EMAIL PROTECTED] Date: Mon, 12 Sep 2005 19:24:30 -0500 Hi, I would like some suggestions for testing a high-speed host controller driver which is based on a 2.4 kernel. Well, http://www.linux-usb.org/usbtest is the best way to test things, but that's only for 2.6 kernels. Some of the tests there are verifying things that work differently on 2.4 kernels; anything to do with URB queueing is out. (And unfortunately that includes test 10, which is really good at turning up problems with host or peripheral controller drivers.) But you should be able to use the synchronous control and bulk tests without much trouble. I was thinking of using the 'usbstress' suite with some high-speed EZ-USB device. However I don't think the firmware for it works for high-speed. I was wondering if anyone had fixed the firmware for high-speed operation. I tried usbstress once and gave up. Maybe you'll have better luck. I've certainly used EZ-USB FX2 devices to test high speed host controller software. If you're willing to spend the time writing high speed test firmware in 8051 assembler, more power to you. (Keil C, or SDCC, are also options; but it's still low level device driver code on an 8 bit CPU...) Would it be a good try to make usbstress work with gadget zero and then use net2280 device? Has anyone tried that before? I bet it'd be a lot quicker to just backport drivers/usb/misc/usbtest.c and comment out the queueing stuff. - Dave --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ 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] [RFC PATCH] USB: add endpoint information to sysfs
On Wed, 14 Sep 2005, Greg KH wrote:
Any objections to me adding this to mainline after 2.6.14 comes out?
I think we now have all of the information that is in
/proc/bus/usb/devices in sysfs. Or does anyone know of anything we are
missing?
And yes, it's a huge pain to dynamically create sysfs attributes and
attribute groups on the fly, but I couldn't think of any other way to do
this. Any suggestions?
This also takes advantage of the ability to do create a different type
of attribute, and use it from within the sysfs callback, something that
I don't think people really realize is now possible.
Nice. Here are a few thoughts:
This adds to sysfs all the information in /proc/bus/usb/devices _for the
active configuration and the current altsettings_. There's nothing about
the other configurations or altsettings, and of course we don't really
want there to be.
Your usb_{create|remove}_intf_ep_files routines are called whenever
interfaces are created or destroyed. But you also need to call them
whenever an altsetting is changed. Which causes difficulties, because in
usb_remove_ep_files, it will no longer be safe to kfree all those data
structures. Unlike interfaces, altsettings aren't refcounted. All the
altsettings for an interface are created/removed at the same time as the
configuration (actually, the interface_cache).
What is the overhead, in terms of memory usage, of creating all these
structures for the sysfs attributes?
Alan Stern
---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42 plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
___
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] nitpick in hub.c:usb_new_device()
On Wed, 14 Sep 2005, Bill Rees wrote: Hi All, While working on a driver for an in-house built usb board, I found that even when the board failed to register the id strings were printed out. This ended up confusing me for a short while as I expected the strings to only show up if the device registered successfully. What about moving the getstring/showstring sequences to after the usb_set_configuration if bracket? This would ensure that the device id strings print out only if the usb_new_device registered the client successfully. What does everyone think? Those ID strings are useful for debugging, if nothing else. My preference is to leave the print statements where they are, and change the routine so that failure of usb_set_configuration isn't fatal. In fact, that's what I did in a patch recently posted for comments: http://marc.theaimsgroup.com/?l=linux-usb-develm=112569555202368w=2 Alan Stern --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
