| Message ID | 1713449192-25926-1-git-send-email-quic_zijuhu@quicinc.com |
|---|---|
| Headers | show |
| Series | Fix two regression issues for QCA controllers | expand |
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
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 >
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
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
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
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 >
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
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
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
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(-)
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.
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
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
>
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 >> >
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
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
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
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
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 >
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 > >
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
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/
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
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
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 >
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
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 >
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(-)