All new accounts created on Gitlab now require administrator approval. If you invite any collaborators, please let Flux staff know so they can approve the accounts.

  1. 24 Sep, 2015 3 commits
  2. 22 Sep, 2015 1 commit
    • Bjorn Helgaas's avatar
      PCI: Clear IORESOURCE_UNSET when clipping a bridge window · b838b39e
      Bjorn Helgaas authored
      c770cb4c ("PCI: Mark invalid BARs as unassigned") sets IORESOURCE_UNSET
      if we fail to claim a resource.  If we tried to claim a bridge window,
      failed, clipped the window, and tried to claim the clipped window, we
      failed again because of IORESOURCE_UNSET:
        pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff window]
        pci 0000:00:01.0: can't claim BAR 15 [mem 0xbdf00000-0xddefffff 64bit pref]: no compatible bridge window
        pci 0000:00:01.0: [mem size 0x20000000 64bit pref] clipped to [mem size 0x1df00000 64bit pref]
        pci 0000:00:01.0:   bridge window [mem size 0x1df00000 64bit pref]
        pci 0000:00:01.0: can't claim BAR 15 [mem size 0x1df00000 64bit pref]: no address assigned
      The 00:01.0 window started as [mem 0xbdf00000-0xddefffff 64bit pref].  That
      starts before the host bridge window [mem 0xc0000000-0xffffffff window], so
      we clipped the 00:01.0 window to [mem 0xc0000000-0xddefffff 64bit pref].
      But we left it marked IORESOURCE_UNSET, so the second claim failed when it
      should have succeeded.
      This means downstream devices will also fail for lack of resources, e.g.,
      in the bugzilla below,
        radeon 0000:01:00.0: Fatal error during GPU init
      Clear IORESOURCE_UNSET when we clip a bridge window.  Also clear
      IORESOURCE_UNSET in our copy of the unclipped window so we can see exactly
      what the original window was and how it now fits inside the upstream
      Fixes: c770cb4c ("PCI: Mark invalid BARs as unassigned")
      Link: default avatarLorenzo Pieralisi <>
      Based-on-patch-by: default avatarYinghai Lu <>
      Tested-by: default avatarLorenzo Pieralisi <>
      Signed-off-by: default avatarBjorn Helgaas <>
      Reviewed-by: default avatarLorenzo Pieralisi <>
      Acked-by: default avatarYinghai Lu <>
      CC:	# v4.1+
  3. 15 Sep, 2015 1 commit
    • Bjorn Helgaas's avatar
      PCI: Revert "PCI: Call pci_read_bridge_bases() from core instead of arch code" · 237865f1
      Bjorn Helgaas authored
      Revert dff22d20 ("PCI: Call pci_read_bridge_bases() from core instead
      of arch code").
      Reading PCI bridge windows is not arch-specific in itself, but there is PCI
      core code that doesn't work correctly if we read them too early.  For
      example, Hannes found this case on an ARM Freescale i.mx6 board:
        pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
        pci 0000:00:00.0: PCI bridge to [bus 01-ff]
        pci 0000:00:00.0: BAR 8: no space for [mem size 0x01000000] (mem window)
        pci 0000:01:00.0: BAR 2: failed to assign [mem size 0x00200000]
        pci 0000:01:00.0: BAR 1: failed to assign [mem size 0x00004000]
        pci 0000:01:00.0: BAR 0: failed to assign [mem size 0x00000100]
      The 00:00.0 mem window needs to be at least 3MB: the 01:00.0 device needs
      0x204100 of space, and mem windows are megabyte-aligned.
      Bus sizing can increase a bridge window size, but never *decrease* it (see
      d65245c3 ("PCI: don't shrink bridge resources")).  Prior to
      dff22d20, ARM didn't read bridge windows at all, so the "original size"
      was zero, and we assigned a 3MB window.
      After dff22d20, we read the bridge windows before sizing the bus.  The
      firmware programmed a 16MB window (size 0x01000000) in 00:00.0, and since
      we never decrease the size, we kept 16MB even though we only needed 3MB.
      But 16MB doesn't fit in the host bridge aperture, so we failed to assign
      space for the window and the downstream devices.
      I think this is a defect in the PCI core: we shouldn't rely on the firmware
      to assign sensible windows.
      Ray reported a similar problem, also on ARM, with Broadcom iProc.
      Issues like this are too hard to fix right now, so revert dff22d20.
      Reported-by: default avatarHannes <>
      Reported-by: default avatarRay Jui <>
      Link: default avatarBjorn Helgaas <>
      Acked-by: default avatarYinghai Lu <>
      Acked-by: default avatarLorenzo Pieralisi <>
  4. 10 Sep, 2015 1 commit
    • Dave Young's avatar
      kexec: split kexec_load syscall from kexec core code · 2965faa5
      Dave Young authored
      There are two kexec load syscalls, kexec_load another and kexec_file_load.
       kexec_file_load has been splited as kernel/kexec_file.c.  In this patch I
      split kexec_load syscall code to kernel/kexec.c.
      And add a new kconfig option KEXEC_CORE, so we can disable kexec_load and
      use kexec_file_load only, or vice verse.
      The original requirement is from Ted Ts'o, he want kexec kernel signature
      being checked with CONFIG_KEXEC_VERIFY_SIG enabled.  But kexec-tools use
      kexec_load syscall can bypass the checking.
      Vivek Goyal proposed to create a common kconfig option so user can compile
      in only one syscall for loading kexec kernel.  KEXEC/KEXEC_FILE selects
      KEXEC_CORE so that old config files still work.
      Because there's general code need CONFIG_KEXEC_CORE, so I updated all the
      architecture Kconfig with a new option KEXEC_CORE, and let KEXEC selects
      KEXEC_CORE in arch Kconfig.  Also updated general kernel code with to
      kexec_load syscall.
      [ coding-style fixes]
      Signed-off-by: default avatarDave Young <>
      Cc: Eric W. Biederman <>
      Cc: Vivek Goyal <>
      Cc: Petr Tesarik <>
      Cc: Theodore Ts'o <>
      Cc: Josh Boyer <>
      Cc: David Howells <>
      Cc: Geert Uytterhoeven <>
      Signed-off-by: default avatarAndrew Morton <>
      Signed-off-by: default avatarLinus Torvalds <>
  5. 08 Sep, 2015 1 commit
    • Helge Deller's avatar
      PCI,parisc: Enable 64-bit bus addresses on PA-RISC · e02a653e
      Helge Deller authored
      Commit 3a9ad0b4 ("PCI: Add pci_bus_addr_t") unconditionally introduced usage of
      64-bit PCI bus addresses on all 64-bit platforms which broke PA-RISC.
      It turned out that due to enabling the 64-bit addresses, the PCI logic decided
      to use the GMMIO instead of the LMMIO region. This commit simply disables
      registering the GMMIO and thus we fall back to use the LMMIO region as before.
      Reverts commit 45ea2a5f
      ("PCI: Don't use 64-bit bus addresses on PA-RISC")
      Cc: Bjorn Helgaas <>
      Cc: Meelis Roos <>
      Cc:  # v3.19+
      Signed-off-by: default avatarHelge Deller <>
  6. 26 Aug, 2015 1 commit
    • Guilherme G. Piccoli's avatar
      PCI: Make pci_msi_setup_pci_dev() non-static for use by arch code · 22b6839b
      Guilherme G. Piccoli authored
      Commit 1851617c ("PCI/MSI: Disable MSI at enumeration even if kernel
      doesn't support MSI") changed the location of the code that initialises
      dev->msi_cap/msix_cap and then disables MSI/MSI-X interrupts at PCI
      probe time in devices that have this flag set. It moved the code from
      pci_msi_init_pci_dev() to a new function named pci_msi_setup_pci_dev(),
      called by pci_setup_device().
      The pseries PCI probing code does not call pci_setup_device(), so since
      the aforementioned commit the function pci_msi_setup_pci_dev() is not
      called and MSI/MSI-X interrupts are left enabled. Additionally because
      dev->msi_cap/msix_cap are not initialised no driver can ever enable
      To fix this, the pseries PCI probe should manually call
      pci_msi_setup_pci_dev(), so this patch makes it non-static.
      Fixes: 1851617c ("PCI/MSI: Disable MSI at enumeration even if kernel doesn't support MSI")
      [mpe: Update change log to mention dev->msi_cap/msix_cap]
      Signed-off-by: default avatarGuilherme G. Piccoli <>
      Signed-off-by: default avatarMichael Ellerman <>
  7. 25 Aug, 2015 1 commit
    • Luis R. Rodriguez's avatar
      PCI: Add pci_ioremap_wc_bar() · c43996f4
      Luis R. Rodriguez authored
      This lets drivers take advantage of PAT when available. It
      should help with the transition of converting video drivers over
      to ioremap_wc() to help with the goal of eventually using
      _PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on
      ioremap_nocache(), see:
        de33c442 ("x86 PAT: fix performance drop for glx, use UC minus for ioremap(), ioremap_nocache() and pci_mmap_page_range()")
      Signed-off-by: default avatarLuis R. Rodriguez <>
      Signed-off-by: default avatarBorislav Petkov <>
      Acked-by: default avatarArnd Bergmann <>
      Cc: <>
      Cc: Andrew Morton <>
      Cc: Andy Lutomirski <>
      Cc: Antonino Daplas <>
      Cc: Bjorn Helgaas <>
      Cc: Daniel Vetter <>
      Cc: Dave Airlie <>
      Cc: Davidlohr Bueso <>
      Cc: H. Peter Anvin <>
      Cc: Jean-Christophe Plagniol-Villard <>
      Cc: Juergen Gross <>
      Cc: Linus Torvalds <>
      Cc: Mel Gorman <>
      Cc: Peter Zijlstra <>
      Cc: Suresh Siddha <>
      Cc: Thomas Gleixner <>
      Cc: Tomi Valkeinen <>
      Cc: Toshi Kani <>
      Cc: Ville Syrjälä <>
      Cc: Vlastimil Babka <>
      Link: default avatarIngo Molnar <>
  8. 24 Aug, 2015 2 commits
    • Zhang Rui's avatar
      PCI: Disable async suspend/resume for JMicron multi-function SATA/AHCI · 91f15fb3
      Zhang Rui authored
      On multi-function JMicron SATA/PATA/AHCI devices, the PATA controller at
      function 1 doesn't work if it is powered on before the SATA controller at
      function 0.  The result is that PATA doesn't work after resume, and we
      print messages like this:
        pata_jmicron 0000:02:00.1: Refused to change power state, currently in D3
        irq 17: nobody cared (try booting with the "irqpoll" option)
      Async resume was introduced in v3.15 by 76569faa ("PM / sleep:
      Asynchronous threads for resume_noirq").  Prior to that, we powered on
      the functions in order, so this problem shouldn't happen.
      e6b7e41c ("ata: Disabling the async PM for JMicron chip 363/361")
      solved the problem for JMicron 361 and 363 devices.  With async suspend
      disabled, we always power on function 0 before function 1.
      Barto then reported the same problem with a JMicron 368 (see comment #57 in
      the bugzilla).
      Rather than extending the blacklist piecemeal, disable async suspend for
      all JMicron multi-function SATA/PATA/AHCI devices.
      This quirk could stay in the ahci and pata_jmicron drivers, but it's likely
      the problem will occur even if pata_jmicron isn't loaded until after the
      suspend/resume.  Making it a PCI quirk ensures that we'll preserve the
      power-on order even if the drivers aren't loaded.
      [bhelgaas: changelog, limit to multi-function, limit to IDE/ATA]
      Link: default avatarBarto <>
      Signed-off-by: default avatarZhang Rui <>
      Signed-off-by: default avatarBjorn Helgaas <>
      CC:	# v3.15+
    • Keith Busch's avatar
      PCI: Set MPS to match upstream bridge · 27d868b5
      Keith Busch authored
      Firmware typically configures the PCIe fabric with a consistent Max Payload
      Size setting based on the devices present at boot.  A hot-added device
      typically has the power-on default MPS setting (128 bytes), which may not
      match the fabric.
      The previous Linux default, in the absence of any "pci=pcie_bus_*" options,
      was PCIE_BUS_TUNE_OFF, in which we never touch MPS, even for hot-added
      Add a new default setting, PCIE_BUS_DEFAULT, in which we make sure every
      device's MPS setting matches the upstream bridge.  This makes it more
      likely that a hot-added device will work in a system with optimized MPS
      Note that if we hot-add a device that only supports 128-byte MPS, it still
      likely won't work because we don't reconfigure the rest of the fabric.
      Booting with "pci=pcie_bus_peer2peer" is a workaround for this because it
      sets MPS to 128 for everything.
      [bhelgaas: changelog, new default, rework for pci_configure_device() path]
      Tested-by: default avatarKeith Busch <>
      Tested-by: default avatarJordan Hargrave <>
      Signed-off-by: default avatarKeith Busch <>
      Signed-off-by: default avatarBjorn Helgaas <>
      Acked-by: default avatarYinghai Lu <>
  9. 20 Aug, 2015 12 commits
  10. 19 Aug, 2015 1 commit
    • Yijing Wang's avatar
      PCI: Tolerate hierarchies with no Root Port · b35b1df5
      Yijing Wang authored
      We should not assume any particular hardware topology.  Commit d0751b98
      ("PCI: Add dev->has_secondary_link to track downstream PCIe links") relied
      on the assumption that every PCIe hierarchy is rooted at a Root Port.  But
      we can't rely on any assumption about what hardware we will find; we just
      have to deal with the world as it is.
      On some platforms, PCIe devices (endpoints, switch upstream ports, etc.)
      appear directly on the root bus, and there is no Root Port in the PCI bus
      hierarchy.  For example, Meelis observed these top-level devices on a
      Sparc V245:
        0000:02:00.0 PCI bridge to [bus 03-0d]    Switch Upstream Port
        0001:02:00.0 PCI bridge to [bus 03]       PCIe to PCI/PCI-X Bridge
      These devices *look* like they have links going upstream, but there really
      are no upstream devices.
      In set_pcie_port_type(), we used the parent device to figure out which side
      of a switch port has a link, so if the parent device did not exist, we
      dereferenced a NULL parent pointer.
      Check whether the parent device exists before dereferencing it.
      Meelis observed this oops on Sparc V245 and T2000.  Ben Herrenschmidt says
      this is also possible on IBM PowerVM guests on PowerPC.
      [bhelgaas: changelog, comment]
      Link: default avatarMeelis Roos <>
      Tested-by: default avatarMeelis Roos <>
      Signed-off-by: default avatarYijing Wang <>
      Signed-off-by: default avatarBjorn Helgaas <>
      Acked-by: default avatarDavid S. Miller <>
  11. 18 Aug, 2015 1 commit
  12. 13 Aug, 2015 8 commits
  13. 11 Aug, 2015 7 commits