user/sven/linux.git/drivers/i2c, branch v5.4.3

i2c: core: fix use after free in of_i2c_notify

2019-11-15T21:01:13Z

We can't use "adap->dev" after it has been freed. Fixes: 5bf4fa7daea6 ("i2c: break out OF support into separate file") Signed-off-by: Wen Yang Signed-off-by: Wolfram Sang

i2c: acpi: Force bus speed to 400KHz if a Silead touchscreen is present

2019-11-15T20:55:14Z

Many cheap devices use Silead touchscreen controllers. Testing has shown repeatedly that these touchscreen controllers work fine at 400KHz, but for unknown reasons do not work properly at 100KHz. This has been seen on both ARM and x86 devices using totally different i2c controllers. On some devices the ACPI tables list another device at the same I2C-bus as only being capable of 100KHz, testing has shown that these other devices work fine at 400KHz (as can be expected of any recent I2C hw). This commit makes i2c_acpi_find_bus_speed() always return 400KHz if a Silead touchscreen controller is present, fixing the touchscreen not working on devices which ACPI tables' wrongly list another device on the same bus as only being capable of 100KHz. Specifically this fixes the touchscreen on the Jumper EZpad 6 m4 not working. Reported-by: youling 257 Tested-by: youling 257 Signed-off-by: Hans de Goede Reviewed-by: Jarkko Nikula Acked-by: Mika Westerberg [wsa: rewording warning a little] Signed-off-by: Wolfram Sang Cc: stable@kernel.org

i2c: stm32f7: remove warning when compiling with W=1

2019-10-24T18:52:21Z

Remove the following warning: drivers/i2c/busses/i2c-stm32f7.c:315: warning: cannot understand function prototype: 'struct stm32f7_i2c_spec i2c_specs[] = Replace a comment starting with /** by simply /* to avoid having it interpreted as a kernel-doc comment. Fixes: aeb068c57214 ("i2c: i2c-stm32f7: add driver") Signed-off-by: Alain Volmat Reviewed-by: Pierre-Yves MORDRET Signed-off-by: Wolfram Sang

i2c: stm32f7: fix a race in slave mode with arbitration loss irq

2019-10-24T18:52:17Z

When in slave mode, an arbitration loss (ARLO) may be detected before the slave had a chance to detect the stop condition (STOPF in ISR). This is seen when two master + slave adapters switch their roles. It provokes the i2c bus to be stuck, busy as SCL line is stretched. - the I2C_SLAVE_STOP event is never generated due to STOPF flag is set but don't generate an irq (race with ARLO irq, STOPIE is masked). STOPF flag remains set until next master xfer (e.g. when STOPIE irq get unmasked). In this case, completion is generated too early: immediately upon new transfer request (then it doesn't send all data). - Some data get stuck in TXDR register. As a consequence, the controller stretches the SCL line: the bus gets busy until a future master transfer triggers the bus busy / recovery mechanism (this can take time... and may never happen at all) So choice is to let the STOPF being detected by the slave isr handler, to properly handle this stop condition. E.g. don't mask IRQs in error handler, when the slave is running. Fixes: 60d609f30de2 ("i2c: i2c-stm32f7: Add slave support") Signed-off-by: Fabrice Gasnier Reviewed-by: Pierre-Yves MORDRET Signed-off-by: Wolfram Sang

i2c: stm32f7: fix first byte to send in slave mode

2019-10-24T18:52:17Z

The slave-interface documentation [1] states "the bus driver should transmit the first byte" upon I2C_SLAVE_READ_REQUESTED slave event: - 'val': backend returns first byte to be sent The driver currently ignores the 1st byte to send on this event. [1] https://www.kernel.org/doc/Documentation/i2c/slave-interface Fixes: 60d609f30de2 ("i2c: i2c-stm32f7: Add slave support") Signed-off-by: Fabrice Gasnier Reviewed-by: Pierre-Yves MORDRET Signed-off-by: Wolfram Sang

i2c: mt65xx: fix NULL ptr dereference

2019-10-24T18:52:11Z

Since commit abf4923e97c3 ("i2c: mediatek: disable zero-length transfers for mt8183"), there is a NULL pointer dereference for all the SoCs that don't have any quirk. mtk_i2c_functionality is not checking that the quirks pointer is not NULL before starting to use it. This commit add a call to i2c_check_quirks which will check whether the quirks pointer is set, and if so will check if the IP has the NO_ZERO_LEN quirk. Fixes: abf4923e97c3 ("i2c: mediatek: disable zero-length transfers for mt8183") Signed-off-by: Fabien Parent Reviewed-by: Cengiz Can Reviewed-by: Hsin-Yi Wang Tested-by: Ulrich Hecht Signed-off-by: Wolfram Sang

i2c: aspeed: fix master pending state handling

2019-10-21T12:09:10Z

In case of master pending state, it should not trigger a master command, otherwise data could be corrupted because this H/W shares the same data buffer for slave and master operations. It also means that H/W command queue handling is unreliable because of the buffer sharing issue. To fix this issue, it clears command queue if a master command is queued in pending state to use S/W solution instead of H/W command queue handling. Also, it refines restarting mechanism of the pending master command. Fixes: 2e57b7cebb98 ("i2c: aspeed: Add multi-master use case support") Signed-off-by: Jae Hyun Yoo Reviewed-by: Brendan Higgins Acked-by: Joel Stanley Tested-by: Tao Ren Signed-off-by: Wolfram Sang

i2c: slave-eeprom: Add read only mode

2019-09-28T18:44:12Z

Add read-only versions of all EEPROMs. These versions are read-only on the i2c side, but can be written from the sysfs side. Signed-off-by: Björn Ardö Signed-off-by: Wolfram Sang

i2c: i801: Bring back Block Process Call support for certain platforms

2019-09-28T18:44:12Z

Commit b84398d6d7f9 ("i2c: i801: Use iTCO version 6 in Cannon Lake PCH and beyond") looks like to drop by accident Block Write-Block Read Process Call support for Intel Sunrisepoint, Lewisburg, Denverton and Kaby Lake. That support was added for above and newer platforms by the commit 315cd67c9453 ("i2c: i801: Add Block Write-Block Read Process Call support") so bring it back for above platforms. Fixes: b84398d6d7f9 ("i2c: i801: Use iTCO version 6 in Cannon Lake PCH and beyond") Signed-off-by: Jarkko Nikula Reviewed-by: Alexander Sverdlin Signed-off-by: Wolfram Sang

i2c: riic: Clear NACK in tend isr

2019-09-28T18:44:12Z

The NACKF flag should be cleared in INTRIICNAKI interrupt processing as description in HW manual. This issue shows up quickly when PREEMPT_RT is applied and a device is probed that is not plugged in (like a touchscreen controller). The result is endless interrupts that halt system boot. Fixes: 310c18a41450 ("i2c: riic: add driver") Cc: stable@vger.kernel.org Reported-by: Chien Nguyen Signed-off-by: Chris Brandt Signed-off-by: Wolfram Sang