1. 23 7月, 2015 1 次提交
    • L
      PCI: Call pci_read_bridge_bases() from core instead of arch code · dff22d20
      Lorenzo Pieralisi 提交于
      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: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NBjorn 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
  2. 03 6月, 2015 2 次提交
  3. 11 4月, 2015 8 次提交
  4. 10 4月, 2015 1 次提交
    • M
      powerpc: Replace mem_init_done with slab_is_available() · f691fa10
      Michael Ellerman 提交于
      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: NMichael Ellerman <mpe@ellerman.id.au>
      f691fa10
  5. 31 3月, 2015 3 次提交
    • W
      powerpc/powernv: Implement pcibios_iov_resource_alignment() on powernv · 5350ab3f
      Wei Yang 提交于
      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: NWei Yang <weiyang@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      5350ab3f
    • W
      powerpc/powernv: Reserve additional space for IOV BAR according to the number of total_pe · 6e628c7d
      Wei Yang 提交于
      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: NWei Yang <weiyang@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      6e628c7d
    • W
      powerpc/pci: Don't unset PCI resources for VFs · c3b80fb0
      Wei Yang 提交于
      Flag PCI_REASSIGN_ALL_RSRC is used to ignore resources information setup by
      firmware, so that kernel would re-assign all resources of pci devices.
      
      On powerpc arch, this happens in a header fixup function
      pcibios_fixup_resources(), which will clean up the resources if this flag
      is set. This works fine for PFs, since after clean up, kernel will
      re-assign the resources in pcibios_resource_survey().
      
      Below is a simple call flow on how it works:
      
          pcibios_init
            pcibios_scan_phb
              pci_scan_child_bus
                ...
                  pci_device_add
                    pci_fixup_device(pci_fixup_header)
                      pcibios_fixup_resources                     # header fixup
                        for (i = 0; i < DEVICE_COUNT_RESOURCE; i++)
                          dev->resource[i].start = 0
            pcibios_resource_survey                               # re-assign
              pcibios_allocate_resources
      
      However, the VF resources won't be re-assigned, since the VF resources are
      completely determined by the PF resources, and the PF resources have
      already been reassigned. This means we need to leave VF's resources
      un-cleared in pcibios_fixup_resources().
      
      In this patch, we skip the resource unset process in
      pcibios_fixup_resources(), if the pci_dev is a VF.
      Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      c3b80fb0
  6. 17 1月, 2015 1 次提交
    • Y
      powerpc/PCI: Clip bridge windows to fit in upstream windows · 3ebfe46a
      Yinghai Lu 提交于
      Every PCI-PCI bridge window should fit inside an upstream bridge window
      because orphaned address space is unreachable from the primary side of the
      upstream bridge.  If we inherit invalid bridge windows that overlap an
      upstream window from firmware, clip them to fit and update the bridge
      accordingly.
      
      [bhelgaas: changelog]
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491Reported-by: NMarek Kordik <kordikmarek@gmail.com>
      Fixes: 5b285415 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      CC: Paul Mackerras <paulus@samba.org>
      CC: Michael Ellerman <mpe@ellerman.id.au>
      CC: Gavin Shan <gwshan@linux.vnet.ibm.com>
      CC: Anton Blanchard <anton@samba.org>
      CC: Sebastian Ott <sebott@linux.vnet.ibm.com>
      CC: Wei Yang <weiyang@linux.vnet.ibm.com>
      CC: Andrew Murray <amurray@embedded-bits.co.uk>
      CC: linuxppc-dev@lists.ozlabs.org
      3ebfe46a
  7. 19 11月, 2014 1 次提交
    • M
      powerpc: Remove more traces of bootmem · e39f223f
      Michael Ellerman 提交于
      Although we are now selecting NO_BOOTMEM, we still have some traces of
      bootmem lying around. That is because even with NO_BOOTMEM there is
      still a shim that converts bootmem calls into memblock calls, but
      ultimately we want to remove all traces of bootmem.
      
      Most of the patch is conversions from alloc_bootmem() to
      memblock_virt_alloc(). In general a call such as:
      
        p = (struct foo *)alloc_bootmem(x);
      
      Becomes:
      
        p = memblock_virt_alloc(x, 0);
      
      We don't need the cast because memblock_virt_alloc() returns a void *.
      The alignment value of zero tells memblock to use the default alignment,
      which is SMP_CACHE_BYTES, the same value alloc_bootmem() uses.
      
      We remove a number of NULL checks on the result of
      memblock_virt_alloc(). That is because memblock_virt_alloc() will panic
      if it can't allocate, in exactly the same way as alloc_bootmem(), so the
      NULL checks are and always have been redundant.
      
      The memory returned by memblock_virt_alloc() is already zeroed, so we
      remove several memsets of the result of memblock_virt_alloc().
      
      Finally we convert a few uses of __alloc_bootmem(x, y, MAX_DMA_ADDRESS)
      to just plain memblock_virt_alloc(). We don't use memblock_alloc_base()
      because MAX_DMA_ADDRESS is ~0ul on powerpc, so limiting the allocation
      to that is pointless, 16XB ought to be enough for anyone.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      e39f223f
  8. 05 11月, 2014 1 次提交
  9. 16 10月, 2014 1 次提交
    • M
      powerpc/pci: Fix IO space breakage after of_pci_range_to_resource() change · aeba3731
      Michael Ellerman 提交于
      Commit 0b0b0893 "of/pci: Fix the conversion of IO ranges into IO
      resources" changed the behaviour of of_pci_range_to_resource().
      
      Previously it simply populated the resource based on the arguments. Now
      it calls pci_register_io_range() and pci_address_to_pio(). These both
      have two implementations depending on whether PCI_IOBASE is defined,
      which it is not for powerpc.
      
      Further complicating matters, both routines are weak, and powerpc
      implements it's own version of one - pci_address_to_pio(). However
      powerpc's implementation depends on other initialisations which are done
      later in boot.
      
      The end result is incorrectly initialised IO space. Often we can get
      away with that, because we don't make much use of IO space. However
      virtio requires it, so we see eg:
      
        pci_bus 0000:00: root bus resource [io  0xffff] (bus address [0xffffffffffffffff-0xffffffffffffffff])
        PCI: Cannot allocate resource region 0 of device 0000:00:01.0, will remap
        virtio-pci 0000:00:01.0: can't enable device: BAR 0 [io  size 0x0020] not assigned
      
      The simplest fix for now is to just stop using of_pci_range_to_resource(),
      and open-code the original implementation, that's all we want it to do.
      
      Fixes: 0b0b0893 ("of/pci: Fix the conversion of IO ranges into IO resources")
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      aeba3731
  10. 03 10月, 2014 1 次提交
  11. 25 9月, 2014 1 次提交
  12. 04 7月, 2014 1 次提交
  13. 01 5月, 2014 1 次提交
  14. 28 4月, 2014 2 次提交
  15. 22 12月, 2013 1 次提交
    • Y
      PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev · fc279850
      Yinghai Lu 提交于
      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: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      fc279850
  16. 24 10月, 2013 3 次提交
    • G
      of/irq: simplify args to irq_create_of_mapping · e6d30ab1
      Grant Likely 提交于
      All the callers of irq_create_of_mapping() pass the contents of a struct
      of_phandle_args structure to the function. Since all the callers already
      have an of_phandle_args pointer, why not pass it directly to
      irq_create_of_mapping()?
      Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      Acked-by: NMichal Simek <monstr@monstr.eu>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      e6d30ab1
    • G
      of/irq: Replace of_irq with of_phandle_args · 530210c7
      Grant Likely 提交于
      struct of_irq and struct of_phandle_args are exactly the same structure.
      This patch makes the kernel use of_phandle_args everywhere. This in
      itself isn't a big deal, but it makes some follow-on patches simpler.
      Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      Acked-by: NMichal Simek <monstr@monstr.eu>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      530210c7
    • G
      of/irq: Rename of_irq_map_* functions to of_irq_parse_* · 0c02c800
      Grant Likely 提交于
      The OF irq handling code has been overloading the term 'map' to refer to
      both parsing the data in the device tree and mapping it to the internal
      linux irq system. This is probably because the device tree does have the
      concept of an 'interrupt-map' function for translating interrupt
      references from one node to another, but 'map' is still confusing when
      the primary purpose of some of the functions are to parse the DT data.
      
      This patch renames all the of_irq_map_* functions to of_irq_parse_*
      which makes it clear that there is a difference between the parsing
      phase and the mapping phase. Kernel code can make use of just the
      parsing or just the mapping support as needed by the subsystem.
      
      The patch was generated mechanically with a handful of sed commands.
      Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      Acked-by: NMichal Simek <monstr@monstr.eu>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      0c02c800
  17. 23 8月, 2013 1 次提交
  18. 14 8月, 2013 3 次提交
  19. 24 7月, 2013 1 次提交
    • G
      powerpc/pci: Partial tree hotplug support · ab444ec9
      Gavin Shan 提交于
      When EEH error happens to one specific PE, the device drivers
      of its attached EEH devices (PCI devices) are checked to see
      the further action: reset with complete hotplug, or reset without
      hotplug. However, that's not enough for those PCI devices whose
      drivers can't support EEH, or those PCI devices without driver.
      So we need do so-called "partial hotplug" on basis of PCI devices.
      In the situation, part of PCI devices of the specific PE are
      unplugged and plugged again after PE reset.
      
      The patch changes pcibios_add_pci_devices() so that it can support
      full hotplug and so-called "partial" hotplug based on device-tree
      or real hardware. It's notable that pci_of_scan.c has been changed
      for a bit in order to support the "partial" hotplug based on dev-tree.
      
      Most of the generic code already supports that, we just need to
      plumb it properly on our side.
      Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      ab444ec9
  20. 30 6月, 2013 1 次提交
    • G
      powerpc/pci: Improve device hotplug initialization · 7846de40
      Guenter Roeck 提交于
      Commit 37f02195 (powerpc/pci: fix PCI-e devices rescan issue on powerpc
      platform) fixes a problem with interrupt and DMA initialization on hot
      plugged devices. With this commit, interrupt and DMA initialization for
      hot plugged devices is handled in the pci device enable function.
      
      This approach has a couple of drawbacks. First, it creates two code paths
      for device initialization, one for hot plugged devices and another for devices
      known during the initial PCI scan. Second, the initialization code for hot
      plugged devices is only called when the device is enabled, ie typically
      in the probe function. Also, the platform specific setup code is called each
      time pci_enable_device() is called, not only once during device discovery,
      meaning it is actually called multiple times, once for devices discovered
      during the initial scan and again each time a driver is re-loaded.
      
      The visible result is that interrupt pins are only assigned to hot plugged
      devices when the device driver is loaded. Effectively this changes the PCI
      probe API, since pci_dev->irq and the device's dma configuration will now
      only be valid after pci_enable() was called at least once. A more subtle
      change is that platform specific PCI device setup is moved from device
      discovery into the driver's probe function, more specifically into the
      pci_enable_device() call.
      
      To fix the inconsistencies, add new function pcibios_add_device.
      Call pcibios_setup_device from pcibios_setup_bus_devices if device setup
      is not complete, and from pcibios_add_device if bus setup is complete.
      
      With this change, device setup code is moved back into device initialization,
      and called exactly once for both static and hot plugged devices.
      
      [ This also fixes a regression introduced by the above patch which
        causes dev->irq to be overwritten under some cirumstances after
        MSIs have been enabled for the device which leads to crashes due
        to the MSI core "hijacking" dev->irq to store the base MSI number
        and not the LSI. --BenH
      ]
      
      Cc: Yuanquan Chen <Yuanquan.Chen@freescale.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Hiroo Matsumoto <matsumoto.hiroo@jp.fujitsu.com>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      7846de40
  21. 10 6月, 2013 1 次提交
  22. 01 6月, 2013 2 次提交
  23. 24 5月, 2013 1 次提交
  24. 14 5月, 2013 1 次提交