summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-07-09net: macb: drop in-flight Tx SKBs on closeThéo Lebrun
The MACB driver has since forever leaked the outgoing SKBs that have not yet been marked as completed. They live in queue->tx_skb which gets freed without remorse nor checking. macb_free_consistent() gets called in a few codepaths, but only close will trigger the added expressions. In macb_open() and macb_alloc_consistent() failure cases, queues' tx_skb just got allocated and are empty. Fixes: 89e5785fc8a6 ("[PATCH] Atmel MACB ethernet driver") Cc: stable@vger.kernel.org Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Link: https://patch.msgid.link/20260702-macb-drop-tx-v4-1-1c833eebdbc8@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-09net: mana: Sync page pool RX frags for CPUDexuan Cui
MANA allocates RX buffers from page pool fragments when frag_count is greater than 1. In that case the buffers remain DMA mapped by page pool and the RX completion path does not call dma_unmap_single(). As a result, the implicit sync-for-CPU normally performed by dma_unmap_single() is missing before the packet data is passed to the networking stack. This breaks RX on configurations which require explicit DMA syncing, for example when booted with swiotlb=force. Fix this by recording the page pool page and DMA sync offset when the RX buffer is allocated, and syncing the received packet range for CPU access before handing the RX buffer to the stack. Fixes: 730ff06d3f5c ("net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.") Cc: stable@vger.kernel.org Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: Dexuan Cui <decui@microsoft.com> Link: https://patch.msgid.link/20260702041237.617719-3-decui@microsoft.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-09net: mana: Validate the packet length reported by the NICDexuan Cui
Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted. Cc: stable@vger.kernel.org Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: Dexuan Cui <decui@microsoft.com> Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Link: https://patch.msgid.link/20260702041237.617719-2-decui@microsoft.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-09iommu/amd: Dynamically verify Southbridge IOAPIC via PCI config spaceWei Wang
check_ioapic_information() verifies whether the BIOS has provided a valid device ID for the Southbridge (SB) IOAPIC in the IVRS table. Currently, if the SB IOAPIC entry in the IVRS table does not match a historically hardcoded device ID (00:14.0), interrupt remapping is forcibly disabled. This hardcoded expectation does not scale to newer architectures. For example, recent Hygon Gen 4 servers use 00:0b.0 for the SB IOAPIC, which originally caused the validation to fail and interrupt remapping to be disabled until this device ID was added upstream. Instead of maintaining per-vendor/per-generation hardcoded device IDs, dynamically verify the SB IOAPIC by reading its PCI configuration space. Because the SB IOAPIC is embedded within the FCH (Fusion Controller Hub) and shares its device ID, we can inspect the PCI class code of the given device ID to confirm it is an actual FCH device (a SMBus controller or ISA Bridge). Signed-off-by: Wei Wang <wei.w.wang@hotmail.com> Tested-by: Yongwei Xu <xuyongwei@open-hieco.net> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-07-09iommu/amd: Fix false positive in SB IOAPIC IVRS validationWei Wang
The check_ioapic_information() function is designed to prevent boot hangs by ensuring the Southbridge (SB) IOAPIC is properly mapped in the IVRS table before enabling Interrupt Remapping. Currently, this check passes if *any* enumerated IOAPIC matches the expected SB IOAPIC device ID. If a buggy BIOS incorrectly assigns the SB IOAPIC's device ID to a secondary IOAPIC in the IVRS, while scrambling the true SB IOAPIC's mapping, the check hits a false positive and succeeds. This erroneously enables Interrupt Remapping. Consequently, the IOMMU blocks unmapped interrupts from the actual SB IOAPIC, dropping the system timer and leading to a silent kernel boot hang. Tighten the validation to verify the device ID specifically against the SB IOAPIC by matching their APIC IDs first. This prevents the validation check from being bypassed via device ID aliasing. Fixes: c2ff5cf5294b ("iommu/amd: Work around wrong IOAPIC device-id in IVRS table") Signed-off-by: Wei Wang <wei.w.wang@hotmail.com> Tested-by: Yongwei Xu <xuyongwei@open-hieco.net> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-07-09iommu/amd: Prevent SB IOAPIC from overriding IVRS validation errorsWei Wang
The check_ioapic_information() function validates IOAPICs against the IVRS table to safely disable Interrupt Remapping (IR) if the BIOS provides a broken topology. Currently, the validation loop contains a bug: If an unmapped secondary IOAPIC is encountered, 'ret' is set to false. But if the Southbridge (SB) IOAPIC is enumerated after it in the MADT, the loop overwrites 'ret' to true. This bypasses the validation failure and leaves IR enabled. When devices attached to the unmapped secondary IOAPIC fire interrupts, the IOMMU drops them due to the missing Requestor ID, leading to localized device hangs. Fix this by initializing 'ret' to true and only toggling it to false upon encountering a validation error, ensuring failures are never erased. Fixes: c2ff5cf5294b ("iommu/amd: Work around wrong IOAPIC device-id in IVRS table") Signed-off-by: Wei Wang <wei.w.wang@hotmail.com> Tested-by: Yongwei Xu <xuyongwei@open-hieco.net> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-07-09iommu/msm: Return -ENOMEM on memory allocation failure in probeVladimir Zapolskiy
If dynamic memory allocation in driver's probe function execution fails, it should be reported to the driver's framework with -ENOMEM error code. Fixes: 109bd48ea2e1 ("iommu/msm: Add DT adaptation") Signed-off-by: Vladimir Zapolskiy <vz@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-07-09iommu/mediatek-v1: Fix off-by-one in MT2701_LARB_NR_MAXAkari Tsuyukusa
The mt2701_m4u_in_larb[] array contains 4 (for LARB0 to LARB3) elements, meaning mt2701_m4u_to_larb() can legitimately return 3. The current check `if (larbid >= MT2701_LARB_NR_MAX)` incorrectly rejects valid LARB3 with -EINVAL. Fix this off-by-one error by updating MT2701_LARB_NR_MAX to 4. Note that this does not cause immediate issues with the current mt2701.dtsi and mt7623n.dtsi because it only defines 3 LARBs: mediatek,larbs = <&larb0 &larb1 &larb2>; Thus, larbid never reaches 3 in the existing upstream device tree. Fixes: de78657e16f4 ("iommu/mediatek: Fix NULL pointer dereference when printing dev_name") Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-07-09iommu/vt-d: Fail probe on ATS configuration failurePranjal Shrivastava
Update the Intel VT-d driver to handle ATS configuration and enablement more strictly. Specifically, update the device probe to fail if pci_prepare_ats() returns an error. This ensures that any ATS-capable master reaching the attach phase is guaranteed to have a valid config. Additionally, update iommu_enable_pci_ats() to WARN() if pci_enable_ats fails. Since earlier checks in the probe phase preclude config-related failures, any failure during hardware enablement is considered a kernel bug. Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Samiullah Khawaja <skhawaja@google.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Pranjal Shrivastava <praan@google.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-07-09iommu/arm-smmu-v3: Standardize ATS enablement failure reportingPranjal Shrivastava
Update arm_smmu_enable_ats() to wrap the pci_enable_ats() call in a WARN(). Since probe-time checks now preclude configuration errors any failure during hardware enablement is considered a kernel bug. Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Samiullah Khawaja <skhawaja@google.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Pranjal Shrivastava <praan@google.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-07-09PCI/ATS: Validate STU for VFs in pci_prepare_ats()Pranjal Shrivastava
While every PCI Function that implements ATS has an independent ATS Extended Capability structure with a Read/Write Smallest Translation Unit (STU) field, the kernel manages SR-IOV ATS by requiring the IOMMU driver to configure the STU on the Physical Function (PF) before any any Virtual Functions (VFs) are created. Currently, pci_prepare_ats() bails out early for VFs, assuming that the PF has already been correctly prepared. However, this creates a potential mismatch if a VF is subsequently prepared with a different page shift. Update pci_prepare_ats() to validate that the requested page shift (ps) matches the STU already configured in the associated PF. This ensures early detection of incompatible configurations and maintains the kernel's policy of consistent STU sizing across all functions associated with a given SMMU. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Samiullah Khawaja <skhawaja@google.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Pranjal Shrivastava <praan@google.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-07-09PCI/ATS: Ensure pci_ats_supported() is PF-aware for VFsPranjal Shrivastava
Update pci_ats_supported() to additionally check the associated PF's status when called on a VF. This ensures that PF-level quirks and untrusted status are correctly propagated to VFs, providing a robust support check that aligns with the kernel's PF-centric ATS configuration model and is immune to the timing of VF-specific fixups. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Samiullah Khawaja <skhawaja@google.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Pranjal Shrivastava <praan@google.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-07-09iommu/riscv: Drop superfluous zeros in pci_device_id arrayUwe Kleine-König (The Capable Hub)
The .driver_data member of the struct pci_device_id array were initialized by a list expressions to zero without making use of that value. In this case it's better to not specify a value at all and let the compiler fill in the zeros. Same for the list terminator that can better be completely empty. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-07-09drm/i915/kunit: DP link: add fallback testsImre Deak
Add KUnit tests for DP link fallback selection across eDP, SST, and MST. Verify that the fallback logic properly selects the maximum allowed configuration, iterates through allowed configurations, and disables failed configs as expected. These tests include UHBR vs. non-UHBR conditions, MST vs. SST mode, and validate that subsequent fallback selections respect the updated allowed configuration mask. v2: - Rebase on changes using a filter object instead of a mask of configuration indices. - Rebase on changes using an iteration object. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-35-imre.deak@intel.com
2026-07-09drm/i915/kunit: DP link: add update config testsImre Deak
Add KUnit tests for link_caps updates shrinking or expanding the supported rates and lane counts. The tests also cover updates with disabled configurations, including random shrink and expand sequences, to verify that disabled state, allowed configurations, ordering, and max limits stay consistent across updates. v2: Remove test cases for the now unused merge update mode. v3: - Test config iteration in lane count, rate order as well. - Keep space after comma in code comment. (Michał) Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> # v2 Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260707124849.135319-4-imre.deak@intel.com
2026-07-09drm/i915/kunit: DP link: add baseline fixed table reference testImre Deak
Add a simple baseline test for DP link caps iteration using a fixed standard DP configuration table. This provides a minimal validity check, independent of more complex test setups, verifying the iterator returns expected configurations in ascending and descending order. v2: Unchanged. v3: Test config iteration in lane count, rate order as well. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> # v2 Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260707124849.135319-3-imre.deak@intel.com
2026-07-09drm/i915/kunit: Export link training and caps funcs for testingImre Deak
Export the link caps and link training helpers needed by the DP link KUnit tests. Use test ops tables instead of exporting the helpers directly, avoiding symbol name collisions between the i915 and xe builds of the shared display code. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-32-imre.deak@intel.com
2026-07-09drm/i915/kunit: Setup DP link test contextImre Deak
Initialize a reusable test context for DP link KUnit tests. Sets up minimal device, connector, encoder, and DP structures, and seeds the pseudo-random generator for deterministic test runs. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-31-imre.deak@intel.com
2026-07-09drm/xe/kunit: Build DP link display testsImre Deak
Hook the shared i915 display DP link KUnit tests into the xe display test build. Build the shared display test source from the i915 display test directory when xe display support is enabled. v2: Unchanged. v3: Add SPDX license header. (Michał) Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260707124849.135319-2-imre.deak@intel.com
2026-07-09drm/xe/kunit: Add display test configImre Deak
Add a separate xe KUnit config for display tests. The existing xe .kunitconfig builds xe statically, which is suitable for non-display xe tests. The display code can only be enabled for xe when xe is built as a module, so add a separate display config with DRM_XE=m and DRM_XE_DISPLAY=y. This can be folded back into the main xe KUnit config once the display code becomes a separate module. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-29-imre.deak@intel.com
2026-07-09drm/i915/kunit: Add DP link test stubImre Deak
Add a Kunit stub test module for DP link test cases. v2: Add missing module license. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-28-imre.deak@intel.com
2026-07-09drm/i915/kunit: Enable KUnit testsImre Deak
Add KUnit configuration for i915 and a local .kunitconfig to run the tests. v2: Unchanged. v3: Remove kconfig options for kernel debug. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> # v2 Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260707124849.135319-1-imre.deak@intel.com
2026-07-09drm/i915/dp_link_training: Disable failed config during fallbackImre Deak
Disable the link configuration that failed training when selecting fallback parameters. Fallback still selects the next configuration using the existing fallback order, but now also removes the failed configuration from the allowed set. Functionally, this only affects the case where an MST <-> SST mode switch occurs on the same root connector: previously, a configuration that failed training in one mode could be reused in the other mode due to the differing config iteration orders. The current fallback logic also sets a temporary maximum link limit across the allowed configurations to constrain subsequent modesets. This legacy behavior is preserved for now; it will be removed once the fallback logic relies solely on the individually disabled configurations to restrict the allowed set. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-26-imre.deak@intel.com
2026-07-09drm/i915/dp_link_training: Use config iterator for fallbackImre Deak
Switch the fallback loop to use the link configuration iterator to select a fallback configuration. This also allows unexporting and removing from the link caps interface all the common link rate query helpers and the helpers that accept or return a link configuration index. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-25-imre.deak@intel.com
2026-07-09drm/i915/dp_link_training: Reset the max link limits in the fallback codeImre Deak
The target maximum rate/lane count selected by the fallback logic may exceed the current link_caps max_limits' rate/lane count, the latter of which are used as a limit by the lookup functions when filtering allowed configurations. To ensure the fallback search finds all relevant candidates, temporarily reset the link_caps max_limits to the maximum common supported capabilities. After the fallback search completes, set the link_caps max_limits to the configuration selected by the fallback logic, as before, determining the allowed configurations for a subsequent modeset. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-24-imre.deak@intel.com
2026-07-09drm/i915/dp: Remove min/max link config limitsImre Deak
Remove the min/max rate and lane count fields from struct link_config_limits after all state computation is converted to use the configuration filter. A simple min/max range cannot fully describe the valid configuration set once individual configurations are disabled (for example by fallback), as it may allow combinations that are not actually valid. The configuration filter, on the other hand, always represents a consistent set of valid configurations. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-23-imre.deak@intel.com
2026-07-09drm/i915/dp_mst: Use link caps for MST DSC config selectionImre Deak
Use the link caps helper to select the maximum DP MST link configuration for DSC computation, instead of using the separate max rate and lane count limits, which may not form a valid configuration after individual configs are disabled by fallback. Also look up the maximum rate for state computation via the configuration mask when checking the DSC hblank expansion quirk. This is a step towards unifying configuration selection and iteration across connector types and between compute and fallback paths. The state computation should likely consider all allowed configurations, as noted in the code comment; for now keep the existing DP MST DSC behavior of selecting the maximum BW configuration determined by the MST connector BW config iteration order. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-22-imre.deak@intel.com
2026-07-09drm/i915/dp_mst: Use link caps for non-DSC config selectionImre Deak
Use the link caps helper to select the maximum MST link configuration for non-DSC computation, instead of using the separate max rate and lane count limits, which may not form a valid configuration after individual configs are disabled by fallback. This is a step towards unifying configuration selection and iteration across connector types and between compute and fallback paths. In some cases all configurations should be considered, as noted in the code comment; for now keep the existing behavior of selecting the maximum bandwidth configuration as determined by the MST connector's BW config iteration order. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-21-imre.deak@intel.com
2026-07-09drm/i915/dp: Use link caps for eDP DSC config selectionImre Deak
Use the link caps helper to select the maximum eDP link configuration for DSC computation, instead of using the separate max rate and lane count limits, which may not form a valid configuration after individual configs are disabled by fallback. This is a step towards unifying configuration selection and iteration across connector types and between compute and fallback paths. The state computation should likely consider all allowed configurations, as noted in the code comment; for now keep the existing eDP DSC behavior of selecting the maximum configuration determined by the eDP connector rate / lane config iteration order. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-20-imre.deak@intel.com
2026-07-09drm/i915/dp: Iterate configurations via link_caps for SST DSCImre Deak
Use the link caps configuration iterator for DP SST link configuration computation for DSC mode. This is a step towards unifying configuration selection and iteration across connector types and between compute and fallback paths. The iteration preserves the DP SST connector rate/lane ordering used by the current code. This also allows removing the now unused common rate count helper. v2: - Rebase on changes using a filter object instead of a mask of configuration indices. - Rebase on changes using an iteration object. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-19-imre.deak@intel.com
2026-07-09drm/i915/dp: Iterate configurations via link_caps for SST non-DSCImre Deak
Use the link caps configuration iterator for DP SST link configuration computation for non-DSC mode. This is a step towards unifying configuration selection and iteration across connector types and between compute and fallback paths. The iteration preserves the DP SST connector rate/lane ordering used by the current code. This also allows removing the now unused common rate count helper. v2: - Rebase on changes using a filter object instead of a mask of configuration indices. - Rebase on changes using an iteration object. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-18-imre.deak@intel.com
2026-07-09drm/i915/dp_test: Use link caps for compliance link configsImre Deak
Use the link caps configuration mask when applying DP compliance test link parameters during state computation. Preserve the legacy behavior of falling back to all configurations with the requested lane count if the requested rate and lane count pair is not allowed. In case no valid configuration is found fail the modeset. v2: - Rebase on changes using a filter object instead of a mask of configuration indices. - Rebase on changes using an iteration object. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-17-imre.deak@intel.com
2026-07-09drm/i915/dp_tunnel: Query max BW config via link_caps for BW computationImre Deak
Query the maximum link BW configuration via the link caps interface to compute the available TBT bandwidth. Unlike the max common link params used so far for this, the max BW config also accounts for any forced link parameters. This makes the max BW link config query uniform across mode validation and TBT BW calculation, and allows unexporting the intel_dp_link_caps_max_common_lane_count() helper. v2: Use the max BW link configuration, instead of the max link limits. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-16-imre.deak@intel.com
2026-07-09drm/i915/dp: Query max BW config via link_caps during mode validationImre Deak
Query the maximum link BW configuration during mode validation and MST link probing directly from intel_dp_link_caps_get_max_bw_config(), instead of using the intel_dp_max_link_rate() and intel_dp_max_lane_count() helpers. This makes the max BW link config query uniform across mode validation and TBT BW calculation, and allows unexporting the intel_dp_max_link_rate()/intel_dp_max_lane_count() helpers. v2: Use the max BW link configuration, instead of the max link limits. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-15-imre.deak@intel.com
2026-07-09drm/i915/dp_link_caps: Add helper to query max BW link configurationImre Deak
Add a helper to query the link configuration among the currently allowed configurations with the maximum link BW. This will be used by follow-up changes to unify the max BW link config query during mode validation and TBT BW calculation. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-14-imre.deak@intel.com
2026-07-09drm/i915/dp: Add link configuration filter for modeset computationImre Deak
Add link_config_filter to link_config_limits to track the set of valid link configurations during modeset state computation. Keep the existing min/max rate and lane count limits for now, until all users are converted to use the configuration filter. Add the helpers required to select the maximum configuration from the currently allowed configuration set. This will be used by follow-up changes as well to query the maximum link configuration without having to iterate the configurations. v2: - Rebase on changes using a filter object instead of a mask of configuration indices. - Rebase on changes using an iteration object. v3: - Add TODO: label to code comment about min/max link config limit removal. (Luca) Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-13-imre.deak@intel.com
2026-07-09drm/i915/gt: use correct selftest config symbolPengpeng Hou
intel_engine_user.c checks CONFIG_DRM_I915_SELFTESTS before running the engine UABI isolation check. Kconfig defines DRM_I915_SELFTEST, without the trailing "S", and the rest of i915 uses CONFIG_DRM_I915_SELFTEST. Because CONFIG_DRM_I915_SELFTESTS is not backed by any Kconfig symbol, the IS_ENABLED() test is always false. Use the existing selftest symbol so the debug/selftest guarded path can be reached when selftests are enabled. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the Kconfig definition and the inconsistent guard in intel_engine_user.c. Fixes: 750e76b4f9f6 ("drm/i915/gt: Move the [class][inst] lookup for engines onto the GT") Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260705080225.436-1-pengpeng@iscas.ac.cn
2026-07-09drm/i915/dp_link_caps: Add debugfs entry showing allowed configurationsImre Deak
Add a debugfs entry showing the currently allowed link configurations in the connector's iteration order. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-12-imre.deak@intel.com
2026-07-09drm/i915/dp_link_caps: Drop noupdate postfix from max link limit set helpersImre Deak
There is no need to update any maximum link information when updating the max link limits, so drop the related noupdate postfix from the helpers setting the max link limits. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-11-imre.deak@intel.com
2026-07-09drm/i915/dp_link_caps: Re-enable link configurations after sink caps changeImre Deak
Re-enable link configurations after sink capabilities change or the link got reset before updating the link capabilities (due to an RX_CAP_CHANGED HPD IRQ for the currently connected sink, or a new sink getting connected). This makes resetting the link explicitly by calling intel_dp_link_caps_reset() subsequently redundant; keep the existing behavior wrt. this for now, adding only a TODO: to remove the explicit reset. While at it add documentation for intel_dp_link_caps_update(). Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-10-imre.deak@intel.com
2026-07-09drm/i915/dp_link_caps: Re-enable link configurations after a link resetImre Deak
Re-enable link configurations after the link is reset via a call to intel_dp_link_caps_reset(), allowing a subsequent modeset to use all the link configurations of a sink newly connected or an already connected sink changing its capabilities. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-9-imre.deak@intel.com
2026-07-09drm/i915/dp_link_caps: Add filter for enabled link configurationsImre Deak
Add a filter for enabled link configurations to the link capability state. This allows fallback code to disable only the configuration that failed link training, instead of constraining later modesets via maximum link rate or lane count. The code only needs to exclude the failed configuration from the allowed set; all other supported configurations remain available. Use the filter when computing the allowed configuration set and when validating maximum link limits. Follow-up changes will switch the fallback code to disable individual configurations through this filter. v2: - Rebase on changes using a filter object instead of a mask of configuration indices. - Track the enabled configurations instead of the disabled ones. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-8-imre.deak@intel.com
2026-07-09drm/i915/dp_link_caps: Validate max link limitsImre Deak
Add validation in intel_dp_link_caps_set_max_limits() to ensure that the new maximum rate and lane count leave at least one allowed configuration. The validation takes disabled configurations and active forced parameters into account. Disabled configurations are not supported yet, so that part has no effect for now. At the moment this validation is also performed by the link training fallback code, but that will be removed later, leaving only the link caps module to perform the validation added in this patch. v2: Rebase on changes using a filter object instead of a mask of configuration indices. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-7-imre.deak@intel.com
2026-07-09drm/i915/dp_link_caps: Add helper to get iteration order for a connectorImre Deak
Add helper to select the link configuration iteration order for a connector during state computation and fallback selection. This keeps the connector-specific ordering policy in the link caps module. v2: Add helper to get the order for fallback selection as well. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-6-imre.deak@intel.com
2026-07-09drm/fb-helper: Only consider active CRTCs for vblank syncThomas Zimmermann
Only synchronize fbdev output to the vblank of an active CRTC. Go over the list of CRTCs and pick the first that matches. Fixes warnings as the one shown below [ 77.201354] WARNING: drivers/gpu/drm/drm_vblank.c:1320 at drm_crtc_wait_one_vblank+0x194/0x1cc [drm], CPU#1: kworker/1:7/1867 [ 77.201354] omapdrm omapdrm.0: [drm] vblank wait timed out on crtc 0 This currently happens if the fbdev output is not on CRTC 0. Atomic and non-atomic drivers require distinct code paths. As for other fbdev operations, implement both and select the correct one at runtime. Not finding an active CRTC is not a bug. Do not wait in this case, but flush the display update as before. v4: - avoid possible deadlocks with locking context (Sashiko) v3: - drop excessive state validation (Jani) - acquire plane and CRTC mutices (Sashiko) v2: - move look-up code into separate helper - support drivers with legacy modesetting v1: - see https://lore.kernel.org/dri-devel/1c9e0e24-9c4a-4259-8700-cf9e5fd60ca3@suse.de/ Co-authored-by: H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: d8c4bddcd8bcb ("drm/fb-helper: Synchronize dirty worker with vblank") Tested-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> Tested-by: H. Nikolaus Schaller <hns@goldelico.com> Closes: https://bugs.debian.org/1138033 Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260702145021.226932-1-tzimmermann@suse.de
2026-07-09drm/i915/dp_link_caps: Add link configuration iteratorImre Deak
Add helpers to iterate over the allowed and optionally filtered set of link configurations in a given order. Taking into account disabled configurations will be added later when adding support for disabling configurations. Use the BW order in descending direction by default. v2: - Keep the iteration state in an iteration object. (Jani) - Use a filter object instead of exposing configuration indices. (Jani) - Move changes adding helpers required to setup the iteration object to this patch. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-5-imre.deak@intel.com
2026-07-09drm/i915/dp_link_caps: Add support for link rate, lane count iteration ordersImre Deak
Add support for iterating configurations in either link rate/lane count or lane count/link rate order. Both orders are required for DP SST connector types: the former for computing the connector state during a modeset, and the latter for selecting a fallback configuration after a link training failure. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-4-imre.deak@intel.com
2026-07-09drm/i915/dp_link_caps: Factor out helper to get link config by indexImre Deak
Factor out a helper that looks up a link configuration by index. This provides the link configuration directly, avoiding the indirect conversion via the packed config entry. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-3-imre.deak@intel.com
2026-07-09drm/i915/doc: Document DP link capabilitiesImre Deak
Add documentation for the DP link capabilities interface. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-2-imre.deak@intel.com
2026-07-09mmc: core: add NXP IW61x base ID and block size quirkJeff Chen
The NXP IW61x series SDIO chipset identifies itself with a base card ID (0x0204) during the initial MMC bus scan, while the specific WLAN function reports a different ID (0x0205). To ensure that the MMC_QUIRK_BLKSZ_FOR_BYTE_MODE quirk is correctly inherited by all SDIO functions (including Wi-Fi), it must be attached to the base card ID at the core level. Add the SDIO_DEVICE_ID_NXP_IW61X_BASE definition and apply the required fixup in the SDIO quirk table. Signed-off-by: Jeff Chen <jeff.chen_1@nxp.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-06 22:09:06 +0000