Re: [PATCH v2] Bluetooth: qca: Fix BT enable failure again for QCA6390 after warm reboot

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

 



On 04/06/2024 16:25, Lk Sii wrote:
> 
> 
> On 2024/5/22 00:02, Krzysztof Kozlowski wrote:
>> On 16/05/2024 15:31, Zijun Hu wrote:
>>> Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed
>>> serdev") will cause below regression issue:
>>>
>>> BT can't be enabled after below steps:
>>> cold boot -> enable BT -> disable BT -> warm reboot -> BT enable failure
>>> if property enable-gpios is not configured within DT|ACPI for QCA6390.
>>>
>>> The commit is to fix a use-after-free issue within qca_serdev_shutdown()
>>> by adding condition to avoid the serdev is flushed or wrote after closed
>>> but also introduces this regression issue regarding above steps since the
>>> VSC is not sent to reset controller during warm reboot.
>>>
>>> Fixed by sending the VSC to reset controller within qca_serdev_shutdown()
>>> once BT was ever enabled, and the use-after-free issue is also fixed by
>>> this change since the serdev is still opened before it is flushed or wrote.
>>>
>>> Verified by the reported machine Dell XPS 13 9310 laptop over below two
>>> kernel commits:
>>
>> I don't understand how does it solve my question. I asked you: on which
>> hardware did you, not the reporter, test?
>> It seems Zijun did NOT perform any tests obviously.
> All these tests were performed by reporter Wren with her machine
> "Dell XPS 13 9310 laptop".

Wren != Zijun.

> 
> From previous discussion, it seems she have tested this change
> several times with positive results over different trees with her
> machine. i noticed she given you reply for your questions within
> below v1 discussion link as following:
> 
> Here are v1 discussion link.
> https://lore.kernel.org/linux-bluetooth/d553edef-c1a4-4d52-a892-715549d31ebe@xxxxxxx/T/#m7371df555fd58ba215d0da63055134126a43c460
> 
> Here are Krzysztof's questions.
> "I asked already *two times*:
> 1. On which kernel did you test it?
> 2. On which hardware did you test it?"
> 
> Here are Wren's reply for Krzysztof's questions
> "I thought I had already chimed in with this information. I am using a
> Dell XPS 13 9310. It's the only hardware I have access to. I can say
> that the fix seems to work as advertised in that it fixes the warm boot
> issue I have been experiencing."

I asked Zijun, not Wren. I believe all this is tested or done by
Qualcomm on some other kernel, so that's my question.

That's important because Wren did not test particular scenarios, like
PREEMPT_RT or RB5 hardware, but Zijun is claiming problems are solved.
Maybe indeed solved, but if takes one month and still not answer which
kernel you are using, then I am sure: this was nowhere tested by Zijun
on the hardware and on the kernel the Qualcomm wants it to be.

> 
>>> commit e00fc2700a3f ("Bluetooth: btusb: Fix triggering coredump
>>> implementation for QCA") of bluetooth-next tree.
>>> commit b23d98d46d28 ("Bluetooth: btusb: Fix triggering coredump
>>> implementation for QCA") of linus mainline tree.
>>
>> ? Same commit with different hashes? No, it looks like you are working
>> on some downstream tree with cherry picks.
>>
> From Zijun's commit message, for the same commit, it seems
> bluetooth-next tree has different hashes as linus tree.
> not sure if this scenario is normal during some time window.
>> No, test it on mainline and answer finally, after *five* tries, which
>> kernel and which hardware did you use for testing this.
>>
>>
> it seems there are two issues mentioned with Zijun's commit message.
> regression issue A:  BT enable failure after warm reboot.
> issue B:  use-after-free issue, namely, kernel crash.
> 
> @Krzysztof
> which issue to test based on your concerns with mainline tree?

No one tested this on non-laptop platform. Wren did not, which is fine.
Qualcomm should, but since they avoid any talks about it for so long
(plus pushy comments during review, re-spinning v1 suggesting entire
discussion is gone), I do not trust their statements at all.

So really, did anything test it on any Qualcomm embedded platform?
Anyone tested the actual race visible with PREEMPT_RT?

Why Zijun cannot provide answer on which kernel was it tested? Why the
hardware cannot be mentioned?

Best regards,
Krzysztof





[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux