summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-10-17HID: intel-ish-hid: ipc: Always schedule FW reset work on RESET_NOTIFY/ACKZhang Lixu
Both ISH firmware and driver can actively send MNG_RESET_NOTIFY to initiate an FW reset handshake. Upon receiving this, the peer should reply with MNG_RESET_NOTIFY_ACK. Therefore, the driver should schedule the FW reset handshake work function when receiving either MNG_RESET_NOTIFY or MNG_RESET_NOTIFY_ACK. Previously, driver only scheduled the work function on MNG_RESET_NOTIFY. This patch ensures the work function is scheduled on both messages, but only replies with MNG_RESET_NOTIFY_ACK when receiving MNG_RESET_NOTIFY. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17HID: intel-ish-ipc: Reset clients state on resume from D3Zhang Lixu
When ISH resumes from D3, the connection between ishtp clients and firmware is lost. The ish_resume() function schedules resume_work asynchronously to re-initiate the connection and then returns immediately. This can cause a race where the upper-layer ishtp client driver's .resume() may execute before the connection is fully restored, leaving the client in a stale connected state. If the client sends messages during this window, the firmware cannot respond. To avoid this, reset the ishtp clients' state before returning from ish_resume() if ISH is resuming from D3. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17HID: intel-ishtp-hid: Clear suspended flag only after connected on resumeZhang Lixu
When resuming from suspend-to-RAM or hibernate, the ISH firmware is powered on from D3, causing all previous client connections between the firmware and driver to be lost. Although the underlying ishtp bus driver initiates a client reconnection flow, this process is asynchronous. As a result, when hid_ishtp_cl_resume_handler() is executed, the connection may not have been re-established yet. Clearing the suspended flag prematurely in this scenario can lead to a timeout when the upper-layer HID sensor driver set feature during resume. To prevent such timeouts, only clear the suspended flag after confirming that the connection state is ISHTP_CL_CONNECTED. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17HID: intel-ish-hid: Add ishtp_get_connection_state() interfaceZhang Lixu
Add the ishtp_get_connection_state() function for struct ishtp_cl, allowing ishtp client drivers to retrieve the current connection state. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17HID: intel-ish-hid: Use dedicated unbound workqueues to prevent resume blockingZhang Lixu
During suspend/resume tests with S2IDLE, some ISH functional failures were observed because of delay in executing ISH resume handler. Here schedule_work() is used from resume handler to do actual work. schedule_work() uses system_wq, which is a per CPU work queue. Although the queuing is not bound to a CPU, but it prefers local CPU of the caller, unless prohibited. Users of this work queue are not supposed to queue long running work. But in practice, there are scenarios where long running work items are queued on other unbound workqueues, occupying the CPU. As a result, the ISH resume handler may not get a chance to execute in a timely manner. In one scenario, one of the ish_resume_handler() executions was delayed nearly 1 second because another work item on an unbound workqueue occupied the same CPU. This delay causes ISH functionality failures. A similar issue was previously observed where the ISH HID driver timed out while getting the HID descriptor during S4 resume in the recovery kernel, likely caused by the same workqueue contention problem. Create dedicated unbound workqueues for all ISH operations to allow work items to execute on any available CPU, eliminating CPU-specific bottlenecks and improving resume reliability under varying system loads. Also ISH has three different components, a bus driver which implements ISH protocols, a PCI interface layer and HID interface. Use one dedicated work queue for all of them. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17Merge tag 'block-6.18-20251016' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux Pull block fixes from Jens Axboe: - NVMe pull request via Keith: - iostats accounting fixed on multipath retries (Amit) - secure concatenation response fixup (Martin) - tls partial record fixup (Wilfred) - Fix for a lockdep reported issue with the elevator lock and blk group frozen operations - Fix for a regression in this merge window, where updating 'nr_requests' would not do the right thing for queues with shared tags * tag 'block-6.18-20251016' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: nvme/tcp: handle tls partially sent records in write_space() block: Remove elevator_lock usage from blkg_conf frozen operations blk-mq: fix stale tag depth for shared sched tags in blk_mq_update_nr_requests() nvme-auth: update sc_c in host response nvme-multipath: Skip nr_active increments in RETRY disposition
2025-10-17Merge tag 'mmc-v6.18-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull mmc cleanup from Ulf Hansson: "Move rpmb_frame struct and constants to rpmb common header This helps us to avoid sharing an immutable branch between our git trees. I was planning to send it before rc1, but I didn't make it" * tag 'mmc-v6.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: rpmb: move rpmb_frame struct and constants to common header
2025-10-17Merge tag 'drm-fixes-2025-10-17' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "As per usual xe/amdgpu are the leaders, with some i915 and then a bunch of scattered fixes. There are a bunch of stability fixes for some older amdgpu cards. draw: - Avoid color truncation gpuvm: - Avoid kernel-doc warning sched: - Avoid double free i915: - Skip GuC communication warning if reset is in progress - Couple frontbuffer related fixes - Deactivate PSR only on LNL and when selective fetch enabled xe: - Increase global invalidation timeout to handle some workloads - Fix NPD while evicting BOs in an array of VM binds - Fix resizable BAR to account for possibly needing to move BARs other than the LMEMBAR - Fix error handling in xe_migrate_init() - Fix atomic fault handling with mixed mappings or if the page is already in VRAM - Enable media samplers power gating for platforms before Xe2 - Fix de-registering exec queue from GuC when unbinding - Ensure data migration to system if indicated by madvise with SVM - Fix kerneldoc for kunit change - Always account for cacheline alignment on migration - Drop bogus assertion on eviction amdgpu: - Backlight fix - SI fixes - CIK fix - Make CE support debug only - IP discovery fix - Ring reset fixes - GPUVM fault memory barrier fix - Drop unused structures in amdgpu_drm.h - JPEG debugfs fix - VRAM handling fixes for GPUs without VRAM - GC 12 MES fixes amdkfd: - MES fix ast: - Fix display output after reboot bridge: - lt9211: Fix version check panthor: - Fix MCU suspend qaic: - Init bootlog in correct order - Treat remaining == 0 as error in find_and_map_user_pages() - Lock access to DBC request queue rockchip: - vop2: Fix destination size in atomic check" * tag 'drm-fixes-2025-10-17' of https://gitlab.freedesktop.org/drm/kernel: (44 commits) drm/sched: Fix potential double free in drm_sched_job_add_resv_dependencies drm/xe/evict: drop bogus assert drm/xe/migrate: don't misalign current bytes drm/xe/kunit: Fix kerneldoc for parameterized tests drm/xe/svm: Ensure data will be migrated to system if indicated by madvise. drm/gpuvm: Fix kernel-doc warning for drm_gpuvm_map_req.map drm/i915/psr: Deactivate PSR only on LNL and when selective fetch enabled drm/ast: Blank with VGACR17 sync enable, always clear VGACRB6 sync off accel/qaic: Synchronize access to DBC request queue head & tail pointer accel/qaic: Treat remaining == 0 as error in find_and_map_user_pages() accel/qaic: Fix bootlog initialization ordering drm/rockchip: vop2: use correct destination rectangle height check drm/draw: fix color truncation in drm_draw_fill24 drm/xe/guc: Check GuC running state before deregistering exec queue drm/xe: Enable media sampler power gating drm/xe: Handle mixed mappings and existing VRAM on atomic faults drm/xe/migrate: Fix an error path drm/xe: Move rebar to be done earlier drm/xe: Don't allow evicting of BOs in same VM in array of VM binds drm/xe: Increase global invalidation timeout to 1000us ...
2025-10-17drm/xe/pf: Allow to restore auto-provisioning modeMichal Wajdeczko
After doing tweaks to the VFs provisioning we may want to restore back the auto-provisioning mode. Allow that unless VFs are still enabled. This can be also used to release all VFs resources. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20251015091211.592-5-michal.wajdeczko@intel.com
2025-10-17Merge tag 'i2c-for-6.18-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: - PM cleanup after all prerequisites are merged with rc1 - usbio: missing addition after all dependencies are in - slimpro: DT binding schema conversion * tag 'i2c-for-6.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: dt-bindings: i2c: Convert apm,xgene-slimpro-i2c to DT schema i2c: usbio: Add ACPI device-id for MTL-CVF devices i2c: Remove redundant pm_runtime_mark_last_busy() calls
2025-10-17drm/xe/pf: Disable auto-provisioning if changed using debugfsMichal Wajdeczko
When we attempt to tweak VFs configurations using debugfs, stop assuming that VFs need auto-(un)provisioning. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20251015091211.592-4-michal.wajdeczko@intel.com
2025-10-17drm/xe/pf: Automatically provision VFs only in auto-modeMichal Wajdeczko
We shouldn't attempt to auto-provision VFs once we allow other provisioning methods. Make the code aware of the new condition. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20251015091211.592-3-michal.wajdeczko@intel.com
2025-10-17drm/xe/pf: Promote VFs provisioning helpersMichal Wajdeczko
As we plan to add more VFs provisioning methods, start moving related code into single place. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20251015091211.592-2-michal.wajdeczko@intel.com
2025-10-17drm/xe/pf: Always expose VRAM provisioning data on discrete GPUsLukasz Laguna
Currently, VRAM provisioning data is only exposed if the device supports LMTT. While it should not be possible to modify VRAM provisioning on platforms without LMTT, it is still useful to be able to read the VRAM provisioning data on all discrete GPU platforms. Expose the VRAM debugfs attributes whenever running on dGFX, adjusting file permissions to read only when LMTT is not available. Signed-off-by: Lukasz Laguna <lukasz.laguna@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20251016122233.3789-1-lukasz.laguna@intel.com
2025-10-17hwmon: (corsair-psu) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (corsair-psu) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (chipcap2) Drop unnecessary include filesGuenter Roeck
The driver does not perform any locking, does not execute or use any sleep related functionality, and does not allocate memory. Drop the unnecessary include files. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (asus_rog_ryujin) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (i5500_temp) Drop unnecessary include filesGuenter Roeck
The driver does not perform any locking, does not execute or use any sleep related functionality, and does not allocate memory. Drop the unnecessary include files. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (gpd-fan) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (aquacomputer_d5next) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (ltc4282) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Nuno Sá <nuno.sa@analog.com>
2025-10-17hwmon: (lochnagar-hwmon) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (sfctemp) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (adt7x10) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Nuno Sá <nuno.sa@analog.com>
2025-10-17hwmon: (peci) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (ltc2947-core) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Nuno Sá <nuno.sa@analog.com>
2025-10-17hwmon: (adt7411) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Nuno Sá <nuno.sa@analog.com>
2025-10-17PCI/VGA: Select SCREEN_INFO on X86Mario Limonciello (AMD)
commit 337bf13aa9dda ("PCI/VGA: Replace vga_is_firmware_default() with a screen info check") introduced an implicit dependency upon SCREEN_INFO by removing the open coded implementation. If a user didn't have CONFIG_SCREEN_INFO set, vga_is_firmware_default() would now return false. SCREEN_INFO is only used on X86 so add a conditional select for SCREEN_INFO to ensure that the VGA arbiter works as intended. Fixes: 337bf13aa9dda ("PCI/VGA: Replace vga_is_firmware_default() with a screen info check") Reported-by: Eric Biggers <ebiggers@kernel.org> Closes: https://lore.kernel.org/linux-pci/20251012182302.GA3412@sol/ Suggested-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Tested-by: Eric Biggers <ebiggers@kernel.org> Link: https://patch.msgid.link/20251013220829.1536292-1-superm1@kernel.org
2025-10-17PCI: vmd: Override irq_startup()/irq_shutdown() in vmd_init_dev_msi_info()Inochi Amaoto
Since commit 54f45a30c0d0 ("PCI/MSI: Add startup/shutdown for per device domains") set callback irq_startup() and irq_shutdown() of the struct pci_msi[x]_template, __irq_startup() will always invokes irq_startup() callback instead of irq_enable() callback overridden in vmd_init_dev_msi_info(). This will not start the IRQ correctly. Also override irq_startup()/irq_shutdown() in vmd_init_dev_msi_info(), so the irq_startup() can invoke the real logic. Fixes: 54f45a30c0d0 ("PCI/MSI: Add startup/shutdown for per device domains") Reported-by: Kenneth Crudup <kenny@panix.com> Closes: https://lore.kernel.org/r/8a923590-5b3a-406f-a324-7bd1cf894d8f@panix.com/ Reported-by: Genes Lists <lists@sapience.com> Closes: https://lore.kernel.org/r/4b392af8847cc19720ffcd53865f60ab3edc56b3.camel@sapience.com Reported-by: Todd Brandt <todd.e.brandt@intel.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220658 Reported-by: Oliver Hartkopp <socketcan@hartkopp.net> Closes: https://lore.kernel.org/r/8d6887a5-60bc-423c-8f7a-87b4ab739f6a@hartkopp.net Reported-by: Hervé <herve@dxcv.net> Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Kenneth R. Crudup <kenny@panix.com> Tested-by: Genes Lists <lists@sapience.com> Tested-by: Oliver Hartkopp <socketcan@hartkopp.net> Tested-by: Todd Brandt <todd.e.brandt@linux.intel.com> Tested-by: Hervé <herve@dxcv.net> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251014014607.612586-1-inochiama@gmail.com
2025-10-17Merge tag 'tee-qcomtee-fixes-for-v6.18' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee into arm/fixes TEE QTEE fixes for v6.18 - Adds ARCH_QCOM dependency for the QTEE driver - Fixing return values for copy_from_user() failures - Guarding against potential off by one read * tag 'tee-qcomtee-fixes-for-v6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee: tee: QCOMTEE should depend on ARCH_QCOM tee: qcom: return -EFAULT instead of -EINVAL if copy_from_user() fails tee: qcom: prevent potential off by one read
2025-10-17Merge tag 'zynqmp-soc-for-6.18' of https://github.com/Xilinx/linux-xlnx into ↵Arnd Bergmann
soc/drivers arm64: Xilinx SOC changes for 6.18 firmware: - Add debugfs interface - Wire versal-net compatible string - Change SOC family detection * tag 'zynqmp-soc-for-6.18' of https://github.com/Xilinx/linux-xlnx: drivers: firmware: xilinx: Switch to new family code in zynqmp_pm_get_family_info() drivers: firmware: xilinx: Add unique family code for all platforms firmware: xilinx: Add Versal NET platform compatible string firmware: xilinx: Add debugfs support for PM_GET_NODE_STATUS
2025-10-17irqchip/qcom-irq-combiner: Rename driver structureJohan Hovold
The "_probe" suffix of the driver structure name prevents modpost from warning about section mismatches so replace it to catch any future issues like the recently fixed probe function being incorrectly marked as __init. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2025-10-17can: m_can: m_can_get_berr_counter(): don't wake up controller if interface ↵Marc Kleine-Budde
is down If the interface is down, the CAN controller might be powered down, the clock disabled, and/or it's external reset asserted. Don't wake up the controller to read the CAN bus error counters, if the interface is down. Reviewed-by: Markus Schneider-Pargmann <msp@baylibre.com> Link: https://patch.msgid.link/20251008-m_can-cleanups-v1-7-1784a18eaa84@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-10-17can: m_can: m_can_tx_submit(): remove unneeded sanity checksMarc Kleine-Budde
m_can_tx_submit() is only called for peripheral devices. So remove the sanity check. Link: https://patch.msgid.link/20251008-m_can-cleanups-v1-6-1784a18eaa84@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-10-17can: m_can: m_can_class_register(): remove error message in case ↵Marc Kleine-Budde
devm_kzalloc() fails If devm_kzalloc() fails, it already outputs an error message. Remove the error message from m_can_class_register() accordingly. Link: https://patch.msgid.link/20251008-m_can-cleanups-v1-5-1784a18eaa84@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-10-17can: m_can: m_can_interrupt_enable(): use m_can_write() instead of open ↵Marc Kleine-Budde
coding it As everywhere else in the driver, use m_can_write() instead of open coding it. Link: https://patch.msgid.link/20251008-m_can-cleanups-v1-4-1784a18eaa84@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-10-17net: m_can: convert dev_{dbg,info,err} -> netdev_{dbg,info,err}Marc Kleine-Budde
To ease debugging use the netdev_{dbg,info,err}() functions instead of dev_{dbg,info,err}. Link: https://patch.msgid.link/20251008-m_can-cleanups-v1-3-1784a18eaa84@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-10-17can: m_can: hrtimer_callback(): rename to m_can_polling_timer()Marc Kleine-Budde
The original use of struct m_can_classdev::hrtimer was to support polling for devices without IRQ, with the timer function called hrtimer_callback(). Commit 07f25091ca02 ("can: m_can: Implement receive coalescing") uses the hrtimer for software-supported IRQ coalescence, with the timer function called m_can_coalescing_timer(). To improve the readability of the driver, rename hrtimer_callback() to m_can_polling_timer(), which better describes the functionality. Link: https://patch.msgid.link/20251008-m_can-cleanups-v1-2-1784a18eaa84@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-10-17can: m_can: m_can_init_ram(): make staticMarc Kleine-Budde
Since commit eaacfeaca7ad ("can: m_can: Call the RAM init directly from m_can_chip_config") m_can_init_ram() is not used outside of m_can.c. Mark as static and remove the EXPORT_SYMBOL_GPL(). Link: https://patch.msgid.link/20251008-m_can-cleanups-v1-1-1784a18eaa84@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-10-17hwmon: (aht10) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (lm95241) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (ina238) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (ftsteutates) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (powr1220) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (mr75203) Drop unnecessary include fileGuenter Roeck
The driver does not perform any locking and thus does not need to include mutex.h. Drop the unnecessary include file. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (k10temp) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (ina3221) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (sht4x) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (ina2xx) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>