1. 07 8月, 2018 35 次提交
  2. 03 8月, 2018 4 次提交
    • R
      powerpc/powernv: Fix concurrency issue with npu->mmio_atsd_usage · 9eab9901
      Reza Arbab 提交于
      We've encountered a performance issue when multiple processors stress
      {get,put}_mmio_atsd_reg(). These functions contend for
      mmio_atsd_usage, an unsigned long used as a bitmask.
      
      The accesses to mmio_atsd_usage are done using test_and_set_bit_lock()
      and clear_bit_unlock(). As implemented, both of these will require
      a (successful) stwcx to that same cache line.
      
      What we end up with is thread A, attempting to unlock, being slowed by
      other threads repeatedly attempting to lock. A's stwcx instructions
      fail and retry because the memory reservation is lost every time a
      different thread beats it to the punch.
      
      There may be a long-term way to fix this at a larger scale, but for
      now resolve the immediate problem by gating our call to
      test_and_set_bit_lock() with one to test_bit(), which is obviously
      implemented without using a store.
      
      Fixes: 1ab66d1f ("powerpc/powernv: Introduce address translation services for Nvlink2")
      Signed-off-by: NReza Arbab <arbab@linux.ibm.com>
      Acked-by: NAlistair Popple <alistair@popple.id.au>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      9eab9901
    • C
      powerpc: Do not redefine NEED_DMA_MAP_STATE · 06832fc0
      Christoph Hellwig 提交于
      kernel/dma/Kconfig already defines NEED_DMA_MAP_STATE, just select it
      from CONFIG_PPC using the same condition as an if guard.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      [mpe: Move it under PPC]
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      06832fc0
    • G
      powerpc/4xx: Fix error return path in ppc4xx_msi_probe() · 6e0495c2
      Guenter Roeck 提交于
      An arbitrary error in ppc4xx_msi_probe() quite likely results in a
      crash similar to the following, seen after dma_alloc_coherent()
      returned an error.
      
        Unable to handle kernel paging request for data at address 0x00000000
        Faulting instruction address: 0xc001bff0
        Oops: Kernel access of bad area, sig: 11 [#1]
        BE Canyonlands
        Modules linked in:
        CPU: 0 PID: 1 Comm: swapper Tainted: G        W
        4.18.0-rc6-00010-gff33d1030a6c #1
        NIP:  c001bff0 LR: c001c418 CTR: c01faa7c
        REGS: cf82db40 TRAP: 0300   Tainted: G        W
        (4.18.0-rc6-00010-gff33d1030a6c)
        MSR:  00029000 <CE,EE,ME>  CR: 28002024  XER: 00000000
        DEAR: 00000000 ESR: 00000000
        GPR00: c001c418 cf82dbf0 cf828000 cf8de400 00000000 00000000 000000c4 000000c4
        GPR08: c0481ea4 00000000 00000000 000000c4 22002024 00000000 c00025e8 00000000
        GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 c0492380 0000004a
        GPR24: 00029000 0000000c 00000000 cf8de410 c0494d60 c0494d60 cf8bebc0 00000001
        NIP [c001bff0] ppc4xx_of_msi_remove+0x48/0xa0
        LR [c001c418] ppc4xx_msi_probe+0x294/0x3b8
        Call Trace:
        [cf82dbf0] [00029000] 0x29000 (unreliable)
        [cf82dc10] [c001c418] ppc4xx_msi_probe+0x294/0x3b8
        [cf82dc70] [c0209fbc] platform_drv_probe+0x40/0x9c
        [cf82dc90] [c0208240] driver_probe_device+0x2a8/0x350
        [cf82dcc0] [c0206204] bus_for_each_drv+0x60/0xac
        [cf82dcf0] [c0207e88] __device_attach+0xe8/0x160
        [cf82dd20] [c02071e0] bus_probe_device+0xa0/0xbc
        [cf82dd40] [c02050c8] device_add+0x404/0x5c4
        [cf82dd90] [c0288978] of_platform_device_create_pdata+0x88/0xd8
        [cf82ddb0] [c0288b70] of_platform_bus_create+0x134/0x220
        [cf82de10] [c0288bcc] of_platform_bus_create+0x190/0x220
        [cf82de70] [c0288cf4] of_platform_bus_probe+0x98/0xec
        [cf82de90] [c0449650] __machine_initcall_canyonlands_ppc460ex_device_probe+0x38/0x54
        [cf82dea0] [c0002404] do_one_initcall+0x40/0x188
        [cf82df00] [c043daec] kernel_init_freeable+0x130/0x1d0
        [cf82df30] [c0002600] kernel_init+0x18/0x104
        [cf82df40] [c000c23c] ret_from_kernel_thread+0x14/0x1c
        Instruction dump:
        90010024 813d0024 2f890000 83c30058 41bd0014 48000038 813d0024 7f89f800
        409d002c 813e000c 57ea103a 3bff0001 <7c69502e> 2f830000 419effe0 4803b26d
        ---[ end trace 8cf551077ecfc42a ]---
      
      Fix it up. Specifically,
      
      - Return valid error codes from ppc4xx_setup_pcieh_hw(), have it clean
        up after itself, and only access hardware after all possible error
        conditions have been handled.
      - Use devm_kzalloc() instead of kzalloc() in ppc4xx_msi_probe()
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      6e0495c2
    • N
      powernv/cpuidle: Fix idle states all being marked invalid · 3127692d
      Nicholas Piggin 提交于
      Commit 9c7b185a ("powernv/cpuidle: Parse dt idle properties into
      global structure") parses dt idle states into structs, but never marks
      them valid. This results in all idle states being lost.
      
      Fixes: 9c7b185a ("powernv/cpuidle: Parse dt idle properties into global structure")
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Acked-by: NAkshay Adiga <akshay.adiga@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      3127692d
  3. 31 7月, 2018 1 次提交
    • S
      powerpc/pseries: fix EEH recovery of some IOV devices · b87b9cf4
      Sam Bobroff 提交于
      EEH recovery currently fails on pSeries for some IOV capable PCI
      devices, if CONFIG_PCI_IOV is on and the hypervisor doesn't provide
      certain device tree properties for the device. (Found on an IOV
      capable device using the ipr driver.)
      
      Recovery fails in pci_enable_resources() at the check on r->parent,
      because r->flags is set and r->parent is not.  This state is due to
      sriov_init() setting the start, end and flags members of the IOV BARs
      but the parent not being set later in
      pseries_pci_fixup_iov_resources(), because the
      "ibm,open-sriov-vf-bar-info" property is missing.
      
      Correct this by zeroing the resource flags for IOV BARs when they
      can't be configured (this is the same method used by sriov_init() and
      __pci_read_base()).
      
      VFs cleared this way can't be enabled later, because that requires
      another device tree property, "ibm,number-of-configurable-vfs" as well
      as support for the RTAS function "ibm_map_pes". These are all part of
      hypervisor support for IOV and it seems unlikely that a hypervisor
      would ever partially, but not fully, support it. (None are currently
      provided by QEMU/KVM.)
      Signed-off-by: NSam Bobroff <sbobroff@linux.ibm.com>
      Reviewed-by: NBryant G. Ly <bryantly@linux.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      b87b9cf4