Following patch fixes the bug introduced by me in VID VRM patch.
Spotted (and later reviewed) by Jean Delvare. This bug is non-fatal,
it8712 will be just treated as it was before my VID VRM patch.

Tested on it8705 and it8712  hardware.
Signed-off-by: Rudolf Marek <r.marek@sh.cvut.cz>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch kills a specific kind of ugly and ultimately useless macro
abuse found in many sensors chip drivers.  Compile tested only.
Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This trivial patch enforces the rule that global variables should not be
explicitely initialized to 0 for all i2c chip drivers.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch changes all the i2c chip drivers and documentation to use the
name "cpu0_vid" instead of "in0_ref". The name "in0_ref" was an error in
the first place as motherboard manufacturers may fail to follow the chip
manufacturer's recommendation about which "in" channel to use for VCore
monitoring.

The new name leaves room for chips able to monitor more than 1 vid
value, such as the LM93 and, to a lesser extent, the PC87360 family (all
by National Semiconductor). These chips are typically designed for
dual-CPU motherboards.

This breaks the interface (obviously) so libsensors has been updated to
support both names.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This is second part, which just adds the functionality to existing code
base, also including support of vid inputs for it8712 chip.

This patch was also briefly reviewed by Jean Delvare.
Signed-off-by: Rudolf Marek <r.marek@sh.cvut.cz>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This is more like the original code.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Attached is a cleanup patch for the it87 sensor driver, against
2.6.7-rc2. Jean Delvare has reviewed it.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Jean Delvare <khali@linux-fr.org> writes:
> So I'd suggest that you simply use the standard exit sequence in the
> it87 driver (the second one in your current patch). A patch for the 2.4
> driver would be appreciated as well.

OK.  I've attached a new version of the patch against linux-2.6.6.
I'll send a patch against current lm_sensors CVS removing the extra
exit command in a separate mail.

Greg KH <greg@kroah.com> writes:
> On Wed, May 12, 2004 at 04:38:03PM +0200, Bj?rn Mork wrote:
>> +	if (!it87_find(&addr)) {
>> +		printk("it87.o: new ISA address: 0x%04x\n", addr);
>
> That printk is wrong (no KERN_ level, or dev_printk() style use).
> Please fix it in your next revision of this patch.

Errh, I just added it to document my sloppyness.  It was never meant
to be in the patch I sent you.  Sorry.  Removed in the attached patch.
The style of these drivers seem to be "just working, making no noise"
so I assume informational printk's are unwanted.

Quoting myself:

> Mmm, I once proposed that I2C_ADAP_CLASS_SMBUS would be better renamed
> I2C_ADAP_CLASS_SENSORS (so I2C_CLASS_SENSORS now). What about that? I
> think it would be great to embed that change into your patch, so that
> the name changes only once.
>
> BTW, if HWMON is prefered to SENSORS, this is fine with me too, I
> have no strong preference.

Below is a patch that does that. I finally went for HWMON. Yes, it's
big, but it's actually nothing more than
s/I2C_CLASS_SMBUS/I2C_CLASS_HWMON/ (thanks perl -wip :)).

in the "[RFC|PATCH][2.6] Additional i2c adapter flags for i2c client
isolation" thread, the i2c people have  agreed that an ".class" field
should be added to struct i2c_driver.

Currently only drivers do checks for plausibility ("Is this an adapter I
can attach to?"), but adapters don't have a chance to keep drivers away
from their bus.

If both drivers and adapters provide a .class entry, the i2c-core can
easily compare them and let devices only probe on busses where they can
really exist.

Real world example: DVB i2c adapters cannot ensure that only known DVB
i2c chipsets probe their busses. Most client drivers probe every bus
they get their hands on. This will confuse some DVB i2c busses.

With the new I2C_CLASS_ALL flag it will be possible that an adapter can
request that really all drivers are probed on the adapter. On the other
hand, drivers can make sure that they get the chance to probe on every
i2c adapter out there (this is not encouraged, though)

The attached patch does the first step:
- add .class member to struct i2c_device
- remove unused .flags member from struct i2c_adapter
- rename I2C_ADAP_CLASS_xxx to I2C_CLASS_xxx (to be used both for
  drivers and adapters)
- add new I2C_CLASS_ALL and I2C_CLASS_SOUND classes
- follow these changes in the existing drivers with copy & paste

Here comes the patch that fixes error paths in the it87 and via686a
detection functions. The it87 part also adds missing error values.

Additional remarks:

1* This patch also removes an unused struct member in via686a and fixes
an error message in ds1621.

2* I discovered error path problems in it87 and via686a detection
functions. For the it87, I think that this patch makes it even more
broken. I will fix both drivers in a later patch (really soon).

A number of chip drivers in 2.6.4-mm1 try to handle an error case that
cannot happen when setting the chip name. The following patch changes
that.

Affected drivers: adm1021, it87, lm75, lm78, lm85, w83627hf, w83781d.

Note that in any case, the worst that could happen (but then again, it
cannot happen) is that the chip name would be set to an empty string,
which doesn't hurt much.

The patch also cleans up a few things in it87, w83627hf and w83781d,
which are tightly related to the rest of the changes and necessary for
them to be safe.

it87: There is only really one "kind" in this driver, so I removed all
references to other kinds.

w83627hf: The driver did not handle unknown chips.

w83781d: The user shouldn't be allowed to force a kind that doesn't
match the chip's bus type (I2C or ISA). The code was not meant to handle
that case, although no check was done so far.

Tested on my AS99127F, works as intended.

This patch is a refactoring of some common code among all sensors chip
drivers (except asb100, which was written this way to begin with.)
It saves a handful of lines and ~100-300 bytes per module.  It compiles
ok.  I've only tested it against one of the drivers, but the changes are
similar across the board and quite mechanical.  Please apply.

I wrote a patch which adds reset option to the it87 driver talking
with Jean Delvare.

* Do not reset the registers unless users want to do because
  resetting registers makes all fans go to full power and we can
  usually rely on values set by BIOS
* Remove all limit initializations as they should be done from
  user-space
* Better register mask for start of monitoring

Here is the second step of my sysfs renaming plan.

This one does the following renames (as I already announced on the
LKML):
temp<n>_hyst  -> temp<n>_max_hyst or temp<n>_crit_hyst
sensor<n>     -> temp<n>_type
pwm<n>        -> fan<n>_pwm
pwm<n>_enable -> fan<n>_pwm_enable
vid           -> in<n>_ref

The associated libsensors patch is here:
http://jdelvare.net1.nerim.net/sensors/libsensors-sysfs-names-2.diff
(not applied yet, on purpose)


Note that the w83781d part is a bit more complex, not only because it is
the only driver to require the 5 changes, but also because at some point
the macros assume that the internal variable names match the sysfs
names, so I had to change them too (better than rewriting the macros,
methinks).

For reference, here is the list of changes, by driver:

asb100:
    hyst -> max_hyst (4)
    pwm -> fan_pwm (1)
    pwm_enable -> fan_pwm_enable (1)
    vid -> in_ref (1)
fscher:
     pwm -> fan_pwm (3)
gl518sm:
    hyst -> max_hyst (1)
it87:
    sensor -> temp_type (3)
lm75:
    hyst -> max_hyst (1)
lm78:
    hyst -> max_hyst (1)
    vid -> in_ref (1)
lm85:
    pwm -> fan_pwm (3)
    pwm_enable -> fan_pwm_enable (3)
    vid -> in_ref (1)
lm90:
    hyst -> crit_hyst (2)
via686a:
    hyst -> max_hyst (3)
w83781d:
    hyst -> max_hyst (2)
    sensor -> temp_type (3)
    pwm -> fan_pwm (4)
    pwm_enable -> fan_pwm_enable (1)
    vid -> in_ref (1)

There's also a documentation update. There will be one more after that
(to make it more readable, no contents change), and a patch to lm83.c to
bring it to compliance with the (new) standard. (If you wonder why I did
not change it with the other drivers: because it was *already* not in
compliance with the old standard. There's some real work to do for this
one.)

Here it is. The associated libsensors patch is here:
http://jdelvare.net1.nerim.net/sensors/libsensors-sysfs-names-1.diff
(not applied yet, on purpose)

Here comes a patch by Takeru Komoriya which fixes the way the it87
driver handles temperature sensor types selection.

* Use the same values as the CVS driver and sensors program.
* Better comments.
* Get rid of the old setting method (already gone in CVS).
* Handle invalid values correctly.

This patch brings the name field of adm1021.c, it87.c and via686a.c in
conformance with the defined standard ("all lowercase, as simple as the
driver name itself").

drivers/i2c/chips/it87.c:130: warning: conflicting types for built-in function 'log2'

This cleans up the mismatch of ways we could enable debugging messages.

> it87 and via686a violate the sysfs standard by having "alarm" instead
> of "alarms", would you please fix in your next patch?

I'm not the only one allowed to send patches to Greg, you know ;)
Anyway, here we go. Greg, here is a patch that corrects the standard
violation reported by Mark. Tested to compile.

(It also removes a useless comment in it87.c.)

Summary of the changes:
adm1021.c: No changes, that chipset uses a real min/max model.
eeeprom.c: No changes (obviously).
it87.c:    Remove buggy comments (obviously taken from via686a) about
           max and min temperature limits being over and hyst. This
           isn't the case for this driver (min/max model).
lm75.c:    Simple sysfs file name change (temp_min to temp_hyst).
lm78.c:    Simple sysfs file name change (temp_min to temp_hyst).
lm85.c:    No changes needed (min/max model).
via686a.c: Rename functions and macros from min/max to hyst/over, what
           it really is. Remove unnecessary comments. Rename sysfs
           files from temp_min[1-3] to temp_hyst[1-3].
w83781d.c: Rename variables from temp_min* to temp_hyst* (needed so
           that the macros keep working). Update macro calls
           accordingly. Fix writing temp to max and hyst being
           swapped.

Additional remarks:

The lm75 and lm78 having a single temperature channel, there is no
number appended to the file names. Shouldn't a "1" be appended in this
case? I think it would make it easier for the future library to catch
all the files.

I made sure the drivers would still compile after the changes, but did
not test them otherwise (no working 2.6.0 kernel here, and not all the
hardware anyway).

fixes all chip drivers by moving the initialization before any sysfs
entry is created.

> That's what you are going to have to set the name file to in the
> i2c_client structure, much like your patch did.  Then look at the
> different name files in each device directory to see what kind of device
> it is (chip, subclient, etc.)

OK attached patch sets all names to just chip name for chips themselves and
"chipname subclient" when subclient ios registered.

This is because the name field of struct device is going away, and the name
fields on these i2c structures are useful for people.

Well, this is it for me and strlcpy. I'll leave the rest of the
non-obvious usages of strncpy to the kernel janitors. Seems like quite a
few uses really wanted memcpy instead, but I don't have time to
investigate them all. It does appear that nearly all strncpy's will be
removable. Obsoleting strncpy will probably atleast make the remaining
few think about how they are using it.

This is the patch for my trip through drivers/*.

Trivial, but important.

Somehow in the patching the bk tree somehow got two memset's to clear
new_client in it87_detect, normally while this would be bad, it would
not be critical.

However one of the two happens BEFORE the variable is set, and thus
things go badly.

Don't provide min/max for in8, which allowed one to scribble on
registers one should not be messing with. (My fault, oops.)

The setting of the temp high/low registers was off by one, not mine this
time.  While I was at it, I reordered a few other register accesses to
be base 0 instead of base 1.

The temp interface was slightly incorrect, degrees * 100 instead of
degrees * 1000, also fixed.

And lastly, when changing the fan count divisor, fix up the min setting
to still be roughly the same. (Previously the meaning of the value in
the register changed, but not the value itself, resulting in, undesired
surprises.)

Ok, after writing up something in the way of a perl script to make some
sense of the data for voltages, and finding that there is no sense to
make, I took a longer look at things.

The it87 driver in 2.5.x is doing some, down right /odd/ math on the
numbers for the in_input* readings, and the 2.4.x driver is doing
something quite different.

And while it might be possible to get sane numbers out of the 2.5.x
driver, people /expect/ to get the numbers that they were getting from
2.4.x.

So this patch puts things back to the simpler calculations done by the
2.4.x lm-sensors drivers, and my script confirms that the numbers come
out right.

This is against my last.

While the old code most definitely did /something/ to the register for
setting the fan div, the 'what' is a more interesting question.

To be honest I could not figure out what it was trying to do, because
the way it was inserting values disagreed with not only the data sheet,
but how it parsed the very same register.

This corrects the issue, and allows one to properly control the divisor
on all 3 fans, including the (much more limited) 3rd fan.

More or less straight forward patch.

Fix a typo in the comments at the top.
Show all 9 voltage inputs.
Show all 3 fan inputs.
Allow you to select the temp sensor type from the sysfs interface,
instead of just with the temp_type module option.
(1 = diode, 2 = thermistor, 0 = disabled).

I'm still trying to figure out the registers for PWM fan controller
support.

This is the last of three patches for i2c.  It introduces a new field
to i2c_adapter which classifies the kind of hardware a i2c adapter
belongs to (analog tv card / dvb card / smbus / gfx card ...).  i2c chip
drivers can use this infomation to decide whenever they want to look for
hardware on that adapter or not.  It doesn't make sense to probe for a
tv tuner on a smbus for example ...