summaryrefslogtreecommitdiff
path: root/drivers/i2c/busses
AgeCommit message (Collapse)Author
8 daysMerge tag 'i2c-7.4-part2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux Pull more i2c updates from Andi Shyti: "This introduces dynamic transfer timeouts in the I2C core, already used by qcom-geni. Alongside some driver improvements and fixes, it also brings in the Rust I2C pull request. Core: - core, qcom-geni: add and use a dynamic timeout helper - acpi: fix adapter reference leak when creating I2C clients Drivers: - imx: support reversed address direction and no-start transfers - designware: queue block data reads once length is known - mt7621: skip the second data register for chunks up to 4 bytes - sh_mobile: ensure IRQs are freed before unmapping registers Rust: - Remove unsound device-to-client reference conversion" * tag 'i2c-7.4-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux: i2c: sh_mobile: request IRQs after mapping registers i2c: imx: add I2C_M_REV_DIR_ADDR and I2C_M_NOSTART i2c: mt7621: fix copying uninitialized kernel stack with reduced page_len i2c: designware: queue only one read command for block reads i2c: acpi: Fix adapter reference leak in i2c_acpi_new_device_by_fwnode() i2c: qcom-geni: Add dynamic transfer timeout based on transfer length and frequency i2c: core: Add i2c_update_timeout() helper for dynamic transfer timeouts rust: i2c: remove TryFrom<&Device> implementation for &I2cClient
10 daysi2c: sh_mobile: request IRQs after mapping registersMyeonghun Pak
The managed IRQ handlers are acquired before the managed register mapping, so devres unmaps the registers before freeing the IRQs. A transfer wakes its waiter before the ISR's final register read, and unregistering the adapter does not synchronize these IRQs. An in-flight handler can therefore still access the mapping when it is released during driver detach. With forced-threaded IRQs, the handler can be preempted after waking the transfer waiter and before its final ICSR read. Map the registers before requesting the IRQs so that managed cleanup frees and synchronizes all handlers before unmapping their registers. Keep IRQs available while unregistering the adapter because client removal may perform transfers. This issue was identified as part of our ongoing research while reviewing kernel code. Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20261017233416.47b09ffff48f.i2c-sh-mobile@gmail.com
11 daysMerge tag 'modules-7.4-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/modules/linux Pull module updates from Petr Pavlu: - Ignore local labels and mapping symbols during module load These symbols were already ignored during kallsyms address-to-symbol lookups. Filter them out earlier during module loading to reduce lookup overhead and prevent them from appearing in /proc/kallsyms. - Fix potentially incorrect access of SetOnce<T> when setting Rust module parameters. - Fix a potential read of an uninitialized count when printing taint information for unloaded modules. - Allocate the kmod argument array using kmalloc_array() in preparation for conversion to type-aware allocators. - Clean up includes in linux/kmod.h Add explicit includes of linux/umh.h to files that use usermode helpers. Then clean up the #include list in linux/kmod.h, notably removing the compatibility linux/umh.h include. - Remove the error-injection.h include from linux/module.h Add explicit includes of linux/error-injection.h to files that use the ALLOW_ERROR_INJECTION() macro and currently rely on it being provided indirectly via linux/module.h. Then remove the unnecessary linux/error-injection.h include from linux/module.h. - Replace __MODULE_STRING() with __stringify() in various drivers in preparation for removing the former macro. * tag 'modules-7.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/modules/linux: drivers: Replace __MODULE_STRING() with __stringify() module: Fix uninitialized count read of unloaded taint tracking record rust: module_param: Fix potentially incorrect access of `SetOnce<T>` module: Remove the error-injection.h include from linux/module.h drm/xe: Include error-injection.h for ALLOW_ERROR_INJECTION() drm/i915: Include error-injection.h for ALLOW_ERROR_INJECTION() syscalls: Include error-injection.h for ALLOW_ERROR_INJECTION() net: Include error-injection.h for ALLOW_ERROR_INJECTION() block: Include error-injection.h for ALLOW_ERROR_INJECTION() module: Bring includes in linux/kmod.h up to date time/jiffies: Include linux/sysctl.h for proc_int_u2k_conv_uop(), ... umh, treewide: Explicitly include linux/umh.h where needed modules/kmod: Allocate argv with kmalloc_array() module/kallsyms: Ignore local labels and mapping symbols during module load module/kallsyms: Refactor current symbol filtering into is_core_symbol() module/kallsyms: Rename is_mapping_symbol() to is_ignored_kernel_symbol()
11 daysi2c: imx: add I2C_M_REV_DIR_ADDR and I2C_M_NOSTARTVincent Jardin
The Realtek RTL8366SE SMI read frame per: S Addr Rd [A] reg[7:0] [A] reg[15:8] [A] [data[7:0]] A [data[15:8]] NA P Linux support it using I2C_M_REV_DIR_ADDR on a write message that inverts the transmitted R/W bit, and I2C_M_NOSTART on the following read message that continues the frame without re-addressing. This NXP i2c-imx is missing such support, so on an LX2160A the Realtek switch could not be used. Signed-off-by: Vincent Jardin <vjardin@free.fr> Acked-by: Carlos Song <carlos.song@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20261023-for-upstream-i2c-imx-lx2160-reverse-v3-1-a07b249df381@free.fr
11 daysi2c: mt7621: fix copying uninitialized kernel stack with reduced page_lenChristian Marangi
When a page_len is less than 5 bytes in mtk_i2c_xfer, uninitialized kernel stack data is copied and written to REG_SM0D1_REG. Equally on the read part, an unnecessary read is done. Guard these extra copy/write and read for the page_len to fix leaking uninitialized stack memory. Fixes: d04913ec5f89 ("i2c: mt7621: Add MediaTek MT7621/7628/7688 I2C driver") Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Cc: <stable@vger.kernel.org> # v5.3+ Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20261022193853.670625-1-ansuelsmth@gmail.com
12 daysi2c: designware: queue only one read command for block readsNavon John Lukose
i2c_dw_xfer_msg() pre-queues up to rx_fifo_depth read commands based on the initial msg.len. For I2C_M_RECV_LEN transfers the real length is unknown until the first byte arrives and i2c_dw_recv_len() runs. When a large initial length is passed, the surplus pre-queued reads leave rx_outstanding non-zero after i2c_dw_recv_len() adjusts msg.len, so the completion condition is never met and the transfer times out. In a loop, this repeatedly times out the controller and disrupts unrelated driver-bound devices on the same adapter. Queue only one read command while I2C_M_RECV_LEN is pending. i2c_dw_recv_len() re-enables TX_EMPTY, and the rest are queued once the device-reported length is known. Fixes: c3ae106050b9 ("i2c: designware: Implement support for SMBus block read and write") Signed-off-by: Navon John Lukose <navonjohnlukose@gmail.com> Cc: <stable@vger.kernel.org> # v4.10+ Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
12 daysi2c: qcom-geni: Add dynamic transfer timeout based on transfer length and ↵Aniket Randive
frequency The driver uses a static XFER_TIMEOUT of HZ (1 second) for all transfers regardless of message length or bus frequency, causing unnecessary delays on error paths. Use i2c_update_timeout() API to calculate transfer timeouts dynamically based on message length and bus frequency. update the timeout per message for FIFO, SE-DMA and GPI single descriptor transfers. For GPI multi descriptor transfers, calculate the timeout from the combined length of all messages, as completion is reported only after the entire batch has finished. A 10x safety margin over the theoretical wire time is applied, with a 300ms floor to account for I2C clock stretching and other situations where a slave may keep SCL asserted for an extended period, including faulty devices holding the bus. Signed-off-by: Aniket Randive <aniket.randive@oss.qualcomm.com> Reviewed-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260911-master-v9-2-77ac458344e2@oss.qualcomm.com
12 daysMerge tag 'i2c-7.4-part1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux Pull i2c updates from Andi Shyti: "The main changes are the new Novatek NT72676 driver, the qcom-cci clock and timing updates and a collection of smaller driver, core and DT binding improvements. Core and helpers: - acpi: run ASUS and Dell touchpads at 100 kHz to avoid lag - core: return bool from check_functionality() and update users - smbus: limit block reads to the caller's buffer size - acpi: mark I2C transfer buffers as DMA-safe Drivers: - qcom-geni: several firmware node and runtime PM improvements - qcom-cci: several patches rework clock selection and timings - qcom-cci: enable SCL clock stretching - imx-lpi2c: fix DMA mapping device selection and cleanup - designware: tune RX FIFO thresholds to reduce interrupts - i801: respect SPD write protection when probing DDR5 modules - bcm2835: fully initialize clock configuration data Generic cleanups: - mux: simplify channel lookup and firmware node handling - core, busses: tidy up ACPI device ID tables - docs: clarify adapter lookup and fix a client driver example - xlnx: update maintainer for Xilinx IIC bindings - ljca: remove redundant adapter deletion New support and DT bindings: - add DW compatibles for Synaptics SL2610 and UltraRISC DP1000 - allow six DMA channels for R-Car Gen5 - add Allwinner A733 compatible to mv64xxx bindings - add support for Novatek NT72676 (new driver)" * tag 'i2c-7.4-part1' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux: (37 commits) i2c: imx-lpi2c: remove dmaengine_desc_free() i2c: busses: use named initializers for acpi_device_id i2c: i2c-core-acpi: use named initializers for acpi_device_id i2c: i801: Gate SPD instantiation on SPD Write Disable bit i2c: acpi: Use I2C_M_DMA_SAFE in acpi_gsb_i2c_[read|write]_bytes() dt-bindings: i2c: dw: Add Synaptics sl2610 i2c i2c: designware: size the RX FIFO threshold to the queued transfer i2c: imx-lpi2c: use dmaengine_get_dma_device() for DMA mapping docs: i2c: writing-clients: Add missing end of command i2c: qcom-cci: skip core clock rates the clock cannot provide i2c: core: document preference for i2c_get_adapter_by_fwnode() i2c: qcom-cci: always enable SCL clock stretching MAINTAINERS: Add entry for Novatek NT72676 I2C controller driver i2c: nt72676: Add Novatek NT72676 I2C controller driver dt-bindings: i2c: Add Novatek NT72676 I2C controller i2c: acpi: Force ASUE140D touchpads to 100 kHz i2c: qcom-cci: Enforce the required CCI clock rate i2c: qcom-cci: Share the timing table across CCI revisions i2c: qcom-cci: Add 19.2 MHz timings for the v2 CCI i2c: qcom-cci: Support per-mode CCI clock rates ...
2026-10-15i2c: xiic: restore non-managed runtime PM to fix clk WARN floodAbdurrahman Hussain
The devres conversion replaced manual pm_runtime_enable()/disable() with devm_pm_runtime_set_active_enabled() and dropped the remove-time runtime PM teardown. The managed release tears runtime PM down in the wrong order: it calls pm_runtime_dont_use_autosuspend() before pm_runtime_disable(), i.e. while runtime PM is still enabled, and devres is LIFO so the devm_clk_get_enabled() release runs afterwards. At remove(), pm_runtime_put_sync() leaves the device active with the autosuspend timer armed. Clearing use_autosuspend then makes rpm_idle() suspend immediately, and xiic_i2c_runtime_suspend() clk_disable()s the clock. The later devm_clk_get_enabled() release clk_disable_unprepare()s the already-disabled clock, so clk_core_disable() WARNs ("clkN already disabled") on every teardown. Drop the managed helper and restore the non-managed runtime PM setup and teardown, so runtime PM is enabled once in probe and disabled once in remove and the clock enable count stays balanced. Order the remove teardown so runtime PM is disabled before the usage count is dropped: pm_runtime_disable() followed by pm_runtime_put_noidle() instead of pm_runtime_put_sync(). Dropping the count first with autosuspend still enabled arms the autosuspend timer, and a preemption before pm_runtime_disable() lets it expire, suspend the device and clk_disable() the clock, which the devm release then disables again - the same WARN. Restore the non-managed IRQ request as well. The probe error paths now unwind runtime PM by hand via goto, and a devm-registered handler is only freed later during devres unwind, so it would stay live across the manual teardown (and across any future failing step added after it). Request the IRQ with request_threaded_irq() and free it explicitly in the probe error path and in remove. The probe error path also clears use_autosuspend, to match the teardown in remove(). Fixes: 50c63491ff26 ("i2c: xiic: switch to devres managed APIs") Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai> Cc: <stable@vger.kernel.org> # v7.1+ Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20261014-i2c-xiic-restore-runtime-pm-teardown-v8-1-40668c270069@nexthop.ai
2026-10-14drivers: Replace __MODULE_STRING() with __stringify()Petr Pavlu
__MODULE_STRING() has been an alias for __stringify() since "[PATCH] MODULE_PARM support for older modules" [1] in 2002-12. That change also moved it to the graveyard section at the end of linux/module.h Replace the remaining uses of __MODULE_STRING() with __stringify() in preparation for its removal. Link: https://git.kernel.org/tglx/history/c/136839a1b4 [1] Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Andi Shyti <andi.shyti@kernel.org> Acked-by: Ian Abbott <abbotti@mev.co.uk> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Mika Westerberg <westeri@kernel.org> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
2026-10-13i2c: imx-lpi2c: remove dmaengine_desc_free()Frank Li
dmaengine_desc_free() is designed for DMA_CTRL_REUSE. If DMA_CTRL_REUSE is not set, dmaengine_desc_free() will return -EPERM. if (!dmaengine_desc_test_reuse(desc)) return -EPERM; So calling dmaengine_desc_free() does nothing. dmaengine_terminate_(a)sync() will free all already allocated descriptors. Signed-off-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Carlos Song <carlos.song@nxp.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260929190605.3516147-1-Frank.Li@oss.nxp.com
2026-10-13i2c: qcom-cci: Fix HALT_ACK reset request being droppedLoic Poulain
A HALT_ACK interrupt indicates that the corresponding I2C master has entered the halted state and must be reset before further operation. The M0 and M1 HALT_ACK status bits may be asserted simultaneously in a single interrupt. However, the interrupt handler currently overwrites the reset mask when processing each HALT_ACK condition, causing the first reset request to be lost if both events are reported together. Accumulate reset requests instead of overwriting them so that both masters are properly reset when M0 and M1 HALT_ACK events occur in the same interrupt. Fixes: e517526195de4 ("i2c: Add Qualcomm CCI I2C driver") Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Cc: <stable@vger.kernel.org> # v5.8+ Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20261012-cci-fixes-v1-1-8cd4eb1fc5f9@oss.qualcomm.com
2026-10-13i2c: busses: use named initializers for acpi_device_idPawel Zalewski
Use a designated initializer for the acpi_device_id fields which makes the code more readable and consistent with how lists are initialized in the rest of the kernel code base. Also drop explicitly setting fields to 0 where it is redundant. Unify the list terminator to have a single space between the brackets and no trailing comma. Unify list item alignment to have a single space padding between the brackets. Signed-off-by: Pawel Zalewski <pzalewski@thegoodpenguin.co.uk> Acked-by: Mika Westerberg <westeri@kernel.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260918-acpi-i2c-v1-2-caf4bea4886c@thegoodpenguin.co.uk
2026-10-13i2c: i801: Gate SPD instantiation on SPD Write Disable bitYo-Jung
When DDR5 memory modules are present, probing the spd5118 hub requires page-selection write transactions. If the BIOS has set the SPD Write Disable (SPD_WD) bit in SMBHSTCFG, the transaction fails and wedges the controller into an unrecoverable "SMBus is busy" state. Pass the PCH SPD Write Disable status into the SMBus core via i2c_register_spd_write_disable(). This safely skips spd5118 instantiation under write-protection while leaving legacy DDR4 (ee1004) functional. Retain the original #ifdef CONFIG_I2C_I801_MUX preprocessor block around mux_pdev to prevent compile-time regressions when the multiplexer driver is disabled. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=213345 Co-developed-by: Saranya Gopal <saranya.gopal@intel.com> Signed-off-by: Saranya Gopal <saranya.gopal@intel.com> Signed-off-by: Yo-Jung <yo-jung@canonical.com> Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20261013080603.808196-1-saranya.gopal@intel.com
2026-10-13i2c: qcom-geni: Restore the source-clock selection policyAbel Vesa
Currently, the source clock lookup prefers 32 MHz whenever that rate is available, regardless of the rate configured by the platform. Before the switch to looking up the clock index, the driver used the 32 MHz timing table only if the current source clock rate was 32 MHz, and the 19.2 MHz table otherwise. On X1E80100 CRD, this results in switching the source clock from 19.2 MHz to 32 MHz, which causes intermittent failures when probing the I2C HID keyboard. These range from corrupted HID descriptors to failed resets and transfer timeouts, which also affect the touchpad on the same bus. Restore the original selection policy: use 32 MHz if already selected, otherwise request 19.2 MHz. Look up the index for the selected rate and keep the check that rejects higher-frequency multiples. This retains the dynamic clock index lookup without preferring 32 MHz on platforms that previously used 19.2 MHz. Report the requested rate if the lookup fails. Fixes: cb97bf3d4f91 ("i2c: qcom-geni: Fix hardcoded clock index in SE_GENI_CLK_SEL") Assisted-by: LLM Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Tested-by: Hasty Heat <hastyheat@gmail.com> Tested-by: Mitchell Augustin <mitchell.augustin@canonical.com> Reviewed-by: Mitchell Augustin <mitchell.augustin@canonical.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260928-b4-i2c-qcom-geni-preserve-source-clock-v1-1-9aded7552a76@oss.qualcomm.com
2026-10-13i2c: viai2c-wmt: Fix clock leak in wmt_i2c_probe()Wentao Liang
In wmt_i2c_probe(), i2c->clk is acquired using of_clk_get(). If any subsequent operation fails or when the module is unloaded, the clock reference count is never decremented via clk_put(), leading to a resource leak. Switch to devm_clk_get() so that the clock is automatically managed and released. Fixes: 560746eb79d3 ("i2c: vt8500: Add support for I2C bus on Wondermedia SoCs") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang <vulab@iscas.ac.cn> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260916070631.1965713-1-vulab@iscas.ac.cn
2026-10-10i2c: designware: size the RX FIFO threshold to the queued transferNavon John Lukose
i2c_dw_xfer_msg() leaves DW_IC_RX_TL at the 0 that i2c_dw_configure_mode() writes, so the controller raises RX_FULL once per received byte. Program RX_TL from the reads already queued, capped at half the FIFO until the last message is queued, so there is room for the rest. On an Arrow Lake-H LPSS core with rx_fifo_depth 32, a 22-byte HID input report costs 2.00 interrupts instead of 21.43, and a 452-byte descriptor 0.14 interrupts per byte instead of 1.64. Polling the touchpad with HIDIOCGINPUT at 142 Hz draws 1.58 W less platform power (psys, 32 paired runs). Assisted-by: LLM Signed-off-by: Navon John Lukose <navonjohnlukose@gmail.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20261007191911.502428-1-navonjohnlukose@gmail.com
2026-10-10i2c: imx-lpi2c: use dmaengine_get_dma_device() for DMA mappingPeng Fan
Replace all chan->device->dev references with dmaengine_get_dma_device(chan) so that DMA mapping goes through the correct device when the DMA controller has per-channel IOMMU domains (chan_dma_dev=true). Without this, DMA map/unmap bypasses the IOMMU context configured by the eDMA driver. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260916-i2c-dma-v1-1-6dd4f1916910@nxp.com
2026-10-10i2c: qcom-cci: skip core clock rates the clock cannot provideOleg Keri
cci_get_required_rate() picks the lowest rate that has timings for every active master, but never checks that the CCI clock can run at it. On glymur, sm8750 and kaanapali the CCI clock table has no 19.2 MHz entry, so the request rounds up to 30 MHz or 37.5 MHz, the timing lookup for the running rate fails and the controller does not probe: i2c-qcom-cci ac16000.cci: CCI clock is not at expected 19200000 Hz i2c-qcom-cci ac16000.cci: no timing for mode 1 at CCI clock 30000000 Hz i2c-qcom-cci ac16000.cci: probe with driver i2c-qcom-cci failed with error -95 Only consider rates clk_round_rate() can deliver exactly. Glymur then runs its CCI at 37.5 MHz, which has timings for every mode. Fixes: fa1eb3af12fa ("i2c: qcom-cci: Enforce the required CCI clock rate") Signed-off-by: Oleg Keri <okerixx@gmail.com> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20261008230725.3228-1-okerixx@gmail.com
2026-10-09i2c: qcom-cci: always enable SCL clock stretchingHitesh Patel
The CCI timing tables leave SCL clock stretching disabled. A slave that holds SCL low is then not waited for: the master keeps its own clock timing and the transfer fails with a NACK or returns corrupt data. This is hit with a camera reached through a GMSL serializer/deserializer I2C tunnel (MAX9296A/MAX96717 on the RB3 Gen2 vision mezzanine). The deserializer acknowledges the address locally, but forwards the transaction over the coax link and stretches SCL until the remote side has completed it, which takes well over one clock period at 100 kHz. Without stretching the register reads of the sensor behind the link intermittently return garbage and writes are dropped, which shows up as random sensor init failures. Clock stretching is part of the I2C specification for every speed mode and a device that does not stretch is unaffected by enabling it, so set the bit unconditionally in cci_init() and drop the per-table scl_stretch_en field, which is zero in every table. Signed-off-by: Hitesh Patel <hitesh@ebytelogic.com> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Tested-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com> # S5KJN5 on Kaanapali Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20261007050147.274096-1-hitesh@ebytelogic.com
2026-10-07i2c: nt72676: Add Novatek NT72676 I2C controller driverBen Huang
This driver performs the fundamental read/write functions as an I2C controller and supports Standard-mode and Fast-mode. Default operation is Standard-mode. Signed-off-by: Ben Huang <Ben_Huang@novatek.com.tw> Signed-off-by: Nina Kuo <Nina_Kuo@novatek.com.tw> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260910030123.215609-3-nina_kuo@novatek.com.tw
2026-10-05i2c: qcom-geni: release runtime PM reference when set_rate failsRahul Pon
geni_i2c_xfer() takes a runtime-PM reference with pm_runtime_get_sync() and then returns directly if the set_rate() callback fails, leaking the reference and keeping the controller resumed for good. Route that error through the existing cleanup path, which drops the reference and resets the transfer state. Found by code review; compile-tested with arm64 defconfig plus ACPI and W=1. Fixes: 10e74f4c5046 ("i2c: qcom-geni: Enable I2C on SA8255p Qualcomm platforms") Assisted-by: LLM Signed-off-by: Rahul Pon <theflyingrahul@gmail.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260930111641.1134-1-theflyingrahul@gmail.com
2026-10-04i2c: qcom-cci: Enforce the required CCI clock rateLoic Poulain
The CCI hw_params timing values are only valid at the specific clock rate they were calibrated for. A previous change made the driver select the timing set matching the currently running clock rate, but the rate itself was still left to the DT (assigned-clock-rates) or the bootloader, which is fragile: if no rate is enforced the timings may not match and violate the I2C specification. Actively drive the CCI clock to the rate required by the configured modes. The single CCI clock is shared by all masters, which may run in different modes, so cci_get_required_rate() picks the lowest rate that has a valid timing set for every active master's mode. This avoids clocking the bus faster than necessary while still satisfying every master (e.g. a Fast+ master forces 37.5 MHz). Apply the rate through the OPP framework so that boards describing an opp table also get the required power-domain/regulator votes for that rate. Boards without an OPP table simply fall back to plain clk_set_rate() behavior, so existing DTs keep working. Drop the now-redundant hw_params[].thigh check in cci_get_hw_params(), cci_get_required_rate() already rejects rates lacking a valid timing set for an active master's mode. Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260929-cci-clk-fix-v6-5-62a268cccb0f@oss.qualcomm.com
2026-10-04i2c: qcom-cci: Share the timing table across CCI revisionsLoic Poulain
The hw_params timing values only depend on the CCI clock rate and the I2C mode, not on the hardware revision: every per-variant table used identical values for a given [rate][mode]. Only the set of supported modes differs between revisions. Move the timings into a single shared cci_hw_params[rate][mode] table and describe each variant's highest supported mode in cci_data with max_mode instead of duplicating the timing values. This removes the per-variant timing tables without any functional change. Suggested-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260929-cci-clk-fix-v6-4-62a268cccb0f@oss.qualcomm.com
2026-10-04i2c: qcom-cci: Add 19.2 MHz timings for the v2 CCILoic Poulain
The v2 CCI (msm8996/sdm630/msm8953/...) is normally clocked at 37.5 MHz, but its CCI clock can also be configured and run at 19.2 MHz. Add the Standard and Fast timing sets calibrated for 19.2 MHz so that a v2 controller left at that rate still has valid timings for those modes (Fast+ requires 37.5 MHz). The values mirror the v1/v1.5 19.2 MHz Standard/Fast timings, which share the same CCI clock rate. Note the "v1"/"v1.5"/"v2" labels are arbitrary driver-internal names for the cci_data configs, not actual CCI hardware version numbers (the real hw versions are e.g. v1.0.7 on msm8974, v1.4.0 on msm8996, v1.6.3 on sdm630/660, ...). They only distinguish the timing/mode configurations used by the driver, and will be subsequently removed. Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260929-cci-clk-fix-v6-3-62a268cccb0f@oss.qualcomm.com
2026-10-04i2c: qcom-cci: Support per-mode CCI clock ratesLoic Poulain
The CCI hw_params timing values (thigh, tlow, etc.) are expressed in clock ticks and are only valid at the specific CCI clock rate they were calibrated for. Different I2C modes may be calibrated for different rates, and the single CCI clock is shared by all masters. Turn the timing table into a two-dimensional [rate][mode] matrix so a given rate can carry timing sets for each mode, and select the entry matching the currently running clock rate at init time. The existing per-variant values are moved under their calibrated rate (19.2 MHz for v1/v1.5, 37.5 MHz for v2), no timing values are changed. At this stage the driver only validates the running rate against the table, the timings are only valid at the exact rate they were calibrated for, so if the current rate has no matching entry for a master's mode, fail initialization rather than program incorrect timings. A following patch actively enforces the required rate so this becomes a safety net. Suggested-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260929-cci-clk-fix-v6-2-62a268cccb0f@oss.qualcomm.com
2026-10-04i2c: qcom-cci: Switch msm8953 to the CCI v2 timing/rate configLoic Poulain
The msm8953 CCI timing table is internally inconsistent. Its Standard and Fast timings match v1/v1.5, which are calibrated for a 19.2 MHz CCI clock, but its Fast+ timings are essentially the 'v2' values, which are calibrated for 37.5 MHz. Since all masters share a single CCI clock, no single rate can satisfy all three modes with the current table, and the DT assigns 19.2 MHz, so Fast+ timings are wrong. The msm8953 CCI is the same hardware version as msm8996/sdm630, which already use the cci_v2_data config (37.5 MHz). 37.5 MHz is supported by the msm8953 CCI RCG, so reuse cci_v2_data for msm8953 as well and drop the redundant, inconsistent standalone table. This makes all three I2C modes self-consistent under a single clock rate. Note this requires the CCI clock to run at 37.5 MHz, the driver selects and enforces the proper rate in following patches. Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260929-cci-clk-fix-v6-1-62a268cccb0f@oss.qualcomm.com
2026-10-01i2c: at91: release DMA channels when probe defersHongjian Dai
at91_twi_probe_master() can return -EPROBE_DEFER from at91_init_twi_recovery_info() after at91_twi_configure_dma() has already claimed the tx/rx DMA channels. at91_twi_probe() then returns without releasing them, and since dma_request_chan() is not devres-managed the channels leak on every deferred probe attempt. Release the channels before deferring the probe. Fixes: f7eeb1af8537 ("i2c: at91: release DMA channels on remove and probe error") Assisted-by: LLM Signed-off-by: Hongjian Dai <daihongjian@kylinsec.com.cn> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/7D85C6CB6BF0A82E+20260929164340.41628-1-daihongjian@kylinsec.com.cn
2026-09-30i2c: qcom-geni: Use device_set_node() helperHans de Goede
Use the device_set_node() helper instead of manually setting adap.dev.of_node. This: 1. Ensures that if the parent has an of_node, adap.dev.fwnode also points to the parent's of_node rather than remaining NULL. 2. Removes the need to handle a parent with an ACPI fwnode specially, since the generic helpers take care of this too. Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260919141434.22999-1-johannes.goede@oss.qualcomm.com
2026-09-28i2c: xiic: don't clobber msg->len to signal block-read completionAbdurrahman Hussain
At the end of a SMBus block read the BNB handler force-set tx_msg->len = 1 to push xiic_tx_space() to zero so the STATE_DONE branch would fire. Two problems: 1. tx_msg and rx_msg alias the same i2c_msg struct during a receive (see xiic_start_recv), so overwriting tx_msg->len also changes rx_msg->len. The i2c core's i2c_smbus_check_pec() then reads the PEC from the wrong offset -- buf[0] instead of buf[rxmsg_len + 1] -- and either mis-validates or returns -EBADMSG. 2. xiic_start_recv sets tx_pos = msg->len (typically 2 when PEC is enabled). xiic_tx_space() is unsigned msg->len - tx_pos, so setting msg->len = 1 with tx_pos = 2 underflows to 0xFFFFFFFF and xiic_tx_space() never compares equal to 0 -- the STATE_DONE check falls through to STATE_ERROR, giving -EIO. Instead, advance tx_pos up to msg->len. That drives tx_space to 0 without touching msg->len, preserving the buffer length that xiic_smbus_block_read_setup() already grew to cover the length byte, the payload and the optional PEC byte. Fixes: e4c1ff772e1a ("i2c: xiic: Add smbus_block_read functionality") Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai> Cc: <stable@vger.kernel.org> # v6.3+ Acked-by: Michal Simek <michal.simek@amd.com> Reviewed-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260924-i2c-xiic-v7-3-df7e752332ef@nexthop.ai
2026-09-28i2c: xiic: defer RX_FULL until all trailing bytes are in FIFOAbdurrahman Hussain
For the normal path of xiic_smbus_block_read_setup() -- the trailing bytes all fit in one Rx FIFO fill -- RFD was programmed two below the byte count, which fires the RX_FULL interrupt while the last byte is still in flight. xiic_read_rx() then lands in its bytes_rem == 1 branch and sets NACK on a byte still on the wire, truncating the read. Without PEC this is harmless: the truncated byte is the dummy one the caller never looks at. With PEC enabled it is the PEC byte itself, and i2c_smbus_check_pec() fails the transfer with -EBADMSG. Raise the threshold by one so RX_FULL fires only once every remaining byte is already buffered. That routes the drain through xiic_read_rx()'s bytes_rem == 0 path, which reads everything out and emits the stop cleanly. The only change for the non-PEC case is that the controller waits one extra byte-time before servicing the interrupt. rfd_set stays inside the 4 bits of XIIC_RFD_REG_OFFSET: this branch is only reached when rxmsg_len + pec_len <= IIC_RX_FIFO_DEPTH, so the value is at most IIC_RX_FIFO_DEPTH - 1. Fixes: e4c1ff772e1a ("i2c: xiic: Add smbus_block_read functionality") Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai> Cc: <stable@vger.kernel.org> # v6.3+ Acked-by: Michal Simek <michal.simek@amd.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260924-i2c-xiic-v7-2-df7e752332ef@nexthop.ai
2026-09-28i2c: xiic: preserve PEC byte length in SMBus block read setupAbdurrahman Hussain
xiic_smbus_block_read_setup() recalculates i2c->rx_msg->len based on the length byte returned by the device, but historically clobbered the PEC byte expectation the SMBus core had baked into msg->len. That dropped the PEC byte from the caller's buffer on the normal and chunked receive-fifo branches. Compute pec_len up-front as (i2c->rx_msg->len - 1) -- the trailing bytes the caller has already accounted for beyond the length byte, 1 when the SMBus core enabled PEC, and possibly more for an I2C_M_RECV_LEN request coming from i2c-dev -- and add it to the new length in every branch: - chunked: the trailing bytes do not fit in the Rx FIFO, so drain in chunks. The guard becomes (rxmsg_len + pec_len > IIC_RX_FIFO_DEPTH) rather than rxmsg_len alone, both because pec_len bytes also have to fit and because it is what bounds rfd_set in the else branch below to the 4 bits of XIIC_RFD_REG_OFFSET. - padded (1 + rxmsg_len + pec_len < SMBUS_BLOCK_READ_MIN_LEN): the hardware needs at least 3 bytes on the bus to exit the read cleanly (the second byte is already being clocked in by the time the ISR reads the length byte and is too late to NACK), so we still pad rx_msg->len up to SMBUS_BLOCK_READ_MIN_LEN. The dummy trailing byte that gets drained must then be trimmed off before handing the message back to the SMBus core; otherwise i2c_smbus_check_pec() reads buf[len-1] (= dummy) instead of the real PEC byte at buf[1] and rejects every clean zero-length block read with -EBADMSG. Record the true valid byte count in a new field i2c->smbus_actual_len and trim rx_msg->len down to it in xiic_smbus_trim_len(), called from both completion sites that clear rx_msg: xiic_process()'s RX_FULL branch and xiic_recv_atomic(), which drains the FIFO with interrupts off. smbus_actual_len is per-receive state, so xiic_start_recv() clears it before every receive. Only the padded branch ever sets it, and a block read aborted by arbitration loss or a TX error never reaches the completion site, so without that clear a stale value would trim the length of an unrelated later read. The condition is expressed in total bytes rather than the old "(rxmsg_len == 1) || (rxmsg_len == 0)" so that a request carrying more than one trailing byte does not get padded: padding records a length the drain never reaches, which would hand the caller a byte that was never received. - normal: all trailing bytes fit in one FIFO fill. rfd_set gains pec_len for the same reason the length does. Because the padded branch above has already taken every case with fewer than SMBUS_BLOCK_READ_MIN_LEN total bytes, rxmsg_len + pec_len is at least 2 here and the subtraction cannot underflow the u8. Fixes: e4c1ff772e1a ("i2c: xiic: Add smbus_block_read functionality") Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai> Cc: <stable@vger.kernel.org> # v6.3+ Acked-by: Michal Simek <michal.simek@amd.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260924-i2c-xiic-v7-1-df7e752332ef@nexthop.ai
2026-09-24i2c: ljca: drop redundant explicit adapter deletionFelix Gu
This driver uses devm_i2c_add_adapter(), so manual i2c_del_adapter() in remove() is unnecessary. Remove ljca_i2c_remove() along with the now unneeded auxiliary_setdrvdata(). Signed-off-by: Felix Gu <ustc.gu@gmail.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260905-ljca-v1-1-9109616ff1c6@gmail.com
2026-09-24i2c: qcom-geni: Fix hardcoded clock index in SE_GENI_CLK_SELViken Dadhaniya
qcom_geni_i2c_conf() writes a hardcoded 0 to SE_GENI_CLK_SEL, which selects an index from the hardware clock performance table. This always picks the first table entry regardless of the actual source clock configuration. On platforms where the matching entry is not at index 0, the wrong source clock divider is active and the I2C bus runs at an incorrect frequency. Use geni_se_clk_freq_match() in geni_i2c_clk_map_idx() to find the performance table index for the source clock (32 MHz or 19.2 MHz). Store the resolved index in a new clk_idx field in geni_i2c_dev and write it to SE_GENI_CLK_SEL instead of the hardcoded 0. Fixes: 37692de5d523 ("i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller") Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> Cc: <stable@vger.kernel.org> # v4.19+ Reviewed-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260921-i2c-fix-se-clk-conf-v2-1-8b5537ceff2d@oss.qualcomm.com
2026-09-20i2c: qcom-cci: fix device_node refcount leak in cci_probe()/cci_remove()Liu Zhenlong
The of_node_put() matching of_node_get() runs after i2c_del_adapter(), whose trailing memset() zeroes adap->dev and thus adap->dev.of_node, making the put a no-op and leaking the node on every adapter removal and error cleanup. Use a devm action: the pointer is captured at registration, out of reach of that memset(), and devres runs the put once on probe failure and detach, replacing the three manual of_node_put() calls. The setup loop uses the scoped iterator form so the child node is released automatically if devm_add_action_or_reset() fails mid-loop. Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Fixes: 02a4a69667a2 ("i2c: qcom-cci: don't put a device tree node before i2c_add_adapter()") Assisted-by: Claude:claude-opus-5 Signed-off-by: Liu Zhenlong <dragonliu2018@gmail.com> Cc: <stable@vger.kernel.org> # v5.17+ Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260818175750.4205-1-dragonliu2018@gmail.com
2026-09-20i2c: qcom-geni: release DMA channels on probe errorShengzhuo Wei
geni_i2c_init() grabs exclusive GPI tx/rx DMA channels when the serial engine runs in GPI mode. If i2c_add_adapter() subsequently fails, probe returns without releasing the channels, because the remove callback is not invoked after a failed probe. The adapter-registration failure path used to release the channels via its err_dma label; that release was dropped when the probe tail was restructured into geni_i2c_init(). Release the channels on the adapter-registration failure path, mirroring geni_i2c_remove(). Fixes: d8d3bb127ad1 ("i2c: qcom-geni: Isolate serial engine setup") Assisted-by: GLM:5.3 Signed-off-by: Shengzhuo Wei <me@cherr.cc> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260827-i2c-dma-channel-leak-v1-3-271d4adc03a0@cherr.cc
2026-09-20i2c: imx: release DMA channels on probe errorShengzhuo Wei
i2c_imx_dma_request() acquires exclusive tx/rx DMA channels and is optional: on errors other than -EPROBE_DEFER the driver falls back to PIO mode and probe continues. If i2c_add_numbered_adapter() then fails, probe returns through clk_notifier_unregister without releasing the channels, because the remove callback is not invoked after a failed probe. Release the channels on the probe error path, mirroring i2c_imx_remove(). Fixes: ce1a78840ff7 ("i2c: imx: add DMA support for freescale i2c driver") Assisted-by: GLM:5.3 Signed-off-by: Shengzhuo Wei <me@cherr.cc> Cc: <stable@vger.kernel.org> # v3.19+ Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260827-i2c-dma-channel-leak-v1-2-271d4adc03a0@cherr.cc
2026-09-20i2c: at91: release DMA channels on remove and probe errorShengzhuo Wei
at91_twi_configure_dma() requests exclusive tx/rx DMA channels, but nothing ever releases them on driver detach, and the probe error path after the channels are acquired (i2c_add_numbered_adapter() failure) returns without releasing them either, because the remove callback is not invoked after a failed probe. Move the release into a helper, call it from the existing configure-failure path, the adapter-registration failure path, and at91_twi_remove(). Fixes: 60937b2cdbf9 ("i2c: at91: add dma support") Assisted-by: GLM:5.3 Signed-off-by: Shengzhuo Wei <me@cherr.cc> Cc: <stable@vger.kernel.org> # v3.8+ Acked-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260827-i2c-dma-channel-leak-v1-1-271d4adc03a0@cherr.cc
2026-09-16i2c: imx: disable autosuspend on removeGuangshuo Li
i2c_imx_probe() enables runtime PM autosuspend with pm_runtime_use_autosuspend(). The probe error path correctly undoes this setting with pm_runtime_dont_use_autosuspend(), but the normal remove path only disables runtime PM. The runtime PM API requires pm_runtime_use_autosuspend() to be undone with pm_runtime_dont_use_autosuspend() at driver exit unless runtime PM was enabled with devm_pm_runtime_enable(). Leaving the autosuspend flag set therefore leaves the runtime PM state incompletely cleaned up after the driver is unbound. Add the missing pm_runtime_dont_use_autosuspend() call to the remove path. This issue was found by manual code inspection. Fixes: 588eb93ea49f ("i2c: imx: add runtime pm support to improve the performance") Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Cc: <stable@vger.kernel.org> # v4.5+ Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260914091544.1667137-1-lgs201920130244@gmail.com
2026-09-10i2c: qcom-geni: Simplify PM resume error handlingMukesh Kumar Savaliya
The driver currently logs pm_runtime_resume_and_get() failures with dev_err() and returns the error code separately. Replace this with dev_err_probe(), which combines the dev_err() log message and the return value propagation into a single call, consistent with how all other error paths in this driver already report failures. No functional change intended. Signed-off-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com> Acked-by: Praveen Talari <praveen.talari@oss.qualcomm.com> Reviewed-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260805070013.494426-1-mukesh.savaliya@oss.qualcomm.com
2026-09-09i2c: qcom-geni: Use modern PM operation macrosMukesh Kumar Savaliya
The driver uses the legacy SET_NOIRQ_SYSTEM_SLEEP_PM_OPS() and SET_RUNTIME_PM_OPS() helpers to initialize struct dev_pm_ops. Switch to the modern NOIRQ_SYSTEM_SLEEP_PM_OPS() and RUNTIME_PM_OPS() macros instead. These macros keep PM callbacks referenced by the compiler and help avoid potential unused-function warnings in configurations where PM support is disabled or partially enabled. No functional change intended. Signed-off-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com> Reviewed-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260729073040.3227692-1-mukesh.savaliya@oss.qualcomm.com
2026-09-09i2c: bcm2835: Make sure clk_init_data is fully initializedGeert Uytterhoeven
The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. Make sure all members are fully initialized, to avoid such bugs, and to prevent future breakage when converting drivers to a different method for specifying the parents. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/9f82f37e6d6c069cd44326bcd5e5a2a8069a13a9.1787239980.git.geert+renesas@glider.be
2026-09-09i2c: busses: Use pm_runtime_resume_and_get()Alex Tran
Utilize the provided pm_runtime_resume_and_get api to increase the usage count and call the rpm resume callback. Upon failure, the function takes care of calling pm_runtime_put_noidle. Remove the explicit call to put no idle. No functional change added. Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com> Reviewed-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patch.msgid.link/20260826-i2c-qcom-geni-pm-runtime-resume-get-v1-1-25ee55d1f0c8@oss.qualcomm.com
2026-09-04treewide: refresh kmalloc_obj() conversionsKees Cook
This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook <kees+treewide@kernel.org>
2026-08-30Merge tag 'i2c-fixes-7.3-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux Pull i2c fixes from Andi Shyti: "Fixes mainly for teardown and resource handling, runtime PM and hardware-specific controller issues: - fix debugfs use-after-free when removing the adapter - designware: apply interrupt mask quirk for HJMC3001 - imx-lpi2c: avoid target accesses on master-only controllers - mux: release channel node when adapter registration fails - qcom-cci: fix autosuspend and runtime PM cleanup on removal - qcom-geni: fix timing parameters for 32 MHz clock" * tag 'i2c-fixes-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux: i2c: core: fix debugfs UAF on adapter removal i2c: imx-lpi2c: avoid accessing target registers on master-only controllers i2c: qcom-cci: fix autosuspend cleanup i2c: designware: Enable interrupt mask workaround for HJMC3001 i2c: qcom-geni: update frequency table to fix timing parameters i2c: mux: Fix channel node leak on adapter add failure
2026-08-28Merge tag 'drm-next-2026-08-29' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull more drm updates from Dave Airlie: "As mentioned last week, an msm pull request fell down the side of the couch or whatever the email equivalent of that is. This has the msm next stuff + the usual fixes for amd/intel. core: - use drm_warn instead of warn msm: - Bindings: - Added Shikra support - Document a840, a704, a722 - Core: - Use drm_client buffers for fbdev emulation - teardown fixes - ARM32 DMA fixup - Remove objects from evict list when re-validated - Bunch of corner case and error path fixes - DPU: - Dropped dev_pm_opp_set_rate(0) preventing burnout - Fixed SSPP offsets of Kaanapali - DP: - Dropped dev_pm_opp_set_rate(0) preventing burnout - Cleaned up core code in preparation for MST support - Fixed prepare() to let Pipewire continue in case of the unplugged cable - GPU: - Add support for a704 - Add support for a722 - HDMI: - Simplifed register access amdgpu: - eGPU fixes - Runtime PM fix - UserQ fixes - Backlight fix - Discovery sysfs fix - Reset handling fixes - Buffer func handling fix for xgmi - VCN boundary check fix - DC lut handling fixes - MES fixes - UVD fix - VCE 3 fix - Enforce isolation fix - HPD fix for VGA/LVDS - DML fix - DCN 6 fixes - DC gpu reset fix amdkfd: - Fix return value - CU occupancy for GFX 11 - CU occupancy for GFX 12/12.1 - Queue bounds checking fix - SVM fixes - CRIU bounds checking fix radeon: - iMac display fix xe: - error message cleanups - i2c global register definitions as dependency for xe/i2c fixes - Media workardound - Add CCS to gt_idle debugfs print - Page fault related fix - i2c related fixes - System Controller mailbox bit fix" * tag 'drm-next-2026-08-29' of https://gitlab.freedesktop.org/drm/kernel: (121 commits) drm/xe/sysctrl: Read mailbox phase bit from hardware drm/xe/i2c: Keep the i2c controller always enabled drm/xe/i2c: Fix the interrupt handling i2c: designware: Global register definitions drm/xe: Reject page faults from non-fault-mode scratch VMs drm/xe/xe_gt_idle: Add CCS to the powergating info print drm/xe: Do not apply WA 14025883347 to media 3503 drm/amd/display: fix dc_lock leak on GPU reset error paths drm/amd/display: Fix redundant GPUVMEnable checks in dcn6 flip schedule drm/amd/display: Fix wrong bytes-per-pixel value for dml2_422_packed_10 drm/amdkfd: guard against NULL restore_mqd in CRIU queue restore drm/amdgpu/userq: fix lock missing for userq fence error set drm/amdkfd: Fix the case that vm range is hole at svm_migrate_copy_to_vram drm/amdkfd: Fix error path at svm_migrate_copy_to_ram drm/amd/display: Log details when failing to register HPD IRQ drm/amd/display: Fix HPD consideration for VGA/LVDS connectors on DCE drm/amdgpu: clamp the isolation index for rings outside a partition drm/amdkfd: Reject zero-sized AQL queue allocations after size halving drm/amdgpu: Fix VCE 3 ring align_mask drm/kfd: Add CU occupancy support to GFX12.1 ...
2026-08-28i2c: imx-lpi2c: avoid accessing target registers on master-only controllersCarlos Song
Not all LPI2C controller instances implement the Target block. Since commit 90311787f483 ("i2c: imx-lpi2c: reset controller in probe stage"), the driver unconditionally resets both the Master and Target blocks during probe. On controllers that do not support target mode, accessing the Target registers triggers an asynchronous SError and prevents the driver from probing successfully. For example on i.MX8QM: SError Interrupt on CPU2, code 0x00000000bf000002 -- SError Hardware name: Freescale i.MX8QM MEK (DT) pc : lpi2c_imx_probe+0x280/0x594 lr : lpi2c_imx_probe+0x224/0x594 Kernel panic - not syncing: Asynchronous SError Interrupt The VERID register is implemented in the Master block and can be safely accessed on all controller variants. Its FEATURE field indicates whether target mode is supported. Read VERID during probe and use it to determine whether the Target block is present. Only access Target registers when target mode is supported and reject target registration requests with -EOPNOTSUPP otherwise. Fixes: 90311787f483 ("i2c: imx-lpi2c: reset controller in probe stage") Signed-off-by: Carlos Song <carlos.song@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260803032705.2250373-1-carlos.song@oss.nxp.com
2026-08-28i2c: qcom-cci: fix autosuspend cleanupGuangshuo Li
cci_probe() calls pm_runtime_use_autosuspend(), but the remove path does not call the matching pm_runtime_dont_use_autosuspend() before disabling runtime PM. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without undoing the autosuspend setting during teardown, this reference is not dropped and usage_count remains unbalanced. Use devm_pm_runtime_set_active_enabled() to manage the runtime PM state. Its managed cleanup disables autosuspend and runtime PM and restores the suspended state on probe failure and driver removal. Remove the now redundant manual runtime PM cleanup. This issue was found by manual code inspection. Fixes: e517526195de ("i2c: Add Qualcomm CCI I2C driver") Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Cc: <stable@vger.kernel.org> # v5.8+ Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260812094425.3515179-1-lgs201920130244@gmail.com
2026-08-28i2c: designware: Enable interrupt mask workaround for HJMC3001Hongbo Yao
On HJMicro ARM64 servers, the DesignWare I2C controller does not retrigger a pending interrupt if the interrupt status changes after the current status bits have been cleared. The issue is exposed under heavy system load when the corresponding SPI is routed across sockets to a core in the remote socket. The interrupt is then lost and the I2C transfer times out. Enable ACCESS_INTR_MASK for HJMC3001. This toggles DW_IC_INTR_MASK before returning from the interrupt handler and retriggers any pending interrupt. Fixes: 6816ce57c479 ("i2c: designware: Add a new ACPI HID for HJMC01 I2C controller") Signed-off-by: Hongbo Yao <andy.xu@hj-micro.com> Cc: <stable@vger.kernel.org> # v6.13+ Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260826070547.268672-1-andy.xu@hj-micro.com
2026-08-28i2c: qcom-geni: update frequency table to fix timing parametersKathiravan Thirumoorthy
In IPQ5424, to meet the setup and hold timing requirements in the standard mode, update the frequency table with the values recommended by HW design team. Also remove the stray space in the I2C_MAX_FAST_MODE_FREQ entry. Fixes: 85c34532849d ("i2c: qcom-geni: fix I2C frequency table to achieve accurate bus rates") Fixes: 506bb2ab0075 ("i2c: qcom-geni: Support systems with 32MHz serial engine clock") Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Cc: <stable@vger.kernel.org> # v6.13+ Reviewed-by: Mukesh Savaliya <mukesh.savaliya@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260812-ipq5424_i2c_scl_updates-v2-1-e09cd39d01d7@oss.qualcomm.com