A new option, pcie_aspm=force, will force ASPM to be enabled, even on system
with PCIe 1.0 devices.
Signed-off-by: NShaohua Li <shaohua.li@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Disable ASPM on pre-1.1 PCIe devices, as many of them don't implement it
correctly.
Tested-by: NJack Howarth <howarth@bromo.msbb.uc.edu>
Signed-off-by: NShaohua Li <shaohua.li@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

The ACPI FADT table includes an ASPM control bit. If the bit is set, do
not enable ASPM since it may indicate that the platform doesn't actually
support the feature.
Tested-by: NJack Howarth <howarth@bromo.msbb.uc.edu>
Signed-off-by: NShaohua Li <shaohua.li@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

David Vrabel has a device which generates an interrupt storm on the INTx
pin if we disable MSI interrupts altogether.  Masking interrupts is only
a performance optimisation, so we can ignore the request to mask the
interrupt.
Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

If the kernel is configured to support 64-bit resources on a 32-bit
machine, we can support 64-bit BARs properly.  Just change the condition
to check sizeof(resource_size_t) instead of BITS_PER_LONG.
Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Factor out the code to read one BAR from the loop in pci_read_bases into
a new function, __pci_read_base.  The new code is slightly more
readable, better commented and removes the ifdef.
Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

The empty kdoc was causing warnings, so provide some actual documentation.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Comamnd->Command
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

drivers/pci/proc.c:91:3: warning: cast from restricted __le16
drivers/pci/proc.c:100:3: warning: cast from restricted __le32
drivers/pci/proc.c:109:3: warning: cast from restricted __le16
drivers/pci/proc.c:161:40: warning: cast to restricted __le16
drivers/pci/proc.c:170:41: warning: cast to restricted __le32
drivers/pci/proc.c:179:40: warning: cast to restricted __le16
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Make more PCI PM core functionality available to drivers

* Export pci_pme_capable() so that it can be called directly by
  drivers (for example, tg3 needs that).

* Move the state choosing part of pci_prepare_to_sleep() to a
  separate function, pci_target_state(), that can be called directly
  by drivers (for example, tg3 needs that).
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

RMRRs do not necessarily have to be present on all VT-d capable platforms.
The printk is just informational and does not need to be followed by an error
return.
Signed-off-by: NYong Y Wang <yong.y.wang@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: mark gross <mgross@linux.intel.com>
Cc: Keshavamurthy, Anil S <anil.s.keshavamurthy@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Kobjects do not have a limit in name size since a while, so stop
pretending that they do.
Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix kernel-doc comments so that they don't produce errors.
Also cut some extraneous copy-paste text.

Error(linhead//drivers/pci/pci.c:1133): duplicate section name 'Description'
Error(linhead//drivers/pci/pci.c:1189): duplicate section name 'Description'
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Since the second argument of acpi_pci_choose_state() and
platform_pci_choose_state() is never used, remove it.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Acked-by: NPavel Machek <pavel@suse.cz>
Signed-off-by: NLen Brown <len.brown@intel.com>

Get rid of a superfluous acpi_pm_device_sleep_state() parameter.  The
only legitimate value of that parameter must be derived from the first
parameter, which is what all the callers already do.  (However, this
does not address the fact that ACPI still doesn't set up those flags.)
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

Proper memory barriers have been added to order accesses
to ->cmd_busy, so volatile declaration for cmd_busy can
be removed.
Signed-off-by: NMing Lei <tom.leiming@gmail.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

drivers/pci/pci.c needs pm_wakeup.h since it uses device_set_wakup_capable().
The latter also needs to be stubbed out for !CONFIG_PM.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

The recently introduced pci_prepare_to_sleep() needs the following fix,
because there are systems which are not power manageable by ACPI (ie.
ACPI doesn't provide methods to put the device into low power states and
back), but require ACPI hooks to be executed for wake-up to work.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

gart.h has only GART-specific stuff. Only GART code needs it. Other
IOMMU stuff should include iommu.h instead of gart.h.
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Acked-by: NMuli Ben-Yehuda <muli@il.ibm.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

add early init quirks for VisWS. This gradually turns the VISWS subarch
into a generic PC architecture.
Signed-off-by: NIngo Molnar <mingo@elte.hu>

first step: make the VISWS subarch boot on a regular PC.

We take various shortcuts for that. We copy the generic arch setup file over
into the VISWS setup file.

This is the only step that is not expected to boot on a real VISWS.
Signed-off-by: NIngo Molnar <mingo@elte.hu>

want to remove arch_get_ram_range, and use early_node_map instead.
Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

If the offset of PCI device's PM capability in its configuration space,
the mask of states that the device supports PME# from and the D1 and D2
support bits are cached in the corresponding struct pci_dev, the PCI
device PM code can be simplified quite a bit.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Introduce functions pci_prepare_to_sleep() and pci_back_from_sleep(),
to be used by the PCI drivers that want to place their devices into
the lowest power state appropiate for them (PCI_D3hot, if the device
is not supposed to wake up the system, or the deepest state from
which the wake-up is possible, otherwise) while the system is being
prepared to go into a sleeping state and to put them back into D0
during the subsequent transition to the working state.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

* Introduce function acpi_pm_device_sleep_wake() for enabling and
  disabling the system wake-up capability of devices that are power
  manageable by ACPI.

* Introduce function acpi_bus_can_wakeup() allowing other (dependent)
  subsystems to check if ACPI is able to enable the system wake-up
  capability of given device.

* Introduce callback .sleep_wake() in struct pci_platform_pm_ops and
  for the ACPI PCI 'driver' make it use acpi_pm_device_sleep_wake().

* Introduce callback .can_wakeup() in struct pci_platform_pm_ops and
  for the ACPI 'driver' make it use acpi_bus_can_wakeup().

* Move the PME# handlig code out of pci_enable_wake() and split it
  into two functions, pci_pme_capable() and pci_pme_active(),
  allowing the caller to check if given device is capable of
  generating PME# from given power state and to enable/disable the
  device's PME# functionality, respectively.

* Modify pci_enable_wake() to use the new ACPI callbacks and the new
  PME#-related functions.

* Drop the generic .platform_enable_wakeup() callback that is not
  used any more.

* Introduce device_set_wakeup_capable() that will set the
  power.can_wakeup flag of given device.

* Rework PCI device PM initialization so that, if given device is
  capable of generating wake-up events, either natively through the
  PME# mechanism, or with the help of the platform, its
  power.can_wakeup flag is set and its power.should_wakeup flag is
  unset as appropriate.

* Make ACPI set the power.can_wakeup flag for devices found to be
  wake-up capable by it.

* Make the ACPI wake-up code enable/disable GPEs for devices that
  have the wakeup.flags.prepared flag set (which means that their
  wake-up power has been enabled).
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Rework pci_set_power_state() so that the platform callback is
invoked before the native mechanism, if necessary.  Also, make
the function check if the device is power manageable by the
platform before invoking the platform callback.

This may matter if the device dependent on additional power
resources controlled by the platform is being put into D0, in which
case those power resources must be turned on before we attempt to
handle the device itself.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NPavel Machek <pavel@suse.cz>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Introduce function pointer platform_pci_power_manageable to be used
by the platform-related code to point to a function allowing us to
check if given device is power manageable by the platform.

Introduce acpi_pci_power_manageable() playing that role for ACPI.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

It seems VT3336 can't do msi either as with its bro 3351.  Disable it.
Reported in the following SUSE bug.

  https://bugzilla.novell.com/show_bug.cgi?id=300001Signed-off-by: NTejun Heo <tj@kernel.org>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This changes pci_setup_device to handle pci_name() now returning a
constant string.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

During the development of the physical PCI slot patch series, Gary Hade
kept on reporting strange oopses due to interactions between pci_slot
and acpiphp.

	http://lkml.org/lkml/2007/11/28/319

find_root_bridges() unconditionally installs
handle_hotplug_event_bridge() as an ACPI_SYSTEM_NOTIFY handler for all
root bridges.

However, during module cleanup, remove_bridge() will only remove the
notify handler iff the root bridge had a hot-pluggable slot directly
underneath. That is:

	root bridge -> hotplug slot

But, if the topology looks like either of the following:

	root bridge -> non-hotplug slot
	root bridge -> p2p bridge -> hotplug slot

Then we currently do not remove the notify handler from that root
bridge.

This can cause a kernel oops if we modprobe acpiphp later and it gets
loaded somewhere else in memory. If the root bridge then receives a
hotplug event, it will then attempt to call a stale, non-existent notify
handler and we blow up.

Much thanks goes to Gary Hade for his persistent debugging efforts.
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NGary Hade <garyhade@us.ibm.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

For Broadcom 5706, 5708, 5709 rev. A nics, any read beyond the
VPD end tag will hang the device.  This problem was initially
observed when a vpd entry was created in sysfs
('/sys/bus/pci/devices/<id>/vpd').   A read to this sysfs entry
will dump 32k of data.  Reading a full 32k will cause an access
beyond the VPD end tag causing the device to hang.  Once the device
is hung, the bnx2 driver will not be able to reset the device.
We believe that it is legal to read beyond the end tag and
therefore the solution is to limit the read/write length.

A majority of this patch is from Matthew Wilcox who gave code for
reworking the PCI vpd size information.  A PCI quirk added for the
Broadcom NIC's to limit the read/write's.
Signed-off-by: NBenjamin Li <benli@broadcom.com>
Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Some PCI devices will lock up if we attempt to read from VPD addresses
beyond some device-dependent limit.  Until we can identify these
devices and adjust the file size accordingly, only let root read VPD
through sysfs to prevent a DoS by normal users.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This patch is the minimal amount of code needed to support
wake-on-lan in platform mode properly (i.e. "ethtool -s eth0 wol g"
is sufficient, no additional magic needed) for me.

This is derived from David Brownells patch
(http://lists.laptop.org/pipermail/devel/2007-April/004691.html).
However I decided to move the hook into pci-acpi.c since the other
two pci hooks also live there and pci and acpi are the only users of
the platform_enable_wakeup-hook.

As a 'side-effect' this also makes wake on usb activity work for me
and I had to disable usb wakeup (which is enabled by default) using
the power/wakeup sysfs functionality ("echo disabled >
${sysfs_path_to_device}/power/wakeup").

(BTW I first thought the 'immediate reboot because of usb wake' effect is
caused by the optical mouse generating a wake event, but it rather
seems to be a problem with a flaky secondary usb host controller,
which sees a connected device where nothing is attached)
Signed-off-by: NTobias Diedrich <ranma+kernel@tdiedrich.de>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Make pci_setup_device() write the bus ID directly into the allotted storage,
rather than using pci_name() as the address as that now returns a const
pointer.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Current pciehp driver saves its private data pointer into pci_dev
structure using pci_set_drvdata()/pci_get_drvdata(). But because
pciehp is not a pci device driver but a PCI Express service driver, it
should save its private data pointer into pcie_device structure using
set_service_data()/get_service_data().
Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Currently, pciehp driver enables command completed interrupt as follows.

(1) Don't enable at initialization.
(2) Enable command completed interrupt whenever pciehp issues a
    command, if the command doesn't attempt to disable the interrupt.
(3) Disable command completed interrupt at driver unloading.

Once we enable command completed interrupt, we don't need to re-enable
it for every command. So we can simplify above steps as follows:

(1) Enable command completed interrupt at initialization.
(2) No special sequence for command completed interrupt.
(3) Disable command completed interrupt at driver unloading.
Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Current pciehp driver's intialization sequence is as follows:

(1) initialize controller data structure
(2) install interrupt handler
(3) enable software notification
(4) initialize controller specific slot data structure
(5) initialize generic slot data structure and register it to pci hotplug core

The interrupt handler of pciehp assumes that controller specific slot
data structure is already initialized. However, it is installed at (2)
before initializing controller specific slot data structure at
(4). Because of this, pciehp driver cannot handle the following cases
properly.

- If devices that shares IRQ with pciehp raise interrupts between (2) and (4).
- If hotplug events (e.g. MRL open) happen between (3) and (4).

We already have a workaround for this problem ("pciehp: fix NULL
dereference in interrupt handler: dbd79aed).
But we still need fundamental fix.

This patch fix the problem by changing the initilization sequence as follows:

(1) initialize controller data structure
(2) initialize controller specific slot data structure
(3) install interrupt handler
(4) enable software notification
(5) initialize generic slot data structure and register it to pci hotplug core
Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Acked-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

If pci_request_region fails, make the warning include the resource number,
not the resource number + 1.

Convert printks to use dev_printk().
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Convert printks to use dev_printk().
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>