Commit Graph

9 Commits

Author SHA1 Message Date
Jean Delvare
563db2fe9e [PATCH] I2C: Kill another macro abuse in via686a
This patch kills another macro abuse in the via686a hardware monitoring
driver. Using a macro just to alias an array is quite useless, isn't it?

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-06-21 21:51:59 -07:00
Jean Delvare
be8992c249 [PATCH] I2C: Coding style cleanups to via686a
The via686a hardware monitoring driver has infamous coding style at the
moment. I'd like to clean up the mess before I start working on other
changes to this driver. Is the following patch acceptable? No code
change, only coding style (indentation, alignments, trailing white
space, a few parentheses and a typo).

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-06-21 21:51:58 -07:00
Jean Delvare
68188ba7de [PATCH] I2C: Kill common macro abuse in chip drivers
This patch kills a common macro abuse in i2c chip drivers: defining
ALARMS_FROM_REG returning its argument unchanged. Dropping the macro
makes the code somewhat more readable IMHO.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-06-21 21:51:57 -07:00
Grant Coady
b9826b3ee8 [PATCH] I2C: remove <linux/delay.h> from via686a
In my cross-reference checking of sysfs names, the via686a needs
special case treatment as it the only driver expands S_IWUSR to
00200 with gcc -E.  (00200 is the correct value for S_IWUSR).

This is caused by the driver including <linux/delay.h>, it compiles
fine without that header but I am unable to test drive the change.

Signed-off-by: Grant Coady <gcoady@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-06-21 21:51:56 -07:00
Alexey Dobriyan
f0bb60e7b1 [PATCH] I2C: drivers/i2c/*: #include <linux/config.h> cleanup
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-06-21 21:51:53 -07:00
Yani Ioannou
a5099cfc2e [PATCH] Driver Core: drivers/i2c/chips/pc87360.c - w83627hf.c: update device attribute callbacks
Signed-off-by: Yani Ioannou <yani.ioannou@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-06-20 15:15:33 -07:00
Jean Delvare
1d66c64c3c [PATCH] I2C: Fix incorrect sysfs file permissions in it87 and via686a drivers
The it87 and via686a hardware monitoring drivers each create a sysfs
file named "alarms" in R/W mode, while they should really create it in
read-only mode. Since we don't provide a store function for these files,
write attempts to these files will do something undefined (I guess) and
bad (I am sure). My own try resulted in a locked terminal (where I
attempted the write) and a 100% CPU load until next reboot.

As a side note, wouldn't it make sense to check, when creating sysfs
files, that readable files have a non-NULL show method, and writable
files have a non-NULL store method? I know drivers are not supposed to
do stupid things, but there is already a BUG_ON for several conditions
in sysfs_create_file, so maybe we could add two more?

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-04-18 21:16:59 -07:00
Jean Delvare
86b5ac878d [PATCH] I2C: via686a cleanups
Here comes a small cleanup patch for the via686a driver. I noticed the
following two non-fatal problems:

1* The device parent is explicitely set, but it's not needed because the
i2c core will do as the client is registered.

2* snprintf is used where strlcpy would suffice.

Fixing them brings the via686a driver in line with what other similar
drivers do.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-04-18 21:16:58 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00