kernel/linux.git/drivers/i2c, branch v6.6.39

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

2024-07-11T10:49:19+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-11T10:49:08+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: testunit: discard write requests while old command is running

2024-07-05T07:33:56+00:00

[ Upstream commit c116deafd1a5cc1e9739099eb32114e90623209c ] When clearing registers on new write requests was added, the protection for currently running commands was missed leading to concurrent access to the testunit registers. Check the flag beforehand. Fixes: b39ab96aa894 ("i2c: testunit: add support for block process calls") Signed-off-by: Wolfram Sang Reviewed-by: Andi Shyti Signed-off-by: Sasha Levin

i2c: testunit: don't erase registers after STOP

2024-07-05T07:33:56+00:00

[ Upstream commit c422b6a630240f706063e0ecbb894aa8491b1fa1 ] STOP fallsthrough to WRITE_REQUESTED but this became problematic when clearing the testunit registers was added to the latter. Actually, there is no reason to clear the testunit state after STOP. Doing it when a new WRITE_REQUESTED arrives is enough. So, no need to fallthrough, at all. Fixes: b39ab96aa894 ("i2c: testunit: add support for block process calls") Signed-off-by: Wolfram Sang Reviewed-by: Andi Shyti Signed-off-by: Sasha Levin

i2c: ocores: set IACK bit after core is enabled

2024-06-27T11:49:13+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: designware: Fix the functionality flags of the slave-only interface

2024-06-21T12:38:50+00:00

[ Upstream commit cbf3fb5b29e99e3689d63a88c3cddbffa1b8de99 ] When an I2C adapter acts only as a slave, it should not claim to support I2C master capabilities. Fixes: 5b6d721b266a ("i2c: designware: enable SLAVE in platform module") Signed-off-by: Jean Delvare Cc: Luis Oliveira Cc: Jarkko Nikula Cc: Andy Shevchenko Cc: Mika Westerberg Cc: Jan Dabros Cc: Andi Shyti Reviewed-by: Andy Shevchenko Acked-by: Jarkko Nikula Tested-by: Jarkko Nikula Signed-off-by: Andi Shyti Signed-off-by: Sasha Levin

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

2024-06-21T12:38:50+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: acpi: Unbind mux adapters before delete

2024-06-16T11:47:40+00:00

commit 3f858bbf04dbac934ac279aaee05d49eb9910051 upstream. There is an issue with ACPI overlay table removal specifically related to I2C multiplexers. Consider an ACPI SSDT Overlay that defines a PCA9548 I2C mux on an existing I2C bus. When this table is loaded we see the creation of a device for the overall PCA9548 chip and 8 further devices - one i2c_adapter each for the mux channels. These are all bound to their ACPI equivalents via an eventual invocation of acpi_bind_one(). When we unload the SSDT overlay we run into the problem. The ACPI devices are deleted as normal via acpi_device_del_work_fn() and the acpi_device_del_list. However, the following warning and stack trace is output as the deletion does not go smoothly: ------------[ cut here ]------------ kernfs: can not remove 'physical_node', no directory WARNING: CPU: 1 PID: 11 at fs/kernfs/dir.c:1674 kernfs_remove_by_name_ns+0xb9/0xc0 Modules linked in: CPU: 1 PID: 11 Comm: kworker/u128:0 Not tainted 6.8.0-rc6+ #1 Hardware name: congatec AG conga-B7E3/conga-B7E3, BIOS 5.13 05/16/2023 Workqueue: kacpi_hotplug acpi_device_del_work_fn RIP: 0010:kernfs_remove_by_name_ns+0xb9/0xc0 Code: e4 00 48 89 ef e8 07 71 db ff 5b b8 fe ff ff ff 5d 41 5c 41 5d e9 a7 55 e4 00 0f 0b eb a6 48 c7 c7 f0 38 0d 9d e8 97 0a d5 ff <0f> 0b eb dc 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffff9f864008fb28 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff8ef90a8d4940 RCX: 0000000000000000 RDX: ffff8f000e267d10 RSI: ffff8f000e25c780 RDI: ffff8f000e25c780 RBP: ffff8ef9186f9870 R08: 0000000000013ffb R09: 00000000ffffbfff R10: 00000000ffffbfff R11: ffff8f000e0a0000 R12: ffff9f864008fb50 R13: ffff8ef90c93dd60 R14: ffff8ef9010d0958 R15: ffff8ef9186f98c8 FS: 0000000000000000(0000) GS:ffff8f000e240000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f48f5253a08 CR3: 00000003cb82e000 CR4: 00000000003506f0 Call Trace: ? kernfs_remove_by_name_ns+0xb9/0xc0 ? __warn+0x7c/0x130 ? kernfs_remove_by_name_ns+0xb9/0xc0 ? report_bug+0x171/0x1a0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? kernfs_remove_by_name_ns+0xb9/0xc0 ? kernfs_remove_by_name_ns+0xb9/0xc0 acpi_unbind_one+0x108/0x180 device_del+0x18b/0x490 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f device_unregister+0xd/0x30 i2c_del_adapter.part.0+0x1bf/0x250 i2c_mux_del_adapters+0xa1/0xe0 i2c_device_remove+0x1e/0x80 device_release_driver_internal+0x19a/0x200 bus_remove_device+0xbf/0x100 device_del+0x157/0x490 ? __pfx_device_match_fwnode+0x10/0x10 ? srso_return_thunk+0x5/0x5f device_unregister+0xd/0x30 i2c_acpi_notify+0x10f/0x140 notifier_call_chain+0x58/0xd0 blocking_notifier_call_chain+0x3a/0x60 acpi_device_del_work_fn+0x85/0x1d0 process_one_work+0x134/0x2f0 worker_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 ---[ end trace 0000000000000000 ]--- ... repeated 7 more times, 1 for each channel of the mux ... The issue is that the binding of the ACPI devices to their peer I2C adapters is not correctly cleaned up. Digging deeper into the issue we see that the deletion order is such that the ACPI devices matching the mux channel i2c adapters are deleted first during the SSDT overlay removal. For each of the channels we see a call to i2c_acpi_notify() with ACPI_RECONFIG_DEVICE_REMOVE but, because these devices are not actually i2c_clients, nothing is done for them. Later on, after each of the mux channels has been dealt with, we come to delete the i2c_client representing the PCA9548 device. This is the call stack we see above, whereby the kernel cleans up the i2c_client including destruction of the mux and its channel adapters. At this point we do attempt to unbind from the ACPI peers but those peers no longer exist and so we hit the kernfs errors. The fix is to augment i2c_acpi_notify() to handle i2c_adapters. But, given that the life cycle of the adapters is linked to the i2c_client, instead of deleting the i2c_adapters during the i2c_acpi_notify(), we just trigger unbinding of the ACPI device from the adapter device, and allow the clean up of the adapter to continue in the way it always has. Signed-off-by: Hamish Martin Reviewed-by: Mika Westerberg Reviewed-by: Andi Shyti Fixes: 525e6fabeae2 ("i2c / ACPI: add support for ACPI reconfigure notifications") Cc: # v4.8+ Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman

i2c: synquacer: Fix an error handling path in synquacer_i2c_probe()

2024-06-12T09:12:26+00:00

[ Upstream commit 55750148e5595bb85605e8fbb40b2759c2c4c2d7 ] If an error occurs after the clk_prepare_enable() call, it should be undone by a corresponding clk_disable_unprepare() call, as already done in the remove() function. As devm_clk_get() is used, we can switch to devm_clk_get_enabled() to handle it automatically and fix the probe. Update the remove() function accordingly and remove the now useless clk_disable_unprepare() call. Fixes: 0d676a6c4390 ("i2c: add support for Socionext SynQuacer I2C controller") Signed-off-by: Christophe JAILLET Acked-by: Ard Biesheuvel Signed-off-by: Andi Shyti Signed-off-by: Sasha Levin

i2c: cadence: Avoid fifo clear after start

2024-06-12T09:12:26+00:00

[ Upstream commit c2e55b449de7298a751ed0256251019d302af453 ] The Driver unintentionally programs ctrl reg to clear the fifo, which happens after the start of transaction. Previously, this was not an issue as it involved read-modified-write. However, this issue breaks i2c reads on QEMU, as i2c-read is executed before guest starts programming control register. Fixes: ff0cf7bca630 ("i2c: cadence: Remove unnecessary register reads") Signed-off-by: Sai Pavan Boddu Acked-by: Michal Simek Signed-off-by: Andi Shyti Signed-off-by: Sasha Levin