On 4/22/24 1:51 AM, Bartosz Golaszewski wrote:
On Mon, 22 Apr 2024 at 07:21, Wren Turkal <wt@xxxxxxxxxxxxxxxx> 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!
