- 12 11月, 2017 1 次提交
-
-
由 Thomas Gleixner 提交于
The llist_for_each_entry() loop in irq_work_run_list() is unsafe because once the works PENDING bit is cleared it can be requeued on another CPU. Use llist_for_each_entry_safe() instead. Fixes: 16c0890d ("irq/work: Don't reinvent the wheel but use existing llist API") Reported-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Cc: Frederic Weisbecker <frederic@kernel.org> Cc: Byungchul Park <byungchul.park@lge.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Petri Latvala <petri.latvala@intel.com> Link: http://lkml.kernel.org/r/151027307351.14762.4611888896020658384@mail.alporthouse.com
-
- 09 11月, 2017 3 次提交
-
-
由 Thomas Gleixner 提交于
Merge tag 'irqchip-4.15-3' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core Pull irqchip updates for 4.15, take #3 from Marc Zyngier: - New Socionext Synquacer EXIU driver - stm32 new platform support and fixes - One GICv4 bugfix - A couple of MIPS GIC cleanups
-
由 Matt Redfearn 提交于
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>
-
由 Matt Redfearn 提交于
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>
-
- 07 11月, 2017 9 次提交
-
-
由 Ludovic Barre 提交于
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>
-
由 Ludovic Barre 提交于
-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>
-
由 Ludovic Barre 提交于
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>
-
由 Ludovic Barre 提交于
This patch updates stm32-exti documentation with stm32h7-exti compatible string. Acked-by: NRob Herring <robh@kernel.org> Signed-off-by: NLudovic Barre <ludovic.barre@st.com> Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Ludovic Barre 提交于
-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>
-
由 Ludovic Barre 提交于
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>
-
由 Ard Biesheuvel 提交于
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>
-
由 Ard Biesheuvel 提交于
Add a description of the External Interrupt Unit (EXIU) interrupt controller as found on the Socionext SynQuacer SoC. Acked-by: NRob Herring <robh@kernel.org> Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Marc Zyngier 提交于
its_vpe_irq_domain_activate should always return 0. Really. There is not a single case why it wouldn't. So this "return true;" is really a copy/paste issue that got revealed now that we actually check the return value of the activate method. Brown paper bag day. Fixes: 2247e1bf ("irqchip/gic-v3-its: Limit scope of VPE mapping to be per ITS") Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
- 03 11月, 2017 1 次提交
-
-
由 Thomas Gleixner 提交于
Merge tag 'irqchip-4.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core Pull the second batch of irqchip updates for 4.15 from marc Zyngier: - A number of MIPS GIC updates and cleanups - One GICv4 update - Another firmware workaround for GICv2 - Support for Mason8 GPIOs - Tiny documentation fix
-
- 02 11月, 2017 13 次提交
-
-
由 Paul Burton 提交于
We have 2 bitmaps used to keep track of interrupts dedicated to IPIs in the MIPS GIC irqchip driver. These bitmaps are only used from the one compilation unit of that driver, and so can be made static. Do so in order to avoid polluting the symbol table & global namespace. Signed-off-by: NPaul Burton <paul.burton@mips.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mips@linux-mips.org Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Paul Burton 提交于
The gic_set_type() function included writes to the MIPS GIC polarity, trigger & dual-trigger registers in each case of a switch statement determining the IRQs type. This is all well & good when we only have a single cluster & thus a single GIC whose register we want to update. It will lead to significant duplication once we have multi-cluster support & multiple GICs to update. Refactor this such that we determine values for the polarity, trigger & dual-trigger registers and then have a single set of register writes following the switch statement. This will allow us to write the same values to each GIC in a multi-cluster system in a later patch, rather than needing to duplicate more register writes in each case. Signed-off-by: NPaul Burton <paul.burton@mips.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mips@linux-mips.org Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Paul Burton 提交于
Following the past few patches nothing uses the gic_vpes variable any longer. Remove the dead code. Signed-off-by: NPaul Burton <paul.burton@mips.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mips@linux-mips.org Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Paul Burton 提交于
Reserving a number of IPIs based upon the number of VPs reported by the GIC makes little sense for a few reasons: - The kernel may have been configured with NR_CPUS less than the number of VPs in the cluster, in which case using gic_vpes causes us to reserve more interrupts for IPIs than we will possibly use. - If a kernel is configured without support for multi-threading & runs on a system with multi-threading & multiple VPs per core then we'll similarly reserve more interrupts for IPIs than we will possibly use. - In systems with multiple clusters the GIC can only provide us with the number of VPs in its cluster, not across all clusters. In this case we'll reserve fewer interrupts for IPIs than we need. Fix these issues by using num_possible_cpus() instead, which in all cases is actually indicative of how many IPIs we may need. Signed-off-by: NPaul Burton <paul.burton@mips.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mips@linux-mips.org Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Paul Burton 提交于
Rather than configuring EIC mode for all CPUs during boot, configure it locally on each when they come online. This will become important with multi-cluster support, since clusters may be powered on & off (for example via hotplug) and would lose the EIC configuration when powered off. Signed-off-by: NPaul Burton <paul.burton@mips.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mips@linux-mips.org Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Paul Burton 提交于
We currently walk through the range 0..gic_vpes-1, expecting these values all to be valid Linux CPU numbers to provide to mips_cm_vp_id(), and masking all routable local interrupts during boot. This approach has a few drawbacks: - In multi-cluster systems we won't have access to all CPU's GIC local registers when the driver is probed, since clusters (and their GICs) may be powered down at this point & only brought online later. - In multi-cluster systems we may power down clusters at runtime, for example if we offline all CPUs within it via hotplug, and the cluster's GIC may lose state. We therefore need to reinitialise it when powering back up, which this approach does not take into account. - The range 0..gic_vpes-1 may not all be valid Linux CPU numbers, for example if we run a kernel configured to support fewer CPUs than the system it is running on actually has. In this case we'll get garbage values from mips_cm_vp_id() as we read past the end of the cpu_data array. Fix this and simplify the code somewhat by writing an all-bits-set value to the VP-local reset mask register when a CPU is brought online, before any local interrupts are configured for it. This removes the need for us to access all CPUs during driver probe, removing all of the problems described above. In the name of simplicity we drop the checks for routability of interrupts and simply clear the mask bits for all interrupts. Bits for non-routable local interrupts will have no effect so there's no point performing extra work to avoid modifying them. Signed-off-by: NPaul Burton <paul.burton@mips.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mips@linux-mips.org Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Paul Burton 提交于
The gic_all_vpes_local_irq_controller chip currently attempts to operate on all CPUs/VPs in the system when masking or unmasking an interrupt. This has a few drawbacks: - In multi-cluster systems we may not always have access to all CPUs in the system. When all CPUs in a cluster are powered down that cluster's GIC may also power down, in which case we cannot configure its state. - Relatedly, if we power down a cluster after having configured interrupts for CPUs within it then the cluster's GIC may lose state & we need to reconfigure it. The current approach doesn't take this into account. - It's wasteful if we run Linux on fewer VPs than are present in the system. For example if we run a uniprocessor kernel on CPU0 of a system with 16 CPUs then there's no point in us configuring CPUs 1-15. - The implementation is also lacking in that it expects the range 0..gic_vpes-1 to represent valid Linux CPU numbers which may not always be the case - for example if we run on a system with more VPs than the kernel is configured to support. Fix all of these issues by only configuring the affected interrupts for CPUs which are online at the time, and recording the configuration in a new struct gic_all_vpes_chip_data for later use by CPUs being brought online. We register a CPU hotplug state (reusing CPUHP_AP_IRQ_GIC_STARTING which the ARM GIC driver uses, and which seems suitably generic for reuse with the MIPS GIC) and execute irq_cpu_online() in order to configure the interrupts on the newly onlined CPU. Signed-off-by: NPaul Burton <paul.burton@mips.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mips@linux-mips.org Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Paul Burton 提交于
The gic_local_irq_domain_map() function has only one callsite in gic_irq_domain_map(), and the split between the two functions makes it unclear that they duplicate calculations & checks. Inline gic_local_irq_domain_map() into gic_irq_domain_map() in order to clean this up. Doing this makes the following small issues obvious, and the patch tidies them up: - Both functions used GIC_HWIRQ_TO_LOCAL() to convert a hwirq number to a local IRQ number. We now only do this once. Although the compiler ought to have optimised this away before anyway, the change leaves us with less duplicate code. - gic_local_irq_domain_map() had a check for invalid local interrupt numbers (intr > GIC_LOCAL_INT_FDC). This condition can never occur because any hwirq higher than those used for local interrupts is a shared interrupt, which gic_irq_domain_map() already handles separately. We therefore remove this check. - The decision of whether to map the interrupt to gic_cpu_pin or timer_cpu_pin can be handled within the existing switch statement in gic_irq_domain_map(), shortening the code a little. The change additionally prepares us nicely for the following patch of the series which would otherwise need to duplicate the check for whether a local interrupt should be percpu_devid or just percpu (ie. the switch statement from gic_irq_domain_map()) in gic_local_irq_domain_map(). Signed-off-by: NPaul Burton <paul.burton@mips.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mips@linux-mips.org Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Martin Blumenstingl 提交于
Meson8 uses the same GPIO interrupt controller IP block as the other Meson SoCs. A total of 134 pins can be spied on, which is the sum of: - 22 pins on bank GPIOX - 17 pins on bank GPIOY - 30 pins on bank GPIODV - 10 pins on bank GPIOH - 15 pins on bank GPIOZ - 7 pins on bank CARD - 19 pins on bank BOOT - 14 pins in the AO domain Acked-by: NKevin Hilman <khilman@baylibre.com> Acked-by: NRob Herring <robh@kernel.org> Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Dou Liyang 提交于
Commit: f110711a ("irqdomain: Convert irqdomain-%3Eof_node to fwnode") converted of_node field to fwnode, but didn't update its comments. Update it. Fixes: f110711a ("irqdomain: Convert irqdomain-%3Eof_node to fwnode") Signed-off-by: NDou Liyang <douly.fnst@cn.fujitsu.com> Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Marc Zyngier 提交于
There is a lot of broken firmware out there that don't really expose the information the kernel requires when it comes with dealing with GICv2: (1) Firmware that only describes the first 4kB of GICv2 (2) Firmware that describe 128kB of CPU interface, while the usable portion of the address space is between 60 and 68kB So far, we only deal with (2). But we have platforms exhibiting behaviour (1), resulting in two sub-cases: (a) The GIC is occupying 8kB, as required by the GICv2 architecture (b) It is actually spread 128kB, and this is likely to be a version of (2) This patch tries to work around both (a) and (b) by poking at the outside of the described memory region, and try to work out what is actually there. This is of course unsafe, and should only be enabled if there is no way to otherwise fix the DT provided by the firmware (we provide a "irqchip.gicv2_force_probe" option to that effect). Note that for the time being, we restrict ourselves to GICv2 implementations provided by ARM, since there I have no knowledge of an alternative implementations. This could be relaxed if such an implementation comes to light on a broken platform. Reviewed-by: NChristoffer Dall <cdall@linaro.org> Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Marc Zyngier 提交于
So far, we require the hypervisor to update the VLPI properties once the the VLPI mapping has been established. While this makes it easy for the ITS driver, it creates a window where an incoming interrupt can be delivered with an unknown set of properties. Not very nice. Instead, let's add a "properties" field to the mapping structure, and use that to configure the VLPI before it actually gets mapped. Reviewed-by: NChristoffer Dall <christoffer.dall@linaro.org> Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Marc Zyngier 提交于
Required merge to get mainline irqchip updates. Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
- 01 11月, 2017 1 次提交
-
-
由 Rakib Mullick 提交于
irq/core: Fix boot crash when the irqaffinity= boot parameter is passed on CPUMASK_OFFSTACK=y kernels(v1) When the irqaffinity= kernel parameter is passed in a CPUMASK_OFFSTACK=y kernel, it fails to boot, because zalloc_cpumask_var() cannot be used before initializing the slab allocator to allocate a cpumask. So, use alloc_bootmem_cpumask_var() instead. Also do some cleanups while at it: in init_irq_default_affinity() remove an #ifdef via using cpumask_available(). Signed-off-by: NRakib Mullick <rakib.mullick@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20171026045800.27087-1-rakib.mullick@gmail.com Link: http://lkml.kernel.org/r/20171101041451.12581-1-rakib.mullick@gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
- 31 10月, 2017 1 次提交
-
-
由 Byungchul Park 提交于
Use the proper llist APIs instead of open-coded variants of them. Signed-off-by: NByungchul Park <byungchul.park@lge.com> Signed-off-by: NFrederic Weisbecker <frederic@kernel.org> Acked-by: NThomas Gleixner <tglx@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1509414414-14987-1-git-send-email-frederic@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
- 29 10月, 2017 1 次提交
-
-
由 Christoffer Dall 提交于
It is currently unclear how to set the VCPU affinity for a percpu_devid interrupt , since the Linux irq_data structure describes the state for multiple interrupts, one for each physical CPU on the system. Since each such interrupt can be associated with different VCPUs or none at all, associating a single VCPU state with such an interrupt does not capture the necessary semantics. The implementers of irq_set_affinity are the Intel and AMD IOMMUs, and the ARM GIC irqchip. The Intel and AMD callers do not appear to use percpu_devid interrupts, and the ARM GIC implementation only checks the pointer against NULL vs. non-NULL. Therefore, simply update the function documentation to explain the expected use in the context of percpu_devid interrupts, allowing future changes or additions to irqchip implementers to do the right thing. Signed-off-by: NChristoffer Dall <cdall@linaro.org> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Acked-by: NMarc Zyngier <marc.zyngier@arm.com> Cc: kvm@vger.kernel.org Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Eric Auger <eric.auger@redhat.com> Cc: kvmarm@lists.cs.columbia.edu Cc: linux-arm-kernel@lists.infradead.org Link: https://lkml.kernel.org/r/1509093281-15225-13-git-send-email-cdall@linaro.org
-
- 20 10月, 2017 1 次提交
-
-
由 Thomas Gleixner 提交于
The driver fails to compile with CONFIG_COMPILE_TEST=y on x86: irq-meson-gpio.c: In function ‘meson_gpio_irq_parse_dt’: irq-meson-gpio.c:343:8: error: implicit declaration of function ‘of_property_read_variable_u32_array’ ret = of_property_read_variable_u32_array(node, Adding COMPILE_TEST to a driver requires at least compile testing it for x86.... Reported-by: NIngo Molnar <mingo@kernel.org> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Cc: Heiner Kallweit <hkallweit1@gmail.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Marc Zyngier <marc.zyngier@arm.com>
-
- 19 10月, 2017 9 次提交
-
-
由 Thomas Gleixner 提交于
Merge tag 'irqchip-4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core Pull irqchip updates for 4.15 from Marc Zyngier - GICv4 updates (improved performance, errata workarounds) - Workaround for Socionext's pre-ITS erratum - Meson GPIO interrupt controller - BCM7271 L2 interrupt controller - GICv3 range selector support - various cleanups
-
由 Wei Yongjun 提交于
In case of error, the function of_iomap() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test.. Reviewed-by: NBrendan Higgins <brendanhiggins@google.com> Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com> Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Jerome Brunet 提交于
Add support for the interrupt gpio controller found on Amlogic's meson SoC family. This controller is a separate controller from the gpio controller. It is able to spy on the SoC pad. It is essentially a 256 to 8 router with a filtering block to select level or edge and polarity. The number of actual mappable inputs depends on the SoC. Cc: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: NJerome Brunet <jbrunet@baylibre.com> Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Jerome Brunet 提交于
This commit adds the device tree bindings description for Amlogic's GPIO interrupt controller available on the meson8b, gxbb and gxl SoC families Cc: Heiner Kallweit <hkallweit1@gmail.com> Acked-by: NRob Herring <robh@kernel.org> Signed-off-by: NJerome Brunet <jbrunet@baylibre.com> Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Marc Zyngier 提交于
When setting the affinity of a VPE (either because we map or move it), make sure the effective affinity is correctly reported back to the core kernel. Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Marc Zyngier 提交于
Sending VINVALL to all ITSs is completely pointless, as all we're trying to achieve is to tell the redistributor that the property table for this VPE should be invalidated. Let's issue the command on the first valid ITS and be done with it. Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Marc Zyngier 提交于
So far, we map all VPEs on all ITSs. While this is not wrong, this is quite a big hammer, as moving a VPE around requires all ITSs to be synchronized. Needles to say, this is an expensive proposition. Instead, let's switch to a mode where we issue VMAPP commands only on ITSs that are actually involved in reporting interrupts to the given VM. For that purpose, we refcount the number of interrupts are are mapped for this VM on each ITS, performing the map/unmap operations as required. It then allows us to use this refcount to only issue VMOVP to the ITSs that need to know about this VM. Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Marc Zyngier 提交于
Currently, its_send_vmapp operates on all ITSs. As we're about to try and limit the amount of commands we send to ITSs that are not involved in dealing with a given VM, let's redefine that primitive so that it takes a target ITS as a parameter. Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Marc Zyngier 提交于
Currently, its_send_vinvall operates on all ITSs. As we're about to try and limit the amount of commands we send to ITSs that are not involved in dealing with a given VM, let's redefine that primitive so that it takes a target ITS as a parameter. Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-