[PATCH/RFC 01/16] perf top: Delete half-processed hist entries when exit
After sample processing is done, hist entries are in both of
hists->entries and hists->entries_in (or hists->entries_collapsed).
So I guess perf report does not have leaks on hists.
But for perf top, it's possible to have half-processed entries which
are only in hists->entries_in. Eventually they will go to the
hists->entries and get freed but they cannot be deleted by current
hists__delete_entries(). This patch adds hists__delete_all_entries
function to delete those entries.
Cc: Masami Hiramatsu
Signed-off-by: Namhyung Kim
---
tools/perf/util/hist.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 565ea3549894..56e97f5af598 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -270,6 +270,8 @@ static void hists__delete_entry(struct hists *hists, struct
hist_entry *he)
if (sort__need_collapse)
rb_erase(>rb_node_in, >entries_collapsed);
+ else
+ rb_erase(>rb_node_in, hists->entries_in);
--hists->nr_entries;
if (!he->filtered)
@@ -1567,11 +1569,33 @@ static int hists_evsel__init(struct perf_evsel *evsel)
return 0;
}
+static void hists__delete_remaining_entries(struct rb_root *root)
+{
+ struct rb_node *node;
+ struct hist_entry *he;
+
+ while (!RB_EMPTY_ROOT(root)) {
+ node = rb_first(root);
+ rb_erase(node, root);
+
+ he = rb_entry(node, struct hist_entry, rb_node_in);
+ hist_entry__delete(he);
+ }
+}
+
+static void hists__delete_all_entries(struct hists *hists)
+{
+ hists__delete_entries(hists);
+ hists__delete_remaining_entries(>entries_in_array[0]);
+ hists__delete_remaining_entries(>entries_in_array[1]);
+ hists__delete_remaining_entries(>entries_collapsed);
+}
+
static void hists_evsel__exit(struct perf_evsel *evsel)
{
struct hists *hists = evsel__hists(evsel);
- hists__delete_entries(hists);
+ hists__delete_all_entries(hists);
}
/*
--
2.6.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/RFC 10/16] perf hist: Add events_stats__add() and hists__add_stats()
These two functions are to update event and hists stats. They'll be
used by multi threads to update local stats in the later patch.
Signed-off-by: Namhyung Kim
---
tools/perf/util/hist.c | 23 +++
tools/perf/util/hist.h | 6 ++
2 files changed, 29 insertions(+)
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index a12e5022fe04..08396a7fea23 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -1347,6 +1347,29 @@ void events_stats__inc(struct events_stats *stats, u32
type)
++stats->nr_events[type];
}
+void events_stats__add(struct events_stats *dst, struct events_stats *src)
+{
+ int i;
+
+#define ADD(_field) dst->_field += src->_field
+
+ ADD(total_period);
+ ADD(total_non_filtered_period);
+ ADD(total_lost);
+ ADD(total_invalid_chains);
+ ADD(nr_non_filtered_samples);
+ ADD(nr_lost_warned);
+ ADD(nr_unknown_events);
+ ADD(nr_invalid_chains);
+ ADD(nr_unknown_id);
+ ADD(nr_unprocessable_samples);
+
+ for (i = 0; i < PERF_RECORD_HEADER_MAX; i++)
+ ADD(nr_events[i]);
+
+#undef ADD
+}
+
void hists__inc_nr_events(struct hists *hists, u32 type)
{
events_stats__inc(>stats, type);
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 670720ef8acd..725afce73738 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -141,8 +141,14 @@ void hists__inc_stats(struct hists *hists, struct
hist_entry *h);
void hists__inc_nr_events(struct hists *hists, u32 type);
void hists__inc_nr_samples(struct hists *hists, bool filtered);
void events_stats__inc(struct events_stats *stats, u32 type);
+void events_stats__add(struct events_stats *dst, struct events_stats *src);
size_t events_stats__fprintf(struct events_stats *stats, FILE *fp);
+static inline void hists__add_stats(struct hists *dst, struct hists *src)
+{
+ events_stats__add(>stats, >stats);
+}
+
size_t hists__fprintf(struct hists *hists, bool show_header, int max_rows,
int max_cols, float min_pcnt, FILE *fp);
size_t perf_evlist__fprintf_nr_events(struct perf_evlist *evlist, FILE *fp);
--
2.6.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/RFC 05/16] perf top: Show warning messages in the display thread
Currently perf top shows warning dialog during processing samples
which means it interrupts the processing. So it'd be better if reader
threads just save the warning information and display thread show the
message. Now warning is managed to have their priority so that higher
priority messages don't get overwritten by lower messages.
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-top.c | 224 ++-
1 file changed, 162 insertions(+), 62 deletions(-)
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 7a237719037a..aafcf27c437e 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -143,68 +143,90 @@ static void __zero_source_counters(struct hist_entry *he)
symbol__annotate_zero_histograms(sym);
}
-static void ui__warn_map_erange(struct perf_top *top __maybe_unused,
- struct addr_location *al)
+static int perf_top__check_map_erange(struct perf_top *top __maybe_unused,
+ struct addr_location *al)
+{
+ return al->map->erange_warned;
+}
+
+static void perf_top__warn_map_erange(struct perf_top *top __maybe_unused,
+ struct addr_location *al)
{
struct map *map = al->map;
struct symbol *sym = al->sym;
u64 ip = al->addr;
+ struct utsname uts;
+ int err = uname();
- if (!map->erange_warned) {
- struct utsname uts;
- int err = uname();
-
- ui__warning("Out of bounds address found:\n\n"
- "Addr: %" PRIx64 "\n"
- "DSO:%s %c\n"
- "Map:%" PRIx64 "-%" PRIx64 "\n"
- "Symbol: %" PRIx64 "-%" PRIx64 " %c %s\n"
- "Arch: %s\n"
- "Kernel: %s\n"
- "Tools: %s\n\n"
- "Not all samples will be on the annotation
output.\n\n"
- "Please report to linux-kernel@vger.kernel.org\n",
- ip, map->dso->long_name,
dso__symtab_origin(map->dso),
- map->start, map->end, sym->start, sym->end,
- sym->binding == STB_GLOBAL ? 'g' :
- sym->binding == STB_LOCAL ? 'l' : 'w', sym->name,
- err ? "[unknown]" : uts.machine,
- err ? "[unknown]" : uts.release,
perf_version_string);
- if (use_browser <= 0)
- sleep(5);
-
- map->erange_warned = true;
+ if (!map || !sym) {
+ ui__warning("Out of bounds address found\n");
+ return;
}
+
+ ui__warning("Out of bounds address found:\n\n"
+ "Addr: %" PRIx64 "\n"
+ "DSO:%s %c\n"
+ "Map:%" PRIx64 "-%" PRIx64 "\n"
+ "Symbol: %" PRIx64 "-%" PRIx64 " %c %s\n"
+ "Arch: %s\n"
+ "Kernel: %s\n"
+ "Tools: %s\n\n"
+ "Not all samples will be on the annotation output.\n\n"
+ "Please report to linux-kernel@vger.kernel.org\n",
+ ip, map->dso->long_name, dso__symtab_origin(map->dso),
+ map->start, map->end, sym->start, sym->end,
+ sym->binding == STB_GLOBAL ? 'g' :
+ sym->binding == STB_LOCAL ? 'l' : 'w', sym->name,
+ err ? "[unknown]" : uts.machine,
+ err ? "[unknown]" : uts.release, perf_version_string);
+
+ map->erange_warned = true;
}
-static void ui__warn_enomem(struct perf_top *top, struct addr_location *al)
+static int perf_top__check_enomem(struct perf_top *top,
+ struct addr_location *al __maybe_unused)
{
- if (!top->enomem_warned) {
- ui__warning("Not enough memory for annotating '%s' symbol!\n",
- al->sym->name);
+ return top->enomem_warned;
+}
+static void perf_top__warn_enomem(struct perf_top *top,
+ struct addr_location *al)
+{
+ ui__warning("Not enough memory for annotating '%s' symbol!\n",
+ al->sym ? al->sym->name : "unknown");
- if (use_browser <= 0)
- sleep(5);
- top->enomem_warned = true;
- }
+ top->enomem_warned = true;
+}
+
+static int perf_top__check_kptr_restrict(struct perf_top *top,
+struct addr_location *al
__maybe_unused)
+{
+ return top->kptr_restrict_warned;
}
-static void ui__warn_kptr_restrict(struct perf_top *top, struct addr_location
*al)
+static void perf_top__warn_kptr_restrict(struct perf_top *top,
+struct addr_location *al)
{
- if
[PATCH/RFC 08/16] perf tools: Export a couple of hist functions
These are necessary for multi threaded sample processing:
- hists__get__get_rotate_entries_in()
- hists__collapse_insert_entry()
- __hists__init()
Signed-off-by: Namhyung Kim
---
tools/perf/util/hist.c | 19 ---
tools/perf/util/hist.h | 5 +
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index d534ed76164b..ea4f3ad978b0 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -972,9 +972,8 @@ void hist_entry__delete(struct hist_entry *he)
* collapse the histogram
*/
-static bool hists__collapse_insert_entry(struct hists *hists __maybe_unused,
-struct rb_root *root,
-struct hist_entry *he)
+bool hists__collapse_insert_entry(struct hists *hists __maybe_unused,
+ struct rb_root *root, struct hist_entry *he)
{
struct rb_node **p = >rb_node;
struct rb_node *parent = NULL;
@@ -1014,7 +1013,7 @@ static bool hists__collapse_insert_entry(struct hists
*hists __maybe_unused,
return true;
}
-static struct rb_root *hists__get_rotate_entries_in(struct hists *hists)
+struct rb_root *hists__get_rotate_entries_in(struct hists *hists)
{
struct rb_root *root;
@@ -1549,10 +1548,8 @@ int perf_hist_config(const char *var, const char *value)
return 0;
}
-static int hists_evsel__init(struct perf_evsel *evsel)
+int __hists__init(struct hists *hists)
{
- struct hists *hists = evsel__hists(evsel);
-
memset(hists, 0, sizeof(*hists));
hists->entries_in_array[0] = hists->entries_in_array[1] = RB_ROOT;
hists->entries_in = >entries_in_array[0];
@@ -1592,6 +1589,14 @@ static void hists_evsel__exit(struct perf_evsel *evsel)
hists__delete_all_entries(hists);
}
+static int hists_evsel__init(struct perf_evsel *evsel)
+{
+ struct hists *hists = evsel__hists(evsel);
+
+ __hists__init(hists);
+ return 0;
+}
+
/*
* XXX We probably need a hists_evsel__exit() to free the hist_entries
* stored in the rbtree...
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 47ae7e6b1de8..670720ef8acd 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -185,6 +185,11 @@ static inline struct hists *evsel__hists(struct perf_evsel
*evsel)
}
int hists__init(void);
+int __hists__init(struct hists *hists);
+
+struct rb_root *hists__get_rotate_entries_in(struct hists *hists);
+bool hists__collapse_insert_entry(struct hists *hists __maybe_unused,
+ struct rb_root *root, struct hist_entry *he);
struct perf_hpp {
char *buf;
--
2.6.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/RFC 06/16] perf top: Get rid of access to hists->lock in perf_top__record_precise_ip()
It was accessed to release the lock before going to sleep, but now it
doesn't go to sleep anymore since warnings will be shown in the
display thread.
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-top.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index aafcf27c437e..24a5434e8a0b 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -355,20 +355,10 @@ static void perf_top__record_precise_ip(struct perf_top
*top,
pthread_mutex_unlock(>lock);
- if (unlikely(err)) {
- /*
-* This function is now called with hists->lock held.
-* Release it before going to sleep.
-*/
- pthread_mutex_unlock(>hists->lock);
-
- if (err == -ERANGE)
- perf_top__request_warning(top, al, WARN_ERANGE);
- else if (err == -ENOMEM)
- perf_top__request_warning(top, al, WARN_ENOMEM);
-
- pthread_mutex_lock(>hists->lock);
- }
+ if (err == -ERANGE)
+ perf_top__request_warning(top, al, WARN_ERANGE);
+ else if (err == -ENOMEM)
+ perf_top__request_warning(top, al, WARN_ENOMEM);
}
static void perf_top__show_details(struct perf_top *top)
--
2.6.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/RFC 02/16] perf top: Fix and cleanup perf_top__record_precise_ip()
At first, it has duplicate ui__has_annotation() and 'sort__has_sym'
and 'use_browser' check. In fact, the ui__has_annotation() should be
removed as it needs to annotate on --stdio as well. And the
top->sym_filter_entry is used only for stdio mode, so make it clear on
the condition too.
Also the check will be simplifed if it sets sym before the check. And
omit check for 'he' since its caller (hist_iter__top_callback) only
gets called when iter->he is not NULL.
Secondly, it converts the 'ip' argument using map__unmap_ip() before
the call and then reverts it using map__map_ip(). This seems
meaningless and strange since only one of them checks the 'map'.
Finally, access the he->hists->lock only if there's an error.
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-top.c | 52
1 file changed, 22 insertions(+), 30 deletions(-)
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 7e2e72e6d9d1..7cd9bb69f5a6 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -175,42 +175,40 @@ static void perf_top__record_precise_ip(struct perf_top
*top,
int counter, u64 ip)
{
struct annotation *notes;
- struct symbol *sym;
+ struct symbol *sym = he->ms.sym;
int err = 0;
- if (he == NULL || he->ms.sym == NULL ||
- ((top->sym_filter_entry == NULL ||
- top->sym_filter_entry->ms.sym != he->ms.sym) && use_browser != 1))
+ if (sym == NULL || (use_browser == 0 &&
+ (top->sym_filter_entry == NULL ||
+top->sym_filter_entry->ms.sym != sym)))
return;
- sym = he->ms.sym;
notes = symbol__annotation(sym);
if (pthread_mutex_trylock(>lock))
return;
- ip = he->ms.map->map_ip(he->ms.map, ip);
-
- if (ui__has_annotation())
- err = hist_entry__inc_addr_samples(he, counter, ip);
+ err = hist_entry__inc_addr_samples(he, counter, ip);
pthread_mutex_unlock(>lock);
- /*
-* This function is now called with he->hists->lock held.
-* Release it before going to sleep.
-*/
- pthread_mutex_unlock(>hists->lock);
+ if (unlikely(err)) {
+ /*
+* This function is now called with hists->lock held.
+* Release it before going to sleep.
+*/
+ pthread_mutex_unlock(>hists->lock);
+
+ if (err == -ERANGE && !he->ms.map->erange_warned)
+ ui__warn_map_erange(he->ms.map, sym, ip);
+ else if (err == -ENOMEM) {
+ pr_err("Not enough memory for annotating '%s'
symbol!\n",
+ sym->name);
+ sleep(1);
+ }
- if (err == -ERANGE && !he->ms.map->erange_warned)
- ui__warn_map_erange(he->ms.map, sym, ip);
- else if (err == -ENOMEM) {
- pr_err("Not enough memory for annotating '%s' symbol!\n",
- sym->name);
- sleep(1);
+ pthread_mutex_lock(>hists->lock);
}
-
- pthread_mutex_lock(>hists->lock);
}
static void perf_top__show_details(struct perf_top *top)
@@ -687,14 +685,8 @@ static int hist_iter__top_callback(struct hist_entry_iter
*iter,
struct hist_entry *he = iter->he;
struct perf_evsel *evsel = iter->evsel;
- if (sort__has_sym && single) {
- u64 ip = al->addr;
-
- if (al->map)
- ip = al->map->unmap_ip(al->map, ip);
-
- perf_top__record_precise_ip(top, he, evsel->idx, ip);
- }
+ if (sort__has_sym && single)
+ perf_top__record_precise_ip(top, he, evsel->idx, al->addr);
hist__account_cycles(iter->sample->branch_stack, al, iter->sample,
!(top->record_opts.branch_stack & PERF_SAMPLE_BRANCH_ANY));
--
2.6.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/RFC 09/16] perf tools: Update hist entry's hists pointer
When sample is processed using multi-thread, each sample is gathered on each thread's hist tree and then merged into the real hist tree. But hist_entry->hists pointer was not updated so it could refer wrong hists resulted in missing outputs. Signed-off-by: Namhyung Kim --- tools/perf/util/hist.c | 8 1 file changed, 8 insertions(+) diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c index ea4f3ad978b0..a12e5022fe04 100644 --- a/tools/perf/util/hist.c +++ b/tools/perf/util/hist.c @@ -1008,6 +1008,14 @@ bool hists__collapse_insert_entry(struct hists *hists __maybe_unused, } hists->nr_entries++; + /* +* If a hist entry is processed in multi-threaded environment, +* it points to a dummy local hists which was used only for +* intermidate processing. So update it to a real one so that +* it can find the correct info later. +*/ + he->hists = hists; + rb_link_node(>rb_node_in, parent, p); rb_insert_color(>rb_node_in, root); return true; -- 2.6.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/RFC 13/16] perf top: Protect the seen list using mutex
When perf didn't find a machine, it records its pid in the seen list.
With multi-thread enabled, it shoud be protected using a mutex.
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-top.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index a9b7461be4f0..5987986b5203 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -916,7 +916,9 @@ static void perf_event__process_sample(struct reader_arg
*rarg,
if (!machine && perf_guest) {
static struct intlist *seen;
+ static pthread_mutex_t seen_lock = PTHREAD_MUTEX_INITIALIZER;
+ pthread_mutex_lock(_lock);
if (!seen)
seen = intlist__new(NULL);
@@ -925,6 +927,7 @@ static void perf_event__process_sample(struct reader_arg
*rarg,
sample->pid);
intlist__add(seen, sample->pid);
}
+ pthread_mutex_unlock(_lock);
return;
}
--
2.6.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] NFC: fdp: fix handling return value of fdp_nci_create_conn
The function can return negative values, so its result should
be assigned to signed variable.
The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].
[1]: http://permalink.gmane.org/gmane.linux.kernel/2046107
Signed-off-by: Andrzej Hajda
---
drivers/nfc/fdp/fdp.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/nfc/fdp/fdp.c b/drivers/nfc/fdp/fdp.c
index ccb07a1..440fac3 100644
--- a/drivers/nfc/fdp/fdp.c
+++ b/drivers/nfc/fdp/fdp.c
@@ -368,11 +368,10 @@ static int fdp_nci_patch_otp(struct nci_dev *ndev)
goto out;
/* Patch data connection creation */
- conn_id = fdp_nci_create_conn(ndev);
- if (conn_id < 0) {
- r = conn_id;
+ r = fdp_nci_create_conn(ndev);
+ if (r < 0)
goto out;
- }
+ conn_id = r;
/* Send the patch over the data connection */
r = fdp_nci_send_patch(ndev, conn_id, NCI_PATCH_TYPE_OTP);
@@ -439,11 +438,10 @@ static int fdp_nci_patch_ram(struct nci_dev *ndev)
goto out;
/* Patch data connection creation */
- conn_id = fdp_nci_create_conn(ndev);
- if (conn_id < 0) {
- r = conn_id;
- goto out;
- }
+ r = fdp_nci_create_conn(ndev);
+ if (r < 0)
+ got out;
+ conn_id = r;
/* Send the patch over the data connection */
r = fdp_nci_send_patch(ndev, conn_id, NCI_PATCH_TYPE_RAM);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] rtc: rv8803: fix handling return value of i2c_smbus_read_byte_data
The function can return negative values, so its result should be assigned to signed variable. The problem has been detected using proposed semantic patch scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1]. [1]: http://permalink.gmane.org/gmane.linux.kernel/2046107 Signed-off-by: Andrzej Hajda --- drivers/rtc/rtc-rv8803.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-rv8803.c b/drivers/rtc/rtc-rv8803.c index e7329e2..f883aa2 100644 --- a/drivers/rtc/rtc-rv8803.c +++ b/drivers/rtc/rtc-rv8803.c @@ -61,7 +61,7 @@ static irqreturn_t rv8803_handle_irq(int irq, void *dev_id) struct i2c_client *client = dev_id; struct rv8803_data *rv8803 = i2c_get_clientdata(client); unsigned long events = 0; - u8 flags; + int flags; spin_lock(>flags_lock); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH/RFC 11/16] perf top: Implement basic parallel processing
This patch changes perf top to process event samples with multiple
threads. For now, each mmap is read and processed with its own hists by
dedicated reader threads in parallel. And then a single collector
thread gathers the hist entries and move it to the evsel's hists tree.
As usual, a single UI thread will display them.
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-top.c | 172 ++-
1 file changed, 141 insertions(+), 31 deletions(-)
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index b62665ce5ea6..a9b7461be4f0 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -831,6 +831,57 @@ static int symbol_filter(struct map *map, struct symbol
*sym)
return 0;
}
+struct collector_arg {
+ struct perf_top *top;
+ struct hists*hists;
+};
+
+static void collect_hists(struct perf_top *top, struct hists *hists)
+{
+ int i, k;
+ struct perf_evsel *evsel;
+
+ for (i = 0, k = 0; i < top->evlist->nr_mmaps; i++) {
+ evlist__for_each(top->evlist, evsel) {
+ struct hists *src_hists = [k++];
+ struct hists *dst_hists = evsel__hists(evsel);
+ struct hist_entry *he;
+ struct rb_root *root;
+ struct rb_node *next;
+
+ root = hists__get_rotate_entries_in(src_hists);
+ next = rb_first(root);
+
+ while (next) {
+ if (session_done())
+ return;
+ he = rb_entry(next, struct hist_entry,
rb_node_in);
+ next = rb_next(next);
+
+ rb_erase(>rb_node_in, root);
+
+ pthread_mutex_lock(_hists->lock);
+ hists__collapse_insert_entry(dst_hists,
+
dst_hists->entries_in, he);
+ pthread_mutex_unlock(_hists->lock);
+ }
+ hists__add_stats(dst_hists, src_hists);
+ }
+ }
+}
+
+static void *collect_worker(void *arg)
+{
+ struct collector_arg *carg = arg;
+
+ while (!done) {
+ collect_hists(carg->top, carg->hists);
+ poll(NULL, 0, 100);
+ }
+
+ return NULL;
+}
+
static int hist_iter__top_callback(struct hist_entry_iter *iter,
struct addr_location *al, bool single,
void *arg)
@@ -847,13 +898,19 @@ static int hist_iter__top_callback(struct hist_entry_iter
*iter,
return 0;
}
-static void perf_event__process_sample(struct perf_tool *tool,
+struct reader_arg {
+ int idx;
+ struct perf_top *top;
+ struct hists*hists;
+};
+
+static void perf_event__process_sample(struct reader_arg *rarg,
const union perf_event *event,
struct perf_evsel *evsel,
struct perf_sample *sample,
struct machine *machine)
{
- struct perf_top *top = container_of(tool, struct perf_top, tool);
+ struct perf_top *top = rarg->top;
struct addr_location al;
int err;
@@ -890,10 +947,10 @@ static void perf_event__process_sample(struct perf_tool
*tool,
perf_top__request_warning(top, , WARN_VMLINUX);
if (al.sym == NULL || !al.sym->ignore) {
- struct hists *hists = evsel__hists(evsel);
+ struct hists* hists = >hists[evsel->idx];
struct hist_entry_iter iter = {
.evsel = evsel,
- .hists = evsel__hists(evsel),
+ .hists = hists,
.sample = sample,
.add_entry_cb = hist_iter__top_callback,
};
@@ -915,13 +972,15 @@ static void perf_event__process_sample(struct perf_tool
*tool,
addr_location__put();
}
-static void perf_top__mmap_read_idx(struct perf_top *top, int idx)
+static void perf_top__mmap_read(struct reader_arg *rarg)
{
struct perf_sample sample;
struct perf_evsel *evsel;
+ struct perf_top *top = rarg->top;
struct perf_session *session = top->session;
union perf_event *event;
struct machine *machine;
+ int idx = rarg->idx;
u8 origin;
int ret;
@@ -974,10 +1033,11 @@ static void perf_top__mmap_read_idx(struct perf_top
*top, int idx)
if (event->header.type == PERF_RECORD_SAMPLE) {
- perf_event__process_sample(>tool, event, evsel,
+
[PATCH/RFC 15/16] perf top: Add --num-thread option
The --num-thread option is to set number of reader thread. Default
value is 0 which will be converted to 1/4 of number of mmaps.
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-top.c | 49 +++-
tools/perf/util/top.h| 1 +
2 files changed, 37 insertions(+), 13 deletions(-)
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index f3ab46b234b6..fc9715b046b3 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -838,10 +838,10 @@ struct collector_arg {
static void collect_hists(struct perf_top *top, struct hists *hists)
{
- int i, k;
+ unsigned int i, k;
struct perf_evsel *evsel;
- for (i = 0, k = 0; i < top->evlist->nr_mmaps; i++) {
+ for (i = 0, k = 0; i < top->nr_threads; i++) {
evlist__for_each(top->evlist, evsel) {
struct hists *src_hists = [k++];
struct hists *dst_hists = evsel__hists(evsel);
@@ -900,6 +900,7 @@ static int hist_iter__top_callback(struct hist_entry_iter
*iter,
struct reader_arg {
int idx;
+ int nr_idx;
struct perf_top *top;
struct hists*hists;
struct perf_top_stats stats;
@@ -993,7 +994,7 @@ static void perf_event__process_sample(struct reader_arg
*rarg,
addr_location__put();
}
-static void perf_top__mmap_read(struct reader_arg *rarg)
+static void perf_top__mmap_read_idx(struct reader_arg *rarg, int idx)
{
struct perf_sample sample;
struct perf_evsel *evsel;
@@ -1001,7 +1002,6 @@ static void perf_top__mmap_read(struct reader_arg *rarg)
struct perf_session *session = top->session;
union perf_event *event;
struct machine *machine;
- int idx = rarg->idx;
u8 origin;
int ret;
@@ -1067,6 +1067,14 @@ static void perf_top__mmap_read(struct reader_arg *rarg)
}
}
+static void perf_top__mmap_read(struct reader_arg *rarg)
+{
+ int i;
+
+ for (i = 0; i < rarg->nr_idx; i++)
+ perf_top__mmap_read_idx(rarg, rarg->idx + i);
+}
+
static void *mmap_read_worker(void *arg)
{
struct reader_arg *rarg = arg;
@@ -1160,7 +1168,8 @@ static int __cmd_top(struct perf_top *top)
struct reader_arg *rargs = NULL;
struct collector_arg carg;
int ret;
- int i;
+ unsigned int i;
+ int idx, nr_idx, rem;
top->session = perf_session__new(NULL, false, NULL);
if (top->session == NULL)
@@ -1211,34 +1220,47 @@ static int __cmd_top(struct perf_top *top)
/* Wait for a minimal set of events before starting the snapshot */
perf_evlist__poll(top->evlist, 100);
+ if (top->nr_threads == 0)
+ top->nr_threads = top->evlist->nr_mmaps / 4 ?: 1;
+ if ((int)top->nr_threads > top->evlist->nr_mmaps)
+ top->nr_threads = top->evlist->nr_mmaps;
+
+ nr_idx = top->evlist->nr_mmaps / top->nr_threads;
+ rem = top->evlist->nr_mmaps % top->nr_threads;
+
ret = -1;
- readers = calloc(sizeof(pthread_t), top->evlist->nr_mmaps);
+ readers = calloc(sizeof(pthread_t), top->nr_threads);
if (readers == NULL)
goto out_delete;
- rargs = calloc(sizeof(*rargs), top->evlist->nr_mmaps);
+ rargs = calloc(sizeof(*rargs), top->nr_threads);
if (rargs == NULL)
goto out_free;
- hists = calloc(sizeof(*hists), top->evlist->nr_mmaps *
top->evlist->nr_entries);
+ hists = calloc(sizeof(*hists), top->nr_threads *
top->evlist->nr_entries);
if (hists == NULL)
goto out_free;
- for (i = 0; i < top->evlist->nr_mmaps * top->evlist->nr_entries; i++)
+ for (i = 0; i < top->nr_threads * top->evlist->nr_entries; i++)
__hists__init([i]);
- for (i = 0; i < top->evlist->nr_mmaps; i++) {
+ for (i = 0, idx = 0; i < top->nr_threads; i++) {
struct reader_arg *rarg = [i];
- rarg->idx = i;
rarg->top = top;
rarg->hists = [i * top->evlist->nr_entries];
+ rarg->idx = idx;
+ rarg->nr_idx = nr_idx;
+ if (rem-- > 0)
+ rarg->nr_idx++;
+ idx += rarg->nr_idx;
+
perf_top__mmap_read(rarg);
}
collect_hists(top, hists);
- for (i = 0; i < top->evlist->nr_mmaps; i++) {
+ for (i = 0; i < top->nr_threads; i++) {
if (pthread_create([i], NULL, mmap_read_worker,
[i]))
goto out_join;
}
@@ -1259,7 +1281,7 @@ static int __cmd_top(struct perf_top *top)
out_join:
pthread_join(ui_thread, NULL);
pthread_join(collector, NULL);
- for (i = 0; i < top->evlist->nr_mmaps; i++) {
+ for (i = 0; i < top->nr_threads; i++) {
pthread_join(readers[i], NULL);
[PATCH] NFC: fdp: fix handling return value of nci_conn_max_data_pkt_payload_size
The function can return negative values, so its result should be assigned to signed variable. The problem has been detected using proposed semantic patch scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1]. [1]: http://permalink.gmane.org/gmane.linux.kernel/2046107 Signed-off-by: Andrzej Hajda --- drivers/nfc/fdp/fdp.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/nfc/fdp/fdp.c b/drivers/nfc/fdp/fdp.c index 440fac3..37a7134 100644 --- a/drivers/nfc/fdp/fdp.c +++ b/drivers/nfc/fdp/fdp.c @@ -192,7 +192,7 @@ static int fdp_nci_send_patch(struct nci_dev *ndev, u8 conn_id, u8 type) struct sk_buff *skb; unsigned long len; u8 max_size, payload_size; - int rc = 0; + int rc; if ((type == NCI_PATCH_TYPE_OTP && !info->otp_patch) || (type == NCI_PATCH_TYPE_RAM && !info->ram_patch)) @@ -203,11 +203,13 @@ static int fdp_nci_send_patch(struct nci_dev *ndev, u8 conn_id, u8 type) else fw = info->ram_patch; - max_size = nci_conn_max_data_pkt_payload_size(ndev, conn_id); - if (max_size <= 0) + rc = nci_conn_max_data_pkt_payload_size(ndev, conn_id); + if (rc <= 0) return -EINVAL; + max_size = rc; len = fw->size; + rc = 0; fdp_nci_set_data_pkt_counter(ndev, fdp_nci_send_patch_cb, DIV_ROUND_UP(fw->size, max_size)); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH/RFC 14/16] perf top: Separate struct perf_top_stats
The perf top maintains various stats regarding samples. Separate out
those stats so that it can be updated concurrently.
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-top.c | 36
tools/perf/util/top.c| 18 --
tools/perf/util/top.h| 12
3 files changed, 44 insertions(+), 22 deletions(-)
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 5987986b5203..f3ab46b234b6 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -902,8 +902,26 @@ struct reader_arg {
int idx;
struct perf_top *top;
struct hists*hists;
+ struct perf_top_stats stats;
};
+static void perf_top_stats__add(struct perf_top_stats *dst,
+ struct perf_top_stats *src)
+{
+ static pthread_mutex_t stats_lock = PTHREAD_MUTEX_INITIALIZER;
+
+ pthread_mutex_lock(_lock);
+
+ dst->samples += src->samples;
+ dst->exact_samples+= src->exact_samples;
+ dst->kernel_samples += src->kernel_samples;
+ dst->us_samples += src->us_samples;
+ dst->guest_kernel_samples += src->guest_kernel_samples;
+ dst->guest_us_samples += src->guest_us_samples;
+
+ pthread_mutex_unlock(_lock);
+}
+
static void perf_event__process_sample(struct reader_arg *rarg,
const union perf_event *event,
struct perf_evsel *evsel,
@@ -938,7 +956,7 @@ static void perf_event__process_sample(struct reader_arg
*rarg,
}
if (event->header.misc & PERF_RECORD_MISC_EXACT_IP)
- top->exact_samples++;
+ rarg->stats.exact_samples++;
if (perf_event__preprocess_sample(event, machine, , sample) < 0)
return;
@@ -1000,28 +1018,28 @@ static void perf_top__mmap_read(struct reader_arg *rarg)
origin = event->header.misc & PERF_RECORD_MISC_CPUMODE_MASK;
if (event->header.type == PERF_RECORD_SAMPLE)
- ++top->samples;
+ ++rarg->stats.samples;
switch (origin) {
case PERF_RECORD_MISC_USER:
- ++top->us_samples;
+ ++rarg->stats.us_samples;
if (top->hide_user_symbols)
goto next_event;
machine = >machines.host;
break;
case PERF_RECORD_MISC_KERNEL:
- ++top->kernel_samples;
+ ++rarg->stats.kernel_samples;
if (top->hide_kernel_symbols)
goto next_event;
machine = >machines.host;
break;
case PERF_RECORD_MISC_GUEST_KERNEL:
- ++top->guest_kernel_samples;
+ ++rarg->stats.guest_kernel_samples;
machine = perf_session__find_machine(session,
sample.pid);
break;
case PERF_RECORD_MISC_GUEST_USER:
- ++top->guest_us_samples;
+ ++rarg->stats.guest_us_samples;
/*
* TODO: we don't process guest user from host side
* except simple counting.
@@ -1065,12 +1083,14 @@ static void *mmap_read_worker(void *arg)
}
while (!done) {
- u64 hits = top->samples;
+ u64 hits = rarg->stats.samples;
perf_top__mmap_read(rarg);
- if (hits == top->samples)
+ if (hits == rarg->stats.samples)
perf_evlist__poll(top->evlist, 100);
+ else
+ perf_top_stats__add(>stats, >stats);
}
return NULL;
}
diff --git a/tools/perf/util/top.c b/tools/perf/util/top.c
index 8e517def925b..95d6bba1a2a0 100644
--- a/tools/perf/util/top.c
+++ b/tools/perf/util/top.c
@@ -30,10 +30,10 @@ size_t perf_top__header_snprintf(struct perf_top *top, char
*bf, size_t size)
struct target *target = >target;
size_t ret = 0;
- if (top->samples) {
- samples_per_sec = top->samples / top->delay_secs;
- ksamples_per_sec = top->kernel_samples / top->delay_secs;
- esamples_percent = (100.0 * top->exact_samples) / top->samples;
+ if (top->stats.samples) {
+ samples_per_sec = top->stats.samples / top->delay_secs;
+ ksamples_per_sec = top->stats.kernel_samples / top->delay_secs;
+ esamples_percent = (100.0 * top->stats.exact_samples) /
top->stats.samples;
} else {
samples_per_sec = ksamples_per_sec = esamples_percent = 0.0;
[PATCH/RFC 07/16] perf hists: Pass hists struct to hist_entry_iter struct
This is a preparation for multi-thread support in perf tools. When
multi-thread is enable, each thread will have its own hists during the
sample processing.
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c | 1 +
tools/perf/builtin-top.c | 1 +
tools/perf/tests/hists_cumulate.c | 1 +
tools/perf/tests/hists_filter.c | 1 +
tools/perf/tests/hists_output.c | 1 +
tools/perf/util/hist.c| 22 --
tools/perf/util/hist.h| 1 +
7 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index af5db885ea9c..c681064f2e18 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -144,6 +144,7 @@ static int process_sample_event(struct perf_tool *tool,
struct addr_location al;
struct hist_entry_iter iter = {
.evsel = evsel,
+ .hists = evsel__hists(evsel),
.sample = sample,
.hide_unresolved= symbol_conf.hide_unresolved,
.add_entry_cb = hist_iter__report_callback,
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 24a5434e8a0b..b62665ce5ea6 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -893,6 +893,7 @@ static void perf_event__process_sample(struct perf_tool
*tool,
struct hists *hists = evsel__hists(evsel);
struct hist_entry_iter iter = {
.evsel = evsel,
+ .hists = evsel__hists(evsel),
.sample = sample,
.add_entry_cb = hist_iter__top_callback,
};
diff --git a/tools/perf/tests/hists_cumulate.c
b/tools/perf/tests/hists_cumulate.c
index 8292948bc5f9..fd0d5d955612 100644
--- a/tools/perf/tests/hists_cumulate.c
+++ b/tools/perf/tests/hists_cumulate.c
@@ -88,6 +88,7 @@ static int add_hist_entries(struct hists *hists, struct
machine *machine)
};
struct hist_entry_iter iter = {
.evsel = evsel,
+ .hists = evsel__hists(evsel),
.sample = ,
.hide_unresolved = false,
};
diff --git a/tools/perf/tests/hists_filter.c b/tools/perf/tests/hists_filter.c
index ccb5b4921f25..c57ed8755e34 100644
--- a/tools/perf/tests/hists_filter.c
+++ b/tools/perf/tests/hists_filter.c
@@ -65,6 +65,7 @@ static int add_hist_entries(struct perf_evlist *evlist,
};
struct hist_entry_iter iter = {
.evsel = evsel,
+ .hists = evsel__hists(evsel),
.sample = ,
.ops = _iter_normal,
.hide_unresolved = false,
diff --git a/tools/perf/tests/hists_output.c b/tools/perf/tests/hists_output.c
index 248beec1d917..86e9d374cd7f 100644
--- a/tools/perf/tests/hists_output.c
+++ b/tools/perf/tests/hists_output.c
@@ -58,6 +58,7 @@ static int add_hist_entries(struct hists *hists, struct
machine *machine)
};
struct hist_entry_iter iter = {
.evsel = evsel,
+ .hists = evsel__hists(evsel),
.sample = ,
.ops = _iter_normal,
.hide_unresolved = false,
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 56e97f5af598..d534ed76164b 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -525,7 +525,7 @@ iter_add_single_mem_entry(struct hist_entry_iter *iter,
struct addr_location *al
{
u64 cost;
struct mem_info *mi = iter->priv;
- struct hists *hists = evsel__hists(iter->evsel);
+ struct hists *hists = iter->hists;
struct hist_entry *he;
if (mi == NULL)
@@ -555,8 +555,7 @@ static int
iter_finish_mem_entry(struct hist_entry_iter *iter,
struct addr_location *al __maybe_unused)
{
- struct perf_evsel *evsel = iter->evsel;
- struct hists *hists = evsel__hists(evsel);
+ struct hists *hists = iter->hists;
struct hist_entry *he = iter->he;
int err = -EINVAL;
@@ -628,8 +627,7 @@ static int
iter_add_next_branch_entry(struct hist_entry_iter *iter, struct addr_location
*al)
{
struct branch_info *bi;
- struct perf_evsel *evsel = iter->evsel;
- struct hists *hists = evsel__hists(evsel);
+ struct hists *hists = iter->hists;
struct hist_entry *he = NULL;
int i = iter->curr;
int err = 0;
@@ -677,11 +675,10 @@ iter_prepare_normal_entry(struct hist_entry_iter *iter
__maybe_unused,
static int
iter_add_single_normal_entry(struct hist_entry_iter *iter, struct
addr_location *al)
{
- struct
[PATCH/RFC 12/16] perf tools: Reduce lock contention when processing events
When multi-thread is enabled, the machine->threads_lock is contented
as all worker threads try to grab the writer lock using the
machine__findnew_thread(). Usually, the thread they're looking for is
in the tree so they only need the reader lock though.
Thus try machine__find_thread() first, and then fallback to the
'findnew' API. This will improve the performance.
Signed-off-by: Namhyung Kim
---
tools/perf/util/event.c | 7 +--
tools/perf/util/machine.c | 19 ---
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 8b10621b415c..cefd43f8ec66 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -993,10 +993,13 @@ int perf_event__preprocess_sample(const union perf_event
*event,
struct perf_sample *sample)
{
u8 cpumode = event->header.misc & PERF_RECORD_MISC_CPUMODE_MASK;
- struct thread *thread = machine__findnew_thread(machine, sample->pid,
- sample->tid);
+ struct thread *thread = machine__find_thread(machine, sample->pid,
+sample->tid);
if (thread == NULL)
+ thread = machine__findnew_thread(machine, sample->pid,
+sample->tid);
+ if (thread == NULL)
return -1;
dump_printf(" ... thread: %s:%d\n", thread__comm_str(thread),
thread->tid);
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index f5882b8c8db9..6d7349501f26 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -467,7 +467,7 @@ struct comm *machine__thread_exec_comm(struct machine
*machine,
int machine__process_comm_event(struct machine *machine, union perf_event
*event,
struct perf_sample *sample)
{
- struct thread *thread = machine__findnew_thread(machine,
+ struct thread *thread = machine__find_thread(machine,
event->comm.pid,
event->comm.tid);
bool exec = event->header.misc & PERF_RECORD_MISC_COMM_EXEC;
@@ -479,6 +479,10 @@ int machine__process_comm_event(struct machine *machine,
union perf_event *event
if (dump_trace)
perf_event__fprintf_comm(event, stdout);
+ if (thread == NULL) {
+ thread = machine__findnew_thread(machine, event->comm.pid,
+event->comm.tid);
+ }
if (thread == NULL ||
__thread__set_comm(thread, event->comm.comm, sample->time, exec)) {
dump_printf("problem processing PERF_RECORD_COMM, skipping
event.\n");
@@ -1314,8 +1318,13 @@ int machine__process_mmap2_event(struct machine *machine,
return 0;
}
- thread = machine__findnew_thread(machine, event->mmap2.pid,
+ thread = machine__find_thread(machine, event->mmap2.pid,
event->mmap2.tid);
+ if (thread == NULL) {
+ thread = machine__findnew_thread(machine,
+event->mmap2.pid,
+event->mmap2.tid);
+ }
if (thread == NULL)
goto out_problem;
@@ -1368,8 +1377,12 @@ int machine__process_mmap_event(struct machine *machine,
union perf_event *event
return 0;
}
- thread = machine__findnew_thread(machine, event->mmap.pid,
+ thread = machine__find_thread(machine, event->mmap.pid,
event->mmap.tid);
+ if (thread == NULL) {
+ thread = machine__findnew_thread(machine, event->mmap.pid,
+event->mmap.tid);
+ }
if (thread == NULL)
goto out_problem;
--
2.6.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/RFC 16/16] perf tools: Skip dso front cache for multi-threaded lookup
Currently the dso maintains a front cache for faster symbol lookup,
but access to it should be synchronized when multi thread is used.
Also it doesn't help much if data file has callchains since it should
walk through the callchains for each sample so single cache is almost
meaningless.
So skip the cache if mult-thread is enabled.
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-top.c | 2 ++
tools/perf/util/symbol.c | 3 +++
tools/perf/util/symbol.h | 3 ++-
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index fc9715b046b3..d69069d57f8c 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1225,6 +1225,8 @@ static int __cmd_top(struct perf_top *top)
if ((int)top->nr_threads > top->evlist->nr_mmaps)
top->nr_threads = top->evlist->nr_mmaps;
+ symbol_conf.multi_thread = (top->nr_threads > 1);
+
nr_idx = top->evlist->nr_mmaps / top->nr_threads;
rem = top->evlist->nr_mmaps % top->nr_threads;
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index d51abd2e7865..d4a966004fa0 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -454,6 +454,9 @@ void dso__reset_find_symbol_cache(struct dso *dso)
struct symbol *dso__find_symbol(struct dso *dso,
enum map_type type, u64 addr)
{
+ if (symbol_conf.multi_thread)
+ return symbols__find(>symbols[type], addr);
+
if (dso->last_find_result[type].addr != addr) {
dso->last_find_result[type].addr = addr;
dso->last_find_result[type].symbol =
symbols__find(>symbols[type], addr);
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index 857f707ac12b..68c198f64e1d 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -109,7 +109,8 @@ struct symbol_conf {
branch_callstack,
has_filter,
show_ref_callgraph,
- hide_unresolved;
+ hide_unresolved,
+ multi_thread;
const char *vmlinux_name,
*kallsyms_name,
*source_prefix,
--
2.6.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/RFC 03/16] perf top: Factor out warnings about kernel addresses and symbols
Factor out warning messages into separate functions. These will be
called in the display thread later.
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-top.c | 95 ++--
1 file changed, 51 insertions(+), 44 deletions(-)
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 7cd9bb69f5a6..e6166ef8fd1a 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -170,6 +170,53 @@ static void ui__warn_map_erange(struct map *map, struct
symbol *sym, u64 ip)
map->erange_warned = true;
}
+static void ui__warn_kptr_restrict(struct perf_top *top, struct addr_location
*al)
+{
+ if (!top->kptr_restrict_warned) {
+ ui__warning(
+"Kernel address maps (/proc/{kallsyms,modules}) are restricted.\n\n"
+"Check /proc/sys/kernel/kptr_restrict.\n\n"
+"Kernel%s samples will not be resolved.\n",
+ al->map &&
!RB_EMPTY_ROOT(>map->dso->symbols[MAP__FUNCTION]) ?
+ " modules" : "");
+ if (use_browser <= 0)
+ sleep(5);
+ top->kptr_restrict_warned = true;
+ }
+}
+
+static void ui__warn_vmlinux(struct perf_top *top, struct addr_location *al)
+{
+ const char *msg = "Kernel samples will not be resolved.\n";
+ /*
+* As we do lazy loading of symtabs we only will know if the
+* specified vmlinux file is invalid when we actually have a
+* hit in kernel space and then try to load it. So if we get
+* here and there are _no_ symbols in the DSO backing the
+* kernel map, bail out.
+*
+* We may never get here, for instance, if we use -K/
+* --hide-kernel-symbols, even if the user specifies an
+* invalid --vmlinux ;-)
+*/
+ if (!top->kptr_restrict_warned && !top->vmlinux_warned &&
+ RB_EMPTY_ROOT(>map->dso->symbols[MAP__FUNCTION])) {
+ if (symbol_conf.vmlinux_name) {
+ char serr[256];
+ dso__strerror_load(al->map->dso, serr, sizeof(serr));
+ ui__warning("The %s file can't be used: %s\n%s",
+ symbol_conf.vmlinux_name, serr, msg);
+ } else {
+ ui__warning("A vmlinux file was not found.\n%s",
+ msg);
+ }
+
+ if (use_browser <= 0)
+ sleep(5);
+ top->vmlinux_warned = true;
+ }
+}
+
static void perf_top__record_precise_ip(struct perf_top *top,
struct hist_entry *he,
int counter, u64 ip)
@@ -729,51 +776,11 @@ static void perf_event__process_sample(struct perf_tool
*tool,
if (perf_event__preprocess_sample(event, machine, , sample) < 0)
return;
- if (!top->kptr_restrict_warned &&
- symbol_conf.kptr_restrict &&
- al.cpumode == PERF_RECORD_MISC_KERNEL) {
- ui__warning(
-"Kernel address maps (/proc/{kallsyms,modules}) are restricted.\n\n"
-"Check /proc/sys/kernel/kptr_restrict.\n\n"
-"Kernel%s samples will not be resolved.\n",
- al.map &&
!RB_EMPTY_ROOT(>dso->symbols[MAP__FUNCTION]) ?
- " modules" : "");
- if (use_browser <= 0)
- sleep(5);
- top->kptr_restrict_warned = true;
- }
-
- if (al.sym == NULL) {
- const char *msg = "Kernel samples will not be resolved.\n";
- /*
-* As we do lazy loading of symtabs we only will know if the
-* specified vmlinux file is invalid when we actually have a
-* hit in kernel space and then try to load it. So if we get
-* here and there are _no_ symbols in the DSO backing the
-* kernel map, bail out.
-*
-* We may never get here, for instance, if we use -K/
-* --hide-kernel-symbols, even if the user specifies an
-* invalid --vmlinux ;-)
-*/
- if (!top->kptr_restrict_warned && !top->vmlinux_warned &&
- al.map == machine->vmlinux_maps[MAP__FUNCTION] &&
- RB_EMPTY_ROOT(>dso->symbols[MAP__FUNCTION])) {
- if (symbol_conf.vmlinux_name) {
- char serr[256];
- dso__strerror_load(al.map->dso, serr,
sizeof(serr));
- ui__warning("The %s file can't be used: %s\n%s",
- symbol_conf.vmlinux_name, serr,
msg);
- } else {
- ui__warning("A vmlinux file was not found.\n%s",
- msg);
- }
+ if (symbol_conf.kptr_restrict &&
[PATCH v2 1/2] net: thunderx: HW TSO support for pass-2 hardware
From: Sunil Goutham
This adds support for offloading TCP segmentation to HW in pass-2
revision of hardware. Both driver level SW TSO for pass1.x chips
and HW TSO for pass-2 chip will co-exist. Modified SQ descriptor
structures to reflect pass-2 hw implementation.
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/cavium/thunder/nic.h |6
drivers/net/ethernet/cavium/thunder/nic_main.c | 11 ++-
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 15 -
drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 20 ++---
drivers/net/ethernet/cavium/thunder/q_struct.h | 30 ++-
5 files changed, 53 insertions(+), 29 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nic.h
b/drivers/net/ethernet/cavium/thunder/nic.h
index 39ca674..6888288 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -265,6 +265,7 @@ struct nicvf {
u8 tns_mode:1;
u8 sqs_mode:1;
u8 loopback_supported:1;
+ boolhw_tso;
u16 mtu;
struct queue_set*qs;
#defineMAX_SQS_PER_VF_SINGLE_NODE 5
@@ -489,6 +490,11 @@ static inline int nic_get_node_id(struct pci_dev *pdev)
return ((addr >> NIC_NODE_ID_SHIFT) & NIC_NODE_ID_MASK);
}
+static inline bool pass1_silicon(struct pci_dev *pdev)
+{
+ return pdev->revision < 8;
+}
+
int nicvf_set_real_num_queues(struct net_device *netdev,
int tx_queues, int rx_queues);
int nicvf_open(struct net_device *netdev);
diff --git a/drivers/net/ethernet/cavium/thunder/nic_main.c
b/drivers/net/ethernet/cavium/thunder/nic_main.c
index 4b7fd63..9f80de4 100644
--- a/drivers/net/ethernet/cavium/thunder/nic_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nic_main.c
@@ -55,11 +55,6 @@ struct nicpf {
boolirq_allocated[NIC_PF_MSIX_VECTORS];
};
-static inline bool pass1_silicon(struct nicpf *nic)
-{
- return nic->pdev->revision < 8;
-}
-
/* Supported devices */
static const struct pci_device_id nic_id_table[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_CAVIUM, PCI_DEVICE_ID_THUNDER_NIC_PF) },
@@ -123,7 +118,7 @@ static void nic_send_msg_to_vf(struct nicpf *nic, int vf,
union nic_mbx *mbx)
* when PF writes to MBOX(1), in next revisions when
* PF writes to MBOX(0)
*/
- if (pass1_silicon(nic)) {
+ if (pass1_silicon(nic->pdev)) {
/* see the comment for nic_reg_write()/nic_reg_read()
* functions above
*/
@@ -400,7 +395,7 @@ static void nic_config_cpi(struct nicpf *nic, struct
cpi_cfg_msg *cfg)
padd = cpi % 8; /* 3 bits CS out of 6bits DSCP */
/* Leave RSS_SIZE as '0' to disable RSS */
- if (pass1_silicon(nic)) {
+ if (pass1_silicon(nic->pdev)) {
nic_reg_write(nic, NIC_PF_CPI_0_2047_CFG | (cpi << 3),
(vnic << 24) | (padd << 16) |
(rssi_base + rssi));
@@ -470,7 +465,7 @@ static void nic_config_rss(struct nicpf *nic, struct
rss_cfg_msg *cfg)
}
cpi_base = nic->cpi_base[cfg->vf_id];
- if (pass1_silicon(nic))
+ if (pass1_silicon(nic->pdev))
idx_addr = NIC_PF_CPI_0_2047_CFG;
else
idx_addr = NIC_PF_MPI_0_2047_CFG;
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index dde8dc7..c24cb2a 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -525,14 +525,22 @@ static void nicvf_snd_pkt_handler(struct net_device
*netdev,
__func__, cqe_tx->sq_qs, cqe_tx->sq_idx,
cqe_tx->sqe_ptr, hdr->subdesc_cnt);
- nicvf_put_sq_desc(sq, hdr->subdesc_cnt + 1);
nicvf_check_cqe_tx_errs(nic, cq, cqe_tx);
skb = (struct sk_buff *)sq->skbuff[cqe_tx->sqe_ptr];
- /* For TSO offloaded packets only one head SKB needs to be freed */
+ /* For TSO offloaded packets only one SQE will have a valid SKB */
if (skb) {
+ nicvf_put_sq_desc(sq, hdr->subdesc_cnt + 1);
prefetch(skb);
dev_consume_skb_any(skb);
sq->skbuff[cqe_tx->sqe_ptr] = (u64)NULL;
+ } else {
+ /* In case of HW TSO, HW sends a CQE for each segment of a TSO
+* packet instead of a single CQE for the whole TSO packet
+* transmitted. Each of this CQE points to the same SQE, so
+* avoid freeing same SQE multiple times.
+*/
+ if (!nic->hw_tso)
+ nicvf_put_sq_desc(sq, hdr->subdesc_cnt + 1);
}
}
@@ -1549,6
[PATCH v2 0/2] net: thunderx: Support for pass-2 hw features
From: Sunil Goutham This patch set adds support for new features added in pass-2 revision of hardware like TSO and count based interrupt coalescing. Changes from v1: - Addressed comments received regarding boolean bit field changes by excluding them from this patch. Will submit a seperate patch along with cleanup of unsed field. - Got rid of new macro 'VNIC_NAPI_WEIGHT' introduced in count threshold interrupt patch. Sunil Goutham (2): net: thunderx: HW TSO support for pass-2 hardware net: thunderx: Enable CQE count threshold interrupt drivers/net/ethernet/cavium/thunder/nic.h |6 drivers/net/ethernet/cavium/thunder/nic_main.c | 11 ++- drivers/net/ethernet/cavium/thunder/nicvf_main.c | 15 - drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 22 ++ drivers/net/ethernet/cavium/thunder/nicvf_queues.h |2 +- drivers/net/ethernet/cavium/thunder/q_struct.h | 30 ++- 6 files changed, 55 insertions(+), 31 deletions(-) -- 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: [v7] serial: 8250_dw: Add support for big-endian MMIO accesses
From: Andy Shevchenko [mailto:andy.shevche...@gmail.com] Sent: Wednesday, December 09, 2015 4:19 PM >Can you send v9 with Cc to me and Heikki? No problem >My concerns here are a) to split refactor part (check LCR), and b) do the >actual feature enhancement. I will split this into couple of commits -Noam
Re: [PATCH] net/macb: add support for resetting PHY using GPIO
Hi Gregory, On Wed, Dec 09, 2015 at 06:49:43PM +0100, Gregory CLEMENT wrote: > With device tree it is no more possible to reset the PHY at board > level. Furthermore, doing in the driver allow to power down the PHY when > the network interface is no more used. > > The patch introduces a new optional property "phy-reset-gpio" inspired > from the one use for the FEC. I don't think it's a good idea to further extend the usage of this binding. The driver should use the phy-handle property and of_phy_connect() which gives you a proper device node for the phy. Then the phy device node should get the reset gpio. I know it's more work, but doing it like this gives you additional goodies like proper handling of the max-speed property, a fixed-link if necessary and picking the correct phy if there are muliple phys on the bus. Sascha -- 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] powerpc/nvram: Fix an incorrect partition merge
From: Pan Xinhui
When we merge two contiguous partitions whose signatures are marked
NVRAM_SIG_FREE, We need update prev's length and checksum, then write it
to nvram, not cur's. So lets fix this mistake now.
Also use memset instead of strncpy to set the partition's name. It's
more readable if we want to fill up with duplicate chars .
Signed-off-by: Pan Xinhui
---
arch/powerpc/kernel/nvram_64.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/nvram_64.c b/arch/powerpc/kernel/nvram_64.c
index 21a278b7..40e80ca 100644
--- a/arch/powerpc/kernel/nvram_64.c
+++ b/arch/powerpc/kernel/nvram_64.c
@@ -969,7 +969,7 @@ int __init nvram_remove_partition(const char *name, int sig,
/* Make partition a free partition */
part->header.signature = NVRAM_SIG_FREE;
- strncpy(part->header.name, "", 12);
+ memset(part->header.name, 'w', 12);
part->header.checksum = nvram_checksum(>header);
rc = nvram_write_header(part);
if (rc <= 0) {
@@ -987,8 +987,8 @@ int __init nvram_remove_partition(const char *name, int sig,
}
if (prev) {
prev->header.length += part->header.length;
- prev->header.checksum = nvram_checksum(>header);
- rc = nvram_write_header(part);
+ prev->header.checksum = nvram_checksum(>header);
+ rc = nvram_write_header(prev);
if (rc <= 0) {
printk(KERN_ERR "nvram_remove_partition:
nvram_write failed (%d)\n", rc);
return rc;
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] MAINTAINERS: change the maintainer of fam15h_power driver
On Wed, Dec 09, 2015 at 10:33:04PM -0800, Joe Perches wrote: > On Thu, 2015-12-10 at 11:56 +0800, Huang Rui wrote: > > Andreas Herrmann won't take the maintainer of fam15h_power driver. I > > will take it and appreciate him for the great contributions on this > > driver. > [] > > diff --git a/CREDITS b/CREDITS > [] > > @@ -1507,6 +1507,14 @@ S: 312/107 Canberra Avenue > > ?S: Griffith, ACT 2603? > > ?S: Australia > > ? > > +N: Andreas Herrmann > > +E: herrmann.der.u...@gmail.com > > +E: herrmann.der.u...@googlemail.com > > +D: Key developer of x86/AMD64 > > +D: Author of AMD family 15h processor power monintoring driver > > trivia: ?monitoring > Oh, that's a typo. Should be "monitoring". Thanks to point out. :) Guenter, can you help to correct it when you apply? Or will I send a v2? Thanks, Rui -- 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 0/4] gpio: pxa: integrate with pincontrol
Linus Walleij writes: > On Sat, Nov 28, 2015 at 10:37 PM, Robert Jarzmik > wrote: > >> Hi Linus, Alexandre and Haojian, >> >> This serie aims at several cleanups and improvements in the pxa gpio driver, >> to > > I have concerns about this series. > > I am worried that joining the banks into one gpio_chip makes it > impossible for you GPIOLIB_IRQCHIP. Usually that is possible and > preferrable when using a chained handler if e.g. one bank has > one IRQ line. > > But overall that depends on how the IRQs map on this hardware. > Can you describe how the GPIO IRQs work on the PXA27x? Of course. For PXA27x, there are 3 interrupts directly connected to the CPU of the SoC, ie. the primary irq controller : - one is only triggered if GPIO0 has a rising/falling edge - one is only triggered if GPIO1 has a rising/falling edge - the last is triggered if any GPIOn has a rising/falling edge (n >= 2) The condition to program the rising/falling edge which implies the interrupt to be asserted is in a GPIO block register, GFER and GRER (1 bit per GPIO). The fact that the last interrupt (let's call it gpiomux_irq) is triggered by GPIOs from _all_ the banks makes me believe it's a single IP block, ie. a single chip. Now if you have concerns with this, then maybe you can advise another approach, I'm pretty open. The final goal will be for me : - gpio and pinctrl have to cooperate - today, with the current state, it's impossible to map pins 0..127 to gpios 0..127, at least in a device-tree .dts file - the GPDR (gpio direction register) shared access bothers me a bit Cheers. -- Robert -- 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] tools: hv: vss: fix the write()'s argument: error -> vss_msg
I found this by chance. I don't have a specific bug caused by this.
Cc: Vitaly Kuznetsov
Cc: "K. Y. Srinivasan"
Signed-off-by: Dexuan Cui
Cc: sta...@vger.kernel.org
---
tools/hv/hv_vss_daemon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/hv/hv_vss_daemon.c b/tools/hv/hv_vss_daemon.c
index 96234b6..5d51d6f 100644
--- a/tools/hv/hv_vss_daemon.c
+++ b/tools/hv/hv_vss_daemon.c
@@ -254,7 +254,7 @@ int main(int argc, char *argv[])
syslog(LOG_ERR, "Illegal op:%d\n", op);
}
vss_msg->error = error;
- len = write(vss_fd, , sizeof(struct hv_vss_msg));
+ len = write(vss_fd, vss_msg, sizeof(struct hv_vss_msg));
if (len != sizeof(struct hv_vss_msg)) {
syslog(LOG_ERR, "write failed; error: %d %s", errno,
strerror(errno));
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH-v8] serial: 8250_dw: Add support for big-endian MMIO accesses
>From: Heikki Krogerus [mailto:heikki.kroge...@linux.intel.com]
>Sent: Wednesday, December 09, 2015 3:20 PM
>> @@ -171,7 +174,8 @@ static void dw8250_serial_out32(struct uart_port *p, int
>> offset, int value)
>> if ((value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR))
>> return;
>> dw8250_force_idle(p);
>> -writel(value, p->membase + (UART_LCR << p->regshift));
>> +d->serial_out(value,
>> + p->membase + (UART_LCR << p->regshift));
>> }
>.. The way I see it, this is the only place where you would really need the
>new private serial_in/out hooks, so why not just check the >iotype here and
>based on that use writeb/writel/iowrite32be or what ever ..
In previous versions (V2) Greg dis-liked using iotype here this is why I added
the private serial_in/serial_out
>> static void dw8250_setup_port(struct uart_port *p) {
>> struct uart_8250_port *up = up_to_u8250p(p);
>> +struct dw8250_data *d = p->private_data;
>> u32 reg;
>>
>> /*
>> * If the Component Version Register returns zero, we know that
>> * ADDITIONAL_FEATURES are not enabled. No need to go any further.
>> */
>> -reg = readl(p->membase + DW_UART_UCV);
>> +reg = d->serial_in(p->membase + DW_UART_UCV);
>> if (!reg)
>> return;
>>
>> dev_dbg(p->dev, "Designware UART version %c.%c%c\n",
>> (reg >> 24) & 0xff, (reg >> 16) & 0xff, (reg >> 8) & 0xff);
>>
>> -reg = readl(p->membase + DW_UART_CPR);
>> +reg = d->serial_in(p->membase + DW_UART_CPR);
>> if (!reg)
>> return;
>.. Here you could as well replace the direct readl calls with serial_port_in
>calls.
Again, if you meant here for using iotype it was rejected.
>> @@ -390,9 +434,19 @@ static int dw8250_probe(struct platform_device
>> *pdev)
>>
>> err = device_property_read_u32(p->dev, "reg-io-width", );
>> if (!err && val == 4) {
>> -p->iotype = UPIO_MEM32;
>> -p->serial_in = dw8250_serial_in32;
>> -p->serial_out = dw8250_serial_out32;
>> +p->iotype = of_device_is_big_endian(p->dev->of_node) ?
>> +UPIO_MEM32BE : UPIO_MEM32;
>If this has to be tied to DT, do this check in dw8250_quirks.
Thanks , I will move this to dw8250_quirks.
>> dw8250_quirks(p, data);
>>
>> +data->serial_in = _dw8250_serial_in32;
>> +data->serial_out = _dw8250_serial_out32;
>I don't think I understand what is going on here? You would never actually
>even use _dw8250_serial_in32be/out32be, no?
>Maybe I'm misunderstanding something.
This is a default in case where "reg-io-width != 4".
What is the case you see that they are not used? (_dw8250_serial_in32be is used
from dw8250_setup_port just few lines below)
-Noam
--
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 v9 7/7] PCI: hv: New paravirtual PCI front-end for Hyper-V VMs
Hi Jake, [auto build test ERROR on pci/next] [also build test ERROR on v4.4-rc4 next-20151209] url: https://github.com/0day-ci/linux/commits/jakeo-microsoft-com/PCI-hv-New-paravirtual-PCI-front-end-for-Hyper-V-VMs/20151210-070027 base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next config: x86_64-randconfig-x006-12100835 (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers/pci/host/hv_pcifront.c: In function 'hv_compose_msi_msg': >> drivers/pci/host/hv_pcifront.c:830:4: error: 'apic' undeclared (first use in >> this function) (apic->irq_delivery_mode == dest_LowestPrio) ? 1 : 0; ^ drivers/pci/host/hv_pcifront.c:830:4: note: each undeclared identifier is reported only once for each function it appears in drivers/pci/host/hv_pcifront.c: In function 'hv_pci_allocate_bridge_windows': drivers/pci/host/hv_pcifront.c:1776:18: warning: unused variable 'length' [-Wunused-variable] resource_size_t length; ^ vim +/apic +830 drivers/pci/host/hv_pcifront.c 824 int_pkt = (struct pci_create_interrupt *) 825 int_pkt->message_type.message_type = PCI_CREATE_INTERRUPT_MESSAGE; 826 int_pkt->wslot.slot = hpdev->desc.win_slot.slot; 827 int_pkt->int_desc.vector = cfg->vector; 828 int_pkt->int_desc.vector_count = 1; 829 int_pkt->int_desc.delivery_mode = > 830 (apic->irq_delivery_mode == dest_LowestPrio) ? 1 : 0; 831 832 /* 833 * This bit doesn't have to work on machines with more than 64 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: [PATCH v2 17/19] ARM: dts: Add support of bus frequency using VDD_INT for exynos3250-rinato
On 2015년 12월 10일 15:58, Krzysztof Kozlowski wrote: > On 09.12.2015 13:08, Chanwoo Choi wrote: >> This patch adds the bus device-tree node of INT (internal) block >> to enable the bus frequency. The following sub-blocks share > > "to enable the bus frequency scaling" > >> the VDD_INT power source: >> - LEFTBUS (parent device) >> - RIGHTBUS >> - PERIL >> - LCD0 >> - FSYS >> - MCUISP / ISP >> - MFC >> >> The LEFTBUS is parent device with devfreq ondemand governor >> and the rest devices has the dependency on LEFTBUS bus. > > How about: > "and the rest of devices depend on the LEFTBUS device." > ? OK, I'll modify it. > > The patch is good: > > Reviewed-by: Krzysztof Kozlowski Thanks for your review. Best Regards, Chanwoo Choi -- 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 19/19] ARM: dts: Add support of bus frequency for exynos4412-trats/odroidu3
On 2015년 12월 10일 16:08, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:08, Chanwoo Choi wrote:
>> THis patch adds the bus device tree nodes for both MIF (Memory) and INT
>> (Internal) block to enable the bus frequency.
>>
>> The DMC bus is parent device in MIF block using VDD_MIF and the LEFTBUS
>> bus is parent device in INT block using VDD_INT.
>>
>> Signed-off-by: Chanwoo Choi
>> ---
>> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 47
>> +
>> arch/arm/boot/dts/exynos4412-trats2.dts | 47
>> +
>> 2 files changed, 94 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> index 171dea1e3e4a..12d08242a179 100644
>> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> @@ -544,3 +544,50 @@
>> };
>> };
>> };
>> +
>> +_dmc {
>> +devfreq-events = <_dmc0_3>, <_dmc1_3>;
>> +vdd-supply = <_reg>;
>> +status = "okay";
>> +};
>> +
>> +_acp {
>> +devfreq = <_dmc>;
>> +status = "okay";
>> +};
>> +
>> +_c2c {
>> +devfreq = <_dmc>;
>> +status = "okay";
>> +};
>> +
>> +_leftbus {
>> +devfreq-events = <_leftbus_3>, <_rightbus_3>;
>> +vdd-supply = <_reg>;
>> +status = "okay";
>> +};
>> +
>> +_rightbus {
>> +devfreq = <_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +_display {
>> +devfreq = <_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +_fsys {
>> +devfreq = <_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +_peri {
>> +devfreq = <_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +_mfc {
>> +devfreq = <_leftbus>;
>> +status = "okay";
>> +};
>> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
>> b/arch/arm/boot/dts/exynos4412-trats2.dts
>> index 40a474c4374b..aecd545803ad 100644
>> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
>> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
>> @@ -1286,3 +1286,50 @@
>> vtmu-supply = <_reg>;
>> status = "okay";
>> };
>> +
>> +_dmc {
>> +devfreq-events = <_dmc0_3>, <_dmc1_3>;
>> +vdd-supply = <_reg>;
>> +status = "okay";
>> +};
>> +
>> +_acp {
>> +devfreq = <_dmc>;
>> +status = "okay";
>> +};
>> +
>> +_c2c {
>> +devfreq = <_dmc>;
>> +status = "okay";
>> +};
>> +
>> +_leftbus {
>> +devfreq-events = <_leftbus_3>, <_rightbus_3>;
>> +vdd-supply = <_reg>;
>> +status = "okay";
>> +};
>> +
>> +_rightbus {
>> +devfreq = <_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +_display {
>> +devfreq = <_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +_fsys {
>> +devfreq = <_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +_peri {
>> +devfreq = <_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +_mfc {
>> +devfreq = <_leftbus>;
>> +status = "okay";
>> +};
>
> The nodes in both files are mostly sorted alphabetically. Could you
> place them in such order as well?
Okay. I'll sort them alphabetically.
Best Regards,
Chanwoo Choi
--
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 18/19] ARM: dts: Expand the voltage range of buck1/3 regulator for exynos4412-odroidu3
On 2015년 12월 10일 16:02, Krzysztof Kozlowski wrote: > On 09.12.2015 13:08, Chanwoo Choi wrote: >> This patch expands the voltage range of buck1/3 regulator due to as >> following: >> - MIF (Memory Interface) bus frequency needs the 9uV ~ 105uV V. >> - INT (Internal) bus frequency needs 9uV ~ 100uV. > > 9->90 and duplicated "uV V". Maybe just: > 900 - 1050 mV > 900 - 1000 mV > ? OK. I'll modify the patch description. > >> >> Signed-off-by: Chanwoo Choi >> --- >> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> > > For the contents of patch: > > Reviewed-by: Krzysztof Kozlowski Best Regards, Chanwoo CHoi -- 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 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12
On 2015년 12월 10일 16:12, Krzysztof Kozlowski wrote:
> On 10.12.2015 16:07, Chanwoo Choi wrote:
>> On 2015년 12월 10일 15:53, Krzysztof Kozlowski wrote:
>>> On 10.12.2015 15:43, Chanwoo Choi wrote:
On 2015년 12월 10일 15:32, Krzysztof Kozlowski wrote:
> On 10.12.2015 15:08, Chanwoo Choi wrote:
>> On 2015년 12월 10일 14:57, Krzysztof Kozlowski wrote:
>>> On 09.12.2015 13:08, Chanwoo Choi wrote:
This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
Exynos4x12 has the following AXI buses to translate data between
DRAM and sub-blocks.
Following list specifies the detailed relation between DRAM and
sub-blocks:
- ACLK100 clock for PERIL/PERIR/MFC(PCLK)
- ACLK160 clock for CAM/TV/LCD
: The minimum clock of ACLK160 should be over 160MHz.
When drop the clock under 160MHz, show the broken image.
- ACLK133 clock for FSYS
- GDL clock for LEFTBUS
- GDR clock for RIGHTBUS
- SCLK_MFC clock for MFC
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos4x12.dtsi | 112
++
1 file changed, 112 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 3bcf0939755e..8bc4aee156b5 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -354,6 +354,118 @@
opp-microvolt = <95>;
};
};
+
+ bus_leftbus: bus_leftbus {
+ compatible = "samsung,exynos-bus";
+ clocks = < CLK_DIV_GDL>;
+ clock-names = "bus";
+ operating-points-v2 = <_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_rightbus: bus_rightbus {
+ compatible = "samsung,exynos-bus";
+ clocks = < CLK_DIV_GDR>;
+ clock-names = "bus";
+ operating-points-v2 = <_leftbus_opp_table>;
+ status = "disabled";
+ };
>>>
>>> These two nodes are symmetrical. The MFC below and other buses in other
>>> DTS share opps. How about changing the binding so multiple clocks could
>>> be specified at once ("bus0", "bus1")? I think there is no need for a
>>> bus device for each clock.
>>
>> The your commented method is possible.
>>
>> But, I focus on implementing the generic bus frequency driver.
>>
>> If specific bus device-tree node includes the one more clocks,
>> when adding the new Exynos SoC, the exynos-bus.c should be added
>> for new Exynos SoC. Because, each Exynos SoC has the different
>> set of bus device.
>>
>> If we use my approach, we don't need to modify the exynos-bus.c
>> driver to support for the bus frequency of new Exynos SoC.
>
> This won't change. The driver will just support from 1 to N clocks for
> given bus device and set the same OPP to all of them. This will only
> limit the number of duplicated entries. This won't affect the generic
> approach of driver itself.
You're right aspect of only implementation of device driver.
But,
If we use your commented approach, we can show the information
of only parent device through sysfs. We cannot see the information
of passive device. The some information includes the current
frequency and correlation of parent device. (But, current patchset
don' include the topology information between parent device and
passive device. I'll do it on later patches).
For example,
We can see the following bus device through /sys/class/devfreq.
drwxr-xr-x 2 root root 0 Dec 31 17:00 .
drwxr-xr-x 44 root root 0 Dec 31 17:00 ..
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_display ->
../../devices/platform/bus_display/devfreq/bus_display
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_fsys ->
../../devices/platform/bus_fsys/devfreq/bus_fsys
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_leftbus ->
../../devices/platform/bus_leftbus/devfreq/bus_leftbus
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_peri ->
../../devices/platform/bus_peri/devfreq/bus_peri
We don't see the following bus device because of following bus device
has the same frequency table with bus_leftbus device.
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_mfc ->
../../devices/platform/bus_mfc/devfreq/bus_mfc
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_rightbus ->
../../devices/platform/bus_rightbus/devfreq/bus_rightbus
>>>
>>> Right, but why do you want to see these bus devices? AFAIU, they will
>>
>> I think that the
Re: [PATCH v2] spi-fsl-dspi: Fix CTAR Register access
On Thursday 10 December 2015 11:25:30, Bhuvanchandra DV wrote: > DSPI instances in Vybrid have a different amount of chip selects > and CTARs (Clock and transfer Attributes Register). In case of > DSPI1 we only have 2 CTAR registers and 4 CS. In present driver > implementation CTAR offset is derived from CS instance which will > lead to out of bound access if chip select instance is greater than > CTAR register instance, hence use single CTAR0 register for all CS > instances. Since we write the CTAR register anyway before each access, > there is no value in using the additional CTAR registers. Also one > should not program a value in CTAS for a CTAR register that is not > present, hence configure CTAS to use CTAR0. Shouldn't the information put into struct fsl_dspi_devtype_data how much CTAR and CS the actual implementation has available? E.g. LS1021A has 6 CS and 4 CTAR Best regards, Alexander -- - Please note our closure period for Christmas vacation and turn of the year We are closed from 21st December 2015 to 3rd January 2016 - Dipl.-Inf. Alexander Stein SYS TEC electronic GmbH alexander.st...@systec-electronic.com Legal and Commercial Address: Am Windrad 2 08468 Heinsdorfergrund Germany Office: +49 (0) 3765 38600-0 Fax:+49 (0) 3765 38600-4100 Managing Directors: Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt; Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp Commercial Registry: Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010 -- 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: mtd, nand, omap2: parse cmdline partition fail
On Thu, Dec 10, 2015 at 12:19 AM, Brian Norris
wrote:
> On Fri, Dec 04, 2015 at 09:42:06AM +0100, Heiko Schocher wrote:
>> It seems to me add_mtd_device() gets only called for the mtd partitions
>> parsed from the cmdline ...
>
> That's true, when CONFIG_MTD_PARTITIONED_MASTER=n. (I'm really thinking
> we should accelerate the adoption of PARTITIONED_MASTER... maybe set it
> to default =y?)
>
> But even with CONFIG_MTD_PARTITIONED_MASTER=y we still have a problem.
>
> [...]
>
>> >The fact that this produces different names for you is slightly
>> >surprising to me, unless mtd->name is already set to something by the
>> >time it reaches add_mtd_device(). Or I overlooked something, which is
>> >entirely plausible as well.
>> >
>> >So effectively this should be the same as doing:
>> >
>> > mtd->dev.parent = >dev;
>> > mtd->name = dev_name(mtd->dev.parent);
>
> Yes, except for one thing (and this is the key): the mtd->name only gets
> set *after* the partitions are parsed, using the method from commit
> 807f16d4db95 ("mtd: core: set some defaults when dev.parent is set"). So
> the parsers (including cmdlinepart) get run with a blank (NULL) name,
> and you can't detect any partitions, since the name match will never
> work.
Right, that was something we overlooked earlier.
> I have a hack of a patch below (untested) that would hopefully work
> (based on current l2-mtd.git). I could port this to a base on 4.4-rc1 if
> it works OK, so we can get the regression fixed in this cycle.
That would be nice.
>> >>But wondering, if there are two or more identical nand chips in the
>> >>system, they will have the same mtd->name ... which seems buggy to me...
>> >
>> >Agree.
>>
>> Good, so we must fix it ;-)
>
> Yeah, that's a bad problem. Most people only plan for one chip and then
> realize they need 2 later. nand_base should probably support something
> to do this easily. Unfortunately, making a change like that could cause
> some problems with cmdline naming across kernel versions, if we start
> changing the convention for some drivers...(do we consider the MTD name
> part of the ABI?)
I would expect a name to be just a name; something parsable by humans.
By definition that cannot be an ABI. On the other hand, maybe it has
grown to become part of the ABI.
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index 89d811e7b04a..185dc36c687f 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -592,6 +592,15 @@ int mtd_device_parse_register(struct mtd_info *mtd,
> const char * const *types,
> struct mtd_partitions parsed;
> int ret;
>
> + if (mtd->dev.parent) {
> + if (!mtd->owner && mtd->dev.parent->driver)
> + mtd->owner = mtd->dev.parent->driver->owner;
> + if (!mtd->name)
> + mtd->name = dev_name(mtd->dev.parent);
> + } else {
> + pr_debug("mtd device won't show a device symlink in sysfs\n");
> + }
> +
> memset(, 0, sizeof(parsed));
>
> ret = parse_mtd_partitions(mtd, types, , parser_data);
This was the first thing I thought of when this issue was brought up.
If you do this, do you still need the chunk of code you copied from in
add_mtd_device()? Since we fill in these things on the master, I
wouldn't think we do.
Thanks,
Frans
--
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] Fixed coding style problems based on checkpatch.pl for goldfish_audio.c
On Wed, Dec 09, 2015 at 03:46:02PM -0800, Benjamin Young wrote: > From f18a3e5f155f5258d2d19ac6b56bfaafa2ad470b Mon Sep 17 00:00:00 2001 > From: Benjamin Young > Date: Wed, 9 Dec 2015 13:45:00 -0800 > Subject: [PATCH] Fixed coding style problems based on checkpatch.pl for > goldfish_audio.c This should not be here. You have not given in commit message and you are doing multiple changes in this patch. Please split them into separate patch, each patch doing only a single type of change. regards sudip -- 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 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12
On 10.12.2015 16:07, Chanwoo Choi wrote:
> On 2015년 12월 10일 15:53, Krzysztof Kozlowski wrote:
>> On 10.12.2015 15:43, Chanwoo Choi wrote:
>>> On 2015년 12월 10일 15:32, Krzysztof Kozlowski wrote:
On 10.12.2015 15:08, Chanwoo Choi wrote:
> On 2015년 12월 10일 14:57, Krzysztof Kozlowski wrote:
>> On 09.12.2015 13:08, Chanwoo Choi wrote:
>>> This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
>>> Exynos4x12 has the following AXI buses to translate data between
>>> DRAM and sub-blocks.
>>>
>>> Following list specifies the detailed relation between DRAM and
>>> sub-blocks:
>>> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
>>> - ACLK160 clock for CAM/TV/LCD
>>> : The minimum clock of ACLK160 should be over 160MHz.
>>> When drop the clock under 160MHz, show the broken image.
>>> - ACLK133 clock for FSYS
>>> - GDL clock for LEFTBUS
>>> - GDR clock for RIGHTBUS
>>> - SCLK_MFC clock for MFC
>>>
>>> Signed-off-by: Chanwoo Choi
>>> ---
>>> arch/arm/boot/dts/exynos4x12.dtsi | 112
>>> ++
>>> 1 file changed, 112 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
>>> b/arch/arm/boot/dts/exynos4x12.dtsi
>>> index 3bcf0939755e..8bc4aee156b5 100644
>>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>>> @@ -354,6 +354,118 @@
>>> opp-microvolt = <95>;
>>> };
>>> };
>>> +
>>> + bus_leftbus: bus_leftbus {
>>> + compatible = "samsung,exynos-bus";
>>> + clocks = < CLK_DIV_GDL>;
>>> + clock-names = "bus";
>>> + operating-points-v2 = <_leftbus_opp_table>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + bus_rightbus: bus_rightbus {
>>> + compatible = "samsung,exynos-bus";
>>> + clocks = < CLK_DIV_GDR>;
>>> + clock-names = "bus";
>>> + operating-points-v2 = <_leftbus_opp_table>;
>>> + status = "disabled";
>>> + };
>>
>> These two nodes are symmetrical. The MFC below and other buses in other
>> DTS share opps. How about changing the binding so multiple clocks could
>> be specified at once ("bus0", "bus1")? I think there is no need for a
>> bus device for each clock.
>
> The your commented method is possible.
>
> But, I focus on implementing the generic bus frequency driver.
>
> If specific bus device-tree node includes the one more clocks,
> when adding the new Exynos SoC, the exynos-bus.c should be added
> for new Exynos SoC. Because, each Exynos SoC has the different
> set of bus device.
>
> If we use my approach, we don't need to modify the exynos-bus.c
> driver to support for the bus frequency of new Exynos SoC.
This won't change. The driver will just support from 1 to N clocks for
given bus device and set the same OPP to all of them. This will only
limit the number of duplicated entries. This won't affect the generic
approach of driver itself.
>>>
>>> You're right aspect of only implementation of device driver.
>>>
>>> But,
>>> If we use your commented approach, we can show the information
>>> of only parent device through sysfs. We cannot see the information
>>> of passive device. The some information includes the current
>>> frequency and correlation of parent device. (But, current patchset
>>> don' include the topology information between parent device and
>>> passive device. I'll do it on later patches).
>>>
>>> For example,
>>> We can see the following bus device through /sys/class/devfreq.
>>>
>>> drwxr-xr-x 2 root root 0 Dec 31 17:00 .
>>> drwxr-xr-x 44 root root 0 Dec 31 17:00 ..
>>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_display ->
>>> ../../devices/platform/bus_display/devfreq/bus_display
>>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_fsys ->
>>> ../../devices/platform/bus_fsys/devfreq/bus_fsys
>>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_leftbus ->
>>> ../../devices/platform/bus_leftbus/devfreq/bus_leftbus
>>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_peri ->
>>> ../../devices/platform/bus_peri/devfreq/bus_peri
>>>
>>>
>>> We don't see the following bus device because of following bus device
>>> has the same frequency table with bus_leftbus device.
>>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_mfc ->
>>> ../../devices/platform/bus_mfc/devfreq/bus_mfc
>>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_rightbus ->
>>> ../../devices/platform/bus_rightbus/devfreq/bus_rightbus
>>
>> Right, but why do you want to see these bus devices? AFAIU, they will
>
> I think that the framework should show the accurate information of H/w device
> through sysfs. On the exynos-bus.c driver, it is important the show the
> accurate
[PATCH 1/1] Fix int1 recursion when no perf_bp_event is registered
If an int1 hardware breakpoint exception is triggered, but no perf bp
pevent block was registered from arch_install_hw_breakpoint, the
system will hard hang with the CPU stuck constantly re-interrupting at
the same execution address because the resume flag never gets set, and
the NOTIFY_DONE state prevents other int1 handlers, including the
default handler in do_debug, from running to handle the condition.
Can be reproduced by writing a program that sets an execute breakpoint
at schedule() without calling arch_install_hw_breakpoint.
The proposed fix checks the dr7 register and sets the resume flag in
pt->regs if it determines an executed breakpoint was triggered just in
case the check lower down fails. I have seen this bug and its a bug.
Signed-off-by: jeffmer...@gmail.com
diff --git a/arch/x86/kernel/hw_breakpoint.c b/arch/x86/kernel/hw_breakpoint.c
index 50a3fad..6effcae 100644
--- a/arch/x86/kernel/hw_breakpoint.c
+++ b/arch/x86/kernel/hw_breakpoint.c
@@ -475,6 +475,14 @@ static int hw_breakpoint_handler(struct die_args *args)
for (i = 0; i < HBP_NUM; ++i) {
if (likely(!(dr6 & (DR_TRAP0 << i
continue;
+ /*
+* Set up resume flag to avoid breakpoint recursion when
+* returning back to origin in the event an int1
+* exception is triggered and no event handler
+* is present.
+*/
+ if ((dr7 & (3 << ((i * 4) + 16))) == 0)
+ args->regs->flags |= X86_EFLAGS_RF;
/*
* The counter may be concurrently released but that can only
--
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] fs: clear file privilege bits when mmap writing
On Thu, Dec 10, 2015 at 08:06:35AM +0100, Willy Tarreau wrote: > Hi Kees, > > Why not add a new file flag instead ? > > Something like this (editing your patch by hand to illustrate) : (...) > diff --git a/include/linux/fs.h b/include/linux/fs.h > index 3aa514254161..409bd7047e7e 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -913,3 +913,4 @@ > #define FL_OFDLCK 1024/* lock is "owned" by struct file */ > #define FL_LAYOUT 2048/* outstanding pNFS layout */ > +#define FL_DROP_PRIVS 4096/* lest something weird decides that 2 is OK > */ Crap, these ones are for locks, we need to use O_* instead But anyway you get the idea, I mean there are probably many spare bits overthere. Another option I was thinking about was to change f_mode and detect the change on close. But I don't know what to compare it against. Willy -- 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 19/19] ARM: dts: Add support of bus frequency for exynos4412-trats/odroidu3
On 09.12.2015 13:08, Chanwoo Choi wrote:
> THis patch adds the bus device tree nodes for both MIF (Memory) and INT
> (Internal) block to enable the bus frequency.
>
> The DMC bus is parent device in MIF block using VDD_MIF and the LEFTBUS
> bus is parent device in INT block using VDD_INT.
>
> Signed-off-by: Chanwoo Choi
> ---
> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 47
> +
> arch/arm/boot/dts/exynos4412-trats2.dts | 47
> +
> 2 files changed, 94 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> index 171dea1e3e4a..12d08242a179 100644
> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> @@ -544,3 +544,50 @@
> };
> };
> };
> +
> +_dmc {
> + devfreq-events = <_dmc0_3>, <_dmc1_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_acp {
> + devfreq = <_dmc>;
> + status = "okay";
> +};
> +
> +_c2c {
> + devfreq = <_dmc>;
> + status = "okay";
> +};
> +
> +_leftbus {
> + devfreq-events = <_leftbus_3>, <_rightbus_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_rightbus {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_display {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_fsys {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_peri {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_mfc {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
> b/arch/arm/boot/dts/exynos4412-trats2.dts
> index 40a474c4374b..aecd545803ad 100644
> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
> @@ -1286,3 +1286,50 @@
> vtmu-supply = <_reg>;
> status = "okay";
> };
> +
> +_dmc {
> + devfreq-events = <_dmc0_3>, <_dmc1_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_acp {
> + devfreq = <_dmc>;
> + status = "okay";
> +};
> +
> +_c2c {
> + devfreq = <_dmc>;
> + status = "okay";
> +};
> +
> +_leftbus {
> + devfreq-events = <_leftbus_3>, <_rightbus_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_rightbus {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_display {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_fsys {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_peri {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_mfc {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
The nodes in both files are mostly sorted alphabetically. Could you
place them in such order as well?
Best regards,
Krzysztof
--
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 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12
On 2015년 12월 10일 15:53, Krzysztof Kozlowski wrote:
> On 10.12.2015 15:43, Chanwoo Choi wrote:
>> On 2015년 12월 10일 15:32, Krzysztof Kozlowski wrote:
>>> On 10.12.2015 15:08, Chanwoo Choi wrote:
On 2015년 12월 10일 14:57, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:08, Chanwoo Choi wrote:
>> This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
>> Exynos4x12 has the following AXI buses to translate data between
>> DRAM and sub-blocks.
>>
>> Following list specifies the detailed relation between DRAM and
>> sub-blocks:
>> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
>> - ACLK160 clock for CAM/TV/LCD
>> : The minimum clock of ACLK160 should be over 160MHz.
>> When drop the clock under 160MHz, show the broken image.
>> - ACLK133 clock for FSYS
>> - GDL clock for LEFTBUS
>> - GDR clock for RIGHTBUS
>> - SCLK_MFC clock for MFC
>>
>> Signed-off-by: Chanwoo Choi
>> ---
>> arch/arm/boot/dts/exynos4x12.dtsi | 112
>> ++
>> 1 file changed, 112 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
>> b/arch/arm/boot/dts/exynos4x12.dtsi
>> index 3bcf0939755e..8bc4aee156b5 100644
>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>> @@ -354,6 +354,118 @@
>> opp-microvolt = <95>;
>> };
>> };
>> +
>> +bus_leftbus: bus_leftbus {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_DIV_GDL>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_rightbus: bus_rightbus {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_DIV_GDR>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>
> These two nodes are symmetrical. The MFC below and other buses in other
> DTS share opps. How about changing the binding so multiple clocks could
> be specified at once ("bus0", "bus1")? I think there is no need for a
> bus device for each clock.
The your commented method is possible.
But, I focus on implementing the generic bus frequency driver.
If specific bus device-tree node includes the one more clocks,
when adding the new Exynos SoC, the exynos-bus.c should be added
for new Exynos SoC. Because, each Exynos SoC has the different
set of bus device.
If we use my approach, we don't need to modify the exynos-bus.c
driver to support for the bus frequency of new Exynos SoC.
>>>
>>> This won't change. The driver will just support from 1 to N clocks for
>>> given bus device and set the same OPP to all of them. This will only
>>> limit the number of duplicated entries. This won't affect the generic
>>> approach of driver itself.
>>
>> You're right aspect of only implementation of device driver.
>>
>> But,
>> If we use your commented approach, we can show the information
>> of only parent device through sysfs. We cannot see the information
>> of passive device. The some information includes the current
>> frequency and correlation of parent device. (But, current patchset
>> don' include the topology information between parent device and
>> passive device. I'll do it on later patches).
>>
>> For example,
>> We can see the following bus device through /sys/class/devfreq.
>>
>> drwxr-xr-x 2 root root 0 Dec 31 17:00 .
>> drwxr-xr-x 44 root root 0 Dec 31 17:00 ..
>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_display ->
>> ../../devices/platform/bus_display/devfreq/bus_display
>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_fsys ->
>> ../../devices/platform/bus_fsys/devfreq/bus_fsys
>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_leftbus ->
>> ../../devices/platform/bus_leftbus/devfreq/bus_leftbus
>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_peri ->
>> ../../devices/platform/bus_peri/devfreq/bus_peri
>>
>>
>> We don't see the following bus device because of following bus device
>> has the same frequency table with bus_leftbus device.
>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_mfc ->
>> ../../devices/platform/bus_mfc/devfreq/bus_mfc
>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_rightbus ->
>> ../../devices/platform/bus_rightbus/devfreq/bus_rightbus
>
> Right, but why do you want to see these bus devices? AFAIU, they will
I think that the framework should show the accurate information of H/w device
through sysfs. On the exynos-bus.c driver, it is important the show the
accurate set of handled bus devices which are included in Exynos SoC.
> always behave exactly the same as LEFTBUS. Their PPMU counters will be
> the
Re: [PATCH v5] fs: clear file privilege bits when mmap writing
Hi Kees,
Why not add a new file flag instead ?
Something like this (editing your patch by hand to illustrate) :
diff --git a/fs/file_table.c b/fs/file_table.c
index ad17e05ebf95..3a7eee76ea90 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -191,6 +191,17 @@ static void __fput(struct file *file)
might_sleep();
+ /*
+* XXX: While avoiding mmap_sem, we've already been written to.
+* We must ignore the return value, since we can't reject the
+* write.
+*/
+ if (unlikely(file->f_flags & FL_DROP_PRIVS)) {
+ mutex_lock(>i_mutex);
+ file_remove_privs(file);
+ mutex_unlock(>i_mutex);
+ }
+
fsnotify_close(file);
/*
* The function eventpoll_release() should be the first called
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 3aa514254161..409bd7047e7e 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -913,3 +913,4 @@
#define FL_OFDLCK 1024/* lock is "owned" by struct file */
#define FL_LAYOUT 2048/* outstanding pNFS layout */
+#define FL_DROP_PRIVS 4096/* lest something weird decides that 2 is OK */
diff --git a/mm/memory.c b/mm/memory.c
index c387430f06c3..08a77e0cf65f 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2036,6 +2036,7 @@ static inline int wp_page_reuse(struct mm_struct *mm,
if (!page_mkwrite)
file_update_time(vma->vm_file);
+ vma->vm_file->f_flags |= FL_DROP_PRIVS;
}
return VM_FAULT_WRITE;
Willy
--
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/
[V6.1 PATCH 5/6] x86/nmi: Fix to save registers for crash dump on external NMI broadcast
Now, multiple CPUs can receive external NMI simultaneously by
specifying "apic_extnmi=all" as an boot option. When we take a
crash dump by using external NMI with this option, we fail to save
register values into the crash dump. This happens as follows:
CPU 0 CPU 1
=
receive an external NMI
default_do_nmi() receive an external NMI
spin_lock(_reason_lock) default_do_nmi()
io_check_error() spin_lock(_reason_lock)
panic()busy loop
...
kdump_nmi_shootdown_cpus()
issue NMI IPI ---> blocked until IRET
busy loop...
Here, since CPU 1 is in NMI context, additional NMI from CPU 0
is blocked until CPU 1 executes IRET. However, CPU 1 never
executes IRET, so the NMI is not handled and the callback function
to save registers is never called.
To solve this issue, we check if the IPI for crash dumping was
issued while waiting for nmi_reason_lock to be released, and if so,
call its callback function directly. If the IPI is not issued (e.g.
kdump is disabled), the actual behavior doesn't change.
V6.1:
- Reintroduce the UP version of run_crash_ipi_callback to fix build
error for CONFIG_SMP=n and CONFIG_DEBUG_SPINLOCK=y case
V6:
- Separated from the former patch `panic/x86: Allow cpus to save
registers even if they are looping in NMI context'
- Fix comments
- Remove unneeded UP version of poll_crash_ipi_and_calback
- Rename poll_crash_ipi_and_callback to run_crash_ipi_callback
Signed-off-by: Hidehiro Kawai
Cc: Andrew Morton
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Peter Zijlstra
Cc: Michal Hocko
---
arch/x86/include/asm/reboot.h |1 +
arch/x86/kernel/nmi.c | 11 ++-
arch/x86/kernel/reboot.c | 22 +-
3 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/reboot.h b/arch/x86/include/asm/reboot.h
index a82c4f1..2cb1cc2 100644
--- a/arch/x86/include/asm/reboot.h
+++ b/arch/x86/include/asm/reboot.h
@@ -25,5 +25,6 @@ void __noreturn machine_real_restart(unsigned int type);
typedef void (*nmi_shootdown_cb)(int, struct pt_regs*);
void nmi_shootdown_cpus(nmi_shootdown_cb callback);
+void run_crash_ipi_callback(struct pt_regs *regs);
#endif /* _ASM_X86_REBOOT_H */
diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
index 5e00de7..cbfa0b5 100644
--- a/arch/x86/kernel/nmi.c
+++ b/arch/x86/kernel/nmi.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#define CREATE_TRACE_POINTS
#include
@@ -357,7 +358,15 @@ static void default_do_nmi(struct pt_regs *regs)
}
/* Non-CPU-specific NMI: NMI sources can be processed on any CPU */
- raw_spin_lock(_reason_lock);
+ /*
+* Another CPU may be processing panic routines while holding
+* nmi_reason_lock. Check if the CPU issued the IPI for crash
+* dumping, and if so, call its callback directly. If there is
+* no CPU preparing crash dump, we simply loop here without doing
+* special things.
+*/
+ while (!raw_spin_trylock(_reason_lock))
+ run_crash_ipi_callback(regs);
reason = x86_platform.get_nmi_reason();
if (reason & NMI_REASON_MASK) {
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 1da1302..8a184e3 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -793,17 +793,25 @@ void nmi_shootdown_cpus(nmi_shootdown_cb callback)
/* Leave the nmi callback set */
}
+/*
+ * Wait for the crash dumping IPI to be issued, and then call its callback
+ * directly. This function is used when we have already been in NMI handler.
+ */
+void run_crash_ipi_callback(struct pt_regs *regs)
+{
+ if (crash_ipi_issued)
+ crash_nmi_callback(0, regs); /* Don't return */
+}
+
/* Override the weak function in kernel/panic.c */
void nmi_panic_self_stop(struct pt_regs *regs)
{
while (1) {
/*
-* Wait for the crash dumping IPI to be issued, and then
-* call its callback directly.
+* If there is no CPU preparing crash dump, we simply loop
+* here without doing special things.
*/
- if (READ_ONCE(crash_ipi_issued))
- crash_nmi_callback(0, regs); /* Don't return */
-
+ run_crash_ipi_callback(regs);
cpu_relax();
}
}
@@ -813,4 +821,8 @@ void nmi_shootdown_cpus(nmi_shootdown_cb callback)
{
/* No other CPUs to shoot down */
}
+
+void run_crash_ipi_callback(struct pt_regs *regs)
+{
+}
#endif
--
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
Re: [PATCH v2 18/19] ARM: dts: Expand the voltage range of buck1/3 regulator for exynos4412-odroidu3
On 09.12.2015 13:08, Chanwoo Choi wrote: > This patch expands the voltage range of buck1/3 regulator due to as following: > - MIF (Memory Interface) bus frequency needs the 9uV ~ 105uV V. > - INT (Internal) bus frequency needs 9uV ~ 100uV. 9->90 and duplicated "uV V". Maybe just: 900 - 1050 mV 900 - 1000 mV ? > > Signed-off-by: Chanwoo Choi > --- > arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > For the contents of patch: Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- 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 v11] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller
Hi Bjorn, On 10.12.2015 00:19, Bjorn Helgaas wrote: > [+cc Michal, Paul, Thierry, Stephen, Alexandre (see irq_dispose_mapping > questions below)] > > On Sun, Nov 29, 2015 at 05:33:53PM +0530, Bharat Kumar Gogada wrote: >> Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP. >> >> Signed-off-by: Bharat Kumar Gogada >> Signed-off-by: Ravi Kiran Gummaluri >> Acked-by: Rob Herring > > This needs either a MAINTAINERS update or an ack from Michal (whose > MAINTAINERS entry matches anything containing "xilinx"). We have done it in this way because driver owners are changing time to time and my entry cover it that I can pass it to appropriate person who is responsible for it. For this Maintainers part here is my: Acked-by: Michal Simek Thanks, 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 17/19] ARM: dts: Add support of bus frequency using VDD_INT for exynos3250-rinato
On 09.12.2015 13:08, Chanwoo Choi wrote: > This patch adds the bus device-tree node of INT (internal) block > to enable the bus frequency. The following sub-blocks share "to enable the bus frequency scaling" > the VDD_INT power source: > - LEFTBUS (parent device) > - RIGHTBUS > - PERIL > - LCD0 > - FSYS > - MCUISP / ISP > - MFC > > The LEFTBUS is parent device with devfreq ondemand governor > and the rest devices has the dependency on LEFTBUS bus. How about: "and the rest of devices depend on the LEFTBUS device." ? The patch is good: Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- 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 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12
On 10.12.2015 15:43, Chanwoo Choi wrote:
> On 2015년 12월 10일 15:32, Krzysztof Kozlowski wrote:
>> On 10.12.2015 15:08, Chanwoo Choi wrote:
>>> On 2015년 12월 10일 14:57, Krzysztof Kozlowski wrote:
On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
> Exynos4x12 has the following AXI buses to translate data between
> DRAM and sub-blocks.
>
> Following list specifies the detailed relation between DRAM and
> sub-blocks:
> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
> - ACLK160 clock for CAM/TV/LCD
> : The minimum clock of ACLK160 should be over 160MHz.
> When drop the clock under 160MHz, show the broken image.
> - ACLK133 clock for FSYS
> - GDL clock for LEFTBUS
> - GDR clock for RIGHTBUS
> - SCLK_MFC clock for MFC
>
> Signed-off-by: Chanwoo Choi
> ---
> arch/arm/boot/dts/exynos4x12.dtsi | 112
> ++
> 1 file changed, 112 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
> b/arch/arm/boot/dts/exynos4x12.dtsi
> index 3bcf0939755e..8bc4aee156b5 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -354,6 +354,118 @@
> opp-microvolt = <95>;
> };
> };
> +
> + bus_leftbus: bus_leftbus {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_GDL>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_rightbus: bus_rightbus {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_GDR>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
These two nodes are symmetrical. The MFC below and other buses in other
DTS share opps. How about changing the binding so multiple clocks could
be specified at once ("bus0", "bus1")? I think there is no need for a
bus device for each clock.
>>>
>>> The your commented method is possible.
>>>
>>> But, I focus on implementing the generic bus frequency driver.
>>>
>>> If specific bus device-tree node includes the one more clocks,
>>> when adding the new Exynos SoC, the exynos-bus.c should be added
>>> for new Exynos SoC. Because, each Exynos SoC has the different
>>> set of bus device.
>>>
>>> If we use my approach, we don't need to modify the exynos-bus.c
>>> driver to support for the bus frequency of new Exynos SoC.
>>
>> This won't change. The driver will just support from 1 to N clocks for
>> given bus device and set the same OPP to all of them. This will only
>> limit the number of duplicated entries. This won't affect the generic
>> approach of driver itself.
>
> You're right aspect of only implementation of device driver.
>
> But,
> If we use your commented approach, we can show the information
> of only parent device through sysfs. We cannot see the information
> of passive device. The some information includes the current
> frequency and correlation of parent device. (But, current patchset
> don' include the topology information between parent device and
> passive device. I'll do it on later patches).
>
> For example,
> We can see the following bus device through /sys/class/devfreq.
>
> drwxr-xr-x 2 root root 0 Dec 31 17:00 .
> drwxr-xr-x 44 root root 0 Dec 31 17:00 ..
> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_display ->
> ../../devices/platform/bus_display/devfreq/bus_display
> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_fsys ->
> ../../devices/platform/bus_fsys/devfreq/bus_fsys
> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_leftbus ->
> ../../devices/platform/bus_leftbus/devfreq/bus_leftbus
> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_peri ->
> ../../devices/platform/bus_peri/devfreq/bus_peri
>
>
> We don't see the following bus device because of following bus device
> has the same frequency table with bus_leftbus device.
> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_mfc ->
> ../../devices/platform/bus_mfc/devfreq/bus_mfc
> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_rightbus ->
> ../../devices/platform/bus_rightbus/devfreq/bus_rightbus
Right, but why do you want to see these bus devices? AFAIU, they will
always behave exactly the same as LEFTBUS. Their PPMU counters will be
the same... or not? The MFC does not have its own PPMU counter. There
are separate counters for left and right bus... but they are attached to
the "_leftbus" node. The "_rightbus" does not use the PPMU
counter and it follows the parent governor decisions... so this is
purely an artificial creation just to handle one clock.
I just can't see the benefit of such additional bus device.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Re: [BISECTED] WARNING: CPU: 2 PID: 142 at block/genhd.c:626 add_disk+0x480/0x4e0()
On 12/10/2015 05:00 AM, Laura Abbott wrote:
Hi,
We received a report
(https://bugzilla.redhat.com/show_bug.cgi?id=1288687) that
live images with the rawhide kernel were failing to boot on USB sticks.
Similar issues were reported when just inserting a USB stick into a
boot from a
CD instead of USB ("I see /dev/sdb, but no /dev/sdb1 etc." per the
report)
I reduced the test scenario to:
1) insert scsi_dh_alua module
2) insert Live USB drive
which gives
[ 125.107185] sd 6:0:0:0: alua: supports implicit and explicit TPGS
[ 125.107778] sd 6:0:0:0: [sdb] 15634432 512-byte logical blocks:
(8.00 GB/7.46 GiB)
[ 125.107973] sd 6:0:0:0: alua: No target port descriptors found
[ 125.107975] sd 6:0:0:0: alua: Attach failed (-22)
[ 125.107978] sd 6:0:0:0: failed to add device handler: -22
[ 125.108462] sd 6:0:0:0: [sdb] Write Protect is off
[ 125.108465] sd 6:0:0:0: [sdb] Mode Sense: 43 00 00 00
[ 125.108468] sd 6:0:0:0: [sdb] Asking for cache data failed
[ 125.108469] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[ 125.109122] [ cut here ]
[ 125.109127] WARNING: CPU: 2 PID: 142 at block/genhd.c:626
add_disk+0x480/0x4e0()
[ 125.109128] Modules linked in: uas usb_storage scsi_dh_alua fuse
xt_CHECKSUM
ipt_MASQUERADE nf_nat_masquerade_ipv4 ccm tun nf_conntrack_netbios_ns
nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
xt_conntrack
ebtable_filter ebtable_nat ebtable_broute bridge stp llc ebtables
ip6table_raw
ip6table_security ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6
nf_nat_ipv6
ip6table_mangle ip6table_filter ip6_tables iptable_raw iptable_security
iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
nf_conntrack
iptable_mangle bnep snd_hda_codec_hdmi arc4 iwlmvm mac80211 i915
intel_rapl
iosf_mbi x86_pkg_temp_thermal coretemp iwlwifi kvm_intel kvm
snd_hda_codec_realtek uvcvideo snd_hda_codec_generic btusb
snd_hda_intel btrtl
videobuf2_vmalloc cfg80211 snd_hda_codec btbcm iTCO_wdt videobuf2_v4l2
[ 125.109164] btintel iTCO_vendor_support videobuf2_core irqbypass
videobuf2_memops bluetooth v4l2_common snd_hda_core ghash_clmulni_intel
videodev snd_hwdep snd_seq media pcspkr joydev snd_seq_device
rtsx_pci_ms
snd_pcm memstick thinkpad_acpi snd_timer mei_me snd i2c_algo_bit mei
drm_kms_helper ie31200_edac rfkill tpm_tis edac_core shpchp
soundcore tpm
i2c_i801 lpc_ich wmi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
binfmt_misc
dm_crypt hid_microsoft rtsx_pci_sdmmc mmc_core crct10dif_pclmul
crc32_pclmul
crc32c_intel serio_raw drm e1000e ptp rtsx_pci pps_core fjes video
[ 125.109197] CPU: 2 PID: 142 Comm: kworker/u16:6 Tainted: G W
4.4.0-rc4-usbbadness-next-20151209+ #3
[ 125.109198] Hardware name: LENOVO 20BFS0EC00/20BFS0EC00, BIOS
GMET62WW (2.10 ) 03/19/2014
[ 125.109202] Workqueue: events_unbound async_run_entry_fn
[ 125.109204] 202f2ede 880402ccfc38
81434509
[ 125.109206] 880402ccfc70 810ad9c2
880407a1e000
[ 125.109208] 880407a1e0b0 880407a1e00c 880401e48ef0
8800c90d0600
[ 125.109211] Call Trace:
[ 125.109214] [] dump_stack+0x4b/0x72
[ 125.109218] [] warn_slowpath_common+0x82/0xc0
[ 125.109220] [] warn_slowpath_null+0x1a/0x20
[ 125.109222] [] add_disk+0x480/0x4e0
[ 125.109225] [] sd_probe_async+0x115/0x1d0
[ 125.109227] [] async_run_entry_fn+0x4a/0x140
[ 125.109231] [] process_one_work+0x239/0x6b0
[ 125.109233] [] ? process_one_work+0x1a2/0x6b0
[ 125.109235] [] worker_thread+0x4e/0x490
[ 125.109237] [] ? process_one_work+0x6b0/0x6b0
[ 125.109238] [] kthread+0x101/0x120
[ 125.109242] [] ?
trace_hardirqs_on_caller+0x129/0x1b0
[ 125.109243] [] ? kthread_create_on_node+0x250/0x250
[ 125.109247] [] ret_from_fork+0x3f/0x70
[ 125.109248] [] ? kthread_create_on_node+0x250/0x250
[ 125.109250] ---[ end trace d54b73ed8d1295d5 ]---
[ 125.109272] sd 6:0:0:0: [sdb] Attached SCSI removable disk
and no partitions so the drive can't be mounted. Note the alua -EINVAL
error is there even when the drive can be mounted so the warning and
lack of partitions is the real indication of the problem.
I did a bisect and came up with this as the first bad commit:
commit 086b91d052ebe4ead5d28021afe3bdfd70af15bf
Author: Christoph Hellwig
Date: Thu Aug 27 14:16:57 2015 +0200
scsi_dh: integrate into the core SCSI code
Stop building scsi_dh as a separate module and integrate it fully
into the
core SCSI code with explicit callouts at bus scan time. For now the
callouts are placed at the same point as the old bus notifiers were
called,
but in the future we will be able to look at ALUA INQUIRY data
earlier on.
Note that this also means that the device handler modules need to be
loaded
by the time we scan the bus. The next patches will add support for
autoloading device handlers at bus scan time to make sure they are
always
loaded if they are enabled in the kernel config.
Signed-off-by: Christoph Hellwig
Reviewed-by: Martin K. Petersen
Reviewed-by: Hannes Reinecke
Acked-by: Mike Snitzer
Re: [PATCH v2 16/19] ARM: dts: Add PPMU node for exynos4412-odroidu3
On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch add dt node for PPMU_{DMC0|DMC1|LEFTBUS|RIGHTBUS} for
> exynos4412-odroidu3 board. Each PPMU dt node includes one event of
> 'PPMU Count3'.
>
> Signed-off-by: Chanwoo Choi
> ---
> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 40
> +
> 1 file changed, 40 insertions(+)
>
The patch itself is good but now I see that it is duplicated with
Rinato, Monk and Trats2. Probably for all other Exynos4 and
one-cluster-Exynos5 boards this would be exactly the same as well.
How about making a DTSI file with common PPMU events configuration?
Best regards,
Krzysztof
--
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: [PATCHv3] Input: xpad - Fix double URB submission races
Hi Laura,
On Mon, Nov 16, 2015 at 02:47:13PM -0800, Laura Abbott wrote:
> +static int __xpad_submit_urb(struct usb_xpad *xpad,
> + unsigned char odata[XPAD_PKT_LEN], int transfer_length,
> + int type, bool safe_submit)
> +{
> + int ret;
> +
> + if (safe_submit || xpad->submit_state == OUT_IRQ_AVAILABLE) {
> + memcpy(xpad->odata, odata, transfer_length);
> + xpad->irq_out->transfer_buffer_length = transfer_length;
> + ret = usb_submit_urb(xpad->irq_out, GFP_ATOMIC);
> + xpad->submit_state = OUT_IRQ_QUEUE_EMPTY;
> + xpad->out_submitter = type;
> + } else {
> + /*
> + * The goal here is to prevent starvation of any other type.
> + * If this type matches what is being submitted and there is
> + * another type in the queue, don't ovewrite it
> + */
> + if (xpad->submit_state != OUT_IRQ_QUEUE_EMPTY &&
> + xpad->out_submitter == type &&
> + xpad->queue_submitter != type) {
> + ret = -EBUSY;
> + goto out;
No, we do not want to return "busy" here. We should save the most
up-to-date request of given type and re-submit it when URB is no longer
busy.
I CCed you on another patch addressing the same issue, please take a
look when you have a chance.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12
On 2015년 12월 10일 15:32, Krzysztof Kozlowski wrote:
> On 10.12.2015 15:08, Chanwoo Choi wrote:
>> On 2015년 12월 10일 14:57, Krzysztof Kozlowski wrote:
>>> On 09.12.2015 13:08, Chanwoo Choi wrote:
This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
Exynos4x12 has the following AXI buses to translate data between
DRAM and sub-blocks.
Following list specifies the detailed relation between DRAM and sub-blocks:
- ACLK100 clock for PERIL/PERIR/MFC(PCLK)
- ACLK160 clock for CAM/TV/LCD
: The minimum clock of ACLK160 should be over 160MHz.
When drop the clock under 160MHz, show the broken image.
- ACLK133 clock for FSYS
- GDL clock for LEFTBUS
- GDR clock for RIGHTBUS
- SCLK_MFC clock for MFC
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos4x12.dtsi | 112
++
1 file changed, 112 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 3bcf0939755e..8bc4aee156b5 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -354,6 +354,118 @@
opp-microvolt = <95>;
};
};
+
+ bus_leftbus: bus_leftbus {
+ compatible = "samsung,exynos-bus";
+ clocks = < CLK_DIV_GDL>;
+ clock-names = "bus";
+ operating-points-v2 = <_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_rightbus: bus_rightbus {
+ compatible = "samsung,exynos-bus";
+ clocks = < CLK_DIV_GDR>;
+ clock-names = "bus";
+ operating-points-v2 = <_leftbus_opp_table>;
+ status = "disabled";
+ };
>>>
>>> These two nodes are symmetrical. The MFC below and other buses in other
>>> DTS share opps. How about changing the binding so multiple clocks could
>>> be specified at once ("bus0", "bus1")? I think there is no need for a
>>> bus device for each clock.
>>
>> The your commented method is possible.
>>
>> But, I focus on implementing the generic bus frequency driver.
>>
>> If specific bus device-tree node includes the one more clocks,
>> when adding the new Exynos SoC, the exynos-bus.c should be added
>> for new Exynos SoC. Because, each Exynos SoC has the different
>> set of bus device.
>>
>> If we use my approach, we don't need to modify the exynos-bus.c
>> driver to support for the bus frequency of new Exynos SoC.
>
> This won't change. The driver will just support from 1 to N clocks for
> given bus device and set the same OPP to all of them. This will only
> limit the number of duplicated entries. This won't affect the generic
> approach of driver itself.
You're right aspect of only implementation of device driver.
But,
If we use your commented approach, we can show the information
of only parent device through sysfs. We cannot see the information
of passive device. The some information includes the current
frequency and correlation of parent device. (But, current patchset
don' include the topology information between parent device and
passive device. I'll do it on later patches).
For example,
We can see the following bus device through /sys/class/devfreq.
drwxr-xr-x 2 root root 0 Dec 31 17:00 .
drwxr-xr-x 44 root root 0 Dec 31 17:00 ..
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_display ->
../../devices/platform/bus_display/devfreq/bus_display
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_fsys ->
../../devices/platform/bus_fsys/devfreq/bus_fsys
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_leftbus ->
../../devices/platform/bus_leftbus/devfreq/bus_leftbus
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_peri ->
../../devices/platform/bus_peri/devfreq/bus_peri
We don't see the following bus device because of following bus device
has the same frequency table with bus_leftbus device.
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_mfc ->
../../devices/platform/bus_mfc/devfreq/bus_mfc
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_rightbus ->
../../devices/platform/bus_rightbus/devfreq/bus_rightbus
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4/9] dmaengine: pl330: add new items for pl330 private data
>-Original Message-
>From: Vinod Koul [mailto:vinod.k...@intel.com]
>Sent: Thursday, December 10, 2015 12:09 PM
>To: Wang, Annie
>Cc: Mika Westerberg; Joerg Roedel; Greg Kroah-Hartman; Rafael J. Wysocki;
>linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
>ser...@vger.kernel.org; dmaeng...@vger.kernel.org; iommu@lists.linux-
>foundation.org; Borislav Petkov; Huang, Ray; Wan, Vincent; Xue, Ken; Li, Tony
>Subject: Re: [PATCH 4/9] dmaengine: pl330: add new items for pl330 private data
>
>On Fri, Dec 04, 2015 at 11:24:21AM +0800, Wang Hongcheng wrote:
>> has_no_cap_mask means this device has no preset cap mask.
>> mcbuf_sz means bytes to allocate for MC buffer.
>
>MC ?
Size of MicroCode buffers for each channel. I will update the comment.
>> flags is for irq sharing, default is non-shared, in AMD Carrizo, pl330
>> shares IRQ with its corresponding UART device.
>>
>> Signed-off-by: Wang Hongcheng
>> ---
>> drivers/acpi/acpi_apd.c| 13 -
>> drivers/dma/pl330.c| 19 +--
>> include/linux/amba/pl330.h | 3 +++
>> 3 files changed, 28 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c index
>> eb3316a..7a582f5 100644
>> --- a/drivers/acpi/acpi_apd.c
>> +++ b/drivers/acpi/acpi_apd.c
>> @@ -21,6 +21,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>>
>> #include "internal.h"
>> @@ -35,6 +36,16 @@ struct apd_private_data;
>> #define ACPI_APD_SYSFS BIT(0)
>> #define ACPI_APD_PM BIT(1)
>>
>> +static u8 peri_id[2] = { 0, 1 };
>> +
>> +static struct dma_pl330_platdata amd_pl330 = {
>> +.nr_valid_peri = 2,
>> +.peri_id = peri_id,
>> +.has_no_cap_mask = true,
>> +.mcbuf_sz = 0,
>> +.flags = IRQF_SHARED,
>> +};
>
>Why not DT or ACPI for this?
>
>--
>~Vinod
We choose to use private data, as pl330 already has struct dma_pl330_platdata.
Physically DMA share ACPI device with UART, however, BIOS believes DMA and UART
is one device.
We can't get irq share info from ACPI. And we don't use DT.
Regards,
Annie
--
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: Re: [V6 PATCH 5/6] x86/nmi: Fix to save registers for crash dump on external NMI broadcast
Hi Steven,
> From: Steven Rostedt [mailto:rost...@goodmis.org]
> On Tue, Nov 24, 2015 at 11:48:53AM +0100, Borislav Petkov wrote:
> > > + */
> > > + while (!raw_spin_trylock(_reason_lock))
> > > + poll_crash_ipi_and_callback(regs);
> >
> > Waaait a minute: so if we're getting NMIs broadcasted on every core but
> > we're *not* crash dumping, we will run into here too. This can't be
> > right. :-\
>
> This only does something if crash_ipi_done is set, which means you are killing
> the box. But perhaps a comment that states that here would be useful, or maybe
> just put in the check here. There's no need to make it depend on SMP, as
> raw_spin_trylock() will turn to just ({1}) for UP, and that code wont even be
> hit.
It seems that poll_crash_ipi_and_callback (now renamed to
run_crash_ipi_callback)
is referred for UP if CONFIG_DEBUG_SPINLOCK=y, and it causes a build error
as below. run_crash_ipi_callback refers crash_ipi_issued and
crash_nmi_callback,
which are defined only if CONFIG_SMP=y. So we need to defined it separately
for SMP and UP.
I'll resend this patch later.
> Hi Hidehiro,
>
> [auto build test ERROR on v4.4-rc4]
> [also build test ERROR on next-20151209]
> [cannot apply to tip/x86/core]
>
> url:
> https://github.com/0day-ci/linux/commits/Hidehiro-Kawai/Fix-race-issues-among-panic-NMI-and-crash_kexec/20151210-095
> 254
> config: x86_64-randconfig-s4-12101030 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All errors (new ones prefixed by >>):
>
>arch/x86/built-in.o: In function `do_nmi':
> >> (.text+0x7339): undefined reference to `run_crash_ipi_callback'
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH v2 4/9] ARM: dts: add dts files for hi3519-demb board
On 2015/12/9 23:31, Arnd Bergmann wrote: > On Tuesday 08 December 2015 11:54:51 xuejiancheng wrote: >> On 2015/12/7 14:37, xuejiancheng wrote: >>> >>> On 2015/12/4 18:49, Arnd Bergmann wrote: On Friday 04 December 2015 10:27:58 xuejiancheng wrote: >> Maybe split out the sysctrl binding from Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt, as it has you already have a couple of those, and it's not clear how they relate to one another. If we introduce a string for all hip04 compatible sysctrl devices, we should document that and use it consistently, so hi3519 becomes compatible = "hisilicon,hi3519-sysctrl", "hisilicon,hip04-sysctrl", "hisilicon,sysctrl"; but I'd clarify in the binding documentation that "hisilicon,sysctrl" should only be used for hip04 and hi3519 but not the others. As this seems to be a standard part, we can also think about making a high-level driver for in in drivers/soc rather than relying on the syscon driver which we tend to use more for one-off devices with random register layouts. >>>Sorry. I didn't understand your meaning well and maybe I gave you a >>> wrong description. >>> Please allow me to clarify it again. >>>The "sysctrl" nodes here is just used for the "reboot" function. It is >>> corresponding to >>> the driver "drivers/power/reset/hisi-reboot.c". The compatible string in >>> the driver is >>> "hisilicon,sysctrl". >>>The layout of this block is also different from the one in HiP04. >> >> I'll use "syscon" as the compatible value for sysctrl node and >> "syscon-reboot" for a new reboot node. >> >> > > This is not what I meant. You have to use "syscon" as the most generic > "compatible" value here, but should add a machine specific string > as a more specific one. "hisilicon,sysctrl" is not appropriate because > it does not identify the IP block uniquely, you can only use that > in combination with another more specific string. OK. I will use "hisilicon,hi3519-syscon" and "syscon" as the compatible value for the sysctrl node in hi3519.dtsi. Thank you! > > That way, we have to option to create a high-level driver for the IP > block later if it turns out that we need some more generic functionality > that is provided by those registers. > > Arnd > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] MAINTAINERS: change the maintainer of fam15h_power driver
On Thu, 2015-12-10 at 11:56 +0800, Huang Rui wrote: > Andreas Herrmann won't take the maintainer of fam15h_power driver. I > will take it and appreciate him for the great contributions on this > driver. [] > diff --git a/CREDITS b/CREDITS [] > @@ -1507,6 +1507,14 @@ S: 312/107 Canberra Avenue > S: Griffith, ACT 2603 > S: Australia > > +N: Andreas Herrmann > +E: herrmann.der.u...@gmail.com > +E: herrmann.der.u...@googlemail.com > +D: Key developer of x86/AMD64 > +D: Author of AMD family 15h processor power monintoring driver trivia: monitoring -- 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 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12
On 10.12.2015 15:08, Chanwoo Choi wrote:
> On 2015년 12월 10일 14:57, Krzysztof Kozlowski wrote:
>> On 09.12.2015 13:08, Chanwoo Choi wrote:
>>> This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
>>> Exynos4x12 has the following AXI buses to translate data between
>>> DRAM and sub-blocks.
>>>
>>> Following list specifies the detailed relation between DRAM and sub-blocks:
>>> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
>>> - ACLK160 clock for CAM/TV/LCD
>>> : The minimum clock of ACLK160 should be over 160MHz.
>>> When drop the clock under 160MHz, show the broken image.
>>> - ACLK133 clock for FSYS
>>> - GDL clock for LEFTBUS
>>> - GDR clock for RIGHTBUS
>>> - SCLK_MFC clock for MFC
>>>
>>> Signed-off-by: Chanwoo Choi
>>> ---
>>> arch/arm/boot/dts/exynos4x12.dtsi | 112
>>> ++
>>> 1 file changed, 112 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
>>> b/arch/arm/boot/dts/exynos4x12.dtsi
>>> index 3bcf0939755e..8bc4aee156b5 100644
>>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>>> @@ -354,6 +354,118 @@
>>> opp-microvolt = <95>;
>>> };
>>> };
>>> +
>>> + bus_leftbus: bus_leftbus {
>>> + compatible = "samsung,exynos-bus";
>>> + clocks = < CLK_DIV_GDL>;
>>> + clock-names = "bus";
>>> + operating-points-v2 = <_leftbus_opp_table>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + bus_rightbus: bus_rightbus {
>>> + compatible = "samsung,exynos-bus";
>>> + clocks = < CLK_DIV_GDR>;
>>> + clock-names = "bus";
>>> + operating-points-v2 = <_leftbus_opp_table>;
>>> + status = "disabled";
>>> + };
>>
>> These two nodes are symmetrical. The MFC below and other buses in other
>> DTS share opps. How about changing the binding so multiple clocks could
>> be specified at once ("bus0", "bus1")? I think there is no need for a
>> bus device for each clock.
>
> The your commented method is possible.
>
> But, I focus on implementing the generic bus frequency driver.
>
> If specific bus device-tree node includes the one more clocks,
> when adding the new Exynos SoC, the exynos-bus.c should be added
> for new Exynos SoC. Because, each Exynos SoC has the different
> set of bus device.
>
> If we use my approach, we don't need to modify the exynos-bus.c
> driver to support for the bus frequency of new Exynos SoC.
This won't change. The driver will just support from 1 to N clocks for
given bus device and set the same OPP to all of them. This will only
limit the number of duplicated entries. This won't affect the generic
approach of driver itself.
Best regards,
Krzysztof
--
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] hexdump: Add ability to do endian conversions in print_hex_dump functions
On Thu, 2015-12-10 at 13:55 +0800, kbuild test robot wrote: > Hi Joe, Hello Fengguang. Thanks for the report. I'll fix and resubmit. > > > include/linux/printk.h:430:24: sparse: undefined identifier 'BIT' > > > include/linux/printk.h:430:27: sparse: bad constant expression type -- 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 2/2] mm: Introduce kernelcore=mirror option
On 2015/12/10 13:37, Izumi, Taku wrote: > Dear Tony, Xishi, > How about add some comment, if mirrored memroy is too small, then the normal zone is small, so it may be oom. The mirrored memory is at least 1/64 of whole memory, because struct pages usually take 64 bytes per page. >>> >>> 1/64th is the absolute lower bound (for the page structures as you say). I >>> expect people will need to configure 10% or more to run any real workloads. > >>> >>> I made the memblock boot time allocator fall back to non-mirrored memory >>> if mirrored memory ran out. What happens in the run time allocator if the >>> non-movable zones run out of pages? Will we allocate kernel pages from >>> movable >>> memory? >>> >> >> As I know, the kernel pages will not allocated from movable zone. > > Yes, kernel pages are not allocated from ZONE_MOVABLE. > > In this case administrator must review and reconfigure the mirror ratio via > "MirrorRequest" EFI variable. > > Sincerely, > Taku Izumi > Hi Taku, Whether it is possible that we rewrite the fallback function in buddy system when zone_movable and mirrored_kernelcore are both enabled? It seems something like that we add a new zone but the name is zone_movable, not zone_mirror. And the prerequisite is that we won't enable these two features(movable memory and mirrored memory) at the same time. Thus we can reuse the code of movable zone. Thanks, Xishi Qiu >> >>> -- >>> 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: [RFC 0/3] reduce latency of direct async compaction
On 12/10/2015 12:35 PM, Joonsoo Kim wrote:
> On Wed, Dec 09, 2015 at 01:40:06PM +0800, Aaron Lu wrote:
>> On Wed, Dec 09, 2015 at 09:33:53AM +0900, Joonsoo Kim wrote:
>>> On Tue, Dec 08, 2015 at 04:52:42PM +0800, Aaron Lu wrote:
On Tue, Dec 08, 2015 at 03:51:16PM +0900, Joonsoo Kim wrote:
> I add work-around for this problem at isolate_freepages(). Please test
> following one.
Still no luck and the error is about the same:
>>>
>>> There is a mistake... Could you insert () for
>>> cc->free_pfn & ~(pageblock_nr_pages-1) like as following?
>>>
>>> cc->free_pfn == (cc->free_pfn & ~(pageblock_nr_pages-1))
>>
>> Oh right, of course.
>>
>> Good news, the result is much better now:
>> $ cat {0..8}/swap
>> cmdline: /lkp/aaron/src/bin/usemem 100064603136
>> 100064603136 transferred in 72 seconds, throughput: 1325 MB/s
>> cmdline: /lkp/aaron/src/bin/usemem 100072049664
>> 100072049664 transferred in 74 seconds, throughput: 1289 MB/s
>> cmdline: /lkp/aaron/src/bin/usemem 100070246400
>> 100070246400 transferred in 92 seconds, throughput: 1037 MB/s
>> cmdline: /lkp/aaron/src/bin/usemem 100069545984
>> 100069545984 transferred in 81 seconds, throughput: 1178 MB/s
>> cmdline: /lkp/aaron/src/bin/usemem 100058895360
>> 100058895360 transferred in 78 seconds, throughput: 1223 MB/s
>> cmdline: /lkp/aaron/src/bin/usemem 100066074624
>> 100066074624 transferred in 94 seconds, throughput: 1015 MB/s
>> cmdline: /lkp/aaron/src/bin/usemem 100062855168
>> 100062855168 transferred in 77 seconds, throughput: 1239 MB/s
>> cmdline: /lkp/aaron/src/bin/usemem 100060990464
>> 100060990464 transferred in 73 seconds, throughput: 1307 MB/s
>> cmdline: /lkp/aaron/src/bin/usemem 100064996352
>> 100064996352 transferred in 84 seconds, throughput: 1136 MB/s
>> Max: 1325 MB/s
>> Min: 1015 MB/s
>> Avg: 1194 MB/s
>
> Nice result! Thanks for testing.
> I will make a proper formatted patch soon.
Thanks for the nice work.
>
> Then, your concern is solved? I think that performance of
I think so.
> always-always on this test case can't follow up performance of
> always-never because migration cost to make hugepage is additionally
> charged to always-always case. Instead, it will have more hugepage
> mapping and it may result in better performance in some situation.
> I guess that it is intention of that option.
OK, I see.
Regards,
Aaron
--
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/9] ARM: hisi: enable Hi3519 soc
On 2015/12/9 23:32, Arnd Bergmann wrote: > On Tuesday 08 December 2015 11:03:20 xuejiancheng wrote: I think we should come up with a way to handle this in general for ARCH_HISI. It's not problem to have a couple of sub-options, but I'd rather not have one for each SoC because I'm sure that hisilicon has made dozens or possibly hundreds of ARM based SoCs that belong into a couple of families. >>> >>> Agree with you. >>> The individual selection of IP blocks is not that important, because those tend to just be generic device drivers that we can enable on any platform using the defconfig files. You said that ARCH_HI3519 and HIP04 have an identical system controller, but it's different for Hi36xx, correct? >>> >>> No. The system controller of HI3519 is also different from HIP04. Maybe I >>> gave you >>> wrong descriptions. Sorry about that. >>> So maybe we can generalize the HIP04 option to include all chips with that system controller as they appear to share a common ancestry regardless of the target market? >>> >>> I agree that we generalize some options regardless of the product line and >>> target market. >>> The Hi35xx family includes some rather older chips as well based on ARM9 etc, correct? Are they closely related to the new one as well, or do they just share the name? >>> >>> Yes. It's correct. They may share some IP blocks. But they may be very >>> different >>> from the new one for the arch code. I also don't think it's a good idea to >>> make >>> them share the same name. >> >> I will use ARCH_HISI instead of ARCH_HI3519. >> >> > > Do you mean you want to remove the other options as well? > > We should do this consistently at least within the Kconfig file. I think it is ideal if we can do that. But I won't change it in HI3519 soc patch. I will just use ARCH_HISI for HI3519 this time. > > Arnd > > . > -- 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 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12
On 2015년 12월 10일 14:57, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:08, Chanwoo Choi wrote:
>> This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
>> Exynos4x12 has the following AXI buses to translate data between
>> DRAM and sub-blocks.
>>
>> Following list specifies the detailed relation between DRAM and sub-blocks:
>> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
>> - ACLK160 clock for CAM/TV/LCD
>> : The minimum clock of ACLK160 should be over 160MHz.
>> When drop the clock under 160MHz, show the broken image.
>> - ACLK133 clock for FSYS
>> - GDL clock for LEFTBUS
>> - GDR clock for RIGHTBUS
>> - SCLK_MFC clock for MFC
>>
>> Signed-off-by: Chanwoo Choi
>> ---
>> arch/arm/boot/dts/exynos4x12.dtsi | 112
>> ++
>> 1 file changed, 112 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
>> b/arch/arm/boot/dts/exynos4x12.dtsi
>> index 3bcf0939755e..8bc4aee156b5 100644
>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>> @@ -354,6 +354,118 @@
>> opp-microvolt = <95>;
>> };
>> };
>> +
>> +bus_leftbus: bus_leftbus {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_DIV_GDL>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_rightbus: bus_rightbus {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_DIV_GDR>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>
> These two nodes are symmetrical. The MFC below and other buses in other
> DTS share opps. How about changing the binding so multiple clocks could
> be specified at once ("bus0", "bus1")? I think there is no need for a
> bus device for each clock.
The your commented method is possible.
But, I focus on implementing the generic bus frequency driver.
If specific bus device-tree node includes the one more clocks,
when adding the new Exynos SoC, the exynos-bus.c should be added
for new Exynos SoC. Because, each Exynos SoC has the different
set of bus device.
If we use my approach, we don't need to modify the exynos-bus.c
driver to support for the bus frequency of new Exynos SoC.
Best Regards,
Chanwoo Choi
>
> Best regards,
> Krzysztof
>
>> +
>> +bus_display: bus_display {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_ACLK160>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_display_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_fsys: bus_fsys {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_ACLK133>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_fsys_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_peri: bus_peri {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_ACLK100>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_peri_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_mfc: bus_mfc {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_SCLK_MFC>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_leftbus_opp_table: opp_table3 {
>> +compatible = "operating-points-v2";
>> +opp-shared;
>> +
>> +opp00 {
>> +opp-hz = /bits/ 64 <1>;
>> +opp-microvolt = <90>;
>> +};
>> +opp01 {
>> +opp-hz = /bits/ 64 <13400>;
>> +opp-microvolt = <925000>;
>> +};
>> +opp02 {
>> +opp-hz = /bits/ 64 <16000>;
>> +opp-microvolt = <95>;
>> +};
>> +opp03 {
>> +opp-hz = /bits/ 64 <2>;
>> +opp-microvolt = <100>;
>> +};
>> +};
>> +
>> +bus_display_opp_table: opp_table4 {
>> +compatible = "operating-points-v2";
>> +opp-shared;
>> +
>> +opp00 {
>> +opp-hz = /bits/ 64 <16000>;
>> +opp-microvolt = <95>;
>> +};
>> +opp01 {
>> +opp-hz = /bits/ 64 <2>;
>> +opp-microvolt = <100>;
>> +};
>> +};
>> +
>> +bus_fsys_opp_table: opp_table5 {
>> +compatible = "operating-points-v2";
>> +opp-shared;
>> +
>> +opp00 {
>> +opp-hz = /bits/ 64 <1>;
>> +opp-microvolt = <90>;
>> +};
>>
Re: [PATCH v9 7/7] PCI: hv: New paravirtual PCI front-end for Hyper-V VMs
Hi Jake,
[auto build test WARNING on pci/next]
[also build test WARNING on v4.4-rc4 next-20151209]
url:
https://github.com/0day-ci/linux/commits/jakeo-microsoft-com/PCI-hv-New-paravirtual-PCI-front-end-for-Hyper-V-VMs/20151210-070027
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: x86_64-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
include/linux/compiler.h:228:8: sparse: attribute 'no_sanitize_address':
unknown attribute
drivers/pci/host/hv_pcifront.c: In function 'hv_pci_allocate_bridge_windows':
>> drivers/pci/host/hv_pcifront.c:1776:18: warning: unused variable 'length'
>> [-Wunused-variable]
resource_size_t length;
^
vim +/length +1776 drivers/pci/host/hv_pcifront.c
1760 hbus->high_mmio_res->flags |= IORESOURCE_BUSY;
1761 release_mem_region(hbus->high_mmio_res->start,
1762 resource_size(hbus->high_mmio_res));
1763 }
1764 }
1765
1766 /**
1767 * hv_pci_allocate_bridge_windows() - Allocate memory regions
1768 * for the bus
1769 * @hbus: Root PCI bus, as understood by this driver
1770 *
1771 * Return: 0 on success, -errno on failure
1772 */
1773 static int hv_pci_allocate_bridge_windows(struct hv_pcibus_device *hbus)
1774 {
1775 resource_size_t align;
> 1776 resource_size_t length;
1777 int ret;
1778
1779 if (hbus->low_mmio_space) {
1780 align = 1ULL << (63 -
__builtin_clzll(hbus->low_mmio_space));
1781 ret = vmbus_allocate_mmio(>low_mmio_res,
hbus->hdev, 0,
1782 0xULL,
1783
(resource_size_t)hbus->low_mmio_space,
1784 align, false);
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH v2 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12
On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
> Exynos4x12 has the following AXI buses to translate data between
> DRAM and sub-blocks.
>
> Following list specifies the detailed relation between DRAM and sub-blocks:
> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
> - ACLK160 clock for CAM/TV/LCD
> : The minimum clock of ACLK160 should be over 160MHz.
> When drop the clock under 160MHz, show the broken image.
> - ACLK133 clock for FSYS
> - GDL clock for LEFTBUS
> - GDR clock for RIGHTBUS
> - SCLK_MFC clock for MFC
>
> Signed-off-by: Chanwoo Choi
> ---
> arch/arm/boot/dts/exynos4x12.dtsi | 112
> ++
> 1 file changed, 112 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
> b/arch/arm/boot/dts/exynos4x12.dtsi
> index 3bcf0939755e..8bc4aee156b5 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -354,6 +354,118 @@
> opp-microvolt = <95>;
> };
> };
> +
> + bus_leftbus: bus_leftbus {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_GDL>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_rightbus: bus_rightbus {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_GDR>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
These two nodes are symmetrical. The MFC below and other buses in other
DTS share opps. How about changing the binding so multiple clocks could
be specified at once ("bus0", "bus1")? I think there is no need for a
bus device for each clock.
Best regards,
Krzysztof
> +
> + bus_display: bus_display {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_ACLK160>;
> + clock-names = "bus";
> + operating-points-v2 = <_display_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_fsys: bus_fsys {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_ACLK133>;
> + clock-names = "bus";
> + operating-points-v2 = <_fsys_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_peri: bus_peri {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_ACLK100>;
> + clock-names = "bus";
> + operating-points-v2 = <_peri_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_mfc: bus_mfc {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_SCLK_MFC>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_leftbus_opp_table: opp_table3 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <90>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <13400>;
> + opp-microvolt = <925000>;
> + };
> + opp02 {
> + opp-hz = /bits/ 64 <16000>;
> + opp-microvolt = <95>;
> + };
> + opp03 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <100>;
> + };
> + };
> +
> + bus_display_opp_table: opp_table4 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <16000>;
> + opp-microvolt = <95>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <100>;
> + };
> + };
> +
> + bus_fsys_opp_table: opp_table5 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <90>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <13400>;
> + opp-microvolt = <925000>;
> + };
> + };
> +
> + bus_peri_opp_table: opp_table6 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <5000>;
> + opp-microvolt = <90>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <925000>;
> +
[PATCH 1/2] perf tests: Fix incorrect free and false TEST_OK result
Commit cc1121ab9687d660cc02f50b1a4974112f87a8e6 ('perf machine: Fix
machine.vmlinux_maps to make sure to clear the old one') reveals a bug
in 'perf test' that in all test cases which use setup_fake_machine()
incorrectly call free() when failure, because all users of
setup_fake_machine() use static allocated 'machines' structure, but
setup_fake_machine() calls machine__delete() which try to free() it.
If a normal user try those test cases this problem can be seen:
$ cat /proc/sys/kernel/kptr_restrict
1
$ ./perf test 'hist'
15: Test matching and linking multiple hists :*** Error in
`./perf': munmap_chunk(): invalid pointer: 0x7ffd6e900090 ***
=== Backtrace: =
/lib64/libc.so.6(+0x6eeef)[0x7fcec97e1eef]
/lib64/libc.so.6(+0x78cae)[0x7fcec97ebcae]
./perf(setup_fake_machine+0x1cd)[0x4721ad]
./perf(test__hists_link+0xbf)[0x472d3f]
./perf[0x4648df]
./perf(cmd_test+0x589)[0x464ec9]
./perf[0x47fd11]
./perf(main+0x5f6)[0x432b96]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7fcec9794bd5]
./perf[0x432cc5]
=== Memory map:
...
25: Test filtering hist entries :*** Error in
`./perf': munmap_chunk(): invalid pointer: 0x7ffd6e900080 ***
=== Backtrace: =
/lib64/libc.so.6(+0x6eeef)[0x7fcec97e1eef]
/lib64/libc.so.6(+0x78cae)[0x7fcec97ebcae]
./perf(setup_fake_machine+0x1cd)[0x4721ad]
./perf(test__hists_filter+0xc6)[0x4730f6]
./perf[0x4648df]
./perf(cmd_test+0x589)[0x464ec9]
./perf[0x47fd11]
./perf(main+0x5f6)[0x432b96]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7fcec9794bd5]
./perf[0x432cc5]
=== Memory map:
...
...
Actually, all users of 'machines__init()' should avoid calling
machine__delete(). We can further add a flag in machine structure to
enforce this restriction.
After changing machine__delete() to machine__exit() another problem
arises:
$ ./perf test 'hist'
15: Test matching and linking multiple hists : Ok
25: Test filtering hist entries : Ok
28: Test output sorting of hist entries : Ok
29: Test cumulation of child hist entries: Ok
The result is not true:
$ ./perf test -v 'hist'
15: Test matching and linking multiple hists :
--- start ---
test child forked, pid 17657
Not enough memory for machine setup
Not enough memory for machine setup
test child finished with 0
end
Test matching and linking multiple hists: Ok
25: Test filtering hist entries :
--- start ---
test child forked, pid 17658
Not enough memory for machine setup
Not enough memory for machine setup
test child finished with 0
end
Test filtering hist entries: Ok
28: Test output sorting of hist entries :
--- start ---
test child forked, pid 17659
Not enough memory for machine setup
Not enough memory for machine setup
test child finished with 0
end
Test output sorting of hist entries: Ok
29: Test cumulation of child hist entries:
--- start ---
test child forked, pid 17660
Not enough memory for machine setup
Not enough memory for machine setup
test child finished with 0
end
Test cumulation of child hist entries: Ok
Because the test body is not executed at all.
The reason is that *ALL* hists test cases forget to reset err after
using it to hold an error code:
err = TEST_FAIL;
...
err = parse_events(evlist, "cpu-clock", NULL);
if (err)
goto out;
/* err is already 0 here */
...
machine = setup_fake_machine();
if (!machine)
goto out;
...
out:
...
return err;
This patch ensure err is reset.
In case when kptr_restrict prevent normal user get kernel address, this
test should be skipped, not fail. This patch use linux/err.h to store
error code in return value of setup_fake_machine(), and let 'EACCES' to
indicate this problem.
Also, the debug message 'Not enough memory for machine setup' is not
true and should be fixed.
Here is the final result:
$ ./perf test 'hist'
15: Test matching and linking multiple hists : Skip
25: Test filtering hist entries : Skip
28: Test output sorting of hist entries : Skip
29: Test cumulation of child hist entries: Skip
$ ./perf test -v 'hist'
15: Test matching and linking multiple hists :
--- start ---
test child forked, pid 20177
Failed to create kernel maps
Hint: Check /proc/sys/kernel/kptr_restrict.
Failed for machine setup
test child finished with -2
end
Test matching and linking multiple hists: Skip
25: Test filtering hist entries
...
$ sudo ./perf test hist
15: Test matching and linking multiple hists : Ok
25: Test filtering hist entries : Ok
28: Test output sorting of hist entries : Ok
29: Test cumulation of child
Re: [PATCH] hexdump: Add ability to do endian conversions in print_hex_dump functions
Hi Joe,
[auto build test WARNING on v4.4-rc4]
[also build test WARNING on next-20151209]
url:
https://github.com/0day-ci/linux/commits/Joe-Perches/hexdump-Add-ability-to-do-endian-conversions-in-print_hex_dump-functions/20151210-060244
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
include/linux/compiler.h:228:8: sparse: attribute 'no_sanitize_address':
unknown attribute
include/linux/printk.h:430:24: sparse: undefined identifier 'BIT'
>> include/linux/printk.h:430:27: sparse: bad constant expression type
include/linux/printk.h:431:24: sparse: undefined identifier 'BIT'
include/linux/printk.h:431:27: sparse: bad constant expression type
In file included from lib/decompress.c:19:0:
include/linux/printk.h:430:17: error: implicit declaration of function 'BIT'
[-Werror=implicit-function-declaration]
DUMP_TYPE_LE = BIT(30),
^
include/linux/printk.h:430:2: error: enumerator value for 'DUMP_TYPE_LE' is
not an integer constant
DUMP_TYPE_LE = BIT(30),
^
include/linux/printk.h:432:1: error: enumerator value for 'DUMP_TYPE_BE' is
not an integer constant
};
^
cc1: some warnings being treated as errors
vim +430 include/linux/printk.h
414 printk_ratelimited(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
415 #else
416 #define pr_debug_ratelimited(fmt, ...) \
417 no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
418 #endif
419
420 extern const struct file_operations kmsg_fops;
421
422 enum {
423 DUMP_PREFIX_NONE,
424 DUMP_PREFIX_ADDRESS,
425 DUMP_PREFIX_OFFSET
426 };
427
428 enum {
429 DUMP_TYPE_CPU = 0,
> 430 DUMP_TYPE_LE = BIT(30),
431 DUMP_TYPE_BE = BIT(31)
432 };
433
434 extern int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
435int groupflags, char *linebuf, size_t
linebuflen,
436bool ascii);
437 #ifdef CONFIG_PRINTK
438 extern void print_hex_dump(const char *level, const char *prefix_str,
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
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] perf tools: Prevent calling machine__delete() on non-allocated machine
To prevent futher commits calling machine__delete() on non-allocated
'struct machine' (which would cause memory corruption), this patch
enforces machine__init(), record whether a machine structure is
dynamically allocated or not, and warn if machine__delete() is called
on incorrect object.
Signed-off-by: Wang Nan
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Masami Hiramatsu
Cc: Namhyung Kim
---
tools/perf/tests/vmlinux-kallsyms.c | 4 ++--
tools/perf/util/machine.c | 14 +-
tools/perf/util/machine.h | 3 ++-
3 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/tools/perf/tests/vmlinux-kallsyms.c
b/tools/perf/tests/vmlinux-kallsyms.c
index f0bfc9e..441e93d 100644
--- a/tools/perf/tests/vmlinux-kallsyms.c
+++ b/tools/perf/tests/vmlinux-kallsyms.c
@@ -35,8 +35,8 @@ int test__vmlinux_matches_kallsyms(int subtest __maybe_unused)
* Init the machines that will hold kernel, modules obtained from
* both vmlinux + .ko files and from /proc/kallsyms split by modules.
*/
- machine__init(, "", HOST_KERNEL_ID);
- machine__init(, "", HOST_KERNEL_ID);
+ machine__init(, "", HOST_KERNEL_ID, false);
+ machine__init(, "", HOST_KERNEL_ID, false);
/*
* Step 2:
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index f5882b8..a2b9b47 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -23,7 +23,7 @@ static void dsos__init(struct dsos *dsos)
pthread_rwlock_init(>lock, NULL);
}
-int machine__init(struct machine *machine, const char *root_dir, pid_t pid)
+int machine__init(struct machine *machine, const char *root_dir, pid_t pid,
bool allocated)
{
map_groups__init(>kmaps, machine);
RB_CLEAR_NODE(>rb_node);
@@ -64,6 +64,7 @@ int machine__init(struct machine *machine, const char
*root_dir, pid_t pid)
}
machine->current_tid = NULL;
+ machine->allocated = allocated;
return 0;
}
@@ -73,7 +74,7 @@ struct machine *machine__new_host(void)
struct machine *machine = malloc(sizeof(*machine));
if (machine != NULL) {
- machine__init(machine, "", HOST_KERNEL_ID);
+ machine__init(machine, "", HOST_KERNEL_ID, true);
if (machine__create_kernel_maps(machine) < 0)
goto out_delete;
@@ -136,12 +137,15 @@ void machine__exit(struct machine *machine)
void machine__delete(struct machine *machine)
{
machine__exit(machine);
- free(machine);
+ if (!machine->allocated)
+ free(machine);
+ else
+ pr_warning("WARNING: delete a non-allocated machine. Skip.\n");
}
void machines__init(struct machines *machines)
{
- machine__init(>host, "", HOST_KERNEL_ID);
+ machine__init(>host, "", HOST_KERNEL_ID, false);
machines->guests = RB_ROOT;
machines->symbol_filter = NULL;
}
@@ -162,7 +166,7 @@ struct machine *machines__add(struct machines *machines,
pid_t pid,
if (machine == NULL)
return NULL;
- if (machine__init(machine, root_dir, pid) != 0) {
+ if (machine__init(machine, root_dir, pid, true) != 0) {
free(machine);
return NULL;
}
diff --git a/tools/perf/util/machine.h b/tools/perf/util/machine.h
index 2c2b443..24dfd46 100644
--- a/tools/perf/util/machine.h
+++ b/tools/perf/util/machine.h
@@ -28,6 +28,7 @@ struct machine {
pid_t pid;
u16 id_hdr_size;
bool comm_exec;
+ bool allocated;
char *root_dir;
struct rb_rootthreads;
pthread_rwlock_t threads_lock;
@@ -131,7 +132,7 @@ void machines__set_symbol_filter(struct machines *machines,
void machines__set_comm_exec(struct machines *machines, bool comm_exec);
struct machine *machine__new_host(void);
-int machine__init(struct machine *machine, const char *root_dir, pid_t pid);
+int machine__init(struct machine *machine, const char *root_dir, pid_t pid,
bool allocated);
void machine__exit(struct machine *machine);
void machine__delete_threads(struct machine *machine);
void machine__delete(struct machine *machine);
--
1.8.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] spi-fsl-dspi: Fix CTAR Register access
DSPI instances in Vybrid have a different amount of chip selects
and CTARs (Clock and transfer Attributes Register). In case of
DSPI1 we only have 2 CTAR registers and 4 CS. In present driver
implementation CTAR offset is derived from CS instance which will
lead to out of bound access if chip select instance is greater than
CTAR register instance, hence use single CTAR0 register for all CS
instances. Since we write the CTAR register anyway before each access,
there is no value in using the additional CTAR registers. Also one
should not program a value in CTAS for a CTAR register that is not
present, hence configure CTAS to use CTAR0.
Signed-off-by: Bhuvanchandra DV
---
drivers/spi/spi-fsl-dspi.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 59a1143..39412c9 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -167,7 +167,7 @@ static inline int is_double_byte_mode(struct fsl_dspi *dspi)
{
unsigned int val;
- regmap_read(dspi->regmap, SPI_CTAR(dspi->cs), );
+ regmap_read(dspi->regmap, SPI_CTAR(0), );
return ((val & SPI_FRAME_BITS_MASK) == SPI_FRAME_BITS(8)) ? 0 : 1;
}
@@ -257,7 +257,7 @@ static u32 dspi_data_to_pushr(struct fsl_dspi *dspi, int
tx_word)
return SPI_PUSHR_TXDATA(d16) |
SPI_PUSHR_PCS(dspi->cs) |
- SPI_PUSHR_CTAS(dspi->cs) |
+ SPI_PUSHR_CTAS(0) |
SPI_PUSHR_CONT;
}
@@ -290,7 +290,7 @@ static int dspi_eoq_write(struct fsl_dspi *dspi)
*/
if (tx_word && (dspi->len == 1)) {
dspi->dataflags |= TRAN_STATE_WORD_ODD_NUM;
- regmap_update_bits(dspi->regmap, SPI_CTAR(dspi->cs),
+ regmap_update_bits(dspi->regmap, SPI_CTAR(0),
SPI_FRAME_BITS_MASK, SPI_FRAME_BITS(8));
tx_word = 0;
}
@@ -339,7 +339,7 @@ static int dspi_tcfq_write(struct fsl_dspi *dspi)
if (tx_word && (dspi->len == 1)) {
dspi->dataflags |= TRAN_STATE_WORD_ODD_NUM;
- regmap_update_bits(dspi->regmap, SPI_CTAR(dspi->cs),
+ regmap_update_bits(dspi->regmap, SPI_CTAR(0),
SPI_FRAME_BITS_MASK, SPI_FRAME_BITS(8));
tx_word = 0;
}
@@ -407,7 +407,7 @@ static int dspi_transfer_one_message(struct spi_master
*master,
regmap_update_bits(dspi->regmap, SPI_MCR,
SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF,
SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF);
- regmap_write(dspi->regmap, SPI_CTAR(dspi->cs),
+ regmap_write(dspi->regmap, SPI_CTAR(0),
dspi->cur_chip->ctar_val);
trans_mode = dspi->devtype_data->trans_mode;
@@ -566,7 +566,7 @@ static irqreturn_t dspi_interrupt(int irq, void *dev_id)
if (!dspi->len) {
if (dspi->dataflags & TRAN_STATE_WORD_ODD_NUM) {
regmap_update_bits(dspi->regmap,
- SPI_CTAR(dspi->cs),
+ SPI_CTAR(0),
SPI_FRAME_BITS_MASK,
SPI_FRAME_BITS(16));
dspi->dataflags &= ~TRAN_STATE_WORD_ODD_NUM;
--
2.6.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 3/3] arm: dts: rockchip: move the public part to rk3288-evb common
Rk3288-evb-act8846 and rk3288-evb-rk808 are the power boards of
rk3288-evb, they provide the same power supply interface to the
motherboard. Sort out them, put the public part to rk3288-evb.dtsi,
such as gmac and cpu-supply, leaving only the power section.
Signed-off-by: Chris Zhong
---
arch/arm/boot/dts/rk3288-evb-act8846.dts | 4
arch/arm/boot/dts/rk3288-evb-rk808.dts | 27 ---
arch/arm/boot/dts/rk3288-evb.dtsi| 37 +++-
3 files changed, 32 insertions(+), 36 deletions(-)
diff --git a/arch/arm/boot/dts/rk3288-evb-act8846.dts
b/arch/arm/boot/dts/rk3288-evb-act8846.dts
index 7b768b7..e662147 100644
--- a/arch/arm/boot/dts/rk3288-evb-act8846.dts
+++ b/arch/arm/boot/dts/rk3288-evb-act8846.dts
@@ -65,10 +65,6 @@
};
};
- {
- cpu0-supply = <_cpu>;
-};
-
{
clock-frequency = <40>;
diff --git a/arch/arm/boot/dts/rk3288-evb-rk808.dts
b/arch/arm/boot/dts/rk3288-evb-rk808.dts
index 18eb6cb..736b08b 100644
--- a/arch/arm/boot/dts/rk3288-evb-rk808.dts
+++ b/arch/arm/boot/dts/rk3288-evb-rk808.dts
@@ -43,17 +43,6 @@
/ {
compatible = "rockchip,rk3288-evb-rk808", "rockchip,rk3288";
-
- ext_gmac: external-gmac-clock {
- compatible = "fixed-clock";
- clock-frequency = <12500>;
- clock-output-names = "ext_gmac";
- #clock-cells = <0>;
- };
-};
-
- {
- cpu0-supply = <_cpu>;
};
{
@@ -244,19 +233,3 @@
};
};
};
-
- {
- phy-supply = <_phy>;
- phy-mode = "rgmii";
- clock_in_out = "input";
- snps,reset-gpio = < 7 0>;
- snps,reset-active-low;
- snps,reset-delays-us = <0 1 100>;
- assigned-clocks = < SCLK_MAC>;
- assigned-clock-parents = <_gmac>;
- pinctrl-names = "default";
- pinctrl-0 = <_pins>;
- tx_delay = <0x30>;
- rx_delay = <0x10>;
- status = "ok";
-};
diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi
b/arch/arm/boot/dts/rk3288-evb.dtsi
index f6d2e78..4faabdb 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -89,6 +89,13 @@
pwms = < 0 100 PWM_POLARITY_INVERTED>;
};
+ ext_gmac: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ clock-output-names = "ext_gmac";
+ #clock-cells = <0>;
+ };
+
gpio-keys {
compatible = "gpio-keys";
#address-cells = <1>;
@@ -160,6 +167,10 @@
};
};
+ {
+ cpu0-supply = <_cpu>;
+};
+
{
broken-cd;
bus-width = <8>;
@@ -172,11 +183,6 @@
status = "okay";
};
- {
- ddc-i2c-bus = <>;
- status = "okay";
-};
-
{
bus-width = <4>;
cap-mmc-highspeed;
@@ -191,6 +197,27 @@
vqmmc-supply = <_sd>;
};
+ {
+ phy-supply = <_phy>;
+ phy-mode = "rgmii";
+ clock_in_out = "input";
+ snps,reset-gpio = < 7 0>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 1 100>;
+ assigned-clocks = < SCLK_MAC>;
+ assigned-clock-parents = <_gmac>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ tx_delay = <0x30>;
+ rx_delay = <0x10>;
+ status = "ok";
+};
+
+ {
+ ddc-i2c-bus = <>;
+ status = "okay";
+};
+
{
status = "okay";
};
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/entry/64: Remove duplicate syscall table for fast path
On Wed, Dec 9, 2015 at 9:42 PM, Brian Gerst wrote: > On Wed, Dec 9, 2015 at 6:50 PM, Andy Lutomirski wrote: >> On Wed, Dec 9, 2015 at 1:15 PM, Andy Lutomirski wrote: >>> On Wed, Dec 9, 2015 at 1:08 PM, Brian Gerst wrote: Simplified version: ENTRY(stub_ptregs_64) cmpl $fast_path_return, (%rsp) >>> >>> Does that instruction actually work the way you want it to? (Does it >>> link?) I think you might need to use leaq the way I did in my patch. > > It should have been cmpq. leaq isn't necessary, since immediates are > sign-extended to 64-bit. Right, I always forget that they're sign-extended and not zero-extended. I folded that bit in to my queue. > jne 1f SAVE_EXTRA_REGS offset=8 call *%rax RESTORE_EXTRA_REGS offset=8 ret 1: jmp *%rax END(stub_ptregs_64) >>> >>> This'll work, I think, but I still think I prefer keeping as much >>> complexity as possible in the slow path. I could be convinced >>> otherwise, though -- this variant is reasonably clean. >> >> On further reflection, there's at least one functional difference. >> With my variant, modifying pt_regs from sys_foo/ptregs is safe. In >> your variant, it's unsafe unless force_iret() is called. I don't know >> whether we care. > > I can go either way at this point. My main concern was getting rid of > the duplicate table. Agreed. I'll sleep on it, and maybe someone else has some reason to prefer one approach over the other. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- 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 Dec 10
Hi all, Changes since 20151209: I applied a fix patch to the orangefs tree for a build failure exposed by the vfs tree. The vfs tree gained a build failure for which I applied a merge fix patch. The pm tree lost its build failure. The akpm-current tree gained a conflict against the net-next tree. I also removed 2 patches from the akpm-current tree that were causing boot failures. Non-merge commits (relative to Linus' tree): 4653 5406 files changed, 189062 insertions(+), 81353 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 231 trees (counting Linus' and 36 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (9a0f76fde9ad Merge tag 'for-linus-4.4-1' of git://git.code.sf.net/p/openipmi/linux-ipmi) Merging fixes/master (25cb62b76430 Linux 4.3-rc5) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (6d1a2adef782 ARC: [axs10x] cap ethernet phy to 100 Mbit/sec) Merging arm-current/fixes (f5e985580978 ARM: 8475/1: SWP emulation: Restore original *data when failed) Merging m68k-current/for-linus (21d380e54c30 m68k: Wire up mlock2) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (dc9c41bd9ece Revert "powerpc/eeh: Don't unfreeze PHB PE after reset") Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (2c302e7e4105 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc) Merging net/master (b0a8d1a0b6e5 net: ezchip: fix address space confusion in nps_enet.c) Merging ipsec/master (a8a572a6b5f2 xfrm: dst_entries_init() per-net dst_ops) Merging ipvs/master (8e662164abb4 netfilter: nfnetlink_queue: avoid harmless unnitialized variable warnings) Merging wireless-drivers/master (eeec5d0ef7ee rtlwifi: rtl8821ae: Fix lockups on boot) Merging mac80211/master (c1df932c0574 mac80211: fix off-channel mgmt-tx uninitialized variable usage) Merging sound-current/for-linus (5328e1ea87fb ALSA: hda/ca0132 - quirk for Alienware 17 2015) Merging pci-current/for-linus (5bd242f824e2 Revert "PCI: hisi: Add HiSilicon SoC Hip05 PCIe driver") Merging driver-core.current/driver-core-linus (31ade3b83e18 Linux 4.4-rc3) Merging tty.current/tty-linus (31ade3b83e18 Linux 4.4-rc3) Merging usb.current/usb-linus (73b39bb0a0fe Merge tag 'fixes-for-v4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus) Merging usb-gadget-fixes/fixes (7d32cdef5356 usb: musb: fail with error when no DMA controller set) Merging usb-serial-fixes/usb-linus (a0e80fbd56b4 USB: serial: Another Infineon flash loader USB ID) Merging usb-chipidea-fixes/ci-for-usb-stable (6f51bc340d2a usb: chipidea: imx: fix a possible NULL dereference) Merging staging.current/staging-linus (9225c0b7b976 staging: lustre: echo_copy.._lsm() dereferences userland pointers directly) Merging char-misc.current/char-misc-linus (e8c77bda05e5 fpga manager: Fix firmware resource leak on error) Merging input-current/for-linus (1cf44efa1e4f Input: arizona-haptic - fix disabling of haptics device) Merging crypto-current/master (70d906bc1750 crypto: skcipher - Copy iv from desc even for 0-len walks) Merging ide/master (1b1050cdc5cd Merge git://git.kernel.org/pub
[PATCH 1/3] ARM: dts: rockchip: correct the name of REG8 for rk3288-evb-act8846
According to the schematic, the name of REG8 should be vcc_tp, rather
than vcca_tp.
Signed-off-by: Chris Zhong
---
arch/arm/boot/dts/rk3288-evb-act8846.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3288-evb-act8846.dts
b/arch/arm/boot/dts/rk3288-evb-act8846.dts
index 43949a6..53d8b08 100644
--- a/arch/arm/boot/dts/rk3288-evb-act8846.dts
+++ b/arch/arm/boot/dts/rk3288-evb-act8846.dts
@@ -152,7 +152,7 @@
regulator-always-on;
};
- vcca_tp: REG8 {
+ vcc_tp: REG8 {
regulator-name = "VCCA_TP";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] ARM: dts: rockchip: add 2 regulators for rk3288-evb-act8846
vcc_wl and vcc_lcd are 2 gpio switches for rk3288-evb-act8846 board.
Signed-off-by: Chris Zhong
---
arch/arm/boot/dts/rk3288-evb-act8846.dts | 34
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-evb-act8846.dts
b/arch/arm/boot/dts/rk3288-evb-act8846.dts
index 53d8b08..7b768b7 100644
--- a/arch/arm/boot/dts/rk3288-evb-act8846.dts
+++ b/arch/arm/boot/dts/rk3288-evb-act8846.dts
@@ -43,6 +43,26 @@
/ {
compatible = "rockchip,rk3288-evb-act8846", "rockchip,rk3288";
+
+ vcc_lcd: vcc-lcd {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = < 3 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_en>;
+ regulator-name = "vcc_lcd";
+ vin-supply = <_io>;
+ };
+
+ vcc_wl: vcc-wl {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = < 9 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pwr>;
+ regulator-name = "vcc_wl";
+ vin-supply = <_18>;
+ };
};
{
@@ -189,3 +209,17 @@
};
};
};
+
+ {
+ lcd {
+ lcd_en: lcd-en {
+ rockchip,pins = <7 3 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+
+ wifi {
+ wifi_pwr: wifi-pwr {
+ rockchip,pins = <7 9 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+};
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/entry/64: Remove duplicate syscall table for fast path
On Wed, Dec 9, 2015 at 6:50 PM, Andy Lutomirski wrote: > On Wed, Dec 9, 2015 at 1:15 PM, Andy Lutomirski wrote: >> On Wed, Dec 9, 2015 at 1:08 PM, Brian Gerst wrote: >>> Simplified version: >>> ENTRY(stub_ptregs_64) >>> cmpl $fast_path_return, (%rsp) >> >> Does that instruction actually work the way you want it to? (Does it >> link?) I think you might need to use leaq the way I did in my patch. It should have been cmpq. leaq isn't necessary, since immediates are sign-extended to 64-bit. >>> jne 1f >>> SAVE_EXTRA_REGS offset=8 >>> call *%rax >>> RESTORE_EXTRA_REGS offset=8 >>> ret >>> 1: >>> jmp *%rax >>> END(stub_ptregs_64) >> >> This'll work, I think, but I still think I prefer keeping as much >> complexity as possible in the slow path. I could be convinced >> otherwise, though -- this variant is reasonably clean. > > On further reflection, there's at least one functional difference. > With my variant, modifying pt_regs from sys_foo/ptregs is safe. In > your variant, it's unsafe unless force_iret() is called. I don't know > whether we care. I can go either way at this point. My main concern was getting rid of the duplicate table. -- Brian Gerst -- 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 2/2] mm: Introduce kernelcore=mirror option
Dear Tony, Xishi, > >> How about add some comment, if mirrored memroy is too small, then the > >> normal zone is small, so it may be oom. > >> The mirrored memory is at least 1/64 of whole memory, because struct > >> pages usually take 64 bytes per page. > > > > 1/64th is the absolute lower bound (for the page structures as you say). I > > expect people will need to configure 10% or more to run any real workloads. > > > > I made the memblock boot time allocator fall back to non-mirrored memory > > if mirrored memory ran out. What happens in the run time allocator if the > > non-movable zones run out of pages? Will we allocate kernel pages from > > movable > > memory? > > > > As I know, the kernel pages will not allocated from movable zone. Yes, kernel pages are not allocated from ZONE_MOVABLE. In this case administrator must review and reconfigure the mirror ratio via "MirrorRequest" EFI variable. Sincerely, Taku Izumi > > > -- > > 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/
[PATCHv2] ARM: dts: kirkwood: Add DTS for Zyxel NSA325
Add a new DTS file to support the Zyxel NSA325(v2) dual bay
NAS device, based on the NSA320 DTS files.
The only difference to the NSA320 device is GPIO47.
This en/disables the power for the hdd in slot2, currently
fixed to on.
Signed-off-by: Hans Ulli Kroll
---
v2
- using kirkwood-nsa325.dts as template, this removes the odd
indentation and unneeded partitions nodes.
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/kirkwood-nsa325.dts | 236 ++
2 files changed, 237 insertions(+)
create mode 100644 arch/arm/boot/dts/kirkwood-nsa325.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index bb8fa02..0fcae90 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -193,6 +193,7 @@ dtb-$(CONFIG_MACH_KIRKWOOD) += \
kirkwood-ns2mini.dtb \
kirkwood-nsa310.dtb \
kirkwood-nsa310a.dtb \
+ kirkwood-nsa325.dtb \
kirkwood-openblocks_a6.dtb \
kirkwood-openblocks_a7.dtb \
kirkwood-openrd-base.dtb \
diff --git a/arch/arm/boot/dts/kirkwood-nsa325.dts
b/arch/arm/boot/dts/kirkwood-nsa325.dts
new file mode 100644
index 000..6e9ffb5
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-nsa325.dts
@@ -0,0 +1,236 @@
+/* Device tree file for the Zyxel NSA 325 NAS box.
+ *
+ * Copyright (c) 2015, Hans Ulli Kroll
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Based upon the board setup file created by Peter Schildmann */
+
+/dts-v1/;
+
+#include "kirkwood-nsa3x0-common.dtsi"
+
+/ {
+ model = "ZyXEL NSA325";
+ compatible = "zyxel,nsa325", "marvell,kirkwood-88f6282",
"marvell,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x2000>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ stdout-path =
+ };
+
+ mbus {
+ pcie-controller {
+ status = "okay";
+
+ pcie@1,0 {
+ status = "okay";
+ };
+ };
+ };
+
+ ocp@f100 {
+ pinctrl: pin-controller@1 {
+ pinctrl-names = "default";
+
+ pmx_led_hdd2_green: pmx-led-hdd2-green {
+ marvell,pins = "mpp12";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_hdd2_red: pmx-led-hdd2-red {
+ marvell,pins = "mpp13";
+ marvell,function = "gpio";
+ };
+
+ pmx_mcu_data: pmx-mcu-data {
+ marvell,pins = "mpp14";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_usb_green: pmx-led-usb-green {
+ marvell,pins = "mpp15";
+ marvell,function = "gpio";
+ };
+
+ pmx_mcu_clk: pmx-mcu-clk {
+ marvell,pins = "mpp16";
+ marvell,function = "gpio";
+ };
+
+ pmx_mcu_act: pmx-mcu-act {
+ marvell,pins = "mpp17";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_sys_green: pmx-led-sys-green {
+ marvell,pins = "mpp28";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_sys_orange: pmx-led-sys-orange {
+ marvell,pins = "mpp29";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_hdd1_green: pmx-led-hdd1-green {
+ marvell,pins = "mpp41";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_hdd1_red: pmx-led-hdd1-red {
+ marvell,pins = "mpp42";
+ marvell,function = "gpio";
+ };
+
+ pmx_htp: pmx-htp {
+ marvell,pins = "mpp43";
+ marvell,function = "gpio";
+ };
+
+ /* Buzzer needs to be switched at around 1kHz so is
+ not compatible with the gpio-beeper driver. */
+ pmx_buzzer: pmx-buzzer {
+ marvell,pins = "mpp44";
+ marvell,function = "gpio";
Re: [PATCH v4 4/5] ARM: dts: DRA7: add entry for qspi mmap region
On 12/03/2015 03:51 PM, Vignesh R wrote:
>
>
> On 12/01/2015 10:09 PM, Tony Lindgren wrote:
>> * Vignesh R [151130 20:46]:
>>> On 12/01/2015 04:04 AM, Tony Lindgren wrote:
...
>>
>> OK. They are both on L3 main so that won't cause any issues for separate
>> interconnect driver instances. As they are still separate targets flushing
>> a posted write to one area will not flush anything to the other.
>>
>
> I didn't quite understand what you meant by interconnect driver instance.
> qspi_base and qspi_mmap region are tightly bound to each other and both
> needs to be accessed by ti-qspi driver (though different targets).
> Besides qspi_mmap region is only used to read data, there will not be
> any write accesses to this target. Are you saying this binding is not
> viable?
>
As I stated above qspi_base and qspi_mmap region are tightly bound,
there is no way to use qspi_mmap region w/o accessing qspi_base. So I am
planning to keep them as it is. I will move qspi_ctrlmod to use syscon.
Something like:
qspi: qspi@4b30 {
compatible = "ti,dra7xxx-qspi";
reg = <0x4b30 0x100>,
<0x5c00 0x400>,
reg-names = "qspi_base", "qspi_mmap";
syscon-chipselects = <_conf 0x558>;
#address-cells = <1>;
#size-cells = <0>;
spi-max-frequency = <4800>;
ti,hwmods = "qspi";
};
Do you think this is not viable in future?
--
Regards
Vignesh
--
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 0/8 v4] enable to use thermal-zone on r8a7790/1
On Tue, Dec 08, 2015 at 05:26:20AM +, Kuninori Morimoto wrote: > > Hi > > These are v4 of thermal-zone support for r8a7790/r8a7791. > Mainly, it cares return value of get_temp() > > I think 8) is needed on of-thermal (?) > > Kuninori Morimoto (8): > 1) thermal: rcar: move rcar_thermal_dt_ids to upside > 2) thermal: rcar: check every rcar_thermal_update_temp() return value > 3) thermal: rcar: check irq possibility in rcar_thermal_irq_xxx() > 4) thermal: rcar: retern error rcar_thermal_get_temp() if no ctemp > update > 5) thermal: rcar: enable to use thermal-zone on DT > 6) ARM: shmobile: r8a7790: enable to use thermal-zone > 7) ARM: shmobile: r8a7791: enable to use thermal-zone > 8) thermal: of-thermal: of_thermal_set_trip_temp() call > thermal_zone_device_update() > I have marked patches 6 and 7 as deferred pending acceptance of the driver changes. -- 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] module: check vermagic match exactly when load modules
Xie XiuQi writes:
> Usually, checking kernel version will be ignore when loading
> modules if CONFIG_MODVERSIONS option is enable. This could
> potentially lead to a mismatch with the running kernel.
>
> With this option, we prevent to load the modules which vermagic
> is not match exactly with the running kernel.
>
> It could be set to N by default.
Hi Xie!
I don't understand this patch. The purpose of
CONFIG_MODVERSIONS is so that you can combine modules from different
kernel versions. If you don't want to do that, I suggest not setting
CONFIG_MODVERSIONS.
Cheers,
Rusty.
>
> Signed-off-by: Xie XiuQi
> ---
> init/Kconfig| 11 +++
> kernel/module.c | 2 ++
> 2 files changed, 13 insertions(+)
>
> diff --git a/init/Kconfig b/init/Kconfig
> index c24b6f7..ce9c23e 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1889,6 +1889,17 @@ config MODVERSIONS
> make them incompatible with the kernel you are running. If
> unsure, say N.
>
> +config MODULE_VERMAGIC_FORCE
> + bool "Require vermagic match exactly"
> + default n
> + depends on MODVERSIONS
> + help
> + Usually, checking kernel version will be ignore when loading
> + modules if CONFIG_MODVERSIONS option is enable. This could
> + potentially lead to a mismatch with the running kernel.
> + With this option, we prevent to load the modules which vermagic
> + is not match exactly with the running kernel. If unsure, say N.
> +
> config MODULE_SRCVERSION_ALL
> bool "Source checksum for all modules"
> help
> diff --git a/kernel/module.c b/kernel/module.c
> index 8f051a1..cf350d5 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -1350,10 +1350,12 @@ static inline int check_modstruct_version(Elf_Shdr
> *sechdrs,
> static inline int same_magic(const char *amagic, const char *bmagic,
>bool has_crcs)
> {
> +#ifndef CONFIG_MODULE_VERMAGIC_FORCE
> if (has_crcs) {
> amagic += strcspn(amagic, " ");
> bmagic += strcspn(bmagic, " ");
> }
> +#endif
> return strcmp(amagic, bmagic) == 0;
> }
> #else
> --
> 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/
--
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 akpm-current tree with the net-next tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
include/net/sock.h
between commits:
297dbde19cf6 ("netprio_cgroup: limit the maximum css->id to USHRT_MAX")
2a56a1fec290 ("net: wrap sock->sk_cgrp_prioidx and ->sk_classid inside a
struct")
from the net-next tree and commit:
c4b672bd7b34 ("net: tcp_memcontrol: simplify linkage between socket and page
counter")
from the akpm-current 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 include/net/sock.h
index c57e7ce0d097,edd552ef8e38..
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@@ -309,8 -292,8 +293,8 @@@ struct cg_proto
* @sk_send_head: front of stuff to transmit
* @sk_security: used by security modules
* @sk_mark: generic packet mark
- * @sk_classid: this socket's cgroup classid
+ * @sk_cgrp_data: cgroup data for this cgroup
- * @sk_cgrp: this socket's cgroup-specific proto data
+ * @sk_memcg: this socket's memory cgroup association
* @sk_write_pending: a write to stream socket waits to start
* @sk_state_change: callback to indicate change in the state of the sock
* @sk_data_ready: callback to indicate there is data to be processed
@@@ -443,8 -428,11 +427,8 @@@ struct sock
#ifdef CONFIG_SECURITY
void*sk_security;
#endif
- __u32 sk_mark;
-#ifdef CONFIG_CGROUP_NET_CLASSID
- u32 sk_classid;
-#endif
+ struct sock_cgroup_data sk_cgrp_data;
- struct cg_proto *sk_cgrp;
+ struct mem_cgroup *sk_memcg;
void(*sk_state_change)(struct sock *sk);
void(*sk_data_ready)(struct sock *sk);
void(*sk_write_space)(struct sock *sk);
--
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 perf/core 00/22] perf refcnt debugger API and fixes
Hi Arnaldo and Masami,
On Wed, Dec 09, 2015 at 10:41:38AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Dec 09, 2015 at 11:10:48AM +0900, Masami Hiramatsu escreveu:
> > In this series I've also tried to fix some object leaks in perf top
> > and perf stat.
> > After applying this series, this reduced (not vanished) to 1/5.
> >
> > # ./perf top --stdio
> > q
> > exiting.
> > REFCNT: BUG: Unreclaimed objects found.
> > REFCNT: Total 866 objects are not reclaimed.
> > "dso" leaks 213 objects
> > "map" leaks 624 objects
> > "comm_str" leaks 12 objects
> > "thread" leaks 9 objects
> > "map_groups" leaks 8 objects
> > To see all backtraces, rerun with -v option
> >
> >
> > Actually, I'm still not able to fix all of the bugs. It seems that
> > hists has a bug that hists__delete_entries doesn't delete all the
> > entries because some entries are on hists->entries but others on
> > hists->entries_in. And I'm not so sure about hists.c.
> > Arnaldo, would you have any idea for this bug?
>
> I'll will audit the hists code, its all about collecting new entries
> into an rbtree to then move the last batch for merging with the
> previous, decayed ones while continuing to process a new batch in
> another thread.
Right. After processing is done, hist entries are in both of
hists->entries and hists->entries_in (or hists->entries_collapsed).
So I guess perf report does not have leaks on hists.
But for perf top, it's possible to have half-processed entries which
are only in hists->entries_in. Eventually they will go to the
hists->entries and get freed but they cannot be deleted by current
hists__delete_entries(). If we really care deleting all of those
half-processed entries, how about this?
Thanks,
Namhyung
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index fd179a068df7..08396a7fea23 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -270,6 +270,8 @@ static void hists__delete_entry(struct hists *hists, struct
hist_entry *he)
if (sort__need_collapse)
rb_erase(>rb_node_in, >entries_collapsed);
+ else
+ rb_erase(>rb_node_in, hists->entries_in);
--hists->nr_entries;
if (!he->filtered)
@@ -1589,11 +1591,33 @@ int __hists__init(struct hists *hists)
return 0;
}
+static void hists__delete_remaining_entries(struct rb_root *root)
+{
+ struct rb_node *node;
+ struct hist_entry *he;
+
+ while (!RB_EMPTY_ROOT(root)) {
+ node = rb_first(root);
+ rb_erase(node, root);
+
+ he = rb_entry(node, struct hist_entry, rb_node_in);
+ hist_entry__delete(he);
+ }
+}
+
+static void hists__delete_all_entries(struct hists *hists)
+{
+ hists__delete_entries(hists);
+ hists__delete_remaining_entries(>entries_in_array[0]);
+ hists__delete_remaining_entries(>entries_in_array[1]);
+ hists__delete_remaining_entries(>entries_collapsed);
+}
+
static void hists_evsel__exit(struct perf_evsel *evsel)
{
struct hists *hists = evsel__hists(evsel);
- hists__delete_entries(hists);
+ hists__delete_all_entries(hists);
}
static int hists_evsel__init(struct perf_evsel *evsel)
--
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 0/3] reduce latency of direct async compaction
On Wed, Dec 09, 2015 at 01:40:06PM +0800, Aaron Lu wrote:
> On Wed, Dec 09, 2015 at 09:33:53AM +0900, Joonsoo Kim wrote:
> > On Tue, Dec 08, 2015 at 04:52:42PM +0800, Aaron Lu wrote:
> > > On Tue, Dec 08, 2015 at 03:51:16PM +0900, Joonsoo Kim wrote:
> > > > I add work-around for this problem at isolate_freepages(). Please test
> > > > following one.
> > >
> > > Still no luck and the error is about the same:
> >
> > There is a mistake... Could you insert () for
> > cc->free_pfn & ~(pageblock_nr_pages-1) like as following?
> >
> > cc->free_pfn == (cc->free_pfn & ~(pageblock_nr_pages-1))
>
> Oh right, of course.
>
> Good news, the result is much better now:
> $ cat {0..8}/swap
> cmdline: /lkp/aaron/src/bin/usemem 100064603136
> 100064603136 transferred in 72 seconds, throughput: 1325 MB/s
> cmdline: /lkp/aaron/src/bin/usemem 100072049664
> 100072049664 transferred in 74 seconds, throughput: 1289 MB/s
> cmdline: /lkp/aaron/src/bin/usemem 100070246400
> 100070246400 transferred in 92 seconds, throughput: 1037 MB/s
> cmdline: /lkp/aaron/src/bin/usemem 100069545984
> 100069545984 transferred in 81 seconds, throughput: 1178 MB/s
> cmdline: /lkp/aaron/src/bin/usemem 100058895360
> 100058895360 transferred in 78 seconds, throughput: 1223 MB/s
> cmdline: /lkp/aaron/src/bin/usemem 100066074624
> 100066074624 transferred in 94 seconds, throughput: 1015 MB/s
> cmdline: /lkp/aaron/src/bin/usemem 100062855168
> 100062855168 transferred in 77 seconds, throughput: 1239 MB/s
> cmdline: /lkp/aaron/src/bin/usemem 100060990464
> 100060990464 transferred in 73 seconds, throughput: 1307 MB/s
> cmdline: /lkp/aaron/src/bin/usemem 100064996352
> 100064996352 transferred in 84 seconds, throughput: 1136 MB/s
> Max: 1325 MB/s
> Min: 1015 MB/s
> Avg: 1194 MB/s
Nice result! Thanks for testing.
I will make a proper formatted patch soon.
Then, your concern is solved? I think that performance of
always-always on this test case can't follow up performance of
always-never because migration cost to make hugepage is additionally
charged to always-always case. Instead, it will have more hugepage
mapping and it may result in better performance in some situation.
I guess that it is intention of that option.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] mm, printk: introduce new format string for flags
On Wed, Dec 09, 2015 at 11:04:56PM -0500, Steven Rostedt wrote:
> On Thu, Dec 10, 2015 at 11:59:44AM +0900, Joonsoo Kim wrote:
> > Ccing, Steven to ask trace-cmd problem.
>
> Thanks, I should have been Cc'd for the rest as well.
>
> >
> > On Fri, Dec 04, 2015 at 04:16:33PM +0100, Vlastimil Babka wrote:
> > > In mm we use several kinds of flags bitfields that are sometimes printed
> > > for
> > > debugging purposes, or exported to userspace via sysfs. To make them
> > > easier to
> > > interpret independently on kernel version and config, we want to dump
> > > also the
> > > symbolic flag names. So far this has been done with repeated calls to
> > > pr_cont(), which is unreliable on SMP, and not usable for e.g. sysfs
> > > export.
> > >
> > > To get a more reliable and universal solution, this patch extends printk()
> > > format string for pointers to handle the page flags (%pgp), gfp_flags
> > > (%pgg)
> > > and vma flags (%pgv). Existing users of dump_flag_names() are converted
> > > and
> > > simplified.
> > >
> > > It would be possible to pass flags by value instead of pointer, but the %p
> > > format string for pointers already has extensions for various kernel
> > > structures, so it's a good fit, and the extra indirection in a
> > > non-critical
> > > path is negligible.
> >
> > I'd like to use %pgp in tracepoint output. It works well when I do
> > 'cat /sys/kernel/debug/tracing/trace' but not works well when I do
> > './trace-cmd report'. It prints following error log.
> >
> > [page_ref:page_ref_unfreeze] bad op token &
> > [page_ref:page_ref_set] bad op token &
> > [page_ref:page_ref_mod_unless] bad op token &
> > [page_ref:page_ref_mod_and_test] bad op token &
> > [page_ref:page_ref_mod_and_return] bad op token &
> > [page_ref:page_ref_mod] bad op token &
> > [page_ref:page_ref_freeze] bad op token &
> >
> > Following is the format I used.
> >
> > TP_printk("pfn=0x%lx flags=%pgp count=%d mapcount=%d mapping=%p mt=%d
> > val=%d ret=%d",
> > __entry->pfn, &__entry->flags, __entry->count,
> > __entry->mapcount, __entry->mapping, __entry->mt,
> > __entry->val, __entry->ret)
> >
> > Could it be solved by 'trace-cmd' itself?
> > Or it's better to pass flags by value?
> > Or should I use something like show_gfp_flags()?
>
> Yes this can be solved in perf and trace-cmd via the parse-events.c file. And
> as soon as that happens, whatever method we decide upon becomes a userspace
> ABI. So don't think you can change it later.
Okay. Because it can be solved by perf and trace-cmd via the
parse-events.c, I have no preference whether it is passed by value or
not.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] spi-fsl-dspi: Fix CTAR Register access
On 12/10/2015 02:11 AM, Mark Brown wrote: On Wed, Dec 09, 2015 at 11:51:39AM +0530, Bhuvanchandra DV wrote: DSPI instances in Vybrid have a different amount of chip selects and CTARs (Clock and transfer Attributes Register). In case of DSPI1 we only have 2 CTAR registers and 4 CS. In present driver This doesn't apply against, current code - please check and resend. Will check and resend. -- Best regards, Bhuvan -- 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: [Resend: PATCH v2 0/3] Fix rcar-pcie for arm64
On Wed, Dec 09, 2015 at 10:59:54AM -0600, Bjorn Helgaas wrote:
> On Thu, Nov 26, 2015 at 08:32:43AM +, Phil Edworthy wrote:
> > HI Bjorn,
> >
> > On 25 November 2015 16:41, Bjorn Helgaas wrote:
> > > Hi Phil,
> > >
> > > On Wed, Nov 25, 2015 at 03:30:36PM +, Phil Edworthy wrote:
> > > > The first patches fixes the build problem
> > >
> > > I'm trying to figure out if v4.4 has a build problem we need to fix.
> > > If I understand correctly, "PCI: rcar: Convert to DT resource parsing
> > > API" doesn't fix a build problem in the current tree; rather, it
> > > removes a dependency on ARM so that we can build it on ARM64.
> > v4.4 doesn't have a build problem because commit 7c537c67d2e4 ensures
> > it doesn't get built on arm64. If we revert this commit, then there is a
> > build failure as the pci_ioremap_io() function is not available on arm64.
> > That's the build failure which "PCI: rcar: Convert to DT resource parsing
> > API"
> > fixes.
> >
> > > > , and the second patch reverts the
> > > > patch that removed the driver from arm64 builds. The final patch add a
> > > > compat
> > > > string for the r8a7795 (arm64) device.
> > > >
> > > > Tested on arm Koelsch board, all ok.
> > > >
> > > > Tested on arm64 Salvator-X board using
> > > > renesas-drivers-2015-10-27-v4.3-rc7
> > > from
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> > > > with
> > > PCI
> > > > next merged.
> > > > Apart from patches to add the PCIe clock and DT nodes, it also needs
> > > > this fix:
> > > > ("PCI: MSI: Only use the generic MSI layer when domain is hierarchical")
> > >
> > > I assume you mean this one from Marc: https://lkml.org/lkml/2015/11/23/388
> > > (Was that posted to linux-pci? I don't see it in patchwork or my
> > > linux-pci archives, so I hadn't seen it yet.)
> > Ok, yes that's the patch.
> >
> > > How exactly is that related to this series? If I merge these before
> > > Marc's change, do we have a tree that builds for arm64 but doesn't
> > > work?
> > Correct.
>
> OK, great! I just asked Linus to pull that patch (3845d2953aac ("PCI/MSI:
> Only use the generic MSI layer when domain is hierarchical")) for v4.4, so
> these changes will be merged after that one.
>
> I put all three of these on pci/host-rcar for v4.5.
>
> Simon, I only see your explicit ack on the first one, but I assume you're
> OK with all three. Let me know if otherwise.
Sorry for not being clearer: I'm ok with these changes.
--
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 13/19] ARM: dts: Add bus nodes using VDD_MIF for Exynos4x12
On 2015년 12월 10일 12:17, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:08, Chanwoo Choi wrote:
>> This patch adds the bus noes using VDD_MIF for Exynos4x12 SoC.
>
> s/noes/nodes/
OK.
>
>> Exynos4x12 has the following AXI buses to translate data
>> between DRAM and DMC/ACP/C2C.
>>
>> Signed-off-by: Chanwoo Choi
>> ---
>> arch/arm/boot/dts/exynos4x12.dtsi | 72
>> +++
>> 1 file changed, 72 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
>> b/arch/arm/boot/dts/exynos4x12.dtsi
>> index b77dac61ffb5..3bcf0939755e 100644
>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>> @@ -282,6 +282,78 @@
>> clocks = < CLK_SMMU_LITE1>, < CLK_FIMC_LITE1>;
>> #iommu-cells = <0>;
>> };
>> +
>> +bus_dmc: bus_dmc {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_DIV_DMC>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_dmc_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_acp: bus_acp {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_DIV_ACP>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_acp_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_c2c: bus_c2c {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_DIV_C2C>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_dmc_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_dmc_opp_table: opp_table1 {
>> +compatible = "operating-points-v2";
>> +opp-shared;
>> +
>> +opp00 {
>> +opp-hz = /bits/ 64 <1>;
>> +opp-microvolt = <90>;
>> +};
>> +opp01 {
>> +opp-hz = /bits/ 64 <13400>;
>> +opp-microvolt = <90>;
>> +};
>> +opp02 {
>> +opp-hz = /bits/ 64 <16000>;
>> +opp-microvolt = <90>;
>> +};
>> +opp03 {
>> +opp-hz = /bits/ 64 <2>;
>> +opp-microvolt = <95>;
>
> The exyno4_bus.c (from mainline) uses 267 MHz here. Why choosing 200 MHz?
There is no special reason.
I'll change it (200MHz -> 267MHz).
Best Regards,
Chanwoo Choi
--
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 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor
Hi Anand,
On 2015년 12월 10일 13:14, Anand Moon wrote:
> Hi Chanwoo Choi,
>
> On 10 December 2015 at 05:42, Chanwoo Choi wrote:
>> Hi Anand,
>>
>> First of all, thanks for trying to test this series.
>>
>> On 2015년 12월 10일 04:05, Anand Moon wrote:
>>> Hi Chanwoo Choi,
>>>
>>> On 9 December 2015 at 09:37, Chanwoo Choi wrote:
This patch-set includes the two features as following. The generic exynos
bus
frequency driver is able to support almost Exynos SoCs for bus frequency
scaling. And the new passive governor is able to make the dependency on
between devices for frequency/voltage scaling. I had posted the
patch-set[1]
with the similiar concept. This is is revised version for exynos bus
frequency.
- Generic exynos bus frequency driver
- New passive governor of DEVFREQ framework
Depends on:
- This patch-set is based on devfreq.git[2].
[1] https://lkml.org/lkml/2015/1/7/872
: [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver
[2] https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/ (branch:
for-rafael)
Changes from v1:
(https://lkml.org/lkml/2015/11/26/260)
- Check whether the instance of regulator is NULL or not
when executing regulator_disable() because of only parent
devfreq device has the regulator instance. After fixing it,
the wake-up from suspend state is well working. (patch1)
- Fix bug which checks 'bus-clk' instead of 'bus->regulator'
after calling devm_clk_get() (on patch1)
- Update the documentation to remove the description about
DEVFREQ-EVENT subsystem (on patch2)
- Add the full name of DMC (Dynamic Memory Controller) (on patch2)
- Modify the detailed correlation of buses for Exynos3250
on documentation (patch2)
- Add the MFC bus node for Exynos3250 (on patch11, patch12)
- Fix the duplicate frequency of bus_display on Exynos4x12.dtsi
- Add the PPMU node for exynos4412-odroidu3
- Add the support of bus frequency for exynos4412-odroidu3
Detailed descirption for patch-set:
1. Add generic exynos bus frequency driver
: This patch-set adds the generic exynos bus frequency driver for AXI bus
of sub-blocks in exynos SoC. The Samsung Exynos SoC have the common
architecture for bus between DRAM and sub-blocks in SoC.
There are the different buses according to Exynos SoC because Exynos SoC
has the differnt sub-blocks and bus speed. In spite of this difference
among Exynos SoCs, this driver is able to support almost Exynos SoC by
adding
unique data of each bus in the devicetree file.
In devicetree, each bus node has a bus clock, regulator, operation-point
and devfreq-event devices which measure the utilization of each bus block.
For example,
- The bus of DMC block in exynos3250.dtsi are listed below:
bus_dmc: bus_dmc {
compatible = "samsung,exynos-bus";
clocks = <_dmc CLK_DIV_DMC>;
clock-names = "bus";
operating-points-v2 = <_dmc_opp_table>;
status = "disabled";
};
bus_dmc_opp_table: opp_table0 {
compatible = "operating-points-v2";
opp-shared;
opp00 {
opp-hz = /bits/ 64 <5000>;
opp-microvolt = <80>;
};
opp01 {
opp-hz = /bits/ 64 <1>;
opp-microvolt = <80>;
};
opp02 {
opp-hz = /bits/ 64 <13400>;
opp-microvolt = <80>;
};
opp03 {
opp-hz = /bits/ 64 <2>;
opp-microvolt = <80>;
};
opp04 {
opp-hz = /bits/ 64 <4>;
opp-microvolt = <875000>;
};
};
- Usage case to handle the frequency and voltage of bus on runtime
in exynos3250-rinato.dts are listed below:
_dmc {
devfreq-events = <_dmc0_3>, <_dmc1_3>;
vdd-supply = <_reg>; /* VDD_MIF */
status = "okay";
};
2. Add new passive governor of DEVFREQ framework (patch5-patch7)
: This patch-set add the new passive governor for DEVFREQ framework.
The existing governors (ondemand, performance and so on) are used for DVFS
(Dynamic Voltage and Frequency Scaling) drivers. The existing governors
are independently used for specific device driver which don't give the
influence to
Re: [PATCH 2/2] mm/page_ref: add tracepoint to track down page reference manipulation
On Wed, Dec 09, 2015 at 10:36:48PM -0500, Steven Rostedt wrote: > On Thu, 10 Dec 2015 11:50:15 +0900 > Joonsoo Kim wrote: > > > Output of cpu 3, 7 are mixed and it's not easy to analyze it. > > > > I think that it'd be better not to sort stack trace. How do > > you think about it? Could you fix it, please? > > It may not be that easy to fix because of the sorting algorithm. That > would require looking going ahead one more event each time and then > checking if its a stacktrace. I may look at it and see if I can come up > with something that's not too invasive in the algorithms. Okay. > That said, for now you can use the --cpu option. I'm not sure I ever > documented it as it was originally added for debugging, but I use it > enough that it may be worth while to officially support it. > > trace-cmd report --cpu 3 > > Will show you just cpu 3 and nothing else. Which is what I use a lot. Thanks for the input. It works but it's not sufficient to me. Page reference is manipulated by multiple cpus so it's better to analyze unified output. > > But doing the stack trace thing may be something to fix as well. I'll > see what I can do, but no guarantees. Okay. Don't be hurry. :) trace-cmd is excellent and works well for me as it is. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: mdc: Correct terminate_all handling
On Mon, Dec 07, 2015 at 04:59:41PM +, Damien Horsley wrote: > On 05/12/15 08:43, Vinod Koul wrote: > > On Mon, Nov 23, 2015 at 02:22:04PM +, Damien Horsley wrote: > >> From: "Damien.Horsley" > >> > >> Use of the CANCEL bit in mdc_terminate_all creates an > >> additional 'command done' to appear in the registers (in > >> addition to an interrupt). > >> > >> In addition, there is a potential race between > >> mdc_terminate_all and the irq handler if a transfer > >> completes at the same time as the terminate all (presently > >> this results in an inappropriate warning). > >> > >> To handle these issues, any outstanding 'command done' > >> events are cleared during mdc_terminate_all and the irq > >> handler takes no action when there are no new 'command done' > >> events. > > > > SO what does 'command done' event represent, and what would be the behaviour > > of ignoring those > > > > The 'command done' event occurs whenever a new descriptor is loaded from > memory, and once when the whole transfer is completed. Use of the CANCEL > bit can cause additional 'command done' events to occur, which need to > be cleared. Okay, btw please fix the subsystem name. I'ts dmaengine -- ~Vinod -- 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] dmaengine: at_xdmac: fix at_xdmac_prep_dma_memcpy()
On Mon, Dec 07, 2015 at 03:58:56PM +0100, Cyrille Pitchen wrote: > This patch fixes at_xdmac_prep_dma_memcpy(). Indeed the data width field > of the Channel Configuration register was not updated properly in the > loop: the bits of the dwidth field were not cleared before adding their > new value. Applied, thanks -- ~Vinod -- 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] fs: clear file privilege bits when mmap writing
On Wed, Dec 09, 2015 at 02:51:48PM -0800, Kees Cook wrote:
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 3aa514254161..409bd7047e7e 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -872,6 +872,7 @@ struct file {
> struct list_headf_tfile_llink;
> #endif /* #ifdef CONFIG_EPOLL */
> struct address_space*f_mapping;
> + boolf_remove_privs;
NAK. If anything, such things belong in ->f_flags. _If_ this is worth
doing at all, that is.
--
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 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor
Hi Chanwoo Choi,
On 10 December 2015 at 05:42, Chanwoo Choi wrote:
> Hi Anand,
>
> First of all, thanks for trying to test this series.
>
> On 2015년 12월 10일 04:05, Anand Moon wrote:
>> Hi Chanwoo Choi,
>>
>> On 9 December 2015 at 09:37, Chanwoo Choi wrote:
>>> This patch-set includes the two features as following. The generic exynos
>>> bus
>>> frequency driver is able to support almost Exynos SoCs for bus frequency
>>> scaling. And the new passive governor is able to make the dependency on
>>> between devices for frequency/voltage scaling. I had posted the patch-set[1]
>>> with the similiar concept. This is is revised version for exynos bus
>>> frequency.
>>> - Generic exynos bus frequency driver
>>> - New passive governor of DEVFREQ framework
>>>
>>> Depends on:
>>> - This patch-set is based on devfreq.git[2].
>>> [1] https://lkml.org/lkml/2015/1/7/872
>>>: [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver
>>> [2] https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/ (branch:
>>> for-rafael)
>>>
>>> Changes from v1:
>>> (https://lkml.org/lkml/2015/11/26/260)
>>> - Check whether the instance of regulator is NULL or not
>>> when executing regulator_disable() because of only parent
>>> devfreq device has the regulator instance. After fixing it,
>>> the wake-up from suspend state is well working. (patch1)
>>> - Fix bug which checks 'bus-clk' instead of 'bus->regulator'
>>> after calling devm_clk_get() (on patch1)
>>> - Update the documentation to remove the description about
>>> DEVFREQ-EVENT subsystem (on patch2)
>>> - Add the full name of DMC (Dynamic Memory Controller) (on patch2)
>>> - Modify the detailed correlation of buses for Exynos3250
>>> on documentation (patch2)
>>> - Add the MFC bus node for Exynos3250 (on patch11, patch12)
>>> - Fix the duplicate frequency of bus_display on Exynos4x12.dtsi
>>> - Add the PPMU node for exynos4412-odroidu3
>>> - Add the support of bus frequency for exynos4412-odroidu3
>>>
>>> Detailed descirption for patch-set:
>>> 1. Add generic exynos bus frequency driver
>>> : This patch-set adds the generic exynos bus frequency driver for AXI bus
>>> of sub-blocks in exynos SoC. The Samsung Exynos SoC have the common
>>> architecture for bus between DRAM and sub-blocks in SoC.
>>>
>>> There are the different buses according to Exynos SoC because Exynos SoC
>>> has the differnt sub-blocks and bus speed. In spite of this difference
>>> among Exynos SoCs, this driver is able to support almost Exynos SoC by
>>> adding
>>> unique data of each bus in the devicetree file.
>>>
>>> In devicetree, each bus node has a bus clock, regulator, operation-point
>>> and devfreq-event devices which measure the utilization of each bus block.
>>>
>>> For example,
>>> - The bus of DMC block in exynos3250.dtsi are listed below:
>>>
>>> bus_dmc: bus_dmc {
>>> compatible = "samsung,exynos-bus";
>>> clocks = <_dmc CLK_DIV_DMC>;
>>> clock-names = "bus";
>>> operating-points-v2 = <_dmc_opp_table>;
>>> status = "disabled";
>>> };
>>>
>>> bus_dmc_opp_table: opp_table0 {
>>> compatible = "operating-points-v2";
>>> opp-shared;
>>>
>>> opp00 {
>>> opp-hz = /bits/ 64 <5000>;
>>> opp-microvolt = <80>;
>>> };
>>> opp01 {
>>> opp-hz = /bits/ 64 <1>;
>>> opp-microvolt = <80>;
>>> };
>>> opp02 {
>>> opp-hz = /bits/ 64 <13400>;
>>> opp-microvolt = <80>;
>>> };
>>> opp03 {
>>> opp-hz = /bits/ 64 <2>;
>>> opp-microvolt = <80>;
>>> };
>>> opp04 {
>>> opp-hz = /bits/ 64 <4>;
>>> opp-microvolt = <875000>;
>>> };
>>> };
>>>
>>> - Usage case to handle the frequency and voltage of bus on runtime
>>> in exynos3250-rinato.dts are listed below:
>>>
>>> _dmc {
>>> devfreq-events = <_dmc0_3>, <_dmc1_3>;
>>> vdd-supply = <_reg>; /* VDD_MIF */
>>> status = "okay";
>>> };
>>>
>>> 2. Add new passive governor of DEVFREQ framework (patch5-patch7)
>>> : This patch-set add the new passive governor for DEVFREQ framework.
>>> The existing governors (ondemand, performance and so on) are used for DVFS
>>> (Dynamic Voltage and Frequency Scaling) drivers. The existing governors
>>> are independently used for specific device driver which don't give the
>>> influence to other device drviers and also don't receive the effect from
>>> other device drivers.
>>>
>>> The passive governor depends on operation of parent driver with existing
>>>
Re: [PATCH v2] dmaengine: stm32-dma: Fix unchecked deference of chan->desc
On Mon, Dec 07, 2015 at 12:00:28PM +0100, M'boumba Cedric Madianga wrote:
> 'commit d8b468394fb7 ("dmaengine: Add STM32 DMA driver")' leads to the
> following Smatch complaint:
>
> drivers/dma/stm32-dma.c:562 stm32_dma_issue_pending()
> error: we previously assumed 'chan->desc' could be null (see line 560)
>
> So, this patch fixes the unchecked dereference of chan->desc by returning
> operation not permitted error when stm32_dma_start_transfer() does not
> succeed to allocate a virtual channel descriptor.
Applied, thanks
--
~Vinod
--
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 00/14] perf tools: Move perf subcommand framework into lib/tools
On Mon, Dec 07, 2015 at 10:21:38PM -0600, Josh Poimboeuf wrote: > Ingo suggested that I factor out the perf subcommand functionality > (originally copied from git) into tools/lib so that it can be used by > stacktool[*] and possibly others. > > All the subcommand option handling files have been moved into libapi, > including parse-options.c, run-command.c, exec_cmd.c, help.c, usage.c, > and their dependencies. Since several of the dependencies are more > general-purpose "utilities" which aren't directly related to > subcommands, I put everything in 'tools/lib/api/util'. They're linked > into perf as part of the libapi.a library. > > Patches 1-13 do some cleanups and splitting up of the code in > preparation for the move. > > Patch 14 does the actual moving of the files into tools/lib/api/util. > > Based on tip/perf/core. > > [*] https://lkml.kernel.org/r/cover.1445443144.git.jpoim...@redhat.com Is there a public repo that I can pull and test? Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/9] dmaengine: pl330: add new items for pl330 private data
On Fri, Dec 04, 2015 at 11:24:21AM +0800, Wang Hongcheng wrote:
> has_no_cap_mask means this device has no preset cap mask.
> mcbuf_sz means bytes to allocate for MC buffer.
MC ?
> flags is for irq sharing, default is non-shared, in AMD
> Carrizo, pl330 shares IRQ with its corresponding UART device.
>
> Signed-off-by: Wang Hongcheng
> ---
> drivers/acpi/acpi_apd.c| 13 -
> drivers/dma/pl330.c| 19 +--
> include/linux/amba/pl330.h | 3 +++
> 3 files changed, 28 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c
> index eb3316a..7a582f5 100644
> --- a/drivers/acpi/acpi_apd.c
> +++ b/drivers/acpi/acpi_apd.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "internal.h"
> @@ -35,6 +36,16 @@ struct apd_private_data;
> #define ACPI_APD_SYSFS BIT(0)
> #define ACPI_APD_PM BIT(1)
>
> +static u8 peri_id[2] = { 0, 1 };
> +
> +static struct dma_pl330_platdata amd_pl330 = {
> + .nr_valid_peri = 2,
> + .peri_id = peri_id,
> + .has_no_cap_mask = true,
> + .mcbuf_sz = 0,
> + .flags = IRQF_SHARED,
> +};
Why not DT or ACPI for this?
--
~Vinod
--
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/3] mm, printk: introduce new format string for flags
On Thu, Dec 10, 2015 at 11:59:44AM +0900, Joonsoo Kim wrote:
> Ccing, Steven to ask trace-cmd problem.
Thanks, I should have been Cc'd for the rest as well.
>
> On Fri, Dec 04, 2015 at 04:16:33PM +0100, Vlastimil Babka wrote:
> > In mm we use several kinds of flags bitfields that are sometimes printed for
> > debugging purposes, or exported to userspace via sysfs. To make them easier
> > to
> > interpret independently on kernel version and config, we want to dump also
> > the
> > symbolic flag names. So far this has been done with repeated calls to
> > pr_cont(), which is unreliable on SMP, and not usable for e.g. sysfs export.
> >
> > To get a more reliable and universal solution, this patch extends printk()
> > format string for pointers to handle the page flags (%pgp), gfp_flags (%pgg)
> > and vma flags (%pgv). Existing users of dump_flag_names() are converted and
> > simplified.
> >
> > It would be possible to pass flags by value instead of pointer, but the %p
> > format string for pointers already has extensions for various kernel
> > structures, so it's a good fit, and the extra indirection in a non-critical
> > path is negligible.
>
> I'd like to use %pgp in tracepoint output. It works well when I do
> 'cat /sys/kernel/debug/tracing/trace' but not works well when I do
> './trace-cmd report'. It prints following error log.
>
> [page_ref:page_ref_unfreeze] bad op token &
> [page_ref:page_ref_set] bad op token &
> [page_ref:page_ref_mod_unless] bad op token &
> [page_ref:page_ref_mod_and_test] bad op token &
> [page_ref:page_ref_mod_and_return] bad op token &
> [page_ref:page_ref_mod] bad op token &
> [page_ref:page_ref_freeze] bad op token &
>
> Following is the format I used.
>
> TP_printk("pfn=0x%lx flags=%pgp count=%d mapcount=%d mapping=%p mt=%d val=%d
> ret=%d",
> __entry->pfn, &__entry->flags, __entry->count,
> __entry->mapcount, __entry->mapping, __entry->mt,
> __entry->val, __entry->ret)
>
> Could it be solved by 'trace-cmd' itself?
> Or it's better to pass flags by value?
> Or should I use something like show_gfp_flags()?
Yes this can be solved in perf and trace-cmd via the parse-events.c file. And
as soon as that happens, whatever method we decide upon becomes a userspace
ABI. So don't think you can change it later.
-- Steve
--
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: emac: emac gigabit ethernet controller driver
Gilad Avidov wrote: pointer math on void* ? what is the size of void ? I'm talking about adding and subtracting pointer values, so u32 pkt_len =((void *)ip_hdr(skb) - skb->data) -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation. -- 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] mm, printk: introduce new format string for flags
On Fri, Dec 04, 2015 at 03:15:45PM +0100, Vlastimil Babka wrote: > On 12/03/2015 07:38 PM, yalin wang wrote: > >that’s all, see cpumask_pr_args(masks) macro, > >it also use macro and %*pb to print cpu mask . > >i think this method is not very complex to use . > > Well, one also has to write the appropriate translation tables. > > >search source code , > >there is lots of printk to print flag into hex number : > >$ grep -n -r 'printk.*flag.*%x’ . > >it will be great if this flag string print is generic. > > I think it can always be done later, this is an internal API. For now we > just have 3 quite generic flags, so let's not over-engineer things right > now. > As long as it is never used in the TP_printk() part of a tracepoint. As soon as it is, trace-cmd and perf will update parse-events to handle that parameter, and as soon as that is done, it becomes a userspace ABI. Just be warned. -- Steve -- 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 v4 3/5] misc: eeprom_93xx46: Implement eeprom_93xx46 DT bindings.
This commit implements bindings in the eeprom_93xx46 driver allowing
device word size and read-only attributes to be specified via
devicetree.
Signed-off-by: Cory Tusar
Tested-by: Chris Healy
---
drivers/misc/eeprom/eeprom_93xx46.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/drivers/misc/eeprom/eeprom_93xx46.c
b/drivers/misc/eeprom/eeprom_93xx46.c
index e1bf0a5..cc27e11 100644
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -13,6 +13,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -294,12 +296,58 @@ static ssize_t eeprom_93xx46_store_erase(struct device
*dev,
}
static DEVICE_ATTR(erase, S_IWUSR, NULL, eeprom_93xx46_store_erase);
+static const struct of_device_id eeprom_93xx46_of_table[] = {
+ { .compatible = "eeprom-93xx46", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, eeprom_93xx46_of_table);
+
+static int eeprom_93xx46_probe_dt(struct spi_device *spi)
+{
+ struct device_node *np = spi->dev.of_node;
+ struct eeprom_93xx46_platform_data *pd;
+ u32 tmp;
+ int ret;
+
+ pd = devm_kzalloc(>dev, sizeof(*pd), GFP_KERNEL);
+ if (!pd)
+ return -ENOMEM;
+
+ ret = of_property_read_u32(np, "data-size", );
+ if (ret < 0) {
+ dev_err(>dev, "data-size property not found\n");
+ return ret;
+ }
+
+ if (tmp == 8) {
+ pd->flags |= EE_ADDR8;
+ } else if (tmp == 16) {
+ pd->flags |= EE_ADDR16;
+ } else {
+ dev_err(>dev, "invalid data-size (%d)\n", tmp);
+ return -EINVAL;
+ }
+
+ if (of_property_read_bool(np, "read-only"))
+ pd->flags |= EE_READONLY;
+
+ spi->dev.platform_data = pd;
+
+ return 0;
+}
+
static int eeprom_93xx46_probe(struct spi_device *spi)
{
struct eeprom_93xx46_platform_data *pd;
struct eeprom_93xx46_dev *edev;
int err;
+ if (spi->dev.of_node) {
+ err = eeprom_93xx46_probe_dt(spi);
+ if (err < 0)
+ return err;
+ }
+
pd = spi->dev.platform_data;
if (!pd) {
dev_err(>dev, "missing platform data\n");
@@ -370,6 +418,7 @@ static int eeprom_93xx46_remove(struct spi_device *spi)
static struct spi_driver eeprom_93xx46_driver = {
.driver = {
.name = "93xx46",
+ .of_match_table = of_match_ptr(eeprom_93xx46_of_table),
},
.probe = eeprom_93xx46_probe,
.remove = eeprom_93xx46_remove,
--
2.4.10
--
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 v4 2/5] Documentation: devicetree: Add DT bindings to eeprom_93xx46 driver.
This commit documents bindings to be added to the eeprom_93xx46 driver
which will allow:
- Device word size and read-only attributes to be specified.
- A device-specific compatible string for use with Atmel AT93C46D
EEPROMs.
- Specifying a GPIO line to function as a 'select' or 'enable' signal
prior to accessing the EEPROM.
Signed-off-by: Cory Tusar
Acked-by: Rob Herring
Tested-by: Chris Healy
---
.../devicetree/bindings/misc/eeprom-93xx46.txt | 25 ++
1 file changed, 25 insertions(+)
diff --git a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
new file mode 100644
index 000..a8ebb46
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
@@ -0,0 +1,25 @@
+EEPROMs (SPI) compatible with Microchip Technology 93xx46 family.
+
+Required properties:
+- compatible : shall be one of:
+"atmel,at93c46d"
+"eeprom-93xx46"
+- data-size : number of data bits per word (either 8 or 16)
+
+Optional properties:
+- read-only : parameter-less property which disables writes to the EEPROM
+- select-gpios : if present, specifies the GPIO that will be asserted prior to
+ each access to the EEPROM (e.g. for SPI bus multiplexing)
+
+Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt
+apply. In particular, "reg" and "spi-max-frequency" properties must be given.
+
+Example:
+ eeprom@0 {
+ compatible = "eeprom-93xx46";
+ reg = <0>;
+ spi-max-frequency = <100>;
+ spi-cs-high;
+ data-size = <8>;
+ select-gpios = < 4 GPIO_ACTIVE_HIGH>;
+ };
--
2.4.10
--
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 v4 4/5] misc: eeprom_93xx46: Add quirks to support Atmel AT93C46D device.
Atmel devices in this family have some quirks not found in other similar
chips - they do not support a sequential read of the entire EEPROM
contents, and the control word sent at the start of each operation
varies in bit length.
This commit adds quirk support to the driver and modifies the read
implementation to support non-sequential reads for consistency with
other misc/eeprom drivers.
Tested on a custom Freescale VF610-based platform, with an AT93C46D
device attached via dspi2. The spi-gpio driver was used to allow the
necessary non-byte-sized transfers.
Signed-off-by: Cory Tusar
Tested-by: Chris Healy
---
drivers/misc/eeprom/eeprom_93xx46.c | 126 ++--
include/linux/eeprom_93xx46.h | 6 ++
2 files changed, 97 insertions(+), 35 deletions(-)
diff --git a/drivers/misc/eeprom/eeprom_93xx46.c
b/drivers/misc/eeprom/eeprom_93xx46.c
index cc27e11..d50bc17 100644
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -27,6 +27,15 @@
#define ADDR_ERAL 0x20
#define ADDR_EWEN 0x30
+struct eeprom_93xx46_devtype_data {
+ unsigned int quirks;
+};
+
+static const struct eeprom_93xx46_devtype_data atmel_at93c46d_data = {
+ .quirks = EEPROM_93XX46_QUIRK_SINGLE_WORD_READ |
+ EEPROM_93XX46_QUIRK_INSTRUCTION_LENGTH,
+};
+
struct eeprom_93xx46_dev {
struct spi_device *spi;
struct eeprom_93xx46_platform_data *pdata;
@@ -35,6 +44,16 @@ struct eeprom_93xx46_dev {
int addrlen;
};
+static inline bool has_quirk_single_word_read(struct eeprom_93xx46_dev *edev)
+{
+ return edev->pdata->quirks & EEPROM_93XX46_QUIRK_SINGLE_WORD_READ;
+}
+
+static inline bool has_quirk_instruction_length(struct eeprom_93xx46_dev *edev)
+{
+ return edev->pdata->quirks & EEPROM_93XX46_QUIRK_INSTRUCTION_LENGTH;
+}
+
static ssize_t
eeprom_93xx46_bin_read(struct file *filp, struct kobject *kobj,
struct bin_attribute *bin_attr,
@@ -42,58 +61,73 @@ eeprom_93xx46_bin_read(struct file *filp, struct kobject
*kobj,
{
struct eeprom_93xx46_dev *edev;
struct device *dev;
- struct spi_message m;
- struct spi_transfer t[2];
- int bits, ret;
- u16 cmd_addr;
+ ssize_t ret = 0;
dev = container_of(kobj, struct device, kobj);
edev = dev_get_drvdata(dev);
- cmd_addr = OP_READ << edev->addrlen;
+ mutex_lock(>lock);
- if (edev->addrlen == 7) {
- cmd_addr |= off & 0x7f;
- bits = 10;
- } else {
- cmd_addr |= (off >> 1) & 0x3f;
- bits = 9;
- }
+ if (edev->pdata->prepare)
+ edev->pdata->prepare(edev);
- dev_dbg(>spi->dev, "read cmd 0x%x, %d Hz\n",
- cmd_addr, edev->spi->max_speed_hz);
+ while (count) {
+ struct spi_message m;
+ struct spi_transfer t[2] = { { 0 } };
+ u16 cmd_addr = OP_READ << edev->addrlen;
+ size_t nbytes = count;
+ int bits;
+ int err;
+
+ if (edev->addrlen == 7) {
+ cmd_addr |= off & 0x7f;
+ bits = 10;
+ if (has_quirk_single_word_read(edev))
+ nbytes = 1;
+ } else {
+ cmd_addr |= (off >> 1) & 0x3f;
+ bits = 9;
+ if (has_quirk_single_word_read(edev))
+ nbytes = 2;
+ }
- spi_message_init();
- memset(t, 0, sizeof(t));
+ dev_dbg(>spi->dev, "read cmd 0x%x, %d Hz\n",
+ cmd_addr, edev->spi->max_speed_hz);
- t[0].tx_buf = (char *)_addr;
- t[0].len = 2;
- t[0].bits_per_word = bits;
- spi_message_add_tail([0], );
+ spi_message_init();
- t[1].rx_buf = buf;
- t[1].len = count;
- t[1].bits_per_word = 8;
- spi_message_add_tail([1], );
+ t[0].tx_buf = (char *)_addr;
+ t[0].len = 2;
+ t[0].bits_per_word = bits;
+ spi_message_add_tail([0], );
- mutex_lock(>lock);
+ t[1].rx_buf = buf;
+ t[1].len = count;
+ t[1].bits_per_word = 8;
+ spi_message_add_tail([1], );
- if (edev->pdata->prepare)
- edev->pdata->prepare(edev);
+ err = spi_sync(edev->spi, );
+ /* have to wait at least Tcsl ns */
+ ndelay(250);
- ret = spi_sync(edev->spi, );
- /* have to wait at least Tcsl ns */
- ndelay(250);
- if (ret) {
- dev_err(>spi->dev, "read %zu bytes at %d: err. %d\n",
- count, (int)off, ret);
+ if (err) {
+ dev_err(>spi->dev, "read %zu bytes at %d: err.
%d\n",
+ nbytes,
Re: [PATCH net-next v4 12/19] net: fcoe: use __ethtool_get_ksettings
apologies, forgot to make allyesconfig/allmodconfig this time. Fixed
in my local copy. Will be part of v5 after other feedback on this v4.
On Wed, Dec 9, 2015 at 11:18 AM, kbuild test robot wrote:
> Hi David,
>
> [auto build test ERROR on net-next/master]
>
> url:
> https://github.com/0day-ci/linux/commits/David-Decotigny/RFC-new-ETHTOOL_GSETTINGS-SSETTINGS-API/20151210-022123
> config: i386-randconfig-b0-12100240 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
>drivers/scsi/fcoe/fcoe_transport.c: In function 'fcoe_link_speed_update':
>>> drivers/scsi/fcoe/fcoe_transport.c:104:32: error: request for member 'mask'
>>> in something not a structure or union
> if (ecmd.link_modes.supported.mask[0] & (
>^
>drivers/scsi/fcoe/fcoe_transport.c:110:32: error: request for member
> 'mask' in something not a structure or union
> if (ecmd.link_modes.supported.mask[0] & (
>^
>drivers/scsi/fcoe/fcoe_transport.c:117:32: error: request for member
> 'mask' in something not a structure or union
> if (ecmd.link_modes.supported.mask[0] & (
>^
>drivers/scsi/fcoe/fcoe_transport.c:122:32: error: request for member
> 'mask' in something not a structure or union
> if (ecmd.link_modes.supported.mask[0] & (
>^
>
> vim +/mask +104 drivers/scsi/fcoe/fcoe_transport.c
>
> 98 if (!__ethtool_get_ksettings(netdev, )) {
> 99 lport->link_supported_speeds &= ~(FC_PORTSPEED_1GBIT
> |
>100FC_PORTSPEED_10GBIT
> |
>101FC_PORTSPEED_20GBIT
> |
>102
> FC_PORTSPEED_40GBIT);
>103
> > 104 if (ecmd.link_modes.supported.mask[0] & (
>105 SUPPORTED_1000baseT_Half |
>106 SUPPORTED_1000baseT_Full |
>107 SUPPORTED_1000baseKX_Full))
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
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/
