Allow the whole I2C menu to be disabled at once without diving into
the submenus for deselecting all options (should the user desire so).
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
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>
i2c: Fix copy-n-paste in subsystem Kconfig
We have:
drivers/i2c/Kconfig:2:# Character device configuration
Which is obviously not true..
Signed-off-by: Arthur Othieno <apgo@patchbomb.org>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Jan Engelhardt
David Brownell
Arthur Othieno
Linus Torvalds