summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-03-22iio: dac: ad5770r: fix error return in ad5770r_read_raw()Antoniu Miclaus
Return the error code from regmap_bulk_read() instead of 0 so that I/O failures are properly propagated. Fixes: cbbb819837f6 ("iio: dac: ad5770r: Add AD5770R support") Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com> Cc: <stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-22iio: accel: fix ADXL355 temperature signature valueValek Andrej
Temperature was wrongly represented as 12-bit signed, confirmed by checking the datasheet. Even if the temperature is negative, the value in the register stays unsigned. Fixes: 12ed27863ea3 iio: accel: Add driver support for ADXL355 Signed-off-by: Valek Andrej <andrej.v@skyrain.eu> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-22counter: rz-mtu3-cnt: do not use struct rz_mtu3_channel's dev memberCosmin Tanislav
The counter driver can use HW channels 1 and 2, while the PWM driver can use HW channels 0, 1, 2, 3, 4, 6, 7. The dev member is assigned both by the counter driver and the PWM driver for channels 1 and 2, to their own struct device instance, overwriting the previous value. The sub-drivers race to assign their own struct device pointer to the same struct rz_mtu3_channel's dev member. The dev member of struct rz_mtu3_channel is used by the counter sub-driver for runtime PM. Depending on the probe order of the counter and PWM sub-drivers, the dev member may point to the wrong struct device instance, causing the counter sub-driver to do runtime PM actions on the wrong device. To fix this, use the parent pointer of the counter, which is assigned during probe to the correct struct device, not the struct device pointer inside the shared struct rz_mtu3_channel. Cc: stable@vger.kernel.org Fixes: 0be8907359df ("counter: Add Renesas RZ/G2L MTU3a counter driver") Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com> Link: https://lore.kernel.org/r/20260130122353.2263273-6-cosmin-gabriel.tanislav.xa@renesas.com Signed-off-by: William Breathitt Gray <wbg@kernel.org>
2026-03-22counter: rz-mtu3-cnt: prevent counter from being toggled multiple timesCosmin Tanislav
Runtime PM counter is incremented / decremented each time the sysfs enable file is written to. If user writes 0 to the sysfs enable file multiple times, runtime PM usage count underflows, generating the following message. rz-mtu3-counter rz-mtu3-counter.0: Runtime PM usage count underflow! At the same time, hardware registers end up being accessed with clocks off in rz_mtu3_terminate_counter() to disable an already disabled channel. If user writes 1 to the sysfs enable file multiple times, runtime PM usage count will be incremented each time, requiring the same number of 0 writes to get it back to 0. If user writes 0 to the sysfs enable file while PWM is in progress, PWM is stopped without counter being the owner of the underlying MTU3 channel. Check against the cached count_is_enabled value and exit if the user is trying to set the same enable value. Cc: stable@vger.kernel.org Fixes: 0be8907359df ("counter: Add Renesas RZ/G2L MTU3a counter driver") Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com> Link: https://lore.kernel.org/r/20260130122353.2263273-5-cosmin-gabriel.tanislav.xa@renesas.com Signed-off-by: William Breathitt Gray <wbg@kernel.org>
2026-03-21zram: do not slot_free() written-back slotsSergey Senozhatsky
slot_free() basically completely resets the slots by clearing all of its flags and attributes. While zram_writeback_complete() restores some of flags back (those that are necessary for async read decompression) we still lose a lot of slot's metadata. For example, slot's ac-time, or ZRAM_INCOMPRESSIBLE. More importantly, restoring flags/attrs requires extra attention as some of the flags are directly affecting zram device stats. And the original code did not pay that attention. Namely ZRAM_HUGE slots handling in zram_writeback_complete(). The call to slot_free() would decrement ->huge_pages, however when zram_writeback_complete() restored the slot's ZRAM_HUGE flag, it would not get reflected in an incremented ->huge_pages. So when the slot would finally get freed, slot_free() would decrement ->huge_pages again, leading to underflow. Fix this by open-coding the required memory free and stats updates in zram_writeback_complete(), rather than calling the destructive slot_free(). Since we now preserve the ZRAM_HUGE flag on written-back slots (for the deferred decompression path), we also update slot_free() to skip decrementing ->huge_pages if ZRAM_WB is set. Link: https://lkml.kernel.org/r/20260320023143.2372879-1-senozhatsky@chromium.org Link: https://lkml.kernel.org/r/20260319034912.1894770-1-senozhatsky@chromium.org Fixes: d38fab605c667 ("zram: introduce compressed data writeback") Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org> Acked-by: Minchan Kim <minchan@kernel.org> Cc: Brian Geffon <bgeffon@google.com> Cc: Richard Chang <richardycc@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-03-21Merge tag 'driver-core-7.0-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core Pull driver core fixes from Danilo Krummrich: - Generalize driver_override in the driver core, providing a common sysfs implementation and concurrency-safe accessors for bus implementations - Do not use driver_override as IRQ name in the hwmon axi-fan driver - Remove an unnecessary driver_override check in sh platform_early - Migrate the platform bus to use the generic driver_override infrastructure, fixing a UAF condition caused by accessing the driver_override field without proper locking in the platform_match() callback * tag 'driver-core-7.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core: driver core: platform: use generic driver_override infrastructure sh: platform_early: remove pdev->driver_override check hwmon: axi-fan: don't use driver_override as IRQ name docs: driver-model: document driver_override driver core: generalize driver_override in struct device
2026-03-21iio: light: vcnl4035: fix scan buffer on big-endianDavid Lechner
Rework vcnl4035_trigger_consumer_handler() so that we are not passing what should be a u16 value as an int * to regmap_read(). This won't work on bit endian systems. Instead, add a new unsigned int variable to pass to regmap_read(). Then copy that value into the buffer struct. The buffer array is replaced with a struct since there is only one value being read. This allows us to use the correct u16 data type and has a side-effect of simplifying the alignment specification. Also fix the endianness of the scan format from little-endian to CPU endianness. Since we are using regmap to read the value, it will be CPU-endian. Fixes: 55707294c4eb ("iio: light: Add support for vishay vcnl4035") Signed-off-by: David Lechner <dlechner@baylibre.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-21iio: adc: ti-adc161s626: use DMA-safe memory for spi_read()David Lechner
Add a DMA-safe buffer and use it for spi_read() instead of a stack memory. All SPI buffers must be DMA-safe. Since we only need up to 3 bytes, we just use a u8[] instead of __be16 and __be32 and change the conversion functions appropriately. Fixes: 4d671b71beef ("iio: adc: ti-adc161s626: add support for TI 1-channel differential ADCs") Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-21iio: adc: ti-adc161s626: fix buffer read on big-endianDavid Lechner
Rework ti_adc_trigger_handler() to properly handle data on big-endian architectures. The scan data format is 16-bit CPU-endian, so we can't cast it to a int * on big-endian and expect it to work. Instead, we introduce a local int variable to read the data into, and then copy it to the buffer. Since the buffer isn't passed to any SPI functions, we don't need it to be DMA-safe. So we can drop it from the driver data struct and just use stack memory for the scan data. Since there is only one data value (plus timestamp), we don't need an array and can just declare a struct with the correct data type instead. Also fix alignment of iio_get_time_ns() to ( while we are touching this. Fixes: 4d671b71beef ("iio: adc: ti-adc161s626: add support for TI 1-channel differential ADCs") Signed-off-by: David Lechner <dlechner@baylibre.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-21Merge tag 'hwmon-for-v7.0-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: - max6639: Fix pulses-per-revolution implementation - Several PMBus drivers: Add missing error checks * tag 'hwmon-for-v7.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (max6639) Fix pulses-per-revolution implementation hwmon: (pmbus/isl68137) Fix unchecked return value and use sysfs_emit() hwmon: (pmbus/ina233) Add error check for pmbus_read_word_data() return value hwmon: (pmbus/mp2869) Check pmbus_read_byte_data() before using its return value hwmon: (pmbus/mp2975) Add error check for pmbus_read_word_data() return value hwmon: (pmbus/hac300s) Add error check for pmbus_read_word_data() return value
2026-03-20virt: tdx-guest: Fix handling of host controlled 'quote' buffer lengthZubin Mithra
Validate host controlled value `quote_buf->out_len` that determines how many bytes of the quote are copied out to guest userspace. In TDX environments with remote attestation, quotes are not considered private, and can be forwarded to an attestation server. Catch scenarios where the host specifies a response length larger than the guest's allocation, or otherwise races modifying the response while the guest consumes it. This prevents contents beyond the pages allocated for `quote_buf` (up to TSM_REPORT_OUTBLOB_MAX) from being read out to guest userspace, and possibly forwarded in attestation requests. Recall that some deployments want per-container configs-tsm-report interfaces, so the leak may cross container protection boundaries, not just local root. Fixes: f4738f56d1dc ("virt: tdx-guest: Add Quote generation support using TSM_REPORTS") Cc: stable@vger.kernel.org Signed-off-by: Zubin Mithra <zsm@google.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2026-03-20net: bcmasp: fix double disable of clkJustin Chen
Switch to devm_clk_get_optional() so we can manage the clock ourselves. We dynamically control the clocks depending on the state of the interface for power savings. The default state is clock disabled, so unbinding the driver causes a double disable. Fixes: 490cb412007d ("net: bcmasp: Add support for ASP2.0 Ethernet controller") Signed-off-by: Justin Chen <justin.chen@broadcom.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20260319234813.1937315-3-justin.chen@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-20net: bcmasp: fix double free of WoL irqJustin Chen
We do not need to free wol_irq since it was instantiated with devm_request_irq(). So devres will free for us. Fixes: a2f0751206b0 ("net: bcmasp: Add support for WoL magic packet") Signed-off-by: Justin Chen <justin.chen@broadcom.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20260319234813.1937315-2-justin.chen@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-20net: macb: Protect access to net_device::ip_ptr with RCU lockKevin Hao
Access to net_device::ip_ptr and its associated members must be protected by an RCU lock. Since we are modifying this piece of code, let's also move it to execute only when WAKE_ARP is enabled. To minimize the duration of the RCU lock, a local variable is used to temporarily store the IP address. This change resolves the following RCU check warning: WARNING: suspicious RCU usage 7.0.0-rc3-next-20260310-yocto-standard+ #122 Not tainted ----------------------------- drivers/net/ethernet/cadence/macb_main.c:5944 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 5 locks held by rtcwake/518: #0: ffff000803ab1408 (sb_writers#5){.+.+}-{0:0}, at: vfs_write+0xf8/0x368 #1: ffff0008090bf088 (&of->mutex#2){+.+.}-{4:4}, at: kernfs_fop_write_iter+0xbc/0x1c8 #2: ffff00080098d588 (kn->active#70){.+.+}-{0:0}, at: kernfs_fop_write_iter+0xcc/0x1c8 #3: ffff800081c84888 (system_transition_mutex){+.+.}-{4:4}, at: pm_suspend+0x1ec/0x290 #4: ffff0008009ba0f8 (&dev->mutex){....}-{4:4}, at: device_suspend+0x118/0x4f0 stack backtrace: CPU: 3 UID: 0 PID: 518 Comm: rtcwake Not tainted 7.0.0-rc3-next-20260310-yocto-standard+ #122 PREEMPT Hardware name: ZynqMP ZCU102 Rev1.1 (DT) Call trace: show_stack+0x24/0x38 (C) __dump_stack+0x28/0x38 dump_stack_lvl+0x64/0x88 dump_stack+0x18/0x24 lockdep_rcu_suspicious+0x134/0x1d8 macb_suspend+0xd8/0x4c0 device_suspend+0x218/0x4f0 dpm_suspend+0x244/0x3a0 dpm_suspend_start+0x50/0x78 suspend_devices_and_enter+0xec/0x560 pm_suspend+0x194/0x290 state_store+0x110/0x158 kobj_attr_store+0x1c/0x30 sysfs_kf_write+0xa8/0xd0 kernfs_fop_write_iter+0x11c/0x1c8 vfs_write+0x248/0x368 ksys_write+0x7c/0xf8 __arm64_sys_write+0x28/0x40 invoke_syscall+0x4c/0xe8 el0_svc_common+0x98/0xf0 do_el0_svc+0x28/0x40 el0_svc+0x54/0x1e0 el0t_64_sync_handler+0x84/0x130 el0t_64_sync+0x198/0x1a0 Fixes: 0cb8de39a776 ("net: macb: Add ARP support to WOL") Signed-off-by: Kevin Hao <haokexin@gmail.com> Cc: stable@vger.kernel.org Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com> Link: https://patch.msgid.link/20260318-macb-irq-v2-2-f1179768ab24@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-20net: macb: Move devm_{free,request}_irq() out of spin lock areaKevin Hao
The devm_free_irq() and devm_request_irq() functions should not be executed in an atomic context. During device suspend, all userspace processes and most kernel threads are frozen. Additionally, we flush all tx/rx status, disable all macb interrupts, and halt rx operations. Therefore, it is safe to split the region protected by bp->lock into two independent sections, allowing devm_free_irq() and devm_request_irq() to run in a non-atomic context. This modification resolves the following lockdep warning: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 501, name: rtcwake preempt_count: 1, expected: 0 RCU nest depth: 1, expected: 0 7 locks held by rtcwake/501: #0: ffff0008038c3408 (sb_writers#5){.+.+}-{0:0}, at: vfs_write+0xf8/0x368 #1: ffff0008049a5e88 (&of->mutex#2){+.+.}-{4:4}, at: kernfs_fop_write_iter+0xbc/0x1c8 #2: ffff00080098d588 (kn->active#70){.+.+}-{0:0}, at: kernfs_fop_write_iter+0xcc/0x1c8 #3: ffff800081c84888 (system_transition_mutex){+.+.}-{4:4}, at: pm_suspend+0x1ec/0x290 #4: ffff0008009ba0f8 (&dev->mutex){....}-{4:4}, at: device_suspend+0x118/0x4f0 #5: ffff800081d00458 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire+0x4/0x48 #6: ffff0008031fb9e0 (&bp->lock){-.-.}-{3:3}, at: macb_suspend+0x144/0x558 irq event stamp: 8682 hardirqs last enabled at (8681): [<ffff8000813c7d7c>] _raw_spin_unlock_irqrestore+0x44/0x88 hardirqs last disabled at (8682): [<ffff8000813c7b58>] _raw_spin_lock_irqsave+0x38/0x98 softirqs last enabled at (7322): [<ffff8000800f1b4c>] handle_softirqs+0x52c/0x588 softirqs last disabled at (7317): [<ffff800080010310>] __do_softirq+0x20/0x2c CPU: 1 UID: 0 PID: 501 Comm: rtcwake Not tainted 7.0.0-rc3-next-20260310-yocto-standard+ #125 PREEMPT Hardware name: ZynqMP ZCU102 Rev1.1 (DT) Call trace: show_stack+0x24/0x38 (C) __dump_stack+0x28/0x38 dump_stack_lvl+0x64/0x88 dump_stack+0x18/0x24 __might_resched+0x200/0x218 __might_sleep+0x38/0x98 __mutex_lock_common+0x7c/0x1378 mutex_lock_nested+0x38/0x50 free_irq+0x68/0x2b0 devm_irq_release+0x24/0x38 devres_release+0x40/0x80 devm_free_irq+0x48/0x88 macb_suspend+0x298/0x558 device_suspend+0x218/0x4f0 dpm_suspend+0x244/0x3a0 dpm_suspend_start+0x50/0x78 suspend_devices_and_enter+0xec/0x560 pm_suspend+0x194/0x290 state_store+0x110/0x158 kobj_attr_store+0x1c/0x30 sysfs_kf_write+0xa8/0xd0 kernfs_fop_write_iter+0x11c/0x1c8 vfs_write+0x248/0x368 ksys_write+0x7c/0xf8 __arm64_sys_write+0x28/0x40 invoke_syscall+0x4c/0xe8 el0_svc_common+0x98/0xf0 do_el0_svc+0x28/0x40 el0_svc+0x54/0x1e0 el0t_64_sync_handler+0x84/0x130 el0t_64_sync+0x198/0x1a0 Fixes: 558e35ccfe95 ("net: macb: WoL support for GEM type of Ethernet controller") Cc: stable@vger.kernel.org Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com> Signed-off-by: Kevin Hao <haokexin@gmail.com> Link: https://patch.msgid.link/20260318-macb-irq-v2-1-f1179768ab24@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-20Merge tag 'drm-fixes-2026-03-21' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "Regular weekly pull request, from sunny San Diego. Usual suspects in xe/i915/amdgpu with small fixes all over, then some minor fixes across a few other drivers. It's probably a bit on the heavy side, but most of the fix seem well contained, core: - drm_dev_unplug UAF fix pagemap: - lock handling fix xe: - A number of teardown fixes - Skip over non-leaf PTE for PRL generation - Fix an uninitialized variable - Fix a missing runtime PM reference i915/display: - Fix #15771: Screen corruption and stuttering on P14s w/ 3K display - Fix for PSR entry setup frames count on rejected commit - Fix OOPS if firmware is not loaded and suspend is attempted - Fix unlikely NULL deref due to DC6 on probe amdgpu: - Fix gamma 2.2 colorop TFs - BO list fix - LTO fix - DC FP fix - DisplayID handling fix - DCN 2.01 fix - MMHUB boundary fixes - ISP fix - TLB fence fix - Hainan pm fix radeon: - Hainan pm fix vmwgfx: - memory leak fix - doc warning fix imagination: - deadlock fix - interrupt handling fixes dw-hdmi-qp: - multi channel audio fix" * tag 'drm-fixes-2026-03-21' of https://gitlab.freedesktop.org/drm/kernel: (40 commits) drm/xe: Fix missing runtime PM reference in ccs_mode_store drm/xe: Open-code GGTT MMIO access protection drm/xe/lrc: Fix uninitialized new_ts when capturing context timestamp drm/xe/oa: Allow reading after disabling OA stream drm/xe: Skip over non leaf pte for PRL generation drm/xe/guc: Ensure CT state transitions via STOP before DISABLED drm/xe: Trigger queue cleanup if not in wedged mode 2 drm/xe: Forcefully tear down exec queues in GuC submit fini drm/xe: Always kill exec queues in xe_guc_submit_pause_abort drm/xe/guc: Fail immediately on GuC load error drm/i915/gt: Check set_default_submission() before deferencing drm/radeon: apply state adjust rules to some additional HAINAN vairants drm/amdgpu: apply state adjust rules to some additional HAINAN vairants drm/amdgpu: rework how we handle TLB fences drm/bridge: dw-hdmi-qp: fix multi-channel audio output drm: Fix use-after-free on framebuffers and property blobs when calling drm_dev_unplug drm/amdgpu: Fix ISP segfault issue in kernel v7.0 drm/amdgpu/gmc9.0: add bounds checking for cid drm/amdgpu/mmhub4.2.0: add bounds checking for cid drm/amdgpu/mmhub4.1.0: add bounds checking for cid ...
2026-03-20hwmon: (max6639) Fix pulses-per-revolution implementationGuenter Roeck
The valid range for the pulses-per-revolution devicetree property is 1..4. The current code checks for a range of 1..5. Fix it. Declare the variable used to retrieve pulses per revolution from devicetree as u32 (unsigned) to match the of_property_read_u32() API. The current code uses a postfix decrement when writing the pulses per resolution into the chip. This has no effect since the value is evaluated before it is decremented. Fix it by decrementing before evaluating the value. Fixes: 7506ebcd662b ("hwmon: (max6639) : Configure based on DT property") Cc: Naresh Solanki <naresh.solanki@9elements.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-03-20Merge tag 'tty-7.0-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull tty/serial fixes from Greg KH: "Here are some small tty/vt and serial driver fixes for 7.0-rc5. Included in here are: - 8250 driver fixes for reported problems - serial core lockup fix - uartlite driver bugfix - vt save/restore bugfix All of these have been in linux-next for over a week with no reported problems" * tag 'tty-7.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: vt: save/restore unicode screen buffer for alternate screen serial: 8250_dw: Ensure BUSY is deasserted serial: 8250: Add late synchronize_irq() to shutdown to handle DW UART BUSY serial: 8250_dw: Rework IIR_NO_INT handling to stop interrupt storm serial: 8250_dw: Rework dw8250_handle_irq() locking and IIR handling serial: 8250: Add serial8250_handle_irq_locked() serial: 8250_dw: Avoid unnecessary LCR writes serial: 8250: Protect LCR write in shutdown serial: 8250_pci: add support for the AX99100 serial: core: fix infinite loop in handle_tx() for PORT_UNKNOWN serial: uartlite: fix PM runtime usage count underflow on probe serial: 8250: always disable IRQ during THRE test serial: 8250: Fix TX deadlock when using DMA
2026-03-20Merge tag 'spi-fix-v7.0-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "There's a couple of core fixes here from Johan, fixing a race condition and an error handling path, plus a bunch of driver specific fixups. The Qualcomm issues could be nasty if you ran into them, especially the DMA ordering one" * tag 'spi-fix-v7.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: geni-qcom: Check DMA interrupts early in ISR spi: fix statistics allocation spi: fix use-after-free on controller registration failure spi: geni-qcom: Fix CPHA and CPOL mode change detection spi: axiado: Fix double-free in ax_spi_probe() spi: amlogic-spisg: Fix memory leak in aml_spisg_probe() spi: amlogic: spifc-a4: Remove redundant clock cleanup
2026-03-20Merge tag 'pmdomain-v7.0-rc1-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm Pull pmdomain fixes from Ulf Hansson: - bcm: increase ASB control timeout for bcm2835 - mediatek: fix power domain count * tag 'pmdomain-v7.0-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm: pmdomain: bcm: bcm2835-power: Increase ASB control timeout pmdomain: mediatek: Fix power domain count
2026-03-20Merge tag 'mmc-v7.0-rc1-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull MMC fixes from Ulf Hansson: - sdhci: Fix timing selection for 1-bit bus width - sdhci-pci-gli: Fix DMA write corruption for GL9750 * tag 'mmc-v7.0-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: sdhci: fix timing selection for 1-bit bus width mmc: sdhci-pci-gli: fix GL9750 DMA write corruption
2026-03-20Merge tag 'ata-7.0-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux Pull ata fixes from Niklas Cassel: - ADATA SU680 SSDs are causing command timeouts when LPM is enabled. Enable the ATA_QUIRK_NOLPM quirk to prevent LPM from being enabled on these devices (Damien) - When receiving a REPORT SUPPORTED OPERATION CODES command with an invalid REPORTING OPTIONS format, sense data should have the field pointer set to byte 2 (the location of the REPORTING OPTIONS field) instead of incorrectly pointing to byte 1 (Damien) * tag 'ata-7.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux: ata: libata-scsi: report correct sense field pointer in ata_scsiop_maint_in() ata: libata-core: disable LPM on ADATA SU680 SSD
2026-03-20Merge tag 'mtd/fixes-for-7.0-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux Pull MTD fixes from Miquel Raynal: - In SPI NOR, there was an issue with the RDCR capability, leading to several platforms no longer capable of using it for wrong reasons (the follow-up commit renames the helper to avoid future confusion) - NAND controller drivers needed to be improved to fix some timings, a locking schenario and avoid certain operations during panic writes - The Spear600 DT binding conversion was done partially, leading to several warnings which have individually been fixed - Tudor gets replaced by Takahiro for the SPI NOR maintainance - Plus two more misc fixes * tag 'mtd/fixes-for-7.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: mtd: rawnand: pl353: make sure optimal timings are applied mtd: spi-nor: Rename spi_nor_spimem_check_op() mtd: spi-nor: Fix RDCR controller capability core check mtd: rawnand: brcmnand: skip DMA during panic write mtd: rawnand: serialize lock/unlock against other NAND operations dt-bindings: mtd: st,spear600-smi: Fix example dt-bindings: mtd: st,spear600-smi: #address/size-cells is mandatory dt-bindings: mtd: st,spear600-smi: Fix description mtd: rawnand: cadence: Fix error check for dma_alloc_coherent() in cadence_nand_init() mtd: Avoid boot crash in RedBoot partition table parser MAINTAINERS: add Takahiro Kuwano as SPI NOR reviewer MAINTAINERS: remove Tudor Ambarus as SPI NOR maintainer
2026-03-20Merge tag 'iommu-fixes-v7.0-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux Pull iommu fixes from Joerg Roedel: "Intel VT-d: - Abort all pending requests on dev_tlb_inv timeout to avoid hardlockup - Limit IOPF handling to PRI-capable device to avoid SVA attach failure AMD-Vi: - Make sure identity domain is not used when SNP is active Core fixes: - Handle mapping IOVA 0x0 correctly - Fix crash in SVA code - Kernel-doc fix in IO-PGTable code" * tag 'iommu-fixes-v7.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux: iommu/amd: Block identity domain when SNP enabled iommu/sva: Fix crash in iommu_sva_unbind_device() iommu/io-pgtable: fix all kernel-doc warnings in io-pgtable.h iommu: Fix mapping check for 0x0 to avoid re-mapping it iommu/vt-d: Only handle IOPF for SVA when PRI is supported iommu/vt-d: Fix intel iommu iotlb sync hardlockup and retry
2026-03-20Merge tag 'arm64-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: "There's a small crop of fixes for the MPAM resctrl driver, a fix for SCS/PAC patching with the AMDGPU driver and a page-table fix for realms running with 52-bit physical addresses: - Fix DWARF parsing for SCS/PAC patching to work with very large modules (such as the amdgpu driver) - Fixes to the mpam resctrl driver - Fix broken handling of 52-bit physical addresses when sharing memory from within a realm" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: realm: Fix PTE_NS_SHARED for 52bit PA support arm_mpam: Force __iomem casts arm_mpam: Disable preemption when making accesses to fake MSC in kunit test arm_mpam: Fix null pointer dereference when restoring bandwidth counters arm64/scs: Fix handling of advance_loc4
2026-03-20Merge tag 'hyperv-fixes-signed-20260319' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux Pull Hyper-V fixes from Wei Liu: - Fix ARM64 MSHV support (Anirudh Rayabharam) - Fix MSHV driver memory handling issues (Stanislav Kinsburskii) - Update maintainers for Hyper-V DRM driver (Saurabh Sengar) - Misc clean up in MSHV crashdump code (Ard Biesheuvel, Uros Bizjak) - Minor improvements to MSHV code (Mukesh R, Wei Liu) - Revert not yet released MSHV scrub partition hypercall (Wei Liu) * tag 'hyperv-fixes-signed-20260319' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux: mshv: Fix error handling in mshv_region_pin MAINTAINERS: Update maintainers for Hyper-V DRM driver mshv: Fix use-after-free in mshv_map_user_memory error path mshv: pass struct mshv_user_mem_region by reference x86/hyperv: Use any general-purpose register when saving %cr2 and %cr8 x86/hyperv: Use current_stack_pointer to avoid asm() in hv_hvcrash_ctxt_save() x86/hyperv: Save segment registers directly to memory in hv_hvcrash_ctxt_save() x86/hyperv: Use __naked attribute to fix stackless C function Revert "mshv: expose the scrub partition hypercall" mshv: add arm64 support for doorbell & intercept SINTs mshv: refactor synic init and cleanup x86/hyperv: print out reserved vectors in hexadecimal
2026-03-21Merge tag 'drm-xe-fixes-2026-03-19' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Driver Changes: - A number of teardown fixes (Daniele, Matt Brost, Zhanjun, Ashutosh) - Skip over non-leaf PTE for PRL generation (Brian) - Fix an unitialized variable (Umesh) - Fix a missing runtime PM reference (Sanjay) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/abxj4_dBHYBiSvDG@fedora
2026-03-21Merge tag 'amd-drm-fixes-7.0-2026-03-19' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-7.0-2026-03-19: amdgpu: - Fix gamma 2.2 colorop TFs - BO list fix - LTO fix - DC FP fix - DisplayID handling fix - DCN 2.01 fix - MMHUB boundary fixes - ISP fix - TLB fence fix - Hainan pm fix radeon: - Hainan pm fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260319131013.36639-1-alexander.deucher@amd.com
2026-03-21Merge tag 'drm-misc-fixes-2026-03-19' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes A doc warning fix and a memory leak fix for vmwgfx, a deadlock fix and interrupt handling fixes for imagination, a locking fix for pagemap_until, a UAF fix for drm_dev_unplug, and a multi-channel audio handling fix for dw-hdmi-qp. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patch.msgid.link/20260319-lush-righteous-malamute-e7bb98@houat
2026-03-20xen/privcmd: add boot control for restricted usage in domUJuergen Gross
When running in an unprivileged domU under Xen, the privcmd driver is restricted to allow only hypercalls against a target domain, for which the current domU is acting as a device model. Add a boot parameter "unrestricted" to allow all hypercalls (the hypervisor will still refuse destructive hypercalls affecting other guests). Make this new parameter effective only in case the domU wasn't started using secure boot, as otherwise hypercalls targeting the domU itself might result in violating the secure boot functionality. This is achieved by adding another lockdown reason, which can be tested to not being set when applying the "unrestricted" option. This is part of XSA-482 Signed-off-by: Juergen Gross <jgross@suse.com> --- V2: - new patch
2026-03-20RDMA/umem: Tell DMA mapping that UMEM requires coherencyLeon Romanovsky
The RDMA subsystem exposes DMA regions through the verbs interface, which assumes a coherent system. Use the DMA_ATTR_REQUIRE_COHERENCE attribute to ensure coherency and avoid taking the SWIOTLB path. The RDMA verbs programming model resembles HMM and assumes concurrent DMA and CPU access to userspace memory. The hardware and programming model support "one-sided" operations initiated remotely without any local CPU involvement or notification. These include ATOMIC compare/swap, READ, and WRITE. A remote CPU can use these operations to traverse data structures, manipulate locks, and perform similar tasks without the host CPU’s awareness. If SWIOTLB substitutes memory or DMA is not cache coherent, these use cases break entirely. In-kernel RDMA is fine with incoherent mappings because kernel users do not rely on one-sided operations in ways that would expose these issues. A given region may also be exported multiple times, which can trigger warnings about cacheline overlaps. These warnings are suppressed when the new attribute is used. infiniband rocep8s0f0: mlx5_ib_reg_user_mr:1592:(pid 5812): start 0x2b28c000, iova 0x2b28c000, length 0x1000, access_flags 0x1 infiniband rocep8s0f0: mlx5_ib_reg_user_mr:1592:(pid 5812): start 0x2b28c001, iova 0x2b28c001, length 0xfff, access_flags 0x1 ------------[ cut here ]------------ DMA-API: mlx5_core 0000:08:00.0: cacheline tracking EEXIST, overlapping mappings aren't supported WARNING: kernel/dma/debug.c:620 at add_dma_entry+0x1bb/0x280, CPU#6: ibv_rc_pingpong/5812 Modules linked in: veth xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay mlx5_fwctl zram zsmalloc mlx5_ib fuse rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_core ib_core CPU: 6 UID: 2733 PID: 5812 Comm: ibv_rc_pingpong Tainted: G W 6.19.0+ #129 PREEMPT Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:add_dma_entry+0x1be/0x280 Code: 8b 7b 10 48 85 ff 0f 84 c3 00 00 00 48 8b 6f 50 48 85 ed 75 03 48 8b 2f e8 ff 8e 6a 00 48 89 c6 48 8d 3d 55 ef 2d 01 48 89 ea <67> 48 0f b9 3a 48 85 db 74 1a 48 c7 c7 b0 00 2b 82 e8 9c 25 fd ff RSP: 0018:ff11000138717978 EFLAGS: 00010286 RAX: ffffffffa02d7831 RBX: ff1100010246de00 RCX: 0000000000000000 RDX: ff110001036fac30 RSI: ffffffffa02d7831 RDI: ffffffff82678650 RBP: ff110001036fac30 R08: ff11000110dcb4a0 R09: ff11000110dcb478 R10: 0000000000000000 R11: ffffffff824b30a8 R12: 0000000000000000 R13: 00000000ffffffef R14: 0000000000000202 R15: ff1100010246de00 FS: 00007f59b411c740(0000) GS:ff110008dcc99000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffe538f7000 CR3: 000000010e066005 CR4: 0000000000373eb0 Call Trace: <TASK> debug_dma_map_sg+0x1b4/0x390 __dma_map_sg_attrs+0x6d/0x1a0 dma_map_sgtable+0x19/0x30 ib_umem_get+0x254/0x380 [ib_uverbs] mlx5_ib_reg_user_mr+0x68/0x2a0 [mlx5_ib] ib_uverbs_reg_mr+0x17f/0x2a0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xc2/0x130 [ib_uverbs] ib_uverbs_cmd_verbs+0xa0b/0xae0 [ib_uverbs] ? ib_uverbs_handler_UVERBS_METHOD_QUERY_PORT_SPEED+0xe0/0xe0 [ib_uverbs] ? mmap_region+0x7a/0xb0 ? do_mmap+0x3b8/0x5c0 ib_uverbs_ioctl+0xa7/0x110 [ib_uverbs] __x64_sys_ioctl+0x14f/0x8b0 ? ksys_mmap_pgoff+0xc5/0x190 do_syscall_64+0x8c/0xbf0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f59b430aeed Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00 RSP: 002b:00007ffe538f9430 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffe538f94c0 RCX: 00007f59b430aeed RDX: 00007ffe538f94e0 RSI: 00000000c0181b01 RDI: 0000000000000003 RBP: 00007ffe538f9480 R08: 0000000000000028 R09: 00007ffe538f9684 R10: 0000000000000001 R11: 0000000000000246 R12: 00007ffe538f9684 R13: 000000000000000c R14: 000000002b28d170 R15: 000000000000000c </TASK> ---[ end trace 0000000000000000 ]--- Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20260316-dma-debug-overlap-v3-7-1dde90a7f08b@nvidia.com
2026-03-20iommu/dma: add support for DMA_ATTR_REQUIRE_COHERENT attributeLeon Romanovsky
Add support for the DMA_ATTR_REQUIRE_COHERENT attribute to the exported functions. This attribute indicates that the SWIOTLB path must not be used and that no sync operations should be performed. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20260316-dma-debug-overlap-v3-6-1dde90a7f08b@nvidia.com
2026-03-20xen/privcmd: restrict usage in unprivileged domUJuergen Gross
The Xen privcmd driver allows to issue arbitrary hypercalls from user space processes. This is normally no problem, as access is usually limited to root and the hypervisor will deny any hypercalls affecting other domains. In case the guest is booted using secure boot, however, the privcmd driver would be enabling a root user process to modify e.g. kernel memory contents, thus breaking the secure boot feature. The only known case where an unprivileged domU is really needing to use the privcmd driver is the case when it is acting as the device model for another guest. In this case all hypercalls issued via the privcmd driver will target that other guest. Fortunately the privcmd driver can already be locked down to allow only hypercalls targeting a specific domain, but this mode can be activated from user land only today. The target domain can be obtained from Xenstore, so when not running in dom0 restrict the privcmd driver to that target domain from the beginning, resolving the potential problem of breaking secure boot. This is XSA-482 Reported-by: Teddy Astie <teddy.astie@vates.tech> Fixes: 1c5de1939c20 ("xen: add privcmd driver") Signed-off-by: Juergen Gross <jgross@suse.com> --- V2: - defer reading from Xenstore if Xenstore isn't ready yet (Jan Beulich) - wait in open() if target domain isn't known yet - issue message in case no target domain found (Jan Beulich)
2026-03-20dma-mapping: Clarify valid conditions for CPU cache line overlapLeon Romanovsky
Rename the DMA_ATTR_CPU_CACHE_CLEAN attribute to better reflect that it is debugging aid to inform DMA core code that CPU cache line overlaps are allowed, and refine the documentation describing its use. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20260316-dma-debug-overlap-v3-3-1dde90a7f08b@nvidia.com
2026-03-20ata: libata-scsi: report correct sense field pointer in ata_scsiop_maint_in()Damien Le Moal
Commit 4ab7bb976343 ("ata: libata-scsi: Refactor ata_scsiop_maint_in()") modified ata_scsiop_maint_in() to directly call ata_scsi_set_invalid_field() to set the field pointer of the sense data of a failed MAINTENANCE IN command. However, in the case of an invalid command format, the sense data field incorrectly indicates byte 1 of the CDB. Fix this to indicate byte 2 of the command. Reported-by: Guenter Roeck <linux@roeck-us.net> Fixes: 4ab7bb976343 ("ata: libata-scsi: Refactor ata_scsiop_maint_in()") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org>
2026-03-20drm/shmem-helper: Fix huge page mapping in fault handlerPedro Demarchi Gomes
When running ./tools/testing/selftests/mm/split_huge_page_test multiple times with /sys/kernel/mm/transparent_hugepage/shmem_enabled and /sys/kernel/mm/transparent_hugepage/enabled set as always the following BUG occurs: [ 232.728858] ------------[ cut here ]------------ [ 232.729458] kernel BUG at mm/memory.c:2276! [ 232.729726] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI [ 232.730217] CPU: 19 UID: 60578 PID: 1497 Comm: llvmpipe-9 Not tainted 7.0.0-rc1mm-new+ #19 PREEMPT(lazy) [ 232.730855] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-9.fc43 06/10/2025 [ 232.731360] RIP: 0010:walk_to_pmd+0x29e/0x3c0 [ 232.731569] Code: d8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 89 ea 48 89 de 4c 89 f7 e8 ae 85 ff ff 85 c0 0f 84 1f fe ff ff 31 db eb d0 <0f> 0b 48 89 ea 48 89 de 4c 89 f7 e8 92 8b ff ff 85 c0 75 e8 48 b8 [ 232.732614] RSP: 0000:ffff8881aa6ff9a8 EFLAGS: 00010282 [ 232.732991] RAX: 8000000142e002e7 RBX: ffff8881433cae10 RCX: dffffc0000000000 [ 232.733362] RDX: 0000000000000000 RSI: 00007fb47840b000 RDI: 8000000142e002e7 [ 232.733801] RBP: 00007fb47840b000 R08: 0000000000000000 R09: 1ffff110354dff46 [ 232.734168] R10: fffffbfff0cb921d R11: 00000000910da5ce R12: 1ffffffff0c1fcdd [ 232.734459] R13: 1ffffffff0c23f36 R14: ffff888171628040 R15: 0000000000000000 [ 232.734861] FS: 00007fb4907f86c0(0000) GS:ffff888791f2c000(0000) knlGS:0000000000000000 [ 232.735265] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 232.735548] CR2: 00007fb47840be00 CR3: 000000015e6dc000 CR4: 00000000000006f0 [ 232.736031] Call Trace: [ 232.736273] <TASK> [ 232.736500] get_locked_pte+0x1f/0xa0 [ 232.736878] insert_pfn+0x9f/0x350 [ 232.737190] ? __pfx_pat_pagerange_is_ram+0x10/0x10 [ 232.737614] ? __pfx_insert_pfn+0x10/0x10 [ 232.737990] ? __pfx_css_rstat_updated+0x10/0x10 [ 232.738281] ? __pfx_pfn_modify_allowed+0x10/0x10 [ 232.738552] ? lookup_memtype+0x62/0x180 [ 232.738761] vmf_insert_pfn_prot+0x14b/0x340 [ 232.739012] ? __pfx_vmf_insert_pfn_prot+0x10/0x10 [ 232.739247] ? __pfx___might_resched+0x10/0x10 [ 232.739475] drm_gem_shmem_fault.cold+0x18/0x39 [ 232.739677] ? rcu_read_unlock+0x20/0x70 [ 232.739882] __do_fault+0x251/0x7b0 [ 232.740028] do_fault+0x6e1/0xc00 [ 232.740167] ? __lock_acquire+0x590/0xc40 [ 232.740335] handle_pte_fault+0x439/0x760 [ 232.740498] ? mtree_range_walk+0x252/0xae0 [ 232.740669] ? __pfx_handle_pte_fault+0x10/0x10 [ 232.740899] __handle_mm_fault+0xa02/0xf30 [ 232.741066] ? __pfx___handle_mm_fault+0x10/0x10 [ 232.741255] ? find_vma+0xa1/0x120 [ 232.741403] handle_mm_fault+0x2bf/0x8f0 [ 232.741564] do_user_addr_fault+0x2d3/0xed0 [ 232.741736] ? trace_page_fault_user+0x1bf/0x240 [ 232.741969] exc_page_fault+0x87/0x120 [ 232.742124] asm_exc_page_fault+0x26/0x30 [ 232.742288] RIP: 0033:0x7fb4d73ed546 [ 232.742441] Code: 66 41 0f 6f fb 66 44 0f 6d dc 66 44 0f 6f c6 66 41 0f 6d f1 66 0f 6c fc 66 45 0f 6c c1 66 44 0f 6f c9 66 0f 6d ca 66 0f db f0 <66> 0f df 04 08 66 44 0f 6c ca 66 45 0f db c2 66 44 0f df 10 66 44 [ 232.743193] RSP: 002b:00007fb4907f68a0 EFLAGS: 00010206 [ 232.743565] RAX: 00007fb47840aa00 RBX: 00007fb4d73ec070 RCX: 0000000000001400 [ 232.743871] RDX: 0000000000002800 RSI: 0000000000003c00 RDI: 0000000000000001 [ 232.744150] RBP: 0000000000000004 R08: 0000000000001400 R09: 00007fb4d73ec060 [ 232.744433] R10: 000055f0261a4288 R11: 00007fb4c013da40 R12: 0000000000000008 [ 232.744712] R13: 0000000000000000 R14: 4332322132212110 R15: 0000000000000004 [ 232.746616] </TASK> [ 232.746711] Modules linked in: nft_nat nft_masq veth bridge stp llc snd_seq_dummy snd_hrtimer snd_seq snd_seq_device snd_timer snd soundcore overlay rfkill nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables qrtr ppdev 9pnet_virtio 9pnet parport_pc i2c_piix4 netfs pcspkr parport i2c_smbus joydev sunrpc vfat fat loop dm_multipath nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport zram lz4hc_compress vmw_vmci lz4_compress vsock e1000 bochs serio_raw ata_generic pata_acpi scsi_dh_rdac scsi_dh_emc scsi_dh_alua i2c_dev fuse qemu_fw_cfg [ 232.749308] ---[ end trace 0000000000000000 ]--- [ 232.749507] RIP: 0010:walk_to_pmd+0x29e/0x3c0 [ 232.749692] Code: d8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 89 ea 48 89 de 4c 89 f7 e8 ae 85 ff ff 85 c0 0f 84 1f fe ff ff 31 db eb d0 <0f> 0b 48 89 ea 48 89 de 4c 89 f7 e8 92 8b ff ff 85 c0 75 e8 48 b8 [ 232.750428] RSP: 0000:ffff8881aa6ff9a8 EFLAGS: 00010282 [ 232.750645] RAX: 8000000142e002e7 RBX: ffff8881433cae10 RCX: dffffc0000000000 [ 232.750954] RDX: 0000000000000000 RSI: 00007fb47840b000 RDI: 8000000142e002e7 [ 232.751232] RBP: 00007fb47840b000 R08: 0000000000000000 R09: 1ffff110354dff46 [ 232.751514] R10: fffffbfff0cb921d R11: 00000000910da5ce R12: 1ffffffff0c1fcdd [ 232.751837] R13: 1ffffffff0c23f36 R14: ffff888171628040 R15: 0000000000000000 [ 232.752124] FS: 00007fb4907f86c0(0000) GS:ffff888791f2c000(0000) knlGS:0000000000000000 [ 232.752441] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 232.752674] CR2: 00007fb47840be00 CR3: 000000015e6dc000 CR4: 00000000000006f0 [ 232.752983] Kernel panic - not syncing: Fatal exception [ 232.753510] Kernel Offset: disabled [ 232.754643] ---[ end Kernel panic - not syncing: Fatal exception ]--- This happens when two concurrent page faults occur within the same PMD range. One fault installs a PMD mapping through vmf_insert_pfn_pmd(), while the other attempts to install a PTE mapping via vmf_insert_pfn(). The bug is triggered because a pmd_trans_huge is not expected when walking the page table inside vmf_insert_pfn. Avoid this race by adding a huge_fault callback to drm_gem_shmem_vm_ops so that PMD-sized mappings are handled through the appropriate huge page fault path. Fixes: 211b9a39f261 ("drm/shmem-helper: Map huge pages in fault handler") Signed-off-by: Pedro Demarchi Gomes <pedrodemargomes@gmail.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20260319015224.46896-1-pedrodemargomes@gmail.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2026-03-19scsi: target: file: Use kzalloc_flex for aio_cmdThinh Nguyen
The target_core_file doesn't initialize the aio_cmd->iocb for the ki_write_stream. When a write command fd_execute_rw_aio() is executed, we may get a bogus ki_write_stream value, causing unintended write failure status when checking iocb->ki_write_stream > max_write_streams in the block device. Let's just use kzalloc_flex when allocating the aio_cmd and let ki_write_stream=0 to fix this issue. Fixes: 732f25a2895a ("fs: add a write stream field to the kiocb") Fixes: c27683da6406 ("block: expose write streams for block device nodes") Cc: stable@vger.kernel.org Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://patch.msgid.link/f1a2f81c62f043e31f80bb92d5f29893400c8ee2.1773450782.git.Thinh.Nguyen@synopsys.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-03-19scsi: scsi_transport_sas: Fix the maximum channel scanning issueYihang Li
After commit 37c4e72b0651 ("scsi: Fix sas_user_scan() to handle wildcard and multi-channel scans"), if the device supports multiple channels (0 to shost->max_channel), user_scan() invokes updated sas_user_scan() to perform the scan behavior for a specific transfer. However, when the user specifies shost->max_channel, it will return -EINVAL, which is not expected. Fix and support specifying the scan shost->max_channel for scanning. Fixes: 37c4e72b0651 ("scsi: Fix sas_user_scan() to handle wildcard and multi-channel scans") Signed-off-by: Yihang Li <liyihang9@huawei.com> Reviewed-by: John Garry <john.g.garry@oracle.com> Link: https://patch.msgid.link/20260317063147.2182562-1-liyihang9@huawei.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-03-19scsi: target: tcm_loop: Drain commands in target_reset handlerJosef Bacik
tcm_loop_target_reset() violates the SCSI EH contract: it returns SUCCESS without draining any in-flight commands. The SCSI EH documentation (scsi_eh.rst) requires that when a reset handler returns SUCCESS the driver has made lower layers "forget about timed out scmds" and is ready for new commands. Every other SCSI LLD (virtio_scsi, mpt3sas, ipr, scsi_debug, mpi3mr) enforces this by draining or completing outstanding commands before returning SUCCESS. Because tcm_loop_target_reset() doesn't drain, the SCSI EH reuses in-flight scsi_cmnd structures for recovery commands (e.g. TUR) while the target core still has async completion work queued for the old se_cmd. The memset in queuecommand zeroes se_lun and lun_ref_active, causing transport_lun_remove_cmd() to skip its percpu_ref_put(). The leaked LUN reference prevents transport_clear_lun_ref() from completing, hanging configfs LUN unlink forever in D-state: INFO: task rm:264 blocked for more than 122 seconds. rm D 0 264 258 0x00004000 Call Trace: __schedule+0x3d0/0x8e0 schedule+0x36/0xf0 transport_clear_lun_ref+0x78/0x90 [target_core_mod] core_tpg_remove_lun+0x28/0xb0 [target_core_mod] target_fabric_port_unlink+0x50/0x60 [target_core_mod] configfs_unlink+0x156/0x1f0 [configfs] vfs_unlink+0x109/0x290 do_unlinkat+0x1d5/0x2d0 Fix this by making tcm_loop_target_reset() actually drain commands: 1. Issue TMR_LUN_RESET via tcm_loop_issue_tmr() to drain all commands that the target core knows about (those not yet CMD_T_COMPLETE). 2. Use blk_mq_tagset_busy_iter() to iterate all started requests and flush_work() on each se_cmd — this drains any deferred completion work for commands that already had CMD_T_COMPLETE set before the TMR (which the TMR skips via __target_check_io_state()). This is the same pattern used by mpi3mr, scsi_debug, and libsas to drain outstanding commands during reset. Fixes: e0eb5d38b732 ("scsi: target: tcm_loop: Use block cmd allocator for se_cmds") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Josef Bacik <josef@toxicpanda.com> Link: https://patch.msgid.link/27011aa34c8f6b1b94d2e3cf5655b6d037f53428.1773706803.git.josef@toxicpanda.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-03-19scsi: ibmvfc: Fix OOB access in ibmvfc_discover_targets_done()Tyllis Xu
A malicious or compromised VIO server can return a num_written value in the discover targets MAD response that exceeds max_targets. This value is stored directly in vhost->num_targets without validation, and is then used as the loop bound in ibmvfc_alloc_targets() to index into disc_buf[], which is only allocated for max_targets entries. Indices at or beyond max_targets access kernel memory outside the DMA-coherent allocation. The out-of-bounds data is subsequently embedded in Implicit Logout and PLOGI MADs that are sent back to the VIO server, leaking kernel memory. Fix by clamping num_written to max_targets before storing it. Fixes: 072b91f9c651 ("[SCSI] ibmvfc: IBM Power Virtual Fibre Channel Adapter Client Driver") Reported-by: Yuhao Jiang <danisjiang@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Tyllis Xu <LivelyCarpet87@gmail.com> Reviewed-by: Dave Marquardt <davemarq@linux.ibm.com> Acked-by: Tyrel Datwyler <tyreld@linux.ibm.com> Link: https://patch.msgid.link/20260314170151.548614-1-LivelyCarpet87@gmail.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-03-19scsi: ses: Handle positive SCSI error from ses_recv_diag()Greg Kroah-Hartman
ses_recv_diag() can return a positive value, which also means that an error happened, so do not only test for negative values. Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com> Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: stable <stable@kernel.org> Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Hannes Reinecke <hare@suse.de> Link: https://patch.msgid.link/2026022301-bony-overstock-a07f@gregkh Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-03-19Merge tag 'for-net-2026-03-19' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - hci_ll: Fix firmware leak on error path - hci_sync: annotate data-races around hdev->req_status - L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cb - L2CAP: Validate PDU length before reading SDU length in l2cap_ecred_data_rcv() - L2CAP: Fix regressions caused by reusing ident - L2CAP: Fix stack-out-of-bounds read in l2cap_ecred_conn_req - MGMT: Fix dangling pointer on mgmt_add_adv_patterns_monitor_complete - SCO: Fix use-after-free in sco_recv_frame() due to missing sock_hold * tag 'for-net-2026-03-19' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: L2CAP: Fix regressions caused by reusing ident Bluetooth: L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cb Bluetooth: hci_ll: Fix firmware leak on error path Bluetooth: hci_sync: annotate data-races around hdev->req_status Bluetooth: MGMT: Fix dangling pointer on mgmt_add_adv_patterns_monitor_complete Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing sock_hold Bluetooth: L2CAP: Validate PDU length before reading SDU length in l2cap_ecred_data_rcv() Bluetooth: L2CAP: Fix stack-out-of-bounds read in l2cap_ecred_conn_req ==================== Link: https://patch.msgid.link/20260319190455.135302-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-19Merge tag 'pci-v7.0-fixes-4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull pci fixes from Bjorn Helgaas: - Create pwrctrl devices only for DT nodes below a PCI controller that describe PCI devices and are related to a power supply; this prevents waiting indefinitely for pwrctrl drivers that will never probe (Manivannan Sadhasivam) - Restore endpoint BAR mapping on subrange setup failure to make selftest reliable (Koichiro Den) * tag 'pci-v7.0-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails PCI/pwrctrl: Create pwrctrl devices only for PCI device nodes PCI/pwrctrl: Ensure that remote endpoint node parent has supply requirement
2026-03-19i2c: pxa: defer reset on Armada 3700 when recovery is usedGabor Juhos
The I2C communication is completely broken on the Armada 3700 platform since commit 0b01392c18b9 ("i2c: pxa: move to generic GPIO recovery"). For example, on the Methode uDPU board, probing of the two onboard temperature sensors fails ... [ 7.271713] i2c i2c-0: using pinctrl states for GPIO recovery [ 7.277503] i2c i2c-0: PXA I2C adapter [ 7.282199] i2c i2c-1: using pinctrl states for GPIO recovery [ 7.288241] i2c i2c-1: PXA I2C adapter [ 7.292947] sfp sfp-eth1: Host maximum power 3.0W [ 7.299614] sfp sfp-eth0: Host maximum power 3.0W [ 7.308178] lm75 1-0048: supply vs not found, using dummy regulator [ 32.489631] lm75 1-0048: probe with driver lm75 failed with error -121 [ 32.496833] lm75 1-0049: supply vs not found, using dummy regulator [ 82.890614] lm75 1-0049: probe with driver lm75 failed with error -121 ... and accessing the plugged-in SFP modules also does not work: [ 511.298537] sfp sfp-eth1: please wait, module slow to respond [ 536.488530] sfp sfp-eth0: please wait, module slow to respond ... [ 1065.688536] sfp sfp-eth1: failed to read EEPROM: -EREMOTEIO [ 1090.888532] sfp sfp-eth0: failed to read EEPROM: -EREMOTEIO After a discussion [1], there was an attempt to fix the problem by reverting the offending change by commit 7b211c767121 ("Revert "i2c: pxa: move to generic GPIO recovery""), but that only helped to fix the issue in the 6.1.y stable tree. The reason behind the partial succes is that there was another change in commit 20cb3fce4d60 ("i2c: Set i2c pinctrl recovery info from it's device pinctrl") in the 6.3-rc1 cycle which broke things further. The cause of the problem is the same in case of both offending commits mentioned above. Namely, the I2C core code changes the pinctrl state to GPIO while running the recovery initialization code. Although the PXA specific initialization also does this, but the key difference is that it happens before the controller is getting enabled in i2c_pxa_reset(), whereas in the case of the generic initialization it happens after that. Change the code to reset the controller only before the first transfer instead of before registering the controller. This ensures that the controller is not enabled at the time when the generic recovery code performs the pinctrl state changes, thus avoids the problem described above. As the result this change restores the original behaviour, which in turn makes the I2C communication to work again as it can be seen from the following log: [ 7.363250] i2c i2c-0: using pinctrl states for GPIO recovery [ 7.369041] i2c i2c-0: PXA I2C adapter [ 7.373673] i2c i2c-1: using pinctrl states for GPIO recovery [ 7.379742] i2c i2c-1: PXA I2C adapter [ 7.384506] sfp sfp-eth1: Host maximum power 3.0W [ 7.393013] sfp sfp-eth0: Host maximum power 3.0W [ 7.399266] lm75 1-0048: supply vs not found, using dummy regulator [ 7.407257] hwmon hwmon0: temp1_input not attached to any thermal zone [ 7.413863] lm75 1-0048: hwmon0: sensor 'tmp75c' [ 7.418746] lm75 1-0049: supply vs not found, using dummy regulator [ 7.426371] hwmon hwmon1: temp1_input not attached to any thermal zone [ 7.432972] lm75 1-0049: hwmon1: sensor 'tmp75c' [ 7.755092] sfp sfp-eth1: module MENTECHOPTO POS22-LDCC-KR rev 1.0 sn MNC208U90009 dc 200828 [ 7.764997] mvneta d0040000.ethernet eth1: unsupported SFP module: no common interface modes [ 7.785362] sfp sfp-eth0: module Mikrotik S-RJ01 rev 1.0 sn 61B103C55C58 dc 201022 [ 7.803426] hwmon hwmon2: temp1_input not attached to any thermal zone Link: https://lore.kernel.org/r/20230926160255.330417-1-robert.marko@sartura.hr #1 Cc: stable@vger.kernel.org # 6.3+ Fixes: 20cb3fce4d60 ("i2c: Set i2c pinctrl recovery info from it's device pinctrl") Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Tested-by: Robert Marko <robert.marko@sartura.hr> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260226-i2c-pxa-fix-i2c-communication-v4-1-797a091dae87@gmail.com
2026-03-19ionic: fix persistent MAC address override on PFMohammad Heib
The use of IONIC_CMD_LIF_SETATTR in the MAC address update path causes the ionic firmware to update the LIF's identity in its persistent state. Since the firmware state is maintained across host warm boots and driver reloads, any MAC change on the Physical Function (PF) becomes "sticky. This is problematic because it causes ethtool -P to report the user-configured MAC as the permanent factory address, which breaks system management tools that rely on a stable hardware identity. While Virtual Functions (VFs) need this hardware-level programming to properly handle MAC assignments in guest environments, the PF should maintain standard transient behavior. This patch gates the ionic_program_mac call using is_virtfn so that PF MAC changes remain local to the netdev filters and do not overwrite the firmware's permanent identity block. Fixes: 19058be7c48c ("ionic: VF initial random MAC address if no assigned mac") Signed-off-by: Mohammad Heib <mheib@redhat.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Brett Creeley <brett.creeley@amd.com> Link: https://patch.msgid.link/20260317170806.35390-1-mheib@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-19i2c: fsi: Fix a potential leak in fsi_i2c_probe()Christophe JAILLET
In the commit in Fixes:, when the code has been updated to use an explicit for loop, instead of for_each_available_child_of_node(), the assumption that a reference to a device_node structure would be released at each iteration has been broken. Now, an explicit of_node_put() is needed to release the reference. Fixes: 095561f476ab ("i2c: fsi: Create busses for all ports") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: <stable@vger.kernel.org> # v5.3+ Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/fd805c39f8de51edf303856103d782138a1633c8.1772382022.git.christophe.jaillet@wanadoo.fr
2026-03-19i2c: cp2615: fix serial string NULL-deref at probeJohan Hovold
The cp2615 driver uses the USB device serial string as the i2c adapter name but does not make sure that the string exists. Verify that the device has a serial number before accessing it to avoid triggering a NULL-pointer dereference (e.g. with malicious devices). Fixes: 4a7695429ead ("i2c: cp2615: add i2c driver for Silicon Labs' CP2615 Digital Audio Bridge") Cc: stable@vger.kernel.org # 5.13 Cc: Bence Csókás <bence98@sch.bme.hu> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Bence Csókás <bence98@sch.bme.hu> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260309075016.25612-1-johan@kernel.org
2026-03-19cxl: Adjust the startup priority of cxl_pmem to be higher than that of cxl_acpiCui Chao
During the cxl_acpi probe process, it checks whether the cxl_nvb device and driver have been attached. Currently, the startup priority of the cxl_pmem driver is lower than that of the cxl_acpi driver. At this point, the cxl_nvb driver has not yet been registered on the cxl_bus, causing the attachment check to fail. This results in a failure to add the root nvdimm bridge, leading to a cxl_acpi probe failure and ultimately affecting the subsequent loading of cxl drivers. As a consequence, only one mem device object exists on the cxl_bus, while the cxl_port device objects and decoder device objects are missing. The solution is to raise the startup priority of cxl_pmem to be higher than that of cxl_acpi, ensuring that the cxl_pmem driver is registered before the aforementioned attachment check occurs. Co-developed-by: Wang Yinfeng <wangyinfeng@phytium.com.cn> Signed-off-by: Wang Yinfeng <wangyinfeng@phytium.com.cn> Signed-off-by: Cui Chao <cuichao1753@phytium.com.cn> Fixes: e7e222ad73d9 ("cxl: Move devm_cxl_add_nvdimm_bridge() to cxl_pmem.ko") Reviewed-by: Dan Williams <dan.j.williams@intel.com> Link: https://patch.msgid.link/20260319074535.1709250-1-cuichao1753@phytium.com.cn Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-03-19pinctrl: mediatek: common: Fix probe failure for devices without EINTLuca Leonardo Scorcia
Some pinctrl devices like mt6397 or mt6392 don't support EINT at all, but the mtk_eint_init function is always called and returns -ENODEV, which then bubbles up and causes probe failure. To address this only call mtk_eint_init if EINT pins are present. Tested on Xiaomi Mi Smart Clock x04g (mt6392). Fixes: e46df235b4e6 ("pinctrl: mediatek: refactor EINT related code for all MediaTek pinctrl can fit") Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-03-19Bluetooth: hci_ll: Fix firmware leak on error pathAnas Iqbal
Smatch reports: drivers/bluetooth/hci_ll.c:587 download_firmware() warn: 'fw' from request_firmware() not released on lines: 544. In download_firmware(), if request_firmware() succeeds but the returned firmware content is invalid (no data or zero size), the function returns without releasing the firmware, resulting in a resource leak. Fix this by calling release_firmware() before returning when request_firmware() succeeded but the firmware content is invalid. Fixes: 371805522f87 ("bluetooth: hci_uart: add LL protocol serdev driver support") Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Anas Iqbal <mohd.abd.6602@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
generated by cgit v1.2.3 (git 2.0.4) at 2026-04-06 04:49:30 +0000