linux-toradex.git/drivers/i2c/i2c-core.c, branch v3.11

PM / Runtime: Rework the "runtime idle" helper routine

2013-06-03T19:49:52+00:00

The "runtime idle" helper routine, rpm_idle(), currently ignores
return values from .runtime_idle() callbacks executed by it.
However, it turns out that many subsystems use
pm_generic_runtime_idle() which checks the return value of the
driver's callback and executes pm_runtime_suspend() for the device
unless that value is not 0.  If that logic is moved to rpm_idle()
instead, pm_generic_runtime_idle() can be dropped and its users
will not need any .runtime_idle() callbacks any more.

Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
ata_port_runtime_idle(), respectively, as well as a few drivers'
ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has
been returned by the .runtime_idle() callback executed by it.

To reduce overall code bloat, make the changes described above.

Tested-by: Mika Westerberg 
Tested-by: Kevin Hilman 
Signed-off-by: Rafael J. Wysocki 
Acked-by: Kevin Hilman 
Reviewed-by: Ulf Hansson 
Acked-by: Alan Stern

i2c: suppress lockdep warning on delete_device

2013-05-17T20:49:45+00:00

i2c: suppress lockdep warning on delete_device

Since commit 846f99749ab68bbc7f75c74fec305de675b1a1bf the following lockdep
warning is thrown in case i2c device is removed (via delete_device sysfs
attribute) which contains subdevices (e.g. i2c multiplexer):

=============================================
[ INFO: possible recursive locking detected ]
3.8.7-0-sampleversion-fct #8 Tainted: G           O
---------------------------------------------
bash/3743 is trying to acquire lock:
  (s_active#110){++++.+}, at: [] sysfs_hash_and_remove+0x58/0xc8

but task is already holding lock:
  (s_active#110){++++.+}, at: [] sysfs_write_file+0xc8/0x208

other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(s_active#110);
   lock(s_active#110);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

4 locks held by bash/3743:
  #0:  (&buffer->mutex){+.+.+.}, at: [] sysfs_write_file+0x4c/0x208
  #1:  (s_active#110){++++.+}, at: [] sysfs_write_file+0xc8/0x208
  #2:  (&adap->userspace_clients_lock/1){+.+.+.}, at: [] i2c_sysfs_delete_device+0x90/0x238
  #3:  (&__lockdep_no_validate__){......}, at: [] device_release_driver+0x24/0x48

stack backtrace:
Call Trace:
[] dump_stack+0x8/0x34
[] __lock_acquire+0x161c/0x2110
[] lock_acquire+0x4c/0x70
[] sysfs_addrm_finish+0x19c/0x1e0
[] sysfs_hash_and_remove+0x58/0xc8
[] sysfs_remove_group+0x64/0x148
[] device_remove_attrs+0x9c/0x1a8
[] device_del+0x104/0x1d8
[] device_unregister+0x28/0x70
[] i2c_del_adapter+0x1cc/0x328
[] i2c_del_mux_adapter+0x14/0x38
[] pca954x_remove+0x90/0xe0 [pca954x]
[] i2c_device_remove+0x80/0xe8
[] __device_release_driver+0x74/0xf8
[] device_release_driver+0x2c/0x48
[] bus_remove_device+0x13c/0x1d8
[] device_del+0x10c/0x1d8
[] device_unregister+0x28/0x70
[] i2c_sysfs_delete_device+0x180/0x238
[] sysfs_write_file+0xe4/0x208
[] vfs_write+0xbc/0x160
[] SyS_write+0x54/0xd8
[] handle_sys64+0x44/0x64

The problem is already known for USB and PCI subsystems. The reason is that
delete_device attribute is defined statically in i2c-core.c and used for all
devices in i2c subsystem.

Discussion of original USB problem:
http://lkml.indiana.edu/hypermail/linux/kernel/1204.3/01160.html

Commit 356c05d58af05d582e634b54b40050c73609617b introduced new macro to suppress
lockdep warnings for this special case and included workaround for USB code.

LKML discussion of the workaround:
http://lkml.indiana.edu/hypermail/linux/kernel/1205.1/03634.html

As i2c case is in principle the same, the same workaround could be used here.

Signed-off-by: Alexander Sverdlin 
Acked-by: Alan Stern 
Cc: Eric W. Biederman 
Cc: Tejun Heo 
Cc: Peter Zijlstra 
Cc: Greg Kroah-Hartman 
Signed-off-by: Wolfram Sang

i2c: remove CONFIG_HOTPLUG ifdefs

2013-04-09T09:57:55+00:00

CONFIG_HOTPLUG is going away as an option, cleanup CONFIG_HOTPLUG
ifdefs in i2c files.

Signed-off-by: Yijing Wang 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Wolfram Sang

i2c: Make return type of i2c_del_adapter() void

2013-04-02T05:06:17+00:00

i2c_del_adapter() is usually called from a drivers remove callback. The Linux
device driver model does not allow the remove callback to fail and all resources
allocated in the probe callback need to be freed, as well as all resources which
have been provided to the rest of the kernel(for example a I2C adapter) need to
be revoked. So any function revoking such resources isn't allowed to fail
either. i2c_del_adapter() adheres to this requirement and will never fail. But
i2c_del_adapter()'s return type is int, which may cause driver authors to think
that it can fail. This led to code constructs like:

	ret = i2c_del_adapter(...);
	BUG_ON(ret);

Since i2c_del_adapter() always returns 0 the BUG_ON is never hit and essentially
becomes dead code, which means it can be removed. Making the return type of
i2c_del_adapter() void makes it explicit that the function will never fail and
should prevent constructs like the above from re-appearing in the kernel code.

All callers of i2c_del_adapter() have already been updated in a previous patch
to ignore the return value, so the conversion of the return type from int to
void can be done without causing any build failures.

Signed-off-by: Lars-Peter Clausen 
Reviewed-by: Jean Delvare 
Signed-off-by: Wolfram Sang

i2c: i2c_del_adapter: Don't treat removing a non-registered adapter as error

2013-04-02T05:03:37+00:00

Currently i2c_del_adapter() returns -EINVAL when it gets an adapter which is not
registered. But none of the users of i2c_del_adapter() depend on this behavior,
so for the sake of being able to sanitize the return type of i2c_del_adapter
argue, that the purpose of i2c_del_adapter() is to remove an I2C adapter from
the system. If the adapter is not registered in the first place this becomes a
no-op. So we can return success without having to do anything.

Signed-off-by: Lars-Peter Clausen 
Reviewed-by: Jean Delvare 
Signed-off-by: Wolfram Sang

i2c: Remove detach_adapter

2013-04-02T05:03:28+00:00

The detach_adapter callback has been deprecated for quite some time and has no
user left. Keeping it alive blocks other cleanups, so remove it.

Signed-off-by: Lars-Peter Clausen 
Reviewed-by: Jean Delvare 
Signed-off-by: Wolfram Sang

i2c: Add bus recovery infrastructure

2013-03-24T09:30:54+00:00

Add i2c bus recovery infrastructure to i2c adapters as specified in the i2c
protocol Rev. 03 section 3.1.16 titled "Bus clear".

http://www.nxp.com/documents/user_manual/UM10204.pdf

Sometimes during operation i2c bus hangs and we need to give dummy clocks to
slave device to start the transfer again. Now we may have capability in the bus
controller to generate these clocks or platform may have gpio pins which can be
toggled to generate dummy clocks. This patch supports both.

This patch also adds in generic bus recovery routines gpio or scl line based
which can be used by bus controller. In addition controller driver may provide
its own version of the bus recovery routine.

This doesn't support multi-master recovery for now.

Signed-off-by: Viresh Kumar 
[wsa: changed gpio type to int and minor reformatting]
Signed-off-by: Wolfram Sang

i2c: core: Pick i2c bus number from dt alias if present

2013-03-24T09:30:53+00:00

This allows you to get the equivalent functionality of
i2c_add_numbered_adapter() with all data in the device tree and no
special case code in your driver.  This is a common device tree
technique.

For quick reference, the FDT syntax for using an alias to provide an
ID looks like:
  aliases {
    i2c0 = &i2c_0;
    i2c1 = &i2c_1;
  };

Signed-off-by: Doug Anderson 
[wsa: removed one check from static function. We know our callers]
Signed-off-by: Wolfram Sang

idr: remove MAX_IDR_MASK and move left MAX_IDR_* into idr.c

2013-02-28T03:10:20+00:00

MAX_IDR_MASK is another weirdness in the idr interface.  As idr covers
whole positive integer range, it's defined as 0x7fffffff or INT_MAX.

Its usage in idr_find(), idr_replace() and idr_remove() is bizarre.
They basically mask off the sign bit and operate on the rest, so if
the caller, by accident, passes in a negative number, the sign bit
will be masked off and the remaining part will be used as if that was
the input, which is worse than crashing.

The constant is visible in idr.h and there are several users in the
kernel.

* drivers/i2c/i2c-core.c:i2c_add_numbered_adapter()

  Basically used to test if adap->nr is a negative number which isn't
  -1 and returns -EINVAL if so.  idr_alloc() already has negative
  @start checking (w/ WARN_ON_ONCE), so this can go away.

* drivers/infiniband/core/cm.c:cm_alloc_id()
  drivers/infiniband/hw/mlx4/cm.c:id_map_alloc()

  Used to wrap cyclic @start.  Can be replaced with max(next, 0).
  Note that this type of cyclic allocation using idr is buggy.  These
  are prone to spurious -ENOSPC failure after the first wraparound.

* fs/super.c:get_anon_bdev()

  The ID allocated from ida is masked off before being tested whether
  it's inside valid range.  ida allocated ID can never be a negative
  number and the masking is unnecessary.

Update idr_*() functions to fail with -EINVAL when negative @id is
specified and update other MAX_IDR_MASK users as described above.

This leaves MAX_IDR_MASK without any user, remove it and relocate
other MAX_IDR_* constants to lib/idr.c.

Signed-off-by: Tejun Heo 
Cc: Jean Delvare 
Cc: Roland Dreier 
Cc: Sean Hefty 
Cc: Hal Rosenstock 
Cc: "Marciniszyn, Mike" 
Cc: Jack Morgenstein 
Cc: Or Gerlitz 
Cc: Al Viro 
Acked-by: Wolfram Sang 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

i2c: convert to idr_alloc()

2013-02-28T03:10:16+00:00

Convert to the much saner new idr interface.

Signed-off-by: Tejun Heo 
Cc: Jean Delvare 
Cc: Wolfram Sang 
Tested-by: Mark Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds