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: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

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: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
Cc: John Garry <john.garry@huawei.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

The Broadcom STB platforms support S5 and we allow specific hardware
wake-up events to take us out of this state. Because we were not
defining an irq_pm_shutdown() function pointer, we would not be
correctly masking non-wakeup events, which would result in spurious
wake-ups from sources that were not explicitly configured for wake-up.

Fixes: 7f646e92 ("irqchip: brcmstb-l2: Add Broadcom Set Top Box Level-2 interrupt controller")
Acked-by: Gregory Fong <gregory.0xf0@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

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: Will Deacon <will.deacon@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

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: Robert Richter <rrichter@cavium.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

Honor the 'force' flag for set_affinity, by selecting a CPU
from the given mask (which may not be reported "online" by
the cpu_online_mask). Some drivers, like ARM PMU, rely on it.

Cc: Marc Zyngier <marc.zyngier@arm.com>
Reported-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

If the GIC cannot map an IRQ via irq_domain_ops->alloc(), it doesn't
return an error code.  This can cause a problem with drivers, where
it thinks it has successfully got an IRQ for the device, but requesting
the same ends up failure with -ENOSYS (as the IRQ's chip is not set).

Fixes: commit 443acc4f ("irqchip: GICv3: Convert to domain hierarchy")
Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

If the GIC cannot map an IRQ via irq_domain_ops->alloc(), it doesn't
return an error code.  This can cause a problem with drivers, where
it thinks it has successfully got an IRQ for the device, but requesting
the same ends up failure with -ENOSYS (as the IRQ's chip is not set).

Fixes: commit 9a1091ef ("irqchip: gic: Support hierarchy irq domain.")
Cc: Yingjoe Chen <yingjoe.chen@mediatek.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

We are no longer using the root argument passed to the ->fixup() hooks.
Remove it.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

of_find_compatible_node() is calling of_node_put() on its first argument
thus leading to an unbalanced of_node_get/put() issue if the node has not
been retained before that.

Instead of passing the root node, pass NULL, which does exactly the same:
iterate over all DT nodes, starting from the root node.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Fixes: 3d61467f ("irqchip: atmel-aic: Implement RTC irq fixup")
Cc: <stable@vger.kernel.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

aic_common_irq_fixup() is calling twice of_node_put() on the same node
thus leading to an unbalanced refcount on the root node.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Fixes: b2f579b5 ("irqchip: atmel-aic: Add irq fixup infrastructure")
Cc: <stable@vger.kernel.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

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: Stafford Horne <shorne@gmail.com>
Signed-off-by: Pedro H. Penna <pedrohenriquepenna@gmail.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

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: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

The current ITS driver is assuming every ITS hardware implementation
supports minimum of 16bit INTID. But this is not true, as per GICv3
specification, INTID field is IMPLEMENTATION DEFINED in the range of
14-24 bits. We might see an unpredictable system behavior on systems
where hardware support less than 16bits and software tries to use
64K LPI interrupts.

On Qualcomm Datacenter Technologies QDF2400 platform, boot log shows
confusing information about number of LPI chunks as shown below. The
QDF2400 ITS hardware supports 24bit INTID.

This patch allocates the memory resources for PEND/PROP tables based
on discoverable value which is specified in GITS_TYPER.IDbits. Also
it fixes the log message that reflects the correct number of LPI
chunks were allocated.

ITS@0xff7efe0000: allocated 524288 Devices @3c0400000 (indirect, esz 8, psz 64K, shr 1)
ITS@0xff7efe0000: allocated 8192 Interrupt Collections @3c0130000 (flat, esz 8, psz 64K, shr 1)
ITS@0xff7efe0000: allocated 8192 Virtual CPUs @3c0140000 (flat, esz 8, psz 64K, shr 1)
ITS: Allocated 524032 chunks for LPIs
PCI/MSI: ITS@0xff7efe0000 domain created
Platform MSI: ITS@0xff7efe0000 domain created
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

Add code to parse SRAT ITS Affinity sub table as defined in ACPI 6.2.
Later in per device probe, ITS devices are mapped to numa node using
ITS Id to proximity domain mapping.

[maz: fix dependency on ACPICA, fixed structure name, minor cleanups]
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by <linux/of.h> work with const
of_device_ids. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by <linux/of.h> work with const
of_device_ids. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

The Marvell ICU unit is found in the CP110 block of the Marvell Armada
7K and 8K SoCs. It collects the wired interrupts of the devices located
in the CP110 and turns them into SPI interrupts in the GIC located in
the AP806 side of the SoC, by using a memory transaction.

Until now, the ICU was configured in a static fashion by the firmware,
and Linux was relying on this static configuration. By having Linux
configure the ICU, we are more flexible, and we can allocate dynamically
the GIC SPI interrupts only for devices that are actually in use.

The driver was initially written by Hanna Hawa <hannah@marvell.com>.
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

This commit adds a simple driver for the Marvell GICP, a hardware unit
that converts memory writes into GIC SPI interrupts. The driver provides
a number of functions to the ICU driver to allocate GICP interrupts, and
get the physical addresses that the ICUs should write to to set/clear
interrupts.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

This commit adds the Device Tree binding documentation for the Marvell
ICU interrupt controller, which collects wired interrupts from the
devices located into the CP110 hardware block of Marvell Armada 7K/8K,
and converts them into SPI interrupts in the GIC located in the AP
hardware block, using the GICP extension.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

This commit adds the Device Tree binding documentation for the Marvell
GICP, an extension to the GIC that allows to trigger GIC SPI interrupts
using memory transactions. It is used by the ICU unit in the Marvell
CP110 block to turn wired interrupts inside the CP into SPI interrupts
at the GIC level in the AP.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

Use the builtin_platform_driver() macro to make the code simpler.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

The Aspeed 24XX/25XX chips share a single hardware interrupt across 14
separate I2C busses. This adds a dummy irqchip which maps the single
hardware interrupt to software interrupts for each of the busses.
Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

Added device tree binding documentation for Aspeed I2C Interrupt
Controller.
Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

In addition to introducing the new compatible string the bindings
description is reworked to be more generic.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

struct irq_domain_ops is not modified, so it can be made const.

Cc: Joel Stanley <joel@jms.id.au>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

This reverts commit 353d6d6c, which is
no longer needed, now that the irq-armada-370-xp driver properly
re-enables per-CPU interrupt on both the boot CPU and secondary CPUs
after resume.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

Commit d17cab44 ("irqchip: Kill off set_irq_flags usage") changed
the code of armada_370_xp_mpic_irq_map() from using set_irq_flags() to
irq_set_probe().

While the commit log seems to imply that there are no functional
changes, there are indeed functional changes introduced by this commit:
the IRQ_NOAUTOEN flag is no longer cleared. This functional change
caused a regression on Armada XP, which no longer works properly after
suspend/resume because per-CPU interrupts remain disabled. This
regression was temporarly worked around in commit
353d6d6c ("irqchip/armada-370-xp: Fix regression by clearing
IRQ_NOAUTOEN"), but it is not the most satisfying solution. This commit
implements the solution that was initially discussed with Thomas
Gleixner.

Due to how the hardware registers work, the irq-armada-370-xp cannot
simply save/restore a bunch of registers at suspend/resume to make sure
that the interrupts remain in the same state after resuming. Therefore,
it relies on the kernel to say whether the interrupt is disabled or not,
using the irqd_irq_disabled() function. This was all working fine while
the IRQ_NOAUTOEN flag was cleared.

With the change introduced by Rob Herring in d17cab44, the
IRQ_NOAUTOEN flag is now set for all interrupts. irqd_irq_disabled()
returns false for per-CPU interrupts, and therefore our per-CPU
interrupts are no longer re-enabled after resume.

This commit fixes that by using irqd_irq_disabled() only for global
interrupts, and using the newly introduced irq_percpu_is_enabled() for
per-CPU interrupts.

Also, it fixes a related problems that per-CPU interrupts were only
re-enabled on the boot CPU and not other CPUs. Until now this wasn't a
problem since on this platform, only the local timers are using per-CPU
interrupts and the local timers of secondary CPUs are turned off/on
during CPU hotplug before suspend, after after resume. However, since
Linux 4.4, we are also be using per-CPU interrupts for the network
controller, so we need to properly restore the per-CPU interrupts on
secondary CPUs as well.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

Since the overall logic of the driver to handle the global and per-CPU
masking of the interrupts is far from trivial, this commit adds a long
comment detailing how the hardware operates and what strategy the
driver implements on top of that.
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

In order to clarify to which register base the various register
definitions apply, this commit re-orders them, and adds a comment that
clearly indicate which registers are relative to "main_int_base" and
which registers are relative to "per_cpu_int_base".
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

Just skip the irq affinity setting when the target cpu is the same as
current setting.
This is a small optimization for irq affinity setting logic.
Signed-off-by: MaJun <majun258@huawei.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

The call to pci_for_each_dma_alias() in the ITS PCI code has aroused
suspicion in the past, and upon closer inspection does turn out to be
completely backwards. Rather than iterating through each RID alias of
the given device, what we actually want to be doing here is iterating
through all the *other* devices which may also alias the same RID, in
order to size the table for the worst case.

Do the right thing by ignoring the initial DMA aliases themselves and
just using that walk to detect an aliasing bridge, then walking back
down the bus topology as necessary to actually count everything else.

Our alias handling still isn't perfect, since we don't account for the
cases of certain bridges only taking ownership of transactions under
particular circumstances, but without completely reworking the ITS code
to cope with the notion of multiple DevIDs per device, it'll have to do.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

struct irq_domain_ops is not modified, so it can be made const.

Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: uclinux-h8-devel@lists.sourceforge.jp
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

struct irq_domain_ops is not modified, so it can be made const.

Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: uclinux-h8-devel@lists.sourceforge.jp
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

struct irq_domain_ops is not modified, so it can be made const.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

struct irq_domain_ops is not modified, so it can be made const.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

struct irq_domain_ops is not modified, so it can be made const.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

struct irq_domain_ops is not modified, so it can be made const.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

The R_INTC on the A31 is undocumented. It was previously supported
by the sun6i-a31-sc-nmi compatible. This compatible however required
the register region to start at the first used register, rather than
the boundaries laid out in the SoC's memory map. The new compatible
fixes the alignment, while also naming it properly.

Since the only difference between the old and new compatibles are
a fixed offset for the registers, and since the old one is deprecated,
this patch adds a set of register defines for the new compatible,
while modifying the old set to reference the new set minus a fixed
offset.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>