1. 17 Oct, 2015 3 commits
    • Laura Abbott's avatar
      xhci: Add spurious wakeup quirk for LynxPoint-LP controllers · fd7cd061
      Laura Abbott authored
      We received several reports of systems rebooting and powering on
      after an attempted shutdown. Testing showed that setting
      XHCI_SPURIOUS_WAKEUP quirk in addition to the XHCI_SPURIOUS_REBOOT
      quirk allowed the system to shutdown as expected for LynxPoint-LP
      xHCI controllers. Set the quirk back.
      
      Note that the quirk was originally introduced for LynxPoint and
      LynxPoint-LP just for this same reason. See:
      
      commit 638298dc ("xhci: Fix spurious wakeups after S5 on Haswell")
      
      It was later limited to only concern HP machines as it caused
      regression on some machines, see both bug and commit:
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171
      commit 6962d914 ("xhci: Limit the spurious wakeup fix only to HP machines")
      
      Later it was discovered that the powering on after shutdown
      was limited to LynxPoint-LP (Haswell-ULT) and that some non-LP HP
      machine suffered from spontaneous resume from S3 (which should
      not be related to the SPURIOUS_WAKEUP quirk at all). An attempt
      to fix this then removed the SPURIOUS_WAKEUP flag usage completely.
      
      commit b45abacd ("xhci: no switching back on non-ULT Haswell")
      
      Current understanding is that LynxPoint-LP (Haswell ULT) machines
      need the SPURIOUS_WAKEUP quirk, otherwise they will restart, and
      plain Lynxpoint (Haswell) machines may _not_ have the quirk
      set otherwise they again will restart.
      Signed-off-by: default avatarLaura Abbott <labbott@fedoraproject.org>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: Oliver Neukum <oneukum@suse.com>
      [Added more history to commit message -Mathias]
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fd7cd061
    • Mathias Nyman's avatar
      xhci: handle no ping response error properly · 3b4739b8
      Mathias Nyman authored
      If a host fails to wake up a isochronous SuperSpeed device from U1/U2
      in time for a isoch transfer it will generate a "No ping response error"
      Host will then move to the next transfer descriptor.
      
      Handle this case in the same way as missed service errors, tag the
      current TD as skipped and handle it on the next transfer event.
      
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3b4739b8
    • Mathias Nyman's avatar
      xhci: don't finish a TD if we get a short transfer event mid TD · e210c422
      Mathias Nyman authored
      If the difference is big enough between the bytes asked and received
      in a bulk transfer we can get a short transfer event pointing to a TRB in
      the middle of the TD. We don't want to handle the TD yet as we will anyway
      receive a new event for the last TRB in the TD.
      
      Hold off from finishing the TD and removing it from the list until we
      receive an event for the last TRB in the TD
      
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e210c422
  2. 11 Oct, 2015 8 commits
  3. 10 Oct, 2015 12 commits
  4. 09 Oct, 2015 10 commits
  5. 08 Oct, 2015 7 commits
    • Mikulas Patocka's avatar
      crash in md-raid1 and md-raid10 due to incorrect list manipulation · a452744b
      Mikulas Patocka authored
      The commit 55ce74d4 (md/raid1: ensure
      device failure recorded before write request returns) is causing crash in
      the LVM2 testsuite test shell/lvchange-raid.sh. For me the crash is 100%
      reproducible.
      
      The reason for the crash is that the newly added code in raid1d moves the
      list from conf->bio_end_io_list to tmp, then tests if tmp is non-empty and
      then incorrectly pops the bio from conf->bio_end_io_list (which is empty
      because the list was alrady moved).
      
      Raid-10 has a similar bug.
      
      Kernel Fault: Code=15 regs=000000006ccb8640 (Addr=0000000100000000)
      CPU: 3 PID: 1930 Comm: mdX_raid1 Not tainted 4.2.0-rc5-bisect+ #35
      task: 000000006cc1f258 ti: 000000006ccb8000 task.ti: 000000006ccb8000
      
           YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
      PSW: 00001000000001001111111000001111 Not tainted
      r00-03  000000ff0804fe0f 000000001059d000 000000001059f818 000000007f16be38
      r04-07  000000001059d000 000000007f16be08 0000000000200200 0000000000000001
      r08-11  000000006ccb8260 000000007b7934d0 0000000000000001 0000000000000000
      r12-15  000000004056f320 0000000000000000 0000000000013dd0 0000000000000000
      r16-19  00000000f0d00ae0 0000000000000000 0000000000000000 0000000000000001
      r20-23  000000000800000f 0000000042200390 0000000000000000 0000000000000000
      r24-27  0000000000000001 000000000800000f 000000007f16be08 000000001059d000
      r28-31  0000000100000000 000000006ccb8560 000000006ccb8640 0000000000000000
      sr00-03  0000000000249800 0000000000000000 0000000000000000 0000000000249800
      sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000
      
      IASQ: 0000000000000000 0000000000000000 IAOQ: 000000001059f61c 000000001059f620
       IIR: 0f8010c6    ISR: 0000000000000000  IOR: 0000000100000000
       CPU:        3   CR30: 000000006ccb8000 CR31: 0000000000000000
       ORIG_R28: 000000001059d000
       IAOQ[0]: call_bio_endio+0x34/0x1a8 [raid1]
       IAOQ[1]: call_bio_endio+0x38/0x1a8 [raid1]
       RP(r2): raid_end_bio_io+0x88/0x168 [raid1]
      Backtrace:
       [<000000001059f818>] raid_end_bio_io+0x88/0x168 [raid1]
       [<00000000105a4f64>] raid1d+0x144/0x1640 [raid1]
       [<000000004017fd5c>] kthread+0x144/0x160
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Fixes: 55ce74d4 ("md/raid1: ensure device failure recorded before write request returns.")
      Fixes: 95af587e ("md/raid10: ensure device failure recorded before write request returns.")
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      a452744b
    • Srinivas Pandruvada's avatar
      cpufreq: prevent lockup on reading scaling_available_frequencies · 55582bcc
      Srinivas Pandruvada authored
      When scaling_available_frequencies is read on an offlined cpu, then
      either lockup or junk values are displayed. This is caused by
      freed freq_table, which policy is using.
      Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      55582bcc
    • Srinivas Pandruvada's avatar
      cpufreq: acpi_cpufreq: prevent crash on reading freqdomain_cpus · e2530367
      Srinivas Pandruvada authored
      When freqdomain_cpus attribute is read from an offlined cpu, it will
      cause crash. This change prevents calling cpufreq_show_cpus when
      policy driver_data is NULL.
      
      Crash info:
      
      [  170.814949] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
      [  170.814990] IP: [<ffffffff813b2490>] _find_next_bit.part.0+0x10/0x70
      [  170.815021] PGD 227d30067 PUD 229e56067 PMD 0
      [  170.815043] Oops: 0000 [#2] SMP
      [  170.816022] CPU: 3 PID: 3121 Comm: cat Tainted: G      D    OE   4.3.0-rc3+ #33
      ...
      ...
      [  170.816657] Call Trace:
      [  170.816672]  [<ffffffff813b2505>] ? find_next_bit+0x15/0x20
      [  170.816696]  [<ffffffff8160e47c>] cpufreq_show_cpus+0x5c/0xd0
      [  170.816722]  [<ffffffffa031a409>] show_freqdomain_cpus+0x19/0x20 [acpi_cpufreq]
      [  170.816749]  [<ffffffff8160e65b>] show+0x3b/0x60
      [  170.816769]  [<ffffffff8129b31c>] sysfs_kf_seq_show+0xbc/0x130
      [  170.816793]  [<ffffffff81299be3>] kernfs_seq_show+0x23/0x30
      [  170.816816]  [<ffffffff81240f2c>] seq_read+0xec/0x390
      [  170.816837]  [<ffffffff8129a64a>] kernfs_fop_read+0x10a/0x160
      [  170.816861]  [<ffffffff8121d9b7>] __vfs_read+0x37/0x100
      [  170.816883]  [<ffffffff813217c0>] ? security_file_permission+0xa0/0xc0
      [  170.816909]  [<ffffffff8121e2e3>] vfs_read+0x83/0x130
      [  170.816930]  [<ffffffff8121f035>] SyS_read+0x55/0xc0
      ...
      ...
      [  170.817185] ---[ end trace bc6eadf82b2b965a ]---
      Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Cc: 4.2+ <stable@vger.kernel.org> # 4.2+
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e2530367
    • ludovic.desroches@atmel.com's avatar
      mmc: sdhci-of-at91: use SDHCI_QUIRK2_NEED_DELAY_AFTER_INT_CLK_RST quirk · 88c6eb0e
      ludovic.desroches@atmel.com authored
      The Atmel sdhci device needs the
      SDHCI_QUIRK2_NEED_DELAY_AFTER_INT_CLK_RST quirk. Without it, the
      internal clock could never stabilised when changing the sd clock
      frequency.
      Signed-off-by: default avatarLudovic Desroches <ludovic.desroches@atmel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      88c6eb0e
    • ludovic.desroches@atmel.com's avatar
      mmc: sdhci: add quirk SDHCI_QUIRK2_NEED_DELAY_AFTER_INT_CLK_RST · af951761
      ludovic.desroches@atmel.com authored
      The Atmel sdhci device needs a new quirk. sdhci_set_clock set the Clock
      Control Register to 0 before computing the new value and writing it.
      It disables the internal clock which causes a reset mecanism. If we
      write the new value before this reset mecanism is done, it will prevent
      the stabilisation of the internal clock, so a delay is needed. This
      delay is about 2-3 cycles of the base clock. To be safe, a 1 ms delay is
      used.
      Signed-off-by: default avatarLudovic Desroches <ludovic.desroches@atmel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      af951761
    • Marcin Wojtas's avatar
      mmc: sdhci-pxav3: fix error handling of armada_38x_quirks · 2162d9f4
      Marcin Wojtas authored
      In case of armada_38x_quirks error, all clocks should be cleaned-up, same
      as after mv_conf_mbus_windows failure.
      Signed-off-by: default avatarMarcin Wojtas <mw@semihalf.com>
      Cc: <stable@vger.kernel.org> # v4.2
      Reviewed-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      2162d9f4
    • Nadav Haklai's avatar
      mmc: sdhci-pxav3: disable clock inversion for HS MMC cards · fa796414
      Nadav Haklai authored
      According to 'FE-2946959' erratum the clock inversion option is
      needed to support slow frequencies when the card input hold time
      requirement is high. This setting is not required for high speed
      MMC and might cause timing violation.
      Signed-off-by: default avatarNadav Haklai <nadavh@marvell.com>
      Cc: <stable@vger.kernel.org> # v4.2
      Reviewed-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      fa796414