Re: [PATCH] Patch for clearing PRC bit in PORTSC register at the time of XHCI driver insertion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

> > > 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.

> > 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>

Nak until this code moves to xhci_reset.

Sarah Sharp
--
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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux