* [PATCH v1 0/2] Fix two regression issues for QCA controllers @ 2024-04-18 14:06 Zijun Hu 2024-04-18 14:06 ` [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" Zijun Hu ` (3 more replies) 0 siblings, 4 replies; 75+ messages in thread From: Zijun Hu @ 2024-04-18 14:06 UTC (permalink / raw) To: luiz.dentz, luiz.von.dentz, marcel Cc: quic_zijuhu, linux-bluetooth, wt, bartosz.golaszewski, krzysztof.kozlowski From: Zijun Hu <zijuhu@qti.qualcomm.com> This patch series are to fix below 2 regression issues for QCA controllers 1) BT can't be enabled once BT is disabled for several QCA controllers 2) BT can't be enabled after disable then warm reboot for QCA_QCA6390 the links for these issues are shown below: https://bugzilla.kernel.org/show_bug.cgi?id=218726 https://lore.kernel.org/linux-bluetooth/ea20bb9b-6b60-47fc-ae42-5eed918ad7b4@quicinc.com/T/#m73d6a71d2f454bb03588c66f3ef7912274d37c6f Zijun Hu (2): Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot drivers/bluetooth/hci_qca.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) -- 2.7.4 ^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" 2024-04-18 14:06 [PATCH v1 0/2] Fix two regression issues for QCA controllers Zijun Hu @ 2024-04-18 14:06 ` Zijun Hu 2024-04-18 14:31 ` Fix two regression issues for QCA controllers bluez.test.bot ` (2 more replies) 2024-04-18 14:06 ` [PATCH v1 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot Zijun Hu ` (2 subsequent siblings) 3 siblings, 3 replies; 75+ messages in thread From: Zijun Hu @ 2024-04-18 14:06 UTC (permalink / raw) To: luiz.dentz, luiz.von.dentz, marcel Cc: quic_zijuhu, linux-bluetooth, wt, bartosz.golaszewski, krzysztof.kozlowski This reverts commit 56d074d26c5828773b00b2185dd7e1d08273b8e8. Commit 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()") will cause serious regression issue for several QCA controllers such as QCA_WCN6750,QCA_WCN6855,QCA_ROME, QCA_QCA6390 and QCA_QCA2066, the regression issue is that BT can't be enabled any more once BT is disabled if BT reset pin is not configured by DT or ACPI. if BT reset pin is not configured, devm_gpiod_get_optional() will return NULL, and we should NOT set quirk HCI_QUIRK_NON_PERSISTENT_SETUP, but the reverted commit SET the quirk since NULL is not a error case, and cause qca_setup() call failure triggered by the 2nd and later BT enable operations since there are no available BT reset pin to clear BT firmware downloaded by the 1st enable operation, fixed by reverting the commit. Fixes: 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()") Reported-by: Wren Turkal <wt@penguintechs.org> Link: https://bugzilla.kernel.org/show_bug.cgi?id=218726 Link: https://lore.kernel.org/linux-bluetooth/ea20bb9b-6b60-47fc-ae42-5eed918ad7b4@quicinc.com/T/#m73d6a71d2f454bb03588c66f3ef7912274d37c6f Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Tested-by: Wren Turkal <wt@penguintechs.org> --- drivers/bluetooth/hci_qca.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index 92fa20f5ac7d..160175a23a49 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -2323,7 +2323,7 @@ static int qca_serdev_probe(struct serdev_device *serdev) qcadev->bt_en = devm_gpiod_get_optional(&serdev->dev, "enable", GPIOD_OUT_LOW); - if (IS_ERR(qcadev->bt_en) && + if (IS_ERR_OR_NULL(qcadev->bt_en) && (data->soc_type == QCA_WCN6750 || data->soc_type == QCA_WCN6855)) { dev_err(&serdev->dev, "failed to acquire BT_EN gpio\n"); @@ -2332,7 +2332,7 @@ static int qca_serdev_probe(struct serdev_device *serdev) qcadev->sw_ctrl = devm_gpiod_get_optional(&serdev->dev, "swctrl", GPIOD_IN); - if (IS_ERR(qcadev->sw_ctrl) && + if (IS_ERR_OR_NULL(qcadev->sw_ctrl) && (data->soc_type == QCA_WCN6750 || data->soc_type == QCA_WCN6855 || data->soc_type == QCA_WCN7850)) @@ -2354,7 +2354,7 @@ static int qca_serdev_probe(struct serdev_device *serdev) default: qcadev->bt_en = devm_gpiod_get_optional(&serdev->dev, "enable", GPIOD_OUT_LOW); - if (IS_ERR(qcadev->bt_en)) { + if (IS_ERR_OR_NULL(qcadev->bt_en)) { dev_warn(&serdev->dev, "failed to acquire enable gpio\n"); power_ctrl_enabled = false; } -- 2.7.4 ^ permalink raw reply related [flat|nested] 75+ messages in thread
* RE: Fix two regression issues for QCA controllers 2024-04-18 14:06 ` [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" Zijun Hu @ 2024-04-18 14:31 ` bluez.test.bot 2024-04-18 16:52 ` [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" Krzysztof Kozlowski 2024-04-18 17:00 ` Bartosz Golaszewski 2 siblings, 0 replies; 75+ messages in thread From: bluez.test.bot @ 2024-04-18 14:31 UTC (permalink / raw) To: linux-bluetooth, quic_zijuhu [-- Attachment #1: Type: text/plain, Size: 4845 bytes --] This is automated email and please do not reply to this email! Dear submitter, Thank you for submitting the patches to the linux bluetooth mailing list. This is a CI test results with your patch series: PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=845820 ---Test result--- Test Summary: CheckPatch FAIL 1.62 seconds GitLint FAIL 0.85 seconds SubjectPrefix PASS 0.22 seconds BuildKernel PASS 32.12 seconds CheckAllWarning PASS 34.76 seconds CheckSparse PASS 40.27 seconds CheckSmatch FAIL 36.68 seconds BuildKernel32 PASS 30.14 seconds TestRunnerSetup PASS 524.15 seconds TestRunner_l2cap-tester PASS 18.69 seconds TestRunner_iso-tester PASS 33.55 seconds TestRunner_bnep-tester PASS 4.80 seconds TestRunner_mgmt-tester FAIL 110.36 seconds TestRunner_rfcomm-tester PASS 7.27 seconds TestRunner_sco-tester PASS 14.96 seconds TestRunner_ioctl-tester PASS 7.61 seconds TestRunner_mesh-tester PASS 5.76 seconds TestRunner_smp-tester PASS 7.22 seconds TestRunner_userchan-tester PASS 4.91 seconds IncrementalBuild PASS 33.90 seconds Details ############################## Test: CheckPatch - FAIL Desc: Run checkpatch.pl script Output: [v1,1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" WARNING: Reported-by: should be immediately followed by Closes: with a URL to the report #116: Reported-by: Wren Turkal <wt@penguintechs.org> Link: https://bugzilla.kernel.org/show_bug.cgi?id=218726 total: 0 errors, 1 warnings, 24 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. /github/workspace/src/src/13634834.patch has style problems, please review. NOTE: Ignored message types: UNKNOWN_COMMIT_ID NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. ############################## Test: GitLint - FAIL Desc: Run gitlint Output: [v1,1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search 1: T1 Title exceeds max length (90>80): "[v1,1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()"" 21: B1 Line exceeds max length (139>80): "Link: https://lore.kernel.org/linux-bluetooth/ea20bb9b-6b60-47fc-ae42-5eed918ad7b4@quicinc.com/T/#m73d6a71d2f454bb03588c66f3ef7912274d37c6f" [v1,2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search 1: T1 Title exceeds max length (93>80): "[v1,2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot" ############################## Test: CheckSmatch - FAIL Desc: Run smatch tool with source Output: Segmentation fault (core dumped) make[4]: *** [scripts/Makefile.build:244: net/bluetooth/hci_core.o] Error 139 make[4]: *** Deleting file 'net/bluetooth/hci_core.o' make[3]: *** [scripts/Makefile.build:485: net/bluetooth] Error 2 make[2]: *** [scripts/Makefile.build:485: net] Error 2 make[2]: *** Waiting for unfinished jobs.... Segmentation fault (core dumped) make[4]: *** [scripts/Makefile.build:244: drivers/bluetooth/bcm203x.o] Error 139 make[4]: *** Deleting file 'drivers/bluetooth/bcm203x.o' make[4]: *** Waiting for unfinished jobs.... make[3]: *** [scripts/Makefile.build:485: drivers/bluetooth] Error 2 make[2]: *** [scripts/Makefile.build:485: drivers] Error 2 make[1]: *** [/github/workspace/src/src/Makefile:1919: .] Error 2 make: *** [Makefile:240: __sub-make] Error 2 ############################## Test: TestRunner_mgmt-tester - FAIL Desc: Run mgmt-tester with test-runner Output: Total: 492, Passed: 489 (99.4%), Failed: 1, Not Run: 2 Failed Test Cases LL Privacy - Add Device 7 (AL is full) Failed 0.189 seconds --- Regards, Linux Bluetooth ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" 2024-04-18 14:06 ` [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" Zijun Hu 2024-04-18 14:31 ` Fix two regression issues for QCA controllers bluez.test.bot @ 2024-04-18 16:52 ` Krzysztof Kozlowski 2024-04-18 21:16 ` quic_zijuhu 2024-04-18 17:00 ` Bartosz Golaszewski 2 siblings, 1 reply; 75+ messages in thread From: Krzysztof Kozlowski @ 2024-04-18 16:52 UTC (permalink / raw) To: Zijun Hu, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, wt, bartosz.golaszewski On 18/04/2024 16:06, Zijun Hu wrote: > This reverts commit 56d074d26c5828773b00b2185dd7e1d08273b8e8. > > Commit 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() > with gpiod_get_optional()") will cause serious regression issue for > several QCA controllers such as QCA_WCN6750,QCA_WCN6855,QCA_ROME, The pin is required on 6750, 6855 and maybe others. You cannot not have the GPIO. This is no correct fix. You provide wrong DTS and, instead fixing it, try to revert kernel code. No, fix your DTS first. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" 2024-04-18 16:52 ` [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" Krzysztof Kozlowski @ 2024-04-18 21:16 ` quic_zijuhu 2024-04-18 22:37 ` Krzysztof Kozlowski 0 siblings, 1 reply; 75+ messages in thread From: quic_zijuhu @ 2024-04-18 21:16 UTC (permalink / raw) To: Krzysztof Kozlowski, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, wt, bartosz.golaszewski On 4/19/2024 12:52 AM, Krzysztof Kozlowski wrote: > On 18/04/2024 16:06, Zijun Hu wrote: >> This reverts commit 56d074d26c5828773b00b2185dd7e1d08273b8e8. >> >> Commit 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() >> with gpiod_get_optional()") will cause serious regression issue for >> several QCA controllers such as QCA_WCN6750,QCA_WCN6855,QCA_ROME, > > The pin is required on 6750, 6855 and maybe others. You cannot not have > the GPIO. > > This is no correct fix. You provide wrong DTS and, instead fixing it, > try to revert kernel code. > > No, fix your DTS first. > no. your point is not right. 1) do you have any evidence that the hci_qca driver must use reset GPIO? 2) why does original design do error return when get GPIO error if GPIO is mandatory? 3) i meet many customer cases that BT are working fine without hci_qca operating the GPIO, there is why HCI_QUIRK_NON_PERSISTENT_SETUP are introduced. 4) does the reverted change solve the issue your mentioned ? > Best regards, > Krzysztof > ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" 2024-04-18 21:16 ` quic_zijuhu @ 2024-04-18 22:37 ` Krzysztof Kozlowski 2024-04-18 23:17 ` quic_zijuhu 0 siblings, 1 reply; 75+ messages in thread From: Krzysztof Kozlowski @ 2024-04-18 22:37 UTC (permalink / raw) To: quic_zijuhu, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, wt, bartosz.golaszewski On 18/04/2024 23:16, quic_zijuhu wrote: > On 4/19/2024 12:52 AM, Krzysztof Kozlowski wrote: >> On 18/04/2024 16:06, Zijun Hu wrote: >>> This reverts commit 56d074d26c5828773b00b2185dd7e1d08273b8e8. >>> >>> Commit 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() >>> with gpiod_get_optional()") will cause serious regression issue for >>> several QCA controllers such as QCA_WCN6750,QCA_WCN6855,QCA_ROME, >> >> The pin is required on 6750, 6855 and maybe others. You cannot not have >> the GPIO. >> >> This is no correct fix. You provide wrong DTS and, instead fixing it, >> try to revert kernel code. >> >> No, fix your DTS first. >> > no. your point is not right. > > 1) do you have any evidence that the hci_qca driver must use reset GPIO? I think we talk here about enable-gpios, right? Then the evidence are bindings. > 2) why does original design do error return when get GPIO error if GPIO is mandatory? If GPIO is mandatory, then it is expected to return error. What is the problem here? > 3) i meet many customer cases that BT are working fine without hci_qca operating the GPIO, > there is why HCI_QUIRK_NON_PERSISTENT_SETUP are introduced. Bindings tell different story and nothing in the commit msg explained this. You did not correct bindings either. > 4) does the reverted change solve the issue your mentioned ? ??? I did not mention any issue. I am saying that your rationale is either not complete or not correct. Specifically, the enable-gpios ARE currently required, so whatever you claim here is not correct till they are required. Make them optional and then your arguments could have sense. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" 2024-04-18 22:37 ` Krzysztof Kozlowski @ 2024-04-18 23:17 ` quic_zijuhu 2024-04-19 13:49 ` Krzysztof Kozlowski 0 siblings, 1 reply; 75+ messages in thread From: quic_zijuhu @ 2024-04-18 23:17 UTC (permalink / raw) To: Krzysztof Kozlowski, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, wt, bartosz.golaszewski On 4/19/2024 6:37 AM, Krzysztof Kozlowski wrote: > On 18/04/2024 23:16, quic_zijuhu wrote: >> On 4/19/2024 12:52 AM, Krzysztof Kozlowski wrote: >>> On 18/04/2024 16:06, Zijun Hu wrote: >>>> This reverts commit 56d074d26c5828773b00b2185dd7e1d08273b8e8. >>>> >>>> Commit 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() >>>> with gpiod_get_optional()") will cause serious regression issue for >>>> several QCA controllers such as QCA_WCN6750,QCA_WCN6855,QCA_ROME, >>> >>> The pin is required on 6750, 6855 and maybe others. You cannot not have >>> the GPIO. >>> >>> This is no correct fix. You provide wrong DTS and, instead fixing it, >>> try to revert kernel code. >>> >>> No, fix your DTS first. >>> >> no. your point is not right. >> >> 1) do you have any evidence that the hci_qca driver must use reset GPIO? > > I think we talk here about enable-gpios, right? Then the evidence are > bindings. > yes. properties within bindings only means driver supporting it, don't means user must config it. the gpio is got by devm_gpiod_get_optional() variant. that means it is optional about if user need to config it. >> 2) why does original design do error return when get GPIO error if GPIO is mandatory? > > If GPIO is mandatory, then it is expected to return error. What is the > problem here? > sorry, i miss a NOT for my question. my question is that 2) why does original design NOT do error return when get GPIO error if GPIO is mandatory? > >> 3) i meet many customer cases that BT are working fine without hci_qca operating the GPIO, >> there is why HCI_QUIRK_NON_PERSISTENT_SETUP are introduced. > > Bindings tell different story and nothing in the commit msg explained > this. You did not correct bindings either. > don't need to correct bindings. i believe bindings does not say enable gpio must be configured. > >> 4) does the reverted change solve the issue your mentioned ? > > ??? I did not mention any issue. I am saying that your rationale is > either not complete or not correct. > do you suggest about how to make it complete? > Specifically, the enable-gpios ARE currently required, so whatever you > claim here is not correct till they are required. Make them optional and > then your arguments could have sense. > > Best regards, > Krzysztof > ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" 2024-04-18 23:17 ` quic_zijuhu @ 2024-04-19 13:49 ` Krzysztof Kozlowski 2024-04-20 5:25 ` quic_zijuhu 0 siblings, 1 reply; 75+ messages in thread From: Krzysztof Kozlowski @ 2024-04-19 13:49 UTC (permalink / raw) To: quic_zijuhu, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, wt, bartosz.golaszewski On 19/04/2024 01:17, quic_zijuhu wrote: > On 4/19/2024 6:37 AM, Krzysztof Kozlowski wrote: >> On 18/04/2024 23:16, quic_zijuhu wrote: >>> On 4/19/2024 12:52 AM, Krzysztof Kozlowski wrote: >>>> On 18/04/2024 16:06, Zijun Hu wrote: >>>>> This reverts commit 56d074d26c5828773b00b2185dd7e1d08273b8e8. >>>>> >>>>> Commit 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() >>>>> with gpiod_get_optional()") will cause serious regression issue for >>>>> several QCA controllers such as QCA_WCN6750,QCA_WCN6855,QCA_ROME, >>>> >>>> The pin is required on 6750, 6855 and maybe others. You cannot not have >>>> the GPIO. >>>> >>>> This is no correct fix. You provide wrong DTS and, instead fixing it, >>>> try to revert kernel code. >>>> >>>> No, fix your DTS first. >>>> >>> no. your point is not right. >>> >>> 1) do you have any evidence that the hci_qca driver must use reset GPIO? >> >> I think we talk here about enable-gpios, right? Then the evidence are >> bindings. >> > yes. properties within bindings only means driver supporting it, don't means user must > config it. the gpio is got by devm_gpiod_get_optional() variant. that means it is optional > about if user need to config it. No. Read writing bindings and other presentations explaining what are Devicetree bindings. You miss entirely the point and use downstream narrative. This won't work and it was told so many times, that I expect you to do the homework first. Use "go/upstream" before posting more on this topic. >>> 2) why does original design do error return when get GPIO error if GPIO is mandatory? >> >> If GPIO is mandatory, then it is expected to return error. What is the >> problem here? >> > sorry, i miss a NOT for my question. my question is that > 2) why does original design NOT do error return when get GPIO error if GPIO is mandatory? >> >>> 3) i meet many customer cases that BT are working fine without hci_qca operating the GPIO, >>> there is why HCI_QUIRK_NON_PERSISTENT_SETUP are introduced. >> >> Bindings tell different story and nothing in the commit msg explained >> this. You did not correct bindings either. >> > don't need to correct bindings. i believe bindings does not say enable gpio > must be configured. They say. Read the bindings. Test your DTS. Or better: upstream your DTS and prove to us that dtbs_check allows lack of enable-gpios. >> >>> 4) does the reverted change solve the issue your mentioned ? >> >> ??? I did not mention any issue. I am saying that your rationale is >> either not complete or not correct. >> > do you suggest about how to make it complete? Yes, read what are bindings and then describe your change including that: what is the issue, how it can be reproduced, what is the hardware, why the bindings are not correct (if they are not correct) etc. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" 2024-04-19 13:49 ` Krzysztof Kozlowski @ 2024-04-20 5:25 ` quic_zijuhu 2024-04-20 5:27 ` quic_zijuhu 2024-04-20 11:13 ` Krzysztof Kozlowski 0 siblings, 2 replies; 75+ messages in thread From: quic_zijuhu @ 2024-04-20 5:25 UTC (permalink / raw) To: Krzysztof Kozlowski, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, wt, bartosz.golaszewski, ,kernel On 4/19/2024 9:49 PM, Krzysztof Kozlowski wrote: Hi Krzysztof,bartosz, let me summarize our discussion here in order to reduce unneccessary disagreements here. 1) i only revert your change IS_ERR() to my change IS_ERR_OR_NULL. 2) your change will cause serious regression issues for many lunched products 3) we only need to discuss how to handle devm_gpiod_get_optional(..., "enable", ...) returning NULL since this is only difference between your change and mine. 4) your change doesn't solve any actual issue and the reason you submitted is that "The optional variants for the gpiod_get() family of functions return NULL if the GPIO in question is not associated with this device, and should not treat it as error". code applet of your merged change is shown by below link https://patchwork.kernel.org/project/bluetooth/patch/20240208164017.26699-1-brgl@bgdev.pl/#25705104 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; } 5) Original BT driver design agree with your point mentioned at 4), so for case "qcadev->bt_en == nullptr", qca_serdev_probe() don't do error return for this scenario and use dev_warn() instead of dev_err() to give user prompt. 6) your wrong fix changes flag power_ctrl_enabled set logic and will cause serious BT regression issue, hope you will realize this point. i would like to give below extra comments even if these comments are irrelevant to the critical point of this issue mentioned at above 3) A) you need to investigate it is a) the prompting approach or message error or b) the if condition error even if if dev_err() is used to give prompt instead of dev_warn() in above 4). B) don't talk about how about devm_gpiod_get_optional() returning error case since it is meaningless as explained by above 3). also don't require a fix to fix another unreported issue. a fix is a good fix if it fix the issue in question and don't introduce new issue. C) per DTS property enable-gpios of BT, different soc types have different requirements, many are required and another many are NOT mandatory as shown be below link. https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml. for a soc type which are attached to 3rd platform, customer doesn't would like to or are not able to congfig BT reset pin within DTS for QCA driver even if QC strongly suggest customer config it and also be marked as required within above DTS bindings spec link. i often meet this scenario. there are many of such lunched products. i will try to fix this issue due your change product by product in new patch thread based on this DTS comment. D) you maybe ping me offline about this issue if you are a member of QC since you known "go/upstream" > On 19/04/2024 01:17, quic_zijuhu wrote: >> On 4/19/2024 6:37 AM, Krzysztof Kozlowski wrote: >>> On 18/04/2024 23:16, quic_zijuhu wrote: >>>> On 4/19/2024 12:52 AM, Krzysztof Kozlowski wrote: >>>>> On 18/04/2024 16:06, Zijun Hu wrote: >>>>>> This reverts commit 56d074d26c5828773b00b2185dd7e1d08273b8e8. >>>>>> >>>>>> Commit 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() >>>>>> with gpiod_get_optional()") will cause serious regression issue for >>>>>> several QCA controllers such as QCA_WCN6750,QCA_WCN6855,QCA_ROME, >>>>> >>>>> The pin is required on 6750, 6855 and maybe others. You cannot not have >>>>> the GPIO. >>>>> >>>>> This is no correct fix. You provide wrong DTS and, instead fixing it, >>>>> try to revert kernel code. >>>>> >>>>> No, fix your DTS first. >>>>> >>>> no. your point is not right. >>>> >>>> 1) do you have any evidence that the hci_qca driver must use reset GPIO? >>> >>> I think we talk here about enable-gpios, right? Then the evidence are >>> bindings. >>> >> yes. properties within bindings only means driver supporting it, don't means user must >> config it. the gpio is got by devm_gpiod_get_optional() variant. that means it is optional >> about if user need to config it. > > No. Read writing bindings and other presentations explaining what are > Devicetree bindings. > > You miss entirely the point and use downstream narrative. This won't > work and it was told so many times, that I expect you to do the homework > first. > > Use "go/upstream" before posting more on this topic. > > >>>> 2) why does original design do error return when get GPIO error if GPIO is mandatory? >>> >>> If GPIO is mandatory, then it is expected to return error. What is the >>> problem here? >>> >> sorry, i miss a NOT for my question. my question is that >> 2) why does original design NOT do error return when get GPIO error if GPIO is mandatory? >>> >>>> 3) i meet many customer cases that BT are working fine without hci_qca operating the GPIO, >>>> there is why HCI_QUIRK_NON_PERSISTENT_SETUP are introduced. >>> >>> Bindings tell different story and nothing in the commit msg explained >>> this. You did not correct bindings either. >>> >> don't need to correct bindings. i believe bindings does not say enable gpio >> must be configured. > > They say. Read the bindings. Test your DTS. Or better: upstream your DTS > and prove to us that dtbs_check allows lack of enable-gpios. > > >>> >>>> 4) does the reverted change solve the issue your mentioned ? >>> >>> ??? I did not mention any issue. I am saying that your rationale is >>> either not complete or not correct. >>> >> do you suggest about how to make it complete? > > Yes, read what are bindings and then describe your change including > that: what is the issue, how it can be reproduced, what is the hardware, > why the bindings are not correct (if they are not correct) etc. > > > Best regards, > Krzysztof > ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" 2024-04-20 5:25 ` quic_zijuhu @ 2024-04-20 5:27 ` quic_zijuhu 2024-04-20 11:13 ` Krzysztof Kozlowski 1 sibling, 0 replies; 75+ messages in thread From: quic_zijuhu @ 2024-04-20 5:27 UTC (permalink / raw) To: Krzysztof Kozlowski, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, wt, bartosz.golaszewski, kernel On 4/20/2024 1:25 PM, quic_zijuhu wrote: > On 4/19/2024 9:49 PM, Krzysztof Kozlowski wrote: > > Hi Krzysztof,bartosz, > > let me summarize our discussion here in order to reduce unneccessary > disagreements here. > > 1) i only revert your change IS_ERR() to my change IS_ERR_OR_NULL. > > 2) your change will cause serious regression issues for many lunched > products > > 3) we only need to discuss how to handle devm_gpiod_get_optional(..., > "enable", ...) returning NULL since this is only difference between your > change and mine. > > 4) your change doesn't solve any actual issue and the reason you > submitted is that "The optional variants for the gpiod_get() family of > functions return NULL if the GPIO in question is not associated with > this device, and should not treat it as error". > > code applet of your merged change is shown by below link > https://patchwork.kernel.org/project/bluetooth/patch/20240208164017.26699-1-brgl@bgdev.pl/#25705104 > > 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; > } > > 5) Original BT driver design agree with your point mentioned at 4), so > for case "qcadev->bt_en == nullptr", qca_serdev_probe() don't do error > return for this scenario and use dev_warn() instead of dev_err() to give > user prompt. > > 6) your wrong fix changes flag power_ctrl_enabled set logic and will > cause serious BT regression issue, hope you will realize this point. > > > i would like to give below extra comments even if these comments are > irrelevant to the critical point of this issue mentioned at above 3) > > A) you need to investigate it is a) the prompting approach or message > error or b) the if condition error even if if dev_err() is used to give > prompt instead of dev_warn() in above 4). > > B) don't talk about how about devm_gpiod_get_optional() returning error > case since it is meaningless as explained by above 3). also don't > require a fix to fix another unreported issue. a fix is a good fix > if it fix the issue in question and don't introduce new issue. > > C) per DTS property enable-gpios of BT, different soc types have > different requirements, many are required and another many are NOT > mandatory as shown be below link. > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml. > > for a soc type which are attached to 3rd platform, customer doesn't > would like to or are not able to congfig BT reset pin within DTS for QCA > driver even if QC strongly suggest customer config it and also be marked > as required within above DTS bindings spec link. i often meet this > scenario. there are many of such lunched products. > > i will try to fix this issue due your change product by product in new > patch thread based on this DTS comment. > > D) you maybe ping me offline about this issue if you are a member of QC > since you known "go/upstream" > >> On 19/04/2024 01:17, quic_zijuhu wrote: >>> On 4/19/2024 6:37 AM, Krzysztof Kozlowski wrote: >>>> On 18/04/2024 23:16, quic_zijuhu wrote: >>>>> On 4/19/2024 12:52 AM, Krzysztof Kozlowski wrote: >>>>>> On 18/04/2024 16:06, Zijun Hu wrote: >>>>>>> This reverts commit 56d074d26c5828773b00b2185dd7e1d08273b8e8. >>>>>>> >>>>>>> Commit 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() >>>>>>> with gpiod_get_optional()") will cause serious regression issue for >>>>>>> several QCA controllers such as QCA_WCN6750,QCA_WCN6855,QCA_ROME, >>>>>> >>>>>> The pin is required on 6750, 6855 and maybe others. You cannot not have >>>>>> the GPIO. >>>>>> >>>>>> This is no correct fix. You provide wrong DTS and, instead fixing it, >>>>>> try to revert kernel code. >>>>>> >>>>>> No, fix your DTS first. >>>>>> >>>>> no. your point is not right. >>>>> >>>>> 1) do you have any evidence that the hci_qca driver must use reset GPIO? >>>> >>>> I think we talk here about enable-gpios, right? Then the evidence are >>>> bindings. >>>> >>> yes. properties within bindings only means driver supporting it, don't means user must >>> config it. the gpio is got by devm_gpiod_get_optional() variant. that means it is optional >>> about if user need to config it. >> >> No. Read writing bindings and other presentations explaining what are >> Devicetree bindings. >> >> You miss entirely the point and use downstream narrative. This won't >> work and it was told so many times, that I expect you to do the homework >> first. >> >> Use "go/upstream" before posting more on this topic. >> >> >>>>> 2) why does original design do error return when get GPIO error if GPIO is mandatory? >>>> >>>> If GPIO is mandatory, then it is expected to return error. What is the >>>> problem here? >>>> >>> sorry, i miss a NOT for my question. my question is that >>> 2) why does original design NOT do error return when get GPIO error if GPIO is mandatory? >>>> >>>>> 3) i meet many customer cases that BT are working fine without hci_qca operating the GPIO, >>>>> there is why HCI_QUIRK_NON_PERSISTENT_SETUP are introduced. >>>> >>>> Bindings tell different story and nothing in the commit msg explained >>>> this. You did not correct bindings either. >>>> >>> don't need to correct bindings. i believe bindings does not say enable gpio >>> must be configured. >> >> They say. Read the bindings. Test your DTS. Or better: upstream your DTS >> and prove to us that dtbs_check allows lack of enable-gpios. >> >> >>>> >>>>> 4) does the reverted change solve the issue your mentioned ? >>>> >>>> ??? I did not mention any issue. I am saying that your rationale is >>>> either not complete or not correct. >>>> >>> do you suggest about how to make it complete? >> >> Yes, read what are bindings and then describe your change including >> that: what is the issue, how it can be reproduced, what is the hardware, >> why the bindings are not correct (if they are not correct) etc. >> >> >> Best regards, >> Krzysztof >> > ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" 2024-04-20 5:25 ` quic_zijuhu 2024-04-20 5:27 ` quic_zijuhu @ 2024-04-20 11:13 ` Krzysztof Kozlowski 2024-04-20 23:01 ` quic_zijuhu 1 sibling, 1 reply; 75+ messages in thread From: Krzysztof Kozlowski @ 2024-04-20 11:13 UTC (permalink / raw) To: quic_zijuhu, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, wt, bartosz.golaszewski On 20/04/2024 07:25, quic_zijuhu wrote: > On 4/19/2024 9:49 PM, Krzysztof Kozlowski wrote: > > Hi Krzysztof,bartosz, > > let me summarize our discussion here in order to reduce unneccessary > disagreements here. > > 1) i only revert your change IS_ERR() to my change IS_ERR_OR_NULL. > > 2) your change will cause serious regression issues for many lunched > products Instead of repeating every time "serious regression" can you actually explain the problem? None of commit messages from v3 help there. > > 3) we only need to discuss how to handle devm_gpiod_get_optional(..., > "enable", ...) returning NULL since this is only difference between your > change and mine. > > 4) your change doesn't solve any actual issue and the reason you > submitted is that "The optional variants for the gpiod_get() family of > functions return NULL if the GPIO in question is not associated with > this device, and should not treat it as error". > > code applet of your merged change is shown by below link > https://patchwork.kernel.org/project/bluetooth/patch/20240208164017.26699-1-brgl@bgdev.pl/#25705104 > > 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; > } > > 5) Original BT driver design agree with your point mentioned at 4), so > for case "qcadev->bt_en == nullptr", qca_serdev_probe() don't do error > return for this scenario and use dev_warn() instead of dev_err() to give > user prompt. > > 6) your wrong fix changes flag power_ctrl_enabled set logic and will > cause serious BT regression issue, hope you will realize this point. Sorry, not realized and you did not explain it. Neither above nor in commit msg. > > > i would like to give below extra comments even if these comments are > irrelevant to the critical point of this issue mentioned at above 3) > > A) you need to investigate it is a) the prompting approach or message > error or b) the if condition error even if if dev_err() is used to give > prompt instead of dev_warn() in above 4). What? > > B) don't talk about how about devm_gpiod_get_optional() returning error > case since it is meaningless as explained by above 3). also don't > require a fix to fix another unreported issue. a fix is a good fix > if it fix the issue in question and don't introduce new issue. What? > > C) per DTS property enable-gpios of BT, different soc types have > different requirements, many are required and another many are NOT > mandatory as shown be below link. > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml. > > for a soc type which are attached to 3rd platform, customer doesn't > would like to or are not able to congfig BT reset pin within DTS for QCA > driver even if QC strongly suggest customer config it and also be marked > as required within above DTS bindings spec link. i often meet this > scenario. there are many of such lunched products. So where is it documented? Where is it explained? Which binding or which commit msg? > > i will try to fix this issue due your change product by product in new > patch thread based on this DTS comment. > > D) you maybe ping me offline about this issue if you are a member of QC > since you known "go/upstream" Please keep all discussions public, unless your customer requires some sort of confidentiality. Although even then I would argue that you can hide company secrets and discuss about hardware. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" 2024-04-20 11:13 ` Krzysztof Kozlowski @ 2024-04-20 23:01 ` quic_zijuhu 0 siblings, 0 replies; 75+ messages in thread From: quic_zijuhu @ 2024-04-20 23:01 UTC (permalink / raw) To: Krzysztof Kozlowski, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, wt, bartosz.golaszewski, kernel On 4/20/2024 7:13 PM, Krzysztof Kozlowski wrote: > On 20/04/2024 07:25, quic_zijuhu wrote: >> On 4/19/2024 9:49 PM, Krzysztof Kozlowski wrote: >> >> Hi Krzysztof,bartosz, >> >> let me summarize our discussion here in order to reduce unneccessary >> disagreements here. >> >> 1) i only revert your change IS_ERR() to my change IS_ERR_OR_NULL. >> >> 2) your change will cause serious regression issues for many lunched >> products > > Instead of repeating every time "serious regression" can you actually > explain the problem? > None of commit messages from v3 help there. > as shown by below link https://lore.kernel.org/all/1713650800-29741-2-git-send-email-quic_zijuhu@quicinc.com/ there are no v3 patch for patch serial with this tile the updated patch serial tile is "Fix two regression issues for QCA controllers" shown by above mentioned link. let us discuss it with the updated one. v3 of the updated one has good commit message for this issue. you have given reply with the v3 and it seems you understand what is the problem >> >> 3) we only need to discuss how to handle devm_gpiod_get_optional(..., >> "enable", ...) returning NULL since this is only difference between your >> change and mine. >> >> 4) your change doesn't solve any actual issue and the reason you >> submitted is that "The optional variants for the gpiod_get() family of >> functions return NULL if the GPIO in question is not associated with >> this device, and should not treat it as error". >> >> code applet of your merged change is shown by below link >> https://patchwork.kernel.org/project/bluetooth/patch/20240208164017.26699-1-brgl@bgdev.pl/#25705104 >> >> 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; >> } >> >> 5) Original BT driver design agree with your point mentioned at 4), so >> for case "qcadev->bt_en == nullptr", qca_serdev_probe() don't do error >> return for this scenario and use dev_warn() instead of dev_err() to give >> user prompt. >> >> 6) your wrong fix changes flag power_ctrl_enabled set logic and will >> cause serious BT regression issue, hope you will realize this point. > > Sorry, not realized and you did not explain it. Neither above nor in > commit msg. > now. you understood why your merged change as shown link of 4) have problems and introduced our discussed issue, right? >> >> >> i would like to give below extra comments even if these comments are >> irrelevant to the critical point of this issue mentioned at above 3) >> >> A) you need to investigate it is a) the prompting approach or message >> error or b) the if condition error even if if dev_err() is used to give >> prompt instead of dev_warn() in above 4). > > What? > >> >> B) don't talk about how about devm_gpiod_get_optional() returning error >> case since it is meaningless as explained by above 3). also don't >> require a fix to fix another unreported issue. a fix is a good fix >> if it fix the issue in question and don't introduce new issue. > > What? > >> >> C) per DTS property enable-gpios of BT, different soc types have >> different requirements, many are required and another many are NOT >> mandatory as shown be below link. >> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml. >> >> for a soc type which are attached to 3rd platform, customer doesn't >> would like to or are not able to congfig BT reset pin within DTS for QCA >> driver even if QC strongly suggest customer config it and also be marked >> as required within above DTS bindings spec link. i often meet this >> scenario. there are many of such lunched products. > > So where is it documented? Where is it explained? Which binding or which > commit msg? > >> >> i will try to fix this issue due your change product by product in new >> patch thread based on this DTS comment. >> >> D) you maybe ping me offline about this issue if you are a member of QC >> since you known "go/upstream" > > Please keep all discussions public, unless your customer requires some > sort of confidentiality. Although even then I would argue that you can > hide company secrets and discuss about hardware. > > Best regards, > Krzysztof > > ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" 2024-04-18 14:06 ` [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" Zijun Hu 2024-04-18 14:31 ` Fix two regression issues for QCA controllers bluez.test.bot 2024-04-18 16:52 ` [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" Krzysztof Kozlowski @ 2024-04-18 17:00 ` Bartosz Golaszewski 2024-04-18 21:43 ` quic_zijuhu 2 siblings, 1 reply; 75+ messages in thread From: Bartosz Golaszewski @ 2024-04-18 17:00 UTC (permalink / raw) To: Zijun Hu Cc: luiz.dentz, luiz.von.dentz, marcel, linux-bluetooth, wt, krzysztof.kozlowski On Thu, 18 Apr 2024 at 16:06, Zijun Hu <quic_zijuhu@quicinc.com> wrote: > > This reverts commit 56d074d26c5828773b00b2185dd7e1d08273b8e8. > > Commit 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() > with gpiod_get_optional()") will cause serious regression issue for > several QCA controllers such as QCA_WCN6750,QCA_WCN6855,QCA_ROME, > QCA_QCA6390 and QCA_QCA2066, the regression issue is that BT can't be > enabled any more once BT is disabled if BT reset pin is not configured > by DT or ACPI. > > if BT reset pin is not configured, devm_gpiod_get_optional() will return > NULL, and we should NOT set quirk HCI_QUIRK_NON_PERSISTENT_SETUP, but the > reverted commit SET the quirk since NULL is not a error case, and cause > qca_setup() call failure triggered by the 2nd and later BT enable > operations since there are no available BT reset pin to clear BT firmware > downloaded by the 1st enable operation, fixed by reverting the commit. > > Fixes: 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()") > Reported-by: Wren Turkal <wt@penguintechs.org> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=218726 > Link: https://lore.kernel.org/linux-bluetooth/ea20bb9b-6b60-47fc-ae42-5eed918ad7b4@quicinc.com/T/#m73d6a71d2f454bb03588c66f3ef7912274d37c6f > Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> > Tested-by: Wren Turkal <wt@penguintechs.org> > --- > drivers/bluetooth/hci_qca.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c > index 92fa20f5ac7d..160175a23a49 100644 > --- a/drivers/bluetooth/hci_qca.c > +++ b/drivers/bluetooth/hci_qca.c > @@ -2323,7 +2323,7 @@ static int qca_serdev_probe(struct serdev_device *serdev) > > qcadev->bt_en = devm_gpiod_get_optional(&serdev->dev, "enable", > GPIOD_OUT_LOW); > - if (IS_ERR(qcadev->bt_en) && > + if (IS_ERR_OR_NULL(qcadev->bt_en) && > (data->soc_type == QCA_WCN6750 || > data->soc_type == QCA_WCN6855)) { > dev_err(&serdev->dev, "failed to acquire BT_EN gpio\n"); > @@ -2332,7 +2332,7 @@ static int qca_serdev_probe(struct serdev_device *serdev) > > qcadev->sw_ctrl = devm_gpiod_get_optional(&serdev->dev, "swctrl", > GPIOD_IN); > - if (IS_ERR(qcadev->sw_ctrl) && > + if (IS_ERR_OR_NULL(qcadev->sw_ctrl) && > (data->soc_type == QCA_WCN6750 || > data->soc_type == QCA_WCN6855 || > data->soc_type == QCA_WCN7850)) > @@ -2354,7 +2354,7 @@ static int qca_serdev_probe(struct serdev_device *serdev) > default: > qcadev->bt_en = devm_gpiod_get_optional(&serdev->dev, "enable", > GPIOD_OUT_LOW); > - if (IS_ERR(qcadev->bt_en)) { > + if (IS_ERR_OR_NULL(qcadev->bt_en)) { > dev_warn(&serdev->dev, "failed to acquire enable gpio\n"); > power_ctrl_enabled = false; > } > -- > 2.7.4 > I told you under your yesterday's submission that you should instead consider bailing out from probe() if gpiod_get_optional() returns an error as right now if it returns EPROBE_DEFER (enable-gpios is there but the controller is not up yet), you will act like the GPIO was not even specified. gpiod_get_optional() returns NULL if the GPIO property is not there or an error if anything else goes wrong. In the latter case, you should abort probe. Bart ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" 2024-04-18 17:00 ` Bartosz Golaszewski @ 2024-04-18 21:43 ` quic_zijuhu 2024-04-18 22:42 ` Bartosz Golaszewski 0 siblings, 1 reply; 75+ messages in thread From: quic_zijuhu @ 2024-04-18 21:43 UTC (permalink / raw) To: Bartosz Golaszewski Cc: luiz.dentz, luiz.von.dentz, marcel, linux-bluetooth, wt, krzysztof.kozlowski On 4/19/2024 1:00 AM, Bartosz Golaszewski wrote: > On Thu, 18 Apr 2024 at 16:06, Zijun Hu <quic_zijuhu@quicinc.com> wrote: >> >> This reverts commit 56d074d26c5828773b00b2185dd7e1d08273b8e8. >> >> Commit 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() >> with gpiod_get_optional()") will cause serious regression issue for >> several QCA controllers such as QCA_WCN6750,QCA_WCN6855,QCA_ROME, >> QCA_QCA6390 and QCA_QCA2066, the regression issue is that BT can't be >> enabled any more once BT is disabled if BT reset pin is not configured >> by DT or ACPI. >> >> if BT reset pin is not configured, devm_gpiod_get_optional() will return >> NULL, and we should NOT set quirk HCI_QUIRK_NON_PERSISTENT_SETUP, but the >> reverted commit SET the quirk since NULL is not a error case, and cause >> qca_setup() call failure triggered by the 2nd and later BT enable >> operations since there are no available BT reset pin to clear BT firmware >> downloaded by the 1st enable operation, fixed by reverting the commit. >> >> Fixes: 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()") >> Reported-by: Wren Turkal <wt@penguintechs.org> >> Link: https://bugzilla.kernel.org/show_bug.cgi?id=218726 >> Link: https://lore.kernel.org/linux-bluetooth/ea20bb9b-6b60-47fc-ae42-5eed918ad7b4@quicinc.com/T/#m73d6a71d2f454bb03588c66f3ef7912274d37c6f >> Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> >> Tested-by: Wren Turkal <wt@penguintechs.org> >> --- >> drivers/bluetooth/hci_qca.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c >> index 92fa20f5ac7d..160175a23a49 100644 >> --- a/drivers/bluetooth/hci_qca.c >> +++ b/drivers/bluetooth/hci_qca.c >> @@ -2323,7 +2323,7 @@ static int qca_serdev_probe(struct serdev_device *serdev) >> >> qcadev->bt_en = devm_gpiod_get_optional(&serdev->dev, "enable", >> GPIOD_OUT_LOW); >> - if (IS_ERR(qcadev->bt_en) && >> + if (IS_ERR_OR_NULL(qcadev->bt_en) && >> (data->soc_type == QCA_WCN6750 || >> data->soc_type == QCA_WCN6855)) { >> dev_err(&serdev->dev, "failed to acquire BT_EN gpio\n"); >> @@ -2332,7 +2332,7 @@ static int qca_serdev_probe(struct serdev_device *serdev) >> >> qcadev->sw_ctrl = devm_gpiod_get_optional(&serdev->dev, "swctrl", >> GPIOD_IN); >> - if (IS_ERR(qcadev->sw_ctrl) && >> + if (IS_ERR_OR_NULL(qcadev->sw_ctrl) && >> (data->soc_type == QCA_WCN6750 || >> data->soc_type == QCA_WCN6855 || >> data->soc_type == QCA_WCN7850)) >> @@ -2354,7 +2354,7 @@ static int qca_serdev_probe(struct serdev_device *serdev) >> default: >> qcadev->bt_en = devm_gpiod_get_optional(&serdev->dev, "enable", >> GPIOD_OUT_LOW); >> - if (IS_ERR(qcadev->bt_en)) { >> + if (IS_ERR_OR_NULL(qcadev->bt_en)) { >> dev_warn(&serdev->dev, "failed to acquire enable gpio\n"); >> power_ctrl_enabled = false; >> } >> -- >> 2.7.4 >> > > I told you under your yesterday's submission that you should instead > consider bailing out from probe() if gpiod_get_optional() returns an > error as right now if it returns EPROBE_DEFER (enable-gpios is there > but the controller is not up yet), you will act like the GPIO was not > even specified. > > gpiod_get_optional() returns NULL if the GPIO property is not there or > an error if anything else goes wrong. In the latter case, you should > abort probe. > 1) do you meet the case that EPROBE_DEFER is returned ? 2) does the reverted change solve above issue you mentioned? 3) does the reverted change solve any functionality issue you actually meet ? 4) BT still is able to work fine by clearing the quirk even if getting preferred H/W reset way failure, why do we need to bail-out and return dev_err_probe() ? we will fix it by right way if EPROBE_DEFER is reported. this change is to solve the issue mentioned by commit message regardless other issues. it is not possible for every commit to fix any other potential issues as long as the fix doesn't introduce new issue. right ? > Bart ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" 2024-04-18 21:43 ` quic_zijuhu @ 2024-04-18 22:42 ` Bartosz Golaszewski 2024-04-18 23:36 ` quic_zijuhu 2024-04-21 7:14 ` Wren Turkal 0 siblings, 2 replies; 75+ messages in thread From: Bartosz Golaszewski @ 2024-04-18 22:42 UTC (permalink / raw) To: quic_zijuhu Cc: luiz.dentz, luiz.von.dentz, marcel, linux-bluetooth, wt, krzysztof.kozlowski On Thu, 18 Apr 2024 at 23:43, quic_zijuhu <quic_zijuhu@quicinc.com> wrote: > > On 4/19/2024 1:00 AM, Bartosz Golaszewski wrote: > > On Thu, 18 Apr 2024 at 16:06, Zijun Hu <quic_zijuhu@quicinc.com> wrote: > >> > >> This reverts commit 56d074d26c5828773b00b2185dd7e1d08273b8e8. > >> > >> Commit 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() > >> with gpiod_get_optional()") will cause serious regression issue for > >> several QCA controllers such as QCA_WCN6750,QCA_WCN6855,QCA_ROME, > >> QCA_QCA6390 and QCA_QCA2066, the regression issue is that BT can't be > >> enabled any more once BT is disabled if BT reset pin is not configured > >> by DT or ACPI. > >> > >> if BT reset pin is not configured, devm_gpiod_get_optional() will return > >> NULL, and we should NOT set quirk HCI_QUIRK_NON_PERSISTENT_SETUP, but the > >> reverted commit SET the quirk since NULL is not a error case, and cause > >> qca_setup() call failure triggered by the 2nd and later BT enable > >> operations since there are no available BT reset pin to clear BT firmware > >> downloaded by the 1st enable operation, fixed by reverting the commit. > >> > >> Fixes: 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()") > >> Reported-by: Wren Turkal <wt@penguintechs.org> > >> Link: https://bugzilla.kernel.org/show_bug.cgi?id=218726 > >> Link: https://lore.kernel.org/linux-bluetooth/ea20bb9b-6b60-47fc-ae42-5eed918ad7b4@quicinc.com/T/#m73d6a71d2f454bb03588c66f3ef7912274d37c6f > >> Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> > >> Tested-by: Wren Turkal <wt@penguintechs.org> > >> --- > >> drivers/bluetooth/hci_qca.c | 6 +++--- > >> 1 file changed, 3 insertions(+), 3 deletions(-) > >> > >> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c > >> index 92fa20f5ac7d..160175a23a49 100644 > >> --- a/drivers/bluetooth/hci_qca.c > >> +++ b/drivers/bluetooth/hci_qca.c > >> @@ -2323,7 +2323,7 @@ static int qca_serdev_probe(struct serdev_device *serdev) > >> > >> qcadev->bt_en = devm_gpiod_get_optional(&serdev->dev, "enable", > >> GPIOD_OUT_LOW); > >> - if (IS_ERR(qcadev->bt_en) && > >> + if (IS_ERR_OR_NULL(qcadev->bt_en) && > >> (data->soc_type == QCA_WCN6750 || > >> data->soc_type == QCA_WCN6855)) { > >> dev_err(&serdev->dev, "failed to acquire BT_EN gpio\n"); > >> @@ -2332,7 +2332,7 @@ static int qca_serdev_probe(struct serdev_device *serdev) > >> > >> qcadev->sw_ctrl = devm_gpiod_get_optional(&serdev->dev, "swctrl", > >> GPIOD_IN); > >> - if (IS_ERR(qcadev->sw_ctrl) && > >> + if (IS_ERR_OR_NULL(qcadev->sw_ctrl) && > >> (data->soc_type == QCA_WCN6750 || > >> data->soc_type == QCA_WCN6855 || > >> data->soc_type == QCA_WCN7850)) > >> @@ -2354,7 +2354,7 @@ static int qca_serdev_probe(struct serdev_device *serdev) > >> default: > >> qcadev->bt_en = devm_gpiod_get_optional(&serdev->dev, "enable", > >> GPIOD_OUT_LOW); > >> - if (IS_ERR(qcadev->bt_en)) { > >> + if (IS_ERR_OR_NULL(qcadev->bt_en)) { > >> dev_warn(&serdev->dev, "failed to acquire enable gpio\n"); > >> power_ctrl_enabled = false; > >> } > >> -- > >> 2.7.4 > >> > > > > I told you under your yesterday's submission that you should instead > > consider bailing out from probe() if gpiod_get_optional() returns an > > error as right now if it returns EPROBE_DEFER (enable-gpios is there > > but the controller is not up yet), you will act like the GPIO was not > > even specified. > > > > gpiod_get_optional() returns NULL if the GPIO property is not there or > > an error if anything else goes wrong. In the latter case, you should > > abort probe. > > > > 1) do you meet the case that EPROBE_DEFER is returned ? > It doesn't matter. It's about correct usage of a programming interface. > 2) does the reverted change solve above issue you mentioned? > What? > 3) does the reverted change solve any functionality issue you actually meet ? > What? > 4) BT still is able to work fine by clearing the quirk even if getting preferred H/W reset way failure, why do we need to bail-out and return dev_err_probe() ? > The only acceptable "failure" for gpiod_get_optional() is when it returns NULL. I should have fixed it when I sent the patch you're reverting but I didn't spot it right away. Proceeding on any other error makes no sense and will result in inconsistent behavior. > we will fix it by right way if EPROBE_DEFER is reported. > What? > this change is to solve the issue mentioned by commit message regardless other issues. > it is not possible for every commit to fix any other potential issues as long as the fix > doesn't introduce new issue. > What I mean is: don't revert a logically sound commit. Instead: improve the situation on top of it. In this case: bail out on error. And like Krzysztof said: right now the GPIO is required according to bindings so using gpiod_get_optional() doesn't even make sense as far as bindings go. Bart ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" 2024-04-18 22:42 ` Bartosz Golaszewski @ 2024-04-18 23:36 ` quic_zijuhu 2024-04-19 21:27 ` Bartosz Golaszewski 2024-04-21 7:14 ` Wren Turkal 1 sibling, 1 reply; 75+ messages in thread From: quic_zijuhu @ 2024-04-18 23:36 UTC (permalink / raw) To: Bartosz Golaszewski Cc: luiz.dentz, luiz.von.dentz, marcel, linux-bluetooth, wt, krzysztof.kozlowski On 4/19/2024 6:42 AM, Bartosz Golaszewski wrote: > On Thu, 18 Apr 2024 at 23:43, quic_zijuhu <quic_zijuhu@quicinc.com> wrote: >> >> On 4/19/2024 1:00 AM, Bartosz Golaszewski wrote: >>> On Thu, 18 Apr 2024 at 16:06, Zijun Hu <quic_zijuhu@quicinc.com> wrote: >>>> >>>> This reverts commit 56d074d26c5828773b00b2185dd7e1d08273b8e8. >>>> >>>> Commit 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() >>>> with gpiod_get_optional()") will cause serious regression issue for >>>> several QCA controllers such as QCA_WCN6750,QCA_WCN6855,QCA_ROME, >>>> QCA_QCA6390 and QCA_QCA2066, the regression issue is that BT can't be >>>> enabled any more once BT is disabled if BT reset pin is not configured >>>> by DT or ACPI. >>>> >>>> if BT reset pin is not configured, devm_gpiod_get_optional() will return >>>> NULL, and we should NOT set quirk HCI_QUIRK_NON_PERSISTENT_SETUP, but the >>>> reverted commit SET the quirk since NULL is not a error case, and cause >>>> qca_setup() call failure triggered by the 2nd and later BT enable >>>> operations since there are no available BT reset pin to clear BT firmware >>>> downloaded by the 1st enable operation, fixed by reverting the commit. >>>> >>>> Fixes: 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()") >>>> Reported-by: Wren Turkal <wt@penguintechs.org> >>>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=218726 >>>> Link: https://lore.kernel.org/linux-bluetooth/ea20bb9b-6b60-47fc-ae42-5eed918ad7b4@quicinc.com/T/#m73d6a71d2f454bb03588c66f3ef7912274d37c6f >>>> Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> >>>> Tested-by: Wren Turkal <wt@penguintechs.org> >>>> --- >>>> drivers/bluetooth/hci_qca.c | 6 +++--- >>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c >>>> index 92fa20f5ac7d..160175a23a49 100644 >>>> --- a/drivers/bluetooth/hci_qca.c >>>> +++ b/drivers/bluetooth/hci_qca.c >>>> @@ -2323,7 +2323,7 @@ static int qca_serdev_probe(struct serdev_device *serdev) >>>> >>>> qcadev->bt_en = devm_gpiod_get_optional(&serdev->dev, "enable", >>>> GPIOD_OUT_LOW); >>>> - if (IS_ERR(qcadev->bt_en) && >>>> + if (IS_ERR_OR_NULL(qcadev->bt_en) && >>>> (data->soc_type == QCA_WCN6750 || >>>> data->soc_type == QCA_WCN6855)) { >>>> dev_err(&serdev->dev, "failed to acquire BT_EN gpio\n"); >>>> @@ -2332,7 +2332,7 @@ static int qca_serdev_probe(struct serdev_device *serdev) >>>> >>>> qcadev->sw_ctrl = devm_gpiod_get_optional(&serdev->dev, "swctrl", >>>> GPIOD_IN); >>>> - if (IS_ERR(qcadev->sw_ctrl) && >>>> + if (IS_ERR_OR_NULL(qcadev->sw_ctrl) && >>>> (data->soc_type == QCA_WCN6750 || >>>> data->soc_type == QCA_WCN6855 || >>>> data->soc_type == QCA_WCN7850)) >>>> @@ -2354,7 +2354,7 @@ static int qca_serdev_probe(struct serdev_device *serdev) >>>> default: >>>> qcadev->bt_en = devm_gpiod_get_optional(&serdev->dev, "enable", >>>> GPIOD_OUT_LOW); >>>> - if (IS_ERR(qcadev->bt_en)) { >>>> + if (IS_ERR_OR_NULL(qcadev->bt_en)) { >>>> dev_warn(&serdev->dev, "failed to acquire enable gpio\n"); >>>> power_ctrl_enabled = false; >>>> } >>>> -- >>>> 2.7.4 >>>> >>> >>> I told you under your yesterday's submission that you should instead >>> consider bailing out from probe() if gpiod_get_optional() returns an >>> error as right now if it returns EPROBE_DEFER (enable-gpios is there >>> but the controller is not up yet), you will act like the GPIO was not >>> even specified. >>> >>> gpiod_get_optional() returns NULL if the GPIO property is not there or >>> an error if anything else goes wrong. In the latter case, you should >>> abort probe. >>> >> >> 1) do you meet the case that EPROBE_DEFER is returned ? >> > > It doesn't matter. It's about correct usage of a programming interface. > >> 2) does the reverted change solve above issue you mentioned? >> > > What? > the revert change means below change. Fixes: 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()") >> 3) does the reverted change solve any functionality issue you actually meet ? >> > > What? > see above. >> 4) BT still is able to work fine by clearing the quirk even if getting preferred H/W reset way failure, why do we need to bail-out and return dev_err_probe() ? >> > > The only acceptable "failure" for gpiod_get_optional() is when it > returns NULL. I should have fixed it when I sent the patch you're > reverting but I didn't spot it right away. Proceeding on any other > error makes no sense and will result in inconsistent behavior. > as i ever explained. we need to treat NULL returning and error returning equivalently. >> we will fix it by right way if EPROBE_DEFER is reported. >> > > What? > will fix the issue if anyone meet and report they meet the error that EPROBE_DEFER is reported. >> this change is to solve the issue mentioned by commit message regardless other issues. >> it is not possible for every commit to fix any other potential issues as long as the fix >> doesn't introduce new issue. >> > > What I mean is: don't revert a logically sound commit. Instead: > improve the situation on top of it. In this case: bail out on error. > And like Krzysztof said: right now the GPIO is required according to > bindings so using gpiod_get_optional() doesn't even make sense as far > as bindings go. > my point is that it is not logically sound commit. > Bart ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" 2024-04-18 23:36 ` quic_zijuhu @ 2024-04-19 21:27 ` Bartosz Golaszewski 2024-04-20 5:39 ` quic_zijuhu 0 siblings, 1 reply; 75+ messages in thread From: Bartosz Golaszewski @ 2024-04-19 21:27 UTC (permalink / raw) To: quic_zijuhu Cc: luiz.dentz, luiz.von.dentz, marcel, linux-bluetooth, wt, krzysztof.kozlowski On Fri, 19 Apr 2024 at 01:36, quic_zijuhu <quic_zijuhu@quicinc.com> wrote: > > On 4/19/2024 6:42 AM, Bartosz Golaszewski wrote: > > On Thu, 18 Apr 2024 at 23:43, quic_zijuhu <quic_zijuhu@quicinc.com> wrote: > > >> we will fix it by right way if EPROBE_DEFER is reported. > >> > > > > What? > > > will fix the issue if anyone meet and report they meet the error that EPROBE_DEFER is reported. No, this is wrong. Anything other than NULL or a valid descriptor pointer returned from gpiod_get_optional() means: an error has occurred and should be handled accordingly. Please improve the driver by bailing out in this case. Or wait until next week and I'll send a follow-up to my patch myself. Bart ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" 2024-04-19 21:27 ` Bartosz Golaszewski @ 2024-04-20 5:39 ` quic_zijuhu 0 siblings, 0 replies; 75+ messages in thread From: quic_zijuhu @ 2024-04-20 5:39 UTC (permalink / raw) To: Bartosz Golaszewski Cc: luiz.dentz, luiz.von.dentz, marcel, linux-bluetooth, wt, krzysztof.kozlowski, kernel On 4/20/2024 5:27 AM, Bartosz Golaszewski wrote: > On Fri, 19 Apr 2024 at 01:36, quic_zijuhu <quic_zijuhu@quicinc.com> wrote: >> >> On 4/19/2024 6:42 AM, Bartosz Golaszewski wrote: >>> On Thu, 18 Apr 2024 at 23:43, quic_zijuhu <quic_zijuhu@quicinc.com> wrote: >> >>>> we will fix it by right way if EPROBE_DEFER is reported. >>>> >>> >>> What? >>> >> will fix the issue if anyone meet and report they meet the error that EPROBE_DEFER is reported. > > No, this is wrong. Anything other than NULL or a valid descriptor > pointer returned from gpiod_get_optional() means: an error has > occurred and should be handled accordingly. Please improve the driver > by bailing out in this case. Or wait until next week and I'll send a > follow-up to my patch myself. > i think we don't need to focus on this point as commented at below link https://lore.kernel.org/all/01677a26-ea91-47cc-bdc4-283cf313d8e4@quicinc.com/ > Bart ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" 2024-04-18 22:42 ` Bartosz Golaszewski 2024-04-18 23:36 ` quic_zijuhu @ 2024-04-21 7:14 ` Wren Turkal 2024-04-21 9:40 ` quic_zijuhu 1 sibling, 1 reply; 75+ messages in thread From: Wren Turkal @ 2024-04-21 7:14 UTC (permalink / raw) To: Bartosz Golaszewski, quic_zijuhu Cc: luiz.dentz, luiz.von.dentz, marcel, linux-bluetooth, krzysztof.kozlowski On 4/18/24 3:42 PM, Bartosz Golaszewski wrote: >> 1) do you meet the case that EPROBE_DEFER is returned ? >> > It doesn't matter. It's about correct usage of a programming interface. In case you are not aware, this apparent correct usage of the programming interface breaks real hardware. As a kernel user with this problem, I am just wondering if we expect a fix to land before v6.9 lands. If we can't find the a fix that has "correct usage of the programming interface" before 6.9 closes out, would we be able to revert this change considering that it causes a real userspace regression in that the BT on some laptops simply don't work now? I guess I am asking if this theoretical correction more important than breaking actual currently supported hardware? Real users like me are hurt by this. In my case, I am using a laptop that was shipped in 2020 with Linux by Dell that included working BT support. I now have broken BT hardware that is barely usable at all. And as a kernel user, I thought the kernel had a no regression policy. Granted, I don't know the specific details of how it works. Does that policy include support of widely deployed hardware? Just so you know, I am just trying to understand what to expect. Also, I want to offer help. Is there anything I can do to help y'all reach a resolution? Thanks, wt -- You're more amazing than you think! ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" 2024-04-21 7:14 ` Wren Turkal @ 2024-04-21 9:40 ` quic_zijuhu 2024-04-22 5:26 ` Wren Turkal 0 siblings, 1 reply; 75+ messages in thread From: quic_zijuhu @ 2024-04-21 9:40 UTC (permalink / raw) To: Wren Turkal, Bartosz Golaszewski Cc: luiz.dentz, luiz.von.dentz, marcel, linux-bluetooth, krzysztof.kozlowski On 4/21/2024 3:14 PM, Wren Turkal wrote: > On 4/18/24 3:42 PM, Bartosz Golaszewski wrote: >>> 1) do you meet the case that EPROBE_DEFER is returned ? >>> >> It doesn't matter. It's about correct usage of a programming interface. > > In case you are not aware, this apparent correct usage of the > programming interface breaks real hardware. As a kernel user with this > problem, I am just wondering if we expect a fix to land before v6.9 lands. > > If we can't find the a fix that has "correct usage of the programming > interface" before 6.9 closes out, would we be able to revert this change > considering that it causes a real userspace regression in that the BT on > some laptops simply don't work now? I guess I am asking if this > theoretical correction more important than breaking actual currently > supported hardware? > > Real users like me are hurt by this. In my case, I am using a laptop > that was shipped in 2020 with Linux by Dell that included working BT > support. I now have broken BT hardware that is barely usable at all. > > And as a kernel user, I thought the kernel had a no regression policy. > Granted, I don't know the specific details of how it works. Does that > policy include support of widely deployed hardware? > > Just so you know, I am just trying to understand what to expect. > > Also, I want to offer help. Is there anything I can do to help y'all > reach a resolution? > > Thanks, > wt per QCA6390. we have correct usage of a programming interface. as my reply at below link, we don't need to take care bout Bartosz's question since it is not relevant with this issue. https://lore.kernel.org/all/01677a26-ea91-47cc-bdc4-283cf313d8e4@quicinc.com/ ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" 2024-04-21 9:40 ` quic_zijuhu @ 2024-04-22 5:26 ` Wren Turkal 0 siblings, 0 replies; 75+ messages in thread From: Wren Turkal @ 2024-04-22 5:26 UTC (permalink / raw) To: quic_zijuhu, Bartosz Golaszewski Cc: luiz.dentz, luiz.von.dentz, marcel, linux-bluetooth, krzysztof.kozlowski On 4/21/24 2:40 AM, quic_zijuhu wrote: > On 4/21/2024 3:14 PM, Wren Turkal wrote: >> On 4/18/24 3:42 PM, Bartosz Golaszewski wrote: >>>> 1) do you meet the case that EPROBE_DEFER is returned ? >>>> >>> It doesn't matter. It's about correct usage of a programming interface. >> >> In case you are not aware, this apparent correct usage of the >> programming interface breaks real hardware. As a kernel user with this >> problem, I am just wondering if we expect a fix to land before v6.9 lands. >> >> If we can't find the a fix that has "correct usage of the programming >> interface" before 6.9 closes out, would we be able to revert this change >> considering that it causes a real userspace regression in that the BT on >> some laptops simply don't work now? I guess I am asking if this >> theoretical correction more important than breaking actual currently >> supported hardware? >> >> Real users like me are hurt by this. In my case, I am using a laptop >> that was shipped in 2020 with Linux by Dell that included working BT >> support. I now have broken BT hardware that is barely usable at all. >> >> And as a kernel user, I thought the kernel had a no regression policy. >> Granted, I don't know the specific details of how it works. Does that >> policy include support of widely deployed hardware? >> >> Just so you know, I am just trying to understand what to expect. >> >> Also, I want to offer help. Is there anything I can do to help y'all >> reach a resolution? >> >> Thanks, >> wt > per QCA6390. we have correct usage of a programming interface. > > as my reply at below link, we don't need to take care bout > Bartosz's question since it is not relevant with this issue. > > https://lore.kernel.org/all/01677a26-ea91-47cc-bdc4-283cf313d8e4@quicinc.com/ Ack. Thx for the pointer. I will admit, I am finding it a bit difficult to follow the discussion. As such, I have no opinion on who's right. I just want to help reach a conclusion that includes my hardware working. wt -- You're more amazing than you think! ^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH v1 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot 2024-04-18 14:06 [PATCH v1 0/2] Fix two regression issues for QCA controllers Zijun Hu 2024-04-18 14:06 ` [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" Zijun Hu @ 2024-04-18 14:06 ` Zijun Hu 2024-04-18 16:48 ` Krzysztof Kozlowski 2024-04-19 21:48 ` [PATCH v1 0/2] Fix two regression issues for QCA controllers Zijun Hu 2024-04-19 22:03 ` [PATCH v3 0/2] Fix two regression issues for QCA controllers Zijun Hu 3 siblings, 1 reply; 75+ messages in thread From: Zijun Hu @ 2024-04-18 14:06 UTC (permalink / raw) To: luiz.dentz, luiz.von.dentz, marcel Cc: quic_zijuhu, linux-bluetooth, wt, bartosz.golaszewski, krzysztof.kozlowski From: Zijun Hu <zijuhu@qti.qualcomm.com> Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") will cause regression issue for QCA_QCA6390 if BT reset pin is not configured by DT or ACPI, the regression issue is that BT can't be enabled after disable then warm reboot, fixed by correcting conditions for sending the VSC reset controller within qca_serdev_shutdown(). Fixes: 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") Reported-by: Wren Turkal <wt@penguintechs.org> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218726 Signed-off-by: Zijun Hu <zijuhu@qti.qualcomm.com> Tested-by: Wren Turkal <wt@penguintechs.org> --- drivers/bluetooth/hci_qca.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index 160175a23a49..2a47a60ecc25 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -2437,15 +2437,21 @@ static void qca_serdev_shutdown(struct device *dev) struct qca_serdev *qcadev = serdev_device_get_drvdata(serdev); struct hci_uart *hu = &qcadev->serdev_hu; struct hci_dev *hdev = hu->hdev; - struct qca_data *qca = hu->priv; const u8 ibs_wake_cmd[] = { 0xFD }; const u8 edl_reset_soc_cmd[] = { 0x01, 0x00, 0xFC, 0x01, 0x05 }; if (qcadev->btsoc_type == QCA_QCA6390) { - if (test_bit(QCA_BT_OFF, &qca->flags) || - !test_bit(HCI_RUNNING, &hdev->flags)) + if (test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) { + BT_INFO("QCA do not need to send EDL_RESET_REQ"); return; + } + + if (hci_dev_test_flag(hdev, HCI_SETUP)) { + BT_INFO("QCA do not send EDL_RESET_REQ"); + return; + } + BT_INFO("QCA start to send EDL_RESET_REQ"); serdev_device_write_flush(serdev); ret = serdev_device_write_buf(serdev, ibs_wake_cmd, sizeof(ibs_wake_cmd)); -- 2.7.4 ^ permalink raw reply related [flat|nested] 75+ messages in thread
* Re: [PATCH v1 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot 2024-04-18 14:06 ` [PATCH v1 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot Zijun Hu @ 2024-04-18 16:48 ` Krzysztof Kozlowski 2024-04-18 20:34 ` quic_zijuhu 0 siblings, 1 reply; 75+ messages in thread From: Krzysztof Kozlowski @ 2024-04-18 16:48 UTC (permalink / raw) To: Zijun Hu, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, wt, bartosz.golaszewski On 18/04/2024 16:06, Zijun Hu wrote: > From: Zijun Hu <zijuhu@qti.qualcomm.com> > > Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed > serdev") will cause regression issue for QCA_QCA6390 if BT reset pin is > not configured by DT or ACPI, the regression issue is that BT can't be > enabled after disable then warm reboot, fixed by correcting conditions > for sending the VSC reset controller within qca_serdev_shutdown(). I have trouble understanding what is the bug. Can you rephrase it? > > Fixes: 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") > Reported-by: Wren Turkal <wt@penguintechs.org> > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218726 > Signed-off-by: Zijun Hu <zijuhu@qti.qualcomm.com> > Tested-by: Wren Turkal <wt@penguintechs.org> > --- > drivers/bluetooth/hci_qca.c | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c > index 160175a23a49..2a47a60ecc25 100644 > --- a/drivers/bluetooth/hci_qca.c > +++ b/drivers/bluetooth/hci_qca.c > @@ -2437,15 +2437,21 @@ static void qca_serdev_shutdown(struct device *dev) > struct qca_serdev *qcadev = serdev_device_get_drvdata(serdev); > struct hci_uart *hu = &qcadev->serdev_hu; > struct hci_dev *hdev = hu->hdev; > - struct qca_data *qca = hu->priv; > const u8 ibs_wake_cmd[] = { 0xFD }; > const u8 edl_reset_soc_cmd[] = { 0x01, 0x00, 0xFC, 0x01, 0x05 }; > > if (qcadev->btsoc_type == QCA_QCA6390) { > - if (test_bit(QCA_BT_OFF, &qca->flags) || > - !test_bit(HCI_RUNNING, &hdev->flags)) > + if (test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) { > + BT_INFO("QCA do not need to send EDL_RESET_REQ"); > return; > + } > + > + if (hci_dev_test_flag(hdev, HCI_SETUP)) { Commit msg does not help me at all to understand why you are changing the test bits. > + BT_INFO("QCA do not send EDL_RESET_REQ"); > + return; > + } > > + BT_INFO("QCA start to send EDL_RESET_REQ"); Why debugging info is part of the fix? Best regards, Krzysztof ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v1 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot 2024-04-18 16:48 ` Krzysztof Kozlowski @ 2024-04-18 20:34 ` quic_zijuhu 2024-04-18 20:58 ` Krzysztof Kozlowski 0 siblings, 1 reply; 75+ messages in thread From: quic_zijuhu @ 2024-04-18 20:34 UTC (permalink / raw) To: Krzysztof Kozlowski, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, wt, bartosz.golaszewski On 4/19/2024 12:48 AM, Krzysztof Kozlowski wrote: > On 18/04/2024 16:06, Zijun Hu wrote: >> From: Zijun Hu <zijuhu@qti.qualcomm.com> >> >> Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed >> serdev") will cause regression issue for QCA_QCA6390 if BT reset pin is >> not configured by DT or ACPI, the regression issue is that BT can't be >> enabled after disable then warm reboot, fixed by correcting conditions >> for sending the VSC reset controller within qca_serdev_shutdown(). > > I have trouble understanding what is the bug. Can you rephrase it? > Think about below sequences: cold reboot(power off then power on) -> Enable BT -> Disable BT -> Warm reboot -> Enable BT again ... BT is failed to be enabled after warm reboot. >> >> Fixes: 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") >> Reported-by: Wren Turkal <wt@penguintechs.org> >> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218726 >> Signed-off-by: Zijun Hu <zijuhu@qti.qualcomm.com> >> Tested-by: Wren Turkal <wt@penguintechs.org> >> --- >> drivers/bluetooth/hci_qca.c | 12 +++++++++--- >> 1 file changed, 9 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c >> index 160175a23a49..2a47a60ecc25 100644 >> --- a/drivers/bluetooth/hci_qca.c >> +++ b/drivers/bluetooth/hci_qca.c >> @@ -2437,15 +2437,21 @@ static void qca_serdev_shutdown(struct device *dev) >> struct qca_serdev *qcadev = serdev_device_get_drvdata(serdev); >> struct hci_uart *hu = &qcadev->serdev_hu; >> struct hci_dev *hdev = hu->hdev; >> - struct qca_data *qca = hu->priv; >> const u8 ibs_wake_cmd[] = { 0xFD }; >> const u8 edl_reset_soc_cmd[] = { 0x01, 0x00, 0xFC, 0x01, 0x05 }; >> >> if (qcadev->btsoc_type == QCA_QCA6390) { >> - if (test_bit(QCA_BT_OFF, &qca->flags) || >> - !test_bit(HCI_RUNNING, &hdev->flags)) >> + if (test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) { >> + BT_INFO("QCA do not need to send EDL_RESET_REQ"); >> return; >> + } >> + >> + if (hci_dev_test_flag(hdev, HCI_SETUP)) { > > Commit msg does not help me at all to understand why you are changing > the test bits. it is test bits not changing bits. > >> + BT_INFO("QCA do not send EDL_RESET_REQ"); >> + return; >> + } >> >> + BT_INFO("QCA start to send EDL_RESET_REQ"); > > Why debugging info is part of the fix? > they are reserved intentionally to print critical info. > Best regards, > Krzysztof > ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v1 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot 2024-04-18 20:34 ` quic_zijuhu @ 2024-04-18 20:58 ` Krzysztof Kozlowski 2024-04-18 22:05 ` quic_zijuhu 0 siblings, 1 reply; 75+ messages in thread From: Krzysztof Kozlowski @ 2024-04-18 20:58 UTC (permalink / raw) To: quic_zijuhu, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, wt, bartosz.golaszewski On 18/04/2024 22:34, quic_zijuhu wrote: > On 4/19/2024 12:48 AM, Krzysztof Kozlowski wrote: >> On 18/04/2024 16:06, Zijun Hu wrote: >>> From: Zijun Hu <zijuhu@qti.qualcomm.com> >>> >>> Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed >>> serdev") will cause regression issue for QCA_QCA6390 if BT reset pin is >>> not configured by DT or ACPI, the regression issue is that BT can't be >>> enabled after disable then warm reboot, fixed by correcting conditions >>> for sending the VSC reset controller within qca_serdev_shutdown(). >> >> I have trouble understanding what is the bug. Can you rephrase it? >> > Think about below sequences: > cold reboot(power off then power on) -> Enable BT -> Disable BT -> Warm reboot -> Enable BT again ... > BT is failed to be enabled after warm reboot. Still not. Please get someone to help you rephrase it. One long sentence is not good approach. Describe the problem, how it can be reproduced and then come with brief explanation how you fixed it (because it is not obvious to me). >>> >>> Fixes: 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") >>> Reported-by: Wren Turkal <wt@penguintechs.org> >>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218726 >>> Signed-off-by: Zijun Hu <zijuhu@qti.qualcomm.com> >>> Tested-by: Wren Turkal <wt@penguintechs.org> >>> --- >>> drivers/bluetooth/hci_qca.c | 12 +++++++++--- >>> 1 file changed, 9 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c >>> index 160175a23a49..2a47a60ecc25 100644 >>> --- a/drivers/bluetooth/hci_qca.c >>> +++ b/drivers/bluetooth/hci_qca.c >>> @@ -2437,15 +2437,21 @@ static void qca_serdev_shutdown(struct device *dev) >>> struct qca_serdev *qcadev = serdev_device_get_drvdata(serdev); >>> struct hci_uart *hu = &qcadev->serdev_hu; >>> struct hci_dev *hdev = hu->hdev; >>> - struct qca_data *qca = hu->priv; >>> const u8 ibs_wake_cmd[] = { 0xFD }; >>> const u8 edl_reset_soc_cmd[] = { 0x01, 0x00, 0xFC, 0x01, 0x05 }; >>> >>> if (qcadev->btsoc_type == QCA_QCA6390) { >>> - if (test_bit(QCA_BT_OFF, &qca->flags) || >>> - !test_bit(HCI_RUNNING, &hdev->flags)) >>> + if (test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) { >>> + BT_INFO("QCA do not need to send EDL_RESET_REQ"); >>> return; >>> + } >>> + >>> + if (hci_dev_test_flag(hdev, HCI_SETUP)) { >> >> Commit msg does not help me at all to understand why you are changing >> the test bits. > it is test bits not changing bits. Previously we tested bits for BT off and HCI running. Now not, so you changed the logic. Maybe it is correct, maybe not, I don't understand why. >> >>> + BT_INFO("QCA do not send EDL_RESET_REQ"); >>> + return; >>> + } >>> >>> + BT_INFO("QCA start to send EDL_RESET_REQ"); >> >> Why debugging info is part of the fix? >> > they are reserved intentionally to print critical info. No, it's downstream coding style. Please don't bring it upstream. Or explain why this deserves informing user. Drivers should be quiet mostly. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v1 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot 2024-04-18 20:58 ` Krzysztof Kozlowski @ 2024-04-18 22:05 ` quic_zijuhu 2024-04-18 22:38 ` Krzysztof Kozlowski 0 siblings, 1 reply; 75+ messages in thread From: quic_zijuhu @ 2024-04-18 22:05 UTC (permalink / raw) To: Krzysztof Kozlowski, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, wt, bartosz.golaszewski On 4/19/2024 4:58 AM, Krzysztof Kozlowski wrote: > On 18/04/2024 22:34, quic_zijuhu wrote: >> On 4/19/2024 12:48 AM, Krzysztof Kozlowski wrote: >>> On 18/04/2024 16:06, Zijun Hu wrote: >>>> From: Zijun Hu <zijuhu@qti.qualcomm.com> >>>> >>>> Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed >>>> serdev") will cause regression issue for QCA_QCA6390 if BT reset pin is >>>> not configured by DT or ACPI, the regression issue is that BT can't be >>>> enabled after disable then warm reboot, fixed by correcting conditions >>>> for sending the VSC reset controller within qca_serdev_shutdown(). >>> >>> I have trouble understanding what is the bug. Can you rephrase it? >>> >> Think about below sequences: >> cold reboot(power off then power on) -> Enable BT -> Disable BT -> Warm reboot -> Enable BT again ... >> BT is failed to be enabled after warm reboot. > > Still not. Please get someone to help you rephrase it. One long sentence > is not good approach. Describe the problem, how it can be reproduced and > then come with brief explanation how you fixed it (because it is not > obvious to me). > thanks for your suggestions. will optimize commit message based on your suggestions. >>>> >>>> Fixes: 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") >>>> Reported-by: Wren Turkal <wt@penguintechs.org> >>>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218726 >>>> Signed-off-by: Zijun Hu <zijuhu@qti.qualcomm.com> >>>> Tested-by: Wren Turkal <wt@penguintechs.org> >>>> --- >>>> drivers/bluetooth/hci_qca.c | 12 +++++++++--- >>>> 1 file changed, 9 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c >>>> index 160175a23a49..2a47a60ecc25 100644 >>>> --- a/drivers/bluetooth/hci_qca.c >>>> +++ b/drivers/bluetooth/hci_qca.c >>>> @@ -2437,15 +2437,21 @@ static void qca_serdev_shutdown(struct device *dev) >>>> struct qca_serdev *qcadev = serdev_device_get_drvdata(serdev); >>>> struct hci_uart *hu = &qcadev->serdev_hu; >>>> struct hci_dev *hdev = hu->hdev; >>>> - struct qca_data *qca = hu->priv; >>>> const u8 ibs_wake_cmd[] = { 0xFD }; >>>> const u8 edl_reset_soc_cmd[] = { 0x01, 0x00, 0xFC, 0x01, 0x05 }; >>>> >>>> if (qcadev->btsoc_type == QCA_QCA6390) { >>>> - if (test_bit(QCA_BT_OFF, &qca->flags) || >>>> - !test_bit(HCI_RUNNING, &hdev->flags)) >>>> + if (test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) { >>>> + BT_INFO("QCA do not need to send EDL_RESET_REQ"); >>>> return; >>>> + } >>>> + >>>> + if (hci_dev_test_flag(hdev, HCI_SETUP)) { >>> >>> Commit msg does not help me at all to understand why you are changing >>> the test bits. >> it is test bits not changing bits. > > Previously we tested bits for BT off and HCI running. Now not, so you > changed the logic. Maybe it is correct, maybe not, I don't understand why. > if HCI_QUIRK_NON_PERSISTENT_SETUP is set, it means we can and need to do initialization by calling hdev->setup() for every BT enable, so we don't need to send VSC to reset controller here. if HCI_QUIRK_NON_PERSISTENT_SETUP is cleared. it means we only can or need to do initialization for the first BT enable operation. if HCI_SETUP is set, that means we don't do any BT enable yet and the initialization operations are never performed. so we also don't need to send VSC any more. otherwise, we need to send VSC to reset controller since initialization have been Done regardless of BT state. for this case the serdev have still be opened. so it also don't meet the crash the 272970be3dab fixed. >>> >>>> + BT_INFO("QCA do not send EDL_RESET_REQ"); >>>> + return; >>>> + } >>>> >>>> + BT_INFO("QCA start to send EDL_RESET_REQ"); >>> >>> Why debugging info is part of the fix? >>> >> they are reserved intentionally to print critical info. > > No, it's downstream coding style. Please don't bring it upstream. Or > explain why this deserves informing user. Drivers should be quiet mostly. > > okay, will remove BT_INFO("QCA start to send EDL_RESET_REQ"); > > Best regards, > Krzysztof > ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v1 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot 2024-04-18 22:05 ` quic_zijuhu @ 2024-04-18 22:38 ` Krzysztof Kozlowski 2024-04-18 23:24 ` quic_zijuhu 0 siblings, 1 reply; 75+ messages in thread From: Krzysztof Kozlowski @ 2024-04-18 22:38 UTC (permalink / raw) To: quic_zijuhu, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, wt, bartosz.golaszewski On 19/04/2024 00:05, quic_zijuhu wrote: > On 4/19/2024 4:58 AM, Krzysztof Kozlowski wrote: >> On 18/04/2024 22:34, quic_zijuhu wrote: >>> On 4/19/2024 12:48 AM, Krzysztof Kozlowski wrote: >>>> On 18/04/2024 16:06, Zijun Hu wrote: >>>>> From: Zijun Hu <zijuhu@qti.qualcomm.com> >>>>> >>>>> Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed >>>>> serdev") will cause regression issue for QCA_QCA6390 if BT reset pin is >>>>> not configured by DT or ACPI, the regression issue is that BT can't be >>>>> enabled after disable then warm reboot, fixed by correcting conditions >>>>> for sending the VSC reset controller within qca_serdev_shutdown(). >>>> >>>> I have trouble understanding what is the bug. Can you rephrase it? >>>> >>> Think about below sequences: >>> cold reboot(power off then power on) -> Enable BT -> Disable BT -> Warm reboot -> Enable BT again ... >>> BT is failed to be enabled after warm reboot. >> >> Still not. Please get someone to help you rephrase it. One long sentence >> is not good approach. Describe the problem, how it can be reproduced and >> then come with brief explanation how you fixed it (because it is not >> obvious to me). >> > thanks for your suggestions. will optimize commit message based on your suggestions. >>>>> >>>>> Fixes: 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") >>>>> Reported-by: Wren Turkal <wt@penguintechs.org> >>>>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218726 >>>>> Signed-off-by: Zijun Hu <zijuhu@qti.qualcomm.com> >>>>> Tested-by: Wren Turkal <wt@penguintechs.org> >>>>> --- >>>>> drivers/bluetooth/hci_qca.c | 12 +++++++++--- >>>>> 1 file changed, 9 insertions(+), 3 deletions(-) >>>>> >>>>> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c >>>>> index 160175a23a49..2a47a60ecc25 100644 >>>>> --- a/drivers/bluetooth/hci_qca.c >>>>> +++ b/drivers/bluetooth/hci_qca.c >>>>> @@ -2437,15 +2437,21 @@ static void qca_serdev_shutdown(struct device *dev) >>>>> struct qca_serdev *qcadev = serdev_device_get_drvdata(serdev); >>>>> struct hci_uart *hu = &qcadev->serdev_hu; >>>>> struct hci_dev *hdev = hu->hdev; >>>>> - struct qca_data *qca = hu->priv; >>>>> const u8 ibs_wake_cmd[] = { 0xFD }; >>>>> const u8 edl_reset_soc_cmd[] = { 0x01, 0x00, 0xFC, 0x01, 0x05 }; >>>>> >>>>> if (qcadev->btsoc_type == QCA_QCA6390) { >>>>> - if (test_bit(QCA_BT_OFF, &qca->flags) || >>>>> - !test_bit(HCI_RUNNING, &hdev->flags)) >>>>> + if (test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) { >>>>> + BT_INFO("QCA do not need to send EDL_RESET_REQ"); >>>>> return; >>>>> + } >>>>> + >>>>> + if (hci_dev_test_flag(hdev, HCI_SETUP)) { >>>> >>>> Commit msg does not help me at all to understand why you are changing >>>> the test bits. >>> it is test bits not changing bits. >> >> Previously we tested bits for BT off and HCI running. Now not, so you >> changed the logic. Maybe it is correct, maybe not, I don't understand why. >> > if HCI_QUIRK_NON_PERSISTENT_SETUP is set, it means we can and need to do initialization > by calling hdev->setup() for every BT enable, so we don't need to send VSC to reset controller > here. > > if HCI_QUIRK_NON_PERSISTENT_SETUP is cleared. it means we only can or need to do initialization > for the first BT enable operation. if HCI_SETUP is set, that means we don't do any BT enable yet > and the initialization operations are never performed. so we also don't need to send VSC any more. > > otherwise, we need to send VSC to reset controller since initialization have been Done regardless of > BT state. for this case the serdev have still be opened. so it also don't meet the crash the 272970be3dab > fixed. Please read again what I request here: your change is not obvious and is not explained in commit msg. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v1 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot 2024-04-18 22:38 ` Krzysztof Kozlowski @ 2024-04-18 23:24 ` quic_zijuhu 0 siblings, 0 replies; 75+ messages in thread From: quic_zijuhu @ 2024-04-18 23:24 UTC (permalink / raw) To: Krzysztof Kozlowski, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, wt, bartosz.golaszewski On 4/19/2024 6:38 AM, Krzysztof Kozlowski wrote: > On 19/04/2024 00:05, quic_zijuhu wrote: >> On 4/19/2024 4:58 AM, Krzysztof Kozlowski wrote: >>> On 18/04/2024 22:34, quic_zijuhu wrote: >>>> On 4/19/2024 12:48 AM, Krzysztof Kozlowski wrote: >>>>> On 18/04/2024 16:06, Zijun Hu wrote: >>>>>> From: Zijun Hu <zijuhu@qti.qualcomm.com> >>>>>> >>>>>> Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed >>>>>> serdev") will cause regression issue for QCA_QCA6390 if BT reset pin is >>>>>> not configured by DT or ACPI, the regression issue is that BT can't be >>>>>> enabled after disable then warm reboot, fixed by correcting conditions >>>>>> for sending the VSC reset controller within qca_serdev_shutdown(). >>>>> >>>>> I have trouble understanding what is the bug. Can you rephrase it? >>>>> >>>> Think about below sequences: >>>> cold reboot(power off then power on) -> Enable BT -> Disable BT -> Warm reboot -> Enable BT again ... >>>> BT is failed to be enabled after warm reboot. >>> >>> Still not. Please get someone to help you rephrase it. One long sentence >>> is not good approach. Describe the problem, how it can be reproduced and >>> then come with brief explanation how you fixed it (because it is not >>> obvious to me). >>> >> thanks for your suggestions. will optimize commit message based on your suggestions. >>>>>> >>>>>> Fixes: 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") >>>>>> Reported-by: Wren Turkal <wt@penguintechs.org> >>>>>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218726 >>>>>> Signed-off-by: Zijun Hu <zijuhu@qti.qualcomm.com> >>>>>> Tested-by: Wren Turkal <wt@penguintechs.org> >>>>>> --- >>>>>> drivers/bluetooth/hci_qca.c | 12 +++++++++--- >>>>>> 1 file changed, 9 insertions(+), 3 deletions(-) >>>>>> >>>>>> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c >>>>>> index 160175a23a49..2a47a60ecc25 100644 >>>>>> --- a/drivers/bluetooth/hci_qca.c >>>>>> +++ b/drivers/bluetooth/hci_qca.c >>>>>> @@ -2437,15 +2437,21 @@ static void qca_serdev_shutdown(struct device *dev) >>>>>> struct qca_serdev *qcadev = serdev_device_get_drvdata(serdev); >>>>>> struct hci_uart *hu = &qcadev->serdev_hu; >>>>>> struct hci_dev *hdev = hu->hdev; >>>>>> - struct qca_data *qca = hu->priv; >>>>>> const u8 ibs_wake_cmd[] = { 0xFD }; >>>>>> const u8 edl_reset_soc_cmd[] = { 0x01, 0x00, 0xFC, 0x01, 0x05 }; >>>>>> >>>>>> if (qcadev->btsoc_type == QCA_QCA6390) { >>>>>> - if (test_bit(QCA_BT_OFF, &qca->flags) || >>>>>> - !test_bit(HCI_RUNNING, &hdev->flags)) >>>>>> + if (test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) { >>>>>> + BT_INFO("QCA do not need to send EDL_RESET_REQ"); >>>>>> return; >>>>>> + } >>>>>> + >>>>>> + if (hci_dev_test_flag(hdev, HCI_SETUP)) { >>>>> >>>>> Commit msg does not help me at all to understand why you are changing >>>>> the test bits. >>>> it is test bits not changing bits. >>> >>> Previously we tested bits for BT off and HCI running. Now not, so you >>> changed the logic. Maybe it is correct, maybe not, I don't understand why. >>> >> if HCI_QUIRK_NON_PERSISTENT_SETUP is set, it means we can and need to do initialization >> by calling hdev->setup() for every BT enable, so we don't need to send VSC to reset controller >> here. >> >> if HCI_QUIRK_NON_PERSISTENT_SETUP is cleared. it means we only can or need to do initialization >> for the first BT enable operation. if HCI_SETUP is set, that means we don't do any BT enable yet >> and the initialization operations are never performed. so we also don't need to send VSC any more. >> >> otherwise, we need to send VSC to reset controller since initialization have been Done regardless of >> BT state. for this case the serdev have still be opened. so it also don't meet the crash the 272970be3dab >> fixed. > > Please read again what I request here: your change is not obvious and is > not explained in commit msg. > > i don't explain much since these HCI_QUIRK_NON_PERSISTENT_SETUP and HCI_SETUP is generic flag. > > > Best regards, > Krzysztof > ^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH v1 0/2] Fix two regression issues for QCA controllers 2024-04-18 14:06 [PATCH v1 0/2] Fix two regression issues for QCA controllers Zijun Hu 2024-04-18 14:06 ` [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" Zijun Hu 2024-04-18 14:06 ` [PATCH v1 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot Zijun Hu @ 2024-04-19 21:48 ` Zijun Hu 2024-04-19 21:48 ` [PATCH v2 1/2] Bluetooth: MGMT: Fix failing to MGMT_OP_ADD_UUID/MGMT_OP_REMOVE_UUID Zijun Hu 2024-04-19 21:48 ` [PATCH v2 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Zijun Hu 2024-04-19 22:03 ` [PATCH v3 0/2] Fix two regression issues for QCA controllers Zijun Hu 3 siblings, 2 replies; 75+ messages in thread From: Zijun Hu @ 2024-04-19 21:48 UTC (permalink / raw) To: luiz.dentz, luiz.von.dentz, marcel Cc: quic_zijuhu, linux-bluetooth, bartosz.golaszewski, krzysztof.kozlowski, wt 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 the links for these issues are shown below: https://bugzilla.kernel.org/show_bug.cgi?id=218726 https://lore.kernel.org/linux-bluetooth/ea20bb9b-6b60-47fc-ae42-5eed918ad7b4@quicinc.com/T/#m73d6a71d2f454bb03588c66f3ef7912274d37c6f Zijun Hu (1): Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 drivers/bluetooth/hci_qca.c | 3 ++- net/bluetooth/mgmt.c | 20 +++++++++++++++----- 2 files changed, 17 insertions(+), 6 deletions(-) -- 2.7.4 ^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH v2 1/2] Bluetooth: MGMT: Fix failing to MGMT_OP_ADD_UUID/MGMT_OP_REMOVE_UUID 2024-04-19 21:48 ` [PATCH v1 0/2] Fix two regression issues for QCA controllers Zijun Hu @ 2024-04-19 21:48 ` Zijun Hu 2024-04-19 22:05 ` quic_zijuhu 2024-04-19 22:12 ` [v2,1/2] " bluez.test.bot 2024-04-19 21:48 ` [PATCH v2 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Zijun Hu 1 sibling, 2 replies; 75+ messages in thread From: Zijun Hu @ 2024-04-19 21:48 UTC (permalink / raw) To: luiz.dentz, luiz.von.dentz, marcel Cc: quic_zijuhu, linux-bluetooth, bartosz.golaszewski, krzysztof.kozlowski, wt From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> These commands don't require the adapter to be up and running so don't use hci_cmd_sync_queue which would check that flag, instead use hci_cmd_sync_submit which would ensure mgmt_class_complete is set properly regardless if any command was actually run or not. Link: https://github.com/bluez/bluez/issues/809 Fixes: d883a4669a1d ("Bluetooth: hci_sync: Only allow hci_cmd_sync_queue if running") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> --- net/bluetooth/mgmt.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c index 7129e70a0253..68deec968405 100644 --- a/net/bluetooth/mgmt.c +++ b/net/bluetooth/mgmt.c @@ -2623,7 +2623,11 @@ static int add_uuid(struct sock *sk, struct hci_dev *hdev, void *data, u16 len) goto failed; } - err = hci_cmd_sync_queue(hdev, add_uuid_sync, cmd, mgmt_class_complete); + /* MGMT_OP_ADD_UUID don't require adapter the UP/Running so use + * hci_cmd_sync_submit instead of hci_cmd_sync_queue. + */ + err = hci_cmd_sync_submit(hdev, add_uuid_sync, cmd, + mgmt_class_complete); if (err < 0) { mgmt_pending_free(cmd); goto failed; @@ -2717,8 +2721,11 @@ static int remove_uuid(struct sock *sk, struct hci_dev *hdev, void *data, goto unlock; } - err = hci_cmd_sync_queue(hdev, remove_uuid_sync, cmd, - mgmt_class_complete); + /* MGMT_OP_REMOVE_UUID don't require adapter the UP/Running so use + * hci_cmd_sync_submit instead of hci_cmd_sync_queue. + */ + err = hci_cmd_sync_submit(hdev, remove_uuid_sync, cmd, + mgmt_class_complete); if (err < 0) mgmt_pending_free(cmd); @@ -2784,8 +2791,11 @@ static int set_dev_class(struct sock *sk, struct hci_dev *hdev, void *data, goto unlock; } - err = hci_cmd_sync_queue(hdev, set_class_sync, cmd, - mgmt_class_complete); + /* MGMT_OP_SET_DEV_CLASS don't require adapter the UP/Running so use + * hci_cmd_sync_submit instead of hci_cmd_sync_queue. + */ + err = hci_cmd_sync_submit(hdev, set_class_sync, cmd, + mgmt_class_complete); if (err < 0) mgmt_pending_free(cmd); -- 2.7.4 ^ permalink raw reply related [flat|nested] 75+ messages in thread
* Re: [PATCH v2 1/2] Bluetooth: MGMT: Fix failing to MGMT_OP_ADD_UUID/MGMT_OP_REMOVE_UUID 2024-04-19 21:48 ` [PATCH v2 1/2] Bluetooth: MGMT: Fix failing to MGMT_OP_ADD_UUID/MGMT_OP_REMOVE_UUID Zijun Hu @ 2024-04-19 22:05 ` quic_zijuhu 2024-04-19 22:12 ` [v2,1/2] " bluez.test.bot 1 sibling, 0 replies; 75+ messages in thread From: quic_zijuhu @ 2024-04-19 22:05 UTC (permalink / raw) To: luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, krzysztof.kozlowski, wt On 4/20/2024 5:48 AM, Zijun Hu wrote: > From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> > > These commands don't require the adapter to be up and running so don't > use hci_cmd_sync_queue which would check that flag, instead use > hci_cmd_sync_submit which would ensure mgmt_class_complete is set > properly regardless if any command was actually run or not. > > Link: https://github.com/bluez/bluez/issues/809 > Fixes: d883a4669a1d ("Bluetooth: hci_sync: Only allow hci_cmd_sync_queue if running") > Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> > --- > net/bluetooth/mgmt.c | 20 +++++++++++++++----- > 1 file changed, 15 insertions(+), 5 deletions(-) > > diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c > index 7129e70a0253..68deec968405 100644 > --- a/net/bluetooth/mgmt.c > +++ b/net/bluetooth/mgmt.c > @@ -2623,7 +2623,11 @@ static int add_uuid(struct sock *sk, struct hci_dev *hdev, void *data, u16 len) > goto failed; > } > > - err = hci_cmd_sync_queue(hdev, add_uuid_sync, cmd, mgmt_class_complete); > + /* MGMT_OP_ADD_UUID don't require adapter the UP/Running so use > + * hci_cmd_sync_submit instead of hci_cmd_sync_queue. > + */ > + err = hci_cmd_sync_submit(hdev, add_uuid_sync, cmd, > + mgmt_class_complete); > if (err < 0) { > mgmt_pending_free(cmd); > goto failed; > @@ -2717,8 +2721,11 @@ static int remove_uuid(struct sock *sk, struct hci_dev *hdev, void *data, > goto unlock; > } > > - err = hci_cmd_sync_queue(hdev, remove_uuid_sync, cmd, > - mgmt_class_complete); > + /* MGMT_OP_REMOVE_UUID don't require adapter the UP/Running so use > + * hci_cmd_sync_submit instead of hci_cmd_sync_queue. > + */ > + err = hci_cmd_sync_submit(hdev, remove_uuid_sync, cmd, > + mgmt_class_complete); > if (err < 0) > mgmt_pending_free(cmd); > > @@ -2784,8 +2791,11 @@ static int set_dev_class(struct sock *sk, struct hci_dev *hdev, void *data, > goto unlock; > } > > - err = hci_cmd_sync_queue(hdev, set_class_sync, cmd, > - mgmt_class_complete); > + /* MGMT_OP_SET_DEV_CLASS don't require adapter the UP/Running so use > + * hci_cmd_sync_submit instead of hci_cmd_sync_queue. > + */ > + err = hci_cmd_sync_submit(hdev, set_class_sync, cmd, > + mgmt_class_complete); > if (err < 0) > mgmt_pending_free(cmd); > sorry to send wrong patch sets please ignore it. ^ permalink raw reply [flat|nested] 75+ messages in thread
* RE: [v2,1/2] Bluetooth: MGMT: Fix failing to MGMT_OP_ADD_UUID/MGMT_OP_REMOVE_UUID 2024-04-19 21:48 ` [PATCH v2 1/2] Bluetooth: MGMT: Fix failing to MGMT_OP_ADD_UUID/MGMT_OP_REMOVE_UUID Zijun Hu 2024-04-19 22:05 ` quic_zijuhu @ 2024-04-19 22:12 ` bluez.test.bot 1 sibling, 0 replies; 75+ messages in thread From: bluez.test.bot @ 2024-04-19 22:12 UTC (permalink / raw) To: linux-bluetooth, quic_zijuhu [-- Attachment #1: Type: text/plain, Size: 543 bytes --] This is an automated email and please do not reply to this email. Dear Submitter, Thank you for submitting the patches to the linux bluetooth mailing list. While preparing the CI tests, the patches you submitted couldn't be applied to the current HEAD of the repository. ----- Output ----- error: patch failed: net/bluetooth/mgmt.c:2623 error: net/bluetooth/mgmt.c: patch does not apply hint: Use 'git am --show-current-patch' to see the failed patch Please resolve the issue and submit the patches again. --- Regards, Linux Bluetooth ^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH v2 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 2024-04-19 21:48 ` [PATCH v1 0/2] Fix two regression issues for QCA controllers Zijun Hu 2024-04-19 21:48 ` [PATCH v2 1/2] Bluetooth: MGMT: Fix failing to MGMT_OP_ADD_UUID/MGMT_OP_REMOVE_UUID Zijun Hu @ 2024-04-19 21:48 ` Zijun Hu 2024-04-19 22:06 ` quic_zijuhu 1 sibling, 1 reply; 75+ messages in thread From: Zijun Hu @ 2024-04-19 21:48 UTC (permalink / raw) To: luiz.dentz, luiz.von.dentz, marcel Cc: quic_zijuhu, linux-bluetooth, bartosz.golaszewski, krzysztof.kozlowski, wt Commit 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()") will cause below serious regression issue: BT can't be enabled any more after below steps: cold boot -> enable BT -> disable BT -> BT enable failure if BT reset pin is not configured within DT|ACPI for QCA_QCA6390. The mentioned commit wrongly set quirk HCI_QUIRK_NON_PERSISTENT_SETUP within qca_serdev_probe() for this case and cause this serious issue. Fixed by reverting the mentioned commit for QCA_QCA6390. Fixes: 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()") Reported-by: Wren Turkal <wt@penguintechs.org> Link: https://bugzilla.kernel.org/show_bug.cgi?id=218726 Link: https://lore.kernel.org/linux-bluetooth/ea20bb9b-6b60-47fc-ae42-5eed918ad7b4@quicinc.com/T/#m73d6a71d2f454bb03588c66f3ef7912274d37c6f Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Tested-by: Wren Turkal <wt@penguintechs.org> --- drivers/bluetooth/hci_qca.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index 92fa20f5ac7d..0934e74112a6 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -2357,7 +2357,8 @@ static int qca_serdev_probe(struct serdev_device *serdev) if (IS_ERR(qcadev->bt_en)) { dev_warn(&serdev->dev, "failed to acquire enable gpio\n"); power_ctrl_enabled = false; - } + } else if (!qcadev->bt_en && qcadev->btsoc_type == QCA_QCA6390) + power_ctrl_enabled = false; qcadev->susclk = devm_clk_get_optional(&serdev->dev, NULL); if (IS_ERR(qcadev->susclk)) { -- 2.7.4 ^ permalink raw reply related [flat|nested] 75+ messages in thread
* Re: [PATCH v2 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 2024-04-19 21:48 ` [PATCH v2 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Zijun Hu @ 2024-04-19 22:06 ` quic_zijuhu 0 siblings, 0 replies; 75+ messages in thread From: quic_zijuhu @ 2024-04-19 22:06 UTC (permalink / raw) To: luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, krzysztof.kozlowski, wt On 4/20/2024 5:48 AM, Zijun Hu wrote: > Commit 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() > with gpiod_get_optional()") will cause below serious regression issue: > > BT can't be enabled any more after below steps: > cold boot -> enable BT -> disable BT -> BT enable failure > if BT reset pin is not configured within DT|ACPI for QCA_QCA6390. > > The mentioned commit wrongly set quirk HCI_QUIRK_NON_PERSISTENT_SETUP > within qca_serdev_probe() for this case and cause this serious issue. > > Fixed by reverting the mentioned commit for QCA_QCA6390. > > Fixes: 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()") > Reported-by: Wren Turkal <wt@penguintechs.org> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=218726 > Link: https://lore.kernel.org/linux-bluetooth/ea20bb9b-6b60-47fc-ae42-5eed918ad7b4@quicinc.com/T/#m73d6a71d2f454bb03588c66f3ef7912274d37c6f > Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> > Tested-by: Wren Turkal <wt@penguintechs.org> > --- > drivers/bluetooth/hci_qca.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c > index 92fa20f5ac7d..0934e74112a6 100644 > --- a/drivers/bluetooth/hci_qca.c > +++ b/drivers/bluetooth/hci_qca.c > @@ -2357,7 +2357,8 @@ static int qca_serdev_probe(struct serdev_device *serdev) > if (IS_ERR(qcadev->bt_en)) { > dev_warn(&serdev->dev, "failed to acquire enable gpio\n"); > power_ctrl_enabled = false; > - } > + } else if (!qcadev->bt_en && qcadev->btsoc_type == QCA_QCA6390) > + power_ctrl_enabled = false; > > qcadev->susclk = devm_clk_get_optional(&serdev->dev, NULL); > if (IS_ERR(qcadev->susclk)) { sorry to send wrong patch sets please ignore it. have send right v3 patch sets ^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH v3 0/2] Fix two regression issues for QCA controllers 2024-04-18 14:06 [PATCH v1 0/2] Fix two regression issues for QCA controllers Zijun Hu ` (2 preceding siblings ...) 2024-04-19 21:48 ` [PATCH v1 0/2] Fix two regression issues for QCA controllers Zijun Hu @ 2024-04-19 22:03 ` Zijun Hu 2024-04-19 22:03 ` [PATCH v3 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Zijun Hu ` (3 more replies) 3 siblings, 4 replies; 75+ messages in thread From: Zijun Hu @ 2024-04-19 22:03 UTC (permalink / raw) To: luiz.dentz, luiz.von.dentz, marcel Cc: quic_zijuhu, linux-bluetooth, bartosz.golaszewski, krzysztof.kozlowski, wt 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 the links for these issues are shown below: https://bugzilla.kernel.org/show_bug.cgi?id=218726 https://lore.kernel.org/linux-bluetooth/ea20bb9b-6b60-47fc-ae42-5eed918ad7b4@quicinc.com/T/#m73d6a71d2f454bb03588c66f3ef7912274d37c6f Zijun Hu (2): Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot drivers/bluetooth/hci_qca.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) -- 2.7.4 ^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH v3 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 2024-04-19 22:03 ` [PATCH v3 0/2] Fix two regression issues for QCA controllers Zijun Hu @ 2024-04-19 22:03 ` Zijun Hu 2024-04-19 22:30 ` Fix two regression issues for QCA controllers bluez.test.bot 2024-04-20 11:03 ` [PATCH v3 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Krzysztof Kozlowski 2024-04-19 22:03 ` [PATCH v3 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot Zijun Hu ` (2 subsequent siblings) 3 siblings, 2 replies; 75+ messages in thread From: Zijun Hu @ 2024-04-19 22:03 UTC (permalink / raw) To: luiz.dentz, luiz.von.dentz, marcel Cc: quic_zijuhu, linux-bluetooth, bartosz.golaszewski, krzysztof.kozlowski, wt Commit 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()") will cause below serious regression issue: BT can't be enabled any more after below steps: cold boot -> enable BT -> disable BT -> BT enable failure if BT reset pin is not configured within DT|ACPI for QCA_QCA6390. The mentioned commit wrongly set quirk HCI_QUIRK_NON_PERSISTENT_SETUP within qca_serdev_probe() for this case and cause this serious issue. Fixed by reverting the mentioned commit for QCA_QCA6390. Fixes: 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()") Reported-by: Wren Turkal <wt@penguintechs.org> Link: https://bugzilla.kernel.org/show_bug.cgi?id=218726 Link: https://lore.kernel.org/linux-bluetooth/ea20bb9b-6b60-47fc-ae42-5eed918ad7b4@quicinc.com/T/#m73d6a71d2f454bb03588c66f3ef7912274d37c6f Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Tested-by: Wren Turkal <wt@penguintechs.org> --- drivers/bluetooth/hci_qca.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index 92fa20f5ac7d..0934e74112a6 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -2357,7 +2357,8 @@ static int qca_serdev_probe(struct serdev_device *serdev) if (IS_ERR(qcadev->bt_en)) { dev_warn(&serdev->dev, "failed to acquire enable gpio\n"); power_ctrl_enabled = false; - } + } else if (!qcadev->bt_en && qcadev->btsoc_type == QCA_QCA6390) + power_ctrl_enabled = false; qcadev->susclk = devm_clk_get_optional(&serdev->dev, NULL); if (IS_ERR(qcadev->susclk)) { -- 2.7.4 ^ permalink raw reply related [flat|nested] 75+ messages in thread
* RE: Fix two regression issues for QCA controllers 2024-04-19 22:03 ` [PATCH v3 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Zijun Hu @ 2024-04-19 22:30 ` bluez.test.bot 2024-04-20 11:03 ` [PATCH v3 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Krzysztof Kozlowski 1 sibling, 0 replies; 75+ messages in thread From: bluez.test.bot @ 2024-04-19 22:30 UTC (permalink / raw) To: linux-bluetooth, quic_zijuhu [-- Attachment #1: Type: text/plain, Size: 4824 bytes --] This is automated email and please do not reply to this email! Dear submitter, Thank you for submitting the patches to the linux bluetooth mailing list. This is a CI test results with your patch series: PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=846241 ---Test result--- Test Summary: CheckPatch FAIL 1.55 seconds GitLint FAIL 1.15 seconds SubjectPrefix PASS 0.24 seconds BuildKernel PASS 29.65 seconds CheckAllWarning PASS 32.54 seconds CheckSparse PASS 37.97 seconds CheckSmatch FAIL 35.74 seconds BuildKernel32 PASS 28.71 seconds TestRunnerSetup PASS 515.72 seconds TestRunner_l2cap-tester PASS 18.28 seconds TestRunner_iso-tester PASS 28.86 seconds TestRunner_bnep-tester PASS 4.67 seconds TestRunner_mgmt-tester FAIL 108.91 seconds TestRunner_rfcomm-tester PASS 7.24 seconds TestRunner_sco-tester PASS 14.94 seconds TestRunner_ioctl-tester PASS 7.64 seconds TestRunner_mesh-tester PASS 5.74 seconds TestRunner_smp-tester PASS 6.80 seconds TestRunner_userchan-tester PASS 4.87 seconds IncrementalBuild PASS 33.04 seconds Details ############################## Test: CheckPatch - FAIL Desc: Run checkpatch.pl script Output: [v3,1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 WARNING: Reported-by: should be immediately followed by Closes: with a URL to the report #112: Reported-by: Wren Turkal <wt@penguintechs.org> Link: https://bugzilla.kernel.org/show_bug.cgi?id=218726 total: 0 errors, 1 warnings, 9 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. /github/workspace/src/src/13636786.patch has style problems, please review. NOTE: Ignored message types: UNKNOWN_COMMIT_ID NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. ############################## Test: GitLint - FAIL Desc: Run gitlint Output: [v3,1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search 17: B1 Line exceeds max length (139>80): "Link: https://lore.kernel.org/linux-bluetooth/ea20bb9b-6b60-47fc-ae42-5eed918ad7b4@quicinc.com/T/#m73d6a71d2f454bb03588c66f3ef7912274d37c6f" [v3,2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search 1: T1 Title exceeds max length (93>80): "[v3,2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot" ############################## Test: CheckSmatch - FAIL Desc: Run smatch tool with source Output: Segmentation fault (core dumped) make[4]: *** [scripts/Makefile.build:244: net/bluetooth/hci_core.o] Error 139 make[4]: *** Deleting file 'net/bluetooth/hci_core.o' make[3]: *** [scripts/Makefile.build:485: net/bluetooth] Error 2 make[2]: *** [scripts/Makefile.build:485: net] Error 2 make[2]: *** Waiting for unfinished jobs.... Segmentation fault (core dumped) make[4]: *** [scripts/Makefile.build:244: drivers/bluetooth/bcm203x.o] Error 139 make[4]: *** Deleting file 'drivers/bluetooth/bcm203x.o' make[4]: *** Waiting for unfinished jobs.... Segmentation fault (core dumped) make[4]: *** [scripts/Makefile.build:244: drivers/bluetooth/bpa10x.o] Error 139 make[4]: *** Deleting file 'drivers/bluetooth/bpa10x.o' make[3]: *** [scripts/Makefile.build:485: drivers/bluetooth] Error 2 make[2]: *** [scripts/Makefile.build:485: drivers] Error 2 make[1]: *** [/github/workspace/src/src/Makefile:1919: .] Error 2 make: *** [Makefile:240: __sub-make] Error 2 ############################## Test: TestRunner_mgmt-tester - FAIL Desc: Run mgmt-tester with test-runner Output: Total: 492, Passed: 489 (99.4%), Failed: 1, Not Run: 2 Failed Test Cases LL Privacy - Add Device 7 (AL is full) Failed 0.191 seconds --- Regards, Linux Bluetooth ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v3 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 2024-04-19 22:03 ` [PATCH v3 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Zijun Hu 2024-04-19 22:30 ` Fix two regression issues for QCA controllers bluez.test.bot @ 2024-04-20 11:03 ` Krzysztof Kozlowski 2024-04-20 21:28 ` quic_zijuhu 1 sibling, 1 reply; 75+ messages in thread From: Krzysztof Kozlowski @ 2024-04-20 11:03 UTC (permalink / raw) To: Zijun Hu, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, wt On 20/04/2024 00:03, Zijun Hu wrote: > Commit 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() > with gpiod_get_optional()") will cause below serious regression issue: > > BT can't be enabled any more after below steps: > cold boot -> enable BT -> disable BT -> BT enable failure > if BT reset pin is not configured within DT|ACPI for QCA_QCA6390. > > The mentioned commit wrongly set quirk HCI_QUIRK_NON_PERSISTENT_SETUP > within qca_serdev_probe() for this case and cause this serious issue. > > Fixed by reverting the mentioned commit for QCA_QCA6390. > > Fixes: 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()") > Reported-by: Wren Turkal <wt@penguintechs.org> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=218726 > Link: https://lore.kernel.org/linux-bluetooth/ea20bb9b-6b60-47fc-ae42-5eed918ad7b4@quicinc.com/T/#m73d6a71d2f454bb03588c66f3ef7912274d37c6f > Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> > Tested-by: Wren Turkal <wt@penguintechs.org> > --- > drivers/bluetooth/hci_qca.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c > index 92fa20f5ac7d..0934e74112a6 100644 > --- a/drivers/bluetooth/hci_qca.c > +++ b/drivers/bluetooth/hci_qca.c > @@ -2357,7 +2357,8 @@ static int qca_serdev_probe(struct serdev_device *serdev) > if (IS_ERR(qcadev->bt_en)) { > dev_warn(&serdev->dev, "failed to acquire enable gpio\n"); > power_ctrl_enabled = false; > - } > + } else if (!qcadev->bt_en && qcadev->btsoc_type == QCA_QCA6390) > + power_ctrl_enabled = false; > Please use kernel coding style, so {}. Please run scripts/checkpatch.pl and fix reported warnings. Then please run `scripts/checkpatch.pl --strict` and (probably) fix more warnings. Some warnings can be ignored, especially from --strict run, but the code here looks like it needs a fix. Feel free to get in touch if the warning is not clear. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v3 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 2024-04-20 11:03 ` [PATCH v3 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Krzysztof Kozlowski @ 2024-04-20 21:28 ` quic_zijuhu 0 siblings, 0 replies; 75+ messages in thread From: quic_zijuhu @ 2024-04-20 21:28 UTC (permalink / raw) To: Krzysztof Kozlowski, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, wt On 4/20/2024 7:03 PM, Krzysztof Kozlowski wrote: > On 20/04/2024 00:03, Zijun Hu wrote: >> Commit 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() >> with gpiod_get_optional()") will cause below serious regression issue: >> >> BT can't be enabled any more after below steps: >> cold boot -> enable BT -> disable BT -> BT enable failure >> if BT reset pin is not configured within DT|ACPI for QCA_QCA6390. >> >> The mentioned commit wrongly set quirk HCI_QUIRK_NON_PERSISTENT_SETUP >> within qca_serdev_probe() for this case and cause this serious issue. >> >> Fixed by reverting the mentioned commit for QCA_QCA6390. >> >> Fixes: 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()") >> Reported-by: Wren Turkal <wt@penguintechs.org> >> Link: https://bugzilla.kernel.org/show_bug.cgi?id=218726 >> Link: https://lore.kernel.org/linux-bluetooth/ea20bb9b-6b60-47fc-ae42-5eed918ad7b4@quicinc.com/T/#m73d6a71d2f454bb03588c66f3ef7912274d37c6f >> Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> >> Tested-by: Wren Turkal <wt@penguintechs.org> >> --- >> drivers/bluetooth/hci_qca.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c >> index 92fa20f5ac7d..0934e74112a6 100644 >> --- a/drivers/bluetooth/hci_qca.c >> +++ b/drivers/bluetooth/hci_qca.c >> @@ -2357,7 +2357,8 @@ static int qca_serdev_probe(struct serdev_device *serdev) >> if (IS_ERR(qcadev->bt_en)) { >> dev_warn(&serdev->dev, "failed to acquire enable gpio\n"); >> power_ctrl_enabled = false; >> - } >> + } else if (!qcadev->bt_en && qcadev->btsoc_type == QCA_QCA6390) >> + power_ctrl_enabled = false; >> > > Please use kernel coding style, so {}. > i will correct based on your suggest even if "checkpatch.pl --strict" don't give any warnings for present code style. > Please run scripts/checkpatch.pl and fix reported warnings. Then please > run `scripts/checkpatch.pl --strict` and (probably) fix more warnings. > Some warnings can be ignored, especially from --strict run, but the code > here looks like it needs a fix. Feel free to get in touch if the warning > is not clear. > the only warnings is that "WARNING: Reported-by: should be immediately followed by Closes:" we don't need to handle this warning for this case. > Best regards, > Krzysztof > > ^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH v3 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot 2024-04-19 22:03 ` [PATCH v3 0/2] Fix two regression issues for QCA controllers Zijun Hu 2024-04-19 22:03 ` [PATCH v3 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Zijun Hu @ 2024-04-19 22:03 ` Zijun Hu 2024-04-20 11:07 ` Krzysztof Kozlowski 2024-04-20 11:01 ` [PATCH v3 0/2] Fix two regression issues for QCA controllers Krzysztof Kozlowski 2024-04-20 22:06 ` [PATCH v4 " Zijun Hu 3 siblings, 1 reply; 75+ messages in thread From: Zijun Hu @ 2024-04-19 22:03 UTC (permalink / raw) To: luiz.dentz, luiz.von.dentz, marcel Cc: quic_zijuhu, linux-bluetooth, bartosz.golaszewski, krzysztof.kozlowski, wt From: Zijun Hu <zijuhu@qti.qualcomm.com> 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 BT reset pin is not configured within DT|ACPI for QCA_QCA6390. Fixed by sending the VSC to reset controller within qca_serdev_shutdown() once BT was ever enabled. Fixes: 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") Reported-by: Wren Turkal <wt@penguintechs.org> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218726 Signed-off-by: Zijun Hu <zijuhu@qti.qualcomm.com> Tested-by: Wren Turkal <wt@penguintechs.org> --- drivers/bluetooth/hci_qca.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index 0934e74112a6..3f5173f1180b 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -2438,13 +2438,12 @@ static void qca_serdev_shutdown(struct device *dev) struct qca_serdev *qcadev = serdev_device_get_drvdata(serdev); struct hci_uart *hu = &qcadev->serdev_hu; struct hci_dev *hdev = hu->hdev; - struct qca_data *qca = hu->priv; const u8 ibs_wake_cmd[] = { 0xFD }; const u8 edl_reset_soc_cmd[] = { 0x01, 0x00, 0xFC, 0x01, 0x05 }; if (qcadev->btsoc_type == QCA_QCA6390) { - if (test_bit(QCA_BT_OFF, &qca->flags) || - !test_bit(HCI_RUNNING, &hdev->flags)) + if (test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks) || + hci_dev_test_flag(hdev, HCI_SETUP)) return; serdev_device_write_flush(serdev); -- 2.7.4 ^ permalink raw reply related [flat|nested] 75+ messages in thread
* Re: [PATCH v3 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot 2024-04-19 22:03 ` [PATCH v3 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot Zijun Hu @ 2024-04-20 11:07 ` Krzysztof Kozlowski 2024-04-20 21:42 ` quic_zijuhu 0 siblings, 1 reply; 75+ messages in thread From: Krzysztof Kozlowski @ 2024-04-20 11:07 UTC (permalink / raw) To: Zijun Hu, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, wt On 20/04/2024 00:03, Zijun Hu wrote: > From: Zijun Hu <zijuhu@qti.qualcomm.com> > > 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 BT reset pin is not configured within DT|ACPI for QCA_QCA6390. Please mention if QCA6390 requires reset pin, according to datasheet or some hardware guideline. > > Fixed by sending the VSC to reset controller within qca_serdev_shutdown() > once BT was ever enabled. > > Fixes: 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") > Reported-by: Wren Turkal <wt@penguintechs.org> > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218726 > Signed-off-by: Zijun Hu <zijuhu@qti.qualcomm.com> > Tested-by: Wren Turkal <wt@penguintechs.org> > --- > drivers/bluetooth/hci_qca.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c > index 0934e74112a6..3f5173f1180b 100644 > --- a/drivers/bluetooth/hci_qca.c > +++ b/drivers/bluetooth/hci_qca.c > @@ -2438,13 +2438,12 @@ static void qca_serdev_shutdown(struct device *dev) > struct qca_serdev *qcadev = serdev_device_get_drvdata(serdev); > struct hci_uart *hu = &qcadev->serdev_hu; > struct hci_dev *hdev = hu->hdev; > - struct qca_data *qca = hu->priv; > const u8 ibs_wake_cmd[] = { 0xFD }; > const u8 edl_reset_soc_cmd[] = { 0x01, 0x00, 0xFC, 0x01, 0x05 }; > > if (qcadev->btsoc_type == QCA_QCA6390) { > - if (test_bit(QCA_BT_OFF, &qca->flags) || > - !test_bit(HCI_RUNNING, &hdev->flags)) > + if (test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks) || > + hci_dev_test_flag(hdev, HCI_SETUP)) > return; I am sorry, but why do we need to perform shutdown procedure now if device is off? I raised questions about this and I still don't understand. Not much got better comparing to previous version. Actually, I have no clue what changed. Where is the changelog? Best regards, Krzysztof ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v3 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot 2024-04-20 11:07 ` Krzysztof Kozlowski @ 2024-04-20 21:42 ` quic_zijuhu 0 siblings, 0 replies; 75+ messages in thread From: quic_zijuhu @ 2024-04-20 21:42 UTC (permalink / raw) To: Krzysztof Kozlowski, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, wt On 4/20/2024 7:07 PM, Krzysztof Kozlowski wrote: > On 20/04/2024 00:03, Zijun Hu wrote: >> From: Zijun Hu <zijuhu@qti.qualcomm.com> >> >> 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 BT reset pin is not configured within DT|ACPI for QCA_QCA6390. > > Please mention if QCA6390 requires reset pin, according to datasheet or > some hardware guideline. > will update commit message. >> >> Fixed by sending the VSC to reset controller within qca_serdev_shutdown() >> once BT was ever enabled. >> >> Fixes: 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") >> Reported-by: Wren Turkal <wt@penguintechs.org> >> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218726 >> Signed-off-by: Zijun Hu <zijuhu@qti.qualcomm.com> >> Tested-by: Wren Turkal <wt@penguintechs.org> >> --- >> drivers/bluetooth/hci_qca.c | 5 ++--- >> 1 file changed, 2 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c >> index 0934e74112a6..3f5173f1180b 100644 >> --- a/drivers/bluetooth/hci_qca.c >> +++ b/drivers/bluetooth/hci_qca.c >> @@ -2438,13 +2438,12 @@ static void qca_serdev_shutdown(struct device *dev) >> struct qca_serdev *qcadev = serdev_device_get_drvdata(serdev); >> struct hci_uart *hu = &qcadev->serdev_hu; >> struct hci_dev *hdev = hu->hdev; >> - struct qca_data *qca = hu->priv; >> const u8 ibs_wake_cmd[] = { 0xFD }; >> const u8 edl_reset_soc_cmd[] = { 0x01, 0x00, 0xFC, 0x01, 0x05 }; >> >> if (qcadev->btsoc_type == QCA_QCA6390) { >> - if (test_bit(QCA_BT_OFF, &qca->flags) || >> - !test_bit(HCI_RUNNING, &hdev->flags)) >> + if (test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks) || >> + hci_dev_test_flag(hdev, HCI_SETUP)) >> return; > > I am sorry, but why do we need to perform shutdown procedure now if > device is off? > this is shutdown of serdev and not hdev's shutdown. > I raised questions about this and I still don't understand. Not much got > better comparing to previous version. Actually, I have no clue what > changed. Where is the changelog? > my reply at below link will help you https://lore.kernel.org/all/fe1a0e3b-3408-4a33-90e9-d4ffcfc7a99b@quicinc.com/ > > Best regards, > Krzysztof > ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v3 0/2] Fix two regression issues for QCA controllers 2024-04-19 22:03 ` [PATCH v3 0/2] Fix two regression issues for QCA controllers Zijun Hu 2024-04-19 22:03 ` [PATCH v3 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Zijun Hu 2024-04-19 22:03 ` [PATCH v3 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot Zijun Hu @ 2024-04-20 11:01 ` Krzysztof Kozlowski 2024-04-22 7:44 ` Krzysztof Kozlowski 2024-04-20 22:06 ` [PATCH v4 " Zijun Hu 3 siblings, 1 reply; 75+ messages in thread From: Krzysztof Kozlowski @ 2024-04-20 11:01 UTC (permalink / raw) To: Zijun Hu, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, wt On 20/04/2024 00:03, 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 > > the links for these issues are shown below: > https://bugzilla.kernel.org/show_bug.cgi?id=218726 > https://lore.kernel.org/linux-bluetooth/ea20 Provide changelog, either in cover letter or in individual patches under ---. Do not attach (thread) your patchsets to some other threads (unrelated or older versions). This buries them deep in the mailbox and might interfere with applying entire sets. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v3 0/2] Fix two regression issues for QCA controllers 2024-04-20 11:01 ` [PATCH v3 0/2] Fix two regression issues for QCA controllers Krzysztof Kozlowski @ 2024-04-22 7:44 ` Krzysztof Kozlowski 2024-04-22 8:07 ` quic_zijuhu 0 siblings, 1 reply; 75+ messages in thread From: Krzysztof Kozlowski @ 2024-04-22 7:44 UTC (permalink / raw) To: Zijun Hu, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, wt On 20/04/2024 13:01, Krzysztof Kozlowski wrote: > On 20/04/2024 00:03, 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 >> >> the links for these issues are shown below: >> https://bugzilla.kernel.org/show_bug.cgi?id=218726 >> https://lore.kernel.org/linux-bluetooth/ea20 > > > Provide changelog, either in cover letter or in individual patches under > ---. > > Do not attach (thread) your patchsets to some other threads (unrelated > or older versions). This buries them deep in the mailbox and might > interfere with applying entire sets. > How did you implement these two feedbacks? v4 and v5 are still bad. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v3 0/2] Fix two regression issues for QCA controllers 2024-04-22 7:44 ` Krzysztof Kozlowski @ 2024-04-22 8:07 ` quic_zijuhu 2024-04-22 8:11 ` Krzysztof Kozlowski 0 siblings, 1 reply; 75+ messages in thread From: quic_zijuhu @ 2024-04-22 8:07 UTC (permalink / raw) To: Krzysztof Kozlowski, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, wt On 4/22/2024 3:44 PM, Krzysztof Kozlowski wrote: > On 20/04/2024 13:01, Krzysztof Kozlowski wrote: >> On 20/04/2024 00:03, 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 >>> >>> the links for these issues are shown below: >>> https://bugzilla.kernel.org/show_bug.cgi?id=218726 >>> https://lore.kernel.org/linux-bluetooth/ea20 >> >> >> Provide changelog, either in cover letter or in individual patches under >> ---. >> >> Do not attach (thread) your patchsets to some other threads (unrelated >> or older versions). This buries them deep in the mailbox and might >> interfere with applying entire sets. >> > sorry, not notice this. in order to send vN patch sets. do i need to --in-reply-to v(N-1) cover letter or v0 cover-letter ? > How did you implement these two feedbacks? > actually. i don't understand that two feedbacks so ask above questions. > v4 and v5 are still bad. > > Best regards, > Krzysztof > ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v3 0/2] Fix two regression issues for QCA controllers 2024-04-22 8:07 ` quic_zijuhu @ 2024-04-22 8:11 ` Krzysztof Kozlowski 2024-04-22 8:21 ` quic_zijuhu 0 siblings, 1 reply; 75+ messages in thread From: Krzysztof Kozlowski @ 2024-04-22 8:11 UTC (permalink / raw) To: quic_zijuhu, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, wt On 22/04/2024 10:07, quic_zijuhu wrote: > On 4/22/2024 3:44 PM, Krzysztof Kozlowski wrote: >> On 20/04/2024 13:01, Krzysztof Kozlowski wrote: >>> On 20/04/2024 00:03, 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 >>>> >>>> the links for these issues are shown below: >>>> https://bugzilla.kernel.org/show_bug.cgi?id=218726 >>>> https://lore.kernel.org/linux-bluetooth/ea20 >>> >>> >>> Provide changelog, either in cover letter or in individual patches under >>> ---. >>> >>> Do not attach (thread) your patchsets to some other threads (unrelated >>> or older versions). This buries them deep in the mailbox and might >>> interfere with applying entire sets. >>> >> > sorry, not notice this. > in order to send vN patch sets. > do i need to --in-reply-to v(N-1) cover letter or v0 cover-letter ? No. b4 or git send-email handle everything correctly. Read go/upstream before posting. If you ask such question, I doubt that you read it. Eventually get someone experienced to help you with this. > >> How did you implement these two feedbacks? >> > actually. i don't understand that two feedbacks so ask above questions. You did not ask questions. You ignored that feedback and kept sending patches, pushing for your point of view and responding to review with unrelated sentences. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v3 0/2] Fix two regression issues for QCA controllers 2024-04-22 8:11 ` Krzysztof Kozlowski @ 2024-04-22 8:21 ` quic_zijuhu 0 siblings, 0 replies; 75+ messages in thread From: quic_zijuhu @ 2024-04-22 8:21 UTC (permalink / raw) To: Krzysztof Kozlowski, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, wt On 4/22/2024 4:11 PM, Krzysztof Kozlowski wrote: > On 22/04/2024 10:07, quic_zijuhu wrote: >> On 4/22/2024 3:44 PM, Krzysztof Kozlowski wrote: >>> On 20/04/2024 13:01, Krzysztof Kozlowski wrote: >>>> On 20/04/2024 00:03, 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 >>>>> >>>>> the links for these issues are shown below: >>>>> https://bugzilla.kernel.org/show_bug.cgi?id=218726 >>>>> https://lore.kernel.org/linux-bluetooth/ea20 >>>> >>>> >>>> Provide changelog, either in cover letter or in individual patches under >>>> ---. >>>> >>>> Do not attach (thread) your patchsets to some other threads (unrelated >>>> or older versions). This buries them deep in the mailbox and might >>>> interfere with applying entire sets. >>>> >>> >> sorry, not notice this. >> in order to send vN patch sets. >> do i need to --in-reply-to v(N-1) cover letter or v0 cover-letter ? > > No. b4 or git send-email handle everything correctly. Read go/upstream > before posting. If you ask such question, I doubt that you read it. > Eventually get someone experienced to help you with this. > actually. i have read go/upstream many times. but b4 is hard for me to use. so i always use git send-email to send patches and use thunderbird to reply mails. we get someone to help. >> >>> How did you implement these two feedbacks? >>> >> actually. i don't understand that two feedbacks so ask above questions. > > You did not ask questions. You ignored that feedback and kept sending > patches, pushing for your point of view and responding to review with > unrelated sentences. > i now understood your feedbacks and concerns about format. > Best regards, > Krzysztof > ^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH v4 0/2] Fix two regression issues for QCA controllers 2024-04-19 22:03 ` [PATCH v3 0/2] Fix two regression issues for QCA controllers Zijun Hu ` (2 preceding siblings ...) 2024-04-20 11:01 ` [PATCH v3 0/2] Fix two regression issues for QCA controllers Krzysztof Kozlowski @ 2024-04-20 22:06 ` Zijun Hu 2024-04-20 22:06 ` [PATCH v4 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Zijun Hu ` (4 more replies) 3 siblings, 5 replies; 75+ messages in thread From: Zijun Hu @ 2024-04-20 22:06 UTC (permalink / raw) To: luiz.dentz, luiz.von.dentz, marcel Cc: quic_zijuhu, linux-bluetooth, bartosz.golaszewski, krzysztof.kozlowski, wt 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 the links for these issues are shown below: https://bugzilla.kernel.org/show_bug.cgi?id=218726 https://lore.kernel.org/linux-bluetooth/ea20bb9b-6b60-47fc-ae42-5eed918ad7b4@quicinc.com/T/#m73d6a71d2f454bb03588c66f3ef7912274d37c6f Changes: V3 -> V4: Correct code stype and commit message V2 -> V3: Wrong patch sets are sent V1 -> V2: Remove debugging logs Zijun Hu (2): Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot drivers/bluetooth/hci_qca.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) -- 2.7.4 ^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH v4 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 2024-04-20 22:06 ` [PATCH v4 " Zijun Hu @ 2024-04-20 22:06 ` Zijun Hu 2024-04-20 22:31 ` Fix two regression issues for QCA controllers bluez.test.bot 2024-04-20 22:06 ` [PATCH v4 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot Zijun Hu ` (3 subsequent siblings) 4 siblings, 1 reply; 75+ messages in thread From: Zijun Hu @ 2024-04-20 22:06 UTC (permalink / raw) To: luiz.dentz, luiz.von.dentz, marcel Cc: quic_zijuhu, linux-bluetooth, bartosz.golaszewski, krzysztof.kozlowski, wt Commit 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()") will cause below serious regression issue: BT can't be enabled any more after below steps: cold boot -> enable BT -> disable BT -> BT enable failure if property enable-gpios is not configured within DT|ACPI for QCA_QCA6390. The mentioned commit wrongly set quirk HCI_QUIRK_NON_PERSISTENT_SETUP within qca_serdev_probe() for this case and cause this serious issue. Fixed by reverting the mentioned commit for QCA_QCA6390. Fixes: 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()") Reported-by: Wren Turkal <wt@penguintechs.org> Link: https://bugzilla.kernel.org/show_bug.cgi?id=218726 Link: https://lore.kernel.org/linux-bluetooth/ea20bb9b-6b60-47fc-ae42-5eed918ad7b4@quicinc.com/T/#m73d6a71d2f454bb03588c66f3ef7912274d37c6f Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Tested-by: Wren Turkal <wt@penguintechs.org> --- drivers/bluetooth/hci_qca.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index 92fa20f5ac7d..4079254fb1c8 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -2357,6 +2357,8 @@ static int qca_serdev_probe(struct serdev_device *serdev) if (IS_ERR(qcadev->bt_en)) { dev_warn(&serdev->dev, "failed to acquire enable gpio\n"); power_ctrl_enabled = false; + } else if (!qcadev->bt_en && qcadev->btsoc_type == QCA_QCA6390) { + power_ctrl_enabled = false; } qcadev->susclk = devm_clk_get_optional(&serdev->dev, NULL); -- 2.7.4 ^ permalink raw reply related [flat|nested] 75+ messages in thread
* RE: Fix two regression issues for QCA controllers 2024-04-20 22:06 ` [PATCH v4 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Zijun Hu @ 2024-04-20 22:31 ` bluez.test.bot 0 siblings, 0 replies; 75+ messages in thread From: bluez.test.bot @ 2024-04-20 22:31 UTC (permalink / raw) To: linux-bluetooth, quic_zijuhu [-- Attachment #1: Type: text/plain, Size: 4387 bytes --] This is automated email and please do not reply to this email! Dear submitter, Thank you for submitting the patches to the linux bluetooth mailing list. This is a CI test results with your patch series: PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=846372 ---Test result--- Test Summary: CheckPatch FAIL 1.49 seconds GitLint FAIL 0.79 seconds SubjectPrefix PASS 0.23 seconds BuildKernel PASS 29.58 seconds CheckAllWarning PASS 32.85 seconds CheckSparse PASS 38.06 seconds CheckSmatch FAIL 34.71 seconds BuildKernel32 PASS 28.63 seconds TestRunnerSetup PASS 516.90 seconds TestRunner_l2cap-tester PASS 18.30 seconds TestRunner_iso-tester PASS 28.64 seconds TestRunner_bnep-tester PASS 4.65 seconds TestRunner_mgmt-tester PASS 109.46 seconds TestRunner_rfcomm-tester PASS 7.21 seconds TestRunner_sco-tester PASS 14.88 seconds TestRunner_ioctl-tester PASS 7.57 seconds TestRunner_mesh-tester PASS 5.74 seconds TestRunner_smp-tester PASS 6.74 seconds TestRunner_userchan-tester PASS 4.82 seconds IncrementalBuild PASS 32.49 seconds Details ############################## Test: CheckPatch - FAIL Desc: Run checkpatch.pl script Output: [v4,1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 WARNING: Reported-by: should be immediately followed by Closes: with a URL to the report #112: Reported-by: Wren Turkal <wt@penguintechs.org> Link: https://bugzilla.kernel.org/show_bug.cgi?id=218726 total: 0 errors, 1 warnings, 8 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. /github/workspace/src/src/13637223.patch has style problems, please review. NOTE: Ignored message types: UNKNOWN_COMMIT_ID NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. ############################## Test: GitLint - FAIL Desc: Run gitlint Output: [v4,1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search 17: B1 Line exceeds max length (139>80): "Link: https://lore.kernel.org/linux-bluetooth/ea20bb9b-6b60-47fc-ae42-5eed918ad7b4@quicinc.com/T/#m73d6a71d2f454bb03588c66f3ef7912274d37c6f" [v4,2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search 1: T1 Title exceeds max length (93>80): "[v4,2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot" ############################## Test: CheckSmatch - FAIL Desc: Run smatch tool with source Output: Segmentation fault (core dumped) make[4]: *** [scripts/Makefile.build:244: net/bluetooth/hci_core.o] Error 139 make[4]: *** Deleting file 'net/bluetooth/hci_core.o' make[3]: *** [scripts/Makefile.build:485: net/bluetooth] Error 2 make[2]: *** [scripts/Makefile.build:485: net] Error 2 make[2]: *** Waiting for unfinished jobs.... Segmentation fault (core dumped) make[4]: *** [scripts/Makefile.build:244: drivers/bluetooth/bcm203x.o] Error 139 make[4]: *** Deleting file 'drivers/bluetooth/bcm203x.o' make[4]: *** Waiting for unfinished jobs.... make[3]: *** [scripts/Makefile.build:485: drivers/bluetooth] Error 2 make[2]: *** [scripts/Makefile.build:485: drivers] Error 2 make[1]: *** [/github/workspace/src/src/Makefile:1919: .] Error 2 make: *** [Makefile:240: __sub-make] Error 2 --- Regards, Linux Bluetooth ^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH v4 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot 2024-04-20 22:06 ` [PATCH v4 " Zijun Hu 2024-04-20 22:06 ` [PATCH v4 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Zijun Hu @ 2024-04-20 22:06 ` Zijun Hu 2024-04-21 7:44 ` [PATCH v4 0/2] Fix two regression issues for QCA controllers Wren Turkal ` (2 subsequent siblings) 4 siblings, 0 replies; 75+ messages in thread From: Zijun Hu @ 2024-04-20 22:06 UTC (permalink / raw) To: luiz.dentz, luiz.von.dentz, marcel Cc: quic_zijuhu, linux-bluetooth, bartosz.golaszewski, krzysztof.kozlowski, wt From: Zijun Hu <zijuhu@qti.qualcomm.com> 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 QCA_QCA6390. Fixed by sending the VSC to reset controller within qca_serdev_shutdown() once BT was ever enabled. Fixes: 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") Reported-by: Wren Turkal <wt@penguintechs.org> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218726 Signed-off-by: Zijun Hu <zijuhu@qti.qualcomm.com> Tested-by: Wren Turkal <wt@penguintechs.org> --- drivers/bluetooth/hci_qca.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index 4079254fb1c8..fc027da98297 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -2439,13 +2439,12 @@ static void qca_serdev_shutdown(struct device *dev) struct qca_serdev *qcadev = serdev_device_get_drvdata(serdev); struct hci_uart *hu = &qcadev->serdev_hu; struct hci_dev *hdev = hu->hdev; - struct qca_data *qca = hu->priv; const u8 ibs_wake_cmd[] = { 0xFD }; const u8 edl_reset_soc_cmd[] = { 0x01, 0x00, 0xFC, 0x01, 0x05 }; if (qcadev->btsoc_type == QCA_QCA6390) { - if (test_bit(QCA_BT_OFF, &qca->flags) || - !test_bit(HCI_RUNNING, &hdev->flags)) + if (test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks) || + hci_dev_test_flag(hdev, HCI_SETUP)) return; serdev_device_write_flush(serdev); -- 2.7.4 ^ permalink raw reply related [flat|nested] 75+ messages in thread
* Re: [PATCH v4 0/2] Fix two regression issues for QCA controllers 2024-04-20 22:06 ` [PATCH v4 " Zijun Hu 2024-04-20 22:06 ` [PATCH v4 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Zijun Hu 2024-04-20 22:06 ` [PATCH v4 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot Zijun Hu @ 2024-04-21 7:44 ` Wren Turkal 2024-04-21 9:30 ` quic_zijuhu 2024-04-21 18:41 ` Krzysztof Kozlowski 2024-04-21 13:51 ` Krzysztof Kozlowski 2024-04-22 7:38 ` [PATCH v5 " Zijun Hu 4 siblings, 2 replies; 75+ messages in thread From: Wren Turkal @ 2024-04-21 7:44 UTC (permalink / raw) To: Zijun Hu, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, krzysztof.kozlowski 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? > the links for these issues are shown below: > https://bugzilla.kernel.org/show_bug.cgi?id=218726 > https://lore.kernel.org/linux-bluetooth/ea20bb9b-6b60-47fc-ae42-5eed918ad7b4@quicinc.com/T/#m73d6a71d2f454bb03588c66f3ef7912274d37c6f > > Changes: > V3 -> V4: Correct code stype and commit message > V2 -> V3: Wrong patch sets are sent > V1 -> V2: Remove debugging logs > > Zijun Hu (2): > Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 > Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable > then warm reboot > > drivers/bluetooth/hci_qca.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) -- You're more amazing than you think! ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v4 0/2] Fix two regression issues for QCA controllers 2024-04-21 7:44 ` [PATCH v4 0/2] Fix two regression issues for QCA controllers Wren Turkal @ 2024-04-21 9:30 ` quic_zijuhu 2024-04-21 18:41 ` Krzysztof Kozlowski 1 sibling, 0 replies; 75+ messages in thread From: quic_zijuhu @ 2024-04-21 9:30 UTC (permalink / raw) To: Wren Turkal, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, krzysztof.kozlowski On 4/21/2024 3:44 PM, 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? > Hi Wren, for QCA6390. this updated patch sets is the same as the patch sets you ever tested. sure. if you would like to test this one. >> the links for these issues are shown below: >> https://bugzilla.kernel.org/show_bug.cgi?id=218726 >> https://lore.kernel.org/linux-bluetooth/ea20bb9b-6b60-47fc-ae42-5eed918ad7b4@quicinc.com/T/#m73d6a71d2f454bb03588c66f3ef7912274d37c6f >> >> Changes: >> V3 -> V4: Correct code stype and commit message >> V2 -> V3: Wrong patch sets are sent >> V1 -> V2: Remove debugging logs >> >> Zijun Hu (2): >> Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 >> Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable >> then warm reboot >> >> drivers/bluetooth/hci_qca.c | 7 ++++--- >> 1 file changed, 4 insertions(+), 3 deletions(-) > > ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v4 0/2] Fix two regression issues for QCA controllers 2024-04-21 7:44 ` [PATCH v4 0/2] Fix two regression issues for QCA controllers Wren Turkal 2024-04-21 9:30 ` quic_zijuhu @ 2024-04-21 18:41 ` Krzysztof Kozlowski 2024-04-22 0:14 ` quic_zijuhu 1 sibling, 1 reply; 75+ messages in thread From: Krzysztof Kozlowski @ 2024-04-21 18:41 UTC (permalink / raw) To: Wren Turkal, Zijun Hu, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski 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... "now. you understood why your merged change as shown link of 4) have problems and introduced our discussed issue, right?" 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 ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v4 0/2] Fix two regression issues for QCA controllers 2024-04-21 18:41 ` Krzysztof Kozlowski @ 2024-04-22 0:14 ` quic_zijuhu 2024-04-22 5:21 ` Wren Turkal 2024-04-22 5:52 ` Krzysztof Kozlowski 0 siblings, 2 replies; 75+ messages in thread From: quic_zijuhu @ 2024-04-22 0:14 UTC (permalink / raw) To: Krzysztof Kozlowski, Wren Turkal, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, regressions 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@quicinc.com/ > "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@linaro.org/ > 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()"). 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. 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. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v4 0/2] Fix two regression issues for QCA controllers 2024-04-22 0:14 ` quic_zijuhu @ 2024-04-22 5:21 ` Wren Turkal 2024-04-22 8:51 ` Bartosz Golaszewski 2024-04-22 5:52 ` Krzysztof Kozlowski 1 sibling, 1 reply; 75+ messages in thread From: Wren Turkal @ 2024-04-22 5:21 UTC (permalink / raw) To: quic_zijuhu, Krzysztof Kozlowski, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, regressions 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@quicinc.com/ >> "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@linaro.org/ >> 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! ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v4 0/2] Fix two regression issues for QCA controllers 2024-04-22 5:21 ` Wren Turkal @ 2024-04-22 8:51 ` Bartosz Golaszewski 2024-04-22 10:42 ` Wren Turkal 0 siblings, 1 reply; 75+ messages in thread From: Bartosz Golaszewski @ 2024-04-22 8:51 UTC (permalink / raw) To: Wren Turkal Cc: quic_zijuhu, Krzysztof Kozlowski, luiz.dentz, luiz.von.dentz, marcel, linux-bluetooth, regressions On Mon, 22 Apr 2024 at 07:21, Wren Turkal <wt@penguintechs.org> wrote: > > 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. > I don't doubt my patch could have caused a regression. > 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. > This all sounds plausible. However just reverting this patch is a waste of time as checking IS_ERR_OR_NULL() on the return value of gpiod_get_optional() and continuing on error is wrong as I explained several times under Ziju's emails already. I provided a suggestion: bail out on error returned from gpiod_get_optional() even if the driver could technically continue in some cases. I don't want to have to argue this anymore. Bart ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v4 0/2] Fix two regression issues for QCA controllers 2024-04-22 8:51 ` Bartosz Golaszewski @ 2024-04-22 10:42 ` Wren Turkal 2024-04-22 13:02 ` Bartosz Golaszewski 0 siblings, 1 reply; 75+ messages in thread From: Wren Turkal @ 2024-04-22 10:42 UTC (permalink / raw) To: Bartosz Golaszewski Cc: quic_zijuhu, Krzysztof Kozlowski, luiz.dentz, luiz.von.dentz, marcel, linux-bluetooth, regressions On 4/22/24 1:51 AM, Bartosz Golaszewski wrote: > On Mon, 22 Apr 2024 at 07:21, Wren Turkal <wt@penguintechs.org> wrote: >> >> 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. >> > > I don't doubt my patch could have caused a regression. > >> 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. >> > > This all sounds plausible. However just reverting this patch is a > waste of time as checking IS_ERR_OR_NULL() on the return value of > gpiod_get_optional() and continuing on error is wrong as I explained > several times under Ziju's emails already. I provided a suggestion: > bail out on error returned from gpiod_get_optional() even if the > driver could technically continue in some cases. I don't want to have > to argue this anymore. I'm not trying to argue. I am trying to find a path forward as a concerned user. I am also trying to figure out if there is any way I can help resolve this. I am not a kernel developer, but I would really like to contribute in some way, if possible. > > Bart -- You're more amazing than you think! ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v4 0/2] Fix two regression issues for QCA controllers 2024-04-22 10:42 ` Wren Turkal @ 2024-04-22 13:02 ` Bartosz Golaszewski 2024-04-24 1:52 ` Wren Turkal 0 siblings, 1 reply; 75+ messages in thread From: Bartosz Golaszewski @ 2024-04-22 13:02 UTC (permalink / raw) To: Wren Turkal Cc: quic_zijuhu, Krzysztof Kozlowski, luiz.dentz, luiz.von.dentz, marcel, linux-bluetooth, regressions On Mon, 22 Apr 2024 at 12:42, Wren Turkal <wt@penguintechs.org> wrote: > > On 4/22/24 1:51 AM, Bartosz Golaszewski wrote: > > > > This all sounds plausible. However just reverting this patch is a > > waste of time as checking IS_ERR_OR_NULL() on the return value of > > gpiod_get_optional() and continuing on error is wrong as I explained > > several times under Ziju's emails already. I provided a suggestion: > > bail out on error returned from gpiod_get_optional() even if the > > driver could technically continue in some cases. I don't want to have > > to argue this anymore. > > I'm not trying to argue. I am trying to find a path forward as a > concerned user. I am also trying to figure out if there is any way I can > help resolve this. I am not a kernel developer, but I would really like > to contribute in some way, if possible. > Can you test the patch[1] I just sent? Bart [1] https://lore.kernel.org/linux-bluetooth/20240422130036.31856-1-brgl@bgdev.pl/ ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v4 0/2] Fix two regression issues for QCA controllers 2024-04-22 13:02 ` Bartosz Golaszewski @ 2024-04-24 1:52 ` Wren Turkal 0 siblings, 0 replies; 75+ messages in thread From: Wren Turkal @ 2024-04-24 1:52 UTC (permalink / raw) To: Bartosz Golaszewski Cc: quic_zijuhu, Krzysztof Kozlowski, luiz.dentz, luiz.von.dentz, marcel, linux-bluetooth, regressions On 4/22/24 6:02 AM, Bartosz Golaszewski wrote: > Can you test the patch[1] I just sent? I am doing this now. Just to be clear, I am testing the patch I found in the thread with subject "[PATCH] Bluetooth: qca: set power_ctrl_enabled on NULL returned by gpiod_get_optional()". If that isn't the one you're referring to, please let me know. I will reply back to that patch after testing. wt -- You're more amazing than you think! ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v4 0/2] Fix two regression issues for QCA controllers 2024-04-22 0:14 ` quic_zijuhu 2024-04-22 5:21 ` Wren Turkal @ 2024-04-22 5:52 ` Krzysztof Kozlowski 2024-04-22 6:00 ` quic_zijuhu 2024-04-22 10:05 ` quic_zijuhu 1 sibling, 2 replies; 75+ messages in thread From: Krzysztof Kozlowski @ 2024-04-22 5:52 UTC (permalink / raw) To: quic_zijuhu, Wren Turkal, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, regressions On 22/04/2024 02:14, 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. No, you did not. > 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@quicinc.com/ You did not answer my questions. Let's quote: "i don't explain much since these HCI_QUIRK_NON_PERSISTENT_SETUP and HCI_SETUP is generic flag." Srsly, what is such answer? >> "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@linaro.org/ >> 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. You keep pushing and pushing even though I stated my remarks. > > 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()"). > > 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. > > 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. You did not address original issue of crash during shutdown and did not clarify my questions. > > 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. Anyway, any explanation providing background how you are fixing this issue while keeping *previous problem fixed* is useful but should be provided in commit msg. I asked about this two or three times. BTW, provide here exact kernel version you tested this patches with. Also the exact hardware. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v4 0/2] Fix two regression issues for QCA controllers 2024-04-22 5:52 ` Krzysztof Kozlowski @ 2024-04-22 6:00 ` quic_zijuhu 2024-04-22 7:45 ` Krzysztof Kozlowski 2024-04-22 10:05 ` quic_zijuhu 1 sibling, 1 reply; 75+ messages in thread From: quic_zijuhu @ 2024-04-22 6:00 UTC (permalink / raw) To: Krzysztof Kozlowski, Wren Turkal, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, regressions Hi Krzysztof, could you list questions i need to explain within commit message based on current v4 patch sets ? let me send v5 patch sets with updated commit messages. On 4/22/2024 1:52 PM, Krzysztof Kozlowski wrote: > On 22/04/2024 02:14, 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. > > No, you did not. > >> 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@quicinc.com/ > > You did not answer my questions. > > Let's quote: > > "i don't explain much since these HCI_QUIRK_NON_PERSISTENT_SETUP and > HCI_SETUP is generic flag." > > Srsly, what is such answer? > > > > > >>> "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@linaro.org/ >>> 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. > > You keep pushing and pushing even though I stated my remarks. > > >> >> 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()"). >> >> 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. >> >> 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. > > You did not address original issue of crash during shutdown and did not > clarify my questions. > >> >> 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. > > Anyway, any explanation providing background how you are fixing this > issue while keeping *previous problem fixed* is useful but should be > provided in commit msg. I asked about this two or three times. > > BTW, provide here exact kernel version you tested this patches with. > Also the exact hardware. > > > Best regards, > Krzysztof > ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v4 0/2] Fix two regression issues for QCA controllers 2024-04-22 6:00 ` quic_zijuhu @ 2024-04-22 7:45 ` Krzysztof Kozlowski 0 siblings, 0 replies; 75+ messages in thread From: Krzysztof Kozlowski @ 2024-04-22 7:45 UTC (permalink / raw) To: quic_zijuhu, Wren Turkal, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, regressions On 22/04/2024 08:00, quic_zijuhu wrote: > Hi Krzysztof, > > could you list questions i need to explain within commit message based > on current v4 patch sets ? > > let me send v5 patch sets with updated commit messages. NAK, no. Stop sending new versions. You ignored several feedbacks already and my question from that email. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v4 0/2] Fix two regression issues for QCA controllers 2024-04-22 5:52 ` Krzysztof Kozlowski 2024-04-22 6:00 ` quic_zijuhu @ 2024-04-22 10:05 ` quic_zijuhu 2024-04-22 12:28 ` Krzysztof Kozlowski 1 sibling, 1 reply; 75+ messages in thread From: quic_zijuhu @ 2024-04-22 10:05 UTC (permalink / raw) To: Krzysztof Kozlowski, Wren Turkal, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, regressions On 4/22/2024 1:52 PM, Krzysztof Kozlowski wrote: > On 22/04/2024 02:14, 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. > > No, you did not. > >> 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@quicinc.com/ > > You did not answer my questions. > > Let's quote: > > "i don't explain much since these HCI_QUIRK_NON_PERSISTENT_SETUP and > HCI_SETUP is generic flag." > > Srsly, what is such answer? > > i reviewed my reply. i have explained to you why my change fix both this issue and the issue your commit fixed. so i don't think it is meaningful to explain why your wrong condition are changed by me. > > > >>> "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@linaro.org/ >>> 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. > > You keep pushing and pushing even though I stated my remarks. > > >> >> 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()"). >> >> 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. >> >> 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. > > You did not address original issue of crash during shutdown and did not > clarify my questions. > as i statemented. my fix have fixed both this issue and the original crash issue. don't need to talk about others. >> >> 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. > > Anyway, any explanation providing background how you are fixing this > issue while keeping *previous problem fixed* is useful but should be > provided in commit msg. I asked about this two or three times. > > BTW, provide here exact kernel version you tested this patches with. > Also the exact hardware. > there are almost no commit with tag Tested-by also provide exact kernel version. for one type bt controller. different h/w has different config. important is that this issue is fixed in reported H/W and don't cause issue for other issue. let us stop here and wait for other comments. i have given too much explanations for my change of only total 7 lines. > > Best regards, > Krzysztof > ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v4 0/2] Fix two regression issues for QCA controllers 2024-04-22 10:05 ` quic_zijuhu @ 2024-04-22 12:28 ` Krzysztof Kozlowski 0 siblings, 0 replies; 75+ messages in thread From: Krzysztof Kozlowski @ 2024-04-22 12:28 UTC (permalink / raw) To: quic_zijuhu, Wren Turkal, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, regressions On 22/04/2024 12:05, quic_zijuhu wrote: >>> 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. >> >> Anyway, any explanation providing background how you are fixing this >> issue while keeping *previous problem fixed* is useful but should be >> provided in commit msg. I asked about this two or three times. >> >> BTW, provide here exact kernel version you tested this patches with. >> Also the exact hardware. >> > there are almost no commit with tag Tested-by also provide exact kernel ?!? So this was not tested at all by you on mainline kernel and you push downstream patch? That's how shall we understand this? > version. for one type bt controller. different h/w has different config. > important is that this issue is fixed in reported H/W and don't cause > issue for other issue. Amount of pushback from your side and ignoring questions raised during review is way too much. > > let us stop here and wait for other comments. So why do you push again in v5? Best regards, Krzysztof ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v4 0/2] Fix two regression issues for QCA controllers 2024-04-20 22:06 ` [PATCH v4 " Zijun Hu ` (2 preceding siblings ...) 2024-04-21 7:44 ` [PATCH v4 0/2] Fix two regression issues for QCA controllers Wren Turkal @ 2024-04-21 13:51 ` Krzysztof Kozlowski 2024-04-22 7:38 ` [PATCH v5 " Zijun Hu 4 siblings, 0 replies; 75+ messages in thread From: Krzysztof Kozlowski @ 2024-04-21 13:51 UTC (permalink / raw) To: Zijun Hu, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, wt On 21/04/2024 00:06, 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 > > the links for these issues are shown below: > https://bugzilla.kernel.org/show_bug.cgi?id=218726 > https://lore.kernel.org/linux-bluetooth/ea20bb9b-6b60-47fc-ae42-5eed918ad7b4@quicinc.com/T/#m73d6a71d2f454bb03588c66f3ef7912274d37c6f > > Changes: > V3 -> V4: Correct code stype and commit message > V2 -> V3: Wrong patch sets are sent Didn't you got comment not to attach your postings to some other threads? Each posting is a separate thread. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH v5 0/2] Fix two regression issues for QCA controllers 2024-04-20 22:06 ` [PATCH v4 " Zijun Hu ` (3 preceding siblings ...) 2024-04-21 13:51 ` Krzysztof Kozlowski @ 2024-04-22 7:38 ` Zijun Hu 2024-04-22 7:38 ` [PATCH v5 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Zijun Hu ` (2 more replies) 4 siblings, 3 replies; 75+ messages in thread From: Zijun Hu @ 2024-04-22 7:38 UTC (permalink / raw) To: luiz.dentz, luiz.von.dentz, marcel Cc: quic_zijuhu, linux-bluetooth, bartosz.golaszewski, krzysztof.kozlowski, wt, regressions This patch series are to fix below 2 regression issues for QCA_QCA6390 1) BT can't be enabled any more after below steps: cold boot -> enable BT -> disable BT -> BT enable failure if property enable-gpios is not configured within DT|ACPI for QCA_QCA6390. 2) 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. Changes: V4 -> V5: Correct commit message V3 -> V4: Correct code stype and commit message V1 -> V3: Remove debugging logs Zijun Hu (2): Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot drivers/bluetooth/hci_qca.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) -- 2.7.4 ^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH v5 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 2024-04-22 7:38 ` [PATCH v5 " Zijun Hu @ 2024-04-22 7:38 ` Zijun Hu 2024-04-22 8:36 ` Fix two regression issues for QCA controllers bluez.test.bot 2024-04-22 7:38 ` [PATCH v5 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot Zijun Hu 2024-04-25 0:59 ` [PATCH v6 v7] Fix two BT regression issues for QCA6390 Zijun Hu 2 siblings, 1 reply; 75+ messages in thread From: Zijun Hu @ 2024-04-22 7:38 UTC (permalink / raw) To: luiz.dentz, luiz.von.dentz, marcel Cc: quic_zijuhu, linux-bluetooth, bartosz.golaszewski, krzysztof.kozlowski, wt, regressions Commit 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()") will cause below serious regression issue: BT can't be enabled any more after below steps: cold boot -> enable BT -> disable BT -> BT enable failure if property enable-gpios is not configured within DT|ACPI for QCA_QCA6390. The commit wrongly changes flag @power_ctrl_enabled set logic for this case as shown by its below code applet and causes this serious issue. 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; } Fixed by reverting the mentioned commit for QCA_QCA6390. Fixes: 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()") Reported-by: Wren Turkal <wt@penguintechs.org> Link: https://bugzilla.kernel.org/show_bug.cgi?id=218726 Link: https://lore.kernel.org/linux-bluetooth/ea20bb9b-6b60-47fc-ae42-5eed918ad7b4@quicinc.com/T/#m73d6a71d2f454bb03588c66f3ef7912274d37c6f Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Tested-by: Wren Turkal <wt@penguintechs.org> --- drivers/bluetooth/hci_qca.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index 92fa20f5ac7d..4079254fb1c8 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -2357,6 +2357,8 @@ static int qca_serdev_probe(struct serdev_device *serdev) if (IS_ERR(qcadev->bt_en)) { dev_warn(&serdev->dev, "failed to acquire enable gpio\n"); power_ctrl_enabled = false; + } else if (!qcadev->bt_en && qcadev->btsoc_type == QCA_QCA6390) { + power_ctrl_enabled = false; } qcadev->susclk = devm_clk_get_optional(&serdev->dev, NULL); -- 2.7.4 ^ permalink raw reply related [flat|nested] 75+ messages in thread
* RE: Fix two regression issues for QCA controllers 2024-04-22 7:38 ` [PATCH v5 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Zijun Hu @ 2024-04-22 8:36 ` bluez.test.bot 0 siblings, 0 replies; 75+ messages in thread From: bluez.test.bot @ 2024-04-22 8:36 UTC (permalink / raw) To: linux-bluetooth, quic_zijuhu [-- Attachment #1: Type: text/plain, Size: 4745 bytes --] This is automated email and please do not reply to this email! Dear submitter, Thank you for submitting the patches to the linux bluetooth mailing list. This is a CI test results with your patch series: PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=846527 ---Test result--- Test Summary: CheckPatch FAIL 1.59 seconds GitLint FAIL 0.90 seconds SubjectPrefix PASS 0.24 seconds BuildKernel PASS 30.10 seconds CheckAllWarning PASS 32.58 seconds CheckSparse PASS 38.41 seconds CheckSmatch FAIL 36.09 seconds BuildKernel32 PASS 28.87 seconds TestRunnerSetup PASS 518.43 seconds TestRunner_l2cap-tester PASS 20.48 seconds TestRunner_iso-tester PASS 28.64 seconds TestRunner_bnep-tester PASS 4.71 seconds TestRunner_mgmt-tester PASS 109.59 seconds TestRunner_rfcomm-tester PASS 7.29 seconds TestRunner_sco-tester PASS 14.97 seconds TestRunner_ioctl-tester PASS 7.67 seconds TestRunner_mesh-tester PASS 5.72 seconds TestRunner_smp-tester PASS 6.72 seconds TestRunner_userchan-tester PASS 4.85 seconds IncrementalBuild PASS 33.12 seconds Details ############################## Test: CheckPatch - FAIL Desc: Run checkpatch.pl script Output: [v5,1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 WARNING: Reported-by: should be immediately followed by Closes: with a URL to the report #119: Reported-by: Wren Turkal <wt@penguintechs.org> Link: https://bugzilla.kernel.org/show_bug.cgi?id=218726 total: 0 errors, 1 warnings, 8 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. /github/workspace/src/src/13637840.patch has style problems, please review. NOTE: Ignored message types: UNKNOWN_COMMIT_ID NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. ############################## Test: GitLint - FAIL Desc: Run gitlint Output: [v5,1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search 16: B3 Line contains hard tab characters (\t): " dev_warn(&serdev->dev, "failed to acquire enable gpio\n");" 17: B3 Line contains hard tab characters (\t): " power_ctrl_enabled = false;" 24: B1 Line exceeds max length (139>80): "Link: https://lore.kernel.org/linux-bluetooth/ea20bb9b-6b60-47fc-ae42-5eed918ad7b4@quicinc.com/T/#m73d6a71d2f454bb03588c66f3ef7912274d37c6f" [v5,2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search 1: T1 Title exceeds max length (93>80): "[v5,2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot" ############################## Test: CheckSmatch - FAIL Desc: Run smatch tool with source Output: Segmentation fault (core dumped) make[4]: *** [scripts/Makefile.build:244: net/bluetooth/hci_core.o] Error 139 make[4]: *** Deleting file 'net/bluetooth/hci_core.o' make[3]: *** [scripts/Makefile.build:485: net/bluetooth] Error 2 make[2]: *** [scripts/Makefile.build:485: net] Error 2 make[2]: *** Waiting for unfinished jobs.... Segmentation fault (core dumped) make[4]: *** [scripts/Makefile.build:244: drivers/bluetooth/bcm203x.o] Error 139 make[4]: *** Deleting file 'drivers/bluetooth/bcm203x.o' make[4]: *** Waiting for unfinished jobs.... Segmentation fault (core dumped) make[4]: *** [scripts/Makefile.build:244: drivers/bluetooth/bpa10x.o] Error 139 make[4]: *** Deleting file 'drivers/bluetooth/bpa10x.o' make[3]: *** [scripts/Makefile.build:485: drivers/bluetooth] Error 2 make[2]: *** [scripts/Makefile.build:485: drivers] Error 2 make[1]: *** [/github/workspace/src/src/Makefile:1919: .] Error 2 make: *** [Makefile:240: __sub-make] Error 2 --- Regards, Linux Bluetooth ^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH v5 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot 2024-04-22 7:38 ` [PATCH v5 " Zijun Hu 2024-04-22 7:38 ` [PATCH v5 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Zijun Hu @ 2024-04-22 7:38 ` Zijun Hu 2024-04-22 7:42 ` Krzysztof Kozlowski 2024-04-25 0:59 ` [PATCH v6 v7] Fix two BT regression issues for QCA6390 Zijun Hu 2 siblings, 1 reply; 75+ messages in thread From: Zijun Hu @ 2024-04-22 7:38 UTC (permalink / raw) To: luiz.dentz, luiz.von.dentz, marcel Cc: quic_zijuhu, linux-bluetooth, bartosz.golaszewski, krzysztof.kozlowski, wt, regressions From: Zijun Hu <zijuhu@qti.qualcomm.com> 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 QCA_QCA6390. The commit is to fix a use-after-free issue within qca_serdev_shutdown() during reboot, but also introduces this new 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 be fixed by this change since serdev is still opened when send to serdev. Fixes: 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") Reported-by: Wren Turkal <wt@penguintechs.org> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218726 Signed-off-by: Zijun Hu <zijuhu@qti.qualcomm.com> Tested-by: Wren Turkal <wt@penguintechs.org> --- drivers/bluetooth/hci_qca.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index 4079254fb1c8..fc027da98297 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -2439,13 +2439,12 @@ static void qca_serdev_shutdown(struct device *dev) struct qca_serdev *qcadev = serdev_device_get_drvdata(serdev); struct hci_uart *hu = &qcadev->serdev_hu; struct hci_dev *hdev = hu->hdev; - struct qca_data *qca = hu->priv; const u8 ibs_wake_cmd[] = { 0xFD }; const u8 edl_reset_soc_cmd[] = { 0x01, 0x00, 0xFC, 0x01, 0x05 }; if (qcadev->btsoc_type == QCA_QCA6390) { - if (test_bit(QCA_BT_OFF, &qca->flags) || - !test_bit(HCI_RUNNING, &hdev->flags)) + if (test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks) || + hci_dev_test_flag(hdev, HCI_SETUP)) return; serdev_device_write_flush(serdev); -- 2.7.4 ^ permalink raw reply related [flat|nested] 75+ messages in thread
* Re: [PATCH v5 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot 2024-04-22 7:38 ` [PATCH v5 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot Zijun Hu @ 2024-04-22 7:42 ` Krzysztof Kozlowski 2024-04-22 11:25 ` quic_zijuhu 0 siblings, 1 reply; 75+ messages in thread From: Krzysztof Kozlowski @ 2024-04-22 7:42 UTC (permalink / raw) To: Zijun Hu, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, wt, regressions On 22/04/2024 09:38, Zijun Hu wrote: > From: Zijun Hu <zijuhu@qti.qualcomm.com> > > 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 QCA_QCA6390. > > The commit is to fix a use-after-free issue within qca_serdev_shutdown() > during reboot, but also introduces this new 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 be fixed > by this change since serdev is still opened when send to serdev. > > Fixes: 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") > Reported-by: Wren Turkal <wt@penguintechs.org> NAK. This is way too much. Previous discussion is going, I asked there questions and before any answers happen, you keep sending new version. This leads to previous discussion gone/missed. You ignored several questions and feedbacks. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v5 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot 2024-04-22 7:42 ` Krzysztof Kozlowski @ 2024-04-22 11:25 ` quic_zijuhu 2024-04-22 12:22 ` Krzysztof Kozlowski 0 siblings, 1 reply; 75+ messages in thread From: quic_zijuhu @ 2024-04-22 11:25 UTC (permalink / raw) To: Krzysztof Kozlowski, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, wt, regressions On 4/22/2024 3:42 PM, Krzysztof Kozlowski wrote: > On 22/04/2024 09:38, Zijun Hu wrote: >> From: Zijun Hu <zijuhu@qti.qualcomm.com> >> >> 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 QCA_QCA6390. >> >> The commit is to fix a use-after-free issue within qca_serdev_shutdown() >> during reboot, but also introduces this new 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 be fixed >> by this change since serdev is still opened when send to serdev. >> >> Fixes: 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") >> Reported-by: Wren Turkal <wt@penguintechs.org> > > NAK. This is way too much. Previous discussion is going, I asked there > questions and before any answers happen, you keep sending new version. > This leads to previous discussion gone/missed. > > You ignored several questions and feedbacks. > > Best regards, > Krzysztof > i believe my commit message explains WHAT/WHY/HOW about this issue. 1) the qca_serdev_shutdown() was introduced by my below commit Commit 7e7bbddd029b ("Bluetooth: hci_qca: Fix qca6390 enable failure after warm reboot") 2) then Krzysztof's below commit was made to fix use-after-free issue but also causes discussed regression issue. Commit 0b7015132878 ("Bluetooth: btusb: mediatek: add MediaTek devcoredump support") 3) my fix will solve both this issue and the use-after-free issue. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v5 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot 2024-04-22 11:25 ` quic_zijuhu @ 2024-04-22 12:22 ` Krzysztof Kozlowski 2024-04-22 12:59 ` quic_zijuhu 0 siblings, 1 reply; 75+ messages in thread From: Krzysztof Kozlowski @ 2024-04-22 12:22 UTC (permalink / raw) To: quic_zijuhu, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, wt, regressions On 22/04/2024 13:25, quic_zijuhu wrote: > On 4/22/2024 3:42 PM, Krzysztof Kozlowski wrote: >> On 22/04/2024 09:38, Zijun Hu wrote: >>> From: Zijun Hu <zijuhu@qti.qualcomm.com> >>> >>> 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 QCA_QCA6390. >>> >>> The commit is to fix a use-after-free issue within qca_serdev_shutdown() >>> during reboot, but also introduces this new 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 be fixed >>> by this change since serdev is still opened when send to serdev. >>> >>> Fixes: 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") >>> Reported-by: Wren Turkal <wt@penguintechs.org> >> >> NAK. This is way too much. Previous discussion is going, I asked there >> questions and before any answers happen, you keep sending new version. >> This leads to previous discussion gone/missed. >> >> You ignored several questions and feedbacks. >> >> Best regards, >> Krzysztof >> > i believe my commit message explains WHAT/WHY/HOW about this issue. > > 1) the qca_serdev_shutdown() was introduced by my below commit > Commit 7e7bbddd029b ("Bluetooth: hci_qca: Fix qca6390 enable failure > after warm reboot") > > 2) then Krzysztof's below commit was made to fix use-after-free issue > but also causes discussed regression issue. > Commit 0b7015132878 ("Bluetooth: btusb: mediatek: add MediaTek > devcoredump support") > > 3) my fix will solve both this issue and the use-after-free issue. I had to keep reminding you about answering to question multiple times. So one more time: > You did not address original issue of crash during shutdown and did not clarify my questions. > Anyway, any explanation providing background how you are fixing this issue while keeping *previous problem fixed* is useful but should be provided in commit msg. I asked about this two or three times. > BTW, provide here exact kernel version you tested this patches with. Also the exact hardware. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH v5 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot 2024-04-22 12:22 ` Krzysztof Kozlowski @ 2024-04-22 12:59 ` quic_zijuhu 0 siblings, 0 replies; 75+ messages in thread From: quic_zijuhu @ 2024-04-22 12:59 UTC (permalink / raw) To: Krzysztof Kozlowski, luiz.dentz, luiz.von.dentz, marcel Cc: linux-bluetooth, bartosz.golaszewski, wt, regressions On 4/22/2024 8:22 PM, Krzysztof Kozlowski wrote: > On 22/04/2024 13:25, quic_zijuhu wrote: >> On 4/22/2024 3:42 PM, Krzysztof Kozlowski wrote: >>> On 22/04/2024 09:38, Zijun Hu wrote: >>>> From: Zijun Hu <zijuhu@qti.qualcomm.com> >>>> >>>> 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 QCA_QCA6390. >>>> >>>> The commit is to fix a use-after-free issue within qca_serdev_shutdown() >>>> during reboot, but also introduces this new 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 be fixed >>>> by this change since serdev is still opened when send to serdev. >>>> >>>> Fixes: 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") >>>> Reported-by: Wren Turkal <wt@penguintechs.org> >>> >>> NAK. This is way too much. Previous discussion is going, I asked there >>> questions and before any answers happen, you keep sending new version. >>> This leads to previous discussion gone/missed. >>> >>> You ignored several questions and feedbacks. >>> >>> Best regards, >>> Krzysztof >>> >> i believe my commit message explains WHAT/WHY/HOW about this issue. >> >> 1) the qca_serdev_shutdown() was introduced by my below commit >> Commit 7e7bbddd029b ("Bluetooth: hci_qca: Fix qca6390 enable failure >> after warm reboot") >> >> 2) then Krzysztof's below commit was made to fix use-after-free issue >> but also causes discussed regression issue. >> Commit 0b7015132878 ("Bluetooth: btusb: mediatek: add MediaTek >> devcoredump support") >> >> 3) my fix will solve both this issue and the use-after-free issue. > > I had to keep reminding you about answering to question multiple times. > So one more time: > >> You did not address original issue of crash during shutdown and did > not clarify my questions. > let me explain here. original crash your commit fixed should only happens with machine for which property enable-gpios is configured, which also results in quirk HCI_QUIRK_NON_PERSISTENT_SETUP is set. for this case. for this case, serdev has been closed when qca_serdev_shutdown() write the VSC to serdev, so cause the crash. your commit fix this issue for this cause but cause regression for the case my commit message described. >> Anyway, any explanation providing background how you are fixing this > issue while keeping *previous problem fixed* is useful but should be > provided in commit msg. I asked about this two or three times. > i have provided it in this v5 commit. >> BTW, provide here exact kernel version you tested this patches with. > Also the exact hardware. > we can provide the kernel version in the bugzilla, as explained above, for the same soc_type, different machine have different config. different config have different result. > Best regards, > Krzysztof > ^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH v6 v7] Fix two BT regression issues for QCA6390 2024-04-22 7:38 ` [PATCH v5 " Zijun Hu 2024-04-22 7:38 ` [PATCH v5 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Zijun Hu 2024-04-22 7:38 ` [PATCH v5 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot Zijun Hu @ 2024-04-25 0:59 ` Zijun Hu 2 siblings, 0 replies; 75+ messages in thread From: Zijun Hu @ 2024-04-25 0:59 UTC (permalink / raw) To: quic_zijuhu; +Cc: linux-bluetooth V6 and V7 patch serial discussion link are shown below: V6 patch serials discussion link is here: https://lore.kernel.org/linux-bluetooth/1713919602-5812-1-git-send-email-quic_zijuhu@quicinc.com/T/#r0a177b0db7f7185ecec9274460fdf8d369d5c255 V7 patch serials discussion link is here: https://lore.kernel.org/linux-bluetooth/1713932807-19619-1-git-send-email-quic_zijuhu@quicinc.com/T/#t -- 2.7.4 ^ permalink raw reply [flat|nested] 75+ messages in thread
end of thread, other threads:[~2024-04-25 0:59 UTC | newest] Thread overview: 75+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-04-18 14:06 [PATCH v1 0/2] Fix two regression issues for QCA controllers Zijun Hu 2024-04-18 14:06 ` [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" Zijun Hu 2024-04-18 14:31 ` Fix two regression issues for QCA controllers bluez.test.bot 2024-04-18 16:52 ` [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()" Krzysztof Kozlowski 2024-04-18 21:16 ` quic_zijuhu 2024-04-18 22:37 ` Krzysztof Kozlowski 2024-04-18 23:17 ` quic_zijuhu 2024-04-19 13:49 ` Krzysztof Kozlowski 2024-04-20 5:25 ` quic_zijuhu 2024-04-20 5:27 ` quic_zijuhu 2024-04-20 11:13 ` Krzysztof Kozlowski 2024-04-20 23:01 ` quic_zijuhu 2024-04-18 17:00 ` Bartosz Golaszewski 2024-04-18 21:43 ` quic_zijuhu 2024-04-18 22:42 ` Bartosz Golaszewski 2024-04-18 23:36 ` quic_zijuhu 2024-04-19 21:27 ` Bartosz Golaszewski 2024-04-20 5:39 ` quic_zijuhu 2024-04-21 7:14 ` Wren Turkal 2024-04-21 9:40 ` quic_zijuhu 2024-04-22 5:26 ` Wren Turkal 2024-04-18 14:06 ` [PATCH v1 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot Zijun Hu 2024-04-18 16:48 ` Krzysztof Kozlowski 2024-04-18 20:34 ` quic_zijuhu 2024-04-18 20:58 ` Krzysztof Kozlowski 2024-04-18 22:05 ` quic_zijuhu 2024-04-18 22:38 ` Krzysztof Kozlowski 2024-04-18 23:24 ` quic_zijuhu 2024-04-19 21:48 ` [PATCH v1 0/2] Fix two regression issues for QCA controllers Zijun Hu 2024-04-19 21:48 ` [PATCH v2 1/2] Bluetooth: MGMT: Fix failing to MGMT_OP_ADD_UUID/MGMT_OP_REMOVE_UUID Zijun Hu 2024-04-19 22:05 ` quic_zijuhu 2024-04-19 22:12 ` [v2,1/2] " bluez.test.bot 2024-04-19 21:48 ` [PATCH v2 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Zijun Hu 2024-04-19 22:06 ` quic_zijuhu 2024-04-19 22:03 ` [PATCH v3 0/2] Fix two regression issues for QCA controllers Zijun Hu 2024-04-19 22:03 ` [PATCH v3 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Zijun Hu 2024-04-19 22:30 ` Fix two regression issues for QCA controllers bluez.test.bot 2024-04-20 11:03 ` [PATCH v3 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Krzysztof Kozlowski 2024-04-20 21:28 ` quic_zijuhu 2024-04-19 22:03 ` [PATCH v3 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot Zijun Hu 2024-04-20 11:07 ` Krzysztof Kozlowski 2024-04-20 21:42 ` quic_zijuhu 2024-04-20 11:01 ` [PATCH v3 0/2] Fix two regression issues for QCA controllers Krzysztof Kozlowski 2024-04-22 7:44 ` Krzysztof Kozlowski 2024-04-22 8:07 ` quic_zijuhu 2024-04-22 8:11 ` Krzysztof Kozlowski 2024-04-22 8:21 ` quic_zijuhu 2024-04-20 22:06 ` [PATCH v4 " Zijun Hu 2024-04-20 22:06 ` [PATCH v4 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Zijun Hu 2024-04-20 22:31 ` Fix two regression issues for QCA controllers bluez.test.bot 2024-04-20 22:06 ` [PATCH v4 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot Zijun Hu 2024-04-21 7:44 ` [PATCH v4 0/2] Fix two regression issues for QCA controllers Wren Turkal 2024-04-21 9:30 ` quic_zijuhu 2024-04-21 18:41 ` Krzysztof Kozlowski 2024-04-22 0:14 ` quic_zijuhu 2024-04-22 5:21 ` Wren Turkal 2024-04-22 8:51 ` Bartosz Golaszewski 2024-04-22 10:42 ` Wren Turkal 2024-04-22 13:02 ` Bartosz Golaszewski 2024-04-24 1:52 ` Wren Turkal 2024-04-22 5:52 ` Krzysztof Kozlowski 2024-04-22 6:00 ` quic_zijuhu 2024-04-22 7:45 ` Krzysztof Kozlowski 2024-04-22 10:05 ` quic_zijuhu 2024-04-22 12:28 ` Krzysztof Kozlowski 2024-04-21 13:51 ` Krzysztof Kozlowski 2024-04-22 7:38 ` [PATCH v5 " Zijun Hu 2024-04-22 7:38 ` [PATCH v5 1/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 Zijun Hu 2024-04-22 8:36 ` Fix two regression issues for QCA controllers bluez.test.bot 2024-04-22 7:38 ` [PATCH v5 2/2] Bluetooth: qca: Fix BT enable failure for QCA_QCA6390 after disable then warm reboot Zijun Hu 2024-04-22 7:42 ` Krzysztof Kozlowski 2024-04-22 11:25 ` quic_zijuhu 2024-04-22 12:22 ` Krzysztof Kozlowski 2024-04-22 12:59 ` quic_zijuhu 2024-04-25 0:59 ` [PATCH v6 v7] Fix two BT regression issues for QCA6390 Zijun Hu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).