| Age | Commit message (Collapse) | Author |
|---|
|
The incoming chip reserved several IO ports to coexist with the other
vendor's stand along chips. In order to configured them easier add the
structure.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260624033941.45918-7-pkshih@realtek.com
|
|
In order to support dual Bluetooth chip, move Bluetooth counters to BT
info. Because the two Bluetooth need to collect their own counters.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260624033941.45918-6-pkshih@realtek.com
|
|
This variable is for asking driver occupied Bluetooth traffic slot while
wifi is running at multi-port mode. Example like station + AP. The time
slot is separated by wifi driver under these wifi modes. And to ensure
Bluetooth performance, Coex will advice the Bluetooth slot length to
driver. And each MAC is able to run multi-port mode, so extend the
variable's index.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260624033941.45918-5-pkshih@realtek.com
|
|
Move wifi related counters to wifi main info, it is to facilitate
the after modification for dual MAC wifi structure.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260624033941.45918-4-pkshih@realtek.com
|
|
In order to compatible with single/dual Bluetooth structure in one branch,
offset the currently using BT info structure to BT-0.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260624033941.45918-3-pkshih@realtek.com
|
|
Wi-Fi can not reach LPS leave threshold while Wi-Fi only throughput
not good & Bluetooth share bandwidth. Add logic to let force leave
Wi-Fi LPS while Bluetooth profile exist. Update COEX version to 9.0.1.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260624033941.45918-2-pkshih@realtek.com
|
|
By default RTL8723D, RTL8703B, RTL8812A, RTL8821A, and RTL8814A are
configured to filter out all control frames except PS-Poll, even in
monitor mode.
Handle FIF_CONTROL in rtw_ops_configure_filter(). When it's set,
configure REG_RXFLTMAP1 to let all control frames through. When it's
unset, restore the original value. Because some drivers configure
REG_RXFLTMAP1 differently, keep track of its value in a new member of
struct rtw_hal.
Signed-off-by: Bitterblue Smith (S.E.A. Datentechnik GmbH) <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/2a52d718-9e46-47f2-84a1-d8e7b1ed89a8@gmail.com
|
|
rtl8723bu_bt.bin
A report from [1] that firmware is missing in linux-firmware repository.
However, there is no specific firmware for RTL8723BU for Bluetooth enabled.
Remove the unnecessary reference of firmware file.
[1] https://github.com/rtlwifi-linux/rtlwifi-next/issues/20
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260622015439.9621-1-pkshih@realtek.com
|
|
rtl92du_tx_fill_desc() uses ieee80211_get_tid() to read the QoS TID
from the 802.11 header and then uses it as an index into
sta_entry->tids[]. ieee80211_get_tid() returns the low 4-bit QoS TID
value, so the result can be in the range 0..15.
rtlwifi only allocates MAX_TID_COUNT entries for sta_entry->tids[], and
MAX_TID_COUNT is 9. A QoS TID greater than 8 therefore indexes past the
aggregation state array. Keep the default RTL_AGG_STOP state for
out-of-range TIDs, matching rtl92cu_tx_fill_desc().
This issue was detected by our static analysis tool and confirmed by
manual audit. UBSAN validation for the same bug pattern reports an
array-index-out-of-bounds access with index 10 for type
'rtl_tid_data [9]'.
Fixes: 8321424134a4 ("wifi: rtlwifi: Add rtl8192du/trx.{c,h}")
Cc: stable@vger.kernel.org
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260620025632.46206-1-runyu.xiao@seu.edu.cn
|
|
rtw_pci_probe() allocates PCI resources through
rtw_pci_setup_resource() before it sets up NAPI. If
rtw_pci_napi_init() fails, the error path jumps straight to
err_pci_declaim and skips rtw_pci_destroy(), leaving the PCI
resources allocated by rtw_pci_setup_resource() behind.
Add a dedicated cleanup label for the NAPI setup failure path so probe
destroys the PCI resources.
The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing current
mainline kernels. The tool is still under development and is not yet
publicly available. Manual inspection confirms that the bug is still
present in v7.1-rc7.
An x86_64 allyesconfig build showed no new warnings. As we do not have a
suitable rtw88 PCI board to test with, no runtime testing was able to be
performed.
Fixes: d0bcb10e7b94 ("wifi: rtw88: Un-embed dummy device")
Cc: stable@vger.kernel.org
Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260617013502.114057-1-dawei.feng@seu.edu.cn
|
|
Replace msleep() with fsleep(), because msleep() may oversleep
to as much as 20 ms when used for a 10 ms delay.
According to the kernel documentation, fsleep() is more suitable
and aligns better with modern kernel style.
Signed-off-by: Chen Jung Ku <ku.loong@gapp.nthu.edu.tw>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260613170434.23645-1-ku.loong@gapp.nthu.edu.tw
|
|
Replace "enable"/"disable" strings in ternary expressions
with the str_enable_disable() helper from <linux/string_choices.h>.
This covers the rfkill state log in rtw89_core_rfkill_poll() and
the DPK on/off log in _dpk_onoff().
No functional change intended.
Signed-off-by: Panagiotis Petrakopoulos <npetrakopoulos2003@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260612223012.504886-1-npetrakopoulos2003@gmail.com
|
|
rtw89_fw_h2c_default_cmac_tbl_be()
BE_CCTL_INFO_W2_PRELOAD_ENABLE is for h2c->w2, not h2c->w1.
These will cause h2c->w1 wrong overlap by w2 and w2 not initialized.
Fixes: c73607b3a8ef ("wifi: rtw89: fw: add CMAC H2C command to initialize default value for RTL8922D")
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260611082021.46650-1-guanwentao@uniontech.com
|
|
Replace <= with < in the loop in query_phy_status_page1(). It was
processing data related to RF path C, which this chip doesn't have.
The only bad effect seems to be that the phy_info file in debugfs was
printing unexpected values for RF path C.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/9c4beb36-2954-4db0-844a-74ba5eacf21b@gmail.com
|
|
Replace <= with < in the loops in query_phy_status_page{0,1}(). They
were processing data related to RF path C, which this chip doesn't have.
The only bad effect seems to be that the phy_info file in debugfs was
printing unexpected values for RF path C.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/ee30b95f-bc68-4711-9b15-cf5fd23c3c48@gmail.com
|
|
rtl8723be hw_init() calls local_save_flags(flags) followed by
local_irq_enable(). Later, local_irq_restore(flags) is called.
This causes warnings from Lockdep on boot and modprobe,
as local_irq_restore(flags) should only be called while irqs are disabled.
The warning was introduced to detect this class of bug in [1].
With testing I found that all paths which call hw_init() have irqs
already enabled for rtl8723be.
Furthermore, the calls were originally added for the rtl8192ce
in commit f78bccd79ba3 ("rtlwifi: rtl8192ce: Fix too long disable of IRQs")
before later being added to most other rtlwifi drivers.
Commit d3feae41a347 ("rtlwifi: Update power-save routines for 062814 driver")
then replaces the call to spin_lock_irqsave() before hw_init(),
and thus the codepath which caused irqs to be disabled in hw_init and
prompted the original commit has been removed.
The same irq save/restore pattern is also present in the hw_init() of
rtl8192ce, rtl8723ae, rtl8188ee, rtl8192se and rtl8192cu,
however I don't have the hardware to test them,
so I did not include them in my changes.
Tested on a Razer Blade 14 2017.
Example of output from Lockdep prior to fix:
raw_local_irq_restore() called with IRQs enabled
...
Call Trace:
<TASK>
rtl8723be_hw_init+0x5992/0x7220 [rtl8723be]
? static_obj+0x61/0xa0
rtl_pci_start+0x222/0x5c0 [rtl_pci]
rtl_op_start+0x128/0x1a0 [rtlwifi]
? __kasan_check_read+0x11/0x20
drv_start+0x16c/0x550 [mac80211]
...
irq event stamp: 887679
hardirqs last enabled at (887689): [<ffffffff96511170>] __up_console_sem+0x90/0xa0
hardirqs last disabled at (887698): [<ffffffff96511155>] __up_console_sem+0x75/0xa0
softirqs last enabled at (887670): [<ffffffff962f4675>] __irq_exit_rcu+0x175/0x2f0
softirqs last disabled at (887649): [<ffffffff962f4675>] __irq_exit_rcu+0x175/0x2f0
---[ end trace 0000000000000000 ]---
[1] https://lore.kernel.org/all/20210111153707.10071-1-mark.rutland@arm.com/
Signed-off-by: William Hansen-Baird <william.hansen.baird@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260609095359.2964193-1-william.hansen.baird@gmail.com
|
|
This > comparison should be >= to avoid an out of bounds access.
Fixes: 419ed7f4a053 ("wifi: rtw89: debug: extend bb_info with TX status and PER")
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/aia25i0ds3B6QF6c@stanley.mountain
|
|
The format of scan offload v2 is to extend fields to consider channel
noise as a factor to adjust dwell time of certain channels. Leave empty
for now to ignore this factor.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260525070735.27659-3-pkshih@realtek.com
|
|
The firmware features including version of command/event format are
maintained by this table, which enables features by firmware version.
Define the first feature set accordingly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260525070735.27659-2-pkshih@realtek.com
|
|
This module is now orphaned code, superseded by a kernel-global
implementation, so remove it.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260701-nova-bitfield-v2-2-2e949bf1836c@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
Replace uses of the Nova-local `bitfield!` macro with the kernel one.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260701-nova-bitfield-v2-1-2e949bf1836c@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
Pull VFIO fixes from Alex Williamson:
"Mostly straightforward fixes here, inconsistent runtime PM handling
due to global device policies, bitfield races, unwind path gaps,
teardown ordering, and a misplaced library flag.
- Fix racy bitfield updates in vfio-pci-core and the mlx5 vfio-pci
variant driver with a binary split between setup/release and
runtime modified flags. These were noted across several Sashiko
reviews as pre-existing issues (Alex Williamson)
- Fix runtime PM inconsistency where the vfio-pci driver module_init
could modify the idle PM policy of existing devices through globals
managed in vfio-pci-core, leading to unbalanced runtime PM
operations (Alex Williamson)
- Restore mutability of writable vfio-pci module options by further
pulling policy globals out of vfio-pci-core, to instead be latched
per device at device init. Provide visibility of the per device
latched values through debugfs (Alex Williamson)
- Fix missing VGA arbiter uninit callback in unwind path (Alex
Williamson)
- Reorder device debugfs removal before device_del() to avoid gap
where debugfs is available with stale devres pointers (Alex
Williamson)
- Move UUID library linking flag from vfio selftest Makefile into
libvfio.mk to avoid exposing such dependencies when linking with
KVM selftests (Sean Christopherson)"
* tag 'vfio-v7.2-rc2' of https://github.com/awilliam/linux-vfio:
vfio: selftests: Add luuid to libvfio.mk's list of libraries, not to the Makefile
vfio/pci: Expose latched module parameter policy in debugfs
vfio: Remove device debugfs before releasing devres
vfio/pci: Latch all module parameters per device
vfio/mlx5: Fix racy bitfields and tighten struct layout
vfio/pci: Fix racy bitfields and tighten struct layout
vfio/pci: Release the VGA arbiter client on register_device() failure
vfio/pci: Latch disable_idle_d3 per device
|
|
This simplifies error handling and ensures consistent error reporting.
Signed-off-by: Prashant Rahul <prashantrahul23@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes
drm-misc-fixes for v7.2-rc2:
- Fix potential null pointer dereference in dma-buf.
- Handle 0 in dma_fence_dedup_array.
- Use the correct callback in dma_fence_timeline_name.
- Fix device removal handling in amdxdna.
- kernel-doc fixes.
- Include header fix for drm_ras.h
- Handle edids better in virtio.
- Use the clk_bulk api for error handling in malidp.
- More clk handling fixes for komeda.
- panthor scheduler block fallout fixes.
- panthor unplug fixes.
- other panthor fixes.
- Fix unnecessary WARN_ON in topology probe after teardown.
- Add refcount to amdxdna job to fix use-after free.
- Fix increasing args->size in ioctl's of drm/imagination.
- Handle stride correctly in pvr_set_uobj_array.
- Only call imagination's drm_sched_entity_fini once.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patch.msgid.link/786bdc92-0ce3-4c0f-9668-b0fa8a0047ea@linux.intel.com
|
|
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes
Driver Changes:
- Wedge from the timeout handler only after releasing the queue (Rodrigo)
- Fix a NULL pointer dereference (Francois)
- Remove redundant exec_queue_suspended (Lu)
- RTP / OA whitelist fixes (Ashutosh, Gustavo, Thomas)
- Return error on non-migratable faults requiring devmem (Matt Brost)
- Skip FORCE_WC and vm_bound check for external dma-bufs (Matt Auld)
- Hold notifier lock for write on inject test path (Shuicheng)
- Drop bogus static from finish in force_invalidate (Shuicheng)
- Fix double-free of managed BO in error path (Shuicheng)
- Don't attempt to process FAST_REQ or EVENT relays (Michal)
- Fix NPD in bo_meminfo (Matthew Auld)
- Prevent invalid cursor access for purged BOs (Matthew Auld)
- Fix offset alignment for MERT WHITELST_OA_MERT_MMIO_TRG (Ashutosh)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com>
Link: https://patch.msgid.link/akZ_UbrL94G4F2iA@fedora
|
|
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
amd-drm-fixes-7.2-2026-07-02:
amdgpu:
- Soc24 aborted suspend fix
- Drop unecessary BUG() and BUG_ON() from error paths
- SCPM fix
- Power reporting fix
- DCE HDR fix
- UVD boundary checks
- VCN boundary checks
- VCE boundary checks
- DCN 4.2 fixes
- Large stack allocation fixes
- Fix aperture mapping leak
- UserQ fixes
- Ignore_damage_clips fix
- ACP fixes
- DC boundary checks
- GPUVM fixes
- JPEG idle check fixes
- Userptr fix
- GC 11.7 updates
- Non-4K page fix
- SMU 13 fixes
- DP alt mode fix
amdkfd:
- Boundary checks
- CRIU fixes
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260702143138.68463-1-alexander.deucher@amd.com
|
|
On multi-tile platforms, we need to probe the hardware for the number
of tiles that are present in the platform. That means that we should
do that as part of xe_probe_info() instead of xe_info_init(). Do
that.
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260609-xe-probe-info-v1-9-21e83e188e60@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
The value of xe->info.tile_count is only really valid after
xe_info_probe_tile_count(). Any use of tile_count before that point
is invalid and, consequently, initializing it in xe_info_init_early()
is pointless.
Move the initialization to xe_info_probe_tile_count().
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260609-xe-probe-info-v1-8-21e83e188e60@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
On GMDID-based platforms, the driver needs to probe the hardware by
reading GMDID registers in order to identify the
graphics/media/display IPs that are present in the platform as well as
their stepping values.
Currently, xe_info_init() has such a probing logic, but that task
should be rather responsibility of xe_probe_info(). As such, move it
to the latter.
For pre-GMDID platforms, the IPs are identified via PCI devid and
revid fields, which is arguably also hardware dependent. So do the
same for those platforms.
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260609-xe-probe-info-v1-7-21e83e188e60@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
Currently the logic to set the graphics step for non-GMDID-based
platforms in kunit testing is defined in xe_wa_test_init(). That
logic should rather belong to the helper xe_pci_fake_device_init(), so
move it there.
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260609-xe-probe-info-v1-6-21e83e188e60@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
The platform-level step information depends on the PCI revid and, as
such, should be probed in xe_probe_info_early() instead of
xe_info_init_early(). Move the code accordingly.
Note that we currently only update probed_info->step.platform as part
of this change. We will deal with the other fields of
probed_info->step as a follow-up change, which will be tied to the
probing of graphics and media IPs.
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260609-xe-probe-info-v1-5-21e83e188e60@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
Currently xe_step_platform_get() uses info fields from xe->info to
define the platform-level stepping value.
Because the platform-level stepping info depends on the PCI revid, it
should be defined as part of xe_probe_info_early() instead of being
directly probed inside xe_info_init_early().
Let's make sure that xe_step_platform_get() receives the necessary
data as parameters and does not depend on xe->info. That will allow
us to move the call up to xe_probe_info_early() in an upcoming change.
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260609-xe-probe-info-v1-4-21e83e188e60@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
The PCI devid and revid fields are info that we probe from the
hardware (indirectly via the PCI subsystem). Add them to
xe_probed_info and set them via xe_probe_info_early(), since the
respective fields in xe->info are updated in xe_info_init_early().
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260609-xe-probe-info-v1-3-21e83e188e60@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
The xe_step_*_get() functions update the step directly in
xe->info.step and are called by functions xe_info_init_early() and
xe_info_init().
As the stepping info is something probed from the hardware (via PCI
revid and/or GMDID) and we want to move away from probing inside
xe_info_init*() functions, let's make xe_step_*_get() functions modify
a pointer to the step structure instead of modifying xe->info.step
directly: this will allow an upcoming change that will move those
function calls out of the info init functions and will pass a member
of struct xe_probed_info instead of xe->info.step.
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260609-xe-probe-info-v1-2-21e83e188e60@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
Functions xe_info_init_early() and xe_info_init() currently probe some
information from the hardware while doing initialization of info
fields. Besides mixing responsibilities, another issue from this
approach is that kunit tests need to implement static stubs for the
probing part.
Let's prepare the ground to ensuring that those functions stop probing
the information from the hardware by creating the necessary framework
for extracting the probing bits out of them. Do that by creating a
new struct type called xe_probed_info and the functions responsible
for populating it.
In upcoming changes, we will gradually refactor the code so that all
info needed by xe_info_init_early() and xe_info_init() that is probed
from the hardware is passed to them via struct xe_probed_info.
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260609-xe-probe-info-v1-1-21e83e188e60@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set
unconditionally even when ath11k_core_qmi_firmware_ready() fails.
This leaves the driver in an inconsistent state where
initialization is considered complete although the firmware ready
handling did not finish successfully. During the subsequent SSR,
the driver enters the restart path based on this incorrect state
and dereferences uninitialized srng members, resulting in a NULL
pointer dereference.
Call trace:
ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P)
ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k]
ath11k_core_restart+0x40/0x168 [ath11k]
Fix this by:
- skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set
- setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds
- setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling
on error
Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1
Fixes: 6fe62a8cec51c ("wifi: ath11k: Add cold boot calibration support on WCN6750")
Signed-off-by: Gaole Zhang <gaole.zhang@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20260609090609.4041009-1-gaole.zhang@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
|
|
The aggr_reset_state() function uses timer_delete() (non-synchronous)
for the aggregation timer before proceeding to delete TID state and
before the structure is freed by callers like aggr_module_destroy().
If the timer callback (aggr_timeout) is executing when aggr_reset_state()
is called, the callback will continue to access aggr_conn fields like
rx_tid[] and stat[] which may be freed immediately after by
kfree(aggr_info->aggr_conn) in aggr_module_destroy().
Additionally, the timer callback can re-arm itself via mod_timer() while
aggr_reset_state() is running, creating a more complex race condition.
Use timer_delete_sync() instead to ensure any running timer callback
has completed before returning.
Fixes: bdcd81707973 ("Add ath6kl cleaned up driver")
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Hodges <git@danielhodges.dev>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20260206185207.30098-1-git@danielhodges.dev
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
|
|
ath9k_hif_request_firmware() re-arms an asynchronous firmware load via
request_firmware_nowait(), passing hif_dev as the completion context, and
then still dereferences hif_dev:
dev_info(&hif_dev->udev->dev, "ath9k_htc: Firmware %s requested\n",
hif_dev->fw_name);
The re-armed callback ath9k_hif_usb_firmware_cb() runs on the "events"
workqueue and, when the firmware is missing, walks the retry chain into
ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That
releases the wait_for_completion(&hif_dev->fw_done) in a concurrent
ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing
dev_info() in the frame that re-armed the request can therefore read freed
memory (hif_dev->udev, the first field of struct hif_device_usb):
BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware
Read of size 8 ... by task kworker/...
ath9k_hif_request_firmware
ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247
request_firmware_work_func
Allocated by ...:
ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c
Freed by ...:
ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c
The fw_done barrier only makes disconnect wait for the firmware chain to
*terminate*; it does not protect the outer ath9k_hif_request_firmware()
frame that re-armed the request and keeps touching hif_dev afterwards.
Drop the post-request dev_info(): it is the only use of hif_dev after the
async request is armed, and it is purely informational (the dev_err() on the
failure path runs only when request_firmware_nowait() did not arm a callback,
so hif_dev is still alive there).
This was first reported by syzbot as a single, non-reproduced crash that was
later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer,
which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc
device whose firmware download fails). The vulnerable code is unchanged and
still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN
once the (sub-microsecond) race window is widened.
Fixes: e904cf6fe230 ("ath9k_htc: introduce support for different fw versions")
Reported-by: syzbot+50122cbc2874b1eb25b0@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=50122cbc2874b1eb25b0
Signed-off-by: Cheng Yongkang <teel4res@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Link: https://patch.msgid.link/20260605153210.20471-1-1020691186@qq.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
|
|
inv_icm45600_buffer_fifo_read() uses the FIFO_COUNT the device reports,
unclamped, as the length of a regmap_noinc_read() into the fixed
INV_ICM45600_FIFO_SIZE_MAX (8 KiB) st->fifo.data buffer. The only bound is
the caller's "max", which the interrupt path skips (it passes 0). A device,
or an attacker on the bus, reporting up to 65535 makes the read as large as
~1 MiB: a heap out-of-bounds write of device-controlled data.
Clamp st->fifo.count to the buffer capacity before the read, and allocate
the buffer with the same INV_ICM45600_FIFO_SIZE_MAX define, so the bound
and the allocation reference one constant. The clamp is a no-op for
conforming hardware.
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
device exposure
The driver currently exposes the IIO device to userspace before
completing sensor hub callback registration, and similarly removes
callbacks while the device can still be accessed during teardown.
This creates a timing window where userspace may enable the buffer
before callbacks are available. In such cases:
- samples can be dropped,
- buffered reads may observe stale or no data.
Reorder probe and remove paths to ensure callbacks are active before
device exposure and are removed after device is no longer accessible.
This avoids a race window leading to data loss.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
device exposure
The driver currently exposes the IIO device to userspace before
completing sensor hub callback registration, and similarly removes
callbacks while the device can still be accessed during teardown.
This creates a timing window where userspace may enable the buffer
before callbacks are available. In such cases:
- samples can be dropped,
- buffered reads may observe stale or no data.
Reorder probe and remove paths to ensure callbacks are active before
device exposure and are removed after device is no longer accessible.
This avoids a race window leading to data loss.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
exposure
The driver currently exposes the IIO device to userspace before
completing sensor hub callback registration, and similarly removes
callbacks while the device can still be accessed during teardown.
This creates a timing window where userspace may enable the buffer
before callbacks are available. In such cases:
- samples can be dropped,
- buffered reads may observe stale or no data.
Reorder probe and remove paths to ensure callbacks are active before
device exposure and are removed after device is no longer accessible.
This avoids a race window leading to data loss.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
exposure
The driver currently exposes the IIO device to userspace before
completing sensor hub callback registration, and similarly removes
callbacks while the device can still be accessed during teardown.
This creates a timing window where userspace may enable the buffer
before callbacks are available. In such cases:
- samples can be dropped,
- buffered reads may observe stale or no data.
Reorder probe and remove paths to ensure callbacks are active before
device exposure and are removed after device is no longer accessible.
This avoids a race window leading to data loss.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
device exposure
The driver currently exposes the IIO device to userspace before
completing sensor hub callback registration, and similarly removes
callbacks while the device can still be accessed during teardown.
This creates a timing window where userspace may enable the buffer
before callbacks are available. In such cases:
- samples can be dropped,
- buffered reads may observe stale or no data.
Reorder probe and remove paths to ensure callbacks are active before
device exposure and are removed after device is no longer accessible.
This avoids a race window leading to data loss.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
exposure
The driver currently exposes the IIO device to userspace before
completing sensor hub callback registration, and similarly removes
callbacks while the device can still be accessed during teardown.
This creates a timing window where userspace may enable the buffer
before callbacks are available. In such cases:
- samples can be dropped,
- buffered reads may observe stale or no data.
Reorder probe and remove paths to ensure callbacks are active before
device exposure and are removed after device is no longer accessible.
This avoids a race window leading to data loss.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
device exposure
The driver currently exposes the IIO device to userspace before
completing sensor hub callback registration, and similarly removes
callbacks while the device can still be accessed during teardown.
This creates a timing window where userspace may enable the buffer
before callbacks are available. In such cases:
- samples can be dropped,
- buffered reads may observe stale or no data.
Reorder probe and remove paths to ensure callbacks are active before
device exposure and are removed after device is no longer accessible.
This avoids a race window leading to data loss.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
device exposure
The driver currently exposes the IIO device to userspace before
completing sensor hub callback registration, and similarly removes
callbacks while the device can still be accessed during teardown.
This creates a timing window where userspace may enable the buffer
before callbacks are available. In such cases:
- samples can be dropped,
- buffered reads may observe stale or no data.
Reorder probe and remove paths to ensure callbacks are active before
device exposure and are removed after device is no longer accessible.
This avoids a race window leading to data loss.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Fixes: fc18dddc0625 ("iio: hid-sensors: Added device rotation support")
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
ownership transferred to rdata
In max8998_pmic_dt_parse_pdata(), of_get_child_by_name() acquires a
reference on reg_np which is then stored in rdata->reg_node, transferring
ownership to the regulator data array. The subsequent of_node_put(reg_np)
at the end of the function releases the last matched regulator node's
reference, leaving rdata->reg_node as a dangling pointer for the last
entry.
Remove the spurious of_node_put(reg_np) call.
Cc: stable@vger.kernel.org
Fixes: 156f252857df ("drivers: regulator: add Maxim 8998 driver")
Signed-off-by: WenTao Liang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20260626160326.54457-1-vulab@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
siw_create_qp() currently calls siw_qp_add() before the queues, CQ
pointers, state, completion, and device list entry are ready. A QPN
lookup can therefore reach a QP that is still being constructed.
Move siw_qp_add() to the end of siw_create_qp(), after QP
initialization and before adding the QP to the siw device list.
Fixes: f29dd55b0236 ("rdma/siw: queue pair methods")
Link: https://patch.msgid.link/r/20260630060040.966461-1-ruoyuw560@gmail.com
Suggested-by: Bernard Metzler <bernard.metzler@linux.dev>
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
Acked-by: Bernard Metzler <bernard.metzler@linux.dev>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
|
Remove extra asterisk to avoid the following kernel-doc warning:
Warning: drivers/infiniband/hw/mlx5/umr.c:986 This comment starts with '/**',
but isn't a kernel-doc comment. Refer to Documentation/doc-guide/kernel-doc.rst
Fixes: e73242aa14d2 ("RDMA/mlx5: Optimize DMABUF mkey page size")
Link: https://patch.msgid.link/r/20260629-kdoc-fix-v1-1-735a90dede7f@nvidia.com
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
