1. 10 Aug, 2017 2 commits
    • Lorenzo Pieralisi's avatar
      irqchip/gic-v3-its-platform-msi: Fix msi-parent parsing loop · a0088737
      Lorenzo Pieralisi authored
      While parsing the msi-parent property to chase up the IRQ domain
      a given device belongs to, the index into the msi-parent tuple should
      be incremented to ensure all properties entries are taken into account.
      
      Current code missed the index update so the parsing loop does not work
      in case multiple msi-parent phandles are present and may turn into
      an infinite loop in of_pmsi_get_dev_id() if phandle at index 0 does
      not correspond to the domain we are actually looking-up.
      
      Fix the code by updating the phandle index at each iteration in
      of_pmsi_get_dev_id().
      
      Fixes: deac7fc1 ("irqchip/gic-v3-its: Parse new version of msi-parent property")
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      a0088737
    • Hanjun Guo's avatar
      irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES · fdf6e7a8
      Hanjun Guo authored
      When enabling ITS NUMA support on D05, I got the boot log:
      
      [    0.000000] SRAT: PXM 0 -> ITS 0 -> Node 0
      [    0.000000] SRAT: PXM 0 -> ITS 1 -> Node 0
      [    0.000000] SRAT: PXM 0 -> ITS 2 -> Node 0
      [    0.000000] SRAT: PXM 1 -> ITS 3 -> Node 1
      [    0.000000] SRAT: ITS affinity exceeding max count[4]
      
      This is wrong on D05 as we have 8 ITSs with 4 NUMA nodes.
      
      So dynamically alloc the memory needed instead of using
      its_srat_maps[MAX_NUMNODES], which count the number of
      ITS entry(ies) in SRAT and alloc its_srat_maps as needed,
      then build the mapping of numa node to ITS ID. Of course,
      its_srat_maps will be freed after ITS probing because
      we don't need that after boot.
      
      After doing this, I got what I wanted:
      
      [    0.000000] SRAT: PXM 0 -> ITS 0 -> Node 0
      [    0.000000] SRAT: PXM 0 -> ITS 1 -> Node 0
      [    0.000000] SRAT: PXM 0 -> ITS 2 -> Node 0
      [    0.000000] SRAT: PXM 1 -> ITS 3 -> Node 1
      [    0.000000] SRAT: PXM 2 -> ITS 4 -> Node 2
      [    0.000000] SRAT: PXM 2 -> ITS 5 -> Node 2
      [    0.000000] SRAT: PXM 2 -> ITS 6 -> Node 2
      [    0.000000] SRAT: PXM 3 -> ITS 7 -> Node 3
      
      Fixes: dbd2b826 ("irqchip/gic-v3-its: Add ACPI NUMA node mapping")
      Signed-off-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      Reviewed-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
      Cc: John Garry <john.garry@huawei.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      fdf6e7a8
  2. 07 Aug, 2017 1 commit
  3. 02 Aug, 2017 2 commits
    • Will Deacon's avatar
      irqchip/gic: Ensure we have an ISB between ack and ->handle_irq · 39a06b67
      Will Deacon authored
      Devices that expose their interrupt status registers via system
      registers (e.g. Statistical profiling, CPU PMU, DynamIQ PMU, arch timer,
      vgic (although unused by Linux), ...) rely on a context synchronising
      operation on the CPU to ensure that the updated status register is
      visible to the CPU when handling the interrupt. This usually happens as
      a result of taking the IRQ exception in the first place, but there are
      two race scenarios where this isn't the case.
      
      For example, let's say we have two peripherals (X and Y), where Y uses a
      system register for its interrupt status.
      
      Case 1:
      1. CPU takes an IRQ exception as a result of X raising an interrupt
      2. Y then raises its interrupt line, but the update to its system
         register is not yet visible to the CPU
      3. The GIC decides to expose Y's interrupt number first in the Ack
         register
      4. The CPU runs the IRQ handler for Y, but the status register is stale
      
      Case 2:
      1. CPU takes an IRQ exception as a result of X raising an interrupt
      2. CPU reads the interrupt number for X from the Ack register and runs
         its IRQ handler
      3. Y raises its interrupt line and the Ack register is updated, but
         again, the update to its system register is not yet visible to the
         CPU.
      4. Since the GIC drivers poll the Ack register, we read Y's interrupt
         number and run its handler without a context synchronisation
         operation, therefore seeing the stale register value.
      
      In either case, we run the risk of missing an IRQ. This patch solves the
      problem by ensuring that we execute an ISB in the GIC drivers prior
      to invoking the interrupt handler. This is already the case for GICv3
      and EOIMode 1 (the usual case for the host).
      
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      39a06b67
    • Robert Richter's avatar
      irqchip/gic-v3-its: Remove ACPICA version check for ACPI NUMA · d1ce263f
      Robert Richter authored
      The version check was added due to dependency to
      
       a618c7f8 ACPICA: Add support for new SRAT subtable
      
      Now, that this code is in the kernel, remove the check. This is esp.
      useful to enable backports.
      Signed-off-by: default avatarRobert Richter <rrichter@cavium.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      d1ce263f
  4. 04 Jul, 2017 6 commits
  5. 30 Jun, 2017 3 commits
    • Pedro H. Penna's avatar
      irqchip/or1k-pic: Fix interrupt acknowledgement · ca387019
      Pedro H. Penna authored
      Usually, hardware implicitly acknowledges interrupts when
      reading them. However, if this is not the case, the IRQ
      gets fired over and over again in the current implementation.
      
      This patch uses the right mask acknowledge function to handle the
      aforementioned situation on or1k processors that interact with
      such kind of hardware.
      Acked-by: default avatarStafford Horne <shorne@gmail.com>
      Signed-off-by: default avatarPedro H. Penna <pedrohenriquepenna@gmail.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      ca387019
    • Dan Carpenter's avatar
      irqchip/irq-mvebu-gicp: Allocate enough memory for spi_bitmap · 478a2db8
      Dan Carpenter authored
      BITS_TO_LONGS() gives us the number of longs we need, but we want to
      allocate the number of bytes.
      
      Fixes: a68a63cb ("irqchip/irq-mvebu-gicp: Add new driver for Marvell GICP")
      Acked-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      478a2db8
    • Suzuki K Poulose's avatar
      irqchip/gic-v3: Fix out-of-bound access in gic_set_affinity · 866d7c1b
      Suzuki K Poulose authored
      The GICv3 driver doesn't check if the target CPU for gic_set_affinity
      is valid before going ahead and making the changes. This triggers the
      following splat with KASAN:
      
      [  141.189434] BUG: KASAN: global-out-of-bounds in gic_set_affinity+0x8c/0x140
      [  141.189704] Read of size 8 at addr ffff200009741d20 by task swapper/1/0
      [  141.189958]
      [  141.190158] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.12.0-rc7
      [  141.190458] Hardware name: Foundation-v8A (DT)
      [  141.190658] Call trace:
      [  141.190908] [<ffff200008089d70>] dump_backtrace+0x0/0x328
      [  141.191224] [<ffff20000808a1b4>] show_stack+0x14/0x20
      [  141.191507] [<ffff200008504c3c>] dump_stack+0xa4/0xc8
      [  141.191858] [<ffff20000826c19c>] print_address_description+0x13c/0x250
      [  141.192219] [<ffff20000826c5c8>] kasan_report+0x210/0x300
      [  141.192547] [<ffff20000826ad54>] __asan_load8+0x84/0x98
      [  141.192874] [<ffff20000854eeec>] gic_set_affinity+0x8c/0x140
      [  141.193158] [<ffff200008148b14>] irq_do_set_affinity+0x54/0xb8
      [  141.193473] [<ffff200008148d2c>] irq_set_affinity_locked+0x64/0xf0
      [  141.193828] [<ffff200008148e00>] __irq_set_affinity+0x48/0x78
      [  141.194158] [<ffff200008bc48a4>] arm_perf_starting_cpu+0x104/0x150
      [  141.194513] [<ffff2000080d73bc>] cpuhp_invoke_callback+0x17c/0x1f8
      [  141.194783] [<ffff2000080d94ec>] notify_cpu_starting+0x8c/0xb8
      [  141.195130] [<ffff2000080911ec>] secondary_start_kernel+0x15c/0x200
      [  141.195390] [<0000000080db81b4>] 0x80db81b4
      [  141.195603]
      [  141.195685] The buggy address belongs to the variable:
      [  141.196012]  __cpu_logical_map+0x200/0x220
      [  141.196176]
      [  141.196315] Memory state around the buggy address:
      [  141.196586]  ffff200009741c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [  141.196913]  ffff200009741c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [  141.197158] >ffff200009741d00: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 00 00
      [  141.197487]                                ^
      [  141.197758]  ffff200009741d80: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00
      [  141.198060]  ffff200009741e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [  141.198358] ==================================================================
      [  141.198609] Disabling lock debugging due to kernel taint
      [  141.198961] CPU1: Booted secondary processor [410fd051]
      
      This patch adds the check to make sure the cpu is valid.
      
      Fixes: commit 021f6537 ("irqchip: gic-v3: Initial support for GICv3")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      866d7c1b
  6. 23 Jun, 2017 7 commits
  7. 22 Jun, 2017 19 commits