Currently, there is no minimum number of fields required when adding
a new device ID to a PCI driver through the new_id sysfs file. It is
possible to add a new ID with only the vendor ID set, causing the
driver to attempt to attach to all PCI devices from that vendor. This
has been reported to happen accidentally:
http://lists.lm-sensors.org/pipermail/lm-sensors/2007-March/019366.html
It is even possible to not even set the vendor ID field, causing the
driver to attempt to attach to _all_ the PCI devices.
This sounds dangerous and I fail to see any valid use of this
"feature". Thus I suggest that we now require at least the first two
fields (vendor ID and device ID) to be set. For what it's worth, this
is what the USB subsystem does.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
At one time, if a BIOS ROM shadow was detected for the boot video
device (stored at offset 0xc0000), we'd set a special resource flag,
IORESOURCE_ROM_SHADOW, so that the sysfs ROM file code could handle
it properly. That broke along the way somewhere though, so current
kernels will be missing 'rom' files in sysfs if the video device
doesn't have an explicit ROM BAR.
This patch fixes the regression by moving the video fixup quirk to a
little later in the boot cycle (to avoid having its work undone by
PCI resource allocation) and checking in the PCI sysfs code whether
a rom file should be created due to a shadow resource, which is also
moved to a little later in the boot cycle so it will occur after the
video fixup. Tested and works on my i386 test box.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Warning(linux-2621-rc3g7/drivers/pci/pci.c:1283): No description found for parameter 'dev'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The event handler of PCIEHP 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 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>
Adds a new API which can be used to issue various types
of PCI-E reset, including PCI-E warm reset and PCI-E hot reset.
This is needed for an ipr PCI-E adapter which does not properly
implement BIST. Running BIST on this adapter results in PCI-E
errors. The only reliable reset mechanism that exists on this
hardware is PCI Fundamental reset (warm reset). Since driving
this type of reset is architecture unique, this provides the
necessary hooks for architectures to add this support.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Acked-by: Linas Vepstas <linas@austin.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes a kernel bug which is triggered when using the
irqbalance daemon with MSI-X hardware.
Because both MSI-X interrupt messages and MSI-X table writes are posted,
it's possible for them to cross while in-flight. This results in
interrupts being received long after the kernel thinks they're disabled,
and in interrupts being sent to stale vectors after rebalancing.
This patch performs a read flush after writes to the MSI-X table for
mask and unmask operations. Since the SMP affinity is set while
the interrupt is masked, and since it's unmasked immediately after,
no additional flushes are required in the various affinity setting
routines.
This patch has been validated with (unreleased) network hardware which
uses MSI-X.
Revised with input from Eric Biederman.
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We need to work on cleaning up the relationship between kobjects, ksets and
ktypes. The removal of 'struct subsystem' is the first step of this,
especially as it is not really needed at all.
Thanks to Kay for fixing the bugs in this patch.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
These are all the remaining instances of get_property. Simple rename of
get_property to of_get_property.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
* 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev: (86 commits)
SPIN_LOCK_UNLOCKED cleanup in drivers/ata/pata_winbond.c
drivers/ata/pata_cmd640.c: fix build with CONFIG_PM=n
pata_hpt37x: Further small fixes
pata_hpt3x2n: Add HPT371N support and other bits
ata: printk warning fixes
libata: separate ATA_EHI_DID_RESET into DID_SOFTRESET and DID_HARDRESET
ahci: consolidate common port flags
ata_timing: ensure t->cycle is always correct
libata: add missing call to ->cable_detect() in new EH path
pata_amd: remove contamination added during cable_detect conversion
libata: Handle drives that require a spin-up command before first access
libata: HPA support
libata: kill probe_ent and related helpers
libata: convert the remaining PATA drivers to new init model
libata: convert the remaining SATA drivers to new init model
libata: convert ata_pci_init_native_mode() users to new init model
libata: convert drivers with combined SATA/PATA ports to new init model
libata: add init helpers including ata_pci_prepare_native_host()
libata: convert native PCI host handling to new init model
libata: convert legacy PCI host handling to new init model
...
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (105 commits)
sonypi: use mutex instead of semaphore
sony-laptop: remove user visible camera controls as platform attributes
meye: make meye use sony-laptop instead of sonypi
sony-laptop: add a meye-usable include file for camera ops
sony-laptop: complete the motion eye camera support in sony-laptop
sonypi: try to detect if sony-laptop has already taken one of the known ioports
sonypi: suggest sonypi users to try sony-laptop instead
sony-laptop: add edge modem support (also called WWAN)
sony-laptop: add locking on accesses to the ioport and global vars
sony-laptop: add camera enable/disable parameter, better handle possible infinite loop
thinkpad-acpi: make drivers/misc/thinkpad_acpi:fan_mutex static
ACPI: thinkpad-acpi: add sysfs support to wan and bluetooth subdrivers
ACPI: thinkpad-acpi: add sysfs support to hotkey subdriver
ACPI: thinkpad-acpi: improve dock subdriver initialization
ACPI: thinkpad-acpi: improve debugging for acpi helpers
ACPI: thinkpad-acpi: improve fan control documentation
ACPI: thinkpad-acpi: map ENXIO to EINVAL for fan sysfs
ACPI: thinkpad-acpi: fix a fan watchdog invocation
ACPI: thinkpad-acpi: do not arm fan watchdog if it would not work
ACPI: thinkpad-acpi: add a fan-control feature master toggle
...
Both old-IDE and libata should be able handle all controllers and
devices found using normal resource reservation methods.
This eliminates the awful, low-performing split-driver configuration
where old-IDE drove the PATA portion of a PCI device, in PIO-only mode,
and libata drove the SATA portion of the /same/ PCI device, in DMA mode.
Typically vendors would ship SATA hard drive / PATA optical
configuration, which would lend itself to slow (PIO-only) CD-ROM
performance.
For Intel users running in combined mode, it is now wholly dependent on
your driver choice (potentially link order, if you compile both drivers
in) whether old-IDE or libata will drive your hardware.
In either case, you will get full performance from both SATA and PATA
ports now, without having to pass a kernel command line parameter.
Signed-off-by: Jeff Garzik <jeff@garzik.org>
This defines a platform hook to enable/disable a device as a wakeup event
source. It's initially for use with ACPI, but more generally it could be used
whenever enable_irq_wake()/disable_irq_wake() don't suffice.
The hook is called -- if available -- inside pci_enable_wake(); and the
semantics of that call are enhanced so that support for PCI PME# is no longer
needed. It can now work for devices with "legacy PCI PM", when platform
support allows it. (That support would use some board-specific signal for for
the same purpose as PME#.)
[akpm@linux-foundation.org: Make it compile with CONFIG_PM=n]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Make multithreaded probing work per subsystem instead of per driver.
It doesn't make much sense to probe the same device for multiple drivers in
parallel (after all, only one driver can bind to the device). Instead, create
a probing thread for each device that probes the drivers one after another.
Also make the decision to use multi-threaded probe per bus instead of per
device and adapt the pci code.
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The ACPI spec defines the bit and Microsoft uses it,
so Linux must use it too.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This is a simplified and actually more comprehensive form of a bug
fix from Mitch Williams <mitch.a.williams@intel.com>.
When we mask or unmask a msi-x irqs the writes may be posted because
we are writing to memory mapped region. This means the mask and
unmask don't happen immediately but at some unspecified time in the
future. Which is out of sync with how the mask/unmask logic work
for ioapic irqs.
The practical result is that we get very subtle and hard to track down
irq migration bugs.
This patch performs a read flush after writes to the MSI-X table for mask
and unmask operations. Since the SMP affinity is set while the interrupt
is masked, and since it's unmasked immediately after, no additional flushes
are required in the various affinity setting routines.
The testing by Mitch Williams on his especially problematic system should
still be valid as I have only simplified the code, not changed the
functionality.
We currently have 7 drivers: cciss, mthca, cxgb3, forceth, s2io,
pcie/portdrv_core, and qla2xxx in 2.6.21 that are affected by this
problem when the hardware they driver is plugged into the right slot.
Given the difficulty of reproducing this bug and tracing it down to
anything that even remotely resembles a cause, even if people are
being affected we aren't likely to see many meaningful bug reports, and
the people who see this bug aren't likely to be able to reproduce this
bug in a timely fashion. So it is best to get this problem fixed
as soon as we can so people don't have problems.
Then if people do have a kernel message stating "No irq for vector" we
will know it is yet another novel cause that needs a complete new
investigation.
Cc: Greg KH <greg@kroah.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Acked-by: Mitch Williams <mitch.a.williams@intel.com>
Acked-by: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
PCIE error output should conform to vendor_id:device_id.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
It was found that the Toshiba laptops with hidden Intel SMBus have SMM
code handling the thermal management which accesses the SMBus. Thus it
is not safe to unhide it and let Linux access it. We have to leave the
SMBus hidden. SMM is a pain, really.
This fixes bugs #6315 and #6395, for good this time.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Because we do not reserve space for the pci-x and pci-e state in struct
pci dev we need to dynamically allocate it. However because we need
to support restore being called multiple times after a single save
it is never safe to free the buffers we have allocated to hold the
state.
So this patch modifies the save routines to first check to see
if we have already allocated a state buffer before allocating
a new one. Then the restore routines are modified to not free
the state after restoring it. Simple and it fixes some subtle
error path handling bugs, that are hard to test for.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Acked-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There are two ways pci_save_state and pci_restore_state are used. As
helper functions during suspend/resume, and as helper functions around
a hardware reset event. When used as helper functions around a hardware
reset event there is no reason to believe the calls will be paired, nor
is there a good reason to believe that if we restore the msi state from
before the reset that it will match the current msi state. Since arch
code may change the msi message without going through the driver, drivers
currently do not have enough information to even know when to call
pci_save_state to ensure they will have msi state in sync with the other
kernel irq reception data structures.
It turns out the solution is straight forward, cache the state in the
existing msi data structures (not the magic pci saved things) and
have the msi code update the cached state each time we write to the hardware.
This means we never need to read the hardware to figure out what the hardware
state should be.
By modifying the caching in this manner we get to remove our save_state
routines and only need to provide restore_state routines.
The only fields that were at all tricky to regenerate were the msi and msi-x
control registers and the way we regenerate them currently is a bit dependent
upon assumptions on how we use the allow msi registers to be configured and used
making the code a little bit brittle. If we ever change what cases we allow
or how we configure the msi bits we can address the fragility then.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Acked-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
drivers/pci/search.c caused following section mismatch warning
(if compiled with CONFIG_HOTPLUG=n):
WARNING: drivers/pci/built-in.o - Section mismatch: reference to .init.text: from .text.pci_find_bus after 'pci_find_bus' (at offset 0x24)
This was due to pci_find_bus() calling a function marked __devinit.
Fix was to remove the __devinit from the offending function.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fix following section mismatch warning (when compiled with CONFIG_HOTPLUG=n):
WARNING: drivers/pci/built-in.o - Section mismatch: reference to .init.text:aer_probe from .data between 'aerdrv' (at offset 0x1608) and 'aer_error_handlers'
Warning was fixed by renaming aerdrv to aerdriver so we pass the whitelist.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fix following section mismatch warning (when compiled with CONFIG_HOTPLUG=n):
WARNING: drivers/pci/built-in.o - Section mismatch: reference to .init.text:pcie_portdrv_probe from .data between 'pcie_portdrv' (at offset 0xe40) and 'pcie_portdrv_err_handler'
This warning was fixed by renaming pcie_portdrv to pcie_portdriver so we pass
the whitelist.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sanity check in pcim_pin_device() was too restrictive in that it didn't
allow multiple calls to the function, which is against the devres
philosohpy of fire-and-forget. Track pinned status separately and allow
pinning multiple times.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
For devices that do not support msi-x we only support 1 interrupt. Therefore
we can disable that one interrupt by disabling the msi capability itself. If
we leave the intx interrupts disabled while we have the msi capability
disabled no interrupts should be delivered from that device.
Devices with just the minimal msi support (and thus hitting this code path)
include things like the intel e1000 nic, so it looks like is going to be a
fairly common case and thus important to get right.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Michael Ellerman <michael@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
enable/disable_msi_mode have several side effects which keeps them from being
generally useful. So this patch replaces them with with two much more
targeted functions: msi_set_enable and msix_set_enable.
This patch makes pci_dev->msi_enabled and pci_dev->msix_enabled the definitive
way to test if linux has enabled the msi capability, and has the appropriate
msi data structures set up.
This patch ensures that while writing the msi messages in save/restore and
during device initialization we have the msi capability disabled so we don't
get into races. The pci spec requires that we do not have the msi capability
enabled and the msi messages unmasked while we write the messages. Completely
disabling the capability is overkill but it is easy :)
Care has been taken so we never have both a msi capability and intx enabled
simultaneously. We haven't run into a problem yet but better safe then sorry.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Michael Ellerman <michael@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In some cases when we are not using msi we need a way to ensure that the
hardware does not have an msi capability enabled. Currently the code has been
calling disable_msi_mode to try and achieve that. However disable_msi_mode
has several other side effects and is only available when msi support is
compiled in so it isn't really appropriate.
Instead this patch implements pci_msi_off which disables all msi and msix
capabilities unconditionally with no additional side effects.
pci_disable_device was redundantly clearing the bus master enable flag and
clearing the msi enable bit. A device that is not allowed to perform bus
mastering operations cannot generate intx or msi interrupt messages as those
are essentially a special case of dma, and require bus mastering. So the call
in pci_disable_device to disable msi capabilities was redundant.
quirk_pcie_pxh also called disable_msi_mode and is updated to use pci_msi_off.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Michael Ellerman <michael@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The change to force legacy mode IDE channels' resources to fixed non-zero
values confuses (at least some versions of) X, because the values reported
by the kernel and those readable from PCI config space aren't consistent
anymore. Therefore, this patch arranges for the respective BARs to also
get updated if possible.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Acked-by: Alan Cox <alan@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Make jmiron_ata quirk update pdev->class after programming the device
and update ahci and pata_jmicron such that they match class code
instead of checking function number manually. For ahci, it matches
for vendor and class. For pata_jmicron, it matches vendor, device and
class as IDE class isn't as well defined as AHCI class.
This makes jmicron device matching more conventional and script
friendly.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Reimplement jmicron ATA quirk.
* renamed to quirk_jmicron_ata()
* quirk is invoked only for the affected controllers
* programming is stricter. e.g. conf5 bit24 is cleared if
unnecessary.
* code factored for readability
* JMB360 and JMB368 are programmed into proper mode
Verified on JMB360, 363 and 368.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
* git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivial: (25 commits)
Documentation/kernel-docs.txt update.
arch/cris: typo in KERN_INFO
Storage class should be before const qualifier
kernel/printk.c: comment fix
update I/O sched Kconfig help texts - CFQ is now default, not AS.
Remove duplicate listing of Cris arch from README
kbuild: more doc. cleanups
doc: make doc. for maxcpus= more visible
drivers/net/eexpress.c: remove duplicate comment
add a help text for BLK_DEV_GENERIC
correct a dead URL in the IP_MULTICAST help text
fix the BAYCOM_SER_HDX help text
fix SCSI_SCAN_ASYNC help text
trivial documentation patch for platform.txt
Fix typos concerning hierarchy
Fix comment typo "spin_lock_irqrestore".
Fix misspellings of "agressive".
drivers/scsi/a100u2w.c: trivial typo patch
Correct trivial typo in log2.h.
Remove useless FIND_FIRST_BIT() macro from cardbus.c.
...
Export the numa-node attribute of PCI devices in sysfs so that
user applications may choose where to be placed accordingly.
Signed-off-by: Brice Goglin <Brice.Goglin@ens-lyon.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
I'm currently working on a port to a CPCI board with a MPC5200. When
testing the PCI interrupt routing, I discovered the following: Even devices
which don't use interrupts (-> PCI Spec.: Interrupt Pin Register is zero),
get an interrupt assigned (this is at least true for most of the
PPC-targets I looked at).
The cause is pretty obvious in drivers/pci/setup-irq.c. I guess at least
in an ideal world with correctly designed hardware, the code should rather
look as in the patch below.
Of course it doesn't hurt anybody to have an unuseable IRQ assigned to a
PCI-to-PCI-bridge (or something alike), but to me it seems a bit strange.
Please correct me, if I'm mislead.
The patch below is tested on the above mentioned CPCI-MPC5200 board and is
compiler tested with the latest git-repository kernel on x86.
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
CARDBUS_MEM_SIZE was increased to 64MB on 2.6.20-rc2, but larger size might
result in allocation failure for the reserving itself on some platforms
(for example typical 32bit MIPS). Make it (and CARDBUS_IO_SIZE too)
customizable by "pci=" option for such platforms.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: Daniel Ritz <daniel.ritz@gmx.ch>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
After Al Viro (finally) succeeded in removing the sched.h #include in module.h
recently, it makes sense again to remove other superfluous sched.h includes.
There are quite a lot of files which include it but don't actually need
anything defined in there. Presumably these includes were once needed for
macros that used to live in sched.h, but moved to other header files in the
course of cleaning it up.
To ease the pain, this time I did not fiddle with any header files and only
removed #includes from .c-files, which tend to cause less trouble.
Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
configs in arch/arm/configs on arm. I also checked that no new warnings were
introduced by the patch (actually, some warnings are removed that were emitted
by unnecessarily included header files).
Signed-off-by: Tim Schmielau <tim@physik3.uni-rostock.de>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Many struct file_operations in the kernel can be "const". Marking them const
moves these to the .rodata section, which avoids false sharing with potential
dirty data. In addition it'll catch accidental writes at compile time to
these shared resources.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is kind of hokey, we could use the hardware provided facilities
much better.
MSIs are assosciated with MSI Queues. MSI Queues generate interrupts
when any MSI assosciated with it is signalled. This suggests a
two-tiered IRQ dispatch scheme:
MSI Queue interrupt --> queue interrupt handler
MSI dispatch --> driver interrupt handler
But we just get one-level under Linux currently. What I'd like to do
is possibly stick the IRQ actions into a per-MSI-Queue data structure,
and dispatch them form there, but the generic IRQ layer doesn't
provide a way to do that right now.
So, the current kludge is to "ACK" the interrupt by processing the
MSI Queue data structures and ACK'ing them, then we run the actual
handler like normal.
We are wasting a lot of useful information, for example the MSI data
and address are provided with ever MSI, as well as a system tick if
available. If we could pass this into the IRQ handler it could help
with certain things, in particular for PCI-Express error messages.
The MSI entries on sparc64 also tell you exactly which bus/device/fn
sent the MSI, which would be great for error handling when no
registered IRQ handler can service the interrupt.
We override the disable/enable IRQ chip methods in sun4v_msi, so we
have to call {mask,unmask}_msi_irq() directly from there. This is
another ugly wart.
Signed-off-by: David S. Miller <davem@davemloft.net>
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6: (28 commits)
sysfs: Shadow directory support
Driver Core: Increase the default timeout value of the firmware subsystem
Driver core: allow to delay the uevent at device creation time
Driver core: add device_type to struct device
Driver core: add uevent vars for devices of a class
SYSFS: Fix missing include of list.h in sysfs.h
HOWTO: Add a reference to Harbison and Steele
sysfs: error handling in sysfs, fill_read_buffer()
kobject: kobject_put cleanup
sysfs: kobject_put cleanup
sysfs: suppress lockdep warnings
Driver core: fix race in sysfs between sysfs_remove_file() and read()/write()
driver core: Change function call order in device_bind_driver().
driver core: Don't stop probing on ->probe errors.
driver core fixes: device_register() retval check in platform.c
driver core fixes: make_class_name() retval checks
/sys/modules/*/holders
USB: add the sysfs driver name to all modules
SERIO: add the sysfs driver name to all modules
PCI: add the sysfs driver name to all modules
...
The arch hooks arch_setup_msi_irq and arch_teardown_msi_irq are now
responsible for allocating and freeing the linux irq in addition to
setting up the the linux irq to work with the interrupt.
arch_setup_msi_irq now takes a pci_device and a msi_desc and returns
an irq.
With this change in place this code should be useable by all platforms
except those that won't let the OS touch the hardware like ppc RTAS.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We need to be able to get from an irq number to a struct msi_desc.
The msi_desc array in msi.c had several short comings the big one was
that it could not be used outside of msi.c. Using irq_data in struct
irq_desc almost worked except on some architectures irq_data needs to
be used for something else.
So this patch adds a msi_desc pointer to irq_desc, adds the appropriate
wrappers and changes all of the msi code to use them.
The dynamic_irq_init/cleanup code was tweaked to ensure the new
field is left in a well defined state.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The attach_msi_entry has been reduced to a single simple assignment,
so for simplicity remove the abstraction and directory perform the
assignment.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Since msi_remove_pci_irq_vectors is designed to be called during
hotplug remove it is actively wrong to query the hardware and expect
meaningful results back.
To that end remove the pci_find_capability calls. Testing
dev->msi_enabled and dev->msix_enabled gives us all of the information
we need.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
With the removal of msi_lookup_irq all of the functions using msi_lock
operated on a single device and none of them could reasonably be
called on that device at the same time.
Since what little synchronization that needs to happen needs to happen
outside of the msi functions, msi_lock could never be contended and as
such is useless and just complicates the code.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The function msi_lookup_irq was horrible. As a side effect of running
it changed dev->irq, and then the callers would need to change it
back. In addition it does a global scan through all of the irqs,
which seems to be the sole justification of the msi_lock.
To remove the neede for msi_lookup_irq I added first_msi_irq to struct
pci_dev. Then depending on the context I replaced msi_lookup_irq with
dev->first_msi_irq, dev->msi_enabled, or dev->msix_enabled.
msi_enabled and msix_enabled were already present in pci_dev for other
reasons.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The PCI save/restore code doesn't need to care about MSI vs MSI-X, all
it really wants is to say "save/restore all MSI(-X) info for this device".
This is borne out in the code, we call the MSI and MSI-X save routines
side by side, and similarly with the restore routines.
So combine the MSI/MSI-X routines into pci_save_msi_state() and
pci_restore_msi_state(). It is up to those routines to decide what state
needs to be saved.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
pci_scan_msi_device() doesn't do anything anymore, so remove it.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
I don't see any reason why we need pci_msi_quirk, quirk code can just
call pci_no_msi() instead.
Remove the check of pci_msi_quirk in msi_init(). This is safe as all
calls to msi_init() are protected by calls to pci_msi_supported(),
which checks pci_msi_enable, which is disabled by pci_no_msi().
The pci_disable_msi routines didn't check pci_msi_quirk, only
pci_msi_enable, but as far as I can see that was a bug not a feature.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Return early from pci_set_power_state() if hardware does not support
power management. This way, we do not generate noise in the logs.
Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Cleanup MSI code as follows:
- fix some types
- fix strange local variable definition
- delete unnecessary blank line
- add comment to #endif which is far from corresponding #ifdef
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Since isa_bridge is neither assigned any value !NULL nor used on !Alpha,
there's no reason for providing it.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Since 2.6.0-test10, all quirk_sis_96x_compatible() had any effect on
was a printk().
This patch therefore removes it.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Mark M. Hoffman <mhoffman@lightlink.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Speed up the Intel SMBus PCI quirk by avoiding tests which can only
fail. This also makes the compiled code significantly smaller when
using gcc 3.2/3.4. gcc 4.x appears to optimize the code by itself so
this change doesn't make a difference there.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There's an existing quirk for the kernel to use 1k IO space granularity
on the Intel P64H2. It turns out however that pci_setup_bridge() in
drivers/pci/setup-bus.c reads in the IO base and limit address register
masks it off to the nearest 4k, and writes it back. This causes the
kernel to be on 1k boundaries and the hardware to be 4k aligned. The
patch below fixes the problem.
Signed-off-by: Dan Yeisley <dan.yeisley@unisys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch deletes trailing white space in SHPCHP driver. This has no
functional change.
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>
The CONFIG_HOTPLUG_PCI_SHPC_POLL_EVENT_MODE config option is not
needed because polling mechanism for shpc hotplug events can be
enabled through module option 'shpchp_poll_mode'. This patch removes
CONFIG_HOTPLUG_PCI_SHPC_POLL_EVENT_MODE.
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>
This patch fixes this problem that pciehp driver will sleep
unnecessarily long when waiting for command completion. With this
patch, modprobe pciehp driver becomes very faster as follows for
instance.
o Without this patch
# time /sbin/modprobe pciehp
real 0m4.976s
user 0m0.000s
sys 0m0.004s
o With this patch
# time /sbin/modprobe pciehp
real 0m0.640s
user 0m0.000s
sys 0m0.004s
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>
This patch cleans up the code to wait for command completion.
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>
This patch cleans up pciehp.h. This has no functional change.
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>
This patch cleans up register access functions. This has no functional
change.
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>
The struct php_ctlr seems to be only for complicating codes. This
patch removes struct php_ctlr and related codes.
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>
This patch cleans up slot list handling (use list_head). This has no
functional change.
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>
This patch cleans up init_slots() in pciehp_core.c based on
pcihp_skeleton.c. This has no functional change.
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>
This patch removes the no longer used pci_find_device_reverse().
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Alan Cox <alan@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch contains the following cleanups:
- move all EXPORT_SYMBOL's directly below the code they are exporting
- move all DECLARE_PCI_FIXUP_*'s directly below the functions they
are calling
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds the following changes into generic PCI code especially
for PCI legacy I/O port free drivers.
- Added new pci_request_selected_regions() and
pci_release_selected_regions() for PCI legacy I/O port free
drivers in order to request/release only the selected regions.
- Added helper routine pci_select_bars() which makes proper mask
of BARs from the specified resource type. This would be very
helpful for users of pci_enable_device_bars().
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Cc: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Original patch was posted as "PCI : Move pci_fixup_device and is_enabled".
This 1 of 3 patches does:
- reverts small part of Inaky's patch
(remove __pci_enable_device)
This change will be recovered by 3rd patch.
- temporarily remove pci_fixup_device.
This change will be recovered by 2nd patch.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Cc: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
For pci mem resource that size is bigger than 4G, the sz returned by
pc_size will be 0.
So that resource is skipped, and register contained hi address will be
treated as another 32bit resource. We need to use sz64 and pci_sz64 for
64 bit resource for clear logical. Typical usages for this: Opteron
system with co-processor and the co-processor could take more than 4G
RAM as pre-fetchable mem resource.
Signed-off-by: Yinghai Lu <yinghai.lu@amd.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This adds the module name to all PCI drivers, if they are built into the
kernel or not. It will show up in /sys/modules/MODULE_NAME/drivers/
It also fixes up the IDE core, which was calling __pci_register_driver()
directly.
Cc: Kay Sievers <kay.sievers@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This is the driver for the Toshiba TC86C001 GOKU-S PCI IDE controller,
completely reworked from the original brain-damaged Toshiba's 2.4 version.
This single channel UltraDMA/66 controller is very simple in programming,
yet Toshiba managed to plant many interesting bugs in it. The particularly
nasty "limitation 5" (as they call the errata) caused me to abuse the IDE
core in a possibly most interesting way so far. However, this is still
better than the #ifdef mess in drivers/ide/ide-io.c that the original
version included (well, it had much more mess)...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Acked-by: Alan Cox <alan@redhat.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Support for dynamic loading and unloading of ACPI SSDT tables upon slot
hotplugs and unplugs.
On SN platforms, we now represent every populated root bus slot with a single
ACPI SSDT table containing info for every device and PPB attached to the slot.
These SSDTs are generated by the prom at initial boot and hotplug time. The
info in these SSDT tables is used by the SN kernel IO "fixup" code (which is
called at boot and hotplug time).
On hotplugs (i.e. enable_slot()), if running with an ACPI capable prom,
attempt to obtain a new ACPI SSDT table for the slot being hotplugged. If
successful, add the table to the ACPI namespace (acpi_load_table()) and then
walk the new devices and add them to the ACPI infrastructure (acpi_bus_add()).
On hot unplugs (i.e. disable_slot()), if running with an ACPI capable prom,
attempt to remove the SSDT table associated with the slot from the ACPI
namespace (acpi_unload_table_id()) and infastructure (acpi_bus_trim()).
From: John Keller <jpk@sgi.com>
A bug was fixed where the sgi hotplug driver was removing
the slot's SSDT table from the ACPI namespace a bit too early in
disable_slot(). Also, we now call acpi_bus_start() subsequent
to acpi_bus_add().
Signed-off-by: Aaron Young <ayoung@sgi.com>
Cc: Greg KH <greg@kroah.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown<len.brown@intel.com>
For all JMicrons except for 361 and 368, AHCI mode enable bits in the
Control(1) should be set. This used to be done in both ahci and
pata_jmicron but while moving programming to PCI quirk, it was removed
from ahci part while still left in pata_jmicron.
The implemented JMicron PCI quirk was incorrect in that it didn't
program AHCI mode enable bits. If pata_jmicron is loaded first and
programs those bits, the ahci ports work; otherwise, ahci device
detection fails miserably.
This patch makes JMicron PCI quirk clear SATA IDE mode bits and set
AHCI mode bits and remove the respective part from pata_jmicron.
Tested on JMB361, 363 and 368.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Remove these recently-added warnings. They don't tell us anythng very
interesting and Kumar says "On an embedded PPC reference system I see this
message 6 times when I've got no cards in the PCI slots."
Acked-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add special handling for the VT82C686.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix VIA quirks that were recently broken by Alan Cox in the upstream
kernel (commit 1597cacbe3).
My understanding is that pci_find_present() doesn't work yet at the time
the quirks are run. So I used a two-step quirk as is done for some other
quirks already. First we detect the VIA south bridges and set the right
low and high device limits, then we are ready to actually run the quirks on
the affected devices.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Acked-by: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Function short description should be on only one line.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Unhide the SMBus on the Asus P4P800-X (and probably some other
models of the family.) This gives access to the memory module SPD
EEPROMs.
Thanks to Winbond for supporting the lm-sensors project with the
donation of this motherboard.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
While testing 2.6.20-rc3 on a machine with some CK804 chipsets, we noticed
that quirk_nvidia_ck804_msi_ht_cap() was not detecting HT MSI capabilities
anymore. It is actually caused by the MSI mapping on the root chipset
being the 2nd HT capability in the chain. pci_find_ht_capability() does
not seem to find anything but the first HT cap correctly, because it
forgets to increment the position before looking for the next cap. The
following patch seems to fix it.
At least, this proves that having a ttl is good idea since the machine
would have been stucked in an infinite loop if we didn't have a ttl :)
We have to pass pos + PCI_CAP_LIST_NEXT to __pci_find_next_cap_ttl to
get the next HT cap instead of the same one again.
Signed-off-by: Brice Goglin <brice@myri.com>
Signed-off-by: Andrew J. Gallatin <gallatin@myri.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
o MODPOST generates warnings for i386 if kernel is compiled with
CONFIG_RELOCATABLE=y
WARNING: vmlinux - Section mismatch: reference to .init.data: from .text between 'asus_hides_smbus_lpc_ich6' (at offset 0xc0217d58) and 'quirk_cardbus_legacy'
WARNING: vmlinux - Section mismatch: reference to .init.data: from .text between 'asus_hides_smbus_lpc' (at offset 0xc0217fd9) and 'pci_match_id'
o Two quirk functions which are non __init, are accessing data which is
of type __init.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Andi Kleen <ak@suse.de>
The sis96x SMBus PCI device depends on two different quirks to run
in a specific order. Apart from being fragile, this was found to
actually break on (at least) recent FC4, FC5, and FC6 kernels. This
patch fixes the quirks so that they work without relying on the
compiler and/or linker to put them in any specific order.
http://lists.lm-sensors.org/pipermail/lm-sensors/2006-April/015962.htmlhttps://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189719
I tested this patch.
Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
Cc: Andrew Morton <akpm@osdl.org>
Cc: Adrian Bunk <bunk@stusta.de>
Cc: Greg K-H <greg@kroah.com>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The pci_find_subsys gets called very early by obsolete ide setup parameters.
This is a bogus call since pci is not initialized yet, so the list is empty.
But in the mean time, interrupts get enabled by down_read. This can result in
a kernel panic when the irq controller gets initialized.
This patch checks if the device list is empty before taking the semaphore, and
hence will not enable irq's. Furthermore it will inform that it is called
while pci_devices is empty as a reminder that the ide code needs to be fixed.
The pci_get_subsys can get called in the same manner, and as such is patched
in the same manner.
[akpm@osdl.org: cleanups]
Signed-off-by: Ard van Breemen <ard@telegraafnet.nl>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Don't have macros between a function's kernel-doc block and the function
definition. This is not valid for kernel-doc.
Warning(/var/linsrc/linux-2.6.20-rc1-git8//drivers/pci/probe.c:653): No description found for parameter 'IORESOURCE_PCI_FIXED'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (68 commits)
ACPI: replace kmalloc+memset with kzalloc
ACPI: Add support for acpi_load_table/acpi_unload_table_id
fbdev: update after backlight argument change
ACPI: video: Add dev argument for backlight_device_register
ACPI: Implement acpi_video_get_next_level()
ACPI: Kconfig - depend on PM rather than selecting it
ACPI: fix NULL check in drivers/acpi/osl.c
ACPI: make drivers/acpi/ec.c:ec_ecdt static
ACPI: prevent processor module from loading on failures
ACPI: fix single linked list manipulation
ACPI: ibm_acpi: allow clean removal
ACPI: fix git automerge failure
ACPI: ibm_acpi: respond to workqueue update
ACPI: dock: add uevent to indicate change in device status
ACPI: ec: Lindent once again
ACPI: ec: Change #define to enums there possible.
ACPI: ec: Style changes.
ACPI: ec: Acquire Global Lock under EC mutex.
ACPI: ec: Drop udelay() from poll mode. Loop by reading status field instead.
ACPI: ec: Rename gpe_bit to gpe
...
Linus sayeth:
Google knows everything, and finds, on MS own site no less:
"Windows 2000 default resources:
One 4K memory window
One 2 MB memory window
Two 256-byte I/O windows"
which is clearly utterly bogus and insufficient. But Microsoft apparently
realized this, and:
"Windows XP default resources:
Because one memory window of 4K and one window of 2 MB are not
sufficient for CardBus controllers in many configurations, Windows XP
allocates larger memory windows to CardBus controllers where possible.
However, resource windows are static (that is, the operating system
does not dynamically allocate larger memory windows if new devices
appear.) Under Windows XP, CardBus controllers will be assigned the
following resources:
One 4K memory window, as in Windows 2000
64 MB memory, if that amount of memory is available. If 64 MB is not
available the controller will receive 32 MB; if 32 MB is not available,
the controller will receive 16 MB; if 16 MB is not available, the
bridge will receive 8 MB; and so on down to a minimum assignment of 1
MB in configurations where memory is too constrained for the operating
system to provide a larger window.
Two 256-byte I/O windows"
So I think we have our answer. Windows uses one 4k window, and one 64MB
window. And they are no more dynamic than we are (we _could_ try to do it
dynamically, but let's face it, it's fairly painful to dynamically expand
PCI bus resources - you may need to reprogram everything up to the root,
so it would be absolutely crazy to do that unless you have some serious
masochistic tendencies).
So let's just increase our default value to 64M too.
Cc: Markus Rechberger <mrechberger@gmail.com>
Cc: Daniel Ritz <daniel.ritz@gmx.ch>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I'm seeing:
`acpiphp_glue_exit' referenced in section `.init.text' of
drivers/built-in.o: defined in discarded section `.exit.text' of
drivers/built-in.o
when trying to compile an IA64 kernel with PCI hotplug enabled.
I suggest this patch:
Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The struct php_ctlr seems to be only for complicating codes. This
patch removes struct php_ctlr and related codes.
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>
Since commit 368c73d4f6 the kernel will try
to update the non-writeable BAR registers 0..3 of PIIX4 IDE adapters if
pci_assign_unassigned_resources() is used to do full resource assignment of
the bus. This fails because in the PIIX4 these BAR registers have
implicitly assumed values and read back as zero; it used to work because
the kernel used to just write zero to that register the read back value did
match what was written.
The fix is a new resource flag IORESOURCE_PCI_FIXED used to mark a resource
as non-movable. This will also be useful to keep other import system
resources from being moved around - for example system consoles on PCI
busses.
[akpm@osdl.org: cleanup]
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Acked-by: Alan Cox <alan@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
pci_get_slot() may return NULL if nothing was found. quirk_nvidia_ck804()
does not check the value returned from pci_get_slot(), so it may end up
causing a NULL pointer deref.
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Acked-by: Alan Cox <alan@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch is designed to fix:
- Disk eating corruptor on KT7 after resume from RAM
- VIA IRQ handling
- VIA fixups for bus lockups after resume from RAM
The core of this is to add a table of resume fixups run at resume time.
We need to do this for a variety of boards and features, but particularly
we need to do this to get various critical VIA fixups done on resume.
The second part of the problem is to handle VIA IRQ number rules which
are a bit odd and need special handling for PIC interrupts. Various
patches broke various boxes and while this one may not be perfect
(hopefully it is) it ensures the workaround is applied to the right
devices only.
From: Jean Delvare <khali@linux-fr.org>
Now that PCI quirks are replayed on software resume, we can safely
re-enable the Asus SMBus unhiding quirk even when software suspend support
is enabled.
[akpm@osdl.org: fix const warning]
Signed-off-by: Alan Cox <alan@redhat.com>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Use pci_find_ht_capability() in drivers/pci/quirks.c.
I'm pretty sure the logic is unchanged here, but someone please eye-ball it
for me. I've changed the message to be a little shorter, it's now:
PCI: Found (enabled|disabled) HT MSI mapping on xxxx:xx:xx.x
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Use pci_find_ht_capability() in drivers/pci/htirq.c
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There are already several places in the kernel that want to search a PCI
device for a given Hypertransport capability. Although this is possible
using pci_find_capability() etc., it makes sense to encapsulate that
logic in a helper - pci_find_ht_capability().
To cater for searching exhaustively for a capability, we also provide
pci_find_next_ht_capability().
We also need to cater for the fact that the HT capability fields may be
either 3 or 5 bits wide. pci_find_ht_capability() deals with this for you,
but callers using the #defines directly must handle that themselves.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The current implementation of __pci_bus_find_cap() does two things,
first it determines the start of the capability chain for the device,
and then it trys to find the requested capability.
Split these out, so that we can use the two parts independantly in
a subsequent patch. Externally visible behaviour should be unchanged.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This works like pci_dev_present but instead of returning boolean returns
the matching pci_device_id entry. This makes it much more useful. Code
bloat is basically nil as the old boolean function is rewritten in terms of
the new one.
This will be used by the updated VIA PCI quirks for one
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The following warning message should not be displayed for devices
which don't use an interrupt pin.
pcie_portdrv_probe->Dev[XXXX:XXXX] has invalid IRQ. Check vendor BIOS
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This janitorial patch removes the following annoying
compile-time message:
drivers/pci/hotplug/rpaphp_slot.c:57: warning: ignoring return
value of sfs_create_file declared with attribute warn_unused_result
It also fixes a typo, removes some misc crud.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Cc: John Rose <johnrose@us.ibm.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Removes redundant check for dev->subordinate; if it is NULL, the function
returns before the patch-affected code region.
Signed-off-by: David Rientjes <rientjes@cs.washington.edu>
Acked-by: Brice Goglin <brice@myri.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Unfortunately, the .../new_id feature does not work with the 8250_pci
driver.
The reason for this comes down to the way .../new_id is implemented.
When PCI tries to match a driver to a device, it checks the modules
static device ID tables _before_ checking the dynamic new_id tables.
When a driver is capable of matching by ID, and falls back to matching
by class (as 8250_pci does), this makes it absolutely impossible to
specify a board by ID, and as such the correct driver_data value to
use with it.
Let's say you have a serial board with vendor 0x1234 and device 0x5678.
It's class is set to PCI_CLASS_COMMUNICATION_SERIAL.
On boot, this card is matched to the 8250_pci driver, which tries to
probe it because it matched using the class entry. The driver finds
that it is unable to automatically detect the correct settings to use,
so it returns -ENODEV.
You know that the information the driver needs is to match this card
using a device_data value of '7'. So you echo 1234 5678 0 0 0 0 7
into new_id.
The kernel attempts to re-bind 8250_pci to this device. However,
because it scans the PCI driver tables, it _again_ matches the class
entry which has the wrong device_data. It fails.
End of story. You can't support the card without rebuilding the
kernel (or writing a specific PCI probe module to support it.)
So, can we make new_id override the driver-internal PCI ID tables?
IOW, like this:
From: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Run this:
#!/bin/sh
for f in $(grep -Erl "\([^\)]*\) *k[cmz]alloc" *) ; do
echo "De-casting $f..."
perl -pi -e "s/ ?= ?\([^\)]*\) *(k[cmz]alloc) *\(/ = \1\(/" $f
done
And then go through and reinstate those cases where code is casting pointers
to non-pointers.
And then drop a few hunks which conflicted with outstanding work.
Cc: Russell King <rmk@arm.linux.org.uk>, Ian Molton <spyro@f2s.com>
Cc: Mikael Starvik <starvik@axis.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Greg KH <greg@kroah.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Paul Fulghum <paulkf@microgate.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Karsten Keil <kkeil@suse.de>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: James Bottomley <James.Bottomley@steeleye.com>
Cc: Ian Kent <raven@themaw.net>
Cc: Steven French <sfrench@us.ibm.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Neil Brown <neilb@cse.unsw.edu.au>
Cc: Jaroslav Kysela <perex@suse.cz>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Refactor Kconfig content to maximize nesting of menus by menuconfig and
xconfig.
Tested by simultaneously running `make xconfig` with and without
patch, and comparing displays.
Signed-off-by: Don Mullis <dwm@meer.net>
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The current code (prior to this change) would disable the PCI INTx
legacy interrupt when enabling MSI... but only on PCI Express. We
should do this for all MSI devices, for safety's sake.
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Replace all uses of kmem_cache_t with struct kmem_cache.
The patch was generated using the following script:
#!/bin/sh
#
# Replace one string by another in all the kernel sources.
#
set -e
for file in `find * -name "*.c" -o -name "*.h"|xargs grep -l $1`; do
quilt add $file
sed -e "1,\$s/$1/$2/g" $file >/tmp/$$
mv /tmp/$$ $file
quilt refresh
done
The script was run like this
sh replace kmem_cache_t "struct kmem_cache"
Signed-off-by: Christoph Lameter <clameter@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
For node-aware skb allocations we need information about the node in struct
net_device or struct device. Davem suggested to put it into struct device
which this patch does.
In particular:
- struct device gets a new int numa_node member if CONFIG_NUMA is set
- there are two new helpers, dev_to_node and set_dev_node to
transparently deal with the non-numa case
- for pci devices the node-info is set to the value we get from
pcibus_to_node.
Note that for some architectures pcibus_to_node doesn't work yet at the time
we call it currently. This is harmless and will just mean skb allocations
aren't node-local on this architectures until the implementation of
pcibus_to_node on these architectures have been updated (There are patches for
x86 and x86_64 floating around)
[akpm@osdl.org: cleanup]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Cc: Christoph Lameter <clameter@engr.sgi.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Conflicts:
drivers/ata/libata-scsi.c
include/linux/libata.h
Futher merge of Linus's head and compilation fixups.
Signed-Off-By: David Howells <dhowells@redhat.com>
Conflicts:
drivers/infiniband/core/iwcm.c
drivers/net/chelsio/cxgb2.c
drivers/net/wireless/bcm43xx/bcm43xx_main.c
drivers/net/wireless/prism54/islpci_eth.c
drivers/usb/core/hub.h
drivers/usb/input/hid-core.c
net/core/netpoll.c
Fix up merge failures with Linus's head and fix new compilation failures.
Signed-Off-By: David Howells <dhowells@redhat.com>
The correct order is: NULL check before dereference
Spotted by the Coverity checker.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes the problem that "irq XX: nobody cared" kernel oops
is reported when pciehp is once rmmoded and insmoded again. The cause
of this problem is pciehp driver calls pci_disable_msi() at controller
release time, even though it must be done by PCI Express Port Bus
driver. This patch removes unnecessary pci_disable_msi() call from
pciehp driver.
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>
This patch fixes the problem that the following error messages is
reported when pciehp driver is rmmoded.
Trying to free already-free IRQ XX
The cause of this problem is that pciehp driver is doing unknown 2nd
free_irq at driver unloading. This patch removes this unknown 2nd
free_irq call.
Note: The pciehp driver should be adapted to standard device driver
mode.
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>
Change the criterion that RPA PCI Hotplug and RPA DLPAR use when
determining the hotplug capabilities of a given device node. The
"device_type" property is less consistent than "name" across PCI nodes
on newer hardware.
Signed-off-by: John Rose <johnrose@austin.ibm.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change memory allocation for acpiphp slots
Change the "struct slot" that acpiphp uses for managing it's slots to
directly contain the memory for the needed struct hotplug_slot_info and
the slot's name. This way we need only two memory allocations per slot
instead of four.
While we are at it: make_slot_name() is just a wrapper around snprintf()
knowing the right arguments to call it. Since the function makes just one
function call and is only called from one place I inlined it by hand.
Finally this fixes a possible bug waiting for someone to hit it. There were
two unused local variables in acpiphp_register_hotplug_slot(). gcc did not
find them because they were used in memory allocations with sizeof(*var).
They had the same types as the target of the allocation, but nevertheless
this was just weird.
Signed-off-by: Rolf Eike Beer <eike-hotplug@sf-tec.de>
Acked-by: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Changes the pci_{enable,disable}_device() functions to work in a
nested basis, so that eg, three calls to enable_device() require three
calls to disable_device().
The reason for this is to simplify PCI drivers for
multi-interface/capability devices. These are devices that cram more
than one interface in a single function. A relevant example of that is
the Wireless [USB] Host Controller Interface (similar to EHCI) [see
http://www.intel.com/technology/comms/wusb/whci.htm].
In these kind of devices, multiple interfaces are accessed through a
single bar and IRQ line. For that, the drivers map only the smallest
area of the bar to access their register banks and use shared IRQ
handlers.
However, because the order at which those drivers load cannot be known
ahead of time, the sequence in which the calls to pci_enable_device()
and pci_disable_device() cannot be predicted. Thus:
1. driverA starts pci_enable_device()
2. driverB starts pci_enable_device()
3. driverA shutdown pci_disable_device()
4. driverB shutdown pci_disable_device()
between steps 3 and 4, driver B would loose access to it's device,
even if it didn't intend to.
By using this modification, the device won't be disabled until all the
callers to enable() have called disable().
This is implemented by replacing 'struct pci_dev->is_enabled' from a
bitfield to an atomic use count. Each caller to enable increments it,
each caller to disable decrements it. When the count increments from 0
to 1, __pci_enable_device() is called to actually enable the
device. When it drops to zero, pci_disable_device() actually does the
disabling.
We keep the backend __pci_enable_device() for pci_default_resume() to
use and also change the sysfs method implementation, so that userspace
enabling/disabling the device doesn't disable it one time too much.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The existing implementation of pci_block_user_cfg_access() was recently
criticised for providing out of date information and for returning errors
on write, which applications won't be expecting.
This reimplementation uses a global wait queue and a bit per device.
I've open-coded prepare_to_wait() / finish_wait() as I could optimise
it significantly by knowing that the pci_lock protected us at all points.
It looked a bit funny to be doing a spin_unlock_irqsave(); schedule(),
so I used spin_lock_irq() for the _user versions of pci_read_config and
pci_write_config. Not carrying a flags pointer around made the code
much less nasty.
Attempts to block an already blocked device hit a BUG() and attempts to
unblock an already unblocked device hit a WARN(). If we need to block
access to a device from userspace, it's because it's unsafe for even
another bit of the kernel to access the device. An attempt to block
a device for a second time means we're about to access the device to
perform some other operation, which could provoke undefined behaviour
from the device.
Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Acked-by: Adam Belay <abelay@novell.com>
Acked-by: Alan Cox <alan@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
__pci_register_driver() error path forgot to unwind.
driver_unregister() needs to be called when pci_create_newid_file() failed.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
So it looks like pci aer code will call pci_osc_support_set to tell the
firmware about OSC_EXT_PCI_CONFIG_SUPPORT flag. that causes
ctrlset_buf[OSC_SUPPORT_TYPE] to evaluate to true when pciehp calls
pci_osc_control_set() is called (to attempt to use OSC to gain native
pcie control from firmware), regardless of whether or not _OSC was
actually successfully executed. That causes this section of code:
if (ctrlset_buf[OSC_SUPPORT_TYPE] &&
((global_ctrlsets & ctrlset) != ctrlset)) {
return AE_SUPPORT;
}
to be hit.
This patch will reset the OSC_SUPPORT_TYPE field if _OSC fails, and then
would allow pciehp to go ahead and try to run _OSC again.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
acpiphp_glue_exit() needs to be called to unwind when no slots found.
(It fixes data corruption when reloading acpiphp driver with no such devices)
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes invalid usage of list_for_each()
list_for_each (node, &bridge_list) {
bridge = (struct acpiphp_bridge *)node;
...
}
This code works while the member of list node is located at the
head of struct acpiphp_bridge.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Support a shadowed ROM when running with an ACPI capable PROM.
Define a new dev.resource flag IORESOURCE_ROM_BIOS_COPY to
describe the case of a BIOS shadowed ROM, which can then
be used to avoid pci_map_rom() making an unneeded call to
pci_enable_rom().
Signed-off-by: John Keller <jpk@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
A few minor changes to the way slot/device fixup is done.
No need to be calling sn_pci_controller_fixup(), as
a root bus cannot be hotplugged.
Signed-off-by: John Keller <jpk@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
pSeries is the only architecture left using HAVE_ARCH_PCI_MWI and it's
really inappropriate for its needs. It really wants to disable MWI
altogether. So here are a pair of stub implementations for pci_set_mwi
and pci_clear_mwi.
Also rename pci_generic_prep_mwi to pci_set_cacheline_size since that
better reflects what it does.
Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Cc: Paul Mackerras <paulus@samba.org>
Acked-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The setting of the CACHE_LINE_SIZE register in sparc64's pci
initialisation code isn't quite adequate as the device may have
incompatible requirements. The generic code tests for this, so switch
sparc64 over to using it.
Since sparc64 has different L1 cache line size and PCI cache line size,
it would need to override the generic code like i386 and ia64 do. We
know what the cache line size is at compile time though, so introduce a
new optional constant PCI_CACHE_LINE_BYTES.
Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: David Miller <davem@davemloft.net>
Acked-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The number of permutations of crap we do is amazing and almost all of it
has the wrong effect in 2.6.
At the heart of this is the PCI SFF magic which says that compatibility
mode PCI IDE controllers use ISA IRQ routing and hard coded addresses
not the BAR values. The old quirks variously clears them, sets them,
adjusts them and then IDE ignores the result.
In order to drive all this garbage out and to do it portably we need to
handle the SFF rules directly and properly. Because we know the device
BAR 0-3 are not used in compatibility mode we load them with the values
that are implied (and indeed which many controllers actually
thoughtfully put there in this mode anyway).
This removes special cases in the IDE layer and libata which now knows
that bar 0/1/2/3 always contain the correct address. It means our
resource allocation map is accurate from boot, not "mostly accurate"
after ide is loaded, and it shoots lots of code. There is also lots more
code and magic constant knowledge to shoot once this is in and settled.
Been in my test tree for a while both with drivers/ide and with libata.
Wants some -mm shakedown in case I've missed something dumb or there are
corner cases lurking.
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Shouldn't PCI-X state be saved/restored? No device really needs this
right now. qla24xx (fc HBA) and mthca (infiniband) don't do suspend,
and sky2 resets its tweaks when links are brought up.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Move some MSI-X #defines into pci_regs.h so they can be used
outside of drivers/pci.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
It's not really broken, but people keep running into other problems
caused by it. Re-enable it so that the drivers get stress tested.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Changes persistant -> persistent. www.dictionary.com does not know
persistant (with an A), but should it be one of those things you can
spell in more than one correct way, let me know.
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Fix various .c/.h typos in comments (no code changes).
Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Fix various Kconfig typos.
Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Pass the work_struct pointer to the work function rather than context data.
The work function can use container_of() to work out the data.
For the cases where the container of the work_struct may go away the moment the
pending bit is cleared, it is made possible to defer the release of the
structure by deferring the clearing of the pending bit.
To make this work, an extra flag is introduced into the management side of the
work_struct. This governs auto-release of the structure upon execution.
Ordinarily, the work queue executor would release the work_struct for further
scheduling or deallocation by clearing the pending bit prior to jumping to the
work function. This means that, unless the driver makes some guarantee itself
that the work_struct won't go away, the work function may not access anything
else in the work_struct or its container lest they be deallocated.. This is a
problem if the auxiliary data is taken away (as done by the last patch).
However, if the pending bit is *not* cleared before jumping to the work
function, then the work function *may* access the work_struct and its container
with no problems. But then the work function must itself release the
work_struct by calling work_release().
In most cases, automatic release is fine, so this is the default. Special
initiators exist for the non-auto-release case (ending in _NAR).
Signed-Off-By: David Howells <dhowells@redhat.com>
Fix http://bugzilla.kernel.org/show_bug.cgi?id=7264
We need to target this quirk a little more tightly, using the T20 DMI string.
Cc: Pavel Kysilka <goldenfish@bsys.cz>
Acked-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Daniel Ritz <daniel.ritz@gmx.ch>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The PCI sysfs attributes are created after the initial PCI bus scan. With
the addition of more return value checking and assertions in the device and
sysfs layers we now can get dumps like this on sparc64:
[ 20.135032] Call Trace:
[ 20.135042] [0000000000537f88] pci_remove_bus_device+0x30/0xc0
[ 20.135076] [000000000078f890] pci_fill_in_pbm_cookies+0x98/0x440
[ 20.135109] [000000000042e828] sabre_scan_bus+0x230/0x400
[ 20.135139] [000000000078c710] pcibios_init+0x58/0xa0
[ 20.135159] [0000000000416f14] init+0x9c/0x2e0
[ 20.135190] [0000000000417a50] kernel_thread+0x38/0x60
[ 20.135211] [0000000000417170] rest_init+0x18/0x40
[ 20.135514] PCI0(PBMB): Bus running at 33MHz
It's triggering because removal of the "config" PCI sysfs file for the
device fails.
On sparc64, after probing the device, we'll delete the PCI device via
pci_remove_bus_device() if we cannot find the firmware device tree node
corresponding to it.
This is fine, but at this point the sysfs files for the PCI device won't be
setup yet.
So we should not try to do anything in pci_remove_sysfs_dev_files() if
pci_sysfs_init() has not run yet.
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch adds a variant of ht_create_irq __ht_create_irq that takes an
aditional parameter update that is a function that is called whenever we want
to write to a drivers htirq configuration registers.
This is needed to support the ipath_iba6110 because it's registers in the
proper location are not actually conected to the hardware that controlls
interrupt delivery.
[bos@serpentine.com: fixes]
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Andi Kleen <ak@suse.de>
Cc: <olson@pathscale.com>
Cc: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Bryan O'Sullivan <bryan.osullivan@qlogic.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This refactoring actually optimizes the code a little by caching the value
that we think the device is programmed with instead of reading it back from
the hardware. Which simplifies the code a little and should speed things up a
bit.
This patch introduces the concept of a ht_irq_msg and modifies the
architecture read/write routines to update this code.
There is a minor consistency fix here as well as x86_64 forgot to initialize
the htirq as masked.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Andi Kleen <ak@suse.de>
Acked-by: Bryan O'Sullivan <bos@pathscale.com>
Cc: <olson@pathscale.com>
Cc: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
PCI_MULTITHREAD_PROBE is an interesting feature, but in its current state
it seems to be more of a trap for users who accidentally enable it.
This patch lets PCI_MULTITHREAD_PROBE depend on BROKEN for 2.6.19.
The intention is to get this patch reversed in -mm as soon as it's in
Linus' tree, and reverse it for 2.6.20 or 2.6.21 after the fallout of
in-kernel problems PCI_MULTITHREAD_PROBE causes got fixed.
(akpm: I get enough bug reports already)
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
My K8T800 mobo resumes fine from suspend to ram with and without patch
applied against 2.6.18.
quirk_via_abnormal_poweroff makes some boards not boot 2.6.18, so IMO patch
should go to head, 2.6.18.2 and everywhere "ACPI: ACPICA 20060623" has been
applied.
Remove quirk_via_abnormal_poweroff
Obsoleted by "ACPI: ACPICA 20060623":
<snip>
Implemented support for "ignored" bits in the ACPI
registers. According to the ACPI specification, these
bits should be preserved when writing the registers via
a read/modify/write cycle. There are 3 bits preserved
in this manner: PM1_CONTROL[0] (SCI_EN), PM1_CONTROL[9],
and PM1_STATUS[11].
http://bugzilla.kernel.org/show_bug.cgi?id=3691
</snip>
Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de>
Cc: Bob Moore <robert.moore@intel.com>
Cc: "Brown, Len" <len.brown@intel.com>
Acked-by: Dave Jones <davej@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Considering below scenario:
1.Unload a PCI device's driver, the device ->current remains in PCI_D0.
2.Do suspend/resume circle. After that, BIOS puts the device to D3.
3.Reload the device driver. The calling pci_set_power_state in the
driver can't change the state to D0, as set_power_state thinks the
device is already in D0.
A bug is reported at http://bugzilla.kernel.org/show_bug.cgi?id=6024
Pat attached a patch at
http://marc.theaimsgroup.com/?l=linux-pci&m=114049761428561&w=2 for this
issue, but it's lost. As pci_set_power_state can handle D3 -> D0
correctly (restore config space), I simplified Patrick's patch.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Cc: Patrick Mochel <mochel@digitalimplant.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This reverts much of the original pci_fixup_video change and makes it
work for all arches that need it.
fixed, and tested on x86, x86_64 and IA64 dig.
Signed-off-by: Eiichiro Oiwa <eiichiro.oiwa.nm@hitachi.com>
Acked-by: David Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
pci_hotplug.h says:
* @latch_status: if the latch (if any) is open or closed (1/0)
However, acpiphp returns opposite value.
This patch fixes this issue.
I tested this patch on my ia64 machine that has some apciphp based
hotplug slots.
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>
In commit 4e8a520150 ("[PKT_SCHED] netem:
Orphan SKB when adding to queue.") Davem mistakenly also included a
temporary diff in his tree that disabled the pci_fixup_video VGA quirk,
which broke sparc64.
This reverts that part of the commit. Sayeth Davem:
"Greg KH has a patch coming to you soon which will move that VGA code
back into x86/x86_64/IA64 specific areas and will fix the sparc64
problem properly."
Special thanks to Claudio Martins <ctpm@ist.utl.pt> for noticing the
error in the first place.
Cc: Claudio Martins <ctpm@ist.utl.pt>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The networking emulator can queue SKBs for a very long
time, so if you're using netem on the sender side for
large bandwidth/delay product testing, the SKB socket
send queue sizes become artificially larger.
Correct this by calling skb_orphan() in netem_enqueue().
Signed-off-by: David S. Miller <davem@davemloft.net>
This makes it possible to build pci hotplug drivers outside of the main
kernel tree, and Sam keeps telling me to move local header files to
their proper places...
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Here's a patch adding me to the maintainers file for the pci
hotplug subsystem, as we discussed.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Problem:
New Dell PowerEdge servers have 2 embedded ethernet ports, which are
labeled NIC1 and NIC2 on the chassis, in the BIOS setup screens, and
in the printed documentation. Assuming no other add-in ethernet ports
in the system, Linux 2.4 kernels name these eth0 and eth1
respectively. Many people have come to expect this naming. Linux 2.6
kernels name these eth1 and eth0 respectively (backwards from
expectations). I also have reports that various Sun and HP servers
have similar behavior.
Root cause:
Linux 2.4 kernels walk the pci_devices list, which happens to be
sorted in breadth-first order (or pcbios_find_device order on i386,
which most often is breadth-first also). 2.6 kernels have both the
pci_devices list and the pci_bus_type.klist_devices list, the latter
is what is walked at driver load time to match the pci_id tables; this
klist happens to be in depth-first order.
On systems where, for physical routing reasons, NIC1 appears on a
lower bus number than NIC2, but NIC2's bridge is discovered first in
the depth-first ordering, NIC2 will be discovered before NIC1. If the
list were sorted breadth-first, NIC1 would be discovered before NIC2.
A PowerEdge 1955 system has the following topology which easily
exhibits the difference between depth-first and breadth-first device
lists.
-[0000:00]-+-00.0 Intel Corporation 5000P Chipset Memory Controller Hub
+-02.0-[0000:03-08]--+-00.0-[0000:04-07]--+-00.0-[0000:05-06]----00.0-[0000:06]----00.0 Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (labeled NIC2, 2.4 kernel name eth1, 2.6 kernel name eth0)
+-1c.0-[0000:01-02]----00.0-[0000:02]----00.0 Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (labeled NIC1, 2.4 kernel name eth0, 2.6 kernel name eth1)
Other factors, such as device driver load order and the presence of
PCI slots at various points in the bus hierarchy further complicate
this problem; I'm not trying to solve those here, just restore the
device order, and thus basic behavior, that 2.4 kernels had.
Solution:
The solution can come in multiple steps.
Suggested fix#1: kernel
Patch below optionally sorts the two device lists into breadth-first
ordering to maintain compatibility with 2.4 kernels. It adds two new
command line options:
pci=bfsort
pci=nobfsort
to force the sort order, or not, as you wish. It also adds DMI checks
for the specific Dell systems which exhibit "backwards" ordering, to
make them "right".
Suggested fix#2: udev rules from userland
Many people also have the expectation that embedded NICs are always
discovered before add-in NICs (which this patch does not try to do).
Using the PCI IRQ Routing Table provided by system BIOS, it's easy to
determine which PCI devices are embedded, or if add-in, which PCI slot
they're in. I'm working on a tool that would allow udev to name
ethernet devices in ascending embedded, slot 1 .. slot N order,
subsort by PCI bus/dev/fn breadth-first. It'll be possible to use it
independent of udev as well for those distributions that don't use
udev in their installers.
Suggested fix#3: system board routing rules
One can constrain the system board layout to put NIC1 ahead of NIC2
regardless of breadth-first or depth-first discovery order. This adds
a significant level of complexity to board routing, and may not be
possible in all instances (witness the above systems from several
major manufacturers). I don't want to encourage this particular train
of thought too far, at the expense of not doing #1 or #2 above.
Feedback appreciated. Patch tested on a Dell PowerEdge 1955 blade
with 2.6.18.
You'll also note I took some liberty and temporarily break the klist
abstraction to simplify and speed up the sort algorithm. I think
that's both safe and appropriate in this instance.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
cpcihp_generic module requires configured "bridge" module parameter.
But it can be loaded successfully without that parameter.
Because module init call ends up returning positive value.
This patch prevents from loading without setting "bridge" module parameter.
Signed-off-by: Akinbou Mita <akinobu.mita@gmail.com>
Signed-off-by: Scott Murray <scottm@somanetworks.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In order to finish converting to pci_get_* interfaces we need to add a couple
of bits of missing functionaility
pci_get_bus_and_slot() provides the equivalent to pci_find_slot()
(pci_get_slot is already taken as a name for something similar but not the
same)
pci_get_device_reverse() is the equivalent of pci_find_device_reverse but
refcounting
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
1. ioremap must be balanced by an iounmap and failing to do so can
result in a memory leak.
2. Handle return value correctly
Tested (compilation only) with:
- allmodconfig
Signed-off-by: Amol Lad <amol@verismonetworks.com>
Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch removes unnecessary cmd_busy member from struct
controller. Read command status register instead of using cmd_busy.
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>
This patch fixes the problem that shpchp driver could mis-detect
command failures if the system was under heavy load.
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>
pci_find is not hotplug safe, so it really doesn't want to be in an
actual hotplug driver either.
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
On Thu, 2006-09-28 at 03:42, Olaf Hering wrote:
> PCI-Express AER implemetation: pcie_portdrv error handler
>
> This patch breaks if CONFIG_PM is not enabled,
> pcie_portdrv_restore_config() will be undefined.
I move the definition of pcie_portdrv_restore_config
out of CONFIG_PM.
Below patch is against 2.6.18-mm1. Could you try it?
Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
pci_fixup_video turns into generic code because there are many platforms need this fixup
for embedded VGA as well as x86. The Video BIOS integrates into System BIOS on a machine
has embedded VGA although embedded VGA generally don't have PCI ROM. As a result,
embedded VGA need the way that the sysfs rom points to the Video BIOS of System
RAM (0xC0000). PCI-to-PCI Bridge Architecture specification describes the condition whether
or not PCI ROM forwards VGA compatible memory address. fixup_video suits this specification.
Although the Video ROM generally implements in x86 code regardless of platform, some
application such as X Window System can run this code by dosemu86. Therefore,
pci_fixup_video should turn into generic code.
Signed-off-by: Eiichiro Oiwa <eiichiro.oiwa.nm@hitachi.com>
Acked-by: Alan Cox <alan@redhat.com>
Acked-by: Jesse Barnes <jesse.barnes@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
__must_check goes on the declaration, not the definition.
Cc: "Randy.Dunlap" <rdunlap@xenotime.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The most recent VIA IRQ quirk changes have broken various VIA devices for
some users. We are not able to add these devices to the blacklist as they
are also available in PCI-card form, and running the quirk on these devices
brings us back to square one (running the VIA quirk on non-VIA boards where
the quirk is not needed).
This patch, based on suggestions from Sergey Vlasov, implements a scheme
similar to but more restrictive than the scheme we had in 2.6.16 and
earlier. It runs the quirk on all VIA hardware, but *only* if a VIA
southbridge was detected on the system.
To further reduce the amount of quirked devices, this patch includes a
change suggested by Linus at http://lkml.org/lkml/2005/9/27/113 This
ensures that devices bound to non-legacy IO-APIC interrupt lines are not
quirked. We have made one change to Linus' suggestion: we do a comparison
of ">15" rather than ">=15", as 15 is still in the legacy interrupt range.
There is still a downside to this patch: if the user inserts a VIA PCI card
into a VIA-based motherboard, in some circumstances the quirk will also run
on the VIA PCI card. This corner case is hard to avoid.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
this was spotted by coverity (cid #819). We dereference p_slot
earlier in the function, and i found no way it could become NULL
anywhere.
Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes the problem that system will panic if multiple power
on/off operations are issued to the same slot in parallel. This
problem can be easily reproduced by commands below.
# while true; do echo 1 > power; echo 0 > power; done &
# while true; do echo 1 > power; echo 0 > power; done &
The cause is lack of locking for enable/disable operations. This patch
fixes this problem.
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>
The slot number displayed in info messages would cause a confusion
because those are displayed in several ways (decimal and hex).
Furthermore, those slot number is not same as slot name (directory
name). This patch fixes those improper info messages.
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>
This patch fixes the problem that issuing SHPC command in poll mode
always fails with the following message.
shpchp: Command not completed in 2000 msec
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>
CONFIG_PCI=n, CONFIG_HT_IRQ=y results in the following compile error:
...
LD vmlinux
arch/i386/mach-generic/built-in.o: In function `apicid_to_node':
summit.c:(.text+0x53): undefined reference to `apicid_2_node'
arch/i386/kernel/built-in.o: In function `arch_setup_ht_irq':
(.text+0xcf79): undefined reference to `write_ht_irq_low'
arch/i386/kernel/built-in.o: In function `arch_setup_ht_irq':
(.text+0xcf85): undefined reference to `write_ht_irq_high'
arch/i386/kernel/built-in.o: In function `k7nops':
alternative.c:(.data+0x1358): undefined reference to `mask_ht_irq'
alternative.c:(.data+0x1360): undefined reference to `unmask_ht_irq'
make[1]: *** [vmlinux] Error 1
Bug report by Jesper Juhl.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
of passing regs around manually through all ~1800 interrupt handlers in the
Linux kernel.
The regs pointer is used in few places, but it potentially costs both stack
space and code to pass it around. On the FRV arch, removing the regs parameter
from all the genirq function results in a 20% speed up of the IRQ exit path
(ie: from leaving timer_interrupt() to leaving do_IRQ()).
Where appropriate, an arch may override the generic storage facility and do
something different with the variable. On FRV, for instance, the address is
maintained in GR28 at all times inside the kernel as part of general exception
handling.
Having looked over the code, it appears that the parameter may be handed down
through up to twenty or so layers of functions. Consider a USB character
device attached to a USB hub, attached to a USB controller that posts its
interrupts through a cascaded auxiliary interrupt controller. A character
device driver may want to pass regs to the sysrq handler through the input
layer which adds another few layers of parameter passing.
I've build this code with allyesconfig for x86_64 and i386. I've runtested the
main part of the code on FRV and i386, though I can't test most of the drivers.
I've also done partial conversion for powerpc and MIPS - these at least compile
with minimal configurations.
This will affect all archs. Mostly the changes should be relatively easy.
Take do_IRQ(), store the regs pointer at the beginning, saving the old one:
struct pt_regs *old_regs = set_irq_regs(regs);
And put the old one back at the end:
set_irq_regs(old_regs);
Don't pass regs through to generic_handle_irq() or __do_IRQ().
In timer_interrupt(), this sort of change will be necessary:
- update_process_times(user_mode(regs));
- profile_tick(CPU_PROFILING, regs);
+ update_process_times(user_mode(get_irq_regs()));
+ profile_tick(CPU_PROFILING);
I'd like to move update_process_times()'s use of get_irq_regs() into itself,
except that i386, alone of the archs, uses something other than user_mode().
Some notes on the interrupt handling in the drivers:
(*) input_dev() is now gone entirely. The regs pointer is no longer stored in
the input_dev struct.
(*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does
something different depending on whether it's been supplied with a regs
pointer or not.
(*) Various IRQ handler function pointers have been moved to type
irq_handler_t.
Signed-Off-By: David Howells <dhowells@redhat.com>
(cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
This moves the declarations for the architecture helpers into
include/linux/htirq.h from the generic include/linux/pci.h. Hopefully this
will make this distinction clearer.
htirq.h is included where it is needed.
The dependency on the msi code is fixed and removed.
The Makefile is tidied up.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Greg KH <greg@kroah.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This is just a few makefile tweaks and some file renames.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Greg KH <greg@kroah.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
It turns out msi_ops was simply not enough to abstract the architecture
specific details of msi. So I have moved the resposibility of constructing
the struct irq_chip to the architectures, and have two architecture specific
functions arch_setup_msi_irq, and arch_teardown_msi_irq.
For simple architectures those functions can do all of the work. For
architectures with platform dependencies they can call into the appropriate
platform code.
With this msi.c is finally free of assuming you have an apic, and this
actually takes less code.
The helpers for the architecture specific code are declared in the linux/msi.h
to keep them separate from the msi functions used by drivers in linux/pci.h
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Greg KH <greg@kroah.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The logic works like this.
Since we no longer track the state logic by hand in msi.c startup and shutdown
are no longer needed.
By updating msi_set_mask_bit to work on msi devices that do not implement a
mask bit we can always call the mask/unmask functions.
What we really have are mask and unmask so we use them to implement the .mask
and .unmask functions instead of .enable and .disable.
By switching to the handle_edge_irq handler we only need an ack function that
moves the irq if necessary. Which removes the old end and ack functions and
their peculiar logic of sometimes disabling an irq.
This removes the reliance on pre genirq irq handling methods.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Greg KH <greg@kroah.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Currently msi.c is doing sanity checks that make certain before an irq is
destroyed it has no more users.
By adding irq_has_action I can perform the test is a generic way, instead of
relying on a msi specific data structure.
By performing the core check in dynamic_irq_cleanup I ensure every user of
dynamic irqs has a test present and we don't free resources that are in use.
In msi.c this allows me to kill the attrib.state member of msi_desc and all of
the assciated code to maintain it.
To keep from freeing data structures when irq cleanup code is called to soon
changing dyanamic_irq_cleanup is insufficient because there are msi specific
data structures that are also not safe to free.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Greg KH <greg@kroah.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch implements two functions ht_create_irq and ht_destroy_irq for
use by drivers. Several other functions are implemented as helpers for
arch specific irq_chip handlers.
The driver for the card I tested this on isn't yet ready to be merged.
However this code is and hypertransport irqs are in use in a few other
places in the kernel. Not that any of this will get merged before 2.6.19
Because the ipath-ht400 is slightly out of spec this code will need to be
generalized to work there.
I think all of the powerpc uses are for a plain interrupt controller in a
chipset so support for native hypertransport devices is a little less
interesting.
However I think this is a half way decent model on how to separate arch
specific and generic helper code, and I think this is a functional model of
how to get the architecture dependencies out of the msi code.
[akpm@osdl.org: Kconfig fix]
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Greg KH <greg@kroah.com>
Cc: Andi Kleen <ak@muc.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
After the previous changes ia64 is the only architecture useing msi-apic.c
[akpm@osdl.org: unbreak MSI on ia64]
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rajesh Shah <rajesh.shah@intel.com>
Cc: Andi Kleen <ak@muc.de>
Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The msi currently allocates irqs backwards. First it allocates a platform
dependent routing value for an interrupt the ``vector'' and then it figures
out from the vector which irq you are on.
For ia64 this is fine. For x86 and x86_64 this is complete nonsense and makes
an enourmous mess of the irq handling code and prevents some pretty
significant cleanups in the code for handling large numbers of irqs.
This patch refactors msi.c to work in terms of irqs and create_irq/destroy_irq
for dynamically managing irqs.
Hopefully this is finally a version of msi.c that is useful on more than just
x86 derivatives.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rajesh Shah <rajesh.shah@intel.com>
Cc: Andi Kleen <ak@muc.de>
Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Currently we attempt to predict how many irqs we will be able to allocate with
msi using pci_vector_resources and some complicated accounting, and then we
only allow each device as many irqs as we think are available on average.
Only the s2io driver even takes advantage of this feature all other drivers
have a fixed number of irqs they need and bail if they can't get them.
pci_vector_resources is inaccurate if anyone ever frees an irq. The whole
implmentation is racy. The current irq limit policy does not appear to make
sense with current drivers. So I have simplified things. We can revisit this
we we need a more sophisticated policy.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rajesh Shah <rajesh.shah@intel.com>
Cc: Andi Kleen <ak@muc.de>
Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The current msi_ops are short sighted in a number of ways, this patch attempts
to fix the glaring deficiences.
- Report in msi_ops if a 64bit address is needed in the msi message, so we
can fail 32bit only msi structures.
- Send and receive a full struct msi_msg in both setup and target. This is
a little cleaner and allows for architectures that need to modify the data
to retarget the msi interrupt to a different cpu.
- In target pass in the full cpu mask instead of just the first cpu in case
we can make use of the full cpu mask.
- Operate in terms of irqs and not vectors, currently there is still a 1-1
relationship but on architectures other than ia64 I expect this will change.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rajesh Shah <rajesh.shah@intel.com>
Cc: Andi Kleen <ak@muc.de>
Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
In support of this I also add a struct msi_msg that captures the the two
address and one data field ina typical msi message, and I remember the pos and
if the address is 64bit in struct msi_desc.
This makes the code a little more readable and easier to maintain, and paves
the way to further simplfications.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rajesh Shah <rajesh.shah@intel.com>
Cc: Andi Kleen <ak@muc.de>
Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This allows the output of the msi tests to be stored directly in a bit field.
If you don't do this a value greater than one will be truncated and become 0.
Changing true to false with bizare consequences.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rajesh Shah <rajesh.shah@intel.com>
Cc: Andi Kleen <ak@muc.de>
Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The problem. Because the disable routines leave the msi interrupts in all
sorts of half enabled states the enable routines become impossible to
implement correctly, and almost impossible to understand.
Simplifing this allows me to simply kill the buggy reroute_msix_table, and
generally makes the code more maintainable.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rajesh Shah <rajesh.shah@intel.com>
Cc: Andi Kleen <ak@muc.de>
Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Cc: Rajesh Shah <rajesh.shah@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Roland Dreier wrote:
> The change "PCI: assign ioapic resource at hotplug" (commit
> 2318627965 in Linus's tree) makes
> networking stop working on my system (SuperMicro H8QC8 with four
> dual-core Opteron 885 CPUs). In particular, the on-board NIC stops
> working, probably because it gets assigned the wrong IRQ (225 in the
> non-working case, 217 in the working case)
>
> With that patch applied, e1000 doesn't work. Reverting just that
> patch (shown below) from Linus's latest tree fixes things for me.
>
The cause of this problem might be an wrong assumption that the 'start'
member of resource structure for ioapic device has non-zero value if the
resources are assigned by firmware. The 'start' member of ioapic device
seems not to be set even though the resources were actually assigned to
ioapic devices by firmware.
Cc: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
Cc: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Roland Dreier <rdreier@cisco.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This fixes two things
Firstly someone mistakenly used "errata" for the singular. This causes
Dave Woodhouse to emit diagnostics whenever the string is read, and so
should be fixed.
Secondly the AMD AGP tunnel has an erratum which causes hangs if you try
and do direct PCI to AGP transfers in some cases. We have a flag for
PCI/PCI failures but we need a different flag for this really as in this
case we don't want to stop PCI/PCI transfers using things like IOAT and the
new RAID offload work.
I'll post some updates to make proper use of the PCIAGP flag in the
media/video drivers to Mauro.
Signed-off-by: Alan Cox <alan@redhat.com>
Cc: David Woodhouse <dwmw2@infradead.org>
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>
The following patches reduce the size of the VFS inode structure by 28 bytes
on a UP x86. (It would be more on an x86_64 system). This is a 10% reduction
in the inode size on a UP kernel that is configured in a production mode
(i.e., with no spinlock or other debugging functions enabled; if you want to
save memory taken up by in-core inodes, the first thing you should do is
disable the debugging options; they are responsible for a huge amount of bloat
in the VFS inode structure).
This patch:
The filesystem or device-specific pointer in the inode is inside a union,
which is pretty pointless given that all 30+ users of this field have been
using the void pointer. Get rid of the union and rename it to i_private, with
a comment to explain who is allowed to use the void pointer. This is just a
cleanup, but it allows us to reuse the union 'u' for something something where
the union will actually be used.
[judith@osdl.org: powerpc build fix]
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Judith Lebzelter <judith@osdl.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch fixes the problem that trying to enable already enabled
slot disables the slot by returning the proper value from
pciehp_enable_slot()/pciehp_disable_slot().
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>
We need to assign resources to ioapics being hot-added. This patch
changes pbus_assign_resources_sorted() to assign resources if the
ioapic has no assigned resources.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Currently acpiphp calls pci_enable_device() against all
hot-added bridges, but acpiphp does not call pci_disable_device()
against them in hot-remove. So ioapic hot-remove would fail.
This patch fixes this issue.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Contrary to PCI bridge hot-add, we need to follow the sequence below
for PCI bridge hot-removal.
(1) Stop devices (detach drivers, remove from the global list, etc.)
(2) Unbind ACPI node from the devices (remove the _PRT entries)
(3) Remove devices (remove from the device list, etc.)
This patch fixes acpiphp driver to follow above sequence for P2P
bridge hot-removal.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds pci_stop_bus_device() which stops a PCI device (detach
the driver, remove from the global list and so on) and any children.
This is needed for ACPI based PCI-to-PCI bridge hot-remove, and it will
be also needed for ACPI based PCI root bridge hot-remove.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Currently acpiphp initializes all ioapics under the bus on which
hot-add event occured. It also initializes already working ioapics.
This patch fixes this bug.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Currently acpiphp initializes ioapics after starting devices,
but ioapics should be initialized before starting devices.
This patch fixes this bug.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Currently acpiphp sets hpp values after starting devices, but
the values should be set before starting devices. This patch
fixes this bug.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Restore PCI Express capability registers after PM event.
This includes maxumum MTU for PCI express and other vital data.
Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There are numerous drivers that can use multithreaded probing but having
some kind of global flag as the way to control this makes migration to
threaded probing hard and since it enables it everywhere and is almost
as likely to cause serious pain as holding a clog dance in a minefield.
If we have a pci_driver multithread_probe flag to inherit you can turn
it on for one driver at a time.
From playing so far however I think we need a different model at the
device layer which serializes until the called probe function says "ok
you can start another one now". That would need some kind of flag and
semaphore plus a helper function.
Anyway in the absence of that this is a starting point to usefully play
with this stuff
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Patch 3 implements the core part of PCI-Express AER and aerdrv
port service driver.
When a root port service device is probed, the aerdrv will call
request_irq to register irq handler for AER error interrupt.
When a device sends an PCI-Express error message to the root port,
the root port will trigger an interrupt, by either MSI or IO-APIC,
then kernel would run the irq handler. The handler collects root
error status register and schedules a work. The work will call
the core part to process the error based on its type
(Correctable/non-fatal/fatal).
As for Correctable errors, the patch chooses to just clear the correctable
error status register of the device.
As for the non-fatal error, the patch follows generic PCI error handler
rules to call the error callback functions of the endpoint's driver. If
the device is a bridge, the patch chooses to broadcast the error to
downstream devices.
As for the fatal error, the patch resets the pci-express link and
follows generic PCI error handler rules to call the error callback
functions of the endpoint's driver. If the device is a bridge, the patch
chooses to broadcast the error to downstream devices.
Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Have pcie_port_bus_register() notice and return errors.
Mark it __must_check so that its caller(s) must check its return value.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Introduce msi_ht_cap_enabled() to check the MSI capability in the
Hypertransport configuration space.
It is used in a generic quirk quirk_msi_ht_cap() to check whether
MSI is enabled on hypertransport chipset, and a nVidia specific quirk
quirk_nvidia_ck804_msi_ht_cap() where two 2 HT MSI mappings have to
be checked.
Both quirks set the PCI_BUS_FLAGS_NO_MSI bus flag when MSI is disabled.
Signed-off-by: Brice Goglin <brice@myri.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Export the PCI_BUS_FLAGS_NO_MSI flag of a PCI bus in the sysfs files
of its parent device and make it writable. Could be used to:
* disable MSI on a device which has not been blacklisted yet
* allow MSI when some setpci hacks enable MSI support (for instance
on the ServerWorks HT2000 chipset where the MSI HT cap is disabled
by default).
Architecture where some bus have no parent chipset cannot use this
strategy to change MSI support.
If the chipset does not have a subordinate bus, its 'bus_msi' file
is empty.
Also document and warn about the possible danger of changing the flag.
Signed-off-by: Brice Goglin <brice@myri.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
pci_enable_msi() and pci_enable_msix() use the same code to detect
whether MSI might be enabled on this device. Factorize this code in
pci_msi_supported(). And improve the documentation about the fact
that only the root chipset must support MSI, but it is hard to
find the root bus so we check all parent busses MSI flags.
Signed-off-by: Brice Goglin <brice@myri.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Move MSI quirks in CONFIG_PCI_MSI, document why the serverworks quirk
does not simply set PCI_BUS_FLAGS_NO_MSI, and create a generic quirk
for other chipsets where setting PCI_BUS_FLAGS_NO_MSI is fine.
Signed-off-by: Brice Goglin <brice@myri.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6: (225 commits)
[PATCH] Don't set calgary iommu as default y
[PATCH] i386/x86-64: New Intel feature flags
[PATCH] x86: Add a cumulative thermal throttle event counter.
[PATCH] i386: Make the jiffies compares use the 64bit safe macros.
[PATCH] x86: Refactor thermal throttle processing
[PATCH] Add 64bit jiffies compares (for use with get_jiffies_64)
[PATCH] Fix unwinder warning in traps.c
[PATCH] x86: Allow disabling early pci scans with pci=noearly or disallowing conf1
[PATCH] x86: Move direct PCI scanning functions out of line
[PATCH] i386/x86-64: Make all early PCI scans dependent on CONFIG_PCI
[PATCH] Don't leak NT bit into next task
[PATCH] i386/x86-64: Work around gcc bug with noreturn functions in unwinder
[PATCH] Fix some broken white space in ia32_signal.c
[PATCH] Initialize argument registers for 32bit signal handlers.
[PATCH] Remove all traces of signal number conversion
[PATCH] Don't synchronize time reading on single core AMD systems
[PATCH] Remove outdated comment in x86-64 mmconfig code
[PATCH] Use string instructions for Core2 copy/clear
[PATCH] x86: - restore i8259A eoi status on resume
[PATCH] i386: Split multi-line printk in oops output.
...
Some buggy systems can machine check when config space accesses
happen for some non existent devices. i386/x86-64 do some early
device scans that might trigger this. Allow pci=noearly to disable
this. Also when type 1 is disabling also don't do any early
accesses which are always type1.
This moves the pci= configuration parsing to be a early parameter.
I don't think this can break anything because it only changes
a single global that is only used by PCI.
Cc: gregkh@suse.de
Cc: Trammell Hudson <hudson@osresearch.net>
Signed-off-by: Andi Kleen <ak@suse.de>
This provides a build and run-time option to turn on multhreaded probe
for all PCI drivers. It can cause bad problems on multi-processor
machines that take a while to find their root disks, and play havoc on
machines that don't use persistant device names for block or network
devices.
But it can cause speedups on some machines, my tiny laptop's boot goes
up by 0.4 seconds, and my desktop boots up several seconds faster.
Use at your own risk!!!
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Make sysfs_remove_bin_file() void. If it detects an error,
printk the file name and call dump_stack().
sysfs_hash_and_remove() now returns an error code indicating
its success or failure so that sysfs_remove_bin_file() can
know success/failure.
Convert the only driver that checked the return value of
sysfs_remove_bin_file().
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Remove the new suspend_prepare() phase. It doesn't seem very usable,
has never been tested, doesn't address fault cleanup, and would need
a sibling resume_complete(); plus there are no real use cases. It
could be restored later if those issues get resolved.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Convert some framework code to handle the new PRETHAW message.
- IDE just treats it like a FREEZE.
- The pci_choose_state() thingie still doesn't use PCI_D0 when it gets a
FREEZE (and now PRETHAW) event, which seems rather buglike but wasn't
something to change with this patch.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Changes the PCI core to use the new suspend infrastructure changes.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Patch to add VIA PCI quirk for Enhanced/Extended USB on VT8235
southbridge. It is needed in order to use EHCI/USB 2.0 with ACPI.
Without it IRQs are not routed correctly, you get an "Unlink after
no-IRQ?" error and the device is unusable.
I belive this could also be a fix for Bugzilla Bug 5835.
Signed-off-by: Mark Hindley <mark@hindley.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Removes an unused kerneldoc entry from pci_match_device and
put the others into correct order.
Signed-off-by: Henrik Kretzschmar <henne@nachtwindheim.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Here is a patch against the CPCI hotplug core to fix up PCI resource
assignment such that things will actually work when a hot inserted
device is enabled. I mentioned this patch to you way back in April at
ELC, but am only now out from under things enough to clean it up and
submit it. I've basically cribbed the corresponding code from
shpchp_pci.c, so there are no big surprises. If it's still possible, I
wouldn't mind this going into 2.6.18, but it wouldn't be the end of the
world if it went into 2.6.19.
Signed-off-by: Scott Murray <scottm@somanetworks.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
- add the ICH6(R) LPC to the ICH6 ACPI quirks. currently only the ICH6-M
is handled. [ PCI_DEVICE_ID_INTEL_ICH6_1 is the ICH6-M LPC, ICH6_0 is
the ICH6(R) ]
- remove the wrong quirk calling asus_hides_smbus_lpc() for ICH6. the
register modified in asus_hides_smbus_lpc() has a different meaning in
ICH6.
Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drivers/pci/quirks.c was not updated when libata config constants were
renamed braking several libata quirks. Fix it.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Change the build options for acpiphp so that it may build without being
dependent on the ACPI_DOCK option, but yet does not allow the option of
acpiphp being built-in when dock is built as a module.
This does not change the previous patch for ACPI_IBM_DOCK Kconfig.
For the following matrix of config options, I built an i386 kernel.
Dock acpiphp should it build? confirmed
y y y y
y n y y
y m y y
m y no - acpiphp should acpiphp was
convert to m converted to m
m n y y
m m y y
n y y y
n n y y
n m y y
Signed-off-by: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Make pciehp build on powerpc
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Unhide the SMBus controller on the Asus PU-DLS board.
This fixes bug #6763.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add acpiphp to the MAINTAINERS file.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If pcie_portdrv_probe() fails but it had already called
pci_enable_device(), then call pci_disable_device() when
returning error.
Is there some reason that this isn't being done?
or was it just missed?
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Clean up kernel-doc comments in drivers/pci/search.c (line sizes and typos).
Enable that source file in DocBook/kernel-api.tmpl.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Now that get_property() returns a void *, there's no need to cast its
return value. Also, treat the return value as const, so we can
constify get_property later.
pseries platform changes.
Built for pseries_defconfig
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Without this quirk, e100 can be pulling on a shared
interrupt line when another device (eg. USB) loads,
causing the interrupt to scream and get disabled.
http://bugzilla.kernel.org/show_bug.cgi?id=5918
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
When changing power states from D0->DX and then from DX->D0, some
Intel PCIE chipsets will cause a device reset to occur. This will
cause problems for any D State other than D3, since any state
information that the driver will expect to be present coming from
a D1 or D2 state will have been cleared. This patch addes a
flag to the pci_dev structure to indicate that devices should
not use states D1 or D2, and will set that flag for the affected
chipsets. This patch also modifies pci_set_power_state() so that
when a device driver tries to set the power state on
a device that is downstream from an affected chipset, or on one
of the affected devices it only allows state changes to or
from D0 & D3. In addition, this patch allows the delay time
between D3->D0 to be changed via a quirk. These chipsets also
need additional time to change states beyond the normal 10ms.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Some VIA southbridges contain a flag in the ACPI register space that
indicates whether an abnormal poweroff has occured, presumably with the
intention that it can be cleared on clean shutdown. Some BIOSes check this
flag at resume time, and will re-POST the system rather than jump back to
the OS if it's set. Clearing it at boot time appears to be sufficient.
I'm not sure if drivers/pci/quirks.c is the right place to do it, but I'm
not sure where would be cleaner.
[akpm@osdl.org: cleanups, build fix]
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Greg KH <greg@kroah.com>
Cc: "Brown, Len" <len.brown@intel.com>
Cc: "Yu, Luming" <luming.yu@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Prior to 2.6.18rc1 you could install with devices on a JMicron chipset
using the "all-generic-ide" option. As of this kernel the AHCI driver
grabs the controller and rams it into AHCI mode losing the PATA ports
and making CD drives and the like vanish. The all-generic-ide option
fails because the AHCI driver grabbed the PCI device and reconfigured
it.
To fix this three things are needed.
#1 We must put the chip into dual function mode
#2 The AHCI driver must grab only function 0 (already in your rc1 tree)
#3 Something must grab the PATA ports
The attached patch is the minimal risk edition of this. It puts the chip
into dual function mode so that AHCI will grab the SATA ports without
losing the PATA ports. To keep the risk as low as possible the third
patch adds the PCI identifiers for the PATA port and the FN check to the
ide-generic driver. There is a more featured jmicron driver on its way
but that adds risk and the ide-generic support is sufficient to install
and run a system.
The actual chip setup done by the quirk is the precise setup recommended
by the vendor.
(The JMB368 appears only in the ide-generic entry as it has no AHCI so
does not need the quirk)
Signed-off-by: Alan Cox <alan@redhat.com>
Acked-by: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
It looks like someone confused kmem_cache_create with a different allocator
and was attempting to give it knowledge of how many cache entries there
were.
With the unfortunate result that each slab entry was big enough to hold
every irq.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This is confirmed to fix a hang due to PCI resource conflicts with
setting up the Cardbus bridge on old laptops with the 440MX chipsets.
Original report by Alessio Sangalli, lspci debugging help by Pekka
Enberg, and trial patch suggested by Daniel Ritz:
"From the docs available i would _guess_ this thing is really similar
to the 82443BX/82371AB combination. at least the SMBus base address
register is hidden at the very same place (32bit at 0x90 in function
3 of the "south" brigde)"
The dang thing is largely undocumented, but the patch was corroborated
by Asit Mallick:
"I am trying to find the register information. 440MX is an integration of
440BX north-bridge without AGP and PIIX4E (82371EB). PIIX4 quirk
should cover the ACPI and SMBus related I/O registers."
and verified to fix the problem by Alessio.
Cc: Daniel Ritz <daniel.ritz-ml@swissonline.ch>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Dmitry Torokhov <dtor_core@ameritech.net>
Tested-by: Alessio Sangalli <alesan@manoweb.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
ACPI: ACPI_DOCK: Initialize the atomic notifier list
ACPI: acpi_os_allocate() fixes
ACPI: SBS: fix initialization, sem2mutex
ACPI: add 'const' to several ACPI file_operations
ACPI: delete some defaults from ACPI Kconfig
ACPI: "Device `[%s]' is not power manageable" make message debug only
ACPI: ACPI_DOCK Kconfig
Revert "Revert "ACPI: dock driver""
ACPI: acpi_os_get_thread_id() returns current
ACPI: ACPICA 20060707
The pci channel state is currently uninitialized, thus there are two ways
of indicating that "everything's OK": 0 and 1. This is a bit of a burden.
If a devce driver wants to check if the pci channel is in a working or a
disconnected state, the driver writer must perform checks similar to
if((pdev->error_state != 0) &&
(pdev->error_state != pci_channel_io_normal)) {
whatever();
}
which is rather akward. The first check is needed because stuct pci_dev is
inited to all-zeros. The scond is needed because the error recovery will
set the state to pci_channel_io_normal (which is not zero).
This patch fixes this awkwardness.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
It's useful to be able to turn off CONFIG_HOTPLUG for compile-coverage testing
and for section-checking coverage. But a few things go and select
CONFIG_HOTPLUG, making it a royal PITA to turn the thing off.
It's only turnable offable if CONFIG_EMBEDDED anyway. So let's make those
things depend on HOTPLUG, not select it.
Cc: Greg KH <greg@kroah.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
HOTPLUG_PCI_ACPI depends on ACPI_DOCK
ACPI_IBM_DOCK depends on ACPI_DOCK=n
ACPI_DOCK is EXPERIMENTAL, though that doesn't seem to mean much
Signed-off-by: Len Brown <len.brown@intel.com>
* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6:
[PATCH] i386: export memory more than 4G through /proc/iomem
[PATCH] 64bit Resource: finally enable 64bit resource sizes
[PATCH] 64bit Resource: convert a few remaining drivers to use resource_size_t where needed
[PATCH] 64bit resource: change pnp core to use resource_size_t
[PATCH] 64bit resource: change pci core and arch code to use resource_size_t
[PATCH] 64bit resource: change resource core to use resource_size_t
[PATCH] 64bit resource: introduce resource_size_t for the start and end of struct resource
[PATCH] 64bit resource: fix up printks for resources in misc drivers
[PATCH] 64bit resource: fix up printks for resources in arch and core code
[PATCH] 64bit resource: fix up printks for resources in pcmcia drivers
[PATCH] 64bit resource: fix up printks for resources in video drivers
[PATCH] 64bit resource: fix up printks for resources in ide drivers
[PATCH] 64bit resource: fix up printks for resources in mtd drivers
[PATCH] 64bit resource: fix up printks for resources in pci core and hotplug drivers
[PATCH] 64bit resource: fix up printks for resources in networks drivers
[PATCH] 64bit resource: fix up printks for resources in sound drivers
[PATCH] 64bit resource: C99 changes for struct resource declarations
Fixed up trivial conflict in drivers/ide/pci/cmd64x.c (the printk that
was changed by the 64-bit resources had been deleted in the meantime ;)
This patch-queue improves the generic IRQ layer to be truly generic, by adding
various abstractions and features to it, without impacting existing
functionality.
While the queue can be best described as "fix and improve everything in the
generic IRQ layer that we could think of", and thus it consists of many
smaller features and lots of cleanups, the one feature that stands out most is
the new 'irq chip' abstraction.
The irq-chip abstraction is about describing and coding and IRQ controller
driver by mapping its raw hardware capabilities [and quirks, if needed] in a
straightforward way, without having to think about "IRQ flow"
(level/edge/etc.) type of details.
This stands in contrast with the current 'irq-type' model of genirq
architectures, which 'mixes' raw hardware capabilities with 'flow' details.
The patchset supports both types of irq controller designs at once, and
converts i386 and x86_64 to the new irq-chip design.
As a bonus side-effect of the irq-chip approach, chained interrupt controllers
(master/slave PIC constructs, etc.) are now supported by design as well.
The end result of this patchset intends to be simpler architecture-level code
and more consolidation between architectures.
We reused many bits of code and many concepts from Russell King's ARM IRQ
layer, the merging of which was one of the motivations for this patchset.
This patch:
rename desc->handler to desc->chip.
Originally i did not want to do this, because it's a big patch. But having
both "desc->handler", "desc->handle_irq" and "action->handler" caused a
large degree of confusion and made the code appear alot less clean than it
truly is.
I have also attempted a dual approach as well by introducing a
desc->chip alias - but that just wasnt robust enough and broke
frequently.
So lets get over with this quickly. The conversion was done automatically
via scripts and converts all the code in the kernel.
This renaming patch is the first one amongst the patches, so that the
remaining patches can stay flexible and can be merged and split up
without having some big monolithic patch act as a merge barrier.
[akpm@osdl.org: build fix]
[akpm@osdl.org: another build fix]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Dock bridges generally do not implement _SUN, yet show up as ejectable
slots. If you have more than one ejectable slot that does not implement
SUN, with the current code you will get duplicate slot numbers. So, if
there is no _SUN, use the current count of the number of slots found
instead.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Modify the acpiphp driver to use the ACPI dock driver for dock
notifications. Only load the acpiphp driver if we find we have pci dock
devices.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
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>
