This project is mirrored from https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9.git.
Pull mirroring updated .
- Mar 27, 2025
-
-
-
Scott Weaver authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6238 # Merge Request Required Information ## Summary of Changes Disable The IPsec Protocols and XFRM (IPSec) Networking Security Hooks and it's related dependencies. CONFIG_XFRM\_\* has a dependency on CONFIG_INET\_\* and CONFIG_IPV6. Hence, the following: CONFIG_INET_AH CONFIG_INET6_AH CONFIG_INET6_ESP CONFIG_INET6_IPCOMP CONFIG_INET6_XFRM_TUNNEL CONFIG_NET_KEY needs to be disabled in automotive. This is needed to satisfy a requirement of FuSa efforts for RHIVOS. ## Approved Development Ticket(s) JIRA: https://issues.redhat.com/browse/RHEL-75561 Upstream-status: RHEL-only: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3617 Signed-off-by:
Dorinda Bassey <dbassey@redhat.com> <details><summary>Click for formatting instructions</summary> Please follow the CentOS Stream [contribution documentation](https://docs.centos.org/en-US/stream-contrib/quickstart/ ) for how to file this ticket and have it approved. List tickets each on their own line of this description using the format "Resolves: RHEL-1234", "Related: RHEL-2345" or "Reverts: RHEL-3456", as appropriate. </details> Approved-by:
Jiri Benc <jbenc@redhat.com> Approved-by:
Brian Masney <bmasney@redhat.com> Approved-by:
CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com> Merged-by:
Scott Weaver <scweaver@redhat.com>
-
Scott Weaver authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6533 re-enable CONFIG_AIO in rhel9 automotive JIRA: https://issues.redhat.com/browse/RHEL-82474 Resolves: RHEL-82474 Signed-off-by:
Davide Caratti <dcaratti@redhat.com> Approved-by:
Eric Chanudet <echanude@redhat.com> Approved-by:
-
Scott Weaver authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6568 JIRA: https://issues.redhat.com/browse/RHEL-83275 Upstream-status: RHEL-only The vxcan module is a software-only CAN bus driver that implements CAN bus interface pairs. It is similar to veth but for CAN bus. The main application is to test the various CAN bus protocol layers without requiring real CAN bus hardware. Signed-off-by:
Radu Rendec <rrendec@redhat.com> Approved-by:
Jared Kangas <jkangas@redhat.com> Approved-by:
-
Scott Weaver authored
kernel-5.14.0-575.el9 Signed-off-by:
-
- Mar 25, 2025
-
-
Dorinda Bassey authored
JIRA: https://issues.redhat.com/browse/RHEL-75561 Disable The IPsec Protocols and XFRM (IPSec) Networking Security Hooks and it's related dependencies. CONFIG_XFRM_* has a dependency on CONFIG_INET_*, CONFIG_IPV6 and CONFIG_NET_KEY. Hence, the following: CONFIG_INET_AH CONFIG_INET_ESP CONFIG_INET_IPCOMP CONFIG_NET_IPVTI CONFIG_INET6_AH CONFIG_INET6_ESP CONFIG_INET6_IPCOMP CONFIG_IPV6_VTI CONFIG_IPV6_MIP6 needs to be disabled in automotive. Upstream status: kernel-ark.git commit 75bff0bf3e67 commit 75bff0bf3e675bafb4e5039092ba3188788f9e10 Author: Dorinda Bassey <dbassey@redhat.com> Date: Tue Jan 21 18:43:28 2025 +0100 redhat/configs: automotive: Disable IPsec Protocols and XFRM Upstream Status: RHEL only Disable The IPsec Protocols and XFRM (IPSec) Networking Security Hooks and it's related dependencies. CONFIG_XFRM_* has a dependency on CONFIG_INET_* and CONFIG_IPV6. Hence, the following: CONFIG_INET_AH CONFIG_INET_ESP CONFIG_INET_IPCOMP CONFIG_NET_IPVTI CONFIG_INET6_AH CONFIG_INET6_ESP CONFIG_INET6_IPCOMP CONFIG_IPV6_VTI CONFIG_IPV6_MIP6 needs to be disabled in automotive. This is needed to satisfy a requirement of FuSa efforts for RHIVOS. Link: https://issues.redhat.com/browse/RHEL-75561 Signed-off-by:
-
- Mar 24, 2025
-
-
Augusto Caringi authored
Signed-off-by:Augusto Caringi <acaringi@redhat.com>
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6615 ``` JIRA: https://issues.redhat.com/browse/RHEL-81906 This series includes a set of key fixes related to PCIe's bandwidth link training from upstream v6.13 by taking in content from upstream merge request d957ff7acaf2 "Merge branch 'pci/bwctrl'". Signed-off-by:
Myron Stowe <mstowe@redhat.com> ``` Approved-by:
John W. Linville <linville@redhat.com> Approved-by:
Desnes Nunes <desnesn@redhat.com> Approved-by:
Tony Camuso <tcamuso@redhat.com> Merged-by:
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6390 JIRA: https://issues.redhat.com/browse/RHEL-79821 The following upstream commits were not applied due to scope: 66bc1a173328 treewide: Use sysfs_bin_attr_simple_read() helper 4a62d588a84e thermal: core: Eliminate writable trip points masks dd64594ca2c5 thermal: Switch back to struct platform_driver::remove() cdd30ebb1b9f module: Convert symbol namespace to string literal Upstream commit 423de5b5bc5b is included in this patchset as it provides a fix for upstream 94c6110b0b13 which was included in a recent update to drivers/thermal Signed-off-by:
David Arcari <darcari@redhat.com> Approved-by:
Steve Best <sbest@redhat.com> Approved-by:
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6547 Description: Updates for powerpc perf mem data JIRA: https://issues.redhat.com/browse/RHEL-80602 Build Info: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=66923908 Tested: Verified Brew build test kernel RPMs Signed-off-by:
Mamatha Inamdar <minamdar@redhat.com> Approved-by:
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6514 JIRA: https://issues.redhat.com/browse/RHEL-81929 commit 747ae81883d21595b162cc40523a982024700fed Author: Joachim Vandersmissen <git@jvdsn.com> Date: Sun May 12 23:55:07 2024 -0500 certs: Add ECDSA signature verification self-test Commit c27b2d2012e1 ("crypto: testmgr - allow ecdsa-nist-p256 and -p384 in FIPS mode") enabled support for ECDSA in crypto/testmgr.c. The PKCS#7 signature verification API builds upon the KCAPI primitives to perform its high-level operations. Therefore, this change in testmgr.c also allows ECDSA to be used by the PKCS#7 signature verification API (in FIPS mode). However, from a FIPS perspective, the PKCS#7 signature verification API is a distinct "service" from the KCAPI primitives. This is because the PKCS#7 API performs a "full" signature verification, which consists of both hashing the data to be verified, and the public key operation. On the other hand, the KCAPI primitive does not perform this hashing step - it accepts pre-hashed data from the caller and only performs the public key operation. For this reason, the ECDSA self-tests in crypto/testmgr.c are not sufficient to cover ECDSA signature verification offered by the PKCS#7 API. This is reflected by the self-test already present in this file for RSA PKCS#1 v1.5 signature verification. The solution is simply to add a second self-test here for ECDSA. P-256 with SHA-256 hashing was chosen as those parameters should remain FIPS-approved for the foreseeable future, while keeping the performance impact to a minimum. The ECDSA certificate and PKCS#7 signed data was generated using OpenSSL. The input data is identical to the input data for the existing RSA self-test. Signed-off-by:
Joachim Vandersmissen <git@jvdsn.com> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Herbert Xu <herbert.xu@redhat.com> Approved-by:
Vladis Dronov <vdronov@redhat.com> Approved-by:
Coiby Xu <coxu@redhat.com> Approved-by:
Clemens Lang <cllang@redhat.com> Approved-by:
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6413 JIRA: https://issues.redhat.com/browse/RHEL-77838 Patches: `a1afb959add1f ("dpll: add clock quality level attribute and op") ` Signed-off-by:
Petr Oros <poros@redhat.com> Approved-by:
Ivan Vecera <ivecera@redhat.com> Approved-by:
Michal Schmidt <mschmidt@redhat.com> Approved-by:
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6475 JIRA: https://issues.redhat.com/browse/RHEL-81489 CVE: CVE-2024-58005 ``` commit a3a860bc0fd6c07332e4911cf9a238d20de90173 Author: Jarkko Sakkinen <jarkko@kernel.org> Date: Fri Dec 27 17:39:09 2024 +0200 tpm: Change to kvalloc() in eventlog/acpi.c The following failure was reported on HPE ProLiant D320: [ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [ 10.848132][ T1] ------------[ cut here ]------------ [ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [ 10.862827][ T1] Modules linked in: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330 [ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0 The above transcript shows that ACPI pointed a 16 MiB buffer for the log events because RSI maps to the 'order' parameter of __alloc_pages_noprof(). Address the bug by moving from devm_kmalloc() to devm_add_action() and kvmalloc() and devm_add_action(). Suggested-by:
Ard Biesheuvel <ardb@kernel.org> Cc: stable@vger.kernel.org # v2.6.16+ Fixes: 55a82ab3 ("[PATCH] tpm: add bios measurement log") Reported-by:
Andy Liang <andy.liang@hpe.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219495 Reviewed-by:
Stefan Berger <stefanb@linux.ibm.com> Reviewed-by:
Takashi Iwai <tiwai@suse.de> Tested-by:
Jarkko Sakkinen <jarkko@kernel.org>```> Signed-off-by:
CKI Backport Bot <cki-ci-bot+cki-gitlab-backport-bot@redhat.com> --- <small>Created 2025-02-27 22:45 UTC by backporter - [KWF FAQ](https://red.ht/kernel_workflow_doc) - [Slack #team-kernel-workflow](https://redhat-internal.slack.com/archives/C04LRUPMJQ5) - [Source](https://gitlab.com/cki-project/kernel-workflow/-/blob/main/webhook/utils/backporter.py) - [Documentation](https://gitlab.com/cki-project/kernel-workflow/-/blob/main/docs/README.backporter.md) - [Report an issue](https://gitlab.com/cki-project/kernel-workflow/-/issues/new?issue%5Btitle%5D=backporter%20webhook%20issue)</small > Approved-by:
Štěpán Horáček <shoracek@redhat.com> Approved-by:
Jerry Snitselaar <jsnitsel@redhat.com> Approved-by:
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6599 JIRA: https://issues.redhat.com/browse/RHEL-74363 This patch is a backport of the following upstream commit: commit 67a2f86846f244d81601cf2e1552c4656b8556d6 Author: Rafael Aquini <raquini@redhat.com> Date: Tue Feb 18 14:22:51 2025 -0500 selftests/mm: run_vmtests.sh: fix half_ufd_size_MB calculation We noticed that uffd-stress test was always failing to run when invoked for the hugetlb profiles on x86_64 systems with a processor count of 64 or bigger: ... ... not ok 3 uffd-stress hugetlb 128 32 # exit=1 ... The problem boils down to how run_vmtests.sh (mis)calculates the size of the region it feeds to uffd-stress. The latter expects to see an amount of MiB while the former is just giving out the number of free hugepages halved down. This measurement discrepancy ends up violating uffd-stress' assertion on number of hugetlb pages allocated per CPU, causing it to bail out with the error above. This commit fixes that issue by adjusting run_vmtests.sh's half_ufd_size_MB calculation so it properly renders the region size in MiB, as expected, while maintaining all of its original constraints in place. Link: https://lkml.kernel.org/r/20250218192251.53243-1-aquini@redhat.com Fixes: 2e47a445d7b3 ("selftests/mm: run_vmtests.sh: fix hugetlb mem size calculation") Signed-off-by:
Rafael Aquini <raquini@redhat.com> Reviewed-by:
David Hildenbrand <david@redhat.com> Reviewed-by:
Peter Xu <peterx@redhat.com> Cc: Shuah Khan <shuah@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Nico Pache <npache@redhat.com> Approved-by:
Herton R. Krzesinski <herton@redhat.com> Approved-by:
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6566 JIRA: https://issues.redhat.com/browse/RHEL-81542 Upstream Status: linux.git CVE: CVE-2025-21791 Signed-off-by:
Guillaume Nault <gnault@redhat.com> Approved-by:
Antoine Tenart <atenart@redhat.com> Approved-by:
Florian Westphal <fwestpha@redhat.com> Approved-by:
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6593 JIRA: https://issues.redhat.com/browse/RHEL-83858 Signed-off-by:
Paulo Alcantara <paalcant@redhat.com> Approved-by:
Jay Shin <jaeshin@redhat.com> Approved-by:
Benjamin Coddington <bcodding@redhat.com> Approved-by:
Scott Mayhew <smayhew@redhat.com> Approved-by:
-
- Mar 21, 2025
-
-
-
Scott Weaver authored
kernel-automotive-5.14.0-570.518.5.1.5.el9_6iv Signed-off-by: -
Scott Weaver authored
kernel-5.14.0-574.el9 Signed-off-by:
-
- Mar 20, 2025
-
-
Myron Stowe authored
JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: 15b8968dcb90f194d44501468b230e6e0d816d4a Conflict(s): Patching file drivers/pci/pcie/bwctrl.c; Hunk #2 FAILED at 334. This is due to RHEL not having incorporated the "PCIe cooling" driver (see upstream commit d278b098282d "thermal: Add PCIe cooling driver"). commit 15b8968dcb90f194d44501468b230e6e0d816d4a Author: Lukas Wunner <lukas@wunner.de> Date: Mon Jan 6 12:26:35 2025 +0100 PCI/bwctrl: Fix NULL pointer deref on unbind and bind The interrupt handler for bandwidth notifications, pcie_bwnotif_irq(), dereferences a "data" pointer. On unbind, that pointer is set to NULL by pcie_bwnotif_remove(). However the interrupt handler may still be invoked afterwards and will dereference that NULL pointer. That's because the interrupt is requested using a devm_*() helper and the driver core releases devm_*() resources *after* calling ->remove(). pcie_bwnotif_remove() does clear the Link Bandwidth Management Interrupt Enable and Link Autonomous Bandwidth Interrupt Enable bits in the Link Control Register, but that won't prevent execution of pcie_bwnotif_irq(): The interrupt for bandwidth notifications may be shared with AER, DPC, PME, and hotplug. So pcie_bwnotif_irq() may be executed as long as the interrupt is requested. There's a similar race on bind: pcie_bwnotif_probe() requests the interrupt when the "data" pointer still points to NULL. A NULL pointer deref may thus likewise occur if AER, DPC, PME or hotplug raise an interrupt in-between the bandwidth controller's call to devm_request_irq() and assignment of the "data" pointer. Drop the devm_*() usage and reorder requesting of the interrupt to fix the issue. While at it, drop a stray but harmless no_free_ptr() invocation when assigning the "data" pointer in pcie_bwnotif_probe(). Ilpo points out that the locking on unbind and bind needs to be symmetric, so move the call to pcie_bwnotif_disable() inside the critical section protected by pcie_bwctrl_setspeed_rwsem and pcie_bwctrl_lbms_rwsem. Evert reports a hang on shutdown of an ASUS ROG Strix SCAR 17 G733PYV. The issue is no longer reproducible with the present commit. Evert found that attaching a USB-C monitor prevented the hang. The machine contains an ASMedia USB 3.2 controller below a hotplug-capable Root Port. So one possible explanation is that the controller gets hot-removed on shutdown unless something is connected. And the ensuing hotplug interrupt occurs exactly when the bandwidth controller is unregistering. The precise cause could not be determined because the screen had already turned black when the hang occurred. Link: https://lore.kernel.org/r/ae2b02c9cfbefff475b6e132b0aa962aaccbd7b2.1736162539.git.lukas@wunner.de Fixes: 665745f27487 ("PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller") Reported-by:
Evert Vorster <evorster@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219629 Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Tested-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by:
-
Myron Stowe authored
JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: 774c71c52aa487001c7da9f93b10cedc9985c371 commit 774c71c52aa487001c7da9f93b10cedc9985c371 Author: Lukas Wunner <lukas@wunner.de> Date: Tue Dec 17 10:51:02 2024 +0100 PCI/bwctrl: Enable only if more than one speed is supported If a PCIe port only supports a single speed, enabling bandwidth control is pointless: There's no need to monitor autonomous speed changes, nor can the speed be changed. Not enabling it saves a small amount of memory and compute resources, but also fixes a boot hang reported by Niklas: It occurs when enabling bandwidth control on Downstream Ports of Intel JHL7540 "Titan Ridge 2018" Thunderbolt controllers. The ports only support 2.5 GT/s in accordance with USB4 v2 sec 11.2.1, so the present commit works around the issue. PCIe r6.2 sec 8.2.1 prescribes that: "A device must support 2.5 GT/s and is not permitted to skip support for any data rates between 2.5 GT/s and the highest supported rate." Consequently, bandwidth control is currently only disabled if a port doesn't support higher speeds than 2.5 GT/s. However the Implementation Note in PCIe r6.2 sec 7.5.3.18 cautions: "It is strongly encouraged that software primarily utilize the Supported Link Speeds Vector instead of the Max Link Speed field, so that software can determine the exact set of supported speeds on current and future hardware. This can avoid software being confused if a future specification defines Links that do not require support for all slower speeds." In other words, future revisions of the PCIe Base Spec may allow gaps in the Supported Link Speeds Vector. To be future-proof, don't just check whether speeds above 2.5 GT/s are supported, but rather check whether *more than one* speed is supported. Fixes: 665745f27487 ("PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller") Closes: https://lore.kernel.org/r/db8e457fcd155436449b035e8791a8241b0df400.camel@kernel.org Link: https://lore.kernel.org/r/3564908a9c99fc0d2a292473af7a94ebfc8f5820.1734428762.git.lukas@wunner.de Reported-by:
Niklas Schnelle <niks@kernel.org> Tested-by:
Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by:
Jonathan Cameron <Jonthan.Cameron@huawei.com> Reviewed-by:
Mario Limonciello <mario.limonciello@amd.com> Reviewed-by:
-
Myron Stowe authored
JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: 3202ca221578850f34e0fea39dc6cfa745ed7aac commit 3202ca221578850f34e0fea39dc6cfa745ed7aac Author: Lukas Wunner <lukas@wunner.de> Date: Tue Dec 17 10:51:01 2024 +0100 PCI: Honor Max Link Speed when determining supported speeds The Supported Link Speeds Vector in the Link Capabilities 2 Register indicates the *supported* link speeds. The Max Link Speed field in the Link Capabilities Register indicates the *maximum* of those speeds. pcie_get_supported_speeds() neglects to honor the Max Link Speed field and will thus incorrectly deem higher speeds as supported. Fix it. One user-visible issue addressed here is an incorrect value in the sysfs attribute "max_link_speed". But the main motivation is a boot hang reported by Niklas: Intel JHL7540 "Titan Ridge 2018" Thunderbolt controllers supports 2.5-8 GT/s speeds, but indicate 2.5 GT/s as maximum. Ilpo recalls seeing this on more devices. It can be explained by the controller's Downstream Ports supporting 8 GT/s if an Endpoint is attached, but limiting to 2.5 GT/s if the port interfaces to a PCIe Adapter, in accordance with USB4 v2 sec 11.2.1: "This section defines the functionality of an Internal PCIe Port that interfaces to a PCIe Adapter. [...] The Logical sub-block shall update the PCIe configuration registers with the following characteristics: [...] Max Link Speed field in the Link Capabilities Register set to 0001b (data rate of 2.5 GT/s only). Note: These settings do not represent actual throughput. Throughput is implementation specific and based on the USB4 Fabric performance." The present commit is not sufficient on its own to fix Niklas' boot hang, but it is a prerequisite: A subsequent commit will fix the boot hang by enabling bandwidth control only if more than one speed is supported. The GENMASK() macro used herein specifies 0 as lowest bit, even though the Supported Link Speeds Vector ends at bit 1. This is done on purpose to avoid a GENMASK(0, 1) macro if Max Link Speed is zero. That macro would be invalid as the lowest bit is greater than the highest bit. Ilpo has witnessed a zero Max Link Speed on Root Complex Integrated Endpoints in particular, so it does occur in practice. (The Link Capabilities Register is optional on RCiEPs per PCIe r6.2 sec 7.5.3.) Fixes: d2bd39c0456b ("PCI: Store all PCIe Supported Link Speeds") Closes: https://lore.kernel.org/r/70829798889c6d779ca0f6cd3260a765780d1369.camel@kernel.org Link: https://lore.kernel.org/r/fe03941e3e1cc42fb9bf4395e302bff53ee2198b.1734428762.git.lukas@wunner.de Reported-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by:
-
Myron Stowe authored
JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: ba58eee1c57b2ad45c36f782861c18faef170a55 commit ba58eee1c57b2ad45c36f782861c18faef170a55 Author: Bjorn Helgaas <bhelgaas@google.com> Date: Mon Nov 11 14:21:33 2024 -0600 PCI: Drop duplicate pcie_get_speed_cap(), pcie_get_width_cap() declarations 6cf57be0 ("PCI: Add pcie_get_speed_cap() to find max supported link speed") and c70b65fb ("PCI: Add pcie_get_width_cap() to find max supported link width") added declarations to drivers/pci/pci.h. 576c7218 ("PCI: Export pcie_get_speed_cap and pcie_get_width_cap") subsequently added duplicates to include/linux/pci.h. Remove the originals from drivers/pci/pci.h. Both interfaces are used by amdgpu, so they must be in include/linux/pci.h. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Acked-by:
Krzysztof Wilczyński <kw@linux.com> Signed-off-by:
-
Myron Stowe authored
JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: de9a6c8d5dbfedb5eb3722c822da0490f6a59a45 commit de9a6c8d5dbfedb5eb3722c822da0490f6a59a45 Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Date: Fri Oct 18 17:47:53 2024 +0300 PCI/bwctrl: Add pcie_set_target_speed() to set PCIe Link Speed Currently, PCIe Link Speeds are adjusted by custom code rather than in a common function provided in PCI core. The PCIe bandwidth controller (bwctrl) introduces an in-kernel API, pcie_set_target_speed(), to set PCIe Link Speed. Convert Target Speed quirk to use the new API. The Target Speed quirk runs very early when bwctrl is not yet probed for a Port and can also run later when bwctrl is already setup for the Port, which requires the per port mutex (set_speed_mutex) to be only taken if the bwctrl setup is already complete. The new API is also intended to be used in an upcoming commit that adds a thermal cooling device to throttle PCIe bandwidth when thermal thresholds are reached. The PCIe bandwidth control procedure is as follows. The highest speed supported by the Port and the PCIe device which is not higher than the requested speed is selected and written into the Target Link Speed in the Link Control 2 Register. Then bandwidth controller retrains the PCIe Link. Bandwidth Notifications enable the cur_bus_speed in the struct pci_bus to keep track PCIe Link Speed changes. While Bandwidth Notifications should also be generated when bandwidth controller alters the PCIe Link Speed, a few platforms do not deliver LMBS interrupt after Link Training as expected. Thus, after changing the Link Speed, bandwidth controller makes additional read for the Link Status Register to ensure cur_bus_speed is consistent with the new PCIe Link Speed. Link: https://lore.kernel.org/r/20241018144755.7875-8-ilpo.jarvinen@linux.intel.com Signed-off-by:
-
Myron Stowe authored
JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: 665745f274870c921020f610e2c99a3b1613519b commit 665745f274870c921020f610e2c99a3b1613519b Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Date: Fri Oct 18 17:47:52 2024 +0300 PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller This mostly reverts the commit b4c7d207 ("PCI/LINK: Remove bandwidth notification"). An upcoming commit extends this driver building PCIe bandwidth controller on top of it. PCIe bandwidth notifications were first added in the commit e8303bb7 ("PCI/LINK: Report degraded links via link bandwidth notification") but later had to be removed. The significant changes compared with the old bandwidth notification driver include: 1) Don't print the notifications into kernel log, just keep the Link Speed cached in struct pci_bus updated. While somewhat unfortunate, the log spam was the source of complaints that eventually lead to the removal of the bandwidth notifications driver (see the links below for further information). 2) Besides the Link Bandwidth Management Interrupt, also enable Link Autonomous Bandwidth Interrupt to cover the other source of bandwidth changes. 3) Handle Link Speed updates robustly. Refresh the cached Link Speed when enabling Bandwidth Notification Interrupts, and solve the race between Link Speed read and LBMS/LABS update in pcie_bwnotif_irq_thread(). 4) Use concurrency safe LNKCTL RMW operations. 5) The driver is now called PCIe bwctrl (bandwidth controller) instead of just bandwidth notifications because of increased scope and functionality within the driver. 6) Coexist with the Target Link Speed quirk in pcie_failed_link_retrain(). Provide LBMS counting API for it. 7) Tweaks to variable/functions names for consistency and length reasons. Bandwidth Notifications enable the cur_bus_speed in the struct pci_bus to keep track PCIe Link Speed changes. [bhelgaas: This is based on previous work by Alexandru Gagniuc <mr.nuke.me@gmail.com>; see e8303bb7 ("PCI/LINK: Report degraded links via link bandwidth notification")] Link: https://lore.kernel.org/r/20241018144755.7875-7-ilpo.jarvinen@linux.intel.com Link: https://lore.kernel.org/all/20190429185611.121751-1-helgaas@kernel.org/ Link: https://lore.kernel.org/linux-pci/20190501142942.26972-1-keith.busch@intel.com/ Link: https://lore.kernel.org/linux-pci/20200115221008.GA191037@google.com/ Suggested-by: Lukas Wunner <lukas@wunner.de> # Building bwctrl on top of bwnotif Signed-off-by:
Stefan Wahren <wahrenst@gmx.net> Reviewed-by:
-
Myron Stowe authored
JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: 3491f509666865412ad344cd4dde9f3c5a52326e commit 3491f509666865412ad344cd4dde9f3c5a52326e Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Date: Fri Oct 18 17:47:51 2024 +0300 PCI: Abstract LBMS seen check into pcie_lbms_seen() The Target Speed quirk in pcie_failed_link_retrain() uses the presence of LBMS bit as one of the triggering conditions, effectively monopolizing the use of that bit. An upcoming change will introduce a PCIe bandwidth controller which sets up an interrupt to track LBMS. As LBMS will be cleared by the interrupt handler, the Target Speed quirk will no longer be able to observe LBMS directly. As a preparatory step for the change, extract the LBMS seen check from pcie_failed_link_retrain() into a new function pcie_lmbs_seen(). Link: https://lore.kernel.org/r/20241018144755.7875-6-ilpo.jarvinen@linux.intel.com Signed-off-by:
-
Myron Stowe authored
JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: e93d9fcfd7dc643eb5fce43053774d27bea2b263 commit e93d9fcfd7dc643eb5fce43053774d27bea2b263 Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Date: Fri Oct 18 17:47:50 2024 +0300 PCI: Refactor pcie_update_link_speed() pcie_update_link_speed() is passed the Link Status register but not all callers have that value at hand nor need the value. Refactor pcie_update_link_speed() to include reading the Link Status register and create __pcie_update_link_speed() which can be used by the hotplug code that has the register value at hand beforehand (and needs the value for other purposes). Link: https://lore.kernel.org/r/20241018144755.7875-5-ilpo.jarvinen@linux.intel.com Signed-off-by:
-
Myron Stowe authored
JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: d2bd39c0456b75be9dfc7d774b8d021355c26ae3 commit d2bd39c0456b75be9dfc7d774b8d021355c26ae3 Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Date: Fri Oct 18 17:47:49 2024 +0300 PCI: Store all PCIe Supported Link Speeds The PCIe bandwidth controller added by a subsequent commit will require selecting PCIe Link Speeds that are lower than the Maximum Link Speed. The struct pci_bus only stores max_bus_speed. Even if PCIe r6.1 sec 8.2.1 currently disallows gaps in supported Link Speeds, the Implementation Note in PCIe r6.1 sec 7.5.3.18, recommends determining supported Link Speeds using the Supported Link Speeds Vector in the Link Capabilities 2 Register (when available) to "avoid software being confused if a future specification defines Links that do not require support for all slower speeds." Reuse code in pcie_get_speed_cap() to add pcie_get_supported_speeds() to query the Supported Link Speeds Vector of a PCIe device. The value is taken directly from the Supported Link Speeds Vector or synthesized from the Max Link Speed in the Link Capabilities Register when the Link Capabilities 2 Register is not available. The Supported Link Speeds Vector in the Link Capabilities Register 2 corresponds to the bus below on Root Ports and Downstream Ports, whereas it corresponds to the bus above on Upstream Ports and Endpoints (PCIe r6.1 sec 7.5.3.18): Supported Link Speeds Vector - This field indicates the supported Link speed(s) of the associated Port. Add supported_speeds into the struct pci_dev that caches the Supported Link Speeds Vector. supported_speeds contains a set of Link Speeds only in the case where PCIe Link Speed can be determined. Root Complex Integrated Endpoints do not have a well-defined Link Speed because they do not implement either of the Link Capabilities Registers, which is allowed by PCIe r6.1 sec 7.5.3 (the same limitation applies to determining cur_bus_speed and max_bus_speed that are PCI_SPEED_UNKNOWN in such case). This is of no concern from PCIe bandwidth controller point of view because such devices are not attached into a PCIe Root Port that could be controlled. The supported_speeds field keeps the extra reserved zero at the least significant bit to match the Link Capabilities 2 Register layout. An attempt was made to store supported_speeds field into the struct pci_bus as an intersection of both ends of the Link, however, the subordinate struct pci_bus is not available early enough. The Target Speed quirk (in pcie_failed_link_retrain()) can run either during initial scan or later, requiring it to use the API provided by the PCIe bandwidth controller to set the Target Link Speed in order to co-exist with the bandwidth controller. When the Target Speed quirk is calling the bandwidth controller during initial scan, the struct pci_bus is not yet initialized. As such, storing supported_speeds into the struct pci_bus is not viable. Suggested-by:
-
Myron Stowe authored
JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: 04af8a399fa40310f831b4f1dc9f757085f41983 commit 04af8a399fa40310f831b4f1dc9f757085f41983 Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Date: Fri Oct 18 17:47:48 2024 +0300 PCI: Protect Link Control 2 Register with RMW locking The PCIe Bandwidth Controller performs RMW accesses the Link Control 2 Register which can occur concurrently to other sources of Link Control 2 Register writes. Therefore, add Link Control 2 Register among the PCI Express Capability Registers that need RMW locking. Link: https://lore.kernel.org/r/20241018144755.7875-3-ilpo.jarvinen@linux.intel.com Signed-off-by:
-
Myron Stowe authored
JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: fad610b987132868e3410c530871086552ce6155 commit fad610b987132868e3410c530871086552ce6155 Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Date: Fri Oct 18 17:47:47 2024 +0300 Documentation PCI: Reformat RMW ops documentation Extract the list of RMW protected PCIe Capability registers into a bullet list to make them easier to pick up on a glance. An upcoming change is going to add one more register among them so it will be much cleaner to have them as bullets. Link: https://lore.kernel.org/r/20241018144755.7875-2-ilpo.jarvinen@linux.intel.com Signed-off-by:
-
Augusto Caringi authored
Signed-off-by: -
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6429 JIRA: https://issues.redhat.com/browse/RHEL-80802 CVE: CVE-2022-49643 ``` commit d2ee2cfc4aa85ff6a2a3b198a3a524ec54e3d999 Author: Huaxin Lu <luhuaxin1@huawei.com> Date: Tue Jul 5 13:14:17 2022 +0800 ima: Fix a potential integer overflow in ima_appraise_measurement When the ima-modsig is enabled, the rc passed to evm_verifyxattr() may be negative, which may cause the integer overflow problem. Fixes: 39b07096 ("ima: Implement support for module-style appended signatures") Signed-off-by:
Huaxin Lu <luhuaxin1@huawei.com> Signed-off-by:
Mimi Zohar <zohar@linux.ibm.com>```> Signed-off-by:
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6588 JIRA: https://issues.redhat.com/browse/RHEL-60023 Tested: Ran the test on s390x and x86-64, with the expected output. Let's make the test also work as expected on architectures that have a different hugepage size than 2 MiB -- such as s390x. While at it, backport the test output cleanup part of the same upstream series. Signed-off-by:
mcasquer <mcasquer@redhat.com> Approved-by:
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6461 JIRA: https://issues.redhat.com/browse/RHEL-81375 CVE: CVE-2024-57988 ``` commit b88655bc6593c6a7fdc1248b212d17e581c4334e Author: Charles Han <hanchunchao@inspur.com> Date: Fri Dec 27 17:20:46 2024 +0800 Bluetooth: btbcm: Fix NULL deref in btbcm_get_board_name() devm_kstrdup() can return a NULL pointer on failure,but this returned value in btbcm_get_board_name() is not checked. Add NULL check in btbcm_get_board_name(), to handle kernel NULL pointer dereference error. Fixes: f9183eaad915 ("Bluetooth: btbcm: Use devm_kstrdup()") Signed-off-by:
Charles Han <hanchunchao@inspur.com> Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com>```> Signed-off-by:
Bastien Nocera <bnocera@redhat.com> Approved-by:
José Ignacio Tornos Martínez <jtornosm@redhat.com> Approved-by:
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6522 JIRA: https://issues.redhat.com/browse/RHEL-80985 CVE: CVE-2022-49443 Upstream Status: linux.git commit d679ae94fdd5d3ab00c35078f5af5f37e068b03d Author: Kuniyuki Iwashima <kuniyu@amazon.co.jp> Date: Fri Apr 29 14:38:01 2022 -0700 ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing. Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next. Commit bf3b9f63 ("epoll: Add busy poll support to epoll with socket fds.") added the first lockless ep_events_available(), and commit c5a282e9 ("fs/epoll: reduce the scope of wq lock in epoll_wait()") made some ep_events_available() calls lockless and added single call under a lock, finally commit e59d3c64 ("epoll: eliminate unnecessary lock for zero timeout") made the last ep_events_available() lockless. BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0xffff88810480c7d0 -> 0xffff888103c15098 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Link: https://lkml.kernel.org/r/20220322002653.33865-3-kuniyu@amazon.co.jp Fixes: e59d3c64 ("epoll: eliminate unnecessary lock for zero timeout") Fixes: c5a282e9 ("fs/epoll: reduce the scope of wq lock in epoll_wait()") Fixes: bf3b9f63 ("epoll: Add busy poll support to epoll with socket fds.") Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.co.jp> Reported-by:
<syzbot+bdd6e38a1ed5ee58d8bd@syzkaller.appspotmail.com> Cc: Al Viro <viro@zeniv.linux.org.uk>, Andrew Morton <akpm@linux-foundation.org> Cc: Kuniyuki Iwashima <kuniyu@amazon.co.jp> Cc: Kuniyuki Iwashima <kuni1840@gmail.com> Cc: "Soheil Hassas Yeganeh" <soheil@google.com> Cc: Davidlohr Bueso <dave@stgolabs.net> Cc: "Sridhar Samudrala" <sridhar.samudrala@intel.com> Cc: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
Jan Stancek <jstancek@redhat.com> Approved-by:
Waiman Long <longman@redhat.com> Approved-by:
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6456 JIRA: https://issues.redhat.com/browse/RHEL-81268 CVE: CVE-2024-57987 ``` commit 3c15082f3567032d196e8760753373332508c2ca Author: Max Chou <max.chou@realtek.com> Date: Tue Dec 31 14:57:19 2024 +0800 Bluetooth: btrtl: check for NULL in btrtl_setup_realtek() If insert an USB dongle which chip is not maintained in ic_id_table, it will hit the NULL point accessed. Add a null point check to avoid the Kernel Oops. Fixes: b39910bb54d9 ("Bluetooth: Populate hci_set_hw_info for Intel and Realtek") Reviewed-by:
Alex Lu <alex_lu@realsil.com.cn> Signed-off-by:
Max Chou <max.chou@realtek.com> Signed-off-by:
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6348 Description: ============ This patch set updates the RDMA core and RDMA ULPs to upstream kernel v6.13. Upstream: ========= Linus's master tree. Issues: ======= JIRA: https://issues.redhat.com/browse/RHEL-77880 Brew: ===== https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=66571801 Testing: ======== https://beaker.engineering.redhat.com/jobs/10588482 https://beaker.engineering.redhat.com/jobs/10588462 https://beaker.engineering.redhat.com/jobs/10588459 https://beaker.engineering.redhat.com/jobs/10588457 https://beaker.engineering.redhat.com/jobs/10588455 https://beaker.engineering.redhat.com/jobs/10588452 Signed-off-by:
Kamal Heib <kheib@redhat.com> Approved-by:
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6442 JIRA: https://issues.redhat.com/browse/RHEL-80989 CVE: CVE-2022-49357 ``` commit 155ca952c7ca19aa32ecfb7373a32bbc2e1ec6eb Author: Aditya Garg <gargaditya08@live.com> Date: Fri Apr 15 17:02:46 2022 +0000 efi: Do not import certificates from UEFI Secure Boot for T2 Macs On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables at early boot to load UEFI Secure Boot certificates, a page fault occurs in Apple firmware code and EFI runtime services are disabled with the following logs: [Firmware Bug]: Page fault caused by firmware at PA: 0xffffb1edc0068000 WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x50/0xf0 (Removed some logs from here) Call Trace: <TASK> page_fault_oops+0x4f/0x2c0 ? search_bpf_extables+0x6b/0x80 ? search_module_extables+0x50/0x80 ? search_exception_tables+0x5b/0x60 kernelmode_fixup_or_oops+0x9e/0x110 __bad_area_nosemaphore+0x155/0x190 bad_area_nosemaphore+0x16/0x20 do_kern_addr_fault+0x8c/0xa0 exc_page_fault+0xd8/0x180 asm_exc_page_fault+0x1e/0x30 (Removed some logs from here) ? __efi_call+0x28/0x30 ? switch_mm+0x20/0x30 ? efi_call_rts+0x19a/0x8e0 ? process_one_work+0x222/0x3f0 ? worker_thread+0x4a/0x3d0 ? kthread+0x17a/0x1a0 ? process_one_work+0x3f0/0x3f0 ? set_kthread_struct+0x40/0x40 ? ret_from_fork+0x22/0x30 </TASK> ---[ end trace 1f82023595a5927f ]--- efi: Froze efi_rts_wq and disabled EFI Runtime Services integrity: Couldn't get size: 0x8000000000000015 integrity: MODSIGN: Couldn't get UEFI db list efi: EFI Runtime Services are disabled! integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get UEFI dbx list integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get mokx list integrity: Couldn't get size: 0x80000000 So we avoid reading these UEFI variables and thus prevent the crash. Cc: stable@vger.kernel.org Signed-off-by:
Aditya Garg <gargaditya08@live.com> Reviewed-by:
Mimi Zohar <zohar@linux.ibm.com> Signed-off-by:
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6505 JIRA: https://issues.redhat.com/browse/RHEL-81291 CVE: CVE-2025-21795 Signed-off-by:
Olga Kornievskaia <okorniev@redhat.com> Approved-by:
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6470 JIRA: https://issues.redhat.com/browse/RHEL-81439 CVE: CVE-2024-58012 ``` commit 569922b82ca660f8b24e705f6cf674e6b1f99cc7 Author: Bard Liao <yung-chuan.liao@linux.intel.com> Date: Tue Dec 3 18:48:53 2024 +0800 ASoC: SOF: Intel: hda-dai: Ensure DAI widget is valid during params Each cpu DAI should associate with a widget. However, the topology might not create the right number of DAI widgets for aggregated amps. And it will cause NULL pointer deference. Check that the DAI widget associated with the CPU DAI is valid to prevent NULL pointer deference due to missing DAI widgets in topologies with aggregated amps. Signed-off-by:
Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by:
Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by:
Liam Girdwood <liam.r.girdwood@intel.com> Link: https://patch.msgid.link/20241203104853.56956-1-yung-chuan.liao@linux.intel.com Signed-off-by:
Mark Brown <broonie@kernel.org>```> Signed-off-by:
Jaroslav Kysela <jkysela@redhat.com> Approved-by:
-
