linux-kernel - Re: [PATCH 02/10] xhci: 'noxhci_port

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 21 May 2014 10:29:09 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Takashi Iwai <tiwai@...e.de>,
	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	USB list <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	Holger Hans Peter Freyther <holger@...ji-mobile.com>,
	Oliver Neukum <oneukum@...e.de>
Subject: Re: [PATCH 02/10] xhci: 'noxhci_port_switch' kernel parameter

On Tue, May 20, 2014 at 11:31 PM, Greg KH <gregkh@...uxfoundation.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 <gregkh@...uxfoundation.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/