[PATCH v7 0/7] perf report: Show branch type
v7:
---
Redefine the common branch types according to review comments from
Michael Ellerman
Now the patch series just defines a minimum but more common set of
branch types.
PERF_BR_NONE: unknown
PERF_BR_COND：conditional
PERF_BR_UNCOND : unconditional
PERF_BR_IND : indirect
PERF_BR_CALL: function call
PERF_BR_IND_CALL: indirect function call
PERF_BR_RET : function return
PERF_BR_SYSCALL : syscall
PERF_BR_SYSRET : syscall return
PERF_BR_COND_CALL : conditional function call
PERF_BR_COND_RET: conditional function return
v6:
---
Update according to the review comments from
Jiri Olsa . Major modifications are:
1. Move that multiline conditional code inside {} brackets.
2. Move branch_type_stat_display() from builtin-report.c to
branch.c. Move branch_type_str() from callchain.c to
branch.c.
3. Keep the original branch info display order, that is:
predicted, abort, cycles, iterations
v5:
---
Mainly the v5 patch series are updated according to
comments from Jiri Olsa .
The kernel part doesn't have functional change. It just
solve the merge issue.
In userspace, the functions of branch type counting and
branch type name resolving are moved to the new files:
util/branch.c, util/branch.h.
And refactor the branch info printing code for better
maintenance.
Not changed (or just fix merge issue):
perf/core: Define the common branch type classification
perf/x86/intel: Record branch type
perf record: Create a new option save_type in --branch-filter
New patches:
perf report: Refactor the branch info printing code
perf util: Create branch.c/.h for common branch functions
Changed:
perf report: Show branch type statistics for stdio mode
perf report: Show branch type in callchain entry
v4:
---
1. Describe the major changes in patch description.
Thanks for Peter Zijlstra's reminding.
2. Initialize branch type to 0 in intel_pmu_lbr_read_32 and
intel_pmu_lbr_read_64. Remove the invalid else code in
intel_pmu_lbr_filter.
v3:
---
1. Move the JCC forward/backward and cross page computing from
kernel to userspace.
2. Use lookup table to replace original switch/case processing.
Changed:
perf/core: Define the common branch type classification
perf/x86/intel: Record branch type
perf report: Show branch type statistics for stdio mode
perf report: Show branch type in callchain entry
Not changed:
perf record: Create a new option save_type in --branch-filter
v2:
---
1. Use 4 bits in perf_branch_entry to record branch type.
2. Pull out some common branch types from FAR_BRANCH. Now the branch
types defined in perf_event.h:
Jin Yao (7):
perf/core: Define the common branch type classification
perf/x86/intel: Record branch type
perf record: Create a new option save_type in --branch-filter
perf report: Refactor the branch info printing code
perf util: Create branch.c/.h for common branch functions
perf report: Show branch type statistics for stdio mode
perf report: Show branch type in callchain entry
arch/x86/events/intel/lbr.c | 53 +-
include/uapi/linux/perf_event.h | 27 -
tools/include/uapi/linux/perf_event.h| 27 -
tools/perf/Documentation/perf-record.txt | 1 +
tools/perf/builtin-report.c | 25 +
tools/perf/util/Build| 1 +
tools/perf/util/branch.c | 166 +++
tools/perf/util/branch.h | 25 +
tools/perf/util/callchain.c | 140 ++
tools/perf/util/callchain.h | 5 +-
tools/perf/util/event.h | 3 +-
tools/perf/util/hist.c | 5 +-
tools/perf/util/machine.c| 26 +++--
tools/perf/util/parse-branch-options.c | 1 +
14 files changed, 421 insertions(+), 84 deletions(-)
create mode 100644 tools/perf/util/branch.c
create mode 100644 tools/perf/util/branch.h
--
2.7.4
[PATCH v7 7/7] perf report: Show branch type in callchain entry
Show branch type in callchain entry. The branch type is printed
with other LBR information (such as cycles/abort/...).
For example:
perf record -g -j any,save_type
perf report --branch-history --stdio --no-children
38.50% div.c:45[.] maindiv
|
---main div.c:42 (RET CROSS_2M cycles:2)
compute_flag div.c:28 (cycles:2)
compute_flag div.c:27 (RET CROSS_2M cycles:1)
rand rand.c:28 (cycles:1)
rand rand.c:28 (RET CROSS_2M cycles:1)
__random random.c:298 (cycles:1)
__random random.c:297 (COND_BWD CROSS_2M cycles:1)
__random random.c:295 (cycles:1)
__random random.c:295 (COND_BWD CROSS_2M cycles:1)
__random random.c:295 (cycles:1)
__random random.c:295 (RET CROSS_2M cycles:9)
Change log
--
v7: Not changed.
v6: Remove the branch_type_str() since it's moved to branch.c.
v5: Rewrite the branch info print code in util/callchain.c.
v4: Comparing to previous version, the major changes are:
Signed-off-by: Jin Yao
---
tools/perf/util/callchain.c | 38 +-
tools/perf/util/callchain.h | 5 -
tools/perf/util/machine.c | 26 +-
3 files changed, 50 insertions(+), 19 deletions(-)
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index abc6908..4fff550 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -23,6 +23,7 @@
#include "sort.h"
#include "machine.h"
#include "callchain.h"
+#include "branch.h"
#define CALLCHAIN_PARAM_DEFAULT\
.mode = CHAIN_GRAPH_ABS, \
@@ -571,6 +572,11 @@ fill_node(struct callchain_node *node, struct
callchain_cursor *cursor)
call->cycles_count = cursor_node->branch_flags.cycles;
call->iter_count = cursor_node->nr_loop_iter;
call->samples_count = cursor_node->samples;
+
+ branch_type_count(&call->brtype_stat,
+ &cursor_node->branch_flags,
+ cursor_node->branch_from,
+ cursor_node->ip);
}
list_add_tail(&call->list, &node->val);
@@ -688,6 +694,11 @@ static enum match_result match_chain(struct
callchain_cursor_node *node,
cnode->cycles_count += node->branch_flags.cycles;
cnode->iter_count += node->nr_loop_iter;
cnode->samples_count += node->samples;
+
+ branch_type_count(&cnode->brtype_stat,
+ &node->branch_flags,
+ node->branch_from,
+ node->ip);
}
return MATCH_EQ;
@@ -922,7 +933,7 @@ merge_chain_branch(struct callchain_cursor *cursor,
list_for_each_entry_safe(list, next_list, &src->val, list) {
callchain_cursor_append(cursor, list->ip,
list->ms.map, list->ms.sym,
- false, NULL, 0, 0);
+ false, NULL, 0, 0, 0);
list_del(&list->list);
map__zput(list->ms.map);
free(list);
@@ -962,7 +973,7 @@ int callchain_merge(struct callchain_cursor *cursor,
int callchain_cursor_append(struct callchain_cursor *cursor,
u64 ip, struct map *map, struct symbol *sym,
bool branch, struct branch_flags *flags,
- int nr_loop_iter, int samples)
+ int nr_loop_iter, int samples, u64 branch_from)
{
struct callchain_cursor_node *node = *cursor->last;
@@ -986,6 +997,7 @@ int callchain_cursor_append(struct callchain_cursor *cursor,
memcpy(&node->branch_flags, flags,
sizeof(struct branch_flags));
+ node->branch_from = branch_from;
cursor->nr++;
cursor->last = &node->next;
@@ -1241,14 +1253,19 @@ static int count_float_printf(int index, const char
*str, float value,
static int counts_str_build(char *bf, int bfsize,
u64 branch_count, u64 predicted_count,
u64 abort_count, u64 cycles_count,
-u64 iter_count, u64 samples_count)
+u64 iter_count, u64 samples_count,
+struct branch_type_stat *brtype_stat)
{
u64 cycles;
- int printed = 0, i = 0;
+ int printed, i = 0;
if (branch_count == 0)
return scnprintf(bf, bfsize, " (calltrace)");
+ printed = branch_type_str(brtype_stat, bf, bfsize);
+ if (printed)
+ i++;
+
if (predicted_count < br
[PATCH v7 3/7] perf record: Create a new option save_type in --branch-filter
The option indicates the kernel to save branch type during sampling.
One example:
perf record -g --branch-filter any,save_type
Change log
--
v7: Not changed.
v6: Not changed.
v5: Not changed.
Signed-off-by: Jin Yao
---
tools/perf/Documentation/perf-record.txt | 1 +
tools/perf/util/parse-branch-options.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index b0e9e92..9bdea04 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -332,6 +332,7 @@ following filters are defined:
- no_tx: only when the target is not in a hardware transaction
- abort_tx: only when the target is a hardware transaction abort
- cond: conditional branches
+ - save_type: save branch type during sampling in case binary is not
available later
+
The option requires at least one branch type among any, any_call, any_ret,
ind_call, cond.
diff --git a/tools/perf/util/parse-branch-options.c
b/tools/perf/util/parse-branch-options.c
index 38fd115..e71fb5f 100644
--- a/tools/perf/util/parse-branch-options.c
+++ b/tools/perf/util/parse-branch-options.c
@@ -28,6 +28,7 @@ static const struct branch_mode branch_modes[] = {
BRANCH_OPT("cond", PERF_SAMPLE_BRANCH_COND),
BRANCH_OPT("ind_jmp", PERF_SAMPLE_BRANCH_IND_JUMP),
BRANCH_OPT("call", PERF_SAMPLE_BRANCH_CALL),
+ BRANCH_OPT("save_type", PERF_SAMPLE_BRANCH_TYPE_SAVE),
BRANCH_END
};
--
2.7.4
[PATCH v7 2/7] perf/x86/intel: Record branch type
Perf already has support for disassembling the branch instruction
and using the branch type for filtering. The patch just records
the branch type in perf_branch_entry.
Before recording, the patch converts the x86 branch type to
common branch type.
Change log
--
v7: Just convert following x86 branch types to common branch types.
X86_BR_CALL -> PERF_BR_CALL
X86_BR_RET -> PERF_BR_RET
X86_BR_JCC -> PERF_BR_COND
X86_BR_JMP -> PERF_BR_UNCOND
X86_BR_IND_CALL -> PERF_BR_IND_CALL
X86_BR_ZERO_CALL -> PERF_BR_CALL
X86_BR_IND_JMP -> PERF_BR_IND
X86_BR_SYSCALL -> PERF_BR_SYSCALL
X86_BR_SYSRET-> PERF_BR_SYSRET
Others are set to PERF_BR_NONE
v6: Not changed.
v5: Just fix the merge error. No other update.
v4: Comparing to previous version, the major changes are:
1. Uses a lookup table to convert x86 branch type to common branch
type.
2. Move the JCC forward/JCC backward and cross page computing to
user space.
3. Initialize branch type to 0 in intel_pmu_lbr_read_32 and
intel_pmu_lbr_read_64
Signed-off-by: Jin Yao
---
arch/x86/events/intel/lbr.c | 53 -
1 file changed, 52 insertions(+), 1 deletion(-)
diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
index eb26165..5c239b1 100644
--- a/arch/x86/events/intel/lbr.c
+++ b/arch/x86/events/intel/lbr.c
@@ -109,6 +109,9 @@ enum {
X86_BR_ZERO_CALL= 1 << 15,/* zero length call */
X86_BR_CALL_STACK = 1 << 16,/* call stack */
X86_BR_IND_JMP = 1 << 17,/* indirect jump */
+
+ X86_BR_TYPE_SAVE= 1 << 18,/* indicate to save branch type */
+
};
#define X86_BR_PLM (X86_BR_USER | X86_BR_KERNEL)
@@ -510,6 +513,7 @@ static void intel_pmu_lbr_read_32(struct cpu_hw_events
*cpuc)
cpuc->lbr_entries[i].in_tx = 0;
cpuc->lbr_entries[i].abort = 0;
cpuc->lbr_entries[i].cycles = 0;
+ cpuc->lbr_entries[i].type = 0;
cpuc->lbr_entries[i].reserved = 0;
}
cpuc->lbr_stack.nr = i;
@@ -596,6 +600,7 @@ static void intel_pmu_lbr_read_64(struct cpu_hw_events
*cpuc)
cpuc->lbr_entries[out].in_tx = in_tx;
cpuc->lbr_entries[out].abort = abort;
cpuc->lbr_entries[out].cycles= cycles;
+ cpuc->lbr_entries[out].type = 0;
cpuc->lbr_entries[out].reserved = 0;
out++;
}
@@ -673,6 +678,10 @@ static int intel_pmu_setup_sw_lbr_filter(struct perf_event
*event)
if (br_type & PERF_SAMPLE_BRANCH_CALL)
mask |= X86_BR_CALL | X86_BR_ZERO_CALL;
+
+ if (br_type & PERF_SAMPLE_BRANCH_TYPE_SAVE)
+ mask |= X86_BR_TYPE_SAVE;
+
/*
* stash actual user request into reg, it may
* be used by fixup code for some CPU
@@ -926,6 +935,44 @@ static int branch_type(unsigned long from, unsigned long
to, int abort)
return ret;
}
+#define X86_BR_TYPE_MAP_MAX16
+
+static int
+common_branch_type(int type)
+{
+ int i, mask;
+ const int branch_map[X86_BR_TYPE_MAP_MAX] = {
+ PERF_BR_CALL, /* X86_BR_CALL */
+ PERF_BR_RET,/* X86_BR_RET */
+ PERF_BR_SYSCALL,/* X86_BR_SYSCALL */
+ PERF_BR_SYSRET, /* X86_BR_SYSRET */
+ PERF_BR_NONE, /* X86_BR_INT */
+ PERF_BR_NONE, /* X86_BR_IRET */
+ PERF_BR_COND, /* X86_BR_JCC */
+ PERF_BR_UNCOND, /* X86_BR_JMP */
+ PERF_BR_NONE, /* X86_BR_IRQ */
+ PERF_BR_IND_CALL, /* X86_BR_IND_CALL */
+ PERF_BR_NONE, /* X86_BR_ABORT */
+ PERF_BR_NONE, /* X86_BR_IN_TX */
+ PERF_BR_NONE, /* X86_BR_NO_TX */
+ PERF_BR_CALL, /* X86_BR_ZERO_CALL */
+ PERF_BR_NONE, /* X86_BR_CALL_STACK */
+ PERF_BR_IND,/* X86_BR_IND_JMP */
+ };
+
+ type >>= 2; /* skip X86_BR_USER and X86_BR_KERNEL */
+ mask = ~(~0 << 1);
+
+ for (i = 0; i < X86_BR_TYPE_MAP_MAX; i++) {
+ if (type & mask)
+ return branch_map[i];
+
+ type >>= 1;
+ }
+
+ return PERF_BR_NONE;
+}
+
/*
* implement actual branch filter based on user demand.
* Hardware may not exactly satisfy that request, thus
@@ -942,7 +989,8 @@ intel_pmu_lbr_filter(struct cpu_hw_events *cpuc)
bool compress = false;
/* if sampling all branches, then nothing to filter */
- if ((br_sel & X86_BR_ALL) == X86_BR_ALL)
+ if (((br_sel & X86_BR_ALL) == X86_BR_ALL) &&
+ ((br_sel & X86_BR_TYPE_SAVE) != X86_BR_TYPE_SAVE))
return;
for (i = 0; i < cpuc->lbr_stack.nr; i++) {
@@ -963,6 +1011,9 @@ i
[PATCH v7 6/7] perf report: Show branch type statistics for stdio mode
Show the branch type statistics at the end of perf report --stdio.
For example:
perf report --stdio
COND_FWD: 28.5%
COND_BWD: 9.4%
CROSS_4K: 0.7%
CROSS_2M: 14.1%
COND: 37.9%
UNCOND: 0.2%
IND: 6.7%
CALL: 26.5%
RET: 28.7%
SYSRET: 0.0%
The branch types are:
-
COND_FWD: conditional forward
COND_BWD: conditional backward
COND: conditional branch
UNCOND: unconditional branch
IND: indirect
CALL: function call
IND_CALL: indirect function call
RET: function return
SYSCALL: syscall
SYSRET: syscall return
COND_CALL: conditional function call
COND_RET: conditional function return
CROSS_4K and CROSS_2M:
--
They are the metrics checking for branches cross 4K or 2MB pages.
It's an approximate computing. We don't know if the area is 4K or
2MB, so always compute both.
To make the output simple, if a branch crosses 2M area, CROSS_4K
will not be incremented.
Change log
--
v7: Since the common branch type definitions are changed, some
tags/strings are updated accordingly.
v6: Remove branch_type_stat_display() since it's moved to branch.c.
v5: Remove the unnecessary sort__mode checking in
hist_iter__branch_callback().
v4: Comparing to previous version, the major changes are:
Add the computing of JCC forward/JCC backward and cross page checking
by using the from and to addresses.
Signed-off-by: Jin Yao
---
tools/perf/builtin-report.c | 25 +
tools/perf/util/hist.c | 5 +
2 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 79a33eb..9b7f107 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -38,6 +38,7 @@
#include "util/time-utils.h"
#include "util/auxtrace.h"
#include "util/units.h"
+#include "util/branch.h"
#include
#include
@@ -73,6 +74,7 @@ struct report {
u64 queue_size;
int socket_filter;
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
+ struct branch_type_stat brtype_stat;
};
static int report__config(const char *var, const char *value, void *cb)
@@ -150,6 +152,22 @@ static int hist_iter__report_callback(struct
hist_entry_iter *iter,
return err;
}
+static int hist_iter__branch_callback(struct hist_entry_iter *iter,
+ struct addr_location *al __maybe_unused,
+ bool single __maybe_unused,
+ void *arg)
+{
+ struct hist_entry *he = iter->he;
+ struct report *rep = arg;
+ struct branch_info *bi;
+
+ bi = he->branch_info;
+ branch_type_count(&rep->brtype_stat, &bi->flags,
+ bi->from.addr, bi->to.addr);
+
+ return 0;
+}
+
static int process_sample_event(struct perf_tool *tool,
union perf_event *event,
struct perf_sample *sample,
@@ -188,6 +206,8 @@ static int process_sample_event(struct perf_tool *tool,
*/
if (!sample->branch_stack)
goto out_put;
+
+ iter.add_entry_cb = hist_iter__branch_callback;
iter.ops = &hist_iter_branch;
} else if (rep->mem_mode) {
iter.ops = &hist_iter_mem;
@@ -410,6 +430,9 @@ static int perf_evlist__tty_browse_hists(struct perf_evlist
*evlist,
perf_read_values_destroy(&rep->show_threads_values);
}
+ if (sort__mode == SORT_MODE__BRANCH)
+ branch_type_stat_display(stdout, &rep->brtype_stat);
+
return 0;
}
@@ -943,6 +966,8 @@ int cmd_report(int argc, const char **argv)
if (has_br_stack && branch_call_mode)
symbol_conf.show_branchflag_count = true;
+ memset(&report.brtype_stat, 0, sizeof(struct branch_type_stat));
+
/*
* Branch mode is a tristate:
* -1 means default, so decide based on the file having branch data.
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index cf0186a..2f6c5e6 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -749,12 +749,9 @@ iter_prepare_branch_entry(struct hist_entry_iter *iter,
struct addr_location *al
}
static int
-iter_add_single_branch_entry(struct hist_entry_iter *iter,
+iter_add_single_branch_entry(struct hist_entry_iter *iter __maybe_unused,
struct addr_location *al __maybe_unused)
{
- /* to avoid calling callback function */
- iter->he = NULL;
-
return 0;
}
--
2.7.4
[PATCH v7 5/7] perf util: Create branch.c/.h for common branch functions
Create new util/branch.c and util/branch.h to contain the common
branch functions. Such as:
branch_type_count(): Count the numbers of branch types
branch_type_name() : Return the name of branch type
branch_type_stat_display(): Display branch type statistics info
branch_type_str(): Construct the branch type string.
The branch type is saved in branch_flags.
Change log
--
v7: Since the common branch type name is changed (e.g. JCC->COND),
this patch is performed the modification accordingly.
v6: Move that multiline conditional code inside {} brackets.
Move branch_type_stat_display() from builtin-report.c to
branch.c.
Move branch_type_str() from callchain.c to branch.c.
v5: It's a new patch in v5 patch series.
Signed-off-by: Jin Yao
---
tools/perf/util/Build| 1 +
tools/perf/util/branch.c | 166 +++
tools/perf/util/branch.h | 25 +++
tools/perf/util/event.h | 3 +-
4 files changed, 194 insertions(+), 1 deletion(-)
create mode 100644 tools/perf/util/branch.c
create mode 100644 tools/perf/util/branch.h
diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 79dea95..9857c38 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -93,6 +93,7 @@ libperf-y += drv_configs.o
libperf-y += units.o
libperf-y += time-utils.o
libperf-y += expr-bison.o
+libperf-y += branch.o
libperf-$(CONFIG_LIBBPF) += bpf-loader.o
libperf-$(CONFIG_BPF_PROLOGUE) += bpf-prologue.o
diff --git a/tools/perf/util/branch.c b/tools/perf/util/branch.c
new file mode 100644
index 000..0df4499
--- /dev/null
+++ b/tools/perf/util/branch.c
@@ -0,0 +1,166 @@
+#include "perf.h"
+#include "util/util.h"
+#include "util/debug.h"
+#include "util/branch.h"
+
+static bool cross_area(u64 addr1, u64 addr2, int size)
+{
+ u64 align1, align2;
+
+ align1 = addr1 & ~(size - 1);
+ align2 = addr2 & ~(size - 1);
+
+ return (align1 != align2) ? true : false;
+}
+
+#define AREA_4K4096
+#define AREA_2M(2 * 1024 * 1024)
+
+void branch_type_count(struct branch_type_stat *stat,
+ struct branch_flags *flags,
+ u64 from, u64 to)
+{
+ if (flags->type == PERF_BR_NONE || from == 0)
+ return;
+
+ stat->counts[flags->type]++;
+
+ if (flags->type == PERF_BR_COND) {
+ if (to > from)
+ stat->cond_fwd++;
+ else
+ stat->cond_bwd++;
+ }
+
+ if (cross_area(from, to, AREA_2M))
+ stat->cross_2m++;
+ else if (cross_area(from, to, AREA_4K))
+ stat->cross_4k++;
+}
+
+const char *branch_type_name(int type)
+{
+ const char *branch_names[PERF_BR_MAX] = {
+ "N/A",
+ "COND",
+ "UNCOND",
+ "IND",
+ "CALL",
+ "IND_CALL",
+ "RET",
+ "SYSCALL",
+ "SYSRET",
+ "COND_CALL",
+ "COND_RET"
+ };
+
+ if (type >= 0 && type < PERF_BR_MAX)
+ return branch_names[type];
+
+ return NULL;
+}
+
+void branch_type_stat_display(FILE *fp, struct branch_type_stat *stat)
+{
+ u64 total = 0;
+ int i;
+
+ for (i = 0; i < PERF_BR_MAX; i++)
+ total += stat->counts[i];
+
+ if (total == 0)
+ return;
+
+ fprintf(fp, "\n#");
+ fprintf(fp, "\n# Branch Statistics:");
+ fprintf(fp, "\n#");
+
+ if (stat->cond_fwd > 0) {
+ fprintf(fp, "\n%8s: %5.1f%%",
+ "COND_FWD",
+ 100.0 * (double)stat->cond_fwd / (double)total);
+ }
+
+ if (stat->cond_bwd > 0) {
+ fprintf(fp, "\n%8s: %5.1f%%",
+ "COND_BWD",
+ 100.0 * (double)stat->cond_bwd / (double)total);
+ }
+
+ if (stat->cross_4k > 0) {
+ fprintf(fp, "\n%8s: %5.1f%%",
+ "CROSS_4K",
+ 100.0 * (double)stat->cross_4k / (double)total);
+ }
+
+ if (stat->cross_2m > 0) {
+ fprintf(fp, "\n%8s: %5.1f%%",
+ "CROSS_2M",
+ 100.0 * (double)stat->cross_2m / (double)total);
+ }
+
+ for (i = 0; i < PERF_BR_MAX; i++) {
+ if (stat->counts[i] > 0)
+ fprintf(fp, "\n%8s: %5.1f%%",
+ branch_type_name(i),
+ 100.0 *
+ (double)stat->counts[i] / (double)total);
+ }
+}
+
+static int count_str_printf(int index, const char *str,
+ char *bf, int bfsize)
+{
+ int printed;
+
+ printed = scnprintf(bf, bfsize,
+ "%s%s",
+ (index) ? " " : " (", str);
+
+ return printed;
+}
+
+int branch_type_str(struct branch_type_stat *stat,
+
[PATCH v7 1/7] perf/core: Define the common branch type classification
It is often useful to know the branch types while analyzing branch
data. For example, a call is very different from a conditional branch.
Currently we have to look it up in binary while the binary may later
not be available and even the binary is available but user has to take
some time. It is very useful for user to check it directly in perf
report.
Perf already has support for disassembling the branch instruction
to get the x86 branch type.
To keep consistent on kernel and userspace and make the classification
more common, the patch adds the common branch type classification
in perf_event.h.
The patch only defines a minimum but most common set of branch types.
PERF_BR_NONE: unknown
PERF_BR_COND：conditional
PERF_BR_UNCOND : unconditional
PERF_BR_IND : indirect
PERF_BR_CALL: function call
PERF_BR_IND_CALL: indirect function call
PERF_BR_RET : function return
PERF_BR_SYSCALL : syscall
PERF_BR_SYSRET : syscall return
PERF_BR_COND_CALL : conditional function call
PERF_BR_COND_RET: conditional function return
The patch also adds a new field type (4 bits) in perf_branch_entry
to record the branch type (reserve 5 for future branch types)
Since the disassembling of branch instruction needs some overhead,
a new PERF_SAMPLE_BRANCH_TYPE_SAVE is introduced to indicate if it
needs to disassemble the branch instruction and record the branch
type.
Change log
--
v7: Just keep the most common branch types.
Others are removed.
v6: Not changed.
v5: Not changed. The v5 patch series just change the userspace.
v4: Comparing to previous version, the major changes are:
1. Remove the PERF_BR_JCC_FWD/PERF_BR_JCC_BWD, they will be
computed later in userspace.
2. Remove the "cross" field in perf_branch_entry. The cross page
computing will be done later in userspace.
Signed-off-by: Jin Yao
---
include/uapi/linux/perf_event.h | 27 ++-
tools/include/uapi/linux/perf_event.h | 27 ++-
2 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index b1c0b18..fcfb98c 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -174,6 +174,8 @@ enum perf_branch_sample_type_shift {
PERF_SAMPLE_BRANCH_NO_FLAGS_SHIFT = 14, /* no flags */
PERF_SAMPLE_BRANCH_NO_CYCLES_SHIFT = 15, /* no cycles */
+ PERF_SAMPLE_BRANCH_TYPE_SAVE_SHIFT = 16, /* save branch type */
+
PERF_SAMPLE_BRANCH_MAX_SHIFT/* non-ABI */
};
@@ -198,9 +200,30 @@ enum perf_branch_sample_type {
PERF_SAMPLE_BRANCH_NO_FLAGS = 1U <<
PERF_SAMPLE_BRANCH_NO_FLAGS_SHIFT,
PERF_SAMPLE_BRANCH_NO_CYCLES= 1U <<
PERF_SAMPLE_BRANCH_NO_CYCLES_SHIFT,
+ PERF_SAMPLE_BRANCH_TYPE_SAVE=
+ 1U << PERF_SAMPLE_BRANCH_TYPE_SAVE_SHIFT,
+
PERF_SAMPLE_BRANCH_MAX = 1U << PERF_SAMPLE_BRANCH_MAX_SHIFT,
};
+/*
+ * Common flow change classification
+ */
+enum {
+ PERF_BR_NONE= 0,/* unknown */
+ PERF_BR_COND= 1,/* conditional */
+ PERF_BR_UNCOND = 2,/* unconditional */
+ PERF_BR_IND = 3,/* indirect */
+ PERF_BR_CALL= 4,/* function call */
+ PERF_BR_IND_CALL= 5,/* indirect function call */
+ PERF_BR_RET = 6,/* function return */
+ PERF_BR_SYSCALL = 7,/* syscall */
+ PERF_BR_SYSRET = 8,/* syscall return */
+ PERF_BR_COND_CALL = 9,/* conditional function call */
+ PERF_BR_COND_RET= 10, /* conditional function return */
+ PERF_BR_MAX,
+};
+
#define PERF_SAMPLE_BRANCH_PLM_ALL \
(PERF_SAMPLE_BRANCH_USER|\
PERF_SAMPLE_BRANCH_KERNEL|\
@@ -1015,6 +1038,7 @@ union perf_mem_data_src {
* in_tx: running in a hardware transaction
* abort: aborting a hardware transaction
*cycles: cycles from last branch (or 0 if not supported)
+ * type: branch type
*/
struct perf_branch_entry {
__u64 from;
@@ -1024,7 +1048,8 @@ struct perf_branch_entry {
in_tx:1,/* in transaction */
abort:1,/* transaction abort */
cycles:16, /* cycle count to last branch */
- reserved:44;
+ type:4, /* branch type */
+ reserved:40;
};
#endif /* _UAPI_LINUX_PERF_EVENT_H */
diff --git a/tools/include/uapi/linux/perf_event.h
b/tools/include/uapi/linux/perf_event.h
index b1c0b18..fcfb98c 100644
--- a/tools/include/uapi/linux/perf_event.h
+++ b/tools/include/uapi/linux/perf_event.h
@@ -174,6 +174,8 @@ enum perf_branch_sample_type_shift {
PERF_SAMPLE_BRANCH_NO_FLAGS_SHIFT = 14, /* no flags */
PERF_SAMPLE_BRANCH_NO_CYCLES_SHIFT = 15, /* no cycles */
[PATCH v7 4/7] perf report: Refactor the branch info printing code
The branch info such as predicted/cycles/... are printed at the
callchain entries.
For example: perf report --branch-history --no-children --stdio
--1.07%--main div.c:39 (predicted:52.4% cycles:1 iterations:17)
main div.c:44 (predicted:52.4% cycles:1)
main div.c:42 (cycles:2)
compute_flag div.c:28 (cycles:2)
compute_flag div.c:27 (cycles:1)
rand rand.c:28 (cycles:1)
rand rand.c:28 (cycles:1)
__random random.c:298 (cycles:1)
__random random.c:297 (cycles:1)
__random random.c:295 (cycles:1)
__random random.c:295 (cycles:1)
__random random.c:295 (cycles:1)
But the current code is difficult to maintain and extend. This patch
refactors the code for easy maintenance.
Change log
--
v7: Not changed
v6: 1. Put the multiline condition code into {} brackets in
counts_str_build()
2. Keep the original display order, that is:
predicted, abort, cycles, iterations
v5: It's a new patch in v5 patch series.
Signed-off-by: Jin Yao
---
tools/perf/util/callchain.c | 106
1 file changed, 47 insertions(+), 59 deletions(-)
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index b4204b4..abc6908 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -1214,83 +1214,71 @@ int callchain_branch_counts(struct callchain_root *root,
cycles_count);
}
+static int count_pri64_printf(int index, const char *str, u64 value,
+ char *bf, int bfsize)
+{
+ int printed;
+
+ printed = scnprintf(bf, bfsize,
+ "%s%s:%" PRId64 "",
+ (index) ? " " : " (", str, value);
+
+ return printed;
+}
+
+static int count_float_printf(int index, const char *str, float value,
+ char *bf, int bfsize)
+{
+ int printed;
+
+ printed = scnprintf(bf, bfsize,
+ "%s%s:%.1f%%",
+ (index) ? " " : " (", str, value);
+
+ return printed;
+}
+
static int counts_str_build(char *bf, int bfsize,
u64 branch_count, u64 predicted_count,
u64 abort_count, u64 cycles_count,
u64 iter_count, u64 samples_count)
{
- double predicted_percent = 0.0;
- const char *null_str = "";
- char iter_str[32];
- char cycle_str[32];
- char *istr, *cstr;
u64 cycles;
+ int printed = 0, i = 0;
if (branch_count == 0)
return scnprintf(bf, bfsize, " (calltrace)");
- cycles = cycles_count / branch_count;
-
- if (iter_count && samples_count) {
- if (cycles > 0)
- scnprintf(iter_str, sizeof(iter_str),
-" iterations:%" PRId64 "",
-iter_count / samples_count);
- else
- scnprintf(iter_str, sizeof(iter_str),
-"iterations:%" PRId64 "",
-iter_count / samples_count);
- istr = iter_str;
- } else
- istr = (char *)null_str;
-
- if (cycles > 0) {
- scnprintf(cycle_str, sizeof(cycle_str),
- "cycles:%" PRId64 "", cycles);
- cstr = cycle_str;
- } else
- cstr = (char *)null_str;
-
- predicted_percent = predicted_count * 100.0 / branch_count;
+ if (predicted_count < branch_count) {
+ printed += count_float_printf(i++, "predicted",
+ predicted_count * 100.0 / branch_count,
+ bf + printed, bfsize - printed);
+ }
- if ((predicted_count == branch_count) && (abort_count == 0)) {
- if ((cycles > 0) || (istr != (char *)null_str))
- return scnprintf(bf, bfsize, " (%s%s)", cstr, istr);
- else
- return scnprintf(bf, bfsize, "%s", (char *)null_str);
+ if (abort_count) {
+ printed += count_float_printf(i++, "abort",
+ abort_count * 100.0 / branch_count,
+ bf + printed, bfsize - printed);
}
- if ((predicted_count < branch_count) && (abort_count == 0)) {
- if ((cycles > 0) || (istr != (char *)null_str))
- return scnprintf(bf, bfsize,
- " (predicted:%.1f%% %s%s)",
- predicted_percent, cstr, istr);
- else {
- return scnprintf(bf, bfsize,
- " (predicted:%.1f%%)",
- predicted_percent);
- }
+ cycles = cycles_count / branch_count;
+ if (cycles) {
+ print
[PATCH] KVM: VMX: Fix invalid guest state detection after task-switch emulation
From: Wanpeng Li This can be reproduced by EPT=1, unrestricted_guest=N, emulate_invalid_state=Y or EPT=0, the trace of kvm-unit-tests/taskswitch2.flat is like below, it tries to emulate invalid guest state task-switch: kvm_exit: reason TASK_SWITCH rip 0x0 info 4058 0 kvm_emulate_insn: 42000:0:0f 0b (0x2) kvm_emulate_insn: 42000:0:0f 0b (0x2) failed kvm_inj_exception: #UD (0x0) kvm_entry: vcpu 0 kvm_exit: reason TASK_SWITCH rip 0x0 info 4058 0 kvm_emulate_insn: 42000:0:0f 0b (0x2) kvm_emulate_insn: 42000:0:0f 0b (0x2) failed kvm_inj_exception: #UD (0x0) .. It appears that the task-switch emulation updates rflags (and vm86 flag) only after the segments are loaded, causing vmx->emulation_required to be set, when in fact invalid guest state emulation is not needed. This patch fixes it by updating vmx->emulation_required after the rflags (and vm86 flag) is updated in task-switch emulation. Suggested-by: Nadav Amit Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Nadav Amit Signed-off-by: Wanpeng Li --- arch/x86/kvm/vmx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index f50cbfd..70270a2 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -6255,6 +6255,7 @@ static int handle_task_switch(struct kvm_vcpu *vcpu) * TODO: What about debug traps on tss switch? * Are we supposed to inject them and update dr6? */ + vmx->emulation_required = emulation_required(vcpu); return 1; } -- 2.7.4
Re: [PATCH RFC v4] cpufreq: schedutil: Make iowait boost more energy efficient
On 10/07/17 22:12, Joel Fernandes wrote:
> Hi Juri,
>
> On Mon, Jul 10, 2017 at 3:55 AM, Juri Lelli wrote:
> > Hi Joel,
> >
> > On 09/07/17 10:08, Joel Fernandes wrote:
[...]
> >> static void sugov_iowait_boost(struct sugov_cpu *sg_cpu, unsigned long
> >> *util,
> >> -unsigned long *max)
> >> +unsigned long *max, unsigned int flags)
> >> {
> >> unsigned long boost_util = sg_cpu->iowait_boost;
> >> unsigned long boost_max = sg_cpu->iowait_boost_max;
> >> @@ -195,7 +222,16 @@ static void sugov_iowait_boost(struct sugov_cpu
> >> *sg_cpu, unsigned long *util,
> >> *util = boost_util;
> >> *max = boost_max;
> >> }
> >> - sg_cpu->iowait_boost >>= 1;
> >> +
> >> + /*
> >> + * Incase iowait boost just happened on this CPU, don't reduce it
> >> right
> >> + * away since then the iowait boost will never increase on subsequent
> >> + * in_iowait wakeups.
> >> + */
> >> + if (flags & SCHED_CPUFREQ_IOWAIT && this_cpu_ptr(&sugov_cpu) ==
> >> sg_cpu)
> >> + return;
> >> +
> >> + sugov_decay_iowait_boost(sg_cpu);
> >
> > Mmm, do we need to decay even when we are computing frequency requests
> > for a domain?
> >
> > Considering it a per-cpu thing, isn't enough that it gets bumped up or
> > decayed only when a CPU does an update (by using the above from
> > sugov_update_shared)?
> >
> > If we go this way I think we will only need to reset prev_iowait_boost
> > if delta_ns > TICK_NSEC during the for_each_cpu() loop of sugov_next_
> > freq_shared().
> >
>
> Actually the "decay" was already being done before (without this
> patch), I am just preserving the same old behavior where we do decay.
> Perhaps your proposal can be a separate match? Or did I miss something
> else subtle here?
>
True, we are currently decaying anyway.
Looking again at this path made me however think if we really need to. I
guess we need currently, as we bump frenquency to max and then decay it.
But, with your changes, I was wondering if we can simplify the thing and
decay only on the per-CPU update path.
The other reason for trying to simplify this is that I don't
particularly like adding and consuming flags argument at this point, but
I guess we could refactor the code if this is really a problem.
Thanks,
- Juri
Re: [RFC] mm/mremap: Remove redundant checks inside vma_expandable()
On Tue 11-07-17 08:56:04, Vlastimil Babka wrote:
> On 07/11/2017 08:50 AM, Michal Hocko wrote:
> > On Tue 11-07-17 08:26:40, Vlastimil Babka wrote:
> >> On 07/11/2017 08:03 AM, Michal Hocko wrote:
> >>>
> >>> Are you telling me that two if conditions cause more than a second
> >>> difference? That sounds suspicious.
> >>
> >> It's removing also a call to get_unmapped_area(), AFAICS. That means a
> >> vma search?
> >
> > Ohh, right. I have somehow missed that. Is this removal intentional?
>
> I think it is: "Checking for availability of virtual address range at
> the end of the VMA for the incremental size is also reduntant at this
> point."
I though this referred to this check
if (vma->vm_next && vma->vm_next->vm_start < end)
becuase get_unampped_area with MAP_FIXED doesn't really check
anything. It will simply return the given address. Btw. this also rules
out find_vma.
> > The
> > changelog is silent about it.
>
> It doesn't explain why it's redundant, indeed. Unfortunately, the commit
> f106af4e90ea ("fix checks for expand-in-place mremap") which added this,
> also doesn't explain why it's needed.
Because it doesn't do anything AFAICS.
--
Michal Hocko
SUSE Labs
Re: [RFC PATCH] fs: ext4: don't trap kswapd and allocating tasks on ext4 inode IO
Hi Jan,
We seemed to get this issue on a file system with data=order mode, and
it can steadily be re-produced by creating lots of symlinks and each
links to a 100KB file created by dd in advance. During the process of
dd and making symlinks, copying a large file via samba to the file
system would get stuck with the following call stacks:
kswapd0
===
[] jbd2_log_wait_commit+0x93/0x100
[] jbd2_complete_transaction+0x50/0x80
[] ext4_evict_inode+0x27c/0x400
[] evict+0xae/0x170
[] dispose_list+0x35/0x50
[] prune_icache_sb+0x46/0x60
[] super_cache_scan+0x14c/0x1a0
[] shrink_slab.part.36+0x19a/0x250
[] shrink_zone+0x23c/0x250
[] kswapd+0x54a/0x930
[] kthread+0xd6/0xf0
[] ret_from_fork+0x3f/0x70
[] 0x
kworker/u8:4
[] wait_transaction_locked+0x74/0xa0
[] start_this_handle+0x233/0x5d0
[] jbd2__journal_start+0xf2/0x180
[] __ext4_journal_start_sb+0x57/0x80
[] ext4_writepages+0x2da/0xad0
[] do_writepages+0x2e/0x70
[] __writeback_single_inode+0x33/0x170
[] writeback_sb_inodes+0x20a/0x460
[] __writeback_inodes_wb+0x84/0xb0
[] wb_writeback+0x1a2/0x1b0
[] wb_workfn+0x1b6/0x320
[] process_one_work+0x139/0x370
[] worker_thread+0x61/0x450
[] kthread+0xd6/0xf0
[] ret_from_fork+0x3f/0x70
[] 0x
jbd2/dm-0-8
===
[] jbd2_journal_commit_transaction+0x1f9/0x1540
[] kjournald2+0xd1/0x250
[] kthread+0xd6/0xf0
[] ret_from_fork+0x3f/0x70
[] 0x
We runs linux-4.2 and the issue is fixed with the patch you mentioned
in previous mail (adding "&& inode->i_data.nrpages"). If there's
anything I could help, feel free to let me know. Thanks!
Jerry
On Mon, Jun 12, 2017 at 4:09 PM, Jan Kara wrote:
> On Tue 16-05-17 18:03:37, Jan Kara wrote:
>> On Tue 16-05-17 11:41:05, Johannes Weiner wrote:
>> > On Tue, May 16, 2017 at 04:36:45PM +0200, Jan Kara wrote:
>> > > On Mon 15-05-17 11:46:34, Johannes Weiner wrote:
>> > > > We have observed across several workloads situations where kswapd and
>> > > > direct reclaimers get stuck in the inode shrinker of the ext4 / mount,
>> > > > causing allocation latencies across tasks in the system, while there
>> > > > are dozens of gigabytes of clean page cache covering multiple disks.
>> > > >
>> > > > The stack traces of such an instance looks like this:
>> > > >
>> > > > [] jbd2_log_wait_commit+0x95/0x110
>> > > > [] jbd2_complete_transaction+0x59/0x90
>> > > > [] ext4_evict_inode+0x2da/0x480
>> > > > [] evict+0xc0/0x190
>> > > > [] dispose_list+0x39/0x50
>> > > > [] prune_icache_sb+0x4b/0x60
>> > > > [] super_cache_scan+0x141/0x190
>> > > > [] shrink_slab+0x235/0x440
>> > > > [] shrink_zone+0x268/0x2d0
>> > > > [] do_try_to_free_pages+0x164/0x410
>> > > > [] try_to_free_pages+0xb5/0x160
>> > > > [] __alloc_pages_nodemask+0x636/0xb30
>> > > > [] alloc_pages_current+0x88/0x120
>> > > > [] skb_page_frag_refill+0xc6/0xf0
>> > > > [] sk_page_frag_refill+0x1d/0x80
>> > > > [] tcp_sendmsg+0x28b/0xb10
>> > > > [] inet_sendmsg+0x67/0xa0
>> > > > [] sock_sendmsg+0x38/0x50
>> > > > [] sock_write_iter+0x78/0xd0
>> > > > [] do_iter_readv_writev+0x5e/0xa0
>> > > > [] do_readv_writev+0x178/0x210
>> > > > [] vfs_writev+0x3c/0x50
>> > > > [] do_writev+0x52/0xd0
>> > > > [] SyS_writev+0x10/0x20
>> > > > [] do_syscall_64+0x50/0xa0
>> > > > [] return_from_SYSCALL_64+0x0/0x6a
>> > > > [] 0x
>> > > >
>> > > > The inode shrinker has provisions to skip any inodes that require
>> > > > writeback, to avoid tarpitting the entire system behind a single
>> > > > object when there are many other pools to recycle memory from. But
>> > > > that logic doesn't cover the situation where an ext4 inode is clean
>> > > > but journaled and tied to a commit that yet needs to hit the platter.
>> > > >
>> > > > Add a superblock operation that lets the generic inode shrinker query
>> > > > the filesystem whether evicting a given inode will require any IO; add
>> > > > an ext4 implementation that checks whether the journal is caught up to
>> > > > the commit id associated with the inode.
>> > > >
>> > > > Fixes: 2d859db3e4a8 ("ext4: fix data corruption in inodes with
>> > > > journalled data")
>> > > > Signed-off-by: Johannes Weiner
>> > >
>> > > OK. I have to say I'm somewhat surprised you use data journalling on some
>> > > of your files / filesystems but whatever - maybe these are long symlink
>> > > after all which would make sense.
>> >
>> > The filesystem is actually mounted data=ordered and we didn't catch
>> > anyone in userspace enabling journaling on individual inodes. So we
>> > assumed this must be from symlinks.
>>
>> OK.
>>
>> > > And I'm actually doubly surprised you can see these stack traces as
>> > > these days inode_lru_isolate() checks inode->i_data.nrpages and
>> > > uncommitted pages cannot be evicted from pagecache
>> > > (ext4_releasepage() will refuse to free them) so I don't see how
>> > > such inode can get to dispose_list(). But maybe the inode doesn't
>> > > really have any pages and i_datasync_tid just happens to be set to
>>
Re: [RFC] mm/mremap: Remove redundant checks inside vma_expandable()
On Tue 11-07-17 09:16:12, Michal Hocko wrote:
> On Tue 11-07-17 08:56:04, Vlastimil Babka wrote:
[...]
> > It doesn't explain why it's redundant, indeed. Unfortunately, the commit
> > f106af4e90ea ("fix checks for expand-in-place mremap") which added this,
> > also doesn't explain why it's needed.
>
> Because it doesn't do anything AFAICS.
Well, it does actually. I have missed security_mmap_addr hook.
--
Michal Hocko
SUSE Labs
[PATCH v2 01/10] net: cdc_ncm: constify attribute_group structures.
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work
with const attribute_group. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
13275 928 1 14204377c drivers/net/usb/cdc_ncm.o
File size After adding 'const':
textdata bss dec hex filename
13339 864 1 14204377c drivers/net/usb/cdc_ncm.o
Signed-off-by: Arvind Yadav
---
Changes in v2:
Added cover later.
drivers/net/usb/cdc_ncm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index d103a1d..b401ba9 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -367,7 +367,7 @@ static DEVICE_ATTR(name, S_IRUGO, cdc_ncm_show_##name, NULL)
NULL,
};
-static struct attribute_group cdc_ncm_sysfs_attr_group = {
+static const struct attribute_group cdc_ncm_sysfs_attr_group = {
.name = "cdc_ncm",
.attrs = cdc_ncm_sysfs_attrs,
};
--
1.9.1
[PATCH v2 00/10] Constify attribute_group structures
attribute_groups are not supposed to change at runtime. So mark the non-const structs as const. Arvind Yadav (10): [PATCH v2 01/10] net: cdc_ncm: constify attribute_group structures. [PATCH v2 02/10] net: can: at91_can: constify attribute_group structures. [PATCH v2 03/10] net: can: janz-ican3: constify attribute_group structures. [PATCH v2 04/10] wireless: ipw2200: constify attribute_group structures. [PATCH v2 05/10] wireless: ipw2100: constify attribute_group structures. [PATCH v2 06/10] wireless: iwlegacy: constify attribute_group structures. [PATCH v2 07/10] wireless: iwlegacy: Constify attribute_group structures. [PATCH v2 08/10] arcnet: com20020-pci: constify attribute_group structures. [PATCH v2 09/10] net: bonding: constify attribute_group structures. [PATCH v2 10/10] net: chelsio: cxgb3: constify attribute_group structures. drivers/net/arcnet/com20020-pci.c | 2 +- drivers/net/bonding/bond_sysfs.c| 2 +- drivers/net/can/at91_can.c | 2 +- drivers/net/can/janz-ican3.c| 2 +- drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 8 ++-- drivers/net/usb/cdc_ncm.c | 2 +- drivers/net/wireless/intel/ipw2x00/ipw2100.c| 2 +- drivers/net/wireless/intel/ipw2x00/ipw2200.c| 2 +- drivers/net/wireless/intel/iwlegacy/3945-mac.c | 2 +- drivers/net/wireless/intel/iwlegacy/4965-mac.c | 2 +- 10 files changed, 15 insertions(+), 11 deletions(-) -- 1.9.1
Re: [PATCH] iscsi-target: Reject immediate data underflow larger than SCSI transfer length
Hi Bart,
On Thu, 2017-06-08 at 23:55 -0700, Nicholas A. Bellinger wrote:
> On Thu, 2017-06-08 at 15:37 +, Bart Van Assche wrote:
> > On Thu, 2017-06-08 at 04:21 +, Nicholas A. Bellinger wrote:
> > > + /*
> > > + * Check for underflow case where both EDTL and immediate data payload
> > > + * exceeds what is presented by CDB's TRANSFER LENGTH, and what has
> > > + * already been set in target_cmd_size_check() as se_cmd->data_length.
> > > + *
> > > + * For this special case, fail the command and dump the immediate data
> > > + * payload.
> > > + */
> > > + if (cmd->first_burst_len > cmd->se_cmd.data_length) {
> > > + cmd->sense_reason = TCM_INVALID_CDB_FIELD;
> > > + goto after_immediate_data;
> > > + }
> >
> > A quote from the iSCSI RFC (https://tools.ietf.org/html/rfc5048):
> >
> >If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in the
> >SCSI Response PDU as specified in [RFC3720]. The Residual Count MUST
> >be set to the numerical value of (EDTL - SPDTL).
> >
> > Sorry but I don't think that sending TCM_INVALID_CDB_FIELD back to the
> > initiator is compliant with the iSCSI RFC.
>
> Alas, the nuance of what this patch actually does was missed when you
> cut the context.
>
> First, a bit of history. LIO has rejected underflow for all WRITEs for
> the first ~12.5 years of RFC-3720, and in the context of iscsi-target
> mode there has never been a single host environment that ever once
> cared.
>
> Since Roland's patch to allow underflow for control CDBs in v4.3+ opened
> this discussion for control CDBs with a WRITE payload in order to make
> MSFT/FCP cert for PERSISTENT_RESERVE_OUT happy, the question has become
> what control CDB WRITE underflow cases should we allow..?
>
> The point with this patch is when a host is sending a underflow with a
> iscsi immediate data payload that exceeds SCSI transfer length, it's a
> bogus request with a garbage payload. It's a garbage payload because
> the SCSI CDB itself obviously doesn't want anything to do it.
>
> I'm very dubious of any host environment who's trying to do this for any
> CDB, and expects achieve expected results.
>
> Of course, since v4.3+ normal overflow where SCSI transfer length
> matches the iscsi immediate data payload just works with or without this
> patch.
>
> So to that extent, I'm going to push this patch as a defensive fix for
> v4.3+, to let those imaginary iscsi host environments know they being
> very, very naughty.
>
> > Please note that a fix that is
> > compliant with the iSCSI RFC is present in the following patch series:
> > [PATCH
> > 00/33] SCSI target driver patches for kernel v4.13, 23 May 2017
> > (https://www.spinics.net/lists/target-devel/msg15370.html).
>
> So I might still consider this as a v4.13-rc item for control CDB
> underflow, but no way as stable material.
>
> Also, there is certainly no way I'm going to allow a patch to randomly
> enable underflow/overflow for all WRITE non control CDBs tree-wide
> across all fabric drivers, because 1) no host environments actually care
> about this, and 2) it's still dangerous to do for all fabrics without
> some serious auditing.
After further consideration, I've decided against allowing iscsi-target
underflow with a immediate data payload larger than SCSI transfer
length.
Any host environment that attempts to send an underflow with a immediate
data payload larger than SCSI transfer length, expects the target to
automatically truncate immediate data, and still return GOOD status is
completely bogus. Any host that attempts this is buggy, and needs to be
fixed.
This is because for the last ~12 years of RFC-3720:
- There has never been a host environment in the wild that exhibits
this behavior.
- There has never been a conformance suite which expects this
behavior.
So rejecting this case as already done in commit abb85a9b51 is the
correct approach for >= v4.3.y.
Of course, the typical underflow scenario which Roland's v4.3.y commit
enabled, underflow where immediate data matches the SCSI transfer length
is supported for control CDBs.
That said, thanks for high-lighting this particular corner case, so it
could be fixed in >= v4.3.y.
[PATCH v2 02/10] net: can: at91_can: constify attribute_group structures.
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work
with const attribute_group. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
6164 304 064681944 drivers/net/can/at91_can.o
File size After adding 'const':
textdata bss dec hex filename
6228 240 064681944 drivers/net/can/at91_can.o
Signed-off-by: Arvind Yadav
---
Changes in v2:
Added cover later.
drivers/net/can/at91_can.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/at91_can.c b/drivers/net/can/at91_can.c
index 0e0df0b..f37ce0e 100644
--- a/drivers/net/can/at91_can.c
+++ b/drivers/net/can/at91_can.c
@@ -1232,7 +1232,7 @@ static DEVICE_ATTR(mb0_id, S_IWUSR | S_IRUGO,
NULL,
};
-static struct attribute_group at91_sysfs_attr_group = {
+static const struct attribute_group at91_sysfs_attr_group = {
.attrs = at91_sysfs_attrs,
};
--
1.9.1
[PATCH v2 03/10] net: can: janz-ican3: constify attribute_group structures.
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work
with const attribute_group. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
11800 368 0 121682f88 drivers/net/can/janz-ican3.o
File size After adding 'const':
textdata bss dec hex filename
11864 304 0 121682f88 drivers/net/can/janz-ican3.o
Signed-off-by: Arvind Yadav
---
Changes in v2:
Added cover later.
drivers/net/can/janz-ican3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/janz-ican3.c b/drivers/net/can/janz-ican3.c
index 2ba1a81..12a53c8 100644
--- a/drivers/net/can/janz-ican3.c
+++ b/drivers/net/can/janz-ican3.c
@@ -1875,7 +1875,7 @@ static DEVICE_ATTR(termination, S_IWUSR | S_IRUGO,
ican3_sysfs_show_term,
NULL,
};
-static struct attribute_group ican3_sysfs_attr_group = {
+static const struct attribute_group ican3_sysfs_attr_group = {
.attrs = ican3_sysfs_attrs,
};
--
1.9.1
Re: [PATCH] tty: Fix TIOCGPTPEER ioctl definition
On Tue, Jul 11, 2017 at 2:12 AM, Gleb Fotengauer-Malinovskiy
wrote:
> This ioctl does nothing to justify an _IOC_READ or _IOC_WRITE flag
> because it doesn't copy anything from/to userspace to access the
> argument.
>
> Fixes: 54ebbfb1 ("tty: add TIOCGPTPEER ioctl")
> Signed-off-by: Gleb Fotengauer-Malinovskiy
Acked-by: Arnd Bergmann
[PATCH v2 00/10] Constify attribute_group structures
attribute_groups are not supposed to change at runtime. So mark the non-const structs as const. Arvind Yadav (10): [PATCH v2 01/10] net: cdc_ncm: constify attribute_group structures. [PATCH v2 02/10] net: can: at91_can: constify attribute_group structures. [PATCH v2 03/10] net: can: janz-ican3: constify attribute_group structures. [PATCH v2 04/10] wireless: ipw2200: constify attribute_group structures. [PATCH v2 05/10] wireless: ipw2100: constify attribute_group structures. [PATCH v2 06/10] wireless: iwlegacy: constify attribute_group structures. [PATCH v2 07/10] wireless: iwlegacy: Constify attribute_group structures. [PATCH v2 08/10] arcnet: com20020-pci: constify attribute_group structures. [PATCH v2 09/10] net: bonding: constify attribute_group structures. [PATCH v2 10/10] net: chelsio: cxgb3: constify attribute_group structures. drivers/net/arcnet/com20020-pci.c | 2 +- drivers/net/bonding/bond_sysfs.c| 2 +- drivers/net/can/at91_can.c | 2 +- drivers/net/can/janz-ican3.c| 2 +- drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 8 ++-- drivers/net/usb/cdc_ncm.c | 2 +- drivers/net/wireless/intel/ipw2x00/ipw2100.c| 2 +- drivers/net/wireless/intel/ipw2x00/ipw2200.c| 2 +- drivers/net/wireless/intel/iwlegacy/3945-mac.c | 2 +- drivers/net/wireless/intel/iwlegacy/4965-mac.c | 2 +- 10 files changed, 15 insertions(+), 11 deletions(-) -- 1.9.1
[PATCH] fsi: core: register with postcore_initcall
When testing an i2c driver that is a fsi bus driver, I saw the following
oops:
kernel BUG at drivers/base/driver.c:153!
Internal error: Oops - BUG: 0 [#1] ARM
[<8027cb1c>] (driver_register) from [<80344e88>]
(fsi_driver_register+0x2c/0x38)
[<80344e88>] (fsi_driver_register) from [<805f5ebc>]
(fsi_i2c_driver_init+0x1c/0x24)
[<805f5ebc>] (fsi_i2c_driver_init) from [<805d1f14>]
(do_one_initcall+0xb4/0x170)
[<805d1f14>] (do_one_initcall) from [<805d20f0>]
(kernel_init_freeable+0x120/0x1dc)
[<805d20f0>] (kernel_init_freeable) from [<8043f4a8>] (kernel_init+0x18/0x104)
[<8043f4a8>] (kernel_init) from [<8000a5e8>] (ret_from_fork+0x14/0x2c)
This is because the fsi bus had not been registered. This fix registers the bus
with postcore_initcall instead, to ensure it is registered earlier on.
When the fsi core is used as a module this should not be a problem as the fsi
driver will depend on the fsi bus type symbol, and will therefore load the core
before the driver.
Fixes: 0508ad1fff11 ("drivers/fsi: Add empty fsi bus definitions")
Signed-off-by: Joel Stanley
---
drivers/fsi/fsi-core.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
index a88df7a2b466..5966ecb72f37 100644
--- a/drivers/fsi/fsi-core.c
+++ b/drivers/fsi/fsi-core.c
@@ -889,17 +889,16 @@ struct bus_type fsi_bus_type = {
};
EXPORT_SYMBOL_GPL(fsi_bus_type);
-static int fsi_init(void)
+static int __init fsi_init(void)
{
return bus_register(&fsi_bus_type);
}
+postcore_initcall(fsi_init);
static void fsi_exit(void)
{
bus_unregister(&fsi_bus_type);
}
-
-module_init(fsi_init);
module_exit(fsi_exit);
module_param(discard_errors, int, 0664);
MODULE_LICENSE("GPL");
--
2.13.2
Re: [PATCH 1/5] mm/persistent-memory: match IORES_DESC name and enum memory_type one
On Wed, Jul 5, 2017 at 11:49 AM, Jerome Glisse wrote:
> On Wed, Jul 05, 2017 at 09:15:35AM -0700, Dan Williams wrote:
>> On Wed, Jul 5, 2017 at 7:25 AM, Jerome Glisse wrote:
>> > On Mon, Jul 03, 2017 at 04:49:18PM -0700, Dan Williams wrote:
>> >> On Mon, Jul 3, 2017 at 2:14 PM, Jérôme Glisse wrote:
>> >> > Use consistent name between IORES_DESC and enum memory_type, rename
>> >> > MEMORY_DEVICE_PUBLIC to MEMORY_DEVICE_PERSISTENT. This is to free up
>> >> > the public name for CDM (cache coherent device memory) for which the
>> >> > term public is a better match.
>> >> >
>> >> > Signed-off-by: Jérôme Glisse
>> >> > Cc: Dan Williams
>> >> > Cc: Ross Zwisler
>> >> > ---
>> >> > include/linux/memremap.h | 4 ++--
>> >> > kernel/memremap.c| 2 +-
>> >> > 2 files changed, 3 insertions(+), 3 deletions(-)
>> >> >
>> >> > diff --git a/include/linux/memremap.h b/include/linux/memremap.h
>> >> > index 57546a07a558..2299cc2d387d 100644
>> >> > --- a/include/linux/memremap.h
>> >> > +++ b/include/linux/memremap.h
>> >> > @@ -41,7 +41,7 @@ static inline struct vmem_altmap
>> >> > *to_vmem_altmap(unsigned long memmap_start)
>> >> > * Specialize ZONE_DEVICE memory into multiple types each having
>> >> > differents
>> >> > * usage.
>> >> > *
>> >> > - * MEMORY_DEVICE_PUBLIC:
>> >> > + * MEMORY_DEVICE_PERSISTENT:
>> >> > * Persistent device memory (pmem): struct page might be allocated in
>> >> > different
>> >> > * memory and architecture might want to perform special actions. It
>> >> > is similar
>> >> > * to regular memory, in that the CPU can access it transparently.
>> >> > However,
>> >> > @@ -59,7 +59,7 @@ static inline struct vmem_altmap
>> >> > *to_vmem_altmap(unsigned long memmap_start)
>> >> > * include/linux/hmm.h and Documentation/vm/hmm.txt.
>> >> > */
>> >> > enum memory_type {
>> >> > - MEMORY_DEVICE_PUBLIC = 0,
>> >> > + MEMORY_DEVICE_PERSISTENT = 0,
>> >> > MEMORY_DEVICE_PRIVATE,
>> >> > };
>> >> >
>> >> > diff --git a/kernel/memremap.c b/kernel/memremap.c
>> >> > index b9baa6c07918..e82456c39a6a 100644
>> >> > --- a/kernel/memremap.c
>> >> > +++ b/kernel/memremap.c
>> >> > @@ -350,7 +350,7 @@ void *devm_memremap_pages(struct device *dev,
>> >> > struct resource *res,
>> >> > }
>> >> > pgmap->ref = ref;
>> >> > pgmap->res = &page_map->res;
>> >> > - pgmap->type = MEMORY_DEVICE_PUBLIC;
>> >> > + pgmap->type = MEMORY_DEVICE_PERSISTENT;
>> >> > pgmap->page_fault = NULL;
>> >> > pgmap->page_free = NULL;
>> >> > pgmap->data = NULL;
>> >>
>> >> I think we need a different name. There's nothing "persistent" about
>> >> the devm_memremap_pages() path. Why can't they share name, is the only
>> >> difference coherence? I'm thinking something like:
>> >>
>> >> MEMORY_DEVICE_PRIVATE
>> >> MEMORY_DEVICE_COHERENT /* persistent memory and coherent devices */
>> >> MEMORY_DEVICE_IO /* "public", but not coherent */
>> >
>> > No that would not work. Device public (in the context of this patchset)
>> > is like device private ie device public page can be anywhere inside a
>> > process address space either as anonymous memory page or as file back
>> > page of regular filesystem (ie vma->ops is not pointing to anything
>> > specific to the device memory).
>> >
>> > As such device public is different from how persistent memory is use
>> > and those the cache coherency being the same between the two kind of
>> > memory is not a discerning factor. So i need to distinguish between
>> > persistent memory and device public memory.
>> >
>> > I believe keeping enum memory_type close to IORES_DESC naming is the
>> > cleanest way to do that but i am open to other name suggestion.
>> >
>>
>> The IORES_DESC has nothing to do with how the memory range is handled
>> by the core mm. It sounds like the distinction this is trying to make
>> is between MEMORY_DEVICE_{PUBLIC,PRIVATE} and MEMORY_DEVICE_HOST.
>> Where a "host" memory range is one that does not need coordination
>> with a specific device.
>
> I want to distinguish between:
> - device memory that is not accessible by the CPU
> - device memory that is accessible by the CPU just like regular
> memory
> - existing user of devm_memremap_pages() which is persistent memory
> (only pmem seems to call devm_memremap_pages()) that is use like a
> filesystem or block device and thus isn't use like generic page in
> a process address space
>
> So if existing user of devm_memremap_pages() are only persistent memory
> then it made sense to match the IORES_DESC we are expecting to see on
> see such memory.
>
> For public device memory (in the sense introduced by this patchset) i
> do not know how it will be described by IORES_DESC. i think first folks
> with it are IBM with CAPI and i am not sure they defined something for
> that already.
>
> I am open to any name beside public (well any reasonable name :)) but
> i do need to be able to distinguish persisten
[PATCH v2 05/10] wireless: ipw2100: constify attribute_group structures.
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work
with const attribute_group. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
---
Changes in v2:
Added cover later.
drivers/net/wireless/intel/ipw2x00/ipw2100.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2100.c
b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
index aaaca4d..ccbe745 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
@@ -4324,7 +4324,7 @@ static ssize_t store_rf_kill(struct device *d, struct
device_attribute *attr,
NULL,
};
-static struct attribute_group ipw2100_attribute_group = {
+static const struct attribute_group ipw2100_attribute_group = {
.attrs = ipw2100_sysfs_entries,
};
--
1.9.1
[PATCH v2 04/10] wireless: ipw2200: constify attribute_group structures.
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work
with const attribute_group. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
---
Changes in v2:
Added cover later.
drivers/net/wireless/intel/ipw2x00/ipw2200.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
index 9368abd..c311b1a 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
@@ -11500,7 +11500,7 @@ static int ipw_wdev_init(struct net_device *dev)
NULL
};
-static struct attribute_group ipw_attribute_group = {
+static const struct attribute_group ipw_attribute_group = {
.name = NULL, /* put in device directory */
.attrs = ipw_sysfs_entries,
};
--
1.9.1
Re: [PATCH] usb: dwc2: gadget: On disconnect reset device address to zero
Hi, Minas Harutyunyan writes: >>> Minas Harutyunyan writes: USB CV driver stack doesn't perform USB RESET after device disconnect/ connect, so need to reset to zero DEVADDR field in DCFG to pass enumeration again. Signed-off-by: Minas Harutyunyan --- drivers/usb/dwc2/gadget.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c index 98a4a79e7f6e..deb3d901b99d 100644 --- a/drivers/usb/dwc2/gadget.c +++ b/drivers/usb/dwc2/gadget.c @@ -3174,6 +3174,9 @@ void dwc2_hsotg_disconnect(struct dwc2_hsotg *hsotg) return; hsotg->connected = 0; + /* On disconnect reset device address to zero */ + __bic32(hsotg->regs + DCFG, DCFG_DEVADDR_MASK); + >>> >>> Which of the tests are you talking about? Which particular USB CV are >>> you running? >>> >>> I don't remember ever seeing this with dwc3. How should I go about >>> triggering this problem? If this was really the case, then we would have >>> this on *all* UDCs. >>> >>> I just did a fresh install of USB 3 Gen X CV (that I just download from >>> usb.org). Ran Chapter 9 tests against a HS dwc3 board I have around and >>> I can't see the problem you're talking about. >>> >>> Here are all my non-endpoint interrupt events in order. Test passes >>> fine. If disconnect, reconnect and run the tests again, then Reset will >>> be driven on the bus which will cause address to be reset. >>> >>> Can you share more details about the problem you're facing? >> >> I've been looking at dwc2 for a while and I think this is a bug in >> dwc2_hsotg_irq() on the branch for GINTSTS_USBRST. I don't have docs for >> dwc2. >> > > USB RESET not issuing by CV host stack after connect. Below dmesg: > > Disconnect > > [23984.039199] dwc2 dwc2.1.auto: dwc2_hsotg_irq: 04008428 0400 > (d0bc3cc4) retry 8 > [23984.039204] dwc2 dwc2.1.auto: GINTSTS_ErlySusp > [23984.042235] dwc2 dwc2.1.auto: gintsts=04008828 gintmsk=d0bc3cc4 > [23984.042240] dwc2 dwc2.1.auto: USB SUSPEND > [23984.042247] dwc2 dwc2.1.auto: DSTS=0x5f4c01 > [23984.042250] dwc2 dwc2.1.auto: DSTS.Suspend Status=1 HWCFG4.Power > Optimize=0 > [23984.042260] dwc2 dwc2.1.auto: dwc2_hsotg_irq: 04008028 > (d0bc3cc4) retry 8 > [23984.272308] dwc2 dwc2.1.auto: gintsts=0480902c gintmsk=d0bc3cc4 > [23984.272318] dwc2 dwc2.1.auto: ++OTG Interrupt gotgint=4 [b_peripheral] > [23984.272321] dwc2 dwc2.1.auto: ++OTG Interrupt: Session End > Detected++ (b_peripheral) > [23984.272331] dwc2 dwc2.1.auto: complete: ep 880401a31b28 ep0, req > 8803e495ef00, -108 => a00541da > [23984.272336] dwc2 dwc2.1.auto: dwc2_hsotg_complete_setup: failed -108 > [23984.272346] dwc2 dwc2.1.auto: complete: ep 880401a30328 ep1out, > req 88040b6d7c80, -108 => a008865c > [23984.272435] dwc2 dwc2.1.auto: dwc2_hsotg_irq: 04809028 00801000 > (d0bc3cc4) retry 8 > [23984.272437] dwc2 dwc2.1.auto: dwc2_hsotg_irq: USBRstDet > [23984.272442] dwc2 dwc2.1.auto: dwc2_hsotg_irq: USBRst here it is. > [23984.272446] dwc2 dwc2.1.auto: GNPTXSTS=00040300 > [23984.272473] dwc2 dwc2.1.auto: dwc2_hsotg_ep_disable(ep 880401a30528) > [23984.272478] dwc2 dwc2.1.auto: dwc2_hsotg_ep_disable: DxEPCTL=0x084a0200 > [23984.272485] dwc2 dwc2.1.auto: dwc2_hsotg_ep_disable(ep 880401a30328) > [23984.272490] dwc2 dwc2.1.auto: dwc2_hsotg_ep_stop_xfr: stopping > transfer on ep1out > [23984.272513] dwc2 dwc2.1.auto: dwc2_hsotg_ep_disable: DxEPCTL=0x08080200 > [23984.272540] dwc2 dwc2.1.auto: dwc2_hsotg_irq: 04008028 > (d0bc3cc4) retry 8 > > Connect > > [24010.664017] dwc2 dwc2.1.auto: gintsts=44008028 gintmsk=d0bc3cc4 > [24010.664023] dwc2 dwc2.1.auto: Session request interrupt - lx_state=0 > [24010.664035] dwc2 dwc2.1.auto: dwc2_hsotg_irq: 04008028 > (d0bc3cc4) retry 8 > > Run test > > First try to enumerate > > [24021.649528] dwc2 dwc2.1.auto: dwc2_hsotg_irq: 0400a028 2000 > (d0bc3cc4) retry 8 > [24021.649536] dwc2 dwc2.1.auto: EnumDone (DSTS=0x0043e902) > [24021.649539] dwc2 dwc2.1.auto: new device is full-speed > [24021.649618] dwc2 dwc2.1.auto: dwc2_hsotg_enqueue_setup: queueing > setup request > [24021.649623] dwc2 dwc2.1.auto: ep0: req 8803e495ef00: > 8@88040ad1d228, noi=0, zero=0, snok=0 > [24021.649631] dwc2 dwc2.1.auto: dwc2_hsotg_start_req: > DxEPCTL=0x80028000, ep 0, dir out > [24021.649636] dwc2 dwc2.1.auto: ureq->length:8 ureq->actual:0 > [24021.649640] dwc2 dwc2.1.auto: dwc2_hsotg_start_req: 1@8/8, 0x00080008 > => 0x0b10 > [24021.649643] dwc2 dwc2.1.auto: dwc2_hsotg_start_req: > 0xd9858800 => 0x0b14 > [24021.649645] dwc2 dwc2.1.auto: ep0 state:0 > [24021.649648] dwc2 dwc2.1.auto: dwc2_hsotg_start_req: DxEPCTL=0x80028000 > [24021.649654] dwc2 dwc2.1.auto: dwc2_hsotg_start_req: DXEPCTL=0x80028000 > [24021.649664] dwc2 dwc2.1.auto: EP0: DIEPCTL0=0x8000, > DOEPCTL0=0x80028000 > [24021.849430] dwc2 dwc2.1.auto: dw
[PATCH v2 00/10] Constify attribute_group structures
attribute_groups are not supposed to change at runtime. So mark the non-const structs as const. Arvind Yadav (10): [PATCH v2 01/10] net: cdc_ncm: constify attribute_group structures. [PATCH v2 02/10] net: can: at91_can: constify attribute_group structures. [PATCH v2 03/10] net: can: janz-ican3: constify attribute_group structures. [PATCH v2 04/10] wireless: ipw2200: constify attribute_group structures. [PATCH v2 05/10] wireless: ipw2100: constify attribute_group structures. [PATCH v2 06/10] wireless: iwlegacy: constify attribute_group structures. [PATCH v2 07/10] wireless: iwlegacy: Constify attribute_group structures. [PATCH v2 08/10] arcnet: com20020-pci: constify attribute_group structures. [PATCH v2 09/10] net: bonding: constify attribute_group structures. [PATCH v2 10/10] net: chelsio: cxgb3: constify attribute_group structures. drivers/net/arcnet/com20020-pci.c | 2 +- drivers/net/bonding/bond_sysfs.c| 2 +- drivers/net/can/at91_can.c | 2 +- drivers/net/can/janz-ican3.c| 2 +- drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 8 ++-- drivers/net/usb/cdc_ncm.c | 2 +- drivers/net/wireless/intel/ipw2x00/ipw2100.c| 2 +- drivers/net/wireless/intel/ipw2x00/ipw2200.c| 2 +- drivers/net/wireless/intel/iwlegacy/3945-mac.c | 2 +- drivers/net/wireless/intel/iwlegacy/4965-mac.c | 2 +- 10 files changed, 15 insertions(+), 11 deletions(-) -- 1.9.1
[PATCH v2 00/10] Constify attribute_group structures
attribute_groups are not supposed to change at runtime. So mark the non-const structs as const. Arvind Yadav (10): [PATCH v2 01/10] net: cdc_ncm: constify attribute_group structures. [PATCH v2 02/10] net: can: at91_can: constify attribute_group structures. [PATCH v2 03/10] net: can: janz-ican3: constify attribute_group structures. [PATCH v2 04/10] wireless: ipw2200: constify attribute_group structures. [PATCH v2 05/10] wireless: ipw2100: constify attribute_group structures. [PATCH v2 06/10] wireless: iwlegacy: constify attribute_group structures. [PATCH v2 07/10] wireless: iwlegacy: Constify attribute_group structures. [PATCH v2 08/10] arcnet: com20020-pci: constify attribute_group structures. [PATCH v2 09/10] net: bonding: constify attribute_group structures. [PATCH v2 10/10] net: chelsio: cxgb3: constify attribute_group structures. drivers/net/arcnet/com20020-pci.c | 2 +- drivers/net/bonding/bond_sysfs.c| 2 +- drivers/net/can/at91_can.c | 2 +- drivers/net/can/janz-ican3.c| 2 +- drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 8 ++-- drivers/net/usb/cdc_ncm.c | 2 +- drivers/net/wireless/intel/ipw2x00/ipw2100.c| 2 +- drivers/net/wireless/intel/ipw2x00/ipw2200.c| 2 +- drivers/net/wireless/intel/iwlegacy/3945-mac.c | 2 +- drivers/net/wireless/intel/iwlegacy/4965-mac.c | 2 +- 10 files changed, 15 insertions(+), 11 deletions(-) -- 1.9.1
[PATCH v2 07/10] wireless: iwlegacy: Constify attribute_group structures.
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work
with const attribute_group. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
---
Changes in v2:
Added cover later.
drivers/net/wireless/intel/iwlegacy/4965-mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlegacy/4965-mac.c
b/drivers/net/wireless/intel/iwlegacy/4965-mac.c
index 5b51fba..de9b652 100644
--- a/drivers/net/wireless/intel/iwlegacy/4965-mac.c
+++ b/drivers/net/wireless/intel/iwlegacy/4965-mac.c
@@ -4654,7 +4654,7 @@ static DEVICE_ATTR(tx_power, S_IWUSR | S_IRUGO,
il4965_show_tx_power,
NULL
};
-static struct attribute_group il_attribute_group = {
+static const struct attribute_group il_attribute_group = {
.name = NULL, /* put in device directory */
.attrs = il_sysfs_entries,
};
--
1.9.1
[PATCH v2 06/10] wireless: iwlegacy: constify attribute_group structures.
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work
with const attribute_group. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
---
Changes in v2:
Added cover later.
drivers/net/wireless/intel/iwlegacy/3945-mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlegacy/3945-mac.c
b/drivers/net/wireless/intel/iwlegacy/3945-mac.c
index 38bf403..329f3a6 100644
--- a/drivers/net/wireless/intel/iwlegacy/3945-mac.c
+++ b/drivers/net/wireless/intel/iwlegacy/3945-mac.c
@@ -3464,7 +3464,7 @@ static DEVICE_ATTR(antenna, S_IWUSR | S_IRUGO,
il3945_show_antenna,
NULL
};
-static struct attribute_group il3945_attribute_group = {
+static const struct attribute_group il3945_attribute_group = {
.name = NULL, /* put in device directory */
.attrs = il3945_sysfs_entries,
};
--
1.9.1
Re: [PATCH] usb: dwc2: gadget: On disconnect reset device address to zero
Hi, Minas Harutyunyan writes: >> Minas Harutyunyan writes: >>> USB CV driver stack doesn't perform USB RESET after device disconnect/ >>> connect, so need to reset to zero DEVADDR field in DCFG to pass >>> enumeration again. >>> >>> Signed-off-by: Minas Harutyunyan >>> --- >>> drivers/usb/dwc2/gadget.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c >>> index 98a4a79e7f6e..deb3d901b99d 100644 >>> --- a/drivers/usb/dwc2/gadget.c >>> +++ b/drivers/usb/dwc2/gadget.c >>> @@ -3174,6 +3174,9 @@ void dwc2_hsotg_disconnect(struct dwc2_hsotg *hsotg) >>> return; >>> >>> hsotg->connected = 0; >>> + /* On disconnect reset device address to zero */ >>> + __bic32(hsotg->regs + DCFG, DCFG_DEVADDR_MASK); >>> + >> >> Which of the tests are you talking about? Which particular USB CV are >> you running? >> > I used USB 3 Gen X CV (downloaded from usb.org 1-2 week ago). Tests are: > 1. "Device Summary" - after 1st pass, disconnect then connect again test > failed. Actually it show as "test passed" but not able to enumerate > device again. > 2. MSC "USB Mass Storage Power Up Test". After disconnect, by suite > request, and then connect test failed (pass, if reloading driver). I'll try these tests tomorrow next time I'm in the office. Woke up sick, working from home today :-s >> I don't remember ever seeing this with dwc3. How should I go about >> triggering this problem? If this was really the case, then we would have >> this on *all* UDCs. >> > dwc2 driver resetting DEVADDR in DCFG register only in function > dwc2_hsotg_core_init_disconnected() by soft reset. This function not > called on disconnect/connect with CV SW stack (function call not seen in > dmesg). right, this is a bug in dwc2. You should clear DEVADDR from your Reset handler, not disconnect. > This issue not seen with any other EHCI/XHCI hosts either on > Linux/Windows because these hosts issuing USB RESET, as result called > dwc2_hsotg_core_init_disconnected(). > > In dwc3 per my understanding same stuff done in function > dwc3_gadget_reset_interrupt(), am I right? right, as it should. If dwc3_gadget_reset_interrupt() runs, this means the host *is* issuing USB reset signalling. >> I just did a fresh install of USB 3 Gen X CV (that I just download from >> usb.org). Ran Chapter 9 tests against a HS dwc3 board I have around and >> I can't see the problem you're talking about. >> > Yes, this issue not seen with dwc3. because we clear DEVADDR on Reset. -- balbi
[PATCH v2 00/10] Constify attribute_group structures
attribute_groups are not supposed to change at runtime. So mark the non-const structs as const. Arvind Yadav (10): [PATCH v2 01/10] net: cdc_ncm: constify attribute_group structures. [PATCH v2 02/10] net: can: at91_can: constify attribute_group structures. [PATCH v2 03/10] net: can: janz-ican3: constify attribute_group structures. [PATCH v2 04/10] wireless: ipw2200: constify attribute_group structures. [PATCH v2 05/10] wireless: ipw2100: constify attribute_group structures. [PATCH v2 06/10] wireless: iwlegacy: constify attribute_group structures. [PATCH v2 07/10] wireless: iwlegacy: Constify attribute_group structures. [PATCH v2 08/10] arcnet: com20020-pci: constify attribute_group structures. [PATCH v2 09/10] net: bonding: constify attribute_group structures. [PATCH v2 10/10] net: chelsio: cxgb3: constify attribute_group structures. drivers/net/arcnet/com20020-pci.c | 2 +- drivers/net/bonding/bond_sysfs.c| 2 +- drivers/net/can/at91_can.c | 2 +- drivers/net/can/janz-ican3.c| 2 +- drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 8 ++-- drivers/net/usb/cdc_ncm.c | 2 +- drivers/net/wireless/intel/ipw2x00/ipw2100.c| 2 +- drivers/net/wireless/intel/ipw2x00/ipw2200.c| 2 +- drivers/net/wireless/intel/iwlegacy/3945-mac.c | 2 +- drivers/net/wireless/intel/iwlegacy/4965-mac.c | 2 +- 10 files changed, 15 insertions(+), 11 deletions(-) -- 1.9.1
Re: [PATCH 00/13]mpt3sas driver NVMe support:
Is there any update on this ? Will include linux-n...@lists.infradead.org in next version of this patch submission, if there is any change suggestion. Thanks, Suganath Prabu S On Thu, Jun 29, 2017 at 8:01 PM, Johannes Thumshirn wrote: > On Thu, Jun 29, 2017 at 07:49:01PM +0530, Suganath Prabu S wrote: >> Ventura Series controller are Tri-mode. The controller and >> firmware are capable of supporting NVMe devices and >> PCIe switches to be connected with the controller. This >> patch set adds driver level support for NVMe devices and >> PCIe switches. > > Hi Suganath, > Can you please also Cc linux-n...@lists.infradead.org for NVMe related topics. > > Thanks, > Johannes > -- > Johannes Thumshirn Storage > jthumsh...@suse.de+49 911 74053 689 > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg > GF: Felix Imendörffer, Jane Smithard, Graham Norton > HRB 21284 (AG Nürnberg) > Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
[PATCH v2 08/10] arcnet: com20020-pci: constify attribute_group structures.
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work
with const attribute_group. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
3409 948 2843851121 drivers/net/arcnet/com20020-pci.o
File size After adding 'const':
textdata bss dec hex filename
3473 884 2843851121 drivers/net/arcnet/com20020-pci.o
Signed-off-by: Arvind Yadav
---
Changes in v2:
Added cover later.
drivers/net/arcnet/com20020-pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/arcnet/com20020-pci.c
b/drivers/net/arcnet/com20020-pci.c
index 01cab95..eb7f767 100644
--- a/drivers/net/arcnet/com20020-pci.c
+++ b/drivers/net/arcnet/com20020-pci.c
@@ -109,7 +109,7 @@ static ssize_t backplane_mode_show(struct device *dev,
NULL,
};
-static struct attribute_group com20020_state_group = {
+static const struct attribute_group com20020_state_group = {
.name = NULL,
.attrs = com20020_state_attrs,
};
--
1.9.1
[PATCH v2 09/10] net: bonding: constify attribute_group structures.
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work
with const attribute_group. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
45121472 059841760 drivers/net/bonding/bond_sysfs.o
File size After adding 'const':
textdata bss dec hex filename
45761408 059841760 drivers/net/bonding/bond_sysfs.o
Signed-off-by: Arvind Yadav
---
Changes in v2:
Added cover later.
drivers/net/bonding/bond_sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 770623a..040b493 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -759,7 +759,7 @@ static DEVICE_ATTR(ad_user_port_key, S_IRUGO | S_IWUSR,
NULL,
};
-static struct attribute_group bonding_group = {
+static const struct attribute_group bonding_group = {
.name = "bonding",
.attrs = per_bond_attrs,
};
--
1.9.1
[PATCH v2 00/10] Constify attribute_group structures
attribute_groups are not supposed to change at runtime. So mark the non-const structs as const. Arvind Yadav (10): [PATCH v2 01/10] net: cdc_ncm: constify attribute_group structures. [PATCH v2 02/10] net: can: at91_can: constify attribute_group structures. [PATCH v2 03/10] net: can: janz-ican3: constify attribute_group structures. [PATCH v2 04/10] wireless: ipw2200: constify attribute_group structures. [PATCH v2 05/10] wireless: ipw2100: constify attribute_group structures. [PATCH v2 06/10] wireless: iwlegacy: constify attribute_group structures. [PATCH v2 07/10] wireless: iwlegacy: Constify attribute_group structures. [PATCH v2 08/10] arcnet: com20020-pci: constify attribute_group structures. [PATCH v2 09/10] net: bonding: constify attribute_group structures. [PATCH v2 10/10] net: chelsio: cxgb3: constify attribute_group structures. drivers/net/arcnet/com20020-pci.c | 2 +- drivers/net/bonding/bond_sysfs.c| 2 +- drivers/net/can/at91_can.c | 2 +- drivers/net/can/janz-ican3.c| 2 +- drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 8 ++-- drivers/net/usb/cdc_ncm.c | 2 +- drivers/net/wireless/intel/ipw2x00/ipw2100.c| 2 +- drivers/net/wireless/intel/ipw2x00/ipw2200.c| 2 +- drivers/net/wireless/intel/iwlegacy/3945-mac.c | 2 +- drivers/net/wireless/intel/iwlegacy/4965-mac.c | 2 +- 10 files changed, 15 insertions(+), 11 deletions(-) -- 1.9.1
Re: [PATCH 00/13]mpt3sas driver NVMe support:
On Tue, Jul 11, 2017 at 01:05:29PM +0530, Suganath Prabu Subramani wrote: > Is there any update on this ? > Will include linux-n...@lists.infradead.org in next version of this > patch submission, if there is any change suggestion. can you please re-send with Cc to linux-nvme? Thanks, Johannes -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
[PATCH v2 10/10] net: chelsio: cxgb3: constify attribute_group structures.
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work
with const attribute_group. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
28720 985 12 297177415 drivers/net/.../cxgb3/cxgb3_main.o
File size After adding 'const':
textdata bss dec hex filename
28848 857 12 297177415 drivers/net/.../cxgb3/cxgb3_main.o
Signed-off-by: Arvind Yadav
---
Changes in v2:
Added cover later.
drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
index 0bc6a4f..6a01536 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
@@ -793,7 +793,9 @@ static DEVICE_ATTR(name, S_IRUGO | S_IWUSR, show_##name,
store_method)
NULL
};
-static struct attribute_group cxgb3_attr_group = {.attrs = cxgb3_attrs };
+static const struct attribute_group cxgb3_attr_group = {
+ .attrs = cxgb3_attrs,
+};
static ssize_t tm_attr_show(struct device *d,
char *buf, int sched)
@@ -880,7 +882,9 @@ static DEVICE_ATTR(name, S_IRUGO | S_IWUSR, show_##name,
store_##name)
NULL
};
-static struct attribute_group offload_attr_group = {.attrs = offload_attrs };
+static const struct attribute_group offload_attr_group = {
+ .attrs = offload_attrs,
+};
/*
* Sends an sk_buff to an offload queue driver
--
1.9.1
Re: [PATCH] fsi: core: register with postcore_initcall
Hi Joel, > This fix registers the bus with postcore_initcall instead, to ensure > it is registered earlier on. Looks good to me. Acked-by: Jeremy Kerr Cheers, Jeremy
[PATCH v2 00/10] Constify attribute_group structures
attribute_groups are not supposed to change at runtime. So mark the non-const structs as const. Arvind Yadav (10): [PATCH v2 01/10] net: cdc_ncm: constify attribute_group structures. [PATCH v2 02/10] net: can: at91_can: constify attribute_group structures. [PATCH v2 03/10] net: can: janz-ican3: constify attribute_group structures. [PATCH v2 04/10] wireless: ipw2200: constify attribute_group structures. [PATCH v2 05/10] wireless: ipw2100: constify attribute_group structures. [PATCH v2 06/10] wireless: iwlegacy: constify attribute_group structures. [PATCH v2 07/10] wireless: iwlegacy: Constify attribute_group structures. [PATCH v2 08/10] arcnet: com20020-pci: constify attribute_group structures. [PATCH v2 09/10] net: bonding: constify attribute_group structures. [PATCH v2 10/10] net: chelsio: cxgb3: constify attribute_group structures. drivers/net/arcnet/com20020-pci.c | 2 +- drivers/net/bonding/bond_sysfs.c| 2 +- drivers/net/can/at91_can.c | 2 +- drivers/net/can/janz-ican3.c| 2 +- drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 8 ++-- drivers/net/usb/cdc_ncm.c | 2 +- drivers/net/wireless/intel/ipw2x00/ipw2100.c| 2 +- drivers/net/wireless/intel/ipw2x00/ipw2200.c| 2 +- drivers/net/wireless/intel/iwlegacy/3945-mac.c | 2 +- drivers/net/wireless/intel/iwlegacy/4965-mac.c | 2 +- 10 files changed, 15 insertions(+), 11 deletions(-) -- 1.9.1
[PATCH 3/3] ARM: dts: at91: sama5d2: use sama5d2 compatible string for SMC
A new compatible string has been introduced for sama5d2 SMC to allow to
manage the registers mapping change.
Signed-off-by: Ludovic Desroches
---
arch/arm/boot/dts/sama5d2.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index 4fcd5bb219e3..60e69aeacbdb 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -1048,7 +1048,7 @@
};
hsmc: hsmc@f8014000 {
- compatible = "atmel,sama5d3-smc", "syscon",
"simple-mfd";
+ compatible = "atmel,sama5d2-smc", "syscon",
"simple-mfd";
reg = <0xf8014000 0x1000>;
interrupts = <17 IRQ_TYPE_LEVEL_HIGH 6>;
clocks = <&hsmc_clk>;
--
2.12.2
[PATCH 1/3] mfd: syscon: update Atmel SMC binding doc
A new compatible string is introduced for SMC on sama5d2 to manage a different layout of the registers. Signed-off-by: Ludovic Desroches --- Documentation/devicetree/bindings/mfd/atmel-smc.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/mfd/atmel-smc.txt b/Documentation/devicetree/bindings/mfd/atmel-smc.txt index 26eeed373934..1103ce2030fb 100644 --- a/Documentation/devicetree/bindings/mfd/atmel-smc.txt +++ b/Documentation/devicetree/bindings/mfd/atmel-smc.txt @@ -8,6 +8,7 @@ Required properties: - compatible: Should be one of the following "atmel,at91sam9260-smc", "syscon" "atmel,sama5d3-smc", "syscon" + "atmel,sama5d2-smc", "syscon" - reg: Contains offset/length value of the SMC memory region. -- 2.12.2
[PATCH 0/3] Fix SMC layout register for sama5d2
Hi, The offset of some registers of the SMC is different between sama5d3/sama5d4 and sama5d2. An helper function has been added to retrieve the correct layout with the help of a new compatible string for sama5d2. The atmel-ebi device will store the register layout to allow the nand controller to setup correctly the data interface. Ludovic Desroches (3): mfd: syscon: update Atmel SMC binding doc mfd: syscon: atmel-smc: add helper to retrieve register layout ARM: dts: at91: sama5d2: use sama5d2 compatible string for SMC .../devicetree/bindings/mfd/atmel-smc.txt | 1 + arch/arm/boot/dts/sama5d2.dtsi | 2 +- drivers/memory/atmel-ebi.c | 13 +++-- drivers/mfd/atmel-smc.c| 67 +- drivers/mtd/nand/atmel/nand-controller.c | 10 +++- include/linux/mfd/syscon/atmel-smc.h | 32 --- 6 files changed, 94 insertions(+), 31 deletions(-) -- 2.12.2
[PATCH 2/3] mfd: syscon: atmel-smc: add helper to retrieve register layout
For HSMC controller, the register layout depends on the device i.e. the
offset of setup, pulse, cycle, mode and timings registers is not the
same. An helper is added to provide the correct register layout.
Fixes: fe9d7cb22ef3 ("mfd: syscon: atmel-smc: Add new helpers to ease
SMC regs manipulation")
Suggested-by: Boris Brezillon
Signed-off-by: Ludovic Desroches
---
drivers/memory/atmel-ebi.c | 13 +--
drivers/mfd/atmel-smc.c | 67 +---
drivers/mtd/nand/atmel/nand-controller.c | 10 +++--
include/linux/mfd/syscon/atmel-smc.h | 32 ++-
4 files changed, 92 insertions(+), 30 deletions(-)
diff --git a/drivers/memory/atmel-ebi.c b/drivers/memory/atmel-ebi.c
index 99e644cda4d1..63c9e7a76854 100644
--- a/drivers/memory/atmel-ebi.c
+++ b/drivers/memory/atmel-ebi.c
@@ -51,6 +51,7 @@ struct atmel_ebi {
struct {
struct regmap *regmap;
struct clk *clk;
+ const struct atmel_hsmc_reg_layout *layout;
} smc;
struct device *dev;
@@ -84,8 +85,8 @@ static void at91sam9_ebi_get_config(struct atmel_ebi_dev
*ebid,
static void sama5_ebi_get_config(struct atmel_ebi_dev *ebid,
struct atmel_ebi_dev_config *conf)
{
- atmel_hsmc_cs_conf_get(ebid->ebi->smc.regmap, conf->cs,
- &conf->smcconf);
+ atmel_hsmc_cs_conf_get(ebid->ebi->smc.regmap, ebid->ebi->smc.layout,
+ conf->cs, &conf->smcconf);
}
static const struct atmel_smc_timing_xlate timings_xlate_table[] = {
@@ -285,8 +286,8 @@ static void at91sam9_ebi_apply_config(struct atmel_ebi_dev
*ebid,
static void sama5_ebi_apply_config(struct atmel_ebi_dev *ebid,
struct atmel_ebi_dev_config *conf)
{
- atmel_hsmc_cs_conf_apply(ebid->ebi->smc.regmap, conf->cs,
-&conf->smcconf);
+ atmel_hsmc_cs_conf_apply(ebid->ebi->smc.regmap, ebid->ebi->smc.layout,
+conf->cs, &conf->smcconf);
}
static int atmel_ebi_dev_setup(struct atmel_ebi *ebi, struct device_node *np,
@@ -525,6 +526,10 @@ static int atmel_ebi_probe(struct platform_device *pdev)
if (IS_ERR(ebi->smc.regmap))
return PTR_ERR(ebi->smc.regmap);
+ ebi->smc.layout = atmel_hsmc_get_reg_layout(smc_np);
+ if (IS_ERR(ebi->smc.layout))
+ return PTR_ERR(ebi->smc.layout);
+
ebi->smc.clk = of_clk_get(smc_np, 0);
if (IS_ERR(ebi->smc.clk)) {
if (PTR_ERR(ebi->smc.clk) != -ENOENT)
diff --git a/drivers/mfd/atmel-smc.c b/drivers/mfd/atmel-smc.c
index 954cf0f66a31..1ad44e63b511 100644
--- a/drivers/mfd/atmel-smc.c
+++ b/drivers/mfd/atmel-smc.c
@@ -258,19 +258,21 @@ EXPORT_SYMBOL_GPL(atmel_smc_cs_conf_apply);
* atmel_hsmc_cs_conf_apply - apply an SMC CS conf
* @regmap: the HSMC regmap
* @cs: the CS id
+ * @layout: the layout of registers
* @conf the SMC CS conf to apply
*
* Applies an SMC CS configuration.
* Only valid on post-sama5 SoCs.
*/
-void atmel_hsmc_cs_conf_apply(struct regmap *regmap, int cs,
- const struct atmel_smc_cs_conf *conf)
+void atmel_hsmc_cs_conf_apply(struct regmap *regmap,
+ const struct atmel_hsmc_reg_layout *layout,
+ int cs, const struct atmel_smc_cs_conf *conf)
{
- regmap_write(regmap, ATMEL_HSMC_SETUP(cs), conf->setup);
- regmap_write(regmap, ATMEL_HSMC_PULSE(cs), conf->pulse);
- regmap_write(regmap, ATMEL_HSMC_CYCLE(cs), conf->cycle);
- regmap_write(regmap, ATMEL_HSMC_TIMINGS(cs), conf->timings);
- regmap_write(regmap, ATMEL_HSMC_MODE(cs), conf->mode);
+ regmap_write(regmap, ATMEL_HSMC_SETUP(layout, cs), conf->setup);
+ regmap_write(regmap, ATMEL_HSMC_PULSE(layout, cs), conf->pulse);
+ regmap_write(regmap, ATMEL_HSMC_CYCLE(layout, cs), conf->cycle);
+ regmap_write(regmap, ATMEL_HSMC_TIMINGS(layout, cs), conf->timings);
+ regmap_write(regmap, ATMEL_HSMC_MODE(layout, cs), conf->mode);
}
EXPORT_SYMBOL_GPL(atmel_hsmc_cs_conf_apply);
@@ -297,18 +299,55 @@ EXPORT_SYMBOL_GPL(atmel_smc_cs_conf_get);
* atmel_hsmc_cs_conf_get - retrieve the current SMC CS conf
* @regmap: the HSMC regmap
* @cs: the CS id
+ * @layout: the layout of registers
* @conf: the SMC CS conf object to store the current conf
*
* Retrieve the SMC CS configuration.
* Only valid on post-sama5 SoCs.
*/
-void atmel_hsmc_cs_conf_get(struct regmap *regmap, int cs,
- struct atmel_smc_cs_conf *conf)
+void atmel_hsmc_cs_conf_get(struct regmap *regmap,
+ const struct atmel_hsmc_reg_layout *layout,
+ int cs, struct atmel_smc_cs_conf *conf)
{
- regmap_read(regmap, ATMEL_HSMC_SETUP(cs), &conf->setup);
- regmap_read(regmap, ATMEL_HSMC_PULSE(cs), &conf->pulse);
-
Re: [PATCH RFC 0/2] KVM: x86: Support using the VMX preemption timer for APIC Timer periodic/oneshot mode
On 11/07/2017 02:13, Andy Lutomirski wrote: > On 10/11/2016 05:17 AM, Wanpeng Li wrote: >> Most windows guests which I have on hand currently still utilize APIC >> Timer >> periodic/oneshot mode instead of APIC Timer tsc-deadline mode: >> - windows 2008 server r2 >> - windows 2012 server r2 >> - windows 7 >> - windows 10 >> >> This patchset adds the support using the VMX preemption timer for APIC >> Timer >> periodic/oneshot mode. >> >> I add a print in oneshot mode testcase of kvm-unit-tests/apic.flat and >> observed >> that w/ patch the latency is ~2% of w/o patch. I think maybe something >> is still >> not right in the patchset, in addition, tmcct in apic_get_tmcct() >> maybe is not >> calculated correctly. Your comments to improve the patchset is a great >> appreciated. >> >> Wanpeng Li (2): >>KVM: lapic: Extract start_sw_period() to handle oneshot/periodic mode >>KVM: x86: Support using the vmx preemption timer for APIC Timer >> periodic/one mode >> >> arch/x86/kvm/lapic.c | 162 >> ++- >> 1 file changed, 95 insertions(+), 67 deletions(-) >> > > I think this is a step in the right direction, but I think there's a > different approach that would be much, much faster: use the VMX > preemption timer for *host* preemption. Specifically, do this: > > 1. Refactor the host TSC deadline timer a bit to allow the TSC deadline > timer to be "borrow". It might look something like this: > > u64 borrow_tsc_deadline(void (*timer_callback)()); > > The caller is now permitted to use the TSC deadline timer for its own > nefarious purposes. The caller promises to call return_tsc_deadline() > in a timely manner if the TSC exceeds the return value while the > deadline timer is borrowed. > > If the TSC deadline fires while it's borrowed, timer_callback() will be > called. > > void return_tsc_deadline(bool timer_fired); > > The caller is done borrowing the TSC deadline timer. The caller need > not reset the TSC deadline timer MSR to its previous value before > calling this. It must be called with IRQs on and preemption off. > > Getting this to work cleanly without races may be a bit tricky. So be it. > > 2. Teach KVM to use the VMX preemption timer as a substitute deadline > timer while in guest mode. Specifically, KVM will borrow_tsc_deadline() > (if TSC deadline is enabled) when entering guest mode and > return_tsc_deadline() when returning out of guest mode. > > 3. Now KVM can change its MSR bitmaps to allow the guest to program the > TSC deadline MSR directly. No exit at all needed to handle guest writes > to the deadline timer. This assumes that the TSC deadline MSR observes the guest TSC offset, which I'm not at all sure of. If you can't, you break live migration. Also, while it would halve the cost of a guest's programming of the timer tick, you would still incur the cost of a vmexit to call timer_callback (it would be different if you could program the TSC deadline timer to send a posted interrupt, of course). Things would be half as slow, but still a far cry from bare metal. Really, we should just ask Intel to virtualize the TSC deadline MSR. Paolo
Re: [PATCH v2 00/10] Constify attribute_group structures
On 07/11/2017 09:29 AM, Arvind Yadav wrote: > attribute_groups are not supposed to change at runtime. So mark the > non-const structs as const. [...] > drivers/net/can/at91_can.c | 2 +- > drivers/net/can/janz-ican3.c| 2 +- For the can drivers: Acked-by: Marc Kleine-Budde -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor
On 10.07.2017 22:49, Bandan Das wrote:
> When L2 uses vmfunc, L0 utilizes the associated vmexit to
> emulate a switching of the ept pointer by reloading the
> guest MMU.
>
> Signed-off-by: Paolo Bonzini
> Signed-off-by: Bandan Das
> ---
> arch/x86/include/asm/vmx.h | 6 +
> arch/x86/kvm/vmx.c | 58
> +++---
> 2 files changed, 61 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
> index da5375e..5f63a2e 100644
> --- a/arch/x86/include/asm/vmx.h
> +++ b/arch/x86/include/asm/vmx.h
> @@ -115,6 +115,10 @@
> #define VMX_MISC_SAVE_EFER_LMA 0x0020
> #define VMX_MISC_ACTIVITY_HLT0x0040
>
> +/* VMFUNC functions */
> +#define VMX_VMFUNC_EPTP_SWITCHING 0x0001
> +#define VMFUNC_EPTP_ENTRIES 512
> +
> static inline u32 vmx_basic_vmcs_revision_id(u64 vmx_basic)
> {
> return vmx_basic & GENMASK_ULL(30, 0);
> @@ -200,6 +204,8 @@ enum vmcs_field {
> EOI_EXIT_BITMAP2_HIGH = 0x2021,
> EOI_EXIT_BITMAP3= 0x2022,
> EOI_EXIT_BITMAP3_HIGH = 0x2023,
> + EPTP_LIST_ADDRESS = 0x2024,
> + EPTP_LIST_ADDRESS_HIGH = 0x2025,
> VMREAD_BITMAP = 0x2026,
> VMWRITE_BITMAP = 0x2028,
> XSS_EXIT_BITMAP = 0x202C,
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index fe8f5fc..0a969fb 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -246,6 +246,7 @@ struct __packed vmcs12 {
> u64 eoi_exit_bitmap1;
> u64 eoi_exit_bitmap2;
> u64 eoi_exit_bitmap3;
> + u64 eptp_list_address;
> u64 xss_exit_bitmap;
> u64 guest_physical_address;
> u64 vmcs_link_pointer;
> @@ -771,6 +772,7 @@ static const unsigned short vmcs_field_to_offset_table[]
> = {
> FIELD64(EOI_EXIT_BITMAP1, eoi_exit_bitmap1),
> FIELD64(EOI_EXIT_BITMAP2, eoi_exit_bitmap2),
> FIELD64(EOI_EXIT_BITMAP3, eoi_exit_bitmap3),
> + FIELD64(EPTP_LIST_ADDRESS, eptp_list_address),
> FIELD64(XSS_EXIT_BITMAP, xss_exit_bitmap),
> FIELD64(GUEST_PHYSICAL_ADDRESS, guest_physical_address),
> FIELD64(VMCS_LINK_POINTER, vmcs_link_pointer),
> @@ -1402,6 +1404,13 @@ static inline bool nested_cpu_has_vmfunc(struct vmcs12
> *vmcs12)
> return nested_cpu_has2(vmcs12, SECONDARY_EXEC_ENABLE_VMFUNC);
> }
>
> +static inline bool nested_cpu_has_eptp_switching(struct vmcs12 *vmcs12)
> +{
> + return nested_cpu_has_vmfunc(vmcs12) &&
> + (vmcs12->vm_function_control &
I wonder if it makes sense to rename vm_function_control to
- vmfunc_control
- vmfunc_controls (so it matches nested_vmx_vmfunc_controls)
- vmfunc_ctrl
> + VMX_VMFUNC_EPTP_SWITCHING);
> +}
> +
> static inline bool is_nmi(u32 intr_info)
> {
> return (intr_info & (INTR_INFO_INTR_TYPE_MASK | INTR_INFO_VALID_MASK))
> @@ -2791,7 +2800,12 @@ static void nested_vmx_setup_ctls_msrs(struct vcpu_vmx
> *vmx)
> if (cpu_has_vmx_vmfunc()) {
> vmx->nested.nested_vmx_secondary_ctls_high |=
> SECONDARY_EXEC_ENABLE_VMFUNC;
> - vmx->nested.nested_vmx_vmfunc_controls = 0;
> + /*
> + * Advertise EPTP switching unconditionally
> + * since we emulate it
> + */
> + vmx->nested.nested_vmx_vmfunc_controls =
> + VMX_VMFUNC_EPTP_SWITCHING;> }
>
> /*
> @@ -7772,6 +7786,9 @@ static int handle_vmfunc(struct kvm_vcpu *vcpu)
> struct vcpu_vmx *vmx = to_vmx(vcpu);
> struct vmcs12 *vmcs12;
> u32 function = vcpu->arch.regs[VCPU_REGS_RAX];
> + u32 index = vcpu->arch.regs[VCPU_REGS_RCX];
> + struct page *page = NULL;
> + u64 *l1_eptp_list, address;
>
> /*
>* VMFUNC is only supported for nested guests, but we always enable the
> @@ -7784,11 +7801,46 @@ static int handle_vmfunc(struct kvm_vcpu *vcpu)
> }
>
> vmcs12 = get_vmcs12(vcpu);
> - if ((vmcs12->vm_function_control & (1 << function)) == 0)
> + if (((vmcs12->vm_function_control & (1 << function)) == 0) ||
> + WARN_ON_ONCE(function))
"... instruction causes a VM exit if the bit at position EAX is 0 in the
VM-function controls (the selected VM function is
not enabled)."
So g2 can trigger this WARN_ON_ONCE, no? I think we should drop it then
completely.
> + goto fail;
> +
> + if (!nested_cpu_has_ept(vmcs12) ||
> + !nested_cpu_has_eptp_switching(vmcs12))
> + goto fail;
> +
> + if (!vmcs12->eptp_list_address || index >= VMFUNC_EPTP_ENTRIES)
> + goto fail;
I can find the definition for an vmexit in case of index >=
VMFUNC_EPTP_ENTRIES, but not for !vmcs12->eptp_list_address in the SDM.
Can you give me a hint?
> +
> + page = nested_get_page(vcpu, vmcs1
Re: [PATCH 3/3] ARM: dts: at91: sama5d2: use sama5d2 compatible string for SMC
On 11/07/2017 at 09:40, Ludovic Desroches wrote:
> A new compatible string has been introduced for sama5d2 SMC to allow to
> manage the registers mapping change.
>
> Signed-off-by: Ludovic Desroches
> ---
> arch/arm/boot/dts/sama5d2.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
> index 4fcd5bb219e3..60e69aeacbdb 100644
> --- a/arch/arm/boot/dts/sama5d2.dtsi
> +++ b/arch/arm/boot/dts/sama5d2.dtsi
> @@ -1048,7 +1048,7 @@
> };
>
> hsmc: hsmc@f8014000 {
> - compatible = "atmel,sama5d3-smc", "syscon",
> "simple-mfd";
> + compatible = "atmel,sama5d2-smc", "syscon",
> "simple-mfd";
You'd better use something like:
compatible = "atmel,sama5d2-smc", "atmel,sama5d3-smc", "syscon", "simple-mfd";
So that this patch is independent from the rest of the series and
we can avoid to having to synchronize with mfd or mtd/nand for this part.
Regards,
> reg = <0xf8014000 0x1000>;
> interrupts = <17 IRQ_TYPE_LEVEL_HIGH 6>;
> clocks = <&hsmc_clk>;
>
--
Nicolas Ferre
Re: [PATCH] drm: inhibit drm drivers register to uninitialized drm core
On Mon, Jul 10, 2017 at 09:56:20PM +0200, Alexandru Moise wrote:
> On Mon, Jul 10, 2017 at 08:00:37PM +0200, Daniel Vetter wrote:
> > On Mon, Jul 10, 2017 at 9:14 AM, Alexandru Moise
> > <00moses.alexande...@gmail.com> wrote:
> > > On Mon, Jul 10, 2017 at 08:52:46AM +0200, Daniel Vetter wrote:
> > >> On Sat, Jul 08, 2017 at 11:43:52PM +0200, Alexandru Moise wrote:
> > >> > If the DRM core fails to init for whatever reason, ensure that
> > >> > no driver ever calls drm_dev_register().
> > >> >
> > >> > This is best done at drm_dev_init() as it covers drivers that call
> > >> > drm_dev_alloc() as well as drivers that prefer to embed struct
> > >> > drm_device into their own device struct and call drm_dev_init()
> > >> > themselves.
> > >> >
> > >> > In my case I had so many dynamic device majors used that the major
> > >> > number for DRM (226) was stolen, causing DRM core init to fail after
> > >> > failing to register a chrdev, and ultimately calling debugfs_remove()
> > >> > on drm_debugfs_root in drm_core_exit().
> > >> >
> > >> > After drm core failed to init, VGEM was still calling
> > >> > drm_dev_register(),
> > >> > ultimately leading to drm_debugfs_init(), with drm_debugfs_root passed
> > >> > as the root for the new debugfs dir at debugfs_create_dir().
> > >> >
> > >> > This led to a kernel panic once we were either derefencing
> > >> > root->d_inode
> > >> > while it was NULL or calling root->d_inode->i_op->lookup() while it was
> > >> > NULL in debugfs at inode_lock() or lookup_*().
> > >> >
> > >> > Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com>
> > >> > ---
> > >> > drivers/gpu/drm/drm_drv.c | 16
> > >> > 1 file changed, 16 insertions(+)
> > >> >
> > >> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > >> > index 37b8ad3e30d8..2ed2d919beae 100644
> > >> > --- a/drivers/gpu/drm/drm_drv.c
> > >> > +++ b/drivers/gpu/drm/drm_drv.c
> > >> > @@ -63,6 +63,15 @@ module_param_named(debug, drm_debug, int, 0600);
> > >> > static DEFINE_SPINLOCK(drm_minor_lock);
> > >> > static struct idr drm_minors_idr;
> > >> >
> > >> > +/*
> > >> > + * If the drm core fails to init for whatever reason,
> > >> > + * we should prevent any drivers from registering with it.
> > >> > + * It's best to check this at drm_dev_init(), as some drivers
> > >> > + * prefer to embed struct drm_device into their own device
> > >> > + * structure and call drm_dev_init() themselves.
> > >> > + */
> > >> > +static bool drm_core_init_complete = false;
> > >> > +
> > >> > static struct dentry *drm_debugfs_root;
> > >> >
> > >> > #define DRM_PRINTK_FMT "[" DRM_NAME ":%s]%s %pV"
> > >> > @@ -484,6 +493,11 @@ int drm_dev_init(struct drm_device *dev,
> > >> > {
> > >> > int ret;
> > >> >
> > >> > + if (!drm_core_init_complete) {
> > >> > + DRM_ERROR("DRM core is not initialized\n");
> > >> > + return -ENODEV;
> > >> > + }
> > >> > +
> > >> > kref_init(&dev->ref);
> > >> > dev->dev = parent;
> > >> > dev->driver = driver;
> > >> > @@ -966,6 +980,8 @@ static int __init drm_core_init(void)
> > >> > if (ret < 0)
> > >> > goto error;
> > >> >
> > >> > + drm_core_init_complete = true;
> > >> > +
> > >> > DRM_DEBUG("Initialized\n");
> > >> > return 0;
> > >>
> > >> Isn't the correct fix to pass down the error value, which iirc should
> > >> make the kmod stuff unload the module again? Or does this not work'
> > >> -Daniel
> > >
> > > What if everything is built in?
> >
> > I feared that would be the answer :-/ Still feels funny that everyone
> > will need to hand-roll this, or does everyone simply assume that their
> > subsystem's module_init never fails?
> >
> > Adding a pile of kmod and driver folks in the hopes of getting a
> > better answer. If there's no better answer pls remind me to merge your
> > patch in 1-2 weeks, I'll likely forget ...
> > -Daniel
>
> I took a look at all the DRM drivers and they all seem pretty sane,
> they all handle the case of the DRM core failure, the fault is clearly
> on the DRM core side, it makes absolutely no sense trying to register
> with a subsystem that failed to init.
>
> This is certainly not a subsystem I am intimately acquainted with
> however, I just stumbled on this crash while working with debugfs.
>
> Most of the DRM core code looks pretty solid, and this is a relatively
> small corner-case, I believe most people out there won't be eating up
> that many major numbers. But I believe it's still the Right Thing™ to do.
>
> It might save some headaches in the future as DRM becomes more complex.
I'm not worried about drm or drm drivers here, I'm just wondered how all
the other subystems handle this same problem. Pretty sure we're not the
only ones who register a chardev block in the core subsystem module (and
sysfs classes, and tons of other stuff), and then drivers would fall over
if that's not there. Having to open code a $foo_init_successful everywhere
seems somewhat
Re: [RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks
On Mon, Jul 10, 2017 at 03:47:54PM -0700, John Stultz wrote:
> On Mon, Jul 10, 2017 at 2:18 PM, Sean Paul wrote:
> > On Mon, Jul 10, 2017 at 01:48:02PM -0700, John Stultz wrote:
> >> Currently the hikey dsi logic cannot generate accurate byte
> >> clocks values for all pixel clock values. Thus if a mode clock
> >> is selected that cannot match the calculated byte clock, the
> >> device will boot with a blank screen.
> >>
> >> This patch uses the new mode_valid callback (many thanks to
> >> Jose Abreu for upstreaming it!) to enforces known good mode
> >> clocks for well known resolutions, which should allow the
> >> display to work from given EDID options, and ensures for a given
> >> resolution & refresh, the right mode clock is selected.
> >>
> >> Cc: Daniel Vetter
> >> Cc: Jani Nikula
> >> Cc: Sean Paul
> >> Cc: David Airlie
> >> Cc: Rob Clark
> >> Cc: Xinliang Liu
> >> Cc: Xinliang Liu
> >> Cc: Rongrong Zou
> >> Cc: Xinwei Kong
> >> Cc: Chen Feng
> >> Cc: Jose Abreu
> >> Cc: Archit Taneja
> >> Cc: dri-de...@lists.freedesktop.org
> >> Signed-off-by: John Stultz
> >> ---
> >> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 37
> >>
> >> 1 file changed, 37 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> >> b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> >> index f77dcfa..a84f4bb 100644
> >> --- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> >> +++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> >> @@ -603,6 +603,42 @@ static void dsi_encoder_enable(struct drm_encoder
> >> *encoder)
> >> dsi->enable = true;
> >> }
> >>
> >> +static enum drm_mode_status dsi_encoder_mode_valid(struct drm_encoder
> >> *crtc,
> >> + const struct drm_display_mode *mode)
> >> +{
> >> + /*
> >> + * kirin cannot generate all modes, so use the whitelist below
> >> + */
> >> + DRM_DEBUG("%s: Checking mode %ix%i@%i clock: %i...", __func__,
> >> + mode->hdisplay, mode->vdisplay, drm_mode_vrefresh(mode),
> >> mode->clock);
> >> + if ((mode->hdisplay == 1920 && mode->vdisplay == 1080 && mode->clock
> >> == 148500) ||
> >> + (mode->hdisplay == 1920 && mode->vdisplay == 1080 && mode->clock
> >> == 80192) ||
> >> + (mode->hdisplay == 1920 && mode->vdisplay == 1080 && mode->clock
> >> == 74250) ||
> >> + (mode->hdisplay == 1920 && mode->vdisplay == 1080 && mode->clock
> >> == 61855) ||
> >> + (mode->hdisplay == 1680 && mode->vdisplay == 1050 && mode->clock
> >> == 147116) ||
> >> + (mode->hdisplay == 1680 && mode->vdisplay == 1050 && mode->clock
> >> == 146250) ||
> >> + (mode->hdisplay == 1680 && mode->vdisplay == 1050 && mode->clock
> >> == 144589) ||
> >> + (mode->hdisplay == 1600 && mode->vdisplay == 1200 && mode->clock
> >> == 160961) ||
> >> + (mode->hdisplay == 1600 && mode->vdisplay == 900 && mode->clock
> >> == 118963) ||
> >> + (mode->hdisplay == 1440 && mode->vdisplay == 900 && mode->clock
> >> == 126991) ||
> >> + (mode->hdisplay == 1280 && mode->vdisplay == 1024 && mode->clock
> >> == 128946) ||
> >> + (mode->hdisplay == 1280 && mode->vdisplay == 1024 && mode->clock
> >> == 98619) ||
> >> + (mode->hdisplay == 1280 && mode->vdisplay == 960 && mode->clock
> >> == 102081) ||
> >> + (mode->hdisplay == 1280 && mode->vdisplay == 800 && mode->clock
> >> == 83496) ||
> >> + (mode->hdisplay == 1280 && mode->vdisplay == 720 && mode->clock
> >> == 74440) ||
> >> + (mode->hdisplay == 1280 && mode->vdisplay == 720 && mode->clock
> >> == 74250) ||
> >> + (mode->hdisplay == 1024 && mode->vdisplay == 768 && mode->clock
> >> == 78800) ||
> >> + (mode->hdisplay == 1024 && mode->vdisplay == 768 && mode->clock
> >> == 75000) ||
> >> + (mode->hdisplay == 1024 && mode->vdisplay == 768 && mode->clock
> >> == 81833) ||
> >> + (mode->hdisplay == 800 && mode->vdisplay == 600 && mode->clock
> >> == 48907) ||
> >> + (mode->hdisplay == 800 && mode->vdisplay == 600 && mode->clock
> >> == 4)) {
> >
> > Bikeshed incoming:
> >
> > Can you break this out into a lookup table? It's kind of long-winded as-is.
> > It'd
>
> That's fair. The list has slowly grown from 4 or so modes to what it
> is now, so it is a bit longer then it was originally.
>
> I'll spin the patches with that change.
>
> > be even better if you could calculate whether the mode is valid, but I
> > didn't
> > spend enough time to figure out if this is possible.
>
> Theoretically that might be possible, checking if the requested freq
> matches the calculated freq, and I've tried that but so far I've not
> been able to get it to work, as in some cases the freq on the current
> whitelist don't exactly match but do work on the large majority of
> monitors tested (while other freq have a similar error but don't work
> on most mo
Re: [PATCH 3/3] ARM: dts: at91: sama5d2: use sama5d2 compatible string for SMC
On Tue, Jul 11, 2017 at 09:52:58AM +0200, Nicolas Ferre wrote:
> On 11/07/2017 at 09:40, Ludovic Desroches wrote:
> > A new compatible string has been introduced for sama5d2 SMC to allow to
> > manage the registers mapping change.
> >
> > Signed-off-by: Ludovic Desroches
> > ---
> > arch/arm/boot/dts/sama5d2.dtsi | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
> > index 4fcd5bb219e3..60e69aeacbdb 100644
> > --- a/arch/arm/boot/dts/sama5d2.dtsi
> > +++ b/arch/arm/boot/dts/sama5d2.dtsi
> > @@ -1048,7 +1048,7 @@
> > };
> >
> > hsmc: hsmc@f8014000 {
> > - compatible = "atmel,sama5d3-smc", "syscon",
> > "simple-mfd";
> > + compatible = "atmel,sama5d2-smc", "syscon",
> > "simple-mfd";
>
> You'd better use something like:
> compatible = "atmel,sama5d2-smc", "atmel,sama5d3-smc", "syscon",
> "simple-mfd";
But it's not true, during data interface setup, we will write values in
the wrong place if we fallback on "atmel,sama5d3-smc".
Regards
Ludovic
>
> So that this patch is independent from the rest of the series and
> we can avoid to having to synchronize with mfd or mtd/nand for this part.
>
> Regards,
>
> > reg = <0xf8014000 0x1000>;
> > interrupts = <17 IRQ_TYPE_LEVEL_HIGH 6>;
> > clocks = <&hsmc_clk>;
> >
>
>
> --
> Nicolas Ferre
Re: [PATCH v4 01/14] drm/atomic: export drm_atomic_replace_property_blob
On Thu, Jul 06, 2017 at 02:20:35PM +0200, Peter Rosin wrote:
> While at it, add some words in the kernel-doc about the 'replaced' arg and
> remove a faulty kernel-doc comment on the return value.
>
> Also remove a redundant return statement.
>
> Signed-off-by: Peter Rosin
> ---
> drivers/gpu/drm/drm_atomic.c | 17 +
> include/drm/drm_atomic.h | 4
> 2 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 09ca662..b7d9696 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -414,13 +414,15 @@ EXPORT_SYMBOL(drm_atomic_set_mode_prop_for_crtc);
> * @new_blob: the new blob to replace with
> * @replaced: whether the blob has been replaced
> *
> - * RETURNS:
> - * Zero on success, error code on failure
> + * Note that you are required to initialize @replaced to false before the
> + * call, since it is only set to true when the blob property is changed and
> + * not set to false when the property is not changed. This enables a series
> + * of calls to be made where you are interested in if any property is
> + * replaced, but not care so much about exactly which of them was replaced.
> */
> -static void
> -drm_atomic_replace_property_blob(struct drm_property_blob **blob,
> - struct drm_property_blob *new_blob,
> - bool *replaced)
> +void drm_atomic_replace_property_blob(struct drm_property_blob **blob,
> + struct drm_property_blob *new_blob,
> + bool *replaced)
Yes I know I'm super-annoying, but this function now feels misplaced. It
has nothing to do with atomic, it just replaces a pointer to a blob with
anther pointer. I think it'd be much better if we move this function to
drm_property.c, and rename it to drm_property_replace_blob.
Second, instead of typing a huge paragraph explaining how replaced works,
I think the better option would be to drop that parameter and instead
return a boolean indicating whether the blob was replaced or not.
That's a bit more work, but imo functions which are exported need to pass
a higher barrier wrt api polish.
Thanks, Daniel
> {
> struct drm_property_blob *old_blob = *blob;
>
> @@ -432,9 +434,8 @@ drm_atomic_replace_property_blob(struct drm_property_blob
> **blob,
> drm_property_blob_get(new_blob);
> *blob = new_blob;
> *replaced = true;
> -
> - return;
> }
> +EXPORT_SYMBOL(drm_atomic_replace_property_blob);
>
> static int
> drm_atomic_replace_property_blob_from_id(struct drm_device *dev,
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index dcc8e0c..8b32ea5 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -321,6 +321,10 @@ int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> struct drm_connector_state *state, struct drm_property
> *property,
> uint64_t val);
>
> +void drm_atomic_replace_property_blob(struct drm_property_blob **blob,
> + struct drm_property_blob *new_blob,
> + bool *replaced);
> +
> void * __must_check
> drm_atomic_get_private_obj_state(struct drm_atomic_state *state,
> void *obj,
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v4 02/14] drm/atomic-helper: update lut props directly in ..._legacy_gamma_set
On Thu, Jul 06, 2017 at 02:20:36PM +0200, Peter Rosin wrote:
> Do not waste cycles looking up the property id when we have the
> actual property already.
>
> Signed-off-by: Peter Rosin
With the names adjusted per my comments on patch 1 this lgtm. Btw good
practice is to cc original authors of the code, a combo of git blame and
scripts/get_maintainers.pl helps with that.
-Daniel
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 23 ---
> 1 file changed, 8 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 667ec97..5a4a344 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3769,11 +3769,11 @@ int drm_atomic_helper_legacy_gamma_set(struct
> drm_crtc *crtc,
> struct drm_modeset_acquire_ctx *ctx)
> {
> struct drm_device *dev = crtc->dev;
> - struct drm_mode_config *config = &dev->mode_config;
> struct drm_atomic_state *state;
> struct drm_crtc_state *crtc_state;
> struct drm_property_blob *blob = NULL;
> struct drm_color_lut *blob_data;
> + bool replaced = false;
> int i, ret = 0;
>
> state = drm_atomic_state_alloc(crtc->dev);
> @@ -3805,20 +3805,13 @@ int drm_atomic_helper_legacy_gamma_set(struct
> drm_crtc *crtc,
> }
>
> /* Reset DEGAMMA_LUT and CTM properties. */
> - ret = drm_atomic_crtc_set_property(crtc, crtc_state,
> - config->degamma_lut_property, 0);
> - if (ret)
> - goto fail;
> -
> - ret = drm_atomic_crtc_set_property(crtc, crtc_state,
> - config->ctm_property, 0);
> - if (ret)
> - goto fail;
> -
> - ret = drm_atomic_crtc_set_property(crtc, crtc_state,
> - config->gamma_lut_property, blob->base.id);
> - if (ret)
> - goto fail;
> + drm_atomic_replace_property_blob(&crtc_state->degamma_lut,
> + NULL, &replaced);
> + drm_atomic_replace_property_blob(&crtc_state->ctm,
> + NULL, &replaced);
> + drm_atomic_replace_property_blob(&crtc_state->gamma_lut,
> + blob, &replaced);
> + crtc_state->color_mgmt_changed |= replaced;
>
> ret = drm_atomic_commit(state);
>
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 3/3] ARM: dts: at91: sama5d2: use sama5d2 compatible string for SMC
On 11/07/2017 at 09:58, Ludovic Desroches wrote:
> On Tue, Jul 11, 2017 at 09:52:58AM +0200, Nicolas Ferre wrote:
>> On 11/07/2017 at 09:40, Ludovic Desroches wrote:
>>> A new compatible string has been introduced for sama5d2 SMC to allow to
>>> manage the registers mapping change.
>>>
>>> Signed-off-by: Ludovic Desroches
>>> ---
>>> arch/arm/boot/dts/sama5d2.dtsi | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
>>> index 4fcd5bb219e3..60e69aeacbdb 100644
>>> --- a/arch/arm/boot/dts/sama5d2.dtsi
>>> +++ b/arch/arm/boot/dts/sama5d2.dtsi
>>> @@ -1048,7 +1048,7 @@
>>> };
>>>
>>> hsmc: hsmc@f8014000 {
>>> - compatible = "atmel,sama5d3-smc", "syscon",
>>> "simple-mfd";
>>> + compatible = "atmel,sama5d2-smc", "syscon",
>>> "simple-mfd";
>>
>> You'd better use something like:
>> compatible = "atmel,sama5d2-smc", "atmel,sama5d3-smc", "syscon",
>> "simple-mfd";
>
> But it's not true, during data interface setup, we will write values in
> the wrong place if we fallback on "atmel,sama5d3-smc".
Yes, I wrote too quickly: sorry for the noise ;-)
Bye,
>> So that this patch is independent from the rest of the series and
>> we can avoid to having to synchronize with mfd or mtd/nand for this part.
>>
>> Regards,
>>
>>> reg = <0xf8014000 0x1000>;
>>> interrupts = <17 IRQ_TYPE_LEVEL_HIGH 6>;
>>> clocks = <&hsmc_clk>;
>>>
>>
>>
>> --
>> Nicolas Ferre
>
--
Nicolas Ferre
Re: [PATCH 2/3] mfd: syscon: atmel-smc: add helper to retrieve register layout
On Tue, 11 Jul 2017 09:40:14 +0200
Ludovic Desroches wrote:
> For HSMC controller, the register layout depends on the device i.e. the
> offset of setup, pulse, cycle, mode and timings registers is not the
> same. An helper is added to provide the correct register layout.
>
> Fixes: fe9d7cb22ef3 ("mfd: syscon: atmel-smc: Add new helpers to ease
> SMC regs manipulation")
> Suggested-by: Boris Brezillon
> Signed-off-by: Ludovic Desroches
Acked-by: Boris Brezillon
> ---
> drivers/memory/atmel-ebi.c | 13 +--
> drivers/mfd/atmel-smc.c | 67
> +---
> drivers/mtd/nand/atmel/nand-controller.c | 10 +++--
> include/linux/mfd/syscon/atmel-smc.h | 32 ++-
> 4 files changed, 92 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/memory/atmel-ebi.c b/drivers/memory/atmel-ebi.c
> index 99e644cda4d1..63c9e7a76854 100644
> --- a/drivers/memory/atmel-ebi.c
> +++ b/drivers/memory/atmel-ebi.c
> @@ -51,6 +51,7 @@ struct atmel_ebi {
> struct {
> struct regmap *regmap;
> struct clk *clk;
> + const struct atmel_hsmc_reg_layout *layout;
> } smc;
>
> struct device *dev;
> @@ -84,8 +85,8 @@ static void at91sam9_ebi_get_config(struct atmel_ebi_dev
> *ebid,
> static void sama5_ebi_get_config(struct atmel_ebi_dev *ebid,
>struct atmel_ebi_dev_config *conf)
> {
> - atmel_hsmc_cs_conf_get(ebid->ebi->smc.regmap, conf->cs,
> -&conf->smcconf);
> + atmel_hsmc_cs_conf_get(ebid->ebi->smc.regmap, ebid->ebi->smc.layout,
> +conf->cs, &conf->smcconf);
> }
>
> static const struct atmel_smc_timing_xlate timings_xlate_table[] = {
> @@ -285,8 +286,8 @@ static void at91sam9_ebi_apply_config(struct
> atmel_ebi_dev *ebid,
> static void sama5_ebi_apply_config(struct atmel_ebi_dev *ebid,
> struct atmel_ebi_dev_config *conf)
> {
> - atmel_hsmc_cs_conf_apply(ebid->ebi->smc.regmap, conf->cs,
> - &conf->smcconf);
> + atmel_hsmc_cs_conf_apply(ebid->ebi->smc.regmap, ebid->ebi->smc.layout,
> + conf->cs, &conf->smcconf);
> }
>
> static int atmel_ebi_dev_setup(struct atmel_ebi *ebi, struct device_node *np,
> @@ -525,6 +526,10 @@ static int atmel_ebi_probe(struct platform_device *pdev)
> if (IS_ERR(ebi->smc.regmap))
> return PTR_ERR(ebi->smc.regmap);
>
> + ebi->smc.layout = atmel_hsmc_get_reg_layout(smc_np);
> + if (IS_ERR(ebi->smc.layout))
> + return PTR_ERR(ebi->smc.layout);
> +
> ebi->smc.clk = of_clk_get(smc_np, 0);
> if (IS_ERR(ebi->smc.clk)) {
> if (PTR_ERR(ebi->smc.clk) != -ENOENT)
> diff --git a/drivers/mfd/atmel-smc.c b/drivers/mfd/atmel-smc.c
> index 954cf0f66a31..1ad44e63b511 100644
> --- a/drivers/mfd/atmel-smc.c
> +++ b/drivers/mfd/atmel-smc.c
> @@ -258,19 +258,21 @@ EXPORT_SYMBOL_GPL(atmel_smc_cs_conf_apply);
> * atmel_hsmc_cs_conf_apply - apply an SMC CS conf
> * @regmap: the HSMC regmap
> * @cs: the CS id
> + * @layout: the layout of registers
> * @conf the SMC CS conf to apply
> *
> * Applies an SMC CS configuration.
> * Only valid on post-sama5 SoCs.
> */
> -void atmel_hsmc_cs_conf_apply(struct regmap *regmap, int cs,
> - const struct atmel_smc_cs_conf *conf)
> +void atmel_hsmc_cs_conf_apply(struct regmap *regmap,
> + const struct atmel_hsmc_reg_layout *layout,
> + int cs, const struct atmel_smc_cs_conf *conf)
> {
> - regmap_write(regmap, ATMEL_HSMC_SETUP(cs), conf->setup);
> - regmap_write(regmap, ATMEL_HSMC_PULSE(cs), conf->pulse);
> - regmap_write(regmap, ATMEL_HSMC_CYCLE(cs), conf->cycle);
> - regmap_write(regmap, ATMEL_HSMC_TIMINGS(cs), conf->timings);
> - regmap_write(regmap, ATMEL_HSMC_MODE(cs), conf->mode);
> + regmap_write(regmap, ATMEL_HSMC_SETUP(layout, cs), conf->setup);
> + regmap_write(regmap, ATMEL_HSMC_PULSE(layout, cs), conf->pulse);
> + regmap_write(regmap, ATMEL_HSMC_CYCLE(layout, cs), conf->cycle);
> + regmap_write(regmap, ATMEL_HSMC_TIMINGS(layout, cs), conf->timings);
> + regmap_write(regmap, ATMEL_HSMC_MODE(layout, cs), conf->mode);
> }
> EXPORT_SYMBOL_GPL(atmel_hsmc_cs_conf_apply);
>
> @@ -297,18 +299,55 @@ EXPORT_SYMBOL_GPL(atmel_smc_cs_conf_get);
> * atmel_hsmc_cs_conf_get - retrieve the current SMC CS conf
> * @regmap: the HSMC regmap
> * @cs: the CS id
> + * @layout: the layout of registers
> * @conf: the SMC CS conf object to store the current conf
> *
> * Retrieve the SMC CS configuration.
> * Only valid on post-sama5 SoCs.
> */
> -void atmel_hsmc_cs_conf_get(struct regmap *regmap, int cs,
> - struct atmel_smc_cs_conf *conf)
> +void atmel_hsmc_cs_conf_get(struct regmap *regmap,
> + const struct a
Re: [PATCH 3/3] ARM: dts: at91: sama5d2: use sama5d2 compatible string for SMC
On Tue, Jul 11, 2017 at 09:58:29AM +0200, Ludovic Desroches wrote:
> On Tue, Jul 11, 2017 at 09:52:58AM +0200, Nicolas Ferre wrote:
> > On 11/07/2017 at 09:40, Ludovic Desroches wrote:
> > > A new compatible string has been introduced for sama5d2 SMC to allow to
> > > manage the registers mapping change.
> > >
> > > Signed-off-by: Ludovic Desroches
> > > ---
> > > arch/arm/boot/dts/sama5d2.dtsi | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/boot/dts/sama5d2.dtsi
> > > b/arch/arm/boot/dts/sama5d2.dtsi
> > > index 4fcd5bb219e3..60e69aeacbdb 100644
> > > --- a/arch/arm/boot/dts/sama5d2.dtsi
> > > +++ b/arch/arm/boot/dts/sama5d2.dtsi
> > > @@ -1048,7 +1048,7 @@
> > > };
> > >
> > > hsmc: hsmc@f8014000 {
> > > - compatible = "atmel,sama5d3-smc", "syscon",
> > > "simple-mfd";
> > > + compatible = "atmel,sama5d2-smc", "syscon",
> > > "simple-mfd";
> >
> > You'd better use something like:
> > compatible = "atmel,sama5d2-smc", "atmel,sama5d3-smc", "syscon",
> > "simple-mfd";
>
> But it's not true, during data interface setup, we will write values in
> the wrong place if we fallback on "atmel,sama5d3-smc".
>
> Regards
>
> Ludovic
>
> >
> > So that this patch is independent from the rest of the series and
> > we can avoid to having to synchronize with mfd or mtd/nand for this part.
If Lee and Boris agree, maybe the series can go through AT91.
Regards
Ludovic
> >
> > Regards,
> >
> > > reg = <0xf8014000 0x1000>;
> > > interrupts = <17 IRQ_TYPE_LEVEL_HIGH 6>;
> > > clocks = <&hsmc_clk>;
> > >
> >
> >
> > --
> > Nicolas Ferre
Re: [PATCH v4 03/14] drm/fb-helper: separate the fb_setcmap helper into atomic and legacy paths
On Thu, Jul 06, 2017 at 02:20:37PM +0200, Peter Rosin wrote:
> The legacy path implements setcmap in terms of crtc .gamma_set.
>
> The atomic path implements setcmap by directly updating the crtc gamma_lut
> property.
>
> This has a couple of benefits:
> - it makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
> completely obsolete. They are now unused and subject for removal.
> - atomic drivers that support clut modes get fbdev support for those from
> the drm core. This includes atmel-hlcdc, but perhaps others as well?
>
> Signed-off-by: Peter Rosin
> ---
> drivers/gpu/drm/drm_fb_helper.c | 232
>
> 1 file changed, 161 insertions(+), 71 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 721511d..32d6ea1 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1195,27 +1195,6 @@ void drm_fb_helper_set_suspend_unlocked(struct
> drm_fb_helper *fb_helper,
> }
> EXPORT_SYMBOL(drm_fb_helper_set_suspend_unlocked);
>
> -static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
> - u16 blue, u16 regno, struct fb_info *info)
> -{
> - struct drm_fb_helper *fb_helper = info->par;
> - struct drm_framebuffer *fb = fb_helper->fb;
> -
> - /*
> - * The driver really shouldn't advertise pseudo/directcolor
> - * visuals if it can't deal with the palette.
> - */
> - if (WARN_ON(!fb_helper->funcs->gamma_set ||
> - !fb_helper->funcs->gamma_get))
> - return -EINVAL;
> -
> - WARN_ON(fb->format->cpp[0] != 1);
> -
> - fb_helper->funcs->gamma_set(crtc, red, green, blue, regno);
> -
> - return 0;
> -}
> -
> static int setcmap_pseudo_palette(struct fb_cmap *cmap, struct fb_info *info)
> {
> u32 *palette = (u32 *)info->pseudo_palette;
> @@ -1248,57 +1227,140 @@ static int setcmap_pseudo_palette(struct fb_cmap
> *cmap, struct fb_info *info)
> return 0;
> }
>
> -/**
> - * drm_fb_helper_setcmap - implementation for &fb_ops.fb_setcmap
> - * @cmap: cmap to set
> - * @info: fbdev registered by the helper
> - */
> -int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info)
> +static int setcmap_legacy(struct fb_cmap *cmap, struct fb_info *info)
> {
> struct drm_fb_helper *fb_helper = info->par;
> - struct drm_device *dev = fb_helper->dev;
> - const struct drm_crtc_helper_funcs *crtc_funcs;
> - u16 *red, *green, *blue, *transp;
> struct drm_crtc *crtc;
> u16 *r, *g, *b;
> - int i, j, rc = 0;
> - int start;
> + int i, ret = 0;
>
> - if (oops_in_progress)
> - return -EBUSY;
> + drm_modeset_lock_all(fb_helper->dev);
> + for (i = 0; i < fb_helper->crtc_count; i++) {
> + crtc = fb_helper->crtc_info[i].mode_set.crtc;
> + if (!crtc->funcs->gamma_set || !crtc->gamma_size)
> + return -EINVAL;
>
> - mutex_lock(&fb_helper->lock);
> - if (!drm_fb_helper_is_bound(fb_helper)) {
> - mutex_unlock(&fb_helper->lock);
> - return -EBUSY;
> + if (cmap->start + cmap->len > crtc->gamma_size)
> + return -EINVAL;
> +
> + r = crtc->gamma_store;
> + g = r + crtc->gamma_size;
> + b = g + crtc->gamma_size;
> +
> + memcpy(r + cmap->start, cmap->red, cmap->len * sizeof(*r));
> + memcpy(g + cmap->start, cmap->green, cmap->len * sizeof(*g));
> + memcpy(b + cmap->start, cmap->blue, cmap->len * sizeof(*b));
> +
> + ret = crtc->funcs->gamma_set(crtc, r, g, b,
> + crtc->gamma_size, NULL);
> + if (ret)
> + return ret;
> }
> + drm_modeset_unlock_all(fb_helper->dev);
>
> - drm_modeset_lock_all(dev);
> - if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
> - rc = setcmap_pseudo_palette(cmap, info);
> - goto out;
> + return ret;
> +}
> +
> +static struct drm_property_blob *setcmap_new_gamma_lut(struct drm_crtc *crtc,
> +struct fb_cmap *cmap)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_property_blob *gamma_lut;
> + struct drm_color_lut *lut;
> + int size = crtc->gamma_size;
> + int i;
> +
> + if (!size || cmap->start + cmap->len > size)
> + return ERR_PTR(-EINVAL);
> +
> + gamma_lut = drm_property_create_blob(dev, sizeof(*lut) * size, NULL);
> + if (IS_ERR(gamma_lut))
> + return gamma_lut;
> +
> + lut = (struct drm_color_lut *)gamma_lut->data;
> + if (cmap->start || cmap->len != size) {
> + u16 *r = crtc->gamma_store;
> + u16 *g = r + crtc->gamma_size;
> + u16 *b = g + crtc->gamma_size;
> +
> + for (i = 0; i < cmap->start; i++) {
> + l
Re: [PATCH] usb: isp1760: compress return logic into one line
Am Montag, den 10.07.2017, 14:58 -0500 schrieb Gustavo A. R. Silva : > Hi Oliver, > > Quoting Oliver Neukum : > > > > > Am Sonntag, den 09.07.2017, 21:00 -0500 schrieb Gustavo A. R. Silva : > > > > > > Simplify return logic to avoid unnecessary variable assignment. > > > > > > This issue was detected using Coccinelle and the following > > > semantic patch: > > > > > > > Hi, > > > > I need to ask: Where is the improvement? The compiler does not bother > > and for the human reader you do not do anything obvious and you > > decreased grepability. > > > > The declaration of local variable _retval_ was removed also. > So both, variable declaration and assignment removal are the improvements. Yeah, but a variable called "retval" has an extremely clear function. Simplifying code is an improvement. Making it clearer is an improvement. I am sorry but the proposed change is almost like removing blank lines to make it more compact > Regarding the greability, I think that depends on the context. "retval" has a clear function and is unique. Regards Oliver
Re: [PATCH v4 14/14] drm: remove unused and redundant callbacks
On Thu, Jul 06, 2017 at 02:20:48PM +0200, Peter Rosin wrote:
> Drivers no longer have any need for these callbacks, and there are no
> users. Zap. Zap-zap-zzzap-p-pp-p.
>
> Signed-off-by: Peter Rosin
On patches 4-14: Acked-by: Daniel Vetter
I'll try to haggle for a few more reviews by maintainers as soon as the
first 3 patches have landed, but I think I'll pull them all in about a
month or so latest. Please remind me in case I forget to do that (which is
likely ...).
Thanks a lot for doing this.
-Daniel
> ---
> include/drm/drm_crtc.h | 8
> include/drm/drm_fb_helper.h | 32
>
> include/drm/drm_modeset_helper_vtables.h | 16
> 3 files changed, 56 deletions(-)
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 3a911a6..0cc8962 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -358,14 +358,6 @@ struct drm_crtc_funcs {
>* drm_crtc_enable_color_mgmt(), which then supports the legacy gamma
>* interface through the drm_atomic_helper_legacy_gamma_set()
>* compatibility implementation.
> - *
> - * NOTE:
> - *
> - * Drivers that support gamma tables and also fbdev emulation through
> - * the provided helper library need to take care to fill out the gamma
> - * hooks for both. Currently there's a bit an unfortunate duplication
> - * going on, which should eventually be unified to just one set of
> - * hooks.
>*/
> int (*gamma_set)(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b,
>uint32_t size,
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index ea170b9..21c5630 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -85,38 +85,6 @@ struct drm_fb_helper_surface_size {
> */
> struct drm_fb_helper_funcs {
> /**
> - * @gamma_set:
> - *
> - * Set the given gamma LUT register on the given CRTC.
> - *
> - * This callback is optional.
> - *
> - * FIXME:
> - *
> - * This callback is functionally redundant with the core gamma table
> - * support and simply exists because the fbdev hasn't yet been
> - * refactored to use the core gamma table interfaces.
> - */
> - void (*gamma_set)(struct drm_crtc *crtc, u16 red, u16 green,
> - u16 blue, int regno);
> - /**
> - * @gamma_get:
> - *
> - * Read the given gamma LUT register on the given CRTC, used to save the
> - * current LUT when force-restoring the fbdev for e.g. kdbg.
> - *
> - * This callback is optional.
> - *
> - * FIXME:
> - *
> - * This callback is functionally redundant with the core gamma table
> - * support and simply exists because the fbdev hasn't yet been
> - * refactored to use the core gamma table interfaces.
> - */
> - void (*gamma_get)(struct drm_crtc *crtc, u16 *red, u16 *green,
> - u16 *blue, int regno);
> -
> - /**
>* @fb_probe:
>*
>* Driver callback to allocate and initialize the fbdev info structure.
> diff --git a/include/drm/drm_modeset_helper_vtables.h
> b/include/drm/drm_modeset_helper_vtables.h
> index 0656984..6cdcb42 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -267,22 +267,6 @@ struct drm_crtc_helper_funcs {
> enum mode_set_atomic);
>
> /**
> - * @load_lut:
> - *
> - * Load a LUT prepared with the &drm_fb_helper_funcs.gamma_set vfunc.
> - *
> - * This callback is optional and is only used by the fbdev emulation
> - * helpers.
> - *
> - * FIXME:
> - *
> - * This callback is functionally redundant with the core gamma table
> - * support and simply exists because the fbdev hasn't yet been
> - * refactored to use the core gamma table interfaces.
> - */
> - void (*load_lut)(struct drm_crtc *crtc);
> -
> - /**
>* @disable:
>*
>* This callback should be used to disable the CRTC. With the atomic
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [GIT PULL 0/3] perf/urgent fixes
* Arnaldo Carvalho de Melo wrote: > Hi Ingo, > > Please consider pulling, the exclude_kernel one is a nasty brown paper > bag one, I'd say :-\ > > - Arnaldo > > Test results at the end of this message, as usual. > > The following changes since commit dbf580623d5fee785218d1a47a2bcdf36d85c0e9: > > kprobes: Ensure that jprobe probepoints are at function entry (2017-07-08 > 11:05:35 +0200) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-urgent-for-mingo-4.13-20170710 > > for you to fetch changes up to 80f62589fa52f530cffc50e78c0b5a2ae572d61e: > > perf annotate: Fix broken arrow at row 0 connecting jmp instruction to its > target (2017-07-10 16:36:40 -0300) > > > perf/urgent fixes: > > - Fix attr.exclude_kernel setting for default cycles:p (Arnaldo Carvalho de > Melo) > > - Fix broken arrow at row 0 connecting jmp instruction to its target in > the annotate TUI (Jin Yao) > > Signed-off-by: Arnaldo Carvalho de Melo > > > Arnaldo Carvalho de Melo (2): > perf evsel: Fix attr.exclude_kernel setting for default cycles:p > perf evsel: State in the default event name if attr.exclude_kernel is > set > > Jin Yao (1): > perf annotate: Fix broken arrow at row 0 connecting jmp instruction to > its target > > tools/perf/ui/browser.c | 2 +- > tools/perf/util/evsel.c | 8 +--- > 2 files changed, 6 insertions(+), 4 deletions(-) Pulled, thanks a lot Arnaldo! Ingo
Re: [PATCH] KVM: s390: Fix KVM_S390_GET_CMMA_BITS ioctl definition
On 07/10/2017 11:23 PM, Gleb Fotengauer-Malinovskiy wrote:
> On Mon, Jul 10, 2017 at 08:43:12PM +0200, Christian Borntraeger wrote:
>> On 07/10/2017 04:44 PM, Gleb Fotengauer-Malinovskiy wrote:
>>> This ioctl actually writes to parameter too.
>>
>> Maybe rephrase that to:
>> The kernel does not only read struct kvm_s390_cmma_log for
>> KVM_S390_GET_CMMA_BITS,
>> it also writes back a return value making this _IOWR instead of _IOW.
>
> Ok, see v2.
>
>>> Fixes: 4036e387 ("KVM: s390: ioctls to get and set guest storage
>>> attributes")
>>> Signed-off-by: Gleb Fotengauer-Malinovskiy
>> Acked-by: Christian Borntraeger
>>
>>
>> Out of curiosity, how did you notice that?
>
> I regenerated strace's ioctl lists. It was obvious from the diff that
> *GET* and *SET* could not be both _IOC_WRITE.
>
In fact we do have multiple GET/SET ioctls in KVM, where both provide a control
block that is _IOC_WRITE only. That control block then has an address that will
be read/written to depending on get/set.
E.g. look at
#define KVM_SET_DEVICE_ATTR _IOW(KVMIO, 0xe1, struct kvm_device_attr)
#define KVM_GET_DEVICE_ATTR _IOW(KVMIO, 0xe2, struct kvm_device_attr)
but as far as I understand, the direction hints only qualify the referenced
struct and not the side effects. So for KVM_*_DEVICE_ATTR it is correct to have
IOW for both cases.
But for GET_CMMA we do indeed write back data.
Paolo, Radim,
if we want to fix the direction hint, it would be good to merge this in as soon
as possible. The new interface was added during this merge window.
Re: A udev rule to serve the change event of ACPI container?
On Mon 26-06-17 10:59:07, Michal Hocko wrote: > On Mon 26-06-17 14:26:57, Joey Lee wrote: > > Hi all, > > > > If ACPI received ejection request for a ACPI container, kernel > > emits KOBJ_CHANGE uevent when it found online children devices > > below the acpi container. > > > > Base on the description of caa73ea15 kernel patch, user space > > is expected to offline all devices below the container and the > > container itself. Then, user space can finalize the removal of > > the container with the help of its ACPI device object's eject > > attribute in sysfs. > > > > That means that kernel relies on users space to peform the offline > > and ejection jobs to acpi container and children devices. The > > discussion is here: > > https://lkml.org/lkml/2013/11/28/520 > > > > The mail loop didn't explain why the userspace is responsible for > > the whole container offlining. Is it possible to do that transparently > > from the kernel? What's the difference between offlining memory and > > processors which happends without any cleanup and container which > > does essentially the same except it happens at once? > > > > - After a couple of years, can we let the container hot-remove > >process transparently? > > - Except udev rule, does there have any other mechanism to trigger > >auto offline/ejection? > > I would be also interested whether the kernel can simply send an udev event > to all devices in the container. Any opinion on this? -- Michal Hocko SUSE Labs
Re: [PATCH] serial: 8250_of: Fix regression in reset support
Hi Linus,
On Mon, 2017-07-10 at 17:24 +0200, Linus Walleij wrote:
> commit e2860e1f62f2 ("serial: 8250_of: Add reset support")
> introduced reset support for the 8250_of driver.
>
> However it unconditionally uses the assert/deassert pair to
> deassert reset on the device at probe and assert it at
> remove. This does not work with systems that have a
> self-deasserting reset controller, such as Gemini, that
> recently added a reset controller.
Self-deasserting resets are fundamentally incompatible with
assert/deassert in the current shared reset model (as there is no
framework for deferring or or vetoing reset assertions while one of the
devices sharing the reset line could be negatively affected).
The way it is implemented right now, after reset() is triggered once,
assert/deassert will return -EINVAL for the lifetime of the reset
control instance. Also, reset() returns -EINVAL between another users'
deassert() and assert() calls.
> As a result, the console will not probe on the Gemini with
> this message:
>
> Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled
> of_serial: probe of 4200.serial failed with error -524
>
> This (-ENOTSUPP) is the error code returned by the
> deassert() operation on self-deasserting reset controllers.
One easy workaround would be to implement deassert() to be a no-op (or
to divert the call to reset()) in your reset controller driver. A more
intrusive variant would be to do the same in the core, as you suggest
below.
> Add some code and comments that will:
>
> - In probe() avoid to bail out if -ENOTSUPP is returned
> from the reset_deassert() call.
I think it would be better not to put this burden on the drivers.
> - If reset_assert() bails out with -ENOTSUPP on remove(),
> try the self-deasserting method as a fallback.
I don't understand the purpose of this, see below.
> Cc: Joel Stanley
> Cc: Philipp Zabel
> Cc: Greg Kroah-Hartman
> Fixes: e2860e1f62f2 ("serial: 8250_of: Add reset support")
> Signed-off-by: Linus Walleij
> ---
> Philipp: please comment on this or ACK if it is the right
> approach. It sort of sets a precedent for handling
> different reset controllers from the consumer side.
>
> Another possibility is to modify the reset core such
> that .deassert() bails out silently if the controller only
> has .reset(), and .assert() just calls .reset() if the
> controller does not have .assert().
>
> Actually I think the latter is more intuitive but it is
> also more intrusive.
I have been thinking about this. Due to the diversity of reset
controller implementations, I'm hesitant to do this in the core.
For starters, why would reset() be called during assert() and not during
deassert()? Can we be sure that this is the right thing for all reset
controllers?
The deassert() call guarantees that the reset line is deasserted after
the call (and as long as deassert_count > 0). What if somebody ends up
building a self-deasserting reset controller that has the reset line
initially asserted?
Also it is implied that after the call to deassert() the device is in a
working state, obviously. This might only be the case after the first
reset() for some devices.
> ---
> drivers/tty/serial/8250/8250_of.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_of.c
> b/drivers/tty/serial/8250/8250_of.c
> index 0cf95fddccfc..927ee8561c8d 100644
> --- a/drivers/tty/serial/8250/8250_of.c
> +++ b/drivers/tty/serial/8250/8250_of.c
> @@ -138,7 +138,12 @@ static int of_platform_serial_setup(struct
> platform_device *ofdev,
> if (IS_ERR(info->rst))
> goto out;
> ret = reset_control_deassert(info->rst);
> - if (ret)
> + /*
> + * If the deassert operation is not supported, this could be because
> + * the reset controller is self-deasserting and onlt supports the
> + * .reset() operation, so this is not a probe error.
> + */
> + if (ret && (ret != -ENOTSUPP))
I don't like to have to do this in the drivers.
The driver just requests the reset line to be deasserted after the call,
if there is one. If the reset controller driver can guarantee that,
deassert() should not return an error.
> goto out;
>
> port->type = type;
> @@ -235,10 +240,14 @@ static int of_platform_serial_probe(struct
> platform_device *ofdev)
> static int of_platform_serial_remove(struct platform_device *ofdev)
> {
> struct of_serial_info *info = platform_get_drvdata(ofdev);
> + int ret;
>
> serial8250_unregister_port(info->line);
>
> - reset_control_assert(info->rst);
> + ret = reset_control_assert(info->rst);
> + /* If the assert operation is not supported, use pure reset() */
> + if (ret == -ENOTSUPP)
> + reset_control_reset(info->rst);
> if (info->clk)
> clk_disable_unprepare(info->clk);
> kfree(info);
What is the purpose of triggering the assert during remove?
I would ex
Re: Potential scheduler regression
* Ben Guthro wrote: > > If people have experience with these in the "enterprise" distros, or any > > other > > tree, and want to provide me with backported, and tested, patches, I'll be > > glad to consider them for stable kernels. > > > > thanks, > > > > greg k-h > > I tried to do a simple cherry-pick of the suggested patches - but they > apply against files that don't exist in the 4.9 series. I think there are only two strategies to maintain a backport which work in the long run: - insist on the simplest fixes and pure cherry-picks - or pick up _everything_ to sync up the two versions. The latter would mean a lot of commits - and I'm afraid it would also involve the scheduler header split-up, which literally involves hundreds of files plus perpetual build-breakage risk, so it's a no-no. > In my release of 4.9 - I'm planning on doing the simpler revert of 1b568f0aab > that introduced the performance degradation, rather than pulling in lots of > code > from newer kernels. That sounds much saner - I'd even Ack that approach for -stable as a special exception, than to complicate things with excessive backports. Thanks, Ingo
Re: [PATCH v2] printk: Modify operators of printed_len and text_len
On Tue 2017-07-11 14:40:55, Pierre Kuo wrote:
> With commit ("printk: report lost messages in printk
> safe/nmi contexts") and commit <8b1742c9c207> ("printk: remove zap_locks()
> function"), it seems we can remove initialization, "=0", of text_len and
> directly assign result of log_output to printed_len.
Just one small thing. The <> brackets should not be there around
the sha1 commit id. Otherwise, the patch looks fine to me.
Acked-by: Petr Mladek
You do not need to resend the patch. I'll remove the brackets
when applying the patch. I'll wait few more days just in case
anyone has more comments on this patch.
Best Regards,
Petr
Re: [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()
On Tue, Jul 11, 2017 at 6:58 AM, Brian Gerst wrote:
> On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky wrote:
>> On 7/8/2017 7:57 AM, Brian Gerst wrote:
>>> On Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky
>>
>> I originally had a check for SME here in a previous version of the
>> patch. Thomas Gleixner recommended removing the check so that the code
>> path was always exercised regardless of the state of SME in order to
>> better detect issues:
>>
>> http://marc.info/?l=linux-kernel&m=149803067811436&w=2
>
> Looking a bit closer, this shortcut doesn't set the caching
> attributes. So it's probably best to get rid of it anyways. Also
> note, there is a corresponding check in iounmap().
Could that cause regressions if a driver relies on (write-through)
cacheable access to the VGA frame buffer RAM or an read-only
cached access to an option ROM but now gets uncached access?
I also tried to find out whether we can stop mapping the ISA MMIO
area into the linear mapping, but at least the VGA code uses
VGA_MAP_MEM() to get access to the same pointers. I'm pretty
sure this got copied incorrectly into most other architectures, but
it is definitely still used on x86 with vga16fb/vgacon/mdacon.
On the plus side, I see that removing this code path will end up
restoring MMIOTRACE support for the ISA MMIO range that was
apparently removed by accident in commit d61fc44853f4
("x86: mmiotrace, preview 2") in linux-2.6.27.
Arnd
Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor
On 11/07/2017 09:51, David Hildenbrand wrote:
>> +static inline bool nested_cpu_has_eptp_switching(struct vmcs12 *vmcs12)
>> +{
>> +return nested_cpu_has_vmfunc(vmcs12) &&
>> +(vmcs12->vm_function_control &
>
> I wonder if it makes sense to rename vm_function_control to
> - vmfunc_control
> - vmfunc_controls (so it matches nested_vmx_vmfunc_controls)
> - vmfunc_ctrl
Blame Intel for this. :) They use full English names for VMCS fields (so
"VM-function control") and uppercase names for MSRs (so "IA32_VMX_VMFUNC").
"nested_vmx_vmfunc_controls" could be renamed to "nested_vmx_vmfunc" for
consistency, but I like the longer name too.
Paolo
Re: [PATCH v2 4/8] objtool: add undwarf debuginfo generation
* Josh Poimboeuf wrote: > Anyway, I used some linker magic to temporarily move the unwinder code to the > end of .text, so that unwinder changes don't add unexpected side effects to > the > microbenchmark behavior. Now I'm getting more consistent results: the packed > struct is measuring ~2% slower. The slight slowdown might just be explained > by > the fact that GCC generates some extra instructions for extracting the fields > out of the packed struct. Yeah, the 16-bit field accesses versus a zero-extended 32-bit field are more complex to access even on x86 that has a fair amount of 16-bit legacy. > In the meantime, I found a ~10% speedup by making the "fast lookup table" > block > size a power-of-two (256) to get rid of the need for a slow 'div' instruction. > > I think I'm done performance tweaking for now. I'll keep the packed struct, > and > add the code for the 'div' removal, and hope to submit v3 soon. Sounds good to me! ~2% slowdown for ~30% RAM savings for a debug data structure that is about as large as a typical kernel's total .text is a decent trade-off. Thanks, Ingo
Re: [PATCH] irqchip: gicv3-its: Use NUMA aware memory allocation for ITS tables
Hi Marc, On Mon, Jul 10, 2017 at 04:15:28PM +0100, Marc Zyngier wrote: > On 10/07/17 15:57, Shanker Donthineni wrote: > > Hi Marc, > > > > On 07/10/2017 08:50 AM, Marc Zyngier wrote: > >> On 10/07/17 11:21, Ganapatrao Kulkarni wrote: > >>> Hi Marc, > >>> > >>> On Mon, Jul 10, 2017 at 2:53 PM, Marc Zyngier > >>> wrote: > On 10/07/17 10:08, Ganapatrao Kulkarni wrote: > > On Mon, Jul 10, 2017 at 2:36 PM, Marc Zyngier > > wrote: > >> On 10/07/17 09:48, Ganapatrao Kulkarni wrote: > >>> Hi Marc, > >>> > >>> On Mon, Jul 3, 2017 at 8:23 PM, Marc Zyngier > >>> wrote: > Hi Shanker, > > On 03/07/17 15:24, Shanker Donthineni wrote: > > Hi Marc, > > > > On 06/30/2017 03:51 AM, Marc Zyngier wrote: > >> On 30/06/17 04:01, Ganapatrao Kulkarni wrote: > >>> On Fri, Jun 30, 2017 at 8:04 AM, Ganapatrao Kulkarni > >>> wrote: > Hi Shanker, > > On Sun, Jun 25, 2017 at 9:16 PM, Shanker Donthineni > wrote: > > The NUMA node information is visible to ITS driver but not > > being used > > other than handling errata. This patch allocates the memory for > > ITS > > tables from the corresponding NUMA node using the appropriate > > NUMA > > aware functions. > >>> > >>> IMHO, the description would have been more constructive? > >>> > >>> "All ITS tables are mapped by default to NODE 0 memory. > >>> Adding changes to allocate memory from respective NUMA NODES of > >>> ITS devices. > >>> This will optimize tables access and avoids unnecessary > >>> inter-node traffic." > >> > >> But more importantly, I'd like to see figures showing the actual > >> benefit > >> of this per-node allocation. Given that both of you guys have > >> access to > >> such platforms, please show me the numbers! > >> > > > > I'll share the actual results which shows the improvement whenever > > available on our next chips. Current version of Qualcomm qdf2400 > > doesn't > > support multi socket configuration to capture results and share > > with you. > > > > Do you see any other issues with this patch apart from the > > performance > > improvements. I strongly believe this brings the noticeable > > improvement > > in numbers on systems where it has multi node memory/CPU > > configuration. > > I agree that it *could* show an improvement, but it very much > depends on > how often the ITS misses in its caches. For this kind of patches, I > want > to see two things: > > 1) It brings a measurable benefit on NUMA platforms > >>> > >>> Did some measurement of interrupt response time for LPIs and we don't > >>> see any major > >>> improvement due to caching of Tables. However, we have seen > >>> improvements of around 5%. > >> > >> An improvement of what exactly? > > > > interrupt response time. > > Measured how? On which HW? Using which benchmark? > >>> > >>> This has been tested on ThunderX2. > >>> We have instrumented gic-v3-its driver code to create dummy LPI device > >>> with few vectors. > >>> The LPI is induced from dummy device(through sysfs by writing to > >>> TRANSLATOR reg). > >>> The ISR routine(gic_handle_irq) being called to handle the induced LPI. > >>> NODE 1 cpu is used to induce LPI and NODE 1 cpu/collection is mapped > >>> in ITT to route this LPI. > >>> > >>> CPU timer counter are sampled at the time LPI is Induced and in ISR > >>> routine to calculate interrupt response time. > >>> the result shown improvement of 5% with this patch. > >> > >> And you call that a realistic measurement of the latency? Really? Sorry, > >> but I cannot take you seriously here. > >> > >>> Do you have any recommended benchmarks to test the same? > >> > >> Run a standard benchmark such as netperf, post the result with and > >> without that patch. The above is just plain ridiculous. > >> > > > > The whole purpose of ACPI subtable "GIC Interrupt Translation Service (ITS) > > Affinity structure" > > is to provide the proximity information to OS so that software will take > > advantage of NUMA > > aware allocations to improve the read latency of ITS/GICR tables, not just > > for implementing > > software workarounds. > > > > > > I believe ITS driver should provide NUMA aware allocations just like x86 > > Linux drivers. How much > > performance improvement we observer is based on the individual SOC > > implementation, inter NODE > > latency, inter node traffic, cache capacity, and type of the test used to > > measure results. > > > > Please consider this patch irrespective
Re: [PATCH] gpu: host1x: Free the IOMMU domain when there is no device to attach
On Mon, 2017-07-10 at 21:33 +0200, Paul Kocialkowski wrote:
> When there is no device to attach to the IOMMU domain, as may be the
> case when the device-tree does not contain the proper iommu node, it
> is
> best to keep going without IOMMU support rather than failing.
> This allows the driver to probe and function instead of taking down
> all of the tegra drm driver, leading to missing display support.
Fixes: 404bfb78daf3 ("gpu: host1x: Add IOMMU support")
> Signed-off-by: Paul Kocialkowski
> ---
> drivers/gpu/host1x/dev.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
> index ac65f52850a6..f296738d0de8 100644
> --- a/drivers/gpu/host1x/dev.c
> +++ b/drivers/gpu/host1x/dev.c
> @@ -186,8 +186,13 @@ static int host1x_probe(struct platform_device
> *pdev)
> return -ENOMEM;
>
> err = iommu_attach_device(host->domain, &pdev->dev);
> - if (err)
> + if (err == -ENODEV) {
> + iommu_domain_free(host->domain);
> + host->domain = NULL;
> + goto iommu_skip;
> + } else if (err) {
> goto fail_free_domain;
> + }
>
> geometry = &host->domain->geometry;
>
> @@ -198,6 +203,7 @@ static int host1x_probe(struct platform_device
> *pdev)
> host->iova_end = geometry->aperture_end;
> }
>
> +iommu_skip:
> err = host1x_channel_list_init(host);
> if (err) {
> dev_err(&pdev->dev, "failed to initialize channel
> list\n");
--
Paul Kocialkowski,
developer of free digital technology and hardware support
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
Re: [PATCH] ARM: tegra: Register host1x node with iommu binding on tegra124
On Sun, 2017-07-09 at 19:36 +0300, Paul Kocialkowski wrote:
> This registers the host1x node with the SMMU (as HC swgroup) to allow
> the host1x code to attach to it. It avoid failing the probe sequence,
> which resulted in the tegra drm driver not probing and thus nothing
> being displayed on-screen.
Fixes: 404bfb78daf3 ("gpu: host1x: Add IOMMU support")
> Signed-off-by: Paul Kocialkowski
> ---
> arch/arm/boot/dts/tegra124.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/tegra124.dtsi
> b/arch/arm/boot/dts/tegra124.dtsi
> index 187a36c6d0fc..b3b89befffeb 100644
> --- a/arch/arm/boot/dts/tegra124.dtsi
> +++ b/arch/arm/boot/dts/tegra124.dtsi
> @@ -85,6 +85,7 @@
> clocks = <&tegra_car TEGRA124_CLK_HOST1X>;
> resets = <&tegra_car 28>;
> reset-names = "host1x";
> + iommus = <&mc TEGRA_SWGROUP_HC>;
>
> #address-cells = <2>;
> #size-cells = <2>;
--
Paul Kocialkowski,
developer of free digital technology and hardware support
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
RE: [PATCH] dpaa_eth: use correct device for DMA mapping API
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Monday, July 10, 2017 6:14 PM
> Subject: [PATCH] dpaa_eth: use correct device for DMA mapping API
>
> Geert Uytterhoeven ran into a build error without CONFIG_HAS_DMA,
> as a result of the driver calling set_dma_ops(). While we can
> fix the build error in the dma-mapping implementation, there is
> another problem in this driver:
>
> The configuration for the DMA is done by the platform code,
> looking up information about the system from the device tree.
> This copies the information only in an incomplete way, setting
> the dma_map_ops and forcing a specific mask, but ignoring all
> settings regarding IOMMU, coherence etc.
>
> A better way to avoid the problem is to only ever pass a device
> into the dma_mapping implementation that has been setup by the
> platform code. In this case, that is the parent device, so we
> can get that pointer at probe time. Fortunately, we already have
> a pointer in the device specific structure for that, so we only
> need to modify that.
>
> Fixes: fb52728a9294 ("dpaa_eth: reuse the dma_ops provided by the FMan MAC
> device")
> Signed-off-by: Arnd Bergmann
> ---
> Not tested, please see if this works before applying!
> ---
> drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 11 ++-
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> index 757b873735a5..f7b0b928cd53 100644
> --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> @@ -2646,14 +2646,6 @@ static int dpaa_eth_probe(struct platform_device
> *pdev)
> priv->buf_layout[RX].priv_data_size = DPAA_RX_PRIV_DATA_SIZE; /* Rx
> */
> priv->buf_layout[TX].priv_data_size = DPAA_TX_PRIV_DATA_SIZE; /* Tx
> */
>
> - /* device used for DMA mapping */
> - set_dma_ops(dev, get_dma_ops(&pdev->dev));
> - err = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(40));
> - if (err) {
> - dev_err(dev, "dma_coerce_mask_and_coherent() failed\n");
> - goto dev_mask_failed;
> - }
> -
> /* bp init */
> for (i = 0; i < DPAA_BPS_NUM; i++) {
> int err;
> @@ -2665,7 +2657,8 @@ static int dpaa_eth_probe(struct platform_device
> *pdev)
> dpaa_bps[i]->raw_size = bpool_buffer_raw_size(i,
> DPAA_BPS_NUM);
> /* avoid runtime computations by keeping the usable size here
> */
> dpaa_bps[i]->size = dpaa_bp_size(dpaa_bps[i]->raw_size);
> - dpaa_bps[i]->dev = dev;
> + /* DMA operations are done on the platform-provided device */
> + dpaa_bps[i]->dev = dev->parent;
>
> err = dpaa_bp_alloc_pool(dpaa_bps[i]);
> if (err < 0) {
> --
> 2.9.0
Hi Arnd,
Thanks for looking into this, I've tested your fix, it seems to need more work:
[0.894968] platform: DMA map failed
[0.898627] platform: DMA map failed
[0.902288] platform: DMA map failed
[0.905947] platform: DMA map failed
[0.909606] platform: DMA map failed
[0.913265] platform: DMA map failed
You also missed this related change:
@@ -2806,7 +2799,6 @@ static int dpaa_eth_probe(struct platform_device *pdev)
dpaa_bps_free(priv);
bp_create_failed:
fq_probe_failed:
-dev_mask_failed:
mac_probe_failed:
dev_set_drvdata(dev, NULL);
free_netdev(net_dev);
I'll try to address your concern about performing the DMA mapping on a different
device than the one set up by the platform code.
Regards,
Madalin
[tip:perf/urgent] perf evsel: Fix attr.exclude_kernel setting for default cycles:p
Commit-ID: d37a369790774af66a4aee61a188384d21b17a43
Gitweb: http://git.kernel.org/tip/d37a369790774af66a4aee61a188384d21b17a43
Author: Arnaldo Carvalho de Melo
AuthorDate: Mon, 10 Jul 2017 16:08:07 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 10 Jul 2017 16:14:48 -0300
perf evsel: Fix attr.exclude_kernel setting for default cycles:p
To allow probing the max attr.precise_ip setting for non-root users
we unconditionally set attr.exclude_kernel, which makes the detection
work but should be done only for !root, fix it.
Cc: Adrian Hunter
Cc: Andy Lutomirski
Cc: David Ahern
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Wang Nan
Fixes: 97365e81366f ("perf evsel: Set attr.exclude_kernel when probing max
attr.precise_ip")
Link: http://lkml.kernel.org/n/tip-bl6bbxzxloonzvm4nvt7o...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/evsel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 87b4318..f2a1876 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -273,7 +273,7 @@ struct perf_evsel *perf_evsel__new_cycles(void)
struct perf_event_attr attr = {
.type = PERF_TYPE_HARDWARE,
.config = PERF_COUNT_HW_CPU_CYCLES,
- .exclude_kernel = 1,
+ .exclude_kernel = geteuid() != 0,
};
struct perf_evsel *evsel;
[tip:perf/urgent] perf evsel: State in the default event name if attr.exclude_kernel is set
Commit-ID: ede5626d303b721dd02246a3850380943c24e380 Gitweb: http://git.kernel.org/tip/ede5626d303b721dd02246a3850380943c24e380 Author: Arnaldo Carvalho de Melo AuthorDate: Mon, 10 Jul 2017 16:19:25 -0300 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 10 Jul 2017 16:19:25 -0300 perf evsel: State in the default event name if attr.exclude_kernel is set When no event is specified perf will use the "cycles" hardware event with the highest precision available in the processor, and excluding kernel events for non-root users, so make that clear in the event name by setting the "u" event modifier, i.e. "cycles:upp". E.g.: The default for root: # perf record usleep 1 # perf evlist -v cycles:ppp: ..., precise_ip: 3, exclude_kernel: 0, ... # And for !root: $ perf record usleep 1 $ perf evlist -v cycles:uppp: ... , precise_ip: 3, exclude_kernel: 1, ... $ Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link: http://lkml.kernel.org/n/tip-lf29zcdl422i9knrgde0u...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/evsel.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c index f2a1876..413f74d 100644 --- a/tools/perf/util/evsel.c +++ b/tools/perf/util/evsel.c @@ -298,8 +298,10 @@ struct perf_evsel *perf_evsel__new_cycles(void) goto out; /* use asprintf() because free(evsel) assumes name is allocated */ - if (asprintf(&evsel->name, "cycles%.*s", -attr.precise_ip ? attr.precise_ip + 1 : 0, ":ppp") < 0) + if (asprintf(&evsel->name, "cycles%s%s%.*s", +(attr.precise_ip || attr.exclude_kernel) ? ":" : "", +attr.exclude_kernel ? "u" : "", +attr.precise_ip ? attr.precise_ip + 1 : 0, "ppp") < 0) goto error_free; out: return evsel;
[tip:perf/urgent] perf annotate: Fix broken arrow at row 0 connecting jmp instruction to its target
Commit-ID: 80f62589fa52f530cffc50e78c0b5a2ae572d61e
Gitweb: http://git.kernel.org/tip/80f62589fa52f530cffc50e78c0b5a2ae572d61e
Author: Jin Yao
AuthorDate: Thu, 8 Jun 2017 14:01:44 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 10 Jul 2017 16:36:40 -0300
perf annotate: Fix broken arrow at row 0 connecting jmp instruction to its
target
When the jump instruction is displayed at the row 0 in annotate view,
the arrow is broken. An example:
16.86 │ ┌──je 82
0.01 │ movsd (%rsp),%xmm0
│ movsd 0x8(%rsp),%xmm4
│ movsd 0x8(%rsp),%xmm1
│ movsd (%rsp),%xmm3
│ divsd %xmm4,%xmm0
│ divsd %xmm3,%xmm1
│ movsd (%rsp),%xmm2
│ addsd %xmm1,%xmm0
│ addsd %xmm2,%xmm0
│ movsd %xmm0,(%rsp)
│82: sub$0x1,%ebx
83.03 │↑ jne38
│ add$0x10,%rsp
│ xor%eax,%eax
│ pop%rbx
│← retq
The patch increments the row number before checking with 0.
Signed-off-by: Yao Jin
Tested-by: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: Jiri Olsa
Cc: Kan Liang
Cc: Peter Zijlstra
Cc: sta...@vger.kernel.org
Fixes: 944e1abed9e1 ("perf ui browser: Add method to draw up/down arrow line")
Link:
http://lkml.kernel.org/r/1496901704-30275-1-git-send-email-yao@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/browser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/ui/browser.c b/tools/perf/ui/browser.c
index a4d3762..83874b0 100644
--- a/tools/perf/ui/browser.c
+++ b/tools/perf/ui/browser.c
@@ -704,7 +704,7 @@ static void __ui_browser__line_arrow_down(struct ui_browser
*browser,
ui_browser__gotorc(browser, row, column + 1);
SLsmg_draw_hline(2);
- if (row++ == 0)
+ if (++row == 0)
goto out;
} else
row = 0;
Re: [PATCH CFT 0/4] VT-d PI fixes
On 07/06/2017 11:33, Gonglei (Arei) wrote: > We are testing your patch, but maybe need some time to report > the results because it's not an inevitable problem. > > Meanwhile we also try to find a possible scenario of non-hotplugging to > explain the double-add warnings. Hi Lei, do you have any updates? I would like to get at least the first three patches in 4.13. Thanks, Paolo
[PATCH 00/13]mpt3sas driver NVMe support:
Ventura Series controller are Tri-mode. The controller and firmware are capable of supporting NVMe devices and PCIe switches to be connected with the controller. This patch set adds driver level support for NVMe devices and PCIe switches. Suganath Prabu S (13): mpt3sas: Add nvme device support in slave alloc, target alloc and probe mpt3sas: SGL to PRP Translation for I/Os to NVMe devices mpt3sas: Added support for nvme encapsulated request message. mpt3sas: Handle NVMe PCIe device related events generated from firmware. mpt3sas: Set NVMe device queue depth as 128 mpt3sas: API 's to support NVMe drive addition to SML mpt3sas: API's to remove nvme drive from sml mpt3sas: scan and add nvme device after controller reset mpt3as: Add-Task-management-debug-info-for-NVMe-drives. mpt3sas: NVMe drive support for BTDHMAPPING ioctl command and log info mpt3sas: Fix nvme drives checking for tlr. mpt3sas: Update MPI Header mpt3sas: Update mpt3sas driver version. drivers/scsi/mpt3sas/mpi/mpi2.h | 43 +- drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h | 647 ++- drivers/scsi/mpt3sas/mpi/mpi2_init.h | 11 +- drivers/scsi/mpt3sas/mpi/mpi2_ioc.h | 331 ++- drivers/scsi/mpt3sas/mpi/mpi2_pci.h | 142 +++ drivers/scsi/mpt3sas/mpi/mpi2_tool.h | 14 +- drivers/scsi/mpt3sas/mpt3sas_base.c | 709 +++- drivers/scsi/mpt3sas/mpt3sas_base.h | 176 +++- drivers/scsi/mpt3sas/mpt3sas_config.c| 100 ++ drivers/scsi/mpt3sas/mpt3sas_ctl.c | 170 +++- drivers/scsi/mpt3sas/mpt3sas_scsih.c | 1871 -- drivers/scsi/mpt3sas/mpt3sas_warpdrive.c |2 +- 12 files changed, 4081 insertions(+), 135 deletions(-) create mode 100644 drivers/scsi/mpt3sas/mpi/mpi2_pci.h Thanks, Suganath Prabu S
[PATCH 02/13] mpt3sas: SGL to PRP Translation for I/Os to NVMe devices
* Added support for translating the SGLs associated with incoming
commands either to IEE SGL or NVMe PRPs for NVMe devices.
* The hardware translation of IEEE SGL to NVMe PRPs has limitation
and if a command cannot be translated by hardware then it will go
to firmware and the firmware needs to translate it. And this will
have a performance reduction. To avoid that driver proactively
checks whether the translation will be done in hardware or not,
if not then driver try to translate inside the driver.
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 623 +-
drivers/scsi/mpt3sas/mpt3sas_base.h | 43 +++-
drivers/scsi/mpt3sas/mpt3sas_ctl.c |1 +
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 12 +-
4 files changed, 666 insertions(+), 13 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 18039bb..b67212c 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -59,6 +59,7 @@
#include
#include
#include
+#include /* To get host page size per arch */
#include
@@ -1347,6 +1348,502 @@ _base_build_sg(struct MPT3SAS_ADAPTER *ioc, void *psge,
/* IEEE format sgls */
/**
+ * _base_build_nvme_prp - This function is called for NVMe end devices to build
+ * a native SGL (NVMe PRP). The native SGL is built starting in the first PRP
+ * entry of the NVMe message (PRP1). If the data buffer is small enough to be
+ * described entirely using PRP1, then PRP2 is not used. If needed, PRP2 is
+ * used to describe a larger data buffer. If the data buffer is too large to
+ * describe using the two PRP entriess inside the NVMe message, then PRP1
+ * describes the first data memory segment, and PRP2 contains a pointer to a
PRP
+ * list located elsewhere in memory to describe the remaining data memory
+ * segments. The PRP list will be contiguous.
+
+ * The native SGL for NVMe devices is a Physical Region Page (PRP). A PRP
+ * consists of a list of PRP entries to describe a number of noncontigous
+ * physical memory segments as a single memory buffer, just as a SGL does.
Note
+ * however, that this function is only used by the IOCTL call, so the memory
+ * given will be guaranteed to be contiguous. There is no need to translate
+ * non-contiguous SGL into a PRP in this case. All PRPs will describe
+ * contiguous space that is one page size each.
+ *
+ * Each NVMe message contains two PRP entries. The first (PRP1) either
contains
+ * a PRP list pointer or a PRP element, depending upon the command. PRP2
+ * contains the second PRP element if the memory being described fits within 2
+ * PRP entries, or a PRP list pointer if the PRP spans more than two entries.
+ *
+ * A PRP list pointer contains the address of a PRP list, structured as a
linear
+ * array of PRP entries. Each PRP entry in this list describes a segment of
+ * physical memory.
+ *
+ * Each 64-bit PRP entry comprises an address and an offset field. The address
+ * always points at the beginning of a 4KB physical memory page, and the offset
+ * describes where within that 4KB page the memory segment begins. Only the
+ * first element in a PRP list may contain a non-zero offest, implying that all
+ * memory segments following the first begin at the start of a 4KB page.
+ *
+ * Each PRP element normally describes 4KB of physical memory, with exceptions
+ * for the first and last elements in the list. If the memory being described
+ * by the list begins at a non-zero offset within the first 4KB page, then the
+ * first PRP element will contain a non-zero offset indicating where the region
+ * begins within the 4KB page. The last memory segment may end before the end
+ * of the 4KB segment, depending upon the overall size of the memory being
+ * described by the PRP list.
+ *
+ * Since PRP entries lack any indication of size, the overall data buffer
length
+ * is used to determine where the end of the data memory buffer is located, and
+ * how many PRP entries are required to describe it.
+ *
+ * @ioc: per adapter object
+ * @smid: system request message index for getting asscociated SGL
+ * @nvme_encap_request: the NVMe request msg frame pointer
+ * @data_out_dma: physical address for WRITES
+ * @data_out_sz: data xfer size for WRITES
+ * @data_in_dma: physical address for READS
+ * @data_in_sz: data xfer size for READS
+ *
+ * Returns nothing.
+ */
+static void
+_base_build_nvme_prp(struct MPT3SAS_ADAPTER *ioc, u16 smid,
+ Mpi26NVMeEncapsulatedRequest_t *nvme_encap_request,
+ dma_addr_t data_out_dma, size_t data_out_sz, dma_addr_t data_in_dma,
+ size_t data_in_sz)
+{
+ int prp_size = NVME_PRP_SIZE;
+ u64 *prp_entry, *prp1_entry, *prp2_entry, *prp_entry_phys;
+ u64 *prp_page, *prp_page_phys;
+ u32 offset, entry_len;
+ u32 page_mask_result, page_mas
[PATCH 04/13] mpt3sas: Handle NVMe PCIe device related events generated from firmware.
* The controller firmware sends separate events for NVMe devices and
PCIe switches similar to existing SAS events.
* NVMe device detection, addition and removal are reported by the
firmware through PCIe Topology Change list events.
* The PCIe device state change events are sent when the firmware
detects any abnormal conditions with a NVMe device or switch.
* The enumeration event are sent when the firmware starts PCIe device
enumeration and stops.
* This patch has the code change to handle the events and add/remove
NVMe devices in driver's inventory.
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 30 ++-
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 468 +-
2 files changed, 492 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index a64cfce..09fecd0 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -663,6 +663,26 @@ _base_display_event_data(struct MPT3SAS_ADAPTER *ioc,
case MPI2_EVENT_ACTIVE_CABLE_EXCEPTION:
desc = "Active cable exception";
break;
+ case MPI2_EVENT_PCIE_DEVICE_STATUS_CHANGE:
+ desc = "PCIE Device Status Change";
+ break;
+ case MPI2_EVENT_PCIE_ENUMERATION:
+ {
+ Mpi26EventDataPCIeEnumeration_t *event_data =
+ (Mpi26EventDataPCIeEnumeration_t *)mpi_reply->EventData;
+ pr_info(MPT3SAS_FMT "PCIE Enumeration: (%s)", ioc->name,
+ (event_data->ReasonCode ==
+ MPI26_EVENT_PCIE_ENUM_RC_STARTED) ?
+ "start" : "stop");
+ if (event_data->EnumerationStatus)
+ pr_info("enumeration_status(0x%08x)",
+ le32_to_cpu(event_data->EnumerationStatus));
+ pr_info("\n");
+ return;
+ }
+ case MPI2_EVENT_PCIE_TOPOLOGY_CHANGE_LIST:
+ desc = "PCIE Topology Change List";
+ break;
}
if (!desc)
@@ -6187,8 +6207,16 @@ mpt3sas_base_attach(struct MPT3SAS_ADAPTER *ioc)
_base_unmask_events(ioc, MPI2_EVENT_IR_OPERATION_STATUS);
_base_unmask_events(ioc, MPI2_EVENT_LOG_ENTRY_ADDED);
_base_unmask_events(ioc, MPI2_EVENT_TEMP_THRESHOLD);
- if (ioc->hba_mpi_version_belonged == MPI26_VERSION)
+ if (ioc->hba_mpi_version_belonged == MPI26_VERSION) {
_base_unmask_events(ioc, MPI2_EVENT_ACTIVE_CABLE_EXCEPTION);
+ if (ioc->is_gen35_ioc) {
+ _base_unmask_events(ioc,
+ MPI2_EVENT_PCIE_DEVICE_STATUS_CHANGE);
+ _base_unmask_events(ioc, MPI2_EVENT_PCIE_ENUMERATION);
+ _base_unmask_events(ioc,
+ MPI2_EVENT_PCIE_TOPOLOGY_CHANGE_LIST);
+ }
+ }
r = _base_make_ioc_operational(ioc);
if (r)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 45b8d94..2a6a8e6 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -3132,8 +3132,6 @@ _scsih_block_io_device(struct MPT3SAS_ADAPTER *ioc, u16
handle)
struct _sas_device *sas_device;
sas_device = mpt3sas_get_sdev_by_handle(ioc, handle);
- if (!sas_device)
- return;
shost_for_each_device(sdev, ioc->shost) {
sas_device_priv_data = sdev->hostdata;
@@ -3143,7 +3141,7 @@ _scsih_block_io_device(struct MPT3SAS_ADAPTER *ioc, u16
handle)
continue;
if (sas_device_priv_data->block)
continue;
- if (sas_device->pend_sas_rphy_add)
+ if (sas_device && sas_device->pend_sas_rphy_add)
continue;
if (sas_device_priv_data->ignore_delay_remove) {
sdev_printk(KERN_INFO, sdev,
@@ -3154,7 +3152,8 @@ _scsih_block_io_device(struct MPT3SAS_ADAPTER *ioc, u16
handle)
_scsih_internal_device_block(sdev, sas_device_priv_data);
}
- sas_device_put(sas_device);
+ if (sas_device)
+ sas_device_put(sas_device);
}
/**
@@ -3238,6 +3237,33 @@ _scsih_block_io_to_children_attached_directly(struct
MPT3SAS_ADAPTER *ioc,
}
/**
+ * _scsih_block_io_to_pcie_children_attached_directly
+ * @ioc: per adapter object
+ * @event_data: topology change event data
+ *
+ * This routine set sdev state to SDEV_BLOCK for all devices
+ * direct attached during device pull/reconnect.
+ */
+static void
+_scsih_block_io_to_pcie_children_attached_directly(struct MPT3SAS_ADAPTER *ioc,
+ Mpi26EventDataPCIeTopologyChangeList_t *event_data)
+{
+ int i;
+ u16 handle;
+ u16 reason_code;
+
+
[PATCH 03/13] mpt3sas: Added support for nvme encapsulated request message.
* Mpt3sas driver uses the NVMe Encapsulated Request message to
send an NVMe command to an NVMe device attached to the IOC.
* Normal I/O commands like reads and writes are passed to the
controller as SCSI commands and the controller has the ability
to translate the commands to NVMe equivalent.
* This encapsulated NVMe command is used by applications to send
direct NVMe commands to NVMe drives or for handling unmap where
the translation at controller/firmware level is having
performance issues.
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 56 +++-
drivers/scsi/mpt3sas/mpt3sas_base.h |1 +
drivers/scsi/mpt3sas/mpt3sas_ctl.c | 81 ++-
3 files changed, 136 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index b67212c..a64cfce 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -557,6 +557,11 @@ _base_sas_ioc_info(struct MPT3SAS_ADAPTER *ioc,
MPI2DefaultReply_t *mpi_reply,
frame_sz = sizeof(Mpi2SmpPassthroughRequest_t) + ioc->sge_size;
func_str = "smp_passthru";
break;
+ case MPI2_FUNCTION_NVME_ENCAPSULATED:
+ frame_sz = sizeof(Mpi26NVMeEncapsulatedRequest_t) +
+ ioc->sge_size;
+ func_str = "nvme_encapsulated";
+ break;
default:
frame_sz = 32;
func_str = "unknown";
@@ -985,7 +990,9 @@ _base_interrupt(int irq, void *bus_id)
if (request_desript_type ==
MPI25_RPY_DESCRIPT_FLAGS_FAST_PATH_SCSI_IO_SUCCESS ||
request_desript_type ==
- MPI2_RPY_DESCRIPT_FLAGS_SCSI_IO_SUCCESS) {
+ MPI2_RPY_DESCRIPT_FLAGS_SCSI_IO_SUCCESS ||
+ request_desript_type ==
+ MPI26_RPY_DESCRIPT_FLAGS_PCIE_ENCAPSULATED_SUCCESS) {
cb_idx = _base_get_cb_idx(ioc, smid);
if ((likely(cb_idx < MPT_MAX_CALLBACKS)) &&
(likely(mpt_callbacks[cb_idx] != NULL))) {
@@ -3079,6 +3086,30 @@ _base_put_smid_hi_priority(struct MPT3SAS_ADAPTER *ioc,
u16 smid,
}
/**
+ * _base_put_smid_nvme_encap - send NVMe encapsulated request to
+ * firmware
+ * @ioc: per adapter object
+ * @smid: system request message index
+ *
+ * Return nothing.
+ */
+static void
+_base_put_smid_nvme_encap(struct MPT3SAS_ADAPTER *ioc, u16 smid)
+{
+ Mpi2RequestDescriptorUnion_t descriptor;
+ u64 *request = (u64 *)&descriptor;
+
+ descriptor.Default.RequestFlags =
+ MPI26_REQ_DESCRIPT_FLAGS_PCIE_ENCAPSULATED;
+ descriptor.Default.MSIxIndex = _base_get_msix_index(ioc);
+ descriptor.Default.SMID = cpu_to_le16(smid);
+ descriptor.Default.LMID = 0;
+ descriptor.Default.DescriptorTypeDependent = 0;
+ _base_writeq(*request, &ioc->chip->RequestDescriptorPostLow,
+ &ioc->scsi_lookup_lock);
+}
+
+/**
* _base_put_smid_default - Default, primarily used for config pages
* @ioc: per adapter object
* @smid: system request message index
@@ -3169,6 +3200,27 @@ _base_put_smid_hi_priority_atomic(struct MPT3SAS_ADAPTER
*ioc, u16 smid,
}
/**
+ * _base_put_smid_nvme_encap_atomic - send NVMe encapsulated request to
+ * firmware using Atomic Request Descriptor
+ * @ioc: per adapter object
+ * @smid: system request message index
+ *
+ * Return nothing.
+ */
+static void
+_base_put_smid_nvme_encap_atomic(struct MPT3SAS_ADAPTER *ioc, u16 smid)
+{
+ Mpi26AtomicRequestDescriptor_t descriptor;
+ u32 *request = (u32 *)&descriptor;
+
+ descriptor.RequestFlags = MPI26_REQ_DESCRIPT_FLAGS_PCIE_ENCAPSULATED;
+ descriptor.MSIxIndex = _base_get_msix_index(ioc);
+ descriptor.SMID = cpu_to_le16(smid);
+
+ writel(cpu_to_le32(*request), &ioc->chip->AtomicRequestDescriptorPost);
+}
+
+/**
* _base_put_smid_default - Default, primarily used for config pages
* use Atomic Request Descriptor
* @ioc: per adapter object
@@ -6001,11 +6053,13 @@ mpt3sas_base_attach(struct MPT3SAS_ADAPTER *ioc)
ioc->put_smid_scsi_io = &_base_put_smid_scsi_io_atomic;
ioc->put_smid_fast_path = &_base_put_smid_fast_path_atomic;
ioc->put_smid_hi_priority = &_base_put_smid_hi_priority_atomic;
+ ioc->put_smid_nvme_encap = &_base_put_smid_nvme_encap_atomic;
} else {
ioc->put_smid_default = &_base_put_smid_default;
ioc->put_smid_scsi_io = &_base_put_smid_scsi_io;
ioc->put_smid_fast_path = &_base_put_smid_fast_path;
ioc->put_smid_hi_priority = &_base_put_smid_hi_priority;
+ ioc->put_smid_nvme_encap = &_base_put_smid_nvme_encap;
}
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sa
[PATCH 06/13] mpt3sas: API 's to support NVMe drive addition to SML
Below Functions are added in various paths to support NVMe
drive addition.
_scsih_pcie_add_device
_scsih_pcie_device_add
_scsih_pcie_device_init_add
_scsih_check_pcie_access_status
_scsih_pcie_check_device
mpt3sas_get_pdev_by_wwid
mpt3sas_get_pdev_by_idchannel
mpt3sas_get_pdev_by_handle
mpt3sas_config_get_pcie_device_pg0
mpt3sas_config_get_pcie_device_pg2
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
---
drivers/scsi/mpt3sas/mpt3sas_base.h | 53 +++
drivers/scsi/mpt3sas/mpt3sas_config.c | 100 ++
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 568 -
3 files changed, 714 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 0f07b16..063977a 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -563,6 +563,49 @@ struct _pcie_device {
u8 *serial_number;
struct kref refcount;
};
+
+/**
+ * pcie_device_get - Increment the pcie device reference count
+ *
+ * @p: pcie_device object
+ *
+ * When ever this function called it will increment the
+ * reference count of the pcie device for which this function called.
+ *
+ */
+static inline void pcie_device_get(struct _pcie_device *p)
+{
+ kref_get(&p->refcount);
+}
+
+/**
+ * pcie_device_free - Release the pcie device object
+ * @r - kref object
+ *
+ * Free's the pcie device object. It will be called when reference count
+ * reaches to zero.
+ */
+static inline void pcie_device_free(struct kref *r)
+{
+ kfree(container_of(r, struct _pcie_device, refcount));
+}
+
+/**
+ * pcie_device_put - Decrement the pcie device reference count
+ *
+ * @p: pcie_device object
+ *
+ * When ever this function called it will decrement the
+ * reference count of the pcie device for which this function called.
+ *
+ * When refernce count reaches to Zero, this will call pcie_device_free to the
+ * pcie_device object.
+ */
+static inline void pcie_device_put(struct _pcie_device *p)
+{
+ kref_put(&p->refcount, pcie_device_free);
+}
+
/**
* struct _raid_device - raid volume link list
* @list: sas device list
@@ -1417,6 +1460,10 @@ struct _sas_device *mpt3sas_get_sdev_by_addr(
struct MPT3SAS_ADAPTER *ioc, u64 sas_address);
struct _sas_device *__mpt3sas_get_sdev_by_addr(
struct MPT3SAS_ADAPTER *ioc, u64 sas_address);
+struct _sas_device *mpt3sas_get_sdev_by_handle(struct MPT3SAS_ADAPTER *ioc,
+ u16 handle);
+struct _pcie_device *mpt3sas_get_pdev_by_handle(struct MPT3SAS_ADAPTER *ioc,
+ u16 handle);
void mpt3sas_port_enable_complete(struct MPT3SAS_ADAPTER *ioc);
struct _raid_device *
@@ -1455,6 +1502,12 @@ int mpt3sas_config_get_sas_device_pg0(struct
MPT3SAS_ADAPTER *ioc,
int mpt3sas_config_get_sas_device_pg1(struct MPT3SAS_ADAPTER *ioc,
Mpi2ConfigReply_t *mpi_reply, Mpi2SasDevicePage1_t *config_page,
u32 form, u32 handle);
+int mpt3sas_config_get_pcie_device_pg0(struct MPT3SAS_ADAPTER *ioc,
+ Mpi2ConfigReply_t *mpi_reply, Mpi26PCIeDevicePage0_t *config_page,
+ u32 form, u32 handle);
+int mpt3sas_config_get_pcie_device_pg2(struct MPT3SAS_ADAPTER *ioc,
+ Mpi2ConfigReply_t *mpi_reply, Mpi26PCIeDevicePage2_t *config_page,
+ u32 form, u32 handle);
int mpt3sas_config_get_sas_iounit_pg0(struct MPT3SAS_ADAPTER *ioc,
Mpi2ConfigReply_t *mpi_reply, Mpi2SasIOUnitPage0_t *config_page,
u16 sz);
diff --git a/drivers/scsi/mpt3sas/mpt3sas_config.c
b/drivers/scsi/mpt3sas/mpt3sas_config.c
index dd62701..1c747cf 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_config.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_config.c
@@ -150,6 +150,24 @@ _config_display_some_debug(struct MPT3SAS_ADAPTER *ioc,
u16 smid,
case MPI2_CONFIG_EXTPAGETYPE_DRIVER_MAPPING:
desc = "driver_mapping";
break;
+ case MPI2_CONFIG_EXTPAGETYPE_SAS_PORT:
+ desc = "sas_port";
+ break;
+ case MPI2_CONFIG_EXTPAGETYPE_EXT_MANUFACTURING:
+ desc = "ext_manufacturing";
+ break;
+ case MPI2_CONFIG_EXTPAGETYPE_PCIE_IO_UNIT:
+ desc = "pcie_io_unit";
+ break;
+ case MPI2_CONFIG_EXTPAGETYPE_PCIE_SWITCH:
+ desc = "pcie_switch";
+ break;
+ case MPI2_CONFIG_EXTPAGETYPE_PCIE_DEVICE:
+ desc = "pcie_device";
+ break;
+ case MPI2_CONFIG_EXTPAGETYPE_PCIE_LINK:
+ desc = "pcie_link";
+ break;
}
break;
}
@@ -1053,6 +1071,88 @@ mpt3sas_config_get_sas_device_pg1(struct MPT3SAS_ADAPTER
*ioc,
}
/**
+ * mpt3sas_config_get_pcie_device_pg0 - obtain pcie device page 0
+ * @ioc: per adapter object
+ * @mpi_reply: reply mf payload returned from
[PATCH 01/13] mpt3sas: Add nvme device support in slave alloc, target alloc and probe
1) Added support for probing pcie device and adding NVMe drives to
SML and driver's internal list pcie_device_list.
2) Added support for determing NVMe as boot device.
3) Added nvme device support for call back functions scan_finished
target_alloc,slave_alloc,target destroy and slave destroy.
a) During scan, pcie devices are probed and added to SML to drivers
internal list.
b) target_alloc & slave alloc API's allocates resources for
(MPT3SAS_TARGET & MPT3SAS_DEVICE) private datas and holds
information like handle, target_id etc.
c) slave_destroy & target_destroy are called when driver unregisters
or removes device. Also frees allocated resources and info.
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
---
drivers/scsi/mpt3sas/mpt3sas_base.h | 68 +++-
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 291 ++
2 files changed, 325 insertions(+), 34 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 099ab4c..60fa7b6 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -357,7 +357,8 @@ struct Mpi2ManufacturingPage11_t {
* @flags: MPT_TARGET_FLAGS_XXX flags
* @deleted: target flaged for deletion
* @tm_busy: target is busy with TM request.
- * @sdev: The sas_device associated with this target
+ * @sas_dev: The sas_device associated with this target
+ * @pcie_dev: The pcie device associated with this target
*/
struct MPT3SAS_TARGET {
struct scsi_target *starget;
@@ -368,7 +369,8 @@ struct MPT3SAS_TARGET {
u32 flags;
u8 deleted;
u8 tm_busy;
- struct _sas_device *sdev;
+ struct _sas_device *sas_dev;
+ struct _pcie_device *pcie_dev;
};
@@ -508,6 +510,48 @@ static inline void sas_device_put(struct _sas_device *s)
kref_put(&s->refcount, sas_device_free);
}
+/*
+ * struct _pcie_device - attached PCIe device information
+ * @list: pcie device list
+ * @starget: starget object
+ * @wwid: device WWID
+ * @handle: device handle
+ * @device_info: bitfield provides detailed info about the device
+ * @id: target id
+ * @channel: target channel
+ * @slot: slot number
+ * @port_num: port number
+ * @responding: used in _scsih_pcie_device_mark_responding
+ * @fast_path: fast path feature enable bit
+ * @nvme_mdts: MaximumDataTransferSize from PCIe Device Page 2 for
+ * NVMe device only
+ * @enclosure_handle: enclosure handle
+ * @enclosure_logical_id: enclosure logical identifier
+ * @enclosure_level: The level of device's enclosure from the controller
+ * @connector_name: ASCII value of the Connector's name
+ * @serial_number: pointer of serial number string allocated runtime
+ * @refcount: reference count for deletion
+ */
+struct _pcie_device {
+ struct list_head list;
+ struct scsi_target *starget;
+ u64 wwid;
+ u16 handle;
+ u32 device_info;
+ int id;
+ int channel;
+ u16 slot;
+ u8 port_num;
+ u8 responding;
+ u8 fast_path;
+ u32 nvme_mdts;
+ u16 enclosure_handle;
+ u64 enclosure_logical_id;
+ u8 enclosure_level;
+ u8 connector_name[4];
+ u8 *serial_number;
+ struct kref refcount;
+};
/**
* struct _raid_device - raid volume link list
* @list: sas device list
@@ -556,12 +600,13 @@ struct _raid_device {
/**
* struct _boot_device - boot device info
- * @is_raid: flag to indicate whether this is volume
- * @device: holds pointer for either struct _sas_device or
- * struct _raid_device
+ *
+ * @channel: sas, raid, or pcie channel
+ * @device: holds pointer for struct _sas_device, struct _raid_device or
+ * struct _pcie_device
*/
struct _boot_device {
- u8 is_raid;
+ int channel;
void *device;
};
@@ -825,6 +870,8 @@ typedef void (*MPT3SAS_FLUSH_RUNNING_CMDS)(struct
MPT3SAS_ADAPTER *ioc);
* @bars: bitmask of BAR's that must be configured
* @mask_interrupts: ignore interrupt
* @dma_mask: used to set the consistent dma mask
+ * @pci_access_mutex: Mutex to synchronize ioctl,sysfs show path and
+ * pci resource handling
* @fault_reset_work_q_name: fw fault work queue
* @fault_reset_work_q: ""
* @fault_reset_work: ""
@@ -888,9 +935,13 @@ typedef void (*MPT3SAS_FLUSH_RUNNING_CMDS)(struct
MPT3SAS_ADAPTER *ioc);
* @sas_device_list: sas device object list
* @sas_device_init_list: sas device object list (used only at init time)
* @sas_device_lock:
+ * @pcie_device_list: pcie device object list
+ * @pcie_device_init_list: pcie device object list (used only at init time)
+ * @pcie_device_lock:
* @io_missing_delay: time for IO completed by fw when PDR enabled
* @device_missing_delay: time for device missing by fw when PDR enabled
* @sas_id : used for setting volume target IDs
+ * @pcie_target_id: used for setting pcie target IDs
* @bl
[PATCH 09/13] mpt3as: Add-Task-management-debug-info-for-NVMe-drives.
Added debug information for NVMe/PCIe drives in target rest path.
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
---
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 86 --
1 files changed, 72 insertions(+), 14 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 7100ee8..b96da33 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -690,7 +690,7 @@ found_device:
* This searches for sas_device based on sas_address, then return sas_device
* object.
*/
-static struct _sas_device *
+struct _sas_device *
mpt3sas_get_sdev_by_handle(struct MPT3SAS_ADAPTER *ioc, u16 handle)
{
struct _sas_device *sas_device;
@@ -1208,6 +1208,7 @@ _scsih_pcie_device_init_add(struct MPT3SAS_ADAPTER *ioc,
_scsih_determine_boot_device(ioc, pcie_device, PCIE_CHANNEL);
spin_unlock_irqrestore(&ioc->pcie_device_lock, flags);
}
+
/**
* _scsih_raid_device_find_by_id - raid device search
* @ioc: per adapter object
@@ -2891,6 +2892,7 @@ _scsih_tm_display_info(struct MPT3SAS_ADAPTER *ioc,
struct scsi_cmnd *scmd)
struct scsi_target *starget = scmd->device->sdev_target;
struct MPT3SAS_TARGET *priv_target = starget->hostdata;
struct _sas_device *sas_device = NULL;
+ struct _pcie_device *pcie_device = NULL;
unsigned long flags;
char *device_str = NULL;
@@ -2907,6 +2909,31 @@ _scsih_tm_display_info(struct MPT3SAS_ADAPTER *ioc,
struct scsi_cmnd *scmd)
"%s handle(0x%04x), %s wwid(0x%016llx)\n",
device_str, priv_target->handle,
device_str, (unsigned long long)priv_target->sas_address);
+
+ } else if (priv_target->flags & MPT_TARGET_FLAGS_PCIE_DEVICE) {
+ spin_lock_irqsave(&ioc->pcie_device_lock, flags);
+ pcie_device = __mpt3sas_get_pdev_from_target(ioc, priv_target);
+ if (pcie_device) {
+ starget_printk(KERN_INFO, starget,
+ "handle(0x%04x), wwid(0x%016llx), port(%d)\n",
+ pcie_device->handle,
+ (unsigned long long)pcie_device->wwid,
+ pcie_device->port_num);
+ if (pcie_device->enclosure_handle != 0)
+ starget_printk(KERN_INFO, starget,
+ "enclosure logical id(0x%016llx),
slot(%d)\n",
+ (unsigned long long)
+ pcie_device->enclosure_logical_id,
+ pcie_device->slot);
+ if (pcie_device->connector_name[0] != '\0')
+ starget_printk(KERN_INFO, starget,
+ "enclosure level(0x%04x), connector
name( %s)\n",
+ pcie_device->enclosure_level,
+ pcie_device->connector_name);
+ pcie_device_put(pcie_device);
+ }
+ spin_unlock_irqrestore(&ioc->pcie_device_lock, flags);
+
} else {
spin_lock_irqsave(&ioc->sas_device_lock, flags);
sas_device = __mpt3sas_get_sdev_from_target(ioc, priv_target);
@@ -3650,6 +3677,7 @@ _scsih_tm_tr_send(struct MPT3SAS_ADAPTER *ioc, u16 handle)
Mpi2SCSITaskManagementRequest_t *mpi_request;
u16 smid;
struct _sas_device *sas_device = NULL;
+ struct _pcie_device *pcie_device = NULL;
struct MPT3SAS_TARGET *sas_target_priv_data = NULL;
u64 sas_address = 0;
unsigned long flags;
@@ -3692,24 +3720,52 @@ _scsih_tm_tr_send(struct MPT3SAS_ADAPTER *ioc, u16
handle)
sas_address = sas_device->sas_address;
}
spin_unlock_irqrestore(&ioc->sas_device_lock, flags);
-
+ if (!sas_device) {
+ spin_lock_irqsave(&ioc->pcie_device_lock, flags);
+ pcie_device = __mpt3sas_get_pdev_by_handle(ioc, handle);
+ if (pcie_device && pcie_device->starget &&
+ pcie_device->starget->hostdata) {
+ sas_target_priv_data = pcie_device->starget->hostdata;
+ sas_target_priv_data->deleted = 1;
+ sas_address = pcie_device->wwid;
+ }
+ spin_unlock_irqrestore(&ioc->pcie_device_lock, flags);
+ }
if (sas_target_priv_data) {
dewtprintk(ioc, pr_info(MPT3SAS_FMT
"setting delete flag: handle(0x%04x),
sas_addr(0x%016llx)\n",
ioc->name, handle,
(unsigned long long)sas_address));
- if (sas_device->enclosure_handle != 0)
- dewtprintk(ioc, pr_info(MPT3SAS_FMT
-"setting
[PATCH 11/13] mpt3sas: Fix nvme drives checking for tlr.
Check for NVMe drives before enabling or checking tlr.
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
---
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 22 --
1 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index b96da33..4d71ef7 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -2013,6 +2013,14 @@ scsih_is_raid(struct device *dev)
return (sdev->channel == RAID_CHANNEL) ? 1 : 0;
}
+static int
+scsih_is_nvme(struct device *dev)
+{
+ struct scsi_device *sdev = to_scsi_device(dev);
+
+ return (sdev->channel == PCIE_CHANNEL) ? 1 : 0;
+}
+
/**
* scsih_get_resync - get raid volume resync percent complete
* @dev the device struct object
@@ -4810,8 +4818,9 @@ scsih_qcmd(struct Scsi_Host *shost, struct scsi_cmnd
*scmd)
/* Make sure Device is not raid volume.
* We do not expose raid functionality to upper layer for warpdrive.
*/
- if (!ioc->is_warpdrive && !scsih_is_raid(&scmd->device->sdev_gendev)
- && sas_is_tlr_enabled(scmd->device) && scmd->cmd_len != 32)
+ if (((!ioc->is_warpdrive && !scsih_is_raid(&scmd->device->sdev_gendev))
+ && !scsih_is_nvme(&scmd->device->sdev_gendev))
+ && sas_is_tlr_enabled(scmd->device) && scmd->cmd_len != 32)
mpi_control |= MPI2_SCSIIO_CONTROL_TLR_ON;
smid = mpt3sas_base_get_smid_scsiio(ioc, ioc->scsi_io_cb_idx, scmd);
@@ -4856,8 +4865,8 @@ scsih_qcmd(struct Scsi_Host *shost, struct scsi_cmnd
*scmd)
raid_device = sas_target_priv_data->raid_device;
if (raid_device && raid_device->direct_io_enabled)
- mpt3sas_setup_direct_io(ioc, scmd, raid_device, mpi_request,
- smid);
+ mpt3sas_setup_direct_io(ioc, scmd,
+ raid_device, mpi_request, smid);
if (likely(mpi_request->Function == MPI2_FUNCTION_SCSI_IO_REQUEST)) {
if (sas_target_priv_data->flags & MPT_TARGET_FASTPATH_IO) {
@@ -5405,9 +5414,10 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8
msix_index, u32 reply)
le32_to_cpu(mpi_reply->ResponseInfo) & 0xFF;
if (!sas_device_priv_data->tlr_snoop_check) {
sas_device_priv_data->tlr_snoop_check++;
- if (!ioc->is_warpdrive &&
+ if ((!ioc->is_warpdrive &&
!scsih_is_raid(&scmd->device->sdev_gendev) &&
- sas_is_tlr_enabled(scmd->device) &&
+ !scsih_is_nvme(&scmd->device->sdev_gendev))
+ && sas_is_tlr_enabled(scmd->device) &&
response_code == MPI2_SCSITASKMGMT_RSP_INVALID_FRAME) {
sas_disable_tlr(scmd->device);
sdev_printk(KERN_INFO, scmd->device, "TLR disabled\n");
--
1.7.1
[PATCH 12/13] mpt3sas: Update MPI Header
Update MPI Files for NVMe support
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
---
drivers/scsi/mpt3sas/mpi/mpi2.h | 43 +++-
drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h | 647 +-
drivers/scsi/mpt3sas/mpi/mpi2_init.h | 11 +-
drivers/scsi/mpt3sas/mpi/mpi2_ioc.h | 331 +-
drivers/scsi/mpt3sas/mpi/mpi2_pci.h | 142
drivers/scsi/mpt3sas/mpi/mpi2_tool.h | 14 +-
6 files changed, 1177 insertions(+), 11 deletions(-)
create mode 100644 drivers/scsi/mpt3sas/mpi/mpi2_pci.h
diff --git a/drivers/scsi/mpt3sas/mpi/mpi2.h b/drivers/scsi/mpt3sas/mpi/mpi2.h
index a9a659f..bc59058 100644
--- a/drivers/scsi/mpt3sas/mpi/mpi2.h
+++ b/drivers/scsi/mpt3sas/mpi/mpi2.h
@@ -8,7 +8,7 @@
* scatter/gather formats.
* Creation Date: June 21, 2006
*
- * mpi2.h Version: 02.00.42
+ * mpi2.h Version: 02.00.48
*
* NOTE: Names (typedefs, defines, etc.) beginning with an MPI25 or Mpi25
* prefix are for use only on MPI v2.5 products, and must not be used
@@ -103,6 +103,16 @@
* 08-25-15 02.00.40 Bumped MPI2_HEADER_VERSION_UNIT.
* 12-15-15 02.00.41 Bumped MPI_HEADER_VERSION_UNIT
* 01-01-16 02.00.42 Bumped MPI_HEADER_VERSION_UNIT
+ * 04-05-16 02.00.43 Modified MPI26_DIAG_BOOT_DEVICE_SELECT defines
+ * to be unique within first 32 characters.
+ * Removed AHCI support.
+ * Removed SOP support.
+ * Bumped MPI2_HEADER_VERSION_UNIT.
+ * 04-10-16 02.00.44 Bumped MPI2_HEADER_VERSION_UNIT.
+ * 07-06-16 02.00.45 Bumped MPI2_HEADER_VERSION_UNIT.
+ * 09-02-16 02.00.46 Bumped MPI2_HEADER_VERSION_UNIT.
+ * 11-23-16 02.00.47 Bumped MPI2_HEADER_VERSION_UNIT.
+ * 02-03-17 02.00.48 Bumped MPI2_HEADER_VERSION_UNIT.
* --
*/
@@ -142,7 +152,7 @@
#define MPI2_VERSION_02_06 (0x0206)
/*Unit and Dev versioning for this MPI header set */
-#define MPI2_HEADER_VERSION_UNIT(0x2A)
+#define MPI2_HEADER_VERSION_UNIT(0x30)
#define MPI2_HEADER_VERSION_DEV (0x00)
#define MPI2_HEADER_VERSION_UNIT_MASK (0xFF00)
#define MPI2_HEADER_VERSION_UNIT_SHIFT (8)
@@ -249,6 +259,12 @@ typedef volatile struct _MPI2_SYSTEM_INTERFACE_REGS {
#define MPI2_DIAG_BOOT_DEVICE_SELECT_DEFAULT(0x)
#define MPI2_DIAG_BOOT_DEVICE_SELECT_HCDW (0x0800)
+/* Defines for V7A/V7R HostDiagnostic Register */
+#define MPI26_DIAG_BOOT_DEVICE_SEL_64FLASH (0x)
+#define MPI26_DIAG_BOOT_DEVICE_SEL_64HCDW (0x0800)
+#define MPI26_DIAG_BOOT_DEVICE_SEL_32FLASH (0x1000)
+#define MPI26_DIAG_BOOT_DEVICE_SEL_32HCDW (0x1800)
+
#define MPI2_DIAG_CLEAR_FLASH_BAD_SIG (0x0400)
#define MPI2_DIAG_FORCE_HCB_ON_RESET(0x0200)
#define MPI2_DIAG_HCB_MODE (0x0100)
@@ -367,6 +383,7 @@ typedef struct _MPI2_DEFAULT_REQUEST_DESCRIPTOR {
#define MPI2_REQ_DESCRIPT_FLAGS_DEFAULT_TYPE(0x08)
#define MPI2_REQ_DESCRIPT_FLAGS_RAID_ACCELERATOR(0x0A)
#define MPI25_REQ_DESCRIPT_FLAGS_FAST_PATH_SCSI_IO (0x0C)
+#define MPI26_REQ_DESCRIPT_FLAGS_PCIE_ENCAPSULATED (0x10)
#define MPI2_REQ_DESCRIPT_FLAGS_IOC_FIFO_MARKER (0x01)
@@ -425,6 +442,13 @@ typedef MPI2_SCSI_IO_REQUEST_DESCRIPTOR
Mpi25FastPathSCSIIORequestDescriptor_t,
*pMpi25FastPathSCSIIORequestDescriptor_t;
+/*PCIe Encapsulated Request Descriptor */
+typedef MPI2_SCSI_IO_REQUEST_DESCRIPTOR
+ MPI26_PCIE_ENCAPSULATED_REQUEST_DESCRIPTOR,
+ *PTR_MPI26_PCIE_ENCAPSULATED_REQUEST_DESCRIPTOR,
+ Mpi26PCIeEncapsulatedRequestDescriptor_t,
+ *pMpi26PCIeEncapsulatedRequestDescriptor_t;
+
/*union of Request Descriptors */
typedef union _MPI2_REQUEST_DESCRIPTOR_UNION {
MPI2_DEFAULT_REQUEST_DESCRIPTOR Default;
@@ -433,6 +457,7 @@ typedef union _MPI2_REQUEST_DESCRIPTOR_UNION {
MPI2_SCSI_TARGET_REQUEST_DESCRIPTOR SCSITarget;
MPI2_RAID_ACCEL_REQUEST_DESCRIPTOR RAIDAccelerator;
MPI25_FP_SCSI_IO_REQUEST_DESCRIPTOR FastPathSCSIIO;
+ MPI26_PCIE_ENCAPSULATED_REQUEST_DESCRIPTOR PCIeEncapsulated;
U64 Words;
} MPI2_REQUEST_DESCRIPTOR_UNION,
*PTR_MPI2_REQUEST_DESCRIPTOR_UNION,
@@ -450,6 +475,7 @@ typedef union _MPI2_REQUEST_DESCRIPTOR_UNION {
* Atomic SCSI Target Request Descriptor
* Atomic RAID Accelerator Request Descriptor
* Atomic Fast Path SCSI IO Request Descriptor
+ * Atomic PCIe Encapsulated Request Descriptor
*/
/*Atomic Request Descriptor */
@@ -487,6 +513,7 @@ typedef struct _MPI2_DEFAULT_REPLY_DESCRIPTOR {
#define MPI2_RPY_DESCRIPT_FLAGS_TARGET_COMMAND_BUFFER (0x03)
#define MPI2_RPY_DESCRIPT_FLAGS_RAID_ACCELERATOR_SUCCESS(0x05)
#define MPI25_RPY_DESCRIPT_FLAGS_FAST_PATH_SCSI_IO_SUCCESS (0x06)
+#define MPI26_RPY_DESCRIPT_FLAGS_PCIE_ENCAPSULAT
[PATCH 07/13] mpt3sas: API's to remove nvme drive from sml
Below API's are included in nvme drive remove path.
_scsih_pcie_device_remove
_scsih_pcie_device_remove_by_handle
_scsih_pcie_device_remove_from_sml
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
---
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 190 +-
1 files changed, 188 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index e52bebe..68aa102 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -73,7 +73,8 @@ static void _scsih_remove_device(struct MPT3SAS_ADAPTER *ioc,
static int _scsih_add_device(struct MPT3SAS_ADAPTER *ioc, u16 handle,
u8 retry_count, u8 is_pd);
static int _scsih_pcie_add_device(struct MPT3SAS_ADAPTER *ioc, u16 handle);
-
+static void _scsih_pcie_device_remove_from_sml(struct MPT3SAS_ADAPTER *ioc,
+ struct _pcie_device *pcie_device);
static u8 _scsih_check_for_pending_tm(struct MPT3SAS_ADAPTER *ioc, u16 smid);
/* global parameters */
@@ -1048,6 +1049,86 @@ mpt3sas_get_pdev_by_handle(struct MPT3SAS_ADAPTER *ioc,
u16 handle)
return pcie_device;
}
+
+/**
+ * _scsih_pcie_device_remove - remove pcie_device from list.
+ * @ioc: per adapter object
+ * @pcie_device: the pcie_device object
+ * Context: This function will acquire ioc->pcie_device_lock.
+ *
+ * If pcie_device is on the list, remove it and decrement its reference count.
+ */
+static void
+_scsih_pcie_device_remove(struct MPT3SAS_ADAPTER *ioc,
+ struct _pcie_device *pcie_device)
+{
+ unsigned long flags;
+ int was_on_pcie_device_list = 0;
+
+ if (!pcie_device)
+ return;
+ pr_info(MPT3SAS_FMT
+ "removing handle(0x%04x), wwid(0x%016llx)\n",
+ ioc->name, pcie_device->handle,
+ (unsigned long long) pcie_device->wwid);
+ if (pcie_device->enclosure_handle != 0)
+ pr_info(MPT3SAS_FMT
+ "removing enclosure logical id(0x%016llx), slot(%d)\n",
+ ioc->name,
+ (unsigned long long)pcie_device->enclosure_logical_id,
+ pcie_device->slot);
+ if (pcie_device->connector_name[0] != '\0')
+ pr_info(MPT3SAS_FMT
+ "removing enclosure level(0x%04x), connector name(
%s)\n",
+ ioc->name, pcie_device->enclosure_level,
+ pcie_device->connector_name);
+
+ spin_lock_irqsave(&ioc->pcie_device_lock, flags);
+ if (!list_empty(&pcie_device->list)) {
+ list_del_init(&pcie_device->list);
+ was_on_pcie_device_list = 1;
+ }
+ spin_unlock_irqrestore(&ioc->pcie_device_lock, flags);
+ if (was_on_pcie_device_list) {
+ kfree(pcie_device->serial_number);
+ pcie_device_put(pcie_device);
+ }
+}
+
+
+/**
+ * _scsih_pcie_device_remove_by_handle - removing pcie device object by handle
+ * @ioc: per adapter object
+ * @handle: device handle
+ *
+ * Return nothing.
+ */
+static void
+_scsih_pcie_device_remove_by_handle(struct MPT3SAS_ADAPTER *ioc, u16 handle)
+{
+ struct _pcie_device *pcie_device;
+ unsigned long flags;
+ int was_on_pcie_device_list = 0;
+
+ if (ioc->shost_recovery)
+ return;
+
+ spin_lock_irqsave(&ioc->pcie_device_lock, flags);
+ pcie_device = __mpt3sas_get_pdev_by_handle(ioc, handle);
+ if (pcie_device) {
+ if (!list_empty(&pcie_device->list)) {
+ list_del_init(&pcie_device->list);
+ was_on_pcie_device_list = 1;
+ pcie_device_put(pcie_device);
+ }
+ }
+ spin_unlock_irqrestore(&ioc->pcie_device_lock, flags);
+ if (was_on_pcie_device_list) {
+ _scsih_pcie_device_remove_from_sml(ioc, pcie_device);
+ pcie_device_put(pcie_device);
+ }
+}
+
/**
* _scsih_pcie_device_add - add pcie_device object
* @ioc: per adapter object
@@ -6630,6 +6711,83 @@ _scsih_check_pcie_access_status(struct MPT3SAS_ADAPTER
*ioc, u64 wwid,
(unsigned long long)wwid, handle);
return rc;
}
+
+/**
+ * _scsih_pcie_device_remove_from_sml - removing pcie device
+ * from SML and free up associated memory
+ * @ioc: per adapter object
+ * @pcie_device: the pcie_device object
+ *
+ * Return nothing.
+ */
+static void
+_scsih_pcie_device_remove_from_sml(struct MPT3SAS_ADAPTER *ioc,
+ struct _pcie_device *pcie_device)
+{
+ struct MPT3SAS_TARGET *sas_target_priv_data;
+
+ dewtprintk(ioc, pr_info(MPT3SAS_FMT
+ "%s: enter: handle(0x%04x), wwid(0x%016llx)\n", ioc->name, __func__,
+ pcie_device->handle, (unsigned long long)
+ pcie_device->wwid));
+ if (pcie_device->enclosure_handle != 0)
+ dewtprintk(ioc, pr_info(MPT3SAS_FMT
+ "%s: enter: enclosur
[PATCH 13/13] mpt3sas: Update mpt3sas driver version.
Updated mpt3sas driver version to 15.101.00.00 Signed-off-by: Chaitra P B Signed-off-by: Suganath Prabu S --- drivers/scsi/mpt3sas/mpt3sas_base.h |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h b/drivers/scsi/mpt3sas/mpt3sas_base.h index ea6e607..835d6da 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_base.h +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h @@ -74,11 +74,11 @@ #define MPT3SAS_DRIVER_NAME"mpt3sas" #define MPT3SAS_AUTHOR "Avago Technologies " #define MPT3SAS_DESCRIPTION"LSI MPT Fusion SAS 3.0 Device Driver" -#define MPT3SAS_DRIVER_VERSION "15.100.00.00" +#define MPT3SAS_DRIVER_VERSION "15.101.00.00" #define MPT3SAS_MAJOR_VERSION 15 -#define MPT3SAS_MINOR_VERSION 100 +#define MPT3SAS_MINOR_VERSION 101 #define MPT3SAS_BUILD_VERSION 0 -#define MPT3SAS_RELEASE_VERSION00 +#define MPT3SAS_RELEASE_VERSION0 #define MPT2SAS_DRIVER_NAME"mpt2sas" #define MPT2SAS_DESCRIPTION"LSI MPT Fusion SAS 2.0 Device Driver" -- 1.7.1
[PATCH 10/13] mpt3sas: NVMe drive support for BTDHMAPPING ioctl command and log info
* Added debug prints for pcie devices in ioctl debug path. Which
will be helpful for debugging.
* Added PCIe device support for ioctl BTDHMAPPING ioctl.
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
---
drivers/scsi/mpt3sas/mpt3sas_base.h |3 +-
drivers/scsi/mpt3sas/mpt3sas_ctl.c | 88 --
drivers/scsi/mpt3sas/mpt3sas_warpdrive.c |2 +-
3 files changed, 61 insertions(+), 32 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 063977a..ea6e607 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -452,6 +452,7 @@ struct _internal_cmd {
struct completion done;
void*reply;
void*sense;
+ u64 *nvme_error_response;
u16 status;
u16 smid;
};
@@ -1615,7 +1616,7 @@ void
mpt3sas_scsi_direct_io_set(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8
direct_io);
void
mpt3sas_setup_direct_io(struct MPT3SAS_ADAPTER *ioc, struct scsi_cmnd *scmd,
- struct _raid_device *raid_device, Mpi2SCSIIORequest_t *mpi_request,
+ struct _raid_device *raid_device, Mpi25SCSIIORequest_t *mpi_request,
u16 smid);
/* NCQ Prio Handling Check */
diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
index 35e5c30..269c753 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
@@ -79,32 +79,6 @@ enum block_state {
};
/**
- * _ctl_sas_device_find_by_handle - sas device search
- * @ioc: per adapter object
- * @handle: sas device handle (assigned by firmware)
- * Context: Calling function should acquire ioc->sas_device_lock
- *
- * This searches for sas_device based on sas_address, then return sas_device
- * object.
- */
-static struct _sas_device *
-_ctl_sas_device_find_by_handle(struct MPT3SAS_ADAPTER *ioc, u16 handle)
-{
- struct _sas_device *sas_device, *r;
-
- r = NULL;
- list_for_each_entry(sas_device, &ioc->sas_device_list, list) {
- if (sas_device->handle != handle)
- continue;
- r = sas_device;
- goto out;
- }
-
- out:
- return r;
-}
-
-/**
* _ctl_display_some_debug - debug routine
* @ioc: per adapter object
* @smid: system request message index
@@ -229,10 +203,9 @@ _ctl_display_some_debug(struct MPT3SAS_ADAPTER *ioc, u16
smid,
Mpi2SCSIIOReply_t *scsi_reply =
(Mpi2SCSIIOReply_t *)mpi_reply;
struct _sas_device *sas_device = NULL;
- unsigned long flags;
+ struct _pcie_device *pcie_device = NULL;
- spin_lock_irqsave(&ioc->sas_device_lock, flags);
- sas_device = _ctl_sas_device_find_by_handle(ioc,
+ sas_device = mpt3sas_get_sdev_by_handle(ioc,
le16_to_cpu(scsi_reply->DevHandle));
if (sas_device) {
pr_warn(MPT3SAS_FMT "\tsas_address(0x%016llx),
phy(%d)\n",
@@ -242,8 +215,25 @@ _ctl_display_some_debug(struct MPT3SAS_ADAPTER *ioc, u16
smid,
"\tenclosure_logical_id(0x%016llx), slot(%d)\n",
ioc->name, (unsigned long long)
sas_device->enclosure_logical_id, sas_device->slot);
+ sas_device_put(sas_device);
+ }
+ if (!sas_device) {
+ pcie_device = mpt3sas_get_pdev_by_handle(ioc,
+ le16_to_cpu(scsi_reply->DevHandle));
+ if (pcie_device) {
+ pr_warn(MPT3SAS_FMT
+ "\tWWID(0x%016llx), port(%d)\n", ioc->name,
+ (unsigned long long)pcie_device->wwid,
+ pcie_device->port_num);
+ if (pcie_device->enclosure_handle != 0)
+ pr_warn(MPT3SAS_FMT
+ "\tenclosure_logical_id(0x%016llx),
slot(%d)\n",
+ ioc->name, (unsigned long long)
+ pcie_device->enclosure_logical_id,
+ pcie_device->slot);
+ pcie_device_put(pcie_device);
+ }
}
- spin_unlock_irqrestore(&ioc->sas_device_lock, flags);
if (scsi_reply->SCSIState || scsi_reply->SCSIStatus)
pr_info(MPT3SAS_FMT
"\tscsi_state(0x%02x), scsi_status"
@@ -1375,6 +1365,42 @@ _ctl_btdh_search_sas_device(struct MPT3SAS_ADAPTER *ioc,
}
/**
+ * _ctl_btdh_search_pcie_device - searching for pcie device
+ * @ioc: per adapter object
+ * @btdh: btdh ioctl payload
+ */
+static int
+_ctl_btdh_search_pcie_device(struct MPT3SAS_ADAPTER *i
Re: [PATCH] brcmfmac: added LED triggers for transmit/receive
On 10-07-17 19:02, Russell Joyce wrote: >> 1) I think most of it should be some cfg80211 shareable code. > > I’m not sure exactly what you mean by this, could you please clarify? What I think Rafał is saying is that it would be better to have this code in cfg80211 so other drivers including mac80211 could use it. >> 2) This "rxtx" while surely present in other places sounds like a >> workaround for LED subsystem limitation. Maybe it's time to finally >> rework LED triggers. > > I agree that it’s not an ideal way to do things, but I couldn’t think of a > better alternative. I think that having a combined trigger is useful though, > for > situations like using the single LED on a Raspberry Pi to show Wi-Fi activity. Indeed. However, the LED subsystem could/should(?) take care of mapping "rx" and "tx" triggers to the same LED. I am happy to comment on your patch, but maybe you can first take a look at the suggestion Rafał made above. Regards, Arend
[PATCH 08/13] mpt3sas: scan and add nvme device after controller reset
After Controller reset, Scan and add nvme device back to the topology.
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
---
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 196 +-
1 files changed, 191 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 68aa102..7100ee8 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -4867,6 +4867,7 @@ _scsih_scsi_ioc_info(struct MPT3SAS_ADAPTER *ioc, struct
scsi_cmnd *scmd,
char *desc_scsi_state = ioc->tmp_string;
u32 log_info = le32_to_cpu(mpi_reply->IOCLogInfo);
struct _sas_device *sas_device = NULL;
+ struct _pcie_device *pcie_device = NULL;
struct scsi_target *starget = scmd->device->sdev_target;
struct MPT3SAS_TARGET *priv_target = starget->hostdata;
char *device_str = NULL;
@@ -4999,6 +5000,28 @@ _scsih_scsi_ioc_info(struct MPT3SAS_ADAPTER *ioc, struct
scsi_cmnd *scmd,
if (priv_target->flags & MPT_TARGET_FLAGS_VOLUME) {
pr_warn(MPT3SAS_FMT "\t%s wwid(0x%016llx)\n", ioc->name,
device_str, (unsigned long long)priv_target->sas_address);
+ } else if (priv_target->flags & MPT_TARGET_FLAGS_PCIE_DEVICE) {
+ pcie_device = mpt3sas_get_pdev_from_target(ioc, priv_target);
+ if (pcie_device) {
+ pr_info(MPT3SAS_FMT "\twwid(0x%016llx), port(%d)\n",
+ ioc->name,
+ (unsigned long long)pcie_device->wwid,
+ pcie_device->port_num);
+ if (pcie_device->enclosure_handle != 0)
+ pr_info(MPT3SAS_FMT
+ "\tenclosure logical id(0x%016llx), "
+ "slot(%d)\n", ioc->name,
+ (unsigned long long)
+ pcie_device->enclosure_logical_id,
+ pcie_device->slot);
+ if (pcie_device->connector_name[0])
+ pr_info(MPT3SAS_FMT
+ "\tenclosure level(0x%04x),"
+ "connector name( %s)\n",
+ ioc->name, pcie_device->enclosure_level,
+ pcie_device->connector_name);
+ pcie_device_put(pcie_device);
+ }
} else {
sas_device = mpt3sas_get_sdev_from_target(ioc, priv_target);
if (sas_device) {
@@ -5045,11 +5068,10 @@ _scsih_scsi_ioc_info(struct MPT3SAS_ADAPTER *ioc,
struct scsi_cmnd *scmd,
struct sense_info data;
_scsih_normalize_sense(scmd->sense_buffer, &data);
pr_warn(MPT3SAS_FMT
- "\t[sense_key,asc,ascq]: [0x%02x,0x%02x,0x%02x],
count(%d)\n",
- ioc->name, data.skey,
- data.asc, data.ascq, le32_to_cpu(mpi_reply->SenseCount));
+ "\t[sense_key,asc,ascq]: [0x%02x,0x%02x,0x%02x], count(%d)\n",
+ ioc->name, data.skey,
+ data.asc, data.ascq, le32_to_cpu(mpi_reply->SenseCount));
}
-
if (scsi_state & MPI2_SCSI_STATE_RESPONSE_INFO_VALID) {
response_info = le32_to_cpu(mpi_reply->ResponseInfo);
response_bytes = (u8 *)&response_info;
@@ -6931,7 +6953,7 @@ _scsih_pcie_add_device(struct MPT3SAS_ADAPTER *ioc, u16
handle)
pcie_device_pg0.AccessStatus))
return 0;
- if (!(_scsih_is_nvme_device(pcie_device_pg0.DeviceInfo)))
+ if (!(_scsih_is_nvme_device(le32_to_cpu(pcie_device_pg0.DeviceInfo
return 0;
pcie_device = mpt3sas_get_pdev_by_wwid(ioc, wwid);
@@ -8510,6 +8532,130 @@ _scsih_search_responding_sas_devices(struct
MPT3SAS_ADAPTER *ioc)
}
/**
+ * _scsih_mark_responding_pcie_device - mark a pcie_device as responding
+ * @ioc: per adapter object
+ * @pcie_device_pg0: PCIe Device page 0
+ *
+ * After host reset, find out whether devices are still responding.
+ * Used in _scsih_remove_unresponding_devices.
+ *
+ * Return nothing.
+ */
+static void
+_scsih_mark_responding_pcie_device(struct MPT3SAS_ADAPTER *ioc,
+ Mpi26PCIeDevicePage0_t *pcie_device_pg0)
+{
+ struct MPT3SAS_TARGET *sas_target_priv_data = NULL;
+ struct scsi_target *starget;
+ struct _pcie_device *pcie_device;
+ unsigned long flags;
+
+ spin_lock_irqsave(&ioc->pcie_device_lock, flags);
+ list_for_each_entry(pcie_device, &ioc->pcie_device_list, list) {
+ if ((pcie_device->wwid == pcie_device_pg0->WWID) &&
+ (pcie_device->slot == pcie_device_pg0->Slot)) {
+ pcie_device->responding = 1;
+ starget = pcie_device->starget;
+
[PATCH 05/13] mpt3sas: Set NVMe device queue depth as 128
Sets nvme device queue depth, name and displays device capabilities.
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
---
drivers/scsi/mpt3sas/mpt3sas_base.h |2 +-
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 40 ++
2 files changed, 41 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 26239ec..0f07b16 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -115,7 +115,7 @@
#define MPT3SAS_RAID_MAX_SECTORS 8192
#define MPT3SAS_HOST_PAGE_SIZE_4K 12
-
+#define MPT3SAS_NVME_QUEUE_DEPTH 128
#define MPT_NAME_LENGTH32 /* generic length of
strings */
#define MPT_STRING_LENGTH 64
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 2a6a8e6..e4e35c1 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -1962,6 +1962,7 @@ scsih_slave_configure(struct scsi_device *sdev)
struct MPT3SAS_DEVICE *sas_device_priv_data;
struct MPT3SAS_TARGET *sas_target_priv_data;
struct _sas_device *sas_device;
+ struct _pcie_device *pcie_device;
struct _raid_device *raid_device;
unsigned long flags;
int qdepth;
@@ -2092,6 +2093,45 @@ scsih_slave_configure(struct scsi_device *sdev)
}
}
+ /* PCIe handling */
+ if (sas_target_priv_data->flags & MPT_TARGET_FLAGS_PCIE_DEVICE) {
+ spin_lock_irqsave(&ioc->pcie_device_lock, flags);
+ pcie_device = __mpt3sas_get_pdev_by_wwid(ioc,
+ sas_device_priv_data->sas_target->sas_address);
+ if (!pcie_device) {
+ spin_unlock_irqrestore(&ioc->pcie_device_lock, flags);
+ dfailprintk(ioc, pr_warn(MPT3SAS_FMT
+ "failure at %s:%d/%s()!\n", ioc->name, __FILE__,
+ __LINE__, __func__));
+ return 1;
+ }
+
+ /*TODO-right Queue Depth?*/
+ qdepth = MPT3SAS_NVME_QUEUE_DEPTH;
+ ds = "NVMe";
+ /*TODO-Add device name when defined*/
+ sdev_printk(KERN_INFO, sdev,
+ "%s: handle(0x%04x), wwid(0x%016llx), port(%d)\n",
+ ds, handle, (unsigned long long)pcie_device->wwid,
+ pcie_device->port_num);
+ if (pcie_device->enclosure_handle != 0)
+ sdev_printk(KERN_INFO, sdev,
+ "%s: enclosure logical id(0x%016llx), slot(%d)\n",
+ ds,
+ (unsigned long long)pcie_device->enclosure_logical_id,
+ pcie_device->slot);
+ if (pcie_device->connector_name[0] != '\0')
+ sdev_printk(KERN_INFO, sdev,
+ "%s: enclosure level(0x%04x),"
+ "connector name( %s)\n", ds,
+ pcie_device->enclosure_level,
+ pcie_device->connector_name);
+ pcie_device_put(pcie_device);
+ spin_unlock_irqrestore(&ioc->pcie_device_lock, flags);
+ scsih_change_queue_depth(sdev, qdepth);
+ return 0;
+ }
+
spin_lock_irqsave(&ioc->sas_device_lock, flags);
sas_device = __mpt3sas_get_sdev_by_addr(ioc,
sas_device_priv_data->sas_target->sas_address);
--
1.7.1
[PATCH] parisc: pdc_stable: constify attribute_group structures.
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work
with const attribute_group. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
---
drivers/parisc/pdc_stable.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/parisc/pdc_stable.c b/drivers/parisc/pdc_stable.c
index 055f83f..7147aa5 100644
--- a/drivers/parisc/pdc_stable.c
+++ b/drivers/parisc/pdc_stable.c
@@ -954,7 +954,7 @@ static ssize_t pdcs_osdep2_write(struct kobject *kobj,
NULL,
};
-static struct attribute_group pdcs_attr_group = {
+static const struct attribute_group pdcs_attr_group = {
.attrs = pdcs_subsys_attrs,
};
--
1.9.1
Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)
* Kyle Huey wrote: > On Wed, Jul 5, 2017 at 10:07 PM, Robert O'Callahan > wrote: > > On Tue, Jul 4, 2017 at 3:21 AM, Mark Rutland wrote: > >> Should any of those be moved into the "should be dropped" pile? > > > > Why not be conservative and clear every sample you're not sure about? > > > > We'd appreciate a fix sooner rather than later here, since rr is > > currently broken on every stable Linux kernel and our attempts to > > implement a workaround have failed. > > > > (We have separate "interrupt" and "measure" counters, and I thought we > > might work around this regression by programming the "interrupt" > > counter to count kernel events as well as user events (interrupting > > early is OK), but that caused our (completely separate) "measure" > > counter to report off-by-one results (!), which seems to be a > > different bug present on a range of older kernels.) > > This seems to have stalled out here unfortunately. > > Can we get a consensus (from ingo or peterz?) on Mark's question? Or, > alternatively, can we move the patch at the top of this thread forward > on the stable branches until we do reach an answer to that question? > > We've abandoned hope of working around this problem in rr and are > currently broken for all of our users with an up-to-date kernel, so > the situation for us is rather dire at the moment I'm afraid. Sorry about that - I've queued up a revert for the original commit and will send the fix to Linus later today. I've added a -stable tag as well so it can be forwarded to Greg the moment it hits upstream. We should do the original fix as well, but in a version that does not skip the sample but zeroes out the RIP and registers (or sets them all to -1LL) - and also covers other possible places where skid-RIP is exposed, such as LBR. Thanks, Ingo
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods
On Mon, Jul 10, 2017 at 10:27:05AM -0700, Andi Kleen wrote: > On Mon, Jul 10, 2017 at 06:42:06PM +0200, Peter Zijlstra wrote: > > I have, and last time I did the actual poking at the LAPIC (to make NOHZ > > happen) was by far the slowest thing happening. > > That must have been a long time ago because modern systems use TSC deadline > for a very long time ... Its been a while, but I didn't use the very latest chip when I did. > It's still slow, but not as slow as the LAPIC. Deadline TSC is a LAPIC timer mode. Sure the MSR might be slightly cheaper than the MMIO, but its still painful.
[tip:perf/urgent] Revert "perf/core: Drop kernel samples even though :u is specified"
Commit-ID: 6a8a75f3235724c5941a33e287b2f98966ad14c5
Gitweb: http://git.kernel.org/tip/6a8a75f3235724c5941a33e287b2f98966ad14c5
Author: Ingo Molnar
AuthorDate: Tue, 11 Jul 2017 10:56:54 +0200
Committer: Ingo Molnar
CommitDate: Tue, 11 Jul 2017 10:56:54 +0200
Revert "perf/core: Drop kernel samples even though :u is specified"
This reverts commit cc1582c231ea041fbc68861dfaf957eaf902b829.
This commit introduced a regression that broke rr-project, which uses sampling
events to receive a signal on overflow (but does not care about the contents
of the sample). These signals are critical to the correct operation of rr.
There's been some back and forth about how to fix it - but to not keep
applications in limbo queue up a revert.
Reported-by: Kyle Huey
Acked-by: Kyle Huey
Acked-by: Peter Zijlstra
Cc: Jin Yao
Cc: Vince Weaver
Cc: Linus Torvalds
Cc: Will Deacon
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Stephane Eranian
Cc: Namhyung Kim
Cc: Jiri Olsa
Cc:
Link: http://lkml.kernel.org/r/20170628105600.GC5981@leverpostej
Signed-off-by: Ingo Molnar
---
kernel/events/core.c | 21 -
1 file changed, 21 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 4d2c32f..9747e42 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7308,21 +7308,6 @@ int perf_event_account_interrupt(struct perf_event
*event)
return __perf_event_account_interrupt(event, 1);
}
-static bool sample_is_allowed(struct perf_event *event, struct pt_regs *regs)
-{
- /*
-* Due to interrupt latency (AKA "skid"), we may enter the
-* kernel before taking an overflow, even if the PMU is only
-* counting user events.
-* To avoid leaking information to userspace, we must always
-* reject kernel samples when exclude_kernel is set.
-*/
- if (event->attr.exclude_kernel && !user_mode(regs))
- return false;
-
- return true;
-}
-
/*
* Generic event overflow handling, sampling.
*/
@@ -7344,12 +7329,6 @@ static int __perf_event_overflow(struct perf_event
*event,
ret = __perf_event_account_interrupt(event, throttle);
/*
-* For security, drop the skid kernel samples if necessary.
-*/
- if (!sample_is_allowed(event, regs))
- return ret;
-
- /*
* XXX event_limit might not quite work as expected on inherited
* events
*/
Re: [PATCH v10] vfio: ABI for mdev display dma-buf operation
On Tue, Jul 11, 2017 at 08:14:08AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > +struct vfio_device_query_gfx_plane {
> > > + __u32 argsz;
> > > + __u32 flags;
> > > + struct vfio_device_gfx_plane_info plane_info;
> > > + __u32 plane_type;
> > > + __s32 fd; /* dma-buf fd */
> > > + __u32 plane_id;
> > > +};
> > > +
> >
> > It would be better to have comment here about what are expected
> > values
> > for plane_type and plane_id.
>
> plane_type is DRM_PLANE_TYPE_*.
>
> yes, a comment saying so would be good, same for drm_format which is
> DRM_FORMAT_*. While looking at these two: renaming plane_type to
> drm_plane_type (for consistency) is probably a good idea too.
>
> plane_id needs a specification.
Why do you need plane_type? With universal planes the plane_id along is
sufficient to identify a plane on a given drm device instance. I'd just
remove it.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v10] vfio: ABI for mdev display dma-buf operation
On Thu, Jul 06, 2017 at 06:29:55AM +0800, Tina Zhang wrote:
> Add VFIO_DEVICE_QUERY_GFX_PLANE ioctl command to let user mode query and
> get the plan and its related information.
>
> The dma-buf's life cycle is handled by user mode and tracked by kernel.
> The returned fd in struct vfio_device_query_gfx_plane can be a new
> fd or an old fd of a re-exported dma-buf. Host User mode can check the
> value of fd and to see if it need to creat new resource according to the
> new fd or just use the existed resource related to the old fd.
>
> Signed-off-by: Tina Zhang
>
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index ae46105..c92bc69 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -502,6 +502,36 @@ struct vfio_pci_hot_reset {
>
> #define VFIO_DEVICE_PCI_HOT_RESET_IO(VFIO_TYPE, VFIO_BASE + 13)
>
> +/**
> + * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14,
> + * struct vfio_device_query_gfx_plane)
> + * Return: 0 on success, -errno on failure.
> + */
> +
> +struct vfio_device_gfx_plane_info {
> + __u64 start;
> + __u64 drm_format_mod;
> + __u32 drm_format;
> + __u32 width;
> + __u32 height;
> + __u32 stride;
> + __u32 size;
> + __u32 x_pos;
> + __u32 y_pos;
> +};
Would be good to have a detailed spec of all this stuff, plus what's it
meant to be used for. I assume that e.g. start would be the opaque cookie
thing we've talked about, for dma-buf reuse? Otherwise I'm not sure what
it's good for, since the same gpu vram address can be reused for different
memory objects ...
> +
> +struct vfio_device_query_gfx_plane {
> + __u32 argsz;
> + __u32 flags;
> + struct vfio_device_gfx_plane_info plane_info;
> + __u32 plane_type;
> + __s32 fd; /* dma-buf fd */
> + __u32 plane_id;
> +};
As mentioned in the other reply already, I'm not sure what plane_type is
for. Otherwise this looks ok-ish, but hard to tell without more detailed
spec.
-Daniel
> +
> +#define VFIO_DEVICE_QUERY_GFX_PLANE _IO(VFIO_TYPE, VFIO_BASE + 14)
> +
> +
> /* API for Type1 VFIO IOMMU */
>
> /**
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
RE: [PATCH CFT 0/4] VT-d PI fixes
> -Original Message- > From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On > Behalf Of Paolo Bonzini > Sent: Tuesday, July 11, 2017 4:56 PM > To: Gonglei (Arei) > Cc: linux-kernel@vger.kernel.org; k...@vger.kernel.org; longpeng; > Huangweidong (C); wangxin (U); Radim Krčmář > Subject: Re: [PATCH CFT 0/4] VT-d PI fixes > > On 07/06/2017 11:33, Gonglei (Arei) wrote: > > We are testing your patch, but maybe need some time to report > > the results because it's not an inevitable problem. > > > > Meanwhile we also try to find a possible scenario of non-hotplugging to > > explain the double-add warnings. > > Hi Lei, > > do you have any updates? Dear Paolo, Thanks for kicking me :) TBH, thinking about the reliability of productive project (we use kvm-4.4), we applied the patch you used in fedora pastebin, and the bug seems gone after one month's testing. diff --git a/source/x86/vmx.c b/source/x86/vmx.c index 79012cf..efc611f 100644 --- a/source/x86/vmx.c +++ b/source/x86/vmx.c @@ -11036,8 +11036,9 @@ static void pi_post_block(struct kvm_vcpu *vcpu) unsigned int dest; unsigned long flags; - if (!kvm_arch_has_assigned_device(vcpu->kvm) || - !irq_remapping_cap(IRQ_POSTING_CAP)) + if ((vcpu->pre_pcpu == -1) && + (!kvm_arch_has_assigned_device(vcpu->kvm) || + !irq_remapping_cap(IRQ_POSTING_CAP))) return; > I would like to get at least the first three > patches in 4.13. > I think they are okay to me for upstream. Thanks, -Gonglei
Re: [PATCH] dpaa_eth: use correct device for DMA mapping API
On Tue, Jul 11, 2017 at 10:50 AM, Madalin-cristian Bucur
wrote:
> Hi Arnd,
>
> Thanks for looking into this, I've tested your fix, it seems to need more
> work:
>
> [0.894968] platform: DMA map failed
> [0.898627] platform: DMA map failed
> [0.902288] platform: DMA map failed
> [0.905947] platform: DMA map failed
> [0.909606] platform: DMA map failed
> [0.913265] platform: DMA map failed
I see: the assignment ended up after the first use, so ->dev was still
NULL here.
This should fix the problem you saw here:
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index f7b0b928cd53..988c0212ce7e 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -2650,6 +2650,8 @@ static int dpaa_eth_probe(struct platform_device *pdev)
for (i = 0; i < DPAA_BPS_NUM; i++) {
int err;
+ /* DMA operations are done on the platform-provided device */
+ dpaa_bps[i]->dev = dev->parent;
dpaa_bps[i] = dpaa_bp_alloc(dev);
if (IS_ERR(dpaa_bps[i]))
return PTR_ERR(dpaa_bps[i]);
@@ -2657,8 +2659,6 @@ static int dpaa_eth_probe(struct platform_device *pdev)
dpaa_bps[i]->raw_size = bpool_buffer_raw_size(i, DPAA_BPS_NUM);
/* avoid runtime computations by keeping the usable size here */
dpaa_bps[i]->size = dpaa_bp_size(dpaa_bps[i]->raw_size);
- /* DMA operations are done on the platform-provided device */
- dpaa_bps[i]->dev = dev->parent;
err = dpaa_bp_alloc_pool(dpaa_bps[i]);
if (err < 0) {
> @@ -2806,7 +2799,6 @@ static int dpaa_eth_probe(struct platform_device *pdev)
> dpaa_bps_free(priv);
> bp_create_failed:
> fq_probe_failed:
> -dev_mask_failed:
> mac_probe_failed:
> dev_set_drvdata(dev, NULL);
> free_netdev(net_dev);
>
> I'll try to address your concern about performing the DMA mapping on a
> different
> device than the one set up by the platform code.
Thanks!
Arnd
Re: [PATCH v2 1/4] scsi: scsi_dh_alua: allow I/O in target port unavailable and standby states
On 07/11/2017 12:47 AM, Mauricio Faria de Oliveira wrote:
> According to SPC-4 (5.15.2.4.5 Unavailable state), the unavailable
> state may (or may not) transition to other states (e.g., microcode
> downloading or hardware error, which may be temporary or permanent).
>
> But, scsi_dh_alua currently fails I/O requests early on once that
> state occurs (in alua_prep_fn()) preventing path checkers in such
> function path to actually check if I/O still fails or now works.
>
> And that prevents a path activation (alua_activate()) which could
> update the PG state if it eventually recovered to an active state,
> thus resume I/O. (This is also the case with the standby state.)
>
> This might cause device-mapper multipath to fail all paths to some
> storage system that moves the controllers to the unavailable state
> for firmware upgrades, and never recover regardless of the storage
> system doing upgrades one controller at a time and get them online.
>
> Then I/O requests are blocked indefinitely due to queue_if_no_path
> but the underlying individual paths are fully operational, and can
> be verified as such through other function paths (e.g., SG_IO):
>
> # multipath -l
> mpatha (360050764008100dac100) dm-0 IBM,2145
> size=40G features='2 queue_if_no_path retain_attached_hw_handler'
> hwhandler='1 alua' wp=rw
> |-+- policy='service-time 0' prio=0 status=enabled
> | |- 1:0:1:0 sdf 8:80 failed undef running
> | `- 2:0:1:0 sdn 8:208 failed undef running
> `-+- policy='service-time 0' prio=0 status=enabled
> |- 1:0:0:0 sdb 8:16 failed undef running
> `- 2:0:0:0 sdj 8:144 failed undef running
>
> # strace -e read \
> sg_dd blk_sgio=0 \
> if=/dev/sdj of=/dev/null bs=512 count=1 iflag=direct \
> 2>&1 | grep 512
> read(3, 0x3fff7ba8, 512) = -1 EIO (Input/output error)
>
> # strace -e ioctl \
> sg_dd blk_sgio=1 \
> if=/dev/sdj of=/dev/null bs=512 count=1 iflag=direct \
> 2>&1 | grep 512
> ioctl(3, SG_IO, {'S', SG_DXFER_FROM_DEV, cmd[10]=[28, 00, 00, 00,
> 00, 00, 00, 00, 01, 00], <...>) = 0
>
> So, allow I/O to paths of PGs in unavailable/standby state, so path
> checkers can actually check them.
>
> Also, schedule a recheck when unavailable/standby state is detected
> (in alua_check_sense()) to update pg->state, and quiet further SCSI
> error messages (in alua_prep_fn()).
>
> Once a path checker eventually detects a working/active state again,
> the PG state is normally updated on path activation (alua_activate(),
> as it schedules a recheck), thus I/O requests are no longer failed.
>
> Signed-off-by: Mauricio Faria de Oliveira
> Reported-by: Naresh Bannoth
>
> ---
> v2:
> - also add support for standby state to alua_check_sense(), alua_prep_fn()
> (Bart Van Assche )
>
> drivers/scsi/device_handler/scsi_dh_alua.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c
> b/drivers/scsi/device_handler/scsi_dh_alua.c
> index c01b47e5b55a..a1cf3d6aa853 100644
> --- a/drivers/scsi/device_handler/scsi_dh_alua.c
> +++ b/drivers/scsi/device_handler/scsi_dh_alua.c
> @@ -431,6 +431,26 @@ static int alua_check_sense(struct scsi_device *sdev,
> alua_check(sdev, false);
> return NEEDS_RETRY;
> }
> + if (sense_hdr->asc == 0x04 && sense_hdr->ascq == 0x0b) {
> + /*
> + * LUN Not Accessible - target port in standby state.
> + *
> + * Do not retry, so failover to another target port
> occur.
> + * Schedule a recheck to update state for other
> functions.
> + */
> + alua_check(sdev, true);
> + return SUCCESS;
> + }
> + if (sense_hdr->asc == 0x04 && sense_hdr->ascq == 0x0c) {
> + /*
> + * LUN Not Accessible - target port in unavailable
> state.
> + *
> + * Do not retry, so failover to another target port
> occur.
> + * Schedule a recheck to update state for other
> functions.
> + */
> + alua_check(sdev, true);
> + return SUCCESS;
> + }
> break;
> case UNIT_ATTENTION:
> if (sense_hdr->asc == 0x29 && sense_hdr->ascq == 0x00) {
> @@ -1057,6 +1077,8 @@ static void alua_check(struct scsi_device *sdev, bool
> force)
> *
> * Fail I/O to all paths not in state
> * active/optimized or active/non-optimized.
> + * Allow I/O to paths in state unavailable/standby
> + * so path checkers can actually check them.
> */
> static int alua_prep_fn(struct scsi_device *sdev, struct request *req)
> {
> @@ -1072,6 +1094,9 @@ static int alua_prep_fn(struct scsi_device *sd
Re: [PATCH] sgi-xpc: remove unnecessary static in xpc_setup_msg_structures_uv()
Acked-by: Robin Holt
