aboutsummaryrefslogtreecommitdiff
path: root/drivers/pci/pci.c
AgeCommit message (Collapse)Author
2006-03-23[PATCH] PCI: fix pci_request_region[s] argJeff Garzik
Add missing 'const' to pci_request_region[s] 'res_name' arg, since we pass it directly to __request_region(), whose 'name' arg is also const. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-03-23[PATCH] PCI: Provide a boot parameter to disable MSIMatthew Wilcox
Several drivers are starting to grow options to disable MSI. However, it's often a host chipset issue, not something which individual drivers should handle. So we add the pci=nomsi kernel parameter to allow the user to disable MSI modes for systems we haven't added to the quirk list yet. Signed-off-by: Matthew Wilcox <matthew@wil.cx> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Acked-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-03-23[PATCH] PCI: return max reserved busnrKristen Accardi
Change the semantics of this call to return the max reserved bus number instead of just the max assigned bus number. Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-03-23[PATCH] PCI: clean up msi.c a bitGrant Grundler
Clean up: move assignments outside of if() statements. AFAICT, no functional change. Easier to read/understand. Depends on "[PATCH 1/3] msi vector targeting abstractions" by Mark Maule <maule@sgi.com>. I expect one hunk to fail if applied against 2.6.15. This is essentially Joe Perches' patch. I've cleaned up the one instance added by Mark's patch. Signed-off-by: Grant Grundler <grundler@parisc-linux.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-31[PATCH] PCI: drivers/pci/pci.c: #if 0 pci_find_ext_capability()Adrian Bunk
This patch #if 0's the unused global function pci_find_ext_capability(). Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09[PATCH] PCI: drivers/pci: some cleanupsAdrian Bunk
This patch contains the following cleanups: - hotplug/pciehp_core.c: make the needlessly global hpdriver_context static - #if 0 the following unused functions: - pci.c: pci_bus_max_busnr() - pci.c: pci_max_busnr() - proc.c: pci_proc_attach_bus() - remove.c: pci_remove_device_safe Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09[PATCH] pci: use pin stored in pci_devKristen Accardi
Use the stored value of the interrupt pin rather than try to read the config again. Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-10[PATCH] PCI: add pci_find_next_capability()Roland Dreier
Some devices have more than one capability of the same type. For example, the PCI header for the PathScale InfiniPath looks like: 04:01.0 InfiniBand: Unknown device 1fc1:000d (rev 02) Subsystem: Unknown device 1fc1:000d Flags: bus master, fast devsel, latency 0, IRQ 193 Memory at fea00000 (64-bit, non-prefetchable) [size=2M] Capabilities: [c0] HyperTransport: Slave or Primary Interface Capabilities: [f8] HyperTransport: Interrupt Discovery and Configuration There are _two_ HyperTransport capabilities, and the PathScale driver wants to look at both of them. The current pci_find_capability() API doesn't work for this, since it only allows us to get to the first capability of a given type. The patch below introduces a new pci_find_next_capability(), which can be used in a loop like for (pos = pci_find_capability(pdev, <ID>); pos; pos = pci_find_next_capability(pdev, pos, <ID>)) { /* ... */ } Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: Matthew Wilcox <matthew@wil.cx> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-30[PATCH] fix missing includesTim Schmielau
I recently picked up my older work to remove unnecessary #includes of sched.h, starting from a patch by Dave Jones to not include sched.h from module.h. This reduces the number of indirect includes of sched.h by ~300. Another ~400 pointless direct includes can be removed after this disentangling (patch to follow later). However, quite a few indirect includes need to be fixed up for this. In order to feed the patches through -mm with as little disturbance as possible, I've split out the fixes I accumulated up to now (complete for i386 and x86_64, more archs to follow later) and post them before the real patch. This way this large part of the patch is kept simple with only adding #includes, and all hunks are independent of each other. So if any hunk rejects or gets in the way of other patches, just drop it. My scripts will pick it up again in the next round. Signed-off-by: Tim Schmielau <tim@physik3.uni-rostock.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-28[PATCH] kernel-doc: PCI fixesRandy Dunlap
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>
2005-10-28[PATCH] pci: cleanup need_restore switch statementJohn W. Linville
Cleanup the need_restore switch statement in pci_set_power_state(). This makes it more safe by explicitly handling all the PCI power states instead of handling them as the default case. It also reads a little better IMHO. Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-14[PATCH] pci: only call pci_restore_bars at bootJohn W. Linville
Certain (SGI?) ia64 boxes object to having their PCI BARs restored unless absolutely necessary. This patch restricts calling pci_restore_bars from pci_set_power_state unless the current state is PCI_UNKNOWN, the actual (i.e. physical) state of the device is PCI_D3hot, and the device indicates that it will lose its configuration when transitioning to PCI_D0. Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09[PATCH] PCI: PCI/libata INTx bug fixBrett M Russ
Previous INTx cleanup patch had a bug that was not caught. I found this last night during testing and can confirm that it is now 100% working. Signed-off-by: Brett Russ <russb@emc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Jeff Garzik <jgarzik@pobox.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-08[PATCH] PCI/libata INTx cleanupBrett M Russ
Simple cleanup to eliminate X copies of the pci_enable_intx() function in libata. Moved ahci.c's pci_intx() to pci.c and use it throughout libata and msi.c. Signed-off-by: Brett Russ <russb@emc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-08[PATCH] PCI: Support PCM PM CAP version 3Daniel 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: Daniel Ritz <daniel.ritz@gmx.ch> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-08[PATCH] PCI: Fix regression in pci_enable_device_barsAlan Stern
This patch (as552) fixes yet another small problem recently added. If an attempt to put a PCI device back into D0 fails because the device doesn't support PCI PM, it shouldn't count as error. Without this patch the UHCI controllers on my Intel motherboard don't work. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-08[PATCH] PCI: start paying attention to a lot of pci function return valuesGreg Kroah-Hartman
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-08[PATCH] PCI: restore BAR values after D3hot->D0 for devices that need itJohn W. Linville
Some PCI devices (e.g. 3c905B, 3c556B) lose all configuration (including BARs) when transitioning from D3hot->D0. This leaves such a device in an inaccessible state. The patch below causes the BARs to be restored when enabling such a device, so that its driver will be able to access it. The patch also adds pci_restore_bars as a new global symbol, and adds a correpsonding EXPORT_SYMBOL_GPL for that. Some firmware (e.g. Thinkpad T21) leaves devices in D3hot after a (re)boot. Most drivers call pci_enable_device very early, so devices left in D3hot that lose configuration during the D3hot->D0 transition will be inaccessible to their drivers. Drivers could be modified to account for this, but it would be difficult to know which drivers need modification. This is especially true since often many devices are covered by the same driver. It likely would be necessary to replicate code across dozens of drivers. The patch below should trigger only when transitioning from D3hot->D0 (or at boot), and only for devices that have the "no soft reset" bit cleared in the PM control register. I believe it is safe to include this patch as part of the PCI infrastructure. The cleanest implementation of pci_restore_bars was to call pci_update_resource. Unfortunately, that does not currently exist for the sparc64 architecture. The patch below includes a null implemenation of pci_update_resource for sparc64. Some have expressed interest in making general use of the the pci_restore_bars function, so that has been exported to GPL licensed modules. Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05[PATCH] swsusp: switch pm_message_t to structPavel Machek
This adds type-checking to pm_message_t, so that people can't confuse it with int or u32. It also allows us to fix "disk yoyo" during suspend (disk spinning down/up/down). [We've tried that before; since that cpufreq problems were fixed and I've tried make allyes config and fixed resulting damage.] Signed-off-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Alexander Nyberg <alexn@telia.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-08Revert "[PATCH] PCI: restore BAR values..."Linus Torvalds
Revert commit fec59a711eef002d4ef9eb8de09dd0a26986eb77, which is breaking sparc64 that doesn't have a working pci_update_resource. We'll re-do this after 2.6.13 when we'll do it all properly.
2005-08-04[PATCH] PCI: restore BAR values after D3hot->D0 for devices that need itJohn W. Linville
Some PCI devices (e.g. 3c905B, 3c556B) lose all configuration (including BARs) when transitioning from D3hot->D0. This leaves such a device in an inaccessible state. The patch below causes the BARs to be restored when enabling such a device, so that its driver will be able to access it. The patch also adds pci_restore_bars as a new global symbol, and adds a correpsonding EXPORT_SYMBOL_GPL for that. Some firmware (e.g. Thinkpad T21) leaves devices in D3hot after a (re)boot. Most drivers call pci_enable_device very early, so devices left in D3hot that lose configuration during the D3hot->D0 transition will be inaccessible to their drivers. Drivers could be modified to account for this, but it would be difficult to know which drivers need modification. This is especially true since often many devices are covered by the same driver. It likely would be necessary to replicate code across dozens of drivers. The patch below should trigger only when transitioning from D3hot->D0 (or at boot), and only for devices that have the "no soft reset" bit cleared in the PM control register. I believe it is safe to include this patch as part of the PCI infrastructure. The cleanest implementation of pci_restore_bars was to call pci_update_resource. Unfortunately, that does not currently exist for the sparc64 architecture. The patch below includes a null implemenation of pci_update_resource for sparc64. Some have expressed interest in making general use of the the pci_restore_bars function, so that has been exported to GPL licensed modules. Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-12[ACPI] merge acpi-2.6.12 branch into latest Linux 2.6.13-rc...Len Brown
Signed-off-by: Len Brown <len.brown@intel.com>
2005-07-11cleanup: remove unnecessary initializer on static pointersGreg Kroah-Hartman
Suggested-by: Greg KH <greg@kroah.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-07-11[ACPI] pci_set_power_state() now callsDavid Shaohua Li
platform_pci_set_power_state() and ACPI can answer http://bugzilla.kernel.org/show_bug.cgi?id=4277 Signed-off-by: David Shaohua Li <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-07-11[ACPI] PCI can now get suspend state from firmwareDavid Shaohua Li
pci_choose_state() can now call platform_pci_choose_state() and ACPI can answer http://bugzilla.kernel.org/show_bug.cgi?id=4277 Signed-off-by: David Shaohua Li <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-07-01[PATCH] pci: cleanup argument comments for pci_{save,restore}_stateJohn W. Linville
The buffer arguments have been removed from pci_{save,restore}_state. The comment blocks for those functions should reflect that. Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-03[PATCH] PCI: drivers/pci/pci.c: remove pci_dac_set_dma_maskAdrian Bunk
pci_dac_set_dma_mask is currently completely unused. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-03[PATCH] PCI: Clean up a lot of sparse "Should it be static?" warnings.Greg KH
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-03[PATCH] PCI: 'is_enabled' flag should be set/cleared when the device is ↵Kenji Kaneshige
actually enabled/disabled I think 'is_enabled' flag in pci_dev structure should be set/cleared when the device actually enabled/disabled. Especially about pci_enable_device(), it can be failed. By this change, we will also get the possibility of refering 'is_enabled' flag from the functions called through pci_enable_device()/pci_disable_device(). Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-04-16Linux-2.6.12-rc2Linus 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!