Re: xHCI USB2 link state change issue

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

 



On Fri, Nov 04, 2011 at 01:16:43PM -0400, Alan Stern wrote:
> This means you need to fix up the xhci_hub_status_data() routine.  It 
> must turn root-hub polling on whenever it returns a nonzero status, 
> and turn polling off whenever the status is 0.  Without this extra 
> polling, status-change events can be lost if they occur while other 
> port-status-change bits are set -- then they'll never cause an IRQ.
> 
> Something very similar had to be added to ohci_hub_status_data(),
> because OHCI status-change interrupts are level-driven.  Take a look at 
> the end of that function to get an idea of what I mean.

Ok, thanks, I'll take a look at that.

> > > >  and it will never have the chance to be cleared in the port
> > > > status change event handler.  I think what we need to do is check if the
> > > > PLC bit is set for a USB 2.0 device in the function that clears any
> > > > other port status change bit, and make sure to clear PLC there.
> > > 
> > > You're talking about USB_PORT_STAT_C_PORT_LINK_STATE, right?  This
> > > happens in two places: hub_activate() and hub_events().
> > 
> > But USB_PORT_STAT_C_PORT_LINK_STATE is never exposed to the USB core for
> > USB 2.0 roothubs, since external USB 2.0 hubs don't have that bit.  So
> > it needs to be cleared internally in the xHCI driver.
> 
> Hmmm.  It looks like include/linux/usb/ch11.h also needs to be fixed
> up.  Table 11-17 in the USB-2.0 spec defines port feature numbers only
> up to 22; the remaining entries (23 - 30) must be introduced elsewhere.  
> In addition, some of the port feature #define's in that file are
> duplicates.
> 
> Anyway, once that's done we could add code to handle 
> USB_PORT_STAT_C_PORT_LINK_STATE to the hub driver.

So you don't mind adding code to the hub driver that will only run for
the roothub?  I thought the idea was to treat roothubs exactly like
external hubs, which is why there's that horrible layering abstraction
of khubd submitting URBs that just get passed down to the host
controller driver.  Not that I *mind* the hub driver handling the link
state change for USB 2.0 and USB 3.0 ports...

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