commit fc3b667678f2513869b20f161d648580c9b2ae62
Author: Sasha Levin <sashal@kernel.org>
Date:   Wed Jul 7 08:26:52 2021 -0400

    Linux 5.12.15
    
    Tested-by: Fox Chen <foxhlchen@gmail.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Justin M. Forbes <jforbes@fedoraproject.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0980e3bec812a8f48f62a31a3e66d283ae2692c6
Author: Sean Christopherson <seanjc@google.com>
Date:   Tue Jun 22 10:56:50 2021 -0700

    Revert "KVM: x86/mmu: Drop kvm_mmu_extended_role.cr4_la57 hack"
    
    commit f71a53d1180d5ecc346f0c6a23191d837fe2871b upstream.
    
    Restore CR4.LA57 to the mmu_role to fix an amusing edge case with nested
    virtualization.  When KVM (L0) is using TDP, CR4.LA57 is not reflected in
    mmu_role.base.level because that tracks the shadow root level, i.e. TDP
    level.  Normally, this is not an issue because LA57 can't be toggled
    while long mode is active, i.e. the guest has to first disable paging,
    then toggle LA57, then re-enable paging, thus ensuring an MMU
    reinitialization.
    
    But if L1 is crafty, it can load a new CR4 on VM-Exit and toggle LA57
    without having to bounce through an unpaged section.  L1 can also load a
    new CR3 on exit, i.e. it doesn't even need to play crazy paging games, a
    single entry PML5 is sufficient.  Such shenanigans are only problematic
    if L0 and L1 use TDP, otherwise L1 and L2 share an MMU that gets
    reinitialized on nested VM-Enter/VM-Exit due to mmu_role.base.guest_mode.
    
    Note, in the L2 case with nested TDP, even though L1 can switch between
    L2s with different LA57 settings, thus bypassing the paging requirement,
    in that case KVM's nested_mmu will track LA57 in base.level.
    
    This reverts commit 8053f924cad30bf9f9a24e02b6c8ddfabf5202ea.
    
    Fixes: 8053f924cad3 ("KVM: x86/mmu: Drop kvm_mmu_extended_role.cr4_la57 hack")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20210622175739.3610207-6-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 533c5bd68164dd78f7bf0749b7971782c0a6558a
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Jun 25 10:37:34 2021 +0200

    gpio: AMD8111 and TQMX86 require HAS_IOPORT_MAP
    
    [ Upstream commit c6414e1a2bd26b0071e2b9d6034621f705dfd4c0 ]
    
    Both of these drivers use ioport_map(), so they need to
    depend on HAS_IOPORT_MAP. Otherwise, they cannot be built
    even with COMPILE_TEST on architectures without an ioport
    implementation, such as ARCH=um.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f809438939f585c83c3acfa6f30669547e2b30e2
Author: Christian König <christian.koenig@amd.com>
Date:   Fri Jun 11 14:34:50 2021 +0200

    drm/nouveau: fix dma_address check for CPU/GPU sync
    
    [ Upstream commit d330099115597bbc238d6758a4930e72b49ea9ba ]
    
    AGP for example doesn't have a dma_address array.
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210614110517.1624-1-christian.koenig@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 72fc8c1e9294dd65beea62939f852e3802a4fd4f
Author: Loic Poulain <loic.poulain@linaro.org>
Date:   Thu Jun 17 15:54:13 2021 +0200

    gpio: mxc: Fix disabled interrupt wake-up support
    
    [ Upstream commit 3093e6cca3ba7d47848068cb256c489675125181 ]
    
    A disabled/masked interrupt marked as wakeup source must be re-enable
    and unmasked in order to be able to wake-up the host. That can be done
    by flaging the irqchip with IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND.
    
    Note: It 'sometimes' works without that change, but only thanks to the
    lazy generic interrupt disabling (keeping interrupt unmasked).
    
    Reported-by: Michal Koziel <michal.koziel@emlogic.no>
    Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2fc4a7f07041ad7d7c7f3a471b36c89e4df4a50f
Author: Tony Krowiak <akrowiak@linux.ibm.com>
Date:   Wed Jun 9 18:46:32 2021 -0400

    s390/vfio-ap: clean up mdev resources when remove callback invoked
    
    [ Upstream commit 8c0795d2a0f50e2b131f5b2a8c2795939a94058e ]
    
    The mdev remove callback for the vfio_ap device driver bails out with
    -EBUSY if the mdev is in use by a KVM guest (i.e., the KVM pointer in the
    struct ap_matrix_mdev is not NULL). The intended purpose was
    to prevent the mdev from being removed while in use. There are two
    problems with this scenario:
    
    1. Returning a non-zero return code from the remove callback does not
       prevent the removal of the mdev.
    
    2. The KVM pointer in the struct ap_matrix_mdev will always be NULL because
       the remove callback will not get invoked until the mdev fd is closed.
       When the mdev fd is closed, the mdev release callback is invoked and
       clears the KVM pointer from the struct ap_matrix_mdev.
    
    Let's go ahead and remove the check for KVM in the remove callback and
    allow the cleanup of mdev resources to proceed.
    
    Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
    Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
    Link: https://lore.kernel.org/r/20210609224634.575156-2-akrowiak@linux.ibm.com
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b8455cb4b4c9d2fd0e581c040d6132c7623b5154
Author: ManYi Li <limanyi@uniontech.com>
Date:   Fri Jun 11 17:44:02 2021 +0800

    scsi: sr: Return appropriate error code when disk is ejected
    
    [ Upstream commit 7dd753ca59d6c8cc09aa1ed24f7657524803c7f3 ]
    
    Handle a reported media event code of 3. This indicates that the media has
    been removed from the drive and user intervention is required to proceed.
    Return DISK_EVENT_EJECT_REQUEST in that case.
    
    Link: https://lore.kernel.org/r/20210611094402.23884-1-limanyi@uniontech.com
    Signed-off-by: ManYi Li <limanyi@uniontech.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>