[linux-usb-devel] kein Betreff
Hi, I'm developing an embedded device with USB support. I'm using a 2.4.31 USB kernel for printer and mass storage support. I have some trouble with UHCI devices behind an external HUB (it works on the root hub). The problem is, that the USB device won't be enumerated if it reports a max packet size larger than 8 in its device descriptor. I'm able to change the device firmware for testing purposes and I figured out, if I use a max packet size of 8, than ervery thing is fine. If I use a max packet size of 16, than the enumeration fails. Unfortunately, there are a lot of USB memory sticks on the market, with max packet size 8. The enumeration fails that way, that the device sends first part (8 bytes) of the device descriptor to the host, showing a max packet size of 16. The device descriptor itself is 18 byte long. After that the host should start aksing for the device descriptor again, supporting the new packet lenght. In fact, he does so, but stops after reading the first 16 bytes. Normally, I would expect, that the host starts another IN transaction to fetch the missing to bytes. This works for the roothub (as mentioned above), but when connected to an external HUB, the HOST stops here and starts a complete new enumeration. Any idea? Thanks for you help, Christian. __ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.17 hangs during boot on ASUS M2NPV-VM motherboard
On Fri, 14 Jul 2006 14:50:16 -0400 (EDT)
Alan Stern [EMAIL PROTECTED] wrote:
On Fri, 14 Jul 2006, Andrew Morton wrote:
On Fri, 14 Jul 2006 16:54:25 +0100
Andy Chittenden [EMAIL PROTECTED] wrote:
So I guess there's something awry with the USB
controller driver?
Is there any other info that someone wants to track
this down? Or has
someone got a fix?
It's hard to come up with a fix without knowing what's
wrong. The current
development version of that subroutine is essentially the
same as the
version in 2.6.17.
If you want to pin down the problem more precisely, try
adding a whole
bunch of printk() statements to the
quirk_usb_handoff_ohci() function in
drivers/usb/host/pci-quirks.c.
Andy, please add the below, work out what line it gets stuck
at and then
let us know? Thanks.
Well I did that and the kernel got a lot further! It ran through the
pci_init stuff without a hitch and then hung just after this line was
output:
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver
(PCI)
So I littered drivers/usb/host/ohci-pci.c with similar debugging and the
last line it printed was from (marked with ---):
static int __init ohci_hcd_pci_init (void)
{
int ret;
printk (KERN_DEBUG %s: DRIVER_INFO (PCI)\n, hcd_name);
if (usb_disabled())
return -ENODEV;
D();
pr_debug (%s: block sizes: ed %Zd td %Zd\n, hcd_name,
sizeof (struct ed), sizeof (struct td));
--- D();
ret = pci_register_driver (ohci_pci_driver);
D();
return ret;
}
IE it never returned from pci_register_driver.
A bit more sprinkling of debugging showed it got to drivers/base/bus.c
(bus_add_driver()):
D();
driver_attach(drv);
D();
It never returned from driver_attach().
More debugging in drivers/base/dd.c showed the last output to be (marked
with ---):
static int __driver_attach(struct device * dev, void * data)
{
struct device_driver * drv = data;
/*
* Lock device and try to bind to it. We drop the error
* here and always return 0, because we need to keep trying
* to bind to devices and some drivers will return an error
* simply if it didn't support the device.
*
* driver_probe_device() will spit a warning if there
* is an error.
*/
---D();
if (dev-parent)/* Needed for USB */
down(dev-parent-sem);
D();
IE it never returned from down.
So why did putting in the initial lot of debug alter where the kernel
hung? And what's next?
NB a reminder: 2.6.16 boots up fine on this machine.
--
Andy, BlueArc Engineering
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] different phenomena at Windows XP
Hi,all Now,i have been testing my udc driver at windowsXP host. But,i find there are different phenomena at the WindowsXP host Both hosts are XP Service Pack2.Marked C1(computer 1) and C2(computer 2). 1. C1. When finish function of done() for SETUP 80.06 v0300 i l00ffappearscomplete ep0 req c13e9220 stat 0 len 4/4 The host sends CLEAR_FEATURE,But the udc program can return to normal. C2.It is no halt thing at C2 2.When i have two medium,one is nand-flash,and the other is sd card.I can only find one removable disk at C1,which one is the first at insmod param,which will appear at WindowsXP host.At C2,i can see 2 removalbe disks. C1.g_file_storage gadget: bulk-out, length 31: 7 0: 55 53 42 43 58 25 99 84 00 00 00 00 00 00 06 00 710: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7g_file_storage gadget: SCSI command: TEST UNIT READY; Dc=6, Dn=0; Hc=6, Hn=0 g_file_storage gadget: bulk-in, length 13: C2.g_file_storage gadget: bulk-out, length 31: 7 0: 55 53 42 43 b8 75 97 81 00 00 00 00 00 01 06 00 710: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7g_file_storage gadget: SCSI command: TEST UNIT READY; Dc=6, Dn=0; Hc=6, Hn=0 7g_file_storage gadget: using LUN 1 from CBW, not LUN 0 from CDB 7g_file_storage gadget: bulk-in, length 13: The C1's CBW,the field of bCBWLUN is 0,the C2 is 1. Before at the CBW which the bCBWLUN field is 0(1), both of computers send several SCSI command: READ(10); Dc=10, Di=4096; Hc=10, Hi=4096 I want to find the reason,and work over it. But i can't find the source of the error. Can u give me some tips? - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] problem with webcam look 312p
Helow list. I am tryin to install the driver spca5xx, but I need to now how to compile the driver. tank you for any heelp! _ Charla con tus amigos en línea mediante MSN Messenger: http://messenger.latam.msn.com/ - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] problem with webcam look 312p
Hi, On 7/17/06, wagner corrales madrigal [EMAIL PROTECTED] wrote: Helow list. I am tryin to install the driver spca5xx, but I need to now how to compile the driver. tank you for any heelp! Which webcam you are using? Give its USB IDs from /sbin/lsusb output. Which Os you are using? If you already got Spca5xx driver tarball. just extract it and give make and then make install command. then attach camera and check dmesg output whether your webcam is detected or not by Spca5xx? Regards, Parag. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] re-plug needed during ESD testing
On Mon, 17 Jul 2006, Aras Vaichas wrote: Eventually they ran the test with the laptop disconnected and then reconnected our device to see if it still worked after each type of test. It took a while longer, but we passed. That's good. * Is there something in the USB host management code that ignores a USB device which is acting strangely? Yes, there is. If a device fails to enumerate after 4 attempts, the USB stack will ignore it until a disconnect event occurs. However, at each reconnect everything should restart from the beginning. So when those electrical pulses stopped, the device should have been enumerated correctly. Is that in the USB specification? No, it's just the way the Linux USB stack is written. Other operating systems will behave differently. It would be better to tackle the shortcomings of the host by fixing the host's software. To start with, you should compile the host's kernel with CONFIG_USB_DEBUG and then post the host's system log for the test period. I'll try and include some form of host logging for the next barrage of tests if I can. I couldn't do anything this time because we couldn't delay the tests and miss our pre-booked (and expensive) testing window. I'll try and think of a way to simulate this test in the office if I can. I think the test was a short 1000V pulse, every 300ms on the power line. It must have caused the ground to bounce around relative to the laptop which detected it as a USB disconnect (I guess). I could probably rig up something similar that applies the same principle to the USB cable (not with a 1000V though!). These rapid repeated disconnects are a kind of stress testing the Linux USB host code is hardly ever exposed to. It's not surprising that eventually it would fail. Alan Stern - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [RFC 0/4] USB autosuspend/autoresume
Everybody: I wanted to get this onto the public lists before heading out to OLS, so here it is. Following is a series of four patches implementing autosuspend and autoresume for USB. The only interface drivers altered are the hub driver and usb-skeleton, so most of the features will be visible only with hubs. Here are the ideas behind the design. The first idea is that each suspend or resume event is propagated up the device tree: Whenever a device suspends or resumes, its parent hub is notified. When a device suspends it may turn out the parent hub has no more unsuspended children; in that case the parent hub will in turn be autosuspended, and so on up the tree. Or it may turn out that we want to resume a device but the parent hub is also suspended; in that case the parent hub will be resumed first, and its parent if needed, and so on. The autoresumes occur immediately, but there is a short delay between the time an autosuspend is requested and when it is carried out. This delay is necessary to prevent bouncing of devices between awake and asleep states. (Imagine what would happen otherwise if you had a complicated tree of devices, all suspended, and ran lsusb -- every hub would have to go through a resume/suspend cycle once for each device behind it.) To implement the delay, a work_struct has been added to struct usb_device. This was the simplest approach, although not the most space-efficient. I set the delay length to 2 seconds. Perhaps shorter would be better and perhaps it will need to vary by device; we won't know until we have more experience. The second idea is that suspend() and resume() method calls can no longer protected by a usb_device's device lock, since the locking rules forbid acquiring these locks going up the device tree. Instead a new lock, pm_mutex, has been added to the usb_device struct. The core is careful to avoid letting PM calls occur during probe() or disconnect(), but drivers will still need to be wary of the possibility that their suspend() or resume() methods might be called at awkward times. (For now this mostly matters only for hubs; other devices don't have USB children and so don't have to worry about PM requests bubbling up from below.) The third idea is that devices should not be autosuspended at times when they are in use. There is a new pm_usage field added to both the usb_device and usb_interface structures; the device will not be autosuspended if any of these fields is larger than 0. The field in the usb_device structure follows a strict increment/decrement regimen, just like a reference counter. For example, when a usbfs device file is opened, the device is autoresumed (if it was suspended) and the device's pm_usage field in incremented. When the device file is closed, the pm_usage field is decremented and the device is autosuspended if the field is now = 0. As a different kind of example, when a suspended device sends a remote wakeup request, it and its interfaces will be resumed but the pm_usage field will remain unchanged. Unless one of the interface drivers does something, in all likelihood the device will be autosuspended again shortly afterward. The pm_usage field in the usb_interface structure is entirely under the control of the interface's driver. The driver may follow the increment/decrement reference-counter model if it wants. This is appropriate for drivers which, like usb-skeleton, expose a character-device node to userspace (pm_usage is incremented when the device node is opened and is decremented when the node is released). There are new function calls exported for interface drivers: usb_autopm_get_interface() will resume the interface's device if it is suspended and will increment the pm_usage value. usb_autopm_put_interface() will decrement the pm_usage value and submit an autosuspend request if the value is now = 0. However a driver may make its own changes to pm_usage, thereby obtaining a more flexible model for the interface's busy-ness. The hub driver does this. The fourth idea is that usbcore will do its own autosuspending and autoresuming at appropriate times. Devices are autoresumed whenever one of their interfaces is probed or unbound and also whenever usb_set_configuration() or usb_reset_composite_device() is called. When the probe, unbind, set-config, or reset call is over, the device is autosuspended unless one of the pm_usage counters is still 0. The fifth idea is that not all drivers will support autosuspend. (In these patches, only usb-skeleton and the hub driver, together with the usb_generic device driver, do.) A new flag has been added to the usb_driver and usb_device_driver structures, indicating whether the driver supports autosuspend. If the flag isn't set, then whenever the driver is bound to an interface (or device) that interface's pm_usage counter is set to 1. The non-autosuspend-aware driver will never change the counter, and hence the device
[linux-usb-devel] [RFC 1/4] USB autosuspend/autoresume
This patch (as739) adds the basic infrastructure for USB autosuspend
and autoresume. The main features are:
PM usage counters added to struct usb_device and struct
usb_interface, indicating whether it's okay to autosuspend
them or they are currently in use.
Flag added to usb_device indicating whether the current
suspend/resume operation originated from outside or as an
autosuspend/autoresume.
Flag added to usb_driver indicating whether the driver
supports autosuspend. If not, no device bound to the driver
will be autosuspended.
Mutex added to usb_device for protecting PM operations.
Unlike the device semaphore, the locking rule for the pm_mutex
is that you must acquire the locks going _up_ the device tree.
New routines handling autosuspend/autoresume requests for
interfaces and devices.
Suspend and resume requests are propagated up the device tree
(but not outside the USB subsystem).
work_struct added to usb_device, for carrying out delayed
autosuspend requests.
Autoresume added (and autosuspend prevented) during probe and
disconnect.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Index: usb-2.6/include/linux/usb.h
===
--- usb-2.6.orig/include/linux/usb.h
+++ usb-2.6/include/linux/usb.h
@@ -19,6 +19,7 @@
#include linux/fs.h /* for struct file_operations */
#include linux/completion.h /* for struct completion */
#include linux/sched.h /* for current schedule_timeout */
+#include linux/mutex.h /* for struct mutex */
struct usb_device;
struct usb_driver;
@@ -103,9 +104,13 @@ enum usb_interface_condition {
* @condition: binding state of the interface: not bound, binding
* (in probe()), bound to a driver, or unbinding (in disconnect())
* @is_active: flag set when the interface is bound and not suspended.
+ * @needs_remote_wakeup: flag set when the driver requires remote-wakeup
+ * capability during autosuspend.
* @dev: driver model's view of this device
* @usb_dev: if an interface is bound to the USB major, this will point
* to the sysfs representation for that device.
+ * @pm_usage_cnt: PM usage counter for this interface; autosuspend is not
+ * allowed unless the counter is 0.
*
* USB device drivers attach to interfaces on a physical device. Each
* interface encapsulates a single high level function, such as feeding
@@ -145,9 +150,11 @@ struct usb_interface {
* bound to */
enum usb_interface_condition condition; /* state of binding */
unsigned is_active:1; /* the interface is not suspended */
+ unsigned needs_remote_wakeup:1; /* driver requires remote wakeup */
struct device dev; /* interface specific device info */
struct device *usb_dev; /* pointer to the usb class's device,
if any */
+ int pm_usage_cnt; /* usage counter for autosuspend */
};
#defineto_usb_interface(d) container_of(d, struct usb_interface, dev)
#defineinterface_to_usbdev(intf) \
@@ -377,6 +384,15 @@ struct usb_device {
int maxchild; /* Number of ports if hub */
struct usb_device *children[USB_MAXCHILDREN];
+
+#ifdef CONFIG_PM
+ struct work_struct autosuspend; /* for delayed autosuspends */
+ struct mutex pm_mutex; /* protects PM operations */
+ int pm_usage_cnt; /* usage counter for autosuspend */
+
+ unsigned auto_pm:1; /* autosuspend/resume in progress */
+ unsigned do_remote_wakeup:1;/* remote wakeup should be enabled */
+#endif
};
#defineto_usb_device(d) container_of(d, struct usb_device, dev)
@@ -397,6 +413,17 @@ extern int usb_reset_composite_device(st
extern struct usb_device *usb_find_device(u16 vendor_id, u16 product_id);
+/* USB autosuspend and autoresume */
+#ifdef CONFIG_USB_SUSPEND
+extern int usb_autopm_get_interface(struct usb_interface *intf);
+extern void usb_autopm_put_interface(struct usb_interface *intf);
+
+#else
+#define usb_autopm_get_interface(intf) 0
+#define usb_autopm_put_interface(intf) do {} while (0)
+#endif
+
+
/*-*/
/* for drivers using iso endpoints */
@@ -596,6 +623,8 @@ struct usbdrv_wrap {
* @drvwrap: Driver-model core structure wrapper.
* @no_dynamic_id: if set to 1, the USB core will not allow dynamic ids to be
* added to this driver by preventing the sysfs file from being created.
+ * @supports_autosuspend: if set to 0, the USB core will not allow autosuspend
+ * for interfaces bound to this driver.
*
* USB interface drivers must provide a name, probe() and disconnect()
* methods, and an id_table. Other driver fields are
[linux-usb-devel] [RFC 2/4] USB autosuspend/autoresume
This patch (as740) removes the existing support for autosuspend of
root hubs. That support fit in rather awkwardly with the rest of
usbcore and it was used only by ohci-hcd. It won't be needed any more
since the hub driver will take care of autosuspending all hubs, root
or external.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Index: usb-2.6/drivers/usb/core/hcd.c
===
--- usb-2.6.orig/drivers/usb/core/hcd.c
+++ usb-2.6/drivers/usb/core/hcd.c
@@ -1476,50 +1476,6 @@ int hcd_bus_resume (struct usb_bus *bus)
return status;
}
-/*
- * usb_hcd_suspend_root_hub - HCD autosuspends downstream ports
- * @hcd: host controller for this root hub
- *
- * This call arranges that usb_hcd_resume_root_hub() is safe to call later;
- * that the HCD's root hub polling is deactivated; and that the root's hub
- * driver is suspended. HCDs may call this to autosuspend when their root
- * hub's downstream ports are all inactive: unpowered, disconnected,
- * disabled, or suspended.
- *
- * The HCD will autoresume on device connect change detection (using SRP
- * or a D+/D- pullup). The HCD also autoresumes on remote wakeup signaling
- * from any ports that are suspended (if that is enabled). In most cases,
- * overcurrent signaling (on powered ports) will also start autoresume.
- *
- * Always called with IRQs blocked.
- */
-void usb_hcd_suspend_root_hub (struct usb_hcd *hcd)
-{
- struct urb *urb;
-
- spin_lock (hcd_root_hub_lock);
- usb_suspend_root_hub (hcd-self.root_hub);
-
- /* force status urb to complete/unlink while suspended */
- if (hcd-status_urb) {
- urb = hcd-status_urb;
- urb-status = -ECONNRESET;
- urb-hcpriv = NULL;
- urb-actual_length = 0;
-
- del_timer (hcd-rh_timer);
- hcd-poll_pending = 0;
- hcd-status_urb = NULL;
- } else
- urb = NULL;
- spin_unlock (hcd_root_hub_lock);
- hcd-state = HC_STATE_SUSPENDED;
-
- if (urb)
- usb_hcd_giveback_urb (hcd, urb, NULL);
-}
-EXPORT_SYMBOL_GPL(usb_hcd_suspend_root_hub);
-
/**
* usb_hcd_resume_root_hub - called by HCD to resume its root hub
* @hcd: host controller for this root hub
Index: usb-2.6/drivers/usb/host/ohci-hub.c
===
--- usb-2.6.orig/drivers/usb/host/ohci-hub.c
+++ usb-2.6/drivers/usb/host/ohci-hub.c
@@ -135,9 +135,6 @@ static int ohci_bus_suspend (struct usb_
hcd-poll_rh = 0;
done:
- /* external suspend vs self autosuspend ... same effect */
- if (status == 0)
- usb_hcd_suspend_root_hub(hcd);
spin_unlock_irqrestore (ohci-lock, flags);
return status;
}
Index: usb-2.6/drivers/usb/core/hcd.h
===
--- usb-2.6.orig/drivers/usb/core/hcd.h
+++ usb-2.6/drivers/usb/core/hcd.h
@@ -376,17 +376,11 @@ extern int usb_find_interface_driver (st
#define usb_endpoint_out(ep_dir) (!((ep_dir) USB_DIR_IN))
#ifdef CONFIG_PM
-extern void usb_hcd_suspend_root_hub (struct usb_hcd *hcd);
extern void usb_hcd_resume_root_hub (struct usb_hcd *hcd);
extern void usb_root_hub_lost_power (struct usb_device *rhdev);
extern int hcd_bus_suspend (struct usb_bus *bus);
extern int hcd_bus_resume (struct usb_bus *bus);
#else
-static inline void usb_hcd_suspend_root_hub(struct usb_hcd *hcd)
-{
- return;
-}
-
static inline void usb_hcd_resume_root_hub(struct usb_hcd *hcd)
{
return;
Index: usb-2.6/drivers/usb/core/hub.c
===
--- usb-2.6.orig/drivers/usb/core/hub.c
+++ usb-2.6/drivers/usb/core/hub.c
@@ -452,18 +452,14 @@ static void hub_power_on(struct usb_hub
msleep(max(pgood_delay, (unsigned) 100));
}
-static inline void __hub_quiesce(struct usb_hub *hub)
+static void hub_quiesce(struct usb_hub *hub)
{
/* (nonblocking) khubd and related activity won't re-trigger */
hub-quiescing = 1;
hub-activating = 0;
hub-resume_root_hub = 0;
-}
-static void hub_quiesce(struct usb_hub *hub)
-{
/* (blocking) stop khubd and related activity */
- __hub_quiesce(hub);
usb_kill_urb(hub-urb);
if (hub-has_indicators)
cancel_delayed_work(hub-leds);
@@ -1895,18 +1891,6 @@ static inline int remote_wakeup(struct u
#endif
-void usb_suspend_root_hub(struct usb_device *hdev)
-{
- struct usb_hub *hub = hdev_to_hub(hdev);
-
- /* This also makes any led blinker stop retriggering. We're called
-* from irq, so the blinker might still be scheduled. Caller promises
-* that the root hub status URB will be canceled.
-*/
- __hub_quiesce(hub);
- mark_quiesced(to_usb_interface(hub-intfdev));
-}
-
void usb_resume_root_hub(struct usb_device *hdev)
{
[linux-usb-devel] [RFC 3/4] USB autosuspend/autoresume
This patch (as741) makes the non-hub parts of usbcore actually use the
autosuspend facilities added by an earlier patch.
Devices opened through usbfs are autoresumed and then
autosuspended upon close.
Likewise for usb-skeleton.
Devices are autoresumed for usb_set_configuration.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Index: usb-2.6/drivers/usb/core/devio.c
===
--- usb-2.6.orig/drivers/usb/core/devio.c
+++ usb-2.6/drivers/usb/core/devio.c
@@ -558,12 +558,13 @@ static int usbdev_open(struct inode *ino
dev = usbdev_lookup_minor(iminor(inode));
if (!dev)
dev = inode-u.generic_ip;
- if (!dev) {
- kfree(ps);
+ if (!dev)
goto out;
- }
+ ret = usb_autoresume_device(dev, 1);
+ if (ret)
+ goto out;
+
usb_get_dev(dev);
- ret = 0;
ps-dev = dev;
ps-file = file;
spin_lock_init(ps-lock);
@@ -581,6 +582,8 @@ static int usbdev_open(struct inode *ino
list_add_tail(ps-list, dev-filelist);
file-private_data = ps;
out:
+ if (ret)
+ kfree(ps);
mutex_unlock(usbfs_mutex);
return ret;
}
@@ -604,6 +607,7 @@ static int usbdev_release(struct inode *
releaseintf(ps, ifnum);
}
destroy_all_async(ps);
+ usb_autosuspend_device(dev, 1);
usb_unlock_device(dev);
usb_put_dev(dev);
kfree(ps);
Index: usb-2.6/drivers/usb/core/generic.c
===
--- usb-2.6.orig/drivers/usb/core/generic.c
+++ usb-2.6/drivers/usb/core/generic.c
@@ -172,14 +172,10 @@ static void generic_disconnect(struct us
/* if this is only an unbind, not a physical disconnect, then
* unconfigure the device */
- if (udev-state == USB_STATE_CONFIGURED)
+ if (udev-actconfig)
usb_set_configuration(udev, 0);
usb_remove_sysfs_dev_files(udev);
-
- /* in case the call failed or the device was suspended */
- if (udev-state = USB_STATE_CONFIGURED)
- usb_disable_device(udev, 0);
}
#ifdef CONFIG_PM
@@ -208,4 +204,5 @@ struct usb_device_driver usb_generic_dri
.suspend = generic_suspend,
.resume = generic_resume,
#endif
+ .supports_autosuspend = 1,
};
Index: usb-2.6/drivers/usb/core/message.c
===
--- usb-2.6.orig/drivers/usb/core/message.c
+++ usb-2.6/drivers/usb/core/message.c
@@ -1381,9 +1381,6 @@ int usb_set_configuration(struct usb_dev
if (cp configuration == 0)
dev_warn(dev-dev, config 0 descriptor??\n);
- if (dev-state == USB_STATE_SUSPENDED)
- return -EHOSTUNREACH;
-
/* Allocate memory for new interfaces before doing anything else,
* so that if we run out then nothing will have changed. */
n = nintf = 0;
@@ -1418,6 +1415,11 @@ free_interfaces:
configuration, -i);
}
+ /* Wake up the device so we can send it the Set-Config request */
+ ret = usb_autoresume_device(dev, 1);
+ if (ret)
+ goto free_interfaces;
+
/* if it's already configured, clear out old state first.
* getting rid of old interfaces means unbinding their drivers.
*/
@@ -1437,6 +1439,7 @@ free_interfaces:
dev-actconfig = cp;
if (!cp) {
usb_set_device_state(dev, USB_STATE_ADDRESS);
+ usb_autosuspend_device(dev, 1);
goto free_interfaces;
}
usb_set_device_state(dev, USB_STATE_CONFIGURED);
@@ -1505,6 +1508,7 @@ free_interfaces:
usb_create_sysfs_intf_files (intf);
}
+ usb_autosuspend_device(dev, 1);
return 0;
}
Index: usb-2.6/drivers/usb/usb-skeleton.c
===
--- usb-2.6.orig/drivers/usb/usb-skeleton.c
+++ usb-2.6/drivers/usb/usb-skeleton.c
@@ -90,6 +90,11 @@ static int skel_open(struct inode *inode
goto exit;
}
+ /* prevent the device from being autosuspended */
+ retval = usb_autopm_get_interface(interface);
+ if (retval)
+ goto exit;
+
/* increment our usage count for the device */
kref_get(dev-kref);
@@ -108,6 +113,12 @@ static int skel_release(struct inode *in
if (dev == NULL)
return -ENODEV;
+ /* allow the device to be autosuspended */
+ mutex_lock(dev-io_mutex);
+ if (dev-interface)
+ usb_autopm_put_interface(dev-interface);
+ mutex_unlock(dev-io_mutex);
+
/* decrement the count on our device */
kref_put(dev-kref, skel_delete);
return 0;
[linux-usb-devel] [RFC 4/4] USB autosuspend/autoresume
This patch (as742) adds autosuspend/autoresume support to the USB hub
driver. The largest aspect of the change is that we no longer need a
special flag for root hubs that want to be resumed. Now every hub is
autoresumed whenever khubd needs to access it.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Index: usb-2.6/drivers/usb/core/hub.c
===
--- usb-2.6.orig/drivers/usb/core/hub.c
+++ usb-2.6/drivers/usb/core/hub.c
@@ -276,6 +276,9 @@ static void kick_khubd(struct usb_hub *h
{
unsigned long flags;
+ /* Suppress autosuspend until khubd runs */
+ to_usb_interface(hub-intfdev)-pm_usage_cnt = 1;
+
spin_lock_irqsave(hub_event_lock, flags);
if (list_empty(hub-event_list)) {
list_add_tail(hub-event_list, hub_event_list);
@@ -457,7 +460,6 @@ static void hub_quiesce(struct usb_hub *
/* (nonblocking) khubd and related activity won't re-trigger */
hub-quiescing = 1;
hub-activating = 0;
- hub-resume_root_hub = 0;
/* (blocking) stop khubd and related activity */
usb_kill_urb(hub-urb);
@@ -473,7 +475,7 @@ static void hub_activate(struct usb_hub
hub-quiescing = 0;
hub-activating = 1;
- hub-resume_root_hub = 0;
+
status = usb_submit_urb(hub-urb, GFP_NOIO);
if (status 0)
dev_err(hub-intfdev, activate -- %d\n, status);
@@ -888,6 +890,7 @@ descriptor_error:
INIT_WORK(hub-leds, led_work, hub);
usb_set_intfdata (intf, hub);
+ intf-needs_remote_wakeup = 1;
if (hdev-speed == USB_SPEED_HIGH)
highspeed_hubs++;
@@ -1833,6 +1836,8 @@ static int hub_suspend(struct usb_interf
}
}
+ dev_dbg(intf-dev, %s\n, __FUNCTION__);
+
/* global suspend of the downstream HC-to-USB interface */
if (!hdev-parent) {
struct usb_bus *bus = hdev-bus;
@@ -1855,10 +1860,12 @@ static int hub_suspend(struct usb_interf
static int hub_resume(struct usb_interface *intf)
{
- struct usb_device *hdev = interface_to_usbdev(intf);
struct usb_hub *hub = usb_get_intfdata (intf);
+ struct usb_device *hdev = hub-hdev;
int status;
+ dev_dbg(intf-dev, %s\n, __FUNCTION__);
+
/* global resume of the downstream HC-to-USB interface */
if (!hdev-parent) {
struct usb_bus *bus = hdev-bus;
@@ -1895,7 +1902,6 @@ void usb_resume_root_hub(struct usb_devi
{
struct usb_hub *hub = hdev_to_hub(hdev);
- hub-resume_root_hub = 1;
kick_khubd(hub);
}
@@ -2518,16 +2524,13 @@ static void hub_events(void)
intf = to_usb_interface(hub-intfdev);
hub_dev = intf-dev;
- i = hub-resume_root_hub;
-
- dev_dbg(hub_dev, state %d ports %d chg %04x evt %04x%s\n,
+ dev_dbg(hub_dev, state %d ports %d chg %04x evt %04x\n,
hdev-state, hub-descriptor
? hub-descriptor-bNbrPorts
: 0,
/* NOTE: expects max 15 ports... */
(u16) hub-change_bits[0],
- (u16) hub-event_bits[0],
- i ? , resume root : );
+ (u16) hub-event_bits[0]);
usb_get_intf(intf);
spin_unlock_irq(hub_event_lock);
@@ -2548,16 +2551,16 @@ static void hub_events(void)
goto loop;
}
- /* Is this is a root hub wanting to reactivate the downstream
-* ports? If so, be sure the interface resumes even if its
-* stub device node was never suspended.
-*/
- if (i)
- usb_autoresume_device(hdev, 0);
+ /* Autoresume */
+ ret = usb_autopm_get_interface(intf);
+ if (ret) {
+ dev_dbg(hub_dev, Can't autoresume: %d\n, ret);
+ goto loop;
+ }
- /* If this is an inactive or suspended hub, do nothing */
+ /* If this is an inactive hub, do nothing */
if (hub-quiescing)
- goto loop;
+ goto loop_autopm;
if (hub-error) {
dev_dbg (hub_dev, resetting for error %d\n,
@@ -2567,7 +2570,7 @@ static void hub_events(void)
if (ret) {
dev_dbg (hub_dev,
error resetting hub: %d\n, ret);
- goto loop;
+ goto loop_autopm;
}
hub-nerrors = 0;
@@ -2695,6 +2698,11 @@ static void
Re: [linux-usb-devel] [PATCH] Add USB to MPC8349 PB platform support
On Jul 14, 2006, at 11:21 AM, Li Yang wrote: On 7/14/06, Kumar Gala [EMAIL PROTECTED] wrote: Nack, my expectation is this is all setup by the boot loader. That's a good wish. ;) However, USB is not required by bootloader. So it is not likely to be initialized there. And if we put it in bootloader, it will be hard to change the mode(MPH/DR), which requires a re-burn of bootloader. It's better that we make sure it's correctly configured here. I disagree. You are coming from this from a board that does everything under the sun. I'd like to avoid having this type of initialization in the kernel. There is a whole additional kitchen sink that could move into the kernel as well. - kumar - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Add USB to MPC8349 PB platform support
On Mon, 2006-07-17 at 14:16 -0500, Kumar Gala wrote: On Jul 14, 2006, at 11:21 AM, Li Yang wrote: On 7/14/06, Kumar Gala [EMAIL PROTECTED] wrote: Nack, my expectation is this is all setup by the boot loader. That's a good wish. ;) However, USB is not required by bootloader. So it is not likely to be initialized there. And if we put it in bootloader, it will be hard to change the mode(MPH/DR), which requires a re-burn of bootloader. It's better that we make sure it's correctly configured here. I disagree. You are coming from this from a board that does everything under the sun. I'd like to avoid having this type of initialization in the kernel. There is a whole additional kitchen sink that could move into the kernel as well. Seems to me that it's far better to have init code in the kernel than firmware. For one example, look at the x86 video card init problem PowerPC Linux has. It's also far easier to fix/deploy Linux code than firmware code, as Li observed, and on top of that it's less work for non-UBoot firmwares in the future. -Hollis - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Add USB to MPC8349 PB platform support
On Jul 17, 2006, at 3:16 PM, Kumar Gala wrote: I disagree. You are coming from this from a board that does everything under the sun. I'd like to avoid having this type of initialization in the kernel. There is a whole additional kitchen sink that could move into the kernel as well. Well, I'm going to have to disagree with your disagreement :-) The kernel should not assume things are properly initialized and rely on the boot rom to do such things. I have several reasons for this. One is that we are always pressed to make embedded systems boot more quickly, and taking time to initialize things in the boot rom just makes that a totally inflexible system design. We don't need to initialize things we don't use, or can postpone until later. Two, it makes us dependent upon a particular boot rom, or boot rom behavior, that not all boards may choose to support. Three, board designs may have external logic that requires a certain start up sequence or control register access that complicates the boot rom in it's ability to share code or implementation. There are more, but I think you see the trend. In my years of doing this kind of development, you can't assume a boot rom is going to do much more than initialize memory and load the kernel. I prefer the flexibility to be in the kernel, and not in the boot rom, because it is so much easier to develop and control. Thanks. -- Dan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Let option driver handle Anydata CDMA modems. Remove anydata driver.
A few days back, I reported that my Anydata ADU-E100A CDMA/EV-DO modem works better with the option driver than with the anydata driver. I now understand better why. Using the option driver fixed a bug which forced me to cycle power between closing a ppp connection and opening it again. It also had better througput than anydata, even with buffer_size=4096 for anydata. The reason that repeated connections work is that option implements TIOCMSET for RTS and DTR, in a way which works for the Anydata modem. I was able to make the anydata driver close and open connections properly by copying the TIOCMSET handler and the necessary state data from the option driver. As another experiment, I added the TIOCMSET handler to the airprime_major_update patch. airprime was now able to handle the Anydata modem and close and open connections properly. option implements TIOCMSET be sending an usb_control_msg with the same request and requesttype as the pl2303 driver uses. Perhaps there is a PL2303 inside these devices. As for throughput, option is best, followed by airprime, anydata with buffer_size=4096 and in last place anydata with default buffers. I've proposed removing the anydata driver and letting the option driver handle Anydata modems. I still stand by the proposal. See Matthias Urlichs's patch from July 12. I've also speculated about whether the airprime and option drivers ought to be merged, but I don't know whether that makes sense. Do the devices which airprime handles also need modem control line handling? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Add USB to MPC8349 PB platform support
On Jul 17, 2006, at 3:17 PM, Dan Malek wrote: On Jul 17, 2006, at 3:16 PM, Kumar Gala wrote: I disagree. You are coming from this from a board that does everything under the sun. I'd like to avoid having this type of initialization in the kernel. There is a whole additional kitchen sink that could move into the kernel as well. Well, I'm going to have to disagree with your disagreement :-) The kernel should not assume things are properly initialized and rely on the boot rom to do such things. I have several reasons for this. One is that we are always pressed to make embedded systems boot more quickly, and taking time to initialize things in the boot rom just makes that a totally inflexible system design. We don't need to initialize things we don't use, or can postpone until later. Two, it makes us dependent upon a particular boot rom, or boot rom behavior, that not all boards may choose to support. Three, board designs may have external logic that requires a certain start up sequence or control register access that complicates the boot rom in it's ability to share code or implementation. Well, I think there is a coupling that exists between whatever your boot rom is and the kernel. If you are trying to optimize boot time I'd say one thing you would want is to avoid multiple writing the same configuration registers. I dont have an issue if a fixed function board decides to do these things in their kernel init instead of their boot rom. I however, don't want thousand and one config options to support all the various ways one can configure the Freescale board. There are more, but I think you see the trend. In my years of doing this kind of development, you can't assume a boot rom is going to do much more than initialize memory and load the kernel. I prefer the flexibility to be in the kernel, and not in the boot rom, because it is so much easier to develop and control. - kumar - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Add USB to MPC8349 PB platform support
On Jul 17, 2006, at 5:39 PM, Kumar Gala wrote: Well, I think there is a coupling that exists between whatever your boot rom is and the kernel. There shouldn't be, I've always said that, but Freescale seems to want to insist on it :-) The problem is people creating this evaluation/demo boards seem to think they are workstations, which they are not. There is such a minimal amount of information needed to actually get a system from the boot rom to the kernel that I don't understand why we are complicating this process for embedded systems. Here is my product development experience. People buy these evaluation boards to test a few of the features they need for a product. These boards try to be everything to everyone, but in reality have never done what someone has wanted very well. Products developed using Linux and many different boot roms are very focused on a particular set of features. Their requirements are nothing like that of an evaluation board, and all of these cute workstation features we are pushing into these evaluation board ports do nothing to help get these products customized for market. If you are trying to optimize boot time I'd say one thing you would want is to avoid multiple writing the same configuration registers. That's what I said. Just do it in Linux when the feature is started, either as a built-in driver or loadable module. No need to do this in a boot rom if there isn't any need for it. I dont have an issue if a fixed function board decides to do these things in their kernel init instead of their boot rom. I however, don't want thousand and one config options to support all the various ways one can configure the Freescale board. I don't understand how configuration options fit into this discussion. In this particular discussion, if you have selected the USB option, then include the proper initialization code in the kernel for the board. No additional options needed. Thanks. -- Dan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Bug with USB proc_bulk in 2.4 kernel
On Mon, 17 Jul 2006 14:35:21 -0700, Benjamin Cherian [EMAIL PROTECTED] wrote: I'm skipping the discussion of the spec, but going further, here's what we have: It is really looking like you are backing me into a corner to make the change myself. However, before doing so I'd like to say that I am disappointed that the kernel developer list has not been more accommodating to this issue. I understand, this is not a good situation. The problem is, it's 2.4. It is upgraded very slowly, if at all. You came around about a year after the fact. At the time, my initial approaches threw similar regressions (with ADSL modems). Of course it's very tempting for me to off-load both the work and the responsibility on you. Besides, the device that is being broken is a 10x CD-ROM drive! Who even uses these anymore? :-) This was my reaction too, when Dell people came knocking. But apparently, that thing is very popular. Also, they backed up their request with a bag of money. In the end, I was glad I did fix that thing. Later, it turned out to be OEM-ed by NEC, Fujitsu, and others; our own QA uses it a lot as well. This happens because the 210PU offers significant savings in power and space in OEM applications, and for casual users, it's a perfect jump drive. It's the same kind of question as, who even uses 2.4 anymore. By the way, did you consider an in-kernel driver? For me, it seems much safer to reimplement the whole thing that way than to monkey with devio again and risk more regressions. Another option would be to change USBDEVFS_BULK to USBDEVFS_SUBMITURB. Did you look at doing that? Yours, -- Pete - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Add USB to MPC8349 PB platform support
On Monday 17 July 2006 1:08 pm, Hollis Blanchard wrote: Seems to me that it's far better to have init code in the kernel than firmware. If there's a general Linux policy on the issue, I think that'd be it. Plus, remember that boot firmware _can't_ always be changed/bugfixed; sometimes it can, but not as a general rule. - Dave For one example, look at the x86 video card init problem PowerPC Linux has. It's also far easier to fix/deploy Linux code than firmware code, as Li observed, and on top of that it's less work for non-UBoot firmwares in the future. -Hollis - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
