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 17:07:57 +03: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-21 02:00:52 +04:00
|
|
|
obj-$(CONFIG_IRQCHIP) += irqchip.o
|
|
|
|
|
|
2019-06-10 11:34:43 +03:00
|
|
|
obj-$(CONFIG_AL_FIC) += irq-al-fic.o
|
2016-02-19 18:22:44 +03:00
|
|
|
obj-$(CONFIG_ALPINE_MSI) += irq-alpine-msi.o
|
2016-01-23 15:57:47 +03:00
|
|
|
obj-$(CONFIG_ATH79) += irq-ath79-cpu.o
|
2016-01-23 15:57:46 +03:00
|
|
|
obj-$(CONFIG_ATH79) += irq-ath79-misc.o
|
2012-11-12 21:26:03 +04:00
|
|
|
obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2835.o
|
2015-08-07 02:00:33 +03:00
|
|
|
obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2836.o
|
2020-09-14 23:27:18 +03:00
|
|
|
obj-$(CONFIG_ARCH_ACTIONS) += irq-owl-sirq.o
|
2019-02-14 17:52:16 +03:00
|
|
|
obj-$(CONFIG_DAVINCI_AINTC) += irq-davinci-aintc.o
|
2019-02-14 17:52:30 +03:00
|
|
|
obj-$(CONFIG_DAVINCI_CP_INTC) += irq-davinci-cp-intc.o
|
2019-12-25 00:11:07 +03:00
|
|
|
obj-$(CONFIG_EXYNOS_IRQ_COMBINER) += exynos-combiner.o
|
2017-03-18 19:53:24 +03:00
|
|
|
obj-$(CONFIG_FARADAY_FTINTC010) += irq-ftintc010.o
|
2014-08-07 14:51:34 +04: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 04:00:38 +03:00
|
|
|
obj-$(CONFIG_ARCH_LPC32XX) += irq-lpc32xx.o
|
2013-04-21 09:21:48 +04:00
|
|
|
obj-$(CONFIG_ARCH_MMP) += irq-mmp.o
|
2015-10-12 22:15:34 +03:00
|
|
|
obj-$(CONFIG_IRQ_MXS) += irq-mxs.o
|
2015-03-11 18:42:59 +03:00
|
|
|
obj-$(CONFIG_ARCH_TEGRA) += irq-tegra.o
|
2013-09-09 16:01:20 +04:00
|
|
|
obj-$(CONFIG_DW_APB_ICTL) += irq-dw-apb-ictl.o
|
2014-02-02 12:07:46 +04:00
|
|
|
obj-$(CONFIG_CLPS711X_IRQCHIP) += irq-clps711x.o
|
2017-10-30 15:38:35 +03:00
|
|
|
obj-$(CONFIG_OMPIC) += irq-ompic.o
|
2014-05-27 00:31:42 +04:00
|
|
|
obj-$(CONFIG_OR1K_PIC) += irq-or1k-pic.o
|
2013-06-06 20:27:09 +04:00
|
|
|
obj-$(CONFIG_ORION_IRQCHIP) += irq-orion.o
|
2014-09-16 01:15:02 +04:00
|
|
|
obj-$(CONFIG_OMAP_IRQCHIP) += irq-omap-intc.o
|
2013-03-24 13:10:04 +04:00
|
|
|
obj-$(CONFIG_ARCH_SUNXI) += irq-sun4i.o
|
irqchip/sun6i-r: Use a stacked irqchip driver
The R_INTC in the A31 and newer sun8i/sun50i SoCs is more similar to the
original sun4i interrupt controller than the sun7i/sun9i NMI controller.
It is used for two distinct purposes:
- To control the trigger, latch, and mask for the NMI input pin
- To provide the interrupt input for the ARISC coprocessor
As this interrupt controller is not documented, information about it
comes from vendor-provided firmware blobs and from experimentation.
Differences from the sun4i interrupt controller appear to be:
- It only has one or two registers of each kind (max 32 or 64 IRQs)
- Multiplexing logic is added to support additional inputs
- There is no FIQ-related logic
- There is no interrupt priority logic
In order to fulfill its two purposes, this hardware block combines four
types of IRQs. First, the NMI pin is routed to the "IRQ 0" input on this
chip, with a trigger type controlled by the NMI_CTRL_REG. The "IRQ 0
pending" output from this chip, if enabled, is then routed to a SPI IRQ
input on the GIC. In other words, bit 0 of IRQ_ENABLE_REG *does* affect
the NMI IRQ seen at the GIC.
The NMI is followed by a contiguous block of 15 "direct" (my name for
them) IRQ inputs that are connected in parallel to both R_INTC and the
GIC. Or in other words, these bits of IRQ_ENABLE_REG *do not* affect the
IRQs seen at the GIC.
Following the direct IRQs are the ARISC's copy of banked IRQs for shared
peripherals. These are not relevant to Linux. The remaining IRQs are
connected to a multiplexer and provide access to the first (up to) 128
SPIs from the ARISC. This range of SPIs overlaps with the direct IRQs.
Because of the 1:1 correspondence between R_INTC and GIC inputs, this is
a perfect scenario for using a stacked irqchip driver. We want to hook
into setting the NMI trigger type, but not actually handle any IRQ here.
To allow access to all multiplexed IRQs, this driver requires a new
binding where the interrupt number matches the GIC interrupt number.
(This moves the NMI from number 0 to 32 or 96, depending on the SoC.)
For simplicity, copy the three-cell GIC binding; this disambiguates
interrupt 0 in the old binding (the NMI) from interrupt 0 in the new
binding (SPI 0) by the number of cells.
Since R_INTC is in the always-on power domain, and its output is visible
to the power management coprocessor, a stacked irqchip driver provides a
simple way to add wakeup support to any of its IRQs. That is the next
patch; for now, just the NMI is moved over.
This commit mostly reverts commit 173bda53b340 ("irqchip/sunxi-nmi:
Support sun6i-a31-r-intc compatible").
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210118055040.21910-4-samuel@sholland.org
2021-01-18 08:50:33 +03:00
|
|
|
obj-$(CONFIG_ARCH_SUNXI) += irq-sun6i-r.o
|
2014-03-19 23:21:17 +04:00
|
|
|
obj-$(CONFIG_ARCH_SUNXI) += irq-sunxi-nmi.o
|
2012-11-12 21:26:03 +04:00
|
|
|
obj-$(CONFIG_ARCH_SPEAR3XX) += spear-shirq.o
|
2014-06-30 19:01:30 +04: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 18:12:34 +03:00
|
|
|
obj-$(CONFIG_ARM_GIC_PM) += irq-gic-pm.o
|
2016-08-10 15:30:35 +03:00
|
|
|
obj-$(CONFIG_ARCH_REALVIEW) += irq-gic-realview.o
|
2014-11-25 21:47:22 +03:00
|
|
|
obj-$(CONFIG_ARM_GIC_V2M) += irq-gic-v2m.o
|
2018-05-08 15:14:36 +03:00
|
|
|
obj-$(CONFIG_ARM_GIC_V3) += irq-gic-v3.o irq-gic-v3-mbi.o irq-gic-common.o
|
2017-11-13 20:25:59 +03: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
|
2018-02-05 17:07:43 +03:00
|
|
|
obj-$(CONFIG_ARM_GIC_V3_ITS_FSL_MC) += irq-gic-v3-its-fsl-mc-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 11:57:53 +03: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 14:56:35 +03:00
|
|
|
obj-$(CONFIG_HISILICON_IRQ_MBIGEN) += irq-mbigen.o
|
2013-06-26 11:18:48 +04:00
|
|
|
obj-$(CONFIG_ARM_NVIC) += irq-nvic.o
|
2012-10-28 02:25:26 +04:00
|
|
|
obj-$(CONFIG_ARM_VIC) += irq-vic.o
|
2016-02-10 17:46:56 +03:00
|
|
|
obj-$(CONFIG_ARMADA_370_XP_IRQ) += irq-armada-370-xp.o
|
2014-07-10 21:14:18 +04: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 15:46:08 +03:00
|
|
|
obj-$(CONFIG_I8259) += irq-i8259.o
|
2013-04-22 18:43:50 +04:00
|
|
|
obj-$(CONFIG_IMGPDC_IRQ) += irq-imgpdc.o
|
2015-05-26 19:20:06 +03:00
|
|
|
obj-$(CONFIG_IRQ_MIPS_CPU) += irq-mips-cpu.o
|
2019-01-25 18:41:25 +03:00
|
|
|
obj-$(CONFIG_IXP4XX_IRQ) += irq-ixp4xx.o
|
2016-08-04 07:30:37 +03:00
|
|
|
obj-$(CONFIG_JCORE_AIC) += irq-jcore-aic.o
|
2018-12-10 20:35:43 +03:00
|
|
|
obj-$(CONFIG_RDA_INTC) += irq-rda-intc.o
|
2013-02-18 18:28:34 +04:00
|
|
|
obj-$(CONFIG_RENESAS_INTC_IRQPIN) += irq-renesas-intc-irqpin.o
|
2013-02-27 12:15:01 +04:00
|
|
|
obj-$(CONFIG_RENESAS_IRQC) += irq-renesas-irqc.o
|
2019-05-27 15:17:11 +03:00
|
|
|
obj-$(CONFIG_RENESAS_RZA1_IRQC) += irq-renesas-rza1.o
|
2012-11-21 07:21:40 +04:00
|
|
|
obj-$(CONFIG_VERSATILE_FPGA_IRQ) += irq-versatile-fpga.o
|
2013-12-05 10:12:17 +04:00
|
|
|
obj-$(CONFIG_ARCH_NSPIRE) += irq-zevio.o
|
2013-03-24 05:12:25 +04:00
|
|
|
obj-$(CONFIG_ARCH_VT8500) += irq-vt8500.o
|
2015-02-18 18:13:58 +03:00
|
|
|
obj-$(CONFIG_ST_IRQCHIP) += irq-st.o
|
2013-06-25 20:29:57 +04:00
|
|
|
obj-$(CONFIG_TB10X_IRQC) += irq-tb10x.o
|
2015-12-21 23:11:23 +03:00
|
|
|
obj-$(CONFIG_TS4800_IRQ) += irq-ts4800.o
|
2013-12-01 12:59:49 +04:00
|
|
|
obj-$(CONFIG_XTENSA) += irq-xtensa-pic.o
|
2013-12-01 12:04:57 +04:00
|
|
|
obj-$(CONFIG_XTENSA_MX) += irq-xtensa-mx.o
|
2016-11-14 15:13:45 +03:00
|
|
|
obj-$(CONFIG_XILINX_INTC) += irq-xilinx-intc.o
|
2013-12-03 14:27:23 +04:00
|
|
|
obj-$(CONFIG_IRQ_CROSSBAR) += irq-crossbar.o
|
2015-03-02 01:41:27 +03:00
|
|
|
obj-$(CONFIG_SOC_VF610) += irq-vf610-mscm-ir.o
|
2015-11-22 17:30:14 +03: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 20:49:06 +03:00
|
|
|
obj-$(CONFIG_BCM7038_L1_IRQ) += irq-bcm7038-l1.o
|
2014-11-07 09:44:27 +03:00
|
|
|
obj-$(CONFIG_BCM7120_L2_IRQ) += irq-bcm7120-l2.o
|
|
|
|
|
obj-$(CONFIG_BRCMSTB_L2_IRQ) += irq-brcmstb-l2.o
|
2014-07-23 18:40:30 +04:00
|
|
|
obj-$(CONFIG_KEYSTONE_IRQ) += irq-keystone.o
|
2014-09-19 01:47:19 +04:00
|
|
|
obj-$(CONFIG_MIPS_GIC) += irq-mips-gic.o
|
2017-04-07 11:06:36 +03:00
|
|
|
obj-$(CONFIG_ARCH_MEDIATEK) += irq-mtk-sysirq.o irq-mtk-cirq.o
|
2015-01-15 13:34:00 +03:00
|
|
|
obj-$(CONFIG_ARCH_DIGICOLOR) += irq-digicolor.o
|
2015-05-09 20:30:47 +03:00
|
|
|
obj-$(CONFIG_RENESAS_H8300H_INTC) += irq-renesas-h8300h.o
|
|
|
|
|
obj-$(CONFIG_RENESAS_H8S_INTC) += irq-renesas-h8s.o
|
2015-05-19 18:17:09 +03:00
|
|
|
obj-$(CONFIG_ARCH_SA1100) += irq-sa11x0.o
|
2015-05-24 18:11:31 +03:00
|
|
|
obj-$(CONFIG_INGENIC_IRQ) += irq-ingenic.o
|
2019-07-24 20:16:08 +03:00
|
|
|
obj-$(CONFIG_INGENIC_TCU_IRQ) += irq-ingenic-tcu.o
|
2015-08-24 22:04:15 +03:00
|
|
|
obj-$(CONFIG_IMX_GPCV2) += irq-imx-gpcv2.o
|
2016-01-14 04:15:35 +03:00
|
|
|
obj-$(CONFIG_PIC32_EVIC) += irq-pic32-evic.o
|
2018-03-22 18:15:24 +03:00
|
|
|
obj-$(CONFIG_MSCC_OCELOT_IRQ) += irq-mscc-ocelot.o
|
2017-06-21 16:29:14 +03:00
|
|
|
obj-$(CONFIG_MVEBU_GICP) += irq-mvebu-gicp.o
|
2017-06-21 16:29:15 +03:00
|
|
|
obj-$(CONFIG_MVEBU_ICU) += irq-mvebu-icu.o
|
2016-02-19 16:34:43 +03:00
|
|
|
obj-$(CONFIG_MVEBU_ODMI) += irq-mvebu-odmi.o
|
2016-08-05 17:55:19 +03:00
|
|
|
obj-$(CONFIG_MVEBU_PIC) += irq-mvebu-pic.o
|
2018-10-01 17:13:51 +03:00
|
|
|
obj-$(CONFIG_MVEBU_SEI) += irq-mvebu-sei.o
|
irqchip: Add support for Layerscape external interrupt lines
The LS1021A allows inverting the polarity of six interrupt lines
IRQ[0:5] via the scfg_intpcr register, effectively allowing
IRQ_TYPE_LEVEL_LOW and IRQ_TYPE_EDGE_FALLING for those. We just need to
check the type, set the relevant bit in INTPCR accordingly, and fixup
the type argument before calling the GIC's irq_set_type.
In fact, the power-on-reset value of the INTPCR register on the LS1021A
is so that all six lines have their polarity inverted. Hence any
hardware connected to those lines is unusable without this: If the line
is indeed active low, the generic GIC code will reject an irq spec with
IRQ_TYPE_LEVEL_LOW, while if the line is active high, we must obviously
disable the polarity inversion (writing 0 to the relevant bit) before
unmasking the interrupt.
Some other Layerscape SOCs (LS1043A, LS1046A) have a similar feature,
just with a different number of external interrupt lines (and a
different POR value for the INTPCR register). This driver should be
prepared for supporting those by properly filling out the device tree
node. I have the reference manuals for all three boards, but I've only
tested the driver on an LS1021A.
Unfortunately, the Kconfig symbol ARCH_LAYERSCAPE only exists on
arm64, so do as is done for irq-ls-scfg-msi.c: introduce a new symbol
which is set when either ARCH_LAYERSCAPE or SOC_LS1021A is set.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20191107122115.6244-3-linux@rasmusvillemoes.dk
2019-11-07 15:21:15 +03:00
|
|
|
obj-$(CONFIG_LS_EXTIRQ) += irq-ls-extirq.o
|
2016-03-23 14:08:20 +03:00
|
|
|
obj-$(CONFIG_LS_SCFG_MSI) += irq-ls-scfg-msi.o
|
2020-01-16 00:29:40 +03:00
|
|
|
obj-$(CONFIG_ARCH_ASPEED) += irq-aspeed-vic.o irq-aspeed-i2c-ic.o irq-aspeed-scu-ic.o
|
2016-09-20 19:00:57 +03:00
|
|
|
obj-$(CONFIG_STM32_EXTI) += irq-stm32-exti.o
|
2017-02-03 02:23:59 +03:00
|
|
|
obj-$(CONFIG_QCOM_IRQ_COMBINER) += qcom-irq-combiner.o
|
2017-08-23 04:31:47 +03:00
|
|
|
obj-$(CONFIG_IRQ_UNIPHIER_AIDET) += irq-uniphier-aidet.o
|
2017-11-06 21:34:37 +03:00
|
|
|
obj-$(CONFIG_ARCH_SYNQUACER) += irq-sni-exiu.o
|
2017-09-18 16:46:10 +03:00
|
|
|
obj-$(CONFIG_MESON_IRQ_GPIO) += irq-meson-gpio.o
|
2017-12-29 18:41:46 +03:00
|
|
|
obj-$(CONFIG_GOLDFISH_PIC) += irq-goldfish-pic.o
|
2017-10-25 10:42:51 +03:00
|
|
|
obj-$(CONFIG_NDS32) += irq-ativic32.o
|
2018-02-28 20:27:29 +03:00
|
|
|
obj-$(CONFIG_QCOM_PDC) += qcom-pdc.o
|
2018-09-16 10:57:14 +03:00
|
|
|
obj-$(CONFIG_CSKY_MPINTC) += irq-csky-mpintc.o
|
2018-09-16 10:57:14 +03:00
|
|
|
obj-$(CONFIG_CSKY_APB_INTC) += irq-csky-apb-intc.o
|
2020-06-01 12:15:40 +03:00
|
|
|
obj-$(CONFIG_RISCV_INTC) += irq-riscv-intc.o
|
2018-07-26 17:27:00 +03:00
|
|
|
obj-$(CONFIG_SIFIVE_PLIC) += irq-sifive-plic.o
|
2018-12-17 17:01:20 +03:00
|
|
|
obj-$(CONFIG_IMX_IRQSTEER) += irq-imx-irqsteer.o
|
2020-01-17 09:10:10 +03:00
|
|
|
obj-$(CONFIG_IMX_INTMUX) += irq-imx-intmux.o
|
2018-12-14 17:44:16 +03:00
|
|
|
obj-$(CONFIG_MADERA_IRQ) += irq-madera.o
|
2019-02-01 09:22:35 +03:00
|
|
|
obj-$(CONFIG_LS1X_IRQ) += irq-ls1x.o
|
2019-04-30 13:12:25 +03:00
|
|
|
obj-$(CONFIG_TI_SCI_INTR_IRQCHIP) += irq-ti-sci-intr.o
|
2019-04-30 13:12:27 +03:00
|
|
|
obj-$(CONFIG_TI_SCI_INTA_IRQCHIP) += irq-ti-sci-inta.o
|
2020-09-16 19:36:03 +03:00
|
|
|
obj-$(CONFIG_TI_PRUSS_INTC) += irq-pruss-intc.o
|
2020-03-25 06:54:54 +03:00
|
|
|
obj-$(CONFIG_LOONGSON_LIOINTC) += irq-loongson-liointc.o
|
2020-03-25 06:54:57 +03:00
|
|
|
obj-$(CONFIG_LOONGSON_HTPIC) += irq-loongson-htpic.o
|
2020-05-28 18:27:49 +03:00
|
|
|
obj-$(CONFIG_LOONGSON_HTVEC) += irq-loongson-htvec.o
|
2020-05-28 18:27:51 +03:00
|
|
|
obj-$(CONFIG_LOONGSON_PCH_PIC) += irq-loongson-pch-pic.o
|
2020-05-28 18:27:53 +03:00
|
|
|
obj-$(CONFIG_LOONGSON_PCH_MSI) += irq-loongson-pch-msi.o
|
2020-09-02 09:33:43 +03:00
|
|
|
obj-$(CONFIG_MST_IRQ) += irq-mst-intc.o
|
2020-09-15 00:43:32 +03:00
|
|
|
obj-$(CONFIG_SL28CPLD_INTC) += irq-sl28cpld.o
|
2021-01-22 23:42:24 +03:00
|
|
|
obj-$(CONFIG_MACH_REALTEK_RTL) += irq-realtek-rtl.o
|
2021-04-06 15:09:17 +03:00
|
|
|
obj-$(CONFIG_WPCM450_AIC) += irq-wpcm450-aic.o
|
2021-04-22 17:53:28 +03:00
|
|
|
obj-$(CONFIG_IRQ_IDT3243X) += irq-idt3243x.o
|
2021-01-21 02:55:15 +03:00
|
|
|
obj-$(CONFIG_APPLE_AIC) += irq-apple-aic.o
|
