Received-SPF: pass (google.com: domain of linux-bluetooth+bounces-3752-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <d6aa48e7-ab87-4014-894e-5b6da4d42687@quicinc.com>
Date: Fri, 19 Apr 2024 07:36:20 +0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/2] Revert "Bluetooth: hci_qca: don't use
 IS_ERR_OR_NULL() with gpiod_get_optional()"
To: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
CC: <luiz.dentz@gmail.com>, <luiz.von.dentz@intel.com>, <marcel@holtmann.org>,
        <linux-bluetooth@vger.kernel.org>, <wt@penguintechs.org>,
        <krzysztof.kozlowski@linaro.org>
References: <1713449192-25926-1-git-send-email-quic_zijuhu@quicinc.com>
 <1713449192-25926-2-git-send-email-quic_zijuhu@quicinc.com>
 <CACMJSevfE3wLhaz1z6A977JL5gOH62NThYWzybVqmHyR7pru=w@mail.gmail.com>
 <1ab7e6fd-68f2-4952-b5d5-bc244b8b7eb3@quicinc.com>
 <CACMJSeuTkC=Sho29HLada3eTPoasZguObhC1FwmgtJ0dqj=Ykw@mail.gmail.com>
Content-Language: en-US
From: quic_zijuhu <quic_zijuhu@quicinc.com>
In-Reply-To: <CACMJSeuTkC=Sho29HLada3eTPoasZguObhC1FwmgtJ0dqj=Ykw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

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