On 11.10.2024 21:05, Luiz Augusto von Dentz wrote: > Hi Heiner, > > On Fri, Oct 11, 2024 at 2:52 PM Heiner Kallweit <hkallweit1@xxxxxxxxx> wrote: >> >> On 11.10.2024 18:36, Luiz Augusto von Dentz wrote: >>> Hi Heiner, >>> >>> On Fri, Oct 11, 2024 at 6:49 AM Heiner Kallweit <hkallweit1@xxxxxxxxx> wrote: >>>> >>>> Since linux-next from Oct 4th my bt speaker fails to connect if I switch it on. >>>> It just hangs trying. Manually connecting it via bluetoothctl works though. >>>> With this patch reverted it auto-connects again. >>>> If you need additional details, please let me know. >>> >>> I suspect something is trying to suspend the controller then, it >>> shouldn't be USB auto-suspend since that should behave as it >>> previously but if there is something externally (aka. userspace) >>> trying to suspend then it will force it to suspend. >>> >> On the host side it's a combined WiFi/BT PCIe adapter (RTL8822CE). >> Runtime PM is enabled, so this may kick in. I'm not aware of any >> userspace tool which may try to suspend the WiFi/BT adapter. >> Disabling Runtime PM may be a workaround, but I don't think that's >> the actual solution. >> > > Well I assume it still using USB as transport, not PCIe, otherwise it > wouldn't be using btusb. Regarding runtime PM, I assume it still means Right, it's a M.2 adapter which utilizes PCIe and USB. > PMSG_IS_AUTO Documentation/driver-api/usb/power-management.rst: > > 'External suspend calls should never be allowed to fail in this way, > only autosuspend calls. The driver can tell them apart by applying > the :c:func:`PMSG_IS_AUTO` macro to the message argument to the > ``suspend`` method; it will return True for internal PM events' >