Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • L linux
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 141
    • Issues 141
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 24
    • Merge requests 24
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.

  • Librem5
  • linux
  • Merge requests
  • !672

hack: usb: core: hub: Add a quirk to disable selective suspend of a given port

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Sebastian Krzyszkowiak requested to merge sebastian.krzyszkowiak/linux-next:globalsuspend into pureos/byzantium Mar 08, 2023
  • Overview 8
  • Commits 2
  • Pipelines 3
  • Changes 3

This can be useful when wanting to rely on global suspend instead for improved wakeup latency and/or reliability.

Kernel's logical devices are still tracking PM status as usual so we know when to suspend the upstream hub.

Special care needs to be taken in order to still support remote wakeup functionality. When the port isn't being actually suspended, we have no idea which port has generated a wakeup request after resuming its hub because there's no change reported in port's status, so we force every port marked with this quirk to be resumed. Also, there's no way for the device to send remote wakeup request while it's not actually suspended, so we need to take care not to logically suspend such devices while a sibling port is active.

This code is likely to break on different USB topologies than the one present on the Librem 5's internal bus, where we want to use this quirk on modem's and hub's upstream ports in order to avoid resets happening when the modem sends remote wakeup request while the hub is being suspended.

Use together with udev rules:

ACTION=="add", SUBSYSTEM=="usb", ENV{ID_PATH}=="platform-xhci-hcd.4.auto-usb-0:0:1.0", ATTR{usb1-port1/quirks}="10000000"
ACTION=="add", SUBSYSTEM=="usb", ENV{ID_PATH}=="platform-xhci-hcd.4.auto-usb-0:1:1.0", ATTR{1-1-port2/quirks}="10000000", ATTR{1-1-port3/power/pm_qos_no_power_off}="0"

Should fix #303 (closed), maybe #197 (closed) too.

Edited Mar 08, 2023 by Sebastian Krzyszkowiak
Assignee
Assign to
Reviewer
Request review from
Time tracking
Source branch: globalsuspend