* [PATCH v4 4/8] arm64: hyperv: Add interrupt handlers for VMbus and stimer
From: Michael Kelley @ 2019-08-06 20:31 UTC (permalink / raw)
To: will.deacon@arm.com, catalin.marinas@arm.com,
mark.rutland@arm.com, marc.zyngier@arm.com,
linux-arm-kernel@lists.infradead.org, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
devel@linuxdriverproject.org, olaf@aepfle.de, apw@canonical.com,
vkuznets, jasowang@redhat.com, marcelo.cerri@canonical.com,
KY Srinivasan
Cc: Sunil Muthuswamy, boqun.feng, Michael Kelley
In-Reply-To: <1565122133-9086-1-git-send-email-mikelley@microsoft.com>
Add ARM64-specific code to set up and handle the interrupts
generated by Hyper-V for VMbus messages and for stimer expiration.
This code is architecture dependent and is mostly driven by
architecture independent code in the VMbus driver and the
Hyper-V timer clocksource driver.
This code is built only when CONFIG_HYPERV is enabled.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
---
arch/arm64/hyperv/Makefile | 2 +-
arch/arm64/hyperv/mshyperv.c | 139 +++++++++++++++++++++++++++++++++++++++++++
2 files changed, 140 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/hyperv/mshyperv.c
diff --git a/arch/arm64/hyperv/Makefile b/arch/arm64/hyperv/Makefile
index 6bd8439..988eda5 100644
--- a/arch/arm64/hyperv/Makefile
+++ b/arch/arm64/hyperv/Makefile
@@ -1,2 +1,2 @@
# SPDX-License-Identifier: GPL-2.0
-obj-y := hv_init.o hv_hvc.o
+obj-y := hv_init.o hv_hvc.o mshyperv.o
diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
new file mode 100644
index 0000000..ae6ece6
--- /dev/null
+++ b/arch/arm64/hyperv/mshyperv.c
@@ -0,0 +1,139 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Core routines for interacting with Microsoft's Hyper-V hypervisor,
+ * including setting up VMbus and STIMER interrupts, and handling
+ * crashes and kexecs. These interactions are through a set of
+ * static "handler" variables set by the architecture independent
+ * VMbus and STIMER drivers.
+ *
+ * Copyright (C) 2019, Microsoft, Inc.
+ *
+ * Author : Michael Kelley <mikelley@microsoft.com>
+ */
+
+#include <linux/types.h>
+#include <linux/export.h>
+#include <linux/interrupt.h>
+#include <linux/kexec.h>
+#include <linux/acpi.h>
+#include <linux/ptrace.h>
+#include <asm/hyperv-tlfs.h>
+#include <asm/mshyperv.h>
+
+static void (*vmbus_handler)(void);
+static void (*hv_stimer0_handler)(void);
+
+static int vmbus_irq;
+static long __percpu *vmbus_evt;
+static long __percpu *stimer0_evt;
+
+irqreturn_t hyperv_vector_handler(int irq, void *dev_id)
+{
+ vmbus_handler();
+ return IRQ_HANDLED;
+}
+
+/* Must be done just once */
+void hv_setup_vmbus_irq(void (*handler)(void))
+{
+ int result;
+
+ vmbus_handler = handler;
+ vmbus_irq = acpi_register_gsi(NULL, HYPERVISOR_CALLBACK_VECTOR,
+ ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_HIGH);
+ if (vmbus_irq <= 0) {
+ pr_err("Can't register Hyper-V VMBus GSI. Error %d",
+ vmbus_irq);
+ vmbus_irq = 0;
+ return;
+ }
+ vmbus_evt = alloc_percpu(long);
+ result = request_percpu_irq(vmbus_irq, hyperv_vector_handler,
+ "Hyper-V VMbus", vmbus_evt);
+ if (result) {
+ pr_err("Can't request Hyper-V VMBus IRQ %d. Error %d",
+ vmbus_irq, result);
+ free_percpu(vmbus_evt);
+ acpi_unregister_gsi(vmbus_irq);
+ vmbus_irq = 0;
+ }
+}
+EXPORT_SYMBOL_GPL(hv_setup_vmbus_irq);
+
+/* Must be done just once */
+void hv_remove_vmbus_irq(void)
+{
+ if (vmbus_irq) {
+ free_percpu_irq(vmbus_irq, vmbus_evt);
+ free_percpu(vmbus_evt);
+ acpi_unregister_gsi(vmbus_irq);
+ }
+}
+EXPORT_SYMBOL_GPL(hv_remove_vmbus_irq);
+
+/* Must be done by each CPU */
+void hv_enable_vmbus_irq(void)
+{
+ enable_percpu_irq(vmbus_irq, 0);
+}
+EXPORT_SYMBOL_GPL(hv_enable_vmbus_irq);
+
+/* Must be done by each CPU */
+void hv_disable_vmbus_irq(void)
+{
+ disable_percpu_irq(vmbus_irq);
+}
+EXPORT_SYMBOL_GPL(hv_disable_vmbus_irq);
+
+/* Routines to do per-architecture handling of STIMER0 when in Direct Mode */
+
+static irqreturn_t hv_stimer0_vector_handler(int irq, void *dev_id)
+{
+ if (hv_stimer0_handler)
+ hv_stimer0_handler();
+ return IRQ_HANDLED;
+}
+
+int hv_setup_stimer0_irq(int *irq, int *vector, void (*handler)(void))
+{
+ int localirq;
+ int result;
+
+ localirq = acpi_register_gsi(NULL, HV_STIMER0_IRQNR,
+ ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_HIGH);
+ if (localirq <= 0) {
+ pr_err("Can't register Hyper-V stimer0 GSI. Error %d",
+ localirq);
+ *irq = 0;
+ return -1;
+ }
+ stimer0_evt = alloc_percpu(long);
+ result = request_percpu_irq(localirq, hv_stimer0_vector_handler,
+ "Hyper-V stimer0", stimer0_evt);
+ if (result) {
+ pr_err("Can't request Hyper-V stimer0 IRQ %d. Error %d",
+ localirq, result);
+ free_percpu(stimer0_evt);
+ acpi_unregister_gsi(localirq);
+ *irq = 0;
+ return -1;
+ }
+
+ hv_stimer0_handler = handler;
+ *vector = HV_STIMER0_IRQNR;
+ *irq = localirq;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(hv_setup_stimer0_irq);
+
+void hv_remove_stimer0_irq(int irq)
+{
+ hv_stimer0_handler = NULL;
+ if (irq) {
+ free_percpu_irq(irq, stimer0_evt);
+ free_percpu(stimer0_evt);
+ acpi_unregister_gsi(irq);
+ }
+}
+EXPORT_SYMBOL_GPL(hv_remove_stimer0_irq);
--
1.8.3.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 5/8] arm64: hyperv: Add kexec and panic handlers
From: Michael Kelley @ 2019-08-06 20:31 UTC (permalink / raw)
To: will.deacon@arm.com, catalin.marinas@arm.com,
mark.rutland@arm.com, marc.zyngier@arm.com,
linux-arm-kernel@lists.infradead.org, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
devel@linuxdriverproject.org, olaf@aepfle.de, apw@canonical.com,
vkuznets, jasowang@redhat.com, marcelo.cerri@canonical.com,
KY Srinivasan
Cc: Sunil Muthuswamy, boqun.feng, Michael Kelley
In-Reply-To: <1565122133-9086-1-git-send-email-mikelley@microsoft.com>
Add functions to set up and remove kexec and panic
handlers, and to inform Hyper-V about a guest panic.
These functions are called from architecture independent
code in the VMbus driver.
This code is built only when CONFIG_HYPERV is enabled.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
---
arch/arm64/hyperv/hv_init.c | 61 ++++++++++++++++++++++++++++++++++++++++++++
arch/arm64/hyperv/mshyperv.c | 26 +++++++++++++++++++
2 files changed, 87 insertions(+)
diff --git a/arch/arm64/hyperv/hv_init.c b/arch/arm64/hyperv/hv_init.c
index 9c294f6..67350ec 100644
--- a/arch/arm64/hyperv/hv_init.c
+++ b/arch/arm64/hyperv/hv_init.c
@@ -199,3 +199,64 @@ void hv_get_vpreg_128(u32 msr, struct hv_get_vp_register_output *result)
}
EXPORT_SYMBOL_GPL(hv_get_vpreg_128);
+
+void hyperv_report_panic(struct pt_regs *regs, long err)
+{
+ static bool panic_reported;
+ u64 guest_id;
+
+ /*
+ * We prefer to report panic on 'die' chain as we have proper
+ * registers to report, but if we miss it (e.g. on BUG()) we need
+ * to report it on 'panic'.
+ */
+ if (panic_reported)
+ return;
+ panic_reported = true;
+
+ guest_id = hv_get_vpreg(HV_REGISTER_GUEST_OSID);
+
+ /*
+ * Hyper-V provides the ability to store only 5 values.
+ * Pick the passed in error value, the guest_id, and the PC.
+ * The first two general registers are added arbitrarily.
+ */
+ hv_set_vpreg(HV_REGISTER_CRASH_P0, err);
+ hv_set_vpreg(HV_REGISTER_CRASH_P1, guest_id);
+ hv_set_vpreg(HV_REGISTER_CRASH_P2, regs->pc);
+ hv_set_vpreg(HV_REGISTER_CRASH_P3, regs->regs[0]);
+ hv_set_vpreg(HV_REGISTER_CRASH_P4, regs->regs[1]);
+
+ /*
+ * Let Hyper-V know there is crash data available
+ */
+ hv_set_vpreg(HV_REGISTER_CRASH_CTL, HV_CRASH_CTL_CRASH_NOTIFY);
+}
+EXPORT_SYMBOL_GPL(hyperv_report_panic);
+
+/*
+ * hyperv_report_panic_msg - report panic message to Hyper-V
+ * @pa: physical address of the panic page containing the message
+ * @size: size of the message in the page
+ */
+void hyperv_report_panic_msg(phys_addr_t pa, size_t size)
+{
+ /*
+ * P3 to contain the physical address of the panic page & P4 to
+ * contain the size of the panic data in that page. Rest of the
+ * registers are no-op when the NOTIFY_MSG flag is set.
+ */
+ hv_set_vpreg(HV_REGISTER_CRASH_P0, 0);
+ hv_set_vpreg(HV_REGISTER_CRASH_P1, 0);
+ hv_set_vpreg(HV_REGISTER_CRASH_P2, 0);
+ hv_set_vpreg(HV_REGISTER_CRASH_P3, pa);
+ hv_set_vpreg(HV_REGISTER_CRASH_P4, size);
+
+ /*
+ * Let Hyper-V know there is crash data available along with
+ * the panic message.
+ */
+ hv_set_vpreg(HV_REGISTER_CRASH_CTL,
+ (HV_CRASH_CTL_CRASH_NOTIFY | HV_CRASH_CTL_CRASH_NOTIFY_MSG));
+}
+EXPORT_SYMBOL_GPL(hyperv_report_panic_msg);
diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
index ae6ece6..c58940d 100644
--- a/arch/arm64/hyperv/mshyperv.c
+++ b/arch/arm64/hyperv/mshyperv.c
@@ -23,6 +23,8 @@
static void (*vmbus_handler)(void);
static void (*hv_stimer0_handler)(void);
+static void (*hv_kexec_handler)(void);
+static void (*hv_crash_handler)(struct pt_regs *regs);
static int vmbus_irq;
static long __percpu *vmbus_evt;
@@ -137,3 +139,27 @@ void hv_remove_stimer0_irq(int irq)
}
}
EXPORT_SYMBOL_GPL(hv_remove_stimer0_irq);
+
+void hv_setup_kexec_handler(void (*handler)(void))
+{
+ hv_kexec_handler = handler;
+}
+EXPORT_SYMBOL_GPL(hv_setup_kexec_handler);
+
+void hv_remove_kexec_handler(void)
+{
+ hv_kexec_handler = NULL;
+}
+EXPORT_SYMBOL_GPL(hv_remove_kexec_handler);
+
+void hv_setup_crash_handler(void (*handler)(struct pt_regs *regs))
+{
+ hv_crash_handler = handler;
+}
+EXPORT_SYMBOL_GPL(hv_setup_crash_handler);
+
+void hv_remove_crash_handler(void)
+{
+ hv_crash_handler = NULL;
+}
+EXPORT_SYMBOL_GPL(hv_remove_crash_handler);
--
1.8.3.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 6/8] arm64: hyperv: Initialize hypervisor on boot
From: Michael Kelley @ 2019-08-06 20:31 UTC (permalink / raw)
To: will.deacon@arm.com, catalin.marinas@arm.com,
mark.rutland@arm.com, marc.zyngier@arm.com,
linux-arm-kernel@lists.infradead.org, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
devel@linuxdriverproject.org, olaf@aepfle.de, apw@canonical.com,
vkuznets, jasowang@redhat.com, marcelo.cerri@canonical.com,
KY Srinivasan
Cc: Sunil Muthuswamy, boqun.feng, Michael Kelley
In-Reply-To: <1565122133-9086-1-git-send-email-mikelley@microsoft.com>
Add ARM64-specific code to initialize the Hyper-V
hypervisor when booting as a guest VM. Provide functions
and data structures indicating hypervisor status that
are needed by VMbus driver.
This code is built only when CONFIG_HYPERV is enabled.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
---
arch/arm64/hyperv/hv_init.c | 142 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 142 insertions(+)
diff --git a/arch/arm64/hyperv/hv_init.c b/arch/arm64/hyperv/hv_init.c
index 67350ec..7179e12 100644
--- a/arch/arm64/hyperv/hv_init.c
+++ b/arch/arm64/hyperv/hv_init.c
@@ -13,15 +13,47 @@
#include <linux/types.h>
#include <linux/version.h>
#include <linux/export.h>
+#include <linux/vmalloc.h>
#include <linux/mm.h>
+#include <linux/acpi.h>
+#include <linux/module.h>
#include <linux/hyperv.h>
#include <linux/spinlock.h>
#include <linux/list.h>
#include <linux/string.h>
+#include <linux/slab.h>
+#include <linux/cpuhotplug.h>
+#include <linux/psci.h>
#include <asm-generic/bug.h>
#include <asm/hyperv-tlfs.h>
#include <asm/mshyperv.h>
+#include <asm/sysreg.h>
+#include <clocksource/hyperv_timer.h>
+static bool hyperv_initialized;
+
+struct ms_hyperv_info ms_hyperv __ro_after_init;
+EXPORT_SYMBOL_GPL(ms_hyperv);
+
+u32 *hv_vp_index;
+EXPORT_SYMBOL_GPL(hv_vp_index);
+
+u32 hv_max_vp_index;
+EXPORT_SYMBOL_GPL(hv_max_vp_index);
+
+static int hv_cpu_init(unsigned int cpu)
+{
+ u64 msr_vp_index;
+
+ hv_get_vp_index(msr_vp_index);
+
+ hv_vp_index[smp_processor_id()] = msr_vp_index;
+
+ if (msr_vp_index > hv_max_vp_index)
+ hv_max_vp_index = msr_vp_index;
+
+ return 0;
+}
/*
* Functions for allocating and freeing memory with size and
@@ -88,6 +120,110 @@ void hv_free_hyperv_page(unsigned long addr)
/*
+ * This function is invoked via the ACPI clocksource probe mechanism. We
+ * don't actually use any values from the ACPI GTDT table, but we set up
+ * the Hyper-V synthetic clocksource and do other initialization for
+ * interacting with Hyper-V the first time. Using early_initcall to invoke
+ * this function is too late because interrupts are already enabled at that
+ * point, and hv_init_clocksource() must run before interrupts are enabled.
+ *
+ * 1. Setup the guest ID.
+ * 2. Get features and hints info from Hyper-V
+ * 3. Setup per-cpu VP indices.
+ * 4. Initialize the Hyper-V clocksource.
+ */
+
+static int __init hyperv_init(struct acpi_table_header *table)
+{
+ struct hv_get_vp_register_output result;
+ u32 a, b, c, d;
+ u64 guest_id;
+ int i;
+
+ /*
+ * If we're in a VM on Hyper-V, the ACPI hypervisor_id field will
+ * have the string "MsHyperV".
+ */
+ if (strncmp((char *)&acpi_gbl_FADT.hypervisor_id, "MsHyperV", 8))
+ return -EINVAL;
+
+ /* Setup the guest ID */
+ guest_id = generate_guest_id(0, LINUX_VERSION_CODE, 0);
+ hv_set_vpreg(HV_REGISTER_GUEST_OSID, guest_id);
+
+ /* Get the features and hints from Hyper-V */
+ hv_get_vpreg_128(HV_REGISTER_PRIVILEGES_AND_FEATURES, &result);
+ ms_hyperv.features = lower_32_bits(result.registervaluelow);
+ ms_hyperv.misc_features = upper_32_bits(result.registervaluehigh);
+
+ hv_get_vpreg_128(HV_REGISTER_FEATURES, &result);
+ ms_hyperv.hints = lower_32_bits(result.registervaluelow);
+
+ pr_info("Hyper-V: Features 0x%x, hints 0x%x\n",
+ ms_hyperv.features, ms_hyperv.hints);
+
+ /*
+ * Direct mode is the only option for STIMERs provided Hyper-V
+ * on ARM64, so Hyper-V doesn't actually set the flag. But add
+ * the flag so the architecture independent code in
+ * drivers/clocksource/hyperv_timer.c will correctly use that mode.
+ */
+ ms_hyperv.misc_features |= HV_STIMER_DIRECT_MODE_AVAILABLE;
+
+ /*
+ * Hyper-V on ARM64 doesn't support AutoEOI. Add the hint
+ * that tells architecture independent code not to use this
+ * feature.
+ */
+ ms_hyperv.hints |= HV_DEPRECATING_AEOI_RECOMMENDED;
+
+ /* Get information about the Hyper-V host version */
+ hv_get_vpreg_128(HV_REGISTER_HYPERVISOR_VERSION, &result);
+ a = lower_32_bits(result.registervaluelow);
+ b = upper_32_bits(result.registervaluelow);
+ c = lower_32_bits(result.registervaluehigh);
+ d = upper_32_bits(result.registervaluehigh);
+ pr_info("Hyper-V: Host Build %d.%d.%d.%d-%d-%d\n",
+ b >> 16, b & 0xFFFF, a, d & 0xFFFFFF, c, d >> 24);
+
+ /* Allocate and initialize percpu VP index array */
+ hv_vp_index = kmalloc_array(num_possible_cpus(), sizeof(*hv_vp_index),
+ GFP_KERNEL);
+ if (!hv_vp_index)
+ return -ENOMEM;
+
+ for (i = 0; i < num_possible_cpus(); i++)
+ hv_vp_index[i] = VP_INVAL;
+
+ if (cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "arm64/hyperv_init:online",
+ hv_cpu_init, NULL) < 0)
+ goto free_vp_index;
+
+ hv_init_clocksource();
+
+ hyperv_initialized = true;
+ return 0;
+
+free_vp_index:
+ kfree(hv_vp_index);
+ hv_vp_index = NULL;
+ return -EINVAL;
+}
+TIMER_ACPI_DECLARE(hyperv, ACPI_SIG_GTDT, hyperv_init);
+
+/*
+ * This routine is called before kexec/kdump, it does the required cleanup.
+ */
+void hyperv_cleanup(void)
+{
+ /* Reset our OS id */
+ hv_set_vpreg(HV_REGISTER_GUEST_OSID, 0);
+
+}
+EXPORT_SYMBOL_GPL(hyperv_cleanup);
+
+
+/*
* hv_do_hypercall- Invoke the specified hypercall
*/
u64 hv_do_hypercall(u64 control, void *input, void *output)
@@ -260,3 +396,9 @@ void hyperv_report_panic_msg(phys_addr_t pa, size_t size)
(HV_CRASH_CTL_CRASH_NOTIFY | HV_CRASH_CTL_CRASH_NOTIFY_MSG));
}
EXPORT_SYMBOL_GPL(hyperv_report_panic_msg);
+
+bool hv_is_hyperv_initialized(void)
+{
+ return hyperv_initialized;
+}
+EXPORT_SYMBOL_GPL(hv_is_hyperv_initialized);
--
1.8.3.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 7/8] Drivers: hv: vmbus: Add hooks for per-CPU IRQ
From: Michael Kelley @ 2019-08-06 20:31 UTC (permalink / raw)
To: will.deacon@arm.com, catalin.marinas@arm.com,
mark.rutland@arm.com, marc.zyngier@arm.com,
linux-arm-kernel@lists.infradead.org, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
devel@linuxdriverproject.org, olaf@aepfle.de, apw@canonical.com,
vkuznets, jasowang@redhat.com, marcelo.cerri@canonical.com,
KY Srinivasan
Cc: Sunil Muthuswamy, boqun.feng, Michael Kelley
In-Reply-To: <1565122133-9086-1-git-send-email-mikelley@microsoft.com>
Add hooks to enable/disable a per-CPU IRQ for VMbus. These hooks
are in the architecture independent setup and shutdown paths for
Hyper-V, and are needed by Linux guests on Hyper-V on ARM64. The
x86/x64 implementation is null because VMbus interrupts on x86/x64
don't use an IRQ.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
---
arch/x86/include/asm/mshyperv.h | 4 ++++
drivers/hv/hv.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index f4138ae..583e1ce 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -56,6 +56,10 @@ typedef int (*hyperv_fill_flush_list_func)(
#endif
void hyperv_vector_handler(struct pt_regs *regs);
+/* On x86/x64, there isn't a real IRQ to be enabled/disable */
+static inline void hv_enable_vmbus_irq(void) {}
+static inline void hv_disable_vmbus_irq(void) {}
+
/*
* Routines for stimer0 Direct Mode handling.
* On x86/x64, there are no percpu actions to take.
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 6188fb7..86f5435 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -180,6 +180,7 @@ int hv_synic_init(unsigned int cpu)
hv_set_siefp(siefp.as_uint64);
/* Setup the shared SINT. */
+ hv_enable_vmbus_irq();
hv_get_synint_state(VMBUS_MESSAGE_SINT, shared_sint.as_uint64);
shared_sint.vector = HYPERVISOR_CALLBACK_VECTOR;
@@ -272,6 +273,7 @@ int hv_synic_cleanup(unsigned int cpu)
/* Disable the global synic bit */
sctrl.enable = 0;
hv_set_synic_state(sctrl.as_uint64);
+ hv_disable_vmbus_irq();
return 0;
}
--
1.8.3.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 8/8] Drivers: hv: Enable Hyper-V code to be built on ARM64
From: Michael Kelley @ 2019-08-06 20:31 UTC (permalink / raw)
To: will.deacon@arm.com, catalin.marinas@arm.com,
mark.rutland@arm.com, marc.zyngier@arm.com,
linux-arm-kernel@lists.infradead.org, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
devel@linuxdriverproject.org, olaf@aepfle.de, apw@canonical.com,
vkuznets, jasowang@redhat.com, marcelo.cerri@canonical.com,
KY Srinivasan
Cc: Sunil Muthuswamy, boqun.feng, Michael Kelley
In-Reply-To: <1565122133-9086-1-git-send-email-mikelley@microsoft.com>
Update drivers/hv/Kconfig so CONFIG_HYPERV and CONFIG_HYPERV_TSCPAGE
can be selected on ARM64, causing the Hyper-V specific code to be built.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
---
drivers/hv/Kconfig | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 9a59957..6f8808f 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -4,7 +4,8 @@ menu "Microsoft Hyper-V guest support"
config HYPERV
tristate "Microsoft Hyper-V client drivers"
- depends on X86 && ACPI && X86_LOCAL_APIC && HYPERVISOR_GUEST
+ depends on ACPI && \
+ ((X86 && X86_LOCAL_APIC && HYPERVISOR_GUEST) || ARM64)
select PARAVIRT
select X86_HV_CALLBACK_VECTOR
help
@@ -15,7 +16,7 @@ config HYPERV_TIMER
def_bool HYPERV
config HYPERV_TSCPAGE
- def_bool HYPERV && X86_64
+ def_bool HYPERV && (X86_64 || ARM64)
config HYPERV_UTILS
tristate "Microsoft Hyper-V Utilities driver"
--
1.8.3.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 01/34] mm/gup: add make_dirty arg to put_user_pages_dirty_lock()
From: John Hubbard @ 2019-08-06 20:39 UTC (permalink / raw)
To: Ira Weiny, john.hubbard
Cc: linux-fbdev, Jan Kara, kvm, Dave Hansen, Dave Chinner, dri-devel,
linux-mm, Matthew Wilcox, sparclinux, Dan Williams, devel,
rds-devel, linux-rdma, x86, amd-gfx, Christoph Hellwig,
Christoph Hellwig, Jason Gunthorpe, xen-devel, devel, linux-media,
intel-gfx, linux-block, Jérôme Glisse, linux-rpi-kernel,
ceph-devel, linux-arm-kernel, linux-nfs, netdev, LKML, linux-xfs,
linux-crypto, linux-fsdevel, Andrew Morton
In-Reply-To: <20190806173945.GA4748@iweiny-DESK2.sc.intel.com>
On 8/6/19 10:39 AM, Ira Weiny wrote:
> On Sun, Aug 04, 2019 at 03:48:42PM -0700, john.hubbard@gmail.com wrote:
>> From: John Hubbard <jhubbard@nvidia.com>
...
>> -
>> /**
>> - * put_user_pages_dirty() - release and dirty an array of gup-pinned pages
>> - * @pages: array of pages to be marked dirty and released.
>> + * put_user_pages_dirty_lock() - release and optionally dirty gup-pinned pages
>> + * @pages: array of pages to be maybe marked dirty, and definitely released.
>
> Better would be.
>
> @pages: array of pages to be put
OK, I'll change to that wording.
>
>> * @npages: number of pages in the @pages array.
>> + * @make_dirty: whether to mark the pages dirty
>> *
>> * "gup-pinned page" refers to a page that has had one of the get_user_pages()
>> * variants called on that page.
>> *
>> * For each page in the @pages array, make that page (or its head page, if a
>> - * compound page) dirty, if it was previously listed as clean. Then, release
>> - * the page using put_user_page().
>> + * compound page) dirty, if @make_dirty is true, and if the page was previously
>> + * listed as clean. In any case, releases all pages using put_user_page(),
>> + * possibly via put_user_pages(), for the non-dirty case.
>
> I don't think users of this interface need this level of detail. I think
> something like.
>
> * For each page in the @pages array, release the page. If @make_dirty is
> * true, mark the page dirty prior to release.
Yes, it is too wordy, I'll change to that.
>
...
>> -void put_user_pages_dirty_lock(struct page **pages, unsigned long npages)
>> -{
>> - __put_user_pages_dirty(pages, npages, set_page_dirty_lock);
>> + /*
>> + * TODO: this can be optimized for huge pages: if a series of pages is
>> + * physically contiguous and part of the same compound page, then a
>> + * single operation to the head page should suffice.
>> + */
>
> I think this comment belongs to the for loop below... or just something about
> how to make this and put_user_pages() more efficient. It is odd, that this is
> the same comment as in put_user_pages()...
Actually I think I'll just delete the comment entirely, it's just noise really.
>
> The code is good. So... Other than the comments.
>
> Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Thanks for the review!
thanks,
--
John Hubbard
NVIDIA
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: a64: Drop PMU node
From: Vasily Khoruzhick @ 2019-08-06 20:52 UTC (permalink / raw)
To: Harald Geyer
Cc: Mark Rutland, devicetree, Jared D . McNeill, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Robin Murphy, arm-linux
In-Reply-To: <E1hv5vZ-0000jN-M8@stardust.g4.wien.funkfeuer.at>
On Tue, Aug 6, 2019 at 1:19 PM Harald Geyer <harald@ccbib.org> wrote:
>
> Vasily Khoruzhick writes:
> > On Tue, Aug 6, 2019 at 7:35 AM Robin Murphy <robin.murphy@arm.com> wrote:
> > >
> > > On 06/08/2019 15:01, Vasily Khoruzhick wrote:
> > > > Looks like PMU in A64 is broken, it generates no interrupts at all and
> > > > as result 'perf top' shows no events.
> > >
> > > Does something like 'perf stat sleep 1' at least count cycles correctly?
> > > It could well just be that the interrupt numbers are wrong...
> >
> > Looks like it does, at least result looks plausible:
>
> I'm using perf stat regularly (cache benchmarks) and it works fine.
>
> Unfortunately I wasn't aware that perf stat is a poor test for
> the interrupts part of the node, when I added it. So I'm not too
> surprised I got it wrong.
>
> However, it would be unfortunate if the node got removed completely,
> because perf stat would not work anymore. Maybe we can only remove
> the interrupts or just fix them even if the HW doesn't work?
I'm not familiar with PMU driver. Is it possible to get it working
without interrupts?
>
> Harald
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] net: mdio-octeon: Fix Kconfig warnings and build errors
From: David Miller @ 2019-08-06 21:11 UTC (permalink / raw)
To: natechancellor
Cc: devel, andrew, f.fainelli, lkp, kernel-build-reports, gregkh,
rdunlap, willy, broonie, linux-next, netdev, linux-arm-kernel,
hkallweit1
In-Reply-To: <20190803060155.89548-1-natechancellor@gmail.com>
From: Nathan Chancellor <natechancellor@gmail.com>
Date: Fri, 2 Aug 2019 23:01:56 -0700
> After commit 171a9bae68c7 ("staging/octeon: Allow test build on
> !MIPS"), the following combination of configs cause a few Kconfig
> warnings and build errors (distilled from arm allyesconfig and Randy's
> randconfig builds):
>
> CONFIG_NETDEVICES=y
> CONFIG_STAGING=y
> CONFIG_COMPILE_TEST=y
>
> and CONFIG_OCTEON_ETHERNET as either a module or built-in.
>
> WARNING: unmet direct dependencies detected for MDIO_OCTEON
> Depends on [n]: NETDEVICES [=y] && MDIO_DEVICE [=y] && MDIO_BUS [=y]
> && 64BIT [=n] && HAS_IOMEM [=y] && OF_MDIO [=n]
> Selected by [y]:
> - OCTEON_ETHERNET [=y] && STAGING [=y] && (CAVIUM_OCTEON_SOC ||
> COMPILE_TEST [=y]) && NETDEVICES [=y]
>
> In file included from ../drivers/net/phy/mdio-octeon.c:14:
> ../drivers/net/phy/mdio-cavium.h:111:36: error: implicit declaration of
> function ‘writeq’; did you mean ‘writel’?
> [-Werror=implicit-function-declaration]
> 111 | #define oct_mdio_writeq(val, addr) writeq(val, (void *)addr)
> | ^~~~~~
>
> CONFIG_64BIT is not strictly necessary if the proper readq/writeq
> definitions are included from io-64-nonatomic-lo-hi.h.
>
> CONFIG_OF_MDIO is not needed when CONFIG_COMPILE_TEST is enabled because
> of commit f9dc9ac51610 ("of/mdio: Add dummy functions in of_mdio.h.").
>
> Fixes: 171a9bae68c7 ("staging/octeon: Allow test build on !MIPS")
> Reported-by: kbuild test robot <lkp@intel.com>
> Reported-by: Mark Brown <broonie@kernel.org>
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Applied to net-next.
Please make it clear what tree your changes are targetting in the future,
thank you.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: a64: Drop PMU node
From: Robin Murphy @ 2019-08-06 21:14 UTC (permalink / raw)
To: Vasily Khoruzhick, Harald Geyer
Cc: Mark Rutland, devicetree, Jared D . McNeill, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, arm-linux
In-Reply-To: <CA+E=qVdHOtebR6xjpwTY_Whp0cHLtv82YULmxLPSEzdLN9TnVg@mail.gmail.com>
On 2019-08-06 9:52 pm, Vasily Khoruzhick wrote:
> On Tue, Aug 6, 2019 at 1:19 PM Harald Geyer <harald@ccbib.org> wrote:
>>
>> Vasily Khoruzhick writes:
>>> On Tue, Aug 6, 2019 at 7:35 AM Robin Murphy <robin.murphy@arm.com> wrote:
>>>>
>>>> On 06/08/2019 15:01, Vasily Khoruzhick wrote:
>>>>> Looks like PMU in A64 is broken, it generates no interrupts at all and
>>>>> as result 'perf top' shows no events.
>>>>
>>>> Does something like 'perf stat sleep 1' at least count cycles correctly?
>>>> It could well just be that the interrupt numbers are wrong...
>>>
>>> Looks like it does, at least result looks plausible:
>>
>> I'm using perf stat regularly (cache benchmarks) and it works fine.
>>
>> Unfortunately I wasn't aware that perf stat is a poor test for
>> the interrupts part of the node, when I added it. So I'm not too
>> surprised I got it wrong.
>>
>> However, it would be unfortunate if the node got removed completely,
>> because perf stat would not work anymore. Maybe we can only remove
>> the interrupts or just fix them even if the HW doesn't work?
>
> I'm not familiar with PMU driver. Is it possible to get it working
> without interrupts?
Yup - you get a grumpy message from the driver, it will refuse sampling
events (the ones which weren't working anyway), and if you measure
anything for long enough that a counter overflows you'll get wonky
results. But for counting hardware events over relatively short periods
it'll still do the job.
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: Disable big endian builds with clang
From: Nick Desaulniers @ 2019-08-06 21:25 UTC (permalink / raw)
To: Mark Brown
Cc: Tri Vo, Catalin Marinas, clang-built-linux, Nathan Chancellor,
Will Deacon, Linux ARM
In-Reply-To: <20190806183918.41078-1-broonie@kernel.org>
On Tue, Aug 6, 2019 at 11:39 AM Mark Brown <broonie@kernel.org> wrote:
>
> Current boot tests with clang built big endian kernels in KernelCI are
> showing problems with the kernel being unable to interpret big endian
> userspace. This is a bug and should be fixed but for now let's prevent
> these kernels being built, we may end up needing to add a version
> dependency on the compiler anyway.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://github.com/ClangBuiltLinux/linux/issues/628
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
> ---
>
> The clang people (CCed) are aware and looking into this.
>
> arch/arm64/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 990fdcbf05c7..1c32d9889e0f 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -813,6 +813,7 @@ config ARM64_PA_BITS
>
> config CPU_BIG_ENDIAN
> bool "Build big-endian kernel"
> + depends on !CC_IS_CLANG
> help
> Say Y if you plan on running a kernel in big-endian mode.
>
> --
> 2.20.1
>
--
Thanks,
~Nick Desaulniers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: REGRESSION: i2c-imx endlessly triggers clk warning
From: Russell King - ARM Linux admin @ 2019-08-06 21:28 UTC (permalink / raw)
To: Aisheng Dong
Cc: Wolfram Sang, Oleksij Rempel, dl-linux-imx, Uwe Kleine-König,
Robin Gong, linux-arm-kernel@lists.infradead.org,
linux-i2c@vger.kernel.org
In-Reply-To: <AM0PR04MB4211E3811826ADCA85F0FD0280DD0@AM0PR04MB4211.eurprd04.prod.outlook.com>
Ping?
On Mon, Jul 29, 2019 at 11:28:52AM +0000, Aisheng Dong wrote:
> > From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> > Sent: Monday, July 29, 2019 7:17 PM
> >
> > Booting 5.2 on the VF610 based ZII rev B board results in the board not making
> > progress due to an endless stream of:
> >
>
> Thanks for the reporting.
>
> > [ 153.077831] ------------[ cut here ]------------ [ 153.082528] WARNING: CPU:
> > 0 PID: 15 at drivers/clk/clk.c:924 clk_core_disable_lock+0x18/0x24
> > [ 153.093077] i2c0 already disabled [ 153.096416] Modules linked in:
> > [ 153.099521] CPU: 0 PID: 15 Comm: kworker/0:1 Tainted: G W
> > 5.2.0+ #321
> > [ 153.107290] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
> > [ 153.113772] Workqueue: events deferred_probe_work_func
> > [ 153.118979] [<c0019560>] (unwind_backtrace) from [<c0014734>]
> > (show_stack+0x10/0x14) [ 153.126778] [<c0014734>] (show_stack) from
> > [<c083f8dc>] (dump_stack+0x9c/0xd4) [ 153.134051] [<c083f8dc>]
> > (dump_stack) from [<c0031154>] (__warn+0xf8/0x124) [ 153.141056]
> > [<c0031154>] (__warn) from [<c0031248>] (warn_slowpath_fmt+0x38/0x48)
> > [ 153.148580] [<c0031248>] (warn_slowpath_fmt) from [<c040fde0>]
> > (clk_core_disable_lock+0x18/0x24) [ 153.157413] [<c040fde0>]
> > (clk_core_disable_lock) from [<c058f520>] (i2c_imx_probe+0x554/0x6ec)
> > [ 153.166076] [<c058f520>] (i2c_imx_probe) from [<c04b9178>]
> > (platform_drv_probe+0x48/0x98) [ 153.174297] [<c04b9178>]
> > (platform_drv_probe) from [<c04b7298>] (really_probe+0x1d8/0x2c0)
> > [ 153.182605] [<c04b7298>] (really_probe) from [<c04b7554>]
> > (driver_probe_device+0x5c/0x174) [ 153.190909] [<c04b7554>]
> > (driver_probe_device) from [<c04b58c8>] (bus_for_each_drv+0x44/0x8c)
> > [ 153.199480] [<c04b58c8>] (bus_for_each_drv) from [<c04b746c>]
> > (__device_attach+0xa0/0x108) [ 153.207782] [<c04b746c>] (__device_attach)
> > from [<c04b65a4>] (bus_probe_device+0x88/0x90) [ 153.215999]
> > [<c04b65a4>] (bus_probe_device) from [<c04b6a04>]
> > (deferred_probe_work_func+0x60/0x90)
> > [ 153.225003] [<c04b6a04>] (deferred_probe_work_func) from [<c004f190>]
> > (process_one_work+0x204/0x634) [ 153.234178] [<c004f190>]
> > (process_one_work) from [<c004f618>] (worker_thread+0x20/0x484)
> > [ 153.242315] [<c004f618>] (worker_thread) from [<c0055c2c>]
> > (kthread+0x118/0x150) [ 153.249758] [<c0055c2c>] (kthread) from
> > [<c00090b4>] (ret_from_fork+0x14/0x20) [ 153.257006] Exception
> > stack(0xdde43fb0 to 0xdde43ff8)
> > [ 153.262095] 3fa0: 00000000
> > 00000000 00000000 00000000
> > [ 153.270306] 3fc0: 00000000 00000000 00000000 00000000 00000000
> > 00000000 00000000 00000000 [ 153.278520] 3fe0: 00000000 00000000
> > 00000000 00000000 00000013 00000000 [ 153.285159] irq event stamp:
> > 3323022 [ 153.288787] hardirqs last enabled at (3323021): [<c0861c4c>]
> > _raw_spin_unlock_irq+0x24/0x2c [ 153.297261] hardirqs last disabled at
> > (3323022): [<c040d7a0>] clk_enable_lock+0x10/0x124 [ 153.305392]
> > softirqs last enabled at (3322092): [<c000a504>] __do_softirq+0x344/0x540
> > [ 153.313352] softirqs last disabled at (3322081): [<c00385c0>]
> > irq_exit+0x10c/0x128 [ 153.320946] ---[ end trace a506731ccd9bd703 ]---
> >
> > My guess is that this is due to a combination of e1ab9a468e3b ("i2c:
> > imx: improve the error handling in i2c_imx_dma_request()") and the fact that
> > my configuration has CONFIG_FSL_EDMA=m. Given that the boot makes no
> > progress, it seems that this driver now requires EDMA to be built-in _if_ this
> > driver is also built in. It seems that Kconfig allows an invalid configuration as
> > far as the driver is concerned.
> >
> > However, even though it seems that EDMA needs to be built-in with 5.2, this
> > should not trigger the above kernel warning, which suggests something is
> > wrong in the driver cleanup paths.
>
> Copy Yibin to check the possible edma issue.
>
> Regards
> Aisheng
>
> >
> > --
> > RMK's Patch system:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ar
> > mlinux.org.uk%2Fdeveloper%2Fpatches%2F&data=02%7C01%7Caisheng.
> > dong%40nxp.com%7Ce3e704d7d9414e860c7a08d714165ebc%7C686ea1d3b
> > c2b4c6fa92cd99c5c301635%7C0%7C0%7C636999958630559001&sdata
> > =2d2Ti0gMN2vi7n4hPrsPZ2jGw3kqScStqPzpI%2BiEOXY%3D&reserved=0
> > FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps
> > up According to speedtest.net: 11.9Mbps down 500kbps up
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH] ARM: UNWINDER_FRAME_POINTER implementation for Clang
From: Nathan Huckleberry @ 2019-08-06 21:29 UTC (permalink / raw)
To: Dave Martin
Cc: Tri Vo, linux, linux-kernel, clang-built-linux, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20190805133940.GA10425@arm.com>
I'm not sure that we should disable a broken feature instead of
attempting a fix.
CONFIG_FUNCTION_GRAPH_TRACER is dependent on CONFIG_FRAME_POINTER and
there have been reports by MediaTek that the frame pointer unwinder is
faster in some cases.
On Mon, Aug 5, 2019 at 6:39 AM Dave Martin <Dave.Martin@arm.com> wrote:
>
> On Fri, Aug 02, 2019 at 10:27:30AM -0700, Nathan Huckleberry wrote:
> > You're right. Would pushing an extra register be an adequate fix?
>
> Would forcing CONFIG_ARM_UNWIND=y for clang work as an alternative to
> this?
>
> Assuming clang supports -funwind-tables or equivalent, this may just
> work.
>
> [...]
>
> Cheers
> ---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/6] hwspinlock: allow sharing of hwspinlocks
From: Suman Anna @ 2019-08-06 21:30 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Ohad Ben-Cohen, Mark Rutland, Alexandre TORGUE, Jonathan Corbet,
linux-doc@vger.kernel.org, linux-remoteproc@vger.kernel.org,
linux-kernel@vger.kernel.org, Fabien DESSENNE,
devicetree@vger.kernel.org, Rob Herring, Maxime Coquelin,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, Benjamin GAIGNARD
In-Reply-To: <20190806182128.GD26807@tuxbook-pro>
On 8/6/19 1:21 PM, Bjorn Andersson wrote:
> On Tue 06 Aug 10:38 PDT 2019, Suman Anna wrote:
>
>> Hi Fabien,
>>
>> On 8/5/19 12:46 PM, Bjorn Andersson wrote:
>>> On Mon 05 Aug 01:48 PDT 2019, Fabien DESSENNE wrote:
>>>
>>>>
>>>> On 01/08/2019 9:14 PM, Bjorn Andersson wrote:
>>>>> On Wed 13 Mar 08:50 PDT 2019, Fabien Dessenne wrote:
> [..]
>>>> B/ This would introduce some inconsistency between the two 'request' API
>>>> which are hwspin_lock_request() and hwspin_lock_request_specific().
>>>> hwspin_lock_request() looks for an unused lock, so requests for an exclusive
>>>> usage. On the other side, request_specific() would request shared locks.
>>>> Worst the following sequence can transform an exclusive usage into a shared
>>>>
>>>
>>> There is already an inconsistency in between these; as with above any
>>> system that uses both request() and request_specific() will be suffering
>>> from intermittent failures due to probe ordering.
>>>
>>>> one:
>>>> -hwspin_lock_request() -> returns Id#0 (exclusive)
>>>> -hwspin_lock_request() -> returns Id#1 (exclusive)
>>>> -hwspin_lock_request_specific(0) -> returns Id#0 and makes Id#0 shared
>>>> Honestly I am not sure that this is a real issue, but it's better to have it
>>>> in mind before we take ay decision
>>
>> Wouldn't it be actually simpler to just introduce a new specific API
>> variant for this, similar to the reset core for example (it uses a
>> separate exclusive API), without having to modify the bindings at all.
>> It is just a case of your driver using the right API, and the core can
>> be modified to use the additional tag semantics based on the API. It
>> should avoid any confusion with say using a different second cell value
>> for the same lock in two different nodes.
>>
>
> But this implies that there is an actual need to hold these locks
> exclusively. Given that they are (except for the raw case) all wrapped
> by Linux locking primitives there shouldn't be a problem sharing a lock
> (except possibly for the raw case).
Yes agreed, the HWLOCK_RAW and HWLOCK_IN_ATOMIC cases are unprotected. I
am still trying to understand better the usecase to see if the same lock
is being multiplexed for different protection contexts, or if all of
them are protecting the same context.
>
> I agree that we shouldn't specify this property in DT - if anything it
> should be a variant of the API.
>
>> If you are sharing a hwlock on the Linux side, surely your driver should
>> be aware that it is a shared lock. The tag can be set during the first
>> request API, and you look through both tags when giving out a handle.
>>
>
> Why would the driver need to know about it?
Just the semantics if we were to support single user vs multiple users
on Linux-side to even get a handle. Your point is that this may be moot
since we have protection anyway other than the raw cases. But we need to
be able to have the same API work across all cases.
So far, it had mostly been that there would be one user on Linux
competing with other equivalent peer entities on different processors.
It is not common to have multiple users since these protection schemes
are usually needed only at the lowest levels of a stack, so the
exclusive handle stuff had been sufficient.
>
>> Obviously, the hwspin_lock_request() API usage semantics always had the
>> implied additional need for communicating the lock id to the other peer
>> entity, so a realistic usage is most always the specific API variant. I
>> doubt this API would be of much use for the shared driver usage. This
>> also implies that the client user does not care about specifying a lock
>> in DT.
>>
>
> Afaict if the lock are shared then there shouldn't be a problem with
> some clients using the request API and others request_specific(). As any
> collisions would simply mean that there are more contention on the lock.
>
> With the current exclusive model that is not possible and the success of
> the request_specific will depend on probe order.
>
> But perhaps it should be explicitly prohibited to use both APIs on the
> same hwspinlock instance?
Yeah, they are meant to be complimentary usage, though I doubt we will
ever have any realistic users for the generic API if we haven't had a
usage so far. I had posted a concept of reserved locks long back [1] to
keep away certain locks from the generic requestor, but dropped it since
we did not have an actual use-case needing it.
regards
Suman
[1] https://lwn.net/Articles/611944/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH 0/3] Add basic support for RTC on Allwinner H6 SoC
From: Ondřej Jirman @ 2019-08-06 22:27 UTC (permalink / raw)
To: Chen-Yu Tsai, Mark Rutland, Alessandro Zummo, Alexandre Belloni,
devicetree, Maxime Ripard, linux-kernel, linux-sunxi, Rob Herring,
linux-arm-kernel, linux-rtc
In-Reply-To: <20190806183045.edhm3qzpegscf2z7@core.my.home>
On Tue, Aug 06, 2019 at 08:30:45PM +0200, megous hlavni wrote:
> On Mon, Apr 15, 2019 at 04:18:12PM +0800, Chen-Yu Tsai wrote:
> > On Fri, Apr 12, 2019 at 8:07 PM megous via linux-sunxi
> > <linux-sunxi@googlegroups.com> wrote:
> > >
> > > From: Ondrej Jirman <megous@megous.com>
> > >
> > > I went through the datasheets for H6 and H5, and compared the differences.
> > > RTCs are largely similar, but not entirely compatible. Incompatibilities
> > > are in details not yet implemented by the rtc driver though.
> > >
> > > I also corrected the clock tree in H6 DTSI.
> >
> > Please also add DCXO clock input/output and XO clock input to the bindings
> > and DT, and also fix up the clock tree. You can skip them in the driver for
> > now, but please add a TODO. As long as you don't change the clock-output-name
> > of osc24M, everything should work as before.
> >
> > We just want the DT to describe what is actually there. For the XO input,
> > you could just directly reference the external crystal node. The gate for
> > it is likely somewhere in the PRCM block, which we don't have docs for.
>
> So I was thinking about this for a while, and came up with this:
>
> ----------------- arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi -----------------
> index 64c39f663d22..ac99ddbebe5c 100644
> @@ -627,14 +635,15 @@
>
> rtc: rtc@7000000 {
> compatible = "allwinner,sun50i-h6-rtc";
> reg = <0x07000000 0x400>;
> interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
> - clock-output-names = "osc32k", "osc32k-out", "iosc";
> - clocks = <&ext_osc32k>;
> + clock-output-names = "osc32k", "osc32k-out", "iosc", "hosc";
> + clock-names = "losc", "dcxo";
> + clocks = <&ext_osc32k>, <&osc24M>;
> #clock-cells = <1>;
> };
>
> r_ccu: clock@7010000 {
> compatible = "allwinner,sun50i-h6-r-ccu";
> reg = <0x07010000 0x400>;
>
> I'm not completely sure how (or why?) to describe in DTSI which oscillator the
> designer used (XO vs DCXO). This information is signalled by the pad voltage and
> can be determined at runtime from DCXO_CTRL_REG's OSC_CLK_SRC_SEL (bit 3). It's
> not possible to change at runtime.
>
> HOSC source selection is only material to the CPUS (ARISC) firmware when it
> wants to turn off all PLLs and the main crystal oscillator so that it knows
> which one to turn off. I don't see any other use for it. It's just
> informational. I don't think (future) crust firmware has space to be reading
> DTBs, so the detection will be using OSC_CLK_SRC_SEL anyway.
>
> Maybe whether XO or DCXO is used also matters if you want to do some fine
> tunning of DCXO (control register has pletny of options), but that's probably
> better done in u-boot. And there's still no need to read HOSC source from DT.
> The driver can just check compatible, and if it is H6 and OSC_CLK_SRC_SEL is 1,
> it can do it's DCXO tunning, or whatever. But neither OS nor bootloader will
> be using this info to gate/disable the osciallator.
>
> If we really want this in DT, maybe we can model it by having just two input
> clocks to RTC described in DTSI, and the DTSI for H6 would have this by default:
>
> clock-names = "losc", "dcxo";
> clocks = <&ext_osc32k>, <&osc24M>;
>
> And the board designer could change it from a board file, like this:
>
> &rtc {
> clock-names = "losc", "xo";
> clocks = <&ext_osc32k>, <&osc24M>;
> };
>
> The driver could decide which oscillator is used by the presence of either
> dcxo or xo input clock.
>
> But in any case, the driver can also get this info from DCXO_CTRL_REG's
> OSC_CLK_SRC_SEL, so it doesn't need to read this from DT at all. So it's a bit
> pointless.
>
> So I see two options:
>
> 1) skip adding dcxo/xo to input clocks of RTC completely
> 2) the above
>
> What do you think?
I tried option 2) and it feels pointless. It just creates this clock tree:
osc24M
hosc
plls...
from:
osc24M
plls...
and doesn't achieve anything else, other than complicating things, for no reason
because no driver will ever need or use this info from the DT.
So my preference is for keeping it simple and going with option 1).
regards,
o.
> regards,
> o.
>
>
> > > There's a small detail here, that's not described absolutely correctly in
> > > DTSI, but the difference is not really that material. ext_osc32k is
> > > originally modelled as a fixed clock that feeds into RTC module, but in
> > > reality it's the RTC module that implements via its registers enabling and
> > > disabling of this oscillator/clock.
> > >
> > > Though:
> > > - there's no other possible user of ext_osc32k than RTC module
> > > - there's no other possible external configuration for the crystal
> > > circuit that would need to be handled in the dts per board
> > >
> > > So I guess, while the description is not perfect, this patch series still
> > > improves the current situation. Or maybe I'm misunderstanding something,
> > > and &ext_osc32k node just describes a fact that there's a crystal on
> > > the board. Then, everything is perhaps fine. :)
> >
> > Correct. The external clock nodes are modeling the crystal, not the internal
> > clock gate / distributor.
> >
> > Were the vendor to not include the crystal (for whatever reasons), the DT
> > should be able to describe it via the absence of the clock input, and the
> > driver should correctly use the internal (inaccurate) oscillator. I realize
> > the clocks property is required, and the driver doesn't handle this case
> > either, so we might have to fix that if it were to appear in the wild.
> >
> > > For now, the enable bit for this oscillator is toggled by the re-parenting
> > > code automatically, as needed.
> >
> > That's fine. No need to increase the clock tree depth.
> >
> > ChenYu
> >
> > > This patchset is necessary for implementing the WiFi/Bluetooth support
> > > on boards using H6 SoC.
> > >
> > > Please take a look.
> > >
> > > Thank you and regards,
> > > Ondrej Jirman
> > >
> > > Ondrej Jirman (3):
> > > dt-bindings: Add compatible for H6 RTC
> > > rtc: sun6i: Add support for H6 RTC
> > > arm64: dts: sun50i-h6: Add support for RTC and fix the clock tree
> > >
> > > .../devicetree/bindings/rtc/sun6i-rtc.txt | 1 +
> > > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 30 +++++++-------
> > > drivers/rtc/rtc-sun6i.c | 40 ++++++++++++++++++-
> > > 3 files changed, 55 insertions(+), 16 deletions(-)
> > >
> > > --
> > > 2.21.0
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> > > For more options, visit https://groups.google.com/d/optout.
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: Disable big endian builds with clang
From: Nick Desaulniers @ 2019-08-06 23:47 UTC (permalink / raw)
To: Mark Brown
Cc: Tri Vo, Catalin Marinas, Nathan Huckleberry, clang-built-linux,
Nathan Chancellor, Will Deacon, Linux ARM
In-Reply-To: <CAKwvOdkvFowCWP6cpKoMOz+EWojBXJWs3TzuTvn4180sVu4ayw@mail.gmail.com>
On Tue, Aug 6, 2019 at 2:25 PM Nick Desaulniers <ndesaulniers@google.com> wrote:
>
> On Tue, Aug 6, 2019 at 11:39 AM Mark Brown <broonie@kernel.org> wrote:
> >
> > Current boot tests with clang built big endian kernels in KernelCI are
> > showing problems with the kernel being unable to interpret big endian
> > userspace. This is a bug and should be fixed but for now let's prevent
> > these kernels being built, we may end up needing to add a version
> > dependency on the compiler anyway.
> >
> > Signed-off-by: Mark Brown <broonie@kernel.org>
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/628
> Acked-by: Nick Desaulniers <ndesaulniers@google.com>
+Huck
Huck notes that the device eventually boots in qemu, it just takes on
the order of 165 seconds to boot. What's the timeout on KernelCI?
I think if we can determine why we see:
[ 144.626755] request_module: kmod_concurrent_max (0) close to 0
(max_modprobes: 50), for module binfmt-4c46, throttling...
[ 149.752826] request_module: modprobe binfmt-4c46 cannot be
processed, kmod busy with 50 threads for more than 5 seconds now
a lot, then we don't actually need to disable this outright when
building w/ Clang?
>
> > ---
> >
> > The clang people (CCed) are aware and looking into this.
> >
> > arch/arm64/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 990fdcbf05c7..1c32d9889e0f 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -813,6 +813,7 @@ config ARM64_PA_BITS
> >
> > config CPU_BIG_ENDIAN
> > bool "Build big-endian kernel"
> > + depends on !CC_IS_CLANG
> > help
> > Say Y if you plan on running a kernel in big-endian mode.
--
Thanks,
~Nick Desaulniers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v10 20/22] x86: mm: Convert dump_pagetables to use walk_page_range
From: Andrew Morton @ 2019-08-06 23:58 UTC (permalink / raw)
To: Steven Price
Cc: Mark Rutland, x86, Arnd Bergmann, Ard Biesheuvel, Peter Zijlstra,
Catalin Marinas, Dave Hansen, linux-kernel, linux-mm,
Jérôme Glisse, Ingo Molnar, Borislav Petkov,
Andy Lutomirski, H. Peter Anvin, James Morse, Thomas Gleixner,
Will Deacon, linux-arm-kernel, Liang, Kan
In-Reply-To: <20190731154603.41797-21-steven.price@arm.com>
On Wed, 31 Jul 2019 16:46:01 +0100 Steven Price <steven.price@arm.com> wrote:
> Make use of the new functionality in walk_page_range to remove the
> arch page walking code and use the generic code to walk the page tables.
>
> The effective permissions are passed down the chain using new fields
> in struct pg_state.
>
> The KASAN optimisation is implemented by including test_p?d callbacks
> which can decide to skip an entire tree of entries
>
> ...
>
> +static const struct ptdump_range ptdump_ranges[] = {
> +#ifdef CONFIG_X86_64
>
> -#define pgd_large(a) (pgtable_l5_enabled() ? pgd_large(a) : p4d_large(__p4d(pgd_val(a))))
> -#define pgd_none(a) (pgtable_l5_enabled() ? pgd_none(a) : p4d_none(__p4d(pgd_val(a))))
> +#define normalize_addr_shift (64 - (__VIRTUAL_MASK_SHIFT + 1))
> +#define normalize_addr(u) ((signed long)(u << normalize_addr_shift) \
> + >> normalize_addr_shift)
>
> -static inline bool is_hypervisor_range(int idx)
> -{
> -#ifdef CONFIG_X86_64
> - /*
> - * A hole in the beginning of kernel address space reserved
> - * for a hypervisor.
> - */
> - return (idx >= pgd_index(GUARD_HOLE_BASE_ADDR)) &&
> - (idx < pgd_index(GUARD_HOLE_END_ADDR));
> + {0, PTRS_PER_PGD * PGD_LEVEL_MULT / 2},
> + {normalize_addr(PTRS_PER_PGD * PGD_LEVEL_MULT / 2), ~0UL},
This blows up because PGD_LEVEL_MULT is sometimes not a constant.
x86_64 allmodconfig:
In file included from ./arch/x86/include/asm/pgtable_types.h:249:0,
from ./arch/x86/include/asm/paravirt_types.h:45,
from ./arch/x86/include/asm/ptrace.h:94,
from ./arch/x86/include/asm/math_emu.h:5,
from ./arch/x86/include/asm/processor.h:12,
from ./arch/x86/include/asm/cpufeature.h:5,
from ./arch/x86/include/asm/thread_info.h:53,
from ./include/linux/thread_info.h:38,
from ./arch/x86/include/asm/preempt.h:7,
from ./include/linux/preempt.h:78,
from ./include/linux/spinlock.h:51,
from ./include/linux/wait.h:9,
from ./include/linux/wait_bit.h:8,
from ./include/linux/fs.h:6,
from ./include/linux/debugfs.h:15,
from arch/x86/mm/dump_pagetables.c:11:
./arch/x86/include/asm/pgtable_64_types.h:56:22: error: initializer element is not constant
#define PTRS_PER_PGD 512
^
arch/x86/mm/dump_pagetables.c:363:6: note: in expansion of macro ‘PTRS_PER_PGD’
{0, PTRS_PER_PGD * PGD_LEVEL_MULT / 2},
^~~~~~~~~~~~
./arch/x86/include/asm/pgtable_64_types.h:56:22: note: (near initialization for ‘ptdump_ranges[0].end’)
#define PTRS_PER_PGD 512
^
arch/x86/mm/dump_pagetables.c:363:6: note: in expansion of macro ‘PTRS_PER_PGD’
{0, PTRS_PER_PGD * PGD_LEVEL_MULT / 2},
^~~~~~~~~~~~
arch/x86/mm/dump_pagetables.c:360:27: error: initializer element is not constant
#define normalize_addr(u) ((signed long)(u << normalize_addr_shift) \
^
arch/x86/mm/dump_pagetables.c:364:3: note: in expansion of macro ‘normalize_addr’
{normalize_addr(PTRS_PER_PGD * PGD_LEVEL_MULT / 2), ~0UL},
^~~~~~~~~~~~~~
arch/x86/mm/dump_pagetables.c:360:27: note: (near initialization for ‘ptdump_ranges[1].start’)
#define normalize_addr(u) ((signed long)(u << normalize_addr_shift) \
^
arch/x86/mm/dump_pagetables.c:364:3: note: in expansion of macro ‘normalize_addr’
{normalize_addr(PTRS_PER_PGD * PGD_LEVEL_MULT / 2), ~0UL},
I don't know what to do about this so I'll drop the series.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/3] arm/arm64: Add support for function error injection
From: Masami Hiramatsu @ 2019-08-07 0:08 UTC (permalink / raw)
To: Leo Yan
Cc: Song Liu, Catalin Marinas, Alexei Starovoitov, Oleg Nesterov,
Paul Mackerras, H. Peter Anvin, Will Deacon, linux-arch,
Daniel Borkmann, Michael Ellerman, x86, Russell King,
clang-built-linux, Ingo Molnar, Benjamin Herrenschmidt,
Yonghong Song, Naveen N. Rao, Arnd Bergmann, Borislav Petkov,
Thomas Gleixner, linux-arm-kernel, netdev, linux-kernel, bpf,
linuxppc-dev, Martin KaFai Lau
In-Reply-To: <20190806100015.11256-1-leo.yan@linaro.org>
On Tue, 6 Aug 2019 18:00:12 +0800
Leo Yan <leo.yan@linaro.org> wrote:
> This small patch set is to add support for function error injection;
> this can be used to eanble more advanced debugging feature, e.g.
> CONFIG_BPF_KPROBE_OVERRIDE.
>
> The patch 01/03 is to consolidate the function definition which can be
> suared cross architectures, patches 02,03/03 are used for enabling
> function error injection on arm64 and arm architecture respectively.
>
> I tested on arm64 platform Juno-r2 and one of my laptop with x86
> architecture with below steps; I don't test for Arm architecture so
> only pass compilation.
>
> - Enable kernel configuration:
> CONFIG_BPF_KPROBE_OVERRIDE
> CONFIG_BTRFS_FS
> CONFIG_BPF_EVENTS=y
> CONFIG_KPROBES=y
> CONFIG_KPROBE_EVENTS=y
> CONFIG_BPF_KPROBE_OVERRIDE=y
>
> - Build samples/bpf on with Debian rootFS:
> # cd $kernel
> # make headers_install
> # make samples/bpf/ LLC=llc-7 CLANG=clang-7
>
> - Run the sample tracex7:
> # dd if=/dev/zero of=testfile.img bs=1M seek=1000 count=1
> # DEVICE=$(losetup --show -f testfile.img)
> # mkfs.btrfs -f $DEVICE
> # ./tracex7 testfile.img
> [ 1975.211781] BTRFS error (device (efault)): open_ctree failed
> mount: /mnt/linux-kernel/linux-cs-dev/samples/bpf/tmpmnt: mount(2) system call failed: Cannot allocate memory.
>
> Changes from v1:
> * Consolidated the function definition into asm-generic header (Will);
> * Used APIs to access pt_regs elements (Will);
> * Fixed typos in the comments (Will).
This looks good to me.
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Thank you!
>
>
> Leo Yan (3):
> error-injection: Consolidate override function definition
> arm64: Add support for function error injection
> arm: Add support for function error injection
>
> arch/arm/Kconfig | 1 +
> arch/arm/include/asm/ptrace.h | 5 +++++
> arch/arm/lib/Makefile | 2 ++
> arch/arm/lib/error-inject.c | 19 +++++++++++++++++++
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/ptrace.h | 5 +++++
> arch/arm64/lib/Makefile | 2 ++
> arch/arm64/lib/error-inject.c | 18 ++++++++++++++++++
> arch/powerpc/include/asm/error-injection.h | 13 -------------
> arch/x86/include/asm/error-injection.h | 13 -------------
> include/asm-generic/error-injection.h | 6 ++++++
> include/linux/error-injection.h | 6 +++---
> 12 files changed, 62 insertions(+), 29 deletions(-)
> create mode 100644 arch/arm/lib/error-inject.c
> create mode 100644 arch/arm64/lib/error-inject.c
> delete mode 100644 arch/powerpc/include/asm/error-injection.h
> delete mode 100644 arch/x86/include/asm/error-injection.h
>
> --
> 2.17.1
>
--
Masami Hiramatsu <mhiramat@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: mm: print hexadecimal EC value in mem_abort_decode()
From: Miles Chen @ 2019-08-07 0:29 UTC (permalink / raw)
To: Mark Rutland
Cc: wsd_upstream, Anshuman Khandual, Catalin Marinas, Will Deacon,
linux-kernel, linux-mediatek, James Morse, linux-arm-kernel
In-Reply-To: <20190806123450.GE475@lakrids.cambridge.arm.com>
On Tue, 2019-08-06 at 13:34 +0100, Mark Rutland wrote:
> On Tue, Aug 06, 2019 at 07:29:48PM +0800, Miles Chen wrote:
> > This change prints the hexadecimal EC value in mem_abort_decode(),
> > which makes it easier to lookup the corresponding EC in
> > the ARM Architecture Reference Manual.
> >
> > The commit 1f9b8936f36f ("arm64: Decode information from ESR upon mem
> > faults") prints useful information when memory abort occurs. It would
> > be easier to lookup "0x25" instead of "DABT" in the document. Then we
> > can check the corresponding ISS.
> >
> > For example:
> > Current info Document
> > EC Exception class
> > "CP15 MCR/MRC" 0x3 "MCR or MRC access to CP15a..."
> > "ASIMD" 0x7 "Access to SIMD or floating-point..."
> > "DABT (current EL)" 0x25 "Data Abort taken without..."
> > ...
> >
> > Before:
> > Unable to handle kernel paging request at virtual address 000000000000c000
> > Mem abort info:
> > ESR = 0x96000046
> > Exception class = DABT (current EL), IL = 32 bits
> > SET = 0, FnV = 0
> > EA = 0, S1PTW = 0
> > Data abort info:
> > ISV = 0, ISS = 0x00000046
> > CM = 0, WnR = 1
> >
> > After:
> > Unable to handle kernel paging request at virtual address 000000000000c000
> > Mem abort info:
> > ESR = 0x96000046
> > EC = 0x25, Exception class = DABT (current EL), IL = 32 bits
> > SET = 0, FnV = 0
> > EA = 0, S1PTW = 0
> > Data abort info:
> > ISV = 0, ISS = 0x00000046
> > CM = 0, WnR = 1
> >
> > Cc: Mark Rutland <Mark.rutland@arm.com>
> > Cc: Anshuman Khandual <anshuman.khandual@arm.com>
> > Cc: James Morse <james.morse@arm.com>
> > Signed-off-by: Miles Chen <miles.chen@mediatek.com>
> > ---
> > arch/arm64/mm/fault.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> > index cfd65b63f36f..afb6041e25e6 100644
> > --- a/arch/arm64/mm/fault.c
> > +++ b/arch/arm64/mm/fault.c
> > @@ -86,8 +86,8 @@ static void mem_abort_decode(unsigned int esr)
> > pr_alert("Mem abort info:\n");
> >
> > pr_alert(" ESR = 0x%08x\n", esr);
> > - pr_alert(" Exception class = %s, IL = %u bits\n",
> > - esr_get_class_string(esr),
> > + pr_alert(" EC = 0x%lx, Exception class = %s, IL = %u bits\n",
> > + ESR_ELx_EC(esr), esr_get_class_string(esr),
>
> Could we make this:
>
> pr_alert(" EC = 0x%02lx: %s, IL = %u bits\n",
> ESR_ELx_EC(esr), esr_get_class_string(esr));
>
> We don't need to spell out "Exception Class" if we say "EC", and we
> should print the EC hex value with a consistent width as we do for the
> ISS.
Thanks for the advise.
It looks better this way. I'll send patch v2.
Miles
>
> With that:
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
>
> Thanks,
> Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] pinctrl: aspeed: g6: Remove const specifier from aspeed_g6_sig_expr_set's ctx parameter
From: Nathan Chancellor @ 2019-08-07 0:30 UTC (permalink / raw)
To: Andrew Jeffery, Linus Walleij
Cc: linux-aspeed, clang-built-linux, openbmc, linux-kernel,
linux-gpio, Joel Stanley, Nathan Chancellor, linux-arm-kernel
clang errors:
drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c:2325:9: error: incompatible
pointer types initializing 'int (*)(struct aspeed_pinmux_data *, const
struct aspeed_sig_expr *, bool)' with an expression of type 'int (const
struct aspeed_pinmux_data *, const struct aspeed_sig_expr *, bool)'
[-Werror,-Wincompatible-pointer-types]
.set = aspeed_g6_sig_expr_set,
^~~~~~~~~~~~~~~~~~~~~~
1 error generated.
Commit 674fa8daa8c9 ("pinctrl: aspeed-g5: Delay acquisition of regmaps")
changed the set function pointer declaration and the g6 one wasn't
updated (I assume because it wasn't merged yet).
Fixes: 2eda1cdec49f ("pinctrl: aspeed: Add AST2600 pinmux support")
Link: https://github.com/ClangBuiltLinux/linux/issues/632
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
index 6012d7d4a22a..648ddb7f038a 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
@@ -2267,7 +2267,7 @@ static const struct aspeed_pin_function aspeed_g6_functions[] = {
* Return: 0 if the expression is configured as requested and a negative error
* code otherwise
*/
-static int aspeed_g6_sig_expr_set(const struct aspeed_pinmux_data *ctx,
+static int aspeed_g6_sig_expr_set(struct aspeed_pinmux_data *ctx,
const struct aspeed_sig_expr *expr,
bool enable)
{
--
2.23.0.rc1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2] arm64: mm: print hexadecimal EC value in mem_abort_decode()
From: Miles Chen @ 2019-08-07 0:33 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Rutland, wsd_upstream, Anshuman Khandual, linux-kernel,
Miles Chen, linux-mediatek, James Morse, linux-arm-kernel
This change prints the hexadecimal EC value in mem_abort_decode(),
which makes it easier to lookup the corresponding EC in
the ARM Architecture Reference Manual.
The commit 1f9b8936f36f ("arm64: Decode information from ESR upon mem
faults") prints useful information when memory abort occurs. It would
be easier to lookup "0x25" instead of "DABT" in the document. Then we
can check the corresponding ISS.
For example:
Current info Document
EC Exception class
"CP15 MCR/MRC" 0x3 "MCR or MRC access to CP15a..."
"ASIMD" 0x7 "Access to SIMD or floating-point..."
"DABT (current EL)" 0x25 "Data Abort taken without..."
...
Before:
Unable to handle kernel paging request at virtual address 000000000000c000
Mem abort info:
ESR = 0x96000046
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000046
CM = 0, WnR = 1
After:
Unable to handle kernel paging request at virtual address 000000000000c000
Mem abort info:
ESR = 0x96000046
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000046
CM = 0, WnR = 1
Change since v1:
print "EC" instead of "Exception class"
print EC in fixwidth
Cc: Mark Rutland <Mark.rutland@arm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: James Morse <james.morse@arm.com>
Signed-off-by: Miles Chen <miles.chen@mediatek.com>
---
arch/arm64/mm/fault.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index cfd65b63f36f..ad4980a27edb 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -86,8 +86,8 @@ static void mem_abort_decode(unsigned int esr)
pr_alert("Mem abort info:\n");
pr_alert(" ESR = 0x%08x\n", esr);
- pr_alert(" Exception class = %s, IL = %u bits\n",
- esr_get_class_string(esr),
+ pr_alert(" EC = 0x%02lx: %s, IL = %u bits\n",
+ ESR_ELx_EC(esr), esr_get_class_string(esr),
(esr & ESR_ELx_IL) ? 32 : 16);
pr_alert(" SET = %lu, FnV = %lu\n",
(esr & ESR_ELx_SET_MASK) >> ESR_ELx_SET_SHIFT,
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] pinctrl: aspeed: g6: Remove const specifier from aspeed_g6_sig_expr_set's ctx parameter
From: Andrew Jeffery @ 2019-08-07 0:36 UTC (permalink / raw)
To: Nathan Chancellor, Linus Walleij
Cc: linux-aspeed, clang-built-linux, openbmc, linux-kernel,
linux-gpio, Joel Stanley, linux-arm-kernel
In-Reply-To: <20190807003037.48457-1-natechancellor@gmail.com>
On Wed, 7 Aug 2019, at 10:02, Nathan Chancellor wrote:
> clang errors:
>
> drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c:2325:9: error: incompatible
> pointer types initializing 'int (*)(struct aspeed_pinmux_data *, const
> struct aspeed_sig_expr *, bool)' with an expression of type 'int (const
> struct aspeed_pinmux_data *, const struct aspeed_sig_expr *, bool)'
> [-Werror,-Wincompatible-pointer-types]
> .set = aspeed_g6_sig_expr_set,
> ^~~~~~~~~~~~~~~~~~~~~~
> 1 error generated.
>
> Commit 674fa8daa8c9 ("pinctrl: aspeed-g5: Delay acquisition of regmaps")
> changed the set function pointer declaration and the g6 one wasn't
> updated (I assume because it wasn't merged yet).
>
> Fixes: 2eda1cdec49f ("pinctrl: aspeed: Add AST2600 pinmux support")
> Link: https://github.com/ClangBuiltLinux/linux/issues/632
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
That's exactly what happened. Thanks.
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 0/2] mmc: Add support for the ASPEED SD controller
From: Andrew Jeffery @ 2019-08-07 0:36 UTC (permalink / raw)
To: linux-mmc
Cc: mark.rutland, devicetree, ulf.hansson, linux-aspeed,
Andrew Jeffery, ryanchen.aspeed, adrian.hunter, linux-kernel,
robh+dt, joel, linux-arm-kernel
Hello,
v5 of the ASPEED SDHCI patches fixes an error-path cleanup issue pointed out by
Adrian.
v4 can be found here:
http://patchwork.ozlabs.org/cover/1141949/
Please review!
Andrew
Andrew Jeffery (2):
dt-bindings: mmc: Document Aspeed SD controller
mmc: Add support for the ASPEED SD controller
.../devicetree/bindings/mmc/aspeed,sdhci.yaml | 105 ++++++
drivers/mmc/host/Kconfig | 12 +
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/sdhci-of-aspeed.c | 332 ++++++++++++++++++
4 files changed, 450 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
create mode 100644 drivers/mmc/host/sdhci-of-aspeed.c
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 1/2] dt-bindings: mmc: Document Aspeed SD controller
From: Andrew Jeffery @ 2019-08-07 0:36 UTC (permalink / raw)
To: linux-mmc
Cc: mark.rutland, devicetree, ulf.hansson, linux-aspeed,
Andrew Jeffery, ryanchen.aspeed, adrian.hunter, linux-kernel,
robh+dt, joel, linux-arm-kernel
In-Reply-To: <20190807003629.2974-1-andrew@aj.id.au>
The ASPEED SD/SDIO/MMC controller exposes two slots implementing the
SDIO Host Specification v2.00, with 1 or 4 bit data buses, or an 8 bit
data bus if only a single slot is enabled.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---
v4:
* Make use of mmc-controller.yaml
* Document sdhci,auto-cmd12
v2:
* Fix compatible enums
* Add AST2600 compatibles
* Describe #address-cells / #size-cells
---
.../devicetree/bindings/mmc/aspeed,sdhci.yaml | 105 ++++++++++++++++++
1 file changed, 105 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
diff --git a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
new file mode 100644
index 000000000000..570f8c72662b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
@@ -0,0 +1,105 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/aspeed,sdhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED SD/SDIO/MMC Controller
+
+maintainers:
+ - Andrew Jeffery <andrew@aj.id.au>
+ - Ryan Chen <ryanchen.aspeed@gmail.com>
+
+description: |+
+ The ASPEED SD/SDIO/eMMC controller exposes two slots implementing the SDIO
+ Host Specification v2.00, with 1 or 4 bit data buses, or an 8 bit data bus if
+ only a single slot is enabled.
+
+ The two slots are supported by a common configuration area. As the SDHCIs for
+ the slots are dependent on the common configuration area, they are described
+ as child nodes.
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2400-sd-controller
+ - aspeed,ast2500-sd-controller
+ - aspeed,ast2600-sd-controller
+ reg:
+ maxItems: 1
+ description: Common configuration registers
+ "#address-cells":
+ const: 1
+ "#size-cells":
+ const: 1
+ ranges: true
+ clocks:
+ maxItems: 1
+ description: The SD/SDIO controller clock gate
+
+patternProperties:
+ "^sdhci@[0-9a-f]+$":
+ type: object
+ allOf:
+ - $ref: mmc-controller.yaml
+ properties:
+ compatible:
+ enum:
+ - aspeed,ast2400-sdhci
+ - aspeed,ast2500-sdhci
+ - aspeed,ast2600-sdhci
+ reg:
+ maxItems: 1
+ description: The SDHCI registers
+ clocks:
+ maxItems: 1
+ description: The SD bus clock
+ interrupts:
+ maxItems: 1
+ description: The SD interrupt shared between both slots
+ sdhci,auto-cmd12:
+ type: boolean
+ description: Specifies that controller should use auto CMD12
+ required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+ - clocks
+
+examples:
+ - |
+ #include <dt-bindings/clock/aspeed-clock.h>
+ sdc@1e740000 {
+ compatible = "aspeed,ast2500-sd-controller";
+ reg = <0x1e740000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x1e740000 0x10000>;
+ clocks = <&syscon ASPEED_CLK_GATE_SDCLK>;
+
+ sdhci0: sdhci@100 {
+ compatible = "aspeed,ast2500-sdhci";
+ reg = <0x100 0x100>;
+ interrupts = <26>;
+ sdhci,auto-cmd12;
+ clocks = <&syscon ASPEED_CLK_SDIO>;
+ };
+
+ sdhci1: sdhci@200 {
+ compatible = "aspeed,ast2500-sdhci";
+ reg = <0x200 0x100>;
+ interrupts = <26>;
+ sdhci,auto-cmd12;
+ clocks = <&syscon ASPEED_CLK_SDIO>;
+ };
+ };
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 2/2] mmc: Add support for the ASPEED SD controller
From: Andrew Jeffery @ 2019-08-07 0:36 UTC (permalink / raw)
To: linux-mmc
Cc: mark.rutland, devicetree, ulf.hansson, linux-aspeed,
Andrew Jeffery, ryanchen.aspeed, adrian.hunter, linux-kernel,
robh+dt, joel, linux-arm-kernel
In-Reply-To: <20190807003629.2974-1-andrew@aj.id.au>
Add a minimal driver for ASPEED's SD controller, which exposes two
SDHCIs.
The ASPEED design implements a common register set for the SDHCIs, and
moves some of the standard configuration elements out to this common
area (e.g. 8-bit mode, and card detect configuration which is not
currently supported).
The SD controller has a dedicated hardware interrupt that is shared
between the slots. The common register set exposes information on which
slot triggered the interrupt; early revisions of the patch introduced an
irqchip for the register, but reality is it doesn't behave as an
irqchip, and the result fits awkwardly into the irqchip APIs. Instead
I've taken the simple approach of using the IRQ as a shared IRQ with
some minor performance impact for the second slot.
Ryan was the original author of the patch - I've taken his work and
massaged it to drop the irqchip support and rework the devicetree
integration. The driver has been smoke tested under qemu against a
minimal SD controller model and lightly tested on an ast2500-evb.
Signed-off-by: Ryan Chen <ryanchen.aspeed@gmail.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
---
v5:
* Cleanup sdhci driver on registration failure
v4: No change
v2:
* Add AST2600 compatible
* Drop SDHCI_QUIRK2_CLOCK_DIV_ZERO_BROKEN
* Ensure slot number is valid
* Fix build with CONFIG_MODULES
* Fix module license string
* Non-PCI devices won't die
* Rename aspeed_sdc_configure_8bit_mode()
* Rename aspeed_sdhci_pdata
* Switch to sdhci_enable_clk()
* Use PTR_ERR() on the right `struct platform_device *`
---
drivers/mmc/host/Kconfig | 12 ++
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/sdhci-of-aspeed.c | 332 +++++++++++++++++++++++++++++
3 files changed, 345 insertions(+)
create mode 100644 drivers/mmc/host/sdhci-of-aspeed.c
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 14d89a108edd..0f8a230de2f3 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -154,6 +154,18 @@ config MMC_SDHCI_OF_ARASAN
If unsure, say N.
+config MMC_SDHCI_OF_ASPEED
+ tristate "SDHCI OF support for the ASPEED SDHCI controller"
+ depends on MMC_SDHCI_PLTFM
+ depends on OF
+ help
+ This selects the ASPEED Secure Digital Host Controller Interface.
+
+ If you have a controller with this interface, say Y or M here. You
+ also need to enable an appropriate bus interface.
+
+ If unsure, say N.
+
config MMC_SDHCI_OF_AT91
tristate "SDHCI OF support for the Atmel SDMMC controller"
depends on MMC_SDHCI_PLTFM
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 73578718f119..390ee162fe71 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -84,6 +84,7 @@ obj-$(CONFIG_MMC_SDHCI_ESDHC_IMX) += sdhci-esdhc-imx.o
obj-$(CONFIG_MMC_SDHCI_DOVE) += sdhci-dove.o
obj-$(CONFIG_MMC_SDHCI_TEGRA) += sdhci-tegra.o
obj-$(CONFIG_MMC_SDHCI_OF_ARASAN) += sdhci-of-arasan.o
+obj-$(CONFIG_MMC_SDHCI_OF_ASPEED) += sdhci-of-aspeed.o
obj-$(CONFIG_MMC_SDHCI_OF_AT91) += sdhci-of-at91.o
obj-$(CONFIG_MMC_SDHCI_OF_ESDHC) += sdhci-of-esdhc.o
obj-$(CONFIG_MMC_SDHCI_OF_HLWD) += sdhci-of-hlwd.o
diff --git a/drivers/mmc/host/sdhci-of-aspeed.c b/drivers/mmc/host/sdhci-of-aspeed.c
new file mode 100644
index 000000000000..8bb095ca2fa9
--- /dev/null
+++ b/drivers/mmc/host/sdhci-of-aspeed.c
@@ -0,0 +1,332 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/* Copyright (C) 2019 ASPEED Technology Inc. */
+/* Copyright (C) 2019 IBM Corp. */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/mmc/host.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+
+#include "sdhci-pltfm.h"
+
+#define ASPEED_SDC_INFO 0x00
+#define ASPEED_SDC_S1MMC8 BIT(25)
+#define ASPEED_SDC_S0MMC8 BIT(24)
+
+struct aspeed_sdc {
+ struct clk *clk;
+ struct resource *res;
+
+ spinlock_t lock;
+ void __iomem *regs;
+};
+
+struct aspeed_sdhci {
+ struct aspeed_sdc *parent;
+ u32 width_mask;
+};
+
+static void aspeed_sdc_configure_8bit_mode(struct aspeed_sdc *sdc,
+ struct aspeed_sdhci *sdhci,
+ bool bus8)
+{
+ u32 info;
+
+ /* Set/clear 8 bit mode */
+ spin_lock(&sdc->lock);
+ info = readl(sdc->regs + ASPEED_SDC_INFO);
+ if (bus8)
+ info |= sdhci->width_mask;
+ else
+ info &= ~sdhci->width_mask;
+ writel(info, sdc->regs + ASPEED_SDC_INFO);
+ spin_unlock(&sdc->lock);
+}
+
+static void aspeed_sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
+{
+ int div;
+ u16 clk;
+
+ if (clock == host->clock)
+ return;
+
+ sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
+
+ if (clock == 0)
+ goto out;
+
+ for (div = 1; div < 256; div *= 2) {
+ if ((host->max_clk / div) <= clock)
+ break;
+ }
+ div >>= 1;
+
+ clk = div << SDHCI_DIVIDER_SHIFT;
+
+ sdhci_enable_clk(host, clk);
+
+out:
+ host->clock = clock;
+}
+
+static void aspeed_sdhci_set_bus_width(struct sdhci_host *host, int width)
+{
+ struct sdhci_pltfm_host *pltfm_priv;
+ struct aspeed_sdhci *aspeed_sdhci;
+ struct aspeed_sdc *aspeed_sdc;
+ u8 ctrl;
+
+ pltfm_priv = sdhci_priv(host);
+ aspeed_sdhci = sdhci_pltfm_priv(pltfm_priv);
+ aspeed_sdc = aspeed_sdhci->parent;
+
+ /* Set/clear 8-bit mode */
+ aspeed_sdc_configure_8bit_mode(aspeed_sdc, aspeed_sdhci,
+ width == MMC_BUS_WIDTH_8);
+
+ /* Set/clear 1 or 4 bit mode */
+ ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
+ if (width == MMC_BUS_WIDTH_4)
+ ctrl |= SDHCI_CTRL_4BITBUS;
+ else
+ ctrl &= ~SDHCI_CTRL_4BITBUS;
+ sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
+}
+
+static const struct sdhci_ops aspeed_sdhci_ops = {
+ .set_clock = aspeed_sdhci_set_clock,
+ .get_max_clock = sdhci_pltfm_clk_get_max_clock,
+ .set_bus_width = aspeed_sdhci_set_bus_width,
+ .get_timeout_clock = sdhci_pltfm_clk_get_max_clock,
+ .reset = sdhci_reset,
+ .set_uhs_signaling = sdhci_set_uhs_signaling,
+};
+
+static const struct sdhci_pltfm_data aspeed_sdhci_pdata = {
+ .ops = &aspeed_sdhci_ops,
+ .quirks = SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
+};
+
+static inline int aspeed_sdhci_calculate_slot(struct aspeed_sdhci *dev,
+ struct resource *res)
+{
+ resource_size_t delta;
+
+ if (!res || resource_type(res) != IORESOURCE_MEM)
+ return -EINVAL;
+
+ if (res->start < dev->parent->res->start)
+ return -EINVAL;
+
+ delta = res->start - dev->parent->res->start;
+ if (delta & (0x100 - 1))
+ return -EINVAL;
+
+ return (delta / 0x100) - 1;
+}
+
+static int aspeed_sdhci_probe(struct platform_device *pdev)
+{
+ struct sdhci_pltfm_host *pltfm_host;
+ struct aspeed_sdhci *dev;
+ struct sdhci_host *host;
+ struct resource *res;
+ int slot;
+ int ret;
+
+ host = sdhci_pltfm_init(pdev, &aspeed_sdhci_pdata, sizeof(*dev));
+ if (IS_ERR(host))
+ return PTR_ERR(host);
+
+ pltfm_host = sdhci_priv(host);
+ dev = sdhci_pltfm_priv(pltfm_host);
+ dev->parent = dev_get_drvdata(pdev->dev.parent);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ slot = aspeed_sdhci_calculate_slot(dev, res);
+
+ if (slot < 0)
+ return slot;
+ else if (slot >= 2)
+ return -EINVAL;
+
+ dev_info(&pdev->dev, "Configuring for slot %d\n", slot);
+ dev->width_mask = !slot ? ASPEED_SDC_S0MMC8 : ASPEED_SDC_S1MMC8;
+
+ sdhci_get_of_property(pdev);
+
+ pltfm_host->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(pltfm_host->clk))
+ return PTR_ERR(pltfm_host->clk);
+
+ ret = clk_prepare_enable(pltfm_host->clk);
+ if (ret) {
+ dev_err(&pdev->dev, "Unable to enable SDIO clock\n");
+ goto err_pltfm_free;
+ }
+
+ ret = mmc_of_parse(host->mmc);
+ if (ret)
+ goto err_sdhci_add;
+
+ ret = sdhci_add_host(host);
+ if (ret)
+ goto err_sdhci_add;
+
+ return 0;
+
+err_sdhci_add:
+ clk_disable_unprepare(pltfm_host->clk);
+err_pltfm_free:
+ sdhci_pltfm_free(pdev);
+ return ret;
+}
+
+static int aspeed_sdhci_remove(struct platform_device *pdev)
+{
+ struct sdhci_pltfm_host *pltfm_host;
+ struct sdhci_host *host;
+ int dead = 0;
+
+ host = platform_get_drvdata(pdev);
+ pltfm_host = sdhci_priv(host);
+
+ sdhci_remove_host(host, dead);
+
+ clk_disable_unprepare(pltfm_host->clk);
+
+ sdhci_pltfm_free(pdev);
+
+ return 0;
+}
+
+static const struct of_device_id aspeed_sdhci_of_match[] = {
+ { .compatible = "aspeed,ast2400-sdhci", },
+ { .compatible = "aspeed,ast2500-sdhci", },
+ { .compatible = "aspeed,ast2600-sdhci", },
+ { }
+};
+
+static struct platform_driver aspeed_sdhci_driver = {
+ .driver = {
+ .name = "sdhci-aspeed",
+ .of_match_table = aspeed_sdhci_of_match,
+ },
+ .probe = aspeed_sdhci_probe,
+ .remove = aspeed_sdhci_remove,
+};
+
+static int aspeed_sdc_probe(struct platform_device *pdev)
+
+{
+ struct device_node *parent, *child;
+ struct aspeed_sdc *sdc;
+ int ret;
+
+ sdc = devm_kzalloc(&pdev->dev, sizeof(*sdc), GFP_KERNEL);
+ if (!sdc)
+ return -ENOMEM;
+
+ spin_lock_init(&sdc->lock);
+
+ sdc->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(sdc->clk))
+ return PTR_ERR(sdc->clk);
+
+ ret = clk_prepare_enable(sdc->clk);
+ if (ret) {
+ dev_err(&pdev->dev, "Unable to enable SDCLK\n");
+ return ret;
+ }
+
+ sdc->res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ sdc->regs = devm_ioremap_resource(&pdev->dev, sdc->res);
+ if (IS_ERR(sdc->regs)) {
+ ret = PTR_ERR(sdc->regs);
+ goto err_clk;
+ }
+
+ dev_set_drvdata(&pdev->dev, sdc);
+
+ parent = pdev->dev.of_node;
+ for_each_available_child_of_node(parent, child) {
+ struct platform_device *cpdev;
+
+ cpdev = of_platform_device_create(child, NULL, &pdev->dev);
+ if (IS_ERR(cpdev)) {
+ of_node_put(child);
+ ret = PTR_ERR(cpdev);
+ goto err_clk;
+ }
+ }
+
+ return 0;
+
+err_clk:
+ clk_disable_unprepare(sdc->clk);
+ return ret;
+}
+
+static int aspeed_sdc_remove(struct platform_device *pdev)
+{
+ struct aspeed_sdc *sdc = dev_get_drvdata(&pdev->dev);
+
+ clk_disable_unprepare(sdc->clk);
+
+ return 0;
+}
+
+static const struct of_device_id aspeed_sdc_of_match[] = {
+ { .compatible = "aspeed,ast2400-sd-controller", },
+ { .compatible = "aspeed,ast2500-sd-controller", },
+ { .compatible = "aspeed,ast2600-sd-controller", },
+ { }
+};
+
+MODULE_DEVICE_TABLE(of, aspeed_sdc_of_match);
+
+static struct platform_driver aspeed_sdc_driver = {
+ .driver = {
+ .name = "sd-controller-aspeed",
+ .pm = &sdhci_pltfm_pmops,
+ .of_match_table = aspeed_sdc_of_match,
+ },
+ .probe = aspeed_sdc_probe,
+ .remove = aspeed_sdc_remove,
+};
+
+static int __init aspeed_sdc_init(void)
+{
+ int rc;
+
+ rc = platform_driver_register(&aspeed_sdhci_driver);
+ if (rc < 0)
+ return rc;
+
+ rc = platform_driver_register(&aspeed_sdc_driver);
+ if (rc < 0)
+ platform_driver_unregister(&aspeed_sdhci_driver);
+
+ return rc;
+}
+module_init(aspeed_sdc_init);
+
+static void __exit aspeed_sdc_exit(void)
+{
+ platform_driver_unregister(&aspeed_sdc_driver);
+ platform_driver_unregister(&aspeed_sdhci_driver);
+}
+module_exit(aspeed_sdc_exit);
+
+MODULE_DESCRIPTION("Driver for the ASPEED SD/SDIO/SDHCI Controllers");
+MODULE_AUTHOR("Ryan Chen <ryan_chen@aspeedtech.com>");
+MODULE_AUTHOR("Andrew Jeffery <andrew@aj.id.au>");
+MODULE_LICENSE("GPL");
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* "of/platform: Pause/resume sync state during init and of_platform_populate()" with a warning on arm64
From: Qian Cai @ 2019-08-07 0:46 UTC (permalink / raw)
To: Saravana Kannan
Cc: Greg Kroah-Hartman, Rob Herring, Linux List Kernel Mailing,
linux-arm-kernel, devicetree
It looks like the linux-next commit “of/platform: Pause/resume sync state during init and of_platform_populate()” [1]
Introduced a warning while booting arm64.
[1] https://lore.kernel.org/lkml/20190731221721.187713-6-saravanak@google.com/
[ 93.449300][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: ias 44-bit, oas 44-bit (features 0x0000170d)
[ 93.464873][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 entries for cmdq
[ 93.485481][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 entries for evtq
[ 93.496320][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: option mask 0x2
[ 93.502917][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: ias 44-bit, oas 44-bit (features 0x0000170d)
[ 93.621818][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 entries for cmdq
[ 93.643000][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 entries for evtq
[ 94.519445][ T1] libphy: Fixed MDIO Bus: probed
[ 94.524649][ T1] EFI Variables Facility v0.08 2004-May-17
[ 94.601166][ T1] NET: Registered protocol family 17
[ 94.766008][ T1] zswap: loaded using pool lzo/zbud
[ 94.774745][ T1] kmemleak: Kernel memory leak detector initialized (mempool size: 16384)
[ 94.774756][ T1699] kmemleak: Automatic memory scanning thread started
[ 94.812338][ T1368] pcieport 0000:0f:00.0: Adding to iommu group 0
[ 94.984466][ T1] ------------[ cut here ]------------
[ 94.989827][ T1] Unmatched sync_state pause/resume!
[ 94.989894][ T1] WARNING: CPU: 25 PID: 1 at drivers/base/core.c:691 device_links_supplier_sync_state_resume+0x100/0x128
[ 95.006062][ T1] Modules linked in:
[ 95.009815][ T1] CPU: 25 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc3-next-20190806+ #11
[ 95.018161][ T1] Hardware name: HPE Apollo 70 /C01_APACHE_MB , BIOS L50_5.13_1.11 06/18/2019
[ 95.028593][ T1] pstate: 60400009 (nZCv daif +PAN -UAO)
[ 95.034077][ T1] pc : device_links_supplier_sync_state_resume+0x100/0x128
[ 95.041124][ T1] lr : device_links_supplier_sync_state_resume+0x100/0x128
[ 95.048167][ T1] sp : 34ff800806e6fbc0
[ 95.052172][ T1] x29: 34ff800806e6fc00 x28: 0000000000000000
[ 95.058177][ T1] x27: 0000000000000000 x26: 0000000000000000
[ 95.064181][ T1] x25: 0000000000000038 x24: 0000000000000000
[ 95.070185][ T1] x23: 0000000000000000 x22: 0000000000000019
[ 95.076189][ T1] x21: 0000000000000000 x20: f9ff808b804e6c50
[ 95.082193][ T1] x19: ffff100014a6e600 x18: 0000000000000040
[ 95.088197][ T1] x17: 0000000000000000 x16: 86ff80099d581b50
[ 95.094201][ T1] x15: 0000000000000000 x14: ffff100010086d1c
[ 95.100205][ T1] x13: ffff1000109d8688 x12: ffffffffffffffff
[ 95.106209][ T1] x11: 00000000000000f9 x10: ffff0808b804e6c6
[ 95.112213][ T1] x9 : 4b71ad522c851d00 x8 : 4b71ad522c851d00
[ 95.118217][ T1] x7 : 6170206574617473 x6 : ffff100014076972
[ 95.124221][ T1] x5 : 34ff800806e6f8f0 x4 : 000000000000000f
[ 95.130225][ T1] x3 : ffff1000101bfa5c x2 : 0000000000000001
[ 95.136229][ T1] x1 : 0000000000000001 x0 : 0000000000000022
[ 95.142233][ T1] Call trace:
[ 95.145374][ T1] device_links_supplier_sync_state_resume+0x100/0x128
[ 95.152074][ T1] of_platform_sync_state_init+0x10/0x1c
[ 95.157557][ T1] do_one_initcall+0x2f8/0x600
[ 95.162172][ T1] do_initcall_level+0x37c/0x3fc
[ 95.166959][ T1] do_basic_setup+0x34/0x4c
[ 95.171313][ T1] kernel_init_freeable+0x188/0x24c
[ 95.176363][ T1] kernel_init+0x18/0x334
[ 95.180543][ T1] ret_from_fork+0x10/0x18
[ 95.184809][ T1] ---[ end trace a9ea68c902540fe5 ]---
[ 95.269085][ T1] Freeing unused kernel memory: 28672K
[ 101.069860][ T1] Checked W+X mappings: passed, no W+X pages found
[ 101.076265][ T1] Run /init as init process
[ 101.186359][ T1] systemd[1]: System time before build time, advancing clock.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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