Merge branch 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging

---------------------------

What:	i2c_attach_client(), i2c_detach_client(), i2c_driver->detach_client(),

	i2c_adapter->client_register(), i2c_adapter->client_unregister

When:	2.6.30

Check:	i2c_attach_client i2c_detach_client

Why:	Deprecated by the new (standard) device driver binding model. Use

	i2c_driver->probe() and ->remove() instead.

Who:	Jean Delvare <khali@linux-fr.org>

---------------------------

What:	fscher and fscpos drivers

When:	June 2009

Why:	Deprecated by the new fschmd driver.

Once again, method 3 should be avoided wherever possible. Explicit device

instantiation (methods 1 and 2) is much preferred for it is safer and

faster.

Method 4: Instantiate from user-space

-------------------------------------

In general, the kernel should know which I2C devices are connected and

what addresses they live at. However, in certain cases, it does not, so a

sysfs interface was added to let the user provide the information. This

interface is made of 2 attribute files which are created in every I2C bus

directory: new_device and delete_device. Both files are write only and you

must write the right parameters to them in order to properly instantiate,

respectively delete, an I2C device.

File new_device takes 2 parameters: the name of the I2C device (a string)

and the address of the I2C device (a number, typically expressed in

hexadecimal starting with 0x, but can also be expressed in decimal.)

File delete_device takes a single parameter: the address of the I2C

device. As no two devices can live at the same address on a given I2C

segment, the address is sufficient to uniquely identify the device to be

deleted.

Example:

# echo eeprom 0x50 > /sys/class/i2c-adapter/i2c-3/new_device

While this interface should only be used when in-kernel device declaration

can't be done, there is a variety of cases where it can be helpful:

* The I2C driver usually detects devices (method 3 above) but the bus

  segment your device lives on doesn't have the proper class bit set and

  thus detection doesn't trigger.

* The I2C driver usually detects devices, but your device lives at an

  unexpected address.

* The I2C driver usually detects devices, but your device is not detected,

  either because the detection routine is too strict, or because your

  device is not officially supported yet but you know it is compatible.

* You are developing a driver on a test board, where you soldered the I2C

  device yourself.

This interface is a replacement for the force_* module parameters some I2C

drivers implement. Being implemented in i2c-core rather than in each

device driver individually, it is much more efficient, and also has the

advantage that you do not have to reload the driver to change a setting.

You can also instantiate the device before the driver is loaded or even

available, and you don't need to know what driver the device needs.

that can't be distinguished by protocol probing, or which need some board

specific information to operate correctly.

Accordingly, the I2C stack now has two models for associating I2C devices

with their drivers:  the original "legacy" model, and a newer one that's

fully compatible with the Linux 2.6 driver model.  These models do not mix,

since the "legacy" model requires drivers to create "i2c_client" device

objects after SMBus style probing, while the Linux driver model expects

drivers to be given such device objects in their probe() routines.

The legacy model is deprecated now and will soon be removed, so we no

longer document it here.

Standard Driver Model Binding ("New Style")

-------------------------------------------

Device/Driver Binding

---------------------

System infrastructure, typically board-specific initialization code or

boot firmware, reports what I2C devices exist.  For example, there may be

devices on a PC's SMBus.  In that case, you may want to let your driver

detect supported devices automatically.  This is how the legacy model

was working, and is now available as an extension to the standard

driver model (so that we can finally get rid of the legacy model.)

driver model.

You simply have to define a detect callback which will attempt to

identify supported devices (returning 0 for supported ones and -ENODEV

#include <linux/kernel.h>

#include <linux/i2c.h>

#include <linux/rwsem.h>

#include "i2c-core.h"

/* These symbols are exported ONLY FOR the i2c core.

 * No other users will be supported.

 */

DEFINE_MUTEX(__i2c_board_lock);

DECLARE_RWSEM(__i2c_board_lock);

EXPORT_SYMBOL_GPL(__i2c_board_lock);

LIST_HEAD(__i2c_board_list);

{

	int status;

	mutex_lock(&__i2c_board_lock);

	down_write(&__i2c_board_lock);

	/* dynamic bus numbers will be assigned after the last static one */

	if (busnum >= __i2c_first_dynamic_bus_num)

		list_add_tail(&devinfo->list, &__i2c_board_list);

	}

	mutex_unlock(&__i2c_board_lock);

	up_write(&__i2c_board_lock);

	return status;

}