linux-stable.git/drivers/i2c, branch v4.18.7

i2c: designware: Re-init controllers with pm_disabled set on resume

2018-09-09T08:32:37+00:00

commit 9d9a152ebaa86a9dede4624919566483c955d0a7 upstream.

On Bay Trail and Cherry Trail devices we set the pm_disabled flag for I2C
busses which the OS shares with the PUNIT as these need special handling.
Until now we called dev_pm_syscore_device(dev, true) for I2C controllers
with this flag set to keep these I2C controllers always on.

After commit 12864ff8545f ("ACPI / LPSS: Avoid PM quirks on suspend and
resume from hibernation"), this no longer works. This commit modifies
lpss_iosf_exit_d3_state() to only run if lpss_iosf_enter_d3_state() has ran
before it, so that it does not run on a resume from hibernate (or from S3).

On these systems the conditions for lpss_iosf_enter_d3_state() to run
never become true, so lpss_iosf_exit_d3_state() never gets called and
the 2 LPSS DMA controllers never get forced into D0 mode, instead they
are left in their default automatic power-on when needed mode.

The not forcing of D0 mode for the DMA controllers enables these systems
to properly enter S0ix modes, which is a good thing.

But after entering S0ix modes the I2C controller connected to the PMIC
no longer works, leading to e.g. broken battery monitoring.

The _PS3 method for this I2C controller looks like this:

            Method (_PS3, 0, NotSerialized)  // _PS3: Power State 3
            {
                If ((((PMID == 0x04) || (PMID == 0x05)) || (PMID == 0x06)))
                {
                    Return (Zero)
                }

                PSAT |= 0x03
                Local0 = PSAT /* \_SB_.I2C5.PSAT */
            }

Where PMID = 0x05, so we enter the Return (Zero) path on these systems.

So even if we were to not call dev_pm_syscore_device(dev, true) the
I2C controller will be left in D0 rather then be switched to D3.

Yet on other Bay and Cherry Trail devices S0ix is not entered unless *all*
I2C controllers are in D3 mode. This combined with the I2C controller no
longer working now that we reach S0ix states on these systems leads to me
believing that the PUNIT itself puts the I2C controller in D3 when all
other conditions for entering S0ix states are true.

Since now the I2C controller is put in D3 over a suspend/resume we must
re-initialize it afterwards and that does indeed fix it no longer working.

This commit implements this fix by:

1) Making the suspend_late callback a no-op if pm_disabled is set and
making the resume_early callback skip the clock re-enable (since it now was
not disabled) while still doing the necessary I2C controller re-init.

2) Removing the dev_pm_syscore_device(dev, true) call, so that the suspend
and resume callbacks are actually called. Normally this would cause the
ACPI pm code to call _PS3 putting the I2C controller in D3, wreaking havoc
since it is shared with the PUNIT, but in this special case the _PS3 method
is a no-op so we can safely allow a "fake" suspend / resume.

Fixes: 12864ff8545f ("ACPI / LPSS: Avoid PM quirks on suspend and resume ...")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200861
Cc: 4.15+  # 4.15+
Signed-off-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Acked-by: Jarkko Nikula 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: imx: Fix race condition in dma read

2018-08-24T11:04:51+00:00

commit bed4ff1ed4d8f2ef5007c5c6ae1b29c5677a3632 upstream.

This fixes a race condition, where the DMAEN bit ends up being set after
I2C slave has transmitted a byte following the dummy read.  When that
happens, an interrupt is generated instead, and no DMA request is generated
to kickstart the DMA read, and a timeout happens after DMA_TIMEOUT (1 sec).

Fixed by setting the DMAEN bit before the dummy read.

Signed-off-by: Esben Haabendal 
Acked-by: Uwe Kleine-König 
Signed-off-by: Wolfram Sang 
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman

i2c: core: ACPI: Properly set status byte to 0 for multi-byte writes

2018-08-24T11:04:51+00:00

commit c463a158cb6c5d9a85b7d894cd4f8116e8bd6be0 upstream.

acpi_gsb_i2c_write_bytes() returns i2c_transfer()'s return value, which
is the number of transfers executed on success, so 1.

The ACPI code expects us to store 0 in gsb->status for success, not 1.

Specifically this breaks the following code in the Thinkpad 8 DSDT:

            ECWR = I2CW = ECWR /* \_SB_.I2C1.BAT0.ECWR */
            If ((ECST == Zero))
            {
                ECRD = I2CR /* \_SB_.I2C1.I2CR */
            }

Before this commit we set ECST to 1, causing the read to never happen
breaking battery monitoring on the Thinkpad 8.

This commit makes acpi_gsb_i2c_write_bytes() return 0 when i2c_transfer()
returns 1, so the single write transfer completed successfully, and
makes it return -EIO on for other (unexpected) return values >= 0.

Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede 
Acked-by: Mika Westerberg 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: xlp9xx: Fix case where SSIF read transaction completes early

2018-08-09T15:41:13+00:00

During ipmi stress tests we see occasional failure of transactions
at the boot time. This happens in the case of a I2C_M_RECV_LEN
transactions, when the read transfer completes (with the initial
read length of 34) before the driver gets a chance to handle interrupts.

The current driver code expects at least 2 interrupts for I2C_M_RECV_LEN
transactions. The length is updated during the first interrupt, and  the
buffer contents are only copied during subsequent interrupts. In case of
just one interrupt, we will complete the transaction without copying
out the bytes from RX fifo.

Update the code to drain the RX fifo after the length update,
so that the transaction completes correctly in all cases.

Signed-off-by: George Cherian 
Signed-off-by: Wolfram Sang 
Cc: stable@kernel.org

Merge branch 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2018-07-30T18:37:16+00:00

Pull locking fixes from Ingo Molnar:
 "A paravirt UP-patching fix, and an I2C MUX driver lockdep warning fix"

* 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  locking/pvqspinlock/x86: Use LOCK_PREFIX in __pv_queued_spin_unlock() assembly code
  i2c/mux, locking/core: Annotate the nested rt_mutex usage
  locking/rtmutex: Allow specifying a subclass for nested locking

i2c/mux, locking/core: Annotate the nested rt_mutex usage

2018-07-25T09:22:20+00:00

If an i2c topology has instances of nested muxes, then a lockdep splat
is produced when when i2c_parent_lock_bus() is called.  Here is an
example:

  ============================================
  WARNING: possible recursive locking detected
  --------------------------------------------
  insmod/68159 is trying to acquire lock:
    (i2c_register_adapter#2){+.+.}, at: i2c_parent_lock_bus+0x32/0x50 [i2c_mux]

  but task is already holding lock:
    (i2c_register_adapter#2){+.+.}, at: i2c_parent_lock_bus+0x32/0x50 [i2c_mux]

  other info that might help us debug this:
    Possible unsafe locking scenario:

          CPU0
          ----
     lock(i2c_register_adapter#2);
     lock(i2c_register_adapter#2);

    *** DEADLOCK ***

    May be due to missing lock nesting notation

  1 lock held by insmod/68159:
    #0:  (i2c_register_adapter#2){+.+.}, at: i2c_parent_lock_bus+0x32/0x50 [i2c_mux]

  stack backtrace:
  CPU: 13 PID: 68159 Comm: insmod Tainted: G           O
  Call Trace:
    dump_stack+0x67/0x98
    __lock_acquire+0x162e/0x1780
    lock_acquire+0xba/0x200
    rt_mutex_lock+0x44/0x60
    i2c_parent_lock_bus+0x32/0x50 [i2c_mux]
    i2c_parent_lock_bus+0x3e/0x50 [i2c_mux]
    i2c_smbus_xfer+0xf0/0x700
    i2c_smbus_read_byte+0x42/0x70
    my2c_init+0xa2/0x1000 [my2c]
    do_one_initcall+0x51/0x192
    do_init_module+0x62/0x216
    load_module+0x20f9/0x2b50
    SYSC_init_module+0x19a/0x1c0
    SyS_init_module+0xe/0x10
    do_syscall_64+0x6c/0x1a0
    entry_SYSCALL_64_after_hwframe+0x42/0xb7

Reported-by: John Sperbeck 
Tested-by: John Sperbeck 
Signed-off-by: Peter Rosin 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Davidlohr Bueso 
Cc: Deepa Dinamani 
Cc: Greg Kroah-Hartman 
Cc: Linus Torvalds 
Cc: Peter Chang 
Cc: Peter Zijlstra 
Cc: Philippe Ombredanne 
Cc: Thomas Gleixner 
Cc: Will Deacon 
Cc: Wolfram Sang 
Link: http://lkml.kernel.org/r/20180720083914.1950-3-peda@axentia.se
Signed-off-by: Ingo Molnar

i2c: imx: use open drain for recovery GPIO

2018-07-24T12:59:12+00:00

I2C is open drain, so request the GPIO accordingly, even if pinmux did
set it up correctly for in-kernel users in this case.

Signed-off-by: Wolfram Sang 
Reviewed-by: Lucas Stach 
Signed-off-by: Wolfram Sang

i2c: rcar: handle RXDMA HW behaviour on Gen3

2018-07-24T12:56:12+00:00

On Gen3, we can only do RXDMA once per transfer reliably. For that, we
must reset the device, then we can have RXDMA once. This patch
implements this. When there is no reset controller or the reset fails,
RXDMA will be blocked completely. Otherwise, it will be disabled after
the first RXDMA transfer. Based on a commit from the BSP by Hiromitsu
Yamasaki, yet completely refactored to handle multiple read messages
within one transfer.

Signed-off-by: Wolfram Sang 
Reviewed-by: Geert Uytterhoeven 
Signed-off-by: Wolfram Sang 
Cc: stable@kernel.org

i2c: imx: Fix reinit_completion() use

2018-07-23T18:07:59+00:00

Make sure to call reinit_completion() before dma is started to avoid race
condition where reinit_completion() is called after complete() and before
wait_for_completion_timeout().

Signed-off-by: Esben Haabendal 
Fixes: ce1a78840ff7 ("i2c: imx: add DMA support for freescale i2c driver")
Reviewed-by: Uwe Kleine-König 
Signed-off-by: Wolfram Sang 
Cc: stable@kernel.org

i2c: davinci: Avoid zero value of CLKH

2018-07-23T18:04:35+00:00

If CLKH is set to 0 I2C clock is not generated at all, so avoid this value
and stretch the clock in this case.

Signed-off-by: Alexander Sverdlin 
Acked-by: Sekhar Nori 
Signed-off-by: Wolfram Sang