linux/drivers/i2c, branch v5.3

i2c: mediatek: disable zero-length transfers for mt8183

2019-08-30T13:06:17Z

Quoting from mt8183 datasheet, the number of transfers to be transferred in one transaction should be set to bigger than 1, so we should forbid zero-length transfer and update functionality. Reported-by: Alexandru M Stan Signed-off-by: Hsin-Yi Wang Reviewed-by: Qii Wang [wsa: shortened commit message a little] Signed-off-by: Wolfram Sang

i2c: iproc: Stop advertising support of SMBUS quick cmd

2019-08-30T12:58:18Z

The driver does not support the SMBUS Quick command so remove the flag that indicates that level of support. By default the i2c_detect tool uses the quick command to try and detect devices at some bus addresses. If the quick command is used then we will not detect the device, even though it is present. Fixes: e6e5dd3566e0 (i2c: iproc: Add Broadcom iProc I2C Driver) Signed-off-by: Lori Hikichi Signed-off-by: Rayagonda Kokatanur Reviewed-by: Ray Jui Signed-off-by: Wolfram Sang

i2c: piix4: Fix port selection for AMD Family 16h Model 30h

2019-08-29T20:17:04Z

Family 16h Model 30h SMBus controller needs the same port selection fix as described and fixed in commit 0fe16195f891 ("i2c: piix4: Fix SMBus port selection for AMD Family 17h chips") commit 6befa3fde65f ("i2c: piix4: Support alternative port selection register") also fixed the port selection for Hudson2, but unfortunately this is not the exact same device and the AMD naming and PCI Device IDs aren't particularly helpful here. The SMBus port selection register is common to the following Families and models, as documented in AMD's publicly available BIOS and Kernel Developer Guides: 50742 - Family 15h Model 60h-6Fh (PCI_DEVICE_ID_AMD_KERNCZ_SMBUS) 55072 - Family 15h Model 70h-7Fh (PCI_DEVICE_ID_AMD_KERNCZ_SMBUS) 52740 - Family 16h Model 30h-3Fh (PCI_DEVICE_ID_AMD_HUDSON2_SMBUS) The Hudson2 PCI Device ID (PCI_DEVICE_ID_AMD_HUDSON2_SMBUS) is shared between Bolton FCH and Family 16h Model 30h, but the location of the SmBus0Sel port selection bits are different: 51192 - Bolton Register Reference Guide We distinguish between Bolton and Family 16h Model 30h using the PCI Revision ID: Bolton is device 0x780b, revision 0x15 Family 16h Model 30h is device 0x780b, revision 0x1F Family 15h Model 60h and 70h are both device 0x790b, revision 0x4A. The following additional public AMD BKDG documents were checked and do not share the same port selection register: 42301 - Family 15h Model 00h-0Fh doesn't mention any 42300 - Family 15h Model 10h-1Fh doesn't mention any 49125 - Family 15h Model 30h-3Fh doesn't mention any 48751 - Family 16h Model 00h-0Fh uses the previously supported index register SB800_PIIX4_PORT_IDX_ALT at 0x2e Signed-off-by: Andrew Cooks Signed-off-by: Jean Delvare Cc: stable@vger.kernel.org [v4.6+] Signed-off-by: Wolfram Sang

i2c: designware: Synchronize IRQs when unregistering slave client

2019-08-29T18:47:42Z

Make sure interrupt handler i2c_dw_irq_handler_slave() has finished before clearing the the dev->slave pointer in i2c_dw_unreg_slave(). There is possibility for a race if i2c_dw_irq_handler_slave() is running on another CPU while clearing the dev->slave pointer. Reported-by: Krzysztof Adamski Reported-by: Wolfram Sang Signed-off-by: Jarkko Nikula Signed-off-by: Wolfram Sang

i2c: i801: Avoid memory leak in check_acpi_smo88xx_device()

2019-08-29T18:46:48Z

check_acpi_smo88xx_device() utilizes acpi_get_object_info() which in its turn allocates a buffer. User is responsible to clean allocated resources. The last has been missed in the original code. Fix it here. While here, replace !ACPI_SUCCESS() with ACPI_FAILURE(). Fixes: 19b07cb4a187 ("i2c: i801: Register optional lis3lv02d I2C device on Dell machines") Signed-off-by: Andy Shevchenko Reviewed-by: Pali Rohár Reviewed-by: Jean Delvare Signed-off-by: Wolfram Sang

i2c: make i2c_unregister_device() ERR_PTR safe

2019-08-29T18:38:11Z

We are moving towards returning ERR_PTRs when i2c_new_*_device() calls fail. Make sure its counterpart for unregistering handles ERR_PTRs as well. Signed-off-by: Wolfram Sang Reviewed-by: Geert Uytterhoeven Signed-off-by: Wolfram Sang

i2c: stm32: Use the correct style for SPDX License Identifier

2019-08-14T12:56:54Z

This patch corrects the SPDX License Identifier style in header file related to STM32 Driver for I2C hardware bus support. For C header files Documentation/process/license-rules.rst mandates C-like comments (opposed to C source files where C++ style should be used) Changes made by using a script provided by Joe Perches here: https://lkml.org/lkml/2019/2/7/46 Suggested-by: Joe Perches Signed-off-by: Nishad Kamdar Signed-off-by: Wolfram Sang

i2c: emev2: avoid race when unregistering slave client

2019-08-14T12:49:43Z

After we disabled interrupts, there might still be an active one running. Sync before clearing the pointer to the slave device. Fixes: c31d0a00021d ("i2c: emev2: add slave support") Reported-by: Krzysztof Adamski Signed-off-by: Wolfram Sang Reviewed-by: Krzysztof Adamski Signed-off-by: Wolfram Sang

i2c: rcar: avoid race when unregistering slave client

2019-08-14T12:49:36Z

After we disabled interrupts, there might still be an active one running. Sync before clearing the pointer to the slave device. Fixes: de20d1857dd6 ("i2c: rcar: add slave support") Reported-by: Krzysztof Adamski Signed-off-by: Wolfram Sang Reviewed-by: Krzysztof Adamski Signed-off-by: Wolfram Sang

Revert "i2c: imx: improve the error handling in i2c_imx_dma_request()"

2019-08-14T09:53:00Z

Since commit e1ab9a468e3b ("i2c: imx: improve the error handling in i2c_imx_dma_request()") when booting with the DMA driver as module (such as CONFIG_FSL_EDMA=m) the following endless clk warnings are seen: [ 153.077831] ------------[ cut here ]------------ [ 153.082528] WARNING: CPU: 0 PID: 15 at drivers/clk/clk.c:924 clk_core_disable_lock+0x18/0x24 [ 153.093077] i2c0 already disabled [ 153.096416] Modules linked in: [ 153.099521] CPU: 0 PID: 15 Comm: kworker/0:1 Tainted: G W 5.2.0+ #321 [ 153.107290] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree) [ 153.113772] Workqueue: events deferred_probe_work_func [ 153.118979] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 153.126778] [] (show_stack) from [] (dump_stack+0x9c/0xd4) [ 153.134051] [] (dump_stack) from [] (__warn+0xf8/0x124) [ 153.141056] [] (__warn) from [] (warn_slowpath_fmt+0x38/0x48) [ 153.148580] [] (warn_slowpath_fmt) from [] (clk_core_disable_lock+0x18/0x24) [ 153.157413] [] (clk_core_disable_lock) from [] (i2c_imx_probe+0x554/0x6ec) [ 153.166076] [] (i2c_imx_probe) from [] (platform_drv_probe+0x48/0x98) [ 153.174297] [] (platform_drv_probe) from [] (really_probe+0x1d8/0x2c0) [ 153.182605] [] (really_probe) from [] (driver_probe_device+0x5c/0x174) [ 153.190909] [] (driver_probe_device) from [] (bus_for_each_drv+0x44/0x8c) [ 153.199480] [] (bus_for_each_drv) from [] (__device_attach+0xa0/0x108) [ 153.207782] [] (__device_attach) from [] (bus_probe_device+0x88/0x90) [ 153.215999] [] (bus_probe_device) from [] (deferred_probe_work_func+0x60/0x90) [ 153.225003] [] (deferred_probe_work_func) from [] (process_one_work+0x204/0x634) [ 153.234178] [] (process_one_work) from [] (worker_thread+0x20/0x484) [ 153.242315] [] (worker_thread) from [] (kthread+0x118/0x150) [ 153.249758] [] (kthread) from [] (ret_from_fork+0x14/0x20) [ 153.257006] Exception stack(0xdde43fb0 to 0xdde43ff8) [ 153.262095] 3fa0: 00000000 00000000 00000000 00000000 [ 153.270306] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 153.278520] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 153.285159] irq event stamp: 3323022 [ 153.288787] hardirqs last enabled at (3323021): [] _raw_spin_unlock_irq+0x24/0x2c [ 153.297261] hardirqs last disabled at (3323022): [] clk_enable_lock+0x10/0x124 [ 153.305392] softirqs last enabled at (3322092): [] __do_softirq+0x344/0x540 [ 153.313352] softirqs last disabled at (3322081): [] irq_exit+0x10c/0x128 [ 153.320946] ---[ end trace a506731ccd9bd703 ]--- This endless clk warnings behaviour is well explained by Andrey Smirnov: "Allocating DMA after registering I2C adapter can lead to infinite probing loop, for example, consider the following scenario: 1. i2c_imx_probe() is called and successfully registers an I2C adapter via i2c_add_numbered_adapter() 2. As a part of i2c_add_numbered_adapter() new I2C slave devices are added from DT which results in a call to driver_deferred_probe_trigger() 3. i2c_imx_probe() continues and calls i2c_imx_dma_request() which due to lack of proper DMA driver returns -EPROBE_DEFER 4. i2c_imx_probe() fails, removes I2C adapter and returns -EPROBE_DEFER, which places it into deferred probe list 5. Deferred probe work triggered in #2 above kicks in and calls i2c_imx_probe() again thus bringing us to step #1" So revert commit e1ab9a468e3b ("i2c: imx: improve the error handling in i2c_imx_dma_request()") and restore the old behaviour, in order to avoid regressions on existing setups. Cc: Reported-by: Andrey Smirnov Reported-by: Russell King Fixes: e1ab9a468e3b ("i2c: imx: improve the error handling in i2c_imx_dma_request()") Signed-off-by: Fabio Estevam Signed-off-by: Wolfram Sang