On Tue, May 20, 2014 at 11:31 PM, Greg KH <gre...@linuxfoundation.org> wrote: > On Tue, May 20, 2014 at 11:21:03PM -0700, Dan Williams wrote: >> On Tue, May 20, 2014 at 5:27 PM, Greg KH <gre...@linuxfoundation.org> wrote: >> >> Greg, >> >> >> >> Sorry, I don't think it is fair to users to force them to re-compile >> >> their kernel to get their device to work. >> > >> > I totally agree. >> > >> >> Granted, I'm new to USB >> >> development, but the rate of reports of endpoint devices that mess up >> >> and require quirks in the hcd-driver or usb-core seems un-ending to >> >> me. So, I don't think it is fair to expect that the tide of quirky >> >> devices will be stemmed in any reasonable amount of time. Having a >> >> "works with noxhci_port_switch" report from users is good data (hmm, I >> >> think a printk to tell users to file a report upstream if the option >> >> resolves their issue is needed). >> > >> > How about just adding a debugfs file instead? That way, once you fix >> > this, we can then remove it and no one will care. >> >> The only thing stopping me from saying "deal." is that this darn >> things is presently a pci quirk. So it happens well before the user >> has a chance to manually override it with a debugfs file. > > Then have the debugfs file disconnect the device and reconnect it.
We also need to reload the ehci hcd driver since it needs to know its port count at load time as well. Which is more violent and error prone than I think we want. >> Let me look into delaying the quirk until the driver loads, because >> ideally the right interface for this is "blacklist xhci_hcd" in >> /etc/modprobe.conf. > > Which really doesn't work for systems / distros that build the driver > into the kernel. True. I'm back to a kernel command line option as the only viable way forward, but let me try to wordsmith the description to make clear when to use this workaround and the obligation to report upstream when this workaround works so we can queue up the fix for xhci. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
