On Fri, 16 Dec 2005, Franck wrote: > Hi Alan, > > 2005/12/15, Alan Stern <[EMAIL PROTECTED]>: > > > > No, the bus should already be suspended. In fact, you should fail the > > driver-suspend request if the bus isn't already suspended. > > hmm I think so but I don't see this behaviour in isp116 or sl811 hcds. > The former do actually nothing, even if the bus is not suspended, the > later does a bus_suspend which does nothing.
The last time I looked, isp116x didn't support suspend/resume at all. Maybe Olav has made some changes since then. And it wouldn't be surprising to learn that sl811 is somewhat out-of-date also. > Actually it's hard from > that point to do something usefull since to suspend the bus we need to > suspend all devices connected on it. Well, yes and no. Certainly you want usbcore and all the device drivers to know that everything is suspended. On the other hand, if you physically suspend the bus then all the devices attached to it will also suspend themselves (in the USB specification it's called -- somewhat illogically -- a "global suspend"). > > Likewise, you > > should fail a bus-resume request if the driver is suspended. > > > > How could it happen ?? Users can cause suspend and resume changes by using sysfs. This particular sort of event would probably be caught by the PM core and not passed on to your driver, but best to be safe and check. > OK, I think I get the main idea of suspend/resume process for usb. But > now, I don't see the purpose of hcd->bus_suspend method. What is it > supposed to do since all of its children must be suspended (meaning > that the bus is already suspended) No, that's not what it means. Suspending all the devices attached to a bus is different from suspending the bus itself. > before executing this method ? I > guess I don't see the purpose since I have a host controller with only > one port, no root hub. By definition every host controller, including yours, has a root hub. That one port is the root hub's downstream port. The point of a bus suspend is that the host controller can save power by turning off the circuitry that drives the USB bus. For example, often there's a 48 MHz clock that isn't needed when the bus is suspended. > BTW, I notice a regression. I can not use anymore my usb stick with an > embedded hub, I got the following error message: > """ > usb 1-1: new full speed USB device using vusb-hcd and address 5 > usb 1-1: can't connect bus-powered hub to this port > hub 1-0:1.0: state 5 ports 1 chg 0000 evt 0002 That's not a regression -- it's what should have happened all along! > Here is the device description: > > T: Bus=01 Lev=02 Prnt=06 Port=01 Cnt=01 Dev#= 7 Spd=12 MxCh= 1 > D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > P: Vendor=067b ProdID=2515 Rev= 1.00 > S: Manufacturer=Prolific Technology Inc. > S: Product=USB Embedded Hub > C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=100mA > I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub > E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=12ms > > T: Bus=01 Lev=03 Prnt=07 Port=00 Cnt=01 Dev#= 8 Spd=12 MxCh= 0 > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > P: Vendor=067b ProdID=2517 Rev= 1.00 > S: Manufacturer=Prolific Technology Inc. > S: Product=USB Mass Storage Device > C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 2mA > I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=05 Prot=50 Driver=usb-storage > E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms This says that the embedded hub in your stick needs 100 mA to run. You didn't say how much power is available from your host controller's port, but apparently it only provides 100 mA (otherwise the error message wouldn't have appeared). Since the embedded hub can use all the current provided by the root hub, there's nothing left over to drive the storage device -- not even the measly 2 mA it wants. The amount of power provided by your root hub is reported in hcd->power_budget. If you change that value to be at least 102 then this error should no longer occur. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel