kernel/git/stable/linux.git/drivers/i2c/busses, branch linux-4.7.y

i2c: qup: skip qup_i2c_suspend if the device is already runtime suspended

2016-09-30T08:12:46+00:00

commit 331dcf421c34d227784d07943eb01e4023a42b0a upstream. If the i2c device is already runtime suspended, if qup_i2c_suspend is executed during suspend-to-idle or suspend-to-ram it will result in the following splat: WARNING: CPU: 3 PID: 1593 at drivers/clk/clk.c:476 clk_core_unprepare+0x80/0x90 Modules linked in: CPU: 3 PID: 1593 Comm: bash Tainted: G W 4.8.0-rc3 #14 Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) PC is at clk_core_unprepare+0x80/0x90 LR is at clk_unprepare+0x28/0x40 pc : [] lr : [] pstate: 60000145 Call trace: clk_core_unprepare+0x80/0x90 qup_i2c_disable_clocks+0x2c/0x68 qup_i2c_suspend+0x10/0x20 platform_pm_suspend+0x24/0x68 ... This patch fixes the issue by executing qup_i2c_pm_suspend_runtime conditionally in qup_i2c_suspend. Signed-off-by: Sudeep Holla Reviewed-by: Andy Gross Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman

i2c-eg20t: fix race between i2c init and interrupt enable

2016-09-30T08:12:46+00:00

commit 371a015344b6e270e7e3632107d9554ec6d27a6b upstream. the eg20t driver call request_irq() function before the pch_base_address, base address of i2c controller's register, is assigned an effective value. there is one possible scenario that an interrupt which isn't inside eg20t arrives immediately after request_irq() is executed when i2c controller shares an interrupt number with others. since the interrupt handler pch_i2c_handler() has already active as shared action, it will be called and read its own register to determine if this interrupt is from itself. At that moment, since base address of i2c registers is not remapped in kernel space yet,so the INT handler will access an illegal address and then a error occurs. Signed-off-by: Yadi.hu Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman

i2c: cros-ec-tunnel: Fix usage of cros_ec_cmd_xfer()

2016-09-07T06:34:52+00:00

commit 4d01d88019261d05ec3bff5f1a6013393faa3b9e upstream. cros_ec_cmd_xfer returns success status if the command transport completes successfully, but the execution result is incorrectly ignored. In many cases, the execution result is assumed to be successful, leading to ignored errors and operating on uninitialized data. We've recently introduced the cros_ec_cmd_xfer_status() helper to avoid these problems. Let's use it. [Regarding the 'Fixes' tag; there is significant refactoring since the driver's introduction, but the underlying logical error exists throughout I believe] Fixes: 9d230c9e4f4e ("i2c: ChromeOS EC tunnel driver") Signed-off-by: Brian Norris Reviewed-by: Javier Martinez Canillas Reviewed-by: Guenter Roeck Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman

i2c: efm32: fix a failure path in efm32_i2c_probe()

2016-08-20T16:10:53+00:00

commit 7dd91d52a813f99a95d20f539b777e9e6198b931 upstream. There is the only failure path in efm32_i2c_probe(), where clk_disable_unprepare() is missed. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Acked-by: Uwe Kleine-König Signed-off-by: Wolfram Sang Fixes: 1b5b23718b84 ("i2c: efm32: new bus driver") Signed-off-by: Greg Kroah-Hartman

i2c: tegra: Correct error path in probe

2016-07-05T15:20:37+00:00

Commit 497fbe24987b ("i2c: tegra: enable multi master mode for tegra210") enables the Tegra I2C 'div_clk' for adapters using the multi-master mode during the device probe. Although the probe error path was updated to disable the clock on probe failure, there is one place after calling tegra_i2c_init() where the clock will not be disabled on failure. Correct the error path so that the 'div_clk' is disabled if calling tegra_i2c_init() fails. Fixes: 497fbe24987b ("i2c: tegra: enable multi master mode for tegra210") Signed-off-by: Jon Hunter Acked-by: Laxman Dewangan Signed-off-by: Wolfram Sang

i2c: qup: Fix wrong value of index variable

2016-06-18T16:33:13+00:00

index gets incremented during check to determine if the messages can be transferred with dma. But not reset after that, resulting in wrong start value in subsequent loop, causing failure. Fix it. Signed-off-by: Sricharan R Signed-off-by: Wolfram Sang Cc: stable@kernel.org

i2c: octeon: Avoid printk after too long SMBUS message

2016-06-09T20:07:57+00:00

Remove the warning about a too long SMBUS message because the ipmi_ssif driver triggers this warning too frequently so it spams the message log. Signed-off-by: Jan Glauber Signed-off-by: Wolfram Sang

i2c: octeon: Missing AAK flag in case of I2C_M_RECV_LEN

2016-06-09T20:05:32+00:00

During receive the controller requires the AAK flag for all bytes but the final one. This was wrong in case of I2C_M_RECV_LEN, where the decision if the final byte is to be transmitted happened before adding the additional received length byte. Set the AAK flag if additional bytes are to be received. Signed-off-by: Jan Glauber Signed-off-by: Wolfram Sang

i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR

2016-06-09T19:38:57+00:00

Many Intel systems the BIOS declares a SystemIO OpRegion below the SMBus PCI device as can be seen in ACPI DSDT table from Lenovo Yoga 900: Device (SBUS) { OperationRegion (SMBI, SystemIO, (SBAR << 0x05), 0x10) Field (SMBI, ByteAcc, NoLock, Preserve) { HSTS, 8, Offset (0x02), HCON, 8, HCOM, 8, TXSA, 8, DAT0, 8, DAT1, 8, HBDR, 8, PECR, 8, RXSA, 8, SDAT, 16 } There are also bunch of AML methods that that the BIOS can use to access these fields. Most of the systems in question AML methods accessing the SMBI OpRegion are never used. Now, because of this SMBI OpRegion many systems fail to load the SMBus driver with an error looking like one below: ACPI Warning: SystemIO range 0x0000000000003040-0x000000000000305F conflicts with OpRegion 0x0000000000003040-0x000000000000304F (\_SB.PCI0.SBUS.SMBI) (20160108/utaddress-255) ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver The reason is that this SMBI OpRegion conflicts with the PCI BAR used by the SMBus driver. It turns out that we can install a custom SystemIO address space handler for the SMBus device to intercept all accesses through that OpRegion. This allows us to share the PCI BAR with the AML code if it for some reason is using it. We do not expect that this OpRegion handler will ever be called but if it is we print a warning and prevent all access from the SMBus driver itself. Link: https://bugzilla.kernel.org/show_bug.cgi?id=110041 Reported-by: Andy Lutomirski Reported-by: Pali Rohár Suggested-by: Rafael J. Wysocki Signed-off-by: Mika Westerberg Acked-by: Rafael J. Wysocki Reviewed-by: Jean Delvare Reviewed-by: Benjamin Tissoires Tested-by: Pali Rohár Tested-by: Jean Delvare Signed-off-by: Wolfram Sang Cc: stable@vger.kernel.org

i2c: xlr: rename ARCH_TANGOX to ARCH_TANGO

2016-05-26T19:18:56+00:00

The ARCH name was changed during the review process of the mach, and this driver was forgotten to be converted. Fix it now. http://article.gmane.org/gmane.linux.ports.arm.kernel/456331 Signed-off-by: Marc Gonzalez [wsa: updated commit message slightly] Signed-off-by: Wolfram Sang