Hi Rafael, I left a comment on the bugzilla post as well but I agree with you now that it's probably bad to fail suspend when this occurs. At https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/bluetooth/hci_core.c#n3363, we try to recover from a failed suspend by restoring running state and returning an -EBUSY. I think if we change this logic to not attempt to restore until resume, log the error and allow suspend, that would probably be preferable from a suspend perspective. I will make this change, test it out and send the patch today. Thanks Abhishek On Wed, Jun 3, 2020 at 9:16 AM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > Hi Marcel, > > Unfortunately, we are observing system suspend failures on multiple > lab machines as reported in the BZ entry at > > https://bugzilla.kernel.org/show_bug.cgi?id=207629 > > which is due to the following commit: > > commit dd522a7429b07e4441871ae75ebbfcf53635bdd4 > Author: Abhishek Pandit-Subedi <abhishekpandit@xxxxxxxxxxxx> > Date: Wed Mar 11 08:54:02 2020 -0700 > > Bluetooth: Handle LE devices during suspend > > Ostensibly, this is because the BT firmware on the machines in > question does not match the new kernel code, but the firmware update > requirement is not entirely obvious to the users and the steps to take > in order to upgrade the firmware are not clear. > > Apart from the above, failing system suspend for a reason like a > protocol timeout isn't really user-friendly, because the user may just > have closed the lid of a laptop and is expecting the system to be > suspended (so it may go into a backpack or similar). Yes, the driver > may not be able to suspend its device gracefully, but failing the > entire system suspend really is a big deal and should be treated as a > last-resort type of action. > > As stated in the BZ above, reverting the above commit along with > "Bluetooth: Pause discovery and advertising during suspend" > (4867bd007d25a8dfd4ffc558534f7aec8b361789) makes the issue go away, so > can you please consider doing that? > > Alternatively, would it be possible to address the issue in a way that > would not require many users to update firmware on their systems? > > Cheers, > Rafael
