commit 3dfa869cb79d60a2fe66efb4a11517ec7c89de16
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Nov 6 14:11:30 2021 +0100

    Linux 5.14.17
    
    Link: https://lore.kernel.org/r/20211104141159.863820939@linuxfoundation.org
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Ken Moffat <zarniwhoop@ntlworld.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b1dbd891bfe548863dc2d7e011285c03f0088228
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Nov 4 12:23:09 2021 +0100

    ALSA: usb-audio: Add Audient iD14 to mixer map quirk table
    
    commit df0380b9539b04c1ae8854a984098da06d5f1e67 upstream.
    
    This is a fix equivalent with the upstream commit df0380b9539b ("ALSA:
    usb-audio: Add quirk for Audient iD14"), adapted to the earlier
    kernels up to 5.14.y.  It adds the quirk entry with the old
    ignore_ctl_error flag to the usbmix_ctl_maps, instead.
    
    The original commit description says:
        Audient iD14 (2708:0002) may get a control message error that
        interferes the operation e.g. with alsactl.  Add the quirk to ignore
        such errors like other devices.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 570b5004f8279d5804e614d56ec2820e89290418
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Nov 4 12:23:08 2021 +0100

    ALSA: usb-audio: Add Schiit Hel device to mixer map quirk table
    
    commit 22390ce786c59328ccd13c329959dee1e8757487 upstream.
    
    This is a fix equivalent with the upstream commit 22390ce786c5 ("ALSA:
    usb-audio: add Schiit Hel device to quirk table"), adapted to the
    earlier kernels up to 5.14.y.  It adds the quirk entry with the old
    ignore_ctl_error flag to the usbmix_ctl_maps, instead.
    
    The original patch description says:
        The Shciit Hel device responds to the ctl message for the mic capture
        switch with a timeout of -EPIPE:
    
                usb 7-2.2: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1
                usb 7-2.2: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1
                usb 7-2.2: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1
                usb 7-2.2: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1
    
        This seems safe to ignore as the device works properly with the control
        message quirk, so add it to the quirk table so all is good.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db6d7c4acca3eb790319dca2ecfa52c1f85ada02
Author: Matthew Brost <matthew.brost@intel.com>
Date:   Thu Sep 9 09:47:28 2021 -0700

    Revert "drm/i915/gt: Propagate change in error status to children on unhold"
    
    commit ac653dd7996edf1770959e11a078312928bd7315 upstream.
    
    Propagating errors to dependent fences is broken and can lead to errors
    from one client ending up in another. In commit 3761baae908a ("Revert
    "drm/i915: Propagate errors on awaiting already signaled fences""), we
    attempted to get rid of fence error propagation but missed the case
    added in commit 8e9f84cf5cac ("drm/i915/gt: Propagate change in error
    status to children on unhold"). Revert that one too. This error was
    found by an up-and-coming selftest which triggers a reset during
    request cancellation and verifies that subsequent requests complete
    successfully.
    
    v2:
     (Daniel Vetter)
      - Use revert
    v3:
     (Jason)
      - Update commit message
    
    v4 (Daniele):
     - fix checkpatch error in commit message.
    
    References: '3761baae908a ("Revert "drm/i915: Propagate errors on awaiting already signaled fences"")'
    Signed-off-by: Matthew Brost <matthew.brost@intel.com>
    Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-8-matthew.brost@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aac2f68616836cc4dc327abbddc4ab1826a4e323
Author: Anson Jacob <Anson.Jacob@amd.com>
Date:   Tue Aug 24 09:32:53 2021 -0400

    drm/amd/display: Revert "Directly retrain link from debugfs"
    
    commit 1131cadfd7563975f3a4efcc6f7c1fdc872db38b upstream.
    
    This reverts commit f5b6a20c7ef40599095c796b0500d842ffdbc639.
    
    This patch broke new settings from taking effect. Hotplug is
    required for new settings to take effect.
    
    Reviewed-by: Mikita Lipski <mikita.lipski@amd.com>
    Acked-by: Mikita Lipski <mikita.lipski@amd.com>
    Signed-off-by: Anson Jacob <Anson.Jacob@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 77d029e1e2189f865c566693fdf917defdd3b891
Author: Christian König <christian.koenig@amd.com>
Date:   Thu Sep 30 11:22:51 2021 +0200

    drm/amdgpu: revert "Add autodump debugfs node for gpu reset v8"
    
    commit c8365dbda056578eebe164bf110816b1a39b4b7f upstream.
    
    This reverts commit 728e7e0cd61899208e924472b9e641dbeb0775c4.
    
    Further discussion reveals that this feature is severely broken
    and needs to be reverted ASAP.
    
    GPU reset can never be delayed by userspace even for debugging or
    otherwise we can run into in kernel deadlocks.
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Acked-by: Nirmoy Das <nirmoy.das@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f9e09a59c588c8224acaed8988777e388627c34
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Date:   Fri Oct 22 15:04:47 2021 +0100

    Revert "wcn36xx: Disable bmps when encryption is disabled"
    
    commit 285bb1738e196507bf985574d0bc1e9dd72d46b1 upstream.
    
    This reverts commit c6522a5076e1a65877c51cfee313a74ef61cabf8.
    
    Testing on tip-of-tree shows that this is working now. Revert this and
    re-enable BMPS for Open APs.
    
    Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20211022140447.2846248-3-bryan.odonoghue@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9722a7369f83bcab9576323b87c8d09444db703
Author: Wang Kefeng <wangkefeng.wang@huawei.com>
Date:   Mon Aug 23 10:41:42 2021 +0100

    ARM: 9120/1: Revert "amba: make use of -1 IRQs warn"
    
    commit eb4f756915875b0ea0757751cd29841f0504d547 upstream.
    
    After commit 77a7300abad7 ("of/irq: Get rid of NO_IRQ usage"),
    no irq case has been removed, irq_of_parse_and_map() will return
    0 in all cases when get error from parse and map an interrupt into
    linux virq space.
    
    amba_device_register() is only used on no-DT initialization, see
      s3c64xx_pl080_init()          arch/arm/mach-s3c/pl080.c
      ep93xx_init_devices()         arch/arm/mach-ep93xx/core.c
    
    They won't set -1 to irq[0], so no need the warn.
    
    This reverts commit 2eac58d5026e4ec8b17ff8b62877fea9e1d2f1b3.
    
    Reviewed-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e556fca311ce67abecf0c6dd7fb948249422045e
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Sat Oct 2 02:59:37 2021 +0200

    Revert "soc: imx: gpcv2: move reset assert after requesting domain power up"
    
    commit 2b2f106eb55276a60a89ac27a52d0d738b57a546 upstream.
    
    This reverts commit a77ebdd9f553. It turns out that the VPU domain has no
    different requirements, even though the downstream ATF implementation seems
    to suggest otherwise. Powering on the domain with the reset asserted works
    fine. As the changed sequence has caused sporadic issues with the GPU
    domains, just revert the change to go back to the working sequence.
    
    Cc: <stable@vger.kernel.org> # 5.14
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Acked-by: Peng Fan <peng.fan@nxp.com>
    Tested-by: Adam Ford <aford173@gmail.com> #imx8mm-beacon
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6a60e6ada492be7f47a99ecca606af861d65318
Author: José Roberto de Souza <jose.souza@intel.com>
Date:   Tue Oct 12 18:00:46 2021 -0700

    drm/i915: Remove memory frequency calculation
    
    commit 59be177a909ac320e5f4b2a461ac09e20f35b2d8 upstream.
    
    This memory frequency calculated is only used to check if it is zero,
    what is not useful as it will never actually be zero.
    
    Also the calculation is wrong, we should be checking other bit to
    select the appropriate frequency multiplier while this code is stuck
    with a fixed multiplier.
    
    So here dropping it as whole.
    
    v2:
    - Also remove memory frequency calculation for gen9 LP platforms
    
    Cc: Yakui Zhao <yakui.zhao@intel.com>
    Cc: Matt Roper <matthew.d.roper@intel.com>
    Fixes: 5d0c938ec9cc ("drm/i915/gen11+: Only load DRAM information from pcode")
    Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
    Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20211013010046.91858-1-jose.souza@intel.com
    (cherry picked from commit 83f52364b15265aec47d07e02b0fbf4093ab8554)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7883e13c249461877ea3be7b24a5935fc8946e46
Author: Yifan Zhang <yifan1.zhang@amd.com>
Date:   Mon Oct 11 20:37:01 2021 +0800

    drm/amdkfd: fix boot failure when iommu is disabled in Picasso.
    
    commit afd18180c07026f94a80ff024acef5f4159084a4 upstream.
    
    When IOMMU disabled in sbios and kfd in iommuv2 path, iommuv2
    init will fail. But this failure should not block amdgpu driver init.
    
    Reported-by: youling <youling257@gmail.com>
    Tested-by: youling <youling257@gmail.com>
    Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
    Reviewed-by: James Zhu <James.Zhu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a82fa1213d12a708fde219f97ea3e76569694fed
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Nov 3 16:51:36 2021 +0100

    Revert "usb: core: hcd: Add support for deferring roothub registration"
    
    This reverts commit e9ce1992a33861b61e9617f578c1f27174bd285f which is
    commit 58877b0824da15698bd85a0a9dbfa8c354e6ecb7 upstream.
    
    It has been reported to be causing problems in Arch and Fedora bug
    reports.
    
    Reported-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://bbs.archlinux.org/viewtopic.php?pid=2000956#p2000956
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2019542
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2019576
    Link: https://lore.kernel.org/r/42bcbea6-5eb8-16c7-336a-2cb72e71bc36@redhat.com
    Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
    Cc: Chris Chiu <chris.chiu@canonical.com>
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Cc: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0979b923ff3f963005b69ce44bc82db183c30e25
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Nov 3 16:51:12 2021 +0100

    Revert "xhci: Set HCD flag to defer primary roothub registration"
    
    This reverts commit 807ac762afee3b88f17354327c74d986e7489b8a which is
    commit b7a0a792f864583207c593b50fd1b752ed89f4c1 upstream.
    
    It has been reported to be causing problems in Arch and Fedora bug
    reports.
    
    Reported-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://bbs.archlinux.org/viewtopic.php?pid=2000956#p2000956
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2019542
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2019576
    Link: https://lore.kernel.org/r/42bcbea6-5eb8-16c7-336a-2cb72e71bc36@redhat.com
    Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
    Cc: Chris Chiu <chris.chiu@canonical.com>
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Cc: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02a476ca886dc8155025fe99cbbad4121d029fa7
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Jun 7 17:23:48 2021 +0200

    media: firewire: firedtv-avc: fix a buffer overflow in avc_ca_pmt()
    
    commit 35d2969ea3c7d32aee78066b1f3cf61a0d935a4e upstream.
    
    The bounds checking in avc_ca_pmt() is not strict enough.  It should
    be checking "read_pos + 4" because it's reading 5 bytes.  If the
    "es_info_length" is non-zero then it reads a 6th byte so there needs to
    be an additional check for that.
    
    I also added checks for the "write_pos".  I don't think these are
    required because "read_pos" and "write_pos" are tied together so
    checking one ought to be enough.  But they make the code easier to
    understand for me.  The check on write_pos is:
    
            if (write_pos + 4 >= sizeof(c->operand) - 4) {
    
    The first "+ 4" is because we're writing 5 bytes and the last " - 4"
    is to leave space for the CRC.
    
    The other problem is that "length" can be invalid.  It comes from
    "data_length" in fdtv_ca_pmt().
    
    Cc: stable@vger.kernel.org
    Reported-by: Luo Likang <luolikang@nsfocus.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec0c91e2ebb8515b482281574b5d8b78288b6367
Author: Eugene Crosser <crosser@average.org>
Date:   Mon Oct 18 20:22:50 2021 +0200

    vrf: Revert "Reset skb conntrack connection..."
    
    commit 55161e67d44fdd23900be166a81e996abd6e3be9 upstream.
    
    This reverts commit 09e856d54bda5f288ef8437a90ab2b9b3eab83d1.
    
    When an interface is enslaved in a VRF, prerouting conntrack hook is
    called twice: once in the context of the original input interface, and
    once in the context of the VRF interface. If no special precausions are
    taken, this leads to creation of two conntrack entries instead of one,
    and breaks SNAT.
    
    Commit above was intended to avoid creation of extra conntrack entries
    when input interface is enslaved in a VRF. It did so by resetting
    conntrack related data associated with the skb when it enters VRF context.
    
    However it breaks netfilter operation. Imagine a use case when conntrack
    zone must be assigned based on the original input interface, rather than
    VRF interface (that would make original interfaces indistinguishable). One
    could create netfilter rules similar to these:
    
            chain rawprerouting {
                    type filter hook prerouting priority raw;
                    iif realiface1 ct zone set 1 return
                    iif realiface2 ct zone set 2 return
            }
    
    This works before the mentioned commit, but not after: zone assignment
    is "forgotten", and any subsequent NAT or filtering that is dependent
    on the conntrack zone does not work.
    
    Here is a reproducer script that demonstrates the difference in behaviour.
    
    ==========
    #!/bin/sh
    
    # This script demonstrates unexpected change of nftables behaviour
    # caused by commit 09e856d54bda5f28 ""vrf: Reset skb conntrack
    # connection on VRF rcv"
    # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=09e856d54bda5f288ef8437a90ab2b9b3eab83d1
    #
    # Before the commit, it was possible to assign conntrack zone to a
    # packet (or mark it for `notracking`) in the prerouting chanin, raw
    # priority, based on the `iif` (interface from which the packet
    # arrived).
    # After the change, # if the interface is enslaved in a VRF, such
    # assignment is lost. Instead, assignment based on the `iif` matching
    # the VRF master interface is honored. Thus it is impossible to
    # distinguish packets based on the original interface.
    #
    # This script demonstrates this change of behaviour: conntrack zone 1
    # or 2 is assigned depending on the match with the original interface
    # or the vrf master interface. It can be observed that conntrack entry
    # appears in different zone in the kernel versions before and after
    # the commit.
    
    IPIN=172.30.30.1
    IPOUT=172.30.30.2
    PFXL=30
    
    ip li sh vein >/dev/null 2>&1 && ip li del vein
    ip li sh tvrf >/dev/null 2>&1 && ip li del tvrf
    nft list table testct >/dev/null 2>&1 && nft delete table testct
    
    ip li add vein type veth peer veout
    ip li add tvrf type vrf table 9876
    ip li set veout master tvrf
    ip li set vein up
    ip li set veout up
    ip li set tvrf up
    /sbin/sysctl -w net.ipv4.conf.veout.accept_local=1
    /sbin/sysctl -w net.ipv4.conf.veout.rp_filter=0
    ip addr add $IPIN/$PFXL dev vein
    ip addr add $IPOUT/$PFXL dev veout
    
    nft -f - <<__END__
    table testct {
            chain rawpre {
                    type filter hook prerouting priority raw;
                    iif { veout, tvrf } meta nftrace set 1
                    iif veout ct zone set 1 return
                    iif tvrf ct zone set 2 return
                    notrack
            }
            chain rawout {
                    type filter hook output priority raw;
                    notrack
            }
    }
    __END__
    
    uname -rv
    conntrack -F
    ping -W 1 -c 1 -I vein $IPOUT
    conntrack -L
    
    Signed-off-by: Eugene Crosser <crosser@average.org>
    Acked-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Florian Westphal <fw@strlen.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6467b75cf9d137109579272c03ce631edb0928ee
Author: Erik Ekman <erik@kryo.se>
Date:   Sun Oct 17 19:16:57 2021 +0200

    sfc: Fix reading non-legacy supported link modes
    
    commit 041c61488236a5a84789083e3d9f0a51139b6edf upstream.
    
    Everything except the first 32 bits was lost when the pause flags were
    added. This makes the 50000baseCR2 mode flag (bit 34) not appear.
    
    I have tested this with a 10G card (SFN5122F-R7) by modifying it to
    return a non-legacy link mode (10000baseCR).
    
    Signed-off-by: Erik Ekman <erik@kryo.se>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f30822c0b4c35ec86187ab055263943dc71a6836
Author: Ming Lei <ming.lei@redhat.com>
Date:   Fri Oct 8 13:01:18 2021 +0800

    scsi: core: Put LLD module refcnt after SCSI device is released
    
    commit f2b85040acec9a928b4eb1b57a989324e8e38d3f upstream.
    
    SCSI host release is triggered when SCSI device is freed. We have to make
    sure that the low-level device driver module won't be unloaded before SCSI
    host instance is released because shost->hostt is required in the release
    handler.
    
    Make sure to put LLD module refcnt after SCSI device is released.
    
    Fixes a kernel panic of 'BUG: unable to handle page fault for address'
    reported by Changhui and Yi.
    
    Link: https://lore.kernel.org/r/20211008050118.1440686-1-ming.lei@redhat.com
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reported-by: Changhui Zhong <czhong@redhat.com>
    Reported-by: Yi Zhang <yi.zhang@redhat.com>
    Tested-by: Yi Zhang <yi.zhang@redhat.com>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>