- 02 Mar, 2005 29 commits
-
-
Mickey Stein authored
gcc 4.0.x cvs seems to dislike "include/linux/i2c.h file" and others due to a current gcc 4.0.x change having to do with array declarations. Example error msg: include/linux/i2c.h:{55,194} error: array type has incomplete element type A. Daplas has recently done a workaround for this on another header file. A thread discussing this can be found by following the link below: http://gcc.gnu.org/ml/gcc/2005-02/msg00053.html The patch changes the array(struct i2c_msg) declaration used by *i2c_transfer and *master_xfer from "struct i2c_msg msg[]" format to "struct i2c_msg *msg". After some grepping, I came up with about a dozen files that used the format disliked by gcc4 that're addressed by the attached patch. Tested on gcc 3.x & gcc 4.x by configuring kernel with all i2c switches enabled as module, and saw no errors or warnings in i2c. Signed-off-by:Mickey Stein <yekkim@pacbell.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jean Delvare authored
Shouldn't the i2c list terminators be explicitely declared as unsigned? I'd hope it to help code analysis tools and possibly avoid false positives. Coverity's SWAT pointed my attention to these constants. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Jean Delvare authored
Several functions in your rtc8564 driver verify the non-NULLity of the i2c client that is passed to them. It doesn't seem to be necessary, as I can't think of any case where these functions could possibly be called with a NULL i2c client. As a matter of fact, I couldn't find any similar driver doing such checks. My attention was brought on this by Coverity's SWAT which correctly noticed that three of these functions contain explicit or hidden dereferences of the i2c client pointer *before* the NULL check. I guess it wasn't a problem because the NULL case cannot happen (unless I miss something), but this still is confusing code. Thus I propose the following changes: Signed-off-by:
-
hfvogt@gmx.net authored
can you please apply the attached patch (against 2.6.11-rc4, but works as well for 2.6.11-rc3-mm2), that adds support for the two SMBusses of the nForce4 to the i2c-nforce2 i2c bus driver. The patch is reported to work on the standard nForce4 (i.e. non-Ultra, non-SLI), but I expect that it works as well for the other nForce4 chipsets, that seem to have the same PCI-id for the SMBus-device. This patch was proposed by Chuck <chunkeey@web.de>, thanks to him for the information, testing and his patch. Signed-off-by:
Hans-Frieder Vogt <hfvogt@arcor.de> Signed-off-by:
-
Ian Campbell authored
I was looking at your ixp4xx gpio i2c driver for inspiration (for a similar pxa2xx one) and I just happened to notice a tiny typo. Signed-off-by:
Ian Campbell <icampbell@arcom.com> Signed-off-by:
-
Maciej W. Rozycki authored
Is there any specific reason for the PIIX4 SMBus driver to be disabled on 64-bit platforms? If not, then please apply the following change. The MIPS Technologies Malta development board has the 82371EB chip and supports 64-bit configurations. I've verified the driver to work correctly using 64-bit kernels for both endiannesses. Signed-off-by:
Maciej W. Rozycki <macro@mips.com> Signed-off-by:
-
Ian Campbell authored
Rework the pca_xfer() function to always print the number of successfully completed transfers in a series when debugging, even when exiting with an error. Signed-off-by:
-
maartendeprez@scarlet.be authored
Port of the Genesys Logic 520SM sensor chip driver from linux 2.4 Signed-off-by:
Maarten Deprez <maartendeprez@users.sourceforge.net> Signed-off-by:
-
Mark A. Greer authored
Marvell makes a line of host bridge for PPC and MIPS systems. On those bridges is an i2c controller. This patch adds the driver for that i2c controller. Please apply. Depends on patch submitted by Jean Delvare: http://archives.andrew.net.au/lm-sensors/msg29405.htmlSigned-off-by:
Mark A. Greer <mgreer@mvista.com> Signed-off-by:
-
Aurelien Jarno authored
Please find below the new version of the patch against kernel 2.6.11-rc3-mm1 to add the sis5595 driver (sensor part). As you suggested, I have changed the PCI part of the driver, taking the via686a driver as an example. I have also changed the comparison of jiffies by using time_after. Signed-off-by:
Aurelien Jarno <aurelien@aurel32.net> Signed-off-by:
-
Mark A. Greer authored
This patch adds support for the ST M41T00 I2C RTC chip. This rtc chip has no mechanism to freeze it's registers while being read; however, it will delay updating the external values of the registers for 250ms after a register is read. To ensure that a sane time value is read, the driver verifies that the same registers values were read twice before returning. Also, when setting the rtc from an interrupt handler, a tasklet is used to provide the context required by the i2c core code. Signed-off-by:
-
Alexey Dobriyan authored
Signed-off-by:
Alexey Dobriyan <adobriyan@mail.ru> Signed-off-by:
-
Adrian Bunk authored
This patch makes some needlessly global code static. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
Greg Kroah-Hartman <greg@kroah.com>
-
Shawn Starr authored
Description: Cleanup some cluttered macros, add error checking for fan divisor value set. Signed-off-by:
Sytse Wielinga <s.b.wielinga@student.utwente.nl> Signed-off-by:
Shawn Starr <shawn.starr@rogers.com> Signed-off-by:
-
Mark M. Hoffman authored
* Jean Delvare <khali@linux-fr.org> [2005-01-25 10:14:49 +0100]: > Any reson why asb100.c (in linux 2.6.11-rc2) includes linux/ioport.h and > asm/io.h? As an i2c-only chip driver, I don't think it needs these. > > As a side note, I also wonder what the inclusions of linux/config.h, > linux/types.h and asm/errno.h are there for. Because they look pretty? Here's a patch Greg, please apply... Signed-off-by:
Mark M. Hoffman <mhoffman@lightlink.com> Signed-off-by:
-
Jean Delvare authored
Looks to me like i2c-sensor-detect.c includes a handful of headers it doesn't need at all. This patch removes them. Signed-off-by:
-
Jean Delvare authored
The chips supported by the w83781d and w83627hf drivers might come up with their temperature channels disabled. Currently, the w83781d driver does so for temp3 but omits temp2, while the w83627hf driver omits both. The following patch fixes that, and prints warning messages when the driver has to enable the channels (normally the BIOS should do it for us). We also skip this initialization step for the AS99127F chips, for which we have no documentation. This should hopefully solve the problem reported here: http://archives.andrew.net.au/lm-sensors/msg29150.htmlSigned-off-by:
-
Aurelien Jarno authored
The following patch against kernel 2.6.11-rc2-mm1 improves the lm78 driver. I used it as a model to port the sis5595 driver to the 2.6 kernel, and I then applied the changes suggested by Jean Delvare on the sis5595 driver to this one. Signed-off-by:
-
Mark M. Hoffman authored
This patch is namespace cleanup for the i2c-dev module. Please apply. Signed-off-by Mark M. Hoffman <mhoffman@lightlink.com> Signed-off-by: -
Stefan Ott authored
Multiplied the voltage multipliers by 10 in order to comply with the sysfs guidelines. Signed-off-by:
Stefan Ott <stefan@desire.ch> Signed-off-by:
-
Greg Kroah-Hartman authored
Becides, sparse keeps complaining when it sees this attribute within a structure... Signed-off-by: -
Jean Delvare authored
> (5/5) Documentation update. Finally, updates are required to the i2c/writing-client and i2c/porting-client documents. Remove any reference to i2c_client id and invite porters to discard that struct member. Signed-off-by:
-
Jean Delvare authored
> (4/5) Deprecate i2c_client.id. Now that i2c_client.id has no more users in the kernel (none that I could find at least) we could remove that struct member. I however think that it's better to only deprecate it at the moment, in case I missed users or any of the other patches are delayed for some reason. We could then delete the id member definitely in a month or so. Signed-off-by:
-
Jean Delvare authored
(3/5) Stop using i2c_client.id in misc drivers. Affected drivers: * acorn/char/pcf8583 * acorn/char/i2c * i2c/i2c-dev * macintosh/therm_windtunnel * sound/oss/dmasound/dac3550a * sound/ppc/keywest The Acorn pcf8583 driver would give the i2c_client id the same value as the i2c_driver id, and later test that client id (in i2c). I changed it to test the client's driver id instead. The result is the same and the client id is then useless and can be removed. All other drivers here would allocate the client id to some value and then never use it. They are unaffected by the change. Signed-off-by:
-
Jean Delvare authored
(2/5) Stop using i2c_client.id in media/video drivers. Affected drivers: * adv7170 * adv7175 * bt819 * bt856 * bttv * cx88 * ovcamchip * saa5246a * saa5249 * saa7110 * saa7111 * saa7114 * saa7134 * saa7185 * tda7432 * tda9840 * tda9875 * tea6415c * tea6420 * tuner-3036 * vpx3220 Most drivers here would include the id as part of their i2c client name (e.g. adv7170[0]). This looks more like an habit than something really needed, so I replaced the various printf by strlcpy, which should be slightly faster. As said earlier, clients can be differenciated thanks to their bus id and address if needed, so I don't think that including this information in the client name is wise anyway. Other drivers would either set the id to -1 or to a unique value but then never use it. These drivers are unaffected by the changes. Signed-off-by:
-
Jean Delvare authored
(1/5) Stop using i2c_client.id in i2c/chips drivers (mostly hardware monitoring drivers). Drivers affected: * adm1021 * adm1025 * adm1026 * adm1031 * ds1621 * fscher * gl518sm * isp1301_omap * lm75 * lm77 * lm80 * lm83 * lm85 * lm87 * lm90 * max1619 * pcf8574 * pcf8591 * rtc8564 * smsc47m1 * w83l785ts The vast majority of these drivers simply defined the i2c_client id struct member but never used it, so they are not affected at all by the change. Exceptions are: * lm85 and rtc8564, which would at least display the id in a debug message when assigning it. Not really useful though, as the id was then never used. * adm1026, which used the assigned id in all driver messages. However, since dev_* calls will append the bus number and client address to these messages, the id information is redundant and can go away. Also, the driver would allow some GPIO reprogramming on the first client only (id=0) and removing the id doesn't allow that anymore. I would restore a similar functionality if needed, but the ADM1026 chip is found on very few motherboards and none of these has more than one ADM1026 chip AFAIK, so it doesn't seem to be worth the effort. Signed-off-by: -
Greg Kroah-Hartman authored
Signed-off-by: -
Jean Delvare authored
Quoting myself: > As soon as you will have confirmed that everything worked as expected, > Jonas and I will provide a patch adding a pwm polarity reconfiguration > module parameter for you to test. This should give you access to the > PWM features of your it87 chip again, but in a safe way for a change > ;) Here comes this patch. The new "fix_pwm_polarity" module parameter allows one to force the it87 chip reconfiguration. This is only supported in the case the original PWM configuration is suspected to be bogus, and only if we think that reconfiguring the chip is safe. I wish to thank Rudolf Marek and Jonas Munsin again for their testing and review of my code. Signed-off-by:
-
Stefan Ott authored
This patch against 2.6.11-rc1 contains a driver for fscpos sensors. Signed-off-by:
-
- 01 Mar, 2005 11 commits
-
-
Linus Torvalds authored
-
Greg Kroah-Hartman authored
You really don't want -2 (which was just a cut-and-paste of the initial value for the parameter) for the file mode in sysfs. Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Chris Wright authored
Send audit repsonse to socket which request came from, rather than pid that request came from. Signed-off-by:
Chris Wright <chrisw@osdl.org> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
bk://bk.arm.linux.org.uk/linux-2.6-serialLinus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
bk://bk.arm.linux.org.uk/linux-2.6-rmkLinus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Greg Kroah-Hartman authored
count is size_t, fill_write_buffer() may return a negative number which would evade the 'count > 0' checks and do bad things. found by the Coverity tool Signed-off-by:
Alexander Nyberg <alexn@dsv.su.se> Signed-off-by:
-
Dmitry Torokhov authored
Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
takis@lumumba.luc.ac.be authored
Remember to release the PCI regions on an error path. Signed-off-by:
-
Chris Wright authored
Audit inode filter drops high bits on inode number by cut 'n paste mistake. Signed-off-by:
-
Andrew Morton authored
Avoid a possible null-pointer deref. Found by the Coverity tool Signed-off-by:
-
Alexander Nyberg authored
The 'bad' label will call function that unconditionally dereferences the NULL pointer. Found by the Coverity tool Signed-off-by:
James Morris <jmorris@redhat.com> Signed-off-by:
-
