That's what we've always historically done, and bigger windows seem to
confuse some cardbus bridges. Or something.
Alan reports that this makes the ThinkPad 600x series work properly
again: the 4kB IO window for some reason made IDE DMA not work, which
makes IDE painfully slow even if it works after DMA timeouts.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This still leaves driver and architecture-specific subdirectories alone,
but gets rid of the bulk of the "generic" generated files that we should
ignore.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This change makes quirk_intel_ide_combined() dependent on the precise
conditions under which it is needed:
* IDE is built in
* IDE SATA option is not set
* ata_piix or ahci drivers are enabled
This fixes an issue where some modular configurations would not cause
the quirk to be enabled.
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Linus torvalds <torvalds@osdl.org>
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>
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>
This patch converts kcalloc(1, ...) calls to use the new kzalloc() function.
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
PCI_ROM_ADDRESS is a 32 bit register and as such should be accessed using
pci_bus_{read,write}_config_dword(). A recent audit of drivers/ turned up
several cases of byte- and word-sized accesses. The harmful ones were fixed
by Linus directly. This patches up one of the remaining
harmless-but-still-wrong cases caught in the dragnet.
Signed-off-by: Adam Kropelin <akropel1@rochester.rr.com>
Cc: <kristen.c.accardi@intel.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
PCI_ROM_ADDRESS is a 32 bit register and as such should be accessed
using pci_bus_{read,write}_config_dword(). A recent audit of drivers/
turned up several cases of byte- and word-sized accesses. The harmful
ones were fixed by Linus directly. This patches up one of the remaining
harmless-but-still-wrong cases caught in the dragnet.
Signed-off-by: Adam Kropelin <akropel1@rochester.rr.com>
Cc: <kristen.c.accardi@intel.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
PCI_ROM_ADDRESS is a 32 bit register and as such should be accessed using
pci_bus_{read,write}_config_dword(). A recent audit of drivers/ turned up
several cases of byte- and word-sized accesses. The harmful ones were fixed
by Linus directly. This patches up one of the remaining
harmless-but-still-wrong cases caught in the dragnet.
Signed-off-by: Adam Kropelin <akropel1@rochester.rr.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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>
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>
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>
Trivial patch against 2.6.13 to unhide SMBus on Compaq Evo N620c laptop using
Intel 82855PM chipset.
Signed-off-by: Rumen Zarev <rzarev@caltech.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Martin Franc reported that the pciehp driver was not enabling bus
master capability on his hot-plugged card. pciehprm_enable_card()
was updating the PCI command register only if _HPP indicated a
value for SERR or PERR that was different from the current setting.
I don't have hardware that reproduces this problem, but Martin
reports that this patch fixes the problem for him.
Signed-off-by: Rajesh Shah <rajesh.shah@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
From rzarev@its.caltech.edu Tue Sep 6 18:29:50 2005
Date: Tue, 6 Sep 2005 13:39:32 -0700 (PDT)
From: Rumen Ivanov Zarev <rzarev@its.caltech.edu>
Message-Id: <200509062039.j86KdWMr014934@inky.its.caltech.edu>
To: gregkh@suse.de
Subject: PCI: Unhide SMBus on Compaq Evo N620c
Cc: linux-kernel@vger.kernel.org
Trivial patch against 2.6.13 to unhide SMBus on Compaq Evo N620c laptop using
Intel 82855PM chipset.
Signed-off-by: Rumen Zarev <rzarev@caltech.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/pci/quirks.c | 6 ++++++
1 file changed, 6 insertions(+)
--- gregkh-2.6.orig/drivers/pci/quirks.c 2005-09-09 10:28:55.000000000 -0700
+++ gregkh-2.6/drivers/pci/quirks.c 2005-09-09 13:51:44.000000000 -0700
@@ -876,6 +876,12 @@ static void __init asus_hides_smbus_host
case 0xC00C: /* Samsung P35 notebook */
asus_hides_smbus = 1;
}
+ } else if (unlikely(dev->subsystem_vendor == PCI_VENDOR_ID_COMPAQ)) {
+ if (dev->device == PCI_DEVICE_ID_INTEL_82855PM_HB)
+ switch(dev->subsystem_device) {
+ case 0x0058: /* Compaq Evo N620c */
+ asus_hides_smbus = 1;
+ }
}
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82845_HB, asus_hides_smbus_hostbridge );
Share code between setup-bus.c and yenta_socket.c: use the write-out code of
resources to the bridge also in yenta_socket.c, as it provides useful debug
output. In addition, it fixes the bug that the CPU-centric resource view
might need to be transferred to the PCI-centric view: setup-bus.c does that,
while yenta-socket.c did not.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This fixes a bug in the environment variables for all PCI device hotplug calls.
Thanks to Kay Sievers for pointing out the problem.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
This patch pulls the PCI-related junk out of struct device_node and
puts it in a separate structure, struct pci_dn. The device_node now
just has a void * pointer in it, which points to a struct pci_dn for
nodes that represent PCI devices. It could potentially be used in
future for device-specific data for other sorts of devices, such as
virtual I/O devices.
Signed-off-by: Paul Mackerras <paulus@samba.org>
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>
- 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>
The PCI error recovery infrastructure needs to be able to contact all
the drivers affected by a PCI error event, which may mean traversing
all the devices under a given PCI-PCI bridge. This patch adds a
function to the PCI core that traverses all the PCI devices on a PCI
bus and under any PCI-PCI bridges on that bus (and so on), calling a
given function for each device. This provides a way for the error
recovery code to iterate through all devices that are affected by an
error event.
This version is not implemented as a recursive function. Instead,
when we reach a PCI-PCI bridge, we set the pointers to start doing the
devices on the bus under the bridge, and when we reach the end of a
bus's devices, we use the bus->self pointer to go back up to the next
higher bus and continue doing its devices.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
These fixes were suggested by pcihpd-discuss, but were dropped in the
initial checkin of the code. These fixes include cleaning up the
hotplug driver sysfs filename, and some minor code cleanups. The driver
also requires at least PROM 4.30, not 4.20.
Signed-off-by: Prarit Bhargava <prarit@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
When handling writes to /proc/irq, current code is re-programming rte
entries directly. This is not recommended and could potentially cause
chipset's to lockup, or cause missing interrupts.
CONFIG_IRQ_BALANCE does this correctly, where it re-programs only when the
interrupt is pending. The same needs to be done for /proc/irq handling as well.
Otherwise user space irq balancers are really not doing the right thing.
- Changed pending_irq_balance_cpumask to pending_irq_migrate_cpumask for
lack of a generic name.
- added move_irq out of IRQ_BALANCE, and added this same to X86_64
- Added new proc handler for write, so we can do deferred write at irq
handling time.
- Display of /proc/irq/XX/smp_affinity used to display CPU_MASKALL, instead
it now shows only active cpu masks, or exactly what was set.
- Provided a common move_irq implementation, instead of duplicating
when using generic irq framework.
Tested on i386/x86_64 and ia64 with CONFIG_PCI_MSI turned on and off.
Tested UP builds as well.
MSI testing: tbd: I have cards, need to look for a x-over cable, although I
did test an earlier version of this patch. Will test in a couple days.
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
Acked-by: Zwane Mwaikambo <zwane@holomorphy.com>
Grudgingly-acked-by: Andi Kleen <ak@muc.de>
Signed-off-by: Coywolf Qi Hunt <coywolf@lovecn.org>
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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>
The VIA VT8237's IOAPIC sends 'APIC De-Assert Messages' by default, causing
another CPU interrupt when the IRQ pin is de-asserted. This feature is
switched off by the patch to get rid of doubled ioapic level interrupt
rates.
Signed-off-by: Karsten Wiese <annabellesgarden@yahoo.de>
Tested-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This fixes a problem with pci_map_rom() which doesn't properly
update the ROM BAR value with the address thas allocated for it by the
PCI code. This problem, among other, breaks boot on Mac laptops.
It'ss a new version based on Linus latest one with better error
checking.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I had some time to think about PCI assign issues in 2.6.13-rc series.
The major problem here is that we call pci_assign_unassigned_resources()
way too early - at subsys_initcall level. Therefore we give no chances
to ACPI and PnP routines (called at fs_initcall level) to reserve their
respective resources properly, as the comments in drivers/pnp/system.c
and drivers/acpi/motherboard.c suggest:
/**
* Reserve motherboard resources after PCI claim BARs,
* but before PCI assign resources for uninitialized PCI devices
*/
So I moved the pci_assign_unassigned_resources() call to
pcibios_assign_resources() (fs_initcall), which should hopefully fix a
lot of problems and make PCIBIOS_MIN_IO tweaks unnecessary.
Other changes:
- remove resource assignment code from pcibios_assign_resources(), since
it duplicates pci_assign_unassigned_resources() functionality and
actually does nothing in 2.6.13;
- modify ROM assignment code as per Ben's suggestion: try to use firmware
settings by default (if PCI_ASSIGN_ROMS is not set);
- set CARDBUS_IO_SIZE back to 4K as it's a wonderful stress test for
various setups.
Confirmed by Tero Roponen <teanropo@cc.jyu.fi> (who had problems with
the 4kB CardBus IO size previously).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Writing even a disabled value seems to mess up some matrox graphics
cards. It may be a card-related issue, but we may also be writing
reserved low bits in the result.
This was a fall-out of switching x86 over to the generic PCI resource
allocation code, and needs more debugging. In particular, the old x86
code defaulted to not doing any resource allocations at all for ROM
resources.
In the meantime, this has been reported to make X happier by Helge
Hafting <helgehaf@aitel.hist.no>.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
It may seem small, but most cards need much less, if any, and this not
only makes the code adhere to the comment, it seems to fix a boot-time
lockup on a ThinkPad 380XD laptop reported by Tero Roponen <teanropo@cc.jyu.fi>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
On the 6700/6702 PXH part, a MSI may get corrupted if an ACPI hotplug
driver and SHPC driver in MSI mode are used together.
This patch will prevent MSI from being enabled for the SHPC as part of
an early pci quirk, as well as on any pci device which sets the no_msi
bit.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Revert commit fec59a711e, 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.
Like many other southbridges from different manufacturers, VIA VT8235
chip has two non-standard BARs for power management and SMBus registers
(see the datasheet at http://www.via.com.tw).
This new quirk routine fixes boot problem with 2.6.13-rc2/rc6 kernels on
Targa Visionary 811 Athlon64 laptop, as reported by Mikael Pettersson
<mikpe@csd.uu.se>.
Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
For 64-bit BAR[i] only pci_dev->resource[i] is valid, ->resource[i+1]
slot is unused and contains zeroes in all fields.
So when we update a PCI BAR, all we need is just to check that we're
going to update a _valid_ resource.
Also make sure to write high bits - use "x >> 16 >> 16" (rather than the
simpler ">> 32") to avoid warnings on 32-bit architectures where we're
not going to have any high bits.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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>
The reason we have PCIBIOS_MIN_IO and PCIBIOS_MIN_CARDBUS_IO is because
we want to protect badly documented motherboard PCI resources and thus
don't want to allocate new resources in low IO/MEM space.
However, if we have already discovered a PCI bridge with a specified
resource base, that should override that decision.
This change will allow us to move the "careful" region upwards without
resulting in problems allocating resources in low mappings. This was
brought on by us having allocated a bus resource at 0x1000, conflicting
with a undocumented VAIO Sony PI resources.
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>
There are ROMs reporting that their size exceeds their PCI ROM
resource window. This patch returns the minimum of the resource window
size or the size in the ROM. An example of this breakage is the XGI
Volari Z7.
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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>
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>
Few more u32 vs. pm_message_t fixes.
Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
There is a slight disagreement between setup-bus.c code and traditional
x86 PCI setup wrt which recourses are invalid vs resources that are free
for further allocations.
In particular, in the setup-bus.c, if we failed to allocate some resource,
we nullify "start" and "flags" fields, but *not* the "end" one.
But x86 pcibios_enable_resources() does the following check:
if (!r->start && r->end) {
printk(KERN_ERR "PCI: Device %s not available because of resource collisions\n", pci_name(dev));
return -EINVAL;
which means that the device owning the offending resource cannot be
enabled.
In particular, this breaks cardbus behind the normal decode p2p bridge -
the cardbus code from setup-bus.c requests rather large IO and MEM
windows, and if it fails, the socket is completely unavailable. Which
is wrong, as the yenta code is capable to allocate smaller windows.
Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch is the SGI hotplug driver and additional changes required for
the driver. These modifications include changes to the SN io_init.c code
for memory management, the inclusion of new SAL calls to enable and disable
PCI slots, and a hotplug-style driver.
Signed-off-by: Prarit Bhargava <prarit@sgi.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
The pci_find_next_bus function is listed as being exported to drivers. It is
not EXPORT_SYMBOL'd.
Signed-off-by: Prarit Bhargava <prarit@sgi.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Here's a patch to fix the build issue when CONFIG_HOTPLUG is not enabled
in 2.6.13-rc2.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
It seems that X86 architectures in general need the setup-bus.o
not just those with HOTPLUG. This avoids the following error on
X86_NUMAQ and x86_64:
arch/i386/pci/built-in.o(.init.text+0x15a6): In function `pcibios_init':
: undefined reference to `pci_assign_unassigned_resources'
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
the pci core sends out a hotplug event variable MODALIAS with a trailing
newline. This is inconsistent with all other event variables and breaks
some hotplug tools. This patch removes the said newline.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch, is based on kernel 2.6.12, provides a fix for PCIe
port bus driver suspend/resume.
Signed-off-by: T. Long Nguyen <tom.l.nguyen@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
One more Asus motherboard requiring the SMBus quirk (P4B-LX). Original
patch from Salah Coronya.
Signed-off-by: Salah Coronya <salahx@yahoo.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The dynamic pci id logic has been bothering me for a while, and now that
I started to look into how to move some of this to the driver core, I
thought it was time to clean it all up.
It ends up making the code smaller, and easier to follow, and fixes a
few bugs at the same time (dynamic ids were not being matched
everywhere, and so could be missed on some call paths for new devices,
semaphore not needed to be grabbed when adding a new id and calling the
driver core, etc.)
I also renamed the function pci_match_device() to pci_match_id() as
that's what it really does.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
- Add sanity check for io[port,mem]_resource in setup-bus.c. These
resources look like "free" as they have no parents, but obviously
we must not touch them.
- In i386.c:pci_allocate_bus_resources(), if a bridge resource cannot be
allocated for some reason, then clear its flags. This prevents any child
allocations in this range, so the setup-bus code will work with a clean
resource sub-tree.
- i386.c:pcibios_enable_resources() doesn't enable bridges, as it checks
only resources 0-5, which looks like a clear bug to me. I suspect it
might break hotplug as well in some cases.
From: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
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>
drivers/pci/hotplug/cpqphp_core.c calls cpqphp_event_start_thread()
in one_time_init(), which is called whenever the hardware is probed.
Unfortunately, cpqphp_event_stop_thread() is *always* called when
the module is unloaded. If the hardware is never probed, then
cpqphp_event_stop_thread() tries to manipulate a couple of
uninitialized mutexes.
Signed-off-by: Keith Moore <keithmo@exmsft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mostly just cleans up the irq handling logic to be smaller and a bit more
descriptive as to what it really does.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This is an updated version of Ben's fix-pci-mmap-on-ppc-and-ppc64.patch
which is in 2.6.12-rc4-mm1.
It fixes the patch to work on PPC iSeries, removes some debug printks
at Ben's request, and incorporates your
fix-pci-mmap-on-ppc-and-ppc64-fix.patch also.
Originally from Benjamin Herrenschmidt <benh@kernel.crashing.org>
This patch was discussed at length on linux-pci and so far, the last
iteration of it didn't raise any comment. It's effect is a nop on
architecture that don't define the new pci_resource_to_user() callback
anyway. It allows architecture like ppc who put weird things inside of
PCI resource structures to convert to some different value for user
visible ones. It also fixes mmap'ing of IO space on those archs.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds PCI based I/O xAPIC hot-add support to ACPIPHP
driver. When PCI root bridge is hot-added, all PCI based I/O xAPICs
under the root bridge are hot-added by this patch. Hot-remove support
is TBD.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Current acpiphp code does not distinguish between the physical presence and
power state of a device/slot. That is, if a device has to be disabled, it
also tries to physically ejects the device. This patch decouples power state
from physical presence. You can now echo to the corresponding sysfs power
control file to repeatedly enable and disable a device without having to
physically re-insert it.
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>
acpiphp changes to support acpi based root bridge hot-add.
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>
Earlier I reported that Matthew's acpiphp rewrite had problem in powering down
slot on my i386 system. The following patch is needed to get the acpiphp
rewrite properly powering down the slot.
Signed-off-by: Dely Sy <dely.l.sy@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
A root bridge may not have directly attached hotpluggable slots under it.
Instead, it may have p2p bridges with slots under it. In this case, we need
to clean up the p2p bridges and slots properly too. Patch below applies on
top of the original patch, and fixes this problem. Without this, acpiphp
leaves behind notify handlers on module unload, and subsequent module load
attempts don't work properly too. Patch was tested on an ia64 Tiger4 box.
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>
This patch converts acpiphp to use the generic PCI resource assignment code.
It's quite large, but most of it is deleting the acpiphp_pci and acpiphp_res
files. It's tested on an hp Integrity rx8620 (which won't work without this
patch). Testers with other hardware welcomed.
Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When hot-plugging an I/O hierarchy that contains many bridges and leaf
devices, it's possible that there are not enough resources to start all the
device present. If we fail to assign a resource, clear the corresponding
value in the pci_dev structure, so other code can take corrective action.
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>
When a root bridge hierarchy is hot-plugged, resource requirements for the new
devices may be greater than what the root bridge is decoding. In this case,
we want to remove devices that did not get needed resources. These devices
have been scanned into bus specific lists but not yet added to the global
device list. Make sure the pci remove functions can handle this case.
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>
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>
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>
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>
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>
