On 4/21/24 5:14 PM, quic_zijuhu wrote:
On 4/22/2024 2:41 AM, Krzysztof Kozlowski wrote:
On 21/04/2024 09:44, Wren Turkal wrote:
On 4/20/24 3:06 PM, Zijun Hu wrote:
This patch series are to fix below 2 regression issues for QCA controllers
1) BT can't be enabled once BT was ever enabled for QCA_QCA6390
2) BT can't be enabled after disable then warm reboot for QCA_QCA6390
@Zijun @Krzysztof and @Bartosz Would it be helpful for me to test these
to ensure they fix the issues I reported?
I look forward to someone testing these on other hardware, not yours. On
the hardware where the original issues were happening leading to this
changes, e.g. RB5.
Anyway, the problem here is poor explanation of the problem which did
not improve in v3 and v4. Instead I receive explanations like:
"this is shutdown of serdev and not hdev's shutdown."
Not related...
this is the reply for secondary issue. i believe i have given much
explain for my fix for the 2nd issue as shown by below links.
let me add a bit more explanation within the ending "For the 2nd issue"
section, supposed you known much for generic flag
HCI_QUIRK_NON_PERSISTENT_SETUP, otherwise, see header comment for the
quirk. also supposed you see commit history to find why
qca_serdev_shutdown() was introduced for QCA6390.
https://lore.kernel.org/all/fe1a0e3b-3408-4a33-90e9-d4ffcfc7a99b@xxxxxxxxxxx/
"now. you understood why your merged change as shown link of 4) have
problems and introduced our discussed issue, right?"
this is the reply for the first issue as shown by below link. it almost
have the same description as the following "For 1st issue:" section.
i believe it have clear illustration why the commit have bugs.
https://lore.kernel.org/all/2166fc66-9340-4e8c-8662-17a19a7d8ce6@xxxxxxxxxx/
No. I did not understand and I feel I am wasting here time.
Code could be correct, could be wrong. Especially second patch looks
suspicious. But the way Zijun Hu explains it and the way Zijun Hu
responds is not helping at all.
Sorry, with such replies to review, it is not worth my time.
Best regards,
Krzysztof
Hi luiz,marcel
it is time for me to request you give comments for our discussion
and for my fixes, Let me explain the 1st issue then 2nd one.
For 1st issue:
1) the following commit will cause serious regression issue for QCA
controllers, and it has been merged with linus's mainline kernel.
Commit 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL()
with gpiod_get_optional()").
As the user who originally reported thes issue, I can confirm this. I
was introduced to this regression because I use Fedora Rawhide on my
laptop, which builds and pushes kernels based on mainline very regularly.
Here is my description of the regression: After the reverted change, the
BT hardware in my laptop (qca6390) will only work after a cold boot when
the hardware has only be enabled once by the driver. Once the hardware
is enabled, the process of disabling/re-enabling fails. Also, the
hardware cannot be enabled after a warm boot of the laptop.
Among other things, this makes logging into KDE Plasma break my
bluetooth mouse. The cause of this breakage appears to be that Plasma
disables/re-enables bluetooth hardware upon login.
GNOME operates slightly less badly in that bluetooth stays enabled.
However, if I manually disable the bluetooth via the ui or by restarting
the bluetooth service with systemctl, the mouse fails in the same way as
happens with Plasma.
Once the bluetooth has failed, the only way to fix is a cold boot and
only enable the hardware once. I cannot remove the modules (btqca,
hci_uart, and bluetooth) and re-modprobe them to fix it. I can't restart
the bluetooth service. I can't do both of those things. I haven't found
any way to re-enable the hardware beyond cold boot with bluetooth
service enabled.
If I disable the bluetooth service and cold boot the laptop, there also
appears to be some kind of race condition as not enabling bluetooth
service very soon after loading the hci_uart and btqca modules during
boot puts the system in a state where I can never enable bluetooth. I do
not know what causes this specifically, but my theory is that not
starting the bluetooth service immediately puts the driver in a similar
state as when the service is started immediately. Maybe some kind of
lazy initialization that is forced to happen more quickly when the
bluetooth service is enabled?
Any way, this reversion by itself (which I manually did after a
discussion with Zijun before getting his test patches applying to my
kernel for test). However, this reversion did not get the hardware
working after a warm boot.
2) the regression issue is described by [PATCH v4 1/2] commit message
as following:
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
QCA_QCA6390.
i will verify and confirm if QCA_QCA2066 and QCA_ROME also are impacted.
I can confirm this. Without this change (and with the #1 change), I can
cold boot the laptop and disable/re-enable the hardware as many times as
I want. However, warm booting will not allow the hardware to work. I
believe that a similar problem existed before the 6.8 kernel (if memory
serves), as I had been having issues of this sort for some time. I was
able to reproduce a similar issue as far back as 5.19. I tested that and
every intervening release until 6.8.0. I did not realize that the warm
boot problem was separate from the enable/disable issue until working
with Zijun.
3) let me explain the bug point for commit mentioned by 1), its
commit message and bug change applet are shown below.
The optional variants for the gpiod_get() family of functions return
NULL if the GPIO in question is not associated with this device. They
return ERR_PTR() on any other error. NULL descriptors are graciously
handled by GPIOLIB and can be safely passed to any of the GPIO consumer
interfaces as they will return 0 and act as if the function succeeded.
If one is using the optional variant, then there's no point in checking
for NULL.
qcadev->bt_en = devm_gpiod_get_optional(&serdev->dev, "enable",
GPIOD_OUT_LOW);
- if (IS_ERR_OR_NULL(qcadev->bt_en)) {
+ if (IS_ERR(qcadev->bt_en)) {
dev_warn(&serdev->dev, "failed to acquire enable gpio\n");
power_ctrl_enabled = false;
}
3.1) we only need to discuss how to handle case "qcadev->bt_en ==
NULL" since this is only difference between the commit and BT original
design.
3.2) BT original design are agree with the point of above commit
message that case "qcadev->bt_en == NULL" should not be treated as
error, so BT original design does not do error return for the case and
use dev_warn() instead of dev_err() to give.
3.3) the commit misunderstands BT original design and wrongly think
BT original design take "qcadev->bt_en == NULL" as error case,
so change the following flag power_ctrl_enabled set logic and cause
discussed issue.
For the 2nd issue:
1) the following commit will cause below regression issue for QCA_QCA6390.
Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed
serdev")
2) the regression issue is described by [PATCH v4 2/2] commit message
as following:
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
QCA_QCA6390.
3) qca_serdev_shutdown() is serdev's shutdown and not hdev's shutdown()
it should not and also never get chance to be invoked even if BT is
disabled at above 2) step. qca_serdev_shutdown() need to send the VSC
to reset controller during warm reset phase of above 2) steps.
It was Zijun who realized that #1 and #2 these were two separate but
related issues. He really dug in and found the problem and produced test
patches. It was impressive, and he should be given credit for finding
that these were the issues so quickly.
The only reason I'm involved here is that I am squeaky wheel that
happened to be running Rawhide and got hurt by the kernel. I am a
glorified beta tester who got unlucky, and I was hoping the find help in
the kernel community. Zijun stepped up.
The only other thing that I am wondering about this patch set is if
Zijun or some other party should be listed as the maintainer of the
btqca module and hci_qca.c and btqca.* files so that they can be found
more easily with the get_maintainer.pl script.
wt
--
You're more amazing than you think!
