sparse  rightfully said:

drivers/gpio/gpio-pca953x.c:771:45: warning: symbol 'id' shadows an earlier one
drivers/gpio/gpio-pca953x.c:742:36: originally declared here

So, name them explicitly 'i2c_id' and 'acpi_id' to avoid any confusion.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Intel Kaby Lake PCH-H has the same legacy SMBus host controller than Intel
Sunrisepoint PCH. It also has same iTCO watchdog on the bus.

Add Kaby Lake PCH-H PCI ID to the list of supported devices.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

If an I2C GPIO multiplexer is driven by a GPIO provided by an expander
when there's a second expander using the same device driver on one of
the I2C bus segments, lockdep prints a deadlock warning when trying to
set the direction or the value of the GPIOs provided by the second
expander.

The below diagram presents the setup:

                                               - - - - -
 -------             ---------  Bus segment 1 |         |
|       |           |         |---------------  Devices
|       | SCL/SDA   |         |               |         |
| Linux |-----------| I2C MUX |                - - - - -
|       |    |      |         | Bus segment 2
|       |    |      |         |-------------------
 -------     |       ---------                    |
             |           |                    - - - - -
        ------------     | MUX GPIO          |         |
       |            |    |                     Devices
       |    GPIO    |    |                   |         |
       | Expander 1 |----                     - - - - -
       |            |                             |
        ------------                              | SCL/SDA
                                                  |
                                             ------------
                                            |            |
                                            |    GPIO    |
                                            | Expander 2 |
                                            |            |
                                             ------------

The reason for lockdep warning is that we take the chip->i2c_lock in
pca953x_gpio_set_value() or pca953x_gpio_direction_output() and then
come right back to pca953x_gpio_set_value() when the GPIO mux kicks
in. The locks actually protect different expanders, but for lockdep
both are of the same class, so it says:

  Possible unsafe locking scenario:

        CPU0
        ----
   lock(&chip->i2c_lock);
   lock(&chip->i2c_lock);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

In order to get rid of the warning, retrieve the adapter nesting depth
and use it as lockdep subclass for chip->i2c_lock.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: NPeter Rosin <peda@axentia.se>
Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This routine is only used together with lockdep for nested locking.
The number of lock subclasses is limited to 8 as defined in lockdep.h

Emit a warning if the adapter depth exceeds the maximum number of
lockdep subclasses.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: NPeter Rosin <peda@axentia.se>
Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This define is needed by i2c_adapter_depth() to detect if we don't
exceed the maximum number of lock subclasses. Make it visible even
if lockdep is disabled.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: NPeter Rosin <peda@axentia.se>
Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

For crazy setups in which an i2c gpio expander is behind an i2c gpio
multiplexer controlled by a gpio provided a second expander using the
same device driver we need to explicitly tell lockdep how to handle
nested locking.

Export i2c_adapter_depth() as public API to be reused outside of i2c
core code.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: NPeter Rosin <peda@axentia.se>
Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This patch fixs the following warning:
drivers/i2c/busses/i2c-rk3x.c: In function 'rk3x_i2c_v1_calc_timings':
drivers/i2c/busses/i2c-rk3x.c:745:41: warning: variable 'min_total_ns' set but not used [-Wunused-but-set-variable]
Reported-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NDavid Wu <david.wu@rock-chips.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This patch fixes the following sparse warning:
drivers/i2c/busses/i2c-rk3x.c:888:17: warning: cast truncates bits from constant value (ffffffffff00 becomes ffffff00)
Reported-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NDavid Wu <david.wu@rock-chips.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

When enumerating I2C devices connected to an I2C adapter we scan the whole
namespace (as it is possible to have devices anywhere in that namespace,
not just below the I2C adapter device) and add each found device to the I2C
bus in question.

Now after commit 525e6fab ("i2c / ACPI: add support for ACPI
reconfigure notifications") checking of the adapter handle to the one found
in the I2cSerialBus() resource was moved to happen after resources of the
I2C device has been parsed. This means that if the I2cSerialBus() resource
points to an adapter that does not exists in the system we still parse
those resources. This is problematic in particular because
acpi_dev_resource_interrupt() tries to configure GSI if the device also has
an Interrupt() resource. Failing to do that results errrors like this to be
printed on the console:

  [   10.409490] ERROR: Unable to locate IOAPIC for GSI 37

To fix this we pass the I2C adapter to i2c_acpi_get_info() and make sure
the handle matches the one in the I2cSerialBus() resource before doing
anything else to the device.
Reported-by: NNicolai Stange <nicstange@gmail.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NNicolai Stange <nicstange@gmail.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

In case the high-level controller (HLC) is used the status code is
reported at a different location. Check that location after HLC
write operations if the ready bit is not set and return an appropriate
error code instead of always returning -EAGAIN.
Signed-off-by: NJan Glauber <jglauber@cavium.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Due to a bug in the ThunderX I2C hardware sending STOP during
a recovery attempt could lock up the hardware. To work around
this problem do not send STOP at the beginning of the recovery
but use the override registers to bring the TWSI including
the high-level controller out of the bad state.
Signed-off-by: NDmitry Bazhenov <dmitry.bazhenov@auriga.com>
Signed-off-by: NJan Glauber <jglauber@cavium.com>
[Changed commit message]
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The set SCL recovery function unconditionally pulls the SCL line low.
Only pull SCL line low according to val parameter.
Signed-off-by: NDmitry Bazhenov <dmitry.bazhenov@auriga.com>
Signed-off-by: NJan Glauber <jglauber@cavium.com>
[Changed commit message]
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Same as r8a7795.
Signed-off-by: NUlrich Hecht <ulrich.hecht+renesas@gmail.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Since commit 1c4b6c3b ("i2c: imx: implement bus recovery") the
driver starts to use gpio/pinctrl to support optional bus recovery
feature.  But pinctrl is not always usable.  There are platforms such
as ls1021a and ls1043a that don't support pinctrl, and it could just
be broken due to old/broken device tree.  The patch makes it really
optional that the probe function won't bailout on pinctrl problems
instead it just disables bus recovery and prints out notification when
there is problem with pinctrl.  Since pinctrl is only used by bus
recovery in this driver, move pinctrl initialization into bus recovery
init function to prevent confusion.
Signed-off-by: NLi Yang <leoyang.li@nxp.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
Acked-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Currently, the adapter is set to the master mode at the first use.
Since then, it is kept in the slave mode, so unexpected glitch
signals on the I2C lines may cause the adapter into insane state.
Setting it to the master mode along with initialization solves the
problem.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reported-by: NAkio Noda <noda.akio@socionext.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

If clk_prepare_enable() fails, clk_disable_unprepare() is called in
the failure path, where the enable_count is still zero, so it hits
WARN_ON(core->enable_count == 0) in the clk_core_disable().

To fix this, make the clock setting more linear in the probe function
so that it can exploit "goto err" in case of error.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

If clk_prepare_enable() fails, clk_disable_unprepare() is called in
the failure path, where the enable_count is still zero, so it hits
WARN_ON(core->enable_count == 0) in the clk_core_disable().

To fix this, make the clock setting more linear in the probe function
so that it can exploit "goto err" in case of error.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Fix the following warnings reported by coccinelle for the Tegra I2C
driver.

drivers/i2c/busses/i2c-tegra.c:513:2-23: WARNING: Assignment of bool to 0/1
drivers/i2c/busses/i2c-tegra.c:539:3-24: WARNING: Assignment of bool to 0/1
Reported-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

To summarize the issue observed in error cases:

SW Flow: For i2c message transfer, packet header and data payload is
posted and then required error/packet completion interrupts are enabled
later.

HW flow: HW process the packet just after packet header is posted, if
ARB lost/NACK error occurs (SW will not handle immediately when error
happens as error interrupts are not enabled at this point). HW assumes
error is acknowledged and clears current data in FIFO, But SW here posts
the remaining data payload which still stays in FIFO as stale data
(data without packet header).

Now once the interrupts are enabled, SW handles ARB lost/NACK error by
clearing the ARB lost/NACK interrupt. Now HW assumes that SW attended
the error and will parse/process stale data (data without packet header)
present in FIFO which causes invalid NACK errors.

Fix: Enable the error interrupts before posting the packet into FIFO
which make sure HW to not clear the fifo. Also disable the packet mode
before acknowledging errors (ARB lost/NACK error) to not process any
stale data. As error interrupts are enabled before posting the packet
header use spinlock to avoid preempting.
Signed-off-by: NShardar Shariff Md <smohammed@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Use readl_poll_timeout_atomic() function as *wait_for_config_load()
function can be called from interrupt context.
Signed-off-by: NShardar Shariff Md <smohammed@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Define separate function for configuration load register handling
to make it use by different functions later.
Signed-off-by: NShardar Shariff Md <smohammed@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

During i2c controller initialization, when fifo flush fails return error
instead of returning the error during exit.
Signed-off-by: NShardar Shariff Md <smohammed@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

After CONFIG_LOAD register is programmed instead of explicitly waiting
for timeout, use readl_poll_timeout() to check for register value to get
updated or wait till timeout.
Signed-off-by: NShardar Shariff Md <smohammed@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

"i2c-sh_mobile" is used on sh7343, sh7366, sh7722, sh7723, and sh7724
only. As all of the above select ARCH_SHMOBILE, restrict its driver
dependencies from SUPERH to ARCH_SHMOBILE.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

It's better to have strings in the code like they appeared in the output.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This makes it trivial to constify them, so do that.
Signed-off-by: NPeter Rosin <peda@axentia.se>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

On Tegra124/132 the pins for I2C6 are shared with the Display Port AUX
(DPAUX) channel and on Tegra210 the pins for I2C4 and I2C6 are shared
with DPAUX1 and DPAUX0, respectively. The multiplexing of the pins is
handled by a register in the DPAUX and so the Tegra DPAUX driver has
been updated to register a pinctrl device for managing these pins.

The pins for these particular I2C devices are bound to the I2C device
prior to probing. However, these I2C devices are in a different power
partition to the DPAUX devices that own the pins. Hence, it is desirable
to place the pins in the 'idle' state and allow the DPAUX power
partition to switch off, when these I2C devices is not in use.
Therefore, add calls to place the I2C pins in the 'default' and 'idle'
states when the I2C device is runtime resumed and suspended,
respectively.

Please note that the pinctrl functions that set the state of the pins
check to see if the devices has pins associated and will return zero
if they do not. Therefore, it is safe to call these pinctrl functions
even for I2C devices that do not have any pins associated.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Acked-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Update the Tegra I2C driver to use runtime PM and move the code in the
tegra_i2c_clock_enable/disable() functions to the PM runtime resume and
suspend callbacks, respectively.

Note that given that CONFIG_PM is not mandatory for Tegra, if CONFIG_PM
is not enabled and so runtime PM is not enabled, ensure that the I2C
clocks are turned on during probe and kept on by calling the resume
callback directly.

In the function tegra_i2c_init(), the variable 'err' does not need to be
initialised to zero in tegra_i2c_init() because it is initialised when
pm_runtime_get_sync() is called. Furthermore, to ensure we only return 0
from tegra_i2c_init(), it is necessary to re-initialise 'err' to 0 after
a successful call to pm_runtime_get_sync() because it can return a
positive value on success. However, alternatively re-initialise 'err' by
using the return value of the function tegra_i2c_flush_fifos() because
it can only be 0 or -ETIMEDOUT.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Acked-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The I2C adapter is unlocked regardless of whether the tegra_i2c_init()
called during the resume is successful or not. However, if the
tegra_i2c_init() is not successful, then ->is_suspended is not set to
false. Simplify the resume code by only setting ->is_suspended to false
if tegra_i2c_init() is successful and return the error code from
tegra_i2c_init().
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Acked-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

All Tegra I2C devices have the name "Tegra I2C adapter" which is not
very useful when viewing the I2C adapter names via the sysfs. Therefore,
use the device name, which is unique for each I2C device, instead.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Acked-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Tegra has only supported device-tree for platform/board configuration
for quite some time now and so simplify the Tegra I2C driver by dropping
code for non device-tree platforms/boards.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Add missing new line characters for the various error messages.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Acked-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Checkpatch warns about missing blank lines after declarations in the
Tegra I2C driver and so fix these.

Note that the initialisation of 'val' to zero in tegra_dvc_init() is
unnecessary and so remove this.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Checkpatch warns about spacing around the '<<' operator in the Tegra I2C
driver and so fix these by converting the bit definitions that are using
this operator to use the BIT macro.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Checkpatch warns about some lines over 80 characters in the Tegra I2C
driver and so fix these.

While we are at it, prefix the second instance of "STOP condition" in
the comment with a "the".
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Disabling the adapter after each transfer adds additional delays
for each I2C transfer. Even if we don't wait for it to be disabled
anymore, on next transfer we will need to if we have several transfers
in a row.

Now during the transfer init we check if IC_TAR can be changed
dynamically, the status register for no activity and TX buffer being
empty. In this case we don't need to disable it

When a transfer fails the adapter will still be disabled - this is a
conservative approach. When transfers succeed, the adapter is left
enabled and it's configured so to disable interrupts.

Alternating register reads on 2 slaves:
perf stat -r4 chrt -f 10 ./i2c-test /dev/i2c-1 25000 0x40 0x6 0x1e 0x00

Before:
	8.638705161 seconds time elapsed                  ( +-  5.90% )
After:
	7.516821591 seconds time elapsed                  ( +-  0.11% )
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Acked-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Tested-by: NChristian Ruppert <christian.ruppert@alitech.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This adapter can be synthesized with dynamic tar update enabled or disabled.
When enabled it is not necessary to disable the adapter to change the slave
address in some situations, which saves some time per transaction.

There is no direct register to know if this feature is enabled but we can do it
indirectly by writing to the 10BIT_ADDR field in IC_CON: this field is
read only when dynamic tar update is enabled.
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Acked-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Tested-by: NChristian Ruppert <christian.ruppert@alitech.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

These are used in 2 places and will be needed in more.
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Acked-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Tested-by: NChristian Ruppert <christian.ruppert@alitech.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>