kernel/git/stable/linux-stable.git/drivers/i2c, branch linux-6.18.y

i2c: i801: fix hardware state machine corruption in error path

2026-07-18T14:53:34+00:00

commit 10dd1a736d557e310a77117832874729a0175d57 upstream. A severe livelock and subsequent Hung Task panic were observed in the i2c-i801 driver during concurrent Fuzzing. The crash is caused by an unconditional hardware register cleanup in the error handling path of i801_access(). When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus controller is actively used by BIOS/ACPI), the kernel does not actually acquire the hardware ownership. However, the code jumps to the 'out' label and executes: iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv)); This forcefully clears the INUSE_STS lock and resets the hardware status flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI transactions and totally corrupts the SMBus hardware state machine. Consequently, all subsequent i801_access() calls fail at the pre-check stage, triggering an endless stream of "SMBus is busy, can't use it!" error logs. Over a slow serial console, this printk flood monopolizes the CPU (Console Livelock), starving other processes trying to acquire the mmap_lock down_read semaphore, ultimately triggering the hung task watchdog. Fix this by moving the 'out' label below the hardware register cleanup. If i801_check_pre() fails, we safely bypass the iowrite8() and only release the software locks (pm_runtime and mutex), strictly adhering to the rule of not releasing resources that were never acquired. Fixes: 1f760b87e54c ("i2c: i801: Call i801_check_pre() from i801_access()") Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Cc: # v6.3+ Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260512093534.348655-1-w15303746062@163.com Signed-off-by: Greg Kroah-Hartman

i2c: imx-lpi2c: mark I2C adapter when hardware is powered down

2026-07-18T14:53:34+00:00

commit 218cfe364b55b2768221629bd4a69ad190b7fbbc upstream. On some i.MX platforms, certain I2C client drivers keep a periodic workqueue which continues to trigger I2C transfers. During system suspend/resume, there exists a time window between: - suspend_noirq and the system entering suspend - the system starting to resume and resume_noirq In this window, the I2C controller resources such as clock and pinctrl may already be disabled or not yet restored. If a workqueue triggers an I2C transfer in this period, the driver attempts to access I2C registers while the hardware resources are unavailable, which may lead to system hang. Mark the I2C adapter as suspended during noirq suspend and block new transfers until resume, ensuring that I2C transfers are only issued when hardware resources are available. Fixes: 1ee867e465c1 ("i2c: imx-lpi2c: add target mode support") Signed-off-by: Carlos Song Cc: # v6.14+ Acked-by: Mukesh Savaliya Reviewed-by: Frank Li Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260525031450.3183421-1-carlos.song@oss.nxp.com Signed-off-by: Greg Kroah-Hartman

i2c: stm32f7: truncate clock period instead of rounding it

2026-07-18T14:53:34+00:00

commit 111bb7f9f4a90b32e495d70a607c67b137f3074a upstream. stm32f7_i2c_compute_timing() derives the I2C clock source period (i2cclk) with DIV_ROUND_CLOSEST, which may round it up. When the period is overestimated, all timings computed from it (SCLDEL, SDADEL, SCLL, SCLH) come out shorter on the wire than calculated, and the resulting bus rate can exceed the requested speed, violating the I2C specification minimums for tLOW and tHIGH. For example, with a 104.45 MHz clock source (e.g. PCLK1, the reset-default I2C clock source on STM32MP1), i2cclk is rounded from 9.574 ns up to 10 ns. Requesting a 400 kHz fast mode bus with 72/27 ns rise/fall times and no analog/digital filters then produces an actual bus rate of 415.6 kHz with tLOW = 1254 ns, violating both the 400 kHz maximum rate and the 1300 ns tLOW minimum of the specification. Truncate the period instead, so that it can only be underestimated. The error then falls on the safe side: the programmed timings come out slightly longer than computed and the bus runs marginally below the target rate (375.3 kHz in the example above) while meeting the specification. i2cbus is left rounded-to-closest: it is only used as the target of the clk_error comparison and is never multiplied into the programmed timings, so nearest rounding remains accurate there. Fixes: aeb068c57214 ("i2c: i2c-stm32f7: add driver") Signed-off-by: Guillermo Rodríguez Cc: # v4.14+ Acked-by: Alain Volmat Reviewed-by: Pierre-Yves MORDRET Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260611104857.242153-1-guille.rodriguez@gmail.com Signed-off-by: Greg Kroah-Hartman

i2c: davinci: Unregister cpufreq notifier on probe failure

2026-07-18T14:53:34+00:00

commit e43f32816a1b1fe5a86279411626fe3a9be56d45 upstream. davinci_i2c_probe() registers a cpufreq transition notifier before adding the I2C adapter. If i2c_add_numbered_adapter() fails, the probe error path releases the device resources without unregistering the notifier. Add a dedicated error path to unregister the cpufreq notifier after i2c_add_numbered_adapter() fails. Fixes: 82c0de11b734 ("i2c: davinci: Add cpufreq support") Signed-off-by: Haoxiang Li Cc: # v2.6.36+ Reviewed-by: Bartosz Golaszewski Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260610030513.2651018-1-haoxiang_li2024@163.com Signed-off-by: Greg Kroah-Hartman

i2c: mpc: Fix timeout calculations

2026-07-18T14:53:34+00:00

commit 2e9a7f68329be41792c0b123c28e6c53c2fa2249 upstream. At first glance the harmless cleanup of the driver does nothing bad. However, as the operator precedence list states the '*' (multiplication) and '/' division operators have order 5 with left-to-right associativity the *= has order 17 and associativity right-to-left. It wouldn't be a problem to replace foo = foo * HZ / 1000000; with foo *= HZ / 1000000; if HZ constant is in Hertz. The problem is that in the Linux kernel HZ is defined in jiffy units, which is order of magnitude smaller than a million. That's why operator precedence has a crucial role here. Fix the regression by reverting pre-optimized calculations. Fixes: be40a3ae719f ("i2c: mpc: Use of_property_read_u32 instead of of_get_property") Signed-off-by: Andy Shevchenko Cc: # v6.4+ Reviewed-by: Chris Packham Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260618144934.3249950-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman

i2c: core: fix adapter deregistration race

2026-07-18T14:53:33+00:00

commit b1a58ed9eab146b36f41a55db8f5d7ce9fdedf3f upstream. Adapters can be looked up by their id using i2c_get_adapter() which takes a reference to the embedded struct device. Remove the adapter from the IDR before tearing it down during deregistration (and on registration failure) to make sure its resources are not accessed after having been freed (e.g. the device name). Fixes: 35fc37f81881 ("i2c: Limit core locking to the necessary sections") Cc: stable@vger.kernel.org # 2.6.31 Cc: Jean Delvare Signed-off-by: Johan Hovold Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman

i2c: core: fix adapter debugfs creation

2026-07-18T14:53:33+00:00

commit 07d5fb537928aad4369aaff0cbae73ba38a719af upstream. Clients can be registered from bus notifier callbacks so the debugfs directory needs to be created before registering the adapter as clients use that directory as their debugfs parent. Move debugfs creation before adapter registration to avoid having clients create their debugfs directories in the debugfs root (which is also more likely to fail due to name collisions). Note that failure to allocate the adapter name must now be handled explicitly as debugfs_create_dir() cannot handle a NULL name (unlike device_add() which returns an error). Fixes: 73febd775bdb ("i2c: create debugfs entry per adapter") Cc: stable@vger.kernel.org # 6.8 Cc: Wolfram Sang Signed-off-by: Johan Hovold Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman

i2c: core: fix adapter probe deferral loop

2026-07-18T14:53:33+00:00

commit 158efa411c57111d87bf265a3776614f32d70007 upstream. Drivers must not probe defer after having registered devices as that will trigger a probe loop if the devices bind to a driver (cf. commit fbc35b45f9f6 ("Add documentation on meaning of -EPROBE_DEFER")). Move the recovery initialisation, where the GPIO lookup may fail, before registering the adapter to prevent this. Fixes: 75820314de26 ("i2c: core: add generic I2C GPIO recovery") Cc: stable@vger.kernel.org # 5.9 Cc: Codrin Ciubotariu Signed-off-by: Johan Hovold Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman

i2c: core: fix NULL-deref on adapter registration failure

2026-07-18T14:53:33+00:00

commit 2295d2bb101faa663fbc45fadbb3fec45f107441 upstream. If adapter registration ever fails the release callback would trigger a NULL-pointer dereference as the completion struct has not been initialised. Note that before the offending commit this would instead have resulted in a minor memory leak of the adapter name. Fixes: 3f8c4f5e9a57 ("i2c: core: fix reference leak in i2c_register_adapter()") Cc: stable@vger.kernel.org Cc: Joe Hattori Signed-off-by: Johan Hovold Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman

i2c: core: fix irq domain leak on adapter registration failure

2026-07-18T14:53:33+00:00

commit 8ce19524e4cc2462685f596a6402fbd8fb984ab2 upstream. Make sure to tear down the host notify irq domain on adapter registration failure to avoid leaking it. This issue was flagged by Sashiko when reviewing another adapter registration fix. Fixes: 4d5538f5882a ("i2c: use an IRQ to report Host Notify events, not alert") Cc: stable@vger.kernel.org # 4.10 Cc: Benjamin Tissoires Signed-off-by: Johan Hovold Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman