* [PATCH 17/37] KVM: arm64: Move userspace system registers into separate function
From: Christoffer Dall @ 2017-12-03 19:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171108093230.kusus6zsrf5jbkr6@kamzik.brq.redhat.com>
On Wed, Nov 08, 2017 at 10:32:30AM +0100, Andrew Jones wrote:
> On Thu, Oct 12, 2017 at 12:41:21PM +0200, Christoffer Dall wrote:
> > There's a semantic difference between the EL1 registers that control
> > operation of a kernel running in EL1 and EL1 registers that only control
> > userspace execution in EL0. Since we can defer saving/restoring the
> > latter, move them into their own function.
> >
> > We also take this chance to rename the function saving/restoring the
> > remaining system register to make it clear this function deals with
> > the EL1 system registers.
> >
> > No functional change.
> >
> > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> > ---
> > arch/arm64/kvm/hyp/sysreg-sr.c | 34 +++++++++++++++++++++++-----------
> > 1 file changed, 23 insertions(+), 11 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/sysreg-sr.c b/arch/arm64/kvm/hyp/sysreg-sr.c
> > index c4a3714..193c2b0 100644
> > --- a/arch/arm64/kvm/hyp/sysreg-sr.c
> > +++ b/arch/arm64/kvm/hyp/sysreg-sr.c
> > @@ -34,14 +34,18 @@ static void __hyp_text __sysreg_do_nothing(struct kvm_cpu_context *ctxt) { }
> >
> > static void __hyp_text __sysreg_save_common_state(struct kvm_cpu_context *ctxt)
> > {
> > + ctxt->sys_regs[MDSCR_EL1] = read_sysreg(mdscr_el1);
> > + ctxt->gp_regs.regs.sp = read_sysreg(sp_el0);
>
> Maybe a comment stating that sp_el0 is here, instead of down in user
> state, because arm64 Linux chooses to use it for the 'current' pointer.
> At least that's why I think it's been promoted to common state, but maybe
> there was a different reason I missed.
>
That is the reason. I can add a comment.
> > +}
> > +
> > +static void __hyp_text __sysreg_save_user_state(struct kvm_cpu_context *ctxt)
> > +{
> > ctxt->sys_regs[ACTLR_EL1] = read_sysreg(actlr_el1);
> > ctxt->sys_regs[TPIDR_EL0] = read_sysreg(tpidr_el0);
> > ctxt->sys_regs[TPIDRRO_EL0] = read_sysreg(tpidrro_el0);
> > - ctxt->sys_regs[MDSCR_EL1] = read_sysreg(mdscr_el1);
> > - ctxt->gp_regs.regs.sp = read_sysreg(sp_el0);
> > }
> >
> > -static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
> > +static void __hyp_text __sysreg_save_el1_state(struct kvm_cpu_context *ctxt)
> > {
> > ctxt->sys_regs[MPIDR_EL1] = read_sysreg(vmpidr_el2);
> > ctxt->sys_regs[CSSELR_EL1] = read_sysreg(csselr_el1);
> > @@ -70,31 +74,37 @@ static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
> > }
> >
> > static hyp_alternate_select(__sysreg_call_save_host_state,
> > - __sysreg_save_state, __sysreg_do_nothing,
> > + __sysreg_save_el1_state, __sysreg_do_nothing,
> > ARM64_HAS_VIRT_HOST_EXTN);
> >
> > void __hyp_text __sysreg_save_host_state(struct kvm_cpu_context *ctxt)
> > {
> > __sysreg_call_save_host_state()(ctxt);
> > __sysreg_save_common_state(ctxt);
> > + __sysreg_save_user_state(ctxt);
> > }
> >
> > void __hyp_text __sysreg_save_guest_state(struct kvm_cpu_context *ctxt)
> > {
> > - __sysreg_save_state(ctxt);
> > + __sysreg_save_el1_state(ctxt);
> > __sysreg_save_common_state(ctxt);
> > + __sysreg_save_user_state(ctxt);
> > }
> >
> > static void __hyp_text __sysreg_restore_common_state(struct kvm_cpu_context *ctxt)
> > {
> > - write_sysreg(ctxt->sys_regs[ACTLR_EL1], actlr_el1);
> > - write_sysreg(ctxt->sys_regs[TPIDR_EL0], tpidr_el0);
> > - write_sysreg(ctxt->sys_regs[TPIDRRO_EL0], tpidrro_el0);
> > write_sysreg(ctxt->sys_regs[MDSCR_EL1], mdscr_el1);
> > write_sysreg(ctxt->gp_regs.regs.sp, sp_el0);
> > }
> >
> > -static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
> > +static void __hyp_text __sysreg_restore_user_state(struct kvm_cpu_context *ctxt)
> > +{
> > + write_sysreg(ctxt->sys_regs[ACTLR_EL1], actlr_el1);
> > + write_sysreg(ctxt->sys_regs[TPIDR_EL0], tpidr_el0);
> > + write_sysreg(ctxt->sys_regs[TPIDRRO_EL0], tpidrro_el0);
> > +}
> > +
> > +static void __hyp_text __sysreg_restore_el1_state(struct kvm_cpu_context *ctxt)
> > {
> > write_sysreg(ctxt->sys_regs[MPIDR_EL1], vmpidr_el2);
> > write_sysreg(ctxt->sys_regs[CSSELR_EL1], csselr_el1);
> > @@ -123,19 +133,21 @@ static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
> > }
> >
> > static hyp_alternate_select(__sysreg_call_restore_host_state,
> > - __sysreg_restore_state, __sysreg_do_nothing,
> > + __sysreg_restore_el1_state, __sysreg_do_nothing,
> > ARM64_HAS_VIRT_HOST_EXTN);
> >
> > void __hyp_text __sysreg_restore_host_state(struct kvm_cpu_context *ctxt)
> > {
> > __sysreg_call_restore_host_state()(ctxt);
> > __sysreg_restore_common_state(ctxt);
> > + __sysreg_restore_user_state(ctxt);
> > }
> >
> > void __hyp_text __sysreg_restore_guest_state(struct kvm_cpu_context *ctxt)
> > {
> > - __sysreg_restore_state(ctxt);
> > + __sysreg_restore_el1_state(ctxt);
> > __sysreg_restore_common_state(ctxt);
> > + __sysreg_restore_user_state(ctxt);
> > }
> >
> > static void __hyp_text __fpsimd32_save_state(struct kvm_cpu_context *ctxt)
> > --
> > 2.9.0
> >
>
> Otherwise
>
> Reviewed-by: Andrew Jones <drjones@redhat.com>
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH] ARM: da850: Fix LEGO EV3 battery voltage gpio
From: David Lechner @ 2017-12-03 19:29 UTC (permalink / raw)
To: linux-arm-kernel
This fixes the battery voltage monitoring gpio-hog settings.
When the gpio is low, it turns off the battery voltage to the ADC chip.
However, this needs to be on all of the time so that we can monitor
battery voltage.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/boot/dts/da850-lego-ev3.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/da850-lego-ev3.dts b/arch/arm/boot/dts/da850-lego-ev3.dts
index aeb5fb0..9d15982 100644
--- a/arch/arm/boot/dts/da850-lego-ev3.dts
+++ b/arch/arm/boot/dts/da850-lego-ev3.dts
@@ -463,7 +463,7 @@
batt_volt_en {
gpio-hog;
gpios = <6 GPIO_ACTIVE_HIGH>;
- output-low;
+ output-high;
};
/* Don't impede Bluetooth clock signal */
--
2.7.4
^ permalink raw reply related
* [Intel-gfx] [PATCH V3 09/29] drm/i915: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-03 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9046d23e-412d-9d9f-147f-a3bc6eea34fc@codeaurora.org>
On 11/28/2017 11:29 AM, Sinan Kaya wrote:
> On 11/28/2017 10:30 AM, Ville Syrj?l? wrote:
>>> + dev_priv->bridge_dev =
>>> + pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 0));
>> Maybe just pci_get_slot(pdev->bus, PCI_DEVFN(0, 0)) ?
>>
>> I guess if we want to be pedantic we could go for:
>>
>> bus = pci_find_host_bridge(pdev->bus)->bus;
>> pci_get_slot(bus, PCI_DEVFN(0, 0))
>>
>> but I think the GPU should always be on the root bus, so the simpler
>> form should be fine.
>>
>
> All three of these should be correct.
>
> I'll use pci_get_slot(pdev->bus, PCI_DEVFN(0, 0)) as you suggested.
>
Now that I think about this more, I think my version is a simpler change
and does not introduce "new features" by assuming GPU and host to be
on the same bus similar to the original code.
Original code could have used pci_get_slot() too. Since all of them are
correct, mine is slightly more correct; I'd like to keep mine.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 15/37] KVM: arm64: Don't deactivate VM on VHE systems
From: Christoffer Dall @ 2017-12-03 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171107161450.akn7yspt4ebxynjy@kamzik.brq.redhat.com>
On Tue, Nov 07, 2017 at 05:14:50PM +0100, Andrew Jones wrote:
> On Thu, Oct 12, 2017 at 12:41:19PM +0200, Christoffer Dall wrote:
> > There is no need to reset the VTTBR to zero when exiting the guest on
> > VHE systems. VHE systems don't use stage 2 translations for the EL2&0
> > translation regime used by the host.
> >
> > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> > ---
> > arch/arm64/kvm/hyp/switch.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> > index b72dc66..2cedf12 100644
> > --- a/arch/arm64/kvm/hyp/switch.c
> > +++ b/arch/arm64/kvm/hyp/switch.c
> > @@ -136,13 +136,13 @@ static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
> > write_sysreg(0, pmuserenr_el0);
> > }
> >
> > -static void __hyp_text __activate_vm(struct kvm_vcpu *vcpu)
> > +static inline void __hyp_text __activate_vm(struct kvm_vcpu *vcpu)
> > {
> > struct kvm *kvm = kern_hyp_va(vcpu->kvm);
>
> Hmm, should we change __activate_vm to take a kvm pointer instead of a
> vcpu, and then call the function from the VHE kvm_vcpu_run normally, but
> from the non-VHE kvm_vcpu_run with kern_hyp_va(vcpu->kvm)? I only ask,
> because it appears to be the last kern_hyp_va() that VHE code would still
> invoke, at least considering the code in arch/arm64/kvm/hyp/switch.c
>
Yes, that's a reasonable point.
> > write_sysreg(kvm->arch.vttbr, vttbr_el2);
> > }
> >
> > -static void __hyp_text __deactivate_vm(struct kvm_vcpu *vcpu)
> > +static inline void __hyp_text __deactivate_vm(struct kvm_vcpu *vcpu)
>
> Adding these 'inline' attributes is unrelated to this patch, and probably
> unnecessary, as the compiler probably knew to do so anyway, but whatever.
>
I actually saw an additional function being inlined on the compiler I
used with the inline attribute, but not without, but I cannot reproduce
currently, so I'll drop these attributes.
> > {
> > write_sysreg(0, vttbr_el2);
> > }
> > @@ -360,7 +360,6 @@ int kvm_vcpu_run(struct kvm_vcpu *vcpu)
> > __vgic_save_state(vcpu);
> >
> > __deactivate_traps(vcpu);
> > - __deactivate_vm(vcpu);
> >
> > __sysreg_restore_host_state(host_ctxt);
> >
> > --
> > 2.9.0
> >
>
> Reviewed-by: Andrew Jones <drjones@redhat.com>
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH 16/37] KVM: arm64: Remove noop calls to timer save/restore from VHE switch
From: Christoffer Dall @ 2017-12-03 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171107162528.q3rdlih5fpn7fnhd@kamzik.brq.redhat.com>
On Tue, Nov 07, 2017 at 05:25:28PM +0100, Andrew Jones wrote:
> On Thu, Oct 12, 2017 at 12:41:20PM +0200, Christoffer Dall wrote:
> > The VHE switch function calls __timer_enable_traps and
> > __timer_disable_traps which don't do anything on VHE systems.
> > Therefore, simply remove these calls from the VHE switch function and
> > make the functions non-conditional as they are now only called from the
> > non-VHE switch path.
> >
> > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> > ---
> > arch/arm64/kvm/hyp/switch.c | 2 --
> > virt/kvm/arm/hyp/timer-sr.c | 10 ++--------
> > 2 files changed, 2 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> > index 2cedf12..b98b73b 100644
> > --- a/arch/arm64/kvm/hyp/switch.c
> > +++ b/arch/arm64/kvm/hyp/switch.c
> > @@ -336,7 +336,6 @@ int kvm_vcpu_run(struct kvm_vcpu *vcpu)
> > __activate_vm(vcpu);
> >
> > __vgic_restore_state(vcpu);
> > - __timer_enable_traps(vcpu);
> >
> > /*
> > * We must restore the 32-bit state before the sysregs, thanks
> > @@ -356,7 +355,6 @@ int kvm_vcpu_run(struct kvm_vcpu *vcpu)
> >
> > __sysreg_save_guest_state(guest_ctxt);
> > __sysreg32_save_state(vcpu);
> > - __timer_disable_traps(vcpu);
> > __vgic_save_state(vcpu);
> >
> > __deactivate_traps(vcpu);
> > diff --git a/virt/kvm/arm/hyp/timer-sr.c b/virt/kvm/arm/hyp/timer-sr.c
> > index f398616..82c217e 100644
> > --- a/virt/kvm/arm/hyp/timer-sr.c
> > +++ b/virt/kvm/arm/hyp/timer-sr.c
> > @@ -53,16 +53,10 @@ void __hyp_text disable_el1_phys_timer_access(void)
> >
> > void __hyp_text __timer_disable_traps(struct kvm_vcpu *vcpu)
> > {
> > - /*
> > - * We don't need to do this for VHE since the host kernel runs in EL2
> > - * with HCR_EL2.TGE ==1, which makes those bits have no impact.
> > - */
>
> I was about to suggest that we should move this comment, instead of remove
> it, but it seems misleading anyway. We do call
> enable/disable_el1_phys_timer_access on VHE, but at VCPU load/put time
> instead of VM enter/exit time. So I guess removing it is best.
>
That was actually a bug in the timer series, which has now been fixed.
In any case, I don't think the comment is necessary as it's already
explained in kvm_timer_init_vhe() in arch_timer.c.
> > - if (!has_vhe())
> > - enable_el1_phys_timer_access();
> > + enable_el1_phys_timer_access();
> > }
> >
> > void __hyp_text __timer_enable_traps(struct kvm_vcpu *vcpu)
> > {
> > - if (!has_vhe())
> > - disable_el1_phys_timer_access();
> > + disable_el1_phys_timer_access();
> > }
> > --
> > 2.9.0
> >
>
> Should we just call enable/disable_el1_phys_timer_access directly from
> __kvm_vcpu_run for non-VHE and drop this extra function level?
>
I don't think there's a problem with this indirection and we could
imagine having more traps in the future.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH v6 0/2] memory: Introduce ti-emif-sram driver
From: Tony Lindgren @ 2017-12-03 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <179c7668-05eb-09cf-9857-7b6fd2308c3a@oracle.com>
* santosh.shilimkar at oracle.com <santosh.shilimkar@oracle.com> [171203 04:03]:
>
>
> On 11/30/17 2:56 PM, Dave Gerlach wrote:
> > This is a resend of v5 of this series found here [1]. It introduces
> > relocatable PM handlers for the emif that are copied to sram and
> > run from there during low power mode entry.
> >
> > The patches still have the previous ACKs but have a small change to
> > accomodate a change made by Tony in commit cd57dc5a2099 ("ARM: dts:
> > Add missing hwmod related nodes for am33xx"). If there are objections
> > to this let me know ASAP.
> >
> > Now that a hwmod is present for the am335x EMIF, on probe fail the call to
> > pm_runtime_put_sync causes the board to hang. In fact, this emif driver should
> > never alter the PM state of the hardware at all through normal kernel calls, it
> > is the job of the suspend handlers that are added, that is the whole point of
> > this driver. Because of this, I have dropped all runtime pm calls, as any
> > change to the PM state while the kernel is running is dangerous as we may shut
> > of the memory controller. It makes the most sense just to drop runtime PM from
> > the driver entirely. Besides that patch is unchanged.
> >
> > This code is required for low-power modes to work on AM335x and AM437x and a
> > forthcoming PM series for those platforms will depend on this series. After
> > both this and the PM series are reviewed I will send the necessary device tree
> > changes for both, but in the meantime all remaining patches for am335x and
> > am437x PM can be found here [2].
> >
> Applied
OK, do you have some immutable commit for these I can pull in too for
the related SoC changes?
Regards,
Tony
^ permalink raw reply
* [PATCH V2] ARM: dts: bcm283x: Use GPIO polarity defines consistently
From: Stefan Wahren @ 2017-12-03 16:36 UTC (permalink / raw)
To: linux-arm-kernel
Currently most of the Raspberry Pi DTS have a mixture of magic
numbers and the proper GPIO polarity defines. So use the latter
one consistently.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 4 ++--
arch/arm/boot/dts/bcm2835-rpi-a.dts | 2 +-
arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 4 ++--
arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 2 +-
arch/arm/boot/dts/bcm2835-rpi-b.dts | 2 +-
arch/arm/boot/dts/bcm2836-rpi-2-b.dts | 4 ++--
arch/arm/boot/dts/bcm2837-rpi-3-b.dts | 2 +-
7 files changed, 10 insertions(+), 10 deletions(-)
Changes in V2:
* fix wording in commit log
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
index f81ae0a..aa1fc7b 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
@@ -10,12 +10,12 @@
leds {
act {
- gpios = <&gpio 47 0>;
+ gpios = <&gpio 47 GPIO_ACTIVE_HIGH>;
};
pwr {
label = "PWR";
- gpios = <&gpio 35 0>;
+ gpios = <&gpio 35 GPIO_ACTIVE_HIGH>;
default-state = "keep";
linux,default-trigger = "default-on";
};
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a.dts b/arch/arm/boot/dts/bcm2835-rpi-a.dts
index 7a960a0..425f6b0 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a.dts
@@ -10,7 +10,7 @@
leds {
act {
- gpios = <&gpio 16 1>;
+ gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
};
};
};
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
index 0161a84..effa195 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
@@ -11,12 +11,12 @@
leds {
act {
- gpios = <&gpio 47 0>;
+ gpios = <&gpio 47 GPIO_ACTIVE_HIGH>;
};
pwr {
label = "PWR";
- gpios = <&gpio 35 0>;
+ gpios = <&gpio 35 GPIO_ACTIVE_HIGH>;
default-state = "keep";
linux,default-trigger = "default-on";
};
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
index 4bc70ef..772ec3b 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
@@ -11,7 +11,7 @@
leds {
act {
- gpios = <&gpio 16 1>;
+ gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
};
};
};
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b.dts b/arch/arm/boot/dts/bcm2835-rpi-b.dts
index cca4a75..434483d 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b.dts
@@ -11,7 +11,7 @@
leds {
act {
- gpios = <&gpio 16 1>;
+ gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
};
};
};
diff --git a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
index 6669355..5c339ad 100644
--- a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
+++ b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
@@ -15,12 +15,12 @@
leds {
act {
- gpios = <&gpio 47 0>;
+ gpios = <&gpio 47 GPIO_ACTIVE_HIGH>;
};
pwr {
label = "PWR";
- gpios = <&gpio 35 0>;
+ gpios = <&gpio 35 GPIO_ACTIVE_HIGH>;
default-state = "keep";
linux,default-trigger = "default-on";
};
diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
index a8844d0..3e4ed7c 100644
--- a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
+++ b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
@@ -20,7 +20,7 @@
leds {
act {
- gpios = <&gpio 47 0>;
+ gpios = <&gpio 47 GPIO_ACTIVE_HIGH>;
};
};
};
--
2.7.4
^ permalink raw reply related
* [GIT PULL] revert ARM SCPI changes for v4.15-rc1
From: Heiner Kallweit @ 2017-12-03 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171203010435.6ycn75rxss5yiixe@localhost>
Am 03.12.2017 um 02:04 schrieb Olof Johansson:
> On Fri, Dec 01, 2017 at 11:53:05AM -0800, Kevin Hilman wrote:
>> Arnd, Olof,
>>
>> These ARM SCPI changes caused SCPI regressions resulting in CPUfreq
>> failures on most Amlogic SoCs (found by kernelci.org.)
>>
>> Unfortunately, this was not caught in linux-next due to other
>> bugs/panics on these platforms masking this problem so we've only found
>> it since we've fixed the other issues.
>>
>> Since we're already in the -rc cycle, I'd prefer to revert to a known
>> working state (that of v4.14) rather than finding/reverting a subset,
>> which would just lead to another untested state.
>>
>> These changes can then have some time to be better reviewed and tested
>> and resubmitted for v4.16.
>>
>> I've tested this revert on the affect Amlogic SoCs and verified that
>> we're back to the previous (working) condition.
>>
>> Also, I'm sending the pull directly to arm-soc instead of Sudeeep
>> because I understand that Sudeep is currently out-of-office and unlikely
>> to be able to address this himself during the -rc cycle.
>>
>
> Sounds like the right approach here. I've merged this and added the above text
> to the merge commit as well.
>
I can't reproduce the issue on my systems, however I'm quite sure that commit
931cf0c53e69 "firmware: arm_scpi: pre-populate dvfs info in scpi_probe" causes
the problem.
I could re-submit the series w/o this patch, the other patches then need some
re-basing.
I'd include a patch addressing the following question from Kevin because I was
asking myself the same thing too:
"Also, is this the expected result for the pre-1.0 firmware:
scpi_protocol scpi: SCP Protocol 0.0 Firmware 0.0.0 version"
In case a legacy firmware doesn't provide version information I propose to
print the following message instead:
scpi_protocol scpi: SCP Protocol legacy pre-1.0 firmware
The series could be applied to a devel branch first to give the Baylibre
Amlogic team some time for testing.
Rgds, Heiner
>
> -Olof
>
^ permalink raw reply
* [PATCH v2] ARM: dts: Add ethernet PHYs to the a bunch of Geminis
From: Andrew Lunn @ 2017-12-03 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171203150457.21774-1-linus.walleij@linaro.org>
On Sun, Dec 03, 2017 at 04:04:57PM +0100, Linus Walleij wrote:
> These Gemini boards have Ethernet PHY on GPIO bit-banged
> MDIO, clearly defined in the corresponding OpenWRT
> ethernet patches since ages. Add them in accordance with
> the OpenWRT patch so we can use them when we add ethernet
> support.
>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
This is good as is, but i just wonder if the mdio node can be moved
into the .dtsi file. Four from six have the exact same setup. So i'm
guessing the reference design has been copied. So it is likely the
other two at the same. So you could move the mdio, set it to status
disable, and have these board enable it in their .dts file.
Andrew
^ permalink raw reply
* [PATCH v2] ARM: dts: Add basic devicetree for D-Link DNS-313
From: Andrew Lunn @ 2017-12-03 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171203133119.20931-1-linus.walleij@linaro.org>
On Sun, Dec 03, 2017 at 02:31:19PM +0100, Linus Walleij wrote:
> This adds a basic device tree for the D-Link DNS-313
> NAS enclosure.
>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH v2] ARM: dts: Add ethernet PHYs to the a bunch of Geminis
From: Linus Walleij @ 2017-12-03 15:04 UTC (permalink / raw)
To: linux-arm-kernel
These Gemini boards have Ethernet PHY on GPIO bit-banged
MDIO, clearly defined in the corresponding OpenWRT
ethernet patches since ages. Add them in accordance with
the OpenWRT patch so we can use them when we add ethernet
support.
Cc: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Fix the unit names on all PHYs to correspond to the
actual reg.
---
arch/arm/boot/dts/gemini-nas4220b.dts | 13 +++++++++++++
arch/arm/boot/dts/gemini-rut1xx.dts | 13 +++++++++++++
arch/arm/boot/dts/gemini-wbd111.dts | 13 +++++++++++++
arch/arm/boot/dts/gemini-wbd222.dts | 18 ++++++++++++++++++
4 files changed, 57 insertions(+)
diff --git a/arch/arm/boot/dts/gemini-nas4220b.dts b/arch/arm/boot/dts/gemini-nas4220b.dts
index d6a22e677c7a..943d2d07fac7 100644
--- a/arch/arm/boot/dts/gemini-nas4220b.dts
+++ b/arch/arm/boot/dts/gemini-nas4220b.dts
@@ -64,6 +64,19 @@
};
};
+ mdio0: ethernet-phy {
+ compatible = "virtual,mdio-gpio";
+ gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>, /* MDC */
+ <&gpio0 21 GPIO_ACTIVE_HIGH>; /* MDIO */
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy0: ethernet-phy at 1 {
+ reg = <1>;
+ device_type = "ethernet-phy";
+ };
+ };
+
soc {
flash at 30000000 {
status = "okay";
diff --git a/arch/arm/boot/dts/gemini-rut1xx.dts b/arch/arm/boot/dts/gemini-rut1xx.dts
index 500057b6570e..fd55528bba56 100644
--- a/arch/arm/boot/dts/gemini-rut1xx.dts
+++ b/arch/arm/boot/dts/gemini-rut1xx.dts
@@ -58,6 +58,19 @@
};
};
+ mdio0: ethernet-phy {
+ compatible = "virtual,mdio-gpio";
+ gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>, /* MDC */
+ <&gpio0 21 GPIO_ACTIVE_HIGH>; /* MDIO */
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy0: ethernet-phy at 1 {
+ reg = <1>;
+ device_type = "ethernet-phy";
+ };
+ };
+
soc {
flash at 30000000 {
status = "okay";
diff --git a/arch/arm/boot/dts/gemini-wbd111.dts b/arch/arm/boot/dts/gemini-wbd111.dts
index b413fd12c5ba..f36e1b65497d 100644
--- a/arch/arm/boot/dts/gemini-wbd111.dts
+++ b/arch/arm/boot/dts/gemini-wbd111.dts
@@ -69,6 +69,19 @@
};
};
+ mdio0: ethernet-phy {
+ compatible = "virtual,mdio-gpio";
+ gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>, /* MDC */
+ <&gpio0 21 GPIO_ACTIVE_HIGH>; /* MDIO */
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy0: ethernet-phy at 1 {
+ reg = <1>;
+ device_type = "ethernet-phy";
+ };
+ };
+
soc {
flash at 30000000 {
status = "okay";
diff --git a/arch/arm/boot/dts/gemini-wbd222.dts b/arch/arm/boot/dts/gemini-wbd222.dts
index 3ba710538662..669bd8b5f92f 100644
--- a/arch/arm/boot/dts/gemini-wbd222.dts
+++ b/arch/arm/boot/dts/gemini-wbd222.dts
@@ -69,6 +69,24 @@
};
};
+ mdio0: ethernet-phy {
+ compatible = "virtual,mdio-gpio";
+ gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>, /* MDC */
+ <&gpio0 21 GPIO_ACTIVE_HIGH>; /* MDIO */
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy0: ethernet-phy at 1 {
+ reg = <1>;
+ device_type = "ethernet-phy";
+ };
+
+ phy1: ethernet-phy at 3 {
+ reg = <3>;
+ device_type = "ethernet-phy";
+ };
+ };
+
soc {
flash at 30000000 {
status = "okay";
--
2.14.3
^ permalink raw reply related
* [PATCH v5.1 1/2] ARM64: dts: meson-gx: use stable UART bindings with correct gate clock
From: Andreas Färber @ 2017-12-03 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1498056132-18508-2-git-send-email-narmstrong@baylibre.com>
Hi,
Am 21.06.2017 um 16:42 schrieb Neil Armstrong:
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> index 17d3efd..ea53cc2 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> @@ -682,6 +682,31 @@
> clocks = <&clkc CLKID_SPI>;
> };
>
> +&uart_A {
> + clocks = <&xtal>, <&clkc CLKID_UART0>, <&xtal>;
> + clock-names = "xtal", "pclk", "baud";
> +};
> +
> +&uart_AO {
> + clocks = <&xtal>, <&clkc CLKID_CLK81>, <&xtal>;
> + clock-names = "xtal", "pclk", "baud";
> +};
> +
> +&uart_AO_B {
> + clocks = <&xtal>, <&clkc CLKID_CLK81>, <&xtal>;
> + clock-names = "xtal", "pclk", "baud";
> +};
> +
> +&uart_B {
> + clocks = <&xtal>, <&clkc CLKID_UART1>, <&xtal>;
> + clock-names = "xtal", "core", "baud";
Looking at the meson_uart driver, it only looks for a "pclk" clock,
never for "core", and the only unnamed clock used should be the first.
There is no bindings documentation for "core", so I assume this was an
oversight and should be "pclk" everywhere?
> +};
> +
> +&uart_C {
> + clocks = <&xtal>, <&clkc CLKID_UART2>, <&xtal>;
> + clock-names = "xtal", "core", "baud";
> +};
The issue I'm facing is that uart_C on NanoPi K2 is not working in
4.14.1. To my surprise it appears to be probing okay though.
Sadly just overwriting the clock-names property via overlay does not fix
my issue. Any ideas?
> +
> &vpu {
> compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
> };
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> index 8d4f316..9e67444 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> @@ -623,6 +623,31 @@
> clocks = <&clkc CLKID_SPI>;
> };
>
> +&uart_A {
> + clocks = <&xtal>, <&clkc CLKID_UART0>, <&xtal>;
> + clock-names = "xtal", "core", "baud";
Same issue spotted here and below.
> +};
> +
> +&uart_AO {
> + clocks = <&xtal>, <&clkc CLKID_CLK81>, <&xtal>;
> + clock-names = "xtal", "pclk", "baud";
> +};
> +
> +&uart_AO_B {
> + clocks = <&xtal>, <&clkc CLKID_CLK81>, <&xtal>;
> + clock-names = "xtal", "pclk", "baud";
> +};
> +
> +&uart_B {
> + clocks = <&xtal>, <&clkc CLKID_UART1>, <&xtal>;
> + clock-names = "xtal", "core", "baud";
> +};
> +
> +&uart_C {
> + clocks = <&xtal>, <&clkc CLKID_UART2>, <&xtal>;
> + clock-names = "xtal", "core", "baud";
> +};
> +
> &vpu {
> compatible = "amlogic,meson-gxl-vpu", "amlogic,meson-gx-vpu";
> };
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [PATCH 11/37] KVM: arm64: Improve debug register save/restore flow
From: Andrew Jones @ 2017-12-03 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201175203.GD6615@lvm>
On Fri, Dec 01, 2017 at 06:52:03PM +0100, Christoffer Dall wrote:
> On Tue, Nov 07, 2017 at 03:48:57PM +0100, Andrew Jones wrote:
> > On Thu, Oct 12, 2017 at 12:41:15PM +0200, Christoffer Dall wrote:
> > > Instead of having multiple calls from the world switch path to the debug
> > > logic, each figuring out if the dirty bit is set and if we should
> > > save/restore the debug registes, let's just provide two hooks to the
> > > debug save/restore functionality, one for switching to the guest
> > > context, and one for switching to the host context, and we get the
> > > benefit of only having to evaluate the dirty flag once on each path,
> > > plus we give the compiler some more room to inline some of this
> > > functionality.
> > >
> > > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> > > ---
> > > arch/arm64/include/asm/kvm_hyp.h | 10 ++-----
> > > arch/arm64/kvm/hyp/debug-sr.c | 56 +++++++++++++++++++++++++++-------------
> > > arch/arm64/kvm/hyp/switch.c | 6 ++---
> > > 3 files changed, 42 insertions(+), 30 deletions(-)
> > >
> > > diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
> > > index 08d3bb6..a0e5a70 100644
> > > --- a/arch/arm64/include/asm/kvm_hyp.h
> > > +++ b/arch/arm64/include/asm/kvm_hyp.h
> > > @@ -139,14 +139,8 @@ void __sysreg_restore_guest_state(struct kvm_cpu_context *ctxt);
> > > void __sysreg32_save_state(struct kvm_vcpu *vcpu);
> > > void __sysreg32_restore_state(struct kvm_vcpu *vcpu);
> > >
> > > -void __debug_save_state(struct kvm_vcpu *vcpu,
> > > - struct kvm_guest_debug_arch *dbg,
> > > - struct kvm_cpu_context *ctxt);
> > > -void __debug_restore_state(struct kvm_vcpu *vcpu,
> > > - struct kvm_guest_debug_arch *dbg,
> > > - struct kvm_cpu_context *ctxt);
> > > -void __debug_cond_save_host_state(struct kvm_vcpu *vcpu);
> > > -void __debug_cond_restore_host_state(struct kvm_vcpu *vcpu);
> > > +void __debug_switch_to_guest(struct kvm_vcpu *vcpu);
> > > +void __debug_switch_to_host(struct kvm_vcpu *vcpu);
> > >
> > > void __fpsimd_save_state(struct user_fpsimd_state *fp_regs);
> > > void __fpsimd_restore_state(struct user_fpsimd_state *fp_regs);
> > > diff --git a/arch/arm64/kvm/hyp/debug-sr.c b/arch/arm64/kvm/hyp/debug-sr.c
> > > index a2291b6..b4cd8e0 100644
> > > --- a/arch/arm64/kvm/hyp/debug-sr.c
> > > +++ b/arch/arm64/kvm/hyp/debug-sr.c
> > > @@ -116,16 +116,13 @@ static void __hyp_text __debug_restore_spe(u64 pmscr_el1)
> > > write_sysreg_s(pmscr_el1, PMSCR_EL1);
> > > }
> > >
> > > -void __hyp_text __debug_save_state(struct kvm_vcpu *vcpu,
> > > - struct kvm_guest_debug_arch *dbg,
> > > - struct kvm_cpu_context *ctxt)
> > > +static void __hyp_text __debug_save_state(struct kvm_vcpu *vcpu,
> > > + struct kvm_guest_debug_arch *dbg,
> > > + struct kvm_cpu_context *ctxt)
> > > {
> > > u64 aa64dfr0;
> > > int brps, wrps;
> > >
> > > - if (!(vcpu->arch.debug_flags & KVM_ARM64_DEBUG_DIRTY))
> > > - return;
> > > -
> > > aa64dfr0 = read_sysreg(id_aa64dfr0_el1);
> > > brps = (aa64dfr0 >> 12) & 0xf;
> > > wrps = (aa64dfr0 >> 20) & 0xf;
> > > @@ -138,16 +135,13 @@ void __hyp_text __debug_save_state(struct kvm_vcpu *vcpu,
> > > ctxt->sys_regs[MDCCINT_EL1] = read_sysreg(mdccint_el1);
> > > }
> > >
> > > -void __hyp_text __debug_restore_state(struct kvm_vcpu *vcpu,
> > > - struct kvm_guest_debug_arch *dbg,
> > > - struct kvm_cpu_context *ctxt)
> > > +static void __hyp_text __debug_restore_state(struct kvm_vcpu *vcpu,
> > > + struct kvm_guest_debug_arch *dbg,
> > > + struct kvm_cpu_context *ctxt)
> > > {
> > > u64 aa64dfr0;
> > > int brps, wrps;
> > >
> > > - if (!(vcpu->arch.debug_flags & KVM_ARM64_DEBUG_DIRTY))
> > > - return;
> > > -
> > > aa64dfr0 = read_sysreg(id_aa64dfr0_el1);
> > >
> > > brps = (aa64dfr0 >> 12) & 0xf;
> > > @@ -161,24 +155,50 @@ void __hyp_text __debug_restore_state(struct kvm_vcpu *vcpu,
> > > write_sysreg(ctxt->sys_regs[MDCCINT_EL1], mdccint_el1);
> > > }
> > >
> > > -void __hyp_text __debug_cond_save_host_state(struct kvm_vcpu *vcpu)
> > > +void __hyp_text __debug_switch_to_guest(struct kvm_vcpu *vcpu)
> > > {
> > > - __debug_save_state(vcpu, &vcpu->arch.host_debug_state.regs,
> > > - kern_hyp_va(vcpu->arch.host_cpu_context));
> > > + struct kvm_cpu_context *__host_ctxt;
> > > + struct kvm_cpu_context *__guest_ctxt;
> > > + struct kvm_guest_debug_arch *__host_dbg;
> > > + struct kvm_guest_debug_arch *__guest_dbg;
> >
> > I caught in your reply to Marc that the __ prefix here is for hyp mode
> > accessible code and data, but do we also need to use it for stack data?
> > No big deal, but it's not very pretty.
> >
>
> sure.
>
> > >
> > > /* Non-VHE: Disable and flush SPE data generation
> > > * VHE: The vcpu can run. but it can't hide. */
> > > if (!has_vhe())
> > > __debug_save_spe_nvhe(&vcpu->arch.host_debug_state.pmscr_el1);
> > > +
> > > + if (!(vcpu->arch.debug_flags & KVM_ARM64_DEBUG_DIRTY))
> > > + return;
> > > +
> > > + __host_ctxt = kern_hyp_va(vcpu->arch.host_cpu_context);
> > > + __guest_ctxt = &vcpu->arch.ctxt;
> > > + __host_dbg = &vcpu->arch.host_debug_state.regs;
> > > + __guest_dbg = kern_hyp_va(vcpu->arch.debug_ptr);
> > > +
> > > + __debug_save_state(vcpu, __host_dbg, __host_ctxt);
> > > + __debug_restore_state(vcpu, __guest_dbg, __guest_ctxt);
> > > }
> > >
> > > -void __hyp_text __debug_cond_restore_host_state(struct kvm_vcpu *vcpu)
> > > +void __hyp_text __debug_switch_to_host(struct kvm_vcpu *vcpu)
> > > {
> > > + struct kvm_cpu_context *__host_ctxt;
> > > + struct kvm_cpu_context *__guest_ctxt;
> > > + struct kvm_guest_debug_arch *__host_dbg;
> > > + struct kvm_guest_debug_arch *__guest_dbg;
> > > +
> > > if (!has_vhe())
> > > __debug_restore_spe(vcpu->arch.host_debug_state.pmscr_el1);
> > >
> > > - __debug_restore_state(vcpu, &vcpu->arch.host_debug_state.regs,
> > > - kern_hyp_va(vcpu->arch.host_cpu_context));
> > > + if (!(vcpu->arch.debug_flags & KVM_ARM64_DEBUG_DIRTY))
> > > + return;
> > > +
> > > + __host_ctxt = kern_hyp_va(vcpu->arch.host_cpu_context);
> > > + __guest_ctxt = &vcpu->arch.ctxt;
> > > + __host_dbg = &vcpu->arch.host_debug_state.regs;
> > > + __guest_dbg = kern_hyp_va(vcpu->arch.debug_ptr);
> > > +
> > > + __debug_save_state(vcpu, __guest_dbg, __guest_ctxt);
> > > + __debug_restore_state(vcpu, __host_dbg, __host_ctxt);
> > >
> > > vcpu->arch.debug_flags &= ~KVM_ARM64_DEBUG_DIRTY;
> > > }
> > > diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> > > index ef05c59..e270cba 100644
> > > --- a/arch/arm64/kvm/hyp/switch.c
> > > +++ b/arch/arm64/kvm/hyp/switch.c
> > > @@ -271,7 +271,6 @@ int __hyp_text __kvm_vcpu_run(struct kvm_vcpu *vcpu)
> > > guest_ctxt = &vcpu->arch.ctxt;
> > >
> > > __sysreg_save_host_state(host_ctxt);
> > > - __debug_cond_save_host_state(vcpu);
> > >
> > > __activate_traps(vcpu);
> > > __activate_vm(vcpu);
> > > @@ -285,7 +284,7 @@ int __hyp_text __kvm_vcpu_run(struct kvm_vcpu *vcpu)
> > > */
> > > __sysreg32_restore_state(vcpu);
> > > __sysreg_restore_guest_state(guest_ctxt);
> > > - __debug_restore_state(vcpu, kern_hyp_va(vcpu->arch.debug_ptr), guest_ctxt);
> > > + __debug_switch_to_guest(vcpu);
> > >
> > > /* Jump in the fire! */
> > > again:
> > > @@ -353,12 +352,11 @@ int __hyp_text __kvm_vcpu_run(struct kvm_vcpu *vcpu)
> > >
> > > __sysreg_restore_host_state(host_ctxt);
> > >
> > > - __debug_save_state(vcpu, kern_hyp_va(vcpu->arch.debug_ptr), guest_ctxt);
> > > /*
> > > * This must come after restoring the host sysregs, since a non-VHE
> > > * system may enable SPE here and make use of the TTBRs.
> > > */
> > > - __debug_cond_restore_host_state(vcpu);
> > > + __debug_switch_to_host(vcpu);
> > >
> > > return exit_code;
> > > }
> > > --
> > > 2.9.0
> > >
> >
> > This looks like a nice cleanup, but can you please add a note to the
> > commit message about why we don't need to use the
> >
> > save-host-state
> > activate-traps-and-vm
> > restore-guest-state
> >
> > and the reverse, patterns for the debug registers?
>
> I think the current commit message motivates the change fine.
>
The motivation is obvious, the justification for an additional change
is not. How does it justify changing the sequence
save-debug-host-state
activate-debug-traps /* and other stuff in between */
restore-debug-guest-state
to
activate-debug-traps /* and other stuff in between */
save-debug-host-state
restore-debug-guest-state
Thanks,
drew
^ permalink raw reply
* [PATCH v4 2/2] arm64: Add software workaround for Falkor erratum 1041
From: Shanker Donthineni @ 2017-12-03 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201112457.GE18083@arm.com>
Hi Will, thanks for your review comments.
On 12/01/2017 05:24 AM, Will Deacon wrote:
> On Mon, Nov 27, 2017 at 05:18:00PM -0600, Shanker Donthineni wrote:
>> The ARM architecture defines the memory locations that are permitted
>> to be accessed as the result of a speculative instruction fetch from
>> an exception level for which all stages of translation are disabled.
>> Specifically, the core is permitted to speculatively fetch from the
>> 4KB region containing the current program counter 4K and next 4K.
>>
>> When translation is changed from enabled to disabled for the running
>> exception level (SCTLR_ELn[M] changed from a value of 1 to 0), the
>> Falkor core may errantly speculatively access memory locations outside
>> of the 4KB region permitted by the architecture. The errant memory
>> access may lead to one of the following unexpected behaviors.
>>
>> 1) A System Error Interrupt (SEI) being raised by the Falkor core due
>> to the errant memory access attempting to access a region of memory
>> that is protected by a slave-side memory protection unit.
>> 2) Unpredictable device behavior due to a speculative read from device
>> memory. This behavior may only occur if the instruction cache is
>> disabled prior to or coincident with translation being changed from
>> enabled to disabled.
>>
>> The conditions leading to this erratum will not occur when either of the
>> following occur:
>> 1) A higher exception level disables translation of a lower exception level
>> (e.g. EL2 changing SCTLR_EL1[M] from a value of 1 to 0).
>> 2) An exception level disabling its stage-1 translation if its stage-2
>> translation is enabled (e.g. EL1 changing SCTLR_EL1[M] from a value of 1
>> to 0 when HCR_EL2[VM] has a value of 1).
>>
>> To avoid the errant behavior, software must execute an ISB immediately
>> prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0.
>>
>> Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
>> ---
>> Changes since v3:
>> Rebased to kernel v4.15-rc1.
>> Changes since v2:
>> Repost the corrected patches.
>> Changes since v1:
>> Apply the workaround where it's required.
>>
>> Documentation/arm64/silicon-errata.txt | 1 +
>> arch/arm64/Kconfig | 12 +++++++++++-
>> arch/arm64/include/asm/assembler.h | 19 +++++++++++++++++++
>> arch/arm64/include/asm/cpucaps.h | 3 ++-
>> arch/arm64/kernel/cpu-reset.S | 1 +
>> arch/arm64/kernel/cpu_errata.c | 16 ++++++++++++++++
>> arch/arm64/kernel/efi-entry.S | 2 ++
>> arch/arm64/kernel/head.S | 1 +
>> arch/arm64/kernel/relocate_kernel.S | 1 +
>> arch/arm64/kvm/hyp-init.S | 1 +
>
> This is an awful lot of code just to add an ISB instruction prior to
> disabling the MMU. Why do you need to go through the alternatives framework
> for this? Just do it with an #ifdef; this isn't a fastpath.
>
We can avoid changes to only two files cpu_errata.c and cpucaps.h without using
the alternatives framework. Even though it's in slow path, cpu-errata.c changes
provides a nice debug message which indicates the erratum E1041 is applied.
Erratum log information would be very useful to conform our customers using the
right kernel with E1014 patch by looking at dmesg. Other than that I don't have
any other strong opinion to avoid alternatives and handle using #idef.
Should I go head and post v5 patch without alternatives?
> Will
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Shanker Donthineni
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v2] ARM: dts: Add basic devicetree for D-Link DNS-313
From: Linus Walleij @ 2017-12-03 13:31 UTC (permalink / raw)
To: linux-arm-kernel
This adds a basic device tree for the D-Link DNS-313
NAS enclosure.
Cc: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Fixed the unit name on the MDIO PHY.
- Add the G751 temperature sensor
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/gemini-dlink-dns-313.dts | 195 +++++++++++++++++++++++++++++
2 files changed, 196 insertions(+)
create mode 100644 arch/arm/boot/dts/gemini-dlink-dns-313.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d0381e9caf21..4388905a4326 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -192,6 +192,7 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
exynos5800-peach-pi.dtb
dtb-$(CONFIG_ARCH_GEMINI) += \
gemini-dlink-dir-685.dtb \
+ gemini-dlink-dns-313.dtb \
gemini-nas4220b.dtb \
gemini-rut1xx.dtb \
gemini-sq201.dtb \
diff --git a/arch/arm/boot/dts/gemini-dlink-dns-313.dts b/arch/arm/boot/dts/gemini-dlink-dns-313.dts
new file mode 100644
index 000000000000..2fad9c3ee3d2
--- /dev/null
+++ b/arch/arm/boot/dts/gemini-dlink-dns-313.dts
@@ -0,0 +1,195 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree file for D-Link DNS-313 1-Bay Network Storage Enclosure
+ */
+
+/dts-v1/;
+
+#include "gemini.dtsi"
+#include <dt-bindings/input/input.h>
+
+/ {
+ model = "D-Link DNS-313 1-Bay Network Storage Enclosure";
+ compatible = "dlink,dir-313", "cortina,gemini";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ memory {
+ /* 64 MB SDRAM in a Nanya NT5DS32M16BS-6K package */
+ device_type = "memory";
+ reg = <0x00000000 0x4000000>;
+ };
+
+ aliases {
+ mdio-gpio0 = &mdio0;
+ };
+
+ chosen {
+ stdout-path = "uart0:19200n8";
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ button-esc {
+ debounce_interval = <50>;
+ wakeup-source;
+ linux,code = <KEY_ESC>;
+ label = "reset";
+ gpios = <&gpio1 31 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ led-power {
+ label = "dns313:blue:power";
+ gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ linux,default-trigger = "heartbeat";
+ };
+ led-disk-blue {
+ label = "dns313:blue:disk";
+ gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+ led-disk-green {
+ label = "dns313:green:disk";
+ gpios = <&gpio0 3 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ linux,default-trigger = "ide-disk";
+ /* Ideally should activate while reading */
+ };
+ led-disk-red {
+ label = "dns313:red:disk";
+ gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ /* Ideally should activate while writing */
+ };
+ };
+
+ /*
+ * This is a ADDA AD0405GB-G73 fan @3000 and 6000 RPM.
+ */
+ gpio-fan {
+ compatible = "gpio-fan";
+ gpios = <&gpio0 11 GPIO_ACTIVE_HIGH>,
+ <&gpio0 12 GPIO_ACTIVE_HIGH>;
+ gpio-fan,speed-map = <0 0>, <3000 1>, <6000 2>;
+ /* If this falls, something is wrong */
+ // alarm-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
+ #cooling-cells = <2>;
+ };
+
+
+ /* Global Mixed-Mode Technology G751 mounted on GPIO I2C */
+ gpio-i2c {
+ compatible = "i2c-gpio";
+ sda-gpios = <&gpio0 15 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
+ scl-gpios = <&gpio0 16 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ temperature-sensor at 48 {
+ compatible = "gmt,g751";
+ reg = <0x48>;
+ };
+ };
+
+ mdio0: ethernet-phy {
+ compatible = "virtual,mdio-gpio";
+ /* Uses MDC and MDIO */
+ gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>, /* MDC */
+ <&gpio0 21 GPIO_ACTIVE_HIGH>; /* MDIO */
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* This is a Realtek RTL8211B Gigabit ethernet transceiver */
+ phy0: ethernet-phy at 1 {
+ reg = <1>;
+ device_type = "ethernet-phy";
+ };
+ };
+
+ soc {
+ flash at 30000000 {
+ status = "okay";
+ /* 512KB of flash */
+ reg = <0x30000000 0x00080000>;
+
+ /*
+ * This "RedBoot" is the Storlink derivative.
+ */
+ partition at 0 {
+ label = "RedBoot";
+ reg = <0x00000000 0x00040000>;
+ read-only;
+ };
+ partition at 40000 {
+ label = "MTD1";
+ reg = <0x00040000 0x00020000>;
+ read-only;
+ };
+ partition at 60000 {
+ label = "MTD2";
+ reg = <0x00060000 0x00020000>;
+ read-only;
+ };
+ };
+
+ syscon: syscon at 40000000 {
+ pinctrl {
+ /*
+ */
+ gpio0_default_pins: pinctrl-gpio0 {
+ mux {
+ function = "gpio0";
+ groups =
+ /* Used by LEDs conflicts ICE */
+ "gpio0bgrp",
+ /* Used by ? conflicts ICE */
+ "gpio0cgrp",
+ /*
+ * Used by fan & G751, conflicts LPC,
+ * UART modem lines, SSP
+ */
+ "gpio0egrp",
+ /* Used by G751 */
+ "gpio0fgrp",
+ /* Used by MDIO */
+ "gpio0igrp";
+ };
+ };
+ gpio1_default_pins: pinctrl-gpio1 {
+ mux {
+ function = "gpio1";
+ /* Used by "reset" button */
+ groups = "gpio1dgrp";
+ };
+ };
+ };
+ };
+
+ sata: sata at 46000000 {
+ /* The ROM uses this muxmode */
+ cortina,gemini-ata-muxmode = <3>;
+ cortina,gemini-enable-sata-bridge;
+ status = "okay";
+ };
+
+ gpio0: gpio at 4d000000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio0_default_pins>;
+ };
+
+ gpio1: gpio at 4e000000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio1_default_pins>;
+ };
+
+ ata at 63000000 {
+ status = "okay";
+ };
+ };
+};
--
2.14.3
^ permalink raw reply related
* [PATCH 09/37] KVM: arm64: Move debug dirty flag calculation out of world switch
From: Andrew Jones @ 2017-12-03 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201172546.GB6615@lvm>
On Fri, Dec 01, 2017 at 06:25:46PM +0100, Christoffer Dall wrote:
> On Tue, Nov 07, 2017 at 03:09:19PM +0100, Andrew Jones wrote:
> > On Thu, Oct 12, 2017 at 12:41:13PM +0200, Christoffer Dall wrote:
> > > There is no need to figure out inside the world-switch if we should
> > > save/restore the debug registers or not, we can might as well do that in
> > > the higher level debug setup code, making it easier to optimize down the
> > > line.
> > >
> > > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> > > ---
> > > arch/arm64/kvm/debug.c | 9 +++++++++
> > > arch/arm64/kvm/hyp/debug-sr.c | 6 ------
> > > 2 files changed, 9 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
> > > index dbadfaf..62550de19 100644
> > > --- a/arch/arm64/kvm/debug.c
> > > +++ b/arch/arm64/kvm/debug.c
> > > @@ -193,6 +193,15 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)
> > > if (trap_debug)
> > > vcpu->arch.mdcr_el2 |= MDCR_EL2_TDA;
> > >
> > > + /*
> > > + * If any of KDE, MDE or KVM_ARM64_DEBUG_DIRTY is set, perform
> > > + * a full save/restore cycle.
> >
> > The commit message implies testing KVM_ARM64_DEBUG_DIRTY, but it only
> > tests KDE and MDE.
> >
>
> You meant the comment, right?
yup
>
> > > + */
> > > + if ((vcpu_sys_reg(vcpu, MDSCR_EL1) & DBG_MDSCR_KDE) ||
> > > + (vcpu_sys_reg(vcpu, MDSCR_EL1) & DBG_MDSCR_MDE))
> >
> > nit: could also write as
> >
> > if (vcpu_sys_reg(vcpu, MDSCR_EL1) & (DBG_MDSCR_KDE | DBG_MDSCR_MDE))
> >
>
> I actually prefer it the other way, and I think the compiler will figure
> out what to do in terms of efficiency.
I won't argue about code aesthetics (although I disagree here :-). I will
point out that in this case the compiler will no doubt do the right thing,
as vcpu_sys_reg() is just a macro, but for a pointer taking function in
general there would be potential to get both calls emitted, as the
compiler wouldn't be sure there would be no side effect.
>
> > > + vcpu->arch.debug_flags |= KVM_ARM64_DEBUG_DIRTY;
> > > +
> >
> > It looks like there's only one flag for debug_flags - this dirty flag,
> > which I guess is also used to trigger trapping. So maybe this could be a
> > second flag of a "lazy state" field, as I suggested earlier?
> >
>
> I'm going to leave this one for now, but we can improve that later on if
> we want to save a little space in the vcpu struct, or rather if we want
> to rearrange things to make frequently accessed fields fit in the same
> cache line.
>
OK
Thanks,
drew
^ permalink raw reply
* [nomadik:gemini-ethernet-rtl8366rb-jaminit 8/18] ERROR: "of_irq_count" [net/dsa/dsa_core.ko] undefined!
From: kbuild test robot @ 2017-12-03 12:55 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git gemini-ethernet-rtl8366rb-jaminit
head: 8c586e6e64b29afb74f775e785aab157d45ff801
commit: 67728777fbf459a4a4541afb18b0a61b5cae4137 [8/18] RFC: net/dsa: Allow DSA PHYs to define link IRQs
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 67728777fbf459a4a4541afb18b0a61b5cae4137
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> ERROR: "of_irq_count" [net/dsa/dsa_core.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 42674 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171203/21ae8f6d/attachment-0001.gz>
^ permalink raw reply
* [PATCH 0/6] Add CPU Frequency scaling support on Armada 37xx
From: Andre Heider @ 2017-12-03 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201112508.14121-1-gregory.clement@free-electrons.com>
Hi Gregory,
I applied this and the dvfs patch set ([PATCH 0/3] Add DVFS support on
CPU clock for Armada 37xx) on top of 4.14.3 and gave it a try on
espressobin.
Upon modprobe I get:
[ 66.231652] freq_table: Duplicate freq-table entries: 0
[ 66.236967] cpu cpu0: cpufreq_init: invalid frequency table: -22
[ 66.243534] freq_table: Duplicate freq-table entries: 0
[ 66.248575] cpu cpu1: cpufreq_init: invalid frequency table: -22
Is this supposed to work already? Do I miss something?
Oh, and on that scenario it's not possible to rmmod the driver again, EBUSY.
Thanks,
Andre
On 01/12/17 12:25, Gregory CLEMENT <gregory.clement@free-electrons.com>
wrote:
> Hi,
>
> This series adds the CPU Frequency support on Armada 37xx using
> DVFS. It is based on the initial work of Evan Wang and Victor Gu.
>
> DVFS control is done by a set of registers from the North Bridge Power
> Management block. The binding for this block is documented in patch 1.
>
> While adding a new cpufreq driver I found that the Kconfig and
> Makefile were no more in order, so it is fixed by patch 2 and 3.
>
> The 4th patch is just about updating the MAINTAINERS file with the new
> driver.
>
> The next patch is the real purpose of the series. The main goal of
> this driver is to setup the CPU load level in the hardware to
> associate them to CPU frequencies and register a standard cpufreq
> driver. Note that the hardware also capable of doing AVS (Adaptive
> Voltage Scaling), by associating a voltage on each level beside the
> CPU frequency. However, this support is not yet ready, so it is not
> part of this series.
>
> Finally, the last patch is for arm-soc the arm-soc subsystem through
> mvebu and update the device tree to support the CPU frequency scaling.
>
> An update on the CPU clock driver is needed in order to take into
> account the DVFS setting. It's the purpose of an other series already
> sent, but is no dependencies between the series (for building or at
> runtime).
>
> Thanks,
>
> Gregory
>
> Gregory CLEMENT (6):
> dt-bindings: marvell: Add documentation for the North Bridge PM on
> Armada 37xx
> cpufreq: ARM: sort the Kconfig menu
> cpufreq: sort the drivers in ARM part
> MAINTAINERS: add new entries for Armada 37xx cpufreq driver
> cpufreq: Add DVFS support for Armada 37xx
> arm64: dts: marvell: armada-37xx: add nodes allowing cpufreq support
>
> .../bindings/arm/marvell/armada-37xx.txt | 19 ++
> MAINTAINERS | 1 +
> arch/arm64/boot/dts/marvell/armada-372x.dtsi | 1 +
> arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 7 +
> drivers/cpufreq/Kconfig.arm | 89 ++++----
> drivers/cpufreq/Makefile | 9 +-
> drivers/cpufreq/armada-37xx-cpufreq.c | 241 +++++++++++++++++++++
> 7 files changed, 322 insertions(+), 45 deletions(-)
> create mode 100644 drivers/cpufreq/armada-37xx-cpufreq.c
>
^ permalink raw reply
* [PATCH] ARM: dts: exynos: Add missing interrupt-controller properties to Exynos5410 PMU
From: Krzysztof Kozlowski @ 2017-12-03 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171129183610.26305-1-krzk@kernel.org>
On Wed, Nov 29, 2017 at 07:36:10PM +0100, Krzysztof Kozlowski wrote:
> PMU (system-controller at 10040000) is used as interrupt-parent for certain
> nodes thus it should be marked as interrupt-controller to silence
> warnings when building Exynos5410-based DTBs:
>
> arch/arm/boot/dts/exynos5410-odroidxu.dtb: Warning (interrupts_property):
> Missing interrupt-controller or interrupt-map property in /soc/system-controller at 10040000
> arch/arm/boot/dts/exynos5410-odroidxu.dtb: Warning (interrupts_property):
> Missing #interrupt-cells in interrupt-parent /soc/system-controller at 10040000
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> arch/arm/boot/dts/exynos5410.dtsi | 3 +++
> 1 file changed, 3 insertions(+)
For the record, applied.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] arm: l2c: unlock ways when in non-secure mode
From: Peng Fan @ 2017-12-03 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB6PR04MB3221EDB9EEF8F2606FC292B5883A0@DB6PR04MB3221.eurprd04.prod.outlook.com>
Hi Russell,
> > > > > >
> > > > > > On Sun, Nov 26, 2017 at 08:25:30PM +0800, Peng Fan wrote:
> > > > > > > To boot Linux in Non-secure mode with l2x0, the l2x0
> > > > > > > controller is enabled in secure mode and ways locked to make
> > > > > > > it seems L2 cache disabled during linux boot process. So
> > > > > > > during l2x0 initialization, need to unlock the ways to make
> > > > > > > l2x0 could
> > cache data/inst.
> > > > > >
> > > > > > Why was this chosen instead of doing what everyone else does?
> > > > >
> > > > > I am not aware of how other platform handles the l2x0 unlock in
> > > > > non secure mode. Could you please share with me what others choose?
> > > >
> > > > That's not what I was asking.
> > > >
> > > > Everyone else provides a way for the l2x0 controller to be enabled
> > > > and disabled from non-secure mode.
> > >
> > > Thanks for the information. I see that some platforms implements
> > l2c_write_sec.
> > >
> > > >
> > > > Why have you decided to enable the l2x0 controller and leave it
> > > > enabled, and then lock down all the cache ways - which means you
> > > > need the kernel to do something entirely different for your platform.
> > >
> > > Currently we are running OP-TEE on i.MX6/7 with Linux in non-secure
> > > mode. See In
> > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
> > > it
> > > hub.com%2FOP-
> > TEE%2Foptee_os%2Fblob%2Fmaster%2Fcore%2Farch%2Farm%2Fkern
> > >
> > el%2Fgeneric_entry_a32.S%23L428&data=02%7C01%7Cpeng.fan%40nxp.com%
> > 7C32
> > >
> >
> e10e1e643f4def0d9508d535805486%7C686ea1d3bc2b4c6fa92cd99c5c301635%7
> > C0%
> > >
> >
> 7C0%7C636473747645673295&sdata=ZGaxxhs8mPNcqk5l2aSiStkPRFNxLzFFj45w
> > kj%
> > > 2Ff%2Fu4%3D&reserved=0
> > > Pl310 is enabled. And In
> > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
> > > it
> > > hub.com%2FOP-
> > TEE%2Foptee_os%2Fblob%2Fmaster%2Fcore%2Farch%2Farm%2Fkern
> > >
> > el%2Fgeneric_entry_a32.S%23L461&data=02%7C01%7Cpeng.fan%40nxp.com%
> > 7C32
> > >
> >
> e10e1e643f4def0d9508d535805486%7C686ea1d3bc2b4c6fa92cd99c5c301635%7
> > C0%
> > >
> >
> 7C0%7C636473747645673295&sdata=rO1LG3639lfclvtgzZRTTPcSAGDQNG0Clqb
> > D1wC
> > > 4wGk%3D&reserved=0
> > > pl310 locked before returning back to Linux.
> > >
> > > I see ti platform not enabled pl310 in OP-TEE, leaving Linux to
> > > enable it. platform-sam/stm/ zynq7k/imx Have pl310 enabled in OP-TEE.
> > >
> > > I could switch to use l2c_write_sec dedicated for i.MX. But I think
> > > this patch is
> > also a valid point.
> > > What do you suggest?
> >
> > What I'm concerned about is that there's a valid scenario where the L2
> > cache would be enabled and left enabled by the secure mode code - that
> > is if the secure mode wishes to take advantage of the L2 cache, and
> > has locked down some ways for its own use.
> >
> > In this scenario, the secure world would have set the L2 cache up to
> > prevent the non-secure side unlocking those ways. This would mean
> > that the NS_LOCKDOWN bit in the auxiliary control register would be
> > clear. The PL310 TRM has this to say:
> >
> > "On reset the Non-Secure Lockdown Enable bit is set to 0 and Lockdown
> > Registers are not permitted to be modified by non-secure accesses. In
> > that configuration, if a non-secure access tries to write to those
> > registers, the write response returns a DECERR response."
> >
> > which means that if we blindly try and unlock the ways, we will end up
> > triggering an exception, and that will crash the kernel.
Just have a follow up question. If implementing l2c_write_sec, the kernel image
could not only running in non-secure world. If we want the image to support
running in secure and non-secure world, do you have any suggestions about
the l2c things?
Thanks,
Peng.
>
> Currently, we set auxiliary control register to let NS could unlock. BIT26 set to 1.
> But you bring a valid point is if TEE would like to lock down some ways for its
> own use, l2c_write_sec should be used, to avoid Linux to directly unlock.
>
> >
> > Given that the kernel does _not_ handle this scenario today, I fail to
> > see why OP-TEE would decide that, on ARM by default, it will enable
> > the L2 cache and lock all ways.
> >
> > As you have already found, at least OMAP has decided to do things
> > sensibly. I fail to see why everyone else can't also decide to do the sensible
> thing.
>
> Most platforms just set BIT26 to allow non-secure unlock ways without
> considering reserving ways dedicated to TEE.
>
> i.MX also has BIT26 set, so if l2c_init is not a good place, do you think moving
> unlock to imx_init_l2cache is ok? But this means "enabling(unlock)" L2C earlier
> which is before l2c_init
>
> >
> > Please talk to the OP-TEE folk to see whether the OP-TEE behaviour can
> > be changed first.
>
> +OP-TEE maintainers Etienne, Jens
> Do you have comments on this?
>
> Thanks,
> Peng.
>
> >
> > --
> > RMK's Patch system:
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> >
> armlinux.org.uk%2Fdeveloper%2Fpatches%2F&data=02%7C01%7Cpeng.fan%4
> >
> 0nxp.com%7C32e10e1e643f4def0d9508d535805486%7C686ea1d3bc2b4c6fa92c
> >
> d99c5c301635%7C0%7C0%7C636473747645673295&sdata=4i8a6dYNkHlMXiYQZ
> > N9Ej4b68q%2FZfMCZvIUfJtFy0Jc%3D&reserved=0
> > FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down
> > 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH 1/2] dt-bindings: trivial: add tfa9879 device
From: Fabio Estevam @ 2017-12-03 11:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8e295c61-089e-170d-bca2-42ded2021c99@axentia.se>
Hi Peter,
On Sun, Dec 3, 2017 at 4:59 AM, Peter Rosin <peda@axentia.se> wrote:
> Right. However, the patch adding that should have been sent to me, the
> maintainer of the driver. That is carefully recorded in MAINTAINERS. So,
> forgive me for assuming that nothing had changed in the driver behind my
> back.
>
> Had that patch been sent my way as it should have been, I would have
> insisted that maintenance of the bindings had been kept together with
> the maintenance of the driver.
When I sent this patch ./scripts/get_maintainer.pl did lot list your
name, so that's why I did not put you on Cc, sorry.
4.15-rc1 still does not list you, but linux-next does.
Would you like me to send the following patch so that new binding
updates go to you?
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9808,6 +9808,7 @@ NXP TFA9879 DRIVER
M: Peter Rosin <peda@axentia.se>
L: alsa-devel at alsa-project.org (moderated for non-subscribers)
S: Maintained
+F: Documentation/devicetree/bindings/sound/tfa9879.txt
F: sound/soc/codecs/tfa9879*
^ permalink raw reply
* [PATCH v2 4/4] thermal: armada: use msleep for long delays
From: Baruch Siach @ 2017-12-03 11:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f8c589337a4fb78852eadf15058e8f8d132d4dc0.1512299484.git.baruch@tkos.co.il>
Use msleep for long (> 10ms) delays, instead of the busy waiting mdelay.
All delays are called from the probe routine, where scheduling is
allowed.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
v2: New patch
---
drivers/thermal/armada_thermal.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 59b75f63945d..d86538d4f519 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -119,7 +119,7 @@ static void armada370_init_sensor(struct platform_device *pdev,
reg &= ~PMU_TDC0_START_CAL_MASK;
writel(reg, priv->control);
- mdelay(10);
+ msleep(10);
}
static void armada375_init_sensor(struct platform_device *pdev,
@@ -133,11 +133,11 @@ static void armada375_init_sensor(struct platform_device *pdev,
reg &= ~A375_HW_RESETn;
writel(reg, priv->control + 4);
- mdelay(20);
+ msleep(20);
reg |= A375_HW_RESETn;
writel(reg, priv->control + 4);
- mdelay(50);
+ msleep(50);
}
static void armada380_init_sensor(struct platform_device *pdev,
@@ -151,7 +151,7 @@ static void armada380_init_sensor(struct platform_device *pdev,
if (!(reg & A380_HW_RESET)) {
reg |= A380_HW_RESET;
writel(reg, control_msb);
- mdelay(10);
+ msleep(10);
}
}
--
2.15.0
^ permalink raw reply related
* [PATCH v2 3/4] thermal: armada: add support for CP110
From: Baruch Siach @ 2017-12-03 11:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f8c589337a4fb78852eadf15058e8f8d132d4dc0.1512299484.git.baruch@tkos.co.il>
The CP110 component is integrated in the Armada 8k and 7k lines of processors.
This patch also adds an option of offset to the MSB of the control
register. The existing DT binding for Armada 38x refers to a single 32 bit
control register. It turns out that this is actually only the MSB of the
control area. Changing the binding to fix that would break existing DT files,
so the Armada 38x binding is left as is.
The new CP110 binding increases the size of the control area to 64 bits, thus
moving the MSB to offset 4.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
v2: No change
---
drivers/thermal/armada_thermal.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 0eb82097571f..59b75f63945d 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -73,6 +73,7 @@ struct armada_thermal_data {
unsigned int temp_shift;
unsigned int temp_mask;
unsigned int is_valid_shift;
+ unsigned int control_msb_offset;
};
static void armadaxp_init_sensor(struct platform_device *pdev,
@@ -142,12 +143,14 @@ static void armada375_init_sensor(struct platform_device *pdev,
static void armada380_init_sensor(struct platform_device *pdev,
struct armada_thermal_priv *priv)
{
- unsigned long reg = readl_relaxed(priv->control);
+ void __iomem *control_msb =
+ priv->control + priv->data->control_msb_offset;
+ unsigned long reg = readl_relaxed(control_msb);
/* Reset hardware once */
if (!(reg & A380_HW_RESET)) {
reg |= A380_HW_RESET;
- writel(reg, priv->control);
+ writel(reg, control_msb);
mdelay(10);
}
}
@@ -266,6 +269,19 @@ static const struct armada_thermal_data armada_ap806_data = {
.signed_sample = true,
};
+static const struct armada_thermal_data armada_cp110_data = {
+ .is_valid = armada_is_valid,
+ .init_sensor = armada380_init_sensor,
+ .is_valid_shift = 10,
+ .temp_shift = 0,
+ .temp_mask = 0x3ff,
+ .control_msb_offset = 4,
+ .coef_b = 1172499100UL,
+ .coef_m = 2000096UL,
+ .coef_div = 4201,
+ .inverted = true,
+};
+
static const struct of_device_id armada_thermal_id_table[] = {
{
.compatible = "marvell,armadaxp-thermal",
@@ -287,6 +303,10 @@ static const struct of_device_id armada_thermal_id_table[] = {
.compatible = "marvell,armada-ap806-thermal",
.data = &armada_ap806_data,
},
+ {
+ .compatible = "marvell,armada-cp110-thermal",
+ .data = &armada_cp110_data,
+ },
{
/* sentinel */
},
--
2.15.0
^ permalink raw reply related
* [PATCH v2 2/4] thermal: armada: add support for AP806
From: Baruch Siach @ 2017-12-03 11:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f8c589337a4fb78852eadf15058e8f8d132d4dc0.1512299484.git.baruch@tkos.co.il>
The AP806 component is integrated in the Armada 8k and 7k lines of processors.
The thermal sensor sample field on the status register is a signed
value. Extend armada_get_temp() to handle signed values.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
v2:
Use msleep instead of mdelay (RMK).
Fix temperature calculation formula according to recent documentation
and vendor code. Update the commit log.
---
drivers/thermal/armada_thermal.c | 44 ++++++++++++++++++++++++++++++++++++++--
1 file changed, 42 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 706d74798cbe..0eb82097571f 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -41,6 +41,10 @@
#define A375_HW_RESETn BIT(8)
#define A380_HW_RESET BIT(8)
+#define AP806_START BIT(0)
+#define AP806_RESET BIT(1)
+#define AP806_ENABLE BIT(2)
+
struct armada_thermal_data;
/* Marvell EBU Thermal Sensor Dev Structure */
@@ -63,6 +67,7 @@ struct armada_thermal_data {
unsigned long coef_m;
unsigned long coef_div;
bool inverted;
+ bool signed_sample;
/* Register shift and mask to access the sensor temperature */
unsigned int temp_shift;
@@ -147,6 +152,18 @@ static void armada380_init_sensor(struct platform_device *pdev,
}
}
+static void armada_ap806_init_sensor(struct platform_device *pdev,
+ struct armada_thermal_priv *priv)
+{
+ u32 reg = readl_relaxed(priv->control);
+
+ reg &= ~AP806_RESET;
+ reg |= AP806_START;
+ reg |= AP806_ENABLE;
+ writel(reg, priv->control);
+ msleep(10);
+}
+
static bool armada_is_valid(struct armada_thermal_priv *priv)
{
unsigned long reg = readl_relaxed(priv->sensor);
@@ -160,6 +177,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
struct armada_thermal_priv *priv = thermal->devdata;
unsigned long reg;
unsigned long m, b, div;
+ int sample;
/* Valid check */
if (priv->data->is_valid && !priv->data->is_valid(priv)) {
@@ -170,6 +188,11 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
reg = readl_relaxed(priv->sensor);
reg = (reg >> priv->data->temp_shift) & priv->data->temp_mask;
+ if (priv->data->signed_sample)
+ /* The most significant bit is the sign bit */
+ sample = sign_extend32(reg, fls(priv->data->temp_mask) - 1);
+ else
+ sample = reg;
/* Get formula coeficients */
b = priv->data->coef_b;
@@ -177,9 +200,9 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
div = priv->data->coef_div;
if (priv->data->inverted)
- *temp = ((m * reg) - b) / div;
+ *temp = ((m * sample) - b) / div;
else
- *temp = (b - (m * reg)) / div;
+ *temp = (b - (m * sample)) / div;
return 0;
}
@@ -230,6 +253,19 @@ static const struct armada_thermal_data armada380_data = {
.inverted = true,
};
+static const struct armada_thermal_data armada_ap806_data = {
+ .is_valid = armada_is_valid,
+ .init_sensor = armada_ap806_init_sensor,
+ .is_valid_shift = 16,
+ .temp_shift = 0,
+ .temp_mask = 0x3ff,
+ .coef_b = -150000,
+ .coef_m = 423UL,
+ .coef_div = 1,
+ .inverted = true,
+ .signed_sample = true,
+};
+
static const struct of_device_id armada_thermal_id_table[] = {
{
.compatible = "marvell,armadaxp-thermal",
@@ -247,6 +283,10 @@ static const struct of_device_id armada_thermal_id_table[] = {
.compatible = "marvell,armada380-thermal",
.data = &armada380_data,
},
+ {
+ .compatible = "marvell,armada-ap806-thermal",
+ .data = &armada_ap806_data,
+ },
{
/* sentinel */
},
--
2.15.0
^ permalink raw reply related
* [PATCH v2 1/4] dt-bindings: thermal/armada: describe AP806 and CP110
From: Baruch Siach @ 2017-12-03 11:11 UTC (permalink / raw)
To: linux-arm-kernel
Add compatible strings for AP806 and CP110 that are part of the Armada 8k/7k
line of SoCs.
Add a note on the difference in the size of the control area in different
bindings. This is an existing difference between the Armada 375 binding and
the rest. The new AP806 and CP110 bindings are similar to the existing Armada
375 in this regard.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
v2: No change
---
Documentation/devicetree/bindings/thermal/armada-thermal.txt | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/thermal/armada-thermal.txt b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
index 24aacf8948c5..eec57f509166 100644
--- a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
@@ -7,12 +7,19 @@ Required properties:
marvell,armada375-thermal
marvell,armada380-thermal
marvell,armadaxp-thermal
+ marvell,armada-ap806-thermal
+ marvell,armada-cp110-thermal
- reg: Device's register space.
Two entries are expected, see the examples below.
The first one is required for the sensor register;
- the second one is required for the control register
+ the second one is required for the control area
to be used for sensor initialization (a.k.a. calibration).
+ The size of the control area must be 4 for
+ marvell,armada370-thermal, marvell,armada380-thermal, and
+ marvell,armadaxp-thermal. The size must be 8 for
+ marvell,armada375-thermal, marvell,armada-ap806-thermal, and
+ marvell,armada-cp110-thermal.
Example:
--
2.15.0
^ permalink raw reply related
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