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

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

2019-11-10T10:34:27+00:00

[ Upstream commit 348e46fbb4cdb2aead79aee1fd8bb25ec5fd25db ]

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

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

2019-11-10T10:34:26+00:00

[ Upstream commit 6d6b0d0d5afc8c4c84b08261260ba11dfa5206f2 ]

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

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

2019-11-10T10:34:26+00:00

[ Upstream commit 02e64276c6dbcc4c5f39844f33d18180832a58f3 ]

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

i2c: mt65xx: fix NULL ptr dereference

2019-11-10T10:34:25+00:00

[ Upstream commit 62931ac2f9015ea38d80494ec37658ab3df6a6d7 ]

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

i2c: aspeed: fix master pending state handling

2019-11-10T10:34:17+00:00

[ Upstream commit 1f0d9cbeec9bb0a1c2013342836f2c9754d6502b ]

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

i2c: qcom-geni: Disable DMA processing on the Lenovo Yoga C630

2019-10-11T16:36:48+00:00

[ Upstream commit 127068abe85bf3dee50df51cb039a5a987a4a666 ]

We have a production-level laptop (Lenovo Yoga C630) which is exhibiting
a rather horrific bug.  When I2C HID devices are being scanned for at
boot-time the QCom Geni based I2C (Serial Engine) attempts to use DMA.
When it does, the laptop reboots and the user never sees the OS.

Attempts are being made to debug the reason for the spontaneous reboot.
No luck so far, hence the requirement for this hot-fix.  This workaround
will be removed once we have a viable fix.

Signed-off-by: Lee Jones 
Tested-by: Bjorn Andersson 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin

i2c: tegra: Move suspend handling to NOIRQ phase

2019-10-07T17:01:40+00:00

[ Upstream commit 8ebf15e9c869e764b3aab4928938ee68c0e2bd6d ]

Commit acc8abcb2a9c ("i2c: tegra: Add suspend-resume support") added
suspend support for the Tegra I2C driver and following this change on
Tegra30 the following WARNING is seen on entering suspend ...

 WARNING: CPU: 2 PID: 689 at /dvs/git/dirty/git-master_l4t-upstream/kernel/drivers/i2c/i2c-core.h:54 __i2c_transfer+0x35c/0x70c
 i2c i2c-4: Transfer while suspended
 Modules linked in: brcmfmac brcmutil
 CPU: 2 PID: 689 Comm: rtcwake Not tainted 5.3.0-rc7-g089cf7f6ecb2 #1
 Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
 [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
 [] (show_stack) from [] (dump_stack+0xb4/0xc8)
 [] (dump_stack) from [] (__warn+0xe0/0xf8)
 [] (__warn) from [] (warn_slowpath_fmt+0x48/0x6c)
 [] (warn_slowpath_fmt) from [] (__i2c_transfer+0x35c/0x70c)
 [] (__i2c_transfer) from [] (i2c_transfer+0x58/0xf4)
 [] (i2c_transfer) from [] (i2c_transfer_buffer_flags+0x4c/0x70)
 [] (i2c_transfer_buffer_flags) from [] (regmap_i2c_write+0x14/0x30)
 [] (regmap_i2c_write) from [] (_regmap_raw_write_impl+0x35c/0x868)
 [] (_regmap_raw_write_impl) from [] (_regmap_update_bits+0xe4/0xec)
 [] (_regmap_update_bits) from [] (regmap_update_bits_base+0x50/0x74)
 [] (regmap_update_bits_base) from [] (regulator_disable_regmap+0x44/0x54)
 [] (regulator_disable_regmap) from [] (_regulator_do_disable+0xf8/0x268)
 [] (_regulator_do_disable) from [] (_regulator_disable+0xf4/0x19c)
 [] (_regulator_disable) from [] (regulator_disable+0x34/0x64)
 [] (regulator_disable) from [] (regulator_bulk_disable+0x28/0xb4)
 [] (regulator_bulk_disable) from [] (tegra_pcie_power_off+0x64/0xa8)
 [] (tegra_pcie_power_off) from [] (tegra_pcie_pm_suspend+0x25c/0x3f4)
 [] (tegra_pcie_pm_suspend) from [] (dpm_run_callback+0x38/0x1d4)
 [] (dpm_run_callback) from [] (__device_suspend_noirq+0xc0/0x2b8)
 [] (__device_suspend_noirq) from [] (dpm_noirq_suspend_devices+0x100/0x37c)
 [] (dpm_noirq_suspend_devices) from [] (dpm_suspend_noirq+0x1c/0x48)
 [] (dpm_suspend_noirq) from [] (suspend_devices_and_enter+0x1d0/0xa00)
 [] (suspend_devices_and_enter) from [] (pm_suspend+0x220/0x74c)
 [] (pm_suspend) from [] (state_store+0x6c/0xc8)
 [] (state_store) from [] (kernfs_fop_write+0xe8/0x1c4)
 [] (kernfs_fop_write) from [] (__vfs_write+0x2c/0x1c4)
 [] (__vfs_write) from [] (vfs_write+0xa4/0x184)
 [] (vfs_write) from [] (ksys_write+0x9c/0xdc)
 [] (ksys_write) from [] (ret_fast_syscall+0x0/0x54)
 Exception stack(0xe9f21fa8 to 0xe9f21ff0)
 1fa0:                   0000006c 004b2438 00000004 004b2438 00000004 00000000
 1fc0: 0000006c 004b2438 004b1228 00000004 00000004 00000004 0049e78c 004b1228
 1fe0: 00000004 be9809b8 b6f0bc0b b6e96206

The problem is that the Tegra PCIe driver indirectly uses I2C for
controlling some regulators and the I2C driver is now being suspended
before the PCIe driver causing the PCIe suspend to fail. The Tegra PCIe
driver is suspended during the NOIRQ phase and this cannot be changed
due to other dependencies. Therefore, we also need to move the suspend
handling for the Tegra I2C driver to the NOIRQ phase as well.

In order to move the I2C suspend handling to the NOIRQ phase we also
need to avoid calling pm_runtime_get/put() because per commit
1e2ef05bb8cf ("PM: Limit race conditions between runtime PM and system
sleep (v2)") these cannot be called early in resume. The function
tegra_i2c_init(), called during resume, calls pm_runtime_get/put() and
so move these calls outside of tegra_i2c_init(), so this function can
be used during the NOIRQ resume phase.

Fixes: acc8abcb2a9c ("i2c: tegra: Add suspend-resume support")

Signed-off-by: Jon Hunter 
Acked-by: Thierry Reding 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin

i2c-cht-wc: Fix lockdep warning

2019-10-07T17:01:30+00:00

[ Upstream commit 232219b9a464c2479c98aa589acb1bd3383ae9d6 ]

When the kernel is build with lockdep support and the i2c-cht-wc driver is
used, the following warning is shown:

[   66.674334] ======================================================
[   66.674337] WARNING: possible circular locking dependency detected
[   66.674340] 5.3.0-rc4+ #83 Not tainted
[   66.674342] ------------------------------------------------------
[   66.674345] systemd-udevd/1232 is trying to acquire lock:
[   66.674349] 00000000a74dab07 (intel_soc_pmic_chtwc:167:(&cht_wc_regmap_cfg)->lock){+.+.}, at: regmap_write+0x31/0x70
[   66.674360]
               but task is already holding lock:
[   66.674362] 00000000d44a85b7 (i2c_register_adapter){+.+.}, at: i2c_smbus_xfer+0x49/0xf0
[   66.674370]
               which lock already depends on the new lock.

[   66.674371]
               the existing dependency chain (in reverse order) is:
[   66.674374]
               -> #1 (i2c_register_adapter){+.+.}:
[   66.674381]        rt_mutex_lock_nested+0x46/0x60
[   66.674384]        i2c_smbus_xfer+0x49/0xf0
[   66.674387]        i2c_smbus_read_byte_data+0x45/0x70
[   66.674391]        cht_wc_byte_reg_read+0x35/0x50
[   66.674394]        _regmap_read+0x63/0x1a0
[   66.674396]        _regmap_update_bits+0xa8/0xe0
[   66.674399]        regmap_update_bits_base+0x63/0xa0
[   66.674403]        regmap_irq_update_bits.isra.0+0x3b/0x50
[   66.674406]        regmap_add_irq_chip+0x592/0x7a0
[   66.674409]        devm_regmap_add_irq_chip+0x89/0xed
[   66.674412]        cht_wc_probe+0x102/0x158
[   66.674415]        i2c_device_probe+0x95/0x250
[   66.674419]        really_probe+0xf3/0x380
[   66.674422]        driver_probe_device+0x59/0xd0
[   66.674425]        device_driver_attach+0x53/0x60
[   66.674428]        __driver_attach+0x92/0x150
[   66.674431]        bus_for_each_dev+0x7d/0xc0
[   66.674434]        bus_add_driver+0x14d/0x1f0
[   66.674437]        driver_register+0x6d/0xb0
[   66.674440]        i2c_register_driver+0x45/0x80
[   66.674445]        do_one_initcall+0x60/0x2f4
[   66.674450]        kernel_init_freeable+0x20d/0x2b4
[   66.674453]        kernel_init+0xa/0x10c
[   66.674457]        ret_from_fork+0x3a/0x50
[   66.674459]
               -> #0 (intel_soc_pmic_chtwc:167:(&cht_wc_regmap_cfg)->lock){+.+.}:
[   66.674465]        __lock_acquire+0xe07/0x1930
[   66.674468]        lock_acquire+0x9d/0x1a0
[   66.674472]        __mutex_lock+0xa8/0x9a0
[   66.674474]        regmap_write+0x31/0x70
[   66.674480]        cht_wc_i2c_adap_smbus_xfer+0x72/0x240 [i2c_cht_wc]
[   66.674483]        __i2c_smbus_xfer+0x1a3/0x640
[   66.674486]        i2c_smbus_xfer+0x67/0xf0
[   66.674489]        i2c_smbus_read_byte_data+0x45/0x70
[   66.674494]        bq24190_probe+0x26b/0x410 [bq24190_charger]
[   66.674497]        i2c_device_probe+0x189/0x250
[   66.674500]        really_probe+0xf3/0x380
[   66.674503]        driver_probe_device+0x59/0xd0
[   66.674506]        device_driver_attach+0x53/0x60
[   66.674509]        __driver_attach+0x92/0x150
[   66.674512]        bus_for_each_dev+0x7d/0xc0
[   66.674515]        bus_add_driver+0x14d/0x1f0
[   66.674518]        driver_register+0x6d/0xb0
[   66.674521]        i2c_register_driver+0x45/0x80
[   66.674524]        do_one_initcall+0x60/0x2f4
[   66.674528]        do_init_module+0x5c/0x230
[   66.674531]        load_module+0x2707/0x2a20
[   66.674534]        __do_sys_init_module+0x188/0x1b0
[   66.674537]        do_syscall_64+0x5c/0xb0
[   66.674541]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
[   66.674543]
               other info that might help us debug this:

[   66.674545]  Possible unsafe locking scenario:

[   66.674547]        CPU0                    CPU1
[   66.674548]        ----                    ----
[   66.674550]   lock(i2c_register_adapter);
[   66.674553]                                lock(intel_soc_pmic_chtwc:167:(&cht_wc_regmap_cfg)->lock);
[   66.674556]                                lock(i2c_register_adapter);
[   66.674559]   lock(intel_soc_pmic_chtwc:167:(&cht_wc_regmap_cfg)->lock);
[   66.674561]
                *** DEADLOCK ***

The problem is that the CHT Whiskey Cove PMIC's builtin i2c-adapter is
itself a part of an i2c-client (the PMIC). This means that transfers done
through it take adapter->bus_lock twice, once for the parent i2c-adapter
and once for its own bus_lock. Lockdep does not like this nested locking.

To make lockdep happy in the case of busses with muxes, the i2c-core's
i2c_adapter_lock_bus function calls:

 rt_mutex_lock_nested(&adapter->bus_lock, i2c_adapter_depth(adapter));

But i2c_adapter_depth only works when the direct parent of the adapter is
another adapter, as it is only meant for muxes. In this case there is an
i2c-client and MFD instantiated platform_device in the parent->child chain
between the 2 devices.

This commit overrides the default i2c_lock_operations, passing a hardcoded
depth of 1 to rt_mutex_lock_nested, making lockdep happy.

Note that if there were to be a mux attached to the i2c-wc-cht adapter,
this would break things again since the i2c-mux code expects the
root-adapter to have a locking depth of 0. But the i2c-wc-cht adapter
always has only 1 client directly attached in the form of the charger IC
paired with the CHT Whiskey Cove PMIC.

Signed-off-by: Hans de Goede 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin

i2c: riic: Clear NACK in tend isr

2019-10-05T13:12:36+00:00

commit a71e2ac1f32097fbb2beab098687a7a95c84543e upstream.

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

i2c: mediatek: disable zero-length transfers for mt8183

2019-08-30T13:06:17+00:00

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