PCI: Add PCI ROM helper for platform-provided ROM images

It turns out that some UEFI systems provide apparently an apparently valid
PCI ROM BAR that turns out to contain garbage, so the attempt in 547b52463
to prefer the ROM from the BAR actually breaks a different set of machines.
As Linus pointed out, the graphics drivers are probably in the best
position to make this judgement, so this basically reverts 547b52463 and
f9a37be0f and adds a new helper function. Followup patches will add support
to nouveau and radeon for probing this ROM source if they can't find a ROM
from some other source.

[bhelgaas: added reporter and bugzilla pointers, s/f4eb5ff05/547b52463]
Reference: https://bugzilla.redhat.com/show_bug.cgi?id=927451
Reference: http://lkml.kernel.org/r/kg69ef$vdb$1@ger.gmane.org
Reported-by: Mantas Mikulėnas <grawity@gmail.com>
Reported-by: Chris Murphy <bugzilla@colorremedies.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
EISA/PCI: Fix bus res reference

Matthew found that 3.8.3 is having problems with an old (ancient)
PCI-to-EISA bridge, the Intel 82375. It worked with the 3.2 kernel.
He identified the 82375, but doesn't assign the struct resource *res
pointer inside the struct eisa_root_device, and panics.

pci_eisa_init() was using bus->resource[] directly instead of
pci_bus_resource_n().  The bus->resource[] array is a PCI-internal
implementation detail, and after commit 45ca9e97 (PCI: add helpers for
building PCI bus resource lists) and commit 0efd5aab (PCI: add struct
pci_host_bridge_window with CPU/bus address offset), bus->resource[] is not
used for PCI root buses any more.

The 82375 is a subtractive-decode PCI device, so handle it the same
way we handle PCI-PCI bridges in subtractive-decode mode in
pci_read_bridge_bases().

[bhelgaas: changelog]
Reported-by: Matthew Whitehead <mwhitehe@redhat.com>
Tested-by: Matthew Whitehead <mwhitehe@redhat.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org	# v3.3+
EISA/PCI: Init EISA early, before PNP

Matthew reported kernels fail the pci_eisa probe and are later successful
with the virtual_eisa_root_init force probe without slot0.

The reason for that is: PNP probing is before pci_eisa_init gets called
as pci_eisa_init is called via pci_driver.

pnp 00:0f has 0xc80 - 0xc84 reserved.
[    9.700409] pnp 00:0f: [io  0x0c80-0x0c84]

so eisa_probe will fail from pci_eisa_init
				==>eisa_root_register
					==>eisa_probe path.
as force_probe is not set in pci_eisa_root, it will bail early when
slot0 is not probed and initialized.

Try to use subsys_initcall_sync instead, and will keep following sequence:
	pci_subsys_init
	pci_eisa_init_early
	pnpacpi_init/isapnp_init

After this patch EISA can be initialized properly, and PNP overlapping
resource will not be reserved.
[   10.104434] system 00:0f: [io  0x0c80-0x0c84] could not be reserved

Reported-by: Matthew Whitehead <mwhitehe@redhat.com>
Tested-by: Matthew Whitehead <mwhitehe@redhat.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
nouveau: Attempt to use platform-provided ROM image

Some platforms only provide their PCI ROM via a platform-specific interface.
Fall back to attempting that if all other sources fail.

Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
radeon: Attempt to use platform-provided ROM image

Some platforms only provide their PCI ROM via a platform-specific interface.
Fall back to attempting that if all other sources fail.

Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Merge branch 'pci/mjg-rom' into for-linus

* pci/mjg-rom:
  radeon: Attempt to use platform-provided ROM image
  nouveau: Attempt to use platform-provided ROM image
  PCI: Add PCI ROM helper for platform-provided ROM images
Merge branch 'pci/yinghai-eisa' into for-linus

* pci/yinghai-eisa:
  EISA/PCI: Init EISA early, before PNP
  EISA/PCI: Fix bus res reference
Revert "PCI/ACPI: Request _OSC control before scanning PCI root bus"

This reverts commit 8c33f51df406e1a1f7fa4e9b244845b7ebd61fa6.

Conflicts:
	drivers/acpi/pci_root.c

This commit broke some pre-1.1 PCIe devices by leaving them with
ASPM enabled.  Previously, we had disabled ASPM on these devices
because many of them don't implement it correctly (per 149e1637).

Requesting _OSC control early means that aspm_disabled may be set
before we scan the PCI bus and configure link ASPM state.  But the
ASPM configuration currently skips the check for pre-PCIe 1.1 devices
when aspm_disabled is set, like this:

    acpi_pci_root_add
      acpi_pci_osc_support
        if (flags != base_flags)
          pcie_no_aspm
            aspm_disabled = 1
      pci_acpi_scan_root
        ...
          pcie_aspm_init_link_state
            pcie_aspm_sanity_check
              if (!aspm_disabled)
                /* check for pre-PCIe 1.1 device */

Therefore, setting aspm_disabled early means that we leave ASPM enabled
on these pre-PCIe 1.1 devices, which is a regression for some devices.

The best fix would be to clean up the ASPM init so we can evaluate
_OSC before scanning the bug (that way boot-time and hot-add discovery
will work the same), but that requires significant rework.

For now, we'll just revert the _OSC change as the lowest-risk fix.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=55211
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
CC: stable@vger.kernel.org	# v3.8+
PCI: Don't try to disable Bus Master on disconnected PCI devices

This is a fix for commit 7897e60227 ("PCI: Disable Bus Master
unconditionally in pci_device_shutdown()").  Vivek reported that
with this commit, kexec failed because none of his SATA disks
came up.

A ->shutdown() callback might put the device in D3cold, which means config
space is no longer available.

[bhelgaas: changelog]
Link: https://lkml.org/lkml/2013/3/12/529
Reported-and-Tested-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
PCI/ACPI: Always resume devices on ACPI wakeup notifications

It turns out that the _Lxx control methods provided by some BIOSes
clear the PME Status bit of PCI devices they handle, which means that
pci_acpi_wake_dev() cannot really use that bit to check whether or
not the device has signalled wakeup.

One symptom of the problem is, for example, that when an affected PCI
USB controller is runtime-suspended, then plugging in a new USB device
into one of the controller's ports will not wake up the controller,
which should happen.

For this reason, make pci_acpi_wake_dev() always attempt to resume
the device it is called for regardless of the device's PME Status bit
value (that bit still has to be cleared if set at this point,
though).

Reported-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
CC: stable@vger.kernel.org	# v3.7+
PCI/PM: Disable runtime PM of PCIe ports

The runtime PM of PCIe ports turns out to be quite fragile, as in
some cases things work while in some other cases they don't and we
don't seem to have a good way to determine whether or not they are
going to work in advance.

For this reason, avoid enabling runtime PM for PCIe ports by
keeping their runtime PM reference counters always above 0 for the
time being.

When a PCIe port is suspended, it can no longer report events like
hotplug, so hotplug below the port may not work, as in the bug
report below.

[bhelgaas: changelog, stable]
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=53811
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.6+
dm cache: fix writes to cache device in writethrough mode

The dm-cache writethrough strategy introduced by commit e2e74d617eadc15
("dm cache: fix race in writethrough implementation") issues a bio to
the origin device, remaps and then issues the bio to the cache device.
This more conservative in-series approach was selected to favor
correctness over performance (of the previous parallel writethrough).
However, this in-series implementation that reuses the same bio to write
both the origin and cache device didn't take into account that the block
layer's req_bio_endio() modifies a completing bio's bi_sector and
bi_size.  So the new writethrough strategy needs to preserve these bio
fields, and restore them before submission to the cache device,
otherwise nothing gets written to the cache (because bi_size is 0).

This patch adds a struct dm_bio_details field to struct per_bio_data,
and uses dm_bio_record() and dm_bio_restore() to ensure the bio is
restored before reissuing to the cache device.  Adding such a large
structure to the per_bio_data is not ideal but we can improve this
later, for now correctness is the important thing.

This problem initially went unnoticed because the dm-cache test-suite
uses a linear DM device for the dm-cache device's origin device.
Writethrough worked as expected because DM submits a *clone* of the
original bio, so the original bio which was reused for the cache was
never touched.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
dm cache: reduce bio front_pad size in writeback mode

A recent patch to fix the dm cache target's writethrough mode extended
the bio's front_pad to include a 1056-byte struct dm_bio_details.
Writeback mode doesn't need this, so this patch reduces the
per_bio_data_size to 16 bytes in this case instead of 1096.

The dm_bio_details structure was added in "dm cache: fix writes to
cache device in writethrough mode" which fixed commit e2e74d617e ("dm
cache: fix race in writethrough implementation").  In writeback mode
we avoid allocating the writethrough-specific members of the
per_bio_data structure (the dm_bio_details structure included).

Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Merge tag 'pci-v3.9-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci

Pull PCI fixes from Bjorn Helgaas:
 "PCI updates for v3.9:

  ASPM
      Revert "PCI/ACPI: Request _OSC control before scanning PCI root bus"
  kexec
      PCI: Don't try to disable Bus Master on disconnected PCI devices
  Platform ROM images
      PCI: Add PCI ROM helper for platform-provided ROM images
      nouveau: Attempt to use platform-provided ROM image
      radeon: Attempt to use platform-provided ROM image
  Hotplug
      PCI/ACPI: Always resume devices on ACPI wakeup notifications
      PCI/PM: Disable runtime PM of PCIe ports
  EISA
      EISA/PCI: Fix bus res reference
      EISA/PCI: Init EISA early, before PNP"

* tag 'pci-v3.9-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
  PCI/PM: Disable runtime PM of PCIe ports
  PCI/ACPI: Always resume devices on ACPI wakeup notifications
  PCI: Don't try to disable Bus Master on disconnected PCI devices
  Revert "PCI/ACPI: Request _OSC control before scanning PCI root bus"
  radeon: Attempt to use platform-provided ROM image
  nouveau: Attempt to use platform-provided ROM image
  EISA/PCI: Init EISA early, before PNP
  EISA/PCI: Fix bus res reference
  PCI: Add PCI ROM helper for platform-provided ROM images
Merge tag 'dm-3.9-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm

Pull device-mapper fixes from Alasdair Kergon:
 "A pair of patches to fix the writethrough mode of the device-mapper
  cache target when the device being cached is not itself wrapped with
  device-mapper."

* tag 'dm-3.9-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm:
  dm cache: reduce bio front_pad size in writeback mode
  dm cache: fix writes to cache device in writethrough mode