This is a note to let you know that I've just added the patch titled
perf trace: Handle unpaired raw_syscalls:sys_exit event
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
perf-trace-handle-unpaired-raw_syscalls-sys_exit-event.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Date: Wed, 29 Mar 2017 16:37:51 -0300
Subject: perf trace: Handle unpaired raw_syscalls:sys_exit event
From: Arnaldo Carvalho de Melo <acme(a)redhat.com>
[ Upstream commit fd2b2975149f5f7099693027cece81b16842964a ]
Which may happen when we start a tracing session and a thread is waiting
for something like "poll" to return, in which case we better print "?"
both for the syscall entry timestamp and for the duration.
E.g.:
Tracing existing mutt session:
# perf trace -p `pidof mutt`
? ( ? ): mutt/17135 ... [continued]: poll()) = 1
0.027 ( 0.013 ms): mutt/17135 read(buf: 0x7ffcb3c42cef, count: 1) = 1
0.047 ( 0.008 ms): mutt/17135 poll(ufds: 0x7ffcb3c42c50, nfds: 1, timeout_msecs: 1000) = 1
0.059 ( 0.008 ms): mutt/17135 read(buf: 0x7ffcb3c42cef, count: 1) = 1
<SNIP>
Before it would print a large number because we'd do:
ttrace->entry_time - trace->base_time
And entry_time would be 0, while base_time would be the timestamp for
the first event 'perf trace' reads, oops.
Cc: Adrian Hunter <adrian.hunter(a)intel.com>
Cc: David Ahern <dsahern(a)gmail.com>
Cc: Jiri Olsa <jolsa(a)kernel.org>
Cc: Luis Claudio Gonçalves <lclaudio(a)redhat.com>
Cc: Namhyung Kim <namhyung(a)kernel.org>
Cc: Wang Nan <wangnan0(a)huawei.com>
Link: http://lkml.kernel.org/n/tip-wbcb93ofva2qdjd5ltn5eeqq@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/builtin-trace.c | 43 ++++++++++++++++++++++++++++++++++---------
1 file changed, 34 insertions(+), 9 deletions(-)
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -822,12 +822,21 @@ struct syscall {
void **arg_parm;
};
-static size_t fprintf_duration(unsigned long t, FILE *fp)
+/*
+ * We need to have this 'calculated' boolean because in some cases we really
+ * don't know what is the duration of a syscall, for instance, when we start
+ * a session and some threads are waiting for a syscall to finish, say 'poll',
+ * in which case all we can do is to print "( ? ) for duration and for the
+ * start timestamp.
+ */
+static size_t fprintf_duration(unsigned long t, bool calculated, FILE *fp)
{
double duration = (double)t / NSEC_PER_MSEC;
size_t printed = fprintf(fp, "(");
- if (duration >= 1.0)
+ if (!calculated)
+ printed += fprintf(fp, " ? ");
+ else if (duration >= 1.0)
printed += color_fprintf(fp, PERF_COLOR_RED, "%6.3f ms", duration);
else if (duration >= 0.01)
printed += color_fprintf(fp, PERF_COLOR_YELLOW, "%6.3f ms", duration);
@@ -1030,13 +1039,27 @@ static bool trace__filter_duration(struc
return t < (trace->duration_filter * NSEC_PER_MSEC);
}
-static size_t trace__fprintf_tstamp(struct trace *trace, u64 tstamp, FILE *fp)
+static size_t __trace__fprintf_tstamp(struct trace *trace, u64 tstamp, FILE *fp)
{
double ts = (double)(tstamp - trace->base_time) / NSEC_PER_MSEC;
return fprintf(fp, "%10.3f ", ts);
}
+/*
+ * We're handling tstamp=0 as an undefined tstamp, i.e. like when we are
+ * using ttrace->entry_time for a thread that receives a sys_exit without
+ * first having received a sys_enter ("poll" issued before tracing session
+ * starts, lost sys_enter exit due to ring buffer overflow).
+ */
+static size_t trace__fprintf_tstamp(struct trace *trace, u64 tstamp, FILE *fp)
+{
+ if (tstamp > 0)
+ return __trace__fprintf_tstamp(trace, tstamp, fp);
+
+ return fprintf(fp, " ? ");
+}
+
static bool done = false;
static bool interrupted = false;
@@ -1047,10 +1070,10 @@ static void sig_handler(int sig)
}
static size_t trace__fprintf_entry_head(struct trace *trace, struct thread *thread,
- u64 duration, u64 tstamp, FILE *fp)
+ u64 duration, bool duration_calculated, u64 tstamp, FILE *fp)
{
size_t printed = trace__fprintf_tstamp(trace, tstamp, fp);
- printed += fprintf_duration(duration, fp);
+ printed += fprintf_duration(duration, duration_calculated, fp);
if (trace->multiple_threads) {
if (trace->show_comm)
@@ -1452,7 +1475,7 @@ static int trace__printf_interrupted_ent
duration = sample->time - ttrace->entry_time;
- printed = trace__fprintf_entry_head(trace, trace->current, duration, ttrace->entry_time, trace->output);
+ printed = trace__fprintf_entry_head(trace, trace->current, duration, true, ttrace->entry_time, trace->output);
printed += fprintf(trace->output, "%-70s) ...\n", ttrace->entry_str);
ttrace->entry_pending = false;
@@ -1499,7 +1522,7 @@ static int trace__sys_enter(struct trace
if (sc->is_exit) {
if (!(trace->duration_filter || trace->summary_only || trace->min_stack)) {
- trace__fprintf_entry_head(trace, thread, 1, ttrace->entry_time, trace->output);
+ trace__fprintf_entry_head(trace, thread, 0, false, ttrace->entry_time, trace->output);
fprintf(trace->output, "%-70s)\n", ttrace->entry_str);
}
} else {
@@ -1547,6 +1570,7 @@ static int trace__sys_exit(struct trace
{
long ret;
u64 duration = 0;
+ bool duration_calculated = false;
struct thread *thread;
int id = perf_evsel__sc_tp_uint(evsel, id, sample), err = -1, callchain_ret = 0;
struct syscall *sc = trace__syscall_info(trace, evsel, id);
@@ -1577,6 +1601,7 @@ static int trace__sys_exit(struct trace
duration = sample->time - ttrace->entry_time;
if (trace__filter_duration(trace, duration))
goto out;
+ duration_calculated = true;
} else if (trace->duration_filter)
goto out;
@@ -1592,7 +1617,7 @@ static int trace__sys_exit(struct trace
if (trace->summary_only)
goto out;
- trace__fprintf_entry_head(trace, thread, duration, ttrace->entry_time, trace->output);
+ trace__fprintf_entry_head(trace, thread, duration, duration_calculated, ttrace->entry_time, trace->output);
if (ttrace->entry_pending) {
fprintf(trace->output, "%-70s", ttrace->entry_str);
@@ -1855,7 +1880,7 @@ static int trace__pgfault(struct trace *
thread__find_addr_location(thread, sample->cpumode, MAP__FUNCTION,
sample->ip, &al);
- trace__fprintf_entry_head(trace, thread, 0, sample->time, trace->output);
+ trace__fprintf_entry_head(trace, thread, 0, true, sample->time, trace->output);
fprintf(trace->output, "%sfault [",
evsel->attr.config == PERF_COUNT_SW_PAGE_FAULTS_MAJ ?
Patches currently in stable-queue which might be from acme(a)redhat.com are
queue-4.9/perf-buildid-do-not-assume-that-readlink-returns-a-null-terminated-string.patch
queue-4.9/perf-session-don-t-rely-on-evlist-in-pipe-mode.patch
queue-4.9/perf-tools-make-perf_event__synthesize_mmap_events-scale.patch
queue-4.9/perf-annotate-fix-a-bug-following-symbolic-link-of-a-build-id-file.patch
queue-4.9/perf-stat-issue-a-hw-watchdog-disable-hint.patch
queue-4.9/perf-sort-fix-segfault-with-basic-block-cycles-sort-dimension.patch
queue-4.9/perf-trace-handle-unpaired-raw_syscalls-sys_exit-event.patch
queue-4.9/perf-probe-fix-concat_probe_trace_events.patch
queue-4.9/perf-inject-copy-events-when-reordering-events-in-pipe-mode.patch
queue-4.9/perf-probe-return-errno-when-not-hitting-any-event.patch
queue-4.9/perf-evsel-return-exact-sub-event-which-failed-with-eperm-for-wildcards.patch
queue-4.9/perf-stat-fix-bug-in-handling-events-in-error-state.patch
This is a note to let you know that I've just added the patch titled
perf tools: Make perf_event__synthesize_mmap_events() scale
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
perf-tools-make-perf_event__synthesize_mmap_events-scale.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Stephane Eranian <eranian(a)google.com>
Date: Wed, 15 Mar 2017 10:17:13 -0700
Subject: perf tools: Make perf_event__synthesize_mmap_events() scale
From: Stephane Eranian <eranian(a)google.com>
[ Upstream commit 88b897a30c525c2eee6e7f16e1e8d0f18830845e ]
This patch significantly improves the execution time of
perf_event__synthesize_mmap_events() when running perf record on systems
where processes have lots of threads.
It just happens that cat /proc/pid/maps support uses a O(N^2) algorithm to
generate each map line in the maps file. If you have 1000 threads, then you
have necessarily 1000 stacks. For each vma, you need to check if it
corresponds to a thread's stack. With a large number of threads, this can take
a very long time. I have seen latencies >> 10mn.
As of today, perf does not use the fact that a mapping is a stack, therefore we
can work around the issue by using /proc/pid/tasks/pid/maps. This entry does
not try to map a vma to stack and is thus much faster with no loss of
functonality.
The proc-map-timeout logic is kept in case users still want some upper limit.
In V2, we fix the file path from /proc/pid/tasks/pid/maps to actual
/proc/pid/task/pid/maps, tasks -> task. Thanks Arnaldo for catching this.
Committer note:
This problem seems to have been elliminated in the kernel since commit :
b18cb64ead40 ("fs/proc: Stop trying to report thread stacks").
Signed-off-by: Stephane Eranian <eranian(a)google.com>
Acked-by: Jiri Olsa <jolsa(a)redhat.com>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Namhyung Kim <namhyung(a)kernel.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Link: http://lkml.kernel.org/r/20170315135059.GC2177@redhat.com
Link: http://lkml.kernel.org/r/1489598233-25586-1-git-send-email-eranian@google.c…
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/util/event.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -255,8 +255,8 @@ int perf_event__synthesize_mmap_events(s
if (machine__is_default_guest(machine))
return 0;
- snprintf(filename, sizeof(filename), "%s/proc/%d/maps",
- machine->root_dir, pid);
+ snprintf(filename, sizeof(filename), "%s/proc/%d/task/%d/maps",
+ machine->root_dir, pid, pid);
fp = fopen(filename, "r");
if (fp == NULL) {
Patches currently in stable-queue which might be from eranian(a)google.com are
queue-4.9/perf-session-don-t-rely-on-evlist-in-pipe-mode.patch
queue-4.9/perf-tools-make-perf_event__synthesize_mmap_events-scale.patch
queue-4.9/perf-inject-copy-events-when-reordering-events-in-pipe-mode.patch
queue-4.9/perf-stat-fix-bug-in-handling-events-in-error-state.patch
This is a note to let you know that I've just added the patch titled
perf stat: Issue a HW watchdog disable hint
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
perf-stat-issue-a-hw-watchdog-disable-hint.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Borislav Petkov <bp(a)suse.de>
Date: Tue, 7 Feb 2017 01:40:05 +0100
Subject: perf stat: Issue a HW watchdog disable hint
From: Borislav Petkov <bp(a)suse.de>
[ Upstream commit 02d492e5dcb72c004d213756eb87c9d62a6d76a7 ]
When using perf stat on an AMD F15h system with the default hw events
attributes, some of the events don't get counted:
Performance counter stats for 'sleep 1':
0.749208 task-clock (msec) # 0.001 CPUs utilized
1 context-switches # 0.001 M/sec
0 cpu-migrations # 0.000 K/sec
54 page-faults # 0.072 M/sec
1,122,815 cycles # 1.499 GHz
286,740 stalled-cycles-frontend # 25.54% frontend cycles idle
<not counted> stalled-cycles-backend (0.00%)
^^^^^^^^^^^^
<not counted> instructions (0.00%)
^^^^^^^^^^^^
<not counted> branches (0.00%)
<not counted> branch-misses (0.00%)
1.001550070 seconds time elapsed
The reason is that we have the HW watchdog consuming one PMU counter and
when perf tries to schedule 6 events on 6 counters and some of those
counters are constrained to only a specific subset of PMCs by the
hardware, the event scheduling fails.
So issue a hint to disable the HW watchdog around a perf stat session.
Committer note:
Testing it...
# perf stat -d usleep 1
Performance counter stats for 'usleep 1':
1.180203 task-clock (msec) # 0.490 CPUs utilized
1 context-switches # 0.847 K/sec
0 cpu-migrations # 0.000 K/sec
54 page-faults # 0.046 M/sec
184,754 cycles # 0.157 GHz
714,553 instructions # 3.87 insn per cycle
154,661 branches # 131.046 M/sec
7,247 branch-misses # 4.69% of all branches
219,984 L1-dcache-loads # 186.395 M/sec
17,600 L1-dcache-load-misses # 8.00% of all L1-dcache hits (90.16%)
<not counted> LLC-loads (0.00%)
<not counted> LLC-load-misses (0.00%)
0.002406823 seconds time elapsed
Some events weren't counted. Try disabling the NMI watchdog:
echo 0 > /proc/sys/kernel/nmi_watchdog
perf stat ...
echo 1 > /proc/sys/kernel/nmi_watchdog
#
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Acked-by: Ingo Molnar <mingo(a)kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Robert Richter <rric(a)kernel.org>
Cc: Vince Weaver <vince(a)deater.net>
Link: http://lkml.kernel.org/r/20170211183218.ijnvb5f7ciyuunx4@pd.tnic
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/builtin-stat.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -146,6 +146,7 @@ static aggr_get_id_t aggr_get_id;
static bool append_file;
static const char *output_name;
static int output_fd;
+static int print_free_counters_hint;
struct perf_stat {
bool record;
@@ -1109,6 +1110,9 @@ static void printout(int id, int nr, str
counter->supported ? CNTR_NOT_COUNTED : CNTR_NOT_SUPPORTED,
csv_sep);
+ if (counter->supported)
+ print_free_counters_hint = 1;
+
fprintf(stat_config.output, "%-*s%s",
csv_output ? 0 : unit_width,
counter->unit, csv_sep);
@@ -1477,6 +1481,13 @@ static void print_footer(void)
avg_stats(&walltime_nsecs_stats));
}
fprintf(output, "\n\n");
+
+ if (print_free_counters_hint)
+ fprintf(output,
+"Some events weren't counted. Try disabling the NMI watchdog:\n"
+" echo 0 > /proc/sys/kernel/nmi_watchdog\n"
+" perf stat ...\n"
+" echo 1 > /proc/sys/kernel/nmi_watchdog\n");
}
static void print_counters(struct timespec *ts, int argc, const char **argv)
Patches currently in stable-queue which might be from bp(a)suse.de are
queue-4.9/x86-mce-handle-broadcasted-mce-gracefully-with-kexec.patch
queue-4.9/perf-stat-issue-a-hw-watchdog-disable-hint.patch
queue-4.9/x86-mm-make-mmap-map_32bit-work-correctly.patch
queue-4.9/edac-altera-fix-peripheral-warnings-for-cyclone5.patch
queue-4.9/kvm-svm-setup-mcg_cap-on-amd-properly.patch
queue-4.9/x86-mce-init-some-cpu-features-early.patch
This is a note to let you know that I've just added the patch titled
perf stat: Fix bug in handling events in error state
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
perf-stat-fix-bug-in-handling-events-in-error-state.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Stephane Eranian <eranian(a)google.com>
Date: Wed, 12 Apr 2017 11:23:01 -0700
Subject: perf stat: Fix bug in handling events in error state
From: Stephane Eranian <eranian(a)google.com>
[ Upstream commit db49a71798a38f3ddf3f3462703328dca39b1ac7 ]
(This is a patch has been sitting in the Intel CQM/CMT driver series for
a while, despite not depend on it. Sending it now independently since
the series is being discarded.)
When an event is in error state, read() returns 0 instead of sizeof()
buffer. In certain modes, such as interval printing, ignoring the 0
return value may cause bogus count deltas to be computed and thus
invalid results printed.
This patch fixes this problem by modifying read_counters() to mark the
event as not scaled (scaled = -1) to force the printout routine to show
<NOT COUNTED>.
Signed-off-by: Stephane Eranian <eranian(a)google.com>
Reviewed-by: David Carrillo-Cisneros <davidcc(a)google.com>
Acked-by: Jiri Olsa <jolsa(a)redhat.com>
Cc: Adrian Hunter <adrian.hunter(a)intel.com>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org>
Cc: Paul Turner <pjt(a)google.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Wang Nan <wangnan0(a)huawei.com>
Link: http://lkml.kernel.org/r/20170412182301.44406-1-davidcc@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/builtin-stat.c | 12 +++++++++---
tools/perf/util/evsel.c | 4 ++--
2 files changed, 11 insertions(+), 5 deletions(-)
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -311,8 +311,12 @@ static int read_counter(struct perf_evse
struct perf_counts_values *count;
count = perf_counts(counter->counts, cpu, thread);
- if (perf_evsel__read(counter, cpu, thread, count))
+ if (perf_evsel__read(counter, cpu, thread, count)) {
+ counter->counts->scaled = -1;
+ perf_counts(counter->counts, cpu, thread)->ena = 0;
+ perf_counts(counter->counts, cpu, thread)->run = 0;
return -1;
+ }
if (STAT_RECORD) {
if (perf_evsel__write_stat_event(counter, cpu, thread, count)) {
@@ -337,12 +341,14 @@ static int read_counter(struct perf_evse
static void read_counters(void)
{
struct perf_evsel *counter;
+ int ret;
evlist__for_each_entry(evsel_list, counter) {
- if (read_counter(counter))
+ ret = read_counter(counter);
+ if (ret)
pr_debug("failed to read counter %s\n", counter->name);
- if (perf_stat_process_counter(&stat_config, counter))
+ if (ret == 0 && perf_stat_process_counter(&stat_config, counter))
pr_warning("failed to process counter %s\n", counter->name);
}
}
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1221,7 +1221,7 @@ int perf_evsel__read(struct perf_evsel *
if (FD(evsel, cpu, thread) < 0)
return -EINVAL;
- if (readn(FD(evsel, cpu, thread), count, sizeof(*count)) < 0)
+ if (readn(FD(evsel, cpu, thread), count, sizeof(*count)) <= 0)
return -errno;
return 0;
@@ -1239,7 +1239,7 @@ int __perf_evsel__read_on_cpu(struct per
if (evsel->counts == NULL && perf_evsel__alloc_counts(evsel, cpu + 1, thread + 1) < 0)
return -ENOMEM;
- if (readn(FD(evsel, cpu, thread), &count, nv * sizeof(u64)) < 0)
+ if (readn(FD(evsel, cpu, thread), &count, nv * sizeof(u64)) <= 0)
return -errno;
perf_evsel__compute_deltas(evsel, cpu, thread, &count);
Patches currently in stable-queue which might be from eranian(a)google.com are
queue-4.9/perf-session-don-t-rely-on-evlist-in-pipe-mode.patch
queue-4.9/perf-tools-make-perf_event__synthesize_mmap_events-scale.patch
queue-4.9/perf-inject-copy-events-when-reordering-events-in-pipe-mode.patch
queue-4.9/perf-stat-fix-bug-in-handling-events-in-error-state.patch
This is a note to let you know that I've just added the patch titled
perf sort: Fix segfault with basic block 'cycles' sort dimension
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
perf-sort-fix-segfault-with-basic-block-cycles-sort-dimension.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Changbin Du <changbin.du(a)intel.com>
Date: Mon, 13 Mar 2017 16:31:48 +0800
Subject: perf sort: Fix segfault with basic block 'cycles' sort dimension
From: Changbin Du <changbin.du(a)intel.com>
[ Upstream commit 4b0b3aa6a2756e6115fdf275c521e4552a7082f3 ]
Skip the sample which doesn't have branch_info to avoid segmentation
fault:
The fault can be reproduced by:
perf record -a
perf report -F cycles
Signed-off-by: Changbin Du <changbin.du(a)intel.com>
Tested-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Fixes: 0e332f033a82 ("perf tools: Add support for cycles, weight branch_info field")
Link: http://lkml.kernel.org/r/20170313083148.23568-1-changbin.du@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/util/sort.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -846,6 +846,9 @@ static int hist_entry__mispredict_snprin
static int64_t
sort__cycles_cmp(struct hist_entry *left, struct hist_entry *right)
{
+ if (!left->branch_info || !right->branch_info)
+ return cmp_null(left->branch_info, right->branch_info);
+
return left->branch_info->flags.cycles -
right->branch_info->flags.cycles;
}
@@ -853,6 +856,8 @@ sort__cycles_cmp(struct hist_entry *left
static int hist_entry__cycles_snprintf(struct hist_entry *he, char *bf,
size_t size, unsigned int width)
{
+ if (!he->branch_info)
+ return scnprintf(bf, size, "%-.*s", width, "N/A");
if (he->branch_info->flags.cycles == 0)
return repsep_snprintf(bf, size, "%-*s", width, "-");
return repsep_snprintf(bf, size, "%-*hd", width,
Patches currently in stable-queue which might be from changbin.du(a)intel.com are
queue-4.9/perf-sort-fix-segfault-with-basic-block-cycles-sort-dimension.patch
This is a note to let you know that I've just added the patch titled
perf session: Don't rely on evlist in pipe mode
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
perf-session-don-t-rely-on-evlist-in-pipe-mode.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: David Carrillo-Cisneros <davidcc(a)google.com>
Date: Mon, 10 Apr 2017 13:14:30 -0700
Subject: perf session: Don't rely on evlist in pipe mode
From: David Carrillo-Cisneros <davidcc(a)google.com>
[ Upstream commit 0973ad97c187e06aece61f685b9c3b2d93290a73 ]
Session sets a number parameters that rely on evlist. These parameters
are not used in pipe-mode and should not be set, since evlist is
unavailable. Fix that.
Signed-off-by: David Carrillo-Cisneros <davidcc(a)google.com>
Acked-by: Jiri Olsa <jolsa(a)kernel.org>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: He Kuang <hekuang(a)huawei.com>
Cc: Masami Hiramatsu <mhiramat(a)kernel.org>
Cc: Paul Turner <pjt(a)google.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Simon Que <sque(a)chromium.org>
Cc: Stephane Eranian <eranian(a)google.com>
Cc: Wang Nan <wangnan0(a)huawei.com>
Link: http://lkml.kernel.org/r/20170410201432.24807-6-davidcc@google.com
[ Check if file != NULL in perf_session__new(), like when used by builtin-top.c ]
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/util/session.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -139,8 +139,14 @@ struct perf_session *perf_session__new(s
if (perf_session__open(session) < 0)
goto out_close;
- perf_session__set_id_hdr_size(session);
- perf_session__set_comm_exec(session);
+ /*
+ * set session attributes that are present in perf.data
+ * but not in pipe-mode.
+ */
+ if (!file->is_pipe) {
+ perf_session__set_id_hdr_size(session);
+ perf_session__set_comm_exec(session);
+ }
}
} else {
session->machines.host.env = &perf_env;
@@ -155,7 +161,11 @@ struct perf_session *perf_session__new(s
pr_warning("Cannot read kernel map\n");
}
- if (tool && tool->ordering_requires_timestamps &&
+ /*
+ * In pipe-mode, evlist is empty until PERF_RECORD_HEADER_ATTR is
+ * processed, so perf_evlist__sample_id_all is not meaningful here.
+ */
+ if ((!file || !file->is_pipe) && tool && tool->ordering_requires_timestamps &&
tool->ordered_events && !perf_evlist__sample_id_all(session->evlist)) {
dump_printf("WARNING: No sample_id_all support, falling back to unordered processing\n");
tool->ordered_events = false;
Patches currently in stable-queue which might be from davidcc(a)google.com are
queue-4.9/perf-session-don-t-rely-on-evlist-in-pipe-mode.patch
queue-4.9/perf-inject-copy-events-when-reordering-events-in-pipe-mode.patch
queue-4.9/perf-stat-fix-bug-in-handling-events-in-error-state.patch
This is a note to let you know that I've just added the patch titled
perf probe: Return errno when not hitting any event
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
perf-probe-return-errno-when-not-hitting-any-event.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Kefeng Wang <wangkefeng.wang(a)huawei.com>
Date: Fri, 17 Mar 2017 16:16:32 +0800
Subject: perf probe: Return errno when not hitting any event
From: Kefeng Wang <wangkefeng.wang(a)huawei.com>
[ Upstream commit 70946723eeb859466f026274b29c6196e39149c4 ]
On old perf, when using 'perf probe -d' to delete an inexistent event,
it returns errno, eg,
-bash-4.3# perf probe -d xxx || echo $?
Info: Event "*:xxx" does not exist.
Error: Failed to delete events.
255
But now perf_del_probe_events() will always set ret = 0, different from
previous del_perf_probe_events(). After this, it returns errno again,
eg,
-bash-4.3# ./perf probe -d xxx || echo $?
"xxx" does not hit any event.
Error: Failed to delete events.
254
And it is more appropriate to return -ENOENT instead of -EPERM.
Signed-off-by: Kefeng Wang <wangkefeng.wang(a)huawei.com>
Acked-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Cc: Hanjun Guo <guohanjun(a)huawei.com>
Cc: Jiri Olsa <jolsa(a)kernel.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Wang Nan <wangnan0(a)huawei.com>
Fixes: dddc7ee32fa1 ("perf probe: Fix an error when deleting probes successfully")
Link: http://lkml.kernel.org/r/1489738592-61011-1-git-send-email-wangkefeng.wang@…
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/builtin-probe.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -442,9 +442,9 @@ static int perf_del_probe_events(struct
}
if (ret == -ENOENT && ret2 == -ENOENT)
- pr_debug("\"%s\" does not hit any event.\n", str);
- /* Note that this is silently ignored */
- ret = 0;
+ pr_warning("\"%s\" does not hit any event.\n", str);
+ else
+ ret = 0;
error:
if (kfd >= 0)
Patches currently in stable-queue which might be from wangkefeng.wang(a)huawei.com are
queue-4.9/perf-probe-return-errno-when-not-hitting-any-event.patch
This is a note to let you know that I've just added the patch titled
perf probe: Fix concat_probe_trace_events
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
perf-probe-fix-concat_probe_trace_events.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Ravi Bangoria <ravi.bangoria(a)linux.vnet.ibm.com>
Date: Wed, 8 Mar 2017 12:29:07 +0530
Subject: perf probe: Fix concat_probe_trace_events
From: Ravi Bangoria <ravi.bangoria(a)linux.vnet.ibm.com>
[ Upstream commit f0a30dca5f84fe8048271799b56677ac2279de66 ]
'*ntevs' contains number of elements present in 'tevs' array. If there
are no elements in array, 'tevs2' can be directly assigned to 'tevs'
without allocating more space. So the condition should be '*ntevs == 0'
not 'ntevs == 0'.
Signed-off-by: Ravi Bangoria <ravi.bangoria(a)linux.vnet.ibm.com>
Acked-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Fixes: 42bba263eb58 ("perf probe: Allow wildcard for cached events")
Link: http://lkml.kernel.org/r/20170308065908.4128-1-ravi.bangoria@linux.vnet.ibm…
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/util/probe-event.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -3060,7 +3060,7 @@ concat_probe_trace_events(struct probe_t
struct probe_trace_event *new_tevs;
int ret = 0;
- if (ntevs == 0) {
+ if (*ntevs == 0) {
*tevs = *tevs2;
*ntevs = ntevs2;
*tevs2 = NULL;
Patches currently in stable-queue which might be from ravi.bangoria(a)linux.vnet.ibm.com are
queue-4.9/perf-probe-fix-concat_probe_trace_events.patch
This is a note to let you know that I've just added the patch titled
perf inject: Copy events when reordering events in pipe mode
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
perf-inject-copy-events-when-reordering-events-in-pipe-mode.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: David Carrillo-Cisneros <davidcc(a)google.com>
Date: Mon, 10 Apr 2017 13:14:27 -0700
Subject: perf inject: Copy events when reordering events in pipe mode
From: David Carrillo-Cisneros <davidcc(a)google.com>
[ Upstream commit 1e0d4f0200e4dbdfc38d818f329d8a0955f7c6f5 ]
__perf_session__process_pipe_events reuses the same memory buffer to
process all events in the pipe.
When reordering is needed (e.g. -b option), events are not immediately
flushed, but kept around until reordering is possible, causing
memory corruption.
The problem is usually observed by a "Unknown sample error" output. It
can easily be reproduced by:
perf record -o - noploop | perf inject -b > output
Committer testing:
Before:
$ perf record -o - stress -t 2 -c 2 | perf inject -b > /dev/null
stress: info: [8297] dispatching hogs: 2 cpu, 0 io, 0 vm, 0 hdd
stress: info: [8297] successful run completed in 2s
[ perf record: Woken up 3 times to write data ]
[ perf record: Captured and wrote 0.000 MB - ]
Warning:
Found 1 unknown events!
Is this an older tool processing a perf.data file generated by a more recent tool?
If that is not the case, consider reporting to linux-kernel(a)vger.kernel.org.
$
After:
$ perf record -o - stress -t 2 -c 2 | perf inject -b > /dev/null
stress: info: [9027] dispatching hogs: 2 cpu, 0 io, 0 vm, 0 hdd
stress: info: [9027] successful run completed in 2s
[ perf record: Woken up 3 times to write data ]
[ perf record: Captured and wrote 0.000 MB - ]
no symbols found in /usr/bin/stress, maybe install a debug package?
no symbols found in /usr/bin/stress, maybe install a debug package?
$
Signed-off-by: David Carrillo-Cisneros <davidcc(a)google.com>
Tested-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Acked-by: Jiri Olsa <jolsa(a)kernel.org>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: He Kuang <hekuang(a)huawei.com>
Cc: Masami Hiramatsu <mhiramat(a)kernel.org>
Cc: Paul Turner <pjt(a)google.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Simon Que <sque(a)chromium.org>
Cc: Stephane Eranian <eranian(a)google.com>
Cc: Wang Nan <wangnan0(a)huawei.com>
Link: http://lkml.kernel.org/r/20170410201432.24807-3-davidcc@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/util/ordered-events.c | 3 ++-
tools/perf/util/session.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
--- a/tools/perf/util/ordered-events.c
+++ b/tools/perf/util/ordered-events.c
@@ -79,7 +79,7 @@ static union perf_event *dup_event(struc
static void free_dup_event(struct ordered_events *oe, union perf_event *event)
{
- if (oe->copy_on_queue) {
+ if (event && oe->copy_on_queue) {
oe->cur_alloc_size -= event->header.size;
free(event);
}
@@ -150,6 +150,7 @@ void ordered_events__delete(struct order
list_move(&event->list, &oe->cache);
oe->nr_events--;
free_dup_event(oe, event->event);
+ event->event = NULL;
}
int ordered_events__queue(struct ordered_events *oe, union perf_event *event,
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1628,6 +1628,7 @@ static int __perf_session__process_pipe_
buf = malloc(cur_size);
if (!buf)
return -errno;
+ ordered_events__set_copy_on_queue(oe, true);
more:
event = buf;
err = readn(fd, event, sizeof(struct perf_event_header));
Patches currently in stable-queue which might be from davidcc(a)google.com are
queue-4.9/perf-session-don-t-rely-on-evlist-in-pipe-mode.patch
queue-4.9/perf-inject-copy-events-when-reordering-events-in-pipe-mode.patch
queue-4.9/perf-stat-fix-bug-in-handling-events-in-error-state.patch
This is a note to let you know that I've just added the patch titled
perf evsel: Return exact sub event which failed with EPERM for wildcards
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
perf-evsel-return-exact-sub-event-which-failed-with-eperm-for-wildcards.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Jin Yao <yao.jin(a)linux.intel.com>
Date: Fri, 7 Apr 2017 20:08:52 +0800
Subject: perf evsel: Return exact sub event which failed with EPERM for wildcards
From: Jin Yao <yao.jin(a)linux.intel.com>
[ Upstream commit 32ccb130f5325abc81b32b1a538390f46e4860f6 ]
The kernel has a special check for a specific irq_vectors trace event.
TRACE_EVENT_PERF_PERM(irq_work_exit,
is_sampling_event(p_event) ? -EPERM : 0);
The perf-record fails for this irq_vectors event when it is present,
like when using a wildcard:
root@skl:/tmp# perf record -a -e irq_vectors:* sleep 2
Error:
You may not have permission to collect system-wide stats.
Consider tweaking /proc/sys/kernel/perf_event_paranoid,
which controls use of the performance events system by
unprivileged users (without CAP_SYS_ADMIN).
The current value is 2:
-1: Allow use of (almost) all events by all users
>= 0: Disallow raw tracepoint access by users without CAP_IOC_LOCK
>= 1: Disallow CPU event access by users without CAP_SYS_ADMIN
>= 2: Disallow kernel profiling by users without CAP_SYS_ADMIN
To make this setting permanent, edit /etc/sysctl.conf too, e.g.:
kernel.perf_event_paranoid = -1
This patch prints out the exact sub event that failed with EPERM for
wildcards to help in understanding what went wrong when this event is
present:
After the patch:
root@skl:/tmp# perf record -a -e irq_vectors:* sleep 2
Error:
No permission to enable irq_vectors:irq_work_exit event.
You may not have permission to collect system-wide stats.
......
Committer notes:
So we have a lot of irq_vectors events:
[root@jouet ~]# perf list irq_vectors:*
List of pre-defined events (to be used in -e):
irq_vectors:call_function_entry [Tracepoint event]
irq_vectors:call_function_exit [Tracepoint event]
irq_vectors:call_function_single_entry [Tracepoint event]
irq_vectors:call_function_single_exit [Tracepoint event]
irq_vectors:deferred_error_apic_entry [Tracepoint event]
irq_vectors:deferred_error_apic_exit [Tracepoint event]
irq_vectors:error_apic_entry [Tracepoint event]
irq_vectors:error_apic_exit [Tracepoint event]
irq_vectors:irq_work_entry [Tracepoint event]
irq_vectors:irq_work_exit [Tracepoint event]
irq_vectors:local_timer_entry [Tracepoint event]
irq_vectors:local_timer_exit [Tracepoint event]
irq_vectors:reschedule_entry [Tracepoint event]
irq_vectors:reschedule_exit [Tracepoint event]
irq_vectors:spurious_apic_entry [Tracepoint event]
irq_vectors:spurious_apic_exit [Tracepoint event]
irq_vectors:thermal_apic_entry [Tracepoint event]
irq_vectors:thermal_apic_exit [Tracepoint event]
irq_vectors:threshold_apic_entry [Tracepoint event]
irq_vectors:threshold_apic_exit [Tracepoint event]
irq_vectors:x86_platform_ipi_entry [Tracepoint event]
irq_vectors:x86_platform_ipi_exit [Tracepoint event]
#
And some may be sampled:
[root@jouet ~]# perf record -e irq_vectors:local* sleep 20s
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.020 MB perf.data (2 samples) ]
[root@jouet ~]# perf report -D | egrep 'stats:|events:'
Aggregated stats:
TOTAL events: 155
MMAP events: 144
COMM events: 2
EXIT events: 1
SAMPLE events: 2
MMAP2 events: 4
FINISHED_ROUND events: 1
TIME_CONV events: 1
irq_vectors:local_timer_entry stats:
TOTAL events: 1
SAMPLE events: 1
irq_vectors:local_timer_exit stats:
TOTAL events: 1
SAMPLE events: 1
[root@jouet ~]#
But, as shown in the tracepoint definition at the start of this message,
some, like "irq_vectors:irq_work_exit", may not be sampled, just counted,
i.e. if we try to sample, as when using 'perf record', we get an error:
[root@jouet ~]# perf record -e irq_vectors:irq_work_exit
Error:
You may not have permission to collect system-wide stats.
Consider tweaking /proc/sys/kernel/perf_event_paranoid,
<SNIP>
The error message is misleading, this patch will help in pointing out
what is the event causing such an error, but the error message needs
improvement, i.e. we need to figure out a way to check if a tracepoint
is counting only, like this one, when all we can do is to count it with
'perf stat', at most printing the delta using interval printing, as in:
[root@jouet ~]# perf stat -I 5000 -e irq_vectors:irq_work_*
# time counts unit events
5.000168871 0 irq_vectors:irq_work_entry
5.000168871 0 irq_vectors:irq_work_exit
10.000676730 0 irq_vectors:irq_work_entry
10.000676730 0 irq_vectors:irq_work_exit
15.001122415 0 irq_vectors:irq_work_entry
15.001122415 0 irq_vectors:irq_work_exit
20.001298051 0 irq_vectors:irq_work_entry
20.001298051 0 irq_vectors:irq_work_exit
25.001485020 1 irq_vectors:irq_work_entry
25.001485020 1 irq_vectors:irq_work_exit
30.001658706 0 irq_vectors:irq_work_entry
30.001658706 0 irq_vectors:irq_work_exit
^C 32.045711878 0 irq_vectors:irq_work_entry
32.045711878 0 irq_vectors:irq_work_exit
[root@jouet ~]#
But at least, when we use a wildcard, this patch helps a bit.
Signed-off-by: Yao Jin <yao.jin(a)linux.intel.com>
Tested-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: Jiri Olsa <jolsa(a)kernel.org>
Cc: Kan Liang <kan.liang(a)intel.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Link: http://lkml.kernel.org/r/1491566932-503-1-git-send-email-yao.jin@linux.inte…
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/util/evsel.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -2400,11 +2400,17 @@ int perf_evsel__open_strerror(struct per
int err, char *msg, size_t size)
{
char sbuf[STRERR_BUFSIZE];
+ int printed = 0;
switch (err) {
case EPERM:
case EACCES:
- return scnprintf(msg, size,
+ if (err == EPERM)
+ printed = scnprintf(msg, size,
+ "No permission to enable %s event.\n\n",
+ perf_evsel__name(evsel));
+
+ return scnprintf(msg + printed, size - printed,
"You may not have permission to collect %sstats.\n\n"
"Consider tweaking /proc/sys/kernel/perf_event_paranoid,\n"
"which controls use of the performance events system by\n"
Patches currently in stable-queue which might be from yao.jin(a)linux.intel.com are
queue-4.9/perf-evsel-return-exact-sub-event-which-failed-with-eperm-for-wildcards.patch
This is a note to let you know that I've just added the patch titled
perf buildid: Do not assume that readlink() returns a null terminated string
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
perf-buildid-do-not-assume-that-readlink-returns-a-null-terminated-string.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Tommi Rantala <tommi.t.rantala(a)nokia.com>
Date: Wed, 22 Mar 2017 15:06:20 +0200
Subject: perf buildid: Do not assume that readlink() returns a null terminated string
From: Tommi Rantala <tommi.t.rantala(a)nokia.com>
[ Upstream commit 5a2342111c68e623e27ee7ea3d0492d8dad6bda0 ]
Valgrind was complaining:
$ valgrind ./perf list >/dev/null
==11643== Memcheck, a memory error detector
==11643== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==11643== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==11643== Command: ./perf list
==11643==
==11643== Conditional jump or move depends on uninitialised value(s)
==11643== at 0x4C30620: rindex (vg_replace_strmem.c:199)
==11643== by 0x49DAA9: build_id_cache__origname (build-id.c:198)
==11643== by 0x49E1C7: build_id_cache__valid_id (build-id.c:222)
==11643== by 0x49E1C7: build_id_cache__list_all (build-id.c:507)
==11643== by 0x4B9C8F: print_sdt_events (parse-events.c:2067)
==11643== by 0x4BB0B3: print_events (parse-events.c:2313)
==11643== by 0x439501: cmd_list (builtin-list.c:53)
==11643== by 0x497150: run_builtin (perf.c:359)
==11643== by 0x428CE0: handle_internal_command (perf.c:421)
==11643== by 0x428CE0: run_argv (perf.c:467)
==11643== by 0x428CE0: main (perf.c:614)
[...]
Additionally, a zero length result from readlink() is not very interesting.
Signed-off-by: Tommi Rantala <tommi.t.rantala(a)nokia.com>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Link: http://lkml.kernel.org/r/20170322130624.21881-3-tommi.t.rantala@nokia.com
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/util/build-id.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/tools/perf/util/build-id.c
+++ b/tools/perf/util/build-id.c
@@ -182,13 +182,17 @@ char *build_id_cache__origname(const cha
char buf[PATH_MAX];
char *ret = NULL, *p;
size_t offs = 5; /* == strlen("../..") */
+ ssize_t len;
linkname = build_id_cache__linkname(sbuild_id, NULL, 0);
if (!linkname)
return NULL;
- if (readlink(linkname, buf, PATH_MAX) < 0)
+ len = readlink(linkname, buf, sizeof(buf) - 1);
+ if (len <= 0)
goto out;
+ buf[len] = '\0';
+
/* The link should be "../..<origpath>/<sbuild_id>" */
p = strrchr(buf, '/'); /* Cut off the "/<sbuild_id>" */
if (p && (p > buf + offs)) {
Patches currently in stable-queue which might be from tommi.t.rantala(a)nokia.com are
queue-4.9/perf-buildid-do-not-assume-that-readlink-returns-a-null-terminated-string.patch
This is a note to let you know that I've just added the patch titled
perf annotate: Fix a bug following symbolic link of a build-id file
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
perf-annotate-fix-a-bug-following-symbolic-link-of-a-build-id-file.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Taeung Song <treeze.taeung(a)gmail.com>
Date: Mon, 27 Mar 2017 16:10:36 +0900
Subject: perf annotate: Fix a bug following symbolic link of a build-id file
From: Taeung Song <treeze.taeung(a)gmail.com>
[ Upstream commit 6ebd2547dd24daf95a21b2bc59931de8502afcc3 ]
It is wrong way to read link name from a build-id file. Because a
build-id file is not anymore a symbolic link but build-id directory of
it is symbolic link, so fix it.
For example, if build-id file name gotten from
dso__build_id_filename() is as below,
/root/.debug/.build-id/4f/75c7d197c951659d1c1b8b5fd49bcdf8f3f8b1/elf
To correctly read link name of build-id, use the build-id dir path that
is a symbolic link, instead of the above build-id file name like below.
/root/.debug/.build-id/4f/75c7d197c951659d1c1b8b5fd49bcdf8f3f8b1
Signed-off-by: Taeung Song <treeze.taeung(a)gmail.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Masami Hiramatsu <mhiramat(a)kernel.org>
Cc: Namhyung Kim <namhyung(a)kernel.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Wang Nan <wangnan0(a)huawei.com>
Link: http://lkml.kernel.org/r/1490598638-13947-2-git-send-email-treeze.taeung@gm…
Fixes: 01412261d994 ("perf buildid-cache: Use path/to/bin/buildid/elf instead of path/to/bin/buildid")
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/util/annotate.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1250,6 +1250,7 @@ static int dso__disassemble_filename(str
{
char linkname[PATH_MAX];
char *build_id_filename;
+ char *build_id_path = NULL;
if (dso->symtab_type == DSO_BINARY_TYPE__KALLSYMS &&
!dso__is_kcore(dso))
@@ -1265,8 +1266,14 @@ static int dso__disassemble_filename(str
goto fallback;
}
+ build_id_path = strdup(filename);
+ if (!build_id_path)
+ return -1;
+
+ dirname(build_id_path);
+
if (dso__is_kcore(dso) ||
- readlink(filename, linkname, sizeof(linkname)) < 0 ||
+ readlink(build_id_path, linkname, sizeof(linkname)) < 0 ||
strstr(linkname, DSO__NAME_KALLSYMS) ||
access(filename, R_OK)) {
fallback:
@@ -1278,6 +1285,7 @@ fallback:
__symbol__join_symfs(filename, filename_size, dso->long_name);
}
+ free(build_id_path);
return 0;
}
Patches currently in stable-queue which might be from treeze.taeung(a)gmail.com are
queue-4.9/perf-annotate-fix-a-bug-following-symbolic-link-of-a-build-id-file.patch
This is a note to let you know that I've just added the patch titled
PCI/MSI: Stop disabling MSI/MSI-X in pci_device_shutdown()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pci-msi-stop-disabling-msi-msi-x-in-pci_device_shutdown.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Prarit Bhargava <prarit(a)redhat.com>
Date: Thu, 26 Jan 2017 14:07:47 -0500
Subject: PCI/MSI: Stop disabling MSI/MSI-X in pci_device_shutdown()
From: Prarit Bhargava <prarit(a)redhat.com>
[ Upstream commit fda78d7a0ead144f4b2cdb582dcba47911f4952c ]
The pci_bus_type .shutdown method, pci_device_shutdown(), is called from
device_shutdown() in the kernel restart and shutdown paths.
Previously, pci_device_shutdown() called pci_msi_shutdown() and
pci_msix_shutdown(). This disables MSI and MSI-X, which causes the device
to fall back to raising interrupts via INTx. But the driver is still bound
to the device, it doesn't know about this change, and it likely doesn't
have an INTx handler, so these INTx interrupts cause "nobody cared"
warnings like this:
irq 16: nobody cared (try booting with the "irqpoll" option)
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.2-1.el7_UNSUPPORTED.x86_64 #1
Hardware name: Hewlett-Packard HP Z820 Workstation/158B, BIOS J63 v03.90 06/
...
The MSI disabling code was added by d52877c7b1af ("pci/irq: let
pci_device_shutdown to call pci_msi_shutdown v2") because a driver left MSI
enabled and kdump failed because the kexeced kernel wasn't prepared to
receive the MSI interrupts.
Subsequent commits 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even
if kernel doesn't support MSI") and e80e7edc55ba ("PCI/MSI: Initialize MSI
capability for all architectures") changed the kexeced kernel to disable
all MSIs itself so it no longer depends on the crashed kernel to clean up
after itself.
Stop disabling MSI/MSI-X in pci_device_shutdown(). This resolves the
"nobody cared" unhandled IRQ issue above. It also allows PCI serial
devices, which may rely on the MSI interrupts, to continue outputting
messages during reboot/shutdown.
[bhelgaas: changelog, drop pci_msi_shutdown() and pci_msix_shutdown() calls
altogether]
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=187351
Signed-off-by: Prarit Bhargava <prarit(a)redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
CC: Alex Williamson <alex.williamson(a)redhat.com>
CC: David Arcari <darcari(a)redhat.com>
CC: Myron Stowe <mstowe(a)redhat.com>
CC: Lukas Wunner <lukas(a)wunner.de>
CC: Keith Busch <keith.busch(a)intel.com>
CC: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/pci-driver.c | 2 --
1 file changed, 2 deletions(-)
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -463,8 +463,6 @@ static void pci_device_shutdown(struct d
if (drv && drv->shutdown)
drv->shutdown(pci_dev);
- pci_msi_shutdown(pci_dev);
- pci_msix_shutdown(pci_dev);
/*
* If this is a kexec reboot, turn off Bus Master bit on the
Patches currently in stable-queue which might be from prarit(a)redhat.com are
queue-4.9/pci-msi-stop-disabling-msi-msi-x-in-pci_device_shutdown.patch
This is a note to let you know that I've just added the patch titled
PCI: hv: Properly handle PCI bus remove
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pci-hv-properly-handle-pci-bus-remove.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Long Li <longli(a)microsoft.com>
Date: Thu, 23 Mar 2017 14:58:10 -0700
Subject: PCI: hv: Properly handle PCI bus remove
From: Long Li <longli(a)microsoft.com>
[ Upstream commit d3a78d8bf759d8848339dcc367c4c1678b57a08b ]
hv_pci_devices_present() is called in hv_pci_remove() when we remove a PCI
device from the host, e.g., by disabling SR-IOV on a device. In
hv_pci_remove(), the bus is already removed before the call, so we don't
need to rescan the bus in the workqueue scheduled from
hv_pci_devices_present().
By introducing bus state hv_pcibus_removed, we can avoid this situation.
Reported-by: Xiaofeng Wang <xiaofwan(a)redhat.com>
Signed-off-by: Long Li <longli(a)microsoft.com>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
Acked-by: K. Y. Srinivasan <kys(a)microsoft.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/host/pci-hyperv.c | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -351,6 +351,7 @@ enum hv_pcibus_state {
hv_pcibus_init = 0,
hv_pcibus_probed,
hv_pcibus_installed,
+ hv_pcibus_removed,
hv_pcibus_maximum
};
@@ -1489,13 +1490,24 @@ static void pci_devices_present_work(str
put_pcichild(hpdev, hv_pcidev_ref_initial);
}
- /* Tell the core to rescan bus because there may have been changes. */
- if (hbus->state == hv_pcibus_installed) {
+ switch(hbus->state) {
+ case hv_pcibus_installed:
+ /*
+ * Tell the core to rescan bus
+ * because there may have been changes.
+ */
pci_lock_rescan_remove();
pci_scan_child_bus(hbus->pci_bus);
pci_unlock_rescan_remove();
- } else {
+ break;
+
+ case hv_pcibus_init:
+ case hv_pcibus_probed:
survey_child_resources(hbus);
+ break;
+
+ default:
+ break;
}
up(&hbus->enum_sem);
@@ -2170,6 +2182,7 @@ static int hv_pci_probe(struct hv_device
hbus = kzalloc(sizeof(*hbus), GFP_KERNEL);
if (!hbus)
return -ENOMEM;
+ hbus->state = hv_pcibus_init;
/*
* The PCI bus "domain" is what is called "segment" in ACPI and
@@ -2312,6 +2325,7 @@ static int hv_pci_remove(struct hv_devic
pci_stop_root_bus(hbus->pci_bus);
pci_remove_root_bus(hbus->pci_bus);
pci_unlock_rescan_remove();
+ hbus->state = hv_pcibus_removed;
}
ret = hv_send_resources_released(hdev);
Patches currently in stable-queue which might be from longli(a)microsoft.com are
queue-4.9/pci-hv-lock-pci-bus-on-device-eject.patch
queue-4.9/pci-hv-properly-handle-pci-bus-remove.patch
This is a note to let you know that I've just added the patch titled
PCI: hv: Lock PCI bus on device eject
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pci-hv-lock-pci-bus-on-device-eject.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Long Li <longli(a)microsoft.com>
Date: Thu, 23 Mar 2017 14:58:32 -0700
Subject: PCI: hv: Lock PCI bus on device eject
From: Long Li <longli(a)microsoft.com>
[ Upstream commit 414428c5da1c71986727c2fa5cdf1ed071e398d7 ]
A PCI_EJECT message can arrive at the same time we are calling
pci_scan_child_bus() in the workqueue for the previous PCI_BUS_RELATIONS
message or in create_root_hv_pci_bus(). In this case we could potentially
modify the bus from multiple places.
Properly lock the bus access.
Thanks Dexuan Cui <decui(a)microsoft.com> for pointing out the race condition
in create_root_hv_pci_bus().
Reported-by: Xiaofeng Wang <xiaofwan(a)redhat.com>
Signed-off-by: Long Li <longli(a)microsoft.com>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
Acked-by: K. Y. Srinivasan <kys(a)microsoft.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/host/pci-hyperv.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -1206,9 +1206,11 @@ static int create_root_hv_pci_bus(struct
hbus->pci_bus->msi = &hbus->msi_chip;
hbus->pci_bus->msi->dev = &hbus->hdev->device;
+ pci_lock_rescan_remove();
pci_scan_child_bus(hbus->pci_bus);
pci_bus_assign_resources(hbus->pci_bus);
pci_bus_add_devices(hbus->pci_bus);
+ pci_unlock_rescan_remove();
hbus->state = hv_pcibus_installed;
return 0;
}
@@ -1597,8 +1599,10 @@ static void hv_eject_device_work(struct
pdev = pci_get_domain_bus_and_slot(hpdev->hbus->sysdata.domain, 0,
wslot);
if (pdev) {
+ pci_lock_rescan_remove();
pci_stop_and_remove_bus_device(pdev);
pci_dev_put(pdev);
+ pci_unlock_rescan_remove();
}
memset(&ctxt, 0, sizeof(ctxt));
Patches currently in stable-queue which might be from longli(a)microsoft.com are
queue-4.9/pci-hv-lock-pci-bus-on-device-eject.patch
queue-4.9/pci-hv-properly-handle-pci-bus-remove.patch
This is a note to let you know that I've just added the patch titled
PCI: Apply Cavium ACS quirk only to CN81xx/CN83xx/CN88xx devices
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pci-apply-cavium-acs-quirk-only-to-cn81xx-cn83xx-cn88xx-devices.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Manish Jaggi <mjaggi(a)caviumnetworks.com>
Date: Thu, 30 Mar 2017 18:47:14 -0500
Subject: PCI: Apply Cavium ACS quirk only to CN81xx/CN83xx/CN88xx devices
From: Manish Jaggi <mjaggi(a)caviumnetworks.com>
[ Upstream commit b77d537d00d08fcf0bf641cd3491dd7df0ad1475 ]
Only apply the Cavium ACS quirk to devices with ID in the range
0xa000-0xa0ff. These are the on-chip PCI devices for CN81xx/CN83xx/CN88xx.
Fixes: b404bcfbf035 ("PCI: Add ACS quirk for all Cavium devices")
Reported-by: Alex Williamson <alex.williamson(a)redhat.com>
Signed-off-by: Manish Jaggi <mjaggi(a)cavium.com>
Acked-by: David Daney <david.daney(a)cavium.com>
Acked-by: Alex Williamson <alex.williamson(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/quirks.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4104,6 +4104,9 @@ static int pci_quirk_cavium_acs(struct p
*/
acs_flags &= ~(PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_SV | PCI_ACS_UF);
+ if (!((dev->device >= 0xa000) && (dev->device <= 0xa0ff)))
+ return -ENOTTY;
+
return acs_flags ? 0 : 1;
}
Patches currently in stable-queue which might be from mjaggi(a)caviumnetworks.com are
queue-4.9/pci-apply-cavium-acs-quirk-only-to-cn81xx-cn83xx-cn88xx-devices.patch
This is a note to let you know that I've just added the patch titled
omapfb: dss: Handle return errors in dss_init_ports()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
omapfb-dss-handle-return-errors-in-dss_init_ports.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Date: Mon, 20 Mar 2017 18:30:59 +0100
Subject: omapfb: dss: Handle return errors in dss_init_ports()
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
[ Upstream commit 0348aaa34412e24ebe622a2b1b013e68d6ae5412 ]
dss_init_ports() is not handling return errors from dpi_init_port() and
sdi_init_port(). It is also always returning 0 currently which results in
part of error handling code in dss_bind() being unused.
Fix dss_init_ports() to handle return errors from dpi_init_port() and
sdi_init_port().
Signed-off-by: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Cc: tomi.valkeinen(a)ti.com
[b.zolnierkie: fail early on errors, minor fixups]
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/video/fbdev/omap2/omapfb/dss/dss.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
@@ -941,11 +941,13 @@ static int dss_init_features(struct plat
return 0;
}
+static void dss_uninit_ports(struct platform_device *pdev);
+
static int dss_init_ports(struct platform_device *pdev)
{
struct device_node *parent = pdev->dev.of_node;
struct device_node *port;
- int r;
+ int r, ret = 0;
if (parent == NULL)
return 0;
@@ -972,17 +974,21 @@ static int dss_init_ports(struct platfor
switch (port_type) {
case OMAP_DISPLAY_TYPE_DPI:
- dpi_init_port(pdev, port);
+ ret = dpi_init_port(pdev, port);
break;
case OMAP_DISPLAY_TYPE_SDI:
- sdi_init_port(pdev, port);
+ ret = sdi_init_port(pdev, port);
break;
default:
break;
}
- } while ((port = omapdss_of_get_next_port(parent, port)) != NULL);
+ } while (!ret &&
+ (port = omapdss_of_get_next_port(parent, port)) != NULL);
- return 0;
+ if (ret)
+ dss_uninit_ports(pdev);
+
+ return ret;
}
static void dss_uninit_ports(struct platform_device *pdev)
Patches currently in stable-queue which might be from arvind.yadav.cs(a)gmail.com are
queue-4.9/omapfb-dss-handle-return-errors-in-dss_init_ports.patch
This is a note to let you know that I've just added the patch titled
of: fix of_device_get_modalias returned length when truncating buffers
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
of-fix-of_device_get_modalias-returned-length-when-truncating-buffers.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Rob Herring <robh(a)kernel.org>
Date: Mon, 16 Jan 2017 14:28:39 -0600
Subject: of: fix of_device_get_modalias returned length when truncating buffers
From: Rob Herring <robh(a)kernel.org>
[ Upstream commit bcf54d5385abaea9c8026aae6f4eeb348671a52d ]
If the length of the modalias is greater than the buffer size, then the
modalias is truncated. However the untruncated length is returned which
will cause an error. Fix this to return the truncated length. If an error
in the case was desired, then then we should just return -ENOMEM.
The reality is no device will ever have 4KB of compatible strings to hit
this case.
Signed-off-by: Rob Herring <robh(a)kernel.org>
Cc: Frank Rowand <frowand.list(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/of/device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -223,7 +223,7 @@ ssize_t of_device_get_modalias(struct de
str[i] = '_';
}
- return tsize;
+ return repend;
}
EXPORT_SYMBOL_GPL(of_device_get_modalias);
Patches currently in stable-queue which might be from robh(a)kernel.org are
queue-4.9/of-fix-of_device_get_modalias-returned-length-when-truncating-buffers.patch
This is a note to let you know that I've just added the patch titled
NFC: pn533: change order of free_irq and dev unregistration
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
nfc-pn533-change-order-of-free_irq-and-dev-unregistration.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Andrey Rusalin <arusalin(a)dev.rtsoft.ru>
Date: Wed, 28 Dec 2016 20:10:57 +0300
Subject: NFC: pn533: change order of free_irq and dev unregistration
From: Andrey Rusalin <arusalin(a)dev.rtsoft.ru>
[ Upstream commit 068a496c4525c638ffab56449d905b88ef97fe32 ]
Change order of free_irq and dev unregistration.
It fixes situation when device already unregistered and
an interrupt happens and nobody can handle it.
Signed-off-by: Andrey Rusalin <arusalin(a)dev.rtsoft.ru>
Signed-off-by: Samuel Ortiz <sameo(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/nfc/pn533/i2c.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/nfc/pn533/i2c.c
+++ b/drivers/nfc/pn533/i2c.c
@@ -242,10 +242,10 @@ static int pn533_i2c_remove(struct i2c_c
dev_dbg(&client->dev, "%s\n", __func__);
- pn533_unregister_device(phy->priv);
-
free_irq(client->irq, phy);
+ pn533_unregister_device(phy->priv);
+
return 0;
}
Patches currently in stable-queue which might be from arusalin(a)dev.rtsoft.ru are
queue-4.9/nfc-pn533-change-order-of-free_irq-and-dev-unregistration.patch
This is a note to let you know that I've just added the patch titled
NFC: nfcmrvl: Include unaligned.h instead of access_ok.h
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
nfc-nfcmrvl-include-unaligned.h-instead-of-access_ok.h.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Tobias Klauser <tklauser(a)distanz.ch>
Date: Wed, 26 Oct 2016 11:00:12 +0200
Subject: NFC: nfcmrvl: Include unaligned.h instead of access_ok.h
From: Tobias Klauser <tklauser(a)distanz.ch>
[ Upstream commit d916d923724d59cde99ee588f15eec59dd863bbd ]
Including linux/unaligned/access_ok.h causes the allmodconfig build on
ia64 (and maybe others) to fail with the following warnings:
include/linux/unaligned/access_ok.h:7:19: error: redefinition of 'get_unaligned_le16'
include/linux/unaligned/access_ok.h:12:19: error: redefinition of 'get_unaligned_le32'
include/linux/unaligned/access_ok.h:17:19: error: redefinition of 'get_unaligned_le64'
include/linux/unaligned/access_ok.h:22:19: error: redefinition of 'get_unaligned_be16'
include/linux/unaligned/access_ok.h:27:19: error: redefinition of 'get_unaligned_be32'
include/linux/unaligned/access_ok.h:32:19: error: redefinition of 'get_unaligned_be64'
include/linux/unaligned/access_ok.h:37:20: error: redefinition of 'put_unaligned_le16'
include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_le32'
include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_le64'
include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be16'
include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be32'
include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be64'
Fix these by including asm/unaligned.h instead and leave it up to the
architecture to decide how to implement unaligned accesses.
Fixes: 3194c6870158 ("NFC: nfcmrvl: add firmware download support")
Reported-by: kbuild test robot <fengguang.wu(a)intel.com>
Link: https://lkml.org/lkml/2016/10/22/247
Cc: Vincent Cuissard <cuissard(a)marvell.com>
Signed-off-by: Tobias Klauser <tklauser(a)distanz.ch>
Signed-off-by: Samuel Ortiz <sameo(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/nfc/nfcmrvl/fw_dnld.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/nfc/nfcmrvl/fw_dnld.c
+++ b/drivers/nfc/nfcmrvl/fw_dnld.c
@@ -17,7 +17,7 @@
*/
#include <linux/module.h>
-#include <linux/unaligned/access_ok.h>
+#include <asm/unaligned.h>
#include <linux/firmware.h>
#include <linux/nfc.h>
#include <net/nfc/nci.h>
Patches currently in stable-queue which might be from tklauser(a)distanz.ch are
queue-4.9/nfc-nfcmrvl-include-unaligned.h-instead-of-access_ok.h.patch
This is a note to let you know that I've just added the patch titled
NFC: nfcmrvl: double free on error path
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
nfc-nfcmrvl-double-free-on-error-path.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Wed, 8 Mar 2017 08:22:37 +0300
Subject: NFC: nfcmrvl: double free on error path
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ Upstream commit ca42fb9e52d155547e6cf18cf26bce3e1a6af4ea ]
The nci_spi_send() function calls kfree_skb(skb) on both error and
success so this extra kfree_skb() is a double free.
Fixes: caf6e49bf6d0 ("NFC: nfcmrvl: add spi driver")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Samuel Ortiz <sameo(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/nfc/nfcmrvl/spi.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/drivers/nfc/nfcmrvl/spi.c
+++ b/drivers/nfc/nfcmrvl/spi.c
@@ -96,10 +96,9 @@ static int nfcmrvl_spi_nci_send(struct n
/* Send the SPI packet */
err = nci_spi_send(drv_data->nci_spi, &drv_data->handshake_completion,
skb);
- if (err != 0) {
+ if (err)
nfc_err(priv->dev, "spi_send failed %d", err);
- kfree_skb(skb);
- }
+
return err;
}
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.9/media-cpia2-fix-a-couple-off-by-one-bugs.patch
queue-4.9/nfc-nfcmrvl-double-free-on-error-path.patch
queue-4.9/asoc-nuc900-fix-a-loop-timeout-test.patch
This is a note to let you know that I've just added the patch titled
netem: apply correct delay when rate throttling
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netem-apply-correct-delay-when-rate-throttling.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Nik Unger <njunger(a)uwaterloo.ca>
Date: Mon, 13 Mar 2017 10:16:58 -0700
Subject: netem: apply correct delay when rate throttling
From: Nik Unger <njunger(a)uwaterloo.ca>
[ Upstream commit 5080f39e8c72e01cf37e8359023e7018e2a4901e ]
I recently reported on the netem list that iperf network benchmarks
show unexpected results when a bandwidth throttling rate has been
configured for netem. Specifically:
1) The measured link bandwidth *increases* when a higher delay is added
2) The measured link bandwidth appears higher than the specified limit
3) The measured link bandwidth for the same very slow settings varies significantly across
machines
The issue can be reproduced by using tc to configure netem with a
512kbit rate and various (none, 1us, 50ms, 100ms, 200ms) delays on a
veth pair between network namespaces, and then using iperf (or any
other network benchmarking tool) to test throughput. Complete detailed
instructions are in the original email chain here:
https://lists.linuxfoundation.org/pipermail/netem/2017-February/001672.html
There appear to be two underlying bugs causing these effects:
- The first issue causes long delays when the rate is slow and no
delay is configured (e.g., "rate 512kbit"). This is because SKBs are
not orphaned when no delay is configured, so orphaning does not
occur until *after* the rate-induced delay has been applied. For
this reason, adding a tiny delay (e.g., "rate 512kbit delay 1us")
dramatically increases the measured bandwidth.
- The second issue is that rate-induced delays are not correctly
applied, allowing SKB delays to occur in parallel. The indended
approach is to compute the delay for an SKB and to add this delay to
the end of the current queue. However, the code does not detect
existing SKBs in the queue due to improperly testing sch->q.qlen,
which is nonzero even when packets exist only in the
rbtree. Consequently, new SKBs do not wait for the current queue to
empty. When packet delays vary significantly (e.g., if packet sizes
are different), then this also causes unintended reordering.
I modified the code to expect a delay (and orphan the SKB) when a rate
is configured. I also added some defensive tests that correctly find
the latest scheduled delivery time, even if it is (unexpectedly) for a
packet in sch->q. I have tested these changes on the latest kernel
(4.11.0-rc1+) and the iperf / ping test results are as expected.
Signed-off-by: Nik Unger <njunger(a)uwaterloo.ca>
Signed-off-by: Stephen Hemminger <stephen(a)networkplumber.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sched/sch_netem.c | 26 ++++++++++++++++++--------
1 file changed, 18 insertions(+), 8 deletions(-)
--- a/net/sched/sch_netem.c
+++ b/net/sched/sch_netem.c
@@ -462,7 +462,7 @@ static int netem_enqueue(struct sk_buff
/* If a delay is expected, orphan the skb. (orphaning usually takes
* place at TX completion time, so _before_ the link transit delay)
*/
- if (q->latency || q->jitter)
+ if (q->latency || q->jitter || q->rate)
skb_orphan_partial(skb);
/*
@@ -530,21 +530,31 @@ static int netem_enqueue(struct sk_buff
now = psched_get_time();
if (q->rate) {
- struct sk_buff *last;
+ struct netem_skb_cb *last = NULL;
+
+ if (sch->q.tail)
+ last = netem_skb_cb(sch->q.tail);
+ if (q->t_root.rb_node) {
+ struct sk_buff *t_skb;
+ struct netem_skb_cb *t_last;
+
+ t_skb = netem_rb_to_skb(rb_last(&q->t_root));
+ t_last = netem_skb_cb(t_skb);
+ if (!last ||
+ t_last->time_to_send > last->time_to_send) {
+ last = t_last;
+ }
+ }
- if (sch->q.qlen)
- last = sch->q.tail;
- else
- last = netem_rb_to_skb(rb_last(&q->t_root));
if (last) {
/*
* Last packet in queue is reference point (now),
* calculate this time bonus and subtract
* from delay.
*/
- delay -= netem_skb_cb(last)->time_to_send - now;
+ delay -= last->time_to_send - now;
delay = max_t(psched_tdiff_t, 0, delay);
- now = netem_skb_cb(last)->time_to_send;
+ now = last->time_to_send;
}
delay += packet_len_2_sched_time(qdisc_pkt_len(skb), q);
Patches currently in stable-queue which might be from njunger(a)uwaterloo.ca are
queue-4.9/netem-apply-correct-delay-when-rate-throttling.patch
This is a note to let you know that I've just added the patch titled
net: xfrm: allow clearing socket xfrm policies.
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-xfrm-allow-clearing-socket-xfrm-policies.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Lorenzo Colitti <lorenzo(a)google.com>
Date: Mon, 20 Nov 2017 19:26:02 +0900
Subject: net: xfrm: allow clearing socket xfrm policies.
From: Lorenzo Colitti <lorenzo(a)google.com>
[ Upstream commit be8f8284cd897af2482d4e54fbc2bdfc15557259 ]
Currently it is possible to add or update socket policies, but
not clear them. Therefore, once a socket policy has been applied,
the socket cannot be used for unencrypted traffic.
This patch allows (privileged) users to clear socket policies by
passing in a NULL pointer and zero length argument to the
{IP,IPV6}_{IPSEC,XFRM}_POLICY setsockopts. This results in both
the incoming and outgoing policies being cleared.
The simple approach taken in this patch cannot clear socket
policies in only one direction. If desired this could be added
in the future, for example by continuing to pass in a length of
zero (which currently is guaranteed to return EMSGSIZE) and
making the policy be a pointer to an integer that contains one
of the XFRM_POLICY_{IN,OUT} enum values.
An alternative would have been to interpret the length as a
signed integer and use XFRM_POLICY_IN (i.e., 0) to clear the
input policy and -XFRM_POLICY_OUT (i.e., -1) to clear the output
policy.
Tested: https://android-review.googlesource.com/539816
Signed-off-by: Lorenzo Colitti <lorenzo(a)google.com>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_policy.c | 2 +-
net/xfrm/xfrm_state.c | 7 +++++++
2 files changed, 8 insertions(+), 1 deletion(-)
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1346,7 +1346,7 @@ EXPORT_SYMBOL(xfrm_policy_delete);
int xfrm_sk_policy_insert(struct sock *sk, int dir, struct xfrm_policy *pol)
{
- struct net *net = xp_net(pol);
+ struct net *net = sock_net(sk);
struct xfrm_policy *old_pol;
#ifdef CONFIG_XFRM_SUB_POLICY
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1883,6 +1883,13 @@ int xfrm_user_policy(struct sock *sk, in
struct xfrm_mgr *km;
struct xfrm_policy *pol = NULL;
+ if (!optval && !optlen) {
+ xfrm_sk_policy_insert(sk, XFRM_POLICY_IN, NULL);
+ xfrm_sk_policy_insert(sk, XFRM_POLICY_OUT, NULL);
+ __sk_dst_reset(sk);
+ return 0;
+ }
+
if (optlen <= 0 || optlen > PAGE_SIZE)
return -EMSGSIZE;
Patches currently in stable-queue which might be from lorenzo(a)google.com are
queue-4.9/net-xfrm-allow-clearing-socket-xfrm-policies.patch
This is a note to let you know that I've just added the patch titled
net: thunderx: Set max queue count taking XDP_TX into account
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-thunderx-set-max-queue-count-taking-xdp_tx-into-account.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Sunil Goutham <sgoutham(a)cavium.com>
Date: Fri, 24 Nov 2017 15:04:03 +0300
Subject: net: thunderx: Set max queue count taking XDP_TX into account
From: Sunil Goutham <sgoutham(a)cavium.com>
[ Upstream commit 87de083857aa269fb171ef0b39696b2888361c58 ]
on T81 there are only 4 cores, hence setting max queue count to 4
would leave nothing for XDP_TX. This patch fixes this by doubling
max queue count in above scenarios.
Signed-off-by: Sunil Goutham <sgoutham(a)cavium.com>
Signed-off-by: cjacob <cjacob(a)caviumnetworks.com>
Signed-off-by: Aleksey Makarov <aleksey.makarov(a)cavium.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -1576,6 +1576,11 @@ static int nicvf_probe(struct pci_dev *p
nic->pdev = pdev;
nic->pnicvf = nic;
nic->max_queues = qcount;
+ /* If no of CPUs are too low, there won't be any queues left
+ * for XDP_TX, hence double it.
+ */
+ if (!nic->t88)
+ nic->max_queues *= 2;
/* MAP VF's configuration registers */
nic->reg_base = pcim_iomap(pdev, PCI_CFG_REG_BAR_NUM, 0);
Patches currently in stable-queue which might be from sgoutham(a)cavium.com are
queue-4.9/net-thunderx-set-max-queue-count-taking-xdp_tx-into-account.patch
This is a note to let you know that I've just added the patch titled
net: mvpp2: set dma mask and coherent dma mask on PPv2.2
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-mvpp2-set-dma-mask-and-coherent-dma-mask-on-ppv2.2.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com>
Date: Tue, 7 Mar 2017 16:53:19 +0100
Subject: net: mvpp2: set dma mask and coherent dma mask on PPv2.2
From: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com>
[ Upstream commit 2067e0a13cfe0b1bdca7b91bc5e4f2740b07d478 ]
On PPv2.2, the streaming mappings can be anywhere in the first 40 bits
of the physical address space. However, for the coherent mappings, we
still need them to be in the first 32 bits of the address space,
because all BM pools share a single register to store the high 32 bits
of the BM pool address, which means all BM pools must be allocated in
the same 4GB memory area.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/marvell/mvpp2.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -6420,6 +6420,20 @@ static int mvpp2_probe(struct platform_d
/* Get system's tclk rate */
priv->tclk = clk_get_rate(priv->pp_clk);
+ if (priv->hw_version == MVPP22) {
+ err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(40));
+ if (err)
+ goto err_mg_clk;
+ /* Sadly, the BM pools all share the same register to
+ * store the high 32 bits of their address. So they
+ * must all have the same high 32 bits, which forces
+ * us to restrict coherent memory to DMA_BIT_MASK(32).
+ */
+ err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
+ if (err)
+ goto err_mg_clk;
+ }
+
/* Initialize network controller */
err = mvpp2_init(pdev, priv);
if (err < 0) {
Patches currently in stable-queue which might be from thomas.petazzoni(a)free-electrons.com are
queue-4.9/net-mvpp2-set-dma-mask-and-coherent-dma-mask-on-ppv2.2.patch
This is a note to let you know that I've just added the patch titled
net: ieee802154: adf7242: Fix bug if defined DEBUG
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-ieee802154-adf7242-fix-bug-if-defined-debug.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Michael Hennerich <michael.hennerich(a)analog.com>
Date: Tue, 28 Nov 2017 13:53:12 +0100
Subject: net: ieee802154: adf7242: Fix bug if defined DEBUG
From: Michael Hennerich <michael.hennerich(a)analog.com>
[ Upstream commit 388b3b2b03701f3b3c10975c272892d7f78080df ]
This fixes undefined reference to struct adf7242_local *lp in
case DEBUG is defined.
Signed-off-by: Michael Hennerich <michael.hennerich(a)analog.com>
Signed-off-by: Stefan Schmidt <stefan(a)osg.samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ieee802154/adf7242.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/ieee802154/adf7242.c
+++ b/drivers/net/ieee802154/adf7242.c
@@ -888,7 +888,7 @@ static struct ieee802154_ops adf7242_ops
.set_cca_ed_level = adf7242_set_cca_ed_level,
};
-static void adf7242_debug(u8 irq1)
+static void adf7242_debug(struct adf7242_local *lp, u8 irq1)
{
#ifdef DEBUG
u8 stat;
@@ -932,7 +932,7 @@ static irqreturn_t adf7242_isr(int irq,
dev_err(&lp->spi->dev, "%s :ERROR IRQ1 = 0x%X\n",
__func__, irq1);
- adf7242_debug(irq1);
+ adf7242_debug(lp, irq1);
xmit = test_bit(FLAG_XMIT, &lp->flags);
Patches currently in stable-queue which might be from michael.hennerich(a)analog.com are
queue-4.9/net-ieee802154-adf7242-fix-bug-if-defined-debug.patch
This is a note to let you know that I've just added the patch titled
net: hns: Correct HNS RSS key set function
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-hns-correct-hns-rss-key-set-function.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: lipeng <lipeng321(a)huawei.com>
Date: Sat, 1 Apr 2017 12:03:39 +0100
Subject: net: hns: Correct HNS RSS key set function
From: lipeng <lipeng321(a)huawei.com>
[ Upstream commit 64ec10dc2ab8ef5bc6e76b1d4bc8203c08a6da1e ]
This patch fixes below ethtool configuration error:
localhost:~ # ethtool -X eth0 hkey XX:XX:XX...
Cannot set Rx flow hash configuration: Operation not supported
Signed-off-by: lipeng <lipeng321(a)huawei.com>
Reviewed-by: Yisen Zhuang <yisen.zhuang(a)huawei.com>
Signed-off-by: Salil Mehta <salil.mehta(a)huawei.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c | 27 +++++++++++++---------
drivers/net/ethernet/hisilicon/hns/hns_ethtool.c | 9 +++----
2 files changed, 20 insertions(+), 16 deletions(-)
--- a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
@@ -773,8 +773,9 @@ static int hns_ae_get_rss(struct hnae_ha
memcpy(key, ppe_cb->rss_key, HNS_PPEV2_RSS_KEY_SIZE);
/* update the current hash->queue mappings from the shadow RSS table */
- memcpy(indir, ppe_cb->rss_indir_table,
- HNS_PPEV2_RSS_IND_TBL_SIZE * sizeof(*indir));
+ if (indir)
+ memcpy(indir, ppe_cb->rss_indir_table,
+ HNS_PPEV2_RSS_IND_TBL_SIZE * sizeof(*indir));
return 0;
}
@@ -785,15 +786,19 @@ static int hns_ae_set_rss(struct hnae_ha
struct hns_ppe_cb *ppe_cb = hns_get_ppe_cb(handle);
/* set the RSS Hash Key if specififed by the user */
- if (key)
- hns_ppe_set_rss_key(ppe_cb, (u32 *)key);
-
- /* update the shadow RSS table with user specified qids */
- memcpy(ppe_cb->rss_indir_table, indir,
- HNS_PPEV2_RSS_IND_TBL_SIZE * sizeof(*indir));
-
- /* now update the hardware */
- hns_ppe_set_indir_table(ppe_cb, ppe_cb->rss_indir_table);
+ if (key) {
+ memcpy(ppe_cb->rss_key, key, HNS_PPEV2_RSS_KEY_SIZE);
+ hns_ppe_set_rss_key(ppe_cb, ppe_cb->rss_key);
+ }
+
+ if (indir) {
+ /* update the shadow RSS table with user specified qids */
+ memcpy(ppe_cb->rss_indir_table, indir,
+ HNS_PPEV2_RSS_IND_TBL_SIZE * sizeof(*indir));
+
+ /* now update the hardware */
+ hns_ppe_set_indir_table(ppe_cb, ppe_cb->rss_indir_table);
+ }
return 0;
}
--- a/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
@@ -1243,6 +1243,7 @@ hns_set_rss(struct net_device *netdev, c
{
struct hns_nic_priv *priv = netdev_priv(netdev);
struct hnae_ae_ops *ops;
+ int ret;
if (AE_IS_VER1(priv->enet_ver)) {
netdev_err(netdev,
@@ -1252,12 +1253,10 @@ hns_set_rss(struct net_device *netdev, c
ops = priv->ae_handle->dev->ops;
- /* currently hfunc can only be Toeplitz hash */
- if (key ||
- (hfunc != ETH_RSS_HASH_NO_CHANGE && hfunc != ETH_RSS_HASH_TOP))
+ if (hfunc != ETH_RSS_HASH_NO_CHANGE && hfunc != ETH_RSS_HASH_TOP) {
+ netdev_err(netdev, "Invalid hfunc!\n");
return -EOPNOTSUPP;
- if (!indir)
- return 0;
+ }
return ops->set_rss(priv->ae_handle, indir, key, hfunc);
}
Patches currently in stable-queue which might be from lipeng321(a)huawei.com are
queue-4.9/net-hns-correct-hns-rss-key-set-function.patch
This is a note to let you know that I've just added the patch titled
net: fec: add phy-reset-gpios PROBE_DEFER check
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-fec-add-phy-reset-gpios-probe_defer-check.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Fugang Duan <fugang.duan(a)nxp.com>
Date: Tue, 11 Apr 2017 19:13:06 +0800
Subject: net: fec: add phy-reset-gpios PROBE_DEFER check
From: Fugang Duan <fugang.duan(a)nxp.com>
[ Upstream commit 9269e5560b261eb9ee157497890dc0948db76cf8 ]
Many boards use i2c/spi expander gpio as phy-reset-gpios and these
gpios maybe registered after fec port, driver should check the return
value of .of_get_named_gpio().
Signed-off-by: Fugang Duan <B38611(a)freescale.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/freescale/fec_main.c | 26 ++++++++++++++++++--------
1 file changed, 18 insertions(+), 8 deletions(-)
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -3209,7 +3209,7 @@ static int fec_enet_init(struct net_devi
}
#ifdef CONFIG_OF
-static void fec_reset_phy(struct platform_device *pdev)
+static int fec_reset_phy(struct platform_device *pdev)
{
int err, phy_reset;
bool active_high = false;
@@ -3217,7 +3217,7 @@ static void fec_reset_phy(struct platfor
struct device_node *np = pdev->dev.of_node;
if (!np)
- return;
+ return 0;
of_property_read_u32(np, "phy-reset-duration", &msec);
/* A sane reset duration should not be longer than 1s */
@@ -3225,8 +3225,10 @@ static void fec_reset_phy(struct platfor
msec = 1;
phy_reset = of_get_named_gpio(np, "phy-reset-gpios", 0);
- if (!gpio_is_valid(phy_reset))
- return;
+ if (phy_reset == -EPROBE_DEFER)
+ return phy_reset;
+ else if (!gpio_is_valid(phy_reset))
+ return 0;
active_high = of_property_read_bool(np, "phy-reset-active-high");
@@ -3235,7 +3237,7 @@ static void fec_reset_phy(struct platfor
"phy-reset");
if (err) {
dev_err(&pdev->dev, "failed to get phy-reset-gpios: %d\n", err);
- return;
+ return err;
}
if (msec > 20)
@@ -3244,14 +3246,17 @@ static void fec_reset_phy(struct platfor
usleep_range(msec * 1000, msec * 1000 + 1000);
gpio_set_value_cansleep(phy_reset, !active_high);
+
+ return 0;
}
#else /* CONFIG_OF */
-static void fec_reset_phy(struct platform_device *pdev)
+static int fec_reset_phy(struct platform_device *pdev)
{
/*
* In case of platform probe, the reset has been done
* by machine code.
*/
+ return 0;
}
#endif /* CONFIG_OF */
@@ -3422,6 +3427,7 @@ fec_probe(struct platform_device *pdev)
if (ret) {
dev_err(&pdev->dev,
"Failed to enable phy regulator: %d\n", ret);
+ clk_disable_unprepare(fep->clk_ipg);
goto failed_regulator;
}
} else {
@@ -3434,7 +3440,9 @@ fec_probe(struct platform_device *pdev)
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
- fec_reset_phy(pdev);
+ ret = fec_reset_phy(pdev);
+ if (ret)
+ goto failed_reset;
if (fep->bufdesc_ex)
fec_ptp_init(pdev);
@@ -3495,8 +3503,10 @@ failed_init:
fec_ptp_stop(pdev);
if (fep->reg_phy)
regulator_disable(fep->reg_phy);
+failed_reset:
+ pm_runtime_put(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
failed_regulator:
- clk_disable_unprepare(fep->clk_ipg);
failed_clk_ipg:
fec_enet_clk_enable(ndev, false);
failed_clk:
Patches currently in stable-queue which might be from fugang.duan(a)nxp.com are
queue-4.9/net-fec-add-phy-reset-gpios-probe_defer-check.patch
This is a note to let you know that I've just added the patch titled
net/faraday: Add missing include of of.h
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-faraday-add-missing-include-of-of.h.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Andrew Lunn <andrew(a)lunn.ch>
Date: Sun, 2 Apr 2017 20:20:47 +0200
Subject: net/faraday: Add missing include of of.h
From: Andrew Lunn <andrew(a)lunn.ch>
[ Upstream commit d39004ab136ebb6949a7dda9d24376f3d6209295 ]
Breaking the include loop netdevice.h, dsa.h, devlink.h broke this
driver, it depends on includes brought in by these headers. Adding
linux/of.h fixes it.
Fixes: ed0e39e97d34 ("net: break include loop netdevice.h, dsa.h, devlink.h")
Signed-off-by: Andrew Lunn <andrew(a)lunn.ch>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/faraday/ftgmac100.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -28,6 +28,7 @@
#include <linux/io.h>
#include <linux/module.h>
#include <linux/netdevice.h>
+#include <linux/of.h>
#include <linux/phy.h>
#include <linux/platform_device.h>
#include <net/ip.h>
Patches currently in stable-queue which might be from andrew(a)lunn.ch are
queue-4.9/net-faraday-add-missing-include-of-of.h.patch
This is a note to let you know that I've just added the patch titled
net: ethernet: bgmac: Allow MAC address to be specified in DTB
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-ethernet-bgmac-allow-mac-address-to-be-specified-in-dtb.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Steve Lin <steven.lin1(a)broadcom.com>
Date: Thu, 16 Mar 2017 11:48:58 -0400
Subject: net: ethernet: bgmac: Allow MAC address to be specified in DTB
From: Steve Lin <steven.lin1(a)broadcom.com>
[ Upstream commit 2f771399a3a2c371c140ff33544a583c6fbc5fd9 ]
Allows the BCMA version of the bgmac driver to obtain MAC address
from the device tree. If no MAC address is specified there, then
the previous behavior (obtaining MAC address from SPROM) is
used.
Signed-off-by: Steve Lin <steven.lin1(a)broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com>
Acked-by: Jon Mason <jon.mason(a)broadcom.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/bgmac-bcma.c | 39 +++++++++++++++++------------
1 file changed, 23 insertions(+), 16 deletions(-)
--- a/drivers/net/ethernet/broadcom/bgmac-bcma.c
+++ b/drivers/net/ethernet/broadcom/bgmac-bcma.c
@@ -11,6 +11,7 @@
#include <linux/bcma/bcma.h>
#include <linux/brcmphy.h>
#include <linux/etherdevice.h>
+#include <linux/of_net.h>
#include "bgmac.h"
static inline bool bgmac_is_bcm4707_family(struct bcma_device *core)
@@ -96,7 +97,7 @@ static int bgmac_probe(struct bcma_devic
struct ssb_sprom *sprom = &core->bus->sprom;
struct mii_bus *mii_bus;
struct bgmac *bgmac;
- u8 *mac;
+ const u8 *mac = NULL;
int err;
bgmac = kzalloc(sizeof(*bgmac), GFP_KERNEL);
@@ -110,21 +111,27 @@ static int bgmac_probe(struct bcma_devic
bcma_set_drvdata(core, bgmac);
- switch (core->core_unit) {
- case 0:
- mac = sprom->et0mac;
- break;
- case 1:
- mac = sprom->et1mac;
- break;
- case 2:
- mac = sprom->et2mac;
- break;
- default:
- dev_err(bgmac->dev, "Unsupported core_unit %d\n",
- core->core_unit);
- err = -ENOTSUPP;
- goto err;
+ if (bgmac->dev->of_node)
+ mac = of_get_mac_address(bgmac->dev->of_node);
+
+ /* If no MAC address assigned via device tree, check SPROM */
+ if (!mac) {
+ switch (core->core_unit) {
+ case 0:
+ mac = sprom->et0mac;
+ break;
+ case 1:
+ mac = sprom->et1mac;
+ break;
+ case 2:
+ mac = sprom->et2mac;
+ break;
+ default:
+ dev_err(bgmac->dev, "Unsupported core_unit %d\n",
+ core->core_unit);
+ err = -ENOTSUPP;
+ goto err;
+ }
}
ether_addr_copy(bgmac->mac_addr, mac);
Patches currently in stable-queue which might be from steven.lin1(a)broadcom.com are
queue-4.9/net-ethernet-bgmac-allow-mac-address-to-be-specified-in-dtb.patch
This is a note to let you know that I've just added the patch titled
net/8021q: create device with all possible features in wanted_features
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-8021q-create-device-with-all-possible-features-in-wanted_features.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Andrey Vagin <avagin(a)openvz.org>
Date: Wed, 15 Mar 2017 17:41:14 -0700
Subject: net/8021q: create device with all possible features in wanted_features
From: Andrey Vagin <avagin(a)openvz.org>
[ Upstream commit 88997e4208aea117627898e5f6f9801cf3cd42d2 ]
wanted_features is a set of features which have to be enabled if a
hardware allows that.
Currently when a vlan device is created, its wanted_features is set to
current features of its base device.
The problem is that the base device can get new features and they are
not propagated to vlan-s of this device.
If we look at bonding devices, they doesn't have this problem and this
patch suggests to fix this issue by the same way how it works for bonding
devices.
We meet this problem, when we try to create a vlan device over a bonding
device. When a system are booting, real devices require time to be
initialized, so bonding devices created without slaves, then vlan
devices are created and only then ethernet devices are added to the
bonding device. As a result we have vlan devices with disabled
scatter-gather.
* create a bonding device
$ ip link add bond0 type bond
$ ethtool -k bond0 | grep scatter
scatter-gather: off
tx-scatter-gather: off [requested on]
tx-scatter-gather-fraglist: off [requested on]
* create a vlan device
$ ip link add link bond0 name bond0.10 type vlan id 10
$ ethtool -k bond0.10 | grep scatter
scatter-gather: off
tx-scatter-gather: off
tx-scatter-gather-fraglist: off
* Add a slave device to bond0
$ ip link set dev eth0 master bond0
And now we can see that the bond0 device has got the scatter-gather
feature, but the bond0.10 hasn't got it.
[root@laptop linux-task-diag]# ethtool -k bond0 | grep scatter
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: on
[root@laptop linux-task-diag]# ethtool -k bond0.10 | grep scatter
scatter-gather: off
tx-scatter-gather: off
tx-scatter-gather-fraglist: off
With this patch the vlan device will get all new features from the
bonding device.
Here is a call trace how features which are set in this patch reach
dev->wanted_features.
register_netdevice
vlan_dev_init
...
dev->hw_features = NETIF_F_HW_CSUM | NETIF_F_SG |
NETIF_F_FRAGLIST | NETIF_F_GSO_SOFTWARE |
NETIF_F_HIGHDMA | NETIF_F_SCTP_CRC |
NETIF_F_ALL_FCOE;
dev->features |= dev->hw_features;
...
dev->wanted_features = dev->features & dev->hw_features;
__netdev_update_features(dev);
vlan_dev_fix_features
...
Cc: Alexey Kuznetsov <kuznet(a)virtuozzo.com>
Cc: Patrick McHardy <kaber(a)trash.net>
Cc: "David S. Miller" <davem(a)davemloft.net>
Signed-off-by: Andrei Vagin <avagin(a)openvz.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/8021q/vlan_dev.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -562,8 +562,7 @@ static int vlan_dev_init(struct net_devi
NETIF_F_HIGHDMA | NETIF_F_SCTP_CRC |
NETIF_F_ALL_FCOE;
- dev->features |= real_dev->vlan_features | NETIF_F_LLTX |
- NETIF_F_GSO_SOFTWARE;
+ dev->features |= dev->hw_features | NETIF_F_LLTX;
dev->gso_max_size = real_dev->gso_max_size;
dev->gso_max_segs = real_dev->gso_max_segs;
if (dev->features & NETIF_F_VLAN_FEATURES)
Patches currently in stable-queue which might be from avagin(a)openvz.org are
queue-4.9/net-8021q-create-device-with-all-possible-features-in-wanted_features.patch
This is a note to let you know that I've just added the patch titled
mwifiex: Fix invalid port issue
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mwifiex-fix-invalid-port-issue.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Ganapathi Bhat <gbhat(a)marvell.com>
Date: Tue, 4 Apr 2017 10:16:28 +0530
Subject: mwifiex: Fix invalid port issue
From: Ganapathi Bhat <gbhat(a)marvell.com>
[ Upstream commit ecd7eb7c2bcf99f6c23d68ad56ce15949da848a1 ]
We have to use start port, for TX/RX of single packet,
instead of current aggregating port. This will fix SDIO
CMD53(TX/RX) returning -ETIMEDOUT and halting the data path.
Fixes: 0cb52aac4d19 ("mwifiex: do not set multiport flag for tx/rx single packet")
Signed-off-by: Ganapathi Bhat <gbhat(a)marvell.com>
Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/marvell/mwifiex/sdio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -1458,7 +1458,7 @@ static int mwifiex_sdio_card_to_host_mp_
}
if (card->mpa_rx.pkt_cnt == 1)
- mport = adapter->ioport + port;
+ mport = adapter->ioport + card->mpa_rx.start_port;
if (mwifiex_read_data_sync(adapter, card->mpa_rx.buf,
card->mpa_rx.buf_len, mport, 1))
@@ -1891,7 +1891,7 @@ static int mwifiex_host_to_card_mp_aggr(
}
if (card->mpa_tx.pkt_cnt == 1)
- mport = adapter->ioport + port;
+ mport = adapter->ioport + card->mpa_tx.start_port;
ret = mwifiex_write_data_to_card(adapter, card->mpa_tx.buf,
card->mpa_tx.buf_len, mport);
Patches currently in stable-queue which might be from gbhat(a)marvell.com are
queue-4.9/mwifiex-fix-invalid-port-issue.patch
This is a note to let you know that I've just added the patch titled
mwifiex: cfg80211: do not change virtual interface during scan processing
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mwifiex-cfg80211-do-not-change-virtual-interface-during-scan-processing.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Limin Zhu <liminzhu(a)marvell.com>
Date: Thu, 30 Nov 2017 14:22:34 +0800
Subject: mwifiex: cfg80211: do not change virtual interface during scan processing
From: Limin Zhu <liminzhu(a)marvell.com>
[ Upstream commit c61cfe49f0f0f0d1f8b56d0b045838d597e8c3a3 ]
(1) Change virtual interface operation in cfg80211 process reset and
reinitilize private data structure.
(2) Scan result event processed in main process will dereference private
data structure concurrently, ocassionly crash the kernel.
The cornel case could be trigger by below steps:
(1) wpa_cli mlan0 scan
(2) ./hostapd mlan0.conf
Cfg80211 asynchronous scan procedure is not all the time operated
under rtnl lock, here we add the protect to serialize the cfg80211
scan and change_virtual interface operation.
Signed-off-by: Limin Zhu <liminzhu(a)marvell.com>
Signed-off-by: Xinming Hu <huxm(a)marvell.com>
Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -1109,6 +1109,12 @@ mwifiex_cfg80211_change_virtual_intf(str
struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev);
enum nl80211_iftype curr_iftype = dev->ieee80211_ptr->iftype;
+ if (priv->scan_request) {
+ mwifiex_dbg(priv->adapter, ERROR,
+ "change virtual interface: scan in process\n");
+ return -EBUSY;
+ }
+
switch (curr_iftype) {
case NL80211_IFTYPE_ADHOC:
switch (type) {
Patches currently in stable-queue which might be from liminzhu(a)marvell.com are
queue-4.9/mwifiex-cfg80211-do-not-change-virtual-interface-during-scan-processing.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: ifc: update bufnum mask for ver >= 2.0.0
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mtd-nand-ifc-update-bufnum-mask-for-ver-2.0.0.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Jagdish Gediya <jagdish.gediya(a)nxp.com>
Date: Thu, 23 Nov 2017 17:04:31 +0530
Subject: mtd: nand: ifc: update bufnum mask for ver >= 2.0.0
From: Jagdish Gediya <jagdish.gediya(a)nxp.com>
[ Upstream commit bccb06c353af3764ca86d9da47652458e6c2eb41 ]
Bufnum mask is used to calculate page position in the internal SRAM.
As IFC version 2.0.0 has 16KB of internal SRAM as compared to older
versions which had 8KB. Hence bufnum mask needs to be updated.
Signed-off-by: Jagdish Gediya <jagdish.gediya(a)nxp.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha(a)nxp.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/fsl_ifc_nand.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -907,6 +907,13 @@ static int fsl_ifc_chip_init(struct fsl_
if (ctrl->version == FSL_IFC_VERSION_1_1_0)
fsl_ifc_sram_init(priv);
+ /*
+ * As IFC version 2.0.0 has 16KB of internal SRAM as compared to older
+ * versions which had 8KB. Hence bufnum mask needs to be updated.
+ */
+ if (ctrl->version >= FSL_IFC_VERSION_2_0_0)
+ priv->bufnum_mask = (priv->bufnum_mask * 2) + 1;
+
return 0;
}
Patches currently in stable-queue which might be from jagdish.gediya(a)nxp.com are
queue-4.9/mtd-nand-ifc-update-bufnum-mask-for-ver-2.0.0.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: fix interpretation of NAND_CMD_NONE in nand_command[_lp]()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mtd-nand-fix-interpretation-of-nand_cmd_none-in-nand_command.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Miquel Raynal <miquel.raynal(a)free-electrons.com>
Date: Wed, 8 Nov 2017 17:00:27 +0100
Subject: mtd: nand: fix interpretation of NAND_CMD_NONE in nand_command[_lp]()
From: Miquel Raynal <miquel.raynal(a)free-electrons.com>
[ Upstream commit df467899da0b71465760b4e35127bce837244eee ]
Some drivers (like nand_hynix.c) call ->cmdfunc() with NAND_CMD_NONE
and a column address and expect the controller to only send address
cycles. Right now, the default ->cmdfunc() implementations provided by
the core do not filter out the command cycle in this case and forwards
the request to the controller driver through the ->cmd_ctrl() method.
The thing is, NAND controller drivers can get this wrong and send a
command cycle with a NAND_CMD_NONE opcode and since NAND_CMD_NONE is
-1, and the command field is usually casted to an u8, we end up sending
the 0xFF command which is actually a RESET operation.
Add conditions in nand_command[_lp]() functions to sending the initial
command cycle when command == NAND_CMD_NONE.
Signed-off-by: Miquel Raynal <miquel.raynal(a)free-electrons.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/nand_base.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -715,7 +715,8 @@ static void nand_command(struct mtd_info
chip->cmd_ctrl(mtd, readcmd, ctrl);
ctrl &= ~NAND_CTRL_CHANGE;
}
- chip->cmd_ctrl(mtd, command, ctrl);
+ if (command != NAND_CMD_NONE)
+ chip->cmd_ctrl(mtd, command, ctrl);
/* Address cycle, when necessary */
ctrl = NAND_CTRL_ALE | NAND_CTRL_CHANGE;
@@ -744,6 +745,7 @@ static void nand_command(struct mtd_info
*/
switch (command) {
+ case NAND_CMD_NONE:
case NAND_CMD_PAGEPROG:
case NAND_CMD_ERASE1:
case NAND_CMD_ERASE2:
@@ -806,7 +808,9 @@ static void nand_command_lp(struct mtd_i
}
/* Command latch cycle */
- chip->cmd_ctrl(mtd, command, NAND_NCE | NAND_CLE | NAND_CTRL_CHANGE);
+ if (command != NAND_CMD_NONE)
+ chip->cmd_ctrl(mtd, command,
+ NAND_NCE | NAND_CLE | NAND_CTRL_CHANGE);
if (column != -1 || page_addr != -1) {
int ctrl = NAND_CTRL_CHANGE | NAND_NCE | NAND_ALE;
@@ -842,6 +846,7 @@ static void nand_command_lp(struct mtd_i
*/
switch (command) {
+ case NAND_CMD_NONE:
case NAND_CMD_CACHEDPROG:
case NAND_CMD_PAGEPROG:
case NAND_CMD_ERASE1:
Patches currently in stable-queue which might be from miquel.raynal(a)free-electrons.com are
queue-4.9/mtd-nand-fix-interpretation-of-nand_cmd_none-in-nand_command.patch
This is a note to let you know that I've just added the patch titled
mm: Fix false-positive VM_BUG_ON() in page_cache_{get,add}_speculative()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mm-fix-false-positive-vm_bug_on-in-page_cache_-get-add-_speculative.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com>
Date: Fri, 24 Mar 2017 14:13:05 +0300
Subject: mm: Fix false-positive VM_BUG_ON() in page_cache_{get,add}_speculative()
From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com>
[ Upstream commit 591a3d7c09fa08baff48ad86c2347dbd28a52753 ]
0day testing by Fengguang Wu triggered this crash while running Trinity:
kernel BUG at include/linux/pagemap.h:151!
...
CPU: 0 PID: 458 Comm: trinity-c0 Not tainted 4.11.0-rc2-00251-g2947ba0 #1
...
Call Trace:
__get_user_pages_fast()
get_user_pages_fast()
get_futex_key()
futex_requeue()
do_futex()
SyS_futex()
do_syscall_64()
entry_SYSCALL64_slow_path()
It' VM_BUG_ON() due to false-negative in_atomic(). We call
page_cache_get_speculative() with disabled local interrupts.
It should be atomic enough.
So let's check for disabled interrupts in the VM_BUG_ON() condition
too, to resolve this.
( This got triggered by the conversion of the x86 GUP code to the
generic GUP code. )
Reported-by: Fengguang Wu <fengguang.wu(a)intel.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Aneesh Kumar K.V <aneesh.kumar(a)linux.vnet.ibm.com>
Cc: Kirill A. Shutemov <kirill(a)shutemov.name>
Cc: LKP <lkp(a)01.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: linux-mm(a)kvack.org
Link: http://lkml.kernel.org/r/20170324114709.pcytvyb3d6ajux33@black.fi.intel.com
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/pagemap.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -148,7 +148,7 @@ static inline int page_cache_get_specula
#ifdef CONFIG_TINY_RCU
# ifdef CONFIG_PREEMPT_COUNT
- VM_BUG_ON(!in_atomic());
+ VM_BUG_ON(!in_atomic() && !irqs_disabled());
# endif
/*
* Preempt must be disabled here - we rely on rcu_read_lock doing
@@ -186,7 +186,7 @@ static inline int page_cache_add_specula
#if !defined(CONFIG_SMP) && defined(CONFIG_TREE_RCU)
# ifdef CONFIG_PREEMPT_COUNT
- VM_BUG_ON(!in_atomic());
+ VM_BUG_ON(!in_atomic() && !irqs_disabled());
# endif
VM_BUG_ON_PAGE(page_count(page) == 0, page);
page_ref_add(page, count);
Patches currently in stable-queue which might be from kirill.shutemov(a)linux.intel.com are
queue-4.9/mm-fix-false-positive-vm_bug_on-in-page_cache_-get-add-_speculative.patch
queue-4.9/x86-mm-make-mmap-map_32bit-work-correctly.patch
This is a note to let you know that I've just added the patch titled
MIPS: r2-on-r6-emu: Fix BLEZL and BGTZL identification
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mips-r2-on-r6-emu-fix-blezl-and-bgtzl-identification.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Leonid Yegoshin <Leonid.Yegoshin(a)imgtec.com>
Date: Mon, 13 Mar 2017 16:36:35 +0100
Subject: MIPS: r2-on-r6-emu: Fix BLEZL and BGTZL identification
From: Leonid Yegoshin <Leonid.Yegoshin(a)imgtec.com>
[ Upstream commit 5bba7aa4958e271c3ffceb70d47d3206524cf489 ]
Fix the problem of inaccurate identification of instructions BLEZL and
BGTZL in R2 emulation code by making sure all necessary encoding
specifications are met.
Previously, certain R6 instructions could be identified as BLEZL or
BGTZL. R2 emulation routine didn't take into account that both BLEZL
and BGTZL instructions require their rt field (bits 20 to 16 of
instruction encoding) to be 0, and that, at same time, if the value in
that field is not 0, the encoding may represent a legitimate MIPS R6
instruction.
This means that a problem could occur after emulation optimization,
when emulation routine tried to pipeline emulation, picked up a next
candidate, and subsequently misrecognized an R6 instruction as BLEZL
or BGTZL.
It should be said that for single pass strategy, the problem does not
happen because CPU doesn't trap on branch-compacts which share opcode
space with BLEZL/BGTZL (but have rt field != 0, of course).
Signed-off-by: Leonid Yegoshin <leonid.yegoshin(a)imgtec.com>
Signed-off-by: Miodrag Dinic <miodrag.dinic(a)imgtech.com>
Signed-off-by: Aleksandar Markovic <aleksandar.markovic(a)imgtech.com>
Reported-by: Douglas Leung <douglas.leung(a)imgtec.com>
Reviewed-by: Paul Burton <paul.burton(a)imgtec.com>
Cc: james.hogan(a)imgtec.com
Cc: petar.jovanovic(a)imgtec.com
Cc: goran.ferenc(a)imgtec.com
Cc: linux-mips(a)linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/15456/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/mips-r2-to-r6-emul.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
--- a/arch/mips/kernel/mips-r2-to-r6-emul.c
+++ b/arch/mips/kernel/mips-r2-to-r6-emul.c
@@ -1096,10 +1096,20 @@ repeat:
}
break;
- case beql_op:
- case bnel_op:
case blezl_op:
case bgtzl_op:
+ /*
+ * For BLEZL and BGTZL, rt field must be set to 0. If this
+ * is not the case, this may be an encoding of a MIPS R6
+ * instruction, so return to CPU execution if this occurs
+ */
+ if (MIPSInst_RT(inst)) {
+ err = SIGILL;
+ break;
+ }
+ /* fall through */
+ case beql_op:
+ case bnel_op:
if (delay_slot(regs)) {
err = SIGILL;
break;
Patches currently in stable-queue which might be from Leonid.Yegoshin(a)imgtec.com are
queue-4.9/mips-r2-on-r6-emu-fix-blezl-and-bgtzl-identification.patch
This is a note to let you know that I've just added the patch titled
MIPS: r2-on-r6-emu: Clear BLTZALL and BGEZALL debugfs counters
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mips-r2-on-r6-emu-clear-bltzall-and-bgezall-debugfs-counters.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Aleksandar Markovic <aleksandar.markovic(a)imgtec.com>
Date: Mon, 13 Mar 2017 16:36:36 +0100
Subject: MIPS: r2-on-r6-emu: Clear BLTZALL and BGEZALL debugfs counters
From: Aleksandar Markovic <aleksandar.markovic(a)imgtec.com>
[ Upstream commit 411dac79cc2ed80f7e348ccc23eb4d8b0ba9f6d5 ]
Add missing clearing of BLTZALL and BGEZALL emulation counters in
function mipsr2_stats_clear_show().
Previously, it was not possible to reset BLTZALL and BGEZALL
emulation counters - their value remained the same even after
explicit request via debugfs. As far as other related counters
are concerned, they all seem to be properly cleared.
This change affects debugfs operation only, core R2 emulation
functionality is not affected.
Signed-off-by: Aleksandar Markovic <aleksandar.markovic(a)imgtec.com>
Reviewed-by: Paul Burton <paul.burton(a)imgtec.com>
Cc: james.hogan(a)imgtec.com
Cc: leonid.yegoshin(a)imgtec.com
Cc: douglas.leung(a)imgtec.com
Cc: petar.jovanovic(a)imgtec.com
Cc: miodrag.dinic(a)imgtec.com
Cc: goran.ferenc(a)imgtec.com
Cc: linux-mips(a)linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/15517/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/mips-r2-to-r6-emul.c | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/mips/kernel/mips-r2-to-r6-emul.c
+++ b/arch/mips/kernel/mips-r2-to-r6-emul.c
@@ -2339,6 +2339,8 @@ static int mipsr2_stats_clear_show(struc
__this_cpu_write((mipsr2bremustats).bgezl, 0);
__this_cpu_write((mipsr2bremustats).bltzll, 0);
__this_cpu_write((mipsr2bremustats).bgezll, 0);
+ __this_cpu_write((mipsr2bremustats).bltzall, 0);
+ __this_cpu_write((mipsr2bremustats).bgezall, 0);
__this_cpu_write((mipsr2bremustats).bltzal, 0);
__this_cpu_write((mipsr2bremustats).bgezal, 0);
__this_cpu_write((mipsr2bremustats).beql, 0);
Patches currently in stable-queue which might be from aleksandar.markovic(a)imgtec.com are
queue-4.9/mips-r2-on-r6-emu-clear-bltzall-and-bgezall-debugfs-counters.patch
This is a note to let you know that I've just added the patch titled
MIPS: BPF: Quit clobbering callee saved registers in JIT code.
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mips-bpf-quit-clobbering-callee-saved-registers-in-jit-code.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: David Daney <david.daney(a)cavium.com>
Date: Tue, 14 Mar 2017 14:21:43 -0700
Subject: MIPS: BPF: Quit clobbering callee saved registers in JIT code.
From: David Daney <david.daney(a)cavium.com>
[ Upstream commit 1ef0910cfd681f0bd0b81f8809935b2006e9cfb9 ]
If bpf_needs_clear_a() returns true, only actually clear it if it is
ever used. If it is not used, we don't save and restore it, so the
clearing has the nasty side effect of clobbering caller state.
Also, don't emit stack pointer adjustment instructions if the
adjustment amount is zero.
Signed-off-by: David Daney <david.daney(a)cavium.com>
Cc: James Hogan <james.hogan(a)imgtec.com>
Cc: Alexei Starovoitov <ast(a)kernel.org>
Cc: Steven J. Hill <steven.hill(a)cavium.com>
Cc: linux-mips(a)linux-mips.org
Cc: netdev(a)vger.kernel.org
Cc: linux-kernel(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/15745/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/net/bpf_jit.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
--- a/arch/mips/net/bpf_jit.c
+++ b/arch/mips/net/bpf_jit.c
@@ -526,7 +526,8 @@ static void save_bpf_jit_regs(struct jit
u32 sflags, tmp_flags;
/* Adjust the stack pointer */
- emit_stack_offset(-align_sp(offset), ctx);
+ if (offset)
+ emit_stack_offset(-align_sp(offset), ctx);
tmp_flags = sflags = ctx->flags >> SEEN_SREG_SFT;
/* sflags is essentially a bitmap */
@@ -578,7 +579,8 @@ static void restore_bpf_jit_regs(struct
emit_load_stack_reg(r_ra, r_sp, real_off, ctx);
/* Restore the sp and discard the scrach memory */
- emit_stack_offset(align_sp(offset), ctx);
+ if (offset)
+ emit_stack_offset(align_sp(offset), ctx);
}
static unsigned int get_stack_depth(struct jit_ctx *ctx)
@@ -625,8 +627,14 @@ static void build_prologue(struct jit_ct
if (ctx->flags & SEEN_X)
emit_jit_reg_move(r_X, r_zero, ctx);
- /* Do not leak kernel data to userspace */
- if (bpf_needs_clear_a(&ctx->skf->insns[0]))
+ /*
+ * Do not leak kernel data to userspace, we only need to clear
+ * r_A if it is ever used. In fact if it is never used, we
+ * will not save/restore it, so clearing it in this case would
+ * corrupt the state of the caller.
+ */
+ if (bpf_needs_clear_a(&ctx->skf->insns[0]) &&
+ (ctx->flags & SEEN_A))
emit_jit_reg_move(r_A, r_zero, ctx);
}
Patches currently in stable-queue which might be from david.daney(a)cavium.com are
queue-4.9/mips-bpf-quit-clobbering-callee-saved-registers-in-jit-code.patch
queue-4.9/pci-apply-cavium-acs-quirk-only-to-cn81xx-cn83xx-cn88xx-devices.patch
queue-4.9/mips-bpf-fix-multiple-problems-in-jit-skb-access-helpers.patch
This is a note to let you know that I've just added the patch titled
media: vsp1: Prevent suspending and resuming DRM pipelines
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-vsp1-prevent-suspending-and-resuming-drm-pipelines.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com>
Date: Mon, 4 Dec 2017 06:01:11 -0500
Subject: media: vsp1: Prevent suspending and resuming DRM pipelines
From: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com>
[ Upstream commit a17d2d6cd9985ca09a9e384f1bc71d710f7e5203 ]
When used as part of a display pipeline, the VSP is stopped and
restarted explicitly by the DU from its suspend and resume handlers.
There is thus no need to stop or restart pipelines in the VSP suspend
and resume handlers, and doing so would cause the hardware to be
left in a misconfigured state.
Ensure that the VSP suspend and resume handlers do not affect DRM-based
pipelines.
Signed-off-by: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/platform/vsp1/vsp1_drv.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -509,7 +509,13 @@ static int __maybe_unused vsp1_pm_suspen
{
struct vsp1_device *vsp1 = dev_get_drvdata(dev);
- vsp1_pipelines_suspend(vsp1);
+ /*
+ * When used as part of a display pipeline, the VSP is stopped and
+ * restarted explicitly by the DU.
+ */
+ if (!vsp1->drm)
+ vsp1_pipelines_suspend(vsp1);
+
pm_runtime_force_suspend(vsp1->dev);
return 0;
@@ -520,7 +526,13 @@ static int __maybe_unused vsp1_pm_resume
struct vsp1_device *vsp1 = dev_get_drvdata(dev);
pm_runtime_force_resume(vsp1->dev);
- vsp1_pipelines_resume(vsp1);
+
+ /*
+ * When used as part of a display pipeline, the VSP is stopped and
+ * restarted explicitly by the DU.
+ */
+ if (!vsp1->drm)
+ vsp1_pipelines_resume(vsp1);
return 0;
}
Patches currently in stable-queue which might be from kieran.bingham+renesas(a)ideasonboard.com are
queue-4.9/v4l-vsp1-prevent-multiple-streamon-race-commencing-pipeline-early.patch
queue-4.9/v4l-vsp1-register-pipe-with-output-wpf.patch
queue-4.9/media-vsp1-prevent-suspending-and-resuming-drm-pipelines.patch
This is a note to let you know that I've just added the patch titled
[media] media: i2c/soc_camera: fix ov6650 sensor getting wrong clock
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-i2c-soc_camera-fix-ov6650-sensor-getting-wrong-clock.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Janusz Krzysztofik <jmkrzyszt(a)gmail.com>
Date: Wed, 15 Jun 2016 19:29:50 -0300
Subject: [media] media: i2c/soc_camera: fix ov6650 sensor getting wrong clock
From: Janusz Krzysztofik <jmkrzyszt(a)gmail.com>
[ Upstream commit 54449af0e0b2ea43a8166611c95b730c850c3184 ]
After changes to v4l2_clk API introduced in v4.1 by commits a37462b919
'[media] V4L: remove clock name from v4l2_clk API' and 4f528afcfb
'[media] V4L: add CCF support to the v4l2_clk API', ov6650 sensor
stopped responding because v4l2_clk_get(), still called with
depreciated V4L2 clock name "mclk", started to return respective CCF
clock instead of the V4l2 one registered by soc_camera. Fix it by
calling v4l2_clk_get() with NULL clock name.
Created and tested on Amstrad Delta against Linux-4.7-rc3 with
omap1_camera fixes.
Signed-off-by: Janusz Krzysztofik <jmkrzyszt(a)gmail.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski(a)gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/i2c/soc_camera/ov6650.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/media/i2c/soc_camera/ov6650.c
+++ b/drivers/media/i2c/soc_camera/ov6650.c
@@ -1033,7 +1033,7 @@ static int ov6650_probe(struct i2c_clien
priv->code = MEDIA_BUS_FMT_YUYV8_2X8;
priv->colorspace = V4L2_COLORSPACE_JPEG;
- priv->clk = v4l2_clk_get(&client->dev, "mclk");
+ priv->clk = v4l2_clk_get(&client->dev, NULL);
if (IS_ERR(priv->clk)) {
ret = PTR_ERR(priv->clk);
goto eclkget;
Patches currently in stable-queue which might be from jmkrzyszt(a)gmail.com are
queue-4.9/media-i2c-soc_camera-fix-ov6650-sensor-getting-wrong-clock.patch
This is a note to let you know that I've just added the patch titled
media: cpia2: Fix a couple off by one bugs
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-cpia2-fix-a-couple-off-by-one-bugs.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Thu, 9 Nov 2017 16:28:14 -0500
Subject: media: cpia2: Fix a couple off by one bugs
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ Upstream commit d5ac225c7d64c9c3ef821239edc035634e594ec9 ]
The cam->buffers[] array has cam->num_frames elements so the > needs to
be changed to >= to avoid going beyond the end of the array. The
->buffers[] array is allocated in cpia2_allocate_buffers() if you want
to confirm.
Fixes: ab33d5071de7 ("V4L/DVB (3376): Add cpia2 camera support")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/usb/cpia2/cpia2_v4l.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/media/usb/cpia2/cpia2_v4l.c
+++ b/drivers/media/usb/cpia2/cpia2_v4l.c
@@ -812,7 +812,7 @@ static int cpia2_querybuf(struct file *f
struct camera_data *cam = video_drvdata(file);
if(buf->type != V4L2_BUF_TYPE_VIDEO_CAPTURE ||
- buf->index > cam->num_frames)
+ buf->index >= cam->num_frames)
return -EINVAL;
buf->m.offset = cam->buffers[buf->index].data - cam->frame_buffer;
@@ -863,7 +863,7 @@ static int cpia2_qbuf(struct file *file,
if(buf->type != V4L2_BUF_TYPE_VIDEO_CAPTURE ||
buf->memory != V4L2_MEMORY_MMAP ||
- buf->index > cam->num_frames)
+ buf->index >= cam->num_frames)
return -EINVAL;
DBG("QBUF #%d\n", buf->index);
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.9/media-cpia2-fix-a-couple-off-by-one-bugs.patch
queue-4.9/nfc-nfcmrvl-double-free-on-error-path.patch
queue-4.9/asoc-nuc900-fix-a-loop-timeout-test.patch
This is a note to let you know that I've just added the patch titled
md.c:didn't unlock the mddev before return EINVAL in array_size_store
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
md.c-didn-t-unlock-the-mddev-before-return-einval-in-array_size_store.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Zhilong Liu <zlliu(a)suse.com>
Date: Mon, 10 Apr 2017 14:15:55 +0800
Subject: md.c:didn't unlock the mddev before return EINVAL in array_size_store
From: Zhilong Liu <zlliu(a)suse.com>
[ Upstream commit b670883bb9e55ba63a278d83e034faefc01ce2cf ]
md.c: it needs to release the mddev lock before
the array_size_store() returns.
Fixes: ab5a98b132fd ("md-cluster: change array_sectors and update size are not supported")
Signed-off-by: Zhilong Liu <zlliu(a)suse.com>
Reviewed-by: Guoqing Jiang <gqjiang(a)suse.com>
Signed-off-by: Shaohua Li <shli(a)fb.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/md.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -4826,8 +4826,10 @@ array_size_store(struct mddev *mddev, co
return err;
/* cluster raid doesn't support change array_sectors */
- if (mddev_is_clustered(mddev))
+ if (mddev_is_clustered(mddev)) {
+ mddev_unlock(mddev);
return -EINVAL;
+ }
if (strncmp(buf, "default", 7) == 0) {
if (mddev->pers)
Patches currently in stable-queue which might be from zlliu(a)suse.com are
queue-4.9/md.c-didn-t-unlock-the-mddev-before-return-einval-in-array_size_store.patch
This is a note to let you know that I've just added the patch titled
md/raid6: Fix anomily when recovering a single device in RAID6.
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
md-raid6-fix-anomily-when-recovering-a-single-device-in-raid6.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: NeilBrown <neilb(a)suse.com>
Date: Mon, 3 Apr 2017 12:11:32 +1000
Subject: md/raid6: Fix anomily when recovering a single device in RAID6.
From: NeilBrown <neilb(a)suse.com>
[ Upstream commit 7471fb77ce4dc4cb81291189947fcdf621a97987 ]
When recoverying a single missing/failed device in a RAID6,
those stripes where the Q block is on the missing device are
handled a bit differently. In these cases it is easy to
check that the P block is correct, so we do. This results
in the P block be destroy. Consequently the P block needs
to be read a second time in order to compute Q. This causes
lots of seeks and hurts performance.
It shouldn't be necessary to re-read P as it can be computed
from the DATA. But we only compute blocks on missing
devices, since c337869d9501 ("md: do not compute parity
unless it is on a failed drive").
So relax the change made in that commit to allow computing
of the P block in a RAID6 which it is the only missing that
block.
This makes RAID6 recovery run much faster as the disk just
"before" the recovering device is no longer seeking
back-and-forth.
Reported-by-tested-by: Brad Campbell <lists2009(a)fnarfbargle.com>
Reviewed-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: NeilBrown <neilb(a)suse.com>
Signed-off-by: Shaohua Li <shli(a)fb.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/raid5.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -3391,9 +3391,20 @@ static int fetch_block(struct stripe_hea
BUG_ON(test_bit(R5_Wantcompute, &dev->flags));
BUG_ON(test_bit(R5_Wantread, &dev->flags));
BUG_ON(sh->batch_head);
+
+ /*
+ * In the raid6 case if the only non-uptodate disk is P
+ * then we already trusted P to compute the other failed
+ * drives. It is safe to compute rather than re-read P.
+ * In other cases we only compute blocks from failed
+ * devices, otherwise check/repair might fail to detect
+ * a real inconsistency.
+ */
+
if ((s->uptodate == disks - 1) &&
+ ((sh->qd_idx >= 0 && sh->pd_idx == disk_idx) ||
(s->failed && (disk_idx == s->failed_num[0] ||
- disk_idx == s->failed_num[1]))) {
+ disk_idx == s->failed_num[1])))) {
/* have disk failed, and we're requested to fetch it;
* do compute it
*/
Patches currently in stable-queue which might be from neilb(a)suse.com are
queue-4.9/md-raid6-fix-anomily-when-recovering-a-single-device-in-raid6.patch
This is a note to let you know that I've just added the patch titled
mac80211_hwsim: use per-interface power level
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mac80211_hwsim-use-per-interface-power-level.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Johannes Berg <johannes.berg(a)intel.com>
Date: Thu, 13 Apr 2017 10:31:16 +0200
Subject: mac80211_hwsim: use per-interface power level
From: Johannes Berg <johannes.berg(a)intel.com>
[ Upstream commit 1d5e9f80ab021e3e1f9436627a4ad07a143ccb2c ]
When channel contexts are used, there's no global power level
(the power_level is always 0). Use the per-interface TX power
in mac80211_hwsim to have a proper setting for both cases.
This fixes the bgscan_simple and bgscan_learn test cases when
the number of channels advertised by hwsim is >1 by default.
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/mac80211_hwsim.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -552,8 +552,6 @@ struct mac80211_hwsim_data {
/* wmediumd portid responsible for netgroup of this radio */
u32 wmediumd;
- int power_level;
-
/* difference between this hw's clock and the real clock, in usecs */
s64 tsf_offset;
s64 bcn_delta;
@@ -1208,7 +1206,9 @@ static bool mac80211_hwsim_tx_frame_no_n
if (info->control.rates[0].flags & IEEE80211_TX_RC_SHORT_GI)
rx_status.flag |= RX_FLAG_SHORT_GI;
/* TODO: simulate real signal strength (and optional packet loss) */
- rx_status.signal = data->power_level - 50;
+ rx_status.signal = -50;
+ if (info->control.vif)
+ rx_status.signal += info->control.vif->bss_conf.txpower;
if (data->ps != PS_DISABLED)
hdr->frame_control |= cpu_to_le16(IEEE80211_FCTL_PM);
@@ -1607,7 +1607,6 @@ static int mac80211_hwsim_config(struct
WARN_ON(data->channel && data->use_chanctx);
- data->power_level = conf->power_level;
if (!data->started || !data->beacon_int)
tasklet_hrtimer_cancel(&data->beacon_timer);
else if (!hrtimer_is_queued(&data->beacon_timer.timer)) {
@@ -2212,7 +2211,6 @@ static const char mac80211_hwsim_gstring
"d_tx_failed",
"d_ps_mode",
"d_group",
- "d_tx_power",
};
#define MAC80211_HWSIM_SSTATS_LEN ARRAY_SIZE(mac80211_hwsim_gstrings_stats)
@@ -2249,7 +2247,6 @@ static void mac80211_hwsim_get_et_stats(
data[i++] = ar->tx_failed;
data[i++] = ar->ps;
data[i++] = ar->group;
- data[i++] = ar->power_level;
WARN_ON(i != MAC80211_HWSIM_SSTATS_LEN);
}
Patches currently in stable-queue which might be from johannes.berg(a)intel.com are
queue-4.9/mac80211-remove-bug-when-interface-type-is-invalid.patch
queue-4.9/mac80211_hwsim-enforce-ps_manual_poll-to-be-set-after-ps_enabled.patch
queue-4.9/mac80211_hwsim-use-per-interface-power-level.patch
queue-4.9/iwlwifi-mvm-fix-rx-skb-header-size-and-align-it-properly.patch
This is a note to let you know that I've just added the patch titled
mac80211_hwsim: enforce PS_MANUAL_POLL to be set after PS_ENABLED
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mac80211_hwsim-enforce-ps_manual_poll-to-be-set-after-ps_enabled.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Adiel Aloni <adiel.aloni(a)intel.com>
Date: Fri, 1 Dec 2017 13:50:53 +0200
Subject: mac80211_hwsim: enforce PS_MANUAL_POLL to be set after PS_ENABLED
From: Adiel Aloni <adiel.aloni(a)intel.com>
[ Upstream commit e16ea4bb516bc21ea2202f2107718b29218bea59 ]
Enforce using PS_MANUAL_POLL in ps hwsim debugfs to trigger a poll,
only if PS_ENABLED was set before.
This is required due to commit c9491367b759 ("mac80211: always update the
PM state of a peer on MGMT / DATA frames") that enforces the ap to
check only mgmt/data frames ps bit, and then update station's power save
accordingly.
When sending only ps-poll (control frame) the ap will not be aware that
the station entered power save.
Setting ps enable before triggering ps_poll, will send NDP with PM bit
enabled first.
Signed-off-by: Adiel Aloni <adiel.aloni(a)intel.com>
Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/mac80211_hwsim.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -728,16 +728,21 @@ static int hwsim_fops_ps_write(void *dat
val != PS_MANUAL_POLL)
return -EINVAL;
- old_ps = data->ps;
- data->ps = val;
-
- local_bh_disable();
if (val == PS_MANUAL_POLL) {
+ if (data->ps != PS_ENABLED)
+ return -EINVAL;
+ local_bh_disable();
ieee80211_iterate_active_interfaces_atomic(
data->hw, IEEE80211_IFACE_ITER_NORMAL,
hwsim_send_ps_poll, data);
- data->ps_poll_pending = true;
- } else if (old_ps == PS_DISABLED && val != PS_DISABLED) {
+ local_bh_enable();
+ return 0;
+ }
+ old_ps = data->ps;
+ data->ps = val;
+
+ local_bh_disable();
+ if (old_ps == PS_DISABLED && val != PS_DISABLED) {
ieee80211_iterate_active_interfaces_atomic(
data->hw, IEEE80211_IFACE_ITER_NORMAL,
hwsim_send_nullfunc_ps, data);
Patches currently in stable-queue which might be from adiel.aloni(a)intel.com are
queue-4.9/mac80211_hwsim-enforce-ps_manual_poll-to-be-set-after-ps_enabled.patch
This is a note to let you know that I've just added the patch titled
mac80211: remove BUG() when interface type is invalid
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mac80211-remove-bug-when-interface-type-is-invalid.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Luca Coelho <luciano.coelho(a)intel.com>
Date: Sun, 29 Oct 2017 11:51:10 +0200
Subject: mac80211: remove BUG() when interface type is invalid
From: Luca Coelho <luciano.coelho(a)intel.com>
[ Upstream commit c7976f5272486e4ff406014c4b43e2fa3b70b052 ]
In the ieee80211_setup_sdata() we check if the interface type is valid
and, if not, call BUG(). This should never happen, but if there is
something wrong with the code, it will not be caught until the bug
happens when an interface is being set up. Calling BUG() is too
extreme for this and a WARN_ON() would be better used instead. Change
that.
Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/iface.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1520,7 +1520,7 @@ static void ieee80211_setup_sdata(struct
break;
case NL80211_IFTYPE_UNSPECIFIED:
case NUM_NL80211_IFTYPES:
- BUG();
+ WARN_ON(1);
break;
}
Patches currently in stable-queue which might be from luciano.coelho(a)intel.com are
queue-4.9/mac80211-remove-bug-when-interface-type-is-invalid.patch
queue-4.9/mac80211_hwsim-enforce-ps_manual_poll-to-be-set-after-ps_enabled.patch
queue-4.9/iwlwifi-mvm-rs-don-t-override-the-rate-history-in-the-search-cycle.patch
queue-4.9/iwlwifi-mvm-fix-rx-skb-header-size-and-align-it-properly.patch
This is a note to let you know that I've just added the patch titled
locking/locktorture: Fix num reader/writer corner cases
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
locking-locktorture-fix-num-reader-writer-corner-cases.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Davidlohr Bueso <dave(a)stgolabs.net>
Date: Mon, 15 May 2017 02:07:23 -0700
Subject: locking/locktorture: Fix num reader/writer corner cases
From: Davidlohr Bueso <dave(a)stgolabs.net>
[ Upstream commit 2ce77d16db4240dd2e422fc0a5c26d3e2ec03446 ]
Things can explode for locktorture if the user does combinations
of nwriters_stress=0 nreaders_stress=0. Fix this by not assuming
we always want to torture writer threads.
Reported-by: Jeremy Linton <jeremy.linton(a)arm.com>
Signed-off-by: Davidlohr Bueso <dbueso(a)suse.de>
Signed-off-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
Reviewed-by: Jeremy Linton <jeremy.linton(a)arm.com>
Tested-by: Jeremy Linton <jeremy.linton(a)arm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/locking/locktorture.c | 76 ++++++++++++++++++++++++-------------------
1 file changed, 44 insertions(+), 32 deletions(-)
--- a/kernel/locking/locktorture.c
+++ b/kernel/locking/locktorture.c
@@ -641,8 +641,7 @@ static void __torture_print_stats(char *
{
bool fail = 0;
int i, n_stress;
- long max = 0;
- long min = statp[0].n_lock_acquired;
+ long max = 0, min = statp ? statp[0].n_lock_acquired : 0;
long long sum = 0;
n_stress = write ? cxt.nrealwriters_stress : cxt.nrealreaders_stress;
@@ -749,7 +748,7 @@ static void lock_torture_cleanup(void)
* such, only perform the underlying torture-specific cleanups,
* and avoid anything related to locktorture.
*/
- if (!cxt.lwsa)
+ if (!cxt.lwsa && !cxt.lrsa)
goto end;
if (writer_tasks) {
@@ -823,6 +822,13 @@ static int __init lock_torture_init(void
firsterr = -EINVAL;
goto unwind;
}
+
+ if (nwriters_stress == 0 && nreaders_stress == 0) {
+ pr_alert("lock-torture: must run at least one locking thread\n");
+ firsterr = -EINVAL;
+ goto unwind;
+ }
+
if (cxt.cur_ops->init)
cxt.cur_ops->init();
@@ -846,17 +852,19 @@ static int __init lock_torture_init(void
#endif
/* Initialize the statistics so that each run gets its own numbers. */
+ if (nwriters_stress) {
+ lock_is_write_held = 0;
+ cxt.lwsa = kmalloc(sizeof(*cxt.lwsa) * cxt.nrealwriters_stress, GFP_KERNEL);
+ if (cxt.lwsa == NULL) {
+ VERBOSE_TOROUT_STRING("cxt.lwsa: Out of memory");
+ firsterr = -ENOMEM;
+ goto unwind;
+ }
- lock_is_write_held = 0;
- cxt.lwsa = kmalloc(sizeof(*cxt.lwsa) * cxt.nrealwriters_stress, GFP_KERNEL);
- if (cxt.lwsa == NULL) {
- VERBOSE_TOROUT_STRING("cxt.lwsa: Out of memory");
- firsterr = -ENOMEM;
- goto unwind;
- }
- for (i = 0; i < cxt.nrealwriters_stress; i++) {
- cxt.lwsa[i].n_lock_fail = 0;
- cxt.lwsa[i].n_lock_acquired = 0;
+ for (i = 0; i < cxt.nrealwriters_stress; i++) {
+ cxt.lwsa[i].n_lock_fail = 0;
+ cxt.lwsa[i].n_lock_acquired = 0;
+ }
}
if (cxt.cur_ops->readlock) {
@@ -873,19 +881,21 @@ static int __init lock_torture_init(void
cxt.nrealreaders_stress = cxt.nrealwriters_stress;
}
- lock_is_read_held = 0;
- cxt.lrsa = kmalloc(sizeof(*cxt.lrsa) * cxt.nrealreaders_stress, GFP_KERNEL);
- if (cxt.lrsa == NULL) {
- VERBOSE_TOROUT_STRING("cxt.lrsa: Out of memory");
- firsterr = -ENOMEM;
- kfree(cxt.lwsa);
- cxt.lwsa = NULL;
- goto unwind;
- }
-
- for (i = 0; i < cxt.nrealreaders_stress; i++) {
- cxt.lrsa[i].n_lock_fail = 0;
- cxt.lrsa[i].n_lock_acquired = 0;
+ if (nreaders_stress) {
+ lock_is_read_held = 0;
+ cxt.lrsa = kmalloc(sizeof(*cxt.lrsa) * cxt.nrealreaders_stress, GFP_KERNEL);
+ if (cxt.lrsa == NULL) {
+ VERBOSE_TOROUT_STRING("cxt.lrsa: Out of memory");
+ firsterr = -ENOMEM;
+ kfree(cxt.lwsa);
+ cxt.lwsa = NULL;
+ goto unwind;
+ }
+
+ for (i = 0; i < cxt.nrealreaders_stress; i++) {
+ cxt.lrsa[i].n_lock_fail = 0;
+ cxt.lrsa[i].n_lock_acquired = 0;
+ }
}
}
@@ -915,12 +925,14 @@ static int __init lock_torture_init(void
goto unwind;
}
- writer_tasks = kzalloc(cxt.nrealwriters_stress * sizeof(writer_tasks[0]),
- GFP_KERNEL);
- if (writer_tasks == NULL) {
- VERBOSE_TOROUT_ERRSTRING("writer_tasks: Out of memory");
- firsterr = -ENOMEM;
- goto unwind;
+ if (nwriters_stress) {
+ writer_tasks = kzalloc(cxt.nrealwriters_stress * sizeof(writer_tasks[0]),
+ GFP_KERNEL);
+ if (writer_tasks == NULL) {
+ VERBOSE_TOROUT_ERRSTRING("writer_tasks: Out of memory");
+ firsterr = -ENOMEM;
+ goto unwind;
+ }
}
if (cxt.cur_ops->readlock) {
Patches currently in stable-queue which might be from dave(a)stgolabs.net are
queue-4.9/locking-locktorture-fix-num-reader-writer-corner-cases.patch
This is a note to let you know that I've just added the patch titled
lkdtm: turn off kcov for lkdtm_rodata_do_nothing:
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
lkdtm-turn-off-kcov-for-lkdtm_rodata_do_nothing.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Tue, 28 Mar 2017 11:57:27 +0200
Subject: lkdtm: turn off kcov for lkdtm_rodata_do_nothing:
From: Arnd Bergmann <arnd(a)arndb.de>
[ Upstream commit 7064dc7fc13b2994d33ae540ffb7a3a05ac463bf ]
I ran into a link error on ARM64 for lkdtm_rodata_do_nothing:
drivers/misc/built-in.o: In function `lkdtm_rodata_do_nothing':
:(.rodata+0x68c8): relocation truncated to fit: R_AARCH64_CALL26 against symbol `__sanitizer_cov_trace_pc' defined in .text section in kernel/built-in.o
I did not analyze this further, but my theory is that we would need a trampoline
to call __sanitizer_cov_trace_pc(), but the linker (correctly) only adds trampolines
for callers in executable sections.
Disabling KCOV for this one file avoids the build failure with no
other practical downsides I can think of.
The problem can only happen on kernels that contain both kcov and
lkdtm, so if we want to backport this, it should be in the earliest
version that has both (v4.8).
Fixes: 5c9a8750a640 ("kernel: add kcov code coverage")
Fixes: 9a49a528dcf3 ("lkdtm: add function for testing .rodata section")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Acked-by: Dmitry Vyukov <dvyukov(a)google.com>
Acked-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/misc/Makefile | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -61,6 +61,8 @@ lkdtm-$(CONFIG_LKDTM) += lkdtm_perms.o
lkdtm-$(CONFIG_LKDTM) += lkdtm_rodata_objcopy.o
lkdtm-$(CONFIG_LKDTM) += lkdtm_usercopy.o
+KCOV_INSTRUMENT_lkdtm_rodata.o := n
+
OBJCOPYFLAGS :=
OBJCOPYFLAGS_lkdtm_rodata_objcopy.o := \
--set-section-flags .text=alloc,readonly \
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.9/lkdtm-turn-off-kcov-for-lkdtm_rodata_do_nothing.patch
queue-4.9/soc-tegra-fix-link-errors-with-pmc-disabled.patch
This is a note to let you know that I've just added the patch titled
leds: pm8058: Silence pointer to integer size warning
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
leds-pm8058-silence-pointer-to-integer-size-warning.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Bjorn Andersson <bjorn.andersson(a)linaro.org>
Date: Thu, 30 Nov 2017 21:16:56 -0800
Subject: leds: pm8058: Silence pointer to integer size warning
From: Bjorn Andersson <bjorn.andersson(a)linaro.org>
[ Upstream commit 8f52df50d9366f770a894d14ef724e5e04574e98 ]
The pointer returned by of_device_get_match_data() doesn't have the same
size as u32 on 64-bit architectures, causing a compile warning when
compile-testing the driver on such platform.
Cast the return value of of_device_get_match_data() to unsigned long and
then to u32 to silence this warning.
Fixes: 7f866986e705 ("leds: add PM8058 LEDs driver")
Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org>
Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org>
Acked-by: Pavel Machek <pavel(a)ucw.cz>
Signed-off-by: Lee Jones <lee.jones(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/leds/leds-pm8058.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/leds/leds-pm8058.c
+++ b/drivers/leds/leds-pm8058.c
@@ -106,7 +106,7 @@ static int pm8058_led_probe(struct platf
if (!led)
return -ENOMEM;
- led->ledtype = (u32)of_device_get_match_data(&pdev->dev);
+ led->ledtype = (u32)(unsigned long)of_device_get_match_data(&pdev->dev);
map = dev_get_regmap(pdev->dev.parent, NULL);
if (!map) {
Patches currently in stable-queue which might be from bjorn.andersson(a)linaro.org are
queue-4.9/leds-pm8058-silence-pointer-to-integer-size-warning.patch
This is a note to let you know that I've just added the patch titled
kvm/svm: Setup MCG_CAP on AMD properly
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kvm-svm-setup-mcg_cap-on-amd-properly.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Borislav Petkov <bp(a)suse.de>
Date: Sun, 26 Mar 2017 23:51:24 +0200
Subject: kvm/svm: Setup MCG_CAP on AMD properly
From: Borislav Petkov <bp(a)suse.de>
[ Upstream commit 74f169090b6f36b867c9df0454366dd9af6f62d1 ]
MCG_CAP[63:9] bits are reserved on AMD. However, on an AMD guest, this
MSR returns 0x100010a. More specifically, bit 24 is set, which is simply
wrong. That bit is MCG_SER_P and is present only on Intel. Thus, clean
up the reserved bits in order not to confuse guests.
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Cc: Joerg Roedel <joro(a)8bytes.org>
Cc: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/svm.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -5449,6 +5449,12 @@ static inline void avic_post_state_resto
avic_handle_ldr_update(vcpu);
}
+static void svm_setup_mce(struct kvm_vcpu *vcpu)
+{
+ /* [63:9] are reserved. */
+ vcpu->arch.mcg_cap &= 0x1ff;
+}
+
static struct kvm_x86_ops svm_x86_ops __ro_after_init = {
.cpu_has_kvm_support = has_svm,
.disabled_by_bios = is_disabled,
@@ -5564,6 +5570,7 @@ static struct kvm_x86_ops svm_x86_ops __
.pmu_ops = &amd_pmu_ops,
.deliver_posted_interrupt = svm_deliver_avic_intr,
.update_pi_irte = svm_update_pi_irte,
+ .setup_mce = svm_setup_mce,
};
static int __init svm_init(void)
Patches currently in stable-queue which might be from bp(a)suse.de are
queue-4.9/x86-mce-handle-broadcasted-mce-gracefully-with-kexec.patch
queue-4.9/perf-stat-issue-a-hw-watchdog-disable-hint.patch
queue-4.9/x86-mm-make-mmap-map_32bit-work-correctly.patch
queue-4.9/edac-altera-fix-peripheral-warnings-for-cyclone5.patch
queue-4.9/kvm-svm-setup-mcg_cap-on-amd-properly.patch
queue-4.9/x86-mce-init-some-cpu-features-early.patch
This is a note to let you know that I've just added the patch titled
kvm: nVMX: Disallow userspace-injected exceptions in guest mode
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kvm-nvmx-disallow-userspace-injected-exceptions-in-guest-mode.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Jim Mattson <jmattson(a)google.com>
Date: Wed, 5 Apr 2017 09:14:40 -0700
Subject: kvm: nVMX: Disallow userspace-injected exceptions in guest mode
From: Jim Mattson <jmattson(a)google.com>
[ Upstream commit 28d06353881939703c34d82a1465136af176c620 ]
The userspace exception injection API and code path are entirely
unprepared for exceptions that might cause a VM-exit from L2 to L1, so
the best course of action may be to simply disallow this for now.
1. The API provides no mechanism for userspace to specify the new DR6
bits for a #DB exception or the new CR2 value for a #PF
exception. Presumably, userspace is expected to modify these registers
directly with KVM_SET_SREGS before the next KVM_RUN ioctl. However, in
the event that L1 intercepts the exception, these registers should not
be changed. Instead, the new values should be provided in the
exit_qualification field of vmcs12 (Intel SDM vol 3, section 27.1).
2. In the case of a userspace-injected #DB, inject_pending_event()
clears DR7.GD before calling vmx_queue_exception(). However, in the
event that L1 intercepts the exception, this is too early, because
DR7.GD should not be modified by a #DB that causes a VM-exit directly
(Intel SDM vol 3, section 27.1).
3. If the injected exception is a #PF, nested_vmx_check_exception()
doesn't properly check whether or not L1 is interested in the
associated error code (using the #PF error code mask and match fields
from vmcs12). It may either return 0 when it should call
nested_vmx_vmexit() or vice versa.
4. nested_vmx_check_exception() assumes that it is dealing with a
hardware-generated exception intercept from L2, with some of the
relevant details (the VM-exit interruption-information and the exit
qualification) live in vmcs02. For userspace-injected exceptions, this
is not the case.
5. prepare_vmcs12() assumes that when its exit_intr_info argument
specifies valid information with a valid error code that it can VMREAD
the VM-exit interruption error code from vmcs02. For
userspace-injected exceptions, this is not the case.
Signed-off-by: Jim Mattson <jmattson(a)google.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/x86.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3070,7 +3070,8 @@ static int kvm_vcpu_ioctl_x86_set_vcpu_e
return -EINVAL;
if (events->exception.injected &&
- (events->exception.nr > 31 || events->exception.nr == NMI_VECTOR))
+ (events->exception.nr > 31 || events->exception.nr == NMI_VECTOR ||
+ is_guest_mode(vcpu)))
return -EINVAL;
/* INITs are latched while in SMM */
Patches currently in stable-queue which might be from jmattson(a)google.com are
queue-4.9/kvm-nvmx-disallow-userspace-injected-exceptions-in-guest-mode.patch
This is a note to let you know that I've just added the patch titled
kprobes/x86: Set kprobes pages read-only
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kprobes-x86-set-kprobes-pages-read-only.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Masami Hiramatsu <mhiramat(a)kernel.org>
Date: Wed, 29 Mar 2017 14:02:46 +0900
Subject: kprobes/x86: Set kprobes pages read-only
From: Masami Hiramatsu <mhiramat(a)kernel.org>
[ Upstream commit d0381c81c2f782fa2131178d11e0cfb23d50d631 ]
Set the pages which is used for kprobes' singlestep buffer
and optprobe's trampoline instruction buffer to readonly.
This can prevent unexpected (or unintended) instruction
modification.
This also passes rodata_test as below.
Without this patch, rodata_test shows a warning:
WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:235 note_page+0x7a9/0xa20
x86/mm: Found insecure W+X mapping at address ffffffffa0000000/0xffffffffa0000000
With this fix, no W+X pages are found:
x86/mm: Checked W+X mappings: passed, no W+X pages found.
rodata_test: all tests were successful
Reported-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Cc: Ananth N Mavinakayanahalli <ananth(a)linux.vnet.ibm.com>
Cc: Anil S Keshavamurthy <anil.s.keshavamurthy(a)intel.com>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Brian Gerst <brgerst(a)gmail.com>
Cc: David S . Miller <davem(a)davemloft.net>
Cc: Denys Vlasenko <dvlasenk(a)redhat.com>
Cc: H. Peter Anvin <hpa(a)zytor.com>
Cc: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Ye Xiaolong <xiaolong.ye(a)intel.com>
Link: http://lkml.kernel.org/r/149076375592.22469.14174394514338612247.stgit@devb…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/kprobes/core.c | 4 ++++
arch/x86/kernel/kprobes/opt.c | 3 +++
2 files changed, 7 insertions(+)
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -409,6 +409,8 @@ static int arch_copy_kprobe(struct kprob
{
int ret;
+ set_memory_rw((unsigned long)p->ainsn.insn & PAGE_MASK, 1);
+
/* Copy an instruction with recovering if other optprobe modifies it.*/
ret = __copy_instruction(p->ainsn.insn, p->addr);
if (!ret)
@@ -423,6 +425,8 @@ static int arch_copy_kprobe(struct kprob
else
p->ainsn.boostable = -1;
+ set_memory_ro((unsigned long)p->ainsn.insn & PAGE_MASK, 1);
+
/* Check whether the instruction modifies Interrupt Flag or not */
p->ainsn.if_modifier = is_IF_modifier(p->ainsn.insn);
--- a/arch/x86/kernel/kprobes/opt.c
+++ b/arch/x86/kernel/kprobes/opt.c
@@ -371,6 +371,7 @@ int arch_prepare_optimized_kprobe(struct
}
buf = (u8 *)op->optinsn.insn;
+ set_memory_rw((unsigned long)buf & PAGE_MASK, 1);
/* Copy instructions into the out-of-line buffer */
ret = copy_optimized_instructions(buf + TMPL_END_IDX, op->kp.addr);
@@ -393,6 +394,8 @@ int arch_prepare_optimized_kprobe(struct
synthesize_reljump(buf + TMPL_END_IDX + op->optinsn.size,
(u8 *)op->kp.addr + op->optinsn.size);
+ set_memory_ro((unsigned long)buf & PAGE_MASK, 1);
+
flush_icache_range((unsigned long) buf,
(unsigned long) buf + TMPL_END_IDX +
op->optinsn.size + RELATIVEJUMP_SIZE);
Patches currently in stable-queue which might be from mhiramat(a)kernel.org are
queue-4.9/perf-session-don-t-rely-on-evlist-in-pipe-mode.patch
queue-4.9/perf-annotate-fix-a-bug-following-symbolic-link-of-a-build-id-file.patch
queue-4.9/kprobes-x86-set-kprobes-pages-read-only.patch
queue-4.9/kprobes-x86-fix-kprobe-booster-not-to-boost-far-call-instructions.patch
queue-4.9/perf-probe-fix-concat_probe_trace_events.patch
queue-4.9/perf-inject-copy-events-when-reordering-events-in-pipe-mode.patch
queue-4.9/perf-probe-return-errno-when-not-hitting-any-event.patch
This is a note to let you know that I've just added the patch titled
kprobes/x86: Fix kprobe-booster not to boost far call instructions
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kprobes-x86-fix-kprobe-booster-not-to-boost-far-call-instructions.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Masami Hiramatsu <mhiramat(a)kernel.org>
Date: Wed, 29 Mar 2017 13:56:56 +0900
Subject: kprobes/x86: Fix kprobe-booster not to boost far call instructions
From: Masami Hiramatsu <mhiramat(a)kernel.org>
[ Upstream commit bd0b90676c30fe640e7ead919b3e38846ac88ab7 ]
Fix the kprobe-booster not to boost far call instruction,
because a call may store the address in the single-step
execution buffer to the stack, which should be modified
after single stepping.
Currently, this instruction will be filtered as not
boostable in resume_execution(), so this is not a
critical issue.
Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Cc: Ananth N Mavinakayanahalli <ananth(a)linux.vnet.ibm.com>
Cc: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Cc: Anil S Keshavamurthy <anil.s.keshavamurthy(a)intel.com>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Brian Gerst <brgerst(a)gmail.com>
Cc: David S . Miller <davem(a)davemloft.net>
Cc: Denys Vlasenko <dvlasenk(a)redhat.com>
Cc: H. Peter Anvin <hpa(a)zytor.com>
Cc: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Ye Xiaolong <xiaolong.ye(a)intel.com>
Link: http://lkml.kernel.org/r/149076340615.22469.14066273186134229909.stgit@devb…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/kprobes/core.c | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -199,6 +199,8 @@ retry:
return (opcode != 0x62 && opcode != 0x67);
case 0x70:
return 0; /* can't boost conditional jump */
+ case 0x90:
+ return opcode != 0x9a; /* can't boost call far */
case 0xc0:
/* can't boost software-interruptions */
return (0xc1 < opcode && opcode < 0xcc) || opcode == 0xcf;
Patches currently in stable-queue which might be from mhiramat(a)kernel.org are
queue-4.9/perf-session-don-t-rely-on-evlist-in-pipe-mode.patch
queue-4.9/perf-annotate-fix-a-bug-following-symbolic-link-of-a-build-id-file.patch
queue-4.9/kprobes-x86-set-kprobes-pages-read-only.patch
queue-4.9/kprobes-x86-fix-kprobe-booster-not-to-boost-far-call-instructions.patch
queue-4.9/perf-probe-fix-concat_probe_trace_events.patch
queue-4.9/perf-inject-copy-events-when-reordering-events-in-pipe-mode.patch
queue-4.9/perf-probe-return-errno-when-not-hitting-any-event.patch
This is a note to let you know that I've just added the patch titled
iwlwifi: mvm: rs: don't override the rate history in the search cycle
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
iwlwifi-mvm-rs-don-t-override-the-rate-history-in-the-search-cycle.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Emmanuel Grumbach <emmanuel.grumbach(a)intel.com>
Date: Thu, 19 Oct 2017 21:36:04 +0300
Subject: iwlwifi: mvm: rs: don't override the rate history in the search cycle
From: Emmanuel Grumbach <emmanuel.grumbach(a)intel.com>
[ Upstream commit 992172e3aec19e5b0ea5b757ba40a146b9282d1e ]
When we are in a search cycle, we try different combinations
of parameters. Those combinations are called 'columns'.
When we switch to a new column, we first need to check if
this column has a suitable rate, if not, we can't try it.
This means we must not erase the statistics we gathered
for the previous column until we are sure that we are
indeed switching column.
The code that tries to switch to a new column first sets
a whole bunch of things for the new column, and only then
checks that we can find suitable rates in that column.
While doing that, the code mistakenly erased the rate
statistics. This code was right until
struct iwl_scale_tbl_info grew up for TPC.
Fix this to make sure we don't erase the rate statistics
until we are sure that we can indeed switch to the new
column.
Note that this bug is really harmless since it causes a
change in the behavior only when we can't find any rate
in the new column which should really not happen. In the
case we do find a suitable we reset the rate statistics
a few lines later anyway.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach(a)intel.com>
Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
@@ -1867,12 +1867,10 @@ static int rs_switch_to_column(struct iw
struct rs_rate *rate = &search_tbl->rate;
const struct rs_tx_column *column = &rs_tx_columns[col_id];
const struct rs_tx_column *curr_column = &rs_tx_columns[tbl->column];
- u32 sz = (sizeof(struct iwl_scale_tbl_info) -
- (sizeof(struct iwl_rate_scale_data) * IWL_RATE_COUNT));
unsigned long rate_mask = 0;
u32 rate_idx = 0;
- memcpy(search_tbl, tbl, sz);
+ memcpy(search_tbl, tbl, offsetof(struct iwl_scale_tbl_info, win));
rate->sgi = column->sgi;
rate->ant = column->ant;
Patches currently in stable-queue which might be from emmanuel.grumbach(a)intel.com are
queue-4.9/iwlwifi-mvm-rs-don-t-override-the-rate-history-in-the-search-cycle.patch
This is a note to let you know that I've just added the patch titled
iwlwifi: mvm: fix RX SKB header size and align it properly
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
iwlwifi-mvm-fix-rx-skb-header-size-and-align-it-properly.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Johannes Berg <johannes.berg(a)intel.com>
Date: Wed, 14 Dec 2016 13:48:04 +0100
Subject: iwlwifi: mvm: fix RX SKB header size and align it properly
From: Johannes Berg <johannes.berg(a)intel.com>
[ Upstream commit 5cddd05c9cbe420436799716d009bc0372ef8268 ]
When receiving a frame, we currently pull in sizeof(*hdr) plus
some extra (crypto/snap), which is too much, most headers aren't
actually sizeof(*hdr) since that takes into account the 4-address
format but doesn't take into account QoS. As a result, a typical
frame will have 4 bytes of the payload in the SKB header already.
Fix this by calculating the correct header length, and now that
we have that, align the end of the SKB header to a multiple of 4
so that the IP header will be aligned properly when pulled in.
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
@@ -104,7 +104,20 @@ static void iwl_mvm_pass_packet_to_mac80
u8 crypt_len,
struct iwl_rx_cmd_buffer *rxb)
{
- unsigned int hdrlen, fraglen;
+ unsigned int hdrlen = ieee80211_hdrlen(hdr->frame_control);
+ unsigned int fraglen;
+
+ /*
+ * The 'hdrlen' (plus the 8 bytes for the SNAP and the crypt_len,
+ * but those are all multiples of 4 long) all goes away, but we
+ * want the *end* of it, which is going to be the start of the IP
+ * header, to be aligned when it gets pulled in.
+ * The beginning of the skb->data is aligned on at least a 4-byte
+ * boundary after allocation. Everything here is aligned at least
+ * on a 2-byte boundary so we can just take hdrlen & 3 and pad by
+ * the result.
+ */
+ skb_reserve(skb, hdrlen & 3);
/* If frame is small enough to fit in skb->head, pull it completely.
* If not, only pull ieee80211_hdr (including crypto if present, and
@@ -118,8 +131,7 @@ static void iwl_mvm_pass_packet_to_mac80
* If the latter changes (there are efforts in the standards group
* to do so) we should revisit this and ieee80211_data_to_8023().
*/
- hdrlen = (len <= skb_tailroom(skb)) ? len :
- sizeof(*hdr) + crypt_len + 8;
+ hdrlen = (len <= skb_tailroom(skb)) ? len : hdrlen + crypt_len + 8;
memcpy(skb_put(skb, hdrlen), hdr, hdrlen);
fraglen = len - hdrlen;
Patches currently in stable-queue which might be from johannes.berg(a)intel.com are
queue-4.9/mac80211-remove-bug-when-interface-type-is-invalid.patch
queue-4.9/mac80211_hwsim-enforce-ps_manual_poll-to-be-set-after-ps_enabled.patch
queue-4.9/mac80211_hwsim-use-per-interface-power-level.patch
queue-4.9/iwlwifi-mvm-fix-rx-skb-header-size-and-align-it-properly.patch
This is a note to let you know that I've just added the patch titled
ipvlan: add L2 check for packets arriving via virtual devices
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ipvlan-add-l2-check-for-packets-arriving-via-virtual-devices.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Mahesh Bandewar <maheshb(a)google.com>
Date: Thu, 7 Dec 2017 15:15:43 -0800
Subject: ipvlan: add L2 check for packets arriving via virtual devices
From: Mahesh Bandewar <maheshb(a)google.com>
[ Upstream commit 92ff42645028fa6f9b8aa767718457b9264316b4 ]
Packets that don't have dest mac as the mac of the master device should
not be entertained by the IPvlan rx-handler. This is mostly true as the
packet path mostly takes care of that, except when the master device is
a virtual device. As demonstrated in the following case -
ip netns add ns1
ip link add ve1 type veth peer name ve2
ip link add link ve2 name iv1 type ipvlan mode l2
ip link set dev iv1 netns ns1
ip link set ve1 up
ip link set ve2 up
ip -n ns1 link set iv1 up
ip addr add 192.168.10.1/24 dev ve1
ip -n ns1 addr 192.168.10.2/24 dev iv1
ping -c2 192.168.10.2
<Works!>
ip neigh show dev ve1
ip neigh show 192.168.10.2 lladdr <random> dev ve1
ping -c2 192.168.10.2
<Still works! Wrong!!>
This patch adds that missing check in the IPvlan rx-handler.
Reported-by: Amit Sikka <amit.sikka(a)ericsson.com>
Signed-off-by: Mahesh Bandewar <maheshb(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ipvlan/ipvlan_core.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/net/ipvlan/ipvlan_core.c
+++ b/drivers/net/ipvlan/ipvlan_core.c
@@ -299,6 +299,10 @@ static int ipvlan_rcv_frame(struct ipvl_
if (dev_forward_skb(ipvlan->dev, skb) == NET_RX_SUCCESS)
success = true;
} else {
+ if (!ether_addr_equal_64bits(eth_hdr(skb)->h_dest,
+ ipvlan->phy_dev->dev_addr))
+ skb->pkt_type = PACKET_OTHERHOST;
+
ret = RX_HANDLER_ANOTHER;
success = true;
}
Patches currently in stable-queue which might be from maheshb(a)google.com are
queue-4.9/bonding-make-speed-duplex-setting-consistent-with-link-state.patch
queue-4.9/ipvlan-add-l2-check-for-packets-arriving-via-virtual-devices.patch
This is a note to let you know that I've just added the patch titled
iommu/iova: Fix underflow bug in __alloc_and_insert_iova_range
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
iommu-iova-fix-underflow-bug-in-__alloc_and_insert_iova_range.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Nate Watterson <nwatters(a)codeaurora.org>
Date: Fri, 7 Apr 2017 01:36:20 -0400
Subject: iommu/iova: Fix underflow bug in __alloc_and_insert_iova_range
From: Nate Watterson <nwatters(a)codeaurora.org>
[ Upstream commit 5016bdb796b3726eec043ca0ce3be981f712c756 ]
Normally, calling alloc_iova() using an iova_domain with insufficient
pfns remaining between start_pfn and dma_limit will fail and return a
NULL pointer. Unexpectedly, if such a "full" iova_domain contains an
iova with pfn_lo == 0, the alloc_iova() call will instead succeed and
return an iova containing invalid pfns.
This is caused by an underflow bug in __alloc_and_insert_iova_range()
that occurs after walking the "full" iova tree when the search ends
at the iova with pfn_lo == 0 and limit_pfn is then adjusted to be just
below that (-1). This (now huge) limit_pfn gives the impression that a
vast amount of space is available between it and start_pfn and thus
a new iova is allocated with the invalid pfn_hi value, 0xFFF.... .
To rememdy this, a check is introduced to ensure that adjustments to
limit_pfn will not underflow.
This issue has been observed in the wild, and is easily reproduced with
the following sample code.
struct iova_domain *iovad = kzalloc(sizeof(*iovad), GFP_KERNEL);
struct iova *rsvd_iova, *good_iova, *bad_iova;
unsigned long limit_pfn = 3;
unsigned long start_pfn = 1;
unsigned long va_size = 2;
init_iova_domain(iovad, SZ_4K, start_pfn, limit_pfn);
rsvd_iova = reserve_iova(iovad, 0, 0);
good_iova = alloc_iova(iovad, va_size, limit_pfn, true);
bad_iova = alloc_iova(iovad, va_size, limit_pfn, true);
Prior to the patch, this yielded:
*rsvd_iova == {0, 0} /* Expected */
*good_iova == {2, 3} /* Expected */
*bad_iova == {-2, -1} /* Oh no... */
After the patch, bad_iova is NULL as expected since inadequate
space remains between limit_pfn and start_pfn after allocating
good_iova.
Signed-off-by: Nate Watterson <nwatters(a)codeaurora.org>
Signed-off-by: Joerg Roedel <jroedel(a)suse.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iommu/iova.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -138,7 +138,7 @@ static int __alloc_and_insert_iova_range
break; /* found a free slot */
}
adjust_limit_pfn:
- limit_pfn = curr_iova->pfn_lo - 1;
+ limit_pfn = curr_iova->pfn_lo ? (curr_iova->pfn_lo - 1) : 0;
move_left:
prev = curr;
curr = rb_prev(curr);
Patches currently in stable-queue which might be from nwatters(a)codeaurora.org are
queue-4.9/iommu-iova-fix-underflow-bug-in-__alloc_and_insert_iova_range.patch
This is a note to let you know that I've just added the patch titled
Input: tsc2007 - check for presence and power down tsc2007 during probe
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
input-tsc2007-check-for-presence-and-power-down-tsc2007-during-probe.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: "H. Nikolaus Schaller" <hns(a)goldelico.com>
Date: Fri, 17 Feb 2017 12:51:19 -0800
Subject: Input: tsc2007 - check for presence and power down tsc2007 during probe
From: "H. Nikolaus Schaller" <hns(a)goldelico.com>
[ Upstream commit 934df23171e7c5b71d937104d4957891c39748ff ]
1. check if chip is really present and don't succeed if it isn't.
2. if it succeeds, power down the chip until accessed
Signed-off-by: H. Nikolaus Schaller <hns(a)goldelico.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/input/touchscreen/tsc2007.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -455,6 +455,14 @@ static int tsc2007_probe(struct i2c_clie
tsc2007_stop(ts);
+ /* power down the chip (TSC2007_SETUP does not ACK on I2C) */
+ err = tsc2007_xfer(ts, PWRDOWN);
+ if (err < 0) {
+ dev_err(&client->dev,
+ "Failed to setup chip: %d\n", err);
+ return err; /* usually, chip does not respond */
+ }
+
err = input_register_device(input_dev);
if (err) {
dev_err(&client->dev,
Patches currently in stable-queue which might be from hns(a)goldelico.com are
queue-4.9/input-tsc2007-check-for-presence-and-power-down-tsc2007-during-probe.patch
This is a note to let you know that I've just added the patch titled
Input: qt1070 - add OF device ID table
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
input-qt1070-add-of-device-id-table.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Javier Martinez Canillas <javier(a)osg.samsung.com>
Date: Thu, 23 Mar 2017 13:33:12 -0700
Subject: Input: qt1070 - add OF device ID table
From: Javier Martinez Canillas <javier(a)osg.samsung.com>
[ Upstream commit cf5cd9d4480a87da78768718cac194a71079b5cb ]
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.
But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
The compatible strings don't have a vendor prefix because that's how it's
used currently, and changing this will be a Device Tree ABI break.
Signed-off-by: Javier Martinez Canillas <javier(a)osg.samsung.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/input/keyboard/qt1070.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/drivers/input/keyboard/qt1070.c
+++ b/drivers/input/keyboard/qt1070.c
@@ -274,9 +274,18 @@ static const struct i2c_device_id qt1070
};
MODULE_DEVICE_TABLE(i2c, qt1070_id);
+#ifdef CONFIG_OF
+static const struct of_device_id qt1070_of_match[] = {
+ { .compatible = "qt1070", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, qt1070_of_match);
+#endif
+
static struct i2c_driver qt1070_driver = {
.driver = {
.name = "qt1070",
+ .of_match_table = of_match_ptr(qt1070_of_match),
.pm = &qt1070_pm_ops,
},
.id_table = qt1070_id,
Patches currently in stable-queue which might be from javier(a)osg.samsung.com are
queue-4.9/asoc-rt5677-add-of-device-id-table.patch
queue-4.9/regulator-core-limit-propagation-of-parent-voltage-count-and-list.patch
queue-4.9/input-qt1070-add-of-device-id-table.patch
This is a note to let you know that I've just added the patch titled
ima: relax requiring a file signature for new files with zero length
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ima-relax-requiring-a-file-signature-for-new-files-with-zero-length.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
Date: Wed, 8 Nov 2017 07:38:28 -0500
Subject: ima: relax requiring a file signature for new files with zero length
From: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
[ Upstream commit b7e27bc1d42e8e0cc58b602b529c25cd0071b336 ]
Custom policies can require file signatures based on LSM labels. These
files are normally created and only afterwards labeled, requiring them
to be signed.
Instead of requiring file signatures based on LSM labels, entire
filesystems could require file signatures. In this case, we need the
ability of writing new files without requiring file signatures.
The definition of a "new" file was originally defined as any file with
a length of zero. Subsequent patches redefined a "new" file to be based
on the FILE_CREATE open flag. By combining the open flag with a file
size of zero, this patch relaxes the file signature requirement.
Fixes: 1ac202e978e1 ima: accept previously set IMA_NEW_FILE
Signed-off-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/integrity/ima/ima_appraise.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -207,7 +207,8 @@ int ima_appraise_measurement(enum ima_ho
if (opened & FILE_CREATED)
iint->flags |= IMA_NEW_FILE;
if ((iint->flags & IMA_NEW_FILE) &&
- !(iint->flags & IMA_DIGSIG_REQUIRED))
+ (!(iint->flags & IMA_DIGSIG_REQUIRED) ||
+ (inode->i_size == 0)))
status = INTEGRITY_PASS;
goto out;
}
Patches currently in stable-queue which might be from zohar(a)linux.vnet.ibm.com are
queue-4.9/ima-relax-requiring-a-file-signature-for-new-files-with-zero-length.patch
This is a note to let you know that I've just added the patch titled
IB/hfi1: Check for QSFP presence before attempting reads
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ib-hfi1-check-for-qsfp-presence-before-attempting-reads.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Easwar Hariharan <easwar.hariharan(a)intel.com>
Date: Mon, 20 Mar 2017 17:25:42 -0700
Subject: IB/hfi1: Check for QSFP presence before attempting reads
From: Easwar Hariharan <easwar.hariharan(a)intel.com>
[ Upstream commit fb897ad315643e5dc1092a115b3cec914b66df9d ]
Attempting to read the status of a QSFP cable creates noise in the logs
and misses out on setting an appropriate Offline/Disabled Reason if the
cable is not plugged in. Check for this prior to attempting the read and
attendant retries.
Fixes: 673b975f1fba ("IB/hfi1: Add QSFP sanity pre-check")
Reviewed-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com>
Signed-off-by: Easwar Hariharan <easwar.hariharan(a)intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com>
Signed-off-by: Doug Ledford <dledford(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/hfi1/chip.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/infiniband/hw/hfi1/chip.c
+++ b/drivers/infiniband/hw/hfi1/chip.c
@@ -9489,8 +9489,11 @@ static int test_qsfp_read(struct hfi1_pp
int ret;
u8 status;
- /* report success if not a QSFP */
- if (ppd->port_type != PORT_TYPE_QSFP)
+ /*
+ * Report success if not a QSFP or, if it is a QSFP, but the cable is
+ * not present
+ */
+ if (ppd->port_type != PORT_TYPE_QSFP || !qsfp_mod_present(ppd))
return 0;
/* read byte 2, the status byte */
Patches currently in stable-queue which might be from easwar.hariharan(a)intel.com are
queue-4.9/ib-hfi1-check-for-qsfp-presence-before-attempting-reads.patch
This is a note to let you know that I've just added the patch titled
i40e: only register client on iWarp-capable devices
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
i40e-only-register-client-on-iwarp-capable-devices.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Mitch Williams <mitch.a.williams(a)intel.com>
Date: Tue, 4 Apr 2017 12:40:16 -0700
Subject: i40e: only register client on iWarp-capable devices
From: Mitch Williams <mitch.a.williams(a)intel.com>
[ Upstream commit 004eb614c4d2fcc12a98714fd887a860582f203a ]
The client interface is only intended for use on devices that support
iWarp. Only register with the client if this is the case.
This fixes a panic when loading i40iw on X710 devices.
Signed-off-by: Mitch Williams <mitch.a.williams(a)intel.com>
Reported-by: Stefan Assmann <sassmann(a)kpanic.de>
Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -11142,10 +11142,12 @@ static int i40e_probe(struct pci_dev *pd
round_jiffies(jiffies + pf->service_timer_period));
/* add this PF to client device list and launch a client service task */
- err = i40e_lan_add_device(pf);
- if (err)
- dev_info(&pdev->dev, "Failed to add PF to client API service list: %d\n",
- err);
+ if (pf->flags & I40E_FLAG_IWARP_ENABLED) {
+ err = i40e_lan_add_device(pf);
+ if (err)
+ dev_info(&pdev->dev, "Failed to add PF to client API service list: %d\n",
+ err);
+ }
#ifdef I40E_FCOE
/* create FCoE interface */
@@ -11323,10 +11325,11 @@ static void i40e_remove(struct pci_dev *
i40e_vsi_release(pf->vsi[pf->lan_vsi]);
/* remove attached clients */
- ret_code = i40e_lan_del_device(pf);
- if (ret_code) {
- dev_warn(&pdev->dev, "Failed to delete client device: %d\n",
- ret_code);
+ if (pf->flags & I40E_FLAG_IWARP_ENABLED) {
+ ret_code = i40e_lan_del_device(pf);
+ if (ret_code)
+ dev_warn(&pdev->dev, "Failed to delete client device: %d\n",
+ ret_code);
}
/* shutdown and destroy the HMC */
Patches currently in stable-queue which might be from mitch.a.williams(a)intel.com are
queue-4.9/i40e-only-register-client-on-iwarp-capable-devices.patch
This is a note to let you know that I've just added the patch titled
i40e/i40evf: Fix use after free in Rx cleanup path
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
i40e-i40evf-fix-use-after-free-in-rx-cleanup-path.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Alexander Duyck <alexander.h.duyck(a)intel.com>
Date: Tue, 21 Feb 2017 15:55:41 -0800
Subject: i40e/i40evf: Fix use after free in Rx cleanup path
From: Alexander Duyck <alexander.h.duyck(a)intel.com>
[ Upstream commit 741b8b832a57402380be79d7d11a59eaf57fff3b ]
We need to reset skb back to NULL when we have freed it in the Rx cleanup
path. I found one spot where this wasn't occurring so this patch fixes it.
Change-ID: Iaca68934200732cd4a63eb0bd83b539c95f8c4dd
Signed-off-by: Alexander Duyck <alexander.h.duyck(a)intel.com>
Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 1 +
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 1 +
2 files changed, 2 insertions(+)
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -1820,6 +1820,7 @@ static int i40e_clean_rx_irq(struct i40e
*/
if (unlikely(i40e_test_staterr(rx_desc, BIT(I40E_RXD_QW1_ERROR_SHIFT)))) {
dev_kfree_skb_any(skb);
+ skb = NULL;
continue;
}
--- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
@@ -1262,6 +1262,7 @@ static int i40e_clean_rx_irq(struct i40e
*/
if (unlikely(i40e_test_staterr(rx_desc, BIT(I40E_RXD_QW1_ERROR_SHIFT)))) {
dev_kfree_skb_any(skb);
+ skb = NULL;
continue;
}
Patches currently in stable-queue which might be from alexander.h.duyck(a)intel.com are
queue-4.9/i40e-i40evf-fix-use-after-free-in-rx-cleanup-path.patch
This is a note to let you know that I've just added the patch titled
i40e: fix ethtool to get EEPROM data from X722 interface
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
i40e-fix-ethtool-to-get-eeprom-data-from-x722-interface.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Lihong Yang <lihong.yang(a)intel.com>
Date: Mon, 30 Jan 2017 12:29:32 -0800
Subject: i40e: fix ethtool to get EEPROM data from X722 interface
From: Lihong Yang <lihong.yang(a)intel.com>
[ Upstream commit c271dd6c391b535226cf1a81aaad9f33cb5899d3 ]
Currently ethtool -e will error out with a X722 interface
as its EEPROM has a scope limit at offset 0x5B9FFF.
This patch fixes the issue by setting the EEPROM length to
the scope limit to avoid NVM read failure beyond that.
Change-ID: I0b7d4dd6c7f2a57cace438af5dffa0f44c229372
Signed-off-by: Lihong Yang <lihong.yang(a)intel.com>
Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -1135,6 +1135,11 @@ static int i40e_get_eeprom_len(struct ne
struct i40e_hw *hw = &np->vsi->back->hw;
u32 val;
+#define X722_EEPROM_SCOPE_LIMIT 0x5B9FFF
+ if (hw->mac.type == I40E_MAC_X722) {
+ val = X722_EEPROM_SCOPE_LIMIT + 1;
+ return val;
+ }
val = (rd32(hw, I40E_GLPCI_LBARCTRL)
& I40E_GLPCI_LBARCTRL_FL_SIZE_MASK)
>> I40E_GLPCI_LBARCTRL_FL_SIZE_SHIFT;
Patches currently in stable-queue which might be from lihong.yang(a)intel.com are
queue-4.9/i40e-fix-ethtool-to-get-eeprom-data-from-x722-interface.patch
This is a note to let you know that I've just added the patch titled
i40e: Acquire NVM lock before reads on all devices
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
i40e-acquire-nvm-lock-before-reads-on-all-devices.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Aaron Salter <aaron.k.salter(a)intel.com>
Date: Fri, 2 Dec 2016 12:33:02 -0800
Subject: i40e: Acquire NVM lock before reads on all devices
From: Aaron Salter <aaron.k.salter(a)intel.com>
[ Upstream commit 96a39aed25e6559b160786117df124084feb9080 ]
Acquire NVM lock before reads on all devices. Previously, locks were
only used for X722 and later. Fixes an issue where simultaneous X710
NVM accesses were interfering with each other.
Change-ID: If570bb7acf958cef58725ec2a2011cead6f80638
Signed-off-by: Aaron Salter <aaron.k.salter(a)intel.com>
Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/i40e/i40e_nvm.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/net/ethernet/intel/i40e/i40e_nvm.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_nvm.c
@@ -292,14 +292,14 @@ i40e_status i40e_read_nvm_word(struct i4
{
enum i40e_status_code ret_code = 0;
- if (hw->flags & I40E_HW_FLAG_AQ_SRCTL_ACCESS_ENABLE) {
- ret_code = i40e_acquire_nvm(hw, I40E_RESOURCE_READ);
- if (!ret_code) {
+ ret_code = i40e_acquire_nvm(hw, I40E_RESOURCE_READ);
+ if (!ret_code) {
+ if (hw->flags & I40E_HW_FLAG_AQ_SRCTL_ACCESS_ENABLE) {
ret_code = i40e_read_nvm_word_aq(hw, offset, data);
- i40e_release_nvm(hw);
+ } else {
+ ret_code = i40e_read_nvm_word_srctl(hw, offset, data);
}
- } else {
- ret_code = i40e_read_nvm_word_srctl(hw, offset, data);
+ i40e_release_nvm(hw);
}
return ret_code;
}
Patches currently in stable-queue which might be from aaron.k.salter(a)intel.com are
queue-4.9/i40e-acquire-nvm-lock-before-reads-on-all-devices.patch
This is a note to let you know that I've just added the patch titled
HID: reject input outside logical range only if null state is set
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
hid-reject-input-outside-logical-range-only-if-null-state-is-set.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: "Valtteri Heikkilä" <rnd(a)nic.fi>
Date: Tue, 14 Feb 2017 23:14:32 +0000
Subject: HID: reject input outside logical range only if null state is set
From: "Valtteri Heikkilä" <rnd(a)nic.fi>
[ Upstream commit 3f3752705dbd50b66b66ad7b4d54fe33d2f746ed ]
This patch fixes an issue in drivers/hid/hid-input.c where USB HID
control null state flag is not checked upon rejecting inputs outside
logical minimum-maximum range. The check should be made according to USB
HID specification 1.11, section 6.2.2.5, p.31. The fix will resolve
issues with some game controllers, such as:
https://bugzilla.kernel.org/show_bug.cgi?id=68621
[tk(a)the-tk.com: shortened and fixed spelling in commit message]
Signed-off-by: Valtteri Heikkilä <rnd(a)nic.fi>
Signed-off-by: Tomasz Kramkowski <tk(a)the-tk.com>
Acked-By: Benjamin Tissoires <benjamin.tissoires(a)redhat.com>
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/hid-input.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -1156,6 +1156,7 @@ void hidinput_hid_event(struct hid_devic
* don't specify logical min and max.
*/
if ((field->flags & HID_MAIN_ITEM_VARIABLE) &&
+ (field->flags & HID_MAIN_ITEM_NULL_STATE) &&
(field->logical_minimum < field->logical_maximum) &&
(value < field->logical_minimum ||
value > field->logical_maximum)) {
Patches currently in stable-queue which might be from rnd(a)nic.fi are
queue-4.9/hid-reject-input-outside-logical-range-only-if-null-state-is-set.patch
This is a note to let you know that I've just added the patch titled
HID: elo: clear BTN_LEFT mapping
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
hid-elo-clear-btn_left-mapping.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Jiri Kosina <jkosina(a)suse.cz>
Date: Wed, 22 Nov 2017 11:19:51 +0100
Subject: HID: elo: clear BTN_LEFT mapping
From: Jiri Kosina <jkosina(a)suse.cz>
[ Upstream commit 9abd04af951e5734c9d5cfee9b49790844b734cf ]
ELO devices have one Button usage in GenDesk field, which makes hid-input map
it to BTN_LEFT; that confuses userspace, which then considers the device to be
a mouse/touchpad instead of touchscreen.
Fix that by unmapping BTN_LEFT and keeping only BTN_TOUCH in place.
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/hid-elo.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/hid/hid-elo.c
+++ b/drivers/hid/hid-elo.c
@@ -42,6 +42,12 @@ static int elo_input_configured(struct h
{
struct input_dev *input = hidinput->input;
+ /*
+ * ELO devices have one Button usage in GenDesk field, which makes
+ * hid-input map it to BTN_LEFT; that confuses userspace, which then
+ * considers the device to be a mouse/touchpad instead of touchscreen.
+ */
+ clear_bit(BTN_LEFT, input->keybit);
set_bit(BTN_TOUCH, input->keybit);
set_bit(ABS_PRESSURE, input->absbit);
input_set_abs_params(input, ABS_PRESSURE, 0, 256, 0, 0);
Patches currently in stable-queue which might be from jkosina(a)suse.cz are
queue-4.9/hid-elo-clear-btn_left-mapping.patch
queue-4.9/hid-clamp-input-to-logical-range-if-no-null-state.patch
queue-4.9/hid-reject-input-outside-logical-range-only-if-null-state-is-set.patch
This is a note to let you know that I've just added the patch titled
HID: clamp input to logical range if no null state
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
hid-clamp-input-to-logical-range-if-no-null-state.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Tomasz Kramkowski <tk(a)the-tk.com>
Date: Tue, 14 Mar 2017 13:29:13 +0000
Subject: HID: clamp input to logical range if no null state
From: Tomasz Kramkowski <tk(a)the-tk.com>
[ Upstream commit c3883fe06488a483658ba5d849b70e49bee15e7c ]
This patch fixes an issue in drivers/hid/hid-input.c where values
outside of the logical range are not clamped when "null state" bit of
the input control is not set.
This was discussed on the lists [1] and this change stems from the fact
due to the ambiguity of the HID specification it might be appropriate to
follow Microsoft's own interpretation of the specification. As noted in
Microsoft's documentation [2] in the section titled "Required HID usages
for digitizers" it is noted that values reported outside the logical
range "will be considered as invalid data and the value will be changed
to the nearest boundary value (logical min/max)."
This patch fixes an issue where the (1292:4745) Innomedia INNEX
GENESIS/ATARI reports out of range values for its X and Y axis of the
DPad which, due to the null state bit being unset, are forwarded to
userspace as is. Now these values will get clamped to the logical range
before being forwarded to userspace. This device was also used to test
this patch.
This patch expands on commit 3f3752705dbd ("HID: reject input outside
logical range only if null state is set").
[1]: http://lkml.kernel.org/r/20170307131036.GA853@gaia.local
[2]: https://msdn.microsoft.com/en-us/library/windows/hardware/dn672278(v=vs.85)…
Signed-off-by: Tomasz Kramkowski <tk(a)the-tk.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com>
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/hid-input.c | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -1149,19 +1149,26 @@ void hidinput_hid_event(struct hid_devic
/*
* Ignore out-of-range values as per HID specification,
- * section 5.10 and 6.2.25.
+ * section 5.10 and 6.2.25, when NULL state bit is present.
+ * When it's not, clamp the value to match Microsoft's input
+ * driver as mentioned in "Required HID usages for digitizers":
+ * https://msdn.microsoft.com/en-us/library/windows/hardware/dn672278(v=vs.85)…
*
* The logical_minimum < logical_maximum check is done so that we
* don't unintentionally discard values sent by devices which
* don't specify logical min and max.
*/
if ((field->flags & HID_MAIN_ITEM_VARIABLE) &&
- (field->flags & HID_MAIN_ITEM_NULL_STATE) &&
- (field->logical_minimum < field->logical_maximum) &&
- (value < field->logical_minimum ||
- value > field->logical_maximum)) {
- dbg_hid("Ignoring out-of-range value %x\n", value);
- return;
+ (field->logical_minimum < field->logical_maximum)) {
+ if (field->flags & HID_MAIN_ITEM_NULL_STATE &&
+ (value < field->logical_minimum ||
+ value > field->logical_maximum)) {
+ dbg_hid("Ignoring out-of-range value %x\n", value);
+ return;
+ }
+ value = clamp(value,
+ field->logical_minimum,
+ field->logical_maximum);
}
/*
Patches currently in stable-queue which might be from tk(a)the-tk.com are
queue-4.9/hid-clamp-input-to-logical-range-if-no-null-state.patch
queue-4.9/hid-reject-input-outside-logical-range-only-if-null-state-is-set.patch
This is a note to let you know that I've just added the patch titled
fm10k: correctly check if interface is removed
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
fm10k-correctly-check-if-interface-is-removed.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Phil Turnbull <phil.turnbull(a)oracle.com>
Date: Wed, 23 Nov 2016 13:33:58 -0500
Subject: fm10k: correctly check if interface is removed
From: Phil Turnbull <phil.turnbull(a)oracle.com>
[ Upstream commit 540fca35e38d15777b310f450f63f056e63039f5 ]
FM10K_REMOVED expects a hardware address, not a 'struct fm10k_hw'.
Fixes: 5cb8db4a4cbc ("fm10k: Add support for VF")
Signed-off-by: Phil Turnbull <phil.turnbull(a)oracle.com>
Tested-by: Krishneil Singh <krishneil.k.singh(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
@@ -942,7 +942,7 @@ static void fm10k_self_test(struct net_d
memset(data, 0, sizeof(*data) * FM10K_TEST_LEN);
- if (FM10K_REMOVED(hw)) {
+ if (FM10K_REMOVED(hw->hw_addr)) {
netif_err(interface, drv, dev,
"Interface removed - test blocked\n");
eth_test->flags |= ETH_TEST_FL_FAILED;
Patches currently in stable-queue which might be from phil.turnbull(a)oracle.com are
queue-4.9/fm10k-correctly-check-if-interface-is-removed.patch
This is a note to let you know that I've just added the patch titled
f2fs: relax node version check for victim data in gc
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
f2fs-relax-node-version-check-for-victim-data-in-gc.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Jaegeuk Kim <jaegeuk(a)kernel.org>
Date: Tue, 21 Mar 2017 10:59:50 -0400
Subject: f2fs: relax node version check for victim data in gc
From: Jaegeuk Kim <jaegeuk(a)kernel.org>
[ Upstream commit c13ff37e359bb3eacf4e1760dcea8d9760aa7459 ]
- has_not_enough_free_secs
node_secs: 0 dent_secs: 0 freed:0 free_segments:103 reserved:104
- f2fs_gc
- get_victim_by_default
alloc_mode 0, gc_mode 1, max_search 2672, offset 4654, ofs_unit 1
- do_garbage_collect
start_segno 3976, end_segno 3977 type 0
- is_alive
nid 22797, blkaddr 2131882, ofs_in_node 0, version 0x8/0x0
- gc_data_segment 766, segno 3976, block 512/426 not alive
So, this patch fixes subtle corrupted case where node version does not match
to summary version which results in infinite loop by gc.
Reported-by: Yunlei He <heyunlei(a)huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/f2fs/gc.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -538,8 +538,10 @@ static bool is_alive(struct f2fs_sb_info
get_node_info(sbi, nid, dni);
if (sum->version != dni->version) {
- f2fs_put_page(node_page, 1);
- return false;
+ f2fs_msg(sbi->sb, KERN_WARNING,
+ "%s: valid data with mismatched node version.",
+ __func__);
+ set_sbi_flag(sbi, SBI_NEED_FSCK);
}
*nofs = ofs_of_node(node_page);
Patches currently in stable-queue which might be from jaegeuk(a)kernel.org are
queue-4.9/f2fs-relax-node-version-check-for-victim-data-in-gc.patch
This is a note to let you know that I've just added the patch titled
eventpoll.h: fix epoll event masks
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
eventpoll.h-fix-epoll-event-masks.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Greg KH <gregkh(a)linuxfoundation.org>
Date: Wed, 8 Mar 2017 19:03:03 +0100
Subject: eventpoll.h: fix epoll event masks
From: Greg KH <gregkh(a)linuxfoundation.org>
[ Upstream commit 6f051e4a685b768f3704c7c069aa1edee3010622 ]
[resend due to me forgetting to cc: linux-api the first time around I
posted these back on Feb 23]
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
When userspace tries to use these defines, it complains that it needs to
be an unsigned 1 that is shifted, so libc implementations have to create
their own version. Fix this by defining it properly so that libcs can
just use the kernel uapi header.
Reported-by: Elliott Hughes <enh(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/uapi/linux/eventpoll.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/include/uapi/linux/eventpoll.h
+++ b/include/uapi/linux/eventpoll.h
@@ -40,7 +40,7 @@
#define EPOLLRDHUP 0x00002000
/* Set exclusive wakeup mode for the target file descriptor */
-#define EPOLLEXCLUSIVE (1 << 28)
+#define EPOLLEXCLUSIVE (1U << 28)
/*
* Request the handling of system wakeup events so as to prevent system suspends
@@ -52,13 +52,13 @@
*
* Requires CAP_BLOCK_SUSPEND
*/
-#define EPOLLWAKEUP (1 << 29)
+#define EPOLLWAKEUP (1U << 29)
/* Set the One Shot behaviour for the target file descriptor */
-#define EPOLLONESHOT (1 << 30)
+#define EPOLLONESHOT (1U << 30)
/* Set the Edge Triggered behaviour for the target file descriptor */
-#define EPOLLET (1 << 31)
+#define EPOLLET (1U << 31)
/*
* On x86-64 make the 64bit structure have the same alignment as the
Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are
queue-4.9/nfc-pn533-change-order-of-free_irq-and-dev-unregistration.patch
queue-4.9/dmaengine-bcm2835-dma-use-vchan_terminate_vdesc-instead-of-desc_free.patch
queue-4.9/asoc-rt5677-add-of-device-id-table.patch
queue-4.9/arm-dra7-hwmod_data-prevent-wait_target_disable-error-for-usb_otg_ss.patch
queue-4.9/arm-dts-omap3-n900-fix-the-audio-codec-s-reset-pin.patch
queue-4.9/hid-elo-clear-btn_left-mapping.patch
queue-4.9/sched-stop-resched_cpu-from-sending-ipis-to-offline-cpus.patch
queue-4.9/arm64-dts-r8a7796-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/mips-bpf-quit-clobbering-callee-saved-registers-in-jit-code.patch
queue-4.9/net-faraday-add-missing-include-of-of.h.patch
queue-4.9/asoc-rcar-ssi-don-t-set-ssicr.ckdv-000-with-ssiwsr.cont.patch
queue-4.9/selinux-check-for-address-length-in-selinux_socket_bind.patch
queue-4.9/drm-ttm-never-add-bo-that-failed-to-validate-to-the-lru-list.patch
queue-4.9/alsa-hda-add-geminilake-id-to-skl_plus.patch
queue-4.9/arm-dts-r8a7791-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/perf-buildid-do-not-assume-that-readlink-returns-a-null-terminated-string.patch
queue-4.9/v4l-vsp1-prevent-multiple-streamon-race-commencing-pipeline-early.patch
queue-4.9/net-thunderx-set-max-queue-count-taking-xdp_tx-into-account.patch
queue-4.9/arm-dts-adjust-moxart-irq-controller-and-flags.patch
queue-4.9/drm-defer-disabling-the-vblank-irq-until-the-next-interrupt-for-instant-off.patch
queue-4.9/spi-omap2-mcspi-poll-omap2_mcspi_chstat_rxs-for-pio-transfer.patch
queue-4.9/ath10k-fix-invalid-sts_cap_offset_mask.patch
queue-4.9/drm-sun4i-fix-up-error-path-cleanup-for-master-bind-function.patch
queue-4.9/qed-always-publish-vf-link-from-leading-hwfn.patch
queue-4.9/qed-fix-tm-block-ilt-allocation.patch
queue-4.9/printk-correctly-handle-preemption-in-console_unlock.patch
queue-4.9/powerpc-nohash-fix-use-of-mmu_has_feature-in-setup_initial_memory_limit.patch
queue-4.9/media-cpia2-fix-a-couple-off-by-one-bugs.patch
queue-4.9/arm-dts-r7s72100-fix-ethernet-clock-parent.patch
queue-4.9/net-hns-correct-hns-rss-key-set-function.patch
queue-4.9/bonding-make-speed-duplex-setting-consistent-with-link-state.patch
queue-4.9/sched-stop-switched_to_rt-from-sending-ipis-to-offline-cpus.patch
queue-4.9/mac80211-remove-bug-when-interface-type-is-invalid.patch
queue-4.9/perf-session-don-t-rely-on-evlist-in-pipe-mode.patch
queue-4.9/net-fec-add-phy-reset-gpios-probe_defer-check.patch
queue-4.9/vfio-spapr_tce-check-kzalloc-return-when-preregistering-memory.patch
queue-4.9/kvm-nvmx-disallow-userspace-injected-exceptions-in-guest-mode.patch
queue-4.9/sched-act_csum-don-t-mangle-tcp-and-udp-gso-packets.patch
queue-4.9/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch
queue-4.9/powerpc-avoid-taking-a-data-miss-on-every-userspace-instruction-miss.patch
queue-4.9/net-xfrm-allow-clearing-socket-xfrm-policies.patch
queue-4.9/omapfb-dss-handle-return-errors-in-dss_init_ports.patch
queue-4.9/mtd-nand-ifc-update-bufnum-mask-for-ver-2.0.0.patch
queue-4.9/mips-r2-on-r6-emu-clear-bltzall-and-bgezall-debugfs-counters.patch
queue-4.9/regulator-core-limit-propagation-of-parent-voltage-count-and-list.patch
queue-4.9/dmaengine-imx-sdma-add-1ms-delay-to-ensure-sdma-channel-is-stopped.patch
queue-4.9/wil6210-fix-protection-against-connections-during-reset.patch
queue-4.9/md.c-didn-t-unlock-the-mddev-before-return-einval-in-array_size_store.patch
queue-4.9/net-8021q-create-device-with-all-possible-features-in-wanted_features.patch
queue-4.9/lkdtm-turn-off-kcov-for-lkdtm_rodata_do_nothing.patch
queue-4.9/drivers-net-xgene-fix-wrong-logical-operation.patch
queue-4.9/pci-hv-lock-pci-bus-on-device-eject.patch
queue-4.9/ath10k-fix-fetching-channel-during-potential-radar-detection.patch
queue-4.9/net-ethernet-bgmac-allow-mac-address-to-be-specified-in-dtb.patch
queue-4.9/powerpc-modules-don-t-try-to-restore-r2-after-a-sibling-call.patch
queue-4.9/rtmutex-fix-pi-chain-order-integrity.patch
queue-4.9/alsa-firewire-digi00x-handle-all-midi-messages-on-streaming-packets.patch
queue-4.9/drm-amdgpu-fail-fb-creation-from-imported-dma-bufs.-v2.patch
queue-4.9/leds-pm8058-silence-pointer-to-integer-size-warning.patch
queue-4.9/qed-correct-msi-x-for-storage.patch
queue-4.9/s390-topology-fix-typo-in-early-topology-code.patch
queue-4.9/ath10k-fix-compile-time-sanity-check-for-ce4-buffer-size.patch
queue-4.9/arm-dts-silk-correct-clock-of-du1.patch
queue-4.9/of-fix-of_device_get_modalias-returned-length-when-truncating-buffers.patch
queue-4.9/clk-qcom-msm8916-fix-mnd_width-for-codec_digcodec.patch
queue-4.9/alsa-firewire-digi00x-add-support-for-console-models-of-digi00x-series.patch
queue-4.9/arm-dts-exynos-correct-trats2-panel-reset-line.patch
queue-4.9/power-supply-ab8500_charger-fix-an-error-handling-path.patch
queue-4.9/perf-tools-make-perf_event__synthesize_mmap_events-scale.patch
queue-4.9/perf-annotate-fix-a-bug-following-symbolic-link-of-a-build-id-file.patch
queue-4.9/usb-dwc2-make-sure-we-disconnect-the-gadget-state.patch
queue-4.9/veth-set-peer-gso-values.patch
queue-4.9/arm-dts-r8a7792-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/mips-r2-on-r6-emu-fix-blezl-and-bgtzl-identification.patch
queue-4.9/i40e-acquire-nvm-lock-before-reads-on-all-devices.patch
queue-4.9/drivers-net-xgene-fix-hardware-checksum-setting.patch
queue-4.9/usb-misc-lvs-fix-race-condition-in-disconnect-handling.patch
queue-4.9/bonding-refine-bond_fold_stats-wrap-detection.patch
queue-4.9/mac80211_hwsim-enforce-ps_manual_poll-to-be-set-after-ps_enabled.patch
queue-4.9/driver-adm1275-set-the-m-b-and-r-coefficients-correctly-for-power.patch
queue-4.9/pwm-stmpe-fix-wrong-register-offset-for-hwpwm-2-case.patch
queue-4.9/scsi-sg-check-for-valid-direction-before-starting-the-request.patch
queue-4.9/x86-mce-handle-broadcasted-mce-gracefully-with-kexec.patch
queue-4.9/drm-radeon-fail-fb-creation-from-imported-dma-bufs.patch
queue-4.9/clk-meson-gxbb-fix-wrong-clock-for-saradc-sana.patch
queue-4.9/iwlwifi-mvm-rs-don-t-override-the-rate-history-in-the-search-cycle.patch
queue-4.9/mm-fix-false-positive-vm_bug_on-in-page_cache_-get-add-_speculative.patch
queue-4.9/sysrq-reset-the-watchdog-timers-while-displaying-high-resolution-timers.patch
queue-4.9/locking-locktorture-fix-num-reader-writer-corner-cases.patch
queue-4.9/ath10k-update-tdls-teardown-state-to-target.patch
queue-4.9/nfc-nfcmrvl-include-unaligned.h-instead-of-access_ok.h.patch
queue-4.9/v4l-vsp1-register-pipe-with-output-wpf.patch
queue-4.9/rcutorture-configinit-fix-build-directory-error-message.patch
queue-4.9/ath10k-fix-a-warning-during-channel-switch-with-multiple-vaps.patch
queue-4.9/netem-apply-correct-delay-when-rate-throttling.patch
queue-4.9/zd1211rw-fix-null-deref-at-probe.patch
queue-4.9/mac80211_hwsim-use-per-interface-power-level.patch
queue-4.9/scsi-devinfo-apply-to-hp-xp-the-same-flags-as-hitachi-vsp.patch
queue-4.9/tty-amba-pl011-fix-spurious-tx-interrupts.patch
queue-4.9/kprobes-x86-set-kprobes-pages-read-only.patch
queue-4.9/batman-adv-handle-race-condition-for-claims-between-gateways.patch
queue-4.9/input-qt1070-add-of-device-id-table.patch
queue-4.9/hid-clamp-input-to-logical-range-if-no-null-state.patch
queue-4.9/input-tsc2007-check-for-presence-and-power-down-tsc2007-during-probe.patch
queue-4.9/perf-stat-issue-a-hw-watchdog-disable-hint.patch
queue-4.9/vxlan-vxlan-dev-should-inherit-lowerdev-s-gso_max_size.patch
queue-4.9/braille-console-fix-value-returned-by-_braille_console_setup.patch
queue-4.9/drm-sun4i-set-drm_crtc.port-to-the-underlying-tcon-s-output-port-node.patch
queue-4.9/fm10k-correctly-check-if-interface-is-removed.patch
queue-4.9/x86-mm-make-mmap-map_32bit-work-correctly.patch
queue-4.9/drm-sun4i-fix-tcon-clock-and-regmap-initialization-sequence.patch
queue-4.9/drm-rcar-du-handle-event-when-disabling-crtcs.patch
queue-4.9/regulator-isl9305-fix-array-size.patch
queue-4.9/kprobes-x86-fix-kprobe-booster-not-to-boost-far-call-instructions.patch
queue-4.9/arm-dts-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch
queue-4.9/arm-dts-r8a7794-correct-clock-of-du1.patch
queue-4.9/arm-brcmstb-enable-zone_dma-for-non-64-bit-capable-peripherals.patch
queue-4.9/arm-dts-r8a7794-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/scsi-ipr-fix-missed-eh-wakeup.patch
queue-4.9/perf-sort-fix-segfault-with-basic-block-cycles-sort-dimension.patch
queue-4.9/iommu-iova-fix-underflow-bug-in-__alloc_and_insert_iova_range.patch
queue-4.9/timers-sched_clock-update-timeout-for-clock-wrap.patch
queue-4.9/perf-trace-handle-unpaired-raw_syscalls-sys_exit-event.patch
queue-4.9/reiserfs-make-cancel_old_flush-reliable.patch
queue-4.9/nfc-nfcmrvl-double-free-on-error-path.patch
queue-4.9/clk-sunxi-ng-a33-add-offset-and-minimum-value-for-ddr1-pll-n-factor.patch
queue-4.9/md-raid6-fix-anomily-when-recovering-a-single-device-in-raid6.patch
queue-4.9/perf-probe-fix-concat_probe_trace_events.patch
queue-4.9/bnxt_en-don-t-print-link-speed-1-no-longer-supported-messages.patch
queue-4.9/drm-qxl-don-t-alloc-fbdev-if-emulation-is-not-supported.patch
queue-4.9/arm-dts-bcm2835-add-index-to-the-ethernet-alias.patch
queue-4.9/userns-don-t-fail-follow_automount-based-on-s_user_ns.patch
queue-4.9/blk-throttle-make-sure-expire-time-isn-t-too-big.patch
queue-4.9/blkcg-fix-double-free-of-new_blkg-in-blkcg_init_queue.patch
queue-4.9/wil6210-fix-memory-access-violation-in-wil_memcpy_from-toio_32.patch
queue-4.9/video-hdmi-allow-empty-hdmi-infoframes.patch
queue-4.9/powerpc-xmon-fix-an-unexpected-xmon-on-off-state-change.patch
queue-4.9/serial-imx-setup-dcedte-early-and-ensure-dcd-and-ri-irqs-to-be-off.patch
queue-4.9/bluetooth-6lowpan-fix-delay-work-init-in-add_peer_chan.patch
queue-4.9/soc-tegra-fix-link-errors-with-pmc-disabled.patch
queue-4.9/test_firmware-fix-setting-old-custom-fw-path-back-on-exit.patch
queue-4.9/scsi-fnic-fix-for-number-of-active-ios-in-fnicstats-becoming-negative.patch
queue-4.9/arm-dts-r8a7793-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/staging-speakup-replace-bug_on-with-warn_on.patch
queue-4.9/hid-reject-input-outside-logical-range-only-if-null-state-is-set.patch
queue-4.9/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch
queue-4.9/ima-relax-requiring-a-file-signature-for-new-files-with-zero-length.patch
queue-4.9/edac-altera-fix-peripheral-warnings-for-cyclone5.patch
queue-4.9/arm-dts-r8a7793-correct-parent-of-ssi-clocks.patch
queue-4.9/x86-boot-32-defer-resyncing-initial_page_table-until-per-cpu-is-set-up.patch
queue-4.9/pci-msi-stop-disabling-msi-msi-x-in-pci_device_shutdown.patch
queue-4.9/staging-wilc1000-add-check-for-kmalloc-allocation-failure.patch
queue-4.9/scsi-be2iscsi-check-tag-in-beiscsi_mccq_compl_wait.patch
queue-4.9/kvm-svm-setup-mcg_cap-on-amd-properly.patch
queue-4.9/usb-gadget-dummy_hcd-fix-wrong-power-status-bit-clear-reset-in-dummy_hub_control.patch
queue-4.9/ib-hfi1-check-for-qsfp-presence-before-attempting-reads.patch
queue-4.9/usb-dwc3-make-sure-ux_exit_px-is-cleared.patch
queue-4.9/perf-inject-copy-events-when-reordering-events-in-pipe-mode.patch
queue-4.9/power-supply-ab8500_charger-bail-out-in-case-of-error-in-ab8500_charger_init_hw_registers.patch
queue-4.9/media-vsp1-prevent-suspending-and-resuming-drm-pipelines.patch
queue-4.9/scsi-ses-don-t-get-power-status-of-ses-device-slot-on-probe.patch
queue-4.9/drm-vmwgfx-fixes-to-vmwgfx_fb.patch
queue-4.9/eventpoll.h-fix-epoll-event-masks.patch
queue-4.9/clk-qcom-msm8996-fix-the-vfe1-powerdomain-name.patch
queue-4.9/pci-apply-cavium-acs-quirk-only-to-cn81xx-cn83xx-cn88xx-devices.patch
queue-4.9/perf-probe-return-errno-when-not-hitting-any-event.patch
queue-4.9/spi-sun6i-disable-unprepare-clocks-on-remove.patch
queue-4.9/x86-mce-init-some-cpu-features-early.patch
queue-4.9/arm-dts-r8a7790-correct-parent-of-ssi-clocks.patch
queue-4.9/mips-bpf-fix-multiple-problems-in-jit-skb-access-helpers.patch
queue-4.9/net-mvpp2-set-dma-mask-and-coherent-dma-mask-on-ppv2.2.patch
queue-4.9/mwifiex-cfg80211-do-not-change-virtual-interface-during-scan-processing.patch
queue-4.9/ipvlan-add-l2-check-for-packets-arriving-via-virtual-devices.patch
queue-4.9/video-arm-clcd-fix-dma-allocation-size.patch
queue-4.9/drm-edid-set-eld-connector-type-in-drm_edid_to_eld.patch
queue-4.9/iwlwifi-mvm-fix-rx-skb-header-size-and-align-it-properly.patch
queue-4.9/drm-amdkfd-fix-memory-leaks-in-kfd-topology.patch
queue-4.9/pci-hv-properly-handle-pci-bus-remove.patch
queue-4.9/drivers-net-xgene-fix-rx-checksum-validation-logic.patch
queue-4.9/media-i2c-soc_camera-fix-ov6650-sensor-getting-wrong-clock.patch
queue-4.9/pwm-tegra-increase-precision-in-pwm-rate-calculation.patch
queue-4.9/net-ieee802154-adf7242-fix-bug-if-defined-debug.patch
queue-4.9/arm-bcm2835-enable-missing-cma-settings-for-vc4-driver.patch
queue-4.9/agp-intel-flush-all-chipset-writes-after-updating-the-ggtt.patch
queue-4.9/arm-dts-am335x-pepper-fix-the-audio-codec-s-reset-pin.patch
queue-4.9/drivers-net-phy-xgene-fix-mdio-write.patch
queue-4.9/apparmor-make-path_max-parameter-readonly.patch
queue-4.9/perf-evsel-return-exact-sub-event-which-failed-with-eperm-for-wildcards.patch
queue-4.9/powerpc-mm-hugetlb-filter-out-hugepage-size-not-supported-by-page-table-layout.patch
queue-4.9/scsi-core-scsi_get_device_flags_keyed-always-return-device-flags.patch
queue-4.9/f2fs-relax-node-version-check-for-victim-data-in-gc.patch
queue-4.9/scsi-dh-add-new-rdac-devices.patch
queue-4.9/scsi-ses-don-t-ask-for-diagnostic-pages-repeatedly-during-probe.patch
queue-4.9/mwifiex-fix-invalid-port-issue.patch
queue-4.9/solo6x10-release-vb2-buffers-in-solo_stop_streaming.patch
queue-4.9/i40e-fix-ethtool-to-get-eeprom-data-from-x722-interface.patch
queue-4.9/drm-rockchip-vop-enable-pm-domain-before-vop_initial.patch
queue-4.9/bluetooth-avoid-bt_accept_unlink-double-unlinking.patch
queue-4.9/i40e-only-register-client-on-iwarp-capable-devices.patch
queue-4.9/alsa-firewire-lib-add-a-quirk-of-packet-without-valid-eoh-in-cip-format.patch
queue-4.9/drivers-perf-arm_pmu-handle-no-platform_device.patch
queue-4.9/tcp-sysctl-fix-a-race-to-avoid-unexpected-0-window-from-space.patch
queue-4.9/i40e-i40evf-fix-use-after-free-in-rx-cleanup-path.patch
queue-4.9/asoc-nuc900-fix-a-loop-timeout-test.patch
queue-4.9/tools-usbip-fixes-build-with-musl-libc-toolchain.patch
queue-4.9/coresight-fixes-coresight-dt-parse-to-get-correct-output-port-id.patch
queue-4.9/mtd-nand-fix-interpretation-of-nand_cmd_none-in-nand_command.patch
queue-4.9/perf-stat-fix-bug-in-handling-events-in-error-state.patch
queue-4.9/vfio-powerpc-spapr_tce-enforce-iommu-type-compatibility-check.patch
queue-4.9/ath10k-disallow-dfs-simulation-if-dfs-channel-is-not-enabled.patch
This is a note to let you know that I've just added the patch titled
EDAC, altera: Fix peripheral warnings for Cyclone5
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
edac-altera-fix-peripheral-warnings-for-cyclone5.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Thor Thayer <thor.thayer(a)linux.intel.com>
Date: Wed, 5 Apr 2017 13:01:02 -0500
Subject: EDAC, altera: Fix peripheral warnings for Cyclone5
From: Thor Thayer <thor.thayer(a)linux.intel.com>
[ Upstream commit 25b223ddfe2a557307c05fe673e09d94ae950877 ]
The peripherals' RAS functionality only exist on the Arria10 SoCFPGA.
The Cyclone5 initialization generates EDAC warnings when the peripherals
aren't found in the device tree. Fix by checking for Arria10 in the init
functions.
Signed-off-by: Thor Thayer <thor.thayer(a)linux.intel.com>
Cc: linux-edac <linux-edac(a)vger.kernel.org>
Link: http://lkml.kernel.org/r/1491415262-5018-1-git-send-email-thor.thayer@linux…
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/edac/altera_edac.c | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -1020,13 +1020,23 @@ out:
return ret;
}
+static int socfpga_is_a10(void)
+{
+ return of_machine_is_compatible("altr,socfpga-arria10");
+}
+
static int validate_parent_available(struct device_node *np);
static const struct of_device_id altr_edac_a10_device_of_match[];
static int __init __maybe_unused altr_init_a10_ecc_device_type(char *compat)
{
int irq;
- struct device_node *child, *np = of_find_compatible_node(NULL, NULL,
- "altr,socfpga-a10-ecc-manager");
+ struct device_node *child, *np;
+
+ if (!socfpga_is_a10())
+ return -ENODEV;
+
+ np = of_find_compatible_node(NULL, NULL,
+ "altr,socfpga-a10-ecc-manager");
if (!np) {
edac_printk(KERN_ERR, EDAC_DEVICE, "ECC Manager not found\n");
return -ENODEV;
@@ -1542,8 +1552,12 @@ static const struct edac_device_prv_data
static int __init socfpga_init_sdmmc_ecc(void)
{
int rc = -ENODEV;
- struct device_node *child = of_find_compatible_node(NULL, NULL,
- "altr,socfpga-sdmmc-ecc");
+ struct device_node *child;
+
+ if (!socfpga_is_a10())
+ return -ENODEV;
+
+ child = of_find_compatible_node(NULL, NULL, "altr,socfpga-sdmmc-ecc");
if (!child) {
edac_printk(KERN_WARNING, EDAC_DEVICE, "SDMMC node not found\n");
return -ENODEV;
Patches currently in stable-queue which might be from thor.thayer(a)linux.intel.com are
queue-4.9/edac-altera-fix-peripheral-warnings-for-cyclone5.patch
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Fixes to vmwgfx_fb
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-vmwgfx-fixes-to-vmwgfx_fb.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Sinclair Yeh <syeh(a)vmware.com>
Date: Thu, 23 Mar 2017 14:28:21 -0700
Subject: drm/vmwgfx: Fixes to vmwgfx_fb
From: Sinclair Yeh <syeh(a)vmware.com>
[ Upstream commit aa74f0687cfe998e59b20d6454f45e8aa4403c45 ]
1. When unsetting a mode, num_connector should be set to zero
2. The pixel_format field needs to be initialized as newer DRM internal
functions checks this field
3. Take the drm_modeset_lock_all() because vmw_fb_kms_detach() can
change current mode
Signed-off-by: Sinclair Yeh <syeh(a)vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom(a)vmware.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
@@ -433,7 +433,7 @@ static int vmw_fb_kms_detach(struct vmw_
set.y = 0;
set.mode = NULL;
set.fb = NULL;
- set.num_connectors = 1;
+ set.num_connectors = 0;
set.connectors = &par->con;
ret = drm_mode_set_config_internal(&set);
if (ret) {
@@ -821,7 +821,9 @@ int vmw_fb_off(struct vmw_private *vmw_p
flush_delayed_work(&par->local_work);
mutex_lock(&par->bo_mutex);
+ drm_modeset_lock_all(vmw_priv->dev);
(void) vmw_fb_kms_detach(par, true, false);
+ drm_modeset_unlock_all(vmw_priv->dev);
mutex_unlock(&par->bo_mutex);
return 0;
Patches currently in stable-queue which might be from syeh(a)vmware.com are
queue-4.9/drm-vmwgfx-fixes-to-vmwgfx_fb.patch
This is a note to let you know that I've just added the patch titled
drm/ttm: never add BO that failed to validate to the LRU list
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-ttm-never-add-bo-that-failed-to-validate-to-the-lru-list.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: "Nicolai Hähnle" <nicolai.haehnle(a)amd.com>
Date: Tue, 14 Feb 2017 09:37:12 +0100
Subject: drm/ttm: never add BO that failed to validate to the LRU list
From: "Nicolai Hähnle" <nicolai.haehnle(a)amd.com>
[ Upstream commit c2c139cf435b18939204800fa72c53a7207bdd68 ]
Fixes a potential race condition in amdgpu that looks as follows:
Task 1: attempt ttm_bo_init, but ttm_bo_validate fails
Task 1: add BO to global list anyway
Task 2: grabs hold of the BO, waits on its reservation lock
Task 1: releases its reference of the BO; never gives up the
reservation lock
The patch "drm/amdgpu: fix a potential deadlock in
amdgpu_bo_create_restricted()" attempts to fix that by releasing
the reservation lock in amdgpu code; unfortunately, it introduces
a use-after-free when this race _doesn't_ happen.
This patch should fix the race properly by never adding the BO
to the global list in the first place.
Cc: zhoucm1 <david1.zhou(a)amd.com>
Signed-off-by: Nicolai Hähnle <nicolai.haehnle(a)amd.com>
Tested-by: Samuel Pitoiset <samuel.pitoiset(a)gmail.com>
Reviewed-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/ttm/ttm_bo.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1209,18 +1209,20 @@ int ttm_bo_init(struct ttm_bo_device *bd
if (likely(!ret))
ret = ttm_bo_validate(bo, placement, interruptible, false);
- if (!resv) {
+ if (!resv)
ttm_bo_unreserve(bo);
- } else if (!(bo->mem.placement & TTM_PL_FLAG_NO_EVICT)) {
+ if (unlikely(ret)) {
+ ttm_bo_unref(&bo);
+ return ret;
+ }
+
+ if (resv && !(bo->mem.placement & TTM_PL_FLAG_NO_EVICT)) {
spin_lock(&bo->glob->lru_lock);
ttm_bo_add_to_lru(bo);
spin_unlock(&bo->glob->lru_lock);
}
- if (unlikely(ret))
- ttm_bo_unref(&bo);
-
return ret;
}
EXPORT_SYMBOL(ttm_bo_init);
Patches currently in stable-queue which might be from nicolai.haehnle(a)amd.com are
queue-4.9/drm-ttm-never-add-bo-that-failed-to-validate-to-the-lru-list.patch
This is a note to let you know that I've just added the patch titled
drm/sun4i: Set drm_crtc.port to the underlying TCON's output port node
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-sun4i-set-drm_crtc.port-to-the-underlying-tcon-s-output-port-node.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Chen-Yu Tsai <wens(a)csie.org>
Date: Thu, 23 Feb 2017 16:05:34 +0800
Subject: drm/sun4i: Set drm_crtc.port to the underlying TCON's output port node
From: Chen-Yu Tsai <wens(a)csie.org>
[ Upstream commit 7544860733d158e3edbf309f27e79e258c8f66bd ]
The way drm_of_find_possible_crtcs works is it tries to match the
remote-endpoint of the given node's various endpoints to all the
crtc's .port field. Thus we need to set drm_crtc.port to the output
port node of the underlying TCON.
Signed-off-by: Chen-Yu Tsai <wens(a)csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard(a)free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/sun4i/sun4i_crtc.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
@@ -19,6 +19,7 @@
#include <linux/clk-provider.h>
#include <linux/ioport.h>
#include <linux/of_address.h>
+#include <linux/of_graph.h>
#include <linux/of_irq.h>
#include <linux/regmap.h>
@@ -136,5 +137,9 @@ struct sun4i_crtc *sun4i_crtc_init(struc
drm_crtc_helper_add(&scrtc->crtc, &sun4i_crtc_helper_funcs);
+ /* Set crtc.port to output port node of the tcon */
+ scrtc->crtc.port = of_graph_get_port_by_id(drv->tcon->dev->of_node,
+ 1);
+
return scrtc;
}
Patches currently in stable-queue which might be from wens(a)csie.org are
queue-4.9/drm-sun4i-fix-up-error-path-cleanup-for-master-bind-function.patch
queue-4.9/drm-sun4i-set-drm_crtc.port-to-the-underlying-tcon-s-output-port-node.patch
queue-4.9/drm-sun4i-fix-tcon-clock-and-regmap-initialization-sequence.patch
queue-4.9/clk-sunxi-ng-a33-add-offset-and-minimum-value-for-ddr1-pll-n-factor.patch
This is a note to let you know that I've just added the patch titled
drm/sun4i: Fix up error path cleanup for master bind function
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-sun4i-fix-up-error-path-cleanup-for-master-bind-function.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Chen-Yu Tsai <wens(a)csie.org>
Date: Fri, 17 Feb 2017 11:13:25 +0800
Subject: drm/sun4i: Fix up error path cleanup for master bind function
From: Chen-Yu Tsai <wens(a)csie.org>
[ Upstream commit 9d56defb44b15427f4342c543a70fb7886fc06f5 ]
The master bind function calls numerous drm functions which initialize
underlying structures. It also tries to bind the various components
of the display pipeline, some of which may add additional drm objects.
This patch adds proper cleanup functions in the error path of the
master bind function.
This requires the patch "drm/sun4i: Move drm_mode_config_cleanup call
to main driver", which splits out drm_mode_config_cleanup from
sun4i_framebuffer_free so we can call it separately.
Signed-off-by: Chen-Yu Tsai <wens(a)csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard(a)free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -145,7 +145,7 @@ static int sun4i_drv_bind(struct device
ret = component_bind_all(drm->dev, drm);
if (ret) {
dev_err(drm->dev, "Couldn't bind all pipelines components\n");
- goto free_drm;
+ goto cleanup_mode_config;
}
/* Create our layers */
@@ -153,7 +153,7 @@ static int sun4i_drv_bind(struct device
if (IS_ERR(drv->layers)) {
dev_err(drm->dev, "Couldn't create the planes\n");
ret = PTR_ERR(drv->layers);
- goto free_drm;
+ goto cleanup_mode_config;
}
/* Create our CRTC */
@@ -161,7 +161,7 @@ static int sun4i_drv_bind(struct device
if (!drv->crtc) {
dev_err(drm->dev, "Couldn't create the CRTC\n");
ret = -EINVAL;
- goto free_drm;
+ goto cleanup_mode_config;
}
drm->irq_enabled = true;
@@ -173,7 +173,7 @@ static int sun4i_drv_bind(struct device
if (IS_ERR(drv->fbdev)) {
dev_err(drm->dev, "Couldn't create our framebuffer\n");
ret = PTR_ERR(drv->fbdev);
- goto free_drm;
+ goto cleanup_mode_config;
}
/* Enable connectors polling */
@@ -181,10 +181,16 @@ static int sun4i_drv_bind(struct device
ret = drm_dev_register(drm, 0);
if (ret)
- goto free_drm;
+ goto finish_poll;
return 0;
+finish_poll:
+ drm_kms_helper_poll_fini(drm);
+ sun4i_framebuffer_free(drm);
+cleanup_mode_config:
+ drm_mode_config_cleanup(drm);
+ drm_vblank_cleanup(drm);
free_drm:
drm_dev_unref(drm);
return ret;
Patches currently in stable-queue which might be from wens(a)csie.org are
queue-4.9/drm-sun4i-fix-up-error-path-cleanup-for-master-bind-function.patch
queue-4.9/drm-sun4i-set-drm_crtc.port-to-the-underlying-tcon-s-output-port-node.patch
queue-4.9/drm-sun4i-fix-tcon-clock-and-regmap-initialization-sequence.patch
queue-4.9/clk-sunxi-ng-a33-add-offset-and-minimum-value-for-ddr1-pll-n-factor.patch
This is a note to let you know that I've just added the patch titled
drm/sun4i: Fix TCON clock and regmap initialization sequence
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-sun4i-fix-tcon-clock-and-regmap-initialization-sequence.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Chen-Yu Tsai <wens(a)csie.org>
Date: Thu, 9 Mar 2017 18:05:24 +0800
Subject: drm/sun4i: Fix TCON clock and regmap initialization sequence
From: Chen-Yu Tsai <wens(a)csie.org>
[ Upstream commit 4c7f16d14a33a9cfb4af9cb780d8a73bcca64a92 ]
The TCON driver calls sun4i_tcon_init_regmap and sun4i_tcon_init_clocks
in its bind function. The former creates a regmap and writes to several
register to clear its configuration to a known default. The latter
initializes various clocks. This includes enabling the bus clock for
register access and creating the dotclock.
In order for the first step's writes to work, the bus clock must be
enabled which is done in the second step. but the dotclock's ops use
the regmap created in the first step.
Rearrange the function calls such that the clocks are initialized before
the regmap, and split out the dot clock creation to after the regmap is
initialized.
Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: Chen-Yu Tsai <wens(a)csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard(a)free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -336,12 +336,11 @@ static int sun4i_tcon_init_clocks(struct
}
}
- return sun4i_dclk_create(dev, tcon);
+ return 0;
}
static void sun4i_tcon_free_clocks(struct sun4i_tcon *tcon)
{
- sun4i_dclk_free(tcon);
clk_disable_unprepare(tcon->clk);
}
@@ -506,22 +505,28 @@ static int sun4i_tcon_bind(struct device
return ret;
}
+ ret = sun4i_tcon_init_clocks(dev, tcon);
+ if (ret) {
+ dev_err(dev, "Couldn't init our TCON clocks\n");
+ goto err_assert_reset;
+ }
+
ret = sun4i_tcon_init_regmap(dev, tcon);
if (ret) {
dev_err(dev, "Couldn't init our TCON regmap\n");
- goto err_assert_reset;
+ goto err_free_clocks;
}
- ret = sun4i_tcon_init_clocks(dev, tcon);
+ ret = sun4i_dclk_create(dev, tcon);
if (ret) {
- dev_err(dev, "Couldn't init our TCON clocks\n");
- goto err_assert_reset;
+ dev_err(dev, "Couldn't create our TCON dot clock\n");
+ goto err_free_clocks;
}
ret = sun4i_tcon_init_irq(dev, tcon);
if (ret) {
dev_err(dev, "Couldn't init our TCON interrupts\n");
- goto err_free_clocks;
+ goto err_free_dotclock;
}
ret = sun4i_rgb_init(drm);
@@ -530,6 +535,8 @@ static int sun4i_tcon_bind(struct device
return 0;
+err_free_dotclock:
+ sun4i_dclk_free(tcon);
err_free_clocks:
sun4i_tcon_free_clocks(tcon);
err_assert_reset:
@@ -542,6 +549,7 @@ static void sun4i_tcon_unbind(struct dev
{
struct sun4i_tcon *tcon = dev_get_drvdata(dev);
+ sun4i_dclk_free(tcon);
sun4i_tcon_free_clocks(tcon);
}
Patches currently in stable-queue which might be from wens(a)csie.org are
queue-4.9/drm-sun4i-fix-up-error-path-cleanup-for-master-bind-function.patch
queue-4.9/drm-sun4i-set-drm_crtc.port-to-the-underlying-tcon-s-output-port-node.patch
queue-4.9/drm-sun4i-fix-tcon-clock-and-regmap-initialization-sequence.patch
queue-4.9/clk-sunxi-ng-a33-add-offset-and-minimum-value-for-ddr1-pll-n-factor.patch
This is a note to let you know that I've just added the patch titled
drm/rockchip: vop: Enable pm domain before vop_initial
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-rockchip-vop-enable-pm-domain-before-vop_initial.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Jeffy Chen <jeffy.chen(a)rock-chips.com>
Date: Thu, 6 Apr 2017 20:31:20 +0800
Subject: drm/rockchip: vop: Enable pm domain before vop_initial
From: Jeffy Chen <jeffy.chen(a)rock-chips.com>
[ Upstream commit 5e570373c015b60a68828b1cd9d475cb33d3be4b ]
We're trying to access vop registers here, so need to make sure
the pm domain is on.
Normally it should be enabled by the bootloader, but there's no
guarantee of it. And if we wanna do unbind/bind, it would also
cause the device to hang.
And this patch also does these:
1/ move vop_initial to the end of vop_bind for eaiser error handling.
2/ correct the err_put_pm_runtime of vop_enable.
Signed-off-by: Jeffy Chen <jeffy.chen(a)rock-chips.com>
Signed-off-by: Sean Paul <seanpaul(a)chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1491481885-13775-8-git-send-em…
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 29 ++++++++++++++++++++--------
1 file changed, 21 insertions(+), 8 deletions(-)
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -503,7 +503,7 @@ static int vop_enable(struct drm_crtc *c
ret = pm_runtime_get_sync(vop->dev);
if (ret < 0) {
dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
- goto err_put_pm_runtime;
+ return ret;
}
ret = clk_enable(vop->hclk);
@@ -1348,10 +1348,16 @@ static int vop_initial(struct vop *vop)
return PTR_ERR(vop->dclk);
}
+ ret = pm_runtime_get_sync(vop->dev);
+ if (ret < 0) {
+ dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
+ return ret;
+ }
+
ret = clk_prepare(vop->dclk);
if (ret < 0) {
dev_err(vop->dev, "failed to prepare dclk\n");
- return ret;
+ goto err_put_pm_runtime;
}
/* Enable both the hclk and aclk to setup the vop */
@@ -1411,6 +1417,8 @@ static int vop_initial(struct vop *vop)
vop->is_enabled = false;
+ pm_runtime_put_sync(vop->dev);
+
return 0;
err_disable_aclk:
@@ -1419,6 +1427,8 @@ err_disable_hclk:
clk_disable_unprepare(vop->hclk);
err_unprepare_dclk:
clk_unprepare(vop->dclk);
+err_put_pm_runtime:
+ pm_runtime_put_sync(vop->dev);
return ret;
}
@@ -1519,12 +1529,6 @@ static int vop_bind(struct device *dev,
if (!vop->regsbak)
return -ENOMEM;
- ret = vop_initial(vop);
- if (ret < 0) {
- dev_err(&pdev->dev, "cannot initial vop dev - err %d\n", ret);
- return ret;
- }
-
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(dev, "cannot find irq for vop\n");
@@ -1551,8 +1555,17 @@ static int vop_bind(struct device *dev,
pm_runtime_enable(&pdev->dev);
+ ret = vop_initial(vop);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "cannot initial vop dev - err %d\n", ret);
+ goto err_disable_pm_runtime;
+ }
+
return 0;
+err_disable_pm_runtime:
+ pm_runtime_disable(&pdev->dev);
+ vop_destroy_crtc(vop);
err_enable_irq:
enable_irq(vop->irq); /* To balance out the disable_irq above */
return ret;
Patches currently in stable-queue which might be from jeffy.chen(a)rock-chips.com are
queue-4.9/drm-rockchip-vop-enable-pm-domain-before-vop_initial.patch
This is a note to let you know that I've just added the patch titled
drm: rcar-du: Handle event when disabling CRTCs
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-rcar-du-handle-event-when-disabling-crtcs.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
Date: Fri, 10 Feb 2017 13:30:35 +0200
Subject: drm: rcar-du: Handle event when disabling CRTCs
From: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
[ Upstream commit 6dd47cfd03a058d08b8caffb06194aa0eb109cf1 ]
The driver currently handles vblank events only when updating planes on
a CRTC. The atomic update API however allows requesting an event when
disabling a CRTC. This currently leads to event objects being leaked in
the kernel and to events not being sent out. Fix it.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -512,6 +512,13 @@ static void rcar_du_crtc_disable(struct
rcar_du_crtc_stop(rcrtc);
rcar_du_crtc_put(rcrtc);
+ spin_lock_irq(&crtc->dev->event_lock);
+ if (crtc->state->event) {
+ drm_crtc_send_vblank_event(crtc, crtc->state->event);
+ crtc->state->event = NULL;
+ }
+ spin_unlock_irq(&crtc->dev->event_lock);
+
rcrtc->outputs = 0;
}
Patches currently in stable-queue which might be from laurent.pinchart+renesas(a)ideasonboard.com are
queue-4.9/v4l-vsp1-prevent-multiple-streamon-race-commencing-pipeline-early.patch
queue-4.9/v4l-vsp1-register-pipe-with-output-wpf.patch
queue-4.9/drm-rcar-du-handle-event-when-disabling-crtcs.patch
queue-4.9/media-vsp1-prevent-suspending-and-resuming-drm-pipelines.patch
This is a note to let you know that I've just added the patch titled
drm/radeon: Fail fb creation from imported dma-bufs.
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-radeon-fail-fb-creation-from-imported-dma-bufs.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Christopher James Halse Rogers <christopher.halse.rogers(a)canonical.com>
Date: Wed, 29 Mar 2017 15:00:54 +1100
Subject: drm/radeon: Fail fb creation from imported dma-bufs.
From: Christopher James Halse Rogers <christopher.halse.rogers(a)canonical.com>
[ Upstream commit a294043b2fbd8de69d161457ed0c7a4026bbfa5a ]
Any use of the framebuffer will migrate it to VRAM, which is not sensible for
an imported dma-buf.
v2: Use DRM_DEBUG_KMS to prevent userspace accidentally spamming dmesg.
Reviewed-by: Michel Dänzer <michel.daenzer(a)amd.com>
Reviewed-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers(a)canonical.com>
CC: amd-gfx(a)lists.freedesktop.org
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/radeon/radeon_display.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1352,6 +1352,12 @@ radeon_user_framebuffer_create(struct dr
return ERR_PTR(-ENOENT);
}
+ /* Handle is imported dma-buf, so cannot be migrated to VRAM for scanout */
+ if (obj->import_attach) {
+ DRM_DEBUG_KMS("Cannot create framebuffer from imported dma_buf\n");
+ return ERR_PTR(-EINVAL);
+ }
+
radeon_fb = kzalloc(sizeof(*radeon_fb), GFP_KERNEL);
if (radeon_fb == NULL) {
drm_gem_object_unreference_unlocked(obj);
Patches currently in stable-queue which might be from christopher.halse.rogers(a)canonical.com are
queue-4.9/drm-amdgpu-fail-fb-creation-from-imported-dma-bufs.-v2.patch
queue-4.9/drm-radeon-fail-fb-creation-from-imported-dma-bufs.patch
This is a note to let you know that I've just added the patch titled
drm/edid: set ELD connector type in drm_edid_to_eld()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-edid-set-eld-connector-type-in-drm_edid_to_eld.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Jani Nikula <jani.nikula(a)intel.com>
Date: Wed, 1 Nov 2017 16:20:58 +0200
Subject: drm/edid: set ELD connector type in drm_edid_to_eld()
From: Jani Nikula <jani.nikula(a)intel.com>
[ Upstream commit 1d1c36650752b7fb81cee515a9bba4131cac4b7c ]
Since drm_edid_to_eld() knows the connector type, we can set the type in
ELD while at it. Most connectors this gets called on are not DP
encoders, and with the HDMI type being 0, this does not change behaviour
for non-DP.
For i915 having this in place earlier would have saved a considerable
amount of debugging that lead to the fix 2d8f63297b9f ("drm/i915: always
update ELD connector type after get modes"). I don't see other drivers,
even the ones calling drm_edid_to_eld() on DP connectors, setting the
connector type in ELD.
Cc: Alex Deucher <alexander.deucher(a)amd.com>
Cc: Christian König <christian.koenig(a)amd.com>
Cc: Archit Taneja <architt(a)codeaurora.org>
Cc: Andrzej Hajda <a.hajda(a)samsung.com>
Cc: Russell King <linux(a)armlinux.org.uk>
Cc: CK Hu <ck.hu(a)mediatek.com>
Cc: Philipp Zabel <p.zabel(a)pengutronix.de>
Cc: Ben Skeggs <bskeggs(a)redhat.com>
Cc: Mark Yao <mark.yao(a)rock-chips.com>
Cc: Benjamin Gaignard <benjamin.gaignard(a)linaro.org>
Cc: Vincent Abriou <vincent.abriou(a)st.com>
Cc: Thierry Reding <thierry.reding(a)gmail.com>
Cc: Eric Anholt <eric(a)anholt.net>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
Acked-by: Thierry Reding <treding(a)nvidia.com>
Signed-off-by: Jani Nikula <jani.nikula(a)intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d527b31619528c477c2c136f25cdf…
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/drm_edid.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3347,8 +3347,7 @@ EXPORT_SYMBOL(drm_edid_get_monitor_name)
* @edid: EDID to parse
*
* Fill the ELD (EDID-Like Data) buffer for passing to the audio driver. The
- * Conn_Type, HDCP and Port_ID ELD fields are left for the graphics driver to
- * fill in.
+ * HDCP and Port_ID ELD fields are left for the graphics driver to fill in.
*/
void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid)
{
@@ -3426,6 +3425,12 @@ void drm_edid_to_eld(struct drm_connecto
}
eld[5] |= total_sad_count << 4;
+ if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
+ connector->connector_type == DRM_MODE_CONNECTOR_eDP)
+ eld[DRM_ELD_SAD_COUNT_CONN_TYPE] |= DRM_ELD_CONN_TYPE_DP;
+ else
+ eld[DRM_ELD_SAD_COUNT_CONN_TYPE] |= DRM_ELD_CONN_TYPE_HDMI;
+
eld[DRM_ELD_BASELINE_ELD_LEN] =
DIV_ROUND_UP(drm_eld_calc_baseline_block_size(eld), 4);
Patches currently in stable-queue which might be from jani.nikula(a)intel.com are
queue-4.9/drm-edid-set-eld-connector-type-in-drm_edid_to_eld.patch
This is a note to let you know that I've just added the patch titled
drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off)
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-defer-disabling-the-vblank-irq-until-the-next-interrupt-for-instant-off.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Chris Wilson <chris(a)chris-wilson.co.uk>
Date: Wed, 15 Mar 2017 20:40:25 +0000
Subject: drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off)
From: Chris Wilson <chris(a)chris-wilson.co.uk>
[ Upstream commit 608b20506941969ea30d8c08dc9ae02bb87dbf7d ]
On vblank instant-off systems, we can get into a situation where the cost
of enabling and disabling the vblank IRQ around a drmWaitVblank query
dominates. And with the advent of even deeper hardware sleep state,
touching registers becomes ever more expensive. However, we know that if
the user wants the current vblank counter, they are also very likely to
immediately queue a vblank wait and so we can keep the interrupt around
and only turn it off if we have no further vblank requests queued within
the interrupt interval.
After vblank event delivery, this patch adds a shadow of one vblank where
the interrupt is kept alive for the user to query and queue another vblank
event. Similarly, if the user is using blocking drmWaitVblanks, the
interrupt will be disabled on the IRQ following the wait completion.
However, if the user is simply querying the current vblank counter and
timestamp, the interrupt will be disabled after every IRQ and the user
will enabled it again on the first query following the IRQ.
v2: Mario Kleiner -
After testing this, one more thing that would make sense is to move
the disable block at the end of drm_handle_vblank() instead of at the
top.
Turns out that if high precision timestaming is disabled or doesn't
work for some reason (as can be simulated by echo 0 >
/sys/module/drm/parameters/timestamp_precision_usec), then with your
delayed disable code at its current place, the vblank counter won't
increment anymore at all for instant queries, ie. with your other
"instant query" patches. Clients which repeatedly query the counter
and wait for it to progress will simply hang, spinning in an endless
query loop. There's that comment in vblank_disable_and_save:
"* Skip this step if there isn't any high precision timestamp
* available. In that case we can't account for this and just
* hope for the best.
*/
With the disable happening after leading edge of vblank (== hw counter
increment already happened) but before the vblank counter/timestamp
handling in drm_handle_vblank, that step is needed to keep the counter
progressing, so skipping it is bad.
Now without high precision timestamping support, a kms driver must not
set dev->vblank_disable_immediate = true, as this would cause problems
for clients, so this shouldn't matter, but it would be good to still
make this robust against a future kms driver which might have
unreliable high precision timestamping, e.g., high precision
timestamping that intermittently doesn't work.
v3: Patch before coffee needs extra coffee.
Testcase: igt/kms_vblank
Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: Daniel Vetter <daniel(a)ffwll.ch>
Cc: Michel Dänzer <michel(a)daenzer.net>
Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Cc: Dave Airlie <airlied(a)redhat.com>,
Cc: Mario Kleiner <mario.kleiner.de(a)gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170315204027.20160-1-chris@c…
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/drm_irq.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1202,9 +1202,9 @@ static void drm_vblank_put(struct drm_de
if (atomic_dec_and_test(&vblank->refcount)) {
if (drm_vblank_offdelay == 0)
return;
- else if (dev->vblank_disable_immediate || drm_vblank_offdelay < 0)
+ else if (drm_vblank_offdelay < 0)
vblank_disable_fn((unsigned long)vblank);
- else
+ else if (!dev->vblank_disable_immediate)
mod_timer(&vblank->disable_timer,
jiffies + ((drm_vblank_offdelay * HZ)/1000));
}
@@ -1819,6 +1819,16 @@ bool drm_handle_vblank(struct drm_device
wake_up(&vblank->queue);
drm_handle_vblank_events(dev, pipe);
+ /* With instant-off, we defer disabling the interrupt until after
+ * we finish processing the following vblank. The disable has to
+ * be last (after drm_handle_vblank_events) so that the timestamp
+ * is always accurate.
+ */
+ if (dev->vblank_disable_immediate &&
+ drm_vblank_offdelay > 0 &&
+ !atomic_read(&vblank->refcount))
+ vblank_disable_fn((unsigned long)vblank);
+
spin_unlock_irqrestore(&dev->event_lock, irqflags);
return true;
Patches currently in stable-queue which might be from chris(a)chris-wilson.co.uk are
queue-4.9/drm-defer-disabling-the-vblank-irq-until-the-next-interrupt-for-instant-off.patch
queue-4.9/agp-intel-flush-all-chipset-writes-after-updating-the-ggtt.patch
This is a note to let you know that I've just added the patch titled
drm/amdkfd: Fix memory leaks in kfd topology
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-amdkfd-fix-memory-leaks-in-kfd-topology.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Yong Zhao <yong.zhao(a)amd.com>
Date: Fri, 8 Dec 2017 23:08:48 -0500
Subject: drm/amdkfd: Fix memory leaks in kfd topology
From: Yong Zhao <yong.zhao(a)amd.com>
[ Upstream commit 5108d768408abc80e4e8d99f5b406a73cb04056b ]
Kobject created using kobject_create_and_add() can be freed using
kobject_put() when there is no referenece any more. However,
kobject memory allocated with kzalloc() has to set up a release
callback in order to free it when the counter decreases to 0.
Otherwise it causes memory leak.
Signed-off-by: Yong Zhao <yong.zhao(a)amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling(a)amd.com>
Reviewed-by: Oded Gabbay <oded.gabbay(a)gmail.com>
Signed-off-by: Oded Gabbay <oded.gabbay(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
@@ -519,11 +519,17 @@ static ssize_t sysprops_show(struct kobj
return ret;
}
+static void kfd_topology_kobj_release(struct kobject *kobj)
+{
+ kfree(kobj);
+}
+
static const struct sysfs_ops sysprops_ops = {
.show = sysprops_show,
};
static struct kobj_type sysprops_type = {
+ .release = kfd_topology_kobj_release,
.sysfs_ops = &sysprops_ops,
};
@@ -559,6 +565,7 @@ static const struct sysfs_ops iolink_ops
};
static struct kobj_type iolink_type = {
+ .release = kfd_topology_kobj_release,
.sysfs_ops = &iolink_ops,
};
@@ -586,6 +593,7 @@ static const struct sysfs_ops mem_ops =
};
static struct kobj_type mem_type = {
+ .release = kfd_topology_kobj_release,
.sysfs_ops = &mem_ops,
};
@@ -625,6 +633,7 @@ static const struct sysfs_ops cache_ops
};
static struct kobj_type cache_type = {
+ .release = kfd_topology_kobj_release,
.sysfs_ops = &cache_ops,
};
@@ -747,6 +756,7 @@ static const struct sysfs_ops node_ops =
};
static struct kobj_type node_type = {
+ .release = kfd_topology_kobj_release,
.sysfs_ops = &node_ops,
};
Patches currently in stable-queue which might be from yong.zhao(a)amd.com are
queue-4.9/drm-amdkfd-fix-memory-leaks-in-kfd-topology.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: Fail fb creation from imported dma-bufs. (v2)
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-amdgpu-fail-fb-creation-from-imported-dma-bufs.-v2.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Christopher James Halse Rogers <christopher.halse.rogers(a)canonical.com>
Date: Wed, 29 Mar 2017 15:02:11 +1100
Subject: drm/amdgpu: Fail fb creation from imported dma-bufs. (v2)
From: Christopher James Halse Rogers <christopher.halse.rogers(a)canonical.com>
[ Upstream commit 1769152ac64b0b07583f696b621624df2ca4c840 ]
Any use of the framebuffer will migrate it to VRAM, which is not sensible for
an imported dma-buf.
v2: Use DRM_DEBUG_KMS to prevent userspace accidentally spamming dmesg.
Reviewed-by: Michel Dänzer <michel.daenzer(a)amd.com>
Reviewed-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers(a)canonical.com>
CC: amd-gfx(a)lists.freedesktop.org
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -533,6 +533,12 @@ amdgpu_user_framebuffer_create(struct dr
return ERR_PTR(-ENOENT);
}
+ /* Handle is imported dma-buf, so cannot be migrated to VRAM for scanout */
+ if (obj->import_attach) {
+ DRM_DEBUG_KMS("Cannot create framebuffer from imported dma_buf\n");
+ return ERR_PTR(-EINVAL);
+ }
+
amdgpu_fb = kzalloc(sizeof(*amdgpu_fb), GFP_KERNEL);
if (amdgpu_fb == NULL) {
drm_gem_object_unreference_unlocked(obj);
Patches currently in stable-queue which might be from christopher.halse.rogers(a)canonical.com are
queue-4.9/drm-amdgpu-fail-fb-creation-from-imported-dma-bufs.-v2.patch
queue-4.9/drm-radeon-fail-fb-creation-from-imported-dma-bufs.patch
This is a note to let you know that I've just added the patch titled
drivers/perf: arm_pmu: handle no platform_device
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drivers-perf-arm_pmu-handle-no-platform_device.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Mark Rutland <mark.rutland(a)arm.com>
Date: Tue, 11 Apr 2017 09:39:49 +0100
Subject: drivers/perf: arm_pmu: handle no platform_device
From: Mark Rutland <mark.rutland(a)arm.com>
[ Upstream commit 7654137071fa706e5c91f4f27bc2a5cd7e435a9b ]
In armpmu_dispatch_irq() we look at arm_pmu::plat_device to acquire
platdata, so that we can defer to platform-specific IRQ handling,
required on some 32-bit parts. With the advent of ACPI we won't always
have a platform_device, and so we must avoid trying to dereference
fields from it.
This patch fixes up armpmu_dispatch_irq() to avoid doing so, introducing
a new armpmu_get_platdata() helper.
Signed-off-by: Mark Rutland <mark.rutland(a)arm.com>
Tested-by: Jeremy Linton <jeremy.linton(a)arm.com>
Cc: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/perf/arm_pmu.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -322,10 +322,16 @@ validate_group(struct perf_event *event)
return 0;
}
+static struct arm_pmu_platdata *armpmu_get_platdata(struct arm_pmu *armpmu)
+{
+ struct platform_device *pdev = armpmu->plat_device;
+
+ return pdev ? dev_get_platdata(&pdev->dev) : NULL;
+}
+
static irqreturn_t armpmu_dispatch_irq(int irq, void *dev)
{
struct arm_pmu *armpmu;
- struct platform_device *plat_device;
struct arm_pmu_platdata *plat;
int ret;
u64 start_clock, finish_clock;
@@ -337,8 +343,8 @@ static irqreturn_t armpmu_dispatch_irq(i
* dereference.
*/
armpmu = *(void **)dev;
- plat_device = armpmu->plat_device;
- plat = dev_get_platdata(&plat_device->dev);
+
+ plat = armpmu_get_platdata(armpmu);
start_clock = sched_clock();
if (plat && plat->handle_irq)
Patches currently in stable-queue which might be from mark.rutland(a)arm.com are
queue-4.9/drivers-perf-arm_pmu-handle-no-platform_device.patch
This is a note to let you know that I've just added the patch titled
drivers: net: xgene: Fix wrong logical operation
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drivers-net-xgene-fix-wrong-logical-operation.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Quan Nguyen <qnguyen(a)apm.com>
Date: Wed, 15 Mar 2017 13:27:17 -0700
Subject: drivers: net: xgene: Fix wrong logical operation
From: Quan Nguyen <qnguyen(a)apm.com>
[ Upstream commit 11623fce0f9afef30c45e3f2120b063de3809a8f ]
This patch fixes the wrong logical OR operation by changing it to
bit-wise OR operation.
Fixes: 3bb502f83080 ("drivers: net: xgene: fix statistics counters race condition")
Signed-off-by: Iyappan Subramanian <isubramanian(a)apm.com>
Signed-off-by: Quan Nguyen <qnguyen(a)apm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -537,9 +537,9 @@ static int xgene_enet_rx_frame(struct xg
buf_pool->rx_skb[skb_index] = NULL;
/* checking for error */
- status = (GET_VAL(ELERR, le64_to_cpu(raw_desc->m0)) << LERR_LEN) ||
+ status = (GET_VAL(ELERR, le64_to_cpu(raw_desc->m0)) << LERR_LEN) |
GET_VAL(LERR, le64_to_cpu(raw_desc->m0));
- if (unlikely(status > 2)) {
+ if (unlikely(status)) {
dev_kfree_skb_any(skb);
xgene_enet_parse_error(rx_ring, netdev_priv(rx_ring->ndev),
status);
Patches currently in stable-queue which might be from qnguyen(a)apm.com are
queue-4.9/drivers-net-xgene-fix-wrong-logical-operation.patch
queue-4.9/drivers-net-xgene-fix-hardware-checksum-setting.patch
queue-4.9/drivers-net-phy-xgene-fix-mdio-write.patch
This is a note to let you know that I've just added the patch titled
drivers: net: xgene: Fix hardware checksum setting
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drivers-net-xgene-fix-hardware-checksum-setting.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Quan Nguyen <qnguyen(a)apm.com>
Date: Wed, 15 Mar 2017 13:27:16 -0700
Subject: drivers: net: xgene: Fix hardware checksum setting
From: Quan Nguyen <qnguyen(a)apm.com>
[ Upstream commit e026e700d940a1ea3d3bc84d92ac668b1f015462 ]
This patch fixes the hardware checksum settings by properly program
the classifier. Otherwise, packet may be received with checksum error
on X-Gene1 SoC.
Signed-off-by: Quan Nguyen <qnguyen(a)apm.com>
Signed-off-by: Iyappan Subramanian <isubramanian(a)apm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 1 +
drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 1 +
2 files changed, 2 insertions(+)
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
@@ -560,6 +560,7 @@ static void xgene_enet_cle_bypass(struct
xgene_enet_rd_csr(pdata, CLE_BYPASS_REG0_0_ADDR, &cb);
cb |= CFG_CLE_BYPASS_EN0;
CFG_CLE_IP_PROTOCOL0_SET(&cb, 3);
+ CFG_CLE_IP_HDR_LEN_SET(&cb, 0);
xgene_enet_wr_csr(pdata, CLE_BYPASS_REG0_0_ADDR, cb);
xgene_enet_rd_csr(pdata, CLE_BYPASS_REG1_0_ADDR, &cb);
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
@@ -163,6 +163,7 @@ enum xgene_enet_rm {
#define CFG_RXCLK_MUXSEL0_SET(dst, val) xgene_set_bits(dst, val, 26, 3)
#define CFG_CLE_IP_PROTOCOL0_SET(dst, val) xgene_set_bits(dst, val, 16, 2)
+#define CFG_CLE_IP_HDR_LEN_SET(dst, val) xgene_set_bits(dst, val, 8, 5)
#define CFG_CLE_DSTQID0_SET(dst, val) xgene_set_bits(dst, val, 0, 12)
#define CFG_CLE_FPSEL0_SET(dst, val) xgene_set_bits(dst, val, 16, 4)
#define CFG_MACMODE_SET(dst, val) xgene_set_bits(dst, val, 18, 2)
Patches currently in stable-queue which might be from qnguyen(a)apm.com are
queue-4.9/drivers-net-xgene-fix-wrong-logical-operation.patch
queue-4.9/drivers-net-xgene-fix-hardware-checksum-setting.patch
queue-4.9/drivers-net-phy-xgene-fix-mdio-write.patch
This is a note to let you know that I've just added the patch titled
drivers: net: phy: xgene: Fix mdio write
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drivers-net-phy-xgene-fix-mdio-write.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Quan Nguyen <qnguyen(a)apm.com>
Date: Wed, 15 Mar 2017 13:27:15 -0700
Subject: drivers: net: phy: xgene: Fix mdio write
From: Quan Nguyen <qnguyen(a)apm.com>
[ Upstream commit 4b72436dc3dd2457056b22d6f147777368c869fa ]
This patches fixes a typo in the argument to xgene_enet_wr_mdio_csr().
Signed-off-by: Quan Nguyen <qnguyen(a)apm.com>
Signed-off-by: Iyappan Subramanian <isubramanian(a)apm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/phy/mdio-xgene.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/phy/mdio-xgene.c
+++ b/drivers/net/phy/mdio-xgene.c
@@ -232,7 +232,7 @@ static int xgene_xfi_mdio_write(struct m
val = SET_VAL(HSTPHYADX, phy_id) | SET_VAL(HSTREGADX, reg) |
SET_VAL(HSTMIIMWRDAT, data);
- xgene_enet_wr_mdio_csr(addr, MIIM_FIELD_ADDR, data);
+ xgene_enet_wr_mdio_csr(addr, MIIM_FIELD_ADDR, val);
val = HSTLDCMD | SET_VAL(HSTMIIMCMD, MIIM_CMD_LEGACY_WRITE);
xgene_enet_wr_mdio_csr(addr, MIIM_COMMAND_ADDR, val);
Patches currently in stable-queue which might be from qnguyen(a)apm.com are
queue-4.9/drivers-net-xgene-fix-wrong-logical-operation.patch
queue-4.9/drivers-net-xgene-fix-hardware-checksum-setting.patch
queue-4.9/drivers-net-phy-xgene-fix-mdio-write.patch
This is a note to let you know that I've just added the patch titled
driver: (adm1275) set the m,b and R coefficients correctly for power
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
driver-adm1275-set-the-m-b-and-r-coefficients-correctly-for-power.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Shikhar Dogra <shidogra(a)cisco.com>
Date: Mon, 27 Mar 2017 16:16:44 -0700
Subject: driver: (adm1275) set the m,b and R coefficients correctly for power
From: Shikhar Dogra <shidogra(a)cisco.com>
[ Upstream commit 6faecba0b3da7b617bf72bef422bf0d3bb6dfe7d ]
Seems like coefficient values for m, b and R under power have been
put in the wrong order. Rearranging them properly to get correct
values of coefficients for power.
For specs, please refer to table 7 (page 35) on
http://www.analog.com/media/en/technical-documentation/data-sheets/ADM1075.…
Fixes: 904b296f308d ("hwmon: (adm1275) Introduce configuration data structure for coeffcients")
Signed-off-by: Shikhar Dogra <shidogra(a)cisco.com>
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hwmon/pmbus/adm1275.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/hwmon/pmbus/adm1275.c
+++ b/drivers/hwmon/pmbus/adm1275.c
@@ -101,8 +101,8 @@ static const struct coefficients adm1075
[0] = { 27169, 0, -1 }, /* voltage */
[1] = { 806, 20475, -1 }, /* current, irange25 */
[2] = { 404, 20475, -1 }, /* current, irange50 */
- [3] = { 0, -1, 8549 }, /* power, irange25 */
- [4] = { 0, -1, 4279 }, /* power, irange50 */
+ [3] = { 8549, 0, -1 }, /* power, irange25 */
+ [4] = { 4279, 0, -1 }, /* power, irange50 */
};
static const struct coefficients adm1275_coefficients[] = {
Patches currently in stable-queue which might be from shidogra(a)cisco.com are
queue-4.9/driver-adm1275-set-the-m-b-and-r-coefficients-correctly-for-power.patch
This is a note to let you know that I've just added the patch titled
dmaengine: imx-sdma: add 1ms delay to ensure SDMA channel is stopped
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-imx-sdma-add-1ms-delay-to-ensure-sdma-channel-is-stopped.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Jiada Wang <jiada_wang(a)mentor.com>
Date: Thu, 16 Mar 2017 23:12:09 -0700
Subject: dmaengine: imx-sdma: add 1ms delay to ensure SDMA channel is stopped
From: Jiada Wang <jiada_wang(a)mentor.com>
[ Upstream commit 7f3ff14b7eb1ffad132117f08a1973b48e653d43 ]
sdma_disable_channel() cannot ensure dma is stopped to access
module's FIFOs. There is chance SDMA core is running and accessing
BD when disable of corresponding channel, this may cause sometimes
even after call of .sdma_disable_channel(), SDMA core still be
running and accessing module's FIFOs.
According to NXP R&D team a delay of one BD SDMA cost time (maximum
is 1ms) should be added after disable of the channel bit, to ensure
SDMA core has really been stopped after SDMA clients call
.device_terminate_all.
This patch introduces adds a new function sdma_disable_channel_with_delay()
which simply adds 1ms delay after call sdma_disable_channel(),
and set it as .device_terminate_all.
Signed-off-by: Jiada Wang <jiada_wang(a)mentor.com>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/imx-sdma.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -937,6 +937,21 @@ static int sdma_disable_channel(struct d
return 0;
}
+static int sdma_disable_channel_with_delay(struct dma_chan *chan)
+{
+ sdma_disable_channel(chan);
+
+ /*
+ * According to NXP R&D team a delay of one BD SDMA cost time
+ * (maximum is 1ms) should be added after disable of the channel
+ * bit, to ensure SDMA core has really been stopped after SDMA
+ * clients call .device_terminate_all.
+ */
+ mdelay(1);
+
+ return 0;
+}
+
static void sdma_set_watermarklevel_for_p2p(struct sdma_channel *sdmac)
{
struct sdma_engine *sdma = sdmac->sdma;
@@ -1828,7 +1843,7 @@ static int sdma_probe(struct platform_de
sdma->dma_device.device_prep_slave_sg = sdma_prep_slave_sg;
sdma->dma_device.device_prep_dma_cyclic = sdma_prep_dma_cyclic;
sdma->dma_device.device_config = sdma_config;
- sdma->dma_device.device_terminate_all = sdma_disable_channel;
+ sdma->dma_device.device_terminate_all = sdma_disable_channel_with_delay;
sdma->dma_device.src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
sdma->dma_device.dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
sdma->dma_device.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
Patches currently in stable-queue which might be from jiada_wang(a)mentor.com are
queue-4.9/dmaengine-imx-sdma-add-1ms-delay-to-ensure-sdma-channel-is-stopped.patch
This is a note to let you know that I've just added the patch titled
dmaengine: bcm2835-dma: Use vchan_terminate_vdesc() instead of desc_free
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-bcm2835-dma-use-vchan_terminate_vdesc-instead-of-desc_free.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Date: Tue, 14 Nov 2017 16:32:07 +0200
Subject: dmaengine: bcm2835-dma: Use vchan_terminate_vdesc() instead of desc_free
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
[ Upstream commit de92436ac40ffe9933230aa503e24dbb5ede9201 ]
To avoid race with vchan_complete, use the race free way to terminate
running transfer.
Implement the device_synchronize callback to make sure that the terminated
descriptor is freed.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Acked-by: Eric Anholt <eric(a)anholt.net>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/bcm2835-dma.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/dma/bcm2835-dma.c
+++ b/drivers/dma/bcm2835-dma.c
@@ -812,7 +812,7 @@ static int bcm2835_dma_terminate_all(str
* c->desc is NULL and exit.)
*/
if (c->desc) {
- bcm2835_dma_desc_free(&c->desc->vd);
+ vchan_terminate_vdesc(&c->desc->vd);
c->desc = NULL;
bcm2835_dma_abort(c->chan_base);
@@ -836,6 +836,13 @@ static int bcm2835_dma_terminate_all(str
return 0;
}
+static void bcm2835_dma_synchronize(struct dma_chan *chan)
+{
+ struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
+
+ vchan_synchronize(&c->vc);
+}
+
static int bcm2835_dma_chan_init(struct bcm2835_dmadev *d, int chan_id,
int irq, unsigned int irq_flags)
{
@@ -942,6 +949,7 @@ static int bcm2835_dma_probe(struct plat
od->ddev.device_prep_dma_memcpy = bcm2835_dma_prep_dma_memcpy;
od->ddev.device_config = bcm2835_dma_slave_config;
od->ddev.device_terminate_all = bcm2835_dma_terminate_all;
+ od->ddev.device_synchronize = bcm2835_dma_synchronize;
od->ddev.src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
od->ddev.dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
od->ddev.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV) |
Patches currently in stable-queue which might be from peter.ujfalusi(a)ti.com are
queue-4.9/dmaengine-bcm2835-dma-use-vchan_terminate_vdesc-instead-of-desc_free.patch
This is a note to let you know that I've just added the patch titled
coresight: Fixes coresight DT parse to get correct output port ID.
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
coresight-fixes-coresight-dt-parse-to-get-correct-output-port-id.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Mike Leach <mike.leach(a)linaro.org>
Date: Mon, 27 Mar 2017 11:09:33 -0600
Subject: coresight: Fixes coresight DT parse to get correct output port ID.
From: Mike Leach <mike.leach(a)linaro.org>
[ Upstream commit eeedc5421dd3b51de73e6106405c5c77f920f281 ]
Corrected to get the port numbering to allow programmable replicator driver
to operate correctly.
By convention, CoreSight devices number ports, not endpoints in
the .dts files:-
port {
reg<N>
endpoint {
}
}
Existing code read endpoint number - always 0x0, rather than the correct
port number.
Signed-off-by: Mike Leach <mike.leach(a)linaro.org>
Signed-off-by: Mathieu Poirier <mathieu.poirier(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hwtracing/coresight/of_coresight.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -149,7 +149,7 @@ struct coresight_platform_data *of_get_c
continue;
/* The local out port number */
- pdata->outports[i] = endpoint.id;
+ pdata->outports[i] = endpoint.port;
/*
* Get a handle on the remote port and parent
Patches currently in stable-queue which might be from mike.leach(a)linaro.org are
queue-4.9/coresight-fixes-coresight-dt-parse-to-get-correct-output-port-id.patch
This is a note to let you know that I've just added the patch titled
clk: sunxi-ng: a33: Add offset and minimum value for DDR1 PLL N factor
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
clk-sunxi-ng-a33-add-offset-and-minimum-value-for-ddr1-pll-n-factor.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Chen-Yu Tsai <wens(a)csie.org>
Date: Wed, 5 Apr 2017 14:37:44 +0800
Subject: clk: sunxi-ng: a33: Add offset and minimum value for DDR1 PLL N factor
From: Chen-Yu Tsai <wens(a)csie.org>
[ Upstream commit 68f37d862403e8f95337b2eca90af15d0b8cd5d7 ]
The DDR1 PLL on the A33 is an oddball amongst the A33 CCU clocks.
It is a clock multiplier, with the effective multiplier in the
range of 12 ~ 255 and no offset between the multiplier value and
the value programmed into the register.
Implement the zero offset and minimum value of 12 for this clock.
Fixes: d05c748bd730 ("clk: sunxi-ng: Add A33 CCU support")
Signed-off-by: Chen-Yu Tsai <wens(a)csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard(a)free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
@@ -159,13 +159,17 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(
BIT(28), /* lock */
CLK_SET_RATE_UNGATE);
-/* TODO: Fix N */
-static SUNXI_CCU_N_WITH_GATE_LOCK(pll_ddr1_clk, "pll-ddr1",
- "osc24M", 0x04c,
- 8, 6, /* N */
- BIT(31), /* gate */
- BIT(28), /* lock */
- CLK_SET_RATE_UNGATE);
+static struct ccu_mult pll_ddr1_clk = {
+ .enable = BIT(31),
+ .lock = BIT(28),
+ .mult = _SUNXI_CCU_MULT_OFFSET_MIN_MAX(8, 6, 0, 12, 0),
+ .common = {
+ .reg = 0x04c,
+ .hw.init = CLK_HW_INIT("pll-ddr1", "osc24M",
+ &ccu_mult_ops,
+ CLK_SET_RATE_UNGATE),
+ },
+};
static const char * const cpux_parents[] = { "osc32k", "osc24M",
"pll-cpux" , "pll-cpux" };
Patches currently in stable-queue which might be from wens(a)csie.org are
queue-4.9/drm-sun4i-fix-up-error-path-cleanup-for-master-bind-function.patch
queue-4.9/drm-sun4i-set-drm_crtc.port-to-the-underlying-tcon-s-output-port-node.patch
queue-4.9/drm-sun4i-fix-tcon-clock-and-regmap-initialization-sequence.patch
queue-4.9/clk-sunxi-ng-a33-add-offset-and-minimum-value-for-ddr1-pll-n-factor.patch
This is a note to let you know that I've just added the patch titled
clk: qcom: msm8996: Fix the vfe1 powerdomain name
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
clk-qcom-msm8996-fix-the-vfe1-powerdomain-name.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Rajendra Nayak <rnayak(a)codeaurora.org>
Date: Thu, 23 Mar 2017 13:13:40 +0530
Subject: clk: qcom: msm8996: Fix the vfe1 powerdomain name
From: Rajendra Nayak <rnayak(a)codeaurora.org>
[ Upstream commit a62ca337b36e31621b582cbe8f17d9404a48e120 ]
Fix a typo which caused both vfe0 and vfe1 powerdomains to be
named as vfe0.
Signed-off-by: Rajendra Nayak <rnayak(a)codeaurora.org>
Fixes: 7e824d507909 ("clk: qcom: gdsc: Add mmcc gdscs for msm8996 family")
Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org>
Signed-off-by: Michael Turquette <mturquette(a)baylibre.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/qcom/mmcc-msm8996.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/clk/qcom/mmcc-msm8996.c
+++ b/drivers/clk/qcom/mmcc-msm8996.c
@@ -2984,7 +2984,7 @@ static struct gdsc vfe1_gdsc = {
.cxcs = (unsigned int []){ 0x36ac },
.cxc_count = 1,
.pd = {
- .name = "vfe0",
+ .name = "vfe1",
},
.parent = &camss_gdsc.pd,
.pwrsts = PWRSTS_OFF_ON,
Patches currently in stable-queue which might be from rnayak(a)codeaurora.org are
queue-4.9/clk-qcom-msm8996-fix-the-vfe1-powerdomain-name.patch
This is a note to let you know that I've just added the patch titled
clk: qcom: msm8916: fix mnd_width for codec_digcodec
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
clk-qcom-msm8916-fix-mnd_width-for-codec_digcodec.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org>
Date: Wed, 6 Dec 2017 12:11:38 +0000
Subject: clk: qcom: msm8916: fix mnd_width for codec_digcodec
From: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org>
[ Upstream commit d8e488e8242ecf129eebc440c92d800a99ca109d ]
This patch fixes missing mnd_width for codec_digital clk, this is now set to
8 inline with datasheet.
Fixes: 3966fab8b6ab ("clk: qcom: Add MSM8916 Global Clock Controller support")
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org>
Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/qcom/gcc-msm8916.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/clk/qcom/gcc-msm8916.c
+++ b/drivers/clk/qcom/gcc-msm8916.c
@@ -1437,6 +1437,7 @@ static const struct freq_tbl ftbl_codec_
static struct clk_rcg2 codec_digcodec_clk_src = {
.cmd_rcgr = 0x1c09c,
+ .mnd_width = 8,
.hid_width = 5,
.parent_map = gcc_xo_gpll1_emclk_sleep_map,
.freq_tbl = ftbl_codec_clk,
Patches currently in stable-queue which might be from srinivas.kandagatla(a)linaro.org are
queue-4.9/clk-qcom-msm8916-fix-mnd_width-for-codec_digcodec.patch
This is a note to let you know that I've just added the patch titled
clk: meson: gxbb: fix wrong clock for SARADC/SANA
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
clk-meson-gxbb-fix-wrong-clock-for-saradc-sana.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Yixun Lan <yixun.lan(a)amlogic.com>
Date: Tue, 7 Nov 2017 22:12:23 +0800
Subject: clk: meson: gxbb: fix wrong clock for SARADC/SANA
From: Yixun Lan <yixun.lan(a)amlogic.com>
[ Upstream commit 75eccf5ed83250c0aeaeeb76f7288254ac0a87b4 ]
According to the datasheet, in Meson-GXBB/GXL series,
The clock gate bit for SARADC is HHI_GCLK_MPEG2 bit[22],
while clock gate bit for SANA is HHI_GCLK_MPEG0 bit[10].
Test passed at gxl-s905x-p212 board.
The following published datasheets are wrong and should be updated
[1] GXBB v1.1.4
[2] GXL v0.3_20170314
Fixes: 738f66d3211d ("clk: gxbb: add AmLogic GXBB clk controller driver")
Tested-by: Xingyu Chen <xingyu.chen(a)amlogic.com>
Signed-off-by: Yixun Lan <yixun.lan(a)amlogic.com>
Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/meson/gxbb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/clk/meson/gxbb.c
+++ b/drivers/clk/meson/gxbb.c
@@ -572,7 +572,7 @@ static MESON_GATE(gxbb_pl301, HHI_GCLK_M
static MESON_GATE(gxbb_periphs, HHI_GCLK_MPEG0, 7);
static MESON_GATE(gxbb_spicc, HHI_GCLK_MPEG0, 8);
static MESON_GATE(gxbb_i2c, HHI_GCLK_MPEG0, 9);
-static MESON_GATE(gxbb_sar_adc, HHI_GCLK_MPEG0, 10);
+static MESON_GATE(gxbb_sana, HHI_GCLK_MPEG0, 10);
static MESON_GATE(gxbb_smart_card, HHI_GCLK_MPEG0, 11);
static MESON_GATE(gxbb_rng0, HHI_GCLK_MPEG0, 12);
static MESON_GATE(gxbb_uart0, HHI_GCLK_MPEG0, 13);
@@ -623,7 +623,7 @@ static MESON_GATE(gxbb_usb0_ddr_bridge,
static MESON_GATE(gxbb_mmc_pclk, HHI_GCLK_MPEG2, 11);
static MESON_GATE(gxbb_dvin, HHI_GCLK_MPEG2, 12);
static MESON_GATE(gxbb_uart2, HHI_GCLK_MPEG2, 15);
-static MESON_GATE(gxbb_sana, HHI_GCLK_MPEG2, 22);
+static MESON_GATE(gxbb_sar_adc, HHI_GCLK_MPEG2, 22);
static MESON_GATE(gxbb_vpu_intr, HHI_GCLK_MPEG2, 25);
static MESON_GATE(gxbb_sec_ahb_ahb3_bridge, HHI_GCLK_MPEG2, 26);
static MESON_GATE(gxbb_clk81_a53, HHI_GCLK_MPEG2, 29);
Patches currently in stable-queue which might be from yixun.lan(a)amlogic.com are
queue-4.9/clk-meson-gxbb-fix-wrong-clock-for-saradc-sana.patch
This is a note to let you know that I've just added the patch titled
braille-console: Fix value returned by _braille_console_setup
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
braille-console-fix-value-returned-by-_braille_console_setup.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Samuel Thibault <samuel.thibault(a)ens-lyon.org>
Date: Sun, 26 Mar 2017 22:47:36 +0200
Subject: braille-console: Fix value returned by _braille_console_setup
From: Samuel Thibault <samuel.thibault(a)ens-lyon.org>
[ Upstream commit 2ed2b8621be2708c0f6d61fe9841e9ad8b9753f0 ]
commit bbeddf52adc1 ("printk: move braille console support into
separate braille.[ch] files") introduced _braille_console_setup()
to outline the braille initialization code. There was however some
confusion over the value it was supposed to return. commit 2cfe6c4ac7ee
("printk: Fix return of braille_register_console()") tried to fix it
but failed to.
This fixes and documents the returned value according to the use
in printk.c: non-zero return means a parsing error, and thus this
console configuration should be ignored.
Signed-off-by: Samuel Thibault <samuel.thibault(a)ens-lyon.org>
Cc: Aleksey Makarov <aleksey.makarov(a)linaro.org>
Cc: Joe Perches <joe(a)perches.com>
Cc: Ming Lei <ming.lei(a)canonical.com>
Cc: Steven Rostedt <rostedt(a)goodmis.org>
Acked-by: Petr Mladek <pmladek(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/printk/braille.c | 15 ++++++++-------
kernel/printk/braille.h | 13 ++++++++++---
2 files changed, 18 insertions(+), 10 deletions(-)
--- a/kernel/printk/braille.c
+++ b/kernel/printk/braille.c
@@ -2,12 +2,13 @@
#include <linux/kernel.h>
#include <linux/console.h>
+#include <linux/errno.h>
#include <linux/string.h>
#include "console_cmdline.h"
#include "braille.h"
-char *_braille_console_setup(char **str, char **brl_options)
+int _braille_console_setup(char **str, char **brl_options)
{
if (!strncmp(*str, "brl,", 4)) {
*brl_options = "";
@@ -15,14 +16,14 @@ char *_braille_console_setup(char **str,
} else if (!strncmp(*str, "brl=", 4)) {
*brl_options = *str + 4;
*str = strchr(*brl_options, ',');
- if (!*str)
+ if (!*str) {
pr_err("need port name after brl=\n");
- else
- *((*str)++) = 0;
- } else
- return NULL;
+ return -EINVAL;
+ }
+ *((*str)++) = 0;
+ }
- return *str;
+ return 0;
}
int
--- a/kernel/printk/braille.h
+++ b/kernel/printk/braille.h
@@ -9,7 +9,14 @@ braille_set_options(struct console_cmdli
c->brl_options = brl_options;
}
-char *
+/*
+ * Setup console according to braille options.
+ * Return -EINVAL on syntax error, 0 on success (or no braille option was
+ * actually given).
+ * Modifies str to point to the serial options
+ * Sets brl_options to the parsed braille options.
+ */
+int
_braille_console_setup(char **str, char **brl_options);
int
@@ -25,10 +32,10 @@ braille_set_options(struct console_cmdli
{
}
-static inline char *
+static inline int
_braille_console_setup(char **str, char **brl_options)
{
- return NULL;
+ return 0;
}
static inline int
Patches currently in stable-queue which might be from samuel.thibault(a)ens-lyon.org are
queue-4.9/braille-console-fix-value-returned-by-_braille_console_setup.patch
queue-4.9/staging-speakup-replace-bug_on-with-warn_on.patch
This is a note to let you know that I've just added the patch titled
bonding: refine bond_fold_stats() wrap detection
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bonding-refine-bond_fold_stats-wrap-detection.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Eric Dumazet <edumazet(a)google.com>
Date: Wed, 29 Mar 2017 10:45:44 -0700
Subject: bonding: refine bond_fold_stats() wrap detection
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit 142c6594acbcc32391af9c15f8cd65c6c177698f ]
Some device drivers reset their stats at down/up events, possibly
fooling bonding stats, since they operate with relative deltas.
It is nearly not possible to fix drivers, since some of them compute the
tx/rx counters based on per rx/tx queue stats, and the queues can be
reconfigured (ethtool -L) between the down/up sequence.
Lets avoid accumulating 'negative' values that render bonding stats
useless.
It is better to lose small deltas, assuming the bonding stats are
fetched at a reasonable frequency.
Fixes: 5f0c5f73e5ef ("bonding: make global bonding stats more reliable")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/bonding/bond_main.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3331,12 +3331,17 @@ static void bond_fold_stats(struct rtnl_
for (i = 0; i < sizeof(*_res) / sizeof(u64); i++) {
u64 nv = new[i];
u64 ov = old[i];
+ s64 delta = nv - ov;
/* detects if this particular field is 32bit only */
if (((nv | ov) >> 32) == 0)
- res[i] += (u32)nv - (u32)ov;
- else
- res[i] += nv - ov;
+ delta = (s64)(s32)((u32)nv - (u32)ov);
+
+ /* filter anomalies, some drivers reset their stats
+ * at down/up events.
+ */
+ if (delta > 0)
+ res[i] += delta;
}
}
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.9/selinux-check-for-address-length-in-selinux_socket_bind.patch
queue-4.9/bonding-refine-bond_fold_stats-wrap-detection.patch
This is a note to let you know that I've just added the patch titled
bonding: make speed, duplex setting consistent with link state
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bonding-make-speed-duplex-setting-consistent-with-link-state.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Mahesh Bandewar <maheshb(a)google.com>
Date: Mon, 27 Mar 2017 11:37:35 -0700
Subject: bonding: make speed, duplex setting consistent with link state
From: Mahesh Bandewar <maheshb(a)google.com>
[ Upstream commit c4adfc822bf5d8e97660b6114b5a8892530ce8cb ]
bond_update_speed_duplex() retrieves speed and duplex settings. There
is a possibility of failure in retrieving these values but caller has
to assume it's always successful. This leads to having inconsistent
slave link settings. If these (speed, duplex) values cannot be
retrieved, then keeping the link UP causes problems.
The updated bond_update_speed_duplex() returns 0 on success if it
retrieves sane values for speed and duplex. On failure it returns 1
and marks the link down.
Signed-off-by: Mahesh Bandewar <maheshb(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/bonding/bond_main.c | 24 ++++++++++++++----------
1 file changed, 14 insertions(+), 10 deletions(-)
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -371,9 +371,10 @@ down:
/* Get link speed and duplex from the slave's base driver
* using ethtool. If for some reason the call fails or the
* values are invalid, set speed and duplex to -1,
- * and return.
+ * and return. Return 1 if speed or duplex settings are
+ * UNKNOWN; 0 otherwise.
*/
-static void bond_update_speed_duplex(struct slave *slave)
+static int bond_update_speed_duplex(struct slave *slave)
{
struct net_device *slave_dev = slave->dev;
struct ethtool_link_ksettings ecmd;
@@ -383,24 +384,27 @@ static void bond_update_speed_duplex(str
slave->duplex = DUPLEX_UNKNOWN;
res = __ethtool_get_link_ksettings(slave_dev, &ecmd);
- if (res < 0)
- return;
-
- if (ecmd.base.speed == 0 || ecmd.base.speed == ((__u32)-1))
- return;
-
+ if (res < 0) {
+ slave->link = BOND_LINK_DOWN;
+ return 1;
+ }
+ if (ecmd.base.speed == 0 || ecmd.base.speed == ((__u32)-1)) {
+ slave->link = BOND_LINK_DOWN;
+ return 1;
+ }
switch (ecmd.base.duplex) {
case DUPLEX_FULL:
case DUPLEX_HALF:
break;
default:
- return;
+ slave->link = BOND_LINK_DOWN;
+ return 1;
}
slave->speed = ecmd.base.speed;
slave->duplex = ecmd.base.duplex;
- return;
+ return 0;
}
const char *bond_slave_link_status(s8 link)
Patches currently in stable-queue which might be from maheshb(a)google.com are
queue-4.9/bonding-make-speed-duplex-setting-consistent-with-link-state.patch
queue-4.9/ipvlan-add-l2-check-for-packets-arriving-via-virtual-devices.patch
This is a note to let you know that I've just added the patch titled
bnxt_en: Don't print "Link speed -1 no longer supported" messages.
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bnxt_en-don-t-print-link-speed-1-no-longer-supported-messages.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Michael Chan <michael.chan(a)broadcom.com>
Date: Wed, 6 Dec 2017 17:31:22 -0500
Subject: bnxt_en: Don't print "Link speed -1 no longer supported" messages.
From: Michael Chan <michael.chan(a)broadcom.com>
[ Upstream commit a8168b6cee6e9334dfebb4b9108e8d73794f6088 ]
On some dual port NICs, the 2 ports have to be configured with compatible
link speeds. Under some conditions, a port's configured speed may no
longer be supported. The firmware will send a message to the driver
when this happens.
Improve this logic that prints out the warning by only printing it if
we can determine the link speed that is no longer supported. If the
speed is unknown or it is in autoneg mode, skip the warning message.
Reported-by: Thomas Bogendoerfer <tbogendoerfer(a)suse.de>
Signed-off-by: Michael Chan <michael.chan(a)broadcom.com>
Tested-by: Thomas Bogendoerfer <tbogendoerfer(a)suse.de>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -1498,12 +1498,16 @@ static int bnxt_async_event_process(stru
if (BNXT_VF(bp))
goto async_event_process_exit;
- if (data1 & 0x20000) {
+
+ /* print unsupported speed warning in forced speed mode only */
+ if (!(link_info->autoneg & BNXT_AUTONEG_SPEED) &&
+ (data1 & 0x20000)) {
u16 fw_speed = link_info->force_link_speed;
u32 speed = bnxt_fw_to_ethtool_speed(fw_speed);
- netdev_warn(bp->dev, "Link speed %d no longer supported\n",
- speed);
+ if (speed != SPEED_UNKNOWN)
+ netdev_warn(bp->dev, "Link speed %d no longer supported\n",
+ speed);
}
set_bit(BNXT_LINK_SPEED_CHNG_SP_EVENT, &bp->sp_event);
/* fall thru */
Patches currently in stable-queue which might be from michael.chan(a)broadcom.com are
queue-4.9/bnxt_en-don-t-print-link-speed-1-no-longer-supported-messages.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: Avoid bt_accept_unlink() double unlinking
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bluetooth-avoid-bt_accept_unlink-double-unlinking.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Dean Jenkins <Dean_Jenkins(a)mentor.com>
Date: Fri, 10 Mar 2017 11:34:46 +0000
Subject: Bluetooth: Avoid bt_accept_unlink() double unlinking
From: Dean Jenkins <Dean_Jenkins(a)mentor.com>
[ Upstream commit 27bfbc21a0c0f711fa5382de026c7c0700c9ea28 ]
There is a race condition between a thread calling bt_accept_dequeue()
and a different thread calling bt_accept_unlink(). Protection against
concurrency is implemented using sk locking. However, sk locking causes
serialisation of the bt_accept_dequeue() and bt_accept_unlink() threads.
This serialisation can cause bt_accept_dequeue() to obtain the sk from the
parent list but becomes blocked waiting for the sk lock held by the
bt_accept_unlink() thread. bt_accept_unlink() unlinks sk and this thread
releases the sk lock unblocking bt_accept_dequeue() which potentially runs
bt_accept_unlink() again on the same sk causing a crash. The attempt to
double unlink the same sk from the parent list can cause a NULL pointer
dereference crash due to bt_sk(sk)->parent becoming NULL on the first
unlink, followed by the second unlink trying to execute
bt_sk(sk)->parent->sk_ack_backlog-- in bt_accept_unlink() which crashes.
When sk is in the parent list, bt_sk(sk)->parent will be not be NULL.
When sk is removed from the parent list, bt_sk(sk)->parent is set to
NULL. Therefore, add a defensive check for bt_sk(sk)->parent not being
NULL to ensure that sk is still in the parent list after the sk lock has
been taken in bt_accept_dequeue(). If bt_sk(sk)->parent is detected as
being NULL then restart the loop so that the loop variables are refreshed
to use the latest values. This is necessary as list_for_each_entry_safe()
is not thread safe so causing a risk of an infinite loop occurring as sk
could point to itself.
In addition, in bt_accept_dequeue() increase the sk reference count to
protect against early freeing of sk. Early freeing can be possible if the
bt_accept_unlink() thread calls l2cap_sock_kill() or rfcomm_sock_kill()
functions before bt_accept_dequeue() gets the sk lock.
For test purposes, the probability of failure can be increased by putting
a msleep of 1 second in bt_accept_dequeue() between getting the sk and
waiting for the sk lock. This exposes the fact that the loop
list_for_each_entry_safe(p, n, &bt_sk(parent)->accept_q) is not safe from
threads that unlink sk from the list in parallel with the loop which can
cause sk to become stale within the loop.
Signed-off-by: Dean Jenkins <Dean_Jenkins(a)mentor.com>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/bluetooth/af_bluetooth.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
--- a/net/bluetooth/af_bluetooth.c
+++ b/net/bluetooth/af_bluetooth.c
@@ -163,6 +163,9 @@ void bt_accept_enqueue(struct sock *pare
}
EXPORT_SYMBOL(bt_accept_enqueue);
+/* Calling function must hold the sk lock.
+ * bt_sk(sk)->parent must be non-NULL meaning sk is in the parent list.
+ */
void bt_accept_unlink(struct sock *sk)
{
BT_DBG("sk %p state %d", sk, sk->sk_state);
@@ -181,11 +184,32 @@ struct sock *bt_accept_dequeue(struct so
BT_DBG("parent %p", parent);
+restart:
list_for_each_entry_safe(s, n, &bt_sk(parent)->accept_q, accept_q) {
sk = (struct sock *)s;
+ /* Prevent early freeing of sk due to unlink and sock_kill */
+ sock_hold(sk);
lock_sock(sk);
+ /* Check sk has not already been unlinked via
+ * bt_accept_unlink() due to serialisation caused by sk locking
+ */
+ if (!bt_sk(sk)->parent) {
+ BT_DBG("sk %p, already unlinked", sk);
+ release_sock(sk);
+ sock_put(sk);
+
+ /* Restart the loop as sk is no longer in the list
+ * and also avoid a potential infinite loop because
+ * list_for_each_entry_safe() is not thread safe.
+ */
+ goto restart;
+ }
+
+ /* sk is safely in the parent list so reduce reference count */
+ sock_put(sk);
+
/* FIXME: Is this check still needed */
if (sk->sk_state == BT_CLOSED) {
bt_accept_unlink(sk);
Patches currently in stable-queue which might be from Dean_Jenkins(a)mentor.com are
queue-4.9/bluetooth-avoid-bt_accept_unlink-double-unlinking.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: 6lowpan: fix delay work init in add_peer_chan()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bluetooth-6lowpan-fix-delay-work-init-in-add_peer_chan.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Michael Scott <michael.scott(a)linaro.org>
Date: Tue, 28 Mar 2017 23:10:54 -0700
Subject: Bluetooth: 6lowpan: fix delay work init in add_peer_chan()
From: Michael Scott <michael.scott(a)linaro.org>
[ Upstream commit d2891c4d071d807f01cc911dc42a68f4568d65cf ]
When adding 6lowpan devices very rapidly we sometimes see a crash:
[23122.306615] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0-43-arm64 #1 Debian 4.9.9.linaro.43-1
[23122.315400] Hardware name: HiKey Development Board (DT)
[23122.320623] task: ffff800075443080 task.stack: ffff800075484000
[23122.326551] PC is at expire_timers+0x70/0x150
[23122.330907] LR is at run_timer_softirq+0xa0/0x1a0
[23122.335616] pc : [<ffff000008142dd8>] lr : [<ffff000008142f58>] pstate: 600001c5
This was due to add_peer_chan() unconditionally initializing the
lowpan_btle_dev->notify_peers delayed work structure, even if the
lowpan_btle_dev passed into add_peer_chan() had previously been
initialized.
Normally, this would go unnoticed as the delayed work timer is set for
100 msec, however when calling add_peer_chan() faster than 100 msec it
clears out a previously queued delay work causing the crash above.
To fix this, let add_peer_chan() know when a new lowpan_btle_dev is passed
in so that it only performs the delay work initialization when needed.
Signed-off-by: Michael Scott <michael.scott(a)linaro.org>
Acked-by: Jukka Rissanen <jukka.rissanen(a)linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/bluetooth/6lowpan.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -755,7 +755,8 @@ static void set_ip_addr_bits(u8 addr_typ
}
static struct l2cap_chan *add_peer_chan(struct l2cap_chan *chan,
- struct lowpan_btle_dev *dev)
+ struct lowpan_btle_dev *dev,
+ bool new_netdev)
{
struct lowpan_peer *peer;
@@ -786,7 +787,8 @@ static struct l2cap_chan *add_peer_chan(
spin_unlock(&devices_lock);
/* Notifying peers about us needs to be done without locks held */
- INIT_DELAYED_WORK(&dev->notify_peers, do_notify_peers);
+ if (new_netdev)
+ INIT_DELAYED_WORK(&dev->notify_peers, do_notify_peers);
schedule_delayed_work(&dev->notify_peers, msecs_to_jiffies(100));
return peer->chan;
@@ -843,6 +845,7 @@ out:
static inline void chan_ready_cb(struct l2cap_chan *chan)
{
struct lowpan_btle_dev *dev;
+ bool new_netdev = false;
dev = lookup_dev(chan->conn);
@@ -853,12 +856,13 @@ static inline void chan_ready_cb(struct
l2cap_chan_del(chan, -ENOENT);
return;
}
+ new_netdev = true;
}
if (!try_module_get(THIS_MODULE))
return;
- add_peer_chan(chan, dev);
+ add_peer_chan(chan, dev, new_netdev);
ifup(dev->netdev);
}
Patches currently in stable-queue which might be from michael.scott(a)linaro.org are
queue-4.9/bluetooth-6lowpan-fix-delay-work-init-in-add_peer_chan.patch
This is a note to let you know that I've just added the patch titled
blk-throttle: make sure expire time isn't too big
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
blk-throttle-make-sure-expire-time-isn-t-too-big.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Shaohua Li <shli(a)fb.com>
Date: Mon, 27 Mar 2017 10:51:36 -0700
Subject: blk-throttle: make sure expire time isn't too big
From: Shaohua Li <shli(a)fb.com>
[ Upstream commit 06cceedcca67a93ac7f7aa93bbd9980c7496d14e ]
cgroup could be throttled to a limit but when all cgroups cross high
limit, queue enters a higher state and so the group should be throttled
to a higher limit. It's possible the cgroup is sleeping because of
throttle and other cgroups don't dispatch IO any more. In this case,
nobody can trigger current downgrade/upgrade logic. To fix this issue,
we could either set up a timer to wakeup the cgroup if other cgroups are
idle or make sure this cgroup doesn't sleep too long. Setting up a timer
means we must change the timer very frequently. This patch chooses the
latter. Making cgroup sleep time not too big wouldn't change cgroup
bps/iops, but could make it wakeup more frequently, which isn't a big
issue because throtl_slice * 8 is already quite big.
Signed-off-by: Shaohua Li <shli(a)fb.com>
Signed-off-by: Jens Axboe <axboe(a)fb.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/blk-throttle.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -499,6 +499,17 @@ static void throtl_dequeue_tg(struct thr
static void throtl_schedule_pending_timer(struct throtl_service_queue *sq,
unsigned long expires)
{
+ unsigned long max_expire = jiffies + 8 * throtl_slice;
+
+ /*
+ * Since we are adjusting the throttle limit dynamically, the sleep
+ * time calculated according to previous limit might be invalid. It's
+ * possible the cgroup sleep time is very long and no other cgroups
+ * have IO running so notify the limit changes. Make sure the cgroup
+ * doesn't sleep too long to avoid the missed notification.
+ */
+ if (time_after(expires, max_expire))
+ expires = max_expire;
mod_timer(&sq->pending_timer, expires);
throtl_log(sq, "schedule timer. delay=%lu jiffies=%lu",
expires - jiffies, jiffies);
Patches currently in stable-queue which might be from shli(a)fb.com are
queue-4.9/md.c-didn-t-unlock-the-mddev-before-return-einval-in-array_size_store.patch
queue-4.9/md-raid6-fix-anomily-when-recovering-a-single-device-in-raid6.patch
queue-4.9/blk-throttle-make-sure-expire-time-isn-t-too-big.patch
This is a note to let you know that I've just added the patch titled
batman-adv: handle race condition for claims between gateways
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
batman-adv-handle-race-condition-for-claims-between-gateways.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Andreas Pape <APape(a)phoenixcontact.com>
Date: Mon, 5 Sep 2016 13:20:29 +0200
Subject: batman-adv: handle race condition for claims between gateways
From: Andreas Pape <APape(a)phoenixcontact.com>
[ Upstream commit a3a5129e122709306cfa6409781716c2933df99b ]
Consider the following situation which has been found in a test setup:
Gateway B has claimed client C and gateway A has the same backbone
network as B. C sends a broad- or multicast to B and directly after
this packet decides to send another packet to A due to a better TQ
value. B will forward the broad-/multicast into the backbone as it is
the responsible gw and after that A will claim C as it has been
chosen by C as the best gateway. If it now happens that A claims C
before it has received the broad-/multicast forwarded by B (due to
backbone topology or due to some delay in B when forwarding the
packet) we get a critical situation: in the current code A will
immediately unclaim C when receiving the multicast due to the
roaming client scenario although the position of C has not changed
in the mesh. If this happens the multi-/broadcast forwarded by B
will be sent back into the mesh by A and we have looping packets
until one of the gateways claims C again.
In order to prevent this, unclaiming of a client due to the roaming
client scenario is only done after a certain time is expired after
the last claim of the client. 100 ms are used here, which should be
slow enough for big backbones and slow gateways but fast enough not
to break the roaming client use case.
Acked-by: Simon Wunderlich <sw(a)simonwunderlich.de>
Signed-off-by: Andreas Pape <apape(a)phoenixcontact.com>
[sven(a)narfation.org: fix conflicts with current version]
Signed-off-by: Sven Eckelmann <sven(a)narfation.org>
Signed-off-by: Simon Wunderlich <sw(a)simonwunderlich.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/batman-adv/bridge_loop_avoidance.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -1964,10 +1964,22 @@ bool batadv_bla_tx(struct batadv_priv *b
/* if yes, the client has roamed and we have
* to unclaim it.
*/
- batadv_handle_unclaim(bat_priv, primary_if,
- primary_if->net_dev->dev_addr,
- ethhdr->h_source, vid);
- goto allow;
+ if (batadv_has_timed_out(claim->lasttime, 100)) {
+ /* only unclaim if the last claim entry is
+ * older than 100 ms to make sure we really
+ * have a roaming client here.
+ */
+ batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_tx(): Roaming client %pM detected. Unclaim it.\n",
+ ethhdr->h_source);
+ batadv_handle_unclaim(bat_priv, primary_if,
+ primary_if->net_dev->dev_addr,
+ ethhdr->h_source, vid);
+ goto allow;
+ } else {
+ batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_tx(): Race for claim %pM detected. Drop packet.\n",
+ ethhdr->h_source);
+ goto handled;
+ }
}
/* check if it is a multicast/broadcast frame */
Patches currently in stable-queue which might be from APape(a)phoenixcontact.com are
queue-4.9/batman-adv-handle-race-condition-for-claims-between-gateways.patch
This is a note to let you know that I've just added the patch titled
ath10k: update tdls teardown state to target
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ath10k-update-tdls-teardown-state-to-target.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Manikanta Pubbisetty <mpubbise(a)qti.qualcomm.com>
Date: Mon, 6 Nov 2017 13:39:31 +0530
Subject: ath10k: update tdls teardown state to target
From: Manikanta Pubbisetty <mpubbise(a)qti.qualcomm.com>
[ Upstream commit 424ea0d174e82365f85c6770225dba098b8f1d5f ]
It is required to update the teardown state of the peer when
a tdls link with that peer is terminated. This information is
useful for the target to perform some cleanups wrt the tdls peer.
Without proper cleanup, target assumes that the peer is connected and
blocks future connection requests, updating the teardown state of the
peer addresses the problem.
Tested this change on QCA9888 with 10.4-3.5.1-00018 fw version.
Signed-off-by: Manikanta Pubbisetty <mpubbise(a)qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ath/ath10k/mac.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6054,6 +6054,16 @@ static int ath10k_sta_state(struct ieee8
"mac vdev %d peer delete %pM sta %pK (sta gone)\n",
arvif->vdev_id, sta->addr, sta);
+ if (sta->tdls) {
+ ret = ath10k_mac_tdls_peer_update(ar, arvif->vdev_id,
+ sta,
+ WMI_TDLS_PEER_STATE_TEARDOWN);
+ if (ret)
+ ath10k_warn(ar, "failed to update tdls peer state for %pM state %d: %i\n",
+ sta->addr,
+ WMI_TDLS_PEER_STATE_TEARDOWN, ret);
+ }
+
ret = ath10k_peer_delete(ar, arvif->vdev_id, sta->addr);
if (ret)
ath10k_warn(ar, "failed to delete peer %pM for vdev %d: %i\n",
Patches currently in stable-queue which might be from mpubbise(a)qti.qualcomm.com are
queue-4.9/ath10k-update-tdls-teardown-state-to-target.patch
This is a note to let you know that I've just added the patch titled
ath10k: fix invalid STS_CAP_OFFSET_MASK
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ath10k-fix-invalid-sts_cap_offset_mask.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Ben Greear <greearb(a)candelatech.com>
Date: Sat, 2 Dec 2017 16:50:49 +0200
Subject: ath10k: fix invalid STS_CAP_OFFSET_MASK
From: Ben Greear <greearb(a)candelatech.com>
[ Upstream commit 8cec57f5277ef0e354e37a0bf909dc71bc1f865b ]
The 10.4 firmware defines this as a 3-bit field, as does the
mac80211 stack. The 4th bit is defined as CONF_IMPLICIT_BF
at least in the firmware header I have seen. This patch
fixes the ath10k wmi header to match the firmware.
Signed-off-by: Ben Greear <greearb(a)candelatech.com>
Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ath/ath10k/wmi.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -5017,7 +5017,8 @@ enum wmi_10_4_vdev_param {
#define WMI_VDEV_PARAM_TXBF_MU_TX_BFER BIT(3)
#define WMI_TXBF_STS_CAP_OFFSET_LSB 4
-#define WMI_TXBF_STS_CAP_OFFSET_MASK 0xf0
+#define WMI_TXBF_STS_CAP_OFFSET_MASK 0x70
+#define WMI_TXBF_CONF_IMPLICIT_BF BIT(7)
#define WMI_BF_SOUND_DIM_OFFSET_LSB 8
#define WMI_BF_SOUND_DIM_OFFSET_MASK 0xf00
Patches currently in stable-queue which might be from greearb(a)candelatech.com are
queue-4.9/ath10k-fix-invalid-sts_cap_offset_mask.patch
This is a note to let you know that I've just added the patch titled
ath10k: fix fetching channel during potential radar detection
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ath10k-fix-fetching-channel-during-potential-radar-detection.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
Date: Wed, 8 Mar 2017 18:03:32 +0530
Subject: ath10k: fix fetching channel during potential radar detection
From: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
[ Upstream commit a28f6f27a88f047f03f04b9246ca260ebc91455e ]
Fetch target operating channel during potential radar detection when
the interface is just brought up, but no channel is assigned from
userspace. In this scenario rx_channel may not be having a valid pointer
hence fetch the target operating channel to avoid warnings as below
which can be triggered by the commands with DFS testing over longer run
comamnds:
iw wlan1 set type mesh
ifconfig wlan1 up (valid tgt_oper_chan only)
iw wlan1 cac trigger freq 5260 HT20 (valid rx_channel, tgt_oper_chan)
iw wlan1 cac trigger freq 5280 HT20
iw wlan1 cac trigger freq 5300 HT20
Once the CAC expires, current channel context will be removed and
we are only left with the fallback option of using 'target operating
channel'
Firmware and driver log:
ath: phy1: DFS: radar found on freq=5300: id=1, pri=1125, count=5,
count_false=4
ath: phy1: DFS: radar found on freq=5260: id=5, pri=3151, count=6,
count_false=11
ath: phy1: DFS: radar found on freq=5280: id=1, pri=1351, count=6,
count_false=4
ath: phy1: DFS: radar found on freq=5300: id=1, pri=1125, count=5,
count_false=4
ath10k_pci 0001:01:00.0: failed to derive channel for radar pulse,
treating as radar
ath10k_pci 0001:01:00.0: failed to derive channel for radar pulse,
treating as radar
Call trace:
WARNING: CPU: 1 PID: 2145 at
backports-20161201-3.14.77-9ab3068/net/wireless/chan.c:265
cfg80211_set_dfs_state+0x3c/0x88 [cfg80211]()
Workqueue: phy1 ieee80211_dfs_radar_detected_work
[mac80211]
[<c0320770>] (warn_slowpath_null) from [<bf79b90c>]
(cfg80211_set_dfs_state+0x3c/0x88 [cfg80211])
[<bf79b90c>] (cfg80211_set_dfs_state [cfg80211]) from
[<bf79697c>] (cfg80211_radar_event+0xc4/0x140 [cfg80211])
[<bf79697c>] (cfg80211_radar_event [cfg80211]) from
[<bf83c058>] (ieee80211_dfs_radar_detected_work+0xa8/0xb4 [mac80211])
[<bf83c058>] (ieee80211_dfs_radar_detected_work
[mac80211]) from [<c0339518>] (process_one_work+0x298/0x4a4)
Signed-off-by: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ath/ath10k/wmi.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -3638,6 +3638,11 @@ static void ath10k_dfs_radar_report(stru
spin_lock_bh(&ar->data_lock);
ch = ar->rx_channel;
+
+ /* fetch target operating channel during channel change */
+ if (!ch)
+ ch = ar->tgt_oper_chan;
+
spin_unlock_bh(&ar->data_lock);
if (!ch) {
Patches currently in stable-queue which might be from mohammed(a)qti.qualcomm.com are
queue-4.9/ath10k-fix-fetching-channel-during-potential-radar-detection.patch
queue-4.9/ath10k-fix-compile-time-sanity-check-for-ce4-buffer-size.patch
queue-4.9/ath10k-fix-a-warning-during-channel-switch-with-multiple-vaps.patch
queue-4.9/ath10k-disallow-dfs-simulation-if-dfs-channel-is-not-enabled.patch
This is a note to let you know that I've just added the patch titled
ath10k: fix compile time sanity check for CE4 buffer size
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ath10k-fix-compile-time-sanity-check-for-ce4-buffer-size.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
Date: Tue, 4 Apr 2017 22:22:56 +0530
Subject: ath10k: fix compile time sanity check for CE4 buffer size
From: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
[ Upstream commit 62ca0690cd495bb7c1414cdf0cf790c2922a1d79 ]
In 'ath10k_ce_alloc_pipe' the compile time sanity check to
ensure that there is sufficient buffers in CE4 for HTT Tx
MSDU descriptors, but this did not take into account of the
case with 'peer flow control' enabled, fix this.
Cc: Michal Kazior <michal.kazior(a)tieto.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ath/ath10k/ce.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -1059,7 +1059,7 @@ int ath10k_ce_alloc_pipe(struct ath10k *
*/
BUILD_BUG_ON(2 * TARGET_NUM_MSDU_DESC >
(CE_HTT_H2T_MSG_SRC_NENTRIES - 1));
- BUILD_BUG_ON(2 * TARGET_10X_NUM_MSDU_DESC >
+ BUILD_BUG_ON(2 * TARGET_10_4_NUM_MSDU_DESC_PFC >
(CE_HTT_H2T_MSG_SRC_NENTRIES - 1));
BUILD_BUG_ON(2 * TARGET_TLV_NUM_MSDU_DESC >
(CE_HTT_H2T_MSG_SRC_NENTRIES - 1));
Patches currently in stable-queue which might be from mohammed(a)qti.qualcomm.com are
queue-4.9/ath10k-fix-fetching-channel-during-potential-radar-detection.patch
queue-4.9/ath10k-fix-compile-time-sanity-check-for-ce4-buffer-size.patch
queue-4.9/ath10k-fix-a-warning-during-channel-switch-with-multiple-vaps.patch
queue-4.9/ath10k-disallow-dfs-simulation-if-dfs-channel-is-not-enabled.patch
This is a note to let you know that I've just added the patch titled
ath10k: fix a warning during channel switch with multiple vaps
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ath10k-fix-a-warning-during-channel-switch-with-multiple-vaps.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
Date: Wed, 8 Mar 2017 13:52:06 +0200
Subject: ath10k: fix a warning during channel switch with multiple vaps
From: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
[ Upstream commit c73f8c00330f59ce9b1ace9ff698aca83390d358 ]
Doing a channel switch via hostapd_cli seems to update
the new channel context for each VAP's appropriately as below
in 'ath10k_mac_update_vif_chan', hence we can safely suppress the
warning that shows up during this operation and dump the warning only
if no vaps are available for channel switch
hostapd_cli -i wlan0 chan_switch 5 5200
OK
ath10k_pci : mac chanctx switch n_vifs 3 mode 1
ath10k_pci : mac chanctx switch vdev_id 2 freq 5180->5200 width 0->0
ath10k_pci : mac chanctx switch vdev_id 1 freq 5180->5200 width 0->0
ath10k_pci : mac chanctx switch vdev_id 0 freq 5180->5200 width 0->0
Call Trace:
WARNING: backports-20161201-3.14.77-9ab3068/drivers/net/wireless/ath/ath10k/mac.c:7126
[<c022f2d4>] (warn_slowpath_null) from [<bf7f150c>]
(ath10k_reconfig_complete+0xe4/0x25c [ath10k_core])
[<bf7f150c>] (ath10k_reconfig_complete [ath10k_core])
[<bf7f35f0>] (ath10k_mac_vif_ap_csa_work+0x214/0x370 [ath10k_core])
[<bf7f38b8>] (ath10k_mac_op_change_chanctx+0x108/0x128 [ath10k_core])
[<bf782ac0>] (ieee80211_recalc_chanctx_min_def+0x30c/0x430 [mac80211])
[<bf7830a4>] (ieee80211_recalc_smps_chanctx+0x2ec/0x840 [mac80211])
[<bf7843e8>] (ieee80211_vif_use_reserved_context+0x7c/0xf8 [mac80211])
[<bf7843e8>] (ieee80211_vif_use_reserved_context [mac80211])
[<bf76e5d4>] (ieee80211_csa_finalize_work+0x5c/0x88 [mac80211])
Fixes: d7bf4b4aba05 ("ath10k: fix ar->rx_channel updating logic")
Signed-off-by: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ath/ath10k/mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7070,7 +7070,7 @@ ath10k_mac_update_rx_channel(struct ath1
lockdep_assert_held(&ar->data_lock);
WARN_ON(ctx && vifs);
- WARN_ON(vifs && n_vifs != 1);
+ WARN_ON(vifs && !n_vifs);
/* FIXME: Sort of an optimization and a workaround. Peers and vifs are
* on a linked list now. Doing a lookup peer -> vif -> chanctx for each
Patches currently in stable-queue which might be from mohammed(a)qti.qualcomm.com are
queue-4.9/ath10k-fix-fetching-channel-during-potential-radar-detection.patch
queue-4.9/ath10k-fix-compile-time-sanity-check-for-ce4-buffer-size.patch
queue-4.9/ath10k-fix-a-warning-during-channel-switch-with-multiple-vaps.patch
queue-4.9/ath10k-disallow-dfs-simulation-if-dfs-channel-is-not-enabled.patch
This is a note to let you know that I've just added the patch titled
ath10k: disallow DFS simulation if DFS channel is not enabled
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ath10k-disallow-dfs-simulation-if-dfs-channel-is-not-enabled.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
Date: Wed, 22 Feb 2017 21:03:11 +0530
Subject: ath10k: disallow DFS simulation if DFS channel is not enabled
From: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
[ Upstream commit ca07baab0b1e627ae1d4a55d190fb1c9d32a3445 ]
If DFS is not enabled in hostapd (ieee80211h=0) DFS channels shall
not be available for use even though the hardware may have the capability
to support DFS. With this configuration (DFS disabled in hostapd) trying to
bring up ath10k device in DFS channel for AP mode fails and trying to
simulate DFS in ath10k debugfs results in a warning in cfg80211 complaining
invalid channel and this should be avoided in the driver itself rather than
false propogating RADAR detection to mac80211/cfg80211. Fix this by
checking for the first vif 'is_started' state(should work for client mode
as well) as all the vifs shall be configured for the same channel
sys/kernel/debug/ieee80211/phy1/ath10k# echo 1 > dfs_simulate_radar
WARNING: at net/wireless/chan.c:265 cfg80211_radar_event+0x24/0x60
Workqueue: phy0 ieee80211_dfs_radar_detected_work [mac80211]
[<c022f2d4>] (warn_slowpath_null) from
[<bf72dab8>] (cfg80211_radar_event+0x24/0x60 [cfg80211])
[<bf72dab8>] (cfg80211_radar_event [cfg80211]) from
[<bf7813e0>] (ieee80211_dfs_radar_detected_work+0x94/0xa0 [mac80211])
[<bf7813e0>] (ieee80211_dfs_radar_detected_work [mac80211]) from
[<c0242320>] (process_one_work+0x20c/0x32c)
WARNING: at net/wireless/nl80211.c:2488 nl80211_get_mpath+0x13c/0x4cc
Workqueue: phy0 ieee80211_dfs_radar_detected_work [mac80211]
[<c022f2d4>] (warn_slowpath_null) from
[<bf72dab8>] (cfg80211_radar_event+0x24/0x60 [cfg80211])
[<bf72dab8>] (cfg80211_radar_event [cfg80211]) from
[<bf7813e0>] (ieee80211_dfs_radar_detected_work+0x94/0xa0 [mac80211])
[<bf7813e0>] (ieee80211_dfs_radar_detected_work [mac80211]) from
[<c0242320>] (process_one_work+0x20c/0x32c)
Signed-off-by: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ath/ath10k/debug.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1942,6 +1942,15 @@ static ssize_t ath10k_write_simulate_rad
size_t count, loff_t *ppos)
{
struct ath10k *ar = file->private_data;
+ struct ath10k_vif *arvif;
+
+ /* Just check for for the first vif alone, as all the vifs will be
+ * sharing the same channel and if the channel is disabled, all the
+ * vifs will share the same 'is_started' state.
+ */
+ arvif = list_first_entry(&ar->arvifs, typeof(*arvif), list);
+ if (!arvif->is_started)
+ return -EINVAL;
ieee80211_radar_detected(ar->hw);
Patches currently in stable-queue which might be from mohammed(a)qti.qualcomm.com are
queue-4.9/ath10k-fix-fetching-channel-during-potential-radar-detection.patch
queue-4.9/ath10k-fix-compile-time-sanity-check-for-ce4-buffer-size.patch
queue-4.9/ath10k-fix-a-warning-during-channel-switch-with-multiple-vaps.patch
queue-4.9/ath10k-disallow-dfs-simulation-if-dfs-channel-is-not-enabled.patch
This is a note to let you know that I've just added the patch titled
ASoC: rt5677: Add OF device ID table
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
asoc-rt5677-add-of-device-id-table.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Javier Martinez Canillas <javier(a)osg.samsung.com>
Date: Tue, 4 Apr 2017 15:26:30 -0400
Subject: ASoC: rt5677: Add OF device ID table
From: Javier Martinez Canillas <javier(a)osg.samsung.com>
[ Upstream commit 7b87463edf3e2c16d72eeea3d1cf3c12bb5487c6 ]
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.
But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
Before this patch:
$ modinfo sound/soc/codecs/snd-soc-rt5677.ko | grep alias
alias: i2c:RT5677CE:00
alias: i2c:rt5676
alias: i2c:rt5677
After this patch:
$ modinfo sound/soc/codecs/snd-soc-rt5677.ko | grep alias
alias: of:N*T*Crealtek,rt5677C*
alias: of:N*T*Crealtek,rt5677
alias: i2c:RT5677CE:00
alias: i2c:rt5676
alias: i2c:rt5677
Signed-off-by: Javier Martinez Canillas <javier(a)osg.samsung.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/codecs/rt5677.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/sound/soc/codecs/rt5677.c
+++ b/sound/soc/codecs/rt5677.c
@@ -5035,6 +5035,12 @@ static const struct i2c_device_id rt5677
};
MODULE_DEVICE_TABLE(i2c, rt5677_i2c_id);
+static const struct of_device_id rt5677_of_match[] = {
+ { .compatible = "realtek,rt5677", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, rt5677_of_match);
+
static const struct acpi_gpio_params plug_det_gpio = { RT5677_GPIO_PLUG_DET, 0, false };
static const struct acpi_gpio_params mic_present_gpio = { RT5677_GPIO_MIC_PRESENT_L, 0, false };
static const struct acpi_gpio_params headphone_enable_gpio = { RT5677_GPIO_HP_AMP_SHDN_L, 0, false };
@@ -5294,6 +5300,7 @@ static int rt5677_i2c_remove(struct i2c_
static struct i2c_driver rt5677_i2c_driver = {
.driver = {
.name = "rt5677",
+ .of_match_table = rt5677_of_match,
},
.probe = rt5677_i2c_probe,
.remove = rt5677_i2c_remove,
Patches currently in stable-queue which might be from javier(a)osg.samsung.com are
queue-4.9/asoc-rt5677-add-of-device-id-table.patch
queue-4.9/regulator-core-limit-propagation-of-parent-voltage-count-and-list.patch
queue-4.9/input-qt1070-add-of-device-id-table.patch
This is a note to let you know that I've just added the patch titled
ASoC: rcar: ssi: don't set SSICR.CKDV = 000 with SSIWSR.CONT
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
asoc-rcar-ssi-don-t-set-ssicr.ckdv-000-with-ssiwsr.cont.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
Date: Wed, 22 Mar 2017 04:02:43 +0000
Subject: ASoC: rcar: ssi: don't set SSICR.CKDV = 000 with SSIWSR.CONT
From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
[ Upstream commit 6b8530cc056efd4a11b034ca5b1e9f7e9563f553 ]
R-Car Datasheet is indicating "SSICR.CKDV = 000 is invalid when
SSIWSR.WS_MODE = 1 or SSIWSR.CONT = 1".
Current driver will set CONT, thus, we shouldn't use CKDV = 000.
This patch fixup it.
Reported-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
Tested-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/sh/rcar/ssi.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -233,6 +233,15 @@ static int rsnd_ssi_master_clk_start(str
for (j = 0; j < ARRAY_SIZE(ssi_clk_mul_table); j++) {
/*
+ * It will set SSIWSR.CONT here, but SSICR.CKDV = 000
+ * with it is not allowed. (SSIWSR.WS_MODE with
+ * SSICR.CKDV = 000 is not allowed either).
+ * Skip it. See SSICR.CKDV
+ */
+ if (j == 0)
+ continue;
+
+ /*
* this driver is assuming that
* system word is 32bit x chan
* see rsnd_ssi_init()
Patches currently in stable-queue which might be from kuninori.morimoto.gx(a)renesas.com are
queue-4.9/asoc-rcar-ssi-don-t-set-ssicr.ckdv-000-with-ssiwsr.cont.patch
This is a note to let you know that I've just added the patch titled
ASoC: nuc900: Fix a loop timeout test
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
asoc-nuc900-fix-a-loop-timeout-test.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Sat, 9 Dec 2017 14:52:28 +0300
Subject: ASoC: nuc900: Fix a loop timeout test
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ Upstream commit 65a12b3aafed5fc59f4ce41b22b752b1729e6701 ]
We should be finishing the loop with timeout set to zero but because
this is a post-op we finish with timeout == -1.
Fixes: 1082e2703a2d ("ASoC: NUC900/audio: add nuc900 audio driver support")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/nuc900/nuc900-ac97.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/sound/soc/nuc900/nuc900-ac97.c
+++ b/sound/soc/nuc900/nuc900-ac97.c
@@ -67,7 +67,7 @@ static unsigned short nuc900_ac97_read(s
/* polling the AC_R_FINISH */
while (!(AUDIO_READ(nuc900_audio->mmio + ACTL_ACCON) & AC_R_FINISH)
- && timeout--)
+ && --timeout)
mdelay(1);
if (!timeout) {
@@ -121,7 +121,7 @@ static void nuc900_ac97_write(struct snd
/* polling the AC_W_FINISH */
while ((AUDIO_READ(nuc900_audio->mmio + ACTL_ACCON) & AC_W_FINISH)
- && timeout--)
+ && --timeout)
mdelay(1);
if (!timeout)
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.9/media-cpia2-fix-a-couple-off-by-one-bugs.patch
queue-4.9/nfc-nfcmrvl-double-free-on-error-path.patch
queue-4.9/asoc-nuc900-fix-a-loop-timeout-test.patch
This is a note to let you know that I've just added the patch titled
arm64: dts: r8a7796: Remove unit-address and reg from integrated cache
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm64-dts-r8a7796-remove-unit-address-and-reg-from-integrated-cache.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Fri, 3 Mar 2017 14:18:17 +0100
Subject: arm64: dts: r8a7796: Remove unit-address and reg from integrated cache
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
[ Upstream commit 57a4fd420c6e8a04b6a87ff24d34250cd7c48f15 ]
The Cortex-A57 cache controller is an integrated controller, and thus
the device node representing it should not have a unit-addresses or reg
property.
Fixes: 1561f20760ec96db ("arm64: dts: r8a7796: Add Renesas R8A7796 SoC support")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -36,9 +36,8 @@
enable-method = "psci";
};
- L2_CA57: cache-controller@0 {
+ L2_CA57: cache-controller-0 {
compatible = "cache";
- reg = <0>;
power-domains = <&sysc R8A7796_PD_CA57_SCU>;
cache-unified;
cache-level = <2>;
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-4.9/arm64-dts-r8a7796-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7791-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r7s72100-fix-ethernet-clock-parent.patch
queue-4.9/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-silk-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7792-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch
queue-4.9/arm-dts-r8a7794-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7794-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-r8a7790-correct-parent-of-ssi-clocks.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: silk: Correct clock of DU1
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-silk-correct-clock-of-du1.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Tue, 28 Mar 2017 12:45:33 +0200
Subject: ARM: dts: silk: Correct clock of DU1
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
[ Upstream commit 403fe77e22eb72c962c3889efc9d4fa62e454737 ]
The second channel of the display unit uses a different module clock
than the first channel.
Fixes: 84e734f497cd48f6 ("ARM: dts: silk: add DU DT support")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Acked-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/r8a7794-silk.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/r8a7794-silk.dts
+++ b/arch/arm/boot/dts/r8a7794-silk.dts
@@ -425,7 +425,7 @@
status = "okay";
clocks = <&mstp7_clks R8A7794_CLK_DU0>,
- <&mstp7_clks R8A7794_CLK_DU0>,
+ <&mstp7_clks R8A7794_CLK_DU1>,
<&x2_clk>, <&x3_clk>;
clock-names = "du.0", "du.1", "dclkin.0", "dclkin.1";
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-4.9/arm64-dts-r8a7796-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7791-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r7s72100-fix-ethernet-clock-parent.patch
queue-4.9/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-silk-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7792-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch
queue-4.9/arm-dts-r8a7794-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7794-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-r8a7790-correct-parent-of-ssi-clocks.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: r8a7794: Remove unit-address and reg from integrated cache
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-r8a7794-remove-unit-address-and-reg-from-integrated-cache.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Mon, 6 Mar 2017 17:40:43 +0100
Subject: ARM: dts: r8a7794: Remove unit-address and reg from integrated cache
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
[ Upstream commit 65d0b7ed40f8a3a41a0ac5ed5ca4d1874c6aaf2d ]
The Cortex-A7 cache controller is an integrated controller, and thus the
device node representing it should not have a unit-addresses or reg
property.
Fixes: 34ea4b4a827b4ee7 ("ARM: dts: r8a7794: Fix W=1 dtc warnings")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/r8a7794.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -56,9 +56,8 @@
next-level-cache = <&L2_CA7>;
};
- L2_CA7: cache-controller@0 {
+ L2_CA7: cache-controller-0 {
compatible = "cache";
- reg = <0>;
power-domains = <&sysc R8A7794_PD_CA7_SCU>;
cache-unified;
cache-level = <2>;
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-4.9/arm64-dts-r8a7796-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7791-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r7s72100-fix-ethernet-clock-parent.patch
queue-4.9/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-silk-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7792-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch
queue-4.9/arm-dts-r8a7794-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7794-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-r8a7790-correct-parent-of-ssi-clocks.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: r8a7794: Correct clock of DU1
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-r8a7794-correct-clock-of-du1.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Tue, 28 Mar 2017 12:45:31 +0200
Subject: ARM: dts: r8a7794: Correct clock of DU1
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
[ Upstream commit 89675f36c9e17512812b9d14d9824f8ef92782c3 ]
The second channel of the display unit uses a different module clock
than the first channel.
Fixes: 46c4f13d04d729fa ("ARM: shmobile: r8a7794: Add DU node to device tree")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Acked-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/r8a7794.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -916,7 +916,7 @@
interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp7_clks R8A7794_CLK_DU0>,
- <&mstp7_clks R8A7794_CLK_DU0>;
+ <&mstp7_clks R8A7794_CLK_DU1>;
clock-names = "du.0", "du.1";
status = "disabled";
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-4.9/arm64-dts-r8a7796-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7791-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r7s72100-fix-ethernet-clock-parent.patch
queue-4.9/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-silk-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7792-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch
queue-4.9/arm-dts-r8a7794-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7794-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-r8a7790-correct-parent-of-ssi-clocks.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: r8a7793: Remove unit-address and reg from integrated cache
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-r8a7793-remove-unit-address-and-reg-from-integrated-cache.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Mon, 6 Mar 2017 17:40:42 +0100
Subject: ARM: dts: r8a7793: Remove unit-address and reg from integrated cache
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
[ Upstream commit beffa8872a3680ef804eb0320ec77037170f4686 ]
The Cortex-A15 cache controller is an integrated controller, and thus
the device node representing it should not have a unit-addresses or reg
property.
Fixes: ad53f5f00b095a0d ("ARM: dts: r8a7793: Fix W=1 dtc warnings")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/r8a7793.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -65,9 +65,8 @@
power-domains = <&sysc R8A7793_PD_CA15_CPU1>;
};
- L2_CA15: cache-controller@0 {
+ L2_CA15: cache-controller-0 {
compatible = "cache";
- reg = <0>;
power-domains = <&sysc R8A7793_PD_CA15_SCU>;
cache-unified;
cache-level = <2>;
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-4.9/arm64-dts-r8a7796-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7791-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r7s72100-fix-ethernet-clock-parent.patch
queue-4.9/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-silk-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7792-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch
queue-4.9/arm-dts-r8a7794-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7794-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-r8a7790-correct-parent-of-ssi-clocks.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: r8a7793: Correct parent of SSI[0-9] clocks
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-r8a7793-correct-parent-of-ssi-clocks.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Mon, 3 Apr 2017 11:45:43 +0200
Subject: ARM: dts: r8a7793: Correct parent of SSI[0-9] clocks
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
[ Upstream commit 1cd9028027c7a7c10b774df698c3cfafec6aa67d ]
The SSI-ALL gate clock is located in between the P clock and the
individual SSI[0-9] clocks, hence the former should be listed as their
parent.
Fixes: 072d326542e49187 ("ARM: dts: r8a7793: add MSTP10 clocks to device tree")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/r8a7793.dtsi | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -1234,8 +1234,11 @@
compatible = "renesas,r8a7793-mstp-clocks", "renesas,cpg-mstp-clocks";
reg = <0 0xe6150998 0 4>, <0 0xe61509a8 0 4>;
clocks = <&p_clk>,
- <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
- <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
+ <&mstp10_clks R8A7793_CLK_SSI_ALL>, <&mstp10_clks R8A7793_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7793_CLK_SSI_ALL>, <&mstp10_clks R8A7793_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7793_CLK_SSI_ALL>, <&mstp10_clks R8A7793_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7793_CLK_SSI_ALL>, <&mstp10_clks R8A7793_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7793_CLK_SSI_ALL>, <&mstp10_clks R8A7793_CLK_SSI_ALL>,
<&p_clk>,
<&mstp10_clks R8A7793_CLK_SCU_ALL>, <&mstp10_clks R8A7793_CLK_SCU_ALL>,
<&mstp10_clks R8A7793_CLK_SCU_ALL>, <&mstp10_clks R8A7793_CLK_SCU_ALL>,
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-4.9/arm64-dts-r8a7796-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7791-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r7s72100-fix-ethernet-clock-parent.patch
queue-4.9/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-silk-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7792-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch
queue-4.9/arm-dts-r8a7794-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7794-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-r8a7790-correct-parent-of-ssi-clocks.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: r8a7792: Remove unit-address and reg from integrated cache
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-r8a7792-remove-unit-address-and-reg-from-integrated-cache.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Mon, 6 Mar 2017 17:40:41 +0100
Subject: ARM: dts: r8a7792: Remove unit-address and reg from integrated cache
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
[ Upstream commit a0504f0880c11da301dc2b5a5135bd02376e367e ]
The Cortex-A15 cache controller is an integrated controller, and thus
the device node representing it should not have a unit-addresses or reg
property.
Fixes: 7c4163aae3d8e5b9 ("ARM: dts: r8a7792: initial SoC device tree")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/r8a7792.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dtsi
@@ -58,9 +58,8 @@
next-level-cache = <&L2_CA15>;
};
- L2_CA15: cache-controller@0 {
+ L2_CA15: cache-controller-0 {
compatible = "cache";
- reg = <0>;
cache-unified;
cache-level = <2>;
power-domains = <&sysc R8A7792_PD_CA15_SCU>;
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-4.9/arm64-dts-r8a7796-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7791-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r7s72100-fix-ethernet-clock-parent.patch
queue-4.9/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-silk-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7792-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch
queue-4.9/arm-dts-r8a7794-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7794-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-r8a7790-correct-parent-of-ssi-clocks.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: r8a7791: Remove unit-address and reg from integrated cache
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-r8a7791-remove-unit-address-and-reg-from-integrated-cache.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Mon, 6 Mar 2017 17:40:40 +0100
Subject: ARM: dts: r8a7791: Remove unit-address and reg from integrated cache
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
[ Upstream commit 5d6a2165abd4635ecf5ece3d02fe8677f00d32c5 ]
The Cortex-A15 cache controller is an integrated controller, and thus
the device node representing it should not have a unit-addresses or reg
property.
Fixes: 6f9314ce258c8504 ("ARM: dts: r8a7791: Fix W=1 dtc warnings")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/r8a7791.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -74,9 +74,8 @@
next-level-cache = <&L2_CA15>;
};
- L2_CA15: cache-controller@0 {
+ L2_CA15: cache-controller-0 {
compatible = "cache";
- reg = <0>;
power-domains = <&sysc R8A7791_PD_CA15_SCU>;
cache-unified;
cache-level = <2>;
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-4.9/arm64-dts-r8a7796-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7791-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r7s72100-fix-ethernet-clock-parent.patch
queue-4.9/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-silk-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7792-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch
queue-4.9/arm-dts-r8a7794-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7794-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-r8a7790-correct-parent-of-ssi-clocks.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: r8a7791: Correct parent of SSI[0-9] clocks
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Mon, 3 Apr 2017 11:45:42 +0200
Subject: ARM: dts: r8a7791: Correct parent of SSI[0-9] clocks
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
[ Upstream commit 16fe68dcab5702a024d85229ff7e98979cb701a5 ]
The SSI-ALL gate clock is located in between the P clock and the
individual SSI[0-9] clocks, hence the former should be listed as their
parent.
Fixes: ee9141522dcf13f8 ("ARM: shmobile: r8a7791: add MSTP10 support on DTSI")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/r8a7791.dtsi | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -1437,8 +1437,11 @@
compatible = "renesas,r8a7791-mstp-clocks", "renesas,cpg-mstp-clocks";
reg = <0 0xe6150998 0 4>, <0 0xe61509a8 0 4>;
clocks = <&p_clk>,
- <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
- <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
+ <&mstp10_clks R8A7791_CLK_SSI_ALL>, <&mstp10_clks R8A7791_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7791_CLK_SSI_ALL>, <&mstp10_clks R8A7791_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7791_CLK_SSI_ALL>, <&mstp10_clks R8A7791_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7791_CLK_SSI_ALL>, <&mstp10_clks R8A7791_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7791_CLK_SSI_ALL>, <&mstp10_clks R8A7791_CLK_SSI_ALL>,
<&p_clk>,
<&mstp10_clks R8A7791_CLK_SCU_ALL>, <&mstp10_clks R8A7791_CLK_SCU_ALL>,
<&mstp10_clks R8A7791_CLK_SCU_ALL>, <&mstp10_clks R8A7791_CLK_SCU_ALL>,
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-4.9/arm64-dts-r8a7796-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7791-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r7s72100-fix-ethernet-clock-parent.patch
queue-4.9/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-silk-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7792-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch
queue-4.9/arm-dts-r8a7794-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7794-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-r8a7790-correct-parent-of-ssi-clocks.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: r8a7790: Correct parent of SSI[0-9] clocks
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-r8a7790-correct-parent-of-ssi-clocks.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Mon, 3 Apr 2017 11:45:41 +0200
Subject: ARM: dts: r8a7790: Correct parent of SSI[0-9] clocks
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
[ Upstream commit d13d4e063d4a08eb1686e890e9183dde709871bf ]
The SSI-ALL gate clock is located in between the P clock and the
individual SSI[0-9] clocks, hence the former should be listed as their
parent.
Fixes: bcde372254386872 ("ARM: shmobile: r8a7790: add MSTP10 support on DTSI")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/r8a7790.dtsi | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1437,8 +1437,11 @@
compatible = "renesas,r8a7790-mstp-clocks", "renesas,cpg-mstp-clocks";
reg = <0 0xe6150998 0 4>, <0 0xe61509a8 0 4>;
clocks = <&p_clk>,
- <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
- <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
+ <&mstp10_clks R8A7790_CLK_SSI_ALL>, <&mstp10_clks R8A7790_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7790_CLK_SSI_ALL>, <&mstp10_clks R8A7790_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7790_CLK_SSI_ALL>, <&mstp10_clks R8A7790_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7790_CLK_SSI_ALL>, <&mstp10_clks R8A7790_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7790_CLK_SSI_ALL>, <&mstp10_clks R8A7790_CLK_SSI_ALL>,
<&p_clk>,
<&mstp10_clks R8A7790_CLK_SCU_ALL>, <&mstp10_clks R8A7790_CLK_SCU_ALL>,
<&mstp10_clks R8A7790_CLK_SCU_ALL>, <&mstp10_clks R8A7790_CLK_SCU_ALL>,
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-4.9/arm64-dts-r8a7796-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7791-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r7s72100-fix-ethernet-clock-parent.patch
queue-4.9/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-silk-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7792-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch
queue-4.9/arm-dts-r8a7794-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7794-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-r8a7790-correct-parent-of-ssi-clocks.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: r7s72100: fix ethernet clock parent
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-r7s72100-fix-ethernet-clock-parent.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Chris Brandt <chris.brandt(a)renesas.com>
Date: Thu, 30 Mar 2017 14:16:09 -0700
Subject: ARM: dts: r7s72100: fix ethernet clock parent
From: Chris Brandt <chris.brandt(a)renesas.com>
[ Upstream commit 91a7c50cb4fabfba218549dfa84356069918bfbf ]
Technically, the Ethernet block is run off the 133MHz Bus (B) clock, not
the 33MHz Peripheral 0 (P0) clock.
Fixes: 969244f9c720 ("ARM: dts: r7s72100: add ethernet clock to device tree")
Signed-off-by: Chris Brandt <chris.brandt(a)renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/r7s72100.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -112,7 +112,7 @@
#clock-cells = <1>;
compatible = "renesas,r7s72100-mstp-clocks", "renesas,cpg-mstp-clocks";
reg = <0xfcfe0430 4>;
- clocks = <&p0_clk>;
+ clocks = <&b_clk>;
clock-indices = <R7S72100_CLK_ETHER>;
clock-output-names = "ether";
};
Patches currently in stable-queue which might be from chris.brandt(a)renesas.com are
queue-4.9/arm-dts-r7s72100-fix-ethernet-clock-parent.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: omap3-n900: Fix the audio CODEC's reset pin
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-omap3-n900-fix-the-audio-codec-s-reset-pin.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: "Andrew F. Davis" <afd(a)ti.com>
Date: Wed, 29 Nov 2017 11:13:59 -0600
Subject: ARM: dts: omap3-n900: Fix the audio CODEC's reset pin
From: "Andrew F. Davis" <afd(a)ti.com>
[ Upstream commit 7be4b5dc7ffa9499ac6ef33a5ffa9ff43f9b7057 ]
The correct DT property for specifying a GPIO used for reset
is "reset-gpios", fix this here.
Fixes: 14e3e295b2b9 ("ARM: dts: omap3-n900: Add TLV320AIC3X support")
Signed-off-by: Andrew F. Davis <afd(a)ti.com>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/omap3-n900.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -510,7 +510,7 @@
tlv320aic3x: tlv320aic3x@18 {
compatible = "ti,tlv320aic3x";
reg = <0x18>;
- gpio-reset = <&gpio2 28 GPIO_ACTIVE_HIGH>; /* 60 */
+ reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>; /* 60 */
ai3x-gpio-func = <
0 /* AIC3X_GPIO1_FUNC_DISABLED */
5 /* AIC3X_GPIO2_FUNC_DIGITAL_MIC_INPUT */
@@ -527,7 +527,7 @@
tlv320aic3x_aux: tlv320aic3x@19 {
compatible = "ti,tlv320aic3x";
reg = <0x19>;
- gpio-reset = <&gpio2 28 GPIO_ACTIVE_HIGH>; /* 60 */
+ reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>; /* 60 */
AVDD-supply = <&vmmc2>;
DRVDD-supply = <&vmmc2>;
Patches currently in stable-queue which might be from afd(a)ti.com are
queue-4.9/arm-dts-omap3-n900-fix-the-audio-codec-s-reset-pin.patch
queue-4.9/arm-dts-am335x-pepper-fix-the-audio-codec-s-reset-pin.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: koelsch: Correct clock frequency of X2 DU clock input
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Mon, 3 Apr 2017 11:55:19 +0200
Subject: ARM: dts: koelsch: Correct clock frequency of X2 DU clock input
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
[ Upstream commit ebf06af55c7594ed1fc18469a5cddf911c40e687 ]
The X2 crystal oscillator on the Koelsch development board provides a
74.25 MHz clock, not a 148.5 MHz clock.
Fixes: cd21cb46e14aae3a ("ARM: shmobile: koelsch: Add DU external pixel clocks to DT")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Acked-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Tested-by: Niklas Söderlund <niklas.soderlund+renesas(a)ragnatech.se>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/r8a7791-koelsch.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -279,7 +279,7 @@
x2_clk: x2-clock {
compatible = "fixed-clock";
#clock-cells = <0>;
- clock-frequency = <148500000>;
+ clock-frequency = <74250000>;
};
x13_clk: x13-clock {
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-4.9/arm64-dts-r8a7796-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7791-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r7s72100-fix-ethernet-clock-parent.patch
queue-4.9/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-silk-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7792-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch
queue-4.9/arm-dts-r8a7794-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7794-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-r8a7790-correct-parent-of-ssi-clocks.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: exynos: Correct Trats2 panel reset line
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-exynos-correct-trats2-panel-reset-line.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Simon Shields <simon(a)lineageos.org>
Date: Tue, 21 Nov 2017 22:24:24 +1100
Subject: ARM: dts: exynos: Correct Trats2 panel reset line
From: Simon Shields <simon(a)lineageos.org>
[ Upstream commit 1b377924841df1e13ab5b225be3a83f807a92b52 ]
Trats2 uses gpf2-1 as the panel reset GPIO. gpy4-5 was only used
on early revisions of the board.
Fixes: 420ae8451a22 ("ARM: dts: exynos4412-trats2: add panel node")
Signed-off-by: Simon Shields <simon(a)lineageos.org>
Acked-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/exynos4412-trats2.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -408,7 +408,7 @@
reg = <0>;
vdd3-supply = <&lcd_vdd3_reg>;
vci-supply = <&ldo25_reg>;
- reset-gpios = <&gpy4 5 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpf2 1 GPIO_ACTIVE_HIGH>;
power-on-delay= <50>;
reset-delay = <100>;
init-delay = <100>;
Patches currently in stable-queue which might be from simon(a)lineageos.org are
queue-4.9/arm-dts-exynos-correct-trats2-panel-reset-line.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: bcm2835: add index to the ethernet alias
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-bcm2835-add-index-to-the-ethernet-alias.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Baruch Siach <baruch(a)tkos.co.il>
Date: Mon, 30 Jan 2017 20:44:39 +0200
Subject: ARM: dts: bcm2835: add index to the ethernet alias
From: Baruch Siach <baruch(a)tkos.co.il>
[ Upstream commit 10b6c0c2e2bb8cd1be682f8d36ef597e3419cb88 ]
An alias name should have an index number even when it is the only of its type.
This allows U-Boot to add the local-mac-address property. Otherwise U-Boot
skips the alias.
Fixes: 6a93792774 ("ARM: bcm2835: dt: Add the ethernet to the device trees")
Signed-off-by: Baruch Siach <baruch(a)tkos.co.il>
Acked-by: Lubomir Rintel <lkundrak(a)v3.sk>
Reviewed-by: Eric Anholt <eric(a)anholt.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/bcm283x-rpi-smsc9512.dtsi | 2 +-
arch/arm/boot/dts/bcm283x-rpi-smsc9514.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/bcm283x-rpi-smsc9512.dtsi
+++ b/arch/arm/boot/dts/bcm283x-rpi-smsc9512.dtsi
@@ -1,6 +1,6 @@
/ {
aliases {
- ethernet = ðernet;
+ ethernet0 = ðernet;
};
};
--- a/arch/arm/boot/dts/bcm283x-rpi-smsc9514.dtsi
+++ b/arch/arm/boot/dts/bcm283x-rpi-smsc9514.dtsi
@@ -1,6 +1,6 @@
/ {
aliases {
- ethernet = ðernet;
+ ethernet0 = ðernet;
};
};
Patches currently in stable-queue which might be from baruch(a)tkos.co.il are
queue-4.9/arm-dts-bcm2835-add-index-to-the-ethernet-alias.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: am335x-pepper: Fix the audio CODEC's reset pin
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-am335x-pepper-fix-the-audio-codec-s-reset-pin.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: "Andrew F. Davis" <afd(a)ti.com>
Date: Wed, 29 Nov 2017 11:13:56 -0600
Subject: ARM: dts: am335x-pepper: Fix the audio CODEC's reset pin
From: "Andrew F. Davis" <afd(a)ti.com>
[ Upstream commit e153db03c6b7a035c797bcdf35262586f003ee93 ]
The correct DT property for specifying a GPIO used for reset
is "reset-gpios", fix this here.
Fixes: 4341881d0562 ("ARM: dts: Add devicetree for Gumstix Pepper board")
Signed-off-by: Andrew F. Davis <afd(a)ti.com>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/am335x-pepper.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/am335x-pepper.dts
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -139,7 +139,7 @@
&audio_codec {
status = "okay";
- gpio-reset = <&gpio1 16 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
AVDD-supply = <&ldo3_reg>;
IOVDD-supply = <&ldo3_reg>;
DRVDD-supply = <&ldo3_reg>;
Patches currently in stable-queue which might be from afd(a)ti.com are
queue-4.9/arm-dts-omap3-n900-fix-the-audio-codec-s-reset-pin.patch
queue-4.9/arm-dts-am335x-pepper-fix-the-audio-codec-s-reset-pin.patch
This is a note to let you know that I've just added the patch titled
ARM: DRA7: hwmod_data: Prevent wait_target_disable error for usb_otg_ss
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dra7-hwmod_data-prevent-wait_target_disable-error-for-usb_otg_ss.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Roger Quadros <rogerq(a)ti.com>
Date: Mon, 13 Mar 2017 13:53:16 +0200
Subject: ARM: DRA7: hwmod_data: Prevent wait_target_disable error for usb_otg_ss
From: Roger Quadros <rogerq(a)ti.com>
[ Upstream commit e2d54fe76997301b49311bde7ba8ef52b47896f9 ]
It seems that if L3_INIT clkdomain is kept in HW_AUTO while usb_otg_ss
is in use then there are random chances that the usb_otg_ss module
will fail to completely idle. i.e. IDLEST = 0x2 instead of 0x3.
Preventing L3_INIT from HW_AUTO while usb_otg_ss module is in use
fixes this issue.
We don't know yet if usb_otg_ss instances 3 and 4 are affected by this
issue or not so don't add this flag for those instances.
Cc: Tero Kristo <t-kristo(a)ti.com>
Signed-off-by: Roger Quadros <rogerq(a)ti.com>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -2572,6 +2572,7 @@ static struct omap_hwmod dra7xx_usb_otg_
.class = &dra7xx_usb_otg_ss_hwmod_class,
.clkdm_name = "l3init_clkdm",
.main_clk = "dpll_core_h13x2_ck",
+ .flags = HWMOD_CLKDM_NOAUTO,
.prcm = {
.omap4 = {
.clkctrl_offs = DRA7XX_CM_L3INIT_USB_OTG_SS1_CLKCTRL_OFFSET,
@@ -2593,6 +2594,7 @@ static struct omap_hwmod dra7xx_usb_otg_
.class = &dra7xx_usb_otg_ss_hwmod_class,
.clkdm_name = "l3init_clkdm",
.main_clk = "dpll_core_h13x2_ck",
+ .flags = HWMOD_CLKDM_NOAUTO,
.prcm = {
.omap4 = {
.clkctrl_offs = DRA7XX_CM_L3INIT_USB_OTG_SS2_CLKCTRL_OFFSET,
Patches currently in stable-queue which might be from rogerq(a)ti.com are
queue-4.9/arm-dra7-hwmod_data-prevent-wait_target_disable-error-for-usb_otg_ss.patch
This is a note to let you know that I've just added the patch titled
ARM: brcmstb: Enable ZONE_DMA for non 64-bit capable peripherals
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-brcmstb-enable-zone_dma-for-non-64-bit-capable-peripherals.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Al Cooper <alcooperx(a)gmail.com>
Date: Thu, 9 Mar 2017 10:51:18 -0800
Subject: ARM: brcmstb: Enable ZONE_DMA for non 64-bit capable peripherals
From: Al Cooper <alcooperx(a)gmail.com>
[ Upstream commit 3c51b9c7f1fae00c25f1e34da649a288e3fea1ae ]
Some Host Controller hardware blocks, like the OHCI, EHCI and SDIO
controllers, have hardware blocks that are not capable of doing 64 bit
DMA. These host controllers fail on boards with >3GB of memory because
the memory above 3GB is located physically >= 0x100000000 and can only
be accessed using 64 DMA. The way Linux is currently configured for
BRCMSTB systems, the memory given to drivers for DMA through functions
like dma_alloc_coherent() comes from CMA memory and CMA memory is taken
from the top of physical memory. When these drivers get a DMA buffer
with an address >=0x100000000, they end up dropping the upper 32 bit of
the address causing the hardware to DMA to incorrect memory, typically
BMEM (custom memory carveout). This issue was discovered on a
BCM97449SSV_DDR4 system with 4GB or memory.
The fix is to enable CONFIG_ZONE_DMA. On ARM systems this makes sure
that all DMA memory is located within the first 32 bits of address
space.
Signed-off-by: Al Cooper <alcooperx(a)gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/mach-bcm/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -199,6 +199,7 @@ config ARCH_BRCMSTB
select BRCMSTB_L2_IRQ
select BCM7120_L2_IRQ
select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
+ select ZONE_DMA if ARM_LPAE
select SOC_BRCMSTB
select SOC_BUS
help
Patches currently in stable-queue which might be from alcooperx(a)gmail.com are
queue-4.9/arm-brcmstb-enable-zone_dma-for-non-64-bit-capable-peripherals.patch
This is a note to let you know that I've just added the patch titled
ARM: bcm2835: Enable missing CMA settings for VC4 driver
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-bcm2835-enable-missing-cma-settings-for-vc4-driver.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Stefan Wahren <stefan.wahren(a)i2se.com>
Date: Sat, 4 Mar 2017 09:43:51 +0000
Subject: ARM: bcm2835: Enable missing CMA settings for VC4 driver
From: Stefan Wahren <stefan.wahren(a)i2se.com>
[ Upstream commit bdd3c25423cb42171446940bca0946e0443e1a84 ]
Currently bcm2835_defconfig has CMA disabled which makes the
HDMI output on a Raspberry Pi 1 stop working during boot:
fb: switching to vc4drmfb from simple
Console: switching to colour dummy device 80x30
[drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
vc4-drm soc:gpu: failed to allocate buffer with size 9216000
vc4-drm soc:gpu: Failed to set initial hw configuration.
So enable CMA and DMA_CMA in bcm2835_defconfig.
Signed-off-by: Stefan Wahren <stefan.wahren(a)i2se.com>
Fixes: 4400d9ac05ee ("ARM: bcm2835: Enable the VC4 graphics driver in the defconfig")
Reviewed-by: Eric Anholt <eric(a)anholt.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/configs/bcm2835_defconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/configs/bcm2835_defconfig
+++ b/arch/arm/configs/bcm2835_defconfig
@@ -1,6 +1,5 @@
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SYSVIPC=y
-CONFIG_FHANDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BSD_PROCESS_ACCT=y
@@ -32,6 +31,7 @@ CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_AEABI=y
CONFIG_KSM=y
CONFIG_CLEANCACHE=y
+CONFIG_CMA=y
CONFIG_SECCOMP=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
@@ -52,6 +52,7 @@ CONFIG_MAC80211=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
# CONFIG_STANDALONE is not set
+CONFIG_DMA_CMA=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SCSI_CONSTANTS=y
@@ -62,7 +63,6 @@ CONFIG_USB_NET_SMSC95XX=y
CONFIG_ZD1211RW=y
CONFIG_INPUT_EVDEV=y
# CONFIG_LEGACY_PTYS is not set
-# CONFIG_DEVKMEM is not set
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
CONFIG_TTY_PRINTK=y
Patches currently in stable-queue which might be from stefan.wahren(a)i2se.com are
queue-4.9/arm-bcm2835-enable-missing-cma-settings-for-vc4-driver.patch
This is a note to let you know that I've just added the patch titled
ALSA: hda: Add Geminilake id to SKL_PLUS
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-hda-add-geminilake-id-to-skl_plus.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: "Subhransu S. Prusty" <subhransu.s.prusty(a)intel.com>
Date: Wed, 12 Apr 2017 09:54:00 +0530
Subject: ALSA: hda: Add Geminilake id to SKL_PLUS
From: "Subhransu S. Prusty" <subhransu.s.prusty(a)intel.com>
[ Upstream commit 12ee4022f67f8854061b46e5c0a7ad6258ab66c2 ]
Geminilake is Skylake family platform. So add it's id to skl_plus check.
Fixes: 126cfa2f5e15 ("ALSA: hda: Add Geminilake HDMI codec ID")
Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty(a)intel.com>
Cc: Senthilnathan Veppur <senthilnathanx.veppur(a)intel.com>
Cc: Vinod Koul <vinod.koul(a)intel.com>
Cc: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/pci/hda/hda_intel.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -369,8 +369,10 @@ enum {
#define IS_KBL_LP(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x9d71)
#define IS_KBL_H(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0xa2f0)
#define IS_BXT(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x5a98)
+#define IS_GLK(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x3198)
#define IS_SKL_PLUS(pci) (IS_SKL(pci) || IS_SKL_LP(pci) || IS_BXT(pci)) || \
- IS_KBL(pci) || IS_KBL_LP(pci) || IS_KBL_H(pci)
+ IS_KBL(pci) || IS_KBL_LP(pci) || IS_KBL_H(pci) || \
+ IS_GLK(pci)
static char *driver_short_names[] = {
[AZX_DRIVER_ICH] = "HDA Intel",
Patches currently in stable-queue which might be from subhransu.s.prusty(a)intel.com are
queue-4.9/alsa-hda-add-geminilake-id-to-skl_plus.patch
This is a note to let you know that I've just added the patch titled
ALSA: firewire-lib: add a quirk of packet without valid EOH in CIP format
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-firewire-lib-add-a-quirk-of-packet-without-valid-eoh-in-cip-format.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Takashi Sakamoto <o-takashi(a)sakamocchi.jp>
Date: Wed, 22 Mar 2017 21:30:27 +0900
Subject: ALSA: firewire-lib: add a quirk of packet without valid EOH in CIP format
From: Takashi Sakamoto <o-takashi(a)sakamocchi.jp>
[ Upstream commit 2128f78f75a36a34dfef0e127273c2f820c5c904 ]
In IEC 61883-1, when two quadlets CIP header is used, the most significant
bit in second CIP header stands. However, packets from units with MOTU
protocol version 3 have a quirk without this flag. Current packet streaming
layer handles this as protocol error.
This commit adds a new enumeration constant for this quirk, to handle MOTU
protocol version 3.
Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/firewire/amdtp-stream.c | 5 +++--
sound/firewire/amdtp-stream.h | 3 +++
2 files changed, 6 insertions(+), 2 deletions(-)
--- a/sound/firewire/amdtp-stream.c
+++ b/sound/firewire/amdtp-stream.c
@@ -471,8 +471,9 @@ static int handle_in_packet(struct amdtp
* This module supports 'Two-quadlet CIP header with SYT field'.
* For convenience, also check FMT field is AM824 or not.
*/
- if (((cip_header[0] & CIP_EOH_MASK) == CIP_EOH) ||
- ((cip_header[1] & CIP_EOH_MASK) != CIP_EOH)) {
+ if ((((cip_header[0] & CIP_EOH_MASK) == CIP_EOH) ||
+ ((cip_header[1] & CIP_EOH_MASK) != CIP_EOH)) &&
+ (!(s->flags & CIP_HEADER_WITHOUT_EOH))) {
dev_info_ratelimited(&s->unit->device,
"Invalid CIP header for AMDTP: %08X:%08X\n",
cip_header[0], cip_header[1]);
--- a/sound/firewire/amdtp-stream.h
+++ b/sound/firewire/amdtp-stream.h
@@ -29,6 +29,8 @@
* @CIP_JUMBO_PAYLOAD: Only for in-stream. The number of data blocks in an
* packet is larger than IEC 61883-6 defines. Current implementation
* allows 5 times as large as IEC 61883-6 defines.
+ * @CIP_HEADER_WITHOUT_EOH: Only for in-stream. CIP Header doesn't include
+ * valid EOH.
*/
enum cip_flags {
CIP_NONBLOCKING = 0x00,
@@ -39,6 +41,7 @@ enum cip_flags {
CIP_SKIP_DBC_ZERO_CHECK = 0x10,
CIP_EMPTY_HAS_WRONG_DBC = 0x20,
CIP_JUMBO_PAYLOAD = 0x40,
+ CIP_HEADER_WITHOUT_EOH = 0x80,
};
/**
Patches currently in stable-queue which might be from o-takashi(a)sakamocchi.jp are
queue-4.9/alsa-firewire-digi00x-handle-all-midi-messages-on-streaming-packets.patch
queue-4.9/alsa-firewire-digi00x-add-support-for-console-models-of-digi00x-series.patch
queue-4.9/alsa-firewire-lib-add-a-quirk-of-packet-without-valid-eoh-in-cip-format.patch
This is a note to let you know that I've just added the patch titled
ALSA: firewire-digi00x: handle all MIDI messages on streaming packets
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-firewire-digi00x-handle-all-midi-messages-on-streaming-packets.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Takashi Sakamoto <o-takashi(a)sakamocchi.jp>
Date: Sun, 2 Apr 2017 23:48:25 +0900
Subject: ALSA: firewire-digi00x: handle all MIDI messages on streaming packets
From: Takashi Sakamoto <o-takashi(a)sakamocchi.jp>
[ Upstream commit 8820a4cf0cb4cd5c6540a9a18b2cedbdfd5a6891 ]
At a commit 9dc5d31cdceb ("ALSA: firewire-digi00x: handle MIDI messages in
isochronous packets"), a functionality to handle MIDI messages on
isochronous packet was supported. But this includes some of my
misunderstanding. This commit is to fix them.
For digi00x series, first data channel of data blocks in rx/tx packet
includes MIDI messages. The data channel has 0x80 in 8 bit of its MSB,
however it's against IEC 61883-6. Unique data format is applied:
- Upper 4 bits of LSB represent port number.
- 0x0: port 1.
- 0x2: port 2.
- 0xe: console port.
- Lower 4 bits of LSB represent the number of included MIDI message bytes;
0x0/0x1/0x2.
- Two bytes of middle of this data channel have MIDI bytes.
Especially, MIDI messages from/to console surface are also transferred by
isochronous packets, as well as physical MIDI ports.
Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/firewire/digi00x/amdtp-dot.c | 53 +++++++++++++++++++++++++------------
1 file changed, 36 insertions(+), 17 deletions(-)
--- a/sound/firewire/digi00x/amdtp-dot.c
+++ b/sound/firewire/digi00x/amdtp-dot.c
@@ -28,6 +28,9 @@
*/
#define MAX_MIDI_RX_BLOCKS 8
+/* 3 = MAX(DOT_MIDI_IN_PORTS, DOT_MIDI_OUT_PORTS) + 1. */
+#define MAX_MIDI_PORTS 3
+
/*
* The double-oh-three algorithm was discovered by Robin Gareus and Damien
* Zammit in 2012, with reverse-engineering for Digi 003 Rack.
@@ -42,10 +45,8 @@ struct amdtp_dot {
unsigned int pcm_channels;
struct dot_state state;
- unsigned int midi_ports;
- /* 2 = MAX(DOT_MIDI_IN_PORTS, DOT_MIDI_OUT_PORTS) */
- struct snd_rawmidi_substream *midi[2];
- int midi_fifo_used[2];
+ struct snd_rawmidi_substream *midi[MAX_MIDI_PORTS];
+ int midi_fifo_used[MAX_MIDI_PORTS];
int midi_fifo_limit;
void (*transfer_samples)(struct amdtp_stream *s,
@@ -124,8 +125,8 @@ int amdtp_dot_set_parameters(struct amdt
return -EBUSY;
/*
- * A first data channel is for MIDI conformant data channel, the rest is
- * Multi Bit Linear Audio data channel.
+ * A first data channel is for MIDI messages, the rest is Multi Bit
+ * Linear Audio data channel.
*/
err = amdtp_stream_set_parameters(s, rate, pcm_channels + 1);
if (err < 0)
@@ -135,11 +136,6 @@ int amdtp_dot_set_parameters(struct amdt
p->pcm_channels = pcm_channels;
- if (s->direction == AMDTP_IN_STREAM)
- p->midi_ports = DOT_MIDI_IN_PORTS;
- else
- p->midi_ports = DOT_MIDI_OUT_PORTS;
-
/*
* We do not know the actual MIDI FIFO size of most devices. Just
* assume two bytes, i.e., one byte can be received over the bus while
@@ -281,13 +277,25 @@ static void write_midi_messages(struct a
b = (u8 *)&buffer[0];
len = 0;
- if (port < p->midi_ports &&
+ if (port < MAX_MIDI_PORTS &&
midi_ratelimit_per_packet(s, port) &&
p->midi[port] != NULL)
len = snd_rawmidi_transmit(p->midi[port], b + 1, 2);
if (len > 0) {
- b[3] = (0x10 << port) | len;
+ /*
+ * Upper 4 bits of LSB represent port number.
+ * - 0000b: physical MIDI port 1.
+ * - 0010b: physical MIDI port 2.
+ * - 1110b: console MIDI port.
+ */
+ if (port == 2)
+ b[3] = 0xe0;
+ else if (port == 1)
+ b[3] = 0x20;
+ else
+ b[3] = 0x00;
+ b[3] |= len;
midi_use_bytes(s, port, len);
} else {
b[1] = 0;
@@ -309,11 +317,22 @@ static void read_midi_messages(struct am
for (f = 0; f < data_blocks; f++) {
b = (u8 *)&buffer[0];
- port = b[3] >> 4;
+
len = b[3] & 0x0f;
+ if (len > 0) {
+ /*
+ * Upper 4 bits of LSB represent port number.
+ * - 0000b: physical MIDI port 1. Use port 0.
+ * - 1110b: console MIDI port. Use port 2.
+ */
+ if (b[3] >> 4 > 0)
+ port = 2;
+ else
+ port = 0;
- if (port < p->midi_ports && p->midi[port] && len > 0)
- snd_rawmidi_receive(p->midi[port], b + 1, len);
+ if (port < MAX_MIDI_PORTS && p->midi[port])
+ snd_rawmidi_receive(p->midi[port], b + 1, len);
+ }
buffer += s->data_block_quadlets;
}
@@ -364,7 +383,7 @@ void amdtp_dot_midi_trigger(struct amdtp
{
struct amdtp_dot *p = s->protocol;
- if (port < p->midi_ports)
+ if (port < MAX_MIDI_PORTS)
ACCESS_ONCE(p->midi[port]) = midi;
}
Patches currently in stable-queue which might be from o-takashi(a)sakamocchi.jp are
queue-4.9/alsa-firewire-digi00x-handle-all-midi-messages-on-streaming-packets.patch
queue-4.9/alsa-firewire-digi00x-add-support-for-console-models-of-digi00x-series.patch
queue-4.9/alsa-firewire-lib-add-a-quirk-of-packet-without-valid-eoh-in-cip-format.patch
This is a note to let you know that I've just added the patch titled
ALSA: firewire-digi00x: add support for console models of Digi00x series
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-firewire-digi00x-add-support-for-console-models-of-digi00x-series.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Takashi Sakamoto <o-takashi(a)sakamocchi.jp>
Date: Sun, 2 Apr 2017 23:48:24 +0900
Subject: ALSA: firewire-digi00x: add support for console models of Digi00x series
From: Takashi Sakamoto <o-takashi(a)sakamocchi.jp>
[ Upstream commit 13e005f9f933a35b5e55c9d36f151efe2a8383ec ]
Digi00x series includes two types of unit; rack and console. As long as
reading information on config rom of Digi 002 console, 'MODEL_ID' field
has a different value from the one on Digi 002 rack.
We've already got a test report from users with Digi 003 rack. We can
assume that console type and rack type has different value in the field.
This commit adds a device entry for console type. For following commits,
this commit also adds a member to 'struct snd_digi00x' to identify console
type.
$ cd linux-firewire-utils/src
$ python2 ./crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 0404f9d0 bus_info_length 4, crc_length 4, crc 63952
404 31333934 bus_name "1394"
408 60647002 irmc 0, cmc 1, isc 1, bmc 0, cyc_clk_acc 100, max_rec 7 (256)
40c 00a07e00 company_id 00a07e |
410 00a30000 device_id 0000a30000 | EUI-64 00a07e0000a30000
root directory
-----------------------------------------------------------------
414 00058a39 directory_length 5, crc 35385
418 0c0043a0 node capabilities
41c 04000001 hardware version
420 0300a07e vendor
424 81000007 --> descriptor leaf at 440
428 d1000001 --> unit directory at 42c
unit directory at 42c
-----------------------------------------------------------------
42c 00046674 directory_length 4, crc 26228
430 120000a3 specifier id
434 13000001 version
438 17000001 model
43c 81000007 --> descriptor leaf at 458
descriptor leaf at 440
-----------------------------------------------------------------
440 00055913 leaf_length 5, crc 22803
444 000050f2 descriptor_type 00, specifier_ID 50f2
448 80000000
44c 44696769
450 64657369
454 676e0000
descriptor leaf at 458
-----------------------------------------------------------------
458 0004a6fd leaf_length 4, crc 42749
45c 00000000 textual descriptor
460 00000000 minimal ASCII
464 44696769 "Digi"
468 20303032 " 002"
Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/firewire/digi00x/digi00x.c | 13 +++++++++++--
sound/firewire/digi00x/digi00x.h | 1 +
2 files changed, 12 insertions(+), 2 deletions(-)
--- a/sound/firewire/digi00x/digi00x.c
+++ b/sound/firewire/digi00x/digi00x.c
@@ -13,7 +13,8 @@ MODULE_AUTHOR("Takashi Sakamoto <o-takas
MODULE_LICENSE("GPL v2");
#define VENDOR_DIGIDESIGN 0x00a07e
-#define MODEL_DIGI00X 0x000002
+#define MODEL_CONSOLE 0x000001
+#define MODEL_RACK 0x000002
static int name_card(struct snd_dg00x *dg00x)
{
@@ -129,6 +130,8 @@ static int snd_dg00x_probe(struct fw_uni
spin_lock_init(&dg00x->lock);
init_waitqueue_head(&dg00x->hwdep_wait);
+ dg00x->is_console = entry->model_id == MODEL_CONSOLE;
+
/* Allocate and register this sound card later. */
INIT_DEFERRABLE_WORK(&dg00x->dwork, do_registration);
snd_fw_schedule_registration(unit, &dg00x->dwork);
@@ -183,7 +186,13 @@ static const struct ieee1394_device_id s
.match_flags = IEEE1394_MATCH_VENDOR_ID |
IEEE1394_MATCH_MODEL_ID,
.vendor_id = VENDOR_DIGIDESIGN,
- .model_id = MODEL_DIGI00X,
+ .model_id = MODEL_CONSOLE,
+ },
+ {
+ .match_flags = IEEE1394_MATCH_VENDOR_ID |
+ IEEE1394_MATCH_MODEL_ID,
+ .vendor_id = VENDOR_DIGIDESIGN,
+ .model_id = MODEL_RACK,
},
{}
};
--- a/sound/firewire/digi00x/digi00x.h
+++ b/sound/firewire/digi00x/digi00x.h
@@ -60,6 +60,7 @@ struct snd_dg00x {
/* For asynchronous MIDI controls. */
struct snd_rawmidi_substream *in_control;
struct snd_fw_async_midi_port out_control;
+ bool is_console;
};
#define DG00X_ADDR_BASE 0xffffe0000000ull
Patches currently in stable-queue which might be from o-takashi(a)sakamocchi.jp are
queue-4.9/alsa-firewire-digi00x-handle-all-midi-messages-on-streaming-packets.patch
queue-4.9/alsa-firewire-digi00x-add-support-for-console-models-of-digi00x-series.patch
queue-4.9/alsa-firewire-lib-add-a-quirk-of-packet-without-valid-eoh-in-cip-format.patch
This is a note to let you know that I've just added the patch titled
agp/intel: Flush all chipset writes after updating the GGTT
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
agp-intel-flush-all-chipset-writes-after-updating-the-ggtt.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Chris Wilson <chris(a)chris-wilson.co.uk>
Date: Fri, 8 Dec 2017 21:46:16 +0000
Subject: agp/intel: Flush all chipset writes after updating the GGTT
From: Chris Wilson <chris(a)chris-wilson.co.uk>
[ Upstream commit 8516673a996870ea0ceb337ee4f83c33c5ec3111 ]
Before accessing the GGTT we must flush the PTE writes and make them
visible to the chipset, or else the indirect access may end up in the
wrong page. In commit 3497971a71d8 ("agp/intel: Flush chipset writes
after updating a single PTE"), we noticed corruption of the uploads for
pwrite and for capturing GPU error states, but it was presumed that the
explicit calls to intel_gtt_chipset_flush() were sufficient for the
execbuffer path. However, we have not been flushing the chipset between
the PTE writes and access via the GTT itself.
For simplicity, do the flush after any PTE update rather than try and
batch the flushes on a just-in-time basis.
References: 3497971a71d8 ("agp/intel: Flush chipset writes after updating a single PTE")
Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com>
Cc: Mika Kuoppala <mika.kuoppala(a)intel.com>
Cc: drm-intel-fixes(a)lists.freedesktop.org
Reviewed-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171208214616.30147-1-chris@…
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/char/agp/intel-gtt.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -871,6 +871,8 @@ void intel_gtt_insert_sg_entries(struct
}
}
wmb();
+ if (intel_private.driver->chipset_flush)
+ intel_private.driver->chipset_flush();
}
EXPORT_SYMBOL(intel_gtt_insert_sg_entries);
Patches currently in stable-queue which might be from chris(a)chris-wilson.co.uk are
queue-4.9/drm-defer-disabling-the-vblank-irq-until-the-next-interrupt-for-instant-off.patch
queue-4.9/agp-intel-flush-all-chipset-writes-after-updating-the-ggtt.patch
This is a note to let you know that I've just added the patch titled
blkcg: fix double free of new_blkg in blkcg_init_queue
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
blkcg-fix-double-free-of-new_blkg-in-blkcg_init_queue.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 9b54d816e00425c3a517514e0d677bb3cec49258 Mon Sep 17 00:00:00 2001
From: Hou Tao <houtao1(a)huawei.com>
Date: Fri, 3 Feb 2017 17:19:07 +0800
Subject: blkcg: fix double free of new_blkg in blkcg_init_queue
From: Hou Tao <houtao1(a)huawei.com>
commit 9b54d816e00425c3a517514e0d677bb3cec49258 upstream.
If blkg_create fails, new_blkg passed as an argument will
be freed by blkg_create, so there is no need to free it again.
Signed-off-by: Hou Tao <houtao1(a)huawei.com>
Signed-off-by: Jens Axboe <axboe(a)fb.com>
Cc: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/blk-cgroup.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -1078,10 +1078,8 @@ int blkcg_init_queue(struct request_queu
if (preloaded)
radix_tree_preload_end();
- if (IS_ERR(blkg)) {
- blkg_free(new_blkg);
+ if (IS_ERR(blkg))
return PTR_ERR(blkg);
- }
q->root_blkg = blkg;
q->root_rl.blkg = blkg;
Patches currently in stable-queue which might be from houtao1(a)huawei.com are
queue-4.9/blkcg-fix-double-free-of-new_blkg-in-blkcg_init_queue.patch
This is a note to let you know that I've just added the patch titled
blkcg: fix double free of new_blkg in blkcg_init_queue
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
blkcg-fix-double-free-of-new_blkg-in-blkcg_init_queue.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 9b54d816e00425c3a517514e0d677bb3cec49258 Mon Sep 17 00:00:00 2001
From: Hou Tao <houtao1(a)huawei.com>
Date: Fri, 3 Feb 2017 17:19:07 +0800
Subject: blkcg: fix double free of new_blkg in blkcg_init_queue
From: Hou Tao <houtao1(a)huawei.com>
commit 9b54d816e00425c3a517514e0d677bb3cec49258 upstream.
If blkg_create fails, new_blkg passed as an argument will
be freed by blkg_create, so there is no need to free it again.
Signed-off-by: Hou Tao <houtao1(a)huawei.com>
Signed-off-by: Jens Axboe <axboe(a)fb.com>
Cc: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/blk-cgroup.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -1078,10 +1078,8 @@ int blkcg_init_queue(struct request_queu
if (preloaded)
radix_tree_preload_end();
- if (IS_ERR(blkg)) {
- blkg_free(new_blkg);
+ if (IS_ERR(blkg))
return PTR_ERR(blkg);
- }
q->root_blkg = blkg;
q->root_rl.blkg = blkg;
Patches currently in stable-queue which might be from houtao1(a)huawei.com are
queue-4.4/blkcg-fix-double-free-of-new_blkg-in-blkcg_init_queue.patch
This is a note to let you know that I've just added the patch titled
dmaengine: virt-dma: Support for race free transfer termination
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-virt-dma-support-for-race-free-transfer-termination.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 1c7f072d94e8b697fd9b70cdb268622a18faf522 Mon Sep 17 00:00:00 2001
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Date: Tue, 14 Nov 2017 16:32:04 +0200
Subject: dmaengine: virt-dma: Support for race free transfer termination
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
commit 1c7f072d94e8b697fd9b70cdb268622a18faf522 upstream.
Even with the introduced vchan_synchronize() we can face race when
terminating a cyclic transfer.
If the terminate_all is called after the interrupt handler called
vchan_cyclic_callback(), but before the vchan_complete tasklet is called:
vc->cyclic is set to the cyclic descriptor, but the descriptor itself was
freed up in the driver's terminate_all() callback.
When the vhan_complete() is executed it will try to fetch the vc->cyclic
vdesc, but the pointer is pointing now to uninitialized memory leading to
(hard to reproduce) kernel crash.
In order to fix this, drivers should:
- call vchan_terminate_vdesc() from their terminate_all callback instead
calling their free_desc function to free up the descriptor.
- implement device_synchronize callback and call vchan_synchronize().
This way we can make sure that the descriptor is only going to be freed up
after the vchan_callback was executed in a safe manner.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/virt-dma.h | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
--- a/drivers/dma/virt-dma.h
+++ b/drivers/dma/virt-dma.h
@@ -35,6 +35,7 @@ struct virt_dma_chan {
struct list_head desc_completed;
struct virt_dma_desc *cyclic;
+ struct virt_dma_desc *vd_terminated;
};
static inline struct virt_dma_chan *to_virt_chan(struct dma_chan *chan)
@@ -116,6 +117,25 @@ static inline void vchan_cyclic_callback
}
/**
+ * vchan_terminate_vdesc - Disable pending cyclic callback
+ * @vd: virtual descriptor to be terminated
+ *
+ * vc.lock must be held by caller
+ */
+static inline void vchan_terminate_vdesc(struct virt_dma_desc *vd)
+{
+ struct virt_dma_chan *vc = to_virt_chan(vd->tx.chan);
+
+ /* free up stuck descriptor */
+ if (vc->vd_terminated)
+ vchan_vdesc_fini(vc->vd_terminated);
+
+ vc->vd_terminated = vd;
+ if (vc->cyclic == vd)
+ vc->cyclic = NULL;
+}
+
+/**
* vchan_next_desc - peek at the next descriptor to be processed
* @vc: virtual channel to obtain descriptor from
*
@@ -168,10 +188,20 @@ static inline void vchan_free_chan_resou
* Makes sure that all scheduled or active callbacks have finished running. For
* proper operation the caller has to ensure that no new callbacks are scheduled
* after the invocation of this function started.
+ * Free up the terminated cyclic descriptor to prevent memory leakage.
*/
static inline void vchan_synchronize(struct virt_dma_chan *vc)
{
+ unsigned long flags;
+
tasklet_kill(&vc->task);
+
+ spin_lock_irqsave(&vc->lock, flags);
+ if (vc->vd_terminated) {
+ vchan_vdesc_fini(vc->vd_terminated);
+ vc->vd_terminated = NULL;
+ }
+ spin_unlock_irqrestore(&vc->lock, flags);
}
#endif
Patches currently in stable-queue which might be from peter.ujfalusi(a)ti.com are
queue-4.15/dmaengine-bcm2835-dma-use-vchan_terminate_vdesc-instead-of-desc_free.patch
queue-4.15/dmaengine-virt-dma-support-for-race-free-transfer-termination.patch
queue-4.15/dmaengine-amba-pl08x-use-vchan_terminate_vdesc-instead-of-desc_free.patch
This is a note to let you know that I've just added the patch titled
dmaengine: virt-dma: Support for race free transfer termination
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-virt-dma-support-for-race-free-transfer-termination.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 1c7f072d94e8b697fd9b70cdb268622a18faf522 Mon Sep 17 00:00:00 2001
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Date: Tue, 14 Nov 2017 16:32:04 +0200
Subject: dmaengine: virt-dma: Support for race free transfer termination
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
commit 1c7f072d94e8b697fd9b70cdb268622a18faf522 upstream.
Even with the introduced vchan_synchronize() we can face race when
terminating a cyclic transfer.
If the terminate_all is called after the interrupt handler called
vchan_cyclic_callback(), but before the vchan_complete tasklet is called:
vc->cyclic is set to the cyclic descriptor, but the descriptor itself was
freed up in the driver's terminate_all() callback.
When the vhan_complete() is executed it will try to fetch the vc->cyclic
vdesc, but the pointer is pointing now to uninitialized memory leading to
(hard to reproduce) kernel crash.
In order to fix this, drivers should:
- call vchan_terminate_vdesc() from their terminate_all callback instead
calling their free_desc function to free up the descriptor.
- implement device_synchronize callback and call vchan_synchronize().
This way we can make sure that the descriptor is only going to be freed up
after the vchan_callback was executed in a safe manner.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/virt-dma.h | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
--- a/drivers/dma/virt-dma.h
+++ b/drivers/dma/virt-dma.h
@@ -35,6 +35,7 @@ struct virt_dma_chan {
struct list_head desc_completed;
struct virt_dma_desc *cyclic;
+ struct virt_dma_desc *vd_terminated;
};
static inline struct virt_dma_chan *to_virt_chan(struct dma_chan *chan)
@@ -116,6 +117,25 @@ static inline void vchan_cyclic_callback
}
/**
+ * vchan_terminate_vdesc - Disable pending cyclic callback
+ * @vd: virtual descriptor to be terminated
+ *
+ * vc.lock must be held by caller
+ */
+static inline void vchan_terminate_vdesc(struct virt_dma_desc *vd)
+{
+ struct virt_dma_chan *vc = to_virt_chan(vd->tx.chan);
+
+ /* free up stuck descriptor */
+ if (vc->vd_terminated)
+ vchan_vdesc_fini(vc->vd_terminated);
+
+ vc->vd_terminated = vd;
+ if (vc->cyclic == vd)
+ vc->cyclic = NULL;
+}
+
+/**
* vchan_next_desc - peek at the next descriptor to be processed
* @vc: virtual channel to obtain descriptor from
*
@@ -168,10 +188,20 @@ static inline void vchan_free_chan_resou
* Makes sure that all scheduled or active callbacks have finished running. For
* proper operation the caller has to ensure that no new callbacks are scheduled
* after the invocation of this function started.
+ * Free up the terminated cyclic descriptor to prevent memory leakage.
*/
static inline void vchan_synchronize(struct virt_dma_chan *vc)
{
+ unsigned long flags;
+
tasklet_kill(&vc->task);
+
+ spin_lock_irqsave(&vc->lock, flags);
+ if (vc->vd_terminated) {
+ vchan_vdesc_fini(vc->vd_terminated);
+ vc->vd_terminated = NULL;
+ }
+ spin_unlock_irqrestore(&vc->lock, flags);
}
#endif
Patches currently in stable-queue which might be from peter.ujfalusi(a)ti.com are
queue-4.14/dmaengine-bcm2835-dma-use-vchan_terminate_vdesc-instead-of-desc_free.patch
queue-4.14/dmaengine-virt-dma-support-for-race-free-transfer-termination.patch
queue-4.14/dmaengine-amba-pl08x-use-vchan_terminate_vdesc-instead-of-desc_free.patch
On Fri, Mar 16, 2018 at 07:21:53PM +0000, Harsh Shandilya wrote:
> On Fri, 16 Mar, 2018, 8:53 PM Greg Kroah-Hartman, <
> gregkh(a)linuxfoundation.org> wrote:
>
> > This is the start of the stable review cycle for the 3.18.100 release.
> > There are 25 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun Mar 18 15:22:18 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> >
> > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.100-r…
> > or in the git tree and branch at:
> > git://
> > git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > linux-3.18.y
> > and the diffstat can be found below.
> >
>
> Builds and boots on the OnePlus 3T, no immediate issues noticed. Thanks for
> the update.
Thanks for testing and letting me know.
greg k-h
glibc keeps getting cleverer, and my version now turns raise() into
more than one syscall. Since the test relies on ptrace seeing an
exact set of syscalls, this breaks the test. Replace raise(SIGSTOP)
with syscall(SYS_tgkill, ...) to force glibc to get out of our way.
Cc: stable(a)vger.kernel.org
Signed-off-by: Andy Lutomirski <luto(a)kernel.org>
---
tools/testing/selftests/x86/ptrace_syscall.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/x86/ptrace_syscall.c b/tools/testing/selftests/x86/ptrace_syscall.c
index 1ae1c5a7392e..6f22238f3217 100644
--- a/tools/testing/selftests/x86/ptrace_syscall.c
+++ b/tools/testing/selftests/x86/ptrace_syscall.c
@@ -183,8 +183,10 @@ static void test_ptrace_syscall_restart(void)
if (ptrace(PTRACE_TRACEME, 0, 0, 0) != 0)
err(1, "PTRACE_TRACEME");
+ pid_t pid = getpid(), tid = syscall(SYS_gettid);
+
printf("\tChild will make one syscall\n");
- raise(SIGSTOP);
+ syscall(SYS_tgkill, pid, tid, SIGSTOP);
syscall(SYS_gettid, 10, 11, 12, 13, 14, 15);
_exit(0);
@@ -301,9 +303,11 @@ static void test_restart_under_ptrace(void)
if (ptrace(PTRACE_TRACEME, 0, 0, 0) != 0)
err(1, "PTRACE_TRACEME");
+ pid_t pid = getpid(), tid = syscall(SYS_gettid);
+
printf("\tChild will take a nap until signaled\n");
setsigign(SIGUSR1, SA_RESTART);
- raise(SIGSTOP);
+ syscall(SYS_tgkill, pid, tid, SIGSTOP);
syscall(SYS_pause, 0, 0, 0, 0, 0, 0);
_exit(0);
--
2.14.3
This is the start of the stable review cycle for the 3.18.100 release.
There are 25 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun Mar 18 15:22:18 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.100-r…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-3.18.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 3.18.100-rc1
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
fixup: sctp: verify size of a new chunk in _sctp_make_chunk()
Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
serial: 8250_pci: Add Brainboxes UC-260 4 port serial device
Pete Zaitcev <zaitcev(a)kotori.zaitcev.us>
usb: usbmon: Read text within supplied buffer size
Julia Lawall <Julia.Lawall(a)lip6.fr>
USB: usbmon: remove assignment from IS_ERR argument
Danilo Krummrich <danilokrummrich(a)dk-develop.de>
usb: quirks: add control message delay for 1b1c:1b20
Joel Fernandes <joelaf(a)google.com>
staging: android: ashmem: Fix lockdep issue during llseek
Oliver Neukum <oneukum(a)suse.com>
uas: fix comparison for error code
Jonas Danielsson <jonas(a)orbital-systems.com>
tty/serial: atmel: add new version check for usart
Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com>
serial: sh-sci: prevent lockup on full TTY buffers
H.J. Lu <hjl.tools(a)gmail.com>
x86: Treat R_X86_64_PLT32 as R_X86_64_PC32
Josh Poimboeuf <jpoimboe(a)redhat.com>
x86/module: Detect and skip invalid relocations
Russell King <rmk+kernel(a)arm.linux.org.uk>
scripts: recordmcount: break hardlinks
Clay McClure <clay(a)daemons.net>
ubi: Fix race condition between ubi volume creation and udev
Florian Westphal <fw(a)strlen.de>
netfilter: ipv6: fix use-after-free Write in nf_nat_ipv6_manip_pkt
Florian Westphal <fw(a)strlen.de>
netfilter: bridge: ebt_among: add missing match size checks
Florian Westphal <fw(a)strlen.de>
netfilter: ebtables: CONFIG_COMPAT: don't trust userland offsets
Eric Dumazet <edumazet(a)google.com>
netfilter: IDLETIMER: be syzkaller friendly
Paolo Abeni <pabeni(a)redhat.com>
netfilter: nat: cope with negative port range
Paolo Abeni <pabeni(a)redhat.com>
netfilter: x_tables: fix missing timer initialization in xt_LED
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: More protection for concurrent write and ioctl races
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: Don't allow resizing pool in use
Seunghun Han <kkamagui(a)gmail.com>
x86/MCE: Serialize sysfs changes
Zhang Bo <zbsdta(a)126.com>
Input: matrix_keypad - fix race when disabling interrupts
Justin Chen <justinpopo6(a)gmail.com>
MIPS: BMIPS: Do not mask IPIs during suspend
himanshu.madhani(a)cavium.com <himanshu.madhani(a)cavium.com>
scsi: qla2xxx: Fix NULL pointer crash due to active timer for ABTS
-------------
Diffstat:
Makefile | 4 +-
arch/mips/kernel/smp-bmips.c | 8 +-
arch/x86/kernel/cpu/mcheck/mce.c | 22 +++++-
arch/x86/kernel/machine_kexec_64.c | 1 +
arch/x86/kernel/module.c | 14 ++++
arch/x86/tools/relocs.c | 3 +
drivers/input/keyboard/matrix_keypad.c | 4 +-
drivers/mtd/ubi/vmt.c | 15 ++--
drivers/scsi/qla2xxx/qla_init.c | 1 +
drivers/staging/android/ashmem.c | 15 ++--
drivers/tty/serial/8250/8250_pci.c | 11 +++
drivers/tty/serial/atmel_serial.c | 1 +
drivers/tty/serial/sh-sci.c | 2 +
drivers/usb/core/message.c | 4 +
drivers/usb/core/quirks.c | 3 +-
drivers/usb/mon/mon_text.c | 124 +++++++++++++++++++------------
drivers/usb/storage/uas.c | 2 +-
include/linux/usb/quirks.h | 3 +
net/bridge/netfilter/ebt_among.c | 21 +++++-
net/bridge/netfilter/ebtables.c | 13 +++-
net/ipv6/netfilter/nf_nat_l3proto_ipv6.c | 4 +
net/netfilter/nf_nat_proto_common.c | 7 +-
net/netfilter/xt_IDLETIMER.c | 9 ++-
net/netfilter/xt_LED.c | 12 +--
net/sctp/sm_make_chunk.c | 2 +-
scripts/recordmcount.c | 14 ++++
sound/core/seq/seq_clientmgr.c | 21 ++++--
sound/core/seq/seq_fifo.c | 2 +-
sound/core/seq/seq_memory.c | 14 +++-
sound/core/seq/seq_memory.h | 3 +-
30 files changed, 262 insertions(+), 97 deletions(-)
When we build this driver with on x86-32, gcc produces a false-positive warning:
drivers/clk/renesas/clk-sh73a0.c: In function 'sh73a0_cpg_clocks_init':
drivers/clk/renesas/clk-sh73a0.c:155:10: error: 'parent_name' may be used uninitialized in this function [-Werror=maybe-uninitialized]
return clk_register_fixed_factor(NULL, name, parent_name, 0,
We can work around that warning by adding a fake initialization, I tried
and failed to come up with any better workaround. This is currently one
of few remaining warnings for a 4.14.y randconfig build, so it would be
good to also have it backported at least to that version. Older versions
have more randconfig warnings, so we might not care.
I had not noticed this earlier, because one patch in my randconfig test
tree removes the '-ffreestanding' option on x86-32, and that avoids
the warning. The -ffreestanding flag was originally global but moved
into arch/i386 by Andi Kleen in commit 6edfba1b33c7 ("[PATCH] x86_64:
Don't define string functions to builtin") as a 'temporary workaround'.
Like many temporary hacks, this turned out to be rather long-lived, from
all I can tell we still need a simple fix to asm/string_32.h before it
can be removed, but I'm not sure about how to best do that.
Cc: stable(a)vger.kernel.org
Cc: Andi Kleen <ak(a)linux.intel.com>
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
drivers/clk/renesas/clk-sh73a0.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/renesas/clk-sh73a0.c b/drivers/clk/renesas/clk-sh73a0.c
index eea38f6ea77e..3892346c4fcc 100644
--- a/drivers/clk/renesas/clk-sh73a0.c
+++ b/drivers/clk/renesas/clk-sh73a0.c
@@ -46,7 +46,7 @@ struct div4_clk {
unsigned int shift;
};
-static struct div4_clk div4_clks[] = {
+static const struct div4_clk div4_clks[] = {
{ "zg", "pll0", CPG_FRQCRA, 16 },
{ "m3", "pll1", CPG_FRQCRA, 12 },
{ "b", "pll1", CPG_FRQCRA, 8 },
@@ -79,7 +79,7 @@ sh73a0_cpg_register_clock(struct device_node *np, struct sh73a0_cpg *cpg,
{
const struct clk_div_table *table = NULL;
unsigned int shift, reg, width;
- const char *parent_name;
+ const char *parent_name = NULL;
unsigned int mult = 1;
unsigned int div = 1;
@@ -135,7 +135,7 @@ sh73a0_cpg_register_clock(struct device_node *np, struct sh73a0_cpg *cpg,
shift = 24;
width = 5;
} else {
- struct div4_clk *c;
+ const struct div4_clk *c;
for (c = div4_clks; c->name; c++) {
if (!strcmp(name, c->name)) {
--
2.9.0
The patch titled
Subject: Revert "mm: page_alloc: skip over regions of invalid pfns where possible"
has been added to the -mm tree. Its filename is
revert-mm-page_alloc-skip-over-regions-of-invalid-pfns-where-possible.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/revert-mm-page_alloc-skip-over-reg…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/revert-mm-page_alloc-skip-over-reg…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Daniel Vacek <neelx(a)redhat.com>
Subject: Revert "mm: page_alloc: skip over regions of invalid pfns where possible"
This reverts b92df1de5d289c0b ("mm: page_alloc: skip over regions of
invalid pfns where possible"). The commit is meant to be a boot init
speed up skipping the loop in memmap_init_zone() for invalid pfns. But
given some specific memory mapping on x86_64 (or more generally
theoretically anywhere but on arm with CONFIG_HAVE_ARCH_PFN_VALID) the
implementation also skips valid pfns which is plain wrong and causes
'kernel BUG at mm/page_alloc.c:1389!'
crash> log | grep -e BUG -e RIP -e Call.Trace -e move_freepages_block -e rmqueue -e freelist -A1
kernel BUG at mm/page_alloc.c:1389!
invalid opcode: 0000 [#1] SMP
--
RIP: 0010:[<ffffffff8118833e>] [<ffffffff8118833e>] move_freepages+0x15e/0x160
RSP: 0018:ffff88054d727688 EFLAGS: 00010087
--
Call Trace:
[<ffffffff811883b3>] move_freepages_block+0x73/0x80
[<ffffffff81189e63>] __rmqueue+0x263/0x460
[<ffffffff8118c781>] get_page_from_freelist+0x7e1/0x9e0
[<ffffffff8118caf6>] __alloc_pages_nodemask+0x176/0x420
--
RIP [<ffffffff8118833e>] move_freepages+0x15e/0x160
RSP <ffff88054d727688>
crash> page_init_bug -v | grep RAM
<struct resource 0xffff88067fffd2f8> 1000 - 9bfff System RAM (620.00 KiB)
<struct resource 0xffff88067fffd3a0> 100000 - 430bffff System RAM ( 1.05 GiB = 1071.75 MiB = 1097472.00 KiB)
<struct resource 0xffff88067fffd410> 4b0c8000 - 4bf9cfff System RAM ( 14.83 MiB = 15188.00 KiB)
<struct resource 0xffff88067fffd480> 4bfac000 - 646b1fff System RAM (391.02 MiB = 400408.00 KiB)
<struct resource 0xffff88067fffd560> 7b788000 - 7b7fffff System RAM (480.00 KiB)
<struct resource 0xffff88067fffd640> 100000000 - 67fffffff System RAM ( 22.00 GiB)
crash> page_init_bug | head -6
<struct resource 0xffff88067fffd560> 7b788000 - 7b7fffff System RAM (480.00 KiB)
<struct page 0xffffea0001ede200> 1fffff00000000 0 <struct pglist_data 0xffff88047ffd9000> 1 <struct zone 0xffff88047ffd9800> DMA32 4096 1048575
<struct page 0xffffea0001ede200> 505736 505344 <struct page 0xffffea0001ed8000> 505855 <struct page 0xffffea0001edffc0>
<struct page 0xffffea0001ed8000> 0 0 <struct pglist_data 0xffff88047ffd9000> 0 <struct zone 0xffff88047ffd9000> DMA 1 4095
<struct page 0xffffea0001edffc0> 1fffff00000400 0 <struct pglist_data 0xffff88047ffd9000> 1 <struct zone 0xffff88047ffd9800> DMA32 4096 1048575
BUG, zones differ!
crash> kmem -p 77fff000 78000000 7b5ff000 7b600000 7b787000 7b788000
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffea0001e00000 78000000 0 0 0 0
ffffea0001ed7fc0 7b5ff000 0 0 0 0
ffffea0001ed8000 7b600000 0 0 0 0 <<<<
ffffea0001ede1c0 7b787000 0 0 0 0
ffffea0001ede200 7b788000 0 0 1 1fffff00000000
Link: http://lkml.kernel.org/r/20180316143855.29838-1-neelx@redhat.com
Fixes: b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns where possible")
Signed-off-by: Daniel Vacek <neelx(a)redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Pavel Tatashin <pasha.tatashin(a)oracle.com>
Cc: Paul Burton <paul.burton(a)imgtec.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/linux/memblock.h | 1 -
mm/memblock.c | 28 ----------------------------
mm/page_alloc.c | 11 +----------
3 files changed, 1 insertion(+), 39 deletions(-)
diff -puN include/linux/memblock.h~revert-mm-page_alloc-skip-over-regions-of-invalid-pfns-where-possible include/linux/memblock.h
--- a/include/linux/memblock.h~revert-mm-page_alloc-skip-over-regions-of-invalid-pfns-where-possible
+++ a/include/linux/memblock.h
@@ -187,7 +187,6 @@ int memblock_search_pfn_nid(unsigned lon
unsigned long *end_pfn);
void __next_mem_pfn_range(int *idx, int nid, unsigned long *out_start_pfn,
unsigned long *out_end_pfn, int *out_nid);
-unsigned long memblock_next_valid_pfn(unsigned long pfn, unsigned long max_pfn);
/**
* for_each_mem_pfn_range - early memory pfn range iterator
diff -puN mm/memblock.c~revert-mm-page_alloc-skip-over-regions-of-invalid-pfns-where-possible mm/memblock.c
--- a/mm/memblock.c~revert-mm-page_alloc-skip-over-regions-of-invalid-pfns-where-possible
+++ a/mm/memblock.c
@@ -1101,34 +1101,6 @@ void __init_memblock __next_mem_pfn_rang
*out_nid = r->nid;
}
-unsigned long __init_memblock memblock_next_valid_pfn(unsigned long pfn,
- unsigned long max_pfn)
-{
- struct memblock_type *type = &memblock.memory;
- unsigned int right = type->cnt;
- unsigned int mid, left = 0;
- phys_addr_t addr = PFN_PHYS(++pfn);
-
- do {
- mid = (right + left) / 2;
-
- if (addr < type->regions[mid].base)
- right = mid;
- else if (addr >= (type->regions[mid].base +
- type->regions[mid].size))
- left = mid + 1;
- else {
- /* addr is within the region, so pfn is valid */
- return pfn;
- }
- } while (left < right);
-
- if (right == type->cnt)
- return -1UL;
- else
- return PHYS_PFN(type->regions[right].base);
-}
-
/**
* memblock_set_node - set node ID on memblock regions
* @base: base of area to set node ID for
diff -puN mm/page_alloc.c~revert-mm-page_alloc-skip-over-regions-of-invalid-pfns-where-possible mm/page_alloc.c
--- a/mm/page_alloc.c~revert-mm-page_alloc-skip-over-regions-of-invalid-pfns-where-possible
+++ a/mm/page_alloc.c
@@ -5356,17 +5356,8 @@ void __meminit memmap_init_zone(unsigned
if (context != MEMMAP_EARLY)
goto not_early;
- if (!early_pfn_valid(pfn)) {
-#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
- /*
- * Skip to the pfn preceding the next valid one (or
- * end_pfn), such that we hit a valid pfn (or end_pfn)
- * on our next iteration of the loop.
- */
- pfn = memblock_next_valid_pfn(pfn, end_pfn) - 1;
-#endif
+ if (!early_pfn_valid(pfn))
continue;
- }
if (!early_pfn_in_nid(pfn, nid))
continue;
if (!update_defer_init(pgdat, pfn, end_pfn, &nr_initialised))
_
Patches currently in -mm which might be from neelx(a)redhat.com are
revert-mm-page_alloc-skip-over-regions-of-invalid-pfns-where-possible.patch
The patch titled
Subject: mm/shmem: do not wait for lock_page() in shmem_unused_huge_shrink()
has been added to the -mm tree. Its filename is
mm-shmem-do-not-wait-for-lock_page-in-shmem_unused_huge_shrink.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-shmem-do-not-wait-for-lock_page…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-shmem-do-not-wait-for-lock_page…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com>
Subject: mm/shmem: do not wait for lock_page() in shmem_unused_huge_shrink()
shmem_unused_huge_shrink() gets called from reclaim path. Waiting for
page lock may lead to deadlock there.
There was a bug report that may be attributed to this:
http://lkml.kernel.org/r/alpine.LRH.2.11.1801242349220.30642@mail.ewheeler.…
Replace lock_page() with trylock_page() and skip the page if we failed to
lock it. We will get to the page on the next scan.
We can test for the PageTransHuge() outside the page lock as we only need
protection against splitting the page under us. Holding pin oni the page
is enough for this.
Link: http://lkml.kernel.org/r/20180316210830.43738-1-kirill.shutemov@linux.intel…
Fixes: 779750d20b93 ("shmem: split huge pages beyond i_size under memory pressure")
Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Reported-by: Eric Wheeler <linux-mm(a)lists.ewheeler.net>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
Cc: Hugh Dickins <hughd(a)google.com>
Cc: <stable(a)vger.kernel.org> [4.8+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/shmem.c | 31 ++++++++++++++++++++-----------
1 file changed, 20 insertions(+), 11 deletions(-)
diff -puN mm/shmem.c~mm-shmem-do-not-wait-for-lock_page-in-shmem_unused_huge_shrink mm/shmem.c
--- a/mm/shmem.c~mm-shmem-do-not-wait-for-lock_page-in-shmem_unused_huge_shrink
+++ a/mm/shmem.c
@@ -493,36 +493,45 @@ next:
info = list_entry(pos, struct shmem_inode_info, shrinklist);
inode = &info->vfs_inode;
- if (nr_to_split && split >= nr_to_split) {
- iput(inode);
- continue;
- }
+ if (nr_to_split && split >= nr_to_split)
+ goto leave;
- page = find_lock_page(inode->i_mapping,
+ page = find_get_page(inode->i_mapping,
(inode->i_size & HPAGE_PMD_MASK) >> PAGE_SHIFT);
if (!page)
goto drop;
+ /* No huge page at the end of the file: nothing to split */
if (!PageTransHuge(page)) {
- unlock_page(page);
put_page(page);
goto drop;
}
+ /*
+ * Leave the inode on the list if we failed to lock
+ * the page at this time.
+ *
+ * Waiting for the lock may lead to deadlock in the
+ * reclaim path.
+ */
+ if (!trylock_page(page)) {
+ put_page(page);
+ goto leave;
+ }
+
ret = split_huge_page(page);
unlock_page(page);
put_page(page);
- if (ret) {
- /* split failed: leave it on the list */
- iput(inode);
- continue;
- }
+ /* If split failed leave the inode on the list */
+ if (ret)
+ goto leave;
split++;
drop:
list_del_init(&info->shrinklist);
removed++;
+leave:
iput(inode);
}
_
Patches currently in -mm which might be from kirill.shutemov(a)linux.intel.com are
mm-khugepaged-convert-vm_bug_on-to-collapse-fail.patch
mm-thp-do-not-wait-for-lock_page-in-deferred_split_scan.patch
mm-shmem-do-not-wait-for-lock_page-in-shmem_unused_huge_shrink.patch
The patch titled
Subject: mm/hmm: HMM should have a callback before MM is destroyed
has been added to the -mm tree. Its filename is
mm-hmm-hmm-should-have-a-callback-before-mm-is-destroyed-v2.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-hmm-hmm-should-have-a-callback-…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-hmm-hmm-should-have-a-callback-…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Ralph Campbell <rcampbell(a)nvidia.com>
Subject: mm/hmm: HMM should have a callback before MM is destroyed
hmm_mirror_register() registers a callback for when the CPU pagetable is
modified. Normally, the device driver will call hmm_mirror_unregister()
when the process using the device is finished. However, if the process
exits uncleanly, the struct_mm can be destroyed with no warning to the
device driver.
Link: http://lkml.kernel.org/r/20180316191414.3223-4-jglisse@redhat.com
Signed-off-by: Ralph Campbell <rcampbell(a)nvidia.com>
Signed-off-by: Jérôme Glisse <jglisse(a)redhat.com>
Cc: Evgeny Baskakov <ebaskakov(a)nvidia.com>
Cc: Mark Hairgrove <mhairgrove(a)nvidia.com>
Cc: John Hubbard <jhubbard(a)nvidia.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/linux/hmm.h | 10 ++++++++++
mm/hmm.c | 18 +++++++++++++++++-
2 files changed, 27 insertions(+), 1 deletion(-)
diff -puN include/linux/hmm.h~mm-hmm-hmm-should-have-a-callback-before-mm-is-destroyed-v2 include/linux/hmm.h
--- a/include/linux/hmm.h~mm-hmm-hmm-should-have-a-callback-before-mm-is-destroyed-v2
+++ a/include/linux/hmm.h
@@ -218,6 +218,16 @@ enum hmm_update_type {
* @update: callback to update range on a device
*/
struct hmm_mirror_ops {
+ /* release() - release hmm_mirror
+ *
+ * @mirror: pointer to struct hmm_mirror
+ *
+ * This is called when the mm_struct is being released.
+ * The callback should make sure no references to the mirror occur
+ * after the callback returns.
+ */
+ void (*release)(struct hmm_mirror *mirror);
+
/* sync_cpu_device_pagetables() - synchronize page tables
*
* @mirror: pointer to struct hmm_mirror
diff -puN mm/hmm.c~mm-hmm-hmm-should-have-a-callback-before-mm-is-destroyed-v2 mm/hmm.c
--- a/mm/hmm.c~mm-hmm-hmm-should-have-a-callback-before-mm-is-destroyed-v2
+++ a/mm/hmm.c
@@ -160,6 +160,21 @@ static void hmm_invalidate_range(struct
up_read(&hmm->mirrors_sem);
}
+static void hmm_release(struct mmu_notifier *mn, struct mm_struct *mm)
+{
+ struct hmm *hmm = mm->hmm;
+ struct hmm_mirror *mirror;
+ struct hmm_mirror *mirror_next;
+
+ down_write(&hmm->mirrors_sem);
+ list_for_each_entry_safe(mirror, mirror_next, &hmm->mirrors, list) {
+ list_del_init(&mirror->list);
+ if (mirror->ops->release)
+ mirror->ops->release(mirror);
+ }
+ up_write(&hmm->mirrors_sem);
+}
+
static void hmm_invalidate_range_start(struct mmu_notifier *mn,
struct mm_struct *mm,
unsigned long start,
@@ -185,6 +200,7 @@ static void hmm_invalidate_range_end(str
}
static const struct mmu_notifier_ops hmm_mmu_notifier_ops = {
+ .release = hmm_release,
.invalidate_range_start = hmm_invalidate_range_start,
.invalidate_range_end = hmm_invalidate_range_end,
};
@@ -230,7 +246,7 @@ void hmm_mirror_unregister(struct hmm_mi
struct hmm *hmm = mirror->hmm;
down_write(&hmm->mirrors_sem);
- list_del(&mirror->list);
+ list_del_init(&mirror->list);
up_write(&hmm->mirrors_sem);
}
EXPORT_SYMBOL(hmm_mirror_unregister);
_
Patches currently in -mm which might be from rcampbell(a)nvidia.com are
mm-hmm-documentation-editorial-update-to-hmm-documentation.patch
mm-hmm-hmm-should-have-a-callback-before-mm-is-destroyed-v2.patch
The patch titled
Subject: mm/hmm: fix header file if/else/endif maze
has been added to the -mm tree. Its filename is
mm-hmm-fix-header-file-if-else-endif-maze.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-hmm-fix-header-file-if-else-end…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-hmm-fix-header-file-if-else-end…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Jérôme Glisse <jglisse(a)redhat.com>
Subject: mm/hmm: fix header file if/else/endif maze
The #if/#else/#endif for IS_ENABLED(CONFIG_HMM) were wrong.
Link: http://lkml.kernel.org/r/20180316191414.3223-3-jglisse@redhat.com
Signed-off-by: Jérôme Glisse <jglisse(a)redhat.com>
Acked-by: Balbir Singh <bsingharora(a)gmail.com>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Ralph Campbell <rcampbell(a)nvidia.com>
Cc: John Hubbard <jhubbard(a)nvidia.com>
Cc: Evgeny Baskakov <ebaskakov(a)nvidia.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/linux/hmm.h | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff -puN include/linux/hmm.h~mm-hmm-fix-header-file-if-else-endif-maze include/linux/hmm.h
--- a/include/linux/hmm.h~mm-hmm-fix-header-file-if-else-endif-maze
+++ a/include/linux/hmm.h
@@ -498,6 +498,9 @@ struct hmm_device {
struct hmm_device *hmm_device_new(void *drvdata);
void hmm_device_put(struct hmm_device *hmm_device);
#endif /* CONFIG_DEVICE_PRIVATE || CONFIG_DEVICE_PUBLIC */
+#else /* IS_ENABLED(CONFIG_HMM) */
+static inline void hmm_mm_destroy(struct mm_struct *mm) {}
+static inline void hmm_mm_init(struct mm_struct *mm) {}
#endif /* IS_ENABLED(CONFIG_HMM) */
/* Below are for HMM internal use only! Not to be used by device driver! */
@@ -513,8 +516,4 @@ static inline void hmm_mm_destroy(struct
static inline void hmm_mm_init(struct mm_struct *mm) {}
#endif /* IS_ENABLED(CONFIG_HMM_MIRROR) */
-
-#else /* IS_ENABLED(CONFIG_HMM) */
-static inline void hmm_mm_destroy(struct mm_struct *mm) {}
-static inline void hmm_mm_init(struct mm_struct *mm) {}
#endif /* LINUX_HMM_H */
_
Patches currently in -mm which might be from jglisse(a)redhat.com are
mm-hmm-fix-header-file-if-else-endif-maze.patch
mm-hmm-hmm_pfns_bad-was-accessing-wrong-struct.patch
mm-hmm-use-struct-for-hmm_vma_fault-hmm_vma_get_pfns-parameters.patch
mm-hmm-remove-hmm_pfn_read-flag-and-ignore-peculiar-architecture.patch
mm-hmm-use-uint64_t-for-hmm-pfn-instead-of-defining-hmm_pfn_t-to-ulong.patch
mm-hmm-cleanup-special-vma-handling-vm_special.patch
mm-hmm-do-not-differentiate-between-empty-entry-or-missing-directory.patch
mm-hmm-rename-hmm_pfn_device_unaddressable-to-hmm_pfn_device_private.patch
mm-hmm-move-hmm_pfns_clear-closer-to-where-it-is-use.patch
mm-hmm-factor-out-pte-and-pmd-handling-to-simplify-hmm_vma_walk_pmd.patch
mm-hmm-change-hmm_vma_fault-to-allow-write-fault-on-page-basis.patch
mm-hmm-use-device-driver-encoding-for-hmm-pfn.patch
shmem_unused_huge_shrink() gets called from reclaim path. Waiting for page
lock may lead to deadlock there.
There was a bug report that may be attributed to this:
http://lkml.kernel.org/r/alpine.LRH.2.11.1801242349220.30642@mail.ewheeler.…
Replace lock_page() with trylock_page() and skip the page if we failed
to lock it. We will get to the page on the next scan.
We can test for the PageTransHuge() outside the page lock as we only
need protection against splitting the page under us. Holding pin oni
the page is enough for this.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Reported-by: Eric Wheeler <linux-mm(a)lists.ewheeler.net>
Fixes: 779750d20b93 ("shmem: split huge pages beyond i_size under memory pressure")
Cc: stable(a)vger.kernel.org # v4.8+
---
mm/shmem.c | 31 ++++++++++++++++++++-----------
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/mm/shmem.c b/mm/shmem.c
index 1907688b75ee..b85919243399 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -493,36 +493,45 @@ static unsigned long shmem_unused_huge_shrink(struct shmem_sb_info *sbinfo,
info = list_entry(pos, struct shmem_inode_info, shrinklist);
inode = &info->vfs_inode;
- if (nr_to_split && split >= nr_to_split) {
- iput(inode);
- continue;
- }
+ if (nr_to_split && split >= nr_to_split)
+ goto leave;
- page = find_lock_page(inode->i_mapping,
+ page = find_get_page(inode->i_mapping,
(inode->i_size & HPAGE_PMD_MASK) >> PAGE_SHIFT);
if (!page)
goto drop;
+ /* No huge page at the end of the file: nothing to split */
if (!PageTransHuge(page)) {
- unlock_page(page);
put_page(page);
goto drop;
}
+ /*
+ * Leave the inode on the list if we failed to lock
+ * the page at this time.
+ *
+ * Waiting for the lock may lead to deadlock in the
+ * reclaim path.
+ */
+ if (!trylock_page(page)) {
+ put_page(page);
+ goto leave;
+ }
+
ret = split_huge_page(page);
unlock_page(page);
put_page(page);
- if (ret) {
- /* split failed: leave it on the list */
- iput(inode);
- continue;
- }
+ /* If split failed leave the inode on the list */
+ if (ret)
+ goto leave;
split++;
drop:
list_del_init(&info->shrinklist);
removed++;
+leave:
iput(inode);
}
--
2.16.1
From: Mathias Kresin <dev(a)kresin.me>
Enable syscon to use it for the RCU MFD on Amazon SE as well.
The Amazon SE also has similar reset controller system as Danube and
XWAY and use their drivers mostly. As these drivers now need syscon also
activate the syscon subsystem for for Amazon SE.
Fixes: 2b6639d4c794 ("MIPS: lantiq: Enable MFD_SYSCON to be able to use it for the RCU MFD")
Cc: <stable(a)vger.kernel.org> # 4.14+
Signed-off-by: Mathias Kresin <dev(a)kresin.me>
Acked-by: Martin Blumenstingl<martin.blumenstingl(a)googlemail.com>
Signed-off-by: Hauke Mehrtens <hauke(a)hauke-m.de>
---
arch/mips/lantiq/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/mips/lantiq/Kconfig b/arch/mips/lantiq/Kconfig
index 692ae85a3e3d..8e3a1fc2bc39 100644
--- a/arch/mips/lantiq/Kconfig
+++ b/arch/mips/lantiq/Kconfig
@@ -13,6 +13,8 @@ choice
config SOC_AMAZON_SE
bool "Amazon SE"
select SOC_TYPE_XWAY
+ select MFD_SYSCON
+ select MFD_CORE
config SOC_XWAY
bool "XWAY"
--
2.11.0
From: Mathias Kresin <dev(a)kresin.me>
On Danube the USB0 controller registers are at 1e101000 and the USB0 PHY
register is at 1f203018 similar to all other lantiq SoCs. Activate the
USB controller gating clock thorough the USB controller driver and not
the PHY.
This fixes a problem introduced in a previous commit.
Fixes: dea54fbad332 ("phy: Add an USB PHY driver for the Lantiq SoCs using the RCU module")
Cc: <stable(a)vger.kernel.org> # 4.14+
Signed-off-by: Mathias Kresin <dev(a)kresin.me>
Acked-by: Martin Blumenstingl<martin.blumenstingl(a)googlemail.com>
Signed-off-by: Hauke Mehrtens <hauke(a)hauke-m.de>
---
arch/mips/lantiq/xway/sysctrl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/lantiq/xway/sysctrl.c b/arch/mips/lantiq/xway/sysctrl.c
index 52500d3b7004..f11f1dd10493 100644
--- a/arch/mips/lantiq/xway/sysctrl.c
+++ b/arch/mips/lantiq/xway/sysctrl.c
@@ -560,7 +560,7 @@ void __init ltq_soc_init(void)
} else {
clkdev_add_static(ltq_danube_cpu_hz(), ltq_danube_fpi_hz(),
ltq_danube_fpi_hz(), ltq_danube_pp32_hz());
- clkdev_add_pmu("1f203018.usb2-phy", "ctrl", 1, 0, PMU_USB0);
+ clkdev_add_pmu("1e101000.usb", "otg", 1, 0, PMU_USB0);
clkdev_add_pmu("1f203018.usb2-phy", "phy", 1, 0, PMU_USB0_P);
clkdev_add_pmu("1e103000.sdio", NULL, 1, 0, PMU_SDIO);
clkdev_add_pmu("1e103100.deu", NULL, 1, 0, PMU_DEU);
--
2.11.0
A vma with vm_pgoff large enough to overflow a loff_t type when
converted to a byte offset can be passed via the remap_file_pages
system call. The hugetlbfs mmap routine uses the byte offset to
calculate reservations and file size.
A sequence such as:
mmap(0x20a00000, 0x600000, 0, 0x66033, -1, 0);
remap_file_pages(0x20a00000, 0x600000, 0, 0x20000000000000, 0);
will result in the following when task exits/file closed,
kernel BUG at mm/hugetlb.c:749!
Call Trace:
hugetlbfs_evict_inode+0x2f/0x40
evict+0xcb/0x190
__dentry_kill+0xcb/0x150
__fput+0x164/0x1e0
task_work_run+0x84/0xa0
exit_to_usermode_loop+0x7d/0x80
do_syscall_64+0x18b/0x190
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
The overflowed pgoff value causes hugetlbfs to try to set up a
mapping with a negative range (end < start) that leaves invalid
state which causes the BUG.
The previous overflow fix to this code was incomplete and did not
take the remap_file_pages system call into account.
Fixes: 045c7a3f53d9 ("hugetlbfs: fix offset overflow in hugetlbfs mmap")
Cc: <stable(a)vger.kernel.org>
Reported-by: Nic Losby <blurbdust(a)gmail.com>
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
---
Changes in v3
* Use a simpler mask computation as suggested by Andrew Morton
Changes in v2
* Use bitmask for overflow check as suggested by Yisheng Xie
* Add explicit (from > to) check when setting up reservations
* Cc stable
fs/hugetlbfs/inode.c | 16 +++++++++++++---
mm/hugetlb.c | 6 ++++++
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 8fe1b0aa2896..e46117dc006a 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -108,6 +108,15 @@ static void huge_pagevec_release(struct pagevec *pvec)
pagevec_reinit(pvec);
}
+/*
+ * Mask used when checking the page offset value passed in via system
+ * calls. This value will be converted to a loff_t which is signed.
+ * Therefore, we want to check the upper PAGE_SHIFT + 1 bits of the
+ * value. The extra bit (- 1 in the shift value) is to take the sign
+ * bit into account.
+ */
+#define PGOFF_LOFFT_MAX (PAGE_MASK << (BITS_PER_LONG - (2 * PAGE_SHIFT) - 1))
+
static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma)
{
struct inode *inode = file_inode(file);
@@ -127,12 +136,13 @@ static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma)
vma->vm_ops = &hugetlb_vm_ops;
/*
- * Offset passed to mmap (before page shift) could have been
- * negative when represented as a (l)off_t.
+ * page based offset in vm_pgoff could be sufficiently large to
+ * overflow a (l)off_t when converted to byte offset.
*/
- if (((loff_t)vma->vm_pgoff << PAGE_SHIFT) < 0)
+ if (vma->vm_pgoff & PGOFF_LOFFT_MAX)
return -EINVAL;
+ /* must be huge page aligned */
if (vma->vm_pgoff & (~huge_page_mask(h) >> PAGE_SHIFT))
return -EINVAL;
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 7c204e3d132b..8eeade0a0b7a 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4374,6 +4374,12 @@ int hugetlb_reserve_pages(struct inode *inode,
struct resv_map *resv_map;
long gbl_reserve;
+ /* This should never happen */
+ if (from > to) {
+ VM_WARN(1, "%s called with a negative range\n", __func__);
+ return -EINVAL;
+ }
+
/*
* Only apply hugepage reservation if asked. At fault time, an
* attempt will be made for VM_NORESERVE to allocate a page
--
2.13.6
This is the start of the stable review cycle for the 4.4.121 release.
There are 36 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Mon Mar 12 00:17:54 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.121-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.4.121-rc1
Ernesto A. Fernández <ernesto.mnd.fernandez(a)gmail.com>
btrfs: preserve i_mode if __btrfs_set_acl() fails
Daniel Borkmann <daniel(a)iogearbox.net>
bpf, x64: implement retpoline for tail call
Mike Snitzer <snitzer(a)redhat.com>
dm io: fix duplicate bio completion due to missing ref count
Dan Williams <dan.j.williams(a)intel.com>
mpls, nospec: Sanitize array index in mpls_label_ok()
David Ahern <dsahern(a)gmail.com>
net: mpls: Pull common label check into helper
Alexey Kodanev <alexey.kodanev(a)oracle.com>
sctp: verify size of a new chunk in _sctp_make_chunk()
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: fix IPA command submission race
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: fix SETIP command handling
Alexey Kodanev <alexey.kodanev(a)oracle.com>
sctp: fix dst refcnt leak in sctp_v6_get_dst()
Tommi Rantala <tommi.t.rantala(a)nokia.com>
sctp: fix dst refcnt leak in sctp_v4_get_dst
Alexey Kodanev <alexey.kodanev(a)oracle.com>
udplite: fix partial checksum initialization
Guillaume Nault <g.nault(a)alphalink.fr>
ppp: prevent unregistered channels from connecting to PPP units
Nicolas Dichtel <nicolas.dichtel(a)6wind.com>
netlink: ensure to loop over all netns in genlmsg_multicast_allns()
Sabrina Dubroca <sd(a)queasysnail.net>
net: ipv4: don't allow setting net.ipv4.route.min_pmtu below 68
Jakub Kicinski <jakub.kicinski(a)netronome.com>
net: fix race on decreasing number of TX queues
Arnd Bergmann <arnd(a)arndb.de>
ipv6 sit: work around bogus gcc-8 -Wrestrict warning
Denis Du <dudenis2000(a)yahoo.ca>
hdlc_ppp: carrier detect ok, don't turn off negotiation
Stefano Brivio <sbrivio(a)redhat.com>
fib_semantics: Don't match route with mismatching tclassid
Xin Long <lucien.xin(a)gmail.com>
bridge: check brport attr show in brport_show
Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Revert "led: core: Fix brightness setting when setting delay_off=0"
Dan Carpenter <dan.carpenter(a)oracle.com>
x86/spectre: Fix an error message
Nathan Sullivan <nathan.sullivan(a)ni.com>
leds: do not overflow sysfs buffer in led_trigger_show
Thomas Gleixner <tglx(a)linutronix.de>
x86/apic/vector: Handle legacy irq data correctly
Adam Ford <aford173(a)gmail.com>
ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux
Jan Kara <jack(a)suse.cz>
btrfs: Don't clear SGID when inheriting ACLs
Jiri Slaby <jslaby(a)suse.cz>
x86/syscall: Sanitize syscall table de-references under speculation fix
Wanpeng Li <wanpeng.li(a)hotmail.com>
KVM: mmu: Fix overlap between public and private memslots
Ulf Magnusson <ulfalizer(a)gmail.com>
ARM: mvebu: Fix broken PL310_ERRATA_753970 selects
Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
nospec: Allow index argument to have const-qualified type
Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
media: m88ds3103: don't call a non-initalized function
Viresh Kumar <viresh.kumar(a)linaro.org>
cpufreq: s3c24xx: Fix broken s3c_cpufreq_init()
Hans de Goede <hdegoede(a)redhat.com>
ALSA: hda: Add a power_save blacklist
Erik Veijola <erik.veijola(a)gmail.com>
ALSA: usb-audio: Add a quirck for B&W PX headphones
Jeremy Boone <jeremy.boone(a)nccgroup.trust>
tpm_i2c_nuvoton: fix potential buffer overruns caused by bit glitches on the bus
Jeremy Boone <jeremy.boone(a)nccgroup.trust>
tpm_i2c_infineon: fix potential buffer overruns caused by bit glitches on the bus
Jeremy Boone <jeremy.boone(a)nccgroup.trust>
tpm: st33zp24: fix potential buffer overruns caused by bit glitches on the bus
-------------
Diffstat:
Makefile | 4 +--
arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 8 +++++
arch/arm/mach-mvebu/Kconfig | 4 +--
arch/x86/entry/entry_64.S | 16 ++++++----
arch/x86/include/asm/nospec-branch.h | 37 +++++++++++++++++++++++
arch/x86/kernel/apic/vector.c | 14 ++++-----
arch/x86/kernel/cpu/bugs.c | 3 +-
arch/x86/net/bpf_jit_comp.c | 9 +++---
drivers/char/tpm/st33zp24/st33zp24.c | 4 +--
drivers/char/tpm/tpm_i2c_infineon.c | 5 ++--
drivers/char/tpm/tpm_i2c_nuvoton.c | 8 +++--
drivers/cpufreq/s3c24xx-cpufreq.c | 8 ++++-
drivers/leds/led-core.c | 2 +-
drivers/leds/led-triggers.c | 12 ++++----
drivers/md/dm-io.c | 1 +
drivers/media/dvb-frontends/m88ds3103.c | 7 +++--
drivers/net/ppp/ppp_generic.c | 9 ++++++
drivers/net/wan/hdlc_ppp.c | 5 +++-
drivers/s390/net/qeth_core.h | 5 ++++
drivers/s390/net/qeth_core_main.c | 33 +++++++++++----------
fs/btrfs/acl.c | 19 +++++++-----
include/linux/nospec.h | 3 +-
include/net/udplite.h | 1 +
net/bridge/br_sysfs_if.c | 3 ++
net/core/dev.c | 11 +++++--
net/ipv4/fib_semantics.c | 5 ++++
net/ipv4/route.c | 8 +++--
net/ipv4/udp.c | 5 ++++
net/ipv6/ip6_checksum.c | 5 ++++
net/ipv6/sit.c | 2 +-
net/mpls/af_mpls.c | 36 +++++++++++++----------
net/netlink/genetlink.c | 12 ++++++--
net/sctp/ipv6.c | 10 +++++--
net/sctp/protocol.c | 10 +++----
net/sctp/sm_make_chunk.c | 8 +++--
sound/pci/hda/hda_intel.c | 38 ++++++++++++++++++++++--
sound/usb/quirks-table.h | 47 ++++++++++++++++++++++++++++++
virt/kvm/kvm_main.c | 3 +-
38 files changed, 320 insertions(+), 100 deletions(-)
From: Israel Rukshin <israelr(a)mellanox.com>
Commit b837b28394fb76993c28bb242db7061ee0417da6 upstream.
There is a problem when another module (e.g. nvmet) takes a reference on
the nvme block device and the physical nvme drive is removed. In that
case nvme_free_ctrl() will not be called and the controller state will be
"deleting" or "dead" unless nvmet module releases the block device.
Later on, the same nvme drive probes back and nvme_init_subsystem() will
be called and fail due to duplicate subnqn (if the nvme device doesn't
support subsystem with multiple controllers). This will cause a probe
failure. This commit changes the check of multiple controllers support
at nvme_init_subsystem() by not counting all the controllers at "dead" or
"deleting" state (this is safe because controllers at this state will
never be active again).
Fixes: ab9e00cc72fa ("nvme: track subsystems")
Reviewed-by: Max Gurtovoy <maxg(a)mellanox.com>
Signed-off-by: Israel Rukshin <israelr(a)mellanox.com>
Signed-off-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Keith Busch <keith.busch(a)intel.com>
---
drivers/nvme/host/core.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 3551fbd6fe41..935593032123 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2052,6 +2052,22 @@ static const struct attribute_group *nvme_subsys_attrs_groups[] = {
NULL,
};
+static int nvme_active_ctrls(struct nvme_subsystem *subsys)
+{
+ int count = 0;
+ struct nvme_ctrl *ctrl;
+
+ mutex_lock(&subsys->lock);
+ list_for_each_entry(ctrl, &subsys->ctrls, subsys_entry) {
+ if (ctrl->state != NVME_CTRL_DELETING &&
+ ctrl->state != NVME_CTRL_DEAD)
+ count++;
+ }
+ mutex_unlock(&subsys->lock);
+
+ return count;
+}
+
static int nvme_init_subsystem(struct nvme_ctrl *ctrl, struct nvme_id_ctrl *id)
{
struct nvme_subsystem *subsys, *found;
@@ -2090,7 +2106,7 @@ static int nvme_init_subsystem(struct nvme_ctrl *ctrl, struct nvme_id_ctrl *id)
* Verify that the subsystem actually supports multiple
* controllers, else bail out.
*/
- if (!(id->cmic & (1 << 1))) {
+ if (nvme_active_ctrls(found) && !(id->cmic & (1 << 1))) {
dev_err(ctrl->device,
"ignoring ctrl due to duplicate subnqn (%s).\n",
found->subnqn);
--
2.14.3
This is a note to let you know that I've just added the patch titled
xfrm: Fix xfrm_replay_overflow_offload_esn
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xfrm-fix-xfrm_replay_overflow_offload_esn.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: Yossef Efraim <yossefe(a)mellanox.com>
Date: Tue, 28 Nov 2017 11:49:28 +0200
Subject: xfrm: Fix xfrm_replay_overflow_offload_esn
From: Yossef Efraim <yossefe(a)mellanox.com>
[ Upstream commit 0ba23a211360af7b6658e4fcfc571970bbbacc55 ]
In case of wrap around, replay_esn->oseq_hi is not updated
before it is tested for it's actual value, leading function
to fail with overflow indication and packets being dropped.
This patch updates replay_esn->oseq_hi in the right place.
Fixes: d7dbefc45cf5 ("xfrm: Add xfrm_replay_overflow functions for offloading")
Signed-off-by: Yossef Efraim <yossefe(a)mellanox.com>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_replay.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/net/xfrm/xfrm_replay.c
+++ b/net/xfrm/xfrm_replay.c
@@ -666,7 +666,7 @@ static int xfrm_replay_overflow_offload_
if (unlikely(oseq < replay_esn->oseq)) {
XFRM_SKB_CB(skb)->seq.output.hi = ++oseq_hi;
xo->seq.hi = oseq_hi;
-
+ replay_esn->oseq_hi = oseq_hi;
if (replay_esn->oseq_hi == 0) {
replay_esn->oseq--;
replay_esn->oseq_hi--;
@@ -678,7 +678,6 @@ static int xfrm_replay_overflow_offload_
}
replay_esn->oseq = oseq;
- replay_esn->oseq_hi = oseq_hi;
if (xfrm_aevent_is_on(net))
x->repl->notify(x, XFRM_REPLAY_UPDATE);
Patches currently in stable-queue which might be from yossefe(a)mellanox.com are
queue-4.14/xfrm-fix-xfrm_replay_overflow_offload_esn.patch
This is a note to let you know that I've just added the patch titled
virtio_net: Disable interrupts if napi_complete_done rescheduled napi
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
virtio_net-disable-interrupts-if-napi_complete_done-rescheduled-napi.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: Toshiaki Makita <makita.toshiaki(a)lab.ntt.co.jp>
Date: Thu, 7 Dec 2017 13:15:15 +0900
Subject: virtio_net: Disable interrupts if napi_complete_done rescheduled napi
From: Toshiaki Makita <makita.toshiaki(a)lab.ntt.co.jp>
[ Upstream commit fdaa767aefc1685f9a41e91f447c9aea94103df6 ]
Since commit 39e6c8208d7b ("net: solve a NAPI race") napi has been able
to be rescheduled within napi_complete_done() even in non-busypoll case,
but virtnet_poll() always enabled interrupts before complete, and when
napi was rescheduled within napi_complete_done() it did not disable
interrupts.
This caused more interrupts when event idx is disabled.
According to commit cbdadbbf0c79 ("virtio_net: fix race in RX VQ
processing") we cannot place virtqueue_enable_cb_prepare() after
NAPI_STATE_SCHED is cleared, so disable interrupts again if
napi_complete_done() returned false.
Tested with vhost-user of OVS 2.7 on host, which does not have the event
idx feature.
* Before patch:
$ netperf -t UDP_STREAM -H 192.168.150.253 -l 60 -- -m 1472
MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.150.253 () port 0 AF_INET
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
212992 1472 60.00 32763206 0 6430.32
212992 60.00 23384299 4589.56
Interrupts on guest: 9872369
Packets/interrupt: 2.37
* After patch
$ netperf -t UDP_STREAM -H 192.168.150.253 -l 60 -- -m 1472
MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.150.253 () port 0 AF_INET
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
212992 1472 60.00 32794646 0 6436.49
212992 60.00 32793501 6436.27
Interrupts on guest: 4941299
Packets/interrupt: 6.64
Signed-off-by: Toshiaki Makita <makita.toshiaki(a)lab.ntt.co.jp>
Acked-by: Michael S. Tsirkin <mst(a)redhat.com>
Acked-by: Jason Wang <jasowang(a)redhat.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/virtio_net.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -260,9 +260,12 @@ static void virtqueue_napi_complete(stru
int opaque;
opaque = virtqueue_enable_cb_prepare(vq);
- if (napi_complete_done(napi, processed) &&
- unlikely(virtqueue_poll(vq, opaque)))
- virtqueue_napi_schedule(napi, vq);
+ if (napi_complete_done(napi, processed)) {
+ if (unlikely(virtqueue_poll(vq, opaque)))
+ virtqueue_napi_schedule(napi, vq);
+ } else {
+ virtqueue_disable_cb(vq);
+ }
}
static void skb_xmit_done(struct virtqueue *vq)
Patches currently in stable-queue which might be from makita.toshiaki(a)lab.ntt.co.jp are
queue-4.14/virtio_net-disable-interrupts-if-napi_complete_done-rescheduled-napi.patch
This is a note to let you know that I've just added the patch titled
video/hdmi: Allow "empty" HDMI infoframes
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
video-hdmi-allow-empty-hdmi-infoframes.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:16 CET 2018
From: "Ville Syrjälä" <ville.syrjala(a)linux.intel.com>
Date: Mon, 13 Nov 2017 19:04:18 +0200
Subject: video/hdmi: Allow "empty" HDMI infoframes
From: "Ville Syrjälä" <ville.syrjala(a)linux.intel.com>
[ Upstream commit 593f4b19a094c4426bd1e1e3cbab87a48bd13c71 ]
HDMI 2.0 Appendix F suggest that we should keep sending the infoframe
when switching from 3D to 2D mode, even if the infoframe isn't strictly
necessary (ie. not needed to transmit the VIC or stereo information).
This is a workaround against some sinks that fail to realize that they
should switch from 3D to 2D mode when the source stop transmitting
the infoframe.
v2: Handle unpack() as well
Pull the length calculation into a helper
Cc: Shashank Sharma <shashank.sharma(a)intel.com>
Cc: Andrzej Hajda <a.hajda(a)samsung.com>
Cc: Thierry Reding <thierry.reding(a)gmail.com>
Cc: Hans Verkuil <hans.verkuil(a)cisco.com>
Cc: linux-media(a)vger.kernel.org
Reviewed-by: Andrzej Hajda <a.hajda(a)samsung.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171113170427.4150-2-ville.s…
Reviewed-by: Shashank Sharma <shashank.sharma(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/video/hdmi.c | 51 +++++++++++++++++++++++++++++++--------------------
1 file changed, 31 insertions(+), 20 deletions(-)
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -321,6 +321,17 @@ int hdmi_vendor_infoframe_init(struct hd
}
EXPORT_SYMBOL(hdmi_vendor_infoframe_init);
+static int hdmi_vendor_infoframe_length(const struct hdmi_vendor_infoframe *frame)
+{
+ /* for side by side (half) we also need to provide 3D_Ext_Data */
+ if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
+ return 6;
+ else if (frame->vic != 0 || frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID)
+ return 5;
+ else
+ return 4;
+}
+
/**
* hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary buffer
* @frame: HDMI infoframe
@@ -341,19 +352,11 @@ ssize_t hdmi_vendor_infoframe_pack(struc
u8 *ptr = buffer;
size_t length;
- /* empty info frame */
- if (frame->vic == 0 && frame->s3d_struct == HDMI_3D_STRUCTURE_INVALID)
- return -EINVAL;
-
/* only one of those can be supplied */
if (frame->vic != 0 && frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID)
return -EINVAL;
- /* for side by side (half) we also need to provide 3D_Ext_Data */
- if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
- frame->length = 6;
- else
- frame->length = 5;
+ frame->length = hdmi_vendor_infoframe_length(frame);
length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
@@ -372,14 +375,16 @@ ssize_t hdmi_vendor_infoframe_pack(struc
ptr[5] = 0x0c;
ptr[6] = 0x00;
- if (frame->vic) {
- ptr[7] = 0x1 << 5; /* video format */
- ptr[8] = frame->vic;
- } else {
+ if (frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) {
ptr[7] = 0x2 << 5; /* video format */
ptr[8] = (frame->s3d_struct & 0xf) << 4;
if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
ptr[9] = (frame->s3d_ext_data & 0xf) << 4;
+ } else if (frame->vic) {
+ ptr[7] = 0x1 << 5; /* video format */
+ ptr[8] = frame->vic;
+ } else {
+ ptr[7] = 0x0 << 5; /* video format */
}
hdmi_infoframe_set_checksum(buffer, length);
@@ -1165,7 +1170,7 @@ hdmi_vendor_any_infoframe_unpack(union h
if (ptr[0] != HDMI_INFOFRAME_TYPE_VENDOR ||
ptr[1] != 1 ||
- (ptr[2] != 5 && ptr[2] != 6))
+ (ptr[2] != 4 && ptr[2] != 5 && ptr[2] != 6))
return -EINVAL;
length = ptr[2];
@@ -1193,16 +1198,22 @@ hdmi_vendor_any_infoframe_unpack(union h
hvf->length = length;
- if (hdmi_video_format == 0x1) {
- hvf->vic = ptr[4];
- } else if (hdmi_video_format == 0x2) {
+ if (hdmi_video_format == 0x2) {
+ if (length != 5 && length != 6)
+ return -EINVAL;
hvf->s3d_struct = ptr[4] >> 4;
if (hvf->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) {
- if (length == 6)
- hvf->s3d_ext_data = ptr[5] >> 4;
- else
+ if (length != 6)
return -EINVAL;
+ hvf->s3d_ext_data = ptr[5] >> 4;
}
+ } else if (hdmi_video_format == 0x1) {
+ if (length != 5)
+ return -EINVAL;
+ hvf->vic = ptr[4];
+ } else {
+ if (length != 4)
+ return -EINVAL;
}
return 0;
Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are
queue-4.14/video-hdmi-allow-empty-hdmi-infoframes.patch
queue-4.14/drm-edid-set-eld-connector-type-in-drm_edid_to_eld.patch
This is a note to let you know that I've just added the patch titled
veth: set peer GSO values
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
veth-set-peer-gso-values.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: Stephen Hemminger <stephen(a)networkplumber.org>
Date: Thu, 7 Dec 2017 15:40:20 -0800
Subject: veth: set peer GSO values
From: Stephen Hemminger <stephen(a)networkplumber.org>
[ Upstream commit 72d24955b44a4039db54a1c252b5031969eeaac3 ]
When new veth is created, and GSO values have been configured
on one device, clone those values to the peer.
For example:
# ip link add dev vm1 gso_max_size 65530 type veth peer name vm2
This should create vm1 <--> vm2 with both having GSO maximum
size set to 65530.
Signed-off-by: Stephen Hemminger <sthemmin(a)microsoft.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/veth.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -410,6 +410,9 @@ static int veth_newlink(struct net *src_
if (ifmp && (dev->ifindex != 0))
peer->ifindex = ifmp->ifi_index;
+ peer->gso_max_size = dev->gso_max_size;
+ peer->gso_max_segs = dev->gso_max_segs;
+
err = register_netdevice(peer);
put_net(net);
net = NULL;
Patches currently in stable-queue which might be from stephen(a)networkplumber.org are
queue-4.14/veth-set-peer-gso-values.patch
This is a note to let you know that I've just added the patch titled
userns: Don't fail follow_automount based on s_user_ns
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
userns-don-t-fail-follow_automount-based-on-s_user_ns.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
Date: Wed, 29 Nov 2017 17:29:20 -0600
Subject: userns: Don't fail follow_automount based on s_user_ns
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
[ Upstream commit bbc3e471011417598e598707486f5d8814ec9c01 ]
When vfs_submount was added the test to limit automounts from
filesystems that with s_user_ns != &init_user_ns accidentially left
in follow_automount. The test was never about any security concerns
and was always about how do we implement this for filesystems whose
s_user_ns != &init_user_ns.
At the moment this check makes no difference as there are no
filesystems that both set FS_USERNS_MOUNT and implement d_automount.
Remove this check now while I am thinking about it so there will not
be odd booby traps for someone who does want to make this combination
work.
vfs_submount still needs improvements to allow this combination to work,
and vfs_submount contains a check that presents a warning.
The autofs4 filesystem could be modified to set FS_USERNS_MOUNT and it would
need not work on this code path, as userspace performs the mounts.
Fixes: 93faccbbfa95 ("fs: Better permission checking for submounts")
Fixes: aeaa4a79ff6a ("fs: Call d_automount with the filesystems creds")
Acked-by: Ian Kent <raven(a)themaw.net>
Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/namei.c | 3 ---
1 file changed, 3 deletions(-)
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1133,9 +1133,6 @@ static int follow_automount(struct path
path->dentry->d_inode)
return -EISDIR;
- if (path->dentry->d_sb->s_user_ns != &init_user_ns)
- return -EACCES;
-
nd->total_link_count++;
if (nd->total_link_count >= 40)
return -ELOOP;
Patches currently in stable-queue which might be from ebiederm(a)xmission.com are
queue-4.14/userns-don-t-fail-follow_automount-based-on-s_user_ns.patch
This is a note to let you know that I've just added the patch titled
USB: ledtrig-usbport: fix of-node leak
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-ledtrig-usbport-fix-of-node-leak.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: Johan Hovold <johan(a)kernel.org>
Date: Thu, 9 Nov 2017 18:07:22 +0100
Subject: USB: ledtrig-usbport: fix of-node leak
From: Johan Hovold <johan(a)kernel.org>
[ Upstream commit 03310a15484ab6a8f6d91bbf7fe486b17275c09a ]
This code looks up a USB device node from a given parent USB device but
never dropped its reference to the returned node.
As only the address of the node is used for a later matching, the
reference can be dropped immediately.
Note that this trigger implementation confuses the description of the
USB device connected to a port with the port itself (which does not have
a device-tree representation).
Fixes: 4f04c210d031 ("usb: core: read USB ports from DT in the usbport LED trigger driver")
Cc: Rafał Miłecki <rafal(a)milecki.pl>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/ledtrig-usbport.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/drivers/usb/core/ledtrig-usbport.c
+++ b/drivers/usb/core/ledtrig-usbport.c
@@ -140,11 +140,17 @@ static bool usbport_trig_port_observed(s
if (!led_np)
return false;
- /* Get node of port being added */
+ /*
+ * Get node of port being added
+ *
+ * FIXME: This is really the device node of the connected device
+ */
port_np = usb_of_get_child_node(usb_dev->dev.of_node, port1);
if (!port_np)
return false;
+ of_node_put(port_np);
+
/* Amount of trigger sources for this LED */
count = of_count_phandle_with_args(led_np, "trigger-sources",
"#trigger-source-cells");
Patches currently in stable-queue which might be from johan(a)kernel.org are
queue-4.14/usb-ledtrig-usbport-fix-of-node-leak.patch
queue-4.14/serial-core-mark-port-as-initialized-in-autoconfig.patch
This is a note to let you know that I've just added the patch titled
typec: tcpm: fusb302: Resolve out of order messaging events
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
typec-tcpm-fusb302-resolve-out-of-order-messaging-events.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: Adam Thomson <Adam.Thomson.Opensource(a)diasemi.com>
Date: Tue, 21 Nov 2017 14:12:12 +0000
Subject: typec: tcpm: fusb302: Resolve out of order messaging events
From: Adam Thomson <Adam.Thomson.Opensource(a)diasemi.com>
[ Upstream commit ab69f61321140ff632d560775bc226259a78dfa2 ]
The expectation in the FUSB302 driver is that a TX_SUCCESS event
should occur after a message has been sent, but before a GCRCSENT
event is raised to indicate successful receipt of a message from
the partner. However in some circumstances it is possible to see
the hardware raise a GCRCSENT event before a TX_SUCCESS event
is raised. The upshot of this is that the GCRCSENT handling portion
of code ends up reporting the GoodCRC message to TCPM because the
TX_SUCCESS event hasn't yet arrived to trigger a consumption of it.
When TX_SUCCESS is then raised by the chip it ends up consuming the
actual message that was meant for TCPM, and this incorrect sequence
results in a hard reset from TCPM.
To avoid this problem, this commit updates the message reading
code to check whether a GoodCRC message was received or not. Based
on this check it will either report that the previous transmission
has completed or it will pass the msg data to TCPM for futher
processing. This way the incorrect ordering of the events no longer
matters.
Signed-off-by: Adam Thomson <Adam.Thomson.Opensource(a)diasemi.com>
Reviewed-by: Guenter Roeck <linux(a)roeck-us.net>
Acked-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/typec/fusb302/fusb302.c | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
--- a/drivers/staging/typec/fusb302/fusb302.c
+++ b/drivers/staging/typec/fusb302/fusb302.c
@@ -1552,6 +1552,21 @@ static int fusb302_pd_read_message(struc
fusb302_log(chip, "PD message header: %x", msg->header);
fusb302_log(chip, "PD message len: %d", len);
+ /*
+ * Check if we've read off a GoodCRC message. If so then indicate to
+ * TCPM that the previous transmission has completed. Otherwise we pass
+ * the received message over to TCPM for processing.
+ *
+ * We make this check here instead of basing the reporting decision on
+ * the IRQ event type, as it's possible for the chip to report the
+ * TX_SUCCESS and GCRCSENT events out of order on occasion, so we need
+ * to check the message type to ensure correct reporting to TCPM.
+ */
+ if ((!len) && (pd_header_type_le(msg->header) == PD_CTRL_GOOD_CRC))
+ tcpm_pd_transmit_complete(chip->tcpm_port, TCPC_TX_SUCCESS);
+ else
+ tcpm_pd_receive(chip->tcpm_port, msg);
+
return ret;
}
@@ -1659,13 +1674,12 @@ static irqreturn_t fusb302_irq_intn(int
if (interrupta & FUSB_REG_INTERRUPTA_TX_SUCCESS) {
fusb302_log(chip, "IRQ: PD tx success");
- /* read out the received good CRC */
ret = fusb302_pd_read_message(chip, &pd_msg);
if (ret < 0) {
- fusb302_log(chip, "cannot read in GCRC, ret=%d", ret);
+ fusb302_log(chip,
+ "cannot read in PD message, ret=%d", ret);
goto done;
}
- tcpm_pd_transmit_complete(chip->tcpm_port, TCPC_TX_SUCCESS);
}
if (interrupta & FUSB_REG_INTERRUPTA_HARDRESET) {
@@ -1686,7 +1700,6 @@ static irqreturn_t fusb302_irq_intn(int
"cannot read in PD message, ret=%d", ret);
goto done;
}
- tcpm_pd_receive(chip->tcpm_port, &pd_msg);
}
done:
mutex_unlock(&chip->lock);
Patches currently in stable-queue which might be from Adam.Thomson.Opensource(a)diasemi.com are
queue-4.14/typec-tcpm-fusb302-resolve-out-of-order-messaging-events.patch
This is a note to let you know that I've just added the patch titled
tools/usbip: fixes build with musl libc toolchain
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tools-usbip-fixes-build-with-musl-libc-toolchain.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: Julien BOIBESSOT <julien.boibessot(a)armadeus.com>
Date: Tue, 5 Dec 2017 18:48:14 +0100
Subject: tools/usbip: fixes build with musl libc toolchain
From: Julien BOIBESSOT <julien.boibessot(a)armadeus.com>
[ Upstream commit 77be4c878c72e411ad22af96b6f81dd45c26450a ]
Indeed musl doesn't define old SIGCLD signal name but only new one SIGCHLD.
SIGCHLD is the new POSIX name for that signal so it doesn't change
anything on other libcs.
This fixes this kind of build error:
usbipd.c: In function ‘set_signal’:
usbipd.c:459:12: error: 'SIGCLD' undeclared (first use in this function)
sigaction(SIGCLD, &act, NULL);
^~~~~~
usbipd.c:459:12: note: each undeclared identifier is reported only once
for each function it appears in
Makefile:407: recipe for target 'usbipd.o' failed
make[3]: *** [usbipd.o] Error 1
Signed-off-by: Julien BOIBESSOT <julien.boibessot(a)armadeus.com>
Acked-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/usb/usbip/src/usbipd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/tools/usb/usbip/src/usbipd.c
+++ b/tools/usb/usbip/src/usbipd.c
@@ -456,7 +456,7 @@ static void set_signal(void)
sigaction(SIGTERM, &act, NULL);
sigaction(SIGINT, &act, NULL);
act.sa_handler = SIG_IGN;
- sigaction(SIGCLD, &act, NULL);
+ sigaction(SIGCHLD, &act, NULL);
}
static const char *pid_file;
Patches currently in stable-queue which might be from julien.boibessot(a)armadeus.com are
queue-4.14/tools-usbip-fixes-build-with-musl-libc-toolchain.patch
This is a note to let you know that I've just added the patch titled
test_firmware: fix setting old custom fw path back on exit
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
test_firmware-fix-setting-old-custom-fw-path-back-on-exit.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: "Luis R. Rodriguez" <mcgrof(a)kernel.org>
Date: Mon, 20 Nov 2017 09:45:35 -0800
Subject: test_firmware: fix setting old custom fw path back on exit
From: "Luis R. Rodriguez" <mcgrof(a)kernel.org>
[ Upstream commit 65c79230576873b312c3599479c1e42355c9f349 ]
The file /sys/module/firmware_class/parameters/path can be used
to set a custom firmware path. The fw_filesystem.sh script creates
a temporary directory to add a test firmware file to be used during
testing, in order for this to work it uses the custom path syfs file
and it was supposed to reset back the file on execution exit. The
script failed to do this due to a typo, it was using OLD_PATH instead
of OLD_FWPATH, since its inception since v3.17.
Its not as easy to just keep the old setting, it turns out that
resetting an empty setting won't actually do what we want, we need
to check if it was empty and set an empty space.
Without this we end up having the temporary path always set after
we run these tests.
Fixes: 0a8adf58475 ("test: add firmware_class loader test")
Signed-off-by: Luis R. Rodriguez <mcgrof(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/testing/selftests/firmware/fw_filesystem.sh | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/tools/testing/selftests/firmware/fw_filesystem.sh
+++ b/tools/testing/selftests/firmware/fw_filesystem.sh
@@ -45,7 +45,10 @@ test_finish()
if [ "$HAS_FW_LOADER_USER_HELPER" = "yes" ]; then
echo "$OLD_TIMEOUT" >/sys/class/firmware/timeout
fi
- echo -n "$OLD_PATH" >/sys/module/firmware_class/parameters/path
+ if [ "$OLD_FWPATH" = "" ]; then
+ OLD_FWPATH=" "
+ fi
+ echo -n "$OLD_FWPATH" >/sys/module/firmware_class/parameters/path
rm -f "$FW"
rmdir "$FWPATH"
}
Patches currently in stable-queue which might be from mcgrof(a)kernel.org are
queue-4.14/test_firmware-fix-setting-old-custom-fw-path-back-on-exit.patch
This is a note to let you know that I've just added the patch titled
staging: rtl8822be: fix missing null check on dev_alloc_skb return
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
staging-rtl8822be-fix-missing-null-check-on-dev_alloc_skb-return.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:16 CET 2018
From: Colin Ian King <colin.king(a)canonical.com>
Date: Fri, 17 Nov 2017 14:50:55 +0000
Subject: staging: rtl8822be: fix missing null check on dev_alloc_skb return
From: Colin Ian King <colin.king(a)canonical.com>
[ Upstream commit 3eb23426e1749a0483bc4c9b18e51f657569e3ed ]
dev_alloc_skb can potentially return NULL, so add a null check to
avoid a null pointer dereference on skb
Detected by CoverityScan, CID#1454558 ("Dereference on null return")
Fixes: 7e5b796cde7e ("staging: r8822be: Add the driver code")
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Acked-by: Larry Finger <Larry.Finger(a)lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/rtlwifi/rtl8822be/fw.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/staging/rtlwifi/rtl8822be/fw.c
+++ b/drivers/staging/rtlwifi/rtl8822be/fw.c
@@ -464,6 +464,8 @@ bool rtl8822b_halmac_cb_write_data_rsvd_
int count;
skb = dev_alloc_skb(size);
+ if (!skb)
+ return false;
memcpy((u8 *)skb_put(skb, size), buf, size);
if (!_rtl8822be_send_bcn_or_cmd_packet(rtlpriv->hw, skb, BEACON_QUEUE))
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.14/usbip-vudc-fix-null-pointer-dereference-on-udc-lock.patch
queue-4.14/crypto-cavium-fix-memory-leak-on-info.patch
queue-4.14/staging-rtl8822be-fix-missing-null-check-on-dev_alloc_skb-return.patch
This is a note to let you know that I've just added the patch titled
spi: sun6i: disable/unprepare clocks on remove
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
spi-sun6i-disable-unprepare-clocks-on-remove.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: Tobias Jordan <Tobias.Jordan(a)elektrobit.com>
Date: Thu, 7 Dec 2017 15:04:53 +0100
Subject: spi: sun6i: disable/unprepare clocks on remove
From: Tobias Jordan <Tobias.Jordan(a)elektrobit.com>
[ Upstream commit 2d9bbd02c54094ceffa555143b0d68cd06504d63 ]
sun6i_spi_probe() uses sun6i_spi_runtime_resume() to prepare/enable
clocks, so sun6i_spi_remove() should use sun6i_spi_runtime_suspend() to
disable/unprepare them if we're not suspended.
Replacing pm_runtime_disable() by pm_runtime_force_suspend() will ensure
that sun6i_spi_runtime_suspend() is called if needed.
Found by Linux Driver Verification project (linuxtesting.org).
Fixes: 3558fe900e8af (spi: sunxi: Add Allwinner A31 SPI controller driver)
Signed-off-by: Tobias Jordan <Tobias.Jordan(a)elektrobit.com>
Acked-by: Maxime Ripard <maxime.ripard(a)free-electrons.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/spi/spi-sun6i.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -541,7 +541,7 @@ err_free_master:
static int sun6i_spi_remove(struct platform_device *pdev)
{
- pm_runtime_disable(&pdev->dev);
+ pm_runtime_force_suspend(&pdev->dev);
return 0;
}
Patches currently in stable-queue which might be from Tobias.Jordan(a)elektrobit.com are
queue-4.14/spi-sun6i-disable-unprepare-clocks-on-remove.patch
This is a note to let you know that I've just added the patch titled
scsi: ses: don't ask for diagnostic pages repeatedly during probe
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-ses-don-t-ask-for-diagnostic-pages-repeatedly-during-probe.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: Li Dongyang <dongyang.li(a)anu.edu.au>
Date: Tue, 14 Nov 2017 10:48:04 +1100
Subject: scsi: ses: don't ask for diagnostic pages repeatedly during probe
From: Li Dongyang <dongyang.li(a)anu.edu.au>
[ Upstream commit 9c0a50022b8ac7e863e6ec8342fa476fe5d1d75c ]
We are testing if there is a match with the ses device in a loop by
calling ses_match_to_enclosure(), which will issue scsi receive
diagnostics commands to the ses device for every device on the same
host. On one of our boxes with 840 disks, it takes a long time to load
the driver:
[root@g1b-oss06 ~]# time modprobe ses
real 40m48.247s
user 0m0.001s
sys 0m0.196s
With the patch:
[root@g1b-oss06 ~]# time modprobe ses
real 0m17.915s
user 0m0.008s
sys 0m0.053s
Note that we still need to refresh page 10 when we see a new disk to
create the link.
Signed-off-by: Li Dongyang <dongyang.li(a)anu.edu.au>
Tested-by: Jason Ozolins <jason.ozolins(a)hpe.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/ses.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
--- a/drivers/scsi/ses.c
+++ b/drivers/scsi/ses.c
@@ -615,13 +615,16 @@ static void ses_enclosure_data_process(s
}
static void ses_match_to_enclosure(struct enclosure_device *edev,
- struct scsi_device *sdev)
+ struct scsi_device *sdev,
+ int refresh)
{
+ struct scsi_device *edev_sdev = to_scsi_device(edev->edev.parent);
struct efd efd = {
.addr = 0,
};
- ses_enclosure_data_process(edev, to_scsi_device(edev->edev.parent), 0);
+ if (refresh)
+ ses_enclosure_data_process(edev, edev_sdev, 0);
if (scsi_is_sas_rphy(sdev->sdev_target->dev.parent))
efd.addr = sas_get_address(sdev);
@@ -652,7 +655,7 @@ static int ses_intf_add(struct device *c
struct enclosure_device *prev = NULL;
while ((edev = enclosure_find(&sdev->host->shost_gendev, prev)) != NULL) {
- ses_match_to_enclosure(edev, sdev);
+ ses_match_to_enclosure(edev, sdev, 1);
prev = edev;
}
return -ENODEV;
@@ -768,7 +771,7 @@ page2_not_supported:
shost_for_each_device(tmp_sdev, sdev->host) {
if (tmp_sdev->lun != 0 || scsi_device_enclosure(tmp_sdev))
continue;
- ses_match_to_enclosure(edev, tmp_sdev);
+ ses_match_to_enclosure(edev, tmp_sdev, 0);
}
return 0;
Patches currently in stable-queue which might be from dongyang.li(a)anu.edu.au are
queue-4.14/scsi-ses-don-t-ask-for-diagnostic-pages-repeatedly-during-probe.patch
This is a note to let you know that I've just added the patch titled
scsi: dh: add new rdac devices
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-dh-add-new-rdac-devices.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: Xose Vazquez Perez <xose.vazquez(a)gmail.com>
Date: Fri, 17 Nov 2017 22:05:13 +0100
Subject: scsi: dh: add new rdac devices
From: Xose Vazquez Perez <xose.vazquez(a)gmail.com>
[ Upstream commit 4b3aec2bbbce1c35f50e7475a9fd78d24b9ea4ea ]
Add IBM 3542 and 3552, arrays: FAStT200 and FAStT500.
Add full STK OPENstorage family, arrays: 9176, D173, D178, D210, D220,
D240 and D280.
Add STK BladeCtlr family, arrays: B210, B220, B240 and B280.
These changes were done in multipath-tools time ago.
Cc: NetApp RDAC team <ng-eseries-upstream-maintainers(a)netapp.com>
Cc: Hannes Reinecke <hare(a)suse.de>
Cc: Christophe Varoqui <christophe.varoqui(a)opensvc.com>
Cc: Martin K. Petersen <martin.petersen(a)oracle.com>
Cc: James E.J. Bottomley <jejb(a)linux.vnet.ibm.com>
Cc: SCSI ML <linux-scsi(a)vger.kernel.org>
Cc: device-mapper development <dm-devel(a)redhat.com>
Signed-off-by: Xose Vazquez Perez <xose.vazquez(a)gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/scsi_dh.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/scsi/scsi_dh.c
+++ b/drivers/scsi/scsi_dh.c
@@ -56,10 +56,13 @@ static const struct scsi_dh_blist scsi_d
{"IBM", "1815", "rdac", },
{"IBM", "1818", "rdac", },
{"IBM", "3526", "rdac", },
+ {"IBM", "3542", "rdac", },
+ {"IBM", "3552", "rdac", },
{"SGI", "TP9", "rdac", },
{"SGI", "IS", "rdac", },
- {"STK", "OPENstorage D280", "rdac", },
+ {"STK", "OPENstorage", "rdac", },
{"STK", "FLEXLINE 380", "rdac", },
+ {"STK", "BladeCtlr", "rdac", },
{"SUN", "CSM", "rdac", },
{"SUN", "LCSM100", "rdac", },
{"SUN", "STK6580_6780", "rdac", },
Patches currently in stable-queue which might be from xose.vazquez(a)gmail.com are
queue-4.14/scsi-devinfo-apply-to-hp-xp-the-same-flags-as-hitachi-vsp.patch
queue-4.14/scsi-dh-add-new-rdac-devices.patch
This is a note to let you know that I've just added the patch titled
scsi: devinfo: apply to HP XP the same flags as Hitachi VSP
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-devinfo-apply-to-hp-xp-the-same-flags-as-hitachi-vsp.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: Xose Vazquez Perez <xose.vazquez(a)gmail.com>
Date: Fri, 17 Nov 2017 21:31:36 +0100
Subject: scsi: devinfo: apply to HP XP the same flags as Hitachi VSP
From: Xose Vazquez Perez <xose.vazquez(a)gmail.com>
[ Upstream commit b369a0471503130cfc74f9f62071db97f48948c3 ]
Commit 56f3d383f37b ("scsi: scsi_devinfo: Add TRY_VPD_PAGES to HITACHI
OPEN-V blacklist entry") modified some Hitachi entries:
HITACHI is always supporting VPD pages, even though it's claiming to
support SCSI Revision 3 only.
The same should have been done also for HP-rebranded.
[mkp: checkpatch and tweaked commit message]
Cc: Hannes Reinecke <hare(a)suse.de>
Cc: Takahiro Yasui <takahiro.yasui(a)hds.com>
Cc: Matthias Rudolph <Matthias.Rudolph(a)hitachivantara.com>
Cc: Martin K. Petersen <martin.petersen(a)oracle.com>
Cc: James E.J. Bottomley <jejb(a)linux.vnet.ibm.com>
Cc: SCSI ML <linux-scsi(a)vger.kernel.org>
Signed-off-by: Xose Vazquez Perez <xose.vazquez(a)gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/scsi_devinfo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -181,7 +181,7 @@ static struct {
{"HITACHI", "6586-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
{"HITACHI", "6588-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
{"HP", "A6189A", NULL, BLIST_SPARSELUN | BLIST_LARGELUN}, /* HP VA7400 */
- {"HP", "OPEN-", "*", BLIST_REPORTLUN2}, /* HP XP Arrays */
+ {"HP", "OPEN-", "*", BLIST_REPORTLUN2 | BLIST_TRY_VPD_PAGES}, /* HP XP Arrays */
{"HP", "NetRAID-4M", NULL, BLIST_FORCELUN},
{"HP", "HSV100", NULL, BLIST_REPORTLUN2 | BLIST_NOSTARTONADD},
{"HP", "C1557A", NULL, BLIST_FORCELUN},
Patches currently in stable-queue which might be from xose.vazquez(a)gmail.com are
queue-4.14/scsi-devinfo-apply-to-hp-xp-the-same-flags-as-hitachi-vsp.patch
queue-4.14/scsi-dh-add-new-rdac-devices.patch
This is a note to let you know that I've just added the patch titled
scsi: core: scsi_get_device_flags_keyed(): Always return device flags
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-core-scsi_get_device_flags_keyed-always-return-device-flags.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Mon, 4 Dec 2017 10:36:31 -0800
Subject: scsi: core: scsi_get_device_flags_keyed(): Always return device flags
From: Bart Van Assche <bart.vanassche(a)wdc.com>
[ Upstream commit a44c9d36509c83cf64f33b93f6ab2e63822c01eb ]
Since scsi_get_device_flags_keyed() callers do not check whether or not
the returned value is an error code, change that function such that it
returns a flags value even if the 'key' argument is invalid. Note:
since commit 28a0bc4120d3 ("scsi: sd: Implement blacklist option for
WRITE SAME w/ UNMAP") bit 31 is a valid device information flag so
checking whether bit 31 is set in the return value is not sufficient to
tell the difference between an error code and a flags value.
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Hannes Reinecke <hare(a)suse.com>
Cc: Johannes Thumshirn <jthumshirn(a)suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/scsi_devinfo.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -595,17 +595,12 @@ int scsi_get_device_flags_keyed(struct s
int key)
{
struct scsi_dev_info_list *devinfo;
- int err;
devinfo = scsi_dev_info_list_find(vendor, model, key);
if (!IS_ERR(devinfo))
return devinfo->flags;
- err = PTR_ERR(devinfo);
- if (err != -ENOENT)
- return err;
-
- /* nothing found, return nothing */
+ /* key or device not found: return nothing */
if (key != SCSI_DEVINFO_GLOBAL)
return 0;
Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are
queue-4.14/scsi-core-scsi_get_device_flags_keyed-always-return-device-flags.patch
This is a note to let you know that I've just added the patch titled
sched: Stop switched_to_rt() from sending IPIs to offline CPUs
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sched-stop-switched_to_rt-from-sending-ipis-to-offline-cpus.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com>
Date: Fri, 13 Oct 2017 17:00:18 -0700
Subject: sched: Stop switched_to_rt() from sending IPIs to offline CPUs
From: "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com>
[ Upstream commit 2fe2582649aa2355f79acddb86bd4d6c5363eb63 ]
The rcutorture test suite occasionally provokes a splat due to invoking
rt_mutex_lock() which needs to boost the priority of a task currently
sitting on a runqueue that belongs to an offline CPU:
WARNING: CPU: 0 PID: 12 at /home/paulmck/public_git/linux-rcu/arch/x86/kernel/smp.c:128 native_smp_send_reschedule+0x37/0x40
Modules linked in:
CPU: 0 PID: 12 Comm: rcub/7 Not tainted 4.14.0-rc4+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
task: ffff9ed3de5f8cc0 task.stack: ffffbbf80012c000
RIP: 0010:native_smp_send_reschedule+0x37/0x40
RSP: 0018:ffffbbf80012fd10 EFLAGS: 00010082
RAX: 000000000000002f RBX: ffff9ed3dd9cb300 RCX: 0000000000000004
RDX: 0000000080000004 RSI: 0000000000000086 RDI: 00000000ffffffff
RBP: ffffbbf80012fd10 R08: 000000000009da7a R09: 0000000000007b9d
R10: 0000000000000001 R11: ffffffffbb57c2cd R12: 000000000000000d
R13: ffff9ed3de5f8cc0 R14: 0000000000000061 R15: ffff9ed3ded59200
FS: 0000000000000000(0000) GS:ffff9ed3dea00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000080686f0 CR3: 000000001b9e0000 CR4: 00000000000006f0
Call Trace:
resched_curr+0x61/0xd0
switched_to_rt+0x8f/0xa0
rt_mutex_setprio+0x25c/0x410
task_blocks_on_rt_mutex+0x1b3/0x1f0
rt_mutex_slowlock+0xa9/0x1e0
rt_mutex_lock+0x29/0x30
rcu_boost_kthread+0x127/0x3c0
kthread+0x104/0x140
? rcu_report_unblock_qs_rnp+0x90/0x90
? kthread_create_on_node+0x40/0x40
ret_from_fork+0x22/0x30
Code: f0 00 0f 92 c0 84 c0 74 14 48 8b 05 34 74 c5 00 be fd 00 00 00 ff 90 a0 00 00 00 5d c3 89 fe 48 c7 c7 a0 c6 fc b9 e8 d5 b5 06 00 <0f> ff 5d c3 0f 1f 44 00 00 8b 05 a2 d1 13 02 85 c0 75 38 55 48
But the target task's priority has already been adjusted, so the only
purpose of switched_to_rt() invoking resched_curr() is to wake up the
CPU running some task that needs to be preempted by the boosted task.
But the CPU is offline, which presumably means that the task must be
migrated to some other CPU, and that this other CPU will undertake any
needed preemption at the time of migration. Because the runqueue lock
is held when resched_curr() is invoked, we know that the boosted task
cannot go anywhere, so it is not necessary to invoke resched_curr()
in this particular case.
This commit therefore makes switched_to_rt() refrain from invoking
resched_curr() when the target CPU is offline.
Signed-off-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo(a)redhat.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/sched/rt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -2218,7 +2218,7 @@ static void switched_to_rt(struct rq *rq
if (p->nr_cpus_allowed > 1 && rq->rt.overloaded)
queue_push_tasks(rq);
#endif /* CONFIG_SMP */
- if (p->prio < rq->curr->prio)
+ if (p->prio < rq->curr->prio && cpu_online(cpu_of(rq)))
resched_curr(rq);
}
}
Patches currently in stable-queue which might be from paulmck(a)linux.vnet.ibm.com are
queue-4.14/sched-stop-resched_cpu-from-sending-ipis-to-offline-cpus.patch
queue-4.14/sched-stop-switched_to_rt-from-sending-ipis-to-offline-cpus.patch
queue-4.14/locking-locktorture-fix-num-reader-writer-corner-cases.patch
queue-4.14/rcutorture-configinit-fix-build-directory-error-message.patch
This is a note to let you know that I've just added the patch titled
sched: Stop resched_cpu() from sending IPIs to offline CPUs
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sched-stop-resched_cpu-from-sending-ipis-to-offline-cpus.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com>
Date: Fri, 13 Oct 2017 16:24:28 -0700
Subject: sched: Stop resched_cpu() from sending IPIs to offline CPUs
From: "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com>
[ Upstream commit a0982dfa03efca6c239c52cabebcea4afb93ea6b ]
The rcutorture test suite occasionally provokes a splat due to invoking
resched_cpu() on an offline CPU:
WARNING: CPU: 2 PID: 8 at /home/paulmck/public_git/linux-rcu/arch/x86/kernel/smp.c:128 native_smp_send_reschedule+0x37/0x40
Modules linked in:
CPU: 2 PID: 8 Comm: rcu_preempt Not tainted 4.14.0-rc4+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
task: ffff902ede9daf00 task.stack: ffff96c50010c000
RIP: 0010:native_smp_send_reschedule+0x37/0x40
RSP: 0018:ffff96c50010fdb8 EFLAGS: 00010096
RAX: 000000000000002e RBX: ffff902edaab4680 RCX: 0000000000000003
RDX: 0000000080000003 RSI: 0000000000000000 RDI: 00000000ffffffff
RBP: ffff96c50010fdb8 R08: 0000000000000000 R09: 0000000000000001
R10: 0000000000000000 R11: 00000000299f36ae R12: 0000000000000001
R13: ffffffff9de64240 R14: 0000000000000001 R15: ffffffff9de64240
FS: 0000000000000000(0000) GS:ffff902edfc80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000f7d4c642 CR3: 000000001e0e2000 CR4: 00000000000006e0
Call Trace:
resched_curr+0x8f/0x1c0
resched_cpu+0x2c/0x40
rcu_implicit_dynticks_qs+0x152/0x220
force_qs_rnp+0x147/0x1d0
? sync_rcu_exp_select_cpus+0x450/0x450
rcu_gp_kthread+0x5a9/0x950
kthread+0x142/0x180
? force_qs_rnp+0x1d0/0x1d0
? kthread_create_on_node+0x40/0x40
ret_from_fork+0x27/0x40
Code: 14 01 0f 92 c0 84 c0 74 14 48 8b 05 14 4f f4 00 be fd 00 00 00 ff 90 a0 00 00 00 5d c3 89 fe 48 c7 c7 38 89 ca 9d e8 e5 56 08 00 <0f> ff 5d c3 0f 1f 44 00 00 8b 05 52 9e 37 02 85 c0 75 38 55 48
---[ end trace 26df9e5df4bba4ac ]---
This splat cannot be generated by expedited grace periods because they
always invoke resched_cpu() on the current CPU, which is good because
expedited grace periods require that resched_cpu() unconditionally
succeed. However, other parts of RCU can tolerate resched_cpu() acting
as a no-op, at least as long as it doesn't happen too often.
This commit therefore makes resched_cpu() invoke resched_curr() only if
the CPU is either online or is the current CPU.
Signed-off-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo(a)redhat.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/sched/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -506,7 +506,8 @@ void resched_cpu(int cpu)
unsigned long flags;
raw_spin_lock_irqsave(&rq->lock, flags);
- resched_curr(rq);
+ if (cpu_online(cpu) || cpu == smp_processor_id())
+ resched_curr(rq);
raw_spin_unlock_irqrestore(&rq->lock, flags);
}
Patches currently in stable-queue which might be from paulmck(a)linux.vnet.ibm.com are
queue-4.14/sched-stop-resched_cpu-from-sending-ipis-to-offline-cpus.patch
queue-4.14/sched-stop-switched_to_rt-from-sending-ipis-to-offline-cpus.patch
queue-4.14/locking-locktorture-fix-num-reader-writer-corner-cases.patch
queue-4.14/rcutorture-configinit-fix-build-directory-error-message.patch
This is a note to let you know that I've just added the patch titled
rtc: brcmstb-waketimer: fix error handling in brcmstb_waketmr_probe()
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rtc-brcmstb-waketimer-fix-error-handling-in-brcmstb_waketmr_probe.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
Date: Sat, 18 Nov 2017 00:15:58 +0300
Subject: rtc: brcmstb-waketimer: fix error handling in brcmstb_waketmr_probe()
From: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
[ Upstream commit f2eef045de9defbc6fc6b72b17f0941cbe26c81d ]
brcmstb_waketmr_probe() does not disable timer->clk on error paths.
Found by Linux Driver Verification project (linuxtesting.org).
Fixes: c4f07ecee22e ("rtc: brcmstb-waketimer: Add Broadcom STB wake-timer")
Signed-off-by: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/rtc/rtc-brcmstb-waketimer.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
--- a/drivers/rtc/rtc-brcmstb-waketimer.c
+++ b/drivers/rtc/rtc-brcmstb-waketimer.c
@@ -253,7 +253,7 @@ static int brcmstb_waketmr_probe(struct
ret = devm_request_irq(dev, timer->irq, brcmstb_waketmr_irq, 0,
"brcmstb-waketimer", timer);
if (ret < 0)
- return ret;
+ goto err_clk;
timer->reboot_notifier.notifier_call = brcmstb_waketmr_reboot;
register_reboot_notifier(&timer->reboot_notifier);
@@ -262,12 +262,21 @@ static int brcmstb_waketmr_probe(struct
&brcmstb_waketmr_ops, THIS_MODULE);
if (IS_ERR(timer->rtc)) {
dev_err(dev, "unable to register device\n");
- unregister_reboot_notifier(&timer->reboot_notifier);
- return PTR_ERR(timer->rtc);
+ ret = PTR_ERR(timer->rtc);
+ goto err_notifier;
}
dev_info(dev, "registered, with irq %d\n", timer->irq);
+ return 0;
+
+err_notifier:
+ unregister_reboot_notifier(&timer->reboot_notifier);
+
+err_clk:
+ if (timer->clk)
+ clk_disable_unprepare(timer->clk);
+
return ret;
}
Patches currently in stable-queue which might be from khoroshilov(a)ispras.ru are
queue-4.14/rtc-brcmstb-waketimer-fix-error-handling-in-brcmstb_waketmr_probe.patch
This is a note to let you know that I've just added the patch titled
rcutorture/configinit: Fix build directory error message
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rcutorture-configinit-fix-build-directory-error-message.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: SeongJae Park <sj38.park(a)gmail.com>
Date: Fri, 3 Nov 2017 19:17:20 +0900
Subject: rcutorture/configinit: Fix build directory error message
From: SeongJae Park <sj38.park(a)gmail.com>
[ Upstream commit 2adfa4210f8f35cdfb4e08318cc06b99752964c2 ]
The 'configinit.sh' script checks the format of optional argument for the
build directory, printing an error message if the format is not valid.
However, the error message uses the wrong variable, indicating an empty
string even though the user entered a non-empty (but erroneous) string.
This commit fixes the script to use the correct variable.
Fixes: c87b9c601ac8 ("rcutorture: Add KVM-based test framework")
Signed-off-by: SeongJae Park <sj38.park(a)gmail.com>
Signed-off-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/testing/selftests/rcutorture/bin/configinit.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/tools/testing/selftests/rcutorture/bin/configinit.sh
+++ b/tools/testing/selftests/rcutorture/bin/configinit.sh
@@ -51,7 +51,7 @@ then
mkdir $builddir
fi
else
- echo Bad build directory: \"$builddir\"
+ echo Bad build directory: \"$buildloc\"
exit 2
fi
fi
Patches currently in stable-queue which might be from sj38.park(a)gmail.com are
queue-4.14/rcutorture-configinit-fix-build-directory-error-message.patch
This is a note to let you know that I've just added the patch titled
pwm: stmpe: Fix wrong register offset for hwpwm=2 case
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pwm-stmpe-fix-wrong-register-offset-for-hwpwm-2-case.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: Axel Lin <axel.lin(a)ingics.com>
Date: Tue, 7 Nov 2017 13:18:53 +0800
Subject: pwm: stmpe: Fix wrong register offset for hwpwm=2 case
From: Axel Lin <axel.lin(a)ingics.com>
[ Upstream commit 8472b529e113e0863ea064fdee51bf73c3f86fd6 ]
Fix trivial copy/paste bug.
Signed-off-by: Axel Lin <axel.lin(a)ingics.com>
Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org>
Fixes: ef1f09eca74a ("pwm: Add a driver for the STMPE PWM")
Signed-off-by: Thierry Reding <thierry.reding(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pwm/pwm-stmpe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/pwm/pwm-stmpe.c
+++ b/drivers/pwm/pwm-stmpe.c
@@ -145,7 +145,7 @@ static int stmpe_24xx_pwm_config(struct
break;
case 2:
- offset = STMPE24XX_PWMIC1;
+ offset = STMPE24XX_PWMIC2;
break;
default:
Patches currently in stable-queue which might be from axel.lin(a)ingics.com are
queue-4.14/pwm-stmpe-fix-wrong-register-offset-for-hwpwm-2-case.patch
This is a note to let you know that I've just added the patch titled
powerpc/modules: Don't try to restore r2 after a sibling call
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
powerpc-modules-don-t-try-to-restore-r2-after-a-sibling-call.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: Josh Poimboeuf <jpoimboe(a)redhat.com>
Date: Thu, 16 Nov 2017 11:45:37 -0600
Subject: powerpc/modules: Don't try to restore r2 after a sibling call
From: Josh Poimboeuf <jpoimboe(a)redhat.com>
[ Upstream commit b9eab08d012fa093947b230f9a87257c27fb829b ]
When attempting to load a livepatch module, I got the following error:
module_64: patch_module: Expect noop after relocate, got 3c820000
The error was triggered by the following code in
unregister_netdevice_queue():
14c: 00 00 00 48 b 14c <unregister_netdevice_queue+0x14c>
14c: R_PPC64_REL24 net_set_todo
150: 00 00 82 3c addis r4,r2,0
GCC didn't insert a nop after the branch to net_set_todo() because it's
a sibling call, so it never returns. The nop isn't needed after the
branch in that case.
Signed-off-by: Josh Poimboeuf <jpoimboe(a)redhat.com>
Acked-by: Naveen N. Rao <naveen.n.rao(a)linux.vnet.ibm.com>
Reviewed-and-tested-by: Kamalesh Babulal <kamalesh(a)linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/include/asm/code-patching.h | 1 +
arch/powerpc/kernel/module_64.c | 12 +++++++++++-
arch/powerpc/lib/code-patching.c | 5 +++++
3 files changed, 17 insertions(+), 1 deletion(-)
--- a/arch/powerpc/include/asm/code-patching.h
+++ b/arch/powerpc/include/asm/code-patching.h
@@ -33,6 +33,7 @@ int patch_branch(unsigned int *addr, uns
int patch_instruction(unsigned int *addr, unsigned int instr);
int instr_is_relative_branch(unsigned int instr);
+int instr_is_relative_link_branch(unsigned int instr);
int instr_is_branch_to_addr(const unsigned int *instr, unsigned long addr);
unsigned long branch_target(const unsigned int *instr);
unsigned int translate_branch(const unsigned int *dest,
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -486,7 +486,17 @@ static bool is_early_mcount_callsite(u32
restore r2. */
static int restore_r2(u32 *instruction, struct module *me)
{
- if (is_early_mcount_callsite(instruction - 1))
+ u32 *prev_insn = instruction - 1;
+
+ if (is_early_mcount_callsite(prev_insn))
+ return 1;
+
+ /*
+ * Make sure the branch isn't a sibling call. Sibling calls aren't
+ * "link" branches and they don't return, so they don't need the r2
+ * restore afterwards.
+ */
+ if (!instr_is_relative_link_branch(*prev_insn))
return 1;
if (*instruction != PPC_INST_NOP) {
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -302,6 +302,11 @@ int instr_is_relative_branch(unsigned in
return instr_is_branch_iform(instr) || instr_is_branch_bform(instr);
}
+int instr_is_relative_link_branch(unsigned int instr)
+{
+ return instr_is_relative_branch(instr) && (instr & BRANCH_SET_LINK);
+}
+
static unsigned long branch_iform_target(const unsigned int *instr)
{
signed long imm;
Patches currently in stable-queue which might be from jpoimboe(a)redhat.com are
queue-4.14/powerpc-modules-don-t-try-to-restore-r2-after-a-sibling-call.patch
This is a note to let you know that I've just added the patch titled
powerpc/64: Don't trace irqs-off at interrupt return to soft-disabled context
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
powerpc-64-don-t-trace-irqs-off-at-interrupt-return-to-soft-disabled-context.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: Nicholas Piggin <npiggin(a)gmail.com>
Date: Fri, 17 Nov 2017 02:00:50 +1000
Subject: powerpc/64: Don't trace irqs-off at interrupt return to soft-disabled context
From: Nicholas Piggin <npiggin(a)gmail.com>
[ Upstream commit acb1feab320e38588fccc568e3767761f494976f ]
When an interrupt is returning to a soft-disabled context (which can
happen for non-maskable interrupts or synchronous interrupts), it goes
through the motions of soft-disabling again, including calling
TRACE_DISABLE_INTS (i.e., trace_hardirqs_off()).
This is not necessary, because we must already be soft-disabled in the
interrupt context, it also may be causing crashes in the irq tracing
code to re-enter as an nmi. Replace it with a warning to ensure that
soft-interrupts are still disabled.
Fixes: 7c0482e3d055 ("powerpc/irq: Fix another case of lazy IRQ state getting out of sync")
Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/kernel/entry_64.S | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -939,9 +939,13 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
beq 1f
rlwinm r7,r7,0,~PACA_IRQ_HARD_DIS
stb r7,PACAIRQHAPPENED(r13)
-1: li r0,0
- stb r0,PACASOFTIRQEN(r13);
- TRACE_DISABLE_INTS
+1:
+#if defined(CONFIG_TRACE_IRQFLAGS) && defined(CONFIG_BUG)
+ /* The interrupt should not have soft enabled. */
+ lbz r7,PACASOFTIRQEN(r13)
+1: tdnei r7,0
+ EMIT_BUG_ENTRY 1b,__FILE__,__LINE__,BUGFLAG_WARNING
+#endif
b .Ldo_restore
/*
Patches currently in stable-queue which might be from npiggin(a)gmail.com are
queue-4.14/powerpc-64-don-t-trace-irqs-off-at-interrupt-return-to-soft-disabled-context.patch
This is a note to let you know that I've just added the patch titled
power: supply: ab8500_charger: Fix an error handling path
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
power-supply-ab8500_charger-fix-an-error-handling-path.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Wed, 22 Nov 2017 21:27:31 +0100
Subject: power: supply: ab8500_charger: Fix an error handling path
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit bf59fddde1c3eab89eb8dca8f3d3dc097887d2bb ]
'ret' is know to be 0 at this point, because it has not been updated by the
the previous call to 'abx500_mask_and_set_register_interruptible()'.
Fix it by updating 'ret' before checking if an error occurred.
Fixes: 84edbeeab67c ("ab8500-charger: AB8500 charger driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Signed-off-by: Sebastian Reichel <sebastian.reichel(a)collabora.co.uk>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/power/supply/ab8500_charger.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/power/supply/ab8500_charger.c
+++ b/drivers/power/supply/ab8500_charger.c
@@ -3218,7 +3218,7 @@ static int ab8500_charger_init_hw_regist
}
/* Enable backup battery charging */
- abx500_mask_and_set_register_interruptible(di->dev,
+ ret = abx500_mask_and_set_register_interruptible(di->dev,
AB8500_RTC, AB8500_RTC_CTRL_REG,
RTC_BUP_CH_ENA, RTC_BUP_CH_ENA);
if (ret < 0)
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-4.14/power-supply-ab8500_charger-fix-an-error-handling-path.patch
queue-4.14/power-supply-ab8500_charger-bail-out-in-case-of-error-in-ab8500_charger_init_hw_registers.patch
This is a note to let you know that I've just added the patch titled
power: supply: ab8500_charger: Bail out in case of error in 'ab8500_charger_init_hw_registers()'
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
power-supply-ab8500_charger-bail-out-in-case-of-error-in-ab8500_charger_init_hw_registers.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Wed, 22 Nov 2017 21:31:20 +0100
Subject: power: supply: ab8500_charger: Bail out in case of error in 'ab8500_charger_init_hw_registers()'
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit 09edcb647542487864e23aa8d2ef26be3e08978a ]
If an error occurs when we enable the backup battery charging, we should
go through the error handling path directly.
Before commit db43e6c473b5 ("ab8500-bm: Add usb power path support") this
was the case, but this commit has added some code between the last test and
the 'out' label.
So, in case of error, this added code is executed and the error may be
silently ignored.
Fix it by adding the missing 'goto out', as done in all other error
handling paths.
Fixes: db43e6c473b5 ("ab8500-bm: Add usb power path support")
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Signed-off-by: Sebastian Reichel <sebastian.reichel(a)collabora.co.uk>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/power/supply/ab8500_charger.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/power/supply/ab8500_charger.c
+++ b/drivers/power/supply/ab8500_charger.c
@@ -3221,8 +3221,10 @@ static int ab8500_charger_init_hw_regist
ret = abx500_mask_and_set_register_interruptible(di->dev,
AB8500_RTC, AB8500_RTC_CTRL_REG,
RTC_BUP_CH_ENA, RTC_BUP_CH_ENA);
- if (ret < 0)
+ if (ret < 0) {
dev_err(di->dev, "%s mask and set failed\n", __func__);
+ goto out;
+ }
if (is_ab8540(di->parent)) {
ret = abx500_mask_and_set_register_interruptible(di->dev,
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-4.14/power-supply-ab8500_charger-fix-an-error-handling-path.patch
queue-4.14/power-supply-ab8500_charger-bail-out-in-case-of-error-in-ab8500_charger_init_hw_registers.patch
This is a note to let you know that I've just added the patch titled
pinctrl: sh-pfc: r8a7795-es1: Fix MOD_SEL1 bit[25:24] to 0x3 when using STP_ISEN_1_D
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pinctrl-sh-pfc-r8a7795-es1-fix-mod_sel1-bit-to-0x3-when-using-stp_isen_1_d.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: Takeshi Kihara <takeshi.kihara.df(a)renesas.com>
Date: Thu, 16 Nov 2017 12:16:00 +0900
Subject: pinctrl: sh-pfc: r8a7795-es1: Fix MOD_SEL1 bit[25:24] to 0x3 when using STP_ISEN_1_D
From: Takeshi Kihara <takeshi.kihara.df(a)renesas.com>
[ Upstream commit b16cd900de7911f96af17327a081a2141a0b763f ]
This patch fixes the implementation incorrect of MOD_SEL1 bit[25:24]
value when STP_ISEN_1_D pin function is selected for IPSR16 bit[27:24].
This is a correction to the incorrect implementation of MOD_SEL register
pin assignment for R8A7795 SoC specification of R-Car Gen3 Hardware
User's Manual Rev.0.51E.
Fixes: 0b0ffc96dbe30fa9 ("pinctrl: sh-pfc: Initial R8A7795 PFC support)
Signed-off-by: Takeshi Kihara <takeshi.kihara.df(a)renesas.com>
Signed-off-by: Yoshihiro Kaneko <ykaneko0929(a)gmail.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pinctrl/sh-pfc/pfc-r8a7795-es1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7795-es1.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7795-es1.c
@@ -1397,7 +1397,7 @@ static const u16 pinmux_data[] = {
PINMUX_IPSR_MSEL(IP16_27_24, AUDIO_CLKOUT_B, SEL_ADG_1),
PINMUX_IPSR_MSEL(IP16_27_24, SSI_SCK2_B, SEL_SSI_1),
PINMUX_IPSR_MSEL(IP16_27_24, TS_SDEN1_D, SEL_TSIF1_3),
- PINMUX_IPSR_MSEL(IP16_27_24, STP_ISEN_1_D, SEL_SSP1_1_2),
+ PINMUX_IPSR_MSEL(IP16_27_24, STP_ISEN_1_D, SEL_SSP1_1_3),
PINMUX_IPSR_MSEL(IP16_27_24, STP_OPWM_0_E, SEL_SSP1_0_4),
PINMUX_IPSR_MSEL(IP16_27_24, RIF3_D0_B, SEL_DRIF3_1),
PINMUX_IPSR_MSEL(IP16_27_24, TCLK2_B, SEL_TIMER_TMU_1),
Patches currently in stable-queue which might be from takeshi.kihara.df(a)renesas.com are
queue-4.14/pinctrl-sh-pfc-r8a7795-es1-fix-mod_sel1-bit-to-0x3-when-using-stp_isen_1_d.patch
This is a note to let you know that I've just added the patch titled
pinctrl: sh-pfc: r8a7791: Add can_clk function
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pinctrl-sh-pfc-r8a7791-add-can_clk-function.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: Fabrizio Castro <fabrizio.castro(a)bp.renesas.com>
Date: Tue, 14 Nov 2017 15:41:17 +0000
Subject: pinctrl: sh-pfc: r8a7791: Add can_clk function
From: Fabrizio Castro <fabrizio.castro(a)bp.renesas.com>
[ Upstream commit 57eec02caee60332b8052615e7257f932ae07abc ]
This patch adds can_clk function to r8a7743/r8a7791 which is cleaner,
and allows for independent configuration.
We keep the can_clk* pins definitions from within can0_groups and
can1_groups for uniformity and backwards compatibility.
Signed-off-by: Fabrizio Castro <fabrizio.castro(a)bp.renesas.com>
Reviewed-by: Ramesh Shanmugasundaram <ramesh.shanmugasundaram(a)bp.renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pinctrl/sh-pfc/pfc-r8a7791.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
@@ -4826,6 +4826,10 @@ static const char * const can0_groups[]
"can0_data_d",
"can0_data_e",
"can0_data_f",
+ /*
+ * Retained for backwards compatibility, use can_clk_groups in new
+ * designs.
+ */
"can_clk",
"can_clk_b",
"can_clk_c",
@@ -4837,6 +4841,21 @@ static const char * const can1_groups[]
"can1_data_b",
"can1_data_c",
"can1_data_d",
+ /*
+ * Retained for backwards compatibility, use can_clk_groups in new
+ * designs.
+ */
+ "can_clk",
+ "can_clk_b",
+ "can_clk_c",
+ "can_clk_d",
+};
+
+/*
+ * can_clk_groups allows for independent configuration, use can_clk function
+ * in new designs.
+ */
+static const char * const can_clk_groups[] = {
"can_clk",
"can_clk_b",
"can_clk_c",
@@ -5308,7 +5327,7 @@ static const char * const vin2_groups[]
};
static const struct {
- struct sh_pfc_function common[56];
+ struct sh_pfc_function common[57];
struct sh_pfc_function r8a779x[2];
} pinmux_functions = {
.common = {
@@ -5316,6 +5335,7 @@ static const struct {
SH_PFC_FUNCTION(avb),
SH_PFC_FUNCTION(can0),
SH_PFC_FUNCTION(can1),
+ SH_PFC_FUNCTION(can_clk),
SH_PFC_FUNCTION(du),
SH_PFC_FUNCTION(du0),
SH_PFC_FUNCTION(du1),
Patches currently in stable-queue which might be from fabrizio.castro(a)bp.renesas.com are
queue-4.14/pinctrl-sh-pfc-r8a7791-add-can_clk-function.patch
This is a note to let you know that I've just added the patch titled
perf annotate: Fix unnecessary memory allocation for s390x
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
perf-annotate-fix-unnecessary-memory-allocation-for-s390x.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Mar 16 15:43:17 CET 2018
From: Thomas Richter <tmricht(a)linux.vnet.ibm.com>
Date: Fri, 24 Nov 2017 10:46:37 +0100
Subject: perf annotate: Fix unnecessary memory allocation for s390x
From: Thomas Richter <tmricht(a)linux.vnet.ibm.com>
[ Upstream commit 36c263607d36c6a3788c09301d9f5fe35404048a ]
This patch fixes a bug introduced with commit d9f8dfa9baf9 ("perf
annotate s390: Implement jump types for perf annotate").
'perf annotate' displays annotated assembler output by reading output of
command objdump and parsing the disassembled lines. For each shown
mnemonic this function sequence is executed:
disasm_line__new()
|
+--> disasm_line__init_ins()
|
+--> ins__find()
|
+--> arch->associate_instruction_ops()
The s390x specific function assigned to function pointer
associate_instruction_ops refers to function s390__associate_ins_ops().
This function checks for supported mnemonics and assigns a NULL pointer
to unsupported mnemonics. However even the NULL pointer is added to the
architecture dependend instruction array.
This leads to an extremely large architecture instruction array
(due to array resize logic in function arch__grow_instructions()).
Depending on the objdump output being parsed the array can end up
with several ten-thousand elements.
This patch checks if a mnemonic is supported and only adds supported
ones into the architecture instruction array. The array does not contain
elements with NULL pointers anymore.
Before the patch (With some debug printf output):
[root@s35lp76 perf]# time ./perf annotate --stdio > /tmp/xxxbb
real 8m49.679s
user 7m13.008s
sys 0m1.649s
[root@s35lp76 perf]# fgrep '__ins__find sorted:1 nr_instructions:'
/tmp/xxxbb | tail -1
__ins__find sorted:1 nr_instructions:87433 ins:0x341583c0
[root@s35lp76 perf]#
The number of different s390x branch/jump/call/return instructions
entered into the array is 87433.
After the patch (With some printf debug output:)
[root@s35lp76 perf]# time ./perf annotate --stdio > /tmp/xxxaa
real 1m24.553s
user 0m0.587s
sys 0m1.530s
[root@s35lp76 perf]# fgrep '__ins__find sorted:1 nr_instructions:'
/tmp/xxxaa | tail -1
__ins__find sorted:1 nr_instructions:56 ins:0x3f406570
[root@s35lp76 perf]#
The number of different s390x branch/jump/call/return instructions
entered into the array is 56 which is sensible.
Signed-off-by: Thomas Richter <tmricht(a)linux.vnet.ibm.com>
Reviewed-by: Hendrik Brueckner <brueckner(a)linux.vnet.ibm.com>
Acked-by: Ravi Bangoria <ravi.bangoria(a)linux.vnet.ibm.com>
Cc: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky(a)de.ibm.com>
Link: http://lkml.kernel.org/r/20171124094637.55558-1-tmricht@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/arch/s390/annotate/instructions.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/tools/perf/arch/s390/annotate/instructions.c
+++ b/tools/perf/arch/s390/annotate/instructions.c
@@ -16,7 +16,8 @@ static struct ins_ops *s390__associate_i
if (!strcmp(name, "br"))
ops = &ret_ops;
- arch__associate_ins_ops(arch, name, ops);
+ if (ops)
+ arch__associate_ins_ops(arch, name, ops);
return ops;
}
Patches currently in stable-queue which might be from tmricht(a)linux.vnet.ibm.com are
queue-4.14/perf-annotate-fix-unnecessary-memory-allocation-for-s390x.patch
queue-4.14/perf-annotate-fix-objdump-comment-parsing-for-intel-mov-dissassembly.patch