aboutsummaryrefslogtreecommitdiff
path: root/drivers/i2c/algos/i2c-algo-sibyte.c
AgeCommit message (Collapse)Author
2006-09-26i2c-algo-sibyte: Merge into i2c-sibyteJean Delvare
i2c-algo-sibyte: Merge into i2c-sibyte Merge i2c-algo-sibyte into i2c-sibyte, as this is a complete, hardware-dependent SMBus implementation and not a reusable algorithm. Perform some basic coding style cleanups while we're here (mainly space-based indentation replaced by tabulations.) Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-09-26i2c-algo-sibyte: CleanupsJean Delvare
i2c-algo-sibyte: Cleanups * Delete empty algo_control implementation. * Simplify i2c_sibyte_del_bus. * Delete empty module init and cleanup functions. * Drop out-of-date #ifdef MODULE construct. Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-07-12[PATCH] i2c: Handle i2c_add_adapter failure in i2c algorithm driversMark M. Hoffman
Content-Disposition: inline; filename=i2c-algo-error-handling-fix.patch It is possible for i2c_add_adapter() to fail. Several I2C algorithm drivers ignore that fact. This (compile-tested only) patch fixes them. Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-02-06[PATCH] i2c: Use module_param in i2c-algo-sibyteEric Sesterhenn
this patch changes MODULE_PARM usage to module_param in i2c-algo-sibyte.c Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-28[PATCH] i2c: Discard explicit static initializations to 0Jean Delvare
Kill explicit static initializations to 0 in 10 i2c drivers. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> drivers/i2c/algos/i2c-algo-pca.c | 2 +- drivers/i2c/algos/i2c-algo-sibyte.c | 2 +- drivers/i2c/busses/i2c-ali15x3.c | 4 ++-- drivers/i2c/busses/i2c-amd756.c | 2 +- drivers/i2c/busses/i2c-iop3xx.c | 2 +- drivers/i2c/busses/i2c-piix4.c | 8 ++++---- drivers/i2c/busses/i2c-sis5595.c | 4 ++-- drivers/i2c/busses/i2c-sis630.c | 2 +- drivers/i2c/busses/i2c-sis96x.c | 2 +- drivers/i2c/busses/i2c-via.c | 2 +- 10 files changed, 15 insertions(+), 15 deletions(-)
2005-09-05[PATCH] I2C: Kill i2c_algorithm.id (5/7)Jean Delvare
Merge the algorithm id part (16 upper bits) of the i2c adapters ids into the definition of the adapters ids directly. After that, we don't need to OR both ids together for each i2c_adapter structure. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05[PATCH] I2C: Kill i2c_algorithm.id (4/7)Jean Delvare
There are no more users of i2c_algorithm.id, so we can finally drop this structure member. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05[PATCH] I2C: Kill i2c_algorithm.id (3/7)Jean Delvare
Don't rely on i2c_algorithm.id to alter the i2c adapter's id, use the I2C_ALGO_* value directly instead, because i2c_algorithm will soon have no id member no more. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05[PATCH] I2C: Kill i2c_algorithm.name (1/7)Jean Delvare
The name member of the i2c_algorithm is never used, although all drivers conscientiously fill it. We can drop it completely, this structure doesn't need to have a name. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-06-21[PATCH] I2C: drivers/i2c/*: #include <linux/config.h> cleanupAlexey Dobriyan
Files that don't use CONFIG_* stuff shouldn't include config.h Files that use CONFIG_* stuff should include config.h It's that simple. ;-) Signed-off-by: Alexey Dobriyan <adobriyan@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
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!