- 08 2月, 2007 2 次提交
-
-
由 Michael Ellerman 提交于
pci_scan_msi_device() doesn't do anything anymore, so remove it. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Yinghai Lu 提交于
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: NYinghai Lu <yinghai.lu@amd.com> Cc: Andi Kleen <ak@suse.de> Cc: Andrew Morton <akpm@osdl.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 31 12月, 2006 1 次提交
-
-
由 Randy Dunlap 提交于
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: NRandy Dunlap <randy.dunlap@oracle.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 21 12月, 2006 1 次提交
-
-
由 Ralf Baechle 提交于
Since commit 368c73d4 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: NRalf Baechle <ralf@linux-mips.org> Acked-by: NAlan Cox <alan@redhat.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 08 12月, 2006 1 次提交
-
-
由 Christoph Hellwig 提交于
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: NChristoph Hellwig <hch@lst.de> Cc: Christoph Lameter <clameter@engr.sgi.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 02 12月, 2006 1 次提交
-
-
由 Alan Cox 提交于
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: NAlan Cox <alan@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 19 10月, 2006 1 次提交
-
-
由 Matt Domsch 提交于
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: NMatt Domsch <Matt_Domsch@dell.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 27 9月, 2006 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 11 7月, 2006 1 次提交
-
-
由 Linas Vepstas 提交于
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: NLinas Vepstas <linas@austin.ibm.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 22 6月, 2006 3 次提交
-
-
由 Zhang Yanmin 提交于
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: NZhang Yanmin <yanmin.zhang@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Bjorn Helgaas 提交于
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: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NH. Peter Anvin <hpa@zytor.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 H. Peter Anvin 提交于
[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: NH. Peter Anvin <hpa@c2micro.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 24 3月, 2006 5 次提交
-
-
由 Eric Sesterhenn 提交于
this patch converts drivers/pci to kzalloc usage. Compile tested with allyes config. Signed-off-by: NEric Sesterhenn <snakebyte@gmx.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Bernhard Kaindl 提交于
"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: NAndrew Morton <akpm@osdl.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Michael S. Tsirkin 提交于
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: NMichael S. Tsirkin <mst@mellanox.co.il> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Ralf Baechle 提交于
> 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: NRalf Baechle <ralf@linux-mips.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Kristen Accardi 提交于
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: NKristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 10 1月, 2006 5 次提交
-
-
由 Benjamin Herrenschmidt 提交于
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: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Dominik Brodowski 提交于
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: NDominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Daniel Yeisley 提交于
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: NDan Yeisley <dan.yeisley@unisys.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Kristen Accardi 提交于
Call pci_read_irq() for bridges too, so that the pin value is stored for bridges that require interrupts. Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Kristen Accardi 提交于
Store the value of the INTERRUPT_PIN in the pci_dev structure so that it can be retrieved later. Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 29 10月, 2005 1 次提交
-
-
由 Randy Dunlap 提交于
PCI: add descriptions for missing function parameters. Eliminate all kernel-doc warnings here. Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 23 9月, 2005 1 次提交
-
-
由 Ivan Kokshaysky 提交于
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: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 22 9月, 2005 1 次提交
-
-
由 Amos Waterland 提交于
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: NAmos Waterland <apw@us.ibm.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 11 9月, 2005 1 次提交
-
-
由 Alan Cox 提交于
pcibus_to_cpumask expands into more than just an initialiser so gcc moans about code before variable declarations. Signed-off-by: NAlan Cox <alan@redhat.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 10 9月, 2005 1 次提交
-
-
由 Paul Mackerras 提交于
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: NPaul Mackerras <paulus@samba.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 09 9月, 2005 2 次提交
-
-
由 Daniel Ritz 提交于
- 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: NDaniel Ritz <daniel.ritz@gmx.ch> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Adrian Bunk 提交于
This patch removes CONFIG_PCI_NAMES. Signed-off-by: NAdrian Bunk <bunk@stusta.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 30 7月, 2005 1 次提交
-
-
由 Ivan Kokshaysky 提交于
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: NIvan Kokshaysky <ink@jurassic.park.msu.ru> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 02 7月, 2005 2 次提交
-
-
由 Ivan Kokshaysky 提交于
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: NIvan Kokshaysky <ink@jurassic.park.msu.ru> Acked-by: NDominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Greg Kroah-Hartman 提交于
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: NAndi Kleen <ak@suse.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 28 6月, 2005 4 次提交
-
-
由 Rajesh Shah 提交于
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: NRajesh Shah <rajesh.shah@intel.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Rajesh Shah 提交于
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: NRajesh Shah <rajesh.shah@intel.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Rajesh Shah 提交于
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: NRajesh Shah <rajesh.shah@intel.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Rajesh Shah 提交于
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: NRajesh Shah <rajesh.shah@intel.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 14 6月, 2005 1 次提交
-
-
由 Olof Johansson 提交于
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: NOlof Johansson <olof@lixom.net> Acked-by: NGreg KH <greg@kroah.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 04 5月, 2005 1 次提交
-
-
由 Greg KH 提交于
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
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!
-