Based on a patch series originally from Vivek Goyal <vgoyal@in.ibm.com>
Cc: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This is needed if we wish to change the size of the resource structures.
Based on an original patch from Vivek Goyal <vgoyal@in.ibm.com>
Cc: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivial:
typo fixes
Clean up 'inline is not at beginning' warnings for usb storage
Storage class should be first
i386: Trivial typo fixes
ixj: make ixj_set_tone_off() static
spelling fixes
fix paniced->panicked typos
Spelling fixes for Documentation/atomic_ops.txt
move acknowledgment for Mark Adler to CREDITS
remove the bouncing email address of David Campbell
CC drivers/pci/msi-apic.o
In file included from include/asm/msi.h:11,
from drivers/pci/msi.h:71,
from drivers/pci/msi-apic.c:8:
include/asm/smp.h:103: error: syntax error before '->' token
akpm: nasty. It appears to be
static inline unsigned int cpu_mask_to_apicid(cpumask_t cpumask)
conflicting with include/asm-x86_64/mach_apic.h's
#define cpu_mask_to_apicid (genapic->cpu_mask_to_apicid)
And I don't know which patch in rc4-mm1 triggered this.
Fixing this in the .c file seems wrong.
Including asm/smp.h instead of linux/smp.h seems wrong too. Need that
.config.
Cc: Andi Kleen <ak@muc.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The nVidia CK804 PCI-E chipset supports the AER extended capability
but sometimes fails to link it (with some BIOS or after a warm reboot).
It makes the AER cap invisible to pci_find_ext_capability().
The patch adds a quirk to set the missing bit that controls the
linking of the capability.
By the way, it removes the corresponding code in the myri10ge driver.
Signed-off-by: Brice Goglin <brice@myri.com>
Signed-off-by: Loic Prylli <loic@myri.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
From: Doug Thompson <norsk5@yahoo.com>
This patch adds the 'broken_parity_status' sysfs attribute file to a PCI device.
Reading this attribute a userland program can determine if PCI device provides false
positives (value of 1) in its generation of PCI Parity status, or not (value of 0).
As PCI devices are found to be 'bad' in this regard, userland programs can also set
the appropriate value (root access only) of a faulty device. This per device
information will be used in the EDAC PCI Parity scanner code in a future patch once
this interface becomes available.
Signed-off-by: Doug Thompson <norsk5@yahoo.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Be more selective when running the MSI-K8T-Neo2Fir soundcard PCI quirk so
as not to run this on hardware where it's probably not needed.
Signed-off-by: Chris Wedgwood <cw@f00f.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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: Zhang Yanmin <yanmin.zhang@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The code is really not needed.
Roland Dreier/Greg KH removed the release_mem_region() calls that
were the only consumers of phys_addr:
http://www.ussg.iu.edu/hypermail/linux/kernel/0503.0/1540.html
patch below deletes the "dead" code.
Signed-off-by: Grant Grundler <iod00d@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
A recent Stratus x86_64 platform uses a system ioapic that is a PCI device
located below a PCI bridge. Other platforms like this may exist.
This patch fixes a problem wherein the kernel's PCI setup code moves
the ioapic to an address other than that assigned by the BIOS. It simply
adds another exclusion (which already includes classless devices and host
bridges) to the function pbus_assign_resources_sorted so that it will not
move the ioapic.
If the ioapic is moved, the fixmap mapping to it is broken, so the OS should
leave it alone.
From: Kimball Murray <kimball.murray@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In IA64 platform, msi driver does not use irq_vector variable, and in
x86 platform LAST_DEVICE_VECTOR should one before FIRST_SYSTEM_VECTOR,
this patch modify this.
Signed-off-by: bibo, mao <bibo.mao@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Brice said the pci_save_msi_state breaks his driver in his special usage
(not in suspend/resume), as pci_save_msi_state will disable msi mode. In
his usage, pci_save_state will be called at runtime, and later (after
the device operates for some time and has an error) pci_restore_state
will be called.
In another hand, suspend/resume needs disable msi mode, as device should
stop working completely. This patch try to workaround this issue.
Drivers are expected call pci_disable_device in suspend time after
pci_save_state.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We recently ran into a problem where the e1000 device failed to
work properly on the kexec kernel. MSI was enabled for the
device in the main kernel when it crashed. The e1000 driver
tried to enable MSI on the kexec kernel, but the code bailed
early when it found that MSI was already enabled in the hardware,
even though the software state was not properly set up in the
kexec'd kernel. This patch fixes the problem by moving the
early return to after making sure that the software state
is properly initialized.
Signed-off-by: Rajesh Shah <rajesh.shah@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The PCI_BUS_FLAGS_NO_MSI bus flags does not appear do be inherited
correctly from the amd8131 MSI quirk to its parent busses. It makes
devices behind a bridge behind amd8131 try to enable MSI while the
amd8131 does not support it.
We fix this by looking at flags of all parent busses in
pci_enable_msi() and pci_enable_msix().
By the way, also add the missing dev->no_msi check in pci_enable_msix()
Signed-off-by: Brice Goglin <brice@myri.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Currently, the EDAC (error detection and correction) modules that are in
the kernel contain some features that need to be moved. After some good
feedback on the PCI Parity detection code and interface
(http://www.ussg.iu.edu/hypermail/linux/kernel/0603.1/0897.html) this
patch ADDs an new attribute to the pci_dev structure: Namely the
'broken_parity_status' bit.
When set this indicates that the respective hardware generates false
positives of Parity errors.
The EDAC "blacklist" solution was inferior and will be removed in a
future patch.
Also in this patch is a PCI quirk.c entry for an Infiniband PCI-X card
which generates false positive parity errors.
I am requesting comments on this AND on the possibility of a exposing
this 'broken_parity_status' bit to userland via the PCI device sysfs
directory for devices. This access would allow for enabling of this
feature on new devices and for old devices that have their drivers
updated. (SLES 9 SP3 did this on an ATI motherboard video device). There
is a need to update such a PCI attribute between kernel releases.
This patch just adds a storage place for the attribute and a quirk entry
for a known bad PCI device. PCI Parity reaper/harvestor operations are
in EDAC itself and will be refactored to use this PCI attribute instead
of its own mechanisms (which are currently disabled) in the future.
Signed-off-by: Doug Thompson <norsk5@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There were two instances of pci_acpi_init(), one in
drivers/pci/pci-acpi.c and another in arch/i386/pci/acpi.c.
Rename the one in pci-acpi.c and make it consistent with
other names in the same file.
Signed-off-by: Muthukumar R <muthur@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If a device is already enabled, don't bother reenabling it.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Acked-By: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds an "enable" sysfs attribute to each PCI device. When read it
shows the "enabled-ness" of the device, but you can write a "0" into it to
disable a device, and a "1" to enable it.
This later is needed for X and other cases where userspace wants to enable
the BARs on a device (typical example: to run the video bios on a secundary
head). Right now X does all this "by hand" via bitbanging, that's just evil.
This allows X to no longer do that but to just let the kernel do this.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
CC: Peter Jones <pjones@redhat.com>
Acked-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
PCI: Add pci_assign_resource_fixed -- allow fixed address assignments
On some embedded systems the PCI address for hotplug devices are not only
known a priori but are required to be at a given PCI address for other
master in the system to be able to access.
An example of such a system would be an FPGA which is setup from user space
after the system has booted. The FPGA may be access by DSPs in the system
and those DSPs expect the FPGA at a fixed PCI address.
Added pci_assign_resource_fixed() as a way to allow assignment of the PCI
devices's BARs at fixed PCI addresses.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[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: H. Peter Anvin <hpa@c2micro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
MSI callouts for altix. Involves a fair amount of code reorg in sn irq.c
code as well as adding some extensions to the altix PCI provider abstaction.
Signed-off-by: Mark Maule <maule@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Abstract IA64_FIRST_DEVICE_VECTOR/IA64_LAST_DEVICE_VECTOR since SN platforms
use a subset of the IA64 range. Implement this by making the above macros
global variables which the platform can override in it setup code.
Also add a reserve_irq_vector() routine used by SN to mark a vector's as
in-use when that weren't allocated through assign_irq_vector().
Signed-off-by: Mark Maule <maule@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Abstract portions of the MSI core for platforms that do not use standard
APIC interrupt controllers. This is implemented through a new arch-specific
msi setup routine, and a set of msi ops which can be set on a per platform
basis.
Signed-off-by: Mark Maule <maule@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Remove checks for value, since the hotplug core always provides
a valid value.
Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Current SHPCHP driver shows device number of slots in info messages,
but it is useless and should be replaced with slot name.
This patch replaces the device number shown in the info messages with
the slot name.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Kristen Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch removes unused hpc_event_lock. This patch has no functional
change.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Kristen Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch cleans up the interrupt polling timer code in
shpchp_hpc.c. This has no functional changes.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Kristen Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch cleans up the code related to issuing SHPC commands. This
patch has no functional changes.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Kristen Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch cleans up the interrupt handler of shpchp driver. This
patch has no functional changes.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Kristen Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch implements .get_address callback of hotplug_slot_ops for
PCIEHP driver. With this patch, we can see bus address of hotplug
slots as follows:
# cat /sys/bus/pci/slots/0010_0000/address
0000:0a:00
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Kristen Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch replaces pci_find_slot() with pci_get_slot() in PCIEHP
driver. This patch enables PCI Express Hotplug on the system which has
multiple PCI domains.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Kristen Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This is a repost of a patch submitted by Prarit Bhargava on 01-19-06 that
never got integrated.
The get_power_status function is currently reporting a bitwise mapping of
the slot if the slot is powered on. It should return 1 if powered on and
0 if powered off.
Signed-off-by: Mike Habeck <habeck@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The workqueue thread of shpchp driver should be created only when SHPC
based hotplug slots are detected on the system.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Kristen Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Global SERR and Interrupt should be masked at shpchp driver unload time.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Kristen Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Current SHPCHP driver doesn't take care of RsvdP/RsvdZ[*] bits in
controller SERR-INT register. This might cause unpredicable
results. This patch fixes this bug.
[*] RsvdP and RsvdZ are defined in SHPC spec as follows:
RsvdP - Reserved and Preserved. Register bits of this type are
reserved for future use as R/W bits. The value read is
undefined. Writes are ignored. Software must follow These rules
when accessing RsvdP bits:
- Software must ignore RsvdP bits when testing values read
from these registers.
- Software must not depend on RsvdP bit's ability to retain
information when written
- Software must always write back the value read in the RsvdP
bits when writing one of these registers.
RsvdZ - Reserved and Zero. Register bits of this type are reserved
for future use as R/WC bits. The value read is undefined. Writes
are ignored. Software must follow these rules when accessing RsvdZ
bits:
- Software must ignore RsvdZ bits when testing values read
from these registers.
- Software must not depends on a RsvdZ bit's ability to retain
information when written.
- Software must always write 0 to RsvdZ bits when writing one
of these register.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Kristen Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Current SHPCHP driver doesn't take care of RsvdP/RsvdZ[*] bits
in logical slot registers. This might cause unpredicable results. This
patch fixes this bug.
[*] RsvdP and RsvdZ are defined in SHPC spec as follows:
RsvdP - Reserved and Preserved. Register bits of this type are
reserved for future use as R/W bits. The value read is
undefined. Writes are ignored. Software must follow These rules
when accessing RsvdP bits:
- Software must ignore RsvdP bits when testing values read
from these registers.
- Software must not depend on RsvdP bit's ability to retain
information when written
- Software must always write back the value read in the RsvdP
bits when writing one of these registers.
RsvdZ - Reserved and Zero. Register bits of this type are reserved
for future use as R/WC bits. The value read is undefined. Writes
are ignored. Software must follow these rules when accessing RsvdZ
bits:
- Software must ignore RsvdZ bits when testing values read
from these registers.
- Software must not depends on a RsvdZ bit's ability to retain
information when written.
- Software must always write 0 to RsvdZ bits when writing one
of these register.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Kristen Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch cleans up the code to access bits in slot logical
registers. This patch has no functional change.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Kristen Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch cleans up the code to access slot logical registers. This
patch has no functional changes.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Kristen Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch cleans up the code to access SHPC working register
sets. This patch has no functional changes.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Kristen Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Current PCHEHP driver doesn't have any code to program hotplug
parameters from firmware. So hotplug parameters are never programed at
hot-add time. This patch add support for programming hotplug
parameters to PCIEHP driver.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Kristen Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds support for _HPX (Hot Plug Parameter Extensions)
defined in ACPI3.0a spec.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Kristen Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch converts the improper error message about OSHP evaluation
to debug message which is displayed only when pci_hotplug.ko is loaded
with debugging mode enabled. To do this, this patch adds a new module
parameter "debug_acpi" to pci_hotplug.ko for enabling/disabling debug
messages in acpi_pcihp.c.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Kristen Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes the problem that hotplug parameters are not programed
when PCI cards are hot-added by ACPIPHP, SHPCHP and PCIEHP driver. The
pci_dev structure being hot-added is not bound to ACPI handle, so we
need to trace PCI bus tree to find ACPI handle.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Kristen Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Don't call pci_enable_device from pciehp because the pcie port service driver
already does this.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
acpi_os_free should not be used by drivers outside
of acpi/*/*.c. Replace with kfree().
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When acpiphp_enable_slot() is failed, acpiphp does not change
the slot->flags. Therefore, when user tries to read power
status, acpiphp_get_power_status() returns the enable status
whether the slot is not really enabled.
This patch fixes this BUG.
Signed-off-by: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
I encountered the problem that when there are some hotplug
slots are under the host bridge, the hotplug slots under the
p2p bridge are not treated as hotpluggable.
This patch fixes this BUG.
Signed-off-by: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
o hotplug slots add
When the hot-added PCI device is p2p bridge, acpiphp calls
find_p2p_bridge() to add hotplug slots.
o hotplug slots remove
When the hot-removing PCI device is p2p bridge, acpiphp
calls cleanup_p2p_bridge() to remove hotplug slots.
o notify handler exchange
When the p2p bridge is added, acpiphp changes the notify
hanlder.
If no bridge device is inserted into the hotpluggable PCI
slot, acpiphp installs the notify handler for function.
After the p2p bridge hot-add, acpiphp has to install the
notify handler for bridge. Because, the role of the
handlers are not same. The hot-remove case is ditto.
Signed-off-by: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Current acpiphp does not free acpi_device structs when the
PCI devices are removed. When the PCI device is added,
acpi_bus_add() fails because acpi_device struct has already
exists. So, _PRT method does not evaluate.
This patch fixes this issue.
Signed-off-by: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
SGI hotplug driver changes required to support Tollhouse system PCI
hotplug, and implements the PRF_HOTPLUG_SUPPORT feature bit.
Signed-off-by: Prarit Bhargava <prarit@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
According to Intel ICH spec, there are several rules that Base Address
should be programmed before IOSE (PCICMD register ) enabled.
For example ICH7:
12.1.3 SATA : the base address register for the bus master register
should be programmed before this bit is set.
11.1.3: PCICMD (USB): The base address register for USB should be
programmed before this bit is set.
....
To make sure kernel code follow this rule , and prevent unnecessary
confusion. I proposal this patch.
Signed-off-by: Luming Yu <luming.yu@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
At least one laptop blew up on resume from suspend with a black screen due
to a lack of this patch. By only writing back config space that is
different, we minimise the possibility of accidents like this.
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We currently don't handle errors properly when resuming a PCI device:
* In pci_default_resume() we capture the error code returned by
pci_enable_device() but don't pass it up to the caller.
Introduced by commit 95a629657d
* In pci_resume_device(), the errors possibly returned by the driver's
.resume method or by the generic pci_default_resume() function are
ignored.
This patch fixes both issues.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch revives pci_find_ext_capability (has been disabled a couple month
ago since it was not used anywhere. See http://lkml.org/lkml/2006/1/20/247).
It will now be used by the myri10ge driver.
Signed-off-by: Brice Goglin <brice@myri.com>
Signed-off-by: Andrew J. Gallatin <gallatin@myri.com>
drivers/pci/pci.c | 3 +--
include/linux/pci.h | 2 ++
2 files changed, 3 insertions(+), 2 deletions(-)
Signed-off-by: Jeff Garzik <jeff@garzik.org>
The OSC set and query functions do not allocate enough space for return
values, and set the output buffer length to a false, too large value. This
causes the acpi-ca code to assume that the output buffer is larger than it
actually is, and overwrite memory when copying acpi return buffers into
this caller provided buffer. In some cases this can cause kernel oops if
the memory that is overwritten is a pointer. This patch will change these
calls to use a dynamically allocated output buffer, thus allowing the
acpi-ca code to decide how much space is needed.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Cc: "Brown, Len" <len.brown@intel.com>
Cc: "Yu, Luming" <luming.yu@intel.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Do not enable the SMBus device on Asus boards if suspend is used. We do
not reenable the device on resume, leading to all sorts of undesirable
effects, the worst being a total fan failure after resume on Samsung P35
laptop.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Signed-off-by: Pavel Machek <pavel@suse.cz>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
An earlier commit (75cf7456dd) changed an
overly-zealous PCI quirk to only poke those VIA devices that need it.
However, some PCI devices were not included in what I hope is now the full
list. Consequently we're failing to run the quirk on all machines which need
it, causing IRQ routing failures.
This should I hope correct this.
Thanks to Masoud Sharbiani <masouds@masoud.ir> for pointing this out
and testing the fix.
Signed-off-by: Chris Wedgwood <cw@f00f.org>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alan Cox pointed out that the VIA 'IRQ fixup' was erroneously running
on my system which has no VIA southbridge (but I do have a VIA IEEE
1394 device).
This should address that. I also changed "Via IRQ" to "VIA IRQ"
(initially I read Via as a capitalized via (by way/means of).
Signed-off-by: Chris Wedgwood <cw@f00f.org>
Acked-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The coverity checker spotted (as entry #599) that we might leak `entry' in
drivers/pci/msi.c::msix_capability_init()
This patch should take care of that.
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
On the MSI-K8T-NEO2 FIR ( Athlon-64, Socket 939 with VIA-K8T800- Chipset
and onboard Sound,... ) the BIOS lets you choose "DISABLED" or "AUTO" for
the On-Board Sound Device.
If you add another PCI-Sound-Card the BIOS disables the on-board device.
So far I have a Quirk, that does set the correspondent BIT in the
PCI-registers to enable the soundcard.
But how to ensure that the code is executed ONLY on excactly this kind of
boards (not any other with similar Chipset)?
Cc: Jaroslav Kysela <perex@suse.cz>
Acked-by: Takashi Iwai <tiwai@suse.de>
Cc: Lee Revell <rlrevell@joe-job.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6: (169 commits)
commit 78a596b449
Author: Adrian Bunk <bunk@stusta.de>
Date: Fri Mar 31 01:38:12 2006 -0800
[PATCH] remove kernel/power/pm.c:pm_unregister()
Since the last user is removed in -mm, we can now remove this long deprecated
function.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Cc: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 21440d3133
Author: David Brownell <david-b@pacbell.net>
Date: Sat Apr 1 10:21:52 2006 -0800
[PATCH] dma doc updates
...
The Asus A6VA notebook was reported to need a PCI quirk to unhide
the SMBus.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The init function for the RPA PCI Hotplug driver returns -ENODEV in the
case that no hotplug-capable slots are detected in the system. This is
bad, since hot-capable slots can be added after boot to a purely virtual
POWER partition. This is also bad because DLPAR I/O operations depend
on the rpaphp module.
Change the rpaphp init module to return success for the case of
partitions that own no hotplug-capable slots at boot. Such slots can be
dynamically added after boot.
Signed-off-by: John Rose <johnrose@austin.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The naming of the constant defined for PCI ID 1022:7450 does not seem
to match the information at http://pciids.sourceforge.net/:
http://pci-ids.ucw.cz/iii/?i=1022
There 1022:7450 is listed as "AMD-8131 PCI-X Bridge" while 1022:7451
is listed as "AMD-8131 PCI-X IOAPIC". Yet, the current definition for
0x7450 is PCI_DEVICE_ID_AMD_8131_APIC. It seems to me like that name
should map to 0x7451, while a name like PCI_DEVICE_ID_AMD_8131_BRIDGE
should map to 0x7450.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Print more diagnostic info to help identify the source of power management
suspend failures.
Example:
usb_hcd_pci_suspend(): pci_set_power_state+0x0/0x1af() returns -22
pci_device_suspend(): usb_hcd_pci_suspend+0x0/0x11b() returns -22
suspend_device(): pci_device_suspend+0x0/0x34() returns -22
Work-in-progress. It needs lots more suspend_report_result() calls sprinkled
everywhere.
Cc: Patrick Mochel <mochel@digitalimplant.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Nigel Cunningham <nigel@suspend2.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Semaphore to mutex conversion.
The conversion was generated via scripts, and the result was validated
automatically via a script as well.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Dave Jones <davej@codemonkey.org.uk>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Jens Axboe <axboe@suse.de>
Cc: Neil Brown <neilb@cse.unsw.edu.au>
Acked-by: Alasdair G Kergon <agk@redhat.com>
Cc: Greg KH <greg@kroah.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Adam Belay <ambx1@neo.rr.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I encountered the problem that the insmod of the acpiphp
fails because of the mis-freeing of the memory.
I tested this patch on my tiger4 box.
Signed-off-by: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch removes the defines TRUE and FALSE and just uses 0 or 1.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
shpchprm_acpi.c and pciehprm_acpi.c are nearly identical. In addition,
there are functions in both these files that are also in acpiphp_glue.c.
This patch will remove duplicate functions from shpchp, pciehp, and
acpiphp and move this functionality to pci_hotplug, as it is not
hardware specific. Get rid of shpchprm* and pciehprm* files since they
are no longer needed. shpchprm_nonacpi.c and pciehprm_nonacpi.c are
identical, as well as shpchprm_legacy.c and can be replaced with a
macro.
This patch also changes acpiphp to use the common hpp code.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
this patch converts drivers/pci to kzalloc usage.
Compile tested with allyes config.
Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Current ACPIPHP driver scans only slots under the top level PCI-to-PCI
bridge. So hotplug PCI slots under the nested PCI-to-PCI bridge would
not be detected. For example, if the system has the ACPI namespace
like below, hotplug slots woule not be detected.
Device (PCI0) { /* Root bridge */
Name (_HID, "PNP0A03")
Device (P2PA) { /* PCI-to-PCI bridge */
Name (_ADR, ...)
Device (P2PB) { /* PCI-to-PCI bridge */
Name (_ADR, ...)
Device (S0F0) { /* hotplug slot */
Name (_ADR, ...)
Name (_SUN, ...)
Method (_EJ0, ...) { ... }
}
...
Device (S0F7) { /* hotplug slot */
Name (_ADR, ...)
Name (_SUN, ...)
Method (_EJ0, ...) { ... }
}
Device (S1F0) { /* hotplug slot */
Name (_ADR, ...)
Name (_SUN, ...)
Method (_EJ0, ...) { ... }
}
...
}
}
}
This patch fixes this issue.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When doing a hotplug removal of a PPB, sn_bus_store_sysdata()
needs to be called for the PPB and all of its children.
Acked-by: Prarit Bhargava <prarit@sgi.com>
Signed-off-by: John Keller <jpk@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The code related to handling bus speed in SHPCHP driver is
unnecessarily complex. This patch cleans up and simplify that.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
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>
This patch contains the scheduled removal of PCI_LEGACY_PROC.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The Coverity checker correctly noted, that in function board_replaced in
drivers/pci/hotplug/cpqphp_ctrl.c, the variable src always has the
value 8, and therefore much code after the
...
if (rc || src) {
...
if (rc)
return rc;
else
return 1;
}
...
can never be called.
This patch removes the unreachable code in this function fixing kernel
Bugzilla #6073.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When hotplug slot is under the host bridge,
DEVICE_ACPI_HANDLE(&bus->self->dev) fails since '&bus->self' was not set.
This patch fixes it.
This patch is based on kristen's latest patches.
I tested this patch on my Tiger4.
Signed-off-by: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
o This patch removes IDs (for slots management).
o This patch removes the slot register/unregister processes
from the init/exit phases. Instead, adds these processes
in the bridge add/cleanup phases.
o Currently, this change doesn't have any meanings. But
these changes are needed to support p2p bridge(with
hotplug slot)
Signed-off-by: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
These patches add generic dock event handling to acpiphp. If there are
pci devices that need to be inserted/removed after the dock event, the
event notification will be handed down to the normal pci hotplug event
handler in acpiphp so that new bridges/devices can be enumerated.
Because some dock stations do not have pci bridges or pci devices that
need to be inserted after a dock, acpiphp will remain loaded to handle
dock events even if no hotpluggable pci slots are discovered.
You probably need to have the pci=assign-busses kernel parameter enabled
to use these patches, and you may not allow ibm_acpi to handle docking
notifications and use this patch.
This patch incorporates feedback provided by many.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If we add a new bridge with subordinate busses, we should call make sure
that acpi is notified so that the PRT (if present) can be read and drivers
who have registered on this bus will be notified when it is started.
Also make sure to use the max reserved bus number for the starting the bus
scan.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as659) fixes a might_sleep problem in the PCI core, by moving
a call to pci_dev_put() outside the scope of a spinlock.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
"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: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Use "unsigned long" when dealing with PCI resources.
The BAR Indicator Register (BIR) can be a 64-bit value
or the resource could be a 64-bit host physical address.
Enables ib_mthca and cciss drivers to use MSI-X on ia64 HW.
Problem showed up now because of new system firmware on one platform.
Symptom will either be memory corruption or MCA.
Second part of this patch deals with "useless" code.
We walk through the steps to find the phys_addr and then
don't use the result. I suspect the intent was to zero
out the respective MSI-X entry but I'm not sure at the moment.
Delete the code inside the #if 0/#endif if it's really
not needed.
Signed-off-by: Grant Grundler <iod00d@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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: Michael S. Tsirkin <mst@mellanox.co.il>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
On ASUS A8V and A8V Deluxe boards, the onboard AC97 audio controller
and MC97 modem controller are deactivated when a second PCI soundcard
is present. This patch enables them.
Signed-off-by: Bauke Jan Douma <bjdouma@xs4all.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
I attach a trivial patch for 2.6.15.4 that unhides SMBus controller
on an HP Compaq nx6110 notebook.
Signed-off-by: Tomasz Koprowski <tomek@koprowski.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The extra compatability code is not necessary. Any code still using
the old shutdown method will trigger the warning in driver_register()
instead.
Signed-off-by: Brian Gerst <bgerst@didntduck.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Current SHPCHP driver doesn't care about the confliction between
hotplug operation via sysfs and hotplug operation via attention
button. So if those ware conflicted, slot could be an unexpected
state.
This patch changes SHPCHP driver to handle slot state properly. With
this patch, slot events are handled according to the current slot
state as shown at the Table below.
Table. Slot States and Event Handling
=========================================================================
Slot State Event and Action
=========================================================================
STATIC - Go to POWERON state if user initiates
(Slot enabled, insertion request via sysfs
Slot disabled) - Go to POWEROFF state if user initiates removal
request via sysfs
- Go to BLINKINGON state if user presses
attention button when the slot is disabled
- Go to BLINKINGOFF state if user presses
attention button when the slot is enabled
The event handler of SHPCHP driver is unnecessarily very complex. In
addition, current event handler can only a fixed number of events at
the same time, and some of events would be lost if several number of
events happened at the same time.
This patch simplify the event handler by using 'work queue', and it
also fix the above-mentioned issue.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
