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".
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...
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."
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?
Best regards, Krzysztof