1. 02 12月, 2015 4 次提交
  2. 19 11月, 2015 3 次提交
    • M
      xhci: Fix a race in usb2 LPM resume, blocking U3 for usb2 devices · dad67d5f
      Mathias Nyman 提交于
      Clear device initiated resume variables once device is fully up and running
      in U0 state.
      
      Resume needs to be signaled for 20ms for usb2 devices before they can be
      moved to U0 state.
      
      An interrupt is triggered if a device initiates resume. As we handle the
      event in interrupt context we can not sleep for 20ms, so we instead set
      a resume flag, a timestamp, and start the roothub polling.
      
      The roothub code will later move the port to U0 when it finds a port in
      resume state with the resume flag set, and timestamp passed by 20ms.
      
      A host initiated resume is however not done in interrupt context, and
      host initiated resume code will directly signal resume, wait 20ms and then
      move the port to U0.
      
      These two codepaths can race, if we are in the middle of a host initated
      resume, while sleeping for 20ms, we may handle a port event and find the
      port in resume state. The port event handling code will assume the resume
      was device initiated and set the resume flag and timestamp.
      
      Root hub code will however not catch the port in resume state again as the
      host initated resume code has already moved the port to U0.
      The resume flag and timestamp will remain set for this port preventing port
      from suspending again  (LPM setting port to U3)
      
      Fix this for now by always clearing the device initated resume parameters
      once port is in U0
      
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dad67d5f
    • L
      usb: xhci: fix checking ep busy for CFC · 42df7215
      Lu Baolu 提交于
      Function ep_ring_is_processing() checks the dequeue pointer
      in endpoint context to know whether an endpoint is busy with
      processing TRBs. This is not correct since dequeue pointer
      field in an endpoint context is only valid when the endpoint
      is in Halted or Stopped states. This buggy code causes audio
      noise when playing sound with USB headset connected to host
      controllers which support CFC (one of xhci 1.1 features).
      
      This patch should exist in stable kernel since v4.3.
      Reported-and-tested-by: NYD Tseng <yd_tseng@asmedia.com.tw>
      Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
      Cc: stable <stable@vger.kernel.org> # v4.3
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      42df7215
    • R
      xhci: Workaround to get Intel xHCI reset working more reliably · a5964396
      Rajmohan Mani 提交于
      Existing Intel xHCI controllers require a delay of 1 mS,
      after setting the CMD_RESET bit in command register, before
      accessing any HC registers. This allows the HC to complete
      the reset operation and be ready for HC register access.
      Without this delay, the subsequent HC register access,
      may result in a system hang, very rarely.
      
      Verified CherryView / Braswell platforms go through over
      5000 warm reboot cycles (which was not possible without
      this patch), without any xHCI reset hang.
      Signed-off-by: NRajmohan Mani <rajmohan.mani@intel.com>
      Tested-by: NJoe Lawrence <joe.lawrence@stratus.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a5964396
  3. 10 11月, 2015 1 次提交
  4. 07 11月, 2015 1 次提交
    • M
      mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep... · d0164adc
      Mel Gorman 提交于
      mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd
      
      __GFP_WAIT has been used to identify atomic context in callers that hold
      spinlocks or are in interrupts.  They are expected to be high priority and
      have access one of two watermarks lower than "min" which can be referred
      to as the "atomic reserve".  __GFP_HIGH users get access to the first
      lower watermark and can be called the "high priority reserve".
      
      Over time, callers had a requirement to not block when fallback options
      were available.  Some have abused __GFP_WAIT leading to a situation where
      an optimisitic allocation with a fallback option can access atomic
      reserves.
      
      This patch uses __GFP_ATOMIC to identify callers that are truely atomic,
      cannot sleep and have no alternative.  High priority users continue to use
      __GFP_HIGH.  __GFP_DIRECT_RECLAIM identifies callers that can sleep and
      are willing to enter direct reclaim.  __GFP_KSWAPD_RECLAIM to identify
      callers that want to wake kswapd for background reclaim.  __GFP_WAIT is
      redefined as a caller that is willing to enter direct reclaim and wake
      kswapd for background reclaim.
      
      This patch then converts a number of sites
      
      o __GFP_ATOMIC is used by callers that are high priority and have memory
        pools for those requests. GFP_ATOMIC uses this flag.
      
      o Callers that have a limited mempool to guarantee forward progress clear
        __GFP_DIRECT_RECLAIM but keep __GFP_KSWAPD_RECLAIM. bio allocations fall
        into this category where kswapd will still be woken but atomic reserves
        are not used as there is a one-entry mempool to guarantee progress.
      
      o Callers that are checking if they are non-blocking should use the
        helper gfpflags_allow_blocking() where possible. This is because
        checking for __GFP_WAIT as was done historically now can trigger false
        positives. Some exceptions like dm-crypt.c exist where the code intent
        is clearer if __GFP_DIRECT_RECLAIM is used instead of the helper due to
        flag manipulations.
      
      o Callers that built their own GFP flags instead of starting with GFP_KERNEL
        and friends now also need to specify __GFP_KSWAPD_RECLAIM.
      
      The first key hazard to watch out for is callers that removed __GFP_WAIT
      and was depending on access to atomic reserves for inconspicuous reasons.
      In some cases it may be appropriate for them to use __GFP_HIGH.
      
      The second key hazard is callers that assembled their own combination of
      GFP flags instead of starting with something like GFP_KERNEL.  They may
      now wish to specify __GFP_KSWAPD_RECLAIM.  It's almost certainly harmless
      if it's missed in most cases as other activity will wake kswapd.
      Signed-off-by: NMel Gorman <mgorman@techsingularity.net>
      Acked-by: NVlastimil Babka <vbabka@suse.cz>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Vitaly Wool <vitalywool@gmail.com>
      Cc: Rik van Riel <riel@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d0164adc
  5. 28 10月, 2015 1 次提交
  6. 25 10月, 2015 3 次提交
    • V
      usb: host: lpc32xx: don't unregister phy device · 164f0aa8
      Vladimir Zapolskiy 提交于
      There is no need to unregister the I2C device, which serves as a phy
      from host code, this should be done in the correspondent phy driver.
      Signed-off-by: NVladimir Zapolskiy <vz@mleia.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      164f0aa8
    • V
      usb: host: lpc32xx: balance clk enable/disable on removal · b1a0c423
      Vladimir Zapolskiy 提交于
      The change adds missing clk_disable_unprepare(usb_otg_clk) call, also
      the disabled clocks are sorted in order opposite to enabled clocks.
      Signed-off-by: NVladimir Zapolskiy <vz@mleia.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b1a0c423
    • V
      usb: host: lpc32xx: fix warnings caused by enabling unprepared clock · 9ae79876
      Vladimir Zapolskiy 提交于
      If common clock framework is configured, the driver generates a warning,
      which is fixed by this change:
      
          WARNING: CPU: 0 PID: 573 at drivers/clk/clk.c:728 clk_core_enable+0x2c/0xf0()
          Modules linked in: ohci_nxp(+) sc16is7xx snd_soc_uda1380
          CPU: 0 PID: 573 Comm: udevd Not tainted 4.3.0-rc2+ #285
          Hardware name: LPC32XX SoC (Flattened Device Tree)
          Backtrace:
          [<>] (dump_backtrace) from [<>] (show_stack+0x18/0x1c)
          [<>] (show_stack) from [<>] (dump_stack+0x20/0x28)
          [<>] (dump_stack) from [<>] (warn_slowpath_common+0x90/0xb8)
          [<>] (warn_slowpath_common) from [<>] (warn_slowpath_null+0x24/0x2c)
          [<>] (warn_slowpath_null) from [<>] (clk_core_enable+0x2c/0xf0)
          [<>] (clk_core_enable) from [<>] (clk_enable+0x24/0x38)
          [<>] (clk_enable) from [<>] (ohci_hcd_nxp_probe+0x1d0/0x518 [ohci_nxp])
          [<>] (ohci_hcd_nxp_probe [ohci_nxp]) from [<>] (platform_drv_probe+0x50/0xa0)
          [<>] (platform_drv_probe) from [<>] (driver_probe_device+0x18c/0x408)
          [<>] (driver_probe_device) from [<>] (__driver_attach+0x70/0x94)
          [<>] (__driver_attach) from [<>] (bus_for_each_dev+0x74/0x98)
          [<>] (bus_for_each_dev) from [<>] (driver_attach+0x20/0x28)
          [<>] (driver_attach) from [<>] (bus_add_driver+0x11c/0x248)
          [<>] (bus_add_driver) from [<>] (driver_register+0xa4/0xe8)
          [<>] (driver_register) from [<>] (__platform_driver_register+0x50/0x64)
          [<>] (__platform_driver_register) from [<>] (ohci_nxp_init+0x3c/0x5c [ohci_nxp])
          [<>] (ohci_nxp_init [ohci_nxp]) from [<>] (do_one_initcall+0x11c/0x1dc)
          [<>] (do_one_initcall) from [<>] (do_init_module+0x60/0x368)
          [<>] (do_init_module) from [<>] (load_module+0x16d0/0x1b7c)
          [<>] (load_module) from [<>] (SyS_finit_module+0x90/0xa4)
          [<>] (SyS_finit_module) from [<>] (ret_fast_syscall+0x0/0x38)
      Signed-off-by: NVladimir Zapolskiy <vz@mleia.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9ae79876
  7. 18 10月, 2015 1 次提交
  8. 17 10月, 2015 18 次提交
  9. 05 10月, 2015 1 次提交
  10. 04 10月, 2015 7 次提交