convert drivers/hwmon/*.c semaphore use to mutexes.
the conversion was generated via scripts, and the result was validated
automatically via a script as well.
all affected hwmon drivers were 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>
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>
We should use the i2c_driver.driver's .name and .owner fields
instead of the i2c_driver's ones.
This patch updates the hwmon 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>
Use kzalloc instead of kmalloc+memset in all hardware monitoring
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>
Discard a common out-of-date comment in 5 hardware monitoring drivers.
The hardware monitoring chip drivers are no more setting sensor limits
at initialization time, for quite some time already.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drivers/hwmon/lm78.c | 1 -
drivers/hwmon/via686a.c | 1 -
drivers/hwmon/w83627hf.c | 1 -
drivers/hwmon/w83781d.c | 1 -
drivers/hwmon/w83792d.c | 1 -
5 files changed, 5 deletions(-)
Do not enable the VIA VT82C686A/B integrated sensors by default, as
disabled sensors usually means that this feature is not used so the
values won't make any sense. This has been confusing many users in the
past:
http://www2.lm-sensors.nu/~lm78/readticket.cgi?ticket=1786http://www2.lm-sensors.nu/~lm78/readticket.cgi?ticket=1811http://www2.lm-sensors.nu/~lm78/readticket.cgi?ticket=2052
It is still possible to forcibly enable the sensors by using the
force_addr module parameter.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Documentation/hwmon/via686a | 17 +++++++++++++++--
drivers/hwmon/via686a.c | 18 +++++++++++-------
2 files changed, 26 insertions(+), 9 deletions(-)
We can save 0.5kB of data in the via686a driver.
From: Denis Vlasenko <vda@ilport.com.ua>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Recent changes to the i2c-isa design broke the force_addr parameter of
two hardware monitoring drivers as a side effect: sis5595 and via686a.
The last address test was in fact useless beforehand, and the redesign
turned it into a bug. I'm sorry about that.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
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>
Call the ISA chip drivers detection function directly instead of relying
on i2c_detect. The net effect is that address lists won't be handled
anymore, but they were mostly useless in the ISA case anyway (pc87360,
smsc47m1, smsc47b397 had already dropped them).
We don't need to handle multiple devices, all we may need is a way to
force a given address instead of the original one (some drivers already
do: sis5595, via686a, w83627hf), and, for drivers supporting multiple
chips, a way to force one given kind. All this may be added later on
demand, but I actually don't think there will be much demand.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Convert the 10 ISA hardware monitoring drivers (it87, lm78, pc87360,
sis5595, smsc47b397, smsc47m1, via686a, w83627hf, w83627ehf, w83781d) to
explicitely register with i2c-isa. For hybrid drivers (it87, lm78,
w83781d), we now have two separate instances of i2c_driver, one for the
I2C interface of the chip, and one for ISA interface. In the long run,
the one for ISA will be replaced with a different driver type.
At this point, all drivers are working again, except for missing
dependencies in Kconfig.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch modifies sensors chip drivers to make use of the new
sysfs class "hwmon".
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>
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>
On Wednesday 22 June 2005 08:17, Greg KH wrote:
> [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>
Nice.
You missed some. This one is on top of your patch:
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
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>
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>
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>
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>
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>
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>
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!
Ingo Molnar