[PATCH v17 05/11] ARM: kprobes: disallow probing stack consuming instructions
This patch prohibits probing instructions for which the stack
requirements are unable to be determined statically. Some test cases
are found not work again after the modification, this patch also
removes them.
Signed-off-by: Wang Nan
Reviewed-by: Jon Medhurst
---
arch/arm/include/asm/kprobes.h | 1 -
arch/arm/include/asm/probes.h | 12
arch/arm/kernel/entry-armv.S | 3 ++-
arch/arm/probes/kprobes/core.c | 9 +
arch/arm/probes/kprobes/test-arm.c | 16 ++--
5 files changed, 33 insertions(+), 8 deletions(-)
diff --git a/arch/arm/include/asm/kprobes.h b/arch/arm/include/asm/kprobes.h
index 49fa0df..56f9ac6 100644
--- a/arch/arm/include/asm/kprobes.h
+++ b/arch/arm/include/asm/kprobes.h
@@ -22,7 +22,6 @@
#define __ARCH_WANT_KPROBES_INSN_SLOT
#define MAX_INSN_SIZE 2
-#define MAX_STACK_SIZE 64 /* 32 would probably be OK */
#define flush_insn_slot(p) do { } while (0)
#define kretprobe_blacklist_size 0
diff --git a/arch/arm/include/asm/probes.h b/arch/arm/include/asm/probes.h
index ccf9af3..f0a1ee8 100644
--- a/arch/arm/include/asm/probes.h
+++ b/arch/arm/include/asm/probes.h
@@ -19,6 +19,8 @@
#ifndef _ASM_PROBES_H
#define _ASM_PROBES_H
+#ifndef __ASSEMBLY__
+
typedef u32 probes_opcode_t;
struct arch_probes_insn;
@@ -41,4 +43,14 @@ struct arch_probes_insn {
int stack_space;
};
+#endif /* __ASSEMBLY__ */
+
+/*
+ * We assume one instruction can consume at most 64 bytes stack, which is
+ * 'push {r0-r15}'. Instructions consume more or unknown stack space like
+ * 'str r0, [sp, #-80]' and 'str r0, [sp, r1]' should be prohibit to probe.
+ * Both kprobe and jprobe use this macro.
+ */
+#define MAX_STACK_SIZE 64
+
#endif
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 2fd..672b219 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -31,6 +31,7 @@
#include "entry-header.S"
#include
+#include
/*
* Interrupt handling.
@@ -249,7 +250,7 @@ __und_svc:
@ If a kprobe is about to simulate a "stmdb sp..." instruction,
@ it obviously needs free stack space which then will belong to
@ the saved context.
- svc_entry 64
+ svc_entry MAX_STACK_SIZE
#else
svc_entry
#endif
diff --git a/arch/arm/probes/kprobes/core.c b/arch/arm/probes/kprobes/core.c
index 74f3dc3..3a58db4 100644
--- a/arch/arm/probes/kprobes/core.c
+++ b/arch/arm/probes/kprobes/core.c
@@ -115,6 +115,15 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
break;
}
+ /*
+* Never instrument insn like 'str r0, [sp, +/-r1]'. Also, insn likes
+* 'str r0, [sp, #-68]' should also be prohibited.
+* See __und_svc.
+*/
+ if ((p->ainsn.stack_space < 0) ||
+ (p->ainsn.stack_space > MAX_STACK_SIZE))
+ return -EINVAL;
+
return 0;
}
diff --git a/arch/arm/probes/kprobes/test-arm.c
b/arch/arm/probes/kprobes/test-arm.c
index d9a1255..fdeb300 100644
--- a/arch/arm/probes/kprobes/test-arm.c
+++ b/arch/arm/probes/kprobes/test-arm.c
@@ -476,7 +476,8 @@ void kprobe_arm_test_cases(void)
TEST_GROUP("Extra load/store instructions")
TEST_RPR( "strhr",0, VAL1,", [r",1, 48,", -r",2, 24,"]")
- TEST_RPR( "streqh r",14,VAL2,", [r",13,0, ", r",12, 48,"]")
+ TEST_RPR( "streqh r",14,VAL2,", [r",11,0, ", r",12, 48,"]")
+ TEST_UNSUPPORTED( "streqh r14, [r13, r12]")
TEST_RPR( "strhr",1, VAL1,", [r",2, 24,", r",3, 48,"]!")
TEST_RPR( "strneh r",12,VAL2,", [r",11,48,", -r",10,24,"]!")
TEST_RPR( "strhr",2, VAL1,", [r",3, 24,"], r",4, 48,"")
@@ -565,7 +566,8 @@ void kprobe_arm_test_cases(void)
#if __LINUX_ARM_ARCH__ >= 5
TEST_RPR( "strdr",0, VAL1,", [r",1, 48,", -r",2,24,"]")
- TEST_RPR( "strccd r",8, VAL2,", [r",13,0, ", r",12,48,"]")
+ TEST_RPR( "strccd r",8, VAL2,", [r",11,0, ", r",12,48,"]")
+ TEST_UNSUPPORTED( "strccd r8, [r13, r12]")
TEST_RPR( "strdr",4, VAL1,", [r",2, 24,", r",3, 48,"]!")
TEST_RPR( "strcsd r",12,VAL2,", [r",11,48,", -r",10,24,"]!")
TEST_RPR( "strdr",2, VAL1,", [r",5, 24,"], r",4,48,"")
@@ -638,13 +640,15 @@ void kprobe_arm_test_cases(void)
TEST_RP( "str"byte" r",2, VAL1,", [r",3, 24,"], #48")
\
TEST_RP( "str"byte" r",10,VAL2,", [r",9, 64,"], #-48")
\
TEST_RPR("str"byte" r",0, VAL1,", [r",1, 48,", -r",2, 24,"]")
\
- TEST_RPR("str"byte" r",14,VAL2,", [r",13,0, ", r",12, 48,"]")
\
+ TEST_RPR("str"byte" r",14,VAL2,", [r",11,0, ", r",12, 48,"]")
\
+ TEST_UNSUPPORTED("str"byte" r14, [r13, r12]") \
TEST_RPR("str"byte" r",1, VAL1,", [r",2, 24,", r",3, 48,"]!")
\
T
[PATCH v17 09/11] ARM: kprobes: Fix unreliable MRS instruction tests
From: "Jon Medhurst (Tixy)"
For the instruction 'mrs Rn, cpsr' the resulting value of Rn can vary due to
external factors we can't control. So get the test code to mask out these
indeterminate bits.
Signed-off-by: Jon Medhurst
---
arch/arm/probes/kprobes/test-arm.c | 6 +++---
arch/arm/probes/kprobes/test-core.c | 19 ++-
arch/arm/probes/kprobes/test-core.h | 33 -
arch/arm/probes/kprobes/test-thumb.c | 4 ++--
4 files changed, 43 insertions(+), 19 deletions(-)
diff --git a/arch/arm/probes/kprobes/test-arm.c
b/arch/arm/probes/kprobes/test-arm.c
index 9b3b1b4..e72b07e 100644
--- a/arch/arm/probes/kprobes/test-arm.c
+++ b/arch/arm/probes/kprobes/test-arm.c
@@ -204,9 +204,9 @@ void kprobe_arm_test_cases(void)
#endif
TEST_GROUP("Miscellaneous instructions")
- TEST("mrs r0, cpsr")
- TEST("mrspl r7, cpsr")
- TEST("mrs r14, cpsr")
+ TEST_RMASKED("mrs r",0,~PSR_IGNORE_BITS,", cpsr")
+ TEST_RMASKED("mrspl r",7,~PSR_IGNORE_BITS,", cpsr")
+ TEST_RMASKED("mrs r",14,~PSR_IGNORE_BITS,", cpsr")
TEST_UNSUPPORTED(__inst_arm(0xe10ff000) " @ mrs r15, cpsr")
TEST_UNSUPPORTED("mrs r0, spsr")
TEST_UNSUPPORTED("mrs lr, spsr")
diff --git a/arch/arm/probes/kprobes/test-core.c
b/arch/arm/probes/kprobes/test-core.c
index 7c5ddd5..e495127 100644
--- a/arch/arm/probes/kprobes/test-core.c
+++ b/arch/arm/probes/kprobes/test-core.c
@@ -1056,15 +1056,6 @@ static int test_case_run_count;
static bool test_case_is_thumb;
static int test_instance;
-/*
- * We ignore the state of the imprecise abort disable flag (CPSR.A) because
this
- * can change randomly as the kernel doesn't take care to preserve or
initialise
- * this across context switches. Also, with Security Extentions, the flag may
- * not be under control of the kernel; for this reason we ignore the state of
- * the FIQ disable flag CPSR.F as well.
- */
-#define PSR_IGNORE_BITS (PSR_A_BIT | PSR_F_BIT)
-
static unsigned long test_check_cc(int cc, unsigned long cpsr)
{
int ret = arm_check_condition(cc << 28, cpsr);
@@ -1271,11 +1262,21 @@ test_case_pre_handler(struct kprobe *p, struct pt_regs
*regs)
static int __kprobes
test_after_pre_handler(struct kprobe *p, struct pt_regs *regs)
{
+ struct test_arg *args;
+
if (container_of(p, struct test_probe, kprobe)->hit == test_instance)
return 0; /* Already run for this test instance */
result_regs = *regs;
+
+ /* Mask out results which are indeterminate */
result_regs.ARM_cpsr &= ~PSR_IGNORE_BITS;
+ for (args = current_args; args[0].type != ARG_TYPE_END; ++args)
+ if (args[0].type == ARG_TYPE_REG_MASKED) {
+ struct test_arg_regptr *arg =
+ (struct test_arg_regptr *)args;
+ result_regs.uregs[arg->reg] &= arg->val;
+ }
/* Undo any changes done to SP by the test case */
regs->ARM_sp = (unsigned long)current_stack;
diff --git a/arch/arm/probes/kprobes/test-core.h
b/arch/arm/probes/kprobes/test-core.h
index 9991754..9428520 100644
--- a/arch/arm/probes/kprobes/test-core.h
+++ b/arch/arm/probes/kprobes/test-core.h
@@ -45,10 +45,11 @@ extern int kprobe_test_cc_position;
*
*/
-#defineARG_TYPE_END0
-#defineARG_TYPE_REG1
-#defineARG_TYPE_PTR2
-#defineARG_TYPE_MEM3
+#defineARG_TYPE_END0
+#defineARG_TYPE_REG1
+#defineARG_TYPE_PTR2
+#defineARG_TYPE_MEM3
+#defineARG_TYPE_REG_MASKED 4
#define ARG_FLAG_UNSUPPORTED 0x01
#define ARG_FLAG_SUPPORTED 0x02
@@ -61,7 +62,7 @@ struct test_arg {
};
struct test_arg_regptr {
- u8 type; /* ARG_TYPE_REG or ARG_TYPE_PTR */
+ u8 type; /* ARG_TYPE_REG or ARG_TYPE_PTR or
ARG_TYPE_REG_MASKED */
u8 reg;
u8 _padding[2];
u32 val;
@@ -138,6 +139,12 @@ struct test_arg_end {
".short 0 \n\t" \
".word "#val" \n\t"
+#defineTEST_ARG_REG_MASKED(reg, val) \
+ ".byte "__stringify(ARG_TYPE_REG_MASKED)" \n\t" \
+ ".byte "#reg" \n\t" \
+ ".short 0 \n\t" \
+ ".word "#val" \n\t"
+
#defineTEST_ARG_END(flags) \
".byte "__stringify(ARG_TYPE_END)" \n\t" \
".byte "TEST_ISA flags"\n\t" \
@@ -395,6 +402,22 @@ struct test_arg_end {
" "codex" \n\t"
\
TESTCASE_END
+#define TEST_RMASKED(code1, reg, mask, code2)
[PATCH v17 03/11] ARM: kprobes: introduces checker
This patch introdces 'checker' to decoding phase, and calls checkers
when instruction decoding. This allows further decoding for specific
instructions. This patch introduces a stub call of checkers in kprobe
arch_prepare_kprobe() as an example and for further expansion.
Signed-off-by: Wang Nan
Reviewed-by: Jon Medhurst
Reviewed-by: Masami Hiramatsu
---
arch/arm/probes/decode-arm.c| 5 +--
arch/arm/probes/decode-arm.h| 3 +-
arch/arm/probes/decode-thumb.c | 10 +++---
arch/arm/probes/decode-thumb.h | 6 ++--
arch/arm/probes/decode.c| 60 +
arch/arm/probes/decode.h| 11 +-
arch/arm/probes/kprobes/actions-arm.c | 2 ++
arch/arm/probes/kprobes/actions-thumb.c | 3 ++
arch/arm/probes/kprobes/core.c | 6 +++-
arch/arm/probes/kprobes/core.h | 7 ++--
arch/arm/probes/uprobes/core.c | 2 +-
11 files changed, 95 insertions(+), 20 deletions(-)
diff --git a/arch/arm/probes/decode-arm.c b/arch/arm/probes/decode-arm.c
index e39cc75..f46d8fc 100644
--- a/arch/arm/probes/decode-arm.c
+++ b/arch/arm/probes/decode-arm.c
@@ -726,10 +726,11 @@ static void __kprobes arm_singlestep(probes_opcode_t insn,
*/
enum probes_insn __kprobes
arm_probes_decode_insn(probes_opcode_t insn, struct arch_probes_insn *asi,
- bool emulate, const union decode_action *actions)
+ bool emulate, const union decode_action *actions,
+ const struct decode_checker *checkers[])
{
asi->insn_singlestep = arm_singlestep;
asi->insn_check_cc = probes_condition_checks[insn>>28];
return probes_decode_insn(insn, asi, probes_decode_arm_table, false,
- emulate, actions);
+ emulate, actions, checkers);
}
diff --git a/arch/arm/probes/decode-arm.h b/arch/arm/probes/decode-arm.h
index f0dbc5a..e4b87fe 100644
--- a/arch/arm/probes/decode-arm.h
+++ b/arch/arm/probes/decode-arm.h
@@ -67,6 +67,7 @@ extern const union decode_item probes_decode_arm_table[];
enum probes_insn arm_probes_decode_insn(probes_opcode_t,
struct arch_probes_insn *, bool emulate,
- const union decode_action *actions);
+ const union decode_action *actions,
+ const struct decode_checker *checkers[]);
#endif
diff --git a/arch/arm/probes/decode-thumb.c b/arch/arm/probes/decode-thumb.c
index 2f0453a..985e7dd 100644
--- a/arch/arm/probes/decode-thumb.c
+++ b/arch/arm/probes/decode-thumb.c
@@ -863,20 +863,22 @@ static void __kprobes thumb32_singlestep(probes_opcode_t
opcode,
enum probes_insn __kprobes
thumb16_probes_decode_insn(probes_opcode_t insn, struct arch_probes_insn *asi,
- bool emulate, const union decode_action *actions)
+ bool emulate, const union decode_action *actions,
+ const struct decode_checker *checkers[])
{
asi->insn_singlestep = thumb16_singlestep;
asi->insn_check_cc = thumb_check_cc;
return probes_decode_insn(insn, asi, probes_decode_thumb16_table, true,
- emulate, actions);
+ emulate, actions, checkers);
}
enum probes_insn __kprobes
thumb32_probes_decode_insn(probes_opcode_t insn, struct arch_probes_insn *asi,
- bool emulate, const union decode_action *actions)
+ bool emulate, const union decode_action *actions,
+ const struct decode_checker *checkers[])
{
asi->insn_singlestep = thumb32_singlestep;
asi->insn_check_cc = thumb_check_cc;
return probes_decode_insn(insn, asi, probes_decode_thumb32_table, true,
- emulate, actions);
+ emulate, actions, checkers);
}
diff --git a/arch/arm/probes/decode-thumb.h b/arch/arm/probes/decode-thumb.h
index 039013c..8457add 100644
--- a/arch/arm/probes/decode-thumb.h
+++ b/arch/arm/probes/decode-thumb.h
@@ -91,9 +91,11 @@ extern const union decode_item probes_decode_thumb16_table[];
enum probes_insn __kprobes
thumb16_probes_decode_insn(probes_opcode_t insn, struct arch_probes_insn *asi,
- bool emulate, const union decode_action *actions);
+ bool emulate, const union decode_action *actions,
+ const struct decode_checker *checkers[]);
enum probes_insn __kprobes
thumb32_probes_decode_insn(probes_opcode_t insn, struct arch_probes_insn *asi,
- bool emulate, const union decode_action *actions);
+ bool emulate, const union decode_action *actions,
+ const struct decode_checker *checkers[]);
#endif
diff --git a/arch/arm/probes/decode.c b/arch/arm/probes/decode.c
index 3b05d57..c7d4420 100644
--- a/arch/arm/probes/decode.c
+++ b/arch/arm/probes/decode.c
@@ -342,6 +342,31 @@
[PATCH v17 10/11] ARM: kprobes: check register usage for probed instruction.
This patch utilizes previous introduced checker to check register usage
for probed ARM instruction and saves it in a mask. Futher patch will
use such information to avoid simuation or emulation.
Signed-off-by: Wang Nan
---
arch/arm/include/asm/probes.h | 9 +++
arch/arm/probes/decode.c | 7 ++
arch/arm/probes/kprobes/actions-arm.c | 2 +-
arch/arm/probes/kprobes/checkers-arm.c | 124 +
arch/arm/probes/kprobes/checkers.h | 1 +
5 files changed, 142 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/probes.h b/arch/arm/include/asm/probes.h
index f0a1ee8..ee8725c 100644
--- a/arch/arm/include/asm/probes.h
+++ b/arch/arm/include/asm/probes.h
@@ -41,6 +41,15 @@ struct arch_probes_insn {
probes_insn_singlestep_t*insn_singlestep;
probes_insn_fn_t*insn_fn;
int stack_space;
+
+ /* Use 2 bits for a register. One more bit for extension */
+#define REG_NO_USE (0)
+#define REG_USE(1)
+#define __set_register_flag(m, n, f) do {(m) = (m) | ((f) << ((n) * 2));}
while(0)
+#define __clear_register_flag(m, n, f) do {(m) = (m) & (~((f) << ((n) * 2)));}
while(0)
+#define set_register_nouse(m, n) __clear_register_flag(m, n, REG_NO_USE)
+#define set_register_use(m, n) __set_register_flag(m, n, REG_USE)
+ int register_usage_mask;
};
#endif /* __ASSEMBLY__ */
diff --git a/arch/arm/probes/decode.c b/arch/arm/probes/decode.c
index f9d7c42..d60a1b2 100644
--- a/arch/arm/probes/decode.c
+++ b/arch/arm/probes/decode.c
@@ -435,6 +435,13 @@ probes_decode_insn(probes_opcode_t insn, struct
arch_probes_insn *asi,
*/
asi->stack_space = 0;
+ /*
+* Similay to stack_space, register_usage_mask is filled by
+* checkers. Its default value is set to ~0, which is 'all
+* registers are used', to prevent any potential optimization.
+*/
+ asi->register_usage_mask = ~(0UL);
+
if (emulate)
insn = prepare_emulated_insn(insn, asi, thumb);
diff --git a/arch/arm/probes/kprobes/actions-arm.c
b/arch/arm/probes/kprobes/actions-arm.c
index 4fedd4c..26e435b 100644
--- a/arch/arm/probes/kprobes/actions-arm.c
+++ b/arch/arm/probes/kprobes/actions-arm.c
@@ -340,4 +340,4 @@ const union decode_action
kprobes_arm_actions[NUM_PROBES_ARM_ACTIONS] = {
[PROBES_LDMSTM] = {.decoder = kprobe_decode_ldmstm}
};
-const struct decode_checker *kprobes_arm_checkers[] = {arm_stack_checker,
NULL};
+const struct decode_checker *kprobes_arm_checkers[] = {arm_stack_checker,
arm_regs_checker, NULL};
diff --git a/arch/arm/probes/kprobes/checkers-arm.c
b/arch/arm/probes/kprobes/checkers-arm.c
index f817663..df1d77b 100644
--- a/arch/arm/probes/kprobes/checkers-arm.c
+++ b/arch/arm/probes/kprobes/checkers-arm.c
@@ -97,3 +97,127 @@ const struct decode_checker
arm_stack_checker[NUM_PROBES_ARM_ACTIONS] = {
[PROBES_STORE] = {.checker = arm_check_stack},
[PROBES_LDMSTM] = {.checker = arm_check_stack},
};
+
+static enum probes_insn __kprobes arm_check_regs_nouse(probes_opcode_t insn,
+ struct arch_probes_insn *asi,
+ const struct decode_header *h)
+{
+ asi->register_usage_mask = 0;
+ return INSN_GOOD;
+}
+
+static void __arm_check_regs(probes_opcode_t insn,
+ const struct decode_header *h,
+ int *quintuple)
+{
+ int i;
+ u32 regs = h->type_regs.bits >> DECODE_TYPE_BITS;
+ probes_opcode_t mask, shifted;
+
+ memset(quintuple, 0xff, sizeof(int) * 5);
+ for (i = 0, shifted = insn, mask = 0xf; regs != 0;
+ regs >>= 4, mask <<= 4, shifted >>= 4, i++)
+ if (regs & 0xf)
+ quintuple[i] = shifted & 0xf;
+}
+
+static enum probes_insn arm_check_regs_normal(probes_opcode_t insn,
+ struct arch_probes_insn *asi,
+ const struct decode_header *h)
+{
+ int quintuple[5], i;
+ asi->register_usage_mask = 0;
+ __arm_check_regs(insn, h, quintuple);
+ for (i = 0; i < 5; i++) {
+ int r = quintuple[i];
+ if (r < 0)
+ continue;
+ set_register_use(asi->register_usage_mask, r);
+ }
+
+ return INSN_GOOD;
+}
+
+static enum probes_insn arm_check_regs_ldmstm(probes_opcode_t insn,
+ struct arch_probes_insn *asi,
+ const struct decode_header *h)
+{
+ unsigned int reglist = insn & 0x;
+ unsigned int rn = (insn >> 16) & 0xf;
+ int i;
+
+ set_register_use(asi->register_usage_mask, rn);
+ for (i = 0; reglist > 0; i++, reglist >>= 1)
+ if (reglist & 1)
+ set_register_use(asi->register_usage_mask, i);
+ return INSN_GOOD;
+}
+
+static enum probes_insn arm_check_regs_mov_ip_sp(probes_opcode_t insn,
+ struct arch_probes_insn *asi,
+ con
[PATCH v17 08/11] ARM: kprobes: enable OPTPROBES for ARM 32
This patch introduce kprobeopt for ARM 32.
Limitations:
- Currently only kernel compiled with ARM ISA is supported.
- Offset between probe point and optinsn slot must not larger than
32MiB. Masami Hiramatsu suggests replacing 2 words, it will make
things complex. Futher patch can make such optimization.
Kprobe opt on ARM is relatively simpler than kprobe opt on x86 because
ARM instruction is always 4 bytes aligned and 4 bytes long. This patch
replace probed instruction by a 'b', branch to trampoline code and then
calls optimized_callback(). optimized_callback() calls opt_pre_handler()
to execute kprobe handler. It also emulate/simulate replaced instruction.
When unregistering kprobe, the deferred manner of unoptimizer may leave
branch instruction before optimizer is called. Different from x86_64,
which only copy the probed insn after optprobe_template_end and
reexecute them, this patch call singlestep to emulate/simulate the insn
directly. Futher patch can optimize this behavior.
Signed-off-by: Wang Nan
Acked-by: Masami Hiramatsu
Cc: Jon Medhurst (Tixy)
Cc: Russell King - ARM Linux
Cc: Will Deacon
---
arch/arm/Kconfig| 1 +
arch/arm/{kernel => include/asm}/insn.h | 0
arch/arm/include/asm/kprobes.h | 29 +++
arch/arm/kernel/Makefile| 2 +-
arch/arm/kernel/ftrace.c| 3 +-
arch/arm/kernel/jump_label.c| 3 +-
arch/arm/probes/kprobes/Makefile| 1 +
arch/arm/probes/kprobes/core.c | 26 ++-
arch/arm/probes/kprobes/core.h | 2 +
arch/arm/probes/kprobes/opt-arm.c | 317
10 files changed, 372 insertions(+), 12 deletions(-)
rename arch/arm/{kernel => include/asm}/insn.h (100%)
create mode 100644 arch/arm/probes/kprobes/opt-arm.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 97d07ed..3d5dc2d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -60,6 +60,7 @@ config ARM
select HAVE_MEMBLOCK
select HAVE_MOD_ARCH_SPECIFIC if ARM_UNWIND
select HAVE_OPROFILE if (HAVE_PERF_EVENTS)
+ select HAVE_OPTPROBES if !THUMB2_KERNEL
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
diff --git a/arch/arm/kernel/insn.h b/arch/arm/include/asm/insn.h
similarity index 100%
rename from arch/arm/kernel/insn.h
rename to arch/arm/include/asm/insn.h
diff --git a/arch/arm/include/asm/kprobes.h b/arch/arm/include/asm/kprobes.h
index 56f9ac6..50ff3bc 100644
--- a/arch/arm/include/asm/kprobes.h
+++ b/arch/arm/include/asm/kprobes.h
@@ -50,5 +50,34 @@ int kprobe_fault_handler(struct pt_regs *regs, unsigned int
fsr);
int kprobe_exceptions_notify(struct notifier_block *self,
unsigned long val, void *data);
+/* optinsn template addresses */
+extern __visible kprobe_opcode_t optprobe_template_entry;
+extern __visible kprobe_opcode_t optprobe_template_val;
+extern __visible kprobe_opcode_t optprobe_template_call;
+extern __visible kprobe_opcode_t optprobe_template_end;
+extern __visible kprobe_opcode_t optprobe_template_sub_sp;
+extern __visible kprobe_opcode_t optprobe_template_add_sp;
+
+#define MAX_OPTIMIZED_LENGTH 4
+#define MAX_OPTINSN_SIZE \
+ ((unsigned long)&optprobe_template_end -\
+(unsigned long)&optprobe_template_entry)
+#define RELATIVEJUMP_SIZE 4
+
+struct arch_optimized_insn {
+ /*
+* copy of the original instructions.
+* Different from x86, ARM kprobe_opcode_t is u32.
+*/
+#define MAX_COPIED_INSNDIV_ROUND_UP(RELATIVEJUMP_SIZE,
sizeof(kprobe_opcode_t))
+ kprobe_opcode_t copied_insn[MAX_COPIED_INSN];
+ /* detour code buffer */
+ kprobe_opcode_t *insn;
+ /*
+* We always copy one instruction on ARM,
+* so size will always be 4, and unlike x86, there is no
+* need for a size field.
+*/
+};
#endif /* _ARM_KPROBES_H */
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 9c51a43..902397d 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -52,7 +52,7 @@ obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o insn.o
obj-$(CONFIG_JUMP_LABEL) += jump_label.o insn.o patch.o
obj-$(CONFIG_KEXEC)+= machine_kexec.o relocate_kernel.o
# Main staffs in KPROBES are in arch/arm/probes/ .
-obj-$(CONFIG_KPROBES) += patch.o
+obj-$(CONFIG_KPROBES) += patch.o insn.o
obj-$(CONFIG_OABI_COMPAT) += sys_oabi-compat.o
obj-$(CONFIG_ARM_THUMBEE) += thumbee.o
obj-$(CONFIG_KGDB) += kgdb.o patch.o
diff --git a/arch/arm/kernel/ftrace.c b/arch/arm/kernel/ftrace.c
index b8c75e4..709ee1d 100644
--- a/arch/arm/kernel/ftrace.c
+++ b/arch/arm/kernel/ftrace.c
@@ -20,8 +20,7 @@
#include
#include
#include
-
-#include "insn.h"
+#include
#ifdef CONFIG_THUMB2_KERNEL
#defineNOP 0xf85deb04 /* pop.w {lr}
[PATCH v17 11/11] ARM: optprobes: execute instruction during restoring if possible.
This patch removes software emulation or simulation for most of probed
instructions. If the instruction doesn't use PC relative addressing,
it will be translated into following instructions in the restore code
in code template:
ldmia {r0 - r14} // restore all instruction except PC
// direct execute the probed instruction
b next_insn // branch to next instruction.
Signed-off-by: Wang Nan
---
arch/arm/include/asm/kprobes.h| 3 +++
arch/arm/include/asm/probes.h | 1 +
arch/arm/probes/kprobes/opt-arm.c | 47 +--
3 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/kprobes.h b/arch/arm/include/asm/kprobes.h
index 50ff3bc..3ea9be5 100644
--- a/arch/arm/include/asm/kprobes.h
+++ b/arch/arm/include/asm/kprobes.h
@@ -57,6 +57,9 @@ extern __visible kprobe_opcode_t optprobe_template_call;
extern __visible kprobe_opcode_t optprobe_template_end;
extern __visible kprobe_opcode_t optprobe_template_sub_sp;
extern __visible kprobe_opcode_t optprobe_template_add_sp;
+extern __visible kprobe_opcode_t optprobe_template_restore_begin;
+extern __visible kprobe_opcode_t optprobe_template_restore_orig_insn;
+extern __visible kprobe_opcode_t optprobe_template_restore_end;
#define MAX_OPTIMIZED_LENGTH 4
#define MAX_OPTINSN_SIZE \
diff --git a/arch/arm/include/asm/probes.h b/arch/arm/include/asm/probes.h
index ee8725c..8ebbe83 100644
--- a/arch/arm/include/asm/probes.h
+++ b/arch/arm/include/asm/probes.h
@@ -50,6 +50,7 @@ struct arch_probes_insn {
#define set_register_nouse(m, n) __clear_register_flag(m, n, REG_NO_USE)
#define set_register_use(m, n) __set_register_flag(m, n, REG_USE)
int register_usage_mask;
+ bool kprobe_direct_exec;
};
#endif /* __ASSEMBLY__ */
diff --git a/arch/arm/probes/kprobes/opt-arm.c
b/arch/arm/probes/kprobes/opt-arm.c
index 6a60df3..f3bd1cc 100644
--- a/arch/arm/probes/kprobes/opt-arm.c
+++ b/arch/arm/probes/kprobes/opt-arm.c
@@ -32,6 +32,13 @@
#include "core.h"
/*
+ * See register_usage_mask. If the probed instruction doesn't use PC,
+ * we can copy it into template and have it executed directly without
+ * simulation or emulation.
+ */
+#define can_kprobe_direct_exec(m) (!((m) & 0xc000UL))
+
+/*
* NOTE: the first sub and add instruction will be modified according
* to the stack cost of the instruction.
*/
@@ -66,7 +73,15 @@ asm (
" orrne r2, #1\n"
" strne r2, [sp, #60] @ set bit0 of PC for
thumb\n"
" msr cpsr_cxsf, r1\n"
+ ".global optprobe_template_restore_begin\n"
+ "optprobe_template_restore_begin:\n"
" ldmia sp, {r0 - r15}\n"
+ ".global optprobe_template_restore_orig_insn\n"
+ "optprobe_template_restore_orig_insn:\n"
+ " nop\n"
+ ".global optprobe_template_restore_end\n"
+ "optprobe_template_restore_end:\n"
+ " ldmia sp, {r13 - r15}\n"
".global optprobe_template_val\n"
"optprobe_template_val:\n"
"1: .long 0\n"
@@ -86,6 +101,12 @@ asm (
((unsigned long *)&optprobe_template_add_sp - (unsigned long
*)&optprobe_template_entry)
#define TMPL_SUB_SP \
((unsigned long *)&optprobe_template_sub_sp - (unsigned long
*)&optprobe_template_entry)
+#define TMPL_RESTORE_BEGIN \
+ ((unsigned long *)&optprobe_template_restore_begin - (unsigned long
*)&optprobe_template_entry)
+#define TMPL_RESTORE_ORIGN_INSN \
+ ((unsigned long *)&optprobe_template_restore_orig_insn - (unsigned long
*)&optprobe_template_entry)
+#define TMPL_RESTORE_END \
+ ((unsigned long *)&optprobe_template_restore_end - (unsigned long
*)&optprobe_template_entry)
/*
* ARM can always optimize an instruction when using ARM ISA, except
@@ -155,8 +176,12 @@ optimized_callback(struct optimized_kprobe *op, struct
pt_regs *regs)
__this_cpu_write(current_kprobe, NULL);
}
- /* In each case, we must singlestep the replaced instruction. */
- op->kp.ainsn.insn_singlestep(p->opcode, &p->ainsn, regs);
+ /*
+* We singlestep the replaced instruction only when it can't be
+* executed directly during restore.
+*/
+ if (!p->ainsn.kprobe_direct_exec)
+ op->kp.ainsn.insn_singlestep(p->opcode, &p->ainsn, regs);
local_irq_restore(flags);
}
@@ -238,6 +263,24 @@ int arch_prepare_optimized_kprobe(struct optimized_kprobe
*op, struct kprobe *or
val = (unsigned long)optimized_callback;
code[TMPL_CALL_IDX] = val;
+ /* If possible, copy insn and have it executed during restore */
+ orig->ainsn.kprobe_direct_exec = false;
+ if (can_kpr
[PATCH v17 07/11] kprobes: Pass the original kprobe for preparing optimized kprobe
From: Masami Hiramatsu
Pass the original kprobe for preparing an optimized kprobe arch-dep
part, since for some architecture (e.g. ARM32) requires the information
in original kprobe.
Signed-off-by: Masami Hiramatsu
Signed-off-by: Wang Nan
---
arch/x86/kernel/kprobes/opt.c | 3 ++-
include/linux/kprobes.h | 3 ++-
kernel/kprobes.c | 4 ++--
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c
index 7c523bb..0dd8d08 100644
--- a/arch/x86/kernel/kprobes/opt.c
+++ b/arch/x86/kernel/kprobes/opt.c
@@ -322,7 +322,8 @@ void arch_remove_optimized_kprobe(struct optimized_kprobe
*op)
* Target instructions MUST be relocatable (checked inside)
* This is called when new aggr(opt)probe is allocated or reused.
*/
-int arch_prepare_optimized_kprobe(struct optimized_kprobe *op)
+int arch_prepare_optimized_kprobe(struct optimized_kprobe *op,
+ struct kprobe *__unused)
{
u8 *buf;
int ret;
diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
index 5297f9f..1ab5475 100644
--- a/include/linux/kprobes.h
+++ b/include/linux/kprobes.h
@@ -308,7 +308,8 @@ struct optimized_kprobe {
/* Architecture dependent functions for direct jump optimization */
extern int arch_prepared_optinsn(struct arch_optimized_insn *optinsn);
extern int arch_check_optimized_kprobe(struct optimized_kprobe *op);
-extern int arch_prepare_optimized_kprobe(struct optimized_kprobe *op);
+extern int arch_prepare_optimized_kprobe(struct optimized_kprobe *op,
+struct kprobe *orig);
extern void arch_remove_optimized_kprobe(struct optimized_kprobe *op);
extern void arch_optimize_kprobes(struct list_head *oplist);
extern void arch_unoptimize_kprobes(struct list_head *oplist,
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 06f5830..bad4e95 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -717,7 +717,7 @@ static void prepare_optimized_kprobe(struct kprobe *p)
struct optimized_kprobe *op;
op = container_of(p, struct optimized_kprobe, kp);
- arch_prepare_optimized_kprobe(op);
+ arch_prepare_optimized_kprobe(op, p);
}
/* Allocate new optimized_kprobe and try to prepare optimized instructions */
@@ -731,7 +731,7 @@ static struct kprobe *alloc_aggr_kprobe(struct kprobe *p)
INIT_LIST_HEAD(&op->list);
op->kp.addr = p->addr;
- arch_prepare_optimized_kprobe(op);
+ arch_prepare_optimized_kprobe(op, p);
return &op->kp;
}
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v17 06/11] ARM: kprobes: Add test cases for stack consuming instructions
From: "Jon Medhurst (Tixy)"
These have extra 'checker' functions associated with them so lets make
sure those get covered by testing. As they may create uninitialised
space on the stack we also update the test code to ensure such space is
consistent between test runs. This is done by disabling interrupts in
setup_test_context().
Signed-off-by: Jon Medhurst
---
arch/arm/probes/kprobes/test-arm.c | 17 +++--
arch/arm/probes/kprobes/test-core.c | 9 +
arch/arm/probes/kprobes/test-thumb.c | 12
3 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/arch/arm/probes/kprobes/test-arm.c
b/arch/arm/probes/kprobes/test-arm.c
index fdeb300..9b3b1b4 100644
--- a/arch/arm/probes/kprobes/test-arm.c
+++ b/arch/arm/probes/kprobes/test-arm.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include "test-core.h"
@@ -478,6 +479,7 @@ void kprobe_arm_test_cases(void)
TEST_RPR( "strhr",0, VAL1,", [r",1, 48,", -r",2, 24,"]")
TEST_RPR( "streqh r",14,VAL2,", [r",11,0, ", r",12, 48,"]")
TEST_UNSUPPORTED( "streqh r14, [r13, r12]")
+ TEST_UNSUPPORTED( "streqh r14, [r12, r13]")
TEST_RPR( "strhr",1, VAL1,", [r",2, 24,", r",3, 48,"]!")
TEST_RPR( "strneh r",12,VAL2,", [r",11,48,", -r",10,24,"]!")
TEST_RPR( "strhr",2, VAL1,", [r",3, 24,"], r",4, 48,"")
@@ -502,6 +504,9 @@ void kprobe_arm_test_cases(void)
TEST_RP( "strplh r",12,VAL2,", [r",11,24,", #-4]!")
TEST_RP( "strhr",2, VAL1,", [r",3, 24,"], #48")
TEST_RP( "strhr",10,VAL2,", [r",9, 64,"], #-48")
+ TEST_RP( "strhr",3, VAL1,", [r",13,TEST_MEMORY_SIZE,",
#-"__stringify(MAX_STACK_SIZE)"]!")
+ TEST_UNSUPPORTED("strh r3, [r13, #-"__stringify(MAX_STACK_SIZE)"-8]!")
+ TEST_RP( "strhr",4, VAL1,", [r",14,TEST_MEMORY_SIZE,",
#-"__stringify(MAX_STACK_SIZE)"-8]!")
TEST_UNSUPPORTED(__inst_arm(0xe1efc3b0) " @ strh r12, [pc, #48]!")
TEST_UNSUPPORTED(__inst_arm(0xe0c9f3b0) " @ strh pc, [r9], #48")
@@ -568,6 +573,7 @@ void kprobe_arm_test_cases(void)
TEST_RPR( "strdr",0, VAL1,", [r",1, 48,", -r",2,24,"]")
TEST_RPR( "strccd r",8, VAL2,", [r",11,0, ", r",12,48,"]")
TEST_UNSUPPORTED( "strccd r8, [r13, r12]")
+ TEST_UNSUPPORTED( "strccd r8, [r12, r13]")
TEST_RPR( "strdr",4, VAL1,", [r",2, 24,", r",3, 48,"]!")
TEST_RPR( "strcsd r",12,VAL2,", [r",11,48,", -r",10,24,"]!")
TEST_RPR( "strdr",2, VAL1,", [r",5, 24,"], r",4,48,"")
@@ -591,6 +597,9 @@ void kprobe_arm_test_cases(void)
TEST_RP( "strvcd r",12,VAL2,", [r",11,24,", #-16]!")
TEST_RP( "strdr",2, VAL1,", [r",4, 24,"], #48")
TEST_RP( "strdr",10,VAL2,", [r",9, 64,"], #-48")
+ TEST_RP( "strdr",6, VAL1,", [r",13,TEST_MEMORY_SIZE,",
#-"__stringify(MAX_STACK_SIZE)"]!")
+ TEST_UNSUPPORTED("strd r6, [r13, #-"__stringify(MAX_STACK_SIZE)"-8]!")
+ TEST_RP( "strdr",4, VAL1,", [r",12,TEST_MEMORY_SIZE,",
#-"__stringify(MAX_STACK_SIZE)"-8]!")
TEST_UNSUPPORTED(__inst_arm(0xe1efc3f0) " @ strd r12, [pc, #48]!")
TEST_P("ldrdr0, [r",0, 24,", #-8]")
@@ -639,16 +648,20 @@ void kprobe_arm_test_cases(void)
TEST_RP( "str"byte" r",12,VAL2,", [r",11,24,", #-4]!")
\
TEST_RP( "str"byte" r",2, VAL1,", [r",3, 24,"], #48")
\
TEST_RP( "str"byte" r",10,VAL2,", [r",9, 64,"], #-48")
\
+ TEST_RP( "str"byte" r",3, VAL1,", [r",13,TEST_MEMORY_SIZE,",
#-"__stringify(MAX_STACK_SIZE)"]!") \
+ TEST_UNSUPPORTED("str"byte" r3, [r13,
#-"__stringify(MAX_STACK_SIZE)"-8]!") \
+ TEST_RP( "str"byte" r",4, VAL1,", [r",10,TEST_MEMORY_SIZE,",
#-"__stringify(MAX_STACK_SIZE)"-8]!") \
TEST_RPR("str"byte" r",0, VAL1,", [r",1, 48,", -r",2, 24,"]")
\
TEST_RPR("str"byte" r",14,VAL2,", [r",11,0, ", r",12, 48,"]")
\
- TEST_UNSUPPORTED("str"byte" r14, [r13, r12]") \
+ TEST_UNSUPPORTED("str"byte" r14, [r13, r12]")
\
+ TEST_UNSUPPORTED("str"byte" r14, [r12, r13]")
\
TEST_RPR("str"byte" r",1, VAL1,", [r",2, 24,", r",3, 48,"]!")
\
TEST_RPR("str"byte" r",12,VAL2,", [r",11,48,", -r",10,24,"]!")
\
TEST_RPR("str"byte" r",2, VAL1,", [r",3, 24,"], r",4, 48,"")
\
TEST_RPR("str"byte" r",10,VAL2,", [r",9, 48,"], -r",11,24,"")
\
TEST_RPR("str"byte" r",0, VAL1,", [r",1, 24,", r",2, 32,", asl
#1]")\
TEST_RPR("str"byte" r",14,VAL2,", [r",11,0, ", r",12, 32,", lsr
#2]")\
- TEST_UNSUPPORTED("str"byte" r14, [r13, r12, lsr #2]")\
+ TEST_UNSUPPORTED("str"byte" r14, [
[PATCH v17 04/11] ARM: kprobes: collects stack consumption for store instructions
This patch uses the previously introduced checker functionality on
store instructions to record their stack consumption information to
arch_probes_insn.
Signed-off-by: Wang Nan
Signed-off-by: Jon Medhurst
Reviewed-by: Jon Medhurst
---
arch/arm/include/asm/probes.h | 1 +
arch/arm/probes/decode.c | 10 +++
arch/arm/probes/kprobes/Makefile | 6 +-
arch/arm/probes/kprobes/actions-arm.c | 3 +-
arch/arm/probes/kprobes/actions-thumb.c | 5 +-
arch/arm/probes/kprobes/checkers-arm.c| 99 +++
arch/arm/probes/kprobes/checkers-common.c | 101 +++
arch/arm/probes/kprobes/checkers-thumb.c | 110 ++
arch/arm/probes/kprobes/checkers.h| 54 +++
9 files changed, 383 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/probes/kprobes/checkers-arm.c
create mode 100644 arch/arm/probes/kprobes/checkers-common.c
create mode 100644 arch/arm/probes/kprobes/checkers-thumb.c
create mode 100644 arch/arm/probes/kprobes/checkers.h
diff --git a/arch/arm/include/asm/probes.h b/arch/arm/include/asm/probes.h
index 806cfe6..ccf9af3 100644
--- a/arch/arm/include/asm/probes.h
+++ b/arch/arm/include/asm/probes.h
@@ -38,6 +38,7 @@ struct arch_probes_insn {
probes_check_cc *insn_check_cc;
probes_insn_singlestep_t*insn_singlestep;
probes_insn_fn_t*insn_fn;
+ int stack_space;
};
#endif
diff --git a/arch/arm/probes/decode.c b/arch/arm/probes/decode.c
index c7d4420..f9d7c42 100644
--- a/arch/arm/probes/decode.c
+++ b/arch/arm/probes/decode.c
@@ -425,6 +425,16 @@ probes_decode_insn(probes_opcode_t insn, struct
arch_probes_insn *asi,
*/
probes_opcode_t origin_insn = insn;
+ /*
+* stack_space is initialized to 0 here. Checker functions
+* should update is value if they find this is a stack store
+* instruction: positive value means bytes of stack usage,
+* negitive value means unable to determine stack usage
+* statically. For instruction doesn't store to stack, checker
+* do nothing with it.
+*/
+ asi->stack_space = 0;
+
if (emulate)
insn = prepare_emulated_insn(insn, asi, thumb);
diff --git a/arch/arm/probes/kprobes/Makefile b/arch/arm/probes/kprobes/Makefile
index eb38a42..bc8d504 100644
--- a/arch/arm/probes/kprobes/Makefile
+++ b/arch/arm/probes/kprobes/Makefile
@@ -1,11 +1,11 @@
-obj-$(CONFIG_KPROBES) += core.o actions-common.o
+obj-$(CONFIG_KPROBES) += core.o actions-common.o checkers-common.o
obj-$(CONFIG_ARM_KPROBES_TEST) += test-kprobes.o
test-kprobes-objs := test-core.o
ifdef CONFIG_THUMB2_KERNEL
-obj-$(CONFIG_KPROBES) += actions-thumb.o
+obj-$(CONFIG_KPROBES) += actions-thumb.o checkers-thumb.o
test-kprobes-objs += test-thumb.o
else
-obj-$(CONFIG_KPROBES) += actions-arm.o
+obj-$(CONFIG_KPROBES) += actions-arm.o checkers-arm.o
test-kprobes-objs += test-arm.o
endif
diff --git a/arch/arm/probes/kprobes/actions-arm.c
b/arch/arm/probes/kprobes/actions-arm.c
index c3e7200..4fedd4c 100644
--- a/arch/arm/probes/kprobes/actions-arm.c
+++ b/arch/arm/probes/kprobes/actions-arm.c
@@ -64,6 +64,7 @@
#include "../decode-arm.h"
#include "core.h"
+#include "checkers.h"
#if __LINUX_ARM_ARCH__ >= 6
#define BLX(reg) "blx"reg" \n\t"
@@ -339,4 +340,4 @@ const union decode_action
kprobes_arm_actions[NUM_PROBES_ARM_ACTIONS] = {
[PROBES_LDMSTM] = {.decoder = kprobe_decode_ldmstm}
};
-const struct decode_checker *kprobes_arm_checkers[] = {NULL};
+const struct decode_checker *kprobes_arm_checkers[] = {arm_stack_checker,
NULL};
diff --git a/arch/arm/probes/kprobes/actions-thumb.c
b/arch/arm/probes/kprobes/actions-thumb.c
index 2796121..07cfd9b 100644
--- a/arch/arm/probes/kprobes/actions-thumb.c
+++ b/arch/arm/probes/kprobes/actions-thumb.c
@@ -15,6 +15,7 @@
#include "../decode-thumb.h"
#include "core.h"
+#include "checkers.h"
/* These emulation encodings are functionally equivalent... */
#define t32_emulate_rd8rn16rm0ra12_noflags \
@@ -665,5 +666,5 @@ const union decode_action
kprobes_t32_actions[NUM_PROBES_T32_ACTIONS] = {
.handler = t32_emulate_rdlo12rdhi8rn16rm0_noflags},
};
-const struct decode_checker *kprobes_t32_checkers[] = {NULL};
-const struct decode_checker *kprobes_t16_checkers[] = {NULL};
+const struct decode_checker *kprobes_t32_checkers[] = {t32_stack_checker,
NULL};
+const struct decode_checker *kprobes_t16_checkers[] = {t16_stack_checker,
NULL};
diff --git a/arch/arm/probes/kprobes/checkers-arm.c
b/arch/arm/probes/kprobes/checkers-arm.c
new file mode 100644
index 000..f817663
--- /dev/null
+++ b/arch/arm/probes/kprobes/checkers-arm.c
@@ -0,0 +1,99 @@
+/*
+ * arch/arm/probes/kprobes/checkers-arm.c
+ *
+ * Copyright (C)
[PATCH v17 02/11] ARM: kprobes: remove unused ARM decoder actions.
There are 3 actions which is never used:
PROBES_MOV_HALFWORD,
PROBES_SEV,
PROBES_WFE,
This patch removes them.
Signed-off-by: Wang Nan
---
arch/arm/probes/decode-arm.h | 3 ---
arch/arm/probes/kprobes/actions-arm.c | 3 ---
arch/arm/probes/uprobes/actions-arm.c | 3 ---
3 files changed, 9 deletions(-)
diff --git a/arch/arm/probes/decode-arm.h b/arch/arm/probes/decode-arm.h
index 9c56b40..f0dbc5a 100644
--- a/arch/arm/probes/decode-arm.h
+++ b/arch/arm/probes/decode-arm.h
@@ -38,9 +38,6 @@ enum probes_arm_action {
PROBES_MOV_IP_SP,
PROBES_DATA_PROCESSING_REG,
PROBES_DATA_PROCESSING_IMM,
- PROBES_MOV_HALFWORD,
- PROBES_SEV,
- PROBES_WFE,
PROBES_SATURATE,
PROBES_REV,
PROBES_MMI,
diff --git a/arch/arm/probes/kprobes/actions-arm.c
b/arch/arm/probes/kprobes/actions-arm.c
index 8797879..099aeb0 100644
--- a/arch/arm/probes/kprobes/actions-arm.c
+++ b/arch/arm/probes/kprobes/actions-arm.c
@@ -325,9 +325,6 @@ const union decode_action
kprobes_arm_actions[NUM_PROBES_ARM_ACTIONS] = {
.handler = emulate_rd12rn16rm0rs8_rwflags},
[PROBES_DATA_PROCESSING_IMM] = {
.handler = emulate_rd12rn16rm0rs8_rwflags},
- [PROBES_MOV_HALFWORD] = {.handler = emulate_rd12rm0_noflags_nopc},
- [PROBES_SEV] = {.handler = probes_emulate_none},
- [PROBES_WFE] = {.handler = probes_simulate_nop},
[PROBES_SATURATE] = {.handler = emulate_rd12rn16rm0_rwflags_nopc},
[PROBES_REV] = {.handler = emulate_rd12rm0_noflags_nopc},
[PROBES_MMI] = {.handler = emulate_rd12rn16rm0_rwflags_nopc},
diff --git a/arch/arm/probes/uprobes/actions-arm.c
b/arch/arm/probes/uprobes/actions-arm.c
index 1dd4916..6a271d6 100644
--- a/arch/arm/probes/uprobes/actions-arm.c
+++ b/arch/arm/probes/uprobes/actions-arm.c
@@ -217,9 +217,6 @@ const union decode_action uprobes_probes_actions[] = {
.decoder = decode_rd12rn16rm0rs8_rwflags},
[PROBES_DATA_PROCESSING_IMM] = {
.decoder = decode_rd12rn16rm0rs8_rwflags},
- [PROBES_MOV_HALFWORD] = {.handler = probes_simulate_nop},
- [PROBES_SEV] = {.handler = probes_simulate_nop},
- [PROBES_WFE] = {.handler = probes_simulate_nop},
[PROBES_SATURATE] = {.handler = probes_simulate_nop},
[PROBES_REV] = {.handler = probes_simulate_nop},
[PROBES_MMI] = {.handler = probes_simulate_nop},
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v17 01/11] ARM: probes: move all probe code to dedicate directory
In discussion on LKML (https://lkml.org/lkml/2014/11/28/158), Russell
King suggests to move all probe related code to arch/arm/probes. This
patch does the work. Due to dependency on 'arch/arm/kernel/patch.h', this
patch also moves patch.h to 'arch/arm/include/asm/patch.h', and related
'#include' directives are also midified to '#include '.
Following is an overview of this patch:
./arch/arm/kernel/ ./arch/arm/probes/
|-- Makefile |-- Makefile
|-- probes-arm.c ==>|-- decode-arm.c
|-- probes-arm.h ==>|-- decode-arm.h
|-- probes-thumb.c==>|-- decode-thumb.c
|-- probes-thumb.h==>|-- decode-thumb.h
|-- probes.c ==>|-- decode.c
|-- probes.h ==>|-- decode.h
||-- kprobes
|| |-- Makefile
|-- kprobes-arm.c ==>| |-- actions-arm.c
|-- kprobes-common.c ==>| |-- actions-common.c
|-- kprobes-thumb.c ==>| |-- actions-thumb.c
|-- kprobes.c ==>| |-- core.c
|-- kprobes.h ==>| |-- core.h
|-- kprobes-test-arm.c==>| |-- test-arm.c
|-- kprobes-test.c==>| |-- test-core.c
|-- kprobes-test.h==>| |-- test-core.h
|-- kprobes-test-thumb.c ==>| `-- test-thumb.c
|`-- uprobes
||-- Makefile
|-- uprobes-arm.c ==>|-- actions-arm.c
|-- uprobes.c ==>|-- core.c
|-- uprobes.h ==>`-- core.h
|
`-- patch.h ==>arch/arm/include/asm/patch.h
Signed-off-by: Wang Nan
Acked-by: Masami Hiramatsu
---
arch/arm/Makefile| 1 +
arch/arm/{kernel => include/asm}/patch.h | 0
arch/arm/kernel/Makefile | 16 ++--
arch/arm/kernel/jump_label.c | 2 +-
arch/arm/kernel/patch.c | 3 +--
arch/arm/probes/Makefile | 7 +++
arch/arm/{kernel/probes-arm.c => probes/decode-arm.c}| 7 ---
arch/arm/{kernel/probes-arm.h => probes/decode-arm.h}| 4 +++-
.../arm/{kernel/probes-thumb.c => probes/decode-thumb.c} | 6 +++---
.../arm/{kernel/probes-thumb.h => probes/decode-thumb.h} | 4 +++-
arch/arm/{kernel/probes.c => probes/decode.c}| 4 ++--
arch/arm/{kernel/probes.h => probes/decode.h}| 2 +-
arch/arm/probes/kprobes/Makefile | 11 +++
.../kprobes-arm.c => probes/kprobes/actions-arm.c} | 6 +++---
.../kprobes-common.c => probes/kprobes/actions-common.c} | 4 ++--
.../kprobes-thumb.c => probes/kprobes/actions-thumb.c} | 6 +++---
arch/arm/{kernel/kprobes.c => probes/kprobes/core.c} | 8
arch/arm/{kernel/kprobes.h => probes/kprobes/core.h} | 3 ++-
.../kprobes-test-arm.c => probes/kprobes/test-arm.c} | 2 +-
.../kprobes-test.c => probes/kprobes/test-core.c}| 8
.../kprobes-test.h => probes/kprobes/test-core.h}| 2 +-
.../kprobes-test-thumb.c => probes/kprobes/test-thumb.c} | 4 ++--
arch/arm/probes/uprobes/Makefile | 1 +
.../uprobes-arm.c => probes/uprobes/actions-arm.c} | 6 +++---
arch/arm/{kernel/uprobes.c => probes/uprobes/core.c} | 6 +++---
arch/arm/{kernel/uprobes.h => probes/uprobes/core.h} | 0
26 files changed, 68 insertions(+), 55 deletions(-)
rename arch/arm/{kernel => include/asm}/patch.h (100%)
create mode 100644 arch/arm/probes/Makefile
rename arch/arm/{kernel/probes-arm.c => probes/decode-arm.c} (99%)
rename arch/arm/{kernel/probes-arm.h => probes/decode-arm.h} (97%)
rename arch/arm/{kernel/probes-thumb.c => probes/decode-thumb.c} (99%)
rename arch/arm/{kernel/probes-thumb.h => probes/decode-thumb.h} (97%)
rename arch/arm/{kernel/probes.c => probes/decode.c} (99%)
rename arch/arm/{kernel/probes.h => probes/decode.h} (99%)
create mode 100644 arch/arm/probes/kprobes/Makefile
rename arch/arm/{kernel/kprobes-arm.c => probes/kprobes/actions-arm.c} (99%)
rename arch/arm/{kernel/kprobes-common.c => probes/kprobes/actions-common.c}
(98%)
rename arch/arm/{kernel/kprobes-thumb.c => probes/kprobes/actions-thumb.c}
(99%)
rename arch/arm/{kernel/kprobes.c => probes/kprobes/core.c} (99%)
rename arch/arm/{kernel/kprobes.h => probes/kprobes/core.h} (96%)
rename arch/arm/{kernel/kprobes-test-arm.c => probes/kprobes/test-arm.c} (99%)
rename arch/arm/{kernel/kprobes-test.c => probes/kprobes/test-core.c} (99%)
rename arch/arm/{kernel/kprobes-test.h => probes/kprobes/test-core.h} (99%)
rename arch/arm/{kernel/kprobes-test-thumb.c => probes/kprobes/test-thumb.c}
(99%)
create mode 100644 arch/arm/probes/uprobes/Makefile
rename arch/arm/{kernel/uprobes-arm.c => probes/uprobes/actions-arm.c} (98%)
rename arch/arm/{kernel/uprobes
[PATCH v17 00/11] ARM: kprobes: OPTPROBES and other improvements.
This is v17 patch series of kprobeopt. The main change in this version
are:
1. Patch 02/11 remove 3 useless ARM decode actions.
2. Patch 10/11 collects register usage of probed instructions.
3. Patch 11/11 use register usage information to decide whether
the probed instruction needs simulation or emulation. In most
of the case, the probed instruction is copied into code template
and get executed during restoring.
Jon Medhurst (Tixy) (2):
ARM: kprobes: Add test cases for stack consuming instructions
ARM: kprobes: Fix unreliable MRS instruction tests
Masami Hiramatsu (1):
kprobes: Pass the original kprobe for preparing optimized kprobe
Wang Nan (8):
ARM: probes: move all probe code to dedicate directory
ARM: kprobes: remove unused ARM decoder actions.
ARM: kprobes: introduces checker
ARM: kprobes: collects stack consumption for store instructions
ARM: kprobes: disallow probing stack consuming instructions
ARM: kprobes: enable OPTPROBES for ARM 32
ARM: kprobes: check register usage for probed instruction.
ARM: optprobes: execute instruction during restoring if possible.
arch/arm/Kconfig | 1 +
arch/arm/Makefile | 1 +
arch/arm/{kernel => include/asm}/insn.h| 0
arch/arm/include/asm/kprobes.h | 33 +-
arch/arm/{kernel => include/asm}/patch.h | 0
arch/arm/include/asm/probes.h | 23 ++
arch/arm/kernel/Makefile | 16 +-
arch/arm/kernel/entry-armv.S | 3 +-
arch/arm/kernel/ftrace.c | 3 +-
arch/arm/kernel/jump_label.c | 5 +-
arch/arm/kernel/patch.c| 3 +-
arch/arm/probes/Makefile | 7 +
.../{kernel/probes-arm.c => probes/decode-arm.c} | 12 +-
.../{kernel/probes-arm.h => probes/decode-arm.h} | 10 +-
.../probes-thumb.c => probes/decode-thumb.c} | 16 +-
.../probes-thumb.h => probes/decode-thumb.h} | 10 +-
arch/arm/{kernel/probes.c => probes/decode.c} | 81 -
arch/arm/{kernel/probes.h => probes/decode.h} | 13 +-
arch/arm/probes/kprobes/Makefile | 12 +
.../kprobes-arm.c => probes/kprobes/actions-arm.c} | 12 +-
.../kprobes/actions-common.c} | 4 +-
.../kprobes/actions-thumb.c} | 10 +-
arch/arm/probes/kprobes/checkers-arm.c | 223 +
arch/arm/probes/kprobes/checkers-common.c | 101 ++
arch/arm/probes/kprobes/checkers-thumb.c | 110 +++
arch/arm/probes/kprobes/checkers.h | 55
.../{kernel/kprobes.c => probes/kprobes/core.c}| 49 ++-
.../{kernel/kprobes.h => probes/kprobes/core.h}| 12 +-
arch/arm/probes/kprobes/opt-arm.c | 360 +
.../kprobes/test-arm.c}| 37 ++-
.../kprobes-test.c => probes/kprobes/test-core.c} | 36 ++-
.../kprobes-test.h => probes/kprobes/test-core.h} | 35 +-
.../kprobes/test-thumb.c} | 20 +-
arch/arm/probes/uprobes/Makefile | 1 +
.../uprobes-arm.c => probes/uprobes/actions-arm.c} | 9 +-
.../{kernel/uprobes.c => probes/uprobes/core.c}| 8 +-
.../{kernel/uprobes.h => probes/uprobes/core.h}| 0
arch/x86/kernel/kprobes/opt.c | 3 +-
include/linux/kprobes.h| 3 +-
kernel/kprobes.c | 4 +-
40 files changed, 1215 insertions(+), 126 deletions(-)
rename arch/arm/{kernel => include/asm}/insn.h (100%)
rename arch/arm/{kernel => include/asm}/patch.h (100%)
create mode 100644 arch/arm/probes/Makefile
rename arch/arm/{kernel/probes-arm.c => probes/decode-arm.c} (99%)
rename arch/arm/{kernel/probes-arm.h => probes/decode-arm.h} (92%)
rename arch/arm/{kernel/probes-thumb.c => probes/decode-thumb.c} (98%)
rename arch/arm/{kernel/probes-thumb.h => probes/decode-thumb.h} (90%)
rename arch/arm/{kernel/probes.c => probes/decode.c} (84%)
rename arch/arm/{kernel/probes.h => probes/decode.h} (97%)
create mode 100644 arch/arm/probes/kprobes/Makefile
rename arch/arm/{kernel/kprobes-arm.c => probes/kprobes/actions-arm.c} (97%)
rename arch/arm/{kernel/kprobes-common.c => probes/kprobes/actions-common.c}
(98%)
rename arch/arm/{kernel/kprobes-thumb.c => probes/kprobes/actions-thumb.c}
(98%)
create mode 100644 arch/arm/probes/kprobes/checkers-arm.c
create mode 100644 arch/arm/probes/kprobes/checkers-common.c
create mode 100644 arch/arm/probes/kprobes/checkers-thumb.c
create mode 100644 arch/arm/probes/kprobes/checkers.h
rename arch/arm/{kernel/kprobes.c => probes/kprobes/core.c} (94%)
rename arch/arm/{kernel/kprobes.h => probes/kprobes/core.h} (79%)
create mode 100644 arch/arm/probes/kprobes/opt-arm.c
rename arch/arm/{kernel/kprobes-test-arm.c => probes/kprobes/te
[PATCH] USB: serial: cp210x: Correcting IDs for production CEL MeshConnect USB Stick
Fixing typo for MeshConnect IDs. The original PID (0x8875) is not in production
and is not needed. Instead it has been changed to the official production PID
(0x8857).
Signed-off-by: Preston Fick
---
drivers/usb/serial/cp210x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 6c4eb3c..fb8d3fa 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -120,7 +120,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x10C4, 0x85F8) }, /* Virtenio Preon32 */
{ USB_DEVICE(0x10C4, 0x8664) }, /* AC-Services CAN-IF */
{ USB_DEVICE(0x10C4, 0x8665) }, /* AC-Services OBD-IF */
- { USB_DEVICE(0x10C4, 0x8875) }, /* CEL MeshConnect USB Stick */
+ { USB_DEVICE(0x10C4, 0x8857) }, /* CEL MeshConnect USB Stick */
{ USB_DEVICE(0x10C4, 0x88A4) }, /* MMB Networks ZigBee USB Device */
{ USB_DEVICE(0x10C4, 0x88A5) }, /* Planet Innovation Ingeni ZigBee USB
Device */
{ USB_DEVICE(0x10C4, 0x8946) }, /* Ketra N1 Wireless Interface */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging/iio/accel: checkpatch: fixed long lines by moving comments
On Fri, Dec 26, 2014 at 10:00:00AM +, Jonathan Cameron wrote: > On 22/12/14 13:48, Sudip Mukherjee wrote: > > On Mon, Dec 22, 2014 at 02:23:42AM +0100, Helene Gsaenger wrote: > >> Signed-off-by: Helene Gsaenger > >> Signed-off-by: Simone Weiss > >> --- > >> drivers/staging/iio/accel/adis16203.h | 41 > >> ++- > >> 1 file changed, 31 insertions(+), 10 deletions(-) > >> > >> diff --git a/drivers/staging/iio/accel/adis16203.h > >> b/drivers/staging/iio/accel/adis16203.h > >> index acc688d..fefe2f9 100644 > >> --- a/drivers/staging/iio/accel/adis16203.h > >> +++ b/drivers/staging/iio/accel/adis16203.h > >> @@ -16,26 +16,47 @@ > >> #define ADIS16203_ALM_SMPL2 0x26 /* Alarm 2, sample period */ > >> #define ADIS16203_ALM_CTRL 0x28 /* Alarm control */ > >> #define ADIS16203_AUX_DAC0x30 /* Auxiliary DAC data */ > >> -#define ADIS16203_GPIO_CTRL 0x32 /* General-purpose digital > >> input/output control */ > >> +#define ADIS16203_GPIO_CTRL 0x32 /* General-purpose digital > >> input/output > >> + * control */ > >> #define ADIS16203_MSC_CTRL 0x34 /* Miscellaneous control */ > >> -#define ADIS16203_SMPL_PRD 0x36 /* Internal sample period (rate) > >> control */ > >> +#define ADIS16203_SMPL_PRD 0x36 /* Internal sample period (rate) > >> + * control */ > > > > this is not the style for multiline comments. Check in CodingStyle. > > and besides, I think it will be better if you can put the comments in a > > line of its own. > + remember checkpatch is only for guidance. Some rules such as the 80 > character limit > are often ignored if clarity would be gained by doing so, or if as here a > large patch > would be needed (move all comments to separate lines) in order to meet the 80 > character > line limit for a couple of cases. ofcourse checkpatch is only for guidance, and we need to use our own judgement to decide. here I mentioned separate line because Helene Gsaenger has sent the patch splitting some commments in the second line, which was not looking good. Personally, I will like comments beside the #define, so that while reading the code, i can immediately see what that #define is doing. Sudip > > > > thanks > > sudip > >> #define ADIS16203_AVG_CNT0x38 /* Operation, filter configuration > >> */ > >> #define ADIS16203_SLP_CNT0x3A /* Operation, sleep mode control */ > >> #define ADIS16203_DIAG_STAT 0x3C /* Diagnostics, system status > >> register */ > >> #define ADIS16203_GLOB_CMD 0x3E /* Operation, system command > >> register */ > >> > >> /* MSC_CTRL */ > >> -#define ADIS16203_MSC_CTRL_PWRUP_SELF_TEST(1 << 10) /* Self-test > >> at power-on: 1 = disabled, 0 = enabled */ > >> -#define ADIS16203_MSC_CTRL_REVERSE_ROT_EN (1 << 9) /* Reverses rotation > >> of both inclination outputs */ > >> +#define ADIS16203_MSC_CTRL_PWRUP_SELF_TEST(1 << 10) /* Self-test > >> at > >> + * power-on: > >> + * 1 = disabled, > >> + * 0 = enabled */ > >> +#define ADIS16203_MSC_CTRL_REVERSE_ROT_EN (1 << 9) /* Reverses rotation > >> + * of both > >> + * inclination > >> + * outputs */ > >> #define ADIS16203_MSC_CTRL_SELF_TEST_EN (1 << 8) /* Self-test > >> enable */ > >> -#define ADIS16203_MSC_CTRL_DATA_RDY_EN(1 << 2) /* Data-ready > >> enable: 1 = enabled, 0 = disabled */ > >> -#define ADIS16203_MSC_CTRL_ACTIVE_HIGH(1 << 1) /* Data-ready > >> polarity: 1 = active high, 0 = active low */ > >> -#define ADIS16203_MSC_CTRL_DATA_RDY_DIO1 (1 << 0) /* Data-ready line > >> selection: 1 = DIO1, 0 = DIO0 */ > >> +#define ADIS16203_MSC_CTRL_DATA_RDY_EN(1 << 2) /* Data-ready > >> enable: > >> + * 1 = enabled, > >> + * 0 = disabled */ > >> +#define ADIS16203_MSC_CTRL_ACTIVE_HIGH(1 << 1) /* Data-ready > >> + * polarity: > >> + * 1 = active high, > >> + * 0 = active low */ > >> +#define ADIS16203_MSC_CTRL_DATA_RDY_DIO1 (1 << 0) /* Data-ready line > >> + * selection: > >> + * 1 = DIO1, > >> + * 0 = DIO0 */ > >> > >> /* DIAG_STAT */ > >> -#define ADIS16203_DIAG_STAT_ALARM2(1<<9) /* Alarm 2 status: 1 = > >> alarm active, 0 = alarm inactive */ >
Re: [PATCH 3/3] cma: add functions to get region pages counters
Hello,
On Fri, 26 Dec 2014, Stefan I. Strogin wrote:
From: Dmitry Safonov
Here are two functions that provide interface to compute/get used size
and size of biggest free chunk in cma region.
Added that information in cmainfo.
Signed-off-by: Dmitry Safonov
---
include/linux/cma.h | 2 ++
mm/cma.c| 34 ++
2 files changed, 36 insertions(+)
diff --git a/include/linux/cma.h b/include/linux/cma.h
index 9384ba6..855e6f2 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -18,6 +18,8 @@ struct cma;
extern unsigned long totalcma_pages;
extern phys_addr_t cma_get_base(struct cma *cma);
extern unsigned long cma_get_size(struct cma *cma);
+extern unsigned long cma_get_used(struct cma *cma);
+extern unsigned long cma_get_maxchunk(struct cma *cma);
extern int __init cma_declare_contiguous(phys_addr_t base,
phys_addr_t size, phys_addr_t limit,
diff --git a/mm/cma.c b/mm/cma.c
index ffaea26..5e560ed 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -78,6 +78,36 @@ unsigned long cma_get_size(struct cma *cma)
return cma->count << PAGE_SHIFT;
}
+unsigned long cma_get_used(struct cma *cma)
+{
+ unsigned long ret = 0;
+
+ mutex_lock(&cma->lock);
+ /* pages counter is smaller than sizeof(int) */
+ ret = bitmap_weight(cma->bitmap, (int)cma->count);
+ mutex_unlock(&cma->lock);
+
+ return ret << (PAGE_SHIFT + cma->order_per_bit);
+}
+
+unsigned long cma_get_maxchunk(struct cma *cma)
+{
+ unsigned long maxchunk = 0;
+ unsigned long start, end = 0;
+
+ mutex_lock(&cma->lock);
+ for (;;) {
+ start = find_next_zero_bit(cma->bitmap, cma->count, end);
+ if (start >= cma->count)
+ break;
+ end = find_next_bit(cma->bitmap, cma->count, start);
+ maxchunk = max(end - start, maxchunk);
+ }
+ mutex_unlock(&cma->lock);
+
+ return maxchunk << (PAGE_SHIFT + cma->order_per_bit);
+}
+
static unsigned long cma_bitmap_aligned_mask(struct cma *cma, int align_order)
{
if (align_order <= cma->order_per_bit)
@@ -591,6 +621,10 @@ static int s_show(struct seq_file *m, void *p)
struct cma_buffer *cmabuf;
struct stack_trace trace;
+ seq_printf(m, "CMARegion stat: %8lu kB total, %8lu kB used, %8lu kB max
contiguous chunk\n\n",
How about 'CMA Region' rather than 'CMARegion'?
+ cma_get_size(cma) >> 10,
+ cma_get_used(cma) >> 10,
+ cma_get_maxchunk(cma) >> 10);
mutex_lock(&cma->list_lock);
list_for_each_entry(cmabuf, &cma->buffers_list, list) {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] stacktrace: add seq_print_stack_trace()
On Fri, 26 Dec 2014, Stefan I. Strogin wrote:
Add a function seq_print_stack_trace() which prints stacktraces to seq_files.
Signed-off-by: Stefan I. Strogin
Reviewed-by: SeongJae Park
---
include/linux/stacktrace.h | 4
kernel/stacktrace.c| 17 +
2 files changed, 21 insertions(+)
diff --git a/include/linux/stacktrace.h b/include/linux/stacktrace.h
index 669045a..6d62484 100644
--- a/include/linux/stacktrace.h
+++ b/include/linux/stacktrace.h
@@ -2,6 +2,7 @@
#define __LINUX_STACKTRACE_H
#include
+#include
struct task_struct;
struct pt_regs;
@@ -24,6 +25,8 @@ extern void save_stack_trace_tsk(struct task_struct *tsk,
extern void print_stack_trace(struct stack_trace *trace, int spaces);
extern int snprint_stack_trace(char *buf, size_t size,
struct stack_trace *trace, int spaces);
+extern void seq_print_stack_trace(struct seq_file *m,
+ struct stack_trace *trace, int spaces);
#ifdef CONFIG_USER_STACKTRACE_SUPPORT
extern void save_stack_trace_user(struct stack_trace *trace);
@@ -37,6 +40,7 @@ extern void save_stack_trace_user(struct stack_trace *trace);
# define save_stack_trace_user(trace) do { } while (0)
# define print_stack_trace(trace, spaces) do { } while (0)
# define snprint_stack_trace(buf, size, trace, spaces) do { } while (0)
+# define seq_print_stack_trace(m, trace, spaces) do { } while (0)
#endif
#endif
diff --git a/kernel/stacktrace.c b/kernel/stacktrace.c
index b6e4c16..66ef6f4 100644
--- a/kernel/stacktrace.c
+++ b/kernel/stacktrace.c
@@ -57,6 +57,23 @@ int snprint_stack_trace(char *buf, size_t size,
}
EXPORT_SYMBOL_GPL(snprint_stack_trace);
+void seq_print_stack_trace(struct seq_file *m, struct stack_trace *trace,
+ int spaces)
+{
+ int i;
+
+ if (WARN_ON(!trace->entries))
+ return;
+
+ for (i = 0; i < trace->nr_entries; i++) {
+ unsigned long ip = trace->entries[i];
+
+ seq_printf(m, "%*c[<%p>] %pS\n", 1 + spaces, ' ',
+ (void *) ip, (void *) ip);
+ }
+}
+EXPORT_SYMBOL_GPL(seq_print_stack_trace);
+
/*
* Architectures that do not implement save_stack_trace_tsk or
* save_stack_trace_regs get this weak alias and a once-per-bootup warning
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] staging: comedi: dmm32at: fix style issues
On Thu, Dec 25, 2014 at 12:28:28PM -0800, David Decotigny wrote: > Before: > 1 ERROR: code indent should use tabs where possible > 1 WARNING: please, no spaces at the start of a line > > After: > (none) > > Signed-off-by: David Decotigny > --- > drivers/staging/comedi/drivers/dmm32at.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/comedi/drivers/dmm32at.c > b/drivers/staging/comedi/drivers/dmm32at.c > index 6df298a..31919b8 100644 > --- a/drivers/staging/comedi/drivers/dmm32at.c > +++ b/drivers/staging/comedi/drivers/dmm32at.c > @@ -365,7 +365,7 @@ static void dmm32at_setaitimer(struct comedi_device *dev, > unsigned int nansec) > /* enable the ai conversion interrupt and the clock to start scans */ > outb(DMM32AT_INTCLK_ADINT | >DMM32AT_INTCLK_CLKEN | DMM32AT_INTCLK_CLKSEL, > - dev->iobase + DMM32AT_INTCLK_REG); > + dev->iobase + DMM32AT_INTCLK_REG); another suggestion: if you do like the following patch (use 2 tabs) then you do not need to give spaces to indent the code. diff --git a/drivers/staging/comedi/drivers/dmm32at.c b/drivers/staging/comedi/drivers/dmm32at.c index 6df298a..cedf8ed 100644 --- a/drivers/staging/comedi/drivers/dmm32at.c +++ b/drivers/staging/comedi/drivers/dmm32at.c @@ -364,8 +364,8 @@ static void dmm32at_setaitimer(struct comedi_device *dev, unsigned int nansec) /* enable the ai conversion interrupt and the clock to start scans */ outb(DMM32AT_INTCLK_ADINT | -DMM32AT_INTCLK_CLKEN | DMM32AT_INTCLK_CLKSEL, - dev->iobase + DMM32AT_INTCLK_REG); + DMM32AT_INTCLK_CLKEN | DMM32AT_INTCLK_CLKSEL, + dev->iobase + DMM32AT_INTCLK_REG); } static int dmm32at_ai_cmd(struct comedi_device *dev, struct comedi_subdevice *s) thanks sudip > } > > static int dmm32at_ai_cmd(struct comedi_device *dev, struct comedi_subdevice > *s) > -- > 2.2.0.rc0.207.ga3a616c > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: line6: Updated comma spacing to fit within coding style
Fixed a coding style issue reported by checkpatch surrounding the
spacing of comma's
Signed-off-by: Damon Swayn
---
drivers/staging/line6/pcm.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/line6/pcm.h b/drivers/staging/line6/pcm.h
index 6aa0d46..5d87934 100644
--- a/drivers/staging/line6/pcm.h
+++ b/drivers/staging/line6/pcm.h
@@ -145,21 +145,21 @@ enum {
LINE6_BIT_PCM_IMPULSE_PLAYBACK_BUFFER |
#endif
LINE6_BIT_PCM_ALSA_PLAYBACK_BUFFER |
- LINE6_BIT_PCM_MONITOR_PLAYBACK_BUFFER ,
+ LINE6_BIT_PCM_MONITOR_PLAYBACK_BUFFER,
LINE6_BITS_PLAYBACK_STREAM =
#ifdef CONFIG_LINE6_USB_IMPULSE_RESPONSE
LINE6_BIT_PCM_IMPULSE_PLAYBACK_STREAM |
#endif
LINE6_BIT_PCM_ALSA_PLAYBACK_STREAM |
- LINE6_BIT_PCM_MONITOR_PLAYBACK_STREAM ,
+ LINE6_BIT_PCM_MONITOR_PLAYBACK_STREAM,
LINE6_BITS_CAPTURE_BUFFER =
#ifdef CONFIG_LINE6_USB_IMPULSE_RESPONSE
LINE6_BIT_PCM_IMPULSE_CAPTURE_BUFFER |
#endif
LINE6_BIT_PCM_ALSA_CAPTURE_BUFFER |
- LINE6_BIT_PCM_MONITOR_CAPTURE_BUFFER ,
+ LINE6_BIT_PCM_MONITOR_CAPTURE_BUFFER,
LINE6_BITS_CAPTURE_STREAM =
#ifdef CONFIG_LINE6_USB_IMPULSE_RESPONSE
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 14/37] perf tools: Convert dead thread list into rbtree
On Sat, Dec 27, 2014 at 2:14 AM, David Ahern wrote:
> On 12/25/14 7:26 PM, Namhyung Kim wrote:
diff --git a/tools/perf/util/thread.h b/tools/perf/util/thread.h
index 0b6dcd70bc8b..413f28cf689b 100644
--- a/tools/perf/util/thread.h
+++ b/tools/perf/util/thread.h
@@ -11,10 +11,8 @@
struct thread_stack;
struct thread {
- union {
- struct rb_node rb_node;
- struct list_head node;
- };
+ struct rb_node rb_node;
+ struct list_headnode;
struct map_groups *mg;
pid_t pid_; /* Not all tools update this */
pid_t tid;
@@ -22,7 +20,8 @@ struct thread {
int cpu;
charshortname[3];
boolcomm_set;
- booldead; /* if set thread has exited */
+ boolexited; /* if set thread has exited */
+ booldead; /* thread is in dead_threads list */
>>>
>>>
>>> looks like this also changes the logic (new exited flag),
>>> not just the dead threads storage wheel
>>
>>
>> AFAICS the 'dead' flag is not used other than thread__exited(). And
>> it confused me a dead thread might not be in a dead_threads tree (or
>> list). So I changed the name and no logical change intended.
>
>
> git show 236a3bbd5cb51
Thanks for the pointer. I understand the need of delaying the move to
dead_threads list, but anyway it still makes me confused. So I
renamed the flag to keep the current behavior and match the name
'dead' to the list/tree management to reduce further confusion.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 11/37] perf tools: Introduce thread__comm_time() helpers
On Sat, Dec 27, 2014 at 2:00 AM, David Ahern wrote:
> On 12/24/14 12:15 AM, Namhyung Kim wrote:
>>
>> @@ -139,6 +161,16 @@ const char *thread__comm_str(const struct thread
>> *thread)
>> return comm__str(comm);
>> }
>>
>> +const char *thread__comm_time_str(const struct thread *thread, u64
>> timestamp)
>> +{
>> + const struct comm *comm = thread__comm_time(thread, timestamp);
>> +
>> + if (!comm)
>> + return NULL;
>> +
>> + return comm__str(comm);
>> +}
>> +
>
>
> thread__comm_str_time()? time_str suggests a time-based string as opposed to
> a comm_str based on time.
Will change - my naming sense is always awful. I'd be happy to hear
any naming suggestion. ;-)
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/37] perf tools: Create separate mmap for dummy tracking event
On Sat, Dec 27, 2014 at 1:51 AM, David Ahern wrote: > On 12/24/14 12:15 AM, Namhyung Kim wrote: >> >> When multi file support is enabled, a dummy tracking event will be >> used to track metadata (like task, comm and mmap events) for a session >> and actual samples will be recorded in separate files. >> >> Provide separate mmap to the dummy tracking event. The size is fixed >> to 128KiB (+ 1 page) as the event rate will be lower than samples. I > > > Have you tried stress tests like a kernel compile with -j Ncpus (Ncpus = 16 > or higher)? Yep, the test results in the cover letter were recorded kernel build with -j 20 on my development machine. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/37] perf tools: Use perf_data_file__fd() consistently
On Sat, Dec 27, 2014 at 1:30 AM, David Ahern wrote:
> On 12/24/14 12:14 AM, Namhyung Kim wrote:
>
>> diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
>> index 84df2deed988..d8b13407594d 100644
>> --- a/tools/perf/builtin-inject.c
>> +++ b/tools/perf/builtin-inject.c
>> @@ -375,8 +375,10 @@ static int __cmd_inject(struct perf_inject *inject)
>> }
>> }
>>
>
> How about a local variable to make this more readable?
> fd = perf_data_file__fd(file_out)
Will do.
>
>> - if (!file_out->is_pipe)
>> - lseek(file_out->fd, session->header.data_offset,
>> SEEK_SET);
>> + if (!file_out->is_pipe) {
>> + lseek(perf_data_file__fd(file_out),
>> session->header.data_offset,
>> + SEEK_SET);
>> + }
>>
>> ret = perf_session__process_events(session, &inject->tool);
>>
>> @@ -385,7 +387,8 @@ static int __cmd_inject(struct perf_inject *inject)
>> perf_header__set_feat(&session->header,
>> HEADER_BUILD_ID);
>> session->header.data_size = inject->bytes_written;
>> - perf_session__write_header(session, session->evlist,
>> file_out->fd, true);
>> + perf_session__write_header(session, session->evlist,
>> + perf_data_file__fd(file_out),
>> true);
>> }
>>
>> return ret;
>> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
>> index aa5fa6aabb31..054c6e57d3b9 100644
>> --- a/tools/perf/builtin-record.c
>> +++ b/tools/perf/builtin-record.c
>> @@ -196,7 +196,7 @@ static int process_buildids(struct record *rec)
>> struct perf_session *session = rec->session;
>> u64 start = session->header.data_offset;
>>
>> - u64 size = lseek(file->fd, 0, SEEK_CUR);
>> + u64 size = lseek(perf_data_file__fd(file), 0, SEEK_CUR);
>> if (size == 0)
>> return 0;
>>
>> @@ -360,12 +360,12 @@ static int __cmd_record(struct record *rec, int
>> argc, const char **argv)
>> perf_header__clear_feat(&session->header,
>> HEADER_GROUP_DESC);
>
>
> Similarly in this function.
No problem.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/37] perf record: Use a software dummy event to track task/mmap events
Hi David,
On Sat, Dec 27, 2014 at 1:27 AM, David Ahern wrote:
> On 12/24/14 12:14 AM, Namhyung Kim wrote:
>>
>> Prepend a software dummy event into evlist to track task/comm/mmap
>> events separately. This is a preparation of multi-file/thread support
>> which will come later.
>
>
> Are you are making this the first event because of how perf internals are
> coded -- that the first event tracks tasks events? With the tracking bit in
> evsel you should not need to do that. Is there another reason?
Yeah, I know the tracking bit can be set to any evsel in the evlist.
But I'd like to keep it at a fixed index so that it can be easily
identified at later stages (like perf report) too. Ideally, it'd be
great if we have a way to distinguish this auto-added dummy tracking
event from other (user-added) (dummy?) tracking events if any.
>
> ---8<---
>
>> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
>> index cfbe2b99b9aa..72dff295237e 100644
>> --- a/tools/perf/util/evlist.c
>> +++ b/tools/perf/util/evlist.c
>> @@ -193,6 +193,44 @@ int perf_evlist__add_default(struct perf_evlist
>> *evlist)
>> return -ENOMEM;
>> }
>>
>> +int perf_evlist__prepend_dummy(struct perf_evlist *evlist)
>> +{
>> + struct perf_event_attr attr = {
>> + .type = PERF_TYPE_SOFTWARE,
>> + .config = PERF_COUNT_SW_DUMMY,
>> + };
>> + struct perf_evsel *evsel, *pos;
>> +
>> + event_attr_init(&attr);
>> +
>> + evsel = perf_evsel__new(&attr);
>> + if (evsel == NULL)
>> + goto error;
>> +
>> + /* use strdup() because free(evsel) assumes name is allocated */
>> + evsel->name = strdup("dummy");
>> + if (!evsel->name)
>> + goto error_free;
>> +
>> + list_for_each_entry(pos, &evlist->entries, node) {
>> + pos->idx += 1;
>> + pos->tracking = false;
>> + }
>> +
>> + list_add(&evsel->node, &evlist->entries);
>> + evsel->idx = 0;
>> + evsel->tracking = true;
>
>
> perf_evlist__set_tracking_event()?
I found that after I wrote this, so yes, it can use the function
instead of the oped-code. But the loop traversal is needed anyway to
fixup the evsel->idx.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCHSET 00/37] perf tools: Speed-up perf report by using multi thread (v1)
On Fri, Dec 26, 2014 at 11:02 PM, Jiri Olsa wrote: > On Wed, Dec 24, 2014 at 04:14:56PM +0900, Namhyung Kim wrote: > > SNIP > >> >> >> You can get it from 'perf/threaded-v1' branch on my tree at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git >> >> Please take a look and play with it. Any comments are welcome! :) > > very nice at first round check ;-) > > I'll do detailed review next week Thank you very much! Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 37/37] perf data: Implement 'split' subcommand
Hi Jiri, On Fri, Dec 26, 2014 at 10:59 PM, Jiri Olsa wrote: > On Wed, Dec 24, 2014 at 04:15:33PM +0900, Namhyung Kim wrote: >> The perf data split command is for splitting a (large) single data >> file into multiple files under a directory (perf.data.dir by default) >> so that it can be processed and reported using multiple threads. >> >> Signed-off-by: Namhyung Kim >> --- >> tools/perf/Documentation/perf-data.txt | 28 + >> tools/perf/builtin-data.c | 223 >> + >> 2 files changed, 251 insertions(+) >> >> diff --git a/tools/perf/Documentation/perf-data.txt >> b/tools/perf/Documentation/perf-data.txt >> index b8c83947715c..42708702f10c 100644 >> --- a/tools/perf/Documentation/perf-data.txt >> +++ b/tools/perf/Documentation/perf-data.txt >> @@ -13,3 +13,31 @@ SYNOPSIS >> DESCRIPTION >> --- >> Data file related processing. >> + >> +COMMANDS >> + >> +split:: >> + Split single data file (perf.data) into multiple files under a >> directory >> + in order to be reported by multiple threads. >> + >> +OPTIONS for 'split' >> +- >> +-i:: >> +--input:: >> + Specify input perf data file path. >> + >> +-o:: >> +--output:: >> + Specify output perf data directory path. > > should the -o have 'perf.data.dir' as default? > > [jolsa@krava perf]$ ./perf record ls > /dev/null > [ perf record: Woken up 1 times to write data ] > [ perf record: Captured and wrote 0.000 MB perf.data (~0 samples) ] > [jolsa@krava perf]$ ./perf data split > [jolsa@krava perf]$ ll perf.data* > -rw--- 1 jolsa jolsa 16172 Dec 26 14:58 perf.data You're right! :) Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] perf diff: Print diff result more precisely
Current perf diff result is somewhat confusing since it sometimes hide
small result and sometimes there's no result. So do not hide small
result (less than 0.01%) and print "N/A" if baseline is not
recorded (for ratio and wdiff only). Blank means the baseline is
available but its pairs are not.
Before:
# BaselineDelta Shared Object Symbol
# ... . .
#
...
0.01% -0.01% [kernel.kallsyms] [k] native_write_msr_safe
0.01% [kernel.kallsyms] [k] scheduler_tick
0.01% [kernel.kallsyms] [k] native_read_msr_safe
0.00% [kernel.kallsyms] [k] __rcu_read_unlock
[kernel.kallsyms] [k] _raw_spin_lock
+0.01% [kernel.kallsyms] [k] apic_timer_interrupt
[kernel.kallsyms] [k] read_tsc
After:
# BaselineDelta Shared Object Symbol
# ... . .
#
...
0.01% -0.01% [kernel.kallsyms] [k] native_write_msr_safe
0.01% [kernel.kallsyms] [k] scheduler_tick
0.01% [kernel.kallsyms] [k] native_read_msr_safe
0.00% [kernel.kallsyms] [k] __rcu_read_unlock
+0.01% [kernel.kallsyms] [k] _raw_spin_lock
+0.01% [kernel.kallsyms] [k] apic_timer_interrupt
+0.01% [kernel.kallsyms] [k] read_tsc
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-diff.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 72c718e6549c..3f86737da2c4 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -788,7 +788,7 @@ static int __hpp__color_compare(struct perf_hpp_fmt *fmt,
char pfmt[20] = " ";
if (!pair)
- goto dummy_print;
+ goto no_print;
switch (comparison_method) {
case COMPUTE_DELTA:
@@ -797,8 +797,6 @@ static int __hpp__color_compare(struct perf_hpp_fmt *fmt,
else
diff = compute_delta(he, pair);
- if (fabs(diff) < 0.01)
- goto dummy_print;
scnprintf(pfmt, 20, "%%%+d.2f", dfmt->header_width - 1);
return percent_color_snprintf(hpp->buf, hpp->size,
pfmt, diff);
@@ -830,6 +828,9 @@ static int __hpp__color_compare(struct perf_hpp_fmt *fmt,
}
dummy_print:
return scnprintf(hpp->buf, hpp->size, "%*s",
+ dfmt->header_width, "N/A");
+no_print:
+ return scnprintf(hpp->buf, hpp->size, "%*s",
dfmt->header_width, pfmt);
}
@@ -879,14 +880,15 @@ hpp__entry_pair(struct hist_entry *he, struct hist_entry
*pair,
else
diff = compute_delta(he, pair);
- if (fabs(diff) >= 0.01)
- scnprintf(buf, size, "%+4.2F%%", diff);
+ scnprintf(buf, size, "%+4.2F%%", diff);
break;
case PERF_HPP_DIFF__RATIO:
/* No point for ratio number if we are dummy.. */
- if (he->dummy)
+ if (he->dummy) {
+ scnprintf(buf, size, "N/A");
break;
+ }
if (pair->diff.computed)
ratio = pair->diff.period_ratio;
@@ -899,8 +901,10 @@ hpp__entry_pair(struct hist_entry *he, struct hist_entry
*pair,
case PERF_HPP_DIFF__WEIGHTED_DIFF:
/* No point for wdiff number if we are dummy.. */
- if (he->dummy)
+ if (he->dummy) {
+ scnprintf(buf, size, "N/A");
break;
+ }
if (pair->diff.computed)
wdiff = pair->diff.wdiff;
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] perf diff: Fix output ordering to honor next column
When perf diff prints output, it sorts the entries using baseline field
by default, but entries which don't have baseline are not sorted
properly. This patch makes it sorted by values of next column.
Before:
# Baseline/0 Delta/1 Delta/2 Shared Object Symbol
# .. ... ... .
..
#
32.75% +0.28% -0.83% libc-2.20.so [.] malloc
31.50% -0.74% -0.23% libc-2.20.so [.] _int_free
22.98% +0.51% +0.52% libc-2.20.so [.] _int_malloc
5.70% +0.28% +0.30% libc-2.20.so [.] free
4.38% -0.21% +0.25% a.out [.] main
1.32% -0.15% +0.05% a.out [.] free@plt
1.31% +0.03% -0.06% a.out [.] malloc@plt
0.01% -0.01% -0.01% [kernel.kallsyms] [k] native_write_msr_safe
0.01%[kernel.kallsyms] [k] scheduler_tick
0.01%-0.00% [kernel.kallsyms] [k] native_read_msr_safe
+0.01% [kernel.kallsyms] [k] _raw_spin_lock_irqsave
+0.01% +0.01% [kernel.kallsyms] [k] apic_timer_interrupt
+0.01% [kernel.kallsyms] [k] intel_pstate_timer_func
+0.01% [kernel.kallsyms] [k]
perf_adjust_freq_unthr_context.part.82
+0.01% [kernel.kallsyms] [k] read_tsc
+0.01% [kernel.kallsyms] [k]
timekeeping_update.constprop.8
After:
# Baseline/0 Delta/1 Delta/2 Shared Object Symbol
# .. ... ... .
..
#
32.75% +0.28% -0.83% libc-2.20.so [.] malloc
31.50% -0.74% -0.23% libc-2.20.so [.] _int_free
22.98% +0.51% +0.52% libc-2.20.so [.] _int_malloc
5.70% +0.28% +0.30% libc-2.20.so [.] free
4.38% -0.21% +0.25% a.out [.] main
1.32% -0.15% +0.05% a.out [.] free@plt
1.31% +0.03% -0.06% a.out [.] malloc@plt
0.01% -0.01% -0.01% [kernel.kallsyms] [k] native_write_msr_safe
0.01%[kernel.kallsyms] [k] scheduler_tick
0.01%-0.00% [kernel.kallsyms] [k] native_read_msr_safe
+0.01% +0.01% [kernel.kallsyms] [k] apic_timer_interrupt
+0.01% [kernel.kallsyms] [k] read_tsc
+0.01% [kernel.kallsyms] [k]
perf_adjust_freq_unthr_context.part.82
+0.01% [kernel.kallsyms] [k] intel_pstate_timer_func
+0.01% [kernel.kallsyms] [k] _raw_spin_lock_irqsave
+0.01% [kernel.kallsyms] [k]
timekeeping_update.constprop.8
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-diff.c | 60 +++
1 file changed, 34 insertions(+), 26 deletions(-)
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 3f86737da2c4..f490e24e9477 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -65,6 +65,7 @@ static bool show_period;
static bool show_formula;
static bool show_baseline_only;
static unsigned int sort_compute;
+static unsigned int data_idx;
static s64 compute_wdiff_w1;
static s64 compute_wdiff_w2;
@@ -448,26 +449,30 @@ static void hists__precompute(struct hists *hists)
next = rb_first(root);
while (next != NULL) {
struct hist_entry *he, *pair;
+ struct data__file *d;
+ int i;
he = rb_entry(next, struct hist_entry, rb_node_in);
next = rb_next(&he->rb_node_in);
- pair = get_pair_data(he, &data__files[sort_compute]);
- if (!pair)
- continue;
+ data__for_each_file_new(i, d) {
+ pair = get_pair_data(he, d);
+ if (!pair)
+ continue;
- switch (compute) {
- case COMPUTE_DELTA:
- compute_delta(he, pair);
- break;
- case COMPUTE_RATIO:
- compute_ratio(he, pair);
- break;
- case COMPUTE_WEIGHTED_DIFF:
- compute_wdiff(he, pair);
- break;
- default:
- BUG_ON(1);
+ switch (compute) {
+ case COMPUTE_DELTA:
+ compute_delta(he, pair);
+ break;
+ case COMPUTE_RATIO:
+ compute_ratio(he, pair);
+ break;
+ case COMPUTE_WEIGHTED_DIFF:
+
[PATCH 5/5] perf diff: Fix -o/--order option behavior
The prior change fixes default output ordering with each column but it
breaks -o/--order option. This patch prepends a new hpp fmt struct to
sort list but not to output field list so that it can affect ordering
without adding a new output column.
The new hpp fmt uses its own compare functions which treats dummy
entries (which have no baseline) little differently - the delta field
can be computed without baseline but others (ratio and wdiff) are not.
The new output will look like below:
$ perf diff -o 2 perf.data.{old,cur,new}
...
# Baseline/0 Delta/1 Delta/2 Shared Object Symbol
# .. ... ... .
..
22.98% +0.51% +0.52% libc-2.20.so [.] _int_malloc
5.70% +0.28% +0.30% libc-2.20.so [.] free
4.38% -0.21% +0.25% a.out [.] main
1.32% -0.15% +0.05% a.out [.] free@plt
+0.01% [kernel.kallsyms] [k] intel_pstate_timer_func
+0.01% [kernel.kallsyms] [k] _raw_spin_lock_irqsave
+0.01% [kernel.kallsyms] [k]
timekeeping_update.constprop.8
+0.01% +0.01% [kernel.kallsyms] [k] apic_timer_interrupt
0.01%-0.00% [kernel.kallsyms] [k] native_read_msr_safe
0.01% -0.01% -0.01% [kernel.kallsyms] [k] native_write_msr_safe
1.31% +0.03% -0.06% a.out [.] malloc@plt
31.50% -0.74% -0.23% libc-2.20.so [.] _int_free
32.75% +0.28% -0.83% libc-2.20.so [.] malloc
0.01%[kernel.kallsyms] [k] scheduler_tick
+0.01% [kernel.kallsyms] [k] read_tsc
+0.01% [kernel.kallsyms] [k]
perf_adjust_freq_unthr_context.part.82
In above example, the output was sorted by 'Delta/2' column first, and
then 'Baseline/0' and finally 'Delta/1'.
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-diff.c | 87 +--
1 file changed, 85 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index f490e24e9477..8ccb48e77eab 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -551,6 +551,37 @@ hist_entry__cmp_compute(struct hist_entry *left, struct
hist_entry *right,
}
static int64_t
+hist_entry__cmp_compute_idx(struct hist_entry *left, struct hist_entry *right,
+ int c, int sort_idx)
+{
+ struct hist_entry *p_right, *p_left;
+
+ p_left = get_pair_data(left, &data__files[sort_idx]);
+ p_right = get_pair_data(right, &data__files[sort_idx]);
+
+ if (!p_left && !p_right)
+ return 0;
+
+ if (!p_left || !p_right)
+ return p_left ? -1 : 1;
+
+ if (c != COMPUTE_DELTA) {
+ /*
+* The delta can be computed without the baseline, but
+* others are not. Put those entries which have no
+* values below.
+*/
+ if (left->dummy && right->dummy)
+ return 0;
+
+ if (left->dummy || right->dummy)
+ return left->dummy ? 1 : -1;
+ }
+
+ return __hist_entry__cmp_compute(p_left, p_right, c);
+}
+
+static int64_t
hist_entry__cmp_nop(struct hist_entry *left __maybe_unused,
struct hist_entry *right __maybe_unused)
{
@@ -591,6 +622,27 @@ hist_entry__cmp_wdiff(struct hist_entry *left, struct
hist_entry *right)
return hist_entry__cmp_compute(right, left, COMPUTE_WEIGHTED_DIFF,
++data_idx);
}
+static int64_t
+hist_entry__cmp_delta_idx(struct hist_entry *left, struct hist_entry *right)
+{
+ return hist_entry__cmp_compute_idx(right, left, COMPUTE_DELTA,
+ sort_compute);
+}
+
+static int64_t
+hist_entry__cmp_ratio_idx(struct hist_entry *left, struct hist_entry *right)
+{
+ return hist_entry__cmp_compute_idx(right, left, COMPUTE_RATIO,
+ sort_compute);
+}
+
+static int64_t
+hist_entry__cmp_wdiff_idx(struct hist_entry *left, struct hist_entry *right)
+{
+ return hist_entry__cmp_compute_idx(right, left, COMPUTE_WEIGHTED_DIFF,
+ sort_compute);
+}
+
static void hists__process(struct hists *hists)
{
if (show_baseline_only)
@@ -1064,9 +1116,10 @@ static void data__hpp_register(struct data__file *d, int
idx)
perf_hpp__register_sort_field(fmt);
}
-static void ui_init(void)
+static int ui_init(void)
{
struct data__file *d;
+ struct perf_hpp_fmt *fmt;
int i;
data__for_each_file(i, d) {
@@ -1096,6 +1149,35 @@ static void ui_init(void)
data__hpp_register(d, i ? PERF_HPP_DIFF__PERIOD :
[PATCH RESEND 2/5] perf diff: Get rid of hists__compute_resort()
The hists__compute_resort() is to sort output fields based on the
given field/criteria. This was done without the sort list but as we
added the field to the sort list, we can do it with normal
hists__output_resort() using the ->sort callback.
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-diff.c | 59 +++
1 file changed, 3 insertions(+), 56 deletions(-)
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 318ab9c3f0ba..72c718e6549c 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -581,68 +581,15 @@ hist_entry__cmp_wdiff(struct hist_entry *left, struct
hist_entry *right)
return hist_entry__cmp_compute(right, left, COMPUTE_WEIGHTED_DIFF);
}
-static void insert_hist_entry_by_compute(struct rb_root *root,
-struct hist_entry *he,
-int c)
-{
- struct rb_node **p = &root->rb_node;
- struct rb_node *parent = NULL;
- struct hist_entry *iter;
-
- while (*p != NULL) {
- parent = *p;
- iter = rb_entry(parent, struct hist_entry, rb_node);
- if (hist_entry__cmp_compute(he, iter, c) < 0)
- p = &(*p)->rb_left;
- else
- p = &(*p)->rb_right;
- }
-
- rb_link_node(&he->rb_node, parent, p);
- rb_insert_color(&he->rb_node, root);
-}
-
-static void hists__compute_resort(struct hists *hists)
-{
- struct rb_root *root;
- struct rb_node *next;
-
- if (sort__need_collapse)
- root = &hists->entries_collapsed;
- else
- root = hists->entries_in;
-
- hists->entries = RB_ROOT;
- next = rb_first(root);
-
- hists__reset_stats(hists);
- hists__reset_col_len(hists);
-
- while (next != NULL) {
- struct hist_entry *he;
-
- he = rb_entry(next, struct hist_entry, rb_node_in);
- next = rb_next(&he->rb_node_in);
-
- insert_hist_entry_by_compute(&hists->entries, he, compute);
- hists__inc_stats(hists, he);
-
- if (!he->filtered)
- hists__calc_col_len(hists, he);
- }
-}
-
static void hists__process(struct hists *hists)
{
if (show_baseline_only)
hists__baseline_only(hists);
- if (sort_compute) {
+ if (sort_compute)
hists__precompute(hists);
- hists__compute_resort(hists);
- } else {
- hists__output_resort(hists, NULL);
- }
+
+ hists__output_resort(hists, NULL);
hists__fprintf(hists, true, 0, 0, 0, stdout);
}
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 1/5] perf diff: Fix to sort by baseline field by default
The currently perf diff didn't add the baseline and delta (or other
compute) fields to the sort list so output will be sorted by other
fields like alphabetical order of DSO or symbol as below example.
Fix it by adding hpp formats for the fields and provides default
compare functions.
Before:
$ perf diff
# Event 'cycles'
#
# BaselineDelta Shared Object Symbol
# ... .. ...
#
[bridge][k] ip_sabotage_in
[btrfs] [k] __etree_search.constprop.47
0.01% [btrfs] [k] btrfs_file_mmap
0.01% -0.01% [btrfs] [k] btrfs_getattr
[e1000e][k] e1000_watchdog
0.00% [kernel.vmlinux][k] PageHuge
0.00% [kernel.vmlinux][k] __acct_update_integrals
0.00% [kernel.vmlinux][k] __activate_page
[kernel.vmlinux][k] __alloc_fd
0.02% +0.02% [kernel.vmlinux][k] __alloc_pages_nodemask
...
After:
# BaselineDelta Shared Object Symbol
# ... ..
#
24.73% -4.62% perf[.] append_chain_children
7.96% -1.29% perf[.] dso__find_symbol
6.97% -2.07% libc-2.20.so[.] vfprintf
4.61% +0.88% libc-2.20.so[.] __fprintf_chk
4.41% +2.43% perf[.] sort__comm_cmp
4.10% -0.16% perf[.] comm__str
4.03% -0.93% perf[.] machine__findnew_thread_time
3.82% +3.09% perf[.] __hists__add_entry
2.95% -0.18% perf[.] sort__dso_cmp
...
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-diff.c | 44
1 file changed, 44 insertions(+)
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index e787a4406d1f..318ab9c3f0ba 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -545,6 +545,42 @@ hist_entry__cmp_compute(struct hist_entry *left, struct
hist_entry *right,
return __hist_entry__cmp_compute(p_left, p_right, c);
}
+static int64_t
+hist_entry__cmp_nop(struct hist_entry *left __maybe_unused,
+ struct hist_entry *right __maybe_unused)
+{
+ return 0;
+}
+
+static int64_t
+hist_entry__cmp_baseline(struct hist_entry *left, struct hist_entry *right)
+{
+ if (sort_compute)
+ return 0;
+
+ if (left->stat.period == right->stat.period)
+ return 0;
+ return left->stat.period > right->stat.period ? 1 : -1;
+}
+
+static int64_t
+hist_entry__cmp_delta(struct hist_entry *left, struct hist_entry *right)
+{
+ return hist_entry__cmp_compute(right, left, COMPUTE_DELTA);
+}
+
+static int64_t
+hist_entry__cmp_ratio(struct hist_entry *left, struct hist_entry *right)
+{
+ return hist_entry__cmp_compute(right, left, COMPUTE_RATIO);
+}
+
+static int64_t
+hist_entry__cmp_wdiff(struct hist_entry *left, struct hist_entry *right)
+{
+ return hist_entry__cmp_compute(right, left, COMPUTE_WEIGHTED_DIFF);
+}
+
static void insert_hist_entry_by_compute(struct rb_root *root,
struct hist_entry *he,
int c)
@@ -1038,27 +1074,35 @@ static void data__hpp_register(struct data__file *d,
int idx)
fmt->header = hpp__header;
fmt->width = hpp__width;
fmt->entry = hpp__entry_global;
+ fmt->cmp= hist_entry__cmp_nop;
+ fmt->collapse = hist_entry__cmp_nop;
/* TODO more colors */
switch (idx) {
case PERF_HPP_DIFF__BASELINE:
fmt->color = hpp__color_baseline;
+ fmt->sort = hist_entry__cmp_baseline;
break;
case PERF_HPP_DIFF__DELTA:
fmt->color = hpp__color_delta;
+ fmt->sort = hist_entry__cmp_delta;
break;
case PERF_HPP_DIFF__RATIO:
fmt->color = hpp__color_ratio;
+ fmt->sort = hist_entry__cmp_ratio;
break;
case PERF_HPP_DIFF__WEIGHTED_DIFF:
fmt->color = hpp__color_wdiff;
+ fmt->sort = hist_entry__cmp_wdiff;
break;
default:
+ fmt->sort = hist_entry__cmp_nop;
break;
}
init_header(d, dfmt);
perf_hpp__column_register(fmt);
+ perf_hpp__register_sort_field(fmt);
}
static void ui_init(void)
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] perf list: Fix --raw-dump option
Currently, 'perf list --raw-dump' requires extra arguments
(e.g., hw) to invoke, which breaks bash/zsh completion
(perf-completion.sh).
$ perf list --raw-dump
Error: unknown option `raw-dump'
usage: perf list [hw|sw|cache|tracepoint|pmu|event_glob]
After,
$ perf list --raw-dump
cpu-cycles instructions cache-references cache-misses ...
Signed-off-by: Taesoo Kim
---
tools/perf/builtin-list.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 011195e..ec76bee 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -16,14 +16,17 @@
#include "util/pmu.h"
#include "util/parse-options.h"
+static bool raw_dump = false;
+
int cmd_list(int argc, const char **argv, const char *prefix __maybe_unused)
{
int i;
const struct option list_options[] = {
+ OPT_BOOLEAN(0, "raw-dump", &raw_dump, "Dump raw events"),
OPT_END()
};
const char * const list_usage[] = {
- "perf list [hw|sw|cache|tracepoint|pmu|event_glob]",
+ "perf list [hw|sw|cache|tracepoint|pmu|event_glob|--raw-dump]",
NULL
};
@@ -32,6 +35,11 @@ int cmd_list(int argc, const char **argv, const char *prefix
__maybe_unused)
setup_pager();
+ if (raw_dump) {
+ print_events(NULL, true);
+ return 0;
+ }
+
if (argc == 0) {
print_events(NULL, false);
return 0;
@@ -53,8 +61,6 @@ int cmd_list(int argc, const char **argv, const char *prefix
__maybe_unused)
print_hwcache_events(NULL, false);
else if (strcmp(argv[i], "pmu") == 0)
print_pmu_events(NULL, false);
- else if (strcmp(argv[i], "--raw-dump") == 0)
- print_events(NULL, true);
else {
char *sep = strchr(argv[i], ':'), *s;
int sep_idx;
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Fri, Dec 26, 2014 at 4:36 PM, Dave Jones wrote: > > > > Oh - and have you actually seen the "TSC unstable (delta = xyz)" + > > "switched to hpet" messages there yet? > > not yet. 3 hrs in. Ok, so then the INFO: rcu_preempt detected stalls on CPUs/tasks: has nothing to do with HPET, since you'd still be running with the TSC enabled. My googling around did find a number of "machine locks up a few hours after switching to hpet" reports, so it is possible that the whole rcu stall and nmi watchdog thing is independent and unrelated to the actual locking up. It *is* intriguing that my broken patch seemed to prevent it from happening, though. And both NMI watchdogs and the rcu stall are related to wall-clock time. But hey, maybe there really is some odd loop in the kernel that stops scheduling or RCU grace periods. It just seems to be never caught by your backtraces.. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Fri, Dec 26, 2014 at 03:30:20PM -0800, Linus Torvalds wrote: > On Fri, Dec 26, 2014 at 2:57 PM, Dave Jones wrote: > > > > still running though.. > > Btw, did you ever boot with "tsc=reliable" as a kernel command line option? I'll check it again in the morning, but before I turn in for the night, so far the only thing is this: [ 6713.394395] INFO: rcu_preempt detected stalls on CPUs/tasks: [ 6713.394489] Tasks blocked on level-0 rcu_node (CPUs 0-7): [ 6713.394513] Tasks blocked on level-0 rcu_node (CPUs 0-7): [ 6713.394536] (detected by 3, t=6502 jiffies, g=141292, c=141291, q=0) [ 6713.394564] INFO: Stall ended before state dump start Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND v2] acpi-cpufreq: make the freq_table store the same freq value
ACPI's P-states will report the acpi_processor_px *states to acpi-cpufreq.
When the states likes these:
[index:freq, 0:2400 1:2400 2:2000 3:1600...],
we will initialize the freq_tables to those:
[index:driver_data:freq, 0:0:2400, 1:2:2000 2:3,1600 ... CPUFREQ_TABLE_END]
So when set the freqs to 2000, the data->acpi_data->state is 2
(data->freq_table[1].driver_data), So when call get_cur_freq_on_cpu, we get
the freqs is data->freq_table[2].frequency,the value is 1600.
we can make the freq_table store the same value to fix this case problem.
Signed-off-by: Wang Weidong
---
Change note:
v2: to check weather the freq_table will be changeable and clarify the problem.
The set of available states which come from acpi won't change. Just like
the power would be remove, the acpi driver will do that:
->acpi_processor_ppc_has_changed
->cpufreq_update_policy
->acpi_ppc_notifier_block.notifier_call
->acpi_processor_ppc_notifier
->cpufreq_verify_within_limits
The progress will change the policy's min_freq and max_freq
while it won't change the set of states(freq_tables).
---
drivers/cpufreq/acpi-cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index b0c18ed..93634a4 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -779,7 +779,7 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy
*policy)
/* table init */
for (i = 0; i < perf->state_count; i++) {
- if (i > 0 && perf->states[i].core_frequency >=
+ if (i > 0 && perf->states[i].core_frequency >
data->freq_table[valid_states-1].frequency / 1000)
continue;
--
1.7.12
.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf: fix building error in x86_64 when dwarf unwind is on
When build with 'make ARCH=x86' and dwarf unwind is on, there is a
compiling error:
CC /home/wn/perf/arch/x86/util/unwind-libdw.o
CC /home/wn/perf/arch/x86/tests/regs_load.o
arch/x86/tests/regs_load.S: Assembler messages:
arch/x86/tests/regs_load.S:65: Error: operand type mismatch for `push'
arch/x86/tests/regs_load.S:72: Error: operand type mismatch for `pop'
make[1]: *** [/home/wn/perf/arch/x86/tests/regs_load.o] Error 1
make[1]: INTERNAL: Exiting with 25 jobserver tokens available; should be 24!
make: *** [all] Error 2
...
Which is caused by incorrectly undefine macro HAVE_ARCH_X86_64_SUPPORT.
'config/Makefile.arch' tests __x86_64__ only when 'ARCH=x86_64'. However,
with 'ARCH=x86', the underlying compile may also be x86_64, which causes
mismatching.
This patch fixes it by checking __x86_64__ in both case of
'ARCH=x86_64' and 'ARCH=x86'.
Signed-off-by: Wang Nan
---
tools/perf/config/Makefile.arch | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/config/Makefile.arch b/tools/perf/config/Makefile.arch
index 851cd01..303a096 100644
--- a/tools/perf/config/Makefile.arch
+++ b/tools/perf/config/Makefile.arch
@@ -15,6 +15,8 @@ endif
ifeq ($(ARCH),x86_64)
override ARCH := x86
+endif
+ifeq ($(ARCH),x86)
IS_X86_64 := 0
ifeq (, $(findstring m32,$(CFLAGS)))
IS_X86_64 := $(shell echo __x86_64__ | ${CC} -E -x c - | tail -n 1)
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] nftables: nft_flush_table: handle chain dependencies
Update: I errously assumed that git add, while writing the commit
message, would be added to the commit.
Based on net-next f96fe225. Compiles and checkpatch clean.
Jumping between chains doesn't mix well with flush ruleset,
since nft_flush_table doesn't handle chains referencing chains.
This way it will take one to two loops, to settle.
Alternatively it can be solved by always having two loops,
[ 353.373791] [ cut here ]
[ 353.373845] kernel BUG at net/netfilter/nf_tables_api.c:1159!
[ 353.373896] invalid opcode: [#1] SMP
[ 353.373942] Modules linked in: intel_powerclamp uas iwldvm iwlwifi
[ 353.374017] CPU: 0 PID: 6445 Comm: 31c3.nft Not tainted 3.18.0 #98
[ 353.374069] Hardware name: LENOVO 5129CTO/5129CTO, BIOS 6QET47WW
(1.17 ) 07/14/2010
[ 353.374132] task: 880230976300 ti: 8800a8444000 task.ti:
8800a8444000
[ 353.374192] RIP: 0010:[] []
nf_tables_chain_destroy+0x58/0x60
[ 353.374275] RSP: 0018:8800a8447a90 EFLAGS: 00010202
[ 353.374320] RAX: 0001 RBX: 880231d92c00 RCX:
0001802a0027
[ 353.374379] RDX: 0001802a0028 RSI: ea0008c537c0 RDI:
8802314df4e0
[ 353.374437] RBP: 8800a8447ad8 R08: 314df201 R09:
0001802a0027
[ 353.374494] R10: 81964a32 R11: 8802314df2a0 R12:
820c50a8
[ 353.374552] R13: 820c46c0 R14: 8800ad706700 R15:
8802314dfcc0
[ 353.374611] FS: 7f96eacb6700() GS:88023bc0()
knlGS:
[ 353.374676] CS: 0010 DS: ES: CR0: 8005003b
[ 353.374723] CR2: 7f96eacc7002 CR3: a8418000 CR4:
07f0
[ 353.374781] Stack:
[ 353.374800] 81964c31 c90024fecb30
c90024fecb3c
[ 353.374872] c90024fecb7c 8800ad706700 0001
[ 353.374944] 8800ad706300 8800a8447b68 81949118
[ 353.375018] Call Trace:
[ 353.375046] [] ? nf_tables_commit+0x381/0x540
[ 353.375101] [] nfnetlink_rcv+0x3d8/0x4b0
[ 353.375150] [] netlink_unicast+0x105/0x1a0
[ 353.375200] [] netlink_sendmsg+0x32e/0x790
[ 353.375253] [] sock_sendmsg+0x8e/0xc0
[ 353.375300] [] ?
move_addr_to_kernel.part.20+0x19/0x70
[ 353.375357] [] ? move_addr_to_kernel+0x19/0x30
[ 353.375410] [] ? verify_iovec+0x42/0xd0
[ 353.375459] [] ___sys_sendmsg+0x3f0/0x400
[ 353.375510] [] ? native_sched_clock+0x2a/0x90
[ 353.375563] [] ? acct_account_cputime+0x17/0x20
[ 353.375616] [] ? account_user_time+0x88/0xa0
[ 353.375667] [] __sys_sendmsg+0x3d/0x80
[ 353.375719] [] ?
int_check_syscall_exit_work+0x34/0x3d
[ 353.375776] [] SyS_sendmsg+0xd/0x20
[ 353.375823] [] system_call_fastpath+0x16/0x1b
[ 353.375872] Code: 8b 78 10 e8 cb cd 7e ff 48 8b 7b f8 e8 f2 98 86 ff
48 8d bb 78 ff ff ff e8 56 b8 89 ff 48 83 c4 08 5b 5d c3 0f 1f 80 00 00
00 00 <0f> 0b 66 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53
[ 353.376307] RIP []
nf_tables_chain_destroy+0x58/0x60
[ 353.376368] RSP
[ 353.388988] ---[ end trace e51c442af1fdea42 ]---
Cc: sta...@vger.kernel.org
Signed-off-by: Asbjoern Sloth Toennesen
---
net/netfilter/nf_tables_api.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index 129a8da..761519b 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -712,7 +712,11 @@ static int nft_flush_table(struct nft_ctx *ctx)
int err;
struct nft_chain *chain, *nc;
struct nft_set *set, *ns;
+ int skipped_chains, flushed_chains;
+flush_chains:
+ skipped_chains = 0;
+ flushed_chains = 0;
list_for_each_entry_safe(chain, nc, &ctx->table->chains, list) {
ctx->chain = chain;
@@ -720,9 +724,20 @@ static int nft_flush_table(struct nft_ctx *ctx)
if (err < 0)
goto out;
+ if (chain->use > 0) {
+ skipped_chains++;
+ continue;
+ }
+
err = nft_delchain(ctx);
if (err < 0)
goto out;
+
+ flushed_chains++;
+ }
+ if (skipped_chains > 0) {
+ BUG_ON(flushed_chains == 0);
+ goto flush_chains;
}
list_for_each_entry_safe(set, ns, &ctx->table->sets, list) {
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Fri, Dec 26, 2014 at 03:30:20PM -0800, Linus Torvalds wrote: > On Fri, Dec 26, 2014 at 2:57 PM, Dave Jones wrote: > > > > still running though.. > > Btw, did you ever boot with "tsc=reliable" as a kernel command line option? I don't think so. > For the last night, can you see if you can just run it with that, and > things work? Sure. > So I'm not even convinced that trying to debug some HPET issue is > really worth it. Especially if your machine is a preproduction board > from Intel. Yeah, I agree. Even though it's strange that this only became a problem this last few months for me, after over a year of abuse. Hopefully the new year brings more trustworthy hardware. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Fri, Dec 26, 2014 at 03:16:41PM -0800, Linus Torvalds wrote: > On Fri, Dec 26, 2014 at 2:57 PM, Dave Jones wrote: > > > > hm. > > So with the previous patch that had the false positives, you never saw > this? You saw the false positives instead? correct. > I'm wondering if the added debug noise just ended up helping. Doing a > printk() will automatically cause some scheduler activity. And they > also caused the time reading jiggle. > > That said, it's also possible that I screwed something up in the > second version of the patch, just breaking it and making it generally > ineffective. > > Oh - and have you actually seen the "TSC unstable (delta = xyz)" + > "switched to hpet" messages there yet? not yet. 3 hrs in. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-nics] [PATCHv4 net] i40e: Implement ndo_gso_check()
On Fri, Dec 5, 2014 at 2:12 PM, Jeff Kirsher
wrote:
> On Fri, 2014-12-05 at 10:41 -0800, Joe Stringer wrote:
>> ndo_gso_check() was recently introduced to allow NICs to report the
>> offloading support that they have on a per-skb basis. Add an
>> implementation for this driver which checks for IPIP, GRE, UDP
>> tunnels.
>>
>> Signed-off-by: Joe Stringer
>> ---
>> v4: Simplify the check to just do tunnel header length.
>> Fix #define style issue.
>> v3: Drop IPIP and GRE (no driver support even though hw supports it).
>> Check for UDP outer protocol for UDP tunnels.
>> v2: Expand to include IP in IP and IPv4/IPv6 inside GRE/UDP tunnels.
>> Add MAX_INNER_LENGTH (as 80).
>> ---
>> drivers/net/ethernet/intel/i40e/i40e_main.c | 12
>> 1 file changed, 12 insertions(+)
>
> Thanks Joe, I will update the patch in my queue with your latest
> version.
Jeff, as a heads-up, this patch and the corresponding one for fm10k
will no longer apply now that the ndo has changed. This was changed by
5f35227e ("net: Generalize ndo_gso_check to ndo_features_check"). The
update needed is trivial and is just due to the change in the function
signature but I'm not sure where you are in the testing process with
this.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nouveau: fix ambiguous backlight controls
Ilia,
On Fri, Dec 26, 2014 at 04:39:08PM -0500, Ilia Mirkin wrote:
> On Fri, Dec 26, 2014 at 4:26 PM, Jeremiah Mahler wrote:
> > If a display supports backlight control using the nouveau driver, and
> > also supports standard ACPI backlight control, there will be two sets of
> > controls.
> >
> > /sys/class/backlight/acpi_video0
> > /sys/class/backlight/nv_backlight
> >
> > This creates ambiguity because these controls can be out of sync with
> > each other. One could be at 100% while the other is at 0% and the
> > actual display brightness depends on which one was used last. This also
> > creates anomalies in Powertop which will show two values for brightness
> > with potentially different values.
> >
> > Fix this ambiguity by having the nouveau driver only enable its
> > backlight controls if the standard ACPI controls are not present.
> >
> > Signed-off-by: Jeremiah Mahler
> > ---
> > drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> > b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> > index e566c5b..3a52bd4 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> > @@ -221,6 +221,11 @@ nouveau_backlight_init(struct drm_device *dev)
> > struct nvif_device *device = &drm->device;
> > struct drm_connector *connector;
> >
> > + if (acpi_video_backlight_support()) {
>
> None of the other drivers have this. Is nouveau somehow different
> than, say, radeon in this respect?
>
> Unfortunately the backlight situation is pretty fubar'd... sometimes
> the acpi controls don't work, sometimes the card controls don't work,
> sometimes they both work but in different ways (and then everyone's
> favourite -- neither works, and there's some third platform thing).
> I'm pretty sure this code existed before, but got removed. See commit
> bee564430feec1175ee64bcfd4913cacc519f817 and the previous commit
> 5bead799d3f8 before that. The ping-pong is probably not the right way
> to go.
>
I was not aware of that change. But you are right, it took out what I
was trying to put back in.
Thanks for the helpful information. I will have to rethink this fix.
[...]
--
- Jeremiah Mahler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] DT Binding for omap3 temperature sensor
Hi Pavel,
On Fri, Dec 26, 2014 at 06:19:44PM +0100, Pavel Machek wrote:
> On Fri 2014-12-26 13:34:52, Sebastian Reichel wrote:
> > OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > which can be used to determine the SoCs temperature. This provides a
> > DT binding specification for the temperature monitor.
> >
> > Signed-off-by: Sebastian Reichel
> > ---
> > .../bindings/hwmon/omap3-temperature.txt | 25
> > ++
> > 1 file changed, 25 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> >
> > diff --git a/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> > b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> > new file mode 100644
> > index 000..99631ad
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> > @@ -0,0 +1,25 @@
> > +* OMAP3 temperature sensor
> > +
> > +The OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> > +which can be used to determine the SoCs temperature.
> > +
> > +Requires node properties:
> > +- compatible : should contain one of
> > + - "ti,omap34xx-temperature-sensor" for OMAP34xx
> > + - "ti,omap36xx-temperature-sensor" for OMAP36xx
> > +- syscon : Should be a phandle to system configuration node which
> > + encompases the temperature register
> > +- clocks : Should contain 32KHz fclk clock specifier
> > +- clock-names :Should contain clock names
> > + - "fck" for the 32KHz fclk clock specifier
>
> I don't quite get it. The temperature sensor is internal on the CPU,
> right? Why do we need device tree to describe it? As soon as we have
> CPU that is compatible to ti,omap3430, we know everything we need to
> know, no?
Lots of stuff is SoC internal and described in the DT (e.g. serial
controllers). Just have a look in omap3.dtsi or omap34xx.dtsi.
I put the temperature sensor into its own node for the following
reasons:
* syscon reference
* clock reference
I first thought about loading the driver from the syscon driver,
but omap uses a generic one, so that's not an option. Apart from
that one would still need the clock reference.
> > +Example for omap34xx:
> > +
> > +/ {
> > + temperature-sensor {
> > + compatible = "ti,omap34xx-temperature-sensor";
> > + syscon = <&omap3_scm_general>;
> > + clocks = <&ts_fck>;
> > + clock-names = "fck";
> > + };
> > +};
>
> Or is there something that depends on the board there? Or do we want
> to do it like this to be consistent with existing bindings?
This is SoC specific and should go into the omap34xx.dtsi and
omap36xx.dtsi files. See also PATCH 3/3.
-- Sebastian
signature.asc
Description: Digital signature
Re: fanotify bug on gdb -- hard crash
hi pavel---I do a complete fresh install on ubuntu 64-bit 14.10 in a vmware virtual machine. the gcc version is 4.9.1. this way I cannot have made a mistake. ;-) the compile is gcc -g -o testfa testfa.c . the gdb and program must run with root privilege. without it, it will just abort on the fd test. then gdb, do "b main", "run", and step through with 'n's. you should see "calling fanotify_mark: fd=3" and then, on the next 'n', it should never return from the fanotify_mark. you should not be able to interrupt. at this point, you have to pull the plug. (I think I also trigger this sometimes without gdb, but then it is not intermittent but replicable. I started debugging because of this issue.) /iaw Ivo Welch (ivo.we...@gmail.com) http://www.ivo-welch.info/ J. Fred Weston Professor of Finance Anderson School at UCLA, C519 Director, UCLA Anderson Fink Center for Finance and Investments Free Finance Textbook, http://book.ivo-welch.info/ Editor, Critical Finance Review, http://www.critical-finance-review.org/ On Sat, Dec 27, 2014 at 6:14 AM, Pavel Machek wrote: > On Fri 2014-12-26 22:45:38, ivo welch wrote: >> I am not a kernel developer, so forgive the intrusion. > > Good bug reports are always welcome. > >> I suspect I have found either a bug in gdb (less likely) or a bug in >> fanotify (more likely). it is replicable, and the code is almost >> unchanged from the example in the fanotify man page. to trigger it, >> all an su needs to do is to step through the program below with gdb >> 7.8.1 'n' command, and linux locks up the system pretty hard (reboot > > Hard lockup -> this can't be gdb problem. > >> required). I have confirmed the replicability of this issue on a >> clean arch 2014.12.01 3.17.6-1 system and on a clean ubuntu 14.10 >> system, both VMs created just to check it. /iaw > > Does it need root priviledges to trigger? > > Best regards, > Pavel > > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/13] incorrect use of init_completion fixup
On Fri, Dec 26, 2014 at 09:06:10AM +0100, Nicholas Mc Guire wrote: > The successive init_completion calls should be reinit_completion calls. > > patch against 3.19.0-rc1 linux-next > > Acked-by: Helge Deller > Signed-off-by: Nicholas Mc Guire Applied, thank you. > --- > drivers/input/keyboard/hil_kbd.c |6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/input/keyboard/hil_kbd.c > b/drivers/input/keyboard/hil_kbd.c > index 610a8af..5b152f2 100644 > --- a/drivers/input/keyboard/hil_kbd.c > +++ b/drivers/input/keyboard/hil_kbd.c > @@ -473,7 +473,7 @@ static int hil_dev_connect(struct serio *serio, struct > serio_driver *drv) > if (error) > goto bail1; > > - init_completion(&dev->cmd_done); > + reinit_completion(&dev->cmd_done); > serio_write(serio, 0); > serio_write(serio, 0); > serio_write(serio, HIL_PKT_CMD >> 8); > @@ -482,7 +482,7 @@ static int hil_dev_connect(struct serio *serio, struct > serio_driver *drv) > if (error) > goto bail1; > > - init_completion(&dev->cmd_done); > + reinit_completion(&dev->cmd_done); > serio_write(serio, 0); > serio_write(serio, 0); > serio_write(serio, HIL_PKT_CMD >> 8); > @@ -491,7 +491,7 @@ static int hil_dev_connect(struct serio *serio, struct > serio_driver *drv) > if (error) > goto bail1; > > - init_completion(&dev->cmd_done); > + reinit_completion(&dev->cmd_done); > serio_write(serio, 0); > serio_write(serio, 0); > serio_write(serio, HIL_PKT_CMD >> 8); > -- > 1.7.10.4 > -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] hrtimers: calculate expires_next after all timers are executed
On 06/22/2014 07:46 AM, Thomas Gleixner wrote:
>> +for (i = 0; i < HRTIMER_MAX_CLOCK_BASES; i++) {
>> +ktime_t expires;
> So this adds the third incarnation of finding the next expiring timer
> to the code. Not really helpful.
>
> Untested patch which addresses the issues below.
We think we're running into the same issue that's fixed by this patch,
but the occurrence is very rare so reproducing is hard. Did this ever go
anywhere?
>
> >
> include/linux/hrtimer.h |2
> kernel/hrtimer.c| 162
> ++--
> 2 files changed, 90 insertions(+), 74 deletions(-)
>
> Index: linux/include/linux/hrtimer.h
> ===
> --- linux.orig/include/linux/hrtimer.h
> +++ linux/include/linux/hrtimer.h
> @@ -141,6 +141,7 @@ struct hrtimer_sleeper {
> * @get_time:function to retrieve the current time of the
> clock
> * @softirq_time:the time when running the hrtimer queue in the softirq
> * @offset: offset of this clock to the monotonic base
> + * @expires_next:absolute time of the next event on this clock base
> */
> struct hrtimer_clock_base {
> struct hrtimer_cpu_base *cpu_base;
> @@ -151,6 +152,7 @@ struct hrtimer_clock_base {
> ktime_t (*get_time)(void);
> ktime_t softirq_time;
> ktime_t offset;
> + ktime_t expires_next;
> };
>
> enum hrtimer_base_type {
> Index: linux/kernel/hrtimer.c
> ===
> --- linux.orig/kernel/hrtimer.c
> +++ linux/kernel/hrtimer.c
> @@ -494,6 +494,36 @@ static inline void debug_deactivate(stru
> trace_hrtimer_cancel(timer);
> }
>
> +/*
> + * Find the next expiring timer and return the expiry in absolute
> + * CLOCK_MONOTONIC time.
> + */
> +static ktime_t hrtimer_get_expires_next(struct hrtimer_cpu_base *cpu_base)
> +{
> + ktime_t expires, expires_next = { .tv64 = KTIME_MAX };
> + unsigned long idx, active = cpu_base->active_bases;
> + struct hrtimer_clock_base *base;
> +
> + while (active) {
> + idx = __ffs(active);
> + active &= ~(1UL << idx);
> +
> + base = cpu_base->clock_base + idx;
> + /* Adjust to CLOCK_MONOTONIC */
> + expires = ktime_sub(base->expires_next, base->offset);
> +
> + if (expires.tv64 < expires_next.tv64)
> + expires_next = expires;
> + }
> + /*
> + * If clock_was_set() has changed base->offset the result
> + * might be negative. Fix it up to prevent a false positive in
> + * clockevents_program_event()
> + */
> + expires.tv64 = 0;
> + return expires_next.tv64 < 0 ? expires : expires_next;
> +}
> +
> /* High resolution timer related functions */
> #ifdef CONFIG_HIGH_RES_TIMERS
>
> @@ -542,32 +572,7 @@ static inline int hrtimer_hres_active(vo
> static void
> hrtimer_force_reprogram(struct hrtimer_cpu_base *cpu_base, int skip_equal)
> {
> - int i;
> - struct hrtimer_clock_base *base = cpu_base->clock_base;
> - ktime_t expires, expires_next;
> -
> - expires_next.tv64 = KTIME_MAX;
> -
> - for (i = 0; i < HRTIMER_MAX_CLOCK_BASES; i++, base++) {
> - struct hrtimer *timer;
> - struct timerqueue_node *next;
> -
> - next = timerqueue_getnext(&base->active);
> - if (!next)
> - continue;
> - timer = container_of(next, struct hrtimer, node);
> -
> - expires = ktime_sub(hrtimer_get_expires(timer), base->offset);
> - /*
> - * clock_was_set() has changed base->offset so the
> - * result might be negative. Fix it up to prevent a
> - * false positive in clockevents_program_event()
> - */
> - if (expires.tv64 < 0)
> - expires.tv64 = 0;
> - if (expires.tv64 < expires_next.tv64)
> - expires_next = expires;
> - }
> + ktime_t expires_next = hrtimer_get_expires_next(cpu_base);
>
> if (skip_equal && expires_next.tv64 == cpu_base->expires_next.tv64)
> return;
> @@ -891,6 +896,8 @@ EXPORT_SYMBOL_GPL(hrtimer_forward);
> static int enqueue_hrtimer(struct hrtimer *timer,
> struct hrtimer_clock_base *base)
> {
> + int leftmost;
> +
> debug_activate(timer);
>
> timerqueue_add(&base->active, &timer->node);
> @@ -902,7 +909,13 @@ static int enqueue_hrtimer(struct hrtime
>*/
> timer->state |= HRTIMER_STATE_ENQUEUED;
>
> - return (&timer->node == base->active.next);
> + leftmost = &timer->node == base->active.next;
> + /*
> + * If the new timer is the leftmost, update clock_base->expires_next.
> + */
> + if (leftmost)
> + base->expires_next = hrtim
[PATCHv5 2/2] INPUT: Introduce generic trigger/LED pairs to input LEDs
This permits to reassign input LEDs to something else than keyboard "leds"
state, by adding a trigger and a led for each input leds, the former being
triggered by EV_LED events, and the latter being by default triggered by the
former. The user can then make the LED use another trigger, including other LED
triggers of the same keyboard.
The hardware LEDs are now not actioned from the ED_LED event any more, but from
the per-device LED layer.
[ebro...@mokafive.com: Rebased to 3.2-rc1 or so, cleaned up some includes, and
fixed some constants]
[blo...@openwrt.org: CONFIG_INPUT_LEDS stubs should be static inline]
[a...@linux-foundation.org: remove unneeded `extern', fix comment layout]
Signed-off-by: Samuel Thibault
Signed-off-by: Evan Broder
Acked-by: Peter Korsgaard
Signed-off-by: John Crispin
Signed-off-by: Andrew Morton
---
Changed in this version:
- separate kbd LED changes from input LED changes
- add a per-device trigger, triggered by EV_LED events
- make the per-device LED triggered by default by the per-device trigger, so
that evdev users get the modified behavior too
- make the hardware driven by the LED instead of EV_LED events
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include "input-compat.h"
MODULE_AUTHOR("Vojtech Pavlik ");
@@ -324,11 +325,20 @@ static int input_get_disposition(struct
break;
case EV_LED:
- if (is_event_supported(code, dev->ledbit, LED_MAX) &&
- !!test_bit(code, dev->led) != !!value) {
-
- __change_bit(code, dev->led);
- disposition = INPUT_PASS_TO_ALL;
+ if (is_event_supported(code, dev->ledbit, LED_MAX)) {
+#ifdef CONFIG_INPUT_LED
+ /* Redirect through trigger/LED pair */
+ if (dev->triggers && dev->triggers[code].name)
+ led_trigger_event(&dev->triggers[code],
+ value ? LED_FULL : LED_OFF);
+ disposition = INPUT_PASS_TO_HANDLERS;
+#else /* !CONFIG_INPUT_LED */
+ /* Directly pass to device */
+ if (!!test_bit(code, dev->led) != !!value) {
+ __change_bit(code, dev->led);
+ disposition = INPUT_PASS_TO_ALL;
+ }
+#endif /* !CONFIG_INPUT_LED */
}
break;
@@ -711,6 +721,9 @@ static void input_disconnect_device(stru
handle->open = 0;
spin_unlock_irq(&dev->event_lock);
+
+ if (is_event_supported(EV_LED, dev->evbit, EV_MAX))
+ input_led_disconnect(dev);
}
/**
@@ -2137,6 +2150,9 @@ int input_register_device(struct input_d
list_add_tail(&dev->node, &input_dev_list);
+ if (is_event_supported(EV_LED, dev->evbit, EV_MAX))
+ input_led_connect(dev);
+
list_for_each_entry(handler, &input_handler_list, node)
input_attach_handler(dev, handler);
--- a/drivers/input/Kconfig
+++ b/drivers/input/Kconfig
@@ -178,6 +178,15 @@ comment "Input Device Drivers"
source "drivers/input/keyboard/Kconfig"
+config INPUT_LEDS
+ bool "LED Support"
+ depends on LEDS_CLASS = INPUT || LEDS_CLASS = y
+ select LEDS_TRIGGERS
+ default y
+ help
+ This option enables support for LEDs on keyboards managed
+ by the input layer.
+
source "drivers/input/mouse/Kconfig"
source "drivers/input/joystick/Kconfig"
--- a/drivers/input/Makefile
+++ b/drivers/input/Makefile
@@ -6,6 +6,9 @@
obj-$(CONFIG_INPUT)+= input-core.o
input-core-y := input.o input-compat.o input-mt.o ff-core.o
+ifeq ($(CONFIG_INPUT_LEDS),y)
+input-core-y += leds.o
+endif
obj-$(CONFIG_INPUT_FF_MEMLESS) += ff-memless.o
obj-$(CONFIG_INPUT_POLLDEV)+= input-polldev.o
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -79,6 +79,8 @@ struct input_value {
* @led: reflects current state of device's LEDs
* @snd: reflects current state of sound effects
* @sw: reflects current state of device's switches
+ * @leds: led objects for the device's LEDs
+ * @triggers: trigger objects for the device's LEDs
* @open: this method is called when the very first user calls
* input_open_device(). The driver must prepare the device
* to start generating events (start polling thread,
@@ -164,6 +166,9 @@ struct input_dev {
unsigned long snd[BITS_TO_LONGS(SND_CNT)];
unsigned long sw[BITS_TO_LONGS(SW_CNT)];
+ struct led_classdev *leds;
+ struct led_trigger *triggers;
+
int (*open)(struct input_dev *dev);
void (*close)(struct input_dev *dev);
int (*flush)(struct input_dev *dev, struct file *file);
@@ -531,4 +536,22 @@ int input_ff_erase(struct input_dev *dev
int input_ff_create_memless(struct input_dev *dev, void *data,
Re: frequent lockups in 3.18rc4
On Fri, Dec 26, 2014 at 2:57 PM, Dave Jones wrote: > > still running though.. Btw, did you ever boot with "tsc=reliable" as a kernel command line option? For the last night, can you see if you can just run it with that, and things work? Because by now, my gut feel is that we should start derating the HPET rather than the TSC, especially going forward on modern hardware. And if this is some subtle timing issue with our hpet code (the whole -ETIME thing when getting close to setting a timer is subtle, for example, even if the HPET hardware itself would be ok), I'm wondering if the fix isn't to just stop believing in HPET if there are better alternatives around. So I'm not even convinced that trying to debug some HPET issue is really worth it. Especially if your machine is a preproduction board from Intel. But verifying that with just the TSC everything is ok might still be worth it. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: lustre: do not ignore try_module_get() fail in obd_class_open()
obd_class_open() ignores error code of try_module_get(),
while it can lead to race with module unload.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/staging/lustre/lustre/obdclass/linux/linux-module.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
b/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
index 66ceab20c743..bb4bc72ddac7 100644
--- a/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
+++ b/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
@@ -168,8 +168,7 @@ EXPORT_SYMBOL(obd_ioctl_popdata);
/* opening /dev/obd */
static int obd_class_open(struct inode *inode, struct file *file)
{
- try_module_get(THIS_MODULE);
- return 0;
+ return try_module_get(THIS_MODULE);
}
/* closing /dev/obd */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv5 1/2] INPUT: Introduce generic trigger/LED pairs between keyboard modifiers and input LEDs
This permits to change which modifier triggers which keyboard LEDs, by adding
modifier triggers, and a series of evled LEDs.
This permits to fix #7063 from userland by using a modifier to implement proper
CapsLock behavior and have the keyboard caps lock led show that modifier state.
[ebro...@mokafive.com: Rebased to 3.2-rc1 or so, cleaned up some includes, and
fixed some constants]
[blo...@openwrt.org: CONFIG_INPUT_LEDS stubs should be static inline]
[a...@linux-foundation.org: remove unneeded `extern', fix comment layout]
Signed-off-by: Samuel Thibault
Signed-off-by: Evan Broder
Acked-by: Peter Korsgaard
Signed-off-by: John Crispin
Signed-off-by: Andrew Morton
---
Changed in this version:
- separate kbd LED changes from input LED changes
- remove the VT triggers, revert back to emitting EV_LED events
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -13,6 +13,9 @@ config VT
bool "Virtual terminal" if EXPERT
depends on !S390 && !UML
select INPUT
+ select NEW_LEDS
+ select LEDS_CLASS
+ select LEDS_TRIGGERS
default y
---help---
If you say Y here, you will get support for terminal devices with
--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
@@ -130,6 +131,7 @@ static char rep;/* flag
telling cha
static int shift_state = 0;
static unsigned char ledstate = 0xff; /* undefined */
+static unsigned char lockstate = 0xff; /* undefined */
static unsigned char ledioctl;
/*
@@ -962,6 +964,146 @@ static void k_brl(struct vc_data *vc, un
}
/*
+ * Keyboard LEDs are propagated by default like the following example:
+ *
+ * VT keyboard LED state or modifier state, calls kbd_bh()
+ * -> kbd-xxx VT trigger
+ * -> vt::xxx VT LED
+ * -> input EV_DEV events (in vt_led_cb)
+ *
+ * KDSETLED directly triggers vt::xxx LEDs.
+ *
+ * Userland can however choose the trigger for the vt::numl LED, or
+ * independently choose the trigger for any inputx::numl LED.
+ */
+
+/* We route VT keyboard "leds" through triggers */
+static void kbd_ledstate_trigger_activate(struct led_classdev *cdev);
+
+static struct led_trigger ledtrig_ledstate[] = {
+#define DEFINE_LEDSTATE_TRIGGER(kbd_led, nam) \
+ [kbd_led] = { \
+ .name = nam, \
+ .activate = kbd_ledstate_trigger_activate, \
+ }
+ DEFINE_LEDSTATE_TRIGGER(VC_SCROLLOCK, "kbd-scrollock"),
+ DEFINE_LEDSTATE_TRIGGER(VC_NUMLOCK, "kbd-numlock"),
+ DEFINE_LEDSTATE_TRIGGER(VC_CAPSLOCK, "kbd-capslock"),
+ DEFINE_LEDSTATE_TRIGGER(VC_KANALOCK, "kbd-kanalock"),
+#undef DEFINE_LEDSTATE_TRIGGER
+};
+
+static int input_leds[] = {
+ [VC_SCROLLOCK] = LED_SCROLLL,
+ [VC_NUMLOCK] = LED_NUML,
+ [VC_CAPSLOCK] = LED_CAPSL,
+ [VC_KANALOCK] = LED_KANA,
+};
+
+/* Called on trigger connection, to set initial state */
+static void kbd_ledstate_trigger_activate(struct led_classdev *cdev)
+{
+ struct led_trigger *trigger = cdev->trigger;
+ int led = trigger - ledtrig_ledstate;
+
+ tasklet_disable(&keyboard_tasklet);
+ led_trigger_event(trigger, ledstate & (1 << led) ? LED_FULL : LED_OFF);
+ tasklet_enable(&keyboard_tasklet);
+}
+
+/* We route VT keyboard lockstates through triggers */
+static void kbd_lockstate_trigger_activate(struct led_classdev *cdev);
+
+static struct led_trigger ledtrig_lockstate[] = {
+#define DEFINE_LOCKSTATE_TRIGGER(kbd_led, nam) \
+ [kbd_led] = { \
+ .name = nam, \
+ .activate = kbd_lockstate_trigger_activate, \
+ }
+ DEFINE_LOCKSTATE_TRIGGER(VC_SHIFTLOCK, "kbd-shiftlock"),
+ DEFINE_LOCKSTATE_TRIGGER(VC_ALTGRLOCK, "kbd-altgrlock"),
+ DEFINE_LOCKSTATE_TRIGGER(VC_CTRLLOCK, "kbd-ctrllock"),
+ DEFINE_LOCKSTATE_TRIGGER(VC_ALTLOCK,"kbd-altlock"),
+ DEFINE_LOCKSTATE_TRIGGER(VC_SHIFTLLOCK, "kbd-shiftllock"),
+ DEFINE_LOCKSTATE_TRIGGER(VC_SHIFTRLOCK, "kbd-shiftrlock"),
+ DEFINE_LOCKSTATE_TRIGGER(VC_CTRLLLOCK, "kbd-ctrlllock"),
+ DEFINE_LOCKSTATE_TRIGGER(VC_CTRLRLOCK, "kbd-ctrlrlock"),
+#undef DEFINE_LOCKSTATE_TRIGGER
+};
+
+/* Called on trigger connection, to set initial state */
+static void kbd_lockstate_trigger_activate(struct led_classdev *cdev)
+{
+ struct led_trigger *trigger = cdev->trigger;
+ int led = trigger - ledtrig_lockstate;
+
+ tasklet_disable(&keyboard_tasklet);
+ led_trigger_event(trigger, lockstate & (1 << led) ? LED_FULL : LED_OFF);
+ tasklet_enable(&keyboard_tasklet);
+}
+
+/* Handler for VT LEDs, scheduling injecting input events in a worker */
+static void vt_led_set(struct led_classdev *cdev,
+ enum led_brightness brightness);
+static struct led_classdev vt_leds[LED_CNT] = {
+#define DEFINE_INPUT_LED(vt_led, nam, deftrig) \
+ [vt_led] = { \
+
[PATCHv5 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer
Here is v5 coming, with separate patches for the kbd and the input parts. Samuel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Fri, Dec 26, 2014 at 2:57 PM, Dave Jones wrote: > > hm. So with the previous patch that had the false positives, you never saw this? You saw the false positives instead? I'm wondering if the added debug noise just ended up helping. Doing a printk() will automatically cause some scheduler activity. And they also caused the time reading jiggle. That said, it's also possible that I screwed something up in the second version of the patch, just breaking it and making it generally ineffective. Oh - and have you actually seen the "TSC unstable (delta = xyz)" + "switched to hpet" messages there yet? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pull-request: wireless-drivers 2014-12-26
From: Kalle Valo Date: Fri, 26 Dec 2014 14:09:42 +0200 > here's my first wireless-drivers pull request after John's "retirement". > I'll start this with few fixes for 3.19, changelog below. > > I used a signed tag to create this pull request, I hope that's ok. > Please let me know if there are any problems. That's fine, as long as you put a good summary list into the tag's commit log message, I'm happy with it. Pulled, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] iio: imu: kmx61: fix simple_return.cocci warnings
drivers/iio/imu/kmx61.c:543:1-4: WARNING: end returns can be simpified drivers/iio/imu/kmx61.c:480:1-4: WARNING: end returns can be simpified if negative or 0 value Simplify a trivial if-return sequence. Possibly combine with a preceding function call. Generated by: scripts/coccinelle/misc/simple_return.cocci CC: Daniel Baluta Signed-off-by: Fengguang Wu --- kmx61.c |6 +- 1 file changed, 1 insertion(+), 5 deletions(-) --- a/drivers/iio/imu/kmx61.c +++ b/drivers/iio/imu/kmx61.c @@ -540,11 +540,7 @@ static int kmx61_setup_new_data_interrup return ret; } - ret = kmx61_set_mode(data, mode, KMX61_ACC | KMX61_MAG, true); - if (ret) - return ret; - - return 0; + return kmx61_set_mode(data, mode, KMX61_ACC | KMX61_MAG, true); } /** -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] nftables: nft_flush_table: handle chain dependencies
Jumping between chains doesn't mix well with flush ruleset,
since nft_flush_table doesn't handle chains referencing chains.
This way it will take one to two loops, to settle.
Alternatively it can be solved by always having two loops,
[ 353.373791] [ cut here ]
[ 353.373845] kernel BUG at net/netfilter/nf_tables_api.c:1159!
[ 353.373896] invalid opcode: [#1] SMP
[ 353.373942] Modules linked in: intel_powerclamp uas iwldvm iwlwifi
[ 353.374017] CPU: 0 PID: 6445 Comm: 31c3.nft Not tainted 3.18.0 #98
[ 353.374069] Hardware name: LENOVO 5129CTO/5129CTO, BIOS 6QET47WW
(1.17 ) 07/14/2010
[ 353.374132] task: 880230976300 ti: 8800a8444000 task.ti:
8800a8444000
[ 353.374192] RIP: 0010:[] []
nf_tables_chain_destroy+0x58/0x60
[ 353.374275] RSP: 0018:8800a8447a90 EFLAGS: 00010202
[ 353.374320] RAX: 0001 RBX: 880231d92c00 RCX:
0001802a0027
[ 353.374379] RDX: 0001802a0028 RSI: ea0008c537c0 RDI:
8802314df4e0
[ 353.374437] RBP: 8800a8447ad8 R08: 314df201 R09:
0001802a0027
[ 353.374494] R10: 81964a32 R11: 8802314df2a0 R12:
820c50a8
[ 353.374552] R13: 820c46c0 R14: 8800ad706700 R15:
8802314dfcc0
[ 353.374611] FS: 7f96eacb6700() GS:88023bc0()
knlGS:
[ 353.374676] CS: 0010 DS: ES: CR0: 8005003b
[ 353.374723] CR2: 7f96eacc7002 CR3: a8418000 CR4:
07f0
[ 353.374781] Stack:
[ 353.374800] 81964c31 c90024fecb30
c90024fecb3c
[ 353.374872] c90024fecb7c 8800ad706700 0001
[ 353.374944] 8800ad706300 8800a8447b68 81949118
[ 353.375018] Call Trace:
[ 353.375046] [] ? nf_tables_commit+0x381/0x540
[ 353.375101] [] nfnetlink_rcv+0x3d8/0x4b0
[ 353.375150] [] netlink_unicast+0x105/0x1a0
[ 353.375200] [] netlink_sendmsg+0x32e/0x790
[ 353.375253] [] sock_sendmsg+0x8e/0xc0
[ 353.375300] [] ?
move_addr_to_kernel.part.20+0x19/0x70
[ 353.375357] [] ? move_addr_to_kernel+0x19/0x30
[ 353.375410] [] ? verify_iovec+0x42/0xd0
[ 353.375459] [] ___sys_sendmsg+0x3f0/0x400
[ 353.375510] [] ? native_sched_clock+0x2a/0x90
[ 353.375563] [] ? acct_account_cputime+0x17/0x20
[ 353.375616] [] ? account_user_time+0x88/0xa0
[ 353.375667] [] __sys_sendmsg+0x3d/0x80
[ 353.375719] [] ?
int_check_syscall_exit_work+0x34/0x3d
[ 353.375776] [] SyS_sendmsg+0xd/0x20
[ 353.375823] [] system_call_fastpath+0x16/0x1b
[ 353.375872] Code: 8b 78 10 e8 cb cd 7e ff 48 8b 7b f8 e8 f2 98 86 ff
48 8d bb 78 ff ff ff e8 56 b8 89 ff 48 83 c4 08 5b 5d c3 0f 1f 80 00 00
00 00 <0f> 0b 66 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53
[ 353.376307] RIP []
nf_tables_chain_destroy+0x58/0x60
[ 353.376368] RSP
[ 353.388988] ---[ end trace e51c442af1fdea42 ]---
Cc: sta...@vger.kernel.org
Signed-off-by: Asbjoern Sloth Toennesen
---
net/netfilter/nf_tables_api.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index 129a8da..6a10cbd 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -712,7 +712,11 @@ static int nft_flush_table(struct nft_ctx *ctx)
int err;
struct nft_chain *chain, *nc;
struct nft_set *set, *ns;
+ int skipped_chains, flushed_chains;
+flush_chains:
+ skipped_chains = 0;
+ flushed_chains = 0;
list_for_each_entry_safe(chain, nc, &ctx->table->chains, list) {
ctx->chain = chain;
@@ -720,9 +724,22 @@ static int nft_flush_table(struct nft_ctx *ctx)
if (err < 0)
goto out;
+ if (chain->use > 0) {
+ skipped_chains++;
+ continue
+ }
+
err = nft_delchain(ctx);
if (err < 0)
goto out;
+
+ flushed_chains++;
+ }
+ if (skipped_chains > 0) {
+ if (flushed_chains > 0)
+ goto flush_chains
+ else
+ BUG_ON(flushed_chains == 0);
}
list_for_each_entry_safe(set, ns, &ctx->table->sets, list) {
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Fri, Dec 26, 2014 at 12:57:07PM -0800, Linus Torvalds wrote: > I have a newer version of the patch that gets rid of the false > positives with some ordering rules instead, and just for you I hacked > it up to say where the problem happens too, but it's likely too late. hm. [ 2733.047100] INFO: rcu_preempt detected stalls on CPUs/tasks: [ 2733.047188] Tasks blocked on level-0 rcu_node (CPUs 0-7): P25811 [ 2733.047216] Tasks blocked on level-0 rcu_node (CPUs 0-7): P25811 [ 2733.047242] (detected by 0, t=6502 jiffies, g=52141, c=52140, q=0) [ 2733.047271] trinity-c406R running task13416 25811 24907 0x [ 2733.047305] 88022208fd28 0002 a819f627 8801df2c [ 2733.047341] 001d31c0 0002 88022208ffd8 001d31c0 [ 2733.047375] 8800806e1780 8801df2c 88022208fd18 88022208ffd8 [ 2733.047411] Call Trace: [ 2733.047429] [] ? context_tracking_user_exit+0x67/0x280 [ 2733.047457] [] preempt_schedule_irq+0x52/0xb0 [ 2733.047482] [] retint_kernel+0x20/0x30 [ 2733.047505] [] ? check_kill_permission+0xb1/0x1e0 [ 2733.047531] [] ? check_kill_permission+0x152/0x1e0 [ 2733.047557] [] group_send_sig_info+0x65/0x150 [ 2733.047581] [] ? group_send_sig_info+0x5/0x150 [ 2733.047607] [] ? rcu_read_lock_held+0x6e/0x80 [ 2733.047632] [] kill_pid_info+0x78/0x130 [ 2733.047654] [] ? kill_pid_info+0x5/0x130 [ 2733.047677] [] SYSC_kill+0xf2/0x2f0 [ 2733.047699] [] ? SYSC_kill+0x9b/0x2f0 [ 2733.047721] [] ? trace_hardirqs_on+0xd/0x10 [ 2733.047745] [] ? syscall_trace_enter_phase1+0x125/0x1a0 [ 2733.048607] [] ? trace_hardirqs_on_caller+0x10d/0x1d0 [ 2733.049469] [] SyS_kill+0xe/0x10 [ 2733.050332] [] system_call_fastpath+0x12/0x17 [ 2733.051197] trinity-c406R running task13416 25811 24907 0x [ 2733.052064] 88022208fd28 0002 a819f627 8801df2c [ 2733.052932] 001d31c0 0002 88022208ffd8 001d31c0 [ 2733.053792] 880209e2c680 8801df2c 88022208fd18 88022208ffd8 [ 2733.054651] Call Trace: [ 2733.055500] [] ? context_tracking_user_exit+0x67/0x280 [ 2733.056362] [] preempt_schedule_irq+0x52/0xb0 [ 2733.057222] [] retint_kernel+0x20/0x30 [ 2733.058076] [] ? check_kill_permission+0xb1/0x1e0 [ 2733.058930] [] ? check_kill_permission+0x152/0x1e0 [ 2733.059778] [] group_send_sig_info+0x65/0x150 [ 2733.060624] [] ? group_send_sig_info+0x5/0x150 [ 2733.061472] [] ? rcu_read_lock_held+0x6e/0x80 [ 2733.062322] [] kill_pid_info+0x78/0x130 [ 2733.063168] [] ? kill_pid_info+0x5/0x130 [ 2733.064015] [] SYSC_kill+0xf2/0x2f0 [ 2733.064863] [] ? SYSC_kill+0x9b/0x2f0 [ 2733.065704] [] ? trace_hardirqs_on+0xd/0x10 [ 2733.066541] [] ? syscall_trace_enter_phase1+0x125/0x1a0 [ 2733.067384] [] ? trace_hardirqs_on_caller+0x10d/0x1d0 [ 2733.068217] [] SyS_kill+0xe/0x10 [ 2733.069045] [] system_call_fastpath+0x12/0x17 [ 3708.217920] perf interrupt took too long (2503 > 2500), lowering kernel.perf_event_max_sample_rate to 5 [ 4583.530580] request_module: runaway loop modprobe personality-87 still running though.. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] merge_config.sh: add -? for help
No objection to the addition of -? if you find it useful.
Acked-by: Darren Hart
--
Darren Hart
Intel Open Source Technology Center
On 12/11/14, 12:55 PM, "Olof Johansson" wrote:
>It's usual enough for help text that it makes sense to support it.
>
>Signed-off-by: Olof Johansson
>---
> scripts/kconfig/merge_config.sh | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
>diff --git a/scripts/kconfig/merge_config.sh
>b/scripts/kconfig/merge_config.sh
>index 2ab91b9..0c89537 100755
>--- a/scripts/kconfig/merge_config.sh
>+++ b/scripts/kconfig/merge_config.sh
>@@ -28,11 +28,11 @@ trap clean_up HUP INT TERM
>
> usage() {
> echo "Usage: $0 [OPTIONS] [CONFIG [...]]"
>- echo " -hdisplay this help text"
>- echo " -monly merge the fragments, do not execute the make command"
>- echo " -nuse allnoconfig instead of alldefconfig"
>- echo " -rlist redundant entries when merging fragments"
>- echo " -Odir to put generated output files"
>+ echo " -h or -? display this help text"
>+ echo " -m only merge the fragments, do not execute the make
>command"
>+ echo " -n use allnoconfig instead of alldefconfig"
>+ echo " -r list redundant entries when merging fragments"
>+ echo " -O dir to put generated output files"
> }
>
> MAKE=true
>@@ -52,7 +52,7 @@ while true; do
> shift
> continue
> ;;
>- "-h")
>+ "-h"|"-?")
> usage
> exit
> ;;
>--
>1.7.10.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] hid: Add a new id 0x501a for Genius MousePen i608X
New Genius MousePen i608X devices have a new id 0x501a instead of the
old 0x5011 so add a new #define with "_2" appended and change required
places.
The remaining two checkpatch warnings about line length
being over 80 characters are present in the original files too and this
patch was made in the same style (no line break).
Just adding a new id and changing the required places should make the
new device work without any issues according to the bug report in the
following url.
This patch was made according to and fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=67111
Signed-off-by: Giedrius Statkevičius
---
Only compile tested as I don't have this hardware to test it.
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-kye.c | 4
drivers/hid/usbhid/hid-quirks.c | 1 +
4 files changed, 7 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index f2a4879..5f49a11 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1821,6 +1821,7 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_ERGO_525V) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_EASYPEN_I405X) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_MOUSEPEN_I608X) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_MOUSEPEN_I608X_2)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_EASYPEN_M610X) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LABTEC,
USB_DEVICE_ID_LABTEC_WIRELESS_KEYBOARD) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LCPOWER, USB_DEVICE_ID_LCPOWER_LC1000 )
},
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index ac20ba0..a96bb03 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -531,6 +531,7 @@
#define USB_DEVICE_ID_KYE_GPEN_560 0x5003
#define USB_DEVICE_ID_KYE_EASYPEN_I405X0x5010
#define USB_DEVICE_ID_KYE_MOUSEPEN_I608X 0x5011
+#define USB_DEVICE_ID_KYE_MOUSEPEN_I608X_2 0x501a
#define USB_DEVICE_ID_KYE_EASYPEN_M610X0x5013
#define USB_VENDOR_ID_LABTEC 0x1020
diff --git a/drivers/hid/hid-kye.c b/drivers/hid/hid-kye.c
index b92bf01..158fcf5 100644
--- a/drivers/hid/hid-kye.c
+++ b/drivers/hid/hid-kye.c
@@ -323,6 +323,7 @@ static __u8 *kye_report_fixup(struct hid_device *hdev, __u8
*rdesc,
}
break;
case USB_DEVICE_ID_KYE_MOUSEPEN_I608X:
+ case USB_DEVICE_ID_KYE_MOUSEPEN_I608X_2:
if (*rsize == MOUSEPEN_I608X_RDESC_ORIG_SIZE) {
rdesc = mousepen_i608x_rdesc_fixed;
*rsize = sizeof(mousepen_i608x_rdesc_fixed);
@@ -415,6 +416,7 @@ static int kye_probe(struct hid_device *hdev, const struct
hid_device_id *id)
switch (id->product) {
case USB_DEVICE_ID_KYE_EASYPEN_I405X:
case USB_DEVICE_ID_KYE_MOUSEPEN_I608X:
+ case USB_DEVICE_ID_KYE_MOUSEPEN_I608X_2:
case USB_DEVICE_ID_KYE_EASYPEN_M610X:
ret = kye_tablet_enable(hdev);
if (ret) {
@@ -446,6 +448,8 @@ static const struct hid_device_id kye_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE,
USB_DEVICE_ID_KYE_MOUSEPEN_I608X) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE,
+ USB_DEVICE_ID_KYE_MOUSEPEN_I608X_2) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_KYE,
USB_DEVICE_ID_KYE_EASYPEN_M610X) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE,
USB_DEVICE_ID_GENIUS_GILA_GAMING_MOUSE) },
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index dc89be9..b27b3d3 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -124,6 +124,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_WIRELESS,
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_SIGMA_MICRO, USB_DEVICE_ID_SIGMA_MICRO_KEYBOARD,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_MOUSEPEN_I608X,
HID_QUIRK_MULTI_INPUT },
+ { USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_MOUSEPEN_I608X_2,
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_EASYPEN_M610X,
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_DUOSENSE,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_SEMICO, USB_DEVICE_ID_SEMICO_USB_KEYKOARD,
HID_QUIRK_NO_INIT_REPORTS },
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: fanotify bug on gdb -- hard crash
On Fri 2014-12-26 22:45:38, ivo welch wrote: > I am not a kernel developer, so forgive the intrusion. Good bug reports are always welcome. > I suspect I have found either a bug in gdb (less likely) or a bug in > fanotify (more likely). it is replicable, and the code is almost > unchanged from the example in the fanotify man page. to trigger it, > all an su needs to do is to step through the program below with gdb > 7.8.1 'n' command, and linux locks up the system pretty hard (reboot Hard lockup -> this can't be gdb problem. > required). I have confirmed the replicability of this issue on a > clean arch 2014.12.01 3.17.6-1 system and on a clean ubuntu 14.10 > system, both VMs created just to check it. /iaw Does it need root priviledges to trigger? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] drivers:ata: Remove unneeded fix me comment for the function,mv_print_info in sata_mv.c
Hello, Nicholas.
On Fri, Dec 26, 2014 at 04:55:59PM -0500, Nicholas Krause wrote:
> Removes a unneed fix me comment for the function,mv_print_info in sata_mv.c.
> This function is correctly completed due to printing out needed info about
> hardware to the kernel log buffer. The needed information that is being
> printed successfully now to the callers of this function is the host
> number of ports, the generation of hardware, the maximum q depth the
> hardware supports, if the hardware is either RAID or SCSI enabled and
> finally the IRQ mode enabled when called and the flag enabled with the
> respectful IRQ called.
It's often more effective to discuss to conclusion on thread before
sending another patch.
When tracking down FIXME comments, it's often a good idea to look at
how the comment came to be by digging through the history. git blame
on the file shows that the comment was added by 05b308e1df6d ("[PATCH]
libata: Marvell function headers") a long time ago. Compared to then,
the function grew generation info printing, which could have been what
the original FIXME author had in mind or maybe not. Regardless, given
that nobody has complained about lacking information over the years,
it can be argued that the FIXME is spurious.
So, I don't object to the patch itself. These are just taking way too
much effort given that the actual gain is almost nil. If you want to
continue to do this, please research about the history of FIXME and
construct and present a valid rationale for the change. For this one,
listing what it prints out doesn't constitute rationale in itself.
Please do keep in mind these changes are ultimately frivolous. If
they incur more cost than they're beneficial, they're pointless, so
please send properly formed and reasoned patches. This probably is my
last response on the subject.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: incorrect use of init_completion fixup
From: Nicholas Mc Guire Date: Tue, 23 Dec 2014 18:47:50 +0100 > The second init_completion call should be a reinit_completion here. > > patch is against 3.18.0 linux-next > > Signed-off-by: Nicholas Mc Guire Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: xilinx: Remove unnecessary temac_property in the driver
From: Kedareswara rao Appana Date: Tue, 23 Dec 2014 18:07:55 +0530 > This property is no longer used in the code yet the code looks for it in the > device tree. > It does not cause an error if it's not in the tree. > > Signed-off-by: Kedareswara rao Appana Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers:ata: Remove unneeded fix me comment for the function,mv_print_info in sata_mv.c
On Fri, Dec 26, 2014 at 04:39:57PM -0500, Nicholas Krause wrote: > Removes a unneed fix me comment for the function,mv_print_info in sata_mv.c. > This comment is no longer needed as this function has been completed correctly > to print out hardware info to the kernel log buffer and therefore this comment > is no longer needed for the function,mv_print_info. How do we know the function is completed correctly? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nouveau: fix ambiguous backlight controls
On Fri, Dec 26, 2014 at 4:26 PM, Jeremiah Mahler wrote:
> If a display supports backlight control using the nouveau driver, and
> also supports standard ACPI backlight control, there will be two sets of
> controls.
>
> /sys/class/backlight/acpi_video0
> /sys/class/backlight/nv_backlight
>
> This creates ambiguity because these controls can be out of sync with
> each other. One could be at 100% while the other is at 0% and the
> actual display brightness depends on which one was used last. This also
> creates anomalies in Powertop which will show two values for brightness
> with potentially different values.
>
> Fix this ambiguity by having the nouveau driver only enable its
> backlight controls if the standard ACPI controls are not present.
>
> Signed-off-by: Jeremiah Mahler
> ---
> drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index e566c5b..3a52bd4 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -221,6 +221,11 @@ nouveau_backlight_init(struct drm_device *dev)
> struct nvif_device *device = &drm->device;
> struct drm_connector *connector;
>
> + if (acpi_video_backlight_support()) {
None of the other drivers have this. Is nouveau somehow different
than, say, radeon in this respect?
Unfortunately the backlight situation is pretty fubar'd... sometimes
the acpi controls don't work, sometimes the card controls don't work,
sometimes they both work but in different ways (and then everyone's
favourite -- neither works, and there's some third platform thing).
I'm pretty sure this code existed before, but got removed. See commit
bee564430feec1175ee64bcfd4913cacc519f817 and the previous commit
5bead799d3f8 before that. The ping-pong is probably not the right way
to go.
> + dev_info(dev->dev, "Standard ACPI backlight control
> supported, disabling local control.\n");
> + return 0;
> + }
> +
> list_for_each_entry(connector, &dev->mode_config.connector_list,
> head) {
> if (connector->connector_type != DRM_MODE_CONNECTOR_LVDS &&
> connector->connector_type != DRM_MODE_CONNECTOR_eDP)
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] nouveau: fix ambiguous backlight controls
If a display supports backlight control using the nouveau driver, and
also supports standard ACPI backlight control, there will be two sets of
controls.
/sys/class/backlight/acpi_video0
/sys/class/backlight/nv_backlight
This creates ambiguity because these controls can be out of sync with
each other. One could be at 100% while the other is at 0% and the
actual display brightness depends on which one was used last. This also
creates anomalies in Powertop which will show two values for brightness
with potentially different values.
Fix this ambiguity by having the nouveau driver only enable its
backlight controls if the standard ACPI controls are not present.
Signed-off-by: Jeremiah Mahler
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index e566c5b..3a52bd4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -221,6 +221,11 @@ nouveau_backlight_init(struct drm_device *dev)
struct nvif_device *device = &drm->device;
struct drm_connector *connector;
+ if (acpi_video_backlight_support()) {
+ dev_info(dev->dev, "Standard ACPI backlight control supported,
disabling local control.\n");
+ return 0;
+ }
+
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
if (connector->connector_type != DRM_MODE_CONNECTOR_LVDS &&
connector->connector_type != DRM_MODE_CONNECTOR_eDP)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] bcma: Fix three coding style issues, more than 80 characters per line
On 26 December 2014 at 19:33, Oscar Forner Martinez wrote: > - /* 4706 CC and PMU watchdogs are clocked at 1/4 of > ALP clock */ > + /* 4706 CC and PMU watchdogs are clocked > +* at 1/4 of ALP clock > +*/ Your editor seems to be treating tabs incorrectly. Like more than 8 chars. After your patch "clocked" ends after 64 chars. You should try to use up to 80 chars. > - bcma_err(cc->core->bus, "serial not supported on this device > ccrev: 0x%x\n", ccrev); > + bcma_err(cc->core->bus, > +"serial not supported on this device ccrev: 0x%x\n", > +ccrev); I think you ignored my comment to V1, see it again please ;) It was about putting pointer and string in one line. -- Rafał -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] tty: serial: 8250_mtk: Add earlycon
On Thu, Dec 18, 2014 at 2:33 AM, Eddie Huang wrote:
> Mediatek UART has highspeed register, but 8250_early.c doesn't
> support this, so add earlycon in 8250_mtk.c
I don't see any highspeed register setup here. More generically,
aren't you just skipping any UART setup? That may be useful on other
platforms with 8250s, too. With the kernel command line version, you
could perhaps add a "noinit" flag. The DT case is harder, and I'm not
sure how we should handle that. We could perhaps add a
"stdout-path-initialized" flag to chosen.
>
> Signed-off-by: Eddie Huang
> ---
> drivers/tty/serial/8250/8250_mtk.c | 33 +
> 1 file changed, 33 insertions(+)
>
> diff --git a/drivers/tty/serial/8250/8250_mtk.c
> b/drivers/tty/serial/8250/8250_mtk.c
> index de7aae5..65dd569 100644
> --- a/drivers/tty/serial/8250/8250_mtk.c
> +++ b/drivers/tty/serial/8250/8250_mtk.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
>
> #include "8250.h"
>
> @@ -289,6 +290,38 @@ static struct platform_driver mtk8250_platform_driver = {
> };
> module_platform_driver(mtk8250_platform_driver);
>
> +#define BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE)
> +
> +static void __init mtk8250_serial_putc(struct uart_port *port, int c)
> +{
> + while ((readl(port->membase + (UART_LSR << 2)) & BOTH_EMPTY) !=
> + BOTH_EMPTY)
> + ;
> + writel(c, port->membase + (UART_TX << 2));
> +}
> +
> +static void __init early_mtk8250_write(struct console *console,
> + const char *s, unsigned int count)
Is there a reason early_serial8250_write can't work for you other than
it is currently static?
Rob
> +{
> + struct earlycon_device *dev = console->data;
> +
> + uart_console_write(&dev->port, s, count, mtk8250_serial_putc);
> +}
> +
> +static int __init early_mtk8250_setup(struct earlycon_device *device,
> + const char *options)
> +{
> + if (!device->port.membase)
> + return -ENODEV;
> +
> + device->con->write = early_mtk8250_write;
> +
> + return 0;
> +}
> +
> +EARLYCON_DECLARE(mtk8250, early_mtk8250_setup);
> +OF_EARLYCON_DECLARE(mtk8250, "mediatek,mt6577-uart", early_mtk8250_setup);
> +
> MODULE_AUTHOR("Matthias Brugger");
> MODULE_LICENSE("GPL");
> MODULE_DESCRIPTION("Mediatek 8250 serial port driver");
> --
> 1.8.1.1.dirty
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: phy: micrel: use generic config_init for KSZ8021/KSZ8031
From: Johan Hovold
Date: Tue, 23 Dec 2014 12:59:17 +0100
> Use generic config_init callback also for KSZ8021 and KSZ8031.
>
> This has been avoided this far due to commit b838b4aced99 ("phy/micrel:
> KSZ8031RNL RMII clock reconfiguration bug"), which claims that the PHY
> becomes unresponsive if the broadcast-disable flag is set before
> configuring the clock mode.
>
> Turns out that the problem seemingly worked-around by the above
> mentioned commit was really due to a hardware-configuration issue, where
> the PHY was in fact strapped to address 3 rather than 0.
>
> Tested-by: Bruno Thomsen
> Signed-off-by: Johan Hovold
Applied, thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Fri, Dec 26, 2014 at 12:57:07PM -0800, Linus Torvalds wrote: > I have a newer version of the patch that gets rid of the false > positives with some ordering rules instead, and just for you I hacked > it up to say where the problem happens too, but it's likely too late. I'll give it a spin and see what falls out this evening. > So I'm still a bit unhappy about not figuring out *what* is wrong. And > I'd still like the dmidecode from that machine, just for posterity. In > case we can figure out some pattern. So this is something I should have done a long time ago. Googling for the board name shows up a very similar report from a year ago, except that was within kvm, and was aparently fixed. https://lkml.org/lkml/2013/10/9/206 and https://bugzilla.kernel.org/show_bug.cgi?id=69491 (dmidecode attachment there is pretty much the same as mine) > - actual hardware bug. >This is *really* unlikely, though. It should hit everybody. The > HPET is in the core intel chipset, we're not talking random unusual > hardware by fly-by-night vendors here. This machine is allegedly a 'production' box from Intel, but given Kashyap saw something very similar I'm wondering now if there was some board/bios errata for this system. There's a few Intel folks cc'd here, maybe one those can dig up whether there was anything peculiar about Shark Bay systems that would explain the HPET getting screwed up. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/38] mm: remove non-linear mess
On Wed, Dec 24, 2014 at 02:22:08PM +0200, Kirill A. Shutemov wrote: > We have remap_file_pages(2) emulation in -mm tree for few release cycles > and we plan to have it mainline in v3.20. This patchset removes rest of > VM_NONLINEAR infrastructure. > > Patches 1-8 take care about generic code. They are pretty > straight-forward and can be applied without other of patches. > > Rest patches removes pte_file()-related stuff from architecture-specific > code. It usually frees up one bit in non-present pte. I've tried to reuse > that bit for swap offset, where I was able to figure out how to do that. > > For obvious reason I cannot test all that arch-specific code and would > like to see acks from maintainers. > > In total, remap_file_pages(2) required about 1.4K lines of not-so-trivial > kernel code. That's too much for functionality nobody uses. > > git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git remap_file_pages have been running this for a while on a three different ARM boards I have around, haven't noticed anything wrong. Tested-by: Felipe Balbi -- balbi signature.asc Description: Digital signature
Re: Question about mv_print_info in sata_mv.c in sata_mv.c
Hello, Nick. On Fri, Dec 26, 2014 at 04:06:11PM -0500, nick wrote: > I am assuming after reading this function's code, that this function is > completed and no longer > needs a fix me comment above it to be completed. I do appreciate that you're studying the FIXME comments but at this point I'm not sure whether blindly chasing them and asking people whether they're still necessary is a productive thing to do. If they're actively misleading, sure, let's remove them, but FIXME in a sata_mv function which prints some controller identification information just doesn't matter. If you can assert that the comment is no longer necessary and misleading, please submit a patch with backing rationale; otherwise, obsessing with each instance of FIXME comment doesn't seem to be a particularly productive way of participating in kernel development. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Dec 26 (f2fs)
I fixed the merged patch directly. Changman, The patch was initially made by you, so let me know, if you have objection. Thanks, On Fri, Dec 26, 2014 at 11:17:15AM -0800, Randy Dunlap wrote: > On 12/26/14 00:30, Stephen Rothwell wrote: > > Hi all, > > > > There will only be intermittent releases of linux-next between now and > > Jan 5. > > > > Changes since 20141221: > > > > on x86_64: > when CONFIG_F2FS_STAT_FS is not enabled: > > ../fs/f2fs/segment.c: In function 'rewrite_data_page': > ../fs/f2fs/segment.c:1233:2: error: implicit declaration of function > 'stat_inc_inplace_blocks' [-Werror=implicit-function-declaration] > > > > -- > ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Fri, Dec 26, 2014 at 10:12 AM, Dave Jones wrote:
> On Fri, Dec 26, 2014 at 11:34:10AM -0500, Dave Jones wrote:
>
> > One thing I think I'll try is to try and narrow down which
> > syscalls are triggering those "Clocksource hpet had cycles off"
> > messages. I'm still unclear on exactly what is doing
> > the stomping on the hpet.
>
> First I ran trinity with "-g vm" which limits it to use just
> a subset of syscalls, specifically VM related ones.
> That triggered the messages. Further experiments revealed:
So I can trigger the false positives with my original patch quite
easily by just putting my box under some load. My numbers are nowhere
near as bad as yours, but then, I didn't put it under as much load
anyway. Just a regular "make -j64" of the kernel.
I suspect your false positives are bigger partly because of the load,
but mostly because you presumably have preemption enabled too. I don't
do preemption in my normal kernels, and that limits the damage of the
race a bit.
I have a newer version of the patch that gets rid of the false
positives with some ordering rules instead, and just for you I hacked
it up to say where the problem happens too, but it's likely too late.
The fact that the original racy patch seems to make a difference for
you does say that yes, we seem to be zeroing in on the right area
here, but I'm not seeing what's wrong. I was hoping for big jumps from
your HPET, since your "TSC unstable" messages do kind of imply that
such really big jumps can happen.
I'm attaching my updated hacky patch, although I assume it's much too
late for that machine. Don't look too closely at the backtrace
generation part, that's just a quick hack, and only works with frame
pointers enabled anyway.
So I'm still a bit unhappy about not figuring out *what* is wrong. And
I'd still like the dmidecode from that machine, just for posterity. In
case we can figure out some pattern.
So right now I can imagine several reasons:
- actual hardware bug.
This is *really* unlikely, though. It should hit everybody. The
HPET is in the core intel chipset, we're not talking random unusual
hardware by fly-by-night vendors here.
- some SMM/BIOS "power management" feature.
We've seen this before, where the SMM saves/restores the TSC on
entry/exit in order to hide itself from the system. I could imagine
similar code for the HPET counter. SMM writers use some bad drugs to
dull their pain.
And with the HPET counter, since it's not even per-CPU, the "save
and restore HPET" will actually show up as "HPET went backwards" to
the other non-SMM CPU's if it happens
- a bug in our own clocksource handling.
I'm not seeing it. But maybe my patch hides it for some magical reason.
- gremlins.
So I dunno. I hope more people will look at this after the holidays,
even if your machine is gone. My test-program to do bad things to the
HPET shows *something*, and works on any machine.
Linus
arch/x86/kernel/entry_64.S | 5 +++
include/linux/timekeeper_internal.h | 1 +
kernel/time/timekeeping.c | 78 +++--
3 files changed, 81 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 9ebaf63ba182..0a4c34b4658e 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -312,6 +312,11 @@ ENTRY(save_paranoid)
CFI_ENDPROC
END(save_paranoid)
+ENTRY(save_back_trace)
+ movq %rbp,%rdi
+ jmp do_save_back_trace
+END(save_back_trace)
+
/*
* A newly forked process directly context switches into this address.
*
diff --git a/include/linux/timekeeper_internal.h
b/include/linux/timekeeper_internal.h
index 05af9a334893..0fcb60d77079 100644
--- a/include/linux/timekeeper_internal.h
+++ b/include/linux/timekeeper_internal.h
@@ -32,6 +32,7 @@ struct tk_read_base {
cycle_t (*read)(struct clocksource *cs);
cycle_t mask;
cycle_t cycle_last;
+ cycle_t cycle_error;
u32 mult;
u32 shift;
u64 xtime_nsec;
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 6a931852082f..1c924c80b462 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -140,6 +140,7 @@ static void tk_setup_internals(struct timekeeper *tk,
struct clocksource *clock)
tk->tkr.read = clock->read;
tk->tkr.mask = clock->mask;
tk->tkr.cycle_last = tk->tkr.read(clock);
+ tk->tkr.cycle_error = 0;
/* Do the ns -> cycle conversion first, using original mult */
tmp = NTP_INTERVAL_LENGTH;
@@ -191,16 +192,59 @@ u32 (*arch_gettimeoffset)(void) =
default_arch_gettimeoffset;
static inline u32 arch_gettimeoffset(void) { return 0; }
#endif
+unsigned long tracebuffer[16];
+
+extern void save_back_trace(long dummy, void *ptr);
+
+void do_save_back_trace(long rbp,
Re: Question about mv_print_info in sata_mv.c in sata_mv.c
On Mon, Dec 22, 2014 at 10:04 PM, nick wrote: > Greetings Tejuin,Grant and Rob, > Hope you are having a good holidays. I am wondering if there is > anything we need to add to this function as stated in a fix me above it.I am > pretty certain > there isn't but as the maintainers, I am double checking first with you:). > Please let me > known if you think of something. Grant and I are not actually maintainers of this driver. get_maintainer.pl is somewhat wrong here because it matches on regex that is present in about every driver that is DT enabled. I've sent a patch now to change that. It would help also if you paste in the actually code you are referring to. Rob > Regards and Have a Great Holidays :), > Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] media: i2c/adp1653: devicetree support for adp1653
On Fri, Dec 26, 2014 at 2:33 PM, Pavel Machek wrote:
> Hi!
>
>> > We are moving to device tree support on OMAP3, but that currently
>> > breaks ADP1653 driver. This adds device tree support, plus required
>> > documentation.
>> >
>> > Signed-off-by: Pavel Machek
>> >
>> > ---
>> >
>> > Changed -microsec to -us, as requested by devicetree people.
>> >
>> > Fixed checkpatch issues.
>> >
>> > diff --git a/Documentation/devicetree/bindings/leds/common.txt
>> > b/Documentation/devicetree/bindings/leds/common.txt
>> > index 2d88816..2c6c7c5 100644
>> > --- a/Documentation/devicetree/bindings/leds/common.txt
>> > +++ b/Documentation/devicetree/bindings/leds/common.txt
>> > @@ -14,6 +14,15 @@ Optional properties for child nodes:
>> > "ide-disk" - LED indicates disk activity
>> > "timer" - LED flashes at a fixed, configurable rate
>> >
>> > +- max-microamp : maximum intensity in microamperes of the LED
>> > +(torch LED for flash devices)
>> > +- flash-max-microamp : maximum intensity in microamperes of the
>> > + flash LED; it is mandatory if the LED should
>> > + support the flash mode
>> > +- flash-timeout-microsec : timeout in microseconds after which the flash
>> > + LED is turned off
>>
>> Doesn't all this go in your flash led binding patch?
>
> No, I should not have included this part.
>
>> > +Example:
>> > +
>> > +adp1653: led-controller@30 {
>> > +compatible = "adi,adp1653";
>> > + reg = <0x30>;
>> > +gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
>> > +
>> > + flash {
>> > +flash-timeout-us = <50>;
>> > +flash-max-microamp = <32>;
>> > +max-microamp = <5>;
>> > + };
>> > +indicator {
>>
>> These are different LEDs or different modes?
>
> flash & indicator are different LEDs. One is white, one is red. Flash
> can be used as a flash and as a torch.
>
>> > +max-microamp = <17500>;
>>
>> This is a bit inconsistent. The binding says this is for flash LEDs
>> torch mode, but I see no reason why it can't be common. Can you update
>> the binding doc to be clear here.
>
> By inconsisnent, you mean you want patch below?
Yes.
>> Also, aren't you missing label properties?
>
> label is optional, and as my driver does not yet use it, I forgot
> about it.
Based on your node names, there are obviously user defined functions
for them already. So they should have labels whether or not the driver
uses them.
Rob
> Signed-off-by: Pavel Machek
>
> index 2c6c7c5..92d4dac 100644
> --- a/Documentation/devicetree/bindings/leds/common.txt
> +++ b/Documentation/devicetree/bindings/leds/common.txt
> @@ -15,7 +15,6 @@ Optional properties for child nodes:
> "timer" - LED flashes at a fixed, configurable rate
>
> - max-microamp : maximum intensity in microamperes of the LED
> -(torch LED for flash devices)
> - flash-max-microamp : maximum intensity in microamperes of the
> flash LED; it is mandatory if the LED should
>support the flash mode
>
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] MAINTAINERS: Update DT website and git repository
From: Rob Herring Per Grant, secretlab.ca is defunct and he has no plans to resurect it, so update the DT website and git tree. devicetree.org needs work, but is better than "Internal Server Error" that secretlab.ca returns. Cc: Grant Likely Signed-off-by: Rob Herring --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index fa9ae27..7c6c4df 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6977,8 +6977,8 @@ OPEN FIRMWARE AND FLATTENED DEVICE TREE M: Grant Likely M: Rob Herring L: devicet...@vger.kernel.org -W: http://fdt.secretlab.ca -T: git git://git.secretlab.ca/git/linux-2.6.git +W: http://www.devicetree.org/ +T: git git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux.git S: Maintained F: drivers/of/ F: include/linux/of*.h -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] MAINTAINERS: drop DT regex matching on of_get_property and of_match_table
From: Rob Herring The regex matching on of_get_property and of_match_table cause Grant and me to be copied on loads of drivers as well as be listed as maintainers of those drivers. I believe the intent here was to check for documenting of properties, but that has proven horribly ineffective. checkpatch now at least partially covers this checking compatible strings. So remove these regex's to reduce the firehose somewhat. Cc: Grant Likely Signed-off-by: Rob Herring --- MAINTAINERS | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index ddb9ac8..fa9ae27 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -696,7 +696,7 @@ L: alsa-de...@alsa-project.org (moderated for non-subscribers) W: http://blackfin.uclinux.org/ S: Supported F: sound/soc/blackfin/* - + ANALOG DEVICES INC IIO DRIVERS M: Lars-Peter Clausen M: Michael Hennerich @@ -6983,8 +6983,6 @@ S:Maintained F: drivers/of/ F: include/linux/of*.h F: scripts/dtc/ -K: of_get_property -K: of_match_table OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS M: Rob Herring -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] media: i2c/adp1653: devicetree support for adp1653
Hi!
> > We are moving to device tree support on OMAP3, but that currently
> > breaks ADP1653 driver. This adds device tree support, plus required
> > documentation.
> >
> > Signed-off-by: Pavel Machek
> >
> > ---
> >
> > Changed -microsec to -us, as requested by devicetree people.
> >
> > Fixed checkpatch issues.
> >
> > diff --git a/Documentation/devicetree/bindings/leds/common.txt
> > b/Documentation/devicetree/bindings/leds/common.txt
> > index 2d88816..2c6c7c5 100644
> > --- a/Documentation/devicetree/bindings/leds/common.txt
> > +++ b/Documentation/devicetree/bindings/leds/common.txt
> > @@ -14,6 +14,15 @@ Optional properties for child nodes:
> > "ide-disk" - LED indicates disk activity
> > "timer" - LED flashes at a fixed, configurable rate
> >
> > +- max-microamp : maximum intensity in microamperes of the LED
> > +(torch LED for flash devices)
> > +- flash-max-microamp : maximum intensity in microamperes of the
> > + flash LED; it is mandatory if the LED should
> > + support the flash mode
> > +- flash-timeout-microsec : timeout in microseconds after which the flash
> > + LED is turned off
>
> Doesn't all this go in your flash led binding patch?
No, I should not have included this part.
> > +Example:
> > +
> > +adp1653: led-controller@30 {
> > +compatible = "adi,adp1653";
> > + reg = <0x30>;
> > +gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
> > +
> > + flash {
> > +flash-timeout-us = <50>;
> > +flash-max-microamp = <32>;
> > +max-microamp = <5>;
> > + };
> > +indicator {
>
> These are different LEDs or different modes?
flash & indicator are different LEDs. One is white, one is red. Flash
can be used as a flash and as a torch.
> > +max-microamp = <17500>;
>
> This is a bit inconsistent. The binding says this is for flash LEDs
> torch mode, but I see no reason why it can't be common. Can you update
> the binding doc to be clear here.
By inconsisnent, you mean you want patch below?
> Also, aren't you missing label properties?
label is optional, and as my driver does not yet use it, I forgot
about it.
Signed-off-by: Pavel Machek
index 2c6c7c5..92d4dac 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -15,7 +15,6 @@ Optional properties for child nodes:
"timer" - LED flashes at a fixed, configurable rate
- max-microamp : maximum intensity in microamperes of the LED
-(torch LED for flash devices)
- flash-max-microamp : maximum intensity in microamperes of the
flash LED; it is mandatory if the LED should
support the flash mode
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 2/3] mfd: qcom-rpm: Driver for the Qualcomm RPM
On Mon, Dec 22, 2014 at 2:50 AM, Paul Bolle wrote: > Hi Bjorn, > Hi Paul [..] > > The Qualcomm RPM regulator driver (see Kconfig symbol > REGULATOR_QCOM_RPM) was added in v3.18. It depends on the above symbol, > so it has not yet gotten build coverage. Even manual hacks like > make -C ../.. M=$PWD CONFIG_REGULATOR_QCOM_RPM=m qcom_rpm-regulator.ko > > won't work for that driver, because it includes linux/mfd/qcom_rpm.h, > which is not part of the tree. > Correct, but unfortunately Lee Jones awaits devicetree maintainers ack (or any comment) and have been doing so for months now. I did send out a ping a few weeks ago, but might have done so when they where occupied by the merge window. Lee, the Qualcomm RPM binding is not for a subsystem and is limited to Qualcomm devices. Could we apply this in accordance with II.2 in Documentation/devicetree/bindings/submitting-patches.txt or is there anything I could do to make you feel comfortable doing so? > It seems there's no generally agreed upon guideline for situations like > this. So I guess it's up to Mark to decide how long the tree should > include an unbuildable driver. > I haven't seen any guidelines, but appreciate Mark's way of working in this matter - as we've been able to run our devices with fewer out-of-tree patches. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 1/2] socket: Allow external sockets to use socket syscalls
Hello Al, On 12/26/14 2:56 PM, Al Viro wrote: On Thu, Dec 25, 2014 at 10:50:23PM -0800, Alex Gartrell wrote: Currently the "is-socket" test for a file compares the ops table pointer, which is static and local to the socket.c. Instead, this adds a flag for private_data_is_socket. This is an exceptionally long commit message for a two-line patch. NAK. Don't crap into struct file, please. I don't disagree with your sentiment here. Is the additional f_op approach less gross or do you have something else in mind? Thanks, -- Alex Gartrell -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 1/2] socket: Allow external sockets to use socket syscalls
On Thu, Dec 25, 2014 at 10:50:23PM -0800, Alex Gartrell wrote: > Currently the "is-socket" test for a file compares the ops table pointer, > which is static and local to the socket.c. Instead, this adds a flag for > private_data_is_socket. This is an exceptionally long commit message for a > two-line patch. NAK. Don't crap into struct file, please. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] of/pci: add of_pci_dma_configure() update dma configuration
On Wed, Dec 24, 2014 at 4:11 PM, Murali Karicheri wrote:
> Add of_pci_dma_configure() to allow updating the dma configuration
> of the pci device using the configuration from DT of the parent of
> the root bridge device.
>
> Signed-off-by: Murali Karicheri
> ---
> drivers/of/of_pci.c| 73
>
> include/linux/of_pci.h | 12
> 2 files changed, 85 insertions(+)
>
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 88471d3..6d43f59 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -229,6 +229,79 @@ parse_failed:
> return err;
> }
> EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
> +
> +/**
> + * of_get_pci_root_bridge_parent - Helper function to get the OF node of
> + * the root bridge's parent
I believe this has to be a one line description for DocBook.
> + * @dev: ptr to pci_dev struct of the pci device
> + *
> + * This function will traverse the bus up to the root bus starting with
> + * the child and return the of node ptr to bridge device's parent device.
> + */
> +struct device_node *of_get_pci_root_bridge_parent(struct pci_dev *dev)
> +{
> + struct pci_bus *bus = dev->bus;
> + struct device *bridge;
> +
> + while (!pci_is_root_bus(bus))
> + bus = bus->parent;
> + bridge = bus->bridge;
> +
> + return bridge->parent->of_node;
> +}
> +EXPORT_SYMBOL_GPL(of_get_pci_root_bridge_parent);
> +
> +/**
> + * of_pci_dma_configure - Setup DMA configuration
> + * @dev: ptr to pci_dev struct of the pci device
> + *
> + * Try to get PCI devices's DMA configuration from DT and update it
> + * accordingly. This is similar to of_dma_configure() in of/platform.c
> + */
> +void of_pci_dma_configure(struct pci_dev *pci_dev)
> +{
> + struct device *dev = &pci_dev->dev;
> + u64 dma_addr, paddr, size;
> + struct device_node *parent_np;
> + unsigned long offset;
> + bool coherent;
> + int ret;
> +
> + parent_np = of_get_pci_root_bridge_parent(pci_dev);
> +
> + if (parent_np) {
Save a level of indentation and do:
if (!parent_np)
return;
> + /*
> +* Set default dma-mask to 32 bit. Drivers are expected to
> setup
> +* the correct supported dma_mask.
> +*/
> + dev->coherent_dma_mask = DMA_BIT_MASK(32);
> +
> + /*
> +* Set it to coherent_dma_mask by default if the architecture
> +* code has not set it.
> +*/
> + if (!dev->dma_mask)
> + dev->dma_mask = &dev->coherent_dma_mask;
> +
> + ret = of_dma_get_range(parent_np, &dma_addr, &paddr, &size);
> + if (ret < 0) {
> + dma_addr = offset = 0;
> + size = dev->coherent_dma_mask + 1;
> + } else {
> + offset = PFN_DOWN(paddr - dma_addr);
> + dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
> + }
> + dev->dma_pfn_offset = offset;
> +
> + coherent = of_dma_is_coherent(parent_np);
> + dev_dbg(dev, "device is%sdma coherent\n",
> + coherent ? " " : " not ");
> +
> + arch_setup_dma_ops(dev, dma_addr, size, NULL, coherent);
This is the same code as of_dma_configure. The only difference I see
is which node ptr is passed to of_dma_get_range. You need to make that
a function param of of_dma_configure.
of_dma_configure also has iommu handling now. You will probably need
something similar for PCI in that you setup an iommu based on the root
bus DT properties.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] move exit_task_work() before exit_fs().
On Fri, Dec 26, 2014 at 03:45:25PM +0800, Leon Ma wrote: > We encountered following panic. The scenario is the process is exiting and > executing its > task work. When closing dev node, the driver triggers a firmware reload > according to device > status. Because task->fs is set to NULL in exit_fs(), panic happens. > Task work is a common interface, we should not limite the resource the user > will utilize. Fix your driver. Forget ->fs being NULL; what will happen if your process is chrooted? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 1/2] socket: Allow external sockets to use socket syscalls
Hello Jason,
Thanks again for your comments.
On 12/26/14 4:45 AM, Jason Wang wrote:
@@ -388,6 +388,7 @@ struct file *sock_alloc_file(struct socket *sock, int
flags, const char *dname)
sock->file = file;
file->f_flags = O_RDWR | (flags & O_NONBLOCK);
file->private_data = sock;
+ file->private_data_is_socket = true;
This is only safe if all user of sock_alloc_file() have full support for
each method in proto_ops.
This doesn't change anything in the invocation of the syscalls, as every
file allocated through this path already passes the "is_socket" test due
to the (sadly missing here)
file = alloc_file(..., &socket_file_ops)
above, so this makes things no less safe than they were.
Of course we also need to implement these proto_ops for the tun device
in the subsequent patch to make it work.
return file;
}
EXPORT_SYMBOL(sock_alloc_file);
@@ -411,7 +412,7 @@ static int sock_map_fd(struct socket *sock, int flags)
struct socket *sock_from_file(struct file *file, int *err)
{
- if (file->f_op == &socket_file_ops)
+ if (file->private_data_is_socket)
return file->private_data; /* set in sock_map_fd */
*err = -ENOTSOCK;
Not sure it's the best method, how about a dedicated f_op to do this?
So like a get_socket operation? That would simplify this a lot,
certainly (we wouldn't need to move private_data around in the tun driver).
Thanks,
--
Alex Gartrell
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Dec 26 (f2fs)
On 12/26/14 00:30, Stephen Rothwell wrote: > Hi all, > > There will only be intermittent releases of linux-next between now and > Jan 5. > > Changes since 20141221: > on x86_64: when CONFIG_F2FS_STAT_FS is not enabled: ../fs/f2fs/segment.c: In function 'rewrite_data_page': ../fs/f2fs/segment.c:1233:2: error: implicit declaration of function 'stat_inc_inplace_blocks' [-Werror=implicit-function-declaration] -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 2/2] tun: enable socket system calls
Hello Jason,
Thanks for commenting.
On 12/26/14 4:43 AM, Jason Wang wrote:
On 12/26/2014 02:50 PM, Alex Gartrell wrote:
By setting private_data to a socket and private_data_is_socket to true, we
can use the socket syscalls. We also can't just blindly use private_data
anymore, so there's a __tun_file_get function that returns the container_of
private_data appropriately.
So this in fact expose other socket syscalls to userspace. But some of
proto_ops was not supported. E.g consider what happens if a bind() was
called for tun socket?
Yeah, I erroneously assumed that NULL => sock_no_*, but a quick glance
assures me that that's not the case. In this case, I'd need to
introduce another patch that sets all of the additional ops to sock_no_*.
+static struct tun_file *tun_file_from_file(struct file *file)
+{
+ struct socket *s = (struct socket *)file->private_data;
+
+ if (!s)
Can s be NULL here? If yes, why tun_get() didn't check for NULL?
This check is just to ensure that tun_get_socket continues to work in
the right way when passed a file with private_data set to NULL.
Thanks,
--
Alex Gartrell
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Dec 26 (sst-haswell-pcm)
On 12/26/14 00:30, Stephen Rothwell wrote: > Hi all, > > There will only be intermittent releases of linux-next between now and > Jan 5. > > Changes since 20141221: > on i386: sound/built-in.o: In function `hsw_pcm_complete': sst-haswell-pcm.c:(.text+0x139a24): undefined reference to `snd_soc_resume' sound/built-in.o: In function `hsw_pcm_prepare': sst-haswell-pcm.c:(.text+0x139aeb): undefined reference to `snd_soc_suspend' Full randconfig file is attached. -- ~Randy # # Automatically generated file; DO NOT EDIT. # Linux/i386 3.19.0-rc1 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_OUTPUT_FORMAT="elf32-i386" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y # CONFIG_ZONE_DMA32 is not set # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set CONFIG_KERNEL_XZ=y # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y # CONFIG_SYSVIPC is not set # CONFIG_CROSS_MEMORY_ATTACH is not set CONFIG_FHANDLE=y CONFIG_USELIB=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # # RCU Subsystem # CONFIG_PREEMPT_RCU=y CONFIG_SRCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_RCU_BOOST=y CONFIG_RCU_KTHREAD_PRIO=1 CONFIG_RCU_BOOST_DELAY=500 CONFIG_RCU_NOCB_CPU=y # CONFIG_RCU_NOCB_CPU_NONE is not set # CONFIG_RCU_NOCB_CPU_ZERO is not set CONFIG_RCU_NOCB_CPU_ALL=y # CONFIG_BUILD_BIN2C is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y # CONFIG_CGROUP_FREEZER is not set # CONFIG_CGROUP_DEVICE is not set # CONFIG_CPUSETS is not set # CONFIG_CGROUP_CPUACCT is not set CONFIG_PAGE_COUNTER=y CONFIG_MEMCG=y # CONFIG_MEMCG_SWAP is not set # CONFIG_MEMCG_KMEM is not set CONFIG_CGROUP_PERF=y CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y CONFIG_RT_GROUP_SCHED=y # CONFIG_BLK_CGROUP is not set # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set CONFIG_USER_NS=y # CONFIG_PID_NS is not set CONFIG_SCHED_AUTOGROUP=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y # CONFIG_RD_LZMA is not set # CONFIG_RD_XZ is not set CONFIG_RD_LZO=y # CONFIG_RD_LZ4 is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y # CONFIG_LTO_MENU is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y # CONFIG_EXPERT is not set CONFIG_UID16=y CONFIG_SGETMASK_SYSCALL=y CONFIG_SYSFS_SYSCALL=y # CONFIG_SYSCTL_SYSCALL is not set
Re: [PATCHv2] media: i2c/adp1653: devicetree support for adp1653
On Wed, Dec 24, 2014 at 4:34 PM, Pavel Machek wrote:
>
> We are moving to device tree support on OMAP3, but that currently
> breaks ADP1653 driver. This adds device tree support, plus required
> documentation.
>
> Signed-off-by: Pavel Machek
>
> ---
>
> Changed -microsec to -us, as requested by devicetree people.
>
> Fixed checkpatch issues.
>
> diff --git a/Documentation/devicetree/bindings/leds/common.txt
> b/Documentation/devicetree/bindings/leds/common.txt
> index 2d88816..2c6c7c5 100644
> --- a/Documentation/devicetree/bindings/leds/common.txt
> +++ b/Documentation/devicetree/bindings/leds/common.txt
> @@ -14,6 +14,15 @@ Optional properties for child nodes:
> "ide-disk" - LED indicates disk activity
> "timer" - LED flashes at a fixed, configurable rate
>
> +- max-microamp : maximum intensity in microamperes of the LED
> +(torch LED for flash devices)
> +- flash-max-microamp : maximum intensity in microamperes of the
> + flash LED; it is mandatory if the LED should
> + support the flash mode
> +- flash-timeout-microsec : timeout in microseconds after which the flash
> + LED is turned off
Doesn't all this go in your flash led binding patch?
> +
> +
> Examples:
>
> system-status {
> @@ -21,3 +30,10 @@ system-status {
> linux,default-trigger = "heartbeat";
> ...
> };
> +
> +camera-flash {
> + label = "Flash";
> + max-microamp = <5>;
> + flash-max-microamp = <32>;
> + flash-timeout-microsec = <50>;
> +}
> diff --git a/Documentation/devicetree/bindings/media/i2c/adp1653.txt
> b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
> new file mode 100644
> index 000..3c7065f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
> @@ -0,0 +1,38 @@
> +* Analog Devices ADP1653 flash LED driver
> +
> +Required Properties:
> +
> + - compatible: Must contain one of the following
> +- "adi,adp1653"
> +
> + - reg: I2C slave address
> +
> + - gpios: References to the GPIO that controls the power for the chip.
> +
> +There are two led outputs available - flash and indicator. One led is
> +represented by one child node, nodes need to be named "flash" and
> "indicator".
> +
> +Required properties of the LED child node:
> +- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
> +
> +Required properties of the flash LED child node:
> +
> +- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
> +- flash-timeout-us : see Documentation/devicetree/bindings/leds/common.txt
> +
> +Example:
> +
> +adp1653: led-controller@30 {
> +compatible = "adi,adp1653";
> + reg = <0x30>;
> +gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
> +
> + flash {
> +flash-timeout-us = <50>;
> +flash-max-microamp = <32>;
> +max-microamp = <5>;
> + };
> +indicator {
These are different LEDs or different modes?
> +max-microamp = <17500>;
This is a bit inconsistent. The binding says this is for flash LEDs
torch mode, but I see no reason why it can't be common. Can you update
the binding doc to be clear here.
Also, aren't you missing label properties?
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: line6: pcm: Corrected checkpatch notices in pcm.h
On 12/26, Damon Swayn wrote:
> Fixed a coding style issue
You need to be more specific here, describe what kind of issue this
patch is fixing. Keep in mind that this message, when formulated
properly, will end up as a comment to the Linux kernel source - it must,
therefore, contain valuable information.
thanks,
konrad
ps: the file name does not have to be mentioned in the subject as this
information is already in the diff.
> Signed-off-by: Damon Swayn
> ---
> drivers/staging/line6/pcm.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/line6/pcm.h b/drivers/staging/line6/pcm.h
> index 6aa0d46..5d87934 100644
> --- a/drivers/staging/line6/pcm.h
> +++ b/drivers/staging/line6/pcm.h
> @@ -145,21 +145,21 @@ enum {
> LINE6_BIT_PCM_IMPULSE_PLAYBACK_BUFFER |
> #endif
> LINE6_BIT_PCM_ALSA_PLAYBACK_BUFFER |
> - LINE6_BIT_PCM_MONITOR_PLAYBACK_BUFFER ,
> + LINE6_BIT_PCM_MONITOR_PLAYBACK_BUFFER,
>
> LINE6_BITS_PLAYBACK_STREAM =
> #ifdef CONFIG_LINE6_USB_IMPULSE_RESPONSE
> LINE6_BIT_PCM_IMPULSE_PLAYBACK_STREAM |
> #endif
> LINE6_BIT_PCM_ALSA_PLAYBACK_STREAM |
> - LINE6_BIT_PCM_MONITOR_PLAYBACK_STREAM ,
> + LINE6_BIT_PCM_MONITOR_PLAYBACK_STREAM,
>
> LINE6_BITS_CAPTURE_BUFFER =
> #ifdef CONFIG_LINE6_USB_IMPULSE_RESPONSE
> LINE6_BIT_PCM_IMPULSE_CAPTURE_BUFFER |
> #endif
> LINE6_BIT_PCM_ALSA_CAPTURE_BUFFER |
> - LINE6_BIT_PCM_MONITOR_CAPTURE_BUFFER ,
> + LINE6_BIT_PCM_MONITOR_CAPTURE_BUFFER,
>
> LINE6_BITS_CAPTURE_STREAM =
> #ifdef CONFIG_LINE6_USB_IMPULSE_RESPONSE
> --
> 2.1.0
>
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: fanotify bug on gdb -- hard crash
Hello Ivo,
On 26.12.2014 15:45, ivo welch wrote:
I am not a kernel developer, so forgive the intrusion.
I suspect I have found either a bug in gdb (less likely) or a bug in
fanotify (more likely). it is replicable, and the code is almost
unchanged from the example in the fanotify man page. to trigger it,
all an su needs to do is to step through the program below with gdb
7.8.1 'n' command, and linux locks up the system pretty hard (reboot
required). I have confirmed the replicability of this issue on a
clean arch 2014.12.01 3.17.6-1 system and on a clean ubuntu 14.10
system, both VMs created just to check it. /iaw
#define _GNU_SOURCE /* Needed to get O_LARGEFILE definition */
#include
#include
#include
#include
#include
#include
int main(int argc, char *argv[]) {
int fd;
fd = fanotify_init(FAN_CLOEXEC | FAN_CLASS_CONTENT | FAN_NONBLOCK,
O_RDONLY | O_LARGEFILE);
if (fd == -1) exit(1);
fprintf(stderr, "calling fanotify_mark: fd=%d\n", fd);
if (fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_MOUNT, FAN_OPEN_PERM |
FAN_CLOSE_WRITE, -1, "/") == -1) exit(2);
fprintf(stderr, "in gdb step through with 'n' for repeat.\n");
fprintf(stderr, " (and sometimes otherwise), a ^C works, but a ^Z
and then ^C does not.\n");
}
I was not able to reproduce your problem according to your description
with Ubuntu 14.10.
I ran a Ubuntu 14.04 amd64 LiveImage in a VM and compiled your example with
gcc -g -o test test.c
The gdb version in Ubuntu 14.10 is 7.4 and not 7.8.1. The kernel version
is 3.13.
root@ubuntu:/home/ubuntu/temp# gdb ./test
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
[PATCH v2] bcma: Fix three coding style issues, more than 80 characters per line
Three lines with more than 80 characters per line have been split in several
lines.
Signed-off-by: Oscar Forner Martinez
---
drivers/bcma/driver_chipcommon.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/bcma/driver_chipcommon.c b/drivers/bcma/driver_chipcommon.c
index 19f6796..15f044d 100644
--- a/drivers/bcma/driver_chipcommon.c
+++ b/drivers/bcma/driver_chipcommon.c
@@ -79,7 +79,9 @@ static int bcma_chipco_watchdog_ticks_per_ms(struct
bcma_drv_cc *cc)
if (cc->capabilities & BCMA_CC_CAP_PMU) {
if (bus->chipinfo.id == BCMA_CHIP_ID_BCM4706)
- /* 4706 CC and PMU watchdogs are clocked at 1/4 of ALP
clock */
+ /* 4706 CC and PMU watchdogs are clocked
+* at 1/4 of ALP clock
+*/
return bcma_chipco_get_alp_clock(cc) / 4000;
else
/* based on 32KHz ILP clock */
@@ -97,7 +99,8 @@ int bcma_chipco_watchdog_register(struct bcma_drv_cc *cc)
wdt.driver_data = cc;
wdt.timer_set = bcma_chipco_watchdog_timer_set_wdt;
wdt.timer_set_ms = bcma_chipco_watchdog_timer_set_ms_wdt;
- wdt.max_timer_ms = bcma_chipco_watchdog_get_max_timer(cc) /
cc->ticks_per_ms;
+ wdt.max_timer_ms =
+ bcma_chipco_watchdog_get_max_timer(cc) / cc->ticks_per_ms;
pdev = platform_device_register_data(NULL, "bcm47xx-wdt",
cc->core->bus->num, &wdt,
@@ -335,7 +338,9 @@ void bcma_chipco_serial_init(struct bcma_drv_cc *cc)
| BCMA_CC_CORECTL_UARTCLKEN);
}
} else {
- bcma_err(cc->core->bus, "serial not supported on this device
ccrev: 0x%x\n", ccrev);
+ bcma_err(cc->core->bus,
+"serial not supported on this device ccrev: 0x%x\n",
+ccrev);
return;
}
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Fri, Dec 26, 2014 at 11:34:10AM -0500, Dave Jones wrote: > One thing I think I'll try is to try and narrow down which > syscalls are triggering those "Clocksource hpet had cycles off" > messages. I'm still unclear on exactly what is doing > the stomping on the hpet. First I ran trinity with "-g vm" which limits it to use just a subset of syscalls, specifically VM related ones. That triggered the messages. Further experiments revealed: -c mremap triggered it, but only when I also passed -C256 to crank up the number of child processes. The same thing occured with mprotect, madvise, remap_file_pages. I couldn't trigger it with -c mmap, or msync, mbind, move_pages, migrate_pages, mlock, regardless of how many child processes there were. Given the high child count necessary to trigger it, it's nigh on impossible to weed through all the calls that trinity made to figure out which one actually triggered the messages. I'm not even convinced that the syscall parameters are even particularly interesting. The "needs high load to trigger" aspect of the bug still has a smell of scheduler interaction or side effect of lock contention. Looking at one childs syscall params in isolation might look quite dull, but if we have N processes hammering on the same mapping, that's probably a lot more interesting. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Fix multiple coding style issues
Alexander, On Fri, Dec 26, 2014 at 11:09:53PM +0600, Alexander Kuleshov wrote: > Hello Jeremiah, > > Thank you for feedback. It is my first patches to kernel, so i have a > some little questions: > I recommend checking out Greg Kroah Hartman's presentation on submitting your first patch. It has lots of good tips. https://www.youtube.com/watch?v=LLBrBBImJt4 > > Jeremiah Mahler : > > Alexander, > > > > On Fri, Dec 26, 2014 at 06:38:59PM +0600, Alexander Kuleshov wrote: > > > > Your description needs to be more specific than just "coding style > > fixes". What type of problems did you fix? How did you find them? > > > > There are some lines which more than 80 chars, I found it with > scripts/checkpatch.pl. > What is the best place to put this description? In commit message > after first line? > Yes, just put that in the log message. The first line is the summary, then a blank line, then the detailed log message. The summary line is what ends up in the subject line of the email. > > Jeremiah Mahler : > > If you are looking for things to fix I suggest looking in the > > drivers/staging directory. There are lots of things that need to be > > fixed in there. > > So i must make this patch for kernel/git/gregkh/staging.git and resend > it again or just to add to this thread? > Or i'm wrong? > You figured this out in your next message :) > Thank you. Glad I could help :) -- - Jeremiah Mahler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] move exit_task_work() before exit_fs().
On 12/26, Leon Ma wrote: > > We encountered following panic. The scenario is the process is exiting and > executing its > task work. When closing dev node, the driver triggers a firmware reload > according to device > status. Because task->fs is set to NULL in exit_fs(), panic happens. I think this should be fixed somewhere else... > Task work is a common interface, we should not limite the resource the user > will utilize. Exactly. And note that with this patch exit_mm()..disassociate_ctty() paths can't use task works. Not to mention that this patch moves exit_files() up, even before exit_mm(), without any explanation. Add Al. May be we can move exit_fs() down after exit_task_work(), I dunno, but to me it would be better to change the driver. > [ 118.521972] task: 880038de5cd0 ti: 880038e86000 task.ti: > 880038e86000 > [ 118.521977] RIP: 0010:[] [] > path_init+0x336/0x440 > [ 118.521986] RSP: :880038e876a0 EFLAGS: 00010246 > [ 118.521991] RAX: RBX: 880038e87790 RCX: > 0071 > [ 118.521996] RDX: 88003f30f5d4 RSI: 82179f75 RDI: > 8209b167 > [ 118.522000] RBP: 880038e876e0 R08: 880038e87730 R09: > 8800218b44c0 > [ 118.522005] R10: R11: 000f R12: > 880038ebf000 > [ 118.522010] R13: 880038e87870 R14: 880038e87850 R15: > ff9c > [ 118.522015] FS: () GS:88003f30() > knlGS: > [ 118.522020] CS: 0010 DS: 002b ES: 002b CR0: 80050033 > [ 118.522025] CR2: 0020 CR3: 39d4f000 CR4: > 001007e0 > [ 118.522030] DR0: DR1: DR2: > > [ 118.522035] DR3: DR6: 0ff0 DR7: > 0400 > [ 118.522039] Stack: > [ 118.522043] 880038dbc300 880038e876b8 822cf046 > 88002e434f00 > [ 118.522056] 880038e87790 880038e87870 880038e87850 > ff9c > [ 118.522069] 880038e87780 8217d419 88003b1de480 > 88003bbf7700 > [ 118.522082] Call Trace: > [ 118.522092] [] ? security_file_alloc+0x16/0x20 > [ 118.522100] [] path_openat+0x69/0x4b0 > [ 118.522109] [] ? is_connected_output_ep+0x15f/0x260 > [ 118.522117] [] do_filp_open+0x39/0x90 > [ 118.522125] [] ? string.isra.3+0x3a/0xe0 > [ 118.522133] [] ? vsnprintf+0x209/0x620 > [ 118.522141] [] file_open_name+0xb2/0xf0 > [ 118.522148] [] filp_open+0x36/0x40 > [ 118.522157] [] _request_firmware+0x351/0x9c0 > [ 118.522164] [] request_firmware+0x16/0x20 > [ 118.522172] [] sst_request_fw+0x63/0x510 > [ 118.522180] [] ? __mutex_lock_slowpath+0x280/0x3b0 > [ 118.522188] [] sst_load_fw+0x1f7/0x4a0 > [ 118.522195] [] sst_download_fw+0xf/0x60 > [ 118.522202] [] intel_sst_check_device+0x92/0x1f0 > [ 118.522209] [] sst_set_generic_params+0x18d/0x500 > [ 118.522218] [] > sst_fill_and_send_cmd.constprop.7+0x95/0x130 > [ 118.56] [] sst_send_gain_cmd+0x9d/0xe0 > [ 118.522233] [] sst_set_pipe_gain+0x63/0xa0 > [ 118.522241] [] sst_send_pipe_gains+0xd5/0x2b0 > [ 118.522248] [] sst_media_digital_mute+0x46/0x80 > [ 118.522257] [] snd_soc_dai_digital_mute+0x21/0x60 > [ 118.522265] [] soc_pcm_close+0xbd/0x250 > [ 118.522272] [] dpcm_fe_dai_close+0x7a/0x150 > [ 118.522281] [] snd_pcm_release_substream+0x58/0xb0 > [ 118.522289] [] snd_pcm_release+0x3f/0xa0// > [ 118.522296] [] __fput+0xf0/0x240 > [ 118.522304] [] fput+0xe/0x10 > [ 118.522312] [] task_work_run+0xa5/0xd0 > [ 118.522320] [] do_exit+0x2b8/0xad0 > [ 118.522327] [] ? __schedule+0x3df/0x820 > [ 118.522335] [] do_group_exit+0x3f/0xa0 > [ 118.522343] [] get_signal_to_deliver+0x24e/0x650 > [ 118.522352] [] do_signal+0x4d/0x960 > [ 118.522360] [] ? hrtimer_start_range_ns+0x14/0x20 > [ 118.522368] [] ? binder_ioctl+0x15d/0x990 > [ 118.522377] [] do_notify_resume+0x65/0x80 > [ 118.522384] [] int_signal+0x12/0x17 > > Signed-off-by: Leon Ma > Signed-off-by: Zhang Di > Signed-off-by: Sun Zhonghua > --- > kernel/exit.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/kernel/exit.c b/kernel/exit.c > index 1ea4369..64ba13b 100644 > --- a/kernel/exit.c > +++ b/kernel/exit.c > @@ -729,6 +729,8 @@ void do_exit(long code) > tsk->exit_code = code; > taskstats_exit(tsk, group_dead); > > + exit_files(tsk); > + exit_task_work(tsk); > exit_mm(tsk); > > if (group_dead) > @@ -737,12 +739,10 @@ void do_exit(long code) > > exit_sem(tsk); > exit_shm(tsk); > - exit_files(tsk); > exit_fs(tsk); > if (group_dead) > disassociate_ctty(1); > exit_task_namespaces(tsk); > - exit_task_work(tsk); > exit_thread(); > > /* > -- > 1.7.9.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org Mor
[PATCH 1/2] regulator: core: Add a sanity check on the regulator_ enable/disable functions
These two functions use the pointer passed in parameter without any
check. By adding a NULL pointer check, it allows using those functions
from a driver in a more generic way. It is useful especially for the
disable case if the regulator is optional.
Signed-off-by: Gregory CLEMENT
---
drivers/regulator/core.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index e225711bb8bc..de29399b5430 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1911,12 +1911,16 @@ static int _regulator_enable(struct regulator_dev *rdev)
*/
int regulator_enable(struct regulator *regulator)
{
- struct regulator_dev *rdev = regulator->rdev;
+ struct regulator_dev *rdev;
int ret = 0;
+ if (!regulator)
+ return 0;
+
if (regulator->always_on)
return 0;
+ rdev = regulator->rdev;
if (rdev->supply) {
ret = regulator_enable(rdev->supply);
if (ret != 0)
@@ -2024,12 +2028,17 @@ static int _regulator_disable(struct regulator_dev
*rdev)
*/
int regulator_disable(struct regulator *regulator)
{
- struct regulator_dev *rdev = regulator->rdev;
+ struct regulator_dev *rdev;
int ret = 0;
+ if (!regulator)
+ return 0;
+
if (regulator->always_on)
return 0;
+ rdev = regulator->rdev;
+
mutex_lock(&rdev->mutex);
ret = _regulator_disable(rdev);
mutex_unlock(&rdev->mutex);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] regulator: core: Add the device tree version to the regulator_get family
This patch adds the device tree version (of_) for each member of the
regulator_get family: normal, exclusive, optional and all of the
manageable version.
The of_regulator_get* functions allow using a device node to get the
regulator instead using the device object. It is needed for the
regulator associated to a child node which is not a device, it is the
case of the SATA ports of an ahci controller for instance.
Signed-off-by: Gregory CLEMENT
---
drivers/regulator/core.c | 114 +
drivers/regulator/devres.c | 70 ---
include/linux/regulator/consumer.h | 20 +++
3 files changed, 187 insertions(+), 17 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index de29399b5430..74167b98797a 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -127,26 +127,37 @@ static bool have_full_constraints(void)
/**
* of_get_regulator - get a regulator device node based on supply name
+ * and on device node if provided
+ *
* @dev: Device pointer for the consumer (of regulator) device
+ * @np: Device tree node pointer on the node containing the regulator
* @supply: regulator supply name
*
* Extract the regulator device node corresponding to the supply name.
* returns the device node corresponding to the regulator if found, else
* returns NULL.
*/
-static struct device_node *of_get_regulator(struct device *dev, const char
*supply)
+static struct device_node *of_get_regulator_by_node(struct device *dev,
+ const char *supply,
+ struct device_node *np)
{
struct device_node *regnode = NULL;
char prop_name[32]; /* 32 is max size of property name */
+ struct device_node *node;
+
+ if (np)
+ node = np;
+ else
+ node = dev->of_node;
dev_dbg(dev, "Looking up %s-supply from device tree\n", supply);
snprintf(prop_name, 32, "%s-supply", supply);
- regnode = of_parse_phandle(dev->of_node, prop_name, 0);
+ regnode = of_parse_phandle(node, prop_name, 0);
if (!regnode) {
dev_dbg(dev, "Looking up %s property in node %s failed",
- prop_name, dev->of_node->full_name);
+ prop_name, node->full_name);
return NULL;
}
return regnode;
@@ -1268,6 +1279,7 @@ static void regulator_supply_alias(struct device **dev,
const char **supply)
static struct regulator_dev *regulator_dev_lookup(struct device *dev,
const char *supply,
+ struct device_node *np,
int *ret)
{
struct regulator_dev *r;
@@ -1278,8 +1290,8 @@ static struct regulator_dev *regulator_dev_lookup(struct
device *dev,
regulator_supply_alias(&dev, &supply);
/* first do a dt based lookup */
- if (dev && dev->of_node) {
- node = of_get_regulator(dev, supply);
+ if ((dev && dev->of_node) || np) {
+ node = of_get_regulator_by_node(dev, supply, np);
if (node) {
list_for_each_entry(r, ®ulator_list, list)
if (r->dev.parent &&
@@ -1322,6 +1334,7 @@ static struct regulator_dev *regulator_dev_lookup(struct
device *dev,
/* Internal regulator request function */
static struct regulator *_regulator_get(struct device *dev, const char *id,
+ struct device_node *node,
bool exclusive, bool allow_dummy)
{
struct regulator_dev *rdev;
@@ -1344,7 +1357,7 @@ static struct regulator *_regulator_get(struct device
*dev, const char *id,
mutex_lock(®ulator_list_mutex);
- rdev = regulator_dev_lookup(dev, id, &ret);
+ rdev = regulator_dev_lookup(dev, id, node, &ret);
if (rdev)
goto found;
@@ -1431,7 +1444,7 @@ out:
*/
struct regulator *regulator_get(struct device *dev, const char *id)
{
- return _regulator_get(dev, id, false, true);
+ return _regulator_get(dev, id, NULL, false, true);
}
EXPORT_SYMBOL_GPL(regulator_get);
@@ -1458,7 +1471,7 @@ EXPORT_SYMBOL_GPL(regulator_get);
*/
struct regulator *regulator_get_exclusive(struct device *dev, const char *id)
{
- return _regulator_get(dev, id, true, false);
+ return _regulator_get(dev, id, NULL, true, false);
}
EXPORT_SYMBOL_GPL(regulator_get_exclusive);
@@ -1484,10 +1497,91 @@ EXPORT_SYMBOL_GPL(regulator_get_exclusive);
*/
struct regulator *regulator_get_optional(struct device *dev, const char *id)
{
- return _regulator_get(dev, id, false, false);
+ return _regulator_get(dev, id, NULL, false, false);
}
EXPORT_SYMBOL_GPL(regulator_get_optional);
[no subject]
Subject: [PATCH 0/2] regulator: Add the device tree version to the regulator_get family Hi, Currently it is not possible to associate a regulator to a child node which is not a device. The several ports of an ahci controller are represented as subnodes but they are not created as devices. In order to be able to associate each port with a regulator the framework API needs to be extended. The second patch adds the device tree version (of_) for each member of the regulator_get family: normal, exclusive, optional and all of the manageable version.The of_regulator_get* functions allow using a device node to get the regulator instead using the device object. The first patch is not related to the second one, but it is little improvement. Gregory Gregory CLEMENT (2): regulator: core: Add a sanity check on the regulator_ enable/disable functions regulator: core: Add the device tree version to the regulator_get family drivers/regulator/core.c | 127 + drivers/regulator/devres.c | 70 ++-- include/linux/regulator/consumer.h | 20 ++ 3 files changed, 198 insertions(+), 19 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This patch provides
> a DT based driver for the temperature sensor based on an older driver
> written by Peter De Schrijver for the Nokia N900 and N9.
>
> Signed-off-by: Sebastian Reichel
> + if (!data->valid || time_after(jiffies, data->last_updated + HZ)) {
> + clk_enable(data->clk_32k);
This needs to be clk_prepare_enable()
> + regmap_update_bits(data->syscon, SYSCON_TEMP_REG,
> +soc_mask, soc_mask);
> +
> + if (!wait_for_eocz(EOCZ_MIN_RISING_DELAY,
> + EOCZ_MAX_RISING_DELAY, 1, data)) {
> + e = -EIO;
> + goto err;
> + }
> +
> + regmap_update_bits(data->syscon, SYSCON_TEMP_REG, soc_mask, 0);
> +
> + if (!wait_for_eocz(EOCZ_MIN_FALLING_DELAY,
> + EOCZ_MAX_FALLING_DELAY, 0, data)) {
> + e = -EIO;
> + goto err;
> + }
> +
> + regmap_read(data->syscon, SYSCON_TEMP_REG, &temp_sensor_reg);
> + data->temperature = temp_sensor_reg & ((1<<7) - 1);
> + data->last_updated = jiffies;
> + data->valid = true;
> +
> +err:
> + clk_disable(data->clk_32k);
And this clk_disable_unprepare().
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 REPOST] ASoC: add xtensa xtfpga I2S interface and platform
XTFPGA boards provides an audio subsystem that consists of TI CDCE706
clock synthesizer, I2S transmitter and TLV320AIC23 audio codec.
I2S transmitter has MMIO-based interface that resembles that of the
OpenCores I2S transmitter. I2S transmitter is always a master on I2S
bus. There's no specialized audio DMA, sample data are transferred to
I2S transmitter FIFO by CPU through memory-mapped queue interface.
Signed-off-by: Max Filippov
---
Changes v2->v3:
- drop .owner = THIS_MODULE from the struct platform_driver initialization;
- rebase to 3.18-rc7.
Changes v1->v2:
- fix module name in the sound/soc/xtensa/Makefile;
- split PCM data transfer code and I2S interface setup code;
- move clock enabling/disabling to runtime PM code;
- document I2S interface RATIO field;
- rewrite I2S interface LEVEL field calculation to avoid overflows;
- drop select statements from Kconfig;
- document RCU usage for tx_substream;
- clean up code running in RCU read-side critical section;
- use threaded IRQ handler instead of IRQ + tasklet;
- remove empty PCM callback handlers;
- add const to static structures where applicable;
- use platform_set_drvdata instead of dev_set_drvdata;
- drop redundant error reporting code;
- use platform_get_irq instead of platform_get_resource;
- clean up xtfpga_i2s_remove;
- add comments.
.../devicetree/bindings/sound/cdns,xtfpga-i2s.txt | 18 +
MAINTAINERS| 1 +
sound/soc/Kconfig | 1 +
sound/soc/Makefile | 1 +
sound/soc/xtensa/Kconfig | 7 +
sound/soc/xtensa/Makefile | 3 +
sound/soc/xtensa/xtfpga-i2s.c | 675 +
7 files changed, 706 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt
create mode 100644 sound/soc/xtensa/Kconfig
create mode 100644 sound/soc/xtensa/Makefile
create mode 100644 sound/soc/xtensa/xtfpga-i2s.c
diff --git a/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt
b/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt
new file mode 100644
index 000..befd125
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt
@@ -0,0 +1,18 @@
+Bindings for I2S controller built into xtfpga Xtensa bitstreams.
+
+Required properties:
+- compatible: shall be "cdns,xtfpga-i2s".
+- reg: memory region (address and length) with device registers.
+- interrupts: interrupt for the device.
+- clocks: phandle to the clk used as master clock. I2S bus clock
+ is derived from it.
+
+Examples:
+
+ i2s0: xtfpga-i2s@0d08 {
+ #sound-dai-cells = <0>;
+ compatible = "cdns,xtfpga-i2s";
+ reg = <0x0d08 0x40>;
+ interrupts = <2 1>;
+ clocks = <&cdce706 4>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index ddb9ac8..f1eb40f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10628,6 +10628,7 @@ M: Max Filippov
L: linux-xte...@linux-xtensa.org
S: Maintained
F: drivers/spi/spi-xtensa-xtfpga.c
+F: sound/soc/xtensa/xtfpga-i2s.c
YAM DRIVER FOR AX.25
M: Jean-Paul Roubelat
diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig
index 7d5d644..dcc79aa 100644
--- a/sound/soc/Kconfig
+++ b/sound/soc/Kconfig
@@ -55,6 +55,7 @@ source "sound/soc/spear/Kconfig"
source "sound/soc/tegra/Kconfig"
source "sound/soc/txx9/Kconfig"
source "sound/soc/ux500/Kconfig"
+source "sound/soc/xtensa/Kconfig"
# Supported codecs
source "sound/soc/codecs/Kconfig"
diff --git a/sound/soc/Makefile b/sound/soc/Makefile
index 865e090..5b3c8f6 100644
--- a/sound/soc/Makefile
+++ b/sound/soc/Makefile
@@ -36,3 +36,4 @@ obj-$(CONFIG_SND_SOC) += spear/
obj-$(CONFIG_SND_SOC) += tegra/
obj-$(CONFIG_SND_SOC) += txx9/
obj-$(CONFIG_SND_SOC) += ux500/
+obj-$(CONFIG_SND_SOC) += xtensa/
diff --git a/sound/soc/xtensa/Kconfig b/sound/soc/xtensa/Kconfig
new file mode 100644
index 000..c201beb
--- /dev/null
+++ b/sound/soc/xtensa/Kconfig
@@ -0,0 +1,7 @@
+config SND_SOC_XTFPGA_I2S
+ tristate "XTFPGA I2S master"
+ select REGMAP_MMIO
+ help
+ Say Y or M if you want to add support for codecs attached to the
+ I2S interface on XTFPGA daughter board. You will also need to select
+ the drivers for the rest of XTFPGA audio subsystem.
diff --git a/sound/soc/xtensa/Makefile b/sound/soc/xtensa/Makefile
new file mode 100644
index 000..15efbf9
--- /dev/null
+++ b/sound/soc/xtensa/Makefile
@@ -0,0 +1,3 @@
+snd-soc-xtfpga-i2s-objs := xtfpga-i2s.o
+
+obj-$(CONFIG_SND_SOC_XTFPGA_I2S) += snd-soc-xtfpga-i2s.o
diff --git a/sound/soc/xtensa/xtfpga-i2s.c b/sound/soc/xtensa/xtfpga-i2s.c
new file mode 100644
index 000..1cfb19e
--- /dev/null
+++ b/sound/soc/xtensa/xtfpga-i2s.c
@@ -0,0 +1,675 @@
+/*
+ * Xtfpga I2S controller driver
+ *
+ * Copyright (c) 2014 Cadence Design Systems Inc.
+ *
+ * This program is free softw
Re: [PATCH 1/3] DT Binding for omap3 temperature sensor
On Fri 2014-12-26 13:34:52, Sebastian Reichel wrote:
> OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> which can be used to determine the SoCs temperature. This provides a
> DT binding specification for the temperature monitor.
>
> Signed-off-by: Sebastian Reichel
> ---
> .../bindings/hwmon/omap3-temperature.txt | 25
> ++
> 1 file changed, 25 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
>
> diff --git a/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> new file mode 100644
> index 000..99631ad
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
> @@ -0,0 +1,25 @@
> +* OMAP3 temperature sensor
> +
> +The OMAP34xx and OMAP36xx processors contain a register in the syscon area,
> +which can be used to determine the SoCs temperature.
> +
> +Requires node properties:
> +- compatible : should contain one of
> + - "ti,omap34xx-temperature-sensor" for OMAP34xx
> + - "ti,omap36xx-temperature-sensor" for OMAP36xx
> +- syscon : Should be a phandle to system configuration node which
> + encompases the temperature register
> +- clocks : Should contain 32KHz fclk clock specifier
> +- clock-names : Should contain clock names
> + - "fck" for the 32KHz fclk clock specifier
I don't quite get it. The temperature sensor is internal on the CPU,
right? Why do we need device tree to describe it? As soon as we have
CPU that is compatible to ti,omap3430, we know everything we need to
know, no?
> +Example for omap34xx:
> +
> +/ {
> + temperature-sensor {
> + compatible = "ti,omap34xx-temperature-sensor";
> + syscon = <&omap3_scm_general>;
> + clocks = <&ts_fck>;
> + clock-names = "fck";
> + };
> +};
Or is there something that depends on the board there? Or do we want
to do it like this to be consistent with existing bindings?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 14/37] perf tools: Convert dead thread list into rbtree
On 12/25/14 7:26 PM, Namhyung Kim wrote:
diff --git a/tools/perf/util/thread.h b/tools/perf/util/thread.h
index 0b6dcd70bc8b..413f28cf689b 100644
--- a/tools/perf/util/thread.h
+++ b/tools/perf/util/thread.h
@@ -11,10 +11,8 @@
struct thread_stack;
struct thread {
- union {
- struct rb_node rb_node;
- struct list_head node;
- };
+ struct rb_node rb_node;
+ struct list_headnode;
struct map_groups *mg;
pid_t pid_; /* Not all tools update this */
pid_t tid;
@@ -22,7 +20,8 @@ struct thread {
int cpu;
charshortname[3];
boolcomm_set;
- booldead; /* if set thread has exited */
+ boolexited; /* if set thread has exited */
+ booldead; /* thread is in dead_threads list */
looks like this also changes the logic (new exited flag),
not just the dead threads storage wheel
AFAICS the 'dead' flag is not used other than thread__exited(). And
it confused me a dead thread might not be in a dead_threads tree (or
list). So I changed the name and no logical change intended.
git show 236a3bbd5cb51
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Fix multiple coding style issues
> Jeremiah Mahler : If you are looking for things to fix I suggest looking in the drivers/staging directory. There are lots of things that need to be fixed in there. Ah sorry, read it incorrectly. 2014-12-26 23:09 GMT+06:00 Alexander Kuleshov : > Hello Jeremiah, > > Thank you for feedback. It is my first patches to kernel, so i have a > some little questions: > >> Jeremiah Mahler : >> Alexander, >> >> On Fri, Dec 26, 2014 at 06:38:59PM +0600, Alexander Kuleshov wrote: >> >> Your description needs to be more specific than just "coding style >> fixes". What type of problems did you fix? How did you find them? >> > > There are some lines which more than 80 chars, I found it with > scripts/checkpatch.pl. > What is the best place to put this description? In commit message > after first line? > >> Jeremiah Mahler : >> If you are looking for things to fix I suggest looking in the >> drivers/staging directory. There are lots of things that need to be >> fixed in there. > > So i must make this patch for kernel/git/gregkh/staging.git and resend > it again or just to add to this thread? > Or i'm wrong? > > Thank you. -- _ 0xAX -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
