Some of these may not have seen review on linux-pci, so I'm sending them out
for comment before I send Linus the pull request.

Any comments/objections?

The biggest patch by far is the resource_wc stuff; it should have been pushed
earlier, but for some reason I thought Ingo & co. were going to do that...

Thanks,
Jesse

commit a123c3d9643464c56417680536ed9515f15cffa1
Author: Yinghai Lu <Yinghai.Lu@Sun.COM>
Date:   Mon May 12 21:21:05 2008 +0200

    PCI: use dev_to_node in pci_call_probe
    
    to make sure get one online node.
    
    Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>

diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 72cf61e..e1637bd 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -181,7 +181,7 @@ static int pci_call_probe(struct pci_driver *drv, struct pci_dev *dev,
 	   any need to change it. */
 	struct mempolicy *oldpol;
 	cpumask_t oldmask = current->cpus_allowed;
-	int node = pcibus_to_node(dev->bus);
+	int node = dev_to_node(&dev->dev);
 
 	if (node >= 0) {
 		node_to_cpumask_ptr(nodecpumask, node);

commit d99f75679d17ada3e90a04c50605f90a6a590e45
Author: Miquel van Smoorenburg <mikevs@xs4all.net>
Date:   Thu Jun 5 18:14:44 2008 +0200

    x86/PCI: pci-dma.c: don't always add __GFP_NORETRY to gfp
    
    Currently arch/x86/kernel/pci-dma.c always adds __GFP_NORETRY
    to the allocation flags, because it wants to be reasonably
    sure not to deadlock when calling alloc_pages().
    
    But really that should only be done in two cases:
    - when allocating memory in the lower 16 MB DMA zone.
      If there's no free memory there, waiting or OOM killing is of no use
    - when optimistically trying an allocation in the DMA32 zone
      when dma_mask < DMA_32BIT_MASK hoping that the allocation
      happens to fall within the ...
[ message continues ]

Although I quite appreciate the addition of patches, IMO it would be 
easier to read if the patch descriptions and patches were not mixed 
together.

Most 'git pull' things I've seen include a changeset summary (shortlog) 
and cumulative patch, when its a single email.  Sometimes (i.e. GregKH 
and a few others) the individual patches are posted in separate emails.

Either way, it saves one from having to wade through a long email, just 
to get an idea of the sum total of the changes...

Regards,

	Jeff




--

[ message continues ]

Right, I probably should have used one of the git mail scripts... but this 
wasn't a real git pull request either, more of a "hey please sanity check 
this" type thing.  I figured in this case keeping the changelogs was 
important, but didn't want to spam people with a bunch of messages when the 
total size really wasn't that big...

Jesse
--

[ message continues ]

Hi Jesse,


A bunch of THREADED messages are quite easy to skip (single keystroke for me).

So just use one of those git mail scripts, which can do threading 
and everyone is happy.

Best Regards

Ingo Oeser, wading through lkml since >10 years.
--

[ message continues ]