Hi Sherry, On Wed, Jan 6, 2021 at 5:40 AM Sherry Sun <sherry.sun@xxxxxxx> wrote: > > Hi Abhishek, > > I want to ask you some questions about your patch: Bluetooth: Handle BR/EDR devices during suspend. (https://patchwork.kernel.org/project/bluetooth/patch/20200311085359.RFC.v6.2.Icc7c35e1cabf10f8a383a009694987520f1d1b35@changeid/) > > Platform: L5.10 + Bluez5.55 + Marvell BT chip > > Background: Our test team usually try suspend/resume test when transferring large file through BT, to see if the file transfer can be continued after suspend/resume. It can works well before L5.10 > But we found on L5.10, the BT connection lost if we try to suspend/resume, so the file transfer(through OBEX Object Push) shows failed. Then we found your patches when debugging. > > Questions: > 1. Before L5.10, kernel always keep BT connected during suspend/resume. So why we need to disconnect all the BT devices when system suspend now? Bluetooth has often been a source of spurious wakes in the past. Using rfkill or masking the wake interrupt were used in the past to make this more reliable but this was resulting in instability on the controller (controller needs to drop traffic if host is asleep and there's no clean way to do that). The new suspend behavior is the following: - All devices get disconnected during suspend. - Only HID devices can wake the device from suspend (i.e. Remote Wake). The BT controller will be configured to scan (page scan and/or LE passive scan) based on currently paired devices. If the device is not configured for wakeup (i.e. power/wakeup in sysfs is "disabled"), we will not configure this scanning either (see the hdev->prevent_wake implementation in btusb for an example) - On resume, devices that support a2dp-sink will be automatically reconnected This results in more reliable behavior from Bluetooth around suspend while allowing Remote Wake to work properly. > 2. I found that the device been disconnected due to suspend won't been auto-connected after resume, shouldn't we get the BT device auto-connected after resume like wifi devices done? We do this currently only for Bluetooth headphones (reconnect on a2dp-sink service). I'm not familiar with Obex so I don't know if this would work for that as well. I did send up a patch making reconnect on resume configurable based on service uuid that may be relevant to this: https://patchwork.kernel.org/project/bluetooth/patch/20201207154903.bluez.1.I3e043a481273442748bcff0728b2f0e208017cd2@changeid/ > 3. For the large file transfer, if the BT been disconnected during suspend, the transfer will fail, do we have any methods to avoid this issue? If you have an active transfer, does it make sense to be suspending? Perhaps you should hold a wakelock while a transfer is ongoing. I am not sure how Obex and other services should behave here so I will defer to Luiz and Marcel's opinion on this topic. > > I'm new to Bluetooth, there are many things I don't understand, looking forward to your answer, and thanks for now! > > Best regards > Sherry sun > Thanks Abhishek
