PCI patches for 2.6.25-git

Here are a some PCI and PCI hotplug patches against your 2.6.25 git tree.

They contain:
- documentation movement into a new directory
- pci section warning fixes
- more generic PCI code for some arches
- removal of the duplicated list of all PCI devices in the system
- second go-around for the PCI ASPM code
- various bugs and other minor stuff
- change the PCI maintainer

All of these have been in the linux-next and -mm tree for quite a while.

Please pull from:

	master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6.git/

The full patches will be sent to the linux-pci mailing list, if anyone wants to see it

thanks,

greg k-h

 Documentation/00-INDEX                         |   10 -
 Documentation/ABI/testing/sysfs-bus-pci        |   11 +
 Documentation/PCI/00-INDEX                     |   12 +
 Documentation/{ => PCI}/PCIEBUS-HOWTO.txt      |   12 +-
 Documentation/{ => PCI}/pci-error-recovery.txt |    0 
 Documentation/{ => PCI}/pci.txt                |    2 +-
 Documentation/{ => PCI}/pcieaer-howto.txt      |    2 +-
 Documentation/kernel-parameters.txt            |    8 +-
 Documentation/memory-barriers.txt              |    4 +-
 MAINTAINERS                                    |    5 +-
 arch/alpha/kernel/pci.c                        |   23 +-
 arch/frv/mb93090-mb00/pci-frv.h                |    2 -
 arch/frv/mb93090-mb00/pci-vdk.c                |   53 --
 arch/ia64/pci/pci.c                            |   44 +--
 arch/mn10300/unit-asb2305/pci-asb2305.h        |    2 -
 arch/parisc/kernel/pci.c                       |   30 +-
 arch/powerpc/kernel/pci-common.c               |   34 +-
 arch/powerpc/platforms/pseries/pci_dlpar.c     |    7 +-
 arch/ppc/kernel/pci.c                          |   59 +--
 arch/sh/drivers/pci/pci-sh4.h                  |    2 -
 arch/x86/kernel/pci-calgary_64.c               |    3 +-
 arch/x86/pci/acpi.c                            |   11 +-
 arch/x86/pci/common.c                          |   63 +--
 arch/x86/pci/i386.c                            |   38 --
 arch/x86/pci/pcbios.c                          |   72 ---
 arch/x86/pci/pci.h                             |    4 -
 drivers/parisc/dino.c                          |    1 -
 drivers/pci/access.c                           |  166 +++++
 drivers/pci/bus.c                              |   15 +-
 drivers/pci/hotplug/Kconfig                    |    4 +-
 drivers/pci/hotplug/acpi_pcihp.c               |   24 +-
 drivers/pci/hotplug/acpiphp_core.c             |   18 +-
 drivers/pci/hotplug/acpiphp_glue.c             |   38 +-
 drivers/pci/hotplug/acpiphp_ibm.c              |   36 +-
 drivers/pci/hotplug/cpci_hotplug_core.c        |   60 +-
 drivers/pci/hotplug/cpci_hotplug_pci.c         |   10 +-
 drivers/pci/hotplug/cpcihp_generic.c           |    8 +-
 drivers/pci/hotplug/cpqphp.h                   |    6 +-
 drivers/pci/hotplug/cpqphp_core.c              |   38 +-
 drivers/pci/hotplug/cpqphp_ctrl.c              |   64 +-
 drivers/pci/hotplug/cpqphp_nvram.c             |    2 +-
 drivers/pci/hotplug/cpqphp_pci.c               |    8 +-
 drivers/pci/hotplug/fakephp.c                  |    4 +-
 drivers/pci/hotplug/ibmphp_core.c              |   30 +-
 drivers/pci/hotplug/ibmphp_ebda.c              |   92 ++--
 drivers/pci/hotplug/ibmphp_hpc.c               |   68 +-
 drivers/pci/hotplug/ibmphp_pci.c               |   18 +-
 drivers/pci/hotplug/ibmphp_res.c               |   12 +-
 drivers/pci/hotplug/pci_hotplug_core.c         |    2 +-
 drivers/pci/hotplug/pciehp.h                   |    2 +-
 drivers/pci/hotplug/pciehp_core.c              |   32 +-
 drivers/pci/hotplug/pciehp_ctrl.c              |   34 +-
 drivers/pci/hotplug/pciehp_hpc.c               |  144 +++---
 drivers/pci/hotplug/pciehp_pci.c               |    8 +-
 drivers/pci/hotplug/pcihp_skeleton.c           |   18 +-
 drivers/pci/hotplug/rpadlpar_core.c            |   20 +-
 drivers/pci/hotplug/rpaphp_core.c              |    6 +-
 drivers/pci/hotplug/rpaphp_pci.c               |   14 +-
 drivers/pci/hotplug/rpaphp_slot.c              |    6 +-
 drivers/pci/hotplug/sgi_hotplug.c              |    8 +-
 drivers/pci/hotplug/shpchp.h                   |    6 +-
 drivers/pci/hotplug/shpchp_core.c              |   26 +-
 drivers/pci/hotplug/shpchp_ctrl.c              |   46 +-
 drivers/pci/hotplug/shpchp_hpc.c               |   64 +-
 drivers/pci/hotplug/shpchp_pci.c               |    4 +-
 drivers/pci/intel-iommu.c                      |  151 ++++-
 drivers/pci/iova.c                             |   50 +-
 drivers/pci/pci-sysfs.c                        |  114 +++-
 drivers/pci/pci.c                              |    6 +-
 drivers/pci/pci.h                              |   19 +
 drivers/pci/pcie/Kconfig                       |   20 +
 drivers/pci/pcie/Makefile                      |    3 +
 drivers/pci/pcie/aer/aerdrv.c                  |    4 +-
 drivers/pci/pcie/aer/aerdrv_acpi.c             |    5 +-
 drivers/pci/pcie/aer/aerdrv_core.c             |    5 +-
 drivers/pci/pcie/aspm.c                        |  811 ++++++++++++++++++++++++
 drivers/pci/pcie/portdrv_core.c                |    4 +-
 drivers/pci/pcie/portdrv_pci.c                 |    2 +-
 drivers/pci/probe.c                            |   80 +--
 drivers/pci/quirks.c                           |   17 +-
 drivers/pci/remove.c                           |   14 +-
 drivers/pci/search.c                           |  313 ++++------
 drivers/pci/setup-bus.c                        |    9 +-
 drivers/pci/setup-res.c                        |   87 ++-
 include/asm-sh/mpc1211/pci.h                   |    2 -
 include/linux/aer.h                            |    5 -
 include/linux/ioport.h                         |    5 +-
 include/linux/pci-aspm.h                       |   56 ++
 include/linux/pci.h                            |   30 +-
 include/linux/pci_regs.h                       |    8 +
 kernel/resource.c                              |   18 +
 91 files changed, 2213 insertions(+), 1300 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-pci
 create mode 100644 Documentation/PCI/00-INDEX
 rename Documentation/{ => PCI}/PCIEBUS-HOWTO.txt (98%)
 rename Documentation/{ => PCI}/pci-error-recovery.txt (100%)
 rename Documentation/{ => PCI}/pci.txt (99%)
 rename Documentation/{ => PCI}/pcieaer-howto.txt (99%)
 create mode 100644 drivers/pci/pcie/aspm.c
 create mode 100644 include/linux/pci-aspm.h

---------------

Adrian Bunk (7):
PCI: #if 0 pci_assign_resource_fixed()
PCI: #if 0 pci_cleanup_aer_correct_error_status()
PCI: aerdrv_acpi.c: remove unneeded NULL check
PCI: pci_alloc_child_bus() mustn't be __devinit
PCI: pci_scan_device() mustn't be __devinit
PCI: pci_bus_size_cardbus() mustn't be __devinit
PCI: pci_setup_bridge() mustn't be __devinit

Ben Hutchings (1):
PCI: Expose PCI VPD through sysfs

Bjorn Helgaas (9):
PCI: remove "pci=routeirq" noise from dmesg
PCI: add generic pci_enable_resources()
PCI: x86: use generic pci_enable_resources()
PCI: alpha: use generic pci_enable_resources()
PCI: ia64: use generic pci_enable_resources()
PCI: powerpc: use generic pci_enable_resources()
PCI: ppc: use generic pci_enable_resources()
PCI: parisc: use generic pci_enable_resources()
PCI: simplify quirk debug output

Gary Hade (1):
PCI: Include PCI domain in PCI bus names on x86/x86_64

Greg Kroah-Hartman (12):
PCI: remove pci_find_present
PCI: remove pci_get_device_reverse from calgary driver
PCI: remove pci_get_device_reverse
PCI: clean up search.c a lot
PCI Hotplug: make cpcihp driver use modern apis PCI Hotplug: the ibm driver is not dependant on PCI_LEGACY
PCI: remove initial bios sort of PCI devices on x86
PCI: make no_pci_devices() use the pci_bus_type list
PCI: add is_added flag to struct pci_dev
PCI: remove pcibios_fixup_ghosts()
PCI: remove global list of PCI devices
PCI: Change PCI subsystem MAINTAINER

Harvey Harrison (1):
PCI: replace remaining __FUNCTION__ occurrences

Ivan Kokshaysky (1):
PCI: clean up resource alignment management

James Bottomley (1):
PCI: remove parisc consumer of the pci global_list

Jesper Juhl (1):
PCI: Hotplug: Fix leaks in IBM Hot Plug Controller Driver - ibmphp_init_devno()

Randy Dunlap (1):
PCI: doc/pci: create Documentation/PCI/ and move files into it

Shaohua Li (1):
PCI: add PCI Express ASPM support

Tim Yamin (1):
PCI: Update VIA CX700 quirk

Trent Piepho (1):
PCI: Hotplug: fakephp: Return success, not ENODEV, when bus rescan is triggered

Yinghai Lu (1):
PCI: pcie AER: don't check _OSC when acpi is disabled

mark gross (3):
PCI: iova RB tree setup tweak
PCI: iommu: iotlb flushing
PCI: pci-iommu-iotlb-flushing-speedup

I just wanted to highlight this last entry. I'm passing the PCI subsystem maintainership on to Jesse Barnes <[email protected]>

I'd like to thank him for volunteering for the job, something for which I know he is more than capable.

So those of you who have automated scripts to hit me with PCI issues/bugs/complaints, might want to adjust them at this point in time.

Now what to do with all of this extra free time I'm going to have...

greg k-h

And now I get to figure out just how much trouble I've gotten myself into...

Thanks for all the time you've put into it, Greg. Maybe your extra free time can be spent on that 5th driver core re-write you've been talking about. :)

Thanks,
Jesse

Mwhahahaaa! Sucker. You'll find out.

The good news is that most of the time, the PCI code works fine. The bad news is that when it doesn't work, it's usually due to something *really* odd, like some magic motherboard device that has magic resources that aren't part of the standard PCI resource set and that clash with some of our resource allocation.

And they don't show up in the PnP lists because Windows never put anything that could clash with them, so there was no reason for the BIOS engineers to bother.

IOW, it's usually almost totally undebuggable crud like "driver X doesn't work on my machine", and then it turns out that it only happens on that particular motherboard that is totally identical to all other motherboards _except_ for that BIOS table not having the right reserved IO regions.

.. and then there's the pluggable PCI stuff, of course. I'm not sure whether you took that over too. That's a whole different set of issues.

Linus

that reminds me of the observations about differences between Linux's and Windows's PCI resource allocation stategies, see the bugzilla entry from today below.

Ingo

----------------->

http://bugzilla.kernel.org/show_bug.cgi?id=10461

------- Comment #6 from [email protected] 2008-04-18 11:03 ------- After a few debug printk() runs watching the allocation strategy I wondered why the PCI resources region doesn't start at the beginning of the largest gap:

[    0.000000] Allocating PCI resources starting at c2000000 (gap:

c0000000:20000000)

since, when 3GB RAM is installed, the gap starts at 0xC0000000 but the allocation region begins at 0xC2000000.

The other issue is that only the largest gap seems to be used for allocations, which explains why smaller allocations for other devices effectively choke off use of the range in 32-bit address space.

In contrast, from looking at the addresses in the allocation comparison with Windows, it looks as if Windows uses *all* gaps for allocation rather than just the largest. It is noticeable that Windows allocates smaller regions in the gaps between the various 'high' e820 reservations.

In looking for the origins of the gap-rounding code I eventually found commit f0eca9626c6becb6fc56106b2e4287c6c784af3d from 2005-09-09:

[PATCH] Update PCI IOMEM allocation start

This fixes the problem with "Averatec 6240 pcmcia_socket0: unable to apply power", which was due to the CardBus IOMEM register region being allocated at an address that was actually inside the RAM window that had been reserved for video frame-buffers in an UMA setup.

This introduces a simple 'rounding up' algorithm to create a 'gap' between top of system RAM and beginning of PCI IOMEM as a guard against unintentional over-writes.

The algorithm used was suggested in an example by Linus Torvalds with some provisos but was adopted verbatim in the patch for the Averatec bug. In his email, Linus went on to say:

"The other alternative is to make PCI allocations generally start at the high range of the allowable - judging by the lspci listings I've seem from people under Windows, that seems to be what Windows does, which might be a good idea (ie the closer we match windows allocation patterns, the more likely we're to not hit some unmarked region - because windows testing would have hit it too)."

See:
http://lists.infradead.org/pipermail/linux-pcmcia/2005-September/002625.html

That comment reflects my findings in dealing with this bug. Looking at the bug there are four issues:

1. No 256MB region on a 256MB boundary available for the GFX IOMEM in the single largest PCI IOMEM region.

2. The first available 256MB region on a 256MB boundary is unusable because pci_mem_start is being 'rounded up' to gap_start + round.

3. Multiple gaps higher in the address space are left unused whereas Windows uses them for smaller allocations thus keeping the largest gap free for the devices with large requirements.

4. Resources aren't being allocated top-down (subtractive decode) as recommended in PCI specs and Intel chipset datasheets, and done by Windows.

If [3] was implemented in addition to [4] the smaller allocations would be at the top of the 32-bit address space much like Windows.

Implementing [3] and [4] together should avoid the need for commit f0eca962 (Cardbus IOMEM in shared video RAM space) since the Cardbus IOMEM would be in a 'high' gap (as it would be with Windws).

Dropping commit f0eca962 would solve [2] since the GFX could allocate 256MB on the 256MB boundary at 0xC0000000 in the largest gap.

There might be an issue if a system has an undeclared shared video memory region *and* another PCI device that needs a large allocation.

Also, Linus' mention of maintaining an unused gap between top-of-RAM and bottom-of-PCI-IOMEM needs to be considered. Would implementation of [2] and [3] negate the need for it?
Windows doesn't maintain a similar gap - is there a reason that Linux should?

Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

Yeah, address space allocation seems to be a perennial problem. Fortunately it looks like I'll be able to get ahold of some nifty PCI test equipment so that I can reproduce weird topologies. I'll take a look at the bug you mentioned too (gotta triage the rest of the PCI bugs anyway).

Fortunately, Kristen will still be taking care of hotplug issues. Picking her brain about the weirdness she's seen there is on my TODO list.

Thanks,
Jesse