summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-07-14iommu/qcom: Fix pgsize_bitmapJason Gunthorpe
qcom uses the ARM_32_LPAE_S1 format which uses the ARM long descriptor page table. Eventually arm_32_lpae_alloc_pgtable_s1() will adjust the pgsize_bitmap with: cfg->pgsize_bitmap &= (SZ_4K | SZ_2M | SZ_1G); So the current declaration is nonsensical. Fix it to be just SZ_4K which is what it has actually been using so far. Most likely the qcom driver copy and pasted the pgsize_bitmap from something using the ARM_V7S format. Fixes: db64591de4b2 ("iommu/qcom: Remove iommu_ops pgsize_bitmap") Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Closes: https://lore.kernel.org/all/CA+G9fYvif6kDDFar5ZK4Dff3XThSrhaZaJundjQYujaJW978yg@mail.gmail.com/ Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/0-v1-65a7964d2545+195-qcom_pgsize_jgg@nvidia.com Signed-off-by: Will Deacon <will@kernel.org>
2025-07-14Add RPMh regulator support for PM7550 & PMR735BMark Brown
Merge series from Luca Weiss <luca.weiss@fairphone.com>: Document and add support for the regulators on PM7550 and PMR735B, which can be paired with the Milos SoC.
2025-07-14ASoC: codec: Convert to GPIO descriptors forMark Brown
Merge series from Peng Fan <peng.fan@nxp.com>: This patchset is a pick up of patch 1,2 from [1]. And I also collect Linus's R-b for patch 2. After this patchset, there is only one user of of_gpio.h left in sound driver(pxa2xx-ac97). of_gpio.h is deprecated, update the driver to use GPIO descriptors. Patch 1 is to drop legacy platform data which in-tree no users are using it Patch 2 is to convert to GPIO descriptors Checking the DTS that use the device, all are using GPIOD_ACTIVE_LOW polarity for reset-gpios, so all should work as expected with this patch. [1] https://lore.kernel.org/all/20250408-asoc-gpio-v1-0-c0db9d3fd6e9@nxp.com/
2025-07-14iommu/vt-d: Deduplicate cache_tag_flush_all by reusing flush_rangeEthan Milon
The logic in cache_tag_flush_all() to iterate over cache tags and issue TLB invalidations is largely duplicated in cache_tag_flush_range(), with the only difference being the range parameters. Extend cache_tag_flush_range() to handle a full address space flush when called with start = 0 and end = ULONG_MAX. This allows cache_tag_flush_all() to simply delegate to cache_tag_flush_range() Signed-off-by: Ethan Milon <ethan.milon@eviden.com> Link: https://lore.kernel.org/r/20250708214821.30967-2-ethan.milon@eviden.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20250714045028.958850-12-baolu.lu@linux.intel.com Signed-off-by: Will Deacon <will@kernel.org>
2025-07-14iommu/vt-d: Fix missing PASID in dev TLB flush with cache_tag_flush_allEthan Milon
The function cache_tag_flush_all() was originally implemented with incorrect device TLB invalidation logic that does not handle PASID, in commit c4d27ffaa8eb ("iommu/vt-d: Add cache tag invalidation helpers") This causes regressions where full address space TLB invalidations occur with a PASID attached, such as during transparent hugepage unmapping in SVA configurations or when calling iommu_flush_iotlb_all(). In these cases, the device receives a TLB invalidation that lacks PASID. This incorrect logic was later extracted into cache_tag_flush_devtlb_all(), in commit 3297d047cd7f ("iommu/vt-d: Refactor IOTLB and Dev-IOTLB flush for batching") The fix replaces the call to cache_tag_flush_devtlb_all() with cache_tag_flush_devtlb_psi(), which properly handles PASID. Fixes: 4f609dbff51b ("iommu/vt-d: Use cache helpers in arch_invalidate_secondary_tlbs") Fixes: 4e589a53685c ("iommu/vt-d: Use cache_tag_flush_all() in flush_iotlb_all") Signed-off-by: Ethan Milon <ethan.milon@eviden.com> Link: https://lore.kernel.org/r/20250708214821.30967-1-ethan.milon@eviden.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20250714045028.958850-11-baolu.lu@linux.intel.com Signed-off-by: Will Deacon <will@kernel.org>
2025-07-14iommu/vt-d: Split paging_domain_compatible()Jason Gunthorpe
Make First/Second stage specific functions that follow the same pattern in intel_iommu_domain_alloc_first/second_stage() for computing EOPNOTSUPP. This makes the code easier to understand as if we couldn't create a domain with the parameters for this IOMMU instance then we certainly are not compatible with it. Check superpage support directly against the per-stage cap bits and the pgsize_bitmap. Add a note that the force_snooping is read without locking. The locking needs to cover the compatible check and the add of the device to the list. Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/7-v3-dbbe6f7e7ae3+124ffe-vtd_prep_jgg@nvidia.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20250714045028.958850-10-baolu.lu@linux.intel.com Signed-off-by: Will Deacon <will@kernel.org>
2025-07-14iommu/vt-d: Split intel_iommu_enforce_cache_coherency()Jason Gunthorpe
First Stage and Second Stage have very different ways to deny no-snoop. The first stage uses the PGSNP bit which is global per-PASID so enabling requires loading new PASID entries for all the attached devices. Second stage uses a bit per PTE, so enabling just requires telling future maps to set the bit. Since we now have two domain ops we can have two functions that can directly code their required actions instead of a bunch of logic dancing around use_first_level. Combine domain_set_force_snooping() into the new functions since they are the only caller. Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/6-v3-dbbe6f7e7ae3+124ffe-vtd_prep_jgg@nvidia.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20250714045028.958850-9-baolu.lu@linux.intel.com Signed-off-by: Will Deacon <will@kernel.org>
2025-07-14iommu/vt-d: Create unique domain ops for each stageJason Gunthorpe
Use the domain ops pointer to tell what kind of domain it is instead of the internal use_first_level indication. This also protects against wrongly using a SVA/nested/IDENTITY/BLOCKED domain type in places they should not be. The only remaining uses of use_first_level outside the paging domain are in paging_domain_compatible() and intel_iommu_enforce_cache_coherency(). Thus, remove the useless sets of use_first_level in intel_svm_domain_alloc() and intel_iommu_domain_alloc_nested(). None of the unique ops for these domain types ever reference it on their call chains. Add a WARN_ON() check in domain_context_mapping_one() as it only works with second stage. This is preparation for iommupt which will have different ops for each of the stages. Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/5-v3-dbbe6f7e7ae3+124ffe-vtd_prep_jgg@nvidia.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20250714045028.958850-8-baolu.lu@linux.intel.com Signed-off-by: Will Deacon <will@kernel.org>
2025-07-14iommu/vt-d: Split intel_iommu_domain_alloc_paging_flags()Jason Gunthorpe
Create stage specific functions that check the stage specific conditions if each stage can be supported. Have intel_iommu_domain_alloc_paging_flags() call both stages in sequence until one does not return EOPNOTSUPP and prefer to use the first stage if available and suitable for the requested flags. Move second stage only operations like nested_parent and dirty_tracking into the second stage function for clarity. Move initialization of the iommu_domain members into paging_domain_alloc(). Drop initialization of domain->owner as the callers all do it. Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/4-v3-dbbe6f7e7ae3+124ffe-vtd_prep_jgg@nvidia.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20250714045028.958850-7-baolu.lu@linux.intel.com Signed-off-by: Will Deacon <will@kernel.org>
2025-07-14iommu/vt-d: Do not wipe out the page table NID when devices detachJason Gunthorpe
The NID is used to control which NUMA node memory for the page table is allocated it from. It should be a permanent property of the page table when it was allocated and not change during attach/detach of devices. Reviewed-by: Wei Wang <wei.w.wang@intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/3-v3-dbbe6f7e7ae3+124ffe-vtd_prep_jgg@nvidia.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Fixes: 7c204426b818 ("iommu/vt-d: Add domain_alloc_paging support") Link: https://lore.kernel.org/r/20250714045028.958850-6-baolu.lu@linux.intel.com Signed-off-by: Will Deacon <will@kernel.org>
2025-07-14iommu/vt-d: Fold domain_exit() into intel_iommu_domain_free()Jason Gunthorpe
It has only one caller, no need for two functions. Correct the WARN_ON() error handling to leak the entire page table if the HW is still referencing it so we don't UAF during WARN_ON recovery. Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/2-v3-dbbe6f7e7ae3+124ffe-vtd_prep_jgg@nvidia.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20250714045028.958850-5-baolu.lu@linux.intel.com Signed-off-by: Will Deacon <will@kernel.org>
2025-07-14iommu/vt-d: Lift the __pa to domain_setup_first_level/intel_svm_set_dev_pasid()Jason Gunthorpe
Pass the phys_addr_t down through the call chain from the top instead of passing a pgd_t * KVA. This moves the __pa() into domain_setup_first_level() which is the first function to obtain the pgd from the IOMMU page table in this call chain. The SVA flow is also adjusted to get the pa of the mm->pgd. iommput will move the __pa() into iommupt code, it never shares the KVA of the page table with the driver. Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/1-v3-dbbe6f7e7ae3+124ffe-vtd_prep_jgg@nvidia.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20250714045028.958850-4-baolu.lu@linux.intel.com Signed-off-by: Will Deacon <will@kernel.org>
2025-07-14iommu/vt-d: Optimize iotlb_sync_map for non-caching/non-RWBF modesLu Baolu
The iotlb_sync_map iommu ops allows drivers to perform necessary cache flushes when new mappings are established. For the Intel iommu driver, this callback specifically serves two purposes: - To flush caches when a second-stage page table is attached to a device whose iommu is operating in caching mode (CAP_REG.CM==1). - To explicitly flush internal write buffers to ensure updates to memory- resident remapping structures are visible to hardware (CAP_REG.RWBF==1). However, in scenarios where neither caching mode nor the RWBF flag is active, the cache_tag_flush_range_np() helper, which is called in the iotlb_sync_map path, effectively becomes a no-op. Despite being a no-op, cache_tag_flush_range_np() involves iterating through all cache tags of the iommu's attached to the domain, protected by a spinlock. This unnecessary execution path introduces overhead, leading to a measurable I/O performance regression. On systems with NVMes under the same bridge, performance was observed to drop from approximately ~6150 MiB/s down to ~4985 MiB/s. Introduce a flag in the dmar_domain structure. This flag will only be set when iotlb_sync_map is required (i.e., when CM or RWBF is set). The cache_tag_flush_range_np() is called only for domains where this flag is set. This flag, once set, is immutable, given that there won't be mixed configurations in real-world scenarios where some IOMMUs in a system operate in caching mode while others do not. Theoretically, the immutability of this flag does not impact functionality. Reported-by: Ioanna Alifieraki <ioanna-maria.alifieraki@canonical.com> Closes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2115738 Link: https://lore.kernel.org/r/20250701171154.52435-1-ioanna-maria.alifieraki@canonical.com Fixes: 129dab6e1286 ("iommu/vt-d: Use cache_tag_flush_range_np() in iotlb_sync_map") Cc: stable@vger.kernel.org Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20250703031545.3378602-1-baolu.lu@linux.intel.com Link: https://lore.kernel.org/r/20250714045028.958850-3-baolu.lu@linux.intel.com Signed-off-by: Will Deacon <will@kernel.org>
2025-07-14iommu/vt-d: Remove the CONFIG_X86 wrapping from iommu init hookVineeth Pillai (Google)
iommu init hook is wrapped in CONFI_X86 and is a remnant of dmar.c when it was a common code in "drivers/pci/dmar.c". This was added in commit (9d5ce73a64be2 x86: intel-iommu: Convert detect_intel_iommu to use iommu_init hook) Now this is built only for x86. This config wrap could be removed. Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20250616131740.3499289-1-vineeth@bitbyteword.org Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20250714045028.958850-2-baolu.lu@linux.intel.com Signed-off-by: Will Deacon <will@kernel.org>
2025-07-14EDAC/synopsys: Clear the ECC counters on initShubhrajyoti Datta
Clear the ECC error and counter registers during initialization/probe to avoid reporting stale errors that may have occurred before EDAC registration. For that, unify the Zynq and ZynqMP ECC state reading paths and simplify the code. [ bp: Massage commit message. Fix an -Wsometimes-uninitialized warning as reported by Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202507141048.obUv3ZUm-lkp@intel.com ] Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250713050753.7042-1-shubhrajyoti.datta@amd.com
2025-07-14pmdomain: samsung: Fix splash-screen handover by enforcing a sync_stateUlf Hansson
It's has been reported that some Samsung platforms fails to boot with genpd's new sync_state support. Typically the problem exists for platforms where bootloaders are turning on the splash-screen and handing it over to be managed by the kernel. However, at this point, it's not clear how to correctly solve the problem. Although, to make the platforms boot again, let's add a temporary hack in the samsung power-domain provider driver, which enforces a sync_state that allows the power-domains to be reset before consumer devices starts to be attached. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/all/212a1a56-08a5-48a5-9e98-23de632168d0@samsung.com Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20250711114719.189441-1-ulf.hansson@linaro.org
2025-07-14xen: fix UAF in dmabuf_exp_from_pages()Al Viro
[dma_buf_fd() fixes; no preferences regarding the tree it goes through - up to xen folks] As soon as we'd inserted a file reference into descriptor table, another thread could close it. That's fine for the case when all we are doing is returning that descriptor to userland (it's a race, but it's a userland race and there's nothing the kernel can do about it). However, if we follow fd_install() with any kind of access to objects that would be destroyed on close (be it the struct file itself or anything destroyed by its ->release()), we have a UAF. dma_buf_fd() is a combination of reserving a descriptor and fd_install(). gntdev dmabuf_exp_from_pages() calls it and then proceeds to access the objects destroyed on close - starting with gntdev_dmabuf itself. Fix that by doing reserving descriptor before anything else and do fd_install() only when everything had been set up. Fixes: a240d6e42e28 ("xen/gntdev: Implement dma-buf export functionality") Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Acked-by: Juergen Gross <jgross@suse.com> Message-ID: <20250712050916.GY1880847@ZenIV> Signed-off-by: Juergen Gross <jgross@suse.com>
2025-07-14xen: Remove some deadcode (x)Dr. David Alan Gilbert
Remove three uncalled functions: xenbus_mkdir() was added in 2007 by commit 4bac07c993d0 ("xen: add the Xenbus sysfs and virtual device hotplug driver") but has remained unused. xen_get_runstate_snapshot() last use was removed in 2016 by commit 6ba286ad8457 ("xen: support runqueue steal time on xen") which replaces the use by the _cpu version. xen_resume_notifier_unregister() last use was removed in 2017 by commit 1914f0cd203c ("xen/acpi: upload PM state from init-domain to Xen") Remove them. Signed-off-by: "Dr. David Alan Gilbert" <linux@treblig.org> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com> Message-ID: <20250713132625.164728-1-linux@treblig.org>
2025-07-14xen-pciback: Replace scnprintf() with sysfs_emit_at()Ryan Chung
This is the third revision (v3) of this patch series. No changes since v2—only adding Reviewed-by lines. Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Ryan Chung <seokwoo.chung130@gmail.com> Signed-off-by: Juergen Gross <jgross@suse.com> Message-ID: <20250708001444.86155-1-seokwoo.chung130@gmail.com>
2025-07-14xen/xenbus: fix W=1 build warning in xenbus_va_dev_error functionPeng Jiang
This patch fixes a W=1 format-string warning reported by GCC 12.3.0 by annotating xenbus_switch_fatal() and xenbus_va_dev_error() with the __printf attribute. The attribute enables compile-time validation of printf-style format strings in these functions. The original warning trace: drivers/xen/xenbus/xenbus_client.c:304:9: warning: function 'xenbus_va_dev_error' might be a candidate for 'gnu_printf' format attribute [-Wsuggest-attribute=format] Signed-off-by: Peng Jiang <jiang.peng9@zte.com.cn> Reviewed-by: Juergen Gross <jgross@suse.com> Message-ID: <20250620084104786r5xoR16_AmYZMJLnno3_Q@zte.com.cn> Signed-off-by: Juergen Gross <jgross@suse.com>
2025-07-14ata: pata_rdc: Use registered definition for the RDC vendorAndy Shevchenko
Convert to PCI_VDEVICE() and use registered definition for RDC vendor from pci_ids.h. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Link: https://lore.kernel.org/r/20250711113650.1475307-1-andriy.shevchenko@linux.intel.com [cassel: add ata: prefix to subject, fix typo in Damien's Rb tag] Signed-off-by: Niklas Cassel <cassel@kernel.org>
2025-07-14clk: sunxi-ng: ccu_nm: convert from round_rate() to determine_rate()Brian Masney
The round_rate() clk ops is deprecated, so migrate this driver from round_rate() to determine_rate() using the Coccinelle semantic patch on the cover letter of this series. I manually fixed up one minor formatting issue that occurred after applying the semantic patch: req->rate = ccu_nm_find_best(&nm->common, req->best_parent_rate, req->rate, &_nm); I manually changed it to: req->rate = ccu_nm_find_best(&nm->common, req->best_parent_rate, req->rate, &_nm); Signed-off-by: Brian Masney <bmasney@redhat.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20250703-clk-cocci-drop-round-rate-v1-10-3a8da898367e@redhat.com Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-07-14clk: sunxi-ng: ccu_nkmp: convert from round_rate() to determine_rate()Brian Masney
The round_rate() clk ops is deprecated, so migrate this driver from round_rate() to determine_rate() using the Coccinelle semantic patch on the cover letter of this series. Signed-off-by: Brian Masney <bmasney@redhat.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20250703-clk-cocci-drop-round-rate-v1-9-3a8da898367e@redhat.com Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-07-14clk: sunxi-ng: ccu_nk: convert from round_rate() to determine_rate()Brian Masney
The round_rate() clk ops is deprecated, so migrate this driver from round_rate() to determine_rate() using the Coccinelle semantic patch on the cover letter of this series. Signed-off-by: Brian Masney <bmasney@redhat.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20250703-clk-cocci-drop-round-rate-v1-8-3a8da898367e@redhat.com Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-07-14clk: sunxi-ng: ccu_gate: convert from round_rate() to determine_rate()Brian Masney
The round_rate() clk ops is deprecated, so migrate this driver from round_rate() to determine_rate() using the Coccinelle semantic patch on the cover letter of this series. Signed-off-by: Brian Masney <bmasney@redhat.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20250703-clk-cocci-drop-round-rate-v1-7-3a8da898367e@redhat.com Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-07-14clk: sunxi-ng: v3s: Assign the de and tcon clocks to the video pllPaul Kocialkowski
It appears (based on experimentation) that both the de and tcon clocks need to have the same parent for the two units to work together. Assign them both to the video pll by manually clearing the parent selection bits (effectively setting index 0) and marking the clocks with the CLK_SET_RATE_NO_REPARENT flag, which ensures that they will never use a different parent. The video pll is also a possible parent for the camera subsystem, but it can use the dedicated isp pll if needed so there should be no negative side-effect due to this change. Note that ccu_mux_helper_set_parent cannot be used at this stage as it requires the clock driver to be initialized and this configuration is best done before the clock driver is available to consumers. Signed-off-by: Paul Kocialkowski <paulk@sys-base.io> Link: https://patch.msgid.link/20250704154008.3463257-2-paulk@sys-base.io Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-07-14clk: sunxi-ng: v3s: Fix de clock definitionPaul Kocialkowski
The de clock is marked with CLK_SET_RATE_PARENT, which is really not necessary (as confirmed from experimentation) and significantly restricts flexibility for other clocks using the same parent. In addition the source selection (parent) field is marked as using 2 bits, when it the documentation reports that it uses 3. Fix both issues in the de clock definition. Fixes: d0f11d14b0bc ("clk: sunxi-ng: add support for V3s CCU") Signed-off-by: Paul Kocialkowski <paulk@sys-base.io> Link: https://patch.msgid.link/20250704154008.3463257-1-paulk@sys-base.io Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-07-14drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2Ankit Nautiyal
Some ICL/TGL platforms with combo PHY ports suffer from signal integrity issues at HBR3. While certain systems include a Parade PS8461 mux to mitigate this, its presence cannot be reliably detected. Furthermore, broken or missing VBT entries make it unsafe to rely on VBT for enforcing link rate limits. To address this introduce a device specific quirk to cap the eDP link rate to HBR2 (540000 kHz). This will override any higher advertised rates from the sink or DPCD for specific devices. Currently, the quirk is added for Dell XPS 13 7390 2-in-1 which is reported in gitlab issue #5969 [1]. [1] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969 v2: Align the quirk with the intended quirk name and refactor the condition to use min(). (Jani) v3: Use condition `rate > 540000`. Drop extra parentheses. (Ville) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://lore.kernel.org/r/20250710052041.1238567-3-ankit.k.nautiyal@intel.com
2025-07-14Revert "drm/i915/dp: Reject HBR3 when sink doesn't support TPS4"Ankit Nautiyal
This reverts commit 584cf613c24a4250d9be4819efc841aa2624d5b6. Commit 584cf613c24a ("drm/i915/dp: Reject HBR3 when sink doesn't support TPS4") introduced a blanket rejection of HBR3 link rate when the sink does not support TPS4. While this was intended to address instability observed on certain eDP panels [1], there seem to be edp panels that do not follow the specification. These eDP panels do not advertise TPS4 support, but require HBR3 to operate at their fixed native resolution [2]. As a result, the change causes blank screens on such panels. Apparently, Windows driver does not enforce this restriction, and the issue is not seen there. Therefore, revert the commit to restore functionality for such panels, and align behaviour with Windows driver. [1] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969 [2] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14517 v2: Update the commit message with better justification. (Ville) Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14517 Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://lore.kernel.org/r/20250710052041.1238567-2-ankit.k.nautiyal@intel.com
2025-07-13mm/balloon_compaction: convert balloon_page_delete() to balloon_page_finalize()David Hildenbrand
Let's move the removal of the page from the balloon list into the single caller, to remove the dependency on the PG_isolated flag and clarify locking requirements. Note that for now, balloon_page_delete() was used on two paths: (1) Removing a page from the balloon for deflation through balloon_page_list_dequeue() (2) Removing an isolated page from the balloon for migration in the per-driver migration handlers. Isolated pages were already removed from the balloon list during isolation. So instead of relying on the flag, we can just distinguish both cases directly and handle it accordingly in the caller. We'll shuffle the operations a bit such that they logically make more sense (e.g., remove from the list before clearing flags). In balloon migration functions we can now move the balloon_page_finalize() out of the balloon lock and perform the finalization just before dropping the balloon reference. Document that the page lock is currently required when modifying the movability aspects of a page; hopefully we can soon decouple this from the page lock. Link: https://lkml.kernel.org/r/20250704102524.326966-3-david@redhat.com Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: Alistair Popple <apopple@nvidia.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Brendan Jackman <jackmanb@google.com> Cc: Byungchul Park <byungchul@sk.com> Cc: Chengming Zhou <chengming.zhou@linux.dev> Cc: Christian Brauner <brauner@kernel.org> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Eugenio Pé rez <eperezma@redhat.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Gregory Price <gourry@gourry.net> Cc: Harry Yoo <harry.yoo@oracle.com> Cc: "Huang, Ying" <ying.huang@linux.alibaba.com> Cc: Jan Kara <jack@suse.cz> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Jason Wang <jasowang@redhat.com> Cc: Jerrin Shaji George <jerrin.shaji-george@broadcom.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Joshua Hahn <joshua.hahnjy@gmail.com> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Madhavan Srinivasan <maddy@linux.ibm.com> Cc: Mathew Brost <matthew.brost@intel.com> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Miaohe Lin <linmiaohe@huawei.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Minchan Kim <minchan@kernel.org> Cc: Naoya Horiguchi <nao.horiguchi@gmail.com> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Peter Xu <peterx@redhat.com> Cc: Qi Zheng <zhengqi.arch@bytedance.com> Cc: Rakie Kim <rakie.kim@sk.com> Cc: Rik van Riel <riel@surriel.com> Cc: Sergey Senozhatsky <senozhatsky@chromium.org> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com> Cc: xu xin <xu.xin16@zte.com.cn> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-07-13mm/page_isolation: remove migratetype parameter from more functionsZi Yan
migratetype is no longer overwritten during pageblock isolation, start_isolate_page_range(), has_unmovable_pages(), and set_migratetype_isolate() no longer need which migratetype to restore during isolation failure. For has_unmoable_pages(), it needs to know if the isolation is for CMA allocation, so adding PB_ISOLATE_MODE_CMA_ALLOC provide the information. At the same time change isolation flags to enum pb_isolate_mode (PB_ISOLATE_MODE_MEM_OFFLINE, PB_ISOLATE_MODE_CMA_ALLOC, PB_ISOLATE_MODE_OTHER). Remove REPORT_FAILURE and check PB_ISOLATE_MODE_MEM_OFFLINE, since only PB_ISOLATE_MODE_MEM_OFFLINE reports isolation failures. alloc_contig_range() no longer needs migratetype. Replace it with a newly defined acr_flags_t to tell if an allocation is for CMA. So does __alloc_contig_migrate_range(). Add ACR_FLAGS_NONE (set to 0) to indicate ordinary allocations. Link: https://lkml.kernel.org/r/20250617021115.2331563-7-ziy@nvidia.com Signed-off-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: David Hildenbrand <david@redhat.com> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Brendan Jackman <jackmanb@google.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Kirill A. Shuemov <kirill.shutemov@linux.intel.com> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Michal Hocko <mhocko@suse.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Richard Chang <richardycc@google.com> Cc: Suren Baghdasaryan <surenb@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-07-13drivers,hmat: use node-notifier instead of memory-notifierOscar Salvador
hmat driver is only concerned when a numa node changes its memory state, specifically when a numa node with memory comes into play for the first time, because it will register the memory_targets belonging to that numa node. So stop using the memory notifier and use the new numa node notifer instead. Link: https://lkml.kernel.org/r/20250616135158.450136-8-osalvador@suse.de Signed-off-by: Oscar Salvador <osalvador@suse.de> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Harry Yoo <harry.yoo@oracle.com> Reviewed-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: David Hildenbrand <david@redhat.com> Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: Rakie Kim <rakie.kim@sk.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-07-13drivers,cxl: use node-notifier instead of memory-notifierOscar Salvador
memory-tier is only concerned when a numa node changes its memory state, specifically when a numa node with memory comes into play for the first time, because it needs to get its performance attributes to build a proper demotion chain. So stop using the memory notifier and use the new numa node notifer instead. Link: https://lkml.kernel.org/r/20250616135158.450136-7-osalvador@suse.de Signed-off-by: Oscar Salvador <osalvador@suse.de> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Harry Yoo <harry.yoo@oracle.com> Reviewed-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: David Hildenbrand <david@redhat.com> Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: Rakie Kim <rakie.kim@sk.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-07-13mm,memory_hotplug: implement numa node notifierOscar Salvador
There are at least six consumers of hotplug_memory_notifier that what they really are interested in is whether any numa node changed its state, e.g: going from having memory to not having memory and vice versa. Implement a specific notifier for numa nodes when their state gets changed, which will later be used by those consumers that are only interested in numa node state changes. Add documentation as well. [dan.carpenter@linaro.org: set failure reason in offline_pages()] Link: https://lkml.kernel.org/r/be4fd31b-7d09-46b0-8329-6d0464ffa7a5@sabinyo.mountain Link: https://lkml.kernel.org/r/20250616135158.450136-4-osalvador@suse.de Signed-off-by: Oscar Salvador <osalvador@suse.de> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Harry Yoo <harry.yoo@oracle.com> Reviewed-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: David Hildenbrand <david@redhat.com> Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: Rakie Kim <rakie.kim@sk.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-07-13regulator: qcom-rpmh: add support for pm7550 regulatorsLuca Weiss
Add RPMH regulators exposed by Qualcomm Technologies, Inc. PM7550 PMIC. It has 6 FTS525 (FT-SMPS) and 23 LDOs with 3 different types. L1-L11 are LDO515 LV NMOS, L12-L13 are LDO515 MV PMOS, L14-L23 are LDO512 MV PMOS. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Link: https://patch.msgid.link/20250711-pm7550-pmr735b-rpmh-regs-v2-4-bca8cc15c199@fairphone.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-07-13regulator: qcom-rpmh: add support for pmr735b regulatorsLuca Weiss
Add RPMH regulators exposed by Qualcomm Technologies, Inc. PMR735B PMIC. It has 12 LDOs with 2 different types, L4 & L10 are LDO512 LV PMOS and the rest are LDO512 NMOS. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Link: https://patch.msgid.link/20250711-pm7550-pmr735b-rpmh-regs-v2-3-bca8cc15c199@fairphone.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-07-13net: dsa: mt7530: Constify struct regmap_configChristophe JAILLET
'struct regmap_config' are not modified in these drivers. They be statically defined instead of allocated and populated at run-time. The main benefits are: - it saves some memory at runtime - the structures can be declared as 'const', which is always better for structures that hold some function pointers - the code is less verbose Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2025-07-13clk: thead: th1520-ap: Correctly refer the parent of osc_12mYao Zi
The "osc_12m" fixed factor clock refers the external oscillator by setting clk_parent_data.fw_name to osc_24m, which is obviously wrong since no clock-names property is allowed for compatible thead,th1520-clk-ap. Refer the oscillator as parent by index instead. Fixes: ae81b69fd2b1 ("clk: thead: Add support for T-Head TH1520 AP_SUBSYS clocks") Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Drew Fustini <fustini@kernel.org> Signed-off-by: Drew Fustini <fustini@kernel.org>
2025-07-13Merge tag 'clk-fixes-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Fixes for a few clk drivers and bindings: - Add a missing property to the Mediatek MT8188 clk binding to keep binding checks happy - Avoid an OOB by setting the correct number of parents in dispmix_csr_clk_dev_data - Allocate clk_hw structs early in probe to avoid an ordering issue where clk_parent_data points to an unallocated clk_hw when the child clk is registered before the parent clk in the SCMI clk driver * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: dt-bindings: clock: mediatek: Add #reset-cells property for MT8188 clk: imx: Fix an out-of-bounds access in dispmix_csr_clk_dev_data clk: scmi: Handle case where child clocks are initialized before their parents
2025-07-13block: floppy: Fix uninitialized use of outparamPurva Yeshi
Fix Smatch-detected error: drivers/block/floppy.c:3569 fd_locked_ioctl() error: uninitialized symbol 'outparam'. Smatch may incorrectly warn about uninitialized use of 'outparam' in fd_locked_ioctl(), even though all _IOC_READ commands guarantee its initialization. Initialize outparam to NULL to make this explicit and suppress the false positive. Signed-off-by: Purva Yeshi <purvayeshi550@gmail.com> Reviewed-by: Denis Efremov <efremov@linux.com> Link: https://lore.kernel.org/r/20250713070020.14530-1-purvayeshi550@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-07-13Merge tag 'irq_urgent_for_v6.16_rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fixes from Borislav Petkov: - Fix a case of recursive locking in the MSI code - Fix a randconfig build failure in armada-370-xp irqchip * tag 'irq_urgent_for_v6.16_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/irq-msi-lib: Fix build with PCI disabled PCI/MSI: Prevent recursive locking in pci_msix_write_tph_tag()
2025-07-13thermal/drivers/qcom-spmi-temp-alarm: Add support for LITE PMIC peripheralsAnjelique Melendez
Add support for TEMP_ALARM LITE PMIC peripherals. This subtype utilizes a pair of registers to configure a warning interrupt threshold temperature and an automatic hardware shutdown threshold temperature. Co-developed-by: David Collins <david.collins@oss.qualcomm.com> Signed-off-by: David Collins <david.collins@oss.qualcomm.com> Signed-off-by: Anjelique Melendez <anjelique.melendez@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250710224555.3047790-6-anjelique.melendez@oss.qualcomm.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-07-13thermal/drivers/qcom-spmi-temp-alarm: Add support for GEN2 rev 2 PMIC ↵Anjelique Melendez
peripherals Add support for TEMP_ALARM GEN2 PMIC peripherals with digital major revision 2. This revision utilizes individual temp DAC registers to set the threshold temperature for over-temperature stages 1 (warning), 2 (system shutdown), and 3 (emergency shutdown) instead of a single register to specify a set of thresholds. Co-developed-by: David Collins <david.collins@oss.qualcomm.com> Signed-off-by: David Collins <david.collins@oss.qualcomm.com> Signed-off-by: Anjelique Melendez <anjelique.melendez@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250710224555.3047790-5-anjelique.melendez@oss.qualcomm.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-07-13thermal/drivers/qcom-spmi-temp-alarm: Prepare to support additional Temp ↵Anjelique Melendez
Alarm subtypes In preparation to support newer temp alarm subtypes, add the "ops", "sync_thresholds" and "configure_trip_temps" references to spmi_temp_alarm_data. This will allow for each Temp Alarm subtype to define its own thermal_zone_device_ops and properly initialize and configure thermal trip temperature. Signed-off-by: Anjelique Melendez <anjelique.melendez@oss.qualcomm.com> Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250710224555.3047790-4-anjelique.melendez@oss.qualcomm.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-07-13thermal/drivers/qcom-spmi-temp-alarm: Add temp alarm data struct based on HW ↵Anjelique Melendez
subtype Currently multiple if/else statements are used in functions to decipher between SPMI temp alarm Gen 1, Gen 2 and Gen 2 Rev 1 functionality. Instead refactor the driver so that SPMI temp alarm chips will have reference to a spmi_temp_alarm_data struct which defines data and function callbacks based on the HW subtype. Signed-off-by: Anjelique Melendez <anjelique.melendez@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20250710224555.3047790-3-anjelique.melendez@oss.qualcomm.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-07-13thermal/drivers/qcom-spmi-temp-alarm: Enable stage 2 shutdown when requiredDavid Collins
Certain TEMP_ALARM GEN2 PMIC peripherals need over-temperature stage 2 automatic PMIC partial shutdown. This will ensure that in the event of reaching the hotter stage 3 over-temperature threshold, repeated faults will be avoided during the automatic PMIC hardware full shutdown. Modify the stage 2 shutdown control logic to ensure that stage 2 shutdown is enabled on all affected PMICs. Read the digital major and minor revision registers to identify these PMICs. Signed-off-by: David Collins <david.collins@oss.qualcomm.com> Signed-off-by: Anjelique Melendez <anjelique.melendez@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250710224555.3047790-2-anjelique.melendez@oss.qualcomm.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-07-13nvmem: imx-ocotp: fix MAC address byte lengthSteffen Bätz
The commit "13bcd440f2ff nvmem: core: verify cell's raw_len" caused an extension of the "mac-address" cell from 6 to 8 bytes due to word_size of 4 bytes. This led to a required byte swap of the full buffer length, which caused truncation of the mac-address when read. Previously, the mac-address was incorrectly truncated from 70:B3:D5:14:E9:0E to 00:00:70:B3:D5:14. Fix the issue by swapping only the first 6 bytes to correctly pass the mac-address to the upper layers. Fixes: 13bcd440f2ff ("nvmem: core: verify cell's raw_len") Cc: stable@vger.kernel.org Signed-off-by: Steffen Bätz <steffen@innosonix.de> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Srinivas Kandagatla <srini@kernel.org> Link: https://lore.kernel.org/r/20250712181729.6495-3-srini@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-13usb: dwc2: gadget: Fix enter to hibernation for UTMI+ PHYMinas Harutyunyan
For UTMI+ PHY, according to programming guide, first should be set PMUACTV bit then STOPPCLK bit. Otherwise, when the device issues Remote Wakeup, then host notices disconnect instead. For ULPI PHY, above mentioned bits must be set in reversed order: STOPPCLK then PMUACTV. Fixes: 4483ef3c1685 ("usb: dwc2: Add hibernation updates for ULPI PHY") Cc: stable <stable@kernel.org> Signed-off-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com> Link: https://lore.kernel.org/r/692110d3c3d9bb2a91cedf24528a7710adc55452.1751881374.git.Minas.Harutyunyan@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-13usb: dwc3: qcom: Don't leave BCR assertedKrishna Kurapati
Leaving the USB BCR asserted prevents the associated GDSC to turn on. This blocks any subsequent attempts of probing the device, e.g. after a probe deferral, with the following showing in the log: [ 1.332226] usb30_prim_gdsc status stuck at 'off' Leave the BCR deasserted when exiting the driver to avoid this issue. Cc: stable <stable@kernel.org> Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver") Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250709132900.3408752-1-krishna.kurapati@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-13iio: accel: adxl313: add AC coupled activity/inactivity eventsLothar Rubusch
Introduce AC-coupled activity and inactivity as MAG_ADAPTIVE events. This adds a new set of threshold and duration configuration options, ensures proper handling of event disabling, and extends the use of the link bit to support complementary event configurations. For example, either ACTIVITY or ACTIVITY_AC can be enabled, but only the most recently set configuration will remain active. Disabling ACTIVITY will have no effect if ACTIVITY_AC is currently enabled, as the event types must match (i.e., ACTIVITY_AC must be explicitly disabled). When either INACTIVITY or INACTIVITY_AC is enabled alongside an activity event, the link bit is set. With the link bit and auto-sleep enabled, activity and inactivity events represent changes in the sensor's power-saving state and are only triggered upon actual state transitions. Since AC coupling uses separate bits for activity and inactivity, each can be configured independently. For instance, ACTIVITY can be linked with INACTIVITY_AC. If one of the linked events is disabled, the link bit is cleared. In that case, the remaining event will no longer reflect a state transition but will instead trigger based on periodic inactivity or whenever the activity threshold is exceeded. Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20250702230819.19353-8-l.rubusch@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>