On Wed, Jul 22, 2009 at 10:51:01AM -0400, Alan Stern wrote: > On Tue, 21 Jul 2009, Sarah Sharp wrote: > > > There is a FIXME note in usb_kick_khubd() that it may have problems if the hub > > isn't bound to the hub driver yet. Since the xHCI hardware can send a port > > status change event as soon as the interrupts are turned on, there is a race > > condition between registering khubd and the xHCI host controller driver. > > It should be obvious that this same reasoning applies to other host > controller drivers too, not just xHCI. How do they solve it? > > Answer: They don't. The race condition is already resolved for you by > usbcore, in the very first line of usb_hcd_poll_rh_status. > > Besides, why do you think that usb_kick_khubd() is relevant here? It > doesn't get used anywhere on the pathway changed by the patch. I was seeing some "duplicate file" errors when the character files for the USB device were created. I tried several different fixes at the time, and this change was one of them. > > Solve this by ignoring port status change events until after khubd polls the > > port status bits for the first time. khubd should notice any changes from > > previous events at that time. > > This change isn't needed. Yes, I agree. I tried taking out this patch, and the enumeration sequence seems to go smoothly now. I guess one of the other changes I implemented solved my initial problem. Greg, you can drop this patch. I'll have to resend my debugging patch, since that printed a variable introduced in this patch. Sarah -- 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
