summaryrefslogtreecommitdiffstats
path: root/drivers/pci/rom.c
AgeCommit message (Collapse)AuthorFilesLines
2017-11-08PCI: Fail pci_map_rom() if the option ROM is invalidChangbin Du1-0/+5
If we detect a invalid PCI option ROM (e.g., invalid ROM header signature), we should unmap it immediately and fail. It doesn't make any sense to return a mapped area with size of 0. I have seen this case on Intel GVTg vGPU, which has no VBIOS. It will not cause a real problem, but we should skip it as early as possible. Signed-off-by: Changbin Du <changbin.du@intel.com> [bhelgaas: split non-functional change into separate patch] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-11-08PCI: Move pci_map_rom() error pathChangbin Du1-6/+8
Move pci_map_rom() error code to the end to prepare for adding another error path. No functional change intended. Signed-off-by: Changbin Du <changbin.du@intel.com> [bhelgaas: split non-functional change into separate patch] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-11-29PCI: Add comments about ROM BAR updatingBjorn Helgaas1-0/+5
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>
2016-03-12PCI: Remove unused IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPYBjorn Helgaas1-30/+1
The IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY bits are unused. Remove them and code that depends on them. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-03-12PCI: Clean up pci_map_rom() whitespaceBjorn Helgaas1-19/+18
Remove unnecessary indentation in pci_map_rom(). This is logically part of the previous patch; I split it out to make the critical changes in that patch more obvious. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-03-08PCI: Set ROM shadow location in arch code, not in PCI coreBjorn Helgaas1-11/+0
IORESOURCE_ROM_SHADOW means there is a copy of a device's option ROM in RAM. The existence of such a copy and its location are arch-specific. Previously the IORESOURCE_ROM_SHADOW flag was set in arch code, but the 0xC0000-0xDFFFF location was hard-coded into the PCI core. If we're using a shadow copy in RAM, disable the ROM BAR and release the address space it was consuming. Move the location information from the PCI core to the arch code that sets IORESOURCE_ROM_SHADOW. Save the location of the RAM copy in the struct resource for PCI_ROM_RESOURCE. After this change, pci_map_rom() will call pci_assign_resource() and pci_enable_rom() for these IORESOURCE_ROM_SHADOW resources, which we did not do before. This is safe because: - pci_assign_resource() will do nothing because the resource is marked IORESOURCE_PCI_FIXED, which means we can't move it, and - pci_enable_rom() will not turn on the ROM BAR's enable bit because the resource is marked IORESOURCE_ROM_SHADOW, which means it is in RAM rather than in PCI memory space. Storing the location in the struct resource means "lspci" will show the shadow location, not the value from the ROM BAR. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-03-08PCI: Don't enable/disable ROM BAR if we're using a RAM shadow copyBjorn Helgaas1-4/+12
If we're using a RAM shadow copy instead of the ROM BAR, we don't need to touch the ROM BAR enable bit. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-01-15Merge branches 'pci/hotplug' and 'pci/resource' into nextBjorn Helgaas1-0/+3
* pci/hotplug: PCI: ibmphp: Remove unneeded NULL test PCI: hotplug: Use list_for_each_entry() to simplify code PCI: acpiphp_ibm: Fix null dereferences on null ibm_slot * pci/resource: PCI: Avoid iterating through memory outside the resource window PCI: Fix minimum allocation address overwrite
2016-01-08PCI: Avoid iterating through memory outside the resource windowEdward O'Callaghan1-0/+3
If the 'image' pointer has been advanced more than 'size', we've already iterated through memory outside the resource window. We have zero control over whatever we find in the option ROM, if it's even an option ROM and not just an accident of random data just happening to look like an option ROM. Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2015-12-10PCI: Print warnings for all invalid expansion ROM headersVladis Dronov1-12/+8
We've always validated that both bytes of the Expansion ROM signature and all four bytes of the PCI Data Structure signature (see PCI Firmware spec r3.0, sec 5.1.1), but we only printed a warning if the first byte of the ROM signature was invalid. Print warnings if *any* of those bytes are invalid. Note that we only look at these headers if we map or read the ROM. [bhelgaas: changelog, tweak printk format] Signed-off-by: Vladis Dronov <vdronov@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2015-01-23PCI: Fix infinite loop with ROM image of size 0Michel Dänzer1-3/+4
If the image size would ever read as 0, pci_get_rom_size() could keep processing the same image over and over again. Exit the loop if we ever read a length of zero. This fixes a soft lockup on boot when the radeon driver calls pci_get_rom_size() on an AMD Radeon R7 250X PCIe discrete graphics card. [bhelgaas: changelog, reference] Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386973 Reported-by: Federico <federicotg@gmail.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> CC: stable@vger.kernel.org
2014-06-10PCI: Whitespace cleanupRyan Desfosses1-2/+2
Fix various whitespace errors. No functional change. [bhelgaas: fix other similar problems] Signed-off-by: Ryan Desfosses <ryan@desfo.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-06-10PCI: Move EXPORT_SYMBOL so it immediately follows function/variableRyan Desfosses1-5/+4
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>
2014-02-27PCI: Mark resources as IORESOURCE_UNSET if we can't assign themBjorn Helgaas1-0/+2
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>
2013-12-21PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_devYinghai Lu1-1/+1
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>
2013-03-26PCI: Add PCI ROM helper for platform-provided ROM imagesMatthew Garrett1-36/+31
It turns out that some UEFI systems provide apparently an apparently valid PCI ROM BAR that turns out to contain garbage, so the attempt in 547b52463 to prefer the ROM from the BAR actually breaks a different set of machines. As Linus pointed out, the graphics drivers are probably in the best position to make this judgement, so this basically reverts 547b52463 and f9a37be0f and adds a new helper function. Followup patches will add support to nouveau and radeon for probing this ROM source if they can't find a ROM from some other source. [bhelgaas: added reporter and bugzilla pointers, s/f4eb5ff05/547b52463] Reference: https://bugzilla.redhat.com/show_bug.cgi?id=927451 Reference: http://lkml.kernel.org/r/kg69ef$vdb$1@ger.gmane.org Reported-by: Mantas Mikulėnas <grawity@gmail.com> Reported-by: Chris Murphy <bugzilla@colorremedies.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-03-19PCI: Use ROM images from firmware only if no other ROM source availableMatthew Garrett1-20/+35
Mantas Mikulėnas reported that his graphics hardware failed to initialise after commit f9a37be0f02a ("x86: Use PCI setup data"). The aim of this commit was to ensure that ROM images were available on some Apple systems that don't expose the GPU ROM via any other source. In this case, UEFI appears to have provided a broken ROM image that we were using even though there was a perfectly valid ROM available via other sources. The simplest way to handle this seems to be to just re-order pci_map_rom() and leave any firmare-supplied ROM to last. Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Tested-by: Mantas Mikulėnas <grawity@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-12-10PCI: Use phys_addr_t for physical ROM addressBjorn Helgaas1-1/+1
Use phys_addr_t rather than "void *" for physical memory address. This removes casts and fixes a "cast from pointer to integer of different size" warning on ppc44x_defconfig. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-12-05PCI: Add support for non-BAR ROMsMatthew Garrett1-2/+9
Platforms may provide their own mechanisms for obtaining ROMs. Add support for using data provided by the platform in that case. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Seth Forshee <seth.forshee@canonical.com>
2012-08-22PCI: Remove unused, commented-out, codeBjorn Helgaas1-59/+0
This removes unused code that was already commented out. Tested-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2011-10-31pci: Fix files needing export.h for EXPORT_SYMBOL/THIS_MODULEPaul Gortmaker1-0/+1
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>
2009-02-13PCI: fix rom.c kernel-doc warningRandy Dunlap1-0/+1
Fix PCI kernel-doc warning: Warning(linux-2.6.29-rc4-git1/drivers/pci/rom.c:67): No description found for parameter 'pdev' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04PCI: return error on failure to read PCI ROMsTimothy S. Nelson1-3/+5
This patch makes the ROM reading code return an error to user space if the size of the ROM read is equal to 0. The patch also emits a warnings if the contents of the ROM are invalid, and documents the effects of the "enable" file on ROM reading. Signed-off-by: Timothy S. Nelson <wayland@wayland.id.au> Acked-by: Alex Villacis-Lasso <a_villacis@palosanto.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-11-03PCI: remove excess kernel-doc notationRandy Dunlap1-2/+4
Fix pci/rom.c kernel-doc function notation: Warning(drivers/pci/rom.c:110): Excess function parameter or struct member 'return' description in 'pci_map_rom' Warning(drivers/pci/rom.c:177): Excess function parameter or struct member 'return' description in 'pci_map_rom_copy' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-09-26Export the ROM enable/disable helpersAlan Cox1-2/+4
.... so that they can be used by MTD map drivers. Lets us close #9420 Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-03-03docbook: fix kernel-api source filesRandy Dunlap1-2/+1
Fix docbook problems in kernel-api.tmpl. These cause the generated docbook to be incorrect. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-01PCI: drivers/pci/rom.c: #if 0 two functionsAdrian Bunk1-2/+4
This patch #if 0's the following unused global functions: - rom.c: pci_map_rom_copy() - rom.c: pci_remove_rom() Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-09[IA64] SN: Correct ROM resource length for BIOS copyJohn Keller1-29/+44
On SN systems, when setting the IORESOURCE_ROM_BIOS_COPY resource flag, the resource length should be set to the actual size of the ROM image so that a call to pci_map_rom() returns the correct size. Signed-off-by: John Keller <jpk@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
2006-12-01Altix: Initial ACPI support - ROM shadowing.John Keller1-3/+6
Support a shadowed ROM when running with an ACPI capable PROM. Define a new dev.resource flag IORESOURCE_ROM_BIOS_COPY to describe the case of a BIOS shadowed ROM, which can then be used to avoid pci_map_rom() making an unneeded call to pci_enable_rom(). Signed-off-by: John Keller <jpk@sgi.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-10-27PCI: fix pci_fixup_video as it blows up on sparc64Eiichiro Oiwa1-2/+3
This reverts much of the original pci_fixup_video change and makes it work for all arches that need it. fixed, and tested on x86, x86_64 and IA64 dig. Signed-off-by: Eiichiro Oiwa <eiichiro.oiwa.nm@hitachi.com> Acked-by: David Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-10-18PCI: Turn pci_fixup_video into generic for embedded VGAeiichiro.oiwa.nm@hitachi.com1-1/+4
pci_fixup_video turns into generic code because there are many platforms need this fixup for embedded VGA as well as x86. The Video BIOS integrates into System BIOS on a machine has embedded VGA although embedded VGA generally don't have PCI ROM. As a result, embedded VGA need the way that the sysfs rom points to the Video BIOS of System RAM (0xC0000). PCI-to-PCI Bridge Architecture specification describes the condition whether or not PCI ROM forwards VGA compatible memory address. fixup_video suits this specification. Although the Video ROM generally implements in x86 code regardless of platform, some application such as X Window System can run this code by dosemu86. Therefore, pci_fixup_video should turn into generic code. Signed-off-by: Eiichiro Oiwa <eiichiro.oiwa.nm@hitachi.com> Acked-by: Alan Cox <alan@redhat.com> Acked-by: Jesse Barnes <jesse.barnes@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-30Remove obsolete #include <linux/config.h>Jörn Engel1-1/+0
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-06-27[PATCH] 64bit resource: change pci core and arch code to use resource_size_tGreg Kroah-Hartman1-5/+5
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>
2005-10-30[PATCH] fix missing includesTim Schmielau1-0/+1
I recently picked up my older work to remove unnecessary #includes of sched.h, starting from a patch by Dave Jones to not include sched.h from module.h. This reduces the number of indirect includes of sched.h by ~300. Another ~400 pointless direct includes can be removed after this disentangling (patch to follow later). However, quite a few indirect includes need to be fixed up for this. In order to feed the patches through -mm with as little disturbance as possible, I've split out the fixes I accumulated up to now (complete for i386 and x86_64, more archs to follow later) and post them before the real patch. This way this large part of the patch is kept simple with only adding #includes, and all hunks are independent of each other. So if any hunk rejects or gets in the way of other patches, just drop it. My scripts will pick it up again in the next round. Signed-off-by: Tim Schmielau <tim@physik3.uni-rostock.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-01[PATCH] Fix PCI ROM mappingBenjamin Herrenschmidt1-7/+17
This fixes a problem with pci_map_rom() which doesn't properly update the ROM BAR value with the address thas allocated for it by the PCI code. This problem, among other, breaks boot on Mac laptops. It'ss a new version based on Linus latest one with better error checking. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-29[PATCH] PCI: Adjust PCI rom code to handle more broken ROMsJon Smirl1-1/+3
There are ROMs reporting that their size exceeds their PCI ROM resource window. This patch returns the minimum of the resource window size or the size in the ROM. An example of this breakage is the XGI Volari Z7. Signed-off-by: Jon Smirl <jonsmirl@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01[PATCH] DocBook: fix some descriptionsMartin Waitz1-7/+7
Some KernelDoc descriptions are updated to match the current code. No code changes. Signed-off-by: Martin Waitz <tali@admingilde.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds1-0/+227
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!