On Thu, May 14, 2015 at 1:12 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > 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. > Up to Broadcom to upstream their driver. >> 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. > If omitting the flag is a problem, then why does such flag exist? Looks like the flag should be removed altogether and EHCI drivers should be forced to use BH. > 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
