Hi Abhishek, Gentle ping, looking forward to your reply! Best regards Sherry > -----Original Message----- > From: Sherry Sun > Sent: 2021年1月7日 11:13 > To: Abhishek Pandit-Subedi <abhishekpandit@xxxxxxxxxxxx> > Cc: linux-bluetooth@xxxxxxxxxxxxxxx; marcel@xxxxxxxxxxxx; > johan.hedberg@xxxxxxxxx > Subject: RE: BT large file transfer failed when do suspend/resume test > > 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%2Fp > > > at > > > > > > 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%2Fpatc > > h > 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
