- 08 Sep, 2005 40 commits
-
-
Greg Kroah-Hartman authored
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
David S. Miller authored
There were three changes necessary in order to allow sparc64 to use setup-res.c: 1) Sparc64 roots the PCI I/O and MEM address space using parent resources contained in the PCI controller structure. I'm actually surprised no other platforms do this, especially ones like Alpha and PPC{,64}. These resources get linked into the iomem/ioport tree when PCI controllers are probed. So the hierarchy looks like this: iomem --| PCI controller 1 MEM space --| device 1 device 2 etc. PCI controller 2 MEM space --| ... ioport --| PCI controller 1 IO space --| ... PCI controller 2 IO space --| ... You get the idea. The drivers/pci/setup-res.c code allocates using plain iomem_space and ioport_space as the root, so that wouldn't work with the above setup. So I added a pcibios_select_root() that is used to handle this. It uses the PCI controller struct's io_space and mem_space on sparc64, and io{port,mem}_resource on every other platform to keep current behavior. 2) quirk_io_region() is buggy. It takes in raw BUS view addresses and tries to use them as a PCI resource. pci_claim_resource() expects the resource to be fully formed when it gets called. The sparc64 implementation would do the translation but that's absolutely wrong, because if the same resource gets released then re-claimed we'll adjust things twice. So I fixed up quirk_io_region() to do the proper pcibios_bus_to_resource() conversion before passing it on to pci_claim_resource(). 3) I was mistakedly __init'ing the function methods the PCI controller drivers provide on sparc64 to implement some parts of these routines. This was, of course, easy to fix. So we end up with the following, and that nasty SPARC64 makefile ifdef in drivers/pci/Makefile is finally zapped. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
John W. Linville authored
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>
-
Kristen Accardi authored
For systems with multiple hotplug controllers, you need to use more than just the slot number to uniquely name the slot. Without a unique slot name, the pci_hp_register() will fail. This patch adds the bus number to the name. Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Michael S. Tsirkin authored
Convert i386/pci to use io_remap_pfn_range instead of remap_pfn_range. This is good for Xen which reuses i386/pci/i386.c for domain 0 code. Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Greg Kroah-Hartman authored
This cleans up some of the #ifdef CONFIG_PCI stuff up, and moves the pci register info out to a separate file, where it belongs. Eventually we can stop including this file from within pci.h, but lots of code needs to be audited first. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Andrew Morton authored
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Adrian Bunk authored
This patch removes CONFIG_PCI_NAMES. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
akpm@osdl.org authored
Make PCI fixup data const, so it'll end up in a r/o section. This also fixes the conversion into ECOFF which gets broken by too many changes between r/w and r/o sections. Call it a hack but it's a change that's correct by itself. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Andi Kleen authored
Run PCI driver initialization on local node Instead of adding messy kmalloc_node()s everywhere run the PCI driver probe on the node local to the device. This would not have helped for IDE, but should for other more clean drivers that do more initialization in probe(). It won't help for drivers that do most of the work on first open (like many network drivers) Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
John Rose authored
Currently rpaphp registers the following bus types as hotplug slots: 1) Actual PCI Hotplug slots 2) Embedded/Internal PCI slots 3) PCI Host Bridges The second and third bus types are not actually direct parents of removable adapters. As such, the rpaphp has special case code to fake results for attributes like power, adapter status, etc. This patch removes types 2 and 3 from the rpaphp module. This patch also changes the DLPAR module so that slots can be DLPAR-added/removed without having been designated as hotplug-capable. Signed-off-by: John Rose <johnrose@austin.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
John Rose authored
This patch exports rpaphp_config_pci_adapter() for use by the rpadlpar module. It also changes this function by removing any dependencies on struct slot. The patch also changes the RPA DLPAR-add path to enable newly-added slots in a separate step from that which registers them as hotplug slots. Signed-off-by: John Rose <johnrose@austin.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
John Rose authored
The rpaphp module currently uses a fragile method to find a pci device by its device node. This function is unnecessary, so this patch scraps it. Signed-off-by: John Rose <johnrose@austin.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
John Rose authored
The slot structure in the rpaphp module currently references the PCI contents of the slot using the PCI device of the parent bridge. This is unnecessary, since the module is actually interested in the subordinate bus of the bridge. The dependency on a PCI bridge device also prohibits the module from registering hotplug slots that have a root bridge as a parent, since root bridges on PPC64 don't have PCI devices. This patch changes struct slot to reference the PCI subsystem using a pci_bus rather than a pci_dev. Signed-off-by: John Rose <johnrose@austin.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
John Rose authored
Currently, rpaphp registers Virtual I/O slots as hotplug slots. The only purpose of this registration is to ensure that the VIO subsystem is notified of new VIO buses during DLPAR adds. Similarly, rpaphp notifies the VIO subsystem when a VIO bus is DLPAR-removed. The rpaphp module has special case code to fake results for attributes like power, adapter status, etc. The VIO register/unregister functions could just as easily be made from the DLPAR module. This patch moves the VIO registration calls to the DLPAR module, and removes the VIO fluff from rpaphp altogether. Signed-off-by: John Rose <johnrose@austin.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
John Rose authored
Subject line says it all :) Signed-off-by: John Rose <johnrose@austin.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Linus Torvalds authored
-
Al Viro authored
When we copy 32bit ->msg_control contents to kernel, we walk the same userland data twice without sanity checks on the second pass. Second version of this patch: the original broke with 64-bit arches running 32-bit-compat-mode executables doing sendmsg() syscalls with unaligned CMSG data areas Another thing is that we use kmalloc() to allocate and sock_kfree_s() to free afterwards; less serious, but also needs fixing. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Kumar Gala authored
head_4xx.S wasn't compiling due to a missing #endif Signed-off-by: Kumar Gala <kumar.gala@freescale.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
-
Hannes Reinecke authored
ICH6 spec defines the PORT_ bits as: PORT_ENABLED (R/W): 0 = Disabled. The port is in the off state and cannot detect any devices. 1 = Enabled. The port can transition between the on, partial, and slumber states and can detect devices. PORT_PRESENT (R/O) The status of this bit may change at any time. This bit is cleared when the port is disabled via PORT_ENABLED. This bit is not cleared upon surprise removal of a device. So from a textual view it is not necessary that PORT_PRESENT _must_ be set, especially if a device detection has to be done anyway. And, in fact, this is the view that ACER has been taken with its new Laptops (e.g. Travelmate 4150). And the definition of PORT_ENABLED / PORT_PRESENT is mixed up, btw. Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Jens Axboe <axboe@suse.de> Cc: Jeff Garzik <jgarzik@pobox.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
-
Jeff Garzik authored
-
Len Brown authored
-
Nathan Scott authored
Signed-off-by: Nathan Scott <nathans@sgi.com>
-
Nathan Scott authored
Signed-off-by: Eric Sandeen <sandeen@sgi.com> Signed-off-by: Nathan Scott <nathans@sgi.com>
-
Nathan Scott authored
Christoph). SGI-PV: 942400 SGI-Modid: xfs-linux-melb:xfs-kern:23771a Signed-off-by: Nathan Scott <nathans@sgi.com>
-
Linus Torvalds authored
With the previous commit that introduces the klist enhancements, we can now re-do 2b7d6a8c again.
-
James Bottomley authored
The problem is that klists claim to provide semantics for safe traversal of lists which are being modified. The failure case is when traversal of a list causes element removal (a fairly common case). The issue is that although the list node is refcounted, if it is embedded in an object (which is universally the case), then the object will be freed regardless of the klist refcount leading to slab corruption because the klist iterator refers to the prior element to get the next. The solution is to make the klist take and release references to the embedding object meaning that the embedding object won't be released until the list relinquishes the reference to it. (akpm: fast-track this because it's needed for the 2.6.13 scsi merge) Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
Revert commit 2b7d6a8c. The "fix" was known to not even compile. Duh. That's not a fix. That's just stupid. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Arnaud Patard authored
This patch adds support for the SiS182 sata chipset. This is a minimalistic version of the patch from http://bugme.osdl.org/show_bug.cgi?id=4192. Basically, it add the PCI IDs and handles the change of the 2nd port adress register. Signed-Off-By: Arnaud Patard <apatard@mandriva.com> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
viro@ZenIV.linux.org.uk authored
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
viro@ZenIV.linux.org.uk authored
Now that asm-powerpc/* is using ifdefs on __powerpc64__ we need to add it to CHECKFLAGS on ppc64. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-