Received-SPF: pass (google.com: domain of linux-bluetooth+bounces-3851-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: <5da9ecae-35c7-4968-9f16-3f10e04c2b1a@penguintechs.org>
Date: Mon, 22 Apr 2024 03:42:26 -0700
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 0/2] Fix two regression issues for QCA controllers
To: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Cc: quic_zijuhu <quic_zijuhu@quicinc.com>,
 Krzysztof Kozlowski <krzk@kernel.org>, luiz.dentz@gmail.com,
 luiz.von.dentz@intel.com, marcel@holtmann.org,
 linux-bluetooth@vger.kernel.org, regressions@lists.linux.dev
References: <1713564212-21725-1-git-send-email-quic_zijuhu@quicinc.com>
 <1713650800-29741-1-git-send-email-quic_zijuhu@quicinc.com>
 <369512e2-f091-4370-bce5-9ac32178dc4d@penguintechs.org>
 <a6ae69ad-b602-4cfc-9f76-8932f357d30b@kernel.org>
 <c0f7036d-c129-400b-85a2-1414ec3d2622@quicinc.com>
 <dc17aea1-9399-4c2b-8775-fa0a7f602035@penguintechs.org>
 <CACMJSevocRot6J06uvridRw9MZFftJrkCyYBgXhLnwfapVPnCw@mail.gmail.com>
Content-Language: en-US
From: Wren Turkal <wt@penguintechs.org>
In-Reply-To: <CACMJSevocRot6J06uvridRw9MZFftJrkCyYBgXhLnwfapVPnCw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 4/22/24 1:51 AM, Bartosz Golaszewski wrote:
> On Mon, 22 Apr 2024 at 07:21, Wren Turkal <wt@penguintechs.org> wrote:
>>
>> As the user who originally reported thes issue, I can confirm this. I
>> was introduced to this regression because I use Fedora Rawhide on my
>> laptop, which builds and pushes kernels based on mainline very regularly.
>>
> 
> I don't doubt my patch could have caused a regression.
> 
>> Here is my description of the regression: After the reverted change, the
>> BT hardware in my laptop (qca6390) will only work after a cold boot when
>> the hardware has only be enabled once by the driver. Once the hardware
>> is enabled, the process of disabling/re-enabling fails. Also, the
>> hardware cannot be enabled after a warm boot of the laptop.
>>
>> Among other things, this makes logging into KDE Plasma break my
>> bluetooth mouse. The cause of this breakage appears to be that Plasma
>> disables/re-enables bluetooth hardware upon login.
>>
>> GNOME operates slightly less badly in that bluetooth stays enabled.
>> However, if I manually disable the bluetooth via the ui or by restarting
>> the bluetooth service with systemctl, the mouse fails in the same way as
>> happens with Plasma.
>>
>> Once the bluetooth has failed, the only way to fix is a cold boot and
>> only enable the hardware once. I cannot remove the modules (btqca,
>> hci_uart, and bluetooth) and re-modprobe them to fix it. I can't restart
>> the bluetooth service. I can't do both of those things. I haven't found
>> any way to re-enable the hardware beyond cold boot with bluetooth
>> service enabled.
>>
>> If I disable the bluetooth service and cold boot the laptop, there also
>> appears to be some kind of race condition as not enabling bluetooth
>> service very soon after loading the hci_uart and btqca modules during
>> boot puts the system in a state where I can never enable bluetooth. I do
>> not know what causes this specifically, but my theory is that not
>> starting the bluetooth service immediately puts the driver in a similar
>> state as when the service is started immediately. Maybe some kind of
>> lazy initialization that is forced to happen more quickly when the
>> bluetooth service is enabled?
>>
>> Any way, this reversion by itself (which I manually did after a
>> discussion with Zijun before getting his test patches applying to my
>> kernel for test). However, this reversion did not get the hardware
>> working after a warm boot.
>>
> 
> This all sounds plausible. However just reverting this patch is a
> waste of time as checking IS_ERR_OR_NULL() on the return value of
> gpiod_get_optional() and continuing on error is wrong as I explained
> several times under Ziju's emails already. I provided a suggestion:
> bail out on error returned from gpiod_get_optional() even if the
> driver could technically continue in some cases. I don't want to have
> to argue this anymore.

I'm not trying to argue. I am trying to find a path forward as a 
concerned user. I am also trying to figure out if there is any way I can 
help resolve this. I am not a kernel developer, but I would really like 
to contribute in some way, if possible.

> 
> Bart

-- 
You're more amazing than you think!