As a bonus: cris, h8300, m68k and sparc can use CONFIG_HOTPLUG now.

Thanks to stephanrave@gmx.de (Stephan Rave) for the patch.

Please consider the following patch for submission.  This patch contains the
implementation of the I/O Slot DLPAR Drivers for PPC64 RISC Platform
Architecture.  This module depends on the RPA PCI Hotplug Module in the
previous post.  The patch is made against kernel version 2.6.3-rc2.

The Dynamic Logical Partitioning Module allows the runtime movement of I/O
Slots between logical partitions.  An administrator can logically add/remove
PCI Buses to/from a PPC64 partition at runtime.  These operations are initiated
using interface files located at:
/sys/bus/pci/pci_hotplug_slots/control/
Development contact for this module is John Rose (johnrose@austin.ibm.com).

It occured to me that we also have the following related code in pci.h:
Perhaps this should be removed as well?

pci_bus_find_capability() is currently broken.  It checks the wrong
device's hdr_type for being a cardbus bridge or not.  This patch pulls
the guts of pci_bus_find_capability() and pci_find_capability() into a
new function __pci_bus_find_cap() and changes these two functions to
call it.

First I would like to say sorry for not responding immediately after receiving
your email mentioning Copyright. I have contacted Intel Legal for proper text
upon receiving this email; but have not received any response. As a result of
team discussion, the attached patch, based on Linux kernel 2.6.3-rc2, includes
the Intel Copyright for files: msi.h and msi.c.

I'm working with some Marvell components (formerly Galileo Technologies)
and noticed that the entries in include/linux/pci_ids.h have become
dated.  I have attached a patch that changes 'GALILEO' to 'MARVELL',
adds some more devices, and updates the uses of the macros in the code.
Please note that the newer marvell parts start with 'MV' instead of 'GT'
to represent the new name.  Also, I didn't change all uses of galileo to
marvell, only the macro in pci_ids.h.

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

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

into redhat.com:/spare/repo/net-drivers-2.5

into redhat.com:/spare/repo/netdev-2.6/netdev-alloc-7

into redhat.com:/spare/repo/netdev-2.6/netdev-alloc-6

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

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

into redhat.com:/spare/repo/netdev-2.6/netdev-alloc-7

From: Neal Stephenson <neal@bakerst.org>

In 2.6.2, I noticed that my modprobe.conf line for tuner "options tuner
type=2" no longer worked.  It even failed with insmod "insmod tuner.ko
type=2".  dmesg reported

vmunix: tuner: chip found @ 0xc0
vmunix: tuner: type set to 19 (Temic PAL* auto (4006 FN5))
vmunix: tuner: type forced to 19 (Temic PAL* auto (4006 FN5)) [insmod]

I noticed that the a line had been removed from 2.6.1 and when it is added
everything works again.

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

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

Disable the RADEON_PARAM_SAREA_HANDLE ioctl on 64-bit architectures,
since it is only used on some embedded platforms, and it isn't 64-bit
safe.

drivers that need it. 

This allows us to have I2C as a module iff the FB driver
that needs it is a module.

This allows us to do something like

	config FB_RADEON
		select I2C_ALGOBIT if FB_RADEON_I2C

where FB_RADEON_I2C itself depends on FB_RADEON without getting a bogus
warning about recursive dependencies.

This matters because the select takes the default minimum dependancy
from the parent menu, so we want to do this under FB_RADEON rather than
under FB_RADEON_I2C (so that the I2C_ALGOBIT config depends properly
on the state of FB_RADEON)

	We used to have sync_blockdev() on each normal (== non-raw)
blkdev_put() + kill_bdev() on the final blkdev_put().  That worked
fine until we'd moved sync_blockdev() to the final blkdev_put().

	Now we have a nasty scenario:

open block device
open raw device
write on block device	# data ends up in cache
close block device	# no sync here, we still have the sucker opened
close raw device	# no sync here either
			# ... and cache is killed by kill_bdev()

	IOW, if we postpone sync to final close, we must do it regardless of
kind of close.  Otherwise we are in for data corruption and yes, it is easy
to trigger.  Fix is obvious...

1) First action must be to set MAC_EVENT to zero.
2) Do not forget to clear MI_COMPLETION/LNKSTATE_CHANGED
   status bits in MAC_STATUS register.

This fixes the bug wherein the link does not come up at all
at the first ifup done after tg3 module load.

kunmap_atomic() takes a kernel-virtual address, not a pageframe address.

(Very common problem.  We really should make the atomic kmap functions
type-safe).

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

There's a fencepost error in the GART IOMMU handling on x86_64
in the unmap path.  When testing to see if the bus address is
within the IOMMU window and needs to be unmapped, the start of
the first page *beyond* the window also passes the test.  This
can cause the first doubleword of the next page beyond the gatt
table to be smashed to zero, with unpredictable results depending
on what that page is used for.

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

The attached trivial patch should fix the "i1-dig" build failure reported
on this page:

	http://www.gelato.unsw.edu.au/kerncomp/

and should make it easier to build a properly configured ia64 kernel.

This is a cleaned-up version of a mremap() fix for "move_one_page()"
by Rajesh Venkatasubramanian <vrajesh@umich.edu>. We could use a NULL
"src" pointer.

Because while we do hold the MM semaphore over the whole sequence, the
destination page table allocation will possibly drop the page table
spinlock.  That in turn can cause a clean source page to be stolen by
page reclaim, causing the source-side "get_one_pte_map_nested()" to
return NULL the second time around even if it didn't on the first case.

So we just check "src" again, and get rid of the bogus TLB invalidate
while we're at it.

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

My "__ide_dma_off()" cleanup uncovered some code that shouldn't be compiled
when CONFIG_BLK_DEV_IDEDMA=n.  Fix it and kill a warning in setup-pci.c.

Noticed by Martin Diehl <lists@mdiehl.de>.