1. 12 10月, 2019 1 次提交
  2. 26 7月, 2019 1 次提交
  3. 21 7月, 2019 1 次提交
    • H
      irqchip/gic-v3-its: Fix command queue pointer comparison bug · ff232a47
      Heyi Guo 提交于
      [ Upstream commit a050fa5476d418fc16b25abe168b3d38ba11e13c ]
      
      When we run several VMs with PCI passthrough and GICv4 enabled, not
      pinning vCPUs, we will occasionally see below warnings in dmesg:
      
      ITS queue timeout (65440 65504 480)
      ITS cmd its_build_vmovp_cmd failed
      
      The reason for the above issue is that in BUILD_SINGLE_CMD_FUNC:
      1. Post the write command.
      2. Release the lock.
      3. Start to read GITS_CREADR to get the reader pointer.
      4. Compare the reader pointer to the target pointer.
      5. If reader pointer does not reach the target, sleep 1us and continue
      to try.
      
      If we have several processors running the above concurrently, other
      CPUs will post write commands while the 1st CPU is waiting the
      completion. So we may have below issue:
      
      phase 1:
      ---rd_idx-----from_idx-----to_idx--0---------
      
      wait 1us:
      
      phase 2:
      --------------from_idx-----to_idx--0-rd_idx--
      
      That is the rd_idx may fly ahead of to_idx, and if in case to_idx is
      near the wrap point, rd_idx will wrap around. So the below condition
      will not be met even after 1s:
      
      if (from_idx < to_idx && rd_idx >= to_idx)
      
      There is another theoretical issue. For a slow and busy ITS, the
      initial rd_idx may fall behind from_idx a lot, just as below:
      
      ---rd_idx---0--from_idx-----to_idx-----------
      
      This will cause the wait function exit too early.
      
      Actually, it does not make much sense to use from_idx to judge if
      to_idx is wrapped, but we need a initial rd_idx when lock is still
      acquired, and it can be used to judge whether to_idx is wrapped and
      the current rd_idx is wrapped.
      
      We switch to a method of calculating the delta of two adjacent reads
      and accumulating it to get the sum, so that we can get the real rd_idx
      from the wrapped value even when the queue is almost full.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Signed-off-by: NHeyi Guo <guoheyi@huawei.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ff232a47
  4. 03 7月, 2019 1 次提交
    • P
      irqchip/mips-gic: Use the correct local interrupt map registers · c22cea5a
      Paul Burton 提交于
      commit 6d4d367d0e9ffab4d64a3436256a6a052dc1195d upstream.
      
      The MIPS GIC contains a block of registers used to map local interrupts
      to a particular CPU interrupt pin. Since these registers are found at a
      consecutive range of addresses we access them using an index, via the
      (read|write)_gic_v[lo]_map accessor functions. We currently use values
      from enum mips_gic_local_interrupt as those indices.
      
      Unfortunately whilst enum mips_gic_local_interrupt provides the correct
      offsets for bits in the pending & mask registers, the ordering of the
      map registers is subtly different... Compared with the ordering of
      pending & mask bits, the map registers move the FDC from the end of the
      list to index 3 after the timer interrupt. As a result the performance
      counter & software interrupts are therefore at indices 4-6 rather than
      indices 3-5.
      
      Notably this causes problems with performance counter interrupts being
      incorrectly mapped on some systems, and presumably will also cause
      problems for FDC interrupts.
      
      Introduce a function to map from enum mips_gic_local_interrupt to the
      index of the corresponding map register, and use it to ensure we access
      the map registers for the correct interrupts.
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Fixes: a0dc5cb5 ("irqchip: mips-gic: Simplify gic_local_irq_domain_map()")
      Fixes: da61fcf9 ("irqchip: mips-gic: Use irq_cpu_online to (un)mask all-VP(E) IRQs")
      Reported-and-tested-by: NArcher Yan <ayan@wavecomp.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: stable@vger.kernel.org # v4.14+
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c22cea5a
  5. 11 6月, 2019 1 次提交
    • G
      Revert "MIPS: perf: ath79: Fix perfcount IRQ assignment" · 221c44d2
      Greg Kroah-Hartman 提交于
      This reverts commit ca864881 which is
      commit a1e8783db8e0d58891681bc1e6d9ada66eae8e20 upstream.
      
      Petr writes:
      	Karl has reported to me today, that he's experiencing weird
      	reboot hang on his devices with 4.9.180 kernel and that he has
      	bisected it down to my backported patch.
      
      	I would like to kindly ask you for removal of this patch.  This
      	patch should be reverted from all stable kernels up to 5.1,
      	because perf counters were not broken on those kernels, and this
      	patch won't work on the ath79 legacy IRQ code anyway, it needs
      	new irqchip driver which was enabled on ath79 with commit
      	51fa4f8912c0 ("MIPS: ath79: drop legacy IRQ code").
      Reported-by: NPetr Štetiar <ynezz@true.cz>
      Cc: Kevin 'ldir' Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
      Cc: John Crispin <john@phrozen.org>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: linux-mips@vger.kernel.org
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Sasha Levin <sashal@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      221c44d2
  6. 17 5月, 2019 1 次提交
    • P
      MIPS: perf: ath79: Fix perfcount IRQ assignment · ca864881
      Petr Štetiar 提交于
      [ Upstream commit a1e8783db8e0d58891681bc1e6d9ada66eae8e20 ]
      
      Currently it's not possible to use perf on ath79 due to genirq flags
      mismatch happening on static virtual IRQ 13 which is used for
      performance counters hardware IRQ 5.
      
      On TP-Link Archer C7v5:
      
                 CPU0
        2:          0      MIPS   2  ath9k
        4:        318      MIPS   4  19000000.eth
        7:      55034      MIPS   7  timer
        8:       1236      MISC   3  ttyS0
       12:          0      INTC   1  ehci_hcd:usb1
       13:          0  gpio-ath79   2  keys
       14:          0  gpio-ath79   5  keys
       15:         31  AR724X PCI    1  ath10k_pci
      
       $ perf top
       genirq: Flags mismatch irq 13. 00014c83 (mips_perf_pmu) vs. 00002003 (keys)
      
      On TP-Link Archer C7v4:
      
               CPU0
        4:          0      MIPS   4  19000000.eth
        5:       7135      MIPS   5  1a000000.eth
        7:      98379      MIPS   7  timer
        8:         30      MISC   3  ttyS0
       12:      90028      INTC   0  ath9k
       13:       5520      INTC   1  ehci_hcd:usb1
       14:       4623      INTC   2  ehci_hcd:usb2
       15:      32844  AR724X PCI    1  ath10k_pci
       16:          0  gpio-ath79  16  keys
       23:          0  gpio-ath79  23  keys
      
       $ perf top
       genirq: Flags mismatch irq 13. 00014c80 (mips_perf_pmu) vs. 00000080 (ehci_hcd:usb1)
      
      This problem is happening, because currently statically assigned virtual
      IRQ 13 for performance counters is not claimed during the initialization
      of MIPS PMU during the bootup, so the IRQ subsystem doesn't know, that
      this interrupt isn't available for further use.
      
      So this patch fixes the issue by simply booking hardware IRQ 5 for MIPS PMU.
      Tested-by: NKevin 'ldir' Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
      Signed-off-by: NPetr Štetiar <ynezz@true.cz>
      Acked-by: NJohn Crispin <john@phrozen.org>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: linux-mips@vger.kernel.org
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ca864881
  7. 20 4月, 2019 2 次提交
  8. 27 3月, 2019 1 次提交
  9. 24 3月, 2019 2 次提交
  10. 14 3月, 2019 3 次提交
    • L
      irqchip/mmp: Only touch the PJ4 IRQ & FIQ bits on enable/disable · 1bf79102
      Lubomir Rintel 提交于
      [ Upstream commit 2380a22b60ce6f995eac806e69c66e397b59d045 ]
      
      Resetting bit 4 disables the interrupt delivery to the "secure
      processor" core. This breaks the keyboard on a OLPC XO 1.75 laptop,
      where the firmware running on the "secure processor" bit-bangs the
      PS/2 protocol over the GPIO lines.
      
      It is not clear what the rest of the bits are and Marvell was unhelpful
      when asked for documentation. Aside from the SP bit, there are probably
      priority bits.
      
      Leaving the unknown bits as the firmware set them up seems to be a wiser
      course of action compared to just turning them off.
      Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      [maz: fixed-up subject and commit message]
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1bf79102
    • M
      irqchip/gic-v3-its: Gracefully fail on LPI exhaustion · 423869f8
      Marc Zyngier 提交于
      [ Upstream commit 45725e0fc3e7fe52fedb94f59806ec50e9618682 ]
      
      In the unlikely event that we cannot find any available LPI in the
      system, we should gracefully return an error instead of carrying
      on with no LPI allocated at all.
      
      Fixes: 38dd7c49 ("irqchip/gic-v3-its: Drop chunk allocation compatibility")
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      423869f8
    • H
      irqchip/gic-v4: Fix occasional VLPI drop · dc81cfaf
      Heyi Guo 提交于
      [ Upstream commit 6479450f72c1391c03f08affe0d0110f41ae7ca0 ]
      
      1. In current implementation, every VLPI will temporarily be mapped to
      the first CPU in system (normally CPU0) and then moved to the real
      scheduled CPU later.
      
      2. So there is a time window and a VLPI may be sent to CPU0 instead of
      the real scheduled vCPU, in a multi-CPU virtual machine.
      
      3. However, CPU0 may have not been scheduled as a virtual CPU after
      system boots up, so the value of its GICR_VPROPBASER is unknown at
      that moment.
      
      4. If the INTID of VLPI is larger than 2^(GICR_VPROPBASER.IDbits+1),
      while IDbits is also in unknown state, GIC will behave as if the VLPI
      is out of range and simply drop it, which results in interrupt missing
      in Guest.
      
      As no code will clear GICR_VPROPBASER at runtime, we can safely
      initialize the IDbits field at boot time for each CPU to get rid of
      this issue.
      
      We also clear Valid bit of GICR_VPENDBASER in case any ancient
      programming gets left in and causes memory corrupting. A new function
      its_clear_vpend_valid() is added to reuse the code in
      its_vpe_deschedule().
      
      Fixes: e643d803 ("irqchip/gic-v3-its: Add VPE scheduling")
      Signed-off-by: NHeyi Guo <guoheyi@huawei.com>
      Signed-off-by: NHeyi Guo <heyi.guo@linaro.org>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      dc81cfaf
  11. 06 3月, 2019 1 次提交
  12. 13 2月, 2019 1 次提交
    • M
      irqchip/gic-v3-its: Plug allocation race for devices sharing a DevID · 8459f1d6
      Marc Zyngier 提交于
      commit 9791ec7df0e7b4d80706ccea8f24b6542f6059e9 upstream.
      
      On systems or VMs where multiple devices share a single DevID
      (because they sit behind a PCI bridge, or because the HW is
      broken in funky ways), we reuse the save its_device structure
      in order to reflect this.
      
      It turns out that there is a distinct lack of locking when looking
      up the its_device, and two device being probed concurrently can result
      in double allocations. That's obviously not nice.
      
      A solution for this is to have a per-ITS mutex that serializes device
      allocation.
      
      A similar issue exists on the freeing side, which can run concurrently
      with the allocation. On top of now taking the appropriate lock, we
      also make sure that a shared device is never freed, as we have no way
      to currently track the life cycle of such object.
      Reported-by: NZheng Xiang <zhengxiang9@huawei.com>
      Tested-by: NZheng Xiang <zhengxiang9@huawei.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8459f1d6
  13. 31 1月, 2019 1 次提交
  14. 14 11月, 2018 1 次提交
  15. 07 9月, 2018 1 次提交
  16. 22 8月, 2018 1 次提交
  17. 21 8月, 2018 1 次提交
  18. 20 8月, 2018 2 次提交
  19. 13 8月, 2018 4 次提交
  20. 06 8月, 2018 1 次提交
  21. 03 8月, 2018 2 次提交
    • P
      genirq/irqchip: Remove MULTI_IRQ_HANDLER as it's now obselete · 4f7799d9
      Palmer Dabbelt 提交于
      Now that every user of MULTI_IRQ_HANDLER has been convereted over to use
      GENERIC_IRQ_MULTI_HANDLER remove the references to MULTI_IRQ_HANDLER.
      Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: linux@armlinux.org.uk
      Cc: catalin.marinas@arm.com
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: jonas@southpole.se
      Cc: stefan.kristiansson@saunalahti.fi
      Cc: shorne@gmail.com
      Cc: jason@lakedaemon.net
      Cc: marc.zyngier@arm.com
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: nicolas.pitre@linaro.org
      Cc: vladimir.murzin@arm.com
      Cc: keescook@chromium.org
      Cc: jinb.park7@gmail.com
      Cc: yamada.masahiro@socionext.com
      Cc: alexandre.belloni@bootlin.com
      Cc: pombredanne@nexb.com
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: kstewart@linuxfoundation.org
      Cc: jhogan@kernel.org
      Cc: mark.rutland@arm.com
      Cc: ard.biesheuvel@linaro.org
      Cc: james.morse@arm.com
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: openrisc@lists.librecores.org
      Link: https://lkml.kernel.org/r/20180622170126.6308-6-palmer@sifive.com
      4f7799d9
    • P
      irqchip: Port the ARM IRQ drivers to GENERIC_IRQ_MULTI_HANDLER · 08fb550c
      Palmer Dabbelt 提交于
      GENERIC_IRQ_MULTI_HANDLER is incompatible with MULTI_IRQ_HANDLER because
      they define the same symbols.  Multiple generic irqchip drivers select
      MULTI_IRQ_HANDLER, which is now defined on all architectures that
      provide set_handle_irq().
      
      To solve this select GENERIC_IRQ_MULTI_HANDLER for all drivers that used to
      select MULTI_IRQ_HANDLER, but only when MULTI_IRQ_HANDLER doesn't exist.
      
      After that every architecture can be converted over from MULTI_IRQ_HANDLER
      to GENERIC_IRQ_MULTI_HANDLER before removing the extra MULTI_IRQ_HANDLER
      scaffolding.
      Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: linux@armlinux.org.uk
      Cc: catalin.marinas@arm.com
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: jonas@southpole.se
      Cc: stefan.kristiansson@saunalahti.fi
      Cc: shorne@gmail.com
      Cc: jason@lakedaemon.net
      Cc: marc.zyngier@arm.com
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: nicolas.pitre@linaro.org
      Cc: vladimir.murzin@arm.com
      Cc: keescook@chromium.org
      Cc: jinb.park7@gmail.com
      Cc: yamada.masahiro@socionext.com
      Cc: alexandre.belloni@bootlin.com
      Cc: pombredanne@nexb.com
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: kstewart@linuxfoundation.org
      Cc: jhogan@kernel.org
      Cc: mark.rutland@arm.com
      Cc: ard.biesheuvel@linaro.org
      Cc: james.morse@arm.com
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: openrisc@lists.librecores.org
      Cc: Shea Levy <shea@shealevy.com>
      Link: https://lkml.kernel.org/r/20180622170126.6308-2-palmer@sifive.com
      08fb550c
  22. 27 7月, 2018 1 次提交
  23. 19 7月, 2018 2 次提交
  24. 16 7月, 2018 6 次提交
    • M
      irqchip/gic-v3-its: Honor hypervisor enforced LPI range · 12b2905a
      Marc Zyngier 提交于
      A recent extension to the GIC architecture allows a hypervisor to
      arbitrarily reduce the number of LPIs available to a guest, no
      matter what the GIC says about the valid range of IntIDs.
      
      Let's factor in this information when computing the number of
      available LPIs
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      12b2905a
    • M
      irqchip/gic-v3: Expose GICD_TYPER in the rdist structure · a4f9edb2
      Marc Zyngier 提交于
      Instead of exposing the GIC distributor IntID field in the rdist
      structure that is passed to the ITS, let's replace it with a
      copy of the whole GICD_TYPER register. We are going to need
      some of this information at a later time.
      
      No functionnal change.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      a4f9edb2
    • M
      irqchip/gic-v3-its: Drop chunk allocation compatibility · 38dd7c49
      Marc Zyngier 提交于
      The chunk allocation system is now officially dead, so let's
      remove it.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      38dd7c49
    • M
      irqchip/gic-v3-its: Move minimum LPI requirements to individual busses · 147c8f37
      Marc Zyngier 提交于
      At the moment, the core ITS driver imposes the allocation to be
      in chunks of 32. As we want to relax this on a per bus basis, let's
      move the the the allocation constraints to each bus.
      
      No functionnal change.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      147c8f37
    • M
      irqchip/gic-v3-its: Use full range of LPIs · fe8e9350
      Marc Zyngier 提交于
      As we used to represent the LPI range using a bitmap, we were reducing
      the number of LPIs to at most 64k in order to preserve memory.
      
      With our new allocator, there is no such need, as dealing with 2^16
      or 2^32 LPIs takes the same amount of memory.
      
      So let's use the number of IntID bits reported by the GIC instead of
      an arbitrary limit.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      fe8e9350
    • M
      irqchip/gic-v3-its: Refactor LPI allocator · 880cb3cd
      Marc Zyngier 提交于
      Our current LPI allocator relies on a bitmap, each bit representing
      a chunk of 32 LPIs, meaning that each device gets allocated LPIs
      in multiple of 32. It served us well so far, but new use cases now
      require much more finer grain allocations, down the the individual
      LPI.
      
      Given the size of the IntID space (up to 32bit), it isn't practical
      to continue using a bitmap, so let's use a different data structure
      altogether.
      
      We switch to a list, where each element represent a contiguous range
      of LPIs. On allocation, we simply grab the first group big enough to
      satisfy the allocation, and substract what we need from it. If the
      group becomes empty, we just remove it. On freeing interrupts, we
      insert a new group of interrupt in the list, sort it and fuse the
      adjacent groups.
      
      This makes freeing interrupt much more expensive than allocating
      them (an unusual behaviour), but that's fine as long as we consider
      that freeing interrupts is an extremely rare event.
      
      We still allocate interrupts in blocks of 32 for the time being,
      but subsequent patches will relax this.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      880cb3cd
  25. 22 6月, 2018 1 次提交