On Tue, 15 Dec 2009, Yuping Luo wrote: > Dear friends, > It's my first time to post, please feel free to correct me if any concern. > > I have one ARM board with linux version (Linux localhost > 2.6.27-default #3 PREEMPT Thu Dec 10 15:17:44 CST 2009 armv6l > unknown), and the usb device controller used for mass storage. it's > normal if without sleep/wakeup procedure, however, if the procedure > happen and the host is Linux Ubuntu OS, the device can't be > enumerated, it's ok with the host as Window XP since > USB_REQ_CLEAR_FEATURE will be sent to the device. > after adding some debug info in the file_storage.c, and I found > there are several raise_exception() called, but no corresponding > handle_exception() when comparing the plug/unplug usb cable procedure, > so the fsg->state not reset properly. > it' ok if commenting the "if (fsg->state <= new_state) " in > function raise_exception(). but I think it may be not the formal way. g_file_storage doesn't really support system suspend. This is because different systems treat their USB device controllers differently during suspend. You'll probably find it works better if you wake up the ARM board _before_ plugging in the USB cable. > it seem that the fsg_main_thread() rescheduled very late by the system. Yes. But it ends up doing the right thing, doesn't it? You end up in the configured state. You could speed it up by getting rid of the set_freezable() call near the start of fsg_main_thread(), but then you might find there are other problems. For example, the host might want to read data from the backing storage before the backing storage device has been resumed. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
