1. 13 Sep, 2019 38 commits
  2. 11 Sep, 2019 2 commits
    • Greg Kurz's avatar
      powerpc/xive: Fix bogus error code returned by OPAL · 6ccb4ac2
      Greg Kurz authored
      There's a bug in skiboot that causes the OPAL_XIVE_ALLOCATE_IRQ call
      to return the 32-bit value 0xffffffff when OPAL has run out of IRQs.
      Unfortunatelty, OPAL return values are signed 64-bit entities and
      errors are supposed to be negative. If that happens, the linux code
      confusingly treats 0xffffffff as a valid IRQ number and panics at some
      point.
      
      A fix was recently merged in skiboot:
      
      e97391ae2bb5 ("xive: fix return value of opal_xive_allocate_irq()")
      
      but we need a workaround anyway to support older skiboots already
      in the field.
      
      Internally convert 0xffffffff to OPAL_RESOURCE which is the usual error
      returned upon resource exhaustion.
      
      Cc: stable@vger.kernel.org # v4.12+
      Signed-off-by: default avatarGreg Kurz <groug@kaod.org>
      Reviewed-by: default avatarCédric Le Goater <clg@kaod.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/156821713818.1985334.14123187368108582810.stgit@bahia.lan
      6ccb4ac2
    • Nathan Lynch's avatar
      powerpc/pseries: correctly track irq state in default idle · 92c94dfb
      Nathan Lynch authored
      prep_irq_for_idle() is intended to be called before entering
      H_CEDE (and it is used by the pseries cpuidle driver). However the
      default pseries idle routine does not call it, leading to mismanaged
      lazy irq state when the cpuidle driver isn't in use. Manifestations of
      this include:
      
      * Dropped IPIs in the time immediately after a cpu comes
        online (before it has installed the cpuidle handler), making the
        online operation block indefinitely waiting for the new cpu to
        respond.
      
      * Hitting this WARN_ON in arch_local_irq_restore():
      	/*
      	 * We should already be hard disabled here. We had bugs
      	 * where that wasn't the case so let's dbl check it and
      	 * warn if we are wrong. Only do that when IRQ tracing
      	 * is enabled as mfmsr() can be costly.
      	 */
      	if (WARN_ON_ONCE(mfmsr() & MSR_EE))
      		__hard_irq_disable();
      
      Call prep_irq_for_idle() from pseries_lpar_idle() and honor its
      result.
      
      Fixes: 363edbe2 ("powerpc: Default arch idle could cede processor on pseries")
      Signed-off-by: default avatarNathan Lynch <nathanl@linux.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20190910225244.25056-1-nathanl@linux.ibm.com
      92c94dfb