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

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

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

Patch from Adrian Bunk

Patch from Bjorn Helgaas

ACPI and HCDP tell us what IRQ the serial port uses, so there's
no need to have the driver probe for the IRQ.

Patch from Steve Youngs

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

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

From: Arnd Bergmann <arnd@arndb.de>

Adds a generic implementation of 32 bit emulation for IPC system calls.  The
code is based on the existing implementations for sparc64, ia64, mips, s390,
ppc and x86_64, which can subsequently be converted to use this.

into kernel.bkbits.net:/home/davem/net-2.6

into kernel.bkbits.net:/home/davem/sparc-2.6

into nuts.davemloft.net:/disk1/BK/net-2.6

This patch declares all possible functions static.

Based on the kobject structure, but much smaller and simpler to use.

Against Jon's cdev stuff

They are obsolted by the i2c-parport.c driver.

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

This symbol is no longer used in modules.

Patch from Jonas Larsson

This patch adds devfs_name member to struct uart_driver. No devfs
entries are created for the serial port without this patch.

Provide more detailed information on machine types and machine
classes.

Patch from Marc Singer

Updates to the ARM architecture README file.  Mostly, this is done for
clarity.

into kroah.com:/home/greg/linux/BK/i2c-2.6

The following patch against kernel 2.6.4-mm1 adds the ds1621 driver (an
I2C sensor). I have ported it from the 2.4 version.

It has been reviewed by Jean Delvare, partly on IRC, and it is
"compliant" with Mark Hoffman's refactoring.

This patch makes the w83781d driver preserve fan_min settings when the
user changes fan_divs. This isn't done "by default" because the actual
fan min value (in RPMs) depends on both the fan_min register and the
fan_div register. Only two drivers handle it properly at the moment as
far as I know (lm78 and asb100). Several other drivers would need to be
fixed the same way, but well, once at a time ;)

Tested on my AS99127F rev.1.

Credits go to Philip Pokorny, since I think I remember he is the one who
introduced the method in the lm78 driver in the first place.

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.

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.

I just noticed that I am doing something wrong in the i2c chip drivers I
ported to Linux 2.6. If these drivers are forced to a specific chip type
("kind" as we call it internally), then the device doesn't have its name
set (and defaults to an empty string).

Affected drivers: gl518sm, lm83, lm90, w83l785ts.

I could verify the problem on my ADM1032 chip (lm90 driver). I also
verified that the proposed patch fixes the issue.

You may notice that I fix the problem differently for gl518sm and
w83l785ts on the one hand, and lm83 and lm90 on the other hand. This is
because the first two drivers are not expected to support more a single
chip in the future, while lm90 already does and lm83 could someday (for
example, support for the LM82 could be added on request).

When Tun initialization fails it shouldn't obscure the error return,
There are several reasons it could fail, and when diagnosing user problems
the error code might provide more info.