1. 24 May, 2022 1 commit
    • Martin Kepplinger's avatar
      hack: drm/panel: mantix: remove shutdown callback · 51b577a4
      Martin Kepplinger authored
      marked as "hack" because we don't yet know what exactly broke the
      shutdown callback.
      
      For Linux v5.18-rc1 and later, the below regulator underflows happen
      when shutting down. Remove the shutdown callback from the driver to work
      around this.
      
      [ 1584.383268] ------------[ cut here ]------------
      [ 1584.388285] unbalanced disables for LCD_AVEE
      [ 1584.392955] WARNING: CPU: 2 PID: 1 at drivers/regulator/core.c:2852 _regulator_disable+0xdc/0x194
      [ 1584.619168] Call trace:
      [ 1584.621656]  _regulator_disable+0xdc/0x194
      [ 1584.625797]  regulator_disable+0x48/0x8c
      [ 1584.629733]  mantix_unprepare+0x50/0x94
      [ 1584.633637]  drm_panel_unprepare+0x34/0x50
      [ 1584.637794]  mantix_shutdown+0x2c/0x44
      [ 1584.641579]  mipi_dsi_drv_shutdown+0x2c/0x40
      [ 1584.645895]  device_shutdown+0x160/0x340
      [ 1584.649881]  __do_sys_reboot+0x1d8/0x25c
      [ 1584.653865]  __arm64_sys_reboot+0x30/0x40
      [ 1584.657937]  invoke_syscall+0x50/0x120
      [ 1584.661723]  el0_svc_common.constprop.0+0x4c/0xf4
      [ 1584.666494]  do_el0_svc+0x28/0x3c
      [ 1584.669818]  el0_svc+0x2c/0x84
      [ 1584.672965]  el0t_64_sync_handler+0x1a4/0x1b0
      [ 1584.677331]  el0t_64_sync+0x18c/0x190
      [ 1584.681072] ---[ end trace 0000000000000000 ]---
      [ 1584.685990] ------------[ cut here ]------------
      [ 1584.690650] unbalanced disables for LCD_AVDD
      [ 1584.694990] WARNING: CPU: 2 PID: 1 at drivers/regulator/core.c:2852 _regulator_disable+0xdc/0x194
      [ 1584.920444] Call trace:
      [ 1584.922922]  _regulator_disable+0xdc/0x194
      [ 1584.927054]  regulator_disable+0x48/0x8c
      [ 1584.931013]  mantix_unprepare+0x58/0x94
      [ 1584.934912]  drm_panel_unprepare+0x34/0x50
      [ 1584.939021]  mantix_shutdown+0x2c/0x44
      [ 1584.942806]  mipi_dsi_drv_shutdown+0x2c/0x40
      [ 1584.947112]  device_shutdown+0x160/0x340
      [ 1584.951070]  __do_sys_reboot+0x1d8/0x25c
      [ 1584.955029]  __arm64_sys_reboot+0x30/0x40
      [ 1584.959072]  invoke_syscall+0x50/0x120
      [ 1584.962859]  el0_svc_common.constprop.0+0x4c/0xf4
      [ 1584.967627]  do_el0_svc+0x28/0x3c
      [ 1584.970952]  el0_svc+0x2c/0x84
      [ 1584.974042]  el0t_64_sync_handler+0x1a4/0x1b0
      [ 1584.978433]  el0t_64_sync+0x18c/0x190
      [ 1584.982130] ---[ end trace 0000000000000000 ]---
      [ 1584.993964] LCD_1V8: Underflow of regulator enable count
      51b577a4
  2. 17 May, 2022 1 commit
  3. 16 May, 2022 4 commits
    • Martin Kepplinger's avatar
      Merge tag 'v5.17.8' into stable/5.17.8 · d1499432
      Martin Kepplinger authored
      This is the 5.17.8 stable release
      d1499432
    • Sarah Sharp's avatar
      [RFT & RFC] USB: Fix USB device disconnects on resume. · 815d00ff
      Sarah Sharp authored and Martin Kepplinger's avatar Martin Kepplinger committed
      
      
      The TLDR; version:
      
      We've assumed that when a device disconnects after a resume from device
      suspend, it was just a cheap, buggy device.  It turns out that the USB
      core simply wasn't waiting long enough for the devices to transition
      from resume to U0, and it's actually been the USB core's fault all
      along...
      
       * * Please go test this patch with your "buggy" USB devices. * *
      
      Background
      ----------
      
      The USB 2.0 specification, section 7.1.7.7, says that upon device remote
      wakeup signaling, the first active hub (which is often the roothub) must
      rebroadcast the resume signaling for at least 20 ms (TDRSMDN).  After
      that's done, the hub's suspend status change bit will be set, and system
      software must not access the device for at least 10 ms (TRSMRCY).
      
      It turns out that TRSMRCY is a *minimum*, not a *maximum*, according to
      Table 7-14.  That means the port can actually take longer than TRSMRCY
      to resume.  Any attempt to communicate with the device, or reset the
      device, will result in a USB device disconnect.
      
      This discrepancy was found with the Intel xHCI host controller, because
      they handle USB 2.0 resume a little differently than EHCI.  See the xHCI
      spec, Figure 34: USB2 Root Hub Port Enabled Substate Diagram for
      details.
      
      Under EHCI, the host controller driver receives an interrupt when the
      port suspend status change bit is set, and the USB core only has to time
      the 10ms TRSMRCY value.
      
      Under xHCI, the host receives an interrupt when the device remote wake
      is first signaled, and the port goes into the Resume state.  The xHCI
      driver kicks khubd, but doesn't allow the suspend state change to be
      exposed until 20 ms (TDRSMDN) after the port status change event occurs.
      
      Then, when the USB core calls into get port status, it transitions the
      port from the Resume state to the RExit state by changing the port link
      state to U0.  The xHCI driver will get a port status change event when
      that transition is complete, but that port status change event is
      currently ignored.
      
      What actually happens
      ---------------------
      
      By busy-waiting with xhci_handshake() after the Lynx Point LP host
      initiates the transition to U0, and printing out how long it took, it
      turns out that roughly 8% of the time, the host takes longer than 10 ms
      to transition from RExit to U0.
      
      Out of 227 remote wakeup events from a USB mouse and keyboard:
       - 163 transitions from RExit to U0 were immediate ( < 1 microsecond)
       - 47 transitions from RExit to U0 took under 10 ms
       - 17 transitions were over 10ms
      
      Those 17 transitions (in microseconds) took:
      
      10140
      10305
      10650
      10659
      10677
      10695
      10819
      10907
      10998
      11030
      11234
      11618
      11656
      11724
      11898
      12060
      12162
      12757
      
      The end result of that is that on 8% of remote wake events, the USB core
      would attempt to communicate with the device before it was fully
      resumed, causing USB disconnects or transfer errors on the next control
      transfer to get the device status.
      
      This bug has been reproduced under ChromeOS, which is very aggressive
      about USB power management.  It enables auto-suspend for all internal
      USB devices (wifi and bluetooth), and the disconnects wreck havoc on
      those devices, causing the ChromeOS GUIs to repeatedly flash the USB
      wifi setup screen on user login.  ChromeOS sets the autosuspend_delay_ms
      to 100 milliseconds, and disables USB device persist.  I can reproduce
      this bug with a vanilla 3.10.7 kernel under ChromeOS.
      
      Possible fixes
      --------------
      
      The USB core obviously needs to be changed to check the port status
      after the TRSMRCY timeout, and continue to wait if the port is still in
      the resuming state.  I will have to study the EHCI port status diagrams
      in detail to figure out how the USB core can do this.  I can easily do
      this without the USB core being involved, by changing the xHCI driver to
      either:
      
      1. Busy wait with xhci_handshake() in the xHCI get port status until
         the port is in U0.
      
      2. Add a completion per xHCI port.  In xHCI get port status, initiate
         U0 entry, and wait on the port's completion for up to 20 ms.  In the
         port status change event code, complete that port's completion when
         the port is in U0 and the bus_state->resuming_ports bit is set.
      
      In the meantime, simply increasing TRSMRCY from 10 ms to 20 ms solves
      the resume issue on the Intel xHCI host.  Please test this patch under
      other host controllers to see if it helps "fix" your buggy devices.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      815d00ff
    • Martin Kepplinger's avatar
      usb: xhci: increase XHCI_MAX_REXIT_TIMEOUT_MS · a51508ef
      Martin Kepplinger authored
      40ms were suggested on the mainling lists even, see
      https://lore.kernel.org/linux-usb/a66bd7ff8356cc0d97073ae41d128eabb74cc94d.camel@puri.sm/
      
      simply trying to work around this:
      
      Mär 18 08:41:00.006534 pureos kernel: xhci-hcd xhci-hcd.4.auto: HC died; cleaning up
      Mär 18 08:41:00.005594 pureos kernel: xhci-hcd xhci-hcd.4.auto: xHCI host controller not responding, as>
      Mär 18 08:41:00.003925 pureos kernel: xhci-hcd xhci-hcd.4.auto: Abort failed to stop command ring: -110
      Mär 18 08:40:44.606136 pureos kernel: xhci-hcd xhci-hcd.4.auto: Port resume timed out, port 1-1: 0xfe3
      a51508ef
    • Martin Kepplinger's avatar
      usb: quirks: hub_slow_reset for usb2642 · d5996a57
      Martin Kepplinger authored
      This reduces the cases where the host controller is dying after
      "reset_resume" during runtime-resume has been being executed.
      
      Usually you'd see
      
      [ 1575.824244] usb 1-1.2: reset high-speed USB device number 4 using xhci-hcd
      [ 1575.904083] usb 1-1.2: device descriptor read/64, error -71
      [ 1576.148256] usb 1-1.2: USB disconnect, device number 4
      (...)
      [ 1653.948112] xhci-hcd xhci-hcd.4.auto: Port resume timed out, port 1-1: 0xfe3
      [ 1664.284277] xhci-hcd xhci-hcd.4.auto: xHCI host not responding to stop endpoint command.
      [ 1664.284485] xhci-hcd xhci-hcd.4.auto: USBSTS:
      [ 1664.292619] xhci-hcd xhci-hcd.4.auto: xHCI host controller not responding, assume dead
      [ 1664.300906] xhci-hcd xhci-hcd.4.auto: HC died; cleaning up
      d5996a57
  4. 15 May, 2022 13 commits
  5. 12 May, 2022 21 commits