The current PCI/MSI support in the GICv3 ITS doesn't really deal
with systems where different PCI devices end-up using the same
RequesterID (as it would be the case with non-transparent bridges,
for example). It is likely that none of these devices would
actually generate any interrupt, as the ITS is programmed with
the device's own ID, and not that of the bridge.

A solution to this is to iterate over the PCI hierarchy to
discover what the device aliases too. We also use this
to discover the upper bound of the number of MSIs that this
sub-hierarchy can generate.

With this in place, PCI aliases can be supported.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-4-git-send-email-marc.zyngier@arm.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>

The ITS table allocator is only allocating a single page per table.
This works fine for most things, but leads to silent lack of
interrupt delivery if we end-up with a device that has an ID that is
out of the range defined by a single page of memory. Even worse, depending
on the page size, behaviour changes, which is not a very good experience.

A solution is actually to allocate memory for the full range of ID that
the ITS supports. A massive waste memory wise, but at least a safe bet.

Tested on a Phytium SoC.
Tested-by: NChen Baozi <chenbaozi@kylinos.com.cn>
Acked-by: NChen Baozi <chenbaozi@kylinos.com.cn>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-3-git-send-email-marc.zyngier@arm.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>

We skip initialisation of ITS in case the device-tree has no
corresponding description, but we are still accessing to ITS bits while
setting CPU interface what leads to the kernel panic:

ITS: No ITS available, not enabling LPIs
CPU0: found redistributor 0 region 0:0x000000002f100000
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = ffffffc0007fb000
[00000000] *pgd=00000000fc407003, *pud=00000000fc407003, *pmd=00000000fc408003, *pte=006000002f000707
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.19.0-rc2+ #318
Hardware name: FVP Base (DT)
task: ffffffc00077edb0 ti: ffffffc00076c000 task.ti: ffffffc00076c000
PC is at its_cpu_init+0x2c/0x320
LR is at gic_cpu_init+0x168/0x1bc

It happens in gic_rdists_supports_plpis() because gic_rdists is NULL.
The gic_rdists is set to non-NULL only when ITS node is presented in
the device-tree.

Fix this by moving the call to gic_rdists_supports_plpis() inside the
!list_empty(&its_nodes) block, because it is that list that guards the
validity of the rest of the information in this driver.
Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NVladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-2-git-send-email-marc.zyngier@arm.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>

arm64 defconfig spits out the following compiler warning from the ITS
driver:

In file included from include/linux/bitmap.h:9:0,
                 from drivers/irqchip/irq-gic-v3-its.c:18:
drivers/irqchip/irq-gic-v3-its.c: In function ‘its_create_device’:
include/linux/kernel.h:716:17: warning: comparison of distinct pointer types lacks a cast
  (void) (&_max1 == &_max2);  \
                 ^
drivers/irqchip/irq-gic-v3-its.c:1056:12: note: in expansion of macro ‘max’
  nr_ites = max(2, roundup_pow_of_two(nvecs));

Fix the warning by specifying the decimal constant `2' explicitly as an
unsigned long type.

Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1418825469-30529-1-git-send-email-will.deacon@arm.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>

When issuing a MAPD command, one of the parameters passed to the ITS
is the number of EventID bits used to index the per-device Interrupt
Translation Table (ITT). Crucially, this is the number of bits
*minus one*.

This has two consequences:
- The size of the ITT has to be a strict power of two, no matter
  how many different events the device is actually going to generate.
- It is impossible to express an ITT with a single entry, as you
  would have to tell the ITS to "use zero bit from the EventID",
  and that clashes with "minus one" above.

Fix this by allocating the ITT with the number of vectors rounded up
to the next power of two, with a minimum of two entries.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Yun Wu (Abel) <wuyun.wu@huawei.com>
Cc: Robert Richter <robert.richter@caviumnetworks.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

The ITS code could do a bit less in the alloc/free paths, and a bit
more in the activate/deactivate methods, giving a better separation
between software allocation and HW programing.
Suggested-by: NWuyun Wu (Abel) <wuyun.wu@huawei.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Yun Wu (Abel) <wuyun.wu@huawei.com>
Cc: Robert Richter <robert.richter@caviumnetworks.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Fix stupid thinko on the path freeing the interrupts, where only
the first interrupt would get reset, and none of the others.

This should only affect multi-MSI allocations.
Reported-by: NWuyun Wu (Abel) <wuyun.wu@huawei.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Robert Richter <robert.richter@caviumnetworks.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Add the code that probes the ITS from the device tree,
and initialize it.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1416839720-18400-11-git-send-email-marc.zyngier@arm.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>

Now, the bit of code that allow us to use the ITS as a MSI controller.
Both MSI and MSI-X are supported.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1416839720-18400-10-git-send-email-marc.zyngier@arm.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>

The ITS has a notion of "device" that can write to it in order to
generate an interrupt.

Conversly, the driver maintains a per-ITS list of devices, together
with their configuration information, and uses this to configure
the HW.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1416839720-18400-9-git-send-email-marc.zyngier@arm.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>

The interrupt translation is driven by a set of tables (device,
ITT, and collection) to be in the end delivered to a CPU. Also,
the redistributors rely on a couple of tables (configuration, and
pending) to deliver the interrupts to the CPUs.

This patch adds the required allocators for these tables.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1416839720-18400-8-git-send-email-marc.zyngier@arm.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>

LPIs are the type of interrupts that are used by the ITS. Given
the size of the namespace (anywhere between 16 and 32bit), interrupt
IDs are allocated in chunks of 32.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1416839720-18400-7-git-send-email-marc.zyngier@arm.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>

The usual methods that are used to present an irqchip to the rest
of the kernel
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1416839720-18400-6-git-send-email-marc.zyngier@arm.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>

The ITS is configured through a number commands that the driver
issues to the HW using a memory-based circular buffer.

This patch implements the subset of commands that are required
for Linux.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1416839720-18400-5-git-send-email-marc.zyngier@arm.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>