On Thu, 1 Aug 2024 at 10:36, Wren Turkal <wt@xxxxxxxxxxxxxxxx> wrote: > > On 8/1/24 1:09 AM, Bartosz Golaszewski wrote: > > On Thu, 1 Aug 2024 at 09:59, Wren Turkal <wt@xxxxxxxxxxxxxxxx> wrote: > >>> > >>> Indeed. I don't know why I assumed it must be an ARM laptop. I will > >>> come up with a fix shortly. > >> > >> I have a question, does this fact have anything to do with the problem > >> with failing to initialize the QCA6390 BT hardware on my laptop after a > >> warm reboot? As I didn't understand the connection to DT in that other > >> issue, does this fact change anything about how to approach that issue? > >> I only ask because that issue still very much exists. > >> > > > > Can you remind me if you had bisected it to a specific offending commit? > > I don't think I was able to fully bisect that one. I was more focused on > the fact that the BT hardware didn't work at all even after a cold boot > in that previous issue. > > Zijun suggested a fix in > https://lore.kernel.org/linux-bluetooth/1715866294-1549-1-git-send-email-quic_zijuhu@xxxxxxxxxxx/. > > That fix was landed (mainline commit > 88e72239ead9814b886db54fc4ee39ef3c2b8f26) and reverted for regression > (revert part of merge 033771c085c2ed73cb29dd25e1ec8c4b2991cad9). > > I do not know how to move that one forward. I was hoping that this > pwrseq work and the fact that this laptop doesn't use DT might be new > facts that make it easier to move forward. > With the fixes from this series the driver should theoretically go back to the behavior pre-pwrseq on your hardware. Is there a specific kernel version where it still works? Bart
