1. 21 12月, 2018 1 次提交
  2. 27 1月, 2018 2 次提交
  3. 11 12月, 2017 1 次提交
  4. 06 11月, 2017 1 次提交
  5. 31 8月, 2017 1 次提交
    • A
      powerpc/pci: Remove OF node back pointer from pci_dn · f1e08232
      Alexey Kardashevskiy 提交于
      The check_req() helper uses pci_get_pdn() to get an OF node pointer.
      pci_get_pdn() returns a pci_dn pointer which either:
      1) from the OF node returned by pci_device_to_OF_node();
      2) from the parent child_list where entries don't have OF node pointers.
      Since check_req() does not care about 2), it can call
      pci_device_to_OF_node() directly, hence the change.
      
      The find_pe_dn() helper uses embedded pci_dn to get an OF node which is
      also stored in edev->pdev so let's take a shortcut and call
      pci_device_to_OF_node() directly.
      
      With these 2 changes, we can finally get rid of the OF node back pointer.
      Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      f1e08232
  6. 31 1月, 2017 1 次提交
  7. 22 8月, 2016 1 次提交
    • M
      powerpc/pseries: use pci_host_bridge.release_fn() to kfree(phb) · 2dd9c11b
      Mauricio Faria de Oliveira 提交于
      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: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NMauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
      Reviewed-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Reviewed-by: NAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Tested-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> # cxl
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      2dd9c11b
  8. 21 6月, 2016 1 次提交
  9. 11 5月, 2016 6 次提交
  10. 09 3月, 2016 2 次提交
    • W
      powerpc/eeh: powerpc/eeh: Support error recovery for VF PE · 67086e32
      Wei Yang 提交于
      PFs are enumerated on PCI bus, while VFs are created by PF's driver.
      
      In EEH recovery, it has two cases:
      1. Device and driver is EEH aware, error handlers are called.
      2. Device and driver is not EEH aware, un-plug the device and plug it again
      by enumerating it.
      
      The special thing happens on the second case. For a PF, we could use the
      original pci core to enumerate the bus, while for VF we need to record the
      VFs which aer un-plugged then plug it again.
      
      Also The patch caches the VF index in pci_dn, which can be used to
      calculate VF's bus, device and function number. Those information helps to
      locate the VF's PCI device instance when doing hotplug during EEH recovery
      if necessary.
      Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
      Acked-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      67086e32
    • W
      powerpc/powernv: Support PCI config restore for VFs · 0dc2830e
      Wei Yang 提交于
      After PE reset, OPAL API opal_pci_reinit() is called on all devices
      contained in the PE to reinitialize them. While skiboot is not aware of
      VFs, we have to implement the function in kernel to reinitialize VFs after
      reset on PE for VFs.
      
      In this patch, two functions pnv_pci_fixup_vf_mps() and
      pnv_eeh_restore_vf_config() both manipulate the MPS of the VF, since for a
      VF it has three cases.
      
      1. Normal creation for a VF
         In this case, pnv_pci_fixup_vf_mps() is called to make the MPS a proper
         value compared with its parent.
      2. EEH recovery without VF removed
         In this case, MPS is stored in pci_dn and pnv_eeh_restore_vf_config() is
         called to restore it and reinitialize other part.
      3. EEH recovery with VF removed
         In this case, VF will be removed then re-created. Both functions are
         called. First pnv_pci_fixup_vf_mps() is called to store the proper MPS
         to pci_dn and then pnv_eeh_restore_vf_config() is called to do proper
         thing.
      
      This introduces two functions: pnv_pci_fixup_vf_mps() to fixup the VF's
      MPS to make sure it is equal to parent's and store this value in pci_dn
      for future use. pnv_eeh_restore_vf_config() to re-initialize on VF by
      restoring MPS, disabling completion timeout, enabling SERR, etc.
      Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
      Acked-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      0dc2830e
  11. 10 2月, 2016 2 次提交
  12. 06 2月, 2016 1 次提交
  13. 17 12月, 2015 1 次提交
  14. 18 8月, 2015 1 次提交
    • A
      powerpc/powernv: move dma_get_required_mask from pnv_phb to pci_controller_ops · 53522982
      Andrew Donnellan 提交于
      Simplify the dma_get_required_mask call chain by moving it from pnv_phb to
      pci_controller_ops, similar to commit 763d2d8d ("powerpc/powernv:
      Move dma_set_mask from pnv_phb to pci_controller_ops").
      
      Previous call chain:
      
        0) call dma_get_required_mask() (kernel/dma.c)
        1) call ppc_md.dma_get_required_mask, if it exists. On powernv, that
           points to pnv_dma_get_required_mask() (platforms/powernv/setup.c)
        2) device is PCI, therefore call pnv_pci_dma_get_required_mask()
           (platforms/powernv/pci.c)
        3) call phb->dma_get_required_mask if it exists
        4) it only exists in the ioda case, where it points to
             pnv_pci_ioda_dma_get_required_mask() (platforms/powernv/pci-ioda.c)
      
      New call chain:
      
        0) call dma_get_required_mask() (kernel/dma.c)
        1) device is PCI, therefore call pci_controller_ops.dma_get_required_mask
           if it exists
        2) in the ioda case, that points to pnv_pci_ioda_dma_get_required_mask()
           (platforms/powernv/pci-ioda.c)
      
      In the p5ioc2 case, the call chain remains the same -
      dma_get_required_mask() does not find either a ppc_md call or
      pci_controller_ops call, so it calls __dma_get_required_mask().
      Signed-off-by: NAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Reviewed-by: NDaniel Axtens <dja@axtens.net>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      53522982
  15. 11 6月, 2015 1 次提交
    • A
      powerpc/spapr: vfio: Replace iommu_table with iommu_table_group · b348aa65
      Alexey Kardashevskiy 提交于
      Modern IBM POWERPC systems support multiple (currently two) TCE tables
      per IOMMU group (a.k.a. PE). This adds a iommu_table_group container
      for TCE tables. Right now just one table is supported.
      
      This defines iommu_table_group struct which stores pointers to
      iommu_group and iommu_table(s). This replaces iommu_table with
      iommu_table_group where iommu_table was used to identify a group:
      - iommu_register_group();
      - iommudata of generic iommu_group;
      
      This removes @data from iommu_table as it_table_group provides
      same access to pnv_ioda_pe.
      
      For IODA, instead of embedding iommu_table, the new iommu_table_group
      keeps pointers to those. The iommu_table structs are allocated
      dynamically.
      
      For P5IOC2, both iommu_table_group and iommu_table are embedded into
      PE struct. As there is no EEH and SRIOV support for P5IOC2,
      iommu_free_table() should not be called on iommu_table struct pointers
      so we can keep it embedded in pnv_phb::p5ioc2.
      
      For pSeries, this replaces multiple calls of kzalloc_node() with a new
      iommu_pseries_alloc_group() helper and stores the table group struct
      pointer into the pci_dn struct. For release, a iommu_table_free_group()
      helper is added.
      
      This moves iommu_table struct allocation from SR-IOV code to
      the generic DMA initialization code in pnv_pci_ioda_setup_dma_pe and
      pnv_pci_ioda2_setup_dma_pe as this is where DMA is actually initialized.
      This change is here because those lines had to be changed anyway.
      
      This should cause no behavioural change.
      Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
      [aw: for the vfio related changes]
      Acked-by: NAlex Williamson <alex.williamson@redhat.com>
      Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Reviewed-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      b348aa65
  16. 03 6月, 2015 3 次提交
  17. 02 6月, 2015 1 次提交
  18. 22 5月, 2015 1 次提交
  19. 11 4月, 2015 7 次提交
  20. 31 3月, 2015 5 次提交