Hi Greg & Sarah, Would please tell us, what should be approach now? If possible, Sarah, would you please give us the Patch to clear all bits in xhci_reset()? Thanks, Bhavik Kothari > On Mon, Nov 19, 2012 at 6:59 PM, Bhavik Kothari > <bhavik.kothari@xxxxxxxxxxxxxxxx > <mailto:bhavik.kothari@xxxxxxxxxxxxxxxx>> wrote: > > Hi Sarah, > > Please find answers as aligned, > > On Fri, Nov 16, 2012 at 11:36 PM, Sarah Sharp > <sarah.a.sharp@xxxxxxxxxxxxxxx > <mailto:sarah.a.sharp@xxxxxxxxxxxxxxx>> wrote: > > On Fri, Nov 16, 2012 at 10:19:01AM -0500, Alan Stern wrote: > > On Thu, 15 Nov 2012, Greg KH wrote: > > > > > On Wed, Nov 07, 2012 at 06:36:46PM +0530, Bhavik Kothari wrote: > > > > Hi Greg, > > > > > > > > Our host controller sets PRC and CSC bits at the time of > initialization > > > > even though no USB device is attached. At the time of > initialization, > > > > hub_probe() gets called and in-turn it calls hub_activate(). > > > > hub_activate() clears the CSC bit, but PRC bit does not > get cleared (in > > > > linux 3.6.1). hub_events() has functionality to clear the > PRC bit, but > > > > initially there is no events from HUB, so hub_events() may > not clear the > > > > PRC bit. Due to this behavior, when we try to insert a USB > device, > > > > interrupt does not generate (because, earlier, PRC bit was > set and not > > > > cleared) and USB device does not get enumerated. > > Does your host controller wait until the port reset is complete > (and the > PRC or BH reset change bits are set) before clearing CMD_RESET? > > > No, our Host controller does not wait till PRC or BH bit gets set. > However, these bits need to be clear to get an event from the root > hub port. > > > > > > > Below Patch allows to clear PRC bit in hub_activate() > function. So, > > > > above issue gets resolved. > > > > > > > > This patch is currently against a linux 3.6.1 kernel, for > the x86 > > > > architecture. > > > > > > The USB code works on all architectures :) > > > > > > > Let me know in case of any concern. > > > > > > So why do this on all host controllers? Why not just clear > the bit for > > > your devices based on a device id or some other identifier? > What > > > happens if you clear this on a different manufacturer's device? > > > > This bit should never be set at this time, regardless of the > > manufacturer. It's okay to clear it always. > > > > A question remains as to whether more should be done in > xhci-hcd for > > controllers that start out in similar weird states. > > All xHCI host controllers are supposed to issue a port reset on > a host > controller reset. The xHCI driver issues a host reset as part of > initialization. > > As Alan said, I don't think this belongs in hub_activate. > External USB > 3.0 hubs don't automatically reset their ports as part of a hub > reset, > so they should not have their port reset bits set. We shouldn't put > code that is specific for the xHCI roothub in hub_activate. > Instead, we > should clear these bits in xhci_reset. > > Note that this patch is not complete. A hot reset can migrate > to a warm > reset, which would cause the BH reset change bit to be set as > well as > the port reset change bit. xhci_reset needs to clear both bits. > > > hub_activate() has handling to clear the BH bit too. > > > > > Also, I would like to get an ack from Alan on this before I > accept it. > > > > The patch is okay with me. But we should get Sarah's opinion too. > > > > Acked-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx > <mailto:stern@xxxxxxxxxxxxxxxxxxx>> > > Nak until this code moves to xhci_reset. > > Sarah Sharp > > > According to spec, section 4.19.1.2.3 Disconnected (initially host > controller should be in Disconnected), "An xHC implementation may > assert WPR or PR to reflect the associated reset operation if HCRST > is asserted while the port is in the Disconnected state." So, if > hub_activate() clears PR bit, then it may not create any problem. > > Please let us know, what should be the proper approach to clear PR bit. > > Thanks, > Bhavik Kothari -- 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
