1. 02 5月, 2016 2 次提交
    • M
      irqchip/gic-v3: Add support for partitioned PPIs · e3825ba1
      Marc Zyngier 提交于
      Plug the partitioning layer into the GICv3 PPI code, parsing the
      DT and building the partition affinities and providing the generic
      code with partition data and callbacks.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: devicetree@vger.kernel.org
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Rob Herring <robh+dt@kernel.org>
      Link: http://lkml.kernel.org/r/1460365075-7316-5-git-send-email-marc.zyngier@arm.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      e3825ba1
    • M
      irqchip: Add per-cpu interrupt partitioning library · 9e2c986c
      Marc Zyngier 提交于
      We've unfortunately started seeing a situation where percpu interrupts
      are partitioned in the system: one arbitrary set of CPUs has an
      interrupt connected to a type of device, while another disjoint
      set of CPUs has the same interrupt connected to another type of device.
      
      This makes it impossible to have a device driver requesting this interrupt
      using the current percpu-interrupt abstraction, as the same interrupt number
      is now potentially claimed by at least two drivers, and we forbid interrupt
      sharing on per-cpu interrupt.
      
      A solution to this is to turn things upside down. Let's assume that our
      system describes all the possible partitions for a given interrupt, and
      give each of them a unique identifier. It is then possible to create
      a namespace where the affinity identifier itself is a form of interrupt
      number. At this point, it becomes easy to implement a set of partitions
      as a cascaded irqchip, each affinity identifier being the HW irq.
      
      This allows us to keep a number of nice properties:
      - Each partition results in a separate percpu-interrupt (with a restrictied
        affinity), which keeps drivers happy.
      - Because the underlying interrupt is still per-cpu, the overhead of
        the indirection can be kept pretty minimal.
      - The core code can ignore most of that crap.
      
      For that purpose, we implement a small library that deals with some of
      the boilerplate code, relying on platform-specific drivers to provide
      a description of the affinity sets and a set of callbacks.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: devicetree@vger.kernel.org
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Rob Herring <robh+dt@kernel.org>
      Link: http://lkml.kernel.org/r/1460365075-7316-4-git-send-email-marc.zyngier@arm.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      9e2c986c
  2. 22 4月, 2016 1 次提交
    • P
      irqchip/mips-gic: Don't overrun pcpu_masks array · 91951f98
      Paul Burton 提交于
      Commit 2a078705 ("irqchip/mips-gic: Use gic_vpes instead of
      NR_CPUS") & commit 78930f09 ("irqchip/mips-gic: Clear percpu_masks
      correctly when mapping") both introduce code which accesses gic_vpes
      entries in the pcpu_masks array. However, this array has length NR_CPUS.
      If NR_CPUS is less than gic_vpes (ie. the kernel supports use of less
      CPUs than are present in the system) then we overrun the array, clobber
      some other data & generally die pretty promptly.
      
      Most notably this affects uniprocessor kernels running on any multicore
      or multithreaded Malta with a GIC (ie. the vast majority of real Malta
      boards).
      
      Fix this by only accessing up to min(gic_vpes, NR_CPUS) entries in the
      pcpu_masks array, preventing the array overrun.
      
      Fixes: 2a078705 ("irqchip/mips-gic: Use gic_vpes instead of NR_CPUS")
      Fixes: 78930f09 ("irqchip/mips-gic: Clear percpu_masks correctly when mapping")
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Link: http://lkml.kernel.org/r/1461234714-9975-1-git-send-email-paul.burton@imgtec.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      91951f98
  3. 23 3月, 2016 1 次提交
  4. 21 3月, 2016 2 次提交
  5. 11 3月, 2016 1 次提交
  6. 10 3月, 2016 2 次提交
  7. 09 3月, 2016 8 次提交
  8. 25 2月, 2016 6 次提交
  9. 19 2月, 2016 2 次提交
  10. 18 2月, 2016 6 次提交
  11. 17 2月, 2016 8 次提交
  12. 12 2月, 2016 1 次提交
    • A
      irqchip/gic-v3-its: Fix double ICC_EOIR write for LPI in EOImode==1 · 004fa08d
      Ashok Kumar 提交于
      When the GIC is using EOImode==1, the EOI is done immediately,
      leaving the deactivation to be performed when the EOI was
      previously done.
      
      Unfortunately, the ITS is not aware of the EOImode at all, and
      blindly EOIs the interrupt again. On most systems, this is ignored
      (despite being a programming error), but some others do raise a
      SError exception as there is no priority drop to perform for this
      interrupt.
      
      The fix is to stop trying to be clever, and always call into the
      underlying GIC to perform the right access, irrespective of the
      more we're in.
      
      [Marc: Reworked commit message]
      
      Fixes: 0b996fd3 ("irqchip/GICv3: Convert to EOImode == 1")
      Cc: stable@vger.kernel.org
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NAshok Kumar <ashoks@broadcom.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      004fa08d