3

On my 18.04 machine with stock kernel 4.15, I'm using a run-of-the-mill CSR Bluetooth dongle. Problem now is that the machine will not suspend properly when that dongle is plugged in - it will go to sleep for something between 5 and 10 seconds, but then resume on its own, even if no Bluetooth devices are currently connected or even powered on. When I unplug the dongle before suspend, it stays suspended as it should.

I could just turn off USB wakeup entirely, but I was hoping there's a more nuanced solution that just prevents wakeup via the Bluetooth dongle...

lsusb, usb-devices, hcitool output for dongle:

Bus 001 Device 007: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

T:  Bus=01 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#=  7 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0a12 ProdID=0001 Rev=88.91
S:  Product=CSR8510 A10
C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

hci0:   Type: Primary  Bus: USB
    BD Address: xx:xx:xx:xx:xx:xx  ACL MTU: 310:10  SCO MTU: 64:8
    UP RUNNING PSCAN 
    RX bytes:124465 acl:0 sco:0 events:3928 errors:0
    TX bytes:3182 acl:0 sco:0 commands:51 errors:0
    Features: 0xff 0xff 0x8f 0xfe 0xdb 0xff 0x5b 0x87
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
    Link policy: RSWITCH HOLD SNIFF PARK 
    Link mode: SLAVE ACCEPT 
    Name: 'monolith'
    Class: 0x0c0104
    Service Classes: Rendering, Capturing
    Device Class: Computer, Desktop workstation
    HCI Version: 4.0 (0x6)  Revision: 0x22bb
    LMP Version: 4.0 (0x6)  Subversion: 0x22bb
    Manufacturer: Cambridge Silicon Radio (10)
karel
  • 114,770
Florian Echtler
  • 2,658

1 Answers1

1

Power off device during suspend, power on during resume

From this answer:

You can create a script called /lib/systemd/system-sleep/cambridge.sh

#!/bin/bash
ZeroBUS1=$(lsusb | grep 0a12:0001 | cut -c  5-7 )
BUS1=$(echo $ZeroBUS1 | sed 's/^0*//') # Strip leading zeros
ZeroBUS2=$(lsusb | grep 0a12:0001 | cut -c  16-18 )
BUS2=$(echo $ZeroBUS2 | sed 's/^0*//') # Strip leading zeros
BUS="$BUS1"-"$BUS2"    

case $1 in
    suspend|suspend_hybrid|hibernate)
        echo "Powering off: $BUS"
        echo "$BUS" | sudo tee /sys/bus/usb/drivers/usb/unbind
        ;;
    resume|thaw)
        echo "Powering on: $BUS"
        echo "$BUS" | sudo tee /sys/bus/usb/drivers/usb/bind
        ;;
esac

Mark the file as executable with 

sudo chmod a+x /lib/systemd/system-sleep/cambridge.sh

You may need to reboot for changes to take effect.

WinEunuuchs2Unix
  • 102,282
  • But this turns of the entire bus, right? I'd still like the machine to wake up via other USB devices... – Florian Echtler Sep 22 '19 at 20:23
  • The link does contain method to turn off all USB buses but the answer here is just for device: 0a12:0001 – WinEunuuchs2Unix Sep 22 '19 at 20:30
  • Mmh, I don't think so. This script still turns off the entire bus which the device 0a12:0001 is connected to. – Florian Echtler Sep 22 '19 at 21:04
  • It's been awhile since I looked at that script. I've changed it from entire BUS to specific device on the BUS. – WinEunuuchs2Unix Sep 23 '19 at 01:25
  • OK, so I tested this and there's two issues with the script: one is that BUS2 variable is still based on ZeroBUS1 instead of ZeroBUS2 (probably copy-paste error). But the other, more important issue is that the bus/device numbers don't correspond to the sysfs identifiers, and that is what the [un]bind node in sysfs expects (e.g. something like "3-13.2"). – Florian Echtler Sep 27 '19 at 21:50
  • Thanks for pointing out the typio. I actually typed and tested directly in the terminal. The system didn't complain with echo "$BUS" | sudo tee /sys/bus/usb/drivers/usb/unbind unless it was already unbound. Perhaps I need a different device to test. – WinEunuuchs2Unix Sep 27 '19 at 22:00