commit 26adb9d8ba0769575032b4ff6cb7baa55574bedf
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Jan 9 13:34:16 2021 +0100

    Linux 4.4.250
    
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20210107143049.179580814@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 878ba6234c5827722d79767d39450340e228ce86
Author: Zhang Xiaohui <ruc_zhangxiaohui@163.com>
Date:   Sun Dec 6 16:48:01 2020 +0800

    mwifiex: Fix possible buffer overflows in mwifiex_cmd_802_11_ad_hoc_start
    
    [ Upstream commit 5c455c5ab332773464d02ba17015acdca198f03d ]
    
    mwifiex_cmd_802_11_ad_hoc_start() calls memcpy() without checking
    the destination size may trigger a buffer overflower,
    which a local user could use to cause denial of service
    or the execution of arbitrary code.
    Fix it by putting the length check before calling memcpy().
    
    Signed-off-by: Zhang Xiaohui <ruc_zhangxiaohui@163.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20201206084801.26479-1-ruc_zhangxiaohui@163.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 308d3019f6698c526bc1baeb7f6a71dff1f15695
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sun Sep 20 12:27:37 2020 +0100

    iio:magnetometer:mag3110: Fix alignment and data leak issues.
    
    commit 89deb1334252ea4a8491d47654811e28b0790364 upstream
    
    One of a class of bugs pointed out by Lars in a recent review.
    iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned
    to the size of the timestamp (8 bytes).  This is not guaranteed in
    this driver which uses an array of smaller elements on the stack.
    As Lars also noted this anti pattern can involve a leak of data to
    userspace and that indeed can happen here.  We close both issues by
    moving to a suitable structure in the iio_priv() data.
    This data is allocated with kzalloc() so no data can leak apart from
    previous readings.
    
    The explicit alignment of ts is not necessary in this case but
    does make the code slightly less fragile so I have included it.
    
    Fixes: 39631b5f9584 ("iio: Add Freescale mag3110 magnetometer driver")
    Reported-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
    Cc: <Stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200920112742.170751-4-jic23@kernel.org
    [sudip: adjust context]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e276172803340b6dd2368c817ccaeb3870947c4
Author: Jessica Yu <jeyu@kernel.org>
Date:   Fri Nov 27 10:09:39 2020 +0100

    module: delay kobject uevent until after module init call
    
    [ Upstream commit 38dc717e97153e46375ee21797aa54777e5498f3 ]
    
    Apparently there has been a longstanding race between udev/systemd and
    the module loader. Currently, the module loader sends a uevent right
    after sysfs initialization, but before the module calls its init
    function. However, some udev rules expect that the module has
    initialized already upon receiving the uevent.
    
    This race has been triggered recently (see link in references) in some
    systemd mount unit files. For instance, the configfs module creates the
    /sys/kernel/config mount point in its init function, however the module
    loader issues the uevent before this happens. sys-kernel-config.mount
    expects to be able to mount /sys/kernel/config upon receipt of the
    module loading uevent, but if the configfs module has not called its
    init function yet, then this directory will not exist and the mount unit
    fails. A similar situation exists for sys-fs-fuse-connections.mount, as
    the fuse sysfs mount point is created during the fuse module's init
    function. If udev is faster than module initialization then the mount
    unit would fail in a similar fashion.
    
    To fix this race, delay the module KOBJ_ADD uevent until after the
    module has finished calling its init routine.
    
    References: https://github.com/systemd/systemd/issues/17586
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Tested-By: Nicolas Morey-Chaisemartin <nmoreychaisemartin@suse.com>
    Signed-off-by: Jessica Yu <jeyu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2ec4a0c66210e12debe6c4f8bdfcfe9208547955
Author: Qinglang Miao <miaoqinglang@huawei.com>
Date:   Wed Oct 28 17:15:51 2020 +0800

    powerpc: sysdev: add missing iounmap() on error in mpic_msgr_probe()
    
    [ Upstream commit ffa1797040c5da391859a9556be7b735acbe1242 ]
    
    I noticed that iounmap() of msgr_block_addr before return from
    mpic_msgr_probe() in the error handling case is missing. So use
    devm_ioremap() instead of just ioremap() when remapping the message
    register block, so the mapping will be automatically released on
    probe failure.
    
    Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20201028091551.136400-1-miaoqinglang@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e1b7f1ab543bffc0d6af7d22e744af9b7acc10ac
Author: Jan Kara <jack@suse.cz>
Date:   Mon Nov 2 16:32:10 2020 +0100

    quota: Don't overflow quota file offsets
    
    [ Upstream commit 10f04d40a9fa29785206c619f80d8beedb778837 ]
    
    The on-disk quota format supports quota files with upto 2^32 blocks. Be
    careful when computing quota file offsets in the quota files from block
    numbers as they can overflow 32-bit types. Since quota files larger than
    4GB would require ~26 millions of quota users, this is mostly a
    theoretical concern now but better be careful, fuzzers would find the
    problem sooner or later anyway...
    
    Reviewed-by: Andreas Dilger <adilger@dilger.ca>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e656f46bdc55d13c06d2d6e46e4b4b7c0f832d6d
Author: Miroslav Benes <mbenes@suse.cz>
Date:   Tue Oct 27 15:03:36 2020 +0100

    module: set MODULE_STATE_GOING state when a module fails to load
    
    [ Upstream commit 5e8ed280dab9eeabc1ba0b2db5dbe9fe6debb6b5 ]
    
    If a module fails to load due to an error in prepare_coming_module(),
    the following error handling in load_module() runs with
    MODULE_STATE_COMING in module's state. Fix it by correctly setting
    MODULE_STATE_GOING under "bug_cleanup" label.
    
    Signed-off-by: Miroslav Benes <mbenes@suse.cz>
    Signed-off-by: Jessica Yu <jeyu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b6048edcda31981ecbd6d8a67bd1575a9db23d36
Author: Takashi Iwai <tiwai@suse.de>
Date:   Sun Dec 6 09:34:56 2020 +0100

    ALSA: seq: Use bool for snd_seq_queue internal flags
    
    commit 4ebd47037027c4beae99680bff3b20fdee5d7c1e upstream.
    
    The snd_seq_queue struct contains various flags in the bit fields.
    Those are categorized to two different use cases, both of which are
    protected by different spinlocks.  That implies that there are still
    potential risks of the bad operations for bit fields by concurrent
    accesses.
    
    For addressing the problem, this patch rearranges those flags to be
    a standard bool instead of a bit field.
    
    Reported-by: syzbot+63cbe31877bb80ef58f5@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/20201206083456.21110-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f04a84506318903aef73cf720037cb6599db690
Author: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Date:   Fri Nov 27 07:40:21 2020 +0100

    media: gp8psk: initialize stats at power control logic
    
    commit d0ac1a26ed5943127cb0156148735f5f52a07075 upstream.
    
    As reported on:
            https://lore.kernel.org/linux-media/20190627222020.45909-1-willemdebruijn.kernel@gmail.com/
    
    if gp8psk_usb_in_op() returns an error, the status var is not
    initialized. Yet, this var is used later on, in order to
    identify:
            - if the device was already started;
            - if firmware has loaded;
            - if the LNBf was powered on.
    
    Using status = 0 seems to ensure that everything will be
    properly powered up.
    
    So, instead of the proposed solution, let's just set
    status = 0.
    
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Reported-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 99f3251fe0d791f8cf2465b4d6b70d66d75ba027
Author: Anant Thazhemadam <anant.thazhemadam@gmail.com>
Date:   Mon Nov 23 04:15:34 2020 +0530

    misc: vmw_vmci: fix kernel info-leak by initializing dbells in vmci_ctx_get_chkpt_doorbells()
    
    commit 31dcb6c30a26d32650ce134820f27de3c675a45a upstream.
    
    A kernel-infoleak was reported by syzbot, which was caused because
    dbells was left uninitialized.
    Using kzalloc() instead of kmalloc() fixes this issue.
    
    Reported-by: syzbot+a79e17c39564bedf0930@syzkaller.appspotmail.com
    Tested-by: syzbot+a79e17c39564bedf0930@syzkaller.appspotmail.com
    Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>
    Link: https://lore.kernel.org/r/20201122224534.333471-1-anant.thazhemadam@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 59d9203d3c3862b512c195e71b2a82d963629235
Author: Rustam Kovhaev <rkovhaev@gmail.com>
Date:   Sun Nov 1 06:09:58 2020 -0800

    reiserfs: add check for an invalid ih_entry_count
    
    commit d24396c5290ba8ab04ba505176874c4e04a2d53c upstream.
    
    when directory item has an invalid value set for ih_entry_count it might
    trigger use-after-free or out-of-bounds read in bin_search_in_dir_item()
    
    ih_entry_count * IH_SIZE for directory item should not be larger than
    ih_item_len
    
    Link: https://lore.kernel.org/r/20201101140958.3650143-1-rkovhaev@gmail.com
    Reported-and-tested-by: syzbot+83b6f7cf9922cae5c4d7@syzkaller.appspotmail.com
    Link: https://syzkaller.appspot.com/bug?extid=83b6f7cf9922cae5c4d7
    Signed-off-by: Rustam Kovhaev <rkovhaev@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c839e2013ad93f9b5791e7d99f85e19eb50b21a1
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Nov 23 11:23:12 2020 +0100

    of: fix linker-section match-table corruption
    
    commit 5812b32e01c6d86ba7a84110702b46d8a8531fe9 upstream.
    
    Specify type alignment when declaring linker-section match-table entries
    to prevent gcc from increasing alignment and corrupting the various
    tables with padding (e.g. timers, irqchips, clocks, reserved memory).
    
    This is specifically needed on x86 where gcc (typically) aligns larger
    objects like struct of_device_id with static extent on 32-byte
    boundaries which at best prevents matching on anything but the first
    entry. Specifying alignment when declaring variables suppresses this
    optimisation.
    
    Here's a 64-bit example where all entries are corrupt as 16 bytes of
    padding has been inserted before the first entry:
    
            ffffffff8266b4b0 D __clk_of_table
            ffffffff8266b4c0 d __of_table_fixed_factor_clk
            ffffffff8266b5a0 d __of_table_fixed_clk
            ffffffff8266b680 d __clk_of_table_sentinel
    
    And here's a 32-bit example where the 8-byte-aligned table happens to be
    placed on a 32-byte boundary so that all but the first entry are corrupt
    due to the 28 bytes of padding inserted between entries:
    
            812b3ec0 D __irqchip_of_table
            812b3ec0 d __of_table_irqchip1
            812b3fa0 d __of_table_irqchip2
            812b4080 d __of_table_irqchip3
            812b4160 d irqchip_of_match_end
    
    Verified on x86 using gcc-9.3 and gcc-4.9 (which uses 64-byte
    alignment), and on arm using gcc-7.2.
    
    Note that there are no in-tree users of these tables on x86 currently
    (even if they are included in the image).
    
    Fixes: 54196ccbe0ba ("of: consolidate linker section OF match table declarations")
    Fixes: f6e916b82022 ("irqchip: add basic infrastructure")
    Cc: stable <stable@vger.kernel.org>     # 3.9
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20201123102319.8090-2-johan@kernel.org
    [ johan: adjust context to 5.4 ]
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f1a8e20777c4134e2fcb233951ba511607d3603
Author: Petr Vorel <petr.vorel@gmail.com>
Date:   Mon Dec 14 19:03:21 2020 -0800

    uapi: move constants from <linux/kernel.h> to <linux/const.h>
    
    commit a85cbe6159ffc973e5702f70a3bd5185f8f3c38d upstream.
    
    and include <linux/const.h> in UAPI headers instead of <linux/kernel.h>.
    
    The reason is to avoid indirect <linux/sysinfo.h> include when using
    some network headers: <linux/netlink.h> or others -> <linux/kernel.h>
    -> <linux/sysinfo.h>.
    
    This indirect include causes on MUSL redefinition of struct sysinfo when
    included both <sys/sysinfo.h> and some of UAPI headers:
    
        In file included from x86_64-buildroot-linux-musl/sysroot/usr/include/linux/kernel.h:5,
                         from x86_64-buildroot-linux-musl/sysroot/usr/include/linux/netlink.h:5,
                         from ../include/tst_netlink.h:14,
                         from tst_crypto.c:13:
        x86_64-buildroot-linux-musl/sysroot/usr/include/linux/sysinfo.h:8:8: error: redefinition of `struct sysinfo'
         struct sysinfo {
                ^~~~~~~
        In file included from ../include/tst_safe_macros.h:15,
                         from ../include/tst_test.h:93,
                         from tst_crypto.c:11:
        x86_64-buildroot-linux-musl/sysroot/usr/include/sys/sysinfo.h:10:8: note: originally defined here
    
    Link: https://lkml.kernel.org/r/20201015190013.8901-1-petr.vorel@gmail.com
    Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
    Suggested-by: Rich Felker <dalias@aerifal.cx>
    Acked-by: Rich Felker <dalias@libc.org>
    Cc: Peter Korsgaard <peter@korsgaard.com>
    Cc: Baruch Siach <baruch@tkos.co.il>
    Cc: Florian Weimer <fweimer@redhat.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 b7f7a2b2b6dc43ad603cfca15726e6b7628dcbed
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Oct 26 11:43:06 2020 +0100

    USB: serial: digi_acceleport: fix write-wakeup deadlocks
    
    [ Upstream commit 5098e77962e7c8947f87bd8c5869c83e000a522a ]
    
    The driver must not call tty_wakeup() while holding its private lock as
    line disciplines are allowed to call back into write() from
    write_wakeup(), leading to a deadlock.
    
    Also remove the unneeded work struct that was used to defer wakeup in
    order to work around a possible race in ancient times (see comment about
    n_tty write_chan() in commit 14b54e39b412 ("USB: serial: remove
    changelogs and old todo entries")).
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable@vger.kernel.org
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c01db33af603a6b32668d4553cceb712925c03d6
Author: Stefan Haberland <sth@linux.ibm.com>
Date:   Thu Dec 17 16:59:04 2020 +0100

    s390/dasd: fix hanging device offline processing
    
    [ Upstream commit 658a337a606f48b7ebe451591f7681d383fa115e ]
    
    For an LCU update a read unit address configuration IO is required.
    This is started using sleep_on(), which has early exit paths in case the
    device is not usable for IO. For example when it is in offline processing.
    
    In those cases the LCU update should fail and not be retried.
    Therefore lcu_update_work checks if EOPNOTSUPP is returned or not.
    
    Commit 41995342b40c ("s390/dasd: fix endless loop after read unit address configuration")
    accidentally removed the EOPNOTSUPP return code from
    read_unit_address_configuration(), which in turn might lead to an endless
    loop of the LCU update in offline processing.
    
    Fix by returning EOPNOTSUPP again if the device is not able to perform the
    request.
    
    Fixes: 41995342b40c ("s390/dasd: fix endless loop after read unit address configuration")
    Cc: stable@vger.kernel.org #5.3
    Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
    Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e253fcb4ccb9da44851c959370e0ddd083060d3a
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>
    [sudip: adjust context]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75dd4f73a9fd47a255b30da22e9c208131471a18
Author: Hui Wang <hui.wang@canonical.com>
Date:   Fri Mar 2 13:05:36 2018 +0800

    ALSA: hda - Fix a wrong FIXUP for alc289 on Dell machines
    
    commit d5078193e56bb24f4593f00102a3b5e07bb84ee0 upstream
    
    With the alc289, the Pin 0x1b is Headphone-Mic, so we should assign
    ALC269_FIXUP_DELL4_MIC_NO_PRESENCE rather than
    ALC225_FIXUP_DELL1_MIC_NO_PRESENCE to it. And this change is suggested
    by Kailang of Realtek and is verified on the machine.
    
    Fixes: 3f2f7c553d07 ("ALSA: hda - Fix headset mic detection problem for two Dell machines")
    Cc: Kailang Yang <kailang@realtek.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1d6b4b7bbb2a97b06489b837216e208bc453bbe2
Author: Kailang Yang <kailang@realtek.com>
Date:   Thu Jun 29 15:21:27 2017 +0800

    ALSA: hda/realtek - Support Dell headset mode for ALC3271
    
    commit fcc6c877a01f83cbce1cca885ea62df6a10d33c3 upstream
    
    Add DELL4_MIC_NO_PRESENCE model.
    Add the pin configuration value of this machine into the pin_quirk
    table to make DELL4_MIC_NO_PRESENCE apply to this machine.
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d2092cfefca63935f16a5b9463ce25189e822740
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 14 09:39:53 2020 +0100

    ALSA: usb-audio: fix sync-ep altsetting sanity check
    
    commit 5d1b71226dc4d44b4b65766fa9d74492f9d4587b upstream
    
    The altsetting sanity check in set_sync_ep_implicit_fb_quirk() was
    checking for there to be at least one altsetting but then went on to
    access the second one, which may not exist.
    
    This could lead to random slab data being used to initialise the sync
    endpoint in snd_usb_add_endpoint().
    
    Fixes: c75a8a7ae565 ("ALSA: snd-usb: add support for implicit feedback")
    Fixes: ca10a7ebdff1 ("ALSA: usb-audio: FT C400 sync playback EP to capture EP")
    Fixes: 5e35dc0338d8 ("ALSA: usb-audio: add implicit fb quirk for Behringer UFX1204")
    Fixes: 17f08b0d9aaf ("ALSA: usb-audio: add implicit fb quirk for Axe-Fx II")
    Fixes: 103e9625647a ("ALSA: usb-audio: simplify set_sync_ep_implicit_fb_quirk")
    Cc: stable <stable@vger.kernel.org>     # 3.5
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20200114083953.1106-1-johan@kernel.org
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 230650b21c7d5a0c346f9c3a1c6a99518ba34b98
Author: Alberto Aguirre <albaguirre@gmail.com>
Date:   Wed Apr 18 09:35:34 2018 -0500

    ALSA: usb-audio: simplify set_sync_ep_implicit_fb_quirk
    
    commit 103e9625647ad74d201e26fb74afcd8479142a37 upstream
    
    Signed-off-by: Alberto Aguirre <albaguirre@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [sudip: adjust context]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c741f4170c0f58b72147f54d99ec06fd212c52a
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Dec 13 09:51:11 2019 +0100

    ALSA: hda/ca0132 - Fix work handling in delayed HP detection
    
    commit 42fb6b1d41eb5905d77c06cad2e87b70289bdb76 upstream
    
    CA0132 has the delayed HP jack detection code that is invoked from the
    unsol handler, but it does a few weird things: it contains the cancel
    of a work inside the work handler, and yet it misses the cancel-sync
    call at (runtime-)suspend.  This patch addresses those issues.
    
    Fixes: 15c2b3cc09a3 ("ALSA: hda/ca0132 - Fix possible workqueue stall")
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20191213085111.22855-4-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [sudip: adjust context]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>