Re: [PATCH] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux