1. 08 11月, 2014 10 次提交
  2. 17 10月, 2014 1 次提交
  3. 16 10月, 2014 2 次提交
    • A
      2c186e05
    • M
      powerpc/pci: Fix IO space breakage after of_pci_range_to_resource() change · aeba3731
      Michael Ellerman 提交于
      Commit 0b0b0893 "of/pci: Fix the conversion of IO ranges into IO
      resources" changed the behaviour of of_pci_range_to_resource().
      
      Previously it simply populated the resource based on the arguments. Now
      it calls pci_register_io_range() and pci_address_to_pio(). These both
      have two implementations depending on whether PCI_IOBASE is defined,
      which it is not for powerpc.
      
      Further complicating matters, both routines are weak, and powerpc
      implements it's own version of one - pci_address_to_pio(). However
      powerpc's implementation depends on other initialisations which are done
      later in boot.
      
      The end result is incorrectly initialised IO space. Often we can get
      away with that, because we don't make much use of IO space. However
      virtio requires it, so we see eg:
      
        pci_bus 0000:00: root bus resource [io  0xffff] (bus address [0xffffffffffffffff-0xffffffffffffffff])
        PCI: Cannot allocate resource region 0 of device 0000:00:01.0, will remap
        virtio-pci 0000:00:01.0: can't enable device: BAR 0 [io  size 0x0020] not assigned
      
      The simplest fix for now is to just stop using of_pci_range_to_resource(),
      and open-code the original implementation, that's all we want it to do.
      
      Fixes: 0b0b0893 ("of/pci: Fix the conversion of IO ranges into IO resources")
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      aeba3731
  4. 15 10月, 2014 7 次提交
    • G
      powerpc/eeh: Don't collect logs on PE with blocked config space · c59004cc
      Gavin Shan 提交于
      When the PE's config space is marked as blocked, PCI config read
      requests always return 0xFF's. It's pointless to collect logs in
      this case.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      c59004cc
    • G
      powerpc/eeh: Block PCI config access upon frozen PE · b6541db1
      Gavin Shan 提交于
      The problem was found when I tried to inject PCI config error by
      PHB3 PAPR error injection registers into Broadcom Austin 4-ports
      NIC adapter. The frozen PE was reported successfully and EEH core
      started to recover it. However, I run into fenced PHB when dumping
      PCI config space as EEH logs. I was told that PCI config requests
      should not be progagated to the adapter until PE reset is done
      successfully. Otherise, we would run out of PHB internal credits
      and trigger PCT (PCIE Completion Timeout), which leads to the
      fenced PHB.
      
      The patch introduces another PE flag EEH_PE_CFG_RESTRICTED, which
      is set during PE initialization time if the PE includes the specific
      PCI devices that need block PCI config access until PE reset is done.
      When the PE becomes frozen for the first time, EEH_PE_CFG_BLOCKED is
      set if the PE has flag EEH_PE_CFG_RESTRICTED. Then the PCI config
      access to the PE will be dropped by platform PCI accessors until
      PE reset is done successfully. The mechanism is shared by PowerNV
      platform owned PE or userland owned ones. It's not used on pSeries
      platform yet.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      b6541db1
    • G
      powerpc/pseries: Drop config requests in EEH accessors · 3409eb4e
      Gavin Shan 提交于
      The pSeires EEH config accessors rely on rtas_{read, write}_config()
      and the condition to check if the PE's config space is blocked
      should be moved to those 2 functions so that config requests from
      kernel, userland, EEH core can be dropped to avoid recursive EEH error
      if necessary.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      3409eb4e
    • G
      powerpc/eeh: Rename flag EEH_PE_RESET to EEH_PE_CFG_BLOCKED · 8a6b3710
      Gavin Shan 提交于
      The flag EEH_PE_RESET indicates blocking config space of the PE
      during reset time. We potentially need block PE's config space
      other than reset time. So it's reasonable to replace it with
      EEH_PE_CFG_BLOCKED to indicate its usage.
      
      There are no substantial code or logic changes in this patch.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      8a6b3710
    • G
      powerpc/eeh: Fix condition for isolated state · 8315070c
      Gavin Shan 提交于
      Function eeh_pe_state_mark() could possibly have combination of
      multiple EEH PE state as its argument. The patch fixes the condition
      used to check if EEH_PE_ISOLATED is included.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      8315070c
    • A
      powerpc: Rename __get_SP() to current_stack_pointer() · acf620ec
      Anton Blanchard 提交于
      Michael points out that __get_SP() is a pretty horrible
      function name. Let's give it a better name.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      acf620ec
    • A
      powerpc: Reimplement __get_SP() as a function not a define · bfe9a2cf
      Anton Blanchard 提交于
      Li Zhong points out an issue with our current __get_SP()
      implementation. If ftrace function tracing is enabled (ie -pg
      profiling using _mcount) we spill a stack frame on 64bit all the
      time.
      
      If a function calls __get_SP() and later calls a function that is
      tail call optimised, we will pop the stack frame and the value
      returned by __get_SP() is no longer valid. An example from Li can
      be found in save_stack_trace -> save_context_stack:
      
      c0000000000432c0 <.save_stack_trace>:
      c0000000000432c0:       mflr    r0
      c0000000000432c4:       std     r0,16(r1)
      c0000000000432c8:       stdu    r1,-128(r1) <-- stack frame for _mcount
      c0000000000432cc:       std     r3,112(r1)
      c0000000000432d0:       bl      <._mcount>
      c0000000000432d4:       nop
      
      c0000000000432d8:       mr      r4,r1 <-- __get_SP()
      
      c0000000000432dc:       ld      r5,632(r13)
      c0000000000432e0:       ld      r3,112(r1)
      c0000000000432e4:       li      r6,1
      
      c0000000000432e8:       addi    r1,r1,128 <-- pop stack frame
      
      c0000000000432ec:       ld      r0,16(r1)
      c0000000000432f0:       mtlr    r0
      c0000000000432f4:       b       <.save_context_stack> <-- tail call optimized
      
      save_context_stack ends up with a stack pointer below the current
      one, and it is likely to be scribbled over.
      
      Fix this by making __get_SP() a function which returns the
      callers stack frame. Also replace inline assembly which grabs
      the stack pointer in save_stack_trace and show_stack with
      __get_SP().
      
      This also fixes an issue with perf_arch_fetch_caller_regs().
      It currently unwinds the stack once, which will skip a
      valid stack frame on a leaf function. With the __get_SP() fixes
      in this patch, we never need to unwind the stack frame to get
      to the first interesting frame.
      
      We have to export __get_SP() because perf_arch_fetch_caller_regs()
      (which is used in modules) calls it from a header file.
      Reported-by: NLi Zhong <zhong@linux.vnet.ibm.com>
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      bfe9a2cf
  5. 10 10月, 2014 2 次提交
  6. 03 10月, 2014 2 次提交
  7. 02 10月, 2014 4 次提交
  8. 01 10月, 2014 1 次提交
  9. 30 9月, 2014 11 次提交