* [PATCH v7 3/8] KVM: arm/arm64: Don't cache the timer IRQ level
From: Auger Eric @ 2017-12-12 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <24ae6f9e-8f83-6b95-a7a0-d900c37b4a7f@redhat.com>
On 11/12/17 21:51, Auger Eric wrote:
> Hi Christoffer,
> On 07/12/17 11:54, Christoffer Dall wrote:
>> The timer was modeled after a strict idea of modelling an interrupt line
>> level in software, meaning that only transitions in the level needed to
>> be reported to the VGIC. This works well for the timer, because the
>> arch timer code is in complete control of the device and can track the
>> transitions of the line.
>>
>> However, as we are about to support using the HW bit in the VGIC not
>> just for the timer, but also for VFIO which cannot track transitions of
>> the interrupt line, we have to decide on an interface for level
>> triggered mapped interrupts to the GIC, which both the timer and VFIO
>> can use.
>>
>> VFIO only sees an asserting transition of the physical interrupt line,
>> and tells the VGIC when that happens. That means that part of the
>> interrupt flow is offloaded to the hardware.
>>
>> To use the same interface for VFIO devices and the timer, we therefore
>> have to change the timer (we cannot change VFIO because it doesn't know
>> the details of the device it is assigning to a VM).
>>
>> Luckily, changing the timer is simple, we just need to stop 'caching'
>> the line level, but instead let the VGIC know the state of the timer
>> every time there is a potential change in the line level, and when the
>> line level should be asserted from the timer ISR. The VGIC can ignore
>> extra notifications using its validate mechanism.
>
> I was confused by the fact we say we stop caching the line level but
> vtimer->irq.level still exists, is updated in the vtimer host ISR and
> kvm_timer_update_state() and read in many places.
>
> I feel difficult to figure out if each time we use the vtimer->irq.level
> value it is safe to use it.
>
> Also for the validate() to succeed we need the vgic irq->line_level to
> to be 0. I understand this is properly handled for mapped level irqs in
> next patch which does that on the populate_lr. However I currently fail
> to understand why the timer level sensitive mapped IRQ does not require
> the next patch to work.
OK reading again "[PATCH v7 7/8] KVM: arm/arm64: Provide a
get_input_level for the arch timer", I now understand it works because
we had the
kvm_timer_sync_hwstate toggling down the line on VM exit. After the
changes of next patch this can be safely removed.
Not related to this patch but I noticed
Documentation/virtual/kvm/arm/vgic-mapped-irqs.txt now is outdated.
>
> Thanks
>
> Eric
>
>>
>> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
>> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>> ---
>> virt/kvm/arm/arch_timer.c | 20 +++++++++++++-------
>> 1 file changed, 13 insertions(+), 7 deletions(-)
>>
>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
>> index 4151250ce8da..dd5aca05c500 100644
>> --- a/virt/kvm/arm/arch_timer.c
>> +++ b/virt/kvm/arm/arch_timer.c
>> @@ -99,11 +99,9 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
>> }
>> vtimer = vcpu_vtimer(vcpu);
>>
>> - if (!vtimer->irq.level) {
>> - vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
>> - if (kvm_timer_irq_can_fire(vtimer))
>> - kvm_timer_update_irq(vcpu, true, vtimer);
>> - }
>> + vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
>> + if (kvm_timer_irq_can_fire(vtimer))
>> + kvm_timer_update_irq(vcpu, true, vtimer);
>>
>> if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
>> kvm_vtimer_update_mask_user(vcpu);
>> @@ -324,12 +322,20 @@ static void kvm_timer_update_state(struct kvm_vcpu *vcpu)
>> struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>> struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
>> struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
>> + bool level;
>>
>> if (unlikely(!timer->enabled))
>> return;
>>
>> - if (kvm_timer_should_fire(vtimer) != vtimer->irq.level)
>> - kvm_timer_update_irq(vcpu, !vtimer->irq.level, vtimer);
>> + /*
>> + * The vtimer virtual interrupt is a 'mapped' interrupt, meaning part
>> + * of its lifecycle is offloaded to the hardware, and we therefore may
>> + * not have lowered the irq.level value before having to signal a new
>> + * interrupt, but have to signal an interrupt every time the level is
>> + * asserted.
>> + */
>> + level = kvm_timer_should_fire(vtimer);
>> + kvm_timer_update_irq(vcpu, level, vtimer);
>>
>> if (kvm_timer_should_fire(ptimer) != ptimer->irq.level)
>> kvm_timer_update_irq(vcpu, !ptimer->irq.level, ptimer);
>>
^ permalink raw reply
* [PATCH v7 4/8] KVM: arm/arm64: vgic: Support level-triggered mapped interrupts
From: Auger Eric @ 2017-12-12 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207105418.22428-5-christoffer.dall@linaro.org>
Hi Christoffer,
On 07/12/17 11:54, Christoffer Dall wrote:
> Level-triggered mapped IRQs are special because we only observe rising
> edges as input to the VGIC, and we don't set the EOI flag and therefore
> are not told when the level goes down, so that we can re-queue a new
> interrupt when the level goes up.
>
> One way to solve this problem is to side-step the logic of the VGIC and
> special case the validation in the injection path, but it has the
> unfortunate drawback of having to peak into the physical GIC state
> whenever we want to know if the interrupt is pending on the virtual
> distributor.
>
> Instead, we can maintain the current semantics of a level triggered
> interrupt by sort of treating it as an edge-triggered interrupt,
> following from the fact that we only observe an asserting edge. This
> requires us to be a bit careful when populating the LRs and when folding
> the state back in though:
>
> * We lower the line level when populating the LR, so that when
> subsequently observing an asserting edge, the VGIC will do the right
> thing.
>
> * If the guest never acked the interrupt while running (for example if
> it had masked interrupts at the CPU level while running), we have
> to preserve the pending state of the LR and move it back to the
> line_level field of the struct irq when folding LR state.
>
> If the guest never acked the interrupt while running, but changed the
> device state and lowered the line (again with interrupts masked) then
> we need to observe this change in the line_level.
>
> Both of the above situations are solved by sampling the physical line
> and set the line level when folding the LR back.
>
> * Finally, if the guest never acked the interrupt while running and
> sampling the line reveals that the device state has changed and the
> line has been lowered, we must clear the physical active state, since
> we will otherwise never be told when the interrupt becomes asserted
> again.
>
> This has the added benefit of making the timer optimization patches
> (https://lists.cs.columbia.edu/pipermail/kvmarm/2017-July/026343.html) a
> bit simpler, because the timer code doesn't have to clear the active
> state on the sync anymore. It also potentially improves the performance
> of the timer implementation because the GIC knows the state or the LR
> and only needs to clear the
> active state when the pending bit in the LR is still set, where the
> timer has to always clear it when returning from running the guest with
> an injected timer interrupt.
>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Looks good to me.
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Thanks
Eric
> ---
> virt/kvm/arm/vgic/vgic-v2.c | 29 +++++++++++++++++++++++++++++
> virt/kvm/arm/vgic/vgic-v3.c | 29 +++++++++++++++++++++++++++++
> virt/kvm/arm/vgic/vgic.c | 23 +++++++++++++++++++++++
> virt/kvm/arm/vgic/vgic.h | 7 +++++++
> 4 files changed, 88 insertions(+)
>
> diff --git a/virt/kvm/arm/vgic/vgic-v2.c b/virt/kvm/arm/vgic/vgic-v2.c
> index 80897102da26..c32d7b93ffd1 100644
> --- a/virt/kvm/arm/vgic/vgic-v2.c
> +++ b/virt/kvm/arm/vgic/vgic-v2.c
> @@ -105,6 +105,26 @@ void vgic_v2_fold_lr_state(struct kvm_vcpu *vcpu)
> irq->pending_latch = false;
> }
>
> + /*
> + * Level-triggered mapped IRQs are special because we only
> + * observe rising edges as input to the VGIC.
> + *
> + * If the guest never acked the interrupt we have to sample
> + * the physical line and set the line level, because the
> + * device state could have changed or we simply need to
> + * process the still pending interrupt later.
> + *
> + * If this causes us to lower the level, we have to also clear
> + * the physical active state, since we will otherwise never be
> + * told when the interrupt becomes asserted again.
> + */
> + if (vgic_irq_is_mapped_level(irq) && (val & GICH_LR_PENDING_BIT)) {
> + irq->line_level = vgic_get_phys_line_level(irq);
> +
> + if (!irq->line_level)
> + vgic_irq_set_phys_active(irq, false);
> + }
> +
> spin_unlock_irqrestore(&irq->irq_lock, flags);
> vgic_put_irq(vcpu->kvm, irq);
> }
> @@ -162,6 +182,15 @@ void vgic_v2_populate_lr(struct kvm_vcpu *vcpu, struct vgic_irq *irq, int lr)
> val |= GICH_LR_EOI;
> }
>
> + /*
> + * Level-triggered mapped IRQs are special because we only observe
> + * rising edges as input to the VGIC. We therefore lower the line
> + * level here, so that we can take new virtual IRQs. See
> + * vgic_v2_fold_lr_state for more info.
> + */
> + if (vgic_irq_is_mapped_level(irq) && (val & GICH_LR_PENDING_BIT))
> + irq->line_level = false;
> +
> /* The GICv2 LR only holds five bits of priority. */
> val |= (irq->priority >> 3) << GICH_LR_PRIORITY_SHIFT;
>
> diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
> index 2f05f732d3fd..a14423a0d383 100644
> --- a/virt/kvm/arm/vgic/vgic-v3.c
> +++ b/virt/kvm/arm/vgic/vgic-v3.c
> @@ -96,6 +96,26 @@ void vgic_v3_fold_lr_state(struct kvm_vcpu *vcpu)
> irq->pending_latch = false;
> }
>
> + /*
> + * Level-triggered mapped IRQs are special because we only
> + * observe rising edges as input to the VGIC.
> + *
> + * If the guest never acked the interrupt we have to sample
> + * the physical line and set the line level, because the
> + * device state could have changed or we simply need to
> + * process the still pending interrupt later.
> + *
> + * If this causes us to lower the level, we have to also clear
> + * the physical active state, since we will otherwise never be
> + * told when the interrupt becomes asserted again.
> + */
> + if (vgic_irq_is_mapped_level(irq) && (val & ICH_LR_PENDING_BIT)) {
> + irq->line_level = vgic_get_phys_line_level(irq);
> +
> + if (!irq->line_level)
> + vgic_irq_set_phys_active(irq, false);
> + }
> +
> spin_unlock_irqrestore(&irq->irq_lock, flags);
> vgic_put_irq(vcpu->kvm, irq);
> }
> @@ -145,6 +165,15 @@ void vgic_v3_populate_lr(struct kvm_vcpu *vcpu, struct vgic_irq *irq, int lr)
> val |= ICH_LR_EOI;
> }
>
> + /*
> + * Level-triggered mapped IRQs are special because we only observe
> + * rising edges as input to the VGIC. We therefore lower the line
> + * level here, so that we can take new virtual IRQs. See
> + * vgic_v3_fold_lr_state for more info.
> + */
> + if (vgic_irq_is_mapped_level(irq) && (val & ICH_LR_PENDING_BIT))
> + irq->line_level = false;
> +
> /*
> * We currently only support Group1 interrupts, which is a
> * known defect. This needs to be addressed at some point.
> diff --git a/virt/kvm/arm/vgic/vgic.c b/virt/kvm/arm/vgic/vgic.c
> index b168a328a9e0..607cbbc27a1c 100644
> --- a/virt/kvm/arm/vgic/vgic.c
> +++ b/virt/kvm/arm/vgic/vgic.c
> @@ -144,6 +144,29 @@ void vgic_put_irq(struct kvm *kvm, struct vgic_irq *irq)
> kfree(irq);
> }
>
> +/* Get the input level of a mapped IRQ directly from the physical GIC */
> +bool vgic_get_phys_line_level(struct vgic_irq *irq)
> +{
> + bool line_level;
> +
> + BUG_ON(!irq->hw);
> +
> + WARN_ON(irq_get_irqchip_state(irq->host_irq,
> + IRQCHIP_STATE_PENDING,
> + &line_level));
> + return line_level;
> +}
> +
> +/* Set/Clear the physical active state */
> +void vgic_irq_set_phys_active(struct vgic_irq *irq, bool active)
> +{
> +
> + BUG_ON(!irq->hw);
> + WARN_ON(irq_set_irqchip_state(irq->host_irq,
> + IRQCHIP_STATE_ACTIVE,
> + active));
> +}
> +
> /**
> * kvm_vgic_target_oracle - compute the target vcpu for an irq
> *
> diff --git a/virt/kvm/arm/vgic/vgic.h b/virt/kvm/arm/vgic/vgic.h
> index efbcf8f96f9c..d0787983a357 100644
> --- a/virt/kvm/arm/vgic/vgic.h
> +++ b/virt/kvm/arm/vgic/vgic.h
> @@ -104,6 +104,11 @@ static inline bool irq_is_pending(struct vgic_irq *irq)
> return irq->pending_latch || irq->line_level;
> }
>
> +static inline bool vgic_irq_is_mapped_level(struct vgic_irq *irq)
> +{
> + return irq->config == VGIC_CONFIG_LEVEL && irq->hw;
> +}
> +
> /*
> * This struct provides an intermediate representation of the fields contained
> * in the GICH_VMCR and ICH_VMCR registers, such that code exporting the GIC
> @@ -140,6 +145,8 @@ vgic_get_mmio_region(struct kvm_vcpu *vcpu, struct vgic_io_device *iodev,
> struct vgic_irq *vgic_get_irq(struct kvm *kvm, struct kvm_vcpu *vcpu,
> u32 intid);
> void vgic_put_irq(struct kvm *kvm, struct vgic_irq *irq);
> +bool vgic_get_phys_line_level(struct vgic_irq *irq);
> +void vgic_irq_set_phys_active(struct vgic_irq *irq, bool active);
> bool vgic_queue_irq_unlock(struct kvm *kvm, struct vgic_irq *irq,
> unsigned long flags);
> void vgic_kick_vcpus(struct kvm *kvm);
>
^ permalink raw reply
* [PATCH v7 5/8] KVM: arm/arm64: Support a vgic interrupt line level sample function
From: Auger Eric @ 2017-12-12 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207105418.22428-6-christoffer.dall@linaro.org>
Hi Christoffer,
On 07/12/17 11:54, Christoffer Dall wrote:
> The GIC sometimes need to sample the physical line of a mapped
> interrupt. As we know this to be notoriously slow, provide a callback
> function for devices (such as the timer) which can do this much faster
> than talking to the distributor, for example by comparing a few
> in-memory values. Fall back to the good old method of poking the
> physical GIC if no callback is provided.
>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> include/kvm/arm_vgic.h | 13 ++++++++++++-
> virt/kvm/arm/arch_timer.c | 3 ++-
> virt/kvm/arm/vgic/vgic.c | 12 +++++++++---
> 3 files changed, 23 insertions(+), 5 deletions(-)
>
> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> index 8c896540a72c..cdbd142ca7f2 100644
> --- a/include/kvm/arm_vgic.h
> +++ b/include/kvm/arm_vgic.h
> @@ -130,6 +130,17 @@ struct vgic_irq {
> u8 priority;
> enum vgic_irq_config config; /* Level or edge */
>
> + /*
> + * Callback function pointer to in-kernel devices that can tell us the
> + * state of the input level of mapped level-triggered IRQ faster than
> + * peaking into the physical GIC.
> + *
> + * Always called in non-preemptible section and the functions can use
> + * kvm_arm_get_running_vcpu() to get the vcpu pointer for private
> + * IRQs.
> + */
> + bool (*get_input_level)(int vintid);
> +
> void *owner; /* Opaque pointer to reserve an interrupt
> for in-kernel devices. */
> };
> @@ -331,7 +342,7 @@ void kvm_vgic_init_cpu_hardware(void);
> int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid, unsigned int intid,
> bool level, void *owner);
> int kvm_vgic_map_phys_irq(struct kvm_vcpu *vcpu, unsigned int host_irq,
> - u32 vintid);
> + u32 vintid, bool (*get_input_level)(int vindid));
> int kvm_vgic_unmap_phys_irq(struct kvm_vcpu *vcpu, unsigned int vintid);
> bool kvm_vgic_map_is_active(struct kvm_vcpu *vcpu, unsigned int vintid);
>
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index dd5aca05c500..e78ba5e20f74 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -840,7 +840,8 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
> return -EINVAL;
> }
>
> - ret = kvm_vgic_map_phys_irq(vcpu, host_vtimer_irq, vtimer->irq.irq);
> + ret = kvm_vgic_map_phys_irq(vcpu, host_vtimer_irq, vtimer->irq.irq,
> + NULL);
> if (ret)
> return ret;
>
> diff --git a/virt/kvm/arm/vgic/vgic.c b/virt/kvm/arm/vgic/vgic.c
> index 607cbbc27a1c..eadabb249d2a 100644
> --- a/virt/kvm/arm/vgic/vgic.c
> +++ b/virt/kvm/arm/vgic/vgic.c
Nit: the comment "Get the input level of a mapped IRQ directly from the
physical GIC" is not strictly correct anymore
> @@ -151,6 +151,9 @@ bool vgic_get_phys_line_level(struct vgic_irq *irq)
>
> BUG_ON(!irq->hw);
>
> + if (irq->get_input_level)
> + return irq->get_input_level(irq->intid);
> +
> WARN_ON(irq_get_irqchip_state(irq->host_irq,
> IRQCHIP_STATE_PENDING,
> &line_level));
> @@ -436,7 +439,8 @@ int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid, unsigned int intid,
>
> /* @irq->irq_lock must be held */
> static int kvm_vgic_map_irq(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
> - unsigned int host_irq)
> + unsigned int host_irq,
> + bool (*get_input_level)(int vindid))
> {
> struct irq_desc *desc;
> struct irq_data *data;
> @@ -456,6 +460,7 @@ static int kvm_vgic_map_irq(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
> irq->hw = true;
> irq->host_irq = host_irq;
> irq->hwintid = data->hwirq;
> + irq->get_input_level = get_input_level;
> return 0;
> }
>
> @@ -464,10 +469,11 @@ static inline void kvm_vgic_unmap_irq(struct vgic_irq *irq)
> {
> irq->hw = false;
> irq->hwintid = 0;
> + irq->get_input_level = NULL;
> }
>
> int kvm_vgic_map_phys_irq(struct kvm_vcpu *vcpu, unsigned int host_irq,
> - u32 vintid)
> + u32 vintid, bool (*get_input_level)(int vindid))
> {
> struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, vintid);
> unsigned long flags;
> @@ -476,7 +482,7 @@ int kvm_vgic_map_phys_irq(struct kvm_vcpu *vcpu, unsigned int host_irq,
> BUG_ON(!irq);
>
> spin_lock_irqsave(&irq->irq_lock, flags);
> - ret = kvm_vgic_map_irq(vcpu, irq, host_irq);
> + ret = kvm_vgic_map_irq(vcpu, irq, host_irq, get_input_level);
> spin_unlock_irqrestore(&irq->irq_lock, flags);
> vgic_put_irq(vcpu->kvm, irq);
>
>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Thanks
Eric
^ permalink raw reply
* [PATCH v7 6/8] KVM: arm/arm64: Support VGIC dist pend/active changes for mapped IRQs
From: Auger Eric @ 2017-12-12 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207105418.22428-7-christoffer.dall@linaro.org>
Hi Christoffer,
On 07/12/17 11:54, Christoffer Dall wrote:
> For mapped IRQs (with the HW bit set in the LR) we have to follow some
> rules of the architecture. One of these rules is that VM must not be
> allowed to deactivate a virtual interrupt with the HW bit set unless the
> physical interrupt is also active.
>
> This works fine when injecting mapped interrupts, because we leave it up
> to the injector to either set EOImode==1 or manually set the active
> state of the physical interrupt.
>
> However, the guest can set virtual interrupt to be pending or active by
> writing to the virtual distributor, which could lead to deactivating a
> virtual interrupt with the HW bit set without the physical interrupt
> being active.
>
> We could set the physical interrupt to active whenever we are about to
> enter the VM with a HW interrupt either pending or active, but that
> would be really slow, especially on GICv2. So we take the long way
> around and do the hard work when needed, which is expected to be
> extremely rare.
>
> When the VM sets the pending state for a HW interrupt on the virtual
> distributor we set the active state on the physical distributor, because
> the virtual interrupt can become active and then the guest can
> deactivate it.
>
> When the VM clears the pending state we also clear it on the physical
> side, because the injector might otherwise raise the interrupt. We also
> clear the physical active state when the virtual interrupt is not
> active, since otherwise a SPEND/CPEND sequence from the guest would
> prevent signaling of future interrupts.
>
> Changing the state of mapped interrupts from userspace is not supported,
> and it's expected that userspace unmaps devices from VFIO before
> attempting to set the interrupt state, because the interrupt state is
> driven by hardware.
>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Thanks
Eric
> ---
> virt/kvm/arm/vgic/vgic-mmio.c | 71 +++++++++++++++++++++++++++++++++++++++----
> virt/kvm/arm/vgic/vgic.c | 7 +++++
> virt/kvm/arm/vgic/vgic.h | 1 +
> 3 files changed, 73 insertions(+), 6 deletions(-)
>
> diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
> index fdad95f62fa3..83d82bd7dc4e 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio.c
> +++ b/virt/kvm/arm/vgic/vgic-mmio.c
> @@ -16,6 +16,7 @@
> #include <linux/kvm.h>
> #include <linux/kvm_host.h>
> #include <kvm/iodev.h>
> +#include <kvm/arm_arch_timer.h>
> #include <kvm/arm_vgic.h>
>
> #include "vgic.h"
> @@ -143,10 +144,22 @@ static struct kvm_vcpu *vgic_get_mmio_requester_vcpu(void)
> return vcpu;
> }
>
> +/* Must be called with irq->irq_lock held */
> +static void vgic_hw_irq_spending(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
> + bool is_uaccess)
> +{
> + if (is_uaccess)
> + return;
> +
> + irq->pending_latch = true;
> + vgic_irq_set_phys_active(irq, true);
> +}
> +
> void vgic_mmio_write_spending(struct kvm_vcpu *vcpu,
> gpa_t addr, unsigned int len,
> unsigned long val)
> {
> + bool is_uaccess = !vgic_get_mmio_requester_vcpu();
> u32 intid = VGIC_ADDR_TO_INTID(addr, 1);
> int i;
> unsigned long flags;
> @@ -155,17 +168,45 @@ void vgic_mmio_write_spending(struct kvm_vcpu *vcpu,
> struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
>
> spin_lock_irqsave(&irq->irq_lock, flags);
> - irq->pending_latch = true;
> -
> + if (irq->hw)
> + vgic_hw_irq_spending(vcpu, irq, is_uaccess);
> + else
> + irq->pending_latch = true;
> vgic_queue_irq_unlock(vcpu->kvm, irq, flags);
> vgic_put_irq(vcpu->kvm, irq);
> }
> }
>
> +/* Must be called with irq->irq_lock held */
> +static void vgic_hw_irq_cpending(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
> + bool is_uaccess)
> +{
> + if (is_uaccess)
> + return;
> +
> + irq->pending_latch = false;
> +
> + /*
> + * We don't want the guest to effectively mask the physical
> + * interrupt by doing a write to SPENDR followed by a write to
> + * CPENDR for HW interrupts, so we clear the active state on
> + * the physical side if the virtual interrupt is not active.
> + * This may lead to taking an additional interrupt on the
> + * host, but that should not be a problem as the worst that
> + * can happen is an additional vgic injection. We also clear
> + * the pending state to maintain proper semantics for edge HW
> + * interrupts.
> + */
> + vgic_irq_set_phys_pending(irq, false);
> + if (!irq->active)
> + vgic_irq_set_phys_active(irq, false);
> +}
> +
> void vgic_mmio_write_cpending(struct kvm_vcpu *vcpu,
> gpa_t addr, unsigned int len,
> unsigned long val)
> {
> + bool is_uaccess = !vgic_get_mmio_requester_vcpu();
> u32 intid = VGIC_ADDR_TO_INTID(addr, 1);
> int i;
> unsigned long flags;
> @@ -175,7 +216,10 @@ void vgic_mmio_write_cpending(struct kvm_vcpu *vcpu,
>
> spin_lock_irqsave(&irq->irq_lock, flags);
>
> - irq->pending_latch = false;
> + if (irq->hw)
> + vgic_hw_irq_cpending(vcpu, irq, is_uaccess);
> + else
> + irq->pending_latch = false;
>
> spin_unlock_irqrestore(&irq->irq_lock, flags);
> vgic_put_irq(vcpu->kvm, irq);
> @@ -202,8 +246,19 @@ unsigned long vgic_mmio_read_active(struct kvm_vcpu *vcpu,
> return value;
> }
>
> +/* Must be called with irq->irq_lock held */
> +static void vgic_hw_irq_change_active(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
> + bool active, bool is_uaccess)
> +{
> + if (is_uaccess)
> + return;
> +
> + irq->active = active;
> + vgic_irq_set_phys_active(irq, active);
> +}
> +
> static void vgic_mmio_change_active(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
> - bool new_active_state)
> + bool active)
> {
> unsigned long flags;
> struct kvm_vcpu *requester_vcpu = vgic_get_mmio_requester_vcpu();
> @@ -231,8 +286,12 @@ static void vgic_mmio_change_active(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
> irq->vcpu->cpu != -1) /* VCPU thread is running */
> cond_resched_lock(&irq->irq_lock);
>
> - irq->active = new_active_state;
> - if (new_active_state)
> + if (irq->hw)
> + vgic_hw_irq_change_active(vcpu, irq, active, !requester_vcpu);
> + else
> + irq->active = active;
> +
> + if (irq->active)
> vgic_queue_irq_unlock(vcpu->kvm, irq, flags);
> else
> spin_unlock_irqrestore(&irq->irq_lock, flags);
> diff --git a/virt/kvm/arm/vgic/vgic.c b/virt/kvm/arm/vgic/vgic.c
> index eadabb249d2a..f4c92fae9cd3 100644
> --- a/virt/kvm/arm/vgic/vgic.c
> +++ b/virt/kvm/arm/vgic/vgic.c
> @@ -144,6 +144,13 @@ void vgic_put_irq(struct kvm *kvm, struct vgic_irq *irq)
> kfree(irq);
> }
>
> +void vgic_irq_set_phys_pending(struct vgic_irq *irq, bool pending)
> +{
> + WARN_ON(irq_set_irqchip_state(irq->host_irq,
> + IRQCHIP_STATE_PENDING,
> + pending));
> +}
> +
> /* Get the input level of a mapped IRQ directly from the physical GIC */
> bool vgic_get_phys_line_level(struct vgic_irq *irq)
> {
> diff --git a/virt/kvm/arm/vgic/vgic.h b/virt/kvm/arm/vgic/vgic.h
> index d0787983a357..12c37b89f7a3 100644
> --- a/virt/kvm/arm/vgic/vgic.h
> +++ b/virt/kvm/arm/vgic/vgic.h
> @@ -146,6 +146,7 @@ struct vgic_irq *vgic_get_irq(struct kvm *kvm, struct kvm_vcpu *vcpu,
> u32 intid);
> void vgic_put_irq(struct kvm *kvm, struct vgic_irq *irq);
> bool vgic_get_phys_line_level(struct vgic_irq *irq);
> +void vgic_irq_set_phys_pending(struct vgic_irq *irq, bool pending);
> void vgic_irq_set_phys_active(struct vgic_irq *irq, bool active);
> bool vgic_queue_irq_unlock(struct kvm *kvm, struct vgic_irq *irq,
> unsigned long flags);
>
^ permalink raw reply
* [PATCH v2 17/18] arm64: Kconfig: Add CONFIG_UNMAP_KERNEL_AT_EL0
From: Geert Uytterhoeven @ 2017-12-12 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512059986-21325-18-git-send-email-will.deacon@arm.com>
Hi Will,
On Thu, Nov 30, 2017 at 5:39 PM, Will Deacon <will.deacon@arm.com> wrote:
> Add a Kconfig entry to control use of the entry trampoline, which allows
> us to unmap the kernel whilst running in userspace and improve the
> robustness of KASLR.
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
This is now commit 084eb77cd3a81134 in arm64/for-next/core.
> ---
> arch/arm64/Kconfig | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index fdcc7b9bb15d..3af1657fcac3 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -833,6 +833,19 @@ config FORCE_MAX_ZONEORDER
> However for 4K, we choose a higher default value, 11 as opposed to 10, giving us
> 4M allocations matching the default size used by generic code.
>
> +config UNMAP_KERNEL_AT_EL0
> + bool "Unmap kernel when running in userspace (aka \"KAISER\")"
But I believe this is no longer called KAISER?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging
From: Marek Szyprowski @ 2017-12-12 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABxcv=n9PvoYr1xwB8CHBmE00XaTUqT642g7F8nuZd-d031h5Q@mail.gmail.com>
Hi Javier,
On 2017-12-12 09:00, Javier Martinez Canillas wrote:
> On Tue, Dec 12, 2017 at 8:54 AM, Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
>> On 2017-12-12 00:25, Shuah Khan wrote:
>>> On 12/11/2017 04:02 PM, Russell King - ARM Linux wrote:
>>>> On Mon, Dec 11, 2017 at 10:58:29PM +0000, Russell King - ARM Linux wrote:
>>>>> On Mon, Dec 11, 2017 at 11:54:48PM +0100, Javier Martinez Canillas
>>>>> wrote:
>>>>>> So I gave a quick look to this, and at the very least there's a bug in
>>>>>> the Exynos5800 Peach Pi DTS caused by commit 1cb686c08d12 ("ARM: dts:
>>>>>> exynos: Add status property to Exynos 542x Mixer nodes").
>>>>>>
>>>>>> I've posted a fix for that:
>>>>>>
>>>>>> https://patchwork.kernel.org/patch/10105921/
>>>>>>
>>>>>> I believe this could be also be the cause for the boot failure, since
>>>>>> I see in the boot log that things start to go wrong after exynos-drm
>>>>>> fails to bind the HDMI component:
>>>>>>
>>>>>> [ 2.916347] exynos-drm exynos-drm: failed to bind 14530000.hdmi (ops
>>>>>> 0xc1398690): -1
>>>>> Umm, -1 ? Looking that error code up in
>>>>> include/uapi/asm-generic/errno-base.h says it's -EPERM.
>>>>>
>>>>> I suspect that's someone just returning -1 because they're lazy...
>>>>> which is real bad form and needs fixing.
>>>> Oh, it really is -EPERM:
>>>>
>>>> struct exynos_drm_crtc *exynos_drm_crtc_get_by_type(struct drm_device
>>>> *drm_dev,
>>>> enum exynos_drm_output_type
>>>> out_type)
>>>> {
>>>> struct drm_crtc *crtc;
>>>>
>>>> drm_for_each_crtc(crtc, drm_dev)
>>>> if (to_exynos_crtc(crtc)->type == out_type)
>>>> return to_exynos_crtc(crtc);
>>>>
>>>> return ERR_PTR(-EPERM);
>>>> }
>>>>
>>>> Does "Operation not permitted" really convey the error here? It doesn't
>>>> look like a permission error to me.
>>>>
>>>> Can we please avoid abusing errno codes?
>>> I tried 4.15-rc3 on odroid-xu4 after seeing drm issues reported. 4.15-rc2+
>>> with top commit g968edbd worked just fine for me last Friday. I ran
>>> several
>>> tests and everything checked out except the exynos-gsc lockdep issue I
>>> sent
>>> a 4.14 patch for.
>>>
>>> However, with 4.15-rc3, dmesg is gets filled with
>>>
>>> [ 342.337181] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>> [ 342.337470] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>> [ 342.337851] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>> [ 402.382346] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>> [ 402.396682] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>> [ 402.399244] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>> [ 402.399496] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>> [ 402.399848] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>> [ 402.400163] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>> [ 402.400495] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>> [ 402.401294] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>> [ 402.401595] [drm] Non-contiguous allocation is not supported without
>>> IOMMU, falling back to contiguous buffer
>>>
>>> Something broke in 4.15-rc3 on odroix-xu4 badly with exynos_defconfig.
>>>
>>> I will start bisect and try to isolate the problem. I suspect this is
>>> related to dts
>>> changes perhaps? I used to this problem a while back and it has been
>>> fixed.
>>
>> This warning has been added intentionally, see following discussions:
>> https://patchwork.kernel.org/patch/10034919/
>> https://patchwork.kernel.org/patch/10070475/
>>
>> This means that your test apps should be updated or you should enable Exynos
>> IOMMU support in your config. Maybe it is a good time to finally enable it
>> in exynos_defconfig.
>>
> Has the issue that the boot-loader keeps the display controller
> enabled and scanning pages on the Exynos Chromebooks resolved?
>
> I think that's that preventing to enable it by default in
> exynos_defconfig since it caused boot failures when enabled on these
> machines. I don't follow exynos development too closely nowadays so
> maybe there's a fix in place now.
Not directly. I still didn't find time to properly add support for
devices, which were left in-working state (with active DMA
transactions) by bootloader, but due to some other changes in the
order of operations during boot process, power domains are
initialized very early and due to temporary lack of devices (which
are not yet added to the system), are turned off. This practically
stops FIMD for scanning framebuffer and "solves" this issue.
I've checked now and Exynos Snow Chromebook boots fine with IOMMU
support enabled, both with v4.15-rc3 and linux-next.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH 2/2] pinctrl: sunxi: Disable strict mode for H5 driver
From: Linus Walleij @ 2017-12-12 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3ef7cfa4-cc1a-f24b-0013-f36db82781e5@arm.com>
On Thu, Nov 30, 2017 at 5:07 PM, Andre Przywara <andre.przywara@arm.com> wrote:
> On 30/11/17 15:51, Linus Walleij wrote:
>> On Sat, Nov 25, 2017 at 1:02 PM, Andre Przywara <andre.przywara@arm.com> wrote:
>>
>>> All of the H5 boards in the kernel reference the MMC0 CD pin twice in
>>> their DT, so strict mode will make the MMC driver fail to load.
>>> To keep existing DTs working, disable strict mode in the H5 driver.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>> Reported-by: Chris Obbard <obbardc@gmail.com>
>>
>> Patch applied with Maxime's ACK.
>
> Thanks for that (also to Maxime and Chen-Yu) and the smooth handling!
>
> Sorry, I just see that I didn't point this out explicitly, but this is
> to fix a regression introduced in 4.15-rc1, so is this on a branch that
> will be pushed for 4.15-rc, still? (Couldn't find anything quickly on
> kernel.org)
Should be upstream as:
commit 07c43a382d7de3db01cc28bf2e17ed151cde2046
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v7 7/8] KVM: arm/arm64: Provide a get_input_level for the arch timer
From: Auger Eric @ 2017-12-12 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207105418.22428-8-christoffer.dall@linaro.org>
Hi Christoffer,
On 07/12/17 11:54, Christoffer Dall wrote:
> The VGIC can now support the life-cycle of mapped level-triggered
> interrupts, and we no longer have to read back the timer state on every
> exit from the VM if we had an asserted timer interrupt signal, because
> the VGIC already knows if we hit the unlikely case where the guest
> disables the timer without ACKing the virtual timer interrupt.
>
> This means we rework a bit of the code to factor out the functionality
> to snapshot the timer state from vtimer_save_state(), and we can reuse
> this functionality in the sync path when we have an irqchip in
> userspace, and also to support our implementation of the
> get_input_level() function for the timer.
>
> This change also means that we can no longer rely on the timer's view of
> the interrupt line to set the active state, because we no longer
> maintain this state for mapped interrupts when exiting from the guest.
> Instead, we only set the active state if the virtual interrupt is
> active, and otherwise we simply let the timer fire again and raise the
> virtual interrupt from the ISR.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> include/kvm/arm_arch_timer.h | 2 ++
> virt/kvm/arm/arch_timer.c | 75 +++++++++++++++++++++-----------------------
> 2 files changed, 38 insertions(+), 39 deletions(-)
>
> diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
> index 01ee473517e2..f57f795d704c 100644
> --- a/include/kvm/arm_arch_timer.h
> +++ b/include/kvm/arm_arch_timer.h
> @@ -90,6 +90,8 @@ void kvm_timer_vcpu_put(struct kvm_vcpu *vcpu);
>
> void kvm_timer_init_vhe(void);
>
> +bool kvm_arch_timer_get_input_level(int vintid);
> +
> #define vcpu_vtimer(v) (&(v)->arch.timer_cpu.vtimer)
> #define vcpu_ptimer(v) (&(v)->arch.timer_cpu.ptimer)
>
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index e78ba5e20f74..82d4963f63b8 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -343,6 +343,12 @@ static void kvm_timer_update_state(struct kvm_vcpu *vcpu)
> phys_timer_emulate(vcpu);
> }
>
> +static void __timer_snapshot_state(struct arch_timer_context *timer)
> +{
> + timer->cnt_ctl = read_sysreg_el0(cntv_ctl);
> + timer->cnt_cval = read_sysreg_el0(cntv_cval);
> +}
> +
> static void vtimer_save_state(struct kvm_vcpu *vcpu)
> {
> struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> @@ -354,10 +360,8 @@ static void vtimer_save_state(struct kvm_vcpu *vcpu)
> if (!vtimer->loaded)
> goto out;
>
> - if (timer->enabled) {
> - vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
> - vtimer->cnt_cval = read_sysreg_el0(cntv_cval);
> - }
> + if (timer->enabled)
> + __timer_snapshot_state(vtimer);
>
> /* Disable the virtual timer */
> write_sysreg_el0(0, cntv_ctl);
> @@ -454,8 +458,7 @@ static void kvm_timer_vcpu_load_vgic(struct kvm_vcpu *vcpu)
> bool phys_active;
> int ret;
>
> - phys_active = vtimer->irq.level ||
> - kvm_vgic_map_is_active(vcpu, vtimer->irq.irq);
> + phys_active = kvm_vgic_map_is_active(vcpu, vtimer->irq.irq);
>
> ret = irq_set_irqchip_state(host_vtimer_irq,
> IRQCHIP_STATE_ACTIVE,
> @@ -541,27 +544,19 @@ void kvm_timer_vcpu_put(struct kvm_vcpu *vcpu)
> set_cntvoff(0);
> }
>
> -static void unmask_vtimer_irq(struct kvm_vcpu *vcpu)
> +/*
> + * With a userspace irqchip we have to check if the guest de-asserted the
> + * timer and if so, unmask the timer irq signal on the host interrupt
> + * controller to ensure that we see future timer signals.
> + */
> +static void unmask_vtimer_irq_user(struct kvm_vcpu *vcpu)
> {
> struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
>
> if (unlikely(!irqchip_in_kernel(vcpu->kvm))) {
> - kvm_vtimer_update_mask_user(vcpu);
> - return;
> - }
> -
> - /*
> - * If the guest disabled the timer without acking the interrupt, then
> - * we must make sure the physical and virtual active states are in
> - * sync by deactivating the physical interrupt, because otherwise we
> - * wouldn't see the next timer interrupt in the host.
> - */
> - if (!kvm_vgic_map_is_active(vcpu, vtimer->irq.irq)) {
> - int ret;
> - ret = irq_set_irqchip_state(host_vtimer_irq,
> - IRQCHIP_STATE_ACTIVE,
> - false);
> - WARN_ON(ret);
> + __timer_snapshot_state(vtimer);
> + if (!kvm_timer_should_fire(vtimer))
> + kvm_vtimer_update_mask_user(vcpu);
> }
> }
>
> @@ -574,21 +569,7 @@ static void unmask_vtimer_irq(struct kvm_vcpu *vcpu)
> */
kernel doc comment is not valid anymore:
" Check if any of the timers have expired while we were running in the
guest, and inject an interrupt if that was the case.
Besides, looks good to me
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Thanks
Eric
> void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
> {
> - struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
> -
> - /*
> - * If we entered the guest with the vtimer output asserted we have to
> - * check if the guest has modified the timer so that we should lower
> - * the line at this point.
> - */
> - if (vtimer->irq.level) {
> - vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
> - vtimer->cnt_cval = read_sysreg_el0(cntv_cval);
> - if (!kvm_timer_should_fire(vtimer)) {
> - kvm_timer_update_irq(vcpu, false, vtimer);
> - unmask_vtimer_irq(vcpu);
> - }
> - }
> + unmask_vtimer_irq_user(vcpu);
> }
>
> int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu)
> @@ -819,6 +800,22 @@ static bool timer_irqs_are_valid(struct kvm_vcpu *vcpu)
> return true;
> }
>
> +bool kvm_arch_timer_get_input_level(int vintid)
> +{
> + struct kvm_vcpu *vcpu = kvm_arm_get_running_vcpu();
> + struct arch_timer_context *timer;
> +
> + if (vintid == vcpu_vtimer(vcpu)->irq.irq)
> + timer = vcpu_vtimer(vcpu);
> + else
> + BUG(); /* We only map the vtimer so far */
> +
> + if (timer->loaded)
> + __timer_snapshot_state(timer);
> +
> + return kvm_timer_should_fire(timer);
> +}
> +
> int kvm_timer_enable(struct kvm_vcpu *vcpu)
> {
> struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> @@ -841,7 +838,7 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
> }
>
> ret = kvm_vgic_map_phys_irq(vcpu, host_vtimer_irq, vtimer->irq.irq,
> - NULL);
> + kvm_arch_timer_get_input_level);
> if (ret)
> return ret;
>
>
^ permalink raw reply
* [PATCH v2] arm64: dts: Hi3660: Fix up psci state id
From: Leo Yan @ 2017-12-12 9:12 UTC (permalink / raw)
To: linux-arm-kernel
Thanks a lot for Vincent Guittot careful work to find bug for 'CPU_NAP'
idle state. From ftrace log we can observe CA73 CPUs can be easily
waken up from 'CPU_NAP' state but the 'waken up' CPUs doesn't handle
anything and sleep again; so there have tons of trace events for CA73
CPUs entering and exiting idle state.
On Hi3660 CA73 has retention state 'CPU_NAP' for CPU idle, this state we
set its psci parameter as '0x0000001' and from this parameter it can
calculate state id is 1. Unfortunately ARM trusted firmware (ARM-TF)
takes 1 as a invalid value for state id, so the CPU cannot enter idle
state and directly bail out to kernel.
We want to create good practice for psci parameters platform definition,
so review the psci specification. The spec "ARM Power State Coordination
Interface - Platform Design Document (ARM DEN 0022D)" recommends state
ID in chapter "6.5 Recommended StateID Encoding". The recommended power
state IDs can be presented by below listed values; and it divides into
three fields, every field can use 4 bits to present power states
corresponding to core level, cluster level and system level:
0: Run
1: Standby
2: Retention
3: Powerdown
This commit changes psci parameter to compliance with the suggested
state ID in the doc. Except we change 'CPU_NAP' state psci parameter
to '0x0000002', this commit also changes 'CPU_SLEEP' and 'CLUSTER_SLEEP'
state parameters to '0x0010003' and '0x1010033' respectively.
Credits to Daniel, Sudeep and Soby for suggestion and consolidation.
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Soby Mathew <Soby.Mathew@arm.com>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index ab0b95b..99d5a46 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -147,7 +147,7 @@
CPU_NAP: cpu-nap {
compatible = "arm,idle-state";
- arm,psci-suspend-param = <0x0000001>;
+ arm,psci-suspend-param = <0x0000002>;
entry-latency-us = <7>;
exit-latency-us = <2>;
min-residency-us = <15>;
@@ -156,7 +156,7 @@
CPU_SLEEP: cpu-sleep {
compatible = "arm,idle-state";
local-timer-stop;
- arm,psci-suspend-param = <0x0010000>;
+ arm,psci-suspend-param = <0x0010003>;
entry-latency-us = <40>;
exit-latency-us = <70>;
min-residency-us = <3000>;
@@ -165,7 +165,7 @@
CLUSTER_SLEEP_0: cluster-sleep-0 {
compatible = "arm,idle-state";
local-timer-stop;
- arm,psci-suspend-param = <0x1010000>;
+ arm,psci-suspend-param = <0x1010033>;
entry-latency-us = <500>;
exit-latency-us = <5000>;
min-residency-us = <20000>;
@@ -174,7 +174,7 @@
CLUSTER_SLEEP_1: cluster-sleep-1 {
compatible = "arm,idle-state";
local-timer-stop;
- arm,psci-suspend-param = <0x1010000>;
+ arm,psci-suspend-param = <0x1010033>;
entry-latency-us = <1000>;
exit-latency-us = <5000>;
min-residency-us = <20000>;
--
2.7.4
^ permalink raw reply related
* [PATCH] ASoC: sun4i-codec: fix to enable 12Khz and 24Khz audio playback and capture sample rates
From: Andrea Bondavalli @ 2017-12-12 9:14 UTC (permalink / raw)
To: linux-arm-kernel
H3 ASoC supports 12Khz and 24Khz audio sample rates but the current drivers doesn't advertise these rates properly and they cannot be used.
For example attempt to capture at 12Khz uses 11Khz (same applies to audio playback):
# arecord -f S16_LE -c 2 -r 12000 -D hw:0,0 -t raw /tmp/testS16_LE.raw
Recording raw data '/tmp/testS16_LE.raw' : Signed 16 bit Little Endian, Rate 12000 Hz, Stereo
Warning: rate is not accurate (requested = 12000Hz, got = 11025Hz)
This patch fixes the audio sample rates declared and supported by the driver according to the H3 data sheet.
Specifically for audio playback:
8000, 11050, 12000, 16000, 22050, 24000, 32000, 44100, 48000, 96000, 192000
and for audio capture:
8000, 11050, 12000, 16000, 22050, 24000, 32000, 44100, 48000
Signed-off-by: Andrea Bondavalli <andrea.bondavalli74@gmail.com>
---
sound/soc/sunxi/sun4i-codec.c | 29 ++++++++++++++++++++---------
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 5da4efe..c79e8a4 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -590,12 +590,28 @@ static int sun4i_codec_hw_params(struct snd_pcm_substream *substream,
hwrate);
}
+
+static unsigned int sun4i_codec_src_rates[] = {
+ 8000, 11025, 12000, 16000, 22050, 24000, 32000,
+ 44100, 48000, 96000, 192000
+};
+
+
+static struct snd_pcm_hw_constraint_list sun4i_codec_constraints = {
+ .count = ARRAY_SIZE(sun4i_codec_src_rates),
+ .list = sun4i_codec_src_rates,
+};
+
+
static int sun4i_codec_startup(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
struct snd_soc_pcm_runtime *rtd = substream->private_data;
struct sun4i_codec *scodec = snd_soc_card_get_drvdata(rtd->card);
+ snd_pcm_hw_constraint_list(substream->runtime, 0,
+ SNDRV_PCM_HW_PARAM_RATE, &sun4i_codec_constraints);
+
/*
* Stop issuing DRQ when we have room for less than 16 samples
* in our TX FIFO
@@ -633,9 +649,7 @@ static struct snd_soc_dai_driver sun4i_codec_dai = {
.channels_max = 2,
.rate_min = 8000,
.rate_max = 192000,
- .rates = SNDRV_PCM_RATE_8000_48000 |
- SNDRV_PCM_RATE_96000 |
- SNDRV_PCM_RATE_192000,
+ .rates = SNDRV_PCM_RATE_CONTINUOUS,
.formats = SNDRV_PCM_FMTBIT_S16_LE |
SNDRV_PCM_FMTBIT_S32_LE,
.sig_bits = 24,
@@ -645,11 +659,8 @@ static struct snd_soc_dai_driver sun4i_codec_dai = {
.channels_min = 1,
.channels_max = 2,
.rate_min = 8000,
- .rate_max = 192000,
- .rates = SNDRV_PCM_RATE_8000_48000 |
- SNDRV_PCM_RATE_96000 |
- SNDRV_PCM_RATE_192000 |
- SNDRV_PCM_RATE_KNOT,
+ .rate_max = 48000,
+ .rates = SNDRV_PCM_RATE_CONTINUOUS,
.formats = SNDRV_PCM_FMTBIT_S16_LE |
SNDRV_PCM_FMTBIT_S32_LE,
.sig_bits = 24,
@@ -1128,7 +1139,7 @@ static const struct snd_soc_component_driver sun4i_codec_component = {
.name = "sun4i-codec",
};
-#define SUN4I_CODEC_RATES SNDRV_PCM_RATE_8000_192000
+#define SUN4I_CODEC_RATES SNDRV_PCM_RATE_CONTINUOUS
#define SUN4I_CODEC_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \
SNDRV_PCM_FMTBIT_S32_LE)
--
2.7.4
^ permalink raw reply related
* [PATCH net-next v5 2/2] net: ethernet: socionext: add AVE ethernet driver
From: Philippe Ombredanne @ 2017-12-12 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAA93ih0C-aMpFAhU+5x6P=QjiOVRPZ0UL1wyKh1oeXzC8UjPXQ@mail.gmail.com>
Dear Masami-san,
On Tue, Dec 12, 2017 at 3:29 AM, Masami Hiramatsu
<masami.hiramatsu@linaro.org> wrote:
[...]
> Then what I'm considering is copyright notice lines. Those are usually
> treat as the header lines, not single line. So
>
>> +// SDPX-License-Identifier: GPL-2.0
>> +// sni_ave.c - Socionext UniPhier AVE ethernet driver
>> +// Copyright 2014 Panasonic Corporation
>> +// Copyright 2015-2017 Socionext Inc.
>
> is acceptable? or should we keep C-style header lines for new drivers?
>
>> +// SDPX-License-Identifier: GPL-2.0
>> +/*
>> + * sni_ave.c - Socionext UniPhier AVE ethernet driver
>> + * Copyright 2014 Panasonic Corporation
>> + * Copyright 2015-2017 Socionext Inc.
>> + */
>
> I just concern that those lines are not "single". that's all. :)
My voice carries the weight of a down feather in this discussion and
to me the benefit of the first form is that you have removed two
lines. Both forms work fine.
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* [PATCH v2] rcutorture: Add basic ARM64 support to run scripts
From: lianglihao at huawei.com @ 2017-12-12 9:19 UTC (permalink / raw)
To: linux-arm-kernel
From: Lihao Liang <lianglihao@huawei.com>
This commit adds support of the qemu command qemu-system-aarch64
to rcutorture.
Signed-off-by: Lihao Liang <lianglihao@huawei.com>
---
This commit is against RCU's git tree rcu/dev branch
commit 505b61b2ec1d ("EXP: rcu: Add debugging info to other assertion")
Note that the max CPUs supported by qemu machine 'virt' is 8 so the value of
CONFIG_NR_CPUS in some test configuration files needs to be adjusted.
tools/testing/selftests/rcutorture/bin/functions.sh | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/rcutorture/bin/functions.sh b/tools/testing/selftests/rcutorture/bin/functions.sh
index 07a1377..0541d10 100644
--- a/tools/testing/selftests/rcutorture/bin/functions.sh
+++ b/tools/testing/selftests/rcutorture/bin/functions.sh
@@ -136,6 +136,9 @@ identify_boot_image () {
qemu-system-x86_64|qemu-system-i386)
echo arch/x86/boot/bzImage
;;
+ qemu-system-aarch64)
+ echo arch/arm64/boot/Image
+ ;;
*)
echo vmlinux
;;
@@ -158,6 +161,9 @@ identify_qemu () {
elif echo $u | grep -q "Intel 80386"
then
echo qemu-system-i386
+ elif echo $u | grep -q aarch64
+ then
+ echo qemu-system-aarch64
elif uname -a | grep -q ppc64
then
echo qemu-system-ppc64
@@ -176,16 +182,20 @@ identify_qemu () {
# Output arguments for the qemu "-append" string based on CPU type
# and the TORTURE_QEMU_INTERACTIVE environment variable.
identify_qemu_append () {
+ local console=ttyS0
case "$1" in
qemu-system-x86_64|qemu-system-i386)
echo noapic selinux=0 initcall_debug debug
;;
+ qemu-system-aarch64)
+ console=ttyAMA0
+ ;;
esac
if test -n "$TORTURE_QEMU_INTERACTIVE"
then
echo root=/dev/sda
else
- echo console=ttyS0
+ echo console=$console
fi
}
@@ -197,6 +207,9 @@ identify_qemu_args () {
case "$1" in
qemu-system-x86_64|qemu-system-i386)
;;
+ qemu-system-aarch64)
+ echo -M virt -cpu host
+ ;;
qemu-system-ppc64)
echo -enable-kvm -M pseries -nodefaults
echo -device spapr-vscsi
@@ -254,7 +267,7 @@ specify_qemu_cpus () {
echo $2
else
case "$1" in
- qemu-system-x86_64|qemu-system-i386)
+ qemu-system-x86_64|qemu-system-i386|qemu-system-aarch64)
echo $2 -smp $3
;;
qemu-system-ppc64)
--
2.7.4
^ permalink raw reply related
* [PATCH v7 8/8] KVM: arm/arm64: Avoid work when userspace iqchips are not used
From: Auger Eric @ 2017-12-12 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207105418.22428-9-christoffer.dall@linaro.org>
Hi Christoffer,
On 07/12/17 11:54, Christoffer Dall wrote:
> We currently check if the VM has a userspace irqchip on every exit from
> the VCPU, and if so, we do some work to ensure correct timer behavior.
> This is unfortunate, as we could avoid doing any work entirely, if we
> didn't have to support irqchip in userspace.
>
> Realizing the userspace irqchip on ARM is mostly a developer or hobby
> feature, and is unlikely to be used in servers or other scenarios where
> performance is a priority, we can use a refcounted static key to only
> check the irqchip configuration when we have at least one VM that uses
> an irqchip in userspace.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Thanks
Eric
> ---
> virt/kvm/arm/arch_timer.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index 82d4963f63b8..df21451e7654 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -51,6 +51,8 @@ static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level,
> struct arch_timer_context *timer_ctx);
> static bool kvm_timer_should_fire(struct arch_timer_context *timer_ctx);
>
> +static DEFINE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
> +
> u64 kvm_phys_timer_read(void)
> {
> return timecounter->cc->read(timecounter->cc);
> @@ -569,7 +571,8 @@ static void unmask_vtimer_irq_user(struct kvm_vcpu *vcpu)
> */
> void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
> {
> - unmask_vtimer_irq_user(vcpu);
> + if (static_branch_unlikely(&userspace_irqchip_in_use))
> + unmask_vtimer_irq_user(vcpu);
> }
>
> int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu)
> @@ -774,6 +777,8 @@ void kvm_timer_vcpu_terminate(struct kvm_vcpu *vcpu)
> soft_timer_cancel(&timer->bg_timer, &timer->expired);
> soft_timer_cancel(&timer->phys_timer, NULL);
> kvm_vgic_unmap_phys_irq(vcpu, vtimer->irq.irq);
> + if (timer->enabled && !irqchip_in_kernel(vcpu->kvm))
> + static_branch_dec(&userspace_irqchip_in_use);
> }
>
> static bool timer_irqs_are_valid(struct kvm_vcpu *vcpu)
> @@ -826,8 +831,10 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
> return 0;
>
> /* Without a VGIC we do not map virtual IRQs to physical IRQs */
> - if (!irqchip_in_kernel(vcpu->kvm))
> + if (!irqchip_in_kernel(vcpu->kvm)) {
> + static_branch_inc(&userspace_irqchip_in_use);
> goto no_vgic;
> + }
>
> if (!vgic_initialized(vcpu->kvm))
> return -ENODEV;
>
^ permalink raw reply
* [PATCH] arm64: allwinner: a64: a64-olinuxino: add usb otg
From: Jagan Teki @ 2017-12-12 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212081335.3qkqcofdbcfuu5zh@flea.lan>
On Tue, Dec 12, 2017 at 1:43 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Tue, Dec 12, 2017 at 11:26:09AM +0530, Jagan Teki wrote:
>> Add usb otg support for a64-olinuxino board,
>> - USB0-ID connected with PH9
>> - USB0-VBUSDET connected with PH6
>> - USB-DRVVBUS controlled by N_VBUSEN pin from PMIC
>>
>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>
> How was this tested? Did you test the OTG part, or only the peripheral
> part?
Yes peripheral.
^ permalink raw reply
* [PATCH] rcutorture: Add basic ARM64 support to run scripts
From: Lihao Liang @ 2017-12-12 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211163243.GR7829@linux.vnet.ibm.com>
Hi Paul,
Many thanks for your helpful comments! I have addressed all of them in a new version of the patch, which is sent out in a separate email.
If you have further comments, please let me know.
Best regards,
Lihao.
On 2017/12/12 0:32, Paul E. McKenney wrote:
> On Fri, Dec 08, 2017 at 06:13:43PM +0800, lianglihao at huawei.com wrote:
>> From: Lihao Liang <lianglihao@huawei.com>
>>
>> This commit adds support of the qemu command qemu-system-aarch64
>> to rcutorture. Use the following command to run:
>>
>> ./kvm.sh --qemu-cmd qemu-system-aarch64
>>
>> Signed-off-by: Lihao Liang <lianglihao@huawei.com>
>
> Nice!!! Getting ARM support for rcutorture has been on my todo list
> for some time!
>
> A few questions and comments below.
>
> Feedback from ARM experts also welcome!
>
> Thanx, Paul
>
>> ---
>>
>> The max CPUs supported by qemu machine 'virt' is 8 so the value of
>> CONFIG_NR_CPUS in some test configuration files needs to be adjusted.
>>
>> tools/testing/selftests/rcutorture/bin/functions.sh | 18 +++++++++++++++++-
>> 1 file changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/testing/selftests/rcutorture/bin/functions.sh b/tools/testing/selftests/rcutorture/bin/functions.sh
>> index 07a1377..5ffe4fe 100644
>> --- a/tools/testing/selftests/rcutorture/bin/functions.sh
>> +++ b/tools/testing/selftests/rcutorture/bin/functions.sh
>> @@ -136,6 +136,9 @@ identify_boot_image () {
>> qemu-system-x86_64|qemu-system-i386)
>> echo arch/x86/boot/bzImage
>> ;;
>> + qemu-system-aarch64)
>> + echo arch/arm64/boot/Image
>> + ;;
>> *)
>> echo vmlinux
>> ;;
>
> Is it possible to automatically select ARM based on the kernel binary?
> See the identify_qemu function for how this is done for i386, x86_64,
> and PowerPC. Can an "elif" be added for ARM?
>
>> @@ -185,7 +188,14 @@ identify_qemu_append () {
>> then
>> echo root=/dev/sda
>> else
>> - echo console=ttyS0
>> + case "$1" in
>> + qemu-system-aarch64)
>> + echo console=ttyAMA0
>> + ;;
>> + *)
>> + echo console=ttyS0
>> + ;;
>> + esac
>> fi
>> }
>
> This approach is going to result in very ugly nesting if support is
> added for additional CPU families. How about something like this?
>
> identify_qemu_append () {
> local console=ttyS0
>
> case "$1" in
> qemu-system-x86_64|qemu-system-i386)
> echo noapic selinux=0 initcall_debug debug
> ;;
> qemu-system-aarch64)
> console=ttyAMA0
> ;;
> esac
> if test -n "$TORTURE_QEMU_INTERACTIVE"
> then
> echo root=/dev/sda
> else
> echo console=$console
> fi
> }
>
>> @@ -197,6 +207,9 @@ identify_qemu_args () {
>> case "$1" in
>> qemu-system-x86_64|qemu-system-i386)
>> ;;
>> + qemu-system-aarch64)
>> + echo -M virt -cpu host
>> + ;;
>> qemu-system-ppc64)
>> echo -enable-kvm -M pseries -nodefaults
>> echo -device spapr-vscsi
>> @@ -257,6 +270,9 @@ specify_qemu_cpus () {
>> qemu-system-x86_64|qemu-system-i386)
>
> How about the following instead, eliminating the need for an additional
> case?
>
> qemu-system-x86_64|qemu-system-i386!qemu-system-aarch64)
>
>> echo $2 -smp $3
>> ;;
>> + qemu-system-aarch64)
>> + echo $2 -smp $3
>> + ;;
>> qemu-system-ppc64)
>> nt="`lscpu | grep '^NUMA node0' | sed -e 's/^[^,]*,\([0-9]*\),.*$/\1/'`"
>> echo $2 -smp cores=`expr \( $3 + $nt - 1 \) / $nt`,threads=$nt
>> --
>> 2.7.4
>>
>
>
> .
>
^ permalink raw reply
* [PATCH] divers/soc/ti: fix max dup length for kstrndup
From: Ma Shimiao @ 2017-12-12 9:29 UTC (permalink / raw)
To: linux-arm-kernel
If source string longer than max, kstrndup will alloc max+1 space.
So, we should make sure the result will not over limit.
Signed-off-by: Ma Shimiao <mashimiao.fnst@cn.fujitsu.com>
---
drivers/soc/ti/knav_qmss_queue.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 39225de9d7f1..77d6b5c03aae 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -225,7 +225,7 @@ static struct knav_queue *__knav_queue_open(struct knav_queue_inst *inst,
if (!knav_queue_is_busy(inst)) {
struct knav_range_info *range = inst->range;
- inst->name = kstrndup(name, KNAV_NAME_SIZE, GFP_KERNEL);
+ inst->name = kstrndup(name, KNAV_NAME_SIZE - 1, GFP_KERNEL);
if (range->ops && range->ops->open_queue)
ret = range->ops->open_queue(range, inst, flags);
@@ -779,7 +779,7 @@ void *knav_pool_create(const char *name,
goto err;
}
- pool->name = kstrndup(name, KNAV_NAME_SIZE, GFP_KERNEL);
+ pool->name = kstrndup(name, KNAV_NAME_SIZE - 1, GFP_KERNEL);
pool->kdev = kdev;
pool->dev = kdev->dev;
--
2.13.6
^ permalink raw reply related
* [PATCH 1/2] net: dsa: allow XAUI phy interface mode
From: Russell King @ 2017-12-12 9:29 UTC (permalink / raw)
To: linux-arm-kernel
XGMII is a 32-bit bus plus two clock signals per direction. XAUI is
four serial lanes per direction. The 88e6190 supports XAUI but not
XGMII as it doesn't have enough pins. The same is true of 88e6176.
Match on PHY_INTERFACE_MODE_XAUI for the XAUI port type, but keep
accepting XGMII for backwards compatibility.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/dsa/mv88e6xxx/port.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c
index a7801f6668a5..6315774d72b3 100644
--- a/drivers/net/dsa/mv88e6xxx/port.c
+++ b/drivers/net/dsa/mv88e6xxx/port.c
@@ -338,6 +338,7 @@ int mv88e6390x_port_set_cmode(struct mv88e6xxx_chip *chip, int port,
cmode = MV88E6XXX_PORT_STS_CMODE_2500BASEX;
break;
case PHY_INTERFACE_MODE_XGMII:
+ case PHY_INTERFACE_MODE_XAUI:
cmode = MV88E6XXX_PORT_STS_CMODE_XAUI;
break;
case PHY_INTERFACE_MODE_RXAUI:
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: vf610-zii-dev: use XAUI for DSA link ports
From: Russell King @ 2017-12-12 9:29 UTC (permalink / raw)
To: linux-arm-kernel
Use XAUI rather than XGMII for DSA link ports, as this is the interface
mode that the switches actually use. XAUI is the 4 lane bus with clock
per direction, whereas XGMII is a 32 bit bus with clock.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
This must be applied along with patch 1 to avoid breakage.
arch/arm/boot/dts/vf610-zii-dev-rev-c.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
index 1b102c7f7928..4a972fceb3b5 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
@@ -128,7 +128,7 @@
switch0port10: port at 10 {
reg = <10>;
label = "dsa";
- phy-mode = "xgmii";
+ phy-mode = "xaui";
link = <&switch1port10>;
};
};
@@ -233,7 +233,7 @@
switch1port10: port at 10 {
reg = <10>;
label = "dsa";
- phy-mode = "xgmii";
+ phy-mode = "xaui";
link = <&switch0port10>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] arm64: dts: renesas: r8a7796: sort subnodes of root node alphabetically
From: Geert Uytterhoeven @ 2017-12-12 9:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212082436.12210-2-horms+renesas@verge.net.au>
On Tue, Dec 12, 2017 at 9:24 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Sort root sub-nodes alphabetically for allow for easier maintenance
> of this file.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v1 4/4] arm64: dts: mediatek: add mt2712 cpufreq related device nodes
From: Matthias Brugger @ 2017-12-12 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212072625.GL25177@vireshk-i7>
Hi,
On 12/12/2017 08:26 AM, Viresh Kumar wrote:
> On 12-12-17, 02:17, Rafael J. Wysocki wrote:
>> On Monday, December 11, 2017 8:57:19 AM CET Viresh Kumar wrote:
>>> On 08-12-17, 14:07, Andrew-sh Cheng wrote:
>>>> Add opp v2 information,
>>>> and also add clocks, regulators and opp information into cpu nodes
>>>>
>>>> Signed-off-by: Andrew-sh Cheng <andrew-sh.cheng@mediatek.com>
>>>> ---
>>>> arch/arm64/boot/dts/mediatek/mt2712-evb.dts | 27 ++++++++++++++
>>>> arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 57 +++++++++++++++++++++++++++++
>>>> 2 files changed, 84 insertions(+)
>>>
>>> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>>
>> Of course, DT bindings require ACKs from DT maintainers to be applied.
>
> I didn't knew that we need Acks from DT maintainers for dts files as well? Yeah,
> its very much required while defining new bindings for sure.
>
I will take the dts parts through the Mediatek SoC tree, so you don't have to
worry about them.
Please let me know when you take patch 1 and 2.
Regards,
Matthias
^ permalink raw reply
* [PATCH] mmc: sdhci-of-arasan: Disable clk_xin clock in the remove
From: Michal Simek @ 2017-12-12 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212081955.2309-1-flavio.ceolin@intel.com>
On 12.12.2017 09:19, Flavio Ceolin wrote:
> clk_xin is properly prepared/enabled on sdhci_arasan_probe(), and
> unprepared/disabled in the error path, but it is not being
> unprepared/disabled on sdhci_arasan_remove().
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
> ---
> drivers/mmc/host/sdhci-of-arasan.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> index 0720ea7..69bd260 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -692,6 +692,7 @@ static int sdhci_arasan_remove(struct platform_device *pdev)
> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> struct sdhci_arasan_data *sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
> struct clk *clk_ahb = sdhci_arasan->clk_ahb;
> + struct clk *clk_xin = devm_clk_get(&pdev->dev, "clk_xin");
I don't think this is right. You have already asked for this clock in
probe. It means you should reuse pltfm_host->clk = clk_xin;
And if you look at sdhci_pltfm_unregister you will find out that
clk_disable_unprepare(pltfm_host->clk);
is called there.
>
> if (!IS_ERR(sdhci_arasan->phy)) {
> if (sdhci_arasan->is_phy_on)
> @@ -705,6 +706,9 @@ static int sdhci_arasan_remove(struct platform_device *pdev)
>
> clk_disable_unprepare(clk_ahb);
>
> + if (!IS_ERR(clk_xin))
And clk_xin is required property.
> + clk_disable_unprepare(clk_xin);
> +
> return ret;
> }
>
>
It means NACK from me.
Thanks,
Michal
^ permalink raw reply
* [PATCH 0/4] Sunxi: Add SMP support on A83T
From: Mylene JOSSERAND @ 2017-12-12 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211193534.GA3967@Red>
Hi,
Le Mon, 11 Dec 2017 20:35:34 +0100,
Corentin Labbe <clabbe.montjoie@gmail.com> a ?crit :
> On Mon, Dec 11, 2017 at 08:49:57AM +0100, Myl?ne Josserand wrote:
> > Hello everyone,
> >
> > This series adds SMP support for Allwinner Sun8i-a83t
> > with MCPM (Multi-Cluster Power Management).
> > Series information:
> > - Based on last linux-next (next-20171211)
> > - Had dependencies on Chen Yu's patch that add MCPM
> > support:
> > https://patchwork.kernel.org/patch/6402801/
> >
> > Patch 01: Convert the mcpm driver (initially for A80) to be able
> > to use it for A83T. This SoC has a bit flip that needs to be
> > handled. Patch 02: Add registers nodes (prcm, cpucfg and r_cpucfg)
> > needed for MCPM.
> > Patch 03: Add CCI-400 node for a83t.
> > Patch 04: Fix the use of virtual timers that hangs the kernel in
> > case of SMP support.
> >
> > If you have any remarks/questions, let me know.
> > Thank you in advance,
> > Myl?ne
> >
>
> Hello
>
> As we discussed in private, Chen Yu's patch should be added in your
> series.
>
> Furthermore, MCPM is not automaticaly selected via imply.
>
> With all patchs I hit a bug:
> [ 0.898668] BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:238 [ 0.911162] in_atomic(): 1,
> irqs_disabled(): 0, pid: 1, name: swapper/0 [ 0.917776] CPU: 0
> PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-next-20171211+ #73
> [ 0.925418] Hardware name: Allwinner sun8i Family [ 0.930118]
> Backtrace: [ 0.932596] [<c010cc50>] (dump_backtrace) from
> [<c010cf0c>] (show_stack+0x18/0x1c) [ 0.940158] r7:c0b261e4
> r6:60000013 r5:00000000 r4:c0b51958 [ 0.945820] [<c010cef4>]
> (show_stack) from [<c06baccc>] (dump_stack+0x8c/0xa0) [ 0.953045]
> [<c06bac40>] (dump_stack) from [<c0149d40>]
> (___might_sleep+0x150/0x170) [ 0.960779] r7:c0b261e4 r6:00000000
> r5:000000ee r4:ee844000 [ 0.966437] [<c0149bf0>] (___might_sleep)
> from [<c0149dc8>] (__might_sleep+0x68/0xa0) [ 0.974253]
> r4:c0861690 [ 0.976796] [<c0149d60>] (__might_sleep) from
> [<c06d2918>] (mutex_lock+0x24/0x68) [ 0.984269] r6:c0892f6c
> r5:ffffffff r4:c0b1bb24 [ 0.988891] [<c06d28f4>] (mutex_lock) from
> [<c01ccb6c>] (perf_pmu_register+0x24/0x3e4) [ 0.996795]
> r5:ffffffff r4:ee98b014 [ 1.000375] [<c01ccb48>]
> (perf_pmu_register) from [<c03efabc>] (cci_pmu_probe+0x340/0x484)
> [ 1.008631] r10:c0892f6c r9:c0bfd5f0 r8:eea19010 r7:c0b261e4
> r6:c0b26240 r5:eea19000 [ 1.016447] r4:ee98b010 [ 1.018989]
> [<c03ef77c>] (cci_pmu_probe) from [<c045e21c>]
> (platform_drv_probe+0x58/0xb8) [ 1.027158] r10:00000000
> r9:c0b2610c r8:00000000 r7:fffffdfb r6:c0b2610c r5:ffffffed
> [ 1.034974] r4:eea19010 [ 1.037511] [<c045e1c4>]
> (platform_drv_probe) from [<c045c984>]
> (driver_probe_device+0x254/0x330) [ 1.046371] r7:00000000
> r6:c0bff498 r5:c0bff494 r4:eea19010 [ 1.052026] [<c045c730>]
> (driver_probe_device) from [<c045cbc4>]
> (__device_attach_driver+0xa0/0xd4) [ 1.061062] r10:00000000
> r9:c0bff470 r8:00000000 r7:00000001 r6:eea19010 r5:ee845ac0
> [ 1.068879] r4:c0b2610c r3:00000000 [ 1.072454] [<c045cb24>]
> (__device_attach_driver) from [<c045ad68>]
> (bus_for_each_drv+0x68/0x9c) [ 1.081228] r7:00000001 r6:c045cb24
> r5:ee845ac0 r4:00000000 [ 1.086883] [<c045ad00>]
> (bus_for_each_drv) from [<c045c60c>] (__device_attach+0xb8/0x11c)
> [ 1.095135] r6:c0b3e848 r5:eea19044 r4:eea19010 [ 1.099750]
> [<c045c554>] (__device_attach) from [<c045cc44>]
> (device_initial_probe+0x14/0x18) [ 1.108263] r7:c0b0a4c8
> r6:c0b3e848 r5:eea19010 r4:eea19018 [ 1.113919] [<c045cc30>]
> (device_initial_probe) from [<c045bb58>] (bus_probe_device+0x8c/0x94)
> [ 1.122523] [<c045bacc>] (bus_probe_device) from [<c0459db8>]
> (device_add+0x40c/0x5a0) [ 1.130429] r7:c0b0a4c8 r6:eea19010
> r5:eea18a10 r4:eea19018 [ 1.136089] [<c04599ac>] (device_add) from
> [<c0582a58>] (of_device_add+0x3c/0x44) [ 1.143564] r10:00000000
> r9:00000000 r8:00000000 r7:eedf21a4 r6:eea18a10 r5:00000000
> [ 1.151380] r4:eea19000 [ 1.153915] [<c0582a1c>]
> (of_device_add) from [<c0582f80>]
> (of_platform_device_create_pdata+0x7c/0xac) [ 1.163210]
> [<c0582f04>] (of_platform_device_create_pdata) from [<c0583100>]
> (of_platform_bus_create+0xf4/0x1f0) [ 1.173372] r9:00000000
> r8:00000000 r7:00000001 r6:00000000 r5:eedf2154 r4:00000000
> [ 1.181107] [<c058300c>] (of_platform_bus_create) from
> [<c0583374>] (of_platform_populate+0x74/0xd4) [ 1.190229]
> r10:00000001 r9:eea18a10 r8:00000000 r7:00000000 r6:00000000
> r5:eedf1d04 [ 1.198045] r4:eedf2154 [ 1.200580] [<c0583300>]
> (of_platform_populate) from [<c03ef2a8>]
> (cci_platform_probe+0x3c/0x54) [ 1.209356] r10:00000000
> r9:c0b26168 r8:00000000 r7:fffffdfb r6:c0b26168 r5:ffffffed
> [ 1.217172] r4:eea18a00 [ 1.219708] [<c03ef26c>]
> (cci_platform_probe) from [<c045e21c>] (platform_drv_probe+0x58/0xb8)
> [ 1.228306] r5:ffffffed r4:eea18a10 [ 1.231881] [<c045e1c4>]
> (platform_drv_probe) from [<c045c984>]
> (driver_probe_device+0x254/0x330) [ 1.240742] r7:00000000
> r6:c0bff498 r5:c0bff494 r4:eea18a10 [ 1.246397] [<c045c730>]
> (driver_probe_device) from [<c045cbc4>]
> (__device_attach_driver+0xa0/0xd4) [ 1.255433] r10:00000000
> r9:c0bff470 r8:00000000 r7:00000001 r6:eea18a10 r5:ee845ce8
> [ 1.263250] r4:c0b26168 r3:00000000 [ 1.266825] [<c045cb24>]
> (__device_attach_driver) from [<c045ad68>]
> (bus_for_each_drv+0x68/0x9c) [ 1.275598] r7:00000001 r6:c045cb24
> r5:ee845ce8 r4:00000000 [ 1.281253] [<c045ad00>]
> (bus_for_each_drv) from [<c045c60c>] (__device_attach+0xb8/0x11c)
> [ 1.289506] r6:c0b3e848 r5:eea18a44 r4:eea18a10 [ 1.294120]
> [<c045c554>] (__device_attach) from [<c045cc44>]
> (device_initial_probe+0x14/0x18) [ 1.302633] r7:c0b0a4c8
> r6:c0b3e848 r5:eea18a10 r4:eea18a18 [ 1.308288] [<c045cc30>]
> (device_initial_probe) from [<c045bb58>] (bus_probe_device+0x8c/0x94)
> [ 1.316890] [<c045bacc>] (bus_probe_device) from [<c0459db8>]
> (device_add+0x40c/0x5a0) [ 1.324796] r7:c0b0a4c8 r6:eea18a10
> r5:ee993810 r4:eea18a18 [ 1.330450] [<c04599ac>] (device_add) from
> [<c0582a58>] (of_device_add+0x3c/0x44) [ 1.337926] r10:00000000
> r9:c07759d8 r8:00000000 r7:eedf1d54 r6:ee993810 r5:00000000
> [ 1.345743] r4:eea18a00 [ 1.348277] [<c0582a1c>]
> (of_device_add) from [<c0582f80>]
> (of_platform_device_create_pdata+0x7c/0xac) [ 1.357572]
> [<c0582f04>] (of_platform_device_create_pdata) from [<c0583100>]
> (of_platform_bus_create+0xf4/0x1f0) [ 1.367734] r9:c07759d8
> r8:00000000 r7:00000001 r6:00000000 r5:eedf1d04 r4:00000000
> [ 1.375469] [<c058300c>] (of_platform_bus_create) from
> [<c058315c>] (of_platform_bus_create+0x150/0x1f0) [ 1.384938]
> r10:ee993810 r9:c07759d8 r8:00000000 r7:00000001 r6:00000000
> r5:eedefe1c [ 1.392754] r4:eedf1d04 [ 1.395289] [<c058300c>]
> (of_platform_bus_create) from [<c0583374>]
> (of_platform_populate+0x74/0xd4) [ 1.404411] r10:00000001
> r9:00000000 r8:00000000 r7:c07759d8 r6:00000000 r5:eedee844
> [ 1.412228] r4:eedefe1c [ 1.414769] [<c0583300>]
> (of_platform_populate) from [<c0a25ee8>]
> (of_platform_default_populate_init+0x80/0x94) [ 1.424844]
> r10:c0a37848 r9:00000000 r8:c0b59680 r7:c0a37834 r6:ffffe000
> r5:c0775ce8 [ 1.432661] r4:00000000 [ 1.435200] [<c0a25e68>]
> (of_platform_default_populate_init) from [<c0102794>]
> (do_one_initcall+0x5c/0x194) [ 1.444925] r5:c0a25e68 r4:c0b0a4c8
> [ 1.448506] [<c0102738>] (do_one_initcall) from [<c0a00f88>]
> (kernel_init_freeable+0x1d4/0x268) [ 1.457195] r9:00000004
> r8:c0b59680 r7:c0a37834 r6:c0b59680 r5:c0a47308 r4:c090cfb8
> [ 1.464932] [<c0a00db4>] (kernel_init_freeable) from [<c06cf3b0>]
> (kernel_init+0x10/0x118) [ 1.473187] r10:00000000 r9:00000000
> r8:00000000 r7:00000000 r6:00000000 r5:c06cf3a0 [ 1.481004]
> r4:00000000 [ 1.483540] [<c06cf3a0>] (kernel_init) from
> [<c01010e8>] (ret_from_fork+0x14/0x2c) [ 1.491098] Exception
> stack(0xee845fb0 to 0xee845ff8) [ 1.496146]
> 5fa0: 00000000 00000000 00000000
> 00000000 [ 1.504313] 5fc0: 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000 [ 1.512480] 5fe0: 00000000
> 00000000 00000000 00000000 00000013 00000000 [ 1.519084]
> r5:c06cf3a0 r4:00000000 [ 1.522737] ARM CCI_400_r1 PMU driver
> probed
I have done further tests.
I booted a previous kernel that I know it was working fine (kernel
v4.13) then, I booted the kernel with this series and it worked just
fine.
Only after a power cycle, I am able to reproduce the error, otherwise,
it is working well. See the boot log of this two tests:
http://code.bulix.org/7kr0e0-239697?raw
So I really tested this series but I did not do any power-cycle between
my tests (only reboots). I will investigate on it.
Best regards,
--
Myl?ne Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH net-next v5 1/2] net: add support for Cavium PTP coprocessor
From: Aleksey Makarov @ 2017-12-12 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211225954.ezqut6jvfg65rg4w@localhost>
Hi Richard,
On 12/12/2017 01:59 AM, Richard Cochran wrote:
>
> Sorry I didn't finish reviewing before...
>
> On Mon, Dec 11, 2017 at 05:14:30PM +0300, Aleksey Makarov wrote:
[ ... ]
>> +static int cavium_ptp_probe(struct pci_dev *pdev,
>> + const struct pci_device_id *ent)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct cavium_ptp *clock;
>> + struct cyclecounter *cc;
>> + u64 clock_cfg;
>> + u64 clock_comp;
>> + int err;
>> +
>> + clock = devm_kzalloc(dev, sizeof(*clock), GFP_KERNEL);
>> + if (!clock)
>> + return -ENOMEM;
>> +
>> + clock->pdev = pdev;
>> +
>> + err = pcim_enable_device(pdev);
>> + if (err)
>> + return err;
>> +
>> + err = pcim_iomap_regions(pdev, 1 << PCI_PTP_BAR_NO, pci_name(pdev));
>> + if (err)
>> + return err;
>> +
>> + clock->reg_base = pcim_iomap_table(pdev)[PCI_PTP_BAR_NO];
>> +
>> + spin_lock_init(&clock->spin_lock);
>> +
>> + cc = &clock->cycle_counter;
>> + cc->read = cavium_ptp_cc_read;
>> + cc->mask = CYCLECOUNTER_MASK(64);
>> + cc->mult = 1;
>> + cc->shift = 0;
>> +
>> + timecounter_init(&clock->time_counter, &clock->cycle_counter,
>> + ktime_to_ns(ktime_get_real()));
>> +
>> + clock->clock_rate = ptp_cavium_clock_get();
>> +
>> + clock->ptp_info = (struct ptp_clock_info) {
>> + .owner = THIS_MODULE,
>> + .name = "ThunderX PTP",
>> + .max_adj = 1000000000ull,
>> + .n_ext_ts = 0,
>> + .n_pins = 0,
>> + .pps = 0,
>> + .adjfreq = cavium_ptp_adjfreq,
>> + .adjtime = cavium_ptp_adjtime,
>> + .gettime64 = cavium_ptp_gettime,
>> + .settime64 = cavium_ptp_settime,
>> + .enable = cavium_ptp_enable,
>> + };
>> +
>> + clock_cfg = readq(clock->reg_base + PTP_CLOCK_CFG);
>> + clock_cfg |= PTP_CLOCK_CFG_PTP_EN;
>> + writeq(clock_cfg, clock->reg_base + PTP_CLOCK_CFG);
>> +
>> + clock_comp = ((u64)1000000000ull << 32) / clock->clock_rate;
>> + writeq(clock_comp, clock->reg_base + PTP_CLOCK_COMP);
>> +
>> + clock->ptp_clock = ptp_clock_register(&clock->ptp_info, dev);
>> + if (IS_ERR(clock->ptp_clock)) {
>
> You need to handle the case when ptp_clock_register() returns NULL.
>
> from ptp_clock_kernel.h:
>
> /**
> * ptp_clock_register() - register a PTP hardware clock driver
> *
> * @info: Structure describing the new clock.
> * @parent: Pointer to the parent device of the new clock.
> *
> * Returns a valid pointer on success or PTR_ERR on failure. If PHC
> * support is missing at the configuration level, this function
> * returns NULL, and drivers are expected to gracefully handle that
> * case separately.
> */
If ptp_clock_register() returns NULL, the device is still paired with the driver,
but the driver is not registered in the PTP core. When ethernet driver needs
the reference to this cavium PTP driver, it calls cavium_ptp_get() that checks
if ptp->ptp_clock is NULL and, if so, returns -ENODEV.
I need this behavior because I need to differentiate between two cases:
- the state when the driver is not initialized for the device because of PTP core
has not registered it. In this case function cavium_ptp_get() returns -ENODEV
and ethernet driver proceeds without PTP device.
- the state when the driver is not initialized because kernel has not tired
to initialize it yet. In this case function cavium_ptp_get() returns -EPROBE_DEFER
that is used in ethernet driver to defer initialization.
If you know how to do the same in more smoothly please share it. Or else I would
prefer to insert a comment about it and leave it as is.
Richard, thank you for review. I am going to address your comments in my next series.
Thank you
Aleksey Makarov
>> + clock_cfg = readq(clock->reg_base + PTP_CLOCK_CFG);
>> + clock_cfg &= ~PTP_CLOCK_CFG_PTP_EN;
>> + writeq(clock_cfg, clock->reg_base + PTP_CLOCK_CFG);
>> + return PTR_ERR(clock->ptp_clock);
>> + }
>> +
>> + pci_set_drvdata(pdev, clock);
>> + return 0;
>> +}
>
> Thanks,
> Richard
>
^ permalink raw reply
* [PATCH 2/3] arm64: dts: renesas: r8a7796: move nodes which have no reg property out of bus
From: Geert Uytterhoeven @ 2017-12-12 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212082436.12210-3-horms+renesas@verge.net.au>
Hi Simon,
On Tue, Dec 12, 2017 at 9:24 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Move pmu_a5[73], timer and thermal-zones nodes from soc node to root node.
> The nodes that have been moved do not have any register properties and thus
> shouldn't be placed on the bus.
[...]
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
but a few minor comments below...
> --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> @@ -154,6 +154,26 @@
> clock-frequency = <0>;
> };
>
> + pmu_a57 {
> + compatible = "arm,cortex-a57-pmu";
> + interrupts-extended = <&gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
> + <&gic GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-affinity = <&a57_0>,
> + <&a57_1>;
> + };
> +
> + pmu_a53 {
> + compatible = "arm,cortex-a53-pmu";
> + interrupts-extended = <&gic GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
> + <&gic GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
> + <&gic GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
> + <&gic GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-affinity = <&a53_0>,
> + <&a53_1>,
> + <&a53_2>,
> + <&a53_3>;
Merge these 4 into a single line?
> @@ -2027,4 +1971,64 @@
> resets = <&cpg 822>;
> };
> };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts-extended = <&gic GIC_PPI 13
> + (GIC_CPU_MASK_SIMPLE(6) |
> + IRQ_TYPE_LEVEL_LOW)>,
> + <&gic GIC_PPI 14
> + (GIC_CPU_MASK_SIMPLE(6) |
> + IRQ_TYPE_LEVEL_LOW)>,
> + <&gic GIC_PPI 11
> + (GIC_CPU_MASK_SIMPLE(6) |
> + IRQ_TYPE_LEVEL_LOW)>,
> + <&gic GIC_PPI 10
> + (GIC_CPU_MASK_SIMPLE(6) |
> + IRQ_TYPE_LEVEL_LOW)>;
I think you can do a better job here, by trying not to break entries across
multiple lines ;-)
(Oops, we already have it this way in r8a7795.dtsi)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a7795: sort subnodes of root node alphabetically
From: Geert Uytterhoeven @ 2017-12-12 9:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212082752.12806-1-horms+renesas@verge.net.au>
On Tue, Dec 12, 2017 at 9:27 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Sort root sub-nodes alphabetically for allow for easier maintenance
> of this file.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox