summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2026-06-22Input: goodix - clamp the device-reported contact countBryam Vargas1-1/+2
goodix_ts_read_input_report() copies the number of touch points reported by the device into an on-stack buffer u8 point_data[2 + GOODIX_MAX_CONTACT_SIZE * GOODIX_MAX_CONTACTS]; which is sized for at most GOODIX_MAX_CONTACTS (10) contacts. The only runtime check bounds the per-interrupt count against ts->max_touch_num, but that value is taken verbatim from a 4-bit field of the device configuration block and is never clamped: ts->max_touch_num = ts->config[MAX_CONTACTS_LOC] & 0x0f; The nibble can be 0..15, so a malfunctioning, malicious or counterfeit controller (or an attacker tampering with the I2C bus) can advertise up to 15 contacts. goodix_ts_read_input_report() then accepts a touch_num of up to 15 and the second goodix_i2c_read() writes ts->contact_size * (touch_num - 1) bytes past the one-contact header into point_data - up to 30 bytes (45 with the 9-byte report format) beyond the 92-byte buffer: a stack out-of-bounds write. Clamp max_touch_num to GOODIX_MAX_CONTACTS, the number of contacts point_data[] is sized for, when reading it from the configuration. Fixes: a7ac7c95d468 ("Input: goodix - use max touch number from device config") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Link: https://patch.msgid.link/20260612-b4-disp-6844625d-v1-1-df0aed080c9d@proton.me Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-23md/raid5: avoid R5_Overlap races while breaking stripe batchesChen Cheng1-5/+5
KCSAN report a race in break_stripe_batch_list() vs. raid5_make_request() on sh->dev[i].flags (plain word write vs. atomic bit op).. and .. one possible scenario is: CPU1 CPU2 break_stripe_batch_list(sh1) -> handle sh2 -> lock(sh2) -> sh2->batch_head = NULL -> unlock(sh2) -> test_and_clear_bit(R5_Overlap, sh2->dev[i].flags) -> wake_up_bit(sh2->dev[i].flags) raid5_make_request() -> add_all_stripe_bios(sh2) -> lock(sh2) -> stripe_bio_overlaps(sh2) returns true batch_head is NULL, so new bio overlap exist bio on sh2 -> true -> set_bit(R5_Overlap, sh2->dev[i].flags) -> unlock(sh2) -> wait_on_bit(sh2->dev[i].flags) -> sh2->dev[i].flags = sh1->dev[i].flags & ~R5_Overlap No wait_up_bit(), CPU2 could be wait_on_bit() forever... Fix by : - Expand the protect zone. - Use batch_head's device flag's snaphot when no held head_sh->stripe_lock. - Move sh/head_sh->batch_head = NULL to the end of protected zone , and , any concurrent add_all_stripe_bios() grabs sh->stripe_lock now either: - see batch_head != null, and , is rejected by stripe_bio_overlaps() under the lock (no R5_Overlap wait ) , or , - sees batch_head == NULL, only after dev[i].flags has already been set and the prior R5_Overlap waiters worken. KCSAN report: ================================================ BUG: KCSAN: data-race in break_stripe_batch_list / raid5_make_request write (marked) to 0xffff8e89c8117548 of 8 bytes by task 4042 on cpu 0: raid5_make_request+0xea0/0x2930 md_handle_request+0x4a2/0xa40 md_submit_bio+0x109/0x1a0 __submit_bio+0x2ec/0x390 submit_bio_noacct_nocheck+0x457/0x710 submit_bio_noacct+0x2a7/0xc20 submit_bio+0x56/0x250 blkdev_direct_IO+0x54c/0xda0 blkdev_write_iter+0x38f/0x570 aio_write+0x22b/0x490 io_submit_one+0xa51/0xf70 __x64_sys_io_submit+0xf7/0x220 x64_sys_call+0x1907/0x1c60 do_syscall_64+0x130/0x570 entry_SYSCALL_64_after_hwframe+0x76/0x7e read to 0xffff8e89c8117548 of 8 bytes by task 4010 on cpu 5: break_stripe_batch_list+0x249/0x480 handle_stripe_clean_event+0x720/0x9b0 handle_stripe+0x32fb/0x4500 handle_active_stripes.isra.0+0x6e0/0xa50 raid5d+0x7e0/0xba0 md_thread+0x15a/0x2d0 kthread+0x1e3/0x220 ret_from_fork+0x37a/0x410 ret_from_fork_asm+0x1a/0x30 value changed: 0x0000000000000019 -> 0x0000000000000099 --> R5_Overlap Fixes: fb642b92c267 ("md/raid5: duplicate some more handle_stripe_clean_event code in break_stripe_batch_list") Signed-off-by: Chen Cheng <chencheng@fnnas.com> Link: https://patch.msgid.link/20260619041013.1207148-1-chencheng@fnnas.com Signed-off-by: Yu Kuai <yukuai@fygo.io>
2026-06-23md/raid5: use stripe state snapshot in break_stripe_batch_list()Chen Cheng1-19/+26
The patch just suppress KCSAN noise. No functional change. RAID-5 can group multi full-stripe-write aka stripe_head into a batch aka batch_list, with one head_sh leading them. Call break_stripe_batch_list() when the batch is finished, or, a stripe has to be dropped out of the batch. break_stripe_batch_list() reads stripe state several times while request paths can update thost state words concurrently with lockless bitops, which reported by KCSAN. Use a snapshot to guarantees that the value used for warning, copying, and handle checks is internally consistent at current read moment. KCSAN report: ============================================== BUG: KCSAN: data-race in __add_stripe_bio / break_stripe_batch_list write (marked) to 0xffff8e89d4f0b988 of 8 bytes by task 4323 on cpu 3: __add_stripe_bio+0x35e/0x400 raid5_make_request+0x6ac/0x2930 md_handle_request+0x4a2/0xa40 md_submit_bio+0x109/0x1a0 __submit_bio+0x2ec/0x390 submit_bio_noacct_nocheck+0x457/0x710 submit_bio_noacct+0x2a7/0xc20 submit_bio+0x56/0x250 blkdev_direct_IO+0x54c/0xda0 blkdev_write_iter+0x38f/0x570 aio_write+0x22b/0x490 io_submit_one+0xa51/0xf70 read to 0xffff8e89d4f0b988 of 8 bytes by task 4290 on cpu 4: break_stripe_batch_list+0x3ce/0x480 handle_stripe_clean_event+0x720/0x9b0 handle_stripe+0x32fb/0x4500 handle_active_stripes.isra.0+0x6e0/0xa50 raid5d+0x7e0/0xba0 Signed-off-by: Chen Cheng <chencheng@fnnas.com> Link: https://patch.msgid.link/20260618134748.1168360-1-chencheng@fnnas.com Signed-off-by: Yu Kuai <yukuai@fygo.io>
2026-06-22net: airoha: Fix TX scheduler queue mask loop upper boundWayen Yan1-1/+1
In airoha_qdma_set_chan_tx_sched(), the loop clearing queue mask was using AIROHA_NUM_TX_RING (32) instead of AIROHA_NUM_QOS_QUEUES (8). Each channel has 8 queues, and TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i) computes BIT(i + (channel * 8)). With i ranging 0..31, this causes: - channel 0: clears bit 0..31 (all 4 channels) instead of 0..7 - channel 1: clears bit 8..31 (channels 1-3) instead of 8..15 - channel 2: clears bit 16..31 (channels 2-3) instead of 16..23 - channel 3: clears bit 24..31 (channel 3 only) - correct by accident While BIT(32+) on arm64 produces 64-bit values truncated to 0 in u32 mask parameter, the loop still incorrectly clears queues within the same channel beyond queue 7. Even though this is functionally harmless (the register resets to 0 and is only ever cleared, never set — so clearing extra bits is a no-op), the loop bound is semantically wrong and should be fixed for correctness and clarity. Fix by using AIROHA_NUM_QOS_QUEUES (8) as the loop upper bound. Fixes: ef1ca9271313 ("net: airoha: Add sched HTB offload support") Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Wayen Yan <win847@gmail.com> Link: https://patch.msgid.link/178187479434.2400840.1312143943526335838@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-22bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp()Abdun Nihaal1-2/+1
If the allocation of fp[i].tpa_info fails, the error path will not free the struct bnx2x_fastpath allocated earlier, as it is not linked to the bp structure yet. Fix that by linking it immediately after allocation. Cc: stable@vger.kernel.org Fixes: 15192a8cf8a8 ("bnx2x: Split the FP structure") Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260620062402.89549-1-nihaal@cse.iitm.ac.in Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-22eth: bnxt: improve the timing of statsJakub Kicinski3-1/+53
Kernel selftests wait 1.25x of the promised stats refresh time (as read from ethtool -c). bnxt reports 1sec by default, but the stats update process has two steps. First device DMAs the new values, then the service task performs update in full-width SW counters. So the worst case delay is actually 2x. Note that the behavior is different for ring stats and port stats. Port stats are fetched synchronously by the service worker, so there's no risk of doubling up the delay there. The problem of stale stats impacts not only tests but real workloads which monitor egress bandwidth of a NIC. The inaccuracy causes double counting in the next cycle and spurious overload alarms. Try to read from the DMA buffer more aggressively, to mitigate timing issues between DMA and service task. The SW update should be cheap. Fixes: 51f307856b60 ("bnxt_en: Allow statistics DMA to be configurable using ethtool -C.") Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20260619191538.104165-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-22hdlc_ppp: sync per-proto timers before freeing hdlc stateFan Wu1-2/+13
Each PPP control protocol (LCP/IPCP/IPV6CP) embedded in struct ppp registers a timer via timer_setup(). That struct ppp is the hdlc->state allocation, which detach_hdlc_protocol() frees with kfree() in both teardown paths: unregister_hdlc_device() and the re-attach inside attach_hdlc_protocol(). The ppp proto never registered a .detach callback, so detach_hdlc_protocol() performs no timer synchronization before the kfree(). The only cancel, timer_delete(&proto->timer) in ppp_cp_event(), is partial (it does not wait for a running callback) and only runs on the ->CLOSED transition; ppp_stop()/ppp_close() do not sync either. A ppp_timer callback already executing (blocked on ppp->lock) survives the kfree and then dereferences proto->state / ppp->lock in freed memory, leading to a use-after-free. Fix this by adding a .detach helper that calls timer_shutdown_sync() on every per-proto timer. detach_hdlc_protocol() invokes proto->detach(dev) before kfree(hdlc->state), so timer_shutdown_sync() now runs on both free paths. timer_shutdown_sync() is used instead of timer_delete_sync() because the keepalive path re-arms the timer through add_timer()/mod_timer() and shutdown blocks any re-activation during teardown. Initialize the per-protocol timers in ppp_ioctl() when the protocol is attached, and remove the now-redundant timer_setup() from ppp_start(), so that the timers are initialized exactly once at attach time and ppp_timer_release() never operates on uninitialized timer_list structures. attach_hdlc_protocol() uses kmalloc() (not kzalloc), so struct ppp's protos[i].timer is uninitialized garbage until the first timer_setup(); without this init-at-attach, attaching the PPP protocol without ever bringing the device up would leave timer_shutdown_sync() operating on uninitialized memory in .detach. Moving the init out of ppp_start() (which only runs on NETDEV_UP) into the attach path makes the initialization unconditional and avoids initializing the same timer_list twice. This bug was found by static analysis. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Link: https://patch.msgid.link/20260617020518.116319-1-fanwu01@zju.edu.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-22net: ethernet: ti: icssg: guard PA stat lookupsPhilippe Schenker1-21/+28
icssg_ndo_get_stats64() unconditionally calls emac_get_stat_by_name() with FW PA stat names regardless of whether the PA stats block is present on the hardware. emac_get_stat_by_name() already guards the PA stats lookup with `if (emac->prueth->pa_stats)`; when that pointer is NULL the lookup falls through to netdev_err() and returns -EINVAL. Because ndo_get_stats64 is polled regularly by the networking stack this produces thousands of log entries of the form: icssg-prueth icssg1-eth end0: Invalid stats FW_RX_ERROR A secondary consequence is that the int(-EINVAL) return value is implicitly widened to a near-ULLONG_MAX unsigned value when accumulated into the __u64 fields of rtnl_link_stats64, silently corrupting the rx_errors, rx_dropped and tx_dropped counters reported by `ip -s link`. Every other PA-aware code path in the driver is already guarded with the same `if (emac->prueth->pa_stats)` check. Apply the same guard here. Fixes: 0d15a26b247d ("net: ti: icssg-prueth: Add ICSSG FW Stats") Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch> Reviewed-by: Simon Horman <horms@kernel.org> Cc: danishanwar@ti.com Cc: rogerq@kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260618093037.3448858-1-dev@pschenker.ch Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-22rocker: Fix memory leak in ofdpa_port_fdb()Ziran Zhang1-0/+3
In ofdpa_port_fdb(), the hash_del() only unlinks the node from hash table, but does not free it. Fix this by adding kfree(found) after the !found == removing check, where the pointer value is no longer needed. Found by Coccinelle kfree script. Cc: <stable+noautosel@kernel.org> # rocker is a test harness, it's never loaded on production systems Signed-off-by: Ziran Zhang <zhangcoder@yeah.net> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260616013245.7098-1-zhangcoder@yeah.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-23rtc: mv: add suspend/resume support for wakeupXue Lei1-0/+23
Add PM suspend/resume callbacks to enable/disable IRQ wake for the RTC alarm interrupt. This allows the RTC alarm to wake the system from STR (e.g. via rtcwake -m mem -s N). Without this, the RTC IRQ is masked during suspend by the MPIC's IRQCHIP_MASK_ON_SUSPEND behavior, preventing alarm-based wakeup. Signed-off-by: Xue Lei <Xue.Lei@windriver.com> Link: https://patch.msgid.link/20260611023350.1370881-1-Xue.Lei@windriver.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-06-23rtc: aspeed: add AST2700 compatibleTommy Huang1-0/+1
Add support for matching the RTC controller on ASPEED AST2700 SoCs. The AST2700 RTC controller is compatible with the existing ASPEED RTC driver implementation. Signed-off-by: Tommy Huang <tommy_huang@aspeedtech.com> Link: https://patch.msgid.link/20260601-ast2700-rtc-v1-2-15d4ca46500a@aspeedtech.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-06-23rtc: interface: fix typos in rtc_handle_legacy_irq() documentationYahya Saqban1-2/+2
Fix spelling of 'occurence' to 'occurrence' and 'of' to 'or' in the kernel-doc comment for rtc_handle_legacy_irq(). Signed-off-by: Yahya Saqban <yahyasaqban@gmail.com> Link: https://patch.msgid.link/20260512210235.343070-1-yahyasaqban@gmail.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-06-23rtc: msc313: fix NULL deref in shared IRQ handler at probeStepan Ionichev1-2/+2
msc313_rtc_probe() calls devm_request_irq() with IRQF_SHARED and &pdev->dev as the cookie, but platform_set_drvdata() is only called later after the clock setup. With a shared IRQ line, another device on the same line can trigger the handler in that window. The handler does dev_get_drvdata() on the cookie, gets NULL, and dereferences priv->rtc_base in interrupt context. Pass priv as the cookie directly so the handler reads it from dev_id without the lookup, removing the dependency on probe order. Fixes: be7d9c9161b9 ("rtc: Add support for the MSTAR MSC313 RTC") Signed-off-by: Stepan Ionichev <sozdayvek@gmail.com> Link: https://patch.msgid.link/20260511032703.48262-1-sozdayvek@gmail.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-06-23rtc: remove unused pcap driverArnd Bergmann3-187/+0
The platform was removed a few years ago, and the mfd driver is also gone now, so it is impossible to build or use it. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260527193927.3523952-1-arnd@kernel.org Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-06-23rtc: interface: Add rtc_read_next_alarm() to read next expiring timerMario Limonciello1-0/+40
Add a new function rtc_read_next_alarm() that reads the next expiring alarm from the RTC timerqueue. This is different from rtc_read_alarm(), which only reads the aie_timer. The wakealarm sysfs file programs the rtc->aie_timer, whereas the alarmtimer suspend routine programs its own timer into the RTC timerqueue. Both timers end up in the RTC's timerqueue, and the first expiring timer is what gets armed in the hardware. This new function allows code to query which alarm will actually fire next, regardless of which subsystem programmed it. This is needed by platform code that needs to program secondary timers based on the actual next wakeup time. Link: https://lore.kernel.org/all/87ed50z0le.ffs@tglx Suggested-by: Thomas Gleixner <tglx@linutronix.de> Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/20260521043714.1022930-2-mario.limonciello@amd.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-06-22nbd: don't warn when reclassifying a busy socket lockDeepanshu Kartikey1-1/+1
nbd_reclassify_socket() warns via WARN_ON_ONCE() if the socket lock is held at the point of reclassification. That assertion was copied from nvme-tcp, where the socket is created internally by the kernel (sock_create_kern()) and is never visible to user space, so the lock is guaranteed to be free. NBD is different: the socket is looked up from a user-supplied fd in nbd_get_socket(), and user space retains that fd. A concurrent syscall on the same socket (or softirq processing taking bh_lock_sock() on a connected TCP socket) can legitimately hold the lock at the instant NBD reclassifies it. sock_allow_reclassification() then returns false and the WARN_ON_ONCE() fires, which turns into a crash under panic_on_warn. This is reachable by simply racing NBD_CMD_CONNECT against socket activity on the same fd, as reported by syzbot. Hitting a held lock here is expected for an externally owned socket and is not a kernel bug, so skip reclassification silently instead of warning. Reclassification is a lockdep-only annotation, so skipping it in the rare racing case is harmless. Reported-by: syzbot+6b85d1e39a5b8ed9a954@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6b85d1e39a5b8ed9a954 Fixes: d532cddb6c60 ("nbd: Reclassify sockets to avoid lockdep circular dependency") Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com> Acked-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260621235255.66015-1-kartikey406@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-06-22e1000e: Reconfigure PLL clock gate timeout and re-enable K1 on Meteor LakeDima Ruinskiy2-1/+17
Commit 3c7bf5af21960 ("e1000e: Introduce private flag to disable K1") disabled K1 by default on Meteor Lake and newer systems due to packet loss observed on various platforms. However, disabling K1 caused an increase in power consumption. To mitigate this, reconfigure the PLL clock gate value so that K1 can remain enabled without incurring the additional power consumption. Re-enable K1 by default, but keep the private flag to support disabling it via ethtool. Additionally, introduce a DMI quirk table, so that K1 may be disabled by default on known problematic systems. Currently, this includes the Dell Pro 16 Plus, where the issue has been reported to persist despite the changes to the PLL lock timeout. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220954 Link: https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20250623/048860.html Link: https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20260330/054059.html Signed-off-by: Dima Ruinskiy <dima.ruinskiy@intel.com> Co-developed-by: Vitaly Lifshits <vitaly.lifshits@intel.com> Signed-off-by: Vitaly Lifshits <vitaly.lifshits@intel.com> Fixes: 3c7bf5af21960 ("e1000e: Introduce private flag to disable K1") Tested-by: Moriya Kadosh <moriyax.kadosh@intel.com> Tested-by: Todd Brandt <todd.e.brandt@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-06-22i40e: Fix i40e_debug() to use struct i40e_hw argumentMohamed Khalfella1-1/+1
i40e_debug() macro takes struct i40e_hw *h as first argument. But the macro body uses hw instead of h. This has been working so far because hw happens to be the name of the variable in the context where the macro is expanded. Fix the macro to use the passed argument. Fixes: 5dfd37c37a44 ("i40e: Split i40e_osdep.h") Signed-off-by: Mohamed Khalfella <mkhalfella@purestorage.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Tested-by: Alexander Nowlin <alexander.nowlin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-06-22ice: dpll: fix memory leak in ice_dpll_init_info error pathsZhaoJinming1-6/+10
Several error return paths in ice_dpll_init_info() directly return without freeing previously allocated resources, causing memory leaks: - When de->input_prio allocation fails, d->inputs is leaked - When dp->input_prio allocation fails, d->inputs and de->input_prio are leaked - When ice_get_cgu_rclk_pin_info() fails, all previously allocated inputs/outputs/input_prio are leaked - When ice_dpll_init_pins_info(RCLK_INPUT) fails, same resources are leaked Fix this by jumping to the deinit_info label which properly calls ice_dpll_deinit_info() to free all allocated resources. Fixes: d7999f5ea64b ("ice: implement dpll interface to control cgu") Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-06-22ice: dpll: set pointers to NULL after kfree in ice_dpll_deinit_infoZhaoJinming1-0/+4
ice_dpll_deinit_info() calls kfree() on several pf->dplls fields (inputs, outputs, eec.input_prio, pps.input_prio) but does not set the pointers to NULL afterward. This leaves dangling pointers in the pf->dplls structure. While not currently exploitable through existing code paths, this is unsafe because: 1. If ice_dpll_init_info() is called again after a deinit (e.g. during driver recovery), and a subsequent allocation within init fails, the error path will jump to deinit_info and call ice_dpll_deinit_info() again. Since some pointers still hold the old freed addresses, this would result in a double-free. 2. Any future code that checks these pointers before use or after free would be unprotected against use-after-free. Follow the common kernel convention of setting pointers to NULL after kfree() so that: - kfree(NULL) is a safe no-op, preventing double-free - NULL checks on these pointers become meaningful This is a preparatory fix for a subsequent patch that routes additional error paths in ice_dpll_init_info() to the deinit_info label. Fixes: d7999f5ea64b ("ice: implement dpll interface to control cgu") Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-06-22rtc: isl1208: Balance enable_irq_wake() with disable_irq_wake() on cleanupJohn Madieu1-1/+14
isl1208_setup_irq() calls enable_irq_wake() after a successful IRQ request, but the driver has no remove path that balances it. The driver is devm-only, so on unbind devm releases the IRQ - but enable_irq_wake() is not undone by IRQ release, so the wake count for that IRQ stays incremented. Each rebind therefore leaks one wake reference; the leak doubles for the chip variant that has a separate evdet IRQ, since isl1208_setup_irq() is then called twice during probe. Register a devm action that calls disable_irq_wake() per IRQ. While at it, check enable_irq_wake()'s return value: on failure, propagate the error rather than silently registering a disable action for an IRQ whose wake state was never enabled. Fixes: 9ece7cd833a3 ("rtc: isl1208: Add "evdet" interrupt source for isl1219") Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Link: https://patch.msgid.link/20260425154959.2796261-3-john.madieu.xa@bp.renesas.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-06-22ice: call netif_keep_dst() once when entering switchdev modeMarcin Szycik1-2/+2
netif_keep_dst() only needs to be called once for the uplink VSI, not once for each port representor. Move it from ice_eswitch_setup_repr() to ice_eswitch_enable_switchdev(). Fixes: defd52455aee ("ice: do Tx through PF netdev in slow-path") Signed-off-by: Marcin Szycik <marcin.szycik@intel.com> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Tested-by: Patryk Holda <patryk.holda@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-06-22ice: fix ice_init_link() error return preventing probePaul Greenwalt1-11/+5
ice_init_link() can return an error status from ice_update_link_info() or ice_init_phy_user_cfg(), causing probe to fail. An incorrect NVM update procedure can result in link/PHY errors, and the recommended resolution is to update the NVM using the correct procedure. If the driver fails probe due to link errors, the user cannot update the NVM to recover. The link/PHY errors logged are non-fatal: they are already annotated as 'not a fatal error if this fails'. Since none of the errors inside ice_init_link() should prevent probe from completing, convert it to void and remove the error check in the caller. All failures are already logged; callers have no meaningful recovery path for link init errors. Fixes: 5b246e533d01 ("ice: split probe into smaller functions") Cc: stable@vger.kernel.org Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Alexander Nowlin <alexander.nowlin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-06-22ice: fix AQ error code comparison in ice_set_pauseparam()Lukasz Czapnik2-5/+8
Fix unreachable code: the conditionals in ice_set_pauseparam() used the bitwise-AND operator suggesting aq_failures is a bitmap, but it is actually an enum, making the third condition logically unreachable. Replace the if-else ladder with a switch statement. Also move the aq_failures initialization to the variable declaration and remove the redundant zeroing from ice_set_fc(). Fixes: fcea6f3da546 ("ice: Add stats and ethtool support") Signed-off-by: Lukasz Czapnik <lukasz.czapnik@intel.com> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-06-22ice: fix FDIR CTRL VSI resource leak in ice_reset_all_vfs()Dawid Osuchowski1-1/+1
Resetting all VFs causes resource leak on VFs with FDIR filters enabled as CTRL VSIs are only invalidated and not freed. Fix by using ice_vf_ctrl_vsi_release() instead of ice_vf_ctrl_invalidate_vsi() which aligns behavior with the ice_reset_vf() function. Reproduction: echo 1 > /sys/class/net/$pf/device/sriov_numvfs ethtool -N $vf flow-type ether proto 0x9000 action 0 echo 1 > /sys/class/net/$pf/device/reset Fixes: da62c5ff9dcd ("ice: Add support for per VF ctrl VSI enabling") Signed-off-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-06-22PCI: endpoint: pci-epf-vntb: Guard configfs writes after EPC attachKoichiro Den1-1/+40
db_count controls how many doorbell slots are allocated and exposed. It is also used by the doorbell mask helpers. After an EPC has been attached, changing it from configfs can leave runtime paths using a different count than the one used to set up the doorbell resources. Reject db_count writes after EPC attach, and reject values outside MIN_DB_COUNT..MAX_DB_COUNT before attach. Now that MIN_DB_COUNT documents the usable doorbell floor, use it in the store path too. While at it, apply the same after-attach guard to the other vNTB configfs knobs. BAR choices, spad_count, memory-window counts and sizes, and the virtual PCI IDs are also consumed during bind, so changing them later at runtime is meaningless and unsafe. Return -EOPNOTSUPP for after-attach writes. The value itself may be valid, but changing it in that state is not supported. Signed-off-by: Koichiro Den <den@valinux.co.jp> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260513024923.451765-6-den@valinux.co.jp
2026-06-22PCI: endpoint: pci-epf-vntb: Reject unusable doorbell countsKoichiro Den1-4/+6
pci-epf-vntb reserves slot 0 for link events and keeps slot 1 unused for legacy layout compatibility. A db_count smaller than MIN_DB_COUNT leaves no usable doorbell slot after those reservations. Reject such configurations when configuring interrupts. While at it, move MAX_DB_COUNT next to MIN_DB_COUNT. They are used as a pair in the range check, and keeping them together makes the valid doorbell range easier to read. Signed-off-by: Koichiro Den <den@valinux.co.jp> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260513024923.451765-5-den@valinux.co.jp
2026-06-22PCI: endpoint: pci-epf-vntb: Report 0-based doorbell vector via ntb_db_event()Koichiro Den1-9/+16
ntb_db_event() expects the vector number to be relative to the first doorbell vector starting at 0. pci-epf-vntb reserves vector 0 for link events and uses higher vector indices for doorbells. By passing the raw slot index to ntb_db_event(), it effectively assumes that doorbell 0 maps to vector 1. However, because the host uses a legacy slot layout and writes doorbell 0 into the third slot, doorbell 0 ultimately appears as vector 2 from the NTB core perspective. Adjust pci-epf-vntb to: - skip the unused second slot, and - report doorbells as 0-based vectors (DB#0 -> vector 0). This change does not introduce a behavioral difference until .db_vector_count()/.db_vector_mask() are implemented, because without those callbacks NTB clients effectively ignore the vector number. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Koichiro Den <den@valinux.co.jp> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260513024923.451765-4-den@valinux.co.jp
2026-06-22PCI: endpoint: pci-epf-vntb: Defer pci_epc_raise_irq() out of atomic contextKoichiro Den1-27/+85
The NTB .peer_db_set() callback may be invoked from atomic context. pci-epf-vntb currently calls pci_epc_raise_irq() directly, but pci_epc_raise_irq() may sleep (it takes epc->lock). Avoid sleeping in atomic context by coalescing doorbell bits into an atomic64 pending mask and raising MSIs from a work item. Limit the amount of work per run to avoid monopolizing the workqueue under a doorbell storm. Clear stale pending bits before enabling the work item and after disabling it during cleanup. Also mask requested doorbells against the currently valid doorbell mask before queueing work, and iterate the pending u64 with __ffs64() so high doorbell bits are handled correctly. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Koichiro Den <den@valinux.co.jp> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260513024923.451765-3-den@valinux.co.jp
2026-06-22PCI: endpoint: pci-epf-vntb: Document legacy MSI doorbell offsetKoichiro Den1-0/+19
vntb_epf_peer_db_set() raises an MSI interrupt to notify the RC side of a doorbell event. pci_epc_raise_irq(..., PCI_IRQ_MSI, interrupt_num) takes a 1-based MSI interrupt number. The ntb_hw_epf driver reserves MSI #1 for link events, so doorbells would naturally start at MSI #2 (doorbell bit 0 -> MSI #2). However, pci-epf-vntb has historically applied an extra offset and mapped doorbell bit 0 to MSI #3. This matches the legacy behavior of ntb_hw_epf and has been preserved since commit e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP"). This offset has not surfaced as a functional issue because: - ntb_hw_epf typically allocates enough MSI vectors, so the off-by-one still hits a valid MSI vector, and - ntb_hw_epf does not implement .db_vector_count()/.db_vector_mask(), so client drivers such as ntb_transport effectively ignore the vector number and schedule all QPs. Correcting the MSI number would break interoperability with peers running older kernels. Document the legacy offset to avoid confusion when enabling per-db-vector handling. Signed-off-by: Koichiro Den <den@valinux.co.jp> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260513024923.451765-2-den@valinux.co.jp
2026-06-22PCI: endpoint: pci-epf-ntb: Add check to detect 'db_count' value of 0Manivannan Sadhasivam1-10/+11
epf_ntb->db_count value should be within 1 to MAX_DB_COUNT. Current code only checks for the upper bound, while the lower bound is unchecked. This can cause a lot of issues in the driver if the user passes 'db_count' as 0. Add a check for 0 also. While at it, remove the redundant 'db_count' variable from epf_ntb_configure_interrupt(). Fixes: 8b821cf76150 ("PCI: endpoint: Add EP function driver to provide NTB functionality") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260407124421.282766-3-mani@kernel.org
2026-06-22PCI: endpoint: pci-epf-vntb: Add check to detect 'db_count' value of 0Manivannan Sadhasivam1-6/+3
epf_ntb->db_count value should be within 1 to MAX_DB_COUNT. Current code only checks for the upper bound, while the lower bound is unchecked. This can cause a lot of issues in the driver if the user passes 'db_count' as 0. Add a check for 0 also. While at it, remove the redundant 'db_count' assignment. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Koichiro Den <den@valinux.co.jp> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260407124421.282766-2-mani@kernel.org
2026-06-22rbd: switch to dynamic root deviceJohan Hovold1-16/+7
Driver core expects devices to be dynamically allocated and will, for example, complain loudly when no release function has been provided. Use root_device_register() to allocate and register the root device instead of open coding using a static device. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2026-06-22NTB: epf: Avoid calling pci_irq_vector() from hardirq contextKoichiro Den1-1/+3
ntb_epf_vec_isr() calls pci_irq_vector() in hardirq context to derive the vector number. pci_irq_vector() calls msi_get_virq() that takes a mutex and can therefore trigger "scheduling while atomic" splats: BUG: scheduling while atomic: kworker/u33:0/55/0x00010001 ... Call trace: ... schedule+0x38/0x110 schedule_preempt_disabled+0x28/0x50 __mutex_lock.constprop.0+0x848/0x908 __mutex_lock_slowpath+0x18/0x30 mutex_lock+0x4c/0x60 msi_domain_get_virq+0xe8/0x138 pci_irq_vector+0x2c/0x60 ntb_epf_vec_isr+0x28/0x120 [ntb_hw_epf] __handle_irq_event_percpu+0x70/0x3a8 handle_irq_event+0x48/0x100 handle_edge_irq+0x100/0x1c8 ... Cache the Linux IRQ number for vector 0 when vectors are allocated and use it as a base in the ISR. Running the ISR in a threaded IRQ handler would also avoid the problem, but that would be unnecessary here. Fixes: 812ce2f8d14e ("NTB: Add support for EPF PCI Non-Transparent Bridge") Signed-off-by: Koichiro Den <den@valinux.co.jp> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Cc: stable@vger.kernel.org # v5.12+ Link: https://patch.msgid.link/20260304083028.1391068-3-den@valinux.co.jp
2026-06-22NTB: epf: Fix request_irq() unwind in ntb_epf_init_isr()Koichiro Den1-6/+4
ntb_epf_init_isr() requests multiple MSI/MSI-X vectors in a loop. If request_irq() fails part-way through, it jumps straight to pci_free_irq_vectors() without freeing already requested IRQs. Fix the error path by freeing any successfully requested IRQs before releasing the vectors. Fixes: 812ce2f8d14e ("NTB: Add support for EPF PCI Non-Transparent Bridge") Signed-off-by: Koichiro Den <den@valinux.co.jp> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Cc: stable@vger.kernel.org # v5.12+ Link: https://patch.msgid.link/20260304083028.1391068-2-den@valinux.co.jp
2026-06-22misc: pci_endpoint_test: Remove dead BAR read before doorbell triggerCarlos Bilbao1-1/+0
The assignment before the writel sequence is dead code (bar is unconditionally overwritten by the re-read immediately after) so remove the assignment entirely. Note that the DB_BAR register is a plain value written by the endpoint firmware; reading it carries no side effect. Signed-off-by: Carlos Bilbao (Lambda) <carlos.bilbao@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Koichiro Den <den@valinux.co.jp> Link: https://patch.msgid.link/20260410230300.135631-3-carlos.bilbao@kernel.org
2026-06-22misc: pci_endpoint_test: Validate BAR index in doorbell testCarlos Bilbao1-0/+5
pci_endpoint_test_doorbell() reads the BAR number directly from an endpoint test register and uses it as an index into test->bar[]. Add a defensive bounds check before the dereference: positive values >= PCI_STD_NUM_BARS are out of range, and NO_BAR (-1) as a negative signed value would slip past an upper-bound-only check. Signed-off-by: Carlos Bilbao (Lambda) <carlos.bilbao@kernel.org> [mani: changed errno to -ERANGE] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260410230300.135631-2-carlos.bilbao@kernel.org
2026-06-22Merge tag 'staging-7.2-rc1' of ↵Linus Torvalds129-2809/+1552
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging driver updates from Greg KH: "Here is the big set of staging driver updates for 7.2-rc1. Nothing major in here, just constant grind of tiny cleanups and coding style fixes and wrapper removals. Overall more code was removed than added, always a nice sign that things are progressing forward. Changes outside of drivers/staging/ was due to the octeon driver changes, which for some reason also lives partially in the mips subsystem, someday that all will be untangled and cleaned up, or just removed entirely, it's hard to tell which is going to be its fate. Other than octeon driver cleanups, in here are the usual: - rtl8723bs driver reworking and cleanups, being the bulk of this merge window given all of the issues and wrappers involved in that beast of a driver - most driver cleanups - sm750fb driver cleanups (which might be done, as this really should be moved to the drm layer one of these days...) - other tiny staging driver cleanups and fixes All of these have been in linux-next for many weeks with no reported issues" * tag 'staging-7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (199 commits) staging: most: video: avoid double free on video register failure staging: sm750: rename CamelCase variable Bpp to bpp staging: rtl8723bs: delete superfluous switch statement staging: sm750fb: Mark g_noaccel, g_nomtrr and g_dualview as __ro_after_init staging: rtl8723bs: propagate errno through hal xmit path staging: rtl8723bs: propagate errno through xmit enqueue path staging: rtl8723bs: convert rtw_xmit_classifier to return errno staging: rtl8723bs: make rtw_xmit_classifier static staging: rtl8723bs: simplify rtw_xmit_classifier control flow staging: rtl8723bs: make _rtw_enqueue_cmd return 0 on success staging: rtl8723bs: simplify rtw_enqueue_cmd control flow staging: rtl8723bs: make _rtw_enqueue_cmd static staging: rtl8723bs: simplify _rtw_enqueue_cmd control flow staging: rtl8723bs: fix multiple blank lines in more hal/ files staging: rtl8723bs: remove unused TXDESC_64_BYTES code staging: rtl8723bs: remove unused DBG_XMIT_BUF and DBG_XMIT_BUF_EXT code staging: rtl8723bs: fix multiple blank lines in hal/Hal* files staging: rtl8723bs: fix multiple blank lines in hal/ files staging: rtl8723bs: rtw_mlme: add blank line for readability staging: rtl8723bs: rtw_mlme: wrap rtw_sitesurvey_cmd condition ...
2026-06-22drm/xe/rtp: Ensure locking/ref counting for OA whitelistsAshutosh Dixit2-0/+12
Since multiple OA streams might be open in parallel on a gt, ensure that proper locking is in place. Also ensure that OA registers are whitelisted when the first OA stream is open and de-whitelisted after the last OA stream is closed. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260615224227.34880-10-ashutosh.dixit@intel.com
2026-06-22drm/xe/oa: (De-)whitelist OA registers on OA stream open/releaseAshutosh Dixit1-0/+7
Whitelist OA registers on stream open and de-whitelist on stream close/release. Whitelisting is only done when 'stream->sample' is true. 'stream->sample' is only true when (a) xe_observation_paranoid is set to false by system admin, or (b) the process is perfmon_capable(). This therefore enforces the OA register whitelisting security requirements. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260615224227.34880-9-ashutosh.dixit@intel.com
2026-06-22drm/xe/rtp: (De-)whitelist OA registers for all hwe's for a gtAshutosh Dixit2-1/+35
Whitelist or de-whitelist OA registers for all hwe's on the gt on which the OA stream is opened. This simplifies the case where an oa unit has 0 attached hwe's (but which monitors OA events on the associated GT). Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260615224227.34880-8-ashutosh.dixit@intel.com
2026-06-22drm/xe/rtp: Toggle 'deny' bit to (de-)whitelist OA regsAshutosh Dixit1-0/+15
Whitelist or de-whitelist OA registers by setting or resetting the 'deny' bit in OA nonpriv registers and writing new register values to HW. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260615224227.34880-7-ashutosh.dixit@intel.com
2026-06-22drm/xe/rtp: Save OA nonpriv registers to register save/restore listsAshutosh Dixit1-0/+12
Now we can save OA whitelisting nonpriv registers to register save/restore lists. OA nonpriv registers are saved to both hwe->oa_sr as well as hwe->reg_sr. During probe, resume and gt-reset flows KMD will apply hwe->reg_sr, ensuring OA registers are de-whitelisted after these events. For engine-reset, hwe->reg_sr is registered with GuC and GuC will apply these registers, ensuring OA registers are de-whitelisted after engine resets. hwe->oa_sr is used for whitelisting or de-whitelisting OA registers during OA operation, by toggling the 'deny' bit on oa stream open/close. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260615224227.34880-6-ashutosh.dixit@intel.com
2026-06-22drm/xe/rtp: Generalize whitelist_apply_to_hweAshutosh Dixit1-5/+6
Generalize whitelist_apply_to_hwe to construct both non-OA and OA whitelist nonpriv registers. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260615224227.34880-5-ashutosh.dixit@intel.com
2026-06-22drm/xe/rtp: Keep track of non-OA nonpriv slotsAshutosh Dixit1-2/+5
In order to dynamically whitelist/dewhitelist OA registers on OA stream open/close, we need to keep track of nonpriv slots occupied by non-OA register whitelists. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260615224227.34880-4-ashutosh.dixit@intel.com
2026-06-22drm/xe/rtp: Maintain OA whitelists separatelyAshutosh Dixit4-1/+18
OA registers are dynamically whitelisted (and again dewhitelisted) on OA stream open/close. Maintaining OA whitelists separately from non-OA register whitlists simplifies this management of OA register whitelisting/dewhitelisting. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260615224227.34880-3-ashutosh.dixit@intel.com
2026-06-22drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelistsAshutosh Dixit1-3/+5
Unconditionally whitelisting OA registers is a security violation. Set RING_FORCE_TO_NONPRIV_DENY bit in OA nonpriv slots, so that OA registers don't get whitelisted by default after probe, gt reset, resume and engine reset. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Suggested-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260615224227.34880-2-ashutosh.dixit@intel.com
2026-06-22Merge tag 'char-misc-7.2-rc1' of ↵Linus Torvalds465-7791/+16989
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull misc driver updates from Greg KH: "Here is the big set of char, misc, iio, fpga, and other small driver subsystems changes for 7.2-rc1. Lots of little stuff in here, the majority being of course the IIO driver updates, as a list they are: - IIO driver updates and additions - GPIB driver bugfixes and cleanups - Android binder driver updates (rust and C version) - counter driver updates - MHI driver updates - mei driver updates - w1 driver updates - interconnect driver updates - Comedi driver fixes and updates - some obsolete char drivers removed (applicom and dtlk) - hwtracing driver updates - other tiny driver updates All of these have been in linux-next for a while with no reported issues" * tag 'char-misc-7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (406 commits) w1: ds2482: Use named initializers for arrays of i2c_device_data firmware: stratix10-svc: Add support to query Arm Trusted Firmware (ATF) version firmware: stratix10-rsu: avoid blocking reboot_image sysfs when busy coresight: ultrasoc-smb: Fix OOB write in smb_sync_perf_buffer() iio: adc: nxp-sar-adc: harden buffer ISR against per-channel read failure iio: chemical: scd30: Replace manual locking with RAII locking iio: light: tsl2591: remove unneeded tsl2591_compatible_als_persist_cycle() iio: dac: ad5686: create bus ops struct iio: dac: ad5686: cleanup doc header of local structs iio: dac: ad5686: add control_sync() for single-channel devices iio: dac: ad5686: add helpers to handle powerdown masks iio: dac: ad5686: add of_match table to the spi driver iio: dac: ad5686: drop enum id iio: dac: ad5686: remove redundant register definition iio: dac: ad5686: refactor include headers iio: adc: ad4080: fix AD4880 chip ID iio: light: veml3328: add support for new device dt-bindings: iio: light: veml6030: add veml3328 fpga: microchip-spi: fix zero header_size OOB read in mpf_ops_parse_header() fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region() ...
2026-06-22Merge tag 'usb-7.2-rc1' of ↵Linus Torvalds156-1921/+5056
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB and Thunderbolt driver updates from Greg KH: "Here is the big set of USB and Thunderbolt driver changes for 7.2-rc1. Lots of little stuff in here, major highlights include: - USB4STREAM support for Thunderbolt devices. A new way to send "raw" data very quickly over a USB4 connection to another system directly - Other thunderbolt updates and changes to make the stream code work - xhci driver updates and additions - typec driver updates and additions - usb gadget driver updates and fixes for reported issues - zh_CN documentation translation of the USB documentation - usb-serial driver updates - dts cleanups for some USB platforms - other minor USB driver updates and tweaks All of these have been in linux-next for over a week with no reported issues, most of them for many many weeks" * tag 'usb-7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (131 commits) usb: ucsi: huawei_gaokun: support mode switching thunderbolt: debugfs: Fix sideband write size check thunderbolt: debugfs: Fix margining error counter buffer leak usb: host: xhci-rcar: Split R-Car Gen2 and Gen3 .plat_start() handling usb: host: xhci-rcar: Remove SET_XHCI_PLAT_PRIV_FOR_RCAR() macro usb: xhci: allocate internal DCBAA mirror dynamically usb: xhci: allocate DCBAA based on host controller max slots usb: xhci: refactor DCBAA struct xhci: Prevent queuing new commands if xhci is inaccessible xhci: dbc: detect and recover hung DbC during enumeraton xhci: dbc: add timestamps to DbC state changes in a new helper. xhci: dbc: add helper to set and clear DbC DCE enable bit xhci: dbc: serialize enabling and disabling dbc xhci: dbc: Fix sysfs ABI Documentation for xhci dbc states usb: xhci: Improve Soft Retries after short transfers usb: xhci: Remove isochronous URB_SHORT_NOT_OK handling usb: xhci: Remove skip_isoc_td() usb: xhci: Simplify xhci_quiesce() usb: xhci: remove legacy 'num_trbs_free' tracking usb: xhci: fix typo in xhci_set_port_power() comment ...
2026-06-22Merge tag 'tty-7.2-rc1' of ↵Linus Torvalds35-7481/+2637
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull tty / serial driver updates from Greg KH: "Here is the big set of TTY and Serial driver updates for 7.2-rc1. Overall we end up removing more code than added, due to an obsolete synclink_gt driver being removed from the tree, always a nice thing to see happen. Other than that driver removal, major things included in here are: - max310x serial driver updates and fixes - 8250 driver updates and rework in places to make it more "modern" - dts file updates - serial driver core tweaks and updates - vt code cleanups - vc_screen crash fixes - other minor driver updates and cleanups All of these have been in linux-next for well over a week with no reported issues" * tag 'tty-7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (49 commits) serial: 8250_pci: Don't specify conflicting values to pci_device_id members vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write serial: qcom_geni: Fix RX DMA stall when SE_DMA_RX_LEN_IN is zero vt: merge ucs_is_zero_width()/ucs_is_double_width() into ucs_get_width() serial: 8250: fix possible ISR soft lockup dt-bindings: serial: rs485: remove deprecated .txt binding stub serial: qcom-geni: trace: Add tracepoint support for Qualcomm GENI serial tty: serial: Use named initializers for arrays of i2c_device_data serial: 8250_dw: remove clock-notifier infrastructure serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails amba/serial: amba-pl011: Bring back zx29 UART support serial: 8250: Add support for console flow control serial: 8250: Check LSR timeout on console flow control serial: 8250: Set cons_flow on port registration tty: serial: 8250: protect against NULL uart->port.dev in register arm64: dts: add support for A9 based Amlogic BY401 dt-bindings: arm: amlogic: add A311Y3 support serial: max310x: fix compile errors if CONFIG_SPI_MASTER is disabled serial: qcom-geni: Avoid probing debug console UART without console support serial: max310x: add comments for PLL limits ...
generated by cgit (git 2.54.0.dirty) at 2026-09-30 22:32:26 +0000