Hi Abhishek, thanks for you answer, please see my reply below. > -----Original Message----- > From: Abhishek Pandit-Subedi <abhishekpandit@xxxxxxxxxxxx> > Sent: 2021年1月7日 3:02 > To: Sherry Sun <sherry.sun@xxxxxxx> > Cc: linux-bluetooth@xxxxxxxxxxxxxxx; marcel@xxxxxxxxxxxx; > johan.hedberg@xxxxxxxxx > Subject: Re: BT large file transfer failed when do suspend/resume test > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat > > > chwork.kernel.org%2Fproject%2Fbluetooth%2Fpatch%2F20200311085359.RF > C.v > > > 6.2.Icc7c35e1cabf10f8a383a009694987520f1d1b35%40changeid%2F&da > ta=0 > > > 4%7C01%7Csherry.sun%40nxp.com%7C9d41a6725ac1432355c408d8b275970 > 0%7C686 > > > ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637455565422685536%7CU > nknown%7 > > > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi > LCJXV > > > CI6Mn0%3D%7C1000&sdata=56h1%2BfVflqDZsx%2FcIbtUfa6kcPjV4p2n > cxPf1uA > > a7iY%3D&reserved=0) > > > > 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) So for HID devices, they also been disconnected when suspend and auto reconnected when resume, right? > - On resume, devices that support a2dp-sink will be automatically > reconnected > I just tried a2dp-sink devices(BT headphones), and it wasn't reconnected after system resume. I checked your patches which to supported a2dp-sink auto reconnect, and found them may didn't been included in bluez5.55, can you help confirm that? > This results in more reliable behavior from Bluetooth around suspend while > allowing Remote Wake to work properly. > Yes, it' reasonable, but I think it may need to reconnect all the devices which are disconnected due to suspend, right? Otherwise for the user, when we connect the BT, which means we do want to use the BT device, but every time when system get into suspend, we will need to reconnect the device manually, it's really inconvenient. > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch > work.kernel.org%2Fproject%2Fbluetooth%2Fpatch%2F20201207154903.blue > z.1.I3e043a481273442748bcff0728b2f0e208017cd2%40changeid%2F&d > ata=04%7C01%7Csherry.sun%40nxp.com%7C9d41a6725ac1432355c408d8b2 > 759700%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6374555654 > 22685536%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi > V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6zZda8Yu > RRbAMkwOxiSwjbJIpvi%2ByMSDWCzVkFkkpzs%3D&reserved=0 > Why here only add a2dp-sink device auto reconnect support? Why not add all the devices auto reconnect support which are disconnected due to suspend? > > 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 not sure whether it's reasonable, our drivers seems can be suspended during transfer file and A2DP playing. Maybe we really need a wakelock here. Thanks and regards Sherry > > > > > 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
