On 2018-05-07 11:37:29 [-0400], Alan Stern wrote:
> > As far as I understand it there should be no deadlock. Without the
> > local_irq_save() things should not deadlock because the HCD invokes USB
> > driver's (usb-storage for instance) ->complete callback always in the
> > same way. If you mix the usb-driver with two different HCDs (say ehci
> > and xhci) then lockdep would complain. However, the locks which were
> > allocated by usb-storage for the ehci driver would never be used in the
> > context of the xhci driver. So lockdep would report a deacklock but
> > there wouldn't be one (again, if I got the piece right).
>
> That argument would be correct if the completion routines were the only
> places where the higher-level drivers (such as usb-storage or usbhid)
> acquired their locks. But we can't depend on this being true; you
> would have to audit each USB driver to make sure.
an entry point for IRQ usage outside of the driver would be the usage of
hrtimer. We have a flag to let the hrtimer run in softirq but yes, we
need to audit them.
> > And I was thinking about converting all drivers to one model and then we
> > could get rid of the block I quoted above.
> >
> > If nobody rejects the approach as such I would go and start hacking…
> >
> > > And even for those two, the conversion will not be easy. Simply
> > > changing the giveback routines would violate the documented guarantees
> > > for isochronous transfers.
> >
> > The requirement was that the ISO urb is completed before the BULK urb,
> > right?
>
> No, that's not what I meant. For one thing, isochronous URBs don't
> need to complete before bulk URBs in general (although they do have
> higher priority).
>
> However, I was really referring to the kerneldoc for usb_submit_urb().
> The part that talks about scheduling of isochronous and interrupt URBs
> lists a bunch of requirements. In order to meet these requirements
> some of the host controller drivers may rely on the fact that when they
> give back an URB, the URB's completion routine will return before the
> giveback call finishes.
You mean the "Reserved Bandwidth Transfers:" paragraph?
> It's possible to rewrite the HCDs not to rely on this (I did exactly
> that for ehci-hcd), but it is a nontrivial job.
are you referring to commit 9118f9eb4f1e ("USB: EHCI: improve interrupt
qh unlink")?
> Alan Stern
Sebastian
--
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
