Список изменений в Linux 5.15.69

 
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>

 
ARM: dts: at91: fix low limit for CPU regulator [+ + +]
Author: Claudiu Beznea <claudiu.beznea@microchip.com>
Date:   Thu Jan 13 16:48:56 2022 +0200

    ARM: dts: at91: fix low limit for CPU regulator
    
    [ Upstream commit 279d626d737486363233b9b99c30b5696c389b41 ]
    
    Fix low limit for CPU regulator. Otherwise setting voltages lower than
    1.125V will not be allowed (CPUFreq will not be allowed to set proper
    voltages on proper frequencies).
    
    Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Link: https://lore.kernel.org/r/20220113144900.906370-7-claudiu.beznea@microchip.com
    Stable-dep-of: 7f41d52ced9e ("ARM: dts: at91: sama7g5ek: specify proper regulator output ranges")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: at91: sama7g5ek: specify proper regulator output ranges [+ + +]
Author: Claudiu Beznea <claudiu.beznea@microchip.com>
Date:   Fri Aug 26 11:39:24 2022 +0300

    ARM: dts: at91: sama7g5ek: specify proper regulator output ranges
    
    [ Upstream commit 7f41d52ced9e1b7ed4ff8e1ae9cacbf46b64e6db ]
    
    Min and max output ranges of regulators need to satisfy board
    requirements not PMIC requirements. Thus adjust device tree to
    cope with this.
    
    Fixes: 7540629e2fc7 ("ARM: dts: at91: add sama7g5 SoC DT and sama7g5-ek")
    Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Link: https://lore.kernel.org/r/20220826083927.3107272-7-claudiu.beznea@microchip.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx6qdl-kontron-samx6i: fix spi-flash compatible [+ + +]
Author: Marco Felsch <m.felsch@pengutronix.de>
Date:   Tue Jul 26 15:05:22 2022 +0200

    ARM: dts: imx6qdl-kontron-samx6i: fix spi-flash compatible
    
    [ Upstream commit af7d78c957017f8b3a0986769f6f18e57f9362ea ]
    
    Drop the "winbond,w25q16dw" compatible since it causes to set the
    MODALIAS to w25q16dw which is not specified within spi-nor id table.
    Fix this by use the common "jedec,spi-nor" compatible.
    
    Fixes: 2125212785c9 ("ARM: dts: imx6qdl-kontron-samx6i: add Kontron SMARC SoM Support")
    Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx: align SPI NOR node name with dtschema [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Thu Apr 7 16:31:54 2022 +0200

    ARM: dts: imx: align SPI NOR node name with dtschema
    
    [ Upstream commit ba9fe460dc2cfe90dc115b22af14dd3f13cffa0f ]
    
    The node names should be generic and SPI NOR dtschema expects "flash".
    
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Stable-dep-of: af7d78c95701 ("ARM: dts: imx6qdl-kontron-samx6i: fix spi-flash compatible")
    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/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: 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>

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

    Linux 5.15.69
    
    Link: https://lore.kernel.org/r/20220916100446.916515275@linuxfoundation.org
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
lockdep: Fix -Wunused-parameter for _THIS_IP_ [+ + +]
Author: Nick Desaulniers <ndesaulniers@google.com>
Date:   Mon Mar 14 15:19:03 2022 -0700

    lockdep: Fix -Wunused-parameter for _THIS_IP_
    
    [ Upstream commit 8b023accc8df70e72f7704d29fead7ca914d6837 ]
    
    While looking into a bug related to the compiler's handling of addresses
    of labels, I noticed some uses of _THIS_IP_ seemed unused in lockdep.
    Drive by cleanup.
    
    -Wunused-parameter:
    kernel/locking/lockdep.c:1383:22: warning: unused parameter 'ip'
    kernel/locking/lockdep.c:4246:48: warning: unused parameter 'ip'
    kernel/locking/lockdep.c:4844:19: warning: unused parameter 'ip'
    
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Waiman Long <longman@redhat.com>
    Link: https://lore.kernel.org/r/20220314221909.2027027-1-ndesaulniers@google.com
    Stable-dep-of: 54c3931957f6 ("tracing: hold caller_addr to hardirq_{enable,disable}_ip")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm: Fix TLB flush for not-first PFNMAP mappings in unmap_region() [+ + +]
Author: Jann Horn <jannh@google.com>
Date:   Thu Sep 15 16:25:19 2022 +0200

    mm: Fix TLB flush for not-first PFNMAP mappings in unmap_region()
    
    This is a stable-specific patch.
    I botched the stable-specific rewrite of
    commit b67fbebd4cf98 ("mmu_gather: Force tlb-flush VM_PFNMAP vmas"):
    As Hugh pointed out, unmap_region() actually operates on a list of VMAs,
    and the variable "vma" merely points to the first VMA in that list.
    So if we want to check whether any of the VMAs we're operating on is
    PFNMAP or MIXEDMAP, we have to iterate through the list and check each VMA.
    
    Signed-off-by: Jann Horn <jannh@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
NFS: Fix WARN_ON due to unionization of nfs_inode.nrequests [+ + +]
Author: Dave Wysochanski <dwysocha@redhat.com>
Date:   Sun Oct 10 18:23:13 2021 -0400

    NFS: Fix WARN_ON due to unionization of nfs_inode.nrequests
    
    commit 0ebeebcf59601bcfa0284f4bb7abdec051eb856d upstream.
    
    Fixes the following WARN_ON
    WARNING: CPU: 2 PID: 18678 at fs/nfs/inode.c:123 nfs_clear_inode+0x3b/0x50 [nfs]
    ...
    Call Trace:
      nfs4_evict_inode+0x57/0x70 [nfsv4]
      evict+0xd1/0x180
      dispose_list+0x48/0x60
      evict_inodes+0x156/0x190
      generic_shutdown_super+0x37/0x110
      nfs_kill_super+0x1d/0x40 [nfs]
      deactivate_locked_super+0x36/0xa0
    
    Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
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>

 
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>

 
soc: fsl: select FSL_GUTS driver for DPIO [+ + +]
Author: Mathew McBride <matt@traverse.com.au>
Date:   Thu Sep 1 05:21:49 2022 +0000

    soc: fsl: select FSL_GUTS driver for DPIO
    
    commit 9a472613f5bccf1b36837423495ae592a9c5182f upstream.
    
    The soc/fsl/dpio driver will perform a soc_device_match()
    to determine the optimal cache settings for a given CPU core.
    
    If FSL_GUTS is not enabled, this search will fail and
    the driver will not configure cache stashing for the given
    DPIO, and a string of "unknown SoC" messages will appear:
    
    fsl_mc_dpio dpio.7: unknown SoC version
    fsl_mc_dpio dpio.6: unknown SoC version
    fsl_mc_dpio dpio.5: unknown SoC version
    
    Fixes: 51da14e96e9b ("soc: fsl: dpio: configure cache stashing destination")
    Signed-off-by: Mathew McBride <matt@traverse.com.au>
    Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20220901052149.23873-2-matt@traverse.com.au'
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
task_stack, x86/cea: Force-inline stack helpers [+ + +]
Author: Borislav Petkov <bp@suse.de>
Date:   Wed Mar 23 20:02:41 2022 +0100

    task_stack, x86/cea: Force-inline stack helpers
    
    [ Upstream commit e87f4152e542610d0b4c6c8548964a68a59d2040 ]
    
    Force-inline two stack helpers to fix the following objtool warnings:
    
      vmlinux.o: warning: objtool: in_task_stack()+0xc: call to task_stack_page() leaves .noinstr.text section
      vmlinux.o: warning: objtool: in_entry_stack()+0x10: call to cpu_entry_stack() leaves .noinstr.text section
    
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20220324183607.31717-2-bp@alien8.de
    Stable-dep-of: 54c3931957f6 ("tracing: hold caller_addr to hardirq_{enable,disable}_ip")
    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>

 
tracefs: Only clobber mode/uid/gid on remount if asked [+ + +]
Author: Brian Norris <briannorris@chromium.org>
Date:   Fri Aug 26 17:44:17 2022 -0700

    tracefs: Only clobber mode/uid/gid on remount if asked
    
    [ Upstream commit 47311db8e8f33011d90dee76b39c8886120cdda4 ]
    
    Users may have explicitly configured their tracefs permissions; we
    shouldn't overwrite those just because a second mount appeared.
    
    Only clobber if the options were provided at mount time.
    
    Note: the previous behavior was especially surprising in the presence of
    automounted /sys/kernel/debug/tracing/.
    
    Existing behavior:
    
      ## Pre-existing status: tracefs is 0755.
      # stat -c '%A' /sys/kernel/tracing/
      drwxr-xr-x
    
      ## (Re)trigger the automount.
      # umount /sys/kernel/debug/tracing
      # stat -c '%A' /sys/kernel/debug/tracing/.
      drwx------
    
      ## Unexpected: the automount changed mode for other mount instances.
      # stat -c '%A' /sys/kernel/tracing/
      drwx------
    
    New behavior (after this change):
    
      ## Pre-existing status: tracefs is 0755.
      # stat -c '%A' /sys/kernel/tracing/
      drwxr-xr-x
    
      ## (Re)trigger the automount.
      # umount /sys/kernel/debug/tracing
      # stat -c '%A' /sys/kernel/debug/tracing/.
      drwxr-xr-x
    
      ## Expected: the automount does not change other mount instances.
      # stat -c '%A' /sys/kernel/tracing/
      drwxr-xr-x
    
    Link: https://lkml.kernel.org/r/20220826174353.2.Iab6e5ea57963d6deca5311b27fb7226790d44406@changeid
    
    Cc: stable@vger.kernel.org
    Fixes: 4282d60689d4f ("tracefs: Add new tracefs file system")
    Signed-off-by: Brian Norris <briannorris@chromium.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tracing: hold caller_addr to hardirq_{enable,disable}_ip [+ + +]
Author: Yipeng Zou <zouyipeng@huawei.com>
Date:   Thu Sep 1 18:45:14 2022 +0800

    tracing: hold caller_addr to hardirq_{enable,disable}_ip
    
    [ Upstream commit 54c3931957f6a6194d5972eccc36d052964b2abe ]
    
    Currently, The arguments passing to lockdep_hardirqs_{on,off} was fixed
    in CALLER_ADDR0.
    The function trace_hardirqs_on_caller should have been intended to use
    caller_addr to represent the address that caller wants to be traced.
    
    For example, lockdep log in riscv showing the last {enabled,disabled} at
    __trace_hardirqs_{on,off} all the time(if called by):
    [   57.853175] hardirqs last  enabled at (2519): __trace_hardirqs_on+0xc/0x14
    [   57.853848] hardirqs last disabled at (2520): __trace_hardirqs_off+0xc/0x14
    
    After use trace_hardirqs_xx_caller, we can get more effective information:
    [   53.781428] hardirqs last  enabled at (2595): restore_all+0xe/0x66
    [   53.782185] hardirqs last disabled at (2596): ret_from_exception+0xa/0x10
    
    Link: https://lkml.kernel.org/r/20220901104515.135162-2-zouyipeng@huawei.com
    
    Cc: stable@vger.kernel.org
    Fixes: c3bc8fd637a96 ("tracing: Centralize preemptirq tracepoints and unify their usage")
    Signed-off-by: Yipeng Zou <zouyipeng@huawei.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
usb: gadget: f_uac2: clean up some inconsistent indenting [+ + +]
Author: Colin Ian King <colin.i.king@gmail.com>
Date:   Thu Sep 2 23:47:58 2021 +0100

    usb: gadget: f_uac2: clean up some inconsistent indenting
    
    commit 18d6b39ee8959c6e513750879b52fd215533cc87 upstream.
    
    There are bunch of statements where the indentation is not correct,
    clean these up.
    
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Link: https://lore.kernel.org/r/20210902224758.57600-1-colin.king@canonical.com
    Signed-off-by: Jack Pham <quic_jackp@quicinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: f_uac2: fix superspeed transfer [+ + +]
Author: Jing Leng <jleng@ambarella.com>
Date:   Wed Jul 20 18:48:15 2022 -0700

    usb: gadget: f_uac2: fix superspeed transfer
    
    commit f511aef2ebe5377d4c263842f2e0c0b8e274e8e5 upstream.
    
    On page 362 of the USB3.2 specification (
    https://usb.org/sites/default/files/usb_32_20210125.zip),
    The 'SuperSpeed Endpoint Companion Descriptor' shall only be returned
    by Enhanced SuperSpeed devices that are operating at Gen X speed.
    Each endpoint described in an interface is followed by a 'SuperSpeed
    Endpoint Companion Descriptor'.
    
    If users use SuperSpeed UDC, host can't recognize the device if endpoint
    doesn't have 'SuperSpeed Endpoint Companion Descriptor' followed.
    
    Currently in the uac2 driver code:
    1. ss_epout_desc_comp follows ss_epout_desc;
    2. ss_epin_fback_desc_comp follows ss_epin_fback_desc;
    3. ss_epin_desc_comp follows ss_epin_desc;
    4. Only ss_ep_int_desc endpoint doesn't have 'SuperSpeed Endpoint
    Companion Descriptor' followed, so we should add it.
    
    Fixes: eaf6cbe09920 ("usb: gadget: f_uac2: add volume and mute support")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Jing Leng <jleng@ambarella.com>
    Signed-off-by: Jack Pham <quic_jackp@quicinc.com>
    Link: https://lore.kernel.org/r/20220721014815.14453-1-quic_jackp@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
x86/mm: Force-inline __phys_addr_nodebug() [+ + +]
Author: Borislav Petkov <bp@suse.de>
Date:   Wed Mar 23 23:24:12 2022 +0100

    x86/mm: Force-inline __phys_addr_nodebug()
    
    [ Upstream commit ace1a98519270c586c0d4179419292df67441cd1 ]
    
    Fix:
    
      vmlinux.o: warning: objtool: __sev_es_nmi_complete()+0x8b: call to __phys_addr_nodebug() leaves .noinstr.text section
    
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20220324183607.31717-4-bp@alien8.de
    Stable-dep-of: 54c3931957f6 ("tracing: hold caller_addr to hardirq_{enable,disable}_ip")
    Signed-off-by: Sasha Levin <sashal@kernel.org>