History log of /drivers/pci/setup-res.c
Revision Date Author Comments
64da465e9841f93183744a9dadf992f938ac3910 09-Jul-2014 Bjorn Helgaas <bhelgaas@google.com> PCI: Tidy resource assignment messages

Print messages about failures in pci_assign_resource(). We can drop the
"by-hand" message from _pci_assign_resource() because %pR now prints the
size rather than the address if the resource hasn't been assigned.

No functional change.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
947788359527d9598356c274c50522e0f6d0ad0f 09-Jul-2014 Bjorn Helgaas <bhelgaas@google.com> PCI: Return conventional error values from pci_revert_fw_address()

Previously we returned zero for success or 1 for failure. This changes
that so we return zero for success or a negative errno for failure.

No functional change.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
28f6dbe2c669c6a02c04c8ece21cafbcb20370ab 04-Jul-2014 Bjorn Helgaas <bhelgaas@google.com> PCI: Cleanup control flow

Return errors immediately so the straightline path is the normal,
no-error path. No functional change.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
c33377082dd9ede1e998f7ce416077e4b1c2276c 04-Jul-2014 Guo Chao <yan@linux.vnet.ibm.com> PCI: Keep original resource if we fail to expand it

If we have space assigned to a resource, we try to expand the resource
(e.g., to accommodate SR-IOV resources), and the expansion attempt fails,
we should keep the original assignment.

After bd064f0a231a ("PCI: Mark resources as IORESOURCE_UNSET if we can't
assign them"), we left the resource marked IORESOURCE_UNSET when the
expansion failed, even if it had originally been set. That caused errors
like this:

pci 0003:00:00.0: can't enable device: BAR 15 [mem size 0x0c000000 64bit pref] not assigned
pci 0003:00:00.0: Error enabling bridge (-22), continuing

Fix this by restoring the original flags when reassignment fails.

[bhelgaas: reworked to simplify, changelog]
Fixes: bd064f0a231a ("PCI: Mark resources as IORESOURCE_UNSET if we can't assign them")
Signed-off-by: Guo Chao <yan@linux.vnet.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v3.15+
227f06470502c4fea3d93df1f12a77e3e37f6263 19-Apr-2014 Ryan Desfosses <ryan@desfo.org> PCI: Merge multi-line quoted strings

Merge quoted strings that are broken across lines into a single entity.
The compiler merges them anyway, but checkpatch complains about it, and
merging them makes it easier to grep for strings.

No functional change.

[bhelgaas: changelog, do the same for everything under drivers/pci]
Signed-off-by: Ryan Desfosses <ryan@desfo.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
b7fe943421396b61b9f7a97c2554ed999e0f3658 25-Apr-2014 Ryan Desfosses <ryan@desfo.org> PCI: Move EXPORT_SYMBOL so it immediately follows function/variable

Move EXPORT_SYMBOL so it immediately follows the function or variable.

No functional change.

[bhelgaas: squash similar changes, fix hotplug, probe, rom, search, too]
Signed-off-by: Ryan Desfosses <ryan@desfo.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
67d29b5c6c40e91b124695e9250c2fd24915e24a 20-May-2014 Bjorn Helgaas <bhelgaas@google.com> PCI: Add resource allocation comments

Add comments in the code to match the allocation strategy of 7c671426dfc3
("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources").

No functional change.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
d3689df04445c568c8b3dfcd8db4b562e1b18cfb 20-May-2014 Bjorn Helgaas <bhelgaas@google.com> PCI: Simplify __pci_assign_resource() coding style

If an allocation succeeds, we can return success immediately. Then we
don't have to test for success in the subsequent code.

No functional change.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
5b28541552ef5eeffc41d6936105f38c2508e566 20-May-2014 Yinghai Lu <yinghai@kernel.org> PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources

This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.

Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.

After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.

With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.

The new strategy is:

1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.

2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.

3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.

This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.

[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
56a3d18279f00c7ccbcdc193ceaf1a2f88c51457 05-Apr-2014 Paul Gortmaker <paul.gortmaker@windriver.com> PCI: Remove unnecessary includes of <linux/init.h>

None of these files are actually using any __init type directives and hence
don't need to include <linux/init.h>. Most are just a left over from
__devinit and __cpuinit removal, or simply due to code getting copied from
one driver to the next.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
3cedcc3621289d41bd21c5dbe0b886d57c83a1ea 26-Feb-2014 Bjorn Helgaas <bhelgaas@google.com> PCI: Don't enable decoding if BAR hasn't been assigned an address

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: Bjorn Helgaas <bhelgaas@google.com>
29003beb7f15d3daa5a8f9afb8d007b64baa2357 26-Feb-2014 Bjorn Helgaas <bhelgaas@google.com> PCI: Don't try to claim IORESOURCE_UNSET resources

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: Bjorn Helgaas <bhelgaas@google.com>
cd8a4d3657c3f2cf9ce3780707be1debb8fea6e2 26-Feb-2014 Bjorn Helgaas <bhelgaas@google.com> PCI: Check IORESOURCE_UNSET before updating BAR

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: Bjorn Helgaas <bhelgaas@google.com>
434aafc1aefb5eb6e8c8d15284c8f929be756521 26-Feb-2014 Bjorn Helgaas <bhelgaas@google.com> PCI: Don't clear IORESOURCE_UNSET when updating BAR

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: Bjorn Helgaas <bhelgaas@google.com>
bd064f0a231af336218838474ea45a64f1672190 26-Feb-2014 Bjorn Helgaas <bhelgaas@google.com> PCI: Mark resources as IORESOURCE_UNSET if we can't assign them

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: Bjorn Helgaas <bhelgaas@google.com>
fc2798502f860b18f3c7121e4dc659d3d9d28d74 10-Dec-2013 Yinghai Lu <yinghai@kernel.org> PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev

These interfaces:

pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)

took a pci_dev, but they really depend only on the pci_bus. And we want to
use them in resource allocation paths where we have the bus but not a
device, so this patch converts them to take the pci_bus instead of the
pci_dev:

pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)

In fact, with standard PCI-PCI bridges, they only depend on the host
bridge, because that's the only place address translation occurs, but
we aren't going that far yet.

[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
f7625980f5820edd1a73536e1a03bcbc1f889fec 14-Nov-2013 Bjorn Helgaas <bhelgaas@google.com> PCI: Fix whitespace, capitalization, and spelling errors

Fix whitespace, capitalization, and spelling errors. No functional change.
I know "busses" is not an error, but "buses" was more common, so I used it
consistently.

Signed-off-by: Marta Rybczynska <rybczynska@gmail.com> (pci_reset_bridge_secondary_bus())
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
b638d7e7b849ad402aaecfe7edb599687b5eb3a8 12-Apr-2013 Bjorn Helgaas <bhelgaas@google.com> PCI: Remove unused variables

This fixes "set but not used" warnings found via "make W=1".

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
fe6dacdb1a31957825c0876de7cdea4c356aca30 12-Jul-2012 Bjorn Helgaas <bhelgaas@google.com> PCI: reorder __pci_assign_resource() (no change)

Reorder functions so __pci_assign_resource(), _pci_assign_resource(),
and pci_assign_resource() are closer together. No code change.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
d6776e6d5c2f8db0252f447b09736075e1bbe387 20-Jun-2012 Nikhil P Rao <nikhil.rao@intel.com> PCI: fix truncation of resource size to 32 bits

_pci_assign_resource() took an int "size" argument, which meant that
sizes larger than 4GB were truncated. Change type to resource_size_t.

[bhelgaas: changelog]
Signed-off-by: Nikhil P Rao <nikhil.rao@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
9aac537e0e33f4e4f28b8e7472c283fb6460c650 10-Jul-2012 Bjorn Helgaas <bhelgaas@google.com> PCI: disable MEM decoding while updating 64-bit MEM BARs

When we update 64-bit BARs, we have to perform two config writes. Between
the writes, the half-written BAR value could match a MEM access intended
for another device. This could result in corruption of this device (for
writes) or an unexpected response machine check (for reads).

To prevent this, disable MEM decoding while updating such BARs. This uses
the same safety test as 253d2e5498, which disables both MEM and IO while
sizing BARs, namely, we don't disable decoding for host bridge devices.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2069ecfbe14ebd71a6f98e8a00724e9adf4fe4ee 16-Feb-2012 Yinghai Lu <yinghai@kernel.org> PCI: Move "pci reassigndev resource alignment" out of quirks.c

This isn't really a quirk; calling it directly from pci_add_device makes
more sense.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
78c3b329b9dd7097781cb900146e503e499cccfe 21-Jan-2012 Yinghai Lu <yinghai@kernel.org> PCI: Move pdev_sort_resources() to setup-bus.c

This allows us to move the definition of struct resource_list to
setup_bus.c and later convert resource_list to a regular list.

Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
a4ac9fea016fc5c09227eb479bd35e34978323a4 21-Jan-2012 Yinghai Lu <yinghai@kernel.org> PCI : Calculate right add_size

During debug of one SRIOV enabled hotplug device, we found found that
add_size is not passed properly.

The device has devices under two level bridges:

+-[0000:80]-+-00.0-[81-8f]--
| +-01.0-[90-9f]--
| +-02.0-[a0-af]----00.0-[a1-a3]--+-02.0-[a2]--+-00.0 Oracle Corporation Device
| | \-03.0-[a3]--+-00.0 Oracle Corporation Device

Which means later the parent bridge will not try to add a big enough range:

[ 557.455077] pci 0000:a0:00.0: BAR 14: assigned [mem 0xf9000000-0xf93fffff]
[ 557.461974] pci 0000:a0:00.0: BAR 15: assigned [mem 0xf6000000-0xf61fffff pref]
[ 557.469340] pci 0000:a1:02.0: BAR 14: assigned [mem 0xf9000000-0xf91fffff]
[ 557.476231] pci 0000:a1:02.0: BAR 15: assigned [mem 0xf6000000-0xf60fffff pref]
[ 557.483582] pci 0000:a1:03.0: BAR 14: assigned [mem 0xf9200000-0xf93fffff]
[ 557.490468] pci 0000:a1:03.0: BAR 15: assigned [mem 0xf6100000-0xf61fffff pref]
[ 557.497833] pci 0000:a1:03.0: BAR 14: can't assign mem (size 0x200000)
[ 557.504378] pci 0000:a1:03.0: failed to add optional resources res=[mem 0xf9200000-0xf93fffff]
[ 557.513026] pci 0000:a1:02.0: BAR 14: can't assign mem (size 0x200000)
[ 557.519578] pci 0000:a1:02.0: failed to add optional resources res=[mem 0xf9000000-0xf91fffff]

It turns out we did not calculate size1 properly.

static resource_size_t calculate_memsize(resource_size_t size,
resource_size_t min_size,
resource_size_t size1,
resource_size_t old_size,
resource_size_t align)
{
if (size < min_size)
size = min_size;
if (old_size == 1 )
old_size = 0;
if (size < old_size)
size = old_size;
size = ALIGN(size + size1, align);
return size;
}

We should not pass add_size with min_size in calculate_memsize since
that will make add_size not contribute final add_size.

So just pass add_size with size1 to calculate_memsize().

With this change, we should have chance to remove extra addon in
pci_reassign_resource.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
0dea210b1769f191d6b2bc3cc86e51481837ec5e 26-Jan-2012 Masanari Iida <standby24x7@gmail.com> PCI: Fix typo in setup-res.c

Correct spelling "resouce" to "resource" in
dricers/pci/setup-res.c

Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
6535943fbf25c8e9419a6b20ca992633baa0bf99 21-Nov-2011 Myron Stowe <mstowe@redhat.com> x86/PCI: Convert maintaining FW-assigned BIOS BAR values to use a list

This patch converts the underlying maintenance aspects of FW-assigned
BIOS BAR values from a statically allocated array within struct pci_dev
to a list of temporary, stand alone, entries.

Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
351fc6d1a5175d587d4f2b00ec7bff79b13ec48a 21-Nov-2011 Myron Stowe <mstowe@redhat.com> PCI: Fix starting basis for resource requests

pci_revert_fw_address() is used to reinstate a PCI device's original
FW-assigned BIOS BAR value(s) if normal resource assignment fails.

When attempting to reinstate an address, the point within the resource
tree from which to attempt the new resource request should be the parent
resource corresponding to the device, not the base of the resource tree
(ioport_resource or iomem_resource). For PCI devices this would
typically be the resource corresponding to the upstream PCI host bridge
or P2P bridge aperture.

This patch sets the point within the resource tree to attempt a new
resource assignment request to the PCI device's parent resource and only
if that fails does it fall back to the base ioport_resource or
iomem_resource.

Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
85b8582d7ca516030efb84d94fa29a73c1d9a125 05-Dec-2011 Vincent Palatin <vpalatin@chromium.org> PCI/PM/Runtime: make PCI traces quieter

When the runtime PM is activated on PCI, if a device switches state
frequently (e.g. an EHCI controller with autosuspending USB devices
connected) the PCI configuration traces might be very verbose in the
kernel log. Let's guard those traces with DEBUG condition.

Acked-by: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
363c75db1d7bbda0aa90e680565f2673bab92ee4 27-May-2011 Paul Gortmaker <paul.gortmaker@windriver.com> pci: Fix files needing export.h for EXPORT_SYMBOL/THIS_MODULE

They were implicitly getting it from device.h --> module.h but
we want to clean that up. So add the minimal header for these
macros.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2bbc6942273b5b3097bd265d82227bdd84b351b2 25-Jul-2011 Ram Pai <linuxram@us.ibm.com> PCI : ability to relocate assigned pci-resources

Currently pci-bridges are allocated enough resources to satisfy their immediate
requirements. Any additional resource-requests fail if additional free space,
contiguous to the one already allocated, is not available. This behavior is not
reasonable since sufficient contiguous resources, that can satisfy the request,
are available at a different location.

This patch provides the ability to expand and relocate a allocated resource.

v2: Changelog: Fixed size calculation in pci_reassign_resource()
v3: Changelog : Split this patch. The resource.c changes are already
upstream. All the pci driver changes are in here.

Signed-off-by: Ram Pai <linuxram@us.ibm.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
28c6821a0f8e686d4f1a6107d970705d37475d87 14-Jun-2011 Bjorn Helgaas <bhelgaas@google.com> PCI: fold pci_calc_resource_flags() into decode_bar()

decode_bar() and pci_calc_resource_flags() both looked at the PCI BAR
type information, and it's simpler to just do it all in one place.

decode_bar() sets IORESOURCE_IO, IORESOURCE_MEM, and IORESOURCE_MEM_64
as appropriate, so res->flags contains all the information pci_bar_type
does, so we don't need to test the pci_bar_type return value.

decode_bar() used to return pci_bar_type, which we no longer need. We
can simplify it a bit by returning the struct resource flags rather than
updating them internally.

In pci_update_resource(), there's no need to decode the BAR type bits
again; we can just test for IORESOURCE_MEM_64 directly.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
1bcd495be9ed3194f618e8af0446459dc52a1423 29-Sep-2010 Bjorn Helgaas <bjorn.helgaas@hp.com> PCI: fix message typo

I missed the closing parenthesis on "(PCI address ...)".

Acked-by: Arnd Bergmann <arnd@arndb.de>
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
58c84eda07560a6b75b03e8d3b26d6eddfc14011 15-Jul-2010 Bjorn Helgaas <bjorn.helgaas@hp.com> PCI: fall back to original BIOS BAR addresses

If we fail to assign resources to a PCI BAR, this patch makes us try the
original address from BIOS rather than leaving it disabled.

Linux tries to make sure all PCI device BARs are inside the upstream
PCI host bridge or P2P bridge apertures, reassigning BARs if necessary.
Windows does similar reassignment.

Before this patch, if we could not move a BAR into an aperture, we left
the resource unassigned, i.e., at address zero. Windows leaves such BARs
at the original BIOS addresses, and this patch makes Linux do the same.

This is a bit ugly because we disable the resource long before we try to
reassign it, so we have to keep track of the BIOS BAR address somewhere.
For lack of a better place, I put it in the struct pci_dev.

I think it would be cleaner to attempt the assignment immediately when the
claim fails, so we could easily remember the original address. But we
currently claim motherboard resources in the middle, after attempting to
claim PCI resources and before assigning new PCI resources, and changing
that is a fairly big job.

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

Reported-by: Andrew <nitr0@seti.kr.ua>
Tested-by: Andrew <nitr0@seti.kr.ua>
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
f6d440daebd12be66ea1f834faf2966a49a07bd6 03-Jun-2010 Bjorn Helgaas <bjorn.helgaas@hp.com> PCI: change resource collision messages from KERN_ERR to KERN_INFO

We can often deal with PCI resource issues by moving devices around. In
that case, there's no point in alarming the user with messages like these.
There are many bug reports where the message itself is the only problem,
e.g., https://bugs.launchpad.net/ubuntu/+source/linux/+bug/413419 .

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
966f3a7570447c5025d67a618d408e68a3ae3167 12-Mar-2010 Bjorn Helgaas <bjorn.helgaas@hp.com> PCI: for address space collisions, show conflicting resource

With request_resource_conflict(), we can learn what the actual conflict is,
so print that info for debugging purposes.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
865df576e8fc70daf297b53e61a4fbefc719d065 04-Nov-2009 Bjorn Helgaas <bjorn.helgaas@hp.com> PCI: improve discovery/configuration messages

This makes PCI resource management messages more consistent and adds a few
new messages to aid debugging.

Whenever we assign resources to a device, update a BAR, or change a
bridge aperture, it's worth noting it.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
c7dabef8a2c59e6a3de9d66fc35fb6a43ef7172d 27-Oct-2009 Bjorn Helgaas <bjorn.helgaas@hp.com> vsprintf: use %pR, %pr instead of %pRt, %pRf

Jesse accidentally applied v1 [1] of the patchset instead of v2 [2]. This
is the diff between v1 and v2.

The changes in this patch are:
- tidied vsprintf stack buffer to shrink and compute size more
accurately
- use %pR for decoding and %pr for "raw" (with type and flags) instead
of adding %pRt and %pRf

[1] http://lkml.org/lkml/2009/10/6/491
[2] http://lkml.org/lkml/2009/10/13/441

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
a369c791e881503a6253dafc0d0ad5e41e5557e5 06-Oct-2009 Bjorn Helgaas <bjorn.helgaas@hp.com> PCI: print resources consistently with %pRt

This uses %pRt to print additional resource information (type, size,
prefetchability, etc.) consistently.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
b812cca4e2efe9a05de20ccf3f8587e7ac6e12fa 06-Oct-2009 Bjorn Helgaas <bjorn.helgaas@hp.com> PCI: remove pci_assign_resource_fixed()

Adrian commented out this function in 2baad5f96b49, but I don't think
it's even worth cluttering the file with the unused code.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
eaa959df299157e2640fcb3321537501b6afd9e6 01-Jul-2009 Jesse Barnes <jbarnes@virtuousgeek.org> PCI: export pci_claim_resource for driver use

yenta needs this for example.

Acked-by: Matthew Wilcox <willy@linux.intel.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
6faf17f6f1ffc586d16efc2f9fa2083a7785ee74 28-Aug-2009 Chris Wright <chrisw@sous-sol.org> PCI SR-IOV: correct broken resource alignment calculations

An SR-IOV capable device includes an SR-IOV PCIe capability which
describes the Virtual Function (VF) BAR requirements. A typical SR-IOV
device can support multiple VFs whose BARs must be in a contiguous region,
effectively an array of VF BARs. The BAR reports the size requirement
for a single VF. We calculate the full range needed by simply multiplying
the VF BAR size with the number of possible VFs and create a resource
spanning the full range.

This all seems sane enough except it artificially inflates the alignment
requirement for the VF BAR. The VF BAR need only be aligned to the size
of a single BAR not the contiguous range of VF BARs. This can cause us
to fail to allocate resources for the BAR despite the fact that we
actually have enough space.

This patch adds a thin PCI specific layer over the generic
resource_alignment() function which is aware of the special nature of
VF BARs and does sorting and allocation based on the smaller alignment
requirement.

I recognize that while resource_alignment is generic, it's basically a
PCI helper. An alternative to this patch is to add PCI VF BAR specific
information to struct resource. I opted for the extra layer rather than
adding such PCI specific information to struct resource. This does
have the slight downside that we don't cache the BAR size and re-read
for each alignment query (happens a small handful of times during boot
for each VF BAR).

Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Yu Zhao <yu.zhao@intel.com>
Cc: stable@kernel.org
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
79896cf42f6a96d7e14f2dc3473443d68d74031d 02-Aug-2009 Linus Torvalds <torvalds@linux-foundation.org> Make pci_claim_resource() use request_resource() rather than insert_resource()

This function has traditionally used "insert_resource()", because before
commit cebd78a8c5 ("Fix pci_claim_resource") it used to just insert the
resource into whatever root resource tree that was indicated by
"pcibios_select_root()".

So there Matthew fixed it to actually look up the proper parent
resource, which means that now it's actively wrong to then traverse the
resource tree any more: we already know exactly where the new resource
should go.

And when we then did commit a76117dfd6 ("x86: Use pci_claim_resource"),
which changed the x86 PCI code from the open-coded

pr = pci_find_parent_resource(dev, r);
if (!pr || request_resource(pr, r) < 0) {

to using

if (pci_claim_resource(dev, idx) < 0) {

that "insert_resource()" now suddenly became a problem, and causes a
regression covered by

http://bugzilla.kernel.org/show_bug.cgi?id=13891

which this fixes.

Reported-and-tested-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Matthew Wilcox <willy@linux.intel.com>
Cc: Andrew Patterson <andrew.patterson@hp.com>
Cc: Linux PCI <linux-pci@vger.kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
cebd78a8c5624b5cf04c39c3335a5fc8670a7b69 17-Jun-2009 Matthew Wilcox <willy@linux.intel.com> Fix pci_claim_resource

Instead of starting from the iomem or ioport roots, start from the
parent bus' resources. This fixes a bug where child resources would
appear above their parents resources if they had the same size.

Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Tested-by: Andrew Patterson <andrew.patterson@hp.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
d09ee9687e027fc7d2c6b95daf05a8ef3ff06340 24-Apr-2009 Yinghai Lu <yinghai@kernel.org> PCI: improve resource allocation under transparent bridges

We could run out of space under under 4g, but devices under transparent
bridges can use 64bit resources, so keep trying on the parent bus until
we hit a non-transparent bridge.

Impact: better support for assigning unassigned resources

Reviewed-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
32a9a682bef2f6fce7026bd94d1ce20028b0e52d 16-Mar-2009 Yuji Shimada <shimada-yxb@necst.nec.co.jp> PCI: allow assignment of memory resources with a specified alignment

This patch allows memory resources to be assigned with a specified
alignment at boot-time or run-time. The patch is useful when we use PCI
pass-through, because page-aligned memory resources are required to
securely share PCI resources with guest drivers.

If you want to assign the resource at boot time, please set
"pci=resource_alignment=" boot parameter.

This is format of "pci=resource_alignment=" boot parameter:

[<order of align>@][<domain>:]<bus>:<slot>.<func>[; ...]
Specifies alignment and device to reassign
aligned memory resources.
If <order of align> is not specified, PAGE_SIZE is
used as alignment.
PCI-PCI bridge can be specified, if resource
windows need to be expanded.

This is example:

pci=resource_alignment=20@07:00.0;18@0f:00.0;00:1d.7

If you want to assign the resource at run-time, please set
"/sys/bus/pci/resource_alignment" file, and hot-remove the device and
hot-add the device. For this purpose, fakephp or PCI hotplug interfaces
can be used.

The format of "/sys/bus/pci/resource_alignment" file is the same with
boot parameter. You can use "," instead of ";".

For example:

# cd /sys/bus/pci
# echo -n 20@12:00.0 > resource_alignment
# echo 1 > devices/0000:12:00.0/remove
# echo 1 > rescan

Reviewed-by: Alex Chiang <achiang@hp.com>
Reviewed-by: Yu Zhao <yu.zhao@intel.com>
Signed-off-by: Yuji Shimada <shimada-yxb@necst.nec.co.jp>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
613e7ed6f72b1a115f7ece8ce1b66cf095de1348 21-Nov-2008 Yu Zhao <yu.zhao@intel.com> PCI: add a new function to map BAR offsets

Add a function to map a given resource number to a corresponding
register so drivers can get the offset and type of device specific BARs.

Signed-off-by: Yu Zhao <yu.zhao@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
14add80b5120966fe0659d61815b9e9b4b68fdc5 21-Nov-2008 Yu Zhao <yu.zhao@intel.com> PCI: remove unnecessary arg of pci_update_resource()

This cleanup removes unnecessary argument 'struct resource *res' in
pci_update_resource(), so it takes same arguments as other companion
functions (pci_assign_resource(), etc.).

Signed-off-by: Yu Zhao <yu.zhao@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
104bafcfab7ce3031399e60069949f10acecc022 12-Dec-2008 Ingo Molnar <mingo@elte.hu> PCI: Don't carp about BAR allocation failures in quiet boot

These are easy to trigger (more or less harmlessly) with multiple video
cards, since the ROM BAR will typically not be given any space by the
BIOS bridge setup. No reason to punish quiet boot for this.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
022edd86d7c864bc8fadc3c8ac4e6a464472ab05 13-Oct-2008 Zhao, Yu <yu.zhao@intel.com> PCI: use resource_size() everywhere.

This is a cleanup that replaces the resource calculation formula with
resource_size().

Signed-off-by: Yu Zhao <yu.zhao@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
096e6f673dc02a6394dc9a7d8f8735c6978f5b91 20-Oct-2008 Benjamin Herrenschmidt <benh@kernel.crashing.org> pci: Use new %pR to print resource ranges

This converts things in drivers/pci to use %pR to printout the
content of a struct resource instead of hand-casted %llx or
other variants.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
80ccba1186d48fa728dc4b1456cc07ffb07da501 13-Jun-2008 Bjorn Helgaas <bjorn.helgaas@hp.com> PCI: use dev_printk when possible

Convert printks to use dev_printk().

I converted pr_debug() to dev_dbg(). Both use KERN_DEBUG and are enabled
only when DEBUG is defined.

I converted printk(KERN_DEBUG) to dev_printk(KERN_DEBUG), not to dev_dbg(),
because dev_dbg() is only enabled when DEBUG is defined.

I converted DBG(KERN_INFO) (only in setup-bus.c) to dev_info(). The DBG()
name makes it sound like debug, but it's been enabled forever, so dev_info()
preserves the previous behavior.

I tried to make the resource assignment formats more consistent, e.g.,
"BAR %d: got res [%#llx-%#llx] bus [%#llx-%#llx] flags %#lx\n"
instead of sometimes using "start-end" and sometimes using "size@start".
I'm not attached to one or the other; I'd just like them consistent.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
884525655d07fdee9245716b998ecdc45cdd8007 30-Mar-2008 Ivan Kokshaysky <ink@jurassic.park.msu.ru> PCI: clean up resource alignment management

Done per Linus' request and suggestions. Linus has explained that
better than I'll be able to explain:

On Thu, Mar 27, 2008 at 10:12:10AM -0700, Linus Torvalds wrote:
> Actually, before we go any further, there might be a less intrusive
> alternative: add just a couple of flags to the resource flags field (we
> still have something like 8 unused bits on 32-bit), and use those to
> implement a generic "resource_alignment()" routine.
>
> Two flags would do it:
>
> - IORESOURCE_SIZEALIGN: size indicates alignment (regular PCI device
> resources)
>
> - IORESOURCE_STARTALIGN: start field is alignment (PCI bus resources
> during probing)
>
> and then the case of both flags zero (or both bits set) would actually be
> "invalid", and we would also clear the IORESOURCE_STARTALIGN flag when we
> actually allocate the resource (so that we don't use the "start" field as
> alignment incorrectly when it no longer indicates alignment).
>
> That wouldn't be totally generic, but it would have the nice property of
> automatically at least add sanity checking for that whole "res->start has
> the odd meaning of 'alignment' during probing" and remove the need for a
> new field, and it would allow us to have a generic "resource_alignment()"
> routine that just gets a resource pointer.

Besides, I removed IORESOURCE_BUS_HAS_VGA flag which was unused for ages.

Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Gary Hade <garyhade@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
842de40d93e00a5c40a1a7f520a6fbe422994e99 04-Mar-2008 Bjorn Helgaas <bjorn.helgaas@hp.com> PCI: add generic pci_enable_resources()

Each architecture has its own pcibios_enable_resources() implementation.
These differ in many minor ways that have nothing to do with actual
architectural differences. Follow-on patches will make most arches
use this generic version instead.

This version is based on powerpc, which seemed most up-to-date. The only
functional difference from the x86 version is that this uses "!r->parent"
to check for resource collisions instead of "!r->start && r->end".

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2baad5f96b498812626eadb6f6af3eb41d8656a3 13-Feb-2008 Adrian Bunk <bunk@kernel.org> PCI: #if 0 pci_assign_resource_fixed()

An unused function that bloated the kernel only when CONFIG_EMBEDDED was
enabled...

Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
6015fbefc4dfe1706b64d33c256878b8296d1470 10-Dec-2007 Benjamin Herrenschmidt <benh@kernel.crashing.org> PCI: Fix warning in setup-res.c on 32-bit platforms with 64-bit resources

This adds appropriate casts to avoid a warning and print the correct
values in pr_debug.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
eb003ec26556057e5f27d4b989bbb432d0bdc0f4 27-Oct-2007 Adrian Bunk <bunk@kernel.org> PCI: drivers/pci/: remove unused exports

This patch removes the following unused exports:
- remove the following unused EXPORT_SYMBOL's:
- pci-acpi.c: pci_osc_support_set
- proc.c: pci_proc_detach_bus
- remove the following unused EXPORT_SYMBOL_GPL's:
- bus.c: pci_walk_bus
- probe.c: pci_create_bus
- setup-res.c: pci_claim_resource

Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
96bde06a2df1b363206d3cdef53134b84ff37813 27-Mar-2007 Sam Ravnborg <sam@ravnborg.org> pci: do not mark exported functions as __devinit

Functions marked __devinit will be removed after kernel init. But being
exported they are potentially called by a module much later.

So the safer choice seems to be to keep the function even in the non
CONFIG_HOTPLUG case.

This silence the follwoing section mismatch warnings:
WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_add_device from __ksymtab_gpl between '__ksymtab_pci_bus_add_device' (at offset 0x20) and '__ksymtab_pci_walk_bus'
WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_create_bus from __ksymtab_gpl between '__ksymtab_pci_create_bus' (at offset 0x40) and '__ksymtab_pci_stop_bus_device'
WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_max_busnr from __ksymtab_gpl between '__ksymtab_pci_bus_max_busnr' (at offset 0xc0) and '__ksymtab_pci_assign_resource_fixed'
WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_claim_resource from __ksymtab_gpl between '__ksymtab_pci_claim_resource' (at offset 0xe0) and '__ksymtab_pcie_port_bus_type'
WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_add_devices from __ksymtab between '__ksymtab_pci_bus_add_devices' (at offset 0x70) and '__ksymtab_pci_bus_alloc_resource'
WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_scan_bus_parented from __ksymtab between '__ksymtab_pci_scan_bus_parented' (at offset 0x90) and '__ksymtab_pci_root_buses'
WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_assign_resources from __ksymtab between '__ksymtab_pci_bus_assign_resources' (at offset 0x4d0) and '__ksymtab_pci_bus_size_bridges'
WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_size_bridges from __ksymtab between '__ksymtab_pci_bus_size_bridges' (at offset 0x4e0) and '__ksymtab_pci_setup_cardbus'

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
fb0f2b40faff41f03acaa2ee6e6231fc96ca497c 19-Dec-2006 Ralf Baechle <ralf@linux-mips.org> PCI legacy resource fix

Since commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f 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>
e31dd6e4520439ceae4753f32dd2da2c345e929a 13-Jun-2006 Greg Kroah-Hartman <gregkh@suse.de> [PATCH] 64bit resource: change pci core and arch code to use resource_size_t

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>
1396a8c3f7cec9f5e0d00bd089be21fc468f0f1c 13-Jun-2006 Greg Kroah-Hartman <gregkh@suse.de> [PATCH] 64bit resource: fix up printks for resources in pci core and hotplug drivers

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>
75acfecaa031c0e1bc412cee4fe58ba49ff3406c 01-May-2006 Kumar Gala <galak@kernel.crashing.org> [PATCH] PCI: Add pci_assign_resource_fixed -- allow fixed address assignments

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>
dd8c49966854a5245f3ed4769c9114e7afd819ef 10-Jan-2006 linas <linas@austin.ibm.com> [PATCH] PCI Hotplug/powerpc: module build break

The RPAPHP hoplug driver will not build as a module, because it calls
on pci_claim_resource(), which is not exported. This exports the symbol.
Problem reported by Olaf Hering <olh@suse.de>

A grep indicates that building drivers/parisc/lba_pci.c
would have trouble building as a module for the same reason.

Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
085ae41f66657a9655ce832b0a61832a06f0e1dc 08-Aug-2005 David S. Miller <davem@davemloft.net> [PATCH] Make sparc64 use setup-res.c

There were three changes necessary in order to allow
sparc64 to use setup-res.c:

1) Sparc64 roots the PCI I/O and MEM address space using
parent resources contained in the PCI controller structure.
I'm actually surprised no other platforms do this, especially
ones like Alpha and PPC{,64}. These resources get linked into the
iomem/ioport tree when PCI controllers are probed.

So the hierarchy looks like this:

iomem --|
PCI controller 1 MEM space --|
device 1
device 2
etc.
PCI controller 2 MEM space --|
...
ioport --|
PCI controller 1 IO space --|
...
PCI controller 2 IO space --|
...

You get the idea. The drivers/pci/setup-res.c code allocates
using plain iomem_space and ioport_space as the root, so that
wouldn't work with the above setup.

So I added a pcibios_select_root() that is used to handle this.
It uses the PCI controller struct's io_space and mem_space on
sparc64, and io{port,mem}_resource on every other platform to
keep current behavior.

2) quirk_io_region() is buggy. It takes in raw BUS view addresses
and tries to use them as a PCI resource.

pci_claim_resource() expects the resource to be fully formed when
it gets called. The sparc64 implementation would do the translation
but that's absolutely wrong, because if the same resource gets
released then re-claimed we'll adjust things twice.

So I fixed up quirk_io_region() to do the proper pcibios_bus_to_resource()
conversion before passing it on to pci_claim_resource().

3) I was mistakedly __init'ing the function methods the PCI controller
drivers provide on sparc64 to implement some parts of these
routines. This was, of course, easy to fix.

So we end up with the following, and that nasty SPARC64 makefile
ifdef in drivers/pci/Makefile is finally zapped.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
064b53dbcc977dbf2753a67c2b8fc1c061d74f21 27-Jul-2005 John W. Linville <linville@tuxdriver.com> [PATCH] PCI: restore BAR values after D3hot->D0 for devices that need it

Some PCI devices (e.g. 3c905B, 3c556B) lose all configuration
(including BARs) when transitioning from D3hot->D0. This leaves such
a device in an inaccessible state. The patch below causes the BARs
to be restored when enabling such a device, so that its driver will
be able to access it.

The patch also adds pci_restore_bars as a new global symbol, and adds a
correpsonding EXPORT_SYMBOL_GPL for that.

Some firmware (e.g. Thinkpad T21) leaves devices in D3hot after a
(re)boot. Most drivers call pci_enable_device very early, so devices
left in D3hot that lose configuration during the D3hot->D0 transition
will be inaccessible to their drivers.

Drivers could be modified to account for this, but it would
be difficult to know which drivers need modification. This is
especially true since often many devices are covered by the same
driver. It likely would be necessary to replicate code across dozens
of drivers.

The patch below should trigger only when transitioning from D3hot->D0
(or at boot), and only for devices that have the "no soft reset" bit
cleared in the PM control register. I believe it is safe to include
this patch as part of the PCI infrastructure.

The cleanest implementation of pci_restore_bars was to call
pci_update_resource. Unfortunately, that does not currently exist
for the sparc64 architecture. The patch below includes a null
implemenation of pci_update_resource for sparc64.

Some have expressed interest in making general use of the the
pci_restore_bars function, so that has been exported to GPL licensed
modules.

Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
755528c860b05fcecda1c88a2bdaffcb50760a7f 26-Aug-2005 Linus Torvalds <torvalds@g5.osdl.org> Ignore disabled ROM resources at setup

Writing even a disabled value seems to mess up some matrox graphics
cards. It may be a card-related issue, but we may also be writing
reserved low bits in the result.

This was a fall-out of switching x86 over to the generic PCI resource
allocation code, and needs more debugging. In particular, the old x86
code defaulted to not doing any resource allocations at all for ROM
resources.

In the meantime, this has been reported to make X happier by Helge
Hafting <helgehaf@aitel.hist.no>.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
dc836b5b6fcde95f750a4790d8200fabaf563dc9 09-Aug-2005 Linus Torvalds <torvalds@g5.osdl.org> Revert "[PATCH] PCI: restore BAR values..."

Revert commit fec59a711eef002d4ef9eb8de09dd0a26986eb77, which is
breaking sparc64 that doesn't have a working pci_update_resource.

We'll re-do this after 2.6.13 when we'll do it all properly.
cf7bee5a0bf270a4eace0be39329d6ac0136cc47 07-Aug-2005 Ivan Kokshaysky <ink@jurassic.park.msu.ru> [PATCH] Fix restore of 64-bit PCI BAR's

For 64-bit BAR[i] only pci_dev->resource[i] is valid, ->resource[i+1]
slot is unused and contains zeroes in all fields.

So when we update a PCI BAR, all we need is just to check that we're
going to update a _valid_ resource.

Also make sure to write high bits - use "x >> 16 >> 16" (rather than the
simpler ">> 32") to avoid warnings on 32-bit architectures where we're
not going to have any high bits.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
fec59a711eef002d4ef9eb8de09dd0a26986eb77 05-Aug-2005 John W. Linville <linville@tuxdriver.com> [PATCH] PCI: restore BAR values after D3hot->D0 for devices that need it

Some PCI devices (e.g. 3c905B, 3c556B) lose all configuration
(including BARs) when transitioning from D3hot->D0. This leaves such
a device in an inaccessible state. The patch below causes the BARs
to be restored when enabling such a device, so that its driver will
be able to access it.

The patch also adds pci_restore_bars as a new global symbol, and adds a
correpsonding EXPORT_SYMBOL_GPL for that.

Some firmware (e.g. Thinkpad T21) leaves devices in D3hot after a
(re)boot. Most drivers call pci_enable_device very early, so devices
left in D3hot that lose configuration during the D3hot->D0 transition
will be inaccessible to their drivers.

Drivers could be modified to account for this, but it would
be difficult to know which drivers need modification. This is
especially true since often many devices are covered by the same
driver. It likely would be necessary to replicate code across dozens
of drivers.

The patch below should trigger only when transitioning from D3hot->D0
(or at boot), and only for devices that have the "no soft reset" bit
cleared in the PM control register. I believe it is safe to include
this patch as part of the PCI infrastructure.

The cleanest implementation of pci_restore_bars was to call
pci_update_resource. Unfortunately, that does not currently exist
for the sparc64 architecture. The patch below includes a null
implemenation of pci_update_resource for sparc64.

Some have expressed interest in making general use of the the
pci_restore_bars function, so that has been exported to GPL licensed
modules.

Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 17-Apr-2005 Linus Torvalds <torvalds@ppc970.osdl.org> Linux-2.6.12-rc2

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!