a) rename to 'put' instead of 'release' to match 'get' when obtaining
   the buffer
b) change the argument order to have the buffer as first argument
c) add a new argument telling the function if the message was
   transferred. This allows the function to be used also in cases
   where setting up DMA failed, so the buffer needs to be freed without
   syncing to the message buffer.

Also convert the only user.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

There aren't any users left. Remove this callback from the 2.4 times.
Phew, finally, that took years to reach...
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

There are two drivers already using the SDA hold time setting.
It might be more in the future, thus, make I2C core to parse the setting
for us if provided by firmware.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: NLudovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Some adapters do not support a message length of 0. Add this as a quirk
so drivers don't have to open code it.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Tested-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Removes all locking from i2c_smbus_xfer and renames it to __i2c_smbus_xfer,
then adds a new i2c_smbus_xfer function that simply grabs the lock while
calling the unlocked variant.

This is not perfectly equivalent, since i2c_smbus_xfer was callable from
atomic/irq context if you happened to end up emulating SMBus with an I2C
transfer, and that is no longer the case with this patch. It is unknown
(to me) if anything depends on that quirk, but it seems fragile enough to
simply break those cases and require them to call i2c_transfer directly
instead.

While at it, for consistency rename the 2nd to last argument (size) of
the i2c_smbus_xfer declaration to protocol and remove the surplus extern
marker.
Signed-off-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Some IP cores have an internal 'bus free' logic which may be more
advanced than just checking if SDA is high. Add a separate callback to
get this status. Filling it is optional.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

For bus recovery, we either need to bail out early if we can read SDA or
we need to send STOP after every pulse. Otherwise recovery might be
misinterpreted as an unwanted write. So, require one of those SDA
handling functions to avoid this problem.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The i2c_lock_adapter name is ambiguous since it is unclear if it
refers to the root adapter or the adapter you name in the argument.
The natural interpretation is the adapter you name in the argument,
but there are historical reasons for that not being the case; it
in fact locks the root adapter. Just remove the function and force
users to spell out the I2C_LOCK_ROOT_ADAPTER name to indicate what
is really going on. Also remove i2c_unlock_adapter, of course.

This patch was generated with

git grep -l 'i2c_\(un\)\?lock_adapter' \
| xargs sed -i 's/i2c_\(un\)\?lock_adapter(\([^)]*\))/'\
'i2c_\1lock_bus(\2, I2C_LOCK_ROOT_ADAPTER)/g'

followed by white-space touch-up.
Signed-off-by: NPeter Rosin <peda@axentia.se>
Acked-by: NJonathan Cameron <jonathan.cameron@huawei.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Removes all locking from i2c_smbus_xfer and renames it to __i2c_smbus_xfer,
then adds a new i2c_smbus_xfer function that simply grabs the lock while
calling the unlocked variant.

This is not perfectly equivalent, since i2c_smbus_xfer was callable from
atomic/irq context if you happened to end up emulating SMBus with an I2C
transfer, and that is no longer the case with this patch. It is unknown
(to me) if anything depends on that quirk, but it seems fragile enough to
simply break those cases and require them to call i2c_transfer directly
instead.

While at it, for consistency rename the 2nd to last argument (size) of
the i2c_smbus_xfer declaration to protocol and remove the surplus extern
marker.
Signed-off-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

I3C busses have to know about all I2C devices connected on the I3C bus
to properly initialize the I3C master, and I2C frames can't be sent on
the bus until this initialization is done.

We can't let the I2C core parse the DT and instantiate I2C devices as
part of its i2c_add_adapter() procedure because, when done this way,
I2C devices are directly registered to the device-model and might be
attached to drivers which could in turn start sending frames on the bus,
which won't work since, as said above, the bus is not yet initialized.

Export of_i2c_register_device() in order to let the I3C core parse the
I2C device nodes by itself and initialize the bus.
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The only user of i2c_board_info->archdata is the OF parsing code and it
just pass a zero-initialized object which has the same effect as leaving
->archdata to NULL since the client object is allocated with kzalloc().

Get rid of this useless field.
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Can be used during probe to double check that the probed device is
what is expected.

Loosely based on code from Adrian Fiergolski <adrian.fiergolski@cern.ch>.
Tested-by: NAdrian Fiergolski <adrian.fiergolski@cern.ch>
Reviewed-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NPeter Rosin <peda@axentia.se>

This will be needed when we want to create STOP conditions, too, later.
Create the needed fields and populate them for the GPIO case if the GPIO
is set to output.
Tested-by: NPhil Reid <preid@electromag.com.au>
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

No reason to have them undefined, so let's add them.
Tested-by: NPhil Reid <preid@electromag.com.au>
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

"Used internally" is vague. What it actually means is that those fields
are populated by the core if valid GPIOs are provided. Change the
comments to reflect that.
Tested-by: NPhil Reid <preid@electromag.com.au>
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Use the new helper to create variants of i2c_master_{send|recv} which
mark their buffers as DMA safe.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Those two functions are very similar, the only differences are that one
needs the I2C_M_RD flag for its message while the other one needs the
buffer casted to drop the const. Introduce a generic helper which allows
to specify the flags (also needed later for DMA safe variants of these
calls) and let the casting be done in the inlining functions which are
now calling the new helper function.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

One helper checks if DMA is suitable and optionally creates a bounce
buffer, if not. The other function returns the bounce buffer and makes
sure the data is properly copied back to the message.
Reviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Remove all reference to code related to using integer based ids for
scl/sda gpio for bus recovery. All in tree drivers are now using the
gpio descriptors to specific the required gpios.
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NPhil Reid <preid@electromag.com.au>
Reviewed-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Currently the i2c gpio recovery code uses gpio integer interface
instead of the gpiod. This change switch the core code to use
the gpiod while still retaining compatibility with the gpio integer
interface. This will allow individual driver to be updated and tested
individual to switch to using the gpiod interface.
Reviewed-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NPhil Reid <preid@electromag.com.au>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Using the macro IS_ENABLED to check the option CONFIG_I2C=(y|m) makes
the code nicer.  No functional change.
Signed-off-by: NStefan Lengfeld <contact@stefanchrist.eu>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

For devices not instantiated through ACPI the i2c-client's device-name
gets set to <busnr>-<addr> by default, e.g. "0-0022" this means that
the device-name is dependent on the order in which the i2c-busses are
enumerated.

In some cases having a predictable constant device-name is desirable,
for example on non device-tree platforms the link between a regulator
and its consumers is specified by the platform code by setting
regulator_init_data.consumers. This array identifies the regulator's
consumers by dev_name and supply(-name). Which requires a constant
dev_name.

This commit adds a dev_name field to i2c_board_info allowing
platform code to set a contstant dev_name so that the device can
be identified by its dev_name in other platform code.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: Mark Brown <broonie@kernel.org> (live at ELCE17)
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> (live at ELCE17)
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Hopefully making clear that it is not needed for new drivers.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Drivers would like to call i2c_detect_slave_mode() even if !I2C_SLAVE.
Give them what they want to,

Otherwise kernel will not compile:
drivers/i2c/busses/i2c-designware-platdrv.c: In function ‘dw_i2c_plat_probe’:
drivers/i2c/busses/i2c-designware-platdrv.c:331:6: error: implicit declaration of function ‘i2c_detect_slave_mode’ [-Werror=implicit-function-declaration]
  if (i2c_detect_slave_mode(&pdev->dev))
      ^~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors

Fixes: 6e38cf3b ("i2c: designware: Let slave adapter support be optional")
Reported-by: NAbdul Haleem <abdhalee@linux.vnet.ibm.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

By default the i2c-core will try to get an irq with index 0 on ACPI / of
instantiated devices. This is troublesome on some ACPI systems where the
irq info at index 0 in the CRS table may contain nonsense and/or point
to an irqchip for which there is no Linux driver.

If this happens then before this commit the driver's probe method would
never get called because i2c_device_probe will try to get an irq by
calling acpi_dev_gpio_irq_get which will always return -EPROBE in this
case, as it waits for a matching irqchip driver to load. Thus causing
the driver to not get a chance to bind.

This commit adds a new disable_i2c_core_irq_mapping flag to struct
i2c_driver which a driver can set to tell the core to skip irq mapping.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

By default the i2c subsys creates an i2c-client for the first I2cSerialBus
resource of an acpi_device, but some acpi_devices have multiple
I2cSerialBus resources and we may want to instantiate i2c-clients for
the others.

This commit adds a new i2c_acpi_new_device function which can be used to
create an i2c-client for any I2cSerialBus resource of an acpi_device.

Note that the other resources may even be on a different i2c bus, so just
retrieving the client address is not enough.

Here is an example DSDT excerpt from such a device:

Device (WIDR)
{
    Name (_HID, "INT33FE" /* XPOWER Battery Device */)
    Name (_CID, "INT33FE" /* XPOWER Battery Device */)
    Name (_DDN, "WC PMIC Battery Device")
<snip>
    Name (RBUF, ResourceTemplate ()
    {
        I2cSerialBusV2 (0x005E, ControllerInitiated, 0x000186A0,
            AddressingMode7Bit, "\\_SB.PCI0.I2C7",
            0x00, ResourceConsumer, , Exclusive,
            )
        I2cSerialBusV2 (0x0036, ControllerInitiated, 0x000186A0,
            AddressingMode7Bit, "\\_SB.PCI0.I2C1",
            0x00, ResourceConsumer, , Exclusive,
            )
        I2cSerialBusV2 (0x0022, ControllerInitiated, 0x00061A80,
            AddressingMode7Bit, "\\_SB.PCI0.I2C1",
            0x00, ResourceConsumer, , Exclusive,
            )
        I2cSerialBusV2 (0x0054, ControllerInitiated, 0x00061A80,
            AddressingMode7Bit, "\\_SB.PCI0.I2C1",
            0x00, ResourceConsumer, , Exclusive,
            )
        GpioInt (Level, ActiveLow, Exclusive, PullNone, 0x0000,
            "\\_SB.PCI0.I2C7.PMI5", 0x00, ResourceConsumer, ,
            )
            {   // Pin list
        0x0012
            }
        GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullNone, 0x0000,
            "\\_SB.GPO1", 0x00, ResourceConsumer, ,
            )
            {   // Pin list
        0x0005
            }
        GpioInt (Level, ActiveLow, Exclusive, PullNone, 0x0000,
            "\\_SB.PCI0.I2C7.PMI5", 0x00, ResourceConsumer, ,
            )
            {   // Pin list
        0x0013
            }
    })
    Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
    {
        Return (RBUF) /* \_SB_.PCI0.I2C7.WIDR.RBUF */
    }
<snip>
}
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Simple integer for interrupt number is not expressive enough, as it does
not convey interrupt trigger type that should be used. Let's allow
attaching array of resources to the board info and have i2c core parse
first IRQ resource and set up interrupt trigger as needed.
Reviewed-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

i2c bus has 2 different types of device belonging to the same bus and
bus notifiers use device type to distinguish between adapters and clients.
Previously we only had i2c_adapter_type exported, which made code wanting
to work with i2c_client devices test for type not equal to adapter type.
This unfortunately is not safe if we ever add another type to the bus,
so let's export i2c_client_type as well.
Reviewed-by: NJean Delvare <jdelvare@suse.de>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Fix up missing #includes in other places that rely on sched.h doing that for them.
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NIngo Molnar <mingo@kernel.org>

With many drivers converting to using generic device properties, it is
useful to provide array of device properties when instantiating new i2c
client via i2c_board_info and have them automatically added to the device
in question.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This function has the purpose of mode detection by checking the
device nodes for a reg matching with the I2C_OWN_SLAVE_ADDREESS flag.
Currently only checks using OF functions (ACPI slave not supported yet).
Signed-off-by: NLuis Oliveira <lolivei@synopsys.com>
Suggested-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Falling back unconditionally to HostNotify as primary client's interrupt
breaks some drivers which alter their functionality depending on whether
interrupt is present or not, so let's introduce a board flag telling I2C
core explicitly if we want wired interrupt or HostNotify-based one:
I2C_CLIENT_HOST_NOTIFY.

For DT-based systems we introduce "host-notify" property that we convert
to I2C_CLIENT_HOST_NOTIFY board flag.
Tested-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The current SMBus Host Notify implementation relies on .alert() to
relay its notifications. However, the use cases where SMBus Host
Notify is needed currently is to signal data ready on touchpads.

This is closer to an IRQ than a custom API through .alert().
Given that the 2 touchpad manufacturers (Synaptics and Elan) that
use SMBus Host Notify don't put any data in the SMBus payload, the
concept actually matches one to one.

Benefits are multiple:
- simpler code and API: the client will just have an IRQ, and
  nothing needs to be added in the adapter beside internally
  enabling it.
- no more specific workqueue, the threading is handled by IRQ core
  directly (when required)
- no more races when removing the device (the drivers are already
  required to disable irq on remove)
- simpler handling for drivers: use plain regular IRQs
- no more dependency on i2c-smbus for i2c-i801 (and any other adapter)
- the IRQ domain is created automatically when the adapter exports
  the Host Notify capability
- the IRQ are assign only if ACPI, OF and the caller did not assign
  one already
- the domain is automatically destroyed on remove
- fewer lines of code (minus 20, yeah!)
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This will aid the seamless removal of the current probe()'s, more
commonly unused than used second parameter.  Most I2C drivers can
simply switch over to the new interface, others which have DT
support can use its own matching instead and others can call
i2c_match_id() themselves.  This brings I2C's device probe method
into line with other similar interfaces in the kernel and prevents
the requirement to pass an i2c_device_id table.
Suggested-by: NGrant Likely <grant.likely@linaro.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
[Kieran: fix rebase conflicts and adapt for dev_pm_domain_{attach,detach}]
Tested-by: NKieran Bingham <kieran@bingham.xyz>
Reviewed-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Tested-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NKieran Bingham <kieran@bingham.xyz>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

When there was no other way to match a I2C device to driver i2c_match_id()
was exclusively used.  However, now there are other types of tables which
are commonly supplied, matching on an i2c_device_id table is used less
frequently.  Instead of _always_ calling i2c_match_id() from within the
framework, we only need to do so from drivers which have no other way of
matching.  This patch makes i2c_match_id() available to the aforementioned
device drivers.
Acked-by: NGrant Likely <grant.likely@linaro.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Tested-by: NKieran Bingham <kieran@bingham.xyz>
Reviewed-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Tested-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NKieran Bingham <kieran@bingham.xyz>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This function provides a single call for all I2C devices which need to
match firstly using traditional OF means i.e by of_node, then if that
fails we attempt to match using the supplied I2C client name with a
list of supplied compatible strings with the '<vendor>,' string
removed.  The latter is required due to the unruly naming conventions
used currently by I2C devices.
Acked-by: NGrant Likely <grant.likely@linaro.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
[Kieran: Fix static inline usage on !CONFIG_OF]
Tested-by: NKieran Bingham <kieran@bingham.xyz>
Reviewed-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Tested-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NKieran Bingham <kieran@bingham.xyz>
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 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>

ACPI 5 specification doesn't have property for the I2C bus speed but
I2cSerialBus resource descriptor which define each controller-slave
connection define the maximum speed supported by that connection.

Thus finding the maximum safe speed for the bus is to walk through all
I2cSerialBus resources that are associated to I2C controller and use the
speed of slowest connection.

Add function i2c_acpi_find_bus_speed() to the i2c-core that adapter
drivers can call prior registering itself to core.

This implies two-step walk through the I2cSerialBus resources: call to
i2c_acpi_find_bus_speed() does the first scan and finds the safe bus
speed that adapter drivers can set up. Adapter driver registration does
the second scan when i2c-core creates the I2C slaves by calling the
i2c_acpi_register_devices(). In that way the bus speed is set in case
slave device probe gets called during registration and does communication.

Previous version commit 55d38d06 ("i2c: core: Add function for finding
the bus speed from ACPI") got reverted due merge conflicts from
commit 525e6fab ("i2c / ACPI: add support for ACPI reconfigure
notifications").

This version is a bit bigger than previous version but is still sharing
the lowest and complicated part of I2cSerialBus lookup routines with the
existing code.
Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This unifies usage with i2c_lock_bus and i2c_unlock_bus, and paves the
way for the next patch which looks a bit saner with this preparatory
work taken care of beforehand.
Signed-off-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>