kernel.git/drivers/i2c/i2c-core.c, branch linux-4.6.y

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

i2c: immediately mark ourselves as registered

2016-03-14T17:17:25Z

Mark the i2c bus as registered right after the the bus_register call, not at the end of init. Otherwise, we can't register our own dummy driver. Reported-by: Thierry Reding Signed-off-by: Wolfram Sang Fixes: 95026658c46ea2 ("i2c: do not use internal data from driver core")

i2c: do not use internal data from driver core

2016-03-12T15:58:11Z

The variable p is a data structure which is used by the driver core internally and it is not expected that busses will be directly accessing these driver core internal only data. Signed-off-by: Sudip Mukherjee Acked-by: Greg Kroah-Hartman [wsa: removed the unlikely()] Signed-off-by: Wolfram Sang

i2c: i2c-core: sort includes

2016-02-20T22:33:38Z

I request this for drivers, so the core should adhere to sorted includes as well. Signed-off-by: Wolfram Sang

i2c: always enable RuntimePM for the adapter device

2016-01-10T08:27:06Z

The adapter device is a logical device. Because of that, it already uses pm_runtime_no_callbacks() in the core. To ensure proper propagation from the children (i2c devices) to the parent of the adapter (the HW device), make sure RuntimePM is enabled in any case. Signed-off-by: Wolfram Sang Signed-off-by: Wolfram Sang

i2c: make i2c_parse_fw_timings() always visible

2015-12-17T19:36:39Z

This function used to be DT only, so it lived inside a CONFIG_OF block. Now it uses device attributes and must be moved outside of it. No further code changes, only one whitespace improvement. Reported-by: Jim Davis Signed-off-by: Wolfram Sang Reviewed-by: Mika Westerberg Signed-off-by: Wolfram Sang

i2c: add generic routine to parse DT for timing information

2015-12-14T09:51:07Z

Inspired from the i2c-rk3x driver (thanks guys!) but refactored and extended. See built-in docs for further information. Signed-off-by: Wolfram Sang Reviewed-by: Mika Westerberg Signed-off-by: Wolfram Sang

i2c: fix wakeup irq parsing

2015-11-20T15:19:08Z

This patch fixes obvious copy-past error in wake up irq parsing code which leads to the fact that dev_pm_set_wake_irq() will be called with wrong IRQ number when "wakeup" IRQ is not defined in DT. Fixes: 3fffd1283927 ("i2c: allow specifying separate wakeup interrupt in device tree") Signed-off-by: Grygorii Strashko Acked-by: Dmitry Torokhov Signed-off-by: Wolfram Sang Cc: # v4.3

Merge branch 'i2c/for-4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux

2015-11-10T19:58:25Z

Pull i2c updates from Wolfram Sang: - New drivers: UniPhier (with and without FIFO) - some drivers got some bigger rework: ismt, designware, img-scb (rcar had to be reverted because issues were showing up just lately) - ACPI: reworked the device scanning and added support for muxes ... and quite a lot of driver bugfixes and cleanups this time. All files touched outside of the i2c realm have proper acks. * 'i2c/for-4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (70 commits) i2c: rcar: Revert the latest refactoring series i2c: pnx: remove superfluous assignment MAINTAINERS: i2c: drop i2c-pnx maintainer MAINTAINERS: i2c: mark also subdirectories as maintained i2c: cadence: enable driver for ARM64 i2c: i801: Document Intel DNV and Broxton i2c: at91: manage unexpected RXRDY flag when starting a transfer i2c: pnx: Use setup_timer instead of open coding it i2c: add ACPI support for I2C mux ports acpi: add acpi_preset_companion() stub i2c: pxa: Add support for pxa910/988 & new configuration features i2c: au1550: Convert to devm_kzalloc and devm_ioremap_resource i2c-dev: Fix I2C_SLAVE ioctl comment i2c-dev: Fix typo in ioctl name reference i2c: sirf: tune the divider to make i2c bus freq more accurate i2c: imx: Use -ENXIO as error in the NACK case i2c: i801: Add support for Intel Broxton i2c: i801: Add support for Intel DNV i2c: mediatek: add i2c resume support i2c: imx: implement bus recovery ...

i2c: add ACPI support for I2C mux ports

2015-10-25T14:49:46Z

Although I2C mux devices are easily enumerated using ACPI (_HID/_CID or device property compatible string match), enumerating I2C client devices connected through an I2C mux needs a little extra work. This change implements a method for describing an I2C device hierarchy that includes mux devices by using an ACPI Device() for each mux channel along with an _ADR to set the channel number for the device. See Documentation/acpi/i2c-muxes.txt for a simple example. To make this work the ismt, i801, and designware pci/platform devs now share an ACPI companion with their I2C adapter dev similar to how it's done in OF. This is done on the assumption that power management functions will not be called directly on the I2C dev that is sharing the ACPI node. Acked-by: Mika Westerberg Tested-by: Mika Westerberg Signed-off-by: Dustin Byford Signed-off-by: Wolfram Sang