On Fri, 2 Jun 2006 rasmit.ranjan at wipro.com wrote: > Hi, > I was trying suspend/resume of OHCI based host controller. I > suspend the device interface, device/port and the roothub interface/bus > selectively through sysfs. > According to Power Management sub-system if I resume the roothub > interface the all the downsteam devices( device/port and device > interface) should be resumed. This isn't true at all. Selective resume of a device through sysfs is _not_ expected to change the power state of the device's children. The fact that it does for USB devices is an historical artifact. This behavior will change in the near future. > That means power state file of > roothub,port/device,device interface should be 0. But power state of the > port/device remains 3. > I tried finding out the reasons. I went through the kernel code. > What I found out is, resuming any node is initiated through > usb_generic_device API. In that API first we change the > dev->power.power_state.event = PM_EVENT_ON which is the notification to > PM sub-system that now the device is not in suspended state, it is on > now and the power state file of the node is changed to 0. When I traced > the path for my case i.e. resuming the bus. > Here it goes: > > Usb_generic_resume-->hub_resume-->hcd_bus_resume-->ohci_bus_resume-->fin > ish_device_resume. > > Actually finish_device_resume is called from hub_resume and the > parameter passed to finish_device_resume is the usb_device structure > representing the device connected. Then for all the interfaces of the > device finish_device_resume calls usb_generic_resume. > So it is clear that expect the device all other node`s resume is > initiated from usb_generic_resume and this is the only API which does > dev->power.power_state.event = PM_EVENT_ON. As for device resume this is > not done, its power state remains 3 although the device is actually > resumed. > > Is my understanding correct? It's hard to say, since you mentioned some things that don't matter and left out the big part that _does_ matter: The code in hub_resume that resumes child devices doesn't call usb_generic_resume. > If yes then is it a known issue ? I am > using kernel 2.6.15.4. > So is ther any patch available for this? No. You can write one if you want. Since there will soon be a patch that prevents the hub driver from waking up child devices, your problem probably doesn't matter. Alan Stern
