[PATCH 02/14] perf tools: Introduce struct add_entry_iter
From: Namhyung Kim
There're some duplicate code when adding hist entries. They are
different in that some have branch info or mem info but generally do
same thing. So introduce new struct add_entry_iter and add callbacks
to customize each case in general way.
The new perf_evsel__add_entry() function will look like:
iter->prepare_entry();
iter->add_single_entry();
while (iter->next_entry())
iter->add_next_entry();
iter->finish_entry();
This will help further work like the cumulative callchain patchset.
Cc: Jiri Olsa
Cc: Stephane Eranian
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c | 435 +---
1 file changed, 284 insertions(+), 151 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index a7a8f7769629..f18cd43687d9 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -73,38 +73,74 @@ static int perf_report_config(const char *var, const char
*value, void *cb)
return perf_default_config(var, value, cb);
}
-static int perf_report__add_mem_hist_entry(struct perf_tool *tool,
- struct addr_location *al,
- struct perf_sample *sample,
- struct perf_evsel *evsel,
- struct machine *machine,
- union perf_event *event)
-{
- struct perf_report *rep = container_of(tool, struct perf_report, tool);
- struct symbol *parent = NULL;
- u8 cpumode = event->header.misc & PERF_RECORD_MISC_CPUMODE_MASK;
- int err = 0;
+struct add_entry_iter {
+ int total;
+ int curr;
+
+ struct perf_report *rep;
+ struct perf_evsel *evsel;
+ struct perf_sample *sample;
struct hist_entry *he;
- struct mem_info *mi, *mx;
- uint64_t cost;
+ struct symbol *parent;
+ void *priv;
+
+ int (*prepare_entry)(struct add_entry_iter *, struct machine *,
+struct perf_evsel *, struct addr_location *,
+struct perf_sample *);
+ int (*add_single_entry)(struct add_entry_iter *, struct addr_location
*);
+ int (*next_entry)(struct add_entry_iter *, struct addr_location *);
+ int (*add_next_entry)(struct add_entry_iter *, struct addr_location *);
+ int (*finish_entry)(struct add_entry_iter *, struct addr_location *);
+};
- if ((sort__has_parent || symbol_conf.use_callchain) &&
- sample->callchain) {
- err = machine__resolve_callchain(machine, evsel, al->thread,
-sample, &parent, al,
-rep->max_stack);
- if (err)
- return err;
- }
+static int
+iter_next_nop_entry(struct add_entry_iter *iter __maybe_unused,
+ struct addr_location *al __maybe_unused)
+{
+ return 0;
+}
+
+static int
+iter_add_next_nop_entry(struct add_entry_iter *iter __maybe_unused,
+ struct addr_location *al __maybe_unused)
+{
+ return 0;
+}
+
+static int
+iter_prepare_mem_entry(struct add_entry_iter *iter, struct machine *machine,
+ struct perf_evsel *evsel, struct addr_location *al,
+ struct perf_sample *sample)
+{
+ union perf_event *event = iter->priv;
+ struct mem_info *mi;
+ u8 cpumode;
+
+ BUG_ON(event == NULL);
+
+ cpumode = event->header.misc & PERF_RECORD_MISC_CPUMODE_MASK;
mi = machine__resolve_mem(machine, al->thread, sample, cpumode);
- if (!mi)
+ if (mi == NULL)
return -ENOMEM;
- if (rep->hide_unresolved && !al->sym)
+ iter->evsel = evsel;
+ iter->sample = sample;
+ iter->priv = mi;
+ return 0;
+}
+
+static int
+iter_add_single_mem_entry(struct add_entry_iter *iter, struct addr_location
*al)
+{
+ u64 cost;
+ struct mem_info *mi = iter->priv;
+ struct hist_entry *he;
+
+ if (iter->rep->hide_unresolved && !al->sym)
return 0;
- cost = sample->weight;
+ cost = iter->sample->weight;
if (!cost)
cost = 1;
@@ -115,11 +151,24 @@ static int perf_report__add_mem_hist_entry(struct
perf_tool *tool,
* and this is indirectly achieved by passing period=weight here
* and the he_stat__add_period() function.
*/
- he = __hists__add_entry(&evsel->hists, al, parent, NULL, mi,
+ he = __hists__add_entry(&iter->evsel->hists, al, iter->parent, NULL, mi,
cost, cost, 0);
if (!he)
return -ENOMEM;
+ iter->he = he;
+ return 0;
+}
+
+static int
+iter_finish_mem_entry(struct add_entry_iter *iter, struct addr_location *al)
+{
+ stru
[PATCH 04/14] perf hists: Add support for accumulated stat of hist entry
From: Namhyung Kim
Maintain accumulated stat information in hist_entry->stat_acc if
symbol_conf.cumulate_callchain is set. Fields in ->stat_acc have same
vaules initially, and will be updated as callchain is processed later.
Cc: Arun Sharma
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/ui/stdio/hist.c | 1 +
tools/perf/util/callchain.c | 2 ++
tools/perf/util/callchain.h | 3 ++-
tools/perf/util/hist.c | 18 ++
tools/perf/util/sort.h | 1 +
5 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/tools/perf/ui/stdio/hist.c b/tools/perf/ui/stdio/hist.c
index 6c152686e837..302f08afd6a2 100644
--- a/tools/perf/ui/stdio/hist.c
+++ b/tools/perf/ui/stdio/hist.c
@@ -283,6 +283,7 @@ static size_t hist_entry_callchain__fprintf(struct
hist_entry *he,
return callchain__fprintf_flat(fp, &he->sorted_chain,
total_samples);
break;
case CHAIN_NONE:
+ case CHAIN_CUMULATIVE:
break;
default:
pr_err("Bad callchain mode\n");
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index e3970e3eaacf..c10052c6e73c 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -52,6 +52,7 @@ rb_insert_callchain(struct rb_root *root, struct
callchain_node *chain,
p = &(*p)->rb_right;
break;
case CHAIN_NONE:
+ case CHAIN_CUMULATIVE:
default:
break;
}
@@ -162,6 +163,7 @@ int callchain_register_param(struct callchain_param *param)
param->sort = sort_chain_flat;
break;
case CHAIN_NONE:
+ case CHAIN_CUMULATIVE:
default:
return -1;
}
diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
index 7bb36022377f..08cf367c2357 100644
--- a/tools/perf/util/callchain.h
+++ b/tools/perf/util/callchain.h
@@ -11,7 +11,8 @@ enum chain_mode {
CHAIN_NONE,
CHAIN_FLAT,
CHAIN_GRAPH_ABS,
- CHAIN_GRAPH_REL
+ CHAIN_GRAPH_REL,
+ CHAIN_CUMULATIVE,
};
enum chain_order {
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 3a06b3326f12..c38655dedad3 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -238,6 +238,8 @@ static bool hists__decay_entry(struct hists *hists, struct
hist_entry *he)
return true;
hist_entry__decay(&he->stat);
+ if (callchain_param.mode == CHAIN_CUMULATIVE)
+ hist_entry__decay(he->stat_acc);
if (!he->filtered)
hists->stats.total_period -= prev_period - he->stat.period;
@@ -285,6 +287,15 @@ static struct hist_entry *hist_entry__new(struct
hist_entry *template)
if (he != NULL) {
*he = *template;
+ if (callchain_param.mode == CHAIN_CUMULATIVE) {
+ he->stat_acc = malloc(sizeof(he->stat));
+ if (he->stat_acc == NULL) {
+ free(he);
+ return NULL;
+ }
+ memcpy(he->stat_acc, &he->stat, sizeof(he->stat));
+ }
+
if (he->ms.map)
he->ms.map->referenced = true;
@@ -296,6 +307,7 @@ static struct hist_entry *hist_entry__new(struct hist_entry
*template)
*/
he->branch_info = malloc(sizeof(*he->branch_info));
if (he->branch_info == NULL) {
+ free(he->stat_acc);
free(he);
return NULL;
}
@@ -368,6 +380,8 @@ static struct hist_entry *add_hist_entry(struct hists
*hists,
if (!cmp) {
he_stat__add_period(&he->stat, period, weight);
+ if (callchain_param.mode == CHAIN_CUMULATIVE)
+ he_stat__add_period(he->stat_acc, period,
weight);
/*
* This mem info was allocated from machine__resolve_mem
@@ -404,6 +418,8 @@ static struct hist_entry *add_hist_entry(struct hists
*hists,
rb_insert_color(&he->rb_node_in, hists->entries_in);
out:
hist_entry__add_cpumode_period(&he->stat, al->cpumode, period);
+ if (callchain_param.mode == CHAIN_CUMULATIVE)
+ hist_entry__add_cpumode_period(he->stat_acc, al->cpumode,
period);
return he;
}
@@ -502,6 +518,8 @@ static bool hists__collapse_insert_entry(struct hists
*hists __maybe_unused,
if (!cmp) {
he_stat__add_stat(&iter->stat, &he->stat);
+ if (callchain_param.mode == CHAIN_CUMULATIVE)
+ he_stat__add_stat(iter->stat_acc, he->stat_acc);
i
[RFC/PATCHSET 00/14] perf report: Add support to accumulate hist periods (v2)
Hi,
This is my second attempt to implement cumulative hist period report.
This work begins from Arun's SORT_INCLUSIVE patch [1] but I completely
rewrote it from scratch.
Please see first two patches. I refactored functions that add hist
entries with struct add_entry_iter. While I converted all functions
carefully, it'd be better anyone can test and confirm that I didn't
mess up something - especially for branch stack and mem stuff.
This patchset basically adds period in a sample to every node in the
callchain. A hist_entry now has an additional fields to keep the
cumulative period if -g cumulative option is given on perf report.
Let me show you an example:
$ cat abc.c
#define barrier() asm volatile("" ::: "memory")
void a(void)
{
int i;
for (i = 0; i < 100; i++)
barrier();
}
void b(void)
{
a();
}
void c(void)
{
b();
}
int main(void)
{
c();
return 0;
}
With this simple program I ran perf record and report:
$ perf record -g -e cycles:u ./abc
$ perf report --stdio
88.29% abc abc[.] a
|
--- a
b
c
main
__libc_start_main
9.43% abc ld-2.17.so [.] _dl_relocate_object
|
--- _dl_relocate_object
dl_main
_dl_sysdep_start
2.27% abc [kernel.kallsyms] [k] page_fault
|
--- page_fault
|
|--95.94%-- _dl_sysdep_start
| _dl_start_user
|
--4.06%-- _start
0.00% abc ld-2.17.so [.] _start
|
--- _start
When the -g cumulative option is given, it'll be shown like this:
$ perf report -g cumulative --stdio
# Overhead Overhead (Acc) Command Shared Object
Symbol
# .. ... .
...
#
0.00% 88.29% abc libc-2.17.so [.] __libc_start_main
0.00% 88.29% abc abc[.] main
0.00% 88.29% abc abc[.] c
0.00% 88.29% abc abc[.] b
88.29% 88.29% abc abc[.] a
0.00% 11.61% abc ld-2.17.so [k] _dl_sysdep_start
0.00% 9.43% abc ld-2.17.so [.] dl_main
9.43% 9.43% abc ld-2.17.so [.]
_dl_relocate_object
2.27% 2.27% abc [kernel.kallsyms] [k] page_fault
0.00% 2.18% abc ld-2.17.so [k] _dl_start_user
0.00% 0.10% abc ld-2.17.so [.] _start
As you can see __libc_start_main -> main -> c -> b -> a callchain show
up in the output.
I know it have some rough edges or even bugs, but I really want to
release it and get reviews. It does not handle event groups and
annotations and it has a bug on TUI.
You can also get this series on 'perf/cumulate-v2' branch in my tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
Any comments are welcome, thanks.
Namhyung
Cc: Arun Sharma
Cc: Frederic Weisbecker
[1] https://lkml.org/lkml/2012/3/31/6
Namhyung Kim (14):
perf tools: Consolidate __hists__add_*entry()
perf tools: Introduce struct add_entry_iter
perf hists: Convert hist entry functions to use struct he_stat
perf hists: Add support for accumulated stat of hist entry
perf hists: Check if accumulated when adding a hist entry
perf hists: Accumulate hist entry stat based on the callchain
perf tools: Update cpumode for each cumulative entry
perf report: Cache cumulative callchains
perf hists: Sort hist entries by accumulated period
perf ui/hist: Add support to accumulated hist stat
perf ui/browser: Add support to accumulated hist stat
perf ui/gtk: Add support to accumulated hist stat
perf tools: Apply percent-limit to cumulative percentage
perf report: Add -g cumulative option
tools/perf/Documentation/perf-report.txt | 2 +
tools/perf/builtin-annotate.c| 3 +-
tools/perf/builtin-diff.c| 3 +-
tools/perf/builtin-report.c | 659 ---
tools/perf/builtin-top.c | 5 +-
tools/perf/tests/hists_link.c| 6 +-
tools/perf/ui/browsers/hists.c | 32 +-
tools/perf/ui/gtk/hists.c| 20 +
tools/perf/ui/hist.c | 41 ++
tools/perf/ui/stdio/hist.c | 5 +
tools/perf
[PATCH 03/14] perf hists: Convert hist entry functions to use struct he_stat
From: Namhyung Kim
hist_entry__add_cpumode_period() and hist_entry__decay() are dealing
with hist_entry's stat fields only. So make them use the struct
directly.
Cc: Arun Sharma
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/util/hist.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index e6f953190443..3a06b3326f12 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -182,21 +182,21 @@ void hists__output_recalc_col_len(struct hists *hists,
int max_rows)
}
}
-static void hist_entry__add_cpumode_period(struct hist_entry *he,
+static void hist_entry__add_cpumode_period(struct he_stat *he_stat,
unsigned int cpumode, u64 period)
{
switch (cpumode) {
case PERF_RECORD_MISC_KERNEL:
- he->stat.period_sys += period;
+ he_stat->period_sys += period;
break;
case PERF_RECORD_MISC_USER:
- he->stat.period_us += period;
+ he_stat->period_us += period;
break;
case PERF_RECORD_MISC_GUEST_KERNEL:
- he->stat.period_guest_sys += period;
+ he_stat->period_guest_sys += period;
break;
case PERF_RECORD_MISC_GUEST_USER:
- he->stat.period_guest_us += period;
+ he_stat->period_guest_us += period;
break;
default:
break;
@@ -223,10 +223,10 @@ static void he_stat__add_stat(struct he_stat *dest,
struct he_stat *src)
dest->weight+= src->weight;
}
-static void hist_entry__decay(struct hist_entry *he)
+static void hist_entry__decay(struct he_stat *he_stat)
{
- he->stat.period = (he->stat.period * 7) / 8;
- he->stat.nr_events = (he->stat.nr_events * 7) / 8;
+ he_stat->period = (he_stat->period * 7) / 8;
+ he_stat->nr_events = (he_stat->nr_events * 7) / 8;
/* XXX need decay for weight too? */
}
@@ -237,7 +237,7 @@ static bool hists__decay_entry(struct hists *hists, struct
hist_entry *he)
if (prev_period == 0)
return true;
- hist_entry__decay(he);
+ hist_entry__decay(&he->stat);
if (!he->filtered)
hists->stats.total_period -= prev_period - he->stat.period;
@@ -403,7 +403,7 @@ static struct hist_entry *add_hist_entry(struct hists
*hists,
rb_link_node(&he->rb_node_in, parent, p);
rb_insert_color(&he->rb_node_in, hists->entries_in);
out:
- hist_entry__add_cpumode_period(he, al->cpumode, period);
+ hist_entry__add_cpumode_period(&he->stat, al->cpumode, period);
return he;
}
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] openrisc: include: asm: define empty SERIAL_PORT_DFNS in serial.h
On 10/31/2013 09:54 AM, Chen Gang wrote: > For some architectures (e.g. openrisc, arc), BASE_BAUD isn't constant > And SERIAL_PORT_DFNS always use BASE_BAUND, and also all drivers use > SERIAL_PORT_DFNS to initialize static variables, statically. > > So need define SERIAL_PORT_DFNS as empty to tell drivers they don't > support SERIAL_PORT_DFNS (mostly like frv and parisc did). > > > Signed-off-by: Chen Gang > --- > arch/openrisc/include/asm/serial.h |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/openrisc/include/asm/serial.h > b/arch/openrisc/include/asm/serial.h > index 270a452..254d1ad 100644 > --- a/arch/openrisc/include/asm/serial.h > +++ b/arch/openrisc/include/asm/serial.h > @@ -31,6 +31,8 @@ > > #define BASE_BAUD (cpuinfo.clock_frequency/16) > > +#define SERIAL_PORT_DFNS > + > #endif /* __KERNEL__ */ > > #endif /* __ASM_OPENRISC_SERIAL_H */ > Oh, sorry, this patch is incorrect, need fix within the driver. Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] Read CONFIG_RD_ variables for initramfs compression
Hello Andrew,
+-- On Wed, 30 Oct 2013, Andrew Morton wrote --+
| Isn't there some convenient way of testing for the presence of an
| executable in $PATH?
|
| The shell-builtin `which' seems to dtrt:
True. Please see an updated patch attached herein.
Thank you.
--
Prasad J Pandit / Red Hat Security Response TeamFrom 352781fd2846c54e92ae0c37dd972dc5fcdfb695 Mon Sep 17 00:00:00 2001
From: P J P
Date: Thu, 31 Oct 2013 12:03:00 +0530
Subject: Read CONFIG_RD_ variables for initramfs compression
When expert configuration option(CONFIG_EXPERT) is enabled,
menuconfig offers a choice of compression algorithm to compress
initial ramfs image; This choice is stored into CONFIG_RD_*
variables. But usr/Makefile uses earlier INITRAMFS_COMPRESSION_*
macros to build initial ramfs file. Since none of them is defined,
resulting 'initramfs_data.cpio' file remains un-compressed.
This patch updates the Makefile to use CONFIG_RD_* variables and
adds support for LZ4 compression algorithm. Also updates the
'gen_initramfs_list.sh' script to check whether a selected
compression command is accessible or not. And fall-back to default
gzip(1) compression when it is not.
Signed-off-by: P J P
diff --git a/scripts/gen_initramfs_list.sh b/scripts/gen_initramfs_list.sh
index b482f16..ef47409 100644
--- a/scripts/gen_initramfs_list.sh
+++ b/scripts/gen_initramfs_list.sh
@@ -240,12 +240,24 @@ case "$arg" in
output_file="$1"
cpio_list="$(mktemp ${TMPDIR:-/tmp}/cpiolist.XX)"
output=${cpio_list}
- echo "$output_file" | grep -q "\.gz$" && compr="gzip -n -9 -f"
- echo "$output_file" | grep -q "\.bz2$" && compr="bzip2 -9 -f"
- echo "$output_file" | grep -q "\.lzma$" && compr="lzma -9 -f"
- echo "$output_file" | grep -q "\.xz$" && \
- compr="xz --check=crc32 --lzma2=dict=1MiB"
- echo "$output_file" | grep -q "\.lzo$" && compr="lzop -9 -f"
+ echo "$output_file" | grep -q "\.gz$" \
+&& [ -x "`which gzip 2> /dev/null`" ] \
+&& compr="gzip -n -9 -f"
+ echo "$output_file" | grep -q "\.bz2$" \
+&& [ -x "`which bzip2 2> /dev/null`" ] \
+&& compr="bzip2 -9 -f"
+ echo "$output_file" | grep -q "\.lzma$" \
+&& [ -x "`which lzma 2> /dev/null`" ] \
+&& compr="lzma -9 -f"
+ echo "$output_file" | grep -q "\.xz$" \
+&& [ -x "`which xz 2> /dev/null`" ] \
+&& compr="xz --check=crc32 --lzma2=dict=1MiB"
+ echo "$output_file" | grep -q "\.lzo$" \
+&& [ -x "`which lzop 2> /dev/null`" ] \
+&& compr="lzop -9 -f"
+ echo "$output_file" | grep -q "\.lz4$" \
+&& [ -x "`which lz4 2> /dev/null`" ] \
+&& compr="lz4 -9 -f"
echo "$output_file" | grep -q "\.cpio$" && compr="cat"
shift
;;
diff --git a/usr/Makefile b/usr/Makefile
index 029ffe6..e767f01 100644
--- a/usr/Makefile
+++ b/usr/Makefile
@@ -6,20 +6,23 @@ klibcdirs:;
PHONY += klibcdirs
-# Gzip
-suffix_$(CONFIG_INITRAMFS_COMPRESSION_GZIP) = .gz
-
# Bzip2
-suffix_$(CONFIG_INITRAMFS_COMPRESSION_BZIP2) = .bz2
+suffix_$(CONFIG_RD_BZIP2) = .bz2
# Lzma
-suffix_$(CONFIG_INITRAMFS_COMPRESSION_LZMA) = .lzma
+suffix_$(CONFIG_RD_LZMA) = .lzma
# XZ
-suffix_$(CONFIG_INITRAMFS_COMPRESSION_XZ) = .xz
+suffix_$(CONFIG_RD_XZ) = .xz
# Lzo
-suffix_$(CONFIG_INITRAMFS_COMPRESSION_LZO) = .lzo
+suffix_$(CONFIG_RD_LZO)= .lzo
+
+# Lz4
+suffix_$(CONFIG_RD_LZ4)= .lz4
+
+# Gzip
+suffix_$(CONFIG_RD_GZIP) = .gz
AFLAGS_initramfs_data.o +=
-DINITRAMFS_IMAGE="usr/initramfs_data.cpio$(suffix_y)"
@@ -53,7 +56,10 @@ endif
quiet_cmd_initfs = GEN $@
cmd_initfs = $(initramfs) -o $@ $(ramfs-args) $(ramfs-input)
-targets := initramfs_data.cpio.gz initramfs_data.cpio.bz2
initramfs_data.cpio.lzma initramfs_data.cpio.xz initramfs_data.cpio.lzo
initramfs_data.cpio
+targets := initramfs_data.cpio.gz initramfs_data.cpio.bz2 \
+ initramfs_data.cpio.lzma initramfs_data.cpio.xz \
+ initramfs_data.cpio.lzo initramfs_data.cpio.lz4 \
+ initramfs_data.cpio
# do not try to update files included in initramfs
$(deps_initramfs): ;
@@ -66,4 +72,3 @@ $(deps_initramfs): klibcdirs
$(obj)/initramfs_data.cpio$(suffix_y): $(obj)/gen_init_cpio $(deps_initramfs)
klibcdirs
$(Q)$(initramfs) -l $(ramfs-input) > $(obj)/.initramfs_data.cpio.d
$(call if_changed,initfs)
-
--
1.8.3.1
Re: [PATCH 12/12] EFI: Runtime services virtual mapping
On 10/30/13 at 11:45am, Borislav Petkov wrote: > On Wed, Oct 30, 2013 at 05:32:27PM +0800, Dave Young wrote: > > Boris, thanks for update, it's very elaborate, I have still wonder if > > 32 bit case should be mentioned as well. > > Ah, so that's why is mfleming bugging me about it on IRC :) > > Well, I left out the 32-bit case simply because I don't think anyone > cares about it. Ok, that's fine, thanks for telling me. > > > Waiting for you next version of the patch series. I will redo my > > patches based on that. > > Since I'm doing only minor fixups, I didn't want to spam > the lists again. > > The latest version is my 'efi' branch at > git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git > > and you can pull it from there. Just pulled your git, the function comment has not yet to be updated, so could you send me privately your new patches if you would not update in list. -- Thanks a lot! Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] dma: imx-sdma: Add sdma firmware version 2 support
On Thu, Oct 31, 2013 at 02:32:03PM +0800, Nicolin Chen wrote:
> On i.MX5/6 series, SDMA is using new version firmware to support SSI
> dual FIFO feature and HDMI Audio (i.MX6Q/DL only). Thus add it.
>
> Signed-off-by: Nicolin Chen
> ---
> diff --git a/include/linux/platform_data/dma-imx-sdma.h
> b/include/linux/platform_data/dma-imx-sdma.h
> index 3a39428..14ca582 100644
> --- a/include/linux/platform_data/dma-imx-sdma.h
> +++ b/include/linux/platform_data/dma-imx-sdma.h
> @@ -43,6 +43,9 @@ struct sdma_script_start_addrs {
> s32 dptc_dvfs_addr;
> s32 utra_addr;
> s32 ram_code_start_addr;
You could add a comment here, like: /* End of v1 array */
Otherwise:
Acked-by: Sascha Hauer
> + s32 mcu_2_ssish_addr;
> + s32 ssish_2_mcu_addr;
> + s32 hdmi_dma_addr;
> };
>
> /**
> --
> 1.8.4
>
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] Input: remove a redundant max() call.
dev->hint_events_per_packet is guaranteed to be >= packet_size.
so an extra max() call is not needed.
Signed-off-by: Kang Hu
---
drivers/input/input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/input.c b/drivers/input/input.c
index c044699..fb513da 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -2048,7 +2048,7 @@ int input_register_device(struct input_dev *dev)
if (dev->hint_events_per_packet < packet_size)
dev->hint_events_per_packet = packet_size;
- dev->max_vals = max(dev->hint_events_per_packet, packet_size) + 2;
+ dev->max_vals = dev->hint_events_per_packet + 2;
dev->vals = kcalloc(dev->max_vals, sizeof(*dev->vals), GFP_KERNEL);
if (!dev->vals) {
error = -ENOMEM;
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] PWM: atmel-pwm: add PWM controller driver
On 17:10 Mon 30 Sep , Bo Shen wrote:
> Add Atmel PWM controller driver based on PWM framework.
>
> This is the basic function implementation of Atmel PWM controller.
> It can work with PWM based led and backlight.
>
> Signed-off-by: Bo Shen
>
> ---
> Changes in v5:
> - call clk_disable directly, if so, it won't cause more than one channel
> enabled, the clock can not be disabled.
>
> Changes in v4:
> - check the return value of clk_prepare()
> - change channel register size as constant
>
> Changes in v3:
> - change compatible string from "atmel,sama5-pwm" to "atmel,sama5d3-pwm"
> - Add PWM led example in binding documentation
> - Using micro replace hard code
>
> Changes in v2:
> - Address the comments from Thierry Reding
>
> .../devicetree/bindings/pwm/atmel-pwm.txt | 41 +++
> drivers/pwm/Kconfig|9 +
> drivers/pwm/Makefile |1 +
> drivers/pwm/pwm-atmel.c| 344
>
> 4 files changed, 395 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/atmel-pwm.txt
> create mode 100644 drivers/pwm/pwm-atmel.c
>
> diff --git a/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
> b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
> new file mode 100644
> index 000..1c1a5fa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
> @@ -0,0 +1,41 @@
> +Atmel PWM controller
> +
> +Required properties:
> + - compatible: should be one of:
> +- "atmel,at91sam9rl-pwm"
> +- "atmel,sama5d3-pwm"
> + - reg: physical base address and length of the controller's registers
> + - #pwm-cells: Should be 3. See pwm.txt in this directory for a
> +description of the cells format
> +
> +Example:
> +
> + pwm0: pwm@f8034000 {
> + compatible = "atmel,at91sam9rl-pwm";
> + reg = <0xf8034000 0x400>;
> + #pwm-cells = <3>;
> + };
> +
> +The following the pwm led based example:
> +
> + pwm0: pwm@f8034000 {
> + compatible = "atmel,at91sam9rl-pwm";
> + reg = <0xf8034000 0x400>;
> + #pwm-cells = <3>;
> + };
> +
> + pwdleds {
> + compatible = "pwm-leds";
> +
> + d1 {
> + label = "d1";
> + pwms = <&pwm0 3 5000 0>
> + max-brightness = <255>;
> + };
> +
> + d2 {
> + label = "d2";
> + pwms = <&pwm0 1 5000 1>
> + max-brightness = <255>;
> + };
> + };
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 75840b5..54237b9 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -41,6 +41,15 @@ config PWM_AB8500
> To compile this driver as a module, choose M here: the module
> will be called pwm-ab8500.
>
> +config PWM_ATMEL
> + tristate "Atmel PWM support"
> + depends on ARCH_AT91
> + help
> + Generic PWM framework driver for Atmel SoC.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called pwm-atmel.
> +
> config PWM_ATMEL_TCB
> tristate "Atmel TC Block PWM support"
> depends on ATMEL_TCLIB && OF
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index 77a8c18..5b193f8 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -1,6 +1,7 @@
> obj-$(CONFIG_PWM)+= core.o
> obj-$(CONFIG_PWM_SYSFS) += sysfs.o
> obj-$(CONFIG_PWM_AB8500) += pwm-ab8500.o
> +obj-$(CONFIG_PWM_ATMEL) += pwm-atmel.o
> obj-$(CONFIG_PWM_ATMEL_TCB) += pwm-atmel-tcb.o
> obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
> obj-$(CONFIG_PWM_IMX)+= pwm-imx.o
> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> new file mode 100644
> index 000..b4df36c
> --- /dev/null
> +++ b/drivers/pwm/pwm-atmel.c
> @@ -0,0 +1,344 @@
> +/*
> + * Driver for Atmel Pulse Width Modulation Controller
> + *
> + * Copyright (C) 2013 Atmel Corporation
> + *Bo Shen
> + *
> + * Licensed under GPLv2.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* The following is global registers for PWM controller */
> +#define PWM_ENA 0x04
> +#define PWM_DIS 0x08
> +#define PWM_SR 0x0C
> +/* bit field in SR */
> +#define PWM_SR_ALL_CH_ON 0x0F
> +
> +/* The following register is PWM channel related registers */
> +#define PWM_CH_REG_OFFSET0x200
> +#define PWM_CH_REG_SIZE 0x20
> +
> +#define PWM_CMR 0x0
> +/* bit field in CMR */
> +#define PWM_CMR_CPOL (1 << 9)
> +#define PWM_CMR_UPD_CDTY (1 << 10)
> +
> +/* The following registers for PWM v1 */
> +#define PWMv1_CDTY 0x04
> +#define PWMv1_CPRD
[PATCH] arch: * : include: asm: remove empty SERIAL_PORT_DFNS in serial.h
If architectures don't support SERIAL_PORT_DFNS, they need not define it to "nothing", the related drivers need do it by themselves (e.g. 8250 serial driver). Signed-off-by: Chen Gang --- arch/frv/include/asm/serial.h|2 -- arch/parisc/include/asm/serial.h |2 -- 2 files changed, 0 insertions(+), 4 deletions(-) diff --git a/arch/frv/include/asm/serial.h b/arch/frv/include/asm/serial.h index dbb8259..658ceea 100644 --- a/arch/frv/include/asm/serial.h +++ b/arch/frv/include/asm/serial.h @@ -14,5 +14,3 @@ #define BASE_BAUD 0 #define STD_COM_FLAGS ASYNC_BOOT_AUTOCONF - -#define SERIAL_PORT_DFNS diff --git a/arch/parisc/include/asm/serial.h b/arch/parisc/include/asm/serial.h index d7e3cc6..77e9b67 100644 --- a/arch/parisc/include/asm/serial.h +++ b/arch/parisc/include/asm/serial.h @@ -6,5 +6,3 @@ * This is used for 16550-compatible UARTs */ #define BASE_BAUD ( 1843200 / 16 ) - -#define SERIAL_PORT_DFNS -- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the tty tree
Hi Greg,
After merging the tty tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/tty/serial/omap-serial.c: In function 'serial_omap_probe':
drivers/tty/serial/omap-serial.c:1724:22: error: expected ')' before numeric
constant
drivers/tty/serial/omap-serial.c:1724:22: warning: format '%d' expects a
matching 'int' argument [-Wformat]
Caused by commit e5f9bf72efbc ("serial: omap: fix a few checkpatch
warnings"). There is a missing ',' in the dev_warn() ...
I have used the version of the tty tree from next-20131030 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgptzbonWTPpT.pgp
Description: PGP signature
Re: [PATCH v5] PWM: atmel-pwm: add PWM controller driver
Hi J,
On 10/31/2013 13:42, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 17:10 Mon 30 Sep , Bo Shen wrote:
Add Atmel PWM controller driver based on PWM framework.
This is the basic function implementation of Atmel PWM controller.
It can work with PWM based led and backlight.
Signed-off-by: Bo Shen
---
Changes in v5:
- call clk_disable directly, if so, it won't cause more than one channel
enabled, the clock can not be disabled.
Changes in v4:
- check the return value of clk_prepare()
- change channel register size as constant
Changes in v3:
- change compatible string from "atmel,sama5-pwm" to "atmel,sama5d3-pwm"
- Add PWM led example in binding documentation
- Using micro replace hard code
Changes in v2:
- Address the comments from Thierry Reding
.../devicetree/bindings/pwm/atmel-pwm.txt | 41 +++
drivers/pwm/Kconfig|9 +
drivers/pwm/Makefile |1 +
drivers/pwm/pwm-atmel.c| 344
4 files changed, 395 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pwm/atmel-pwm.txt
create mode 100644 drivers/pwm/pwm-atmel.c
diff --git a/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
new file mode 100644
index 000..1c1a5fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
@@ -0,0 +1,41 @@
+Atmel PWM controller
+
+Required properties:
+ - compatible: should be one of:
+- "atmel,at91sam9rl-pwm"
+- "atmel,sama5d3-pwm"
+ - reg: physical base address and length of the controller's
+registers
+ - #pwm-cells: Should be 3. See pwm.txt in this directory for a
+description of the cells format
+
+Example:
+
+ pwm0: pwm@f8034000 {
+ compatible = "atmel,at91sam9rl-pwm";
+ reg = <0xf8034000 0x400>;
+ #pwm-cells = <3>;
+ };
+
+The following the pwm led based example:
+
+ pwm0: pwm@f8034000 {
+ compatible = "atmel,at91sam9rl-pwm";
+ reg = <0xf8034000 0x400>;
+ #pwm-cells = <3>;
+ };
+
+ pwdleds {
+ compatible = "pwm-leds";
+
+ d1 {
+ label = "d1";
+ pwms = <&pwm0 3 5000 0>
+ max-brightness = <255>;
+ };
+
+ d2 {
+ label = "d2";
+ pwms = <&pwm0 1 5000 1>
+ max-brightness = <255>;
+ };
+ };
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig index
75840b5..54237b9 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -41,6 +41,15 @@ config PWM_AB8500
To compile this driver as a module, choose M here: the module
will be called pwm-ab8500.
+config PWM_ATMEL
+ tristate "Atmel PWM support"
+ depends on ARCH_AT91
+ help
+ Generic PWM framework driver for Atmel SoC.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-atmel.
+
config PWM_ATMEL_TCB
tristate "Atmel TC Block PWM support"
depends on ATMEL_TCLIB && OF
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile index
77a8c18..5b193f8 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -1,6 +1,7 @@
obj-$(CONFIG_PWM) += core.o
obj-$(CONFIG_PWM_SYSFS) += sysfs.o
obj-$(CONFIG_PWM_AB8500) += pwm-ab8500.o
+obj-$(CONFIG_PWM_ATMEL)+= pwm-atmel.o
obj-$(CONFIG_PWM_ATMEL_TCB) += pwm-atmel-tcb.o
obj-$(CONFIG_PWM_BFIN)+= pwm-bfin.o
obj-$(CONFIG_PWM_IMX) += pwm-imx.o
diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c new
file mode 100644 index 000..b4df36c
--- /dev/null
+++ b/drivers/pwm/pwm-atmel.c
@@ -0,0 +1,344 @@
+/*
+ * Driver for Atmel Pulse Width Modulation Controller
+ *
+ * Copyright (C) 2013 Atmel Corporation
+ * Bo Shen
+ *
+ * Licensed under GPLv2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* The following is global registers for PWM controller */
+#define PWM_ENA0x04
+#define PWM_DIS0x08
+#define PWM_SR 0x0C
+/* bit field in SR */
+#define PWM_SR_ALL_CH_ON 0x0F
+
+/* The following register is PWM channel related registers */
+#define PWM_CH_REG_OFFSET 0x200
+#define PWM_CH_REG_SIZE0x20
+
+#define PWM_CMR0x0
+/* bit field in CMR */
+#define PWM_CMR_CPOL (1 << 9)
+#define PWM_CMR_UPD_CDTY (1 << 10)
+
+/* The following registers for PWM v1 */
+#define PWMv1_CDTY 0x04
+#define PWMv1_CPRD 0x08
+#define PWMv1_CUPD 0x10
+
+/* The following registers for PWM v2 */
+#define PWMv2_CDTY 0x04
+#define PWMv
Re: [PATCH] input: i8042 - add PNP modaliases
On Wed, Sep 04, 2013 at 11:27:36AM +0200, Tom Gundersen wrote: > This allows the module to be autoloaded in the common case. > > In order to work on non-PnP systems the module should be compiled in or loaded > unconditionally at boot (c.f. modules-load.d(5)), as before. > > Cc: Matthew Garrett > Cc: Dmitry Torokhov > Signed-off-by: Tom Gundersen Applied, thank you. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] dt: exynos5420: Enable support for DWC3 controller
Add device tree nodes for DWC3 controller present on
Exynos 5420 SoC, to enable support for USB 3.0.
Signed-off-by: Vivek Gautam
---
arch/arm/boot/dts/exynos5420.dtsi | 38 +++-
1 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 5df3308..4f676c1 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -236,7 +236,24 @@
status = "disabled";
};
- usbphy@1210 {
+ usb@1200 {
+ compatible = "samsung,exynos5250-dwusb3";
+ clocks = <&clock 366>;
+ clock-names = "usbdrd30";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ dwc3 {
+ compatible = "synopsys,dwc3";
+ reg = <0x1200 0x1>;
+ interrupts = <0 72 0>;
+ phys = <&usb3_phy0>;
+ phy-names = "usb3-phy";
+ };
+ };
+
+ usb3_phy0: usbphy@1210 {
compatible = "samsung,exynos5420-usb3phy";
reg = <0x1210 0x100 0x10040704 0x4>;
clocks = <&clock 366>, <&clock 1>, <&clock 152>;
@@ -244,7 +261,24 @@
#phy-cells = <0>;
};
- usbphy@1250 {
+ usb@1240 {
+ compatible = "samsung,exynos5250-dwusb3";
+ clocks = <&clock 367>;
+ clock-names = "usbdrd30";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ dwc3 {
+ compatible = "synopsys,dwc3";
+ reg = <0x1240 0x1>;
+ interrupts = <0 73 0>;
+ phys = <&usb3_phy1>;
+ phy-names = "usb3-phy";
+ };
+ };
+
+ usb3_phy1: usbphy@1250 {
compatible = "samsung,exynos5420-usb3phy";
reg = <0x1250 0x100 0x10040708 0x4>;
clocks = <&clock 367>, <&clock 1>, <&clock 153>;
--
1.7.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] dt: exynos5250: Enable support for generic USB 3.0 phy
Update device tree bindings for DWC3 controller and
USB 3.0 phy present on Exynos 5250 SoC, to start using
the phy driver based on generic phy framework.
Signed-off-by: Vivek Gautam
---
arch/arm/boot/dts/exynos5250.dtsi | 17 ++---
1 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index bbac42a..31a6595 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -472,22 +472,17 @@
compatible = "synopsys,dwc3";
reg = <0x1200 0x1>;
interrupts = <0 72 0>;
- usb-phy = <&usb2_phy &usb3_phy>;
+ phys = <&usb3_phy>;
+ phy-names = "usb3-phy";
};
};
usb3_phy: usbphy@1210 {
compatible = "samsung,exynos5250-usb3phy";
- reg = <0x1210 0x100>;
- clocks = <&clock 1>, <&clock 286>;
- clock-names = "ext_xtal", "usbdrd30";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- usbphy-sys {
- reg = <0x10040704 0x8>;
- };
+ reg = <0x1210 0x100 0x10040704 0x4>;
+ clocks = <&clock 286>, <&clock 1>;
+ clock-names = "phy", "usb3drd";
+ #phy-cells = <0>;
};
usb@1211 {
--
1.7.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] dt: exynos5420: Enable support for USB 3.0 PHY controller
Add device tree nodes for USB 3.0 PHY present alongwith
USB 3.0 controller Exynos 5420 SoC. This phy driver is
based on generic phy framework.
Signed-off-by: Vivek Gautam
---
arch/arm/boot/dts/exynos5420.dtsi | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index d537cd7..5df3308 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -235,4 +235,20 @@
io-channel-ranges;
status = "disabled";
};
+
+ usbphy@1210 {
+ compatible = "samsung,exynos5420-usb3phy";
+ reg = <0x1210 0x100 0x10040704 0x4>;
+ clocks = <&clock 366>, <&clock 1>, <&clock 152>;
+ clock-names = "phy", "usb3drd", "sclk_usbphy30";
+ #phy-cells = <0>;
+ };
+
+ usbphy@1250 {
+ compatible = "samsung,exynos5420-usb3phy";
+ reg = <0x1250 0x100 0x10040708 0x4>;
+ clocks = <&clock 367>, <&clock 1>, <&clock 153>;
+ clock-names = "phy", "usb3drd", "sclk_usbphy30";
+ #phy-cells = <0>;
+ };
};
--
1.7.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] Input: remove a redundant max() call.
On Thu, Oct 31, 2013 at 03:26:34PM +0800, Kang Hu wrote:
> dev->hint_events_per_packet is guaranteed to be >= packet_size.
> so an extra max() call is not needed.
Applied, thank you.
>
> Signed-off-by: Kang Hu
> ---
> drivers/input/input.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/input.c b/drivers/input/input.c
> index c044699..fb513da 100644
> --- a/drivers/input/input.c
> +++ b/drivers/input/input.c
> @@ -2048,7 +2048,7 @@ int input_register_device(struct input_dev *dev)
> if (dev->hint_events_per_packet < packet_size)
> dev->hint_events_per_packet = packet_size;
>
> - dev->max_vals = max(dev->hint_events_per_packet, packet_size) + 2;
> + dev->max_vals = dev->hint_events_per_packet + 2;
> dev->vals = kcalloc(dev->max_vals, sizeof(*dev->vals), GFP_KERNEL);
> if (!dev->vals) {
> error = -ENOMEM;
> --
> 1.8.3.1
>
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 0/4] Add Exynos5 USB 3.0 phy driver based on generic PHY framework
Adding a phy driver for USB 3.0 PHY controller present on Exynos5 series of SoCs alongwith DWC3 controller for USB 3.0 operations. This driver is inline with Kamil's USB 2.0 phy driver. [1] Few functions used to translate ref clock rate are common to Kamil's changes. So we can figure out how to re-use them across these drivers. Theses patches are based on usb-next branch and tested with Kishon's patches for adapting DWC3 to generic phy framework, [2] on smdk5250 as well as smdk5420 board. [1] [PATCH 0/5] phy: Add new Exynos USB PHY driver https://lkml.org/lkml/2013/10/25/230 [2] [PATCH v2 1/7] usb: dwc3: get "usb_phy" only if the platform indicates the presence of PHY's (http://www.spinics.net/lists/linux-usb/msg95733.html) [PATCH v2 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework (http://www.spinics.net/lists/linux-usb/msg95734.html) Vivek Gautam (4): phy: Add new Exynos5 USB 3.0 PHY driver dt: exynos5250: Enable support for generic USB 3.0 phy dt: exynos5420: Enable support for USB 3.0 PHY controller dt: exynos5420: Enable support for DWC3 controller .../devicetree/bindings/phy/samsung-phy.txt| 20 + arch/arm/boot/dts/exynos5250.dtsi | 17 +- arch/arm/boot/dts/exynos5420.dtsi | 50 ++ drivers/phy/Kconfig|7 + drivers/phy/Makefile |1 + drivers/phy/phy-exynos5-usb3.c | 562 6 files changed, 646 insertions(+), 11 deletions(-) create mode 100644 drivers/phy/phy-exynos5-usb3.c -- 1.7.6.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs. The new driver uses the generic PHY framework and will interact with DWC3 controller present on Exynos5 series of SoCs. Signed-off-by: Vivek Gautam --- .../devicetree/bindings/phy/samsung-phy.txt| 20 + drivers/phy/Kconfig|7 + drivers/phy/Makefile |1 + drivers/phy/phy-exynos5-usb3.c | 562 4 files changed, 590 insertions(+), 0 deletions(-) create mode 100644 drivers/phy/phy-exynos5-usb3.c diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index c0fccaa..9b5c111 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -20,3 +20,23 @@ Required properties: - compatible : should be "samsung,exynos5250-dp-video-phy"; - reg : offset and length of the Display Port PHY register set; - #phy-cells : from the generic PHY bindings, must be 0; + +Samsung Exynos5 SoC seiries USB 3.0 PHY controller +-- + +Required properties: +- compatible : + should be "samsung,exynos5250-usb3phy" for exynos5250 SoC + should be "samsung,exynos5420-usb3phy" for exynos5420 SoC +- reg : Register offset and length array + - first field corresponds to USB 3.0 PHY register set; + - second field corresponds to PHY power isolation register + present in PMU; +- clocks: Clock IDs array as required by the controller +- clock-names: names of clocks correseponding to IDs in the clock property; + Required clocks: + - first clock is main PHY clock (same as USB 3.0 controller IP clock) + - second clock is reference clock (usually crystal clock) + optional clock: + - third clock is special clock used by PHY for operation +- #phy-cells : from the generic PHY bindings, must be 0; diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index a344f3d..9a100c6 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -51,4 +51,11 @@ config PHY_EXYNOS_DP_VIDEO help Support for Display Port PHY found on Samsung EXYNOS SoCs. +config PHY_EXYNOS5_USB3 + tristate "Exynos5 SoC series USB 3.0 PHY driver" + depends on ARCH_EXYNOS5 + select GENERIC_PHY + help + Enable USB 3.0 PHY support for Exynos 5 SoC series + endmenu diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index d0caae9..9c06a61 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -7,3 +7,4 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)+= phy-exynos-mipi-video.o obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o +obj-$(CONFIG_PHY_EXYNOS5_USB3) += phy-exynos5-usb3.o diff --git a/drivers/phy/phy-exynos5-usb3.c b/drivers/phy/phy-exynos5-usb3.c new file mode 100644 index 000..b9a2674 --- /dev/null +++ b/drivers/phy/phy-exynos5-usb3.c @@ -0,0 +1,562 @@ +/* + * Samsung EXYNOS5 SoC series USB 3.0 PHY driver + * + * Copyright (C) 2013 Samsung Electronics Co., Ltd. + * Author: Vivek Gautam + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* Exynos USB PHY registers */ +#define EXYNOS5_FSEL_9MHZ6 0x0 +#define EXYNOS5_FSEL_10MHZ 0x1 +#define EXYNOS5_FSEL_12MHZ 0x2 +#define EXYNOS5_FSEL_19MHZ20x3 +#define EXYNOS5_FSEL_20MHZ 0x4 +#define EXYNOS5_FSEL_24MHZ 0x5 +#define EXYNOS5_FSEL_50MHZ 0x7 + +/* EXYNOS5: USB 3.0 DRD PHY registers */ +#define EXYNOS5_DRD_LINKSYSTEM (0x04) + +#define LINKSYSTEM_FLADJ_MASK (0x3f << 1) +#define LINKSYSTEM_FLADJ(_x) ((_x) << 1) +#define LINKSYSTEM_XHCI_VERSION_CONTROL(0x1 << 27) + +#define EXYNOS5_DRD_PHYUTMI(0x08) + +#define PHYUTMI_OTGDISABLE (0x1 << 6) +#define PHYUTMI_FORCESUSPEND (0x1 << 1) +#define PHYUTMI_FORCESLEEP (0x1 << 0) + +#define EXYNOS5_DRD_PHYPIPE(0x0c) + +#define EXYNOS5_DRD_PHYCLKRST (0x10) + +#define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23) +#define PHYCLKRST_SSC_REFCLKSEL(_x)((_x) << 23) + +#define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21) +#define PHYCLKRST_SSC_RANGE(_x)((_x) << 21) + +#define PHYCLKRST_SSC_EN (0x1 << 20) +#define PHYCLKRST_REF_SSP_EN (0x1 << 19) +#define PHYCLKRST_RE
Re: [Suggestion] arc: compiler: bug: about an arc compiler's bug which is not in gcc main source code.
Hi Chen, On 10/30/2013 07:14 AM, Chen Gang wrote: > On 10/23/2013 11:12 AM, Chen Gang wrote: >> On 10/23/2013 10:51 AM, Francois Bedard wrote: >>> Our sources are on github at >>> https://github.com/foss-for-synopsys-dwc-arc-processors and you can report >>> problems by opening "Issues" with command lines and log outputs below >>> against relevant toolchain component: >>> >>> For GCC: >>> https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/issues?state=open >>> For binutils: >>> https://github.com/foss-for-synopsys-dwc-arc-processors/binutils/issues?page=1&state=open >>> >>> >>> Go ahead and officially file these and we'll take a look at them. > Hello Francois, I marked them at 2013-10-26 night (China time). > > for gcc (3 issues, but #28 duplicates with #26): > > https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/issues/26 > https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/issues/27 > https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/issues/28 > > for binutils (1 issue): > > https://github.com/foss-for-synopsys-dwc-arc-processors/binutils/issues/21 > > > Hello Joern, for current shrinking status: > > for gcc issue #26, (#28 is its duplication): > > issue command: arc-elf32-gcc -Os -fno-reorder-blocks -c systohc.i > source code: systohc.i contents 41 lines (past it on website). > whether GNU: only for arc, gnu no issue: gnu gcc-4.8/4.9 are OK. > > for gcc issue #27: > > issue command: arc-elf32-gcc -Os -c target_core_pr.i > status:just shrinking code. >will/should be finish within 2013-10-31. >welcome any suggestions or completions. > > for binutils issue #21: > > it seems simple enough, if still need shrinking, please let me know. > > > It seems no response, and I am a newbie about the website, need I do > something more for them? (e.g. cc to some members, although I don't > know how to cc). Many thanks for all your efforts so far. Most of your patches have already been folded into ARC for 3.13. I will send out the patches for some of the cross-arch changes in next development cycle as currently I need to finish up a few things for upcoming merge window. We are actively working on toolchain issues and hopefully the fixes will make it into next formal release of tools. Please check back in few weeks. Thanks, -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -next] pinctrl: imx1: fix return value check in imx1_pinctrl_core_probe()
From: Wei Yongjun In case of error, the function devm_ioremap_nocache() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Signed-off-by: Wei Yongjun --- drivers/pinctrl/pinctrl-imx1-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/pinctrl/pinctrl-imx1-core.c b/drivers/pinctrl/pinctrl-imx1-core.c index 4d5a9e7..f77914a 100644 --- a/drivers/pinctrl/pinctrl-imx1-core.c +++ b/drivers/pinctrl/pinctrl-imx1-core.c @@ -615,8 +615,8 @@ int imx1_pinctrl_core_probe(struct platform_device *pdev, ipctl->base = devm_ioremap_nocache(&pdev->dev, res->start, resource_size(res)); - if (IS_ERR(ipctl->base)) - return PTR_ERR(ipctl->base); + if (!ipctl->base) + return -ENOMEM; pctl_desc = &imx1_pinctrl_desc; pctl_desc->name = dev_name(&pdev->dev); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] f2fs: avoid to wait all the node blocks during fsync
Previously, f2fs_sync_file() waits for all the node blocks to be written.
But, we don't need to do that, but wait only the inode-related node blocks.
This patch adds wait_on_node_pages_writeback() in which waits inode-related
node blocks that are on writeback.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/f2fs.h | 1 +
fs/f2fs/file.c | 5 +++--
fs/f2fs/node.c | 40
3 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 6aaefdb..625eb4b 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1026,6 +1026,7 @@ void get_node_info(struct f2fs_sb_info *, nid_t, struct
node_info *);
int get_dnode_of_data(struct dnode_of_data *, pgoff_t, int);
int truncate_inode_blocks(struct inode *, pgoff_t);
int truncate_xattr_node(struct inode *, struct page *);
+int wait_on_node_pages_writeback(struct f2fs_sb_info *, nid_t);
int remove_inode_page(struct inode *);
struct page *new_inode_page(struct inode *, const struct qstr *);
struct page *new_node_page(struct dnode_of_data *, unsigned int, struct page
*);
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 58ed19a..7d714f4 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -189,8 +189,9 @@ int f2fs_sync_file(struct file *file, loff_t start, loff_t
end, int datasync)
if (ret)
goto out;
}
- filemap_fdatawait_range(sbi->node_inode->i_mapping,
- 0, LONG_MAX);
+ ret = wait_on_node_pages_writeback(sbi, inode->i_ino);
+ if (ret)
+ goto out;
ret = blkdev_issue_flush(inode->i_sb->s_bdev, GFP_KERNEL, NULL);
}
out:
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 8e331d5..b527ed4 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1148,6 +1148,46 @@ continue_unlock:
return nwritten;
}
+int wait_on_node_pages_writeback(struct f2fs_sb_info *sbi, nid_t ino)
+{
+ struct address_space *mapping = sbi->node_inode->i_mapping;
+ pgoff_t index = 0, end = LONG_MAX;
+ struct pagevec pvec;
+ int nr_pages;
+ int ret2 = 0, ret = 0;
+
+ pagevec_init(&pvec, 0);
+ while ((index <= end) &&
+ (nr_pages = pagevec_lookup_tag(&pvec, mapping, &index,
+ PAGECACHE_TAG_WRITEBACK,
+ min(end - index, (pgoff_t)PAGEVEC_SIZE-1) + 1)) != 0) {
+ unsigned i;
+
+ for (i = 0; i < nr_pages; i++) {
+ struct page *page = pvec.pages[i];
+
+ /* until radix tree lookup accepts end_index */
+ if (page->index > end)
+ continue;
+
+ if (ino && ino_of_node(page) == ino)
+ wait_on_page_writeback(page);
+ if (TestClearPageError(page))
+ ret = -EIO;
+ }
+ pagevec_release(&pvec);
+ cond_resched();
+ }
+
+ if (test_and_clear_bit(AS_ENOSPC, &mapping->flags))
+ ret2 = -ENOSPC;
+ if (test_and_clear_bit(AS_EIO, &mapping->flags))
+ ret2 = -EIO;
+ if (!ret)
+ ret = ret2;
+ return ret;
+}
+
static int f2fs_write_node_page(struct page *page,
struct writeback_control *wbc)
{
--
1.8.4.474.g128a96c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/4] ASoC: fsl_ssi: Add dual fifo mode support
Hi + /* When using dual fifo mode, we need to keep watermark +* as even numbers due to dma script limitation. +*/ + ssi_private->dma_params_tx.maxburst /= 2; + ssi_private->dma_params_tx.maxburst *= 2; + ssi_private->dma_params_rx.maxburst /= 2; + ssi_private->dma_params_rx.maxburst *= 2; Why not using a mask here ? ssi_private->dma_params_tx.maxburst &= ~0x1; ssi_private->dma_params_rx.maxburst &= ~0x1; Regards, Philippe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/4] ASoC: fsl_ssi: Add dual fifo mode support
Hi, Philippe On Thu, Oct 31, 2013 at 08:54:12AM +0100, Philippe Rétornaz wrote: > Hi > > > > >+/* When using dual fifo mode, we need to keep watermark > >+ * as even numbers due to dma script limitation. > >+ */ > >+ssi_private->dma_params_tx.maxburst /= 2; > >+ssi_private->dma_params_tx.maxburst *= 2; > >+ssi_private->dma_params_rx.maxburst /= 2; > >+ssi_private->dma_params_rx.maxburst *= 2; > > > > Why not using a mask here ? > ssi_private->dma_params_tx.maxburst &= ~0x1; > ssi_private->dma_params_rx.maxburst &= ~0x1; I'll use this in v3. Thank you! Nicolin Chen > > Regards, > > Philippe > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] Input updates for 3.12-rc7
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus or master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. A bit late than I would want, but the changes are very minor - a few new device IDs for new hardware in existing drivers, fix for battery in Wacom devices not be considered system battery and cause emergency hibernations, and a couple of other bug fixes. Changelog: - Andrey Moiseev (1): Input: i8042 - i8042_flush fix for a full 8042 buffer Bastien Nocera (1): Input: wacom - export battery scope David Herrmann (1): Input: move name/timer init to input_alloc_dev() Jason Gerecke (2): Input: wacom - add support for ISDv4 0x10F sensor Input: wacom - add support for ISDv4 0x10E sensor Mike Dunn (1): Input: pxa27x_keypad - fix NULL pointer dereference Tim Gardner (1): Input: cm109 - convert high volume dev_err() to dev_err_ratelimited() Yunkang Tang (1): Input: ALPS - add support for model found on Dell XT2 Diffstat: drivers/input/input.c | 10 +- drivers/input/keyboard/pxa27x_keypad.c | 11 +-- drivers/input/misc/cm109.c | 14 ++ drivers/input/mouse/alps.c | 1 + drivers/input/serio/i8042.c| 23 ++- drivers/input/tablet/wacom_sys.c | 4 drivers/input/tablet/wacom_wac.c | 8 7 files changed, 51 insertions(+), 20 deletions(-) -- Dmitry pgpM3uK6_brji.pgp Description: PGP signature
Re: RFC: paravirtualizing perf_clock
(2013/10/30 23:03), David Ahern wrote: > On 10/29/13 11:59 PM, Masami Hiramatsu wrote: >> (2013/10/29 11:58), David Ahern wrote: >>> To back out a bit, my end goal is to be able to create and merge >>> perf-events from any context on a KVM-based host -- guest userspace, >>> guest kernel space, host userspace and host kernel space (userspace >>> events with a perf-clock timestamp is another topic ;-)). >> >> That is almost same as what we(Yoshihiro and I) are trying on integrated >> tracing, we are doing it on ftrace and trace-cmd (but perhaps, it eventually >> works on perf-ftrace). > > I thought at this point (well, once perf-ftrace gets committed) that you > can do everything with perf. What feature is missing in perf that you > get with trace-cmd or using debugfs directly? The perftools interface is the best for profiling a process or in a short period. However, what we'd like to do is monitoring or tracing in background a long period on the memory, while the system life cycle, as a flight recorder. This kind of tracing interface is required for mission-critical system for trouble shooting. Also, on-the-fly configurability of ftrace such as snapshot, multi-buffer, event-adding/removing are very useful, since in the flight-recorder use-case, we can't stop tracing for even a moment. Moreover, our guest/host integrated tracer can pass event buffers from guest to host with very small overhead, because it uses ftrace ringbuffer and virtio-serial with splice (so, zero page copying in the guest). Note that we need low overhead tracing as small as possible because it is running always in background. That's why we're using ftrace for our purpose. But anyway, the time synchronization is common issue. Let's share the solution :) >>> And then for the cherry on top a design that works across architectures >>> (e.g., x86 now, but arm later). >> >> I think your proposal is good for the default implementation, it doesn't >> depends on the arch specific feature. However, since physical timer(clock) >> interfaces and virtualization interfaces strongly depends on the arch, >> I guess the optimized implementations will become different on each arch. >> For example, maybe we can export tsc-offset to the guest to adjust clock >> on x86, but not on ARM, or other devices. In that case, until implementing >> optimized one, we can use paravirt perf_clock. > > So this MSR read takes about 1.6usecs (from 'perf stat kvm live') and > that is total time between VMEXIT and VMENTRY. The time it takes to run > perf_clock in the host should be a very small part of that 1.6 usec. Yeah, a hypercall is always heavy operation. So that is not the best solution, we need a optimized one for each arch. > I'll take a look at the TSC path to see how it is optimized (suggestions > appreciated). At least on the machine which has stable tsc, we can relay on that. We just need the tsc-offset to adjust it in the guest. Note that this offset can change if the guest sleeps/resumes or does a live-migration. Each time we need to refresh the tsc-offset. > Another thought is to make the use of pv_perf_clock an option -- user > can knowingly decide the additional latency/overhead is worth the feature. Yeah. BTW, would you see the paravirt_sched_clock(pv_time_ops)? It seems that such synchronized clock is there. Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCHSET 00/14] perf report: Add support to accumulate hist periods (v2)
* Namhyung Kim wrote: > When the -g cumulative option is given, it'll be shown like this: > > $ perf report -g cumulative --stdio > > # Overhead Overhead (Acc) Command Shared Object > Symbol > # .. ... . > ... > # >0.00% 88.29% abc libc-2.17.so [.] > __libc_start_main >0.00% 88.29% abc abc[.] main > >0.00% 88.29% abc abc[.] c > >0.00% 88.29% abc abc[.] b > > 88.29% 88.29% abc abc[.] a > >0.00% 11.61% abc ld-2.17.so [k] > _dl_sysdep_start >0.00% 9.43% abc ld-2.17.so [.] dl_main > >9.43% 9.43% abc ld-2.17.so [.] > _dl_relocate_object >2.27% 2.27% abc [kernel.kallsyms] [k] page_fault > >0.00% 2.18% abc ld-2.17.so [k] _dl_start_user > >0.00% 0.10% abc ld-2.17.so [.] _start > > > As you can see __libc_start_main -> main -> c -> b -> a callchain > show up in the output. This looks really useful! A couple of details: 1) This is pretty close to SysProf output, right? So why not use the well-known SysProf naming and call the first column 'self' and the second column 'total'? I think those names are pretty intuitive and it would help people who come from SysProf over to perf. 2) Is it possible to configure the default 'report -g' style, so that people who'd like to use it all the time don't have to type '-g cumulative' all the time? 3) I'd even argue that we enable this reporting feature by default, if a data file includes call-chain data: the first column will still show the well-known percentage that perf report produces today, the second column will be a new feature in essence. The only open question would be, by which column should we sort: 'sysprof style' sorts by 'total', 'perf style' sorts by 'self'. Agreed? 4) This is not directly related to the new feature you added: call-graph profiling still takes quite a bit of time. It might make sense to save the ordered histogram to a perf.data.ordered file, so that repeat invocations of 'perf report' don't have to recalculate everything again and again? This file would be maintained transparently and would only be re-created when the perf.data file changes, or something like that. 5) I realize that this is an early RFC, still there are some usability complaints I have about call-graph recording/reporting which should be addressed before adding new features. For example I tried to get a list of the -g output modi via: $ perf report -g help Which produced a lot of options - I think it should produce only a list of -g options. It also doesn't list cumulative: -g, --call-graph Display callchains using output_type (graph, flat, fractal, or none) , min percent threshold, optional print limit, callchain order, key (function or address). Default: fractal,0.5,callee,function Also, the list is very long and not very readable - I think there should be more newlines. Then I tried to do: $ perf report -g which, somewhat surprisingly, was accepted. Given that call-graph perf.data is recognized automatically by 'perf report', the -g option should only accept -g syntax and provide a list of options when '-g' or '-g help' is provided. 6) A similar UI problem exists on the 'perf record' side: 'perf record --call-graph help' should produce a specific list of call-graph possibilities, not the two screens full output it does today. > I know it have some rough edges or even bugs, but I really want to > release it and get reviews. It does not handle event groups and > annotations and it has a bug on TUI. > > You can also get this series on 'perf/cumulate-v2' branch in my tree at: > > git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git So I tried it out on top of tip:master, with your testcase, and in the --stdio case it works very well: # Overhead Overhead (Acc) Command Shared Object Symbol # .. ... . .. # 0.00% 100.00% abc abc[.] _start 0.00% 100.00% abc libc-2.17.so [.] __libc_start_main 0.00% 100.00% abc abc[.] main 0.00% 100.00% abc abc[.] c 0.00% 100.00% abc abc[.]
Re: [PATCH] x86: print microcode revision on PEBs errors
* Michael S. Tsirkin wrote:
> On Sandy bridge CPUs with old microcode, PEBs
> fails and suggests a microcode update.
> Print out the required and the actual revision to
> make it easier to figure out what's wrong.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> arch/x86/kernel/cpu/perf_event_intel.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
> b/arch/x86/kernel/cpu/perf_event_intel.c
> index f31a165..81f2789 100644
> --- a/arch/x86/kernel/cpu/perf_event_intel.c
> +++ b/arch/x86/kernel/cpu/perf_event_intel.c
> @@ -2105,6 +2105,8 @@ static int intel_snb_pebs_broken(int cpu)
> }
> }
>
> + pr_info("PEBS checking: microcode 0x%x min legal 0x%x\n",
> + cpu_data(cpu).microcode, rev);
That's not a very informative message though.
Something like:
"x86/perf/intel: PEBS turned off due to too old microcode version 0x%x\n"
"x86/perf/intel: Minimum required microcode version for PEBS: 0x%x\n"
would work better I think.
Also, only output this once, and only output it if the check
_fails_.
> return (cpu_data(cpu).microcode < rev);
Btw., please also fix the return statement, it doesn't need
parentheses.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the arm-soc tree with the devicetree tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-integrator/pci_v3.c between commit 16b84e5a505c ("of/irq:
Create of_irq_parse_and_map_pci() to consolidate arch code") from the
devicetree tree and commit d7057e1de8d6 ("ARM: integrator: delete
non-devicetree boot path") from the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-integrator/pci_v3.c
index a87e510fe0c4,c9c5a33bc802..
--- a/arch/arm/mach-integrator/pci_v3.c
+++ b/arch/arm/mach-integrator/pci_v3.c
@@@ -809,21 -808,22 +808,6 @@@ static u8 __init pci_v3_swizzle(struct
return pci_common_swizzle(dev, pinp);
}
- static int irq_tab[4] __initdata = {
- IRQ_AP_PCIINT0, IRQ_AP_PCIINT1, IRQ_AP_PCIINT2, IRQ_AP_PCIINT3
- };
-
- /*
- * map the specified device/slot/pin to an IRQ. This works out such
- * that slot 9 pin 1 is INT0, pin 2 is INT1, and slot 10 pin 1 is INT1.
- */
- static int __init pci_v3_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
-static int __init pci_v3_map_irq_dt(const struct pci_dev *dev, u8 slot, u8
pin)
--{
- int intnr = ((slot - 9) + (pin - 1)) & 3;
- struct of_irq oirq;
- int ret;
--
- return irq_tab[intnr];
- ret = of_irq_map_pci(dev, &oirq);
- if (ret) {
- dev_err(&dev->dev, "of_irq_map_pci() %d\n", ret);
- /* Proper return code 0 == NO_IRQ */
- return 0;
- }
-
- return irq_create_of_mapping(oirq.controller, oirq.specifier,
- oirq.size);
--}
--
static struct hw_pci pci_v3 __initdata = {
.swizzle= pci_v3_swizzle,
.setup = pci_v3_setup,
pgptXrQhLK_9t.pgp
Description: PGP signature
Re: [PATCH -tip 1/2] [BUGFIX] kprobes/x86: Prohibit probing on debug_stack_*
* Masami Hiramatsu wrote: > -int is_debug_stack(unsigned long addr) > +int __kprobes is_debug_stack(unsigned long addr) _Please_ add a __noprobes method, for new annotations. Naming it '__kprobes' is actively confusing, as it suggests that the function is somehow positively involved with kprobes support. Instead it should the noinline/notrace pattern. I complained about this before and not much happened on this front. We might not want to convert the whole kernel straight away, but for _new_ annotations there's no excuse not to name them properly. Lets phase out __kprobes, and use __noprobe from now on, okay? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/4] Add dual-fifo mode support of i.MX ssi
Changelog v3: * PATCH-1: Add comments to indicate the end of v1 and v2 array. * PATCH-3: Use better way to keep watermark as even number. * * Nothing changes for PATCH-2 and PATCH-4 v2: * Instead of adding rogue scripts to current SDMA driver based on firmware * V1, we define the new SDMA firmware as version 2 and bisect the PATCH-1 * to two patches: The first is to add version check code to the SDMA driver; * And the second is to add SSI dual FIFO DMATYPE. * * Nothing changes for the last two patches. v1: * SSI can reduce hardware overrun/underrun possibility when using dual * fifo mode. To support this mode, we need to first update sdma sciprt * list, and then enable dual fifo BIT in SSI driver, and last update DT * bindings of i.MX series. * * ! This series of patches has a direct dependency between them. When * ! applying them, we need to apply to one single branch. Otherwise, * ! it would break currect branches. Nicolin Chen (4): dma: imx-sdma: Add sdma firmware version 2 support dma: imx-sdma: Add new dma type for ssi dual fifo script ASoC: fsl_ssi: Add dual fifo mode support ARM: dts: imx: use dual-fifo sdma script for ssi .../devicetree/bindings/dma/fsl-imx-sdma.txt | 1 + arch/arm/boot/dts/imx51.dtsi | 4 ++-- arch/arm/boot/dts/imx53.dtsi | 4 ++-- arch/arm/boot/dts/imx6qdl.dtsi | 12 ++-- arch/arm/boot/dts/imx6sl.dtsi | 12 ++-- drivers/dma/imx-sdma.c | 19 ++- include/linux/platform_data/dma-imx-sdma.h | 5 + include/linux/platform_data/dma-imx.h | 1 + sound/soc/fsl/fsl_ssi.c| 22 +- 9 files changed, 62 insertions(+), 18 deletions(-) -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/4] dma: imx-sdma: Add new dma type for ssi dual fifo script
This patch adds a new DMA_TYPE for SSI dual FIFO script, included
in SDMA firmware version 2. This script would allow SSI use dual
fifo mode to transimit/receive data without occasional hardware
underrun/overrun.
Signed-off-by: Nicolin Chen
---
Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt | 1 +
drivers/dma/imx-sdma.c | 4
include/linux/platform_data/dma-imx.h | 1 +
3 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
index 4fa814d..68b83ec 100644
--- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
+++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
@@ -42,6 +42,7 @@ The full ID of peripheral types can be found below.
19 IPU Memory
20 ASRC
21 ESAI
+ 22 SSI Dual FIFO (needs firmware ver >= 2)
The third cell specifies the transfer priority as below.
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index c7ece8d..efaa9a9 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -725,6 +725,10 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
per_2_emi = sdma->script_addrs->app_2_mcu_addr;
emi_2_per = sdma->script_addrs->mcu_2_app_addr;
break;
+ case IMX_DMATYPE_SSI_DUAL:
+ per_2_emi = sdma->script_addrs->ssish_2_mcu_addr;
+ emi_2_per = sdma->script_addrs->mcu_2_ssish_addr;
+ break;
case IMX_DMATYPE_SSI_SP:
case IMX_DMATYPE_MMC:
case IMX_DMATYPE_SDHC:
diff --git a/include/linux/platform_data/dma-imx.h
b/include/linux/platform_data/dma-imx.h
index beac6b8..bcbc6c3 100644
--- a/include/linux/platform_data/dma-imx.h
+++ b/include/linux/platform_data/dma-imx.h
@@ -39,6 +39,7 @@ enum sdma_peripheral_type {
IMX_DMATYPE_IPU_MEMORY, /* IPU Memory */
IMX_DMATYPE_ASRC, /* ASRC */
IMX_DMATYPE_ESAI, /* ESAI */
+ IMX_DMATYPE_SSI_DUAL, /* SSI Dual FIFO */
};
enum imx_dma_prio {
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/4] ASoC: fsl_ssi: Add dual fifo mode support
By enabling dual fifo mode, it would allow SSI enter a better performance
to transimit/receive data without occasional hardware underrun/overrun.
[ Passed compile-test with mpc85xx_defconfig ]
Signed-off-by: Nicolin Chen
---
sound/soc/fsl/fsl_ssi.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 35e2773..51a2022 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -143,6 +143,7 @@ struct fsl_ssi_private {
bool ssi_on_imx;
bool imx_ac97;
bool use_dma;
+ bool use_dual_fifo;
struct clk *clk;
struct snd_dmaengine_dai_dma_data dma_params_tx;
struct snd_dmaengine_dai_dma_data dma_params_rx;
@@ -413,6 +414,16 @@ static int fsl_ssi_setup(struct fsl_ssi_private
*ssi_private)
write_ssi(CCSR_SSI_SOR_WAIT(3), &ssi->sor);
}
+ if (ssi_private->use_dual_fifo) {
+ write_ssi_mask(&ssi->srcr, 0, CCSR_SSI_SRCR_RFEN1);
+ write_ssi_mask(&ssi->stcr, 0, CCSR_SSI_STCR_TFEN1);
+ write_ssi_mask(&ssi->scr, 0, CCSR_SSI_SCR_TCH_EN);
+ } else {
+ write_ssi_mask(&ssi->srcr, CCSR_SSI_SRCR_RFEN1, 0);
+ write_ssi_mask(&ssi->stcr, CCSR_SSI_STCR_TFEN1, 0);
+ write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_TCH_EN, 0);
+ }
+
return 0;
}
@@ -947,7 +958,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
ssi_private->fifo_depth = 8;
if (of_device_is_compatible(pdev->dev.of_node, "fsl,imx21-ssi")) {
- u32 dma_events[2];
+ u32 dma_events[2], dmas[4];
ssi_private->ssi_on_imx = true;
ssi_private->clk = devm_clk_get(&pdev->dev, NULL);
@@ -1001,6 +1012,15 @@ static int fsl_ssi_probe(struct platform_device *pdev)
dma_events[0], shared ? IMX_DMATYPE_SSI_SP :
IMX_DMATYPE_SSI);
imx_pcm_dma_params_init_data(&ssi_private->filter_data_rx,
dma_events[1], shared ? IMX_DMATYPE_SSI_SP :
IMX_DMATYPE_SSI);
+ if (!of_property_read_u32_array(pdev->dev.of_node, "dmas",
dmas, 4)
+ && dmas[2] == IMX_DMATYPE_SSI_DUAL) {
+ ssi_private->use_dual_fifo = true;
+ /* When using dual fifo mode, we need to keep watermark
+* as even numbers due to dma script limitation.
+*/
+ ssi_private->dma_params_tx.maxburst &= ~0x1;
+ ssi_private->dma_params_rx.maxburst &= ~0x1;
+ }
} else if (ssi_private->use_dma) {
/* The 'name' should not have any slashes in it. */
ret = devm_request_irq(&pdev->dev, ssi_private->irq,
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 4/4] ARM: dts: imx: use dual-fifo sdma script for ssi
Use dual-fifo sdma scripts instead of shared scripts for ssi on i.MX series. Signed-off-by: Nicolin Chen --- arch/arm/boot/dts/imx51.dtsi | 4 ++-- arch/arm/boot/dts/imx53.dtsi | 4 ++-- arch/arm/boot/dts/imx6qdl.dtsi | 12 ++-- arch/arm/boot/dts/imx6sl.dtsi | 12 ++-- 4 files changed, 16 insertions(+), 16 deletions(-) diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi index 54cee65..1a71eac 100644 --- a/arch/arm/boot/dts/imx51.dtsi +++ b/arch/arm/boot/dts/imx51.dtsi @@ -154,8 +154,8 @@ reg = <0x70014000 0x4000>; interrupts = <30>; clocks = <&clks 49>; - dmas = <&sdma 24 1 0>, - <&sdma 25 1 0>; + dmas = <&sdma 24 22 0>, + <&sdma 25 22 0>; dma-names = "rx", "tx"; fsl,fifo-depth = <15>; fsl,ssi-dma-events = <25 24 23 22>; /* TX0 RX0 TX1 RX1 */ diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi index 4307e80..7208fde 100644 --- a/arch/arm/boot/dts/imx53.dtsi +++ b/arch/arm/boot/dts/imx53.dtsi @@ -153,8 +153,8 @@ reg = <0x50014000 0x4000>; interrupts = <30>; clocks = <&clks 49>; - dmas = <&sdma 24 1 0>, - <&sdma 25 1 0>; + dmas = <&sdma 24 22 0>, + <&sdma 25 22 0>; dma-names = "rx", "tx"; fsl,fifo-depth = <15>; fsl,ssi-dma-events = <25 24 23 22>; /* TX0 RX0 TX1 RX1 */ diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi index 57e9c38..6e096ca 100644 --- a/arch/arm/boot/dts/imx6qdl.dtsi +++ b/arch/arm/boot/dts/imx6qdl.dtsi @@ -223,8 +223,8 @@ reg = <0x02028000 0x4000>; interrupts = <0 46 0x04>; clocks = <&clks 178>; - dmas = <&sdma 37 1 0>, - <&sdma 38 1 0>; + dmas = <&sdma 37 22 0>, + <&sdma 38 22 0>; dma-names = "rx", "tx"; fsl,fifo-depth = <15>; fsl,ssi-dma-events = <38 37>; @@ -236,8 +236,8 @@ reg = <0x0202c000 0x4000>; interrupts = <0 47 0x04>; clocks = <&clks 179>; - dmas = <&sdma 41 1 0>, - <&sdma 42 1 0>; + dmas = <&sdma 41 22 0>, + <&sdma 42 22 0>; dma-names = "rx", "tx"; fsl,fifo-depth = <15>; fsl,ssi-dma-events = <42 41>; @@ -249,8 +249,8 @@ reg = <0x0203 0x4000>; interrupts = <0 48 0x04>; clocks = <&clks 180>; - dmas = <&sdma 45 1 0>, - <&sdma 46 1 0>; + dmas = <&sdma 45 22 0>, + <&sdma 46 22 0>; dma-names = "rx", "tx"; fsl,fifo-depth = <15>; fsl,ssi-dma-events = <46 45>; diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi index c46651e..b32ba99 100644 --- a/arch/arm/boot/dts/imx6sl.dtsi +++ b/arch/arm/boot/dts/imx6sl.dtsi @@ -195,8 +195,8 @@ reg = <0x02028000 0x4000>; interrupts = <0 46 0x04>; clocks = <&clks IMX6SL_CLK_SSI1>; - dmas = <&sdma 37 1 0>, - <&sdma 38 1 0>; + dmas = <&sdma 37 22 0>, + <&sdma 38 22 0>; dma-names = "rx", "tx";
linux-next: manual merge of the arm-soc tree with the devicetree tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
drivers/pci/host/pci-mvebu.c between commit 16b84e5a505c ("of/irq: Create
of_irq_parse_and_map_pci() to consolidate arch code.") from the
devicetree tree and commit e5615c30c1c9 ("PCI: mvebu: remove
subsys_initcall") from the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/pci/host/pci-mvebu.c
index 07ddb3a13c6e,80b2250ea19a..
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@@ -693,9 -732,10 +719,10 @@@ static void mvebu_pcie_enable(struct mv
hw.private_data = (void **)&pcie;
hw.setup = mvebu_pcie_setup;
hw.scan = mvebu_pcie_scan_bus;
- hw.map_irq= mvebu_pcie_map_irq;
+ hw.map_irq= of_irq_parse_and_map_pci;
hw.ops= &mvebu_pcie_ops;
hw.align_resource = mvebu_pcie_align_resource;
+ hw.add_bus= mvebu_pcie_add_bus;
pci_common_init(&hw);
}
pgp24u9KQIJ7K.pgp
Description: PGP signature
Re: [PATCH RESEND v2] Input: add driver for Neonode zForce based touchscreens
On Wed, Oct 30, 2013 at 05:18:47PM +0100, Heiko Stübner wrote: > This adds a driver for touchscreens using the zforce infrared > technology from Neonode connected via i2c to the host system. > > It supports multitouch with up to two fingers and tracking of the > contacts in hardware. Applied, thank you. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ima: define '_ima' as a builtin 'trusted' keyring
On 30/10/13 20:54, Mimi Zohar wrote:
> Require all keys added to the IMA keyring be signed by an
> existing trusted key on the system trusted keyring.
>
> Changelog:
> - define stub integrity_init_keyring() function (reported-by Fengguang Wu)
> - differentiate between regular and trusted keyring names.
> - replace printk with pr_info (D. Kasatkin)
>
> Signed-off-by: Mimi Zohar
> ---
> security/integrity/digsig.c | 30 +-
> security/integrity/ima/Kconfig| 8
> security/integrity/ima/ima_appraise.c | 11 +++
> security/integrity/integrity.h| 7 +++
> 4 files changed, 55 insertions(+), 1 deletion(-)
>
> diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
> index b4af4eb..77ca965 100644
> --- a/security/integrity/digsig.c
> +++ b/security/integrity/digsig.c
> @@ -13,7 +13,9 @@
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> #include
> +#include
> #include
> +#include
> #include
> #include
>
> @@ -21,11 +23,19 @@
>
> static struct key *keyring[INTEGRITY_KEYRING_MAX];
>
> +#ifdef CONFIG_IMA_TRUSTED_KEYRING
> +static const char *keyring_name[INTEGRITY_KEYRING_MAX] = {
> + ".evm",
> + ".module",
> + ".ima",
> +};
> +#else
> static const char *keyring_name[INTEGRITY_KEYRING_MAX] = {
> "_evm",
> "_module",
> "_ima",
> };
> +#endif
Hello,
I am not sure if having 2 different names "_" and "." makes sense.
Setting trusted-only makes sense until we will get support of setting
trusted only from user-space using keyctl...
David, do you remember our discussion in Edinburgh?
Can you provide a way to set keyring as trusted-only from user space..
Motivation...
In many embedded systems, initramfs is built into the kernel image.
Kernel image is signed and obviously initramfs as well..
Or initramfs may be signed separately like in my prototype implementation...
Note that non-x86 systems - embedded, mobile, etc has no UEFI, MOK.
Initial keys cannot be verified. (we should not rely on using kernel
modules key)
Thus keys on the protected initramfs may not be required to be signed..
It must be a way to add "initial keys" from user-space...
This is like "setting initial trust"..
This kind of functionality also useful for ".system" keyring itself.
- Dmitry
>
> int integrity_digsig_verify(const unsigned int id, const char *sig, int
> siglen,
> const char *digest, int digestlen)
> @@ -35,7 +45,7 @@ int integrity_digsig_verify(const unsigned int id, const
> char *sig, int siglen,
>
> if (!keyring[id]) {
> keyring[id] =
> - request_key(&key_type_keyring, keyring_name[id], NULL);
> + request_key(&key_type_keyring, keyring_name[id], NULL);
> if (IS_ERR(keyring[id])) {
> int err = PTR_ERR(keyring[id]);
> pr_err("no %s keyring: %d\n", keyring_name[id], err);
> @@ -56,3 +66,21 @@ int integrity_digsig_verify(const unsigned int id, const
> char *sig, int siglen,
>
> return -EOPNOTSUPP;
> }
> +
> +int integrity_init_keyring(const unsigned int id)
> +{
> + const struct cred *cred = current_cred();
> + const struct user_struct *user = cred->user;
> +
> + keyring[id] = keyring_alloc(keyring_name[id], KUIDT_INIT(0),
> + KGIDT_INIT(0), cred,
> + ((KEY_POS_ALL & ~KEY_POS_SETATTR) |
> + KEY_USR_VIEW | KEY_USR_READ),
> + KEY_ALLOC_NOT_IN_QUOTA, user->uid_keyring);
> + if (!IS_ERR(keyring[id]))
> + set_bit(KEY_FLAG_TRUSTED_ONLY, &keyring[id]->flags);
> + else
> + pr_info("Can't allocate %s keyring (%ld)\n",
> + keyring_name[id], PTR_ERR(keyring[id]));
> + return 0;
> +}
> diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> index 81a2797..dad8d4c 100644
> --- a/security/integrity/ima/Kconfig
> +++ b/security/integrity/ima/Kconfig
> @@ -123,3 +123,11 @@ config IMA_APPRAISE
> For more information on integrity appraisal refer to:
>
> If unsure, say N.
> +
> +config IMA_TRUSTED_KEYRING
> + bool "Require all keys on the _ima keyring be signed"
> + depends on IMA_APPRAISE && SYSTEM_TRUSTED_KEYRING
> + default y
> + help
> +This option requires that all keys added to the _ima
> +keyring be signed by a key on the system trusted keyring.
> diff --git a/security/integrity/ima/ima_appraise.c
> b/security/integrity/ima/ima_appraise.c
> index 734e946..46353ee 100644
> --- a/security/integrity/ima/ima_appraise.c
> +++ b/security/integrity/ima/ima_appraise.c
> @@ -381,3 +381,14 @@ int ima_inode_removexattr(struct dentry *dentry, const
> char *xattr_name)
> }
> return result;
> }
> +
> +#ifdef CONFIG_IMA_TRUSTED_KEYRING
> +static in
Re: [PATCH 0/2] KVM_SET_XCRS fixes
On Thu, Oct 17, 2013 at 04:50:45PM +0200, Paolo Bonzini wrote: > The first patch fixes bugs 63121 and 63131 (yeah, all kernel bugs > end with 1). The second patch fixes a typo (the same typo exists > in QEMU). > > Paolo Bonzini (2): > KVM: x86: fix KVM_SET_XCRS for CPUs that do not support XSAVE > KVM: x86: fix KVM_SET_XCRS loop > > arch/x86/kvm/x86.c | 15 --- > 1 file changed, 12 insertions(+), 3 deletions(-) > Reviewed-by: Gleb Natapov -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/4] dma: imx-sdma: Add sdma firmware version 2 support
On i.MX5/6 series, SDMA is using new version firmware to support SSI
dual FIFO feature and HDMI Audio (i.MX6Q/DL only). Thus add it.
Signed-off-by: Nicolin Chen
---
drivers/dma/imx-sdma.c | 15 ++-
include/linux/platform_data/dma-imx-sdma.h | 5 +
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index fc43603..c7ece8d 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -323,6 +323,7 @@ struct sdma_engine {
struct clk *clk_ipg;
struct clk *clk_ahb;
spinlock_t channel_0_lock;
+ u32 script_number;
struct sdma_script_start_addrs *script_addrs;
const struct sdma_driver_data *drvdata;
};
@@ -1238,6 +1239,7 @@ static void sdma_issue_pending(struct dma_chan *chan)
}
#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V134
+#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V238
static void sdma_add_scripts(struct sdma_engine *sdma,
const struct sdma_script_start_addrs *addr)
@@ -1246,7 +1248,7 @@ static void sdma_add_scripts(struct sdma_engine *sdma,
s32 *saddr_arr = (u32 *)sdma->script_addrs;
int i;
- for (i = 0; i < SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1; i++)
+ for (i = 0; i < sdma->script_number; i++)
if (addr_arr[i] > 0)
saddr_arr[i] = addr_arr[i];
}
@@ -1272,6 +1274,17 @@ static void sdma_load_firmware(const struct firmware
*fw, void *context)
goto err_firmware;
if (header->ram_code_start + header->ram_code_size > fw->size)
goto err_firmware;
+ switch (header->version_major) {
+ case 1:
+ sdma->script_number = SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1;
+ break;
+ case 2:
+ sdma->script_number = SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V2;
+ break;
+ default:
+ dev_err(sdma->dev, "unknown firmware version\n");
+ return;
+ }
addr = (void *)header + header->script_addrs_start;
ram_code = (void *)header + header->ram_code_start;
diff --git a/include/linux/platform_data/dma-imx-sdma.h
b/include/linux/platform_data/dma-imx-sdma.h
index 3a39428..eabac4e 100644
--- a/include/linux/platform_data/dma-imx-sdma.h
+++ b/include/linux/platform_data/dma-imx-sdma.h
@@ -43,6 +43,11 @@ struct sdma_script_start_addrs {
s32 dptc_dvfs_addr;
s32 utra_addr;
s32 ram_code_start_addr;
+ /* End of v1 array */
+ s32 mcu_2_ssish_addr;
+ s32 ssish_2_mcu_addr;
+ s32 hdmi_dma_addr;
+ /* End of v2 array */
};
/**
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] drivers: phy: Fix memory leak
Hi,
On Friday 25 October 2013 10:56 AM, Sachin Kamat wrote:
> 'phy' was not being freed upon error in one of the cases.
> Adjust the 'goto's to fix this.
This patch looks good. I'll send this once -rc1 is tagged?
Thanks
Kishon
>
> Signed-off-by: Sachin Kamat
> ---
> drivers/phy/phy-core.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index 03cf8fb..712b358 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -453,7 +453,7 @@ struct phy *phy_create(struct device *dev, const struct
> phy_ops *ops,
> if (id < 0) {
> dev_err(dev, "unable to get id\n");
> ret = id;
> - goto err0;
> + goto err1;
> }
>
> device_initialize(&phy->dev);
> @@ -468,11 +468,11 @@ struct phy *phy_create(struct device *dev, const struct
> phy_ops *ops,
>
> ret = dev_set_name(&phy->dev, "phy-%s.%d", dev_name(dev), id);
> if (ret)
> - goto err1;
> + goto err2;
>
> ret = device_add(&phy->dev);
> if (ret)
> - goto err1;
> + goto err2;
>
> if (pm_runtime_enabled(dev)) {
> pm_runtime_enable(&phy->dev);
> @@ -481,11 +481,11 @@ struct phy *phy_create(struct device *dev, const struct
> phy_ops *ops,
>
> return phy;
>
> -err1:
> +err2:
> ida_remove(&phy_ida, phy->id);
> put_device(&phy->dev);
> +err1:
> kfree(phy);
> -
> err0:
> return ERR_PTR(ret);
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Move drivers/acpi/apei/cper.c to drivers/firmware/efi/
* Luck, Tony wrote:
> The following changes since commit 56507694de3453076d73e0e9813349586ee67e59:
>
> EDAC, GHES: Update ghes error record info (2013-10-23 10:11:00 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git
> tags/please-pull-move-cper
>
> for you to fetch changes up to c57a801195153e111bcd712680a718cf101b6d1f:
>
> Move cper.c from drivers/acpi/apei to drivers/firmware/efi (2013-10-29
> 09:23:38 -0700)
>
>
> cper.c implements UEFI Appendix N "Common Platform Error Record"
> handling. Move it to drivers/firmware/efi/cper.c to reflect this
> heritage.
>
>
> Tony Luck (1):
> Move cper.c from drivers/acpi/apei to drivers/firmware/efi
>
> drivers/acpi/Kconfig | 4 +++-
> drivers/acpi/apei/Kconfig | 2 ++
> drivers/acpi/apei/Makefile | 2 +-
> drivers/firmware/efi/Kconfig | 3 +++
> drivers/firmware/efi/Makefile | 1 +
> drivers/{acpi/apei => firmware/efi}/cper.c | 0
> 6 files changed, 10 insertions(+), 2 deletions(-)
> rename drivers/{acpi/apei => firmware/efi}/cper.c (100%)
Pulled, thanks Tony!
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] drivers: phy: Fix memory leak
On 31 October 2013 14:16, Kishon Vijay Abraham I wrote: > Hi, > > On Friday 25 October 2013 10:56 AM, Sachin Kamat wrote: >> 'phy' was not being freed upon error in one of the cases. >> Adjust the 'goto's to fix this. > > This patch looks good. I'll send this once -rc1 is tagged? Sure. Thanks. -- With warm regards, Sachin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] tools/perf/build: Fix detection of non-core features
* Jiri Olsa wrote: > On Tue, Oct 29, 2013 at 10:43:15AM -0600, David Ahern wrote: > > feature_check needs to be invoked through call, and LDFLAGS may not be set > > so quotes are needed. > > and the problem is also when there's more than one option in LDFLAGS yeah. > > Thanks to Jiri for spotting the quotes around LDFLAGS; that one was driving > > me nuts with the upcoming timerfd feature detection. > > > > Signed-off-by: David Ahern > > Cc: Ingo Molnar > > Cc: Peter Zijlstra > > Cc: Namhyung Kim > > Cc: Jiri Olsa > > Reviewed-and-tested-by: Jiri Olsa Acked-by: Ingo Molnar Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Suggestion] arc: compiler: bug: about an arc compiler's bug which is not in gcc main source code.
On 10/31/2013 03:48 PM, Vineet Gupta wrote:
> Hi Chen,
>
> Many thanks for all your efforts so far.
>
Since I need provide contribution to Public Open Source, so what I have
done is what I should do. :-)
In fact, I really need improve myself: e.g. how to make negative effect
lowest (e.g. how to let more members pleased with what I have done), how
to improve efficiency (make my waste mail lower) ...
> Most of your patches have already been folded into ARC for 3.13. I will send
> out
> the patches for some of the cross-arch changes in next development cycle as
> currently I need to finish up a few things for upcoming merge window.
>
OK, thanks.
> We are actively working on toolchain issues and hopefully the fixes will make
> it
> into next formal release of tools. Please check back in few weeks.
>
OK, I will/should focus.
And for gcc issue #27, I shrank the demo source file is about 1K lines
(shrank from 50K lines to 1K lines), although it is still a big file
which can be shrunk more.
And excuse me, I don't know how to past this file on this website, so I
load it as attachment, please check.
Thanks.
--
Chen Gang
typedef char __s8;
typedef unsigned char __u8;
typedef short __s16;
typedef unsigned short __u16;
typedef int __s32;
typedef unsigned int __u32;
typedef long long __s64;
typedef unsigned long long __u64;
typedef signed char s8;
typedef unsigned char u8;
typedef signed short s16;
typedef unsigned short u16;
typedef signed int s32;
typedef unsigned int u32;
typedef signed long long s64;
typedef unsigned long long u64;
enum {
false = 0,
true = 1
};
typedef struct {
unsigned long fds_bits[1024 / (8 * sizeof(long))];
} __kernel_fd_set;
typedef void (*__kernel_sighandler_t)(int);
typedef int __kernel_key_t;
typedef int __kernel_mqd_t;
typedef long __kernel_long_t;
typedef unsigned long __kernel_ulong_t;
typedef __kernel_ulong_t __kernel_ino_t;
typedef unsigned int __kernel_mode_t;
typedef int __kernel_pid_t;
typedef int __kernel_ipc_pid_t;
typedef unsigned int __kernel_uid_t;
typedef unsigned int __kernel_gid_t;
typedef __kernel_long_t __kernel_suseconds_t;
typedef int __kernel_daddr_t;
typedef unsigned int __kernel_uid32_t;
typedef unsigned int __kernel_gid32_t;
typedef __kernel_uid_t __kernel_old_uid_t;
typedef __kernel_gid_t __kernel_old_gid_t;
typedef unsigned int __kernel_old_dev_t;
typedef unsigned int __kernel_size_t;
typedef int __kernel_ssize_t;
typedef int __kernel_ptrdiff_t;
typedef struct {
int val[2];
} __kernel_fsid_t;
typedef __kernel_long_t __kernel_off_t;
typedef long long __kernel_loff_t;
typedef __kernel_long_t __kernel_time_t;
typedef __kernel_long_t __kernel_clock_t;
typedef int __kernel_timer_t;
typedef int __kernel_clockid_t;
typedef char * __kernel_caddr_t;
typedef unsigned short __kernel_uid16_t;
typedef unsigned short __kernel_gid16_t;
typedef __u16 __le16;
typedef __u16 __be16;
typedef __u32 __le32;
typedef __u32 __be32;
typedef __u64 __le64;
typedef __u64 __be64;
typedef __u16 __sum16;
typedef __u32 __wsum;
typedef __u32 __kernel_dev_t;
typedef __kernel_fd_set fd_set;
typedef __kernel_dev_t dev_t;
typedef __kernel_ino_t ino_t;
typedef __kernel_mode_t mode_t;
typedef unsigned short umode_t;
typedef __u32 nlink_t;
typedef __kernel_off_t off_t;
typedef __kernel_pid_t pid_t;
typedef __kernel_daddr_t daddr_t;
typedef __kernel_key_t key_t;
typedef __kernel_suseconds_t suseconds_t;
typedef __kernel_timer_t timer_t;
typedef __kernel_clockid_t clockid_t;
typedef __kernel_mqd_t mqd_t;
typedef _Bool bool;
typedef __kernel_uid32_t uid_t;
typedef __kernel_gid32_t gid_t;
typedef __kernel_uid16_t uid16_t;
typedef __kernel_gid16_t gid16_t;
typedef unsigned long uintptr_t;
typedef __kernel_loff_t loff_t;
typedef __kernel_size_t size_t;
typedef __kernel_ssize_t ssize_t;
typedef __kernel_ptrdiff_t ptrdiff_t;
typedef __kernel_time_t time_t;
typedef __kernel_clock_t clock_t;
typedef __kernel_caddr_t caddr_t;
typedef unsigned char u_char;
typedef unsigned short u_short;
typedef unsigned int u_int;
typedef unsigned long u_long;
typedef unsigned char unchar;
typedef unsigned short ushort;
typedef unsigned int uint;
typedef unsigned long ulong;
typedef __u8 u_int8_t;
typedef __s8 int8_t;
typedef __u16 u_int16_t;
typedef __s16 int16_t;
typedef __u32 u_int32_t;
typedef __s32 int32_t;
typedef __u8 uint8_t;
typedef __u16 uint16_t;
typedef __u32 uint32_t;
typedef __u64 uint64_t;
typedef __u64 u_int64_t;
typedef __s64 int64_t;
typedef u64 sector_t;
typedef u64 blkcnt_t;
typedef u32 dma_addr_t;
typedef unsigned gfp_t;
typedef unsigned fmode_t;
typedef unsigned oom_flags_t;
typedef u32 phys_addr_t;
typedef phys_addr_t resource_size_t;
typedef unsigned long irq_hw_number_t;
typedef struct {
int counter;
} atomic_t;
struct list_head {
struct list_head *next, *prev;
};
typedef struct {
volatile unsigned int slock;
} arch_spinlock_t;
typedef struct raw_spinlock {
arch_spinlock_t raw_lock;
unsigned int magic, owner_cpu;
void *owner;
} raw_spinlock_t;
typedef struct spinlock {
union {
s
Re: [PATCH] net/cdc_ncm: fix null pointer panic at usbnet_link_change
"Du, ChangbinX" writes:
>> From: Bjørn Mork [mailto:bj...@mork.no]
>> Sent: Tuesday, October 29, 2013 4:41 PM
>> To: Du, ChangbinX
>> Cc: oli...@neukum.org; linux-...@vger.kernel.org; net...@vger.kernel.org;
>> linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH] net/cdc_ncm: fix null pointer panic at
>> usbnet_link_change
>>
>> "Du, ChangbinX" writes:
>>
>> > From: "Du, Changbin"
>> >
>> > In cdc_ncm_bind() function, it call cdc_ncm_bind_common() to setup usb.
>> > But cdc_ncm_bind_common() may meet error and cause usbnet_disconnect()
>> > be called which calls free_netdev(net).
>>
>> I am sure you are right, but I really don't see how that can happen.
>>
>> AFAICS, we ensure that the intfdata is set to NULL before calling
>> usb_driver_release_interface() in the error cleanup in
>> cdc_ncm_bind_common():
>>
>>
>> error2:
>> usb_set_intfdata(ctx->control, NULL);
>> usb_set_intfdata(ctx->data, NULL);
>> if (ctx->data != ctx->control)
>> usb_driver_release_interface(driver, ctx->data);
>> error:
>> cdc_ncm_free((struct cdc_ncm_ctx *)dev->data[0]);
>> dev->data[0] = 0;
>> dev_info(&dev->udev->dev, "bind() failure\n");
>> return -ENODEV;
>>
>>
>> Thus we hit the test in disconnect, and usbnet_disconnect() is never
>> called:
>>
>> static void cdc_ncm_disconnect(struct usb_interface *intf)
>> {
>> struct usbnet *dev = usb_get_intfdata(intf);
>>
>> if (dev == NULL)
>> return; /* already disconnected */
>>
>> usbnet_disconnect(intf);
>> }
>>
>> So we should really be OK, but we are not I would appreciate it if
>> anyone took the time to feed me why, with a very small spoon...
>>
>
> Yes, you are right. It should not happen if cdc_ncm_disconnect is not
> called. But this really happened. It produced on kernel 3.10.
Yes, I do not doubt it. I just don't understand it. There is no
contradiction there. I believe lots of stuff I don't understand :-)
The version this happened is very useful, although I don't think there
are any relevant changes after v3.10.
> Here is the full panic message for you to refer. I will get a method try to
> reproduce it.
That would be great if you were able to. Otherwise it will be difficult
to verify that the proposed fix works.
In any case, as I said: I believe a fix which avoids the call to
usbnet_link_change() in case of bind failure is correct and
appropriate. But I suggest that you do it by removing the call and
comment from cdc_ncm_bind() and instead set the FLAG_LINK_INTR in the
driver_info. That's how this should have been implemented from the
beginning.
> [ 15.635727] BUG: Bad page state in process khubd pfn:31994
> [ 15.641989] page:f3ad9280 count:0 mapcount:0 mapping:0020 index:0x0
> [ 15.649384] page flags: 0x4000()
> [ 15.670096] BUG: unable to handle kernel NULL pointer dereference at
> 0078
> [ 15.678078] IP: [] usbnet_link_change+0x1e/0x80
> [ 15.684120] *pde =
> [ 15.687339] Oops: [#1] SMP
> [ 15.690953] Modules linked in: atmel_mxt_ts vxd392 videobuf_vmalloc
> videobuf_core bcm_bt_lpm bcm432)
> [ 15.702658] CPU: 0 PID: 573 Comm: khubd Tainted: GB W O 3.10.1+ #1
> [ 15.710241] task: f27e8f30 ti: f2084000 task.ti: f2084000
> [ 15.716270] EIP: 0060:[] EFLAGS: 00010246 CPU: 0
> [ 15.722396] EIP is at usbnet_link_change+0x1e/0x80
> [ 15.727747] EAX: f18524c0 EBX: ECX: f18524c0 EDX:
> [ 15.734746] ESI: f18524c0 EDI: EBP: f2085b7c ESP: f2085b70
> [ 15.741746] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068
> [ 15.747775] CR0: 8005003b CR2: 0078 CR3: 02c3b000 CR4: 001007d0
> [ 15.754774] DR0: DR1: DR2: DR3:
> [ 15.761774] DR6: 0ff0 DR7: 0400
> [ 15.766054] Stack:
> [ 15.768295] f18524c0 c2a03818 f2085b8c c24bc69a f1852000
> f1f52e00 f2085be0
> [ 15.776991] c24b8d32 0001 c2167f2c f2085bb4
> c2821253 f2085bec
> [ 15.785687] 0246 0246 f18d8088 f1f52e1c f1fce464 f1fce400
> f18524c0 c28a06e0
> [ 15.794376] Call Trace:
> [ 15.797109] [] cdc_ncm_bind+0x3a/0x50
> [ 15.802267] [] usbnet_probe+0x282/0x7d0
> [ 15.807621] [] ? sysfs_new_dirent+0x6c/0x100
> [ 15.813460] [] ? mutex_lock+0x13/0x40
> [ 15.818618] [] cdc_ncm_probe+0x8/0x10
> [ 15.823777] [] usb_probe_interface+0x187/0x2c0
I still do not understand how this happens, but usbnet_link_change will
schedule some delayed work which absolutely is not appropriate if
usbnet_probe fails. There are no cancel_work calls in the usbnet_probe
exit path
So the call should definitely be avoided if bind fails.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: perf events ring buffer memory barrier on powerpc
On Wed, Oct 30, 2013 at 09:32:58PM -0700, Paul E. McKenney wrote: > Before C/C++11, the closest thing to such a prohibition is use of > volatile, for example, ACCESS_ONCE(). Even in C/C++11, you have to > use atomics to get anything resembing this prohibition. > > If you just use normal variables, the compiler is within its rights > to transform something like the following: > > if (a) > b = 1; > else > b = 42; > > Into: > > b = 42; > if (a) > b = 1; > > Many other similar transformations are permitted. Some are used to all > vector instructions to be used -- the compiler can do a write with an > overly wide vector instruction, then clean up the clobbered variables > later, if it wishes. Again, if the variables are not marked volatile, > or, in C/C++11, atomic. While I've heard you tell this story before, my mind keeps boggling how we've been able to use shared memory at all, all these years. It seems to me stuff should have broken left, right and center if compilers were really aggressive about this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers: w1: make w1_slave::flags long to avoid casts
On Wed, Oct 30 2013, Andrew Morton wrote: > On Sat, 26 Oct 2013 12:56:11 +0100 Michal Nazarewicz wrote: > >> From: Michal Nazarewicz >> >> Changing flags field of the w1_slave to unsigned long may on >> some architectures increase the size of the structure, but >> otherwise makes the code more kosher as casting is avoided >> and *_bit family of calls do not attempt to operate on an >> entity of bigger size than realy is available. >> >> The current behaviour does not introduce any bugs (since any >> bytes past flags field are preserved) > > hm, what does this mean > >> --- a/drivers/w1/w1.c >> +++ b/drivers/w1/w1.c >> @@ -709,7 +709,7 @@ static int w1_attach_slave_device(struct w1_master *dev, >> struct w1_reg_num *rn) >> >> sl->owner = THIS_MODULE; >> sl->master = dev; >> -set_bit(W1_SLAVE_ACTIVE, (long *)&sl->flags); >> +set_bit(W1_SLAVE_ACTIVE, &sl->flags); > > ... I'd have though that running this code on little-endian 64-bit > would result in a scribble over ... > >> --- a/drivers/w1/w1.h >> +++ b/drivers/w1/w1.h >> @@ -67,8 +67,8 @@ struct w1_slave >> struct w1_reg_num reg_num; >> atomic_trefcnt; >> u8 rom[9]; >> -u32 flags; >> int ttl; > > ... w1_slave.ttl? Now that I look at documentation, I think you are correct, but the problem is on big-endian 64-bit architectures. The fix is still valid, but the commit message not so much. Something along the lines of the following would be better: >8 drivers: w1: make w1_slave::flags long to avoid memory corruption On architectures where long is more then 32 bits, modifying a 32-bit field with set_bit (and other atomic bit operations) may cause bytes following the field to by modified. Because the endianness of the bits within a field is the native endianness of the CPU[1], on big-endian machines, bit number zero is in the last byte of the field. Therefore, “set_bit(0, ptr)” on a 64-bit big-endian machine is roughly equivalent to “((char *)ptr)[7] |= 1”, and since w1 driver uses a 32-bit field for holding the flags, this causes bytes beyond the field to be modified. [1] From Documentation/atomic_ops.txt: Native atomic bit operations are defined to operate on objects aligned to the size of an "unsigned long" C data type, and are least of that size. The endianness of the bits within each "unsigned long" are the native endianness of the cpu. >8 >> +unsigned long flags; >> >> struct w1_master*master; >> struct w1_family*family; -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +--ooO--(_)--Ooo-- signature.asc Description: PGP signature
[PATCH][RESEND] lib/genalloc: add a helper function for DMA buffer allocation
When using pool space for DMA buffer, there might be duplicated calling
of gen_pool_alloc() and gen_pool_virt_to_phys() in each implementation.
Thus it's better to add a simple helper function, a compatible one to
the common dma_alloc_coherent(), to save some code.
Signed-off-by: Nicolin Chen
---
include/linux/genalloc.h | 2 ++
lib/genalloc.c | 28
2 files changed, 30 insertions(+)
diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index f8d41cb..1eda33d 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -94,6 +94,8 @@ static inline int gen_pool_add(struct gen_pool *pool,
unsigned long addr,
}
extern void gen_pool_destroy(struct gen_pool *);
extern unsigned long gen_pool_alloc(struct gen_pool *, size_t);
+extern void *gen_pool_dma_alloc(struct gen_pool *pool, size_t size,
+ dma_addr_t *dma);
extern void gen_pool_free(struct gen_pool *, unsigned long, size_t);
extern void gen_pool_for_each_chunk(struct gen_pool *,
void (*)(struct gen_pool *, struct gen_pool_chunk *, void *), void *);
diff --git a/lib/genalloc.c b/lib/genalloc.c
index 26cf20b..dda3116 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -313,6 +313,34 @@ retry:
EXPORT_SYMBOL(gen_pool_alloc);
/**
+ * gen_pool_dma_alloc - allocate special memory from the pool for DMA usage
+ * @pool: pool to allocate from
+ * @size: number of bytes to allocate from the pool
+ * @dma: dma-view physical address
+ *
+ * Allocate the requested number of bytes from the specified pool.
+ * Uses the pool allocation function (with first-fit algorithm by default).
+ * Can not be used in NMI handler on architectures without
+ * NMI-safe cmpxchg implementation.
+ */
+void *gen_pool_dma_alloc(struct gen_pool *pool, size_t size, dma_addr_t *dma)
+{
+ unsigned long vaddr;
+
+ if (!pool)
+ return NULL;
+
+ vaddr = gen_pool_alloc(pool, size);
+ if (!vaddr)
+ return NULL;
+
+ *dma = gen_pool_virt_to_phys(pool, vaddr);
+
+ return (void *)vaddr;
+}
+EXPORT_SYMBOL(gen_pool_dma_alloc);
+
+/**
* gen_pool_free - free allocated special memory back to the pool
* @pool: pool to free to
* @addr: starting address of memory to free back to pool
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] IOMMU/trivial: Use for_each_drhd_unit() instead of list_for_each_entry()
Use for_each_drhd_unit() instead of list_for_each_entry for
better readability.
Signed-off-by: Yijing Wang
---
drivers/iommu/dmar.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 785675a..da2d0d9 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -403,7 +403,7 @@ dmar_find_matched_drhd_unit(struct pci_dev *dev)
dev = pci_physfn(dev);
- list_for_each_entry(dmaru, &dmar_drhd_units, list) {
+ for_each_drhd_unit(dmaru) {
drhd = container_of(dmaru->hdr,
struct acpi_dmar_hardware_unit,
header);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] IOMMU: Use list_for_each_entry_safe() for dmar_domain->devices traversal
Replace list_for_each_safe() + list_entry() with the simpler
list_for_each_entry_safe().
Signed-off-by: Yijing Wang
---
drivers/iommu/intel-iommu.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 15e9b57..98faa1d 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3777,11 +3777,10 @@ static void iommu_detach_dependent_devices(struct
intel_iommu *iommu,
static void domain_remove_one_dev_info(struct dmar_domain *domain,
struct pci_dev *pdev)
{
- struct device_domain_info *info;
+ struct device_domain_info *info, *tmp;
struct intel_iommu *iommu;
unsigned long flags;
int found = 0;
- struct list_head *entry, *tmp;
iommu = device_to_iommu(pci_domain_nr(pdev->bus), pdev->bus->number,
pdev->devfn);
@@ -3789,8 +3788,7 @@ static void domain_remove_one_dev_info(struct dmar_domain
*domain,
return;
spin_lock_irqsave(&device_domain_lock, flags);
- list_for_each_safe(entry, tmp, &domain->devices) {
- info = list_entry(entry, struct device_domain_info, link);
+ list_for_each_entry_safe(info, tmp, &domain->devices, link) {
if (info->segment == pci_domain_nr(pdev->bus) &&
info->bus == pdev->bus->number &&
info->devfn == pdev->devfn) {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] enable boot delay for earlyprintk
Previously boot_delay does not work for earlyprintk
because the kernel cmdline parsing is late.
Change to use early_param so early kernel messages
can also be delayed.
Signed-off-by: Dave Young
---
kernel/printk/printk.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.orig/kernel/printk/printk.c
+++ linux-2.6/kernel/printk/printk.c
@@ -822,7 +822,7 @@ static int __init boot_delay_setup(char
boot_delay, preset_lpj, lpj, HZ, loops_per_msec);
return 1;
}
-__setup("boot_delay=", boot_delay_setup);
+early_param("boot_delay", boot_delay_setup);
static void boot_delay_msec(int level)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Extended martian logging with data dump: patch not working, why? RFC on idea
Hello List, I have tried to extend the martian logging functionale in kernel, but the patch does not work. Rationale (SKIP IF NOT INTERESTED): martian packets do not inter iptables stack, hence cannot be full-packet-capture logged via e.g. ulog. The capure would be interesting to distinguish these 3 cases: a) normal noise, e.g. VM-hosts with virtual local networks that occasionally leak packets without natting those, b) unskilled attacker using forbidden source IP by chance/accident with not so problematic payloads c) skilled attacker, who is sending crafted payloads and knows which source-IP/dest/service/vuln he targets. Since source policy check also has security advantages, hence complete disabling is out of question. Otherwise moving source route checks would require to re-implement those rules in iptables to get same effect, a duplication I do want to make. CONTINUE HERE FOR PROGRAMMING PROBLEM: I added log_martian type 2, where packet dump should also be produced. Why does setting echo 2 > log_martians not activate my new code? Does ./include/linux/inetdevice.h:#define IN_DEV_LOG_MARTIANS(in_dev) IN_DEV_ORCONF((in_dev), LOG_MARTIANS) only return 0 or 1? Any help appreciated, I hope Outlook does not mixup the plaintext too much, Roman martian.patch Description: martian.patch
Re: [GIT PULL] Move drivers/acpi/apei/cper.c to drivers/firmware/efi/
* Luck, Tony wrote:
> The following changes since commit 56507694de3453076d73e0e9813349586ee67e59:
>
> EDAC, GHES: Update ghes error record info (2013-10-23 10:11:00 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git
> tags/please-pull-move-cper
>
> for you to fetch changes up to c57a801195153e111bcd712680a718cf101b6d1f:
>
> Move cper.c from drivers/acpi/apei to drivers/firmware/efi (2013-10-29
> 09:23:38 -0700)
>
>
> cper.c implements UEFI Appendix N "Common Platform Error Record"
> handling. Move it to drivers/firmware/efi/cper.c to reflect this
> heritage.
>
>
> Tony Luck (1):
> Move cper.c from drivers/acpi/apei to drivers/firmware/efi
>
> drivers/acpi/Kconfig | 4 +++-
> drivers/acpi/apei/Kconfig | 2 ++
> drivers/acpi/apei/Makefile | 2 +-
> drivers/firmware/efi/Kconfig | 3 +++
> drivers/firmware/efi/Makefile | 1 +
> drivers/{acpi/apei => firmware/efi}/cper.c | 0
> 6 files changed, 10 insertions(+), 2 deletions(-)
> rename drivers/{acpi/apei => firmware/efi}/cper.c (100%)
Hm, it's not very well tested:
drivers/firmware/efi/Kconfig:41: syntax error
drivers/firmware/efi/Kconfig:40: unknown option "defbool"
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 2/3] Staging: zram: Fix decrement of variable by calling bdput()
Hello, Rashika
On Wed, Oct 30, 2013 at 9:10 PM, Rashika Kheria
wrote:
> As suggested by Jerome Marchand "The code in reset_store get the block device
> (bdget_disk()) but it does not put it (bdput()) when it's done using it.
> The usage count is therefore incremented but never decremented."
>
> This patch also puts bdput() for all error cases.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Rashika Kheria
> ---
>
> This revision fixes the following issues of the previous revision-
> Proper error handling
>
> drivers/staging/zram/zram_drv.c | 25 ++---
> 1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
> index 012ba15..0bc2835 100644
> --- a/drivers/staging/zram/zram_drv.c
> +++ b/drivers/staging/zram/zram_drv.c
> @@ -648,25 +648,36 @@ static ssize_t reset_store(struct device *dev,
> zram = dev_to_zram(dev);
> bdev = bdget_disk(zram->disk, 0);
>
> - if (!bdev)
> - return -ENOMEM;
> + if (!bdev) {
> + ret = -ENOMEM;
> + goto out;
> + }
If bdev is NULL, just return -ENOMEM; DO NOT goto out;
or you will get a NULL point reference in bdput(bdev);
> /* Do not reset an active device! */
> - if (bdev->bd_holders)
> - return -EBUSY;
> + if (bdev->bd_holders) {
> + ret = -EBUSY;
> + goto out;
> + }
>
> ret = kstrtou16(buf, 10, &do_reset);
> if (ret)
> - return ret;
> + goto out;
>
> - if (!do_reset)
> - return -EINVAL;
> + if (!do_reset) {
> + ret = -EINVAL;
> + goto out;
> + }
>
> /* Make sure all pending I/O is finished */
> fsync_bdev(bdev);
> + bdput(bdev);
>
> zram_reset_device(zram, true);
> return len;
> +
> +out:
> + bdput(bdev);
> + return ret;
> }
>
> static void __zram_make_request(struct zram *zram, struct bio *bio, int rw)
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 0/3] perf/x86/amd: AMD Family 16h Data Breakpoint Extensions
On Wed, Oct 02, 2013 at 11:11:05AM -0500, suravee.suthikulpa...@amd.com wrote: > From: Suravee Suthikulpanit > > Frederic, this is the rebase of the V4 patch onto the linux-3.12.0-rc3 > (linux.git), > and retest. > > The following patchset enables hardware breakpoint bp_len greater than > HW_BREAKPOINT_LEN_8 on AMD Family 16h and later. > > $ perf stat -e mem:0x1000/16:w a.out > ^^ > bp_len > > This will count writes to [0x1000 ~ 0x1010) This interface looks good to me. I mean it seems flexible enough to provide a range of address that fits anyway whenever the architecture supports breakpoint ranges through either a length or a mask. Thanks. > > V5: > * Rebase onto 3.12.0-rc3. > * Modify the tools/perf/util/parse-events.y due to change in > parse_events_add_breakpoint(). > > V4: > Even more per Oleg's suggestion: > * Further simplify info->len and info->mask setting switch statement > > V3: > More per Oleg's suggestion: > * Use already existing bp_len instead of changing userland API and > in kernel turn bp_len into proper AMD hardware breakpoint address > mask. > > V2: > Per Oleg's suggestions: > * Moved testing of bp_addr_mask to validate_hw_breakpoint() > * Changed perf tool syntax to mem:[/addr_mask][:access] > > > Jacob Shin (3): > perf/x86/amd: AMD support for bp_len > HW_BREAKPOINT_LEN_8 > perf tools: allow user to specify hardware breakpoint bp_len > perf tools: add hardware breakpoint bp_len test cases > > arch/x86/include/asm/cpufeature.h| 2 ++ > arch/x86/include/asm/debugreg.h | 5 +++ > arch/x86/include/asm/hw_breakpoint.h | 1 + > arch/x86/include/uapi/asm/msr-index.h| 4 +++ > arch/x86/kernel/cpu/amd.c| 19 +++ > arch/x86/kernel/hw_breakpoint.c | 47 +++ > tools/perf/Documentation/perf-record.txt | 7 ++-- > tools/perf/tests/parse-events.c | 55 > > tools/perf/util/parse-events.c | 17 -- > tools/perf/util/parse-events.h | 2 +- > tools/perf/util/parse-events.l | 1 + > tools/perf/util/parse-events.y | 26 +-- > 12 files changed, 142 insertions(+), 44 deletions(-) > > -- > 1.8.1.2 > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC GIT PULL] NUMA-balancing memory corruption fixes
Linus,
* Mel Gorman wrote:
> Hi Ingo,
>
> Off-list we talked with Peter about the fact that automatic NUMA
> balancing as merged in 3.10, 3.11 and 3.12 shortly may corrupt
> userspace memory. [...]
So these fixes are definitely not something I'd like to sit on, but
as I said to you at the KS the timing is quite tight, with Linus
planning v3.12-final within a week.
Fedora-19 is affected:
comet:~> grep NUMA_BALANCING /boot/config-3.11.3-201.fc19.x86_64
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
CONFIG_NUMA_BALANCING=y
AFAICS Ubuntu will be affected as well, once it updates the kernel:
hubble:~> grep NUMA_BALANCING /boot/config-3.8.0-32-generic
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
CONFIG_NUMA_BALANCING=y
Linus, please consider pulling the latest core-urgent-for-linus git
tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
core-urgent-for-linus
# HEAD: 0255d491848032f6c601b6410c3b8ebded3a37b1 mm: Account for a THP NUMA
hinting update as one PTE update
These 6 commits are a minimalized set of cherry-picks needed to fix
the memory corruption bugs. All commits are fixes, except "mm: numa:
Sanitize task_numa_fault() callsites" which is a cleanup that made
two followup fixes simpler.
I've done targeted testing with just this SHA1 to try to make sure
there are no cherry-picking artifacts. The original
non-cherry-picked set of fixes were exposed to linux-next for a
couple of weeks.
( If you think this is too dangerous for too little benefit then
I'll drop this separate tree and will send the original commits in
the merge window. )
Thanks,
Ingo
-->
Mel Gorman (6):
mm: numa: Do not account for a hinting fault if we raced
mm: Wait for THP migrations to complete during NUMA hinting faults
mm: Prevent parallel splits during THP migration
mm: numa: Sanitize task_numa_fault() callsites
mm: Close races between THP migration and PMD numa clearing
mm: Account for a THP NUMA hinting update as one PTE update
mm/huge_memory.c | 70 ++--
mm/memory.c | 53 +-
mm/migrate.c | 19 ---
mm/mprotect.c| 2 +-
4 files changed, 81 insertions(+), 63 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 610e3df..cca80d9 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1278,64 +1278,90 @@ out:
int do_huge_pmd_numa_page(struct mm_struct *mm, struct vm_area_struct *vma,
unsigned long addr, pmd_t pmd, pmd_t *pmdp)
{
+ struct anon_vma *anon_vma = NULL;
struct page *page;
unsigned long haddr = addr & HPAGE_PMD_MASK;
+ int page_nid = -1, this_nid = numa_node_id();
int target_nid;
- int current_nid = -1;
- bool migrated;
+ bool page_locked;
+ bool migrated = false;
spin_lock(&mm->page_table_lock);
if (unlikely(!pmd_same(pmd, *pmdp)))
goto out_unlock;
page = pmd_page(pmd);
- get_page(page);
- current_nid = page_to_nid(page);
+ page_nid = page_to_nid(page);
count_vm_numa_event(NUMA_HINT_FAULTS);
- if (current_nid == numa_node_id())
+ if (page_nid == this_nid)
count_vm_numa_event(NUMA_HINT_FAULTS_LOCAL);
+ /*
+* Acquire the page lock to serialise THP migrations but avoid dropping
+* page_table_lock if at all possible
+*/
+ page_locked = trylock_page(page);
target_nid = mpol_misplaced(page, vma, haddr);
if (target_nid == -1) {
- put_page(page);
- goto clear_pmdnuma;
+ /* If the page was locked, there are no parallel migrations */
+ if (page_locked)
+ goto clear_pmdnuma;
+
+ /*
+* Otherwise wait for potential migrations and retry. We do
+* relock and check_same as the page may no longer be mapped.
+* As the fault is being retried, do not account for it.
+*/
+ spin_unlock(&mm->page_table_lock);
+ wait_on_page_locked(page);
+ page_nid = -1;
+ goto out;
}
- /* Acquire the page lock to serialise THP migrations */
+ /* Page is misplaced, serialise migrations and parallel THP splits */
+ get_page(page);
spin_unlock(&mm->page_table_lock);
- lock_page(page);
+ if (!page_locked)
+ lock_page(page);
+ anon_vma = page_lock_anon_vma_read(page);
/* Confirm the PTE did not while locked */
spin_lock(&mm->page_table_lock);
if (unlikely(!pmd_same(pmd, *pmdp))) {
unlock_page(page);
put_page(page);
+ page_nid = -1;
goto out_un
Re: [PATCH] USB: Maintainers change for usb serial drivers
On Wed, Oct 30, 2013 at 11:07:31AM -0700, Greg KH wrote: > Johan has been conned^Wgracious in accepting the maintainership of the > USB serial drivers, especially as he's been doing all of the real work > for the past few years. > > At the same time, remove a bunch of old entries for USB serial drivers > that don't make sense anymore, given that the developers are no longer > around, and individual driver maintainerships for tiny things like this > is pretty pointless. > > Cc: Johan Hovold > Signed-off-by: Greg Kroah-Hartman Acked-by: Johan Hovold -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[3.5.y.z extended stable] Linux 3.5.7.24
I am announcing the release of the Linux 3.5.7.24 kernel. The updated 3.5.y tree can be found at: git://kernel.ubuntu.com/ubuntu/linux.git linux-3.5.y and can be browsed at: http://kernel.ubuntu.com/git?p=ubuntu/linux.git;h=refs/heads/linux-3.5.y;a=shortlog The diff from v3.5.7.23 is posted as a follow-up to this email. The 3.5.y extended stable tree is maintained by the Ubuntu Kernel Team. For more info, see https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable -Luis -- Makefile| 2 +- arch/arm/include/asm/syscall.h | 6 + arch/arm/mm/init.c | 3 + arch/ia64/mm/contig.c | 2 + arch/ia64/mm/discontig.c| 2 + arch/parisc/kernel/traps.c | 6 +- arch/parisc/mm/init.c | 2 + arch/powerpc/kernel/lparcfg.c | 1 + arch/powerpc/kvm/book3s_hv_rmhandlers.S | 2 +- arch/powerpc/lib/checksum_64.S | 54 -- arch/tile/include/asm/percpu.h | 34 +++- arch/unicore32/mm/init.c| 3 + drivers/acpi/acpi_ipmi.c| 24 +-- drivers/char/random.c | 11 +- drivers/connector/cn_proc.c | 16 ++ drivers/connector/connector.c | 7 +- drivers/gpu/drm/radeon/evergreen.c | 2 +- drivers/hwmon/applesmc.c| 13 ++ drivers/md/dm-snap-persistent.c | 18 +- drivers/media/video/sh_vou.c| 2 +- drivers/net/can/dev.c | 10 +- drivers/net/can/flexcan.c | 20 +-- drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 1 + drivers/net/ethernet/marvell/mv643xx_eth.c | 6 +- drivers/net/ethernet/ti/davinci_emac.c | 3 +- drivers/net/wan/farsync.c | 1 + drivers/net/wan/wanxl.c | 1 + drivers/net/wireless/rt2x00/rt2800lib.c | 7 + drivers/pci/setup-res.c | 3 +- drivers/usb/core/quirks.c | 6 + drivers/usb/host/xhci-hub.c | 28 --- drivers/usb/host/xhci-pci.c | 25 +++ drivers/usb/host/xhci.c | 14 +- drivers/usb/host/xhci.h | 2 + drivers/usb/serial/option.c | 225 +++- drivers/usb/serial/ti_usb_3410_5052.c | 1 + drivers/usb/storage/scsiglue.c | 5 +- drivers/usb/storage/unusual_devs.h | 7 + drivers/watchdog/ts72xx_wdt.c | 3 +- fs/btrfs/relocation.c | 14 +- fs/buffer.c | 14 +- fs/ext4/xattr.c | 2 + fs/fuse/dir.c | 7 +- fs/fuse/file.c | 8 +- fs/fuse/fuse_i.h| 9 + fs/fuse/inode.c | 4 +- fs/nilfs2/page.c| 2 + fs/nilfs2/segment.c | 11 +- include/linux/mm.h | 3 +- include/linux/random.h | 1 + include/linux/skbuff.h | 15 ++ include/linux/timex.h | 14 ++ include/linux/usb_usual.h | 4 +- include/net/cipso_ipv4.h| 6 +- include/net/dst.h | 12 ++ init/main.c | 2 + lib/show_mem.c | 3 + mm/memcontrol.c | 2 + mm/mmap.c | 77 +++- mm/page-writeback.c | 10 +- mm/page_alloc.c | 7 + net/8021q/vlan_netlink.c| 2 +- net/bridge/br_stp_if.c | 2 +- net/compat.c| 2 + net/ipv4/inet_hashtables.c | 2 +- net/ipv4/ip_output.c| 2 +- net/ipv4/route.c| 2 +- net/ipv4/tcp_input.c| 5 +- net/ipv4/tcp_output.c | 9 +- net/ipv6/inet6_hashtables.c | 2 +- net/ipv6/ip6_output.c | 2 +- net/ipv6/route.c| 11 +- net/l2tp/l2tp_ppp.c | 4 + net/sctp/output.c | 3 +- net/socket.c| 24 ++- net/unix/af_unix.c | 10 ++ net/unix/diag.c | 1 + sound/pci/hda/patch_realtek.c
Re: 3.11.4: kernel BUG at fs/buffer.c:1268
Sorry for the long delay between updates, but it took a while to re-trigger the bug. It seems to be caused by iceweasel crashing due to some OOM condition. Anyway, here's the stack dump with CONFIG_DEBUG_ATOMIC_SLEEP enabled. (x = 1166866 seconds of uptime.) [x.908244] BUG: sleeping function called from invalid context at fs/ext4/ext4_jbd2.c:45 [x.908248] in_atomic(): 0, irqs_disabled(): 1, pid: 15216, name: iceweasel [x.908250] CPU: 6 PID: 15216 Comm: iceweasel Not tainted 3.11.5-8-ga1818c5 #99 [x.908252] Hardware name: Gigabyte Technology Co., Ltd. Z68A-D3H-B3/Z68A-D3H-B3, BIOS F13 03/20/2012 [x.908253] 0002 88010d249908 81561d7f 88021549a000 [x.908255] 88010d249918 81069d2f 88010d249930 8119079b [x.908257] 88021549a000 88010d249968 81190871 8800cc7b8c20 [x.908259] Call Trace: [x.908265] [] dump_stack+0x54/0x74 [x.908268] [] __might_sleep+0xcf/0xf0 [x.908271] [] ext4_journal_check_start+0x1b/0xa0 [x.908273] [] __ext4_journal_start_sb+0x21/0x80 [x.908276] [] ext4_dirty_inode+0x25/0x60 [x.908280] [] __mark_inode_dirty+0x2d/0x230 [x.908283] [] ext4_free_blocks+0x73c/0xa30 [x.908285] [] ext4_ext_remove_space+0x806/0xe20 [x.908287] [] ? ext4_es_free_extent+0x54/0x60 [x.908289] [] ext4_ext_truncate+0xb8/0xe0 [x.908291] [] ext4_truncate+0x2b5/0x300 [x.908292] [] ext4_evict_inode+0x3f8/0x430 [x.908295] [] evict+0xba/0x1c0 [x.908297] [] iput+0x10b/0x1b0 [x.908298] [] dput+0x278/0x350 [x.908301] [] __fput+0x16a/0x240 [x.908303] [] fput+0x9/0x10 [x.908306] [] task_work_run+0x9c/0xd0 [x.908309] [] do_exit+0x2a7/0x9d0 [x.908311] [] ? __sigqueue_free.part.13+0x2e/0x40 [x.908312] [] do_group_exit+0x3e/0xb0 [x.908315] [] get_signal_to_deliver+0x1b0/0x5f0 [x.908317] [] do_signal+0x43/0x940 [x.908319] [] ? do_send_sig_info+0x58/0x80 [x.908320] [] do_notify_resume+0x5d/0x80 [x.908323] [] int_signal+0x12/0x17 [x.908329] [ cut here ] [x.908352] kernel BUG at fs/buffer.c:1268! [x.908370] invalid opcode: [#1] SMP [x.908391] Modules linked in: pl2303 fuse ftdi_sio usbserial iTCO_wdt [x.908425] CPU: 6 PID: 15216 Comm: iceweasel Not tainted 3.11.5-8-ga1818c5 #99 [x.908460] Hardware name: Gigabyte Technology Co., Ltd. Z68A-D3H-B3/Z68A-D3H-B3, BIOS F13 03/20/2012 [x.908484] task: 8801124ae800 ti: 88010d248000 task.ti: 88010d248000 [x.908504] RIP: 0010:[] [] check_irqs_on.part.19+0x4/0x6 [x.908529] RSP: 0018:88010d249798 EFLAGS: 00210046 [x.908543] RAX: 00200082 RBX: 88010d249928 RCX: 880215a5c000 [x.908562] RDX: 1000 RSI: 0038005b RDI: 8802164296c0 [x.908580] RBP: 88010d249798 R08: R09: [x.908599] R10: 880215a5c000 R11: 88010d24947e R12: 8802164296c0 [x.908617] R13: 1000 R14: 88021fbdbe00 R15: 88021549a000 [x.908635] FS: () GS:88021fb8() knlGS: [x.908656] CS: 0010 DS: 002b ES: 002b CR0: 80050033 [x.908672] CR2: CR3: 0180c000 CR4: 000407e0 [x.908690] Stack: [x.908696] 88010d249808 8112feb7 b760 88010d2498f0 [x.908720] 88021fb83fc0 88010d2498e8 88010d249840 81004b7f [x.908743] 88010d24980c 0d2498f0 88010d249928 8802164296c0 [x.908766] Call Trace: [x.908776] [] __find_get_block+0x1d7/0x1e0 [x.908793] [] ? dump_trace+0x17f/0x2d0 [x.908808] [] __getblk+0x20/0x2f0 [x.908823] [] __ext4_get_inode_loc+0x106/0x410 [x.908840] [] ? show_stack_log_lvl+0xaf/0x1a0 [x.908857] [] ext4_get_inode_loc+0x18/0x20 [x.908874] [] ext4_reserve_inode_write+0x21/0x90 [x.908891] [] ? dump_stack+0x54/0x74 [x.908906] [] ext4_mark_inode_dirty+0x49/0x1a0 [x.908924] [] ext4_dirty_inode+0x3b/0x60 [x.908940] [] __mark_inode_dirty+0x2d/0x230 [x.908957] [] ext4_free_blocks+0x73c/0xa30 [x.908974] [] ext4_ext_remove_space+0x806/0xe20 [x.908991] [] ? ext4_es_free_extent+0x54/0x60 [x.909008] [] ext4_ext_truncate+0xb8/0xe0 [x.909025] [] ext4_truncate+0x2b5/0x300 [x.909041] [] ext4_evict_inode+0x3f8/0x430 [x.909057] [] evict+0xba/0x1c0 [x.909071] [] iput+0x10b/0x1b0 [x.909084] [] dput+0x278/0x350 [x.909099] [] __fput+0x16a/0x240 [x.909113] [] fput+0x9/0x10 [x.909127] [] task_work_run+0x9c/0xd0 [x.909143] [] do_exit+0x2a7/0x9d0 [x.909157] [] ? __sigqueue_free.part.13+0x2e/0x40 [x.909175] [] do_group_exit+0x3e/0xb0 [x.909190] [] get_signal_to_deliver+0x1b0/0x5f0 [x.909207] [] do_signal+0x43/0x940 [x.909222] [] ? do_send_sig_info+0x58/0x80 [x.909238] [] do_notify_resume+0x5d/0x80 [x.909254] [] int_signal+0x12/0x17 [x.909267] Code: 4d 85 e4 74 1d 41 80 44 24 58 01 65 48 8b 04 25 b0 b7 00 00 ff 88 44 e0 ff ff 4c 89 e7 e8 23 79 bb ff 5b 41 5c 5d c3 55 48 89 e5 <0f> 0b 55 48 89 e5 0f 0b 55 48 89 e5 0f 0b 55 48 89 e5 0f 0b 55 [x.909390] RIP [] check_irqs_on.part.19+0x4/0x6 [x.909408] RSP [x.915643] ---[ end
Re: [PATCH 1/3] perf/x86/amd: AMD support for bp_len > HW_BREAKPOINT_LEN_8
On Wed, Oct 02, 2013 at 11:11:06AM -0500, suravee.suthikulpa...@amd.com wrote:
> From: Jacob Shin
>
> Implement hardware breakpoint address mask for AMD Family 16h and
> above processors. CPUID feature bit indicates hardware support for
> DRn_ADDR_MASK MSRs. These masks further qualify DRn/DR7 hardware
> breakpoint addresses to allow matching of larger addresses ranges.
>
> Valuable advice and pseudo code from Oleg Nesterov
>
> Signed-off-by: Jacob Shin
> Signed-off-by: Suravee Suthikulpanit
> ---
> arch/x86/include/asm/cpufeature.h | 2 ++
> arch/x86/include/asm/debugreg.h | 5
> arch/x86/include/asm/hw_breakpoint.h | 1 +
> arch/x86/include/uapi/asm/msr-index.h | 4 +++
> arch/x86/kernel/cpu/amd.c | 19 ++
> arch/x86/kernel/hw_breakpoint.c | 47
> ++-
> 6 files changed, 49 insertions(+), 29 deletions(-)
>
> diff --git a/arch/x86/include/asm/cpufeature.h
> b/arch/x86/include/asm/cpufeature.h
> index d3f5c63..26609bb 100644
> --- a/arch/x86/include/asm/cpufeature.h
> +++ b/arch/x86/include/asm/cpufeature.h
> @@ -170,6 +170,7 @@
> #define X86_FEATURE_TOPOEXT (6*32+22) /* topology extensions CPUID leafs */
> #define X86_FEATURE_PERFCTR_CORE (6*32+23) /* core performance counter
> extensions */
> #define X86_FEATURE_PERFCTR_NB (6*32+24) /* NB performance counter
> extensions */
> +#define X86_FEATURE_BPEXT(6*32+26) /* data breakpoint extension */
Is this perhaps a bit too generic? Extension can mean about everything and who
knows
what other feature Intel and Amd will add to breakpoints in the future.
How about X86_FEATURE_BP_RANGE?
> #define X86_FEATURE_PERFCTR_L2 (6*32+28) /* L2 performance counter
> extensions */
>
> /*
> @@ -332,6 +333,7 @@ extern const char * const x86_power_flags[32];
> #define cpu_has_cx16 boot_cpu_has(X86_FEATURE_CX16)
> #define cpu_has_eager_fpuboot_cpu_has(X86_FEATURE_EAGER_FPU)
> #define cpu_has_topoext boot_cpu_has(X86_FEATURE_TOPOEXT)
> +#define cpu_has_bpextboot_cpu_has(X86_FEATURE_BPEXT)
>
> #ifdef CONFIG_X86_64
>
> diff --git a/arch/x86/include/asm/debugreg.h b/arch/x86/include/asm/debugreg.h
> index 4b528a9..145b009 100644
> --- a/arch/x86/include/asm/debugreg.h
> +++ b/arch/x86/include/asm/debugreg.h
> @@ -114,5 +114,10 @@ static inline void debug_stack_usage_inc(void) { }
> static inline void debug_stack_usage_dec(void) { }
> #endif /* X86_64 */
>
> +#ifdef CONFIG_CPU_SUP_AMD
> +extern void set_dr_addr_mask(unsigned long mask, int dr);
> +#else
> +static inline void set_dr_addr_mask(unsigned long mask, int dr) { }
> +#endif
>
> #endif /* _ASM_X86_DEBUGREG_H */
> diff --git a/arch/x86/include/asm/hw_breakpoint.h
> b/arch/x86/include/asm/hw_breakpoint.h
> index ef1c4d2..6c98be8 100644
> --- a/arch/x86/include/asm/hw_breakpoint.h
> +++ b/arch/x86/include/asm/hw_breakpoint.h
> @@ -12,6 +12,7 @@
> */
> struct arch_hw_breakpoint {
> unsigned long address;
> + unsigned long mask;
> u8 len;
So it's a bit sad that we have both len and mask. OTOH it's my fault because we
have that len
thing that is actually buggy for instruction breakpoints and needs to be
sizeof(long) (who knows
what kind of fluorescent bier I drank before writing that).
But Oleg had a patch to fix that.
Oleg?
> u8 type;
> };
> diff --git a/arch/x86/include/uapi/asm/msr-index.h
> b/arch/x86/include/uapi/asm/msr-index.h
> index bb04650..1f04f6c 100644
> --- a/arch/x86/include/uapi/asm/msr-index.h
> +++ b/arch/x86/include/uapi/asm/msr-index.h
> @@ -205,6 +205,10 @@
> /* Fam 16h MSRs */
> #define MSR_F16H_L2I_PERF_CTL0xc0010230
> #define MSR_F16H_L2I_PERF_CTR0xc0010231
> +#define MSR_F16H_DR1_ADDR_MASK 0xc0011019
> +#define MSR_F16H_DR2_ADDR_MASK 0xc001101a
> +#define MSR_F16H_DR3_ADDR_MASK 0xc001101b
> +#define MSR_F16H_DR0_ADDR_MASK 0xc0011027
>
> /* Fam 15h MSRs */
> #define MSR_F15H_PERF_CTL0xc0010200
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index 903a264..fffc9cb 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -909,3 +909,22 @@ static bool cpu_has_amd_erratum(struct cpuinfo_x86 *cpu,
> const int *erratum)
>
> return false;
> }
> +
> +void set_dr_addr_mask(unsigned long mask, int dr)
> +{
> + if (!cpu_has_bpext)
> + return;
> +
> + switch (dr) {
> + case 0:
> + wrmsr(MSR_F16H_DR0_ADDR_MASK, mask, 0);
> + break;
> + case 1:
> + case 2:
> + case 3:
> + wrmsr(MSR_F16H_DR1_ADDR_MASK - 1 + dr, mask, 0);
> + break;
> + default:
> + break;
> + }
> +}
> diff --git a/arch/x86/kernel/hw_breakpoint.c b/arch/x86/kernel/hw_breakpoint.c
> index f66ff16..3cb1951 100644
> --- a/arch/x86/kernel/hw_breakpoint.c
> +++ b/ar
Re: [PATCH v4 2/3] Support for perf to probe into SDT markers:
* Pekka Enberg wrote: > On 10/30/13 12:05 PM, Masami Hiramatsu wrote: > >To find all system libraries, we can use ldconfig. > > > >$ ldconfig --print-cache > > > >shows what dynamic libraries will be loaded. On my own laptop (running > >ubuntu13.04) shows ~1000 libs. > > Good point. That definitely narrows down the scanned set. > > Pekka There's also 'strings /etc/prelink.cache' that should give a good list of binaries and libraries that matter. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf events ring buffer memory barrier on powerpc
"Paul E. McKenney" wrote on 10/31/2013 06:32:58 AM: > If you want to play the "omit memory barriers" game, then proving a > negative is in fact the task before you. Generally it is not fair. Otherwise, anyone could put an smp_mb() at a random place, and expect others to "prove" that it is not needed. It is not fair also because it should be virtually impossible to prove lack of any problem. OTH, if a problem exists, it should be easy for proponents of a memory barrier to build a test case or design a scenario demonstrating the problem. Actually, advocates of the memory barrier in our case do have an argument - - the rule of thumb saying that barriers should be paired. I consider this rule only as a general recommendation to look into potentially risky places. And indeed, in our case if the store to circular wasn't conditional, it would require a memory barrier to prevent the store to be performed before the read of @tail. But in our case the store is conditional, so no memory barrier is required. > And the correctness of this code has been called into question. :-( > An embarrassingly long time ago -- I need to get this either proven > or fixed. I agree. > Before C/C++11, the closest thing to such a prohibition is use of > volatile, for example, ACCESS_ONCE(). Even in C/C++11, you have to > use atomics to get anything resembing this prohibition. > > If you just use normal variables, the compiler is within its rights > to transform something like the following: > >if (a) > b = 1; >else > b = 42; > > Into: > >b = 42; >if (a) > b = 1; > > Many other similar transformations are permitted. Some are used to all > vector instructions to be used -- the compiler can do a write with an > overly wide vector instruction, then clean up the clobbered variables > later, if it wishes. Again, if the variables are not marked volatile, > or, in C/C++11, atomic. All this can justify only compiler barrier() which is almost free from performance point of view, since current gcc anyway doesn't perform store hoisting optimization in our case. (And I'm not getting into philosophical discussion whether kernel code should consider future possible bugs/features in gcc or C/C++11 standard). > The compilers don't always know as much as they might about the underlying > hardware's memory model. That's correct in general. But can you point out a problem that really exists? > Of course, if this code is architecture specific, > it can avoid DEC Alpha's fun and games, which could also violate your > assumptions in the above paragraph: > >http://www.openvms.compaq.com/wizard/wiz_2637.html Are you talking about this paragraph from above link: "For instance, your producer must issue a "memory barrier" instruction after writing the data to shared memory and before inserting it on the queue; likewise, your consumer must issue a memory barrier instruction after removing an item from the queue and before reading from its memory. Otherwise, you risk seeing stale data, since, while the Alpha processor does provide coherent memory, it does not provide implicit ordering of reads and writes. (That is, the write of the producer's data might reach memory after the write of the queue, such that the consumer might read the new item from the queue but get the previous values from the item's memory." If yes, I don't think it explains the need of memory barrier on Alpha in our case (we all agree about the need of smp_wmb() right before @head update by producer). If not, could you please point to specific paragraph? > > Anyway, proving or fixing the code in Documentation/circular-buffers.txt > has been on my list for too long, so I will take a closer look at it. Thanks! I'm concerned more about performance overhead imposed by the full memory barrier in kfifo circular buffers. Even if it is needed on Alpha (I don't understand why) we could try to solve this with some memory barrier which is effective only on architectures which really need it. Regards, -- Victor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Oct 31
Hi all, Changes since 20131030: The net-next tree gained a conflict against the net tree. The devicetree tree gained a conflict against the crypto tree. The tty tree gained a build failure so I used the version from next-20131030. The arm-soc tree gained conflicts against the devicetree tree. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 212 trees (counting Linus' and 30 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (12aee278b50c Merge branch 'akpm' (fixes from Andrew Morton)) Merging fixes/master (fa8218def1b1 Merge tag 'regmap-v3.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap) Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make "make install" not depend on vmlinux) Merging arc-current/for-curr (020bc50bf8f6 ARC: SMP TLB flush) Merging arm-current/fixes (384b38b66947 ARM: 7873/1: vfp: clear vfp_current_hw_state for dying cpu) Merging m68k-current/for-linus (55490050df0f m68k/atari: ARAnyM - Always use physical addresses in NatFeat calls) Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2) Merging powerpc-merge/merge (8b5ede69d24d powerpc/irq: Don't switch to irq stack from softirq stack) Merging sparc/master (6d15ee492809 Merge git://git.kernel.org/pub/scm/virt/kvm/kvm) Merging net/master (c17cb8b55b10 doc:net: Fix typo in Documentation/networking) Merging ipsec/master (eeb1b73378b5 xfrm: Increase the garbage collector threshold) Merging sound-current/for-linus (c4a4ddaefbef Merge tag 'asoc-fix-v3.12-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging pci-current/for-linus (67d470e0e171 Revert "x86/PCI: MMCONFIG: Check earlier for MMCONFIG region at address zero") Merging wireless/master (8ce9beac4661 drivers: net: wireless: b43: Fix possible NULL ptr dereference) Merging driver-core.current/driver-core-linus (31d141e3a666 Linux 3.12-rc6) Merging tty.current/tty-linus (6e757ad2c92c tty/serial: at91: fix uart/usart selection for older products) Merging usb.current/usb-linus (31d141e3a666 Linux 3.12-rc6) Merging staging.current/staging-linus (31d141e3a666 Linux 3.12-rc6) Merging char-misc.current/char-misc-linus (31d141e3a666 Linux 3.12-rc6) Merging input-current/for-linus (2d3163f10256 Input: wacom - add support for ISDv4 0x10E sensor) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging audit-current/for-linus (c158a35c8a68 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (26052f9b9bb8 crypto: crct10dif - Add fallback for broken initrds) Merging ide/master (64110c16e012 ide: sgiioc4: Staticize ioc4_ide_attach_one()) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (44033109e99c SH: Convert out[bwl] macros to inline functions) Merging devicetree-current/devicetree/merge (1931ee143b0a Revert "drivers: of: add initialization code for dma reserved memory") Merging rr-fixes/fixes (d8524ae9d6f4 Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux) Merging mfd-fixes/master (d0e639c9e06d Linux 3.12-rc4) Merging vfio-fixes/for-linus
Fw:
Hi! I recommend to visit the site http://navegacion.com.my/_45_advise.facebook.apps_34_.html?ubetjfav=1352340 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: get rid of unnecessary pageblock scanning in setup_zone_migrate_reserve
On Wed, Oct 30, 2013 at 04:19:07PM -0400, KOSAKI Motohiro wrote:
> >@@ -3926,11 +3929,11 @@ static void setup_zone_migrate_reserve(struct zone
> >*zone)
> > /*
> > * Reserve blocks are generally in place to help high-order atomic
> > * allocations that are short-lived. A min_free_kbytes value that
> >- * would result in more than 2 reserve blocks for atomic allocations
> >- * is assumed to be in place to help anti-fragmentation for the
> >- * future allocation of hugepages at runtime.
> >+ * would result in more than MAX_MIGRATE_RESERVE_BLOCKS reserve blocks
> >+ * for atomic allocations is assumed to be in place to help
> >+ * anti-fragmentation for the future allocation of hugepages at runtime.
> > */
> >-reserve = min(2, reserve);
> >+reserve = min(MAX_MIGRATE_RESERVE_BLOCKS, reserve);
> >
> > for (pfn = start_pfn; pfn < end_pfn; pfn += pageblock_nr_pages) {
> > if (!pfn_valid(pfn))
> >@@ -3956,6 +3959,7 @@ static void setup_zone_migrate_reserve(struct zone
> >*zone)
> > /* If this block is reserved, account for it */
> > if (block_migratetype == MIGRATE_RESERVE) {
> > reserve--;
> >+found++;
> > continue;
> > }
> >
> >@@ -3970,6 +3974,10 @@ static void setup_zone_migrate_reserve(struct zone
> >*zone)
> > }
> > }
> >
> >+/* If all possible reserve blocks have been found, we're done */
> >+if (found >= MAX_MIGRATE_RESERVE_BLOCKS)
> >+break;
> >+
> > /*
> > * If the reserve is met and this is a previous reserved block,
> > * take it back
>
> Nit. I would like to add following hunk. This is just nit because moving
> reserve pageblock is extreme rare.
>
> if (block_migratetype == MIGRATE_RESERVE) {
> + found++;
> set_pageblock_migratetype(page, MIGRATE_MOVABLE);
> move_freepages_block(zone, page, MIGRATE_MOVABLE);
> }
I don't really see the advantage but if you think it is necessary then I
do not object either.
--
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pci: fix invalid list entry warning for double pci device removing via sysfs
Hi Bjorn, Thanks for your comments.:) Please refer to inline. Best regards, Gu On 10/31/2013 01:08 AM, Bjorn Helgaas wrote: > On Wed, Oct 30, 2013 at 06:14:20PM +0800, Gu Zheng wrote: >> When concurent removing pci devices which are in the same pci subtree >> via sysfs, such as: >> echo -n 1 > /sys/bus/pci/devices/\:10\:00.0/remove ; echo -n 1 > >> /sys/bus/pci/devices/\:1a\:01.0/remove >> (1a:01.0 device is downstream from the 10:00.0 bridge) >> >> the following warning will show: >> [ 1799.280918] [ cut here ] >> [ 1799.336199] WARNING: CPU: 7 PID: 126 at lib/list_debug.c:53 >> __list_del_entry+0x63/0xd0() >> [ 1799.433093] list_del corruption, 8807b4a7c000->next is LIST_POISON1 >> (dead00100100) >> [ 1799.532110] Modules linked in: nf_conntrack_netbios_ns >> nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT >> nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat_ipv4 nf_nat >> iptable_mangle ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack >> nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tables >> iptable_filter ip_tables sg dm_mirror dm_region_hash dm_log dm_mod vfat fat >> e1000e igb iTCO_wdt iTCO_vendor_support ioatdma ptp i7core_edac ipmi_si >> edac_core lpc_ich pps_core i2c_i801 pcspkr mfd_core dca ipmi_msghandler >> acpi_cpufreq xfs libcrc32c sd_mod crc_t10dif crct10dif_common i2c_algo_bit >> drm_kms_helper ttm drm mptsas scsi_transport_sas mptscsih i2c_core >> megaraid_sas mptbase >> [ 1800.276623] CPU: 7 PID: 126 Comm: kworker/u512:1 Tainted: GW >> 3.12.0-rc5+ #196 >> [ 1800.508918] Workqueue: sysfsd sysfs_schedule_callback_work >> [ 1800.574703] 0009 8807adbadbd8 8168b26c >> 8807c27d08a8 >> [ 1800.663860] 8807adbadc28 8807adbadc18 810711dc >> 8807adbadc68 >> [ 1800.753130] 8807b4a7c000 8807b4a7c000 8807ad089c00 >> >> [ 1800.842282] Call Trace: >> [ 1800.871651] [] dump_stack+0x55/0x76 >> [ 1800.933301] [] warn_slowpath_common+0x8c/0xc0 >> [ 1801.005283] [] warn_slowpath_fmt+0x46/0x50 >> [ 1801.074081] [] __list_del_entry+0x63/0xd0 >> [ 1801.141839] [] list_del+0x11/0x40 >> [ 1801.201320] [] pci_remove_bus_device+0x6a/0xe0 >> [ 1801.274279] [] pci_stop_and_remove_bus_device+0x1e/0x30 >> [ 1801.356606] [] remove_callback+0x2b/0x40 >> [ 1801.423412] [] sysfs_schedule_callback_work+0x18/0x60 >> [ 1801.503744] [] process_one_work+0x1f5/0x540 >> [ 1801.573640] [] ? process_one_work+0x193/0x540 >> [ 1801.645616] [] worker_thread+0x11c/0x370 >> [ 1801.712337] [] ? rescuer_thread+0x350/0x350 >> [ 1801.782178] [] kthread+0xed/0x100 >> [ 1801.841661] [] ? kthread_create_on_node+0x160/0x160 >> [ 1801.919919] [] ret_from_fork+0x7c/0xb0 >> [ 1801.984608] [] ? kthread_create_on_node+0x160/0x160 >> [ 1802.062825] ---[ end trace d77f2054de000fb7 ]--- >> >> This issue is related to the bug 54411: >> https://bugzilla.kernel.org/show_bug.cgi?id=54411 >> >> Since we added the pci_bus reference management, the bug becomes a >> invalid list entry warning as descripted above. Beacuse it still >> trys to delete an deleted pci device from device list. >> >> So here we make stop device actually detach driver only, and remove >> device will do device_del instead, and move bus_list change and pci device >> resource free into pci_release_dev, so that it'll consistent with >> bus reference managment, and the device only can be deleted from device >> list in pci_release_dev just for one time. > > You have a good argument for moving the &dev->bus_list maintenance from > pci_destroy_dev() to pci_release_dev(), because I think we can call > pci_destroy_dev() twice for the same device, and we don't want to do the > list_del() twice. > > I suspect we want to move other stuff, too, but you haven't explained > why we need the device_del(), device_release_driver(), and > pci_free_resources() changes. Possibly similar arguments apply. I'd > rather see separate patches to move these pieces so we can think about > them individually. Sorry for missing explanation. The reason of moving pci_free_resources() into pci_release_dev is that the original place(pci_destory_dev()) is too early as there may be still others holding reference as the case mentioned above. Changing device_del() and device_release_driver() in order to make pci_stop_dev just do one thing--release driver, but it seems this change is nonsense.:( > >> Besides, it also makes hostbridge to use device_unregister to be pair >> with device_register before. > > Please split the host bridge changes into a separate patch. One logical > change, one patch. If they *can* be split up, please split them up. Agree all. Thanks for your suggestion, got it. > >> This patch is based on Yinghai's privious similar patch: >> http://lkml.org/lkml/2013/5/13/658 > > There are seven patches in that series. I don't know which one you're > referring to. [2/7]~[4/7] > > Please run a s
Re: [PATCH] pci: fix invalid list entry warning for double pci device removing via sysfs
Hi Yinghai, On 10/31/2013 02:45 PM, Yinghai Lu wrote: > On Wed, Oct 30, 2013 at 3:14 AM, Gu Zheng wrote: >> When concurent removing pci devices which are in the same pci subtree >> via sysfs, such as: >> echo -n 1 > /sys/bus/pci/devices/\:10\:00.0/remove ; echo -n 1 > >> /sys/bus/pci/devices/\:1a\:01.0/remove >> (1a:01.0 device is downstream from the 10:00.0 bridge) >> >> the following warning will show: >> [ 1799.280918] [ cut here ] >> [ 1799.336199] WARNING: CPU: 7 PID: 126 at lib/list_debug.c:53 >> __list_del_entry+0x63/0xd0() >> [ 1799.433093] list_del corruption, 8807b4a7c000->next is LIST_POISON1 >> (dead00100100) >> [ 1799.532110] Modules linked in: nf_conntrack_netbios_ns >> nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT >> nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat_ipv4 nf_nat >> iptable_mangle ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack >> nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tables >> iptable_filter ip_tables sg dm_mirror dm_region_hash dm_log dm_mod vfat fat >> e1000e igb iTCO_wdt iTCO_vendor_support ioatdma ptp i7core_edac ipmi_si >> edac_core lpc_ich pps_core i2c_i801 pcspkr mfd_core dca ipmi_msghandler >> acpi_cpufreq xfs libcrc32c sd_mod crc_t10dif crct10dif_common i2c_algo_bit >> drm_kms_helper ttm drm mptsas scsi_transport_sas mptscsih i2c_core >> megaraid_sas mptbase >> [ 1800.276623] CPU: 7 PID: 126 Comm: kworker/u512:1 Tainted: GW >> 3.12.0-rc5+ #196 >> [ 1800.508918] Workqueue: sysfsd sysfs_schedule_callback_work >> [ 1800.574703] 0009 8807adbadbd8 8168b26c >> 8807c27d08a8 >> [ 1800.663860] 8807adbadc28 8807adbadc18 810711dc >> 8807adbadc68 >> [ 1800.753130] 8807b4a7c000 8807b4a7c000 8807ad089c00 >> >> [ 1800.842282] Call Trace: >> [ 1800.871651] [] dump_stack+0x55/0x76 >> [ 1800.933301] [] warn_slowpath_common+0x8c/0xc0 >> [ 1801.005283] [] warn_slowpath_fmt+0x46/0x50 >> [ 1801.074081] [] __list_del_entry+0x63/0xd0 >> [ 1801.141839] [] list_del+0x11/0x40 >> [ 1801.201320] [] pci_remove_bus_device+0x6a/0xe0 >> [ 1801.274279] [] pci_stop_and_remove_bus_device+0x1e/0x30 >> [ 1801.356606] [] remove_callback+0x2b/0x40 >> [ 1801.423412] [] sysfs_schedule_callback_work+0x18/0x60 >> [ 1801.503744] [] process_one_work+0x1f5/0x540 >> [ 1801.573640] [] ? process_one_work+0x193/0x540 >> [ 1801.645616] [] worker_thread+0x11c/0x370 >> [ 1801.712337] [] ? rescuer_thread+0x350/0x350 >> [ 1801.782178] [] kthread+0xed/0x100 >> [ 1801.841661] [] ? kthread_create_on_node+0x160/0x160 >> [ 1801.919919] [] ret_from_fork+0x7c/0xb0 >> [ 1801.984608] [] ? kthread_create_on_node+0x160/0x160 >> [ 1802.062825] ---[ end trace d77f2054de000fb7 ]--- >> >> This issue is related to the bug 54411: >> https://bugzilla.kernel.org/show_bug.cgi?id=54411 >> >> Since we added the pci_bus reference management, the bug becomes a >> invalid list entry warning as descripted above. Beacuse it still >> trys to delete an deleted pci device from device list. >> >> So here we make stop device actually detach driver only, and remove >> device will do device_del instead, and move bus_list change and pci device >> resource free into pci_release_dev, so that it'll consistent with >> bus reference managment, and the device only can be deleted from device >> list in pci_release_dev just for one time. >> >> Besides, it also makes hostbridge to use device_unregister to be pair >> with device_register before. >> >> This patch is based on Yinghai's privious similar patch: >> http://lkml.org/lkml/2013/5/13/658 > > I have updated version, please check if attached patches fix the problem. > > virtfn_release.patch > fix_cx3_hotplug_2.patch > fix_racing_removing_6_1.patch > fix_racing_removing_6_2.patch > fix_racing_removing_6_3.patch It works well on latest Linus' tree, thanks. Regards, Gu > > Thanks > > Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] watchdog: at91sam9_wdt: various fixes
On 14:27 Tue 29 Oct , Guenter Roeck wrote:
> On Tue, Oct 29, 2013 at 06:22:47PM +0100, boris brezillon wrote:
> > On 29/10/2013 17:43, Guenter Roeck wrote:
> > >On Tue, Oct 29, 2013 at 05:22:50PM +0100, boris brezillon wrote:
> > >>On 29/10/2013 16:45, Guenter Roeck wrote:
> > >>>On Tue, Oct 29, 2013 at 11:37:33AM +0100, Boris BREZILLON wrote:
> > Fix the secs_to_ticks macro in case 0 is passed as an argument.
> >
> > Rework the heartbeat calculation to increase the security margin of the
> > watchdog reset timer.
> >
> > Use the min_heartbeat value instead of the calculated heartbeat value
> > for
> > the first watchdog reset.
> >
> > Signed-off-by: Boris BREZILLON
> > >>>Hi Boris,
> > >>>
> > >>>can you possibly split the three changes into separate patches ?
> > >>Sure. My first idea was to split this in 3 patches, but, as the
> > >>buggy at91 watchdog series was
> > >>already applied to linux-watchdog-next, I thought it would be faster
> > >>to only provide one
> > >>patch to fix all the issues at once.
> > >>
> > >>>The first is a no-brainer. Gives my opinion of my code review
> > >>>capabilities
> > >>>a slight damper ;-).
> > >>>
> > >>>For the other two problems, it might make sense to describe
> > >>>the problems you are trying to solve.
> > >>>
> > >>>Couple of comments inline.
> > >>>
> > >>>Thanks,
> > >>>Guenter
> > >>>
> > >>>
> > ---
> > drivers/watchdog/at91sam9_wdt.c | 35
> > ---
> > 1 file changed, 24 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/watchdog/at91sam9_wdt.c
> > b/drivers/watchdog/at91sam9_wdt.c
> > index 9bd089e..f1b59f1 100644
> > --- a/drivers/watchdog/at91sam9_wdt.c
> > +++ b/drivers/watchdog/at91sam9_wdt.c
> > @@ -51,7 +51,7 @@
> > #define ticks_to_hz_rounddown(t) t) + 1) * HZ) >> 8)
> > #define ticks_to_hz_roundup(t)(t) + 1) * HZ) +
> > 255) >> 8)
> > #define ticks_to_secs(t) (((t) + 1) >> 8)
> > -#define secs_to_ticks(s) (((s) << 8) - 1)
> > +#define secs_to_ticks(s) (s ? (((s) << 8) - 1) : 0)
> > >>> (s)
> > >>>
> > #define WDT_MR_RESET 0x3FFF2FFF
> > @@ -61,6 +61,11 @@
> > /* Watchdog max delta/value in secs */
> > #define WDT_COUNTER_MAX_SECS ticks_to_secs(WDT_COUNTER_MAX_TICKS)
> > +/* Watchdog heartbeat shift used for security margin:
> > + * we'll try to rshift the heartbeat value with this value to secure
> > + * the watchdog reset. */
> > +#define WDT_HEARTBEAT_SHIFT2
> > +
> > /* Hardware timeout in seconds */
> > #define WDT_HW_TIMEOUT 2
> > @@ -158,7 +163,9 @@ static int at91_wdt_init(struct platform_device
> > *pdev, struct at91wdt *wdt)
> > int err;
> > u32 mask = wdt->mr_mask;
> > unsigned long min_heartbeat = 1;
> > + unsigned long max_heartbeat;
> > struct device *dev = &pdev->dev;
> > + int shift;
> > tmp = wdt_read(wdt, AT91_WDT_MR);
> > if ((tmp & mask) != (wdt->mr & mask)) {
> > @@ -181,23 +188,27 @@ static int at91_wdt_init(struct platform_device
> > *pdev, struct at91wdt *wdt)
> > if (delta < value)
> > min_heartbeat = ticks_to_hz_roundup(value - delta);
> > - wdt->heartbeat = ticks_to_hz_rounddown(value);
> > - if (!wdt->heartbeat) {
> > + max_heartbeat = ticks_to_hz_rounddown(value);
> > + if (!max_heartbeat) {
> > dev_err(dev,
> > "heartbeat is too small for the system to
> > handle it correctly\n");
> > return -EINVAL;
> > }
> > - if (wdt->heartbeat < min_heartbeat + 4) {
> > + for (shift = WDT_HEARTBEAT_SHIFT; shift > 0; shift--) {
> > + if ((max_heartbeat >> shift) < min_heartbeat)
> > + continue;
> > +
> > + wdt->heartbeat = max_heartbeat >> shift;
> > + break;
> > + }
> > +
> > + if (!shift)
> > wdt->heartbeat = min_heartbeat;
> > >>>Correct me if I am wrong, but it seems to me that
> > >>>
> > >>> if ((max_heartbeat >> 2) >= min_heartbeat)
> > >>> wdt->heartbeat = max_heartbeat >> 2;
> > >>> else if ((max_heartbeat >> 1) >= min_heartbeat)
> > >>> wdt->heartbeat = max_heartbeat >> 1;
> > >>> else
> > >>> wdt->heartbeat = min_heartbeat;
> > >>>
> > >>>would accomplish the same and be easier to understand.
> > >>This is exactly what I'm trying to accomplish.
> > >>I used the for loop in case we ever want to change the
> > >>WDT_HEARTBEAT_SHIFT value
> > >>(which is unlikely to happen).
> > >>
> > >>I'll move to your proposition.
> > >>
> > >>>However, given that, I wonder if it is really necessary to bai
Re: [PATCH] x86: Run checksumming in parallel accross multiple alu's
* Neil Horman wrote: > > etc. For such short runtimes make sure the last column displays > > close to 100%, so that the PMU results become trustable. > > > > A nehalem+ PMU will allow 2-4 events to be measured in parallel, > > plus generics like 'cycles', 'instructions' can be added 'for free' > > because they get counted in a separate (fixed purpose) PMU register. > > > > The last colum tells you what percentage of the runtime that > > particular event was actually active. 100% (or empty last column) > > means it was active all the time. > > > > Thanks, > > > > Ingo > > > > Hmm, > > I ran this test: > > for i in `seq 0 1 3` > do > echo $i > /sys/module/csum_test/parameters/module_test_mode > taskset -c 0 perf stat --repeat 20 -C 0 -e L1-dcache-load-misses -e > L1-dcache-prefetches -e cycles -e instructions -ddd ./test.sh > done You need to remove '-ddd' which is a shortcut for a ton of useful events, but here you want to use fewer events, to increase the precision of the measurement. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 2/2] virtio-net: coalesce rx frags when possible during rx
Commit 2613af0ed18a11d5c566a81f9a6510b73180660a (virtio_net: migrate mergeable
rx buffers to page frag allocators) try to increase the payload/truesize for
MTU-sized traffic. But this will introduce the extra overhead for GSO packets
received because of the frag list. This commit tries to reduce this issue by
coalesce the possible rx frags when possible during rx. Test result shows the
about 15% improvement on full size GSO packet receiving (and even better than
commit 2613af0ed18a11d5c566a81f9a6510b73180660a).
Before this commit:
./netperf -H 192.168.100.4
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.100.4
() port 0 AF_INET : demo
Recv SendSend
Socket Socket Message Elapsed
Size SizeSize Time Throughput
bytes bytes bytessecs.10^6bits/sec
87380 16384 1638410.0020303.87
After this commit:
./netperf -H 192.168.100.4
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.100.4
() port 0 AF_INET : demo
Recv SendSend
Socket Socket Message Elapsed
Size SizeSize Time Throughput
bytes bytes bytessecs.10^6bits/sec
87380 16384 1638410.0023841.26
Cc: Rusty Russell
Cc: Michael S. Tsirkin
Cc: Michael Dalton
Cc: Eric Dumazet
Signed-off-by: Jason Wang
---
drivers/net/virtio_net.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 113ee93..4ff4f78 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -305,7 +305,7 @@ static int receive_mergeable(struct receive_queue *rq,
struct sk_buff *head_skb)
struct sk_buff *curr_skb = head_skb;
char *buf;
struct page *page;
- int num_buf, len;
+ int num_buf, len, offset;
num_buf = hdr->mhdr.num_buffers;
while (--num_buf) {
@@ -342,9 +342,15 @@ static int receive_mergeable(struct receive_queue *rq,
struct sk_buff *head_skb)
head_skb->truesize += MAX_PACKET_LEN;
}
page = virt_to_head_page(buf);
- skb_add_rx_frag(curr_skb, num_skb_frags, page,
- buf - (char *)page_address(page), len,
- MAX_PACKET_LEN);
+ offset = buf - (char *)page_address(page);
+ if (skb_can_coalesce(curr_skb, num_skb_frags, page, offset)) {
+ skb_coalesce_rx_frag(curr_skb, num_skb_frags - 1,
+offset, len, MAX_PACKET_LEN);
+ } else {
+ skb_add_rx_frag(curr_skb, num_skb_frags, page,
+ offset, len,
+ MAX_PACKET_LEN);
+ }
--rq->num;
}
return 0;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] KVM: x86: emulate SAHF instruction
Yet another instruction that we fail to emulate, this time found
in Windows 2008R2 32-bit.
Cc: sta...@vger.kernel.org
Signed-off-by: Paolo Bonzini
---
Testcase on its way. BTW, lahf/sahf is another candidate for
#UD emulation.
arch/x86/kvm/emulate.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 8e2a07bd8eac..ef750e75c930 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -3296,6 +3296,18 @@ static int em_cpuid(struct x86_emulate_ctxt *ctxt)
return X86EMUL_CONTINUE;
}
+static int em_sahf(struct x86_emulate_ctxt *ctxt)
+{
+ u32 flags;
+
+ flags = EFLG_CF | EFLG_PF | EFLG_AF | EFLG_ZF | EFLG_SF;
+ flags &= *reg_rmw(ctxt, VCPU_REGS_RAX) >> 8;
+
+ ctxt->eflags &= ~0xffUL;
+ ctxt->eflags |= flags | X86_EFLAGS_FIXED;
+ return X86EMUL_CONTINUE;
+}
+
static int em_lahf(struct x86_emulate_ctxt *ctxt)
{
*reg_rmw(ctxt, VCPU_REGS_RAX) &= ~0xff00UL;
@@ -3788,7 +3800,7 @@ static const struct opcode opcode_table[256] = {
DI(SrcAcc | DstReg, pause), X7(D(SrcAcc | DstReg)),
/* 0x98 - 0x9F */
D(DstAcc | SrcNone), I(ImplicitOps | SrcAcc, em_cwd),
- I(SrcImmFAddr | No64, em_call_far), N,
+ I(SrcImmFAddr | No64, em_call_far), I(ImplicitOps, em_sahf),
II(ImplicitOps | Stack, em_pushf, pushf),
II(ImplicitOps | Stack, em_popf, popf), N, I(ImplicitOps, em_lahf),
/* 0xA0 - 0xA7 */
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 1/2] net: introduce skb_coalesce_rx_frag()
Sometimes we need to coalesce the rx frags to avoid frag list. One example is
virtio-net driver which tries to use small frags for both MTU sized packet and
GSO packet. So this patch introduce skb_coalesce_rx_frag() to do this.
Cc: Rusty Russell
Cc: Michael S. Tsirkin
Cc: Michael Dalton
Cc: Eric Dumazet
Signed-off-by: Jason Wang
---
include/linux/skbuff.h | 3 +++
net/core/skbuff.c | 13 +
2 files changed, 16 insertions(+)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 2c15497..e34652b 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1372,6 +1372,9 @@ static inline void skb_fill_page_desc(struct sk_buff
*skb, int i,
void skb_add_rx_frag(struct sk_buff *skb, int i, struct page *page, int off,
int size, unsigned int truesize);
+void skb_coalesce_rx_frag(struct sk_buff *skb, int i, int off, int size,
+ unsigned int truesize);
+
#define SKB_PAGE_ASSERT(skb) BUG_ON(skb_shinfo(skb)->nr_frags)
#define SKB_FRAG_ASSERT(skb) BUG_ON(skb_has_frag_list(skb))
#define SKB_LINEAR_ASSERT(skb) BUG_ON(skb_is_nonlinear(skb))
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 0ab32fa..fdef994 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -476,6 +476,19 @@ void skb_add_rx_frag(struct sk_buff *skb, int i, struct
page *page, int off,
}
EXPORT_SYMBOL(skb_add_rx_frag);
+void skb_coalesce_rx_frag(struct sk_buff *skb, int i, int off, int size,
+ unsigned int truesize)
+{
+ skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
+
+ skb_frag_size_add(frag, size);
+ skb->len += size;
+ skb->data_len += size;
+ skb->truesize += truesize;
+ skb_frag_unref(skb, i);
+}
+EXPORT_SYMBOL(skb_coalesce_rx_frag);
+
static void skb_drop_list(struct sk_buff **listp)
{
kfree_skb_list(*listp);
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/6] procfs: Introduce sequential fdinfo engine
On Wed, Oct 30, 2013 at 10:59 PM, Cyrill Gorcunov wrote: > At moment the fdinfo operations (ie the output from /proc/$pid/fdinfo/$fd) > are generating output in one pass, which makes useless memory pressue > if the reader/user provides a buffer with a small size. cat(1) uses 64 KB buffer. The output doesn't exceed one page anyway. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
On 2013-10-30 00:25, Marek Belisko wrote: > Signed-off-by: Marek Belisko > Signed-off-by: H. Nikolaus Schaller > --- > changes from v2: > - move tx_buf from driver data to functions where it's used > - update write functions names (to reflect how many bytes are transferred) > - update delays from 1s to 1ms (probably typo) > - remove unnecessary 90ms sleep (tested and works fine) > - disable dpi output after disable panel > > changes from v1: > - reworked to be spi driver instead platform with custom spi bitbang > this configuration was tested with spi_gpio bitbang driver on gta04 board > and works fine (thanks Tomi and Lars-Peter for comments) > - address previous comments > > drivers/video/omap2/displays-new/Kconfig | 6 + > drivers/video/omap2/displays-new/Makefile | 1 + > .../omap2/displays-new/panel-tpo-td028ttec1.c | 480 > + > include/video/omap-panel-data.h| 13 + > 4 files changed, 500 insertions(+) > create mode 100644 drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c Sparse gave these warnings: drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c:67:5: warning: symbol 'jbt_ret_write_0' was not declared. Should it be static? drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c:81:5: warning: symbol 'jbt_reg_write_1' was not declared. Should it be static? drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c:97:5: warning: symbol 'jbt_reg_write_2' was not declared. Should it be static? I fixed them and queued the patch for 3.13. Tomi signature.asc Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the tty tree
On Thu, Oct 31, 2013 at 8:40 AM, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the tty tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/tty/serial/omap-serial.c: In function 'serial_omap_probe':
> drivers/tty/serial/omap-serial.c:1724:22: error: expected ')' before numeric
> constant
> drivers/tty/serial/omap-serial.c:1724:22: warning: format '%d' expects a
> matching 'int' argument [-Wformat]
>
> Caused by commit e5f9bf72efbc ("serial: omap: fix a few checkpatch
> warnings"). There is a missing ',' in the dev_warn() ...
>
> I have used the version of the tty tree from next-20131030 for today.
>
[ Add CC to linux-serial ML ]
Happy HelloWien and WelcomeBackStephen!
That was only checkpatch-tested, eh :-)?
@@ -1724,8 +1722,9 @@ static int serial_omap_probe(struct platform_device *pdev)
up->port.uartclk = omap_up_info->uartclk;
if (!up->port.uartclk) {
up->port.uartclk = DEFAULT_CLK_SPEED;
- dev_warn(&pdev->dev, "No clock speed specified: using default:"
- "%d\n", DEFAULT_CLK_SPEED);
+ dev_warn(&pdev->dev,
+ "No clock speed specified: using default: %d\n" <--- Comma missing here!
+ DEFAULT_CLK_SPEED);
}
- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -next] clk: keystone: fix return value check in _of_pll_clk_init()
From: Wei Yongjun
clk_register_pll() returns ERR_PTR() when memory alloc fail and NULL
in the other case, the user of this function should used IS_ERR_OR_NULL()
to check the return value. this patch change clk_register_pll() to return
only ERR_PTR(), and also fixed the user.
Signed-off-by: Wei Yongjun
---
drivers/clk/keystone/pll.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/keystone/pll.c b/drivers/clk/keystone/pll.c
index 47a1bd9..78a6e0e 100644
--- a/drivers/clk/keystone/pll.c
+++ b/drivers/clk/keystone/pll.c
@@ -127,12 +127,9 @@ static struct clk *clk_register_pll(struct device *dev,
clk = clk_register(NULL, &pll->hw);
if (IS_ERR(clk))
- goto out;
+ kfree(pll);
return clk;
-out:
- kfree(pll);
- return NULL;
}
/**
@@ -182,7 +179,7 @@ static void __init _of_pll_clk_init(struct device_node
*node, bool pllctrl)
}
clk = clk_register_pll(NULL, node->name, parent_name, pll_data);
- if (clk) {
+ if (!IS_ERR(clk)) {
of_clk_add_provider(node, of_clk_src_simple_get, clk);
return;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] fb: reorder the lock sequence to fix potential dead lock
Following commits:
50e244cc79 fb: rework locking to fix lock ordering on takeover
e93a9a8687 fb: Yet another band-aid for fixing lockdep mess
054430e773 fbcon: fix locking harder
reworked locking to fix related lock ordering on takeover, and introduced
console_lock
into fbmem, but it seems that the new lock sequence(fb_info->lock --->
console_lock)
is against with the one in console_callback(console_lock ---> fb_info->lock),
and leads to
a potential dead lock as following:
[ 601.079000] ==
[ 601.079000] [ INFO: possible circular locking dependency detected ]
[ 601.079000] 3.11.0 #189 Not tainted
[ 601.079000] ---
[ 601.079000] kworker/0:3/619 is trying to acquire lock:
[ 601.079000] (&fb_info->lock){+.+.+.}, at: []
lock_fb_info+0x26/0x60
[ 601.079000]
but task is already holding lock:
[ 601.079000] (console_lock){+.+.+.}, at: []
console_callback+0x13/0x160
[ 601.079000]
which lock already depends on the new lock.
[ 601.079000]
the existing dependency chain (in reverse order) is:
[ 601.079000]
-> #1 (console_lock){+.+.+.}:
[ 601.079000][] lock_acquire+0xa1/0x140
[ 601.079000][] console_lock+0x77/0x80
[ 601.079000][] register_framebuffer+0x1d8/0x320
[ 601.079000][] efifb_probe+0x408/0x48f
[ 601.079000][] platform_drv_probe+0x43/0x80
[ 601.079000][] driver_probe_device+0x8b/0x390
[ 601.079000][] __driver_attach+0xab/0xb0
[ 601.079000][] bus_for_each_dev+0x5d/0xa0
[ 601.079000][] driver_attach+0x1e/0x20
[ 601.079000][] bus_add_driver+0x117/0x290
[ 601.079000][] driver_register+0x7a/0x170
[ 601.079000][] __platform_driver_register+0x4a/0x50
[ 601.079000][] platform_driver_probe+0x1d/0xb0
[ 601.079000][] efifb_init+0x273/0x292
[ 601.079000][] do_one_initcall+0x102/0x1c0
[ 601.079000][] kernel_init_freeable+0x15d/0x1ef
[ 601.079000][] kernel_init+0xe/0xf0
[ 601.079000][] ret_from_fork+0x7c/0xb0
[ 601.079000]
-> #0 (&fb_info->lock){+.+.+.}:
[ 601.079000][] __lock_acquire+0x1e18/0x1f10
[ 601.079000][] lock_acquire+0xa1/0x140
[ 601.079000][] mutex_lock_nested+0x7a/0x3b0
[ 601.079000][] lock_fb_info+0x26/0x60
[ 601.079000][] fbcon_blank+0x29b/0x2e0
[ 601.079000][] do_blank_screen+0x1d8/0x280
[ 601.079000][] console_callback+0x64/0x160
[ 601.079000][] process_one_work+0x1f5/0x540
[ 601.079000][] worker_thread+0x11c/0x370
[ 601.079000][] kthread+0xed/0x100
[ 601.079000][] ret_from_fork+0x7c/0xb0
[ 601.079000]
other info that might help us debug this:
[ 601.079000] Possible unsafe locking scenario:
[ 601.079000]CPU0CPU1
[ 601.079000]
[ 601.079000] lock(console_lock);
[ 601.079000]lock(&fb_info->lock);
[ 601.079000]lock(console_lock);
[ 601.079000] lock(&fb_info->lock);
[ 601.079000]
*** DEADLOCK ***
so we reorder the lock sequence the same as it in console_callback() to
avoid this issue. And following Tomi's suggestion, fix these similar
issues all in fb subsystem.
Signed-off-by: Gu Zheng
---
drivers/video/fbmem.c| 50 -
drivers/video/fbsysfs.c | 19 ++
drivers/video/sh_mobile_lcdcfb.c | 10 ---
3 files changed, 51 insertions(+), 28 deletions(-)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index dacaf74..010d191 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1108,14 +1108,16 @@ static long do_fb_ioctl(struct fb_info *info, unsigned
int cmd,
case FBIOPUT_VSCREENINFO:
if (copy_from_user(&var, argp, sizeof(var)))
return -EFAULT;
- if (!lock_fb_info(info))
- return -ENODEV;
console_lock();
+ if (!lock_fb_info(info)) {
+ console_unlock();
+ return -ENODEV;
+ }
info->flags |= FBINFO_MISC_USEREVENT;
ret = fb_set_var(info, &var);
info->flags &= ~FBINFO_MISC_USEREVENT;
- console_unlock();
unlock_fb_info(info);
+ console_unlock();
if (!ret && copy_to_user(argp, &var, sizeof(var)))
ret = -EFAULT;
break;
@@ -1144,12 +1146,14 @@ static long do_fb_ioctl(struct fb_info *info, unsigned
int cmd,
case FBIOPAN_DISPLAY:
if (copy_from_user(&var, argp, sizeof(var)))
return -EFAULT;
- if (!lock_fb_info(info))
- return -ENODEV;
console_lock();
+ if (!lock_fb_info(info)) {
+
Re: [PATCH v2] efifb: prevent null-deref when iterating dmi_list
On 18:40 Wed 02 Oct , David Herrmann wrote:
> The dmi_list array is initialized using gnu designated initializers, and
> therefore may contain fewer explicitly defined entries as there are
> elements in it. This is because the enum above with M_xyz constants
> contains more items than the designated initializer. Those elements not
> explicitly initialized are implicitly set to 0.
>
> Now efifb_setup() loops through all these array elements, and performs
> a strcmp on each item. For non explicitly initialized elements this will
> be a null pointer:
>
> This patch swaps the check order in the if statement, thus checks first
> whether dmi_list[i].base is null.
>
> Signed-off-by: James Bates
> Signed-off-by: David Herrmann
with the simpleDRM arriving next merge I'm wondering if we need to keep it?
Best Regaards,
J.
> ---
> Hi
>
> As James didn't respond to the last emails, I just rebased the patch and
> resent
> it. The efi M_xyz constants were moved to x86-sysfb so if anyone wants to
> remove
> unused bits, please send a separate patch to LKML and x86-ML. This patch just
> fixes the NULL-deref.
>
> Thanks
> David
>
> drivers/video/efifb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
> index 7f9ff75..fcb9500 100644
> --- a/drivers/video/efifb.c
> +++ b/drivers/video/efifb.c
> @@ -108,8 +108,8 @@ static int efifb_setup(char *options)
> if (!*this_opt) continue;
>
> for (i = 0; i < M_UNKNOWN; i++) {
> - if (!strcmp(this_opt,
> efifb_dmi_list[i].optname) &&
> - efifb_dmi_list[i].base != 0) {
> + if (efifb_dmi_list[i].base != 0 &&
> + !strcmp(this_opt,
> efifb_dmi_list[i].optname)) {
> screen_info.lfb_base =
> efifb_dmi_list[i].base;
> screen_info.lfb_linelength =
> efifb_dmi_list[i].stride;
> screen_info.lfb_width =
> efifb_dmi_list[i].width;
> --
> 1.8.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
Dear Mr. Young, On Thu, Oct 31, 2013 at 10:07:14AM +0800, Dave Young wrote: > > But Frankly I'd like to see them in list instead even with only small fixes > > beacuse in this way there might be more people to review it carefully. > > There's another shorcoming for keeping new patches in git is that nobody know > when you push it and when is the proper date to pull from your git. I think > it's better to use git only for the patches which have already been accepted > and is waiting for maintainer to pull. thank you for teaching me how to do kernel development! The actual and real reason why I didn't send them yet is because I didn't want to be that kaffeine-inflated dork who spams the lists every other day with a new version of his patches. I am running build smoketests now and will send the latest version of the patchset later today so don't worry, the world will see them :) -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
On Wed, Oct 30, 2013 at 08:07:45PM -0700, H. Peter Anvin wrote: > You can use git for your own purposes, still. git mk-coffee --refill --now -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] perf/x86/amd: AMD support for bp_len > HW_BREAKPOINT_LEN_8
fix tglx's address. On Thu, Oct 31, 2013 at 10:58:31AM +0100, Frederic Weisbecker wrote: > Is this perhaps a bit too generic? Extension can mean about everything > and who knows what other feature Intel and Amd will add to breakpoints > in the future. Yeah, but that's the name of the feature. When they come up with another extension, they'll call it BP_EXT2, most probably... :-) -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: New kconfig maintainer
Dne 30.10.2013 19:22, Yann E. MORIN napsal(a): > Michal, All, > > On 2013-10-30 12:07 +0100, Michal Marek spake thusly: >> Yann has been the de facto maintainer of kconfig for some time. Update >> the KCONFIG entry with his emails address and git tree. >> >> Cc: "Yann E. MORIN" >> Signed-off-by: Michal Marek > > Acked-by: "Yann E. MORIN" > > Thank you for the trust you've put in me with this patch! :-) > > Shall I take this in my tree, or will you add it to yours? I'll add it. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V2 1/7] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
Hi Thomas,
Sorry for top posting. My mailer is not allowing me any formatting.
I agree with both of your comments below.
I will post V3 for this.
Regards,
Sricharan
From: Thomas Gleixner [t...@linutronix.de]
Sent: Wednesday, October 30, 2013 8:45 PM
To: R, Sricharan
Cc: linux-kernel@vger.kernel.org; devicet...@vger.kernel.org;
linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
linux-o...@vger.kernel.org; linus.wall...@linaro.org; li...@arm.linux.org.uk;
t...@atomide.com; Nayak, Rajendra; marc.zyng...@arm.com;
grant.lik...@linaro.org; mark.rutl...@arm.com; robherri...@gmail.com;
Shilimkar, Santosh; Rob Herring
Subject: Re: [PATCH V2 1/7] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable
irqs
On Wed, 30 Oct 2013, Sricharan R wrote:
> @@ -700,11 +709,22 @@ static int gic_irq_domain_xlate(struct irq_domain *d,
> *out_hwirq = intspec[1] + 16;
>
> /* For SPIs, we need to add 16 more to get the GIC irq ID number */
> - if (!intspec[0])
> + if (!intspec[0]) {
> *out_hwirq += 16;
Minor nit. This should be in the default implementation. The crossbar
implementation will fill out_hwirq in its own way and is not
interested in the +16 operation at all.
> + ret = gic_routable_irq_domain_ops->xlate(d, controller,
> + intspec,
> + intsize,
> + out_hwirq,
> + out_type);
> +
> + gic->domain = irq_domain_add_legacy(node, gic_irqs, irq_base,
> + hwirq_base, &gic_irq_domain_ops, gic);
> + } else {
> + if (WARN_ON(!gic_routable_irq_domain_ops))
> + return;
This warning is pointless, because you have default ops now.
> +
> + gic->domain = irq_domain_add_linear(node, nr_routable_irqs,
> + &gic_irq_domain_ops,
> + gic);
> }
Thanks,
tglx--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:core/locking] hung_task debugging: Add tracepoint to report the hang
Commit-ID: 6a716c90a51338009c3bc1f460829afaed8f922d
Gitweb: http://git.kernel.org/tip/6a716c90a51338009c3bc1f460829afaed8f922d
Author: Oleg Nesterov
AuthorDate: Sat, 19 Oct 2013 18:18:28 +0200
Committer: Ingo Molnar
CommitDate: Thu, 31 Oct 2013 11:16:18 +0100
hung_task debugging: Add tracepoint to report the hang
Currently check_hung_task() prints a warning if it detects the
problem, but it is not convenient to watch the system logs if
user-space wants to be notified about the hang.
Add the new trace_sched_process_hang() into check_hung_task(),
this way a user-space monitor can easily wait for the hang and
potentially resolve a problem.
Signed-off-by: Oleg Nesterov
Cc: Dave Sullivan
Cc: Peter Zijlstra
Cc: Steven Rostedt
Link: http://lkml.kernel.org/r/20131019161828.ga7...@redhat.com
Signed-off-by: Ingo Molnar
---
include/trace/events/sched.h | 19 +++
kernel/hung_task.c | 4
2 files changed, 23 insertions(+)
diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
index 2e7d994..2a652d1 100644
--- a/include/trace/events/sched.h
+++ b/include/trace/events/sched.h
@@ -424,6 +424,25 @@ TRACE_EVENT(sched_pi_setprio,
__entry->oldprio, __entry->newprio)
);
+#ifdef CONFIG_DETECT_HUNG_TASK
+TRACE_EVENT(sched_process_hang,
+ TP_PROTO(struct task_struct *tsk),
+ TP_ARGS(tsk),
+
+ TP_STRUCT__entry(
+ __array( char, comm, TASK_COMM_LEN )
+ __field( pid_t, pid )
+ ),
+
+ TP_fast_assign(
+ memcpy(__entry->comm, tsk->comm, TASK_COMM_LEN);
+ __entry->pid = tsk->pid;
+ ),
+
+ TP_printk("comm=%s pid=%d", __entry->comm, __entry->pid)
+);
+#endif /* CONFIG_DETECT_HUNG_TASK */
+
#endif /* _TRACE_SCHED_H */
/* This part must be outside protection */
diff --git a/kernel/hung_task.c b/kernel/hung_task.c
index 0422523..8807061 100644
--- a/kernel/hung_task.c
+++ b/kernel/hung_task.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
/*
* The number of tasks checked:
@@ -92,6 +93,9 @@ static void check_hung_task(struct task_struct *t, unsigned
long timeout)
t->last_switch_count = switch_count;
return;
}
+
+ trace_sched_process_hang(t);
+
if (!sysctl_hung_task_warnings)
return;
sysctl_hung_task_warnings--;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] MAINTAINERS: fix broken link to www.linux-kvm.org
Cc: Gleb Natapov Cc: Paolo Bonzini Signed-off-by: Ramkumar Ramachandra --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 3438384..1dd73f7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4835,7 +4835,7 @@ KERNEL VIRTUAL MACHINE (KVM) M: Gleb Natapov M: Paolo Bonzini L: k...@vger.kernel.org -W: http://linux-kvm.org +W: http://www.linux-kvm.org S: Supported F: Documentation/*/kvm*.txt F: Documentation/virtual/kvm/ -- 1.8.5.rc0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] Documentation/kvm: patches should be against linux.git
The document hasn't been updated since cf3e3d3 (KVM: Document KVM specific review items, 2010-06-24); kvm does not have a separate repository anymore. Cc: Avi Kivity Cc: Gleb Natapov Cc: Paolo Bonzini Signed-off-by: Ramkumar Ramachandra --- Documentation/virtual/kvm/review-checklist.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/virtual/kvm/review-checklist.txt b/Documentation/virtual/kvm/review-checklist.txt index a850986..8385c4d 100644 --- a/Documentation/virtual/kvm/review-checklist.txt +++ b/Documentation/virtual/kvm/review-checklist.txt @@ -4,7 +4,7 @@ Review checklist for kvm patches 1. The patch must follow Documentation/CodingStyle and Documentation/SubmittingPatches. -2. Patches should be against kvm.git master branch. +2. Patches should be against linux.git master branch. 3. If the patch introduces or modifies a new userspace API: - the API must be documented in Documentation/virtual/kvm/api.txt -- 1.8.5.rc0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] Documentation/kvm: add a 00-INDEX file
Cc: Gleb Natapov Cc: Paolo Bonzini Signed-off-by: Ramkumar Ramachandra --- Documentation/virtual/kvm/00-INDEX | 24 1 file changed, 24 insertions(+) create mode 100644 Documentation/virtual/kvm/00-INDEX diff --git a/Documentation/virtual/kvm/00-INDEX b/Documentation/virtual/kvm/00-INDEX new file mode 100644 index 000..1d339cd --- /dev/null +++ b/Documentation/virtual/kvm/00-INDEX @@ -0,0 +1,24 @@ +00-INDEX + - this file. +api.txt + - the definitive KVM API documentation. +cpuid.txt + - notes on KVM cpuid functions. +devices/ + - directory with info on device bindings for KVM_CAP_DEVICE_CTRL. +hypercalls.txt + - info on the KVM hypercalls. +locking.txt + - notes on KVM locks. +mmu.txt + - the x86 kvm shadow mmu. +msr.txt + - list of custom MSRs in KVM. +nested-vmx.txt + - notes on a feature enabling nested VMX guests. +ppc-pv.txt + - the paravirtualization interface on PowerPC. +review-checklist.txt + - review checklist for KVM patches. +timekeeping.txt + - info on timekeeping virtualization for x86-based architectures. -- 1.8.5.rc0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] Small patches around kvm doc
Hi, I was going through the kvm documentation when I noticed the following minor nits. Thanks. Ramkumar Ramachandra (3): MAINTAINERS: fix broken link to www.linux-kvm.org Documentation/kvm: patches should be against linux.git Documentation/kvm: add a 00-INDEX file Documentation/virtual/kvm/00-INDEX | 24 Documentation/virtual/kvm/review-checklist.txt | 2 +- MAINTAINERS| 2 +- 3 files changed, 26 insertions(+), 2 deletions(-) create mode 100644 Documentation/virtual/kvm/00-INDEX -- 1.8.5.rc0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/3] Support for perf to probe into SDT markers:
On Wed, 2013-10-30 at 13:51 +0200, Pekka Enberg wrote: > On 10/30/13 12:05 PM, Masami Hiramatsu wrote: > > To find all system libraries, we can use ldconfig. > > > > $ ldconfig --print-cache > > > > shows what dynamic libraries will be loaded. On my own laptop (running > > ubuntu13.04) shows ~1000 libs. > > Good point. That definitely narrows down the scanned set. It is fast. But that would miss the various libjvm.so variants for example. Or other programs, like libreoffice, which have SDT probes in their internal shared libraries that aren't in the default ldconfig paths. Cheers, Mark -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/3] Support for perf to probe into SDT markers:
* Mark Wielaard wrote: > On Wed, 2013-10-30 at 13:51 +0200, Pekka Enberg wrote: > > On 10/30/13 12:05 PM, Masami Hiramatsu wrote: > > > To find all system libraries, we can use ldconfig. > > > > > > $ ldconfig --print-cache > > > > > > shows what dynamic libraries will be loaded. On my own laptop (running > > > ubuntu13.04) shows ~1000 libs. > > > > Good point. That definitely narrows down the scanned set. > > It is fast. But that would miss the various libjvm.so variants for > example. Or other programs, like libreoffice, which have SDT > probes in their internal shared libraries that aren't in the > default ldconfig paths. I suppose those Java libraries ought to show up in /etc/prelink.cache though, right? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/6] procfs: Introduce sequential fdinfo engine
On Thu, Oct 31, 2013 at 01:32:13PM +0300, Alexey Dobriyan wrote: > On Wed, Oct 30, 2013 at 10:59 PM, Cyrill Gorcunov wrote: > > At moment the fdinfo operations (ie the output from /proc/$pid/fdinfo/$fd) > > are generating output in one pass, which makes useless memory pressue > > if the reader/user provides a buffer with a small size. > > cat(1) uses 64 KB buffer. > The output doesn't exceed one page anyway. Yes, good point. I probably need to update changelog (forgot that i'm using single_open here). What if we meet a file with that big number of epoll or say notifies assigned that the fdinfo won't fit a page? I didn't meet such scenario yet, but I think it's possible? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V2 2/7] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
Hi Thomas,
Again sorry for top post.
I agree and will fix both of the comments below.
Thanks for the reviews.
Regards,
Sricharan
From: Thomas Gleixner [t...@linutronix.de]
Sent: Wednesday, October 30, 2013 9:00 PM
To: R, Sricharan
Cc: linux-kernel@vger.kernel.org; devicet...@vger.kernel.org;
linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
linux-o...@vger.kernel.org; linus.wall...@linaro.org; li...@arm.linux.org.uk;
t...@atomide.com; Nayak, Rajendra; marc.zyng...@arm.com;
grant.lik...@linaro.org; mark.rutl...@arm.com; robherri...@gmail.com;
Shilimkar, Santosh; Rob Herring
Subject: Re: [PATCH V2 2/7] DRIVERS: IRQCHIP: CROSSBAR: Add support for
Crossbar IP
On Wed, 30 Oct 2013, Sricharan R wrote:
> +static inline const u32 allocate_free_irq(int cb_no)
I understand the "static inline" part, but "const u32" is more than
fishy. What's wrong with "static inline int" ?
> +{
> + int i;
> +
> + for (i = 0; i < cb->int_max; i++) {
> + if (cb->irq_map[i] == IRQ_FREE) {
> + cb->irq_map[i] = cb_no;
> + return i;
> + }
> + }
> +
> + return -ENODEV;
> +}
> +static int crossbar_domain_xlate(struct irq_domain *d,
> + struct device_node *controller,
> + const u32 *intspec, unsigned int intsize,
> + unsigned long *out_hwirq,
> + unsigned int *out_type)
> +{
> + unsigned long ret = 0;
Why do you need to initialize ret when you assign a value to it in the
next line?
Thanks,
tglx--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Documentation/kvm: patches should be against linux.git
Il 31/10/2013 11:46, Ramkumar Ramachandra ha scritto: > The document hasn't been updated since cf3e3d3 (KVM: Document KVM > specific review items, 2010-06-24); kvm does not have a separate > repository anymore. Maintainer have their repository at git://git.kernel.org/pub/scm/virt/kvm/kvm.git. The right fix is to add that tree to MAINTAINERS. Paolo > Cc: Avi Kivity > Cc: Gleb Natapov > Cc: Paolo Bonzini > Signed-off-by: Ramkumar Ramachandra > --- > Documentation/virtual/kvm/review-checklist.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/virtual/kvm/review-checklist.txt > b/Documentation/virtual/kvm/review-checklist.txt > index a850986..8385c4d 100644 > --- a/Documentation/virtual/kvm/review-checklist.txt > +++ b/Documentation/virtual/kvm/review-checklist.txt > @@ -4,7 +4,7 @@ Review checklist for kvm patches > 1. The patch must follow Documentation/CodingStyle and > Documentation/SubmittingPatches. > > -2. Patches should be against kvm.git master branch. > +2. Patches should be against linux.git master branch. > > 3. If the patch introduces or modifies a new userspace API: > - the API must be documented in Documentation/virtual/kvm/api.txt > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 1/2] net: introduce skb_coalesce_rx_frag()
On Thu, Oct 31, 2013 at 6:28 PM, Jason Wang wrote:
> Sometimes we need to coalesce the rx frags to avoid frag list. One example is
> virtio-net driver which tries to use small frags for both MTU sized packet and
> GSO packet. So this patch introduce skb_coalesce_rx_frag() to do this.
>
> Cc: Rusty Russell
> Cc: Michael S. Tsirkin
> Cc: Michael Dalton
> Cc: Eric Dumazet
> Signed-off-by: Jason Wang
> ---
> include/linux/skbuff.h | 3 +++
> net/core/skbuff.c | 13 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 2c15497..e34652b 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -1372,6 +1372,9 @@ static inline void skb_fill_page_desc(struct sk_buff
> *skb, int i,
> void skb_add_rx_frag(struct sk_buff *skb, int i, struct page *page, int off,
> int size, unsigned int truesize);
>
> +void skb_coalesce_rx_frag(struct sk_buff *skb, int i, int off, int size,
> + unsigned int truesize);
> +
> #define SKB_PAGE_ASSERT(skb) BUG_ON(skb_shinfo(skb)->nr_frags)
> #define SKB_FRAG_ASSERT(skb) BUG_ON(skb_has_frag_list(skb))
> #define SKB_LINEAR_ASSERT(skb) BUG_ON(skb_is_nonlinear(skb))
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 0ab32fa..fdef994 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -476,6 +476,19 @@ void skb_add_rx_frag(struct sk_buff *skb, int i, struct
> page *page, int off,
> }
> EXPORT_SYMBOL(skb_add_rx_frag);
>
> +void skb_coalesce_rx_frag(struct sk_buff *skb, int i, int off, int size,
> + unsigned int truesize)
> +{
> + skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
> +
> + skb_frag_size_add(frag, size);
> + skb->len += size;
> + skb->data_len += size;
> + skb->truesize += truesize;
> + skb_frag_unref(skb, i);
> +}
I didn't see you use "off" in skb_coalesce_rx_frag.
> +EXPORT_SYMBOL(skb_coalesce_rx_frag);
> +
> static void skb_drop_list(struct sk_buff **listp)
> {
> kfree_skb_list(*listp);
> --
> 1.8.1.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] MAINTAINERS: add tree for kvm.git
Cc: Gleb Natapov Cc: Paolo Bonzini Cc: KVM List Signed-off-by: Ramkumar Ramachandra --- This is a replacement for [PATCH 2/3] Documentation/kvm: patches should be against linux.git Thanks to Paolo for pointing to the right tree. MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 1dd73f7..36b05119 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4836,6 +4836,7 @@ M:Gleb Natapov M: Paolo Bonzini L: k...@vger.kernel.org W: http://www.linux-kvm.org +T: git git://git.kernel.org/pub/scm/virt/kvm/kvm.git S: Supported F: Documentation/*/kvm*.txt F: Documentation/virtual/kvm/ -- 1.8.5.rc0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] MAINTAINERS: Add git tree for KVM
Signed-off-by: Paolo Bonzini --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index fed84d861e7f..366f90cc6fdb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4815,6 +4815,7 @@ M:Gleb Natapov M: Paolo Bonzini L: k...@vger.kernel.org W: http://www.linux-kvm.org +T: git git://git.kernel.org/pub/scm/virt/kvm/kvm.git S: Supported F: Documentation/*/kvm*.txt F: Documentation/virtual/kvm/ -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] iommu/arm-smmu: Use devm_ioremap_resource
While at it, propagate the error code.
Signed-off-by: Tushar Behera
CC: linux-arm-ker...@lists.infradead.org
CC: io...@lists.linux-foundation.org
CC: Will Deacon
CC: Joerg Roedel
---
drivers/iommu/arm-smmu.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 2349d62..fe275b3 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1790,9 +1790,9 @@ static int arm_smmu_device_dt_probe(struct
platform_device *pdev)
}
smmu->size = resource_size(res);
- smmu->base = devm_request_and_ioremap(dev, res);
- if (!smmu->base)
- return -EADDRNOTAVAIL;
+ smmu->base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(smmu->base))
+ return PTR_ERR(smmu->base);
if (of_property_read_u32(dev->of_node, "#global-interrupts",
&smmu->num_global_irqs)) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] MAINTAINERS: add tree for kvm.git
Il 31/10/2013 11:59, Ramkumar Ramachandra ha scritto: > Cc: Gleb Natapov > Cc: Paolo Bonzini > Cc: KVM List > Signed-off-by: Ramkumar Ramachandra > --- > This is a replacement for [PATCH 2/3] Documentation/kvm: patches > should be against linux.git > > Thanks to Paolo for pointing to the right tree. > > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 1dd73f7..36b05119 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4836,6 +4836,7 @@ M: Gleb Natapov > M: Paolo Bonzini > L: k...@vger.kernel.org > W: http://www.linux-kvm.org > +T: git git://git.kernel.org/pub/scm/virt/kvm/kvm.git > S: Supported > F: Documentation/*/kvm*.txt > F: Documentation/virtual/kvm/ > Looks like we crossed. :) I'm applying this patch and the other 2 from the first submission. Thanks! Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] DRM: Armada: Use devm_ioremap_resource
While at it, propagate the error code.
Signed-off-by: Tushar Behera
CC: dri-de...@lists.freedesktop.org
CC: Russell King
CC: David Airlie
---
drivers/gpu/drm/armada/armada_crtc.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index d8e3982..2b6e7b7 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -1037,11 +1037,9 @@ int armada_drm_crtc_create(struct drm_device *dev,
unsigned num,
if (ret)
return ret;
- base = devm_request_and_ioremap(dev->dev, res);
- if (!base) {
- DRM_ERROR("failed to ioremap register\n");
- return -ENOMEM;
- }
+ base = devm_ioremap_resource(dev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
dcrtc = kzalloc(sizeof(*dcrtc), GFP_KERNEL);
if (!dcrtc) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
