- 03 May, 2007 40 commits
-
-
Linas Vepstas authored
Eliminate the tail call to rpaphp_register_slot() by placing it in the caller. This will help later dis-entanglement. Signed-off-by:
Linas Vepstas <linas@austin.ibm.com> Cc: John Rose <johnrose@austin.ibm.com> Signed-off-by:
Kristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Linas Vepstas authored
The rpaphp_set_attention_status() routine seems to be a wrapper around a single rtas call. Abolish it. Signed-off-by:
-
Linas Vepstas authored
The debug function print_slot_pci_funcs() is a large wrapper around two debug print statements. Just invoke these directly. Signed-off-by:
-
Linas Vepstas authored
The setup_pci_slot() routine appears to be nothing else than a big, complicated wrapper around pcibios_add_pci_devices(). Remove the wrapping, and call pcibios_add_pci_devices() directly. Signed-off-by:
-
Linas Vepstas authored
Delete another stovepipe: a call to a routine which does nothing. Remove un-needed semaphore as well. Signed-off-by:
-
Linas Vepstas authored
Remove another stove-pipe; this funcion was called from two different places, with a compile-time const that is then run-time checked to perform two different things. Signed-off-by:
-
Linas Vepstas authored
Remove another stovepipe: a call which wraps another call, and just adds printks. Signed-off-by:
-
Linas Vepstas authored
Remove a stove-pipe-- a function that is called from only one place, does nothing but wraps another function with debug printk's. Signed-off-by:
-
Linas Vepstas authored
Remove un-needed goto. Signed-off-by:
-
Linas Vepstas authored
Fix a memleak; the slot->location string was never freed. Fix some whitespace and overlong-line probelms while we're here. Signed-off-by:
-
Linas Vepstas authored
The routine that called an alloc should be the same routine that calles the mathcing free, if anything in the middle failed. Signed-off-by:
-
Linas Vepstas authored
Cleanup cruft: remove the global "num_slots" variable; although scattered across multiple files, it is used only once, in a debug statement. Signed-off-by:
-
Linas Vepstas authored
Cleanup the flow of control for rpaphp_add_slot(), so as to make it easier to read. The ext patch will fix a bug in this same code. Signed-off-by:
-
Chuck Ebbert authored
Add more information to PCI resource collision message to help with debugging. Signed-off-by:
Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Adrian Bunk authored
Unless we finally completely remove it, people will always add new users. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
Adrian Bunk authored
This patch removes the PCI_MULTITHREAD_PROBE option that had already been marked as broken. Signed-off-by:
-
Michael Ellerman authored
This patch introduces an optional function, arch_teardown_msi_irqs(), which gives an arch the opportunity to do per-device teardown for MSI/X. If that's not required, the default version simply calls arch_teardown_msi_irq() for each msi irq required. arch_teardown_msi_irqs() is simply passed a pdev, attached to the pdev is a list of msi_descs, it is up to the arch to free the irq associated with each of these as appropriate. For archs that _don't_ implement arch_teardown_msi_irqs(), all msi_descs with irq == 0 are considered unallocated, and the arch teardown routine is not called on them. Signed-off-by:
Michael Ellerman <michael@ellerman.id.au> Signed-off-by:
-
Michael Ellerman authored
This patch introduces an optional function, arch_setup_msi_irqs(), (note the plural) which gives an arch the opportunity to do per-device setup for MSI/X and then allocate all the requested MSI/Xs at once. If that's not required by the arch, the default version simply calls arch_setup_msi_irq() for each MSI irq required. arch_setup_msi_irqs() is passed a pdev, attached to the pdev is a list of msi_descs with irq == 0, it is up to the arch to connect these up to an irq (via set_irq_msi()) or return an error. For convenience the number of vectors and the type are passed also. All msi_descs with irq != 0 are considered allocated, and the arch teardown routine will be called on them when necessary. The existing semantics of pci_enable_msix() are that if the requested number of irqs can not be allocated, the maximum number that _could_ be allocated is returned. To support that, we define that in case of an error from arch_setup_msi_irqs(), the number of msi_descs with irq != 0 are considered allocated, and are counted toward the "max that could be allocated". Signed-off-by:
-
Michael Ellerman authored
set_irq_msi() currently connects an irq_desc to an msi_desc. The archs call it at some point in their setup routine, and then the generic code sets up the reverse mapping from the msi_desc back to the irq. set_irq_msi() should do both connections, making it the one and only call required to connect an irq with it's MSI desc and vice versa. The arch code MUST call set_irq_msi(), and it must do so only once it's sure it's not going to fail the irq allocation. Given that there's no need for the arch to return the irq anymore, the return value from the arch setup routine just becomes 0 for success and anything else for failure. Signed-off-by:
-
Dan Williams authored
Allows architectures to advertise that they support MSI rather than listing each architecture as a PCI_MSI dependency. Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Acked-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Michael Ellerman authored
Now that we keep a list of msi descriptors, we don't need first_msi_irq in the pci dev. If we somehow have zero MSIs configured list_entry() will give us weird oopes or nice memory corruption bugs. So be paranoid. Add BUG_ONs and also a check in pci_msi_check_device() to make sure nvec > 0. Signed-off-by:
-
Michael Ellerman authored
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 authored
Convert code that allocs a struct pci_dev to use alloc_pci_dev(). Signed-off-by:
-
Michael Ellerman authored
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 authored
Add an arch_check_device(), which gives archs a chance to check the input to pci_enable_msi/x. The arch might be interested in the value of nvec so pass it in. Propagate the error value returned from the arch routine out to the caller. Signed-off-by:
-
Michael Ellerman authored
As pointed out by Eric, the name pci_msi_supported() suggests it should return a boolean value, however it doesn't. So update the name to be a bit less confusing and update the doco too. Signed-off-by:
-
Michael Ellerman authored
Consolidate precondition checks into a single if statement. Signed-off-by:
-
Michael Ellerman authored
pci_enable_msi() and pci_enable_msix() both search for the MSI/MSI-X capability, we can fold this into pci_msi_supported() by passing the type in. Update the code to match the comment for pci_msi_supported(). That is it returns 0 on success, and anything else indicates an error. Signed-off-by:
-
Michael Ellerman authored
We don't need a special cache just for msi descriptors. They're not particularly large, under 100 bytes for sure, and don't seem to require any special alignment etc. On most systems there will be relatively few MSIs, and hence we waste most of a page on the cache. Better to just kzalloc the space for the few we do need. Signed-off-by:
-
Michael Ellerman authored
Move EXPORT_SYMBOL()s near their definition. Signed-off-by:
-
Michael Ellerman authored
When freeing MSIs and MSI-Xs, we BUG_ON() if the irq has not been freed, ie. if it still has an action. We can consolidate all of these BUG_ON()s into msi_free_irqs() as all the code paths lead there almost immediately anyway. Signed-off-by:
-
Michael Ellerman authored
For the MSI-X case we do exactly the same logic in pci_disable_msix() and msi_remove_pci_irq_vectors(), so consolidate them. msi_remove_pci_irq_vectors() wasn't setting dev->first_msi_irq to 0, but I think it should have been, so the consolidated version does. Signed-off-by:
-
Michael Ellerman authored
Although it might be nice to do a printk before BUG'ing, it's really not necessary, and it complicates the code. The behaviour has changed slightly, in that before we set a flag if the irq had an action, and continued freeing the other irqs. But as I see it that's all irrelevant because we end up BUG'ing anyway. Signed-off-by:
-
Michael Ellerman authored
Although it might be nice to do a printk before BUG'ing, it's really not necessary, and it complicates the code. Signed-off-by:
-
Michael Ellerman authored
Although it might be nice to do a printk before BUG'ing, it's really not necessary, and it complicates the code. The behaviour has changed slightly, in that before we set a flag if the irq had an action, and continued freeing the other irqs. But as I see it that's all irrelevant because we end up BUG'ing anyway. Signed-off-by:
-
Michael Ellerman authored
Although it might be nice to do a printk before BUG'ing, it's really not necessary, and it complicates the code. Signed-off-by:
-
Randy Dunlap authored
Correct function name copy-paste error. Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Sergei Shtylyov authored
Balance declarations of pci_request_regions() and pci_release_regions() with empty inline definitions for the CONFIG_PCI=n case -- otherwise my patch to drivers/net/3c59x.c in the -mm tree doesn't compile. :-) Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by:
-
Sam Ravnborg authored
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:
-
Jean Delvare authored
Currently, there is no minimum number of fields required when adding a new device ID to a PCI driver through the new_id sysfs file. It is possible to add a new ID with only the vendor ID set, causing the driver to attempt to attach to all PCI devices from that vendor. This has been reported to happen accidentally: http://lists.lm-sensors.org/pipermail/lm-sensors/2007-March/019366.html It is even possible to not even set the vendor ID field, causing the driver to attempt to attach to _all_ the PCI devices. This sounds dangerous and I fail to see any valid use of this "feature". Thus I suggest that we now require at least the first two fields (vendor ID and device ID) to be set. For what it's worth, this is what the USB subsystem does. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
