On Thu, 14 May 2015, Petri Gynther wrote: > >> 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? It exists because other (non-EHCI) drivers require the flag to be omitted. > Looks like the flag should be removed altogether and EHCI drivers > should be forced to use BH. Getting rid of the flag would break those non-EHCI drivers. However, I agree with you that EHCI drivers should be forced to use BH. In fact, that's exactly what we did when the BH mechanism was introduced -- we added the flag to every EHCI driver in the kernel. It wasn't our fault that we couldn't modify ehci-brcm (hint, hint). 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
