1. 10 Feb, 2018 1 commit
  2. 17 Jan, 2018 1 commit
    • Rob Herring's avatar
      powerpc/pci: Use of_irq_parse_and_map_pci() helper · 59f47eff
      Rob Herring authored
      
      
      Instead of calling both of_irq_parse_pci() and irq_create_of_mapping(),
      call of_irq_parse_and_map_pci(), which does the same thing. This will allow
      making of_irq_parse_pci() a private, static function.
      
      This changes the logic slightly in that the fallback path will also be
      taken if irq_create_of_mapping() fails internally.
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      [bhelgaas: fold in virq init from Stephen Rothwell <sfr@canb.auug.org.au>]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      59f47eff
  3. 10 Jan, 2018 1 commit
  4. 11 Dec, 2017 1 commit
  5. 04 Dec, 2017 1 commit
  6. 18 Oct, 2017 1 commit
    • Bjorn Helgaas's avatar
      vgaarb: Select a default VGA device even if there's no legacy VGA · a37c0f48
      Bjorn Helgaas authored
      Daniel Axtens reported that on the HiSilicon D05 board, the VGA device is
      behind a bridge that doesn't support PCI_BRIDGE_CTL_VGA, so the VGA arbiter
      never selects it as the default, which means Xorg auto-detection doesn't
      work.
      
      VGA is a legacy PCI feature: a VGA device can respond to addresses, e.g.,
      [mem 0xa0000-0xbffff], [io 0x3b0-0x3bb], [io 0x3c0-0x3df], etc., that are
      not configurable by BARs.  Consequently, multiple VGA devices can conflict
      with each other.  The VGA arbiter avoids conflicts by ensuring that those
      legacy resources are only routed to one VGA device at a time.
      
      The arbiter identifies the "default VGA" device, i.e., a legacy VGA device
      that was used by boot firmware.  It selects the first device that:
      
        - is of PCI_CLASS_DISPLAY_VGA,
        - has both PCI_COMMAND_IO and PCI_COMMAND_MEMORY enabled, and
        - has PCI_BRIDGE_CTL_VGA set in all upstream bridges.
      
      Some systems don't have such a device.  For example, if a host bridge
      doesn't support I/O space, PCI_COMMAND_IO probably won't be enabled for any
      devices below it.  Or, as on the HiSilicon D05, the VGA device may be
      behind a bridge that doesn't support PCI_BRIDGE_CTL_VGA, so accesses to the
      legacy VGA resources will never reach the device.
      
      This patch extends the arbiter so that if it doesn't find a device that
      meets all the above criteria, it selects the first device that:
      
        - is of PCI_CLASS_DISPLAY_VGA and
        - has PCI_COMMAND_IO or PCI_COMMAND_MEMORY enabled
      
      If it doesn't find even that, it selects the first device that:
      
        - is of class PCI_CLASS_DISPLAY_VGA.
      
      Such a device may not be able to use the legacy VGA resources, but most
      drivers can operate the device without those.  Setting it as the default
      device means its "boot_vga" sysfs file will contain "1", which Xorg (via
      libpciaccess) uses to help select its default output device.
      
      This fixes Xorg auto-detection on some arm64 systems (HiSilicon D05 in
      particular; see the link below).
      
      It also replaces the powerpc fixup_vga() quirk, albeit with slightly
      different semantics: the quirk selected the first VGA device we found, and
      overrode that selection with any enabled VGA device we found.  If there
      were several enabled VGA devices, the *last* one we found would become the
      default.
      
      The code here instead selects the *first* enabled VGA device we find, and
      if none are enabled, the first VGA device we find.
      
      Link: http://lkml.kernel.org/r/20170901072744.2409-1-dja@axtens.net
      
      
      Tested-by: Daniel Axtens <dja@axtens.net>       # arm64, ppc64-qemu-tcg
      Tested-by: Zhou Wang <wangzhou1@hisilicon.com>  # D05 Hisi Hip07, Hip08
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: default avatarDaniel Axtens <dja@axtens.net>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171013034721.14630.65913.stgit@bhelgaas-glaptop.roam.corp.google.com
      a37c0f48
  7. 23 Aug, 2017 1 commit
  8. 20 Apr, 2017 1 commit
  9. 19 Apr, 2017 1 commit
  10. 25 Feb, 2017 1 commit
  11. 17 Feb, 2017 1 commit
    • Gavin Shan's avatar
      powerpc/kernel: Remove error message in pcibios_setup_phb_resources() · 727597d1
      Gavin Shan authored
      
      
      The CAPI driver creates virtual PHB (vPHB) from the CAPI adapter.
      The vPHB's IO and memory windows aren't built from device-tree node
      as we do for normal PHBs. A error message is thrown in below path
      when trying to probe AFUs contained in the adapter. The error message
      is confusing and unnecessary.
      
          cxl_probe()
          pci_init_afu()
          cxl_pci_vphb_add()
          pcibios_scan_phb()
          pcibios_setup_phb_resources()
      
      This removes the error message. We might have the case where the
      first memory window on real PHB isn't populated properly because
      of error in "ranges" property in the device-tree node. We can check
      the device-tree instead for that. This also removes one unnecessary
      blank line in the function.
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Reviewed-by: default avatarAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      727597d1
  12. 24 Jan, 2017 1 commit
    • Bart Van Assche's avatar
      treewide: Constify most dma_map_ops structures · 5299709d
      Bart Van Assche authored
      
      
      Most dma_map_ops structures are never modified. Constify these
      structures such that these can be write-protected. This patch
      has been generated as follows:
      
      git grep -l 'struct dma_map_ops' |
        xargs -d\\n sed -i \
          -e 's/struct dma_map_ops/const struct dma_map_ops/g' \
          -e 's/const struct dma_map_ops {/struct dma_map_ops {/g' \
          -e 's/^const struct dma_map_ops;$/struct dma_map_ops;/' \
          -e 's/const const struct dma_map_ops /const struct dma_map_ops /g';
      sed -i -e 's/const \(struct dma_map_ops intel_dma_ops\)/\1/' \
        $(git grep -l 'struct dma_map_ops intel_dma_ops');
      sed -i -e 's/const \(struct dma_map_ops dma_iommu_ops\)/\1/' \
        $(git grep -l 'struct dma_map_ops' | grep ^arch/powerpc);
      sed -i -e '/^struct vmd_dev {$/,/^};$/ s/const \(struct dma_map_ops[[:blank:]]dma_ops;\)/\1/' \
             -e '/^static void vmd_setup_dma_ops/,/^}$/ s/const \(struct dma_map_ops \*dest\)/\1/' \
             -e 's/const \(struct dma_map_ops \*dest = \&vmd->dma_ops\)/\1/' \
          drivers/pci/host/*.c
      sed -i -e '/^void __init pci_iommu_alloc(void)$/,/^}$/ s/dma_ops->/intel_dma_ops./' arch/ia64/kernel/pci-dma.c
      sed -i -e 's/static const struct dma_map_ops sn_dma_ops/static struct dma_map_ops sn_dma_ops/' arch/ia64/sn/pci/pci_dma.c
      sed -i -e 's/(const struct dma_map_ops \*)//' drivers/misc/mic/bus/vop_bus.c
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: linux-arch@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: x86@kernel.org
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      5299709d
  13. 20 Sep, 2016 1 commit
    • Michael Ellerman's avatar
      powerpc: Remove all usages of NO_IRQ · ef24ba70
      Michael Ellerman authored
      NO_IRQ has been == 0 on powerpc for just over ten years (since commit
      0ebfff14
      
       ("[POWERPC] Add new interrupt mapping core and change
      platforms to use it")). It's also 0 on most other arches.
      
      Although it's fairly harmless, every now and then it causes confusion
      when a driver is built on powerpc and another arch which doesn't define
      NO_IRQ. There's at least 6 definitions of NO_IRQ in drivers/, at least
      some of which are to work around that problem.
      
      So we'd like to remove it. This is fairly trivial in the arch code, we
      just convert:
      
          if (irq == NO_IRQ)	to	if (!irq)
          if (irq != NO_IRQ)	to	if (irq)
          irq = NO_IRQ;	to	irq = 0;
          return NO_IRQ;	to	return 0;
      
      And a few other odd cases as well.
      
      At least for now we keep the #define NO_IRQ, because there is driver
      code that uses NO_IRQ and the fixes to remove those will go via other
      trees.
      
      Note we also change some occurrences in PPC sound drivers, drivers/ps3,
      and drivers/macintosh.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      ef24ba70
  14. 22 Aug, 2016 1 commit
    • Mauricio Faria de Oliveira's avatar
      powerpc/pseries: use pci_host_bridge.release_fn() to kfree(phb) · 2dd9c11b
      Mauricio Faria de Oliveira authored
      
      
      This patch leverages 'struct pci_host_bridge' from the PCI subsystem
      in order to free the pci_controller only after the last reference to
      its devices is dropped (avoiding an oops in pcibios_release_device()
      if the last reference is dropped after pcibios_free_controller()).
      
      The patch relies on pci_host_bridge.release_fn() (and .release_data),
      which is called automatically by the PCI subsystem when the root bus
      is released (i.e., the last reference is dropped).  Those fields are
      set via pci_set_host_bridge_release() (e.g. in the platform-specific
      implementation of pcibios_root_bridge_prepare()).
      
      It introduces the 'pcibios_free_controller_deferred()' .release_fn()
      and it expects .release_data to hold a pointer to the pci_controller.
      
      The function implictly calls 'pcibios_free_controller()', so an user
      must *NOT* explicitly call it if using the new _deferred() callback.
      
      The functionality is enabled for pseries (although it isn't platform
      specific, and may be used by cxl).
      
      Details on not-so-elegant design choices:
      
       - Use 'pci_host_bridge.release_data' field as pointer to associated
         'struct pci_controller' so *not* to 'pci_bus_to_host(bridge->bus)'
         in pcibios_free_controller_deferred().
      
         That's because pci_remove_root_bus() sets 'host_bridge->bus = NULL'
         (so, if the last reference is released after pci_remove_root_bus()
         runs, which eventually reaches pcibios_free_controller_deferred(),
         that would hit a null pointer dereference).
      
         The cxl/vphb.c code calls pci_remove_root_bus(), and the cxl folks
         are interested in this fix.
      
      Test-case #1 (hold references)
      
        # ls -ld /sys/block/sd* | grep -m1 0021:01:00.0
        <...> /sys/block/sdaa -> ../devices/pci0021:01/0021:01:00.0/<...>
      
        # ls -ld /sys/block/sd* | grep -m1 0021:01:00.1
        <...> /sys/block/sdab -> ../devices/pci0021:01/0021:01:00.1/<...>
      
        # cat >/dev/sdaa & pid1=$!
        # cat >/dev/sdab & pid2=$!
      
        # drmgr -w 5 -d 1 -c phb -s 'PHB 33' -r
        Validating PHB DLPAR capability...yes.
        [  594.306719] pci_hp_remove_devices: PCI: Removing devices on bus 0021:01
        [  594.306738] pci_hp_remove_devices:    Removing 0021:01:00.0...
        ...
        [  598.236381] pci_hp_remove_devices:    Removing 0021:01:00.1...
        ...
        [  611.972077] pci_bus 0021:01: busn_res: [bus 01-ff] is released
        [  611.972140] rpadlpar_io: slot PHB 33 removed
      
        # kill -9 $pid1
        # kill -9 $pid2
        [  632.918088] pcibios_free_controller_deferred: domain 33, dynamic 1
      
      Test-case #2 (don't hold references)
      
        # drmgr -w 5 -d 1 -c phb -s 'PHB 33' -r
        Validating PHB DLPAR capability...yes.
        [  916.357363] pci_hp_remove_devices: PCI: Removing devices on bus 0021:01
        [  916.357386] pci_hp_remove_devices:    Removing 0021:01:00.0...
        ...
        [  920.566527] pci_hp_remove_devices:    Removing 0021:01:00.1...
        ...
        [  933.955873] pci_bus 0021:01: busn_res: [bus 01-ff] is released
        [  933.955977] pcibios_free_controller_deferred: domain 33, dynamic 1
        [  933.955999] rpadlpar_io: slot PHB 33 removed
      Suggested-By: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarMauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
      Reviewed-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Reviewed-by: default avatarAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Tested-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> # cxl
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      2dd9c11b
  15. 09 Aug, 2016 1 commit
    • Michael Ellerman's avatar
      powerpc/pci: Fix endian bug in fixed PHB numbering · 61e8a0d5
      Michael Ellerman authored
      The recent commit 63a72284 ("powerpc/pci: Assign fixed PHB number
      based on device-tree properties"), added code to read a 64-bit property
      from the device tree, and if not found read a 32-bit property (reg).
      
      There was a bug in the 32-bit case, on big endian machines, due to the
      use of the 64-bit value to read the 32-bit property. The cast of &prop
      means we end up writing to the high 32-bit of prop, leaving the low
      32-bits containing whatever junk was on the stack.
      
      If that junk value was non-zero, and < MAX_PHBS, we would end up using
      it as the PHB id. This results in users seeing what appear to be random
      PHB ids.
      
      Fix it by reading into a u32 property and then assigning that to the
      u64 value, letting the CPU do the correct conversions for us.
      
      Fixes: 63a72284
      
       ("powerpc/pci: Assign fixed PHB number based on device-tree properties")
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      61e8a0d5
  16. 08 Aug, 2016 1 commit
  17. 17 Jul, 2016 1 commit
  18. 07 Jul, 2016 1 commit
    • Guilherme G. Piccoli's avatar
      powerpc/pci: Assign fixed PHB number based on device-tree properties · 63a72284
      Guilherme G. Piccoli authored
      
      
      The domain/PHB field of PCI addresses has its value obtained from a
      global variable, incremented each time a new domain (represented by
      struct pci_controller) is added on the system. The domain addition
      process happens during boot or due to PHB hotplug add.
      
      As recent kernels are using predictable naming for network interfaces,
      the network stack is more tied to PCI naming. This can be a problem in
      hotplug scenarios, because PCI addresses will change if devices are
      removed and then re-added. This situation seems unusual, but it can
      happen if a user wants to replace a NIC without rebooting the machine,
      for example.
      
      This patch changes the way PCI domain values are generated: now, we use
      device-tree properties to assign fixed PHB numbers to PCI addresses
      when available (meaning pSeries and PowerNV cases). We also use a bitmap
      to allow dynamic PHB numbering when device-tree properties are not
      used. This bitmap keeps track of used PHB numbers and if a PHB is
      released (by hotplug operations for example), it allows the reuse of
      this PHB number, avoiding PCI address to change in case of device remove
      and re-add soon after. No functional changes were introduced.
      Signed-off-by: default avatarGuilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
      Reviewed-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Reviewed-by: default avatarIan Munsie <imunsie@au1.ibm.com>
      Acked-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      [mpe: Drop unnecessary machine_is(pseries) test]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      63a72284
  19. 24 Jun, 2016 1 commit
  20. 21 Jun, 2016 2 commits
  21. 17 Jun, 2016 2 commits
    • Bjorn Helgaas's avatar
      powerpc/pci: Implement pci_resource_to_user() with pcibios_resource_to_bus() · 38301358
      Bjorn Helgaas authored
      
      
      "User" addresses are shown in /sys/devices/pci.../.../resource and
      /proc/bus/pci/devices and used as mmap offsets for /proc/bus/pci/BB/DD.F
      files.  For I/O port resources on powerpc, these are PCI bus addresses,
      i.e., raw BAR values.
      
      Previously pci_resource_to_user() computed the user address by subtracting
      "hose->io_base_virt - _IO_BASE" from the resource start:
      
        pci_resource_to_user()
          if (IO)
            offset = (unsigned long)hose->io_base_virt - _IO_BASE;
          *start = rsrc->start - offset;
      
      We've already told the PCI core about that "hose->io_base_virt - _IO_BASE"
      offset:
      
        pcibios_setup_phb_resources()
          res = &hose->io_resource;
          offset = pcibios_io_space_offset();
          /* i.e., "offset = hose->io_base_virt - _IO_BASE" */
          pci_add_resource_offset(resources, res, offset);
      
      so pcibios_resource_to_bus() knows how to do that translation.
      
      No functional change intended.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarYinghai Lu <yinghai@kernel.org>
      38301358
    • Yinghai Lu's avatar
      powerpc/pci: Remove __pci_mmap_set_pgprot() · 1e70cdd6
      Yinghai Lu authored
      
      
      The powerpc-specific __pci_mmap_set_pgprot() does two things:
      
        1) Disables write combining for I/O port space mappings
      
           This only affects procfs mappings.  The pci_mmap_resource() sysfs path
           only requests write combining for resources with IORESOURCE_PREFETCH
           set, which doesn't include I/O resources.
      
           The only way to request write combining for I/O port space mappings
           was via the PCIIOC_WRITE_COMBINE ioctl and the proc_bus_pci_mmap()
           path, and we recently changed that path to ignore write combining for
           I/O, so this code in powerpc is no longer needed.
      
        2) Automatically enables write combining for mappings of prefetchable
           resources, even if not requested by the user
      
           Both procfs (via PCIIOC_MMAP_IS_MEM and PCIIOC_WRITE_COMBINE ioctls)
           and sysfs (via "resourceN_wc" files, which are created for resources
           with IORESOURCE_PREFETCH) provide ways for the user to map PCI memory
           space with write combining.
      
           Users that desire write combining should use one of those ways instead
           of relying on powerpc-specific behavior.
      
      Remove the powerpc-specific __pci_mmap_set_pgprot().
      
      The user-visible effect of this change is that powerpc users mapping
      prefetchable PCI memory space via procfs without PCIIOC_WRITE_COMBINE or
      via sysfs "resourceN" (not "resourceN_wc") will get regular uncacheable
      mappings instead of the write combining mappings they used to get.
      
      The new behavior matches the behavior on all other arches that support
      write combining mapping.
      
      [bhelgaas: changelog]
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      1e70cdd6
  22. 15 Oct, 2015 1 commit
  23. 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 <oe5hpm@gmail.com>
      Reported-by: default avatarRay Jui <rjui@broadcom.com>
      Link: http://lkml.kernel.org/r/CAAa04yFQEUJm7Jj1qMT57-LG7ZGtnhNDBe=PpSRa70Mj+XhW-A@mail.gmail.com
      Link: http://lkml.kernel.org/r/55F75BB8.4070405@broadcom.com
      
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarYinghai Lu <yinghai@kernel.org>
      Acked-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      237865f1
  24. 06 Aug, 2015 1 commit
  25. 23 Jul, 2015 1 commit
    • Lorenzo Pieralisi's avatar
      PCI: Call pci_read_bridge_bases() from core instead of arch code · dff22d20
      Lorenzo Pieralisi authored
      
      
      When we scan a PCI bus, we read PCI-PCI bridge window registers with
      pci_read_bridge_bases() so we can validate the resource hierarchy.  Most
      architectures call pci_read_bridge_bases() from pcibios_fixup_bus(), but
      PCI-PCI bridges are not arch-specific, so this doesn't need to be in
      arch-specific code.
      
      Call pci_read_bridge_bases() directly from the PCI core instead of from
      arch code.
      
      For alpha and mips, we now call pci_read_bridge_bases() always; previously
      we only called it if PCI_PROBE_ONLY was set.
      
      [bhelgaas: changelog]
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Ralf Baechle <ralf@linux-mips.org>
      CC: James E.J. Bottomley <jejb@parisc-linux.org>
      CC: Michael Ellerman <mpe@ellerman.id.au>
      CC: Bjorn Helgaas <bhelgaas@google.com>
      CC: Richard Henderson <rth@twiddle.net>
      CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      CC: David Howells <dhowells@redhat.com>
      CC: Russell King <linux@arm.linux.org.uk>
      CC: Tony Luck <tony.luck@intel.com>
      CC: David S. Miller <davem@davemloft.net>
      CC: Ingo Molnar <mingo@redhat.com>
      CC: Guenter Roeck <linux@roeck-us.net>
      CC: Michal Simek <monstr@monstr.eu>
      CC: Chris Zankel <chris@zankel.net>
      dff22d20
  26. 03 Jun, 2015 2 commits
  27. 11 Apr, 2015 8 commits
  28. 10 Apr, 2015 1 commit
    • Michael Ellerman's avatar
      powerpc: Replace mem_init_done with slab_is_available() · f691fa10
      Michael Ellerman authored
      
      
      We have a powerpc specific global called mem_init_done which is "set on
      boot once kmalloc can be called".
      
      But that's not *quite* true. We set it at the bottom of mem_init(), and
      rely on the fact that mm_init() calls kmem_cache_init() immediately
      after that, and nothing is running in parallel.
      
      So replace it with the generic and 100% correct slab_is_available().
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      f691fa10
  29. 31 Mar, 2015 2 commits
    • Wei Yang's avatar
      powerpc/powernv: Implement pcibios_iov_resource_alignment() on powernv · 5350ab3f
      Wei Yang authored
      
      
      Implement pcibios_iov_resource_alignment() on powernv platform.
      
      On PowerNV platform, there are 3 cases for the IOV BAR:
      1. initial state, the IOV BAR size is multiple times of VF BAR size
      2. after expanded, the IOV BAR size is expanded to meet the M64 segment size
      3. sizing stage, the IOV BAR is truncated to 0
      
      pnv_pci_iov_resource_alignment() handle these three cases respectively.
      
      [bhelgaas: adjust to drop "align" parameter, return pci_iov_resource_size()
      if no ppc_md machdep_call version]
      Signed-off-by: default avatarWei Yang <weiyang@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      5350ab3f
    • Wei Yang's avatar
      powerpc/powernv: Reserve additional space for IOV BAR according to the number of total_pe · 6e628c7d
      Wei Yang authored
      
      
      On PHB3, PF IOV BAR will be covered by M64 BAR to have better PE isolation.
      M64 BAR is a type of hardware resource in PHB3, which could map a range of
      MMIO to PE numbers on powernv platform. And this range is divided equally
      by the number of total_pe with each divided range mapping to a PE number.
      Also, the M64 BAR must map a MMIO range with power-of-two size.
      
      The total_pe number is usually different from total_VFs, which can lead to
      a conflict between MMIO space and the PE number.
      
      For example, if total_VFs is 128 and total_pe is 256, the second half of
      M64 BAR will be part of other PCI device, which may already belong to other
      PEs.
      
      This patch prevents the conflict by reserving additional space for the PF
      IOV BAR, which is total_pe number of VF's BAR size.
      
      [bhelgaas: make dev_printk() output more consistent, index resource[]
      conventionally]
      Signed-off-by: default avatarWei Yang <weiyang@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      6e628c7d