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

Reply via email to