1
0
mirror of https://github.com/torvalds/linux.git synced 2024-12-23 11:21:33 +00:00
Commit Graph

2304 Commits

Author SHA1 Message Date
Andrew Morton
df08cdc7ef drivers/pci/intel-iommu.c: fix build with older gcc's
drivers/pci/intel-iommu.c: In function `__iommu_calculate_agaw':
drivers/pci/intel-iommu.c:437: sorry, unimplemented: inlining failed in call to 'width_to_agaw': function body not available
drivers/pci/intel-iommu.c:445: sorry, unimplemented: called from here

Move the offending function (and its siblings) to top-of-file, remove the
forward declaration.

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=17441

Reported-by: Martin Mokrejs <mmokrejs@ribosome.natur.cuni.cz>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-09-22 17:22:39 -07:00
Linus Torvalds
d56557af19 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6:
  PCI: bus speed strings should be const
  PCI hotplug: Fix build with CONFIG_ACPI unset
  PCI: PCIe: Remove the port driver module exit routine
  PCI: PCIe: Move PCIe PME code to the pcie directory
  PCI: PCIe: Disable PCIe port services during port initialization
  PCI: PCIe: Ask BIOS for control of all native services at once
  ACPI/PCI: Negotiate _OSC control bits before requesting them
  ACPI/PCI: Do not preserve _OSC control bits returned by a query
  ACPI/PCI: Make acpi_pci_query_osc() return control bits
  ACPI/PCI: Reorder checks in acpi_pci_osc_control_set()
  PCI: PCIe: Introduce commad line switch for disabling port services
  PCI: PCIe AER: Introduce pci_aer_available()
  x86/PCI: only define pci_domain_nr if PCI and PCI_DOMAINS are set
  PCI: provide stub pci_domain_nr function for !CONFIG_PCI configs
2010-09-07 16:00:17 -07:00
Stephen Hemminger
17134d9673 PCI: bus speed strings should be const
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-08-31 15:28:00 -07:00
Rafael J. Wysocki
6e63e80d88 PCI hotplug: Fix build with CONFIG_ACPI unset
One of the recent changes caused complilation of
drivers/pci/hotplug/pciehp_core.c to fail.  Fix this issue.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-08-25 12:54:03 -07:00
Kenji Kaneshige
a9d2a6df11 PCI: PCIe: Remove the port driver module exit routine
The PCIe port driver's module exit routine is never used, so drop it.

Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-08-24 13:47:49 -07:00
Rafael J. Wysocki
271fb719cc PCI: PCIe: Move PCIe PME code to the pcie directory
The PCIe PME code only consists of one file, so it doesn't need to
occupy its own directory.  Move it to drivers/pci/pcie/pme.c and
remove the contents of drivers/pci/pcie/pme .

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-08-24 13:47:48 -07:00
Rafael J. Wysocki
2bd50dd800 PCI: PCIe: Disable PCIe port services during port initialization
In principle PCIe port services may be enabled by the BIOS, so it's
better to disable them during port initialization to avoid spurious
events from being generated.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-08-24 13:47:47 -07:00
Rafael J. Wysocki
28eb5f274a PCI: PCIe: Ask BIOS for control of all native services at once
After commit 852972acff (ACPI: Disable
ASPM if the platform won't provide _OSC control for PCIe) control of
the PCIe Capability Structure is unconditionally requested by
acpi_pci_root_add(), which in principle may cause problems to
happen in two ways.  First, the BIOS may refuse to give control of
the PCIe Capability Structure if it is not asked for any of the
_OSC features depending on it at the same time.  Second, the BIOS may
assume that control of the _OSC features depending on the PCIe
Capability Structure will be requested in the future and may behave
incorrectly if that doesn't happen.  For this reason, control of
the PCIe Capability Structure should always be requested along with
control of any other _OSC features that may depend on it (ie. PCIe
native PME, PCIe native hot-plug, PCIe AER).

Rework the PCIe port driver so that (1) it checks which native PCIe
port services can be enabled, according to the BIOS, and (2) it
requests control of all these services simultaneously.  In
particular, this causes pcie_portdrv_probe() to fail if the BIOS
refuses to grant control of the PCIe Capability Structure, which
means that no native PCIe port services can be enabled for the PCIe
Root Complex the given port belongs to.  If that happens, ASPM is
disabled to avoid problems with mishandling it by the part of the
PCIe hierarchy for which control of the PCIe Capability Structure
has not been received.

Make it possible to override this behavior using 'pcie_ports=native'
(use the PCIe native services regardless of the BIOS response to the
control request), or 'pcie_ports=compat' (do not use the PCIe native
services at all).

Accordingly, rework the existing PCIe port service drivers so that
they don't request control of the services directly.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-08-24 13:47:33 -07:00
Rafael J. Wysocki
75fb60f26b ACPI/PCI: Negotiate _OSC control bits before requesting them
It is possible that the BIOS will not grant control of all _OSC
features requested via acpi_pci_osc_control_set(), so it is
recommended to negotiate the final set of _OSC features with the
query flag set before calling _OSC to request control of these
features.

To implement it, rework acpi_pci_osc_control_set() so that the caller
can specify the mask of _OSC control bits to negotiate and the mask
of _OSC control bits that are absolutely necessary to it.  Then,
acpi_pci_osc_control_set() will run _OSC queries in a loop until
the mask of _OSC control bits returned by the BIOS is equal to the
mask passed to it.  Also, before running the _OSC request
acpi_pci_osc_control_set() will check if the caller's required
control bits are present in the final mask.

Using this mechanism we will be able to avoid situations in which the
BIOS doesn't grant control of certain _OSC features, because they
depend on some other _OSC features that have not been requested.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-08-24 13:44:40 -07:00
Rafael J. Wysocki
79dd9182db PCI: PCIe: Introduce commad line switch for disabling port services
Introduce kernel command line switch pcie_ports= allowing one to
disable all of the native PCIe port services, so that PCIe ports
are treated like PCI-to-PCI bridges.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-08-24 13:43:15 -07:00
Rafael J. Wysocki
f1a7bfaf6b PCI: PCIe AER: Introduce pci_aer_available()
Introduce a function allowing the caller to check whether to try to
enable PCIe AER.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-08-24 13:43:08 -07:00
Linus Torvalds
e2e96c6636 Merge git://git.infradead.org/iommu-2.6
* git://git.infradead.org/iommu-2.6:
  intel-iommu: Fix 32-bit build warning with __cmpxchg()
  intr-remap: allow disabling source id checking
2010-08-15 17:34:20 -07:00
Linus Torvalds
dcded10f6d Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx
* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx: (30 commits)
  DMAENGINE: at_hdmac: locking fixlet
  DMAENGINE: pch_dma: kill another usage of __raw_{read|write}l
  dma: dmatest: fix potential sign bug
  ioat2: catch and recover from broken vtd configurations v6
  DMAENGINE: add runtime slave control to COH 901 318 v3
  DMAENGINE: add runtime slave config to DMA40 v3
  DMAENGINE: generic slave channel control v3
  dmaengine: Driver for Topcliff PCH DMA controller
  intel_mid: Add Mrst & Mfld DMA Drivers
  drivers/dma: Eliminate a NULL pointer dereference
  dma/timb_dma: compile warning on 32 bit
  DMAENGINE: ste_dma40: support older silicon
  DMAENGINE: ste_dma40: support disabling physical channels
  DMAENGINE: ste_dma40: no disabled phy channels on ux500
  DMAENGINE: ste_dma40: fix suspend bug
  DMAENGINE: ste_dma40: add DB8500 memcpy channels
  DMAENGINE: ste_dma40: no flow control on memcpy
  DMAENGINE: ste_dma40: arch updates for LCLA and LCPA
  DMAENGINE: ste_dma40: allocate LCLA dynamically
  DMAENGINE: ste_dma40: no premature stop
  ...

Fix up trivial conflicts in arch/arm/mach-ux500/devices-db8500.c
2010-08-09 21:00:07 -07:00
David Woodhouse
1a8bd481bf intel-iommu: Fix 32-bit build warning with __cmpxchg()
drivers/pci/intel-iommu.c: In function 'dma_pte_addr':
drivers/pci/intel-iommu.c:239: warning: passing argument 1 of '__cmpxchg64' from incompatible pointer type

It seems that __cmpxchg64() now cares about the type of its pointer argument,
so give it a (uint64_t *) instead of a pointer to a structure which contains
only that.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2010-08-10 01:38:53 +01:00
Chris Wright
d1423d5679 intr-remap: allow disabling source id checking
Allow disabling the source id checking while programming the interrupt
remap table entry. Useful for debugging or working around the broken
source id checks on some platforms.

Signed-off-by: Chris Wright <chrisw@redhat.com>
Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>
Acked-by: Weidong Han <weidong.han@intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2010-08-10 01:37:09 +01:00
Linus Torvalds
9e50ab91d0 Merge branch 'acpica' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6
* 'acpica' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (27 commits)
  ACPI / ACPICA: Simplify acpi_ev_initialize_gpe_block()
  ACPI / ACPICA: Fail acpi_gpe_wakeup() if ACPI_GPE_CAN_WAKE is unset
  ACPI / ACPICA: Do not execute _PRW methods during initialization
  ACPI: Fix bogus GPE test in acpi_bus_set_run_wake_flags()
  ACPICA: Update version to 20100702
  ACPICA: Fix for Alias references within Package objects
  ACPICA: Fix lint warning for 64-bit constant
  ACPICA: Remove obsolete GPE function
  ACPICA: Update debug output components
  ACPICA: Add support for WDDT - Watchdog Descriptor Table
  ACPICA: Drop acpi_set_gpe
  ACPICA: Use low-level GPE enable during GPE block initialization
  ACPI / EC: Do not use acpi_set_gpe
  ACPI / EC: Drop suspend and resume routines
  ACPICA: Remove wakeup GPE reference counting which is not used
  ACPICA: Introduce acpi_gpe_wakeup()
  ACPICA: Rename acpi_hw_gpe_register_bit
  ACPICA: Update version to 20100528
  ACPICA: Add signatures for undefined tables: ATKG, GSCI, IEIT
  ACPICA: Optimization: Reduce the number of namespace walks
  ...
2010-08-07 17:08:30 -07:00
Linus Torvalds
1cfd2bda8c Merge branch 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6
* 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: (30 commits)
  PCI: update for owner removal from struct device_attribute
  PCI: Fix warnings when CONFIG_DMI unset
  PCI: Do not run NVidia quirks related to MSI with MSI disabled
  x86/PCI: use for_each_pci_dev()
  PCI: use for_each_pci_dev()
  PCI: MSI: Restore read_msi_msg_desc(); add get_cached_msi_msg_desc()
  PCI: export SMBIOS provided firmware instance and label to sysfs
  PCI: Allow read/write access to sysfs I/O port resources
  x86/PCI: use host bridge _CRS info on ASRock ALiveSATA2-GLAN
  PCI: remove unused HAVE_ARCH_PCI_SET_DMA_MAX_SEGMENT_{SIZE|BOUNDARY}
  PCI: disable mmio during bar sizing
  PCI: MSI: Remove unsafe and unnecessary hardware access
  PCI: Default PCIe ASPM control to on and require !EMBEDDED to disable
  PCI: kernel oops on access to pci proc file while hot-removal
  PCI: pci-sysfs: remove casts from void*
  ACPI: Disable ASPM if the platform won't provide _OSC control for PCIe
  PCI hotplug: make sure child bridges are enabled at hotplug time
  PCI hotplug: shpchp: Removed check for hotplug of display devices
  PCI hotplug: pciehp: Fixed return value sign for pciehp_unconfigure_device
  PCI: Don't enable aspm before drivers have had a chance to veto it
  ...
2010-08-06 11:44:36 -07:00
Linus Torvalds
c513b67e68 pci: fix type warnings in intr_remapping.c
Commit 69309a0590 ("x86, asm: Clean up and simplify set_64bit()")
sanitized the x86-64 types to set_64bit(), and incidentally resulted in
warnings like

 drivers/pci/intr_remapping.c: In function 'modify_irte':
 drivers/pci/intr_remapping.c:314: warning: passing argument 1 of 'set_64bit' from incompatible pointer type
 arch/x86/include/asm/cmpxchg_64.h:6: note:expected 'volatile u64 *' but argument is of type 'long unsigned int *'

It turns out that the change to set_64bit() really does clean up things,
and the PCI intr_remapping.c file did a rather ugly cast in order to
avoid warnings with the previous set_64bit() type model.

Removing the ugly cast fixes the warning, and makes everybody happy and
expects a set_64bit() to take the logical "u64 *" argument.

Pointed-out-by: Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-06 11:02:31 -07:00
Linus Torvalds
cc77b4db00 Merge branch 'core-iommu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
* 'core-iommu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  x86/amd-iommu: Export cache-coherency capability
  iommu-api: Extension to check for interrupt remapping
  x86/amd-iommu: Use for_each_pci_dev()
2010-08-06 09:22:39 -07:00
Linus Torvalds
132a4edb2b Merge branch 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
  sata_fsl,mv,nv: prepare for NCQ command completion update
  ata: Convert pci_table entries to PCI_VDEVICE (if PCI_ANY_ID is used)
  libata: more PCI IDs for jmicron controllers
  ata_piix: fix locking around SIDPR access
  [libata] update blacklist for new hyphenated pattern ranges (v2)
  libata: allow hyphenated pattern ranges
  ata_generic: drop hard coded DMA force logic for CENATEK
  [libata] ahci: Fix warning: comparison between 'enum <anonymous>' and 'enum <anonymous>'
  [libata] add ATA_CMD_DSM to ata_get_cmd_descript
  [libata] Add Samsung PATA controller driver, pata_samsung_cf
  [libata] Add 460EX on-chip SATA driver, sata_dwc_460ex
  libata: reduce blacklist size even more (v2)
  libata: reduce blacklist size (v2)
  libata: glob_match for ata_device_blacklist (v2)
  ahci_platform: Remove unneeded ahci_driver.probe assignment
  ahci_platform: Provide for vendor specific init
2010-08-06 09:20:19 -07:00
Stephen Rothwell
763e9db999 PCI: update for owner removal from struct device_attribute
Fixes the build.

Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-08-04 14:23:55 -07:00
Dan Williams
556ab45f9a ioat2: catch and recover from broken vtd configurations v6
On some platforms (MacPro3,1) the BIOS assigns the ioatdma device to the
incorrect iommu causing faults when the driver initializes.  Add a quirk
to catch this misconfiguration and try falling back to untranslated
operation (which works in the MacPro3,1 case).

Assuming there are other platforms with misconfigured iommus teach the
ioatdma driver to treat initialization failures as non-fatal (just fail
the driver load and emit a warning instead of triggering a BUG_ON).

This can be classified as a boot regression since 2.6.32 on affected
platforms since the ioatdma module did not autoload prior to that
kernel.

Cc: <stable@kernel.org>
Acked-by: David Woodhouse <David.Woodhouse@intel.com>
Reported-by: Chris Li <lkml@chrisli.org>
Tested-by: Chris Li <lkml@chrisli.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2010-08-04 14:18:17 -07:00
Narendra K
b879743f26 PCI: Fix warnings when CONFIG_DMI unset
This patch fixes the below warnings introduced by the commit
911e1c9b05 ("PCI:
export SMBIOS provided firmware instance and label to sysfs").

drivers/pci/pci.h: In function ‘pci_create_firmware_label_files’:
drivers/pci/pci.h:16: warning: ‘return’ with a value, in function returning void
drivers/pci/pci.h: In function ‘pci_remove_firmware_label_files’:
drivers/pci/pci.h:18: warning: ‘return’ with a value, in function returning void

The warnings are seen because of the below code, doing a retun 0
from the functions 'pci_create_firmware_label_files' and
'pci_remove_firmware_label_files' defined as void.

+#ifndef CONFIG_DMI
+static inline void pci_create_firmware_label_files(struct pci_dev *pdev)
+{ return 0; }
+static inline void pci_remove_firmware_label_files(struct pci_dev *pdev)
+{ return 0; }

Signed-off-by: Narendra K <narendra_k@dell.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-08-02 09:11:10 -07:00
Tejun Heo
5b6ae5ba0c libata: more PCI IDs for jmicron controllers
Add support for JMB364 and 369.

Patch-originally-from: Aries Lee <arieslee@jmicron.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2010-08-01 19:46:44 -04:00
Rafael J. Wysocki
3d2a531804 PCI: Do not run NVidia quirks related to MSI with MSI disabled
There is no reason to run NVidia-specific quirks related to HT MSI
mappings with MSI disabled via pci=nomsi, so make
__nv_msi_ht_cap_quirk() return immediately in that case.

This allows at least one machine to boot 100% of the time with
pci=nomsi (it still doesn't boot reliably without that).

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16443 .

Cc: stable@kernel.org
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-30 09:47:58 -07:00
Kulikov Vasiliy
4e344b1cc5 PCI: use for_each_pci_dev()
Use for_each_pci_dev() to simplify the code.

Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-30 09:47:22 -07:00
Ben Hutchings
30da552428 PCI: MSI: Restore read_msi_msg_desc(); add get_cached_msi_msg_desc()
commit 2ca1af9aa3285c6a5f103ed31ad09f7399fc65d7 "PCI: MSI: Remove
unsafe and unnecessary hardware access" changed read_msi_msg_desc() to
return the last MSI message written instead of reading it from the
device, since it may be called while the device is in a reduced
power state.

However, the pSeries platform code really does need to read messages
from the device, since they are initially written by firmware.
Therefore:
- Restore the previous behaviour of read_msi_msg_desc()
- Add new functions get_cached_msi_msg{,_desc}() which return the
  last MSI message written
- Use the new functions where appropriate

Acked-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-30 09:41:39 -07:00
Narendra K
911e1c9b05 PCI: export SMBIOS provided firmware instance and label to sysfs
This patch exports SMBIOS provided firmware instance and label of
onboard PCI devices to sysfs.  New files are:
  /sys/bus/pci/devices/.../label which contains the firmware name for
the device in question, and
  /sys/bus/pci/devices/.../index which contains the firmware device type
instance for the given device.

Signed-off-by: Jordan Hargrave <jordan_hargrave@dell.com>
Signed-off-by: Narendra K <narendra_k@dell.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-30 09:36:01 -07:00
Alex Williamson
8633328be2 PCI: Allow read/write access to sysfs I/O port resources
PCI sysfs resource files currently only allow mmap'ing.  On x86 this
works fine for memory backed BARs, but doesn't work at all for I/O
port backed BARs.  Add read/write to I/O port PCI sysfs resource
files to allow userspace access to these device regions.

Acked-by: Chris Wright <chrisw@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-30 09:32:08 -07:00
FUJITA Tomonori
bfb51cd016 PCI: remove unused HAVE_ARCH_PCI_SET_DMA_MAX_SEGMENT_{SIZE|BOUNDARY}
In 2.6.34, we transformed the PCI DMA API into the generic device
mode. The PCI DMA API is just the wrapper of the DMA API.

So we don't need HAVE_ARCH_PCI_SET_DMA_MAX_SEGMENT_SIZE or
HAVE_ARCH_PCI_SET_DMA_SEGMENT_BOUNDARY (which enable architectures to
have the own implementations). Both haven't been used anyway.

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-30 09:29:36 -07:00
Jacob Pan
253d2e5498 PCI: disable mmio during bar sizing
It is a known issue that mmio decoding shall be disabled while doing PCI
bar sizing. Host bridge and other devices (PCI PIC) shall be excluded for
certain platforms. This patch mainly comes from Mathew Willcox's
patch in http://kerneltrap.org/mailarchive/linux-kernel/2007/9/13/258969.

A new flag bit "mmio_alway_on" is added to pci_dev with the intention that
devices with their mmio decoding cannot be disabled during BAR sizing shall
have this bit set, preferrablly in their quirks.

Without this patch, Intel Moorestown platform graphics unit will be
corrupted during bar sizing activities.

Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-30 09:29:35 -07:00
Ben Hutchings
fcd097f31a PCI: MSI: Remove unsafe and unnecessary hardware access
During suspend on an SMP system, {read,write}_msi_msg_desc() may be
called to mask and unmask interrupts on a device that is already in a
reduced power state.  At this point memory-mapped registers including
MSI-X tables are not accessible, and config space may not be fully
functional either.

While a device is in a reduced power state its interrupts are
effectively masked and its MSI(-X) state will be restored when it is
brought back to D0.  Therefore these functions can simply read and
write msi_desc::msg for devices not in D0.

Further, read_msi_msg_desc() should only ever be used to update a
previously written message, so it can always read msi_desc::msg
and never needs to touch the hardware.

Tested-by: "Michael Chan" <mchan@broadcom.com>
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-30 09:29:34 -07:00
Matthew Garrett
ea5f9fc589 PCI: Default PCIe ASPM control to on and require !EMBEDDED to disable
The CONFIG_PCIEASPM option is confusing and potentially dangerous. ASPM is
a hardware mediated feature rather than one under direct OS control, and
even if the config option is disabled the system firmware may have turned
on ASPM on various bits of hardware. This can cause problems later -
various hardware that claims to support ASPM does a poor job of it and may
hang or cause other difficulties. The kernel is able to recognise this in
many cases and disable the ASPM functionality, but only if CONFIG_PCIEASPM
is enabled.

Given that in its default configuration this option will either leave the
hardware as it was originally or disable hardware functionality that may
cause problems, it should by default y. The only reason to disable it
ought to be to reduce code size, so make it dependent on CONFIG_EMBEDDED.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: lrodriguez@atheros.com
Cc: maximlevitsky@gmail.com
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-30 09:29:34 -07:00
Kenji Kaneshige
8cc2bfd87f PCI: kernel oops on access to pci proc file while hot-removal
I encountered the problem that /proc/bus/pci/XX/YY is not removed even
after the corresponding device is hot-removed, if the file is still
being opened. In addtion, accessing this file in this situation causes
kernel panic (see below).

Becasue the pci_proc_detach_device() doesn't call remove_proc_entry()
if struct proc_dir_entry->count > 1, access to /proc/bus/pci/XX/YY
would refer to struct pci_dev that was already freed.

Though I don't know why the check for proc_dir_entry->count was added,
I don't think it is needed. Removing this check fixes the problem.

Steps to reproduce
------------------
# cd /sys/bus/pci/slots/2/
# PROC_BUS_PCI_FILE=/proc/bus/pci/`awk -F: '{print $2"/"$3}' < address`.0
# sleep 10000 < $PROC_BUS_PCI_FILE &
# echo 0 > power
# while true; do cat $PROC_BUS_PCI_FILE > /dev/null; done

Oops Messages
-------------
BUG: unable to handle kernel NULL pointer dereference at 00000042
IP: [<c05c82d5>] pci_user_read_config_dword+0x65/0xa0
*pdpt = 000000002185e001 *pde = 0000000476a79067
Oops: 0000 [] SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:1c.0/0000:10:00.0/local_cpus
Modules linked in: autofs4 sunrpc cpufreq_ondemand acpi_cpufreq ipv6 dm_mirror dm_region_hash dm_log dm_mod e1000e i2c_i801 i2c_core iTCO_wdt igb sg pcspkr dca iTCO_vendor_support ext4 mbcache jbd2 sd_mod crc_t10dif lpfc mptsas scsi_transport_fc mptscsih mptbase scsi_tgt scsi_transport_sas [last unloaded: microcode]

Pid: 2997, comm: cat Not tainted 2.6.34-kk  SB/PRIMEQUEST 1800E
EIP: 0060:[<c05c82d5>] EFLAGS: 00010046 CPU: 19
EIP is at pci_user_read_config_dword+0x65/0xa0
EAX: 00000002 EBX: e44f1800 ECX: e144df14 EDX: 155668c7
ESI: 00000087 EDI: 00000000 EBP: e144df40 ESP: e144df0c
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process cat (pid: 2997, ti=e144c000 task=e26f2570 task.ti=e144c000)
Stack:
 c09ceac0 c0570f72 ffffffff 08c57000 00000000 00001000 e44f1800 c05d2404
<0> e144df40 00001000 00000000 00001000 08c57000 3093ae50 e420cb40 e358d5c0
<0> c05d2300 fffffffb c054984f e144df9c 00008000 08c57000 e358d5c0 00008000
Call Trace:
 [<c0570f72>] ? security_capable+0x22/0x30
 [<c05d2404>] ? proc_bus_pci_read+0x104/0x220
 [<c05d2300>] ? proc_bus_pci_read+0x0/0x220
 [<c054984f>] ? proc_reg_read+0x5f/0x90
 [<c05497f0>] ? proc_reg_read+0x0/0x90
 [<c050694d>] ? vfs_read+0x9d/0x190
 [<c04958f4>] ? audit_syscall_entry+0x204/0x230
 [<c0506a81>] ? sys_read+0x41/0x70
 [<c0402f1f>] ? sysenter_do_call+0x12/0x28
Code: b4 26 00 00 00 00 b8 20 88 b1 c0 c7 44 24 08 ff ff ff ff e8 3e 52 22 00 f6 83 24 04 00 00 20 75 34 8b 43 08 8d 4c 24 08 8b 53 1c <8b> 70 40 89 4c 24 04 89 f9 c7 04 24 04 00 00 00 ff 16 89 c6 f0
EIP: [<c05c82d5>] pci_user_read_config_dword+0x65/0xa0 SS:ESP 0068:e144df0c
CR2: 0000000000000042

Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-30 09:29:33 -07:00
Kulikov Vasiliy
a3f5835a8e PCI: pci-sysfs: remove casts from void*
Remove unnesessary casts from void*.

Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-30 09:29:18 -07:00
Yinghai Lu
3f579c340f PCI hotplug: make sure child bridges are enabled at hotplug time
Found one PCIe Module with several bridges built-in where a "cold"
hotadd doesn't work.

If we end up reassigning bridge windows at hotadd time, and have to loop
through assigning new ranges, we won't end up enabling the child bridges
because the first assignment pass already tried to enable them, which
prevents __pci_bridge_assign_resource from updating the windows.

So try to move enabling of child bridges to the end, and only do it
once.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-30 09:29:16 -07:00
Praveen Kalamegham
0ba10bc752 PCI hotplug: shpchp: Removed check for hotplug of display devices
Removed check to prevent hotplug of display devices within shpchp.
Originally this was thought to have been required within the PCI
Hotplug specification for some legacy devices.  However there is
no such requirement in the most recent revision. The check prevents
hotplug of not only display devices but also computational GPUs
which require serviceability.

Signed-off-by: Praveen Kalamegham <praveen@nextio.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-30 09:29:16 -07:00
Praveen Kalamegham
01b666df48 PCI hotplug: pciehp: Fixed return value sign for pciehp_unconfigure_device
pciehp_unconfigure_device() should return -EINVAL, not EINVAL.

Signed-off-by: Praveen Kalamegham <praveen@nextio.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-30 09:29:15 -07:00
Matthew Garrett
41cd766b06 PCI: Don't enable aspm before drivers have had a chance to veto it
The aspm code will currently set the configured aspm policy before drivers
have had an opportunity to indicate that their hardware doesn't support it.
Unfortunately, putting some hardware in L0 or L1 can result in the hardware
no longer responding to any requests, even after aspm is disabled. It makes
more sense to leave aspm policy at the BIOS defaults at initial setup time,
reconfiguring it after pci_enable_device() is called. This allows the
driver to blacklist individual devices beforehand.

Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-30 09:29:15 -07:00
Kenji Kaneshige
4302e0fb7f PCI: fix wrong memory address handling in MSI-X
Use resource_size_t for MMIO address instead of unsigned long. Otherwise,
higher 32-bits of MMIO address are cleared unexpectedly in x86-32 PAE.

Acked-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-30 09:29:14 -07:00
Junchang Wang
2eb5ebd366 PCI: check return value of pci_enable_device() when enabling bridges
pci_enable_device can fail. In that case, a printed warning would be
more appropriate.

Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Signed-off-by: Junchang Wang <junchangwang@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-30 09:29:14 -07:00
Stephen Hemminger
7736a05a32 PCI: sparse warning (trivial)
Assigning zero where NULL should be used.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-30 09:29:13 -07:00
Tejun Heo
549e15611b PCI: disable MSI on VIA K8M800
MSI delivery from on-board ahci controller doesn't work on K8M800.  At
this point, it's unclear whether the culprit is with the ahci
controller or the host bridge.  Given the track record and considering
the rather minimal impact of MSI, disabling it seems reasonable.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Rainer Hurtado Navarro <publio.escipion.el.africano@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-30 09:29:12 -07:00
Clemens Ladisch
aff6136974 PCI quirk: AMD 780: work around wrong vendor ID on APC bridge
In all AMD 780 family northbridges, the vendor ID of the internal
graphics PCI/PCI bridge reads not as AMD but as that of the mainboard
vendor, because the hardware actually returns the value of the subsystem
vendor ID (erratum 18).

We currently have additional quirk entries for Asus and Acer, but it is
likely that we will encounter more systems with other vendor IDs.

Since we do not know in advance all possible vendor IDs, a better way to
find the device is to declare the quirk on the host bridge, whose ID is
always correct, and use that device as a stepping stone to find the PCI/
PCI bridge, if present.

Reviewed-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-30 09:29:11 -07:00
Dan Carpenter
3b8fdb759e PCI: hotplug/shpchp_hpc: add parenthesis in SLOT_REG_RSVDZ_MASK
The SLOT_REG_RSVDZ_MASK macro is normally used like this:
	slot_reg &= ~SLOT_REG_RSVDZ_MASK;
The ~ operator has higher precedence than the | operator from inside the
macro, so it needs parenthesis.

Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-30 09:29:10 -07:00
Linus Torvalds
f6735590e9 PCI aerdrv: fix annoying warnings
Some compiler generates following warnings:

  In function 'aer_isr':
  warning: 'e_src.id' may be used uninitialized in this function
  warning: 'e_src.status' may be used uninitialized in this function

Avoid status flag "int ret" and return constants instead, so that
gcc sees the return value matching "it is initialized" better.

Acked-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-30 09:29:10 -07:00
Alan Stern
f3ec4f87d6 PCI: change device runtime PM settings for probe and remove
This patch (as1388) changes the way the PCI core handles runtime PM
settings when probing or unbinding drivers.  Now the core will make
sure the device is enabled for runtime PM, with a usage count >= 1,
when a driver is probed.  It does the same when calling a driver's
remove method.

If the driver wants to use runtime PM, all it has to do is call
pm_runtime_pu_noidle() near the end of its probe routine (to cancel
the core's usage increment) and pm_runtime_get_noresume() near the
start of its remove routine (to restore the usage count).  It does not
need to mess around with setting the runtime state to enabled,
disabled, active, or suspended.

The patch updates e1000e and r8169, the only PCI drivers that already
use the existing runtime PM interface.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-30 09:29:09 -07:00
Joerg Roedel
7a42c4ff02 Merge branches 'iommu-api/2.6.36' and 'amd-iommu/2.6.36' into iommu/2.6.36 2010-07-27 18:19:32 +02:00
Tom Lyon
323f99cbc3 iommu-api: Extension to check for interrupt remapping
This patch allows IOMMU users to determine whether the
hardware and software support safe, isolated interrupt
remapping.  Not all Intel IOMMUs have the hardware, and the
software for AMD is not there yet.

Signed-off-by: Tom Lyon <pugs@cisco.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2010-07-19 15:44:25 +02:00
Rafael J. Wysocki
c125e96f04 PM: Make it possible to avoid races between wakeup and system sleep
One of the arguments during the suspend blockers discussion was that
the mainline kernel didn't contain any mechanisms making it possible
to avoid races between wakeup and system suspend.

Generally, there are two problems in that area.  First, if a wakeup
event occurs exactly when /sys/power/state is being written to, it
may be delivered to user space right before the freezer kicks in, so
the user space consumer of the event may not be able to process it
before the system is suspended.  Second, if a wakeup event occurs
after user space has been frozen, it is not generally guaranteed that
the ongoing transition of the system into a sleep state will be
aborted.

To address these issues introduce a new global sysfs attribute,
/sys/power/wakeup_count, associated with a running counter of wakeup
events and three helper functions, pm_stay_awake(), pm_relax(), and
pm_wakeup_event(), that may be used by kernel subsystems to control
the behavior of this attribute and to request the PM core to abort
system transitions into a sleep state already in progress.

The /sys/power/wakeup_count file may be read from or written to by
user space.  Reads will always succeed (unless interrupted by a
signal) and return the current value of the wakeup events counter.
Writes, however, will only succeed if the written number is equal to
the current value of the wakeup events counter.  If a write is
successful, it will cause the kernel to save the current value of the
wakeup events counter and to abort the subsequent system transition
into a sleep state if any wakeup events are reported after the write
has returned.

[The assumption is that before writing to /sys/power/state user space
will first read from /sys/power/wakeup_count.  Next, user space
consumers of wakeup events will have a chance to acknowledge or
veto the upcoming system transition to a sleep state.  Finally, if
the transition is allowed to proceed, /sys/power/wakeup_count will
be written to and if that succeeds, /sys/power/state will be written
to as well.  Still, if any wakeup events are reported to the PM core
by kernel subsystems after that point, the transition will be
aborted.]

Additionally, put a wakeup events counter into struct dev_pm_info and
make these per-device wakeup event counters available via sysfs,
so that it's possible to check the activity of various wakeup event
sources within the kernel.

To illustrate how subsystems can use pm_wakeup_event(), make the
low-level PCI runtime PM wakeup-handling code use it.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Acked-by: markgross <markgross@thegnar.org>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
2010-07-19 01:58:48 +02:00