into home.transmeta.com:/home/torvalds/v2.5/linux

into home.transmeta.com:/home/torvalds/v2.5/linux

into mandrakesoft.com:/home/jgarzik/repo/net-drivers-2.5

into mandrakesoft.com:/home/jgarzik/repo/irda-2.5

	code-duplication that existed between ACPI and the ia64 IOSAPIC code.
	To make this work, the Makefiles had to be re-organized to ensure that
	the ACPI subsystem is initialized before PCI (even though both are called
	via subsys-initcalls).

o [FEATURE] Cleanly change speed back to 9600bps
o [CORRECT] Change speed under spinlock/irq disabled
o [CORRECT] Make sure interrupt handlers don't mess irq mask
o [CORRECT] Don't change speed if we haven't fully finished to Tx

into tiger.hpl.hp.com:/data1/bk/lia64/to-linus-2.5

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

Fix errors due to header differences between mainline kernel and
acl.bestbits.org patches.

into kleikamp.austin.ibm.com:/home/shaggy/bk/jfs-2.5

Existing OS/2 extended attributes are stored without a namespace
prefix.  To avoid polluting the linux namespace, prepend "os2." when
listing the EAs but store "os2." EA names without the prefix.

Also disallow setting extended attributes that don't begin with
"user." or "os2."

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

into mandrakesoft.com:/home/jgarzik/repo/net-drivers-2.5

into mandrakesoft.com:/home/jgarzik/repo/net-drivers-2.5

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

This makes the in_atomic() check in schedule() actually work.  You
merged the PREEMPT_ACTIVE bits, we just need to handle the exit() case
correctly.

into mandrakesoft.com:/home/jgarzik/repo/net-drivers-2.5

(Bjoern A. Zeeb)

into hostme.bitkeeper.com:/ua/repos/j/jfs/linux-2.5

into groveronline.com:/root/bk/linux-acpi

I discovered this while auditing a large part of the remaining
lock_kernel users in the 2.5.x tree.

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

into vc.cvut.cz:/mnt2/usr/src/bk/linus/ncpfs

deliver server messages to logged-in users even with UDP or TCP transport.

ncpfs: Add support for packet signatures when using TCP transport.

since the thread_info support went in (early July), and can cause
lockups at X startup etc.

This adds the basic driver model support for the IDE subsystem.

Basically, it registers the controllers and devices with the driver
model core, which puts them in the device tree and gets them a directory
in driverfs.  The driverfs layout looks like this (on my workstation):

	[mochel@cherise mochel]$ tree -d /sys/root/pci0/
	/sys/root/pci0/
	|-- 00:00.0
	|-- 00:01.0
	|   `-- 01:00.0
	|-- 00:02.0
	|   `-- 02:1f.0
	|       `-- 03:00.0
	|-- 00:1e.0
	|   `-- 04:04.0
	|-- 00:1f.0
	|-- 00:1f.1
	|   |-- ide0
	|   |   |-- 0.0
	|   |   `-- 0.1
	|   `-- ide1
	|       |-- 1.0
	|       `-- 1.1

The drive bus IDs (the directory names)  are created using this:

	sprintf(bus_id,"%u.%u",hwif->index,unit);

which should give each drive a unique name for the entire system, right?

I've also created a struct bus_type for IDE, which gives ide a directory
in the driverfs bus/ directory. The layout of that is:

	[mochel@cherise mochel]$ tree -d /sys/bus/ide/
	/sys/bus/ide/
	|-- devices
	|   |-- 0.0 -> ../../../root/pci0/00:1f.1/ide0/0.0
	|   |-- 0.1 -> ../../../root/pci0/00:1f.1/ide0/0.1
	|   |-- 1.0 -> ../../../root/pci0/00:1f.1/ide1/1.0
	|   `-- 1.1 -> ../../../root/pci0/00:1f.1/ide1/1.1
	`-- drivers

Those are symlinks under devices/ (which is why the drive names must be
unique..). When drivers are registered with the IDE core, they should also
be passed through the core, which will give them a directory in the
drivers/ directory just above.

In general, there is a bit of code that can be cleaned up, and some
explicit calls removed, because of the way the driver model core works.
Most of these are pretty simple, and barring any objections, I will
implement and send them to you.

starting from 2.5.35 IDE stopped working on my alphas because of
following problems:

- ide_hwif_configure() ignores BARs for IDE base/control registers
  and assumes legacy 0x1f0/0x170 ports, unless controller reports
  native PCI mode (ProgIf bits 0 and 2).

  This is incorrect, as there are quite a few IDE chips operating
  in "semi-legacy" mode, i.e. legacy interrupts, but functional
  BAR0-3, like cy82c693 and ali5229. I guess Andre could give a lot
  more examples. :-)

  This happens to work on i386 simply because BIOS usually assigns
  legacy values to BAR0-3, but we can't rely on it.

  Just checking respective resource->start for zero should work in
  all cases.

- ide_pci_check_iomem(): resource->flags == 0 means "unconfigured" as well.
  Thus we avoid false positives.

- Apparently cut'n'paste typo in cy82c693.c - wrong PCI IDs.