This one line patch fixes voltage rounding in the asb100 chip driver.
It's very similar to a patch I submitted for the lm80 a few days ago.

The following patch removes limits initialization in the via686a driver.
It was decided some times ago that this belongs to user-space, not
kernel. See the thread here:
http://archives.andrew.net.au/lm-sensors/msg06134.html

It also prevents the sensor chip from being savagely reset at load time.
This too follows a decision taken long ago that drivers should do as
little as possible in their init procedure. See the thread here:
http://archives.andrew.net.au/lm-sensors/msg04593.html

This should make the driver smaller, safer and faster to load. The same
was done to our 2.4/CVS version of the driver 5 months ago and it seems
to work just fine.

This one line patch fixes voltage rounding in the lm80 chip driver.

Hi nymisi, Greg:

* Nyeste Mihály <nymisi@freemail.hu> [2004-01-27 16:02:04 +0100]:
> Hi!
>
> I reported a bug of asb100 chip at:
> http://www2.lm-sensors.nu/~lm78/readticket.cgi?ticket=1539
>
> The reply was the follow:
>
> "Is there a BIOS option you can disable, e.g. Asus "COP",
> "QFAN", or some such?  My guess is that the BIOS is
> somehow interfering with the asb100 driver.  Otherwise
> I don´t know how this could happen.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Yeah, I wrote that.

"You do that, you go to the box, you know.  Two minutes by
yourself, and you feel shame, you know." - Denis the goalie

Greg, please apply this fix (vs. 2.6.5):

Here is a general pwm support cleanup patch for the w83781d chip driver.
Featuring:

* Don't pretend that we handle PWM on AS99127F chips. We don't know how
it works, and one of the register we are accessing for now is clearly
not a PWM register, and changing its value usually breaks temperature
readings.

* Discard irrelevant comments.

* Rewrite show_pwmenable_reg. It was obviously taken from the 2.4
driver, with unneeded tests and the code was much too complicated
anyway. And now we handle errors correctly.

* Initialize pwm_enable at load time. So far it was done conditionally
(if init=1) while it should always be done. And pwm2_enable wasn't read
from the chip, while it should.

I could test that my AS99127F doesn't expose pwm files through ssysfs
anymore. Which means that I couldn't test the rest of the pwm changes,
unfortunately.

I've applied similar changes to our 2.4/CVS repository.

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).

Please find below a patch against kernel 2.6.5-rc2-mm4 to add the pcf8591
driver (a 8-bit A/D and D/A converter). I have ported it from the 2.4
version, and it includes some fixes, improvements and simplifications.

It has been reviewed by Jean Delvare on IRC.

Please also note that the patch also fixes a missing space in
drivers/i2c/chips/Kconfig, introduced by the previous patch I sent you
concerning the pcf8574.

For some reason the original lm80 driver in 2.6 cannot set fan_divs
(while the 2.4 driver could). This patch brings support back. It was
lightly tested by one user.

This patch also suggests some code cleanups (fan code refactoring). I'll
send a different patch later for these.

ali1563_shutdown() is called from __init ali1563_probe() and hence cannot be
marked __init.

> Ick, no, we should be using the proper kernel call for this, swab16(),
> right?  Care to redo this patch to just fix the drivers and get rid of
> our duplicating of this function.

Oh, I didn't know such a function existed, sorry.

Here's a new patch, hope you like it. Tested to work on my as99127f, btw
(w83781d driver).

Documentation update follows (well, tomorrow it does).

The i2c interface on the 1563 is totally different than on both the 1533
and the 1535. It supports i2c 2.0, and happens to be nearly identical to
the interface on the i810 chipsets.

The simple patch below discards a comment in via686a referencing a file
that doesn't belong to the Linux tree. Now that I tell people not to do
that in my porting guide, we better follow our own advice.

Quoting Ralf Roesch:

> currently I'm only working with Linux MIPS 2.4 kernel,
> so it would be nice if you could forward the patch for 2.6.

OK, so here we are. Greg, this is the port to 2.6 of Ralf patch that
fixes an incorrect memset while initializing the eeprom driver. Please
apply.

Here is a patch to Documentation/i2c/sysfs-interface. This is mostly my
intent to make the document more readable. There are also a few
incorrectnesses fixed, and some comments added.

Here is an update to my 2.4 to 2.6 i2c client porting guide. The changes
were inspired by the feedback I got with the drivers that have been
ported so far.

Yet another patch for the adm1021 chip driver. I refined the detection
code a bit in order to prevent chip misdetection. Some chips handled
by the adm1021 driver are hard to detect and identify (LM84 and
MAX1617) so we tend to accept any chip it the valid I2C address range
as one of these. It has caused much, much trouble already. See these
threads for example:

http://archives.andrew.net.au/lm-sensors/msg04448.html
http://archives.andrew.net.au/lm-sensors/msg04624.html
http://archives.andrew.net.au/lm-sensors/msg05560.html
http://archives.andrew.net.au/lm-sensors/msg05871.html
http://archives.andrew.net.au/lm-sensors/msg06754.html
http://archives.andrew.net.au/lm-sensors/msg07181.html

And this ticket:

http://www2.lm-sensors.nu/~lm78/readticket.cgi?ticket=1434

So I thought it would be good to prevent this kind of problems if
possible, and read the 8 datasheets again in search for ways to refine
the detection method.

I changed it in sensors-detect already, and had positive feedback from
one user. I will also backport the changes to the driver to the 2.4
version we have in CVS.

What the patch does:

* Use unused bits of two more registers (configuration and conversion
rate) to reduce misdetections.

* Return with -ENODEV if the detection fails.

* Change the order in which we try to identify the chips. We better
finish with the LM84 and the MAX1617, in this order, because they are
harder to identify and are more likely to result in false positives.

* Refine LM84 detection. The LM84 has less features than the other
chips(chip cannot be stopped, conversion rate cannot be set, no low
limits) so it has extra unused bits.

* Do not intialize the chip if it was detected as an LM84. This one
cannot be stopped so why would we try to start it again? And as said
right before, conversion rate isn't changeable either.

Note that I couldn't test the changes on any supported chip since I
don't own any. Still I believe that they should be applied, since the
current code already broke one system and seriously harmed several
others. I believe it's not critical if it turns out that we reject
valid chips (which shouldn't happen if the datasheets are correct,
anyway). People will simply let us know and we'll be less restrictive.
In the meantime they can force the driver. That said, testers are
welcome, as usual.

Here is a patch that updates the w83627hf driver in the exact same way I
did recently for the w83781d driver. There were two problems:
1* Fan divisor storing code was ugly, badly ripped from the 2.4 w83627hf
   driver and/or the 2.6 w83781d driver.
2* Setting fan divisors wouldn't preserve fan mins.

Exactly the same as w83781d:
http://archives.andrew.net.au/lm-sensors/msg06952.html
http://archives.andrew.net.au/lm-sensors/msg07008.html

No surprise since the w83627hf driver is a fork of the w83781d driver.

Since the two drivers are strongly similar, I took the code directly
from the updated w83781d driver. I cannot test the w83627hf driver
(testers welcome BTW) but this makes me feel confident that the code is
correct.

To make it clear, this single patch is the w83627f equivalent of the
three patches I submitted for the w83781d:
* Cleanup
* Refactoring
* Setting fan_div preserves fan_min
All in one (much better looking BTW).

Quoting myself:

> 3* Drop adm1021's limit init. This was already done in the 2.4 driver
> and should have been done in 2.6 as well.

Here is a patch that does that. It also prevents bit 7 (and unused bits)
of configuration register from being reset, as was discussed before:
  http://archives.andrew.net.au/lm-sensors/msg04593.html
That second part needs to be backported to the 2.4 driver, and I will do
so.

Additionally, we get rid of a useless label.

The patch is untested (I don't own any supported chip) but quite
straightforward IMHO.

Quoting myself:

> While testing, I found a corner case that isn't handled properly. It
> doesn't seem to be handled by the lm78 and the asb100 either. Setting
> fanN_div before ever reading from the chip or setting fanN_min will
> make use of fanN_min while it was never initialized.

The following patch addesses the issue. Tested to work on my AS99127F
rev.1 (which means that only the changes to the w83781d driver were
actually tested). Testers welcome.

This simple patch discards an out-of-date comment in the adm1021 driver.
I've done the same in our CVS repository where many more drivers were
affected.

I agree it's not very important, but I prefer it to be done before any
driver with the error is used as a base to port a new driver, and the
misinformation spreads.

Please find below a patch against kernel 2.6.5-rc1 to add the pcf8574
driver (an I/O expander for the I2C bus). I have ported it from the 2.4
version, and it includes some fixes and simplifications.

It has been reviewed by Jean Delvare on IRC.

Quoting myself:

> This tends to increase the size of the three set_store_regs_fan_div
> functions, and I am considering refactoring them at some point. Later
> though.

Here is the promised refactoring. Tested on my AS99127F rev.1, seems to
work. As for the previous patch, there is a part that I cannot test with
the AS99127F, so additional testing is welcome.

I agree this makes the code slightly less readable, but this saves 60
lines of code (1754 bytes, around 3% of the driver total), and is
actually far less complex that I first feared.

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into ppc970.osdl.org:/home/torvalds/v2.6/linux

We no longer have a CPU_OFFLINE notifier: we freeze the machine and
kill the CPU atomically.  Remove it.

Various files keep per-cpu caches which need to be freed/moved when a
CPU goes down.  All under CONFIG_HOTPLUG_CPU ifdefs.

scsi.c: drain dead cpu's scsi_done_q onto this cpu.

buffer.c: brelse the bh_lrus queue for dead cpu.

timer.c: migrate timers from dead cpu, being careful of lock order vs
	__mod_timer.

radix_tree.c: free dead cpu's radix_tree_preloads

page_alloc.c: empty dead cpu's nr_pagecache_local into nr_pagecache, and
	free pages on cpu's local cache.

slab.c: stop reap_timer for dead cpu, adjust each cache's free limit, and
	free each slab cache's per-cpu block.

swap.c: drain dead cpu's lru_add_pvecs into ours, and empty its committed_space
	counter into global counter.

dev.c: drain device queues from dead cpu into this one.

flow.c: drain dead cpu's flow cache.

Keep track of kswapds: it's OK that they get moved off a node when the
last CPU goes down, but when a CPU comes back, we should try to move
the kswapd back onto its node.

Workqueues need to bring up/destroy the per-cpu thread on cpu up/down.

1) Add a global list of workqueues, and keep the name in the structure
   (to name the newly created thread).

2) Remove BUG_ON in run_workqueue, since thread is dragged off CPU when
   it goes down.

3) Lock out cpu up/down in flush_workqueue, create_workqueue and
   destroy_workqueue.

4) Add notifier to add/destroy workqueue threads, and take over work.

Change ksoftirqd not to assume it's on the CPU: when a cpu goes down,
it will be rudely dragged off.  Since do_softirq() uses
smp_processor_id(), it's easiest to disable preemption, check that the
cpu is still up, then call do_softirq().

If the cpu is actually offline, wait for the notifier, which kills us.

Take over tasklets from dead cpu in the notifier.

Clean up redundant double assignment in CPU_UP callback.

Add hook for RCU to handle jobs on dead cpu.  Requires new
tasklet_kill_immediate for RCU to clean up its tasklet (which might
have been about to run, so tasklet_kill won't work).

Change the migration thread to directly use its cpu arg, rather than
smp_processor_id(): if a cpu goes up then down rapidly, it can be on
the wrong cpu just before it is stopped.

Add code to stop the migration thread on CPU_DEAD and CPU_UP_CANCELED.

Remove the (bogus) priority of the notifier.