We want to reuse the core of the map/unmap functions for IRQ
forwarding. Let's move the computation of the hwirq in
kvm_vgic_map_phys_irq and pass the linux IRQ as parameter.
the host_irq is added to struct vgic_irq.
We introduce kvm_vgic_map/unmap_irq which take a struct vgic_irq
handle as a parameter.
Acked-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Eric Auger [Fri, 27 Oct 2017 14:28:31 +0000 (15:28 +0100)]
KVM: arm/arm64: register irq bypass consumer on ARM/ARM64
This patch selects IRQ_BYPASS_MANAGER and HAVE_KVM_IRQ_BYPASS
configs for ARM/ARM64.
kvm_arch_has_irq_bypass() now is implemented and returns true.
As a consequence the irq bypass consumer will be registered for
ARM/ARM64 with the forwarding callbacks:
We don't have any actual support yet, so nothing gets actually
forwarded.
Acked-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Eric Auger <eric.auger@redhat.com>
[maz: dropped the DEOI stuff for the time being in order to
reduce the dependency chain, amended commit message] Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Dongjiu Geng [Mon, 30 Oct 2017 06:05:18 +0000 (14:05 +0800)]
KVM: arm/arm64: fix the incompatible matching for external abort
kvm_vcpu_dabt_isextabt() tries to match a full fault syndrome, but
calls kvm_vcpu_trap_get_fault_type() that only returns the fault class,
thus reducing the scope of the check. This doesn't cause any observable
bug yet as we end-up matching a closely related syndrome for which we
return the same value.
Using kvm_vcpu_trap_get_fault() instead fixes it for good.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Marc Zyngier [Sun, 29 Oct 2017 02:18:09 +0000 (02:18 +0000)]
KVM: arm/arm64: Unify 32bit fault injection
Both arm and arm64 implementations are capable of injecting
faults, and yet have completely divergent implementations,
leading to different bugs and reduced maintainability.
Let's elect the arm64 version as the canonical one
and move it into aarch32.c, which is common to both
architectures.
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
On reset we clear the valid bits of GITS_CBASER and GITS_BASER<n>.
We also clear command queue registers and free the cache (device,
collection, and lpi lists).
As we need to take the same locks as save/restore functions, we
create a vgic_its_ctrl() wrapper that handles KVM_DEV_ARM_VGIC_GRP_CTRL
group functions.
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
At the moment, the in-kernel emulated ITS is not properly reset.
On guest restart/reset some registers keep their old values and
internal structures like device, ITE, and collection lists are not
freed.
This may lead to various bugs. Among them, we can have incorrect state
backup or failure when saving the ITS state at early guest boot stage.
This patch documents a new attribute, KVM_DEV_ARM_ITS_CTRL_RESET in
the KVM_DEV_ARM_VGIC_GRP_CTRL group.
Upon this action, we can reset registers and especially those
pointing to tables previously allocated by the guest and free
the internal data structures storing the list of devices, collections
and lpis.
The usual approach for device reset of having userspace write
the reset values of the registers to the kernel via the register
read/write APIs doesn't work for the ITS because it has some
internal state (caches) which is not exposed as registers,
and there is no register interface for "drop cached data without
writing it back to RAM". So we need a KVM API which mimics the
hardware's reset line, to provide the equivalent behaviour to
a "pull the power cord out of the back of the machine" reset.
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Eric Auger <eric.auger@redhat.com> Reported-by: wanghaibin <wanghaibin.wang@huawei.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Eric Auger [Thu, 26 Oct 2017 15:23:09 +0000 (17:23 +0200)]
KVM: arm/arm64: vgic-its: Free caches when GITS_BASER Valid bit is cleared
When the GITS_BASER<n>.Valid gets cleared, the data structures in
guest RAM are not valid anymore. The device, collection
and LPI lists stored in the in-kernel ITS represent the same
information in some form of cache. So let's void the cache.
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
wanghaibin [Thu, 26 Oct 2017 15:23:08 +0000 (17:23 +0200)]
KVM: arm/arm64: vgic-its: New helper functions to free the caches
We create two new functions that free the device and
collection lists. They are currently called by vgic_its_destroy()
and other callers will be added in subsequent patches.
We also remove the check on its->device_list.next.
Lists are initialized in vgic_create_its() and the device
is added to the device list only if this latter succeeds.
vgic_its_destroy is the device destroy ops. This latter is called
by kvm_destroy_devices() which loops on all created devices. So
at this point the list is initialized.
Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: wanghaibin <wanghaibin.wang@huawei.com> Signed-off-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Let's remove kvm_its_unmap_device and use kvm_its_free_device
as both functions are identical.
Signed-off-by: Eric Auger <eric.auger@redhat.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Christoffer Dall [Sun, 29 Oct 2017 01:04:55 +0000 (02:04 +0100)]
arm/arm64: KVM: Load the timer state when enabling the timer
After being lazy with saving/restoring the timer state, we defer that
work to vcpu_load and vcpu_put, which ensure that the timer state is
loaded on the hardware timers whenever the VCPU runs.
Unfortunately, we are failing to do that the first time vcpu_load()
runs, because the timer has not yet been enabled at that time. As long
as the initialized timer state matches what happens to be in the
hardware (a disabled timer, because we never leave the timer screaming),
this does not show up as a problem, but is nevertheless incorrect.
The solution is simple; disable preemption while setting the timer to be
enabled, and call the timer load function when first enabling the timer.
Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
kvm_timer_should_fire() can be called in two different situations from
the kvm_vcpu_block().
The first case is before calling kvm_timer_schedule(), used for wait
polling, and in this case the VCPU thread is running and the timer state
is loaded onto the hardware so all we have to do is check if the virtual
interrupt lines are asserted, becasue the timer interrupt handler
functions will raise those lines as appropriate.
The second case is inside the wait loop of kvm_vcpu_block(), where we
have already called kvm_timer_schedule() and therefore the hardware will
be disabled and the software view of the timer state is up to date
(timer->loaded is false), and so we can simply check if the timer should
fire by looking at the software state.
Signed-off-by: Christoffer Dall <cdall@linaro.org> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Christoffer Dall [Tue, 20 Jun 2017 14:56:20 +0000 (07:56 -0700)]
KVM: arm/arm64: Get rid of kvm_timer_flush_hwstate
Now when both the vtimer and the ptimer when using both the in-kernel
vgic emulation and a userspace IRQ chip are driven by the timer signals
and at the vcpu load/put boundaries, instead of recomputing the timer
state at every entry/exit to/from the guest, we can get entirely rid of
the flush hwstate function.
Signed-off-by: Christoffer Dall <cdall@linaro.org> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Christoffer Dall [Sun, 18 Jun 2017 08:42:55 +0000 (01:42 -0700)]
KVM: arm/arm64: Avoid phys timer emulation in vcpu entry/exit
There is no need to schedule and cancel a hrtimer when entering and
exiting the guest, because we know when the physical timer is going to
fire when the guest programs it, and we can simply program the hrtimer
at that point.
Now when the register modifications from the guest go through the
kvm_arm_timer_set/get_reg functions, which always call
kvm_timer_update_state(), we can simply consider the timer state in this
function and schedule and cancel the timers as needed.
This avoids looking at the physical timer emulation state when entering
and exiting the VCPU, allowing for faster servicing of the VM when
needed.
Signed-off-by: Christoffer Dall <cdall@linaro.org> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Christoffer Dall [Sun, 18 Jun 2017 08:41:06 +0000 (01:41 -0700)]
KVM: arm/arm64: Move phys_timer_emulate function
We are about to call phys_timer_emulate() from kvm_timer_update_state()
and modify phys_timer_emulate() at the same time. Moving the function
and modifying it in a single patch makes the diff hard to read, so do
this separately first.
No functional change.
Signed-off-by: Christoffer Dall <cdall@linaro.org> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Christoffer Dall [Sat, 17 Jun 2017 06:12:06 +0000 (23:12 -0700)]
KVM: arm/arm64: Use kvm_arm_timer_set/get_reg for guest register traps
When trapping on a guest access to one of the timer registers, we were
messing with the internals of the timer state from the sysregs handling
code, and that logic was about to receive more added complexity when
optimizing the timer handling code.
Therefore, since we already have timer register access functions (to
access registers from userspace), reuse those for the timer register
traps from a VM and let the timer code maintain its own consistency.
Signed-off-by: Christoffer Dall <cdall@linaro.org> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Christoffer Dall [Sat, 17 Jun 2017 06:08:57 +0000 (23:08 -0700)]
KVM: arm/arm64: Support EL1 phys timer register access in set/get reg
Add suport for the physical timer registers in kvm_arm_timer_set_reg and
kvm_arm_timer_get_reg so that these functions can be reused to interact
with the rest of the system.
Note that this paves part of the way for the physical timer state
save/restore, but we still need to add those registers to
KVM_GET_REG_LIST before we support migrating the physical timer state.
Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <cdall@linaro.org>
Christoffer Dall [Sun, 16 Oct 2016 18:30:38 +0000 (20:30 +0200)]
KVM: arm/arm64: Avoid timer save/restore in vcpu entry/exit
We don't need to save and restore the hardware timer state and examine
if it generates interrupts on on every entry/exit to the guest. The
timer hardware is perfectly capable of telling us when it has expired
by signaling interrupts.
When taking a vtimer interrupt in the host, we don't want to mess with
the timer configuration, we just want to forward the physical interrupt
to the guest as a virtual interrupt. We can use the split priority drop
and deactivate feature of the GIC to do this, which leaves an EOI'ed
interrupt active on the physical distributor, making sure we don't keep
taking timer interrupts which would prevent the guest from running. We
can then forward the physical interrupt to the VM using the HW bit in
the LR of the GIC, like we do already, which lets the guest directly
deactivate both the physical and virtual timer simultaneously, allowing
the timer hardware to exit the VM and generate a new physical interrupt
when the timer output is again asserted later on.
We do need to capture this state when migrating VCPUs between physical
CPUs, however, which we use the vcpu put/load functions for, which are
called through preempt notifiers whenever the thread is scheduled away
from the CPU or called directly if we return from the ioctl to
userspace.
One caveat is that we have to save and restore the timer state in both
kvm_timer_vcpu_[put/load] and kvm_timer_[schedule/unschedule], because
we can have the following flows:
Since kvm_timer_[schedule/unschedule] may not be followed by put/load,
but put/load also may be called independently, we call the timer
save/restore functions from both paths. Since they rely on the loaded
flag to never save/restore when unnecessary, this doesn't cause any
harm, and we ensure that all invokations of either set of functions work
as intended.
An added benefit beyond not having to read and write the timer sysregs
on every entry and exit is that we no longer have to actively write the
active state to the physical distributor, because we configured the
irq for the vtimer to only get a priority drop when handling the
interrupt in the GIC driver (we called irq_set_vcpu_affinity()), and
the interrupt stays active after firing on the host.
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <cdall@linaro.org>
KVM: arm/arm64: Set VCPU affinity for virt timer irq
As we are about to take physical interrupts for the virtual timer on the
host but want to leave those active while running the VM (and let the VM
deactivate them), we need to set the vtimer PPI affinity accordingly.
Signed-off-by: Christoffer Dall <cdall@linaro.org> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
KVM: arm/arm64: Move timer save/restore out of the hyp code
As we are about to be lazy with saving and restoring the timer
registers, we prepare by moving all possible timer configuration logic
out of the hyp code. All virtual timer registers can be programmed from
EL1 and since the arch timer is always a level triggered interrupt we
can safely do this with interrupts disabled in the host kernel on the
way to the guest without taking vtimer interrupts in the host kernel
(yet).
The downside is that the cntvoff register can only be programmed from
hyp mode, so we jump into hyp mode and back to program it. This is also
safe, because the host kernel doesn't use the virtual timer in the KVM
code. It may add a little performance performance penalty, but only
until following commits where we move this operation to vcpu load/put.
Signed-off-by: Christoffer Dall <cdall@linaro.org> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Christoffer Dall [Sun, 18 Jun 2017 07:32:08 +0000 (00:32 -0700)]
KVM: arm/arm64: Use separate timer for phys timer emulation
We were using the same hrtimer for emulating the physical timer and for
making sure a blocking VCPU thread would be eventually woken up. That
worked fine in the previous arch timer design, but as we are about to
actually use the soft timer expire function for the physical timer
emulation, change the logic to use a dedicated hrtimer.
This has the added benefit of not having to cancel any work in the sync
path, which in turn allows us to run the flush and sync with IRQs
disabled.
Note that the hrtimer used to program the host kernel's timer to
generate an exit from the guest when the emulated physical timer fires
never has to inject any work, and to share the soft_timer_cancel()
function with the bg_timer, we change the function to only cancel any
pending work if the pointer to the work struct is not null.
Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <cdall@linaro.org>
Christoffer Dall [Sun, 16 Oct 2016 18:24:30 +0000 (20:24 +0200)]
KVM: arm/arm64: Move timer/vgic flush/sync under disabled irq
As we are about to play tricks with the timer to be more lazy in saving
and restoring state, we need to move the timer sync and flush functions
under a disabled irq section and since we have to flush the vgic state
after the timer and PMU state, we do the whole flush/sync sequence with
disabled irqs.
The only downside is a slightly longer delay before being able to
process hardware interrupts and run softirqs.
Signed-off-by: Christoffer Dall <cdall@linaro.org> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Christoffer Dall [Sat, 17 Jun 2017 14:33:02 +0000 (07:33 -0700)]
KVM: arm/arm64: Rename soft timer to bg_timer
As we are about to introduce a separate hrtimer for the physical timer,
call this timer bg_timer, because we refer to this timer as the
background timer in the code and comments elsewhere.
Signed-off-by: Christoffer Dall <cdall@linaro.org> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Christoffer Dall [Sat, 17 Jun 2017 08:09:19 +0000 (01:09 -0700)]
KVM: arm/arm64: Make timer_arm and timer_disarm helpers more generic
We are about to add an additional soft timer to the arch timer state for
a VCPU and would like to be able to reuse the functions to program and
cancel a timer, so we make them slightly more generic and rename to make
it more clear that these functions work on soft timers and not the
hardware resource that this code is managing.
The armed flag on the timer state is only used to assert a condition,
and we don't rely on this assertion in any meaningful way, so we can
simply get rid of this flack and slightly reduce complexity.
Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <cdall@linaro.org>
KVM: arm/arm64: Check that system supports split eoi/deactivate
Some systems without proper firmware and/or hardware description data
don't support the split EOI and deactivate operation.
On such systems, we cannot leave the physical interrupt active after the
timer handler on the host has run, so we cannot support KVM with an
in-kernel GIC with the timer changes we are about to introduce.
This patch makes sure that trying to initialize the KVM GIC code will
fail on such systems.
Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <cdall@linaro.org>
Christoffer Dall [Sun, 16 Oct 2016 20:19:11 +0000 (22:19 +0200)]
KVM: arm/arm64: Support calling vgic_update_irq_pending from irq context
We are about to optimize our timer handling logic which involves
injecting irqs to the vgic directly from the irq handler.
Unfortunately, the injection path can take any AP list lock and irq lock
and we must therefore make sure to use spin_lock_irqsave where ever
interrupts are enabled and we are taking any of those locks, to avoid
deadlocking between process context and the ISR.
This changes a lot of the VGIC code, but the good news are that the
changes are mostly mechanical.
Acked-by: Marc Zyngier <marc,zyngier@arm.com> Signed-off-by: Christoffer Dall <cdall@linaro.org>
Christoffer Dall [Wed, 19 Oct 2016 10:40:17 +0000 (12:40 +0200)]
KVM: arm/arm64: Guard kvm_vgic_map_is_active against !vgic_initialized
If the vgic is not initialized, don't try to grab its spinlocks or
traverse its data structures.
This is important because we soon have to start considering the active
state of a virtual interrupts when doing vcpu_load, which may happen
early on before the vgic is initialized.
Signed-off-by: Christoffer Dall <cdall@linaro.org> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
arm64: Use physical counter for in-kernel reads when booted in EL2
Using the physical counter allows KVM to retain the offset between the
virtual and physical counter as long as it is actively running a VCPU.
As soon as a VCPU is released, another thread is scheduled or we start
running userspace applications, we reset the offset to 0, so that
userspace accessing the virtual timer can still read the virtual counter
and get the same view of time as the kernel.
This opens up potential improvements for KVM performance, but we have to
make a few adjustments to preserve system consistency.
Currently get_cycles() is hardwired to arch_counter_get_cntvct() on
arm64, but as we move to using the physical timer for the in-kernel
time-keeping on systems that boot in EL2, we should use the same counter
for get_cycles() as for other in-kernel timekeeping operations.
Similarly, implementations of arch_timer_set_next_event_phys() is
modified to use the counter specific to the timer being programmed.
VHE kernels or kernels continuing to use the virtual timer are
unaffected.
Cc: Will Deacon <will.deacon@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <cdall@linaro.org>
Christoffer Dall [Wed, 18 Oct 2017 11:06:25 +0000 (13:06 +0200)]
arm64: Implement arch_counter_get_cntpct to read the physical counter
As we are about to use the physical counter on arm64 systems that have
KVM support, implement arch_counter_get_cntpct() and the associated
errata workaround functionality for stable timer reads.
Cc: Will Deacon <will.deacon@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Thomas Gleixner [Thu, 2 Nov 2017 18:18:08 +0000 (19:18 +0100)]
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
Paul Burton [Tue, 31 Oct 2017 16:41:51 +0000 (09:41 -0700)]
irqchip: mips-gic: Make IPI bitmaps static
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: Paul 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: Marc Zyngier <marc.zyngier@arm.com>
Paul Burton [Tue, 31 Oct 2017 16:41:50 +0000 (09:41 -0700)]
irqchip: mips-gic: Share register writes in gic_set_type()
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: Paul 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: Marc Zyngier <marc.zyngier@arm.com>
Paul Burton [Tue, 31 Oct 2017 16:41:49 +0000 (09:41 -0700)]
irqchip: mips-gic: Remove gic_vpes variable
Following the past few patches nothing uses the gic_vpes variable any
longer. Remove the dead code.
Signed-off-by: Paul 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: Marc Zyngier <marc.zyngier@arm.com>
Paul Burton [Tue, 31 Oct 2017 16:41:48 +0000 (09:41 -0700)]
irqchip: mips-gic: Use num_possible_cpus() to reserve IPIs
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: Paul 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: Marc Zyngier <marc.zyngier@arm.com>
Paul Burton [Tue, 31 Oct 2017 16:41:47 +0000 (09:41 -0700)]
irqchip: mips-gic: Configure EIC when CPUs come online
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: Paul 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: Marc Zyngier <marc.zyngier@arm.com>
Paul Burton [Tue, 31 Oct 2017 16:41:46 +0000 (09:41 -0700)]
irqchip: mips-gic: Mask local interrupts when CPUs come online
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: Paul 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: Marc Zyngier <marc.zyngier@arm.com>
Paul Burton [Tue, 31 Oct 2017 16:41:45 +0000 (09:41 -0700)]
irqchip: mips-gic: Use irq_cpu_online to (un)mask all-VP(E) IRQs
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: Paul 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: Marc Zyngier <marc.zyngier@arm.com>
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: Paul 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: Marc Zyngier <marc.zyngier@arm.com>
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: Kevin Hilman <khilman@baylibre.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Marc Zyngier [Fri, 27 Oct 2017 08:34:22 +0000 (10:34 +0200)]
irqchip/gic: Deal with broken firmware exposing only 4kB of GICv2 CPU interface
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: Christoffer Dall <cdall@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Marc Zyngier [Thu, 26 Oct 2017 09:44:07 +0000 (10:44 +0100)]
irqchip/gic-v3-its: Setup VLPI properties at map time
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: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Rakib Mullick [Wed, 1 Nov 2017 04:14:51 +0000 (10:14 +0600)]
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().
Christoffer Dall [Fri, 27 Oct 2017 08:34:33 +0000 (10:34 +0200)]
genirq: Document vcpu_info usage for percpu_devid interrupts
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: Christoffer Dall <cdall@linaro.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Marc 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
Thomas Gleixner [Fri, 20 Oct 2017 09:15:36 +0000 (11:15 +0200)]
irqchip/meson: Disable COMPILE_TEST
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: Ingo Molnar <mingo@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Heiner Kallweit <hkallweit1@gmail.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Marc Zyngier <marc.zyngier@arm.com>
Wei Yongjun [Wed, 11 Oct 2017 10:50:23 +0000 (10:50 +0000)]
irqchip/aspeed-i2c-ic: Fix return value check in aspeed_i2c_ic_of_init()
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..
irqchip/meson: Add support for gpio interrupt controller
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.
Marc Zyngier [Mon, 9 Oct 2017 12:17:43 +0000 (13:17 +0100)]
irqchip/gic-v3-its: Only send VINVALL to a single ITS
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: Marc Zyngier <marc.zyngier@arm.com>
Marc Zyngier [Sun, 8 Oct 2017 17:50:36 +0000 (18:50 +0100)]
irqchip/gic-v3-its: Limit scope of VPE mapping to be per ITS
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: Marc Zyngier <marc.zyngier@arm.com>
Marc Zyngier [Sun, 8 Oct 2017 17:46:39 +0000 (18:46 +0100)]
irqchip/gic-v3-its: Make its_send_vmapp operate on a single ITS
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: Marc Zyngier <marc.zyngier@arm.com>
Marc Zyngier [Sun, 8 Oct 2017 14:16:09 +0000 (15:16 +0100)]
irqchip/gic-v3-its: Make its_send_vinvall operate on a single ITS
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: Marc Zyngier <marc.zyngier@arm.com>
Marc Zyngier [Sun, 8 Oct 2017 17:44:42 +0000 (18:44 +0100)]
irqchip/gic-v3-its: Track per-ITS list number
At boot time, we enumerate all the GICv4-capable ITSs, and build
a mask of the available ITSs. Take this opportunity to store
the ITS number in the its_node structure so that we can use it
at a later time.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
The ITSes on the Hip07 (as present in the Huawei D05) are broken when
it comes to addressing the redistributors, and need to be explicitely
told to address the VLPI page instead of the redistributor base address.
So let's add yet another quirk, fixing up the target address
in the command stream.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Marc Zyngier [Fri, 4 Aug 2017 16:45:50 +0000 (17:45 +0100)]
irqchip/gic-v3-its: Add post-mortem info on command timeout
If the ITS stops processing commands, we're pretty much toasted
as we cannot update the configuration anymore (and we're not
even sure that the ITS still translates interrups).
If that happens, let's dump some basic information about the
state of affairs before moving on.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Ard Biesheuvel [Tue, 17 Oct 2017 16:55:56 +0000 (17:55 +0100)]
irqchip/gic-v3: Add workaround for Synquacer pre-ITS
The Socionext Synquacer SoC's implementation of GICv3 has a so-called
'pre-ITS', which maps 32-bit writes targeted at a separate window of
size '4 << device_id_bits' onto writes to GITS_TRANSLATER with device
ID taken from bits [device_id_bits + 1:2] of the window offset.
Writes that target GITS_TRANSLATER directly are reported as originating
from device ID #0.
So add a workaround for this. Given that this breaks isolation, clear
the IRQ_DOMAIN_FLAG_MSI_REMAP flag as well.
Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Ard Biesheuvel [Tue, 17 Oct 2017 16:55:55 +0000 (17:55 +0100)]
irqchip/gic: Make quirks matching conditional on init return value
As it turns out, the IIDR is not sufficient to distinguish between GICv3
implementations when it comes to enabling quirks. So update the prototype
of the init() hook to return a bool, and interpret a 'false' return value
as no match, in which case the 'enabling workaround' log message should
not be printed.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Ard Biesheuvel [Tue, 17 Oct 2017 16:55:54 +0000 (17:55 +0100)]
irqchip/gic-v3: Probe device ID space before quirks handling
Before adding another SoC whose device ID space deviates from the
value presented in the GIC ID registers, let's slightly refactor
the code so that the ID registers are probed before that quirks
handling executes. This allows us to move the device ID override
into the quirk handler itself.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
irqchip/gic-v3: Add support for Range Selector (RS) feature
A new feature Range Selector (RS) has been added to GIC specification
in order to support more than 16 CPUs at affinity level 0. New fields
are introduced in SGI system registers (ICC_SGI0R_EL1, ICC_SGI1R_EL1
and ICC_ASGI1R_EL1) to relax an artificial limit of 16 at level 0.
- A new RSS field in ICC_CTLR_EL3, ICC_CTLR_EL1 and ICV_CTLR_EL1:
[18] - Range Selector Support (RSS)
0b0 = Targeted SGIs with affinity level 0 values of 0-15 are supported.
0b1 = Targeted SGIs with affinity level 0 values of 0-255 are supported.
- A new RS field in ICC_SGI0R_EL1, ICC_SGI1R_EL1 and ICC_ASGI1R_EL1:
[47:44] - RangeSelector (RS) which group of 16 TargetList[n] field
TargetList[n] represents aff0 value ((RS*16)+n)
When ICC_CTLR_EL3.RSS==0 or ICC_CTLR_EL1.RSS==0, RS is RES0.
- A new RSS field in GICD_TYPER:
[26] - Range Selector Support (RSS)
0b0 = Targeted SGIs with affinity level 0 values of 0-15 are supported.
0b1 = Targeted SGIs with affinity level 0 values of 0-255 are supported.
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
irqchip/brcmstb-l2: Add support for the BCM7271 L2 controller
Add the initialization of the generic irq chip for the BCM7271 L2
interrupt controller. This controller only supports level
interrupts and uses the "brcm,bcm7271-l2-intc" compatibility
string.
Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Doug Berger <opendmb@gmail.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Added register block offsets to the brcmstb_l2_intc_data structure
for the status and mask registers to support reading the active
interupts in an abstracted way. It seems like an irq_chip method
should have been provided for this, but it's not there yet.
Abstracted the implementation of the handler, suspend, and resume
functions to not use any hard coded register offsets.
irqchip/brcmstb-l2: Remove some processing from the handler
Saving the generic chip pointer in the brcmstb_l2_intc_data prevents
the need to call irq_get_domain_generic_chip(). Also don't need to
save parent_irq and base there since local variables in the
brcmstb_l2_intc_of_init() function are just as good.
The handle_edge_irq flow or chained_irq_enter takes care of the
acknowledgment of the interrupt so it is redundant to clear it in
brcmstb_l2_intc_irq_handle().
irq_linear_revmap() is a fast path equivalent of irq_find_mapping()
that is appropriate to use for domain controllers of this type.
Defining irq_mask_ack is slightly more efficient than just
implementing irq_mask and irq_ack separately.
Masahiro Yamada [Thu, 5 Oct 2017 01:44:54 +0000 (10:44 +0900)]
irqdomain: Move revmap_trees_mutex to struct irq_domain
The revmap_trees_mutex protects domain->revmap_tree. There is no
need to make it global because it is allowed to modify revmap_tree
of two different domains concurrently. Having said that, this would
not be a actual bottleneck because the interrupt map/unmap does not
occur quite often. Rather, the motivation is to tidy up the code
from a data structure point of view.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Randy Dunlap [Mon, 16 Oct 2017 18:04:33 +0000 (11:04 -0700)]
irqchip: Add Kconfig menu
Add a menu for IRQ chip drivers. This makes the Device drivers menu be more
consistent (listing "subsystems" instead of specific options) and makes the
IRQCHIP options be listed in expected places for 'make menu|xconfig'.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jason Cooper <jason@lakedaemon.net> Link: https://lkml.kernel.org/r/3db7385a-c6a1-5c93-0797-6f4b6b2b2cde@infradead.org
Ladislav Michl [Mon, 16 Oct 2017 16:13:03 +0000 (18:13 +0200)]
irqchip/irq-omap-intc: Do not statically initialize variables
omap_nr_pending and omap_nr_irqs variables are initialized
right at the beginning of intc_of_init function, so there's
no need to statically initialize them.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Tony Lindgren <tony@atomide.com> Cc: linux-omap@vger.kernel.org Cc: Jason Cooper <jason@lakedaemon.net> Link: https://lkml.kernel.org/r/20171016161303.veumgcd3xom5c54r@lenoch
Ladislav Michl [Mon, 16 Oct 2017 16:04:22 +0000 (18:04 +0200)]
irqchip/irq-omap-intc: Remove omap3_init_irq()
All mach-omap2 variants are device tree only now, so this function is dead
code. Remove it.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Tony Lindgren <tony@atomide.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: linux-omap@vger.kernel.org Cc: Jason Cooper <jason@lakedaemon.net> Link: https://lkml.kernel.org/r/20171016160422.uu2i7vvrgy7cc4aw@lenoch
Linus Torvalds [Sat, 7 Oct 2017 17:07:51 +0000 (10:07 -0700)]
Merge branch 'i2c/for-current-4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
Pull i2c fixes from Wolfram Sang:
"I2C has three driver fixes for the newly introduced drivers and one ID
addition for the i801 driver"
* 'i2c/for-current-4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: i2c-stm32f7: make structure stm32f7_setup static const
i2c: ensure termination of *_device_id tables
i2c: i801: Add support for Intel Cedar Fork
i2c: stm32f7: fix setup structure
Linus Torvalds [Sat, 7 Oct 2017 17:03:03 +0000 (10:03 -0700)]
Merge tag 'mmc-v4.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
Pull MMC fixes from Ulf Hansson:
"MMC core:
- Fix driver strength selection when selecting hs400es
- Delete bounce buffer handling:
This change fixes a problem related to how bounce buffers are being
allocated. However, instead of trying to fix that, let's just
remove the mmc bounce buffer code altogether, as it has practically
no use.
MMC host:
- meson-gx: A couple of fixes related to clock/phase/tuning
- sdhci-xenon: Fix clock resource by adding an optional bus clock"
* tag 'mmc-v4.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
mmc: sdhci-xenon: Fix clock resource by adding an optional bus clock
mmc: meson-gx: include tx phase in the tuning process
mmc: meson-gx: fix rx phase reset
mmc: meson-gx: make sure the clock is rounded down
mmc: Delete bounce buffer handling
mmc: core: add driver strength selection when selecting hs400es
Linus Torvalds [Sat, 7 Oct 2017 00:59:32 +0000 (17:59 -0700)]
Merge tag 'hwmon-for-linus-v4.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
Pull hwmon fix from Guenter Roeck:
"Fix up error path in xgene driver"
* tag 'hwmon-for-linus-v4.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
hwmon: (xgene) Fix up error handling path mixup in 'xgene_hwmon_probe()'
Linus Torvalds [Fri, 6 Oct 2017 23:25:08 +0000 (16:25 -0700)]
Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
Pull clk fixes from Stephen Boyd:
- build fix to export the clk_bulk_prepare() symbol
- suspend fix for Samsung Exynos SoCs where we need to keep clks on
across suspend
- two critical clk markings for clks that shouldn't ever turn off on
Rockchip SoCs
- a fix for a copy-paste mistake on Rockchip rk3128 causing some clks
to touch the same bit and trample over one another
* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
clk: samsung: exynos4: Enable VPLL and EPLL clocks for suspend/resume cycle
clk: Export clk_bulk_prepare()
clk: rockchip: add sclk_timer5 as critical clock on rk3128
clk: rockchip: fix up rk3128 pvtm and mipi_24m gate regs error
clk: rockchip: add pclk_pmu as critical clock on rk3128
Linus Torvalds [Fri, 6 Oct 2017 22:57:08 +0000 (15:57 -0700)]
Merge tag 'arc-4.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc
Pull ARC udpates from Vineet Gupta:
- updates for various platforms
- boot log updates for upcoming HS48 family of cores (dual issue)
* tag 'arc-4.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
ARC: [plat-hsdk]: Add reset controller node to manage ethernet reset
ARC: [plat-hsdk]: Temporary fix to set CPU frequency to 1GHz
ARC: fix allnoconfig build warning
ARCv2: boot log: identify HS48 cores (dual issue)
ARC: boot log: decontaminate ARCv2 ISA_CONFIG register
arc: remove redundant UTS_MACHINE define in arch/arc/Makefile
ARC: [plat-eznps] Update platform maintainer as Noam left
ARC: [plat-hsdk] use actual clk driver to manage cpu clk
ARC: [*defconfig] Reenable soft lock-up detector
ARC: [plat-axs10x] sdio: Temporary fix of sdio ciu frequency
ARC: [plat-hsdk] sdio: Temporary fix of sdio ciu frequency
ARC: [plat-axs103] Add temporary quirk to reset ethernet IP
Linus Torvalds [Fri, 6 Oct 2017 22:53:36 +0000 (15:53 -0700)]
Merge tag 'xfs-4.14-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
Pull xfs fixes from Darrick Wong:
- fix a race between overlapping copy on write aio
- fix cow fork swapping when we defragment reflinked files
* tag 'xfs-4.14-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
xfs: handle racy AIO in xfs_reflink_end_cow
xfs: always swap the cow forks when swapping extents
Linus Torvalds [Fri, 6 Oct 2017 19:13:50 +0000 (12:13 -0700)]
Merge branch 'for-linus' of git://git.kernel.dk/linux-block
Pull block fixes from Jens Axboe:
"A collection of fixes for this series. This contains:
- NVMe pull request from Christoph, one uuid attribute fix, and one
fix for the controller memory buffer address for remapped BARs.
- use-after-free fix for bsg, from Benjamin Block.
- bcache race/use-after-free fix for a list traversal, fixing a
regression in this merge window. From Coly Li.
- null_blk change configfs dependency change from a 'depends' to a
'select'. This is a change from this merge window as well. From me.
- nbd signal fix from Josef, fixing a regression introduced with the
status code changes.
- nbd MAINTAINERS mailing list entry update.
- blk-throttle stall fix from Joseph Qi.
- blk-mq-debugfs fix from Omar, fixing an issue where we don't
register the IO scheduler debugfs directory, if the driver is
loaded with it. Only shows up if you switch through the sysfs
interface"
* 'for-linus' of git://git.kernel.dk/linux-block:
bsg-lib: fix use-after-free under memory-pressure
nvme-pci: Use PCI bus address for data/queues in CMB
blk-mq-debugfs: fix device sched directory for default scheduler
null_blk: change configfs dependency to select
blk-throttle: fix possible io stall when upgrade to max
MAINTAINERS: update list for NBD
nbd: fix -ERESTARTSYS handling
nvme: fix visibility of "uuid" ns attribute
bcache: use llist_for_each_entry_safe() in __closure_wake_up()
Linus Torvalds [Fri, 6 Oct 2017 19:07:09 +0000 (12:07 -0700)]
Merge tag 'pci-v4.14-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
Pull PCI fixes from Bjorn Helgaas:
"Fix legacy IDE probe issues exposed by recent PCI core IRQ mapping
changes (Bartlomiej Zolnierkiewicz, Lorenzo Pieralisi)"
* tag 'pci-v4.14-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
ide: fix IRQ assignment for PCI bus order probing
ide: pci: free PCI BARs on initialization failure
ide: free hwif->portdev on hwif_init() failure
Linus Torvalds [Fri, 6 Oct 2017 18:31:46 +0000 (11:31 -0700)]
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Catalin Marinas:
- Bring initialisation of user space undefined instruction handling
early (core_initcall) since late_initcall() happens after modprobe in
initramfs is invoked. Similar fix for fpsimd initialisation
- Increase the kernel stack when KASAN is enabled
- Bring the PCI ACS enabling earlier via the
iort_init_platform_devices()
- Fix misleading data abort address printing (decimal vs hex)
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: Ensure fpsimd support is ready before userspace is active
arm64: Ensure the instruction emulation is ready for userspace
arm64: Use larger stacks when KASAN is selected
ACPI/IORT: Fix PCI ACS enablement
arm64: fix misleading data abort decoding
Linus Torvalds [Fri, 6 Oct 2017 18:28:34 +0000 (11:28 -0700)]
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull KVM fixes from Radim Krčmář:
- fix PPC XIVE interrupt delivery
- fix x86 RCU breakage from asynchronous page faults when built without
PREEMPT_COUNT
- fix x86 build with -frecord-gcc-switches
- fix x86 build without X86_LOCAL_APIC
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: add X86_LOCAL_APIC dependency
x86/kvm: Move kvm_fastop_exception to .fixup section
kvm/x86: Avoid async PF preempting the kernel incorrectly
KVM: PPC: Book3S: Fix server always zero from kvmppc_xive_get_xive()
Linus Torvalds [Fri, 6 Oct 2017 18:25:55 +0000 (11:25 -0700)]
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma
Pull rdma fixes from Doug Ledford:
"This is a pretty small pull request. Only 6 patches in total. There
are no outstanding -rc patches on the mailing list after this pull
request, so only if some new issues are discovered in the remainder of
the rc cycles will you hear from me again.
Summary:
- a fix for iwpm netlink usage
- a fix for error unwinding in mlx5
- two fixes to vlan handling in qedr
- a couple small i40iw fixes"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma:
i40iw: Fix port number for query QP
i40iw: Add missing memory barriers
RDMA/qedr: Parse vlan priority as sl
RDMA/qedr: Parse VLAN ID correctly and ignore the value of zero
IB/mlx5: Fix label order in error path handling
RDMA/iwpm: Properly mark end of NL messages
Linus Torvalds [Fri, 6 Oct 2017 16:03:08 +0000 (09:03 -0700)]
Merge branch 'for-4.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux
Pull btrfs fixes from David Sterba:
"Two more fixes for bugs introduced in 4.13.
The sector_t problem with 32bit architecture and !LBDAF config seems
serious but the number of affected deployments is hopefully low.
The clashing status bits could lead to a confusing in-memory state of
the whole-filesystem operations if used with the quota override sysfs
knob"
* 'for-4.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
Btrfs: fix overlap of fs_info::flags values
btrfs: avoid overflow when sector_t is 32 bit
Linus Torvalds [Fri, 6 Oct 2017 16:01:45 +0000 (09:01 -0700)]
Merge tag 'ceph-for-4.14-rc4' of git://github.com/ceph/ceph-client
Pull ceph fixes from Ilya Dryomov:
"Two fixups for CephFS snapshot-handling patches in -rc1"
* tag 'ceph-for-4.14-rc4' of git://github.com/ceph/ceph-client:
ceph: fix __choose_mds() for LSSNAP request
ceph: properly queue cap snap for newly created snap realm
Linus Torvalds [Fri, 6 Oct 2017 15:52:53 +0000 (08:52 -0700)]
Merge branch 'overlayfs-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs
Pull overlayfs fixes from Miklos Szeredi:
"Fix a regression in 4.14 and one in 4.13. The latter is a case when
Docker is doing something it really shouldn't and gets away with it.
We now print a warning instead of erroring out.
There are also fixes to several error paths"
* 'overlayfs-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs:
ovl: fix regression caused by exclusive upper/work dir protection
ovl: fix missing unlock_rename() in ovl_do_copy_up()
ovl: fix dentry leak in ovl_indexdir_cleanup()
ovl: fix dput() of ERR_PTR in ovl_cleanup_index()
ovl: fix error value printed in ovl_lookup_index()
ovl: fix may_write_real() for overlayfs directories
Linus Torvalds [Fri, 6 Oct 2017 15:47:21 +0000 (08:47 -0700)]
Merge tag 'powerpc-4.14-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
Pull powerpc fixes from Michael Ellerman:
"Nine small fixes, really nothing that stands out.
A work-around for a spurious MCE on Power9. A CXL fault handling fix,
some fixes to the new XIVE code, and a fix to the new 32-bit
STRICT_KERNEL_RWX code.
Fixes for old code/stable: an fix to an incorrect TLB flush on boot
but not on any current machines, a compile error on 4xx and a fix to
memory hotplug when using radix (Power9).
Thanks to: Anton Blanchard, Cédric Le Goater, Christian Lamparter,
Christophe Leroy, Christophe Lombard, Guenter Roeck, Jeremy Kerr,
Michael Neuling, Nicholas Piggin"
* tag 'powerpc-4.14-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
powerpc/powernv: Increase memory block size to 1GB on radix
powerpc/mm: Call flush_tlb_kernel_range with interrupts enabled
powerpc/xive: Clear XIVE internal structures when a CPU is removed
powerpc/xive: Fix IPI reset
powerpc/4xx: Fix compile error with 64K pages on 40x, 44x
powerpc: Fix action argument for cpufeatures-based TLB flush
cxl: Fix memory page not handled
powerpc: Fix workaround for spurious MCE on POWER9
powerpc: Handle MCE on POWER9 with only DSISR bit 30 set
Linus Torvalds [Fri, 6 Oct 2017 15:42:06 +0000 (08:42 -0700)]
Merge tag 'drm-fixes-for-v4.14-rc4' of git://people.freedesktop.org/~airlied/linux
Pull drm fixes from Dave Airlie:
"Some i915 fixes from the last two weeks (as they were on a strange
base and I just waited for rc3), also a single sun4i hdmi fix"
* tag 'drm-fixes-for-v4.14-rc4' of git://people.freedesktop.org/~airlied/linux:
drm/i915/glk: Fix DMC/DC state idleness calculation
drm/i915/cnl: Reprogram DMC firmware after S3/S4 resume
drm/i915: Fix DDI PHY init if it was already on
drm/sun4i: hdmi: Disable clks in bind function error path and unbind function
drm/i915/bios: ignore HDMI on port A
drm/i915: remove redundant variable hw_check
drm/i915: always update ELD connector type after get modes
Linus Torvalds [Fri, 6 Oct 2017 15:36:41 +0000 (08:36 -0700)]
Merge branch 'core-watchdog-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull watchddog clean-up and fixes from Thomas Gleixner:
"The watchdog (hard/softlockup detector) code is pretty much broken in
its current state. The patch series addresses this by removing all
duct tape and refactoring it into a workable state.
The reasons why I ask for inclusion that late in the cycle are:
1) The code causes lockdep splats vs. hotplug locking which get
reported over and over. Unfortunately there is no easy fix.
2) The risk of breakage is minimal because it's already broken
3) As 4.14 is a long term stable kernel, I prefer to have working
watchdog code in that and the lockdep issues resolved. I wouldn't
ask you to pull if 4.14 wouldn't be a LTS kernel or if the
solution would be easy to backport.
4) The series was around before the merge window opened, but then got
delayed due to the UP failure caused by the for_each_cpu()
surprise which we discussed recently.
Changes vs. V1:
- Addressed your review points
- Addressed the warning in the powerpc code which was discovered late
- Changed two function names which made sense up to a certain point
in the series. Now they match what they do in the end.
- Fixed a 'unused variable' warning, which got not detected by the
intel robot. I triggered it when trying all possible related config
combinations manually. Randconfig testing seems not random enough.
The changes have been tested by and reviewed by Don Zickus and tested
and acked by Micheal Ellerman for powerpc"
* 'core-watchdog-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (36 commits)
watchdog/core: Put softlockup_threads_initialized under ifdef guard
watchdog/core: Rename some softlockup_* functions
powerpc/watchdog: Make use of watchdog_nmi_probe()
watchdog/core, powerpc: Lock cpus across reconfiguration
watchdog/core, powerpc: Replace watchdog_nmi_reconfigure()
watchdog/hardlockup/perf: Fix spelling mistake: "permanetely" -> "permanently"
watchdog/hardlockup/perf: Cure UP damage
watchdog/hardlockup: Clean up hotplug locking mess
watchdog/hardlockup/perf: Simplify deferred event destroy
watchdog/hardlockup/perf: Use new perf CPU enable mechanism
watchdog/hardlockup/perf: Implement CPU enable replacement
watchdog/hardlockup/perf: Implement init time detection of perf
watchdog/hardlockup/perf: Implement init time perf validation
watchdog/core: Get rid of the racy update loop
watchdog/core, powerpc: Make watchdog_nmi_reconfigure() two stage
watchdog/sysctl: Clean up sysctl variable name space
watchdog/sysctl: Get rid of the #ifdeffery
watchdog/core: Clean up header mess
watchdog/core: Further simplify sysctl handling
watchdog/core: Get rid of the thread teardown/setup dance
...
arm64: Ensure fpsimd support is ready before userspace is active
We register the pm/hotplug callbacks for FPSIMD as late_initcall,
which happens after the userspace is active (from initramfs via
populate_rootfs, a rootfs_initcall). Make sure we are ready even
before the userspace could potentially use it, by promoting to
a core_initcall.
Cc: Will Deacon <will.deacon@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Dave Martin <dave.martin@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
arm64: Ensure the instruction emulation is ready for userspace
We trap and emulate some instructions (e.g, mrs, deprecated instructions)
for the userspace. However the handlers for these are registered as
late_initcalls and the userspace could be up and running from the initramfs
by that time (with populate_rootfs, which is a rootfs_initcall()). This
could cause problems for the early applications ending up in failure
like :
Anton Blanchard [Thu, 7 Sep 2017 05:05:51 +0000 (15:05 +1000)]
powerpc/powernv: Increase memory block size to 1GB on radix
Memory hot unplug on PowerNV radix hosts is broken. Our memory block
size is 256MB but since we map the linear region with very large
pages, each pte we tear down maps 1GB.
A hot unplug of one 256MB memory block results in 768MB of memory
getting unintentionally unmapped. At this point we are likely to oops.
Fix this by increasing our memory block size to 1GB on PowerNV radix
hosts.
Fixes: 4b5d62ca17a1 ("powerpc/mm: add radix__remove_section_mapping()") Cc: stable@vger.kernel.org # v4.11+ Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Dave Airlie [Fri, 6 Oct 2017 01:09:47 +0000 (11:09 +1000)]
Merge tag 'drm-misc-fixes-2017-10-05' of git://anongit.freedesktop.org/git/drm-misc into drm-fixes
One bugfix in sun4i for 4.14
* tag 'drm-misc-fixes-2017-10-05' of git://anongit.freedesktop.org/git/drm-misc:
drm/sun4i: hdmi: Disable clks in bind function error path and unbind function
Dave Airlie [Fri, 6 Oct 2017 01:09:29 +0000 (11:09 +1000)]
Merge tag 'drm-intel-fixes-2017-10-04' of git://anongit.freedesktop.org/git/drm-intel into drm-fixes
drm/i915 fixes for 4.14-rc4:
All 3 highest GLK bugs fixed by Imre:
- GLK drv reload - Fix DDI Phy init if it was already on.
- GLK suspend resume - Reprogram DMC firmware after s3/s4.
- GLK DC states - Fix idleness calculation.
* tag 'drm-intel-fixes-2017-10-04' of git://anongit.freedesktop.org/git/drm-intel:
drm/i915/glk: Fix DMC/DC state idleness calculation
drm/i915/cnl: Reprogram DMC firmware after S3/S4 resume
drm/i915: Fix DDI PHY init if it was already on
projects / linux.git / log