[PATCH v2 net-next 2/3] samples/bpf: add samples for more perf event types

[Alexei Starovoitov]

From: Teng Qin 

This commit adds test code to attach BPF to HW_CACHE and RAW type events
and updates clean-up logic to disable the perf events before closing pmu_fd.

This commit also adds test code to read SOFTWARE, HW_CACHE, RAW and dynamic
pmu events from BPF program using bpf_perf_event_read(). Refactored the
existing sample to fork individual task on each CPU, attach kprobe to
more controllable function, and more accurately check if each read on
every CPU returned with good value.

Signed-off-by: Teng Qin 
Signed-off-by: Alexei Starovoitov 
---
 samples/bpf/bpf_helpers.h  |   3 +-
 samples/bpf/trace_event_user.c |  46 ++-
 samples/bpf/tracex6_kern.c |  28 +--
 samples/bpf/tracex6_user.c | 176 -
 4 files changed, 204 insertions(+), 49 deletions(-)

diff --git a/samples/bpf/bpf_helpers.h b/samples/bpf/bpf_helpers.h
index 9a9c95f2c9fb..51e567bc70fc 100644
--- a/samples/bpf/bpf_helpers.h
+++ b/samples/bpf/bpf_helpers.h
@@ -31,7 +31,8 @@ static unsigned long long (*bpf_get_current_uid_gid)(void) =
(void *) BPF_FUNC_get_current_uid_gid;
 static int (*bpf_get_current_comm)(void *buf, int buf_size) =
(void *) BPF_FUNC_get_current_comm;
-static int (*bpf_perf_event_read)(void *map, int index) =
+static unsigned long long (*bpf_perf_event_read)(void *map,
+unsigned long long flags) =
(void *) BPF_FUNC_perf_event_read;
 static int (*bpf_clone_redirect)(void *ctx, int ifindex, int flags) =
(void *) BPF_FUNC_clone_redirect;
diff --git a/samples/bpf/trace_event_user.c b/samples/bpf/trace_event_user.c
index fa4336423da5..666761773fda 100644
--- a/samples/bpf/trace_event_user.c
+++ b/samples/bpf/trace_event_user.c
@@ -122,13 +122,14 @@ static void test_perf_event_all_cpu(struct 
perf_event_attr *attr)
 {
int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
int *pmu_fd = malloc(nr_cpus * sizeof(int));
-   int i;
+   int i, error = 0;
 
/* open perf_event on all cpus */
for (i = 0; i < nr_cpus; i++) {
pmu_fd[i] = sys_perf_event_open(attr, -1, i, -1, 0);
if (pmu_fd[i] < 0) {
printf("sys_perf_event_open failed\n");
+   error = 1;
goto all_cpu_err;
}
assert(ioctl(pmu_fd[i], PERF_EVENT_IOC_SET_BPF, prog_fd[0]) == 
0);
@@ -137,9 +138,13 @@ static void test_perf_event_all_cpu(struct perf_event_attr 
*attr)
system("dd if=/dev/zero of=/dev/null count=5000k");
print_stacks();
 all_cpu_err:
-   for (i--; i >= 0; i--)
+   for (i--; i >= 0; i--) {
+   ioctl(pmu_fd[i], PERF_EVENT_IOC_DISABLE, 0);
close(pmu_fd[i]);
+   }
free(pmu_fd);
+   if (error)
+   int_exit(0);
 }
 
 static void test_perf_event_task(struct perf_event_attr *attr)
@@ -150,7 +155,7 @@ static void test_perf_event_task(struct perf_event_attr 
*attr)
pmu_fd = sys_perf_event_open(attr, 0, -1, -1, 0);
if (pmu_fd < 0) {
printf("sys_perf_event_open failed\n");
-   return;
+   int_exit(0);
}
assert(ioctl(pmu_fd, PERF_EVENT_IOC_SET_BPF, prog_fd[0]) == 0);
assert(ioctl(pmu_fd, PERF_EVENT_IOC_ENABLE, 0) == 0);
@@ -175,11 +180,45 @@ static void test_bpf_perf_event(void)
.config = PERF_COUNT_SW_CPU_CLOCK,
.inherit = 1,
};
+   struct perf_event_attr attr_hw_cache_l1d = {
+   .sample_freq = SAMPLE_FREQ,
+   .freq = 1,
+   .type = PERF_TYPE_HW_CACHE,
+   .config =
+   PERF_COUNT_HW_CACHE_L1D |
+   (PERF_COUNT_HW_CACHE_OP_READ << 8) |
+   (PERF_COUNT_HW_CACHE_RESULT_ACCESS << 16),
+   .inherit = 1,
+   };
+   struct perf_event_attr attr_hw_cache_branch_miss = {
+   .sample_freq = SAMPLE_FREQ,
+   .freq = 1,
+   .type = PERF_TYPE_HW_CACHE,
+   .config =
+   PERF_COUNT_HW_CACHE_BPU |
+   (PERF_COUNT_HW_CACHE_OP_READ << 8) |
+   (PERF_COUNT_HW_CACHE_RESULT_MISS << 16),
+   .inherit = 1,
+   };
+   struct perf_event_attr attr_type_raw = {
+   .sample_freq = SAMPLE_FREQ,
+   .freq = 1,
+   .type = PERF_TYPE_RAW,
+   /* Intel Instruction Retired */
+   .config = 0xc0,
+   .inherit = 1,
+   };
 
test_perf_event_all_cpu(_type_hw);
test_perf_event_task(_type_hw);
test_perf_event_all_cpu(_type_sw);
test_perf_event_task(_type_sw);
+   test_perf_event_all_cpu(_hw_cache_l1d);
+   test_perf_event_task(_hw_cache_l1d);
+   test_perf_event_all_cpu(_hw_cache_branch_miss);
+ 

[PATCH v2 net-next 2/3] samples/bpf: add samples for more perf event types

[Alexei Starovoitov]

From: Teng Qin 

This commit adds test code to attach BPF to HW_CACHE and RAW type events
and updates clean-up logic to disable the perf events before closing pmu_fd.

This commit also adds test code to read SOFTWARE, HW_CACHE, RAW and dynamic
pmu events from BPF program using bpf_perf_event_read(). Refactored the
existing sample to fork individual task on each CPU, attach kprobe to
more controllable function, and more accurately check if each read on
every CPU returned with good value.

Signed-off-by: Teng Qin 
Signed-off-by: Alexei Starovoitov 
---
 samples/bpf/bpf_helpers.h  |   3 +-
 samples/bpf/trace_event_user.c |  46 ++-
 samples/bpf/tracex6_kern.c |  28 +--
 samples/bpf/tracex6_user.c | 176 -
 4 files changed, 204 insertions(+), 49 deletions(-)

diff --git a/samples/bpf/bpf_helpers.h b/samples/bpf/bpf_helpers.h
index 9a9c95f2c9fb..51e567bc70fc 100644
--- a/samples/bpf/bpf_helpers.h
+++ b/samples/bpf/bpf_helpers.h
@@ -31,7 +31,8 @@ static unsigned long long (*bpf_get_current_uid_gid)(void) =
(void *) BPF_FUNC_get_current_uid_gid;
 static int (*bpf_get_current_comm)(void *buf, int buf_size) =
(void *) BPF_FUNC_get_current_comm;
-static int (*bpf_perf_event_read)(void *map, int index) =
+static unsigned long long (*bpf_perf_event_read)(void *map,
+unsigned long long flags) =
(void *) BPF_FUNC_perf_event_read;
 static int (*bpf_clone_redirect)(void *ctx, int ifindex, int flags) =
(void *) BPF_FUNC_clone_redirect;
diff --git a/samples/bpf/trace_event_user.c b/samples/bpf/trace_event_user.c
index fa4336423da5..666761773fda 100644
--- a/samples/bpf/trace_event_user.c
+++ b/samples/bpf/trace_event_user.c
@@ -122,13 +122,14 @@ static void test_perf_event_all_cpu(struct 
perf_event_attr *attr)
 {
int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
int *pmu_fd = malloc(nr_cpus * sizeof(int));
-   int i;
+   int i, error = 0;
 
/* open perf_event on all cpus */
for (i = 0; i < nr_cpus; i++) {
pmu_fd[i] = sys_perf_event_open(attr, -1, i, -1, 0);
if (pmu_fd[i] < 0) {
printf("sys_perf_event_open failed\n");
+   error = 1;
goto all_cpu_err;
}
assert(ioctl(pmu_fd[i], PERF_EVENT_IOC_SET_BPF, prog_fd[0]) == 
0);
@@ -137,9 +138,13 @@ static void test_perf_event_all_cpu(struct perf_event_attr 
*attr)
system("dd if=/dev/zero of=/dev/null count=5000k");
print_stacks();
 all_cpu_err:
-   for (i--; i >= 0; i--)
+   for (i--; i >= 0; i--) {
+   ioctl(pmu_fd[i], PERF_EVENT_IOC_DISABLE, 0);
close(pmu_fd[i]);
+   }
free(pmu_fd);
+   if (error)
+   int_exit(0);
 }
 
 static void test_perf_event_task(struct perf_event_attr *attr)
@@ -150,7 +155,7 @@ static void test_perf_event_task(struct perf_event_attr 
*attr)
pmu_fd = sys_perf_event_open(attr, 0, -1, -1, 0);
if (pmu_fd < 0) {
printf("sys_perf_event_open failed\n");
-   return;
+   int_exit(0);
}
assert(ioctl(pmu_fd, PERF_EVENT_IOC_SET_BPF, prog_fd[0]) == 0);
assert(ioctl(pmu_fd, PERF_EVENT_IOC_ENABLE, 0) == 0);
@@ -175,11 +180,45 @@ static void test_bpf_perf_event(void)
.config = PERF_COUNT_SW_CPU_CLOCK,
.inherit = 1,
};
+   struct perf_event_attr attr_hw_cache_l1d = {
+   .sample_freq = SAMPLE_FREQ,
+   .freq = 1,
+   .type = PERF_TYPE_HW_CACHE,
+   .config =
+   PERF_COUNT_HW_CACHE_L1D |
+   (PERF_COUNT_HW_CACHE_OP_READ << 8) |
+   (PERF_COUNT_HW_CACHE_RESULT_ACCESS << 16),
+   .inherit = 1,
+   };
+   struct perf_event_attr attr_hw_cache_branch_miss = {
+   .sample_freq = SAMPLE_FREQ,
+   .freq = 1,
+   .type = PERF_TYPE_HW_CACHE,
+   .config =
+   PERF_COUNT_HW_CACHE_BPU |
+   (PERF_COUNT_HW_CACHE_OP_READ << 8) |
+   (PERF_COUNT_HW_CACHE_RESULT_MISS << 16),
+   .inherit = 1,
+   };
+   struct perf_event_attr attr_type_raw = {
+   .sample_freq = SAMPLE_FREQ,
+   .freq = 1,
+   .type = PERF_TYPE_RAW,
+   /* Intel Instruction Retired */
+   .config = 0xc0,
+   .inherit = 1,
+   };
 
test_perf_event_all_cpu(_type_hw);
test_perf_event_task(_type_hw);
test_perf_event_all_cpu(_type_sw);
test_perf_event_task(_type_sw);
+   test_perf_event_all_cpu(_hw_cache_l1d);
+   test_perf_event_task(_hw_cache_l1d);
+   test_perf_event_all_cpu(_hw_cache_branch_miss);
+   test_perf_event_task(_hw_cache_branch_miss);
+ 

[PATCH v2 net-next 0/3] bpf: Add BPF support to all perf_event

[Alexei Starovoitov]

v1->v2: address Peter's feedback. Refactor patch 1 to allow attaching
bpf programs to all event types and reading counters from all of them as well
patch 2 - more tests
patch 3 - address Dave's feedback and document bpf_perf_event_read()
and bpf_perf_event_output() properly

Teng Qin (3):
  perf, bpf: Add BPF support to all perf_event types
  samples/bpf: add samples for more perf event types
  bpf: update perf event helper functions documentation

 include/uapi/linux/bpf.h   |  11 ++-
 kernel/bpf/arraymap.c  |  26 +++---
 kernel/events/core.c   |   6 +-
 kernel/trace/bpf_trace.c   |   4 +-
 samples/bpf/bpf_helpers.h  |   3 +-
 samples/bpf/trace_event_user.c |  46 ++-
 samples/bpf/tracex6_kern.c |  28 +--
 samples/bpf/tracex6_user.c | 176 -
 tools/include/uapi/linux/bpf.h |  11 ++-
 9 files changed, 232 insertions(+), 79 deletions(-)

-- 
2.9.3

[PATCH v2 net-next 0/3] bpf: Add BPF support to all perf_event

[Alexei Starovoitov]

v1->v2: address Peter's feedback. Refactor patch 1 to allow attaching
bpf programs to all event types and reading counters from all of them as well
patch 2 - more tests
patch 3 - address Dave's feedback and document bpf_perf_event_read()
and bpf_perf_event_output() properly

Teng Qin (3):
  perf, bpf: Add BPF support to all perf_event types
  samples/bpf: add samples for more perf event types
  bpf: update perf event helper functions documentation

 include/uapi/linux/bpf.h   |  11 ++-
 kernel/bpf/arraymap.c  |  26 +++---
 kernel/events/core.c   |   6 +-
 kernel/trace/bpf_trace.c   |   4 +-
 samples/bpf/bpf_helpers.h  |   3 +-
 samples/bpf/trace_event_user.c |  46 ++-
 samples/bpf/tracex6_kern.c |  28 +--
 samples/bpf/tracex6_user.c | 176 -
 tools/include/uapi/linux/bpf.h |  11 ++-
 9 files changed, 232 insertions(+), 79 deletions(-)

-- 
2.9.3

[PATCH v2 net-next 1/3] perf, bpf: Add BPF support to all perf_event types

[Alexei Starovoitov]

From: Teng Qin 

Allow BPF program to attach to all perf_event types supported
by the current bpf and perf code logic, including HW_CACHE, RAW,
and dynamic pmu events.

Also add support for reading these event counters using
bpf_perf_event_read() helper.

Signed-off-by: Teng Qin 
Signed-off-by: Alexei Starovoitov 
---
 kernel/bpf/arraymap.c| 26 +++---
 kernel/events/core.c |  6 +-
 kernel/trace/bpf_trace.c |  4 ++--
 3 files changed, 14 insertions(+), 22 deletions(-)

diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index 5e00b2333c26..55ffa9949128 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -462,26 +462,22 @@ static void *perf_event_fd_array_get_ptr(struct bpf_map 
*map,
 
event = perf_file->private_data;
ee = ERR_PTR(-EINVAL);
+   /* Per-task events are not supported */
+   if (event->attach_state & PERF_ATTACH_TASK)
+   goto err_out;
 
attr = perf_event_attrs(event);
if (IS_ERR(attr) || attr->inherit)
goto err_out;
+   /* TRACEPOINT and BREAKPOINT not supported in perf_event_read_local */
+   if (attr->type == PERF_TYPE_TRACEPOINT ||
+   attr->type == PERF_TYPE_BREAKPOINT)
+   goto err_out;
 
-   switch (attr->type) {
-   case PERF_TYPE_SOFTWARE:
-   if (attr->config != PERF_COUNT_SW_BPF_OUTPUT)
-   goto err_out;
-   /* fall-through */
-   case PERF_TYPE_RAW:
-   case PERF_TYPE_HARDWARE:
-   ee = bpf_event_entry_gen(perf_file, map_file);
-   if (ee)
-   return ee;
-   ee = ERR_PTR(-ENOMEM);
-   /* fall-through */
-   default:
-   break;
-   }
+   ee = bpf_event_entry_gen(perf_file, map_file);
+   if (ee)
+   return ee;
+   ee = ERR_PTR(-ENOMEM);
 
 err_out:
fput(perf_file);
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 6e75a5c9412d..52f667046599 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -8037,12 +8037,8 @@ static int perf_event_set_bpf_prog(struct perf_event 
*event, u32 prog_fd)
bool is_kprobe, is_tracepoint;
struct bpf_prog *prog;
 
-   if (event->attr.type == PERF_TYPE_HARDWARE ||
-   event->attr.type == PERF_TYPE_SOFTWARE)
-   return perf_event_set_bpf_handler(event, prog_fd);
-
if (event->attr.type != PERF_TYPE_TRACEPOINT)
-   return -EINVAL;
+   return perf_event_set_bpf_handler(event, prog_fd);
 
if (event->tp_event->prog)
return -EEXIST;
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 460a031c77e5..8425bf193f39 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -248,8 +248,8 @@ BPF_CALL_2(bpf_perf_event_read, struct bpf_map *, map, u64, 
flags)
return -ENOENT;
 
event = ee->event;
-   if (unlikely(event->attr.type != PERF_TYPE_HARDWARE &&
-event->attr.type != PERF_TYPE_RAW))
+   if (unlikely(event->attr.type == PERF_TYPE_SOFTWARE &&
+event->attr.config == PERF_COUNT_SW_BPF_OUTPUT))
return -EINVAL;
 
/* make sure event is local and doesn't have pmu::count */
-- 
2.9.3

[PATCH v2 net-next 3/3] bpf: update perf event helper functions documentation

[Alexei Starovoitov]

From: Teng Qin 

This commit updates documentation of the bpf_perf_event_output and
bpf_perf_event_read helpers to match their implementation.

Signed-off-by: Teng Qin 
Signed-off-by: Alexei Starovoitov 
---
 include/uapi/linux/bpf.h   | 11 +++
 tools/include/uapi/linux/bpf.h | 11 +++
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 94dfa9def355..e78aece03628 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -313,8 +313,11 @@ union bpf_attr {
  * @flags: room for future extensions
  * Return: 0 on success or negative error
  *
- * u64 bpf_perf_event_read(, index)
- * Return: Number events read or error code
+ * u64 bpf_perf_event_read(map, flags)
+ * read perf event counter value
+ * @map: pointer to perf_event_array map
+ * @flags: index of event in the map or bitmask flags
+ * Return: value of perf event counter read or error code
  *
  * int bpf_redirect(ifindex, flags)
  * redirect to another netdev
@@ -328,11 +331,11 @@ union bpf_attr {
  * @skb: pointer to skb
  * Return: realm if != 0
  *
- * int bpf_perf_event_output(ctx, map, index, data, size)
+ * int bpf_perf_event_output(ctx, map, flags, data, size)
  * output perf raw sample
  * @ctx: struct pt_regs*
  * @map: pointer to perf_event_array map
- * @index: index of event in the map
+ * @flags: index of event in the map or bitmask flags
  * @data: data on stack to be output as raw data
  * @size: size of data
  * Return: 0 on success or negative error
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 94dfa9def355..e78aece03628 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -313,8 +313,11 @@ union bpf_attr {
  * @flags: room for future extensions
  * Return: 0 on success or negative error
  *
- * u64 bpf_perf_event_read(, index)
- * Return: Number events read or error code
+ * u64 bpf_perf_event_read(map, flags)
+ * read perf event counter value
+ * @map: pointer to perf_event_array map
+ * @flags: index of event in the map or bitmask flags
+ * Return: value of perf event counter read or error code
  *
  * int bpf_redirect(ifindex, flags)
  * redirect to another netdev
@@ -328,11 +331,11 @@ union bpf_attr {
  * @skb: pointer to skb
  * Return: realm if != 0
  *
- * int bpf_perf_event_output(ctx, map, index, data, size)
+ * int bpf_perf_event_output(ctx, map, flags, data, size)
  * output perf raw sample
  * @ctx: struct pt_regs*
  * @map: pointer to perf_event_array map
- * @index: index of event in the map
+ * @flags: index of event in the map or bitmask flags
  * @data: data on stack to be output as raw data
  * @size: size of data
  * Return: 0 on success or negative error
-- 
2.9.3

[PATCH v2 net-next 1/3] perf, bpf: Add BPF support to all perf_event types

[Alexei Starovoitov]

From: Teng Qin 

Allow BPF program to attach to all perf_event types supported
by the current bpf and perf code logic, including HW_CACHE, RAW,
and dynamic pmu events.

Also add support for reading these event counters using
bpf_perf_event_read() helper.

Signed-off-by: Teng Qin 
Signed-off-by: Alexei Starovoitov 
---
 kernel/bpf/arraymap.c| 26 +++---
 kernel/events/core.c |  6 +-
 kernel/trace/bpf_trace.c |  4 ++--
 3 files changed, 14 insertions(+), 22 deletions(-)

diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index 5e00b2333c26..55ffa9949128 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -462,26 +462,22 @@ static void *perf_event_fd_array_get_ptr(struct bpf_map 
*map,
 
event = perf_file->private_data;
ee = ERR_PTR(-EINVAL);
+   /* Per-task events are not supported */
+   if (event->attach_state & PERF_ATTACH_TASK)
+   goto err_out;
 
attr = perf_event_attrs(event);
if (IS_ERR(attr) || attr->inherit)
goto err_out;
+   /* TRACEPOINT and BREAKPOINT not supported in perf_event_read_local */
+   if (attr->type == PERF_TYPE_TRACEPOINT ||
+   attr->type == PERF_TYPE_BREAKPOINT)
+   goto err_out;
 
-   switch (attr->type) {
-   case PERF_TYPE_SOFTWARE:
-   if (attr->config != PERF_COUNT_SW_BPF_OUTPUT)
-   goto err_out;
-   /* fall-through */
-   case PERF_TYPE_RAW:
-   case PERF_TYPE_HARDWARE:
-   ee = bpf_event_entry_gen(perf_file, map_file);
-   if (ee)
-   return ee;
-   ee = ERR_PTR(-ENOMEM);
-   /* fall-through */
-   default:
-   break;
-   }
+   ee = bpf_event_entry_gen(perf_file, map_file);
+   if (ee)
+   return ee;
+   ee = ERR_PTR(-ENOMEM);
 
 err_out:
fput(perf_file);
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 6e75a5c9412d..52f667046599 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -8037,12 +8037,8 @@ static int perf_event_set_bpf_prog(struct perf_event 
*event, u32 prog_fd)
bool is_kprobe, is_tracepoint;
struct bpf_prog *prog;
 
-   if (event->attr.type == PERF_TYPE_HARDWARE ||
-   event->attr.type == PERF_TYPE_SOFTWARE)
-   return perf_event_set_bpf_handler(event, prog_fd);
-
if (event->attr.type != PERF_TYPE_TRACEPOINT)
-   return -EINVAL;
+   return perf_event_set_bpf_handler(event, prog_fd);
 
if (event->tp_event->prog)
return -EEXIST;
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 460a031c77e5..8425bf193f39 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -248,8 +248,8 @@ BPF_CALL_2(bpf_perf_event_read, struct bpf_map *, map, u64, 
flags)
return -ENOENT;
 
event = ee->event;
-   if (unlikely(event->attr.type != PERF_TYPE_HARDWARE &&
-event->attr.type != PERF_TYPE_RAW))
+   if (unlikely(event->attr.type == PERF_TYPE_SOFTWARE &&
+event->attr.config == PERF_COUNT_SW_BPF_OUTPUT))
return -EINVAL;
 
/* make sure event is local and doesn't have pmu::count */
-- 
2.9.3

[PATCH v2 net-next 3/3] bpf: update perf event helper functions documentation

[Alexei Starovoitov]

From: Teng Qin 

This commit updates documentation of the bpf_perf_event_output and
bpf_perf_event_read helpers to match their implementation.

Signed-off-by: Teng Qin 
Signed-off-by: Alexei Starovoitov 
---
 include/uapi/linux/bpf.h   | 11 +++
 tools/include/uapi/linux/bpf.h | 11 +++
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 94dfa9def355..e78aece03628 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -313,8 +313,11 @@ union bpf_attr {
  * @flags: room for future extensions
  * Return: 0 on success or negative error
  *
- * u64 bpf_perf_event_read(, index)
- * Return: Number events read or error code
+ * u64 bpf_perf_event_read(map, flags)
+ * read perf event counter value
+ * @map: pointer to perf_event_array map
+ * @flags: index of event in the map or bitmask flags
+ * Return: value of perf event counter read or error code
  *
  * int bpf_redirect(ifindex, flags)
  * redirect to another netdev
@@ -328,11 +331,11 @@ union bpf_attr {
  * @skb: pointer to skb
  * Return: realm if != 0
  *
- * int bpf_perf_event_output(ctx, map, index, data, size)
+ * int bpf_perf_event_output(ctx, map, flags, data, size)
  * output perf raw sample
  * @ctx: struct pt_regs*
  * @map: pointer to perf_event_array map
- * @index: index of event in the map
+ * @flags: index of event in the map or bitmask flags
  * @data: data on stack to be output as raw data
  * @size: size of data
  * Return: 0 on success or negative error
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 94dfa9def355..e78aece03628 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -313,8 +313,11 @@ union bpf_attr {
  * @flags: room for future extensions
  * Return: 0 on success or negative error
  *
- * u64 bpf_perf_event_read(, index)
- * Return: Number events read or error code
+ * u64 bpf_perf_event_read(map, flags)
+ * read perf event counter value
+ * @map: pointer to perf_event_array map
+ * @flags: index of event in the map or bitmask flags
+ * Return: value of perf event counter read or error code
  *
  * int bpf_redirect(ifindex, flags)
  * redirect to another netdev
@@ -328,11 +331,11 @@ union bpf_attr {
  * @skb: pointer to skb
  * Return: realm if != 0
  *
- * int bpf_perf_event_output(ctx, map, index, data, size)
+ * int bpf_perf_event_output(ctx, map, flags, data, size)
  * output perf raw sample
  * @ctx: struct pt_regs*
  * @map: pointer to perf_event_array map
- * @index: index of event in the map
+ * @flags: index of event in the map or bitmask flags
  * @data: data on stack to be output as raw data
  * @size: size of data
  * Return: 0 on success or negative error
-- 
2.9.3

Re: [PATCH net-next v3 5/5] net-next: dsa: add dsa support for Mediatek MT7530 switch

[Florian Fainelli]

On May 24, 2017 4:17:39 AM PDT, "Andrey Jr. Melnikov"  
wrote:
>In gmane.linux.kernel sean.w...@mediatek.com wrote:
>> From: Sean Wang 
>
>> MT7530 is a 7-ports Gigabit Ethernet Switch that could be found on
>> Mediatek router platforms such as MT7623A or MT7623N platform which
>> includes 7-port Gigabit Ethernet MAC and 5-port Gigabit Ethernet PHY.
>> Among these ports, The port from 0 to 4 are the user ports connecting
>> with the remote devices while the port 5 and 6 are the CPU ports
>> connecting into Mediatek Ethernet GMAC.
>
>> For port 6, it can communicate with the CPU via Mediatek Ethernet
>GMAC
>> through either the TRGMII or RGMII which could be controlled by
>phy-mode
>> in the dt-bindings to specify which mode is preferred to use. And for
>> port 5, only RGMII can be specified. However, currently, only port 6
>is
>> being supported in this DSA driver.
>
>> The driver is made with the reference to qca8k and other existing DSA
>> driver. The most of the essential callbacks of the DSA are already
>> support in the driver, including tag insert for user port
>distinguishing,
>> port control, bridge offloading, STP setup and ethtool operation to
>allow
>> DSA to model each user port into a standalone netdevice as the other
>DSA
>> driver had done.
>
>What about JUMBO frames and large MTU support? devlink support?

We don't have a ndo_change_mtu callback implemented for DSA network devices but 
that is probably how we should do it. Regarding devlink, Andrew added basic 
support for it but unlike mlxsw it is currently of mild interest. Do you have 
something specific in mind with devlink?

-- 
Florian

Re: [PATCH net-next v3 5/5] net-next: dsa: add dsa support for Mediatek MT7530 switch

[Florian Fainelli]

On May 24, 2017 4:17:39 AM PDT, "Andrey Jr. Melnikov"  
wrote:
>In gmane.linux.kernel sean.w...@mediatek.com wrote:
>> From: Sean Wang 
>
>> MT7530 is a 7-ports Gigabit Ethernet Switch that could be found on
>> Mediatek router platforms such as MT7623A or MT7623N platform which
>> includes 7-port Gigabit Ethernet MAC and 5-port Gigabit Ethernet PHY.
>> Among these ports, The port from 0 to 4 are the user ports connecting
>> with the remote devices while the port 5 and 6 are the CPU ports
>> connecting into Mediatek Ethernet GMAC.
>
>> For port 6, it can communicate with the CPU via Mediatek Ethernet
>GMAC
>> through either the TRGMII or RGMII which could be controlled by
>phy-mode
>> in the dt-bindings to specify which mode is preferred to use. And for
>> port 5, only RGMII can be specified. However, currently, only port 6
>is
>> being supported in this DSA driver.
>
>> The driver is made with the reference to qca8k and other existing DSA
>> driver. The most of the essential callbacks of the DSA are already
>> support in the driver, including tag insert for user port
>distinguishing,
>> port control, bridge offloading, STP setup and ethtool operation to
>allow
>> DSA to model each user port into a standalone netdevice as the other
>DSA
>> driver had done.
>
>What about JUMBO frames and large MTU support? devlink support?

We don't have a ndo_change_mtu callback implemented for DSA network devices but 
that is probably how we should do it. Regarding devlink, Andrew added basic 
support for it but unlike mlxsw it is currently of mild interest. Do you have 
something specific in mind with devlink?

-- 
Florian

[PATCH] ARM: dts: rockchip:add sd card support

[Eddie Cai]

firefly reload board not support sd card yet. so support it.

Signed-off-by: Eddie Cai 
---
 arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi 
b/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
index 413b61f..2f41209 100644
--- a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
@@ -57,6 +57,17 @@
clock-output-names = "ext_gmac";
};
 
+   vcc_sd: sdmmc-regulator {
+   compatible = "regulator-fixed";
+   gpio = < RK_PB3 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pwr>;
+   regulator-name = "vcc_sd";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   startup-delay-us = <10>;
+   vin-supply = <_io>;
+   };
 
vcc_flash: flash-regulator {
compatible = "regulator-fixed";
@@ -281,6 +292,26 @@
rockchip,pins = <4 8 RK_FUNC_GPIO _output_high>;
};
};
+
+   sdmmc {
+   sdmmc_pwr: sdmmc-pwr {
+   rockchip,pins = <7 11 RK_FUNC_GPIO _pull_none>;
+   };
+   };
+};
+
+ {
+   bus-width = <4>;
+   cap-mmc-highspeed;
+   cap-sd-highspeed;
+   card-detect-delay = <200>;
+   disable-wp;
+   num-slots = <1>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_clk>, <_cmd>, <_cd>, <_bus4>;
+   vmmc-supply = <_sd>;
+   vqmmc-supply = <_sd>;
+   status = "okay";
 };
 
  {
-- 
1.9.1

[PATCH] ARM: dts: rockchip:add sd card support

[Eddie Cai]

firefly reload board not support sd card yet. so support it.

Signed-off-by: Eddie Cai 
---
 arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi 
b/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
index 413b61f..2f41209 100644
--- a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
@@ -57,6 +57,17 @@
clock-output-names = "ext_gmac";
};
 
+   vcc_sd: sdmmc-regulator {
+   compatible = "regulator-fixed";
+   gpio = < RK_PB3 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pwr>;
+   regulator-name = "vcc_sd";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   startup-delay-us = <10>;
+   vin-supply = <_io>;
+   };
 
vcc_flash: flash-regulator {
compatible = "regulator-fixed";
@@ -281,6 +292,26 @@
rockchip,pins = <4 8 RK_FUNC_GPIO _output_high>;
};
};
+
+   sdmmc {
+   sdmmc_pwr: sdmmc-pwr {
+   rockchip,pins = <7 11 RK_FUNC_GPIO _pull_none>;
+   };
+   };
+};
+
+ {
+   bus-width = <4>;
+   cap-mmc-highspeed;
+   cap-sd-highspeed;
+   card-detect-delay = <200>;
+   disable-wp;
+   num-slots = <1>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_clk>, <_cmd>, <_cd>, <_bus4>;
+   vmmc-supply = <_sd>;
+   vqmmc-supply = <_sd>;
+   status = "okay";
 };
 
  {
-- 
1.9.1

Re: [PATCH] drm/rockchip: Don't allow zero sized gem buffer

[Christoph Hellwig]

On Fri, May 26, 2017 at 10:30:09AM +0800, jeffy wrote:
> Hi sean,
> 
> On 05/25/2017 11:30 PM, Sean Paul wrote:
> > On Tue, May 23, 2017 at 02:39:43PM +0800, Jeffy Chen wrote:
> > > The system would crash when trying to alloc zero sized gem buffer:
> > > [6.712435] Unable to handle kernel NULL pointer dereference at 
> > > virtual address 0010 <--ZERO_SIZE_PTR
> > > ...
> > > [6.757502] PC is at sg_alloc_table_from_pages+0x170/0x1ec
> > 
> > It's unfortunate that you didn't include the entire stack trace. From code
> > inspection, it seems like the 0 size comes from the fb_probe path? Is there
> > somewhere in the helpers that you could check the mode is sane so all 
> > drivers
> > can benefit?
> 
> hmm, sorry, i was testing it on chromeos 4.4 kernel, it turns out that we
> have a custom ioctl for userspace to create gem buffer(the same as exynos
> drm), which might get the the 0 size.
> 
> but on upstream kernel, it could only be called by dump_create, and the
> drm_mode_create_dumb_ioctl already did the size check.
> 
> will resent this patch, and rewrite the commit message, thanx.

That suggests that this patch isn't needed at all.

Re: [PATCH] drm/rockchip: Don't allow zero sized gem buffer

[Christoph Hellwig]

On Fri, May 26, 2017 at 10:30:09AM +0800, jeffy wrote:
> Hi sean,
> 
> On 05/25/2017 11:30 PM, Sean Paul wrote:
> > On Tue, May 23, 2017 at 02:39:43PM +0800, Jeffy Chen wrote:
> > > The system would crash when trying to alloc zero sized gem buffer:
> > > [6.712435] Unable to handle kernel NULL pointer dereference at 
> > > virtual address 0010 <--ZERO_SIZE_PTR
> > > ...
> > > [6.757502] PC is at sg_alloc_table_from_pages+0x170/0x1ec
> > 
> > It's unfortunate that you didn't include the entire stack trace. From code
> > inspection, it seems like the 0 size comes from the fb_probe path? Is there
> > somewhere in the helpers that you could check the mode is sane so all 
> > drivers
> > can benefit?
> 
> hmm, sorry, i was testing it on chromeos 4.4 kernel, it turns out that we
> have a custom ioctl for userspace to create gem buffer(the same as exynos
> drm), which might get the the 0 size.
> 
> but on upstream kernel, it could only be called by dump_create, and the
> drm_mode_create_dumb_ioctl already did the size check.
> 
> will resent this patch, and rewrite the commit message, thanx.

That suggests that this patch isn't needed at all.

Re: [PATCH v2] PCI/msi: fix the pci_alloc_irq_vectors_affinity stub

[Christoph Hellwig]

Bjorn,

can you take this regression fix and sent it to Linux before -rc3?
I had hope we could get it into -rc2 but already missed that, and
I haven't heard a comment since..

On Sat, May 20, 2017 at 06:59:54PM +0200, Christoph Hellwig wrote:
> We need to return an error for any call that asks for MSI / MSI-X
> vectors only, so that non-trivial fallback logic can work properly.
> 
> Also valid dev->irq and use the "correct" errno value based on feedback
> from Linus.
> 
> Signed-off-by: Christoph Hellwig 
> Reported-by: Steven Rostedt 
> Fixes: aff17164 ("PCI: Provide sensible IRQ vector alloc/free routines")
> ---
> 
> Changes from V1:
>  - use == comparism
>  - return -ENOSPC
>  - verify dev->irq
> 
>  include/linux/pci.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 33c2b0b77429..fc2e832d7b9c 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1342,9 +1342,9 @@ pci_alloc_irq_vectors_affinity(struct pci_dev *dev, 
> unsigned int min_vecs,
>  unsigned int max_vecs, unsigned int flags,
>  const struct irq_affinity *aff_desc)
>  {
> - if (min_vecs > 1)
> - return -EINVAL;
> - return 1;
> + if ((flags & PCI_IRQ_LEGACY) && min_vecs == 1 && dev->irq)
> + return 1;
> + return -ENOSPC;
>  }
>  
>  static inline void pci_free_irq_vectors(struct pci_dev *dev)
> -- 
> 2.11.0
---end quoted text---

Re: [PATCH v2] PCI/msi: fix the pci_alloc_irq_vectors_affinity stub

[Christoph Hellwig]

Bjorn,

can you take this regression fix and sent it to Linux before -rc3?
I had hope we could get it into -rc2 but already missed that, and
I haven't heard a comment since..

On Sat, May 20, 2017 at 06:59:54PM +0200, Christoph Hellwig wrote:
> We need to return an error for any call that asks for MSI / MSI-X
> vectors only, so that non-trivial fallback logic can work properly.
> 
> Also valid dev->irq and use the "correct" errno value based on feedback
> from Linus.
> 
> Signed-off-by: Christoph Hellwig 
> Reported-by: Steven Rostedt 
> Fixes: aff17164 ("PCI: Provide sensible IRQ vector alloc/free routines")
> ---
> 
> Changes from V1:
>  - use == comparism
>  - return -ENOSPC
>  - verify dev->irq
> 
>  include/linux/pci.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 33c2b0b77429..fc2e832d7b9c 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1342,9 +1342,9 @@ pci_alloc_irq_vectors_affinity(struct pci_dev *dev, 
> unsigned int min_vecs,
>  unsigned int max_vecs, unsigned int flags,
>  const struct irq_affinity *aff_desc)
>  {
> - if (min_vecs > 1)
> - return -EINVAL;
> - return 1;
> + if ((flags & PCI_IRQ_LEGACY) && min_vecs == 1 && dev->irq)
> + return 1;
> + return -ENOSPC;
>  }
>  
>  static inline void pci_free_irq_vectors(struct pci_dev *dev)
> -- 
> 2.11.0
---end quoted text---

Re: [PATCH V2 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

[Michael Ellerman]

Michael Bringmann  writes:

> Removing or adding memory via the PowerPC hotplug interface shows
> anomalies in the association between memory and nodes.

What anomalies? Please describe the actual problem you're seeing, with
details, and why you think this is the correct fix.

This is a revert of 3af229f2071f ("powerpc/numa: Reset node_possible_map
to only node_online_map"), so please explain why all the things
mentioned in the change log for that commit are either wrong or no
longer true.

cheers

Re: [PATCH V2 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

[Michael Ellerman]

Michael Bringmann  writes:

> Removing or adding memory via the PowerPC hotplug interface shows
> anomalies in the association between memory and nodes.

What anomalies? Please describe the actual problem you're seeing, with
details, and why you think this is the correct fix.

This is a revert of 3af229f2071f ("powerpc/numa: Reset node_possible_map
to only node_online_map"), so please explain why all the things
mentioned in the change log for that commit are either wrong or no
longer true.

cheers

[PATCH] iscsi-target: Fix initial login PDU asynchronous socket close OOPs

[Nicholas A. Bellinger]

From: Nicholas Bellinger 

This patch fixes a OOPs originally introduced by:

   commit bb048357dad6d604520c91586334c9c230366a14
   Author: Nicholas Bellinger 
   Date:   Thu Sep 5 14:54:04 2013 -0700

   iscsi-target: Add sk->sk_state_change to cleanup after TCP failure

which would trigger a NULL pointer dereference when a TCP connection
was closed asynchronously via iscsi_target_sk_state_change(), but only
when the initial PDU processing in iscsi_target_do_login() from iscsi_np
process context was blocked waiting for backend I/O to complete.

To address this issue, this patch makes the following changes.

First, it introduces some common helper functions used for checking
socket closing state, checking login_flags, and atomically checking
socket closing state + setting login_flags.

Second, it introduces a LOGIN_FLAGS_INITIAL_PDU bit to know when a TCP
connection has dropped via iscsi_target_sk_state_change(), but the
initial PDU processing within iscsi_target_do_login() in iscsi_np
context is still running.  For this case, it sets LOGIN_FLAGS_CLOSED,
but doesn't invoke schedule_delayed_work().

The original NULL pointer dereference case reported by MNC is now handled
by iscsi_target_do_login() doing a iscsi_target_sk_check_close() before
transitioning to FFP to determine when the socket has already closed,
or iscsi_target_start_negotiation() if the login needs to exchange
more PDUs (eg: iscsi_target_do_login returned 0) but the socket has
closed.  For both of these cases, the cleanup up of remaining connection
resources will occur in iscsi_target_start_negotiation() from iscsi_np
process context once the failure is detected.

Finally, to handle to case where iscsi_target_sk_state_change() is
called after the initial PDU procesing is complete, it now invokes
conn->login_work -> iscsi_target_do_login_rx() to perform cleanup once
existing iscsi_target_sk_check_close() checks detect connection failure.
For this case, the cleanup of remaining connection resources will occur
in iscsi_target_do_login_rx() from delayed workqueue process context
once the failure is detected.

Reported-by: Mike Christie 
Cc: Mike Christie 
Reported-by: Hannes Reinecke 
Cc: Hannes Reinecke 
Cc: Sagi Grimberg 
Cc: Varun Prakash 
Signed-off-by: Nicholas Bellinger 
---
 drivers/target/iscsi/iscsi_target_nego.c | 194 +--
 include/target/iscsi/iscsi_target_core.h |   1 +
 2 files changed, 133 insertions(+), 62 deletions(-)

diff --git a/drivers/target/iscsi/iscsi_target_nego.c 
b/drivers/target/iscsi/iscsi_target_nego.c
index 7ccc9c1..6f88b31 100644
--- a/drivers/target/iscsi/iscsi_target_nego.c
+++ b/drivers/target/iscsi/iscsi_target_nego.c
@@ -493,14 +493,60 @@ static void iscsi_target_restore_sock_callbacks(struct 
iscsi_conn *conn)
 
 static int iscsi_target_do_login(struct iscsi_conn *, struct iscsi_login *);
 
-static bool iscsi_target_sk_state_check(struct sock *sk)
+static bool __iscsi_target_sk_check_close(struct sock *sk)
 {
if (sk->sk_state == TCP_CLOSE_WAIT || sk->sk_state == TCP_CLOSE) {
-   pr_debug("iscsi_target_sk_state_check: 
TCP_CLOSE_WAIT|TCP_CLOSE,"
+   pr_debug("__iscsi_target_sk_check_close: 
TCP_CLOSE_WAIT|TCP_CLOSE,"
"returning FALSE\n");
-   return false;
+   return true;
}
-   return true;
+   return false;
+}
+
+static bool iscsi_target_sk_check_close(struct iscsi_conn *conn)
+{
+   bool state = false;
+
+   if (conn->sock) {
+   struct sock *sk = conn->sock->sk;
+
+   read_lock_bh(>sk_callback_lock);
+   state = (__iscsi_target_sk_check_close(sk) ||
+test_bit(LOGIN_FLAGS_CLOSED, >login_flags));
+   read_unlock_bh(>sk_callback_lock);
+   }
+   return state;
+}
+
+static bool iscsi_target_sk_check_flag(struct iscsi_conn *conn, unsigned int 
flag)
+{
+   bool state = false;
+
+   if (conn->sock) {
+   struct sock *sk = conn->sock->sk;
+
+   read_lock_bh(>sk_callback_lock);
+   state = test_bit(flag, >login_flags);
+   read_unlock_bh(>sk_callback_lock);
+   }
+   return state;
+}
+
+static bool iscsi_target_sk_check_and_clear(struct iscsi_conn *conn, unsigned 
int flag)
+{
+   bool state = false;
+
+   if (conn->sock) {
+   struct sock *sk = conn->sock->sk;
+
+   write_lock_bh(>sk_callback_lock);
+   state = (__iscsi_target_sk_check_close(sk) ||
+test_bit(LOGIN_FLAGS_CLOSED, >login_flags));
+   if (!state)
+   clear_bit(flag, >login_flags);
+   write_unlock_bh(>sk_callback_lock);
+   }
+   return state;
 }
 
 static void 

[PATCH] iscsi-target: Fix initial login PDU asynchronous socket close OOPs

[Nicholas A. Bellinger]

From: Nicholas Bellinger 

This patch fixes a OOPs originally introduced by:

   commit bb048357dad6d604520c91586334c9c230366a14
   Author: Nicholas Bellinger 
   Date:   Thu Sep 5 14:54:04 2013 -0700

   iscsi-target: Add sk->sk_state_change to cleanup after TCP failure

which would trigger a NULL pointer dereference when a TCP connection
was closed asynchronously via iscsi_target_sk_state_change(), but only
when the initial PDU processing in iscsi_target_do_login() from iscsi_np
process context was blocked waiting for backend I/O to complete.

To address this issue, this patch makes the following changes.

First, it introduces some common helper functions used for checking
socket closing state, checking login_flags, and atomically checking
socket closing state + setting login_flags.

Second, it introduces a LOGIN_FLAGS_INITIAL_PDU bit to know when a TCP
connection has dropped via iscsi_target_sk_state_change(), but the
initial PDU processing within iscsi_target_do_login() in iscsi_np
context is still running.  For this case, it sets LOGIN_FLAGS_CLOSED,
but doesn't invoke schedule_delayed_work().

The original NULL pointer dereference case reported by MNC is now handled
by iscsi_target_do_login() doing a iscsi_target_sk_check_close() before
transitioning to FFP to determine when the socket has already closed,
or iscsi_target_start_negotiation() if the login needs to exchange
more PDUs (eg: iscsi_target_do_login returned 0) but the socket has
closed.  For both of these cases, the cleanup up of remaining connection
resources will occur in iscsi_target_start_negotiation() from iscsi_np
process context once the failure is detected.

Finally, to handle to case where iscsi_target_sk_state_change() is
called after the initial PDU procesing is complete, it now invokes
conn->login_work -> iscsi_target_do_login_rx() to perform cleanup once
existing iscsi_target_sk_check_close() checks detect connection failure.
For this case, the cleanup of remaining connection resources will occur
in iscsi_target_do_login_rx() from delayed workqueue process context
once the failure is detected.

Reported-by: Mike Christie 
Cc: Mike Christie 
Reported-by: Hannes Reinecke 
Cc: Hannes Reinecke 
Cc: Sagi Grimberg 
Cc: Varun Prakash 
Signed-off-by: Nicholas Bellinger 
---
 drivers/target/iscsi/iscsi_target_nego.c | 194 +--
 include/target/iscsi/iscsi_target_core.h |   1 +
 2 files changed, 133 insertions(+), 62 deletions(-)

diff --git a/drivers/target/iscsi/iscsi_target_nego.c 
b/drivers/target/iscsi/iscsi_target_nego.c
index 7ccc9c1..6f88b31 100644
--- a/drivers/target/iscsi/iscsi_target_nego.c
+++ b/drivers/target/iscsi/iscsi_target_nego.c
@@ -493,14 +493,60 @@ static void iscsi_target_restore_sock_callbacks(struct 
iscsi_conn *conn)
 
 static int iscsi_target_do_login(struct iscsi_conn *, struct iscsi_login *);
 
-static bool iscsi_target_sk_state_check(struct sock *sk)
+static bool __iscsi_target_sk_check_close(struct sock *sk)
 {
if (sk->sk_state == TCP_CLOSE_WAIT || sk->sk_state == TCP_CLOSE) {
-   pr_debug("iscsi_target_sk_state_check: 
TCP_CLOSE_WAIT|TCP_CLOSE,"
+   pr_debug("__iscsi_target_sk_check_close: 
TCP_CLOSE_WAIT|TCP_CLOSE,"
"returning FALSE\n");
-   return false;
+   return true;
}
-   return true;
+   return false;
+}
+
+static bool iscsi_target_sk_check_close(struct iscsi_conn *conn)
+{
+   bool state = false;
+
+   if (conn->sock) {
+   struct sock *sk = conn->sock->sk;
+
+   read_lock_bh(>sk_callback_lock);
+   state = (__iscsi_target_sk_check_close(sk) ||
+test_bit(LOGIN_FLAGS_CLOSED, >login_flags));
+   read_unlock_bh(>sk_callback_lock);
+   }
+   return state;
+}
+
+static bool iscsi_target_sk_check_flag(struct iscsi_conn *conn, unsigned int 
flag)
+{
+   bool state = false;
+
+   if (conn->sock) {
+   struct sock *sk = conn->sock->sk;
+
+   read_lock_bh(>sk_callback_lock);
+   state = test_bit(flag, >login_flags);
+   read_unlock_bh(>sk_callback_lock);
+   }
+   return state;
+}
+
+static bool iscsi_target_sk_check_and_clear(struct iscsi_conn *conn, unsigned 
int flag)
+{
+   bool state = false;
+
+   if (conn->sock) {
+   struct sock *sk = conn->sock->sk;
+
+   write_lock_bh(>sk_callback_lock);
+   state = (__iscsi_target_sk_check_close(sk) ||
+test_bit(LOGIN_FLAGS_CLOSED, >login_flags));
+   if (!state)
+   clear_bit(flag, >login_flags);
+   write_unlock_bh(>sk_callback_lock);
+   }
+   return state;
 }
 
 static void iscsi_target_login_drop(struct iscsi_conn *conn, struct 
iscsi_login *login)
@@ -540,6 +586,20 @@ static void iscsi_target_do_login_rx(struct work_struct 
*work)
 
pr_debug("entering 

[PATCH] Input: mousedev - fix implicit conversion warning

[Nick Desaulniers]

Clang warns:

drivers/input/mousedev.c:653:63: error: implicit conversion from 'int'
to 'signed char' changes value from 200 to -56
[-Wconstant-conversion]
  client->ps2[1] = 0x60; client->ps2[2] = 3; client->ps2[3] = 200;
~ ^~~

As far as I can tell, from

http://www.computer-engineering.org/ps2mouse/

Under "Command Set" > "0xE9 (Status Request)"

the value 200 is a valid sample rate. An explicit cast silences this
warning.

Signed-off-by: Nick Desaulniers 
---
 drivers/input/mousedev.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/input/mousedev.c b/drivers/input/mousedev.c
index 0e0ff84088fd..816e2431bba8 100644
--- a/drivers/input/mousedev.c
+++ b/drivers/input/mousedev.c
@@ -650,7 +650,9 @@ static void mousedev_generate_response(struct 
mousedev_client *client,
break;
 
case 0xe9: /* Get info */
-   client->ps2[1] = 0x60; client->ps2[2] = 3; client->ps2[3] = 200;
+   client->ps2[1] = 0x60;
+   client->ps2[2] = 3;
+   client->ps2[3] = (char) 200;
client->bufsiz = 4;
break;
 
-- 
2.11.0

[PATCH] Input: mousedev - fix implicit conversion warning

[Nick Desaulniers]

Clang warns:

drivers/input/mousedev.c:653:63: error: implicit conversion from 'int'
to 'signed char' changes value from 200 to -56
[-Wconstant-conversion]
  client->ps2[1] = 0x60; client->ps2[2] = 3; client->ps2[3] = 200;
~ ^~~

As far as I can tell, from

http://www.computer-engineering.org/ps2mouse/

Under "Command Set" > "0xE9 (Status Request)"

the value 200 is a valid sample rate. An explicit cast silences this
warning.

Signed-off-by: Nick Desaulniers 
---
 drivers/input/mousedev.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/input/mousedev.c b/drivers/input/mousedev.c
index 0e0ff84088fd..816e2431bba8 100644
--- a/drivers/input/mousedev.c
+++ b/drivers/input/mousedev.c
@@ -650,7 +650,9 @@ static void mousedev_generate_response(struct 
mousedev_client *client,
break;
 
case 0xe9: /* Get info */
-   client->ps2[1] = 0x60; client->ps2[2] = 3; client->ps2[3] = 200;
+   client->ps2[1] = 0x60;
+   client->ps2[2] = 3;
+   client->ps2[3] = (char) 200;
client->bufsiz = 4;
break;
 
-- 
2.11.0

Ich brauche deine Hilfe!

[Hubert Guillaud]

Lieber Freund,

Ich bin Frau Dionisia Denis Perman aus Island, verheiratet mit Late Engineer
Denis Perman {PhD}, der mit MULTINATIONAL OIL COMPANY EXXON AS A gearbeitet hat
DRILLING RIG SUPPLIER in Kuwait seit 19 Jahren, bevor er auf der
22. August 2009. Wir waren seit vierundzwanzig Jahren verheiratet
Kind. Er starb nach einer kurzen Krankheit, die nur vier Tage dauerte.
Vor seinem Tod hat er die Summe von USD 10.142.728,00 Dollar
Mit einer Kurierfirma in Indien und dieser Fonds ist derzeit mit dem Kurier 
warten auf meine
Auszahlung als Begünstigter und nächste Angehörige der Mittel. Kürzlich, meine
Doktor sagte mir, dass ich nicht für die nächsten acht Monate dauern würde
Krebsproblem Nachdem ich meinen Zustand gekannt habe, habe ich beschlossen, 
dies zu spenden
Fonds für eine Kirche, Organisation oder gute Person, die dies nutzen wird
Geld in gutem Glauben.

Ich habe diese Entscheidung getroffen, weil ich kein Kind habe, das erben wird
dieses Geld. Ich hielt diese Kaution bis heute; Deshalb bin ich
Diese Entscheidung treffen Ich glaube nicht, dass ich ein Telefon brauchen werde
Kommunikation in dieser Hinsicht wegen der Vertraulichkeit dieser
Transaktion. Nach deiner Antwort werde ich dir den Kontakt des Kuriers geben. 
ich
Wird auch ein Genehmigungsschreiben an den Kurier ausstellen, der beweisen wird
Sie der gegenwärtige Begünstigte dieses Geldes. So solltest du mir deine 
Adresse, deinen Namen, dein Land und deine Hand schicken.

Erwarten Sie Ihre Antworten und Gott segnen Sie.
Frau Dionisia Denis Perman

Ich brauche deine Hilfe!

[Hubert Guillaud]

Lieber Freund,

Ich bin Frau Dionisia Denis Perman aus Island, verheiratet mit Late Engineer
Denis Perman {PhD}, der mit MULTINATIONAL OIL COMPANY EXXON AS A gearbeitet hat
DRILLING RIG SUPPLIER in Kuwait seit 19 Jahren, bevor er auf der
22. August 2009. Wir waren seit vierundzwanzig Jahren verheiratet
Kind. Er starb nach einer kurzen Krankheit, die nur vier Tage dauerte.
Vor seinem Tod hat er die Summe von USD 10.142.728,00 Dollar
Mit einer Kurierfirma in Indien und dieser Fonds ist derzeit mit dem Kurier 
warten auf meine
Auszahlung als Begünstigter und nächste Angehörige der Mittel. Kürzlich, meine
Doktor sagte mir, dass ich nicht für die nächsten acht Monate dauern würde
Krebsproblem Nachdem ich meinen Zustand gekannt habe, habe ich beschlossen, 
dies zu spenden
Fonds für eine Kirche, Organisation oder gute Person, die dies nutzen wird
Geld in gutem Glauben.

Ich habe diese Entscheidung getroffen, weil ich kein Kind habe, das erben wird
dieses Geld. Ich hielt diese Kaution bis heute; Deshalb bin ich
Diese Entscheidung treffen Ich glaube nicht, dass ich ein Telefon brauchen werde
Kommunikation in dieser Hinsicht wegen der Vertraulichkeit dieser
Transaktion. Nach deiner Antwort werde ich dir den Kontakt des Kuriers geben. 
ich
Wird auch ein Genehmigungsschreiben an den Kurier ausstellen, der beweisen wird
Sie der gegenwärtige Begünstigte dieses Geldes. So solltest du mir deine 
Adresse, deinen Namen, dein Land und deine Hand schicken.

Erwarten Sie Ihre Antworten und Gott segnen Sie.
Frau Dionisia Denis Perman

[PATCH linux-next v3 1/1] spi: imx: dynamic burst length adjust for PIO mode

[jiada_wang]

From: Jiada Wang 

previously burst length (BURST_LENGTH) is always set to equal
to bits_per_word, causes a 10us gap between each word in
transfer, which significantly affects performance.

This patch uses 32 bits transfer to simulate lower bits transfer,
and adjusts burst length runtimely to use biggeest burst length
as possible to reduce the gaps in transfer for PIO mode.

Signed-off-by: Jiada Wang 
---

Changes in v2:
* used cpu_to_* functions to ensure this patch works for both
  little & big endian kernel.

Changes in v3:
* Only allow dynamic burst in PIO mode
* Avoid direct manipulation of tx_buf & rx_buf

 drivers/spi/spi-imx.c | 156 +++---
 1 file changed, 148 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index b402530..54f7c31 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -56,9 +56,11 @@
 
 /* The maximum  bytes that a sdma BD can transfer.*/
 #define MAX_SDMA_BD_BYTES  (1 << 15)
+#define MX51_ECSPI_CTRL_MAX_BURST  512
 struct spi_imx_config {
unsigned int speed_hz;
unsigned int bpw;
+   unsigned int len;
 };
 
 enum spi_imx_devtype {
@@ -97,12 +99,14 @@ struct spi_imx_data {
unsigned int bytes_per_word;
unsigned int spi_drctl;
 
-   unsigned int count;
+   unsigned int count, count_index;
void (*tx)(struct spi_imx_data *);
void (*rx)(struct spi_imx_data *);
void *rx_buf;
const void *tx_buf;
unsigned int txfifo; /* number of words pushed in tx FIFO */
+   unsigned int dynamic_burst, bpw_rx;
+   unsigned int bpw_w;
 
/* DMA */
bool usedma;
@@ -238,6 +242,7 @@ static bool spi_imx_can_dma(struct spi_master *master, 
struct spi_device *spi,
return false;
 
spi_imx->wml = i;
+   spi_imx->dynamic_burst = 0;
 
return true;
 }
@@ -252,6 +257,7 @@ static bool spi_imx_can_dma(struct spi_master *master, 
struct spi_device *spi,
 #define MX51_ECSPI_CTRL_PREDIV_OFFSET  12
 #define MX51_ECSPI_CTRL_CS(cs) ((cs) << 18)
 #define MX51_ECSPI_CTRL_BL_OFFSET  20
+#define MX51_ECSPI_CTRL_BL_MASK(0xfff << 20)
 
 #define MX51_ECSPI_CONFIG  0x0c
 #define MX51_ECSPI_CONFIG_SCLKPHA(cs)  (1 << ((cs) +  0))
@@ -279,6 +285,95 @@ static bool spi_imx_can_dma(struct spi_master *master, 
struct spi_device *spi,
 #define MX51_ECSPI_TESTREG 0x20
 #define MX51_ECSPI_TESTREG_LBC BIT(31)
 
+static u32 spi_imx_u32_swap_u16(u32 val)
+{
+   u32 data = val;
+   u16 *temp = (u16 *)
+
+   *temp = cpu_to_be16(*temp);
+   *(temp + 1) = cpu_to_be16(*(temp + 1));
+
+   data = cpu_to_be32(data);
+
+   return data;
+}
+
+static void spi_imx_buf_rx_swap_u32(struct spi_imx_data *spi_imx)
+{
+   unsigned int val = readl(spi_imx->base + MXC_CSPIRXDATA);
+
+   if (spi_imx->rx_buf) {
+   if (spi_imx->bpw_w == 1)
+   val = cpu_to_be32(val);
+   else if (spi_imx->bpw_w == 2)
+   val = spi_imx_u32_swap_u16(val);
+
+   *(u32 *)spi_imx->rx_buf = val;
+   spi_imx->rx_buf += sizeof(u32);
+   }
+}
+
+static void spi_imx_buf_rx_swap(struct spi_imx_data *spi_imx)
+{
+   if (!spi_imx->bpw_rx) {
+   spi_imx_buf_rx_swap_u32(spi_imx);
+   return;
+   }
+
+   if (spi_imx->bpw_w == 1)
+   spi_imx_buf_rx_u8(spi_imx);
+   else if (spi_imx->bpw_w == 2)
+   spi_imx_buf_rx_u16(spi_imx);
+}
+
+static void spi_imx_buf_tx_swap_u32(struct spi_imx_data *spi_imx)
+{
+   u32 val = 0;
+
+   if (spi_imx->tx_buf) {
+   val = *(u32 *)spi_imx->tx_buf;
+   spi_imx->tx_buf += sizeof(u32);
+   }
+
+   spi_imx->count -= sizeof(u32);
+   if (spi_imx->bpw_w == 1)
+   val = cpu_to_be32(val);
+   else if (spi_imx->bpw_w == 2)
+   val = spi_imx_u32_swap_u16(val);
+
+   writel(val, spi_imx->base + MXC_CSPITXDATA);
+}
+
+static void spi_imx_buf_tx_swap(struct spi_imx_data *spi_imx)
+{
+   u32 ctrl, val;
+
+   if (spi_imx->count == spi_imx->count_index) {
+   spi_imx->count_index = spi_imx->count > sizeof(u32) ?
+   spi_imx->count % sizeof(u32) : 0;
+   ctrl = readl(spi_imx->base + MX51_ECSPI_CTRL);
+   ctrl &= ~MX51_ECSPI_CTRL_BL_MASK;
+   if (spi_imx->count >= sizeof(u32)) {
+   val = spi_imx->count - spi_imx->count_index;
+   } else {
+   val = spi_imx->bpw_w;
+   spi_imx->bpw_rx = 1;
+   }
+   ctrl |= ((val * 8 - 1) << MX51_ECSPI_CTRL_BL_OFFSET);
+   writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
+   }
+
+   if (spi_imx->count >= sizeof(u32)) {
+   spi_imx_buf_tx_swap_u32(spi_imx);
+

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

[Xunlei Pang]

On 05/26/2017 at 10:49 AM, Dave Young wrote:
> Ccing Xunlei he is reading the patches see what need to be done for
> kdump. There should still be several places to handle to make kdump work.
>
> On 05/18/17 at 07:01pm, Borislav Petkov wrote:
>> On Tue, Apr 18, 2017 at 04:22:12PM -0500, Tom Lendacky wrote:
>>> Add sysfs support for SME so that user-space utilities (kdump, etc.) can
>>> determine if SME is active.
>> But why do user-space tools need to know that?
>>
>> I mean, when we load the kdump kernel, we do it with the first kernel,
>> with the kexec_load() syscall, AFAICT. And that code does a lot of
>> things during that init, like machine_kexec_prepare()->init_pgtable() to
>> prepare the ident mapping of the second kernel, for example.
>>
>> What I'm aiming at is that the first kernel knows *exactly* whether SME
>> is enabled or not and doesn't need to tell the second one through some
>> sysfs entries - it can do that during loading.
>>
>> So I don't think we need any userspace things at all...
> If kdump kernel can get the SME status from hardware register then this
> should be not necessary and this patch can be dropped.

Yes, I also agree with dropping this one.

Regards,
Xunlei

[PATCH linux-next v3 1/1] spi: imx: dynamic burst length adjust for PIO mode

[jiada_wang]

From: Jiada Wang 

previously burst length (BURST_LENGTH) is always set to equal
to bits_per_word, causes a 10us gap between each word in
transfer, which significantly affects performance.

This patch uses 32 bits transfer to simulate lower bits transfer,
and adjusts burst length runtimely to use biggeest burst length
as possible to reduce the gaps in transfer for PIO mode.

Signed-off-by: Jiada Wang 
---

Changes in v2:
* used cpu_to_* functions to ensure this patch works for both
  little & big endian kernel.

Changes in v3:
* Only allow dynamic burst in PIO mode
* Avoid direct manipulation of tx_buf & rx_buf

 drivers/spi/spi-imx.c | 156 +++---
 1 file changed, 148 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index b402530..54f7c31 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -56,9 +56,11 @@
 
 /* The maximum  bytes that a sdma BD can transfer.*/
 #define MAX_SDMA_BD_BYTES  (1 << 15)
+#define MX51_ECSPI_CTRL_MAX_BURST  512
 struct spi_imx_config {
unsigned int speed_hz;
unsigned int bpw;
+   unsigned int len;
 };
 
 enum spi_imx_devtype {
@@ -97,12 +99,14 @@ struct spi_imx_data {
unsigned int bytes_per_word;
unsigned int spi_drctl;
 
-   unsigned int count;
+   unsigned int count, count_index;
void (*tx)(struct spi_imx_data *);
void (*rx)(struct spi_imx_data *);
void *rx_buf;
const void *tx_buf;
unsigned int txfifo; /* number of words pushed in tx FIFO */
+   unsigned int dynamic_burst, bpw_rx;
+   unsigned int bpw_w;
 
/* DMA */
bool usedma;
@@ -238,6 +242,7 @@ static bool spi_imx_can_dma(struct spi_master *master, 
struct spi_device *spi,
return false;
 
spi_imx->wml = i;
+   spi_imx->dynamic_burst = 0;
 
return true;
 }
@@ -252,6 +257,7 @@ static bool spi_imx_can_dma(struct spi_master *master, 
struct spi_device *spi,
 #define MX51_ECSPI_CTRL_PREDIV_OFFSET  12
 #define MX51_ECSPI_CTRL_CS(cs) ((cs) << 18)
 #define MX51_ECSPI_CTRL_BL_OFFSET  20
+#define MX51_ECSPI_CTRL_BL_MASK(0xfff << 20)
 
 #define MX51_ECSPI_CONFIG  0x0c
 #define MX51_ECSPI_CONFIG_SCLKPHA(cs)  (1 << ((cs) +  0))
@@ -279,6 +285,95 @@ static bool spi_imx_can_dma(struct spi_master *master, 
struct spi_device *spi,
 #define MX51_ECSPI_TESTREG 0x20
 #define MX51_ECSPI_TESTREG_LBC BIT(31)
 
+static u32 spi_imx_u32_swap_u16(u32 val)
+{
+   u32 data = val;
+   u16 *temp = (u16 *)
+
+   *temp = cpu_to_be16(*temp);
+   *(temp + 1) = cpu_to_be16(*(temp + 1));
+
+   data = cpu_to_be32(data);
+
+   return data;
+}
+
+static void spi_imx_buf_rx_swap_u32(struct spi_imx_data *spi_imx)
+{
+   unsigned int val = readl(spi_imx->base + MXC_CSPIRXDATA);
+
+   if (spi_imx->rx_buf) {
+   if (spi_imx->bpw_w == 1)
+   val = cpu_to_be32(val);
+   else if (spi_imx->bpw_w == 2)
+   val = spi_imx_u32_swap_u16(val);
+
+   *(u32 *)spi_imx->rx_buf = val;
+   spi_imx->rx_buf += sizeof(u32);
+   }
+}
+
+static void spi_imx_buf_rx_swap(struct spi_imx_data *spi_imx)
+{
+   if (!spi_imx->bpw_rx) {
+   spi_imx_buf_rx_swap_u32(spi_imx);
+   return;
+   }
+
+   if (spi_imx->bpw_w == 1)
+   spi_imx_buf_rx_u8(spi_imx);
+   else if (spi_imx->bpw_w == 2)
+   spi_imx_buf_rx_u16(spi_imx);
+}
+
+static void spi_imx_buf_tx_swap_u32(struct spi_imx_data *spi_imx)
+{
+   u32 val = 0;
+
+   if (spi_imx->tx_buf) {
+   val = *(u32 *)spi_imx->tx_buf;
+   spi_imx->tx_buf += sizeof(u32);
+   }
+
+   spi_imx->count -= sizeof(u32);
+   if (spi_imx->bpw_w == 1)
+   val = cpu_to_be32(val);
+   else if (spi_imx->bpw_w == 2)
+   val = spi_imx_u32_swap_u16(val);
+
+   writel(val, spi_imx->base + MXC_CSPITXDATA);
+}
+
+static void spi_imx_buf_tx_swap(struct spi_imx_data *spi_imx)
+{
+   u32 ctrl, val;
+
+   if (spi_imx->count == spi_imx->count_index) {
+   spi_imx->count_index = spi_imx->count > sizeof(u32) ?
+   spi_imx->count % sizeof(u32) : 0;
+   ctrl = readl(spi_imx->base + MX51_ECSPI_CTRL);
+   ctrl &= ~MX51_ECSPI_CTRL_BL_MASK;
+   if (spi_imx->count >= sizeof(u32)) {
+   val = spi_imx->count - spi_imx->count_index;
+   } else {
+   val = spi_imx->bpw_w;
+   spi_imx->bpw_rx = 1;
+   }
+   ctrl |= ((val * 8 - 1) << MX51_ECSPI_CTRL_BL_OFFSET);
+   writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
+   }
+
+   if (spi_imx->count >= sizeof(u32)) {
+   spi_imx_buf_tx_swap_u32(spi_imx);
+   return;
+   }
+
+   if 

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

[Xunlei Pang]

On 05/26/2017 at 10:49 AM, Dave Young wrote:
> Ccing Xunlei he is reading the patches see what need to be done for
> kdump. There should still be several places to handle to make kdump work.
>
> On 05/18/17 at 07:01pm, Borislav Petkov wrote:
>> On Tue, Apr 18, 2017 at 04:22:12PM -0500, Tom Lendacky wrote:
>>> Add sysfs support for SME so that user-space utilities (kdump, etc.) can
>>> determine if SME is active.
>> But why do user-space tools need to know that?
>>
>> I mean, when we load the kdump kernel, we do it with the first kernel,
>> with the kexec_load() syscall, AFAICT. And that code does a lot of
>> things during that init, like machine_kexec_prepare()->init_pgtable() to
>> prepare the ident mapping of the second kernel, for example.
>>
>> What I'm aiming at is that the first kernel knows *exactly* whether SME
>> is enabled or not and doesn't need to tell the second one through some
>> sysfs entries - it can do that during loading.
>>
>> So I don't think we need any userspace things at all...
> If kdump kernel can get the SME status from hardware register then this
> should be not necessary and this patch can be dropped.

Yes, I also agree with dropping this one.

Regards,
Xunlei

Re: [RESEND: PATCH v4 2/4] remoteproc: qcom: refactor mss fw image loading sequence

[Sricharan R]

Hi Bjorn,

On 5/26/2017 12:33 AM, Bjorn Andersson wrote:
> On Mon 22 May 06:26 PDT 2017, Dwivedi, Avaneesh Kumar (avani) wrote:
>> On 5/22/2017 4:07 PM, Sricharan R wrote:
>>> Hi,
>>>
>>> On 5/22/2017 3:03 PM, Dwivedi, Avaneesh Kumar (avani) wrote:

 On 5/20/2017 8:25 AM, Sricharan R wrote:
> Hi Bjorn/Avaneesh,
>
> On 5/16/2017 11:32 PM, Avaneesh Kumar Dwivedi wrote:
> [..]
>> -
>> -size = readl(qproc->rmb_base + RMB_PMI_CODE_LENGTH_REG);
>> -if (!size) {
>> -boot_addr = relocate ? qproc->mpss_phys : min_addr;
>> -writel(boot_addr, qproc->rmb_base + RMB_PMI_CODE_START_REG);
>> -writel(RMB_CMD_LOAD_READY, qproc->rmb_base + 
>> RMB_MBA_COMMAND_REG);
>> -}
>> -
>>size += phdr->p_memsz;
>> -writel(size, qproc->rmb_base + RMB_PMI_CODE_LENGTH_REG);
>>}
> So while moving this down, can we use qcom_mdt_load instead for
> the mpss image loading part above ?
 qcom_mdt_load() can not be used to load segments for mpss, as MPSS
 blobs are self authenticated.  while qcom_mdt_load() is used in
 cases where authentication of loaded blobs is done by trustzone.
 for that qcom_mdt_load() does extra steps to send pas_id to
 trustzone and mem_setup() etc.
>>> Right, so my intention of asking this was if the code which does the
>>> calculation and loads the segments in qcom_mdt_load can somehow be
>>> abstracted out, so that future self authenticating rproc (even mpss
>>> in this case) can use them to load mdt ?
>> As i understand, you want to replace the piece of code which does
>> parse mdt and load individual firmware blobs in a separate routine.
>> So that it can be called by any one without again doing parsing and
>> loading for self authentication.?  Till now only MPSS does rely on
>> self authentication, all other subsystems use qcom_mdt_load().  I
>> think this is reason why the qcom_mdt_load() equivalent routine has
>> not been used.  Bjorn may further add in this.
> 
> I have not been able to come up with a clean way to provide a useful
> mdt-loader abstraction that works for the SCM PILs, the
> self-authenticated PILs and the non-PIL SCM users.
> 
> Further more with the upcoming ramdump support we will need to extract
> segment information from the mdt header, so we will have to revisit this
> topic.
> 
> 
> Regardless, I would prefer that we follow up with such refactoring after
> getting this series sorted out.
> 

ok, agree.  While trying to add Q6 support for ipq8074, which is again
a self-authenticating PIL with mdt, i can try this.

>>>
>> +/* Transfer ownership of modem region with modem fw */
>> +boot_addr = relocate ? qproc->mpss_phys : min_addr;
>> +writel(boot_addr, qproc->rmb_base + RMB_PMI_CODE_START_REG);
>> +writel(RMB_CMD_LOAD_READY, qproc->rmb_base + RMB_MBA_COMMAND_REG);
>> +writel(size, qproc->rmb_base + RMB_PMI_CODE_LENGTH_REG);
> For ipq8074 [1], wcnss core has an Q6V5 version of the ip for
> which the initialization/boot sequence is pretty much the same
> as that has been added for msm8996 in this series. So wanted to
> understand if its better to use this remoteproc itself by
> keeping the Q6 and mpss parts separately (or) add a new
> remoteproc ?
 Bjorn can better answer this query, but i believe this remoteproc
 can be extended to load mpss part by adding private initialization
 for the IP.
>>> ya, the mpss part can be separated out, so that this can be a Q6 +
>>> MPSS (or) Q6 + WCNSS remoteproc. Was asking this to get the right
>>> way for adding the Q6 + WCNSS remoteproc, as the Q6 part is same
>>> what you have added for msm8996.
>> Again, i believe yes but leave Bjorn to make final comment.
> 
> It definitely sounds like there's room for reuse here, how much of the
> initialization and authentication sequences are common between the two?

The initialization sequence is exactly the same as what was done for
msm8996(Q6) one added in this series. So for reusing this driver for Q6,
the Q6 + MPSS has to be decoupled and driver has to look common for
Q6 + any, (ie) Q6 + mpss (or) Q6 + wcnss. Incase if that's not neat,
atleast the Q6 initialization sequence can be reused.

Regards,
 Sricharan

> 
> Regards,
> Bjorn
> 

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [RESEND: PATCH v4 2/4] remoteproc: qcom: refactor mss fw image loading sequence

[Sricharan R]

Hi Bjorn,

On 5/26/2017 12:33 AM, Bjorn Andersson wrote:
> On Mon 22 May 06:26 PDT 2017, Dwivedi, Avaneesh Kumar (avani) wrote:
>> On 5/22/2017 4:07 PM, Sricharan R wrote:
>>> Hi,
>>>
>>> On 5/22/2017 3:03 PM, Dwivedi, Avaneesh Kumar (avani) wrote:

 On 5/20/2017 8:25 AM, Sricharan R wrote:
> Hi Bjorn/Avaneesh,
>
> On 5/16/2017 11:32 PM, Avaneesh Kumar Dwivedi wrote:
> [..]
>> -
>> -size = readl(qproc->rmb_base + RMB_PMI_CODE_LENGTH_REG);
>> -if (!size) {
>> -boot_addr = relocate ? qproc->mpss_phys : min_addr;
>> -writel(boot_addr, qproc->rmb_base + RMB_PMI_CODE_START_REG);
>> -writel(RMB_CMD_LOAD_READY, qproc->rmb_base + 
>> RMB_MBA_COMMAND_REG);
>> -}
>> -
>>size += phdr->p_memsz;
>> -writel(size, qproc->rmb_base + RMB_PMI_CODE_LENGTH_REG);
>>}
> So while moving this down, can we use qcom_mdt_load instead for
> the mpss image loading part above ?
 qcom_mdt_load() can not be used to load segments for mpss, as MPSS
 blobs are self authenticated.  while qcom_mdt_load() is used in
 cases where authentication of loaded blobs is done by trustzone.
 for that qcom_mdt_load() does extra steps to send pas_id to
 trustzone and mem_setup() etc.
>>> Right, so my intention of asking this was if the code which does the
>>> calculation and loads the segments in qcom_mdt_load can somehow be
>>> abstracted out, so that future self authenticating rproc (even mpss
>>> in this case) can use them to load mdt ?
>> As i understand, you want to replace the piece of code which does
>> parse mdt and load individual firmware blobs in a separate routine.
>> So that it can be called by any one without again doing parsing and
>> loading for self authentication.?  Till now only MPSS does rely on
>> self authentication, all other subsystems use qcom_mdt_load().  I
>> think this is reason why the qcom_mdt_load() equivalent routine has
>> not been used.  Bjorn may further add in this.
> 
> I have not been able to come up with a clean way to provide a useful
> mdt-loader abstraction that works for the SCM PILs, the
> self-authenticated PILs and the non-PIL SCM users.
> 
> Further more with the upcoming ramdump support we will need to extract
> segment information from the mdt header, so we will have to revisit this
> topic.
> 
> 
> Regardless, I would prefer that we follow up with such refactoring after
> getting this series sorted out.
> 

ok, agree.  While trying to add Q6 support for ipq8074, which is again
a self-authenticating PIL with mdt, i can try this.

>>>
>> +/* Transfer ownership of modem region with modem fw */
>> +boot_addr = relocate ? qproc->mpss_phys : min_addr;
>> +writel(boot_addr, qproc->rmb_base + RMB_PMI_CODE_START_REG);
>> +writel(RMB_CMD_LOAD_READY, qproc->rmb_base + RMB_MBA_COMMAND_REG);
>> +writel(size, qproc->rmb_base + RMB_PMI_CODE_LENGTH_REG);
> For ipq8074 [1], wcnss core has an Q6V5 version of the ip for
> which the initialization/boot sequence is pretty much the same
> as that has been added for msm8996 in this series. So wanted to
> understand if its better to use this remoteproc itself by
> keeping the Q6 and mpss parts separately (or) add a new
> remoteproc ?
 Bjorn can better answer this query, but i believe this remoteproc
 can be extended to load mpss part by adding private initialization
 for the IP.
>>> ya, the mpss part can be separated out, so that this can be a Q6 +
>>> MPSS (or) Q6 + WCNSS remoteproc. Was asking this to get the right
>>> way for adding the Q6 + WCNSS remoteproc, as the Q6 part is same
>>> what you have added for msm8996.
>> Again, i believe yes but leave Bjorn to make final comment.
> 
> It definitely sounds like there's room for reuse here, how much of the
> initialization and authentication sequences are common between the two?

The initialization sequence is exactly the same as what was done for
msm8996(Q6) one added in this series. So for reusing this driver for Q6,
the Q6 + MPSS has to be decoupled and driver has to look common for
Q6 + any, (ie) Q6 + mpss (or) Q6 + wcnss. Incase if that's not neat,
atleast the Q6 initialization sequence can be reused.

Regards,
 Sricharan

> 
> Regards,
> Bjorn
> 

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH V4 00/17] thermal: cpu_cooling: improve interaction with cpufreq core

[Viresh Kumar]

On 26-04-17, 11:41, Lukasz Luba wrote:
> Hi Viresh,
> 
> I went through the v4 code and it looks good to me.
> Feel free to add for the v4 series
> Reviewed-by: Lukasz Luba 

@Eduardo: You missed adding this to the patches.

-- 
viresh

Re: [PATCH V4 00/17] thermal: cpu_cooling: improve interaction with cpufreq core

[Viresh Kumar]

On 26-04-17, 11:41, Lukasz Luba wrote:
> Hi Viresh,
> 
> I went through the v4 code and it looks good to me.
> Feel free to add for the v4 series
> Reviewed-by: Lukasz Luba 

@Eduardo: You missed adding this to the patches.

-- 
viresh

RE: [PATCH] pinctrl/amd: Use regular interrupt instead of chained

[Shah, Nehal-bakulchandra]

Hi Thomas,

Thanks for the patch. However, we have received this issue from multiple people 
and different disro but it occurs only on Gigabyte hardware. With reference AM4 
ryzen board we are not facing this issue.
We are in discussion with gigabyte to check the BIOS part. Once we have clarity 
on that, we can consider driver part. Also, this code is running on multiple 
platform of different customers so changing directly at this point of time may 
be risky in my point of view. Requesting you to hold this patch till we get 
clarity on bios end.

Thanks for your understanding.

Regards

Nehal

-Original Message-
From: linux-gpio-ow...@vger.kernel.org 
[mailto:linux-gpio-ow...@vger.kernel.org] On Behalf Of Thomas Gleixner
Sent: Wednesday, May 24, 2017 2:54 AM
To: LKML 
Cc: Linus Walleij ; linux-g...@vger.kernel.org; 
Borislav Petkov ; Xue, Ken 
Subject: [PATCH] pinctrl/amd: Use regular interrupt instead of chained

The AMD pinctrl driver uses a chained interrupt to demultiplex the GPIO 
interrupts. Kevin Vandeventer reported, that his new AMD Ryzen locks up hard on 
boot when the AMD pinctrl driver is initialized. The reason is an interrupt 
storm. It's not clear whether that's caused by hardware or firmware or both.

Using chained interrupts on X86 is a dangerous endavour. If a system is 
misconfigured or the hardware buggy there is no safety net to catch an 
interrupt storm.

Convert the driver to use a regular interrupt for the demultiplex handler. This 
allows the interrupt storm detector to catch the malfunction and lets the 
system boot up.

This should be backported to stable because it's likely that more users run 
into this problem as the AMD Ryzen machines are spreading.

Reported-by: Kevin Vandeventer
Link: https://bugzilla.suse.com/show_bug.cgi?id=1034261
Signed-off-by: Thomas Gleixner 
---
 drivers/pinctrl/pinctrl-amd.c |   91 ++
 1 file changed, 41 insertions(+), 50 deletions(-)

--- a/drivers/pinctrl/pinctrl-amd.c
+++ b/drivers/pinctrl/pinctrl-amd.c
@@ -495,64 +495,54 @@ static struct irq_chip amd_gpio_irqchip
.flags= IRQCHIP_SKIP_SET_WAKE,
 };
 
-static void amd_gpio_irq_handler(struct irq_desc *desc)
+#define PIN_IRQ_PENDING(BIT(INTERRUPT_STS_OFF) | BIT(WAKE_STS_OFF))
+
+static irqreturn_t amd_gpio_irq_handler(int irq, void *dev_id)
 {
-   u32 i;
-   u32 off;
-   u32 reg;
-   u32 pin_reg;
-   u64 reg64;
-   int handled = 0;
-   unsigned int irq;
+   struct amd_gpio *gpio_dev = dev_id;
+   struct gpio_chip *gc = _dev->gc;
+   irqreturn_t ret = IRQ_NONE;
+   unsigned int i, irqnr;
unsigned long flags;
-   struct irq_chip *chip = irq_desc_get_chip(desc);
-   struct gpio_chip *gc = irq_desc_get_handler_data(desc);
-   struct amd_gpio *gpio_dev = gpiochip_get_data(gc);
+   u32 *regs, regval;
+   u64 status, mask;
 
-   chained_irq_enter(chip, desc);
-   /*enable GPIO interrupt again*/
+   /* Read the wake status */
raw_spin_lock_irqsave(_dev->lock, flags);
-   reg = readl(gpio_dev->base + WAKE_INT_STATUS_REG1);
-   reg64 = reg;
-   reg64 = reg64 << 32;
-
-   reg = readl(gpio_dev->base + WAKE_INT_STATUS_REG0);
-   reg64 |= reg;
+   status = readl(gpio_dev->base + WAKE_INT_STATUS_REG1);
+   status <<= 32;
+   status |= readl(gpio_dev->base + WAKE_INT_STATUS_REG0);
raw_spin_unlock_irqrestore(_dev->lock, flags);
 
-   /*
-* first 46 bits indicates interrupt status.
-* one bit represents four interrupt sources.
-   */
-   for (off = 0; off < 46 ; off++) {
-   if (reg64 & BIT(off)) {
-   for (i = 0; i < 4; i++) {
-   pin_reg = readl(gpio_dev->base +
-   (off * 4 + i) * 4);
-   if ((pin_reg & BIT(INTERRUPT_STS_OFF)) ||
-   (pin_reg & BIT(WAKE_STS_OFF))) {
-   irq = irq_find_mapping(gc->irqdomain,
-   off * 4 + i);
-   generic_handle_irq(irq);
-   writel(pin_reg,
-   gpio_dev->base
-   + (off * 4 + i) * 4);
-   handled++;
-   }
-   }
+   /* Bit 0-45 contain the relevant status bits */
+   status &= (1ULL << 46) - 1;
+   regs = gpio_dev->base;
+   for (mask = 1, irqnr = 0; status; mask <<= 1, regs += 4, irqnr += 4) {
+   if (!(status & mask))
+   continue;
+   status &= ~mask;
+
+   /* Each status 

RE: [PATCH] pinctrl/amd: Use regular interrupt instead of chained

[Shah, Nehal-bakulchandra]

Hi Thomas,

Thanks for the patch. However, we have received this issue from multiple people 
and different disro but it occurs only on Gigabyte hardware. With reference AM4 
ryzen board we are not facing this issue.
We are in discussion with gigabyte to check the BIOS part. Once we have clarity 
on that, we can consider driver part. Also, this code is running on multiple 
platform of different customers so changing directly at this point of time may 
be risky in my point of view. Requesting you to hold this patch till we get 
clarity on bios end.

Thanks for your understanding.

Regards

Nehal

-Original Message-
From: linux-gpio-ow...@vger.kernel.org 
[mailto:linux-gpio-ow...@vger.kernel.org] On Behalf Of Thomas Gleixner
Sent: Wednesday, May 24, 2017 2:54 AM
To: LKML 
Cc: Linus Walleij ; linux-g...@vger.kernel.org; 
Borislav Petkov ; Xue, Ken 
Subject: [PATCH] pinctrl/amd: Use regular interrupt instead of chained

The AMD pinctrl driver uses a chained interrupt to demultiplex the GPIO 
interrupts. Kevin Vandeventer reported, that his new AMD Ryzen locks up hard on 
boot when the AMD pinctrl driver is initialized. The reason is an interrupt 
storm. It's not clear whether that's caused by hardware or firmware or both.

Using chained interrupts on X86 is a dangerous endavour. If a system is 
misconfigured or the hardware buggy there is no safety net to catch an 
interrupt storm.

Convert the driver to use a regular interrupt for the demultiplex handler. This 
allows the interrupt storm detector to catch the malfunction and lets the 
system boot up.

This should be backported to stable because it's likely that more users run 
into this problem as the AMD Ryzen machines are spreading.

Reported-by: Kevin Vandeventer
Link: https://bugzilla.suse.com/show_bug.cgi?id=1034261
Signed-off-by: Thomas Gleixner 
---
 drivers/pinctrl/pinctrl-amd.c |   91 ++
 1 file changed, 41 insertions(+), 50 deletions(-)

--- a/drivers/pinctrl/pinctrl-amd.c
+++ b/drivers/pinctrl/pinctrl-amd.c
@@ -495,64 +495,54 @@ static struct irq_chip amd_gpio_irqchip
.flags= IRQCHIP_SKIP_SET_WAKE,
 };
 
-static void amd_gpio_irq_handler(struct irq_desc *desc)
+#define PIN_IRQ_PENDING(BIT(INTERRUPT_STS_OFF) | BIT(WAKE_STS_OFF))
+
+static irqreturn_t amd_gpio_irq_handler(int irq, void *dev_id)
 {
-   u32 i;
-   u32 off;
-   u32 reg;
-   u32 pin_reg;
-   u64 reg64;
-   int handled = 0;
-   unsigned int irq;
+   struct amd_gpio *gpio_dev = dev_id;
+   struct gpio_chip *gc = _dev->gc;
+   irqreturn_t ret = IRQ_NONE;
+   unsigned int i, irqnr;
unsigned long flags;
-   struct irq_chip *chip = irq_desc_get_chip(desc);
-   struct gpio_chip *gc = irq_desc_get_handler_data(desc);
-   struct amd_gpio *gpio_dev = gpiochip_get_data(gc);
+   u32 *regs, regval;
+   u64 status, mask;
 
-   chained_irq_enter(chip, desc);
-   /*enable GPIO interrupt again*/
+   /* Read the wake status */
raw_spin_lock_irqsave(_dev->lock, flags);
-   reg = readl(gpio_dev->base + WAKE_INT_STATUS_REG1);
-   reg64 = reg;
-   reg64 = reg64 << 32;
-
-   reg = readl(gpio_dev->base + WAKE_INT_STATUS_REG0);
-   reg64 |= reg;
+   status = readl(gpio_dev->base + WAKE_INT_STATUS_REG1);
+   status <<= 32;
+   status |= readl(gpio_dev->base + WAKE_INT_STATUS_REG0);
raw_spin_unlock_irqrestore(_dev->lock, flags);
 
-   /*
-* first 46 bits indicates interrupt status.
-* one bit represents four interrupt sources.
-   */
-   for (off = 0; off < 46 ; off++) {
-   if (reg64 & BIT(off)) {
-   for (i = 0; i < 4; i++) {
-   pin_reg = readl(gpio_dev->base +
-   (off * 4 + i) * 4);
-   if ((pin_reg & BIT(INTERRUPT_STS_OFF)) ||
-   (pin_reg & BIT(WAKE_STS_OFF))) {
-   irq = irq_find_mapping(gc->irqdomain,
-   off * 4 + i);
-   generic_handle_irq(irq);
-   writel(pin_reg,
-   gpio_dev->base
-   + (off * 4 + i) * 4);
-   handled++;
-   }
-   }
+   /* Bit 0-45 contain the relevant status bits */
+   status &= (1ULL << 46) - 1;
+   regs = gpio_dev->base;
+   for (mask = 1, irqnr = 0; status; mask <<= 1, regs += 4, irqnr += 4) {
+   if (!(status & mask))
+   continue;
+   status &= ~mask;
+
+   /* Each status bit covers four pins */
+   for (i = 0; i < 4; i++) {
+   regval = readl(regs 

[PATCH] selftests/ftrace: Add a testcase for many kprobe events

[Masami Hiramatsu]

Add a testcase to test kprobes via ftrace interface
with many concurrent kprobe events.

This tries to add many kprobe events (up to 256) on
kernel functions. To avoid making ftrace-based
kprobes (kprobes on fentry), it skips first N bytes
(on x86 N=5, on ppc or arm N=4) of function entry.
After that, it enables all those events, disable it,
and remove it.

Since the unoptimization buffer reclaiming will
be delayed, after removing events, it will wait
enough time.

Signed-off-by: Masami Hiramatsu 
Suggested-by: Steven Rostedt 
---
 This ensures following bug is fixed and no regression.

 https://lkml.org/lkml/2017/5/25/218
---
 .../ftrace/test.d/kprobe/multiple_kprobes.tc   |   21 
 1 file changed, 21 insertions(+)
 create mode 100644 
tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc

diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc 
b/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
new file mode 100644
index 000..f4d1ff7
--- /dev/null
+++ b/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
@@ -0,0 +1,21 @@
+#!/bin/sh
+# description: Register/unregister many kprobe events
+
+# ftrace fentry skip size depends on the machine architecture.
+# Currently HAVE_KPROBES_ON_FTRACE defined on x86 and powerpc
+case `uname -m` in
+  x86_64|i[3456]86) OFFS=5;;
+  ppc*) OFFS=4;;
+  *) OFFS=0;;
+esac
+
+echo "Setup up to 256 kprobes"
+grep t /proc/kallsyms | cut -f3 -d" " | grep -v .*\\..* | \
+head -n 256 | while read i; do echo p ${i}+${OFFS} ; done > kprobe_events ||:
+
+echo 1 > events/kprobes/enable
+echo 0 > events/kprobes/enable
+echo > kprobe_events
+echo "Waiting for unoptimizing & freeing"
+sleep 5
+echo "Done"

[PATCH] selftests/ftrace: Add a testcase for many kprobe events

[Masami Hiramatsu]

Add a testcase to test kprobes via ftrace interface
with many concurrent kprobe events.

This tries to add many kprobe events (up to 256) on
kernel functions. To avoid making ftrace-based
kprobes (kprobes on fentry), it skips first N bytes
(on x86 N=5, on ppc or arm N=4) of function entry.
After that, it enables all those events, disable it,
and remove it.

Since the unoptimization buffer reclaiming will
be delayed, after removing events, it will wait
enough time.

Signed-off-by: Masami Hiramatsu 
Suggested-by: Steven Rostedt 
---
 This ensures following bug is fixed and no regression.

 https://lkml.org/lkml/2017/5/25/218
---
 .../ftrace/test.d/kprobe/multiple_kprobes.tc   |   21 
 1 file changed, 21 insertions(+)
 create mode 100644 
tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc

diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc 
b/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
new file mode 100644
index 000..f4d1ff7
--- /dev/null
+++ b/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
@@ -0,0 +1,21 @@
+#!/bin/sh
+# description: Register/unregister many kprobe events
+
+# ftrace fentry skip size depends on the machine architecture.
+# Currently HAVE_KPROBES_ON_FTRACE defined on x86 and powerpc
+case `uname -m` in
+  x86_64|i[3456]86) OFFS=5;;
+  ppc*) OFFS=4;;
+  *) OFFS=0;;
+esac
+
+echo "Setup up to 256 kprobes"
+grep t /proc/kallsyms | cut -f3 -d" " | grep -v .*\\..* | \
+head -n 256 | while read i; do echo p ${i}+${OFFS} ; done > kprobe_events ||:
+
+echo 1 > events/kprobes/enable
+echo 0 > events/kprobes/enable
+echo > kprobe_events
+echo "Waiting for unoptimizing & freeing"
+sleep 5
+echo "Done"

Re: [Patch v2] mm/vmscan: fix unsequenced modification and access warning

[Nick Desaulniers]

On Tue, May 16, 2017 at 10:27:46AM +0200, Michal Hocko wrote:
> I guess it is worth reporting this to clang bugzilla. Could you take
> care of that Nick?

>From https://bugs.llvm.org//show_bug.cgi?id=33065#c5
it seems that this is indeed a sequence bug in the previous version of
this code and not a compiler bug.  You can read that response for the
properly-cited wording but my TL;DR/understanding is for the given code:

struct foo bar = {
  .a = (c = 0),
  .b = c,
};

That the compiler is allowed to reorder the initializations of bar.a and
bar.b, so what the value of c here might not be what you expect.

Re: [Patch v2] mm/vmscan: fix unsequenced modification and access warning

[Nick Desaulniers]

On Tue, May 16, 2017 at 10:27:46AM +0200, Michal Hocko wrote:
> I guess it is worth reporting this to clang bugzilla. Could you take
> care of that Nick?

>From https://bugs.llvm.org//show_bug.cgi?id=33065#c5
it seems that this is indeed a sequence bug in the previous version of
this code and not a compiler bug.  You can read that response for the
properly-cited wording but my TL;DR/understanding is for the given code:

struct foo bar = {
  .a = (c = 0),
  .b = c,
};

That the compiler is allowed to reorder the initializations of bar.a and
bar.b, so what the value of c here might not be what you expect.

[git pull] drm fixes for v4.12-rc3

[Dave Airlie]

Hi Linus,

Not a whole lot happening here, a set of amdgpu fixes and one core
deadlock fix, and some misc drivers fixes.

Dave.


The following changes since commit 08332893e37af6ae779367e78e444f8f9571511d:

  Linux 4.12-rc2 (2017-05-21 19:30:23 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.12-rc3

for you to fetch changes up to bc1f0e04da20473d6feab0cd9ac638a348d5:

  Merge branch 'drm-fixes-4.12' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2017-05-26
11:51:55 +1000)


misc and amdgpu fixes


Alex Deucher (4):
  drm/amdgpu/ci: disable mclk switching for high refresh rates (v2)
  drm/radeon/ci: disable mclk switching for high refresh rates (v2)
  drm/amd/powerplay/smu7: add vblank check for mclk switching (v2)
  drm/amd/powerplay/smu7: disable mclk switching for high refresh rates

Christian König (1):
  drm/amdgpu: fix fundamental suspend/resume issue

Chunming Zhou (1):
  drm/amdgpu: fix NULL pointer panic of emit_gds_switch

Dan Carpenter (1):
  drm/amd/powerplay: fix a signedness bugs

Daniel Vetter (1):
  drm: Fix deadlock retry loop in page_flip_ioctl

Dave Airlie (2):
  Merge tag 'drm-misc-fixes-2017-05-25' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
  Merge branch 'drm-fixes-4.12' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Gabriel Krisman Bertazi (1):
  drm: qxl: Delay entering atomic context during cursor update

Lukas Wunner (1):
  drm/radeon: Fix oops upon driver load on PowerXpress laptops

Lyude (1):
  drm/radeon: Unbreak HPD handling for r600+

Patrik Jakobsson (1):
  drm/gma500/psb: Actually use VBT mode when it is found

Rex Zhu (1):
  drm/amdgpu: fix null point error when rmmod amdgpu.

 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c |  7 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 24 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  1 +
 drivers/gpu/drm/amd/amdgpu/ci_dpm.c|  6 
 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c  | 15 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  | 15 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  | 15 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c  | 16 ++-
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   | 32 +++---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c |  2 +-
 drivers/gpu/drm/drm_plane.c|  5 ++--
 drivers/gpu/drm/gma500/psb_intel_lvds.c| 18 +++-
 drivers/gpu/drm/qxl/qxl_display.c  |  4 +--
 drivers/gpu/drm/radeon/ci_dpm.c|  6 
 drivers/gpu/drm/radeon/cik.c   |  4 +--
 drivers/gpu/drm/radeon/evergreen.c |  4 +--
 drivers/gpu/drm/radeon/r600.c  |  2 +-
 drivers/gpu/drm/radeon/radeon_kms.c|  2 +-
 drivers/gpu/drm/radeon/si.c|  4 +--
 19 files changed, 102 insertions(+), 80 deletions(-)

[git pull] drm fixes for v4.12-rc3

[Dave Airlie]

Hi Linus,

Not a whole lot happening here, a set of amdgpu fixes and one core
deadlock fix, and some misc drivers fixes.

Dave.


The following changes since commit 08332893e37af6ae779367e78e444f8f9571511d:

  Linux 4.12-rc2 (2017-05-21 19:30:23 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.12-rc3

for you to fetch changes up to bc1f0e04da20473d6feab0cd9ac638a348d5:

  Merge branch 'drm-fixes-4.12' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2017-05-26
11:51:55 +1000)


misc and amdgpu fixes


Alex Deucher (4):
  drm/amdgpu/ci: disable mclk switching for high refresh rates (v2)
  drm/radeon/ci: disable mclk switching for high refresh rates (v2)
  drm/amd/powerplay/smu7: add vblank check for mclk switching (v2)
  drm/amd/powerplay/smu7: disable mclk switching for high refresh rates

Christian König (1):
  drm/amdgpu: fix fundamental suspend/resume issue

Chunming Zhou (1):
  drm/amdgpu: fix NULL pointer panic of emit_gds_switch

Dan Carpenter (1):
  drm/amd/powerplay: fix a signedness bugs

Daniel Vetter (1):
  drm: Fix deadlock retry loop in page_flip_ioctl

Dave Airlie (2):
  Merge tag 'drm-misc-fixes-2017-05-25' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
  Merge branch 'drm-fixes-4.12' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Gabriel Krisman Bertazi (1):
  drm: qxl: Delay entering atomic context during cursor update

Lukas Wunner (1):
  drm/radeon: Fix oops upon driver load on PowerXpress laptops

Lyude (1):
  drm/radeon: Unbreak HPD handling for r600+

Patrik Jakobsson (1):
  drm/gma500/psb: Actually use VBT mode when it is found

Rex Zhu (1):
  drm/amdgpu: fix null point error when rmmod amdgpu.

 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c |  7 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 24 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  1 +
 drivers/gpu/drm/amd/amdgpu/ci_dpm.c|  6 
 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c  | 15 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  | 15 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  | 15 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c  | 16 ++-
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   | 32 +++---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c |  2 +-
 drivers/gpu/drm/drm_plane.c|  5 ++--
 drivers/gpu/drm/gma500/psb_intel_lvds.c| 18 +++-
 drivers/gpu/drm/qxl/qxl_display.c  |  4 +--
 drivers/gpu/drm/radeon/ci_dpm.c|  6 
 drivers/gpu/drm/radeon/cik.c   |  4 +--
 drivers/gpu/drm/radeon/evergreen.c |  4 +--
 drivers/gpu/drm/radeon/r600.c  |  2 +-
 drivers/gpu/drm/radeon/radeon_kms.c|  2 +-
 drivers/gpu/drm/radeon/si.c|  4 +--
 19 files changed, 102 insertions(+), 80 deletions(-)

Re: [PATCH v5 06/10] drm/bridge: analogix-anx78xx: Use bridge->mode_valid() callback

[Archit Taneja]

On 05/25/2017 07:49 PM, Jose Abreu wrote:

Now that we have a callback to check if bridge supports a given mode
we can use it in Analogix bridge so that we restrict the number of
probbed modes to the ones we can actually display.

Also, there is no need to use mode_fixup() callback as mode_valid()
will handle the mode validation.



Reviewed-by: Archit Taneja 


NOTE: Only compile tested.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Daniel Vetter 
Cc: Archit Taneja 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: David Airlie 
---
 drivers/gpu/drm/bridge/analogix-anx78xx.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index a2a8236..cf69a1c 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -1061,18 +1061,17 @@ static int anx78xx_bridge_attach(struct drm_bridge 
*bridge)
return 0;
 }

-static bool anx78xx_bridge_mode_fixup(struct drm_bridge *bridge,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+enum drm_mode_status anx78xx_bridge_mode_valid(struct drm_bridge *bridge,
+  const struct drm_display_mode 
*mode)
 {
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
-   return false;
+   return MODE_NO_INTERLACE;

/* Max 1200p at 5.4 Ghz, one lane */
if (mode->clock > 154000)
-   return false;
+   return MODE_CLOCK_HIGH;

-   return true;
+   return MODE_OK;
 }

 static void anx78xx_bridge_disable(struct drm_bridge *bridge)
@@ -1129,7 +1128,7 @@ static void anx78xx_bridge_enable(struct drm_bridge 
*bridge)

 static const struct drm_bridge_funcs anx78xx_bridge_funcs = {
.attach = anx78xx_bridge_attach,
-   .mode_fixup = anx78xx_bridge_mode_fixup,
+   .mode_valid = anx78xx_bridge_mode_valid,
.disable = anx78xx_bridge_disable,
.mode_set = anx78xx_bridge_mode_set,
.enable = anx78xx_bridge_enable,



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v5 06/10] drm/bridge: analogix-anx78xx: Use bridge->mode_valid() callback

[Archit Taneja]

On 05/25/2017 07:49 PM, Jose Abreu wrote:

Now that we have a callback to check if bridge supports a given mode
we can use it in Analogix bridge so that we restrict the number of
probbed modes to the ones we can actually display.

Also, there is no need to use mode_fixup() callback as mode_valid()
will handle the mode validation.



Reviewed-by: Archit Taneja 


NOTE: Only compile tested.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Daniel Vetter 
Cc: Archit Taneja 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: David Airlie 
---
 drivers/gpu/drm/bridge/analogix-anx78xx.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index a2a8236..cf69a1c 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -1061,18 +1061,17 @@ static int anx78xx_bridge_attach(struct drm_bridge 
*bridge)
return 0;
 }

-static bool anx78xx_bridge_mode_fixup(struct drm_bridge *bridge,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+enum drm_mode_status anx78xx_bridge_mode_valid(struct drm_bridge *bridge,
+  const struct drm_display_mode 
*mode)
 {
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
-   return false;
+   return MODE_NO_INTERLACE;

/* Max 1200p at 5.4 Ghz, one lane */
if (mode->clock > 154000)
-   return false;
+   return MODE_CLOCK_HIGH;

-   return true;
+   return MODE_OK;
 }

 static void anx78xx_bridge_disable(struct drm_bridge *bridge)
@@ -1129,7 +1128,7 @@ static void anx78xx_bridge_enable(struct drm_bridge 
*bridge)

 static const struct drm_bridge_funcs anx78xx_bridge_funcs = {
.attach = anx78xx_bridge_attach,
-   .mode_fixup = anx78xx_bridge_mode_fixup,
+   .mode_valid = anx78xx_bridge_mode_valid,
.disable = anx78xx_bridge_disable,
.mode_set = anx78xx_bridge_mode_set,
.enable = anx78xx_bridge_enable,



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging

[Kevin Easton]

On Thu, May 25, 2017 at 05:40:16PM -0700, Andy Lutomirski wrote:
> On Thu, May 25, 2017 at 4:24 PM, Linus Torvalds
>  wrote:
> > On Thu, May 25, 2017 at 1:33 PM, Kirill A. Shutemov
> >  wrote:
> >> Here' my first attempt to bring boot-time between 4- and 5-level paging.
> >> It looks not too terrible to me. I've expected it to be worse.
> >
> > If I read this right, you just made it a global on/off thing.
> >
> > May I suggest possibly a different model entirely? Can you make it a
> > per-mm flag instead?
> >
> > And then we
> >
> >  (a) make all kthreads use the 4-level page tables
> >
> >  (b) which means that all the init code uses the 4-level page tables
> >
> >  (c) which means that all those checks for "start_secondary" etc can
> > just go away, because those all run with 4-level page tables.
> >
> > Or is it just much too expensive to switch between 4-level and 5-level
> > paging at run-time?
> >
> 
> Even ignoring expensiveness, I'm not convinced it's practical.  AFAICT
> you can't atomically switch the paging mode and CR3, so either you
> need some magic page table with trampoline that works in both modes
> (which is presumably doable with some trickery) or you need to flip
> paging off.  Good luck if an NMI hits in the mean time.  There was
> code like that once upon a time for EFI mixed mode, but it got deleted
> due to triple-faults.

According to Intel's documentation you pretty much have to disable
paging anyway:

"The processor allows software to modify CR4.LA57 only outside of IA-32e
mode. In IA-32e mode, an attempt to modify CR4.LA57 using the MOV CR
instruction causes a general-protection exception (#GP)."

(If it weren't for that, maybe you could point the last entry in the PML4
at the PML4 itself, so it also works as a PML5 for accessing kernel
addresses? And of course make sure nothing gets loaded above 
0xff80).

- Kevin

Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging

[Kevin Easton]

On Thu, May 25, 2017 at 05:40:16PM -0700, Andy Lutomirski wrote:
> On Thu, May 25, 2017 at 4:24 PM, Linus Torvalds
>  wrote:
> > On Thu, May 25, 2017 at 1:33 PM, Kirill A. Shutemov
> >  wrote:
> >> Here' my first attempt to bring boot-time between 4- and 5-level paging.
> >> It looks not too terrible to me. I've expected it to be worse.
> >
> > If I read this right, you just made it a global on/off thing.
> >
> > May I suggest possibly a different model entirely? Can you make it a
> > per-mm flag instead?
> >
> > And then we
> >
> >  (a) make all kthreads use the 4-level page tables
> >
> >  (b) which means that all the init code uses the 4-level page tables
> >
> >  (c) which means that all those checks for "start_secondary" etc can
> > just go away, because those all run with 4-level page tables.
> >
> > Or is it just much too expensive to switch between 4-level and 5-level
> > paging at run-time?
> >
> 
> Even ignoring expensiveness, I'm not convinced it's practical.  AFAICT
> you can't atomically switch the paging mode and CR3, so either you
> need some magic page table with trampoline that works in both modes
> (which is presumably doable with some trickery) or you need to flip
> paging off.  Good luck if an NMI hits in the mean time.  There was
> code like that once upon a time for EFI mixed mode, but it got deleted
> due to triple-faults.

According to Intel's documentation you pretty much have to disable
paging anyway:

"The processor allows software to modify CR4.LA57 only outside of IA-32e
mode. In IA-32e mode, an attempt to modify CR4.LA57 using the MOV CR
instruction causes a general-protection exception (#GP)."

(If it weren't for that, maybe you could point the last entry in the PML4
at the PML4 itself, so it also works as a PML5 for accessing kernel
addresses? And of course make sure nothing gets loaded above 
0xff80).

- Kevin

Re: [PATCH v5 02/10] drm: Introduce drm_bridge_mode_valid()

[Archit Taneja]

On 05/25/2017 07:49 PM, Jose Abreu wrote:

Introduce a new helper function which calls mode_valid() callback
for all bridges in an encoder chain.



Reviewed-by: Archit Taneja 


Signed-off-by: Jose Abreu 
Reviewed-by: Daniel Vetter 
Cc: Carlos Palminha 
Cc: Ville Syrjälä 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
Cc: Laurent Pinchart 
---
 drivers/gpu/drm/drm_bridge.c | 33 +
 include/drm/drm_bridge.h |  2 ++
 2 files changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 86a7637..dc8cdfe 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -206,6 +206,39 @@ bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
 EXPORT_SYMBOL(drm_bridge_mode_fixup);

 /**
+ * drm_bridge_mode_valid - validate the mode against all bridges in the
+ *encoder chain.
+ * @bridge: bridge control structure
+ * @mode: desired mode to be validated
+ *
+ * Calls _bridge_funcs.mode_valid for all the bridges in the encoder
+ * chain, starting from the first bridge to the last. If at least one bridge
+ * does not accept the mode the function returns the error code.
+ *
+ * Note: the bridge passed should be the one closest to the encoder.
+ *
+ * RETURNS:
+ * MODE_OK on success, drm_mode_status Enum error code on failure
+ */
+enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge,
+  const struct drm_display_mode *mode)
+{
+   enum drm_mode_status ret = MODE_OK;
+
+   if (!bridge)
+   return ret;
+
+   if (bridge->funcs->mode_valid)
+   ret = bridge->funcs->mode_valid(bridge, mode);
+
+   if (ret != MODE_OK)
+   return ret;
+
+   return drm_bridge_mode_valid(bridge->next, mode);
+}
+EXPORT_SYMBOL(drm_bridge_mode_valid);
+
+/**
  * drm_bridge_disable - disables all bridges in the encoder chain
  * @bridge: bridge control structure
  *
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 00c6c36..8358eb3 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -233,6 +233,8 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct 
drm_bridge *bridge,
 bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
+enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge,
+  const struct drm_display_mode *mode);
 void drm_bridge_disable(struct drm_bridge *bridge);
 void drm_bridge_post_disable(struct drm_bridge *bridge);
 void drm_bridge_mode_set(struct drm_bridge *bridge,



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v5 02/10] drm: Introduce drm_bridge_mode_valid()

[Archit Taneja]

On 05/25/2017 07:49 PM, Jose Abreu wrote:

Introduce a new helper function which calls mode_valid() callback
for all bridges in an encoder chain.



Reviewed-by: Archit Taneja 


Signed-off-by: Jose Abreu 
Reviewed-by: Daniel Vetter 
Cc: Carlos Palminha 
Cc: Ville Syrjälä 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
Cc: Laurent Pinchart 
---
 drivers/gpu/drm/drm_bridge.c | 33 +
 include/drm/drm_bridge.h |  2 ++
 2 files changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 86a7637..dc8cdfe 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -206,6 +206,39 @@ bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
 EXPORT_SYMBOL(drm_bridge_mode_fixup);

 /**
+ * drm_bridge_mode_valid - validate the mode against all bridges in the
+ *encoder chain.
+ * @bridge: bridge control structure
+ * @mode: desired mode to be validated
+ *
+ * Calls _bridge_funcs.mode_valid for all the bridges in the encoder
+ * chain, starting from the first bridge to the last. If at least one bridge
+ * does not accept the mode the function returns the error code.
+ *
+ * Note: the bridge passed should be the one closest to the encoder.
+ *
+ * RETURNS:
+ * MODE_OK on success, drm_mode_status Enum error code on failure
+ */
+enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge,
+  const struct drm_display_mode *mode)
+{
+   enum drm_mode_status ret = MODE_OK;
+
+   if (!bridge)
+   return ret;
+
+   if (bridge->funcs->mode_valid)
+   ret = bridge->funcs->mode_valid(bridge, mode);
+
+   if (ret != MODE_OK)
+   return ret;
+
+   return drm_bridge_mode_valid(bridge->next, mode);
+}
+EXPORT_SYMBOL(drm_bridge_mode_valid);
+
+/**
  * drm_bridge_disable - disables all bridges in the encoder chain
  * @bridge: bridge control structure
  *
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 00c6c36..8358eb3 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -233,6 +233,8 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct 
drm_bridge *bridge,
 bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
+enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge,
+  const struct drm_display_mode *mode);
 void drm_bridge_disable(struct drm_bridge *bridge);
 void drm_bridge_post_disable(struct drm_bridge *bridge);
 void drm_bridge_mode_set(struct drm_bridge *bridge,



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 5/5] drm: dw-hdmi-i2s: add .get_dai_id callback for ALSA SoC

[Archit Taneja]

On 05/26/2017 09:46 AM, Archit Taneja wrote:

Hi,

On 05/25/2017 05:04 AM, Kuninori Morimoto wrote:


Hi Mark
Cc: DRM maintainer


ALSA SoC needs to know connected DAI ID for probing.
It is not a big problem if device/driver was only for sound,
but getting DAI ID will be difficult if device includes both
Video/Sound, like HDMI.


As far as I understand what's going on with the graph code this seems to
make sense to me.  How do we want to go about handling the patch?


This is comment to me ? or DRM maintainer ?

If to me, any case (pickup by Mark, or by DRM maintainer) is OK for me


I'll pick it up for drm-misc-next.


Ah, I just saw the dependence on the previous patches.

Mark,

Please feel free to pull this to the asoc tree. You can add my Ack:

Acked-by: Archit Taneja 

Thanks,
Archit



Thanks,
Archit



Best regards
---
Kuninori Morimoto





--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 5/5] drm: dw-hdmi-i2s: add .get_dai_id callback for ALSA SoC

[Archit Taneja]

On 05/26/2017 09:46 AM, Archit Taneja wrote:

Hi,

On 05/25/2017 05:04 AM, Kuninori Morimoto wrote:


Hi Mark
Cc: DRM maintainer


ALSA SoC needs to know connected DAI ID for probing.
It is not a big problem if device/driver was only for sound,
but getting DAI ID will be difficult if device includes both
Video/Sound, like HDMI.


As far as I understand what's going on with the graph code this seems to
make sense to me.  How do we want to go about handling the patch?


This is comment to me ? or DRM maintainer ?

If to me, any case (pickup by Mark, or by DRM maintainer) is OK for me


I'll pick it up for drm-misc-next.


Ah, I just saw the dependence on the previous patches.

Mark,

Please feel free to pull this to the asoc tree. You can add my Ack:

Acked-by: Archit Taneja 

Thanks,
Archit



Thanks,
Archit



Best regards
---
Kuninori Morimoto





--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

[Xunlei Pang]

On 04/19/2017 at 05:21 AM, Tom Lendacky wrote:
> Provide support so that kexec can be used to boot a kernel when SME is
> enabled.
>
> Support is needed to allocate pages for kexec without encryption.  This
> is needed in order to be able to reboot in the kernel in the same manner
> as originally booted.

Hi Tom,

Looks like kdump will break, I didn't see the similar handling for kdump cases, 
see kernel:
kimage_alloc_crash_control_pages(), kimage_load_crash_segment(), etc.

We need to support kdump with SME, kdump 
kernel/initramfs/purgatory/elfcorehdr/etc
are all loaded into the reserved memory(see crashkernel=X) by userspace 
kexec-tools.
I think a straightforward way would be to mark the whole reserved memory range 
without
encryption before loading all the kexec segments for kdump, I guess we can 
handle this
easily in arch_kexec_unprotect_crashkres().

Moreover, now that "elfcorehdr=X" is left as decrypted, it needs to be remapped 
to the
encrypted data.

Regards,
Xunlei

>
> Additionally, when shutting down all of the CPUs we need to be sure to
> flush the caches and then halt. This is needed when booting from a state
> where SME was not active into a state where SME is active (or vice-versa).
> Without these steps, it is possible for cache lines to exist for the same
> physical location but tagged both with and without the encryption bit. This
> can cause random memory corruption when caches are flushed depending on
> which cacheline is written last.
>
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/init.h  |1 +
>  arch/x86/include/asm/irqflags.h  |5 +
>  arch/x86/include/asm/kexec.h |8 
>  arch/x86/include/asm/pgtable_types.h |1 +
>  arch/x86/kernel/machine_kexec_64.c   |   35 
> +-
>  arch/x86/kernel/process.c|   26 +++--
>  arch/x86/mm/ident_map.c  |   11 +++
>  include/linux/kexec.h|   14 ++
>  kernel/kexec_core.c  |7 +++
>  9 files changed, 101 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/include/asm/init.h b/arch/x86/include/asm/init.h
> index 737da62..b2ec511 100644
> --- a/arch/x86/include/asm/init.h
> +++ b/arch/x86/include/asm/init.h
> @@ -6,6 +6,7 @@ struct x86_mapping_info {
>   void *context;   /* context for alloc_pgt_page */
>   unsigned long pmd_flag;  /* page flag for PMD entry */
>   unsigned long offset;/* ident mapping offset */
> + unsigned long kernpg_flag;   /* kernel pagetable flag override */
>  };
>  
>  int kernel_ident_mapping_init(struct x86_mapping_info *info, pgd_t *pgd_page,
> diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
> index ac7692d..38b5920 100644
> --- a/arch/x86/include/asm/irqflags.h
> +++ b/arch/x86/include/asm/irqflags.h
> @@ -58,6 +58,11 @@ static inline __cpuidle void native_halt(void)
>   asm volatile("hlt": : :"memory");
>  }
>  
> +static inline __cpuidle void native_wbinvd_halt(void)
> +{
> + asm volatile("wbinvd; hlt" : : : "memory");
> +}
> +
>  #endif
>  
>  #ifdef CONFIG_PARAVIRT
> diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
> index 70ef205..e8183ac 100644
> --- a/arch/x86/include/asm/kexec.h
> +++ b/arch/x86/include/asm/kexec.h
> @@ -207,6 +207,14 @@ struct kexec_entry64_regs {
>   uint64_t r15;
>   uint64_t rip;
>  };
> +
> +extern int arch_kexec_post_alloc_pages(void *vaddr, unsigned int pages,
> +gfp_t gfp);
> +#define arch_kexec_post_alloc_pages arch_kexec_post_alloc_pages
> +
> +extern void arch_kexec_pre_free_pages(void *vaddr, unsigned int pages);
> +#define arch_kexec_pre_free_pages arch_kexec_pre_free_pages
> +
>  #endif
>  
>  typedef void crash_vmclear_fn(void);
> diff --git a/arch/x86/include/asm/pgtable_types.h 
> b/arch/x86/include/asm/pgtable_types.h
> index ce8cb1c..0f326f4 100644
> --- a/arch/x86/include/asm/pgtable_types.h
> +++ b/arch/x86/include/asm/pgtable_types.h
> @@ -213,6 +213,7 @@ enum page_cache_mode {
>  #define PAGE_KERNEL  __pgprot(__PAGE_KERNEL | _PAGE_ENC)
>  #define PAGE_KERNEL_RO   __pgprot(__PAGE_KERNEL_RO | _PAGE_ENC)
>  #define PAGE_KERNEL_EXEC __pgprot(__PAGE_KERNEL_EXEC | _PAGE_ENC)
> +#define PAGE_KERNEL_EXEC_NOENC   __pgprot(__PAGE_KERNEL_EXEC)
>  #define PAGE_KERNEL_RX   __pgprot(__PAGE_KERNEL_RX | _PAGE_ENC)
>  #define PAGE_KERNEL_NOCACHE  __pgprot(__PAGE_KERNEL_NOCACHE | _PAGE_ENC)
>  #define PAGE_KERNEL_LARGE__pgprot(__PAGE_KERNEL_LARGE | _PAGE_ENC)
> diff --git a/arch/x86/kernel/machine_kexec_64.c 
> b/arch/x86/kernel/machine_kexec_64.c
> index 085c3b3..11c0ca9 100644
> --- a/arch/x86/kernel/machine_kexec_64.c
> +++ b/arch/x86/kernel/machine_kexec_64.c
> @@ -86,7 +86,7 @@ static int init_transition_pgtable(struct kimage *image, 
> pgd_t *pgd)
>  

Re: [PATCH 5/5] drm: dw-hdmi-i2s: add .get_dai_id callback for ALSA SoC

[Archit Taneja]

Hi,

On 05/25/2017 05:04 AM, Kuninori Morimoto wrote:


Hi Mark
Cc: DRM maintainer


ALSA SoC needs to know connected DAI ID for probing.
It is not a big problem if device/driver was only for sound,
but getting DAI ID will be difficult if device includes both
Video/Sound, like HDMI.


As far as I understand what's going on with the graph code this seems to
make sense to me.  How do we want to go about handling the patch?


This is comment to me ? or DRM maintainer ?

If to me, any case (pickup by Mark, or by DRM maintainer) is OK for me


I'll pick it up for drm-misc-next.

Thanks,
Archit



Best regards
---
Kuninori Morimoto



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

[Xunlei Pang]

On 04/19/2017 at 05:21 AM, Tom Lendacky wrote:
> Provide support so that kexec can be used to boot a kernel when SME is
> enabled.
>
> Support is needed to allocate pages for kexec without encryption.  This
> is needed in order to be able to reboot in the kernel in the same manner
> as originally booted.

Hi Tom,

Looks like kdump will break, I didn't see the similar handling for kdump cases, 
see kernel:
kimage_alloc_crash_control_pages(), kimage_load_crash_segment(), etc.

We need to support kdump with SME, kdump 
kernel/initramfs/purgatory/elfcorehdr/etc
are all loaded into the reserved memory(see crashkernel=X) by userspace 
kexec-tools.
I think a straightforward way would be to mark the whole reserved memory range 
without
encryption before loading all the kexec segments for kdump, I guess we can 
handle this
easily in arch_kexec_unprotect_crashkres().

Moreover, now that "elfcorehdr=X" is left as decrypted, it needs to be remapped 
to the
encrypted data.

Regards,
Xunlei

>
> Additionally, when shutting down all of the CPUs we need to be sure to
> flush the caches and then halt. This is needed when booting from a state
> where SME was not active into a state where SME is active (or vice-versa).
> Without these steps, it is possible for cache lines to exist for the same
> physical location but tagged both with and without the encryption bit. This
> can cause random memory corruption when caches are flushed depending on
> which cacheline is written last.
>
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/init.h  |1 +
>  arch/x86/include/asm/irqflags.h  |5 +
>  arch/x86/include/asm/kexec.h |8 
>  arch/x86/include/asm/pgtable_types.h |1 +
>  arch/x86/kernel/machine_kexec_64.c   |   35 
> +-
>  arch/x86/kernel/process.c|   26 +++--
>  arch/x86/mm/ident_map.c  |   11 +++
>  include/linux/kexec.h|   14 ++
>  kernel/kexec_core.c  |7 +++
>  9 files changed, 101 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/include/asm/init.h b/arch/x86/include/asm/init.h
> index 737da62..b2ec511 100644
> --- a/arch/x86/include/asm/init.h
> +++ b/arch/x86/include/asm/init.h
> @@ -6,6 +6,7 @@ struct x86_mapping_info {
>   void *context;   /* context for alloc_pgt_page */
>   unsigned long pmd_flag;  /* page flag for PMD entry */
>   unsigned long offset;/* ident mapping offset */
> + unsigned long kernpg_flag;   /* kernel pagetable flag override */
>  };
>  
>  int kernel_ident_mapping_init(struct x86_mapping_info *info, pgd_t *pgd_page,
> diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
> index ac7692d..38b5920 100644
> --- a/arch/x86/include/asm/irqflags.h
> +++ b/arch/x86/include/asm/irqflags.h
> @@ -58,6 +58,11 @@ static inline __cpuidle void native_halt(void)
>   asm volatile("hlt": : :"memory");
>  }
>  
> +static inline __cpuidle void native_wbinvd_halt(void)
> +{
> + asm volatile("wbinvd; hlt" : : : "memory");
> +}
> +
>  #endif
>  
>  #ifdef CONFIG_PARAVIRT
> diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
> index 70ef205..e8183ac 100644
> --- a/arch/x86/include/asm/kexec.h
> +++ b/arch/x86/include/asm/kexec.h
> @@ -207,6 +207,14 @@ struct kexec_entry64_regs {
>   uint64_t r15;
>   uint64_t rip;
>  };
> +
> +extern int arch_kexec_post_alloc_pages(void *vaddr, unsigned int pages,
> +gfp_t gfp);
> +#define arch_kexec_post_alloc_pages arch_kexec_post_alloc_pages
> +
> +extern void arch_kexec_pre_free_pages(void *vaddr, unsigned int pages);
> +#define arch_kexec_pre_free_pages arch_kexec_pre_free_pages
> +
>  #endif
>  
>  typedef void crash_vmclear_fn(void);
> diff --git a/arch/x86/include/asm/pgtable_types.h 
> b/arch/x86/include/asm/pgtable_types.h
> index ce8cb1c..0f326f4 100644
> --- a/arch/x86/include/asm/pgtable_types.h
> +++ b/arch/x86/include/asm/pgtable_types.h
> @@ -213,6 +213,7 @@ enum page_cache_mode {
>  #define PAGE_KERNEL  __pgprot(__PAGE_KERNEL | _PAGE_ENC)
>  #define PAGE_KERNEL_RO   __pgprot(__PAGE_KERNEL_RO | _PAGE_ENC)
>  #define PAGE_KERNEL_EXEC __pgprot(__PAGE_KERNEL_EXEC | _PAGE_ENC)
> +#define PAGE_KERNEL_EXEC_NOENC   __pgprot(__PAGE_KERNEL_EXEC)
>  #define PAGE_KERNEL_RX   __pgprot(__PAGE_KERNEL_RX | _PAGE_ENC)
>  #define PAGE_KERNEL_NOCACHE  __pgprot(__PAGE_KERNEL_NOCACHE | _PAGE_ENC)
>  #define PAGE_KERNEL_LARGE__pgprot(__PAGE_KERNEL_LARGE | _PAGE_ENC)
> diff --git a/arch/x86/kernel/machine_kexec_64.c 
> b/arch/x86/kernel/machine_kexec_64.c
> index 085c3b3..11c0ca9 100644
> --- a/arch/x86/kernel/machine_kexec_64.c
> +++ b/arch/x86/kernel/machine_kexec_64.c
> @@ -86,7 +86,7 @@ static int init_transition_pgtable(struct kimage *image, 
> pgd_t *pgd)
>   set_pmd(pmd, 

Re: [PATCH 5/5] drm: dw-hdmi-i2s: add .get_dai_id callback for ALSA SoC

[Archit Taneja]

Hi,

On 05/25/2017 05:04 AM, Kuninori Morimoto wrote:


Hi Mark
Cc: DRM maintainer


ALSA SoC needs to know connected DAI ID for probing.
It is not a big problem if device/driver was only for sound,
but getting DAI ID will be difficult if device includes both
Video/Sound, like HDMI.


As far as I understand what's going on with the graph code this seems to
make sense to me.  How do we want to go about handling the patch?


This is comment to me ? or DRM maintainer ?

If to me, any case (pickup by Mark, or by DRM maintainer) is OK for me


I'll pick it up for drm-misc-next.

Thanks,
Archit



Best regards
---
Kuninori Morimoto



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] mm/zsmalloc: fix -Wunneeded-internal-declaration warning

[Nick Desaulniers]

On Wed, May 24, 2017 at 05:16:18PM +0900, Sergey Senozhatsky wrote:
> On (05/23/17 22:38), Nick Desaulniers wrote:
> > Fixes the following warning, found with Clang:
> well, no objections from my side. MM seems to be getting more and
> more `__maybe_unused' annotations because of clang.

Indeed, but does find bugs when this warning pops up unexpected (unlike
in this particular instance). See:

https://patchwork.kernel.org/patch/9738897/
https://www.spinics.net/lists/intel-gfx/msg128737.html

TL;DR
>>> You have actually uncovered a bug here where the call is not
>>> supposed to be optional in the first place.

Re: [PATCH] mm/zsmalloc: fix -Wunneeded-internal-declaration warning

[Nick Desaulniers]

On Wed, May 24, 2017 at 05:16:18PM +0900, Sergey Senozhatsky wrote:
> On (05/23/17 22:38), Nick Desaulniers wrote:
> > Fixes the following warning, found with Clang:
> well, no objections from my side. MM seems to be getting more and
> more `__maybe_unused' annotations because of clang.

Indeed, but does find bugs when this warning pops up unexpected (unlike
in this particular instance). See:

https://patchwork.kernel.org/patch/9738897/
https://www.spinics.net/lists/intel-gfx/msg128737.html

TL;DR
>>> You have actually uncovered a bug here where the call is not
>>> supposed to be optional in the first place.

Re: [PATCH] KVM: x86: dynamically allocate large struct in em_fxrstor

[Nick Desaulniers]

On Thu, May 25, 2017 at 04:07:08PM +0200, Paolo Bonzini wrote:
> I think we should do the fixup backwards.
> 
> That is:
> 
> - first do get_fpu
> 
> - if the fixup is necessary, i.e. ctxt->mode < X86EMUL_MODE_PROT64, do
> fxsave into 
> 
> - then do segmented_read_std with the correct size, which is
>   - offsetof(struct fxregs_state, xmm_space[16]), i.e. 416
> if ctxt->mode == X86EMUL_MODE_PROT64
>   - offsetof(struct fxregs_state, xmm_space[8]), i.e. 288
> if ctxt->mode < X86EMUL_MODE_PROT64 and CR4.OSFXSR=1
>   - offsetof(struct fxregs_state, xmm_space[0]), i.e. 160
> if ctxt->mode < X86EMUL_MODE_PROT64 and CR4.OSFXSR=0

but we still want to do a segmented_read_std with size 512 otherwise,
correct?

> - then check fx_state.mxcsr
> 
> - then do fxrstor

This sounds like we conditionally do the fxsave, but then always do the
fxrstor.  Is that ok? I guess the original code kind of does that as
well.

> - finally do put_fpu

Sounds straight forward.  I can see how fxsave and CR4.OSFXSR are
accessed in fxstor_fixup.  Is it ok to skip those memcpy's that would
otherwise occur when calling fxrstor_fixup() (which after these changes,
we would not be)?

Re: [PATCH] KVM: x86: dynamically allocate large struct in em_fxrstor

[Nick Desaulniers]

On Thu, May 25, 2017 at 04:07:08PM +0200, Paolo Bonzini wrote:
> I think we should do the fixup backwards.
> 
> That is:
> 
> - first do get_fpu
> 
> - if the fixup is necessary, i.e. ctxt->mode < X86EMUL_MODE_PROT64, do
> fxsave into 
> 
> - then do segmented_read_std with the correct size, which is
>   - offsetof(struct fxregs_state, xmm_space[16]), i.e. 416
> if ctxt->mode == X86EMUL_MODE_PROT64
>   - offsetof(struct fxregs_state, xmm_space[8]), i.e. 288
> if ctxt->mode < X86EMUL_MODE_PROT64 and CR4.OSFXSR=1
>   - offsetof(struct fxregs_state, xmm_space[0]), i.e. 160
> if ctxt->mode < X86EMUL_MODE_PROT64 and CR4.OSFXSR=0

but we still want to do a segmented_read_std with size 512 otherwise,
correct?

> - then check fx_state.mxcsr
> 
> - then do fxrstor

This sounds like we conditionally do the fxsave, but then always do the
fxrstor.  Is that ok? I guess the original code kind of does that as
well.

> - finally do put_fpu

Sounds straight forward.  I can see how fxsave and CR4.OSFXSR are
accessed in fxstor_fixup.  Is it ok to skip those memcpy's that would
otherwise occur when calling fxrstor_fixup() (which after these changes,
we would not be)?

Re: [PATCH net] sky2: Do not deadlock on sky2_hw_down

[David Miller]

From: Stephen Hemminger 
Date: Thu, 25 May 2017 15:05:02 -0700

> Ok, the issue is that lockdep is being stupid and thinking that
> seqcount's behave like locks.

Well.. they do.  That's why they have that annotation.

Re: [PATCH net] sky2: Do not deadlock on sky2_hw_down

[David Miller]

From: Stephen Hemminger 
Date: Thu, 25 May 2017 15:05:02 -0700

> Ok, the issue is that lockdep is being stupid and thinking that
> seqcount's behave like locks.

Well.. they do.  That's why they have that annotation.

Re: [linux-sunxi] [PATCH 1/3] arm64: allwinner: a64: Add initial Orangepi Win/WinPlus support

[Chen-Yu Tsai]

On Fri, May 26, 2017 at 6:30 AM, André Przywara  wrote:
> On 25/05/17 20:26, Jagan Teki wrote:
>> From: Jagan Teki 
>>
>> Orangepi Win/WinPlus is an open-source single-board computer
>> using the Allwinner A64 SOC.
>>
>> A64 Orangepi Win/WinPlus has
>> - A64 Quad-core Cortex-A53 64bit
>> - 1GB(Win)/2GB(Win Plus) DDR3 SDRAM
>> - Debug TTL UART
>> - Four USB 2.0
>
> I take it those are connected to a hub chip, and the micro-USB socket is
> connected as a true OTG socket?
> So you should enable the usb_otg node, but without the host mode
> override we use for the Pine64.

Agreed. Unless OTG needs PMIC support.

>
>> - HDMI
>> - LCD
>> - Audio and MIC
>> - Wifi + BT
>
> It looks like Wifi + BT are soldered on the board, so you should at
> least enable the proper UART connected to the Bluetooth chip, probably
> also MMC1 (which is surely connected to the WiFi chip) should be
> described as an SDIO node.

Those probably need regulator support. Having them enabled together
might be better.

>
>> - IR receiver
>> - 5V DC power supply
>
> I guess the board uses the AXP803 as well? You might want to coordinate
> with Icenowy what to do to describe this as well, given that her patches
> might go in before.

Still waiting for NMI driver/bindings to be merged before I merge the dts
file changes. The mfd and regulator driver changes are already in -next.

>
> Cheers,
> Andre.
>
>> http://www.orangepi.org/OrangePiWin_WinPlus/

The URL is not going to be helpful if it goes offline.

Can someone provide schematics for this board? Without it there's really
no verification for what the device tree describes.

>>
>> Signed-off-by: Jagan Teki 
>> ---
>>  arch/arm64/boot/dts/allwinner/Makefile |   1 +
>>  .../boot/dts/allwinner/sun50i-a64-orangepi-win.dts | 102 
>> +
>>  2 files changed, 103 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
>> b/arch/arm64/boot/dts/allwinner/Makefile
>> index 244e8b7..4120ce9 100644
>> --- a/arch/arm64/boot/dts/allwinner/Makefile
>> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>> @@ -1,5 +1,6 @@
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
>> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
>>
>>  always   := $(dtb-y)
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts 
>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
>> new file mode 100644
>> index 000..b16e606
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
>> @@ -0,0 +1,102 @@
>> +/*
>> + * Copyright (C) 2017 Jagan Teki 
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This library is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of the
>> + * License, or (at your option) any later version.
>> + *
>> + * This library is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + *  b) Permission is hereby granted, free of charge, to any person
>> + * obtaining a copy of this software and associated documentation
>> + * files (the "Software"), to deal in the Software without
>> + * restriction, including without limitation the rights to use,
>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>> + * sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following
>> + * conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be
>> + * included in all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE 

Re: [linux-sunxi] [PATCH 1/3] arm64: allwinner: a64: Add initial Orangepi Win/WinPlus support

[Chen-Yu Tsai]

On Fri, May 26, 2017 at 6:30 AM, André Przywara  wrote:
> On 25/05/17 20:26, Jagan Teki wrote:
>> From: Jagan Teki 
>>
>> Orangepi Win/WinPlus is an open-source single-board computer
>> using the Allwinner A64 SOC.
>>
>> A64 Orangepi Win/WinPlus has
>> - A64 Quad-core Cortex-A53 64bit
>> - 1GB(Win)/2GB(Win Plus) DDR3 SDRAM
>> - Debug TTL UART
>> - Four USB 2.0
>
> I take it those are connected to a hub chip, and the micro-USB socket is
> connected as a true OTG socket?
> So you should enable the usb_otg node, but without the host mode
> override we use for the Pine64.

Agreed. Unless OTG needs PMIC support.

>
>> - HDMI
>> - LCD
>> - Audio and MIC
>> - Wifi + BT
>
> It looks like Wifi + BT are soldered on the board, so you should at
> least enable the proper UART connected to the Bluetooth chip, probably
> also MMC1 (which is surely connected to the WiFi chip) should be
> described as an SDIO node.

Those probably need regulator support. Having them enabled together
might be better.

>
>> - IR receiver
>> - 5V DC power supply
>
> I guess the board uses the AXP803 as well? You might want to coordinate
> with Icenowy what to do to describe this as well, given that her patches
> might go in before.

Still waiting for NMI driver/bindings to be merged before I merge the dts
file changes. The mfd and regulator driver changes are already in -next.

>
> Cheers,
> Andre.
>
>> http://www.orangepi.org/OrangePiWin_WinPlus/

The URL is not going to be helpful if it goes offline.

Can someone provide schematics for this board? Without it there's really
no verification for what the device tree describes.

>>
>> Signed-off-by: Jagan Teki 
>> ---
>>  arch/arm64/boot/dts/allwinner/Makefile |   1 +
>>  .../boot/dts/allwinner/sun50i-a64-orangepi-win.dts | 102 
>> +
>>  2 files changed, 103 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
>> b/arch/arm64/boot/dts/allwinner/Makefile
>> index 244e8b7..4120ce9 100644
>> --- a/arch/arm64/boot/dts/allwinner/Makefile
>> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>> @@ -1,5 +1,6 @@
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
>> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
>>
>>  always   := $(dtb-y)
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts 
>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
>> new file mode 100644
>> index 000..b16e606
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
>> @@ -0,0 +1,102 @@
>> +/*
>> + * Copyright (C) 2017 Jagan Teki 
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This library is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of the
>> + * License, or (at your option) any later version.
>> + *
>> + * This library is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + *  b) Permission is hereby granted, free of charge, to any person
>> + * obtaining a copy of this software and associated documentation
>> + * files (the "Software"), to deal in the Software without
>> + * restriction, including without limitation the rights to use,
>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>> + * sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following
>> + * conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be
>> + * included in all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "sun50i-a64.dtsi"
>> +
>> +#include 
>> +
>> +/ {

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

[Michael Ellerman]

Reza Arbab  writes:

> On Thu, May 25, 2017 at 04:19:53PM +1000, Michael Ellerman wrote:
>>The commit message for 3af229f2071f says:
>>
>>In practice, we never see a system with 256 NUMA nodes, and in fact, we
>>do not support node hotplug on power in the first place, so the nodes
>>^^^
>>that are online when we come up are the nodes that will be present for
>>the lifetime of this kernel.
>>
>>Is that no longer true?
>
> I don't know what the reasoning behind that statement was at the time, 
> but as far as I can tell, the only thing missing for node hotplug now is 
> Balbir's patchset [1]. He fixes the resource issue which motivated 
> 3af229f2071f and reverts it.
>
> With that set, I can instantiate a new numa node just by doing 
> add_memory(nid, ...) where nid doesn't currently exist.

But does that actually happen on any real system?

cheers

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

[Michael Ellerman]

Reza Arbab  writes:

> On Thu, May 25, 2017 at 04:19:53PM +1000, Michael Ellerman wrote:
>>The commit message for 3af229f2071f says:
>>
>>In practice, we never see a system with 256 NUMA nodes, and in fact, we
>>do not support node hotplug on power in the first place, so the nodes
>>^^^
>>that are online when we come up are the nodes that will be present for
>>the lifetime of this kernel.
>>
>>Is that no longer true?
>
> I don't know what the reasoning behind that statement was at the time, 
> but as far as I can tell, the only thing missing for node hotplug now is 
> Balbir's patchset [1]. He fixes the resource issue which motivated 
> 3af229f2071f and reverts it.
>
> With that set, I can instantiate a new numa node just by doing 
> add_memory(nid, ...) where nid doesn't currently exist.

But does that actually happen on any real system?

cheers

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

[Balbir Singh]

On Thu, 25 May 2017 10:10:11 -0500
Reza Arbab  wrote:

> On Thu, May 25, 2017 at 04:19:53PM +1000, Michael Ellerman wrote:
> >The commit message for 3af229f2071f says:
> >
> >In practice, we never see a system with 256 NUMA nodes, and in fact, we
> >do not support node hotplug on power in the first place, so the nodes
> >^^^
> >that are online when we come up are the nodes that will be present for
> >the lifetime of this kernel.
> >
> >Is that no longer true?  
> 
> I don't know what the reasoning behind that statement was at the time, 
> but as far as I can tell, the only thing missing for node hotplug now is 
> Balbir's patchset [1]. He fixes the resource issue which motivated 
> 3af229f2071f and reverts it.
> 
> With that set, I can instantiate a new numa node just by doing 
> add_memory(nid, ...) where nid doesn't currently exist.
> 
> [1] 
> https://lkml.kernel.org/r/1479253501-26261-1-git-send-email-bsinghar...@gmail.com
> 

I guess I should try and revive that patchset. One of the suggestions of
then was to limit maximum possible nodes in firmware, but I'm double checking
to see if we can do that in a well defined manner.

Balbir Singh

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

[Balbir Singh]

On Thu, 25 May 2017 10:10:11 -0500
Reza Arbab  wrote:

> On Thu, May 25, 2017 at 04:19:53PM +1000, Michael Ellerman wrote:
> >The commit message for 3af229f2071f says:
> >
> >In practice, we never see a system with 256 NUMA nodes, and in fact, we
> >do not support node hotplug on power in the first place, so the nodes
> >^^^
> >that are online when we come up are the nodes that will be present for
> >the lifetime of this kernel.
> >
> >Is that no longer true?  
> 
> I don't know what the reasoning behind that statement was at the time, 
> but as far as I can tell, the only thing missing for node hotplug now is 
> Balbir's patchset [1]. He fixes the resource issue which motivated 
> 3af229f2071f and reverts it.
> 
> With that set, I can instantiate a new numa node just by doing 
> add_memory(nid, ...) where nid doesn't currently exist.
> 
> [1] 
> https://lkml.kernel.org/r/1479253501-26261-1-git-send-email-bsinghar...@gmail.com
> 

I guess I should try and revive that patchset. One of the suggestions of
then was to limit maximum possible nodes in firmware, but I'm double checking
to see if we can do that in a well defined manner.

Balbir Singh

Re: [PATCH v4 6/6] Documentation/dev-tools: Add kselftest_harness documentation

[Kees Cook]

On Thu, May 25, 2017 at 5:20 PM, Mickaël Salaün  wrote:
> Add metadata to kselftest_harness.h to be able to include the comments
> in the Sphinx documentation.
>
> Changes since v3:
> * document macros as actual functions (suggested by Jonathan Corbet)
> * remove the TEST_API() wrapper to expose the underlying macro arguments
>   to the documentation tools
> * move and cleanup comments

To aid review, can you actually split this into 2 patches with the
renaming after the removal of TEST_API() in the first and the addition
of the ReST docs in the second? Regardless, it looks good. Thanks!

-Kees

>
> Changes since v2:
> * add reference to the full documentation in the header file (suggested
>   by Kees Cook)
>
> Signed-off-by: Mickaël Salaün 
> Acked-by: Kees Cook 
> Cc: Andy Lutomirski 
> Cc: Jonathan Corbet 
> Cc: Shuah Khan 
> Cc: Will Drewry 
> ---
>  Documentation/dev-tools/kselftest.rst   |  34 ++
>  tools/testing/selftests/kselftest_harness.h | 678 
> ++--
>  2 files changed, 468 insertions(+), 244 deletions(-)
>
> diff --git a/Documentation/dev-tools/kselftest.rst 
> b/Documentation/dev-tools/kselftest.rst
> index 9232ce94612c..a92fa181b6cf 100644
> --- a/Documentation/dev-tools/kselftest.rst
> +++ b/Documentation/dev-tools/kselftest.rst
> @@ -120,3 +120,37 @@ Contributing new tests (details)
> executable which is not tested by default.
> TEST_FILES, TEST_GEN_FILES mean it is the file which is used by
> test.
> +
> +Test Harness
> +
> +
> +The kselftest_harness.h file contains useful helpers to build tests.  The 
> tests
> +from tools/testing/selftests/seccomp/seccomp_bpf.c can be used as example.
> +
> +Example
> +---
> +
> +.. kernel-doc:: tools/testing/selftests/kselftest_harness.h
> +:doc: example
> +
> +
> +Helpers
> +---
> +
> +.. kernel-doc:: tools/testing/selftests/kselftest_harness.h
> +:functions: TH_LOG TEST TEST_SIGNAL FIXTURE FIXTURE_DATA FIXTURE_SETUP
> +FIXTURE_TEARDOWN TEST_F TEST_HARNESS_MAIN
> +
> +Operators
> +-
> +
> +.. kernel-doc:: tools/testing/selftests/kselftest_harness.h
> +:doc: operators
> +
> +.. kernel-doc:: tools/testing/selftests/kselftest_harness.h
> +:functions: ASSERT_EQ ASSERT_NE ASSERT_LT ASSERT_LE ASSERT_GT ASSERT_GE
> +ASSERT_NULL ASSERT_TRUE ASSERT_NULL ASSERT_TRUE ASSERT_FALSE
> +ASSERT_STREQ ASSERT_STRNE EXPECT_EQ EXPECT_NE EXPECT_LT
> +EXPECT_LE EXPECT_GT EXPECT_GE EXPECT_NULL EXPECT_TRUE
> +EXPECT_FALSE EXPECT_STREQ EXPECT_STRNE
> +
> diff --git a/tools/testing/selftests/kselftest_harness.h 
> b/tools/testing/selftests/kselftest_harness.h
> index 171e70aead9c..8f623a4e1889 100644
> --- a/tools/testing/selftests/kselftest_harness.h
> +++ b/tools/testing/selftests/kselftest_harness.h
> @@ -4,41 +4,49 @@
>   *
>   * kselftest_harness.h: simple C unit test helper.
>   *
> - * Usage:
> - *   #include "../kselftest_harness.h"
> - *   TEST(standalone_test) {
> - * do_some_stuff;
> - * EXPECT_GT(10, stuff) {
> - *stuff_state_t state;
> - *enumerate_stuff_state();
> - *TH_LOG("expectation failed with state: %s", state.msg);
> - * }
> - * more_stuff;
> - * ASSERT_NE(some_stuff, NULL) TH_LOG("how did it happen?!");
> - * last_stuff;
> - * EXPECT_EQ(0, last_stuff);
> - *   }
> - *
> - *   FIXTURE(my_fixture) {
> - * mytype_t *data;
> - * int awesomeness_level;
> - *   };
> - *   FIXTURE_SETUP(my_fixture) {
> - * self->data = mytype_new();
> - * ASSERT_NE(NULL, self->data);
> - *   }
> - *   FIXTURE_TEARDOWN(my_fixture) {
> - * mytype_free(self->data);
> - *   }
> - *   TEST_F(my_fixture, data_is_good) {
> - * EXPECT_EQ(1, is_my_data_good(self->data));
> - *   }
> - *
> - *   TEST_HARNESS_MAIN
> + * See documentation in Documentation/dev-tools/kselftest.rst
>   *
>   * API inspired by code.google.com/p/googletest
>   */
>
> +/**
> + * DOC: example
> + *
> + * .. code-block:: c
> + *
> + *#include "../kselftest_harness.h"
> + *
> + *TEST(standalone_test) {
> + *  do_some_stuff;
> + *  EXPECT_GT(10, stuff) {
> + * stuff_state_t state;
> + * enumerate_stuff_state();
> + * TH_LOG("expectation failed with state: %s", state.msg);
> + *  }
> + *  more_stuff;
> + *  ASSERT_NE(some_stuff, NULL) TH_LOG("how did it happen?!");
> + *  last_stuff;
> + *  EXPECT_EQ(0, last_stuff);
> + *}
> + *
> + *FIXTURE(my_fixture) {
> + *  mytype_t *data;
> + *  int awesomeness_level;
> + *};
> + *FIXTURE_SETUP(my_fixture) {
> + *  self->data = mytype_new();
> + *  ASSERT_NE(NULL, self->data);
> + *}
> + *FIXTURE_TEARDOWN(my_fixture) {
> + *  mytype_free(self->data);
> + *}
> + *TEST_F(my_fixture, data_is_good) {
> + * 

Re: [PATCH v4 6/6] Documentation/dev-tools: Add kselftest_harness documentation

[Kees Cook]

On Thu, May 25, 2017 at 5:20 PM, Mickaël Salaün  wrote:
> Add metadata to kselftest_harness.h to be able to include the comments
> in the Sphinx documentation.
>
> Changes since v3:
> * document macros as actual functions (suggested by Jonathan Corbet)
> * remove the TEST_API() wrapper to expose the underlying macro arguments
>   to the documentation tools
> * move and cleanup comments

To aid review, can you actually split this into 2 patches with the
renaming after the removal of TEST_API() in the first and the addition
of the ReST docs in the second? Regardless, it looks good. Thanks!

-Kees

>
> Changes since v2:
> * add reference to the full documentation in the header file (suggested
>   by Kees Cook)
>
> Signed-off-by: Mickaël Salaün 
> Acked-by: Kees Cook 
> Cc: Andy Lutomirski 
> Cc: Jonathan Corbet 
> Cc: Shuah Khan 
> Cc: Will Drewry 
> ---
>  Documentation/dev-tools/kselftest.rst   |  34 ++
>  tools/testing/selftests/kselftest_harness.h | 678 
> ++--
>  2 files changed, 468 insertions(+), 244 deletions(-)
>
> diff --git a/Documentation/dev-tools/kselftest.rst 
> b/Documentation/dev-tools/kselftest.rst
> index 9232ce94612c..a92fa181b6cf 100644
> --- a/Documentation/dev-tools/kselftest.rst
> +++ b/Documentation/dev-tools/kselftest.rst
> @@ -120,3 +120,37 @@ Contributing new tests (details)
> executable which is not tested by default.
> TEST_FILES, TEST_GEN_FILES mean it is the file which is used by
> test.
> +
> +Test Harness
> +
> +
> +The kselftest_harness.h file contains useful helpers to build tests.  The 
> tests
> +from tools/testing/selftests/seccomp/seccomp_bpf.c can be used as example.
> +
> +Example
> +---
> +
> +.. kernel-doc:: tools/testing/selftests/kselftest_harness.h
> +:doc: example
> +
> +
> +Helpers
> +---
> +
> +.. kernel-doc:: tools/testing/selftests/kselftest_harness.h
> +:functions: TH_LOG TEST TEST_SIGNAL FIXTURE FIXTURE_DATA FIXTURE_SETUP
> +FIXTURE_TEARDOWN TEST_F TEST_HARNESS_MAIN
> +
> +Operators
> +-
> +
> +.. kernel-doc:: tools/testing/selftests/kselftest_harness.h
> +:doc: operators
> +
> +.. kernel-doc:: tools/testing/selftests/kselftest_harness.h
> +:functions: ASSERT_EQ ASSERT_NE ASSERT_LT ASSERT_LE ASSERT_GT ASSERT_GE
> +ASSERT_NULL ASSERT_TRUE ASSERT_NULL ASSERT_TRUE ASSERT_FALSE
> +ASSERT_STREQ ASSERT_STRNE EXPECT_EQ EXPECT_NE EXPECT_LT
> +EXPECT_LE EXPECT_GT EXPECT_GE EXPECT_NULL EXPECT_TRUE
> +EXPECT_FALSE EXPECT_STREQ EXPECT_STRNE
> +
> diff --git a/tools/testing/selftests/kselftest_harness.h 
> b/tools/testing/selftests/kselftest_harness.h
> index 171e70aead9c..8f623a4e1889 100644
> --- a/tools/testing/selftests/kselftest_harness.h
> +++ b/tools/testing/selftests/kselftest_harness.h
> @@ -4,41 +4,49 @@
>   *
>   * kselftest_harness.h: simple C unit test helper.
>   *
> - * Usage:
> - *   #include "../kselftest_harness.h"
> - *   TEST(standalone_test) {
> - * do_some_stuff;
> - * EXPECT_GT(10, stuff) {
> - *stuff_state_t state;
> - *enumerate_stuff_state();
> - *TH_LOG("expectation failed with state: %s", state.msg);
> - * }
> - * more_stuff;
> - * ASSERT_NE(some_stuff, NULL) TH_LOG("how did it happen?!");
> - * last_stuff;
> - * EXPECT_EQ(0, last_stuff);
> - *   }
> - *
> - *   FIXTURE(my_fixture) {
> - * mytype_t *data;
> - * int awesomeness_level;
> - *   };
> - *   FIXTURE_SETUP(my_fixture) {
> - * self->data = mytype_new();
> - * ASSERT_NE(NULL, self->data);
> - *   }
> - *   FIXTURE_TEARDOWN(my_fixture) {
> - * mytype_free(self->data);
> - *   }
> - *   TEST_F(my_fixture, data_is_good) {
> - * EXPECT_EQ(1, is_my_data_good(self->data));
> - *   }
> - *
> - *   TEST_HARNESS_MAIN
> + * See documentation in Documentation/dev-tools/kselftest.rst
>   *
>   * API inspired by code.google.com/p/googletest
>   */
>
> +/**
> + * DOC: example
> + *
> + * .. code-block:: c
> + *
> + *#include "../kselftest_harness.h"
> + *
> + *TEST(standalone_test) {
> + *  do_some_stuff;
> + *  EXPECT_GT(10, stuff) {
> + * stuff_state_t state;
> + * enumerate_stuff_state();
> + * TH_LOG("expectation failed with state: %s", state.msg);
> + *  }
> + *  more_stuff;
> + *  ASSERT_NE(some_stuff, NULL) TH_LOG("how did it happen?!");
> + *  last_stuff;
> + *  EXPECT_EQ(0, last_stuff);
> + *}
> + *
> + *FIXTURE(my_fixture) {
> + *  mytype_t *data;
> + *  int awesomeness_level;
> + *};
> + *FIXTURE_SETUP(my_fixture) {
> + *  self->data = mytype_new();
> + *  ASSERT_NE(NULL, self->data);
> + *}
> + *FIXTURE_TEARDOWN(my_fixture) {
> + *  mytype_free(self->data);
> + *}
> + *TEST_F(my_fixture, data_is_good) {
> + *  EXPECT_EQ(1, is_my_data_good(self->data));
> + *}
> + *
> + *TEST_HARNESS_MAIN
> + */
> +
>  #ifndef 

Re: [PATCH v3] add the option of fortified string.h functions

[Kees Cook]

On Mon, May 22, 2017 at 4:10 PM, Daniel Micay  wrote:
> diff --git a/arch/x86/include/asm/string_64.h 
> b/arch/x86/include/asm/string_64.h
> index 733bae07fb29..3c5b26e07b85 100644
> --- a/arch/x86/include/asm/string_64.h
> +++ b/arch/x86/include/asm/string_64.h
> @@ -77,6 +77,11 @@ int strcmp(const char *cs, const char *ct);
>  #define memcpy(dst, src, len) __memcpy(dst, src, len)
>  #define memmove(dst, src, len) __memmove(dst, src, len)
>  #define memset(s, c, n) __memset(s, c, n)
> +
> +#ifndef __NO_FORTIFY
> +#define __NO_FORTIFY /* FORTIFY_SOURCE uses __builtin_memcpy, etc. */
> +#endif
> +
>  #endif
>
>  #define __HAVE_ARCH_MEMCPY_MCSAFE 1

Ah-ha, this same KASAN exclusion is missing for string_32.h, which is
what I think akpm tripped over in build tests.

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH v3] add the option of fortified string.h functions

[Kees Cook]

On Mon, May 22, 2017 at 4:10 PM, Daniel Micay  wrote:
> diff --git a/arch/x86/include/asm/string_64.h 
> b/arch/x86/include/asm/string_64.h
> index 733bae07fb29..3c5b26e07b85 100644
> --- a/arch/x86/include/asm/string_64.h
> +++ b/arch/x86/include/asm/string_64.h
> @@ -77,6 +77,11 @@ int strcmp(const char *cs, const char *ct);
>  #define memcpy(dst, src, len) __memcpy(dst, src, len)
>  #define memmove(dst, src, len) __memmove(dst, src, len)
>  #define memset(s, c, n) __memset(s, c, n)
> +
> +#ifndef __NO_FORTIFY
> +#define __NO_FORTIFY /* FORTIFY_SOURCE uses __builtin_memcpy, etc. */
> +#endif
> +
>  #endif
>
>  #define __HAVE_ARCH_MEMCPY_MCSAFE 1

Ah-ha, this same KASAN exclusion is missing for string_32.h, which is
what I think akpm tripped over in build tests.

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH 2/4] pinctrl: rockchip: Add iomux-route switching support for rk3228

[David.Wu]

Hi Heiko,

在 2017/5/26 5:12, Heiko Stuebner 写道:

Requiring developers to calculate this pin-bit-value for each bank
is cumbersome and error-prone. With the routes-struct known in
the driver (see above and below), you can keep the the value element
in rockchip_pin_bank, but calculate the per-bank value dynamically
when the bank gets created.

For example in rockchip_pinctrl_get_soc_data just parse the route-struct
and calculate that value when the driver probes.

This reduces possible errors and also spares us the clutter of all the
additional PIN_BANK_* defines.


It is good to calculate the per-bank value dynamically, Thanks.☺

Re: [PATCH 2/4] pinctrl: rockchip: Add iomux-route switching support for rk3228

[David.Wu]

Hi Heiko,

在 2017/5/26 5:12, Heiko Stuebner 写道:

Requiring developers to calculate this pin-bit-value for each bank
is cumbersome and error-prone. With the routes-struct known in
the driver (see above and below), you can keep the the value element
in rockchip_pin_bank, but calculate the per-bank value dynamically
when the bank gets created.

For example in rockchip_pinctrl_get_soc_data just parse the route-struct
and calculate that value when the driver probes.

This reduces possible errors and also spares us the clutter of all the
additional PIN_BANK_* defines.


It is good to calculate the per-bank value dynamically, Thanks.☺

Re: [PATCH 02/20] ipc: merge ipc_rcu and kern_ipc_perm

[Kees Cook]

On Thu, May 25, 2017 at 12:34 PM, Kees Cook  wrote:
> On Thu, May 25, 2017 at 11:50 AM, Manfred Spraul
>  wrote:
>> ipc has two management structures that exist for every id:
>> - struct kern_ipc_perm, it contains e.g. the permissions.
>> - struct ipc_rcu, it contains the rcu head for rcu handling and
>>   the refcount.
>>
>> The patch merges both structures.
>> As a bonus, we may save one cacheline, because both structures are
>> cacheline aligned.
>> In addition, it reduces the number of casts, instead most codepaths can
>> use container_of.
>>
>> To simplify code, the ipc_rcu_alloc initializes the allocation to 0.
>
> I don't see this change in the code, only the removal of sem's
> memset(..., 0, ...)?
>
>> diff --git a/ipc/sem.c b/ipc/sem.c
>> index fff8337..bdff6d9 100644
>> --- a/ipc/sem.c
>> +++ b/ipc/sem.c
>> @@ -469,20 +469,20 @@ static int newary(struct ipc_namespace *ns, struct 
>> ipc_params *params)
>> if (ns->used_sems + nsems > ns->sc_semmns)
>> return -ENOSPC;
>>
>> +   BUILD_BUG_ON(offsetof(struct sem_array, sem_perm) != 0);
>> +
>> size = sizeof(*sma) + nsems * sizeof(sma->sems[0]);
>> -   sma = ipc_rcu_alloc(size);
>> +   sma = container_of(ipc_rcu_alloc(size), struct sem_array, sem_perm);
>> if (!sma)
>> return -ENOMEM;
>>
>> -   memset(sma, 0, size);
>> -
>> sma->sem_perm.mode = (semflg & S_IRWXUGO);
>> sma->sem_perm.key = key;
>>
>> sma->sem_perm.security = NULL;
>> retval = security_sem_alloc(sma);
>> if (retval) {
>> -   ipc_rcu_putref(sma, ipc_rcu_free);
>> +   ipc_rcu_putref(>sem_perm, ipc_rcu_free);
>> return retval;
>> }
>>
>> [...]
>> diff --git a/ipc/util.c b/ipc/util.c
>> index caec7b1..9dcc08b 100644
>> --- a/ipc/util.c
>> +++ b/ipc/util.c
>> @@ -418,46 +418,43 @@ void ipc_free(void *ptr)
>>  }
>>
>>  /**
>> - * ipc_rcu_alloc - allocate ipc and rcu space
>> + * ipc_rcu_alloc - allocate ipc space
>>   * @size: size desired
>>   *
>> - * Allocate memory for the rcu header structure +  the object.
>> - * Returns the pointer to the object or NULL upon failure.
>> + * Allocate memory for an ipc object.
>> + * The first member must be struct kern_ipc_perm.
>>   */
>> -void *ipc_rcu_alloc(int size)
>> +struct kern_ipc_perm *ipc_rcu_alloc(int size)
>>  {
>> /*
>>  * We prepend the allocation with the rcu struct
>>  */
>> -   struct ipc_rcu *out = ipc_alloc(sizeof(struct ipc_rcu) + size);
>> +   struct kern_ipc_perm *out = ipc_alloc(size);
>> if (unlikely(!out))
>> return NULL;
>> atomic_set(>refcount, 1);
>> -   return out + 1;
>> +   return out;
>>  }

See above:

- newary() loses memset()
- ipc_rcu_alloc() does not gain it
- changelog says "To simplify code, the ipc_rcu_alloc initializes the
allocation to 0." This is what's wanted but the patch doesn't do it.

The actual change that (temporarily) adds memset to ipc_rcu_alloc() is
one of the following patches, but it should be here or bisection may
cause unexpected results for semaphores.

It's a minor issue, since these will likely all land at the same time,
but it's probably still worth fixing.

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH 02/20] ipc: merge ipc_rcu and kern_ipc_perm

[Kees Cook]

On Thu, May 25, 2017 at 12:34 PM, Kees Cook  wrote:
> On Thu, May 25, 2017 at 11:50 AM, Manfred Spraul
>  wrote:
>> ipc has two management structures that exist for every id:
>> - struct kern_ipc_perm, it contains e.g. the permissions.
>> - struct ipc_rcu, it contains the rcu head for rcu handling and
>>   the refcount.
>>
>> The patch merges both structures.
>> As a bonus, we may save one cacheline, because both structures are
>> cacheline aligned.
>> In addition, it reduces the number of casts, instead most codepaths can
>> use container_of.
>>
>> To simplify code, the ipc_rcu_alloc initializes the allocation to 0.
>
> I don't see this change in the code, only the removal of sem's
> memset(..., 0, ...)?
>
>> diff --git a/ipc/sem.c b/ipc/sem.c
>> index fff8337..bdff6d9 100644
>> --- a/ipc/sem.c
>> +++ b/ipc/sem.c
>> @@ -469,20 +469,20 @@ static int newary(struct ipc_namespace *ns, struct 
>> ipc_params *params)
>> if (ns->used_sems + nsems > ns->sc_semmns)
>> return -ENOSPC;
>>
>> +   BUILD_BUG_ON(offsetof(struct sem_array, sem_perm) != 0);
>> +
>> size = sizeof(*sma) + nsems * sizeof(sma->sems[0]);
>> -   sma = ipc_rcu_alloc(size);
>> +   sma = container_of(ipc_rcu_alloc(size), struct sem_array, sem_perm);
>> if (!sma)
>> return -ENOMEM;
>>
>> -   memset(sma, 0, size);
>> -
>> sma->sem_perm.mode = (semflg & S_IRWXUGO);
>> sma->sem_perm.key = key;
>>
>> sma->sem_perm.security = NULL;
>> retval = security_sem_alloc(sma);
>> if (retval) {
>> -   ipc_rcu_putref(sma, ipc_rcu_free);
>> +   ipc_rcu_putref(>sem_perm, ipc_rcu_free);
>> return retval;
>> }
>>
>> [...]
>> diff --git a/ipc/util.c b/ipc/util.c
>> index caec7b1..9dcc08b 100644
>> --- a/ipc/util.c
>> +++ b/ipc/util.c
>> @@ -418,46 +418,43 @@ void ipc_free(void *ptr)
>>  }
>>
>>  /**
>> - * ipc_rcu_alloc - allocate ipc and rcu space
>> + * ipc_rcu_alloc - allocate ipc space
>>   * @size: size desired
>>   *
>> - * Allocate memory for the rcu header structure +  the object.
>> - * Returns the pointer to the object or NULL upon failure.
>> + * Allocate memory for an ipc object.
>> + * The first member must be struct kern_ipc_perm.
>>   */
>> -void *ipc_rcu_alloc(int size)
>> +struct kern_ipc_perm *ipc_rcu_alloc(int size)
>>  {
>> /*
>>  * We prepend the allocation with the rcu struct
>>  */
>> -   struct ipc_rcu *out = ipc_alloc(sizeof(struct ipc_rcu) + size);
>> +   struct kern_ipc_perm *out = ipc_alloc(size);
>> if (unlikely(!out))
>> return NULL;
>> atomic_set(>refcount, 1);
>> -   return out + 1;
>> +   return out;
>>  }

See above:

- newary() loses memset()
- ipc_rcu_alloc() does not gain it
- changelog says "To simplify code, the ipc_rcu_alloc initializes the
allocation to 0." This is what's wanted but the patch doesn't do it.

The actual change that (temporarily) adds memset to ipc_rcu_alloc() is
one of the following patches, but it should be here or bisection may
cause unexpected results for semaphores.

It's a minor issue, since these will likely all land at the same time,
but it's probably still worth fixing.

-Kees

-- 
Kees Cook
Pixel Security

[PATCH 0/2] reset: Basic reset controller

[Joel Stanley]

Hello,

In the Aspeed SoCs we have some reset registers spread out in various parts of
the soc: in the system controller IP, as well as other peripherals. I need to be
able to deassert those resets before other drivers work.

In writing a driver to do this I realised it was very generic. So instead I've
sent a generic driver that can be used by the device tree to clear reset lines
described by single bits in a register.

Let me know what you think of the idea. I've tested this driver on our SoC to
release the UART reset.

Joel Stanley (2):
  dt-bindings: reset: Add bindings for basic reset controller
  reset: Add basic single-register reset driver

 .../devicetree/bindings/reset/reset-basic.txt  |  31 ++
 drivers/reset/Kconfig  |   6 ++
 drivers/reset/Makefile |   1 +
 drivers/reset/reset-basic.c| 109 +
 4 files changed, 147 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/reset-basic.txt
 create mode 100644 drivers/reset/reset-basic.c

-- 
2.11.0

[PATCH 2/2] reset: Add basic single-register reset driver

[Joel Stanley]

This driver is a basic single-register reset controller driver that
supports clearing a single bit in a register.

Signed-off-by: Joel Stanley 
---
 drivers/reset/Kconfig   |   6 +++
 drivers/reset/Makefile  |   1 +
 drivers/reset/reset-basic.c | 109 
 3 files changed, 116 insertions(+)
 create mode 100644 drivers/reset/reset-basic.c

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index d21c07ccc94e..980cda887dfe 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -28,6 +28,12 @@ config RESET_ATH79
  This enables the ATH79 reset controller driver that supports the
  AR71xx SoC reset controller.
 
+config RESET_BASIC
+   bool "Basic Reset Driver"
+   help
+ This enables a basic single-register reset controller driver that
+ supports clearing a single bit in a register.
+
 config RESET_BERLIN
bool "Berlin Reset Driver" if COMPILE_TEST
default ARCH_BERLIN
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 02a74db94339..e8e8869e098d 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_ARCH_STI) += sti/
 obj-$(CONFIG_ARCH_TEGRA) += tegra/
 obj-$(CONFIG_RESET_A10SR) += reset-a10sr.o
 obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
+obj-$(CONFIG_RESET_BASIC) += reset-basic.o
 obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
 obj-$(CONFIG_RESET_IMX7) += reset-imx7.o
 obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
diff --git a/drivers/reset/reset-basic.c b/drivers/reset/reset-basic.c
new file mode 100644
index ..62a676de9f62
--- /dev/null
+++ b/drivers/reset/reset-basic.c
@@ -0,0 +1,109 @@
+/*
+ * Copyright 2017 IBM Corperation
+ *
+ * Joel Stanley 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define to_basic_reset_priv(p) \
+   container_of((p), struct basic_reset_priv, rcdev)
+
+struct basic_reset_priv {
+   struct regmap *regmap;
+   struct reset_controller_dev rcdev;
+   u32 reg;
+};
+
+static int basic_reset_assert(struct reset_controller_dev *rcdev,
+  unsigned long id)
+{
+   struct basic_reset_priv *priv = to_basic_reset_priv(rcdev);
+   u32 mask = BIT(id);
+
+   regmap_update_bits(priv->regmap, priv->reg, mask, mask);
+
+   return 0;
+}
+
+static int basic_reset_deassert(struct reset_controller_dev *rcdev,
+unsigned long id)
+{
+   struct basic_reset_priv *priv = to_basic_reset_priv(rcdev);
+   u32 mask = BIT(id);
+
+   regmap_update_bits(priv->regmap, priv->reg, mask, 0);
+
+   return 0;
+}
+
+static int basic_reset_status(struct reset_controller_dev *rcdev,
+  unsigned long id)
+{
+   struct basic_reset_priv *priv = to_basic_reset_priv(rcdev);
+   u32 mask = BIT(id);
+   u32 val;
+
+   regmap_read(priv->regmap, priv->reg, );
+
+   return !!(val & mask);
+}
+
+static const struct reset_control_ops basic_reset_ops = {
+   .assert = basic_reset_assert,
+   .deassert = basic_reset_deassert,
+   .status = basic_reset_status,
+};
+
+static int basic_reset_probe(struct platform_device *pdev)
+{
+   struct device_node *parent_np = of_get_parent(pdev->dev.of_node);
+   struct basic_reset_priv *priv;
+   int ret;
+
+   priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+   priv->regmap = syscon_node_to_regmap(parent_np);
+   of_node_put(parent_np);
+   if (IS_ERR(priv->regmap))
+   return PTR_ERR(priv->regmap);
+
+   ret = of_property_read_u32(pdev->dev.of_node, "reg", >reg);
+   if (ret)
+   return ret;
+
+   priv->rcdev.owner = THIS_MODULE;
+   priv->rcdev.ops = _reset_ops;
+   priv->rcdev.of_node = pdev->dev.of_node;
+   priv->rcdev.nr_resets = 32;
+
+   return reset_controller_register(>rcdev);
+}
+
+static const struct of_device_id basic_reset_dt_match[] = {
+   { .compatible = "reset-basic" },
+   { },
+};
+
+static struct platform_driver basic_reset_driver = {
+   .probe  = basic_reset_probe,
+   .driver = {
+   .name = "basic-reset",
+   .of_match_table = basic_reset_dt_match,
+   },
+};
+builtin_platform_driver(basic_reset_driver);
-- 
2.11.0

[PATCH 1/2] dt-bindings: reset: Add bindings for basic reset controller

[Joel Stanley]

This adds the bindings documentation for a basic single-register reset
controller.

The bindings describe a single 32-bit register that contains up to 32
reset lines, each deasserted by clearing the appropriate bit in the
register.

Signed-off-by: Joel Stanley 
---
 .../devicetree/bindings/reset/reset-basic.txt  | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/reset-basic.txt

diff --git a/Documentation/devicetree/bindings/reset/reset-basic.txt 
b/Documentation/devicetree/bindings/reset/reset-basic.txt
new file mode 100644
index ..7341e04e7904
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/reset-basic.txt
@@ -0,0 +1,31 @@
+Basic single-register reset controller
+==
+
+This describes a generic reset controller where the reset lines are controlled
+by single bits within a 32-bit memory location. The memory location is assumed
+to be part of a syscon regmap.
+
+Reset controller required properties:
+ - compatible: should be "reset-basic"
+ - #reset-cells: must be set to 1
+ - reg: reset register location within regmap
+
+Device node required properties:
+ - resets phandle
+ - bit number, counting from zero, for the desired reset line. Max is 31.
+
+Example:
+
+syscon {
+   compatible = "syscon";
+
+   uart_rest: rest@0c {
+   compatible = "reset-basic";
+   #reset-cells = <1>;
+   reg = <0x0c>;
+   };
+}
+
+ {
+   resets = <_rest 0x04>;
+}
-- 
2.11.0

[PATCH 0/2] reset: Basic reset controller

[Joel Stanley]

Hello,

In the Aspeed SoCs we have some reset registers spread out in various parts of
the soc: in the system controller IP, as well as other peripherals. I need to be
able to deassert those resets before other drivers work.

In writing a driver to do this I realised it was very generic. So instead I've
sent a generic driver that can be used by the device tree to clear reset lines
described by single bits in a register.

Let me know what you think of the idea. I've tested this driver on our SoC to
release the UART reset.

Joel Stanley (2):
  dt-bindings: reset: Add bindings for basic reset controller
  reset: Add basic single-register reset driver

 .../devicetree/bindings/reset/reset-basic.txt  |  31 ++
 drivers/reset/Kconfig  |   6 ++
 drivers/reset/Makefile |   1 +
 drivers/reset/reset-basic.c| 109 +
 4 files changed, 147 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/reset-basic.txt
 create mode 100644 drivers/reset/reset-basic.c

-- 
2.11.0

[PATCH 2/2] reset: Add basic single-register reset driver

[Joel Stanley]

This driver is a basic single-register reset controller driver that
supports clearing a single bit in a register.

Signed-off-by: Joel Stanley 
---
 drivers/reset/Kconfig   |   6 +++
 drivers/reset/Makefile  |   1 +
 drivers/reset/reset-basic.c | 109 
 3 files changed, 116 insertions(+)
 create mode 100644 drivers/reset/reset-basic.c

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index d21c07ccc94e..980cda887dfe 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -28,6 +28,12 @@ config RESET_ATH79
  This enables the ATH79 reset controller driver that supports the
  AR71xx SoC reset controller.
 
+config RESET_BASIC
+   bool "Basic Reset Driver"
+   help
+ This enables a basic single-register reset controller driver that
+ supports clearing a single bit in a register.
+
 config RESET_BERLIN
bool "Berlin Reset Driver" if COMPILE_TEST
default ARCH_BERLIN
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 02a74db94339..e8e8869e098d 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_ARCH_STI) += sti/
 obj-$(CONFIG_ARCH_TEGRA) += tegra/
 obj-$(CONFIG_RESET_A10SR) += reset-a10sr.o
 obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
+obj-$(CONFIG_RESET_BASIC) += reset-basic.o
 obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
 obj-$(CONFIG_RESET_IMX7) += reset-imx7.o
 obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
diff --git a/drivers/reset/reset-basic.c b/drivers/reset/reset-basic.c
new file mode 100644
index ..62a676de9f62
--- /dev/null
+++ b/drivers/reset/reset-basic.c
@@ -0,0 +1,109 @@
+/*
+ * Copyright 2017 IBM Corperation
+ *
+ * Joel Stanley 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define to_basic_reset_priv(p) \
+   container_of((p), struct basic_reset_priv, rcdev)
+
+struct basic_reset_priv {
+   struct regmap *regmap;
+   struct reset_controller_dev rcdev;
+   u32 reg;
+};
+
+static int basic_reset_assert(struct reset_controller_dev *rcdev,
+  unsigned long id)
+{
+   struct basic_reset_priv *priv = to_basic_reset_priv(rcdev);
+   u32 mask = BIT(id);
+
+   regmap_update_bits(priv->regmap, priv->reg, mask, mask);
+
+   return 0;
+}
+
+static int basic_reset_deassert(struct reset_controller_dev *rcdev,
+unsigned long id)
+{
+   struct basic_reset_priv *priv = to_basic_reset_priv(rcdev);
+   u32 mask = BIT(id);
+
+   regmap_update_bits(priv->regmap, priv->reg, mask, 0);
+
+   return 0;
+}
+
+static int basic_reset_status(struct reset_controller_dev *rcdev,
+  unsigned long id)
+{
+   struct basic_reset_priv *priv = to_basic_reset_priv(rcdev);
+   u32 mask = BIT(id);
+   u32 val;
+
+   regmap_read(priv->regmap, priv->reg, );
+
+   return !!(val & mask);
+}
+
+static const struct reset_control_ops basic_reset_ops = {
+   .assert = basic_reset_assert,
+   .deassert = basic_reset_deassert,
+   .status = basic_reset_status,
+};
+
+static int basic_reset_probe(struct platform_device *pdev)
+{
+   struct device_node *parent_np = of_get_parent(pdev->dev.of_node);
+   struct basic_reset_priv *priv;
+   int ret;
+
+   priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+   priv->regmap = syscon_node_to_regmap(parent_np);
+   of_node_put(parent_np);
+   if (IS_ERR(priv->regmap))
+   return PTR_ERR(priv->regmap);
+
+   ret = of_property_read_u32(pdev->dev.of_node, "reg", >reg);
+   if (ret)
+   return ret;
+
+   priv->rcdev.owner = THIS_MODULE;
+   priv->rcdev.ops = _reset_ops;
+   priv->rcdev.of_node = pdev->dev.of_node;
+   priv->rcdev.nr_resets = 32;
+
+   return reset_controller_register(>rcdev);
+}
+
+static const struct of_device_id basic_reset_dt_match[] = {
+   { .compatible = "reset-basic" },
+   { },
+};
+
+static struct platform_driver basic_reset_driver = {
+   .probe  = basic_reset_probe,
+   .driver = {
+   .name = "basic-reset",
+   .of_match_table = basic_reset_dt_match,
+   },
+};
+builtin_platform_driver(basic_reset_driver);
-- 
2.11.0

[PATCH 1/2] dt-bindings: reset: Add bindings for basic reset controller

[Joel Stanley]

This adds the bindings documentation for a basic single-register reset
controller.

The bindings describe a single 32-bit register that contains up to 32
reset lines, each deasserted by clearing the appropriate bit in the
register.

Signed-off-by: Joel Stanley 
---
 .../devicetree/bindings/reset/reset-basic.txt  | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/reset-basic.txt

diff --git a/Documentation/devicetree/bindings/reset/reset-basic.txt 
b/Documentation/devicetree/bindings/reset/reset-basic.txt
new file mode 100644
index ..7341e04e7904
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/reset-basic.txt
@@ -0,0 +1,31 @@
+Basic single-register reset controller
+==
+
+This describes a generic reset controller where the reset lines are controlled
+by single bits within a 32-bit memory location. The memory location is assumed
+to be part of a syscon regmap.
+
+Reset controller required properties:
+ - compatible: should be "reset-basic"
+ - #reset-cells: must be set to 1
+ - reg: reset register location within regmap
+
+Device node required properties:
+ - resets phandle
+ - bit number, counting from zero, for the desired reset line. Max is 31.
+
+Example:
+
+syscon {
+   compatible = "syscon";
+
+   uart_rest: rest@0c {
+   compatible = "reset-basic";
+   #reset-cells = <1>;
+   reg = <0x0c>;
+   };
+}
+
+ {
+   resets = <_rest 0x04>;
+}
-- 
2.11.0

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

[Christoph Lameter]

On Thu, 25 May 2017, Marcelo Tosatti wrote:

> Argument? We're showing you the data that this is causing a latency
> problem for us.

Sorry I am not sure where the data shows a latency problem. There are
interrupts and scheduler ticks. But what does this have to do with vmstat?

Show me your dpdk code running and trace the tick on / off events  as well
as the vmstat invocations. Also show all system calls occurring on the cpu
that runs dpdk. That is necessary to see what triggers vmstat and how the
system reacts to the changes to the differentials.

Then please rerun the test by setting the vmstat_interval to 60.

Do another run with your modifications and show the difference.

> > Something that crossed my mind was to add a new tunable to set
> > the vmstat_interval for each CPU, this way we could essentially
> > disable it to the CPUs where DPDK is running. What's the implications
> > of doing this besides not getting up to date stats in /proc/vmstat
> > (which I still have to confirm would be OK)? Can this break anything
> > in the kernel for example?
>
> Well, you get incorrect statistics.

The statistics are never completely accurate. You will get less accurate
statistics but they will be correct. The differentials may not be
reflected in the counts shown via /proc but there is a cap on how
inaccurate those can becore.

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

[Christoph Lameter]

On Thu, 25 May 2017, Marcelo Tosatti wrote:

> Argument? We're showing you the data that this is causing a latency
> problem for us.

Sorry I am not sure where the data shows a latency problem. There are
interrupts and scheduler ticks. But what does this have to do with vmstat?

Show me your dpdk code running and trace the tick on / off events  as well
as the vmstat invocations. Also show all system calls occurring on the cpu
that runs dpdk. That is necessary to see what triggers vmstat and how the
system reacts to the changes to the differentials.

Then please rerun the test by setting the vmstat_interval to 60.

Do another run with your modifications and show the difference.

> > Something that crossed my mind was to add a new tunable to set
> > the vmstat_interval for each CPU, this way we could essentially
> > disable it to the CPUs where DPDK is running. What's the implications
> > of doing this besides not getting up to date stats in /proc/vmstat
> > (which I still have to confirm would be OK)? Can this break anything
> > in the kernel for example?
>
> Well, you get incorrect statistics.

The statistics are never completely accurate. You will get less accurate
statistics but they will be correct. The differentials may not be
reflected in the counts shown via /proc but there is a cap on how
inaccurate those can becore.

Re: [PATCH V2 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

[Balbir Singh]

On Thu, 25 May 2017 12:37:40 -0500
Michael Bringmann  wrote:

> Removing or adding memory via the PowerPC hotplug interface shows
> anomalies in the association between memory and nodes.  The code
> was updated to ensure that all nodes found at boot are still available
> to subsequent DLPAR hotplug-memory operations, even if they are not
> needed at boot time.
> 
> Signed-off-by: Michael Bringmann 
> ---
> Changes in V2:
>   -- Simplify patches to ensure more nodes in possible map, removing
>  code from PowerPC numa.c that constrained possible map to size
>  of online map.
> ---
>  arch/powerpc/mm/numa.c |7 ---
>  1 file changed, 7 deletions(-)
> 
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 15c2dd5..18f3038 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -907,13 +907,6 @@ void __init initmem_init(void)
>  
>   memblock_dump_all();
>  
> - /*
> -  * Reduce the possible NUMA nodes to the online NUMA nodes,
> -  * since we do not support node hotplug. This ensures that  we
> -  * lower the maximum NUMA node ID to what is actually present.
> -  */
> - nodes_and(node_possible_map, node_possible_map, node_online_map);
> -

There is an overhead with turning this off if you have too many cgroups
with the memory controller. I think this fix was added for a pathological
test case. On my system I see 84 cgroups with 1 node, so the probable
overhead is 84*255*sizeof(struct mem_cgroup_tree_per_node).

I tried some patches to reduce the overhead, but those need more overhauling
and rework.

Balbir Singh.

Re: [PATCH V2 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

[Balbir Singh]

On Thu, 25 May 2017 12:37:40 -0500
Michael Bringmann  wrote:

> Removing or adding memory via the PowerPC hotplug interface shows
> anomalies in the association between memory and nodes.  The code
> was updated to ensure that all nodes found at boot are still available
> to subsequent DLPAR hotplug-memory operations, even if they are not
> needed at boot time.
> 
> Signed-off-by: Michael Bringmann 
> ---
> Changes in V2:
>   -- Simplify patches to ensure more nodes in possible map, removing
>  code from PowerPC numa.c that constrained possible map to size
>  of online map.
> ---
>  arch/powerpc/mm/numa.c |7 ---
>  1 file changed, 7 deletions(-)
> 
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 15c2dd5..18f3038 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -907,13 +907,6 @@ void __init initmem_init(void)
>  
>   memblock_dump_all();
>  
> - /*
> -  * Reduce the possible NUMA nodes to the online NUMA nodes,
> -  * since we do not support node hotplug. This ensures that  we
> -  * lower the maximum NUMA node ID to what is actually present.
> -  */
> - nodes_and(node_possible_map, node_possible_map, node_online_map);
> -

There is an overhead with turning this off if you have too many cgroups
with the memory controller. I think this fix was added for a pathological
test case. On my system I see 84 cgroups with 1 node, so the probable
overhead is 84*255*sizeof(struct mem_cgroup_tree_per_node).

I tried some patches to reduce the overhead, but those need more overhauling
and rework.

Balbir Singh.

Re: [PATCH] reset: hisilicon: Fix hi6220 module license

[Chen Feng]

looks good to me.

On 2017/5/25 17:22, Andreas Färber wrote:
> The hi6220_reset driver fails to load:
>
>   [   10.423640] hi6220_reset: module license 'unspecified' taints kernel.
>   [   10.423644] Disabling lock debugging due to kernel taint
>   [   10.423735] hi6220_reset: Unknown symbol regmap_write (err 0)
>   [   10.423747] hi6220_reset: Unknown symbol devm_kmalloc (err 0)
>   [   10.423759] hi6220_reset: Unknown symbol syscon_node_to_regmap (err 0)
>   [   10.423768] hi6220_reset: Unknown symbol reset_controller_register (err 
> 0)
>   [   10.423784] hi6220_reset: Unknown symbol __platform_driver_register (err 
> 0)
>
> Add a MODULE_LICENSE() to fix this.
>
> Fixes: 70b3590f639f ("reset: hi6220: fix modular build")
> Cc: Arnd Bergmann 
> Cc: Chen Feng 
> Signed-off-by: Andreas Färber 
> ---
>  drivers/reset/hisilicon/hi6220_reset.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/reset/hisilicon/hi6220_reset.c 
> b/drivers/reset/hisilicon/hi6220_reset.c
> index 35ce53edabf9..d5e5229308f2 100644
> --- a/drivers/reset/hisilicon/hi6220_reset.c
> +++ b/drivers/reset/hisilicon/hi6220_reset.c
> @@ -155,3 +155,5 @@ static int __init hi6220_reset_init(void)
>  }
>  
>  postcore_initcall(hi6220_reset_init);
> +
> +MODULE_LICENSE("GPL v2");

Re: [PATCH] reset: hisilicon: Fix hi6220 module license

[Chen Feng]

looks good to me.

On 2017/5/25 17:22, Andreas Färber wrote:
> The hi6220_reset driver fails to load:
>
>   [   10.423640] hi6220_reset: module license 'unspecified' taints kernel.
>   [   10.423644] Disabling lock debugging due to kernel taint
>   [   10.423735] hi6220_reset: Unknown symbol regmap_write (err 0)
>   [   10.423747] hi6220_reset: Unknown symbol devm_kmalloc (err 0)
>   [   10.423759] hi6220_reset: Unknown symbol syscon_node_to_regmap (err 0)
>   [   10.423768] hi6220_reset: Unknown symbol reset_controller_register (err 
> 0)
>   [   10.423784] hi6220_reset: Unknown symbol __platform_driver_register (err 
> 0)
>
> Add a MODULE_LICENSE() to fix this.
>
> Fixes: 70b3590f639f ("reset: hi6220: fix modular build")
> Cc: Arnd Bergmann 
> Cc: Chen Feng 
> Signed-off-by: Andreas Färber 
> ---
>  drivers/reset/hisilicon/hi6220_reset.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/reset/hisilicon/hi6220_reset.c 
> b/drivers/reset/hisilicon/hi6220_reset.c
> index 35ce53edabf9..d5e5229308f2 100644
> --- a/drivers/reset/hisilicon/hi6220_reset.c
> +++ b/drivers/reset/hisilicon/hi6220_reset.c
> @@ -155,3 +155,5 @@ static int __init hi6220_reset_init(void)
>  }
>  
>  postcore_initcall(hi6220_reset_init);
> +
> +MODULE_LICENSE("GPL v2");

Re: [PATCH v9 6/7] LPC: Add the ACPI LPC support

[kbuild test robot]

Hi zhichang.yuan,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.12-rc2 next-20170525]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Gabriele-Paoloni/LPC-legacy-ISA-I-O-support/20170526-033719
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `lpc_host_io_setup':
>> hisi_lpc.c:(.text+0x252): undefined reference to 
>> `acpi_set_logic_pio_resource'
   drivers/built-in.o: In function `acpi_scan_init':
   (.init.text+0x6742): undefined reference to `acpi_indirectio_scan_init'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v9 6/7] LPC: Add the ACPI LPC support

[kbuild test robot]

Hi zhichang.yuan,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.12-rc2 next-20170525]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Gabriele-Paoloni/LPC-legacy-ISA-I-O-support/20170526-033719
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `lpc_host_io_setup':
>> hisi_lpc.c:(.text+0x252): undefined reference to 
>> `acpi_set_logic_pio_resource'
   drivers/built-in.o: In function `acpi_scan_init':
   (.init.text+0x6742): undefined reference to `acpi_indirectio_scan_init'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

linux-next: Tree for May 26

[Stephen Rothwell]

Hi all,

Changes since 20170525:

New tree: realtek

Non-merge commits (relative to Linus' tree): 2775
 3084 files changed, 111008 insertions(+), 61381 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 261 trees (counting Linus' and 40 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (be941bf2e6a3 Merge tag 'scsi-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (05d8cba4a1e8 kbuild: skip install/check of 
headers right under uapi directories)
Merging arc-current/for-curr (2ea659a9ef48 Linux 4.12-rc1)
Merging arm-current/fixes (2ea659a9ef48 Linux 4.12-rc1)
Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card 
definitions)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (a4700a261072 powerpc: Add PPC_FEATURE userspace 
bits for SCV and DARN instructions)
Merging sparc/master (be941bf2e6a3 Merge tag 'scsi-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (797a93647a48 bonding: Don't update slave->link until ready 
to commit)
Merging ipsec/master (a486cd23661c xfrm: fix state migration copy replay 
sequence numbers)
Merging netfilter/master (fefa92679dbe netfilter: ctnetlink: fix incorrect 
nf_ct_put during hash resize)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (6d18c732b95c bridge: start hello_timer when 
enabling KERNEL_STP in br_stp_start)
Merging mac80211/master (1b57b6210f4e cfg80211: make 
cfg80211_sched_scan_results() work from atomic context)
Merging sound-current/for-linus (1fc2e41f7af4 ALSA: hda - apply 
STAC_9200_DELL_M22 quirk for Dell Latitude D430)
Merging pci-current/for-linus (4d071c323898 PCI/PM: Add needs_resume flag to 
avoid suspend complete optimization)
Merging driver-core.current/driver-core-linus (08332893e37a Linux 4.12-rc2)
Merging tty.current/tty-linus (59fe2cc8b1c3 serial: altera_uart: call iounmap() 
at driver remove)
Merging usb.current/usb-linus (8b77b0cfa99e Merge tag 'usb-ci-v4.12-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb into usb-linus)
Merging usb-gadget-fixes/fixes (a351e9b9fc24 Linux 4.11)
Merging usb-serial-fixes/usb-linus (08332893e37a Linux 4.12-rc2)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (a380b78b799b phy: qualcomm: phy-qcom-qmp: fix application of 
sizeof to pointer)
Merging staging.current/staging-linus (3d51b9562673 staging: ccree: add CRYPTO 
dependency)
Merging char-misc.current/char-misc-linus (cdc1daca1b9b MAINTAINERS: Change 
maintainer of genwqe driver)
Merging input-current/for-linus (a04f144059ac Input: elan_i2c - ignore signals 
when finishing updating firmware)
Merging crypto-current/master (f3ad587070d6 crypto: gcm - wait for crypto op 
not signal safe)
Merging ide/master (acfead32f3f9 ide: don't call memcpy with the same source 
and destination)
Merging vfio-fixes/for-linus (39da7c509acf Linux 4.11-rc6)
Merging kselftest-fixes/fixes (2ea659a9ef48 Linux 4.12-rc1)
Merging backlight-fixes/for-backli

linux-next: Tree for May 26

[Stephen Rothwell]

Hi all,

Changes since 20170525:

New tree: realtek

Non-merge commits (relative to Linus' tree): 2775
 3084 files changed, 111008 insertions(+), 61381 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 261 trees (counting Linus' and 40 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (be941bf2e6a3 Merge tag 'scsi-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (05d8cba4a1e8 kbuild: skip install/check of 
headers right under uapi directories)
Merging arc-current/for-curr (2ea659a9ef48 Linux 4.12-rc1)
Merging arm-current/fixes (2ea659a9ef48 Linux 4.12-rc1)
Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card 
definitions)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (a4700a261072 powerpc: Add PPC_FEATURE userspace 
bits for SCV and DARN instructions)
Merging sparc/master (be941bf2e6a3 Merge tag 'scsi-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (797a93647a48 bonding: Don't update slave->link until ready 
to commit)
Merging ipsec/master (a486cd23661c xfrm: fix state migration copy replay 
sequence numbers)
Merging netfilter/master (fefa92679dbe netfilter: ctnetlink: fix incorrect 
nf_ct_put during hash resize)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (6d18c732b95c bridge: start hello_timer when 
enabling KERNEL_STP in br_stp_start)
Merging mac80211/master (1b57b6210f4e cfg80211: make 
cfg80211_sched_scan_results() work from atomic context)
Merging sound-current/for-linus (1fc2e41f7af4 ALSA: hda - apply 
STAC_9200_DELL_M22 quirk for Dell Latitude D430)
Merging pci-current/for-linus (4d071c323898 PCI/PM: Add needs_resume flag to 
avoid suspend complete optimization)
Merging driver-core.current/driver-core-linus (08332893e37a Linux 4.12-rc2)
Merging tty.current/tty-linus (59fe2cc8b1c3 serial: altera_uart: call iounmap() 
at driver remove)
Merging usb.current/usb-linus (8b77b0cfa99e Merge tag 'usb-ci-v4.12-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb into usb-linus)
Merging usb-gadget-fixes/fixes (a351e9b9fc24 Linux 4.11)
Merging usb-serial-fixes/usb-linus (08332893e37a Linux 4.12-rc2)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (a380b78b799b phy: qualcomm: phy-qcom-qmp: fix application of 
sizeof to pointer)
Merging staging.current/staging-linus (3d51b9562673 staging: ccree: add CRYPTO 
dependency)
Merging char-misc.current/char-misc-linus (cdc1daca1b9b MAINTAINERS: Change 
maintainer of genwqe driver)
Merging input-current/for-linus (a04f144059ac Input: elan_i2c - ignore signals 
when finishing updating firmware)
Merging crypto-current/master (f3ad587070d6 crypto: gcm - wait for crypto op 
not signal safe)
Merging ide/master (acfead32f3f9 ide: don't call memcpy with the same source 
and destination)
Merging vfio-fixes/for-linus (39da7c509acf Linux 4.11-rc6)
Merging kselftest-fixes/fixes (2ea659a9ef48 Linux 4.12-rc1)
Merging backlight-fixes/for-backli

[PATCH 3/4] test: firmwware: add signature test to driver_data loader test

[AKASHI Takahiro]

Add the following tests:
No.15 - verify loaded data witha signature
No.16 - verify loaded data witha signature under signature enforcing

For each test, there are several test cases:
* no signature provided
* valid signature provided
* invalid signature provided

Signed-off-by: AKASHI Takahiro 
Cc: Luis R. Rodriguez 
---
 lib/test_driver_data.c  |  56 -
 tools/testing/selftests/firmware/driver_data.sh | 265 +++-
 2 files changed, 315 insertions(+), 6 deletions(-)

diff --git a/lib/test_driver_data.c b/lib/test_driver_data.c
index 422ea6289396..660cf9ff9ac0 100644
--- a/lib/test_driver_data.c
+++ b/lib/test_driver_data.c
@@ -85,6 +85,9 @@ int num_test_devs;
  * @api_min: API min version to use for the test.
  * @api_max: API max version to use for the test.
  * @api_name_postfix: API name postfix
+ * @no_sig_check: whether or not we wish to verify the driver_data with its
+ *  signature. If CONFIG_FIRMWARE_SIG_ENFORCE, passing the verification
+ *  is mandatory.
  * @test_result: a test may use this to collect the result from the call
  * of the driver_data_request_async() or driver_data_request_sync() calls
  * used in their tests. Note that for async calls this typically will be a
@@ -125,6 +128,7 @@ struct test_config {
u8 api_min;
u8 api_max;
char *api_name_postfix;
+   bool no_sig_check;
 
int test_result;
 };
@@ -345,6 +349,9 @@ static ssize_t config_show(struct device *dev,
len += snprintf(buf+len, PAGE_SIZE,
"keep:\t\t%s\n",
config->keep ? "true" : "false");
+   len += snprintf(buf+len, PAGE_SIZE,
+   "no_sig_check:\t%s\n",
+   config->no_sig_check ? "true" : "false");
 
mutex_unlock(_dev->config_mutex);
 
@@ -443,6 +450,9 @@ static int config_sync_req_cb(void *context,
 {
struct driver_data_test_device *test_dev = context;
 
+   if (unused_error)
+   return unused_error;
+
return config_load_data(test_dev, driver_data);
 }
 
@@ -455,14 +465,19 @@ static int trigger_config_sync(struct 
driver_data_test_device *test_dev)
  (config->optional ?
   DRIVER_DATA_REQ_OPTIONAL : 0) |
  (config->keep ?
-  DRIVER_DATA_REQ_KEEP : 0)),
+  DRIVER_DATA_REQ_KEEP : 0) |
+ (config->no_sig_check ?
+  DRIVER_DATA_REQ_NO_SIG_CHECK :
+  0)),
};
const struct driver_data_req_params req_params_opt_cb = {
DRIVER_DATA_DEFAULT_SYNC(config_sync_req_cb, test_dev),
DRIVER_DATA_SYNC_OPT_CB(config_sync_req_default_cb,
 test_dev),
.reqs = (config->optional ? DRIVER_DATA_REQ_OPTIONAL : 0) |
-   (config->keep ? DRIVER_DATA_REQ_KEEP : 0),
+   (config->keep ? DRIVER_DATA_REQ_KEEP : 0) |
+   (config->no_sig_check ? DRIVER_DATA_REQ_NO_SIG_CHECK :
+   0),
};
const struct driver_data_req_params *req_params;
 
@@ -528,20 +543,26 @@ static int trigger_config_async(struct 
driver_data_test_device *test_dev)
const struct driver_data_req_params req_params_default = {
DRIVER_DATA_DEFAULT_ASYNC(config_async_req_cb, test_dev),
.reqs = (config->optional ? DRIVER_DATA_REQ_OPTIONAL : 0) |
-   (config->keep ? DRIVER_DATA_REQ_KEEP : 0),
+   (config->keep ? DRIVER_DATA_REQ_KEEP : 0) |
+   (config->no_sig_check ? DRIVER_DATA_REQ_NO_SIG_CHECK :
+   0),
};
const struct driver_data_req_params req_params_opt_cb = {
DRIVER_DATA_DEFAULT_ASYNC(config_async_req_cb, test_dev),
DRIVER_DATA_ASYNC_OPT_CB(config_async_req_default_cb, test_dev),
.reqs = (config->optional ? DRIVER_DATA_REQ_OPTIONAL : 0) |
-   (config->keep ? DRIVER_DATA_REQ_KEEP : 0),
+   (config->keep ? DRIVER_DATA_REQ_KEEP : 0) |
+   (config->no_sig_check ? DRIVER_DATA_REQ_NO_SIG_CHECK :
+   0),
};
const struct driver_data_req_params req_params_api = {
DRIVER_DATA_API_CB(config_async_req_api_cb, test_dev),
DRIVER_DATA_API(config->api_min, config->api_max, 
config->api_name_postfix),
.reqs = (config->optional ? DRIVER_DATA_REQ_OPTIONAL : 0) |
(config->keep ? 

[PATCH 3/4] test: firmwware: add signature test to driver_data loader test

[AKASHI Takahiro]

Add the following tests:
No.15 - verify loaded data witha signature
No.16 - verify loaded data witha signature under signature enforcing

For each test, there are several test cases:
* no signature provided
* valid signature provided
* invalid signature provided

Signed-off-by: AKASHI Takahiro 
Cc: Luis R. Rodriguez 
---
 lib/test_driver_data.c  |  56 -
 tools/testing/selftests/firmware/driver_data.sh | 265 +++-
 2 files changed, 315 insertions(+), 6 deletions(-)

diff --git a/lib/test_driver_data.c b/lib/test_driver_data.c
index 422ea6289396..660cf9ff9ac0 100644
--- a/lib/test_driver_data.c
+++ b/lib/test_driver_data.c
@@ -85,6 +85,9 @@ int num_test_devs;
  * @api_min: API min version to use for the test.
  * @api_max: API max version to use for the test.
  * @api_name_postfix: API name postfix
+ * @no_sig_check: whether or not we wish to verify the driver_data with its
+ *  signature. If CONFIG_FIRMWARE_SIG_ENFORCE, passing the verification
+ *  is mandatory.
  * @test_result: a test may use this to collect the result from the call
  * of the driver_data_request_async() or driver_data_request_sync() calls
  * used in their tests. Note that for async calls this typically will be a
@@ -125,6 +128,7 @@ struct test_config {
u8 api_min;
u8 api_max;
char *api_name_postfix;
+   bool no_sig_check;
 
int test_result;
 };
@@ -345,6 +349,9 @@ static ssize_t config_show(struct device *dev,
len += snprintf(buf+len, PAGE_SIZE,
"keep:\t\t%s\n",
config->keep ? "true" : "false");
+   len += snprintf(buf+len, PAGE_SIZE,
+   "no_sig_check:\t%s\n",
+   config->no_sig_check ? "true" : "false");
 
mutex_unlock(_dev->config_mutex);
 
@@ -443,6 +450,9 @@ static int config_sync_req_cb(void *context,
 {
struct driver_data_test_device *test_dev = context;
 
+   if (unused_error)
+   return unused_error;
+
return config_load_data(test_dev, driver_data);
 }
 
@@ -455,14 +465,19 @@ static int trigger_config_sync(struct 
driver_data_test_device *test_dev)
  (config->optional ?
   DRIVER_DATA_REQ_OPTIONAL : 0) |
  (config->keep ?
-  DRIVER_DATA_REQ_KEEP : 0)),
+  DRIVER_DATA_REQ_KEEP : 0) |
+ (config->no_sig_check ?
+  DRIVER_DATA_REQ_NO_SIG_CHECK :
+  0)),
};
const struct driver_data_req_params req_params_opt_cb = {
DRIVER_DATA_DEFAULT_SYNC(config_sync_req_cb, test_dev),
DRIVER_DATA_SYNC_OPT_CB(config_sync_req_default_cb,
 test_dev),
.reqs = (config->optional ? DRIVER_DATA_REQ_OPTIONAL : 0) |
-   (config->keep ? DRIVER_DATA_REQ_KEEP : 0),
+   (config->keep ? DRIVER_DATA_REQ_KEEP : 0) |
+   (config->no_sig_check ? DRIVER_DATA_REQ_NO_SIG_CHECK :
+   0),
};
const struct driver_data_req_params *req_params;
 
@@ -528,20 +543,26 @@ static int trigger_config_async(struct 
driver_data_test_device *test_dev)
const struct driver_data_req_params req_params_default = {
DRIVER_DATA_DEFAULT_ASYNC(config_async_req_cb, test_dev),
.reqs = (config->optional ? DRIVER_DATA_REQ_OPTIONAL : 0) |
-   (config->keep ? DRIVER_DATA_REQ_KEEP : 0),
+   (config->keep ? DRIVER_DATA_REQ_KEEP : 0) |
+   (config->no_sig_check ? DRIVER_DATA_REQ_NO_SIG_CHECK :
+   0),
};
const struct driver_data_req_params req_params_opt_cb = {
DRIVER_DATA_DEFAULT_ASYNC(config_async_req_cb, test_dev),
DRIVER_DATA_ASYNC_OPT_CB(config_async_req_default_cb, test_dev),
.reqs = (config->optional ? DRIVER_DATA_REQ_OPTIONAL : 0) |
-   (config->keep ? DRIVER_DATA_REQ_KEEP : 0),
+   (config->keep ? DRIVER_DATA_REQ_KEEP : 0) |
+   (config->no_sig_check ? DRIVER_DATA_REQ_NO_SIG_CHECK :
+   0),
};
const struct driver_data_req_params req_params_api = {
DRIVER_DATA_API_CB(config_async_req_api_cb, test_dev),
DRIVER_DATA_API(config->api_min, config->api_max, 
config->api_name_postfix),
.reqs = (config->optional ? DRIVER_DATA_REQ_OPTIONAL : 0) |
(config->keep ? DRIVER_DATA_REQ_KEEP : 0) |
-  

[PATCH 4/4] firmware: document signature verification for driver data

[AKASHI Takahiro]

add descriptions and usage about firmware signing in driver data APIs.

Signed-off-by: AKASHI Takahiro 
Cc: Luis R. Rodriguez 
---
 Documentation/driver-api/firmware/driver_data.rst  |  6 ++
 .../driver-api/firmware/fallback-mechanisms.rst|  5 +-
 Documentation/driver-api/firmware/signing.rst  | 81 ++
 3 files changed, 90 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/driver-api/firmware/signing.rst

diff --git a/Documentation/driver-api/firmware/driver_data.rst 
b/Documentation/driver-api/firmware/driver_data.rst
index be7c7ff99151..cdc47144a8b2 100644
--- a/Documentation/driver-api/firmware/driver_data.rst
+++ b/Documentation/driver-api/firmware/driver_data.rst
@@ -94,6 +94,12 @@ in these callbacks it frees it for you by default after 
callback handlers
 are issued. If you wish to keep the driver data around after your callbacks
 you must specify this through the driver data request parameter data structure.
 
+Signature verification
+==
+
+  * `data signing`_
+.. _`data signing`: ./signing.rst
+
 Driver data private internal functionality
 ==
 
diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst 
b/Documentation/driver-api/firmware/fallback-mechanisms.rst
index d19354794e67..e557d6630330 100644
--- a/Documentation/driver-api/firmware/fallback-mechanisms.rst
+++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst
@@ -81,11 +81,12 @@ and a file upload firmware into:
 
   * /sys/$DEVPATH/loading
   * /sys/$DEVPATH/data
+  * /sys/$DEVPATH/sig_data
 
 To upload firmware you will echo 1 onto the loading file to indicate
 you are loading firmware. You then cat the firmware into the data file,
-and you notify the kernel the firmware is ready by echo'ing 0 onto
-the loading file.
+optionally its signature file, and you notify the kernel the firmware is
+ready by echo'ing 0 onto the loading file.
 
 The firmware device used to help load firmware using sysfs is only created if
 direct firmware loading fails and if the fallback mechanism is enabled for your
diff --git a/Documentation/driver-api/firmware/signing.rst 
b/Documentation/driver-api/firmware/signing.rst
new file mode 100644
index ..2dbee104700e
--- /dev/null
+++ b/Documentation/driver-api/firmware/signing.rst
@@ -0,0 +1,81 @@
+
+Kernel firmware signing facility
+
+
+Overview
+
+
+The kernel firmware signing facility enables to cryptographically sign
+firmware files on a system using the same keys used for module signing.
+Firmware files's signatures consist of PKCS#7 messages of the respective
+firmware file. A firmware file named foo.bin, would have its respective
+signature on the filesystem as foo.bin.p7s. When firmware signature
+checking is enabled (FIRMWARE_SIG) and when one of the above APIs is used
+against foo.bin, the file foo.bin.p7s will also be looked for. If
+FIRMWARE_SIG_FORCE is enabled the foo.bin file will only be allowed to
+be returned to callers of the above APIs if and only if the foo.bin.p7s
+file is confirmed to be a valid signature of the foo.bin file. If
+FIRMWARE_SIG_FORCE is not enabled and only FIRMWARE_SIG is enabled the
+kernel will be permissive and enabled unsigned firmware files, or firmware
+files with incorrect signatures. If FIRMWARE_SIG is not enabled the
+signature file is ignored completely.
+
+Firmware signing increases security by making it harder to load a malicious
+firmware into the kernel.  The firmware signature checking is done by the
+kernel so that it is not necessary to have trusted userspace bits.
+
+Configuring firmware signing
+
+
+The firmware signing facility is enabled by going to the section::
+
+  -> Device Drivers
+-> Generic Driver Options
+  -> Userspace firmware loading support (FW_LOADER [=y])
+-> Firmware signature verification (FIRMWARE_SIG [=y])
+
+If you want to not allow unsigned firmware to be loaded you should
+enable::
+
+-> Require all firmware to be validly signed (FIRMWARE_SIG_FORCE [=y])
+
+under the same menu.
+
+Using signing keys
+==
+
+The same key types used for module signing can be used for firmware
+signing. For details on that refer to `Kernel module signing`_.
+
+.. _`Kernel module signing`: /admin-guide/module-signing.rst
+
+You will need:
+
+  A) A DER-encoded X.509 certificate containing the public key.
+  B) A DER-encoded PKCS#7 message containing the signatures, these are
+ the .p7s files.
+  C) A binary blob that is the detached data for the PKCS#7 message, this
+ is the firmware files
+
+A) is must be made available to the kernel. One way to do this is to provide a
+DER-encoded in the source directory as .x509 when you build the kernel.
+
+Signing firmware files
+==
+
+To generate a DER-encoded PKCS#7 signature 

[PATCH 2/4] scripts: sign-file: add firmware-signing option

[AKASHI Takahiro]

This new option (-f) allows us to create a signature file (*.p7s) for
firmware binary.

Signed-off-by: AKASHI Takahiro 
Cc: Luis R. Rodriguez 
---
 scripts/sign-file.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/scripts/sign-file.c b/scripts/sign-file.c
index fbd34b8e8f57..211f6531fd7e 100644
--- a/scripts/sign-file.c
+++ b/scripts/sign-file.c
@@ -242,8 +242,11 @@ int main(int argc, char **argv)
 #endif
 
do {
-   opt = getopt(argc, argv, "sdpk");
+   opt = getopt(argc, argv, "fsdpk");
switch (opt) {
+   case 'f':
+ use_signed_attrs = 0;
+ sign_only = true; save_sig = true; break;
case 's': raw_sig = true; break;
case 'p': save_sig = true; break;
case 'd': sign_only = true; save_sig = true; break;
-- 
2.11.1

[PATCH 4/4] firmware: document signature verification for driver data

[AKASHI Takahiro]

add descriptions and usage about firmware signing in driver data APIs.

Signed-off-by: AKASHI Takahiro 
Cc: Luis R. Rodriguez 
---
 Documentation/driver-api/firmware/driver_data.rst  |  6 ++
 .../driver-api/firmware/fallback-mechanisms.rst|  5 +-
 Documentation/driver-api/firmware/signing.rst  | 81 ++
 3 files changed, 90 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/driver-api/firmware/signing.rst

diff --git a/Documentation/driver-api/firmware/driver_data.rst 
b/Documentation/driver-api/firmware/driver_data.rst
index be7c7ff99151..cdc47144a8b2 100644
--- a/Documentation/driver-api/firmware/driver_data.rst
+++ b/Documentation/driver-api/firmware/driver_data.rst
@@ -94,6 +94,12 @@ in these callbacks it frees it for you by default after 
callback handlers
 are issued. If you wish to keep the driver data around after your callbacks
 you must specify this through the driver data request parameter data structure.
 
+Signature verification
+==
+
+  * `data signing`_
+.. _`data signing`: ./signing.rst
+
 Driver data private internal functionality
 ==
 
diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst 
b/Documentation/driver-api/firmware/fallback-mechanisms.rst
index d19354794e67..e557d6630330 100644
--- a/Documentation/driver-api/firmware/fallback-mechanisms.rst
+++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst
@@ -81,11 +81,12 @@ and a file upload firmware into:
 
   * /sys/$DEVPATH/loading
   * /sys/$DEVPATH/data
+  * /sys/$DEVPATH/sig_data
 
 To upload firmware you will echo 1 onto the loading file to indicate
 you are loading firmware. You then cat the firmware into the data file,
-and you notify the kernel the firmware is ready by echo'ing 0 onto
-the loading file.
+optionally its signature file, and you notify the kernel the firmware is
+ready by echo'ing 0 onto the loading file.
 
 The firmware device used to help load firmware using sysfs is only created if
 direct firmware loading fails and if the fallback mechanism is enabled for your
diff --git a/Documentation/driver-api/firmware/signing.rst 
b/Documentation/driver-api/firmware/signing.rst
new file mode 100644
index ..2dbee104700e
--- /dev/null
+++ b/Documentation/driver-api/firmware/signing.rst
@@ -0,0 +1,81 @@
+
+Kernel firmware signing facility
+
+
+Overview
+
+
+The kernel firmware signing facility enables to cryptographically sign
+firmware files on a system using the same keys used for module signing.
+Firmware files's signatures consist of PKCS#7 messages of the respective
+firmware file. A firmware file named foo.bin, would have its respective
+signature on the filesystem as foo.bin.p7s. When firmware signature
+checking is enabled (FIRMWARE_SIG) and when one of the above APIs is used
+against foo.bin, the file foo.bin.p7s will also be looked for. If
+FIRMWARE_SIG_FORCE is enabled the foo.bin file will only be allowed to
+be returned to callers of the above APIs if and only if the foo.bin.p7s
+file is confirmed to be a valid signature of the foo.bin file. If
+FIRMWARE_SIG_FORCE is not enabled and only FIRMWARE_SIG is enabled the
+kernel will be permissive and enabled unsigned firmware files, or firmware
+files with incorrect signatures. If FIRMWARE_SIG is not enabled the
+signature file is ignored completely.
+
+Firmware signing increases security by making it harder to load a malicious
+firmware into the kernel.  The firmware signature checking is done by the
+kernel so that it is not necessary to have trusted userspace bits.
+
+Configuring firmware signing
+
+
+The firmware signing facility is enabled by going to the section::
+
+  -> Device Drivers
+-> Generic Driver Options
+  -> Userspace firmware loading support (FW_LOADER [=y])
+-> Firmware signature verification (FIRMWARE_SIG [=y])
+
+If you want to not allow unsigned firmware to be loaded you should
+enable::
+
+-> Require all firmware to be validly signed (FIRMWARE_SIG_FORCE [=y])
+
+under the same menu.
+
+Using signing keys
+==
+
+The same key types used for module signing can be used for firmware
+signing. For details on that refer to `Kernel module signing`_.
+
+.. _`Kernel module signing`: /admin-guide/module-signing.rst
+
+You will need:
+
+  A) A DER-encoded X.509 certificate containing the public key.
+  B) A DER-encoded PKCS#7 message containing the signatures, these are
+ the .p7s files.
+  C) A binary blob that is the detached data for the PKCS#7 message, this
+ is the firmware files
+
+A) is must be made available to the kernel. One way to do this is to provide a
+DER-encoded in the source directory as .x509 when you build the kernel.
+
+Signing firmware files
+==
+
+To generate a DER-encoded PKCS#7 signature message for each firmware file
+you can use 

[PATCH 2/4] scripts: sign-file: add firmware-signing option

[AKASHI Takahiro]

This new option (-f) allows us to create a signature file (*.p7s) for
firmware binary.

Signed-off-by: AKASHI Takahiro 
Cc: Luis R. Rodriguez 
---
 scripts/sign-file.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/scripts/sign-file.c b/scripts/sign-file.c
index fbd34b8e8f57..211f6531fd7e 100644
--- a/scripts/sign-file.c
+++ b/scripts/sign-file.c
@@ -242,8 +242,11 @@ int main(int argc, char **argv)
 #endif
 
do {
-   opt = getopt(argc, argv, "sdpk");
+   opt = getopt(argc, argv, "fsdpk");
switch (opt) {
+   case 'f':
+ use_signed_attrs = 0;
+ sign_only = true; save_sig = true; break;
case 's': raw_sig = true; break;
case 'p': save_sig = true; break;
case 'd': sign_only = true; save_sig = true; break;
-- 
2.11.1

[PATCH 1/4] firmware: add firmware signing

[AKASHI Takahiro]

Systems that have module signing currently enabled may
wish to extend vetting of firmware passed to the kernel
as well. We can re-use most of the code for module signing
for firmware signature verification and signing. This will
also later enable re-use of this same code for subsystems
that wish to provide their own cryptographic verification
requirements on userspace data needed.

Contrary to module signing, the signature files are expected
to be completely detached for practical and licensing puposes.
If you have foo.bin, you'll need foo.bin.p7s file present
for firmware signing.

Firmware signing is per-data per device and if this feature is
enabled permissively (by default), both valid and invalid firmware,
which can be unsigned, signed by non-trusted key, or even one
with invalid digest, will be loaded, just leaving a warning message
in the kernel log.

On the othe hand, in enforcing mode, which is enabled by either
a kernel configuration (CONFIG_FIRMWARE_SIG_FORCE) or a module
parameter (fw_sig_enforce), only the verified firmware are
allowed to be loaded.

There is one driver data option, DRIVER_DATA_REQ_NO_SIG_CHECK,
which will skip signature verification check at load time
even in enforcing mode.
This option is solely for non security-sensitive data.
Please also note any firmware loaded with request_firmware()
will not be affected by firmware signing.

Contrary to module signing, we do not taint the kernel in
the permissive fw signing mode due to restrictions on the
firmware_class API, extensions to enable this are expected
however in the future.

Cc: Rusty Russell 
Cc: David Howells 
Cc: Ming Lei 
Cc: Seth Forshee 
Cc: Kyle McMartin 
Cc: David Woodhouse 
Signed-off-by: Luis R. Rodriguez 
[akashi:migrated to driver data APIs]
Signed-off-by: AKASHI Takahiro 
---
 drivers/base/Kconfig  |  25 +
 drivers/base/firmware_class.c | 211 +++---
 include/linux/driver_data.h   |   5 +
 3 files changed, 229 insertions(+), 12 deletions(-)

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 74779ee3d3b1..4c9600437396 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -79,6 +79,31 @@ config FW_LOADER
  require userspace firmware loading support, but a module built
  out-of-tree does.
 
+config FIRMWARE_SIG
+   bool "Firmware signature verification"
+   depends on FW_LOADER
+   select SYSTEM_DATA_VERIFICATION
+   help
+ Check firmware files for valid signatures upon load: if the firmware
+ was called foo.bin, a respective foo.bin.p7s is expected to be
+ present as the signature in the same directory.
+
+ This configuration only affects drivers with driver_data APIs,
+ disabling DRIVER_DATA_REQ_NO_SIG_CHECK.
+
+ For more information see Documentation/driver-api/firmware/signing.rst
+
+config FIRMWARE_SIG_FORCE
+   bool "Require all firmware to be validly signed"
+   depends on FIRMWARE_SIG
+   help
+ Reject unsigned files or signed files for which we don't have
+ a trusted key. Without this, you'll only get a record on kernel
+ log and yet the firmware will be loaded.
+
+ This configuration only affects drivers with driver_data APIs,
+ disabling DRIVER_DATA_REQ_NO_SIG_CHECK.
+
 config FIRMWARE_IN_KERNEL
bool "Include in-kernel firmware blobs in kernel binary"
depends on FW_LOADER
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index e87e91bcd8f8..590a2a834fec 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -146,6 +147,9 @@ struct driver_data_params {
  * o request_firmware_nowait():__DATA_REQ_FIRMWARE_NOWAIT()
  */
 #define __DATA_REQ_FIRMWARE()  \
+   .req_params = { \
+   .reqs = DRIVER_DATA_REQ_NO_SIG_CHECK,   \
+   },  \
.priv_params = {\
.priv_reqs = DRIVER_DATA_PRIV_REQ_FALLBACK |\
 DRIVER_DATA_PRIV_REQ_FALLBACK_UEVENT,  \
@@ -153,7 +157,8 @@ struct driver_data_params {
 
 #define __DATA_REQ_FIRMWARE_DIRECT()   \
.req_params = { \
-   .reqs = DRIVER_DATA_REQ_OPTIONAL,   \
+   .reqs = DRIVER_DATA_REQ_OPTIONAL |  \
+   DRIVER_DATA_REQ_NO_SIG_CHECK,   \
}, 

[PATCH 1/4] firmware: add firmware signing

[AKASHI Takahiro]

Systems that have module signing currently enabled may
wish to extend vetting of firmware passed to the kernel
as well. We can re-use most of the code for module signing
for firmware signature verification and signing. This will
also later enable re-use of this same code for subsystems
that wish to provide their own cryptographic verification
requirements on userspace data needed.

Contrary to module signing, the signature files are expected
to be completely detached for practical and licensing puposes.
If you have foo.bin, you'll need foo.bin.p7s file present
for firmware signing.

Firmware signing is per-data per device and if this feature is
enabled permissively (by default), both valid and invalid firmware,
which can be unsigned, signed by non-trusted key, or even one
with invalid digest, will be loaded, just leaving a warning message
in the kernel log.

On the othe hand, in enforcing mode, which is enabled by either
a kernel configuration (CONFIG_FIRMWARE_SIG_FORCE) or a module
parameter (fw_sig_enforce), only the verified firmware are
allowed to be loaded.

There is one driver data option, DRIVER_DATA_REQ_NO_SIG_CHECK,
which will skip signature verification check at load time
even in enforcing mode.
This option is solely for non security-sensitive data.
Please also note any firmware loaded with request_firmware()
will not be affected by firmware signing.

Contrary to module signing, we do not taint the kernel in
the permissive fw signing mode due to restrictions on the
firmware_class API, extensions to enable this are expected
however in the future.

Cc: Rusty Russell 
Cc: David Howells 
Cc: Ming Lei 
Cc: Seth Forshee 
Cc: Kyle McMartin 
Cc: David Woodhouse 
Signed-off-by: Luis R. Rodriguez 
[akashi:migrated to driver data APIs]
Signed-off-by: AKASHI Takahiro 
---
 drivers/base/Kconfig  |  25 +
 drivers/base/firmware_class.c | 211 +++---
 include/linux/driver_data.h   |   5 +
 3 files changed, 229 insertions(+), 12 deletions(-)

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 74779ee3d3b1..4c9600437396 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -79,6 +79,31 @@ config FW_LOADER
  require userspace firmware loading support, but a module built
  out-of-tree does.
 
+config FIRMWARE_SIG
+   bool "Firmware signature verification"
+   depends on FW_LOADER
+   select SYSTEM_DATA_VERIFICATION
+   help
+ Check firmware files for valid signatures upon load: if the firmware
+ was called foo.bin, a respective foo.bin.p7s is expected to be
+ present as the signature in the same directory.
+
+ This configuration only affects drivers with driver_data APIs,
+ disabling DRIVER_DATA_REQ_NO_SIG_CHECK.
+
+ For more information see Documentation/driver-api/firmware/signing.rst
+
+config FIRMWARE_SIG_FORCE
+   bool "Require all firmware to be validly signed"
+   depends on FIRMWARE_SIG
+   help
+ Reject unsigned files or signed files for which we don't have
+ a trusted key. Without this, you'll only get a record on kernel
+ log and yet the firmware will be loaded.
+
+ This configuration only affects drivers with driver_data APIs,
+ disabling DRIVER_DATA_REQ_NO_SIG_CHECK.
+
 config FIRMWARE_IN_KERNEL
bool "Include in-kernel firmware blobs in kernel binary"
depends on FW_LOADER
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index e87e91bcd8f8..590a2a834fec 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -146,6 +147,9 @@ struct driver_data_params {
  * o request_firmware_nowait():__DATA_REQ_FIRMWARE_NOWAIT()
  */
 #define __DATA_REQ_FIRMWARE()  \
+   .req_params = { \
+   .reqs = DRIVER_DATA_REQ_NO_SIG_CHECK,   \
+   },  \
.priv_params = {\
.priv_reqs = DRIVER_DATA_PRIV_REQ_FALLBACK |\
 DRIVER_DATA_PRIV_REQ_FALLBACK_UEVENT,  \
@@ -153,7 +157,8 @@ struct driver_data_params {
 
 #define __DATA_REQ_FIRMWARE_DIRECT()   \
.req_params = { \
-   .reqs = DRIVER_DATA_REQ_OPTIONAL,   \
+   .reqs = DRIVER_DATA_REQ_OPTIONAL |  \
+   DRIVER_DATA_REQ_NO_SIG_CHECK,   \
},  \
.priv_params = {\
.priv_reqs = DRIVER_DATA_PRIV_REQ_FALLBACK |\

[PATCH 0/4] firmware: signature verification

[AKASHI Takahiro]

This is my first version of patch series for adding signature
verification to firmware loading.

The original idea and code came from the work by Luis some time ago,
and I migrated it with some improvements to new driver data APIs,
leaving request_firmware() intact.

For details about how it works, please see the commit message of
patch#1 and the document under Documentation/driver-api/firmware.

Please note that patch#3, test script, is still a bit rough-edged,
especially that we have to prepare some data files in advance.
I will try to improve it for better automation.

For you convenience, the patch is available:
https://git.linaro.org/people/takahiro.akashi/linux-aarch64.git
firmware/signature

AKASHI Takahiro (4):
  firmware: add firmware signing
  scripts: sign-file: add firmware-signing option
  test: firmwware: add signature test to driver_data loader test
  firmware: document signature verification for driver data

 Documentation/driver-api/firmware/driver_data.rst  |   6 +
 .../driver-api/firmware/fallback-mechanisms.rst|   5 +-
 Documentation/driver-api/firmware/signing.rst  |  81 +++
 drivers/base/Kconfig   |  25 ++
 drivers/base/firmware_class.c  | 211 +++-
 include/linux/driver_data.h|   5 +
 lib/test_driver_data.c |  56 -
 scripts/sign-file.c|   5 +-
 tools/testing/selftests/firmware/driver_data.sh| 265 -
 9 files changed, 638 insertions(+), 21 deletions(-)
 create mode 100644 Documentation/driver-api/firmware/signing.rst

-- 
2.11.1

[PATCH 0/4] firmware: signature verification

[AKASHI Takahiro]

This is my first version of patch series for adding signature
verification to firmware loading.

The original idea and code came from the work by Luis some time ago,
and I migrated it with some improvements to new driver data APIs,
leaving request_firmware() intact.

For details about how it works, please see the commit message of
patch#1 and the document under Documentation/driver-api/firmware.

Please note that patch#3, test script, is still a bit rough-edged,
especially that we have to prepare some data files in advance.
I will try to improve it for better automation.

For you convenience, the patch is available:
https://git.linaro.org/people/takahiro.akashi/linux-aarch64.git
firmware/signature

AKASHI Takahiro (4):
  firmware: add firmware signing
  scripts: sign-file: add firmware-signing option
  test: firmwware: add signature test to driver_data loader test
  firmware: document signature verification for driver data

 Documentation/driver-api/firmware/driver_data.rst  |   6 +
 .../driver-api/firmware/fallback-mechanisms.rst|   5 +-
 Documentation/driver-api/firmware/signing.rst  |  81 +++
 drivers/base/Kconfig   |  25 ++
 drivers/base/firmware_class.c  | 211 +++-
 include/linux/driver_data.h|   5 +
 lib/test_driver_data.c |  56 -
 scripts/sign-file.c|   5 +-
 tools/testing/selftests/firmware/driver_data.sh| 265 -
 9 files changed, 638 insertions(+), 21 deletions(-)
 create mode 100644 Documentation/driver-api/firmware/signing.rst

-- 
2.11.1

[PATCH] staging: lustre: Replace printk_ratelimited with pr_warn_ratelimited

[Konrad Malkowski]

This patch fixes the checkpoint.pl warning:

WARNING: Prefer printk_ratelimited or pr__ratelimited to
printk_ratelimit

Signed-off-by: Konrad Malkowski 
---
 drivers/staging/lustre/lnet/libcfs/tracefile.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/lustre/lnet/libcfs/tracefile.c 
b/drivers/staging/lustre/lnet/libcfs/tracefile.c
index 9599b74..a0efea4 100644
--- a/drivers/staging/lustre/lnet/libcfs/tracefile.c
+++ b/drivers/staging/lustre/lnet/libcfs/tracefile.c
@@ -191,10 +191,9 @@ cfs_trace_get_tage_try(struct cfs_trace_cpu_data *tcd, 
unsigned long len)
} else {
tage = cfs_tage_alloc(GFP_ATOMIC);
if (unlikely(!tage)) {
-   if ((!memory_pressure_get() ||
-in_interrupt()) && printk_ratelimit())
-   pr_warn("cannot allocate a tage 
(%ld)\n",
-   tcd->tcd_cur_pages);
+   if (!memory_pressure_get() || in_interrupt())
+   pr_warn_ratelimited("cannot allocate a 
tage (%ld)\n",
+   tcd->tcd_cur_pages);
return NULL;
}
}
@@ -229,9 +228,8 @@ static void cfs_tcd_shrink(struct cfs_trace_cpu_data *tcd)
 * from here: this will lead to infinite recursion.
 */
 
-   if (printk_ratelimit())
-   pr_warn("debug daemon buffer overflowed; discarding 10%% of 
pages (%d of %ld)\n",
-   pgcount + 1, tcd->tcd_cur_pages);
+   pr_warn_ratelimited("debug daemon buffer overflowed; discarding 10%% of 
pages (%d of %ld)\n",
+   pgcount + 1, tcd->tcd_cur_pages);
 
INIT_LIST_HEAD(_pages);
 
-- 
2.7.4

[PATCH] staging: lustre: Replace printk_ratelimited with pr_warn_ratelimited

[Konrad Malkowski]

This patch fixes the checkpoint.pl warning:

WARNING: Prefer printk_ratelimited or pr__ratelimited to
printk_ratelimit

Signed-off-by: Konrad Malkowski 
---
 drivers/staging/lustre/lnet/libcfs/tracefile.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/lustre/lnet/libcfs/tracefile.c 
b/drivers/staging/lustre/lnet/libcfs/tracefile.c
index 9599b74..a0efea4 100644
--- a/drivers/staging/lustre/lnet/libcfs/tracefile.c
+++ b/drivers/staging/lustre/lnet/libcfs/tracefile.c
@@ -191,10 +191,9 @@ cfs_trace_get_tage_try(struct cfs_trace_cpu_data *tcd, 
unsigned long len)
} else {
tage = cfs_tage_alloc(GFP_ATOMIC);
if (unlikely(!tage)) {
-   if ((!memory_pressure_get() ||
-in_interrupt()) && printk_ratelimit())
-   pr_warn("cannot allocate a tage 
(%ld)\n",
-   tcd->tcd_cur_pages);
+   if (!memory_pressure_get() || in_interrupt())
+   pr_warn_ratelimited("cannot allocate a 
tage (%ld)\n",
+   tcd->tcd_cur_pages);
return NULL;
}
}
@@ -229,9 +228,8 @@ static void cfs_tcd_shrink(struct cfs_trace_cpu_data *tcd)
 * from here: this will lead to infinite recursion.
 */
 
-   if (printk_ratelimit())
-   pr_warn("debug daemon buffer overflowed; discarding 10%% of 
pages (%d of %ld)\n",
-   pgcount + 1, tcd->tcd_cur_pages);
+   pr_warn_ratelimited("debug daemon buffer overflowed; discarding 10%% of 
pages (%d of %ld)\n",
+   pgcount + 1, tcd->tcd_cur_pages);
 
INIT_LIST_HEAD(_pages);
 
-- 
2.7.4