1. 24 May, 2013 3 commits
    • Tony Camuso's avatar
      xhci - correct comp_mode_recovery_timer on return from hibernate · 77df9e0b
      Tony Camuso authored
      Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP
      Hardware) was a workaround for systems using the SN65LVPE502CP,
      controller, but it introduced a bug in resume from hibernate.
      
      The fix created a timer, comp_mode_recovery_timer, which is deleted from
      a timer list when xhci_suspend() is called. However, the hibernate image,
      including the timer list containing the comp_mode_recovery_timer, had
      already been saved before the timer was deleted.
      
      Upon resume from hibernate, the list containing the comp_mode_recovery_timer
      is restored from the image saved to disk, and xhci_resume(), assuming that
      the timer had been deleted by xhci_suspend(), makes a call to
      compliance_mode_recoery_timer_init(), which creates a new instance of the
      comp_mode_recovery_timer and attempts to place it into the same list in which
      it is already active, thus corrupting the list during the list_add() call.
      
      At this point, a call trace is emitted indicating the list corruption.
      Soon afterward, the system locks up, the watchdog times out, and the
      ensuing NMI crashes the system.
      
      The problem did not occur when resuming from suspend. In suspend, the
      image in RAM remains exactly as it was when xhci_suspend() deleted the
      comp_mode_recovery_timer, so there is no problem when xhci_resume()
      creates a new instance of this timer and places it in the still empty
      list.
      
      This patch avoids the problem by deleting the timer in xhci_resume()
      when resuming from hibernate. Now xhci_resume() can safely make the
      call to create a new instance of this timer, whether returning from
      suspend or hibernate.
      
      Thanks to Alan Stern for his help with understanding the problem.
      
      [Sarah reworked this patch to cover the case where the xHCI restore
      register operation fails, and (temp & STS_SRE) is true (and we re-init
      the host, including re-init for the compliance mode), but hibernate is
      false.  The original patch would have caused list corruption in this
      case.]
      
      This patch should be backported to kernels as old as 3.2, that
      contain the commit 71c731a2 "usb: host:
      xhci: Fix Compliance Mode on SN65LVPE502CP Hardware"
      Signed-off-by: default avatarTony Camuso <tcamuso@redhat.com>
      Tested-by: default avatarTony Camuso <tcamuso@redhat.com>
      Acked-by: default avatarDon Zickus <dzickus@redhat.com>
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      77df9e0b
    • Vladimir Murzin's avatar
      xhci: fix list access before init · 88696ae4
      Vladimir Murzin authored
      If for whatever reason we fall into fail path in xhci_mem_init()
      before bw table gets initialized we may access the uninitialized lists
      in xhci_mem_cleanup().
      
      Check for bw table before traversing lists in cleanup routine.
      
      This patch should be backported to kernels as old as 3.2, that contain
      the commit 839c817c "xhci: Store
      information about roothubs and TTs."
      Reported-by: default avatarSergey Dyasly <dserrg@gmail.com>
      Tested-by: default avatarSergey Dyasly <dserrg@gmail.com>
      Signed-off-by: default avatarVladimir Murzin <murzin.v@gmail.com>
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      88696ae4
    • Sergio Aguirre's avatar
      xhci-mem: init list heads at the beginning of init · 331de00a
      Sergio Aguirre authored
      It is possible that we fail on xhci_mem_init, just before doing
      the INIT_LIST_HEAD, and calling xhci_mem_cleanup.
      
      Problem is that, the list_for_each_entry_safe macro, assumes
      list heads are initialized (not NULL), and dereferences their 'next'
      pointer, causing a kernel panic if this is not yet initialized.
      
      Let's protect from that by moving inits to the beginning.
      
      This patch should be backported to kernels as old as 3.2, that
      contain the commit 9574323c "xHCI: test
      USB2 software LPM".
      Signed-off-by: default avatarSergio Aguirre <sergio.a.aguirre.rodriguez@intel.com>
      Acked-by: default avatarDavid Cohen <david.a.cohen@intel.com>
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      331de00a
  2. 20 May, 2013 1 commit
  3. 17 May, 2013 19 commits
  4. 15 May, 2013 17 commits