08 Feb, 2020
6 commits
-
V{PEND,PROP}BASER registers are actually located in VLPI_base frame
of the *redistributor*. Rename their accessors to reflect this fact.No functional changes.
Signed-off-by: Zenghui Yu
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/20200206075711.1275-7-yuzenghui@huawei.com -
"ITS virtual pending table not cleaning" is already complained inside
its_clear_vpend_valid(), there's no need to trigger a WARN_ON again.Signed-off-by: Zenghui Yu
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/20200206075711.1275-6-yuzenghui@huawei.com -
The variable 'tmp' in inherit_vpe_l1_table_from_rd() is actually
not needed, drop it.Signed-off-by: Zenghui Yu
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/20200206075711.1275-5-yuzenghui@huawei.com -
In GICv4, we will ensure that level2 vPE table memory is allocated
for the specified vpe_id on all v4 ITS, in its_alloc_vpe_table().
This still works well for the typical GICv4.1 implementation, where
the new vPE table is shared between the ITSs and the RDs.To make it explicit, let us introduce allocate_vpe_l2_table() to
make sure that the L2 tables are allocated on all v4.1 RDs. We're
likely not need to allocate memory in it because the vPE table is
shared and (L2 table is) already allocated at ITS level, except
for the case where the ITS doesn't share anything (say SVPET == 0,
practically unlikely but architecturally allowed).The implementation of allocate_vpe_l2_table() is mostly copied from
its_alloc_table_entry().Signed-off-by: Zenghui Yu
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/20200206075711.1275-4-yuzenghui@huawei.com -
Currently, we will not set vpe_l1_page for the current RD if we can
inherit the vPE configuration table from another RD (or ITS), which
results in an inconsistency between RDs within the same CommonLPIAff
group.Let's rename it to vpe_l1_base to indicate the base address of the
vPE configuration table of this RD, and set it properly for *all*
v4.1 redistributors.Signed-off-by: Zenghui Yu
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/20200206075711.1275-3-yuzenghui@huawei.com -
The Size field of GICv4.1 VPROPBASER register indicates number of
pages minus one and together Page_Size and Size control the vPEID
width. Let's respect this requirement of the architecture.Signed-off-by: Zenghui Yu
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/20200206075711.1275-2-yuzenghui@huawei.com
03 Feb, 2020
1 commit
-
It looks like an obvious mistake to use its_mapc_cmd descriptor when
building the INVALL command block. It so far worked by luck because
both its_mapc_cmd.col and its_invall_cmd.col sit at the same offset of
the ITS command descriptor, but we should not rely on it.Fixes: cc2d3216f53c ("irqchip: GICv3: ITS command queue")
Signed-off-by: Zenghui Yu
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/20191202071021.1251-1-yuzenghui@huawei.com
29 Jan, 2020
1 commit
-
Fixes to Kconfig help text:
- spell out "hardware"
- fix verb usageSigned-off-by: Randy Dunlap
Signed-off-by: Marc Zyngier
Acked-by: Guo Ren
Link: https://lore.kernel.org/r/d44baeee-cceb-7c02-7249-e6b4817f0847@infradead.org
28 Jan, 2020
1 commit
-
We currently allocate redistributor region structures for
individual redistributors when ACPI doesn't present us with
compact MMIO regions covering multiple redistributors.It turns out that we allocate these structures even when
the redistributor is flagged as disabled by ACPI. It works
fine until someone actually tries to tarse one of these
structures, and access the corresponding MMIO region.Instead, track the number of enabled redistributors, and
only allocate what is required. This makes sure that there
is no invalid data to misuse.Signed-off-by: Marc Zyngier
Reported-by: Heyi Guo
Tested-by: Heyi Guo
Link: https://lore.kernel.org/r/20191216062745.63397-1-guoheyi@huawei.com
22 Jan, 2020
14 commits
-
Just like for INVALL, GICv4.1 has grown a VPE-aware INVLPI register.
Let's plumb it in and make use of the DirectLPI code in that case.Signed-off-by: Marc Zyngier
Reviewed-by: Zenghui Yu
Link: https://lore.kernel.org/r/20191224111055.11836-16-maz@kernel.org -
Since GICv4.1 gives us a per-VPE doorbell, avoid programming anything
else on VMOVI/VMAPI/VMAPTI and on any other action that would have
otherwise resulted in a per-VLPI doorbell to be programmed.Signed-off-by: Marc Zyngier
Reviewed-by: Zenghui Yu
Link: https://lore.kernel.org/r/20191224111055.11836-15-maz@kernel.org -
GICv4.1 redistributors have a VPE-aware INVALL register. Progress!
We can now emulate a guest-requested INVALL without emiting a
VINVALL command.Signed-off-by: Marc Zyngier
Reviewed-by: Zenghui Yu
Link: https://lore.kernel.org/r/20191224111055.11836-14-maz@kernel.org -
When descheduling a VPE, special care must be taken to tell the GIC
about whether we want to receive a doorbell or not. This is a
major improvement on GICv4.0, where the doorbell had to be separately
enabled/disabled.Signed-off-by: Marc Zyngier
Reviewed-by: Zenghui Yu
Link: https://lore.kernel.org/r/20191224111055.11836-13-maz@kernel.org -
Making a VPE resident on GICv4.1 is pretty simple, as it is just a
single write to the local redistributor. We just need extra information
about which groups to enable, which the KVM code will have to provide.Signed-off-by: Marc Zyngier
Reviewed-by: Zenghui Yu
Link: https://lore.kernel.org/r/20191224111055.11836-12-maz@kernel.org -
masking/unmasking doorbells on GICv4.1 relies on a new INVDB command,
which broadcasts the invalidation to all RDs.Implement the new command as well as the masking callbacks, and plug
the whole thing into the v4.1 VPE irqchip.Signed-off-by: Marc Zyngier
Reviewed-by: Zenghui Yu
Link: https://lore.kernel.org/r/20191224111055.11836-11-maz@kernel.org -
Just like for GICv4.0, each VPE has its own doorbell interrupt, and
thus an irqchip that manages them. Since the doorbell management is
quite different on GICv4.1, let's introduce an almost empty irqchip
the will get populated over the next new patches.Signed-off-by: Marc Zyngier
Reviewed-by: Zenghui Yu
Link: https://lore.kernel.org/r/20191224111055.11836-10-maz@kernel.org -
With GICv4.1, VMOVP is extended to allow a default doorbell to be
specified, as well as a validity bit for this doorbell. As an added
bonus, VMOVP isn't required anymore of moving a VPE between
redistributors that share the same affinity.Let's add this support to the VMOVP builder, and make sure we don't
issue the command if we don't really need to.Signed-off-by: Marc Zyngier
Reviewed-by: Zenghui Yu
Link: https://lore.kernel.org/r/20191224111055.11836-9-maz@kernel.org -
The infamous VPE proxy device isn't used with GICv4.1 because:
- we can invalidate any LPI from the DirectLPI MMIO interface
- the ITS and redistributors understand the life cycle of
the doorbell, so we don't need to enable/disable it all
the timeSo let's escape early from the proxy related functions.
Signed-off-by: Marc Zyngier
Reviewed-by: Zenghui Yu
Link: https://lore.kernel.org/r/20191224111055.11836-8-maz@kernel.org -
The ITS VMAPP command gains some new fields with GICv4.1:
- a default doorbell, which allows a single doorbell to be used for
all the VLPIs routed to a given VPE
- a pointer to the configuration table (instead of having it in a register
that gets context switched)
- a flag indicating whether this is the first map or the last unmap for
this particular VPE
- a flag indicating whether the pending table is known to be zeroed, or notPlumb in the new fields in the VMAPP builder, and add the map/unmap
refcounting so that the ITS can do the right thing.Signed-off-by: Marc Zyngier
Reviewed-by: Zenghui Yu
Link: https://lore.kernel.org/r/20191224111055.11836-7-maz@kernel.org -
GICv4.1 defines a new VPE table that is potentially shared between
both the ITSs and the redistributors, following complicated affinity
rules.To make things more confusing, the programming of this table at
the redistributor level is reusing the GICv4.0 GICR_VPROPBASER register
for something completely different.The code flow is somewhat complexified by the need to respect the
affinities required by the HW, meaning that tables can either be
inherited from a previously discovered ITS or redistributor.Signed-off-by: Marc Zyngier
Reviewed-by: Zenghui Yu
Link: https://lore.kernel.org/r/20191224111055.11836-6-maz@kernel.org -
While GICv4.0 mandates 16 bit worth of VPEIDs, GICv4.1 allows smaller
implementations to be built. Add the required glue to dynamically
compute the limit.Signed-off-by: Marc Zyngier
Reviewed-by: Zenghui Yu
Link: https://lore.kernel.org/r/20191224111055.11836-3-maz@kernel.org -
GICv4.1 supports the RVPEID ("Residency per vPE ID"), which allows for
a much efficient way of making virtual CPUs resident (to allow direct
injection of interrupts).The functionnality needs to be discovered on each and every redistributor
in the system, and disabled if the settings are inconsistent.Signed-off-by: Marc Zyngier
Reviewed-by: Zenghui Yu
Link: https://lore.kernel.org/r/20191224111055.11836-2-maz@kernel.org -
When updating an LPI configuration, get_vlpi_map() may be passed a
irq_data structure relative to an ITS domain (the normal case) or one
that is relative to the core GICv3 domain in the case of a GICv4
doorbell.In the latter case, special care must be take not to dereference
the irq_chip data as an its_dev structure, as that isn't what is
stored there. Instead, check *first* whether the IRQ is forwarded
to a vcpu, and only then try to obtain the vlpi mapping.Fixes: c1d4d5cd203c ("irqchip/gic-v3-its: Add its_vlpi_map helpers")
Signed-off-by: Marc Zyngier
Reported-by: Zenghui Yu
Link: https://lore.kernel.org/r/20200122085609.658-1-yuzenghui@huawei.com
21 Jan, 2020
11 commits
-
Fix a memory leak reported by kmemleak:
unreferenced object 0xffff000bc6f50e80 (size 128):
comm "kworker/23:2", pid 201, jiffies 4294894947 (age 942.132s)
hex dump (first 32 bytes):
00 00 00 00 41 00 00 00 86 c0 03 00 00 00 00 00 ....A...........
00 a0 b2 c6 0b 00 ff ff 40 51 fd 10 00 80 ff ff ........@Q......
backtrace:
[] kmem_cache_alloc_trace+0x1a4/0x320
[] irq_domain_push_irq+0x7c/0x188
[] thunderx_gpio_probe+0x3ac/0x438
[] pci_device_probe+0xe4/0x198
[] really_probe+0xdc/0x320
[] driver_probe_device+0x5c/0xf0
[] __device_attach_driver+0x88/0xc0
[] bus_for_each_drv+0x7c/0xc8
[] __device_attach+0xe4/0x140
[] device_initial_probe+0x18/0x20
[] bus_probe_device+0x98/0xa0
[] deferred_probe_work_func+0x74/0xa8
[] process_one_work+0x1c8/0x470
[] worker_thread+0x1f8/0x428
[] kthread+0xfc/0x128
[] ret_from_fork+0x10/0x18Fixes: 495c38d3001f ("irqdomain: Add irq_domain_{push,pop}_irq() functions")
Signed-off-by: Kevin Hao
Signed-off-by: Marc Zyngier
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200120043547.22271-1-haokexin@gmail.com -
The Interrupt Multiplexer (INTMUX) expands the number of peripherals
that can interrupt the core:
* The INTMUX has 8 channels that are assigned to 8 NVIC interrupt slots.
* Each INTMUX channel can receive up to 32 interrupt sources and has 1
interrupt output.
* The INTMUX routes the interrupt sources to the interrupt outputs.Signed-off-by: Shengjiu Wang
Signed-off-by: Joakim Zhang
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/20200117060653.27485-3-qiangqing.zhang@nxp.com -
This patch adds the DT bindings for the NXP INTMUX interrupt multiplexer
for i.MX8 family SoCs.Signed-off-by: Joakim Zhang
Signed-off-by: Marc Zyngier
Reviewed-by: Rob Herring
Link: https://lore.kernel.org/r/20200117060653.27485-2-qiangqing.zhang@nxp.com -
This patch is written to clean up dependency of ARCH_EXYNOS
Not all exynos device have IRQ_COMBINER, especially aarch64 EXYNOS
but it is built for all exynos devices.
Thus add the config for EXYNOS_IRQ_COMBINER
remove direct dependency between ARCH_EXYNOS and exynos-combiner.c
and only selected on the aarch32 devicesSigned-off-by: Hyunki Koo
Signed-off-by: Marc Zyngier
Reviewed-by: Krzysztof Kozlowski
Link: https://lore.kernel.org/r/20191224211108.7128-1-hyunki00.koo@gmail.com -
The meson a1 Socs have some changes compared with previous
chips. For A113L, it contains 62 pins and can be spied on:- 62:128 undefined
- 61:50 12 pins on bank A
- 49:37 13 pins on bank F
- 36:20 17 pins on bank X
- 19:13 7 pins on bank B
- 12:0 13 pins on bank PThere are five relative registers for gpio interrupt controller,
details are as below:- PADCTRL_GPIO_IRQ_CTRL0
bit[31]: enable/disable the whole irq lines
bit[16-23]: both edge trigger
bit[8-15]: single edge trigger
bit[0-7]: pol trigger- PADCTRL_GPIO_IRQ_CTRL[X]
bit[0-6]: 7 bits to choose gpio source for irq line 2*[X] - 2
bit[16-22]: 7 bits to choose gpio source for irq line 2*[X] - 1
where X =1,2,3,4Signed-off-by: Qianggui Song
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/20191216123645.10099-4-qianggui.song@amlogic.com -
Since Meson-A1 SoCs register layout of gpio interrupt controller has
difference with previous chips, registers to decide irq line and offset
of trigger method are all changed, the current driver should be modified.Signed-off-by: Qianggui Song
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/20191216123645.10099-3-qianggui.song@amlogic.com -
Update dt-binding document for GPIO interrupt controller of Meson-A1 SoCs
Signed-off-by: Qianggui Song
Signed-off-by: Marc Zyngier
Acked-by: Rob Herring
Link: https://lore.kernel.org/r/20191216123645.10099-2-qianggui.song@amlogic.com -
The following crash can be seen for setting
CONFIG_DEBUG_TEST_DRIVER_REMOVE=y for DT FW (which some people still use):Hisilicon MBIGEN-V2 60080000.interrupt-controller: Failed to create mbi-gen irqdomain
Hisilicon MBIGEN-V2: probe of 60080000.interrupt-controller failed with error -12[...]
Unable to handle kernel paging request at virtual address 0000000000005008
Mem abort info:
ESR = 0x96000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000004
CM = 0, WnR = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=0000041fb9990000
[0000000000005008] pgd=0000000000000000
Internal error: Oops: 96000004 [#1] PREEMPT SMP
Modules linked in:
CPU: 7 PID: 1 Comm: swapper/0 Not tainted 5.5.0-rc6-00002-g3fc42638a506-dirty #1622
Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT21 Nemo 2.0 RC0 04/18/2018
pstate: 40000085 (nZcv daIf -PAN -UAO)
pc : mbigen_set_type+0x38/0x60
lr : __irq_set_trigger+0x6c/0x188
sp : ffff800014b4b400
x29: ffff800014b4b400 x28: 0000000000000007
x27: 0000000000000000 x26: 0000000000000000
x25: ffff041fd83bd0d4 x24: ffff041fd83bd188
x23: 0000000000000000 x22: ffff80001193ce00
x21: 0000000000000004 x20: 0000000000000000
x19: ffff041fd83bd000 x18: ffffffffffffffff
x17: 0000000000000000 x16: 0000000000000000
x15: ffff8000119098c8 x14: ffff041fb94ec91c
x13: ffff041fb94ec1a1 x12: 0000000000000030
x11: 0101010101010101 x10: 0000000000000040
x9 : 0000000000000000 x8 : ffff041fb98c6680
x7 : ffff800014b4b380 x6 : ffff041fd81636c8
x5 : 0000000000000000 x4 : 000000000000025f
x3 : 0000000000005000 x2 : 0000000000005008
x1 : 0000000000000004 x0 : 0000000080000000
Call trace:
mbigen_set_type+0x38/0x60
__setup_irq+0x744/0x900
request_threaded_irq+0xe0/0x198
pcie_pme_probe+0x98/0x118
pcie_port_probe_service+0x38/0x78
really_probe+0xa0/0x3e0
driver_probe_device+0x58/0x100
__device_attach_driver+0x90/0xb0
bus_for_each_drv+0x64/0xc8
__device_attach+0xd8/0x138
device_initial_probe+0x10/0x18
bus_probe_device+0x90/0x98
device_add+0x4c4/0x770
device_register+0x1c/0x28
pcie_port_device_register+0x1e4/0x4f0
pcie_portdrv_probe+0x34/0xd8
local_pci_probe+0x3c/0xa0
pci_device_probe+0x128/0x1c0
really_probe+0xa0/0x3e0
driver_probe_device+0x58/0x100
__device_attach_driver+0x90/0xb0
bus_for_each_drv+0x64/0xc8
__device_attach+0xd8/0x138
device_attach+0x10/0x18
pci_bus_add_device+0x4c/0xb8
pci_bus_add_devices+0x38/0x88
pci_host_probe+0x3c/0xc0
pci_host_common_probe+0xf0/0x208
hisi_pcie_almost_ecam_probe+0x24/0x30
platform_drv_probe+0x50/0xa0
really_probe+0xa0/0x3e0
driver_probe_device+0x58/0x100
device_driver_attach+0x6c/0x90
__driver_attach+0x84/0xc8
bus_for_each_dev+0x74/0xc8
driver_attach+0x20/0x28
bus_add_driver+0x148/0x1f0
driver_register+0x60/0x110
__platform_driver_register+0x40/0x48
hisi_pcie_almost_ecam_driver_init+0x1c/0x24The specific problem here is that the mbigen driver real probe has failed
as the mbigen_of_create_domain()->of_platform_device_create() call fails,
the reason for that being that we never destroyed the platform device
created during the remove test dry run and there is some conflict.Since we generally would never want to unbind this driver, and to save
adding a driver tear down path for that, just set the driver
.suppress_bind_attrs member to avoid this possibility.Signed-off-by: John Garry
Signed-off-by: Marc Zyngier
Reviewed-by: Hanjun Guo
Link: https://lore.kernel.org/r/1579196323-180137-1-git-send-email-john.garry@huawei.com -
The Aspeed SOCs provide some interrupts through the System Control
Unit registers. Add an interrupt controller that provides these
interrupts to the system.Signed-off-by: Eddie James
Signed-off-by: Marc Zyngier
Reviewed-by: Andrew Jeffery
Link: https://lore.kernel.org/r/1579123790-6894-3-git-send-email-eajames@linux.ibm.com -
Document the Aspeed SCU interrupt controller and add an include file
for the interrupts it provides.Signed-off-by: Eddie James
Signed-off-by: Marc Zyngier
Reviewed-by: Rob Herring
Acked-by: Andrew Jeffery
Link: https://lore.kernel.org/r/1579123790-6894-2-git-send-email-eajames@linux.ibm.com -
Adds the GPIO driver for SiFive RISC-V SoCs.
Signed-off-by: Wesley W. Terpstra
[Atish: Various fixes and code cleanup]
Signed-off-by: Atish Patra
Signed-off-by: Yash Shah
Signed-off-by: Marc Zyngier
Reviewed-by: Bartosz Golaszewski
Reviewed-by: Linus Walleij
Link: https://lore.kernel.org/r/1575976274-13487-6-git-send-email-yash.shah@sifive.com
20 Jan, 2020
4 commits
-
DT json-schema for GPIO controller added.
Signed-off-by: Wesley W. Terpstra
[Atish: Compatible string update]
Signed-off-by: Atish Patra
Signed-off-by: Yash Shah
Signed-off-by: Marc Zyngier
Reviewed-by: Linus Walleij
Reviewed-by: Rob Herring
Link: https://lore.kernel.org/r/1575976274-13487-5-git-send-email-yash.shah@sifive.com -
Add support for hierarchical irq domains. This is needed as
pre-requisite for gpio-sifive driver.Signed-off-by: Yash Shah
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/1575976274-13487-4-git-send-email-yash.shah@sifive.com -
Make use of newly introduced irq_domain_translate_onecell() instead of
custom made function.Signed-off-by: Yash Shah
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/1575976274-13487-3-git-send-email-yash.shah@sifive.com -
Add a new function irq_domain_translate_onecell() that is to be used as
the translate function in struct irq_domain_ops.Signed-off-by: Yash Shah
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/1575976274-13487-2-git-send-email-yash.shah@sifive.com
30 Dec, 2019
2 commits
-
Pull RISC-V fixes from Paul Walmsley:
"One important fix for RISC-V:- Redirect any incoming syscall with an ID less than -1 to
sys_ni_syscall, rather than allowing them to fall through into the
syscall handler.and two minor build fixes:
- Export __asm_copy_{from,to}_user() from where they are defined.
This fixes a build error triggered by some randconfigs.- Export flush_icache_all(). I'd resisted this before, since
historically we didn't want modules to be able to flush the I$
directly; but apparently everyone else is doing it now"* tag 'riscv/for-v5.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
riscv: export flush_icache_all to modules
riscv: reject invalid syscalls below -1
riscv: fix compile failure with EXPORT_SYMBOL() & !MMU
