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

i2c: designware-pci: Group AMD NAVI quirk parts together

2022-10-24T07:58:16+00:00

[ Upstream commit 65769162ae4b7f2d82e54998be446226b05fcd8f ] The code is ogranized in a way that all related parts to the certain platform quirk go together. This is not the case for AMD NAVI. Shuffle code to make it happen. While at it, drop the frequency definition and use hard coded value as it's done for other platforms and add a comment to the PCI ID list. Signed-off-by: Andy Shevchenko Acked-by: Jarkko Nikula Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin

i2c: mlxbf: support lock mechanism

2022-10-24T07:57:13+00:00

[ Upstream commit 86067ccfa1424a26491542d6f6d7546d40b61a10 ] Linux is not the only entity using the BlueField I2C busses so support a lock mechanism provided by hardware to avoid issues when multiple entities are trying to access the same bus. The lock is acquired whenever written explicitely or the lock register is read. So make sure it is always released at the end of a successful or failed transaction. Fixes: b5b5b32081cd206b (i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC) Reviewed-by: Khalil Blaiech Signed-off-by: Asmaa Mnebhi Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin

i2c: designware: Fix handling of real but unexpected device interrupts

2022-10-24T07:56:43+00:00

commit 301c8f5c32c8fb79c67539bc23972dc3ef48024c upstream. Commit c7b79a752871 ("mfd: intel-lpss: Add Intel Alder Lake PCH-S PCI IDs") caused a regression on certain Gigabyte motherboards for Intel Alder Lake-S where system crashes to NULL pointer dereference in i2c_dw_xfer_msg() when system resumes from S3 sleep state ("deep"). I was able to debug the issue on Gigabyte Z690 AORUS ELITE and made following notes: - Issue happens when resuming from S3 but not when resuming from "s2idle" - PCI device 00:15.0 == i2c_designware.0 is already in D0 state when system enters into pci_pm_resume_noirq() while all other i2c_designware PCI devices are in D3. Devices were runtime suspended and in D3 prior entering into suspend - Interrupt comes after pci_pm_resume_noirq() when device interrupts are re-enabled - According to register dump the interrupt really comes from the i2c_designware.0. Controller is enabled, I2C target address register points to a one detectable I2C device address 0x60 and the DW_IC_RAW_INTR_STAT register START_DET, STOP_DET, ACTIVITY and TX_EMPTY bits are set indicating completed I2C transaction. My guess is that the firmware uses this controller to communicate with an on-board I2C device during resume but does not disable the controller before giving control to an operating system. I was told the UEFI update fixes this but never the less it revealed the driver is not ready to handle TX_EMPTY (or RX_FULL) interrupt when device is supposed to be idle and state variables are not set (especially the dev->msgs pointer which may point to NULL or stale old data). Introduce a new software status flag STATUS_ACTIVE indicating when the controller is active in driver point of view. Now treat all interrupts that occur when is not set as unexpected and mask all interrupts from the controller. Fixes: c7b79a752871 ("mfd: intel-lpss: Add Intel Alder Lake PCH-S PCI IDs") Reported-by: Samuel Clark Link: https://bugzilla.kernel.org/show_bug.cgi?id=215907 Cc: stable@vger.kernel.org # v5.12+ Signed-off-by: Jarkko Nikula Reviewed-by: Andy Shevchenko Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman

i2c: davinci: fix PM disable depth imbalance in davinci_i2c_probe

2022-10-12T07:51:25+00:00

[ Upstream commit e2062df704dea47efe16edcaa2316d7b5ecca64f ] The pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it balanced according to context. Fixes: 17f88151ff190 ("i2c: davinci: Add PM Runtime Support") Signed-off-by: Zhang Qilong Reviewed-by: Bartosz Golaszewski Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin

i2c: mux: harden i2c_mux_alloc() against integer overflows

2022-09-28T09:32:26+00:00

[ Upstream commit b7af938f4379a884f15713319648a7653497a907 ] A couple years back we went through the kernel an automatically converted size calculations to use struct_size() instead. The struct_size() calculation is protected against integer overflows. However it does not make sense to use the result from struct_size() for additional math operations as that would negate any safeness. Fixes: 1f3b69b6b939 ("i2c: mux: Use struct_size() in devm_kzalloc()") Signed-off-by: Dan Carpenter Acked-by: Peter Rosin Reviewed-by: Gustavo A. R. Silva Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin

i2c: mlxbf: Fix frequency calculation

2022-09-28T09:32:26+00:00

[ Upstream commit 37f071ec327b04c83d47637c5e5c2199b39899ca ] The i2c-mlxbf.c driver is currently broken because there is a bug in the calculation of the frequency. core_f, core_r and core_od are components read from hardware registers and are used to compute the frequency used to compute different timing parameters. The shifting mechanism used to get core_f, core_r and core_od is wrong. Use FIELD_GET to mask and shift the bitfields properly. Fixes: b5b5b32081cd206b (i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC) Reviewed-by: Khalil Blaiech Signed-off-by: Asmaa Mnebhi Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin

i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction()

2022-09-28T09:32:26+00:00

[ Upstream commit de24aceb07d426b6f1c59f33889d6a964770547b ] memcpy() is called in a loop while 'operation->length' upper bound is not checked and 'data_idx' also increments. Fixes: b5b5b32081cd206b ("i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC") Reviewed-by: Khalil Blaiech Signed-off-by: Asmaa Mnebhi Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin

i2c: mlxbf: incorrect base address passed during io write

2022-09-28T09:32:26+00:00

[ Upstream commit 2a5be6d1340c0fefcee8a6489cff7fd88a0d5b85 ] Correct the base address used during io write. This bug had no impact over the overall functionality of the read and write transactions. MLXBF_I2C_CAUSE_OR_CLEAR=0x18 so writing to (smbus->io + 0x18) instead of (mst_cause->ioi + 0x18) actually writes to the sc_low_timeout register which just sets the timeout value before a read/write aborts. Fixes: b5b5b32081cd206b (i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC) Reviewed-by: Khalil Blaiech Signed-off-by: Asmaa Mnebhi Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin

i2c: imx: If pm_runtime_get_sync() returned 1 device access is possible

2022-09-28T09:32:26+00:00

[ Upstream commit 085aacaa73163f4b8a89dec24ecb32cfacd34017 ] pm_runtime_get_sync() returning 1 also means the device is powered. So resetting the chip registers in .remove() is possible and should be done. Reported-by: Dan Carpenter Fixes: d98bdd3a5b50 ("i2c: imx: Make sure to unregister adapter on remove()") Signed-off-by: Uwe Kleine-König Acked-by: Oleksij Rempel Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin

i2c: imx: Make sure to unregister adapter on remove()

2022-08-25T09:45:35+00:00

commit d98bdd3a5b50446d8e010be5b04ce81c4eabf728 upstream. If for whatever reasons pm_runtime_resume_and_get() fails and .remove() is exited early, the i2c adapter stays around and the irq still calls its handler, while the driver data and the register mapping go away. So if later the i2c adapter is accessed or the irq triggers this results in havoc accessing freed memory and unmapped registers. So unregister the software resources even if resume failed, and only skip the hardware access in that case. Fixes: 588eb93ea49f ("i2c: imx: add runtime pm support to improve the performance") Signed-off-by: Uwe Kleine-König Acked-by: Oleksij Rempel Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman