sh pci ops changes

mips pci ops changes

ia64 pci ops changes

pci_ops update for most of the alpha ports.

x86-64 pci changes

removed the pci_*_nodev functions, as the pci_bus_* functions should be used instead.

add pci_bus_* functions to replace the pci_read_* and pci_write_* functions.

The patch removes the pci_confN_(read|write)_config_(byte|word|dword) mess and
pares it down to pci_confN_(read|write).  This change is reflected in the
pci_ops structure, which only has read and write function pointers rather than
the byte, word, and dword versions.  These changes happen in the pci_conf(1|2)
and pci_bios read and write calls.

This patch also removes the pci_config_(read|write) function pointers.  People
shouldn't be using these (I don't think) and should be using the pci_ops
structure linked through the pci_dev structure.  These end up calling the same
functions that the pci_config_(read|write) pointers refer to anyway.

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

requested, also fix a possible race with two processes using the same
file descriptor.

Archs can define i8042 access in i8042-io*.h

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

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

Misc. kernel preemption-related bits.  Specifically,

 - update to Documentation/preempt-locking.txt (me)

 - preempt-safe arch/i386/kernel/ioport.c :: sys_ioperm()
   (George Anzinger)

 - remove "kernel_lock()" cruft in include/linux/smp.h
   (Andrew Morton)

 - we have a debug check in preempt_schedule that, even
   on detecting a schedule with irqs disabled, still goes
   ahead and reschedules.  We should return. (me)

 - preempt-safe net/core/dev.c :: netif_rx() (George Anzinger)

The raid5 xor checksums use MMX/SSE state and are not preempt-safe.

Attached patch disables preemption in FPU_SAVE and XMMS_SAVE and
restores it in FPU_RESTORE and XMMS_RESTORE - preventing preemption
while in fp mode.

Neither lockd nor rpciod properly drop the BKL on exit.

Yes, the BKL is automatically relinquished on schedule but the failure
to drop the lock throws off the atomic accounting and results in a
preempt_count warning on exit.

This makes them play fair - it does not hurt.

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

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

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

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

into nuts.ninka.net:/home/davem/src/BK/sparc-2.5

into nuts.ninka.net:/home/davem/src/BK/sctp-2.5