There is a huge number of broken device trees out there. Just
grepping through the tree for the use of IRQ_TYPE_NONE in conjunction
with the GIC is scary.

People just don't realise that IRQ_TYPE_NONE just doesn't exist, and
you just get whatever junk was there before. So let's make them aware
of the issue.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

This adds functionality to resend the MAPC command to an ITS node on
resume. If the ITS is powered down during suspend and the collections
are not backed by memory, the ITS will lose that state. This just sets
up the known state for the collections after the ITS is restored.
Signed-off-by: NDerek Basehore <dbasehore@chromium.org>
Reviewed-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Some platforms power off GIC logic in suspend, so we need to
save/restore state. The distributor and redistributor registers need
to be handled in firmware code due to access permissions on those
registers, but the ITS registers can be restored in the kernel.

We limit this to systems where the ITS collections are implemented
in HW (as opposed to being backed by memory tables), as they are
the only ones that cannot be dealt with by the firmware.
Signed-off-by: NDerek Basehore <dbasehore@chromium.org>
[maz: fixed changelog, dropped DT property, limited to HCC being >0]
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

For most GICv3 implementations, enabling LPIs is a one way switch.
Once they're on, there is no turning back, which completely kills
kexec (pending tables will always be live, and we can't tell the
secondary kernel where they are).

This is really annoying if you plan to use Linux as a bootloader,
as it pretty much guarantees that the secondary kernel won't be
able to use MSIs, and may even see some memory corruption. Bad.

A workaround for this unfortunate situation is to allow the kernel
not to enable LPIs, even if the feature is present in the HW. This
would allow Linux-as-a-bootloader to leave LPIs alone, and let the
secondary kernel to do whatever it wants with them.

Let's introduce a boolean "irqchip.gicv3_nolpi" command line option
that serves that purpose.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Booting a crash kernel while in an interrupt handler is likely
to leave the Active Priority Registers with some state that
is not relevant to the new kernel, and is likely to lead
to erratic behaviours such as interrupts not firing as their
priority is already active.

As a sanity measure, wipe the APRs clean on startup. We make
sure to wipe both group 0 and 1 registers in order to avoid
any surprise.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Booting a crash kernel while in an interrupt handler is likely
to leave the Active Priority Registers with some state that
is not relevant to the new kernel, and is likely to lead
to erratic behaviours such as interrupts not firing as their
priority is already active.

As a sanity measure, wipe the APRs clean on startup.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

The Power Domain Controller (PDC) on QTI SoCs like SDM845 houses an
interrupt controller along with other domain control functions to handle
interrupt related functions like handle falling edge or active low which
are not detected at the GIC and handle wakeup interrupts.

The interrupt controller is on an always-on domain for the purpose of
waking up the processor. Only a subset of the processor's interrupts are
routed through the PDC to the GIC. The PDC powers on the processors'
domain, when in low power mode and replays pending interrupts so the GIC
may wake up the processor.
Signed-off-by: NArchana Sathyakumar <asathyak@codeaurora.org>
Signed-off-by: NLina Iyer <ilina@codeaurora.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Since commit 6f46aedb ("irqchip: renesas-irqc: Add wake-up
support"), when an IRQ is used for wakeup, the INTC
block's module clock is manually kept running during system suspend, to
make sure the device stays active.

However, this explicit clock handling is merely a workaround for a
failure to properly communicate wakeup information to the device core.

Instead, set the device's power.wakeup_path field, to indicate this
device is part of the wakeup path.  Depending on the PM Domain's
active_wakeup configuration, the genpd core code will keep the device
enabled (and the clock running) during system suspend when needed.
This allows for the removal of all explicit clock handling code from the
driver.
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Since commit 705bc96c ("irqchip: renesas-intc-irqpin: Add
minimal runtime PM support"), when an IRQ is used for wakeup, the INTC
block's module clock (if exists) is manually kept running during system
suspend, to make sure the device stays active.

However, this explicit clock handling is merely a workaround for a
failure to properly communicate wakeup information to the device core.

Instead, set the device's power.wakeup_path field, to indicate this
device is part of the wakeup path.  Depending on the PM Domain's
active_wakeup configuration, the genpd core code will keep the device
enabled (and the clock running) during system suspend when needed.
This allows for the removal of all explicit clock handling code from the
driver.
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Since commit ad67b74d ("printk: hash addresses printed with %p")
pointers are being hashed when printed. Displaying the virtual memory at
bootup time is not helpful. so delete the prints.
Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NJaedon Shin <jaedon.shin@gmail.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

We'd never implemented Multi-MSI support with GICv2m, because
it is weird and clunky, and you'd think people would rather use
MSI-X.

Turns out there is still plenty of devices out there that rely
on Multi-MSI. Oh well, let's teach that trick to the v2m widget,
it is not a big deal anyway.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

On some platforms there's an ITS available but it's not enabled
because reading or writing the registers is denied by the
firmware. In fact, reading or writing them will cause the system
to reset. We could remove the node from DT in such a case, but
it's better to skip nodes that are marked as "disabled" in DT so
that we can describe the hardware that exists and use the status
property to indicate how the firmware has configured things.

Cc: Stuart Yoder <stuyoder@gmail.com>
Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Rajendra Nayak <rnayak@codeaurora.org>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

A DMB instruction can be used to ensure the relative order of only
memory accesses before and after the barrier. Since writes to system
registers are not memory operations, barrier DMB is not sufficient
for observability of memory accesses that occur before ICC_SGI1R_EL1
writes.

A DSB instruction ensures that no instructions that appear in program
order after the DSB instruction, can execute until the DSB instruction
has completed.

Cc: stable@vger.kernel.org
Acked-by: Will Deacon <will.deacon@arm.com>,
Signed-off-by: NShanker Donthineni <shankerd@codeaurora.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

The pr_debug() in gic-v3 gic_send_sgi() can trigger a circular locking
warning:

 GICv3: CPU10: ICC_SGI1R_EL1 5000400
 ======================================================
 WARNING: possible circular locking dependency detected
 4.15.0+ #1 Tainted: G        W
 ------------------------------------------------------
 dynamic_debug01/1873 is trying to acquire lock:
  ((console_sem).lock){-...}, at: [<0000000099c891ec>] down_trylock+0x20/0x4c

 but task is already holding lock:
  (&rq->lock){-.-.}, at: [<00000000842e1587>] __task_rq_lock+0x54/0xdc

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -> #2 (&rq->lock){-.-.}:
        __lock_acquire+0x3b4/0x6e0
        lock_acquire+0xf4/0x2a8
        _raw_spin_lock+0x4c/0x60
        task_fork_fair+0x3c/0x148
        sched_fork+0x10c/0x214
        copy_process.isra.32.part.33+0x4e8/0x14f0
        _do_fork+0xe8/0x78c
        kernel_thread+0x48/0x54
        rest_init+0x34/0x2a4
        start_kernel+0x45c/0x488

 -> #1 (&p->pi_lock){-.-.}:
        __lock_acquire+0x3b4/0x6e0
        lock_acquire+0xf4/0x2a8
        _raw_spin_lock_irqsave+0x58/0x70
        try_to_wake_up+0x48/0x600
        wake_up_process+0x28/0x34
        __up.isra.0+0x60/0x6c
        up+0x60/0x68
        __up_console_sem+0x4c/0x7c
        console_unlock+0x328/0x634
        vprintk_emit+0x25c/0x390
        dev_vprintk_emit+0xc4/0x1fc
        dev_printk_emit+0x88/0xa8
        __dev_printk+0x58/0x9c
        _dev_info+0x84/0xa8
        usb_new_device+0x100/0x474
        hub_port_connect+0x280/0x92c
        hub_event+0x740/0xa84
        process_one_work+0x240/0x70c
        worker_thread+0x60/0x400
        kthread+0x110/0x13c
        ret_from_fork+0x10/0x18

 -> #0 ((console_sem).lock){-...}:
        validate_chain.isra.34+0x6e4/0xa20
        __lock_acquire+0x3b4/0x6e0
        lock_acquire+0xf4/0x2a8
        _raw_spin_lock_irqsave+0x58/0x70
        down_trylock+0x20/0x4c
        __down_trylock_console_sem+0x3c/0x9c
        console_trylock+0x20/0xb0
        vprintk_emit+0x254/0x390
        vprintk_default+0x58/0x90
        vprintk_func+0xbc/0x164
        printk+0x80/0xa0
        __dynamic_pr_debug+0x84/0xac
        gic_raise_softirq+0x184/0x18c
        smp_cross_call+0xac/0x218
        smp_send_reschedule+0x3c/0x48
        resched_curr+0x60/0x9c
        check_preempt_curr+0x70/0xdc
        wake_up_new_task+0x310/0x470
        _do_fork+0x188/0x78c
        SyS_clone+0x44/0x50
        __sys_trace_return+0x0/0x4

 other info that might help us debug this:

 Chain exists of:
   (console_sem).lock --> &p->pi_lock --> &rq->lock

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(&rq->lock);
                                lock(&p->pi_lock);
                                lock(&rq->lock);
   lock((console_sem).lock);

  *** DEADLOCK ***

 2 locks held by dynamic_debug01/1873:
  #0:  (&p->pi_lock){-.-.}, at: [<000000001366df53>] wake_up_new_task+0x40/0x470
  #1:  (&rq->lock){-.-.}, at: [<00000000842e1587>] __task_rq_lock+0x54/0xdc

 stack backtrace:
 CPU: 10 PID: 1873 Comm: dynamic_debug01 Tainted: G        W        4.15.0+ #1
 Hardware name: GIGABYTE R120-T34-00/MT30-GS2-00, BIOS T48 10/02/2017
 Call trace:
  dump_backtrace+0x0/0x188
  show_stack+0x24/0x2c
  dump_stack+0xa4/0xe0
  print_circular_bug.isra.31+0x29c/0x2b8
  check_prev_add.constprop.39+0x6c8/0x6dc
  validate_chain.isra.34+0x6e4/0xa20
  __lock_acquire+0x3b4/0x6e0
  lock_acquire+0xf4/0x2a8
  _raw_spin_lock_irqsave+0x58/0x70
  down_trylock+0x20/0x4c
  __down_trylock_console_sem+0x3c/0x9c
  console_trylock+0x20/0xb0
  vprintk_emit+0x254/0x390
  vprintk_default+0x58/0x90
  vprintk_func+0xbc/0x164
  printk+0x80/0xa0
  __dynamic_pr_debug+0x84/0xac
  gic_raise_softirq+0x184/0x18c
  smp_cross_call+0xac/0x218
  smp_send_reschedule+0x3c/0x48
  resched_curr+0x60/0x9c
  check_preempt_curr+0x70/0xdc
  wake_up_new_task+0x310/0x470
  _do_fork+0x188/0x78c
  SyS_clone+0x44/0x50
  __sys_trace_return+0x0/0x4
 GICv3: CPU0: ICC_SGI1R_EL1 12000

This could be fixed with printk_deferred() but that might lessen its
usefulness for debugging. So change it to pr_devel to keep it out of
production kernels. Developers working on gic-v3 can enable it as
needed in their kernels.
Signed-off-by: NMark Salter <msalter@redhat.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Commit 7778c4b2 ("irqchip: mips-gic: Use pcpu_masks to avoid reading
GIC_SH_MASK*") removed the read of the hardware mask register when
handling shared interrupts, instead using the driver's shadow pcpu_masks
entry as the effective mask. Unfortunately this did not take account of
the write to pcpu_masks during gic_shared_irq_domain_map, which
effectively unmasks the interrupt early. If an interrupt is asserted,
gic_handle_shared_int decodes and processes the interrupt even though it
has not yet been unmasked via gic_unmask_irq, which also sets the
appropriate bit in pcpu_masks.

On the MIPS Boston board, when a console command line of
"console=ttyS0,115200n8r" is passed, the modem status IRQ is enabled in
the UART, which is immediately raised to the GIC. The interrupt has been
mapped, but no handler has yet been registered, nor is it expected to be
unmasked. However, the write to pcpu_masks in gic_shared_irq_domain_map
has effectively unmasked it, resulting in endless reports of:

[    5.058454] irq 13, desc: ffffffff80a7ad80, depth: 1, count: 0, unhandled: 0
[    5.062057] ->handle_irq():  ffffffff801b1838,
[    5.062175] handle_bad_irq+0x0/0x2c0

Where IRQ 13 is the UART interrupt.

To fix this, just remove the write to pcpu_masks in
gic_shared_irq_domain_map. The existing write in gic_unmask_irq is the
correct place for what is now the effective unmasking.

Cc: stable@vger.kernel.org
Fixes: 7778c4b2 ("irqchip: mips-gic: Use pcpu_masks to avoid reading GIC_SH_MASK*")
Signed-off-by: NMatt Redfearn <matt.redfearn@mips.com>
Reviewed-by: NPaul Burton <paul.burton@mips.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Uniformize STMicroelectronics copyrights header and add SPDX identifier

CC: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@st.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NAlexandre TORGUE <alexandre.torgue@st.com>
Acked-by: NMaxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: jason@lakedaemon.net
Cc: marc.zyngier@arm.com
Cc: linux-arm-kernel@lists.infradead.org
Link: https://lkml.kernel.org/r/20171130084500.23439-1-benjamin.gaignard@st.com

The ACPI specification says OS shouldn't attempt to use GICC configuration
parameters if the flag ACPI_MADT_ENABLED is cleared. The ARM64-SMP code
skips the disabled GICC entries but not causing any issue. However the
current GICv3 driver probe bails out causing kernel panic() instead of
skipping the disabled GICC interfaces. This issue happens on systems
where redistributor regions are not in the always-on power domain and
one of GICC interface marked with ACPI_MADT_ENABLED=0.

This patch does the two things to fix the panic.
  - Don't return an error in gic_acpi_match_gicc() for disabled GICC entry.
  - No need to keep GICR region information for disabled GICC entry.

Observed kernel crash on QDF2400 platform GICC entry is disabled.
Kernel crash traces:
  Kernel panic - not syncing: No interrupt controller found.
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.13.5 #26
  [<ffff000008087770>] dump_backtrace+0x0/0x218
  [<ffff0000080879dc>] show_stack+0x14/0x20
  [<ffff00000883b078>] dump_stack+0x98/0xb8
  [<ffff0000080c5c14>] panic+0x118/0x26c
  [<ffff000008b62348>] init_IRQ+0x24/0x2c
  [<ffff000008b609fc>] start_kernel+0x230/0x394
  [<ffff000008b601e4>] __primary_switched+0x64/0x6c
  ---[ end Kernel panic - not syncing: No interrupt controller found.

Disabled GICC subtable example:
                   Subtable Type : 0B [Generic Interrupt Controller]
                          Length : 50
                        Reserved : 0000
            CPU Interface Number : 0000003D
                   Processor UID : 0000003D
           Flags (decoded below) : 00000000
               Processor Enabled : 0
 Performance Interrupt Trig Mode : 0
 Virtual GIC Interrupt Trig Mode : 0
        Parking Protocol Version : 00000000
           Performance Interrupt : 00000017
                  Parked Address : 0000000000000000
                    Base Address : 0000000000000000
        Virtual GIC Base Address : 0000000000000000
     Hypervisor GIC Base Address : 0000000000000000
           Virtual GIC Interrupt : 00000019
      Redistributor Base Address : 0000FFFF88F40000
                       ARM MPIDR : 000000000000000D
                Efficiency Class : 00
                        Reserved : 000000
Signed-off-by: NShanker Donthineni <shankerd@codeaurora.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Add device driver for a virtual programmable interrupt controller

The virtual PIC is designed as a device tree-based interrupt controller.

The compatible string used by OS for binding the driver is
"google,goldfish-pic".
Signed-off-by: NMiodrag Dinic <miodrag.dinic@mips.com>
Signed-off-by: NGoran Ferenc <goran.ferenc@mips.com>
Signed-off-by: NAleksandar Markovic <aleksandar.markovic@mips.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

In case of error, the function ioremap() returns NULL pointer not
ERR_PTR(). The IS_ERR() test in the return value check should be
replaced with NULL test.

Fixes: 9b54470a ("irqchip: add initial support for ompic")
Acked-by: NStafford Horne <shorne@gmail.com>
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

In order to properly define the polarity of the per-cpu interrupts,
we need to support for a second property cell. But this must be
optional to keep backward compatibility with old DT blobs.
Suggested-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Use the new generic helper of_cpu_node_to_id() instead
of using our own version to map a device node to logical CPU
number.
Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

The 'early' argument of irq_domain_activate_irq() is actually used to
denote reservation mode. To avoid confusion, rename it before abuse
happens.

No functional change.

Fixes: 72491643 ("genirq/irqdomain: Update irq_domain_ops.activate() signature")
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Alexandru Chirvasitu <achirvasub@gmail.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Dou Liyang <douly.fnst@cn.fujitsu.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Mikael Pettersson <mikpelinux@gmail.com>
Cc: Josh Poulson <jopoulso@microsoft.com>
Cc: Mihai Costache <v-micos@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: linux-pci@vger.kernel.org
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Dexuan Cui <decui@microsoft.com>
Cc: Simon Xiao <sixiao@microsoft.com>
Cc: Saeed Mahameed <saeedm@mellanox.com>
Cc: Jork Loeser <Jork.Loeser@microsoft.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: devel@linuxdriverproject.org
Cc: KY Srinivasan <kys@microsoft.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Sakari Ailus <sakari.ailus@intel.com>,
Cc: linux-media@vger.kernel.org

The IRQ code already has support for lockdep class for the lock mutex
in an interrupt descriptor. Extend this to add a second class for the
request mutex in the descriptor. Not having a class is resulting in
false positive splats in some code paths.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: linus.walleij@linaro.org
Cc: grygorii.strashko@ti.com
Cc: f.fainelli@gmail.com
Link: https://lkml.kernel.org/r/1512234664-21555-1-git-send-email-andrew@lunn.ch

Set I/O port resource structs to have IORESOURCE_IO in their type field.

Previously we marked these as merely IORESOURCE_BUSY without indicating the
type.  Setting the type doesn't fix any functional problem but makes %pR
on the resource work better.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

drivers/irqchip/irq-imgpdc.c:327:20-23: WARNING: Suspicious code.
		resource_size is maybe missing with res_regs

Generated by: scripts/coccinelle/api/resource_size.cocci
Signed-off-by: NVasyl Gomonovych <gomonovych@gmail.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: marc.zyngier@arm.com
Cc: jason@lakedaemon.net
Link: https://lkml.kernel.org/r/1511215361-8279-1-git-send-email-gomonovych@gmail.com

The comparison of u32 nregs being less than zero is never true since
nregs is unsigned. Fix this by making nregs a signed integer.

Fixes: f20cc9b0 ("irqchip/qcom: Add IRQ combiner driver")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: kernel-janitors@vger.kernel.org
Cc: Jason Cooper <jason@lakedaemon.net>
Link: https://lkml.kernel.org/r/20171117183553.2739-1-colin.king@canonical.com

In case of error, the function of_iomap() returns NULL pointer not
ERR_PTR().

Replace the IS_ERR() test of the return value with NULL test and return
a proper error code.

Fixes: 706cffc1 ("irqchip/exiu: Add support for Socionext Synquacer EXIU controller")
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Link: https://lkml.kernel.org/r/1510642648-123574-1-git-send-email-weiyongjun1@huawei.com

The GICv3 ITS doesn't really depend on PCI. Only the PCI/MSI
part of it does, and there is no reason not to blow away most
of the irqchip stack because PCI is not selected (though not
selecting PCI seem to be asking for punishment, but hey...).

So let's split the PCI-specific part from the ITS in the Kconfig
file, and let's make that part depend on PCI. Architecture specific
hacks (arch/arm{,64}/Kconfig) will be addressed in a separate patch.
Reported-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

pr_err() messages should end with a new-line to avoid other messages
being concatenated.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

pr_err() messages should end with a new-line to avoid other messages
being concatenated.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Fix child-node lookup during initialisation, which ended up searching
the whole device tree depth-first starting at the parent rather than
just matching on its children.

To make things worse, the parent gic node was prematurely freed, while
the ppi-partitions node was leaked.

Fixes: e3825ba1 ("irqchip/gic-v3: Add support for partitioned PPIs")
Cc: stable <stable@vger.kernel.org>     # 4.7
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Should the call to irq_set_vcpu_affinity() fail at map time,
we should restore the normal lazy-disable behaviour instead
of staying with the eager disable that GICv4 requires.
Reported-by: NEric Auger <eric.auger@redhat.com>
Acked-by: NChristoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

If the physical address of the GIC resource cannot be read from device
tree, then the code falls back to reading it from the gcr_gic_base
register. Hopefully this has been set to a sane value by the bootloader
or some platform code, but is defined by the hardware manual to have
"undefined" reset state. Using it as the address at which the GIC will
be mapped into physical memory space can therefore be risky if it has
not been initialised, since it may result in the GIC being mapped to an
effectively random address anywhere in physical memory, where it might
conflict with peripherals or RAM and lead to weird crashes.

Since a "sane value" is very platform specific because it is particular
to the platform's memory map, it is difficult to test for. At the very
least, a warning message should be printed in the case that we trust the
inherited value.
Reported-by: NAmit Kama <amit.kama@satixfy.com>
Signed-off-by: NMatt Redfearn <matt.redfearn@mips.com>
Reviewed-by: NPaul Burton <paul.burton@mips.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Several messages from the MIPS GIC driver include the text "GIC", but
the format is not standard. Add a pr_fmt of "irq-mips-gic: " and reword
the messages now that they will be prefixed with the driver name.
Signed-off-by: NMatt Redfearn <matt.redfearn@mips.com>
Reviewed-by: NPaul Burton <paul.burton@mips.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Move irq_set_wake on interrupt mask, needed to wake up from
low power mode as the event mask is not able to do so.
Signed-off-by: NLudovic Barre <ludovic.barre@st.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

-After cold boot, imr default value depends on hardware configuration.
-After hot reboot the registers must be cleared to avoid residue.
Signed-off-by: NLudovic Barre <ludovic.barre@st.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

stm32h7 has up to 96 inputs
(3 banks of 32 inputs max).
Signed-off-by: NLudovic Barre <ludovic.barre@st.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

-Prepare to manage multi-bank of external interrupts
(N banks of 32 inputs).
-Prepare to manage registers offsets by compatible
(registers offsets could be different follow per stm32 platform).
Signed-off-by: NLudovic Barre <ludovic.barre@st.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

This patch adds GENERIC_IRQ_CHIP to stm32 exti
config.
Signed-off-by: NLudovic Barre <ludovic.barre@st.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

The Socionext Synquacer SoC has an external interrupt unit (EXIU)
that forwards a block of 32 configurable input lines to 32 adjacent
level-high type GICv3 SPIs.

The EXIU has per-interrupt level/edge and polarity controls, and
mask bits that keep the outgoing lines de-asserted, even though
the controller may still latch interrupt conditions that occur
while the line is masked.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>