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
