On Fri, 20 Jul 2018, Mathias Nyman wrote:

> >> But we need to fix this properly as well.
> >> xhci needs to be more in sync with usb core in usb_set_interface(), 
> >> currently xhci
> >> has the altssetting up and running when usb core hasn't event started 
> >> flushing endpoints.
> > 
> > Absolutely.  The core tries to be compatible with host controller
> > drivers that either allocate bandwidth as it is requested or else
> > allocate bandwidth all at once when an altsetting is installed.
> > 
> > xhci-hcd falls into the second category.  However, this approach
> > requires the bandwidth verification for the new altsetting to be
> > performed before the old altsetting has been disabled, and the xHCI
> > hardware can't do this.
> > 
> > We may need to change the core so that the old endpoints are disabled
> > before the bandwidth check is done, instead of after.  Of course, this
> > leads to an awkward situation if the check fails -- we'd probably have
> > to go back and re-install the old altsetting.
> 
> That would help xhci a lot.
> 
> If we want to avoid the awkward altsetting re-install after bandwidth failure
> then adding a extra endpoint flush before checking the bandwidth would 
> already help a lot.
> 
> The endpoint disabling can then be remain after bandwidth checking.
> Does that work for other host controllers?

As far as I know, the other host controller drivers don't really care 
how this is done.  xHCI is the only technology where the hardware has 
to verify the bandwidth requirements.  (Maybe some other SuperSpeed 
controller design also cares, but if so then this change is unlikely to 
hurt.)

Alan Stern

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Reply via email to