Linux 5.19.10

 
ACPI: resource: skip IRQ override on AMD Zen platforms [+ + +]
Author: Chuanhong Guo <gch981213@gmail.com>
Date:   Tue Jul 12 10:00:58 2022 +0800

    ACPI: resource: skip IRQ override on AMD Zen platforms
    
    commit 9946e39fe8d0a5da9eb947d8e40a7ef204ba016e upstream.
    
    IRQ override isn't needed on modern AMD Zen systems.
    There's an active low keyboard IRQ on AMD Ryzen 6000 and it will stay
    this way on newer platforms. This IRQ override breaks keyboards for
    almost all Ryzen 6000 laptops currently on the market.
    
    Skip this IRQ override for all AMD Zen platforms because this IRQ
    override is supposed to be a workaround for buggy ACPI DSDT and we can't
    have a long list of all future AMD CPUs/Laptops in the kernel code.
    If a device with buggy ACPI DSDT shows up, a separated list containing
    just them should be created.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216118
    Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
    Acked-by: Mario Limonciello <mario.limonciello@amd.com>
    Tested-by: XiaoYan Li <lxy.lixiaoyan@gmail.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Bluetooth: MGMT: Fix Get Device Flags [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Mon Aug 15 16:14:32 2022 -0700

    Bluetooth: MGMT: Fix Get Device Flags
    
    [ Upstream commit 23b72814da1a094b4c065e0bb598249f310c5577 ]
    
    Get Device Flags don't check if device does actually use an RPA in which
    case it shall only set HCI_CONN_FLAG_REMOTE_WAKEUP if LL Privacy is
    enabled.
    
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/amdgpu: skip ucode loading if ucode_size == 0 [+ + +]
Author: Chengming Gui <Jack.Gui@amd.com>
Date:   Tue Aug 30 16:33:01 2022 +0800

    drm/amd/amdgpu: skip ucode loading if ucode_size == 0
    
    [ Upstream commit 39c84b8e929dbd4f63be7e04bf1a2bcd92b44177 ]
    
    Restrict the ucode loading check to avoid frontdoor loading error.
    
    Signed-off-by: Chengming Gui <Jack.Gui@amd.com>
    Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/pm: use vbios carried pptable for all SMU13.0.7 SKUs [+ + +]
Author: Evan Quan <evan.quan@amd.com>
Date:   Tue Aug 23 16:07:18 2022 +0800

    drm/amd/pm: use vbios carried pptable for all SMU13.0.7 SKUs
    
    [ Upstream commit b023053592646b1da9477b0b598f2cdd5d3f89d8 ]
    
    For those SMU13.0.7 unsecure SKUs, the vbios carried pptable is ready to go.
    Use that one instead of hardcoded softpptable.
    
    Signed-off-by: Evan Quan <evan.quan@amd.com>
    Reviewed-by: Kenneth Feng <kenneth.feng@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu: disable FRU access on special SIENNA CICHLID card [+ + +]
Author: Guchun Chen <guchun.chen@amd.com>
Date:   Wed Aug 24 23:00:02 2022 +0800

    drm/amdgpu: disable FRU access on special SIENNA CICHLID card
    
    [ Upstream commit c8fea9273fd1be308668496badfcbd55183e0dd3 ]
    
    Below driver load error will be printed, not friendly to end user.
    
    amdgpu: ATOM BIOS: 113-D603GLXE-077
    [drm] FRU: Failed to get size field
    [drm:amdgpu_fru_get_product_info [amdgpu]] *ERROR* Failed to read FRU Manufacturer, ret:-5
    
    Signed-off-by: Guchun Chen <guchun.chen@amd.com>
    Reviewed-by: Kent Russell <kent.russell@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/rd: Fix FIFO-full deadlock [+ + +]
Author: Rob Clark <robdclark@chromium.org>
Date:   Sun Aug 7 09:09:01 2022 -0700

    drm/msm/rd: Fix FIFO-full deadlock
    
    [ Upstream commit 174974d8463b77c2b4065e98513adb204e64de7d ]
    
    If the previous thing cat'ing $debugfs/rd left the FIFO full, then
    subsequent open could deadlock in rd_write() (because open is blocked,
    not giving a chance for read() to consume any data in the FIFO).  Also
    it is generally a good idea to clear out old data from the FIFO.
    
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Patchwork: https://patchwork.freedesktop.org/patch/496706/
    Link: https://lore.kernel.org/r/20220807160901.2353471-2-robdclark@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dt-bindings: iio: gyroscope: bosch,bmg160: correct number of pins [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Fri Aug 5 09:55:03 2022 +0200

    dt-bindings: iio: gyroscope: bosch,bmg160: correct number of pins
    
    [ Upstream commit 767470209cedbe2cc72ba38d77c9f096d2c7694c ]
    
    BMG160 has two interrupt pins to which interrupts can be freely mapped.
    Correct the schema to express such case and fix warnings like:
    
      qcom/msm8916-alcatel-idol347.dtb: gyroscope@68: interrupts: [[97, 1], [98, 1]] is too long
    
    However the basic issue still persists - the interrupts should come in a
    defined order.
    
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20220805075503.16983-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
gpio: 104-dio-48e: Make irq_chip immutable [+ + +]
Author: William Breathitt Gray <william.gray@linaro.org>
Date:   Fri Sep 2 13:45:23 2022 -0400

    gpio: 104-dio-48e: Make irq_chip immutable
    
    [ Upstream commit 35f0aa7727b092520bf91374768a4fdafd4a4fe3 ]
    
    Kernel warns about mutable irq_chips:
    
        "not an immutable chip, please consider fixing!"
    
    Make the struct irq_chip const, flag it as IRQCHIP_IMMUTABLE, add the
    new helper functions, and call the appropriate gpiolib functions.
    
    Signed-off-by: William Breathitt Gray <william.gray@linaro.org>
    Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gpio: 104-idio-16: Make irq_chip immutable [+ + +]
Author: William Breathitt Gray <william.gray@linaro.org>
Date:   Fri Sep 2 13:45:25 2022 -0400

    gpio: 104-idio-16: Make irq_chip immutable
    
    [ Upstream commit 410a5041aa60d91ff66a861560e7c879d664270f ]
    
    Kernel warns about mutable irq_chips:
    
        "not an immutable chip, please consider fixing!"
    
    Make the struct irq_chip const, flag it as IRQCHIP_IMMUTABLE, add the
    new helper functions, and call the appropriate gpiolib functions.
    
    Signed-off-by: William Breathitt Gray <william.gray@linaro.org>
    Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gpio: mockup: remove gpio debugfs when remove device [+ + +]
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date:   Mon Aug 22 04:10:25 2022 +0000

    gpio: mockup: remove gpio debugfs when remove device
    
    [ Upstream commit 303e6da99429510b1e4edf833afe90ac8542e747 ]
    
    GPIO mockup debugfs is created in gpio_mockup_probe() but
    forgot to remove when remove device. This patch add a devm
    managed callback for removing them.
    
    Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
    Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hid: intel-ish-hid: ishtp: Fix ishtp client sending disordered message [+ + +]
Author: Even Xu <even.xu@intel.com>
Date:   Thu Aug 4 08:59:19 2022 +0800

    hid: intel-ish-hid: ishtp: Fix ishtp client sending disordered message
    
    [ Upstream commit e1fa076706209cc447d7a2abd0843a18277e5ef7 ]
    
    There is a timing issue captured during ishtp client sending stress tests.
    It was observed during stress tests that ISH firmware is getting out of
    ordered messages. This is a rare scenario as the current set of ISH client
    drivers don't send much data to firmware. But this may not be the case
    going forward.
    
    When message size is bigger than IPC MTU, ishtp splits the message into
    fragments and uses serialized async method to send message fragments.
    The call stack:
    ishtp_cl_send_msg_ipc->ipc_tx_callback(first fregment)->
    ishtp_send_msg(with callback)->write_ipc_to_queue->
    write_ipc_from_queue->callback->ipc_tx_callback(next fregment)......
    
    When an ipc write complete interrupt is received, driver also calls
    write_ipc_from_queue->ipc_tx_callback in ISR to start sending of next fragment.
    
    Through ipc_tx_callback uses spin_lock to protect message splitting, as the
    serialized sending method will call back to ipc_tx_callback again, so it doesn't
    put sending under spin_lock, it causes driver cannot guarantee all fragments
    be sent in order.
    
    Considering this scenario:
    ipc_tx_callback just finished a fragment splitting, and not call ishtp_send_msg
    yet, there is a write complete interrupt happens, then ISR->write_ipc_from_queue
    ->ipc_tx_callback->ishtp_send_msg->write_ipc_to_queue......
    
    Because ISR has higher exec priority than normal thread, this causes the new
    fragment be sent out before previous fragment. This disordered message causes
    invalid message to firmware.
    
    The solution is, to send fragments synchronously:
    Use ishtp_write_message writing fragments into tx queue directly one by one,
    instead of ishtp_send_msg only writing one fragment with completion callback.
    As no completion callback be used, so change ipc_tx_callback to ipc_tx_send.
    
    Signed-off-by: Even Xu <even.xu@intel.com>
    Acked-by: Srinivas Pandruvada <srinivas.pandruvada@intel.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
HID: ishtp-hid-clientHID: ishtp-hid-client: Fix comment typo [+ + +]
Author: Jason Wang <wangborong@cdjrlc.com>
Date:   Thu Aug 4 08:58:14 2022 +0800

    HID: ishtp-hid-clientHID: ishtp-hid-client: Fix comment typo
    
    [ Upstream commit 94553f8a218540d676efbf3f7827ed493d1057cf ]
    
    The double `like' is duplicated in the comment, remove one.
    
    Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ieee802154: cc2520: add rc code in cc2520_tx() [+ + +]
Author: Li Qiong <liqiong@nfschina.com>
Date:   Mon Aug 29 15:12:59 2022 +0800

    ieee802154: cc2520: add rc code in cc2520_tx()
    
    [ Upstream commit ffd7bdddaab193c38416fd5dd416d065517d266e ]
    
    The rc code is 0 at the error path "status & CC2520_STATUS_TX_UNDERFLOW".
    Assign rc code with '-EINVAL' at this error path to fix it.
    
    Signed-off-by: Li Qiong <liqiong@nfschina.com>
    Link: https://lore.kernel.org/r/20220829071259.18330-1-liqiong@nfschina.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Input: goodix - add compatible string for GT1158 [+ + +]
Author: Jarrah Gosbell <kernel@undef.tools>
Date:   Tue Aug 23 10:00:37 2022 -0700

    Input: goodix - add compatible string for GT1158
    
    commit 80b9ebd3e478cd41526cbf84f80c3e0eb885d1d3 upstream.
    
    Add compatible string for GT1158 missing from the previous patch.
    
    Fixes: 425fe4709c76 ("Input: goodix - add support for GT1158")
    Signed-off-by: Jarrah Gosbell <kernel@undef.tools>
    Link: https://lore.kernel.org/r/20220813043821.9981-1-kernel@undef.tools
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Input: goodix - add support for GT1158 [+ + +]
Author: Ondrej Jirman <megi@xff.cz>
Date:   Thu Aug 11 16:16:54 2022 -0700

    Input: goodix - add support for GT1158
    
    [ Upstream commit 425fe4709c76e35f93f4c0e50240f0b61b2a2e54 ]
    
    This controller is used by PinePhone and PinePhone Pro. Support for
    the PinePhone Pro will be added in a later patch set.
    
    Signed-off-by: Ondrej Jirman <megi@xff.cz>
    Signed-off-by: Jarrah Gosbell <kernel@undef.tools>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20220809091200.290492-1-kernel@undef.tools
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: iforce - add support for Boeder Force Feedback Wheel [+ + +]
Author: Greg Tulli <greg.iforce@gmail.com>
Date:   Mon Aug 29 11:21:03 2022 -0700

    Input: iforce - add support for Boeder Force Feedback Wheel
    
    [ Upstream commit 9c9c71168f7979f3798b61c65b4530fbfbcf19d1 ]
    
    Add a new iforce_device entry to support the Boeder Force Feedback Wheel
    device.
    
    Signed-off-by: Greg Tulli <greg.iforce@gmail.com>
    Link: https://lore.kernel.org/r/3256420-c8ac-31b-8499-3c488a9880fd@gmail.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommu/vt-d: Fix kdump kernels boot failure with scalable mode [+ + +]
Author: Lu Baolu <baolu.lu@linux.intel.com>
Date:   Tue Aug 23 14:15:54 2022 +0800

    iommu/vt-d: Fix kdump kernels boot failure with scalable mode
    
    [ Upstream commit 0c5f6c0d8201a809a6585b07b6263e9db2c874a3 ]
    
    The translation table copying code for kdump kernels is currently based
    on the extended root/context entry formats of ECS mode defined in older
    VT-d v2.5, and doesn't handle the scalable mode formats. This causes
    the kexec capture kernel boot failure with DMAR faults if the IOMMU was
    enabled in scalable mode by the previous kernel.
    
    The ECS mode has already been deprecated by the VT-d spec since v3.0 and
    Intel IOMMU driver doesn't support this mode as there's no real hardware
    implementation. Hence this converts ECS checking in copying table code
    into scalable mode.
    
    The existing copying code consumes a bit in the context entry as a mark
    of copied entry. It needs to work for the old format as well as for the
    extended context entries. As it's hard to find such a common bit for both
    legacy and scalable mode context entries. This replaces it with a per-
    IOMMU bitmap.
    
    Fixes: 7373a8cc38197 ("iommu/vt-d: Setup context and enable RID2PASID support")
    Cc: stable@vger.kernel.org
    Reported-by: Jerry Snitselaar <jsnitsel@redhat.com>
    Tested-by: Wen Jin <wen.jin@intel.com>
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Link: https://lore.kernel.org/r/20220817011035.3250131-1-baolu.lu@linux.intel.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
 
kvm: x86: mmu: Always flush TLBs when enabling dirty logging [+ + +]
Author: Junaid Shahid <junaids@google.com>
Date:   Wed Aug 10 15:49:39 2022 -0700

    kvm: x86: mmu: Always flush TLBs when enabling dirty logging
    
    [ Upstream commit b64d740ea7ddc929d97b28de4c0665f7d5db9e2a ]
    
    When A/D bits are not available, KVM uses a software access tracking
    mechanism, which involves making the SPTEs inaccessible. However,
    the clear_young() MMU notifier does not flush TLBs. So it is possible
    that there may still be stale, potentially writable, TLB entries.
    This is usually fine, but can be problematic when enabling dirty
    logging, because it currently only does a TLB flush if any SPTEs were
    modified. But if all SPTEs are in access-tracked state, then there
    won't be a TLB flush, which means that the guest could still possibly
    write to memory and not have it reflected in the dirty bitmap.
    
    So just unconditionally flush the TLBs when enabling dirty logging.
    As an alternative, KVM could explicitly check the MMU-Writable bit when
    write-protecting SPTEs to decide if a flush is needed (instead of
    checking the Writable bit), but given that a flush almost always happens
    anyway, so just making it unconditional seems simpler.
    
    Signed-off-by: Junaid Shahid <junaids@google.com>
    Message-Id: <20220810224939.2611160-1-junaids@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 5.19.10 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Sep 20 12:43:50 2022 +0200

    Linux 5.19.10
    
    Link: https://lore.kernel.org/r/20220916100448.431016349@linuxfoundation.org
    Tested-by: Ronald Warsow <rwarsow@gmx.de>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Fenil Jain <fkjainco@gmail.com>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Justin M. Forbes <jforbes@fedoraproject.org>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
LoongArch: Fix arch_remove_memory() undefined build error [+ + +]
Author: Yupeng Li <liyupeng@zbhlos.com>
Date:   Wed Aug 31 13:40:17 2022 +0800

    LoongArch: Fix arch_remove_memory() undefined build error
    
    [ Upstream commit 1a470ce4e9106cc4c3c0edfb2e213dcbb7224dc4 ]
    
    The kernel build error when unslected CONFIG_MEMORY_HOTREMOVE because
    arch_remove_memory() is needed by mm/memory_hotplug.c but undefined.
    
    Some build error messages like:
    
     LD      vmlinux.o
     MODPOST vmlinux.symvers
     MODINFO modules.builtin.modinfo
     GEN     modules.builtin
     LD      .tmp_vmlinux.kallsyms1
    loongarch64-linux-gnu-ld: mm/memory_hotplug.o: in function `.L242':
    memory_hotplug.c:(.ref.text+0x930): undefined reference to `arch_remove_memory'
    make: *** [Makefile:1169:vmlinux] 错误 1
    
    Removed CONFIG_MEMORY_HOTREMOVE requirement and rearrange the file refer
    to the definitions of other platform architectures.
    
    Signed-off-by: Yupeng Li <liyupeng@zbhlos.com>
    Signed-off-by: Caicai <caizp2008@163.com>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

LoongArch: Fix section mismatch due to acpi_os_ioremap() [+ + +]
Author: Huacai Chen <chenhuacai@kernel.org>
Date:   Fri Sep 2 22:33:42 2022 +0800

    LoongArch: Fix section mismatch due to acpi_os_ioremap()
    
    [ Upstream commit e0fba87c854347007fb9fc873e890b686cc61302 ]
    
    Now acpi_os_ioremap() is marked with __init because it calls memblock_
    is_memory() which is also marked with __init in the !ARCH_KEEP_MEMBLOCK
    case. However, acpi_os_ioremap() is called by ordinary functions such
    as acpi_os_{read, write}_memory() and causes section mismatch warnings:
    
    WARNING: modpost: vmlinux.o: section mismatch in reference: acpi_os_read_memory (section: .text) -> acpi_os_ioremap (section: .init.text)
    WARNING: modpost: vmlinux.o: section mismatch in reference: acpi_os_write_memory (section: .text) -> acpi_os_ioremap (section: .init.text)
    
    Fix these warnings by selecting ARCH_KEEP_MEMBLOCK unconditionally and
    removing the __init modifier of acpi_os_ioremap(). This can also give a
    chance to track "memory" and "reserved" memblocks after early boot.
    
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/mlx5: Introduce ifc bits for using software vhca id [+ + +]
Author: Yishai Hadas <yishaih@nvidia.com>
Date:   Thu Jun 2 12:41:00 2022 +0300

    net/mlx5: Introduce ifc bits for using software vhca id
    
    [ Upstream commit 0372c546eca575445331c0ad8902210b70be6d61 ]
    
    Introduce ifc related stuff to enable using software vhca id
    functionality.
    
    Signed-off-by: Yishai Hadas <yishaih@nvidia.com>
    Reviewed-by: Mark Bloch <mbloch@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Stable-dep-of: 9ca05b0f27de ("RDMA/mlx5: Rely on RoCE fw cap instead of devlink when setting profile")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: Use software VHCA id when it's supported [+ + +]
Author: Yishai Hadas <yishaih@nvidia.com>
Date:   Thu Jun 2 12:47:34 2022 +0300

    net/mlx5: Use software VHCA id when it's supported
    
    [ Upstream commit dc402ccc0d7b55922a79505df3000da7deb77a2b ]
    
    Use software VHCA id when it's supported by the firmware.
    
    A unique id is allocated upon mlx5_mdev_init() and freed upon
    mlx5_mdev_uninit(), as such it stays the same during the full life cycle
    of the device including upon health recovery if occurred.
    
    The conjunction of sw_vhca_id with sw_owner_id will be a global unique
    id per function which uses mlx5_core.
    
    The sw_vhca_id is set upon init_hca command and is used to specify the
    VHCA that the NIC vport is affiliated with.
    
    This functionality is needed upon migration of VM which is MPV based.
    (i.e. multi port device).
    
    Signed-off-by: Yishai Hadas <yishaih@nvidia.com>
    Reviewed-by: Mark Bloch <mbloch@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Stable-dep-of: 9ca05b0f27de ("RDMA/mlx5: Rely on RoCE fw cap instead of devlink when setting profile")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: dsa: hellcreek: Print warning only once [+ + +]
Author: Kurt Kanzenbach <kurt@linutronix.de>
Date:   Tue Aug 30 18:34:48 2022 +0200

    net: dsa: hellcreek: Print warning only once
    
    [ Upstream commit 52267ce25f60f37ae40ccbca0b21328ebae5ae75 ]
    
    In case the source port cannot be decoded, print the warning only once. This
    still brings attention to the user and does not spam the logs at the same time.
    
    Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Link: https://lore.kernel.org/r/20220830163448.8921-1-kurt@linutronix.de
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvme-pci: add NVME_QUIRK_BOGUS_NID for Lexar NM610 [+ + +]
Author: Shyamin Ayesh <me@shyamin.com>
Date:   Fri Aug 26 09:51:40 2022 -0700

    nvme-pci: add NVME_QUIRK_BOGUS_NID for Lexar NM610
    
    [ Upstream commit 200dccd07df21b504a2168960059f0a971bf415d ]
    
    Lexar NM610 reports bogus eui64 values that appear to be the same across
    all drives. Quirk them out so they are not marked as "non globally unique"
    duplicates.
    
    Signed-off-by: Shyamin Ayesh <me@shyamin.com>
    [patch formatting]
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvmet-tcp: fix unhandled tcp states in nvmet_tcp_state_change() [+ + +]
Author: Maurizio Lombardi <mlombard@redhat.com>
Date:   Mon Aug 29 14:40:30 2022 +0200

    nvmet-tcp: fix unhandled tcp states in nvmet_tcp_state_change()
    
    [ Upstream commit 478814a5584197fa1fb18377653626e3416e7cd6 ]
    
    TCP_FIN_WAIT2 and TCP_LAST_ACK were not handled, the connection is closing
    so we can ignore them and avoid printing the "unhandled state"
    warning message.
    
    [ 1298.852386] nvmet_tcp: queue 2 unhandled state 5
    [ 1298.879112] nvmet_tcp: queue 7 unhandled state 5
    [ 1298.884253] nvmet_tcp: queue 8 unhandled state 5
    [ 1298.889475] nvmet_tcp: queue 9 unhandled state 5
    
    v2: Do not call nvmet_tcp_schedule_release_queue(), just ignore
    the fin_wait2 and last_ack states.
    
    Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
peci: cpu: Fix use-after-free in adev_release() [+ + +]
Author: Iwona Winiarska <iwona.winiarska@intel.com>
Date:   Tue Jul 5 12:15:01 2022 +0200

    peci: cpu: Fix use-after-free in adev_release()
    
    [ Upstream commit 1c11289b34ab67ed080bbe0f1855c4938362d9cf ]
    
    When auxiliary_device_add() returns an error, auxiliary_device_uninit()
    is called, which causes refcount for device to be decremented and
    .release callback will be triggered.
    
    Because adev_release() re-calls auxiliary_device_uninit(), it will cause
    use-after-free:
    [ 1269.455172] WARNING: CPU: 0 PID: 14267 at lib/refcount.c:28 refcount_warn_saturate+0x110/0x15
    [ 1269.464007] refcount_t: underflow; use-after-free.
    
    Reported-by: Jianglei Nie <niejianglei2021@163.com>
    Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
    Link: https://lore.kernel.org/r/20220705101501.298395-1-iwona.winiarska@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf/arm_pmu_platform: fix tests for platform_get_irq() failure [+ + +]
Author: Yu Zhe <yuzhe@nfschina.com>
Date:   Thu Aug 25 09:18:44 2022 +0800

    perf/arm_pmu_platform: fix tests for platform_get_irq() failure
    
    [ Upstream commit 6bb0d64c100091e131cd16710b62fda3319cd0af ]
    
    The platform_get_irq() returns negative error codes.  It can't actually
    return zero.
    
    Signed-off-by: Yu Zhe <yuzhe@nfschina.com>
    Link: https://lore.kernel.org/r/20220825011844.8536-1-yuzhe@nfschina.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/surface: aggregator_registry: Add support for Surface Laptop Go 2 [+ + +]
Author: Maximilian Luz <luzmaximilian@gmail.com>
Date:   Wed Aug 10 16:01:33 2022 +0200

    platform/surface: aggregator_registry: Add support for Surface Laptop Go 2
    
    [ Upstream commit 84b8e403435c8fb94b872309673764a447961e00 ]
    
    The Surface Laptop Go 2 seems to have the same SAM client devices as the
    Surface Laptop Go 1, so re-use its node group.
    
    Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
    Link: https://lore.kernel.org/r/20220810140133.99087-1-luzmaximilian@gmail.com
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/x86: acer-wmi: Acer Aspire One AOD270/Packard Bell Dot keymap fixes [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Aug 29 18:35:44 2022 +0200

    platform/x86: acer-wmi: Acer Aspire One AOD270/Packard Bell Dot keymap fixes
    
    [ Upstream commit c3b82d26bc85f5fc2fef5ec8cce17c89633a55a8 ]
    
    2 keymap fixes for the Acer Aspire One AOD270 and the same hardware
    rebranded as Packard Bell Dot SC:
    
    1. The F2 key is marked with a big '?' symbol on the Packard Bell Dot SC,
    this sends WMID_HOTKEY_EVENTs with a scancode of 0x27 add a mapping
    for this.
    
    2. Scancode 0x61 is KEY_SWITCHVIDEOMODE. Usually this is a duplicate
    input event with the "Video Bus" input device events. But on these devices
    the "Video Bus" does not send events for this key. Map 0x61 to KEY_UNKNOWN
    instead of using KE_IGNORE so that udev/hwdb can override it on these devs.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20220829163544.5288-1-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: asus-wmi: Increase FAN_CURVE_BUF_LEN to 32 [+ + +]
Author: Luke D. Jones <luke@ljones.dev>
Date:   Sun Aug 28 19:46:38 2022 +1200

    platform/x86: asus-wmi: Increase FAN_CURVE_BUF_LEN to 32
    
    [ Upstream commit 5542dfc582f4a925f67bbfaf8f62ca83506032ae ]
    
    Fix for TUF laptops returning with an -ENOSPC on calling
    asus_wmi_evaluate_method_buf() when fetching default curves. The TUF method
    requires at least 32 bytes space.
    
    This also moves and changes the pr_debug() in fan_curve_check_present() to
    pr_warn() in fan_curve_get_factory_default() so that there is at least some
    indication in logs of why it fails.
    
    Signed-off-by: Luke D. Jones <luke@ljones.dev>
    Link: https://lore.kernel.org/r/20220828074638.5473-1-luke@ljones.dev
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
r8152: add PID for the Lenovo OneLink+ Dock [+ + +]
Author: Jean-Francois Le Fillatre <jflf_kernel@gmx.com>
Date:   Wed Aug 24 21:14:36 2022 +0200

    r8152: add PID for the Lenovo OneLink+ Dock
    
    [ Upstream commit 1bd3a383075c64d638e65d263c9267b08ee7733c ]
    
    The Lenovo OneLink+ Dock contains an RTL8153 controller that behaves as
    a broken CDC device by default. Add the custom Lenovo PID to the r8152
    driver to support it properly.
    
    Also, systems compatible with this dock provide a BIOS option to enable
    MAC address passthrough (as per Lenovo document "ThinkPad Docking
    Solutions 2017"). Add the custom PID to the MAC passthrough list too.
    
    Tested on a ThinkPad 13 1st gen with the expected results:
    
    passthrough disabled: Invalid header when reading pass-thru MAC addr
    passthrough enabled:  Using pass-thru MAC addr XX:XX:XX:XX:XX:XX
    
    Signed-off-by: Jean-Francois Le Fillatre <jflf_kernel@gmx.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/irdma: Use s/g array in post send only when its valid [+ + +]
Author: Sindhu-Devale <sindhu.devale@intel.com>
Date:   Tue Sep 6 17:32:43 2022 -0500

    RDMA/irdma: Use s/g array in post send only when its valid
    
    commit 2c8844431d065ae15a6b442f5769b60aeaaa07af upstream.
    
    Send with invalidate verb call can pass in an
    uninitialized s/g array with 0 sge's which is
    filled into irdma WQE and causes a HW asynchronous
    event.
    
    Fix this by using the s/g array in irdma post send
    only when its valid.
    
    Fixes: 551c46e ("RDMA/irdma: Add user/kernel shared libraries")
    Signed-off-by: Sindhu-Devale <sindhu.devale@intel.com>
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Link: https://lore.kernel.org/r/20220906223244.1119-5-shiraz.saleem@intel.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
RDMA/mlx5: Add a umr recovery flow [+ + +]
Author: Aharon Landau <aharonl@nvidia.com>
Date:   Sun May 15 07:19:53 2022 +0300

    RDMA/mlx5: Add a umr recovery flow
    
    [ Upstream commit 158e71bb69e368b8b33e8b7c4ac8c111da0c1ae2 ]
    
    When a UMR fails, the UMR QP state changes to an error state. Therefore,
    all the further UMR operations will fail too.
    
    Add a recovery flow to the UMR QP, and repost the flushed WQEs.
    
    Link: https://lore.kernel.org/r/6cc24816cca049bd8541317f5e41d3ac659445d3.1652588303.git.leonro@nvidia.com
    Signed-off-by: Aharon Landau <aharonl@nvidia.com>
    Reviewed-by: Michael Guralnik <michaelgur@nvidia.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Stable-dep-of: 9b7d4be967f1 ("RDMA/mlx5: Fix UMR cleanup on error flow of driver init")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/mlx5: Fix UMR cleanup on error flow of driver init [+ + +]
Author: Maor Gottlieb <maorg@nvidia.com>
Date:   Mon Aug 29 12:02:29 2022 +0300

    RDMA/mlx5: Fix UMR cleanup on error flow of driver init
    
    [ Upstream commit 9b7d4be967f16f79a2283b2338709fcc750313ee ]
    
    The cited commit removed from the cleanup flow of umr the checks
    if the resources were created. This could lead to null-ptr-deref
    in case that we had failure in mlx5_ib_stage_ib_reg_init stage.
    
    Fix it by adding new state to the umr that can say if the resources
    were created or not and check it in the umr cleanup flow before
    destroying the resources.
    
    Fixes: 04876c12c19e ("RDMA/mlx5: Move init and cleanup of UMR to umr.c")
    Reviewed-by: Michael Guralnik <michaelgur@nvidia.com>
    Signed-off-by: Maor Gottlieb <maorg@nvidia.com>
    Link: https://lore.kernel.org/r/4cfa61386cf202e9ce330e8d228ce3b25a36326e.1661763459.git.leonro@nvidia.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/mlx5: Rely on RoCE fw cap instead of devlink when setting profile [+ + +]
Author: Maher Sanalla <msanalla@nvidia.com>
Date:   Mon Aug 29 12:02:27 2022 +0300

    RDMA/mlx5: Rely on RoCE fw cap instead of devlink when setting profile
    
    [ Upstream commit 9ca05b0f27de928be121cccf07735819dc9e1ed3 ]
    
    When the RDMA auxiliary driver probes, it sets its profile based on
    devlink driverinit value. The latter might not be in sync with FW yet
    (In case devlink reload is not performed), thus causing a mismatch
    between RDMA driver and FW. This results in the following FW syndrome
    when the RDMA driver tries to adjust RoCE state, which fails the probe:
    
    "0xC1F678 | modify_nic_vport_context: roce_en set on a vport that
    doesn't support roce"
    
    To prevent this, select the PF profile based on FW RoCE capability
    instead of relying on devlink driverinit value.
    To provide backward compatibility of the RoCE disable feature, on older
    FW's where roce_rw is not set (FW RoCE capability is read-only), keep
    the current behavior e.g., rely on devlink driverinit value.
    
    Fixes: fbfa97b4d79f ("net/mlx5: Disable roce at HCA level")
    Reviewed-by: Shay Drory <shayd@nvidia.com>
    Reviewed-by: Michael Guralnik <michaelgur@nvidia.com>
    Reviewed-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Maher Sanalla <msanalla@nvidia.com>
    Link: https://lore.kernel.org/r/cb34ce9a1df4a24c135cb804db87f7d2418bd6cc.1661763459.git.leonro@nvidia.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tg3: Disable tg3 device on system reboot to avoid triggering AER [+ + +]
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Fri Aug 26 08:25:30 2022 +0800

    tg3: Disable tg3 device on system reboot to avoid triggering AER
    
    [ Upstream commit 2ca1c94ce0b65a2ce7512b718f3d8a0fe6224bca ]
    
    Commit d60cd06331a3 ("PM: ACPI: reboot: Use S5 for reboot") caused a
    reboot hang on one Dell servers so the commit was reverted.
    
    Someone managed to collect the AER log and it's caused by MSI:
    [ 148.762067] ACPI: Preparing to enter system sleep state S5
    [ 148.794638] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 5
    [ 148.803731] {1}[Hardware Error]: event severity: recoverable
    [ 148.810191] {1}[Hardware Error]: Error 0, type: fatal
    [ 148.816088] {1}[Hardware Error]: section_type: PCIe error
    [ 148.822391] {1}[Hardware Error]: port_type: 0, PCIe end point
    [ 148.829026] {1}[Hardware Error]: version: 3.0
    [ 148.834266] {1}[Hardware Error]: command: 0x0006, status: 0x0010
    [ 148.841140] {1}[Hardware Error]: device_id: 0000:04:00.0
    [ 148.847309] {1}[Hardware Error]: slot: 0
    [ 148.852077] {1}[Hardware Error]: secondary_bus: 0x00
    [ 148.857876] {1}[Hardware Error]: vendor_id: 0x14e4, device_id: 0x165f
    [ 148.865145] {1}[Hardware Error]: class_code: 020000
    [ 148.870845] {1}[Hardware Error]: aer_uncor_status: 0x00100000, aer_uncor_mask: 0x00010000
    [ 148.879842] {1}[Hardware Error]: aer_uncor_severity: 0x000ef030
    [ 148.886575] {1}[Hardware Error]: TLP Header: 40000001 0000030f 90028090 00000000
    [ 148.894823] tg3 0000:04:00.0: AER: aer_status: 0x00100000, aer_mask: 0x00010000
    [ 148.902795] tg3 0000:04:00.0: AER: [20] UnsupReq (First)
    [ 148.910234] tg3 0000:04:00.0: AER: aer_layer=Transaction Layer, aer_agent=Requester ID
    [ 148.918806] tg3 0000:04:00.0: AER: aer_uncor_severity: 0x000ef030
    [ 148.925558] tg3 0000:04:00.0: AER: TLP Header: 40000001 0000030f 90028090 00000000
    
    The MSI is probably raised by incoming packets, so power down the device
    and disable bus mastering to stop the traffic, as user confirmed this
    approach works.
    
    In addition to that, be extra safe and cancel reset task if it's running.
    
    Cc: Josef Bacik <josef@toxicpanda.com>
    Link: https://lore.kernel.org/all/b8db79e6857c41dab4ef08bdf826ea7c47e3bafc.1615947283.git.josef@toxicpanda.com/
    BugLink: https://bugs.launchpad.net/bugs/1917471
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Reviewed-by: Michael Chan <michael.chan@broadcom.com>
    Link: https://lore.kernel.org/r/20220826002530.1153296-1-kai.heng.feng@canonical.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
usb: storage: Add ASUS <0x0b05:0x1932> to IGNORE_UAS [+ + +]
Author: Hu Xiaoying <huxiaoying@kylinos.cn>
Date:   Thu Sep 1 12:57:37 2022 +0800

    usb: storage: Add ASUS <0x0b05:0x1932> to IGNORE_UAS
    
    [ Upstream commit c61feaee68b9735be06f162bc046c7f1959efb0c ]
    
    USB external storage device(0x0b05:1932), use gnome-disk-utility tools
    to test usb write  < 30MB/s.
    if does not to load module of uas for this device, can increase the
    write speed from 20MB/s to >40MB/s.
    
    Suggested-by: Matthias Kaehlcke <mka@chromium.org>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Hu Xiaoying <huxiaoying@kylinos.cn>
    Link: https://lore.kernel.org/r/20220901045737.3438046-1-huxiaoying@kylinos.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>