linux/drivers/i2c, branch v4.6

i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared

2016-04-22T13:31:54Z

The exynos5 I2C controller driver always prepares and enables a clock before using it and then disables unprepares it when the clock is not used anymore. But this can cause a possible ABBA deadlock in some scenarios since a driver that uses regmap to access its I2C registers, will first grab the regmap lock and then the I2C xfer function will grab the prepare lock when preparing the I2C clock. But since the clock driver also uses regmap for I2C accesses, preparing a clock will first grab the prepare lock and then the regmap lock when using the regmap API. An example of this happens on the Exynos5422 Odroid XU4 board where a s2mps11 PMIC is used and both the s2mps11 regulators and clk drivers share the same I2C regmap. The possible deadlock is reported by the kernel lockdep: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sec_core:428:(regmap)->lock); lock(prepare_lock); lock(sec_core:428:(regmap)->lock); lock(prepare_lock); *** DEADLOCK *** Fix it by leaving the code prepared on probe and use {en,dis}able in the I2C transfer function. This patch is similar to commit 34e81ad5f0b6 ("i2c: s3c2410: fix ABBA deadlock by keeping clock prepared") that fixes the same bug in other driver for an I2C controller found in Samsung SoCs. Reported-by: Anand Moon Signed-off-by: Javier Martinez Canillas Reviewed-by: Anand Moon Reviewed-by: Krzysztof Kozlowski Signed-off-by: Wolfram Sang Cc: stable@kernel.org

i2c: cpm: Fix build break due to incompatible pointer types

2016-04-22T13:25:53Z

Since commit ea8daa7b9784 ("kbuild: Add option to turn incompatible pointer check into error"), assignments from an incompatible pointer types have become a hard error, eg: drivers/i2c/busses/i2c-cpm.c:545:91: error: passing argument 3 of 'dma_alloc_coherent' from incompatible pointer type Fix the build break by converting txdma & rxdma to dma_addr_t. Signed-off-by: Michael Ellerman Signed-off-by: Wolfram Sang Cc: stable@kernel.org Fixes: ea8daa7b9784

i2c: ismt: Add Intel DNV PCI ID

2016-04-12T21:44:16Z

Intel DNV has the same iSMT SMBus host controller than Intel Avoton. Add DNV PCI ID to the list of supported devices. Signed-off-by: Mika Westerberg Acked-by: Andy Shevchenko Acked-by: Neil Horman Signed-off-by: Wolfram Sang

i2c: xlp9xx: add support for Broadcom Vulcan

2016-04-12T21:40:11Z

The Broadcom Vulcan ARM64 processor uses the same I2C controller present on the Broadcom XLP9xx/5xx MIPS processor family. Updated the Kconfig by adding ARCH_VULCAN option. Signed-off-by: Tanmay Jagdale Signed-off-by: Wolfram Sang

i2c: rk3x: add support for rk3228

2016-04-12T21:34:44Z

Enable the I2C core for this SoC. Signed-off-by: Yakir Yang Reviewed-by: Heiko Stuebner Acked-by: Rob Herring Signed-off-by: Wolfram Sang

i2c: jz4780: really prevent potential division by zero

2016-04-09T06:36:44Z

Make sure we avoid a division-by-zero OOPS in case clock-frequency is set too low in DT. Add missing '\n' while we are here. Signed-off-by: Wolfram Sang Acked-by: Axel Lin

Revert "i2c: jz4780: prevent potential division by zero"

2016-04-09T06:32:37Z

This reverts commit 34cf2acdafaa31a13821e45de5ee896adcd307b1. 'ret' is not set when bailing out. Also, there is a better place to check for 0. Reported-by: Axel Lin Signed-off-by: Wolfram Sang

i2c: jz4780: prevent potential division by zero

2016-04-07T19:13:38Z

Make sure we don't OOPS in case clock-frequency is set to 0 in a DT. The variable set here is later used as a divisor. Signed-off-by: Wolfram Sang

i2c: mux: demux-pinctrl: Clean up sysfs attributes

2016-04-01T11:00:07Z

sysfs attributes should use the same format for reads and writes, rather than pretty-printing on read. * Make the "cur_master" attribute read back as just the name of the master * Expose the list of all masters as a read-only "available_masters" attribute, using space separators as in similar attributes of other devices Also, spell out "cur_master" in full as "current_master". Fixes: 50a5ba876908 ("i2c: mux: demux-pinctrl: add driver") Signed-off-by: Ben Hutchings Tested-by: Wolfram Sang Signed-off-by: Wolfram Sang

i2c: prevent endless uevent loop with CONFIG_I2C_DEBUG_CORE

2016-03-30T12:20:33Z

Jan reported this: === After enabling CONFIG_I2C_DEBUG_CORE my system was broken (no network, console login not possible). System log was flooded with the this message: ... [ 608.052077] rtc-ds1307 0-0068: uevent [ 608.052500] rtc-ds1307 0-0068: uevent [ 608.052925] rtc-ds1307 0-0068: uevent ... The culprit is the dev_dbg printk in the i2c uevent handler. If this is activated (for instance by CONFIG_I2C_DEBUG_CORE) it results in an endless loop with systemd-journald. This happens if user-space scans the system log and reads the uevent file to get information about a newly created device, which seems fair use to me. Unfortunately reading the "uevent" file uses the same function that runs for creating the uevent for a new device, generating the next syslog entry. Ideally user-space would implement a recursion detection and after reading the same device file for the 1000th time call it a day, but nevertheless I think we should avoid this problem by removing the debug print completely or using another print variant. The same problem seems to be reported here: https://bugs.freedesktop.org/show_bug.cgi?id=76886 === His patch converted the message to pr_debug, but I think the debug can simply go. We have other means to see code paths these days. This enables us to clean up the function some more while we are here. Reported-by: Jan Glauber Signed-off-by: Wolfram Sang Acked-by: Alexander Sverdlin Tested-by: Jan Glauber