summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2026-03-20reset: sti: kzalloc + kcalloc to kzallocRosen Penev1-7/+2
Simplify allocation. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2026-03-20drm/ttm: Avoid invoking the OOM killer when reading back swapped contentThomas Hellström2-3/+8
In situations where the system is very short on RAM, the shmem readback from swap-space may invoke the OOM killer. However, since this might be a recoverable situation where the caller is indicating this by setting struct ttm_operation_ctx::gfp_retry_mayfail to true, adjust the gfp value used by the allocation accordingly. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Christian König <christian.koening@amd.com> Link: https://patch.msgid.link/20260317141856.237876-3-thomas.hellstrom@linux.intel.com
2026-03-20drm/ttm: Don't spam the log on buffer object backing store allocation failureThomas Hellström1-1/+1
If the struct ttm_operation_ctx::gfp_retry_mayfail is true, buffer object backing store allocation failures are expected to silently fail with an error code to the caller. But currently an elaborate warning is printed to the system log. Don't spam the log in this way. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch> Acked-by: Christian König <christian.koening@amd.com> Link: https://patch.msgid.link/20260317141856.237876-2-thomas.hellstrom@linux.intel.com
2026-03-20drm/atomic: Remove state argument to drm_atomic_private_obj_initMaxime Ripard13-38/+19
Now that all drm_private_objs users have been converted to use atomic_create_state instead of the old ad-hoc initialization, we can remove the state parameter from drm_private_obj_init and the fallback code. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260224-drm-private-obj-reset-v5-4-5a72f8ec9934@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-03-20drm/tegra: Switch private_obj initialization to atomic_create_stateMaxime Ripard1-6/+16
The tegra driver relies on a drm_private_obj, that is initialized by allocating and initializing a state, and then passing it to drm_private_obj_init. Since we're gradually moving away from that pattern to the more established one relying on a atomic_create_state implementation, let's migrate this instance to the new pattern. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patch.msgid.link/20260224-drm-private-obj-reset-v5-3-5a72f8ec9934@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-03-20drm/omapdrm: Switch private_obj initialization to atomic_create_stateMaxime Ripard1-6/+16
The omapdrm driver relies on a drm_private_obj, that is initialized by allocating and initializing a state, and then passing it to drm_private_obj_init. Since we're gradually moving away from that pattern to the more established one relying on a atomic_create_state implementation, let's migrate this instance to the new pattern. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patch.msgid.link/20260224-drm-private-obj-reset-v5-2-5a72f8ec9934@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-03-20drm/amdgpu: Switch private_obj initialization to atomic_create_stateMaxime Ripard1-24/+28
The amdgpu driver relies on a drm_private_obj, that is initialized by allocating and initializing a state, and then passing it to drm_private_obj_init. Since we're gradually moving away from that pattern to the more established one relying on a atomic_create_state implementation, let's migrate this instance to the new pattern. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patch.msgid.link/20260224-drm-private-obj-reset-v5-1-5a72f8ec9934@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-03-20ata: libata-scsi: report correct sense field pointer in ata_scsiop_maint_in()Damien Le Moal1-1/+1
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 Gomes1-22/+28
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-20accel/ivpu: Perform engine reset instead of device recovery on TDRKarol Wachowski9-17/+92
Replace full device recovery on TDR timeout with per-context abort, allowing individual context handling instead of resetting the entire device. Extend ivpu_jsm_reset_engine() to return the list of contexts impacted by the engine reset and use that information to abort only the affected contexts. Only check for potentially faulty contexts when the engine reset was not triggered by an MMU fault or a job completion error status. This prevents misidentifying non-guilty contexts that happened to be running at the time of the fault. Trigger full device recovery if no contexts were marked by engine reset if triggered by job completion timeout, as there is no way to identify guilty one. Add engine reset counter to debugfs for engine resets bookkeeping for debugging/testing purposes. Reviewed-by: Lizhi Hou <lizhi.hou@amd.com> Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com> Link: https://patch.msgid.link/20260318093927.4080303-1-karol.wachowski@linux.intel.com
2026-03-20cpufreq: tegra194: remove COMPILE_TESTRosen Penev1-1/+1
The driver needs architecture specific headers to build. Problem gets exposed when TEGRA_BPMP gets COMPILE_TEST added to it. Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2026-03-20platform/chrome: cros_usbpd_logger: Simplify with devmKrzysztof Kozlowski1-11/+7
Simplify the driver by using devm interfaces, which allow to drop probe() error paths and the remove() callback. Change is not equivalent in the workqueue itself: use non-legacy API which does not set (__WQ_LEGACY | WQ_MEM_RECLAIM). The workqueue is used to update logs, thus there is no point to run it for memory reclaim. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20260305-workqueue-devm-v2-10-66a38741c652@oss.qualcomm.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2026-03-20extcon: usbc-tusb320: Make typec-power-opmode optionalYannis Bolliger1-13/+11
The driver returned an error in the probe function when a usb c connector is configured in the DT without a "typec-power-opmode" property. This property is used to initialize the CURRENT_MODE_ADVERTISE register of the TUSB320, which is unused when operating as a UFP. Requiring this property causes unnecessary configuration overhead and inconsistency with the USB connector DT bindings, which do not specify it as required. This change makes typec-power-opmode optional. When the property is not present, the driver will skip programming the CURRENT_MODE_ADVERTISE register and rely on the hardware default. Signed-off-by: Yannis Bolliger <yannis.bolliger@protonmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Link: https://lore.kernel.org/lkml/aPKZJ6WTZlhSOyST@yaene-desktop/
2026-03-20extcon: ptn5150: Support USB role switch via connector fwnodeXu Yang1-0/+2
Since the PTN5150 is a Type-C chip, it's common to describe related properties under the connector node. To align with this, the port node will be located under the connector node in the future. To support this layout, retrieve the USB role switch using the connector's fwnode. For compatibility with existing device trees, keep the usb_role_switch_get() function. Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Link: https://lore.kernel.org/lkml/20250926025309.24267-3-xu.yang_2@nxp.com/
2026-03-20extcon: ptn5150: Add Type-C orientation switch supportXu Yang2-0/+41
PTN5150 is able to detect CC polarity. The field[1:0] of CC status register (04H) will keep the result. 00: Cable Not Attached 01: CC1 is connected (normal orientation) 10: CC2 is connected (reversed orientation) 11: Reserved Add orientation switch support to correctly set orientation of multiplexer according to CC status. Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Link: https://lore.kernel.org/lkml/20250926025309.24267-2-xu.yang_2@nxp.com/
2026-03-20extcon: Fixed sysfs duplicate filename issueMichael Wu1-2/+2
With current extcon_dev_unregister() timing, ida_free is before device_unregister(), that may cause current id re-alloc to another device in extcon_dev_register() context but sysfs filename path not removal completed yet. The right timing shows below: on extcon_dev_register: ida_alloc() -> device_register() on extcon_dev_unregister: device_unregister() -> ida_free() stack information when an error occurs: sysfs: cannot create duplicate filename '/class/extcon/extcon1' Call trace: sysfs_warn_dup+0x68/0x88 sysfs_do_create_link_sd+0x94/0xdc sysfs_create_link+0x30/0x48 device_add_class_symlinks+0xb4/0x12c device_add+0x1e0/0x48c device_register+0x20/0x34 extcon_dev_register+0x3b8/0x5c4 Fixes: 7bba9e81a6fb ("extcon: Use unique number for the extcon device ID") Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Michael Wu <michael@allwinnertech.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Link: https://lore.kernel.org/lkml/20251024024946.16618-1-michael@allwinnertech.com/
2026-03-20extcon: int3496: replace use of system_wq with system_percpu_wqMarco Crivellari1-2/+2
Currently if a user enqueue a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistentcy cannot be addressed without refactoring the API. This patch continues the effort to refactor worqueue APIs, which has begun with the change introducing new workqueues and a new alloc_workqueue flag: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") system_wq should be the per-cpu workqueue, yet in this name nothing makes that clear, so replace system_wq with system_percpu_wq. The old wq (system_wq) will be kept for a few release cycles. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Link: https://lore.kernel.org/lkml/20251104110105.116858-1-marco.crivellari@suse.com/
2026-03-20extcon: ptn5150: handle pending IRQ events during system resumeXu Yang1-0/+14
When the system is suspended and ptn5150 wakeup interrupt is disabled, any changes on ptn5150 will only be record in interrupt status registers and won't fire an IRQ since its trigger type is falling edge. So the HW interrupt line will keep at low state and any further changes won't trigger IRQ anymore. To fix it, this will schedule a work to check whether any IRQ are pending and handle it accordingly. Fixes: 4ed754de2d66 ("extcon: Add support for ptn5150 extcon driver") Cc: stable@vger.kernel.org Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Link: https://lore.kernel.org/lkml/20251115025905.1395347-1-xu.yang_2@nxp.com/
2026-03-20scsi: target: file: Use kzalloc_flex for aio_cmdThinh Nguyen1-1/+1
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-20scsi: scsi_transport_sas: Fix the maximum channel scanning issueYihang Li1-1/+1
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-20scsi: target: tcm_loop: Drain commands in target_reset handlerJosef Bacik1-6/+46
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-20scsi: lpfc: Use the crc32c() functionEric Biggers5-57/+12
lpfc_cgn_calc_crc32(data, size, crc) is really just an open-coded version of ~crc32c(bitrev32(crc), data, size). However, all callers pass crc == ~0, so it can be simplified even further to just ~crc32c(~0, data, size). Remove the crc argument and implement it that way. While we're at it, also use proper types in the function prototype. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Link: https://patch.msgid.link/20260316223631.72361-1-ebiggers@kernel.org Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-03-20scsi: ibmvfc: Fix OOB access in ibmvfc_discover_targets_done()Tyllis Xu1-1/+2
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-20scsi: ufs: core: Handle MCQ IAG eventsvamshi gajjela3-4/+27
Add support for handling aggregation-based interrupts when operating in MCQ mode. In legacy interrupt mode, an IE.IAGES is triggered when the counter or timer threshold is reached. To manage this, the handler now resets the aggregation counter and timer by writing to the MCQIACRy.CTR register. Since the register layout of MCQIACRy is identical to the existing UTRIACR register, this implementation reuses the previously defined bitfield masks to maintain consistency and reduce code duplication. Extend ufshcd_handle_mcq_cq_events() with a boolean iag parameter. If set, the handler resets the MCQ IAG counter and timer. Define MCQ_IAG_EVENT_STATUS (0x200000) and include it in UFSHCD_ENABLE_MCQ_INTRS to ensure the interrupt is unmasked during initialization. Signed-off-by: Vamshi Gajjela <vamshigajjela@google.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Link: https://patch.msgid.link/20260310190308.2474956-1-vamshigajjela@google.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-03-20scsi: ses: Handle positive SCSI error from ses_recv_diag()Greg Kroah-Hartman1-1/+1
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-20drm/panel-edp: Add BOE NV153WUM-N42, CMN N153JCA-ELK, CSW MNF307QS3-2Alvin1 Chen1-0/+3
The raw EDIDs for each panel: BOE: NV153WUM-N42 00 ff ff ff ff ff ff 00 09 e5 b3 0d 00 00 00 00 11 23 01 04 a5 21 15 78 03 af e5 97 5e 58 92 28 1f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 9c 3e 80 c8 70 b0 3c 40 30 20 36 00 49 ce 10 00 00 1a 00 00 00 fd 00 28 3c 4c 4c 10 01 0a 20 20 20 20 20 20 00 00 00 fe 00 42 4f 45 20 43 51 0a 20 20 20 20 20 20 00 00 00 fc 00 4e 56 31 35 33 57 55 4d 2d 4e 34 32 0a 01 92 70 20 79 02 00 81 00 15 74 1a 00 00 03 01 28 3c 00 00 60 49 60 49 3c 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cb 90 CMN: N153JCA-ELK 00 ff ff ff ff ff ff 00 0d ae 6b 15 00 00 00 00 16 23 01 04 a5 21 15 78 03 08 82 93 59 53 8e 27 1e 4f 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 42 3c 80 a0 70 b0 24 40 30 20 a6 00 49 cd 10 00 00 1a 00 00 00 fd 00 28 3c 4a 4a 10 01 0a 20 20 20 20 20 20 00 00 00 fe 00 43 4d 4e 0a 20 20 20 20 20 20 20 20 20 00 00 00 fc 00 4e 31 35 33 4a 43 41 2d 45 4c 4b 0a 20 01 d5 70 20 79 02 00 25 01 09 94 5a 02 94 5a 02 28 3c 80 81 00 13 72 1a 00 00 03 01 28 3c 00 00 00 00 00 00 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ae 90 CSW: MNF307QS3-2 00 ff ff ff ff ff ff 00 0e 77 29 15 00 00 00 00 13 23 01 04 a5 21 15 78 03 9c 81 96 5d 5a 94 28 1e 51 56 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 1a 3f 80 04 71 b0 23 40 30 20 36 00 49 cd 10 00 00 18 00 00 00 fd 00 28 3c 4a 4a 10 01 0a 20 20 20 20 20 20 00 00 00 fe 00 43 4f 53 54 20 54 39 0a 20 20 20 20 20 00 00 00 fc 00 4d 4e 46 33 30 37 51 53 33 2d 32 0a 20 01 5c 70 20 79 02 00 81 00 15 74 1a 00 00 03 01 28 3c 00 00 60 46 60 46 3c 00 00 00 00 8d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c4 90 Signed-off-by: Alvin1 Chen <alvin1.chen@lcfc.corp-partner.google.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260319050938.556235-1-alvin1.chen@lcfc.corp-partner.google.com
2026-03-20net: fjes: Drop fjes_acpi_driver and rework initializationRafael J. Wysocki1-70/+50
The ACPI driver interface used by the Fujitsu Extended Socket (fjes) Network Device driver is redundant because its only role is to create a platform device the fjes platform driver can bind to, which can be done already at the module initialization time. Namely, acpi_find_extended_socket_device() looks for the requisite ACPI device object anyway and it may as well check its resources, and the platform device can be created when the ACPI object in question has been found (and it can be freed when the module is unloaded). Moreover, as a rule, it is better to avoid binding drivers directly to ACPI device objects [1]. Accordingly, drop fjes_acpi_driver, adjust the module initialization and exit code as per the above and set the fwnode for the fjes platform device to point to the corresponding ACPI device object as its ACPI companion. While this is not expected to alter functionality, it changes sysfs layout and so it will be visible to user space. Link: https://lore.kernel.org/all/2396510.ElGaqSPkdT@rafael.j.wysocki/ [1] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/12857407.O9o76ZdvQC@rafael.j.wysocki Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-20net: stmmac: rename STMMAC_GET_ENTRY() -> STMMAC_NEXT_ENTRY()Russell King (Oracle)4-16/+16
STMMAC_GET_ENTRY() doesn't describe what this macro is doing - it is incrementing the provided index for the circular array of descriptors. Replace "GET" with "NEXT" as this better describes the action here. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1w2vba-0000000DbWo-1oL5@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-20net: stmmac: use more descriptive names in stmmac_xmit()Russell King (Oracle)1-22/+23
Use "frag_size" rather than "len", correcting its type to be unsigned int. Rename "des" to "dma_addr" since that's what it is. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1w2vbV-0000000DbWi-1O80@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-20net: stmmac: simplify DMA descriptor allocation/init/freeingRussell King (Oracle)1-30/+27
Rather than having separate branches to handle the different types of descriptors, use the helper functions to calculate the total size of the DMA descriptors. Use this to allocate or free the descriptor array, and use a local variable to hold the address of the descriptor array, so we only need one dma_alloc_coherent() or dma_free_coherent() call in these paths. Also do the same for the receive ring initialisation. The transmit ring can't be converted as there is a case where stmmac_mode_init() is not called. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1w2vbQ-0000000DbWc-0ty5@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-20net: stmmac: more mode -> descriptor_mode renamesRussell King (Oracle)5-35/+42
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1w2vbL-0000000DbWW-0PON@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-20net: stmmac: rename "mode" to "descriptor_mode"Russell King (Oracle)3-14/+19
priv->mode doesn't describe what it refers to, it is whether we operate the DMA descriptors as a ring or chain. It is also difficult to grep for as there are several "mode" struct members. Add "descriptor_" prefix. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1w2vbF-0000000DbWQ-4674@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-20net: ntb_netdev: add SPDX tag and remove boilerplate license textOskar Ray-Frayssinet1-46/+1
Add SPDX-License-Identifier tag to reflect the dual GPL-2.0-only/BSD-3-Clause license, remove the redundant boilerplate license text and contact information, keeping only the driver description. Signed-off-by: Oskar Ray-Frayssinet <rayfraytech@gmail.com> Acked-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260318211153.9460-1-rayfraytech@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-20Merge tag 'for-net-2026-03-19' of ↵Jakub Kicinski1-0/+2
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-20Merge tag 'pci-v7.0-fixes-4' of ↵Linus Torvalds2-13/+46
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-20i2c: npcm7xx: Use NULL instead of 0 for pointerKrzysztof Kozlowski1-1/+1
Pointers should use NULL instead of explicit '0', as pointed out by sparse: i2c-npcm7xx.c:1387:61: warning: Using plain integer as NULL pointer Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by: Tali Perry <tali.perry1@gmail.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260216085825.70568-2-krzysztof.kozlowski@oss.qualcomm.com
2026-03-20hsi: hsi_core: use kzalloc_flexRosen Penev1-22/+15
Simplifies allocations by using a flexible array member in this struct. Add __counted_by to get extra runtime analysis. Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20260318191037.5661-1-rosenp@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-03-20i2c: pxa: defer reset on Armada 3700 when recovery is usedGabor Juhos1-1/+16
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-20ionic: fix persistent MAC address override on PFMohammad Heib1-6/+11
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-20i2c: fsi: Fix a potential leak in fsi_i2c_probe()Christophe JAILLET1-0/+1
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-20i2c: cp2615: fix serial string NULL-deref at probeJohan Hovold1-0/+3
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-20cxl: Adjust the startup priority of cxl_pmem to be higher than that of cxl_acpiCui Chao1-1/+1
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-20PCI: eswin: Add ESWIN PCIe Root Complex driverSenchuan Zhang3-0/+419
Add driver for the ESWIN PCIe Root Complex based on the DesignWare PCIe core, IP revision 5.96a. The PCIe Gen.3 Root Complex supports data rate of 8 GT/s and x4 lanes, with INTx and MSI interrupt capability. Signed-off-by: Yu Ning <ningyu@eswincomputing.com> Signed-off-by: Yanghui Ou <ouyanghui@eswincomputing.com> Signed-off-by: Senchuan Zhang <zhangsenchuan@eswincomputing.com> [mani: renamed "EIC7700" to "ESWIN", added maintainers entry, removed async probe] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> [bhelgaas: add driver tag in subject] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260227111808.1996-1-zhangsenchuan@eswincomputing.com
2026-03-20Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski216-1325/+1915
Cross-merge networking fixes after downstream PR (net-7.0-rc5). net/netfilter/nft_set_rbtree.c 598adea720b97 ("netfilter: revert nft_set_rbtree: validate open interval overlap") 3aea466a43998 ("netfilter: nft_set_rbtree: don't disable bh when acquiring tree lock") https://lore.kernel.org/abgaQBpeGstdN4oq@sirena.org.uk No adjacent changes. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-19pinctrl: mediatek: common: Fix probe failure for devices without EINTLuca Leonardo Scorcia1-3/+6
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 Iqbal1-0/+2
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>
2026-03-19vfio/mlx5: Add REINIT support to VFIO_MIG_GET_PRECOPY_INFOYishai Hadas3-39/+83
When userspace opts into VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2, the driver may report the VFIO_PRECOPY_INFO_REINIT output flag in response to the VFIO_MIG_GET_PRECOPY_INFO ioctl, along with a new initial_bytes value. The presence of the VFIO_PRECOPY_INFO_REINIT flag indicates to the caller that new initial data is available in the migration stream. If the firmware reports a new initial-data chunk, any previously dirty bytes in memory are treated as initial bytes, since the caller must read both sets before reaching the end of the initial-data region. In this case, the driver issues a new SAVE command to fetch the data and prepare it for a subsequent read() from userspace. Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Link: https://lore.kernel.org/r/20260317161753.18964-7-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-03-19vfio/mlx5: consider inflight SAVE during PRE_COPYYishai Hadas3-1/+8
Consider an inflight SAVE operation during the PRE_COPY phase, so the caller will wait when no data is currently available but is expected to arrive. This enables a follow-up patch to avoid returning -ENOMSG while a new *initial_bytes* chunk is still pending from an asynchronous SAVE command issued by the VFIO_MIG_GET_PRECOPY_INFO ioctl. Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Link: https://lore.kernel.org/r/20260317161753.18964-6-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-03-19vfio: Adapt drivers to use the core helper vfio_check_precopy_ioctlYishai Hadas4-45/+24
Introduce a core helper function for VFIO_MIG_GET_PRECOPY_INFO and adapt all drivers to use it. It centralizes the common code and ensures that output flags are cleared on entry, in case user opts in to VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2. This preventing any unintended echoing of userspace data back to userspace. Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Link: https://lore.kernel.org/r/20260317161753.18964-4-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-03-19vfio: Add support for VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2Yishai Hadas1-0/+21
Currently, existing VFIO_MIG_GET_PRECOPY_INFO implementations don't assign info.flags before copy_to_user(). Because they copy the struct in from userspace first, this effectively echoes userspace-provided flags back as output, preventing the field from being used to report new reliable data from the drivers. Add support for a new device feature named VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2. On SET, enables the v2 pre_copy_info behaviour, where the vfio_precopy_info.flags is a valid output field. Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Link: https://lore.kernel.org/r/20260317161753.18964-3-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex@shazbot.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-04 14:07:53 +0300