Eric Lee / smarc-fsl-linux-kernel

30 Jun, 2018

3 commits

20 Mar, 2018

1 commit

  • df62ab5e0   PCI: Tidy comments ... Browse Code »

    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

    Bjorn Helgaas
     

02 Feb, 2018

1 commit

  • ab8c60935   Merge branch 'pci/spdx' into next ... Browse Code »

    * pci/spdx:
    PCI: Add SPDX GPL-2.0+ to replace implicit GPL v2 or later statement
    PCI: Add SPDX GPL-2.0+ to replace GPL v2 or later boilerplate
    PCI: Add SPDX GPL-2.0 to replace COPYING boilerplate
    PCI: Add SPDX GPL-2.0 to replace GPL v2 boilerplate
    PCI: Add SPDX GPL-2.0 when no license was specified

    Bjorn Helgaas
     

01 Feb, 2018

1 commit

  • 414ae7609   Merge branch 'pci/resource' into next ... Browse Code »

    * pci/resource:
    PCI: tegra: Remove PCI_REASSIGN_ALL_BUS use on Tegra
    resource: Set type when reserving new regions
    resource: Set type of "reserve=" user-specified resources
    irqchip/i8259: Set I/O port resource types correctly
    powerpc: Set I/O port resource types correctly
    MIPS: Set I/O port resource types correctly
    vgacon: Set VGA struct resource types
    PCI: Use dev_info() rather than dev_err() for ROM validation
    PCI: Remove PCI_REASSIGN_ALL_RSRC use on arm and arm64
    PCI: Remove sysfs resource mmap warning

    Conflicts:
    drivers/pci/rom.c

    Bjorn Helgaas
     

27 Jan, 2018

1 commit

  • 7328c8f48   PCI: Add SPDX GPL-2.0 when no license was specified ... Browse Code »

    b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to
    files with no license") added SPDX GPL-2.0 to several PCI files that
    previously contained no license information.

    Add SPDX GPL-2.0 to all other PCI files that did not contain any license
    information and hence were under the default GPL version 2 license of the
    kernel.

    Signed-off-by: Bjorn Helgaas
    Reviewed-by: Greg Kroah-Hartman

    Bjorn Helgaas
     

19 Jan, 2018

1 commit

19 Dec, 2017

1 commit

  • 116a6063c   PCI: Use dev_info() rather than dev_err() for ROM validation ... Browse Code »

    On AMD GPUs, we use several mechanisms to fetch the VBIOS ROM depending on
    the platform. We try to read the ROM via the ROM BAR and fall back to
    other methods in some cases. This leads to spurious error messages from
    the PCI ROM code which are harmless in our case. This leads to bugs being
    filed, etc. Change these to dev_info() rather than dev_err() to avoid
    that.

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=198077
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=1462438
    Link: https://bugs.freedesktop.org/show_bug.cgi?id=98798
    Signed-off-by: Alex Deucher
    Signed-off-by: Bjorn Helgaas
    Reviewed-by: Christian König <christian.koenig@amd.com

    Alex Deucher
     

09 Nov, 2017

2 commits

  • a405f191f   PCI: Fail pci_map_rom() if the option ROM is invalid ... Browse Code »

    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
    [bhelgaas: split non-functional change into separate patch]
    Signed-off-by: Bjorn Helgaas

    Changbin Du
     
  • a48a687d8   PCI: Move pci_map_rom() error path ... Browse Code »

    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
    [bhelgaas: split non-functional change into separate patch]
    Signed-off-by: Bjorn Helgaas

    Changbin Du
     

30 Nov, 2016

1 commit

  • 0b457dde3   PCI: Add comments about ROM BAR updating ... Browse Code »

    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
    Reviewed-by: Gavin Shan

    Bjorn Helgaas
     

12 Mar, 2016

2 commits

09 Mar, 2016

2 commits

  • 0c0e0736a   PCI: Set ROM shadow location in arch code, not in PCI core ... Browse Code »

    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

    Bjorn Helgaas
     
  • 4708f9a55   PCI: Don't enable/disable ROM BAR if we're using a RAM shadow copy ... Browse Code »

    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

    Bjorn Helgaas
     

16 Jan, 2016

1 commit

09 Jan, 2016

1 commit

  • 47b975d23   PCI: Avoid iterating through memory outside the resource window ... Browse Code »

    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
    Signed-off-by: Bjorn Helgaas

    Edward O'Callaghan
     

11 Dec, 2015

1 commit

  • 4066df634   PCI: Print warnings for all invalid expansion ROM headers ... Browse Code »

    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
    Signed-off-by: Bjorn Helgaas

    Vladis Dronov
     

24 Jan, 2015

1 commit

  • 16b036af3   PCI: Fix infinite loop with ROM image of size 0 ... Browse Code »

    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
    Signed-off-by: Michel Dänzer
    Signed-off-by: Bjorn Helgaas
    Reviewed-by: Alex Deucher
    CC: stable@vger.kernel.org

    Michel Dänzer
     

11 Jun, 2014

2 commits

28 Feb, 2014

1 commit

  • bd064f0a2   PCI: Mark resources as IORESOURCE_UNSET if we can't assign them ... Browse Code »

    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

    Bjorn Helgaas
     

22 Dec, 2013

1 commit

  • fc2798502   PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev ... Browse Code »

    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
    Signed-off-by: Bjorn Helgaas

    Yinghai Lu
     

27 Mar, 2013

1 commit

  • fffe01f7a   PCI: Add PCI ROM helper for platform-provided ROM images ... Browse Code »

    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
    Reported-by: Chris Murphy
    Signed-off-by: Matthew Garrett
    Signed-off-by: Bjorn Helgaas

    Matthew Garrett
     

20 Mar, 2013

1 commit

  • 547b52463   PCI: Use ROM images from firmware only if no other ROM source available ... Browse Code »

    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
    Tested-by: Mantas Mikulėnas
    Signed-off-by: Linus Torvalds

    Matthew Garrett
     

11 Dec, 2012

1 commit

06 Dec, 2012

1 commit

23 Aug, 2012

1 commit

01 Nov, 2011

1 commit

14 Feb, 2009

1 commit

05 Feb, 2009

1 commit

  • 97c44836c   PCI: return error on failure to read PCI ROMs ... Browse Code »

    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
    Acked-by: Alex Villacis-Lasso
    Signed-off-by: Jesse Barnes

    Timothy S. Nelson
     

04 Nov, 2008

1 commit

  • f5dafca52   PCI: remove excess kernel-doc notation ... Browse Code »

    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
    Signed-off-by: Jesse Barnes

    Randy Dunlap
     

27 Sep, 2008

1 commit

04 Mar, 2008

1 commit

02 Feb, 2008

1 commit

10 Jul, 2007

1 commit

02 Dec, 2006

1 commit

  • a2302c68d   Altix: Initial ACPI support - ROM shadowing. ... Browse Code »

    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
    Signed-off-by: Greg Kroah-Hartman

    John Keller
     

28 Oct, 2006

1 commit

19 Oct, 2006

1 commit

  • b5e4efe7e   PCI: Turn pci_fixup_video into generic for embedded VGA ... Browse Code »

    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
    Acked-by: Alan Cox
    Acked-by: Jesse Barnes
    Signed-off-by: Greg Kroah-Hartman

    eiichiro.oiwa.nm@hitachi.com