1. 13 10月, 2014 1 次提交
    • M
      powerpc/powernv: Fallback to old HMI handling behavior for old firmware · 6507955c
      Mahesh Salgaonkar 提交于
      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: NMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      [mpe: Minor comment and printk rewording]
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      6507955c
  2. 10 10月, 2014 2 次提交
    • M
      powerpc/book3s: Don't clear MSR_RI in hmi handler. · c675c7db
      Mahesh Salgaonkar 提交于
      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: NMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      c675c7db
    • R
      powerpc: Fix sys_call_table declaration to enable syscall tracing · 1028ccf5
      Romeo Cane 提交于
      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: NRomeo Cane <romeo.cane.ext@coriant.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      1028ccf5
  3. 09 10月, 2014 1 次提交
  4. 08 10月, 2014 16 次提交
  5. 07 10月, 2014 5 次提交
  6. 04 10月, 2014 1 次提交
  7. 03 10月, 2014 5 次提交
  8. 02 10月, 2014 8 次提交
  9. 01 10月, 2014 1 次提交