commit dfbf345b63c31518e269f7f0adf55bbf57017e23
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Mar 11 14:17:30 2021 +0100

    Linux 5.10.23
    
    Tested-by: Hulk Robot <hulkrobot@huawei.com>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Jason Self <jason@bluehome.net>
    Tested-by: Ross Schmidt <ross.schm.dev@gmail.com>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Link: https://lore.kernel.org/r/20210310182834.696191666@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c8714d1faae829ebb4139c73bcbc0d66fd7edbc9
Author: Pascal Terjan <pterjan@google.com>
Date:   Tue Feb 23 22:10:46 2021 +0000

    nvme-pci: add quirks for Lexar 256GB SSD
    
    [ Upstream commit 6e6a6828c517fb6819479bf5187df5f39084eb9e ]
    
    Add the NVME_QUIRK_NO_NS_DESC_LIST and NVME_QUIRK_IGNORE_DEV_SUBNQN
    quirks for this buggy device.
    
    Reported and tested in https://bugs.mageia.org/show_bug.cgi?id=28417
    
    Signed-off-by: Pascal Terjan <pterjan@google.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e88e01440a480d2d30d18657ab9a2e2f2e4c23a8
Author: Julian Einwag <jeinwag-nvme@marcapo.com>
Date:   Tue Feb 16 13:25:43 2021 +0100

    nvme-pci: mark Seagate Nytro XM1440 as QUIRK_NO_NS_DESC_LIST.
    
    [ Upstream commit 5e112d3fb89703a4981ded60561b5647db3693bf ]
    
    The kernel fails to fully detect these SSDs, only the character devices
    are present:
    
    [   10.785605] nvme nvme0: pci function 0000:04:00.0
    [   10.876787] nvme nvme1: pci function 0000:81:00.0
    [   13.198614] nvme nvme0: missing or invalid SUBNQN field.
    [   13.198658] nvme nvme1: missing or invalid SUBNQN field.
    [   13.206896] nvme nvme0: Shutdown timeout set to 20 seconds
    [   13.215035] nvme nvme1: Shutdown timeout set to 20 seconds
    [   13.225407] nvme nvme0: 16/0/0 default/read/poll queues
    [   13.233602] nvme nvme1: 16/0/0 default/read/poll queues
    [   13.239627] nvme nvme0: Identify Descriptors failed (8194)
    [   13.246315] nvme nvme1: Identify Descriptors failed (8194)
    
    Adding the NVME_QUIRK_NO_NS_DESC_LIST fixes this problem.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205679
    Signed-off-by: Julian Einwag <jeinwag-nvme@marcapo.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3b659091587a39bc581e0cf2775b03d18ed97fa7
Author: Babu Moger <babu.moger@amd.com>
Date:   Tue Mar 2 12:51:31 2021 -0600

    KVM: SVM: Clear the CR4 register on reset
    
    [ Upstream commit 9e46f6c6c959d9bb45445c2e8f04a75324a0dfd0 ]
    
    This problem was reported on a SVM guest while executing kexec.
    Kexec fails to load the new kernel when the PCID feature is enabled.
    
    When kexec starts loading the new kernel, it starts the process by
    resetting the vCPU's and then bringing each vCPU online one by one.
    The vCPU reset is supposed to reset all the register states before the
    vCPUs are brought online. However, the CR4 register is not reset during
    this process. If this register is already setup during the last boot,
    all the flags can remain intact. The X86_CR4_PCIDE bit can only be
    enabled in long mode. So, it must be enabled much later in SMP
    initialization.  Having the X86_CR4_PCIDE bit set during SMP boot can
    cause a boot failures.
    
    Fix the issue by resetting the CR4 register in init_vmcb().
    
    Signed-off-by: Babu Moger <babu.moger@amd.com>
    Message-Id: <161471109108.30811.6392805173629704166.stgit@bmoger-ubuntu>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1611c323df9f5ddfc1ed36c9deec6052da9d40df
Author: Avri Altman <avri.altman@wdc.com>
Date:   Thu Feb 11 12:46:38 2021 +0200

    scsi: ufs: Fix a duplicate dev quirk number
    
    [ Upstream commit 9599a1cf23330008d90b7c232efe95de7510ff29 ]
    
    Fixes: 2b2bfc8aa519 ("scsi: ufs: Introduce a quirk to allow only page-aligned sg entries")
    Link: https://lore.kernel.org/r/20210211104638.292499-1-avri.altman@wdc.com
    Reviewed-by: Bean Huo <beanhuo@micron.com>
    Signed-off-by: Avri Altman <avri.altman@wdc.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2dba0f805416ef88c0fa4c3e4c5603aa4078e329
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Mon Feb 8 17:33:28 2021 -0600

    ASoC: Intel: sof_sdw: add quirk for HP Spectre x360 convertible
    
    [ Upstream commit d92e279dee56b4b65c1af21f972413f172a9734a ]
    
    This set of devices has SoundWire support along with DMICs.
    The DMI information was provided by users for 3 separate skus.
    
    BugLink: https://github.com/thesofproject/linux/issues/2700
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Link: https://lore.kernel.org/r/20210208233336.59449-4-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c08344abc9714f7ea43f338a177031d5ec1bcde3
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Mon Feb 8 17:33:26 2021 -0600

    ASoC: Intel: sof_sdw: reorganize quirks by generation
    
    [ Upstream commit 3d09cf8d0d791a41a75123e135f604d59f4aa870 ]
    
    The quirk table is a mess, let's reorganize it by generation before
    making sure that the quirks are consistent for each generation.
    
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Link: https://lore.kernel.org/r/20210208233336.59449-2-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1d3efd15e8a43ce2ea91c040f77ef67a0b2b3bc5
Author: Nadeem Athani <nadeem@cadence.com>
Date:   Tue Feb 9 15:46:21 2021 +0100

    PCI: cadence: Retrain Link to work around Gen2 training defect
    
    [ Upstream commit 4740b969aaf58adeca6829947a3ad8da423976cf ]
    
    Cadence controller will not initiate autonomous speed change if strapped
    as Gen2. The Retrain Link bit is set as quirk to enable this speed change.
    
    Link: https://lore.kernel.org/r/20210209144622.26683-3-nadeem@cadence.com
    Signed-off-by: Nadeem Athani <nadeem@cadence.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 015d38539db9121147682380111f7a460eb46df4
Author: Fabian Lesniak <fabian@lesniak-it.de>
Date:   Fri Feb 5 22:51:16 2021 +0100

    ALSA: usb-audio: add mixer quirks for Pioneer DJM-900NXS2
    
    [ Upstream commit fee03efc69345344c8851596d74d93199b175bfe ]
    
    This commit adds mixer quirks for the Pioneer DJM-900NXS2 mixer. This
    device has 6 capture channels, 5 of them allow setting the signal
    source. This adds controls for these, similar to the DJM-250Mk2.
    However, playpack channels are not controllable via software like on the
    250Mk2, as they can only be set manually on the mixing console.
    Read-only controls showing the currently selected playback channels are
    omitted.
    
    Signed-off-by: Fabian Lesniak <fabian@lesniak-it.de>
    Link: https://lore.kernel.org/r/20210205215116.258724-2-fabian@lesniak-it.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d78acca2afe50a73e89617732ba029098e7abaac
Author: Olivia Mackintosh <livvy@base.nu>
Date:   Fri Feb 5 18:42:56 2021 +0000

    ALSA: usb-audio: Add DJM750 to Pioneer mixer quirk
    
    [ Upstream commit a07df82c799013236aa90a140785775eda9f9523 ]
    
    This allows for N different devices to use the pioneer mixer quirk for
    setting capture/record type and recording level. The impementation has
    not changed much with the exception of an additional mask on
    private_value to allow storing of a device index:
            DEVICE MASK     0xff000000
            GROUP_MASK      0x00ff0000
            VALUE_MASK      0x0000ffff
    
    This could be improved by changing the arrays of wValues for each
    channel to contain named definitions (e.g. SND_DJM_CAP_LINE). It would
    improve readability and perhaps would allow using the same array for
    multiple channels. The channel number can be specified on the control
    next to the wIndex.
    
    Feedback is very much appreciated as I'm not the most proficient C
    programmer but am learning as I go.
    
    Signed-off-by: Olivia Mackintosh <livvy@base.nu>
    Link: https://lore.kernel.org/r/20210205184256.10201-2-livvy@base.nu
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 96c4c0a9405e0a5b9c8fcb6d338628a799a3b350
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Jan 30 21:33:23 2021 +0100

    HID: i2c-hid: Add I2C_HID_QUIRK_NO_IRQ_AFTER_RESET for ITE8568 EC on Voyo Winpad A15
    
    [ Upstream commit fc6a31b00739356809dd566e16f2c4325a63285d ]
    
    The ITE8568 EC on the Voyo Winpad A15 presents itself as an I2C-HID
    attached keyboard and mouse (which seems to never send any events).
    
    This needs the I2C_HID_QUIRK_NO_IRQ_AFTER_RESET quirk, otherwise we get
    the following errors:
    
    [ 3688.770850] i2c_hid i2c-ITE8568:00: failed to reset device.
    [ 3694.915865] i2c_hid i2c-ITE8568:00: failed to reset device.
    [ 3701.059717] i2c_hid i2c-ITE8568:00: failed to reset device.
    [ 3707.205944] i2c_hid i2c-ITE8568:00: failed to reset device.
    [ 3708.227940] i2c_hid i2c-ITE8568:00: can't add hid device: -61
    [ 3708.236518] i2c_hid: probe of i2c-ITE8568:00 failed with error -61
    
    Which leads to a significant boot delay.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5b652628349903df12c03154aad81d0afd987d21
Author: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Date:   Thu Dec 10 16:55:10 2020 +0800

    mmc: sdhci-of-dwcmshc: set SDHCI_QUIRK2_PRESET_VALUE_BROKEN
    
    [ Upstream commit 5f7dfda4f2cec580c135fd81d96a05006651c128 ]
    
    The SDHCI_PRESET_FOR_* registers are not set(all read as zeros), so
    set the quirk.
    
    Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
    Link: https://lore.kernel.org/r/20201210165510.76b917e5@xhacker.debian
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e62bdb34858cf25262e36f9f41aaf558577576ac
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Date:   Wed Jan 13 19:33:33 2021 +0100

    drm/msm/a5xx: Remove overwriting A5XX_PC_DBG_ECO_CNTL register
    
    [ Upstream commit 8f03c30cb814213e36032084a01f49a9e604a3e3 ]
    
    The PC_DBG_ECO_CNTL register on the Adreno A5xx family gets
    programmed to some different values on a per-model basis.
    At least, this is what we intend to do here;
    
    Unfortunately, though, this register is being overwritten with a
    static magic number, right after applying the GPU-specific
    configuration (including the GPU-specific quirks) and that is
    effectively nullifying the efforts.
    
    Let's remove the redundant and wrong write to the PC_DBG_ECO_CNTL
    register in order to retain the wanted configuration for the
    target GPU.
    
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
    Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e74b237ef989facf9b3e0874cf9fddd0c6df957f
Author: Kiwoong Kim <kwmad.kim@samsung.com>
Date:   Tue Jan 19 12:33:42 2021 +0900

    scsi: ufs: ufs-exynos: Use UFSHCD_QUIRK_ALIGN_SG_WITH_PAGE_SIZE
    
    [ Upstream commit f1ef9047aaab036edb39261b0a7a6bdcf3010b87 ]
    
    Exynos needs scatterlist entries aligned to page size because it isn't
    capable of transferring data contained in one DATA IN operation to seversal
    areas in memory.
    
    Link: https://lore.kernel.org/r/80d7e27d6ec537e650a6bd74897b6c60618efcdc.1611026909.git.kwmad.kim@samsung.com
    Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0905bfe69ac2240a6b01b06da21b7c5da0d028ae
Author: Kiwoong Kim <kwmad.kim@samsung.com>
Date:   Mon Dec 21 10:24:41 2020 +0900

    scsi: ufs: ufs-exynos: Apply vendor-specific values for three timeouts
    
    [ Upstream commit a967ddb22d94eb476ccef983b5f2730fa4d184d0 ]
    
    Set optimized values for the following timeouts:
    
     - FC0_PROTECTION_TIMER
     - TC0_REPLAY_TIMER
     - AFC0_REQUEST_TIMER
    
    Exynos doesn't yet use traffic class #1.
    
    Link: https://lore.kernel.org/r/a0ff44f665a4f31d2f945fd71de03571204c576c.1608513782.git.kwmad.kim@samsung.com
    Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c32b34115357ca555189b48296bbd4242b5cd256
Author: Kiwoong Kim <kwmad.kim@samsung.com>
Date:   Tue Jan 19 12:33:41 2021 +0900

    scsi: ufs: Introduce a quirk to allow only page-aligned sg entries
    
    [ Upstream commit 2b2bfc8aa519f696087475ed8e8c61850c673272 ]
    
    Some SoCs require a single scatterlist entry for smaller than page size,
    i.e. 4KB. When dispatching commands with more than one scatterlist entry
    under 4KB in size the following behavior is observed:
    
    A command to read a block range is dispatched with two scatterlist entries
    that are named AAA and BBB. After dispatching, the host builds two PRDT
    entries and during transmission, device sends just one DATA IN because
    device doesn't care about host DMA. The host then transfers the combined
    amount of data from start address of the area named AAA. As a consequence,
    the area that follows AAA in memory would be corrupted.
    
        |<------------->|
        +-------+------------         +-------+
        +  AAA  + (corrupted)   ...   +  BBB  +
        +-------+------------         +-------+
    
    To avoid this we need to enforce page size alignment for sg entries.
    
    Link: https://lore.kernel.org/r/56dddef94f60bd9466fd77e69f64bbbd657ed2a1.1611026909.git.kwmad.kim@samsung.com
    Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eece8fe5ebb0ef25151840df73a71857e7177b70
Author: Aswath Govindraju <a-govindraju@ti.com>
Date:   Tue Jan 5 16:28:12 2021 +0530

    misc: eeprom_93xx46: Add quirk to support Microchip 93LC46B eeprom
    
    [ Upstream commit f6f1f8e6e3eea25f539105d48166e91f0ab46dd1 ]
    
    A dummy zero bit is sent preceding the data during a read transfer by the
    Microchip 93LC46B eeprom (section 2.7 of[1]). This results in right shift
    of data during a read. In order to ignore this bit a quirk can be added to
    send an extra zero bit after the read address.
    
    Add a quirk to ignore the zero bit sent before data by adding a zero bit
    after the read address.
    
    [1] - https://www.mouser.com/datasheet/2/268/20001749K-277859.pdf
    
    Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
    Link: https://lore.kernel.org/r/20210105105817.17644-3-a-govindraju@ti.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2fc01226c288413261085450954faf8d027b65c0
Author: Kiwoong Kim <kwmad.kim@samsung.com>
Date:   Mon Dec 21 10:24:40 2020 +0900

    scsi: ufs: Add a quirk to permit overriding UniPro defaults
    
    [ Upstream commit b1d0d2eb89d4e3a25b212a9d836587503537067e ]
    
    The UniPro specification states that attribute IDs of the following
    parameters are vendor-specific so some SoCs could have no regions at the
    defined addresses:
    
     - DME_LocalFC0ProtectionTimeOutVal
     - DME_LocalTC0ReplayTimeOutVal
     - DME_LocalAFC0ReqTimeOutVal
    
    In addition, the following parameters should be set considering the
    compatibility between host and device.
    
     - PA_PWRMODEUSERDATA0
     - PA_PWRMODEUSERDATA1
     - PA_PWRMODEUSERDATA2
     - PA_PWRMODEUSERDATA3
     - PA_PWRMODEUSERDATA4
     - PA_PWRMODEUSERDATA5
    
    Introduce a quirk to allow vendor drivers to override the UniPro defaults.
    
    Link: https://lore.kernel.org/r/1fedd3dea0ccc980913a5995a10510d86a5b01b9.1608513782.git.kwmad.kim@samsung.com
    Acked-by: Avri Altman <Avri.Altman@wdc.com>
    Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dbaa2667515edf5b0c3f9deb56d60bfedcea7651
Author: Stanley Chu <stanley.chu@mediatek.com>
Date:   Tue Dec 22 15:29:28 2020 +0800

    scsi: ufs-mediatek: Enable UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL
    
    [ Upstream commit 46ec9592ffd679fa26142dcb9e5119aad7e60b55 ]
    
    Flush during hibern8 is sufficient on MediaTek platforms, thus enable
    UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL to skip enabling
    fWriteBoosterBufferFlush during WriteBooster initialization.
    
    Link: https://lore.kernel.org/r/20201222072928.32328-1-stanley.chu@mediatek.com
    Reviewed-by: Avri Altman <avri.altman@wdc.com>
    Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ff72a41132b3422e9be342889513446a3367d653
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Thu Feb 4 14:33:01 2021 -0600

    ASoC: Intel: sof_sdw: add missing TGL_HDMI quirk for Dell SKU 0A32
    
    [ Upstream commit 45c92ec32b43c6cb42341ebf07577eefed9d87ec ]
    
    We missed adding the TGL_HDMI quirk which is very much needed to
    expose the 4 display pipelines and will be required on TGL topologies.
    
    Fixes: 488cdbd8931fe ('ASoC: Intel: sof_sdw: add quirk for new TigerLake-SDCA device')
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Link: https://lore.kernel.org/r/20210204203312.27112-4-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c7ebe45e403dd38bc93ee56820a4a5cc4d67f66e
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Mon Feb 1 15:28:43 2021 +0100

    KVM: x86: Supplement __cr4_reserved_bits() with X86_FEATURE_PCID check
    
    [ Upstream commit 4683d758f48e6ae87d3d3493ffa00aceb955ee16 ]
    
    Commit 7a873e455567 ("KVM: selftests: Verify supported CR4 bits can be set
    before KVM_SET_CPUID2") reveals that KVM allows to set X86_CR4_PCIDE even
    when PCID support is missing:
    
    ==== Test Assertion Failure ====
      x86_64/set_sregs_test.c:41: rc
      pid=6956 tid=6956 - Invalid argument
         1  0x000000000040177d: test_cr4_feature_bit at set_sregs_test.c:41
         2  0x00000000004014fc: main at set_sregs_test.c:119
         3  0x00007f2d9346d041: ?? ??:0
         4  0x000000000040164d: _start at ??:?
      KVM allowed unsupported CR4 bit (0x20000)
    
    Add X86_FEATURE_PCID feature check to __cr4_reserved_bits() to make
    kvm_is_valid_cr4() fail.
    
    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Message-Id: <20210201142843.108190-1-vkuznets@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 422da3196be9ee17a642c1fe98d2dd07bf088ec0
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Tue Nov 10 16:00:57 2020 -0600

    PCI: Add function 1 DMA alias quirk for Marvell 9215 SATA controller
    
    [ Upstream commit 059983790a4c963d92943e55a61fca55be427d55 ]
    
    Add function 1 DMA alias quirk for Marvell 88SS9215 PCIe SSD Controller.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=42679#c135
    Link: https://lore.kernel.org/r/20201110220516.697934-1-helgaas@kernel.org
    Reported-by: John Smith <LK7S2ED64JHGLKj75shg9klejHWG49h5hk@protonmail.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0ff1f97510fde30905cb8cafbd5b0daca72e2315
Author: Roger Quadros <rogerq@ti.com>
Date:   Mon Nov 23 12:49:31 2020 +0200

    usb: cdns3: fix NULL pointer dereference on no platform data
    
    [ Upstream commit 448373d9db1a7000072f65103af19e20503f0c0c ]
    
    Some platforms (e.g. TI) will not have any platform data which will
    lead to NULL pointer dereference if we don't check for NULL pdata.
    
    Fixes: 7cea9657756b ("usb: cdns3: add quirk for enable runtime pm by default")
    Reported-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Roger Quadros <rogerq@ti.com>
    Acked-by: Pawel Laszczak <pawell@cadence.com>
    Signed-off-by: Peter Chen <peter.chen@nxp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8694c4e2b19c26bc4c0a714d362f6b53cde2d650
Author: Peter Chen <peter.chen@nxp.com>
Date:   Mon Sep 28 15:20:03 2020 +0800

    usb: cdns3: add quirk for enable runtime pm by default
    
    [ Upstream commit 7cea9657756b2c83069a775c0671ff169bce456a ]
    
    Some vendors (eg: NXP) may want to enable runtime pm by default for
    power saving, add one quirk for it.
    
    Reviewed-by: Jun Li <jun.li@nxp.com>
    Signed-off-by: Peter Chen <peter.chen@nxp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit febf7d870371ea5b064299ddda2116600824c90c
Author: Peter Chen <peter.chen@nxp.com>
Date:   Fri May 22 18:08:31 2020 +0800

    usb: cdns3: host: add xhci_plat_priv quirk XHCI_SKIP_PHY_INIT
    
    [ Upstream commit 68ed3f3d8a057bd34254e885a6306fedc0936e50 ]
    
    cdns3 manages PHY by own DRD driver, so skip the management by
    HCD core.
    
    Reviewed-by: Jun Li <jun.li@nxp.com>
    Reviewed-by: Pawel Laszczak <pawell@cadence.com>
    Signed-off-by: Peter Chen <peter.chen@nxp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3db17e283a923af5dc8e9ba44b3173306dddfd17
Author: Peter Chen <peter.chen@nxp.com>
Date:   Fri May 22 17:56:30 2020 +0800

    usb: cdns3: host: add .suspend_quirk for xhci-plat.c
    
    [ Upstream commit ed22764847e8100f0af9af91ccfa58e5c559bd47 ]
    
    cdns3 has some special PM sequence between xhci_bus_suspend and
    xhci_suspend, add quirk to implement it.
    
    Reviewed-by: Pawel Laszczak <pawell@cadence.com>
    Signed-off-by: Peter Chen <peter.chen@nxp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1b2ac1d95fb1619ed7dc345fe2e4ca4df2a81e3d
Author: Chris Chiu <chiu@endlessos.org>
Date:   Tue Dec 8 14:04:14 2020 +0800

    ASoC: Intel: bytcr_rt5640: Add quirk for ARCHOS Cesium 140
    
    [ Upstream commit 1bea2256aa96a2d7b1b576eb74e29d79edc9bea8 ]
    
    Tha ARCHOS Cesium 140 tablet has problem with the jack-sensing,
    thus the heaset functions are not working.
    
    Add quirk for this model to select the correct input map, jack-detect
    options and channel map to enable jack sensing and headset microphone.
    This device uses IN1 for its internal MIC and JD2 for jack-detect.
    
    Signed-off-by: Chris Chiu <chiu@endlessos.org>
    Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20201208060414.27646-1-chiu@endlessos.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d3116e06fb16ad53183036c9e425f8d0a2acf200
Author: Jasper St. Pierre <jstpierre@mecheye.net>
Date:   Wed Dec 2 14:39:42 2020 +0800

    ACPI: video: Add DMI quirk for GIGABYTE GB-BXBT-2807
    
    [ Upstream commit 25417185e9b5ff90746d50769d2a3fcd1629e254 ]
    
    The GIGABYTE GB-BXBT-2807 is a mini-PC which uses off the shelf
    components, like an Intel GPU which is meant for mobile systems.
    As such, it, by default, has a backlight controller exposed.
    
    Unfortunately, the backlight controller only confuses userspace, which
    sees the existence of a backlight device node and has the unrealistic
    belief that there is actually a backlight there!
    
    Add a DMI quirk to force the backlight off on this system.
    
    Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
    Reviewed-by: Chris Chiu <chiu@endlessos.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c5188a98d2fbac2e00e257f1ac0cff093c54ae9b
Author: Daniel Lee Kruse <daniel.lee.kruse@protonmail.com>
Date:   Wed Sep 30 05:36:35 2020 +0200

    media: cx23885: add more quirks for reset DMA on some AMD IOMMU
    
    [ Upstream commit dbf0b3a7b719eb3f72cb53c2ce7d34a012a9c261 ]
    
    On AMD Family 15h (Models 30h-3fh), I/O Memory Management Unit
    RiSC engine sometimes stalls, requiring a reset.
    
    As result, MythTV and w-scan won't scan channels on the AMD Kaveri
    APU with the Hauppauge QuadHD TV tuner card.
    
    For the solution I added the Input/Output Memory Management Unit's PCI
    Identity of 0x1423 to the broken_dev_id[] array, which is used by
    a quirks logic meant to fix similar problems with other AMD
    chipsets.
    
    Signed-off-by: Daniel Lee Kruse <daniel.lee.kruse@protonmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 748446897d367d86b28406467072ab65079d0dc3
Author: Ethan Warth <redyoshi49q@gmail.com>
Date:   Tue Nov 17 09:48:00 2020 +0100

    HID: mf: add support for 0079:1846 Mayflash/Dragonrise USB Gamecube Adapter
    
    [ Upstream commit 1008230f2abeb624f6d71b2e1c424fa4eeebbf84 ]
    
    Mayflash/Dragonrise seems to have yet another device ID for one of their
    Gamecube controller adapters.  Previous to this commit, the adapter
    registered only one /dev/input/js* device, and all controller inputs (from
    any controller) were mapped to this device.  This patch defines the 1846
    USB device ID and enables the HID_QUIRK_MULTI_INPUT quirk for it, which
    fixes that (with the patch, four /dev/input/js* devices are created, one
    for each of the four controller ports).
    
    Signed-off-by: Ethan Warth <redyoshi49q@gmail.com>
    Tested-by: Wladimir J. van der Laan <laanwj@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8fb656fefdddd4c53c692f9d244a259ba3c9d961
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Nov 23 16:16:25 2020 +0100

    platform/x86: acer-wmi: Add ACER_CAP_KBD_DOCK quirk for the Aspire Switch 10E SW3-016
    
    [ Upstream commit bf753400280d1384abb783efc0b42c491d6deec3 ]
    
    Add the Acer Aspire Switch 10E SW3-016 to the list of models which use the
    Acer Switch WMI interface for reporting SW_TABLET_MODE.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20201123151625.5530-1-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ba1a647e0f113944b54d7a4bd8db2f72caa76c6e
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Oct 19 20:56:28 2020 +0200

    platform/x86: acer-wmi: Add support for SW_TABLET_MODE on Switch devices
    
    [ Upstream commit 5c54cb6c627e8f50f490e6b5656051a5ac29eab4 ]
    
    Add support for SW_TABLET_MODE on the Acer Switch 10 (SW5-012) and the
    acer Switch 10 (S1003) models.
    
    There is no way to detect if this is supported, so this uses DMI based
    quirks setting force_caps to ACER_CAP_KBD_DOCK (these devices have no
    other acer-wmi based functionality).
    
    The new SW_TABLET_MODE functionality can be tested on devices which
    are not in the DMI table by passing acer_wmi.force_caps=0x40 on the
    kernel commandline.
    
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20201019185628.264473-6-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2c9132e543b7cc5aa164f7fcb5106ae429a816ef
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Oct 19 20:56:27 2020 +0200

    platform/x86: acer-wmi: Add ACER_CAP_SET_FUNCTION_MODE capability flag
    
    [ Upstream commit 82cb8a5c395ea5be20e0fe31a8fe84380a502ca5 ]
    
    Not all devices supporting WMID_GUID3 support the wmid3_set_function_mode()
    call, leading to errors like these:
    
    [   60.138358] acer_wmi: Enabling RF Button failed: 0x1 - 0xff
    [   60.140036] acer_wmi: Enabling Launch Manager failed: 0x1 - 0xff
    
    Add an ACER_CAP_SET_FUNCTION_MODE capability flag, so that these calls
    can be disabled through the new force_caps mechanism.
    
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20201019185628.264473-5-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 039cd40179e94a6eec5c76f5a143a39f44cdcfda
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Oct 19 20:56:26 2020 +0200

    platform/x86: acer-wmi: Add new force_caps module parameter
    
    [ Upstream commit 39aa009bb66f9d5fbd1e58ca4aa03d6e6f2c9915 ]
    
    Add a new force_caps module parameter to allow overriding the drivers
    builtin capability detection mechanism.
    
    This can be used to for example:
    -Disable rfkill functionality on devices where there is an AA OEM DMI
     record advertising non functional rfkill switches
    -Force loading of the driver on devices with a missing AA OEM DMI record
    
    Note that force_caps is -1 when unset, this allows forcing the
    capability field to 0, which results in acer-wmi only providing WMI
    hotkey handling while disabling all other (led, rfkill, backlight)
    functionality.
    
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20201019185628.264473-4-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 74848026bcb1b86071f3adddd6988899e28fa74c
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Oct 19 20:56:25 2020 +0200

    platform/x86: acer-wmi: Cleanup accelerometer device handling
    
    [ Upstream commit 9feb0763e4985ccfae632de3bb2f029cc8389842 ]
    
    Cleanup accelerometer device handling:
    -Drop acer_wmi_accel_destroy instead directly call input_unregister_device.
    -The information tracked by the CAP_ACCEL flag mirrors acer_wmi_accel_dev
     being NULL. Drop the CAP flag, this is a preparation change for allowing
     users to override the capability flags. Dropping the flag stops users
     from causing a NULL pointer dereference by forcing the capability.
    
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20201019185628.264473-3-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit be52e3ea452039fb416caac61e71aa2fc426a711
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Oct 19 20:56:24 2020 +0200

    platform/x86: acer-wmi: Cleanup ACER_CAP_FOO defines
    
    [ Upstream commit 7c936d8d26afbc74deac0651d613dead2f76e81c ]
    
    Cleanup the ACER_CAP_FOO defines:
    -Switch to using BIT() macro.
    -The ACER_CAP_RFBTN flag is set, but it is never checked anywhere, drop it.
    -Drop the unused ACER_CAP_ANY define.
    
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20201019185628.264473-2-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b159a9a4d357d42d339ea9e459defb057ce9ac49
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon Nov 16 12:57:13 2020 +0200

    bus: ti-sysc: Implement GPMC debug quirk to drop platform data
    
    [ Upstream commit cfeeea60af2f01c13b94d57a9bb1291e7bc181da ]
    
    We need to enable no-reset-on-init quirk for GPMC if the config
    option for CONFIG_OMAP_GPMC_DEBUG is set. Otherwise the GPMC
    driver code is unable to show the bootloader configured timings.
    
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f7f227eb32d1ab0acb1d8358996a22dccddf48aa
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Wed Nov 11 15:43:15 2020 -0600

    ASoC: Intel: sof_sdw: add quirk for new TigerLake-SDCA device
    
    [ Upstream commit 488cdbd8931fe4bc7f374a8b429e81d0e4b7ac76 ]
    
    Add quirks for jack detection, rt715 DAI and number of speakers.
    
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Rander Wang <rander.wang@linux.intel.com>
    Link: https://lore.kernel.org/r/20201111214318.150529-2-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 36b3ba412d7c64121aca4af9fa7804efa567255f
Author: Tsuchiya Yuto <kitakar@gmail.com>
Date:   Wed Oct 28 23:23:46 2020 +0900

    mwifiex: pcie: skip cancel_work_sync() on reset failure path
    
    [ Upstream commit 4add4d988f95f47493500a7a19c623827061589b ]
    
    If a reset is performed, but even the reset fails for some reasons (e.g.,
    on Surface devices, the fw reset requires another quirks),
    cancel_work_sync() hangs in mwifiex_cleanup_pcie().
    
        # firmware went into a bad state
        [...]
        [ 1608.281690] mwifiex_pcie 0000:03:00.0: info: shutdown mwifiex...
        [ 1608.282724] mwifiex_pcie 0000:03:00.0: rx_pending=0, tx_pending=1,       cmd_pending=0
        [ 1608.292400] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
        [ 1608.292405] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
        # reset performed after firmware went into a bad state
        [ 1609.394320] mwifiex_pcie 0000:03:00.0: WLAN FW already running! Skip FW dnld
        [ 1609.394335] mwifiex_pcie 0000:03:00.0: WLAN FW is active
        # but even the reset failed
        [ 1619.499049] mwifiex_pcie 0000:03:00.0: mwifiex_cmd_timeout_func: Timeout cmd id = 0xfa, act = 0xe000
        [ 1619.499094] mwifiex_pcie 0000:03:00.0: num_data_h2c_failure = 0
        [ 1619.499103] mwifiex_pcie 0000:03:00.0: num_cmd_h2c_failure = 0
        [ 1619.499110] mwifiex_pcie 0000:03:00.0: is_cmd_timedout = 1
        [ 1619.499117] mwifiex_pcie 0000:03:00.0: num_tx_timeout = 0
        [ 1619.499124] mwifiex_pcie 0000:03:00.0: last_cmd_index = 0
        [ 1619.499133] mwifiex_pcie 0000:03:00.0: last_cmd_id: fa 00 07 01 07 01 07 01 07 01
        [ 1619.499140] mwifiex_pcie 0000:03:00.0: last_cmd_act: 00 e0 00 00 00 00 00 00 00 00
        [ 1619.499147] mwifiex_pcie 0000:03:00.0: last_cmd_resp_index = 3
        [ 1619.499155] mwifiex_pcie 0000:03:00.0: last_cmd_resp_id: 07 81 07 81 07 81 07 81 07 81
        [ 1619.499162] mwifiex_pcie 0000:03:00.0: last_event_index = 2
        [ 1619.499169] mwifiex_pcie 0000:03:00.0: last_event: 58 00 58 00 58 00 58 00 58 00
        [ 1619.499177] mwifiex_pcie 0000:03:00.0: data_sent=0 cmd_sent=1
        [ 1619.499185] mwifiex_pcie 0000:03:00.0: ps_mode=0 ps_state=0
        [ 1619.499215] mwifiex_pcie 0000:03:00.0: info: _mwifiex_fw_dpc: unregister device
        # mwifiex_pcie_work hang happening
        [ 1823.233923] INFO: task kworker/3:1:44 blocked for more than 122 seconds.
        [ 1823.233932]       Tainted: G        WC OE     5.10.0-rc1-1-mainline #1
        [ 1823.233935] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
        [ 1823.233940] task:kworker/3:1     state:D stack:    0 pid:   44 ppid:     2 flags:0x00004000
        [ 1823.233960] Workqueue: events mwifiex_pcie_work [mwifiex_pcie]
        [ 1823.233965] Call Trace:
        [ 1823.233981]  __schedule+0x292/0x820
        [ 1823.233990]  schedule+0x45/0xe0
        [ 1823.233995]  schedule_timeout+0x11c/0x160
        [ 1823.234003]  wait_for_completion+0x9e/0x100
        [ 1823.234012]  __flush_work.isra.0+0x156/0x210
        [ 1823.234018]  ? flush_workqueue_prep_pwqs+0x130/0x130
        [ 1823.234026]  __cancel_work_timer+0x11e/0x1a0
        [ 1823.234035]  mwifiex_cleanup_pcie+0x28/0xd0 [mwifiex_pcie]
        [ 1823.234049]  mwifiex_free_adapter+0x24/0xe0 [mwifiex]
        [ 1823.234060]  _mwifiex_fw_dpc+0x294/0x560 [mwifiex]
        [ 1823.234074]  mwifiex_reinit_sw+0x15d/0x300 [mwifiex]
        [ 1823.234080]  mwifiex_pcie_reset_done+0x50/0x80 [mwifiex_pcie]
        [ 1823.234087]  pci_try_reset_function+0x5c/0x90
        [ 1823.234094]  process_one_work+0x1d6/0x3a0
        [ 1823.234100]  worker_thread+0x4d/0x3d0
        [ 1823.234107]  ? rescuer_thread+0x410/0x410
        [ 1823.234112]  kthread+0x142/0x160
        [ 1823.234117]  ? __kthread_bind_mask+0x60/0x60
        [ 1823.234124]  ret_from_fork+0x22/0x30
        [...]
    
    This is a deadlock caused by calling cancel_work_sync() in
    mwifiex_cleanup_pcie():
    
    - Device resets are done via mwifiex_pcie_card_reset()
    - which schedules card->work to call mwifiex_pcie_card_reset_work()
    - which calls pci_try_reset_function().
    - This leads to mwifiex_pcie_reset_done() be called on the same workqueue,
      which in turn calls
    - mwifiex_reinit_sw() and that calls
    - _mwifiex_fw_dpc().
    
    The problem is now that _mwifiex_fw_dpc() calls mwifiex_free_adapter()
    in case firmware initialization fails. That ends up calling
    mwifiex_cleanup_pcie().
    
    Note that all those calls are still running on the workqueue. So when
    mwifiex_cleanup_pcie() now calls cancel_work_sync(), it's really waiting
    on itself to complete, causing a deadlock.
    
    This commit fixes the deadlock by skipping cancel_work_sync() on a reset
    failure path.
    
    After this commit, when reset fails, the following output is
    expected to be shown:
    
        kernel: mwifiex_pcie 0000:03:00.0: info: _mwifiex_fw_dpc: unregister device
        kernel: mwifiex: Failed to bring up adapter: -5
        kernel: mwifiex_pcie 0000:03:00.0: reinit failed: -5
    
    To reproduce this issue, for example, try putting the root port of wifi
    into D3 (replace "00:1d.3" with your setup).
    
        # put into D3 (root port)
        sudo setpci -v -s 00:1d.3 CAP_PM+4.b=0b
    
    Cc: Maximilian Luz <luzmaximilian@gmail.com>
    Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20201028142346.18355-1-kitakar@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f5526b77335da764e2789c7ee7a08c36cfd7422b
Author: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Date:   Wed Sep 30 13:01:38 2020 -0700

    Bluetooth: btqca: Add valid le states quirk
    
    [ Upstream commit 547801380ec7e6104ea679f599d03c342b4b39a0 ]
    
    WCN3991 supports connectable advertisements so we need to add the valid
    le states quirk so the 'central-peripheral' role is exposed in
    userspace.
    
    Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 93d20ce4c47f9678011c4b293aa4242a8e184508
Author: Andrey Ryabinin <arbn@yandex-team.com>
Date:   Wed Feb 17 17:30:04 2021 +0300

    iommu/amd: Fix sleeping in atomic in increase_address_space()
    
    commit 140456f994195b568ecd7fc2287a34eadffef3ca upstream.
    
    increase_address_space() calls get_zeroed_page(gfp) under spin_lock with
    disabled interrupts. gfp flags passed to increase_address_space() may allow
    sleeping, so it comes to this:
    
     BUG: sleeping function called from invalid context at mm/page_alloc.c:4342
     in_atomic(): 1, irqs_disabled(): 1, pid: 21555, name: epdcbbf1qnhbsd8
    
     Call Trace:
      dump_stack+0x66/0x8b
      ___might_sleep+0xec/0x110
      __alloc_pages_nodemask+0x104/0x300
      get_zeroed_page+0x15/0x40
      iommu_map_page+0xdd/0x3e0
      amd_iommu_map+0x50/0x70
      iommu_map+0x106/0x220
      vfio_iommu_type1_ioctl+0x76e/0x950 [vfio_iommu_type1]
      do_vfs_ioctl+0xa3/0x6f0
      ksys_ioctl+0x66/0x70
      __x64_sys_ioctl+0x16/0x20
      do_syscall_64+0x4e/0x100
      entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Fix this by moving get_zeroed_page() out of spin_lock/unlock section.
    
    Fixes: 754265bcab ("iommu/amd: Fix race in increase_address_space()")
    Signed-off-by: Andrey Ryabinin <arbn@yandex-team.com>
    Acked-by: Will Deacon <will@kernel.org>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210217143004.19165-1-arbn@yandex-team.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Andrey Ryabinin <arbn@yandex-team.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bf6dd437c3bad5014cbd2b16dc4240b8069267b3
Author: Nikolay Borisov <nborisov@suse.com>
Date:   Mon Feb 22 18:40:44 2021 +0200

    btrfs: don't flush from btrfs_delayed_inode_reserve_metadata
    
    commit 4d14c5cde5c268a2bc26addecf09489cb953ef64 upstream
    
    Calling btrfs_qgroup_reserve_meta_prealloc from
    btrfs_delayed_inode_reserve_metadata can result in flushing delalloc
    while holding a transaction and delayed node locks. This is deadlock
    prone. In the past multiple commits:
    
     * ae5e070eaca9 ("btrfs: qgroup: don't try to wait flushing if we're
    already holding a transaction")
    
     * 6f23277a49e6 ("btrfs: qgroup: don't commit transaction when we already
     hold the handle")
    
    Tried to solve various aspects of this but this was always a
    whack-a-mole game. Unfortunately those 2 fixes don't solve a deadlock
    scenario involving btrfs_delayed_node::mutex. Namely, one thread
    can call btrfs_dirty_inode as a result of reading a file and modifying
    its atime:
    
      PID: 6963   TASK: ffff8c7f3f94c000  CPU: 2   COMMAND: "test"
      #0  __schedule at ffffffffa529e07d
      #1  schedule at ffffffffa529e4ff
      #2  schedule_timeout at ffffffffa52a1bdd
      #3  wait_for_completion at ffffffffa529eeea             <-- sleeps with delayed node mutex held
      #4  start_delalloc_inodes at ffffffffc0380db5
      #5  btrfs_start_delalloc_snapshot at ffffffffc0393836
      #6  try_flush_qgroup at ffffffffc03f04b2
      #7  __btrfs_qgroup_reserve_meta at ffffffffc03f5bb6     <-- tries to reserve space and starts delalloc inodes.
      #8  btrfs_delayed_update_inode at ffffffffc03e31aa      <-- acquires delayed node mutex
      #9  btrfs_update_inode at ffffffffc0385ba8
     #10  btrfs_dirty_inode at ffffffffc038627b               <-- TRANSACTIION OPENED
     #11  touch_atime at ffffffffa4cf0000
     #12  generic_file_read_iter at ffffffffa4c1f123
     #13  new_sync_read at ffffffffa4ccdc8a
     #14  vfs_read at ffffffffa4cd0849
     #15  ksys_read at ffffffffa4cd0bd1
     #16  do_syscall_64 at ffffffffa4a052eb
     #17  entry_SYSCALL_64_after_hwframe at ffffffffa540008c
    
    This will cause an asynchronous work to flush the delalloc inodes to
    happen which can try to acquire the same delayed_node mutex:
    
      PID: 455    TASK: ffff8c8085fa4000  CPU: 5   COMMAND: "kworker/u16:30"
      #0  __schedule at ffffffffa529e07d
      #1  schedule at ffffffffa529e4ff
      #2  schedule_preempt_disabled at ffffffffa529e80a
      #3  __mutex_lock at ffffffffa529fdcb                    <-- goes to sleep, never wakes up.
      #4  btrfs_delayed_update_inode at ffffffffc03e3143      <-- tries to acquire the mutex
      #5  btrfs_update_inode at ffffffffc0385ba8              <-- this is the same inode that pid 6963 is holding
      #6  cow_file_range_inline.constprop.78 at ffffffffc0386be7
      #7  cow_file_range at ffffffffc03879c1
      #8  btrfs_run_delalloc_range at ffffffffc038894c
      #9  writepage_delalloc at ffffffffc03a3c8f
     #10  __extent_writepage at ffffffffc03a4c01
     #11  extent_write_cache_pages at ffffffffc03a500b
     #12  extent_writepages at ffffffffc03a6de2
     #13  do_writepages at ffffffffa4c277eb
     #14  __filemap_fdatawrite_range at ffffffffa4c1e5bb
     #15  btrfs_run_delalloc_work at ffffffffc0380987         <-- starts running delayed nodes
     #16  normal_work_helper at ffffffffc03b706c
     #17  process_one_work at ffffffffa4aba4e4
     #18  worker_thread at ffffffffa4aba6fd
     #19  kthread at ffffffffa4ac0a3d
     #20  ret_from_fork at ffffffffa54001ff
    
    To fully address those cases the complete fix is to never issue any
    flushing while holding the transaction or the delayed node lock. This
    patch achieves it by calling qgroup_reserve_meta directly which will
    either succeed without flushing or will fail and return -EDQUOT. In the
    latter case that return value is going to be propagated to
    btrfs_dirty_inode which will fallback to start a new transaction. That's
    fine as the majority of time we expect the inode will have
    BTRFS_DELAYED_NODE_INODE_DIRTY flag set which will result in directly
    copying the in-memory state.
    
    Fixes: c53e9653605d ("btrfs: qgroup: try to flush qgroup space when we get -EDQUOT")
    CC: stable@vger.kernel.org # 5.10+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Nikolay Borisov <nborisov@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    [sudip: adjust context]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf9317ceb5a119458bffbaf47c4d0e1a49d73123
Author: Nikolay Borisov <nborisov@suse.com>
Date:   Mon Feb 22 18:40:43 2021 +0200

    btrfs: export and rename qgroup_reserve_meta
    
    commit 80e9baed722c853056e0c5374f51524593cb1031 upstream
    
    Signed-off-by: Nikolay Borisov <nborisov@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7215d7742daf4c036567f03c647738e269d6a943
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Mon Feb 8 17:57:20 2021 -0700

    arm64: Make CPU_BIG_ENDIAN depend on ld.bfd or ld.lld 13.0.0+
    
    commit e9c6deee00e9197e75cd6aa0d265d3d45bd7cc28 upstream
    
    Similar to commit 28187dc8ebd9 ("ARM: 9025/1: Kconfig: CPU_BIG_ENDIAN
    depends on !LD_IS_LLD"), ld.lld prior to 13.0.0 does not properly
    support aarch64 big endian, leading to the following build error when
    CONFIG_CPU_BIG_ENDIAN is selected:
    
    ld.lld: error: unknown emulation: aarch64linuxb
    
    This has been resolved in LLVM 13. To avoid errors like this, only allow
    CONFIG_CPU_BIG_ENDIAN to be selected if using ld.bfd or ld.lld 13.0.0
    and newer.
    
    While we are here, the indentation of this symbol used spaces since its
    introduction in commit a872013d6d03 ("arm64: kconfig: allow
    CPU_BIG_ENDIAN to be selected"). Change it to tabs to be consistent with
    kernel coding style.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/380
    Link: https://github.com/ClangBuiltLinux/linux/issues/1288
    Link: https://github.com/llvm/llvm-project/commit/7605a9a009b5fa3bdac07e3131c8d82f6d08feb7
    Link: https://github.com/llvm/llvm-project/commit/eea34aae2e74e9b6fbdd5b95f479bc7f397bf387
    Reported-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Link: https://lore.kernel.org/r/20210209005719.803608-1-nathan@kernel.org
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a6425142f522d7e8ac5244ff94cf6cd844ddc818
Author: Helge Deller <deller@gmx.de>
Date:   Tue Mar 2 21:07:07 2021 +0100

    parisc: Enable -mlong-calls gcc option with CONFIG_COMPILE_TEST
    
    commit 778e45d7720d663811352943dd515b41f6849637 upstream
    
    The kernel test robot reported multiple linkage problems like this:
    
        hppa64-linux-ld: init/main.o(.init.text+0x56c): cannot reach printk
        init/main.o: in function `unknown_bootoption':
        (.init.text+0x56c): relocation truncated to fit: R_PARISC_PCREL22F against
            symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o
    
    There are two ways to solve it:
    a) Enable the -mlong-call compiler option (CONFIG_MLONGCALLS),
    b) Add long branch stub support in 64-bit linker.
    
    While b) is the long-term solution, this patch works around the issue by
    automatically enabling the CONFIG_MLONGCALLS option when
    CONFIG_COMPILE_TEST is set, which indicates that a non-production kernel
    (e.g. 0-day kernel) is built.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Reported-by: kernel test robot <lkp@intel.com>
    Fixes: 00e35f2b0e8a ("parisc: Enable -mlong-calls gcc option by default when !CONFIG_MODULES")
    Cc: stable@vger.kernel.org # v5.6+
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea222427ae9ced2ad6c39d0bbbd8f8c66b2a5045
Author: Zoltán Böszörményi <zboszor@gmail.com>
Date:   Sun Feb 21 06:12:16 2021 +0100

    nvme-pci: mark Kingston SKC2000 as not supporting the deepest power state
    
    commit dc22c1c058b5c4fe967a20589e36f029ee42a706 upstream
    
    My 2TB SKC2000 showed the exact same symptoms that were provided
    in 538e4a8c57 ("nvme-pci: avoid the deepest sleep state on
    Kingston A2000 SSDs"), i.e. a complete NVME lockup that needed
    cold boot to get it back.
    
    According to some sources, the A2000 is simply a rebadged
    SKC2000 with a slightly optimized firmware.
    
    Adding the SKC2000 PCI ID to the quirk list with the same workaround
    as the A2000 made my laptop survive a 5 hours long Yocto bootstrap
    buildfest which reliably triggered the SSD lockup previously.
    
    Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    [sudip: adjust context]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6d7fdad08fbd1d85a79012040f15852763c803c1
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Tue Mar 9 16:16:18 2021 -0600

    ASoC: SOF: Intel: broadwell: fix mutual exclusion with catpt driver
    
    In v5.10, the "haswell" driver was replaced by the "catpt" driver, but
    the mutual exclusion with the SOF driver was not updated. This leads
    to errors with card names and UCM profiles not being loaded by
    PulseAudio.
    
    This fix should only be applied on v5.10-stable, the mutual exclusion
    was removed in 5.11.
    
    Reported-by: David Ward <david.ward@ll.mit.edu>
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=211985
    Fixes: 6cbfa11d2694 ("ASoC: Intel: Select catpt and deprecate haswell")
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Acked-by: Mark Brown <broonie@kernel.org>
    Cc: <stable@vger.kernel.org>
    Cc: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62ba6d817c9175b92dcb1cf5d224a5d635a243f5
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Feb 18 15:17:07 2021 -0800

    ACPICA: Fix race in generic_serial_bus (I2C) and GPIO op_region parameter handling
    
    commit c27f3d011b08540e68233cf56274fdc34bebb9b5 upstream.
    
    ACPICA commit c9e0116952363b0fa815143dca7e9a2eb4fefa61
    
    The handling of the generic_serial_bus (I2C) and GPIO op_regions in
    acpi_ev_address_space_dispatch() passes a number of extra parameters
    to the address-space handler through the address-space Context pointer
    (instead of using more function parameters).
    
    The Context is shared between threads, so if multiple threads try to
    call the handler for the same address-space at the same time, then
    a second thread could change the parameters of a first thread while
    the handler is running for the first thread.
    
    An example of this race hitting is the Lenovo Yoga Tablet2 1015L,
    where there are both attrib_bytes accesses and attrib_byte accesses
    to the same address-space. The attrib_bytes access stores the number
    of bytes to transfer in Context->access_length. Where as for the
    attrib_byte access the number of bytes to transfer is always 1 and
    field_obj->Field.access_length is unused (so 0). Both types of
    accesses racing from different threads leads to the following problem:
    
     1. Thread a. starts an attrib_bytes access, stores a non 0 value
        from field_obj->Field.access_length in Context->access_length
    
     2. Thread b. starts an attrib_byte access, stores 0 in
        Context->access_length
    
     3. Thread a. calls i2c_acpi_space_handler() (under Linux). Which
        sees that the access-type is ACPI_GSB_ACCESS_ATTRIB_MULTIBYTE
        and calls acpi_gsb_i2c_read_bytes(..., Context->access_length)
    
     4. At this point Context->access_length is 0 (set by thread b.)
    
    rather then the field_obj->Field.access_length value from thread a.
    This 0 length reads leads to the following errors being logged:
    
     i2c i2c-0: adapter quirk: no zero length (addr 0x0078, size 0, read)
     i2c i2c-0: i2c read 0 bytes from client@0x78 starting at reg 0x0 failed, error: -95
    
    Note this is just an example of the problems which this race can cause.
    
    There are likely many more (sporadic) problems caused by this race.
    
    This commit adds a new context_mutex to struct acpi_object_addr_handler
    and makes acpi_ev_address_space_dispatch() take that mutex when
    using the shared Context to pass extra parameters to an address-space
    handler, fixing this race.
    
    Note the new mutex must be taken *after* exiting the interpreter,
    therefor the existing acpi_ex_exit_interpreter() call is moved to above
    the code which stores the extra parameters in the Context.
    
    Link: https://github.com/acpica/acpica/commit/c9e01169
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Bob Moore <robert.moore@intel.com>
    Signed-off-by: Erik Kaneda <erik.kaneda@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>