aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/i2c/chips/eeprom.c
Commit message (Collapse)AuthorAgeFilesLines
* [PATCH] i2c: Static function fixes, 1 of 4Ben Dooks2005-10-281-1/+1
| | | | | | | | | eeprom_detect is first declared static and then when the function is actually implemented, there is no static. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] i2c: kzalloc conversion, other driversDeepak Saxena2005-10-281-2/+1
| | | | | | | | | Use kzalloc instead of kmalloc+memset in all remaining i2c bus and chip drivers. Signed-off-by: Deepak Saxena <dsaxena@plexity.net> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] i2c: Drop I2C_SMBUS_I2C_BLOCK_MAXJean Delvare2005-10-281-2/+2
| | | | | | | | | | | | | | | Drop I2C_SMBUS_I2C_BLOCK_MAX, use I2C_SMBUS_BLOCK_MAX instead. I2C_SMBUS_I2C_BLOCK_MAX has always been defined to the same value as I2C_SMBUS_BLOCK_MAX, and this will never change: setting it to a lower value would make no sense, setting it to a higher value would break i2c_smbus_data compatibility. There is no point in changing i2c_smbus_data to support larger block transactions in SMBus mode, as no SMBus hardware supports more than 32 byte blocks. Thus, for larger transactions, direct I2C transfers are the way to go. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] I2C: Centralize 24RF08 corruption preventionJean Delvare2005-09-051-5/+0
| | | | | | | | | | | | | | | | | | | | The 24RF08 corruption would better be prevented at i2c-core level than at chip driver level, for several reasons: * The second quick write should happen as soon as possible after the first one, so as to limit the risk that another command is issued on the bus inbetween, causing the corruption. * As a matter of fact, the protection code at driver level was reworked at least three times already, which proves how hard it is to get it right there, while it's straightforward at i2c-core level. * It's easy to add a new driver that would need the protection, and forget to add it. This did happen already. * As additional probing addresses can be passed to most i2c chip drivers as module parameters, virtually every i2c chip driver would need the protection if we want to be really safe. * Why duplicate code when we can easily avoid it? Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] hwmon: hwmon vs i2c, second round (06/11)Jean Delvare2005-09-051-2/+1
| | | | | | | | | | | The only thing left in i2c-sensor.h are module parameter definition macros. It's only an extension of what i2c.h offers, and this extension is not sensors-specific. As a matter of fact, a few non-sensors drivers use them. So we better merge them in i2c.h, and get rid of i2c-sensor.h altogether. Signed-off-by: Jean Delvare <khali@linux-fr> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] hwmon: hwmon vs i2c, second round (04/11)Jean Delvare2005-09-051-2/+2
| | | | | | | | i2c_probe and i2c_detect now do the exact same thing and operate on the same data structure, so we can have everyone call i2c_probe. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] I2C: refactor message in i2c_detach_clientJean Delvare2005-09-051-3/+1
| | | | | | | | | | | | We could refactor the error message 34 different i2c drivers print if i2c_detach_client() fails in this function itself. Saves quite a few lines of code. Documentation is updated to reflect that change. Note that this patch should be applied after Rudolf Marek's w83792d patches. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] I2C: Separate non-i2c hwmon drivers from i2c-core (7/9)Jean Delvare2005-09-051-1/+0
| | | | | | | | | | | Kill normal_isa in header files, documentation and all chip drivers, as it is no more used. normal_i2c could be renamed to normal, but I decided not to do so at the moment, so as to limit the number of changes. This might be done later as part of the i2c_probe/i2c_detect merge. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] I2C: 24RF08 corruption prevention (again)Jean Delvare2005-07-291-3/+5
| | | | | | | | | | | | | | | | | The 24RF08 corruption prevention in the eeprom and max6875 drivers wasn't complete. For one thing, the additional quick write should happen as soon as possible and unconditionally, while both drivers had error paths before. For another, when a given chip is forced, the core does not emit a quick write, so a second quick write would cause the corruption rather than prevent it. I plan to move the corruption prevention in the core in the long run, so that individual drivers don't have to care anymore. But I need to merge i2c_probe and i2c_detect before I do (work in progress). Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] I2C: drop bogus eeprom commentJean Delvare2005-07-111-3/+0
| | | | | | | | This simple patch drops an out-of-date comment in the eeprom i2c chip driver. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] I2C: drivers/i2c/*: #include <linux/config.h> cleanupAlexey Dobriyan2005-06-211-1/+0
| | | | | | | | | | 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>
* Linux-2.6.12-rc2Linus Torvalds2005-04-161-0/+264
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!