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

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

2019-09-06T08:23:46+00:00

commit c7c06a1532f3fe106687ac82a13492c6a619ff1c upstream.

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 
Signed-off-by: Greg Kroah-Hartman

i2c: emev2: avoid race when unregistering slave client

2019-09-06T08:23:25+00:00

[ Upstream commit d7437fc0d8291181debe032671a289b6bd93f46f ]

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 
Signed-off-by: Sasha Levin

i2c: rcar: avoid race when unregistering slave client

2019-09-06T08:23:24+00:00

[ Upstream commit 7b814d852af6944657c2961039f404c4490771c0 ]

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 
Signed-off-by: Sasha Levin

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

2019-08-25T14:10:24+00:00

commit e8c220fac415d9f4a994b0c2871b835feac1eb4e upstream.

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 
Signed-off-by: Greg Kroah-Hartman

i2c: at91: fix clk_offset for sama5d2

2019-08-06T17:08:17+00:00

commit b1ac6704493fa14b5dc19eb6b69a73932361a131 upstream.

In SAMA5D2 datasheet, TWIHS_CWGR register rescription mentions clock
offset of 3 cycles (compared to 4 in eg. SAMA5D3).

Cc: stable@vger.kernel.org # 5.2.x
[needs applying to i2c-at91.c instead for earlier kernels]
Fixes: 0ef6f3213dac ("i2c: at91: add support for new alternative command mode")
Signed-off-by: Michał Mirosław 
Acked-by: Ludovic Desroches 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: at91: disable TXRDY interrupt after sending data

2019-08-06T17:08:17+00:00

commit d12e3aae160fb26b534c4496b211d6e60a5179ed upstream.

Driver was not disabling TXRDY interrupt after last TX byte.
This caused interrupt storm until transfer timeouts for slow
or broken device on the bus. The patch fixes the interrupt storm
on my SAMA5D2-based board.

Cc: stable@vger.kernel.org # 5.2.x
[v5.2 introduced file split; the patch should apply to i2c-at91.c before the split]
Fixes: fac368a04048 ("i2c: at91: add new driver")
Signed-off-by: Michał Mirosław 
Acked-by: Ludovic Desroches 
Tested-by: Raag Jadav 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: iproc: Fix i2c master read more than 63 bytes

2019-08-06T17:08:16+00:00

commit fd01eecdf9591453177d7b06faaabef8c300114a upstream.

Use SMBUS_MASTER_DATA_READ.MASTER_RD_STATUS bit to check for RX
FIFO empty condition because SMBUS_MASTER_FIFO_CONTROL.MASTER_RX_PKT_COUNT
is not updated for read >= 64 bytes. This fixes the issue when trying to
read from the I2C slave more than 63 bytes.

Fixes: c24b8d574b7c ("i2c: iproc: Extend I2C read up to 255 bytes")
Cc: stable@kernel.org
Signed-off-by: Rayagonda Kokatanur 
Reviewed-by: Ray Jui 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: stm32f7: fix the get_irq error cases

2019-07-31T05:24:43+00:00

[ Upstream commit 79b4499524ed659fb76323efc30f3dc03967c88f ]

During probe, return the "get_irq" error value instead of -EINVAL which
allows the driver to be deferred probed if needed.
Fix also the case where of_irq_get() returns a negative value.
Note :
On failure of_irq_get() returns 0 or a negative value while
platform_get_irq() returns a negative value.

Fixes: aeb068c57214 ("i2c: i2c-stm32f7: add driver")
Reviewed-by: Pierre-Yves MORDRET 
Signed-off-by: Fabien Dessenne 
Signed-off-by: Fabrice Gasnier 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin

i2c: nvidia-gpu: resume ccgx i2c client

2019-07-31T05:24:37+00:00

[ Upstream commit 9f2e244d0a39eb437f98324ac315e605e48636db ]

Cypress USB Type-C CCGx controller firmware version 3.1.10
(which is being used in many NVIDIA GPU cards) has known issue of
not triggering interrupt when a USB device is hot plugged to runtime
resume the controller. If any GPU card gets latest kernel with runtime
pm support but does not get latest fixed firmware then also it should
continue to work and therefore a workaround is required to check for
any connector change event

The workaround is to request runtime resume of i2c client
which is UCSI Cypress CCGx driver. CCG driver will call the ISR
for any connector change event only if NVIDIA GPU has old
CCG firmware with the known issue.

Signed-off-by: Ajay Gupta 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

2019-06-19T15:09:55+00:00

Based on 2 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).

Signed-off-by: Thomas Gleixner 
Reviewed-by: Enrico Weigelt 
Reviewed-by: Kate Stewart 
Reviewed-by: Allison Randal 
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman