On Wed, 18 Sep 2019, Abhishek Pandit-Subedi wrote: > Sorry, last reply went out with HTML. Re-sending in plain text. > > On Wed, Sep 18, 2019 at 7:23 AM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On Tue, 17 Sep 2019, Abhishek Pandit-Subedi wrote: > > > > > On a Realtek USB bluetooth device, I wanted a simple and consistent way > > > to put the device in reset during suspend (2 reasons: to save power and > > > disable BT as a wakeup source). Resetting it in the suspend callback > > > causes a detach and the resume callback is not called. Hence the changes > > > in this series to do the reset in suspend_noirq. > > > > What about people who _want_ BT to be a wakeup source? > > When BT is enabled as a wakeup source, there is no reset. > > > Why does putting the device in reset save power? That is, a suspended > > device is very strictly limited in the amount of current it's allowed > > to draw from the USB bus; why should it draw significantly less when it > > is reset? > > I don't know that it's significantly less (only that it's OFF). My > greater motivation is to make sure the bluetooth chip isn't > accumulating events while the host is turned off. Sorry, I should have > made that more clear in the cover letter. > > When the host is off, it continues to accumulate events for the host > to process (packets from connected devices, LE advertisements, etc). > At some point, the firmware buffers fill up and no more events can be > stored. When the host is resumed later on, the firmware is in a bad > state and doesn't respond. I had originally just reset in ->resume but > then connected wireless devices wouldn't disconnect from the BT either > and I had trouble getting them to reconnect. > > > > > > I looked into using PERSIST and reset on resume but those seem mainly > > > for misbehaving devices that reset themselves. > > > > They are, but that doesn't mean you can't use them for other things > > too. > > > > > This patch series has been tested with Realtek BT hardware as well as > > > Intel BT (test procedure = disable as wake source, user suspend and > > > observe a detach + reattach on resume). > > > > This series really seems like overkill for a single kind of device. > > > > Is there any way to turn off the device's BT radio during suspend (if > > wakeup is disabled) and then turn it back on during resume? Wouldn't > > that accomplish what you want just as well? > > Probably (but I couldn't find a way to do that). There's no way to turn off the device's BT radio? Then what happens when the user turns off Bluetooth from the wireless control panel? > I want to prevent > bluetooth from waking up the host and to reliably be in a good state > when the host resumes. The reset logic I implemented causes the hci > device to disappear and reappear, which userspace seems to handle > gracefully. Have you tried out the persist/reset-on-resume approach? Alan Stern
