Hello All, I'm trying to understand the debounce introduced in function hub_activate, in file drivers/usb/core/hub.c. This used to be a very simple function which doesn't do much except submitting an URB to query port status and kicking off hub_thread. (in some early 2.6.27 versions or older) The function became more complicated in recent releases (such as 2.6.29), and the most significant change I noticed is the 100ms debounce for port status change. ------ snip ------ #define HUB_DEBOUNCE_STABLE 100 ...... if (need_debounce_delay) msleep(HUB_DEBOUNCE_STABLE); ------ snip ------ Here are my questions, 1. My understanding is port debounce is done in the hub_thread when there is a connection change detected. In the run time hub_activate gets called when there is a remote wakeup or device detach (there are other cases too, but these are my concern for now). I'm wondering if there is any USB specification or documentation explains the debounce in function hub_activate. If not, is this designed to cover certain use cases? I would like to get some background knowledge about this code. 2. Why is this HUB_DEBOUNCE_STABLE set to 100? Is it set to cover certain worst case? Is it possible for this value to be adjusted from time to time? 3. Is the timing control in this driver mostly considering transceiver/cable connection case? From USB standard perspective, should we follow the same timing control for transceiverless case as well? 4. To be more specific, please allow me to present an issue I'm dealing with. In this system, there is an EHCI controller connected to the device through TLL (12pin ULPI interface). The device could switch mode anytime by disconnect and reconnect to the host controller in a very short time. It used to work with older linux versions before the debounce was introduced into hub_activate function. However, with recent releases, the hub_activate function sees portstatus=0x0100 and portchange=0x0001 which indicates device disconnected, because of this 100ms debounce and the device switch mode very quickly, by the time hub_thread is started, the device reconnect already and the portstatus becomes 0x0501 and portchange=0x0001, the hub_port_connect_change function returns before even calling usb_disconnect, thus enumeration for the second mode doesn't even happen. As I'm not clear about the reasoning behind this debounce in hub_activate function, I don't know if this problem should be fixed from the host driver side or the device side. If this should be fixed on the device side, how do we decide the interval between disconnect and connect, which is directly related to the question #2. Thanks, Fei -- 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
