Summary of http://lkml.org/lkml/2014/3/14/363 :

  Ted: module_param(queue_depth, int, 444)
  Joe: 0444!
  Rusty: User perms >= group perms >= other perms?
  Joe: CLASS_ATTR, DEVICE_ATTR, SENSOR_ATTR and SENSOR_ATTR_2?

Side effect of stricter permissions means removing the unnecessary
S_IFREG from several callers.

Note that the BUILD_BUG_ON_ZERO((perm) & 2) test was removed: a fair
number of drivers fail this test, so that will be the debate for a
future patch.
Suggested-by: NJoe Perches <joe@perches.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com> for drivers/pci/slot.c
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Miklos Szeredi <miklos@szeredi.hu>
Cc: Mark Fasheh <mfasheh@suse.com>
Cc: Joel Becker <jlbec@evilplan.org>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Make a note in dmesg when we overwrite legacy IDE BAR info.  We previously
logged something like this:

  pci 0000:00:1f.1: reg 0x10: [io  0x0000-0x0007]

and then silently overwrote the resource.  There's an example in the
bugzilla below.  This doesn't fix the bugzilla; it just makes what's going
on more obvious.

No functional change; merely adds some dev_info() calls.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=48451Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The pci_bus_alloc_resource() "type_mask" parameter is used to compare with
the "flags" member of a struct resource, so it should be the same type,
namely "unsigned long".

No functional change because all current IORESOURCE_* flags fit in 32 bits.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

When allocating space from a bus resource, i.e., from apertures leading to
this bus, make sure the entire resource type matches.  The previous code
assumed the IORESOURCE_TYPE_BITS field was a bitmask with only a single bit
set, but this is not true.  IORESOURCE_TYPE_BITS is really an enumeration,
and we have to check all the bits.

See 72dcb119 ("resources: Add register address resource type").

No functional change.  If we used this path for allocating IRQs, DMA
channels, or bus numbers, this would fix a bug because those types are
indistinguishable when masked by IORESOURCE_IO | IORESOURCE_MEM.  But we
don't, so this shouldn't make any difference.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Paul reported that after f75b99d5 ("PCI: Enforce bus address limits in
resource allocation") on a 32-bit kernel (CONFIG_PHYS_ADDR_T_64BIT not
set), intel-gtt complained "can't ioremap flush page - no chipset
flushing".  In addition, other PCI resource allocations, e.g., for bridge
windows, failed.

This happens because we incorrectly skip bus resources of
[mem 0x00000000-0xffffffff] because we think they are of size zero.
When resource_size_t is 32 bits wide, resource_size() on
[mem 0x00000000-0xffffffff] returns 0 because (r->end - r->start + 1)
overflows.

Therefore, we can't use "resource_size() == 0" to decide that allocation
from this resource will fail.  allocate_resource() should fail anyway if it
can't satisfy the address constraints, so we should just depend on that.

A [mem 0x00000000-0xffffffff] bus resource is obviously not really valid,
but we do fall back to it as a default when we don't have information about
host bridge apertures.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=71611
Fixes: f75b99d5 PCI: Enforce bus address limits in resource allocation
Reported-and-tested-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Many architectures implement pcibios_enable_device() the same way, so
provide a default implementation in the core.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Don't enable memory or I/O decoding if we haven't assigned or claimed the
BAR's resource.

If we enable decoding for a BAR that hasn't been assigned an address, we'll
likely cause bus conflicts.  This declines to enable decoding for resources
with IORESOURCE_UNSET.

Note that drivers can use pci_enable_device_io() or pci_enable_device_mem()
if they only care about specific types of BARs.  In that case, we don't
bother checking whether the corresponding resources are assigned or
claimed.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Paul reported that after f75b99d5 ("PCI: Enforce bus address limits in
resource allocation") on a 32-bit kernel (CONFIG_PHYS_ADDR_T_64BIT not
set), intel-gtt complained "can't ioremap flush page - no chipset
flushing".  In addition, other PCI resource allocations, e.g., for bridge
windows, failed.

This happens because we incorrectly skip bus resources of
[mem 0x00000000-0xffffffff] because we think they are of size zero.
When resource_size_t is 32 bits wide, resource_size() on
[mem 0x00000000-0xffffffff] returns 0 because (r->end - r->start + 1)
overflows.

Therefore, we can't use "resource_size() == 0" to decide that allocation
from this resource will fail.  allocate_resource() should fail anyway if it
can't satisfy the address constraints, so we should just depend on that.

A [mem 0x00000000-0xffffffff] bus resource is obviously not really valid,
but we do fall back to it as a default when we don't have information about
host bridge apertures.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=71611
Fixes: f75b99d5 PCI: Enforce bus address limits in resource allocation
Reported-and-tested-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Andreas reported that after 1f42db78 ("PCI: Enable INTx if BIOS left
them disabled"), pciehp surprise removal stopped working.

This happens because pci_reenable_device() on the hotplug bridge (used in
the pciehp_configure_device() path) clears the Interrupt Disable bit, which
apparently breaks the bridge's MSI hotplug event reporting.

Previously we cleared the Interrupt Disable bit in do_pci_enable_device(),
which is used by both pci_enable_device() and pci_reenable_device().  But
we use pci_reenable_device() after the driver may have enabled MSI or
MSI-X, and we *set* Interrupt Disable as part of enabling MSI/MSI-X.

This patch clears Interrupt Disable only when MSI/MSI-X has not been
enabled.

Fixes: 1f42db78 PCI: Enable INTx if BIOS left them disabled
Link: https://bugzilla.kernel.org/show_bug.cgi?id=71691Reported-and-tested-by: NAndreas Noever <andreas.noever@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>

Andreas reported that after 1f42db78 ("PCI: Enable INTx if BIOS left
them disabled"), pciehp surprise removal stopped working.

This happens because pci_reenable_device() on the hotplug bridge (used in
the pciehp_configure_device() path) clears the Interrupt Disable bit, which
apparently breaks the bridge's MSI hotplug event reporting.

Previously we cleared the Interrupt Disable bit in do_pci_enable_device(),
which is used by both pci_enable_device() and pci_reenable_device().  But
we use pci_reenable_device() after the driver may have enabled MSI or
MSI-X, and we *set* Interrupt Disable as part of enabling MSI/MSI-X.

This patch clears Interrupt Disable only when MSI/MSI-X has not been
enabled.

Fixes: 1f42db78 PCI: Enable INTx if BIOS left them disabled
Link: https://bugzilla.kernel.org/show_bug.cgi?id=71691Reported-and-tested-by: NAndreas Noever <andreas.noever@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>

Make the ACPI-based PCI hotplug (ACPIPHP) code use
pci_device_is_present() for checking if devices are present instead
of open coding the same thing.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

There is no reason to care about irq_desc in that context, escpecially
as irq_data for that interrupt is retrieved as well.

Use the proper accessor for the msi descriptor
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJingoo Han <jg1.han@samsung.com>
Cc: Mohit Kumar <mohit.kumar@st.com>
Cc: pci <linux-pci@vger.kernel.org>
Link: http://lkml.kernel.org/r/20140223212736.987803648@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Runtime-suspended devices are resumed during system suspend by
pci_pm_prepare() for two reasons: First, because they may need
to be reprogrammed in order to change their wakeup settings and,
second, because they may need to be operatonal for their children
to be successfully suspended.  That is a problem, though, if there
are many runtime-suspended devices that need to be resumed this
way during system suspend, because the .prepare() PM callbacks of
devices are executed sequentially and the times taken by them
accumulate, which may increase the total system suspend time quite
a bit.

For this reason, move the resume of runtime-suspended devices up
to the next phase of device suspend (during system suspend), except
for the ones that have power.ignore_children set.  The exception is
made, because the devices with power.ignore_children set may still
be necessary for their children to be successfully suspended (during
system suspend) and they won't be resumed automatically as a result
of the runtime resume of their children.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>

If we don't support 64-bit addresses, i.e., CONFIG_PHYS_ADDR_T_64BIT is not
set, we can't deal with BARs above 4GB.  In this case we already pretend
the BAR contained zero; this patch also sets IORESOURCE_UNSET so we can try
to reallocate it later.

I don't think this is exactly correct: what we care about here are *bus*
addresses, not CPU addresses, so the tests of sizeof(resource_size_t)
probably should be on sizeof(dma_addr_t) instead.  But this is what's been
in -next, so we'll fix that later.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

If the IORESOURCE_UNSET bit is set, it means we haven't assigned an address
yet, so don't try to claim the region.

Also, make the error messages more uniform and add info about which BAR is
involved.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Check to make sure we don't update a BAR with an address we haven't
assigned.

If we haven't assigned an address to a resource, we shouldn't write it to a
BAR.  This isn't a problem for the usual path via pci_assign_resource(),
which clears IORESOURCE_UNSET before calling pci_update_resource(), but
paths like pci_restore_bars() can call this for resources we haven't
assigned.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Clear IORESOURCE_UNSET when we assign an address to a resource, not when we
write the address to the BAR.

Also, drop the "BAR %d: set to %pR" message; this is mostly redundant with
the "BAR %d: assigned %pR" message from pci_assign_resource().
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

When assigning addresses to resources, mark them with IORESOURCE_UNSET
before we start and clear IORESOURCE_UNSET if assignment is successful.
That means that if we print the resource during assignment, we will show
the size, not a meaningless address.

Also, clear IORESOURCE_UNSET if we do assign an address, so we print the
address when it is valid.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

If the resource hasn't been allocated yet, pci_find_parent_resource() is
documented as returning the region "where it should be allocated from."
This is impossible in general because there may be several candidates: a
prefetchable BAR can be put in either a prefetchable or non-prefetchable
window, a transparent bridge may have overlapping positively- and
subtractively-decoded windows, and a root bus may have several windows of
the same type.

Allocation should be done by pci_bus_alloc_resource(), which iterates
through all bus resources and looks for the best match, e.g., one with the
desired prefetchability attributes, and falls back to less-desired
possibilities.

The only valid use of pci_find_parent_resource() is to find the parent of
an already-allocated resource so we can claim it via request_resource(),
and all we need for that is a bus region of the correct type that contains
the resource.

Note that like 8c8def26 ("PCI: allow matching of prefetchable resources
to non-prefetchable windows"), this depends on pci_bus_for_each_resource()
iterating through positively-decoded regions before subtractively-decoded
ones.  We prefer not to return a subtractively-decoded region because
requesting from it will likely conflict with the overlapping positively-
decoded window (see Launchpad report below).

Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/424142Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Linus Torvalds <torvalds@linux-foundation.org>

The SGI Visual Workstation seems to be dead; remove support so we
don't have to continue maintaining it.

Cc: Andrey Panin <pazke@donpac.ru>
Cc: Michael Reed <mdr@sgi.com>
Link: http://lkml.kernel.org/r/530CFD6C.7040705@zytor.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>

We have two identical copies of resource_contains() already, and more
places that could use it.  This moves it to ioport.h where it can be
shared.

resource_contains(struct resource *r1, struct resource *r2) returns true
iff r1 and r2 are the same type (most callers already checked this
separately) and the r1 address range completely contains r2.

In addition, the new resource_contains() checks that both r1 and r2 have
addresses assigned to them.  If a resource is IORESOURCE_UNSET, it doesn't
have a valid address and can't contain or be contained by another resource.
Some callers already check this or for res->start.

No functional change.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Update the R-Car Generation 2 PCI driver Kconfig dependencies to follow
same style as other drivers - no SoC dependencies.

Also, update the COMPILE_TEST bits to depend on ARM. This since the DMA
bounce buffer and dma_ops handling code is ARM specific.

[bhelgaas: adjust context after dropping DMABOUNCE patches]
Signed-off-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NSimon Horman <horms+renesas@verge.net.au>

In order to avoid the need to register special ACPI dock
operations for SATA devices add a .uevent() callback pointer to
struct acpi_hotplug_context and make dock_hotplug_event() use that
callback if available.  Also rename the existing .event() callback
in struct acpi_hotplug_context to .notify() to avoid possible
confusion in the future.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Instead of requiring a set of special dock operations to be registered
via register_hotplug_dock_device() for each ACPI dock device, it is
much more straightforward to use callback pointers from the devices'
hotplug contexts if available.

For this reason, modify dock_hotplug_event() to use callback pointers
from the hotplug contexts of ACPI devices and fall back to using the
special dock operarions only if those callbacks are missing.  Also
make the ACPI-based PCI hotplug (ACPIPHP) subsystem set the .fixup
callback pointer in the hotplug contexts of devices handled by it to
a new function, acpiphp_post_dock_fixup(), so that the dock station
driver can use the callbacks from those contexts instead of special
dock operations registered via register_hotplug_dock_device().

Along with the above changes drop the ACPIPHP's dock operations that
are not necessary any more.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Rework the ACPI dock station driver to store ACPI device object
pointers instead of ACPI handles in its internal data structures.

The purpose is moslty to make subsequent simplifications possible,
but also this allows the overall code size to be reduced slightly.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

In order for the ACPI dock station code to be able to use the
callbacks pointed to by the ACPI device objects' hotplug contexts
add a .fixup() callback pointer to struct acpi_hotplug_context.
That callback will be useful to handle PCI devices located in
dock stations.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

After recent changes adding dock station handling to the ACPI hotplug
core, it is not necessary to clear the .event() pointer in the
ACPIPHP device hotplug context for dock stations any more, so don't
do that.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Minor whitespace cleanup; no functional change.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

In case a card is physically yanked out, it should immediately be removed,
regardless of the "surprise" capability bit. Thus:

  - Always handle the physical removal - regardless of the "surprise" bit.
  - Don't use "surprise" capability when making decisions about enabling
    presence detect notifications.
  - Reword the comments to indicate the intent.
Signed-off-by: NRajat Jain <rajatxjain@gmail.com>
Signed-off-by: NRajat Jain <rajatjain@juniper.net>
Signed-off-by: NGuenter Roeck <groeck@juniper.net>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

This patch handles the case where the PCIe link is up and running, yet
drops into the LTSSM training mode. The link spends short time in the LTSSM
training mode, but the current code can misinterpret it as the link being
stalled.  Waiting for the LTSSM training to complete fixes the issue.

Quoting Sascha:

  This is broken since commit 7f9f40c0 ('PCI: imx6: Report "link up"
  only after link training completes').

  The designware driver changes the PORT_LOGIC_SPEED_CHANGE bit in
  dw_pcie_host_init() which causes the link to be retrained. During the
  next call to dw_pcie_rd_conf() the link is then reported being down and
  the function returns PCIBIOS_DEVICE_NOT_FOUND resulting in nonfunctioning
  PCIe.

Fixes: 7f9f40c0 (PCI: imx6: Report "link up" only after link training completes)
Tested-by: NTroy Kisky <troy.kisky@boundarydevices.com>
Tested-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NTroy Kisky <troy.kisky@boundarydevices.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>

The Synopsys PCIe core provides one pair of 32-bit BARs (BAR 0 and BAR 1).
The BARs can be configured as follows:

  - One 64-bit BAR: BARs 0 and 1 are combined to form a single 64-bit BAR
  - Two 32-bit BARs: BARs 0 and 1 are two independent 32-bit BARs

This patch corrects 64-bit, non-prefetchable memory BAR configuration
implemented in dw driver.
Signed-off-by: NMohit Kumar <mohit.kumar@st.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Pratyush Anand <pratyush.anand@st.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: stable@vger.kernel.org	# v3.12+

This reverts commit 74bb1bcc ("PCI: handle SR-IOV Virtual Function
Migration"), removing this exported interface:

  pci_sriov_migration()

Since pci_sriov_migration() is unused, it is impossible to schedule
sriov_migration_task() or use any of the other migration infrastructure.

This is based on Stephen Hemminger's patch (see link below), but goes a bit
further.

Link: http://lkml.kernel.org/r/20131227132710.7190647c@nehalam.linuxnetplumber.netSigned-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Stephen Hemminger <stephen@networkplumber.org>

Some firmware leaves the Interrupt Disable bit set even if the device uses
INTx interrupts.  Clear Interrupt Disable so we get those interrupts.

Based on the report mentioned below, if the user selects the "EHCI only"
option in the Intel Baytrail BIOS, the EHCI device is handed off to the OS
with the PCI_COMMAND_INTX_DISABLE bit set.

Link: http://lkml.kernel.org/r/20140114181721.GC12126@xanatos
Link: https://bugzilla.kernel.org/show_bug.cgi?id=70601Reported-by: NChris Cheng <chris.cheng@atrustcorp.com>
Reported-and-tested-by: NJamie Chen <jamie.chen@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>

It is typical for host drivers to request a resource for the aperture; once
this is done the PCI core will properly populate resources for all BARs in
the system.

With this patch cat /proc/iomem will now show:

  e0000000-efffffff : PCI MEM 0000
    e0000000-e00fffff : PCI Bus 0000:01
      e0000000-e001ffff : 0000:01:00.0

Tested on Kirkwood.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJason Cooper <jason@lakedaemon.net>

Break out the hard coded window size code to allow dynamic setup. The
window size is still left at 1GiB but with this patch changing window size
is easy for testing.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NSimon Horman <horms+renesas@verge.net.au>

Convert the code to allow per-device probe() like other device drivers.
This also delays driver registration due to change from subsys_initcall()
to regular module_platform_driver().
Signed-off-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NSimon Horman <horms+renesas@verge.net.au>

The bridge logic at slot 0 only supports reads up to 0x40 and the rest of
the PCI configuration space for this slot is marked as reserved in the
manual.

Trying a read from offset 0x100 is producing an error from the bridge. With
error interrupts enabled, the following is printed:

  pci-rcar-gen2 ee0d0000.pci: error irq: status 00000014
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NSimon Horman <horms+renesas@verge.net.au>

Add option to enable interrupts to report any errors from the AHB-PCI
bridge to help find any issues with the bridge when in use.
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NSimon Horman <horms+renesas@verge.net.au>

The current code does not check the return from platform_get_irq() so add
an error check and return if this call does fail.
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NSimon Horman <horms+renesas@verge.net.au>

Currently, ACPIPHP does not add hotplug context to devices that
should be handled by the native PCI hotplug (PCIeHP) code.  The
reason why was because PCIeHP didn't know about the devices'
connections with ACPI and would not clean up things properly
during an eject of an ACPI-backed device, for example.

However, after recent changes that made the ACPI core create struct
acpi_device objects for all namespace nodes regardless of the
underlying devices' status and added PCI rescan-remove locking to
both ACPIPHP and PCIeHP, that concern is not valid any more.
Namely, after those changes PCIeHP need not care about the ACPI
side of things any more and it should be serialized with respect to
ACPIPHP and they won't be running concurrently with each other in
any case.

For this reason, make ACPIPHP to add its hotplug context to
all devices with ACPI companions, even the ones that should be
handled by PCIeHP in principle.  That may work around hotplug
issues on some systems where PCIeHP is supposed to work, but it
doesn't and the ACPI hotplug signaling works instead.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>