1. 15 7月, 2016 3 次提交
  2. 05 7月, 2016 1 次提交
  3. 21 6月, 2016 1 次提交
    • G
      powerpc/pci: Delay populating pdn · 8cc7581c
      Gavin Shan 提交于
      The pdn (struct pci_dn) instances are allocated from memblock or
      bootmem when creating PCI controller (hoses) in setup_arch(). PCI
      hotplug, which will be supported by proceeding patches, releases
      PCI device nodes and their corresponding pdn on unplugging event.
      The memory chunks for pdn instances allocated from memblock or
      bootmem are hard to reused after being released.
      
      This delays creating pdn by pci_devs_phb_init() from setup_arch()
      to core_initcall() so that they are allocated from slab. The memory
      consumed by pdn can be released to system without problem during
      PCI unplugging time. It indicates that pci_dn is unavailable in
      setup_arch() and the the fixup on pdn (like AGP's) can't be carried
      out that time. We have to do that in pcibios_root_bridge_prepare()
      on maple/pasemi/powermac platforms where/when the pdn is available.
      pcibios_root_bridge_prepare is called from subsys_initcall() which
      is executed after core_initcall() so the code flow does not change.
      
      At the mean while, the EEH device is created when pdn is populated,
      meaning pdn and EEH device have same life cycle. In turn, we needn't
      call eeh_dev_init() to create EEH device explicitly.
      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>
      8cc7581c
  4. 16 6月, 2016 3 次提交
  5. 14 6月, 2016 7 次提交
  6. 06 6月, 2016 1 次提交
  7. 30 5月, 2016 2 次提交
  8. 12 5月, 2016 1 次提交
    • G
      powerpc/iommu: Remove the dependency on EEH struct in DDW mechanism · 8445a87f
      Guilherme G. Piccoli 提交于
      Commit 39baadbf ("powerpc/eeh: Remove eeh information from pci_dn")
      changed the pci_dn struct by removing its EEH-related members.
      As part of this clean-up, DDW mechanism was modified to read the device
      configuration address from eeh_dev struct.
      
      As a consequence, now if we disable EEH mechanism on kernel command-line
      for example, the DDW mechanism will fail, generating a kernel oops by
      dereferencing a NULL pointer (which turns to be the eeh_dev pointer).
      
      This patch just changes the configuration address calculation on DDW
      functions to a manual calculation based on pci_dn members instead of
      using eeh_dev-based address.
      
      No functional changes were made. This was tested on pSeries, both
      in PHyp and qemu guest.
      
      Fixes: 39baadbf ("powerpc/eeh: Remove eeh information from pci_dn")
      Cc: stable@vger.kernel.org # v3.4+
      Reviewed-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NGuilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      8445a87f
  9. 11 5月, 2016 7 次提交
  10. 01 5月, 2016 2 次提交
    • A
      powerpc/mm/hash: Add support for Power9 Hash · 50de596d
      Aneesh Kumar K.V 提交于
      PowerISA 3.0 adds a parition table indexed by LPID. Parition table
      allows us to specify the MMU model that will be used for guest and host
      translation.
      
      This patch adds support with SLB based hash model (UPRT = 0). What is
      required with this model is to support the new hash page table entry
      format and also setup partition table such that we use hash table for
      address translation.
      
      We don't have segment table support yet.
      
      In order to make sure we don't load KVM module on Power9 (since we don't
      have kvm support yet) this patch also disables KVM on Power9.
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      50de596d
    • A
      powerpc/mm: Drop WIMG in favour of new constants · 30bda41a
      Aneesh Kumar K.V 提交于
      PowerISA 3.0 introduces two pte bits with the below meaning for radix:
        00 -> Normal Memory
        01 -> Strong Access Order (SAO)
        10 -> Non idempotent I/O (Cache inhibited and guarded)
        11 -> Tolerant I/O (Cache inhibited)
      
      We drop the existing WIMG bits in the Linux page table in favour of the
      above constants. We loose _PAGE_WRITETHRU with this conversion. We only
      use writethru via pgprot_cached_wthru() which is used by
      fbdev/controlfb.c which is Apple control display and also PPC32.
      
      With respect to _PAGE_COHERENCE, we have been marking hpte always
      coherent for some time now. htab_convert_pte_flags() always added
      HPTE_R_M.
      
      NOTE: KVM changes need closer review.
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      30bda41a
  11. 11 4月, 2016 2 次提交
    • N
      powerpc/pseries: Update LMB associativity index during DLPAR add/remove · bdf5fc63
      Nathan Fontenot 提交于
      The associativity array index specified for a LMB in the device tree,
      /ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory, needs to be updated
      prior to DLPAR adding a LMB and after DLPAR removing a LMB.
      
      Without doing this step in the DLPAR add process a LMB could be configured
      with the incorrect affinity. For a LMB that was not present at boot the
      affinity index is set to 0xffffffff, which defaults to adding the LMB to
      the first online node since the index is not a valid value. Or, the
      affinity index could contain a stale value if the LMB was present at boot
      but later DLPAR removed and is being DLPAR added back to the system.
      
      This patch adds a step in the DLPAR add flow to look up the associativity
      index for a LMB prior to adding a LMB and setting the associativity to
      0xffffffff when a LMB is removed.
      
      This patch also modifies the DLPAR add/remove flow to no longer do a single
      update of the device tree property after all of the requested DLPAR
      operations are complete and now does a property update during the add
      or remove of each LMB.
      Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      bdf5fc63
    • N
      powerpc/pseries: Refactor dlpar_add_lmb() code · 4a4bdfea
      Nathan Fontenot 提交于
      Re-factor dlpar_lmb_add() routine by moving the validation of the lmb
      flags and the acquireing of the DRC to a wrapper around the work to add
      the memory to the system. This is done to make handling of errors
      during the addition of the memory easier and to facilitate the upcoming
      addition of updating the lmb's affinity prior to adding the memory.
      Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      4a4bdfea
  12. 18 3月, 2016 1 次提交
  13. 01 3月, 2016 2 次提交
    • D
      powerpc/mm: Handle removing maybe-present bolted HPTEs · 27828f98
      David Gibson 提交于
      At the moment the hpte_removebolted callback in ppc_md returns void and
      will BUG_ON() if the hpte it's asked to remove doesn't exist in the first
      place.  This is awkward for the case of cleaning up a mapping which was
      partially made before failing.
      
      So, we add a return value to hpte_removebolted, and have it return ENOENT
      in the case that the HPTE to remove didn't exist in the first place.
      
      In the (sole) caller, we propagate errors in hpte_removebolted to its
      caller to handle.  However, we handle ENOENT specially, continuing to
      complete the unmapping over the specified range before returning the error
      to the caller.
      
      This means that htab_remove_mapping() will work sanely on a partially
      present mapping, removing any HPTEs which are present, while also returning
      ENOENT to its caller in case it's important there.
      
      There are two callers of htab_remove_mapping():
         - In remove_section_mapping() we already WARN_ON() any error return,
           which is reasonable - in this case the mapping should be fully
           present
         - In vmemmap_remove_mapping() we BUG_ON() any error.  We change that to
           just a WARN_ON() in the case of ENOENT, since failing to remove a
           mapping that wasn't there in the first place probably shouldn't be
           fatal.
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Reviewed-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      27828f98
    • A
      446957ba
  14. 17 12月, 2015 7 次提交