1. 17 3月, 2015 2 次提交
  2. 02 2月, 2015 1 次提交
    • R
      cxl: Fix device_node reference counting · 6f963ec2
      Ryan Grimm 提交于
      When unbinding and rebinding the driver on a system with a card in PHB0, this
      error condition is reached after a few attempts:
      
      ERROR: Bad of_node_put() on /pciex@3fffe40000000
      CPU: 0 PID: 3040 Comm: bash Not tainted 3.18.0-rc3-12545-g3627ffe #152
      Call Trace:
      [c000000721acb5c0] [c00000000086ef94] .dump_stack+0x84/0xb0 (unreliable)
      [c000000721acb640] [c00000000073a0a8] .of_node_release+0xd8/0xe0
      [c000000721acb6d0] [c00000000044bc44] .kobject_release+0x74/0xe0
      [c000000721acb760] [c0000000007394fc] .of_node_put+0x1c/0x30
      [c000000721acb7d0] [c000000000545cd8] .cxl_probe+0x1a98/0x1d50
      [c000000721acb900] [c0000000004845a0] .local_pci_probe+0x40/0xc0
      [c000000721acb980] [c000000000484998] .pci_device_probe+0x128/0x170
      [c000000721acba30] [c00000000052400c] .driver_probe_device+0xac/0x2a0
      [c000000721acbad0] [c000000000522468] .bind_store+0x108/0x160
      [c000000721acbb70] [c000000000521448] .drv_attr_store+0x38/0x60
      [c000000721acbbe0] [c000000000293840] .sysfs_kf_write+0x60/0xa0
      [c000000721acbc50] [c000000000292500] .kernfs_fop_write+0x140/0x1d0
      [c000000721acbcf0] [c000000000208648] .vfs_write+0xd8/0x260
      [c000000721acbd90] [c000000000208b18] .SyS_write+0x58/0x100
      [c000000721acbe30] [c000000000009258] syscall_exit+0x0/0x98
      
      We are missing a call to of_node_get(). pnv_pci_to_phb_node() should
      call of_node_get() otherwise np's reference count isn't incremented and
      it might go away. Rename pnv_pci_to_phb_node() to pnv_pci_get_phb_node()
      so it's clear it calls of_node_get().
      Signed-off-by: NRyan Grimm <grimm@linux.vnet.ibm.com>
      Acked-by: NIan Munsie <imunsie@au1.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      6f963ec2
  3. 23 1月, 2015 2 次提交
  4. 22 1月, 2015 1 次提交
  5. 27 11月, 2014 1 次提交
  6. 24 11月, 2014 1 次提交
  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. 14 11月, 2014 7 次提交
  9. 08 10月, 2014 2 次提交
  10. 30 9月, 2014 2 次提交
  11. 25 9月, 2014 3 次提交
  12. 13 8月, 2014 1 次提交
    • G
      powerpc/powernv: Fix IOMMU group lost · 763fe0ad
      Gavin Shan 提交于
      When we take full hotplug to recover from EEH errors, PCI buses
      could be involved. For the case, the child devices of involved
      PCI buses can't be attached to IOMMU group properly, which is
      caused by commit 3f28c5af ("powerpc/powernv: Reduce multi-hit of
      iommu_add_device()").
      
      When adding the PCI devices of the newly created PCI buses to
      the system, the IOMMU group is expected to be added in (C).
      (A) fails to bind the IOMMU group because bus->is_added is
      false. (B) fails because the device doesn't have binding IOMMU
      table yet. bus->is_added is set to true at end of (C) and
      pdev->is_added is set to true at (D).
      
         pcibios_add_pci_devices()
            pci_scan_bridge()
               pci_scan_child_bus()
                  pci_scan_slot()
                     pci_scan_single_device()
                        pci_scan_device()
                        pci_device_add()
                           pcibios_add_device()           A: Ignore
                           device_add()                   B: Ignore
                        pcibios_fixup_bus()
                           pcibios_setup_bus_devices()
                              pcibios_setup_device()      C: Hit
            pcibios_finish_adding_to_bus()
               pci_bus_add_devices()
                  pci_bus_add_device()                    D: Add device
      
      If the parent PCI bus isn't involved in hotplug, the IOMMU
      group is expected to be bound in (B). (A) should fail as the
      sysfs entries aren't populated.
      
      The patch fixes the issue by reverting commit 3f28c5af and remove
      WARN_ON() in iommu_add_device() to allow calling the function
      even the specified device already has associated IOMMU group.
      
      Cc: <stable@vger.kernel.org>  # 3.16+
      Reported-by: NThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Acked-by: NWei Yang <weiyang@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      763fe0ad
  13. 05 8月, 2014 6 次提交
  14. 11 7月, 2014 2 次提交
  15. 28 4月, 2014 6 次提交
    • G
      powerpc/powernv: Don't use pe->pbus to get the domain number · e9bc03fe
      Gavin Shan 提交于
      If the PE contains single PCI function, "pe->pbus" would be NULL.
      It's not reliable to be used by pci_domain_nr().  We just grab the
      PCI domain number from the PCI host controller (struct pci_controller)
      instance.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      e9bc03fe
    • G
      powerpc/powernv: Missed IOMMU table type · 65fd766b
      Gavin Shan 提交于
      In function pnv_pci_ioda2_setup_dma_pe(), the IOMMU table type is
      set to (TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE) unconditionally.
      It was just set to TCE_PCI by pnv_pci_setup_iommu_table(). So the
      primary IOMMU table type (TCE_PCI) is lost. The patch fixes it.
      
      Also, pnv_pci_setup_iommu_table() already set "tbl->it_busno" to
      zero and we needn't do it again. The patch removes the redundant
      assignment.
      
      The patch also fixes similar issues in pnv_pci_ioda_setup_dma_pe().
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      65fd766b
    • G
      powrpc/powernv: Reset PHB in kdump kernel · 361f2a2a
      Gavin Shan 提交于
      In the kdump scenario, the first kerenl doesn't shutdown PCI devices
      and the kdump kerenl clean PHB IODA table at the early probe time.
      That means the kdump kerenl can't support PCI transactions piled
      by the first kerenl. Otherwise, lots of EEH errors and frozen PEs
      will be detected.
      
      In order to avoid the EEH errors, the PHB is resetted to drop all
      PCI transaction from the first kerenl.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      361f2a2a
    • G
      powerpc/pci: Mask linkDown on resetting PCI bus · d92a208d
      Gavin Shan 提交于
      The problem was initially reported by Wendy who tried pass through
      IPR adapter, which was connected to PHB root port directly, to KVM
      based guest. When doing that, pci_reset_bridge_secondary_bus() was
      called by VFIO driver and linkDown was detected by the root port.
      That caused all PEs to be frozen.
      
      The patch fixes the issue by routing the reset for the secondary bus
      of root port to underly firmware. For that, one more weak function
      pci_reset_secondary_bus() is introduced so that the individual platforms
      can override that and do specific reset for bridge's secondary bus.
      Reported-by: NWendy Xiong <wenxiong@linux.vnet.ibm.com>
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      d92a208d
    • W
      powerpc/powernv: Release the refcount for pci_dev · 4966bfa1
      Wei Yang 提交于
      On PowerNV platform, we are holding an unnecessary refcount on a pci_dev, which
      leads to the pci_dev is not destroyed when hotplugging a pci device.
      
      This patch release the unnecessary refcount.
      Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      4966bfa1
    • W
      powerpc/powernv: Reduce multi-hit of iommu_add_device() · 3f28c5af
      Wei Yang 提交于
      During the EEH hotplug event, iommu_add_device() will be invoked three times
      and two of them will trigger warning or error.
      
      The three times to invoke the iommu_add_device() are:
      
          pci_device_add
             ...
             set_iommu_table_base_and_group   <- 1st time, fail
          device_add
             ...
             tce_iommu_bus_notifier           <- 2nd time, succees
          pcibios_add_pci_devices
             ...
             pcibios_setup_bus_devices        <- 3rd time, re-attach
      
      The first time fails, since the dev->kobj->sd is not initialized. The
      dev->kobj->sd is initialized in device_add().
      The third time's warning is triggered by the re-attach of the iommu_group.
      
      After applying this patch, the error
      
          iommu_tce: 0003:05:00.0 has not been added, ret=-14
      
      and the warning
      
          [  204.123609] ------------[ cut here ]------------
          [  204.123645] WARNING: at arch/powerpc/kernel/iommu.c:1125
          [  204.123680] Modules linked in: xt_CHECKSUM nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6t_REJECT bnep bluetooth 6lowpan_iphc rfkill xt_conntrack ebtable_nat ebtable_broute bridge stp llc mlx4_ib ib_sa ib_mad ib_core ib_addr ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw bnx2x tg3 mlx4_core nfsd ptp mdio ses libcrc32c nfs_acl enclosure be2net pps_core shpchp lockd kvm uinput sunrpc binfmt_misc lpfc scsi_transport_fc ipr scsi_tgt
          [  204.124356] CPU: 18 PID: 650 Comm: eehd Not tainted 3.14.0-rc5yw+ #102
          [  204.124400] task: c0000027ed485670 ti: c0000027ed50c000 task.ti: c0000027ed50c000
          [  204.124453] NIP: c00000000003cf80 LR: c00000000006c648 CTR: c00000000006c5c0
          [  204.124506] REGS: c0000027ed50f440 TRAP: 0700   Not tainted  (3.14.0-rc5yw+)
          [  204.124558] MSR: 9000000000029032 <SF,HV,EE,ME,IR,DR,RI>  CR: 88008084  XER: 20000000
          [  204.124682] CFAR: c00000000006c644 SOFTE: 1
          GPR00: c00000000006c648 c0000027ed50f6c0 c000000001398380 c0000027ec260300
          GPR04: c0000027ea92c000 c00000000006ad00 c0000000016e41b0 0000000000000110
          GPR08: c0000000012cd4c0 0000000000000001 c0000027ec2602ff 0000000000000062
          GPR12: 0000000028008084 c00000000fdca200 c0000000000d1d90 c0000027ec281a80
          GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
          GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
          GPR24: 000000005342697b 0000000000002906 c000001fe6ac9800 c000001fe6ac9800
          GPR28: 0000000000000000 c0000000016e3a80 c0000027ea92c090 c0000027ea92c000
          [  204.125353] NIP [c00000000003cf80] .iommu_add_device+0x30/0x1f0
          [  204.125399] LR [c00000000006c648] .pnv_pci_ioda_dma_dev_setup+0x88/0xb0
          [  204.125443] Call Trace:
          [  204.125464] [c0000027ed50f6c0] [c0000027ed50f750] 0xc0000027ed50f750 (unreliable)
          [  204.125526] [c0000027ed50f750] [c00000000006c648] .pnv_pci_ioda_dma_dev_setup+0x88/0xb0
          [  204.125588] [c0000027ed50f7d0] [c000000000069cc8] .pnv_pci_dma_dev_setup+0x78/0x340
          [  204.125650] [c0000027ed50f870] [c000000000044408] .pcibios_setup_device+0x88/0x2f0
          [  204.125712] [c0000027ed50f940] [c000000000046040] .pcibios_setup_bus_devices+0x60/0xd0
          [  204.125774] [c0000027ed50f9c0] [c000000000043acc] .pcibios_add_pci_devices+0xdc/0x1c0
          [  204.125837] [c0000027ed50fa50] [c00000000086f970] .eeh_reset_device+0x36c/0x4f0
          [  204.125939] [c0000027ed50fb20] [c00000000003a2d8] .eeh_handle_normal_event+0x448/0x480
          [  204.126068] [c0000027ed50fbc0] [c00000000003a35c] .eeh_handle_event+0x4c/0x340
          [  204.126192] [c0000027ed50fc80] [c00000000003a74c] .eeh_event_handler+0xfc/0x1b0
          [  204.126319] [c0000027ed50fd30] [c0000000000d1ea0] .kthread+0x110/0x130
          [  204.126430] [c0000027ed50fe30] [c00000000000a460] .ret_from_kernel_thread+0x5c/0x7c
          [  204.126556] Instruction dump:
          [  204.126610] 7c0802a6 fba1ffe8 fbc1fff0 fbe1fff8 f8010010 f821ff71 7c7e1b78 60000000
          [  204.126787] 60000000 e87e0298 3143ffff 7d2a1910 <0b090000> 2fa90000 40de00c8 ebfe0218
          [  204.126966] ---[ end trace 6e7aefd80add2973 ]---
      
      are cleared.
      
      This patch removes iommu_add_device() in pnv_pci_ioda_dma_dev_setup(), which
      revert part of the change in commit d905c5df(PPC: POWERNV: move
      iommu_add_device earlier).
      Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      3f28c5af
  16. 11 2月, 2014 1 次提交
    • B
      powerpc/powernv: Add iommu DMA bypass support for IODA2 · cd15b048
      Benjamin Herrenschmidt 提交于
      This patch adds the support for to create a direct iommu "bypass"
      window on IODA2 bridges (such as Power8) allowing to bypass iommu
      page translation completely for 64-bit DMA capable devices, thus
      significantly improving DMA performances.
      
      Additionally, this adds a hook to the struct iommu_table so that
      the IOMMU API / VFIO can disable the bypass when external ownership
      is requested, since in that case, the device will be used by an
      environment such as userspace or a KVM guest which must not be
      allowed to bypass translations.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      cd15b048
  17. 15 1月, 2014 1 次提交