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. Bart
