Received-SPF: pass (google.com: domain of linux-bluetooth+bounces-3845-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
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>
In-Reply-To: <dc17aea1-9399-4c2b-8775-fa0a7f602035@penguintechs.org>
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Date: Mon, 22 Apr 2024 10:51:24 +0200
Message-ID: <CACMJSevocRot6J06uvridRw9MZFftJrkCyYBgXhLnwfapVPnCw@mail.gmail.com>
Subject: Re: [PATCH v4 0/2] Fix two regression issues for QCA controllers
To: Wren Turkal <wt@penguintechs.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
Content-Type: text/plain; charset="UTF-8"

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.

Bart