1. 27 6月, 2017 2 次提交
    • R
      powerpc/powernv/pci: Dynamically allocate PHB diag data · 5cb1f8fd
      Russell Currey 提交于
      Diagnostic data for PHBs currently works by allocated a fixed-sized buffer.
      This is simple, but either wastes memory (though only a few kilobytes) or
      in the case of PHB4 isn't enough to fit the whole data blob.
      
      For machines that don't describe the diagnostic data size in the device
      tree, use the hardcoded buffer size as before.  For those that do, only
      allocate exactly what's needed.
      
      In the special case of P7IOC (which has two types of diag data), the larger
      should be specified in the device tree.
      Signed-off-by: NRussell Currey <ruscur@russell.cc>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      5cb1f8fd
    • R
      powerpc/powernv/pci: Reduce spam when dumping PEST · 31bbd45a
      Russell Currey 提交于
      Dumping the PE State Tables (PEST) can be highly verbose if a number of PEs
      are affected, especially in the case where the whole PHB is frozen and 512
      lines get printed.  Check for duplicates when dumping the PEST to reduce
      useless output.
      
      For example:
      
          PE[0f8] A/B: 9700002600000000 80000080d00000f8
          PE[0f9] A/B: 8000000000000000 0000000000000000
          PE[..0fe] A/B: as above
          PE[0ff] A/B: 8440002b00000000 0000000000000000
      
      instead of:
      
          PE[0f8] A/B: 9700002600000000 80000080d00000f8
          PE[0f9] A/B: 8000000000000000 0000000000000000
          PE[0fa] A/B: 8000000000000000 0000000000000000
          PE[0fb] A/B: 8000000000000000 0000000000000000
          PE[0fc] A/B: 8000000000000000 0000000000000000
          PE[0fd] A/B: 8000000000000000 0000000000000000
          PE[0fe] A/B: 8000000000000000 0000000000000000
          PE[0ff] A/B: 8440002b00000000 0000000000000000
      
      and you can imagine how much worse it can get for 512 PEs.
      Signed-off-by: NRussell Currey <ruscur@russell.cc>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      31bbd45a
  2. 19 6月, 2017 4 次提交
  3. 05 6月, 2017 1 次提交
  4. 30 5月, 2017 5 次提交
  5. 25 5月, 2017 2 次提交
  6. 04 5月, 2017 1 次提交
  7. 03 5月, 2017 3 次提交
  8. 28 4月, 2017 8 次提交
  9. 27 4月, 2017 1 次提交
  10. 26 4月, 2017 2 次提交
    • M
      powerpc/powernv: Fix oops on P9 DD1 in cause_ipi() · 45b21cfe
      Michael Ellerman 提交于
      Recently we merged the native xive support for Power9, and then separately some
      reworks for doorbell IPI support. In isolation both series were OK, but the
      merged result had a bug in one case.
      
      On P9 DD1 we use pnv_p9_dd1_cause_ipi() which tries to use doorbells, and then
      falls back to the interrupt controller. However the fallback is implemented by
      calling icp_ops->cause_ipi. But now that xive support is merged we might be
      using xive, in which case icp_ops is not initialised, it's a xics specific
      structure. This leads to an oops such as:
      
        Unable to handle kernel paging request for data at address 0x00000028
        Oops: Kernel access of bad area, sig: 11 [#1]
        NIP pnv_p9_dd1_cause_ipi+0x74/0xe0
        LR smp_muxed_ipi_message_pass+0x54/0x70
      
      To fix it, rather than using icp_ops which might be NULL, have both xics and
      xive set smp_ops->cause_ipi, and then in the powernv code we save that as
      ic_cause_ipi before overriding smp_ops->cause_ipi. For paranoia add a WARN_ON()
      to check if somehow smp_ops->cause_ipi is NULL.
      
      Fixes: b866cc21 ("powerpc: Change the doorbell IPI calling convention")
      Tested-by: NGautham R. Shenoy <ego@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      45b21cfe
    • M
      powerpc/powernv: Fix missing attr initialisation in opal_export_attrs() · 83c49190
      Michael Ellerman 提交于
      In opal_export_attrs() we dynamically allocate some bin_attributes. They're
      allocated with kmalloc() and although we initialise most of the fields, we don't
      initialise write() or mmap(), and in particular we don't initialise the lockdep
      related fields in the embedded struct attribute.
      
      This leads to a lockdep warning at boot:
      
        BUG: key c0000000f11906d8 not in .data!
        WARNING: CPU: 0 PID: 1 at ../kernel/locking/lockdep.c:3136 lockdep_init_map+0x28c/0x2a0
        ...
        Call Trace:
          lockdep_init_map+0x288/0x2a0 (unreliable)
          __kernfs_create_file+0x8c/0x170
          sysfs_add_file_mode_ns+0xc8/0x240
          __machine_initcall_powernv_opal_init+0x60c/0x684
          do_one_initcall+0x60/0x1c0
          kernel_init_freeable+0x2f4/0x3d4
          kernel_init+0x24/0x160
          ret_from_kernel_thread+0x5c/0xb0
      
      Fix it by kzalloc'ing the attr, which fixes the uninitialised write() and
      mmap(), and calling sysfs_bin_attr_init() on it to initialise the lockdep
      fields.
      
      Fixes: 11fe909d ("powerpc/powernv: Add OPAL exports attributes to sysfs")
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      83c49190
  11. 24 4月, 2017 1 次提交
    • T
      powerpc/pseries: Fix of_node_put() underflow during DLPAR remove · 68baf692
      Tyrel Datwyler 提交于
      Historically struct device_node references were tracked using a kref embedded as
      a struct field. Commit 75b57ecf ("of: Make device nodes kobjects so they
      show up in sysfs") (Mar 2014) refactored device_nodes to be kobjects such that
      the device tree could by more simply exposed to userspace using sysfs.
      
      Commit 0829f6d1 ("of: device_node kobject lifecycle fixes") (Mar 2014)
      followed up these changes to better control the kobject lifecycle and in
      particular the referecne counting via of_node_get(), of_node_put(), and
      of_node_init().
      
      A result of this second commit was that it introduced an of_node_put() call when
      a dynamic node is detached, in of_node_remove(), that removes the initial kobj
      reference created by of_node_init().
      
      Traditionally as the original dynamic device node user the pseries code had
      assumed responsibilty for releasing this final reference in its platform
      specific DLPAR detach code.
      
      This patch fixes a refcount underflow introduced by commit 0829f6d1, and
      recently exposed by the upstreaming of the recount API.
      
      Messages like the following are no longer seen in the kernel log with this
      patch following DLPAR remove operations of cpus and pci devices.
      
        rpadlpar_io: slot PHB 72 removed
        refcount_t: underflow; use-after-free.
        ------------[ cut here ]------------
        WARNING: CPU: 5 PID: 3335 at lib/refcount.c:128 refcount_sub_and_test+0xf4/0x110
      
      Fixes: 0829f6d1 ("of: device_node kobject lifecycle fixes")
      Cc: stable@vger.kernel.org # v3.15+
      Signed-off-by: NTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      [mpe: Make change log commit references more verbose]
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      68baf692
  12. 23 4月, 2017 1 次提交
    • N
      powerpc/64s: Stop using bit in HSPRG0 to test winkle · 544686ca
      Nicholas Piggin 提交于
      The POWER8 idle code has a neat trick of programming the power on engine
      to restore a low bit into HSPRG0, so idle wakeup code can test and see
      if it has been programmed this way and therefore lost all state. Restore
      time can be reduced if winkle has not been reached.
      
      However this messes with our r13 PACA pointer, and requires HSPRG0 to be
      written to. It also optimizes the slowest and most uncommon case at the
      expense of another SPR write in the common nap state wakeup.
      
      Remove this complexity and assume winkle sleeps always require a state
      restore. This speedup could be made entirely contained within the winkle
      idle code by counting per-core winkles and setting a thread bitmap when
      all have gone to winkle.
      Reviewed-by: NGautham R. Shenoy <ego@linux.vnet.ibm.com>
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      544686ca
  13. 20 4月, 2017 2 次提交
  14. 19 4月, 2017 1 次提交
  15. 13 4月, 2017 5 次提交
    • M
      powerpc/pseries: Always enable SMP when building pseries · 270e2dc9
      Michael Ellerman 提交于
      The pseries platform supports Power4 and later CPUs, all of which are
      multithreaded and/or multicore.
      
      In practice no one ever builds a SMP=n kernel for these machines. So as
      we did for powernv, have the pseries platform imply SMP=y.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      270e2dc9
    • M
      powerpc/powernv: Always enable SMP when building powernv · 40e27565
      Michael Ellerman 提交于
      The powernv platform supports Power7 and later CPUs, all of which are
      multithreaded and multicore.
      
      As such we never build a SMP=n kernel for those machines, other than
      possibly for debugging or running in a simulator.
      
      In the debugging case we can get a similar effect by booting with
      nr_cpus=1, or there's always the option of building a custom kernel with
      SMP hacked out.
      
      For running in simulators the code size reduction from building without
      SMP is not particularly important, what matters is the number of
      instructions executed. A quick test shows that a SMP=y kernel takes ~6%
      more instructions to boot to a shell. Booting with nr_cpus=1 recovers
      about half that deficit.
      
      On the flip side, keeping the SMP=n kernel building can be a pain at
      times. And although we've mostly kept it building in recent years, no
      one is regularly testing that the SMP=n kernel actually boots and works
      well on these machines.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      40e27565
    • M
      powerpc: Allow platforms to force-enable CONFIG_SMP · ebbe9d7d
      Michael Ellerman 提交于
      Of the 64-bit Book3S platforms, only powermac supports booting on an
      actual non-SMP system. The other platforms can be built with SMP
      disabled, but it doesn't make a lot of sense given the CPUs they support
      are all multicore or multithreaded.
      
      So give platforms the option of forcing SMP=y.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      ebbe9d7d
    • N
      powerpc/powernv: POWER9 support for msgsnd/doorbell IPI · 6b3edefe
      Nicholas Piggin 提交于
      POWER9 requires msgsync for receiver-side synchronization, and a DD1
      workaround restricts IPIs to core-local.
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      [mpe: Drop no longer needed asm feature macro changes]
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      6b3edefe
    • N
      powerpc: Change the doorbell IPI calling convention · b866cc21
      Nicholas Piggin 提交于
      Change the doorbell callers to know about their msgsnd addressing,
      rather than have them set a per-cpu target data tag at boot that gets
      sent to the cause_ipi functions. The data is only used for doorbell IPI
      functions, no other IPI types, so it makes sense to keep that detail
      local to doorbell.
      
      Have the platform code understand doorbell IPIs, rather than the
      interrupt controller code understand them. Platform code can look at
      capabilities it has available and decide which to use.
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      b866cc21
  16. 11 4月, 2017 1 次提交
    • G
      powerpc/powernv: Recover correct PACA on wakeup from a stop on P9 DD1 · 17ed4c8f
      Gautham R. Shenoy 提交于
      POWER9 DD1.0 hardware has a bug where the SPRs of a thread waking up
      from stop 0,1,2 with ESL=1 can endup being misplaced in the core. Thus
      the HSPRG0 of a thread waking up from can contain the paca pointer of
      its sibling.
      
      This patch implements a context recovery framework within threads of a
      core, by provisioning space in paca_struct for saving every sibling
      threads's paca pointers. Basically, we should be able to arrive at the
      right paca pointer from any of the thread's existing paca pointer.
      
      At bootup, during powernv idle-init, we save the paca address of every
      CPU in each one its siblings paca_struct in the slot corresponding to
      this CPU's index in the core.
      
      On wakeup from a stop, the thread will determine its index in the core
      from the TIR register and recover its PACA pointer by indexing into
      the correct slot in the provisioned space in the current PACA.
      
      Furthermore, ensure that the NVGPRs are restored from the stack on the
      way out by setting the NAPSTATELOST in paca.
      
      [Changelog written with inputs from svaidy@linux.vnet.ibm.com]
      Signed-off-by: NGautham R. Shenoy <ego@linux.vnet.ibm.com>
      Reviewed-by: NNicholas Piggin <npiggin@gmail.com>
      [mpe: Call it a bug]
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      17ed4c8f