linux-stable.git/drivers/i2c, branch v5.4.282

i2c: smbus: Send alert notifications to all devices if source not found

2024-08-19T03:33:50+00:00

[ Upstream commit f6c29f710c1ff2590109f83be3e212b86c01e0f3 ]

If a SMBus alert is received and the originating device is not found,
the reason may be that the address reported on the SMBus alert address
is corrupted, for example because multiple devices asserted alert and
do not correctly implement SMBus arbitration.

If this happens, call alert handlers on all devices connected to the
given I2C bus, in the hope that this cleans up the situation.

This change reliably fixed the problem on a system with multiple devices
on a single bus. Example log where the device on address 0x18 (ADM1021)
and on address 0x4c (ADT7461A) both had the alert line asserted:

smbus_alert 3-000c: SMBALERT# from dev 0x0c, flag 0
smbus_alert 3-000c: no driver alert()!
smbus_alert 3-000c: SMBALERT# from dev 0x0c, flag 0
smbus_alert 3-000c: no driver alert()!
lm90 3-0018: temp1 out of range, please check!
lm90 3-0018: Disabling ALERT#
lm90 3-0029: Everything OK
lm90 3-002a: Everything OK
lm90 3-004c: temp1 out of range, please check!
lm90 3-004c: temp2 out of range, please check!
lm90 3-004c: Disabling ALERT#

Fixes: b5527a7766f0 ("i2c: Add SMBus alert support")
Signed-off-by: Guenter Roeck 
[wsa: fixed a typo in the commit message]
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin

i2c: smbus: Improve handling of stuck alerts

2024-08-19T03:33:50+00:00

[ Upstream commit 37c526f00bc1c4f847fc800085f8f009d2e11be6 ]

The following messages were observed while testing alert functionality
on systems with multiple I2C devices on a single bus if alert was active
on more than one chip.

smbus_alert 3-000c: SMBALERT# from dev 0x0c, flag 0
smbus_alert 3-000c: no driver alert()!

and:

smbus_alert 3-000c: SMBALERT# from dev 0x28, flag 0

Once it starts, this message repeats forever at high rate. There is no
device at any of the reported addresses.

Analysis shows that this is seen if multiple devices have the alert pin
active. Apparently some devices do not support SMBus arbitration correctly.
They keep sending address bits after detecting an address collision and
handle the collision not at all or too late.
Specifically, address 0x0c is seen with ADT7461A at address 0x4c and
ADM1021 at address 0x18 if alert is active on both chips. Address 0x28 is
seen with ADT7483 at address 0x2a and ADT7461 at address 0x4c if alert is
active on both chips.

Once the system is in bad state (alert is set by more than one chip),
it often only recovers by power cycling.

To reduce the impact of this problem, abort the endless loop in
smbus_alert() if the same address is read more than once and not
handled by a driver.

Fixes: b5527a7766f0 ("i2c: Add SMBus alert support")
Signed-off-by: Guenter Roeck 
[wsa: it also fixed an interrupt storm in one of my experiments]
Tested-by: Wolfram Sang 
[wsa: rebased, moved a comment as well, improved the 'invalid' value]
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin

i2c: smbus: Don't filter out duplicate alerts

2024-08-19T03:33:50+00:00

[ Upstream commit dca0dd28fa5e0a1ec41a623dbaf667601fc62331 ]

Getting the same alert twice in a row is legal and normal,
especially on a fast device (like running in qemu).  Kind of
like interrupts.  So don't report duplicate alerts, and deliver
them normally.

[JD: Fixed subject]

Signed-off-by: Corey Minyard 
Signed-off-by: Jean Delvare 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Wolfram Sang 
Stable-dep-of: 37c526f00bc1 ("i2c: smbus: Improve handling of stuck alerts")
Signed-off-by: Sasha Levin

i2c: rcar: bring hardware to known state when probing

2024-07-18T09:40:56+00:00

[ Upstream commit 4e36c0f20cb1c74c7bd7ea31ba432c1c4a989031 ]

When probing, the hardware is not brought into a known state. This may
be a problem when a hypervisor restarts Linux without resetting the
hardware, leaving an old state running. Make sure the hardware gets
initialized, especially interrupts should be cleared and disabled.

Reported-by: Dirk Behme 
Reported-by: Geert Uytterhoeven 
Closes: https://lore.kernel.org/r/20240702045535.2000393-1-dirk.behme@de.bosch.com
Fixes: 6ccbe607132b ("i2c: add Renesas R-Car I2C driver")
Signed-off-by: Wolfram Sang 
Signed-off-by: Andi Shyti 
Signed-off-by: Sasha Levin

i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr

2024-07-18T09:40:52+00:00

[ Upstream commit f63b94be6942ba82c55343e196bd09b53227618e ]

When del_timer_sync() is called in an interrupt context it throws a warning
because of potential deadlock. The timer is used only to exit from
wait_for_completion() after a timeout so replacing the call with
wait_for_completion_timeout() allows to remove the problematic timer and
its related functions altogether.

Fixes: 41561f28e76a ("i2c: New Philips PNX bus driver")
Signed-off-by: Piotr Wojtaszczyk 
Signed-off-by: Andi Shyti 
Signed-off-by: Sasha Levin

i2c: i801: Annotate apanel_addr as __ro_after_init

2024-07-18T09:40:49+00:00

[ Upstream commit 355b1513b1e97b6cef84b786c6480325dfd3753d ]

Annotate this variable as __ro_after_init to protect it from being
overwritten later.

Signed-off-by: Heiner Kallweit 
Signed-off-by: Andi Shyti 
Signed-off-by: Sasha Levin

i2c: ocores: set IACK bit after core is enabled

2024-07-05T07:08:24+00:00

commit 5a72477273066b5b357801ab2d315ef14949d402 upstream.

Setting IACK bit when core is disabled does not clear the "Interrupt Flag"
bit in the status register, and the interrupt remains pending.

Sometimes it causes failure for the very first message transfer, that is
usually a device probe.

Hence, set IACK bit after core is enabled to clear pending interrupt.

Fixes: 18f98b1e3147 ("[PATCH] i2c: New bus driver for the OpenCores I2C controller")
Signed-off-by: Grygorii Tertychnyi 
Acked-by: Peter Korsgaard 
Cc: stable@vger.kernel.org
Signed-off-by: Andi Shyti 
Signed-off-by: Greg Kroah-Hartman

i2c: at91: Fix the functionality flags of the slave-only interface

2024-07-05T07:08:20+00:00

[ Upstream commit d6d5645e5fc1233a7ba950de4a72981c394a2557 ]

When an I2C adapter acts only as a slave, it should not claim to
support I2C master capabilities.

Fixes: 9d3ca54b550c ("i2c: at91: added slave mode support")
Signed-off-by: Jean Delvare 
Cc: Juergen Fitschen 
Cc: Ludovic Desroches 
Cc: Codrin Ciubotariu 
Cc: Andi Shyti 
Cc: Nicolas Ferre 
Cc: Alexandre Belloni 
Cc: Claudiu Beznea 
Signed-off-by: Andi Shyti 
Signed-off-by: Sasha Levin

i2c: smbus: fix NULL function pointer dereference

2024-05-02T14:18:37+00:00

[ Upstream commit 91811a31b68d3765b3065f4bb6d7d6d84a7cfc9f ]

Baruch reported an OOPS when using the designware controller as target
only. Target-only modes break the assumption of one transfer function
always being available. Fix this by always checking the pointer in
__i2c_transfer.

Reported-by: Baruch Siach 
Closes: https://lore.kernel.org/r/4269631780e5ba789cf1ae391eec1b959def7d99.1712761976.git.baruch@tkos.co.il
Fixes: 4b1acc43331d ("i2c: core changes for slave support")
[wsa: dropped the simplification in core-smbus to avoid theoretical regressions]
Signed-off-by: Wolfram Sang 
Tested-by: Baruch Siach 
Signed-off-by: Sasha Levin

i2c: i801: Fix block process call transactions

2024-02-23T07:25:10+00:00

[ Upstream commit c1c9d0f6f7f1dbf29db996bd8e166242843a5f21 ]

According to the Intel datasheets, software must reset the block
buffer index twice for block process call transactions: once before
writing the outgoing data to the buffer, and once again before
reading the incoming data from the buffer.

The driver is currently missing the second reset, causing the wrong
portion of the block buffer to be read.

Signed-off-by: Jean Delvare 
Reported-by: Piotr Zakowski 
Closes: https://lore.kernel.org/linux-i2c/20240213120553.7b0ab120@endymion.delvare/
Fixes: 315cd67c9453 ("i2c: i801: Add Block Write-Block Read Process Call support")
Reviewed-by: Alexander Sverdlin 
Signed-off-by: Andi Shyti 
Signed-off-by: Sasha Levin