This second part 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
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQScDfrjQa34uOld1VLaeAVmJtMtbgUCat5h5QAKCRDaeAVmJtMt
biyNAP9gA0/jhwsviVHxdXGc5MwNIA3ldVWH3DInK0Ei0zdUvwEA3LtcEdtrxWy9
ifakgLufzgUdzxv1H+h7HPimEyEqcQc=
=ZZC3
-----END PGP SIGNATURE-----
Merge tag 'i2c-7.4-part2' of 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
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
- 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.
The changes to several #include lists have been reported to cause trivial
conflicts in linux-next with the drm, drm-xe, and usb trees.
-----BEGIN PGP SIGNATURE-----
iQFkBAABCABOFiEEIduBR9MnFA82q/jtumpXJwqY6poFAmrWJvAbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyFBxwZXRyLnBhdmx1QHN1c2UuY29tAAoJELpqVycK
mOqalOYH/RpwszqX+OuRhf3G9IDokSZFZyiAJLZan3H7jZNb9VBVLYmTTRYF/UE4
uXKeGAUXZOaUdhVjQi/1LqX3NbDO1NfUCM9sbk3EPal0L6ILbcmkBecXu9JXHxvB
6sfEAdTMdAn28613wcnbjmdGfEkgHuDZqZeld4dIAtZ+GvLzFz0D+o0zkigCnT4I
faKU9GLIHJe2Cn5FB40b1+M+IGY9t6bl2+WxVc1rd9oSZXfr8ptE7NPllhiOmOhD
/aMVpeSlXzo8DYxIhvtZGwDh5NrJglPFdFRXYuHUDLxkWCCFtXRt//LtWv3EpKqp
dgQUH5QAO5E/+OuycHFLaXOUiKVS0P4=
=bCLk
-----END PGP SIGNATURE-----
Merge tag 'modules-7.4-rc1' of 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()
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
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: d04913ec5f ("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
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: c3ae106050 ("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>
i2c_acpi_new_device_by_fwnode() obtains an i2c_adapter through
i2c_acpi_find_adapter_by_handle(). That helper uses bus_find_device()
internally, so it returns the adapter with a reference held:
adapter = i2c_verify_adapter(dev);
if (!adapter)
put_device(dev);
return adapter;
The reference is only put on the failure path inside that helper. The
caller owns it otherwise. i2c_acpi_new_device_by_fwnode() never drops
it, neither on the -EPROBE_DEFER path nor after
i2c_new_client_device(), so every call leaks one reference on the
adapter and the adapter can never be released.
i2c_new_client_device() does not consume that reference. It registers
the new client with the adapter as its parent, and device_add() takes
its own reference on the parent, which device_del() releases when the
client goes away. The reference obtained by the lookup is a separate
one and has to be dropped here.
i2c_acpi_notify() in the same file already does exactly this. It takes
the adapter from the same helper, registers the client through
i2c_acpi_register_device(), which calls i2c_new_client_device(), and
then puts the reference.
i2c_new_client_device() gives the client its own reference on the
adapter, so ours can be dropped unconditionally.
Found by code review.
Fixes: 605f8fc224 ("i2c: core: Add new i2c_acpi_new_device helper function")
Signed-off-by: Ma Ke <make_ruc2021@163.com>
Cc: <stable@vger.kernel.org> # v4.12+
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://patch.msgid.link/20261012013421.3597430-1-make_ruc2021@163.com
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
The transfer timeout for an I2C controller should reflect the actual
message length and bus frequency rather than a static 1-second value.
A static timeout causes unnecessary delays on error paths for short
messages, and may be insufficient for very long transfers.
Add i2c_update_timeout() to i2c-core which computes a transfer-specific
timeout and stores it directly in the standard adap->timeout field. The
formula accounts for 9 bits per byte (8 data + 1 ACK) at the configured
bus frequency. The caller supplies a safety multiplier and a minimum
floor so that each driver retains full control over its timing policy
without those values becoming public API.
Storing the result in adap->timeout makes it visible to all consumers of
that field, including the arbitration-loss retry loop in __i2c_transfer().
The function is gated by CONFIG_I2C_DYNAMIC_TIMEOUT. When the config is
disabled, i2c_update_timeout() compiles to a no-op inline stub so drivers
that call it build cleanly and the existing static 1-second default is
preserved unchanged.
A timeout explicitly configured by userspace via the I2C_TIMEOUT ioctl is
stored in a new adap->user_timeout field and always takes precedence over
the kernel-computed value. When userspace has not configured a timeout,
the computed value is used. The ioctl keeps writing adap->timeout as well,
so adapters that never call i2c_update_timeout() continue to honour it
exactly as before.
As i2c_update_timeout() is an exported helper, guard against a zero bus
frequency from a misbehaving caller with WARN_ON_ONCE() and return early,
leaving the existing timeout untouched as a safe fallback rather than
dividing by zero.
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-1-77ac458344e2@oss.qualcomm.com
A mix of new hardware support, driver improvements and smaller
core, DT binding and documentation cleanups.
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)
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQScDfrjQa34uOld1VLaeAVmJtMtbgUCatfuigAKCRDaeAVmJtMt
bu2DAQDvyVRaTGxk7ijnmwHNXXhr9BHKtNxr1ssBpEl8qwoVxgEA2+Si+fpQeovk
zim0KJGxCoPVJuvfbNHojSaOviTdpQw=
=7W7U
-----END PGP SIGNATURE-----
Merge tag 'i2c-7.4-part1' of 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
...
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: 50c63491ff ("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
__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>
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
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: e517526195 ("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
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
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.
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-1-caf4bea4886c@thegoodpenguin.co.uk
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
The main read / write "buffer" is kzalloc()ed and as such is safe to
directly use for DMA (unlike stack mem). Add the I2C_M_DMA_SAFE flag
to the transfers using these buffers.
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Acked-by: Mika Westerberg <westeri@kernel.org>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://patch.msgid.link/20260919193642.43058-1-johannes.goede@oss.qualcomm.com
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: cb97bf3d4f ("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
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: 560746eb79 ("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
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
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
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: fa1eb3af12 ("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
The i2c subsystem currently blocks during adapter deregistration
whenever there are consumers holding a reference.
Document that i2c_get_adapter_by_fwnode(), which also takes a module
reference, should almost always be preferred over
i2c_find_adapter_by_fwnode() so that an attempt to unload the adapter
module while in use fails gracefully instead of blocking
uninterruptibly.
Note that by implication of_get_i2c_adapter_by_node() is also generally
preferred over of_find_i2c_adapter_by_node().
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://patch.msgid.link/20260716133029.1565853-1-johan@kernel.org
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
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
The ASUE140D touchpad on the ASUS Zenbook UX3404VC (BIOS UX3404VC.303)
starts lagging shortly after boot when the bus runs at the 400 kHz the
DSDT asks for, and only recovers after rebinding i2c-hid. Forcing
100 kHz fixes it.
Signed-off-by: Harinn <prinn.dev@pm.me>
Acked-by: Mika Westerberg <westeri@kernel.org>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://patch.msgid.link/20261004-i2c-acpi-asue140d-100khz-v1-1-cc2dbad00470@pm.me
The attach_addr() and detach_addr() callbacks may need to reconfigure
the remote side of the bus. Maxim GMSL deserializers, for example,
disable all links but one to reach a serializer at its default address,
since all serializers power up at the same address.
Transfers on other channels of the same ATR can run concurrently with
these callbacks and fail with -EIO while the links are disabled.
Take the ATR bus lock around both callbacks, before alias_pairs_lock.
i2c_atr_replace_mapping_by_addr() already calls them under this lock,
so ATR drivers see no new constraint.
Suggested-by: Quentin Freimanis <quentin@q-lab.dev>
Signed-off-by: Dumitru Ceclan <dumitru.ceclan@analog.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
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: 10e74f4c50 ("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
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
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
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
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
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
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: f7eeb1af85 ("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
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
i2c_smbus_read_block_data() is dangerous to use because it may deliver
up to I2C_SMBUS_BLOCK_MAX (32) bytes, which may be surprising to the
caller. Callers tend to allocate buffers of sizes big enough to hold
data from a well-behaving device and do not expect that
i2c_smbus_read_block_data() may attempt to write more data than
expected.
To make i2c_smbus_read_block_data() safer to use, change it so that
it accepts size of the supplied buffer as another argument and ensure
that it will not copy more data than the size of the buffer. Signal
oversized responses with -EMSGSIZE.
To allow users to gradually transition to the new API employ some
macro trickery allowing calling i2c_smbus_read_block_data() with either
3 or 4 arguments. When called with 3 arguments it is assumed that
the buffer size is I2C_SMBUS_BLOCK_MAX bytes. Once everyone is
transitioned to the 4 argument form the macros should be removed.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://patch.msgid.link/ammWUROtUGeriY8G@google.com
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: e4c1ff772e ("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
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: e4c1ff772e ("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
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: e4c1ff772e ("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
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
Device Tree channel nodes are associated with the adapters created by
i2c-mux, but equivalent firmware-node descriptions are not.
Use generic firmware-node operations for the existing channel lookup
and associate the returned node with the adapter. Do not restrict the
lookup by firmware-node type, so Device Tree, software nodes, and ACPI
descriptions all follow the same property traversal. The existing
acpi_preset_companion() call remains in place for the standard ACPI
channel association.
Keep a separate reference to the node returned by the generic lookup
because acpi_preset_companion() may replace the device's primary
firmware node. Release the saved reference after adapter deletion.
Signed-off-by: Ahmad Byagowi <ahmadexp@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://patch.msgid.link/00b33b4b352848ff87dd9089190b35d8732676f3.1788623619.git.ahmadexp@gmail.com
Move the existing Device Tree channel-node lookup into a helper in
preparation for using generic firmware-node operations.
This is a pure refactoring with no functional change.
Signed-off-by: Ahmad Byagowi <ahmadexp@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://patch.msgid.link/adf12f66229d5faa0bc75571da1c3f53a1c81dd8.1788623619.git.ahmadexp@gmail.com
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: 37692de5d5 ("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
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: 02a4a69667 ("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
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: d8d3bb127a ("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
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: ce1a78840f ("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
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: 60937b2cdb ("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
i2c_atr_add_adapter() stores atr->adapter[chan_id] before
i2c_add_adapter() so that the I2C bus notifier can match child clients
during registration. On failure the channel is freed but the slot was
left pointing at freed memory, which can lead to use-after-free in
i2c_atr_del_adapter() / cleanup and also block reuse with -EEXIST.
Clear the slot on the i2c_add_adapter() error path before freeing chan.
Fixes: a076a860ac ("media: i2c: add I2C Address Translator (ATR) support")
Signed-off-by: Linkai Gong <gonglinkai@kylinos.cn>
Cc: <stable@vger.kernel.org> # v6.6+
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://patch.msgid.link/20260907071102.1080840-1-gonglinkai@kylinos.cn
