summaryrefslogtreecommitdiff
path: root/drivers
diff options
context:
space:
mode:
authorDenis Vlasenko <vda@ilport.com.ua>2005-06-22 07:25:13 (GMT)
committerGreg Kroah-Hartman <gregkh@suse.de>2005-07-11 21:10:36 (GMT)
commit6328c0e163abfce679b1beffb166f72900bf0a22 (patch)
treed5fa7087c5d18b12bd1b93797de2277bddcb6300 /drivers
parent200d481f28be4522464bb849dd0eb5f8cb6be781 (diff)
downloadlinux-fsl-qoriq-6328c0e163abfce679b1beffb166f72900bf0a22.tar.xz
[PATCH] I2C: Coding style cleanups to via686a
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>
Diffstat (limited to 'drivers')
-rw-r--r--drivers/i2c/chips/via686a.c12
1 files changed, 6 insertions, 6 deletions
diff --git a/drivers/i2c/chips/via686a.c b/drivers/i2c/chips/via686a.c
index 137d9b7..164d479 100644
--- a/drivers/i2c/chips/via686a.c
+++ b/drivers/i2c/chips/via686a.c
@@ -1,9 +1,9 @@
/*
via686a.c - Part of lm_sensors, Linux kernel modules
- for hardware monitoring
+ for hardware monitoring
Copyright (c) 1998 - 2002 Frodo Looijaard <frodol@dds.nl>,
- Kyösti Mälkki <kmalkki@cc.hut.fi>,
+ Kyösti Mälkki <kmalkki@cc.hut.fi>,
Mark Studebaker <mdsxyz123@yahoo.com>,
and Bob Dougherty <bobd@stanford.edu>
(Some conversion-factor data were contributed by Jonathan Teh Soon Yew
@@ -171,18 +171,18 @@ static inline u8 FAN_TO_REG(long rpm, int div)
/******** TEMP CONVERSIONS (Bob Dougherty) *********/
/* linear fits from HWMon.cpp (Copyright 1998-2000 Jonathan Teh Soon Yew)
if(temp<169)
- return double(temp)*0.427-32.08;
+ return double(temp)*0.427-32.08;
else if(temp>=169 && temp<=202)
- return double(temp)*0.582-58.16;
+ return double(temp)*0.582-58.16;
else
- return double(temp)*0.924-127.33;
+ return double(temp)*0.924-127.33;
A fifth-order polynomial fits the unofficial data (provided by Alex van
Kaam <darkside@chello.nl>) a bit better. It also give more reasonable
numbers on my machine (ie. they agree with what my BIOS tells me).
Here's the fifth-order fit to the 8-bit data:
temp = 1.625093e-10*val^5 - 1.001632e-07*val^4 + 2.457653e-05*val^3 -
- 2.967619e-03*val^2 + 2.175144e-01*val - 7.090067e+0.
+ 2.967619e-03*val^2 + 2.175144e-01*val - 7.090067e+0.
(2000-10-25- RFD: thanks to Uwe Andersen <uandersen@mayah.com> for
finding my typos in this formula!)