After discovering that a lot of i2c-drivers leave the pointer to their
clientdata dangling, it was decided to let the core handle this issue.
It is assumed that the core may access the private data after remove()
as there are no guarantees for the lifetime of such pointers anyhow (see
thread starting at http://lkml.org/lkml/2010/3/21/68)
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

i2c_master_send & i2c_master_recv do not support more than 64 kb
transfer, since msg.len is u16.
Signed-off-by: NZhangfei Gao <zgao6@marvell.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Allow I2C drivers to make use of the runtime PM framework by adding
bus implementations of the runtime PM operations. These simply
immediately suspend when the device is idle. The runtime PM framework
provides drivers with off the shelf refcounts for enables and sysfs
control for managing runtime suspend from userspace so is useful even
without meaningful input from the bus.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

dev_dbg outputs dev_name, which is released with device_unregister. This bug
resulted in output like this:

i2c Xy2�0: adapter [SMBus I801 adapter at 1880] unregistered

The right output would be:
i2c i2c-0: adapter [SMBus I801 adapter at 1880] unregistered
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

The C99 specification states in section 6.11.5:

The placement of a storage-class specifier other than at the beginning
of the declaration specifiers in a declaration is an obsolescent
feature.
Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Struct dev_pm_ops is not configured in current i2c bus type. i2c drivers
only depends on suspend/resume entries in struct dev_pm_ops are not
informed of PM suspend and resume events by i2c framework.
Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Struct i2c_client_address_data only contains one field at this point,
which makes its usefulness questionable. Get rid of it and pass simple
address lists around instead.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Tested-by: NWolfram Sang <w.sang@pengutronix.de>

The "kind" parameter always has value -1, and nobody is using it any
longer, so we can remove it.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Tested-by: NWolfram Sang <w.sang@pengutronix.de>

Functions i2c_do_add_adapter() and __attach_adapter() do essentially
the same thing, differing only in how the parameters are passed. Same
for i2c_do_add_adapter() and __detach_adapter(). Introduce wrappers to
normalize the parameters, so that we do not have to duplicate the
code.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>

The kind parameter of i2c_detect_address() always has value -1, so we
can get rid of it.

Next step is to update all i2c detect callback functions to get rid of
this now useless parameter.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

The legacy probe and force module parameters are obsolete now, the
same can be achieved using the new_device sysfs interface, which is
both more flexible and cheaper (it is implemented by i2c-core rather
than replicated in every driver module.)

The legacy ignore module parameters can be dropped as well. Ignoring
can be done by instantiating a "dummy" device at the problematic
address.

This is the first step of a huge cleanup to i2c-core's i2c_detect
function, i2c.h's I2C_CLIENT_INSMOD* macros, and all drivers that made
use of them.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Low priority thread holding the i2c bus mutex could block higher
priority threads to access the bus resulting in unacceptable
latencies. Change the mutex type to rt_mutex preventing priority
inversion.
Tested-by: NPeter Ujfalusi <peter.ujfalusi@nokia.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@nokia.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Fix userspace_device list corruption. The corruption was caused by
clients not being removed when adapters with such clients were
themselves removed. Something like the following would trigger it
(assuming i2c-stub gets adapter number 3):

# modprobe i2c-stub chip_addr=0x50
# echo 24c08 0x50 > /sys/bus/i2c/devices/i2c-3/new_device 
# rmmod i2c-stub
# modprobe i2c-stub chip_addr=0x50
# echo 24c08 0x50 > /sys/bus/i2c/devices/i2c-3/new_device 

For the records, the stack trace in the kernel logs look like this:

kernel: WARNING: at lib/list_debug.c:30 __list_add+0x8b/0x90()
kernel: Hardware name: (...)
kernel: list_add corruption. prev->next should be next (c137fc84), but was (null). (prev=f57111b8).
kernel: Modules linked in: (...)
kernel: Pid: 4669, comm: bash Not tainted 2.6.32-rc8 #259
kernel: Call Trace:
kernel:  [<c111eb8b>] ? __list_add+0x8b/0x90
kernel:  [<c111eb8b>] ? __list_add+0x8b/0x90
kernel:  [<c103265c>] warn_slowpath_common+0x6c/0xc0
kernel:  [<c111eb8b>] ? __list_add+0x8b/0x90
kernel:  [<c10326f6>] warn_slowpath_fmt+0x26/0x30
kernel:  [<c111eb8b>] __list_add+0x8b/0x90
kernel:  [<c11ba165>] i2c_sysfs_new_device+0x1c5/0x250
kernel:  [<c10861be>] ? might_fault+0x2e/0x80
kernel:  [<c11b9fa0>] ? i2c_sysfs_new_device+0x0/0x250
kernel:  [<c118c625>] dev_attr_store+0x25/0x30
kernel:  [<c10e305c>] sysfs_write_file+0x9c/0xf0
kernel:  [<c109d35c>] vfs_write+0x9c/0x160
kernel:  [<c10e2fc0>] ? sysfs_write_file+0x0/0xf0
kernel:  [<c109d4dd>] sys_write+0x3d/0x70
kernel:  [<c1002ed8>] sysenter_do_call+0x12/0x36
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Some user-space applications may be relying on i2c adapters showing up
as class devices in sysfs. Provide compatibility links for them for
the time being. We will remove them after a long transition period.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Kay Sievers <kay.sievers@vrfy.org>

Kay says i2c adapters shouldn't be class devices but bus devices.
Convert them that way, using a device type.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Kay Sievers <kay.sievers@vrfy.org>

This is required for upcoming changes.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Kay Sievers <kay.sievers@vrfy.org>

By using rwsem we can easily manage recursive calls of
i2c_scan_static_board_info() function without breaking the locking.
Signed-off-by: NRodolfo Giometti <giometti@linux.it>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Add a sysfs interface to instantiate and delete I2C devices. This is
primarily a replacement of the force_* module parameters implemented
by some i2c drivers. These module parameters were implemented
internally by the I2C_CLIENT_INSMOD* macros, which don't scale well.

This can also be used when developing a driver on a self-soldered
board which doesn't yet have proper I2C device declaration at the
platform level, and presumably for various debugging situations.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>

The i2c-core code tends to hold the core lock for longer than it
should. Limit locking to the necessary sections for both performance
and clarity. This is also a requirement to support I2C multiplexers in
the future.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Tested-by: NRodolfo Giometti <giometti@linux.it>
Cc: David Brownell <dbrownell@users.sourceforge.net>

We used to maintain our own per-adapter list of i2c clients, but this
is redundant with what the driver core does, and no longer needed.
Just drop the redundant list.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>

Legacy i2c drivers are gone, all drivers are new-style now, so there
is no point to check.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>

Now that i2c_attach_client is no longer exported, it doesn't need to
be a separate function. Merge it into its only user, i2c_new_device.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>

The legacy i2c_probe() function has no users left, get rid of it.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>

We converted all the legacy i2c drivers so we can finally get rid of
the legacy binding model. Hooray!
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>

These methods were useful in the legacy binding model but no longer in
the new (standard) binding model. There are no users left so we can
drop them.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>

We don't need to give adapters a parent if they don't have one. The
driver core will put them in the virtual device directory and all will
be fine.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Some small changes in i2c core to retry i2c xfers until either the
maximum number of retries or the timeout is hit.
Signed-off-by: NClifford Wolf <clifford@clifford.at>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Remove uneeded void casts.
Signed-off-by: NJack Stone <jwjstone@fastmail.fm>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

While it isn't the way the standard device binding model works, it is
OK for new-style drivers to implement attach_adapter. It may help
convert the renaming legacy drivers to new style drivers faster.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>

Some lines over 80. 
The printk(KERN_ERR ... ) should be dev_err.
And some blankspace should be deleted.
Signed-off-by: NZhenwen Xu <helight.xu@gmail.com>
Signed-off-by: NJean Delvare <khlai@linux-fr.org>

Setting a default timeout value on a per-algo basis doesn't make any
sense. Move the default value setting to i2c-core. Individual adapter
drivers can specify a different (non-zero) value if they wish.

Also express the timeout value in a way which results in the same
duration regarless of the value of HZ.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NWolfram Sang <w.sang@pengutronix.de>

The automatic removal of i2c clients only affects the clients which
were created automatically in the first place. Add a comment saying
that to avoid any confusion.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

This patch implements uevent suppress in kobject and removes it
from struct device, based on the following ideas:

1,Uevent sending should be one attribute of kobject, so suppressing it
in kobject layer is more natural than in device layer. By this way,
we can do it for other objects embedded with kobject.

2,It may save several bytes for each instance of struct device.(On my
omap3(32bit ARM) based box, can save 8bytes per device object)

This patch also introduces dev_set|get_uevent_suppress() helpers to
set and query uevent_suppress attribute in case to help kobject
as private part of struct device in future.

[This version is against the latest driver-core patch set of Greg,please
ignore the last version.]
Signed-off-by: NMing Lei <tom.leiming@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix misplaced parentheses.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

This patch is part of a larger patch series which will remove
the "char bus_id[20]" name string from struct device. The device
name is managed in the kobject anyway, and without any size
limitation, and just needlessly copied into "struct device".

To set and read the device name dev_name(dev) and dev_set_name(dev)
must be used. If your code uses static kobjects, which it shouldn't
do, "const char *init_name" can be used to statically provide the
name the registered device should have. At registration time, the
init_name field is cleared, to enforce the use of dev_name(dev) to
access the device name at a later time.

We need to get rid of all occurrences of bus_id in the entire tree
to be able to enable the new interface. Please apply this patch,
and possibly convert any remaining remaining occurrences of bus_id.

We want to submit a patch to -next, which will remove bus_id from
"struct device", to find the remaining pieces to convert, and finally
switch over to the new api, which will remove the 20 bytes array
and does no longer have a size limitation.
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

i2c clients should be removed in reverse order compared to the probe
(actually: bind) order. This matters when several clients depend on
each other.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Tested-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>

If present the info->archdata is copied into the dev->archdata.
Some (OpenFirmware) platforms need it.
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Restore the i2c_smbus_process_call() as one driver (for the
Micronas MAP5401) will need it soon.

[JD: Update documentation accordingly.]
Signed-off-by: NPrakash Mortha <pmortha@escient.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Move I2C driver model init earlier in the boot sequence.

This avoids oopsing in statically linked systems when some
subsystems register I2C drivers in subsys_initcall() code,
but those subsystems are linked (and initialized) before I2C.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Guard I2C against oopsing because of init sequence problems, by
verifying that i2c_init() has been called before calling any
routines that rely on that initialization.  This specific test
just requires that bus_register(&i2c_bus_type) was called.

Examples of this kind of oopsing come from subystems and drivers
which register I2C drivers in their subsys_initcall code but
which are statically linked before I2C by drivers/Makefile.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NJean Delvare <khali@linux-fr.org>