> On Fri, 10 Feb 2006, Jon Sjöstedt wrote: > >> > Suspend isn't a command. >> > It's more like a lack of a command (more >> > accurately, the lack of any signals on the bus). It can be caused by >> > unloading a host controller driver >> Including the *hci in the kernel can prevent this? > > Yes. Unless the user reboots. > >> > or by the user explicitly requesting a >> > suspend (via sysfs or by putting the whole system into standby or >> suspend >> > mode). >> This should defenately be possible to prevent > > Yes, if you remove Power Management from the kernel configuration. > >> > Resumes occur when the user wakens the whole system from standby or >> > suspend mode or explicitly requests a resume via sysfs. >> > >> > In the future, some USB drivers may automatically suspend their >> devices >> > after some period of inactivity and automatically resume them when >> they >> > are needed. >> > >> >> Is there a way to guarantee that suspend-commands are not sent, or >> are >> >> there any states in the kernel when one can guarantee that they are >> not >> >> sent? >> > >> > There is no way to prevent USB suspends from occurring. >> AFAIK, it is possible to disable USB suspend/resume in the kernel >> configuration. Wouldnt this stop a suspend to occour? > > Are you talking about the CONFIG_USB_SUSPEND setting? The prevents > individual USB devices from being suspended but it doesn't prevent an > entire USB bus from being suspended. (Removing CONFIG_PM does prevent all > such suspends.) > > You would also have to remove CONFIG_USB_DEVICEFS to prevent users from > sending suspend requests directly to the hardware. > > Why are you so concerned about preventing suspends and resumes? They are > part of the USB specification; if your device doesn't support them then it > isn't compliant with the spec. The gadget i question is constructed using several FTDI FT2232L, a USB to dual UART chip. The system where the gadget is intended to be used is a gambling machine based on a PC running Linux. The UARTs mustbe able to pickup a transmission at any point in time. If the FT2232L is in suspend mode, the transmission must be buffered until the remote wakeup from FT2232L has made the USB bus ready again. Kind of. Guess that the description lack some details. Ask
The ugly solutiuon to this problem is to get rid of any suspend, if possible. The better solution is, of course, to accept suspend/resume, but with some extra work to be sure that the system works during suspend/resume. So far i dont have enough detailed info on how the usb-core and the FT2232L linux-driver handles suspend/resume. Hopefully I can acquire enough info implement the nice solution. Datasheet for FT2232L http://www.ftdichip.com/Documents/DataSheets/ds2232l_15.pdf > > Alan Stern > > <--------------------------------------------> Jon Sjöstedt _O_ Godvädersgatan 52 /(|)\ 418 38 GÖTEBORG | H | -OOO-[-+X+-]-OOO- 031 - 49 33 78 ( ) 070 - 435 06 33 _| |_ [EMAIL PROTECTED] [EMAIL PROTECTED] ------------------------------------------------------- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
