#
dc4e6f21 |
|
06-Nov-2021 |
Puranjay Mohan <puranjay12@gmail.com> |
PCI: Use resource names in PCI log messages Use the pci_resource_name() to get the name of the resource and use it while printing log messages. [bhelgaas: rename to match struct resource * names, also use names in other BAR messages] Link: https://lore.kernel.org/r/20211106112606.192563-3-puranjay12@gmail.com Signed-off-by: Puranjay Mohan <puranjay12@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
62008578 |
|
15-Jan-2021 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Fix printk field formatting Previously we used "%#08x" to print a 32-bit value. This fills an 8-character field with "0x...", but of course many 32-bit values require a 10-character field "0x12345678" for this format. Fix the formats to avoid confusion. Link: https://lore.kernel.org/r/20230824193712.542167-5-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
#
09cc9006 |
|
30-Mar-2023 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
PCI: Introduce pci_dev_for_each_resource() Instead of open-coding it everywhere introduce a tiny helper that can be used to iterate over each resource of a PCI device, and convert the most obvious users into it. While at it drop doubled empty line before pdev_sort_resources(). No functional changes intended. Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230330162434.35055-4-andriy.shevchenko@linux.intel.com Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
|
#
0e328183 |
|
21-Sep-2022 |
Maciej W. Rozycki <macro@orcam.me.uk> |
PCI: Sanitise firmware BAR assignments behind a PCI-PCI bridge When pci_assign_resource() is unable to assign resources to a BAR, it uses pci_revert_fw_address() to fall back to a firmware assignment (if any). Previously pci_revert_fw_address() assumed all addresses could reach the device, but this is not true if the device is below a bridge that only forwards addresses within its windows. This problem was observed on a Tyan Tomcat IV S1564D system where the BIOS did not assign valid addresses to several bridges and USB devices: pci 0000:00:11.0: PCI-to-PCIe bridge to [bus 01-ff] pci 0000:00:11.0: bridge window [io 0xe000-0xefff] pci 0000:01:00.0: PCIe Upstream Port to [bus 02-ff] pci 0000:01:00.0: bridge window [io 0x0000-0x0fff] # unreachable pci 0000:02:02.0: PCIe Downstream Port to [bus 05-ff] pci 0000:02:02.0: bridge window [io 0x0000-0x0fff] # unreachable pci 0000:05:00.0: PCIe-to-PCI bridge to [bus 06-ff] pci 0000:05:00.0: bridge window [io 0x0000-0x0fff] # unreachable pci 0000:06:08.0: USB UHCI 1.1 pci 0000:06:08.0: BAR 4: [io 0xfce0-0xfcff] # unreachable pci 0000:06:08.1: USB UHCI 1.1 pci 0000:06:08.1: BAR 4: [io 0xfce0-0xfcff] # unreachable pci 0000:06:08.0: can't claim BAR 4 [io 0xfce0-0xfcff]: no compatible bridge window pci 0000:06:08.1: can't claim BAR 4 [io 0xfce0-0xfcff]: no compatible bridge window During the first pass of assigning unassigned resources, there was not enough I/O space available, so we couldn't assign the 06:08.0 BAR and reverted to the firmware assignment (still unreachable). Reverting the 06:08.1 assignment failed because it conflicted with 06:08.0: pci 0000:00:11.0: bridge window [io 0xe000-0xefff] pci 0000:01:00.0: no space for bridge window [io size 0x2000] pci 0000:02:02.0: no space for bridge window [io size 0x1000] pci 0000:05:00.0: no space for bridge window [io size 0x1000] pci 0000:06:08.0: BAR 4: no space for [io size 0x0020] pci 0000:06:08.0: BAR 4: trying firmware assignment [io 0xfce0-0xfcff] pci 0000:06:08.1: BAR 4: no space for [io size 0x0020] pci 0000:06:08.1: BAR 4: trying firmware assignment [io 0xfce0-0xfcff] pci 0000:06:08.1: BAR 4: [io 0xfce0-0xfcff] conflicts with 0000:06:08.0 [io 0xfce0-0xfcff] A subsequent pass assigned valid bridge windows and a valid 06:08.1 BAR, but left the 06:08.0 BAR alone, so the UHCI device was still unusable: pci 0000:00:11.0: bridge window [io 0xe000-0xefff] released pci 0000:00:11.0: bridge window [io 0x1000-0x2fff] # reassigned pci 0000:01:00.0: bridge window [io 0x1000-0x2fff] # reassigned pci 0000:02:02.0: bridge window [io 0x2000-0x2fff] # reassigned pci 0000:05:00.0: bridge window [io 0x2000-0x2fff] # reassigned pci 0000:06:08.0: BAR 4: assigned [io 0xfce0-0xfcff] # left alone pci 0000:06:08.1: BAR 4: assigned [io 0x2000-0x201f] ... uhci_hcd 0000:06:08.0: host system error, PCI problems? uhci_hcd 0000:06:08.0: host controller process error, something bad happened! uhci_hcd 0000:06:08.0: host controller halted, very bad! uhci_hcd 0000:06:08.0: HCRESET not completed yet! uhci_hcd 0000:06:08.0: HC died; cleaning up If the address assigned by firmware is not reachable because it's not within upstream bridge windows, fail instead of assigning the unusable address from firmware. [bhelgaas: commit log, use pci_upstream_bridge()] Link: https://bugzilla.kernel.org/show_bug.cgi?id=16263 Link: https://lore.kernel.org/r/alpine.DEB.2.21.2203012338460.46819@angie.orcam.me.uk Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209211921250.29493@angie.orcam.me.uk Fixes: 58c84eda0756 ("PCI: fall back to original BIOS BAR addresses") Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # v2.6.35+
|
#
500b55b0 |
|
21-Dec-2021 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Work around Intel I210 ROM BAR overlap defect Per PCIe r5, sec 7.5.1.2.4, a device must not claim accesses to its Expansion ROM unless both the Memory Space Enable and the Expansion ROM Enable bit are set. But apparently some Intel I210 NICs don't work correctly if the ROM BAR overlaps another BAR, even if the Expansion ROM is disabled. Michael reported that on a Kontron SMARC-sAL28 ARM64 system with U-Boot v2021.01-rc3, the ROM BAR overlaps BAR 3, and networking doesn't work at all: BAR 0: 0x40000000 (32-bit, non-prefetchable) [size=1M] BAR 3: 0x40200000 (32-bit, non-prefetchable) [size=16K] ROM: 0x40200000 (disabled) [size=1M] NETDEV WATCHDOG: enP2p1s0 (igb): transmit queue 0 timed out Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier (DT) igb 0002:01:00.0 enP2p1s0: Reset adapter Previously, pci_std_update_resource() wrote the assigned ROM address to the BAR only when the ROM was enabled. This meant that the I210 ROM BAR could be left with an address assigned by firmware, which might overlap with other BARs. Quirk these I210 devices so pci_std_update_resource() always writes the assigned address to the ROM BAR, whether or not the ROM is enabled. Link: https://lore.kernel.org/r/20211223163754.GA1267351@bhelgaas Link: https://lore.kernel.org/r/20201230185317.30915-1-michael@walle.cc Link: https://bugzilla.kernel.org/show_bug.cgi?id=211105 Reported-by: Michael Walle <michael@walle.cc> Tested-by: Michael Walle <michael@walle.cc> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
729e3a66 |
|
09-Jan-2021 |
Ard Biesheuvel <ardb@kernel.org> |
PCI: Decline to resize resources if boot config must be preserved The _DSM #5 method in the ACPI host bridge object tells us whether the OS must preserve the resource assignments done by firmware. If this is the case, we should not permit drivers to resize BARs on the fly. Make pci_resize_resource() take this into account. Link: https://lore.kernel.org/r/20210109095353.13417-1-ardb@kernel.org Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # v5.4+
|
#
16bbbc87 |
|
29-Jun-2020 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Replace lkml.org, spinics, gmane with lore.kernel.org The lkml.org, spinics.net, and gmane.org archives are not very reliable and, in some cases, not even easily accessible. Replace links to them with links to lore.kernel.org, the archives hosted by kernel.org. I found the gmane items via the Wayback Machine archive at https://web.archive.org/. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
d09ddd81 |
|
21-Apr-2020 |
Ard Biesheuvel <ardb@kernel.org> |
PCI: Allow pci_resize_resource() for devices on root bus When resizing a BAR, pci_reassign_bridge_resources() is invoked to bring the bridge windows of parent bridges in line with the new BAR assignment. This assumes the device whose BAR is being resized lives on a subordinate bus, but this is not necessarily the case. A device may live on the root bus, in which case dev->bus->self is NULL, and passing a NULL pci_dev pointer to pci_reassign_bridge_resources() will cause it to crash. So let's make the call to pci_reassign_bridge_resources() conditional on whether dev->bus->self is non-NULL in the first place. Fixes: 8bb705e3e79d84e7 ("PCI: Add pci_resize_resource() for resizing BARs") Link: https://lore.kernel.org/r/20200421162256.26887-1-ardb@kernel.org Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Christian König <christian.koenig@amd.com>
|
#
adf58458 |
|
10-Apr-2018 |
Desnes A. Nunes do Rosario <desnesn@linux.vnet.ibm.com> |
PCI: Remove messages about reassigning resources When reassigning device resources to increase their alignment, e.g., because of a "pci=resource_alignment=" kernel parameter or because the platform aligns resources to its page size, we previously emitted messages like this: pci 0000:00:00.0: Disabling memory decoding and releasing memory resources pci 0000:00:00.0: disabling bridge mem windows These messages don't convey any useful information, so remove them. Fixes: 38274637699 ("powerpc/powernv: Override pcibios_default_alignment() to force PCI devices to be page aligned") Signed-off-by: Desnes A. Nunes do Rosario <desnesn@linux.vnet.ibm.com> [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
|
#
df62ab5e |
|
09-Mar-2018 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Tidy comments Remove pointless comments that tell us the file name, remove blank line comments, follow multi-line comment conventions. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
c37406e0 |
|
26-Feb-2018 |
Christian König <ckoenig.leichtzumerken@gmail.com> |
PCI: Allow release of resources that were never assigned It is entirely possible that the BIOS wasn't able to assign resources to a device. In this case don't crash in pci_release_resource() when we try to resize the resource. Fixes: 8bb705e3e79d ("PCI: Add pci_resize_resource() for resizing BARs") Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> CC: stable@vger.kernel.org # v4.15+
|
#
7506dc79 |
|
17-Jan-2018 |
Frederick Lawler <fred@fredlawl.com> |
PCI: Add wrappers for dev_printk() Add PCI-specific dev_printk() wrappers and use them to simplify the code slightly. No functional change intended. Signed-off-by: Frederick Lawler <fred@fredlawl.com> [bhelgaas: squash into one patch] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
b2441318 |
|
01-Nov-2017 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
License cleanup: add SPDX GPL-2.0 license identifier to files with no license Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
8bb705e3 |
|
24-Oct-2017 |
Christian König <christian.koenig@amd.com> |
PCI: Add pci_resize_resource() for resizing BARs Add a pci_resize_resource() interface to allow device drivers to resize BARs of their devices. This is useful for devices with large local storage, e.g., graphics devices. These devices often only expose 256MB BARs initially to be compatible with 32-bit systems. This function only tries to reprogram the windows of the bridge directly above the requesting device and only the BAR of the same type (usually mem, 64bit, prefetchable). This is done to avoid disturbing other drivers by changing the BARs of their devices. Drivers should use the following sequence to resize their BARs: 1. Disable memory decoding of the device using the PCI cfg dword. 2. Use pci_release_resource() to release all BARs which can move during the resize, including the one you want to resize. 3. Call pci_resize_resource() for each BAR you want to resize. 4. Call pci_assign_unassigned_bus_resources() to reassign new locations for all BARs which are not resized, but could move. 5. If everything worked as expected, enable memory decoding in the device again using the PCI cfg dword. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
ecf677c8 |
|
02-Aug-2017 |
Palmer Dabbelt <palmer@dabbelt.com> |
PCI: Add a generic weak pcibios_align_resource() Multiple architectures define this as a trivial function, and I'm adding another one as part of the RISC-V port. Add a __weak version of pcibios_align_resource() and delete the now-obselete ones in a handful of ports. The only functional change should be that a handful of ports used to export pcibios_fixup_bus(). Only some architectures export this, so I just dropped it. Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
76dc5268 |
|
14-Apr-2017 |
Matthias Kaehlcke <mka@chromium.org> |
PCI: Make PCI_ROM_ADDRESS_MASK a 32-bit constant A 64-bit value is not needed since a PCI ROM address consists in 32 bits. This fixes a clang warning about "implicit conversion from 'unsigned long' to 'u32'". Also remove now unnecessary casts to u32 from __pci_read_base() and pci_std_update_resource(). Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
0b457dde |
|
28-Nov-2016 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Add comments about ROM BAR updating pci_update_resource() updates a hardware BAR so its address matches the kernel's struct resource UNLESS it's a disabled ROM BAR. We only update those when we enable the ROM. It's not obvious from the code why ROM BARs should be handled specially. Apparently there are Matrox devices with defective ROM BARs that read as zero when disabled. That means that if pci_enable_rom() reads the disabled BAR, sets PCI_ROM_ADDRESS_ENABLE (without re-inserting the address), and writes it back, it would enable the ROM at address zero. Add comments and references to explain why we can't make the code look more rational. The code changes are from 755528c860b0 ("Ignore disabled ROM resources at setup") and 8085ce084c0f ("[PATCH] Fix PCI ROM mapping"). Link: https://lkml.org/lkml/2005/8/30/138 Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
|
#
286c2378 |
|
28-Nov-2016 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Remove pci_resource_bar() and pci_iov_resource_bar() pci_std_update_resource() only deals with standard BARs, so we don't have to worry about the complications of VF BARs in an SR-IOV capability. Compute the BAR address inline and remove pci_resource_bar(). That makes pci_iov_resource_bar() unused, so remove that as well. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
|
#
6ffa2489 |
|
28-Nov-2016 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Separate VF BAR updates from standard BAR updates Previously pci_update_resource() used the same code path for updating standard BARs and VF BARs in SR-IOV capabilities. Split the VF BAR update into a new pci_iov_update_resource() internal interface, which makes it simpler to compute the BAR address (we can get rid of pci_resource_bar() and pci_iov_resource_bar()). This patch: - Renames pci_update_resource() to pci_std_update_resource(), - Adds pci_iov_update_resource(), - Makes pci_update_resource() a wrapper that calls the appropriate one, No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
|
#
45d004f4 |
|
29-Nov-2016 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Update BARs using property bits appropriate for type The BAR property bits (0-3 for memory BARs, 0-1 for I/O BARs) are supposed to be read-only, but we do save them in res->flags and include them when updating the BAR. Mask the I/O property bits with ~PCI_BASE_ADDRESS_IO_MASK (0x3) instead of PCI_REGION_FLAG_MASK (0xf) to make it obvious that we can't corrupt bits 2-3 of I/O addresses. Use PCI_ROM_ADDRESS_MASK for ROM BARs. This means we'll only check the top 21 bits (instead of the 28 bits we used to check) of a ROM BAR to see if the update was successful. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
63880b23 |
|
28-Nov-2016 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Ignore BAR updates on virtual functions VF BARs are read-only zero, so updating VF BARs will not have any effect. See the SR-IOV spec r1.1, sec 3.4.1.11. We already ignore these updates because of 70675e0b6a1a ("PCI: Don't try to restore VF BARs"); this merely restructures it slightly to make it easier to split updates for standard and SR-IOV BARs. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
|
#
16d917b1 |
|
08-Nov-2016 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Don't attempt to claim shadow copies of ROM If we're using a shadow copy of a PCI device ROM, the shadow copy is in RAM and the device never sees accesses to it and doesn't respond to it. We don't have to route the shadow range to the PCI device, and the device doesn't have to claim the range. Previously we treated the shadow copy as though it were the ROM BAR, and we failed to claim it because the region wasn't routed to the device: pci 0000:01:00.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff] pci_bus 0000:01: Allocating resources pci 0000:01:00.0: can't claim BAR 6 [mem 0x000c0000-0x000dffff]: no compatible bridge window The failure path of pcibios_allocate_dev_rom_resource() cleared out the resource start address, which also caused the following ioremap() warning: WARNING: CPU: 0 PID: 116 at /build/linux-akdJXO/linux-4.8.0/arch/x86/mm/ioremap.c:121 __ioremap_caller+0x1ec/0x370 ioremap on RAM at 0x0000000000000000 - 0x000000000001ffff Handle an option ROM shadow copy as RAM, without trying to insert it into the iomem resource tree. This fixes a regression caused by 0c0e0736acad ("PCI: Set ROM shadow location in arch code, not in PCI core"), which appeared in v4.6. The regression causes video device initialization to fail. This was reported on AMD Turks, but it likely affects others as well. Fixes: 0c0e0736acad ("PCI: Set ROM shadow location in arch code, not in PCI core") Reported-and-tested-by: Vecu Bosseur <vecu.bosseur@gmail.com> Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1627496 Link: https://bugzilla.kernel.org/show_bug.cgi?id=175391 Link: https://bugzilla.redhat.com/show_bug.cgi?id=1352272 Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v4.6+
|
#
2ea4adf7 |
|
01-Mar-2016 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Don't assign or reassign immutable resources IORESOURCE_PCI_FIXED means the resource can't be moved, so if it's set, don't bother trying to assign or reassign the resource. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
0b26cd69 |
|
21-Sep-2015 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Clear IORESOURCE_UNSET when reverting to firmware-assigned address If pci_assign_resource() fails to assign space for a BAR, we may restore the BAR to whatever firmware left there at boot-time (this depends on whether the arch implements pcibios_retrieve_fw_addr()). The messages we print are not as useful as they could be: pci 0000:00:01.0: BAR 15: assigned [mem 0xc0000000-0xc01fffff 64bit pref] pci 0000:01:00.0: BAR 0: no space for [mem size 0x10000000 pref] pci 0000:01:00.0: BAR 0: trying firmware assignment [mem size 0x10000000 pref] pci 0000:01:00.0: BAR 0: [mem size 0x10000000 pref] conflicts with PCI Bus 0000:00 [mem 0xc0000000-0xffffffff window] The last two lines should contain the actual BAR address, not the size. Clear IORESOURCE_UNSET so we print the address. If requesting the firmware-assigned resource fails, mark it IORESOURCE_UNSET again. This is a cosmetic change to clarify the message: previously, if pci_revert_fw_address() succeeded, pci_assign_resource() cleared IORESOURCE_UNSET anyway, so this isn't really a functional change. Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491#c50 Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
70675e0b |
|
29-Jul-2015 |
Wei Yang <weiyang@linux.vnet.ibm.com> |
PCI: Don't try to restore VF BARs VF BARs are read-only zero, so updating VF BARs will not have any effect. See the SR-IOV spec r1.1, sec 3.4.1.11. Don't update VF BARs in pci_restore_bars(). This avoids spurious "BAR %d: error updating" messages that we see when doing vfio pass-through after 6eb7018705de ("vfio-pci: Move idle devices to D3hot power state"). [bhelgaas: changelog, fix whitespace] Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
c770cb4c |
|
11-Mar-2015 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Mark invalid BARs as unassigned If a BAR is not inside any upstream bridge window, or if it conflicts with another resource, mark it as IORESOURCE_UNSET so we don't try to use it. We may be able to assign a different address for it. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
64da465e |
|
08-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>
|
#
94778835 |
|
08-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>
|
#
28f6dbe2 |
|
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>
|
#
c3337708 |
|
03-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+
|
#
227f0647 |
|
18-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>
|
#
b7fe9434 |
|
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>
|
#
67d29b5c |
|
19-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>
|
#
d3689df0 |
|
19-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>
|
#
5b285415 |
|
19-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>
|
#
56a3d182 |
|
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>
|
#
3cedcc36 |
|
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>
|
#
29003beb |
|
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>
|
#
cd8a4d36 |
|
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>
|
#
434aafc1 |
|
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>
|
#
bd064f0a |
|
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>
|
#
fc279850 |
|
09-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>
|
#
f7625980 |
|
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>
|
#
b638d7e7 |
|
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>
|
#
fe6dacdb |
|
11-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>
|
#
d6776e6d |
|
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>
|
#
9aac537e |
|
09-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>
|
#
2069ecfb |
|
15-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>
|
#
78c3b329 |
|
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>
|
#
a4ac9fea |
|
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>
|
#
0dea210b |
|
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>
|
#
6535943f |
|
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>
|
#
351fc6d1 |
|
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>
|
#
85b8582d |
|
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>
|
#
363c75db |
|
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>
|
#
2bbc6942 |
|
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>
|
#
28c6821a |
|
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>
|
#
1bcd495b |
|
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>
|
#
58c84eda |
|
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>
|
#
f6d440da |
|
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>
|
#
966f3a75 |
|
11-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>
|
#
865df576 |
|
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>
|
#
c7dabef8 |
|
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>
|
#
a369c791 |
|
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>
|
#
b812cca4 |
|
05-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>
|
#
eaa959df |
|
30-Jun-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>
|
#
6faf17f6 |
|
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>
|
#
79896cf4 |
|
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>
|
#
cebd78a8 |
|
17-Jun-2009 |
Matthew Wilcox <willy@infradead.org> |
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>
|
#
d09ee968 |
|
23-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>
|
#
32a9a682 |
|
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>
|
#
613e7ed6 |
|
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>
|
#
14add80b |
|
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>
|
#
104bafcf |
|
11-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>
|
#
022edd86 |
|
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>
|
#
096e6f67 |
|
19-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>
|
#
80ccba11 |
|
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>
|
#
88452565 |
|
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>
|
#
842de40d |
|
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>
|
#
2baad5f9 |
|
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>
|
#
6015fbef |
|
09-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>
|
#
eb003ec2 |
|
26-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>
|
#
96bde06a |
|
26-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>
|
#
fb0f2b40 |
|
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>
|
#
e31dd6e4 |
|
12-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>
|
#
1396a8c3 |
|
12-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>
|
#
75acfeca |
|
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>
|
#
dd8c4996 |
|
10-Jan-2006 |
Linas Vepstas <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>
|
#
085ae41f |
|
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>
|
#
064b53db |
|
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>
|
#
755528c8 |
|
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>
|
#
dc836b5b |
|
08-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.
|
#
cf7bee5a |
|
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>
|
#
fec59a71 |
|
04-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>
|
#
1da177e4 |
|
16-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!
|