Bart,
On 8/1/24 11:37 AM, Wren Turkal wrote:
Bart,
On 8/1/24 1:40 AM, Bartosz Golaszewski wrote:
On Thu, 1 Aug 2024 at 10:36, Wren Turkal <wt@xxxxxxxxxxxxxxxx> wrote:
On 8/1/24 1:09 AM, Bartosz Golaszewski wrote:
On Thu, 1 Aug 2024 at 09:59, Wren Turkal <wt@xxxxxxxxxxxxxxxx> wrote:
Indeed. I don't know why I assumed it must be an ARM laptop. I will
come up with a fix shortly.
I have a question, does this fact have anything to do with the problem
with failing to initialize the QCA6390 BT hardware on my laptop
after a
warm reboot? As I didn't understand the connection to DT in that other
issue, does this fact change anything about how to approach that
issue?
I only ask because that issue still very much exists.
Can you remind me if you had bisected it to a specific offending
commit?
I don't think I was able to fully bisect that one. I was more focused on
the fact that the BT hardware didn't work at all even after a cold boot
in that previous issue.
Zijun suggested a fix in
https://lore.kernel.org/linux-bluetooth/1715866294-1549-1-git-send-
email-quic_zijuhu@xxxxxxxxxxx/.
That fix was landed (mainline commit
88e72239ead9814b886db54fc4ee39ef3c2b8f26) and reverted for regression
(revert part of merge 033771c085c2ed73cb29dd25e1ec8c4b2991cad9).
I do not know how to move that one forward. I was hoping that this
pwrseq work and the fact that this laptop doesn't use DT might be new
facts that make it easier to move forward.
With the fixes from this series the driver should theoretically go
back to the behavior pre-pwrseq on your hardware. Is there a specific
kernel version where it still works?
I know it used to work a long time ago (like when I first got this
laptop years ago). Having said that I do not have specifics on which
kernel versions that actually worked. I do think that Zijun is right
about the reset command being sent to the hardware in the wrong case
causing the problem. His patch did seem to work reliably for me. I am
not sure what the regression was with Zijun's patch. I see references to
use-after-free, so I am assuming that there was some bug in the logic in
a case that doesn't affect my use case.
I forgot to say this. Yes, the behavior with your patch series is as it
was before the pwrseq changes. At this point, the regression should be
considered closed when the bluetooth changed are merged into Linus' tree.
wt
--
You're more amazing than you think!
