On Thu, 14 May 2015, Petri Gynther wrote: > > The trick here is that hub_irq() and all the stuff beneath it is > > supposed to execute in a tasklet, not in the same context as > > ehci_irq(). Consequently the lock should not be taken recursively. > > > > Perhaps your EHCI platform driver has forgotten to include the HCD_BH > > bit in the .flags member of its hc_driver structure. Which driver are > > you using? Running "grep EHCI" on the kernel config file should > > provide the answer. > > > > Thanks for your reply. The flag HCD_BH was indeed missing from our > driver (echi-brcm, not in upstream), and adding it fixes the problem. That's the problem with maintaining out-of-tree drivers -- they miss out on essential changes to the core parts of the system. I strongly urge you to submit your driver for inclusion in the upstream kernel. > Having said that -- adding HCD_BH effectively masks this recursive > locking problem. Perhaps it is still worth fixing, so that drivers > could operate without HCD_BH? You've got this almost completely backward. It isn't a problem and it doesn't need fixing. By design, the ehci-hcd driver now _requires_ the HCD_BH flag; it cannot operate properly without that flag. Adding HCD_BH doesn't mask anything; rather, omitting HCD_BH creates the problem. Alan Stern -- 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
