> On Jul 30, 2020, at 15:30, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: > > Hi Kai-Heng, > >>> On Jul 30, 2020, at 07:17, Abhishek Pandit-Subedi <abhishekpandit@xxxxxxxxxxxx> wrote: >>> >>> This reverts commit 7ecacafc240638148567742cca41aa7144b4fe1e. >>> >>> Testing this change on a board with RTL8822CE, I found that enabling >>> autosuspend has no effect on the stability of the system. The board >>> continued working after autosuspend, suspend and reboot. >> >> The original issue was found on 8723DE. Do you have one to test with? >> The rtw88 codebase has changed a lot and maybe it's already fixed in mainline. >> Let me do some test and I'll report back. >> >>> >>> The original commit makes it impossible to enable autosuspend on working >>> systems so it should be reverted. Disabling autosuspend should be done >>> via module param or udev in userspace instead. >>> >>> Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@xxxxxxxxxxxx> >>> --- >>> We have a few Chromebooks using the RTL 8822CE part over USB and they >>> are running without problems with autosuspend enabled. While bringing up >>> a new board, I found some power regressions that I was able to narrow >>> down to this change so I'm requesting a revert. >>> >>> I tested this on Hp Chromebook 14a (running 4.14 kernel and 5.4 kernel) >>> with this revert: >>> * Enabled autosuspend, used it normally with a HID device >>> * Suspended the Chromebook and verified it worked normally on resume >>> * Rebooted the Chromebook and verified Bluetooth was working on next >>> boot >>> >>> I didn't see the issue that was originally reported with this fix. For >>> the original reporter, if you're still seeing this issue, there are >>> other ways to disable autosuspend for your device: >>> * set module param: enable_autosuspend=0 >>> * change your kconfig so BT_HCIBTUSB_AUTOSUSPEND=n >>> * use a udev rule to disable autosuspend for specific vid:pid >>> >>> Keeping this change in the kernel makes it impossible to enable >>> autosuspend so it should be reverted. >> >> It's apparently a driver/firmware/hardware issue, so the fix should keep inside the kernel. >> However, the fix can be more precise and target only 8723DE. > > lets do that and lets do it quickly since the merge window is close. Otherwise I really have to revert that patch. Ok, I no longer observe the original issue with the patch reverted. Acked-by: Kai-Heng Feng <kai.heng.feng@xxxxxxxxxxxxx> > > Regards > > Marcel >
