Received-SPF: pass (google.com: domain of linux-bluetooth+bounces-3821-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <8a625e4e-8283-41bf-9f2f-70bcc47784ab@penguintechs.org>
Date: Sun, 21 Apr 2024 22:26:58 -0700
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: quic_zijuhu <quic_zijuhu@quicinc.com>,
 Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Cc: luiz.dentz@gmail.com, luiz.von.dentz@intel.com, marcel@holtmann.org,
 linux-bluetooth@vger.kernel.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>
 <5c9a57ba-d516-4d3e-85e5-bba299ee97a6@penguintechs.org>
 <cd6539e1-3d6c-4174-96cd-838fdaa9288c@quicinc.com>
Content-Language: en-US
From: Wren Turkal <wt@penguintechs.org>
In-Reply-To: <cd6539e1-3d6c-4174-96cd-838fdaa9288c@quicinc.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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!