summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-06-09hwmon: (ina238) Add update_interval_us attributeFerdinand Schwenk
The INA238 family supports eight conversion time steps from 50 us to 4120 us (SQ52206: 66 us to 8230 us). At the millisecond granularity of update_interval, the four shortest steps (50, 84, 150, 280 us) all round to the same value and cannot be individually selected. Add support for the generic update_interval_us attribute, which reports and programs the same ADC cycle time as update_interval but in microseconds, giving userspace full access to all conversion time steps. Both attributes reflect the total cycle time including the active averaging count: the reported value is the raw conversion time multiplied by the number of averaged samples, and writes apply the inverse mapping. Signed-off-by: Ferdinand Schwenk <ferdinand.schwenk@advastore.com> Link: https://lore.kernel.org/r/20260609-hwmon-ina238-update-interval-us-v2-v3-3-016b55567950@advastore.com [groeck: Fixed some multi-line alignment issues] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-09hwmon: Add update_interval_us chip attributeFerdinand Schwenk
Some hardware monitoring chips support update intervals below one millisecond. The existing update_interval attribute uses millisecond granularity, which causes sub-millisecond steps to round to the same value and become inaccessible from userspace. Introduce update_interval_us, a companion chip-level attribute that expresses the same update interval in microseconds. Drivers implementing this attribute should also implement update_interval for compatibility with millisecond-based userspace interfaces. Signed-off-by: Ferdinand Schwenk <ferdinand.schwenk@advastore.com> Link: https://lore.kernel.org/r/20260609-hwmon-ina238-update-interval-us-v2-v3-2-016b55567950@advastore.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-09hwmon: (ina238) Add support for samples and update_intervalFerdinand Schwenk
Expose INA238 ADC averaging count (AVG) and conversion timing (VBUSCT/VSHCT/VTCT) through chip-level hwmon attributes: chip/samples chip/update_interval Use per-chip conversion-time lookup tables so the same helpers work for INA228/INA237/INA238/INA700/INA780 and SQ52206. Cache ADC_CONFIG in driver data and update it on writes to avoid extra register reads during read-modify-write updates. Report update_interval in milliseconds as required by the hwmon ABI. Compute it from raw ADC cycle time multiplied by the active averaging count, and apply the inverse mapping on writes so programmed conversion time tracks the selected sample count. Clamp user-provided update_interval before unit scaling to prevent overflow in arithmetic conversions. Also combine chip attributes in HWMON_CHANNEL_INFO using a bitwise OR for a single logical chip channel. Signed-off-by: Ferdinand Schwenk <ferdinand.schwenk@advastore.com> Link: https://lore.kernel.org/r/20260609-hwmon-ina238-update-interval-us-v2-v3-1-016b55567950@advastore.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-09iommu/dma: Do not try to iommu_map a 0 length region in swiotlbJason Gunthorpe
iommu_dma_iova_link_swiotlb() processes a mapping that is unaligned in three parts, the head, middle and trailer. If the middle is empty because there are no aligned pages it will call down to iommu_map() with a 0 size which the iommupt implementation will fail as illegal. It then tries to do an error unwind and starts from the wrong spot corrupting the mapping so the eventual destruction triggers a WARN_ON. Check for 0 length and avoid mapping and use offset not 0 as the starting point to unlink. This is frequently triggered by using some kinds of thunderbolt NVMe drives that trigger forced SWIOTLB for unaligned memory. NVMe seems to pass in oddly aligned buffers for the passthrough commands from smartctl that hit this condition. Cc: stable@vger.kernel.org Fixes: 433a76207dcf ("dma-mapping: Implement link/unlink ranges API") Reported-by: Mark Lord <mlord@pobox.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Samiullah Khawaja <skhawaja@google.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/0-v1-8536728bc89f+469-swiotlb_warn_jgg@nvidia.com
2026-06-09RDMA/efa: Implement the query port speed verbTom Sela
Implement the query port speed callback to report the port effective bandwidth directly in 100 Mb/s granularity. Link: https://patch.msgid.link/r/20260608083927.4116-1-tomsela@amazon.com Reviewed-by: Michael Margolin <mrgolin@amazon.com> Reviewed-by: Yonatan Nachum <ynachum@amazon.com> Signed-off-by: Tom Sela <tomsela@amazon.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-09RDMA/efa: Report 800 and 1600 Gbps link speedTom Sela
Add support for reporting 800 Gbps as 8X NDR and 1600 Gbps as 8X XDR link speeds. Link: https://patch.msgid.link/r/20260608083736.48454-1-tomsela@amazon.com Reviewed-by: Michael Margolin <mrgolin@amazon.com> Reviewed-by: Yonatan Nachum <ynachum@amazon.com> Signed-off-by: Tom Sela <tomsela@amazon.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-09drm/vc4: fix krealloc() memory leakAlexander A. Klimov
Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array(). Fixes: 6d45c81d229d ("drm/vc4: Add support for branching in shader validation.") Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Signed-off-by: Maíra Canal <mcanal@igalia.com> Link: https://patch.msgid.link/20260606123817.37222-1-grandmaster@al2klimov.de
2026-06-09nvme: target: allocate ana_state with portRosen Penev
Use a flexible array member to remove one allocation. Simplifies code slightly. Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-06-09i2c: qcom-geni: Use pm_runtime_force_{suspend,resume} helpersPraveen Talari
The driver carries custom system suspend/resume handling that manually tracks a suspended state and conditionally calls geni_i2c_runtime_suspend() from the noirq suspend path, then adjusts runtime PM state by hand. This duplicates PM core behavior and adds unnecessary complexity. Drop the manual state tracking and switch to pm_runtime_force_suspend() and pm_runtime_force_resume() for system sleep. These helpers already perform the required checks, call the runtime PM callbacks when needed, and keep runtime PM state transitions consistent. Reviewed-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260520-use_pm_runtime_apis-v1-1-6a5238fc6cb6@oss.qualcomm.com
2026-06-09regulator: mt6359: Fix vbbck default internal supply nameChen-Yu Tsai
This issue was pointed out by Sashiko. vbbck is fed internally from vio18. For the MT6359, the default supply name was incorrectly set as "VIO18", instead of the supply's default "VIO18". In practice this still works, but it causes the regulator description copy and replace to always happen. For the MT6359P the name is correct. Fix the supply name for MT6359 so that both instances are the same and correct. Also copy the comment about the internal supply from the MT6359 list to the MT6359P list. Fixes: 10be8fc1d534 ("regulator: mt6359: Add regulator supply names") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20260609083630.1600070-1-wenst@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-09RDMA/mlx5: Use strscpy() to copy strings into arraysDavid Laight
Replacing strcpy() with strscpy() ensures that overflow of the target buffer cannot happen. Link: https://patch.msgid.link/r/20260608095500.2567-2-david.laight.linux@gmail.com Signed-off-by: David Laight <david.laight.linux@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-09RDMA/usnic: User strscpy() to copy device nameDavid Laight
Link: https://patch.msgid.link/r/20260606202633.5018-11-david.laight.linux@gmail.com Signed-off-by: David Laight <david.laight.linux@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-09RDMA/iwcm: User strscpy() to copy device nameDavid Laight
Link: https://patch.msgid.link/r/20260606202633.5018-10-david.laight.linux@gmail.com Signed-off-by: David Laight <david.laight.linux@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-09IB/mlx4: Fill in the access_flags if IB_MR_REREG_ACCESS is not specifiedJason Gunthorpe
Sashiko noticed mlx4 was using whatever random access flags were provided when IB_MR_REREG_ACCESS is not used. Since IB_MR_REREG_TRANS needs access_flags it used the random ones which means it doesn't work sensibly if userspace provides only IB_MR_REREG_TRANS. Keep track of the current access_flag of the MR and use it if the user does not specify one. Also fixup a little confusion around mmr.access, it is the HW access flags so the convert_access() was missing. But nothing reads this by the time rereg_mr can happen. Fixes: 9376932d0c26 ("IB/mlx4_ib: Add support for user MR re-registration") Link: https://patch.msgid.link/r/0-v1-29ca7a402625+ddd6-mlx4_rereg_flags_jgg@nvidia.com Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-09cxl/region: Avoid variable shadowing in region attach pathsAlison Schofield
A couple of symbol declarations shadow earlier variables in the region attach paths. Shadowing makes it harder to tell which object is being referenced and can obscure future bugs. Reuse the existing 'cxld' variable in cxl_port_attach_region() and rename the endpoint decoder iterator in cxl_region_attach() to avoid shadowing the function parameter. No functional change. Found with sparse. Signed-off-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Li Ming <ming.li@zohomail.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260605040504.865728-1-alison.schofield@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-06-09s390/ap: Fix locking issue in SE bind and associate sysfs functionsHarald Freudenberger
Revisit and reorganize the locking and lock coverage of the ap->lock spinlock as used in the two sysfs functions se_bind_store() and se_associate_store(). A kernel run reported a possible deadlock situation, caused by holding the spinlock (ap->lock) while triggering a uevent. The fix rearranges the code protected by the spinlock by excluding the uevent invocation, which does not require protection. Additionally, the start of the protected region is moved earlier to cover more lines, ensuring a consistent view of the AP queue state between reading and updating its struct fields. ===================================================== WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected 7.1.0-20260601.rc6.git12.516b5dbd4d4a.300.fc44.s390x+debug #1 Not tainted ----------------------------------------------------- setupseguest.sh/11034 [HC0[0]:SC0[2]:HE1:SE0] is trying to acquire: 000001c991f498e8 (fs_reclaim){+.+.}-{0:0}, at: __kmalloc_cache_noprof+0x5a/0x6d0 and this task is already holding: 000000c4a1a12378 (&aq->lock){+.-.}-{2:2}, at: se_bind_store+0x96/0x3a0 which would create a new lock dependency: (&aq->lock){+.-.}-{2:2} -> (fs_reclaim){+.+.}-{0:0} but this new dependency connects a SOFTIRQ-irq-safe lock: (&aq->lock){+.-.}-{2:2} ... which became SOFTIRQ-irq-safe at: __lock_acquire+0x5ae/0x15a0 lock_acquire+0x14c/0x400 _raw_spin_lock_bh+0x58/0xb0 ap_tasklet_fn+0x72/0xd0 tasklet_action_common+0x174/0x1b0 handle_softirqs+0x180/0x5c0 irq_exit_rcu+0x196/0x200 do_ext_irq+0x12a/0x4d0 ext_int_handler+0xc6/0xf0 folio_zero_user+0x1c6/0x240 folio_zero_user+0x182/0x240 vma_alloc_anon_folio_pmd+0xa0/0x1d0 __do_huge_pmd_anonymous_page+0x3a/0x200 __handle_mm_fault+0x56c/0x590 handle_mm_fault+0xa2/0x370 do_exception+0x292/0x590 __do_pgm_check+0x136/0x3e0 pgm_check_handler+0x114/0x160 to a SOFTIRQ-irq-unsafe lock: (fs_reclaim){+.+.}-{0:0} ... which became SOFTIRQ-irq-unsafe at: ... __lock_acquire+0x5ae/0x15a0 lock_acquire+0x14c/0x400 __fs_reclaim_acquire+0x44/0x50 fs_reclaim_acquire+0xbe/0x100 fs_reclaim_correct_nesting+0x20/0x70 dotest+0x5e/0x148 locking_selftest+0x2854/0x2a88 start_kernel+0x3b2/0x4f0 startup_continue+0x2e/0x40 other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); local_irq_disable(); lock(&aq->lock); lock(fs_reclaim); <Interrupt> lock(&aq->lock); *** DEADLOCK *** 4 locks held by setupseguest.sh/11034: #0: 000000c485d01440 (sb_writers#4){.+.+}-{0:0}, at: vfs_write+0x2fc/0x380 #1: 000000c4d2283288 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x12a0x270 #2: 000000c4a1830e48 (kn->active#172){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x1e/0x270 #3: 000000c4a1a12378 (&aq->lock){+.-.}-{2:2}, at: se_bind_store+0x96/0x3a0 the dependencies between SOFTIRQ-irq-safe lock and the holding lock: -> (&aq->lock){+.-.}-{2:2} { HARDIRQ-ON-W at: __lock_acquire+0x5ae/0x15a0 lock_acquire+0x14c/0x400 _raw_spin_lock_bh+0x58/0xb0 ap_queue_init_state+0x2e/0x50 ap_scan_domains+0x5d6/0x620 ap_scan_adapter+0x4c0/0x810 ap_scan_bus+0x70/0x350 ap_scan_bus_wq_callback+0x56/0x80 process_one_work+0x2ba/0x820 worker_thread+0x21a/0x400 kthread+0x164/0x190 __ret_from_fork+0x4c/0x340 ret_from_fork+0xa/0x30 IN-SOFTIRQ-W at: __lock_acquire+0x5ae/0x15a0 lock_acquire+0x14c/0x400 _raw_spin_lock_bh+0x58/0xb0 ap_tasklet_fn+0x72/0xd0 tasklet_action_common+0x174/0x1b0 handle_softirqs+0x180/0x5c0 irq_exit_rcu+0x196/0x200 do_ext_irq+0x12a/0x4d0 ext_int_handler+0xc6/0xf0 folio_zero_user+0x1c6/0x240 folio_zero_user+0x182/0x240 vma_alloc_anon_folio_pmd+0xa0/0x1d0 __do_huge_pmd_anonymous_page+0x3a/0x200 __handle_mm_fault+0x56c/0x590 handle_mm_fault+0xa2/0x370 do_exception+0x292/0x590 __do_pgm_check+0x136/0x3e0 pgm_check_handler+0x114/0x160 INITIAL USE at: __lock_acquire+0x5ae/0x15a0 lock_acquire+0x14c/0x400 _raw_spin_lock_bh+0x58/0xb0 ap_queue_init_state+0x2e/0x50 ap_scan_domains+0x5d6/0x620 ap_scan_adapter+0x4c0/0x810 ap_scan_bus+0x70/0x350 ap_scan_bus_wq_callback+0x56/0x80 process_one_work+0x2ba/0x820 worker_thread+0x21a/0x400 kthread+0x164/0x190 __ret_from_fork+0x4c/0x340 ret_from_fork+0xa/0x30 } ... key at: [<000001c9936e8aa0>] __key.7+0x0/0x10 the dependencies between the lock to be acquired and SOFTIRQ-irq-unsafe lock: -> (fs_reclaim){+.+.}-{0:0} { HARDIRQ-ON-W at: __lock_acquire+0x5ae/0x15a0 lock_acquire+0x14c/0x400 __fs_reclaim_acquire+0x44/0x50 fs_reclaim_acquire+0xbe/0x100 fs_reclaim_correct_nesting+0x20/0x70 dotest+0x5e/0x148 locking_selftest+0x2854/0x2a88 start_kernel+0x3b2/0x4f0 startup_continue+0x2e/0x40 SOFTIRQ-ON-W at: __lock_acquire+0x5ae/0x15a0 lock_acquire+0x14c/0x400 __fs_reclaim_acquire+0x44/0x50 fs_reclaim_acquire+0xbe/0x100 fs_reclaim_correct_nesting+0x20/0x70 dotest+0x5e/0x148 locking_selftest+0x2854/0x2a88 start_kernel+0x3b2/0x4f0 startup_continue+0x2e/0x40 INITIAL USE at: __lock_acquire+0x5ae/0x15a0 lock_acquire+0x14c/0x400 __fs_reclaim_acquire+0x44/0x50 fs_reclaim_acquire+0xbe/0x100 fs_reclaim_correct_nesting+0x20/0x70 dotest+0x5e/0x148 locking_selftest+0x2854/0x2a88 start_kernel+0x3b2/0x4f0 startup_continue+0x2e/0x40 } ... key at: [<000001c991f498e8>] __fs_reclaim_map+0x0/0x30 ... acquired at: check_prev_add+0x178/0xf40 __lock_acquire+0x12aa/0x15a0 lock_acquire+0x14c/0x400 __fs_reclaim_acquire+0x44/0x50 fs_reclaim_acquire+0xbe/0x100 __kmalloc_cache_noprof+0x5a/0x6d0 kobject_uevent_env+0xd4/0x420 ap_send_se_bind_uevent+0x48/0x70 se_bind_store+0x146/0x3a0 kernfs_fop_write_iter+0x18c/0x270 vfs_write+0x23c/0x380 ksys_write+0x88/0x120 __do_syscall+0x170/0x750 system_call+0x72/0x90 stack backtrace: CPU: 6 UID: 0 PID: 11034 Comm: setupseguest.sh Not tainted 7.1.0-20260601.rc6.git2.516b5dbd4d4a.300.fc44.s390x+debug #1 PREEMPT Hardware name: IBM 9175 ME1 701 (KVM/Linux) Call Trace: [<000001c98ffa0a7e>] dump_stack_lvl+0xae/0x108 [<000001c9900a6d7a>] print_bad_irq_dependency+0x47a/0x480 [<000001c9900a7184>] check_irq_usage+0x404/0x4c0 [<000001c9900a73b8>] check_prev_add+0x178/0xf40 [<000001c9900aaf1a>] __lock_acquire+0x12aa/0x15a0 [<000001c9900ab35c>] lock_acquire+0x14c/0x400 [<000001c9903be454>] __fs_reclaim_acquire+0x44/0x50 [<000001c9903be51e>] fs_reclaim_acquire+0xbe/0x100 [<000001c9903cf4ca>] __kmalloc_cache_noprof+0x5a/0x6d0 [<000001c9910ca9d4>] kobject_uevent_env+0xd4/0x420 [<000001c990d84098>] ap_send_se_bind_uevent+0x48/0x70 [<000001c990d87416>] se_bind_store+0x146/0x3a0 [<000001c99057da7c>] kernfs_fop_write_iter+0x18c/0x270 [<000001c99047712c>] vfs_write+0x23c/0x380 [<000001c990477438>] ksys_write+0x88/0x120 [<000001c9910f64e0>] __do_syscall+0x170/0x750 [<000001c99110a412>] system_call+0x72/0x90 INFO: lockdep is turned off. Fixes: 4179c3984227 ("s390/ap: Implement SE bind and associate uevents") Reported-by: Ingo Franzki <ifranzki@linux.ibm.com> Suggested-by: Finn Callies <fcallies@linux.ibm.com> Reviewed-by: Finn Callies <fcallies@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-09nvme: fix crash and memory leak during invalid cdev teardownMaurizio Lombardi
In the NVMe multipath code, if nvme_add_ns_head_cdev() fails during nvme_mpath_set_live(), the error is ignored. However, during teardown, nvme_remove_head() unconditionally calls nvme_cdev_del(). This teardown asymmetry leads to a kernel panic if the character device was never successfully initialized. BUG: kernel NULL pointer dereference, address: 00000000000000d0 device_del+0x39/0x3c0 cdev_device_del+0x15/0x50 nvme_cdev_del+0xe/0x20 [nvme_core] nvme_mpath_shutdown_disk+0x38/0x60 [nvme_core] nvme_ns_remove+0x177/0x1f0 [nvme_core] nvme_remove_namespaces+0xdc/0x130 [nvme_core] nvme_do_delete_ctrl+0x71/0xd0 [nvme_core] Additionally, a memory leak exists in the nvme_cdev_add() failure path. Previously, dev_set_name() was called before ida_alloc(). If ida_alloc() subsequently failed, device_initialize() was never called, meaning put_device() could not be used to clean up the kobject, leaking the memory allocated by dev_set_name(). * Introduces the NVME_NSHEAD_CDEV_LIVE and NVME_NS_CDEV_LIVE bits to track the successful creation of the character devices. Teardown routines now check these bits before attempting deletion. * Refactor nvme_cdev_add() to accept the formatted device name as a parameter, moving dev_set_name() after the IDA allocation and immediately before device_initialize(). This ensures any internally allocated strings are safely cleaned up by put_device() upon failure. Signed-off-by: Maurizio Lombardi <mlombard@redhat.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-06-09net: ethtool: optionally skip rtnl_lock on Netlink path for SET opsJakub Kicinski
Make ethtool not take rtnl_lock for SET commands when operation is performed on an ops-locked driver. cfg/cfg_pending are now ops-locked, since only ethtool modifies them. Some SET driver callbacks will still need rtnl_lock, most notably those which may end up calling netdev_update_features() or the qdisc layer (via netif_set_real_num_tx_queues()). Let drivers selectively opt back into the rtnl_lock with a new bitfield in ops. We need two helpers since Netlink and ioctl cmds have different values. Keep the helpers side by side in common.h to make sure they get updated together, even tho they will only get called from ioctl.c and netlink.c. SET commands which don't use ethnl_default_set_doit() are converted by subsequent commits. Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260605002912.3456868-6-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09net: ethtool: optionally skip rtnl_lock on Netlink path for GET opsJakub Kicinski
ethnl_default_doit() and ethnl_default_dump_one() are both used exclusively for GET callbacks (former to get info for a single device or get global strings). ops-locked devices don't need rtnl_lock for GET callbacks, stop taking it. Introduce an opt-out mechanism for devices which use phylink (fbnic) since phylink currently depends on rtnl_lock protection. Subsequent patches will add more exceptions, anyway. Practically the new helpers for judging if command needs rtnl_lock could also call netdev_need_ops_lock() but I find that it makes the code in the callers slightly less obvious. Add a helper for IOCTLs already, even tho it's unused so that we can keep them in sync as the series progresses. This is the first user-visible step of moving ethtool ops out from under rtnl. Subsequent patches do the same for SET ops, as well as the ioctl path. Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260605002912.3456868-5-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09net: ethtool: make dev->hwprov ops-protectedJakub Kicinski
dev->hwprov tracks the active hwtstamp provider for the device. Make it ops protected (instance lock if the netdev driver opts into holding instance lock around callbacks, otherwise rtnl_lock). hwprov is written and read in: - drivers/net/phy/phy_device.c phydev and ops protection don't currently mix, add a comment - net/ethtool/ as of now holds both rtnl lock and ops lock, this one will soon only hold one lock or the other read in: - net/core/dev_ioctl.c holds both rtnl lock and ops lock - net/core/timestamping.c RCU reader The new netdev_ops_lock_dereference() helper does not have "compat" in the name. The name would be quite long and I think in this case it should be obvious that we need _a_ lock. netdev_lock_dereference() already exists and means dev->lock is always expected. Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260605002912.3456868-4-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09net: ethtool: relax ethnl_req_get_phydev() locking assertionJakub Kicinski
phydev <> netdev linking and lifecycle depends on rtnl_lock. We want to switch to instance locks for most ethtool ops. Let's add an assert that ops locked devices don't use phydev today. If one does we can either opt the phy ops out of being purely ops locked, or do deeper surgery to make phy locking ops-compatible. I don't think there's any fundamental challenge to make that work. Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260605002912.3456868-3-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09igc: skip RX timestamp header for frame preemption verificationKhaiWenTan
When RX hardware timestamping is enabled, a 16-byte inline timestamp header is added to the start of the packet buffer, causing FPE handshake verification to fail. Because an incorrect packet buffer is passed to igc_fpe_handle_mpacket(), the mem_is_zero() check inspects the timestamp metadata instead of the actual mPacket payload. As a result, valid Verify/Response mPackets can be missed when inline RX timestamps are present. Pass pktbuf + pkt_offset to igc_fpe_handle_mpacket() so it inspects the actual mPacket payload instead of the timestamp header. Fixes: 5422570c0010 ("igc: add support for frame preemption verification") Co-developed-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com> Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com> Signed-off-by: KhaiWenTan <khai.wen.tan@linux.intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-06-09ixgbe: do not configure xps for XDP queuesLarysa Zaremba
netif_set_xps_queue() should not be called for an XDP Tx queue, since such queues are not netdev-exposed. On systems with number of CPUs >=64, on E610 adapter, netdev is configured with maximum number queue pairs being 63 (due to MSI-X assignment), but configuring XDP results in 64 XDP queues. So, during XDP program load, when netif_set_xps_queue() is called for the last XDP queue, we get a WARNING with a call trace and KASAN report afterwards (if enabled). [ 2012.699800] WARNING: net/core/dev.c:2854 at __netif_set_xps_queue+0x116a/0x1e40, CPU#36: xdpsock/103668 [...] [ 2012.700029] RIP: 0010:__netif_set_xps_queue+0x116a/0x1e40 [ 2012.700035] Code: b6 34 06 48 89 f8 83 e0 07 83 c0 01 40 38 f0 7c 09 40 84 f6 0f 85 03 0a 00 00 0f b7 44 24 40 66 43 89 44 6a 18 e9 01 fb ff ff <0f> 0b e9 f2 ee ff ff 44 8b 44 24 44 45 85 c0 74 50 4d 85 e4 0f 84 [ 2012.700040] RSP: 0018:ffff8882369aeb28 EFLAGS: 00010246 [ 2012.700046] RAX: 0000000000000000 RBX: 000000000000003f RCX: 0000000000000000 [ 2012.700050] RDX: 1ffff1111da3d891 RSI: ffff888120e34250 RDI: ffff8888ed1ec488 [ 2012.700054] RBP: ffff888913281560 R08: 0000000000000000 R09: ffff8888ed1ec000 [ 2012.700058] R10: ffff8888a2e83180 R11: 0000000000000000 R12: 0000000000007fa8 [ 2012.700061] R13: 000000000000003f R14: ffff888120e34854 R15: ffff8889132817c8 [ 2012.700065] FS: 00007fc8ea9ff740(0000) GS:ffff88884cefe000(0000) knlGS:0000000000000000 [ 2012.700069] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2012.700073] CR2: 00007f81c8000020 CR3: 00000002299f8006 CR4: 00000000007726f0 [ 2012.700077] PKRU: 55555554 [ 2012.700080] Call Trace: [ 2012.700084] <TASK> [ 2012.700087] ? ktime_get+0x61/0x150 [ 2012.700097] ? usleep_range_state+0x133/0x1b0 [ 2012.700108] ? __pfx_usleep_range_state+0x10/0x10 [ 2012.700114] netif_set_xps_queue+0x31/0x50 [ 2012.700119] ixgbe_configure_tx_ring+0x472/0x920 [ixgbe] [...] [ 2012.700486] ixgbe_xdp+0x38f/0x750 [ixgbe] [...] [ 2012.701094] BUG: KASAN: slab-out-of-bounds in __netif_set_xps_queue+0x1ac5/0x1e40 [ 2012.701100] Write of size 4 at addr ffff88888d43cff8 by task xdpsock/103668 Skip XPS configuration for XDP Tx queues. Fixes: 33fdc82f0883 ("ixgbe: add support for XDP_TX action") Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Patryk Holda <patryk.holda@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-06-09idpf: add padding to PTP virtchnl structuresPrzemyslaw Korba
Add padding to virtchnl2 PTP structures to match the Control Plane expected message sizes: * virtchnl2_ptp_get_dev_clk_time: 8 -> 16 bytes * virtchnl2_ptp_set_dev_clk_time: 8 -> 16 bytes * virtchnl2_ptp_get_cross_time: 16 -> 24 bytes The FW expects the above sizes and PTP negotiation fails due to the mismatch. Previously neither the FW nor the driver checked message/reply sizes strictly, so the problem appeared only after recent validation improvements. reproduction steps: ptp4l -i <pf> -m Observe: failed to open /dev/ptp0: Permission denied Fixes: bf27283ba594 ("virtchnl: add PTP virtchnl definitions") Cc: stable@vger.kernel.org Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Signed-off-by: Przemyslaw Korba <przemyslaw.korba@intel.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-06-09PCI: mediatek: Fix IRQ domain leak when port fails to enableManivannan Sadhasivam
When mtk_pcie_enable_port() fails, mtk_pcie_port_free() removes the port from pcie->ports and frees the port structure. However, the IRQ domains set up earlier by mtk_pcie_init_irq_domain() are never freed. Fix this by refactoring mtk_pcie_irq_teardown() into a per-port helper, mtk_pcie_irq_teardown_port(), and calling it from mtk_pcie_setup() when mtk_pcie_enable_port() fails. Since the IRQ teardown must only happen in the probe error path (during resume, child devices may have active MSI mappings and the NOIRQ context prohibits sleeping locks), mtk_pcie_enable_port() is changed to return an error code so callers can distinguish the two paths and act accordingly. This issue was reported by Sashiko while reviewing the EcoNet EN7528 SoC support series. Fixes: b099631df160 ("PCI: mediatek: Add controller support for MT2712 and MT7622") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Cc: stable@vger.kernel.org # 5.10 Cc: Caleb James DeLisle <cjd@cjdns.fr> Link: https://patch.msgid.link/20260521174617.17692-1-mani@kernel.org
2026-06-09cxl: Fix CXL_HEADERLOG_SIZE to match RAS Capability sizeTerry Bowman
The CXL r4.0 8.2.4.17.7 RAS Capability Structure has total length 0x58 bytes (CXL_RAS_CAPABILITY_LENGTH); the Header Log occupies the trailing 64 bytes at offset 0x18. CXL_HEADERLOG_SIZE was defined as SZ_512, eight times the actual on-device size. header_log_copy() reads CXL_HEADERLOG_SIZE_U32 (128) dwords from the RAS capability iomap, overrunning the 88-byte mapping by 448 bytes. The cxl_aer_uncorrectable_error trace event memcpy()s CXL_HEADERLOG_SIZE (512) bytes from its source. For the CPER caller the source is struct cxl_ras_capability_regs::header_log[16] (64 bytes) embedded in a stack-local cxl_cper_prot_err_work_data, so the memcpy reads 448 bytes of kernel stack into the trace event ring buffer where userspace can read it via tracefs. Set CXL_HEADERLOG_SIZE to 64 and derive CXL_HEADERLOG_SIZE_U32 from it, bringing all iomap readers into agreement on 16 dwords. Userspace tools such as rasdaemon have grown a dependency on the buggy 512-byte (128 u32) header_log layout in the cxl_aer_uncorrectable_error trace event. Add CXL_HEADERLOG_TRACE_SIZE_U32 = 128 and use it for the trace event __array and its memcpy to preserve that ABI. Both callers now pass a zero-filled u32[CXL_HEADERLOG_TRACE_SIZE_U32] staging buffer with only the first CXL_HEADERLOG_SIZE_U32 (16) entries populated from hardware; the remaining 112 u32s are zero-padded, keeping the 512-byte trace ring buffer layout intact. [ dj: Replaced 64 with SZ_64 per RichardC ] Fixes: 36f257e3b0ba ("acpi/ghes, cxl/pci: Process CXL CPER Protocol Errors") Fixes: 2905cb5236cb ("cxl/pci: Add (hopeful) error handling support") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Terry Bowman <terry.bowman@amd.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Ben Cheatham <benjamin.cheatham@amd.com> Reviewed-by: Richard Cheng <icheng@nvidia.com> Link: https://patch.msgid.link/20260605180610.2249458-1-terry.bowman@amd.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-06-09nvmet: fix refcount leak in nvmet_sq_create()Wentao Liang
In nvmet_sq_create(), a reference on the ctrl is taken via kref_get_unless_zero() before calling nvmet_check_sqid(). If nvmet_check_sqid() fails, the function returns the error directly without releasing the reference, leading to a leak. Fix this by jumping to the "ctrl_put" label, which already performs the necessary nvmet_ctrl_put(ctrl). This ensures the reference is properly released on this error path. Cc: stable@vger.kernel.org Fixes: 1eb380caf527 ("nvmet: Introduce nvmet_sq_create() and nvmet_cq_create()") Signed-off-by: Wentao Liang <vulab@iscas.ac.cn> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-06-09PCI: meson: Add missing remove callbackShuvam Pandey
meson_pcie_probe() powers on the PHY and registers the DesignWare host bridge with dw_pcie_host_init(), but the driver has no remove callback. On driver unbind or module unload, the driver core therefore proceeds to devres cleanup without first unregistering the host bridge or powering off the PHY. Add a remove callback that deinitializes the DesignWare host bridge and powers off the PHY while device-managed resources are still valid. Fixes: 9c0ef6d34fdb ("PCI: amlogic: Add the Amlogic Meson PCIe controller driver") Signed-off-by: Shuvam Pandey <shuvampandey1@gmail.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/1a0c86ab264cdc1c79c917e984b90991af51d827.1779123847.git.shuvampandey1@gmail.com
2026-06-09PCI: meson: Propagate devm_add_action_or_reset() failureShuvam Pandey
meson_pcie_probe_clock() enables a clock and then registers a devres action to disable it during teardown. If devm_add_action_or_reset() fails, it runs the action immediately, disabling the clock. The return value is currently ignored, so on that failure path, meson_pcie_probe_clock() returns the disabled clock and probe continues. Return the error so the existing probe error path unwinds normally. Fixes: 9c0ef6d34fdbf ("PCI: amlogic: Add the Amlogic Meson PCIe controller driver") Signed-off-by: Shuvam Pandey <shuvampandey1@gmail.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/177909148011.9588.6639767953842842291@gmail.com
2026-06-09virtio-blk: clamp zone report to the report buffer capacityMichael Bommarito
virtblk_report_zones() trusts the device-reported number of zones when walking the report buffer: nz = min_t(u64, virtio64_to_cpu(vblk->vdev, report->nr_zones), nr_zones); ... for (i = 0; i < nz && zone_idx < nr_zones; i++) { ret = virtblk_parse_zone(vblk, &report->zones[i], ...); The buffer is allocated by virtblk_alloc_report_buffer(), whose size is capped by the queue's max hardware sectors and max segments and can therefore hold fewer descriptors than nr_zones. nz is bounded only by the device-supplied report->nr_zones and the requested nr_zones, never by the buffer's descriptor capacity. At probe time the request count is unbounded (blk_revalidate_disk_zones() calls report_zones() with nr_zones == UINT_MAX), so the device-supplied report->nr_zones is the sole gate: a device that reports more zones than fit in the buffer drives the loop to read report->zones[i] past the end of the allocation. A malicious or buggy virtio-blk device that reports an inflated nr_zones triggers this during zone revalidation at probe. KASAN reports a vmalloc-out-of-bounds read in virtblk_report_zones() against the report buffer allocated a few lines earlier. Clamp nz to the number of descriptors that actually fit in the report buffer. Fixes: 95bfec41bd3d ("virtio-blk: add support for zoned block devices") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Link: https://patch.msgid.link/20260607124834.3059944-1-michael.bommarito@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-06-09PCI: imx6: Assert ref_clk_en after reference clock stabilizes on i.MX95Richard Zhu
According to the PHY Databook Common Block Signals section, the ref_clk_en signal must remain de-asserted until the reference clock is running at the appropriate frequency. Once the clock is stable, ref_clk_en can be asserted. For lower power states where the reference clock to the PHY is disabled, ref_clk_en should also be de-asserted. Move the ref_clk_en bit manipulation into imx95_pcie_enable_ref_clk() to ensure the reference clock stabilizes before ref_clk_en is asserted and before the PHY reset is de-asserted. This aligns with the timing requirements specified in the PHY documentation. Fixes: d8574ce57d76 ("PCI: imx6: Add external reference clock input mode support") Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260518072715.3166514-3-hongxing.zhu@nxp.com
2026-06-09PCI: imx6: Configure REF_USE_PAD before PHY reset for i.MX95Richard Zhu
According to the i.MX95 PCIe PHY Databook, the ref_use_pad signal in the Common Block Signals section selects the reference clock source connected to the PHY pads. Per the specification, any change to this input must be followed by a PHY reset assertion to take effect. Move the REF_USE_PAD configuration before the PHY reset toggle to comply with the required initialization sequence. Fixes: 47f54a902dcd ("PCI: imx6: Toggle the core reset for i.MX95 PCIe") Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> [mani: renamed the callback and helper to match the usecase] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260518072715.3166514-2-hongxing.zhu@nxp.com
2026-06-09gpio: gpio-ltc4283: Add support for the LTC4283 Swap ControllerNuno Sá
The LTC4283 device has up to 8 pins that can be configured as GPIOs. Note that PGIO pins are not set as GPIOs by default so if they are configured to be used as GPIOs we need to make sure to initialize them to a sane default. They are set as inputs by default. Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20260502-ltc4283-support-v13-3-1c206542e652@analog.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-09hwmon: ltc4283: Add support for the LTC4283 Swap ControllerNuno Sá
Support the LTC4283 Hot Swap Controller. The device features programmable current limit with foldback and independently adjustable inrush current to optimize the MOSFET safe operating area (SOA). The SOA timer limits MOSFET temperature rise for reliable protection against overstresses. An I2C interface and onboard ADC allow monitoring of board current, voltage, power, energy, and fault status. Signed-off-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20260502-ltc4283-support-v13-2-1c206542e652@analog.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-09Merge tag 'mm-hotfixes-stable-2026-06-08-20-51' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "11 hotfixes. 9 are for MM. 8 are cc:stable and the remaining 3 address post-7.1 issues or aren't considered suitable for backporting. Thre's a two-patch series "mm/damon/{reclaim,lru_sort}: handle ctx allocation failures" from SeongJae Park which fixes a couple of DAMON -ENOMEM bloopers. The rest are singletons - please see the individual changelogs for details" * tag 'mm-hotfixes-stable-2026-06-08-20-51' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm/mincore: handle non-swap entries before !CONFIG_SWAP guard arm64: mm: call pagetable dtor when freeing hot-removed page tables mm/list_lru: drain before clearing xarray entry on reparent mm/huge_memory: use correct flags for device private PMD entry mm/damon/lru_sort: handle ctx allocation failure mm/damon/reclaim: handle ctx allocation failure zram: fix use-after-free in zram_bvec_write_partial() MAINTAINERS: update Baoquan He's email address tools headers UAPI: sync linux/taskstats.h for procacct.c mm/cma_sysfs: skip inactive CMA areas in sysfs ipc/shm: serialize orphan cleanup with shm_nattch updates
2026-06-09hwmon: (pmbus/xdp720) Fix driver issues xdp720/730Ashish Yadav
Fix driver issues: - Add the missing regulator and property files in include - Declare XDP720_DEFAULT_RIMON as unsigned constant - Declare struct pmbus_driver_info xdp720_info as constant Signed-off-by: Ashish Yadav <ashish.yadav@infineon.com> Link: https://lore.kernel.org/r/20260609072231.15486-4-Ashish.Yadav@infineon.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-09hwmon: (pmbus/xdp720) Add support for efuse xdp730Ashish Yadav
Adds support for the Infineon XDP730 Digital eFuse Controller by updating the existing XDP720 driver. Signed-off-by: Ashish Yadav <ashish.yadav@infineon.com> Link: https://lore.kernel.org/r/20260609072231.15486-3-Ashish.Yadav@infineon.com [groeck: Fixed conflicts in xdp720_id declaration] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-09hwmon: (adt7462) Add of_match_table to support devicetreeKory Maincent
Add of_match_table to add support of devicetree probing. Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> [rgantois: Removed of_match_ptr().] Signed-off-by: Romain Gantois <romain.gantois@bootlin.com> Link: https://lore.kernel.org/r/20260608-adt7462-bindings-v2-1-272982c40325@bootlin.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-09hwmon: (asus-ec-sensors) add ROG MAXIMUS Z790 EXTREMEBrian Downey
Add support for ROG MAXIMUS Z790 EXTREME Signed-off-by: Brian Downey <bdowne01@gmail.com> Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com> Link: https://lore.kernel.org/r/20260608060855.40469-1-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-09hwmon: (pmbus/max20860a) Add driver for Analog Devices MAX20860ASyed Arif
Add a PMBus driver for the Analog Devices MAX20860A step-down DC-DC switching regulator. The MAX20860A provides monitoring of input/output voltage, output current, and temperature via the PMBus interface using linear data format. Optional regulator support is available via CONFIG_SENSORS_MAX20860A_REGULATOR. Signed-off-by: Syed Arif <arif.syed@hpe.com> Signed-off-by: Sanman Pradhan <psanman@juniper.net> Link: https://lore.kernel.org/r/20260601184516.919488-3-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-09hwmon: (pmbus) Add support for Flex BMR316, BMR321, BMR350 and BMR351Daniel Nilsson
Add support for BMR316, BMR321, BMR350 and BMR351 DC/DC converter modules from Flex to the pmbus driver. Signed-off-by: Daniel Nilsson <linux@erq.se> Link: https://lore.kernel.org/r/20260603085712.659432-2-linux@erq.se [groeck: Resolved conflicts (explicit struct members in pmbus_id)] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-09hwmon: Use named initializers for platform_device_id arraysUwe Kleine-König (The Capable Hub)
Named initializers are better readable and more robust to changes of the struct definition. This robustness is relevant for a planned change to struct platform_device_id replacing .driver_data by an anonymous unit. While touching these arrays unify usage of commas. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/25d38df8db42d69f33fa30267c9fd5ea058223d0.1779894738.git.u.kleine-koenig@baylibre.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-09hwmon: (cros_ec) Drop unused assignment of platform_device_id driver dataUwe Kleine-König (The Capable Hub)
The driver explicitly set the .driver_data member of struct platform_device_id to zero without relying on that value. Drop this unused assignments. While touching this array unify spacing and use named initializers for .name. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Acked-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/972c9998054c7944f63266819d6fb08b36edb5c5.1779894738.git.u.kleine-koenig@baylibre.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-09hwmon: (it87) Clamp negative values to zero in set_fan()Nikita Zhandarovich
set_fan() parses user input with kstrtol() and passes the resulting value to FAN16_TO_REG() on chips with 16-bit fan support. Negative fan speeds are not meaningful and should be rejected before conversion. Worst scenario, one may be able to abuse undefined behaviour of signed overflow to possibly induce rpm * 2 == 0 in FAN16_TO_REG(), thus causing a division by zero. Instead, clamp val < 0 to zero and keep the conversion in its valid input domain, avoiding unsafe arithmetic in the register conversion path. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: 17d648bf5786 ("it87: Add support for the IT8716F") Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru> Link: https://lore.kernel.org/r/20260529141839.1639287-1-n.zhandarovich@fintech.ru Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-09hwmon: (asus-ec-sensors) add ROG STRIX B850-E GAMING WIFIEugene Shalygin
The board has a similar sensor configuration to the ROG STRIX B850-I GAMING WIFI, but includes an additional T-Sensor header. The patch was provided via GitHub [1]. [1] https://github.com/zeule/asus-ec-sensors/pull/105 Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com> Link: https://lore.kernel.org/r/20260607123626.100630-1-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-09hwmon: (asus-ec-sensors) add ROG STRIX B650E-E GAMING WIFIVeronika Kossmann
Add support for ROG STRIX B650E-E GAMING WIFI Signed-off-by: Veronika Kossmann <nanodesuu@gmail.com> Co-developed-by: Oleg Tsvetkov <oleg-tsv@yandex.ru> Signed-off-by: Oleg Tsvetkov <oleg-tsv@yandex.ru> Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com> Link: https://lore.kernel.org/r/20260607110702.84599-2-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-09hwmon: (nct6683) Add support for ASRock Z890 Pro-AReiner Pröls
Add the ASRock Z890 Pro-A customer ID to the list of supported boards for the NCT6683 hardware monitoring driver. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Reiner Pröls <reiner.proels@gmail.com> Link: https://lore.kernel.org/r/20260521212632.223724-1-Reiner.Proels@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-09hwmon: (adt7475) Add explicit header includeFlaviu Nistor
Since device_property_read_string() and similar functions defined in linux/property.h are used in the driver add explicit include for linux/mod_devicetable.h and linux/property.h rather than having implicit inclusions. Removed of_match_ptr() improving non-Device Tree compatibility of the driver and drop unnecessary __maybe_unused. Header linux/of.h can't be removed yet since macro is_of_node() is used. Signed-off-by: Flaviu Nistor <flaviu.nistor@gmail.com> Link: https://lore.kernel.org/r/20260522052352.12139-1-flaviu.nistor@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-09hwmon: (lm63) expose PWM frequency and LUT hysteresis as writableJan-Henrik Bruhn
The driver caches the PWM frequency register and the CONFIG_FAN slow-clock select bit, but never lets userspace pick a different output frequency. Add a pwm1_freq sysfs attribute that selects the closest SCS + PFR combination for the requested value in Hz, gated by manual mode like set_pwm1(). PFR is clamped to 31 so that 2*PFR fits in the chip's 6-bit PWM register (matching the existing scaling assumption in show_pwm1). The hardware LUT hysteresis register is shared by all LUT entries, so the per-point pwm1_auto_pointN_temp_hyst attributes can't be made RW without N-to-1 cross-attribute side effects. Following the max31760 precedent, expose a single chip-wide pwm1_auto_point_temp_hyst attribute holding the hysteresis amount in millidegrees; the per-point attributes stay RO and continue to show the resulting absolute trip-down temperature for each entry. This was tested on a Linksys LGS328MPC switch hardware where the fan would not spin with the default PWM Frequency, which is why this change is required. Signed-off-by: Jan-Henrik Bruhn <kernel@jhbruhn.de> Link: https://lore.kernel.org/r/20260523133617.3439102-1-kernel@jhbruhn.de Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-09hwmon: (pmbus/adm1266) add rtc debugfs entryAbdurrahman Hussain
The driver seeds the chip's SET_RTC register once at probe with ktime_get_real_seconds(). Over a long uptime the chip's internal seconds counter drifts away from the host's wall-clock time, so the timestamp embedded in each blackbox record stops being meaningful in wall-clock terms. The datasheet recommends that the host periodically resynchronise the counter to address this; today the driver has no userspace-facing knob for that. Expose SET_RTC via an rtc debugfs file alongside the other adm1266 debugfs entries: read -- returns the chip's current SET_RTC seconds counter, so userspace can observe how far the chip has drifted from host wall-clock without writing anything. write -- the kernel re-reads ktime_get_real_seconds() itself and pushes it to the chip. The write payload is ignored; userspace does not get to supply its own timestamp value, so there is no way for it to push a wrong time into the chip. A small userspace agent (chrony hook, systemd-timesyncd dispatch script, or a periodic cron job) can write to this file to keep the chip's counter aligned with wall-clock across long uptimes. Both the read and write paths take pmbus_lock to serialise against the pmbus_core's own PAGE+register sequences and against the other adm1266 debugfs accessors that already run under the same lock. While at it, drop the now-redundant adm1266_set_rtc() probe-time helper. The new adm1266_rtc_set() callback does exactly the same byte-packing and write; probe just calls adm1266_rtc_set(client, 0) (the ignored @val argument) after pmbus_do_probe() so the pmbus_lock acquired by the new helper has a live mutex to take. Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai> Assisted-by: Claude-Code:claude-opus-4-7 Assisted-by: sashiko:gemini-3.1-pro-preview Link: https://lore.kernel.org/r/20260520-adm1266-v5-3-c72ef1fac1ea@nexthop.ai Signed-off-by: Guenter Roeck <linux@roeck-us.net>
generated by cgit v1.2.3 (git 2.39.1) at 2026-07-13 04:57:28 +0000