1. 22 Aug, 2016 21 commits
  2. 09 Aug, 2016 1 commit
  3. 08 Aug, 2016 18 commits
    • Lukas Wunner's avatar
      x86/quirks: Reintroduce scanning of secondary buses · dcb5a62d
      Lukas Wunner authored
      [ Upstream commit 850c3210 ]
      
      We used to scan secondary buses until the following commit that
      was applied in 2009:
      
        8659c406 ("x86: only scan the root bus in early PCI quirks")
      
      which commit constrained early quirks to the root bus only. Its
      motivation was to prevent application of the nvidia_bugs quirk
      on secondary buses.
      
      We're about to add a quirk to reset the Broadcom 4331 wireless card on
      2011/2012 Macs, which is located on a secondary bus behind a PCIe root
      port. To facilitate that, reintroduce scanning of secondary buses.
      
      The commit message of 8659c406 notes that scanning only the root bus
      "saves quite some unnecessary scanning work". The algorithm used prior
      to 8659c406 was particularly time consuming because it scanned
      buses 0 to 31 brute force. To avoid lengthening boot time, employ a
      recursive strategy which only scans buses that are actually reachable
      from the root bus.
      
      Yinghai Lu pointed out that the secondary bus number read from a
      bridge's config space may be invalid, in particular a value of 0 would
      cause an infinite loop. The PCI core goes beyond that and recurses to a
      child bus only if its bus number is greater than the parent bus number
      (see pci_scan_bridge()). Since the root bus is numbered 0, this implies
      that secondary buses may not be 0. Do the same on early scanning.
      
      If this algorithm is found to significantly impact boot time or cause
      infinite loops on broken hardware, it would be possible to limit its
      recursion depth: The Broadcom 4331 quirk applies at depth 1, all others
      at depth 0, so the bus need not be scanned deeper than that for now. An
      alternative approach would be to revert to scanning only the root bus,
      and apply the Broadcom 4331 quirk to the root ports 8086:1c12, 8086:1e12
      and 8086:1e16. Apple always positioned the card behind either of these
      three ports. The quirk would then check presence of the card in slot 0
      below the root port and do its deed.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-pci@vger.kernel.org
      Link: http://lkml.kernel.org/r/f0daa70dac1a9b2483abdb31887173eb6ab77bdf.1465690253.git.lukas@wunner.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      dcb5a62d
    • Lukas Wunner's avatar
      x86/quirks: Apply nvidia_bugs quirk only on root bus · 927dc15e
      Lukas Wunner authored
      [ Upstream commit 447d29d1 ]
      
      Since the following commit:
      
        8659c406 ("x86: only scan the root bus in early PCI quirks")
      
      ... early quirks are only applied to devices on the root bus.
      
      The motivation was to prevent application of the nvidia_bugs quirk on
      secondary buses.
      
      We're about to reintroduce scanning of secondary buses for a quirk to
      reset the Broadcom 4331 wireless card on 2011/2012 Macs. To prevent
      regressions, open code the requirement to apply nvidia_bugs only on the
      root bus.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Link: http://lkml.kernel.org/r/4d5477c1d76b2f0387a780f2142bbcdd9fee869b.1465690253.git.lukas@wunner.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      927dc15e
    • Jiri Slaby's avatar
      pps: do not crash when failed to register · 9c5125ac
      Jiri Slaby authored
      [ Upstream commit 368301f2 ]
      
      With this command sequence:
      
        modprobe plip
        modprobe pps_parport
        rmmod pps_parport
      
      the partport_pps modules causes this crash:
      
        BUG: unable to handle kernel NULL pointer dereference at (null)
        IP: parport_detach+0x1d/0x60 [pps_parport]
        Oops: 0000 [#1] SMP
        ...
        Call Trace:
          parport_unregister_driver+0x65/0xc0 [parport]
          SyS_delete_module+0x187/0x210
      
      The sequence that builds up to this is:
      
       1) plip is loaded and takes the parport device for exclusive use:
      
          plip0: Parallel port at 0x378, using IRQ 7.
      
       2) pps_parport then fails to grab the device:
      
          pps_parport: parallel port PPS client
          parport0: cannot grant exclusive access for device pps_parport
          pps_parport: couldn't register with parport0
      
       3) rmmod of pps_parport is then killed because it tries to access
          pardev->name, but pardev (taken from port->cad) is NULL.
      
      So add a check for NULL in the test there too.
      
      Link: http://lkml.kernel.org/r/20160714115245.12651-1-jslaby@suse.czSigned-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Acked-by: default avatarRodolfo Giometti <giometti@enneenne.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      9c5125ac
    • Andrey Ryabinin's avatar
      radix-tree: fix radix_tree_iter_retry() for tagged iterators. · b863398c
      Andrey Ryabinin authored
      [ Upstream commit 3cb9185c ]
      
      radix_tree_iter_retry() resets slot to NULL, but it doesn't reset tags.
      Then NULL slot and non-zero iter.tags passed to radix_tree_next_slot()
      leading to crash:
      
        RIP: radix_tree_next_slot include/linux/radix-tree.h:473
          find_get_pages_tag+0x334/0x930 mm/filemap.c:1452
        ....
        Call Trace:
          pagevec_lookup_tag+0x3a/0x80 mm/swap.c:960
          mpage_prepare_extent_to_map+0x321/0xa90 fs/ext4/inode.c:2516
          ext4_writepages+0x10be/0x2b20 fs/ext4/inode.c:2736
          do_writepages+0x97/0x100 mm/page-writeback.c:2364
          __filemap_fdatawrite_range+0x248/0x2e0 mm/filemap.c:300
          filemap_write_and_wait_range+0x121/0x1b0 mm/filemap.c:490
          ext4_sync_file+0x34d/0xdb0 fs/ext4/fsync.c:115
          vfs_fsync_range+0x10a/0x250 fs/sync.c:195
          vfs_fsync fs/sync.c:209
          do_fsync+0x42/0x70 fs/sync.c:219
          SYSC_fdatasync fs/sync.c:232
          SyS_fdatasync+0x19/0x20 fs/sync.c:230
          entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207
      
      We must reset iterator's tags to bail out from radix_tree_next_slot()
      and go to the slow-path in radix_tree_next_chunk().
      
      Fixes: 46437f9a ("radix-tree: fix race in gang lookup")
      Link: http://lkml.kernel.org/r/1468495196-10604-1-git-send-email-aryabinin@virtuozzo.comSigned-off-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Acked-by: default avatarKonstantin Khlebnikov <koct9i@gmail.com>
      Cc: Matthew Wilcox <willy@linux.intel.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      b863398c
    • Ilya Dryomov's avatar
      libceph: apply new_state before new_up_client on incrementals · 8777c9f6
      Ilya Dryomov authored
      [ Upstream commit 930c5328 ]
      
      Currently, osd_weight and osd_state fields are updated in the encoding
      order.  This is wrong, because an incremental map may look like e.g.
      
          new_up_client: { osd=6, addr=... } # set osd_state and addr
          new_state: { osd=6, xorstate=EXISTS } # clear osd_state
      
      Suppose osd6's current osd_state is EXISTS (i.e. osd6 is down).  After
      applying new_up_client, osd_state is changed to EXISTS | UP.  Carrying
      on with the new_state update, we flip EXISTS and leave osd6 in a weird
      "!EXISTS but UP" state.  A non-existent OSD is considered down by the
      mapping code
      
      2087    for (i = 0; i < pg->pg_temp.len; i++) {
      2088            if (ceph_osd_is_down(osdmap, pg->pg_temp.osds[i])) {
      2089                    if (ceph_can_shift_osds(pi))
      2090                            continue;
      2091
      2092                    temp->osds[temp->size++] = CRUSH_ITEM_NONE;
      
      and so requests get directed to the second OSD in the set instead of
      the first, resulting in OSD-side errors like:
      
      [WRN] : client.4239 192.168.122.21:0/2444980242 misdirected client.4239.1:2827 pg 2.5df899f2 to osd.4 not [1,4,6] in e680/680
      
      and hung rbds on the client:
      
      [  493.566367] rbd: rbd0: write 400000 at 11cc00000 (0)
      [  493.566805] rbd: rbd0:   result -6 xferred 400000
      [  493.567011] blk_update_request: I/O error, dev rbd0, sector 9330688
      
      The fix is to decouple application from the decoding and:
      - apply new_weight first
      - apply new_state before new_up_client
      - twiddle osd_state flags if marking in
      - clear out some of the state if osd is destroyed
      
      Fixes: http://tracker.ceph.com/issues/14901
      
      Cc: stable@vger.kernel.org # 3.15+: 6dd74e44: libceph: set 'exists' flag for newly up osd
      Cc: stable@vger.kernel.org # 3.15+
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarJosh Durgin <jdurgin@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      8777c9f6
    • Yan, Zheng's avatar
      libceph: set 'exists' flag for newly up osd · a7176826
      Yan, Zheng authored
      [ Upstream commit 6dd74e44 ]
      Signed-off-by: default avatarYan, Zheng <zyan@redhat.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      a7176826
    • Maxim Patlasov's avatar
      ovl: verify upper dentry in ovl_remove_and_whiteout() · 5eaee47b
      Maxim Patlasov authored
      [ Upstream commit cfc9fde0 ]
      
      The upper dentry may become stale before we call ovl_lock_rename_workdir.
      For example, someone could (mistakenly or maliciously) manually unlink(2)
      it directly from upperdir.
      
      To ensure it is not stale, let's lookup it after ovl_lock_rename_workdir
      and and check if it matches the upper dentry.
      
      Essentially, it is the same problem and similar solution as in
      commit 11f37104 ("ovl: verify upper dentry before unlink and rename").
      Signed-off-by: default avatarMaxim Patlasov <mpatlasov@virtuozzo.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      5eaee47b
    • Dmitry Torokhov's avatar
      tty/vt/keyboard: fix OOB access in do_compute_shiftstate() · a9d39310
      Dmitry Torokhov authored
      [ Upstream commit 510cccb5 ]
      
      The size of individual keymap in drivers/tty/vt/keyboard.c is NR_KEYS,
      which is currently 256, whereas number of keys/buttons in input device (and
      therefor in key_down) is much larger - KEY_CNT - 768, and that can cause
      out-of-bound access when we do
      
      	sym = U(key_maps[0][k]);
      
      with large 'k'.
      
      To fix it we should not attempt iterating beyond smaller of NR_KEYS and
      KEY_CNT.
      
      Also while at it let's switch to for_each_set_bit() instead of open-coding
      it.
      Reported-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Reviewed-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      a9d39310
    • Taras Kondratiuk's avatar
      mmc: block: fix packed command header endianness · e18fa5ad
      Taras Kondratiuk authored
      [ Upstream commit f68381a7 ]
      
      The code that fills packed command header assumes that CPU runs in
      little-endian mode. Hence the header is malformed in big-endian mode
      and causes MMC data transfer errors:
      
      [  563.200828] mmcblk0: error -110 transferring data, sector 2048, nr 8, cmd response 0x900, card status 0xc40
      [  563.219647] mmcblk0: packed cmd failed, nr 2, sectors 16, failure index: -1
      
      Convert header data to LE.
      Signed-off-by: default avatarTaras Kondratiuk <takondra@cisco.com>
      Fixes: ce39f9d1 ("mmc: support packed write command for eMMC4.5 devices")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      e18fa5ad
    • James Patrick-Evans's avatar
      media: fix airspy usb probe error path · d380c88d
      James Patrick-Evans authored
      [ Upstream commit aa93d1fe ]
      
      Fix a memory leak on probe error of the airspy usb device driver.
      
      The problem is triggered when more than 64 usb devices register with
      v4l2 of type VFL_TYPE_SDR or VFL_TYPE_SUBDEV.
      
      The memory leak is caused by the probe function of the airspy driver
      mishandeling errors and not freeing the corresponding control structures
      when an error occours registering the device to v4l2 core.
      
      A badusb device can emulate 64 of these devices, and then through
      continual emulated connect/disconnect of the 65th device, cause the
      kernel to run out of RAM and crash the kernel, thus causing a local DOS
      vulnerability.
      
      Fixes CVE-2016-5400
      Signed-off-by: default avatarJames Patrick-Evans <james@jmp-e.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Cc: stable@vger.kernel.org # 3.17+
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      d380c88d
    • Awais Belal's avatar
      ALSA: hda: add AMD Stoney PCI ID with proper driver caps · 5f51fe4b
      Awais Belal authored
      [ Upstream commit d716fb03 ]
      
      This allows the device to correctly show up as ATI HDMI
      rather than a generic one and allows the driver to use
      the available caps.
      Signed-off-by: default avatarAwais Belal <awais_belal@mentor.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      5f51fe4b
    • Maruthi Srinivas Bayyavarapu's avatar
      ALSA: hda: add new AMD PCI IDs with proper driver caps · 1fcba7f0
      Maruthi Srinivas Bayyavarapu authored
      [ Upstream commit 5022813d ]
      
      Fixes audio problems on newer asics
      Signed-off-by: default avatarMaruthi Bayyavarapu <maruthi.bayyavarapu@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      1fcba7f0
    • Sasha Levin's avatar
      ALSA: hda - fix use-after-free after module unload · 1a012d58
      Sasha Levin authored
      [ Upstream commit ab58d8cc ]
      
      register_vga_switcheroo() sets the PM ops from the hda structure which
      is freed later in azx_free. Make sure that these ops are cleared.
      
      Caught by KASAN, initially noticed due to a general protection fault.
      
      Fixes: 246efa4a ("snd/hda: add runtime suspend/resume on optimus support (v4)")
      Signed-off-by: default avatarPeter Wu <peter@lekensteyn.nl>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      1a012d58
    • Alexey Dobriyan's avatar
      posix_cpu_timer: Exit early when process has been reaped · 943e282c
      Alexey Dobriyan authored
      [ Upstream commit 2c13ce8f ]
      
      Variable "now" seems to be genuinely used unintialized
      if branch
      
      	if (CPUCLOCK_PERTHREAD(timer->it_clock)) {
      
      is not taken and branch
      
      	if (unlikely(sighand == NULL)) {
      
      is taken. In this case the process has been reaped and the timer is marked as
      disarmed anyway. So none of the postprocessing of the sample is
      required. Return right away.
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20160707223911.GA26483@p183.telecom.bySigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      943e282c
    • Lukas Wunner's avatar
      x86/quirks: Add early quirk to reset Apple AirPort card · 26c5fd38
      Lukas Wunner authored
      [ Upstream commit abb2bafd ]
      
      The EFI firmware on Macs contains a full-fledged network stack for
      downloading OS X images from osrecovery.apple.com. Unfortunately
      on Macs introduced 2011 and 2012, EFI brings up the Broadcom 4331
      wireless card on every boot and leaves it enabled even after
      ExitBootServices has been called. The card continues to assert its IRQ
      line, causing spurious interrupts if the IRQ is shared. It also corrupts
      memory by DMAing received packets, allowing for remote code execution
      over the air. This only stops when a driver is loaded for the wireless
      card, which may be never if the driver is not installed or blacklisted.
      
      The issue seems to be constrained to the Broadcom 4331. Chris Milsted
      has verified that the newer Broadcom 4360 built into the MacBookPro11,3
      (2013/2014) does not exhibit this behaviour. The chances that Apple will
      ever supply a firmware fix for the older machines appear to be zero.
      
      The solution is to reset the card on boot by writing to a reset bit in
      its mmio space. This must be done as an early quirk and not as a plain
      vanilla PCI quirk to successfully combat memory corruption by DMAed
      packets: Matthew Garrett found out in 2012 that the packets are written
      to EfiBootServicesData memory (http://mjg59.dreamwidth.org/11235.html).
      This type of memory is made available to the page allocator by
      efi_free_boot_services(). Plain vanilla PCI quirks run much later, in
      subsys initcall level. In-between a time window would be open for memory
      corruption. Random crashes occurring in this time window and attributed
      to DMAed packets have indeed been observed in the wild by Chris
      Bainbridge.
      
      When Matthew Garrett analyzed the memory corruption issue in 2012, he
      sought to fix it with a grub quirk which transitions the card to D3hot:
      http://git.savannah.gnu.org/cgit/grub.git/commit/?id=9d34bb85da56
      
      This approach does not help users with other bootloaders and while it
      may prevent DMAed packets, it does not cure the spurious interrupts
      emanating from the card. Unfortunately the card's mmio space is
      inaccessible in D3hot, so to reset it, we have to undo the effect of
      Matthew's grub patch and transition the card back to D0.
      
      Note that the quirk takes a few shortcuts to reduce the amount of code:
      The size of BAR 0 and the location of the PM capability is identical
      on all affected machines and therefore hardcoded. Only the address of
      BAR 0 differs between models. Also, it is assumed that the BCMA core
      currently mapped is the 802.11 core. The EFI driver seems to always take
      care of this.
      
      Michael Büsch, Bjorn Helgaas and Matt Fleming contributed feedback
      towards finding the best solution to this problem.
      
      The following should be a comprehensive list of affected models:
          iMac13,1        2012  21.5"       [Root Port 00:1c.3 = 8086:1e16]
          iMac13,2        2012  27"         [Root Port 00:1c.3 = 8086:1e16]
          Macmini5,1      2011  i5 2.3 GHz  [Root Port 00:1c.1 = 8086:1c12]
          Macmini5,2      2011  i5 2.5 GHz  [Root Port 00:1c.1 = 8086:1c12]
          Macmini5,3      2011  i7 2.0 GHz  [Root Port 00:1c.1 = 8086:1c12]
          Macmini6,1      2012  i5 2.5 GHz  [Root Port 00:1c.1 = 8086:1e12]
          Macmini6,2      2012  i7 2.3 GHz  [Root Port 00:1c.1 = 8086:1e12]
          MacBookPro8,1   2011  13"         [Root Port 00:1c.1 = 8086:1c12]
          MacBookPro8,2   2011  15"         [Root Port 00:1c.1 = 8086:1c12]
          MacBookPro8,3   2011  17"         [Root Port 00:1c.1 = 8086:1c12]
          MacBookPro9,1   2012  15"         [Root Port 00:1c.1 = 8086:1e12]
          MacBookPro9,2   2012  13"         [Root Port 00:1c.1 = 8086:1e12]
          MacBookPro10,1  2012  15"         [Root Port 00:1c.1 = 8086:1e12]
          MacBookPro10,2  2012  13"         [Root Port 00:1c.1 = 8086:1e12]
      
      For posterity, spurious interrupts caused by the Broadcom 4331 wireless
      card resulted in splats like this (stacktrace omitted):
      
          irq 17: nobody cared (try booting with the "irqpoll" option)
          handlers:
          [<ffffffff81374370>] pcie_isr
          [<ffffffffc0704550>] sdhci_irq [sdhci] threaded [<ffffffffc07013c0>] sdhci_thread_irq [sdhci]
          [<ffffffffc0a0b960>] azx_interrupt [snd_hda_codec]
          Disabling IRQ #17
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79301
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111781
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=728916
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=895951#c16
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1009819
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1098621
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1149632#c5
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1279130
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1332732
      Tested-by: Konstantin Simanov <k.simanov@stlk.ru>        # [MacBookPro8,1]
      Tested-by: Lukas Wunner <lukas@wunner.de>                # [MacBookPro9,1]
      Tested-by: Bryan Paradis <bryan.paradis@gmail.com>       # [MacBookPro9,2]
      Tested-by: Andrew Worsley <amworsley@gmail.com>          # [MacBookPro10,1]
      Tested-by: Chris Bainbridge <chris.bainbridge@gmail.com> # [MacBookPro10,2]
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Acked-by: default avatarRafał Miłecki <zajec5@gmail.com>
      Acked-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Chris Milsted <cmilsted@redhat.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Michael Buesch <m@bues.ch>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: b43-dev@lists.infradead.org
      Cc: linux-pci@vger.kernel.org
      Cc: linux-wireless@vger.kernel.org
      Cc: stable@vger.kernel.org
      Cc: stable@vger.kernel.org # 123456789abc: x86/quirks: Apply nvidia_bugs quirk only on root bus
      Cc: stable@vger.kernel.org # 123456789abc: x86/quirks: Reintroduce scanning of secondary buses
      Link: http://lkml.kernel.org/r/48d0972ac82a53d460e5fce77a07b2560db95203.1465690253.git.lukas@wunner.de
      [ Did minor readability edits. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      26c5fd38
    • Dmitri Epshtein's avatar
      net: mvneta: set real interrupt per packet for tx_done · b001c42a
      Dmitri Epshtein authored
      [ Upstream commit 06708f81 ]
      
      Commit aebea2ba ("net: mvneta: fix Tx interrupt delay") intended to
      set coalescing threshold to a value guaranteeing interrupt generation
      per each sent packet, so that buffers can be released with no delay.
      
      In fact setting threshold to '1' was wrong, because it causes interrupt
      every two packets. According to the documentation a reason behind it is
      following - interrupt occurs once sent buffers counter reaches a value,
      which is higher than one specified in MVNETA_TXQ_SIZE_REG(q). This
      behavior was confirmed during tests. Also when testing the SoC working
      as a NAS device, better performance was observed with int-per-packet,
      as it strongly depends on the fact that all transmitted packets are
      released immediately.
      
      This commit enables NETA controller work in interrupt per sent packet mode
      by setting coalescing threshold to 0.
      Signed-off-by: default avatarDmitri Epshtein <dima@marvell.com>
      Signed-off-by: default avatarMarcin Wojtas <mw@semihalf.com>
      Cc: <stable@vger.kernel.org> # v3.10+
      Fixes aebea2ba ("net: mvneta: fix Tx interrupt delay")
      Acked-by: default avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      b001c42a
    • Takashi Iwai's avatar
      ALSA: ctl: Stop notification after disconnection · 77dee6b7
      Takashi Iwai authored
      [ Upstream commit f388cdcd ]
      
      snd_ctl_remove() has a notification for the removal event.  It's
      superfluous when done during the device got disconnected.  Although
      the notification itself is mostly harmless, it may potentially be
      harmful, and should be suppressed.  Actually some components PCM may
      free ctl elements during the disconnect or free callbacks, thus it's
      no theoretical issue.
      
      This patch adds the check of card->shutdown flag for avoiding
      unnecessary notifications after (or during) the disconnect.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      77dee6b7
    • Hui Wang's avatar
      ALSA: hda/realtek - add new pin definition in alc225 pin quirk table · ee5dc420
      Hui Wang authored
      [ Upstream commit 8a132099 ]
      
      We have some Dell laptops which can't detect headset mic, the machines
      use the codec ALC225, they have some new pin configuration values,
      after adding them in the alc225 pin quirk table, they work well.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      ee5dc420