License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 14:07:57 +00:00
|
|
|
# SPDX-License-Identifier: GPL-2.0
|
irqchip: add basic infrastructure
With the recent creation of the drivers/irqchip/ directory, it is
desirable to move irq controller drivers here. At the moment, the only
driver here is irq-bcm2835, the driver for the irq controller found in
the ARM BCM2835 SoC, present in Rasberry Pi systems. This irq
controller driver was exporting its initialization function and its
irq handling function through a header file in
<linux/irqchip/bcm2835.h>.
When proposing to also move another irq controller driver in
drivers/irqchip, Rob Herring raised the very valid point that moving
things to drivers/irqchip was good in order to remove more stuff from
arch/arm, but if it means adding gazillions of headers files in
include/linux/irqchip/, it would not be very nice.
So, upon the suggestion of Rob Herring and Arnd Bergmann, this commit
introduces a small infrastructure that defines a central
irqchip_init() function in drivers/irqchip/irqchip.c, which is meant
to be called as the ->init_irq() callback of ARM platforms. This
function calls of_irq_init() with an array of match strings and init
functions generated from a special linker section.
Note that the irq controller driver initialization function is
responsible for setting the global handle_arch_irq() variable, so that
ARM platforms no longer have to define the ->handle_irq field in their
DT_MACHINE structure.
A global header, <linux/irqchip.h> is also added to expose the single
irqchip_init() function to the reset of the kernel.
A further commit moves the BCM2835 irq controller driver to this new
small infrastructure, therefore removing the include/linux/irqchip/
directory.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
[rob.herring: reword commit message to reflect use of linker sections.]
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
2012-11-20 22:00:52 +00:00
|
|
|
obj-$(CONFIG_IRQCHIP) += irqchip.o
|
|
|
|
|
|
2016-02-19 15:22:44 +00:00
|
|
|
obj-$(CONFIG_ALPINE_MSI) += irq-alpine-msi.o
|
2016-01-23 12:57:47 +00:00
|
|
|
obj-$(CONFIG_ATH79) += irq-ath79-cpu.o
|
2016-01-23 12:57:46 +00:00
|
|
|
obj-$(CONFIG_ATH79) += irq-ath79-misc.o
|
2012-11-12 17:26:03 +00:00
|
|
|
obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2835.o
|
2015-08-06 23:00:33 +00:00
|
|
|
obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2836.o
|
2013-02-12 22:04:52 +00:00
|
|
|
obj-$(CONFIG_ARCH_EXYNOS) += exynos-combiner.o
|
2017-03-18 16:53:24 +00:00
|
|
|
obj-$(CONFIG_FARADAY_FTINTC010) += irq-ftintc010.o
|
2014-08-07 10:51:34 +00:00
|
|
|
obj-$(CONFIG_ARCH_HIP04) += irq-hip04.o
|
irqchip: Add LPC32xx interrupt controller driver
The change adds improved support of NXP LPC32xx MIC, SIC1 and SIC2
interrupt controllers.
This is a list of new features in comparison to the legacy driver:
* irq types are taken from device tree settings, no more need to
hardcode them,
* old driver is based on irq_domain_add_legacy, which causes problems
with handling MIC hardware interrupt 0 produced by SIC1,
* there is one driver for MIC, SIC1 and SIC2, no more need to handle
them separately, e.g. have two separate handlers for SIC1 and SIC2,
* the driver does not have any dependencies on hardcoded register
offsets,
* the driver is much simpler for maintenance,
* SPARSE_IRQS option is supported.
Legacy LPC32xx interrupt controller driver was broken since commit
76ba59f8366f ("genirq: Add irq_domain-aware core IRQ handler"), which
requires a private interrupt handler, otherwise any SIC1 generated
interrupt (mapped to MIC hwirq 0) breaks the kernel with the message
"unexpected IRQ trap at vector 00".
The change disables compilation of a legacy driver found at
arch/arm/mach-lpc32xx/irq.c, the file will be removed in a separate
commit.
Fixes: 76ba59f8366f ("genirq: Add irq_domain-aware core IRQ handler")
Tested-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2016-04-25 01:00:38 +00:00
|
|
|
obj-$(CONFIG_ARCH_LPC32XX) += irq-lpc32xx.o
|
2013-04-21 05:21:48 +00:00
|
|
|
obj-$(CONFIG_ARCH_MMP) += irq-mmp.o
|
2015-10-12 19:15:34 +00:00
|
|
|
obj-$(CONFIG_IRQ_MXS) += irq-mxs.o
|
2015-03-11 15:42:59 +00:00
|
|
|
obj-$(CONFIG_ARCH_TEGRA) += irq-tegra.o
|
2013-04-04 05:53:33 +00:00
|
|
|
obj-$(CONFIG_ARCH_S3C24XX) += irq-s3c24xx.o
|
2013-09-09 12:01:20 +00:00
|
|
|
obj-$(CONFIG_DW_APB_ICTL) += irq-dw-apb-ictl.o
|
2012-10-09 09:54:47 +00:00
|
|
|
obj-$(CONFIG_METAG) += irq-metag-ext.o
|
|
|
|
|
obj-$(CONFIG_METAG_PERFCOUNTER_IRQS) += irq-metag.o
|
2014-02-02 08:07:46 +00:00
|
|
|
obj-$(CONFIG_CLPS711X_IRQCHIP) += irq-clps711x.o
|
2017-10-30 12:38:35 +00:00
|
|
|
obj-$(CONFIG_OMPIC) += irq-ompic.o
|
2014-05-26 20:31:42 +00:00
|
|
|
obj-$(CONFIG_OR1K_PIC) += irq-or1k-pic.o
|
2013-06-06 16:27:09 +00:00
|
|
|
obj-$(CONFIG_ORION_IRQCHIP) += irq-orion.o
|
2014-09-15 21:15:02 +00:00
|
|
|
obj-$(CONFIG_OMAP_IRQCHIP) += irq-omap-intc.o
|
2013-03-24 09:10:04 +00:00
|
|
|
obj-$(CONFIG_ARCH_SUNXI) += irq-sun4i.o
|
2014-03-19 19:21:17 +00:00
|
|
|
obj-$(CONFIG_ARCH_SUNXI) += irq-sunxi-nmi.o
|
2012-11-12 17:26:03 +00:00
|
|
|
obj-$(CONFIG_ARCH_SPEAR3XX) += spear-shirq.o
|
2014-06-30 15:01:30 +00:00
|
|
|
obj-$(CONFIG_ARM_GIC) += irq-gic.o irq-gic-common.o
|
irqchip/gic: Add platform driver for non-root GICs that require RPM
Add a platform driver to support non-root GICs that require runtime
power-management. Currently, only non-root GICs are supported because
the functions, smp_cross_call() and set_handle_irq(), that need to
be called for a root controller are located in the __init section and
so cannot be called by the platform driver.
The GIC platform driver re-uses many functions from the existing GIC
driver including some functions to save and restore the GIC context
during power transitions. The functions for saving and restoring the
GIC context are currently only defined if CONFIG_CPU_PM is enabled and
to ensure that these functions are always defined when the platform
driver is enabled, a dependency on CONFIG_ARM_GIC_PM (which selects the
platform driver) has been added.
In order to re-use the private GIC initialisation code, a new public
function, gic_of_init_child(), has been added which calls various
private functions to initialise the GIC. This is different from the
existing gic_of_init() because it only supports non-root GICs (ie. does
not call smp_cross_call() is set_handle_irq()) and is not located in
the __init section (so can be used by platform drivers). Furthermore,
gic_of_init_child() dynamically allocates memory for the GIC chip data
which is also different from gic_of_init().
There is no specific suspend handling for GICs registered as platform
devices. Non-wakeup interrupts will be disabled by the kernel during
late suspend, however, this alone will not power down the GIC if
interrupts have been requested and not freed. Therefore, requestors of
non-wakeup interrupts will need to free them on entering suspend in
order to power-down the GIC.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2016-06-07 15:12:34 +00:00
|
|
|
obj-$(CONFIG_ARM_GIC_PM) += irq-gic-pm.o
|
2016-08-10 12:30:35 +00:00
|
|
|
obj-$(CONFIG_ARCH_REALVIEW) += irq-gic-realview.o
|
2014-11-25 18:47:22 +00:00
|
|
|
obj-$(CONFIG_ARM_GIC_V2M) += irq-gic-v2m.o
|
2014-06-30 15:01:31 +00:00
|
|
|
obj-$(CONFIG_ARM_GIC_V3) += irq-gic-v3.o irq-gic-common.o
|
2017-11-13 17:25:59 +00:00
|
|
|
obj-$(CONFIG_ARM_GIC_V3_ITS) += irq-gic-v3-its.o irq-gic-v3-its-platform-msi.o irq-gic-v4.o
|
|
|
|
|
obj-$(CONFIG_ARM_GIC_V3_ITS_PCI) += irq-gic-v3-its-pci-msi.o
|
irqchip: Add per-cpu interrupt partitioning library
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: Marc 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.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2016-04-11 08:57:53 +00:00
|
|
|
obj-$(CONFIG_PARTITION_PERCPU) += irq-partition-percpu.o
|
irqchip/mgigen: Add platform device driver for mbigen device
Mbigen means Message Based Interrupt Generator(MBIGEN).
Its a kind of interrupt controller that collects
the interrupts from external devices and generate msi interrupt.
Mbigen is applied to reduce the number of wire connected interrupts.
As the peripherals increasing, the interrupts lines needed is
increasing much, especially on the Arm64 server SOC.
Therefore, the interrupt pin in GIC is not enough to cover so
many peripherals.
Mbigen is designed to fix this problem.
Mbigen chip locates in ITS or outside of ITS.
Mbigen chip hardware structure shows as below:
mbigen chip
|---------------------|-------------------|
mgn_node0 mgn_node1 mgn_node2
| |-------| |-------|------|
dev1 dev1 dev2 dev1 dev3 dev4
Each mbigen chip contains several mbigen nodes.
External devices can connect to mbigen node through wire connecting way.
Because a mbigen node only can support 128 interrupt maximum, depends
on the interrupt lines number of devices, a device can connects to one
more mbigen nodes.
Also, several different devices can connect to a same mbigen node.
When devices triggered interrupt,mbigen chip detects and collects
the interrupts and generates the MBI interrupts by writing the ITS
Translator register.
To simplify mbigen driver,I used a new conception--mbigen device.
Each mbigen device is initialized as a platform device.
Mbigen device presents the parts(register, pin definition etc.) in
mbigen chip corresponding to a peripheral device.
So from software view, the structure likes below
mbigen chip
|---------------------|-----------------|
mbigen device1 mbigen device2 mbigen device3
| | |
dev1 dev2 dev3
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Ma Jun <majun258@huawei.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2015-12-17 11:56:35 +00:00
|
|
|
obj-$(CONFIG_HISILICON_IRQ_MBIGEN) += irq-mbigen.o
|
2013-06-26 07:18:48 +00:00
|
|
|
obj-$(CONFIG_ARM_NVIC) += irq-nvic.o
|
2012-10-27 22:25:26 +00:00
|
|
|
obj-$(CONFIG_ARM_VIC) += irq-vic.o
|
2016-02-10 14:46:56 +00:00
|
|
|
obj-$(CONFIG_ARMADA_370_XP_IRQ) += irq-armada-370-xp.o
|
2014-07-10 17:14:18 +00:00
|
|
|
obj-$(CONFIG_ATMEL_AIC_IRQ) += irq-atmel-aic-common.o irq-atmel-aic.o
|
|
|
|
|
obj-$(CONFIG_ATMEL_AIC5_IRQ) += irq-atmel-aic-common.o irq-atmel-aic5.o
|
2015-07-08 12:46:08 +00:00
|
|
|
obj-$(CONFIG_I8259) += irq-i8259.o
|
2013-04-22 14:43:50 +00:00
|
|
|
obj-$(CONFIG_IMGPDC_IRQ) += irq-imgpdc.o
|
2015-05-26 16:20:06 +00:00
|
|
|
obj-$(CONFIG_IRQ_MIPS_CPU) += irq-mips-cpu.o
|
2013-03-19 10:21:44 +00:00
|
|
|
obj-$(CONFIG_SIRF_IRQ) += irq-sirfsoc.o
|
2016-08-04 04:30:37 +00:00
|
|
|
obj-$(CONFIG_JCORE_AIC) += irq-jcore-aic.o
|
2013-02-18 14:28:34 +00:00
|
|
|
obj-$(CONFIG_RENESAS_INTC_IRQPIN) += irq-renesas-intc-irqpin.o
|
2013-02-27 08:15:01 +00:00
|
|
|
obj-$(CONFIG_RENESAS_IRQC) += irq-renesas-irqc.o
|
2012-11-21 03:21:40 +00:00
|
|
|
obj-$(CONFIG_VERSATILE_FPGA_IRQ) += irq-versatile-fpga.o
|
2013-12-05 06:12:17 +00:00
|
|
|
obj-$(CONFIG_ARCH_NSPIRE) += irq-zevio.o
|
2013-03-24 01:12:25 +00:00
|
|
|
obj-$(CONFIG_ARCH_VT8500) += irq-vt8500.o
|
2015-02-18 15:13:58 +00:00
|
|
|
obj-$(CONFIG_ST_IRQCHIP) += irq-st.o
|
2016-01-20 18:07:17 +00:00
|
|
|
obj-$(CONFIG_TANGO_IRQ) += irq-tango.o
|
2013-06-25 16:29:57 +00:00
|
|
|
obj-$(CONFIG_TB10X_IRQC) += irq-tb10x.o
|
2015-12-21 20:11:23 +00:00
|
|
|
obj-$(CONFIG_TS4800_IRQ) += irq-ts4800.o
|
2013-12-01 08:59:49 +00:00
|
|
|
obj-$(CONFIG_XTENSA) += irq-xtensa-pic.o
|
2013-12-01 08:04:57 +00:00
|
|
|
obj-$(CONFIG_XTENSA_MX) += irq-xtensa-mx.o
|
2016-11-14 12:13:45 +00:00
|
|
|
obj-$(CONFIG_XILINX_INTC) += irq-xilinx-intc.o
|
2013-12-03 10:27:23 +00:00
|
|
|
obj-$(CONFIG_IRQ_CROSSBAR) += irq-crossbar.o
|
2015-03-01 22:41:27 +00:00
|
|
|
obj-$(CONFIG_SOC_VF610) += irq-vf610-mscm-ir.o
|
2015-11-22 14:30:14 +00:00
|
|
|
obj-$(CONFIG_BCM6345_L1_IRQ) += irq-bcm6345-l1.o
|
IRQCHIP: Add new driver for BCM7038-style level 1 interrupt controllers
This is the main peripheral IRQ controller on the BCM7xxx MIPS chips;
it has the following characteristics:
- 64 to 160+ level IRQs
- Atomic set/clear registers
- Reasonably predictable register layout (N status words, then N
mask status words, then N mask set words, then N mask clear words)
- SMP affinity supported on most systems
- Typically connected to MIPS IRQ 2,3,2,3 on CPUs 0,1,2,3
This driver registers one IRQ domain and one IRQ chip to cover all
instances of the block. Up to 4 instances of the block may appear, as
it supports 4-way IRQ affinity on BCM7435.
The same block exists on the ARM BCM7xxx chips, but typically the ARM GIC
is used instead. So this driver is primarily intended for MIPS STB chips.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Cc: f.fainelli@gmail.com
Cc: jaedon.shin@gmail.com
Cc: abrestic@chromium.org
Cc: tglx@linutronix.de
Cc: jason@lakedaemon.net
Cc: jogo@openwrt.org
Cc: arnd@arndb.de
Cc: computersforpeace@gmail.com
Cc: linux-mips@linux-mips.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/8844/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-12-25 17:49:06 +00:00
|
|
|
obj-$(CONFIG_BCM7038_L1_IRQ) += irq-bcm7038-l1.o
|
2014-11-07 06:44:27 +00:00
|
|
|
obj-$(CONFIG_BCM7120_L2_IRQ) += irq-bcm7120-l2.o
|
|
|
|
|
obj-$(CONFIG_BRCMSTB_L2_IRQ) += irq-brcmstb-l2.o
|
2014-07-23 14:40:30 +00:00
|
|
|
obj-$(CONFIG_KEYSTONE_IRQ) += irq-keystone.o
|
2014-09-18 21:47:19 +00:00
|
|
|
obj-$(CONFIG_MIPS_GIC) += irq-mips-gic.o
|
2017-04-07 08:06:36 +00:00
|
|
|
obj-$(CONFIG_ARCH_MEDIATEK) += irq-mtk-sysirq.o irq-mtk-cirq.o
|
2015-01-15 10:34:00 +00:00
|
|
|
obj-$(CONFIG_ARCH_DIGICOLOR) += irq-digicolor.o
|
2015-05-09 17:30:47 +00:00
|
|
|
obj-$(CONFIG_RENESAS_H8300H_INTC) += irq-renesas-h8300h.o
|
|
|
|
|
obj-$(CONFIG_RENESAS_H8S_INTC) += irq-renesas-h8s.o
|
2015-05-19 15:17:09 +00:00
|
|
|
obj-$(CONFIG_ARCH_SA1100) += irq-sa11x0.o
|
2015-05-24 15:11:31 +00:00
|
|
|
obj-$(CONFIG_INGENIC_IRQ) += irq-ingenic.o
|
2015-08-24 19:04:15 +00:00
|
|
|
obj-$(CONFIG_IMX_GPCV2) += irq-imx-gpcv2.o
|
2016-01-14 01:15:35 +00:00
|
|
|
obj-$(CONFIG_PIC32_EVIC) += irq-pic32-evic.o
|
2017-06-21 13:29:14 +00:00
|
|
|
obj-$(CONFIG_MVEBU_GICP) += irq-mvebu-gicp.o
|
2017-06-21 13:29:15 +00:00
|
|
|
obj-$(CONFIG_MVEBU_ICU) += irq-mvebu-icu.o
|
2016-02-19 13:34:43 +00:00
|
|
|
obj-$(CONFIG_MVEBU_ODMI) += irq-mvebu-odmi.o
|
2016-08-05 14:55:19 +00:00
|
|
|
obj-$(CONFIG_MVEBU_PIC) += irq-mvebu-pic.o
|
2016-03-23 11:08:20 +00:00
|
|
|
obj-$(CONFIG_LS_SCFG_MSI) += irq-ls-scfg-msi.o
|
2015-10-28 22:26:22 +00:00
|
|
|
obj-$(CONFIG_EZNPS_GIC) += irq-eznps.o
|
2017-06-03 01:29:49 +00:00
|
|
|
obj-$(CONFIG_ARCH_ASPEED) += irq-aspeed-vic.o irq-aspeed-i2c-ic.o
|
2016-09-20 16:00:57 +00:00
|
|
|
obj-$(CONFIG_STM32_EXTI) += irq-stm32-exti.o
|
2017-02-02 23:23:59 +00:00
|
|
|
obj-$(CONFIG_QCOM_IRQ_COMBINER) += qcom-irq-combiner.o
|
2017-08-23 01:31:47 +00:00
|
|
|
obj-$(CONFIG_IRQ_UNIPHIER_AIDET) += irq-uniphier-aidet.o
|
2017-11-06 18:34:37 +00:00
|
|
|
obj-$(CONFIG_ARCH_SYNQUACER) += irq-sni-exiu.o
|
2017-09-18 13:46:10 +00:00
|
|
|
obj-$(CONFIG_MESON_IRQ_GPIO) += irq-meson-gpio.o
|
2017-12-29 15:41:46 +00:00
|
|
|
obj-$(CONFIG_GOLDFISH_PIC) += irq-goldfish-pic.o
|
