linux-stable.git/drivers/i2c, branch v6.0.7

i2c: qcom-cci: Fix ordering of pm_runtime_xx and i2c_add_adapter

2022-10-29T08:08:29+00:00

commit 61775d54d674ff8ec3658495e0dbc537227dc5c1 upstream.

When we compile-in the CCI along with the imx412 driver and run on the RB5
we see that i2c_add_adapter() causes the probe of the imx412 driver to
happen.

This probe tries to perform an i2c xfer() and the xfer() in i2c-qcom-cci.c
fails on pm_runtime_get() because the i2c-qcom-cci.c::probe() function has
not completed to pm_runtime_enable(dev).

Fix this sequence by ensuring pm_runtime_xxx() calls happen prior to adding
the i2c adapter.

Fixes: e517526195de ("i2c: Add Qualcomm CCI I2C driver")
Reported-by: Vladimir Zapolskiy 
Reviewed-by: Vladimir Zapolskiy 
Tested-by: Vladimir Zapolskiy 
Cc: 
Signed-off-by: Bryan O'Donoghue 
Reviewed-by: Robert Foss 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

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

2022-10-21T10:39:11+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-21T10:38:17+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-21T10:37:36+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-01T22:46:42+00:00

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

i2c: mux: harden i2c_mux_alloc() against integer overflows

2022-09-21T20:12:06+00:00

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

i2c: mlxbf: Fix frequency calculation

2022-09-21T19:43:19+00:00

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

i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction()

2022-09-17T18:13:57+00:00

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

i2c: mlxbf: incorrect base address passed during io write

2022-09-17T18:11:21+00:00

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

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

2022-09-16T19:37:50+00:00

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