aboutsummaryrefslogtreecommitdiff
path: root/drivers/i2c/chips
AgeCommit message (Collapse)Author
2006-04-19[PATCH] m41t00: fix bitmasks when writing to chipDavid Barksdale
Fix the bitmasks used when writing to the M41T00 registers. The original code used a mask of 0x7f when writing to each register, this is incorrect and probably the result of a copy-paste error. As a result years from 1980 to 1999 will be read back as 2000 to 2019. Signed-off-by: David Barksdale <amatus@ocgnet.org> Acked-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-14[PATCH] i2c: convert m41t00 to use a workqueueMark A. Greer
The m41t00 i2c/rtc driver currently uses a tasklet to schedule interrupt-level writes to the rtc. This patch causes the driver to use a workqueue instead. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-04-14[PATCH] i2c: convert ds1374 to use a workqueueJean Delvare
A tasklet is not suitable for what the ds1374 driver does: neither sleeping nor mutex operations are allowed in tasklets, and ds1374_set_tlet may do both. We can use a workqueue instead, where both sleeping and mutex operations are allowed. Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Randy Vinson <rvinson@mvista.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-03-27[PATCH] RTC subsystem: I2C cleanupAlessandro Zummo
This patch, completely optional, removes from drivers/i2c/chips all the drivers that are implemented in the new RTC subsystem. It should be noted that none of the current driver is actually integrated, i.e. usable without further patches. Signed-off-by: Alessandro Zummo <a.zummo@towertech.it> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-24[PATCH] s/;;/;/gAlexey Dobriyan
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-23[PATCH] i2c: Cleanup isp1301_omapJean Delvare
Drop unused rogue i2c driver ID and nonsensical i2c class. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-03-23[PATCH] i2c: Semaphore to mutex conversions, part 2Ingo Molnar
semaphore to mutex conversion. the conversion was generated via scripts, and the result was validated automatically via a script as well. build tested. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-03-23[PATCH] I2C: Convert i2c to mutexesArjan van de Ven
The patch below converts a few i2c semaphores to mutexes Signed-off-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-08[PATCH] IRQ type flagsRussell King
Some ARM platforms have the ability to program the interrupt controller to detect various interrupt edges and/or levels. For some platforms, this is critical to setup correctly, particularly those which the setting is dependent on the device. Currently, ARM drivers do (eg) the following: err = request_irq(irq, ...); set_irq_type(irq, IRQT_RISING); However, if the interrupt has previously been programmed to be level sensitive (for whatever reason) then this will cause an interrupt storm. Hence, if we combine set_irq_type() with request_irq(), we can then safely set the type prior to unmasking the interrupt. The unfortunate problem is that in order to support this, these flags need to be visible outside of the ARM architecture - drivers such as smc91x need these flags and they're cross-architecture. Finally, the SA_TRIGGER_* flag passed to request_irq() should reflect the property that the device would like. The IRQ controller code should do its best to select the most appropriate supported mode. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-05[PATCH] I2C: Remove .owner setting from i2c_driver as it's no longer neededGreg Kroah-Hartman
Now that i2c_add_driver() doesn't need the module owner to be set by hand, we can delete it from the drivers. This patch catches all of the drivers that I found in the current tree (if a driver sets the .owner by hand, it's not a problem, just not needed.) Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Cc: Jean Delvare <khali@linux-fr.org>
2006-01-05[PATCH] i2c: Drop i2c_driver.{owner,name}, 2 of 11Laurent Riffard
We should use the i2c_driver.driver's .name and .owner fields instead of the i2c_driver's ones. This patch updates the miscellaneaous i2c chip drivers. Signed-off-by: Laurent Riffard <laurent.riffard@free.fr> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-05[PATCH] i2c: Rework client usage count, 2 of 3Jean Delvare
Make I2C_CLIENT_ALLOW_USE the default for all i2c clients. It doesn't hurt if the usage count is actually never used for any given driver, and allows for nice code simplifications in i2c-core. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-05[PATCH] i2c: Drop i2c_driver.flags, 2 of 3Jean Delvare
Just about every i2c chip driver sets the I2C_DF_NOTIFY flag, so we can simply make it the default and drop the flag. If any driver really doesn't want to be notified when i2c adapters are added, that driver can simply omit to set .attach_adapter. This approach is also more robust as it prevents accidental NULL pointer dereferences. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-05[PATCH] i2c: Remove duplicate rtc8564 BCD macrosNicolas Kaiser
Remove duplicate of BCD macros. Signed-off-by: Nicolas Kaiser <nikai@nikai.net> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-05[PATCH] i2c: Extend ds1337 initializationMichael Burian
Add code to handle case where board firmware does not start the RTC. Signed-off-by: Jean Delvare <khali@linux-fr.org> CC: James Chapman <jchapman@katalix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-11Merge master.kernel.org:/home/rmk/linux-2.6-drvmodelLinus Torvalds
2005-11-09[DRIVER MODEL] Convert platform drivers to use struct platform_driverRussell King
This allows us to eliminate the casts in the drivers, and eventually remove the use of the device_driver function pointer methods for platform device drivers. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-07[PATCH] i2c: ds1337 BCD conversion fixJames Chapman
Fix BCD value errors when month=9, moving the increment inside the BIN2BCD macro. Fix similar code for the weekday value, just for consistency. This bug was reported by Michael Burian <dynmail1@gassner-waagen.at>. Signed-off-by: James Chapman <jchapman@katalix.com> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-29Create platform_device.h to contain all the platform device details.Russell King
Convert everyone who uses platform_bus_type to include linux/platform_device.h. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-28[PATCH] i2c: Static function fixes, 4 of 4Ben Dooks
Fix functions declared static and then implemented without the static in drivers/i2c/chips. 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>
2005-10-28[PATCH] i2c: Static function fixes, 1 of 4Ben Dooks
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>
2005-10-28[PATCH] i2c: kzalloc conversion, other driversDeepak Saxena
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>
2005-10-28[PATCH] i2c: New Xicor X1205 RTC driverAlessandro Zummo
New driver for the Xicor X1205 RTC chip. Signed-off-by: Alessandro Zummo <alessandro.zummo@towertech.it> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-28[PATCH] Owner field additions to many i2c drivers, 2 of 5Laurent Riffard
This patch updates the .owner field for various struct xxxx_driver variables, other than pci_driver. Signed-off-by: Laurent Riffard <laurent.riffard@free.fr> Signed-off-by: Jean Delvare <khali@linux-fr> Acked-by: Mark A. Greer <mgreer@mvista.com> Acked-by: Ben Dooks <ben-linux@fluff.org> Acked-by: Deepak Saxena <dsaxena@mvista.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-28[PATCH] i2c: Drop meaningless use of I2C_DF_NOTIFY in i2c_client structuresJean Delvare
I2C_DF_NOTIFY is an i2c_driver flag, using it as an i2c_client flag doesn't make any sense. Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Mark A. Greer <mgreer@mvista.com> Acked-by: Randy Vinson <rvinson@mvista.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-28[PATCH] i2c: Drop I2C_SMBUS_I2C_BLOCK_MAXJean Delvare
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>
2005-09-07[PATCH] drivers: convert kcalloc to kzallocPekka Enberg
This patch converts kcalloc(1, ...) calls to use the new kzalloc() function. Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-05[PATCH] i2c: chips/ds1374.c fixupMark A. Greer
The 'new_time' variable should be static. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05[PATCH] i2c: chips/m41t00.c fixupMark A. Greer
The 'new_time' variable should be static. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05[PATCH] I2C: Centralize 24RF08 corruption preventionJean Delvare
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>
2005-09-05[PATCH] hwmon: hwmon vs i2c, second round (07/11)Jean Delvare
The only part left in i2c-sensor is the VRM/VRD/VID handling code. This is in no way related to i2c, so it doesn't belong there. Move the code to hwmon, where it belongs. Note that not all hardware monitoring drivers do VRM/VRD/VID operations, so less drivers depend on hwmon-vid than there were depending on i2c-sensor. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05[PATCH] hwmon: hwmon vs i2c, second round (06/11)Jean Delvare
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>
2005-09-05[PATCH] hwmon: hwmon vs i2c, second round (04/11)Jean Delvare
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>
2005-09-05[PATCH] hwmon: hwmon vs i2c, second round (01/11)Jean Delvare
Add support for kind-forced addresses to i2c_probe, like i2c_detect has for (essentially) hardware monitoring drivers. Note that this change will slightly increase the size of the drivers using I2C_CLIENT_INSMOD, with no immediate benefit. This is a requirement if we want to merge i2c_probe and i2c_detect though, and seems a reasonable price to pay in comparison with the previous cleanups which saved much more than that (such as the i2c-isa cleanup or the i2c address ranges removal.) Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05[PATCH] I2C: refactor message in i2c_detach_clientJean Delvare
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>
2005-09-05[PATCH] I2C: Separate non-i2c hwmon drivers from i2c-core (7/9)Jean Delvare
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>
2005-09-05[PATCH] I2C: max6875 code cleanupbgardner@wabtec.com
Remove an unused local variable and change the subclient name. Signed-off-by: Ben Gardner <bgardner@wabtec.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05[PATCH] I2C: add kobj_to_i2c_clientbgardner@wabtec.com
Move the inline function kobj_to_i2c_client() from max6875.c to i2c.h. Signed-off-by: Ben Gardner <bgardner@wabtec.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05[PATCH] I2C: fix max6875 build errorGreg Kroah-Hartman
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05[PATCH] I2C: simplify max6875 driverbgardner@wabtec.com
This is an update to the max6875 driver. It no longer does any detection, so the address must be forced on module load. It only makes available the user EEPROM (read-only). This patch is based off 2.6.13-rc2-mm2. Signed-off-by: Ben Gardner <bgardner@wabtec.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-07-29[PATCH] I2C: 24RF08 corruption prevention (again)Jean Delvare
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>
2005-07-29[PATCH] I2C: ds1337 - fix 12/24 hour mode bugLadislav Michl
DS1339 manual, page 6, chapter Date and time operation: The DS1339 can be run in either 12-hour or 24-hour mode. Bit 6 of the hours register is defined as the 12-hour or 24-hour mode-select bit. When high, the 12-hour mode is selected. Patch below makes ds1337 driver work as documented in manual. Signed-off-by: Ladislav Michl <ladis@linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-11[PATCH] I2C: Move hwmon drivers (2/3)Jean Delvare
Part 2: Move the driver files themselves. Note that the patch "adds trailing whitespace", because it does move the files as-is, and some files happen to have trailing whitespace. From: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-07-11[PATCH] I2C: Move hwmon drivers (1/3)Jean Delvare
Part 1: Configuration files and Makefiles. From: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-07-11[PATCH] I2C: SENSORS_ATXP1 must select I2C_SENSORAdrian Bunk
On Thu, Jun 30, 2005 at 11:47:09PM +0200, Sebastian Pigulak wrote: > I've tried patching linux-2.6.13-RC1 with patch-2.6.13-rc1-git2 and > building atxp1(it allows Vcore voltage changing) into the kernel. > Unfortunately, the kernel compilation stops with: > > LD init/built-in.o > LD vmlinux > drivers/built-in.o(.text+0x92298): In function `atxp1_detect': > : undefined reference to `i2c_which_vrm' > drivers/built-in.o(.text+0x921ae): In function `atxp1_attach_adapter': > : undefined reference to `i2c_detect' > make: *** [vmlinux] B??d 1 > ==> ERROR: Build Failed. Aborting... > > Could someone have a look at the module and possibly fix it up? SENSORS_ATXP1 must select I2C_SENSOR. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-07-11[PATCH] I2C: drop bogus eeprom commentJean Delvare
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>
2005-07-11[PATCH] I2C: m41t00: fix incorrect kfreeJean Delvare
Here is a simple path fixing an incorrect kfree in the m41t00 i2c chip driver. The current code happens to work by accident, but the freed pointer isn't the one which was allocated in the first place, which could cause problems later. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-07-11[PATCH] I2C: max6875 Kconfig updateJean Delvare
Here is a proposed Kconfig update for the new max6875 i2c chip driver. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-07-11[PATCH] I2C: New max6875 driver may corrupt EEPROMsJean Delvare
After a careful code analysis on the new max6875 driver (drivers/i2c/chips/max6875.c), I have come to the conclusion that this driver may cause EEPROM corruptions if used on random systems. The EEPROM part of the MAX6875 chip is accessed using rather uncommon I2C sequences. What is seen by the MAX6875 as reads can be seen by a standard EEPROM (24C02) as writes. If you check the detection method used by the driver, you'll find that the first SMBus command it will send on the bus is i2c_smbus_write_byte_data(client, 0x80, 0x40). For the MAX6875 it makes an internal pointer point to a specific offset of the EEPROM waiting for a subsequent read command, so it's not an actual data write operation, but for a standard EEPROM, this instead means writing value 0x40 to offset 0x80. Blame Philips and Intel for the obscure protocol. Since the MAX6875 and the standard, common 24C02 EEPROMs share two I2C addresses (0x50 and 0x52), loading the max6875 driver on a system with standard EEPROMs at either address will trigger a write on these EEPROMs, which will lead to their corruption if they happen not to be write protected. This kind of EEPROMs can be found on memory modules (SPD), ethernet adapters (MAC address), laptops (proprietary data) and displays (EDID/DDC). Most of these are hopefully write-protected, but not all of them. For this reason, I would recommend that the max6875 driver be neutralized, in a way that nobody can corrupt his/her EEPROMs by just loading the driver. This means either deleting the driver completely, or not listing any default address for it. I'd like this to be done before 2.6.13-rc1 is released. Additionally, the max6875 driver lacks the 24RF08 corruption preventer present in the eeprom driver, which means that loading this driver in a system with such a chip would corrupt it as well. Here is a proposed quick patch addressing the issue, although I wouldn't mind a complete removal if it makes everyone feel safer. I think Ben has plans to replace this driver by a much simplified one anyway. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-07-11[PATCH] I2C: minor TPS6501x cleanupsdavid-b@pacbell.net
This includes various small cleanups and fixes to the TPS 6501x driver that came mostly from review feedback by Jean Delvare; thanks Jean! Also some goofy whitespace gets fixed. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>