On Thursday 08 June 2006 11:52 pm, naveen kumar wrote: > Right now I am tyring to call ehci_hub_suspend call > directly from another module using EXPORT_SYMBOL, but
There are lots of reasons that driver-internal symbols do not get exported. In this case, you really can't guarantee the correct system context for suspending the hub ... if you tried, you would break things. As indeed you seem to report later. > it is suspending all the ports & when I call > ehci_hub_resume , all the ports are resuming.But I > don't know whether it is correct or not. In this case the default "driver works OK" assumption is the right one. Hubs certainly couldn't suspend if any of their ports were still active. > and also after > suspending a port & trying to disconnect and again > connect a device , Wakeon Connect is not working.The > port is still in suspended mode. If you use the driver correctly, rather than poking around with internal APIs, you should have no problems. > Should it be > ehci_hub_suspend (or) usb_suspend_device.If it is > usb_suspend_device , then what is the parameter > "state". If any suspend() method accepts a parameter named "state", it needs to be renamed. A pm_message_t is a ** MESSAGE ** although the original power management APIs passed a target system state. > Is there any standard mechanism in Linux which will > Invoke this above process like suspending.I have > enabled CONFIG_PM & CONFIG_USB_SUSPEND options in the > kernel , but who will invoke suspend. As Alan reported, and purely for debugging purposes, there are some /sys/devices/.../power/state files that can be used to invoke selective suspend. - Dave _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
