summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-08-02wifi: nxpwifi: embed rx_reorder_ptrRosen Penev
rx_reorder_ptr is a dynamically allocated array which is done near the main struct allocation. Combine the two to avoid freeing separately. Also fix the type to what it actually is. void is normally used to avoid casting but there's no need here. Signed-off-by: Rosen Penev <rosenp@gmail.com> Tested-by: Jeff Chen <jeff.chen_1@nxp.com> Reviewed-by: Jeff Chen <jeff.chen_1@nxp.com> Link: https://patch.msgid.link/20260729183715.691287-1-rosenp@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-08-02wifi: cfg80211: convert cookie output to input parameterArend van Spriel
The remain_on_channel, mgmt_tx, and probe_peer ops previously used a u64 *cookie output parameter. Now that cfg80211 pre-assigns the cookie value before invoking drivers, the parameter conveys a value from caller to driver, not the other way around. Convert it to a plain u64 input parameter across the ops struct (cfg80211.h), rdev-ops.h wrappers, nl80211.c/mlme.c call sites, mac80211, and all driver implementations. The tx_control_port op is excluded: its cookie pointer is nullable (passed as NULL when dont_wait_for_ack is set), so the nullable pointer semantics are still required. Internal mac80211 helpers ieee80211_start_roc_work() and ieee80211_attach_ack_skb() still take u64 *cookie because they assign to the pointee; their callers now pass &cookie to take the address of the local value parameter. wil6210's internal wil_p2p_listen() is also updated to take u64 cookie since it is called directly from the remain_on_channel callback. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-12-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-08-02wifi: rtl8723bs: use pre-assigned cookie for mgmt_txArend van Spriel
Stop using params->buf address as cookie value and simply pass the pre-assigned cookie in frame tx status. This implementation seems to fire-and-forget the transmitted frame as the cookie is not used in any other way. Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-11-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-08-02wifi: qtnfmac: use pre-assigned cookie for mgmt_txArend van Spriel
Stop overwriting *cookie with a random value in qtnf_mgmt_tx(). The internal firmware frame identifier (short_cookie) is unchanged. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-10-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-08-02wifi: nxpwifi: use pre-assigned cookie for remain_on_channel and mgmt_txArend van Spriel
Stop calling nxpwifi_roc_cookie() to generate cookies in nxpwifi_cfg80211_remain_on_channel() and nxpwifi_cfg80211_mgmt_tx(). Use the pre-assigned cookie from cfg80211 instead. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-9-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-08-02wifi: wilc1000: use pre-assigned cookie for remain_on_channel and mgmt_txArend van Spriel
Stop generating cookies by incrementing inc_roc_cookie in remain_on_channel() and via get_random_u32() in mgmt_tx(). Use the pre-assigned cookie from cfg80211 instead. Remove the now-unused id local variable from remain_on_channel(). Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-8-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-08-02wifi: mwifiex: use pre-assigned cookie for remain_on_channel and mgmt_txArend van Spriel
Stop generating cookies via get_random_u32() in mwifiex_cfg80211_remain_on_channel() and mwifiex_cfg80211_mgmt_tx(). Use the pre-assigned cookie from cfg80211 instead. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-7-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-08-02wifi: brcmfmac: use pre-assigned cookie for remain_on_channel and mgmt_txArend van Spriel
Stop generating cookies in brcmf_p2p_remain_on_channel() and brcmf_cfg80211_mgmt_tx(). For remain_on_channel, remove the cookie increment from brcmf_p2p_discover_listen() and store the pre-assigned cookie in p2p->remain_on_channel_cookie. The expiry callback in brcmf_p2p_notify_listen_complete() already reads from that field. For mgmt_tx, remove the "*cookie = 0" assignments in brcmf_cfg80211_mgmt_tx() and the cyw extension. The pre-assigned cookie is then correctly passed to cfg80211_mgmt_tx_status() which already uses *cookie. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-6-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-08-02wifi: wil6210: use pre-assigned cookie for remain_on_channel, mgmt_tx and ↵Arend van Spriel
probe_peer Stop overwriting the pre-assigned cookie in wil_p2p_listen(), wil_cfg80211_mgmt_tx(), and wil_cfg80211_probe_peer(). For remain_on_channel, store the pre-assigned cookie in p2p->cookie instead of incrementing it. All cancel and expiry callbacks already read from p2p->cookie so they pick up the correct value. For mgmt_tx, remove the defensive "cookie ? *cookie : 0" guard; cfg80211 guarantees a non-NULL cookie pointer. For probe_peer, store the pre-assigned cookie in req->cookie instead of the CID value. The CID is still available via req->cid for STA lookup in wil_probe_client_handle(). Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-5-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-08-02wifi: ath6kl: use pre-assigned cookie for remain_on_channel and mgmt_txArend van Spriel
Stop generating cookies in ath6kl_remain_on_channel() and ath6kl_mgmt_tx(). cfg80211 now pre-assigns the cookie before calling into the driver. For remain_on_channel, store the pre-assigned cookie in vif->last_roc_id. Widen last_roc_id and last_cancel_roc_id from u32 to u64 to hold the full 64-bit cookie value. For mgmt_tx, store the pre-assigned cookie in wmi->last_mgmt_tx_cookie so the firmware TX status event handler can pass the correct cookie to cfg80211_mgmt_tx_status(). Thread the cookie through the powersave queue (ath6kl_mgmt_buff) so it is available when the frame is eventually dequeued and sent. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-4-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-08-02counter: ti-eqep: Remove redundant dev_err_probe()Pan Chuang
devm_request_threaded_irq() automatically logs detailed error messages on failure. Remove the now-redundant driver-specific dev_err_probe() call. Signed-off-by: Pan Chuang <panchuang@vivo.com> Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com> Reviewed-by: David Lechner <david@lechnology.com> Link: https://lore.kernel.org/r/20260715135030.326290-4-panchuang@vivo.com Signed-off-by: William Breathitt Gray <wbg@kernel.org>
2026-08-02counter: ti-ecap-capture: Remove redundant dev_err_probe()Pan Chuang
devm_request_irq() automatically logs detailed error messages on failure. Remove the now-redundant driver-specific dev_err_probe() call. Signed-off-by: Pan Chuang <panchuang@vivo.com> Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com> Link: https://lore.kernel.org/r/20260715135030.326290-3-panchuang@vivo.com Signed-off-by: William Breathitt Gray <wbg@kernel.org>
2026-08-02counter: stm32-timer-cnt: Remove redundant dev_err()Pan Chuang
devm_request_irq() automatically logs detailed error messages on failure. Remove the now-redundant driver-specific dev_err() calls. Signed-off-by: Pan Chuang <panchuang@vivo.com> Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com> Link: https://lore.kernel.org/r/20260715135030.326290-2-panchuang@vivo.com Signed-off-by: William Breathitt Gray <wbg@kernel.org>
2026-08-02counter: microchip-tcb-capture: Fix DT channel validationBabanpreet Singh
mchp_tc_probe() reads the devicetree "reg" cell - a u32, per the API contract of of_property_read_u32_index() - into a signed int, so the bounds check "channel > 2" fails to reject cell values at or above 0x80000000: reinterpreted as a negative int, they compare below 2 and pass validation. A malformed devicetree can therefore drive a negative channel into the ATMEL_TC_REG() offset arithmetic, making the driver access syscon regmap offsets outside the TC block's register window, and into the "t%d_clk" clock-name formatting, where it truncates clk_name (sized for "t0_clk".."t2_clk"). Declare channel as u32, matching the API contract; the unsigned comparison then rejects everything except channels 0..2. Adjust the format specifier to %u accordingly, which also resolves the W=1 warning that exposed the gap: microchip-tcb-capture.c:520:56: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size 6 [-Wformat-truncation=] note: directive argument in the range [-2147483648, 2] No behavior change for well-formed devicetrees: channels 0..2 take identical paths before and after. Fixes: 106b104137fd ("counter: Add microchip TCB capture counter") Assisted-by: Claude:claude-fable-5 [gcc W=1] Signed-off-by: Babanpreet Singh <bbnpreetsingh@gmail.com> Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com> Link: https://lore.kernel.org/r/20260714042910.7-1-bbnpreetsingh@gmail.com Signed-off-by: William Breathitt Gray <wbg@kernel.org>
2026-08-02perf: arm_pmu_acpi: Get rid of the edge-triggered interrupt oddityMarc Zyngier
The ACPI spec bizarrely indicates that the PMU interrupt can be edge-triggered, which contradicts the very basics of the PMU architecture (SW is required to clear the interrupt condition for the level to drop). Remove the code parsing this flag and always flag the interrupt as level triggered, no matter what firmware says. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02perf/arm_cspmu: Make IRQ more optionalRobin Murphy
If we have 64-bit counters, we can reasonably assume we'll never have to handle an overflow before the end of the universe (since we're a system PMU with no sampling). Thus even if firmware does specify an IRQ, we can still continue in the event of being unable to request it. This can help systems where IRQs cannot be claimed exclusively, or are broken in other ways. Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02perf/arm_cspmu: Improve sub-module error reportingRobin Murphy
When waiting for a sub-module to register, we return a bare -EPROBE_DEFER that ends up showing the end user: platform arm-cs-arch-pmu.1: deferred probe pending (no reason) wherein it's not necessarily clear that they might need to take some action to ensure the appropriate module is available to load. Let's use dev_err_probe() here so we can show exactly what we're waiting for. Similarly, in the case where something's gone horribly wrong with an already-registered module, we can use dev_WARN() to standardise the device/driver attribution rather than just open-coding "arm_cspmu". Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02perf/arm_cspmu: Improve APMT-based PMU namingRobin Murphy
On ACPI systems, it has not actually been possible for userspace to reliably tell which PMU corresponds to which APMT entry for types other than "ACPI device" - the evidence trail only leads from the arbitrarily-numbered PMU device to its arbitrarily-numbered parent platform device that has no distinguishing features either. While we've now improved the platform device creation to associate the actual APMT unique ID, we may as well also tweak the PMU devices to substitute the arbitrary number with a different arbitrary number that might be more directly meaningful based on the APMT definitions. We don't have an equivalent for Devicetree, but in that case the platform devices are at least identifiable via their sysfs-visible of_node. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> [will: Remove unneeded semicolon reported by coccinelle] Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02ACPI/APMT: Use stable device IDRobin Murphy
The APMT node format includes a unique identifier, so we can use this as the platform device ID to give userspace stable and identifiable device names, rather than auto numbering dependent on how the table is parsed. Cc: Lorenzo Pieralisi <lpieralisi@kernel.org> Cc: Hanjun Guo <guohanjun@huawei.com> Cc: Sudeep Holla <sudeep.holla@kernel.org> Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02perf/cxlpmu: Support Channel/Rank/Bank filterHarshal Thakkar
Implement CRB filtering per CXL 4.0 8.2.7.2.2, and extend the current filtering support beyond HDM. CRB filtering is only permitted for the DDR Interface, Queue Occupancy, Queue Residency and Retry event groups (CXL 4.0 Table 13-5), and only when counting a single event (a single mask bit). Because these group IDs are scoped by the CXL vendor ID, events from other vendors are also rejected. For example, to count DDR activates on channel 2 only: perf stat -a -e cxl_pmu_mem0.0/ddr_act,crb_filter_en=1,crb=0x02FFFFFF/ Placing the 32-bit CRB value at config2:32-63 leaves the existing HDM value at config2:0-15 untouched and avoids needing a new config3. Signed-off-by: Harshal Thakkar <harshal.t@samsung.com> [davidlohr: multiple fixes] Signed-off-by: Davidlohr Bueso <dave@stgolabs.net> Reviewed-by: Richard Cheng <icheng@nvidia.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02perf/cxlpmu: Add missing CXL 4.0 eventsHarshal Thakkar
Add support for CXL 4.0 events that are exposed by the CPMU hardware but not present in the driver. Such events are defined in Table 13-5 of the spec. Signed-off-by: Harshal Thakkar <harshal.t@samsung.com> [davidlohr: add missing throttle and queue occupancy events] Signed-off-by: Davidlohr Bueso <dave@stgolabs.net> Reviewed-by: Richard Cheng <icheng@nvidia.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02perf/cxlpmu: Fix 64-bit write to 32-bit HDM filter registerDavidlohr Bueso
The HDM decoder filter configuration register is 32 bits wide, but the driver programs it with a 64-bit writeq(). The filter value never exceeds 32 bits, so the upper half of the write is always zero and lands in the adjacent Filter ID 1 (Channel/Rank/Bank) configuration register at offset+4. Fixes: 5d7107c72796 ("perf: CXL Performance Monitoring Unit driver") Signed-off-by: Davidlohr Bueso <dave@stgolabs.net> Reviewed-by: Richard Cheng <icheng@nvidia.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02iommu/arm-smmu-v3: Support IDR5.DS and widen the TLBI SCALE fieldNicolin Chen
An SMMU implementing SMMU_IDR5.DS extends the range invalidation commands: the SCALE field grows a 6th bit, raising its maximum value from 31 to 39, and TTL == 0b01 becomes a valid level hint for a 16KB translation granule. Add a new ARM_SMMU_FEAT_DS feature detecting the DS bit, and widen the CMDQ_TLBI_0_SCALE field to its architectural 6 bits. Mask the scale value explicitly in arm_smmu_cmdq_batch_add_range(), so the range invalidation path emits the same commands as before, keeping the pre-existing 5-bit truncation of a scale above 31. Also list DS as a valid IDR5 field in the iommu_hw_info_arm_smmuv3 kdoc: iommufd has always reported the raw IDR5 register, so a VMM may conclude from that bit alone that it can expose DS to its guest. Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Assisted-by: Claude:claude-fable-5 Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02iommu/arm-smmu-v3: Convert to use atomic poll timeoutPranjal Shrivastava
The arm_smmu_write_reg_sync() helper is currently implemented using readl_relaxed_poll_timeout() (that relies on usleep_range() internally) which becomes a critical issue when used in the gerror irq handler. If the SMMU hits a gerror and enters Service Failure Mode (GERROR_SFM_ERR), the gerror handler calls arm_smmu_device_disable() in hard-irq context. This becomes a problem as arm_smmu_device_disable() inevitably calls arm_smmu_write_reg_sync() which might attempt to sleep inside a hard-irq context. Fix this by converting the arm_smmu_write_reg_sync to use the readl_relaxed_poll_timeout_atomic() polling helper. (Discovered while running Sashiko locally on another patch series). Reported-by: Sashiko <sashiko-bot@kernel.org> Fixes: 48ec83bcbcf5 ("iommu/arm-smmu: Add initial driver support for ARM SMMUv3 devices") Signed-off-by: Pranjal Shrivastava <praan@google.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02iommu/arm-smmu-v3: Add HAFT support for SVARobin Murphy
Since table access flags cannot be software-managed, if process pagetables are using HAFT then SVA must require the SMMU to support and enable it too, otherwise page aging is liable to get out of whack. For unbinding, we can't disable HAFT atomically with HA as might be desired, but luckily we can get away with just not disabling HA either. Cc: stable@vger.kernel.org Fixes: 62df5870ebf7 ("arm64: Enable ARCH_HAS_NONLEAF_PMD_YOUNG") Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02arm_mpam: Apply T241-MPAM-6 to 63-bit countersShanker Donthineni
T241-MPAM-6 causes all MBWU counter formats to count 64-byte requests instead of bytes. Commit dc48eb1ff27c excluded the 63-bit MSMON_MBWU_LWD format while scaling the shorter counters. Systems selecting the preferred 63-bit counter consequently report bandwidth values that are 64 times too small. Apply the scale to both the sampled value and overflow correction for the 63-bit format. Unsigned arithmetic retains modulo-u64 behavior when the scaled counter range exceeds u64. Fixes: dc48eb1ff27c ("arm_mpam: Add workaround for T241-MPAM-6") Link: https://lore.kernel.org/lkml/20240816131432.993859-1-sdonthineni@nvidia.com/ Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Reviewed-by: Fenghua Yu <fenghuay@nvidia.com> Tested-by: Fenghua Yu <fenghuay@nvidia.com> Reviewed-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02arm_mpam: resctrl: Add resctrl_arch_cntr_read() & resctrl_arch_reset_cntr()James Morse
When used in 'mbm_event' mode, ABMC emulation, resctrl uses arch hooks to read and reset the memory bandwidth utilization (MBWU) counters. Add these. Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Fenghua Yu <fenghuay@nvidia.com> Tested-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Fenghua Yu <fenghuay@nvidia.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02arm_mpam: resctrl: Add resctrl_arch_config_cntr() for ABMC useJames Morse
ABMC, mbm_event mode, has a helper resctrl_arch_config_cntr() for changing the mapping between 'cntr_id' and a CLOSID/RMID pair. Add the helper. For MPAM this is done by updating the mon->mbwu_idx_to_mon[] array, and as usual CDP means it needs doing in three different ways. Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Fenghua Yu <fenghuay@nvidia.com> Tested-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Fenghua Yu <fenghuay@nvidia.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02arm_mpam: resctrl: Pre-allocate assignable monitorsBen Horgan
MPAM is able to emulate ABMC, i.e. mbm_event mode, by making memory bandwidth monitors assignable. Rather than supporting the 'default' mbm_assign_mode always use 'mbm_event' mode even if there are sufficient memory bandwidth monitors. The per monitor event configuration is only provided by resctrl when in 'mbm_event' mode and so only allowing 'mbm_event' mode will make it easier to support per-monitor event configuration for MPAM. For the moment, the only event supported is mbm_total_event with no bandwidth type configuration. The 'mbm_assign_mode' file will still show 'default' when there is no support for memory bandwidth monitoring. The monitors need to be allocated from the driver, and mapped to whichever control/monitor group resctrl wants to use them with. Add a second array to hold the monitor values indexed by resctrl's cntr_id. When CDP is in use, two monitors are needed so the available number of counters halves. Platforms with one monitor will have zero monitors when CDP is in use. Co-developed-by: James Morse <james.morse@arm.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Fenghua Yu <fenghuay@nvidia.com> Tested-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Fenghua Yu <fenghuay@nvidia.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02arm_mpam: resctrl: Pick classes for use as MBM countersJames Morse
resctrl has two types of bandwidth counters, NUMA-local and global. MPAM can only count globally; either using MSC at the L3 cache or in the memory controllers. When global and local equate to the same thing continue just to call it global. Pick the corresponding MPAM classes to back the MBM counters. As resctrl requires all monitors to be at the L3 cache, we can only use the counters at the memory controllers when they have the same topology as the L3 cache and the traffic they see if the same. In particular, for the bandwidth counters at the memory controllers to be exposed to resctrl it is required there is a single L3 cache and a single NUMA node as otherwise cross NUMA traffic will be counted at the wrong instance. Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Zeng Heng <zengheng4@huawei.com> Tested-by: Fenghua Yu <fenghuay@nvidia.com> Tested-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Fenghua Yu <fenghuay@nvidia.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02arm64: escalate smp_send_stop() to an SDEI NMI as a last resortKiryl Shutsemau (Meta)
A CPU wedged with interrupts masked ignores the stop IPI, and without pseudo-NMI there is no NMI IPI to escalate to: a reboot proceeds with the CPU still running, and a kdump misses its registers. Add a third rung to smp_send_stop(): once the IPI (and pseudo-NMI IPI, if enabled) rungs have run, signal SDEI event 0 at whatever stayed online. Firmware delivers it regardless of the target's DAIF, so it reaches a CPU a plain IPI cannot; the target acks by going offline, which the caller already polls for. Fold the stop bookkeeping into one arm64_nmi_cpu_stop(regs, die_on_crash), shared by the stop IPI handlers, panic_smp_self_stop() and the SDEI handler, replacing the near-duplicate local_cpu_stop() and ipi_cpu_crash_stop(). @die_on_crash is the only difference: the IPI handlers pass true and PSCI CPU_OFF the CPU on a crash stop so a capture kernel can reclaim it; the SDEI handler and self-stop pass false and park. The SDEI park is required, not conservative -- its handler runs inside an SDEI event that is never completed (completing it resumes the wedged context), and a CPU_OFF from that unfinished-event context wedges EL3 on some firmware (left as a follow-up). The dump is unaffected; only re-onlining the CPU in an SMP capture kernel is lost. Suggested-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Yin Fengwei <fengwei_yin@linux.alibaba.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02drivers/firmware: add SDEI cross-CPU NMI service for arm64Kiryl Shutsemau (Meta)
Deliver an NMI-like event to an interrupt-masked arm64 CPU via the standard SDEI software-signalled event (event 0), without the pseudo-NMI hot-path cost: register a handler for event 0 and poke a target with sdei_event_signal(0, mpidr). First user is arch_trigger_cpumask_backtrace() (sysrq-l, RCU stalls, hung-task/soft-lockup dumps), which otherwise rides an IPI that can't reach a masked CPU. Falls back to the IPI path when SDEI is absent; no watchdog backend yet, so the stock detector is untouched. Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Yin Fengwei <fengwei_yin@linux.alibaba.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02firmware: arm_sdei: add SDEI_EVENT_SIGNAL supportKiryl Shutsemau (Meta)
Add sdei_event_signal(), a thin wrapper over the SDEI_EVENT_SIGNAL call (DEN0054) that makes the software-signalled event (event 0) pending on a target PE -- delivered NMI-like even when that PE has interrupts masked. It takes no locks, so it is safe to call from NMI / crash context. Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Yin Fengwei <fengwei_yin@linux.alibaba.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02firmware: arm_sdei: add sdei_is_present()Kiryl Shutsemau (Meta)
invoke_sdei_fn() returns -EIO when no SDEI conduit was probed, and the core warns ("Failed to create event ...") on any registration that hits that. An optional consumer that registers an event from an unconditional initcall would therefore make every boot on a non-SDEI system emit that warning for what is simply absent firmware. Expose whether SDEI firmware is present so such a consumer can skip registration -- and the warning -- when there is nothing to talk to. Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Yin Fengwei <fengwei_yin@linux.alibaba.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02drm/exynos: hdmi: take i2c adapter module referenceJohan Hovold
The i2c subsystem currently blocks during adapter deregistration whenever there are consumers holding a reference. Switch to using of_get_i2c_adapter_by_node() which also takes a reference to the adapter module so that an attempt to unload the module while in use fails gracefully instead of blocking uninterruptibly. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2026-08-02drm/exynos: Add error handling to drm_encoder_init()Diogo Silva
Not handling the return code on drm_encoder_init can lead to silent failure and/or a drm_encoder_cleanup on a non-initialized encoder. This patch adds error handling to the drm_encoder_init calls to prevent that from happening. Signed-off-by: Diogo Silva <diogompaissilva@gmail.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2026-08-02drm/exynos: Remove dependency on DRM simple helpersDiogo Silva
Simple KMS helper are deprecated since they only add an intermediate layer between drivers and the atomic modesetting. This patch removes the dependency on drm simple helpers from exynos DRM drivers. Signed-off-by: Diogo Silva <diogompaissilva@gmail.com> Dropped unnecessary blank line and reorder header definition. Signed-off-by: Inki Dae <inki.dae@samsung.com>
2026-08-02wifi: rtw89: 8922d: enable Makefile and Kconfig for RTL8922DEPing-Ke Shih
RTL8922DE is a WiFi 7 chipset, supporting 2x2 2GHz/5GHz/6GHz 4096/1024-QAM 160MHz channels. As STA, AP and P2P modes work well, enable this chipset. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260730060220.55844-8-pkshih@realtek.com
2026-08-02wifi: rtw89: coex: Update Wi-Fi/Bluetooth coexistence version to 9.24.1Ching-Te Ku
The 9.24.1 coexistence version included firmware 0.35.111.X support for RTL8922A/D, 0.24.97.X support for RTL8852C, 0.29.133.X support for RTL8852B chip family. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260730060220.55844-7-pkshih@realtek.com
2026-08-02wifi: rtw89: coex: Port _update_bt_ctrl_lps() for BT profile-based LPS controlChing-Te Ku
The old lps_ctrl_scbd logic in _update_bt_scbd() blocked WiFi LPS only when mode == BTC_WLINK_V0_2G_STA, which created a dead-lock while WiFi already in LPS suppressed TDD binding so mode was never set to BTC_WLINK_V0_2G_STA, lps_ctrl_scbd stayed 0, and WiFi remained stuck in LPS. Port _update_bt_ctrl_lps() from the reference implementation to check BT profile existence (A2DP, HFP, PAN) for both radios directly, with out_of_band and freerun guards so LPS is only blocked when WiFi and Bluetooth actually share a band. Call it from both _update_bt_scbd() and _update_bt_info() so profile changes reported via either SCBD or BT info C2H correctly update lps_ctrl_scbd. Also remove the dead lps_ctrl_scbd_last field. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260730060220.55844-6-pkshih@realtek.com
2026-08-02wifi: rtw89: coex: Change Wi-Fi link_mode_v0 translating timingChing-Te Ku
Logic should only get explicit link_mode only, to cover the old branch link_mode_v0 using (old branch firmware needed) should do translating after link_mode is settled. And the coexistence logic has already updated to new branch style, so the logic should use new link_mode, don't need to consider link_mode_v0. To prevent unexpected logic bug, refine the related logic. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260730060220.55844-5-pkshih@realtek.com
2026-08-02wifi: rtw89: coex: Clear BT link weight when BT is disabledChing-Te Ku
When a BT device is disabled, _update_bt_link_cnt() is no longer called for that device, so its link_weight[] retains stale values from the last active period. _set_bind_info() then computes a non-zero band score for the disabled device, which can lead to an incorrect tdd_bind.rf_band selection and ultimately wrong coexistence policy. Clear link_weight[] for any disabled BT device at the start of the _set_bind_info() loop so that stale scores are not carried forward. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260730060220.55844-4-pkshih@realtek.com
2026-08-02wifi: rtw89: coex: Fix BT-info parsing for 5/6 GHz band & dual BluetoothChing-Te Ku
The _update_bt_info() function always parsed BT-info for bt0 and used a single raw_info buffer regardless of which BT device sent the packet or which RF band it belongs to. This caused two bugs: 1. BT-info packets from bt1 were incorrectly parsed into bt0's state. 2. BT-info packets from 5/6 GHz BT (L1 bit7=1) overwrote the 2.4 GHz link_info and raw_info, breaking duplicate detection across bands. Fix by adding the bid parameter to select bt0/bt1, detecting the 5/6 GHz band flag (L1 bit7) to route packets into link_info_56g with a dedicated raw_info_56g buffer, and updating the early-return mask to ignore bit7 when checking the length field. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260730060220.55844-3-pkshih@realtek.com
2026-08-02wifi: rtw89: coex: Fix Bluetooth link weight not updated on profile changeChing-Te Ku
_update_bt_link_cnt() was missing the bt->link_weight[]. Without it, link_weight stays at the initial value of 5 (set on BT re-enable) regardless of the active BT profile. _set_bind_info() uses link_weight to compute b2g_score/b5g_score, which determines tdd_bind.rf_band. With a stale weight of 5 (below the active profile threshold), tdd_bind.rf_band may not reflect the actual RF band, causing mode_v0 in _run_coex() to remain 0 (BTC_WLINK_NOLINK), which incorrectly triggers _action_wl_nc() instead of the BT-profile action. Add the link_weight calculation to _update_bt_link_cnt() using the same weighting table as Formal (BIS/A2DP-sink: 70, A2DP: 40-60, PAN/active: 30, no-profile: 5, else: 9) and call _update_bt_link_cnt() from _update_bt_info() after parsing the profile exist flags, replacing the open-coded link_cnt increment that omitted le-audio profiles. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260730060220.55844-2-pkshih@realtek.com
2026-08-02wifi: rtw89: change scan offload format to V3 for WiFi 7 ICPo-Hao Huang
Adapt H2C format to fit firmware version after 0.35.113.2, which only supports active scanning with a provided SSID list. The wildcard_6ghz field is no longer required for WiFi 7 chips' new format, but not removed since WiFi 6 still requires it. Keep original H2C style also to support older firmwares. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260729124354.3231368-4-pkshih@realtek.com
2026-08-02wifi: rtw89: fix scan offload version check logicPo-Hao Huang
The version check with less than should check for smallest upper-bound first, or some branch will be unreachable. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260729124354.3231368-3-pkshih@realtek.com
2026-08-02wifi: rtw89: refine RX filter configuration for WiFi 7 generationDian-Syuan Yang
When an AP interface is registered and starts AP, mac80211 calls the configure_filter() to clear B_AX_A_UC_CAM_MATCH and B_AX_A_BC_CAM_MATCH so that frames from un-associated stations can be received. However, for a dedicated AP interface created via iw command, configure_filter() is only triggered on the initial AP startup. Since the interface remains up even after hostapd stops, and it isn't triggered again on later restarts. Additionally, each AP start causes IPS leave, reverting the RX filter to its default value. For WiFi 7 chips, the default value is hardcoded in rx_fltr_init_be(), so the reverted value does not match hal.rx_fltr. Therefore, refine the behavior of WiFi 7 chips to align with the WiFi 6 implementation. Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260729124354.3231368-2-pkshih@realtek.com
2026-08-02wifi: rtw89: pci: add .shutdown callback to stop rfkill polling on rebootYuhang.chen
Since the hardware rfkill polling was introduced, arm64 platforms can panic with an asynchronous SError during warm reboot: SError Interrupt on CPU8, code 0x00000000be000011 -- SError Workqueue: events_power_efficient rfkill_poll [rfkill] rtw89_pci_ops_read8+0x94/0x160 [rtw89_pci] rtw89_core_rfkill_poll+0x50/0x1e0 [rtw89_core] rtw89_ops_rfkill_poll+0x40/0x68 [rtw89_core] ieee80211_rfkill_poll+0x3c/0x70 [mac80211] cfg80211_rfkill_poll+0x40/0x2a0 [cfg80211] rfkill_poll+0x30/0x88 [rfkill] Kernel panic - not syncing: Asynchronous SError Interrupt On the reboot path the kernel only runs device_shutdown(), which calls each driver's .shutdown callback; .remove is not invoked. The rtw89 PCI driver had no .shutdown callback, so nothing stopped the rfkill polling work while the platform was tearing the PCIe link down. Once the link is gone, the next MMIO read from the poll handler targets a non-responding device and is reported as a fatal asynchronous SError on arm64. Add rtw89_pci_shutdown(), wired to all rtw89 PCI device drivers, which sets a new RTW89_FLAG_SHUTDOWN flag (mirroring the USB RTW89_FLAG_UNPLUGGED pattern). When the flag is set, rtw89_ops_rfkill_poll() returns early, so no MMIO read is issued to the chip after shutdown begins and the SError no longer occurs. This does not call the full .remove path from .shutdown, to keep the shutdown handler minimal and avoid running the non-idempotent teardown twice. Fixes: 0b38e6277aed ("wifi: rtw89: add support for hardware rfkill") Cc: stable@vger.kernel.org Suggested-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yuhang.chen <yhchen312@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260729014142.2746777-1-yhchen312@gmail.com
2026-08-01wifi: mt76: mt7996: remove beacon_int_min_gcd from ADHOC interface combinationsJose Ignacio Tornos Martinez
The driver fails to register with error -22 (EINVAL) due to a cfg80211 validation failure in wiphy_verify_iface_combinations(). Commit 5ef0e8e2653b ("wifi: mt76: mt7996: fix iface combination for different chipsets") added beacon_int_min_gcd to if_comb_global and if_comb_global_7992, but these combinations include ADHOC (IBSS) interface type. This violates a cfg80211 rule from commit 56271da29c52 ("cfg80211: disallow beacon_int_min_gcd with IBSS") that explicitly forbids combining ADHOC with beacon_int_min_gcd. The restriction exists because beacon_int_min_gcd requires static, predictable beacon intervals to coordinate multiple beaconing interfaces, but ADHOC interfaces have dynamic beacon intervals that change when joining different networks, making the GCD constraint unenforceable. Remove beacon_int_min_gcd from the interface combinations that include ADHOC because they are not necessary for ADHOC operation. The if_comb combination (AP/MESH/STA only, without ADHOC) correctly retains beacon_int_min_gcd for multi-AP coordination. Fixes: 5ef0e8e2653b ("wifi: mt76: mt7996: fix iface combination for different chipsets") Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com> Tested-by: Alex Gavin <alex.gavin@candelatech.com> Link: https://patch.msgid.link/20260702104337.679536-1-jtornosm@redhat.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-08-01wifi: mt76: mt792x: do not advertise active monitorDevin Wittmayer
mt76_phy_init() sets NL80211_FEATURE_ACTIVE_MONITOR for every mt76 device, but mt792x firmware does not honor it: entering active monitor mode stops RX. Gate the feature behind a new per-phy no_active_monitor flag and set it for mt792x. Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca> Link: https://patch.msgid.link/20260722011302.113060-1-lucid_duck@justthetip.ca Signed-off-by: Felix Fietkau <nbd@nbd.name>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-17 07:44:23 +0000