1. 13 Oct, 2014 1 commit
    • Mahesh Salgaonkar's avatar
      powerpc/powernv: Fallback to old HMI handling behavior for old firmware · 6507955c
      Mahesh Salgaonkar authored
      Recently we moved HMI handling into Linux kernel instead of taking
      HMI directly in OPAL. This new change is dependent on new OPAL call
      for HMI recovery which was introduced in newer firmware. While this new
      change works fine with latest OPAL firmware, we broke the HMI handling
      if we run newer kernel on old OPAL firmware that results in system hang.
      
      This patch fixes this issue by falling back to old HMI behavior on older
      OPAL firmware.
      
      This patch introduces a check for opal token OPAL_HANDLE_HMI to see
      if we are running on newer firmware or old firmware. On newer firmware
      this check would return OPAL_TOKEN_PRESENT, otherwise we are running on
      old firmware and fallback to old HMI behavior.
      
      Old firmware: POWER8 System Firmware Release as of today <= SV810_087
      Action: Let OPAL handle HMIs
      
      Newer firmware: in development/yet to be released.
      Action: Let Linux host handle HMIs.
      
      This patch depends on opal check token patch posted at ppc-devel
      https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-August/120224.htmlSigned-off-by: default avatarMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      [mpe: Minor comment and printk rewording]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      6507955c
  2. 10 Oct, 2014 2 commits
    • Mahesh Salgaonkar's avatar
      powerpc/book3s: Don't clear MSR_RI in hmi handler. · c675c7db
      Mahesh Salgaonkar authored
      In HMI interrupt handler we don't touch SRR0/SRR1, instead we touch
      HSRR0/HSRR1. Hence we don't need to clear MSR_RI bit.
      Signed-off-by: default avatarMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      c675c7db
    • Romeo Cane's avatar
      powerpc: Fix sys_call_table declaration to enable syscall tracing · 1028ccf5
      Romeo Cane authored
      Declaring sys_call_table as a pointer causes the compiler to generate
      the wrong lookup code in arch_syscall_addr().
      
           <arch_syscall_addr>:
              lis     r9,-16384
              rlwinm  r3,r3,2,0,29
        -     lwz     r11,30640(r9)
        -     lwzx    r3,r11,r3
        +     addi    r9,r9,30640
        +     lwzx    r3,r9,r3
              blr
      
      The actual sys_call_table symbol, declared in assembler, is an
      array. If we lie about that to the compiler we get the wrong code
      generated, as above.
      
      This definition seems only to be used by the syscall tracing code in
      kernel/trace/trace_syscalls.c. With this patch I can successfully use
      the syscall tracepoints:
      
        bash-3815  [002] ....   333.239082: sys_write -> 0x2
        bash-3815  [002] ....   333.239087: sys_dup2(oldfd: a, newfd: 1)
        bash-3815  [002] ....   333.239088: sys_dup2 -> 0x1
        bash-3815  [002] ....   333.239092: sys_fcntl(fd: a, cmd: 1, arg: 0)
        bash-3815  [002] ....   333.239093: sys_fcntl -> 0x1
        bash-3815  [002] ....   333.239094: sys_close(fd: a)
        bash-3815  [002] ....   333.239094: sys_close -> 0x0
      Signed-off-by: default avatarRomeo Cane <romeo.cane.ext@coriant.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      1028ccf5
  3. 09 Oct, 2014 1 commit
  4. 08 Oct, 2014 16 commits
  5. 07 Oct, 2014 5 commits
  6. 03 Oct, 2014 6 commits
  7. 02 Oct, 2014 8 commits
  8. 01 Oct, 2014 1 commit