On 4/18/2024 8:01 AM, Bartosz Golaszewski wrote:
> On Thu, 18 Apr 2024 at 01:44, quic_zijuhu <quic_zijuhu@xxxxxxxxxxx> wrote:
>>
>> On 4/18/2024 2:59 AM, Bartosz Golaszewski wrote:
>>> On Wed, 17 Apr 2024 at 13:53, Zijun Hu <quic_zijuhu@xxxxxxxxxxx> 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.
>>>>
>>>
>>> Then you just go back to bad usage of the GPIO API. Please see my
>>> suggestion below.
>>>
>> we need to treat below tow cases equivalently.
>> 1) BT reset pin is NOT configured, devm_gpiod_get_optional() return NULL.
>> 2) BT reset pin is configured, but failed to be got, devm_gpiod_get_optional() return ERROR.
>>
>> FOR above two cases, hci_qca driver doesn't get available BT reset pin for H/W reset.
>> so we use IS_ERR_OR_NULL() instead of IS_ERR().
>>
>> is it not right ?
>>
>>
>>>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=218726
>>>> Fixes: 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()")
>>>> Signed-off-by: Zijun Hu <quic_zijuhu@xxxxxxxxxxx>
>>>> ---
>>>> 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;
>>>
>>> Can you just move this out of this block? Or just simply check the
>>> presence of the GPIO descriptor in the if block setting the quirk bit?
>>> Warning on a missing *optional* GPIO is wrong. It's not an unexpected
>>> situation, it's normal.
>>>
>> your concern is that the prompt message is printed by wrong way or the prompt message is not precise.
>> is it right ?
>>
>
> Actually now that you're saying this: if gpiod_get_optional() returns
> IS_ERR() then we should bail-out and return dev_err_probe(), not
> proceed. What if GPIOLIB returns EPROBE_DEFER? Only NULL is an
> acceptable return value from gpiod_get_optional().
>
1) "you're saying this" or "i am saying this" ? is it a typo error?
2) BT still is able to work by clearing the quirk even if getting preferred H/W reset way failure, why need to bail-out and return dev_err_probe() ?
3) are you sumbit the change because you meet any functionality issues?
4) do you meet the case that EPROBE_DEFER is returned ?, are your change is to fix the EPROBE_DEFER case ? if so, your fix is not right.
> Bart
>
>>> Bartosz
>>>
>>>> }
>>>> --
>>>> 2.7.4
>>>>
>>
