commit bfb9e5c03076a446b1f4f6a523ddc8d723c907a6
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Dec 17 20:40:05 2019 +0100

    Linux 4.14.159

commit 002fffa0fb32a3bb14b6422bac2cbb263cc0476b
Author: Erhard Furtner <erhard_f@mailbox.org>
Date:   Tue Nov 26 02:48:04 2019 +0100

    of: unittest: fix memory leak in attach_node_and_children
    
    [ Upstream commit 2aacace6dbbb6b6ce4e177e6c7ea901f389c0472 ]
    
    In attach_node_and_children memory is allocated for full_name via
    kasprintf. If the condition of the 1st if is not met the function
    returns early without freeing the memory. Add a kfree() to fix that.
    
    This has been detected with kmemleak:
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=205327
    
    It looks like the leak was introduced by this commit:
    Fixes: 5babefb7f7ab ("of: unittest: allow base devicetree to have symbol metadata")
    
    Signed-off-by: Erhard Furtner <erhard_f@mailbox.org>
    Reviewed-by: Michael Ellerman <mpe@ellerman.id.au>
    Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2e22c56fb8993f9e7f329a29a2fb87585526859d
Author: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
Date:   Wed Nov 27 17:57:50 2019 +0100

    raid5: need to set STRIPE_HANDLE for batch head
    
    [ Upstream commit a7ede3d16808b8f3915c8572d783530a82b2f027 ]
    
    With commit 6ce220dd2f8ea71d6afc29b9a7524c12e39f374a ("raid5: don't set
    STRIPE_HANDLE to stripe which is in batch list"), we don't want to set
    STRIPE_HANDLE flag for sh which is already in batch list.
    
    However, the stripe which is the head of batch list should set this flag,
    otherwise panic could happen inside init_stripe at BUG_ON(sh->batch_head),
    it is reproducible with raid5 on top of nvdimm devices per Xiao oberserved.
    
    Thanks for Xiao's effort to verify the change.
    
    Fixes: 6ce220dd2f8ea ("raid5: don't set STRIPE_HANDLE to stripe which is in batch list")
    Reported-by: Xiao Ni <xni@redhat.com>
    Tested-by: Xiao Ni <xni@redhat.com>
    Signed-off-by: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
    Signed-off-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d6000c7fc76e02d259e9e987d960d3404115d693
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Nov 6 12:51:09 2019 +0100

    gpiolib: acpi: Add Terra Pad 1061 to the run_edge_events_on_boot_blacklist
    
    [ Upstream commit 2727315df3f5ffbebcb174eed3153944a858b66f ]
    
    The Terra Pad 1061 has the usual micro-USB-B id-pin handler, but instead
    of controlling the actual micro-USB-B it turns the 5V boost for the
    tablet's USB-A connector and its keyboard-cover connector off.
    
    The actual micro-USB-B connector on the tablet is wired for charging only,
    and its id pin is *not* connected to the GPIO which is used for the
    (broken) id-pin event handler in the DSDT.
    
    While at it not only add a comment why the Terra Pad 1061 is on the
    blacklist, but also fix the missing comment for the Minix Neo Z83-4 entry.
    
    Fixes: 61f7f7c8f978 ("gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklist")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4faf1cc3dbbd85e49787f4ff3ffa21257c2256bb
Author: Konstantin Khorenko <khorenko@virtuozzo.com>
Date:   Wed Nov 13 12:29:50 2019 +0300

    kernel/module.c: wakeup processes in module_wq on module unload
    
    [ Upstream commit 5d603311615f612320bb77bd2a82553ef1ced5b7 ]
    
    Fix the race between load and unload a kernel module.
    
    sys_delete_module()
     try_stop_module()
      mod->state = _GOING
                                            add_unformed_module()
                                             old = find_module_all()
                                             (old->state == _GOING =>
                                              wait_event_interruptible())
    
                                             During pre-condition
                                             finished_loading() rets 0
                                             schedule()
                                             (never gets waken up later)
     free_module()
      mod->state = _UNFORMED
       list_del_rcu(&mod->list)
       (dels mod from "modules" list)
    
    return
    
    The race above leads to modprobe hanging forever on loading
    a module.
    
    Error paths on loading module call wake_up_all(&module_wq) after
    freeing module, so let's do the same on straight module unload.
    
    Fixes: 6e6de3dee51a ("kernel/module.c: Only return -EEXIST for modules that have finished loading")
    Reviewed-by: Prarit Bhargava <prarit@redhat.com>
    Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
    Signed-off-by: Jessica Yu <jeyu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cb9e778a29b803402ef7451451063d11f583c598
Author: Bob Peterson <rpeterso@redhat.com>
Date:   Thu Nov 14 09:49:11 2019 -0500

    gfs2: fix glock reference problem in gfs2_trans_remove_revoke
    
    [ Upstream commit fe5e7ba11fcf1d75af8173836309e8562aefedef ]
    
    Commit 9287c6452d2b fixed a situation in which gfs2 could use a glock
    after it had been freed. To do that, it temporarily added a new glock
    reference by calling gfs2_glock_hold in function gfs2_add_revoke.
    However, if the bd element was removed by gfs2_trans_remove_revoke, it
    failed to drop the additional reference.
    
    This patch adds logic to gfs2_trans_remove_revoke to properly drop the
    additional glock reference.
    
    Fixes: 9287c6452d2b ("gfs2: Fix occasional glock use-after-free")
    Cc: stable@vger.kernel.org # v5.2+
    Signed-off-by: Bob Peterson <rpeterso@redhat.com>
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6360d971e40fe56e6c945d17972d69c69194c4d8
Author: Eran Ben Elisha <eranbe@mellanox.com>
Date:   Thu Dec 5 10:30:22 2019 +0200

    net/mlx5e: Fix SFF 8472 eeprom length
    
    [ Upstream commit c431f8597863a91eea6024926e0c1b179cfa4852 ]
    
    SFF 8472 eeprom length is 512 bytes. Fix module info return value to
    support 512 bytes read.
    
    Fixes: ace329f4ab3b ("net/mlx5e: ethtool, Remove unsupported SFP EEPROM high pages query")
    Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
    Reviewed-by: Aya Levin <ayal@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cfd2194d549935af5230386aebfb6693c1770f83
Author: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Date:   Tue Oct 1 11:03:59 2019 +0300

    sunrpc: fix crash when cache_head become valid before update
    
    [ Upstream commit 5fcaf6982d1167f1cd9b264704f6d1ef4c505d54 ]
    
    I was investigating a crash in our Virtuozzo7 kernel which happened in
    in svcauth_unix_set_client. I found out that we access m_client field
    in ip_map structure, which was received from sunrpc_cache_lookup (we
    have a bit older kernel, now the code is in sunrpc_cache_add_entry), and
    these field looks uninitialized (m_client == 0x74 don't look like a
    pointer) but in the cache_head in flags we see 0x1 which is CACHE_VALID.
    
    It looks like the problem appeared from our previous fix to sunrpc (1):
    commit 4ecd55ea0742 ("sunrpc: fix cache_head leak due to queued
    request")
    
    And we've also found a patch already fixing our patch (2):
    commit d58431eacb22 ("sunrpc: don't mark uninitialised items as VALID.")
    
    Though the crash is eliminated, I think the core of the problem is not
    completely fixed:
    
    Neil in the patch (2) makes cache_head CACHE_NEGATIVE, before
    cache_fresh_locked which was added in (1) to fix crash. These way
    cache_is_valid won't say the cache is valid anymore and in
    svcauth_unix_set_client the function cache_check will return error
    instead of 0, and we don't count entry as initialized.
    
    But it looks like we need to remove cache_fresh_locked completely in
    sunrpc_cache_lookup:
    
    In (1) we've only wanted to make cache_fresh_unlocked->cache_dequeue so
    that cache_requests with no readers also release corresponding
    cache_head, to fix their leak.  We with Vasily were not sure if
    cache_fresh_locked and cache_fresh_unlocked should be used in pair or
    not, so we've guessed to use them in pair.
    
    Now we see that we don't want the CACHE_VALID bit set here by
    cache_fresh_locked, as "valid" means "initialized" and there is no
    initialization in sunrpc_cache_add_entry. Both expiry_time and
    last_refresh are not used in cache_fresh_unlocked code-path and also not
    required for the initial fix.
    
    So to conclude cache_fresh_locked was called by mistake, and we can just
    safely remove it instead of crutching it with CACHE_NEGATIVE. It looks
    ideologically better for me. Hope I don't miss something here.
    
    Here is our crash backtrace:
    [13108726.326291] BUG: unable to handle kernel NULL pointer dereference at 0000000000000074
    [13108726.326365] IP: [<ffffffffc01f79eb>] svcauth_unix_set_client+0x2ab/0x520 [sunrpc]
    [13108726.326448] PGD 0
    [13108726.326468] Oops: 0002 [#1] SMP
    [13108726.326497] Modules linked in: nbd isofs xfs loop kpatch_cumulative_81_0_r1(O) xt_physdev nfnetlink_queue bluetooth rfkill ip6table_nat nf_nat_ipv6 ip_vs_wrr ip_vs_wlc ip_vs_sh nf_conntrack_netlink ip_vs_sed ip_vs_pe_sip nf_conntrack_sip ip_vs_nq ip_vs_lc ip_vs_lblcr ip_vs_lblc ip_vs_ftp ip_vs_dh nf_nat_ftp nf_conntrack_ftp iptable_raw xt_recent nf_log_ipv6 xt_hl ip6t_rt nf_log_ipv4 nf_log_common xt_LOG xt_limit xt_TCPMSS xt_tcpmss vxlan ip6_udp_tunnel udp_tunnel xt_statistic xt_NFLOG nfnetlink_log dummy xt_mark xt_REDIRECT nf_nat_redirect raw_diag udp_diag tcp_diag inet_diag netlink_diag af_packet_diag unix_diag rpcsec_gss_krb5 xt_addrtype ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 ebtable_nat ebtable_broute nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_mangle ip6table_raw nfsv4
    [13108726.327173]  dns_resolver cls_u32 binfmt_misc arptable_filter arp_tables ip6table_filter ip6_tables devlink fuse_kio_pcs ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_nat iptable_nat nf_nat_ipv4 xt_comment nf_conntrack_ipv4 nf_defrag_ipv4 xt_wdog_tmo xt_multiport bonding xt_set xt_conntrack iptable_filter iptable_mangle kpatch(O) ebtable_filter ebt_among ebtables ip_set_hash_ip ip_set nfnetlink vfat fat skx_edac intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass fuse pcspkr ses enclosure joydev sg mei_me hpwdt hpilo lpc_ich mei ipmi_si shpchp ipmi_devintf ipmi_msghandler xt_ipvs acpi_power_meter ip_vs_rr nfsv3 nfsd auth_rpcgss nfs_acl nfs lockd grace fscache nf_nat cls_fw sch_htb sch_cbq sch_sfq ip_vs em_u32 nf_conntrack tun br_netfilter veth overlay ip6_vzprivnet ip6_vznetstat ip_vznetstat
    [13108726.327817]  ip_vzprivnet vziolimit vzevent vzlist vzstat vznetstat vznetdev vzmon vzdev bridge pio_kaio pio_nfs pio_direct pfmt_raw pfmt_ploop1 ploop ip_tables ext4 mbcache jbd2 sd_mod crc_t10dif crct10dif_generic mgag200 i2c_algo_bit drm_kms_helper scsi_transport_iscsi 8021q syscopyarea sysfillrect garp sysimgblt fb_sys_fops mrp stp ttm llc bnx2x crct10dif_pclmul crct10dif_common crc32_pclmul crc32c_intel drm dm_multipath ghash_clmulni_intel uas aesni_intel lrw gf128mul glue_helper ablk_helper cryptd tg3 smartpqi scsi_transport_sas mdio libcrc32c i2c_core usb_storage ptp pps_core wmi sunrpc dm_mirror dm_region_hash dm_log dm_mod [last unloaded: kpatch_cumulative_82_0_r1]
    [13108726.328403] CPU: 35 PID: 63742 Comm: nfsd ve: 51332 Kdump: loaded Tainted: G        W  O   ------------   3.10.0-862.20.2.vz7.73.29 #1 73.29
    [13108726.328491] Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 10/02/2018
    [13108726.328554] task: ffffa0a6a41b1160 ti: ffffa0c2a74bc000 task.ti: ffffa0c2a74bc000
    [13108726.328610] RIP: 0010:[<ffffffffc01f79eb>]  [<ffffffffc01f79eb>] svcauth_unix_set_client+0x2ab/0x520 [sunrpc]
    [13108726.328706] RSP: 0018:ffffa0c2a74bfd80  EFLAGS: 00010246
    [13108726.328750] RAX: 0000000000000001 RBX: ffffa0a6183ae000 RCX: 0000000000000000
    [13108726.328811] RDX: 0000000000000074 RSI: 0000000000000286 RDI: ffffa0c2a74bfcf0
    [13108726.328864] RBP: ffffa0c2a74bfe00 R08: ffffa0bab8c22960 R09: 0000000000000001
    [13108726.328916] R10: 0000000000000001 R11: 0000000000000001 R12: ffffa0a32aa7f000
    [13108726.328969] R13: ffffa0a6183afac0 R14: ffffa0c233d88d00 R15: ffffa0c2a74bfdb4
    [13108726.329022] FS:  0000000000000000(0000) GS:ffffa0e17f9c0000(0000) knlGS:0000000000000000
    [13108726.329081] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [13108726.332311] CR2: 0000000000000074 CR3: 00000026a1b28000 CR4: 00000000007607e0
    [13108726.334606] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [13108726.336754] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [13108726.338908] PKRU: 00000000
    [13108726.341047] Call Trace:
    [13108726.343074]  [<ffffffff8a2c78b4>] ? groups_alloc+0x34/0x110
    [13108726.344837]  [<ffffffffc01f5eb4>] svc_set_client+0x24/0x30 [sunrpc]
    [13108726.346631]  [<ffffffffc01f2ac1>] svc_process_common+0x241/0x710 [sunrpc]
    [13108726.348332]  [<ffffffffc01f3093>] svc_process+0x103/0x190 [sunrpc]
    [13108726.350016]  [<ffffffffc07d605f>] nfsd+0xdf/0x150 [nfsd]
    [13108726.351735]  [<ffffffffc07d5f80>] ? nfsd_destroy+0x80/0x80 [nfsd]
    [13108726.353459]  [<ffffffff8a2bf741>] kthread+0xd1/0xe0
    [13108726.355195]  [<ffffffff8a2bf670>] ? create_kthread+0x60/0x60
    [13108726.356896]  [<ffffffff8a9556dd>] ret_from_fork_nospec_begin+0x7/0x21
    [13108726.358577]  [<ffffffff8a2bf670>] ? create_kthread+0x60/0x60
    [13108726.360240] Code: 4c 8b 45 98 0f 8e 2e 01 00 00 83 f8 fe 0f 84 76 fe ff ff 85 c0 0f 85 2b 01 00 00 49 8b 50 40 b8 01 00 00 00 48 89 93 d0 1a 00 00 <f0> 0f c1 02 83 c0 01 83 f8 01 0f 8e 53 02 00 00 49 8b 44 24 38
    [13108726.363769] RIP  [<ffffffffc01f79eb>] svcauth_unix_set_client+0x2ab/0x520 [sunrpc]
    [13108726.365530]  RSP <ffffa0c2a74bfd80>
    [13108726.367179] CR2: 0000000000000074
    
    Fixes: d58431eacb22 ("sunrpc: don't mark uninitialised items as VALID.")
    Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
    Acked-by: NeilBrown <neilb@suse.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 80797bdcc591c24d8714bbc1342595b7b171bdd4
Author: Tejun Heo <tj@kernel.org>
Date:   Fri Sep 20 13:39:57 2019 -0700

    workqueue: Fix missing kfree(rescuer) in destroy_workqueue()
    
    commit 8efe1223d73c218ce7e8b2e0e9aadb974b582d7f upstream.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Qian Cai <cai@lca.pw>
    Fixes: def98c84b6cd ("workqueue: Fix spurious sanity check failures in destroy_workqueue()")
    Cc: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c499f898286777653deac3d47885aa95ffad1046
Author: Ming Lei <ming.lei@redhat.com>
Date:   Mon Nov 4 16:26:53 2019 +0800

    blk-mq: make sure that line break can be printed
    
    commit d2c9be89f8ebe7ebcc97676ac40f8dec1cf9b43a upstream.
    
    8962842ca5ab ("blk-mq: avoid sysfs buffer overflow with too many CPU cores")
    avoids sysfs buffer overflow, and reserves one character for line break.
    However, the last snprintf() doesn't get correct 'size' parameter passed
    in, so fixed it.
    
    Fixes: 8962842ca5ab ("blk-mq: avoid sysfs buffer overflow with too many CPU cores")
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Cc: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dca66097c0187a3b8e301991873eb5007f6cfae6
Author: Daniel Schultz <d.schultz@phytec.de>
Date:   Tue Sep 17 10:12:53 2019 +0200

    mfd: rk808: Fix RK818 ID template
    
    [ Upstream commit 37ef8c2c15bdc1322b160e38986c187de2b877b2 ]
    
    The Rockchip PMIC driver can automatically detect connected component
    versions by reading the ID_MSB and ID_LSB registers. The probe function
    will always fail with RK818 PMICs because the ID_MSK is 0xFFF0 and the
    RK818 template ID is 0x8181.
    
    This patch changes this value to 0x8180.
    
    Fixes: 9d6105e19f61 ("mfd: rk808: Fix up the chip id get failed")
    Cc: stable@vger.kernel.org
    Cc: Elaine Zhang <zhangqing@rock-chips.com>
    Cc: Joseph Chen <chenjh@rock-chips.com>
    Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7c112026ce3b6d215b9ceccbe339634b17c1e0f3
Author: yangerkun <yangerkun@huawei.com>
Date:   Thu Sep 19 14:35:08 2019 +0800

    ext4: fix a bug in ext4_wait_for_tail_page_commit
    
    commit 565333a1554d704789e74205989305c811fd9c7a upstream.
    
    No need to wait for any commit once the page is fully truncated.
    Besides, it may confuse e.g. concurrent ext4_writepage() with the page
    still be dirty (will be cleared by truncate_pagecache() in
    ext4_setattr()) but buffers has been freed; and then trigger a bug
    show as below:
    
    [   26.057508] ------------[ cut here ]------------
    [   26.058531] kernel BUG at fs/ext4/inode.c:2134!
    ...
    [   26.088130] Call trace:
    [   26.088695]  ext4_writepage+0x914/0xb28
    [   26.089541]  writeout.isra.4+0x1b4/0x2b8
    [   26.090409]  move_to_new_page+0x3b0/0x568
    [   26.091338]  __unmap_and_move+0x648/0x988
    [   26.092241]  unmap_and_move+0x48c/0xbb8
    [   26.093096]  migrate_pages+0x220/0xb28
    [   26.093945]  kernel_mbind+0x828/0xa18
    [   26.094791]  __arm64_sys_mbind+0xc8/0x138
    [   26.095716]  el0_svc_common+0x190/0x490
    [   26.096571]  el0_svc_handler+0x60/0xd0
    [   26.097423]  el0_svc+0x8/0xc
    
    Run the procedure (generate by syzkaller) parallel with ext3.
    
    void main()
    {
            int fd, fd1, ret;
            void *addr;
            size_t length = 4096;
            int flags;
            off_t offset = 0;
            char *str = "12345";
    
            fd = open("a", O_RDWR | O_CREAT);
            assert(fd >= 0);
    
            /* Truncate to 4k */
            ret = ftruncate(fd, length);
            assert(ret == 0);
    
            /* Journal data mode */
            flags = 0xc00f;
            ret = ioctl(fd, _IOW('f', 2, long), &flags);
            assert(ret == 0);
    
            /* Truncate to 0 */
            fd1 = open("a", O_TRUNC | O_NOATIME);
            assert(fd1 >= 0);
    
            addr = mmap(NULL, length, PROT_WRITE | PROT_READ,
                                            MAP_SHARED, fd, offset);
            assert(addr != (void *)-1);
    
            memcpy(addr, str, 5);
            mbind(addr, length, 0, 0, 0, MPOL_MF_MOVE);
    }
    
    And the bug will be triggered once we seen the below order.
    
    reproduce1                         reproduce2
    
    ...                            |   ...
    truncate to 4k                 |
    change to journal data mode    |
                                   |   memcpy(set page dirty)
    truncate to 0:                 |
    ext4_setattr:                  |
    ...                            |
    ext4_wait_for_tail_page_commit |
                                   |   mbind(trigger bug)
    truncate_pagecache(clean dirty)|   ...
    ...                            |
    
    mbind will call ext4_writepage() since the page still be dirty, and then
    report the bug since the buffers has been free. Fix it by return
    directly once offset equals to 0 which means the page has been fully
    truncated.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: yangerkun <yangerkun@huawei.com>
    Link: https://lore.kernel.org/r/20190919063508.1045-1-yangerkun@huawei.com
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f49aa24d035c965146a96c2c64901b099f7fbae1
Author: Chen Jun <chenjun102@huawei.com>
Date:   Sat Nov 30 17:58:11 2019 -0800

    mm/shmem.c: cast the type of unmap_start to u64
    
    commit aa71ecd8d86500da6081a72da6b0b524007e0627 upstream.
    
    In 64bit system. sb->s_maxbytes of shmem filesystem is MAX_LFS_FILESIZE,
    which equal LLONG_MAX.
    
    If offset > LLONG_MAX - PAGE_SIZE, offset + len < LLONG_MAX in
    shmem_fallocate, which will pass the checking in vfs_fallocate.
    
            /* Check for wrap through zero too */
            if (((offset + len) > inode->i_sb->s_maxbytes) || ((offset + len) < 0))
                    return -EFBIG;
    
    loff_t unmap_start = round_up(offset, PAGE_SIZE) in shmem_fallocate
    causes a overflow.
    
    Syzkaller reports a overflow problem in mm/shmem:
    
      UBSAN: Undefined behaviour in mm/shmem.c:2014:10
      signed integer overflow: '9223372036854775807 + 1' cannot be represented in type 'long long int'
      CPU: 0 PID:17076 Comm: syz-executor0 Not tainted 4.1.46+ #1
      Hardware name: linux, dummy-virt (DT)
      Call trace:
         dump_backtrace+0x0/0x2c8 arch/arm64/kernel/traps.c:100
         show_stack+0x20/0x30 arch/arm64/kernel/traps.c:238
         __dump_stack lib/dump_stack.c:15 [inline]
         ubsan_epilogue+0x18/0x70 lib/ubsan.c:164
         handle_overflow+0x158/0x1b0 lib/ubsan.c:195
         shmem_fallocate+0x6d0/0x820 mm/shmem.c:2104
         vfs_fallocate+0x238/0x428 fs/open.c:312
         SYSC_fallocate fs/open.c:335 [inline]
         SyS_fallocate+0x54/0xc8 fs/open.c:239
    
    The highest bit of unmap_start will be appended with sign bit 1
    (overflow) when calculate shmem_falloc.start:
    
        shmem_falloc.start = unmap_start >> PAGE_SHIFT.
    
    Fix it by casting the type of unmap_start to u64, when right shifted.
    
    This bug is found in LTS Linux 4.1.  It also seems to exist in mainline.
    
    Link: http://lkml.kernel.org/r/1573867464-5107-1-git-send-email-chenjun102@huawei.com
    Signed-off-by: Chen Jun <chenjun102@huawei.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Qian Cai <cai@lca.pw>
    Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e61a32ba9a028d0288cfb0f9ec4243086e8ec90b
Author: Will Deacon <will@kernel.org>
Date:   Mon Nov 4 15:58:15 2019 +0000

    firmware: qcom: scm: Ensure 'a0' status code is treated as signed
    
    commit ff34f3cce278a0982a7b66b1afaed6295141b1fc upstream.
    
    The 'a0' member of 'struct arm_smccc_res' is declared as 'unsigned long',
    however the Qualcomm SCM firmware interface driver expects to receive
    negative error codes via this field, so ensure that it's cast to 'long'
    before comparing to see if it is less than 0.
    
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d5a2955049171e48feba628e60f15206689bba94
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Mon Nov 11 22:18:13 2019 -0500

    ext4: work around deleting a file with i_nlink == 0 safely
    
    commit c7df4a1ecb8579838ec8c56b2bb6a6716e974f37 upstream.
    
    If the file system is corrupted such that a file's i_links_count is
    too small, then it's possible that when unlinking that file, i_nlink
    will already be zero.  Previously we were working around this kind of
    corruption by forcing i_nlink to one; but we were doing this before
    trying to delete the directory entry --- and if the file system is
    corrupted enough that ext4_delete_entry() fails, then we exit with
    i_nlink elevated, and this causes the orphan inode list handling to be
    FUBAR'ed, such that when we unmount the file system, the orphan inode
    list can get corrupted.
    
    A better way to fix this is to simply skip trying to call drop_nlink()
    if i_nlink is already zero, thus moving the check to the place where
    it makes the most sense.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=205433
    
    Link: https://lore.kernel.org/r/20191112032903.8828-1-tytso@mit.edu
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Reviewed-by: Andreas Dilger <adilger@dilger.ca>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf9e11a310348a49ed481195ea6d686d3a3bfd1c
Author: Vincenzo Frascino <vincenzo.frascino@arm.com>
Date:   Mon Dec 2 07:57:29 2019 +0000

    powerpc: Fix vDSO clock_getres()
    
    [ Upstream commit 552263456215ada7ee8700ce022d12b0cffe4802 ]
    
    clock_getres in the vDSO library has to preserve the same behaviour
    of posix_get_hrtimer_res().
    
    In particular, posix_get_hrtimer_res() does:
        sec = 0;
        ns = hrtimer_resolution;
    and hrtimer_resolution depends on the enablement of the high
    resolution timers that can happen either at compile or at run time.
    
    Fix the powerpc vdso implementation of clock_getres keeping a copy of
    hrtimer_resolution in vdso data and using that directly.
    
    Fixes: a7f290dad32e ("[PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel")
    Cc: stable@vger.kernel.org
    Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
    Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
    Acked-by: Shuah Khan <skhan@linuxfoundation.org>
    [chleroy: changed CLOCK_REALTIME_RES to CLOCK_HRTIMER_RES]
    Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/a55eca3a5e85233838c2349783bcb5164dae1d09.1575273217.git.christophe.leroy@c-s.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c1a61364fb72a1b2c03ec9fbf9d5329e432956ea
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Mon Nov 18 21:57:11 2019 -0700

    powerpc: Avoid clang warnings around setjmp and longjmp
    
    [ Upstream commit c9029ef9c95765e7b63c4d9aa780674447db1ec0 ]
    
    Commit aea447141c7e ("powerpc: Disable -Wbuiltin-requires-header when
    setjmp is used") disabled -Wbuiltin-requires-header because of a
    warning about the setjmp and longjmp declarations.
    
    r367387 in clang added another diagnostic around this, complaining
    that there is no jmp_buf declaration.
    
      In file included from ../arch/powerpc/xmon/xmon.c:47:
      ../arch/powerpc/include/asm/setjmp.h:10:13: error: declaration of
      built-in function 'setjmp' requires the declaration of the 'jmp_buf'
      type, commonly provided in the header <setjmp.h>.
      [-Werror,-Wincomplete-setjmp-declaration]
      extern long setjmp(long *);
                  ^
      ../arch/powerpc/include/asm/setjmp.h:11:13: error: declaration of
      built-in function 'longjmp' requires the declaration of the 'jmp_buf'
      type, commonly provided in the header <setjmp.h>.
      [-Werror,-Wincomplete-setjmp-declaration]
      extern void longjmp(long *, long);
                  ^
      2 errors generated.
    
    We are not using the standard library's longjmp/setjmp implementations
    for obvious reasons; make this clear to clang by using -ffreestanding
    on these files.
    
    Cc: stable@vger.kernel.org # 4.14+
    Suggested-by: Segher Boessenkool <segher@kernel.crashing.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20191119045712.39633-3-natechancellor@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cd087b7f2a1db06185461f143f039a399f5b9e21
Author: Miaoqing Pan <miaoqing@codeaurora.org>
Date:   Fri May 24 11:16:22 2019 +0800

    ath10k: fix fw crash by moving chip reset after napi disabled
    
    [ Upstream commit 08d80e4cd27ba19f9bee9e5f788f9a9fc440a22f ]
    
    On SMP platform, when continuously running wifi up/down, the napi
    poll can be scheduled during chip reset, which will call
    ath10k_pci_has_fw_crashed() to check the fw status. But in the reset
    period, the value from FW_INDICATOR_ADDRESS register will return
    0xdeadbeef, which also be treated as fw crash. Fix the issue by
    moving chip reset after napi disabled.
    
    ath10k_pci 0000:01:00.0: firmware crashed! (guid 73b30611-5b1e-4bdd-90b4-64c81eb947b6)
    ath10k_pci 0000:01:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
    ath10k_pci 0000:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1
    ath10k_pci 0000:01:00.0: failed to get memcpy hi address for firmware address 4: -16
    ath10k_pci 0000:01:00.0: failed to read firmware dump area: -16
    ath10k_pci 0000:01:00.0: Copy Engine register dump:
    ath10k_pci 0000:01:00.0: [00]: 0x0004a000   0   0   0   0
    ath10k_pci 0000:01:00.0: [01]: 0x0004a400   0   0   0   0
    ath10k_pci 0000:01:00.0: [02]: 0x0004a800   0   0   0   0
    ath10k_pci 0000:01:00.0: [03]: 0x0004ac00   0   0   0   0
    ath10k_pci 0000:01:00.0: [04]: 0x0004b000   0   0   0   0
    ath10k_pci 0000:01:00.0: [05]: 0x0004b400   0   0   0   0
    ath10k_pci 0000:01:00.0: [06]: 0x0004b800   0   0   0   0
    ath10k_pci 0000:01:00.0: [07]: 0x0004bc00   1   0   1   0
    ath10k_pci 0000:01:00.0: [08]: 0x0004c000   0   0   0   0
    ath10k_pci 0000:01:00.0: [09]: 0x0004c400   0   0   0   0
    ath10k_pci 0000:01:00.0: [10]: 0x0004c800   0   0   0   0
    ath10k_pci 0000:01:00.0: [11]: 0x0004cc00   0   0   0   0
    
    Tested HW: QCA9984,QCA9887,WCN3990
    
    Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5e3816e76d26696acb298920e0cf9be495a9c99c
Author: Helen Koike <helen.koike@collabora.com>
Date:   Fri May 17 13:20:11 2019 -0400

    media: vimc: fix component match compare
    
    [ Upstream commit ee1c71a8e1456ab53fe667281d855849edf26a4d ]
    
    If the system has other devices being registered in the component
    framework, the compare function will be called with a device that
    doesn't belong to vimc.
    This device is not necessarily a platform_device, nor have a
    platform_data (which causes a NULL pointer dereference error) and if it
    does have a pdata, it is not necessarily type of struct vimc_platform_data.
    So casting to any of these types is wrong.
    
    Instead of expecting a given pdev with a given pdata, just expect for
    the device it self. vimc-core is the one who creates them, we know in
    advance exactly which object to expect in the match.
    
    Fixes: 4a29b7090749 ("[media] vimc: Subdevices as modules")
    
    Signed-off-by: Helen Koike <helen.koike@collabora.com>
    Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
    Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7aeb6588a4a777496834787f4f19cae9dcdfecbe
Author: Ido Schimmel <idosch@mellanox.com>
Date:   Tue Jun 11 10:19:41 2019 +0300

    mlxsw: spectrum_router: Refresh nexthop neighbour when it becomes dead
    
    [ Upstream commit 83d5782681cc12b3d485a83cb34c46b2445f510c ]
    
    The driver tries to periodically refresh neighbours that are used to
    reach nexthops. This is done by periodically calling neigh_event_send().
    
    However, if the neighbour becomes dead, there is nothing we can do to
    return it to a connected state and the above function call is basically
    a NOP.
    
    This results in the nexthop never being written to the device's
    adjacency table and therefore never used to forward packets.
    
    Fix this by dropping our reference from the dead neighbour and
    associating the nexthop with a new neigbhour which we will try to
    refresh.
    
    Fixes: a7ff87acd995 ("mlxsw: spectrum_router: Implement next-hop routing")
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Reported-by: Alex Veber <alexve@mellanox.com>
    Tested-by: Alex Veber <alexve@mellanox.com>
    Acked-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8799fa7c7d07cb2fa5d375069a07de8f3fda33b4
Author: Tony Lindgren <tony@atomide.com>
Date:   Sun Apr 7 11:12:50 2019 -0700

    power: supply: cpcap-battery: Fix signed counter sample register
    
    [ Upstream commit c68b901ac4fa969db8917b6a9f9b40524a690d20 ]
    
    The accumulator sample register is signed 32-bits wide register on
    droid 4. And only the earlier version of cpcap has a signed 24-bits
    wide register. We're currently passing it around as unsigned, so
    let's fix that and use sign_extend32() for the earlier revision.
    
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Acked-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b5b43a3dba23028b2a3ea388fe4d9d6e8ebec9ef
Author: Shirish S <Shirish.S@amd.com>
Date:   Wed Jan 16 15:10:40 2019 +0000

    x86/MCE/AMD: Carve out the MC4_MISC thresholding quirk
    
    [ Upstream commit 30aa3d26edb0f3d7992757287eec0ca588a5c259 ]
    
    The MC4_MISC thresholding quirk needs to be applied during S5 -> S0 and
    S3 -> S0 state transitions, which follow different code paths. Carve it
    out into a separate function and call it mce_amd_feature_init() where
    the two code paths of the state transitions converge.
    
     [ bp: massage commit message and the carved out function. ]
    
    Signed-off-by: Shirish S <shirish.s@amd.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Vishal Verma <vishal.l.verma@intel.com>
    Cc: Yazen Ghannam <yazen.ghannam@amd.com>
    Cc: x86-ml <x86@kernel.org>
    Link: https://lkml.kernel.org/r/1547651417-23583-3-git-send-email-shirish.s@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 67717e5ec607db7b841f2c48eb8c030d7466a0df
Author: Shirish S <Shirish.S@amd.com>
Date:   Thu Jan 10 07:54:40 2019 +0000

    x86/MCE/AMD: Turn off MC4_MISC thresholding on all family 0x15 models
    
    [ Upstream commit c95b323dcd3598dd7ef5005d6723c1ba3b801093 ]
    
    MC4_MISC thresholding is not supported on all family 0x15 processors,
    hence skip the x86_model check when applying the quirk.
    
     [ bp: massage commit message. ]
    
    Signed-off-by: Shirish S <shirish.s@amd.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Vishal Verma <vishal.l.verma@intel.com>
    Cc: x86-ml <x86@kernel.org>
    Link: https://lkml.kernel.org/r/1547106849-3476-2-git-send-email-shirish.s@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f27b638437dadd059ea182c4fb13e310241758d5
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Mon Nov 19 20:48:19 2018 +0800

    e100: Fix passing zero to 'PTR_ERR' warning in e100_load_ucode_wait
    
    [ Upstream commit cd0d465bb697a9c7bf66a9fe940f7981232f1676 ]
    
    Fix a static code checker warning:
    drivers/net/ethernet/intel/e100.c:1349
     e100_load_ucode_wait() warn: passing zero to 'PTR_ERR'
    
    Signed-off-by: YueHaibing <yuehaibing@huawei.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 <sashal@kernel.org>

commit 20e106dfb16f1207308f832f0b2f7c09f4212ea2
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Thu Dec 20 17:23:44 2018 +0100

    drbd: Change drbd_request_detach_interruptible's return type to int
    
    [ Upstream commit 5816a0932b4fd74257b8cc5785bc8067186a8723 ]
    
    Clang warns when an implicit conversion is done between enumerated
    types:
    
    drivers/block/drbd/drbd_state.c:708:8: warning: implicit conversion from
    enumeration type 'enum drbd_ret_code' to different enumeration type
    'enum drbd_state_rv' [-Wenum-conversion]
                    rv = ERR_INTR;
                       ~ ^~~~~~~~
    
    drbd_request_detach_interruptible's only call site is in the return
    statement of adm_detach, which returns an int. Change the return type of
    drbd_request_detach_interruptible to match, silencing Clang's warning.
    
    Reported-by: Nick Desaulniers <ndesaulniers@google.com>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cbe87667e31662c57c530ad3c50d2ded9157e9bf
Author: James Smart <jsmart2021@gmail.com>
Date:   Thu Nov 29 16:09:37 2018 -0800

    scsi: lpfc: Correct code setting non existent bits in sli4 ABORT WQE
    
    [ Upstream commit 1c36833d82ff24d0d54215fd956e7cc30fffce54 ]
    
    Driver is setting bits in word 10 of the SLI4 ABORT WQE (the wqid).  The
    field was a carry over from a prior SLI revision. The field does not exist
    in SLI4, and the action may result in an overlap with future definition of
    the WQE.
    
    Remove the setting of WQID in the ABORT WQE.
    
    Also cleaned up WQE field settings - initialize to zero, don't bother to
    set fields to zero.
    
    Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3bfe0a6aa251c88aa439e8a09fc68a858d6eecc9
Author: James Smart <jsmart2021@gmail.com>
Date:   Thu Nov 29 16:09:33 2018 -0800

    scsi: lpfc: Cap NPIV vports to 256
    
    [ Upstream commit 8b47ae69e049ae0b3373859d901f0334322f9fe9 ]
    
    Depending on the chipset, the number of NPIV vports may vary and be in
    excess of what most switches support (256). To avoid confusion with the
    users, limit the reported NPIV vports to 256.
    
    Additionally correct the 16G adapter which is reporting a bogus NPIV vport
    number if the link is down.
    
    Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0f3c518936e275eeb4a5608a171350bbd0b74ae5
Author: H. Nikolaus Schaller <hns@goldelico.com>
Date:   Thu Nov 7 11:30:39 2019 +0100

    omap: pdata-quirks: remove openpandora quirks for mmc3 and wl1251
    
    [ Upstream commit 2398c41d64321e62af54424fd399964f3d48cdc2 ]
    
    With a wl1251 child node of mmc3 in the device tree decoded
    in omap_hsmmc.c to handle special wl1251 initialization, we do
    no longer need to instantiate the mmc3 through pdata quirks.
    
    We also can remove the wlan regulator and reset/interrupt definitions
    and do them through device tree.
    
    Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel")
    Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
    Cc: <stable@vger.kernel.org> # v4.7+
    Acked-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 96dd9ce3d01630998200162864f256de495057cd
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Mon Oct 7 16:55:10 2019 +0900

    phy: renesas: rcar-gen3-usb2: Fix sysfs interface of "role"
    
    [ Upstream commit 4bd5ead82d4b877ebe41daf95f28cda53205b039 ]
    
    Since the role_store() uses strncmp(), it's possible to refer
    out-of-memory if the sysfs data size is smaller than strlen("host").
    This patch fixes it by using sysfs_streq() instead of strncmp().
    
    Reported-by: Pavel Machek <pavel@denx.de>
    Fixes: 9bb86777fb71 ("phy: rcar-gen3-usb2: add sysfs for usb role swap")
    Cc: <stable@vger.kernel.org> # v4.10+
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Acked-by: Pavel Machek <pavel@denx.de>
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fe09dc3e5168d8b967a9e6fc66cfb421cacc6f82
Author: Nuno Sá <nuno.sa@analog.com>
Date:   Mon Oct 28 17:33:49 2019 +0100

    iio: adis16480: Add debugfs_reg_access entry
    
    [ Upstream commit 4c35b7a51e2f291471f7221d112c6a45c63e83bc ]
    
    The driver is defining debugfs entries by calling
    `adis16480_debugfs_init()`. However, those entries are attached to the
    iio_dev debugfs entry which won't exist if no debugfs_reg_access
    callback is provided.
    
    Fixes: 2f3abe6cbb6c ("iio:imu: Add support for the ADIS16480 and similar IMUs")
    Signed-off-by: Nuno Sá <nuno.sa@analog.com>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d12f592f95c956813e513a9f443f1375f5c73b28
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Wed Dec 11 16:20:07 2019 +0200

    xhci: make sure interrupts are restored to correct state
    
    [ Upstream commit bd82873f23c9a6ad834348f8b83f3b6a5bca2c65 ]
    
    spin_unlock_irqrestore() might be called with stale flags after
    reading port status, possibly restoring interrupts to a incorrect
    state.
    
    If a usb2 port just finished resuming while the port status is read
    the spin lock will be temporary released and re-acquired in a separate
    function. The flags parameter is passed as value instead of a pointer,
    not updating flags properly before the final spin_unlock_irqrestore()
    is called.
    
    Cc: <stable@vger.kernel.org> # v3.12+
    Fixes: 8b3d45705e54 ("usb: Fix xHCI host issues on remote wakeup.")
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20191211142007.8847-7-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1fbaac5f1827570565dd0373190e75bde878c854
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Wed Dec 11 16:20:02 2019 +0200

    xhci: Fix memory leak in xhci_add_in_port()
    
    [ Upstream commit ce91f1a43b37463f517155bdfbd525eb43adbd1a ]
    
    When xHCI is part of Alpine or Titan Ridge Thunderbolt controller and
    the xHCI device is hot-removed as a result of unplugging a dock for
    example, the driver leaks memory it allocates for xhci->usb3_rhub.psi
    and xhci->usb2_rhub.psi in xhci_add_in_port() as reported by kmemleak:
    
    unreferenced object 0xffff922c24ef42f0 (size 16):
      comm "kworker/u16:2", pid 178, jiffies 4294711640 (age 956.620s)
      hex dump (first 16 bytes):
        21 00 0c 00 12 00 dc 05 23 00 e0 01 00 00 00 00  !.......#.......
      backtrace:
        [<000000007ac80914>] xhci_mem_init+0xcf8/0xeb7
        [<0000000001b6d775>] xhci_init+0x7c/0x160
        [<00000000db443fe3>] xhci_gen_setup+0x214/0x340
        [<00000000fdffd320>] xhci_pci_setup+0x48/0x110
        [<00000000541e1e03>] usb_add_hcd.cold+0x265/0x747
        [<00000000ca47a56b>] usb_hcd_pci_probe+0x219/0x3b4
        [<0000000021043861>] xhci_pci_probe+0x24/0x1c0
        [<00000000b9231f25>] local_pci_probe+0x3d/0x70
        [<000000006385c9d7>] pci_device_probe+0xd0/0x150
        [<0000000070241068>] really_probe+0xf5/0x3c0
        [<0000000061f35c0a>] driver_probe_device+0x58/0x100
        [<000000009da11198>] bus_for_each_drv+0x79/0xc0
        [<000000009ce45f69>] __device_attach+0xda/0x160
        [<00000000df201aaf>] pci_bus_add_device+0x46/0x70
        [<0000000088a1bc48>] pci_bus_add_devices+0x27/0x60
        [<00000000ad9ee708>] pci_bus_add_devices+0x52/0x60
    unreferenced object 0xffff922c24ef3318 (size 8):
      comm "kworker/u16:2", pid 178, jiffies 4294711640 (age 956.620s)
      hex dump (first 8 bytes):
        34 01 05 00 35 41 0a 00                          4...5A..
      backtrace:
        [<000000007ac80914>] xhci_mem_init+0xcf8/0xeb7
        [<0000000001b6d775>] xhci_init+0x7c/0x160
        [<00000000db443fe3>] xhci_gen_setup+0x214/0x340
        [<00000000fdffd320>] xhci_pci_setup+0x48/0x110
        [<00000000541e1e03>] usb_add_hcd.cold+0x265/0x747
        [<00000000ca47a56b>] usb_hcd_pci_probe+0x219/0x3b4
        [<0000000021043861>] xhci_pci_probe+0x24/0x1c0
        [<00000000b9231f25>] local_pci_probe+0x3d/0x70
        [<000000006385c9d7>] pci_device_probe+0xd0/0x150
        [<0000000070241068>] really_probe+0xf5/0x3c0
        [<0000000061f35c0a>] driver_probe_device+0x58/0x100
        [<000000009da11198>] bus_for_each_drv+0x79/0xc0
        [<000000009ce45f69>] __device_attach+0xda/0x160
        [<00000000df201aaf>] pci_bus_add_device+0x46/0x70
        [<0000000088a1bc48>] pci_bus_add_devices+0x27/0x60
        [<00000000ad9ee708>] pci_bus_add_devices+0x52/0x60
    
    Fix this by calling kfree() for the both psi objects in
    xhci_mem_cleanup().
    
    Cc: <stable@vger.kernel.org> # 4.4+
    Fixes: 47189098f8be ("xhci: parse xhci protocol speed ID list for usb 3.1 usage")
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20191211142007.8847-2-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4b4a166ce8b96199c9812af094a631e8ad2d8eb7
Author: Himanshu Madhani <hmadhani@marvell.com>
Date:   Fri Aug 30 15:23:57 2019 -0700

    scsi: qla2xxx: Fix message indicating vectors used by driver
    
    [ Upstream commit da48b82425b8bf999fb9f7c220e967c4d661b5f8 ]
    
    This patch updates log message which indicates number of vectors used by
    the driver instead of displaying failure to get maximum requested
    vectors. Driver will always request maximum vectors during
    initialization. In the event driver is not able to get maximum requested
    vectors, it will adjust the allocated vectors. This is normal and does not
    imply failure in driver.
    
    Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
    Reviewed-by: Ewan D. Milne <emilne@redhat.com>
    Reviewed-by: Lee Duncan <lduncan@suse.com>
    Link: https://lore.kernel.org/r/20190830222402.23688-2-hmadhani@marvell.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 88a18e5f69e5cb1e072343585bd1ef5233ab1e49
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Thu Aug 8 20:01:52 2019 -0700

    scsi: qla2xxx: Always check the qla2x00_wait_for_hba_online() return value
    
    [ Upstream commit e6803efae5acd109fad9f2f07dab674563441a53 ]
    
    This patch fixes several Coverity complaints about not always checking
    the qla2x00_wait_for_hba_online() return value.
    
    Cc: Himanshu Madhani <hmadhani@marvell.com>
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Tested-by: Himanshu Madhani <hmadhani@marvell.com>
    Reviewed-by: Himanshu Madhani <hmadhani@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 940774ffa457e09aac3508a515285c1ccc3144a8
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Thu Aug 8 20:01:48 2019 -0700

    scsi: qla2xxx: Fix qla24xx_process_bidir_cmd()
    
    [ Upstream commit c29282c65d1cf54daeea63be46243d7f69d72f4d ]
    
    Set the r??_data_len variables before using these instead of after.
    
    This patch fixes the following Coverity complaint:
    
    const: At condition req_data_len != rsp_data_len, the value of req_data_len
    must be equal to 0.
    const: At condition req_data_len != rsp_data_len, the value of rsp_data_len
    must be equal to 0.
    dead_error_condition: The condition req_data_len != rsp_data_len cannot be
    true.
    
    Cc: Himanshu Madhani <hmadhani@marvell.com>
    Fixes: a9b6f722f62d ("[SCSI] qla2xxx: Implementation of bidirectional.") # v3.7.
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Tested-by: Himanshu Madhani <hmadhani@marvell.com>
    Reviewed-by: Himanshu Madhani <hmadhani@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a5caef09ebace942a12b0e17476ffb1ff2e9c784
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Thu Aug 8 20:01:40 2019 -0700

    scsi: qla2xxx: Fix session lookup in qlt_abort_work()
    
    [ Upstream commit ac452b8e79320c9e90c78edf32ba2d42431e4daf ]
    
    Pass the correct session ID to find_sess_by_s_id() instead of passing an
    uninitialized variable.
    
    Cc: Himanshu Madhani <hmadhani@marvell.com>
    Fixes: 2d70c103fd2a ("[SCSI] qla2xxx: Add LLD target-mode infrastructure for >= 24xx series") # v3.5.
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Tested-by: Himanshu Madhani <hmadhani@marvell.com>
    Reviewed-by: Himanshu Madhani <hmadhani@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 890140f2d4b3e111c99f3d97ca3c165db806f76c
Author: Himanshu Madhani <hmadhani@marvell.com>
Date:   Fri Jul 26 09:07:26 2019 -0700

    scsi: qla2xxx: Fix DMA unmap leak
    
    [ Upstream commit 5d328de64d89400dcf9911125844d8adc0db697f ]
    
    With debug kernel we see following wanings indicating memory leak.
    
    [28809.523959] WARNING: CPU: 3 PID: 6790 at lib/dma-debug.c:978
    dma_debug_device_change+0x166/0x1d0
    [28809.523964] pci 0000:0c:00.6: DMA-API: device driver has pending DMA
    allocations while released from device [count=5]
    [28809.523964] One of leaked entries details: [device
    address=0x00000002aefe4000] [size=8208 bytes] [mapped with DMA_BIDIRECTIONAL]
    [mapped as coherent]
    
    Fix this by unmapping DMA memory.
    
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f0297a3cb3eb6d271c052962e094392ba9c86d4d
Author: Steffen Maier <maier@linux.ibm.com>
Date:   Fri Oct 25 18:12:53 2019 +0200

    scsi: zfcp: trace channel log even for FCP command responses
    
    [ Upstream commit 100843f176109af94600e500da0428e21030ca7f ]
    
    While v2.6.26 commit b75db73159cc ("[SCSI] zfcp: Add qtcb dump to hba debug
    trace") is right that we don't want to flood the (payload) trace ring
    buffer, we don't trace successful FCP command responses by default.  So we
    can include the channel log for problem determination with failed responses
    of any FSF request type.
    
    Fixes: b75db73159cc ("[SCSI] zfcp: Add qtcb dump to hba debug trace")
    Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
    Cc: <stable@vger.kernel.org> #2.6.38+
    Link: https://lore.kernel.org/r/e37597b5c4ae123aaa85fd86c23a9f71e994e4a9.1572018132.git.bblock@linux.ibm.com
    Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
    Signed-off-by: Steffen Maier <maier@linux.ibm.com>
    Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9fb95b97ee1492d9e0d3e3b911d39b741f394acd
Author: Ming Lei <ming.lei@redhat.com>
Date:   Sat Dec 1 00:38:18 2018 +0800

    block: fix single range discard merge
    
    commit 2a5cf35cd6c56b2924bce103413ad3381bdc31fa upstream.
    
    There are actually two kinds of discard merge:
    
    - one is the normal discard merge, just like normal read/write request,
    and call it single-range discard
    
    - another is the multi-range discard, queue_max_discard_segments(rq->q) > 1
    
    For the former case, queue_max_discard_segments(rq->q) is 1, and we
    should handle this kind of discard merge like the normal read/write
    request.
    
    This patch fixes the following kernel panic issue[1], which is caused by
    not removing the single-range discard request from elevator queue.
    
    Guangwu has one raid discard test case, in which this issue is a bit
    easier to trigger, and I verified that this patch can fix the kernel
    panic issue in Guangwu's test case.
    
    [1] kernel panic log from Jens's report
    
     BUG: unable to handle kernel NULL pointer dereference at 0000000000000148
     PGD 0 P4D 0.
     Oops: 0000 [#1] SMP PTI
     CPU: 37 PID: 763 Comm: kworker/37:1H Not tainted \
    4.20.0-rc3-00649-ge64d9a554a91-dirty #14  Hardware name: Wiwynn \
    Leopard-Orv2/Leopard-DDR BW, BIOS LBM08   03/03/2017       Workqueue: kblockd \
    blk_mq_run_work_fn                                            RIP: \
    0010:blk_mq_get_driver_tag+0x81/0x120                                       Code: 24 \
    10 48 89 7c 24 20 74 21 83 fa ff 0f 95 c0 48 8b 4c 24 28 65 48 33 0c 25 28 00 00 00 \
    0f 85 96 00 00 00 48 83 c4 30 5b 5d c3 <48> 8b 87 48 01 00 00 8b 40 04 39 43 20 72 37 \
    f6 87 b0 00 00 00 02  RSP: 0018:ffffc90004aabd30 EFLAGS: 00010246                     \
      RAX: 0000000000000003 RBX: ffff888465ea1300 RCX: ffffc90004aabde8
     RDX: 00000000ffffffff RSI: ffffc90004aabde8 RDI: 0000000000000000
     RBP: 0000000000000000 R08: ffff888465ea1348 R09: 0000000000000000
     R10: 0000000000001000 R11: 00000000ffffffff R12: ffff888465ea1300
     R13: 0000000000000000 R14: ffff888465ea1348 R15: ffff888465d10000
     FS:  0000000000000000(0000) GS:ffff88846f9c0000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000000000000148 CR3: 000000000220a003 CR4: 00000000003606e0
     DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
     DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
     Call Trace:
      blk_mq_dispatch_rq_list+0xec/0x480
      ? elv_rb_del+0x11/0x30
      blk_mq_do_dispatch_sched+0x6e/0xf0
      blk_mq_sched_dispatch_requests+0xfa/0x170
      __blk_mq_run_hw_queue+0x5f/0xe0
      process_one_work+0x154/0x350
      worker_thread+0x46/0x3c0
      kthread+0xf5/0x130
      ? process_one_work+0x350/0x350
      ? kthread_destroy_worker+0x50/0x50
      ret_from_fork+0x1f/0x30
     Modules linked in: sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel \
    kvm switchtec irqbypass iTCO_wdt iTCO_vendor_support efivars cdc_ether usbnet mii \
    cdc_acm i2c_i801 lpc_ich mfd_core ipmi_si ipmi_devintf ipmi_msghandler acpi_cpufreq \
    button sch_fq_codel nfsd nfs_acl lockd grace auth_rpcgss oid_registry sunrpc nvme \
    nvme_core fuse sg loop efivarfs autofs4  CR2: 0000000000000148                        \
    
     ---[ end trace 340a1fb996df1b9b ]---
     RIP: 0010:blk_mq_get_driver_tag+0x81/0x120
     Code: 24 10 48 89 7c 24 20 74 21 83 fa ff 0f 95 c0 48 8b 4c 24 28 65 48 33 0c 25 28 \
    00 00 00 0f 85 96 00 00 00 48 83 c4 30 5b 5d c3 <48> 8b 87 48 01 00 00 8b 40 04 39 43 \
    20 72 37 f6 87 b0 00 00 00 02
    
    Fixes: 445251d0f4d329a ("blk-mq: fix discard merge with scheduler attached")
    Reported-by: Jens Axboe <axboe@kernel.dk>
    Cc: Guangwu Zhang <guazhang@redhat.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Jianchao Wang <jianchao.w.wang@oracle.com>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Cc: Andre Tomt <andre@tomt.net>
    Cc: Jack Wang <jack.wang.usish@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f2e7e222144061d10e777311f327af7b73653f8
Author: Jeff Mahoney <jeffm@suse.com>
Date:   Thu Oct 24 10:31:27 2019 -0400

    reiserfs: fix extended attributes on the root directory
    
    commit 60e4cf67a582d64f07713eda5fcc8ccdaf7833e6 upstream.
    
    Since commit d0a5b995a308 (vfs: Add IOP_XATTR inode operations flag)
    extended attributes haven't worked on the root directory in reiserfs.
    
    This is due to reiserfs conditionally setting the sb->s_xattrs handler
    array depending on whether it located or create the internal privroot
    directory.  It necessarily does this after the root inode is already
    read in.  The IOP_XATTR flag is set during inode initialization, so
    it never gets set on the root directory.
    
    This commit unconditionally assigns sb->s_xattrs and clears IOP_XATTR on
    internal inodes.  The old return values due to the conditional assignment
    are handled via open_xa_root, which now returns EOPNOTSUPP as the VFS
    would have done.
    
    Link: https://lore.kernel.org/r/20191024143127.17509-1-jeffm@suse.com
    CC: stable@vger.kernel.org
    Fixes: d0a5b995a308 ("vfs: Add IOP_XATTR inode operations flag")
    Signed-off-by: Jeff Mahoney <jeffm@suse.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c21619f86370aed2c8fb93b485ce082b1e4d646
Author: Jan Kara <jack@suse.cz>
Date:   Tue Nov 5 17:44:12 2019 +0100

    ext4: Fix credit estimate for final inode freeing
    
    commit 65db869c754e7c271691dd5feabf884347e694f5 upstream.
    
    Estimate for the number of credits needed for final freeing of inode in
    ext4_evict_inode() was to small. We may modify 4 blocks (inode & sb for
    orphan deletion, bitmap & group descriptor for inode freeing) and not
    just 3.
    
    [ Fixed minor whitespace nit. -- TYT ]
    
    Fixes: e50e5129f384 ("ext4: xattr-in-inode support")
    CC: stable@vger.kernel.org
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20191105164437.32602-6-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17da23ef719d36495b60372d552933dedca4baba
Author: Dmitry Monakhov <dmtrmonakhov@yandex-team.ru>
Date:   Thu Oct 31 10:39:19 2019 +0000

    quota: fix livelock in dquot_writeback_dquots
    
    commit 6ff33d99fc5c96797103b48b7b0902c296f09c05 upstream.
    
    Write only quotas which are dirty at entry.
    
    XFSTEST: https://github.com/dmonakhov/xfstests/commit/b10ad23566a5bf75832a6f500e1236084083cddc
    
    Link: https://lore.kernel.org/r/20191031103920.3919-1-dmonakhov@openvz.org
    CC: stable@vger.kernel.org
    Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Signed-off-by: Dmitry Monakhov <dmtrmonakhov@yandex-team.ru>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4845e598a438c5a168084adbfe6312b5da4a2f7
Author: Chengguang Xu <cgxu519@mykernel.net>
Date:   Tue Nov 5 12:51:00 2019 +0800

    ext2: check err when partial != NULL
    
    commit e705f4b8aa27a59f8933e8f384e9752f052c469c upstream.
    
    Check err when partial == NULL is meaningless because
    partial == NULL means getting branch successfully without
    error.
    
    CC: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20191105045100.7104-1-cgxu519@mykernel.net
    Signed-off-by: Chengguang Xu <cgxu519@mykernel.net>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f780a35182bf0c37668f734d2bbf8e5dd63d8713
Author: Dmitry Monakhov <dmtrmonakhov@yandex-team.ru>
Date:   Thu Oct 31 10:39:20 2019 +0000

    quota: Check that quota is not dirty before release
    
    commit df4bb5d128e2c44848aeb36b7ceceba3ac85080d upstream.
    
    There is a race window where quota was redirted once we drop dq_list_lock inside dqput(),
    but before we grab dquot->dq_lock inside dquot_release()
    
    TASK1                                                       TASK2 (chowner)
    ->dqput()
      we_slept:
        spin_lock(&dq_list_lock)
        if (dquot_dirty(dquot)) {
              spin_unlock(&dq_list_lock);
              dquot->dq_sb->dq_op->write_dquot(dquot);
              goto we_slept
        if (test_bit(DQ_ACTIVE_B, &dquot->dq_flags)) {
              spin_unlock(&dq_list_lock);
              dquot->dq_sb->dq_op->release_dquot(dquot);
                                                                dqget()
                                                                mark_dquot_dirty()
                                                                dqput()
              goto we_slept;
            }
    So dquot dirty quota will be released by TASK1, but on next we_sleept loop
    we detect this and call ->write_dquot() for it.
    XFSTEST: https://github.com/dmonakhov/xfstests/commit/440a80d4cbb39e9234df4d7240aee1d551c36107
    
    Link: https://lore.kernel.org/r/20191031103920.3919-2-dmonakhov@openvz.org
    CC: stable@vger.kernel.org
    Signed-off-by: Dmitry Monakhov <dmtrmonakhov@yandex-team.ru>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 772098e8b6999656b9b28d78f52f80b224556c06
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu Sep 19 16:28:53 2019 +0300

    video/hdmi: Fix AVI bar unpack
    
    commit 6039f37dd6b76641198e290f26b31c475248f567 upstream.
    
    The bar values are little endian, not big endian. The pack
    function did it right but the unpack got it wrong. Fix it.
    
    Cc: stable@vger.kernel.org
    Cc: linux-media@vger.kernel.org
    Cc: Martin Bugge <marbugge@cisco.com>
    Cc: Hans Verkuil <hans.verkuil@cisco.com>
    Cc: Thierry Reding <treding@nvidia.com>
    Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Fixes: 2c676f378edb ("[media] hdmi: added unpack and logging functions for InfoFrames")
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190919132853.30954-1-ville.syrjala@linux.intel.com
    Reviewed-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a4c1a8952b19e2d6c39cce5de13c157cd0b8f7c
Author: Cédric Le Goater <clg@kaod.org>
Date:   Tue Dec 3 17:36:42 2019 +0100

    powerpc/xive: Skip ioremap() of ESB pages for LSI interrupts
    
    commit b67a95f2abff0c34e5667c15ab8900de73d8d087 upstream.
    
    The PCI INTx interrupts and other LSI interrupts are handled differently
    under a sPAPR platform. When the interrupt source characteristics are
    queried, the hypervisor returns an H_INT_ESB flag to inform the OS
    that it should be using the H_INT_ESB hcall for interrupt management
    and not loads and stores on the interrupt ESB pages.
    
    A default -1 value is returned for the addresses of the ESB pages. The
    driver ignores this condition today and performs a bogus IO mapping.
    Recent changes and the DEBUG_VM configuration option make the bug
    visible with :
    
      kernel BUG at arch/powerpc/include/asm/book3s/64/pgtable.h:612!
      Oops: Exception in kernel mode, sig: 5 [#1]
      LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=1024 NUMA pSeries
      Modules linked in:
      CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.0-0.rc6.git0.1.fc32.ppc64le #1
      NIP:  c000000000f63294 LR: c000000000f62e44 CTR: 0000000000000000
      REGS: c0000000fa45f0d0 TRAP: 0700   Not tainted  (5.4.0-0.rc6.git0.1.fc32.ppc64le)
      ...
      NIP ioremap_page_range+0x4c4/0x6e0
      LR  ioremap_page_range+0x74/0x6e0
      Call Trace:
        ioremap_page_range+0x74/0x6e0 (unreliable)
        do_ioremap+0x8c/0x120
        __ioremap_caller+0x128/0x140
        ioremap+0x30/0x50
        xive_spapr_populate_irq_data+0x170/0x260
        xive_irq_domain_map+0x8c/0x170
        irq_domain_associate+0xb4/0x2d0
        irq_create_mapping+0x1e0/0x3b0
        irq_create_fwspec_mapping+0x27c/0x3e0
        irq_create_of_mapping+0x98/0xb0
        of_irq_parse_and_map_pci+0x168/0x230
        pcibios_setup_device+0x88/0x250
        pcibios_setup_bus_devices+0x54/0x100
        __of_scan_bus+0x160/0x310
        pcibios_scan_phb+0x330/0x390
        pcibios_init+0x8c/0x128
        do_one_initcall+0x60/0x2c0
        kernel_init_freeable+0x290/0x378
        kernel_init+0x2c/0x148
        ret_from_kernel_thread+0x5c/0x80
    
    Fixes: bed81ee181dd ("powerpc/xive: introduce H_INT_ESB hcall")
    Cc: stable@vger.kernel.org # v4.14+
    Signed-off-by: Cédric Le Goater <clg@kaod.org>
    Tested-by: Daniel Axtens <dja@axtens.net>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20191203163642.2428-1-clg@kaod.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0cea5de4dbad9f821efaab09699ac36950719933
Author: Alastair D'Silva <alastair@d-silva.org>
Date:   Mon Nov 4 13:32:53 2019 +1100

    powerpc: Allow flush_icache_range to work across ranges >4GB
    
    commit 29430fae82073d39b1b881a3cd507416a56a363f upstream.
    
    When calling flush_icache_range with a size >4GB, we were masking
    off the upper 32 bits, so we would incorrectly flush a range smaller
    than intended.
    
    This patch replaces the 32 bit shifts with 64 bit ones, so that
    the full size is accounted for.
    
    Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20191104023305.9581-2-alastair@au1.ibm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9aeaa898f580ed9a20de0235430149a26da65d16
Author: Cédric Le Goater <clg@kaod.org>
Date:   Thu Oct 31 07:31:00 2019 +0100

    powerpc/xive: Prevent page fault issues in the machine crash handler
    
    commit 1ca3dec2b2dff9d286ce6cd64108bda0e98f9710 upstream.
    
    When the machine crash handler is invoked, all interrupts are masked
    but interrupts which have not been started yet do not have an ESB page
    mapped in the Linux address space. This crashes the 'crash kexec'
    sequence on sPAPR guests.
    
    To fix, force the mapping of the ESB page when an interrupt is being
    mapped in the Linux IRQ number space. This is done by setting the
    initial state of the interrupt to OFF which is not necessarily the
    case on PowerNV.
    
    Fixes: 243e25112d06 ("powerpc/xive: Native exploitation of the XIVE interrupt controller")
    Cc: stable@vger.kernel.org # v4.12+
    Signed-off-by: Cédric Le Goater <clg@kaod.org>
    Reviewed-by: Greg Kurz <groug@kaod.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20191031063100.3864-1-clg@kaod.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ff419d70d9f5bd65b3c59334acdc4e01466069b
Author: Alastair D'Silva <alastair@d-silva.org>
Date:   Mon Nov 4 13:32:54 2019 +1100

    powerpc: Allow 64bit VDSO __kernel_sync_dicache to work across ranges >4GB
    
    commit f9ec11165301982585e5e5f606739b5bae5331f3 upstream.
    
    When calling __kernel_sync_dicache with a size >4GB, we were masking
    off the upper 32 bits, so we would incorrectly flush a range smaller
    than intended.
    
    This patch replaces the 32 bit shifts with 64 bit ones, so that
    the full size is accounted for.
    
    Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20191104023305.9581-3-alastair@au1.ibm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a963f7589ba8f2af0089608e414059196f92dd7
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Nov 8 21:34:30 2019 +0100

    ppdev: fix PPGETTIME/PPSETTIME ioctls
    
    commit 998174042da229e2cf5841f574aba4a743e69650 upstream.
    
    Going through the uses of timeval in the user space API,
    I noticed two bugs in ppdev that were introduced in the y2038
    conversion:
    
    * The range check was accidentally moved from ppsettime to
      ppgettime
    
    * On sparc64, the microseconds are in the other half of the
      64-bit word.
    
    Fix both, and mark the fix for stable backports.
    
    Cc: stable@vger.kernel.org
    Fixes: 3b9ab374a1e6 ("ppdev: convert to y2038 safe")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20191108203435.112759-8-arnd@arndb.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 822e1ba45f4879184fc17b4a0246da71d771f7e3
Author: Jarkko Nikula <jarkko.nikula@bitmer.com>
Date:   Sat Nov 16 17:16:51 2019 +0200

    ARM: dts: omap3-tao3530: Fix incorrect MMC card detection GPIO polarity
    
    commit 287897f9aaa2ad1c923d9875914f57c4dc9159c8 upstream.
    
    The MMC card detection GPIO polarity is active low on TAO3530, like in many
    other similar boards. Now the card is not detected and it is unable to
    mount rootfs from an SD card.
    
    Fix this by using the correct polarity.
    
    This incorrect polarity was defined already in the commit 30d95c6d7092
    ("ARM: dts: omap3: Add Technexion TAO3530 SOM omap3-tao3530.dtsi") in v3.18
    kernel and later changed to use defined GPIO constants in v4.4 kernel by
    the commit 3a637e008e54 ("ARM: dts: Use defined GPIO constants in flags
    cell for OMAP2+ boards").
    
    While the latter commit did not introduce the issue I'm marking it with
    Fixes tag due the v4.4 kernels still being maintained.
    
    Fixes: 3a637e008e54 ("ARM: dts: Use defined GPIO constants in flags cell for OMAP2+ boards")
    Cc: linux-stable <stable@vger.kernel.org> # 4.4+
    Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c8838dba5ad776273f8472c2e760dda1973f0e42
Author: H. Nikolaus Schaller <hns@goldelico.com>
Date:   Thu Nov 7 11:30:37 2019 +0100

    mmc: host: omap_hsmmc: add code for special init of wl1251 to get rid of pandora_wl1251_init_card
    
    commit f6498b922e57aecbe3b7fa30a308d9d586c0c369 upstream.
    
    Pandora_wl1251_init_card was used to do special pdata based
    setup of the sdio mmc interface. This does no longer work with
    v4.7 and later. A fix requires a device tree based mmc3 setup.
    
    Therefore we move the special setup to omap_hsmmc.c instead
    of calling some pdata supplied init_card function.
    
    The new code checks for a DT child node compatible to wl1251
    so it will not affect other MMC3 use cases.
    
    Generally, this code was and still is a hack and should be
    moved to mmc core to e.g. read such properties from optional
    DT child nodes.
    
    Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel")
    Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
    Cc: <stable@vger.kernel.org> # v4.7+
    [Ulf: Fixed up some checkpatch complaints]
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05ee4d44389663446ba94af894d0df183f25d67c
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Mon Aug 5 18:27:09 2019 +0200

    pinctrl: samsung: Fix device node refcount leaks in S3C64xx wakeup controller init
    
    commit 7f028caadf6c37580d0f59c6c094ed09afc04062 upstream.
    
    In s3c64xx_eint_eint0_init() the for_each_child_of_node() loop is used
    with a break to find a matching child node.  Although each iteration of
    for_each_child_of_node puts the previous node, but early exit from loop
    misses it.  This leads to leak of device node.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 61dd72613177 ("pinctrl: Add pinctrl-s3c64xx driver")
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3708cad610607c7b5f1d618940eb6742744385b2
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Mon Aug 5 18:27:10 2019 +0200

    pinctrl: samsung: Fix device node refcount leaks in init code
    
    commit a322b3377f4bac32aa25fb1acb9e7afbbbbd0137 upstream.
    
    Several functions use for_each_child_of_node() loop with a break to find
    a matching child node.  Although each iteration of
    for_each_child_of_node puts the previous node, but early exit from loop
    misses it.  This leads to leak of device node.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 9a2c1c3b91aa ("pinctrl: samsung: Allow grouping multiple pinmux/pinconf nodes")
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5958149d5eaac72e78304a7e3d501eb59b4ee7f
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Mon Aug 5 18:27:08 2019 +0200

    pinctrl: samsung: Fix device node refcount leaks in S3C24xx wakeup controller init
    
    commit 6fbbcb050802d6ea109f387e961b1dbcc3a80c96 upstream.
    
    In s3c24xx_eint_init() the for_each_child_of_node() loop is used with a
    break to find a matching child node.  Although each iteration of
    for_each_child_of_node puts the previous node, but early exit from loop
    misses it.  This leads to leak of device node.
    
    Cc: <stable@vger.kernel.org>
    Fixes: af99a7507469 ("pinctrl: Add pinctrl-s3c24xx driver")
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d892c97851235087932113d7fefd818484ceba5a
Author: Nishka Dasgupta <nishkadg.linux@gmail.com>
Date:   Sun Aug 4 21:32:00 2019 +0530

    pinctrl: samsung: Add of_node_put() before return in error path
    
    commit 3d2557ab75d4c568c79eefa2e550e0d80348a6bd upstream.
    
    Each iteration of for_each_child_of_node puts the previous node, but in
    the case of a return from the middle of the loop, there is no put, thus
    causing a memory leak. Hence add an of_node_put before the return of
    exynos_eint_wkup_init() error path.
    Issue found with Coccinelle.
    
    Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
    Cc: <stable@vger.kernel.org>
    Fixes: 14c255d35b25 ("pinctrl: exynos: Add irq_chip instance for Exynos7 wakeup interrupts")
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 63d22de1f7aa3b8a588d53f3a5ca0f4fec1cc8af
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Wed Dec 4 02:54:27 2019 +0100

    ACPI: PM: Avoid attaching ACPI PM domain to certain devices
    
    commit b9ea0bae260f6aae546db224daa6ac1bd9d94b91 upstream.
    
    Certain ACPI-enumerated devices represented as platform devices in
    Linux, like fans, require special low-level power management handling
    implemented by their drivers that is not in agreement with the ACPI
    PM domain behavior.  That leads to problems with managing ACPI fans
    during system-wide suspend and resume.
    
    For this reason, make acpi_dev_pm_attach() skip the affected devices
    by adding a list of device IDs to avoid to it and putting the IDs of
    the affected devices into that list.
    
    Fixes: e5cc8ef31267 (ACPI / PM: Provide ACPI PM callback routines for subsystems)
    Reported-by: Zhang Rui <rui.zhang@intel.com>
    Tested-by: Todd Brandt <todd.e.brandt@linux.intel.com>
    Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a136f412dbac4718137a05f24d9bd6906e53301a
Author: Vamshi K Sthambamkadi <vamshi.k.sthambamkadi@gmail.com>
Date:   Thu Nov 28 15:58:29 2019 +0530

    ACPI: bus: Fix NULL pointer check in acpi_bus_get_private_data()
    
    commit 627ead724eff33673597216f5020b72118827de4 upstream.
    
    kmemleak reported backtrace:
        [<bbee0454>] kmem_cache_alloc_trace+0x128/0x260
        [<6677f215>] i2c_acpi_install_space_handler+0x4b/0xe0
        [<1180f4fc>] i2c_register_adapter+0x186/0x400
        [<6083baf7>] i2c_add_adapter+0x4e/0x70
        [<a3ddf966>] intel_gmbus_setup+0x1a2/0x2c0 [i915]
        [<84cb69ae>] i915_driver_probe+0x8d8/0x13a0 [i915]
        [<81911d4b>] i915_pci_probe+0x48/0x160 [i915]
        [<4b159af1>] pci_device_probe+0xdc/0x160
        [<b3c64704>] really_probe+0x1ee/0x450
        [<bc029f5a>] driver_probe_device+0x142/0x1b0
        [<d8829d20>] device_driver_attach+0x49/0x50
        [<de71f045>] __driver_attach+0xc9/0x150
        [<df33ac83>] bus_for_each_dev+0x56/0xa0
        [<80089bba>] driver_attach+0x19/0x20
        [<cc73f583>] bus_add_driver+0x177/0x220
        [<7b29d8c7>] driver_register+0x56/0xf0
    
    In i2c_acpi_remove_space_handler(), a leak occurs whenever the
    "data" parameter is initialized to 0 before being passed to
    acpi_bus_get_private_data().
    
    This is because the NULL pointer check in acpi_bus_get_private_data()
    (condition->if(!*data)) returns EINVAL and, in consequence, memory is
    never freed in i2c_acpi_remove_space_handler().
    
    Fix the NULL pointer check in acpi_bus_get_private_data() to follow
    the analogous check in acpi_get_data_full().
    
    Signed-off-by: Vamshi K Sthambamkadi <vamshi.k.sthambamkadi@gmail.com>
    [ rjw: Subject & changelog ]
    Cc: All applicable <stable@vger.kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c996bfa0802a7d69387efc27e16dacdaa4fa227
Author: Francesco Ruggeri <fruggeri@arista.com>
Date:   Tue Nov 19 21:47:27 2019 -0800

    ACPI: OSL: only free map once in osl.c
    
    commit 833a426cc471b6088011b3d67f1dc4e147614647 upstream.
    
    acpi_os_map_cleanup checks map->refcount outside of acpi_ioremap_lock
    before freeing the map. This creates a race condition the can result
    in the map being freed more than once.
    A panic can be caused by running
    
    for ((i=0; i<10; i++))
    do
            for ((j=0; j<100000; j++))
            do
                    cat /sys/firmware/acpi/tables/data/BERT >/dev/null
            done &
    done
    
    This patch makes sure that only the process that drops the reference
    to 0 does the freeing.
    
    Fixes: b7c1fadd6c2e ("ACPI: Do not use krefs under a mutex in osl.c")
    Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
    Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com>
    Cc: All applicable <stable@vger.kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6dd08f64d4aec82510820f9359b8e6d37ef61728
Author: John Hubbard <jhubbard@nvidia.com>
Date:   Wed Oct 30 22:21:59 2019 -0700

    cpufreq: powernv: fix stack bloat and hard limit on number of CPUs
    
    commit db0d32d84031188443e25edbd50a71a6e7ac5d1d upstream.
    
    The following build warning occurred on powerpc 64-bit builds:
    
    drivers/cpufreq/powernv-cpufreq.c: In function 'init_chip_info':
    drivers/cpufreq/powernv-cpufreq.c:1070:1: warning: the frame size of
    1040 bytes is larger than 1024 bytes [-Wframe-larger-than=]
    
    This is with a cross-compiler based on gcc 8.1.0, which I got from:
      https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/
    
    The warning is due to putting 1024 bytes on the stack:
    
        unsigned int chip[256];
    
    ...and it's also undesirable to have a hard limit on the number of
    CPUs here.
    
    Fix both problems by dynamically allocating based on num_possible_cpus,
    as recommended by Michael Ellerman.
    
    Fixes: 053819e0bf840 ("cpufreq: powernv: Handle throttling due to Pmax capping at chip level")
    Signed-off-by: John Hubbard <jhubbard@nvidia.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Cc: 4.10+ <stable@vger.kernel.org> # 4.10+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19c513e62cc6a8b7adb8b9a98c6289bceddbd692
Author: Leonard Crestez <leonard.crestez@nxp.com>
Date:   Tue Sep 24 10:52:23 2019 +0300

    PM / devfreq: Lock devfreq in trans_stat_show
    
    commit 2abb0d5268ae7b5ddf82099b1f8d5aa8414637d4 upstream.
    
    There is no locking in this sysfs show function so stats printing can
    race with a devfreq_update_status called as part of freq switching or
    with initialization.
    
    Also add an assert in devfreq_update_status to make it clear that lock
    must be held by caller.
    
    Fixes: 39688ce6facd ("PM / devfreq: account suspend/resume for stats")
    Cc: stable@vger.kernel.org
    Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
    Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
    Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 638327101f3e022ab4edf496f0cc8ee1c5e197e6
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Wed Nov 20 15:08:06 2019 +0200

    intel_th: pci: Add Tiger Lake CPU support
    
    commit 6e6c18bcb78c0dc0601ebe216bed12c844492d0c upstream.
    
    This adds support for the Trace Hub in Tiger Lake CPU.
    
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20191120130806.44028-4-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 735ef8110f629226d61f393e8254bef46e69d6c2
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Wed Nov 20 15:08:05 2019 +0200

    intel_th: pci: Add Ice Lake CPU support
    
    commit 6a1743422a7c0fda26764a544136cac13e5ae486 upstream.
    
    This adds support for the Trace Hub in Ice Lake CPU.
    
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20191120130806.44028-3-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 644d976f0b0032abc548a8a02e145988f33de47b
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Wed Nov 20 15:08:04 2019 +0200

    intel_th: Fix a double put_device() in error path
    
    commit 512592779a337feb5905d8fcf9498dbf33672d4a upstream.
    
    Commit a753bfcfdb1f ("intel_th: Make the switch allocate its subdevices")
    factored out intel_th_subdevice_alloc() from intel_th_populate(), but got
    the error path wrong, resulting in two instances of a double put_device()
    on a freshly initialized, but not 'added' device.
    
    Fix this by only doing one put_device() in the error path.
    
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Fixes: a753bfcfdb1f ("intel_th: Make the switch allocate its subdevices")
    Reported-by: Wen Yang <wenyang@linux.alibaba.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: stable@vger.kernel.org # v4.14+
    Link: https://lore.kernel.org/r/20191120130806.44028-2-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c4aca8b2a0dd01bfd4b06fc1b5513b158669c1f
Author: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Date:   Wed Oct 23 09:57:14 2019 +0800

    cpuidle: Do not unset the driver if it is there already
    
    commit 918c1fe9fbbe46fcf56837ff21f0ef96424e8b29 upstream.
    
    Fix __cpuidle_set_driver() to check if any of the CPUs in the mask has
    a driver different from drv already and, if so, return -EBUSY before
    updating any cpuidle_drivers per-CPU pointers.
    
    Fixes: 82467a5a885d ("cpuidle: simplify multiple driver support")
    Cc: 3.11+ <stable@vger.kernel.org> # 3.11+
    Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    [ rjw: Subject & changelog ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 958d6e4dc61f9bff9fffd04c9cab70772a8bf4ee
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Mon Sep 16 02:47:41 2019 -0300

    media: cec.h: CEC_OP_REC_FLAG_ values were swapped
    
    commit 806e0cdfee0b99efbb450f9f6e69deb7118602fc upstream.
    
    CEC_OP_REC_FLAG_NOT_USED is 0 and CEC_OP_REC_FLAG_USED is 1, not the
    other way around.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Reported-by: Jiunn Chang <c0d1n61at3@gmail.com>
    Cc: <stable@vger.kernel.org>      # for v4.10 and up
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62b9c0f96f80bee929027b0ac23b240c7464fe73
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Oct 10 10:13:32 2019 -0300

    media: radio: wl1273: fix interrupt masking on release
    
    commit 1091eb830627625dcf79958d99353c2391f41708 upstream.
    
    If a process is interrupted while accessing the radio device and the
    core lock is contended, release() could return early and fail to update
    the interrupt mask.
    
    Note that the return value of the v4l2 release file operation is
    ignored.
    
    Fixes: 87d1a50ce451 ("[media] V4L2: WL1273 FM Radio: TI WL1273 FM radio driver")
    Cc: stable <stable@vger.kernel.org>     # 2.6.38
    Cc: Matti Aaltonen <matti.j.aaltonen@nokia.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 721e7e7f3de9d00896ba902278ee4025a0ab58bb
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Oct 10 10:13:31 2019 -0300

    media: bdisp: fix memleak on release
    
    commit 11609a7e21f8cea42630350aa57662928fa4dc63 upstream.
    
    If a process is interrupted while accessing the video device and the
    device lock is contended, release() could return early and fail to free
    related resources.
    
    Note that the return value of the v4l2 release file operation is
    ignored.
    
    Fixes: 28ffeebbb7bd ("[media] bdisp: 2D blitter driver using v4l2 mem2mem framework")
    Cc: stable <stable@vger.kernel.org>     # 4.2
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ff3dd95600168b1695d818fcf4cd3a092adfc95
Author: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Date:   Wed Sep 11 19:42:23 2019 +0200

    s390/mm: properly clear _PAGE_NOEXEC bit when it is not supported
    
    commit ab874f22d35a8058d8fdee5f13eb69d8867efeae upstream.
    
    On older HW or under a hypervisor, w/o the instruction-execution-
    protection (IEP) facility, and also w/o EDAT-1, a translation-specification
    exception may be recognized when bit 55 of a pte is one (_PAGE_NOEXEC).
    
    The current code tries to prevent setting _PAGE_NOEXEC in such cases,
    by removing it within set_pte_at(). However, ptep_set_access_flags()
    will modify a pte directly, w/o using set_pte_at(). There is at least
    one scenario where this can result in an active pte with _PAGE_NOEXEC
    set, which would then lead to a panic due to a translation-specification
    exception (write to swapped out page):
    
    do_swap_page
      pte = mk_pte (with _PAGE_NOEXEC bit)
      set_pte_at   (will remove _PAGE_NOEXEC bit in page table, but keep it
                    in local variable pte)
      vmf->orig_pte = pte (pte still contains _PAGE_NOEXEC bit)
      do_wp_page
        wp_page_reuse
          entry = vmf->orig_pte (still with _PAGE_NOEXEC bit)
          ptep_set_access_flags (writes entry with _PAGE_NOEXEC bit)
    
    Fix this by clearing _PAGE_NOEXEC already in mk_pte_phys(), where the
    pgprot value is applied, so that no pte with _PAGE_NOEXEC will ever be
    visible, if it is not supported. The check in set_pte_at() can then also
    be removed.
    
    Cc: <stable@vger.kernel.org> # 4.11+
    Fixes: 57d7f939e7bd ("s390: add no-execute support")
    Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3557094f407c744e12b38fc4ddd5ee28b3ba1cbb
Author: Denis Efremov <efremov@linux.com>
Date:   Mon Sep 30 23:31:47 2019 +0300

    ar5523: check NULL before memcpy() in ar5523_cmd()
    
    commit 315cee426f87658a6799815845788fde965ddaad upstream.
    
    memcpy() call with "idata == NULL && ilen == 0" results in undefined
    behavior in ar5523_cmd(). For example, NULL is passed in callchain
    "ar5523_stat_work() -> ar5523_cmd_write() -> ar5523_cmd()". This patch
    adds ilen check before memcpy() call in ar5523_cmd() to prevent an
    undefined behavior.
    
    Cc: Pontus Fuchs <pontus.fuchs@gmail.com>
    Cc: Kalle Valo <kvalo@codeaurora.org>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: David Laight <David.Laight@ACULAB.COM>
    Cc: stable@vger.kernel.org
    Signed-off-by: Denis Efremov <efremov@linux.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc992138b37d85ff426f7f0c4fb90d0eb2ec7fff
Author: Aleksa Sarai <cyphar@cyphar.com>
Date:   Thu Oct 17 02:50:01 2019 +1100

    cgroup: pids: use atomic64_t for pids->limit
    
    commit a713af394cf382a30dd28a1015cbe572f1b9ca75 upstream.
    
    Because pids->limit can be changed concurrently (but we don't want to
    take a lock because it would be needlessly expensive), use atomic64_ts
    instead.
    
    Fixes: commit 49b786ea146f ("cgroup: implement the PIDs subsystem")
    Cc: stable@vger.kernel.org # v4.3+
    Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 365874a0eab5478d2d4f7b30e57bfc51dde7843c
Author: Ming Lei <ming.lei@redhat.com>
Date:   Sat Nov 2 16:02:15 2019 +0800

    blk-mq: avoid sysfs buffer overflow with too many CPU cores
    
    commit 8962842ca5abdcf98e22ab3b2b45a103f0408b95 upstream.
    
    It is reported that sysfs buffer overflow can be triggered if the system
    has too many CPU cores(>841 on 4K PAGE_SIZE) when showing CPUs of
    hctx via /sys/block/$DEV/mq/$N/cpu_list.
    
    Use snprintf to avoid the potential buffer overflow.
    
    This version doesn't change the attribute format, and simply stops
    showing CPU numbers if the buffer is going to overflow.
    
    Cc: stable@vger.kernel.org
    Fixes: 676141e48af7("blk-mq: don't dump CPU -> hw queue map on driver load")
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51fb33d0b2b1c9bb69e5612eae5b57837f767e71
Author: Pawel Harlozinski <pawel.harlozinski@linux.intel.com>
Date:   Tue Nov 12 14:02:36 2019 +0100

    ASoC: Jack: Fix NULL pointer dereference in snd_soc_jack_report
    
    commit 8f157d4ff039e03e2ed4cb602eeed2fd4687a58f upstream.
    
    Check for existance of jack before tracing.
    NULL pointer dereference has been reported by KASAN while unloading
    machine driver (snd_soc_cnl_rt274).
    
    Signed-off-by: Pawel Harlozinski <pawel.harlozinski@linux.intel.com>
    Link: https://lore.kernel.org/r/20191112130237.10141-1-pawel.harlozinski@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e0f33da9079a3e4e3acd5bdf163963b901d8484
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Sep 25 06:59:15 2019 -0700

    workqueue: Fix pwq ref leak in rescuer_thread()
    
    commit e66b39af00f426b3356b96433d620cb3367ba1ff upstream.
    
    008847f66c3 ("workqueue: allow rescuer thread to do more work.") made
    the rescuer worker requeue the pwq immediately if there may be more
    work items which need rescuing instead of waiting for the next mayday
    timer expiration.  Unfortunately, it doesn't check whether the pwq is
    already on the mayday list and unconditionally gets the ref and moves
    it onto the list.  This doesn't corrupt the list but creates an
    additional reference to the pwq.  It got queued twice but will only be
    removed once.
    
    This leak later can trigger pwq refcnt warning on workqueue
    destruction and prevent freeing of the workqueue.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: "Williams, Gerald S" <gerald.s.williams@intel.com>
    Cc: NeilBrown <neilb@suse.de>
    Cc: stable@vger.kernel.org # v3.19+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05905c2f2123a80dd8bdeee7f3178303ec97d08f
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Sep 18 18:43:40 2019 -0700

    workqueue: Fix spurious sanity check failures in destroy_workqueue()
    
    commit def98c84b6cdf2eeea19ec5736e90e316df5206b upstream.
    
    Before actually destrying a workqueue, destroy_workqueue() checks
    whether it's actually idle.  If it isn't, it prints out a bunch of
    warning messages and leaves the workqueue dangling.  It unfortunately
    has a couple issues.
    
    * Mayday list queueing increments pwq's refcnts which gets detected as
      busy and fails the sanity checks.  However, because mayday list
      queueing is asynchronous, this condition can happen without any
      actual work items left in the workqueue.
    
    * Sanity check failure leaves the sysfs interface behind too which can
      lead to init failure of newer instances of the workqueue.
    
    This patch fixes the above two by
    
    * If a workqueue has a rescuer, disable and kill the rescuer before
      sanity checks.  Disabling and killing is guaranteed to flush the
      existing mayday list.
    
    * Remove sysfs interface before sanity checks.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Marcin Pawlowski <mpawlowski@fb.com>
    Reported-by: "Williams, Gerald S" <gerald.s.williams@intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b3a529808ab7d3a936d0253d4b3195262af8b83
Author: Dmitry Fomichev <dmitry.fomichev@wdc.com>
Date:   Wed Nov 6 14:34:35 2019 -0800

    dm zoned: reduce overhead of backing device checks
    
    commit e7fad909b68aa37470d9f2d2731b5bec355ee5d6 upstream.
    
    Commit 75d66ffb48efb3 added backing device health checks and as a part
    of these checks, check_events() block ops template call is invoked in
    dm-zoned mapping path as well as in reclaim and flush path. Calling
    check_events() with ATA or SCSI backing devices introduces a blocking
    scsi_test_unit_ready() call being made in sd_check_events(). Even though
    the overhead of calling scsi_test_unit_ready() is small for ATA zoned
    devices, it is much larger for SCSI and it affects performance in a very
    negative way.
    
    Fix this performance regression by executing check_events() only in case
    of any I/O errors. The function dmz_bdev_is_dying() is modified to call
    only blk_queue_dying(), while calls to check_events() are made in a new
    helper function, dmz_check_bdev().
    
    Reported-by: zhangxiaoxu <zhangxiaoxu5@huawei.com>
    Fixes: 75d66ffb48efb3 ("dm zoned: properly handle backing device failure")
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Fomichev <dmitry.fomichev@wdc.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 53c2427d221918fb3cc3e71a08664bc9f9132e8c
Author: Sumit Garg <sumit.garg@linaro.org>
Date:   Mon Oct 14 17:32:45 2019 +0530

    hwrng: omap - Fix RNG wait loop timeout
    
    commit be867f987a4e1222114dd07a01838a17c26f3fff upstream.
    
    Existing RNG data read timeout is 200us but it doesn't cover EIP76 RNG
    data rate which takes approx. 700us to produce 16 bytes of output data
    as per testing results. So configure the timeout as 1000us to also take
    account of lack of udelay()'s reliability.
    
    Fixes: 383212425c92 ("hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a8791ab32a79c967a21c46ddcd9f6c5da59308b
Author: Joel Stanley <joel@jms.id.au>
Date:   Fri Nov 8 13:59:05 2019 +1030

    watchdog: aspeed: Fix clock behaviour for ast2600
    
    [ Upstream commit c04571251b3d842096f1597f5d4badb508be016d ]
    
    The ast2600 no longer uses bit 4 in the control register to indicate a
    1MHz clock (It now controls whether this watchdog is reset by a SOC
    reset). This means we do not want to set it. It also does not need to be
    set for the ast2500, as it is read-only on that SoC.
    
    The comment next to the clock rate selection wandered away from where it
    was set, so put it back next to the register setting it's describing.
    
    Fixes: b3528b487448 ("watchdog: aspeed: Add support for AST2600")
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Reviewed-by: Cédric Le Goater <clg@kaod.org>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20191108032905.22463-1-joel@jms.id.au
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8f873b8b1f78a329711b88972c1da53440d6d84a
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Sat Sep 21 09:00:31 2019 +0300

    md/raid0: Fix an error message in raid0_make_request()
    
    [ Upstream commit e3fc3f3d0943b126f76b8533960e4168412d9e5a ]
    
    The first argument to WARN() is supposed to be a condition.  The
    original code will just print the mdname() instead of the full warning
    message.
    
    Fixes: c84a1372df92 ("md/raid0: avoid RAID0 data corruption due to layout confusion.")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7dc871b7257a7afe05d1a6f145cbd6d69efb6800
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Oct 28 11:58:03 2019 +0100

    ALSA: hda - Fix pending unsol events at shutdown
    
    [ Upstream commit ca58f55108fee41d87c9123f85ad4863e5de7f45 ]
    
    This is an alternative fix attemp for the issue reported in the commit
    caa8422d01e9 ("ALSA: hda: Flush interrupts on disabling") that was
    reverted later due to regressions.  Instead of tweaking the hardware
    disablement order and the enforced irq flushing, do calling
    cancel_work_sync() of the unsol work early enough, and explicitly
    ignore the unsol events during the shutdown by checking the
    bus->shutdown flag.
    
    Fixes: caa8422d01e9 ("ALSA: hda: Flush interrupts on disabling")
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Link: https://lore.kernel.org/r/s5h1ruxt9cz.wl-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6890751cfea7d79d998b049647a8c49e2f288ed0
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Fri Dec 6 08:33:36 2019 +0200

    ovl: relax WARN_ON() on rename to self
    
    commit 6889ee5a53b8d969aa542047f5ac8acdc0e79a91 upstream.
    
    In ovl_rename(), if new upper is hardlinked to old upper underneath
    overlayfs before upper dirs are locked, user will get an ESTALE error
    and a WARN_ON will be printed.
    
    Changes to underlying layers while overlayfs is mounted may result in
    unexpected behavior, but it shouldn't crash the kernel and it shouldn't
    trigger WARN_ON() either, so relax this WARN_ON().
    
    Reported-by: syzbot+bb1836a212e69f8e201a@syzkaller.appspotmail.com
    Fixes: 804032fabb3b ("ovl: don't check rename to self")
    Cc: <stable@vger.kernel.org> # v4.9+
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02072c31e11badb90cc5000fe240ddd2b538570c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Dec 6 16:26:00 2019 +0100

    lib: raid6: fix awk build warnings
    
    commit 702600eef73033ddd4eafcefcbb6560f3e3a90f7 upstream.
    
    Newer versions of awk spit out these fun warnings:
            awk: ../lib/raid6/unroll.awk:16: warning: regexp escape sequence `\#' is not a known regexp operator
    
    As commit 700c1018b86d ("x86/insn: Fix awk regexp warnings") showed, it
    turns out that there are a number of awk strings that do not need to be
    escaped and newer versions of awk now warn about this.
    
    Fix the string up so that no warning is produced.  The exact same kernel
    module gets created before and after this patch, showing that it wasn't
    needed.
    
    Link: https://lore.kernel.org/r/20191206152600.GA75093@kroah.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ee9e4b70861a4af9a947cf67fc817aaffbcdd62
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Mon Nov 11 13:40:46 2019 -0600

    rtlwifi: rtl8192de: Fix missing enable interrupt flag
    
    commit 330bb7117101099c687e9c7f13d48068670b9c62 upstream.
    
    In commit 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for
    new drivers"), the flag that indicates that interrupts are enabled was
    never set.
    
    In addition, there are several places when enable/disable interrupts
    were commented out are restored. A sychronize_interrupts() call is
    removed.
    
    Fixes: 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers")
    Cc: Stable <stable@vger.kernel.org>     # v3.18+
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f2ab9a8520f0adb3dd3f88ca17f7b16932a67257
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Mon Nov 11 13:40:45 2019 -0600

    rtlwifi: rtl8192de: Fix missing callback that tests for hw release of buffer
    
    commit 3155db7613edea8fb943624062baf1e4f9cfbfd6 upstream.
    
    In commit 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for
    new drivers"), a callback needed to check if the hardware has released
    a buffer indicating that a DMA operation is completed was not added.
    
    Fixes: 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers")
    Cc: Stable <stable@vger.kernel.org>     # v3.18+
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c7ed1e7f8d8ce78338732a894da67c94a4ec22de
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Mon Nov 11 13:40:44 2019 -0600

    rtlwifi: rtl8192de: Fix missing code to retrieve RX buffer address
    
    commit 0e531cc575c4e9e3dd52ad287b49d3c2dc74c810 upstream.
    
    In commit 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for
    new drivers"), a callback to get the RX buffer address was added to
    the PCI driver. Unfortunately, driver rtl8192de was not modified
    appropriately and the code runs into a WARN_ONCE() call. The use
    of an incorrect array is also fixed.
    
    Fixes: 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers")
    Cc: Stable <stable@vger.kernel.org> # 3.18+
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04e23c8fced1cb2e015ace155a4dd02c32fd1227
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Fri Nov 15 15:43:06 2019 -0500

    btrfs: record all roots for rename exchange on a subvol
    
    commit 3e1740993e43116b3bc71b0aad1e6872f6ccf341 upstream.
    
    Testing with the new fsstress support for subvolumes uncovered a pretty
    bad problem with rename exchange on subvolumes.  We're modifying two
    different subvolumes, but we only start the transaction on one of them,
    so the other one is not added to the dirty root list.  This is caught by
    btrfs_cow_block() with a warning because the root has not been updated,
    however if we do not modify this root again we'll end up pointing at an
    invalid root because the root item is never updated.
    
    Fix this by making sure we add the destination root to the trans list,
    the same as we do with normal renames.  This fixes the corruption.
    
    Fixes: cdd1fedf8261 ("btrfs: add support for RENAME_EXCHANGE and RENAME_WHITEOUT")
    CC: stable@vger.kernel.org # 4.9+
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebf66f5a00c3483d17261af50bf5f913586ad16f
Author: Filipe Manana <fdmanana@suse.com>
Date:   Wed Oct 30 12:23:01 2019 +0000

    Btrfs: send, skip backreference walking for extents with many references
    
    commit fd0ddbe2509568b00df364156f47561e9f469f15 upstream.
    
    Backreference walking, which is used by send to figure if it can issue
    clone operations instead of write operations, can be very slow and use
    too much memory when extents have many references. This change simply
    skips backreference walking when an extent has more than 64 references,
    in which case we fallback to a write operation instead of a clone
    operation. This limit is conservative and in practice I observed no
    signicant slowdown with up to 100 references and still low memory usage
    up to that limit.
    
    This is a temporary workaround until there are speedups in the backref
    walking code, and as such it does not attempt to add extra interfaces or
    knobs to tweak the threshold.
    
    Reported-by: Atemu <atemu.main@gmail.com>
    Link: https://lore.kernel.org/linux-btrfs/CAE4GHgkvqVADtS4AzcQJxo0Q1jKQgKaW3JGp3SGdoinVo=C9eQ@mail.gmail.com/T/#me55dc0987f9cc2acaa54372ce0492c65782be3fa
    CC: stable@vger.kernel.org # 4.4+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0e1357a0a5c4e152f47c313737e6e05f8de70d1
Author: Qu Wenruo <wqu@suse.com>
Date:   Thu Oct 24 09:38:29 2019 +0800

    btrfs: Remove btrfs_bio::flags member
    
    commit 34b127aecd4fe8e6a3903e10f204a7b7ffddca22 upstream.
    
    The last user of btrfs_bio::flags was removed in commit 326e1dbb5736
    ("block: remove management of bi_remaining when restoring original
    bi_end_io"), remove it.
    
    (Tagged for stable as the structure is heavily used and space savings
    are desirable.)
    
    CC: stable@vger.kernel.org # 4.4+
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a2e1bc91abc04481f81ac4f9c6cb8a65bc4f867
Author: Filipe Manana <fdmanana@suse.com>
Date:   Fri Oct 11 16:41:20 2019 +0100

    Btrfs: fix negative subv_writers counter and data space leak after buffered write
    
    commit a0e248bb502d5165b3314ac3819e888fdcdf7d9f upstream.
    
    When doing a buffered write it's possible to leave the subv_writers
    counter of the root, used for synchronization between buffered nocow
    writers and snapshotting. This happens in an exceptional case like the
    following:
    
    1) We fail to allocate data space for the write, since there's not
       enough available data space nor enough unallocated space for allocating
       a new data block group;
    
    2) Because of that failure, we try to go to NOCOW mode, which succeeds
       and therefore we set the local variable 'only_release_metadata' to true
       and set the root's sub_writers counter to 1 through the call to
       btrfs_start_write_no_snapshotting() made by check_can_nocow();
    
    3) The call to btrfs_copy_from_user() returns zero, which is very unlikely
       to happen but not impossible;
    
    4) No pages are copied because btrfs_copy_from_user() returned zero;
    
    5) We call btrfs_end_write_no_snapshotting() which decrements the root's
       subv_writers counter to 0;
    
    6) We don't set 'only_release_metadata' back to 'false' because we do
       it only if 'copied', the value returned by btrfs_copy_from_user(), is
       greater than zero;
    
    7) On the next iteration of the while loop, which processes the same
       page range, we are now able to allocate data space for the write (we
       got enough data space released in the meanwhile);
    
    8) After this if we fail at btrfs_delalloc_reserve_metadata(), because
       now there isn't enough free metadata space, or in some other place
       further below (prepare_pages(), lock_and_cleanup_extent_if_need(),
       btrfs_dirty_pages()), we break out of the while loop with
       'only_release_metadata' having a value of 'true';
    
    9) Because 'only_release_metadata' is 'true' we end up decrementing the
       root's subv_writers counter to -1 (through a call to
       btrfs_end_write_no_snapshotting()), and we also end up not releasing the
       data space previously reserved through btrfs_check_data_free_space().
       As a consequence the mechanism for synchronizing NOCOW buffered writes
       with snapshotting gets broken.
    
    Fix this by always setting 'only_release_metadata' to false at the start
    of each iteration.
    
    Fixes: 8257b2dc3c1a ("Btrfs: introduce btrfs_{start, end}_nocow_write() for each subvolume")
    Fixes: 7ee9e4405f26 ("Btrfs: check if we can nocow if we don't have data space")
    CC: stable@vger.kernel.org # 4.4+
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca64b008af0edf8e17e3f13c535d2bc5b2a2d506
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Thu Sep 26 08:29:32 2019 -0400

    btrfs: use refcount_inc_not_zero in kill_all_nodes
    
    commit baf320b9d531f1cfbf64c60dd155ff80a58b3796 upstream.
    
    We hit the following warning while running down a different problem
    
    [ 6197.175850] ------------[ cut here ]------------
    [ 6197.185082] refcount_t: underflow; use-after-free.
    [ 6197.194704] WARNING: CPU: 47 PID: 966 at lib/refcount.c:190 refcount_sub_and_test_checked+0x53/0x60
    [ 6197.521792] Call Trace:
    [ 6197.526687]  __btrfs_release_delayed_node+0x76/0x1c0
    [ 6197.536615]  btrfs_kill_all_delayed_nodes+0xec/0x130
    [ 6197.546532]  ? __btrfs_btree_balance_dirty+0x60/0x60
    [ 6197.556482]  btrfs_clean_one_deleted_snapshot+0x71/0xd0
    [ 6197.566910]  cleaner_kthread+0xfa/0x120
    [ 6197.574573]  kthread+0x111/0x130
    [ 6197.581022]  ? kthread_create_on_node+0x60/0x60
    [ 6197.590086]  ret_from_fork+0x1f/0x30
    [ 6197.597228] ---[ end trace 424bb7ae00509f56 ]---
    
    This is because the free side drops the ref without the lock, and then
    takes the lock if our refcount is 0.  So you can have nodes on the tree
    that have a refcount of 0.  Fix this by zero'ing out that element in our
    temporary array so we don't try to kill it again.
    
    CC: stable@vger.kernel.org # 4.14+
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    [ add comment ]
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 797200898adbea5e7ece68f92331efd26faa3efc
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Tue Sep 24 16:50:43 2019 -0400

    btrfs: check page->mapping when loading free space cache
    
    commit 3797136b626ad4b6582223660c041efdea8f26b2 upstream.
    
    While testing 5.2 we ran into the following panic
    
    [52238.017028] BUG: kernel NULL pointer dereference, address: 0000000000000001
    [52238.105608] RIP: 0010:drop_buffers+0x3d/0x150
    [52238.304051] Call Trace:
    [52238.308958]  try_to_free_buffers+0x15b/0x1b0
    [52238.317503]  shrink_page_list+0x1164/0x1780
    [52238.325877]  shrink_inactive_list+0x18f/0x3b0
    [52238.334596]  shrink_node_memcg+0x23e/0x7d0
    [52238.342790]  ? do_shrink_slab+0x4f/0x290
    [52238.350648]  shrink_node+0xce/0x4a0
    [52238.357628]  balance_pgdat+0x2c7/0x510
    [52238.365135]  kswapd+0x216/0x3e0
    [52238.371425]  ? wait_woken+0x80/0x80
    [52238.378412]  ? balance_pgdat+0x510/0x510
    [52238.386265]  kthread+0x111/0x130
    [52238.392727]  ? kthread_create_on_node+0x60/0x60
    [52238.401782]  ret_from_fork+0x1f/0x30
    
    The page we were trying to drop had a page->private, but had no
    page->mapping and so called drop_buffers, assuming that we had a
    buffer_head on the page, and then panic'ed trying to deref 1, which is
    our page->private for data pages.
    
    This is happening because we're truncating the free space cache while
    we're trying to load the free space cache.  This isn't supposed to
    happen, and I'll fix that in a followup patch.  However we still
    shouldn't allow those sort of mistakes to result in messing with pages
    that do not belong to us.  So add the page->mapping check to verify that
    we still own this page after dropping and re-acquiring the page lock.
    
    This page being unlocked as:
    btrfs_readpage
      extent_read_full_page
        __extent_read_full_page
          __do_readpage
            if (!nr)
               unlock_page  <-- nr can be 0 only if submit_extent_page
                                returns an error
    
    CC: stable@vger.kernel.org # 4.4+
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    [ add callchain ]
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5320472be4fe909f53279d2fd5aaa422dd06f69
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Wed Nov 27 13:10:54 2019 -0800

    usb: dwc3: ep0: Clear started flag on completion
    
    commit 2d7b78f59e020b07fc6338eefe286f54ee2d6773 upstream.
    
    Clear ep0's DWC3_EP_TRANSFER_STARTED flag if the END_TRANSFER command is
    completed. Otherwise, we can't start control transfer again after
    END_TRANSFER.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
    Signed-off-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef785dd3ca4407e06210645a332728a3f84b34c7
Author: David Hildenbrand <david@redhat.com>
Date:   Wed Dec 11 12:11:52 2019 +0100

    virtio-balloon: fix managed page counts when migrating pages between zones
    
    commit 63341ab03706e11a31e3dd8ccc0fbc9beaf723f0 upstream.
    
    In case we have to migrate a ballon page to a newpage of another zone, the
    managed page count of both zones is wrong. Paired with memory offlining
    (which will adjust the managed page count), we can trigger kernel crashes
    and all kinds of different symptoms.
    
    One way to reproduce:
    1. Start a QEMU guest with 4GB, no NUMA
    2. Hotplug a 1GB DIMM and online the memory to ZONE_NORMAL
    3. Inflate the balloon to 1GB
    4. Unplug the DIMM (be quick, otherwise unmovable data ends up on it)
    5. Observe /proc/zoneinfo
      Node 0, zone   Normal
        pages free     16810
              min      24848885473806
              low      18471592959183339
              high     36918337032892872
              spanned  262144
              present  262144
              managed  18446744073709533486
    6. Do anything that requires some memory (e.g., inflate the balloon some
    more). The OOM goes crazy and the system crashes
      [  238.324946] Out of memory: Killed process 537 (login) total-vm:27584kB, anon-rss:860kB, file-rss:0kB, shmem-rss:00
      [  238.338585] systemd invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
      [  238.339420] CPU: 0 PID: 1 Comm: systemd Tainted: G      D W         5.4.0-next-20191204+ #75
      [  238.340139] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu4
      [  238.341121] Call Trace:
      [  238.341337]  dump_stack+0x8f/0xd0
      [  238.341630]  dump_header+0x61/0x5ea
      [  238.341942]  oom_kill_process.cold+0xb/0x10
      [  238.342299]  out_of_memory+0x24d/0x5a0
      [  238.342625]  __alloc_pages_slowpath+0xd12/0x1020
      [  238.343024]  __alloc_pages_nodemask+0x391/0x410
      [  238.343407]  pagecache_get_page+0xc3/0x3a0
      [  238.343757]  filemap_fault+0x804/0xc30
      [  238.344083]  ? ext4_filemap_fault+0x28/0x42
      [  238.344444]  ext4_filemap_fault+0x30/0x42
      [  238.344789]  __do_fault+0x37/0x1a0
      [  238.345087]  __handle_mm_fault+0x104d/0x1ab0
      [  238.345450]  handle_mm_fault+0x169/0x360
      [  238.345790]  do_user_addr_fault+0x20d/0x490
      [  238.346154]  do_page_fault+0x31/0x210
      [  238.346468]  async_page_fault+0x43/0x50
      [  238.346797] RIP: 0033:0x7f47eba4197e
      [  238.347110] Code: Bad RIP value.
      [  238.347387] RSP: 002b:00007ffd7c0c1890 EFLAGS: 00010293
      [  238.347834] RAX: 0000000000000002 RBX: 000055d196a20a20 RCX: 00007f47eba4197e
      [  238.348437] RDX: 0000000000000033 RSI: 00007ffd7c0c18c0 RDI: 0000000000000004
      [  238.349047] RBP: 00007ffd7c0c1c20 R08: 0000000000000000 R09: 0000000000000033
      [  238.349660] R10: 00000000ffffffff R11: 0000000000000293 R12: 0000000000000001
      [  238.350261] R13: ffffffffffffffff R14: 0000000000000000 R15: 00007ffd7c0c18c0
      [  238.350878] Mem-Info:
      [  238.351085] active_anon:3121 inactive_anon:51 isolated_anon:0
      [  238.351085]  active_file:12 inactive_file:7 isolated_file:0
      [  238.351085]  unevictable:0 dirty:0 writeback:0 unstable:0
      [  238.351085]  slab_reclaimable:5565 slab_unreclaimable:10170
      [  238.351085]  mapped:3 shmem:111 pagetables:155 bounce:0
      [  238.351085]  free:720717 free_pcp:2 free_cma:0
      [  238.353757] Node 0 active_anon:12484kB inactive_anon:204kB active_file:48kB inactive_file:28kB unevictable:0kB iss
      [  238.355979] Node 0 DMA free:11556kB min:36kB low:48kB high:60kB reserved_highatomic:0KB active_anon:152kB inactivB
      [  238.358345] lowmem_reserve[]: 0 2955 2884 2884 2884
      [  238.358761] Node 0 DMA32 free:2677864kB min:7004kB low:10028kB high:13052kB reserved_highatomic:0KB active_anon:0B
      [  238.361202] lowmem_reserve[]: 0 0 72057594037927865 72057594037927865 72057594037927865
      [  238.361888] Node 0 Normal free:193448kB min:99395541895224kB low:73886371836733356kB high:147673348131571488kB reB
      [  238.364765] lowmem_reserve[]: 0 0 0 0 0
      [  238.365101] Node 0 DMA: 7*4kB (U) 5*8kB (UE) 6*16kB (UME) 2*32kB (UM) 1*64kB (U) 2*128kB (UE) 3*256kB (UME) 2*512B
      [  238.366379] Node 0 DMA32: 0*4kB 1*8kB (U) 2*16kB (UM) 2*32kB (UM) 2*64kB (UM) 1*128kB (U) 1*256kB (U) 1*512kB (U)B
      [  238.367654] Node 0 Normal: 1985*4kB (UME) 1321*8kB (UME) 844*16kB (UME) 524*32kB (UME) 300*64kB (UME) 138*128kB (B
      [  238.369184] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
      [  238.369915] 130 total pagecache pages
      [  238.370241] 0 pages in swap cache
      [  238.370533] Swap cache stats: add 0, delete 0, find 0/0
      [  238.370981] Free swap  = 0kB
      [  238.371239] Total swap = 0kB
      [  238.371488] 1048445 pages RAM
      [  238.371756] 0 pages HighMem/MovableOnly
      [  238.372090] 306992 pages reserved
      [  238.372376] 0 pages cma reserved
      [  238.372661] 0 pages hwpoisoned
    
    In another instance (older kernel), I was able to observe this
    (negative page count :/):
      [  180.896971] Offlined Pages 32768
      [  182.667462] Offlined Pages 32768
      [  184.408117] Offlined Pages 32768
      [  186.026321] Offlined Pages 32768
      [  187.684861] Offlined Pages 32768
      [  189.227013] Offlined Pages 32768
      [  190.830303] Offlined Pages 32768
      [  190.833071] Built 1 zonelists, mobility grouping on.  Total pages: -36920272750453009
    
    In another instance (older kernel), I was no longer able to start any
    process:
      [root@vm ~]# [  214.348068] Offlined Pages 32768
      [  215.973009] Offlined Pages 32768
      cat /proc/meminfo
      -bash: fork: Cannot allocate memory
      [root@vm ~]# cat /proc/meminfo
      -bash: fork: Cannot allocate memory
    
    Fix it by properly adjusting the managed page count when migrating if
    the zone changed. The managed page count of the zones now looks after
    unplug of the DIMM (and after deflating the balloon) just like before
    inflating the balloon (and plugging+onlining the DIMM).
    
    We'll temporarily modify the totalram page count. If this ever becomes a
    problem, we can fine tune by providing helpers that don't touch
    the totalram pages (e.g., adjust_zone_managed_page_count()).
    
    Please note that fixing up the managed page count is only necessary when
    we adjusted the managed page count when inflating - only if we
    don't have VIRTIO_BALLOON_F_DEFLATE_ON_OOM. With that feature, the
    managed page count is not touched when inflating/deflating.
    
    Reported-by: Yumei Huang <yuhuang@redhat.com>
    Fixes: 3dcc0571cd64 ("mm: correctly update zone->managed_pages")
    Cc: <stable@vger.kernel.org> # v3.11+
    Cc: "Michael S. Tsirkin" <mst@redhat.com>
    Cc: Jason Wang <jasowang@redhat.com>
    Cc: Jiang Liu <liuj97@gmail.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Igor Mammedov <imammedo@redhat.com>
    Cc: virtualization@lists.linux-foundation.org
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26bde72620ba28d7a979aeb23109c771b4b5ea18
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Tue Oct 22 16:58:59 2019 +0200

    mtd: spear_smi: Fix Write Burst mode
    
    commit 69c7f4618c16b4678f8a4949b6bb5ace259c0033 upstream.
    
    Any write with either dd or flashcp to a device driven by the
    spear_smi.c driver will pass through the spear_smi_cpy_toio()
    function. This function will get called for chunks of up to 256 bytes.
    If the amount of data is smaller, we may have a problem if the data
    length is not 4-byte aligned. In this situation, the kernel panics
    during the memcpy:
    
        # dd if=/dev/urandom bs=1001 count=1 of=/dev/mtd6
        spear_smi_cpy_toio [620] dest c9070000, src c7be8800, len 256
        spear_smi_cpy_toio [620] dest c9070100, src c7be8900, len 256
        spear_smi_cpy_toio [620] dest c9070200, src c7be8a00, len 256
        spear_smi_cpy_toio [620] dest c9070300, src c7be8b00, len 233
        Unhandled fault: external abort on non-linefetch (0x808) at 0xc90703e8
        [...]
        PC is at memcpy+0xcc/0x330
    
    The above error occurs because the implementation of memcpy_toio()
    tries to optimize the number of I/O by writing 4 bytes at a time as
    much as possible, until there are less than 4 bytes left and then
    switches to word or byte writes.
    
    Unfortunately, the specification states about the Write Burst mode:
    
            "the next AHB Write request should point to the next
            incremented address and should have the same size (byte,
            half-word or word)"
    
    This means ARM architecture implementation of memcpy_toio() cannot
    reliably be used blindly here. Workaround this situation by update the
    write path to stick to byte access when the burst length is not
    multiple of 4.
    
    Fixes: f18dbbb1bfe0 ("mtd: ST SPEAr: Add SMI driver for serial NOR flash")
    Cc: Russell King <linux@armlinux.org.uk>
    Cc: Boris Brezillon <boris.brezillon@collabora.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Reviewed-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3be0e56cd6a8ea11fd8ecfc5f52b5cc52a236213
Author: Tadeusz Struk <tadeusz.struk@intel.com>
Date:   Mon Oct 7 14:46:37 2019 -0700

    tpm: add check after commands attribs tab allocation
    
    commit f1689114acc5e89a196fec6d732dae3e48edb6ad upstream.
    
    devm_kcalloc() can fail and return NULL so we need to check for that.
    
    Cc: stable@vger.kernel.org
    Fixes: 58472f5cd4f6f ("tpm: validate TPM 2.0 commands")
    Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
    Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
    Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
    Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
    Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d41971493d28edf2b916ad5201d8301a8513ed51
Author: Pete Zaitcev <zaitcev@redhat.com>
Date:   Wed Dec 4 20:39:41 2019 -0600

    usb: mon: Fix a deadlock in usbmon between mmap and read
    
    commit 19e6317d24c25ee737c65d1ffb7483bdda4bb54a upstream.
    
    The problem arises because our read() function grabs a lock of the
    circular buffer, finds something of interest, then invokes copy_to_user()
    straight from the buffer, which in turn takes mm->mmap_sem. In the same
    time, the callback mon_bin_vma_fault() is invoked under mm->mmap_sem.
    It attempts to take the fetch lock and deadlocks.
    
    This patch does away with protecting of our page list with any
    semaphores, and instead relies on the kernel not close the device
    while mmap is active in a process.
    
    In addition, we prohibit re-sizing of a buffer while mmap is active.
    This way, when (now unlocked) fault is processed, it works with the
    page that is intended to be mapped-in, and not some other random page.
    Note that this may have an ABI impact, but hopefully no legitimate
    program is this wrong.
    
    Signed-off-by: Pete Zaitcev <zaitcev@redhat.com>
    Reported-by: syzbot+56f9673bb4cdcbeb0e92@syzkaller.appspotmail.com
    Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
    Fixes: 46eb14a6e158 ("USB: fix usbmon BUG trigger")
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20191204203941.3503452b@suzdal.zaitcev.lan
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a275fa6ad522f6b48bce59617dcce1d4ef5ecd2
Author: Emiliano Ingrassia <ingrassia@epigenesys.com>
Date:   Wed Nov 27 17:03:55 2019 +0100

    usb: core: urb: fix URB structure initialization function
    
    commit 1cd17f7f0def31e3695501c4f86cd3faf8489840 upstream.
    
    Explicitly initialize URB structure urb_list field in usb_init_urb().
    This field can be potentially accessed uninitialized and its
    initialization is coherent with the usage of list_del_init() in
    usb_hcd_unlink_urb_from_ep() and usb_giveback_urb_bh() and its
    explicit initialization in usb_hcd_submit_urb() error path.
    
    Signed-off-by: Emiliano Ingrassia <ingrassia@epigenesys.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20191127160355.GA27196@ingrassia.epigenesys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea1570688c3f0b8bbf03218c1e94ce0251934e0d
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Dec 10 12:25:59 2019 +0100

    USB: adutux: fix interface sanity check
    
    commit 3c11c4bed02b202e278c0f5c319ae435d7fb9815 upstream.
    
    Make sure to use the current alternate setting when verifying the
    interface descriptors to avoid binding to an invalid interface.
    
    Failing to do so could cause the driver to misbehave or trigger a WARN()
    in usb_submit_urb() that kernels with panic_on_warn set would choke on.
    
    Fixes: 03270634e242 ("USB: Add ADU support for Ontrak ADU devices")
    Cc: stable <stable@vger.kernel.org>     # 2.6.19
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20191210112601.3561-3-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b62b19936438532cb578a0f4060ebfb377a1d99
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Dec 10 12:26:01 2019 +0100

    USB: serial: io_edgeport: fix epic endpoint lookup
    
    commit 7c5a2df3367a2c4984f1300261345817d95b71f8 upstream.
    
    Make sure to use the current alternate setting when looking up the
    endpoints on epic devices to avoid binding to an invalid interface.
    
    Failing to do so could cause the driver to misbehave or trigger a WARN()
    in usb_submit_urb() that kernels with panic_on_warn set would choke on.
    
    Fixes: 6e8cf7751f9f ("USB: add EPIC support to the io_edgeport driver")
    Cc: stable <stable@vger.kernel.org>     # 2.6.21
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20191210112601.3561-5-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19401ee0fb9e199e1ba01adb3c3da13163c2ee6a
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Dec 10 12:26:00 2019 +0100

    USB: idmouse: fix interface sanity checks
    
    commit 59920635b89d74b9207ea803d5e91498d39e8b69 upstream.
    
    Make sure to use the current alternate setting when verifying the
    interface descriptors to avoid binding to an invalid interface.
    
    Failing to do so could cause the driver to misbehave or trigger a WARN()
    in usb_submit_urb() that kernels with panic_on_warn set would choke on.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20191210112601.3561-4-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 38aca0b906833dfc48544461d3e8b2ee517e2b40
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Dec 10 12:25:58 2019 +0100

    USB: atm: ueagle-atm: add missing endpoint check
    
    commit 09068c1ad53fb077bdac288869dec2435420bdc4 upstream.
    
    Make sure that the interrupt interface has an endpoint before trying to
    access its endpoint descriptors to avoid dereferencing a NULL pointer.
    
    The driver binds to the interrupt interface with interface number 0, but
    must not assume that this interface or its current alternate setting are
    the first entries in the corresponding configuration arrays.
    
    Fixes: b72458a80c75 ("[PATCH] USB: Eagle and ADI 930 usb adsl modem driver")
    Cc: stable <stable@vger.kernel.org>     # 2.6.16
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20191210112601.3561-2-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1958757ac6fb4046d143ae9e905c3e6b0fe8b69
Author: Chris Lesiak <chris.lesiak@licor.com>
Date:   Thu Nov 21 20:39:42 2019 +0000

    iio: humidity: hdc100x: fix IIO_HUMIDITYRELATIVE channel reporting
    
    commit 342a6928bd5017edbdae376042d8ad6af3d3b943 upstream.
    
    The IIO_HUMIDITYRELATIVE channel was being incorrectly reported back
    as percent when it should have been milli percent. This is via an
    incorrect scale value being returned to userspace.
    
    Signed-off-by: Chris Lesiak <chris.lesiak@licor.com>
    Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f2643dec8fd5b6736f71b1cdc036982eefb04fe4
Author: H. Nikolaus Schaller <hns@goldelico.com>
Date:   Thu Nov 7 11:30:36 2019 +0100

    ARM: dts: pandora-common: define wl1251 as child node of mmc3
    
    commit 4f9007d692017cef38baf2a9b82b7879d5b2407b upstream.
    
    Since v4.7 the dma initialization requires that there is a
    device tree property for "rx" and "tx" channels which is
    not provided by the pdata-quirks initialization.
    
    By conversion of the mmc3 setup to device tree this will
    finally allows to remove the OpenPandora wlan specific omap3
    data-quirks.
    
    Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel")
    Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
    Cc: <stable@vger.kernel.org> # v4.7+
    Acked-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d0b11b6ac68f280aabe962349678342f0dcc297
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Wed Dec 11 16:20:06 2019 +0200

    xhci: handle some XHCI_TRUST_TX_LENGTH quirks cases as default behaviour.
    
    commit 7ff11162808cc2ec66353fc012c58bb449c892c3 upstream.
    
    xhci driver claims it needs XHCI_TRUST_TX_LENGTH quirk for both
    Broadcom/Cavium and a Renesas xHC controllers.
    
    The quirk was inteded for handling false "success" complete event for
    transfers that had data left untransferred.
    These transfers should complete with "short packet" events instead.
    
    In these two new cases the false "success" completion is reported
    after a "short packet" if the TD consists of several TRBs.
    xHCI specs 4.10.1.1.2 say remaining TRBs should report "short packet"
    as well after the first short packet in a TD, but this issue seems so
    common it doesn't make sense to add the quirk for all vendors.
    
    Turn these events into short packets automatically instead.
    
    This gets rid of the  "The WARN Successful completion on short TX for
    slot 1 ep 1: needs XHCI_TRUST_TX_LENGTH quirk" warning in many cases.
    
    Cc: <stable@vger.kernel.org>
    Reported-by: Eli Billauer <eli.billauer@gmail.com>
    Reported-by: Ard Biesheuvel <ardb@kernel.org>
    Tested-by: Eli Billauer <eli.billauer@gmail.com>
    Tested-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20191211142007.8847-6-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b399e679da42f76abdeab9722e687a61bb581f5
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Wed Dec 11 16:20:05 2019 +0200

    xhci: Increase STS_HALT timeout in xhci_suspend()
    
    commit 7c67cf6658cec70d8a43229f2ce74ca1443dc95e upstream.
    
    I've recently observed failed xHCI suspend attempt on AMD Raven Ridge
    system:
    kernel: xhci_hcd 0000:04:00.4: WARN: xHC CMD_RUN timeout
    kernel: PM: suspend_common(): xhci_pci_suspend+0x0/0xd0 returns -110
    kernel: PM: pci_pm_suspend(): hcd_pci_suspend+0x0/0x30 returns -110
    kernel: PM: dpm_run_callback(): pci_pm_suspend+0x0/0x150 returns -110
    kernel: PM: Device 0000:04:00.4 failed to suspend async: error -110
    
    Similar to commit ac343366846a ("xhci: Increase STS_SAVE timeout in
    xhci_suspend()") we also need to increase the HALT timeout to make it be
    able to suspend again.
    
    Cc: <stable@vger.kernel.org> # 5.2+
    Fixes: f7fac17ca925 ("xhci: Convert xhci_handshake() to use readl_poll_timeout_atomic()")
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20191211142007.8847-5-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 839a996485c7159cee3c81b06ae7b3c206f4238f
Author: Henry Lin <henryl@nvidia.com>
Date:   Wed Dec 11 16:20:04 2019 +0200

    usb: xhci: only set D3hot for pci device
    
    commit f2c710f7dca8457e88b4ac9de2060f011254f9dd upstream.
    
    Xhci driver cannot call pci_set_power_state() on non-pci xhci host
    controllers. For example, NVIDIA Tegra XHCI host controller which acts
    as platform device with XHCI_SPURIOUS_WAKEUP quirk set in some platform
    hits this issue during shutdown.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 638298dc66ea ("xhci: Fix spurious wakeups after S5 on Haswell")
    Signed-off-by: Henry Lin <henryl@nvidia.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20191211142007.8847-4-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c4d935cc494f9ede67820fa217850a31f26b4b5
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Dec 2 09:56:10 2019 +0100

    staging: gigaset: add endpoint-type sanity check
    
    commit ed9ed5a89acba51b82bdff61144d4e4a4245ec8a upstream.
    
    Add missing endpoint-type sanity checks to probe.
    
    This specifically prevents a warning in USB core on URB submission when
    fuzzing USB descriptors.
    
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20191202085610.12719-4-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56a6f724344677de2a4c72935b5c12f3a1216aeb
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Dec 2 09:56:09 2019 +0100

    staging: gigaset: fix illegal free on probe errors
    
    commit 84f60ca7b326ed8c08582417493982fe2573a9ad upstream.
    
    The driver failed to initialise its receive-buffer pointer, something
    which could lead to an illegal free on late probe errors.
    
    Fix this by making sure to clear all driver data at allocation.
    
    Fixes: 2032e2c2309d ("usb_gigaset: code cleanup")
    Cc: stable <stable@vger.kernel.org>     # 2.6.33
    Cc: Tilman Schmidt <tilman@imap.cc>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20191202085610.12719-3-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3891da012011da4ac8b0bd4e4453ca758633208
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Dec 2 09:56:08 2019 +0100

    staging: gigaset: fix general protection fault on probe
    
    commit 53f35a39c3860baac1e5ca80bf052751cfb24a99 upstream.
    
    Fix a general protection fault when accessing the endpoint descriptors
    which could be triggered by a malicious device due to missing sanity
    checks on the number of endpoints.
    
    Reported-by: syzbot+35b1c403a14f5c89eba7@syzkaller.appspotmail.com
    Fixes: 07dc1f9f2f80 ("[PATCH] isdn4linux: Siemens Gigaset drivers - M105 USB DECT adapter")
    Cc: stable <stable@vger.kernel.org>     # 2.6.17
    Cc: Hansjoerg Lipp <hjlipp@web.de>
    Cc: Tilman Schmidt <tilman@imap.cc>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20191202085610.12719-2-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c64cee83f105ef564348ac06648057987a879c1
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Dec 10 12:47:51 2019 +0100

    staging: rtl8712: fix interface sanity check
    
    commit c724f776f048538ecfdf53a52b7a522309f5c504 upstream.
    
    Make sure to use the current alternate setting when verifying the
    interface descriptors to avoid binding to an invalid interface.
    
    Failing to do so could cause the driver to misbehave or trigger a WARN()
    in usb_submit_urb() that kernels with panic_on_warn set would choke on.
    
    Fixes: 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel")
    Cc: stable <stable@vger.kernel.org>     # 2.6.37
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20191210114751.5119-3-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca922fe7d466944dab40a7d93e3203f81d7110d0
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Dec 10 12:47:50 2019 +0100

    staging: rtl8188eu: fix interface sanity check
    
    commit 74ca34118a0e05793935d804ccffcedd6eb56596 upstream.
    
    Make sure to use the current alternate setting when verifying the
    interface descriptors to avoid binding to an invalid interface.
    
    Failing to do so could cause the driver to misbehave or trigger a WARN()
    in usb_submit_urb() that kernels with panic_on_warn set would choke on.
    
    Fixes: c2478d39076b ("staging: r8188eu: Add files for new driver - part 20")
    Cc: stable <stable@vger.kernel.org>     # 3.12
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20191210114751.5119-2-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b394c7780773890ca1ad0bc50a9e5d52805f36bb
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Wed Nov 6 14:27:10 2019 +0800

    usb: Allow USB device to be warm reset in suspended state
    
    commit e76b3bf7654c3c94554c24ba15a3d105f4006c80 upstream.
    
    On Dell WD15 dock, sometimes USB ethernet cannot be detected after plugging
    cable to the ethernet port, the hub and roothub get runtime resumed and
    runtime suspended immediately:
    ...
    [  433.315169] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_resume: 0
    [  433.315204] usb usb4: usb auto-resume
    [  433.315226] hub 4-0:1.0: hub_resume
    [  433.315239] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10202e2, return 0x10343
    [  433.315264] usb usb4-port1: status 0343 change 0001
    [  433.315279] xhci_hcd 0000:3a:00.0: clear port1 connect change, portsc: 0x10002e2
    [  433.315293] xhci_hcd 0000:3a:00.0: Get port status 4-2 read: 0x2a0, return 0x2a0
    [  433.317012] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling.
    [  433.422282] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10002e2, return 0x343
    [  433.422307] usb usb4-port1: do warm reset
    [  433.422311] usb 4-1: device reset not allowed in state 8
    [  433.422339] hub 4-0:1.0: state 7 ports 2 chg 0002 evt 0000
    [  433.422346] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10002e2, return 0x343
    [  433.422356] usb usb4-port1: do warm reset
    [  433.422358] usb 4-1: device reset not allowed in state 8
    [  433.422428] xhci_hcd 0000:3a:00.0: set port remote wake mask, actual port 0 status  = 0xf0002e2
    [  433.422455] xhci_hcd 0000:3a:00.0: set port remote wake mask, actual port 1 status  = 0xe0002a0
    [  433.422465] hub 4-0:1.0: hub_suspend
    [  433.422475] usb usb4: bus auto-suspend, wakeup 1
    [  433.426161] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling.
    [  433.466209] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
    [  433.510204] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
    [  433.554051] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
    [  433.598235] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
    [  433.642154] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
    [  433.686204] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
    [  433.730205] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
    [  433.774203] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
    [  433.818207] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
    [  433.862040] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
    [  433.862053] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling.
    [  433.862077] xhci_hcd 0000:3a:00.0: xhci_suspend: stopping port polling.
    [  433.862096] xhci_hcd 0000:3a:00.0: // Setting command ring address to 0x8578fc001
    [  433.862312] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_suspend: 0
    [  433.862445] xhci_hcd 0000:3a:00.0: PME# enabled
    [  433.902376] xhci_hcd 0000:3a:00.0: restoring config space at offset 0xc (was 0x0, writing 0x20)
    [  433.902395] xhci_hcd 0000:3a:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100403)
    [  433.902490] xhci_hcd 0000:3a:00.0: PME# disabled
    [  433.902504] xhci_hcd 0000:3a:00.0: enabling bus mastering
    [  433.902547] xhci_hcd 0000:3a:00.0: // Setting command ring address to 0x8578fc001
    [  433.902649] pcieport 0000:00:1b.0: PME: Spurious native interrupt!
    [  433.902839] xhci_hcd 0000:3a:00.0: Port change event, 4-1, id 3, portsc: 0xb0202e2
    [  433.902842] xhci_hcd 0000:3a:00.0: resume root hub
    [  433.902845] xhci_hcd 0000:3a:00.0: handle_port_status: starting port polling.
    [  433.902877] xhci_hcd 0000:3a:00.0: xhci_resume: starting port polling.
    [  433.902889] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling.
    [  433.902891] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_resume: 0
    [  433.902919] usb usb4: usb wakeup-resume
    [  433.902942] usb usb4: usb auto-resume
    [  433.902966] hub 4-0:1.0: hub_resume
    ...
    
    As Mathias pointed out, the hub enters Cold Attach Status state and
    requires a warm reset. However usb_reset_device() bails out early when
    the device is in suspended state, as its callers port_event() and
    hub_event() don't always resume the device.
    
    Since there's nothing wrong to reset a suspended device, allow
    usb_reset_device() to do so to solve the issue.
    
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20191106062710.29880-1-kai.heng.feng@canonical.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 657d54ede01239ea658a436f0d3407febfbbef91
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu Nov 14 12:27:58 2019 +0100

    USB: documentation: flags on usb-storage versus UAS
    
    commit 65cc8bf99349f651a0a2cee69333525fe581f306 upstream.
    
    Document which flags work storage, UAS or both
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20191114112758.32747-4-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36808fd964c75b54b7f25d87d3d3fe27c33c14f6
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu Nov 14 12:27:57 2019 +0100

    USB: uas: heed CAPACITY_HEURISTICS
    
    commit 335cbbd5762d5e5c67a8ddd6e6362c2aa42a328f upstream.
    
    There is no need to ignore this flag. We should be as close
    to storage in that regard as makes sense, so honor flags whose
    cost is tiny.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20191114112758.32747-3-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8ee2f8c4aed7191fadc5542c9d762566f231e99
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu Nov 14 12:27:56 2019 +0100

    USB: uas: honor flag to avoid CAPACITY16
    
    commit bff000cae1eec750d62e265c4ba2db9af57b17e1 upstream.
    
    Copy the support over from usb-storage to get feature parity
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20191114112758.32747-2-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c8957279aabecdcfaad925a465f02a9b469603d
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Nov 6 10:06:54 2019 +0100

    media: venus: remove invalid compat_ioctl32 handler
    
    commit 4adc0423de92cf850d1ef5c0e7cb28fd7a38219e upstream.
    
    v4l2_compat_ioctl32() is the function that calls into
    v4l2_file_operations->compat_ioctl32(), so setting that back to the same
    function leads to a trivial endless loop, followed by a kernel
    stack overrun.
    
    Remove the incorrect assignment.
    
    Cc: stable@vger.kernel.org
    Fixes: 7472c1c69138 ("[media] media: venus: vdec: add video decoder files")
    Fixes: aaaa93eda64b ("[media] media: venus: venc: add video encoder files")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2ae20e7a5f2979d13e76e8b83ed355b5d909d8e
Author: Quinn Tran <qutran@marvell.com>
Date:   Tue Nov 5 07:06:53 2019 -0800

    scsi: qla2xxx: Fix driver unload hang
    
    commit dd322b7f3efc8cda085bb60eadc4aee6324eadd8 upstream.
    
    This patch fixes driver unload hang by removing msleep()
    
    Fixes: d74595278f4ab ("scsi: qla2xxx: Add multiple queue pair functionality.")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20191105150657.8092-5-hmadhani@marvell.com
    Reviewed-by: Ewan D. Milne <emilne@redhat.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 802317c442a362ec935a41966f2de4552360fe5b
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Wed Nov 6 14:28:21 2019 -0600

    usb: gadget: pch_udc: fix use after free
    
    commit 66d1b0c0580b7f1b1850ee4423f32ac42afa2e92 upstream.
    
    Remove pointer dereference after free.
    
    pci_pool_free doesn't care about contents of td.
    It's just a void* for it
    
    Addresses-Coverity-ID: 1091173 ("Use after free")
    Cc: stable@vger.kernel.org
    Acked-by: Michal Nazarewicz <mina86@mina86.com>
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Link: https://lore.kernel.org/r/20191106202821.GA20347@embeddedor
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f777dd5b9540fe4640256615522c64219782c2c4
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date:   Wed Oct 30 03:40:46 2019 +0000

    usb: gadget: configfs: Fix missing spin_lock_init()
    
    commit 093edc2baad2c258b1f55d1ab9c63c2b5ae67e42 upstream.
    
    The driver allocates the spinlock but not initialize it.
    Use spin_lock_init() on it to initialize it correctly.
    
    This is detected by Coccinelle semantic patch.
    
    Fixes: 1a1c851bbd70 ("usb: gadget: configfs: fix concurrent issue between composite APIs")
    Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
    Cc: stable <stable@vger.kernel.org>
    Reviewed-by: Peter Chen <peter.chen@nxp.com>
    Link: https://lore.kernel.org/r/20191030034046.188808-1-weiyongjun1@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 709438c431239cc13fc9e0a0483d0c9d05984fa2
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Tue Apr 30 19:34:08 2019 +0800

    appletalk: Set error code if register_snap_client failed
    
    commit c93ad1337ad06a718890a89cdd85188ff9a5a5cc upstream.
    
    If register_snap_client fails in atalk_init,
    error code should be set, otherwise it will
    triggers NULL pointer dereference while unloading
    module.
    
    Fixes: 9804501fa122 ("appletalk: Fix potential NULL pointer dereference in unregister_snap_client")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39de8cc3678f5cd1f4e0ae274c20acabbd85a8b1
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Thu Mar 14 13:47:59 2019 +0800

    appletalk: Fix potential NULL pointer dereference in unregister_snap_client
    
    commit 9804501fa1228048857910a6bf23e085aade37cc upstream.
    
    register_snap_client may return NULL, all the callers
    check it, but only print a warning. This will result in
    NULL pointer dereference in unregister_snap_client and other
    places.
    
    It has always been used like this since v2.6
    
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to <4.15: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f70609f898d63973388b36adf3650489311b13b9
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Wed Dec 4 10:28:54 2019 +0100

    KVM: x86: fix out-of-bounds write in KVM_GET_EMULATED_CPUID (CVE-2019-19332)
    
    commit 433f4ba1904100da65a311033f17a9bf586b287e upstream.
    
    The bounds check was present in KVM_GET_SUPPORTED_CPUID but not
    KVM_GET_EMULATED_CPUID.
    
    Reported-by: syzbot+e3f4897236c4eeb8af4f@syzkaller.appspotmail.com
    Fixes: 84cffe499b94 ("kvm: Emulate MOVBE", 2013-10-29)
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9792606b604b972afebc89375e1ffad763135ac
Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date:   Fri Feb 1 16:49:30 2019 +0900

    ASoC: rsnd: fixup MIX kctrl registration
    
    commit 7aea8a9d71d54f449f49e20324df06341cc18395 upstream.
    
    Renesas sound device has many IPs and many situations.
    If platform/board uses MIXer, situation will be more complex.
    To avoid duplicate DVC kctrl registration when MIXer was used,
    it had original flags.
    But it was issue when sound card was re-binded, because
    no one can't cleanup this flags then.
    
    To solve this issue, commit 9c698e8481a15237a ("ASoC: rsnd: tidyup
    registering method for rsnd_kctrl_new()") checks registered
    card->controls, because if card was re-binded, these were cleanuped
    automatically. This patch could solve re-binding issue.
    But, it start to avoid MIX kctrl.
    
    To solve these issues, we need below.
    To avoid card re-binding issue: check registered card->controls
    To avoid duplicate DVC registration: check registered rsnd_kctrl_cfg
    To allow multiple MIX registration: check registered rsnd_kctrl_cfg
    This patch do it.
    
    Fixes: 9c698e8481a15237a ("ASoC: rsnd: tidyup registering method for rsnd_kctrl_new()")
    Reported-by: Jiada Wang <jiada_wang@mentor.com>
    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Tested-By: Jiada Wang <jiada_wang@mentor.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f8c097ed7fc36a8b8fba0f59ed47840b2e20db5
Author: Jann Horn <jannh@google.com>
Date:   Fri Oct 18 22:56:31 2019 +0200

    binder: Handle start==NULL in binder_update_page_range()
    
    commit 2a9edd056ed4fbf9d2e797c3fc06335af35bccc4 upstream.
    
    The old loop wouldn't stop when reaching `start` if `start==NULL`, instead
    continuing backwards to index -1 and crashing.
    
    Luckily you need to be highly privileged to map things at NULL, so it's not
    a big problem.
    
    Fix it by adjusting the loop so that the loop variable is always in bounds.
    
    This patch is deliberately minimal to simplify backporting, but IMO this
    function could use a refactor. The jump labels in the second loop body are
    horrible (the error gotos should be jumping to free_range instead), and
    both loops would look nicer if they just iterated upwards through indices.
    And the up_read()+mmput() shouldn't be duplicated like that.
    
    Cc: stable@vger.kernel.org
    Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")
    Signed-off-by: Jann Horn <jannh@google.com>
    Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
    Link: https://lore.kernel.org/r/20191018205631.248274-3-jannh@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3be5da34757a684c239e7164c5bd783b6e9e724f
Author: Wei Wang <wvw@google.com>
Date:   Tue Nov 12 12:42:23 2019 -0800

    thermal: Fix deadlock in thermal thermal_zone_device_check
    
    commit 163b00cde7cf2206e248789d2780121ad5e6a70b upstream.
    
    1851799e1d29 ("thermal: Fix use-after-free when unregistering thermal zone
    device") changed cancel_delayed_work to cancel_delayed_work_sync to avoid
    a use-after-free issue. However, cancel_delayed_work_sync could be called
    insides the WQ causing deadlock.
    
    [54109.642398] c0   1162 kworker/u17:1   D    0 11030      2 0x00000000
    [54109.642437] c0   1162 Workqueue: thermal_passive_wq thermal_zone_device_check
    [54109.642447] c0   1162 Call trace:
    [54109.642456] c0   1162  __switch_to+0x138/0x158
    [54109.642467] c0   1162  __schedule+0xba4/0x1434
    [54109.642480] c0   1162  schedule_timeout+0xa0/0xb28
    [54109.642492] c0   1162  wait_for_common+0x138/0x2e8
    [54109.642511] c0   1162  flush_work+0x348/0x40c
    [54109.642522] c0   1162  __cancel_work_timer+0x180/0x218
    [54109.642544] c0   1162  handle_thermal_trip+0x2c4/0x5a4
    [54109.642553] c0   1162  thermal_zone_device_update+0x1b4/0x25c
    [54109.642563] c0   1162  thermal_zone_device_check+0x18/0x24
    [54109.642574] c0   1162  process_one_work+0x3cc/0x69c
    [54109.642583] c0   1162  worker_thread+0x49c/0x7c0
    [54109.642593] c0   1162  kthread+0x17c/0x1b0
    [54109.642602] c0   1162  ret_from_fork+0x10/0x18
    [54109.643051] c0   1162 kworker/u17:2   D    0 16245      2 0x00000000
    [54109.643067] c0   1162 Workqueue: thermal_passive_wq thermal_zone_device_check
    [54109.643077] c0   1162 Call trace:
    [54109.643085] c0   1162  __switch_to+0x138/0x158
    [54109.643095] c0   1162  __schedule+0xba4/0x1434
    [54109.643104] c0   1162  schedule_timeout+0xa0/0xb28
    [54109.643114] c0   1162  wait_for_common+0x138/0x2e8
    [54109.643122] c0   1162  flush_work+0x348/0x40c
    [54109.643131] c0   1162  __cancel_work_timer+0x180/0x218
    [54109.643141] c0   1162  handle_thermal_trip+0x2c4/0x5a4
    [54109.643150] c0   1162  thermal_zone_device_update+0x1b4/0x25c
    [54109.643159] c0   1162  thermal_zone_device_check+0x18/0x24
    [54109.643167] c0   1162  process_one_work+0x3cc/0x69c
    [54109.643177] c0   1162  worker_thread+0x49c/0x7c0
    [54109.643186] c0   1162  kthread+0x17c/0x1b0
    [54109.643195] c0   1162  ret_from_fork+0x10/0x18
    [54109.644500] c0   1162 cat             D    0  7766      1 0x00000001
    [54109.644515] c0   1162 Call trace:
    [54109.644524] c0   1162  __switch_to+0x138/0x158
    [54109.644536] c0   1162  __schedule+0xba4/0x1434
    [54109.644546] c0   1162  schedule_preempt_disabled+0x80/0xb0
    [54109.644555] c0   1162  __mutex_lock+0x3a8/0x7f0
    [54109.644563] c0   1162  __mutex_lock_slowpath+0x14/0x20
    [54109.644575] c0   1162  thermal_zone_get_temp+0x84/0x360
    [54109.644586] c0   1162  temp_show+0x30/0x78
    [54109.644609] c0   1162  dev_attr_show+0x5c/0xf0
    [54109.644628] c0   1162  sysfs_kf_seq_show+0xcc/0x1a4
    [54109.644636] c0   1162  kernfs_seq_show+0x48/0x88
    [54109.644656] c0   1162  seq_read+0x1f4/0x73c
    [54109.644664] c0   1162  kernfs_fop_read+0x84/0x318
    [54109.644683] c0   1162  __vfs_read+0x50/0x1bc
    [54109.644692] c0   1162  vfs_read+0xa4/0x140
    [54109.644701] c0   1162  SyS_read+0xbc/0x144
    [54109.644708] c0   1162  el0_svc_naked+0x34/0x38
    [54109.845800] c0   1162 D 720.000s 1->7766->7766 cat [panic]
    
    Fixes: 1851799e1d29 ("thermal: Fix use-after-free when unregistering thermal zone device")
    Cc: stable@vger.kernel.org
    Signed-off-by: Wei Wang <wvw@google.com>
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44e7fd346b31527d49e923fc36f6c614fef1da49
Author: Jan Kara <jack@suse.cz>
Date:   Thu Nov 21 16:14:38 2019 -0800

    iomap: Fix pipe page leakage during splicing
    
    commit 419e9c38aa075ed0cd3c13d47e15954b686bcdb6 upstream.
    
    When splicing using iomap_dio_rw() to a pipe, we may leak pipe pages
    because bio_iov_iter_get_pages() records that the pipe will have full
    extent worth of data however if file size is not block size aligned
    iomap_dio_rw() returns less than what bio_iov_iter_get_pages() set up
    and splice code gets confused leaking a pipe page with the file tail.
    
    Handle the situation similarly to the old direct IO implementation and
    revert iter to actually returned read amount which makes iter consistent
    with value returned from iomap_dio_rw() and thus the splice code is
    happy.
    
    Fixes: ff6a9292e6f6 ("iomap: implement direct I/O")
    CC: stable@vger.kernel.org
    Reported-by: syzbot+991400e8eba7e00a26e1@syzkaller.appspotmail.com
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 589d00cebfc204c579c3212dd3c00a03c298d298
Author: Viresh Kumar <viresh.kumar@linaro.org>
Date:   Thu Nov 7 08:50:25 2019 +0530

    RDMA/qib: Validate ->show()/store() callbacks before calling them
    
    commit 7ee23491b39259ae83899dd93b2a29ef0f22f0a7 upstream.
    
    The permissions of the read-only or write-only sysfs files can be
    changed (as root) and the user can then try to read a write-only file or
    write to a read-only file which will lead to kernel crash here.
    
    Protect against that by always validating the show/store callbacks.
    
    Link: https://lore.kernel.org/r/d45cc26361a174ae12dbb86c994ef334d257924b.1573096807.git.viresh.kumar@linaro.org
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d83013e02e15826658e25857795270e12e290529
Author: Gregory CLEMENT <gregory.clement@bootlin.com>
Date:   Thu Oct 17 16:18:41 2019 +0200

    spi: atmel: Fix CS high support
    
    commit 7cbb16b2122c09f2ae393a1542fed628505b9da6 upstream.
    
    Until a few years ago, this driver was only used with CS GPIO. The
    only exception is CS0 on AT91RM9200 which has to use internal CS. A
    limitation of the internal CS is that they don't support CS High.
    
    So by using the CS GPIO the CS high configuration was available except
    for the particular case CS0 on RM9200.
    
    When the support for the internal chip-select was added, the check of
    the CS high support was not updated. Due to this the driver accepts
    this configuration for all the SPI controller v2 (used by all SoCs
    excepting the AT91RM9200) whereas the hardware doesn't support it for
    infernal CS.
    
    This patch fixes the test to match the hardware capabilities.
    
    Fixes: 4820303480a1 ("spi: atmel: add support for the internal chip-select of the spi controller")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Link: https://lore.kernel.org/r/20191017141846.7523-3-gregory.clement@bootlin.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41b3b8e0775465c33083ce1998df7f15c039c9bf
Author: Navid Emamdoost <navid.emamdoost@gmail.com>
Date:   Fri Oct 4 14:29:16 2019 -0500

    crypto: user - fix memory leak in crypto_report
    
    commit ffdde5932042600c6807d46c1550b28b0db6a3bc upstream.
    
    In crypto_report, a new skb is created via nlmsg_new(). This skb should
    be released if crypto_report_alg() fails.
    
    Fixes: a38f7907b926 ("crypto: Add userspace configuration API")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cfb63e86ff0ebfd7419d1cb85a6c55d4b9380613
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Wed Oct 23 11:50:44 2019 +0200

    crypto: ecdh - fix big endian bug in ECC library
    
    commit f398243e9fd6a3a059c1ea7b380c40628dbf0c61 upstream.
    
    The elliptic curve arithmetic library used by the EC-DH KPP implementation
    assumes big endian byte order, and unconditionally reverses the byte
    and word order of multi-limb quantities. On big endian systems, the byte
    reordering is not necessary, while the word ordering needs to be retained.
    
    So replace the __swab64() invocation with a call to be64_to_cpu() which
    should do the right thing for both little and big endian builds.
    
    Fixes: 3c4b23901a0c ("crypto: ecdh - Add ECDH software support")
    Cc: <stable@vger.kernel.org> # v4.9+
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f59e0c6a9b1b33003207ede29e934be48e237c4
Author: Mark Salter <msalter@redhat.com>
Date:   Mon Oct 21 11:29:49 2019 -0400

    crypto: ccp - fix uninitialized list head
    
    commit 691505a803a7f223b2af621848d581259c61f77d upstream.
    
    A NULL-pointer dereference was reported in fedora bz#1762199 while
    reshaping a raid6 array after adding a fifth drive to an existing
    array.
    
    [   47.343549] md/raid:md0: raid level 6 active with 3 out of 5 devices, algorithm 2
    [   47.804017] md0: detected capacity change from 0 to 7885289422848
    [   47.822083] Unable to handle kernel read from unreadable memory at virtual address 0000000000000000
    ...
    [   47.940477] CPU: 1 PID: 14210 Comm: md0_raid6 Tainted: G        W         5.2.18-200.fc30.aarch64 #1
    [   47.949594] Hardware name: AMD Overdrive/Supercharger/To be filled by O.E.M., BIOS ROD1002C 04/08/2016
    [   47.958886] pstate: 00400085 (nzcv daIf +PAN -UAO)
    [   47.963668] pc : __list_del_entry_valid+0x2c/0xa8
    [   47.968366] lr : ccp_tx_submit+0x84/0x168 [ccp]
    [   47.972882] sp : ffff00001369b970
    [   47.976184] x29: ffff00001369b970 x28: ffff00001369bdb8
    [   47.981483] x27: 00000000ffffffff x26: ffff8003b758af70
    [   47.986782] x25: ffff8003b758b2d8 x24: ffff8003e6245818
    [   47.992080] x23: 0000000000000000 x22: ffff8003e62450c0
    [   47.997379] x21: ffff8003dfd6add8 x20: 0000000000000003
    [   48.002678] x19: ffff8003e6245100 x18: 0000000000000000
    [   48.007976] x17: 0000000000000000 x16: 0000000000000000
    [   48.013274] x15: 0000000000000000 x14: 0000000000000000
    [   48.018572] x13: ffff7e000ef83a00 x12: 0000000000000001
    [   48.023870] x11: ffff000010eff998 x10: 00000000000019a0
    [   48.029169] x9 : 0000000000000000 x8 : ffff8003e6245180
    [   48.034467] x7 : 0000000000000000 x6 : 000000000000003f
    [   48.039766] x5 : 0000000000000040 x4 : ffff8003e0145080
    [   48.045064] x3 : dead000000000200 x2 : 0000000000000000
    [   48.050362] x1 : 0000000000000000 x0 : ffff8003e62450c0
    [   48.055660] Call trace:
    [   48.058095]  __list_del_entry_valid+0x2c/0xa8
    [   48.062442]  ccp_tx_submit+0x84/0x168 [ccp]
    [   48.066615]  async_tx_submit+0x224/0x368 [async_tx]
    [   48.071480]  async_trigger_callback+0x68/0xfc [async_tx]
    [   48.076784]  ops_run_biofill+0x178/0x1e8 [raid456]
    [   48.081566]  raid_run_ops+0x248/0x818 [raid456]
    [   48.086086]  handle_stripe+0x864/0x1208 [raid456]
    [   48.090781]  handle_active_stripes.isra.0+0xb0/0x278 [raid456]
    [   48.096604]  raid5d+0x378/0x618 [raid456]
    [   48.100602]  md_thread+0xa0/0x150
    [   48.103905]  kthread+0x104/0x130
    [   48.107122]  ret_from_fork+0x10/0x18
    [   48.110686] Code: d2804003 f2fbd5a3 eb03003f 54000320 (f9400021)
    [   48.116766] ---[ end trace 23f390a527f7ad77 ]---
    
    ccp_tx_submit is passed a dma_async_tx_descriptor which is contained in
    a ccp_dma_desc and adds it to a ccp channel's pending list:
    
            list_del(&desc->entry);
            list_add_tail(&desc->entry, &chan->pending);
    
    The problem is that desc->entry may be uninitialized in the
    async_trigger_callback path where the descriptor was gotten
    from ccp_prep_dma_interrupt which got it from ccp_alloc_dma_desc
    which doesn't initialize the desc->entry list head. So, just
    initialize the list head to avoid the problem.
    
    Cc: <stable@vger.kernel.org>
    Reported-by: Sahaj Sarup <sahajsarup@gmail.com>
    Signed-off-by: Mark Salter <msalter@redhat.com>
    Acked-by: Gary R Hook <gary.hook@amd.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9fdc6de63a205a3a469be55aa9863e3969e2c791
Author: Ayush Sawal <ayush.sawal@chelsio.com>
Date:   Fri Oct 4 10:50:58 2019 -0700

    crypto: af_alg - cast ki_complete ternary op to int
    
    commit 64e7f852c47ce99f6c324c46d6a299a5a7ebead9 upstream.
    
    when libkcapi test is executed  using HW accelerator, cipher operation
    return -74.Since af_alg_async_cb->ki_complete treat err as unsigned int,
    libkcapi receive 429467222 even though it expect -ve value.
    
    Hence its required to cast resultlen to int so that proper
    error is returned to libkcapi.
    
    AEAD one shot non-aligned test 2(libkcapi test)
    ./../bin/kcapi   -x 10   -c "gcm(aes)" -i 7815d4b06ae50c9c56e87bd7
    -k ea38ac0c9b9998c80e28fb496a2b88d9 -a
    "853f98a750098bec1aa7497e979e78098155c877879556bb51ddeb6374cbaefc"
    -t "c4ce58985b7203094be1d134c1b8ab0b" -q
    "b03692f86d1b8b39baf2abb255197c98"
    
    Fixes: d887c52d6ae4 ("crypto: algif_aead - overhaul memory management")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Ayush Sawal <ayush.sawal@chelsio.com>
    Signed-off-by: Atul Gupta <atul.gupta@chelsio.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Ayush Sawal <ayush.sawal@chelsio.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b161fccec2120511edc840797594cd01ecf872d
Author: Christian Lamparter <chunkeey@gmail.com>
Date:   Thu Oct 31 17:14:38 2019 +0100

    crypto: crypto4xx - fix double-free in crypto4xx_destroy_sdr
    
    commit 746c908c4d72e49068ab216c3926d2720d71a90d upstream.
    
    This patch fixes a crash that can happen during probe
    when the available dma memory is not enough (this can
    happen if the crypto4xx is built as a module).
    
    The descriptor window mapping would end up being free'd
    twice, once in crypto4xx_build_pdr() and the second time
    in crypto4xx_destroy_sdr().
    
    Fixes: 5d59ad6eea82 ("crypto: crypto4xx - fix crypto4xx_build_pdr, crypto4xx_build_sdr leak")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd606fb8f575ec2eaca138d9b3ba3b5131d9a875
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Mon Nov 18 18:58:26 2019 +0100

    KVM: x86: fix presentation of TSX feature in ARCH_CAPABILITIES
    
    commit cbbaa2727aa3ae9e0a844803da7cef7fd3b94f2b upstream.
    
    KVM does not implement MSR_IA32_TSX_CTRL, so it must not be presented
    to the guests.  It is also confusing to have !ARCH_CAP_TSX_CTRL_MSR &&
    !RTM && ARCH_CAP_TAA_NO: lack of MSR_IA32_TSX_CTRL suggests TSX was not
    hidden (it actually was), yet the value says that TSX is not vulnerable
    to microarchitectural data sampling.  Fix both.
    
    Cc: stable@vger.kernel.org
    Tested-by: Jim Mattson <jmattson@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5591672b05c953ec07f6aec042d25d58956e553
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Mon Nov 18 12:23:00 2019 -0500

    KVM: x86: do not modify masked bits of shared MSRs
    
    commit de1fca5d6e0105c9d33924e1247e2f386efc3ece upstream.
    
    "Shared MSRs" are guest MSRs that are written to the host MSRs but
    keep their value until the next return to userspace.  They support
    a mask, so that some bits keep the host value, but this mask is
    only used to skip an unnecessary MSR write and the value written
    to the MSR is always the guest MSR.
    
    Fix this and, while at it, do not update smsr->values[slot].curr if
    for whatever reason the wrmsr fails.  This should only happen due to
    reserved bits, so the value written to smsr->values[slot].curr
    will not match when the user-return notifier and the host value will
    always be restored.  However, it is untidy and in rare cases this
    can actually avoid spurious WRMSRs on return to userspace.
    
    Cc: stable@vger.kernel.org
    Reviewed-by: Jim Mattson <jmattson@google.com>
    Tested-by: Jim Mattson <jmattson@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 69d2eb21297bffd1a2ba6807ac030b42f73dce1c
Author: Zenghui Yu <yuzenghui@huawei.com>
Date:   Tue Oct 29 15:19:19 2019 +0800

    KVM: arm/arm64: vgic: Don't rely on the wrong pending table
    
    commit ca185b260951d3b55108c0b95e188682d8a507b7 upstream.
    
    It's possible that two LPIs locate in the same "byte_offset" but target
    two different vcpus, where their pending status are indicated by two
    different pending tables.  In such a scenario, using last_byte_offset
    optimization will lead KVM relying on the wrong pending table entry.
    Let us use last_ptr instead, which can be treated as a byte index into
    a pending table and also, can be vcpu specific.
    
    Fixes: 280771252c1b ("KVM: arm64: vgic-v3: KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES")
    Cc: stable@vger.kernel.org
    Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Acked-by: Eric Auger <eric.auger@redhat.com>
    Link: https://lore.kernel.org/r/20191029071919.177-4-yuzenghui@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48612e9cc0a0c8c676c59f6a3ae0d9b46f7ccee7
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Oct 4 13:22:51 2019 +0300

    drm/i810: Prevent underflow in ioctl
    
    commit 4f69851fbaa26b155330be35ce8ac393e93e7442 upstream.
    
    The "used" variables here come from the user in the ioctl and it can be
    negative.  It could result in an out of bounds write.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Link: https://patchwork.freedesktop.org/patch/msgid/20191004102251.GC823@mwanda
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d0c2dc1a3a54cecddaafe2b5aa29f4698b6d912
Author: Jan Kara <jack@suse.cz>
Date:   Tue Nov 5 17:44:07 2019 +0100

    jbd2: Fix possible overflow in jbd2_log_space_left()
    
    commit add3efdd78b8a0478ce423bb9d4df6bd95e8b335 upstream.
    
    When number of free space in the journal is very low, the arithmetic in
    jbd2_log_space_left() could underflow resulting in very high number of
    free blocks and thus triggering assertion failure in transaction commit
    code complaining there's not enough space in the journal:
    
    J_ASSERT(journal->j_free > 1);
    
    Properly check for the low number of free blocks.
    
    CC: stable@vger.kernel.org
    Reviewed-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20191105164437.32602-1-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc9a5fd2f3053eeb6ce6e0b7d9d5ec4af13a0cd3
Author: Tejun Heo <tj@kernel.org>
Date:   Mon Nov 4 15:54:29 2019 -0800

    kernfs: fix ino wrap-around detection
    
    commit e23f568aa63f64cd6b355094224cc9356c0f696b upstream.
    
    When the 32bit ino wraps around, kernfs increments the generation
    number to distinguish reused ino instances.  The wrap-around detection
    tests whether the allocated ino is lower than what the cursor but the
    cursor is pointing to the next ino to allocate so the condition never
    triggers.
    
    Fix it by remembering the last ino and comparing against that.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Fixes: 4a3ef68acacf ("kernfs: implement i_generation")
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: stable@vger.kernel.org # v4.14+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd6eec4ce9d9f027ce5ece1fa880ad4eb516bdd9
Author: Jouni Hogander <jouni.hogander@unikie.com>
Date:   Wed Nov 27 08:40:26 2019 +0200

    can: slcan: Fix use-after-free Read in slcan_open
    
    commit 9ebd796e24008f33f06ebea5a5e6aceb68b51794 upstream.
    
    Slcan_open doesn't clean-up device which registration failed from the
    slcan_devs device list. On next open this list is iterated and freed
    device is accessed. Fix this by calling slc_free_netdev in error path.
    
    Driver/net/can/slcan.c is derived from slip.c. Use-after-free error was
    identified in slip_open by syzboz. Same bug is in slcan.c. Here is the
    trace from the Syzbot slip report:
    
    __dump_stack lib/dump_stack.c:77 [inline]
    dump_stack+0x197/0x210 lib/dump_stack.c:118
    print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374
    __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506
    kasan_report+0x12/0x20 mm/kasan/common.c:634
    __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
    sl_sync drivers/net/slip/slip.c:725 [inline]
    slip_open+0xecd/0x11b7 drivers/net/slip/slip.c:801
    tty_ldisc_open.isra.0+0xa3/0x110 drivers/tty/tty_ldisc.c:469
    tty_set_ldisc+0x30e/0x6b0 drivers/tty/tty_ldisc.c:596
    tiocsetd drivers/tty/tty_io.c:2334 [inline]
    tty_ioctl+0xe8d/0x14f0 drivers/tty/tty_io.c:2594
    vfs_ioctl fs/ioctl.c:46 [inline]
    file_ioctl fs/ioctl.c:509 [inline]
    do_vfs_ioctl+0xdb6/0x13e0 fs/ioctl.c:696
    ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
    __do_sys_ioctl fs/ioctl.c:720 [inline]
    __se_sys_ioctl fs/ioctl.c:718 [inline]
    __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
    do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
    entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    Fixes: ed50e1600b44 ("slcan: Fix memory leak in error path")
    Cc: Wolfgang Grandegger <wg@grandegger.com>
    Cc: Marc Kleine-Budde <mkl@pengutronix.de>
    Cc: David Miller <davem@davemloft.net>
    Cc: Oliver Hartkopp <socketcan@hartkopp.net>
    Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
    Signed-off-by: Jouni Hogander <jouni.hogander@unikie.com>
    Cc: linux-stable <stable@vger.kernel.org> # >= v5.4
    Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c68ab0f33eabef9c9d4206cec2fb6509d1d5b621
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Fri Nov 22 12:42:20 2019 -0800

    tty: vt: keyboard: reject invalid keycodes
    
    commit b2b2dd71e0859436d4e05b2f61f86140250ed3f8 upstream.
    
    Do not try to handle keycodes that are too big, otherwise we risk doing
    out-of-bounds writes:
    
    BUG: KASAN: global-out-of-bounds in clear_bit include/asm-generic/bitops-instrumented.h:56 [inline]
    BUG: KASAN: global-out-of-bounds in kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline]
    BUG: KASAN: global-out-of-bounds in kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495
    Write of size 8 at addr ffffffff89a1b2d8 by task syz-executor108/1722
    ...
     kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline]
     kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495
     input_to_handler+0x3b6/0x4c0 drivers/input/input.c:118
     input_pass_values.part.0+0x2e3/0x720 drivers/input/input.c:145
     input_pass_values drivers/input/input.c:949 [inline]
     input_set_keycode+0x290/0x320 drivers/input/input.c:954
     evdev_handle_set_keycode_v2+0xc4/0x120 drivers/input/evdev.c:882
     evdev_do_ioctl drivers/input/evdev.c:1150 [inline]
    
    In this case we were dealing with a fuzzed HID device that declared over
    12K buttons, and while HID layer should not be reporting to us such big
    keycodes, we should also be defensive and reject invalid data ourselves as
    well.
    
    Reported-by: syzbot+19340dff067c2d3835c0@syzkaller.appspotmail.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20191122204220.GA129459@dtor-ws
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0082adb163f54a6aff72e456fd0b789cb7c3216c
Author: Pavel Shilovsky <pshilov@microsoft.com>
Date:   Thu Oct 31 14:18:57 2019 -0700

    CIFS: Fix SMB2 oplock break processing
    
    commit fa9c2362497fbd64788063288dc4e74daf977ebb upstream.
    
    Even when mounting modern protocol version the server may be
    configured without supporting SMB2.1 leases and the client
    uses SMB2 oplock to optimize IO performance through local caching.
    
    However there is a problem in oplock break handling that leads
    to missing a break notification on the client who has a file
    opened. It latter causes big latencies to other clients that
    are trying to open the same file.
    
    The problem reproduces when there are multiple shares from the
    same server mounted on the client. The processing code tries to
    match persistent and volatile file ids from the break notification
    with an open file but it skips all share besides the first one.
    Fix this by looking up in all shares belonging to the server that
    issued the oplock break.
    
    Cc: Stable <stable@vger.kernel.org>
    Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit defbcd1f8e852b403985a6e12abea2909fbbdbaa
Author: Pavel Shilovsky <pshilov@microsoft.com>
Date:   Wed Nov 27 16:18:39 2019 -0800

    CIFS: Fix NULL-pointer dereference in smb2_push_mandatory_locks
    
    commit 6f582b273ec23332074d970a7fb25bef835df71f upstream.
    
    Currently when the client creates a cifsFileInfo structure for
    a newly opened file, it allocates a list of byte-range locks
    with a pointer to the new cfile and attaches this list to the
    inode's lock list. The latter happens before initializing all
    other fields, e.g. cfile->tlink. Thus a partially initialized
    cifsFileInfo structure becomes available to other threads that
    walk through the inode's lock list. One example of such a thread
    may be an oplock break worker thread that tries to push all
    cached byte-range locks. This causes NULL-pointer dereference
    in smb2_push_mandatory_locks() when accessing cfile->tlink:
    
    [598428.945633] BUG: kernel NULL pointer dereference, address: 0000000000000038
    ...
    [598428.945749] Workqueue: cifsoplockd cifs_oplock_break [cifs]
    [598428.945793] RIP: 0010:smb2_push_mandatory_locks+0xd6/0x5a0 [cifs]
    ...
    [598428.945834] Call Trace:
    [598428.945870]  ? cifs_revalidate_mapping+0x45/0x90 [cifs]
    [598428.945901]  cifs_oplock_break+0x13d/0x450 [cifs]
    [598428.945909]  process_one_work+0x1db/0x380
    [598428.945914]  worker_thread+0x4d/0x400
    [598428.945921]  kthread+0x104/0x140
    [598428.945925]  ? process_one_work+0x380/0x380
    [598428.945931]  ? kthread_park+0x80/0x80
    [598428.945937]  ret_from_fork+0x35/0x40
    
    Fix this by reordering initialization steps of the cifsFileInfo
    structure: initialize all the fields first and then add the new
    byte-range lock list to the inode's lock list.
    
    Cc: Stable <stable@vger.kernel.org>
    Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
    Reviewed-by: Aurelien Aptel <aaptel@suse.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f14270c56125e0a3e80d89138a4c80f1a8c461b4
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Mon Sep 2 22:52:52 2019 +0800

    x86/PCI: Avoid AMD FCH XHCI USB PME# from D0 defect
    
    commit 7e8ce0e2b036dbc6617184317983aea4f2c52099 upstream.
    
    The AMD FCH USB XHCI Controller advertises support for generating PME#
    while in D0.  When in D0, it does signal PME# for USB 3.0 connect events,
    but not for USB 2.0 or USB 1.1 connect events, which means the controller
    doesn't wake correctly for those events.
    
      00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller [1022:7914] (rev 20) (prog-if 30 [XHCI])
            Subsystem: Dell FCH USB XHCI Controller [1028:087e]
            Capabilities: [50] Power Management version 3
                    Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
    
    Clear PCI_PM_CAP_PME_D0 in dev->pme_support to indicate the device will not
    assert PME# from D0 so we don't rely on it.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203673
    Link: https://lore.kernel.org/r/20190902145252.32111-1-kai.heng.feng@canonical.com
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ed71720e46c881d803bcb2403e48556841515ce
Author: Navid Emamdoost <navid.emamdoost@gmail.com>
Date:   Thu Nov 21 14:01:11 2019 -0600

    Input: Fix memory leak in psxpad_spi_probe
    
    In the implementation of psxpad_spi_probe() the allocated memory for
    pdev is leaked if psxpad_spi_init_ff() or input_register_polled_device()
    fail. The solution is using device managed allocation, like the one used
    for pad. Perform the allocation using
    devm_input_allocate_polled_device().
    
    Fixes: 8be193c7b1f4 ("Input: add support for PlayStation 1/2 joypads connected via SPI")
    Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
    Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60c5e0c603dd8edd1b571ae322edf2a0c0f47fc0
Author: Mike Leach <mike.leach@linaro.org>
Date:   Mon Nov 4 11:12:42 2019 -0700

    coresight: etm4x: Fix input validation for sysfs.
    
    commit 2fe6899e36aa174abefd017887f9cfe0cb60c43a upstream.
    
    A number of issues are fixed relating to sysfs input validation:-
    
    1) bb_ctrl_store() - incorrect compare of bit select field to absolute
    value. Reworked per ETMv4 specification.
    2) seq_event_store() - incorrect mask value - register has two
    event values.
    3) cyc_threshold_store() - must mask with max before checking min
    otherwise wrapped values can set illegal value below min.
    4) res_ctrl_store() - update to mask off all res0 bits.
    
    Reviewed-by: Leo Yan <leo.yan@linaro.org>
    Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Mike Leach <mike.leach@linaro.org>
    Fixes: a77de2637c9eb ("coresight: etm4x: moving sysFS entries to a dedicated file")
    Cc: stable <stable@vger.kernel.org> # 4.9+
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Link: https://lore.kernel.org/r/20191104181251.26732-6-mathieu.poirier@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7455c3af9d61dc914b1c2f86d76fa7bc644989ee
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Dec 2 09:36:15 2019 -0800

    Input: goodix - add upside-down quirk for Teclast X89 tablet
    
    commit df5b5e555b356662a5e4a23c6774fdfce8547d54 upstream.
    
    The touchscreen on the Teclast X89 is mounted upside down in relation to
    the display orientation (the touchscreen itself is mounted upright, but the
    display is mounted upside-down). Add a quirk for this so that we send
    coordinates which match the display orientation.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Bastien Nocera <hadess@hadess.net>
    Link: https://lore.kernel.org/r/20191202085636.6650-1-hdegoede@redhat.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d5b244e0d7a66fb0bace68d9f6cb8634c8a04481
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Mon Dec 2 10:08:12 2019 -0800

    Input: synaptics-rmi4 - don't increment rmiaddr for SMBus transfers
    
    commit a284e11c371e446371675668d8c8120a27227339 upstream.
    
    This increment of rmi_smbus in rmi_smb_read/write_block() causes
    garbage to be read/written.
    
    The first read of SMB_MAX_COUNT bytes is fine, but after that
    it is nonsense. Trial-and-error showed that by dropping the
    increment of rmiaddr everything is fine and the F54 function
    properly works.
    
    I tried a hack with rmi_smb_write_block() as well (writing to the
    same F54 touchpad data area, then reading it back), and that
    suggests that there too the rmiaddr increment has to be dropped.
    It makes sense that if it has to be dropped for read, then it has
    to be dropped for write as well.
    
    It looks like the initial work with F54 was done using i2c, not smbus,
    and it seems nobody ever tested F54 with smbus. The other functions
    all read/write less than SMB_MAX_COUNT as far as I can tell, so this
    issue was never noticed with non-F54 functions.
    
    With this change I can read out the touchpad data correctly on my
    Lenovo X1 Carbon 6th Gen laptop.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Link: https://lore.kernel.org/r/8dd22e21-4933-8e9c-a696-d281872c8de7@xs4all.nl
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fac3956db21c30b89f73163b2090c66eee6b0834
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Mon Dec 2 09:37:00 2019 -0800

    Input: synaptics-rmi4 - re-enable IRQs in f34v7_do_reflash
    
    commit 86bcd3a12999447faad60ec59c2d64d18d8e61ac upstream.
    
    F34 is a bit special as it reinitializes the device and related driver
    structs during the firmware update. This clears the fn_irq_mask which
    will then prevent F34 from receiving further interrupts, leading to
    timeouts during the firmware update. Make sure to reinitialize the
    IRQ enables at the appropriate times.
    
    The issue is in F34 code, but the commit in the fixes tag exposed the
    issue, as before this commit things would work by accident.
    
    Fixes: 363c53875aef (Input: synaptics-rmi4 - avoid processing unknown IRQs)
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Link: https://lore.kernel.org/r/20191129133514.23224-1-l.stach@pengutronix.de
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ddcd540fba9b774d9f220b844f930de8f72a1b8
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Fri Nov 22 16:17:08 2019 -0800

    Input: synaptics - switch another X1 Carbon 6 to RMI/SMbus
    
    commit fc1156f373e3927e0dcf06678906c367588bfdd6 upstream.
    
    Some Lenovo X1 Carbon Gen 6 laptops report LEN0091. Add this
    to the smbus_pnp_ids list.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20191119105118.54285-2-hverkuil-cisco@xs4all.nl
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eed584fbd956d25ee8bf5b515d750a94537e4a38
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Wed Nov 20 16:20:35 2019 +0800

    ALSA: hda - Add mute led support for HP ProBook 645 G4
    
    commit e190de6941db14813032af87873f5550ad5764fe upstream.
    
    Mic mute led does not work on HP ProBook 645 G4.
    We can use CXT_FIXUP_MUTE_LED_GPIO fixup to support it.
    
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20191120082035.18937-1-kai.heng.feng@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a76606d8a830a02ea3a7aef6f5362ceccb8749f
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Dec 4 15:48:24 2019 +0100

    ALSA: pcm: oss: Avoid potential buffer overflows
    
    commit 4cc8d6505ab82db3357613d36e6c58a297f57f7c upstream.
    
    syzkaller reported an invalid access in PCM OSS read, and this seems
    to be an overflow of the internal buffer allocated for a plugin.
    Since the rate plugin adjusts its transfer size dynamically, the
    calculation for the chained plugin might be bigger than the given
    buffer size in some extreme cases, which lead to such an buffer
    overflow as caught by KASAN.
    
    Fix it by limiting the max transfer size properly by checking against
    the destination size in each plugin transfer callback.
    
    Reported-by: syzbot+f153bde47a62e0b05f83@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20191204144824.17801-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9437a4c887bfc2f4bcf8eb0c28eb1e4019acbb3
Author: Kailang Yang <kailang@realtek.com>
Date:   Tue Nov 26 17:04:23 2019 +0800

    ALSA: hda/realtek - Dell headphone has noise on unmute for ALC236
    
    commit e1e8c1fdce8b00fce08784d9d738c60ebf598ebc upstream.
    
    headphone have noise even the volume is very small.
    Let it fill up pcbeep hidden register to default value.
    The issue was gone.
    
    Fixes: 4344aec84bd8 ("ALSA: hda/realtek - New codec support for ALC256")
    Fixes: 736f20a70608 ("ALSA: hda/realtek - Add support for ALC236/ALC3204")
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/9ae47f23a64d4e41a9c81e263cd8a250@realtek.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79804ebaa31a911a2a5b8267055b8248b5d99bdf
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Tue Nov 12 11:49:04 2019 +0100

    fuse: verify attributes
    
    commit eb59bd17d2fa6e5e84fba61a5ebdea984222e6d5 upstream.
    
    If a filesystem returns negative inode sizes, future reads on the file were
    causing the cpu to spin on truncate_pagecache.
    
    Create a helper to validate the attributes.  This now does two things:
    
     - check the file mode
     - check if the file size fits in i_size without overflowing
    
    Reported-by: Arijit Banerjee <arijit@rubrik.com>
    Fixes: d8a5ba45457e ("[PATCH] FUSE - core")
    Cc: <stable@vger.kernel.org> # v2.6.14
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c48b0da2b514a715591c5ed3819c8ae828b06e6
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Tue Nov 12 11:49:04 2019 +0100

    fuse: verify nlink
    
    commit c634da718db9b2fac201df2ae1b1b095344ce5eb upstream.
    
    When adding a new hard link, make sure that i_nlink doesn't overflow.
    
    Fixes: ac45d61357e8 ("fuse: fix nlink after unlink")
    Cc: <stable@vger.kernel.org> # v3.4
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c294780a80b0fb2e92ab4e2fd584029ced994186
Author: Xuewei Zhang <xueweiz@google.com>
Date:   Thu Oct 3 17:12:43 2019 -0700

    sched/fair: Scale bandwidth quota and period without losing quota/period ratio precision
    
    commit 4929a4e6faa0f13289a67cae98139e727f0d4a97 upstream.
    
    The quota/period ratio is used to ensure a child task group won't get
    more bandwidth than the parent task group, and is calculated as:
    
      normalized_cfs_quota() = [(quota_us << 20) / period_us]
    
    If the quota/period ratio was changed during this scaling due to
    precision loss, it will cause inconsistency between parent and child
    task groups.
    
    See below example:
    
    A userspace container manager (kubelet) does three operations:
    
     1) Create a parent cgroup, set quota to 1,000us and period to 10,000us.
     2) Create a few children cgroups.
     3) Set quota to 1,000us and period to 10,000us on a child cgroup.
    
    These operations are expected to succeed. However, if the scaling of
    147/128 happens before step 3, quota and period of the parent cgroup
    will be changed:
    
      new_quota: 1148437ns,   1148us
     new_period: 11484375ns, 11484us
    
    And when step 3 comes in, the ratio of the child cgroup will be
    104857, which will be larger than the parent cgroup ratio (104821),
    and will fail.
    
    Scaling them by a factor of 2 will fix the problem.
    
    Tested-by: Phil Auld <pauld@redhat.com>
    Signed-off-by: Xuewei Zhang <xueweiz@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Phil Auld <pauld@redhat.com>
    Cc: Anton Blanchard <anton@ozlabs.org>
    Cc: Ben Segall <bsegall@google.com>
    Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Cc: Juri Lelli <juri.lelli@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Vincent Guittot <vincent.guittot@linaro.org>
    Fixes: 2e8e19226398 ("sched/fair: Limit sched_cfs_period_timer() loop to avoid hard lockup")
    Link: https://lkml.kernel.org/r/20191004001243.140897-1-xueweiz@google.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6d9175b95504d28045909631514d06660b4b1a9a
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Dec 6 10:20:16 2019 -0800

    tcp: exit if nothing to retransmit on RTO timeout
    
    Two upstream commits squashed together for v4.14 stable :
    
     commit 88f8598d0a302a08380eadefd09b9f5cb1c4c428 upstream.
    
      Previously TCP only warns if its RTO timer fires and the
      retransmission queue is empty, but it'll cause null pointer
      reference later on. It's better to avoid such catastrophic failure
      and simply exit with a warning.
    
    Squashed with "tcp: refactor tcp_retransmit_timer()" :
    
     commit 0d580fbd2db084a5c96ee9c00492236a279d5e0f upstream.
    
      It appears linux-4.14 stable needs a backport of commit
      88f8598d0a30 ("tcp: exit if nothing to retransmit on RTO timeout")
    
      Since tcp_rtx_queue_empty() is not in pre 4.15 kernels,
      let's refactor tcp_retransmit_timer() to only use tcp_rtx_queue_head()
    
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Neal Cardwell <ncardwell@google.com>
    Reviewed-by: Soheil Hassas Yeganeh <soheil@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 29ccdd181733e631003c291f26811cf3b07c9ae7
Author: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
Date:   Fri Dec 7 14:00:11 2018 +0000

    net: aquantia: fix RSS table and key sizes
    
    [ Upstream commit 474fb1150d40780e71f0b569aeac4f375df3af3d ]
    
    Set RSS indirection table and RSS hash key sizes to their real size.
    
    Signed-off-by: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
    Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5ca05d9f18dbe4aa15f1417431d371c526be0776
Author: Helen Fornazier <helen.koike@collabora.com>
Date:   Fri Dec 7 12:56:41 2018 -0500

    media: vimc: fix start stream when link is disabled
    
    [ Upstream commit e159b6074c82fe31b79aad672e02fa204dbbc6d8 ]
    
    If link is disabled, media_entity_remote_pad returns NULL, causing a
    NULL pointer deference.
    Ignore links that are not enabled instead.
    
    Signed-off-by: Helen Koike <helen.koike@collabora.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 36e6f0ec773437ddc086e2b1b2ff71aa038e46b4
Author: Rob Herring <robh@kernel.org>
Date:   Thu Dec 6 13:11:42 2018 -0600

    ARM: dts: sunxi: Fix PMU compatible strings
    
    [ Upstream commit 5719ac19fc32d892434939c1756c2f9a8322e6ef ]
    
    "arm,cortex-a15-pmu" is not a valid fallback compatible string for an
    Cortex-A7 PMU, so drop it.
    
    Cc: Maxime Ripard <maxime.ripard@bootlin.com>
    Cc: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 24390936175399315ecfbdbd9aed5afe291b377a
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Fri Dec 7 03:52:43 2018 +0000

    usb: mtu3: fix dbginfo in qmu_tx_zlp_error_handler
    
    [ Upstream commit f770e3bc236ee954a3b4052bdf55739e26ee25db ]
    
    Fixes gcc '-Wunused-but-set-variable' warning:
    
    drivers/usb/mtu3/mtu3_qmu.c: In function 'qmu_tx_zlp_error_handler':
    drivers/usb/mtu3/mtu3_qmu.c:385:22: warning:
     variable 'req' set but not used [-Wunused-but-set-variable]
    
    It seems dbginfo original intention is print 'req' other than 'mreq'
    
    Acked-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7a15c302ad22cf20308b38aba13ad985690ebed3
Author: Qian Cai <cai@gmx.us>
Date:   Thu Nov 29 21:18:07 2018 -0500

    mlx4: Use snprintf instead of complicated strcpy
    
    [ Upstream commit 0fbc9b8b4ea3f688a5da141a64f97aa33ad02ae9 ]
    
    This fixes a compilation warning in sysfs.c
    
    drivers/infiniband/hw/mlx4/sysfs.c:360:2: warning: 'strncpy' output may be
    truncated copying 8 bytes from a string of length 31
    [-Wstringop-truncation]
    
    By eliminating the temporary stack buffer.
    
    Signed-off-by: Qian Cai <cai@gmx.us>
    Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c4e7247f99e600351bd499eb51ef1141a8b04091
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date:   Wed Nov 28 10:32:48 2018 -0800

    IB/hfi1: Close VNIC sdma_progress sleep window
    
    [ Upstream commit 18912c4524385dd6532c682cb9d4f6aa39ba8d47 ]
    
    The call to sdma_progress() is called outside the wait lock.
    
    In this case, there is a race condition where sdma_progress() can return
    false and the sdma_engine can idle.  If that happens, there will be no
    more sdma interrupts to cause the wakeup and the vnic_sdma xmit will hang.
    
    Fix by moving the lock to enclose the sdma_progress() call.
    
    Also, delete the tx_retry. The need for this was removed by:
    commit bcad29137a97 ("IB/hfi1: Serve the most starved iowait entry first")
    
    Fixes: 64551ede6cd1 ("IB/hfi1: VNIC SDMA support")
    Reviewed-by: Gary Leshner <Gary.S.Leshner@intel.com>
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d78aaa8896bb2b0dc2979e3e81142f1bebeabf7d
Author: Kaike Wan <kaike.wan@intel.com>
Date:   Wed Nov 28 10:19:04 2018 -0800

    IB/hfi1: Ignore LNI errors before DC8051 transitions to Polling state
    
    [ Upstream commit c1a797c0818e0122c7ec8422edd971cfec9b15ea ]
    
    When it is requested to change its physical state back to Offline while in
    the process to go up, DC8051 will set the ERROR field in the
    DC8051_DBG_ERR_INFO_SET_BY_8051 register. This ERROR field will remain
    until the next time when DC8051 transitions from Offline to Polling.
    Subsequently, when the host requests DC8051 to change its physical state
    to Polling again, it may receive a DC8051 interrupt with the stale ERROR
    field still in DC8051_DBG_ERR_INFO_SET_BY_8051. If the host link state has
    been changed to Polling, this stale ERROR will force the host to
    transition to Offline state, resulting in a vicious cycle of Polling
    ->Offline->Polling->Offline. On the other hand, if the host link state is
    still Offline when the stale ERROR is received, the stale ERROR will be
    ignored, and the link will come up correctly.  This patch implements the
    correct behavior by changing host link state to Polling only after DC8051
    changes its physical state to Polling.
    
    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Krzysztof Goreczny <krzysztof.goreczny@intel.com>
    Signed-off-by: Kaike Wan <kaike.wan@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de4f3fa347e8d3f7e1cb60389aa2e7d843c17bce
Author: Nir Dotan <nird@mellanox.com>
Date:   Thu Dec 6 17:44:52 2018 +0000

    mlxsw: spectrum_router: Relax GRE decap matching check
    
    [ Upstream commit da93d2913fdf43d5cde3c5a53ac9cc29684d5c7c ]
    
    GRE decap offload is configured when local routes prefix correspond to the
    local address of one of the offloaded GRE tunnels. The matching check was
    found to be too strict, such that for a flat GRE configuration, in which
    the overlay and underlay traffic share the same non-default VRF, decap flow
    was not offloaded.
    
    Relax the check for decap flow offloading. A match occurs if the local
    address of the tunnel matches the local route address while both share the
    same VRF table.
    
    Fixes: 4607f6d26950 ("mlxsw: spectrum_router: Support IPv4 underlay decap")
    Signed-off-by: Nir Dotan <nird@mellanox.com>
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2fa2b92afedab6464599db563e574811219d621d
Author: Jonathan Marek <jonathan@marek.ca>
Date:   Wed Nov 21 21:32:25 2018 -0500

    firmware: qcom: scm: fix compilation error when disabled
    
    [ Upstream commit 16ad9501b1f2edebe24f8cf3c09da0695871986b ]
    
    This fixes the case when CONFIG_QCOM_SCM is not enabled, and linux/errno.h
    has not been included previously.
    
    Signed-off-by: Jonathan Marek <jonathan@marek.ca>
    Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Andy Gross <andy.gross@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d3ad47d79540c889c45879082063f6482480063e
Author: Andreas Pape <ap@ca-pape.de>
Date:   Fri Nov 23 11:14:54 2018 -0500

    media: stkwebcam: Bugfix for wrong return values
    
    [ Upstream commit 3c28b91380dd1183347d32d87d820818031ebecf ]
    
    usb_control_msg returns in case of a successfully sent message the number
    of sent bytes as a positive number. Don't use this value as a return value
    for stk_camera_read_reg, as a non-zero return value is used as an error
    condition in some cases when stk_camera_read_reg is called.
    
    Signed-off-by: Andreas Pape <ap@ca-pape.de>
    Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ebded7823e7f1aedf9d8b47a5cb006119895a9d2
Author: Dmitry Safonov <dima@arista.com>
Date:   Thu Nov 1 00:24:48 2018 +0000

    tty: Don't block on IO when ldisc change is pending
    
    [ Upstream commit c96cf923a98d1b094df9f0cf97a83e118817e31b ]
    
    There might be situations where tty_ldisc_lock() has blocked, but there
    is already IO on tty and it prevents line discipline changes.
    It might theoretically turn into dead-lock.
    
    Basically, provide more priority to pending tty_ldisc_lock() than to
    servicing reads/writes over tty.
    
    User-visible issue was reported by Mikulas where on pa-risc with
    Debian 5 reboot took either 80 seconds, 3 minutes or 3:25 after proper
    locking in tty_reopen().
    
    Cc: Jiri Slaby <jslaby@suse.com>
    Reported-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Dmitry Safonov <dima@arista.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b7b8d8e667d0e5b4074bdb68e0faed2218b764de
Author: zhengbin <zhengbin13@huawei.com>
Date:   Fri Nov 30 16:04:25 2018 +0800

    nfsd: Return EPERM, not EACCES, in some SETATTR cases
    
    [ Upstream commit 255fbca65137e25b12bced18ec9a014dc77ecda0 ]
    
    As the man(2) page for utime/utimes states, EPERM is returned when the
    second parameter of utime or utimes is not NULL, the caller's effective UID
    does not match the owner of the file, and the caller is not privileged.
    
    However, in a NFS directory mounted from knfsd, it will return EACCES
    (from nfsd_setattr-> fh_verify->nfsd_permission).  This patch fixes
    that.
    
    Signed-off-by: zhengbin <zhengbin13@huawei.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 37ac694eeab669ec86c55e3dcca065920b5b4b3e
Author: Aaro Koskinen <aaro.koskinen@iki.fi>
Date:   Tue Dec 4 22:12:17 2018 +0200

    MIPS: OCTEON: cvmx_pko_mem_debug8: use oldest forward compatible definition
    
    [ Upstream commit 1c6121c39677175bd372076020948e184bad4b6b ]
    
    cn58xx is compatible with cn50xx, so use the latter.
    
    Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    [paul.burton@mips.com: s/cn52xx/cn50xx/ in commit message.]
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: James Hogan <jhogan@kernel.org>
    Cc: linux-mips@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c6a0ade2549d5a09474143a7b7b5ad9c1e7add20
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Thu Nov 29 11:06:37 2018 +0100

    clk: renesas: r8a77995: Correct parent clock of DU
    
    [ Upstream commit 515b2915ee08060ad4f6a3b3de38c5c2c5258e8b ]
    
    According to the R-Car Gen3 Hardware Manual Rev 1.00, the parent clock
    of the DU module clocks on R-Car D3 is S1D1.
    
    Fixes: d71e851d82c6cfe5 ("clk: renesas: cpg-mssr: Add R8A77995 support")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Acked-by: Stephen Boyd <sboyd@kernel.org>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1725a88d8f5f2b7826206a11fd91a64ce25e43d0
Author: Joel Stanley <joel@jms.id.au>
Date:   Tue Dec 4 09:37:46 2018 +1030

    powerpc/math-emu: Update macros from GCC
    
    [ Upstream commit b682c8692442711684befe413cf93cf01c5324ea ]
    
    The add_ssaaaa, sub_ddmmss, umul_ppmm and udiv_qrnnd macros originate
    from GCC's longlong.h which in turn was copied from GMP's longlong.h a
    few decades ago.
    
    This was found when compiling with clang:
    
       arch/powerpc/math-emu/fnmsub.c:46:2: error: invalid use of a cast in a
       inline asm context requiring an l-value: remove the cast or build with
       -fheinous-gnu-extensions
               FP_ADD_D(R, T, B);
               ^~~~~~~~~~~~~~~~~
       ...
    
       ./arch/powerpc/include/asm/sfp-machine.h:283:27: note: expanded from
       macro 'sub_ddmmss'
                      : "=r" ((USItype)(sh)),                                  \
                              ~~~~~~~~~~^~~
    
    Segher points out: this was fixed in GCC over 16 years ago
    ( https://gcc.gnu.org/r56600 ), and in GMP (where it comes from)
    presumably before that.
    
    Update the add_ssaaaa, sub_ddmmss, umul_ppmm and udiv_qrnnd macros to
    the latest GCC version in order to git rid of the invalid casts. These
    were taken as-is from GCC's longlong in order to make future syncs
    obvious. Other parts of sfp-machine.h were left as-is as the file
    contains more features than present in longlong.h.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/260
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c22e4aea49acdb156a2126a67a1464584fb88e8
Author: Kees Cook <keescook@chromium.org>
Date:   Mon Dec 3 16:39:01 2018 -0800

    pstore/ram: Avoid NULL deref in ftrace merging failure path
    
    [ Upstream commit 8665569e97dd52920713b95675409648986b5b0d ]
    
    Given corruption in the ftrace records, it might be possible to allocate
    tmp_prz without assigning prz to it, but still marking it as needing to
    be freed, which would cause at least a NULL dereference.
    
    smatch warnings:
    fs/pstore/ram.c:340 ramoops_pstore_read() error: we previously assumed 'prz' could be null (see line 255)
    
    https://lists.01.org/pipermail/kbuild-all/2018-December/055528.html
    
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Fixes: 2fbea82bbb89 ("pstore: Merge per-CPU ftrace records into one")
    Cc: "Joel Fernandes (Google)" <joel@joelfernandes.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0f1e0e050f0b91e9892dd516b4a240a5ccfc7a55
Author: Erez Alfasi <ereza@mellanox.com>
Date:   Sun Dec 2 17:40:25 2018 +0200

    net/mlx4_core: Fix return codes of unsupported operations
    
    [ Upstream commit 95aac2cdafd8c8298c9b2589c52f44db0d824e0e ]
    
    Functions __set_port_type and mlx4_check_port_params returned
    -EINVAL while the proper return code is -EOPNOTSUPP as a
    result of an unsupported operation. All drivers should generate
    this and all users should check for it when detecting an
    unsupported functionality.
    
    Signed-off-by: Erez Alfasi <ereza@mellanox.com>
    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f569ce4a1072da843d078d4013e1b446ed4af5c3
Author: David Teigland <teigland@redhat.com>
Date:   Mon Dec 3 15:27:37 2018 -0600

    dlm: fix invalid cluster name warning
    
    [ Upstream commit 3595c559326d0b660bb088a88e22e0ca630a0e35 ]
    
    The warning added in commit 3b0e761ba83
      "dlm: print log message when cluster name is not set"
    
    did not account for the fact that lockspaces created
    from userland do not supply a cluster name, so bogus
    warnings are printed every time a userland lockspace
    is created.
    
    Signed-off-by: David Teigland <teigland@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f8c0bf3b812161aedeb6f7050e470a207db9fdf3
Author: Rob Herring <robh@kernel.org>
Date:   Mon Dec 3 13:12:48 2018 -0600

    ARM: dts: realview: Fix some more duplicate regulator nodes
    
    [ Upstream commit f3b2f758ec1e6cdb13c925647cbd8ad4938b78fb ]
    
    There's a bug in dtc in checking for duplicate node names when there's
    another section (e.g. "/ { };"). In this case, skeleton.dtsi provides
    another section. Upon removal of skeleton.dtsi, the dtb fails to build
    due to a duplicate node 'fixedregulator@0'. As both nodes were pretty
    much the same 3.3V fixed regulator, it hasn't really mattered. Fix this
    by renaming the nodes to something unique. In the process, drop the
    unit-address which shouldn't be present wtihout reg property.
    
    Signed-off-by: Rob Herring <robh@kernel.org>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Olof Johansson <olof@lixom.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a4adade5dde697f778a3dd44ef7fb000671a1bca
Author: Chen-Yu Tsai <wens@csie.org>
Date:   Fri Nov 30 13:33:28 2018 +0800

    clk: sunxi-ng: h3/h5: Fix CSI_MCLK parent
    
    [ Upstream commit 7bb7d29cffdd24bf419516d14b6768591e74069e ]
    
    The third parent of CSI_MCLK is PLL_PERIPH1, not PLL_PERIPH0.
    Fix it.
    
    Fixes: 0577e4853bfb ("clk: sunxi-ng: Add H3 clocks")
    Acked-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1864086ee0766a905f0e09b81de7d1fd32b44aff
Author: Daniel Mack <daniel@zonque.org>
Date:   Sat Dec 1 14:54:51 2018 +0100

    ARM: dts: pxa: clean up USB controller nodes
    
    [ Upstream commit c40ad24254f1dbd54f2df5f5f524130dc1862122 ]
    
    PXA25xx SoCs don't have a USB controller, so drop the node from the
    common pxa2xx.dtsi base file. Both pxa27x and pxa3xx have a dedicated
    node already anyway.
    
    While at it, unify the names for the nodes across all pxa platforms.
    
    Signed-off-by: Daniel Mack <daniel@zonque.org>
    Reported-by: Sergey Yanovich <ynvich@gmail.com>
    Link: https://patchwork.kernel.org/patch/8375421/
    Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1c1dc30605fd146e9acfdb92c595d99f7861d14b
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Sun Nov 18 21:18:30 2018 +0100

    mtd: fix mtd_oobavail() incoherent returned value
    
    [ Upstream commit 4348433d8c0234f44adb6e12112e69343f50f0c5 ]
    
    mtd_oobavail() returns either mtd->oovabail or mtd->oobsize. Both
    values are unsigned 32-bit entities, so there is no reason to pretend
    returning a signed one.
    
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a87bd630bc84586f181f07a90a1f2ad715148a06
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date:   Thu Nov 22 08:11:54 2018 +0900

    kbuild: fix single target build for external module
    
    [ Upstream commit e07db28eea38ed4e332b3a89f3995c86b713cb5b ]
    
    Building a single target in an external module fails due to missing
    .tmp_versions directory.
    
    For example,
    
      $ make -C /lib/modules/$(uname -r)/build M=$PWD foo.o
    
    will fail in the following way:
    
      CC [M]  /home/masahiro/foo/foo.o
    /bin/sh: 1: cannot create /home/masahiro/foo/.tmp_versions/foo.mod: Directory nonexistent
    
    This is because $(cmd_crmodverdir) is executed only before building
    /, %/, %.ko single targets of external modules. Create .tmp_versions
    in the 'prepare' target.
    
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4d64f26e2a30dd4aab623182a38cbb90b5460b73
Author: Paul Walmsley <paul.walmsley@sifive.com>
Date:   Wed Nov 21 13:14:13 2018 -0800

    modpost: skip ELF local symbols during section mismatch check
    
    [ Upstream commit a4d26f1a0958bb1c2b60c6f1e67c6f5d43e2647b ]
    
    During development of a serial console driver with a gcc 8.2.0
    toolchain for RISC-V, the following modpost warning appeared:
    
    ----
    WARNING: vmlinux.o(.data+0x19b10): Section mismatch in reference from the variable .LANCHOR1 to the function .init.text:sifive_serial_console_setup()
    The variable .LANCHOR1 references
    the function __init sifive_serial_console_setup()
    If the reference is valid then annotate the
    variable with __init* or __refdata (see linux/init.h) or name the variable:
    *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
    ----
    
    ".LANCHOR1" is an ELF local symbol, automatically created by gcc's section
    anchor generation code:
    
    https://gcc.gnu.org/onlinedocs/gccint/Anchored-Addresses.html
    
    https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/varasm.c;h=cd9591a45617464946dcf9a126dde277d9de9804;hb=9fb89fa845c1b2e0a18d85ada0b077c84508ab78#l7473
    
    This was verified by compiling the kernel with -fno-section-anchors
    and observing that the ".LANCHOR1" ELF local symbol disappeared, and
    modpost no longer warned about the section mismatch.  The serial
    driver code idiom triggering the warning is standard Linux serial
    driver practice that has a specific whitelist inclusion in modpost.c.
    
    I'm neither a modpost nor an ELF expert, but naively, it doesn't seem
    useful for modpost to report section mismatch warnings caused by ELF
    local symbols by default.  Local symbols have compiler-generated
    names, and thus bypass modpost's whitelisting algorithm, which relies
    on the presence of a non-autogenerated symbol name.  This increases
    the likelihood that false positive warnings will be generated (as in
    the above case).
    
    Thus, disable section mismatch reporting on ELF local symbols.  The
    rationale here is similar to that of commit 2e3a10a1551d ("ARM: avoid
    ARM binutils leaking ELF local symbols") and of similar code already
    present in modpost.c:
    
    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/mod/modpost.c?h=v4.19-rc4&id=7876320f88802b22d4e2daf7eb027dd14175a0f8#n1256
    
    This third version of the patch implements a suggestion from Masahiro
    Yamada <yamada.masahiro@socionext.com> to restructure the code as an
    additional pattern matching step inside secref_whitelist(), and
    further improves the patch description.
    
    Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
    Signed-off-by: Paul Walmsley <paul@pwsan.com>
    Acked-by: Sam Ravnborg <sam@ravnborg.org>
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2e117bb2abf3e5722d6984e358166c674a70250d
Author: Yuchung Cheng <ycheng@google.com>
Date:   Wed Nov 28 16:06:45 2018 -0800

    tcp: fix SNMP TCP timeout under-estimation
    
    [ Upstream commit e1561fe2dd69dc5dddd69bd73aa65355bdfb048b ]
    
    Previously the SNMP TCPTIMEOUTS counter has inconsistent accounting:
    1. It counts all SYN and SYN-ACK timeouts
    2. It counts timeouts in other states except recurring timeouts and
       timeouts after fast recovery or disorder state.
    
    Such selective accounting makes analysis difficult and complicated. For
    example the monitoring system needs to collect many other SNMP counters
    to infer the total amount of timeout events. This patch makes TCPTIMEOUTS
    counter simply counts all the retransmit timeout (SYN or data or FIN).
    
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3dc07e00451b6f8a9021c7de214d620c7ba12f26
Author: Yuchung Cheng <ycheng@google.com>
Date:   Wed Nov 28 16:06:44 2018 -0800

    tcp: fix SNMP under-estimation on failed retransmission
    
    [ Upstream commit ec641b39457e17774313b66697a8a1dc070257bd ]
    
    Previously the SNMP counter LINUX_MIB_TCPRETRANSFAIL is not counting
    the TSO/GSO properly on failed retransmission. This patch fixes that.
    
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5b7ff64f5040ced0118fce42b9b95230214ff70a
Author: Yuchung Cheng <ycheng@google.com>
Date:   Wed Nov 28 16:06:43 2018 -0800

    tcp: fix off-by-one bug on aborting window-probing socket
    
    [ Upstream commit 3976535af0cb9fe34a55f2ffb8d7e6b39a2f8188 ]
    
    Previously there is an off-by-one bug on determining when to abort
    a stalled window-probing socket. This patch fixes that so it is
    consistent with tcp_write_timeout().
    
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7422156369281a11f0ccbbb70de9d33979942429
Author: Rob Herring <robh@kernel.org>
Date:   Thu Nov 29 19:05:47 2018 -0600

    ARM: dts: realview-pbx: Fix duplicate regulator nodes
    
    [ Upstream commit 7f4b001b7f6e0480b5bdab9cd8ce1711e43e5cb5 ]
    
    There's a bug in dtc in checking for duplicate node names when there's
    another section (e.g. "/ { };"). In this case, skeleton.dtsi provides
    another section. Upon removal of skeleton.dtsi, the dtb fails to build
    due to a duplicate node 'fixedregulator@0'. As both nodes were pretty
    much the same 3.3V fixed regulator, it hasn't really mattered. Fix this
    by renaming the nodes to something unique. In the process, drop the
    unit-address which shouldn't be present wtihout reg property.
    
    Cc: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Olof Johansson <olof@lixom.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ed65deea2aa2df9ba3fa035eb8ef33709064388
Author: Lubomir Rintel <lkundrak@v3.sk>
Date:   Wed Nov 28 18:53:06 2018 +0100

    ARM: dts: mmp2: fix the gpio interrupt cell number
    
    [ Upstream commit 400583983f8a8e95ec02c9c9e2b50188753a87fb ]
    
    gpio-pxa uses two cell to encode the interrupt source: the pin number
    and the trigger type. Adjust the device node accordingly.
    
    Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
    Acked-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Olof Johansson <olof@lixom.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 87989217d997b31478e5e43e97886fcfbefa7469
Author: Martin Schiller <ms@dev.tdt.de>
Date:   Tue Nov 27 09:50:28 2018 +0100

    net/x25: fix null_x25_address handling
    
    [ Upstream commit 06137619f061f498c2924f6543fa45b7d39f0501 ]
    
    o x25_find_listener(): the compare for the null_x25_address was wrong.
       We have to check the x25_addr of the listener socket instead of the
       x25_addr of the incomming call.
    
     o x25_bind(): it was not possible to bind a socket to null_x25_address
    
    Signed-off-by: Martin Schiller <ms@dev.tdt.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fdda36a1dd007f0bbfccc1f3f4b71a4d5a5e0ced
Author: Martin Schiller <ms@dev.tdt.de>
Date:   Tue Nov 27 09:50:27 2018 +0100

    net/x25: fix called/calling length calculation in x25_parse_address_block
    
    [ Upstream commit d449ba3d581ed29f751a59792fdc775572c66904 ]
    
    The length of the called and calling address was not calculated
    correctly (BCD encoding).
    
    Signed-off-by: Martin Schiller <ms@dev.tdt.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2fe0edbd6f53f186cfbf85cc7b2c5e28fb9bfd53
Author: Neil Armstrong <narmstrong@baylibre.com>
Date:   Wed Nov 7 11:45:50 2018 +0100

    arm64: dts: meson-gxl-khadas-vim: fix GPIO lines names
    
    [ Upstream commit 5b78012636f537344bd551934387f5772c38ba80 ]
    
    The gpio line names were set in the pinctrl node instead of the gpio node,
    at the time it was merged, it worked, but was obviously wrong.
    This patch moves the properties to the gpio nodes.
    
    Fixes: 60795933b709 ("ARM64: dts: meson-gxl-khadas-vim: Add GPIO lines names")
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 24c97fa190b836c659221fdb83d67756b40875e6
Author: Neil Armstrong <narmstrong@baylibre.com>
Date:   Wed Nov 7 11:45:49 2018 +0100

    arm64: dts: meson-gxbb-odroidc2: fix GPIO lines names
    
    [ Upstream commit 2165b006b65d609140dafafcb14cce5a4aaacbab ]
    
    The gpio line names were set in the pinctrl node instead of the gpio node,
    at the time it was merged, it worked, but was obviously wrong.
    This patch moves the properties to the gpio nodes.
    
    Fixes: b03c7d6438bb ("ARM64: dts: meson-gxbb-odroidc2: Add GPIO lines names")
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 214f7f64f028ce219e3d25445c42c30d0994d582
Author: Neil Armstrong <narmstrong@baylibre.com>
Date:   Wed Nov 7 11:45:48 2018 +0100

    arm64: dts: meson-gxbb-nanopi-k2: fix GPIO lines names
    
    [ Upstream commit f0783f5edb52af14ecaae6c5ce4f38e0a358f5d8 ]
    
    The gpio line names were set in the pinctrl node instead of the gpio node,
    at the time it was merged, it worked, but was obviously wrong.
    This patch moves the properties to the gpio nodes.
    
    Fixes: 12ada0513d7a ("ARM64: dts: meson-gxbb-nanopi-k2: Add GPIO lines names")
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cf974fcbb73ab049649af31f72a04e6cb44bf87c
Author: Neil Armstrong <narmstrong@baylibre.com>
Date:   Wed Nov 7 11:45:47 2018 +0100

    arm64: dts: meson-gxl-libretech-cc: fix GPIO lines names
    
    [ Upstream commit 11fa9774612decea87144d7f950a9c53a4fe3050 ]
    
    The gpio line names were set in the pinctrl node instead of the gpio node,
    at the time it was merged, it worked, but was obviously wrong.
    This patch moves the properties to the gpio nodes.
    
    Fixes: 47884c5c746e ("ARM64: dts: meson-gxl-libretech-cc: Add GPIO lines names")
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb1957e583d2c85fd747057a3a26e3b4038383f5
Author: Aaro Koskinen <aaro.koskinen@iki.fi>
Date:   Mon Nov 19 21:46:41 2018 +0200

    ARM: OMAP1/2: fix SoC name printing
    
    [ Upstream commit 04a92358b3964988c78dfe370a559ae550383886 ]
    
    Currently we get extra newlines on OMAP1/2 when the SoC name is printed:
    
    [    0.000000] OMAP1510
    [    0.000000]  revision 2 handled as 15xx id: bc058c9b93111a16
    
    [    0.000000] OMAP2420
    [    0.000000]
    
    Fix by using pr_cont.
    
    Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 917f32f65876caf0984cad6fda41054f835416ea
Author: Young_X <YangX92@hotmail.com>
Date:   Tue Nov 27 06:33:16 2018 +0000

    ASoC: au8540: use 64-bit arithmetic instead of 32-bit
    
    [ Upstream commit cd7fdc45bc69a62b4e22c6e875f1f1aea566256d ]
    
    Add suffix ULL to constant 256 in order to give the compiler complete
    information about the proper arithmetic to use.
    
    Notice that such constant is used in a context that expects an
    expression of type u64 (64 bits, unsigned) and the following
    expression is currently being evaluated using 32-bit arithmetic:
    
        256 * fs * 2 * mclk_src_scaling[i].param
    
    Signed-off-by: Young_X <YangX92@hotmail.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9a889ad76bd7db3fb6ef09511d27818970d4bae6
Author: Scott Mayhew <smayhew@redhat.com>
Date:   Tue Nov 6 13:35:08 2018 -0500

    nfsd: fix a warning in __cld_pipe_upcall()
    
    [ Upstream commit b493fd31c0b89d9453917e977002de58bebc3802 ]
    
    __cld_pipe_upcall() emits a "do not call blocking ops when
    !TASK_RUNNING" warning due to the dput() call in rpc_queue_upcall().
    Fix it by using a completion instead of hand coding the wait.
    
    Signed-off-by: Scott Mayhew <smayhew@redhat.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c02b397e8a82297738dd8cc48bc072f27297ccf7
Author: Clément Péron <peron.clem@gmail.com>
Date:   Tue Oct 9 13:28:37 2018 +0200

    ARM: debug: enable UART1 for socfpga Cyclone5
    
    [ Upstream commit f6628486c8489e91c513b62608f89ccdb745600d ]
    
    Cyclone5 and Arria10 doesn't have the same memory map for UART1.
    
    Split the SOCFPGA_UART1 into 2 options to allow debugging on UART1 for Cyclone5.
    
    Signed-off-by: Clément Péron <peron.clem@gmail.com>
    Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 180b858fb530f4c38b3668da16b22f35461a8c70
Author: Wen Yang <wen.yang99@zte.com.cn>
Date:   Wed Nov 28 15:25:00 2018 +0800

    dlm: NULL check before kmem_cache_destroy is not needed
    
    [ Upstream commit f31a89692830061bceba8469607e4e4b0f900159 ]
    
    kmem_cache_destroy(NULL) is safe, so removes NULL check before
    freeing the mem. This patch also fix ifnullfree.cocci warnings.
    
    Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
    Signed-off-by: David Teigland <teigland@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 51d1d9badf233dc5337ecdc5ed6e5c064eea836f
Author: Maxime Ripard <maxime.ripard@bootlin.com>
Date:   Wed Nov 7 10:58:01 2018 +0100

    ARM: dts: sun8i: v3s: Change pinctrl nodes to avoid warning
    
    [ Upstream commit 438a44ce7e51ce571f942433c6c7cb87c4c0effd ]
    
    All our pinctrl nodes were using a node name convention with a unit-address
    to differentiate the different muxing options. However, since those nodes
    didn't have a reg property, they were generating warnings in DTC.
    
    In order to accomodate for this, convert the old nodes to the syntax we've
    been using for the new SoCs, including removing the letter suffix of the
    node labels to the bank of those pins to make things more readable.
    
    Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
    Acked-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 17fd415ec51c124bb3fc5be5db538611557d7007
Author: Maxime Ripard <maxime.ripard@bootlin.com>
Date:   Fri Sep 7 16:00:22 2018 +0200

    ARM: dts: sun5i: a10s: Fix HDMI output DTC warning
    
    [ Upstream commit ed5fc60b909427be6ca93d3e07a0a5f296d7000a ]
    
    Our HDMI output endpoint on the A10s DTSI has a warning under DTC: "graph
    node has single child node 'endpoint', #address-cells/#size-cells are not
    necessary". Fix this by removing those properties.
    
    Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
    Acked-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 13c82e5c5979adcde94dd02ae9015616d06d280c
Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date:   Tue Nov 27 07:35:34 2018 +0000

    ASoC: rsnd: tidyup registering method for rsnd_kctrl_new()
    
    [ Upstream commit 9c698e8481a15237a5b1db5f8391dd66d59e42a4 ]
    
    Current rsnd dvc.c is using flags to avoid duplicating register for
    MIXer case. OTOH, commit e894efef9ac7 ("ASoC: core: add support to card
    rebind") allows to rebind sound card without rebinding all drivers.
    
    Because of above patch and dvc.c flags, it can't re-register kctrl if
    only sound card was rebinded, because dvc is keeping old flags.
    (Of course it will be no problem if rsnd driver also be rebinded,
    but it is not purpose of above patch).
    
    This patch checks current card registered kctrl when registering.
    In MIXer case, it can avoid duplicate register if card already has same
    kctrl. In rebind case, it can re-register kctrl because card registered
    kctl had been removed when unbinding.
    
    This patch is updated version of commit b918f1bc7f1ce ("ASoC: rsnd: DVC
    kctrl sets once")
    
    Reported-by: Nguyen Viet Dung <dung.nguyen.aj@renesas.com>
    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Tested-by: Nguyen Viet Dung <dung.nguyen.aj@renesas.com>
    Cc: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 43e4008bc77f9b6a674e9b471cb5719d4966d174
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Mon Nov 26 11:36:52 2018 -0500

    lockd: fix decoding of TEST results
    
    [ Upstream commit b8db159239b3f51e2b909859935cc25cb3ff3eed ]
    
    We fail to advance the read pointer when reading the stat.oh field that
    identifies the lock-holder in a TEST result.
    
    This turns out not to matter if the server is knfsd, which always
    returns a zero-length field.  But other servers (Ganesha is an example)
    may not do this.  The result is bad values in fcntl F_GETLK results.
    
    Fix this.
    
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ed799aa6288884ff34ea5bdb3d13d38086b54a83
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Wed Nov 14 18:29:13 2018 +0100

    i2c: imx: don't print error message on probe defer
    
    [ Upstream commit fece4978510e43f09c8cd386fee15210e8c68493 ]
    
    Probe deferral is a normal operating condition in the probe function,
    so don't spam the log with an error in this case.
    
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b287fd473e054a9d0cbc625ca96343e870a61a5e
Author: Stefan Agner <stefan@agner.ch>
Date:   Wed Nov 14 18:49:38 2018 +0100

    serial: imx: fix error handling in console_setup
    
    [ Upstream commit 63fd4b94b948c14eeb27a3bbf50ea0f7f0593bad ]
    
    The ipg clock only needs to be unprepared in case preparing
    per clock fails. The ipg clock has already disabled at the point.
    
    Fixes: 1cf93e0d5488 ("serial: imx: remove the uart_console() check")
    Signed-off-by: Stefan Agner <stefan@agner.ch>
    Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3e919ae954cc93e1ce379191045ad1660d94412d
Author: Colin Ian King <colin.king@canonical.com>
Date:   Sat Nov 24 12:34:10 2018 +0000

    altera-stapl: check for a null key before strcasecmp'ing it
    
    [ Upstream commit 9ccb645683ef46e3c52c12c088a368baa58447d4 ]
    
    Currently the null check on key is occurring after the strcasecmp on
    the key, hence there is a potential null pointer dereference on key.
    Fix this by checking if key is null first. Also replace the == 0
    check on strcasecmp with just the ! operator.
    
    Detected by CoverityScan, CID#1248787 ("Dereference before null check")
    
    Fixes: fa766c9be58b ("[media] Altera FPGA firmware download module")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4d9021f2d4310c248481b815deb6c7ffb31981d8
Author: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Date:   Wed Aug 29 23:29:21 2018 +0200

    dma-mapping: fix return type of dma_set_max_seg_size()
    
    [ Upstream commit c9d76d0655c06b8c1f944e46c4fd9e9cf4b331c0 ]
    
    The function dma_set_max_seg_size() can return either 0 on success or
    -EIO on error. Change its return type from unsigned int to int to
    capture this.
    
    Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 616b460b9eb2fafaa2707c07ed73a9b448a1a126
Author: David Miller <davem@davemloft.net>
Date:   Mon Nov 26 14:52:18 2018 -0800

    sparc: Correct ctx->saw_frame_pointer logic.
    
    [ Upstream commit e2ac579a7a18bcd9e8cf14cf42eac0b8a2ba6c4b ]
    
    We need to initialize the frame pointer register not just if it is
    seen as a source operand, but also if it is seen as the destination
    operand of a store or an atomic instruction (which effectively is a
    source operand).
    
    This is exercised by test_verifier's "non-invalid fp arithmetic"
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 06f891d78348d389955365d4c199f827ff617723
Author: Sahitya Tummala <stummala@codeaurora.org>
Date:   Mon Nov 26 13:31:41 2018 +0530

    f2fs: fix to allow node segment for GC by ioctl path
    
    [ Upstream commit 08ac9a3870f6babb2b1fff46118536ca8a71ef19 ]
    
    Allow node type segments also to be GC'd via f2fs ioctl
    F2FS_IOC_GARBAGE_COLLECT_RANGE.
    
    Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 446815353148f9b07b26891cf81e56c652431dc1
Author: Otavio Salvador <otavio@ossystems.com.br>
Date:   Mon Nov 26 15:35:04 2018 -0200

    ARM: dts: rockchip: Assign the proper GPIO clocks for rv1108
    
    [ Upstream commit efc2e0bd9594060915696a418564aefd0270b1d6 ]
    
    It is not correct to assign the 24MHz clock oscillator to the GPIO
    ports.
    
    Fix it by assigning the proper GPIO clocks instead.
    
    Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
    Tested-by: Fabio Berton <fabio.berton@ossystems.com.br>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5bfe5f331b905bdb4b2f8f17c5656d3be0ccb5d0
Author: Otavio Salvador <otavio@ossystems.com.br>
Date:   Mon Nov 26 15:35:03 2018 -0200

    ARM: dts: rockchip: Fix the PMU interrupt number for rv1108
    
    [ Upstream commit c955b7aec510145129ca7aaea6ecbf6d748f5ebf ]
    
    According to the Rockchip vendor tree the PMU interrupt number is
    76, so fix it accordingly.
    
    Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
    Tested-by: Fabio Berton <fabio.berton@ossystems.com.br>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 36e1c31a864db4402db215966d925d257169d874
Author: Yunlong Song <yunlong.song@huawei.com>
Date:   Tue Oct 30 20:37:55 2018 +0800

    f2fs: change segment to section in f2fs_ioc_gc_range
    
    [ Upstream commit 67b0e42b768c9ddc3fd5ca1aee3db815cfaa635c ]
    
    f2fs_ioc_gc_range skips blocks_per_seg each time, however, f2fs_gc moves
    blocks of section each time, so fix it from segment to section.
    
    Signed-off-by: Yunlong Song <yunlong.song@huawei.com>
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cb4174cc219c6586c76be3529b93c001951f1f07
Author: Yunlong Song <yunlong.song@huawei.com>
Date:   Wed Oct 24 16:08:30 2018 +0800

    f2fs: fix count of seg_freed to make sec_freed correct
    
    [ Upstream commit d6c66cd19ef322fe0d51ba09ce1b7f386acab04a ]
    
    When sbi->segs_per_sec > 1, and if some segno has 0 valid blocks before
    gc starts, do_garbage_collect will skip counting seg_freed++, and this
    will cause seg_freed < sbi->segs_per_sec and finally skip sec_freed++.
    
    Signed-off-by: Yunlong Song <yunlong.song@huawei.com>
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fd84a6d04ac436f218e8d1ebc71a9e32c8536dfa
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date:   Fri Nov 23 23:07:14 2018 +0300

    ACPI: fix acpi_find_child_device() invocation in acpi_preset_companion()
    
    [ Upstream commit f8c6d1402b89f22a3647705d63cbd171aa19a77e ]
    
    acpi_find_child_device() accepts boolean not pointer as last argument.
    
    Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
    [ rjw: Subject ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 28dd0f809425e88146072b9ef29fb46f0e909a74
Author: Brian Norris <briannorris@chromium.org>
Date:   Wed Nov 7 12:40:29 2018 -0800

    usb: dwc3: don't log probe deferrals; but do log other error codes
    
    [ Upstream commit 408d3ba006af57380fa48858b39f72fde6405031 ]
    
    It's not very useful to repeat a bunch of probe deferral errors. And
    it's also not very useful to log "failed" without telling the error
    code.
    
    Signed-off-by: Brian Norris <briannorris@chromium.org>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0b741a6cb29b4ff2c8b9bce0f9210274e5dab1c8
Author: Thinh Nguyen <thinh.nguyen@synopsys.com>
Date:   Wed Nov 7 17:55:19 2018 -0800

    usb: dwc3: debugfs: Properly print/set link state for HS
    
    [ Upstream commit 0d36dede457873404becd7c9cb9d0f2bcfd0dcd9 ]
    
    Highspeed device and below has different state names than superspeed and
    higher. Add proper checks and printouts of link states for highspeed and
    below.
    
    Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d91b55213fd41c116013dc39d9ec20f2011c9ea
Author: Christian Lamparter <chunkeey@gmail.com>
Date:   Sat Nov 17 17:17:21 2018 +0100

    dmaengine: dw-dmac: implement dma protection control setting
    
    [ Upstream commit 7b0c03ecc42fb223baf015877fee9d517c2c8af1 ]
    
    This patch adds a new device-tree property that allows to
    specify the dma protection control bits for the all of the
    DMA controller's channel uniformly.
    
    Setting the "correct" bits can have a huge impact on the
    PPC460EX and APM82181 that use this DMA engine in combination
    with a DesignWare' SATA-II core (sata_dwc_460ex driver).
    
    In the OpenWrt Forum, the user takimata reported that:
    |It seems your patch unleashed the full power of the SATA port.
    |Where I was previously hitting a really hard limit at around
    |82 MB/s for reading and 27 MB/s for writing, I am now getting this:
    |
    |root@OpenWrt:/mnt# time dd if=/dev/zero of=tempfile bs=1M count=1024
    |1024+0 records in
    |1024+0 records out
    |real    0m 13.65s
    |user    0m 0.01s
    |sys     0m 11.89s
    |
    |root@OpenWrt:/mnt# time dd if=tempfile of=/dev/null bs=1M count=1024
    |1024+0 records in
    |1024+0 records out
    |real    0m 8.41s
    |user    0m 0.01s
    |sys     0m 4.70s
    |
    |This means: 121 MB/s reading and 75 MB/s writing!
    |
    |The drive is a WD Green WD10EARX taken from an older MBL Single.
    |I repeated the test a few times with even larger files to rule out
    |any caching, I'm still seeing the same great performance. OpenWrt is
    |now completely on par with the original MBL firmware's performance.
    
    Another user And.short reported:
    |I can report that your fix worked! Boots up fine with two
    |drives even with more partitions, and no more reboot on
    |concurrent disk access!
    
    A closer look into the sata_dwc_460ex code revealed that
    the driver did initally set the correct protection control
    bits. However, this feature was lost when the sata_dwc_460ex
    driver was converted to the generic DMA driver framework.
    
    BugLink: https://forum.openwrt.org/t/wd-mybook-live-duo-two-disks/16195/55
    BugLink: https://forum.openwrt.org/t/wd-mybook-live-duo-two-disks/16195/50
    Fixes: 8b3444852a2b ("sata_dwc_460ex: move to generic DMA driver")
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a1723f99c3b9d19361b70660a29e0f93577a424
Author: Vinod Koul <vkoul@kernel.org>
Date:   Mon Nov 26 13:34:15 2018 +0530

    dmaengine: coh901318: Remove unused variable
    
    commit 35faaf0df42d285b40f8a6310afbe096720f7758 upstream.
    
    Commit 627469e4445b ("dmaengine: coh901318: Fix a double-lock bug") left
    flags variable unused, so remove it to fix the warning.
    
    drivers/dma/coh901318.c: In function 'coh901318_config':
    drivers/dma/coh901318.c:1805:16: warning: unused variable 'flags' [-Wunused-variable]
      unsigned long flags;
                    ^~~~~
    
    Fixes: 627469e4445b ("dmaengine: coh901318: Fix a double-lock bug")
    Reported-By: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3efad7bca56705b36f95d54422cdabf979113635
Author: Jia-Ju Bai <baijiaju1990@gmail.com>
Date:   Tue Nov 6 11:33:48 2018 +0800

    dmaengine: coh901318: Fix a double-lock bug
    
    [ Upstream commit 627469e4445b9b12e0229b3bdf8564d5ce384dd7 ]
    
    The function coh901318_alloc_chan_resources() calls spin_lock_irqsave()
    before calling coh901318_config().
    But coh901318_config() calls spin_lock_irqsave() again in its
    definition, which may cause a double-lock bug.
    
    Because coh901318_config() is only called by
    coh901318_alloc_chan_resources(), the bug fix is to remove the
    calls to spin-lock and -unlock functions in coh901318_config().
    
    Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fdb3d54ff703adbb6755be444bb9c5dd8f5d7d7b
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Tue Oct 16 03:44:20 2018 -0400

    media: cec: report Vendor ID after initialization
    
    [ Upstream commit 7f02ac77c768ba2bcdd0ce719c1fca0870ffe2fb ]
    
    The CEC specification requires that the Vendor ID (if any) is reported
    after a logical address was claimed.
    
    This was never done, so add support for this.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4fb387b553ec2f34eddd2ba64feaa406ff3a5845
Author: Hans Verkuil <hverkuil@xs4all.nl>
Date:   Wed Nov 14 08:25:53 2018 -0500

    media: pulse8-cec: return 0 when invalidating the logical address
    
    [ Upstream commit 2e84eb9affac43eeaf834992888b72426a8cd442 ]
    
    Return 0 when invalidating the logical address. The cec core produces
    a warning for drivers that do this.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Reported-by: Torbjorn Jansson <torbjorn.jansson@mbox200.swipnet.se>
    Signed-off-by: Hans Verkuil <hansverk@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 16d1e1892fffe5a319f24e14232d32ce47ce92a4
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Tue Nov 20 16:54:28 2018 +0100

    ARM: dts: exynos: Use Samsung SoC specific compatible for DWC2 module
    
    [ Upstream commit 6035cbcceb069f87296b3cd0bc4736ad5618bf47 ]
    
    DWC2 hardware module integrated in Samsung SoCs requires some quirks to
    operate properly, so use Samsung SoC specific compatible to notify driver
    to apply respective fixes.
    
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ecebcf49dded44233c891da987cc2b6224b2ff90
Author: Baruch Siach <baruch@tkos.co.il>
Date:   Mon Nov 19 14:34:02 2018 +0200

    rtc: dt-binding: abx80x: fix resistance scale
    
    [ Upstream commit 73852e56827f5cb5db9d6e8dd8191fc2f2e8f424 ]
    
    The abracon,tc-resistor property value is in kOhm.
    
    Signed-off-by: Baruch Siach <baruch@tkos.co.il>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aa3baaae553dc780b742f75b6a8424ed5a4afe31
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Wed Nov 14 18:19:51 2018 +0100

    rtc: max8997: Fix the returned value in case of error in 'max8997_rtc_read_alarm()'
    
    [ Upstream commit 41ef3878203cd9218d92eaa07df4b85a2cb128fb ]
    
    In case of error, we return 0.
    This is spurious and not consistent with the other functions of the driver.
    Propagate the error code instead.
    
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4a0b4f32bec9bf72b4914d70088f426a1cf123d5
Author: Vincent Chen <vincentc@andestech.com>
Date:   Thu Nov 22 11:14:38 2018 +0800

    math-emu/soft-fp.h: (_FP_ROUND_ZERO) cast 0 to void to fix warning
    
    [ Upstream commit 83312f1b7ae205dca647bf52bbe2d51303cdedfb ]
    
    _FP_ROUND_ZERO is defined as 0 and used as a statemente in macro
    _FP_ROUND. This generates "error: statement with no effect
    [-Werror=unused-value]" from gcc. Defining _FP_ROUND_ZERO as (void)0 to
    fix it.
    
    This modification is quoted from glibc 'commit <In libc/:>
    (8ed1e7d5894000c155acbd06f)'
    
    Signed-off-by: Vincent Chen <vincentc@andestech.com>
    Acked-by: Greentime Hu <greentime@andestech.com>
    Signed-off-by: Greentime Hu <greentime@andestech.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7d04bd4fe981cabd19eab3040a9facd4c74a8535
Author: Ursula Braun <ursula.braun@linux.ibm.com>
Date:   Tue Nov 20 16:46:43 2018 +0100

    net/smc: use after free fix in smc_wr_tx_put_slot()
    
    [ Upstream commit e438bae43c1e08e688c09c410407b59fc1c173b4 ]
    
    In smc_wr_tx_put_slot() field pend->idx is used after being
    cleared. That means always idx 0 is cleared in the wr_tx_mask.
    This results in a broken administration of available WR send
    payload buffers.
    
    Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 861e54e55ede06fc6f094baed3b3ab3fdeff64dd
Author: Aaro Koskinen <aaro.koskinen@iki.fi>
Date:   Thu Nov 22 00:37:29 2018 +0200

    MIPS: OCTEON: octeon-platform: fix typing
    
    [ Upstream commit 2cf1c8933dd93088cfb5f8f58b3bb9bbdf1781b9 ]
    
    Use correct type for fdt_property nameoff field.
    
    Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Patchwork: https://patchwork.linux-mips.org/patch/21204/
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: James Hogan <jhogan@kernel.org>
    Cc: linux-mips@linux-mips.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 427001403f3b12452553e727f1edb094f8b94b5c
Author: Dave Chinner <dchinner@redhat.com>
Date:   Mon Nov 19 13:31:10 2018 -0800

    iomap: sub-block dio needs to zeroout beyond EOF
    
    [ Upstream commit b450672fb66b4a991a5b55ee24209ac7ae7690ce ]
    
    If we are doing sub-block dio that extends EOF, we need to zero
    the unused tail of the block to initialise the data in it it. If we
    do not zero the tail of the block, then an immediate mmap read of
    the EOF block will expose stale data beyond EOF to userspace. Found
    with fsx running sub-block DIO sizes vs MAPREAD/MAPWRITE operations.
    
    Fix this by detecting if the end of the DIO write is beyond EOF
    and zeroing the tail if necessary.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f306329dcaf67ff3271488373b7aab2f52c39151
Author: Xue Chaojing <xuechaojing@huawei.com>
Date:   Tue Nov 20 05:47:33 2018 +0000

    net-next/hinic:fix a bug in set mac address
    
    [ Upstream commit 9ea72dc9430306b77c73a8a21beb51437cde1d6d ]
    
    In add_mac_addr(), if the MAC address is a muliticast address,
    it will not be set, which causes the network card fail to receive
    the multicast packet. This patch fixes this bug.
    
    Signed-off-by: Xue Chaojing <xuechaojing@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 62a176cb87456f1800ddf3bac406c8f9bba2c698
Author: Mark Brown <broonie@kernel.org>
Date:   Fri Nov 16 19:19:30 2018 -0800

    regulator: Fix return value of _set_load() stub
    
    [ Upstream commit f1abf67217de91f5cd3c757ae857632ca565099a ]
    
    The stub implementation of _set_load() returns a mode value which is
    within the bounds of valid return codes for success (the documentation
    just says that failures are negative error codes) but not sensible or
    what the actual implementation does.  Fix it to just return 0.
    
    Reported-by: Cheng-Yi Chiang <cychiang@chromium.org>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d8d7d24a87f3b37661027d2539e1582975261d01
Author: Katsuhiro Suzuki <katsuhiro@katsuster.net>
Date:   Sun Nov 18 13:18:02 2018 +0900

    clk: rockchip: fix ID of 8ch clock of I2S1 for rk3328
    
    [ Upstream commit df7b1f2e0a4ae0fceff261e29cde63dafcf2360f ]
    
    This patch fixes mistakes in HCLK_I2S1_8CH for running I2S1
    successfully.
    
    Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0209e997a2ed2ec2b382b2f8a4dd35125c249eb1
Author: Katsuhiro Suzuki <katsuhiro@katsuster.net>
Date:   Sun Nov 18 13:16:12 2018 +0900

    clk: rockchip: fix I2S1 clock gate register for rk3328
    
    [ Upstream commit 5c73ac2f8b70834a603eb2d92eb0bb464634420b ]
    
    This patch fixes definition of I2S1 clock gate register for rk3328.
    Current setting is not related I2S clocks.
      - bit6 of CRU_CLKGATE_CON0 means clk_ddrmon_en
      - bit6 of CRU_CLKGATE_CON1 means clk_i2s1_en
    
    Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2affb3126446e642d5f5ea80aff266844c925b8c
Author: Janne Huttunen <janne.huttunen@nokia.com>
Date:   Fri Nov 16 15:08:32 2018 -0800

    mm/vmstat.c: fix NUMA statistics updates
    
    [ Upstream commit 13c9aaf7fa01cc7600c61981609feadeef3354ec ]
    
    Scan through the whole array to see if an update is needed.  While we're
    at it, use sizeof() to be safe against any possible type changes in the
    future.
    
    The bug here is that we wouldn't sync per-cpu counters into global ones
    if there was an update of numa_stats for higher cpus.  Highly
    theoretical one though because it is much more probable that zone_stats
    are updated so we would refresh anyway.  So I wouldn't bother to mark
    this for stable, yet something nice to fix.
    
    [mhocko@suse.com: changelog enhancement]
    Link: http://lkml.kernel.org/r/1541601517-17282-1-git-send-email-janne.huttunen@nokia.com
    Fixes: 1d90ca897cb0 ("mm: update NUMA counter threshold size")
    Signed-off-by: Janne Huttunen <janne.huttunen@nokia.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1473301fc47c1975a5c31795c5d5d735c96862f2
Author: Shreeya Patel <shreeya.patel23498@gmail.com>
Date:   Sat Nov 17 04:19:07 2018 +0530

    Staging: iio: adt7316: Fix i2c data reading, set the data field
    
    [ Upstream commit 688cd642ba0c393344c802647848da5f0d925d0e ]
    
    adt7316_i2c_read function nowhere sets the data field.
    It is necessary to have an appropriate value for it.
    Hence, assign the value stored in 'ret' variable to data field.
    
    This is an ancient bug, and as no one seems to have noticed,
    probably no sense in applying it to stable.
    
    Signed-off-by: Shreeya Patel <shreeya.patel23498@gmail.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6aee64a401e4e5a1ca4351e5aa3336a77a3dab03
Author: Brian Masney <masneyb@onstation.org>
Date:   Sat Nov 10 20:34:11 2018 -0500

    pinctrl: qcom: ssbi-gpio: fix gpio-hog related boot issues
    
    [ Upstream commit 7ed07855773814337b9814f1c3e866df52ebce68 ]
    
    When attempting to setup up a gpio hog, device probing will repeatedly
    fail with -EPROBE_DEFERED errors. It is caused by a circular dependency
    between the gpio and pinctrl frameworks. If the gpio-ranges property is
    present in device tree, then the gpio framework will handle the gpio pin
    registration and eliminate the circular dependency.
    
    See Christian Lamparter's commit a86caa9ba5d7 ("pinctrl: msm: fix
    gpio-hog related boot issues") for a detailed commit message that
    explains the issue in much more detail. The code comment in this commit
    came from Christian's commit.
    
    I did not test this change against any hardware supported by this
    particular driver, however I was able to validate this same fix works
    for pinctrl-spmi-gpio.c using a LG Nexus 5 (hammerhead) phone.
    
    Signed-off-by: Brian Masney <masneyb@onstation.org>
    Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bb7c0f87426b3686ef1fe306b08fb7408ec2cd50
Author: Raveendra Padasalagi <raveendra.padasalagi@broadcom.com>
Date:   Tue Nov 6 13:58:58 2018 +0530

    crypto: bcm - fix normal/non key hash algorithm failure
    
    [ Upstream commit 4f0129d13e69bad0363fd75553fb22897b32c379 ]
    
    Remove setkey() callback handler for normal/non key
    hash algorithms and keep it for AES-CBC/CMAC which needs key.
    
    Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver")
    Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi@broadcom.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7291f13968761680615ab613f0832433b1123510
Author: Vitaly Chikunov <vt@altlinux.org>
Date:   Mon Nov 5 11:36:18 2018 +0300

    crypto: ecc - check for invalid values in the key verification test
    
    [ Upstream commit 2eb4942b6609d35a4e835644a33203b0aef7443d ]
    
    Currently used scalar multiplication algorithm (Matthieu Rivain, 2011)
    have invalid values for scalar == 1, n-1, and for regularized version
    n-2, which was previously not checked. Verify that they are not used as
    private keys.
    
    Signed-off-by: Vitaly Chikunov <vt@altlinux.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e3c914631c0e2130b8a84f326be2a4eda0ba834c
Author: Steffen Maier <maier@linux.ibm.com>
Date:   Thu Nov 8 15:44:57 2018 +0100

    scsi: zfcp: drop default switch case which might paper over missing case
    
    [ Upstream commit 0c902936e55cff9335b27ed632fc45e7115ced75 ]
    
    This was introduced with v4.18 commit 8c3d20aada70 ("scsi: zfcp: fix
    missing REC trigger trace for all objects in ERP_FAILED") but would now
    suppress helpful -Wswitch compiler warnings when building with W=1 such as
    the following forced example:
    
    drivers/s390/scsi/zfcp_erp.c: In function 'zfcp_erp_handle_failed':
    drivers/s390/scsi/zfcp_erp.c:126:2: warning: enumeration value 'ZFCP_ERP_ACTION_REOPEN_PORT_FORCED' not handled in switch [-Wswitch]
      switch (want) {
      ^~~~~~
    
    But then again, only with W=1 we would notice unhandled enum cases.
    Without the default cases and a missed unhandled enum case, the code might
    perform unforeseen things we might not want...
    
    As of today, we never run through the removed default case, so removing it
    is no functional change.  In the future, we never should run through a
    default case but introduce the necessary specific case(s) to handle new
    functionality.
    
    Signed-off-by: Steffen Maier <maier@linux.ibm.com>
    Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 08d28c1840082f88efe7fbe5ace5d5ae4f8a3305
Author: Andrew Lunn <andrew@lunn.ch>
Date:   Mon Nov 12 18:51:01 2018 +0100

    net: dsa: mv88e6xxx: Work around mv886e6161 SERDES missing MII_PHYSID2
    
    [ Upstream commit ddc49acb659a2d8bfc5fdb0de0ef197712c11d75 ]
    
    We already have a workaround for a couple of switches whose internal
    PHYs only have the Marvel OUI, but no model number. We detect such
    PHYs and give them the 6390 ID as the model number. However the
    mv88e6161 has two SERDES interfaces in the same address range as its
    internal PHYs. These suffer from the same problem, the Marvell OUI,
    but no model number. As a result, these SERDES interfaces were getting
    the same PHY ID as the mv88e6390, even though they are not PHYs, and
    the Marvell PHY driver was trying to drive them.
    
    Add a special case to stop this from happen.
    
    Reported-by: Chris Healy <Chris.Healy@zii.aero>
    Signed-off-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e12048b273d12f46cf83b98e81b7190bd96b1dc1
Author: Maciej W. Rozycki <macro@linux-mips.org>
Date:   Tue Nov 13 22:42:37 2018 +0000

    MIPS: SiByte: Enable ZONE_DMA32 for LittleSur
    
    [ Upstream commit 756d6d836dbfb04a5a486bc2ec89397aa4533737 ]
    
    The LittleSur board is marked for high memory support and therefore
    clearly must provide a way to have enough memory installed for some to
    be present outside the low 4GiB physical address range.  With the memory
    map of the BCM1250 SOC it has been built around it means over 1GiB of
    actual DRAM, as only the first 1GiB is mapped in the low 4GiB physical
    address range[1].
    
    Complement commit cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need
    DMA32.") then and also enable ZONE_DMA32 for LittleSur.
    
    References:
    
    [1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R,
        Broadcom Corporation, 21 Oct 2002, Section 3: "System Overview",
        "Memory Map", pp. 34-38
    
    Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Patchwork: https://patchwork.linux-mips.org/patch/21107/
    Fixes: cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need DMA32.")
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: linux-mips@linux-mips.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9ee10af9e9a53b27a9720f0cf5de7d94c3e92f93
Author: David Teigland <teigland@redhat.com>
Date:   Thu Nov 15 11:17:40 2018 -0600

    dlm: fix missing idr_destroy for recover_idr
    
    [ Upstream commit 8fc6ed9a3508a0435b9270c313600799d210d319 ]
    
    Which would leak memory for the idr internals.
    
    Signed-off-by: David Teigland <teigland@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 73623e6344356ea492215a5c05324595a8d11d9d
Author: John Keeping <john@metanate.com>
Date:   Tue Nov 13 15:24:13 2018 +0000

    ARM: dts: rockchip: Fix rk3288-rock2 vcc_flash name
    
    [ Upstream commit 03d9f8fa2bfdc791865624d3adc29070cf67814e ]
    
    There is no functional change from this, but it is confusing to find two
    copies of vcc_sys and no vcc_flash when looking in
    /sys/class/regulator/*/name.
    
    Signed-off-by: John Keeping <john@metanate.com>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 20e935cd77190802d4dbf2f57754884199023222
Author: Heiko Stuebner <heiko@sntech.de>
Date:   Thu Nov 15 12:17:30 2018 +0100

    clk: rockchip: fix rk3188 sclk_mac_lbtest parameter ordering
    
    [ Upstream commit ac8cb53829a6ba119082e067f5bc8fab3611ce6a ]
    
    Similar to commit a9f0c0e56371 ("clk: rockchip: fix rk3188 sclk_smc
    gate data") there is one other gate clock in the rk3188 clock driver
    with a similar wrong ordering, the sclk_mac_lbtest. So fix it as well.
    
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0759b23e9ed6fab0b5dc77debe755661aef65cdc
Author: Finley Xiao <finley.xiao@rock-chips.com>
Date:   Wed Nov 14 15:45:49 2018 +0000

    clk: rockchip: fix rk3188 sclk_smc gate data
    
    [ Upstream commit a9f0c0e563717b9f63b3bb1c4a7c2df436a206d9 ]
    
    Fix sclk_smc gate data.
    Change variable order, flags come before the register address.
    
    Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
    Signed-off-by: Johan Jonker <jbx9999@hotmail.com>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 095d4dbe73367911351406fac242dc016a7c5c41
Author: Mitch Williams <mitch.a.williams@intel.com>
Date:   Fri Oct 26 14:33:28 2018 -0700

    i40e: don't restart nway if autoneg not supported
    
    [ Upstream commit 7c3758f7839377ab67529cc50264a640636c47af ]
    
    On link types that do not support autoneg, we cannot attempt to restart
    nway negotiation. This results in a dead link that requires a power
    cycle to remedy.
    
    Fix this by saving off the autoneg state and checking this value before
    we try to restart nway.
    
    Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
    Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d4e3d38b904175860da5937e6afc541084063bd9
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Tue Nov 13 12:32:50 2018 +0100

    rtc: s3c-rtc: Avoid using broken ALMYEAR register
    
    [ Upstream commit 50c8aec4212a966817e868056efc9bfbb73337c0 ]
    
    (RTC,ALM)YEAR registers of Exynos built-in RTC device contains 3 BCD
    characters. s3c-rtc driver uses only 2 lower of them and supports years
    from 2000..2099 range. The third BCD value is typically set to 0, but it
    looks that handling of it is broken in the hardware. It sometimes
    defaults to a random (even non-BCD) value. This is not an issue
    for handling RTCYEAR register, because bcd2bin() properly handles only
    8bit values (2 BCD characters, the third one is skipped). The problem
    is however with ALMYEAR register and proper RTC alarm operation. When
    YEAREN bit is set for the configured alarm, RTC hardware triggers alarm
    only when ALMYEAR and RTCYEAR matches. This usually doesn't happen
    because of the random noise on the third BCD character.
    
    Fix this by simply skipping setting ALMYEAR register in alarm
    configuration. This workaround fixes broken alarm operation on Exynos
    built-in rtc device. My tests revealed that the issue happens on the
    following Exynos series: 3250, 4210, 4412, 5250 and 5410.
    
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3be734fe0ed7f1ab7d8c43ae9afed733a91c4200
Author: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Date:   Mon Nov 12 16:00:20 2018 +0200

    net: ethernet: ti: cpts: correct debug for expired txq skb
    
    [ Upstream commit d0e14c4d9bcef0d4aa1057d2959adaa6f18d4a17 ]
    
    The msgtype and seqid that is smth that belongs to event for
    comparison but not for staled txq skb.
    
    Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8437a3769abc01ff4d03be57983482fe94de96fd
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Tue Nov 13 16:38:47 2018 +0100

    extcon: max8997: Fix lack of path setting in USB device mode
    
    [ Upstream commit a2dc50914744eea9f83a70a5db0486be625e5dc0 ]
    
    MAX8997 driver disables automatic path selection from MicroUSB connector
    and manually sets path to either UART or USB lines. However the code for
    setting USB path worked only for USB host mode (when ID pin is set
    to ground). When standard USB cable (USB device mode) is connected, path
    registers are not touched. This means that once the non-USB accessory is
    connected to MAX8997-operated micro USB port, the path is no longer set
    to USB and USB device mode doesn't work. This patch fixes it by setting
    USB path both for USB and USB host modes.
    
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c466461b1d4070dd60e235a22fb014ec46946676
Author: Denis V. Lunev <den@openvz.org>
Date:   Tue Nov 13 20:39:50 2018 +0300

    dlm: fix possible call to kfree() for non-initialized pointer
    
    [ Upstream commit 58a923adf4d9aca8bf7205985c9c8fc531c65d72 ]
    
    Technically dlm_config_nodes() could return error and keep nodes
    uninitialized. After that on the fail path of we'll call kfree()
    for that uninitialized value.
    
    The patch is simple - we should just initialize nodes with NULL.
    
    Signed-off-by: Denis V. Lunev <den@openvz.org>
    Signed-off-by: David Teigland <teigland@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a6e4cbc18bb7ee5cff1aafd38965444ff84157a
Author: Jagan Teki <jagan@amarulasolutions.com>
Date:   Tue Nov 13 16:46:08 2018 +0530

    clk: sunxi-ng: a64: Fix gate bit of DSI DPHY
    
    [ Upstream commit ee678706e46d0d185c27cc214ad97828e0643159 ]
    
    DSI DPHY gate bit on MIPI DSI clock register is bit 15
    not bit 30.
    
    Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
    Acked-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 202d886f7eb77192d337f5ff982de69845edc424
Author: Moni Shoua <monis@mellanox.com>
Date:   Thu Nov 8 21:10:08 2018 +0200

    net/mlx5: Release resource on error flow
    
    [ Upstream commit 698114968a22f6c0c9f42e983ba033cc36bb7217 ]
    
    Fix reference counting leakage when the event handler aborts due to an
    unsupported event for the resource type.
    
    Fixes: a14c2d4beee5 ("net/mlx5_core: Warn on unsupported events of QP/RQ/SQ")
    Signed-off-by: Moni Shoua <monis@mellanox.com>
    Reviewed-by: Majd Dibbiny <majd@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e82dd54ec0a259c510528ad2ac90f133cd9b9c5d
Author: Vincent Whitchurch <vincent.whitchurch@axis.com>
Date:   Fri Nov 9 10:12:30 2018 +0100

    ARM: 8813/1: Make aligned 2-byte getuser()/putuser() atomic on ARMv6+
    
    [ Upstream commit 344eb5539abf3e0b6ce22568c03e86450073e097 ]
    
    getuser() and putuser() (and there underscored variants) use two
    strb[t]/ldrb[t] instructions when they are asked to get/put 16-bits.
    This means that the read/write is not atomic even when performed to a
    16-bit-aligned address.
    
    This leads to problems with vhost: vhost uses __getuser() to read the
    vring's 16-bit avail.index field, and if it happens to observe a partial
    update of the index, wrong descriptors will be used which will lead to a
    breakdown of the virtio communication.  A similar problem exists for
    __putuser() which is used to write to the vring's used.index field.
    
    The reason these functions use strb[t]/ldrb[t] is because strht/ldrht
    instructions did not exist until ARMv6T2/ARMv7.  So we should be easily
    able to fix this on ARMv7.  Also, since all ARMv6 processors also don't
    actually use the unprivileged instructions anymore for uaccess (since
    CONFIG_CPU_USE_DOMAINS is not used) we can easily fix them too.
    
    Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1830e1a276bd6c5d4355293195037e4e814f9ce0
Author: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Date:   Tue Jul 24 21:57:50 2018 +0300

    iwlwifi: mvm: Send non offchannel traffic via AP sta
    
    [ Upstream commit dc1aca22f8f38b7e2ad7b118db87404d11e68771 ]
    
    TDLS discovery response frame is a unicast direct frame to the peer.
    Since we don't have a STA for this peer, this frame goes through
    iwl_tx_skb_non_sta(). As the result aux_sta and some completely
    arbitrary queue would be selected for this frame, resulting in a queue
    hang.  Fix that by sending such frames through AP sta instead.
    
    Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9ae9efa0ae08a9f66ba82605e436d8bf316c796e
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Jul 4 23:12:33 2018 +0200

    iwlwifi: mvm: synchronize TID queue removal
    
    [ Upstream commit 06bc6f6ed4ae0246a5e52094d1be90906a1361c7 ]
    
    When we mark a TID as no longer having a queue, there's no
    guarantee the TX path isn't using this txq_id right now,
    having accessed it just before we reset the value. To fix
    this, add synchronize_net() when we change the TIDs from
    having a queue to not having one, so that we can then be
    sure that the TX path is no longer accessing that queue.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 968a8ada7e022f85eb51f47a8eb0949149d2d942
Author: Arjun Vynipadath <arjun@chelsio.com>
Date:   Fri Nov 9 14:52:01 2018 +0530

    cxgb4vf: fix memleak in mac_hlist initialization
    
    [ Upstream commit 24357e06ba511ad874d664d39475dbb01c1ca450 ]
    
    mac_hlist was initialized during adapter_up, which will be called
    every time a vf device is first brought up, or every time when device
    is brought up again after bringing all devices down. This means our
    state of previous list is lost, causing a memleak if entries are
    present in the list. To fix that, move list init to the condition
    that performs initial one time adapter setup.
    
    Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
    Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 66ba64dd77c3768ea64aec759ab7de521e1515f3
Author: Douglas Anderson <dianders@chromium.org>
Date:   Tue Oct 30 15:11:04 2018 -0700

    serial: core: Allow processing sysrq at port unlock time
    
    [ Upstream commit d6e1935819db0c91ce4a5af82466f3ab50d17346 ]
    
    Right now serial drivers process sysrq keys deep in their character
    receiving code.  This means that they've already grabbed their
    port->lock spinlock.  This can end up getting in the way if we've go
    to do serial stuff (especially kgdb) in response to the sysrq.
    
    Serial drivers have various hacks in them to handle this.  Looking at
    '8250_port.c' you can see that the console_write() skips locking if
    we're in the sysrq handler.  Looking at 'msm_serial.c' you can see
    that the port lock is dropped around uart_handle_sysrq_char().
    
    It turns out that these hacks aren't exactly perfect.  If you have
    lockdep turned on and use something like the 8250_port hack you'll get
    a splat that looks like:
    
      WARNING: possible circular locking dependency detected
      [...] is trying to acquire lock:
      ... (console_owner){-.-.}, at: console_unlock+0x2e0/0x5e4
    
      but task is already holding lock:
      ... (&port_lock_key){-.-.}, at: serial8250_handle_irq+0x30/0xe4
    
      which lock already depends on the new lock.
    
      the existing dependency chain (in reverse order) is:
    
      -> #1 (&port_lock_key){-.-.}:
             _raw_spin_lock_irqsave+0x58/0x70
             serial8250_console_write+0xa8/0x250
             univ8250_console_write+0x40/0x4c
             console_unlock+0x528/0x5e4
             register_console+0x2c4/0x3b0
             uart_add_one_port+0x350/0x478
             serial8250_register_8250_port+0x350/0x3a8
             dw8250_probe+0x67c/0x754
             platform_drv_probe+0x58/0xa4
             really_probe+0x150/0x294
             driver_probe_device+0xac/0xe8
             __driver_attach+0x98/0xd0
             bus_for_each_dev+0x84/0xc8
             driver_attach+0x2c/0x34
             bus_add_driver+0xf0/0x1ec
             driver_register+0xb4/0x100
             __platform_driver_register+0x60/0x6c
             dw8250_platform_driver_init+0x20/0x28
             ...
    
      -> #0 (console_owner){-.-.}:
             lock_acquire+0x1e8/0x214
             console_unlock+0x35c/0x5e4
             vprintk_emit+0x230/0x274
             vprintk_default+0x7c/0x84
             vprintk_func+0x190/0x1bc
             printk+0x80/0xa0
             __handle_sysrq+0x104/0x21c
             handle_sysrq+0x30/0x3c
             serial8250_read_char+0x15c/0x18c
             serial8250_rx_chars+0x34/0x74
             serial8250_handle_irq+0x9c/0xe4
             dw8250_handle_irq+0x98/0xcc
             serial8250_interrupt+0x50/0xe8
             ...
    
      other info that might help us debug this:
    
       Possible unsafe locking scenario:
    
             CPU0                    CPU1
             ----                    ----
        lock(&port_lock_key);
                                     lock(console_owner);
                                     lock(&port_lock_key);
        lock(console_owner);
    
       *** DEADLOCK ***
    
    The hack used in 'msm_serial.c' doesn't cause the above splats but it
    seems a bit ugly to unlock / lock our spinlock deep in our irq
    handler.
    
    It seems like we could defer processing the sysrq until the end of the
    interrupt handler right after we've unlocked the port.  With this
    scheme if a whole batch of sysrq characters comes in one irq then we
    won't handle them all, but that seems like it should be a fine
    compromise.
    
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4ad684ad733f1c8520cc3096a794407462cb1ade
Author: Wen Yang <wenyang@linux.alibaba.com>
Date:   Fri Nov 8 16:36:48 2019 +0800

    i2c: core: fix use after free in of_i2c_notify
    
    [ Upstream commit a4c2fec16f5e6a5fee4865e6e0e91e2bc2d10f37 ]
    
    We can't use "adap->dev" after it has been freed.
    
    Fixes: 5bf4fa7daea6 ("i2c: break out OF support into separate file")
    Signed-off-by: Wen Yang <wenyang@linux.alibaba.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit faf35651c75253903de694128520e248a4bd486b
Author: Chuhong Yuan <hslester96@gmail.com>
Date:   Thu Nov 14 23:43:24 2019 +0800

    net: ep93xx_eth: fix mismatch of request_mem_region in remove
    
    [ Upstream commit 3df70afe8d33f4977d0e0891bdcfb639320b5257 ]
    
    The driver calls release_resource in remove to match request_mem_region
    in probe, which is incorrect.
    Fix it by using the right one, release_mem_region.
    
    Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c4c09c87464eaf59bdb648d074414deb09d84936
Author: Chuhong Yuan <hslester96@gmail.com>
Date:   Wed Nov 13 14:38:47 2019 +0800

    rsxx: add missed destroy_workqueue calls in remove
    
    [ Upstream commit dcb77e4b274b8f13ac6482dfb09160cd2fae9a40 ]
    
    The driver misses calling destroy_workqueue in remove like what is done
    when probe fails.
    Add the missed calls to fix it.
    
    Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1da0c5d2dcd1309a2006b3662e0074cb3713374d
Author: paulhsia <paulhsia@chromium.org>
Date:   Wed Nov 13 01:17:14 2019 +0800

    ALSA: pcm: Fix stream lock usage in snd_pcm_period_elapsed()
    
    [ Upstream commit f5cdc9d4003a2f66ea57b3edd3e04acc2b1a4439 ]
    
    If the nullity check for `substream->runtime` is outside of the lock
    region, it is possible to have a null runtime in the critical section
    if snd_pcm_detach_substream is called right before the lock.
    
    Signed-off-by: paulhsia <paulhsia@chromium.org>
    Link: https://lore.kernel.org/r/20191112171715.128727-2-paulhsia@chromium.org
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f506ed55388432e56b5d9c12f0da3a02b149b53d
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Oct 1 11:18:37 2019 +0200

    sched/core: Avoid spurious lock dependencies
    
    [ Upstream commit ff51ff84d82aea5a889b85f2b9fb3aa2b8691668 ]
    
    While seemingly harmless, __sched_fork() does hrtimer_init(), which,
    when DEBUG_OBJETS, can end up doing allocations.
    
    This then results in the following lock order:
    
      rq->lock
        zone->lock.rlock
          batched_entropy_u64.lock
    
    Which in turn causes deadlocks when we do wakeups while holding that
    batched_entropy lock -- as the random code does.
    
    Solve this by moving __sched_fork() out from under rq->lock. This is
    safe because nothing there relies on rq->lock, as also evident from the
    other __sched_fork() callsite.
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Qian Cai <cai@lca.pw>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: akpm@linux-foundation.org
    Cc: bigeasy@linutronix.de
    Cc: cl@linux.com
    Cc: keescook@chromium.org
    Cc: penberg@kernel.org
    Cc: rientjes@google.com
    Cc: thgarnie@google.com
    Cc: tytso@mit.edu
    Cc: will@kernel.org
    Fixes: b7d5dc21072c ("random: add a spinlock_t to struct batched_entropy")
    Link: https://lkml.kernel.org/r/20191001091837.GK4536@hirez.programming.kicks-ass.net
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b4827e98dec326329015e19b767fa942354d32b6
Author: Pan Bian <bianpan2016@163.com>
Date:   Tue Nov 12 17:04:54 2019 -0800

    Input: cyttsp4_core - fix use after free bug
    
    [ Upstream commit 79aae6acbef16f720a7949f8fc6ac69816c79d62 ]
    
    The device md->input is used after it is released. Setting the device
    data to NULL is unnecessary as the device is never used again. Instead,
    md->input should be assigned NULL to avoid accessing the freed memory
    accidently. Besides, checking md->si against NULL is superfluous as it
    points to a variable address, which cannot be NULL.
    
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Link: https://lore.kernel.org/r/1572936379-6423-1-git-send-email-bianpan2016@163.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3bbb8eec91fe6939bce32c7658f5d8f4c0442659
Author: Xiaodong Xu <stid.smth@gmail.com>
Date:   Mon Nov 11 15:05:46 2019 -0800

    xfrm: release device reference for invalid state
    
    [ Upstream commit 4944a4b1077f74d89073624bd286219d2fcbfce3 ]
    
    An ESP packet could be decrypted in async mode if the input handler for
    this packet returns -EINPROGRESS in xfrm_input(). At this moment the device
    reference in skb is held. Later xfrm_input() will be invoked again to
    resume the processing.
    If the transform state is still valid it would continue to release the
    device reference and there won't be a problem; however if the transform
    state is not valid when async resumption happens, the packet will be
    dropped while the device reference is still being held.
    When the device is deleted for some reason and the reference to this
    device is not properly released, the kernel will keep logging like:
    
    unregister_netdevice: waiting for ppp2 to become free. Usage count = 1
    
    The issue is observed when running IPsec traffic over a PPPoE device based
    on a bridge interface. By terminating the PPPoE connection on the server
    end for multiple times, the PPPoE device on the client side will eventually
    get stuck on the above warning message.
    
    This patch will check the async mode first and continue to release device
    reference in async resumption, before it is dropped due to invalid state.
    
    v2: Do not assign address family from outer_mode in the transform if the
    state is invalid
    
    v3: Release device reference in the error path instead of jumping to resume
    
    Fixes: 4ce3dbe397d7b ("xfrm: Fix xfrm_input() to verify state is valid when (encap_type < 0)")
    Signed-off-by: Xiaodong Xu <stid.smth@gmail.com>
    Reported-by: Bo Chen <chenborfc@163.com>
    Tested-by: Bo Chen <chenborfc@163.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7a9b522fa65d4a25754b3a4329f76d132ffab63d
Author: Stephan Gerhold <stephan@gerhold.net>
Date:   Sun Nov 10 17:19:15 2019 +0100

    NFC: nxp-nci: Fix NULL pointer dereference after I2C communication error
    
    [ Upstream commit a71a29f50de1ef97ab55c151a1598eb12dde379d ]
    
    I2C communication errors (-EREMOTEIO) during the IRQ handler of nxp-nci
    result in a NULL pointer dereference at the moment:
    
        BUG: kernel NULL pointer dereference, address: 0000000000000000
        Oops: 0002 [#1] PREEMPT SMP NOPTI
        CPU: 1 PID: 355 Comm: irq/137-nxp-nci Not tainted 5.4.0-rc6 #1
        RIP: 0010:skb_queue_tail+0x25/0x50
        Call Trace:
         nci_recv_frame+0x36/0x90 [nci]
         nxp_nci_i2c_irq_thread_fn+0xd1/0x285 [nxp_nci_i2c]
         ? preempt_count_add+0x68/0xa0
         ? irq_forced_thread_fn+0x80/0x80
         irq_thread_fn+0x20/0x60
         irq_thread+0xee/0x180
         ? wake_threads_waitq+0x30/0x30
         kthread+0xfb/0x130
         ? irq_thread_check_affinity+0xd0/0xd0
         ? kthread_park+0x90/0x90
         ret_from_fork+0x1f/0x40
    
    Afterward the kernel must be rebooted to work properly again.
    
    This happens because it attempts to call nci_recv_frame() with skb == NULL.
    However, unlike nxp_nci_fw_recv_frame(), nci_recv_frame() does not have any
    NULL checks for skb, causing the NULL pointer dereference.
    
    Change the code to call only nxp_nci_fw_recv_frame() in case of an error.
    Make sure to log it so it is obvious that a communication error occurred.
    The error above then becomes:
    
        nxp-nci_i2c i2c-NXP1001:00: NFC: Read failed with error -121
        nci: __nci_request: wait_for_completion_interruptible_timeout failed 0
        nxp-nci_i2c i2c-NXP1001:00: NFC: Read failed with error -121
    
    Fixes: 6be88670fc59 ("NFC: nxp-nci_i2c: Add I2C support to NXP NCI driver")
    Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0eda2827797d047ad79ee5d9568531bed7950308
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Nov 2 13:11:41 2019 -0400

    audit_get_nd(): don't unlock parent too early
    
    [ Upstream commit 69924b89687a2923e88cc42144aea27868913d0e ]
    
    if the child has been negative and just went positive
    under us, we want coherent d_is_positive() and ->d_inode.
    Don't unlock the parent until we'd done that work...
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0d29e9eed56cadb805bb2f2432cda97e6621f17c
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Fri Nov 8 22:08:29 2019 -0500

    exportfs_decode_fh(): negative pinned may become positive without the parent locked
    
    [ Upstream commit a2ece088882666e1dc7113744ac912eb161e3f87 ]
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cb8ce68f3037f911cf1b51b37ad8787f7c1cbcd7
Author: Mordechay Goodstein <mordechay.goodstein@intel.com>
Date:   Thu Nov 7 13:51:47 2019 +0200

    iwlwifi: pcie: don't consider IV len in A-MSDU
    
    [ Upstream commit cb1a4badf59275eb7221dcec621e8154917eabd1 ]
    
    From gen2 PN is totally offloaded to hardware (also the space for the
    IV isn't part of the skb).  As you can see in mvm/mac80211.c:3545, the
    MAC for cipher types CCMP/GCMP doesn't set
    IEEE80211_KEY_FLAG_PUT_IV_SPACE for gen2 NICs.
    
    This causes all the AMSDU data to be corrupted with cipher enabled.
    
    Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 223767740e15a0bd5c4c91baa9ffa21b92653ae1
Author: Sirong Wang <wangsirong@huawei.com>
Date:   Fri Nov 1 10:33:29 2019 +0800

    RDMA/hns: Correct the value of HNS_ROCE_HEM_CHUNK_LEN
    
    [ Upstream commit 531eb45b3da4267fc2a64233ba256c8ffb02edd2 ]
    
    Size of pointer to buf field of struct hns_roce_hem_chunk should be
    considered when calculating HNS_ROCE_HEM_CHUNK_LEN, or sg table size will
    be larger than expected when allocating hem.
    
    Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver")
    Link: https://lore.kernel.org/r/1572575610-52530-2-git-send-email-liweihang@hisilicon.com
    Signed-off-by: Sirong Wang <wangsirong@huawei.com>
    Signed-off-by: Weihang Li <liweihang@hisilicon.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4404070f6a8cf2c86c76176e4b7221fa6edd5368
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Fri Oct 25 00:03:11 2019 -0400

    autofs: fix a leak in autofs_expire_indirect()
    
    [ Upstream commit 03ad0d703df75c43f78bd72e16124b5b94a95188 ]
    
    if the second call of should_expire() in there ends up
    grabbing and returning a new reference to dentry, we need
    to drop it before continuing.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5cbcf71375eaaeef9c127407d34a63682cd1bd12
Author: Chuhong Yuan <hslester96@gmail.com>
Date:   Mon Nov 18 10:48:33 2019 +0800

    serial: ifx6x60: add missed pm_runtime_disable
    
    commit 50b2b571c5f3df721fc81bf9a12c521dfbe019ba upstream.
    
    The driver forgets to call pm_runtime_disable in remove.
    Add the missed calls to fix it.
    
    Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20191118024833.21587-1-hslester96@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79e08aef5797d2ec18e538f57ae2acd20b6c9b7b
Author: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
Date:   Wed Nov 20 23:18:53 2019 +0800

    serial: serial_core: Perform NULL checks for break_ctl ops
    
    commit 7d73170e1c282576419f8b50a771f1fcd2b81a94 upstream.
    
    Doing fuzz test on sbsa uart device, causes a kernel crash
    due to NULL pointer dereference:
    
    ------------[ cut here ]------------
    Unable to handle kernel paging request at virtual address fffffffffffffffc
    pgd = ffffffe331723000
    [fffffffffffffffc] *pgd=0000002333595003, *pud=0000002333595003, *pmd=00000
    Internal error: Oops: 96000005 [#1] PREEMPT SMP
    Modules linked in: ping(O) jffs2 rtos_snapshot(O) pramdisk(O) hisi_sfc(O)
    Drv_Nandc_K(O) Drv_SysCtl_K(O) Drv_SysClk_K(O) bsp_reg(O) hns3(O)
    hns3_uio_enet(O) hclgevf(O) hclge(O) hnae3(O) mdio_factory(O)
    mdio_registry(O) mdio_dev(O) mdio(O) hns3_info(O) rtos_kbox_panic(O)
    uart_suspend(O) rsm(O) stp llc tunnel4 xt_tcpudp ipt_REJECT nf_reject_ipv4
    iptable_filter ip_tables x_tables sd_mod xhci_plat_hcd xhci_pci xhci_hcd
    usbmon usbhid usb_storage ohci_platform ohci_pci ohci_hcd hid_generic hid
    ehci_platform ehci_pci ehci_hcd vfat fat usbcore usb_common scsi_mod
    yaffs2multi(O) ext4 jbd2 ext2 mbcache ofpart i2c_dev i2c_core uio ubi nand
    nand_ecc nand_ids cfi_cmdset_0002 cfi_cmdset_0001 cfi_probe gen_probe
    cmdlinepart chipreg mtdblock mtd_blkdevs mtd nfsd auth_rpcgss oid_registry
    nfsv3 nfs nfs_acl lockd sunrpc grace autofs4
    CPU: 2 PID: 2385 Comm: tty_fuzz_test Tainted: G           O    4.4.193 #1
    task: ffffffe32b23f110 task.stack: ffffffe32bda4000
    PC is at uart_break_ctl+0x44/0x84
    LR is at uart_break_ctl+0x34/0x84
    pc : [<ffffff8393196098>] lr : [<ffffff8393196088>] pstate: 80000005
    sp : ffffffe32bda7cc0
    x29: ffffffe32bda7cc0 x28: ffffffe32b23f110
    x27: ffffff8393402000 x26: 0000000000000000
    x25: ffffffe32b233f40 x24: ffffffc07a8ec680
    x23: 0000000000005425 x22: 00000000ffffffff
    x21: ffffffe33ed73c98 x20: 0000000000000000
    x19: ffffffe33ed94168 x18: 0000000000000004
    x17: 0000007f92ae9d30 x16: ffffff8392fa6064
    x15: 0000000000000010 x14: 0000000000000000
    x13: 0000000000000000 x12: 0000000000000000
    x11: 0000000000000020 x10: 0000007ffdac1708
    x9 : 0000000000000078 x8 : 000000000000001d
    x7 : 0000000052a64887 x6 : ffffffe32bda7e08
    x5 : ffffffe32b23c000 x4 : 0000005fbc5b0000
    x3 : ffffff83938d5018 x2 : 0000000000000080
    x1 : ffffffe32b23c040 x0 : ffffff83934428f8
    virtual start addr offset is 38ac00000
    module base offset is 2cd4cf1000
    linear region base offset is : 0
    Process tty_fuzz_test (pid: 2385, stack limit = 0xffffffe32bda4000)
    Stack: (0xffffffe32bda7cc0 to 0xffffffe32bda8000)
    7cc0: ffffffe32bda7cf0 ffffff8393177718 ffffffc07a8ec680 ffffff8393196054
    7ce0: 000000001739f2e0 0000007ffdac1978 ffffffe32bda7d20 ffffff8393179a1c
    7d00: 0000000000000000 ffffff8393c0a000 ffffffc07a8ec680 cb88537fdc8ba600
    7d20: ffffffe32bda7df0 ffffff8392fa5a40 ffffff8393c0a000 0000000000005425
    7d40: 0000007ffdac1978 ffffffe32b233f40 ffffff8393178dcc 0000000000000003
    7d60: 000000000000011d 000000000000001d ffffffe32b23f110 000000000000029e
    7d80: ffffffe34fe8d5d0 0000000000000000 ffffffe32bda7e14 cb88537fdc8ba600
    7da0: ffffffe32bda7e30 ffffff8393042cfc ffffff8393c41720 ffffff8393c46410
    7dc0: ffffff839304fa68 ffffffe32b233f40 0000000000005425 0000007ffdac1978
    7de0: 000000000000011d cb88537fdc8ba600 ffffffe32bda7e70 ffffff8392fa60cc
    7e00: 0000000000000000 ffffffe32b233f40 ffffffe32b233f40 0000000000000003
    7e20: 0000000000005425 0000007ffdac1978 ffffffe32bda7e70 ffffff8392fa60b0
    7e40: 0000000000000280 ffffffe32b233f40 ffffffe32b233f40 0000000000000003
    7e60: 0000000000005425 cb88537fdc8ba600 0000000000000000 ffffff8392e02e78
    7e80: 0000000000000280 0000005fbc5b0000 ffffffffffffffff 0000007f92ae9d3c
    7ea0: 0000000060000000 0000000000000015 0000000000000003 0000000000005425
    7ec0: 0000007ffdac1978 0000000000000000 00000000a54c910e 0000007f92b95014
    7ee0: 0000007f92b95090 0000000052a64887 000000000000001d 0000000000000078
    7f00: 0000007ffdac1708 0000000000000020 0000000000000000 0000000000000000
    7f20: 0000000000000000 0000000000000010 000000556acf0090 0000007f92ae9d30
    7f40: 0000000000000004 000000556acdef10 0000000000000000 000000556acdebd0
    7f60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
    7f80: 0000000000000000 0000000000000000 0000000000000000 0000007ffdac1840
    7fa0: 000000556acdedcc 0000007ffdac1840 0000007f92ae9d3c 0000000060000000
    7fc0: 0000000000000000 0000000000000000 0000000000000003 000000000000001d
    7fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
    Call trace:
    Exception stack(0xffffffe32bda7ab0 to 0xffffffe32bda7bf0)
    7aa0:                                   0000000000001000 0000007fffffffff
    7ac0: ffffffe32bda7cc0 ffffff8393196098 0000000080000005 0000000000000025
    7ae0: ffffffe32b233f40 ffffff83930d777c ffffffe32bda7b30 ffffff83930d777c
    7b00: ffffffe32bda7be0 ffffff83938d5000 ffffffe32bda7be0 ffffffe32bda7c20
    7b20: ffffffe32bda7b60 ffffff83930d777c ffffffe32bda7c10 ffffff83938d5000
    7b40: ffffffe32bda7c10 ffffffe32bda7c50 ffffff8393c0a000 ffffffe32b23f110
    7b60: ffffffe32bda7b70 ffffff8392e09df4 ffffffe32bda7bb0 cb88537fdc8ba600
    7b80: ffffff83934428f8 ffffffe32b23c040 0000000000000080 ffffff83938d5018
    7ba0: 0000005fbc5b0000 ffffffe32b23c000 ffffffe32bda7e08 0000000052a64887
    7bc0: 000000000000001d 0000000000000078 0000007ffdac1708 0000000000000020
    7be0: 0000000000000000 0000000000000000
    [<ffffff8393196098>] uart_break_ctl+0x44/0x84
    [<ffffff8393177718>] send_break+0xa0/0x114
    [<ffffff8393179a1c>] tty_ioctl+0xc50/0xe84
    [<ffffff8392fa5a40>] do_vfs_ioctl+0xc4/0x6e8
    [<ffffff8392fa60cc>] SyS_ioctl+0x68/0x9c
    [<ffffff8392e02e78>] __sys_trace_return+0x0/0x4
    Code: b9410ea0 34000160 f9408aa0 f9402814 (b85fc280)
    ---[ end trace 8606094f1960c5e0 ]---
    Kernel panic - not syncing: Fatal exception
    
    Fix this problem by adding NULL checks prior to calling break_ctl ops.
    
    Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/1574263133-28259-1-git-send-email-xiaojiangfeng@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c6aed4fc2387cec8ffcdb796c3687ef82727984
Author: Vincent Whitchurch <vincent.whitchurch@axis.com>
Date:   Mon Nov 18 10:25:47 2019 +0100

    serial: pl011: Fix DMA ->flush_buffer()
    
    commit f6a196477184b99a31d16366a8e826558aa11f6d upstream.
    
    PL011's ->flush_buffer() implementation releases and reacquires the port
    lock.  Due to a race condition here, data can end up being added to the
    circular buffer but neither being discarded nor being sent out.  This
    leads to, for example, tcdrain(2) waiting indefinitely.
    
    Process A                       Process B
    
    uart_flush_buffer()
     - acquire lock
     - circ_clear
     - pl011_flush_buffer()
     -- release lock
     -- dmaengine_terminate_all()
    
                                    uart_write()
                                    - acquire lock
                                    - add chars to circ buffer
                                    - start_tx()
                                    -- start DMA
                                    - release lock
    
     -- acquire lock
     -- turn off DMA
     -- release lock
    
                                    // Data in circ buffer but DMA is off
    
    According to the comment in the code, the releasing of the lock around
    dmaengine_terminate_all() is to avoid a deadlock with the DMA engine
    callback.  However, since the time this code was written, the DMA engine
    API documentation seems to have been clarified to say that
    dmaengine_terminate_all() (in the identically implemented but
    differently named dmaengine_terminate_async() variant) does not wait for
    any running complete callback to be completed and can even be called
    from a complete callback.  So there is no possibility of deadlock if the
    DMA engine driver implements this API correctly.
    
    So we should be able to just remove this release and reacquire of the
    lock to prevent the aforementioned race condition.
    
    Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20191118092547.32135-1-vincent.whitchurch@axis.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 358aba9b3ba4264060598559043e99bd621f263d
Author: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Date:   Mon Oct 21 08:46:16 2019 -0700

    tty: serial: msm_serial: Fix flow control
    
    commit b027ce258369cbfa88401a691c23dad01deb9f9b upstream.
    
    hci_qca interfaces to the wcn3990 via a uart_dm on the msm8998 mtp and
    Lenovo Miix 630 laptop.  As part of initializing the wcn3990, hci_qca
    disables flow, configures the uart baudrate, and then reenables flow - at
    which point an event is expected to be received over the uart from the
    wcn3990.  It is observed that this event comes after the baudrate change
    but before hci_qca re-enables flow. This is unexpected, and is a result of
    msm_reset() being broken.
    
    According to the uart_dm hardware documentation, it is recommended that
    automatic hardware flow control be enabled by setting RX_RDY_CTL.  Auto
    hw flow control will manage RFR based on the configured watermark.  When
    there is space to receive data, the hw will assert RFR.  When the watermark
    is hit, the hw will de-assert RFR.
    
    The hardware documentation indicates that RFR can me manually managed via
    CR when RX_RDY_CTL is not set.  SET_RFR asserts RFR, and RESET_RFR
    de-asserts RFR.
    
    msm_reset() is broken because after resetting the hardware, it
    unconditionally asserts RFR via SET_RFR.  This enables flow regardless of
    the current configuration, and would undo a previous flow disable
    operation.  It should instead de-assert RFR via RESET_RFR to block flow
    until the hardware is reconfigured.  msm_serial should rely on the client
    to specify that flow should be enabled, either via mctrl() or the termios
    structure, and only assert RFR in response to those triggers.
    
    Fixes: 04896a77a97b ("msm_serial: serial driver for MSM7K onboard serial peripheral.")
    Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
    Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Cc: stable <stable@vger.kernel.org>
    Reviewed-by: Andy Gross <agross@kernel.org>
    Link: https://lore.kernel.org/r/20191021154616.25457-1-jeffrey.l.hugo@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3e83b6532a008200b46c9e7ff04b767d6b34d1c
Author: Peng Fan <peng.fan@nxp.com>
Date:   Tue Nov 5 05:51:10 2019 +0000

    tty: serial: fsl_lpuart: use the sg count from dma_map_sg
    
    commit 487ee861de176090b055eba5b252b56a3b9973d6 upstream.
    
    The dmaengine_prep_slave_sg needs to use sg count returned
    by dma_map_sg, not use sport->dma_tx_nents, because the return
    value of dma_map_sg is not always same with "nents".
    
    When enabling iommu for lpuart + edma, iommu framework may concatenate
    two sgs into one.
    
    Fixes: 6250cc30c4c4e ("tty: serial: fsl_lpuart: Use scatter/gather DMA for Tx")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Link: https://lore.kernel.org/r/1572932977-17866-1-git-send-email-peng.fan@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec85bb89cc74a60c1afb47f537f9613b795a184a
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date:   Sat Aug 10 10:42:48 2019 +0200

    usb: gadget: u_serial: add missing port entry locking
    
    commit daf82bd24e308c5a83758047aff1bd81edda4f11 upstream.
    
    gserial_alloc_line() misses locking (for a release barrier) while
    resetting port entry on TTY allocation failure. Fix this.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Tested-by: Ladislav Michl <ladis@linux-mips.org>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f3836c8aee27c43fd26af7d05e214ea4fe1d67e
Author: Jon Hunter <jonathanh@nvidia.com>
Date:   Wed Sep 25 15:12:29 2019 +0100

    arm64: tegra: Fix 'active-low' warning for Jetson TX1 regulator
    
    commit 1e5e929c009559bd7e898ac8e17a5d01037cb057 upstream.
    
    Commit 34993594181d ("arm64: tegra: Enable HDMI on Jetson TX1")
    added a regulator for HDMI on the Jetson TX1 platform. This regulator
    has an active high enable, but the GPIO specifier for enabling the
    regulator incorrectly defines it as active-low. This causes the
    following warning to occur on boot ...
    
     WARNING KERN regulator@10 GPIO handle specifies active low - ignored
    
    The fixed-regulator binding does not use the active-low flag from the
    gpio specifier and purely relies of the presence of the
    'enable-active-high' property to determine if it is active high or low
    (if this property is omitted). Fix this warning by setting the GPIO
    to active-high in the GPIO specifier which aligns with the presense of
    the 'enable-active-high' property.
    
    Fixes: 34993594181d ("arm64: tegra: Enable HDMI on Jetson TX1")
    Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d8b2921af273b9545e16ad21375fabcb647c56e
Author: Navid Emamdoost <navid.emamdoost@gmail.com>
Date:   Fri Sep 13 19:08:11 2019 -0500

    rsi: release skb if rsi_prepare_beacon fails
    
    commit d563131ef23cbc756026f839a82598c8445bc45f upstream.
    
    In rsi_send_beacon, if rsi_prepare_beacon fails the allocated skb should
    be released.
    
    Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>