1. 25 1月, 2017 1 次提交
  2. 22 11月, 2016 2 次提交
  3. 04 10月, 2016 1 次提交
  4. 29 9月, 2016 1 次提交
  5. 23 9月, 2016 2 次提交
  6. 21 9月, 2016 1 次提交
  7. 15 9月, 2016 2 次提交
  8. 14 9月, 2016 1 次提交
  9. 09 9月, 2016 1 次提交
    • S
      powerpc/powernv: Provide facilities for EOI, usable from real mode · 4ee11c1a
      Suresh Warrier 提交于
      This adds a new function pnv_opal_pci_msi_eoi() which does the part of
      end-of-interrupt (EOI) handling of an MSI which involves doing an
      OPAL call.  This function can be called in real mode.  This doesn't
      just export pnv_ioda2_msi_eoi() because that does a call to
      icp_native_eoi(), which does not work in real mode.
      
      This also adds a function, is_pnv_opal_msi(), which KVM can call to
      check whether an interrupt is one for which we should be calling
      pnv_opal_pci_msi_eoi() when we need to do an EOI.
      
      [paulus@ozlabs.org - split out the addition of pnv_opal_pci_msi_eoi()
       from Suresh's patch "KVM: PPC: Book3S HV: Handle passthrough
       interrupts in guest"; added is_pnv_opal_msi(); wrote description.]
      Signed-off-by: NSuresh Warrier <warrier@linux.vnet.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@ozlabs.org>
      4ee11c1a
  10. 08 9月, 2016 1 次提交
  11. 06 9月, 2016 1 次提交
    • G
      powerpc/powernv: Fix crash on releasing compound PE · b314427a
      Gavin Shan 提交于
      The compound PE is created to accommodate the devices attached to
      one specific PCI bus that consume multiple M64 segments. The compound
      PE is made up of one master PE and possibly multiple slave PEs. The
      slave PEs should be destroyed when releasing the master PE. A kernel
      crash happens when derferencing @pe->pdev on releasing the slave PE
      in pnv_ioda_deconfigure_pe().
      
        # echo 0 > /sys/bus/pci/slots/C7/power
        iommu: Removing device 0000:01:00.1 from group 0
        iommu: Removing device 0000:01:00.0 from group 0
        Unable to handle kernel paging request for data at address 0x00000010
        Faulting instruction address: 0xc00000000005d898
        cpu 0x1: Vector: 300 (Data Access) at [c000000fe8217620]
            pc: c00000000005d898: pnv_ioda_release_pe+0x288/0x610
            lr: c00000000005dbdc: pnv_ioda_release_pe+0x5cc/0x610
            sp: c000000fe82178a0
           msr: 9000000000009033
           dar: 10
         dsisr: 40000000
          current = 0xc000000fe815ab80
          paca    = 0xc00000000ff00400	 softe: 0	 irq_happened: 0x01
            pid   = 2709, comm = sh
        Linux version 4.8.0-rc5-gavin-00006-g745efdb (gwshan@gwshan) \
        (gcc version 4.9.3 (Buildroot 2016.02-rc2-00093-g5ea3bce) ) #586 SMP \
        Tue Sep 6 13:37:29 AEST 2016
        enter ? for help
        [c000000fe8217940] c00000000005d684 pnv_ioda_release_pe+0x74/0x610
        [c000000fe82179e0] c000000000034460 pcibios_release_device+0x50/0x70
        [c000000fe8217a10] c0000000004aba80 pci_release_dev+0x50/0xa0
        [c000000fe8217a40] c000000000704898 device_release+0x58/0xf0
        [c000000fe8217ac0] c000000000470510 kobject_release+0x80/0xf0
        [c000000fe8217b00] c000000000704dd4 put_device+0x24/0x40
        [c000000fe8217b20] c0000000004af94c pci_remove_bus_device+0x12c/0x150
        [c000000fe8217b60] c000000000034244 pci_hp_remove_devices+0x94/0xd0
        [c000000fe8217ba0] c0000000004ca444 pnv_php_disable_slot+0x64/0xb0
        [c000000fe8217bd0] c0000000004c88c0 power_write_file+0xa0/0x190
        [c000000fe8217c50] c0000000004c248c pci_slot_attr_store+0x3c/0x60
        [c000000fe8217c70] c0000000002d6494 sysfs_kf_write+0x94/0xc0
        [c000000fe8217cb0] c0000000002d50f0 kernfs_fop_write+0x180/0x260
        [c000000fe8217d00] c0000000002334a0 __vfs_write+0x40/0x190
        [c000000fe8217d90] c000000000234738 vfs_write+0xc8/0x240
        [c000000fe8217de0] c000000000236250 SyS_write+0x60/0x110
        [c000000fe8217e30] c000000000009524 system_call+0x38/0x108
      
      It fixes the kernel crash by bypassing releasing resources (DMA,
      IO and memory segments, PELTM) because there are no resources assigned
      to the slave PE.
      
      Fixes: c5f7700b ("powerpc/powernv: Dynamically release PE")
      Reported-by: NFrederic Barrat <fbarrat@linux.vnet.ibm.com>
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      b314427a
  12. 22 8月, 2016 1 次提交
  13. 09 8月, 2016 2 次提交
  14. 04 8月, 2016 1 次提交
    • K
      dma-mapping: use unsigned long for dma_attrs · 00085f1e
      Krzysztof Kozlowski 提交于
      The dma-mapping core and the implementations do not change the DMA
      attributes passed by pointer.  Thus the pointer can point to const data.
      However the attributes do not have to be a bitfield.  Instead unsigned
      long will do fine:
      
      1. This is just simpler.  Both in terms of reading the code and setting
         attributes.  Instead of initializing local attributes on the stack
         and passing pointer to it to dma_set_attr(), just set the bits.
      
      2. It brings safeness and checking for const correctness because the
         attributes are passed by value.
      
      Semantic patches for this change (at least most of them):
      
          virtual patch
          virtual context
      
          @r@
          identifier f, attrs;
      
          @@
          f(...,
          - struct dma_attrs *attrs
          + unsigned long attrs
          , ...)
          {
          ...
          }
      
          @@
          identifier r.f;
          @@
          f(...,
          - NULL
          + 0
           )
      
      and
      
          // Options: --all-includes
          virtual patch
          virtual context
      
          @r@
          identifier f, attrs;
          type t;
      
          @@
          t f(..., struct dma_attrs *attrs);
      
          @@
          identifier r.f;
          @@
          f(...,
          - NULL
          + 0
           )
      
      Link: http://lkml.kernel.org/r/1468399300-5399-2-git-send-email-k.kozlowski@samsung.comSigned-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Acked-by: NVineet Gupta <vgupta@synopsys.com>
      Acked-by: NRobin Murphy <robin.murphy@arm.com>
      Acked-by: NHans-Christian Noren Egtvedt <egtvedt@samfundet.no>
      Acked-by: Mark Salter <msalter@redhat.com> [c6x]
      Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> [cris]
      Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> [drm]
      Reviewed-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
      Acked-by: Fabien Dessenne <fabien.dessenne@st.com> [bdisp]
      Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> [vb2-core]
      Acked-by: David Vrabel <david.vrabel@citrix.com> [xen]
      Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> [xen swiotlb]
      Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
      Acked-by: Richard Kuo <rkuo@codeaurora.org> [hexagon]
      Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> [m68k]
      Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> [s390]
      Acked-by: NBjorn Andersson <bjorn.andersson@linaro.org>
      Acked-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no> [avr32]
      Acked-by: Vineet Gupta <vgupta@synopsys.com> [arc]
      Acked-by: Robin Murphy <robin.murphy@arm.com> [arm64 and dma-iommu]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      00085f1e
  15. 17 7月, 2016 7 次提交
  16. 14 7月, 2016 3 次提交
    • I
      cxl: Add support for interrupts on the Mellanox CX4 · a2f67d5e
      Ian Munsie 提交于
      The Mellanox CX4 in cxl mode uses a hybrid interrupt model, where
      interrupts are routed from the networking hardware to the XSL using the
      MSIX table, and from there will be transformed back into an MSIX
      interrupt using the cxl style interrupts (i.e. using IVTE entries and
      ranges to map a PE and AFU interrupt number to an MSIX address).
      
      We want to hide the implementation details of cxl interrupts as much as
      possible. To this end, we use a special version of the MSI setup &
      teardown routines in the PHB while in cxl mode to allocate the cxl
      interrupts and configure the IVTE entries in the process element.
      
      This function does not configure the MSIX table - the CX4 card uses a
      custom format in that table and it would not be appropriate to fill that
      out in generic code. The rest of the functionality is similar to the
      "Full MSI-X mode" described in the CAIA, and this could be easily
      extended to support other adapters that use that mode in the future.
      
      The interrupts will be associated with the default context. If the
      maximum number of interrupts per context has been limited (e.g. by the
      mlx5 driver), it will automatically allocate additional kernel contexts
      to associate extra interrupts as required. These contexts will be
      started using the same WED that was used to start the default context.
      Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
      Reviewed-by: NAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      a2f67d5e
    • I
      powerpc/powernv: Add support for the cxl kernel api on the real phb · 4361b034
      Ian Munsie 提交于
      This adds support for the peer model of the cxl kernel api to the
      PowerNV PHB, in which physical function 0 represents the cxl function on
      the card (an XSL in the case of the CX4), which other physical functions
      will use for memory access and interrupt services. It is referred to as
      the peer model as these functions are peers of one another, as opposed
      to the Virtual PHB model which forms a hierarchy.
      
      This patch exports APIs to enable the peer mode, check if a PCI device
      is attached to a PHB in this mode, and to set and get the peer AFU for
      this mode.
      
      The cxl driver will enable this mode for supported cards by calling
      pnv_cxl_enable_phb_kernel_api(). This will set a flag in the PHB to note
      that this mode is enabled, and switch out it's controller_ops for the
      cxl version.
      
      The cxl version of the controller_ops struct implements it's own
      versions of the enable_device_hook and release_device to handle
      refcounting on the peer AFU and to allocate a default context for the
      device.
      
      Once enabled, the cxl kernel API may not be disabled on a PHB. Currently
      there is no safe way to disable cxl mode short of a reboot, so until
      that changes there is no reason to support the disable path.
      Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
      Reviewed-by: NAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      4361b034
    • I
      powerpc/powernv: Split cxl code out into a separate file · f456834a
      Ian Munsie 提交于
      The support for using the Mellanox CX4 in cxl mode will require
      additions to the PHB code. In preparation for this, move the existing
      cxl code out of pci-ioda.c into a separate pci-cxl.c file to keep things
      more organised.
      Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
      Reviewed-by: NAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Reviewed-by: NFrederic Barrat <fbarrat@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      f456834a
  17. 21 6月, 2016 9 次提交
    • G
      powerpc/powernv: Print correct PHB type names · 9497a1c1
      Gavin Shan 提交于
      We're initializing "IODA1" and "IODA2" PHBs though they are IODA2
      and NPU PHBs as below kernel log indicates.
      
         Initializing IODA1 OPAL PHB /pciex@3fffe40700000
         Initializing IODA2 OPAL PHB /pciex@3fff000400000
      
      This fixes the PHB names. After it's applied, we get:
      
         Initializing IODA2 PHB (/pciex@3fffe40700000)
         Initializing NPU PHB (/pciex@3fff000400000)
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      9497a1c1
    • G
      powerpc/powernv: Dynamically release PE · c5f7700b
      Gavin Shan 提交于
      This supports releasing PEs dynamically. A reference count is
      introduced to PE representing number of PCI devices associated
      with the PE. The reference count is increased when PCI device
      joins the PE and decreased when PCI device leaves the PE in
      pnv_pci_release_device(). When the count becomes zero, the PE
      and its consumed resources are released. Note that the count
      is accessed concurrently. So a counter with "int" type is enough
      here.
      
      In order to release the sources consumed by the PE, couple of
      helper functions are introduced as below:
      
         * pnv_pci_ioda1_unset_window() - Unset IODA1 DMA32 window
         * pnv_pci_ioda1_release_dma_pe() - Release IODA1 DMA32 segments
         * pnv_pci_ioda2_release_dma_pe() - Release IODA2 DMA resource
         * pnv_ioda_release_pe_seg() - Unmap IO/M32/M64 segments
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      c5f7700b
    • G
      powerpc/powernv: Make pnv_ioda_deconfigure_pe() visible · 93e01a50
      Gavin Shan 提交于
      pnv_ioda_deconfigure_pe() is visible only when CONFIG_PCI_IOV is
      enabled. The function will be used to tear down PE's associated
      mapping in PCI hotplug path that doesn't depend on CONFIG_PCI_IOV.
      
      This makes pnv_ioda_deconfigure_pe() visible and not depend on
      CONFIG_PCI_IOV.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      93e01a50
    • G
      powerpc/powernv: Extend PCI bridge resources · 40e2a47e
      Gavin Shan 提交于
      The PCI slots are associated with root port or downstream ports
      of the PCIe switch connected to root port. When adapter is hot
      added to the PCI slot, it usually requests more IO or memory
      resource from the directly connected parent bridge (port) and
      update the bridge's windows accordingly. The resource windows
      of upstream bridges can't be updated automatically. It possibly
      leads to unbalanced resource across the bridges: The window of
      downstream bridge is overruning that of upstream bridge. The
      IO or MMIO path won't work.
      
      This resolves the above issue by extending bridge windows of
      root port and upstream port of the PCIe switch connected to
      the root port to PHB's windows.
      
      The windows of root port and bridge behind that are extended to
      the PHB's windows to accomodate the PCI hotplug happening in
      future. The PHB's 64KB 32-bits MSI region is included in bridge's
      M32 windows (in hardware) though it's excluded in the corresponding
      resource, as the bridge's M32 windows have 1MB as their minimal
      alignment. We observed EEH error during system boot when the MSI
      region is included in bridge's M32 window.
      
      This excludes top 1MB (including 64KB 32-bits MSI region) region
      from bridge's M32 windows when extending them.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      40e2a47e
    • G
      powerpc/powernv: Setup PE for root bus · 63803c39
      Gavin Shan 提交于
      There is no parent bridge for root bus, meaning pcibios_setup_bridge()
      isn't invoked for root bus. The PE for root bus is the ancestor of
      other PEs in PELTV. It means we need PE for root bus populated before
      all others.
      
      This populates the PE for root bus in pcibios_setup_bridge() path
      if it's not populated yet. The PE number next to the reserved one
      is used as the PE# to avoid holes in continuous M64 space.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      63803c39
    • G
      powerpc/powernv: Create PEs in pcibios_setup_bridge() · ccd1c191
      Gavin Shan 提交于
      Currently, the PEs and their associated resources are assigned in
      ppc_md.pcibios_fixup() except those used by SRIOV VFs. The function
      is called for once after PCI probing and resources assignment is
      completed. So it's obviously not hotplug friendly.
      
      This creates PEs dynamically in pcibios_setup_bridge() that is
      called for the event during system bootup and PCI hotplug: updating
      PCI bridge's windows after resource assignment/reassignment are done.
      In partial hotplug case, not all PCI devices included to one particular
      PE are unplugged and plugged again, we just need unbinding/binding the
      hot added PCI devices with the corresponding PE without creating new
      one. The change is applied to IODA1 and IODA2 PHBs only. The behaviour
      on NPU PHBs aren't changed. There are no PCI bridges on NPU PHBs,
      meaning pcibios_setup_bridge() won't be invoked there. We have to use
      old path (pnv_pci_ioda_fixup()) to setup PEs on NPU PHBs.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      ccd1c191
    • G
      powerpc/powernv: Allocate PE# in reverse order · 9fcd6f4a
      Gavin Shan 提交于
      PE number for one particular PE can be allocated dynamically or
      reserved according to the consumed M64 (64-bits prefetchable)
      segments of the PE. The M64 segment can't be remapped to arbitrary
      PE, meaning the PE number is determined according to the index
      of the consumed M64 segment. As below figure shows, M64 resource
      grows from low to high end, meaning the PE (number) reserved
      according to M64 segment grows from low to high end as well,
      so does the dynamically allocated PE number. It will lead to
      conflict: PE number (M64 segment) reserved by dynamic allocation
      is required by hot added PCI adapter at later point. It fails
      the PCI hotplug because of the PE number can't be reserved
      based on the index of the consumed M64 segment.
      
        +---+---+---+---+---+--------------------------------+-----+
        | 0 | 1 | 2 | 3 | 4 |      .......                   | 255 |
        +---+---+---+---+---+--------------------------------+-----+
      
        PE number for dynamic allocation          ----------------->
        PE number reserved for M64 segment        ----------------->
      
      To resolve above conflicts, this forces the PE number to be
      allocated dynamically in reverse order. With this patch applied,
      the PE numbers are reserved in ascending order, but allocated
      dynamically in reverse order.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      9fcd6f4a
    • G
      powerpc/powernv: Increase PE# capacity · c127562a
      Gavin Shan 提交于
      Each PHB maintains an array helping to translate 2-bytes Request
      ID (RID) to PE# with the assumption that PE# takes one byte, meaning
      that we can't have more than 256 PEs. However, pci_dn->pe_number
      already had 4-bytes for the PE#.
      
      This extends the PE# capacity for every PHB. After that, the PE number
      is represented by 4-bytes value. Then we can reuse IODA_INVALID_PE to
      check the PE# in phb->pe_rmap[] is valid or not.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Reviewed-by: NDaniel Axtens <dja@axtens.net>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      c127562a
    • G
      powerpc/powernv: Move pnv_pci_ioda_setup_opal_tce_kill() around · 577c8c88
      Gavin Shan 提交于
      pnv_pci_ioda_setup_opal_tce_kill() called by pnv_ioda_setup_dma()
      to remap the TCE kill regiter. What's done in pnv_ioda_setup_dma()
      will be covered in pcibios_setup_bridge() which is invoked on each
      PCI bridge. It means we will possibly remap the TCE kill register
      for multiple times and it's unnecessary.
      
      This moves pnv_pci_ioda_setup_opal_tce_kill() to where the PHB is
      initialized (pnv_pci_init_ioda_phb()) to avoid above issue.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Reviewed-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      577c8c88
  18. 16 6月, 2016 1 次提交
  19. 14 6月, 2016 1 次提交
  20. 12 5月, 2016 1 次提交