linux.git/drivers/i2c, branch v5.7-rc6

i2c: aspeed: Avoid i2c interrupt status clear race condition.

2020-04-30T14:12:33+00:00

In AST2600 there have a slow peripheral bus between CPU and i2c
controller. Therefore GIC i2c interrupt status clear have delay timing,
when CPU issue write clear i2c controller interrupt status. To avoid
this issue, the driver need have read after write clear at i2c ISR.

Fixes: f327c686d3ba ("i2c: aspeed: added driver for Aspeed I2C")
Signed-off-by: ryan_chen 
Acked-by: Benjamin Herrenschmidt 
[wsa: added Fixes tag]
Signed-off-by: Wolfram Sang

i2c: amd-mp2-pci: Fix Oops in amd_mp2_pci_init() error handling

2020-04-30T14:11:41+00:00

The problem is that we dereference "privdata->pci_dev" when we print
the error messages in amd_mp2_pci_init():

	dev_err(ndev_dev(privdata), "Failed to enable MP2 PCI device\n");
		^^^^^^^^^^^^^^^^^

Fixes: 529766e0a011 ("i2c: Add drivers for the AMD PCIe MP2 I2C controller")
Signed-off-by: Dan Carpenter 
Signed-off-by: Wolfram Sang 
Cc: stable@kernel.org

Revert "i2c: tegra: Better handle case where CPU0 is busy for a long time"

2020-04-28T11:31:17+00:00

This reverts commit a900aeac253729411cf33c6cb598c152e9e4137f because
regressions were showing up.

Suggested-by: Thierry Reding 
Link: https://lore.kernel.org/dmaengine/20200319201140.17451-1-digetx@gmail.com/
Signed-off-by: Wolfram Sang

Revert "i2c: tegra: Synchronize DMA before termination"

2020-04-28T11:31:16+00:00

This reverts commit 8814044fe0fa182abc9ff818d3da562de98bc9a7 because
regressions were showing up.

Suggested-by: Thierry Reding 
Link: https://lore.kernel.org/dmaengine/20200319201140.17451-1-digetx@gmail.com/
Signed-off-by: Wolfram Sang

i2c: iproc: generate stop event for slave writes

2020-04-28T11:31:09+00:00

When slave status is I2C_SLAVE_RX_END, generate I2C_SLAVE_STOP
event to i2c_client.

Fixes: c245d94ed106 ("i2c: iproc: Add multi byte read-write support for slave mode")
Signed-off-by: Rayagonda Kokatanur 
Signed-off-by: Wolfram Sang

i2c: tegra: Synchronize DMA before termination

2020-04-15T16:27:31+00:00

DMA transfer could be completed, but CPU (which handles DMA interrupt)
may get too busy and can't handle the interrupt in a timely manner,
despite of DMA IRQ being raised. In this case the DMA state needs to
synchronized before terminating DMA transfer in order not to miss the
DMA transfer completion.

Signed-off-by: Dmitry Osipenko 
Signed-off-by: Wolfram Sang

i2c: tegra: Better handle case where CPU0 is busy for a long time

2020-04-15T16:27:25+00:00

Boot CPU0 always handle I2C interrupt and under some rare circumstances
(like running KASAN + NFS root) it may stuck in uninterruptible state for
a significant time. In this case we will get timeout if I2C transfer is
running on a sibling CPU, despite of IRQ being raised. In order to handle
this rare condition, the IRQ status needs to be checked after completion
timeout.

Signed-off-by: Dmitry Osipenko 
Signed-off-by: Wolfram Sang

i2c: remove i2c_new_probed_device API

2020-04-15T09:48:21+00:00

All in-tree users have been converted to the new i2c_new_scanned_device
function, so remove this deprecated one.

Signed-off-by: Wolfram Sang 
Signed-off-by: Wolfram Sang

i2c: altera: use proper variable to hold errno

2020-04-15T09:48:21+00:00

device_property_read_u32() returns errno or 0, so we should use the
integer variable 'ret' and not the u32 'val' to hold the retval.

Fixes: 0560ad576268 ("i2c: altera: Add Altera I2C Controller driver")
Signed-off-by: Wolfram Sang 
Reviewed-by: Thor Thayer 
Signed-off-by: Wolfram Sang

i2c: designware: platdrv: Remove DPM_FLAG_SMART_SUSPEND flag on BYT and CHT

2020-04-15T09:48:20+00:00

We already set DPM_FLAG_SMART_PREPARE, so we completely skip all
callbacks (other then prepare) where possible, quoting from
dw_i2c_plat_prepare():

        /*
         * If the ACPI companion device object is present for this device, it
         * may be accessed during suspend and resume of other devices via I2C
         * operation regions, so tell the PM core and middle layers to avoid
         * skipping system suspend/resume callbacks for it in that case.
         */
        return !has_acpi_companion(dev);

Also setting the DPM_FLAG_SMART_SUSPEND will cause acpi_subsys_suspend()
to leave the controller runtime-suspended even if dw_i2c_plat_prepare()
returned 0.

Leaving the controller runtime-suspended normally, when the I2C controller
is suspended during the suspend_late phase, is not an issue because
the pm_runtime_get_sync() done by i2c_dw_xfer() will (runtime-)resume it.

But for dw I2C controllers on Bay- and Cherry-Trail devices acpi_lpss.c
leaves the controller alive until the suspend_noirq phase, because it may
be used by the _PS3 ACPI methods of PCI devices and PCI devices are left
powered on until the suspend_noirq phase.

Between the suspend_late and resume_early phases runtime-pm is disabled.
So for any ACPI I2C OPRegion accesses done after the suspend_late phase,
the pm_runtime_get_sync() done by i2c_dw_xfer() is a no-op and the
controller is left runtime-suspended.

i2c_dw_xfer() has a check to catch this condition (rather then waiting
for the I2C transfer to timeout because the controller is suspended).
acpi_subsys_suspend() leaving the controller runtime-suspended in
combination with an ACPI I2C OPRegion access done after the suspend_late
phase triggers this check, leading to the following error being logged
on a Bay Trail based Lenovo Thinkpad 8 tablet:

[   93.275882] i2c_designware 80860F41:00: Transfer while suspended
[   93.275993] WARNING: CPU: 0 PID: 412 at drivers/i2c/busses/i2c-designware-master.c:429 i2c_dw_xfer+0x239/0x280
...
[   93.276252] Workqueue: kacpi_notify acpi_os_execute_deferred
[   93.276267] RIP: 0010:i2c_dw_xfer+0x239/0x280
...
[   93.276340] Call Trace:
[   93.276366]  __i2c_transfer+0x121/0x520
[   93.276379]  i2c_transfer+0x4c/0x100
[   93.276392]  i2c_acpi_space_handler+0x219/0x510
[   93.276408]  ? up+0x40/0x60
[   93.276419]  ? i2c_acpi_notify+0x130/0x130
[   93.276433]  acpi_ev_address_space_dispatch+0x1e1/0x252
...

So since on BYT and CHT platforms we want ACPI I2c OPRegion accesses
to work until the suspend_noirq phase, we need the controller to be
runtime-resumed during the suspend phase if it is runtime-suspended
suspended at that time. This means that we must not set the
DPM_FLAG_SMART_SUSPEND on these platforms.

On BYT and CHT we already have a special ACCESS_NO_IRQ_SUSPEND flag
to make sure the controller stays functional until the suspend_noirq
phase. This commit makes the driver not set the DPM_FLAG_SMART_SUSPEND
flag when that flag is set.

Cc: stable@vger.kernel.org
Fixes: b30f2f65568f ("i2c: designware: Set IRQF_NO_SUSPEND flag for all BYT and CHT controllers")
Signed-off-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Acked-by: Rafael J. Wysocki 
Acked-by: Jarkko Nikula 
Signed-off-by: Wolfram Sang