History log of /drivers/i2c/i2c-core.h
Revision Date Author Comments
5694f8a888f8f69a562e4cf939eed81ca7a5ecf2 26-Mar-2012 Jean Delvare <khali@linux-fr.org> i2c: Update the FSF address

Signed-off-by: Jean Delvare <khali@linux-fr.org>
f18c41daea14baee11252da268cdf5dcd57c7c10 19-Jun-2009 Rodolfo Giometti <giometti@linux.it> i2c: Use rwsem instead of mutex for board info

By using rwsem we can easily manage recursive calls of
i2c_scan_static_board_info() function without breaking the locking.

Signed-off-by: Rodolfo Giometti <giometti@linux.it>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
9c1600eda42e52796f49b36cf15b9debcfd09bea 01-May-2007 David Brownell <david-b@pacbell.net> i2c: Add i2c_board_info and i2c_new_device()

This provides partial support for new-style I2C driver binding. It builds
on "struct i2c_board_info" declarations that identify I2C devices on a given
board. This is needed on systems with I2C devices that can't be fully probed
and/or autoconfigured, such as many embedded Linux configurations where the
way a given I2C device is wired may affect how it must be used.

There are two models for declaring such devices:

* LATE -- using a public function i2c_new_device(). This lets modules
declare I2C devices found *AFTER* a given I2C adapter becomes available.

For example, a PCI card could create adapters giving access to utility
chips on that card, and this would be used to associate those chips with
those adapters.

* EARLY -- from arch_initcall() level code, using a non-exported function
i2c_register_board_info(). This copies the declarations *BEFORE* such
an i2c_adapter becomes available, arranging that i2c_new_device() will
be called later when i2c-core registers the relevant i2c_adapter.

For example, arch/.../.../board-*.c files would declare the I2C devices
along with their platform data, and I2C devices would behave much like
PNPACPI devices. (That is, both enumerate from board-specific tables.)

To match the exported i2c_new_device(), the previously-private function
i2c_unregister_device() is now exported.

Pending later patches using these new APIs, this is effectively a NOP.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Jean Delvare <khali@linux-fr.org>