aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/pci/probe.c
Commit message (Collapse)AuthorAge
* fix jvc cdrom drive lockupZhang, Yanmin2007-07-16
| | | | | | | | | | | | | | | | | Before calling init_hwif_default, ide_unregister gets lock ide_lock and disables irq. init_hwif_default calls ide_default_io_base which calls pci_get_device and later pci_get_subsys tries to apply for semaphore pci_bus_sem and goes to sleep. Mostly, pci_get_device should be called when irq is turned on. ide_default_io_base just needs find if list pci_devices is empty. Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com> Cc: Greg KH <greg@kroah.com> Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6Linus Torvalds2007-07-12
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6: (34 commits) PCI: Only build PCI syscalls on architectures that want them PCI: limit pci_get_bus_and_slot to domain 0 PCI: hotplug: acpiphp: avoid acpiphp "cannot get bridge info" PCI hotplug failure PCI: hotplug: acpiphp: remove hot plug parameter write to PCI host bridge PCI: hotplug: acpiphp: fix slot poweroff problem on systems without _PS3 PCI: hotplug: pciehp: wait for 1 second after power off slot PCI: pci_set_power_state(): check for PM capabilities earlier PCI: cpci_hotplug: Convert to use the kthread API PCI: add pci_try_set_mwi PCI: pcie: remove SPIN_LOCK_UNLOCKED PCI: ROUND_UP macro cleanup in drivers/pci PCI: remove pci_dac_dma_... APIs PCI: pci-x-pci-express-read-control-interfaces cleanups PCI: Fix typo in include/linux/pci.h PCI: pci_ids, remove double or more empty lines PCI: pci_ids, add atheros and 3com_2 vendors PCI: pci_ids, reorder some entries PCI: i386: traps, change VENDOR to DEVICE PCI: ATM: lanai, change VENDOR to DEVICE PCI: Change all drivers to use pci_device->revision ...
| * PCI: read revision ID by defaultAuke Kok2007-07-11
| | | | | | | | | | | | | | | | | | | | | | | | Currently there are 97 occurrences where drivers need the pci revision ID. We can do this once for all devices. Even the pci subsystem needs the revision several times for quirks. The extra u8 member pads out nicely in the pci_dev struct. Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * PCI: point people to Bernhard instead of the linux-kernel listGreg Kroah-Hartman2007-07-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Back in commit 8c4b2cf9af9b4ecc29d4f0ec4ecc8e94dc4432d7, Bernhard said that he would fix up all instances of when this message happens. So point people at him instead of the linux-kernel list which can not fix things up. Cc: Bernhard Kaindl <bk@suse.de> Cc: Dave Jones <davej@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Miles Lane <miles.lane@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* | sysfs: kill unnecessary attribute->ownerTejun Heo2007-07-11
|/ | | | | | | | | | | | | | | | | | | | | | | | | | sysfs is now completely out of driver/module lifetime game. After deletion, a sysfs node doesn't access anything outside sysfs proper, so there's no reason to hold onto the attribute owners. Note that often the wrong modules were accounted for as owners leading to accessing removed modules. This patch kills now unnecessary attribute->owner. Note that with this change, userland holding a sysfs node does not prevent the backing module from being unloaded. For more info regarding lifetime rule cleanup, please read the following message. http://article.gmane.org/gmane.linux.kernel/510293 (tweaked by Greg to not delete the field just yet, to make it easier to merge things properly.) Signed-off-by: Tejun Heo <htejun@gmail.com> Cc: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* MSI: Use a list instead of the custom link structureMichael Ellerman2007-05-02
| | | | | | | | | | | | | | The msi descriptors are linked together with what looks a lot like a linked list, but isn't a struct list_head list. Make it one. The only complication is that previously we walked a list of irqs, and got the descriptor for each with get_irq_msi(). Now we have a list of descriptors and need to get the irq out of it, so it needs to be in the actual struct msi_desc. We use 0 to indicate no irq is setup. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* PCI: Convert to alloc_pci_dev()Michael Ellerman2007-05-02
| | | | | | | | Convert code that allocs a struct pci_dev to use alloc_pci_dev(). Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* PCI: Create alloc_pci_dev(), the one true way to create a struct pci_devMichael Ellerman2007-05-02
| | | | | | | | | | | There are currently several places in the kernel where we kmalloc() a struct pci_dev and start initialising it. It'd be preferable to have an allocator so we can ensure the pci_dev is correctly initialised in one place. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* pci: do not mark exported functions as __devinitSam Ravnborg2007-05-02
| | | | | | | | | | | | | | | | | | | | | | | Functions marked __devinit will be removed after kernel init. But being exported they are potentially called by a module much later. So the safer choice seems to be to keep the function even in the non CONFIG_HOTPLUG case. This silence the follwoing section mismatch warnings: WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_add_device from __ksymtab_gpl between '__ksymtab_pci_bus_add_device' (at offset 0x20) and '__ksymtab_pci_walk_bus' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_create_bus from __ksymtab_gpl between '__ksymtab_pci_create_bus' (at offset 0x40) and '__ksymtab_pci_stop_bus_device' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_max_busnr from __ksymtab_gpl between '__ksymtab_pci_bus_max_busnr' (at offset 0xc0) and '__ksymtab_pci_assign_resource_fixed' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_claim_resource from __ksymtab_gpl between '__ksymtab_pci_claim_resource' (at offset 0xe0) and '__ksymtab_pcie_port_bus_type' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_add_devices from __ksymtab between '__ksymtab_pci_bus_add_devices' (at offset 0x70) and '__ksymtab_pci_bus_alloc_resource' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_scan_bus_parented from __ksymtab between '__ksymtab_pci_scan_bus_parented' (at offset 0x90) and '__ksymtab_pci_root_buses' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_assign_resources from __ksymtab between '__ksymtab_pci_bus_assign_resources' (at offset 0x4d0) and '__ksymtab_pci_bus_size_bridges' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_size_bridges from __ksymtab between '__ksymtab_pci_bus_size_bridges' (at offset 0x4e0) and '__ksymtab_pci_setup_cardbus' Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Revert "adjust legacy IDE resource setting (v2)"Bartlomiej Zolnierkiewicz2007-04-23
| | | | | | | | | | | | | | | | This reverts commit ed8ccee0918ad063a4741c0656fda783e02df627. It causes hang on boot for some users and we don't yet know why: http://bugzilla.kernel.org/show_bug.cgi?id=7562 http://lkml.org/lkml/2007/4/20/404 http://lkml.org/lkml/2007/3/25/113 Just reverse it for 2.6.21-final, having broken X server is somehow better than unbootable system. Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* adjust legacy IDE resource setting (v2)Jan Beulich2007-03-03
| | | | | | | | | | | | | The change to force legacy mode IDE channels' resources to fixed non-zero values confuses (at least some versions of) X, because the values reported by the kernel and those readable from PCI config space aren't consistent anymore. Therefore, this patch arranges for the respective BARs to also get updated if possible. Signed-off-by: Jan Beulich <jbeulich@novell.com> Acked-by: Alan Cox <alan@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* MSI: Remove pci_scan_msi_device()Michael Ellerman2007-02-07
| | | | | | | | pci_scan_msi_device() doesn't do anything anymore, so remove it. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* PCI: check szhi when sz is 0 when 64 bit iomem bigger than 4GYinghai Lu2007-02-07
| | | | | | | | | | | | | | | | | | For pci mem resource that size is bigger than 4G, the sz returned by pc_size will be 0. So that resource is skipped, and register contained hi address will be treated as another 32bit resource. We need to use sz64 and pci_sz64 for 64 bit resource for clear logical. Typical usages for this: Opteron system with co-processor and the co-processor could take more than 4G RAM as pre-fetchable mem resource. Signed-off-by: Yinghai Lu <yinghai.lu@amd.com> Cc: Andi Kleen <ak@suse.de> Cc: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] pci/probe: fix macro that confuses kernel-docRandy Dunlap2006-12-30
| | | | | | | | | | | | Don't have macros between a function's kernel-doc block and the function definition. This is not valid for kernel-doc. Warning(/var/linsrc/linux-2.6.20-rc1-git8//drivers/pci/probe.c:653): No description found for parameter 'IORESOURCE_PCI_FIXED' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* PCI legacy resource fixRalf Baechle2006-12-20
| | | | | | | | | | | | | | | | | | | | | | Since commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f the kernel will try to update the non-writeable BAR registers 0..3 of PIIX4 IDE adapters if pci_assign_unassigned_resources() is used to do full resource assignment of the bus. This fails because in the PIIX4 these BAR registers have implicitly assumed values and read back as zero; it used to work because the kernel used to just write zero to that register the read back value did match what was written. The fix is a new resource flag IORESOURCE_PCI_FIXED used to mark a resource as non-movable. This will also be useful to keep other import system resources from being moved around - for example system consoles on PCI busses. [akpm@osdl.org: cleanup] Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Acked-by: Alan Cox <alan@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] add numa node information to struct deviceChristoph Hellwig2006-12-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | For node-aware skb allocations we need information about the node in struct net_device or struct device. Davem suggested to put it into struct device which this patch does. In particular: - struct device gets a new int numa_node member if CONFIG_NUMA is set - there are two new helpers, dev_to_node and set_dev_node to transparently deal with the non-numa case - for pci devices the node-info is set to the value we get from pcibus_to_node. Note that for some architectures pcibus_to_node doesn't work yet at the time we call it currently. This is harmless and will just mean skb allocations aren't node-local on this architectures until the implementation of pcibus_to_node on these architectures have been updated (There are patches for x86 and x86_64 floating around) [akpm@osdl.org: cleanup] Signed-off-by: Christoph Hellwig <hch@lst.de> Cc: Christoph Lameter <clameter@engr.sgi.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* PCI: quirks: fix the festering mess that claims to handle IDE quirksAlan Cox2006-12-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The number of permutations of crap we do is amazing and almost all of it has the wrong effect in 2.6. At the heart of this is the PCI SFF magic which says that compatibility mode PCI IDE controllers use ISA IRQ routing and hard coded addresses not the BAR values. The old quirks variously clears them, sets them, adjusts them and then IDE ignores the result. In order to drive all this garbage out and to do it portably we need to handle the SFF rules directly and properly. Because we know the device BAR 0-3 are not used in compatibility mode we load them with the values that are implied (and indeed which many controllers actually thoughtfully put there in this mode anyway). This removes special cases in the IDE layer and libata which now knows that bar 0/1/2/3 always contain the correct address. It means our resource allocation map is accurate from boot, not "mostly accurate" after ide is loaded, and it shoots lots of code. There is also lots more code and magic constant knowledge to shoot once this is in and settled. Been in my test tree for a while both with drivers/ide and with libata. Wants some -mm shakedown in case I've missed something dumb or there are corner cases lurking. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* PCI: optionally sort device lists breadth-firstMatt Domsch2006-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: New Dell PowerEdge servers have 2 embedded ethernet ports, which are labeled NIC1 and NIC2 on the chassis, in the BIOS setup screens, and in the printed documentation. Assuming no other add-in ethernet ports in the system, Linux 2.4 kernels name these eth0 and eth1 respectively. Many people have come to expect this naming. Linux 2.6 kernels name these eth1 and eth0 respectively (backwards from expectations). I also have reports that various Sun and HP servers have similar behavior. Root cause: Linux 2.4 kernels walk the pci_devices list, which happens to be sorted in breadth-first order (or pcbios_find_device order on i386, which most often is breadth-first also). 2.6 kernels have both the pci_devices list and the pci_bus_type.klist_devices list, the latter is what is walked at driver load time to match the pci_id tables; this klist happens to be in depth-first order. On systems where, for physical routing reasons, NIC1 appears on a lower bus number than NIC2, but NIC2's bridge is discovered first in the depth-first ordering, NIC2 will be discovered before NIC1. If the list were sorted breadth-first, NIC1 would be discovered before NIC2. A PowerEdge 1955 system has the following topology which easily exhibits the difference between depth-first and breadth-first device lists. -[0000:00]-+-00.0 Intel Corporation 5000P Chipset Memory Controller Hub +-02.0-[0000:03-08]--+-00.0-[0000:04-07]--+-00.0-[0000:05-06]----00.0-[0000:06]----00.0 Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (labeled NIC2, 2.4 kernel name eth1, 2.6 kernel name eth0) +-1c.0-[0000:01-02]----00.0-[0000:02]----00.0 Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (labeled NIC1, 2.4 kernel name eth0, 2.6 kernel name eth1) Other factors, such as device driver load order and the presence of PCI slots at various points in the bus hierarchy further complicate this problem; I'm not trying to solve those here, just restore the device order, and thus basic behavior, that 2.4 kernels had. Solution: The solution can come in multiple steps. Suggested fix #1: kernel Patch below optionally sorts the two device lists into breadth-first ordering to maintain compatibility with 2.4 kernels. It adds two new command line options: pci=bfsort pci=nobfsort to force the sort order, or not, as you wish. It also adds DMI checks for the specific Dell systems which exhibit "backwards" ordering, to make them "right". Suggested fix #2: udev rules from userland Many people also have the expectation that embedded NICs are always discovered before add-in NICs (which this patch does not try to do). Using the PCI IRQ Routing Table provided by system BIOS, it's easy to determine which PCI devices are embedded, or if add-in, which PCI slot they're in. I'm working on a tool that would allow udev to name ethernet devices in ascending embedded, slot 1 .. slot N order, subsort by PCI bus/dev/fn breadth-first. It'll be possible to use it independent of udev as well for those distributions that don't use udev in their installers. Suggested fix #3: system board routing rules One can constrain the system board layout to put NIC1 ahead of NIC2 regardless of breadth-first or depth-first discovery order. This adds a significant level of complexity to board routing, and may not be possible in all instances (witness the above systems from several major manufacturers). I don't want to encourage this particular train of thought too far, at the expense of not doing #1 or #2 above. Feedback appreciated. Patch tested on a Dell PowerEdge 1955 blade with 2.6.18. You'll also note I took some liberty and temporarily break the klist abstraction to simplify and speed up the sort algorithm. I think that's both safe and appropriate in this instance. Signed-off-by: Matt Domsch <Matt_Domsch@dell.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* PCI: fix __must_check warningsGreg Kroah-Hartman2006-09-26
| | | | | Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] pci: initialize struct pci_dev.error_stateLinas Vepstas2006-07-10
| | | | | | | | | | | | | | | | | | | | | | | | The pci channel state is currently uninitialized, thus there are two ways of indicating that "everything's OK": 0 and 1. This is a bit of a burden. If a devce driver wants to check if the pci channel is in a working or a disconnected state, the driver writer must perform checks similar to if((pdev->error_state != 0) && (pdev->error_state != pci_channel_io_normal)) { whatever(); } which is rather akward. The first check is needed because stuct pci_dev is inited to all-zeros. The scond is needed because the error recovery will set the state to pci_channel_io_normal (which is not zero). This patch fixes this awkwardness. Signed-off-by: Linas Vepstas <linas@austin.ibm.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] PCI: fix race with pci_walk_bus and pci_destroy_devZhang Yanmin2006-06-21
| | | | | | | | | | | | | pci_walk_bus has a race with pci_destroy_dev. When cb is called in pci_walk_bus, pci_destroy_dev might unlink the dev pointed by next. Later on in the next loop, pointer next becomes NULL and cause kernel panic. Below patch against 2.6.17-rc4 fixes it by changing pci_bus_lock (spin_lock) to pci_bus_sem (rw_semaphore). Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] PCI: fix to pci ignore pre-set 64-bit bars on 32-bit platformsBjorn Helgaas2006-06-21
| | | | | | | | | | | | | | | | | | When we detect a 64-bit pre-set address in a BAR on a 32-bit platform, we disable it and treat it as if it had been unset, thus allowing the general address assignment code to assign a new address to it when the device is enabled. This can happen either if the firmware assigns 64-bit addresses; additionally, some cards have been found "in the wild" which do not come out of reset with all the BAR registers set to zero. Unfortunately, the patch that implemented this tested the low part of the address instead of the high part of the address. This patch fixes that. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] PCI: Ignore pre-set 64-bit BARs on 32-bit platformsH. Peter Anvin2006-06-21
| | | | | | | | | | | | | | | | | | | [pci] Ignore pre-set 64-bit BARs on 32-bit platforms Currently, Linux always rejects a device which has a pre-set 64-bit address on a 32-bit platform. On systems which do not do PCI initialization in firmware, this causes some devices which don't correctly power up with all BARs zero to fail. This patch makes the kernel automatically zero out such an address (thus treating it as if it had not been set at all, meaning it will assign an address if necessary). I have done this only for devices, not bridges. It seems potentially hazardous to do for bridges. Signed-off-by: H. Peter Anvin <hpa@c2micro.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] PCI: kzalloc() conversion in drivers/pciEric Sesterhenn2006-03-23
| | | | | | | | this patch converts drivers/pci to kzalloc usage. Compile tested with allyes config. Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] PCI: PCI/Cardbus cards hidden, needs pci=assign-busses to fixBernhard Kaindl2006-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "In some cases, especially on modern laptops with a lot of PCI and cardbus bridges, we're unable to assign correct secondary/subordinate bus numbers to all cardbus bridges due to BIOS limitations unless we are using "pci=assign-busses" boot option." -- Ivan Kokshaysky (from a patch comment) Without it, Cardbus cards inserted are never seen by PCI because the parent PCI-PCI Bridge of the Cardbus bridge will not pass and translate Type 1 PCI configuration cycles correctly and the system will fail to find and initialise the PCI devices in the system. Reference: PCI-PCI Bridges: PCI Configuration Cycles and PCI Bus Numbering: http://www.science.unitn.it/~fiorella/guidelinux/tlk/node72.html The reason for this is that: ``All PCI busses located behind a PCI-PCI bridge must reside between the secondary bus number and the subordinate bus number (inclusive).'' "pci=assign-busses" makes pcibios_assign_all_busses return 1 and this turns on PCI renumbering during PCI probing. Alan suggested to use DMI automatically set assign-busses on problem systems. The only question for me was where to put it. I put it directly before scanning PCI bus into pcibios_scan_root() because it's called from legacy, acpi and numa and so it can be one place for all systems and configurations which may need it. AMD64 Laptops are also affected and fixed by assign-busses, and the code is also incuded from arch/x86_64/pci/ that place will also work for x86_64 kernels, I only ifdef'-ed the x86-only Laptop in this example. Affected and known or assumed to be fixed with it are (found by googling): * ASUS Z71V and L3s * Samsung X20 * Compaq R3140us and all Compaq R3000 series laptops with TI1620 Controller, also Compaq R4000 series (from a kernel.org bugreport) * HP zv5000z (AMD64 3700+, known that fixup_parent_subordinate_busnr fixes it) * HP zv5200z * IBM ThinkPad 240 * An IBM ThinkPad (1.8 GHz Pentium M) debugged by Pavel Machek gives the correspondig message which detects the possible problem. * MSI S260 / Medion SIM 2100 MD 95600 The patch also expands the "try pci=assign-busses" warning so testers will help us to update the DMI table. Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] PCI: make MSI quirk inheritable from the pci busMichael S. Tsirkin2006-03-23
| | | | | | | | It turns out AMD 8131 quirk only affects MSI for devices behind the 8131 bridge. Handle this by adding a flags field in pci_bus, inherited from parent to child. Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] PCI: Avoid leaving MASTER_ABORT disabled permanently when returning ↵Ralf Baechle2006-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | from pci_scan_bridge. > On Mon, Feb 13, 2006 at 05:13:21PM -0800, David S. Miller wrote: > > > > In drivers/pci/probe.c:pci_scan_bridge(), if this is not the first > > pass (pass != 0) we don't restore the PCI_BRIDGE_CONTROL_REGISTER and > > thus leave PCI_BRIDGE_CTL_MASTER_ABORT off: > > > > int __devinit pci_scan_bridge(struct pci_bus *bus, struct pci_dev * dev, int max, int pass) > > { > > ... > > /* Disable MasterAbortMode during probing to avoid reporting > > of bus errors (in some architectures) */ > > pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &bctl); > > pci_write_config_word(dev, PCI_BRIDGE_CONTROL, > > bctl & ~PCI_BRIDGE_CTL_MASTER_ABORT); > > ... > > if ((buses & 0xffff00) && !pcibios_assign_all_busses() && !is_cardbus) { > > unsigned int cmax, busnr; > > /* > > * Bus already configured by firmware, process it in the first > > * pass and just note the configuration. > > */ > > if (pass) > > return max; > > ... > > } > > > > pci_write_config_word(dev, PCI_BRIDGE_CONTROL, bctl); > > ... > > > > This doesn't seem intentional. Agreed, looks like an accident. The patch [1] originally came from Kip Walker (Broadcom back then) between 2.6.0-test3 and 2.6.0-test4. As I recall it was supposed to fix an issue with with PCI aborts being signalled by the PCI bridge of the Broadcom BCM1250 family of SOCs when probing behind pci_scan_bridge. It is undeseriable to disable PCI_BRIDGE_CTL_MASTER_ABORT in pci_{read,write)_config_* and the behaviour wasn't considered a bug in need of a workaround, so this was put in probe.c. I don't have an affected system at hand, so can't really test but I propose something like the below patch. [1] http://www.linux-mips.org/git?p=linux.git;a=commit;h=599457e0cb702a31a3247ea6a5d9c6c99c4cf195 [PCI] Avoid leaving MASTER_ABORT disabled permanently when returning from pci_scan_bridge. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] PCI: really fix parent's subordinate busnrKristen Accardi2006-03-23
| | | | | | | | | After you find the maximum value of the subordinate buses below the child bus, you must fix the parent's subordinate bus number again, otherwise it may be too small. Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] PCI: Export pci_cfg_space_sizeBenjamin Herrenschmidt2006-01-09
| | | | | | | | | | The powerpc PCI code sets up the PCI tree without doing config space accesses in most cases, from the firmware tree. However, it still wants to call pci_cfg_space_size() under some conditions, thus it needs to be made non-static (though I don't see a point to export it to modules). Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] PCI: use bus numbers sparsely, if necessaryDominik Brodowski2006-01-09
| | | | | | | | | | | | | Add a warning if a child bus may be inaccessible because the parent bridge has wrong secondary or subordinate bus numbers. Note that this may or may not happen on "transparent" bridges, as can be seen in bug #5557. Also, if we do not fix up the assignment of bus numbers, try to make use of the bus number space available. Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] PCI Quirk: 1K I/O space granularity on Intel P64H2Daniel Yeisley2006-01-09
| | | | | | | | | | | | | I've implemented a quirk to take advantage of the 1KB I/O space granularity option on the Intel P64H2 PCI Bridge. I had to change probe.c because it sets the resource start and end to be aligned on 4k boundaries (after the quirk sets them to 1k boundaries). I've tested this patch on a Unisys ES7000-600 both with and without the 1KB option enabled. I also tested this on a 2 processor Dell box that doesn't have a P64H2 to make sure there were no negative affects there. Signed-off-by: Dan Yeisley <dan.yeisley@unisys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] pci: call pci_read_irq for bridgesKristen Accardi2006-01-09
| | | | | | | | Call pci_read_irq() for bridges too, so that the pin value is stored for bridges that require interrupts. Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] pci: store PCI_INTERRUPT_PIN in pci_devKristen Accardi2006-01-09
| | | | | | | | Store the value of the INTERRUPT_PIN in the pci_dev structure so that it can be retrieved later. Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] kernel-doc: PCI fixesRandy Dunlap2005-10-28
| | | | | | | | PCI: add descriptions for missing function parameters. Eliminate all kernel-doc warnings here. Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] pci: fixup parent subordinate busnrIvan Kokshaysky2005-09-23
| | | | | | | | | | | | | | | | | I believe the change that broke things is introduction of pci_fixup_parent_subordinate_busnr(). The patch here does two things: - hunk #1 should fix the problems you've seen when you boot without additional "pci" kernel options; - hunk #2 supposedly fixes boot with "pci=assign-busses" option which otherwise hangs Acer TM81xx machines as reported. Please try this with and without "pci=assign-busses". If it boots, I'd like to see 'lspci -vvx' for both cases. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] fix drivers/pci/probe.c warningAmos Waterland2005-09-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This function expects an unsigned 32-bit type as its third argument: static u32 pci_size(u32 base, u32 maxbase, u32 mask) However, given these definitions: #define PCI_BASE_ADDRESS_MEM_MASK (~0x0fUL) #define PCI_ROM_ADDRESS_MASK (~0x7ffUL) these two calls in drivers/pci/probe.c are problematic for architectures for which a UL is not equivalent to a u32: sz = pci_size(l, sz, PCI_BASE_ADDRESS_MEM_MASK); sz = pci_size(l, sz, PCI_ROM_ADDRESS_MASK); Hence the below compile warning when building for ARCH=ppc64: drivers/pci/probe.c: In function `pci_read_bases': /.../probe.c:168: warning: large integer implicitly truncated to unsigned type /.../probe.c:218: warning: large integer implicitly truncated to unsigned type Here is a simple fix. Signed-off-by: Amos Waterland <apw@us.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Subject: PATCH: fix numa caused compile warningsAlan Cox2005-09-10
| | | | | | | | | pcibus_to_cpumask expands into more than just an initialiser so gcc moans about code before variable declarations. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] PCI: Small rearrangement of PCI probing codePaul Mackerras2005-09-09
| | | | | | | | | | | | This patch makes some small rearrangements of the PCI probing code in order to make it possible for arch code to set up the PCI tree without needing to duplicate code from the PCI layer unnecessarily. PPC64 will use this to set up the PCI tree from the Open Firmware device tree, which we need to do on logically-partitioned pSeries systems. Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] PCI: Support PCM PM CAP version 3Daniel Ritz2005-09-08
| | | | | | | | | | | | | - support PCI PM CAP version 3 (as defined in PCI PM Interface Spec v1.2) - pci/probe.c sets the PM state initially to 4 which is D3cold. add a PCI_UNKNOWN - minor cleanups Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] PCI: remove CONFIG_PCI_NAMESAdrian Bunk2005-09-08
| | | | | | | This patch removes CONFIG_PCI_NAMES. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] PCI: remove PCI_BRIDGE_CTL_VGA handling from setup-bus.cIvan Kokshaysky2005-07-29
| | | | | | | | | | | | | | | | | | The setup-bus code doesn't work correctly for configurations with more than one display adapter in the same PCI domain. This stuff actually is a leftover of an early 2.4 PCI setup code and apparently it stopped working after some "bridge_ctl" changes. So the best thing we can do is just to remove it and rely on the fact that any firmware *has* to configure VGA port forwarding for the boot display device properly. But then we need to ensure that the bus->bridge_ctl will always contain valid information collected at the probe time, therefore the following change in pci_scan_bridge() is needed. Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] PCI: handle subtractive decode pci-pci bridge betterIvan Kokshaysky2005-07-01
| | | | | | | | | | | | | | | | | | | With the number of PCI bus resources increased to 8, we can handle the subtractive decode PCI-PCI bridge like a normal bridge, taking into account standard PCI-PCI bridge windows (resources 0-2). This helps to avoid problems with peer-to-peer DMA behind such bridges, poor performance for MMIO ranges outside bridge windows and prefetchable vs. non-prefetchable memory issues. To reflect the fact that such bridges do forward all addresses to the secondary bus (transparency), remaining bus resources 3-7 are linked to resources 0-4 of the primary bus. These resources will be used as fallback by resource management code if allocation from standard bridge windows fails for some reason. Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Acked-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] PCI: Fix up PCI routing in parent bridgeGreg Kroah-Hartman2005-07-01
| | | | | | | | | When the cardbus bridge is behind another bridge change the routing in the parent bridge for new cards. This fixes Cardbus on various AMD64 laptops. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] acpi bridge hotadd: Link newly created pci child bus to its parent ↵Rajesh Shah2005-06-28
| | | | | | | | | | | | | | on creation When a pci child bus is created, add it to the parent's children list immediately rather than waiting till pci_bus_add_devices(). For hot-plug bridges/devices, pci_bus_add_devices() may be called much later, after they have been properly configured. In the meantime, this allows us to use the normal pci bus search functions for the hot-plug bridges/buses. Signed-off-by: Rajesh Shah <rajesh.shah@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] acpi bridge hotadd: Take the PCI lock when modifying pci bus or ↵Rajesh Shah2005-06-28
| | | | | | | | | | | | device lists With root bridge and pci bridge hot-plug, new buses and devices can be added or removed at run time. Protect the pci bus and device lists with the pci lock when doing so. Signed-off-by: Rajesh Shah <rajesh.shah@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] acpi bridge hotadd: Prevent duplicate bus numbers when scanning PCI ↵Rajesh Shah2005-06-28
| | | | | | | | | | | | | bridge When hot-plugging a root bridge, as we try to assign bus numbers we may find that the hotplugged hieratchy has more PCI to PCI bridges (i.e. bus requirements) than available. Make sure we don't step over an existing bus when that happens. Signed-off-by: Rajesh Shah <rajesh.shah@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] acpi bridge hotadd: ACPI based root bridge hot-addRajesh Shah2005-06-28
| | | | | | | | | | | | | | | | | | | When you hot-plug a (root) bridge hierarchy, it may have p2p bridges and devices attached to it that have not been configured by firmware. In this case, we need to configure the devices before starting them. This patch separates device start from device scan so that we can introduce the configuration step in the middle. I kept the existing semantics for pci_scan_bus() since there are a huge number of callers to that function. Also, I have no way of testing the changes I made to the parisc files, so this needs review by those folks. Sorry for the massive cross-post, this touches files in many different places. Signed-off-by: Rajesh Shah <rajesh.shah@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] Fix PCI BAR size interpretation on 64-bit archesOlof Johansson2005-06-13
| | | | | | | | | | | | | | | | | | | | | | On 64-bit machines, PCI_BASE_ADDRESS_MEM_MASK and other mask constants passed to pci_size() are 64-bit (for example ~0x0fUL). However, pci_size does comparisons between the u32 arguments and the mask, which will fail even though any result from pci_size is still just 32-bit. Changing the mask argument to u32 seems the obvious thing to do, since all arithmetic in the function is 32-bit and having a larger mask makes no sense. This triggered on a PPC64 system here where an adapter (VGA, as it happened) had a memory region base of 0xfe000000 and a sz of the same, matching the if (max == maxbase ...) test at the bottom of pci_size but failing the mask comparison. Quite a corner case which I guess explains why we haven't seen it until now. Signed-off-by: Olof Johansson <olof@lixom.net> Acked-by: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] PCI: Clean up a lot of sparse "Should it be static?" warnings.Greg KH2005-05-04
| | | | Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-16
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
generated by cgit v1.2.2 (git 2.25.0) at 2024-11-22 12:15:49 -0500