How to Prevent USB Reset After Suspend on iMX6 Board?

[jrosa]

I am working on an iMX6ULL board running a Debian-based OS with suspend capabilities. A USB hub (USB2514) is connected to the USB bus. When a single device or two devices with different VID and PID are connected to the USB hub (and consequently to the USB bus) the system resumes from suspend almost immediately. However, the system resume is much slower when I have two devices connected to the USB hub with the same VID and PID. After digging, I found that the OS resets the USB devices after wake-up from suspend and before resuming (see code blocks below).

How can I prevent the OS from resetting the USB devices on wake-up to speed up the resume process when two devices with the same VID and PID are connected to the same bus?

Logs

• Single Device (Normal) Wake-up

>>>>>>>>>>>>>> SYSTEM WAKE-UP REQUEST
[ 9217.484783] ieee80211 phy6: brcmf_fil_cmd_data: bus is down. we have nothing to do.
[ 9217.484817] ieee80211 phy6: brcmf_cfg80211_get_tx_power: error (-5)
[ 9218.076812] PM: suspend devices took 1.640 seconds
[ 9218.082099] Disabling non-boot CPUs ...
[ 9218.330490] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[ 9218.399775] usb 2-1.1: reset high-speed USB device number 19 using ci_hdrc
[ 9218.476006] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Jun 13 2018 23:24:39 version 7.45.98.52 (r691997 CY) FWID 01-8b9f8ef5
[ 9218.552328] PM: resume devices took 0.470 seconds
[ 9218.608394] OOM killer enabled.
[ 9218.611611] Restarting tasks ... done.
[ 9218.714350] random: crng reseeded on system resumption
[ 9218.771424] PM: suspend exit
>>>>>>>>>>>>>> SYSTEM RESUME

• Two Devices Same VID and PID Wake-up

>>>>>>>>>>>>>> SYSTEM WAKE-UP REQUEST
[ 8907.844493] ieee80211 phy0: brcmf_fil_cmd_data: bus is down. we have nothing to do.
[ 8907.844524] ieee80211 phy0: brcmf_cfg80211_get_tx_power: error (-5)
[ 8908.436812] PM: suspend devices took 1.670 seconds
[ 8908.442572] Disabling non-boot CPUs ...
[ 8908.681128] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[ 8908.749956] usb 2-1.3: reset high-speed USB device number 13 using ci_hdrc
[ 8908.826696] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Jun 13 2018 23:24:39 version 7.45.98.52 (r691997 CY) FWID 01-8b9f8ef5
[ 8908.859973] usb 2-1.3: device no response, device descriptor read/64, error -71
[ 8909.089935] usb 2-1.3: device no response, device descriptor read/64, error -71
[ 8909.309918] usb 2-1.3: reset high-speed USB device number 13 using ci_hdrc
[ 8909.419914] usb 2-1.3: device no response, device descriptor read/64, error -71
[ 8909.649893] usb 2-1.3: device no response, device descriptor read/64, error -71
[ 8909.869896] usb 2-1.3: reset high-speed USB device number 13 using ci_hdrc
[ 8910.309878] usb 2-1.3: device not accepting address 13, error -71
[ 8910.409859] usb 2-1.3: reset high-speed USB device number 13 using ci_hdrc
[ 8910.849852] usb 2-1.3: device not accepting address 13, error -71
[ 8910.949853] usb 2-1.1: reset high-speed USB device number 14 using ci_hdrc
[ 8911.102358] PM: resume devices took 2.660 seconds
[ 8911.227343] OOM killer enabled.
[ 8911.230543] Restarting tasks ...
[ 8911.281057] usb 2-1.3: USB disconnect, device number 13
[ 8911.292238] done.
[ 8911.294268] random: crng reseeded on system resumption
[ 8911.351833] PM: suspend exit
>>>>>>>>>>>>>> SYSTEM RESUME

So far, I have attempted the following (without success):

• Applied udev rules to set the removable attribute to fixed or 0.
• Configured the USB hub's NON_REMpins, causing /sys/bus/usb/devices/2-1.1/removable to report as fixed.
• Modified /sys/bus/usb/devices/2-1.1:1.0/host0/target0:0:0/0:0:0:0/block/sda/removable by writing 0 or fixed, but this did not resolve the issue.
• Loaded the SCSI Generic (sg) kernel module, exposing the devices at /dev/sg*, but they remained listed under /dev/sd* as well.
• Blacklisted the usb-storage module, which caused the SCSI Generic module to stop functioning.

[jrosa · Accepted solution]

I solved the issue by adding the USB_QUIRK_DISCONNECT_SUSPEND USB quirk.