commit 9764536dc592144beee43c987fef45d2e91ca55c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Mar 24 10:57:35 2018 +0100

    Linux 3.18.102

commit eb5394496c07b4ed8a63f9217c89acf349ffe90c
Author: Leon Romanovsky <leonro@mellanox.com>
Date:   Tue Mar 13 11:43:23 2018 +0200

    RDMA/ucma: Fix access to non-initialized CM_ID object
    
    commit 7688f2c3bbf55e52388e37ac5d63ca471a7712e1 upstream.
    
    The attempt to join multicast group without ensuring that CMA device
    exists will lead to the following crash reported by syzkaller.
    
    [   64.076794] BUG: KASAN: null-ptr-deref in rdma_join_multicast+0x26e/0x12c0
    [   64.076797] Read of size 8 at addr 00000000000000b0 by task join/691
    [   64.076797]
    [   64.076800] CPU: 1 PID: 691 Comm: join Not tainted 4.16.0-rc1-00219-gb97853b65b93 #23
    [   64.076802] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-proj4
    [   64.076803] Call Trace:
    [   64.076809]  dump_stack+0x5c/0x77
    [   64.076817]  kasan_report+0x163/0x380
    [   64.085859]  ? rdma_join_multicast+0x26e/0x12c0
    [   64.086634]  rdma_join_multicast+0x26e/0x12c0
    [   64.087370]  ? rdma_disconnect+0xf0/0xf0
    [   64.088579]  ? __radix_tree_replace+0xc3/0x110
    [   64.089132]  ? node_tag_clear+0x81/0xb0
    [   64.089606]  ? idr_alloc_u32+0x12e/0x1a0
    [   64.090517]  ? __fprop_inc_percpu_max+0x150/0x150
    [   64.091768]  ? tracing_record_taskinfo+0x10/0xc0
    [   64.092340]  ? idr_alloc+0x76/0xc0
    [   64.092951]  ? idr_alloc_u32+0x1a0/0x1a0
    [   64.093632]  ? ucma_process_join+0x23d/0x460
    [   64.094510]  ucma_process_join+0x23d/0x460
    [   64.095199]  ? ucma_migrate_id+0x440/0x440
    [   64.095696]  ? futex_wake+0x10b/0x2a0
    [   64.096159]  ucma_join_multicast+0x88/0xe0
    [   64.096660]  ? ucma_process_join+0x460/0x460
    [   64.097540]  ? _copy_from_user+0x5e/0x90
    [   64.098017]  ucma_write+0x174/0x1f0
    [   64.098640]  ? ucma_resolve_route+0xf0/0xf0
    [   64.099343]  ? rb_erase_cached+0x6c7/0x7f0
    [   64.099839]  __vfs_write+0xc4/0x350
    [   64.100622]  ? perf_syscall_enter+0xe4/0x5f0
    [   64.101335]  ? kernel_read+0xa0/0xa0
    [   64.103525]  ? perf_sched_cb_inc+0xc0/0xc0
    [   64.105510]  ? syscall_exit_register+0x2a0/0x2a0
    [   64.107359]  ? __switch_to+0x351/0x640
    [   64.109285]  ? fsnotify+0x899/0x8f0
    [   64.111610]  ? fsnotify_unmount_inodes+0x170/0x170
    [   64.113876]  ? __fsnotify_update_child_dentry_flags+0x30/0x30
    [   64.115813]  ? ring_buffer_record_is_on+0xd/0x20
    [   64.117824]  ? __fget+0xa8/0xf0
    [   64.119869]  vfs_write+0xf7/0x280
    [   64.122001]  SyS_write+0xa1/0x120
    [   64.124213]  ? SyS_read+0x120/0x120
    [   64.126644]  ? SyS_read+0x120/0x120
    [   64.128563]  do_syscall_64+0xeb/0x250
    [   64.130732]  entry_SYSCALL_64_after_hwframe+0x21/0x86
    [   64.132984] RIP: 0033:0x7f5c994ade99
    [   64.135699] RSP: 002b:00007f5c99b97d98 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    [   64.138740] RAX: ffffffffffffffda RBX: 00000000200001e4 RCX: 00007f5c994ade99
    [   64.141056] RDX: 00000000000000a0 RSI: 00000000200001c0 RDI: 0000000000000015
    [   64.143536] RBP: 00007f5c99b97ec0 R08: 0000000000000000 R09: 0000000000000000
    [   64.146017] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f5c99b97fc0
    [   64.148608] R13: 0000000000000000 R14: 00007fff660e1c40 R15: 00007f5c99b989c0
    [   64.151060]
    [   64.153703] Disabling lock debugging due to kernel taint
    [   64.156032] BUG: unable to handle kernel NULL pointer dereference at 00000000000000b0
    [   64.159066] IP: rdma_join_multicast+0x26e/0x12c0
    [   64.161451] PGD 80000001d0298067 P4D 80000001d0298067 PUD 1dea39067 PMD 0
    [   64.164442] Oops: 0000 [#1] SMP KASAN PTI
    [   64.166817] CPU: 1 PID: 691 Comm: join Tainted: G    B 4.16.0-rc1-00219-gb97853b65b93 #23
    [   64.170004] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-proj4
    [   64.174985] RIP: 0010:rdma_join_multicast+0x26e/0x12c0
    [   64.177246] RSP: 0018:ffff8801c8207860 EFLAGS: 00010282
    [   64.179901] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff94789522
    [   64.183344] RDX: 1ffffffff2d50fa5 RSI: 0000000000000297 RDI: 0000000000000297
    [   64.186237] RBP: ffff8801c8207a50 R08: 0000000000000000 R09: ffffed0039040ea7
    [   64.189328] R10: 0000000000000001 R11: ffffed0039040ea6 R12: 0000000000000000
    [   64.192634] R13: 0000000000000000 R14: ffff8801e2022800 R15: ffff8801d4ac2400
    [   64.196105] FS:  00007f5c99b98700(0000) GS:ffff8801e5d00000(0000) knlGS:0000000000000000
    [   64.199211] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   64.202046] CR2: 00000000000000b0 CR3: 00000001d1c48004 CR4: 00000000003606a0
    [   64.205032] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [   64.208221] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [   64.211554] Call Trace:
    [   64.213464]  ? rdma_disconnect+0xf0/0xf0
    [   64.216124]  ? __radix_tree_replace+0xc3/0x110
    [   64.219337]  ? node_tag_clear+0x81/0xb0
    [   64.222140]  ? idr_alloc_u32+0x12e/0x1a0
    [   64.224422]  ? __fprop_inc_percpu_max+0x150/0x150
    [   64.226588]  ? tracing_record_taskinfo+0x10/0xc0
    [   64.229763]  ? idr_alloc+0x76/0xc0
    [   64.232186]  ? idr_alloc_u32+0x1a0/0x1a0
    [   64.234505]  ? ucma_process_join+0x23d/0x460
    [   64.237024]  ucma_process_join+0x23d/0x460
    [   64.240076]  ? ucma_migrate_id+0x440/0x440
    [   64.243284]  ? futex_wake+0x10b/0x2a0
    [   64.245302]  ucma_join_multicast+0x88/0xe0
    [   64.247783]  ? ucma_process_join+0x460/0x460
    [   64.250841]  ? _copy_from_user+0x5e/0x90
    [   64.253878]  ucma_write+0x174/0x1f0
    [   64.257008]  ? ucma_resolve_route+0xf0/0xf0
    [   64.259877]  ? rb_erase_cached+0x6c7/0x7f0
    [   64.262746]  __vfs_write+0xc4/0x350
    [   64.265537]  ? perf_syscall_enter+0xe4/0x5f0
    [   64.267792]  ? kernel_read+0xa0/0xa0
    [   64.270358]  ? perf_sched_cb_inc+0xc0/0xc0
    [   64.272575]  ? syscall_exit_register+0x2a0/0x2a0
    [   64.275367]  ? __switch_to+0x351/0x640
    [   64.277700]  ? fsnotify+0x899/0x8f0
    [   64.280530]  ? fsnotify_unmount_inodes+0x170/0x170
    [   64.283156]  ? __fsnotify_update_child_dentry_flags+0x30/0x30
    [   64.286182]  ? ring_buffer_record_is_on+0xd/0x20
    [   64.288749]  ? __fget+0xa8/0xf0
    [   64.291136]  vfs_write+0xf7/0x280
    [   64.292972]  SyS_write+0xa1/0x120
    [   64.294965]  ? SyS_read+0x120/0x120
    [   64.297474]  ? SyS_read+0x120/0x120
    [   64.299751]  do_syscall_64+0xeb/0x250
    [   64.301826]  entry_SYSCALL_64_after_hwframe+0x21/0x86
    [   64.304352] RIP: 0033:0x7f5c994ade99
    [   64.306711] RSP: 002b:00007f5c99b97d98 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    [   64.309577] RAX: ffffffffffffffda RBX: 00000000200001e4 RCX: 00007f5c994ade99
    [   64.312334] RDX: 00000000000000a0 RSI: 00000000200001c0 RDI: 0000000000000015
    [   64.315783] RBP: 00007f5c99b97ec0 R08: 0000000000000000 R09: 0000000000000000
    [   64.318365] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f5c99b97fc0
    [   64.320980] R13: 0000000000000000 R14: 00007fff660e1c40 R15: 00007f5c99b989c0
    [   64.323515] Code: e8 e8 79 08 ff 4c 89 ff 45 0f b6 a7 b8 01 00 00 e8 68 7c 08 ff 49 8b 1f 4d 89 e5 49 c1 e4 04 48 8
    [   64.330753] RIP: rdma_join_multicast+0x26e/0x12c0 RSP: ffff8801c8207860
    [   64.332979] CR2: 00000000000000b0
    [   64.335550] ---[ end trace 0c00c17a408849c1 ]---
    
    Reported-by: <syzbot+e6aba77967bd72cbc9d6@syzkaller.appspotmail.com>
    Fixes: c8f6a362bf3e ("RDMA/cma: Add multicast communication support")
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Reviewed-by: Sean Hefty <sean.hefty@intel.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 236ab41ffc3a4f1d30465cfc3a676ada550715bf
Author: Sergej Sawazki <sergej@taudac.com>
Date:   Tue Jul 25 23:21:02 2017 +0200

    clk: si5351: Rename internal plls to avoid name collisions
    
    
    [ Upstream commit cdba9a4fb0b53703959ac861e415816cb61aded4 ]
    
    This drivers probe fails due to a clock name collision if a clock named
    'plla' or 'pllb' is already registered when registering this drivers
    internal plls.
    
    Fix it by renaming internal plls to avoid name collisions.
    
    Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
    Cc: Rabeeh Khoury <rabeeh@solid-run.com>
    Signed-off-by: Sergej Sawazki <sergej@taudac.com>
    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a967fd2dce5eab4c743db600229f62c22625806
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Wed Mar 1 10:32:57 2017 -0800

    pinctrl: Really force states during suspend/resume
    
    
    [ Upstream commit 981ed1bfbc6c4660b2ddaa8392893e20a6255048 ]
    
    In case a platform only defaults a "default" set of pins, but not a
    "sleep" set of pins, and this particular platform suspends and resumes
    in a way that the pin states are not preserved by the hardware, when we
    resume, we would call pinctrl_single_resume() -> pinctrl_force_default()
    -> pinctrl_select_state() and the first thing we do is check that the
    pins state is the same as before, and do nothing.
    
    In order to fix this, decouple the actual state change from
    pinctrl_select_state() and move it pinctrl_commit_state(), while keeping
    the p->state == state check in pinctrl_select_state() not to change the
    caller assumptions. pinctrl_force_sleep() and pinctrl_force_default()
    are updated to bypass the state check by calling pinctrl_commit_state().
    
    [Linus Walleij]
    The forced pin control states are currently only used in some pin
    controller drivers that grab their own reference to their own pins.
    This is equal to the pin control hogs: pins taken by pin control
    devices since there are no corresponding device in the Linux device
    hierarchy, such as memory controller lines or unused GPIO lines,
    or GPIO lines that are used orthogonally from the GPIO subsystem
    but pincontrol-wise managed as hogs (non-strict mode, allowing
    simultaneous use by GPIO and pin control). For this case forcing
    the state from the drivers' suspend()/resume() callbacks makes
    sense and should semantically match the name of the function.
    
    Fixes: 6e5e959dde0d ("pinctrl: API changes to support multiple states per device")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8abf722326dee57e29ef94ae9828ca123efb1934
Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
Date:   Fri Sep 29 14:49:49 2017 +0300

    drm/omap: DMM: Check for DMM readiness after successful transaction commit
    
    
    [ Upstream commit b7ea6b286c4051e043f691781785e3c4672f014a ]
    
    Check the status of the DMM engine after it is reported that the
    transaction was completed as in rare cases the engine might not reached a
    working state.
    
    The wait_status() will print information in case the DMM is not reached the
    expected state and the dmm_txn_commit() will return with an error code to
    make sure that we are not continuing with a broken setup.
    
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b6d24e43fb39e4bbc3013c10e1d32bc796f32f8
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Fri Dec 1 11:06:39 2017 -0600

    vgacon: Set VGA struct resource types
    
    
    [ Upstream commit c82084117f79bcae085e40da526253736a247120 ]
    
    Set the resource type when we reserve VGA-related I/O port resources.
    
    The resource code doesn't actually look at the type, so it inserts
    resources without a type in the tree correctly even without this change.
    But if we ever print a resource without a type, it looks like this:
    
      vga+ [??? 0x000003c0-0x000003df flags 0x0]
    
    Setting the type means it will be printed correctly as:
    
      vga+ [io  0x000003c0-0x000003df]
    
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0353b3376f655b140175245db6643f06a78bd241
Author: Parav Pandit <parav@mellanox.com>
Date:   Tue Nov 14 14:51:55 2017 +0200

    RDMA/cma: Use correct size when writing netlink stats
    
    
    [ Upstream commit 7baaa49af3716fb31877c61f59b74d029ce15b75 ]
    
    The code was using the src size when formatting the dst. They are almost
    certainly the same value but it reads wrong.
    
    Fixes: ce117ffac2e9 ("RDMA/cma: Export AF_IB statistics")
    Signed-off-by: Parav Pandit <parav@mellanox.com>
    Reviewed-by: Daniel Jurgens <danielj@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6bfd5a3a3c2599657a78583eb728afc1d8519b58
Author: Erez Shitrit <erezsh@mellanox.com>
Date:   Tue Nov 14 14:51:53 2017 +0200

    IB/ipoib: Avoid memory leak if the SA returns a different DGID
    
    
    [ Upstream commit 439000892ee17a9c92f1e4297818790ef8bb4ced ]
    
    The ipoib path database is organized around DGIDs from the LLADDR, but the
    SA is free to return a different GID when asked for path. This causes a
    bug because the SA's modified DGID is copied into the database key, even
    though it is no longer the correct lookup key, causing a memory leak and
    other malfunctions.
    
    Ensure the database key does not change after the SA query completes.
    
    Demonstration of the bug is as  follows
    ipoib wants to send to GID fe80:0000:0000:0000:0002:c903:00ef:5ee2, it
    creates new record in the DB with that gid as a key, and issues a new
    request to the SM.
    Now, the SM from some reason returns path-record with other SGID (for
    example, 2001:0000:0000:0000:0002:c903:00ef:5ee2 that contains the local
    subnet prefix) now ipoib will overwrite the current entry with the new
    one, and if new request to the original GID arrives ipoib  will not find
    it in the DB (was overwritten) and will create new record that in its
    turn will also be overwritten by the response from the SM, and so on
    till the driver eats all the device memory.
    
    Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a86d90de6b80bb3bebe0b7011207c1c216633e32
Author: Daniel Drake <drake@endlessm.com>
Date:   Tue Dec 12 10:49:02 2017 +0000

    mmc: avoid removing non-removable hosts during suspend
    
    
    [ Upstream commit de8dcc3d2c0e08e5068ee1e26fc46415c15e3637 ]
    
    The Weibu F3C MiniPC has an onboard AP6255 module, presenting
    two SDIO functions on a single MMC host (Bluetooth/btsdio and
    WiFi/brcmfmac), and the mmc layer correctly detects this as
    non-removable.
    
    After suspend/resume, the wifi and bluetooth interfaces disappear
    and do not get probed again.
    
    The conditions here are:
    
     1. During suspend, we reach mmc_pm_notify()
    
     2. mmc_pm_notify() calls mmc_sdio_pre_suspend() to see if we can
        suspend the SDIO host. However, mmc_sdio_pre_suspend() returns
        -ENOSYS because btsdio_driver does not have a suspend method.
    
     3. mmc_pm_notify() proceeds to remove the card
    
     4. Upon resume, mmc_rescan() does nothing with this host, because of
        the rescan_entered check which aims to only scan a non-removable
        device a single time (i.e. during boot).
    
    Fix the loss of functionality by detecting that we are unable to
    suspend a non-removable host, so avoid the forced removal in that
    case. The comment above this function already indicates that this
    code was only intended for removable devices.
    
    Signed-off-by: Daniel Drake <drake@endlessm.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e3b1d03712386c5c32e0e6749c5a24b8625637e
Author: Ron Economos <w6rz@comcast.net>
Date:   Mon Dec 11 19:51:53 2017 -0500

    media: [RESEND] media: dvb-frontends: Add delay to Si2168 restart
    
    
    [ Upstream commit 380a6c86457573aa42d27ae11e025eb25941a0b7 ]
    
    On faster CPUs a delay is required after the resume command and the restart command. Without the delay, the restart command often returns -EREMOTEIO and the Si2168 does not restart.
    
    Note that this patch fixes the same issue as https://patchwork.linuxtv.org/patch/44304/, but I believe my udelay() fix addresses the actual problem.
    
    Signed-off-by: Ron Economos <w6rz@comcast.net>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4716cf97d194fe21bbad6a098a7b6fadc3cb12e2
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Thu Sep 21 19:23:56 2017 -0400

    media: bt8xx: Fix err 'bt878_probe()'
    
    
    [ Upstream commit 45392ff6881dbe56d41ef0b17c2e576065f8ffa1 ]
    
    This is odd to call 'pci_disable_device()' in an error path before a
    coresponding successful 'pci_enable_device()'.
    
    Return directly instead.
    
    Fixes: 77e0be12100a ("V4L/DVB (4176): Bug-fix: Fix memory overflow")
    
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1fa04de1af73874d7e0ef4ca7b91e513a2023f8f
Author: Prakash Kamliya <pkamliya@codeaurora.org>
Date:   Mon Dec 4 19:10:15 2017 +0530

    drm/msm: fix leak in failed get_pages
    
    
    [ Upstream commit 62e3a3e342af3c313ab38603811ecdb1fcc79edb ]
    
    get_pages doesn't keep a reference of the pages allocated
    when it fails later in the code path. This can lead to
    a memory leak. Keep reference of the allocated pages so
    that it can be freed when msm_gem_free_object gets called
    later during cleanup.
    
    Signed-off-by: Prakash Kamliya <pkamliya@codeaurora.org>
    Signed-off-by: Sharat Masetty <smasetty@codeaurora.org>
    Signed-off-by: Rob Clark <robdclark@gmail.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4eee23a7ce7fef8740a6f989830bc4d72144197
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon May 1 21:43:43 2017 +0300

    cifs: small underflow in cnvrtDosUnixTm()
    
    
    [ Upstream commit 564277eceeca01e02b1ef3e141cfb939184601b4 ]
    
    January is month 1.  There is no zero-th month.  If someone passes a
    zero month then it means we read from one space before the start of the
    total_days_of_prev_months[] array.
    
    We may as well also be strict about days as well.
    
    Fixes: 1bd5bbcb6531 ("[CIFS] Legacy time handling for Win9x and OS/2 part 1")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f9612c99c20a9a2537f50b4bd7289411c4a96a2
Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date:   Tue May 2 13:47:53 2017 +0200

    sm501fb: don't return zero on failure path in sm501fb_start()
    
    
    [ Upstream commit dc85e9a87420613b3129d5cc5ecd79c58351c546 ]
    
    If fbmem iomemory mapping failed, sm501fb_start() breaks off
    initialization, deallocates resources, but returns zero.
    As a result, double deallocation can happen in sm501fb_stop().
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 654c7e21f68fb92176784bd835e15bbb9c1ee1d2
Author: Maksim Salau <maksim.salau@gmail.com>
Date:   Tue May 2 13:47:53 2017 +0200

    video: fbdev: udlfb: Fix buffer on stack
    
    
    [ Upstream commit 45f580c42e5c125d55dbd8099750a1998de3d917 ]
    
    Allocate buffers on HEAP instead of STACK for local array
    that is to be sent using usb_control_msg().
    
    Signed-off-by: Maksim Salau <maksim.salau@gmail.com>
    Cc: Bernie Thompson <bernie@plugable.com>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7aadba03eb8807dd4769f8f0c851b0a631967419
Author: Sergei Trofimovich <slyfox@gentoo.org>
Date:   Mon May 1 11:51:55 2017 -0700

    ia64: fix module loading for gcc-5.4
    
    
    [ Upstream commit a25fb8508c1b80dce742dbeaa4d75a1e9f2c5617 ]
    
    Starting from gcc-5.4+ gcc generates MLX instructions in more cases to
    refer local symbols:
    
        https://gcc.gnu.org/PR60465
    
    That caused ia64 module loader to choke on such instructions:
    
        fuse: invalid slot number 1 for IMM64
    
    The Linux kernel used to handle only case where relocation pointed to
    slot=2 instruction in the bundle.  That limitation was fixed in linux by
    commit 9c184a073bfd ("[IA64] Fix 2.6 kernel for the new ia64 assembler")
    See
    
        http://sources.redhat.com/bugzilla/show_bug.cgi?id=1433
    
    This change lifts the slot=2 restriction from the kernel module loader.
    
    Tested on 'fuse' and 'btrfs' kernel modules.
    
    Cc: Markus Elfring <elfring@users.sourceforge.net>
    Cc: H J Lu <hjl.tools@gmail.com>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Bug: https://bugs.gentoo.org/601014
    Tested-by: Émeric MASCHINO <emeric.maschino@gmail.com>
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c846fc16527ac6a768aaf1e7bede685b03344050
Author: Shaohua Li <shli@fb.com>
Date:   Mon May 1 12:15:07 2017 -0700

    md/raid10: skip spare disk as 'first' disk
    
    
    [ Upstream commit b506335e5d2b4ec687dde392a3bdbf7601778f1d ]
    
    Commit 6f287ca(md/raid10: reset the 'first' at the end of loop) ignores
    a case in reshape, the first rdev could be a spare disk, which shouldn't
    be accounted as the first disk since it doesn't include the offset info.
    
    Fix: 6f287ca(md/raid10: reset the 'first' at the end of loop)
    Cc: Guoqing Jiang <gqjiang@suse.com>
    Cc: NeilBrown <neilb@suse.com>
    Signed-off-by: Shaohua Li <shli@fb.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4245507843aa51c25f9b5ff5b3f1b3014d0a8cc
Author: Michael Trimarchi <michael@amarulasolutions.com>
Date:   Tue Apr 25 15:18:05 2017 +0200

    power: supply: pda_power: move from timer to delayed_work
    
    
    [ Upstream commit 633e8799ddc09431be2744c4a1efdbda13af2b0b ]
    
    This changed is needed to avoid locking problem during
    boot as shown:
    
    <5>[    8.824096] Registering SWP/SWPB emulation handler
    <6>[    8.977294] clock: disabling unused clocks to save power
    <3>[    9.108154] BUG: sleeping function called from invalid context at kernel_albert/kernel/mutex.c:269
    <3>[    9.122894] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0
    <4>[    9.130249] 3 locks held by swapper/0/1:
    <4>[    9.134613]  #0:  (&__lockdep_no_validate__){......}, at: [<c0342430>] __driver_attach+0x58/0xa8
    <4>[    9.144500]  #1:  (&__lockdep_no_validate__){......}, at: [<c0342440>] __driver_attach+0x68/0xa8
    <4>[    9.154357]  #2:  (&polling_timer){......}, at: [<c0053770>] run_timer_softirq+0x108/0x3ec
    <4>[    9.163726] Backtrace:
    <4>[    9.166473] [<c001269c>] (dump_backtrace+0x0/0x114) from [<c067e5f0>] (dump_stack+0x20/0x24)
    <4>[    9.175811]  r6:00203230 r5:0000010d r4:d782e000 r3:60000113
    <4>[    9.182250] [<c067e5d0>] (dump_stack+0x0/0x24) from [<c007441c>] (__might_sleep+0x10c/0x128)
    <4>[    9.191650] [<c0074310>] (__might_sleep+0x0/0x128) from [<c0688f60>] (mutex_lock_nested+0x34/0x36c)
    <4>[    9.201660]  r5:c02d5350 r4:d79a0c64
    <4>[    9.205688] [<c0688f2c>] (mutex_lock_nested+0x0/0x36c) from [<c02d5350>] (regulator_set_current_limit+0x30/0x118)
    <4>[    9.217071] [<c02d5320>] (regulator_set_current_limit+0x0/0x118) from [<c0435ce0>] (update_charger+0x84/0xc4)
    <4>[    9.228027]  r7:d782fb20 r6:00000101 r5:c1767e94 r4:00000000
    <4>[    9.234436] [<c0435c5c>] (update_charger+0x0/0xc4) from [<c0435d40>] (psy_changed+0x20/0x48)
    <4>[    9.243804]  r5:d782e000 r4:c1767e94
    <4>[    9.247802] [<c0435d20>] (psy_changed+0x0/0x48) from [<c0435dec>] (polling_timer_func+0x84/0xb8)
    <4>[    9.257537]  r4:c1767e94 r3:00000002
    <4>[    9.261566] [<c0435d68>] (polling_timer_func+0x0/0xb8) from [<c00537e4>] (run_timer_softirq+0x17c/0x3ec)
    <4>[    9.272033]  r4:c1767eb0 r3:00000000
    <4>[    9.276062] [<c0053668>] (run_timer_softirq+0x0/0x3ec) from [<c004b000>] (__do_softirq+0xf0/0x298)
    <4>[    9.286010] [<c004af10>] (__do_softirq+0x0/0x298) from [<c004b650>] (irq_exit+0x98/0xa0)
    <4>[    9.295013] [<c004b5b8>] (irq_exit+0x0/0xa0) from [<c000edbc>] (handle_IRQ+0x60/0xc0)
    <4>[    9.303680]  r4:c1194e98 r3:c00bc778
    <4>[    9.307708] [<c000ed5c>] (handle_IRQ+0x0/0xc0) from [<c0008504>] (gic_handle_irq+0x34/0x68)
    <4>[    9.316955]  r8:000ac383 r7:d782fc3c r6:d782fc08 r5:c11936c4 r4:e0802100
    <4>[    9.324310] r3:c026ba48
    <4>[    9.327301] [<c00084d0>] (gic_handle_irq+0x0/0x68) from [<c068c2c0>] (__irq_svc+0x40/0x74)
    <4>[    9.336456] Exception stack(0xd782fc08 to 0xd782fc50)
    <4>[    9.342041] fc00:                   d6e30e6c ac383627 00000000 ac383417 ea19c000 ea200000
    <4>[    9.351104] fc20: beffffff 00000667 000ac383 d6e30670 d6e3066c d782fc94 d782fbe8 d782fc50
    <4>[    9.360168] fc40: c026ba48 c001d1f0 00000113 ffffffff
    
    Fixes: b2998049cfae ("[BATTERY] pda_power platform driver")
    Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
    Signed-off-by: Anthony Brandon <anthony@amarulasolutions.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 045901c13f15ca0471c85da5d5b2d78080c3126c
Author: Scott Wood <swood@redhat.com>
Date:   Fri Apr 28 19:17:41 2017 -0500

    bnx2x: Align RX buffers
    
    
    [ Upstream commit 9b70de6d0266888b3743f03802502e43131043c8 ]
    
    The bnx2x driver is not providing proper alignment on the receive buffers it
    passes to build_skb(), causing skb_shared_info to be misaligned.
    skb_shared_info contains an atomic, and while PPC normally supports
    unaligned accesses, it does not support unaligned atomics.
    
    Aligning the size of rx buffers will ensure that page_frag_alloc() returns
    aligned addresses.
    
    This can be reproduced on PPC by setting the network MTU to 1450 (or other
    non-multiple-of-4) and then generating sufficient inbound network traffic
    (one or two large "wget"s usually does it), producing the following oops:
    
    Unable to handle kernel paging request for unaligned access at address 0xc00000ffc43af656
    Faulting instruction address: 0xc00000000080ef8c
    Oops: Kernel access of bad area, sig: 7 [#1]
    SMP NR_CPUS=2048
    NUMA
    PowerNV
    Modules linked in: vmx_crypto powernv_rng rng_core powernv_op_panel leds_powernv led_class nfsd ip_tables x_tables autofs4 xfs lpfc bnx2x mdio libcrc32c crc_t10dif crct10dif_generic crct10dif_common
    CPU: 104 PID: 0 Comm: swapper/104 Not tainted 4.11.0-rc8-00088-g4c761da #2
    task: c00000ffd4892400 task.stack: c00000ffd4920000
    NIP: c00000000080ef8c LR: c00000000080eee8 CTR: c0000000001f8320
    REGS: c00000ffffc33710 TRAP: 0600   Not tainted  (4.11.0-rc8-00088-g4c761da)
    MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>
      CR: 24082042  XER: 00000000
    CFAR: c00000000080eea0 DAR: c00000ffc43af656 DSISR: 00000000 SOFTE: 1
    GPR00: c000000000907f64 c00000ffffc33990 c000000000dd3b00 c00000ffcaf22100
    GPR04: c00000ffcaf22e00 0000000000000000 0000000000000000 0000000000000000
    GPR08: 0000000000b80008 c00000ffc43af636 c00000ffc43af656 0000000000000000
    GPR12: c0000000001f6f00 c00000000fe1a000 000000000000049f 000000000000c51f
    GPR16: 00000000ffffef33 0000000000000000 0000000000008a43 0000000000000001
    GPR20: c00000ffc58a90c0 0000000000000000 000000000000dd86 0000000000000000
    GPR24: c000007fd0ed10c0 00000000ffffffff 0000000000000158 000000000000014a
    GPR28: c00000ffc43af010 c00000ffc9144000 c00000ffcaf22e00 c00000ffcaf22100
    NIP [c00000000080ef8c] __skb_clone+0xdc/0x140
    LR [c00000000080eee8] __skb_clone+0x38/0x140
    Call Trace:
    [c00000ffffc33990] [c00000000080fb74] skb_clone+0x74/0x110 (unreliable)
    [c00000ffffc339c0] [c000000000907f64] packet_rcv+0x144/0x510
    [c00000ffffc33a40] [c000000000827b64] __netif_receive_skb_core+0x5b4/0xd80
    [c00000ffffc33b00] [c00000000082b2bc] netif_receive_skb_internal+0x2c/0xc0
    [c00000ffffc33b40] [c00000000082c49c] napi_gro_receive+0x11c/0x260
    [c00000ffffc33b80] [d000000066483d68] bnx2x_poll+0xcf8/0x17b0 [bnx2x]
    [c00000ffffc33d00] [c00000000082babc] net_rx_action+0x31c/0x480
    [c00000ffffc33e10] [c0000000000d5a44] __do_softirq+0x164/0x3d0
    [c00000ffffc33f00] [c0000000000d60a8] irq_exit+0x108/0x120
    [c00000ffffc33f20] [c000000000015b98] __do_irq+0x98/0x200
    [c00000ffffc33f90] [c000000000027f14] call_do_irq+0x14/0x24
    [c00000ffd4923a90] [c000000000015d94] do_IRQ+0x94/0x110
    [c00000ffd4923ae0] [c000000000008d90] hardware_interrupt_common+0x150/0x160
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21d4b929df88029f83976bbf863df0b7231b7d3b
Author: Robert Lippert <roblip@gmail.com>
Date:   Thu Apr 20 16:49:47 2017 -0700

    ipmi/watchdog: fix wdog hang on panic waiting for ipmi response
    
    
    [ Upstream commit 2c1175c2e8e5487233cabde358a19577562ac83e ]
    
    Commit c49c097610fe ("ipmi: Don't call receive handler in the
    panic context") means that the panic_recv_free is not called during a
    panic and the atomic count does not drop to 0.
    
    Fix this by only expecting one decrement of the atomic variable
    which comes from panic_smi_free.
    
    Signed-off-by: Robert Lippert <rlippert@google.com>
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b69c4a124258f393b5fea8729b2ce12cbe2602a5
Author: Kishon Vijay Abraham I <kishon@ti.com>
Date:   Mon Mar 27 15:15:20 2017 +0530

    ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP
    
    
    [ Upstream commit 2c949ce38f4e81d7487f165fa3b8f77d74a2a6c4 ]
    
    The PCIe programming sequence in TRM suggests CLKSTCTRL of PCIe should be
    set to SW_WKUP. There are no issues when CLKSTCTRL is set to HW_AUTO in RC
    mode. However in EP mode, the host system is not able to access the
    MEMSPACE and setting the CLKSTCTRL to SW_WKUP fixes it.
    
    Acked-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9d6765b5747a0569fe7e09550fca0e54e09b477
Author: Keerthy <j-keerthy@ti.com>
Date:   Thu Nov 10 10:39:18 2016 +0530

    mfd: palmas: Reset the POWERHOLD mux during power off
    
    
    [ Upstream commit 85fdaf8eb9bbec1f0f8a52fd5d85659d60738816 ]
    
    POWERHOLD signal has higher priority  over the DEV_ON bit.
    So power off will not happen if the POWERHOLD is held high.
    Hence reset the MUX to GPIO_7 mode to release the POWERHOLD
    and the DEV_ON bit to take effect to power off the PMIC.
    
    PMIC Power off happens in dire situations like thermal shutdown
    so irrespective of the POWERHOLD setting go ahead and turn off
    the powerhold.  Currently poweroff is broken on boards that have
    powerhold enabled. This fixes poweroff on those boards.
    
    Signed-off-by: Keerthy <j-keerthy@ti.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 354ae15a58fb7fc325956c3930d9c4f879f07e70
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Wed Apr 26 10:58:51 2017 +0300

    mac80211: don't parse encrypted management frames in ieee80211_frame_acked
    
    
    [ Upstream commit cf147085fdda044622973a12e4e06f1c753ab677 ]
    
    ieee80211_frame_acked is called when a frame is acked by
    the peer. In case this is a management frame, we check
    if this an SMPS frame, in which case we can update our
    antenna configuration.
    
    When we parse the management frame we look at the category
    in case it is an action frame. That byte sits after the IV
    in case the frame was encrypted. This means that if the
    frame was encrypted, we basically look at the IV instead
    of looking at the category. It is then theorically
    possible that we think that an SMPS action frame was acked
    where really we had another frame that was encrypted.
    
    Since the only management frame whose ack needs to be
    tracked is the SMPS action frame, and that frame is not
    a robust management frame, it will never be encrypted.
    The easiest way to fix this problem is then to not look
    at frames that were encrypted.
    
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 00a4087f7a4a99ae483a1c67f183883e78ae310d
Author: Filipe Manana <fdmanana@suse.com>
Date:   Tue Apr 4 20:31:00 2017 +0100

    Btrfs: send, fix file hole not being preserved due to inline extent
    
    
    [ Upstream commit e1cbfd7bf6dabdac561c75d08357571f44040a45 ]
    
    Normally we don't have inline extents followed by regular extents, but
    there's currently at least one harmless case where this happens. For
    example, when the page size is 4Kb and compression is enabled:
    
      $ mkfs.btrfs -f /dev/sdb
      $ mount -o compress /dev/sdb /mnt
      $ xfs_io -f -c "pwrite -S 0xaa 0 4K" -c "fsync" /mnt/foobar
      $ xfs_io -c "pwrite -S 0xbb 8K 4K" -c "fsync" /mnt/foobar
    
    In this case we get a compressed inline extent, representing 4Kb of
    data, followed by a hole extent and then a regular data extent. The
    inline extent was not expanded/converted to a regular extent exactly
    because it represents 4Kb of data. This does not cause any apparent
    problem (such as the issue solved by commit e1699d2d7bf6
    ("btrfs: add missing memset while reading compressed inline extents"))
    except trigger an unexpected case in the incremental send code path
    that makes us issue an operation to write a hole when it's not needed,
    resulting in more writes at the receiver and wasting space at the
    receiver.
    
    So teach the incremental send code to deal with this particular case.
    
    The issue can be currently triggered by running fstests btrfs/137 with
    compression enabled (MOUNT_OPTIONS="-o compress" ./check btrfs/137).
    
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fcafccbd29c56cc0fef2edd602ddf4aa2d35c4c3
Author: Pan Bian <bianpan2016@163.com>
Date:   Mon Apr 24 08:40:28 2017 +0800

    rndis_wlan: add return value validation
    
    
    [ Upstream commit 9dc7efd3978aa67ae598129d2a3f240b390ce508 ]
    
    Function create_singlethread_workqueue() will return a NULL pointer if
    there is no enough memory, and its return value should be validated
    before using. However, in function rndis_wlan_bind(), its return value
    is not checked. This may cause NULL dereference bugs. This patch fixes
    it.
    
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 868a3686cae502ce219b1373e86d6eda1c599077
Author: Finn Thain <fthain@telegraphics.com.au>
Date:   Sun Apr 2 17:08:05 2017 +1000

    scsi: mac_esp: Replace bogus memory barrier with spinlock
    
    
    [ Upstream commit 4da2b1eb230ba4ad19b58984dc52e05b1073df5f ]
    
    Commit da244654c66e ("[SCSI] mac_esp: fix for quadras with two esp
    chips") added mac_scsi_esp_intr() to handle the IRQ lines from a pair of
    on-board ESP chips (a normal shared IRQ did not work).
    
    Proper mutual exclusion was missing from that patch. This patch fixes
    race conditions between comparison and assignment of esp_chips[]
    pointers.
    
    Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
    Reviewed-by: Michael Schmitz <schmitzmic@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2805557d1c815b37448df79cd6a1bdf6806661ec
Author: Pan Bian <bianpan2016@163.com>
Date:   Sun Apr 23 20:04:04 2017 +0800

    qlcnic: fix unchecked return value
    
    
    [ Upstream commit 91ec701a553cb3de470fd471c6fefe3ad1125455 ]
    
    Function pci_find_ext_capability() may return 0, which is an invalid
    address. In function qlcnic_sriov_virtid_fn(), its return value is used
    without validation. This may result in invalid memory access bugs. This
    patch fixes the bug.
    
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4525033938cb6d8ed70717506917cb5e547debb8
Author: Pan Bian <bianpan2016@163.com>
Date:   Sun Apr 23 17:38:35 2017 +0800

    wan: pc300too: abort path on failure
    
    
    [ Upstream commit 2a39e7aa8a98f777f0732ca7125b6c9668791760 ]
    
    In function pc300_pci_init_one(), on the ioremap error path, function
    pc300_pci_remove_one() is called to free the allocated memory. However,
    the path is not terminated, and the freed memory will be used later,
    resulting in use-after-free bugs. This path fixes the bug.
    
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc0808f0c2a43212f73d438e083a34251984540c
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Apr 10 16:54:17 2017 +0300

    mmc: host: omap_hsmmc: checking for NULL instead of IS_ERR()
    
    
    [ Upstream commit ec5ab8933772c87f24ad62a4a602fe8949f423c2 ]
    
    devm_pinctrl_get() returns error pointers, it never returns NULL.
    
    Fixes: 455e5cd6f736 ("mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c84d2e72f5dd07d6a3fc4195a2b8574ba8f7721d
Author: James Smart <jsmart2021@gmail.com>
Date:   Fri Apr 21 16:04:56 2017 -0700

    Fix driver usage of 128B WQEs when WQ_CREATE is V1.
    
    
    [ Upstream commit 3f247de750b8dd8f50a2c1390e2a1238790a9dff ]
    
    There are two versions of a structure for queue creation and setup that the
    driver shares with FW. The driver was only treating as version 0.
    
    Verify WQ_CREATE with 128B WQEs in V0 and V1.
    
    Code review of another bug showed the driver passing
    128B WQEs and 8 pages in WQ CREATE and V0.
    Code inspection/instrumentation showed that the driver
    uses V0 in WQ_CREATE and if the caller passes queue->entry_size
    128B, the driver sets the hdr_version to V1 so all is good.
    When I tested the V1 WQ_CREATE, the mailbox failed causing
    the driver to unload.
    
    Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
    Signed-off-by: James Smart <james.smart@broadcom.com>
    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21bdd575943daef3c951ecd3dd70ef62bb9f065e
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Apr 21 13:39:09 2017 +0300

    HSI: ssi_protocol: double free in ssip_pn_xmit()
    
    
    [ Upstream commit 3026050179a3a9a6f5c892c414b5e36ecf092081 ]
    
    If skb_pad() fails then it frees skb and we don't need to free it again
    at the end of the function.
    
    Fixes: dc7bf5d7 ("HSI: Introduce driver for SSI Protocol")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Sebastian Reichel <sre@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bff38ff05503e2161d6fe2d6e1979db4e9b80e46
Author: Feras Daoud <ferasda@mellanox.com>
Date:   Sun Mar 19 11:18:54 2017 +0200

    IB/ipoib: Update broadcast object if PKey value was changed in index 0
    
    
    [ Upstream commit 9a9b8112699d78e7f317019b37f377e90023f3ed ]
    
    Update the broadcast address in the priv->broadcast object when the
    Pkey value changes in index 0, otherwise the multicast GID value will
    keep the previous value of the PKey, and will not be updated.
    This leads to interface state down because the interface will keep the
    old PKey value.
    
    For example, in SR-IOV environment, if the PF changes the value of PKey
    index 0 for one of the VFs, then the VF receives PKey change event that
    triggers heavy flush. This flush calls update_parent_pkey that update the
    broadcast object and its relevant members. If in this case the multicast
    GID will not be updated, the interface state will be down.
    
    Fixes: c2904141696e ("IPoIB: Fix pkey change flow for virtualization environments")
    Signed-off-by: Feras Daoud <ferasda@mellanox.com>
    Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
    Reviewed-by: Alex Vesker <valex@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ead2134a1859bd75c8b34d9bf020b289341eaac
Author: Mikhail Paulyshka <me@mixaill.tk>
Date:   Fri Apr 21 08:52:42 2017 +0200

    ALSA: hda - Fix headset microphone detection for ASUS N551 and N751
    
    
    [ Upstream commit fc7438b1eb12b6c93d7b7a62423779eb5dfc673c ]
    
    Headset microphone does not work out of the box on ASUS Nx51
    laptops. This patch fixes it.
    
    Patch tested on Asus N551 laptop. Asus N751 part is not tested, but
    according to [1] this laptop uses the same audiosystem.
    
    1. https://bugzilla.kernel.org/show_bug.cgi?id=117781
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195437
    Signed-off-by: Mikhail Paulyshka <me@mixaill.tk>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae7579e5308cece1a10028b5aba0b8fa9ed06401
Author: Bernd Faust <berndfaust@gmail.com>
Date:   Thu Feb 16 19:42:07 2017 +0100

    e1000e: fix timing for 82579 Gigabit Ethernet controller
    
    
    [ Upstream commit 5313eeccd2d7f486be4e5c7560e3e2be239ec8f7 ]
    
    After an upgrade to Linux kernel v4.x the hardware timestamps of the
    82579 Gigabit Ethernet Controller are different than expected.
    The values that are being read are almost four times as big as before
    the kernel upgrade.
    
    The difference is that after the upgrade the driver sets the clock
    frequency to 25MHz, where before the upgrade it was set to 96MHz. Intel
    confirmed that the correct frequency for this network adapter is 96MHz.
    
    Signed-off-by: Bernd Faust <berndfaust@gmail.com>
    Acked-by: Sasha Neftin <sasha.neftin@intel.com>
    Acked-by: Jacob Keller <jacob.e.keller@intel.com>
    Tested-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a5294f03a10031a9407d01287e6ccc800304bf3
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Apr 18 09:45:52 2017 -0700

    tcp: remove poll() flakes with FastOpen
    
    
    [ Upstream commit 0f9fa831aecfc297b7b45d4f046759bcefcf87f0 ]
    
    When using TCP FastOpen for an active session, we send one wakeup event
    from tcp_finish_connect(), right before the data eventually contained in
    the received SYNACK is queued to sk->sk_receive_queue.
    
    This means that depending on machine load or luck, poll() users
    might receive POLLOUT events instead of POLLIN|POLLOUT
    
    To fix this, we need to move the call to sk->sk_state_change()
    after the (optional) call to tcp_rcv_fastopen_synack()
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a4063b03ba4a76765705adb997124cbe7900938
Author: Alexey Kardashevskiy <aik@ozlabs.ru>
Date:   Fri Mar 24 17:48:10 2017 +1100

    KVM: PPC: Book3S PR: Exit KVM on failed mapping
    
    
    [ Upstream commit bd9166ffe624000140fc6b606b256df01fc0d060 ]
    
    At the moment kvmppc_mmu_map_page() returns -1 if
    mmu_hash_ops.hpte_insert() fails for any reason so the page fault handler
    resumes the guest and it faults on the same address again.
    
    This adds distinction to kvmppc_mmu_map_page() to return -EIO if
    mmu_hash_ops.hpte_insert() failed for a reason other than full pteg.
    At the moment only pSeries_lpar_hpte_insert() returns -2 if
    plpar_pte_enter() failed with a code other than H_PTEG_FULL.
    Other mmu_hash_ops.hpte_insert() instances can only fail with
    -1 "full pteg".
    
    With this change, if PR KVM fails to update HPT, it can signal
    the userspace about this instead of returning to guest and having
    the very same page fault over and over again.
    
    Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dec444b63dee03febc0abe04db6fe680b2c99c2b
Author: David Gibson <david@gibson.dropbear.id.au>
Date:   Thu Apr 13 12:13:00 2017 +1000

    scsi: virtio_scsi: Always try to read VPD pages
    
    
    [ Upstream commit 25d1d50e23275e141e3a3fe06c25a99f4c4bf4e0 ]
    
    Passed through SCSI targets may have transfer limits which come from the
    host SCSI controller or something on the host side other than the target
    itself.
    
    To make this work properly, the hypervisor can adjust the target's VPD
    information to advertise these limits.  But for that to work, the guest
    has to look at the VPD pages, which we won't do by default if it is an
    SPC-2 device, even if it does actually support it.
    
    This adds a workaround to address this, forcing devices attached to a
    virtio-scsi controller to always check the VPD pages.  This is modelled
    on a similar workaround for the storvsc (Hyper-V) SCSI controller,
    although that exists for slightly different reasons.
    
    A specific case which causes this is a volume from IBM's IPR RAID
    controller (which presents as an SPC-2 device, although it does support
    VPD) passed through with qemu's 'scsi-block' device.
    
    [mkp: fixed typo]
    
    Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
    Acked-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be5f85e3f355d4afe72e387e7b7fae054f731b51
Author: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Date:   Wed Apr 12 23:19:37 2017 +0530

    ath: Fix updating radar flags for coutry code India
    
    
    [ Upstream commit c0c345d4cacc6a1f39d4856f37dcf6e34f51a5e4 ]
    
    As per latest regulatory update for India, channel 52, 56, 60, 64
    is no longer restricted to DFS. Enabling DFS/no infra flags in driver
    results in applying all DFS related restrictions (like doing CAC etc
    before this channel moves to 'available state') for these channels
    even though the country code is programmed as 'India' in he hardware,
    fix this by relaxing the frequency range while applying RADAR flags
    only if the country code is programmed to India. If the frequency range
    needs to modified based on different country code, ath_is_radar_freq
    can be extended/modified dynamically.
    
    Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
    Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 65e796250cfb067092357bddf44cea97e9e1c717
Author: Marek Vasut <marex@denx.de>
Date:   Tue Apr 18 20:09:06 2017 +0200

    spi: dw: Disable clock after unregistering the host
    
    
    [ Upstream commit 400c18e3dc86e04ef5afec9b86a8586ca629b9e9 ]
    
    The dw_mmio driver disables the block clock before unregistering
    the host. The code unregistering the host may access the SPI block
    registers. If register access happens with block clock disabled,
    this may lead to a bus hang. Disable the clock after unregistering
    the host to prevent such situation.
    
    This bug was observed on Altera Cyclone V SoC.
    
    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: Mark Brown <broonie@kernel.org>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eba5af302e5c42711feaa5bd07cf36ee64e15a22
Author: Jasmin J <jasmin@anw.at>
Date:   Fri Mar 17 23:04:20 2017 -0300

    media/dvb-core: Race condition when writing to CAM
    
    
    [ Upstream commit e7080d4471d805d921a9ea21b32f911a91e248cb ]
    
    It started with a sporadic message in syslog: "CAM tried to send a
    buffer larger than the ecount size" This message is not the fault
    itself, but a consecutive fault, after a read error from the CAM. This
    happens only on several CAMs, several hardware, and of course sporadic.
    
    It is a consecutive fault, if the last read from the CAM did fail. I
    guess this will not happen on all CAMs, but at least it did on mine.
    There was a write error to the CAM and during the re-initialization
    procedure, the CAM finished the last read, although it got a RS.
    
    The write error to the CAM happened because a race condition between HC
    write, checking DA and FR.
    
    This patch added an additional check for DA(RE), just after checking FR.
    It is important to read the CAMs status register again, to give the CAM
    the necessary time for a proper reaction to HC. Please note the
    description within the source code (patch below).
    
    [mchehab@s-opensource.com: make checkpatch happy]
    
    Signed-off-by: Jasmin jessich <jasmin@anw.at>
    Tested-by: Ralph Metzler <rjkm@metzlerbros.de>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f566bb949757cb3312e31b79400c30103d4a8434
Author: David Ahern <dsa@cumulusnetworks.com>
Date:   Wed Apr 12 11:49:04 2017 -0700

    net: ipv6: send unsolicited NA on admin up
    
    
    [ Upstream commit 4a6e3c5def13c91adf2acc613837001f09af3baa ]
    
    ndisc_notify is the ipv6 equivalent to arp_notify. When arp_notify is
    set to 1, gratuitous arp requests are sent when the device is brought up.
    The same is expected when ndisc_notify is set to 1 (per ndisc_notify in
    Documentation/networking/ip-sysctl.txt). The NA is not sent on NETDEV_UP
    event; add it.
    
    Fixes: 5cb04436eef6 ("ipv6: add knob to send unsolicited ND on link-layer address change")
    Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e69880c86c7391e7a78eb05faa736fa77a7cf8a7
Author: Edgar Cherkasov <echerkasov@dev.rtsoft.ru>
Date:   Tue Apr 4 19:18:27 2017 +0300

    i2c: i2c-scmi: add a MS HID
    
    
    [ Upstream commit e058e7a4bc89104540a8a303682248614b5df6f1 ]
    
    Description of the problem:
     - i2c-scmi driver contains only two identifiers "SMBUS01" and "SMBUSIBM";
     - the fist HID (SMBUS01) is clearly defined in "SMBus Control Method
       Interface Specification, version 1.0": "Each device must specify
       'SMBUS01' as its _HID and use a unique _UID value";
     - unfortunately, BIOS vendors (like AMI) seem to ignore this requirement
       and implement "SMB0001" HID instead of "SMBUS01";
     - I speculate that they do this because only "SMB0001" is hard coded in
       Windows SMBus driver produced by Microsoft.
    
    This leads to following situation:
     - SMBus works out of box in Windows but not in Linux;
     - board vendors are forced to add correct "SMBUS01" HID to BIOS to make
       SMBus work in Linux. Moreover the same board vendors complain that
       tools (3-rd party ASL compiler) do not like the "SMBUS01" identifier
       and produce errors.  So they need to constantly patch the compiler for
       each new version of BIOS.
    
    As it is very unlikely that BIOS vendors implement a correct HID in
    future, I would propose to consider whether it is possible to work around
    the problem by adding MS HID to the Linux i2c-scmi driver.
    
    v2: move the definition of the new HID to the driver itself.
    
    Signed-off-by: Edgar Cherkasov <echerkasov@dev.rtsoft.ru>
    Signed-off-by: Michael Brunner <Michael.Brunner@kontron.com>
    Acked-by: Viktor Krasnov <vkrasnov@dev.rtsoft.ru>
    Reviewed-by: Jean Delvare <jdelvare@suse.de>
    Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 093c265afffb0a91a7611c3bb74d0883731a807b
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Apr 15 12:08:31 2017 +0200

    genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs
    
    
    [ Upstream commit 382bd4de61827dbaaf5fb4fb7b1f4be4a86505e7 ]
    
    When requesting a shared irq with IRQF_TRIGGER_NONE then the irqaction
    flags get filled with the trigger type from the irq_data:
    
            if (!(new->flags & IRQF_TRIGGER_MASK))
                    new->flags |= irqd_get_trigger_type(&desc->irq_data);
    
    On the first setup_irq() the trigger type in irq_data is NONE when the
    above code executes, then the irq is started up for the first time and
    then the actual trigger type gets established, but that's too late to fix
    up new->flags.
    
    When then a second user of the irq requests the irq with IRQF_TRIGGER_NONE
    its irqaction's triggertype gets set to the actual trigger type and the
    following check fails:
    
            if (!((old->flags ^ new->flags) & IRQF_TRIGGER_MASK))
    
    Resulting in the request_irq failing with -EBUSY even though both
    users requested the irq with IRQF_SHARED | IRQF_TRIGGER_NONE
    
    Fix this by comparing the new irqaction's trigger type to the trigger type
    stored in the irq_data which correctly reflects the actual trigger type
    being used for the irq.
    
    Suggested-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Marc Zyngier <marc.zyngier@arm.com>
    Link: http://lkml.kernel.org/r/20170415100831.17073-1-hdegoede@redhat.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fad89533e0d5067d38ffd119b4eee5e19d945821
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Apr 12 22:07:36 2017 +0200

    cpufreq/sh: Replace racy task affinity logic
    
    
    [ Upstream commit 205dcc1ecbc566cbc20acf246e68de3b080b3ecf ]
    
    The target() callback must run on the affected cpu. This is achieved by
    temporarily setting the affinity of the calling thread to the requested CPU
    and reset it to the original affinity afterwards.
    
    That's racy vs. concurrent affinity settings for that thread resulting in
    code executing on the wrong CPU.
    
    Replace it by work_on_cpu(). All call pathes which invoke the callbacks are
    already protected against CPU hotplug.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Sebastian Siewior <bigeasy@linutronix.de>
    Cc: linux-pm@vger.kernel.org
    Cc: Lai Jiangshan <jiangshanlai@gmail.com>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Len Brown <lenb@kernel.org>
    Link: http://lkml.kernel.org/r/20170412201042.958216363@linutronix.de
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d2cfeb58d8c120a95150006bc39063db2b7ac54
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Apr 12 22:07:34 2017 +0200

    ACPI/processor: Replace racy task affinity logic
    
    
    [ Upstream commit 8153f9ac43897f9f4786b30badc134fcc1a4fb11 ]
    
    acpi_processor_get_throttling() requires to invoke the getter function on
    the target CPU. This is achieved by temporarily setting the affinity of the
    calling user space thread to the requested CPU and reset it to the original
    affinity afterwards.
    
    That's racy vs. CPU hotplug and concurrent affinity settings for that
    thread resulting in code executing on the wrong CPU and overwriting the
    new affinity setting.
    
    acpi_processor_get_throttling() is invoked in two ways:
    
    1) The CPU online callback, which is already running on the target CPU and
       obviously protected against hotplug and not affected by affinity
       settings.
    
    2) The ACPI driver probe function, which is not protected against hotplug
       during modprobe.
    
    Switch it over to work_on_cpu() and protect the probe function against CPU
    hotplug.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Sebastian Siewior <bigeasy@linutronix.de>
    Cc: Lai Jiangshan <jiangshanlai@gmail.com>
    Cc: linux-acpi@vger.kernel.org
    Cc: Viresh Kumar <viresh.kumar@linaro.org>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Len Brown <lenb@kernel.org>
    Link: http://lkml.kernel.org/r/20170412201042.785920903@linutronix.de
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 177bea46fe929297547441508a48589fe4331daa
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Mon Dec 12 15:32:57 2016 -0800

    Input: ar1021_i2c - fix too long name in driver's device table
    
    
    [ Upstream commit 95123fc43560d6f4a60e74f72836e63cd8848f76 ]
    
    The name field in structure i2c_device_id is 20 characters, and we expect
    it to be NULL-terminated, however we are trying to stuff it with 21 bytes
    and thus NULL-terminator is lost. This causes issues when one creates
    device with name "MICROCHIP_AR1021_I2C" as i2c core cuts off the last "C",
    and automatic module loading by alias does not work as result.
    
    The -I2C suffix in the device name is superfluous, we know what bus we are
    dealing with, so let's drop it. Also, no other driver uses capitals, and
    the manufacturer name is normally not included, except in very rare cases
    of incompatible name collisions.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116211
    Fixes: dd4cae8bf166 ("Input: Add Microchip AR1021 i2c touchscreen")
    Reviewed-By: Christian Gmeiner <christian.gmeiner@gmail.com>
    Tested-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 50655ac3bc2f9ec73d828896c70f6be2229d4f29
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Apr 8 19:54:20 2017 +0200

    x86: i8259: export legacy_pic symbol
    
    
    [ Upstream commit 7ee06cb2f840a96be46233181ed4557901a74385 ]
    
    The classic PC rtc-coms driver has a workaround for broken ACPI device
    nodes for it which lack an irq resource. This workaround used to
    unconditionally hardcode the irq to 8 in these cases.
    
    This was causing irq conflict problems on systems without a legacy-pic
    so a recent patch added an if (nr_legacy_irqs()) guard to the
    workaround to avoid this irq conflict.
    
    nr_legacy_irqs() uses the legacy_pic symbol under the hood causing
    an undefined symbol error if the rtc-cmos code is build as a module.
    
    This commit exports the legacy_pic symbol to fix this.
    
    Cc: rtc-linux@googlegroups.com
    Cc: alexandre.belloni@free-electrons.com
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 911e850bc967ff7c00524f4d8f068ce8a7a12695
Author: Santeri Toivonen <santeri.toivonen@vatsul.com>
Date:   Tue Apr 4 21:09:00 2017 +0300

    platform/x86: asus-nb-wmi: Add wapf4 quirk for the X302UA
    
    
    [ Upstream commit f35823619db8bbaa2afea8705f239c3cecb9d22f ]
    
    Asus laptop X302UA starts up with Wi-Fi disabled,
    without a way to enable it. Set wapf=4 to fix the problem.
    
    Signed-off-by: Santeri Toivonen <santeri.toivonen@vatsul.com>
    Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>