Hi,
On 27-02-18 03:29, Brian Norris wrote:
On Thu, Feb 22, 2018 at 11:14 PM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
On 23-02-18 04:12, Brian Norris wrote:
Hmm? I'm not sure I completely follow here when you say "he was not
hitting the firmware loading race". If things were functioning fine with
system suspend (but not with autosuspend), then he's not seeing the
controller (quoting commit fd865802c66b) "losing power during suspend".
He was running a kernel with the original "fd865802c66b Bluetooth: btusb:
fix QCA Rome suspend/resume" commit, which fixes regular suspend for
devices which are "losing power during suspend", but does nothing for
runtime-suspend.
He ran tests both with and without runtime-pm enabled with that same kernel
and he needed to disable runtime-pm to get working bluetooth.
Did he ever test with commit fd865802c66b reverted?
My symptoms were exactly the same as you described. BT was broken as
of v4.14 if I had runtime suspend enabled. Things were fine if I
either (a) reverted the patch or (b) disabled runtime suspend. I
obviously preferred (a), which is why I continued to complain :)
Did your tester ever try (a)? If not, then I don't think you've really
ensured that he really needed a "fixed" version; he may not have
needed the patch at all.
Or an alternative question: did that system work on an older Fedora
release (and presumably an older kernel)? If so, then he probably also
did not need that patch.
So, that would suggest he could only be seeing the race (as I was), and
that his machine does not deserve a RESET_RESUME quirk?
I hope my above answer helps to clarify why I believe the quirk is
necessary on his machine.
I'm sorry, but no it doesn't. If anything, it suggests to me even more
that it may not have been necessary.
Ok, I've started another test-kernel build for the reporter this time
without any quirks at all and I've asked him to test.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
