* [PATCH v3 2/2] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
From: Dongjiu Geng @ 2018-06-05 20:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528231582-19370-1-git-send-email-gengdongjiu@huawei.com>
For the migrating VMs, user space may need to know the exception
state. For example, in the machine A, KVM make an SError pending,
when migrate to B, KVM also needs to pend an SError.
This new IOCTL exports user-invisible states related to SError.
Together with appropriate user space changes, user space can get/set
the SError exception state to do migrate/snapshot/suspend.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
--
change since v2:
1. Add kvm_vcpu_events structure definition.
change since v1:
Address Marc's comments, thanks Marc's review
1. serror_has_esr always true when ARM64_HAS_RAS_EXTN is set
2. remove Spurious blank line in kvm_arm_vcpu_set_events()
3. rename pend_guest_serror() to kvm_set_sei_esr()
4. Make kvm_arm_vcpu_get_events() did all the work rather than having this split responsibility.
5. using sizeof(events) instead of sizeof(struct kvm_vcpu_events)
this series patch is separated from https://www.spinics.net/lists/kvm/msg168917.html
The user space patch is here: https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg06965.html
change since V12:
1. change (vcpu->arch.hcr_el2 & HCR_VSE) to !!(vcpu->arch.hcr_el2 & HCR_VSE) in kvm_arm_vcpu_get_events()
Change since V11:
Address James's comments, thanks James
1. Align the struct of kvm_vcpu_events to 64 bytes
2. Avoid exposing the stale ESR value in the kvm_arm_vcpu_get_events()
3. Change variables 'injected' name to 'serror_pending' in the kvm_arm_vcpu_set_events()
4. Change to sizeof(events) from sizeof(struct kvm_vcpu_events) in kvm_arch_vcpu_ioctl()
Change since V10:
Address James's comments, thanks James
1. Merge the helper function with the user.
2. Move the ISS_MASK into pend_guest_serror() to clear top bits
3. Make kvm_vcpu_events struct align to 4 bytes
4. Add something check in the kvm_arm_vcpu_set_events()
5. Check kvm_arm_vcpu_get/set_events()'s return value.
6. Initialise kvm_vcpu_events to 0 so that padding transferred to user-space doesn't
contain kernel stack.
---
Documentation/virtual/kvm/api.txt | 31 ++++++++++++++++++++++++++++---
arch/arm/include/asm/kvm_host.h | 6 ++++++
arch/arm/include/uapi/asm/kvm.h | 12 ++++++++++++
arch/arm/kvm/guest.c | 12 ++++++++++++
arch/arm64/include/asm/kvm_emulate.h | 5 +++++
arch/arm64/include/asm/kvm_host.h | 7 +++++++
arch/arm64/include/uapi/asm/kvm.h | 13 +++++++++++++
arch/arm64/kvm/guest.c | 36 ++++++++++++++++++++++++++++++++++++
arch/arm64/kvm/inject_fault.c | 6 +++---
arch/arm64/kvm/reset.c | 1 +
virt/kvm/arm/arm.c | 19 +++++++++++++++++++
11 files changed, 142 insertions(+), 6 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index fdac969..8896737 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -835,11 +835,13 @@ struct kvm_clock_data {
Capability: KVM_CAP_VCPU_EVENTS
Extended by: KVM_CAP_INTR_SHADOW
-Architectures: x86
+Architectures: x86, arm, arm64
Type: vm ioctl
Parameters: struct kvm_vcpu_event (out)
Returns: 0 on success, -1 on error
+X86:
+
Gets currently pending exceptions, interrupts, and NMIs as well as related
states of the vcpu.
@@ -881,15 +883,32 @@ Only two fields are defined in the flags field:
- KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that
smi contains a valid state.
+ARM, ARM64:
+
+Gets currently pending SError exceptions as well as related states of the vcpu.
+
+struct kvm_vcpu_events {
+ struct {
+ __u8 serror_pending;
+ __u8 serror_has_esr;
+ /* Align it to 8 bytes */
+ __u8 pad[6];
+ __u64 serror_esr;
+ } exception;
+ __u32 reserved[12];
+};
+
4.32 KVM_SET_VCPU_EVENTS
-Capability: KVM_CAP_VCPU_EVENTS
+Capebility: KVM_CAP_VCPU_EVENTS
Extended by: KVM_CAP_INTR_SHADOW
-Architectures: x86
+Architectures: x86, arm, arm64
Type: vm ioctl
Parameters: struct kvm_vcpu_event (in)
Returns: 0 on success, -1 on error
+X86:
+
Set pending exceptions, interrupts, and NMIs as well as related states of the
vcpu.
@@ -910,6 +929,12 @@ shall be written into the VCPU.
KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available.
+ARM, ARM64:
+
+Set pending SError exceptions as well as related states of the vcpu.
+
+See KVM_GET_VCPU_EVENTS for the data structure.
+
4.33 KVM_GET_DEBUGREGS
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index c7c28c8..39f9901 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -213,6 +213,12 @@ unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu);
int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
+
unsigned long kvm_call_hyp(void *hypfn, ...);
void force_vm_exit(const cpumask_t *mask);
diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
index caae484..c3e6975 100644
--- a/arch/arm/include/uapi/asm/kvm.h
+++ b/arch/arm/include/uapi/asm/kvm.h
@@ -124,6 +124,18 @@ struct kvm_sync_regs {
struct kvm_arch_memory_slot {
};
+/* for KVM_GET/SET_VCPU_EVENTS */
+struct kvm_vcpu_events {
+ struct {
+ __u8 serror_pending;
+ __u8 serror_has_esr;
+ /* Align it to 8 bytes */
+ __u8 pad[6];
+ __u64 serror_esr;
+ } exception;
+ __u32 reserved[12];
+};
+
/* If you need to interpret the index values, here is the key: */
#define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
#define KVM_REG_ARM_COPROC_SHIFT 16
diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
index a18f33e..c685f0e 100644
--- a/arch/arm/kvm/guest.c
+++ b/arch/arm/kvm/guest.c
@@ -261,6 +261,18 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return -EINVAL;
}
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ return -EINVAL;
+}
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ return -EINVAL;
+}
+
int __attribute_const__ kvm_target_cpu(void)
{
switch (read_cpuid_part()) {
diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index 1dab3a9..18f61ff 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -81,6 +81,11 @@ static inline unsigned long *vcpu_hcr(struct kvm_vcpu *vcpu)
return (unsigned long *)&vcpu->arch.hcr_el2;
}
+static inline unsigned long vcpu_get_vsesr(struct kvm_vcpu *vcpu)
+{
+ return vcpu->arch.vsesr_el2;
+}
+
static inline void vcpu_set_vsesr(struct kvm_vcpu *vcpu, u64 vsesr)
{
vcpu->arch.vsesr_el2 = vsesr;
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 469de8a..357304a 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -335,6 +335,11 @@ unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu);
int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
#define KVM_ARCH_WANT_MMU_NOTIFIER
int kvm_unmap_hva(struct kvm *kvm, unsigned long hva);
@@ -363,6 +368,8 @@ void handle_exit_early(struct kvm_vcpu *vcpu, struct kvm_run *run,
int kvm_perf_init(void);
int kvm_perf_teardown(void);
+void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome);
+
struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
void __kvm_set_tpidr_el2(u64 tpidr_el2);
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 04b3256..df4faee 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -39,6 +39,7 @@
#define __KVM_HAVE_GUEST_DEBUG
#define __KVM_HAVE_IRQ_LINE
#define __KVM_HAVE_READONLY_MEM
+#define __KVM_HAVE_VCPU_EVENTS
#define KVM_COALESCED_MMIO_PAGE_OFFSET 1
@@ -153,6 +154,18 @@ struct kvm_sync_regs {
struct kvm_arch_memory_slot {
};
+/* for KVM_GET/SET_VCPU_EVENTS */
+struct kvm_vcpu_events {
+ struct {
+ __u8 serror_pending;
+ __u8 serror_has_esr;
+ /* Align it to 8 bytes */
+ __u8 pad[6];
+ __u64 serror_esr;
+ } exception;
+ __u32 reserved[12];
+};
+
/* If you need to interpret the index values, here is the key: */
#define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
#define KVM_REG_ARM_COPROC_SHIFT 16
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 56a0260..542ec2d 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -289,6 +289,42 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return -EINVAL;
}
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ memset(&events, 0, sizeof(events));
+
+ events->exception.serror_pending = !!(vcpu->arch.hcr_el2 & HCR_VSE);
+ events->exception.serror_has_esr =
+ cpus_have_const_cap(ARM64_HAS_RAS_EXTN);
+
+ if (events->exception.serror_pending &&
+ events->exception.serror_has_esr)
+ events->exception.serror_esr = vcpu_get_vsesr(vcpu);
+ else
+ events->exception.serror_esr = 0;
+
+ return 0;
+}
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ bool serror_pending = events->exception.serror_pending;
+ bool has_esr = events->exception.serror_has_esr;
+
+ if (serror_pending && has_esr) {
+ if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN))
+ return -EINVAL;
+
+ kvm_set_sei_esr(vcpu, events->exception.serror_esr);
+ } else if (serror_pending) {
+ kvm_inject_vabt(vcpu);
+ }
+
+ return 0;
+}
+
int __attribute_const__ kvm_target_cpu(void)
{
unsigned long implementor = read_cpuid_implementor();
diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
index d8e7165..a55e91d 100644
--- a/arch/arm64/kvm/inject_fault.c
+++ b/arch/arm64/kvm/inject_fault.c
@@ -164,9 +164,9 @@ void kvm_inject_undefined(struct kvm_vcpu *vcpu)
inject_undef64(vcpu);
}
-static void pend_guest_serror(struct kvm_vcpu *vcpu, u64 esr)
+void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 esr)
{
- vcpu_set_vsesr(vcpu, esr);
+ vcpu_set_vsesr(vcpu, esr & ESR_ELx_ISS_MASK);
*vcpu_hcr(vcpu) |= HCR_VSE;
}
@@ -184,5 +184,5 @@ static void pend_guest_serror(struct kvm_vcpu *vcpu, u64 esr)
*/
void kvm_inject_vabt(struct kvm_vcpu *vcpu)
{
- pend_guest_serror(vcpu, ESR_ELx_ISV);
+ kvm_set_sei_esr(vcpu, ESR_ELx_ISV);
}
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 38c8a64..20e919a 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -82,6 +82,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext)
break;
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_VCPU_ATTRIBUTES:
+ case KVM_CAP_VCPU_EVENTS:
r = 1;
break;
default:
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index a4c1b76..79ecba9 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -1107,6 +1107,25 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
r = kvm_arm_vcpu_has_attr(vcpu, &attr);
break;
}
+ case KVM_GET_VCPU_EVENTS: {
+ struct kvm_vcpu_events events;
+
+ if (kvm_arm_vcpu_get_events(vcpu, &events))
+ return -EINVAL;
+
+ if (copy_to_user(argp, &events, sizeof(events)))
+ return -EFAULT;
+
+ return 0;
+ }
+ case KVM_SET_VCPU_EVENTS: {
+ struct kvm_vcpu_events events;
+
+ if (copy_from_user(&events, argp, sizeof(events)))
+ return -EFAULT;
+
+ return kvm_arm_vcpu_set_events(vcpu, &events);
+ }
default:
r = -EINVAL;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/2] arm64: KVM: export the capability to set guest SError syndrome
From: Dongjiu Geng @ 2018-06-05 20:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528231582-19370-1-git-send-email-gengdongjiu@huawei.com>
For the arm64 RAS Extension, user space can inject a virtual-SError
with specified ESR. So user space needs to know whether KVM support
to inject such SError, this interface adds this query for this capability.
KVM will check whether system support RAS Extension, if supported, KVM
returns true to user space, otherwise returns false.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
Reviewed-by: James Morse <james.morse@arm.com>
---
Documentation/virtual/kvm/api.txt | 11 +++++++++++
arch/arm64/kvm/reset.c | 3 +++
include/uapi/linux/kvm.h | 1 +
3 files changed, 15 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 758bf40..fdac969 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -4603,3 +4603,14 @@ Architectures: s390
This capability indicates that kvm will implement the interfaces to handle
reset, migration and nested KVM for branch prediction blocking. The stfle
facility 82 should not be provided to the guest without this capability.
+
+8.14 KVM_CAP_ARM_SET_SERROR_ESR
+
+Architectures: arm, arm64
+
+This capability indicates that userspace can specify the syndrome value reported
+to the guest OS when guest takes a virtual SError interrupt exception.
+If KVM has this capability, userspace can only specify the ISS field for the ESR
+syndrome, it can not specify the EC field which is not under control by KVM.
+If this virtual SError is taken to EL1 using AArch64, this value will be reported
+in ISS filed of ESR_EL1.
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 3256b92..38c8a64 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_ARM_PMU_V3:
r = kvm_arm_support_pmu_v3();
break;
+ case KVM_CAP_ARM_INJECT_SERROR_ESR:
+ r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN);
+ break;
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_VCPU_ATTRIBUTES:
r = 1;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index b02c41e..e88f976 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -948,6 +948,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_S390_BPB 152
#define KVM_CAP_GET_MSR_FEATURES 153
#define KVM_CAP_HYPERV_EVENTFD 154
+#define KVM_CAP_ARM_INJECT_SERROR_ESR 155
#ifdef KVM_CAP_IRQ_ROUTING
--
2.7.4
^ permalink raw reply related
* [PATCH v3 0/2] support to set VSESR_EL2 by user space
From: Dongjiu Geng @ 2018-06-05 20:46 UTC (permalink / raw)
To: linux-arm-kernel
This series patch is separated from https://www.spinics.net/lists/kvm/msg168917.html
1. Detect whether KVM can set set guest SError syndrome
2. Support to Set VSESR_EL2 and inject SError by user space.
3. Support live migration to keep SError pending state and VSESR_EL2 value
The user space patch is here: https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg06965.html
Dongjiu Geng (2):
arm64: KVM: export the capability to set guest SError syndrome
arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
Documentation/virtual/kvm/api.txt | 42 +++++++++++++++++++++++++++++++++---
arch/arm/include/asm/kvm_host.h | 6 ++++++
arch/arm/include/uapi/asm/kvm.h | 12 +++++++++++
arch/arm/kvm/guest.c | 12 +++++++++++
arch/arm64/include/asm/kvm_emulate.h | 5 +++++
arch/arm64/include/asm/kvm_host.h | 7 ++++++
arch/arm64/include/uapi/asm/kvm.h | 13 +++++++++++
arch/arm64/kvm/guest.c | 36 +++++++++++++++++++++++++++++++
arch/arm64/kvm/inject_fault.c | 6 +++---
arch/arm64/kvm/reset.c | 4 ++++
include/uapi/linux/kvm.h | 1 +
virt/kvm/arm/arm.c | 19 ++++++++++++++++
12 files changed, 157 insertions(+), 6 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH] PCI: Clean up resource allocation in devm_of_pci_get_host_bridge_resources()
From: Bjorn Helgaas @ 2018-06-05 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VdWhCDYt3jvii92g222WeHTvwX5e8Sthr0pknXvCgwHDA@mail.gmail.com>
On Tue, Jun 05, 2018 at 07:26:57PM +0300, Andy Shevchenko wrote:
> On Wed, May 16, 2018 at 3:31 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> > Instead of first allocating and then freeing memory for struct resource
> > in case we cannot parse a PCI resource from the device tree, work
> > against a local struct and kmemdup it when we decide to go with it.
> >
>
> Bjorn, any comments on this?
I'm trying to finish up the v4.18 changes now, but I'll look at this later.
If it's urgent, let me know and I can look sooner.
> > Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> > ---
> > drivers/pci/of.c | 14 ++++++--------
> > 1 file changed, 6 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> > index b06585a1da75..fc0f906c5c25 100644
> > --- a/drivers/pci/of.c
> > +++ b/drivers/pci/of.c
> > @@ -266,7 +266,7 @@ int devm_of_pci_get_host_bridge_resources(struct device *dev,
> > struct list_head *resources, resource_size_t *io_base)
> > {
> > struct device_node *dev_node = dev->of_node;
> > - struct resource *res;
> > + struct resource *res, tmp_res;
> > struct resource *bus_range;
> > struct of_pci_range range;
> > struct of_pci_range_parser parser;
> > @@ -320,18 +320,16 @@ int devm_of_pci_get_host_bridge_resources(struct device *dev,
> > if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
> > continue;
> >
> > - res = devm_kzalloc(dev, sizeof(struct resource), GFP_KERNEL);
> > + err = of_pci_range_to_resource(&range, dev_node, &tmp_res);
> > + if (err)
> > + continue;
> > +
> > + res = devm_kmemdup(dev, &tmp_res, sizeof(tmp_res), GFP_KERNEL);
> > if (!res) {
> > err = -ENOMEM;
> > goto failed;
> > }
> >
> > - err = of_pci_range_to_resource(&range, dev_node, res);
> > - if (err) {
> > - devm_kfree(dev, res);
> > - continue;
> > - }
> > -
> > if (resource_type(res) == IORESOURCE_IO) {
> > if (!io_base) {
> > dev_err(dev,
> > --
> > 2.13.6
>
>
>
> --
> With Best Regards,
> Andy Shevchenko
^ permalink raw reply
* [PATCH v2 12/16] dt-bindings/interrupt-controller: update Marvell ICU bindings
From: Thomas Petazzoni @ 2018-06-05 20:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605202902.GA8875@rob-hp-laptop>
Hello,
On Tue, 5 Jun 2018 14:29:02 -0600, Rob Herring wrote:
> On Tue, May 22, 2018 at 11:40:38AM +0200, Miquel Raynal wrote:
> > Change the documentation to reflect the new bindings used for Marvell
> > ICU. This involves describing each interrupt group as a subnode of the
> > ICU node. Each of them having their own compatible.
>
> Need to explain why you need to do this and why breaking backwards
> compatibility is okay.
It does not break backward compatibility. The driver changes keep
support for the previous DT binding where there was a single node with
no subnodes.
The DT binding documentation still documents the legacy binding,
because it is still supported, and still works.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2 12/16] dt-bindings/interrupt-controller: update Marvell ICU bindings
From: Rob Herring @ 2018-06-05 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180522094042.24770-13-miquel.raynal@bootlin.com>
On Tue, May 22, 2018 at 11:40:38AM +0200, Miquel Raynal wrote:
> Change the documentation to reflect the new bindings used for Marvell
> ICU. This involves describing each interrupt group as a subnode of the
> ICU node. Each of them having their own compatible.
Need to explain why you need to do this and why breaking backwards
compatibility is okay.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> .../bindings/interrupt-controller/marvell,icu.txt | 81 ++++++++++++++++++----
> 1 file changed, 69 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,icu.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,icu.txt
> index 649b7ec9d9b1..6f7e4355b3d8 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/marvell,icu.txt
> +++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,icu.txt
> @@ -5,6 +5,8 @@ The Marvell ICU (Interrupt Consolidation Unit) controller is
> responsible for collecting all wired-interrupt sources in the CP and
> communicating them to the GIC in the AP, the unit translates interrupt
> requests on input wires to MSG memory mapped transactions to the GIC.
> +These messages will access a different GIC memory area depending on
> +their type (NSR, SR, SEI, REI, etc).
>
> Required properties:
>
> @@ -12,20 +14,19 @@ Required properties:
>
> - reg: Should contain ICU registers location and length.
>
> +Subnodes: Each group of interrupt is declared as a subnode of the ICU,
> +with their own compatible.
> +
> +Required properties for the icu_nsr/icu_sei subnodes:
> +
> +- compatible: Should be "marvell,cp110-icu-nsr" or "marvell,cp110-icu-sei".
> +
> - #interrupt-cells: Specifies the number of cells needed to encode an
> - interrupt source. The value shall be 3.
> + interrupt source. The value shall be 2.
>
> - The 1st cell is the group type of the ICU interrupt. Possible group
> - types are:
> + The 1st cell is the index of the interrupt in the ICU unit.
>
> - ICU_GRP_NSR (0x0) : Shared peripheral interrupt, non-secure
> - ICU_GRP_SR (0x1) : Shared peripheral interrupt, secure
> - ICU_GRP_SEI (0x4) : System error interrupt
> - ICU_GRP_REI (0x5) : RAM error interrupt
What happens to SR and REI interrupts?
> -
> - The 2nd cell is the index of the interrupt in the ICU unit.
> -
> - The 3rd cell is the type of the interrupt. See arm,gic.txt for
> + The 2nd cell is the type of the interrupt. See arm,gic.txt for
> details.
>
> - interrupt-controller: Identifies the node as an interrupt
> @@ -35,17 +36,73 @@ Required properties:
> that allows to trigger interrupts using MSG memory mapped
> transactions.
>
> +Note: each 'interrupts' property referring to any 'icu_xxx' node shall
> + have a different number within [0:206].
> +
> Example:
>
> icu: interrupt-controller at 1e0000 {
> compatible = "marvell,cp110-icu";
> reg = <0x1e0000 0x440>;
> +
> + CP110_LABEL(icu_nsr): icu-nsr {
'interrupt-controller' is the proper node name. Is there no register
range associated sub nodes?
> + compatible = "marvell,cp110-icu-nsr";
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + msi-parent = <&gicp>;
> + };
> +
> + CP110_LABEL(icu_sei): icu-sei {
> + compatible = "marvell,cp110-icu-sei";
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + msi-parent = <&sei>;
> + };
Mixture of tabs and spaces.
> +};
> +
> +node1 {
> + interrupt-parent = <&icu_nsr>;
> + interrupts = <106 IRQ_TYPE_LEVEL_HIGH>;
> +};
> +
> +node2 {
> + interrupt-parent = <&icu_sei>;
> + interrupts = <107 IRQ_TYPE_LEVEL_HIGH>;
> +};
> +
> +/* Would not work with the above nodes */
> +node3 {
> + interrupt-parent = <&icu_nsr>;
> + interrupts = <107 IRQ_TYPE_LEVEL_HIGH>;
> +};
> +
> +Note on legacy bindings:
> +Before using a subnode for each domain, only NSR were
> +supported. Bindings were different in this way:
> +
> +- #interrupt-cells: The value was 3.
> + The 1st cell was the group type of the ICU interrupt. Possible
> + group types were:
> + ICU_GRP_NSR (0x0) : Shared peripheral interrupt, non-secure
> + ICU_GRP_SR (0x1) : Shared peripheral interrupt, secure
> + ICU_GRP_SEI (0x4) : System error interrupt
> + ICU_GRP_REI (0x5) : RAM error interrupt
> + The 2nd cell was the index of the interrupt in the ICU unit.
> + The 3rd cell was the type of the interrupt. See arm,gic.txt for
> + details.
> +
> +Example:
> +
> +icu: interrupt-controller at 1e0000 {
> + compatible = "marvell,cp110-icu";
> + reg = <0x1e0000 0x440>;
> +
> #interrupt-cells = <3>;
> interrupt-controller;
> msi-parent = <&gicp>;
> };
>
> -usb3h0: usb3 at 500000 {
> +node1 {
> interrupt-parent = <&icu>;
> interrupts = <ICU_GRP_NSR 106 IRQ_TYPE_LEVEL_HIGH>;
> };
> --
> 2.14.1
>
^ permalink raw reply
* [PATCH v3 2/5] gpio: syscon: rockchip: add GPIO_MUTE support for rk3328
From: Rob Herring @ 2018-06-05 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87zi0d8tue.fsf@t-chip.com.cn>
On Sat, Jun 02, 2018 at 04:40:09PM +0800, Levin Du wrote:
>
> Rob Herring <robh+dt@kernel.org> writes:
>
> > On Thu, May 31, 2018 at 9:05 PM, Levin <djw@t-chip.com.cn> wrote:
> > > Hi Rob,
> > >
> > >
> > > On 2018-05-31 10:45 PM, Rob Herring wrote:
> > > >
> > > > On Wed, May 30, 2018 at 10:27 PM, <djw@t-chip.com.cn> wrote:
> > > > >
> > > > > From: Levin Du <djw@t-chip.com.cn>
> > > > >
> > > > > In Rockchip RK3328, the output only GPIO_MUTE pin,
> > > > > originally for codec
> > > > > mute control, can also be used for general purpose. It is
> > > > > manipulated by
> > > > > the GRF_SOC_CON10 register.
> > > > >
> > > > > Signed-off-by: Levin Du <djw@t-chip.com.cn>
> > > > >
> > > > > ---
> > > > >
> > > > > Changes in v3:
> > > > > - Change from general gpio-syscon to specific
> > > > > rk3328-gpio-mute
> > > > >
> > > > > Changes in v2:
> > > > > - Rename gpio_syscon10 to gpio_mute in doc
> > > > >
> > > > > Changes in v1:
> > > > > - Refactured for general gpio-syscon usage for Rockchip SoCs.
> > > > > - Add doc rockchip,gpio-syscon.txt
> > > > >
> > > > > .../bindings/gpio/rockchip,rk3328-gpio-mute.txt | 28
> > > > > +++++++++++++++++++
> > > > > drivers/gpio/gpio-syscon.c | 31
> > > > > ++++++++++++++++++++++
> > > > > 2 files changed, 59 insertions(+)
> > > > > create mode 100644
> > > > > Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
> > > > >
> > > > > diff --git
> > > > > a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
> > > > > b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
> > > > > new file mode 100644
> > > > > index 0000000..10bc632
> > > > > --- /dev/null
> > > > > +++
> > > > > b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
> > > > > @@ -0,0 +1,28 @@
> > > > > +Rockchip RK3328 GPIO controller dedicated for the GPIO_MUTE
> > > > > pin.
> > > > > +
> > > > > +In Rockchip RK3328, the output only GPIO_MUTE pin,
> > > > > originally for codec
> > > > > mute
> > > > > +control, can also be used for general purpose. It is
> > > > > manipulated by the
> > > > > +GRF_SOC_CON10 register.
> > > > > +
> > > > > +Required properties:
> > > > > +- compatible: Should contain "rockchip,rk3328-gpio-mute".
> > > > > +- gpio-controller: Marks the device node as a gpio
> > > > > controller.
> > > > > +- #gpio-cells: Should be 2. The first cell is the pin
> > > > > number and
> > > > > + the second cell is used to specify the gpio polarity:
> > > > > + 0 = Active high,
> > > > > + 1 = Active low.
> > > > > +
> > > > > +Example:
> > > > > +
> > > > > + grf: syscon at ff100000 {
> > > > > + compatible = "rockchip,rk3328-grf", "syscon",
> > > > > "simple-mfd";
> > > > > +
> > > > > + gpio_mute: gpio-mute {
> > > >
> > > > Node names should be generic:
> > > >
> > > > gpio {
> > > >
> > > > This also means you can't add another GPIO node in the future
> > > > and
> > > > you'll have to live with "rockchip,rk3328-gpio-mute" covering
> > > > more
> > > > than 1 GPIO if you do need to add more GPIOs.
> > >
> > >
> > > As the first line describes, this GPIO controller is dedicated for
> > > the
> > > GPIO_MUTE pin.
> > > There's only one GPIO pin in the GRF_SOC_CON10 register. Therefore
> > > the
> > > gpio_mute
> > > name is proper IMHO.
> >
> > It's how many GPIOs in the GRF, not this register. What I'm saying is
> > when you come along later to add another GPIO in the GRF, you had
> > better just add it to this same node. I'm not going to accept another
> > GPIO controller node within the GRF. You have the cells to support
> > more than 1, so it would only be a driver change. The compatible
> > string would then not be ideally named at that point. But compatible
> > strings are just unique identifiers, so it doesn't really matter what
> > the string is.
> >
>
> I'll try my best to introduce the situation here. The GRF, GPIO0~GPIO3
> are register blocks in the RK3328 Soc. The GPIO0~GPIO3 contain registers
> for GPIO operations like reading/writing data, setting direction,
> interruption etc, which corresponds to the GPIO banks (gpio0~gpio3)
> defined in rk3328.dtsi:
I'm only talking about GRF functions, not "regular" GPIOs.
> pinctrl: pinctrl {
> compatible = "rockchip,rk3328-pinctrl";
> rockchip,grf = <&grf>;
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
>
> gpio0: gpio0 at ff210000 {
> compatible = "rockchip,gpio-bank";
> reg = <0x0 0xff210000 0x0 0x100>;
> interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&cru PCLK_GPIO0>;
>
> gpio-controller;
> #gpio-cells = <2>;
>
> interrupt-controller;
> #interrupt-cells = <2>;
> };
>
> gpio1: gpio1 at ff220000 {
> //...
> };
>
> gpio2: gpio2 at ff230000 {
> //...
> };
>
> gpio3: gpio3 at ff240000 {
> //...
> };
> }
>
> However, these general GPIO pins has multiplexed functions and their
> pull up/down and driving strength can also be configured. These settings
> are manipulated by the GRF registers in pinctrl driver. Quoted from the
> TRM, the GRF has the following function:
>
> - IOMUX control
> - Control the state of GPIO in power-down mode
> - GPIO PAD pull down and pull up control
> - Used for common system control
> - Used to record the system state
>
> Therefore the functions of the GRF are messy and scattered in different
> nodes. The so-called GPIO_MUTE does not belong to GPIO0~GPIO3. It is
> manipulated by the GRF_SOC_CON10 register in the GRF block.
>
> > I'm being told both "this is the only GPIO" and "the GRF has too many
> > different functions for us to tell you what they all are". So which is
> > it?
> >
> > Rob
>
> They are both true, but lack of context. See the above description.
What I meant was "only GPIO in GRF registers"...
Rob
^ permalink raw reply
* [PATCH v4 2/6] Documentation: DT: Add optional 'timeout-sec' property for sp805
From: Rob Herring @ 2018-06-05 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527530497-10392-3-git-send-email-ray.jui@broadcom.com>
On Mon, May 28, 2018 at 11:01:33AM -0700, Ray Jui wrote:
> Update the SP805 binding document to add optional 'timeout-sec'
> devicetree property
Note "dt-bindings: watchdog: ..." is the preferred subject prefix.
>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> ---
> Documentation/devicetree/bindings/watchdog/arm,sp805.txt | 2 ++
> 1 file changed, 2 insertions(+)
Otherwise,
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [GIT PULL] SoCFPGA DTS updates for v4.18, part 2
From: Dinh Nguyen @ 2018-06-05 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514135144.26872-1-dinguyen@kernel.org>
Hi Arnd, Kevin and Olof:
Perhaps this pull request got buried in your inbox somewhere? Can you
still pull these in for v4.18?
Thanks,
Dinh
On 05/14/2018 08:51 AM, Dinh Nguyen wrote:
> Hi Arnd, Kevin, and Olof:
>
> Please pull in more updates for SoCFPGA Stratix10 DTS for v4.18.
>
> Thanks,
> Dinh
>
> The following changes since commit ab50a44404a53b12554005ed4c5a1b3547ac9492:
>
> arm64: dts: stratix10: Add PL330 DMAC to Stratix10 dts (2018-04-16 15:58:58 -0500)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git socfpga_for_next_v4.18_dts_v2
>
> for you to fetch changes up to 91fdd8274f32987760bbdb2981b4a896e338c09e:
>
> arm64: dts: stratix10: add sdram ecc (2018-05-08 08:11:29 -0500)
>
> ----------------------------------------------------------------
> Bartosz Golaszewski (1):
> ARM: dts: consistently use 'atmel' as at24 manufacturer in cyclone5
>
> Ooi, Joyce (1):
> arm64: dts: stratix10: Change pad skew values for EMAC0 PHY driver
>
> Thor Thayer (1):
> arm64: dts: stratix10: add sdram ecc
>
> arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts | 6 +++---
> arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 12 ++++++++++++
> arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts | 2 +-
> 3 files changed, 16 insertions(+), 4 deletions(-)
>
^ permalink raw reply
* [GIT PULL] SoCFPGA DTS updates for v4.18
From: Dinh Nguyen @ 2018-06-05 19:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1524494393-8052-1-git-send-email-dinguyen@kernel.org>
Hi Olof, Kevin, and Arnd:
Perhaps this pull request got buried in your inbox somewhere?
There are a few patches that touches the socfpga_stratix10.dtsi that are
in the EDAC branch that is dependent on these patches, so Boris is
taking these patches through his edac changes for v4.18.
Dinh
On 04/23/2018 09:39 AM, Dinh Nguyen wrote:
> Hi Arnd, Kevin, and Olof:
>
> Please full in these SoCFPGA Stratix10 DTS updates for v4.18.
>
> Thanks,
> Dinh
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_updates_for_v4.18_part1
>
> for you to fetch changes up to ab50a44404a53b12554005ed4c5a1b3547ac9492:
>
> arm64: dts: stratix10: Add PL330 DMAC to Stratix10 dts (2018-04-16 15:58:58 -0500)
>
> ----------------------------------------------------------------
> SoCFPGA DTS updates for v4.18
> - Stratix10 platform updates
> - Populate clock properties for platform
> - Enable DMA and I2C
>
> ----------------------------------------------------------------
> Alan Tull (1):
> arm64: dts: stratix10: enable i2c, add i2c periperals
>
> Dinh Nguyen (1):
> arm64: dts: stratix10: use clock bindings for the Stratix10 platform
>
> Graham Moore (1):
> arm64: dts: stratix10: Add PL330 DMAC to Stratix10 dts
>
> arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 71 +++++++++++++++++++++-
> .../boot/dts/altera/socfpga_stratix10_socdk.dts | 42 +++++++++++++
> 2 files changed, 111 insertions(+), 2 deletions(-)
>
^ permalink raw reply
* [PATCH v4 1/6] Documentation: DT: Consolidate SP805 binding docs
From: Rob Herring @ 2018-06-05 19:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527530497-10392-2-git-send-email-ray.jui@broadcom.com>
On Mon, May 28, 2018 at 11:01:32AM -0700, Ray Jui wrote:
> Consolidate two SP805 binding documents "arm,sp805.txt" and
> "sp805-wdt.txt" into "arm,sp805.txt" that matches the naming of the
> desired compatible string to be used
>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> ---
> .../devicetree/bindings/watchdog/arm,sp805.txt | 27 ++++++++++++++-----
> .../devicetree/bindings/watchdog/sp805-wdt.txt | 31 ----------------------
> 2 files changed, 20 insertions(+), 38 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
Would be good to get a ACK from FSL/NXP person on this. It looks to me
like the driver fetches the wrong clock as it gets the first one and the
driver really wants 'wdog_clk'. In any case, their dts files should be
updated.
Reviewed-by: Rob Herring <robh@kernel.org>
Rob
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gxl-s905x-p212: Add phy-supply for usb0
From: Martin Blumenstingl @ 2018-06-05 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528188743-12798-1-git-send-email-narmstrong@baylibre.com>
On Tue, Jun 5, 2018 at 10:52 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> Like LibreTech-CC, the USB0 needs the 5V regulator to be enabled to power the
> devices on the P212 Reference Design based boards.
>
> Fixes: b9f07cb4f41f ("ARM64: dts: meson-gxl-s905x-p212: enable the USB controller")
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
out of curiosity: I guess you tested this using u-boot?
if anyone else is interested: the only other way to test this is by
ensuring that the hdmi_5v regulator is turned off by Linux (by
removing it from the HDMI nodes) and then plugging in a USB device ->
if it doesn't get VBUS then the hdmi_5v regulator is the cause (and
needs to be kept/turned on by the USB code, just like Neil's patch
does)
> ---
> arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
> index 0cfd701..a1b3101 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
> @@ -189,3 +189,10 @@
> &usb0 {
> status = "okay";
> };
> +
> +&usb2_phy0 {
> + /*
> + * HDMI_5V is also used as supply for the USB VBUS.
> + */
> + phy-supply = <&hdmi_5v>;
> +};
> --
> 2.7.4
>
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply
* [PATCH] arm64: topology: Avoid checking numa mask for scheduler MC selection
From: Jeremy Linton @ 2018-06-05 19:08 UTC (permalink / raw)
To: linux-arm-kernel
The numa mask subset check has problems if !CONFIG_NUMA, over hotplug
operations or during early boot. Lets disable the NUMA siblings checks
for the time being, as NUMA in socket machines have LLC's that will
assure that the scheduler topology isn't "borken".
Futher, as a defensive mechanism during hotplug, lets assure that the
LLC siblings are also masked.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
arch/arm64/kernel/topology.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 7415c166281f..f845a8617812 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -215,13 +215,8 @@ EXPORT_SYMBOL_GPL(cpu_topology);
const struct cpumask *cpu_coregroup_mask(int cpu)
{
- const cpumask_t *core_mask = cpumask_of_node(cpu_to_node(cpu));
+ const cpumask_t *core_mask = &cpu_topology[cpu].core_sibling;
- /* Find the smaller of NUMA, core or LLC siblings */
- if (cpumask_subset(&cpu_topology[cpu].core_sibling, core_mask)) {
- /* not numa in package, lets use the package siblings */
- core_mask = &cpu_topology[cpu].core_sibling;
- }
if (cpu_topology[cpu].llc_id != -1) {
if (cpumask_subset(&cpu_topology[cpu].llc_siblings, core_mask))
core_mask = &cpu_topology[cpu].llc_siblings;
@@ -239,8 +234,10 @@ static void update_siblings_masks(unsigned int cpuid)
for_each_possible_cpu(cpu) {
cpu_topo = &cpu_topology[cpu];
- if (cpuid_topo->llc_id == cpu_topo->llc_id)
+ if (cpuid_topo->llc_id == cpu_topo->llc_id) {
cpumask_set_cpu(cpu, &cpuid_topo->llc_siblings);
+ cpumask_set_cpu(cpuid, &cpu_topo->llc_siblings);
+ }
if (cpuid_topo->package_id != cpu_topo->package_id)
continue;
--
2.14.3
^ permalink raw reply related
* [PATCH V3] ARM: dts: armada388-helios4
From: Dennis Gilmore @ 2018-06-05 18:48 UTC (permalink / raw)
To: linux-arm-kernel
The helios4 is a Armada388 based nas board designed by SolidRun and
based on their SOM. It is sold by kobol.io the dts file came from
https://raw.githubusercontent.com/armbian/build/master/patch/kernel/mvebu-default/95-helios4-device-tree.patch
I added a SPDX license line to match the clearfog it says it was based
on and a compatible line for "kobol,helios4"
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
changes since first submission
change solidrun to kobol in compatible line based on feedback
changes since v2
remove commented out nodes based on feedback
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-388-helios4.dts | 313 +++++++++++++++++++++++
2 files changed, 314 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-388-helios4.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e2424957809..490bfd586198 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1123,6 +1123,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-388-clearfog-pro.dtb \
armada-388-db.dtb \
armada-388-gp.dtb \
+ armada-388-helios4.dtb \
armada-388-rd.dtb
dtb-$(CONFIG_MACH_ARMADA_39X) += \
armada-398-db.dtb
diff --git a/arch/arm/boot/dts/armada-388-helios4.dts b/arch/arm/boot/dts/armada-388-helios4.dts
new file mode 100644
index 000000000000..59048740ae06
--- /dev/null
+++ b/arch/arm/boot/dts/armada-388-helios4.dts
@@ -0,0 +1,313 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Device Tree file for Helios4
+ * based on SolidRun Clearfog revision A1 rev 2.0 (88F6828)
+ *
+ * Copyright (C) 2017
+ *
+ */
+
+/dts-v1/;
+#include "armada-388.dtsi"
+#include "armada-38x-solidrun-microsom.dtsi"
+
+/ {
+ model = "Helios4";
+ compatible = "kobol,helios4", "marvell,armada388",
+ "marvell,armada385", "marvell,armada380";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x80000000>; /* 2 GB */
+ };
+
+ aliases {
+ /* So that mvebu u-boot can update the MAC addresses */
+ ethernet1 = ð0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ reg_12v: regulator-12v {
+ compatible = "regulator-fixed";
+ regulator-name = "power_brick_12V";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ vin-supply = <®_12v>;
+ };
+
+ reg_5p0v_hdd: regulator-5v-hdd {
+ compatible = "regulator-fixed";
+ regulator-name = "5V_HDD";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ vin-supply = <®_12v>;
+ };
+
+ reg_5p0v_usb: regulator-5v-usb {
+ compatible = "regulator-fixed";
+ regulator-name = "USB-PWR";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ enable-active-high;
+ gpio = <&expander0 6 GPIO_ACTIVE_HIGH>;
+ vin-supply = <®_12v>;
+ };
+
+ system-leds {
+ compatible = "gpio-leds";
+ status-led {
+ label = "helios4:green:status";
+ gpios = <&gpio0 24 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+
+ fault-led {
+ label = "helios4:red:fault";
+ gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;
+ default-state = "keep";
+ };
+ };
+
+ io-leds {
+ compatible = "gpio-leds";
+ sata1-led {
+ label = "helios4:green:ata1";
+ gpios = <&gpio1 17 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata1";
+ default-state = "off";
+ };
+ sata2-led {
+ label = "helios4:green:ata2";
+ gpios = <&gpio1 18 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata2";
+ default-state = "off";
+ };
+ sata3-led {
+ label = "helios4:green:ata3";
+ gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata3";
+ default-state = "off";
+ };
+ sata4-led {
+ label = "helios4:green:ata4";
+ gpios = <&gpio1 21 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata4";
+ default-state = "off";
+ };
+ usb-led {
+ label = "helios4:green:usb";
+ gpios = <&gpio1 22 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "usb-host";
+ default-state = "off";
+ };
+ };
+
+ fan1: j10-pwm {
+ compatible = "pwm-fan";
+ pwms = <&gpio1 9 40000>; /* Target freq:25 kHz */
+ };
+
+ fan2: j17-pwm {
+ compatible = "pwm-fan";
+ pwms = <&gpio1 23 40000>; /* Target freq:25 kHz */
+ };
+
+ usb2_phy: usb2-phy {
+ compatible = "usb-nop-xceiv";
+ vbus-regulator = <®_5p0v_usb>;
+ };
+
+ usb3_phy: usb3-phy {
+ compatible = "usb-nop-xceiv";
+ };
+
+ soc {
+ internal-regs {
+ i2c at 11000 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ /*
+ * PCA9655 GPIO expander, up to 1MHz clock.
+ * 0-Board Revision bit 0 #
+ * 1-Board Revision bit 1 #
+ * 5-USB3 overcurrent
+ * 6-USB3 power
+ */
+ expander0: gpio-expander at 20 {
+ /*
+ * This is how it should be:
+ * compatible = "onnn,pca9655",
+ * "nxp,pca9555";
+ * but you can't do this because of
+ * the way I2C works.
+ */
+ compatible = "nxp,pca9555";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x20>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pca0_pins>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <23 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ board_rev_bit_0 {
+ gpio-hog;
+ gpios = <0 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "board-rev-0";
+ };
+ board_rev_bit_1 {
+ gpio-hog;
+ gpios = <1 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "board-rev-1";
+ };
+ usb3_ilimit {
+ gpio-hog;
+ gpios = <5 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "usb-overcurrent-status";
+ };
+ };
+
+ temp_sensor: temp at 4c {
+ compatible = "ti,lm75";
+ reg = <0x4c>;
+ vcc-supply = <®_3p3v>;
+ };
+ };
+
+ i2c at 11100 {
+ /*
+ * External I2C Bus for user peripheral
+ */
+ clock-frequency = <400000>;
+ pinctrl-0 = <&helios_i2c1_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ sata at a8000 {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sata0: sata-port at 0 {
+ reg = <0>;
+ };
+
+ sata1: sata-port at 1 {
+ reg = <1>;
+ };
+ };
+
+ sata at e0000 {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sata2: sata-port at 0 {
+ reg = <0>;
+ };
+
+ sata3: sata-port at 1 {
+ reg = <1>;
+ };
+ };
+
+ spi at 10680 {
+ pinctrl-0 = <&spi1_pins
+ µsom_spi1_cs_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ sdhci at d8000 {
+ bus-width = <4>;
+ cd-gpios = <&gpio0 20 GPIO_ACTIVE_LOW>;
+ no-1-8-v;
+ pinctrl-0 = <&helios_sdhci_pins
+ &helios_sdhci_cd_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ vmmc = <®_3p3v>;
+ wp-inverted;
+ };
+
+ usb at 58000 {
+ usb-phy = <&usb2_phy>;
+ status = "okay";
+ };
+
+ usb3 at f0000 {
+ status = "okay";
+ };
+
+ usb3 at f8000 {
+ status = "okay";
+ };
+
+ pinctrl at 18000 {
+ pca0_pins: pca0-pins {
+ marvell,pins = "mpp23";
+ marvell,function = "gpio";
+ };
+ microsom_phy0_int_pins: microsom-phy0-int-pins {
+ marvell,pins = "mpp18";
+ marvell,function = "gpio";
+ };
+ helios_i2c1_pins: i2c1-pins {
+ marvell,pins = "mpp26", "mpp27";
+ marvell,function = "i2c1";
+ };
+ helios_sdhci_cd_pins: helios-sdhci-cd-pins {
+ marvell,pins = "mpp20";
+ marvell,function = "gpio";
+ };
+ helios_sdhci_pins: helios-sdhci-pins {
+ marvell,pins = "mpp21", "mpp28",
+ "mpp37", "mpp38",
+ "mpp39", "mpp40";
+ marvell,function = "sd0";
+ };
+ helios_led_pins: helios-led-pins {
+ marvell,pins = "mpp24", "mpp25",
+ "mpp49", "mpp50",
+ "mpp52", "mpp53",
+ "mpp54";
+ marvell,function = "gpio";
+ };
+ helios_fan_pins: helios-fan-pins {
+ marvell,pins = "mpp41", "mpp43",
+ "mpp48", "mpp55";
+ marvell,function = "gpio";
+ };
+ microsom_spi1_cs_pins: spi1-cs-pins {
+ marvell,pins = "mpp59";
+ marvell,function = "spi1";
+ };
+ };
+ };
+ };
+};
--
2.17.1
^ permalink raw reply related
* [alsa-devel] [PATCH 0/3] ASoC: stm32: sai: add support of iec958 controls
From: Takashi Iwai @ 2018-06-05 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2ae6c5b6-872a-9aaa-6ca4-e29adb7c8bc0@st.com>
On Tue, 05 Jun 2018 17:50:57 +0200,
Arnaud Pouliquen wrote:
>
> Hi Takashi,
>
> On 04/17/2018 01:17 PM, Mark Brown wrote:
> > On Tue, Apr 17, 2018 at 08:29:17AM +0000, Olivier MOYSAN wrote:
> >
> >> I guess the blocking patch in this patchset is the patch "add IEC958
> >> channel status control helper". This patch has been reviewed several
> >> times, but did not get a ack so far.
> >> If you think these helpers will not be merged, I will reintegrate the
> >> corresponding code in stm driver.
> >> Please let me know, if I need to prepare a v2 without helpers, or if we
> >> can go further in the review of iec helpers patch ?
> >
> > I don't mind either way but you're right here, I'm waiting for Takashi
> > to review the first patch.? I'd probably be OK with it just integrated
> > into the driver if we have to go that way though.
>
> Gentlemen reminder for this patch set. We would appreciate to have your
> feedback on iec helper.
> From our point of view it could be useful to have a generic management
> of the iec controls based on helpers instead of redefining them in DAIs.
> Having the same behavior for these controls could be useful to ensure
> coherence of the control management used by application (for instance
> Gstreamer uses it to determine iec raw mode capability for iec61937 streams)
Oh sorry for the late reply, I've totally overlooked the thread.
And, another sorry: the patchset doesn't look convincing enough to
me.
First off, the provided API definition appears somewhat
unconventional, the mixture of the ops, the static data and the
dynamic data.
Moreover, this is only for your driver, ATM. If it were an API that
does clean up the already existing usages, I'd happily apply it. There
are lots of drivers creating and controlling the IEC958 ctls even
now.
Also, the patchset requires more fine-tuning, in anyways. The changes
in create_iec958_consumre() are basically irrelevant, should be split
off as an individual fix. Also, the new function doesn't create the
"XXX Mask" controls. And the byte comparison should be replaced with
memcmp(), etc, etc.
So, please proceed rather with the open codes for now. If you can
provide a patch that cleans up the *multiple* driver codes, again,
I'll happily take it. But it can be done anytime later, too.
thanks,
Takashi
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v2] arm: sun4i: Add support for Pengpod 1000 tablet
From: Bob Ham @ 2018-06-05 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605145038.qptdlcphdbnw6jyg@flea>
On 05/06/18 15:50, Maxime Ripard wrote:
> On Mon, Jun 04, 2018 at 06:33:02PM +0100, Bob Ham wrote:
>> On 04/06/18 09:13, Maxime Ripard wrote:
>>> On Sat, Jun 02, 2018 at 05:03:13PM +0100, Bob Ham wrote:
>>
>>>> + * This file is dual-licensed: you can use it either under the terms
>>>> + * of the GPL or the X11 license, at your option. Note that this dual
>>>> + * licensing only applies to this file, and not this project as a
>>>> + * whole.
>>
>>>> + * The above copyright notice and this permission notice shall be
>>>> + * included in all copies or substantial portions of the Software.
>>
>>> And this is redundant with the SPDX header.
>>
>> The X11 license notice states explicitly that the notice has to be
>> included in the file. Wouldn't removing it be a violation of the license?
>
> The SPDX header is explicitly here to remove the license text and
> create a tag that is in a indirect reference to the license text in
> LICENSES. It's not going away.
Well, the top bit that I quoted above says that the licenses refer to
only that one file in particular and not the project as a whole. Then
the X11 license states that the notice can't be removed from 'this
software and associated documentation files (the "Software")' which
would seem to refer to the single file. Therefore, removing the notice
from the single file and replacing it with an SPDX header would seem to
violate the license.
It's a fine point but it makes me nervous. I originally based my .dts
on sun4i-a10-inet1.dts. I've CC'd the original copyright holder, Hans
de Goede. Hans, are you willing to give permission for the license
notice to be replaced with just an SPDX header indicating the dual
licensing?
While we're at it, there are a number of other files with the same
license text. Hans, are you prepared to give permission for your other
license notices to be replaced with SPDX headers?
Thanks,
Bob
--
Bob Ham <rah@settrans.net>
for (;;) { ++pancakes; }
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 2913 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180605/c91f541e/attachment.sig>
^ permalink raw reply
* panic kexec broken on ARM64?
From: James Morse @ 2018-06-05 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605100151.7fd54381@ezekiel.suse.cz>
Hi Petr,
(CC: +Akashi, Marc)
On 05/06/18 09:01, Petr Tesarik wrote:
> I have observed hangs after crash on a Raspberry Pi 3 Model B+ board
> when a panic kernel is loaded.
kdump is a best-effort thing, it looks like this is a case where the
crashed-kernel can't tear itself down.
Do you have the rest of the stack trace? Was it handling an irq when it decided
to panic?:
https://lkml.org/lkml/2018/3/13/1134
> I attached a hardware debugger and found
> out that all CPU cores were stopped except one which was stuck in the
> idle thread. It seems that irq_set_irqchip_state() may sleep, which is
> definitely not safe after a kernel panic.
I don't know much about irqchip stuff, but __irq_get_desc_lock() takes a
raw_spin_lock(), and calls gic_irq_get_irqchip_state() which is just poking
around in mmio registers, this should all be safe unless you re-entered the same
code.
> If I'm right, then this is broken in general, but I have only ever seen
> it on RPi 3 Model B+ (even RPi3 Model B works fine), so the issue may
> be more subtle.
Is there a hardware difference around the interrupt controller on these?
> FWIW the code for 32-bit ARM seems to work just fine
> without this code in machine_kexec_mask_interrupts():
>
> /*
> * First try to remove the active state. If this
> * fails, try to EOI the interrupt.
> */
> ret = irq_set_irqchip_state(i, IRQCHIP_STATE_ACTIVE, false);
>
> I wonder what breaks if this call to irq_set_irqchip_state() is removed.
My understanding is this is to reset all interrupts so the new kernel doesn't
spend its first waking minutes declaring all these pending interrupts as
spurious as the device drivers haven't (re-)claimed them yet.
I don't know if/how this is done on 32bit.
> For reference, here is a stack trace of the process which originally
> triggered the panic:
>
> #0 __switch_to (prev=0xffff000008e62a00 <init_task>, next=0xffff80002b796080) at ../arch/arm64/kernel/process.c:355
> #1 0xffff0000088f584c in context_switch (rf=<optimized out>, next=<optimized out>, prev=<optimized out>, rq=<optimized out>) at ../kernel/sched/core.c:2896
> #2 __schedule (preempt=false) at ../kernel/sched/core.c:3457
> #3 0xffff0000088f5eac in schedule () at ../kernel/sched/core.c:3516
> #4 0xffff0000088f9448 in schedule_timeout (timeout=<optimized out>) at ../kernel/time/timer.c:1743
> #5 0xffff0000088f6afc in do_wait_for_common (state=<optimized out>, timeout=500, action=<optimized out>, x=<optimized out>) at ../kernel/sched/completion.c:77
> #6 __wait_for_common (state=<optimized out>, timeout=<optimized out>, action=<optimized out>, x=<optimized out>) at ../kernel/sched/completion.c:96
> #7 wait_for_common (x=0xffff000008e53848 <init_thread_union+14408>, timeout=500, state=<optimized out>) at ../kernel/sched/completion.c:104
> #8 0xffff0000088f6c1c in wait_for_completion_timeout (x=0xffff000008e53848 <init_thread_union+14408>, timeout=500) at ../kernel/sched/completion.c:144
> #9 0xffff000000a19f1c in usb_start_wait_urb (urb=0xffff80002c1cd700, timeout=5000, actual_length=0xffff000008e538dc <init_thread_union+14556>)
> at ../drivers/usb/core/message.c:61
(USB?!)
> #10 0xffff000000a1a05c in usb_internal_control_msg (timeout=<optimized out>, len=<optimized out>, data=<optimized out>, cmd=<optimized out>, pipe=<optimized out>,
> usb_dev=<optimized out>) at ../drivers/usb/core/message.c:100
> #11 usb_control_msg (dev=0xffff80002c348000, pipe=2147484800, request=161 '\241', requesttype=192 '\300', value=0, index=152, data=0xffff80002b6fa080, size=4,
> timeout=5000) at ../drivers/usb/core/message.c:151
> #12 0xffff000001001cd0 in lan78xx_read_reg (index=152, data=0xffff000008e5396c <init_thread_union+14700>, dev=<optimized out>, dev=<optimized out>)
> at ../drivers/net/usb/lan78xx.c:425
> #13 0xffff00000100365c in lan78xx_irq_bus_sync_unlock (irqd=<optimized out>) at ../drivers/net/usb/lan78xx.c:1909
I'm not sure what these 'struct irq_chip' outside drivers/irqchip are,
presumably irq-controllers can be nested, and devices believe they are interrupt
controllers too.
This looks like yours is actually a network chip on the other end of a usb bus.
Any configuration attempt involves taking mutexs, allocating memory and sitting
on a wait queue until the response comes, (all relying on a different kind of
interrupt).
So for this network-irqcontroller-chip its not safe to call
irq_set_irqchip_state() from irq context. (you also survived taking a mutex and
allocating a few buffers before hitting the wait queue).
I'm not sure how this should be fixed, but as suggested on that irqchip thread
above, having a irqchip-specific separate 'reset' API could do something more
drastic than trying to modify the configuration, which requires these
locks/memory-allocation.
> #14 0xffff00000813e590 in chip_bus_sync_unlock (desc=<optimized out>) at ../kernel/irq/internals.h:129
> #15 __irq_put_desc_unlock (desc=0xffff80002c361c00, flags=128, bus=true) at ../kernel/irq/irqdesc.c:804
> #16 0xffff00000813f604 in irq_put_desc_busunlock (flags=<optimized out>, desc=<optimized out>) at ../kernel/irq/internals.h:155
> #17 irq_set_irqchip_state (irq=<optimized out>, which=<optimized out>, val=false) at ../kernel/irq/manage.c:2136
> #18 0xffff00000809b7d4 in machine_kexec_mask_interrupts () at ../arch/arm64/kernel/machine_kexec.c:233
> #19 machine_crash_shutdown (regs=<optimized out>) at ../arch/arm64/kernel/machine_kexec.c:259
> #20 0xffff000008180fd4 in __crash_kexec (regs=0xffff000008e53d70 <init_thread_union+15728>) at ../kernel/kexec_core.c:943
> #21 0xffff0000081810e4 in crash_kexec (regs=0xffff000008e53d70 <init_thread_union+15728>) at ../kernel/kexec_core.c:965
> #22 0xffff00000808ab58 in die (str=<optimized out>, regs=0xffff000008e53d70 <init_thread_union+15728>, err=-2046820348) at ../arch/arm64/kernel/traps.c:266
> #23 0xffff0000080a1c14 in __do_kernel_fault (mm=0x0, addr=0, esr=2248146948, regs=0xffff000008e53d70 <init_thread_union+15728>) at ../arch/arm64/mm/fault.c:226
> #24 0xffff0000088fc8dc in do_page_fault (addr=0, esr=2248146948, regs=0xffff000008e53d70 <init_thread_union+15728>) at ../arch/arm64/mm/fault.c:476
> #25 0xffff0000088fccdc in do_translation_fault (addr=0, esr=2248146948, regs=0xffff000008e53d70 <init_thread_union+15728>) at ../arch/arm64/mm/fault.c:502
> #26 0xffff000008081478 in do_mem_abort (addr=0, esr=2248146948, regs=0xffff000008e53d70 <init_thread_union+15728>) at ../arch/arm64/mm/fault.c:657
> #27 0xffff000008082dd0 in el1_sync () at ../arch/arm64/kernel/entry.S:548
What was going on just before this NULL deference? This looks like CPU0's idle
thread stack, which rules out another irq.
Thanks,
James
^ permalink raw reply
* How to print stack uses of IRQ in ARM64
From: James Morse @ 2018-06-05 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VcTvMKy8h_2gztav2FOUvE1QG01FByTNmc=x0bdyRx5Dg@mail.gmail.com>
Hi Vishun,
(CC: +linux-arm-kernel list)
On 05/06/18 14:12, Andy Shevchenko wrote:
> On Thu, May 31, 2018 at 1:01 PM, Vishnu Motghare
> <vishnumotghare@gmail.com> wrote:
>> My understanding is each CPU getting its own IRQ stack. So is it
>> possible to print the stack uses of each IRQ handler?
The stacks are per-cpu not per-handler, so you would get a jumble of different
interrupt-handlers, mixed up with softirq that runs on the same stack.
>> like, How much stack is used & how much left free ?
What would you do with the information?
>> like in process context we have API like stack_not_used(struct
>> task_struct *p) to get the unused stack of processes.
Isn't this only printed when the process exits?
When would you print it for an irqstack?
To get this information you would need to mask interrupts, then search backwards
on the irq-stack to find the 'last' value. I think it would always be more
useful to take interrupts in that time...
>> So, is it possible to get the similar result for IRQ?
Probably, but I don't think its useful.
If you're debugging a stack-overflow, its much better to use vmap stacks, which
will give you the function and stack trace that triggered the overflow.
Thanks,
James
^ permalink raw reply
* [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Frank Rowand @ 2018-06-05 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528198148-23308-3-git-send-email-michel.pollet@bp.renesas.com>
On 06/05/18 04:28, Michel Pollet wrote:
> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time, it
> requires a special enable method to get it started.
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
> ---
> arch/arm/mach-shmobile/Makefile | 1 +
> arch/arm/mach-shmobile/smp-r9a06g032.c | 79 ++++++++++++++++++++++++++++++++++
> 2 files changed, 80 insertions(+)
> create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
>
> diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
> index 1939f52..d7fc98f 100644
> --- a/arch/arm/mach-shmobile/Makefile
> +++ b/arch/arm/mach-shmobile/Makefile
> @@ -34,6 +34,7 @@ smp-$(CONFIG_ARCH_SH73A0) += smp-sh73a0.o headsmp-scu.o platsmp-scu.o
> smp-$(CONFIG_ARCH_R8A7779) += smp-r8a7779.o headsmp-scu.o platsmp-scu.o
> smp-$(CONFIG_ARCH_R8A7790) += smp-r8a7790.o
> smp-$(CONFIG_ARCH_R8A7791) += smp-r8a7791.o
> +smp-$(CONFIG_ARCH_R9A06G032) += smp-r9a06g032.o
> smp-$(CONFIG_ARCH_EMEV2) += smp-emev2.o headsmp-scu.o platsmp-scu.o
>
> # PM objects
> diff --git a/arch/arm/mach-shmobile/smp-r9a06g032.c b/arch/arm/mach-shmobile/smp-r9a06g032.c
> new file mode 100644
> index 0000000..cd40e6e
> --- /dev/null
> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
> @@ -0,0 +1,79 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * R9A06G032 Second CA7 enabler.
> + *
> + * Copyright (C) 2018 Renesas Electronics Europe Limited
> + *
> + * Michel Pollet <michel.pollet@bp.renesas.com>, <buserror@gmail.com>
> + * Derived from action,s500-smp
> + */
> +
> +#include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/smp.h>
> +
> +/*
> + * The second CPU is parked in ROM at boot time. It requires waking it after
> + * writing an address into the BOOTADDR register of sysctrl.
> + *
> + * So the default value of the "cpu-release-addr" corresponds to BOOTADDR...
> + *
> + * *However* the BOOTADDR register is not available when the kernel
> + * starts in NONSEC mode.
> + *
> + * So for NONSEC mode, the bootloader re-parks the second CPU into a pen
> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a SRAM address,
> + * which is not restricted.
The binding document for cpu-release-addr does not have a definition for 32 bit
arm. The existing definition is only 64 bit arm. Please add the definition
for 32 bit arm to patch 1.
-Frank
> + */
> +
> +static void __iomem *cpu_bootaddr;
> +
> +static DEFINE_SPINLOCK(cpu_lock);
> +
> +static int r9a06g032_smp_boot_secondary(unsigned int cpu, struct task_struct *idle)
> +{
> + if (!cpu_bootaddr)
> + return -ENODEV;
> +
> + spin_lock(&cpu_lock);
> +
> + writel(__pa_symbol(secondary_startup), cpu_bootaddr);
> + arch_send_wakeup_ipi_mask(cpumask_of(cpu));
> +
> + spin_unlock(&cpu_lock);
> +
> + return 0;
> +}
> +
> +static void __init r9a06g032_smp_prepare_cpus(unsigned int max_cpus)
> +{
> + struct device_node *dn;
> + int ret;
> + u32 bootaddr;
> +
> + dn = of_get_cpu_node(1, NULL);
> + if (!dn) {
> + pr_err("CPU#1: missing device tree node\n");
> + return;
> + }
> + /*
> + * Determine the address from which the CPU is polling.
> + * The bootloader *does* change this property
> + */
> + ret = of_property_read_u32(dn, "cpu-release-addr", &bootaddr);
> + of_node_put(dn);
> + if (ret) {
> + pr_err("CPU#1: invalid cpu-release-addr property\n");
> + return;
> + }
> + pr_info("CPU#1: cpu-release-addr %08x\n", bootaddr);
> +
> + cpu_bootaddr = ioremap(bootaddr, sizeof(bootaddr));
> +}
> +
> +static const struct smp_operations r9a06g032_smp_ops __initconst = {
> + .smp_prepare_cpus = r9a06g032_smp_prepare_cpus,
> + .smp_boot_secondary = r9a06g032_smp_boot_secondary,
> +};
> +CPU_METHOD_OF_DECLARE(r9a06g032_smp, "renesas,r9a06g032-smp", &r9a06g032_smp_ops);
>
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a77990: ebisu: Enable watchdog timer
From: Geert Uytterhoeven @ 2018-06-05 17:20 UTC (permalink / raw)
To: linux-arm-kernel
From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Add a device node for the Watchdog Timer (WDT) controller on the
R8A77990 SoC, and enable the watchdog on the Ebisu board.
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
[geert: Squashed 2 commits]
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 5 +++++
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 10 ++++++++++
2 files changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index 7a09d0524f9b0663..28945a8b980080f2 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -60,6 +60,11 @@
};
};
+&rwdt {
+ timeout-sec = <60>;
+ status = "okay";
+};
+
&scif2 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index 6d597a1c7636784f..735881d4e57ac1ad 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -69,6 +69,16 @@
#size-cells = <2>;
ranges;
+ rwdt: watchdog at e6020000 {
+ compatible = "renesas,r8a77990-wdt",
+ "renesas,rcar-gen3-wdt";
+ reg = <0 0xe6020000 0 0x0c>;
+ clocks = <&cpg CPG_MOD 402>;
+ power-domains = <&sysc 32>;
+ resets = <&cpg 402>;
+ status = "disabled";
+ };
+
gpio0: gpio at e6050000 {
compatible = "renesas,gpio-r8a77990",
"renesas,rcar-gen3-gpio";
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] ACPI / PPTT: fix build when CONFIG_ACPI_PPTT is not enabled
From: Catalin Marinas @ 2018-06-05 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528209304-3280-2-git-send-email-sudeep.holla@arm.com>
On Tue, Jun 05, 2018 at 03:35:03PM +0100, Sudeep Holla wrote:
> Though CONFIG_ACPI_PPTT is selected by platforms and nor user visible,
> it may be useful to support the build with CONFIG_ACPI_PPTT disabled.
>
> This patch adds the missing dummy/boiler plate implementation to fix
> the build.
>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> include/linux/acpi.h | 15 +++++++++++++++
> include/linux/cacheinfo.h | 2 +-
> 2 files changed, 16 insertions(+), 1 deletion(-)
I queued this patch for now, it's a good clean-up regardless of whether
we disable PPTT temporarily or not.
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH] arm64: alternative:flush cache with unpatched code
From: Alexander Van Brunt @ 2018-06-05 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605165511.GB2193@arm.com>
> 1. Boot. This happens once, and we end up putting *all* secondary cores into
> a tight loop anyway, so I don't see that the performance of
> __flush_icache_all is relevant
Native boot happens once. But, each VM that boots will slow down all of the other VM's on the system. A VM boot can happen thousands of times.
I really don't want to cause the whole system to hiccup for a millisecond or more when there are only a few cache lines that need to be invalidated.
^ permalink raw reply
* [PATCH v2] dmaengine: ti: omap-dma: Fix OMAP1510 incorrect residue_granularity
From: Janusz Krzysztofik @ 2018-06-05 16:59 UTC (permalink / raw)
To: linux-arm-kernel
Commit 0198d7bb8a0c ("ASoC: omap-mcbsp: Convert to use the sdma-pcm
instead of omap-pcm") resulted in broken audio playback on OMAP1510
(discovered on Amstrad Delta).
When running on OMAP1510, omap-pcm used to obtain DMA offset from
snd_dmaengine_pcm_pointer_no_residue() based on DMA interrupt triggered
software calculations instead of snd_dmaengine_pcm_pointer() which
depended on residue value calculated from omap_dma_get_src_pos().
Similar code path is still available in now used
sound/soc/soc-generic-dmaengine-pcm.c but it is not triggered.
It was verified already before that omap_get_dma_src_pos() from
arch/arm/plat-omap/dma.c didn't work correctly for OMAP1510 - see
commit 1bdd7419910c ("ASoC: OMAP: fix OMAP1510 broken PCM pointer
callback") for details. Apparently the same applies to its successor,
omap_dma_get_src_pos() from drivers/dma/ti/omap-dma.c.
On the other hand, snd_dmaengine_pcm_pointer_no_residue() is described
as depreciated and discouraged for use in new drivers because of its
unreliable accuracy. However, it seems the only working option for
OPAM1510 now, as long as a software calculated residue is not
implemented as OMAP1510 fallback in omap-dma.
Using snd_dmaengine_pcm_pointer_no_residue() code path instead of
snd_dmaengine_pcm_pointer() in sound/soc/soc-generic-dmaengine-pcm.c
can be triggered in two ways:
- by passing pcm->flags |= SND_DMAENGINE_PCM_FLAG_NO_RESIDUE from
sound/soc/omap/sdma-pcm.c,
- by passing dma_caps.residue_granularity =
DMA_RESIDUE_GRANULARITY_DESCRIPTOR from DMA engine.
Let's do the latter.
Created and tested against next-20180531 tag from linux-next tree.
Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
Changelog:
v2: fix subject as requested by Peter.
drivers/dma/ti/omap-dma.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/ti/omap-dma.c b/drivers/dma/ti/omap-dma.c
index b73fb51fbc81..96b5096c26dd 100644
--- a/drivers/dma/ti/omap-dma.c
+++ b/drivers/dma/ti/omap-dma.c
@@ -1485,7 +1485,11 @@ static int omap_dma_probe(struct platform_device *pdev)
od->ddev.src_addr_widths = OMAP_DMA_BUSWIDTHS;
od->ddev.dst_addr_widths = OMAP_DMA_BUSWIDTHS;
od->ddev.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
- od->ddev.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
+ if (__dma_omap15xx(od->plat->dma_attr))
+ od->ddev.residue_granularity =
+ DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
+ else
+ od->ddev.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
od->ddev.max_burst = SZ_16M - 1; /* CCEN: 24bit unsigned */
od->ddev.dev = &pdev->dev;
INIT_LIST_HEAD(&od->ddev.channels);
--
2.16.1
^ permalink raw reply related
* [PATCH] arm64: alternative:flush cache with unpatched code
From: Will Deacon @ 2018-06-05 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528140881044.41145@nvidia.com>
Hi Alex,
On Mon, Jun 04, 2018 at 07:34:10PM +0000, Alexander Van Brunt wrote:
> __flush_icache_all all cache is slow in large systems. It flushes the
> instruction caches cache in the inner-shareable domain. That includes
> other NUMA nodes in multi-socket systems. The CPU issuing the invalidate
> has to wait for all of the other CPUs to complete the invalidate
> instruction. The remote CPU's responding to the request all need to slow
> down.
>
> In contrast, flushes by range can be checked in a snoop filter to see if
> the addresses are relevant to the CPU. So, it scales to systems with more
> than two clusters much better.
>
> The flush ignores the VMID. So, one guest OS can slow down others. That
> creates a big covert channel between guests unless the hypervisor traps
> and emulates it by invalidating an entire VMID. By flushing by VA range,
> the hardware only flushes lines associated with the VMID, ASID, and VA
> associated with the line.
>
> Selfishly, NVIDIA's Denver CPU's are even more sensitive because the
> optimized code stored in DRAM is effectively a very large (on the order of
> 64 MB) instruction cache. "ic ialluis" can result in the entire
> optimization cache for all guests to be invalidated.
>
> I am aware that the arguments I made apply to TLB invalidates and the
> other places that Linux calls __flush_icache_all. But, that doesn't mean I
> don't like those either. For now, I just don't want more calls to
> __flush_icache_all.
Sure, but there are only two cases to consider here:
1. Boot. This happens once, and we end up putting *all* secondary cores into
a tight loop anyway, so I don't see that the performance of
__flush_icache_all is relevant
2. On module load. This happens right before we start remapping the module
areas and sending out TLB invalidation so, again, not sure I see why this
is such a big deal. In fact, it looks like the core module loading code
does invalidation by range, so if we remove it from __apply_alternatives
then we can avoid doing it twice.
In other words, something like the diff below.
Will
--->8
diff --git a/arch/arm64/include/asm/alternative.h b/arch/arm64/include/asm/alternative.h
index a91933b1e2e6..934f99215bd4 100644
--- a/arch/arm64/include/asm/alternative.h
+++ b/arch/arm64/include/asm/alternative.h
@@ -28,7 +28,12 @@ typedef void (*alternative_cb_t)(struct alt_instr *alt,
__le32 *origptr, __le32 *updptr, int nr_inst);
void __init apply_alternatives_all(void);
-void apply_alternatives(void *start, size_t length);
+
+#ifdef CONFIG_MODULES
+void apply_alternatives_module(void *start, size_t length);
+#else
+void apply_alternatives_module(void *start, size_t length) { }
+#endif
#define ALTINSTR_ENTRY(feature,cb) \
" .word 661b - .\n" /* label */ \
diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h
index 9bbffc7a301f..627d62ff2ddd 100644
--- a/arch/arm64/include/asm/cache.h
+++ b/arch/arm64/include/asm/cache.h
@@ -21,6 +21,7 @@
#define CTR_L1IP_SHIFT 14
#define CTR_L1IP_MASK 3
#define CTR_DMINLINE_SHIFT 16
+#define CTR_IMINLINE_SHIFT 0
#define CTR_ERG_SHIFT 20
#define CTR_CWG_SHIFT 24
#define CTR_CWG_MASK 15
diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
index 5c4bce4ac381..6c813f58824b 100644
--- a/arch/arm64/kernel/alternative.c
+++ b/arch/arm64/kernel/alternative.c
@@ -122,7 +122,29 @@ static void patch_alternative(struct alt_instr *alt,
}
}
-static void __apply_alternatives(void *alt_region, bool use_linear_alias)
+static void clean_dcache_range_nopatch(u64 start, u64 end)
+{
+ u64 cur, d_size, i_size, ctr_el0;
+
+ /* use sanitised value of ctr_el0 rather than raw value from CPU */
+ ctr_el0 = read_sanitised_ftr_reg(SYS_CTR_EL0);
+ /* size in bytes */
+ d_size = 4 << cpuid_feature_extract_unsigned_field(ctr_el0,
+ CTR_DMINLINE_SHIFT);
+ i_size = 4 << cpuid_feature_extract_unsigned_field(ctr_el0,
+ CTR_IMINLINE_SHIFT);
+
+ cur = start & ~(d_size - 1);
+ do {
+ /*
+ * We must clean+invalidate in order to avoid Cortex-A53
+ * errata 826319, 827319, 824069 and 819472.
+ */
+ asm volatile("dc civac, %0" : : "r" (cur) : "memory");
+ } while (cur += d_size, cur < end);
+}
+
+static void __apply_alternatives(void *alt_region, bool is_module)
{
struct alt_instr *alt;
struct alt_region *region = alt_region;
@@ -145,7 +167,7 @@ static void __apply_alternatives(void *alt_region, bool use_linear_alias)
pr_info_once("patching kernel code\n");
origptr = ALT_ORIG_PTR(alt);
- updptr = use_linear_alias ? lm_alias(origptr) : origptr;
+ updptr = is_module ? origptr : lm_alias(origptr);
nr_inst = alt->orig_len / AARCH64_INSN_SIZE;
if (alt->cpufeature < ARM64_CB_PATCH)
@@ -155,9 +177,23 @@ static void __apply_alternatives(void *alt_region, bool use_linear_alias)
alt_cb(alt, origptr, updptr, nr_inst);
- flush_icache_range((uintptr_t)origptr,
- (uintptr_t)(origptr + nr_inst));
+ if (is_module)
+ continue;
+
+ clean_dcache_range_nopatch((u64)origptr,
+ (u64)(origptr + nr_inst));
}
+
+ /*
+ * The core module code takes care of cache maintenance in
+ * flush_module_icache().
+ */
+ if (is_module)
+ return;
+
+ dsb(ish);
+ __flush_icache_all();
+ isb();
}
/*
@@ -178,7 +214,7 @@ static int __apply_alternatives_multi_stop(void *unused)
isb();
} else {
BUG_ON(alternatives_applied);
- __apply_alternatives(®ion, true);
+ __apply_alternatives(®ion, false);
/* Barriers provided by the cache flushing */
WRITE_ONCE(alternatives_applied, 1);
}
@@ -192,12 +228,14 @@ void __init apply_alternatives_all(void)
stop_machine(__apply_alternatives_multi_stop, NULL, cpu_online_mask);
}
-void apply_alternatives(void *start, size_t length)
+#ifdef CONFIG_MODULES
+void apply_alternatives_module(void *start, size_t length)
{
struct alt_region region = {
.begin = start,
.end = start + length,
};
- __apply_alternatives(®ion, false);
+ __apply_alternatives(®ion, true);
}
+#endif
diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
index 155fd91e78f4..f0f27aeefb73 100644
--- a/arch/arm64/kernel/module.c
+++ b/arch/arm64/kernel/module.c
@@ -448,9 +448,8 @@ int module_finalize(const Elf_Ehdr *hdr,
const char *secstrs = (void *)hdr + sechdrs[hdr->e_shstrndx].sh_offset;
for (s = sechdrs, se = sechdrs + hdr->e_shnum; s < se; s++) {
- if (strcmp(".altinstructions", secstrs + s->sh_name) == 0) {
- apply_alternatives((void *)s->sh_addr, s->sh_size);
- }
+ if (strcmp(".altinstructions", secstrs + s->sh_name) == 0)
+ apply_alternatives_module((void *)s->sh_addr, s->sh_size);
#ifdef CONFIG_ARM64_MODULE_PLTS
if (IS_ENABLED(CONFIG_DYNAMIC_FTRACE) &&
!strcmp(".text.ftrace_trampoline", secstrs + s->sh_name))
^ permalink raw reply related
* [PATCH v2 3/3] arm64: disable ACPI PPTT support temporarily
From: Jeremy Linton @ 2018-06-05 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a93212e3-7965-9ae2-34b0-407f04590567@arm.com>
Hi,
On 06/05/2018 10:27 AM, Sudeep Holla wrote:
>
>
> On 05/06/18 16:02, Rafael J. Wysocki wrote:
>> On Tue, Jun 5, 2018 at 4:35 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> Currently, ARM64 doesn't support updating the CPU topology masks on
>>> CPU hotplug operations. ACPI PPTT support rely on that missing feature
>>> which is technically not incorrect. Instead of reverting all the PPTT
>>> support, let's keep it simple and disable ACPI PPTT support on ARM64
>>> for time-being until the topology updates are added for CPU hotplug
>>> operations.
>>
>> When is that going to happen?
>>> Nobody else uses PPTT now.
>>
>
> No we need it on ARM64. I have even the fixes for the original issue
> but it's bit invasive and too late as we are already in the merge
> window. It needs to be tested on NUMA platforms, I have asked for that
> explicitly.
>
So, there is a lot simpler fix for this, and its to remove the numa mask
dependency from the scheduler domain building. That is just a couple
line fix, and it reverts !ACPI to its original behavior, while the ACPI
LLC building will work around the NUMA in package issue that caused
patch 12/12 as the machine in question doesn't have a LLC crossing numa
domains.
^ 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