* [PATCH net-next 0/2] drivers: net: xgene: fix: Use GPIO to get link status
From: David Miller @ 2016-10-12 5:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475789758-5196-1-git-send-email-isubramanian@apm.com>
From: Iyappan Subramanian <isubramanian@apm.com>
Date: Thu, 6 Oct 2016 14:35:56 -0700
> Since the link value reported by the link status register is not
> reliable if no SPF module inserted, this patchset fixes the issue by
> using GPIO to determine the link status when no module inserted.
>
> Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
> Signed-off-by: Quan Nguyen <qnguyen@apm.com>
Series applied, thanks.
^ permalink raw reply
* [PATCH 0/4] ARM64: More flexible HW watchpoint
From: Pratyush Anand @ 2016-10-12 5:58 UTC (permalink / raw)
To: linux-arm-kernel
Currently, we do not support all the byte select option provided by ARM64
specs for a HW watchpoint.
This patch set will help user to instrument a watchpoint with all possible
byte select options.
Pratyush Anand (4):
hw_breakpoint: Allow watchpoint of length 3,5,6 and 7
arm64: Allow hw watchpoint at varied offset from base address
arm64: Allow hw watchpoint of length 3,5,6 and 7
selftests: arm64: add test for unaligned watchpoint address handling
arch/arm64/include/asm/hw_breakpoint.h | 6 +-
arch/arm64/kernel/hw_breakpoint.c | 79 ++++++--
arch/arm64/kernel/ptrace.c | 5 +-
include/uapi/linux/hw_breakpoint.h | 4 +
tools/include/uapi/linux/hw_breakpoint.h | 4 +
tools/testing/selftests/breakpoints/Makefile | 5 +-
.../selftests/breakpoints/breakpoint_test_arm64.c | 223 +++++++++++++++++++++
7 files changed, 300 insertions(+), 26 deletions(-)
create mode 100644 tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
--
2.7.4
^ permalink raw reply
* [PATCH 1/4] hw_breakpoint: Allow watchpoint of length 3,5,6 and 7
From: Pratyush Anand @ 2016-10-12 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1476251587.git.panand@redhat.com>
We only support breakpoint/watchpoint of length 1, 2, 4 and 8. If we can
support other length as well, then user may watch more data with less
number of watchpoints (provided hardware supports it). For example: if we
have to watch only 4th, 5th and 6th byte from a 64 bit aligned address, we
will have to use two slots to implement it currently. One slot will watch a
half word at offset 4 and other a byte at offset 6. If we can have a
watchpoint of length 3 then we can watch it with single slot as well.
ARM64 hardware does support such functionality, therefore adding these new
definitions in generic layer.
Signed-off-by: Pratyush Anand <panand@redhat.com>
---
include/uapi/linux/hw_breakpoint.h | 4 ++++
tools/include/uapi/linux/hw_breakpoint.h | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/include/uapi/linux/hw_breakpoint.h b/include/uapi/linux/hw_breakpoint.h
index b04000a2296a..2b65efd19a46 100644
--- a/include/uapi/linux/hw_breakpoint.h
+++ b/include/uapi/linux/hw_breakpoint.h
@@ -4,7 +4,11 @@
enum {
HW_BREAKPOINT_LEN_1 = 1,
HW_BREAKPOINT_LEN_2 = 2,
+ HW_BREAKPOINT_LEN_3 = 3,
HW_BREAKPOINT_LEN_4 = 4,
+ HW_BREAKPOINT_LEN_5 = 5,
+ HW_BREAKPOINT_LEN_6 = 6,
+ HW_BREAKPOINT_LEN_7 = 7,
HW_BREAKPOINT_LEN_8 = 8,
};
diff --git a/tools/include/uapi/linux/hw_breakpoint.h b/tools/include/uapi/linux/hw_breakpoint.h
index b04000a2296a..2b65efd19a46 100644
--- a/tools/include/uapi/linux/hw_breakpoint.h
+++ b/tools/include/uapi/linux/hw_breakpoint.h
@@ -4,7 +4,11 @@
enum {
HW_BREAKPOINT_LEN_1 = 1,
HW_BREAKPOINT_LEN_2 = 2,
+ HW_BREAKPOINT_LEN_3 = 3,
HW_BREAKPOINT_LEN_4 = 4,
+ HW_BREAKPOINT_LEN_5 = 5,
+ HW_BREAKPOINT_LEN_6 = 6,
+ HW_BREAKPOINT_LEN_7 = 7,
HW_BREAKPOINT_LEN_8 = 8,
};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/4] arm64: Allow hw watchpoint at varied offset from base address
From: Pratyush Anand @ 2016-10-12 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1476251587.git.panand@redhat.com>
ARM64 hardware supports watchpoint at any double word aligned address.
However, it can select any consecutive bytes from offset 0 to 7 from that
base address. For example, if base address is programmed as 0x420030 and
byte select is 0x1C, then access of 0x420032,0x420033 and 0x420034 will
generate a watchpoint exception.
Currently, we do not have such modularity. We can only program byte,
halfword, word and double word access exception from any base address.
This patch adds support to overcome above limitations.
Signed-off-by: Pratyush Anand <panand@redhat.com>
---
arch/arm64/include/asm/hw_breakpoint.h | 2 +-
arch/arm64/kernel/hw_breakpoint.c | 43 +++++++++++++++++-----------------
arch/arm64/kernel/ptrace.c | 5 ++--
3 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/arch/arm64/include/asm/hw_breakpoint.h b/arch/arm64/include/asm/hw_breakpoint.h
index 115ea2a64520..4f4e58bee9bc 100644
--- a/arch/arm64/include/asm/hw_breakpoint.h
+++ b/arch/arm64/include/asm/hw_breakpoint.h
@@ -118,7 +118,7 @@ struct perf_event;
struct pmu;
extern int arch_bp_generic_fields(struct arch_hw_breakpoint_ctrl ctrl,
- int *gen_len, int *gen_type);
+ int *gen_len, int *gen_type, int *offset);
extern int arch_check_bp_in_kernelspace(struct perf_event *bp);
extern int arch_validate_hwbkpt_settings(struct perf_event *bp);
extern int hw_breakpoint_exceptions_notify(struct notifier_block *unused,
diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
index 26a6bf77d272..c888c23149ad 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -349,7 +349,7 @@ int arch_check_bp_in_kernelspace(struct perf_event *bp)
* to generic breakpoint descriptions.
*/
int arch_bp_generic_fields(struct arch_hw_breakpoint_ctrl ctrl,
- int *gen_len, int *gen_type)
+ int *gen_len, int *gen_type, int *offset)
{
/* Type */
switch (ctrl.type) {
@@ -369,8 +369,10 @@ int arch_bp_generic_fields(struct arch_hw_breakpoint_ctrl ctrl,
return -EINVAL;
}
+ *offset = ffs(ctrl.len) - 1;
+
/* Len */
- switch (ctrl.len) {
+ switch (ctrl.len >> *offset) {
case ARM_BREAKPOINT_LEN_1:
*gen_len = HW_BREAKPOINT_LEN_1;
break;
@@ -517,18 +519,17 @@ int arch_validate_hwbkpt_settings(struct perf_event *bp)
default:
return -EINVAL;
}
-
- info->address &= ~alignment_mask;
- info->ctrl.len <<= offset;
} else {
if (info->ctrl.type == ARM_BREAKPOINT_EXECUTE)
alignment_mask = 0x3;
else
alignment_mask = 0x7;
- if (info->address & alignment_mask)
- return -EINVAL;
+ offset = info->address & alignment_mask;
}
+ info->address &= ~alignment_mask;
+ info->ctrl.len <<= offset;
+
/*
* Disallow per-task kernel breakpoints since these would
* complicate the stepping code.
@@ -671,6 +672,7 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr,
struct debug_info *debug_info;
struct arch_hw_breakpoint *info;
struct arch_hw_breakpoint_ctrl ctrl;
+ u32 lens, lene;
slots = this_cpu_ptr(wp_on_reg);
debug_info = ¤t->thread.debug;
@@ -684,25 +686,22 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr,
goto unlock;
info = counter_arch_bp(wp);
- /* AArch32 watchpoints are either 4 or 8 bytes aligned. */
- if (is_compat_task()) {
- if (info->ctrl.len == ARM_BREAKPOINT_LEN_8)
- alignment_mask = 0x7;
- else
- alignment_mask = 0x3;
- } else {
- alignment_mask = 0x7;
- }
- /* Check if the watchpoint value matches. */
+ /* Check if the watchpoint value and byte select match. */
val = read_wb_reg(AARCH64_DBG_REG_WVR, i);
- if (val != (addr & ~alignment_mask))
- goto unlock;
-
- /* Possible match, check the byte address select to confirm. */
ctrl_reg = read_wb_reg(AARCH64_DBG_REG_WCR, i);
decode_ctrl_reg(ctrl_reg, &ctrl);
- if (!((1 << (addr & alignment_mask)) & ctrl.len))
+ lens = ffs(ctrl.len) - 1;
+ lene = fls(ctrl.len) - 1;
+ /*
+ * Ideally, a read/write type information such as
+ * byte/hw/word/dw would have provided a good check. But
+ * I do not see such possibility. So, considering that max
+ * rd/wr size as 8, i.e. this watchpoint interrupt would
+ * have generated because any of the address from `addr` to
+ * `addr + 7` would have been accessed.
+ */
+ if (addr + 7 < val + lens || addr > val + lene)
goto unlock;
/*
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index e0c81da60f76..0eb366a94382 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -327,13 +327,13 @@ static int ptrace_hbp_fill_attr_ctrl(unsigned int note_type,
struct arch_hw_breakpoint_ctrl ctrl,
struct perf_event_attr *attr)
{
- int err, len, type, disabled = !ctrl.enabled;
+ int err, len, type, offset, disabled = !ctrl.enabled;
attr->disabled = disabled;
if (disabled)
return 0;
- err = arch_bp_generic_fields(ctrl, &len, &type);
+ err = arch_bp_generic_fields(ctrl, &len, &type, &offset);
if (err)
return err;
@@ -352,6 +352,7 @@ static int ptrace_hbp_fill_attr_ctrl(unsigned int note_type,
attr->bp_len = len;
attr->bp_type = type;
+ attr->bp_addr += offset;
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 3/4] arm64: Allow hw watchpoint of length 3,5,6 and 7
From: Pratyush Anand @ 2016-10-12 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1476251587.git.panand@redhat.com>
Since, arm64 can support all offset within a double word limit. Therefore,
now support other lengths within that range as well.
Signed-off-by: Pratyush Anand <panand@redhat.com>
---
arch/arm64/include/asm/hw_breakpoint.h | 4 ++++
arch/arm64/kernel/hw_breakpoint.c | 36 ++++++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+)
diff --git a/arch/arm64/include/asm/hw_breakpoint.h b/arch/arm64/include/asm/hw_breakpoint.h
index 4f4e58bee9bc..7a18c8520588 100644
--- a/arch/arm64/include/asm/hw_breakpoint.h
+++ b/arch/arm64/include/asm/hw_breakpoint.h
@@ -76,7 +76,11 @@ static inline void decode_ctrl_reg(u32 reg,
/* Lengths */
#define ARM_BREAKPOINT_LEN_1 0x1
#define ARM_BREAKPOINT_LEN_2 0x3
+#define ARM_BREAKPOINT_LEN_3 0x7
#define ARM_BREAKPOINT_LEN_4 0xf
+#define ARM_BREAKPOINT_LEN_5 0x1f
+#define ARM_BREAKPOINT_LEN_6 0x3f
+#define ARM_BREAKPOINT_LEN_7 0x7f
#define ARM_BREAKPOINT_LEN_8 0xff
/* Kernel stepping */
diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
index c888c23149ad..7ff2c3cfeb46 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -317,9 +317,21 @@ static int get_hbp_len(u8 hbp_len)
case ARM_BREAKPOINT_LEN_2:
len_in_bytes = 2;
break;
+ case ARM_BREAKPOINT_LEN_3:
+ len_in_bytes = 3;
+ break;
case ARM_BREAKPOINT_LEN_4:
len_in_bytes = 4;
break;
+ case ARM_BREAKPOINT_LEN_5:
+ len_in_bytes = 5;
+ break;
+ case ARM_BREAKPOINT_LEN_6:
+ len_in_bytes = 6;
+ break;
+ case ARM_BREAKPOINT_LEN_7:
+ len_in_bytes = 7;
+ break;
case ARM_BREAKPOINT_LEN_8:
len_in_bytes = 8;
break;
@@ -379,9 +391,21 @@ int arch_bp_generic_fields(struct arch_hw_breakpoint_ctrl ctrl,
case ARM_BREAKPOINT_LEN_2:
*gen_len = HW_BREAKPOINT_LEN_2;
break;
+ case ARM_BREAKPOINT_LEN_3:
+ *gen_len = HW_BREAKPOINT_LEN_3;
+ break;
case ARM_BREAKPOINT_LEN_4:
*gen_len = HW_BREAKPOINT_LEN_4;
break;
+ case ARM_BREAKPOINT_LEN_5:
+ *gen_len = HW_BREAKPOINT_LEN_5;
+ break;
+ case ARM_BREAKPOINT_LEN_6:
+ *gen_len = HW_BREAKPOINT_LEN_6;
+ break;
+ case ARM_BREAKPOINT_LEN_7:
+ *gen_len = HW_BREAKPOINT_LEN_7;
+ break;
case ARM_BREAKPOINT_LEN_8:
*gen_len = HW_BREAKPOINT_LEN_8;
break;
@@ -425,9 +449,21 @@ static int arch_build_bp_info(struct perf_event *bp)
case HW_BREAKPOINT_LEN_2:
info->ctrl.len = ARM_BREAKPOINT_LEN_2;
break;
+ case HW_BREAKPOINT_LEN_3:
+ info->ctrl.len = ARM_BREAKPOINT_LEN_3;
+ break;
case HW_BREAKPOINT_LEN_4:
info->ctrl.len = ARM_BREAKPOINT_LEN_4;
break;
+ case HW_BREAKPOINT_LEN_5:
+ info->ctrl.len = ARM_BREAKPOINT_LEN_5;
+ break;
+ case HW_BREAKPOINT_LEN_6:
+ info->ctrl.len = ARM_BREAKPOINT_LEN_6;
+ break;
+ case HW_BREAKPOINT_LEN_7:
+ info->ctrl.len = ARM_BREAKPOINT_LEN_7;
+ break;
case HW_BREAKPOINT_LEN_8:
info->ctrl.len = ARM_BREAKPOINT_LEN_8;
break;
--
2.7.4
^ permalink raw reply related
* [PATCH 4/4] selftests: arm64: add test for unaligned watchpoint address handling
From: Pratyush Anand @ 2016-10-12 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1476251587.git.panand@redhat.com>
ARM64 hardware expects 64bit aligned address for watchpoint invocation.
However, it provides byte selection method to select any number of
consecutive byte set within the range of 1-8.
This patch adds support to test all such byte selection option for
different memory write sizes.
Signed-off-by: Pratyush Anand <panand@redhat.com>
---
tools/testing/selftests/breakpoints/Makefile | 5 +-
.../selftests/breakpoints/breakpoint_test_arm64.c | 223 +++++++++++++++++++++
2 files changed, 227 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
diff --git a/tools/testing/selftests/breakpoints/Makefile b/tools/testing/selftests/breakpoints/Makefile
index 74e533fd4bc5..61b79e8df1f4 100644
--- a/tools/testing/selftests/breakpoints/Makefile
+++ b/tools/testing/selftests/breakpoints/Makefile
@@ -5,6 +5,9 @@ ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/x86/ -e s/x86_64/x86/)
ifeq ($(ARCH),x86)
TEST_PROGS := breakpoint_test
endif
+ifeq ($(ARCH),aarch64)
+TEST_PROGS := breakpoint_test_arm64
+endif
TEST_PROGS += step_after_suspend_test
@@ -13,4 +16,4 @@ all: $(TEST_PROGS)
include ../lib.mk
clean:
- rm -fr breakpoint_test step_after_suspend_test
+ rm -fr breakpoint_test breakpoint_test_arm64 step_after_suspend_test
diff --git a/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c b/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
new file mode 100644
index 000000000000..f56331831182
--- /dev/null
+++ b/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
@@ -0,0 +1,223 @@
+/*
+ * Copyright (C) 2016 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Original Code by Pavel Labath <test.tberghammer@gmail.com>
+ *
+ * Code modified by Pratyush Anand <panand@redhat.com>
+ * for testing different byte select for each access size.
+ *
+ */
+
+#define _GNU_SOURCE
+
+#include <sys/types.h>
+#include <sys/wait.h>
+#include <sys/ptrace.h>
+#include <sys/param.h>
+#include <sys/uio.h>
+#include <stdint.h>
+#include <stdbool.h>
+#include <stddef.h>
+#include <string.h>
+#include <stdio.h>
+#include <unistd.h>
+#include <elf.h>
+#include <errno.h>
+#include <signal.h>
+
+#include "../kselftest.h"
+
+static volatile uint8_t var[96] __attribute__((__aligned__(32)));
+
+static void child(int size, int wr)
+{
+ volatile uint8_t *addr = &var[32 + wr];
+
+ if (ptrace(PTRACE_TRACEME, 0, NULL, NULL) != 0) {
+ perror("ptrace(PTRACE_TRACEME) failed");
+ _exit(1);
+ }
+
+ if (raise(SIGSTOP) != 0) {
+ perror("raise(SIGSTOP) failed");
+ _exit(1);
+ }
+
+ if ((uintptr_t) addr % size) {
+ perror("Wrong address write for the given size\n");
+ _exit(1);
+ }
+ switch (size) {
+ case 1:
+ *addr = 47;
+ break;
+ case 2:
+ *(uint16_t *)addr = 47;
+ break;
+ case 4:
+ *(uint32_t *)addr = 47;
+ break;
+ case 8:
+ *(uint64_t *)addr = 47;
+ break;
+ case 16:
+ __asm__ volatile ("stp x29, x30, %0" : "=m" (addr[0]));
+ break;
+ case 32:
+ __asm__ volatile ("stp q29, q30, %0" : "=m" (addr[0]));
+ break;
+ }
+
+ _exit(0);
+}
+
+static bool set_watchpoint(pid_t pid, int size, int wp)
+{
+ const volatile uint8_t *addr = &var[32 + wp];
+ const int offset = (uintptr_t)addr % 8;
+ const unsigned int byte_mask = ((1 << size) - 1) << offset;
+ const unsigned int type = 2; /* Write */
+ const unsigned int enable = 1;
+ const unsigned int control = byte_mask << 5 | type << 3 | enable;
+ struct user_hwdebug_state dreg_state;
+ struct iovec iov;
+
+ memset(&dreg_state, 0, sizeof(dreg_state));
+ dreg_state.dbg_regs[0].addr = (uintptr_t)(addr - offset);
+ dreg_state.dbg_regs[0].ctrl = control;
+ iov.iov_base = &dreg_state;
+ iov.iov_len = offsetof(struct user_hwdebug_state, dbg_regs) +
+ sizeof(dreg_state.dbg_regs[0]);
+ if (ptrace(PTRACE_SETREGSET, pid, NT_ARM_HW_WATCH, &iov) == 0)
+ return true;
+
+ if (errno == EIO) {
+ printf("ptrace(PTRACE_SETREGSET, NT_ARM_HW_WATCH) "
+ "not supported on this hardware\n");
+ ksft_exit_skip();
+ }
+ perror("ptrace(PTRACE_SETREGSET, NT_ARM_HW_WATCH) failed");
+ return false;
+}
+
+static bool run_test(int size, int wr, int wp)
+{
+ int status;
+ siginfo_t siginfo;
+ pid_t pid = fork();
+ pid_t wpid;
+
+ if (pid < 0) {
+ perror("fork() failed");
+ return false;
+ }
+ if (pid == 0)
+ child(size, wr);
+
+ wpid = waitpid(pid, &status, __WALL);
+ if (wpid != pid) {
+ perror("waitpid() failed");
+ return false;
+ }
+ if (!WIFSTOPPED(status)) {
+ printf("child did not stop\n");
+ return false;
+ }
+ if (WSTOPSIG(status) != SIGSTOP) {
+ printf("child did not stop with SIGSTOP\n");
+ return false;
+ }
+
+ if (!set_watchpoint(pid, MIN(size, 8), wp))
+ return false;
+
+ if (ptrace(PTRACE_CONT, pid, NULL, NULL) < 0) {
+ perror("ptrace(PTRACE_SINGLESTEP) failed");
+ return false;
+ }
+
+ alarm(3);
+ wpid = waitpid(pid, &status, __WALL);
+ if (wpid != pid) {
+ perror("waitpid() failed");
+ return false;
+ }
+ alarm(0);
+ if (WIFEXITED(status)) {
+ printf("child did not single-step\t");
+ return false;
+ }
+ if (!WIFSTOPPED(status)) {
+ printf("child did not stop\n");
+ return false;
+ }
+ if (WSTOPSIG(status) != SIGTRAP) {
+ printf("child did not stop with SIGTRAP\n");
+ return false;
+ }
+ if (ptrace(PTRACE_GETSIGINFO, pid, NULL, &siginfo) != 0) {
+ perror("ptrace(PTRACE_GETSIGINFO)");
+ return false;
+ }
+ if (siginfo.si_code != TRAP_HWBKPT) {
+ printf("Unexpected si_code %d\n", siginfo.si_code);
+ return false;
+ }
+
+ kill(pid, SIGKILL);
+ wpid = waitpid(pid, &status, 0);
+ if (wpid != pid) {
+ perror("waitpid() failed");
+ return false;
+ }
+ return true;
+}
+
+static void sigalrm(int sig)
+{
+}
+
+int main(int argc, char **argv)
+{
+ int opt;
+ bool succeeded = true;
+ struct sigaction act;
+ int wr, wp, size;
+ bool result;
+
+ act.sa_handler = sigalrm;
+ sigemptyset(&act.sa_mask);
+ act.sa_flags = 0;
+ sigaction(SIGALRM, &act, NULL);
+ for (size = 1; size <= 32; size = size*2) {
+ for (wr = 0; wr <= 32; wr = wr + size) {
+ for (wp = wr - size; wp <= wr + size; wp = wp + size) {
+ printf("Test size = %d write offset = %d watchpoint offset = %d\t", size, wr, wp);
+ result = run_test(size, wr, wp);
+ if ((result && wr == wp) || (!result && wr != wp)) {
+ printf("[OK]\n");
+ ksft_inc_pass_cnt();
+ } else {
+ printf("[FAILED]\n");
+ ksft_inc_fail_cnt();
+ succeeded = false;
+ }
+ }
+ }
+ }
+
+ ksft_print_cnts();
+ if (succeeded)
+ ksft_exit_pass();
+ else
+ ksft_exit_fail();
+}
--
2.7.4
^ permalink raw reply related
* [patch] serial: stm32: fix a type issue
From: Dan Carpenter @ 2016-10-12 6:21 UTC (permalink / raw)
To: linux-arm-kernel
We store UNDEF_REG in a u8. It causes a problem in functions like
stm32_tx_dma_complete() where we check "if (ofs->icr == UNDEF_REG)".
Fixes: 3489187204eb ('serial: stm32: adding dma support')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/tty/serial/stm32-usart.h b/drivers/tty/serial/stm32-usart.h
index 41d9749..f9887cc 100644
--- a/drivers/tty/serial/stm32-usart.h
+++ b/drivers/tty/serial/stm32-usart.h
@@ -31,7 +31,7 @@ struct stm32_usart_info {
struct stm32_usart_config cfg;
};
-#define UNDEF_REG ~0
+#define UNDEF_REG 0xFF
/* Register offsets */
struct stm32_usart_info stm32f4_info = {
^ permalink raw reply related
* [PATCH V3 0/8] IOMMU probe deferral support
From: Sricharan @ 2016-10-12 6:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <12cfb59f-f7ca-d4df-eb7f-42348e357979@samsung.com>
Hi Marek,
>Hi Sricharan,
>
>
>On 2016-10-04 19:03, Sricharan R wrote:
>> Initial post from Laurent Pinchart[1]. This is
>> series calls the dma ops configuration for the devices
>> at a generic place so that it works for all busses.
>> The dma_configure_ops for a device is now called during
>> the device_attach callback just before the probe of the
>> bus/driver is called. Similarly dma_deconfigure is called during
>> device/driver_detach path.
>>
>>
>> pci_bus_add_devices (platform/amba)(_device_create/driver_register)
>> | |
>> pci_bus_add_device (device_add/driver_register)
>> | |
>> device_attach device_initial_probe
>> | |
>> __device_attach_driver __device_attach_driver
>> |
>> driver_probe_device
>> |
>> really_probe
>> |
>> dma_configure
>>
>> Similarly on the device/driver_unregister path __device_release_driver is
>> called which inturn calls dma_deconfigure.
>>
>> If the ACPI bus code follows the same, we can add acpi_dma_configure
>> at the same place as of_dma_configure.
>>
>> This series is based on the recently merged Generic DT bindings for
>> PCI IOMMUs and ARM SMMU from Robin Murphy robin.murphy at arm.com [2]
>>
>> This time tested this with platform and pci device for probe deferral
>> and reprobe on arm64 based platform. There is an issue on the cleanup
>> path for arm64 though, where there is WARN_ON if the dma_ops is reset while
>> device is attached to an domain in arch_teardown_dma_ops.
>> But with iommu_groups created from the iommu driver, the device is always
>> attached to a domain/default_domain. So so the WARN has to be removed/handled
>> probably.
>
>Thanks for continuing work on this feature! Your can add my:
>
>Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
Thanks for testing this. So the for the below fix, the remove_device callback
gets called on the dma_ops cleanup path, so would it be easy to remove the
data for the device there ?
Regards,
Sricharan
>It works fine with Exynos SYSMMU driver, although a patch is needed to fix
>infinite loop due to list corruption (same element is added twice if master
>device fails with deferred probe):
>
>From: Marek Szyprowski <m.szyprowski@samsung.com>
>Date: Mon, 10 Oct 2016 14:22:42 +0200
>Subject: [PATCH] iommu/exynos: ensure that sysmmu is added only once to its
> master
>
>Since adding IOMMU deferred probing support, of_xlate() callback might
>be called more than once for given master device (for example it happens
>when masters device driver fails with EPROBE_DEFER), so ensure that
>SYSMMU controller is added to its master device (owner) only once.
>
>Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>---
> drivers/iommu/exynos-iommu.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
>index 30808e91b775..1525a86eb829 100644
>--- a/drivers/iommu/exynos-iommu.c
>+++ b/drivers/iommu/exynos-iommu.c
>@@ -1253,7 +1253,7 @@ static int exynos_iommu_of_xlate(struct device *dev,
> {
> struct exynos_iommu_owner *owner = dev->archdata.iommu;
> struct platform_device *sysmmu = of_find_device_by_node(spec->np);
>- struct sysmmu_drvdata *data;
>+ struct sysmmu_drvdata *data, *entry;
>
> if (!sysmmu)
> return -ENODEV;
>@@ -1271,6 +1271,10 @@ static int exynos_iommu_of_xlate(struct device *dev,
> dev->archdata.iommu = owner;
> }
>
>+ list_for_each_entry(entry, &owner->controllers, owner_node)
>+ if (entry == data)
>+ return 0;
>+
> list_add_tail(&data->owner_node, &owner->controllers);
> return 0;
> }
>--
>1.9.1
>
^ permalink raw reply
* [PATCH v3 07/11] arm64/tracing: fix compat syscall handling
From: Marcin Nowakowski @ 2016-10-12 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161011133623.GE9532@arm.com>
Hi Will,
On 11.10.2016 15:36, Will Deacon wrote:
> On Tue, Oct 11, 2016 at 12:42:52PM +0200, Marcin Nowakowski wrote:
>> Add arch_syscall_addr for arm64 and define NR_compat_syscalls, as the
>> number of compat syscalls for arm64 exceeds the number defined by
>> NR_syscalls.
>>
>> Signed-off-by: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
>> Cc: Steven Rostedt <rostedt@goodmis.org>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: linux-arm-kernel at lists.infradead.org
>> ---
>> arch/arm64/include/asm/ftrace.h | 12 +-----------
>> arch/arm64/include/asm/unistd.h | 1 +
>> arch/arm64/kernel/Makefile | 1 +
>> arch/arm64/kernel/ftrace.c | 16 ++++++++++++++++
>> 4 files changed, 19 insertions(+), 11 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h
>> index caa955f..b57ff7c 100644
>> --- a/arch/arm64/include/asm/ftrace.h
>> +++ b/arch/arm64/include/asm/ftrace.h
>> @@ -41,17 +41,7 @@ static inline unsigned long ftrace_call_adjust(unsigned long addr)
>>
>> #define ftrace_return_address(n) return_address(n)
>>
>> -/*
>> - * Because AArch32 mode does not share the same syscall table with AArch64,
>> - * tracing compat syscalls may result in reporting bogus syscalls or even
>> - * hang-up, so just do not trace them.
>> - * See kernel/trace/trace_syscalls.c
>> - *
>> - * x86 code says:
>> - * If the user really wants these, then they should use the
>> - * raw syscall tracepoints with filtering.
>> - */
>> -#define ARCH_TRACE_IGNORE_COMPAT_SYSCALLS
>> +#define ARCH_COMPAT_SYSCALL_NUMBERS_OVERLAP 1
>> static inline bool arch_trace_is_compat_syscall(struct pt_regs *regs)
>> {
>> return is_compat_task();
>> diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h
>> index e78ac26..276d049 100644
>> --- a/arch/arm64/include/asm/unistd.h
>> +++ b/arch/arm64/include/asm/unistd.h
>> @@ -45,6 +45,7 @@
>> #define __ARM_NR_compat_set_tls (__ARM_NR_COMPAT_BASE+5)
>>
>> #define __NR_compat_syscalls 394
>> +#define NR_compat_syscalls (__NR_compat_syscalls)
>
> We may as well just define NR_compat_syscalls instead of
> __NR_compat_syscalls and move the handful of users over.
I had tried to minimise the amount of arch-specific changes here -
especially those that are not directly related to the proposed syscall
handling change. But I agree having these 2 #defines is a bit
unnecessary ...
>> diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
>> index 40ad08a..75d010f 100644
>> --- a/arch/arm64/kernel/ftrace.c
>> +++ b/arch/arm64/kernel/ftrace.c
>> @@ -176,4 +176,20 @@ int ftrace_disable_ftrace_graph_caller(void)
>> return ftrace_modify_graph_caller(false);
>> }
>> #endif /* CONFIG_DYNAMIC_FTRACE */
>> +
>> #endif /* CONFIG_FUNCTION_GRAPH_TRACER */
>> +
>> +#if (defined CONFIG_FTRACE_SYSCALLS) && (defined CONFIG_COMPAT)
>> +
>> +extern const void *sys_call_table[];
>> +extern const void *compat_sys_call_table[];
>> +
>> +unsigned long __init arch_syscall_addr(int nr, bool compat)
>> +{
>> + if (compat)
>> + return (unsigned long)compat_sys_call_table[nr];
>> +
>> + return (unsigned long)sys_call_table[nr];
>> +}
>
> Do we care about the compat private syscalls (from base 0x0f0000)? We
> need to make sure that we exhibit the same behaviour as a native
> 32-bit ARM machine.
>
> Will
Tracing of such syscalls has been disabled for a long time (see
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=086ba77a6db0).
Apart from using non-contiguous numbers, they are not defined using
standard SYSCALL macros, so they do not have any metadata generated either.
My suggestion is that if you wanted those to be included in the trace
then it should be done separately from these changes.
Marcin
^ permalink raw reply
* [patch] serial: stm32: fix a type issue
From: Gerald Baeza @ 2016-10-12 7:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161012062103.GS12841@mwanda>
Hi Dan and thanks for the patch
On 10/12/2016 08:21 AM, Dan Carpenter wrote:
> We store UNDEF_REG in a u8. It causes a problem in functions like
> stm32_tx_dma_complete() where we check "if (ofs->icr == UNDEF_REG)".
>
> Fixes: 3489187204eb ('serial: stm32: adding dma support')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/tty/serial/stm32-usart.h b/drivers/tty/serial/stm32-usart.h
> index 41d9749..f9887cc 100644
> --- a/drivers/tty/serial/stm32-usart.h
> +++ b/drivers/tty/serial/stm32-usart.h
> @@ -31,7 +31,7 @@ struct stm32_usart_info {
> struct stm32_usart_config cfg;
> };
>
> -#define UNDEF_REG ~0
> +#define UNDEF_REG 0xFF
>
> /* Register offsets */
> struct stm32_usart_info stm32f4_info = {
>
Reviewed-by: Gerald Baeza <gerald.baeza@st.com>
^ permalink raw reply
* [PATCH v6 1/2] serial: xuartps: Add new compatible string for ZynqMP
From: Nava kishore Manne @ 2016-10-12 7:47 UTC (permalink / raw)
To: linux-arm-kernel
This patch Adds the new compatible string for ZynqMP SoC.
Signed-off-by: Nava kishore Manne <navam@xilinx.com>
---
Changes for v6:
-Added New patch.
drivers/tty/serial/xilinx_uartps.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index f37edaa..dd4c02f 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -1200,6 +1200,7 @@ static int __init cdns_early_console_setup(struct earlycon_device *device,
OF_EARLYCON_DECLARE(cdns, "xlnx,xuartps", cdns_early_console_setup);
OF_EARLYCON_DECLARE(cdns, "cdns,uart-r1p8", cdns_early_console_setup);
OF_EARLYCON_DECLARE(cdns, "cdns,uart-r1p12", cdns_early_console_setup);
+OF_EARLYCON_DECLARE(cdns, "xlnx,zynqmp-uart", cdns_early_console_setup);
/**
* cdns_uart_console_write - perform write operation
@@ -1438,6 +1439,7 @@ static const struct of_device_id cdns_uart_of_match[] = {
{ .compatible = "xlnx,xuartps", },
{ .compatible = "cdns,uart-r1p8", },
{ .compatible = "cdns,uart-r1p12", .data = &zynqmp_uart_def },
+ { .compatible = "xlnx,zynqmp-uart", .data = &zynqmp_uart_def },
{}
};
MODULE_DEVICE_TABLE(of, cdns_uart_of_match);
--
2.1.1
^ permalink raw reply related
* [PATCH v6 2/2] devicetree: bindings: uart: Add new compatible string for ZynqMP
From: Nava kishore Manne @ 2016-10-12 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476258448-20483-1-git-send-email-navam@xilinx.com>
From: Nava kishore Manne <nava.manne@xilinx.com>
This patch Adds the new compatible string for ZynqMP SoC.
Signed-off-by: Nava kishore Manne <navam@xilinx.com>
---
Changes for v6:
-Added New compatiable string for ZynqMP SoC as
suggested by Rob Herring.
Changes for v5:
-Mofified the compatible session.
Changes for v4:
-Modified the ChangeLog comment.
Changes for v3:
-Added changeLog comment.
Changes for v2:
-None
Documentation/devicetree/bindings/serial/cdns,uart.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.txt b/Documentation/devicetree/bindings/serial/cdns,uart.txt
index a3eb154..227bb77 100644
--- a/Documentation/devicetree/bindings/serial/cdns,uart.txt
+++ b/Documentation/devicetree/bindings/serial/cdns,uart.txt
@@ -1,7 +1,9 @@
Binding for Cadence UART Controller
Required properties:
-- compatible : should be "cdns,uart-r1p8", or "xlnx,xuartps"
+- compatible :
+ Use "xlnx,xuartps","cdns,uart-r1p8" for Zynq-7xxx SoC.
+ Use "xlnx,zynqmp-uart","cdns,uart-r1p12" for Zynq Ultrascale+ MPSoC.
- reg: Should contain UART controller registers location and length.
- interrupts: Should contain UART controller interrupts.
- clocks: Must contain phandles to the UART clocks
--
2.1.1
^ permalink raw reply related
* [PATCH v3 0/11] Add R8A7743/SK-RZG1M board support
From: Simon Horman @ 2016-10-12 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5be99d76-a082-129b-1aa6-b6f7402ae79b@cogentembedded.com>
On Fri, Oct 07, 2016 at 07:40:34PM +0300, Sergei Shtylyov wrote:
> On 10/06/2016 12:23 AM, Sergei Shtylyov wrote:
>
> > Here's the set of 11 patches against Simon Horman's 'renesas.git' repo's
> >'renesas-devel-20161003-v4.8' tag. I'm adding the device tree support for
> >the R8A7743-based SK-RZG1M board. The SoC is close to R8A7791 and the board
> >seems identical to the R8A7791/Porter board. The device tree patches depend on
> >the R8A7743 CPG/MSSR driver series just posted in order to compile and work.
>
> Forgot to mention that this version causes a regression with the sh_eth
> driver (well, actually with phylib): since IRQC now gets a deferred probing,
> PHY IRQ doesn't work anymore -- phylib falls back to polling.
Is there a resolution to that problem?
^ permalink raw reply
* [PATCH v3 1/4] net: phy: dp83867: Add documentation for optional impedance control
From: Mugunthan V N @ 2016-10-12 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161010131841.GA8391@rob-hp-laptop>
On Monday 10 October 2016 06:48 PM, Rob Herring wrote:
> On Thu, Oct 06, 2016 at 10:43:52AM +0530, Mugunthan V N wrote:
>> Add documention of ti,impedance-control which can be used to
>
> Needs updating.
Oops, will update this in next version.
>
>> correct MAC impedance mismatch using phy extended registers.
>>
>> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
>> ---
>> Documentation/devicetree/bindings/net/ti,dp83867.txt | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt
>> index 5d21141..85bf945 100644
>> --- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
>> +++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
>> @@ -9,6 +9,18 @@ Required properties:
>> - ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
>> for applicable values
>>
>> +Optional property:
>> + - ti,min-output-impedance - MAC Interface Impedance control to set
>> + the programmable output impedance to
>> + minimum value (35 ohms).
>> + - ti,max-output-impedance - MAC Interface Impedance control to set
>> + the programmable output impedance to
>> + maximum value (70 ohms).
>
> Define what are valid range of values for these.
The values are already mentioned in documentation as 35/70 ohms.
Are you mentioning about the register values?
Regards
Mugunthan V N
^ permalink raw reply
* [PATCH v3 0/11] Add R8A7743/SK-RZG1M board support
From: Sergei Shtylyov @ 2016-10-12 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161012080905.GD31183@verge.net.au>
On 10/12/2016 11:09 AM, Simon Horman wrote:
>>> Here's the set of 11 patches against Simon Horman's 'renesas.git' repo's
>>> 'renesas-devel-20161003-v4.8' tag. I'm adding the device tree support for
>>> the R8A7743-based SK-RZG1M board. The SoC is close to R8A7791 and the board
>>> seems identical to the R8A7791/Porter board. The device tree patches depend on
>>> the R8A7743 CPG/MSSR driver series just posted in order to compile and work.
>>
>> Forgot to mention that this version causes a regression with the sh_eth
>> driver (well, actually with phylib): since IRQC now gets a deferred probing,
>> PHY IRQ doesn't work anymore -- phylib falls back to polling.
>
> Is there a resolution to that problem?
Geert has posted his IRQC driver patch recently. Not sure if it was
intended for merging but it solves the issue.
MBR, Sergei
^ permalink raw reply
* [PATCH v4 10/10] ARM: sunxi: Enable sun8i-emac driver on multi_v7_defconfig
From: LABBE Corentin @ 2016-10-12 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161011094042.GS3462@lukather>
On Tue, Oct 11, 2016 at 11:40:42AM +0200, Maxime Ripard wrote:
> On Mon, Oct 10, 2016 at 03:09:43PM +0200, Jean-Francois Moine wrote:
> > On Mon, 10 Oct 2016 14:35:11 +0200
> > LABBE Corentin <clabbe.montjoie@gmail.com> wrote:
> >
> > > On Mon, Oct 10, 2016 at 02:30:46PM +0200, Maxime Ripard wrote:
> > > > On Fri, Oct 07, 2016 at 10:25:57AM +0200, Corentin Labbe wrote:
> > > > > Enable the sun8i-emac driver in the multi_v7 default configuration
> > > > >
> > > > > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > > > > ---
> > > > > arch/arm/configs/multi_v7_defconfig | 1 +
> > > > > 1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> > > > > index 5845910..f44d633 100644
> > > > > --- a/arch/arm/configs/multi_v7_defconfig
> > > > > +++ b/arch/arm/configs/multi_v7_defconfig
> > > > > @@ -229,6 +229,7 @@ CONFIG_NETDEVICES=y
> > > > > CONFIG_VIRTIO_NET=y
> > > > > CONFIG_HIX5HD2_GMAC=y
> > > > > CONFIG_SUN4I_EMAC=y
> > > > > +CONFIG_SUN8I_EMAC=y
> > > >
> > > > Any reason to build it statically?
> > >
> > > No, just copied the same than CONFIG_SUN4I_EMAC that probably do
> > > not need it also.
> >
> > All arm configs are done the same way, and, some day, the generic ARM
> > V7 kernel will not be loadable in 1Gb RAM...
>
> Yeah, if possible, I'd really like to avoid introducing statically
> built drivers to multi_v7.
>
I forgot to said it in my first answer, but yes I will change it.
Regards
^ permalink raw reply
* [patch] serial: stm32: fix a type issue
From: Russell King - ARM Linux @ 2016-10-12 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161012062103.GS12841@mwanda>
On Wed, Oct 12, 2016 at 09:21:03AM +0300, Dan Carpenter wrote:
> We store UNDEF_REG in a u8. It causes a problem in functions like
> stm32_tx_dma_complete() where we check "if (ofs->icr == UNDEF_REG)".
>
> Fixes: 3489187204eb ('serial: stm32: adding dma support')
Correct form is:
Fixes: 12-digit-hash ("summary line")
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v4 08/10] ARM: dts: sun8i: Enable sun8i-emac on the Orange Pi 2
From: Jean-Francois Moine @ 2016-10-12 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475828757-926-9-git-send-email-clabbe.montjoie@gmail.com>
On Fri, 7 Oct 2016 10:25:55 +0200
Corentin Labbe <clabbe.montjoie@gmail.com> wrote:
> The sun8i-emac hardware is present on the Orange PI 2.
> It uses the internal PHY.
>
> This patch create the needed emac node.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
> arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> index f93f5d1..5608eb4 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> @@ -54,6 +54,7 @@
>
> aliases {
> serial0 = &uart0;
> + ethernet0 = &emac;
As there is no 'of_alias_get_id' in the driver, this alias is useless.
> };
>
> chosen {
> @@ -184,3 +185,10 @@
> usb1_vbus-supply = <®_usb1_vbus>;
> status = "okay";
> };
> +
> +&emac {
> + phy-handle = <&int_mii_phy>;
> + phy-mode = "mii";
> + allwinner,leds-active-low;
> + status = "okay";
> +};
> --
> 2.7.3
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH 3/3] mtd: s3c2410: parse the device configuration from OF node
From: Boris Brezillon @ 2016-10-12 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475711217-974-4-git-send-email-sergio.prado@e-labworks.com>
Hi Sergio,
On Wed, 5 Oct 2016 20:46:57 -0300
Sergio Prado <sergio.prado@e-labworks.com> wrote:
> Allows configuring Samsung's s3c2410 memory controller using a
> devicetree.
>
> Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
> ---
> drivers/mtd/nand/s3c2410.c | 171 ++++++++++++++++++++++---
> include/linux/platform_data/mtd-nand-s3c2410.h | 1 +
> 2 files changed, 156 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mtd/nand/s3c2410.c b/drivers/mtd/nand/s3c2410.c
> index 174ac9dc4265..352cf2656bc8 100644
> --- a/drivers/mtd/nand/s3c2410.c
> +++ b/drivers/mtd/nand/s3c2410.c
[...]
> +
> +static int s3c2410_nand_init_timings(struct s3c2410_nand_info *info,
> + struct nand_chip *chip)
> +{
> + struct s3c2410_platform_nand *pdata = info->platform;
> + const struct nand_sdr_timings *t;
> + int tacls, mode;
> +
> + mode = onfi_get_async_timing_mode(chip);
> + if (mode == ONFI_TIMING_MODE_UNKNOWN)
> + mode = chip->onfi_timing_mode_default;
> +
> + t = onfi_async_timing_mode_to_sdr_timings(mode);
> + if (IS_ERR(t))
> + return PTR_ERR(t);
We recently introduced an method to automate timing selection and
configuration [1]. Can you switch to this approach (the changes are in
the nand/next branch [2] and should appear in 4.9-rc1)?
Thanks,
Boris
[1]https://www.spinics.net/lists/arm-kernel/msg532007.html
[2]https://github.com/linux-nand/linux/tree/nand/next
^ permalink raw reply
* [PATCH v4 08/10] ARM: dts: sun8i: Enable sun8i-emac on the Orange Pi 2
From: Maxime Ripard @ 2016-10-12 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161012105559.aaf9122e376fa5969a2e61d9@free.fr>
On Wed, Oct 12, 2016 at 10:55:59AM +0200, Jean-Francois Moine wrote:
> On Fri, 7 Oct 2016 10:25:55 +0200
> Corentin Labbe <clabbe.montjoie@gmail.com> wrote:
>
> > The sun8i-emac hardware is present on the Orange PI 2.
> > It uses the internal PHY.
> >
> > This patch create the needed emac node.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> > index f93f5d1..5608eb4 100644
> > --- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> > +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> > @@ -54,6 +54,7 @@
> >
> > aliases {
> > serial0 = &uart0;
> > + ethernet0 = &emac;
>
> As there is no 'of_alias_get_id' in the driver, this alias is
> useless.
Not really, this is used by U-Boot to set the mac address.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161012/982f5d88/attachment.sig>
^ permalink raw reply
* [patch] serial: stm32: fix a type issue
From: Dan Carpenter @ 2016-10-12 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161012085239.GD1041@n2100.armlinux.org.uk>
On Wed, Oct 12, 2016 at 09:52:39AM +0100, Russell King - ARM Linux wrote:
> On Wed, Oct 12, 2016 at 09:21:03AM +0300, Dan Carpenter wrote:
> > We store UNDEF_REG in a u8. It causes a problem in functions like
> > stm32_tx_dma_complete() where we check "if (ofs->icr == UNDEF_REG)".
> >
> > Fixes: 3489187204eb ('serial: stm32: adding dma support')
>
> Correct form is:
>
> Fixes: 12-digit-hash ("summary line")
When I originally created the Fixes tag format, I used single quotes.
I don't remember why though and I can change with the times. :)
regards,
dan carpenter
^ permalink raw reply
* [RFC 0/1] misc: Add Allwinner Q8 tablet hardware manager
From: Mark Rutland @ 2016-10-12 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJVkPPiDh66nhfh0D7BvkZ7KKN0X7uhfPGgiYbc2Ca1rg@mail.gmail.com>
Hi,
On Fri, Sep 09, 2016 at 04:32:06PM -0500, Rob Herring wrote:
> On Thu, Sep 1, 2016 at 2:08 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> > Hi All,
> >
> > Here is a first RFC for the q8 tablet hw-manager I've been talking
> > about for a while now.
> >
> > The touchscreen part is finished, I'll start working on the
> > accelerometer bits next.
>
> This at least partially overlaps with the "overlay manager" just
> posted. A dev board having different devices attached and a production
> device have 2nd source components are not really different problems.
> We need a common solution and can't have each platform making up their
> own scheme.
To follow up discussions at ELC-E, I agree that we need a common solution (if
this has to happen in the kernel rather than in an earlier stage of the boot
process).
Otherwise, we're creating pseudo-board-files, and a whole new set of problems
for ourselves.
Thanks
Mark.
^ permalink raw reply
* [PATCH] drm/bridge: analogix: protect power when get_modes or detect
From: Mark Yao @ 2016-10-12 10:00 UTC (permalink / raw)
To: linux-arm-kernel
The drm callback ->detect and ->get_modes seems is not power safe,
they may be called when device is power off, do register access on
detect or get_modes will cause system die.
Here is the path call ->detect before analogix_dp power on
[<ffffff800843babc>] analogix_dp_detect+0x44/0xdc
[<ffffff80083fd840>] drm_helper_probe_single_connector_modes_merge_bits+0xe8/0x41c
[<ffffff80083fdb84>] drm_helper_probe_single_connector_modes+0x10/0x18
[<ffffff8008418d24>] drm_mode_getconnector+0xf4/0x304
[<ffffff800840cff0>] drm_ioctl+0x23c/0x390
[<ffffff80081a8adc>] do_vfs_ioctl+0x4b8/0x58c
[<ffffff80081a8c10>] SyS_ioctl+0x60/0x88
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Cc: "Ville Syrj?l?" <ville.syrjala@linux.intel.com>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index efac8ab..09dece2 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1062,6 +1062,13 @@ int analogix_dp_get_modes(struct drm_connector *connector)
return 0;
}
+ if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
+ pm_runtime_get_sync(dp->dev);
+
+ if (dp->plat_data->power_on)
+ dp->plat_data->power_on(dp->plat_data);
+ }
+
if (analogix_dp_handle_edid(dp) == 0) {
drm_mode_connector_update_edid_property(&dp->connector, edid);
num_modes += drm_add_edid_modes(&dp->connector, edid);
@@ -1073,6 +1080,13 @@ int analogix_dp_get_modes(struct drm_connector *connector)
if (dp->plat_data->get_modes)
num_modes += dp->plat_data->get_modes(dp->plat_data, connector);
+ if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
+ if (dp->plat_data->power_off)
+ dp->plat_data->power_off(dp->plat_data);
+
+ pm_runtime_put_sync(dp->dev);
+ }
+
ret = analogix_dp_prepare_panel(dp, false, false);
if (ret)
DRM_ERROR("Failed to unprepare panel (%d)\n", ret);
@@ -1106,9 +1120,23 @@ analogix_dp_detect(struct drm_connector *connector, bool force)
return connector_status_disconnected;
}
+ if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
+ pm_runtime_get_sync(dp->dev);
+
+ if (dp->plat_data->power_on)
+ dp->plat_data->power_on(dp->plat_data);
+ }
+
if (!analogix_dp_detect_hpd(dp))
status = connector_status_connected;
+ if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
+ if (dp->plat_data->power_off)
+ dp->plat_data->power_off(dp->plat_data);
+
+ pm_runtime_put_sync(dp->dev);
+ }
+
ret = analogix_dp_prepare_panel(dp, false, false);
if (ret)
DRM_ERROR("Failed to unprepare panel (%d)\n", ret);
--
1.9.1
^ permalink raw reply related
* [PATCH v3 07/11] arm64/tracing: fix compat syscall handling
From: Will Deacon @ 2016-10-12 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fed0151c-ebfd-18d2-939c-21e315dc7584@imgtec.com>
On Wed, Oct 12, 2016 at 09:07:03AM +0200, Marcin Nowakowski wrote:
> On 11.10.2016 15:36, Will Deacon wrote:
> >On Tue, Oct 11, 2016 at 12:42:52PM +0200, Marcin Nowakowski wrote:
> >>diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h
> >>index e78ac26..276d049 100644
> >>--- a/arch/arm64/include/asm/unistd.h
> >>+++ b/arch/arm64/include/asm/unistd.h
> >>@@ -45,6 +45,7 @@
> >> #define __ARM_NR_compat_set_tls (__ARM_NR_COMPAT_BASE+5)
> >>
> >> #define __NR_compat_syscalls 394
> >>+#define NR_compat_syscalls (__NR_compat_syscalls)
> >
> >We may as well just define NR_compat_syscalls instead of
> >__NR_compat_syscalls and move the handful of users over.
>
> I had tried to minimise the amount of arch-specific changes here -
> especially those that are not directly related to the proposed syscall
> handling change. But I agree having these 2 #defines is a bit unnecessary
There's only three users of __NR_compat_syscalls, so I think you can
move them over.
> >>diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
> >>index 40ad08a..75d010f 100644
> >>--- a/arch/arm64/kernel/ftrace.c
> >>+++ b/arch/arm64/kernel/ftrace.c
> >>@@ -176,4 +176,20 @@ int ftrace_disable_ftrace_graph_caller(void)
> >> return ftrace_modify_graph_caller(false);
> >> }
> >> #endif /* CONFIG_DYNAMIC_FTRACE */
> >>+
> >> #endif /* CONFIG_FUNCTION_GRAPH_TRACER */
> >>+
> >>+#if (defined CONFIG_FTRACE_SYSCALLS) && (defined CONFIG_COMPAT)
> >>+
> >>+extern const void *sys_call_table[];
> >>+extern const void *compat_sys_call_table[];
> >>+
> >>+unsigned long __init arch_syscall_addr(int nr, bool compat)
> >>+{
> >>+ if (compat)
> >>+ return (unsigned long)compat_sys_call_table[nr];
> >>+
> >>+ return (unsigned long)sys_call_table[nr];
> >>+}
> >
> >Do we care about the compat private syscalls (from base 0x0f0000)? We
> >need to make sure that we exhibit the same behaviour as a native
> >32-bit ARM machine.
> >
> >Will
>
> Tracing of such syscalls has been disabled for a long time (see
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=086ba77a6db0).
> Apart from using non-contiguous numbers, they are not defined using standard
> SYSCALL macros, so they do not have any metadata generated either.
> My suggestion is that if you wanted those to be included in the trace then
> it should be done separately from these changes.
Fine by me -- I just wanted to make sure our compat behaviour matched
the behaviour of native arch/arm/. It sounds like it does, so no need to
change anything here.
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH v7 2/8] power: add power sequence library
From: Heiko Stuebner @ 2016-10-12 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474342607-27512-3-git-send-email-peter.chen@nxp.com>
Hi,
Am Dienstag, 20. September 2016, 11:36:41 CEST schrieb Peter Chen:
> We have an well-known problem that the device needs to do some power
> sequence before it can be recognized by related host, the typical
> example like hard-wired mmc devices and usb devices.
>
> This power sequence is hard to be described at device tree and handled by
> related host driver, so we have created a common power sequence
> library to cover this requirement. The core code has supplied
> some common helpers for host driver, and individual power sequence
> libraries handle kinds of power sequence for devices.
>
> pwrseq_generic is intended for general purpose of power sequence, which
> handles gpios and clocks currently, and can cover regulator and pinctrl
> in future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> if only one power sequence is needed, else call of_pwrseq_on_list
> /of_pwrseq_off_list instead (eg, USB hub driver).
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> Tested-by Joshua Clayton <stillcompiling@gmail.com>
> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> Tested-by: Matthias Kaehlcke <mka@chromium.org>
first of all, glad to see this move forward. I've only some qualms with the
static number of allocated power sequences below.
[...]
> diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig
> new file mode 100644
> index 0000000..dff5e35
> --- /dev/null
> +++ b/drivers/power/pwrseq/Kconfig
> @@ -0,0 +1,45 @@
> +#
> +# Power Sequence library
> +#
> +
> +config POWER_SEQUENCE
> + bool
> +
> +menu "Power Sequence Support"
> +
> +config PWRSEQ_GENERIC
> + bool "Generic power sequence control"
> + depends on OF
> + select POWER_SEQUENCE
> + help
> + It is used for drivers which needs to do power sequence
> + (eg, turn on clock, toggle reset gpio) before the related
> + devices can be found by hardware. This generic one can be
> + used for common power sequence control.
> +
> +config PWRSEQ_GENERIC_INSTANCE_NUMBER
> + int "Number of Generic Power Sequence Instance"
> + depends on PWRSEQ_GENERIC
> + range 1 10
> + default 2
> + help
> + Usually, there are not so many devices needs power sequence, we set two
> + as default value.
limiting this to some arbitary compile-time number somehow seems crippling for
the single-image approach. I.e. a distribution might select something and
during its lifetime the board requiring n+1 power-sequences appears and thus
needs a different kernel version just to support that additional sequence.
Also, board designers are creative, and there were already complex examples
mentioned elsewhere, so nothing keeps people from inventing something even
more complex.
[...]
> diff --git a/drivers/power/pwrseq/pwrseq_generic.c
> b/drivers/power/pwrseq/pwrseq_generic.c new file mode 100644
> index 0000000..bcd16c3
> --- /dev/null
> +++ b/drivers/power/pwrseq/pwrseq_generic.c
[...]
> +static int pwrseq_generic_get(struct device_node *np, struct pwrseq
> *pwrseq) +{
> + struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> + enum of_gpio_flags flags;
> + int reset_gpio, clk, ret = 0;
> +
> + for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++) {
> + pwrseq_gen->clks[clk] = of_clk_get(np, clk);
> + if (IS_ERR(pwrseq_gen->clks[clk])) {
> + ret = PTR_ERR(pwrseq_gen->clks[clk]);
> + if (ret != -ENOENT)
> + goto err_put_clks;
> + pwrseq_gen->clks[clk] = NULL;
> + break;
> + }
> + }
> +
> + reset_gpio = of_get_named_gpio_flags(np, "reset-gpios", 0, &flags);
> + if (gpio_is_valid(reset_gpio)) {
> + unsigned long gpio_flags;
> +
> + if (flags & OF_GPIO_ACTIVE_LOW)
> + gpio_flags = GPIOF_ACTIVE_LOW | GPIOF_OUT_INIT_LOW;
> + else
> + gpio_flags = GPIOF_OUT_INIT_HIGH;
> +
> + ret = gpio_request_one(reset_gpio, gpio_flags,
> + "pwrseq-reset-gpios");
> + if (ret)
> + goto err_put_clks;
> +
> + pwrseq_gen->gpiod_reset = gpio_to_desc(reset_gpio);
> + of_property_read_u32(np, "reset-duration-us",
> + &pwrseq_gen->duration_us);
> + } else {
> + if (reset_gpio == -ENOENT)
> + return 0;
> +
> + ret = reset_gpio;
> + pr_err("Failed to get reset gpio on %s, err = %d\n",
> + np->full_name, reset_gpio);
> + goto err_put_clks;
> + }
> +
> + return ret;
> +
> +err_put_clks:
> + while (--clk >= 0)
> + clk_put(pwrseq_gen->clks[clk]);
> + return ret;
> +}
> +
> +static const struct of_device_id generic_id_table[] = {
> + { .compatible = "generic",},
> + { /* sentinel */ }
> +};
> +
> +static int __init pwrseq_generic_register(void)
> +{
> + struct pwrseq_generic *pwrseq_gen;
> + int i;
> +
> + for (i = 0; i < CONFIG_PWRSEQ_GENERIC_INSTANCE_NUMBER; i++) {
> + pwrseq_gen = kzalloc(sizeof(*pwrseq_gen), GFP_KERNEL);
> + if (!pwrseq_gen)
> + return -ENOMEM;
> +
> + pwrseq_gen->pwrseq.pwrseq_of_match_table = generic_id_table;
> + pwrseq_gen->pwrseq.get = pwrseq_generic_get;
> + pwrseq_gen->pwrseq.on = pwrseq_generic_on;
> + pwrseq_gen->pwrseq.off = pwrseq_generic_off;
> + pwrseq_gen->pwrseq.put = pwrseq_generic_put;
> + pwrseq_gen->pwrseq.free = pwrseq_generic_free;
> +
> + pwrseq_register(&pwrseq_gen->pwrseq);
> + }
> +
> + return 0;
> +}
> +postcore_initcall(pwrseq_generic_register)
I see that you need to have it preallocated for the compatible matching, but
wouldn't it also work to either just register the type and allocate
dynamically or otherwise just allocate a new spare everytime
pwrseq_generic_get() picks up the previous spare?
That way the total number of power sequences can still be dynamic without
haggling over how many power sequences should be the build-default in the
generic configs.
^ 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