HI,
On 16-02-18 18:59, Brian Norris wrote:
Hi,
On Fri, Feb 16, 2018 at 01:10:20PM +0100, Hans de Goede wrote:
On 16-02-18 12:45, Marcel Holtmann wrote:
<snip>
actually if this is really platform related as Qualcomm is indicating, then we should just go with 3) and the two platforms that previously added quirks to usb/core/quirks.c and blacklist these. I am all for figuring out what is going on here. So lets blacklist these and see how this goes. Maybe there are only two bad platforms out there and we are making too much fuzz about this. Before we added quirks in the USB core these platforms were just plain broken as well. So not much different situation than before. We need to push the DMI blacklisting back into -stable as well and that means any impact of a 3rd broken platform briefly working and then be broken again is slim and also fixable via -stable.
Ok, I've asked the reporter of:
https://bugzilla.redhat.com/show_bug.cgi?id=1514836
Are you even sure that this reporter is seeing the original symptom at
all (BT loses power, and therefore firmware)? Their report shows them
running 4.15, which had this commit:
fd865802c66b Bluetooth: btusb: fix QCA Rome suspend/resume
which is admittedly completely broken. It breaks even perfectly working
BT/USB devices, like mine. That's where I first complained, and we got
this into 4.16-rc1:
7d06d5895c15 Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"
Isn't it possible your reporter has no further problem, and none if this
is actually important to them? I'd just caution you to be careful before
assuming you need to add blacklist info for their DMI...
Thanks, that is a good question. His problems only started when I
enabled usb-autosuspend by default for btusb devices and he got things
working by adding "btusb.enable_autosuspend=n" on the kernel commandline,
so he was not hitting the firmware loading race introduced by
fd865802c66b and runtime suspend/resume is really broken for him.
As I read it, you need to investigate who are the "numerous reported
instances" that generated commit fd865802c66b in the first place. That's
where this mess started, IIUC. >
But otherwise, yes, option 3 sounds OK. FWIW, my systems are ARM based
and don't have DMI data, so option 2 wouldn't work.
Right I think we all agree that the new plan now is to go back to
QCA behaving normally wrt (runtime) suspend/resume and then set the
USB-core RESET_RESUME quirk (which does not have the firmware
loading race) based on a DMI blacklist.
I only have the one report for which I will write a patch implementing
this new policy soonish. And Kai-Heng Feng has another report which
might even be the machine. I certainly would not be surprised if it
is another Lenovo machine.
Regards,
Hans