[PATCH 1/5] perf hists: Introduce perf_hpp for hist period printing

[Namhyung Kim]

From: Namhyung Kim 

Current hist print functions are messy because it has to consider many
of command line options and the code doing that is scattered around to
places. So when someone wants to add an option to manipulate the hist
output it'd very easy to miss to update all of them in sync. And things
getting worse as more options/features are added continuously.

So I'd like to refactor them using hpp formats and move common code to
ui/hist.c in order to make it easy to maintain and to add new features.

Signed-off-by: Namhyung Kim 
---
 tools/perf/Makefile|   2 +
 tools/perf/builtin-diff.c  |   1 +
 tools/perf/ui/hist.c   | 316 +
 tools/perf/ui/setup.c  |   8 +-
 tools/perf/ui/stdio/hist.c | 238 ++
 tools/perf/util/hist.h |  37 ++
 6 files changed, 402 insertions(+), 200 deletions(-)
 create mode 100644 tools/perf/ui/hist.c

diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 6bd888d04b6e..e834b848c9b1 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -403,7 +403,9 @@ LIB_OBJS += $(OUTPUT)util/cgroup.o
 LIB_OBJS += $(OUTPUT)util/target.o
 LIB_OBJS += $(OUTPUT)util/rblist.o
 LIB_OBJS += $(OUTPUT)util/intlist.o
+
 LIB_OBJS += $(OUTPUT)ui/helpline.o
+LIB_OBJS += $(OUTPUT)ui/hist.o
 LIB_OBJS += $(OUTPUT)ui/stdio/hist.o
 
 BUILTIN_OBJS += $(OUTPUT)builtin-annotate.o
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index d29d350fb2b7..3fc53f8b098e 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -235,6 +235,7 @@ int cmd_diff(int argc, const char **argv, const char 
*prefix __used)
if (symbol__init() < 0)
return -1;
 
+   perf_hpp__init(true, show_displacement);
setup_sorting(diff_usage, options);
setup_pager();
 
diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
new file mode 100644
index ..c9a566cfd9c2
--- /dev/null
+++ b/tools/perf/ui/hist.c
@@ -0,0 +1,316 @@
+#include 
+
+#include "../util/hist.h"
+#include "../util/util.h"
+#include "../util/sort.h"
+
+
+/* hist period print (hpp) functions */
+static int hpp__header_overhead(struct perf_hpp *hpp)
+{
+   if (hpp->ptr)
+   return scnprintf(hpp->buf, hpp->size, "Baseline");
+   else
+   return scnprintf(hpp->buf, hpp->size, "Overhead");
+}
+
+static int hpp__width_overhead(struct perf_hpp *hpp __used)
+{
+   return 8;
+}
+
+static int hpp__color_overhead(struct perf_hpp *hpp, struct hist_entry *he)
+{
+   double percent = 100.0 * he->period / hpp->total_period;
+   return percent_color_snprintf(hpp->buf, hpp->size, "  %5.2f%%", 
percent);
+}
+
+static int hpp__entry_overhead(struct perf_hpp *hpp, struct hist_entry *he)
+{
+   double percent = 100.0 * he->period / hpp->total_period;
+   return scnprintf(hpp->buf, hpp->size, "  %5.2f%%", percent);
+}
+
+static int hpp__header_overhead_sys(struct perf_hpp *hpp)
+{
+   return scnprintf(hpp->buf, hpp->size, " sys  ");
+}
+
+static int hpp__width_overhead_sys(struct perf_hpp *hpp __used)
+{
+   return 6;
+}
+
+static int hpp__color_overhead_sys(struct perf_hpp *hpp, struct hist_entry *he)
+{
+   double percent = 100.0 * he->period_sys / hpp->total_period;
+   return percent_color_snprintf(hpp->buf, hpp->size, "%5.2f%%", percent);
+}
+
+static int hpp__entry_overhead_sys(struct perf_hpp *hpp, struct hist_entry *he)
+{
+   double percent = 100.0 * he->period_sys / hpp->total_period;
+   return scnprintf(hpp->buf, hpp->size, "%5.2f%%", percent);
+}
+
+static int hpp__header_overhead_us(struct perf_hpp *hpp)
+{
+   return scnprintf(hpp->buf, hpp->size, " user ");
+}
+
+static int hpp__width_overhead_us(struct perf_hpp *hpp __used)
+{
+   return 6;
+}
+
+static int hpp__color_overhead_us(struct perf_hpp *hpp, struct hist_entry *he)
+{
+   double percent = 100.0 * he->period_us / hpp->total_period;
+   return percent_color_snprintf(hpp->buf, hpp->size, "%5.2f%%", percent);
+}
+
+static int hpp__entry_overhead_us(struct perf_hpp *hpp, struct hist_entry *he)
+{
+   double percent = 100.0 * he->period_us / hpp->total_period;
+   return scnprintf(hpp->buf, hpp->size, "%5.2f%%", percent);
+}
+
+static int hpp__header_overhead_guest_sys(struct perf_hpp *hpp)
+{
+   return scnprintf(hpp->buf, hpp->size, "guest sys");
+}
+
+static int hpp__width_overhead_guest_sys(struct perf_hpp *hpp __used)
+{
+   return 9;
+}
+
+static int hpp__color_overhead_guest_sys(struct perf_hpp *hpp,
+struct hist_entry *he)
+{
+   double percent = 100.0 * he->period_guest_sys / hpp->total_period;
+   return percent_color_snprintf(hpp->buf, hpp->size, "  %5.2f%% ", 
percent);
+}
+
+static int hpp__entry_overhead_guest_sys(struct perf_hpp *hpp,
+struct hist_entry *he)
+{
+   double percent = 100.0 * he->period_guest_sys / 

[PATCH 5/5] perf gtk/browser: Use perf_hpp__format functions

[Namhyung Kim]

From: Namhyung Kim 

Now we can support color using pango markup with this change.

Acked-by: Pekka Enberg 
Signed-off-by: Namhyung Kim 
---
 tools/perf/ui/gtk/browser.c | 101 +---
 tools/perf/ui/gtk/gtk.h |   1 +
 tools/perf/ui/gtk/setup.c   |   1 +
 3 files changed, 87 insertions(+), 16 deletions(-)

diff --git a/tools/perf/ui/gtk/browser.c b/tools/perf/ui/gtk/browser.c
index 26b5b652a8cd..3c16ab50e0f8 100644
--- a/tools/perf/ui/gtk/browser.c
+++ b/tools/perf/ui/gtk/browser.c
@@ -36,6 +36,57 @@ static void perf_gtk__resize_window(GtkWidget *window)
gtk_window_resize(GTK_WINDOW(window), width, height);
 }
 
+static const char *perf_gtk__get_percent_color(double percent)
+{
+   if (percent >= MIN_RED)
+   return "";
+   if (percent >= MIN_GREEN)
+   return "";
+   return NULL;
+}
+
+#define HPP__COLOR_FN(_name, _field)   
\
+static int perf_gtk__hpp_color_ ## _name(struct perf_hpp *hpp, 
\
+struct hist_entry *he) 
\
+{  
\
+   double percent = 100.0 * he->_field / hpp->total_period;
\
+   const char *markup; 
\
+   int ret = 0;
\
+   
\
+   markup = perf_gtk__get_percent_color(percent);  
\
+   if (markup) 
\
+   ret += scnprintf(hpp->buf, hpp->size, "%s", markup);
\
+   ret += scnprintf(hpp->buf + ret, hpp->size - ret, "%5.2f%%", percent);  
\
+   if (markup) 
\
+   ret += scnprintf(hpp->buf + ret, hpp->size - ret, "");   
\
+   
\
+   return ret; 
\
+}
+
+HPP__COLOR_FN(overhead, period)
+HPP__COLOR_FN(overhead_sys, period_sys)
+HPP__COLOR_FN(overhead_us, period_us)
+HPP__COLOR_FN(overhead_guest_sys, period_guest_sys)
+HPP__COLOR_FN(overhead_guest_us, period_guest_us)
+
+#undef HPP__COLOR_FN
+
+void perf_gtk__init_hpp(void)
+{
+   perf_hpp__init(false, false);
+
+   perf_hpp__format[PERF_HPP__OVERHEAD].color =
+   perf_gtk__hpp_color_overhead;
+   perf_hpp__format[PERF_HPP__OVERHEAD_SYS].color =
+   perf_gtk__hpp_color_overhead_sys;
+   perf_hpp__format[PERF_HPP__OVERHEAD_US].color =
+   perf_gtk__hpp_color_overhead_us;
+   perf_hpp__format[PERF_HPP__OVERHEAD_GUEST_SYS].color =
+   perf_gtk__hpp_color_overhead_guest_sys;
+   perf_hpp__format[PERF_HPP__OVERHEAD_GUEST_US].color =
+   perf_gtk__hpp_color_overhead_guest_us;
+}
+
 static void perf_gtk__show_hists(GtkWidget *window, struct hists *hists)
 {
GType col_types[MAX_COLUMNS];
@@ -43,15 +94,25 @@ static void perf_gtk__show_hists(GtkWidget *window, struct 
hists *hists)
struct sort_entry *se;
GtkListStore *store;
struct rb_node *nd;
-   u64 total_period;
GtkWidget *view;
-   int col_idx;
+   int i, col_idx;
int nr_cols;
+   char s[512];
+
+   struct perf_hpp hpp = {
+   .buf= s,
+   .size   = sizeof(s),
+   .total_period   = hists->stats.total_period,
+   };
 
nr_cols = 0;
 
-   /* The percentage column */
-   col_types[nr_cols++] = G_TYPE_STRING;
+   for (i = 0; i < PERF_HPP__MAX_INDEX; i++) {
+   if (!perf_hpp__format[i].cond)
+   continue;
+
+   col_types[nr_cols++] = G_TYPE_STRING;
+   }
 
list_for_each_entry(se, _entry__sort_list, list) {
if (se->elide)
@@ -68,11 +129,17 @@ static void perf_gtk__show_hists(GtkWidget *window, struct 
hists *hists)
 
col_idx = 0;
 
-   /* The percentage column */
-   gtk_tree_view_insert_column_with_attributes(GTK_TREE_VIEW(view),
-   -1, "Overhead (%)",
-   renderer, "text",
-   col_idx++, NULL);
+   for (i = 0; i < PERF_HPP__MAX_INDEX; i++) {
+   if (!perf_hpp__format[i].cond)
+   continue;
+
+   perf_hpp__format[i].header();
+
+   gtk_tree_view_insert_column_with_attributes(GTK_TREE_VIEW(view),
+   -1, s,
+ 

[PATCH 3/5] perf hists: Use perf_hpp__format->width to calculate the column widths

[Namhyung Kim]

From: Namhyung Kim 

Signed-off-by: Namhyung Kim 
---
 tools/perf/ui/hist.c   | 27 +++
 tools/perf/util/hist.c | 33 -
 2 files changed, 27 insertions(+), 33 deletions(-)

diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
index 802a8659c15a..16dc486d02be 100644
--- a/tools/perf/ui/hist.c
+++ b/tools/perf/ui/hist.c
@@ -337,3 +337,30 @@ int hist_entry__sort_snprintf(struct hist_entry *he, char 
*s, size_t size,
 
return ret;
 }
+
+/*
+ * See hists__fprintf to match the column widths
+ */
+unsigned int hists__sort_list_width(struct hists *hists)
+{
+   struct sort_entry *se;
+   int i, ret = 0;
+
+   for (i = 0; i < PERF_HPP__MAX_INDEX; i++) {
+   if (!perf_hpp__format[i].cond)
+   continue;
+   if (i)
+   ret += 2;
+
+   ret += perf_hpp__format[i].width(NULL);
+   }
+
+   list_for_each_entry(se, _entry__sort_list, list)
+   if (!se->elide)
+   ret += 2 + hists__col_len(hists, se->se_width_idx);
+
+   if (verbose) /* Addr + origin */
+   ret += 3 + BITS_PER_LONG / 4;
+
+   return ret;
+}
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index b1817f15bb87..0ba65ad07cd1 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -563,39 +563,6 @@ void hists__output_resort_threaded(struct hists *hists)
return __hists__output_resort(hists, true);
 }
 
-/*
- * See hists__fprintf to match the column widths
- */
-unsigned int hists__sort_list_width(struct hists *hists)
-{
-   struct sort_entry *se;
-   int ret = 9; /* total % */
-
-   if (symbol_conf.show_cpu_utilization) {
-   ret += 7; /* count_sys % */
-   ret += 6; /* count_us % */
-   if (perf_guest) {
-   ret += 13; /* count_guest_sys % */
-   ret += 12; /* count_guest_us % */
-   }
-   }
-
-   if (symbol_conf.show_nr_samples)
-   ret += 11;
-
-   if (symbol_conf.show_total_period)
-   ret += 13;
-
-   list_for_each_entry(se, _entry__sort_list, list)
-   if (!se->elide)
-   ret += 2 + hists__col_len(hists, se->se_width_idx);
-
-   if (verbose) /* Addr + origin */
-   ret += 3 + BITS_PER_LONG / 4;
-
-   return ret;
-}
-
 static void hists__remove_entry_filter(struct hists *hists, struct hist_entry 
*h,
   enum hist_filter filter)
 {
-- 
1.7.11.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 4/5] perf ui/browser: Use perf_hpp__format functions

[Namhyung Kim]

From: Namhyung Kim 

Override hpp->color functions for TUI. Because line coloring is done
outside of the function, it just sets the percent value and pass it.

Signed-off-by: Namhyung Kim 
---
 tools/perf/ui/browsers/hists.c | 94 --
 tools/perf/ui/tui/setup.c  |  4 ++
 2 files changed, 76 insertions(+), 22 deletions(-)

diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 81bd8c2af730..144d7be2872e 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -28,6 +28,8 @@ struct hist_browser {
bool has_symbols;
 };
 
+extern void hist_browser__init_hpp(void);
+
 static int hists__browser_title(struct hists *hists, char *bf, size_t size,
const char *ev_name);
 
@@ -563,14 +565,47 @@ static int hist_browser__show_callchain(struct 
hist_browser *browser,
return row - first_row;
 }
 
+#define HPP__COLOR_FN(_name, _field)   \
+static int hist_browser__hpp_color_ ## _name(struct perf_hpp *hpp, \
+struct hist_entry *he) \
+{  \
+   double percent = 100.0 * he->_field / hpp->total_period;\
+   *(double *)hpp->ptr = percent;  \
+   return scnprintf(hpp->buf, hpp->size, "%5.2f%%", percent);  \
+}
+
+HPP__COLOR_FN(overhead, period)
+HPP__COLOR_FN(overhead_sys, period_sys)
+HPP__COLOR_FN(overhead_us, period_us)
+HPP__COLOR_FN(overhead_guest_sys, period_guest_sys)
+HPP__COLOR_FN(overhead_guest_us, period_guest_us)
+
+#undef HPP__COLOR_FN
+
+void hist_browser__init_hpp(void)
+{
+   perf_hpp__init(false, false);
+
+   perf_hpp__format[PERF_HPP__OVERHEAD].color =
+   hist_browser__hpp_color_overhead;
+   perf_hpp__format[PERF_HPP__OVERHEAD_SYS].color =
+   hist_browser__hpp_color_overhead_sys;
+   perf_hpp__format[PERF_HPP__OVERHEAD_US].color =
+   hist_browser__hpp_color_overhead_us;
+   perf_hpp__format[PERF_HPP__OVERHEAD_GUEST_SYS].color =
+   hist_browser__hpp_color_overhead_guest_sys;
+   perf_hpp__format[PERF_HPP__OVERHEAD_GUEST_US].color =
+   hist_browser__hpp_color_overhead_guest_us;
+}
+
 static int hist_browser__show_entry(struct hist_browser *browser,
struct hist_entry *entry,
unsigned short row)
 {
char s[256];
double percent;
-   int printed = 0;
-   int width = browser->b.width - 6; /* The percentage */
+   int i, printed = 0;
+   int width = browser->b.width;
char folded_sign = ' ';
bool current_entry = ui_browser__is_current_entry(>b, row);
off_t row_offset = entry->row_offset;
@@ -586,35 +621,50 @@ static int hist_browser__show_entry(struct hist_browser 
*browser,
}
 
if (row_offset == 0) {
-   hist_entry__sort_snprintf(entry, s, sizeof(s), browser->hists);
-   percent = (entry->period * 100.0) / 
browser->hists->stats.total_period;
+   struct perf_hpp hpp = {
+   .buf= s,
+   .size   = sizeof(s),
+   .total_period   = browser->hists->stats.total_period,
+   };
 
-   ui_browser__set_percent_color(>b, percent, 
current_entry);
ui_browser__gotorc(>b, row, 0);
-   if (symbol_conf.use_callchain) {
-   slsmg_printf("%c ", folded_sign);
-   width -= 2;
-   }
 
-   slsmg_printf(" %5.2f%%", percent);
+   for (i = 0; i < PERF_HPP__MAX_INDEX; i++) {
+   if (!perf_hpp__format[i].cond)
+   continue;
 
-   /* The scroll bar isn't being used */
-   if (!browser->b.navkeypressed)
-   width += 1;
+   if (i) {
+   slsmg_printf("  ");
+   width -= 2;
+   }
 
-   if (!current_entry || !browser->b.navkeypressed)
-   ui_browser__set_color(>b, HE_COLORSET_NORMAL);
+   if (perf_hpp__format[i].color) {
+   hpp.ptr = 
+   /* It will set percent for us. See 
HPP__COLOR_FN above. */
+   width -= perf_hpp__format[i].color(, entry);
 
-   if (symbol_conf.show_nr_samples) {
-   slsmg_printf(" %11u", entry->nr_events);
-   width -= 12;
-   }
+   ui_browser__set_percent_color(>b, 
percent, current_entry);
+
+   

[PATCH 2/5] perf hists: Handle field separator properly

[Namhyung Kim]

From: Namhyung Kim 

When a field separator is given, the output format doesn't need to be
fancy like aligning to column length, coloring the percent value and
so on.  And since there's a slight difference to normal format, fix it
not to break backward compatibility.

Signed-off-by: Namhyung Kim 
---
 tools/perf/ui/hist.c   | 75 ++
 tools/perf/ui/stdio/hist.c |  3 +-
 2 files changed, 51 insertions(+), 27 deletions(-)

diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
index c9a566cfd9c2..802a8659c15a 100644
--- a/tools/perf/ui/hist.c
+++ b/tools/perf/ui/hist.c
@@ -8,10 +8,9 @@
 /* hist period print (hpp) functions */
 static int hpp__header_overhead(struct perf_hpp *hpp)
 {
-   if (hpp->ptr)
-   return scnprintf(hpp->buf, hpp->size, "Baseline");
-   else
-   return scnprintf(hpp->buf, hpp->size, "Overhead");
+   const char *fmt = hpp->ptr ? "Baseline" : "Overhead";
+
+   return scnprintf(hpp->buf, hpp->size, fmt);
 }
 
 static int hpp__width_overhead(struct perf_hpp *hpp __used)
@@ -28,12 +27,16 @@ static int hpp__color_overhead(struct perf_hpp *hpp, struct 
hist_entry *he)
 static int hpp__entry_overhead(struct perf_hpp *hpp, struct hist_entry *he)
 {
double percent = 100.0 * he->period / hpp->total_period;
-   return scnprintf(hpp->buf, hpp->size, "  %5.2f%%", percent);
+   const char *fmt = symbol_conf.field_sep ? "%.2f" : "  %5.2f%%";
+
+   return scnprintf(hpp->buf, hpp->size, fmt, percent);
 }
 
 static int hpp__header_overhead_sys(struct perf_hpp *hpp)
 {
-   return scnprintf(hpp->buf, hpp->size, " sys  ");
+   const char *fmt = symbol_conf.field_sep ? "%s" : "%6s";
+
+   return scnprintf(hpp->buf, hpp->size, fmt, "sys");
 }
 
 static int hpp__width_overhead_sys(struct perf_hpp *hpp __used)
@@ -50,12 +53,16 @@ static int hpp__color_overhead_sys(struct perf_hpp *hpp, 
struct hist_entry *he)
 static int hpp__entry_overhead_sys(struct perf_hpp *hpp, struct hist_entry *he)
 {
double percent = 100.0 * he->period_sys / hpp->total_period;
-   return scnprintf(hpp->buf, hpp->size, "%5.2f%%", percent);
+   const char *fmt = symbol_conf.field_sep ? "%.2f" : "%5.2f%%";
+
+   return scnprintf(hpp->buf, hpp->size, fmt, percent);
 }
 
 static int hpp__header_overhead_us(struct perf_hpp *hpp)
 {
-   return scnprintf(hpp->buf, hpp->size, " user ");
+   const char *fmt = symbol_conf.field_sep ? "%s" : "%6s";
+
+   return scnprintf(hpp->buf, hpp->size, fmt, "user");
 }
 
 static int hpp__width_overhead_us(struct perf_hpp *hpp __used)
@@ -72,7 +79,9 @@ static int hpp__color_overhead_us(struct perf_hpp *hpp, 
struct hist_entry *he)
 static int hpp__entry_overhead_us(struct perf_hpp *hpp, struct hist_entry *he)
 {
double percent = 100.0 * he->period_us / hpp->total_period;
-   return scnprintf(hpp->buf, hpp->size, "%5.2f%%", percent);
+   const char *fmt = symbol_conf.field_sep ? "%.2f" : "%5.2f%%";
+
+   return scnprintf(hpp->buf, hpp->size, fmt, percent);
 }
 
 static int hpp__header_overhead_guest_sys(struct perf_hpp *hpp)
@@ -96,7 +105,9 @@ static int hpp__entry_overhead_guest_sys(struct perf_hpp 
*hpp,
 struct hist_entry *he)
 {
double percent = 100.0 * he->period_guest_sys / hpp->total_period;
-   return scnprintf(hpp->buf, hpp->size, "  %5.2f%% ", percent);
+   const char *fmt = symbol_conf.field_sep ? "%.2f" : "  %5.2f%% ";
+
+   return scnprintf(hpp->buf, hpp->size, fmt, percent);
 }
 
 static int hpp__header_overhead_guest_us(struct perf_hpp *hpp)
@@ -120,12 +131,16 @@ static int hpp__entry_overhead_guest_us(struct perf_hpp 
*hpp,
struct hist_entry *he)
 {
double percent = 100.0 * he->period_guest_us / hpp->total_period;
-   return scnprintf(hpp->buf, hpp->size, "  %5.2f%% ", percent);
+   const char *fmt = symbol_conf.field_sep ? "%.2f" : "  %5.2f%% ";
+
+   return scnprintf(hpp->buf, hpp->size, fmt, percent);
 }
 
 static int hpp__header_samples(struct perf_hpp *hpp)
 {
-   return scnprintf(hpp->buf, hpp->size, "  Samples  ");
+   const char *fmt = symbol_conf.field_sep ? "%s" : "%11s";
+
+   return scnprintf(hpp->buf, hpp->size, fmt, "Samples");
 }
 
 static int hpp__width_samples(struct perf_hpp *hpp __used)
@@ -135,12 +150,16 @@ static int hpp__width_samples(struct perf_hpp *hpp __used)
 
 static int hpp__entry_samples(struct perf_hpp *hpp, struct hist_entry *he)
 {
-   return scnprintf(hpp->buf, hpp->size, "%11" PRIu64, he->nr_events);
+   const char *fmt = symbol_conf.field_sep ? "%" PRIu64 : "%11" PRIu64;
+
+   return scnprintf(hpp->buf, hpp->size, fmt, he->nr_events);
 }
 
 static int hpp__header_period(struct perf_hpp *hpp)
 {
-   return scnprintf(hpp->buf, hpp->size, "   Period   ");
+   const char *fmt = symbol_conf.field_sep ? "%s" : "%12s";
+
+   return 

[PATCH 0/5] perf tools: Cleanup hist printing code (v4)

[Namhyung Kim]

Hi,

This is a cleanup and refactoring patchset for the hist printing code
by adding perf_hpp__format functions and perf_hpp.  I believe it makes
the code easy to maintain and to add new features like upcoming group
viewing and callchain accumulation.

Any comments are welcome, thanks.
Namhyung

v3 -> v4:
 * Rebase to current acme/perf/core
 * The first two in the previous series have been merged
 * Rename hist_period_print to perf_hpp_fmt (Arnaldo)
 * Rename ctx->s to hpp->buf (Arnaldo)

v2 -> v3:
 * Move fprintf code to ui/stdio/hist.c (Arnaldo)
 * Add ack from Pekka


Namhyung Kim (5):
  perf hists: Introduce perf_hpp for hist period printing
  perf hists: Handle field separator properly
  perf hists: Use perf_hpp__format->width to calculate the column widths
  perf ui/browser: Use perf_hpp__format functions
  perf gtk/browser: Use perf_hpp__format functions

 tools/perf/Makefile|   2 +
 tools/perf/builtin-diff.c  |   1 +
 tools/perf/ui/browsers/hists.c |  94 ---
 tools/perf/ui/gtk/browser.c| 101 ++--
 tools/perf/ui/gtk/gtk.h|   1 +
 tools/perf/ui/gtk/setup.c  |   1 +
 tools/perf/ui/hist.c   | 366 +
 tools/perf/ui/setup.c  |   8 +-
 tools/perf/ui/stdio/hist.c | 239 +--
 tools/perf/ui/tui/setup.c  |   4 +
 tools/perf/util/hist.c |  33 
 tools/perf/util/hist.h |  37 +
 12 files changed, 616 insertions(+), 271 deletions(-)
 create mode 100644 tools/perf/ui/hist.c

-- 
1.7.11.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] spi: omap2-mcspi: Remove the macro MOD_REG_BIT

[Shubhrajyoti]

Hi Felipe,
Thanks for the review

On Tuesday 21 August 2012 02:35 PM, Felipe Balbi wrote:
> On Tue, Aug 21, 2012 at 11:47:43AM +0530, Shubhrajyoti D wrote:
>> Remove the macro MOD_REG_BIT instead make the bit field modifications
>> directly. This deletes a branch operation in cases where the the set
>> is predecided.While at it optimise two sequential bit clear in one step.
>^^
>  you need a space here, besides you can add the ack below
Will fix that and resend.
>> Signed-off-by: Shubhrajyoti D 
> Acked-by: Felipe Balbi 
>
>> ---
>>  drivers/spi/spi-omap2-mcspi.c |   28 ++--
>>  1 files changed, 14 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
>> index dd887eb..5642111 100644
>> --- a/drivers/spi/spi-omap2-mcspi.c
>> +++ b/drivers/spi/spi-omap2-mcspi.c
>> @@ -140,13 +140,6 @@ struct omap2_mcspi_cs {
>>  u32 chconf0;
>>  };
>>  
>> -#define MOD_REG_BIT(val, mask, set) do { \
>> -if (set) \
>> -val |= mask; \
>> -else \
>> -val &= ~mask; \
>> -} while (0)
>> -
>>  static inline void mcspi_write_reg(struct spi_master *master,
>>  int idx, u32 val)
>>  {
>> @@ -205,7 +198,11 @@ static void omap2_mcspi_set_dma_req(const struct 
>> spi_device *spi,
>>  else
>>  rw = OMAP2_MCSPI_CHCONF_DMAW;
>>  
>> -MOD_REG_BIT(l, rw, enable);
>> +if (enable)
>> +l |= rw;
>> +else
>> +l &= ~rw;
>> +
>>  mcspi_write_chconf0(spi, l);
>>  }
>>  
>> @@ -224,7 +221,11 @@ static void omap2_mcspi_force_cs(struct spi_device 
>> *spi, int cs_active)
>>  u32 l;
>>  
>>  l = mcspi_cached_chconf0(spi);
>> -MOD_REG_BIT(l, OMAP2_MCSPI_CHCONF_FORCE, cs_active);
>> +if (cs_active)
>> +l |= OMAP2_MCSPI_CHCONF_FORCE;
>> +else
>> +l &= ~OMAP2_MCSPI_CHCONF_FORCE;
>> +
>>  mcspi_write_chconf0(spi, l);
>>  }
>>  
>> @@ -239,9 +240,8 @@ static void omap2_mcspi_set_master_mode(struct 
>> spi_master *master)
>>   * to single-channel master mode
>>   */
>>  l = mcspi_read_reg(master, OMAP2_MCSPI_MODULCTRL);
>> -MOD_REG_BIT(l, OMAP2_MCSPI_MODULCTRL_STEST, 0);
>> -MOD_REG_BIT(l, OMAP2_MCSPI_MODULCTRL_MS, 0);
>> -MOD_REG_BIT(l, OMAP2_MCSPI_MODULCTRL_SINGLE, 1);
>> +l &= ~(OMAP2_MCSPI_MODULCTRL_STEST | OMAP2_MCSPI_MODULCTRL_MS);
>> +l |= OMAP2_MCSPI_MODULCTRL_SINGLE;
>>  mcspi_write_reg(master, OMAP2_MCSPI_MODULCTRL, l);
>>  
>>  ctx->modulctrl = l;
>> @@ -1276,9 +1276,9 @@ static int omap2_mcspi_resume(struct device *dev)
>>   * We need to toggle CS state for OMAP take this
>>   * change in account.
>>   */
>> -MOD_REG_BIT(cs->chconf0, OMAP2_MCSPI_CHCONF_FORCE, 1);
>> +cs->chconf0 |= OMAP2_MCSPI_CHCONF_FORCE;
>>  __raw_writel(cs->chconf0, cs->base + 
>> OMAP2_MCSPI_CHCONF0);
>> -MOD_REG_BIT(cs->chconf0, OMAP2_MCSPI_CHCONF_FORCE, 0);
>> +cs->chconf0 &= ~OMAP2_MCSPI_CHCONF_FORCE;
>>  __raw_writel(cs->chconf0, cs->base + 
>> OMAP2_MCSPI_CHCONF0);
>>  }
>>  }
>> -- 
>> 1.7.5.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/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git pull] drm fixes + one fbcon one

[Dave Airlie]

On Wed, Aug 22, 2012 at 2:06 PM, Dave Airlie  wrote:
>
> Hi Linus,
>
> Intel: edid fixes, power consumption fix, s/r fix, haswell fix
> radeon: BIOS loading fixes for UEFI and Thunderbolt machines, better MSAA
> validation, lockup timeout fixes, modesetting fixes
> one udl dpms fix,
> one vmwgfx fix,
> couple of trivial core changes
>
> There is an export added to ACPI as part of the radeon bios fixes,
>
> I've also included the fbcon flashing cursor vs deinit race fix, that
> seems the simplest place to start, so that distros can pick it up easier.

Me notices now you've already pulled the fbcon fix, let me know if you
want me to drop my one, or just
pull in the commit above it in my tree,
27fc4f1c0be917b1e5cef934783f9b09e28e92ea also now a branch
in the same tree called drm-fixes-no-fbcon.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 4/8] fs, exportfs: Add export_encode_inode_fh helper

[Aneesh Kumar K.V]

Pavel Emelyanov  writes:

> On 08/21/2012 02:42 PM, Aneesh Kumar K.V wrote:
>> Pavel Emelyanov  writes:
>> 
>>> On 08/20/2012 11:32 PM, J. Bruce Fields wrote:
 On Mon, Aug 20, 2012 at 11:06:06PM +0400, Cyrill Gorcunov wrote:
> On Mon, Aug 20, 2012 at 02:32:25PM -0400, J. Bruce Fields wrote:
>> On Mon, Aug 20, 2012 at 08:33:38PM +0400, Cyrill Gorcunov wrote:
>>> On Mon, Aug 20, 2012 at 07:49:23PM +0530, Aneesh Kumar K.V wrote:
 Cyrill Gorcunov  writes:

> To provide fsnotify object inodes being watched without
> binding to alphabetical path we need to encode them with
> exportfs help. This patch adds a helper which operates
> with plain inodes directly.

 doesn't name_to_handle_at()  work for you ? It also allows to get a 
 file
 handle using file descriptor.
>>>
>>> Hi, sorry for dealy. Well, the last idea is to get rid of this helper,
>>> I've sent out an updated version where ino+dev is only printed.
>>
>> I don't understand how ino and dev are useful to you, though, if you're
>> still hoping to be able to look up inodes using this information later
>> on.
>
> Hi Bruce, I believe having ino+dev is better than nothing. Otherwise we
> simply have no clue which targets are bound to inotify mark. Sometime
> (!) we can try to generate fhandle in userspace from this ino+dev bundle
> and then open the target file.

 That's insufficient to generate a filehandle in general.
>>>
>>> Yes, sure, but for live migration having inode and device is enough and 
>>> that's why.
>>> We can use two ways of having a filesystem on the target machine in the same
>>> state (from paths points of view) as it was on destination one:
>>>
>>> 1. copy file tree in a rsync manner
>>> 2. copy a virtual disk image file
>>>
>>> In the 1st case we can map inode number to path easily, since we iterate 
>>> over a filesystem
>>> anyway. I agree, that rsync is not perfect for migration but still.
>>>
>>> In the 2nd case we can generate filehandle out of an inode number only 
>>> since we _do_ know
>>> that inode will not get reused.
>> 
>> If you are going to to use open_by_handle, then that handle is not
>> sufficient right ? Or do you have open_by_inode ? as part of c/r ?
>
> Why? For e.g. ext4 you can construct a handle in userspace and open by
> it.

open_by_handle use exportfs_decode_fh which use file system specific
fh_to_dentry

foe ext4 we require a generation number

inode = get_inode(sb, fid->i32.ino, fid->i32.gen);

For brtfs

objectid = fid->objectid;
root_objectid = fid->root_objectid;
generation = fid->gen;

return btrfs_get_dentry(sb, objectid, root_objectid, generation, 1);

-aneesh

--
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] Input: Let the FT5x06 driver build without debugfs

[Dmitry Torokhov]

On Mon, Aug 20, 2012 at 06:53:03AM -0700, Guenter Roeck wrote:
> On Fri, Aug 17, 2012 at 12:21:34PM -0700, Eric W. Biederman wrote:
> > Simon Budig  writes:
> > 
> > > On 08/17/2012 02:15 AM, Eric W. Biederman wrote:
> > >> When testing to make certain my user namespace code works in
> > >> various configurations I tripped over the tf5x06.c not building
> > >> with debugfs disabled.
> > >
> > > Sorry for that.
> > >
> > > There already is a patch for this issue which I slightly prefer. You
> > > can find it in the mail from Guenther Roeck:
> > >http://www.mail-archive.com/linux-input@vger.kernel.org/msg00646.html
> > 
> > If you guys could get that merged into 3.6 I would appreciate it.
> > 
> Yes, that would be great. I don't recall seeing an e-mail from Dmitry 
> accepting
> it, though.

Applied, sorry for the delay.

-- 
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 2/4] leds-lp5523: set the brightness to 0 forcely on removing the driver

[Kim, Milo]

> Hmmm, I think we still should use cancel_work() here based on your
> idea. Please find the patch from Tejun and add him to this loop
> [PATCH 4/6] workqueue: deprecate flush[_delayed]_work_sync()
> ---
> Before this patchset,
> 
>  flush_work()
> 
> flush the last queued instance of the work item.  If it got
> queued on multple CPUs, it only considers the last queued
> instance.  The work item could still be executing on other
> CPUs and the flush might become noop if there are competing
> queueing operation on another CPU.
> 
>  flush_work_sync()
> 
> flush_work() + wait for executing instances on all CPUs.  The
> flush_work() part may still become noop if there's competing
> queueing operation.
> 
>  cancel_work()
> 
> Dequeue the work item if it's pending.  Doesn't care about
> whether it's executing or not.
> 
>  cancel_work_sync()
> 
> cancel_work() + flush_work_sync().
> 
> 
> After this patchset,
> 
>  flush_work()
> 
> flush the work item.  Any queueing happened previously is
> guaranteed to have finished execution on return.  If no
> further queueing happened after flush started, the work item
> is guaranteed to be idle on return.
> 
>  cancel_work()
> 
> Same as before.
> 
>  cancel_work_sync()
> 
> cancel_work() followed by flush_work().  The same semantics as
> del_timer_sync().
> ---
> 
> cancel_work_sync() won't execute the work item at all just cancel
> them, but flush will execute them and return.
> 

Thanks a lot for the updates!

Then, I think flush_work() should be used for executing remaining brightness 
work
rather than cancel_work_sync().

Best Regards,
Milo



--
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/4] leds-lp5523: add channel name in the platform data

[Kim, Milo]

> >  LP5523 can drive up to 9 channels. Leds can be controlled directly
> via
> > -the led class control interface. Channels have generic names:
> > +the led class control interface.
> > +The name of each channel is configurable in the platform data.
> > +If the name is NULL, channels have generic names:
> >  lp5523:channelx where x is 0...8

> Why we need a test here "pdata->label ?:"? From the document, looks
> like we use lp5523:channel%d as default.

To define the channel name, we have three options.
a) using 'name' field for each channel
b) using 'label' field without 'name'
c) default : neither data is defined

So I would change the description as below.

Signed-off-by: Milo(Woogyom) Kim 
---
 Documentation/leds/leds-lp5523.txt |   18 --
 1 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/Documentation/leds/leds-lp5523.txt 
b/Documentation/leds/leds-lp5523.txt
index fad2feb..120fdfe 100644
--- a/Documentation/leds/leds-lp5523.txt
+++ b/Documentation/leds/leds-lp5523.txt
@@ -10,8 +10,22 @@ Contact: Samu Onkalo (samu.p.onkalo-at-nokia.com)
 Description
 ---
 LP5523 can drive up to 9 channels. Leds can be controlled directly via
-the led class control interface. Channels have generic names:
-lp5523:channelx where x is 0...8
+the led class control interface.
+The name of each channel is configurable in the platform data - name and label.
+There are three options to make the channel name.
+
+a) Define the 'name' in the platform data
+To make specific channel name, then use 'name' platform data.
+/sys/class/leds/R1   (name: 'R1')
+/sys/class/leds/B1   (name: 'B1')
+
+b) Use the 'label' with no 'name' field
+For one device name with channel number, then use 'label'.
+/sys/class/leds/RGB:channelN (label: 'RGB', N: 0 ~ 8)
+
+c) Default
+If both fields are NULL, 'lp5523' is used by default.
+/sys/class/leds/lp5523:channelN  (N: 0 ~ 8)
 
 The chip provides 3 engines. Each engine can control channels without
 interaction from the main CPU. Details of the micro engine code can be found
-- 
1.7.2.5


Best Regards,
Milo



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled

[Omar Ramirez Luna]

Some IP blocks might not be using/controlling more than one
reset line, this check loosens the restriction to fully use
hwmod framework for those drivers.

E.g.: ipu has reset lines: mmu_cache, cpu0 and cpu1.
- As of now cpu1 is not used and hence (with previous check) the
  IP block isn't fully enabled by hwmod code.
- Usually ipu and dsp processors configure their mmu module first
  and then enable the processors, this involves:
* Deasserting mmu reset line, and enabling the module.
* Deasserting cpu0 reset line, and enabling the processor.
  The ones portrayed in this example are controlled through
  rproc_fw_boot in drivers/remoteproc/remoteproc_core.c

While at it, prevent _omap4_module_disable if all the hardreset
lines on an IP block are not under reset.

This will allow the driver to:
  a. Deassert the reset line.
  b. Enable the hwmod through runtime PM default callbacks.
  c. Do its usecase.
  d. Disable hwmod through runtime PM.
  e. Assert the reset line.

Signed-off-by: Omar Ramirez Luna 
---
 arch/arm/mach-omap2/omap_hwmod.c |   37 ++---
 1 file changed, 22 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 6ca8e51..eaedc33 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1558,25 +1558,28 @@ static int _read_hardreset(struct omap_hwmod *oh, const 
char *name)
 }
 
 /**
- * _are_any_hardreset_lines_asserted - return true if part of @oh is hard-reset
+ * _are_all_hardreset_lines_asserted - return true if the @oh is hard-reset
  * @oh: struct omap_hwmod *
  *
- * If any hardreset line associated with @oh is asserted, then return true.
- * Otherwise, if @oh has no hardreset lines associated with it, or if
- * no hardreset lines associated with @oh are asserted, then return false.
+ * If all hardreset lines associated with @oh are asserted, then return true.
+ * Otherwise, if part of @oh is out hardreset or if no hardreset lines
+ * associated with @oh are asserted, then return false.
  * This function is used to avoid executing some parts of the IP block
- * enable/disable sequence if a hardreset line is set.
+ * enable/disable sequence if its hardreset line is set.
  */
-static bool _are_any_hardreset_lines_asserted(struct omap_hwmod *oh)
+static bool _are_all_hardreset_lines_asserted(struct omap_hwmod *oh)
 {
-   int i;
+   int i, rst_cnt = 0;
 
if (oh->rst_lines_cnt == 0)
return false;
 
for (i = 0; i < oh->rst_lines_cnt; i++)
if (_read_hardreset(oh, oh->rst_lines[i].name) > 0)
-   return true;
+   rst_cnt++;
+
+   if (oh->rst_lines_cnt == rst_cnt)
+   return true;
 
return false;
 }
@@ -1595,6 +1598,13 @@ static int _omap4_disable_module(struct omap_hwmod *oh)
if (!oh->clkdm || !oh->prcm.omap4.modulemode)
return -EINVAL;
 
+   /*
+* Since integration code might still be doing something, only
+* disable if all lines are under hardreset.
+*/
+   if (!_are_all_hardreset_lines_asserted(oh))
+   return 0;
+
pr_debug("omap_hwmod: %s: %s\n", oh->name, __func__);
 
omap4_cminst_module_disable(oh->clkdm->prcm_partition,
@@ -1602,9 +1612,6 @@ static int _omap4_disable_module(struct omap_hwmod *oh)
oh->clkdm->clkdm_offs,
oh->prcm.omap4.clkctrl_offs);
 
-   if (_are_any_hardreset_lines_asserted(oh))
-   return 0;
-
v = _omap4_wait_target_disable(oh);
if (v)
pr_warn("omap_hwmod: %s: _wait_target_disable failed\n",
@@ -1830,7 +1837,7 @@ static int _enable(struct omap_hwmod *oh)
}
 
/*
-* If an IP block contains HW reset lines and any of them are
+* If an IP block contains HW reset lines and all of them are
 * asserted, we let integration code associated with that
 * block handle the enable.  We've received very little
 * information on what those driver authors need, and until
@@ -1838,7 +1845,7 @@ static int _enable(struct omap_hwmod *oh)
 * posted to the public lists, this is probably the best we
 * can do.
 */
-   if (_are_any_hardreset_lines_asserted(oh))
+   if (_are_all_hardreset_lines_asserted(oh))
return 0;
 
/* Mux pins for device runtime if populated */
@@ -1918,7 +1925,7 @@ static int _idle(struct omap_hwmod *oh)
return -EINVAL;
}
 
-   if (_are_any_hardreset_lines_asserted(oh))
+   if (_are_all_hardreset_lines_asserted(oh))
return 0;
 
if (oh->class->sysc)
@@ -2006,7 +2013,7 @@ static int _shutdown(struct omap_hwmod *oh)
return -EINVAL;
}
 
-   if (_are_any_hardreset_lines_asserted(oh))
+   if (_are_all_hardreset_lines_asserted(oh))
  

[PATCH 2/2] ARM: OMAP: hwmod: revise deassert sequence

[Omar Ramirez Luna]

For a reset sequence to complete cleanly, a module needs its
associated clocks to be enabled, otherwise the timeout check
in prcm code can print a false failure (failed to hardreset)
that occurs because the clocks aren't powered ON and the status
bit checked can't transition without them.

Signed-off-by: Omar Ramirez Luna 
---
 arch/arm/mach-omap2/omap_hwmod.c |   37 +
 1 file changed, 37 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index eaedc33..b65e021 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1509,6 +1509,7 @@ static int _deassert_hardreset(struct omap_hwmod *oh, 
const char *name)
 {
struct omap_hwmod_rst_info ohri;
int ret = -EINVAL;
+   int hwsup = 0;
 
if (!oh)
return -EINVAL;
@@ -1520,10 +1521,46 @@ static int _deassert_hardreset(struct omap_hwmod *oh, 
const char *name)
if (IS_ERR_VALUE(ret))
return ret;
 
+   if (oh->clkdm) {
+   /*
+* A clockdomain must be in SW_SUP otherwise reset
+* might not be completed. The clockdomain can be set
+* in HW_AUTO only when the module become ready.
+*/
+   hwsup = clkdm_in_hwsup(oh->clkdm);
+   ret = clkdm_hwmod_enable(oh->clkdm, oh);
+   if (ret) {
+   WARN(1, "omap_hwmod: %s: could not enable clockdomain 
%s: %d\n",
+oh->name, oh->clkdm->name, ret);
+   return ret;
+   }
+   }
+
+   _enable_clocks(oh);
+   if (soc_ops.enable_module)
+   soc_ops.enable_module(oh);
+
ret = soc_ops.deassert_hardreset(oh, );
+
+   if (soc_ops.disable_module)
+   soc_ops.disable_module(oh);
+   _disable_clocks(oh);
+
if (ret == -EBUSY)
pr_warning("omap_hwmod: %s: failed to hardreset\n", oh->name);
 
+   if (!ret) {
+   /*
+* Set the clockdomain to HW_AUTO, assuming that the
+* previous state was HW_AUTO.
+*/
+   if (oh->clkdm && hwsup)
+   clkdm_allow_idle(oh->clkdm);
+   } else {
+   if (oh->clkdm)
+   clkdm_hwmod_disable(oh->clkdm, oh);
+   }
+
return ret;
 }
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2] OMAP: hwmod: fix hardreset handling

[Omar Ramirez Luna]

From: Omar Ramirez Luna 

The patch to expose hwmod assert/deassert functions through omap_device
has been accepted and queued for 3.7[1], however these two patches are
needed to make the API functional. Hence a revised version is being sent
according to previous comments:

- ARM: OMAP: hwmod: revise deassert sequence
Now it uses enable|disable_module to handle the configuration of the
modulemode inside CLKCTRL. As part of the cleanup of leaf clocks, the
one associated with ipu_mmu will be removed along with the iommu hwmod
migration[2].

- ARM: OMAP: hwmod: partially un-reset hwmods might not be properly
  enabled
More infomation added in the patch description[3].

[1] http://patchwork.kernel.org/patch/1266731/
[2] http://patchwork.kernel.org/patch/1201791/
[3] http://patchwork.kernel.org/patch/1201801/

Omar Ramirez Luna (2):
  ARM: OMAP: hwmod: partially un-reset hwmods might not be properly
enabled
  ARM: OMAP: hwmod: revise deassert sequence

 arch/arm/mach-omap2/omap_hwmod.c |   74 ++
 1 file changed, 59 insertions(+), 15 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/3] Runtime Interpreted Power Sequences

[Thierry Reding]

On Tue, Aug 21, 2012 at 05:57:38PM +0100, Mark Brown wrote:
> On Tue, Aug 21, 2012 at 12:54:20PM +0300, Tomi Valkeinen wrote:
> 
> > However, if we already have a generic driver for that type of panel,
> > (which we would need anyway for the DT based approach), the developer
> > only needs to add the name of the panel and the data for the power
> > sequence to the panel driver's database, which is about the same amount
> > of work as with DT.
> 
> > So it's really just a question of where to put the data in question, DT
> > or driver. Both contain the same data, and the data structure may also
> > be the same. In DT's case it just needs to be parsed first, whereas in
> > database case you'll enter the data in structs.
> 
> I think the device tree idiomatic way of doing this is to have a bunch
> of .dtsi files for the panels which then get included by reference in
> the board files.  This isn't helpful to people working on non-DT
> architectures though.

One problem that's likely to crop up here again is that the panels won't
be properly describable in the DT. Typically there is no device that can
be addressed by the CPU. This is the same as for backlights and fixed
regulators.

Thierry


pgpm455F21Z7E.pgp
Description: PGP signature

Re: [PATCH] drivers/dma/sirf-dma.c: fix usage of devm functions

[Barry Song]

2012/8/22 Julia Lawall :
> On Wed, 22 Aug 2012, Barry Song wrote:
>
>> 2012/8/22 Vinod Koul :
>>>
>>> On Sat, 2012-08-04 at 10:35 +0200, Julia Lawall wrote:

 From: Julia Lawall 

 Fix some problems with the use of devm_ functions.
>>>
>>> Applied, thanks
>>
>>
>> the git log "drivers/dma/sirf-dma.c: fix usage of devm functions"
>> should be fixed.
>
>
> What do you suggest?  The patch is about problems with the use of
> devm_kzalloc, devm_ioremap, and devm_request_irq.

i mean the prefix

dmaengine: sirf: .

>
> thanks,
> julia

-barry
--
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: [discussion]sched: a rough proposal to enable power saving in scheduler

[Mike Galbraith]

On Tue, 2012-08-21 at 17:02 +0100, Alan Cox wrote:

> I'd like to see actual numbers and evidence on a wide range of workloads
> the spread/don't spread thing is even measurable given that you've also
> got to factor in effects like completing faster and turning everything
> off. I'd *really* like to see such evidence on a laptop,which is your
> one cited case it might work.

For my dinky dual core laptop, I suspect you're right, but for a more
powerful laptop, I'd expect spread/don't to be noticeable.

Yeah, hard numbers would be nice to see.

If I had a powerful laptop, I'd kill irq balancing, and all but periodic
load balancing, and expect to see a positive result.  Dunno what fickle
electron gods would _really_ do with those prayers though.

-Mike

--
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] task_work: add a scheduling point in task_work_run()

[Al Viro]

On Wed, Aug 22, 2012 at 01:27:21PM +0800, Michael Wang wrote:

> And can we make sure that it is safe to sleep(schedule) at this point?
> It may need some totally testing to cover all the situation...

task_work callback can bloody well block, so yes, it is safe.  Hell,
we are doing final close from that; that can lead to any amount of
IO, up to and including on-disk file freeing and, in case of vfsmount
kept alive by an opened file after we'd done umount -l, actual final
unmount of a filesystem.  That can more than just block, that can block
for a long time if that's a network filesystem...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: mmu_notifier: fix inconsistent memory between secondary MMU and host

[Xiao Guangrong]

On 08/22/2012 12:12 PM, Hugh Dickins wrote:
> On Wed, 22 Aug 2012, Xiao Guangrong wrote:
>> On 08/21/2012 11:06 PM, Andrea Arcangeli wrote:
>>>
>>> The KSM usage of it looks safe because it will only establish readonly
>>> ptes with it.
>>
>> Hmm, in KSM code, i found this code in replace_page:
>>
>> set_pte_at_notify(mm, addr, ptep, mk_pte(kpage, vma->vm_page_prot));
>>
>> It is possible to establish a writable pte, no?
> 
> No: we only do KSM in private vmas (!VM_SHARED), and because of the
> need to CopyOnWrite in those, vm_page_prot excludes write permission:
> write permission has to be added on COW fault.

After read the code carefully, yes, you are right. Thank you very much
for your explanation, Hugh! :)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers/dma/sirf-dma.c: fix usage of devm functions

[Julia Lawall]

On Wed, 22 Aug 2012, Barry Song wrote:


2012/8/22 Vinod Koul :

On Sat, 2012-08-04 at 10:35 +0200, Julia Lawall wrote:

From: Julia Lawall 

Fix some problems with the use of devm_ functions.

Applied, thanks


the git log "drivers/dma/sirf-dma.c: fix usage of devm functions"
should be fixed.


What do you suggest?  The patch is about problems with the use of 
devm_kzalloc, devm_ioremap, and devm_request_irq.


thanks,
julia






--
~Vinod



-barry
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] task_work: add a scheduling point in task_work_run()

[Michael Wang]

Hi, Eric

On 08/21/2012 09:05 PM, Eric Dumazet wrote:
> From: Eric Dumazet 
> 
> It seems commit 4a9d4b02 (switch fput to task_work_add) reintroduced
> the problem addressed in commit 944be0b2 (close_files(): add scheduling
> point)
> 
> If a server process with a lot of files (say 2 million tcp sockets)
> is killed, we can spend a lot of time in task_work_run() and trigger
> a soft lockup.

The thread will be rescheduled if we support kernel preempt, so this
change may only help the case we haven't enabled CONFIG_PREEMPT, isn't
it? What about using ifndef?

And can we make sure that it is safe to sleep(schedule) at this point?
It may need some totally testing to cover all the situation...

Regards,
Michael Wang

> 
> Signed-off-by: Eric Dumazet 
> ---
>  kernel/task_work.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/kernel/task_work.c b/kernel/task_work.c
> index 91d4e17..d320d44 100644
> --- a/kernel/task_work.c
> +++ b/kernel/task_work.c
> @@ -75,6 +75,7 @@ void task_work_run(void)
>   p = q->next;
>   q->func(q);
>   q = p;
> + cond_resched();
>   }
>   }
>  }
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers/dma/sirf-dma.c: fix usage of devm functions

[Barry Song]

2012/8/22 Vinod Koul :
> On Sat, 2012-08-04 at 10:35 +0200, Julia Lawall wrote:
>> From: Julia Lawall 
>>
>> Fix some problems with the use of devm_ functions.
> Applied, thanks

the git log "drivers/dma/sirf-dma.c: fix usage of devm functions"
should be fixed.

>
>
> --
> ~Vinod
>

-barry
--
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: linux-next: New tree -- linux-pstore.git

[Kees Cook]

On Tue, Aug 21, 2012 at 7:50 PM, Anton Vorontsov  wrote:
> Hello Stephen,
>
> Can you please add linux-pstore.git tree to the linux-next,
> the repository address is as follows:
>
>   git://git.infradead.org/users/cbou/linux-pstore.git master
>
> This tree is dedicated to track pstore infrastructure fixes and
> enhancements, currently it holds these commits:
>
> Anton Vorontsov (3):
>   pstore/ram: Fix possible NULL dereference
>   pstore/ram: Mark ramoops_pstore_write_buf() as notrace
>   MAINTAINERS: Add pstore maintainers
>
> Jovi Zhang (1):
>   pstore/ram: Add missing platform_device_unregister
>
> Randy Dunlap (1):
>   pstore/ram: Fix printk format warning

FWIW, Acked-by: Kees Cook  :)

-Kees

-- 
Kees Cook
Chrome OS Security
--
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: Regression associated with commit c8628155ece3 - "tcp: reduce out_of_order memory use"

[Eric Dumazet]

On Tue, 2012-08-21 at 23:07 -0500, Larry Finger wrote:
> Hi,
> 
> The commit entitled "tcp: reduce out_of_order memory use" turns out to cause 
> problems with a number of USB drivers.
> 
> The first one called to my attention was for staging/r8712u. For this driver, 
> there are problems with SSL communications as reported in 
> https://bugzilla.redhat.com/show_bug.cgi?id=847525.
> 
> Other drivers including rtl8187, rtl8192cu and rt2800usb cannot connect to a 
> WPA1- or WEP-encrypted AP, but work fine with WPA2. The rtl8192cu problem is 
> reported in https://bugzilla.kernel.org/show_bug.cgi?id=46171.
> 
> I find it hard to understand why this patch should cause these effects; 
> however, 
> I have verified that a kernel generated from "git checkout e86b2919" works 
> fine. 
> This commit is immediately before the patch in question.
> 
> Note, this patch was applied during the merge between 3.3 and 3.4. The 
> regression has been undiscovered for some time.
> 
> Any help on this problem will be appreciated.
> 
> Larry

This particular commit is the start of a patches batch that ended in the
generic TCP coalescing mechanism.

It is known to have problem on drivers doing skb_clone() in their rx
path.

Current kernels should be ok, because coalescing doesnt happen if the
destination skb is cloned (skb_cloned(to) in skb_try_coalesce())

For 3.4 kernel, I guess I need to backport this skb_cloned(to) check fo
stable 3.4 kernel

But these skb_clone() in various USB drivers should be killed for good,
they really can kill the box because of skb->truesize lies.

Please test following patch (for 3.4 kernels)

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 257b617..c45ac2d 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4496,7 +4496,9 @@ static void tcp_data_queue_ofo(struct sock *sk, struct 
sk_buff *skb)
 * to avoid future tcp_collapse_ofo_queue(),
 * probably the most expensive function in tcp stack.
 */
-   if (skb->len <= skb_tailroom(skb1) && !tcp_hdr(skb)->fin) {
+   if (skb->len <= skb_tailroom(skb1) &&
+   !skb_cloned(skb1) &&
+   !tcp_hdr(skb)->fin) {
NET_INC_STATS_BH(sock_net(sk),
 LINUX_MIB_TCPRCVCOALESCE);
BUG_ON(skb_copy_bits(skb, 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: linux-next: manual merge of the rcu tree with the tip tree

[Paul E. McKenney]

On Wed, Aug 22, 2012 at 02:27:35PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> Today's linux-next merge of the rcu tree got a conflict in
> kernel/rcutree.h between commit 62ab7072476a ("rcu: Use
> smp_hotplug_thread facility for RCUs per-CPU kthread") from the tip tree
> and commit daa5d37ff51b ("rcu: Prevent force_quiescent_state() memory
> contention") from the rcu tree.
> 
> Just context changes (I think).  I fixed it up (see below) and can carry
> the fix as necessary.

This one also looks correct.

Thanx, Paul

> -- 
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
> 
> diff --cc kernel/rcutree.h
> index 1224d4c,c2a3e7d..000
> --- a/kernel/rcutree.h
> +++ b/kernel/rcutree.h
> @@@ -196,6 -200,13 +200,7 @@@ struct rcu_node 
>   /* Refused to boost: not sure why, though. */
>   /*  This can happen due to race conditions. */
>   #endif /* #ifdef CONFIG_RCU_BOOST */
>  -struct task_struct *node_kthread_task;
>  -/* kthread that takes care of this rcu_node */
>  -/*  structure, for example, awakening the */
>  -/*  per-CPU kthreads as needed. */
>  -unsigned int node_kthread_status;
>  -/* State of node_kthread_task for tracing. */
> + raw_spinlock_t fqslock cacheline_internodealigned_in_smp;
>   } cacheline_internodealigned_in_smp;
>   
>   /*


--
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/

Power: s3c_adc_battery.c backup battery query

[anish kumar]

Hello,

I am trying to write a generic batttery driver using IIO and I have
one some below
questions:

Why do we have the representation of backup battery in this
driver(s3c_adc_battery.c) and when does the
s3c_adc_backup_bat_get_property function gets called?

As I understand, it is as this:It is called when it is registered
and when the user wants to know the backup battery status(sysfs)
and we don't do a workqueue scheduling as it will consume more power.

static struct s3c_adc_bat backup_bat = {
.psy = {
.name   = "backup-battery",
.type   = POWER_SUPPLY_TYPE_BATTERY,
.properties = s3c_adc_backup_bat_props,
.num_properties = ARRAY_SIZE(s3c_adc_backup_bat_props),
.get_property   = s3c_adc_backup_bat_get_property,
.use_for_apm= 1,
},
};

I am stuck with mulitple *get_property callbacks.As we don't know how many
batteries system has and consequently we don't know how many *get_property
callbacks to be implemented.

So below is my plan:
What I am trying to do is to have a single callback(*get_property) and manage
everything in this callback and will use the name of the psy to
distinguish between
the different batteries which system has and driver will receive this
information using
platform data.Hope it makes sense.
--
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: linux-next: manual merge of the rcu tree with the tip tree

[Paul E. McKenney]

On Wed, Aug 22, 2012 at 02:27:22PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> Today's linux-next merge of the rcu tree got a conflict in
> kernel/rcutree_plugin.h between commit 62ab7072476a ("rcu: Use
> smp_hotplug_thread facility for RCUs per-CPU kthread") from the tip tree
> and commit 8732d57a8ce0 ("rcu: Provide OOM handler to motivate lazy RCU
> callbacks") from the rcu tree.
> 
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary.

The fix looks correct to me!

Thanx, Paul

> -- 
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
> 
> diff --cc kernel/rcutree_plugin.h
> index c1961ae,c3e3fc4..000
> --- a/kernel/rcutree_plugin.h
> +++ b/kernel/rcutree_plugin.h
> @@@ -25,7 -25,7 +25,8 @@@
>*/
>   
>   #include 
>  +#include 
> + #include 
>   
>   #define RCU_KTHREAD_PRIO 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: linux-next: build failure after merge of the gpio-lw tree

[Kuninori Morimoto]

Hi Linus W

> >> >> > After merging the gpio-lw tree, today's linux-next build (x86_64
> >> >> > allmodconfig) failed like this:
> >> >> >
> >> >> > ERROR: "irq_set_chip_and_handler_name" [drivers/gpio/gpio-pcf857x.ko] 
> >> >> > undefined!
> >> >> > ERROR: "dummy_irq_chip" [drivers/gpio/gpio-pcf857x.ko] undefined!
> >> >>
> >> >> Thanks, I've dropped the offending patch, Kuninori can you look into 
> >> >> this and
> >> >> provide a new patch? It's the second patch from your patch set.
> >> >
> >> > OK. I will, but it will be next week.
> >> > And could you please show me where is your repository/branch ?
> >>
> >> http://git.kernel.org/?p=linux/kernel/git/linusw/linux-gpio.git;a=summary
> >> branch devel/for-next
> >
> > In my check, these are export symbol issue.
> > I think above 2 function/struct were not exported for module.
> >
> > Is it poosible to solve this issue by these patches ?
> 
> Hm Thomas has to answer to that (and merge the patches, if he
> likes them).

Now, these fixup patches were accepted.
  http://git.kernel.org/tip/17d83127d4c2b322dd8f217e0ac08c66eb403779
  http://git.kernel.org/tip/b3ae66f209e8929db62b5a5f874ab2cdcf5ef1d4

Could you please re-check this dropped patch ?
it was

[PATCH 2/2 v3][resend] gpio: pcf857x: enable gpio_to_irq() support
(https://lkml.org/lkml/2012/6/14/654)

I can resend this patch if you want

Best regards
---
Kuninori Morimoto
--
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/4] leds-lp5523: minor code style fixes

[Bryan Wu]

On Tue, Aug 21, 2012 at 5:04 PM, Kim, Milo  wrote:
> (a) use LP5523_ENABLE rather than magic number 0x40
> (b) use min_t() in lp5523_mux_parse()
> (c) skip while loop and just return if invalid command
>

Thanks for this cleanup. I will merge it later.

-Bryan

> Signed-off-by: Milo(Woogyom) Kim 
> ---
>  drivers/leds/leds-lp5523.c |   15 +++
>  1 files changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
> index f8231f1..64ba8b2 100644
> --- a/drivers/leds/leds-lp5523.c
> +++ b/drivers/leds/leds-lp5523.c
> @@ -177,7 +177,7 @@ static int lp5523_detect(struct i2c_client *client)
> int ret;
> u8 buf;
>
> -   ret = lp5523_write(client, LP5523_REG_ENABLE, 0x40);
> +   ret = lp5523_write(client, LP5523_REG_ENABLE, LP5523_ENABLE);
> if (ret)
> return ret;
> ret = lp5523_read(client, LP5523_REG_ENABLE, );
> @@ -338,7 +338,8 @@ static int lp5523_mux_parse(const char *buf, u16 *mux, 
> size_t len)
>  {
> int i;
> u16 tmp_mux = 0;
> -   len = len < LP5523_LEDS ? len : LP5523_LEDS;
> +
> +   len = min_t(int, len, LP5523_LEDS);
> for (i = 0; i < len; i++) {
> switch (buf[i]) {
> case '1':
> @@ -546,6 +547,9 @@ static int lp5523_do_store_load(struct lp5523_engine 
> *engine,
> unsigned cmd;
> u8 pattern[LP5523_PROGRAM_LENGTH] = {0};
>
> +   if (engine->mode != LP5523_CMD_LOAD)
> +   return -EINVAL;
> +
> while ((offset < len - 1) && (i < LP5523_PROGRAM_LENGTH)) {
> /* separate sscanfs because length is working only for %s */
> ret = sscanf(buf + offset, "%2s%n ", c, );
> @@ -563,12 +567,7 @@ static int lp5523_do_store_load(struct lp5523_engine 
> *engine,
> goto fail;
>
> mutex_lock(>lock);
> -
> -   if (engine->mode == LP5523_CMD_LOAD)
> -   ret = lp5523_load_program(engine, pattern);
> -   else
> -   ret = -EINVAL;
> -
> +   ret = lp5523_load_program(engine, pattern);
> mutex_unlock(>lock);
>
> if (ret) {
> --
> 1.7.2.5
>
>
> Best Regards,
> Milo
>
>



-- 
Bryan Wu 
Kernel Developer+86.186-168-78255 Mobile
Canonical Ltd.  www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/4] leds-lp5523: change the return type of lp5523_set_mode()

[Bryan Wu]

On Tue, Aug 21, 2012 at 5:03 PM, Kim, Milo  wrote:
> The return value of this function is not handled any place, so
> make it as void type.
>
> And three if-statements are replaced with switch-statements.
>

This one looks fine with me. I will merge it after you rework on first 2 patches

Thanks,
-Bryan

> Signed-off-by: Milo(Woogyom) Kim 
> ---
>  drivers/leds/leds-lp5523.c |   24 +---
>  1 files changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
> index f090819..f8231f1 100644
> --- a/drivers/leds/leds-lp5523.c
> +++ b/drivers/leds/leds-lp5523.c
> @@ -150,7 +150,7 @@ static inline struct lp5523_chip *led_to_lp5523(struct 
> lp5523_led *led)
> leds[led->id]);
>  }
>
> -static int lp5523_set_mode(struct lp5523_engine *engine, u8 mode);
> +static void lp5523_set_mode(struct lp5523_engine *engine, u8 mode);
>  static int lp5523_set_engine_mode(struct lp5523_engine *engine, u8 mode);
>  static int lp5523_load_program(struct lp5523_engine *engine, const u8 
> *pattern);
>
> @@ -789,26 +789,28 @@ static void lp5523_unregister_sysfs(struct i2c_client 
> *client)
>  /*--*/
>  /* Set chip operating mode */
>  /*--*/
> -static int lp5523_set_mode(struct lp5523_engine *engine, u8 mode)
> +static void lp5523_set_mode(struct lp5523_engine *engine, u8 mode)
>  {
> -   int ret = 0;
> -
> /* if in that mode already do nothing, except for run */
> if (mode == engine->mode && mode != LP5523_CMD_RUN)
> -   return 0;
> +   return;
>
> -   if (mode == LP5523_CMD_RUN) {
> -   ret = lp5523_run_program(engine);
> -   } else if (mode == LP5523_CMD_LOAD) {
> +   switch (mode) {
> +   case LP5523_CMD_RUN:
> +   lp5523_run_program(engine);
> +   break;
> +   case LP5523_CMD_LOAD:
> lp5523_set_engine_mode(engine, LP5523_CMD_DISABLED);
> lp5523_set_engine_mode(engine, LP5523_CMD_LOAD);
> -   } else if (mode == LP5523_CMD_DISABLED) {
> +   break;
> +   case LP5523_CMD_DISABLED:
> lp5523_set_engine_mode(engine, LP5523_CMD_DISABLED);
> +   break;
> +   default:
> +   return;
> }
>
> engine->mode = mode;
> -
> -   return ret;
>  }
>
>  /*--*/
> --
> 1.7.2.5
>
>
> Best Regards,
> Milo
>
>



-- 
Bryan Wu 
Kernel Developer+86.186-168-78255 Mobile
Canonical Ltd.  www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/4] pinctrl: add samsung pinctrl and gpiolib driver

[Thomas Abraham]

On 22 August 2012 03:08, Stephen Warren  wrote:
> On 08/21/2012 05:25 AM, Linus Walleij wrote:
>> On Wed, Aug 15, 2012 at 9:57 PM, Thomas Abraham
>>  wrote:
>>
>>> Add a new device tree enabled pinctrl and gpiolib driver for Samsung
>>> SoC's.
> ...
>>> +  The child node can also optionally specify one or more of the pin
>>> +  configuration that should be applied on all the pins listed in the
>>> +  "samsung,pins" property of the child node. The following pin 
>>> configuration
>>> +  properties are supported.
>>> +
>>> +  - samsung,pin-pud: Pull up/down configuration.
>>> +  - samsung,pin-drv: Drive strength configuration.
>>> +  - samsung,pin-pud-pdn: Pull up/down configuration in power down mode.
>>> +  - samsung,pin-drv-pdn: Drive strength configuration in power down mode.
>>
>> This looks a bit scary, as it seems to be orthogonal to the pin config
>> interface. I.e. this will be programmed "behind the back" of the
>> pin config system. However as long as the pin config implementation
>> reads back these things from the registers it will work, too.
>>
>> In the U300 and Ux500 I explicitly use pin config hogs to set up
>> the pin configuration, and when we enter a state such as
>> "default" the mux setting and config settings are set from the
>> framework separately.
>
> I know that some HW has a separate set of registers (or fields) for the
> "awake" and "sleep" configuration, and the HW switches between the two
> automatically when sleeping. I have no idea if the Samsung SoCs do this,
> but I think if this were the case, it'd be quite legitimate to define
> both these HW states as separate sets of properties within a single
> pinctrl SW state. So, that might be the explanation here?
>

Hi Stephen,

Yes, Samsung SoC support the "awake" and "sleep" configuration in that
way you described.

Thanks,
Thomas.
--
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: [ 04/16] drm/i915: correctly order the ring init sequence

[Herton Ronaldo Krzesinski]

On Tue, Aug 21, 2012 at 06:55:30PM +0200, Daniel Vetter wrote:
> On Tue, Aug 21, 2012 at 3:11 PM, Herton Ronaldo Krzesinski
>  wrote:
> > On Tue, Aug 21, 2012 at 08:42:35AM +0200, Daniel Vetter wrote:
> >> On Tue, Aug 21, 2012 at 7:13 AM, Herton Ronaldo Krzesinski
> >>  wrote:
> >> > I had the same problem as on 3.2 with this change, i915 stopped working
> >> > unable to initialize render ring, eg. on one of the boots here:
> >> > [drm:init_ring_common] *ERROR* render ring initialization failed ctl 
> >> > 0001f003 head 1020 tail  start 1000
> >> >
> >> > But unlike I was expecting as with 3.2 case, picking commit
> >> > f01db988ef6f6c70a6cc36ee71e4a98a68901229 ("drm/i915: Add wait_for in
> >> > init_ring_common") here isn't enough, it continues to fail even if I
> >> > try to increase the delay in the wait_for, I'm not sure why yet... may
> >> > be something else is going on, or 3.0 has something else missing.
> >> >
> >> > Also the same proposed patch for 3.4.10 gives the same problem, but
> >> > picking f01db988ef6f6c70a6cc36ee71e4a98a68901229 there made things work
> >> > again like happend on first 3.2.28 proposed update. Only 3.0
> >> > is misteriously failing either way here.
> >>
> >> I guess we're missing something then still in the stable backports for
> >> 3.0. Herton, what machine do you have exaclty (lspci -nn)?
> >
> > It's a G41 based board:
> 
> Hm, I've reviewed git log and bug reports and I have no idea what's
> missing on 3.0. I guess the best course of action is to not apply this
> patch to 3.0 stable - it fixes an ivb issue anyway, and 3.0 is a
> rather old kernel for ivb support anyway (we generally recommend 3.2.x
> for ivb).
> -Daniel

Yeah, 3.0 being old, if it was only for ivb, supported only later, makes
sense. I continued investigating this today, and some things are looking
very strange to me. Here is what I discovered and narrowed down so far:

* There is difference of behaviour depending on which environment I
  build 3.0: Originally I built the 3.0 kernel on Ubuntu Oneiric, gcc is
  4.6.1, binutils 2.21.53.20110810 (I'm just saying the versions, not sure
  if it makes a difference or not, and the distro toolchain usually is
  patched so the versions may not mean much). Then I tried building the
  3.0 kernel on a newer environment/distro version, Ubuntu Precise, gcc is
  4.6.3, binutils 2.22.
- Building the stock 3.0.42 proposed kernel on both Ubuntu distros
  (Oneiric and Precise), and testing them, I get the same render ring
  initialization failure.
- Building 3.0.42 with commit f01db988ef6f6c70a6cc36ee71e4a98a68901229
  picked on top gives a different result though: The kernel built on
  Oneiric continues to fail, while the one built on Precise then works.
This was very weird, and I suspected of the toolchain. But the generated
assembly is the same, I also compared the objdump output of the built
i915 module, and there were no differences in the init_common_ring
function. There were some differences in other places, but no difference
in the section of code patched between the working case to the
non-working case. Really didn't made sense, and probably something else
is going on, related to code size or timing or alignment somewhere, I
don't know, but I was unable yet to detect really what's the cause.

I also noticed something else. I started to patch the init_ring_common
function reading back and printing the render ring buffer pointer
values that were being set, with the attached patch, and building the
kernel on the environment which the bug happens (Oneiric). This is the
relevant output I got, I numbered by hand to comment after:

1)
[   34.872786] i915: ctl  head  tail  start 
[   34.872789] i915: ctl  head  tail  start 
[   34.872792] i915: ctl  head  tail  start 
[   34.872793] i915: head = 
[   34.872795] i915: ctl  head  tail  start 
2)
[   34.872797] i915: head = 1000
[   34.872798] i915: ctl  head 1000 tail  start 1000
3)
[   35.880034] i915: timeout
[   35.936111] [drm:init_ring_common] *ERROR* render ring initialization failed 
ctl 0001f003 head 7cc4 tail  start 1000
[   35.936174] i915: 0001 1000 7cc4
[   35.936229] vga_switcheroo: disabled
[   35.936232] [drm:i915_driver_load] *ERROR* failed to init modeset
[   35.954182] i915 :00:02.0: PCI INT A disabled
[   35.954188] i915: probe of :00:02.0 failed with error -5

1) At first run, the render ring buffer is "stopped", everything is
zero. The zeros written to ctl, head and tail changes nothing, everything
stays zero, as expected.

2) These are the values read after I915_WRITE_START runs. For some
reason on this machine here, after start address was written, the head
is set the same as the start (?), and this is the root of the failing
case here. I was reading the documentation, and it says when 

Re: [PATCH v2 4/4] ARM: EXYNOS: skip wakeup interrupt setup if pinctrl driver is used

[Thomas Abraham]

On 21 August 2012 17:34, Linus Walleij  wrote:
> On Wed, Aug 15, 2012 at 9:57 PM, Thomas Abraham
>  wrote:
>
>> Pinctrl driver includes support for configuring the external wakeup
>> interrupts. On exynos platforms that use pinctrl driver, the setup
>> of wakeup interrupts in the exynos platform code can be skipped.
>>
>> Cc: Kukjin Kim 
>> Signed-off-by: Thomas Abraham 
>
>> +#ifdef CONFIG_OF
>
> Don't you actually want to use:
>
> #fidef CONFIG_PINCTRL_SAMSUNG
>
> here? CONFIG_OF is a bit vague.

Ok. I will use CONFIG_PINCTRL_SAMSUNG here.

>
> Yours,
> Linus Walleij

Thanks,
Thomas.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 3/4] gpio: exynos4: skip gpiolib registration if pinctrl driver is used

[Thomas Abraham]

On 21 August 2012 17:35, Linus Walleij  wrote:
> On Wed, Aug 15, 2012 at 9:57 PM, Thomas Abraham
>  wrote:
>
>> Pinctrl driver, when enabled, registers all the gpio pins and hence the
>> registration of gpio pins by this driver can be skipped.
>>
>> Acked-by: Grant Likely 
>> Acked-by: Linus Walleij 
>> Signed-off-by: Thomas Abraham 
>
>> +#ifdef CONFIG_OF
>
> Wouldn't it be better to use
> #ifdef CONFIG_PINCTRL_SAMSUNG?

Yes, this would be better. I will fix this.

>
> Yours,
> Linus Walleij

Thanks,
Thomas.
--
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] mmc: core: Add a capability for disabling mmc cards

[Jaehoon Chung]

Hi Doug,

I didn't know what purpose is.
Why need to add the MMC_CAP2_NO_MMC?
If card is SD or SDIO, mmc_attach_mmc(host) should not be entered.
Could you explain to me in more detail?

Best Regards,
Jaehoon Chung

On 08/22/2012 01:05 PM, Doug Anderson wrote:
> On some systems we need a way to disable MMC card support in a MMC/SD
> card slot.  Add support in the core SD/MMC code to support this.
> 
> Signed-off-by: Doug Anderson 
> Signed-off-by: Alim Akhtar 
> ---
>  drivers/mmc/core/core.c  |2 +-
>  include/linux/mmc/host.h |1 +
>  2 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 8ac5246..3214972 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -1981,7 +1981,7 @@ static int mmc_rescan_try_freq(struct mmc_host *host, 
> unsigned freq)
>   return 0;
>   if (!mmc_attach_sd(host))
>   return 0;
> - if (!mmc_attach_mmc(host))
> + if (!(host->caps2 & MMC_CAP2_NO_MMC) && !mmc_attach_mmc(host))
>   return 0;
>  
>   mmc_power_off(host);
> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> index f578a71..f36370e 100644
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -257,6 +257,7 @@ struct mmc_host {
>  #define MMC_CAP2_HC_ERASE_SZ (1 << 9)/* High-capacity erase size */
>  #define MMC_CAP2_CD_ACTIVE_HIGH  (1 << 10)   /* Card-detect signal 
> active high */
>  #define MMC_CAP2_RO_ACTIVE_HIGH  (1 << 11)   /* Write-protect signal 
> active high */
> +#define MMC_CAP2_NO_MMC  (1 << 12)   /* Only SD supported, 
> not MMC */
>  
>   mmc_pm_flag_t   pm_caps;/* supported pm features */
>   unsigned intpower_notify_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 v2 2/4] pinctrl: add exynos4210 specific extensions for samsung pinctrl driver

[Thomas Abraham]

On 21 August 2012 17:32, Linus Walleij  wrote:
> On Wed, Aug 15, 2012 at 9:57 PM, Thomas Abraham
>  wrote:
>
>> Add information about the Exynos4210 pin banks and driver data which is
>> used by the Samsung pinctrl driver. In addition to this, the support for
>> external gpio and wakeup interrupt support is included and hooked up with
>> the Samsung pinctrl driver.
>
> OK...
>
>> diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
>> +config PINCTRL_EXYNOS4
>> +   bool "Pinctrl driver data for Exynos4 SoC"
>> +   depends on ARCH_EXYNOS4 && OF
>
> Since you depend on PINCTRL_SAMSUNG which depends
> on OF you don't need to depend on OF here.

Ok.

>
>> +   depends on PINCTRL_SAMSUNG
>> +   select PINMUX
>> +   select PINCONF
>
> So as noted in the main driver, let PINCTRL_SAMSUNG
> select PINMUX and PINCONF and you need only select
> PINCTRL_SAMSUNG here.

Ok.

>
>> diff --git a/drivers/pinctrl/pinctrl-exynos.c 
>> b/drivers/pinctrl/pinctrl-exynos.c
> (...)
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>
> Do you need these includes? Didn't you put them
> all in "pinctrl-samsung.h"?

Yes, I will fix this.

>
> Overall this looks good and straight-forward, but I cannot figure
> out how the samsung_pinctrl_soc_data is passed to the main
> driver, it seems to be through some DT node but I cannot figure
> this out. Can you explain this?

The main driver uses the .data field of the of_device_id structure to
pass the pointer of the SoC data. So, upon match of a compatible value
which is supported by the main driver with that in dt, the
of_match_node() call can be used to find out the corresponding SoC
data. There are included in the first patch (reference:
samsung_pinctrl_get_soc_data() function and samsung_pinctrl_dt_mach
structure).

>
> Yours,
> Linus Walleij

Thanks,
Thomas.
--
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] crypto: twofish - add x86_64/avx assembler implementation

[Jussi Kivilinna]

Quoting Borislav Petkov :

> 
> Here you go:
> 
> [   52.282208]
> [   52.282208] testing speed of async ecb(twofish) encryption

Thanks!

Looks that encryption lost ~0.4% while decryption gained ~1.8%.

For 256 byte test, it's still slightly slower than twofish-3way (~3%). For 1k
and 8k tests, it's ~5% faster.

Here's very last test-patch, testing different ordering of fpu<->cpu reg
instructions at few places.

---
 arch/x86/crypto/twofish-avx-x86_64-asm_64.S |  232 ++-
 1 file changed, 154 insertions(+), 78 deletions(-)

diff --git a/arch/x86/crypto/twofish-avx-x86_64-asm_64.S 
b/arch/x86/crypto/twofish-avx-x86_64-asm_64.S
index 35f4557..693963a 100644
--- a/arch/x86/crypto/twofish-avx-x86_64-asm_64.S
+++ b/arch/x86/crypto/twofish-avx-x86_64-asm_64.S
@@ -4,6 +4,8 @@
  * Copyright (C) 2012 Johannes Goetzfried
  * 
  *
+ * Copyright © 2012 Jussi Kivilinna 
+ *
  * 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
@@ -47,16 +49,21 @@
 #define RC2 %xmm6
 #define RD2 %xmm7
 
-#define RX %xmm8
-#define RY %xmm9
+#define RX0 %xmm8
+#define RY0 %xmm9
+
+#define RX1 %xmm10
+#define RY1 %xmm11
+
+#define RK1 %xmm12
+#define RK2 %xmm13
 
-#define RK1 %xmm10
-#define RK2 %xmm11
+#define RT %xmm14
 
-#define RID1  %rax
-#define RID1b %al
-#define RID2  %rbx
-#define RID2b %bl
+#define RID1  %rbp
+#define RID1d %ebp
+#define RID2  %rsi
+#define RID2d %esi
 
 #define RGI1   %rdx
 #define RGI1bl %dl
@@ -65,6 +72,13 @@
 #define RGI2bl %cl
 #define RGI2bh %ch
 
+#define RGI3   %rax
+#define RGI3bl %al
+#define RGI3bh %ah
+#define RGI4   %rbx
+#define RGI4bl %bl
+#define RGI4bh %bh
+
 #define RGS1  %r8
 #define RGS1d %r8d
 #define RGS2  %r9
@@ -73,40 +87,58 @@
 #define RGS3d %r10d
 
 
-#define lookup_32bit(t0, t1, t2, t3, src, dst) \
-   movbsrc ## bl,RID1b; \
-   movbsrc ## bh,RID2b; \
+#define lookup_32bit(t0, t1, t2, t3, src, dst, interleave_op, il_reg) \
+   movzbl  src ## bl,RID1d; \
+   movzbl  src ## bh,RID2d; \
+   shrq $16,   src; \
movlt0(CTX, RID1, 4), dst ## d;  \
xorlt1(CTX, RID2, 4), dst ## d;  \
-   shrq $16,   src; \
-   movbsrc ## bl,RID1b; \
-   movbsrc ## bh,RID2b; \
+   movzbl  src ## bl,RID1d; \
+   movzbl  src ## bh,RID2d; \
+   interleave_op(il_reg);   \
xorlt2(CTX, RID1, 4), dst ## d;  \
xorlt3(CTX, RID2, 4), dst ## d;
 
-#define G(a, x, t0, t1, t2, t3) \
-   vmovq   a,RGI1;   \
-   vpsrldq $8, a,x;  \
-   vmovq   x,RGI2;   \
-   \
-   lookup_32bit(t0, t1, t2, t3, RGI1, RGS1); \
-   shrq $16,   RGI1; \
-   lookup_32bit(t0, t1, t2, t3, RGI1, RGS2); \
-   shlq $32,   RGS2; \
-   orq RGS1, RGS2;   \
-   \
-   lookup_32bit(t0, t1, t2, t3, RGI2, RGS1); \
-   shrq $16,   RGI2; \
-   lookup_32bit(t0, t1, t2, t3, RGI2, RGS3); \
-   shlq $32,   RGS3; \
-   orq RGS1, RGS3;   \
-   \
-   vmovq   RGS2, x;  \
-   vpinsrq $1, RGS3, x, x;
+#define dummy(d) /* do nothing */
 
-#define encround(a, b, c, d, x, y) \
-   G(a, x, s0, s1, s2, s3);   \
-   G(b, y, s1, s2, s3, s0);   \
+#define shr_next(reg) \
+   shrq $16,   reg;
+
+#define G_enc(gi1, gi2, x, t0, t1, t2, t3) \
+   lookup_32bit(t0, t1, t2, t3, ##gi1, RGS1, shr_next, ##gi1);  \
+   lookup_32bit(t0, t1, t2, t3, ##gi1, RGS2, dummy, none);  \
+   shlq $32,   RGS2;\
+   orq RGS1, RGS2;  \
+   \
+   lookup_32bit(t0, t1, t2, t3, ##gi2, RGS3, shr_next, ##gi2);  \
+   lookup_32bit(t0, t1, t2, t3, ##gi2, RGS1, dummy, none);  \
+   shlq $32,   RGS1;\
+   orq RGS1, RGS3;
+
+#define encround_head_2(a, b, c, d, x1, y1, x2, y2) \
+   vmovq   b ## 1, RGI3;   \
+   vpextrq $1, b ## 1, RGI4;   \
+   G_enc(RGI1, RGI2, x1, s0, s1, s2, s3);  \
+   vmovq   a ## 2, RGI1;   \
+   vpextrq $1, a ## 2, RGI2;   \
+   vmovq   RGS2, x1;   \
+   vpinsrq $1, RGS3, x1, x1;   \
+   G_enc(RGI3, RGI4, y1, s1, s2, s3, s0);  \
+   vmovq   b ## 2, RGI3;   \
+  

linux-next: manual merge of the rcu tree with the tip tree

[Stephen Rothwell]

Hi Paul,

Today's linux-next merge of the rcu tree got a conflict in
kernel/rcutree.h between commit 62ab7072476a ("rcu: Use
smp_hotplug_thread facility for RCUs per-CPU kthread") from the tip tree
and commit daa5d37ff51b ("rcu: Prevent force_quiescent_state() memory
contention") from the rcu tree.

Just context changes (I think).  I fixed it up (see below) and can carry
the fix as necessary.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc kernel/rcutree.h
index 1224d4c,c2a3e7d..000
--- a/kernel/rcutree.h
+++ b/kernel/rcutree.h
@@@ -196,6 -200,13 +200,7 @@@ struct rcu_node 
/* Refused to boost: not sure why, though. */
/*  This can happen due to race conditions. */
  #endif /* #ifdef CONFIG_RCU_BOOST */
 -  struct task_struct *node_kthread_task;
 -  /* kthread that takes care of this rcu_node */
 -  /*  structure, for example, awakening the */
 -  /*  per-CPU kthreads as needed. */
 -  unsigned int node_kthread_status;
 -  /* State of node_kthread_task for tracing. */
+   raw_spinlock_t fqslock cacheline_internodealigned_in_smp;
  } cacheline_internodealigned_in_smp;
  
  /*


pgpB7WC3i9BNf.pgp
Description: PGP signature

linux-next: manual merge of the rcu tree with the tip tree

[Stephen Rothwell]

Hi Paul,

Today's linux-next merge of the rcu tree got a conflict in
kernel/rcutree_plugin.h between commit 62ab7072476a ("rcu: Use
smp_hotplug_thread facility for RCUs per-CPU kthread") from the tip tree
and commit 8732d57a8ce0 ("rcu: Provide OOM handler to motivate lazy RCU
callbacks") from the rcu tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc kernel/rcutree_plugin.h
index c1961ae,c3e3fc4..000
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@@ -25,7 -25,7 +25,8 @@@
   */
  
  #include 
 +#include 
+ #include 
  
  #define RCU_KTHREAD_PRIO 1
  


pgp7wIABzTgUz.pgp
Description: PGP signature

Re: [PATCH 2/5] drivers/dma/amba-pl08x.c: fix error return code

[Vinod Koul]

On Tue, 2012-08-14 at 14:58 +0200, Julia Lawall wrote:
> From: Julia Lawall 
> 
> Convert a 0 error return code to a negative one, as returned elsewhere in the
> function.
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: Regression associated with commit c8628155ece3 - "tcp: reduce out_of_order memory use"

[David Miller]

From: Larry Finger 
Date: Tue, 21 Aug 2012 23:07:46 -0500

> I find it hard to understand why this patch should cause these
> effects; however, I have verified that a kernel generated from "git
> checkout e86b2919" works fine. This commit is immediately before the
> patch in question.

I can guarentee it's improper skb->truesize setting in these drivers,
or use of too huge buffer sizes compared to the amount of data
contained within the packet.
--
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: linux-next: Tree for July 17 (mfd/tps65217.c)

[AnilKumar, Chimata]

Hi Samuel,

On Tue, Aug 21, 2012 at 23:21:37, Randy Dunlap wrote:
> On 08/05/2012 11:38 PM, AnilKumar, Chimata wrote:
> 
> > On Fri, Aug 03, 2012 at 22:58:01, Randy Dunlap wrote:
> >> On 07/17/2012 02:48 PM, Randy Dunlap wrote:
> >>
> >>> On 07/16/2012 10:41 PM, Stephen Rothwell wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> Changes since 20120716:
> >>>>
> >>>
> >>>
> >>> on i386:
> >>>
> >>> drivers/built-in.o: In function `tps65217_probe':
> >>> tps65217.c:(.devinit.text+0x13e37): undefined reference to 
> >>> `of_regulator_match'
> >>>
> >>>
> >>> Full randconfig file is attached.
> >>> CONFIG_REGULATOR is not enabled.
> >>>
> >>
> >>
> >> This build error is still present in linux-next of 20120803.
> >>
> > 
> > This will be fixed with this patch
> > https://patchwork.kernel.org/patch/1220151/
> > 
> > Today, I will submit v2 for this
> 
> 
> This build still fails in linux-next 20120821.

Could you please push this patch ASAP?
http://www.spinics.net/lists/linux-omap/msg75336.html

Thanks
AnilKumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/4] pinctrl: add samsung pinctrl and gpiolib driver

[Thomas Abraham]

Hi Linus,

Thanks for your time to review the Samsung pinctrl driver patches. I
have inlined the reply to your comments.

On 21 August 2012 16:55, Linus Walleij  wrote:
> On Wed, Aug 15, 2012 at 9:57 PM, Thomas Abraham
>  wrote:
>
>> Add a new device tree enabled pinctrl and gpiolib driver for Samsung
>> SoC's.
>
> Thanks for doing this Thomas, great work!
>
>> +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
>
> I don't understand the rules around bindings very well, I would
> suggest you include
> devicetree-disc...@lists.ozlabs.org on the mails, besides you know
> this stuff way
> better than me anyway :-)

Yes, I missed Cc'ing devicetree-disc...@lists.ozlabs.org. I will do
that in the post of this patch set.

>
>> +  The child node can also optionally specify one or more of the pin
>> +  configuration that should be applied on all the pins listed in the
>> +  "samsung,pins" property of the child node. The following pin configuration
>> +  properties are supported.
>> +
>> +  - samsung,pin-pud: Pull up/down configuration.
>> +  - samsung,pin-drv: Drive strength configuration.
>> +  - samsung,pin-pud-pdn: Pull up/down configuration in power down mode.
>> +  - samsung,pin-drv-pdn: Drive strength configuration in power down mode.
>
> This looks a bit scary, as it seems to be orthogonal to the pin config
> interface. I.e. this will be programmed "behind the back" of the
> pin config system. However as long as the pin config implementation
> reads back these things from the registers it will work, too.

These properties are converted to a PIN_MAP_TYPE_CONFIGS_GROUP map
type and stored in a instance of 'struct pinctrl_map'. These can be
read back from the registers and reverse-mapped as well.

All the dt bindings defined and used in the Samsung pinctrl driver are
first translated into pinctrl subystem defined data structures and
then used. Hence, there are no register configurations done that skip
over the pinctrl subsystem (except for the gpio/wakeup interrupts).

>
> In the U300 and Ux500 I explicitly use pin config hogs to set up
> the pin configuration, and when we enter a state such as
> "default" the mux setting and config settings are set from the
> framework separately.
>
> See for example:
> arch/arm/mach-ux500/board-mop500-pins.c
>
> This example is using platform data but it should be trivial to do with
> device tree.
>
> I think the Tegra also works this way. Can you elaborate on
> why you need this static setup from the device tree instead
> of using default states?

Sorry, I did not understand this question.

>
> I also think this looks like it could use generic pin config to stash
> the configs, just expand the stuff in 
>
> (...)
>> +Example 1:
>
> The examples seem to only pertain to the pin controller per se, maybe you
> could include a DT entry for a uart or something showing how the
> uart device binds to a certain pinctrl setting.

Yes, such an example will be informative here. I will add an example for this.

>
>> +   pinctrl_0: pinctrl@1140 {
>> +   compatible = "samsung,pinctrl-exynos4210";
>> +   reg = <0x1140 0x1000>;
>> +   interrupts = <0 47 0>;
>> +
>> +   uart0_data: uart0-data {
>> +   samsung,pins = "gpa0-0", "gpa0-1";
>> +   samsung,pin-function = <2>;
>> +   samsung,pin-pud = <0>;
>> +   samsung,pin-drv = <0>;
>> +   };
>
> This setup needs to be associated with a certain state, it's possible to
> do in the code or directly in the device tree.
>
> I.e. these settings for pin-pud and pin-drv needs to belong to a
> certain pin config state, typically the state named "default"

Yes, I agree. So, for example, the uart device node would have

uart@1380 {
   compatilble = "  ";
   

   pinctrl-names = "default";
   pinctrl-0 - <_data>;
};

The uart driver during probe can then call

   devm_pinctrl_get_select_default(>dev);

For the example above, this call will set the 'mux', 'pud' and 'drv'
values to gpa-0 and gpa-1 pins.

>
>> diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
>
>> +config PINCTRL_SAMSUNG
>> +   bool "Samsung pinctrl driver"
>> +   depends on OF
>
> I don't understand how this can even compile. Do you need:
>
> select PINMUX
> select PINCONF
>
> to get the framework files you need to compile?
>
> Or are you selecting thes in some platform Kconfig or so?
> In that case please move them here.

These were selected if PINCTRL_EXYNOS4 config option is selected. This
is in the 2/4 patch of this series. But, as you said, PINMUX and
PINCONF should be selected with PINCTRL_SAMSUNG config option. I will
fix this.

>
>> +/* list of all possible config options supported */
>> +struct pin_config {
>> +   char  

Re: [PATCH] drivers/dma/sirf-dma.c: fix usage of devm functions

[Vinod Koul]

On Sat, 2012-08-04 at 10:35 +0200, Julia Lawall wrote:
> From: Julia Lawall 
> 
> Fix some problems with the use of devm_ functions.
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] mm: mmu_notifier: fix inconsistent memory between secondary MMU and host

[Hugh Dickins]

On Wed, 22 Aug 2012, Xiao Guangrong wrote:
> On 08/21/2012 11:06 PM, Andrea Arcangeli wrote:
> > 
> > The KSM usage of it looks safe because it will only establish readonly
> > ptes with it.
> 
> Hmm, in KSM code, i found this code in replace_page:
> 
> set_pte_at_notify(mm, addr, ptep, mk_pte(kpage, vma->vm_page_prot));
> 
> It is possible to establish a writable pte, no?

No: we only do KSM in private vmas (!VM_SHARED), and because of the
need to CopyOnWrite in those, vm_page_prot excludes write permission:
write permission has to be added on COW fault.

Hugh
--
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/

Regression associated with commit c8628155ece3 - "tcp: reduce out_of_order memory use"

[Larry Finger]

Hi,

The commit entitled "tcp: reduce out_of_order memory use" turns out to cause 
problems with a number of USB drivers.


The first one called to my attention was for staging/r8712u. For this driver, 
there are problems with SSL communications as reported in 
https://bugzilla.redhat.com/show_bug.cgi?id=847525.


Other drivers including rtl8187, rtl8192cu and rt2800usb cannot connect to a 
WPA1- or WEP-encrypted AP, but work fine with WPA2. The rtl8192cu problem is 
reported in https://bugzilla.kernel.org/show_bug.cgi?id=46171.


I find it hard to understand why this patch should cause these effects; however, 
I have verified that a kernel generated from "git checkout e86b2919" works fine. 
This commit is immediately before the patch in question.


Note, this patch was applied during the merge between 3.3 and 3.4. The 
regression has been undiscovered for some time.


Any help on this problem will be appreciated.

Larry
--
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: ext4 write performance regression in 3.6-rc1 on RAID0/5

[Shaohua Li]

On 8/22/12 11:57 AM, Yuanhan Liu wrote:

 On Fri, Aug 17, 2012 at 10:25:26PM +0800, Fengguang Wu wrote:
> [CC md list]
>
> On Fri, Aug 17, 2012 at 09:40:39AM -0400, Theodore Ts'o wrote:
>> On Fri, Aug 17, 2012 at 02:09:15PM +0800, Fengguang Wu wrote:
>>> Ted,
>>>
>>> I find ext4 write performance dropped by 3.3% on average in the
>>> 3.6-rc1 merge window. xfs and btrfs are fine.
>>>
>>> Two machines are tested. The performance regression happens in the
>>> lkp-nex04 machine, which is equipped with 12 SSD drives. lkp-st02 does
>>> not see regression, which is equipped with HDD drives. I'll continue
>>> to repeat the tests and report variations.
>>
>> Hmm... I've checked out the commits in "git log v3.5..v3.6-rc1 --
>> fs/ext4 fs/jbd2" and I don't see anything that I would expect would
>> cause that. The are the lock elimination changes for Direct I/O
>> overwrites, but that shouldn't matter for your tests which are
>> measuring buffered writes, correct?
>>
>> Is there any chance you could do me a favor and do a git bisect
>> restricted to commits involving fs/ext4 and fs/jbd2?
>
> I noticed that the regressions all happen in the RAID0/RAID5 cases.
> So it may be some interactions between the RAID/ext4 code?
>
> I'll try to get some ext2/3 numbers, which should have less changes 

on the fs side.

>
> wfg@bee /export/writeback% ./compare -g ext4 

lkp-nex04/*/*-{3.5.0,3.6.0-rc1+}

> 3.5.0 3.6.0-rc1+
>  
> 720.62 -1.5% 710.16 lkp-nex04/JBOD-12HDD-thresh=1000M/ext4-100dd-1-3.5.0
> 706.04 -0.0% 705.86 lkp-nex04/JBOD-12HDD-thresh=1000M/ext4-10dd-1-3.5.0
> 702.86 -0.2% 701.74 lkp-nex04/JBOD-12HDD-thresh=1000M/ext4-1dd-1-3.5.0
> 702.41 -0.0% 702.06 lkp-nex04/JBOD-12HDD-thresh=1000M/ext4-1dd-2-3.5.0
> 779.52 +6.5% 830.11 lkp-nex04/JBOD-12HDD-thresh=100M/ext4-100dd-1-3.5.0
> 646.70 +4.9% 678.59 lkp-nex04/JBOD-12HDD-thresh=100M/ext4-10dd-1-3.5.0
> 704.49 +2.6% 723.00 lkp-nex04/JBOD-12HDD-thresh=100M/ext4-1dd-1-3.5.0
> 704.21 +1.2% 712.47 lkp-nex04/JBOD-12HDD-thresh=100M/ext4-1dd-2-3.5.0
> 705.26 -1.2% 696.61 lkp-nex04/JBOD-12HDD-thresh=8G/ext4-100dd-1-3.5.0
> 703.37 +0.1% 703.76 lkp-nex04/JBOD-12HDD-thresh=8G/ext4-10dd-1-3.5.0
> 701.66 -0.1% 700.83 lkp-nex04/JBOD-12HDD-thresh=8G/ext4-1dd-1-3.5.0
> 701.17 +0.0% 701.36 lkp-nex04/JBOD-12HDD-thresh=8G/ext4-1dd-2-3.5.0
> 675.08 -10.5% 604.29 

lkp-nex04/RAID0-12HDD-thresh=1000M/ext4-100dd-1-3.5.0

> 676.52 -2.7% 658.38 lkp-nex04/RAID0-12HDD-thresh=1000M/ext4-10dd-1-3.5.0
> 512.70 +4.0% 533.22 lkp-nex04/RAID0-12HDD-thresh=1000M/ext4-1dd-1-3.5.0
> 524.61 -0.3% 522.90 lkp-nex04/RAID0-12HDD-thresh=1000M/ext4-1dd-2-3.5.0
> 709.76 -15.7% 598.44 lkp-nex04/RAID0-12HDD-thresh=100M/ext4-100dd-1-3.5.0
> 681.39 -2.1% 667.25 lkp-nex04/RAID0-12HDD-thresh=100M/ext4-10dd-1-3.5.0
> 524.16 +0.8% 528.25 lkp-nex04/RAID0-12HDD-thresh=100M/ext4-1dd-2-3.5.0
> 699.77 -19.2% 565.54 lkp-nex04/RAID0-12HDD-thresh=8G/ext4-100dd-1-3.5.0
> 675.79 -1.9% 663.17 lkp-nex04/RAID0-12HDD-thresh=8G/ext4-10dd-1-3.5.0
> 484.84 -7.4% 448.83 lkp-nex04/RAID0-12HDD-thresh=8G/ext4-1dd-1-3.5.0
> 470.40 -3.2% 455.31 lkp-nex04/RAID0-12HDD-thresh=8G/ext4-1dd-2-3.5.0
> 167.97 -38.7% 103.03 

lkp-nex04/RAID5-12HDD-thresh=1000M/ext4-100dd-1-3.5.0

> 243.67 -9.1% 221.41 lkp-nex04/RAID5-12HDD-thresh=1000M/ext4-10dd-1-3.5.0
> 248.98 +12.2% 279.33 lkp-nex04/RAID5-12HDD-thresh=1000M/ext4-1dd-1-3.5.0
> 208.45 +14.1% 237.86 lkp-nex04/RAID5-12HDD-thresh=1000M/ext4-1dd-2-3.5.0
> 71.18 -34.2% 46.82 lkp-nex04/RAID5-12HDD-thresh=100M/ext4-100dd-1-3.5.0
> 145.84 -7.3% 135.25 lkp-nex04/RAID5-12HDD-thresh=100M/ext4-10dd-1-3.5.0
> 255.22 +6.7% 272.35 lkp-nex04/RAID5-12HDD-thresh=100M/ext4-1dd-1-3.5.0
> 243.09 +20.7% 293.30 lkp-nex04/RAID5-12HDD-thresh=100M/ext4-1dd-2-3.5.0
> 209.24 -23.6% 159.96 lkp-nex04/RAID5-12HDD-thresh=8G/ext4-100dd-1-3.5.0
> 243.73 -10.9% 217.28 lkp-nex04/RAID5-12HDD-thresh=8G/ext4-10dd-1-3.5.0

 Hi,

 About this issue, I did some investigation. And found we are blocked at
 get_active_stripes() in most times. It's reasonable, since max_nr_stripes
 is set to 256 now. It's a kind of small value, thus I tried with
 different value. Please see the following patch for detailed numbers.

 The test machine is same as above.

 From 85c27fca12b770da5bc8ec9f26a22cb414e84c68 Mon Sep 17 00:00:00 2001
 From: Yuanhan Liu 
 Date: Wed, 22 Aug 2012 10:51:48 +0800
 Subject: [RFC PATCH] md/raid5: increase NR_STRIPES to 1024

 Stripe head is a must held resource before doing any IO. And it's
 limited to 256 by default. With 10dd case, we found that it is
 blocked at get_active_stripes() in most times(please see the ps
 output attached).

 Thus I did some tries with different value set to NR_STRIPS, and
 here are some numbers(EXT4 only) I got with different NR_STRIPS set:

 write bandwidth:
 
 3.5.0-rc1-256+: (Here 256 means with max strip head set to 256)
 write bandwidth: 280
 3.5.0-rc1-1024+:
 write bandwidth: 421 (+50.4%)
 3.5.0-rc1-4096+:
 write bandwidth: 506 

[git pull] drm fixes + one fbcon one

[Dave Airlie]

Hi Linus,

Intel: edid fixes, power consumption fix, s/r fix, haswell fix
radeon: BIOS loading fixes for UEFI and Thunderbolt machines, better MSAA 
validation, lockup timeout fixes, modesetting fixes
one udl dpms fix,
one vmwgfx fix,
couple of trivial core changes

There is an export added to ACPI as part of the radeon bios fixes,

I've also included the fbcon flashing cursor vs deinit race fix, that 
seems the simplest place to start, so that distros can pick it up easier.

Dave.

The following changes since commit d9875690d9b89a866022ff49e3fcea892345ad92:

  Linux 3.6-rc2 (2012-08-16 14:51:24 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux.git drm-fixes

for you to fetch changes up to d8636a2717bb3da2a7ce2154bf08de90bb8c87b0:

  fbcon: fix race condition between console lock and cursor timer (v1.1) 
(2012-08-22 14:00:35 +1000)


Alan Cox (1):
  drm: stop vmgfx driver explosion

Alex Deucher (5):
  ACPI: export symbol acpi_get_table_with_size
  drm/radeon: convert radeon vfct code to use acpi_get_table_with_size
  drm/radeon: split ATRM support out from the ATPX handler (v3)
  Revert "drm/radeon: fix bo creation retry path"
  drm/radeon/ss: use num_crtc rather than hardcoded 6

Ben Widawsky (1):
  drm/i915/contexts: fix list corruption

Christian König (1):
  drm/radeon: init lockup timeout on ring init

Damien Lespiau (1):
  drm: Remove two unused fields from struct drm_display_mode

Daniel Vetter (2):
  drm/i915: fix hsw uncached pte
  drm/i915: use hsw rps tuning values everywhere on gen6+

Dave Airlie (4):
  Merge branch 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes
  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
  drm/udl: dpms off the crtc when disabled.
  fbcon: fix race condition between console lock and cursor timer (v1.1)

David Lamparter (1):
  drm/radeon: implement ACPI VFCT vbios fetch (v3)

Jani Nikula (3):
  drm/i915: fix EDID memory leak in SDVO
  drm/i915: extract connector update from intel_ddc_get_modes() for reuse
  drm/i915: fall back to bit-banging if GMBUS fails in CRT EDID reads

Jerome Glisse (1):
  drm/radeon: avoid turning off spread spectrum for used pll

Marek Olšák (2):
  drm/radeon: allow CMASK and FMASK in the CS checker on r600-r700
  drm/radeon: fix checking of MSAA renderbuffers on r600-r700

Sachin Kamat (1):
  drm: Add missing static storage class specifiers in drm_proc.c file

Tvrtko Ursulin (1):
  drm/radeon/kms: extend the Fujitsu D3003-S2 board connector quirk to 
cover later silicon stepping

 drivers/acpi/acpica/tbxface.c|1 +
 drivers/char/agp/intel-agp.h |1 +
 drivers/char/agp/intel-gtt.c |  105 +---
 drivers/gpu/drm/drm_modes.c  |3 -
 drivers/gpu/drm/drm_proc.c   |4 +-
 drivers/gpu/drm/i915/i915_gem.c  |8 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c  |5 +-
 drivers/gpu/drm/i915/i915_reg.h  |1 +
 drivers/gpu/drm/i915/intel_crt.c |   36 ++-
 drivers/gpu/drm/i915/intel_drv.h |2 +
 drivers/gpu/drm/i915/intel_modes.c   |   31 --
 drivers/gpu/drm/i915/intel_pm.c  |   15 +--
 drivers/gpu/drm/i915/intel_sdvo.c|1 +
 drivers/gpu/drm/radeon/atombios_crtc.c   |   25 -
 drivers/gpu/drm/radeon/r600_cs.c |  105 
 drivers/gpu/drm/radeon/r600d.h   |   17 
 drivers/gpu/drm/radeon/radeon.h  |   15 ---
 drivers/gpu/drm/radeon/radeon_atombios.c |2 +-
 drivers/gpu/drm/radeon/radeon_atpx_handler.c |   56 +--
 drivers/gpu/drm/radeon/radeon_bios.c |  138 +-
 drivers/gpu/drm/radeon/radeon_drv.c  |3 +-
 drivers/gpu/drm/radeon/radeon_object.c   |3 +-
 drivers/gpu/drm/radeon/radeon_ring.c |1 +
 drivers/gpu/drm/radeon/reg_srcs/r600 |8 --
 drivers/gpu/drm/udl/udl_modeset.c|3 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  |6 +-
 drivers/video/console/fbcon.c|9 +-
 include/drm/drm_crtc.h   |2 -
 28 files changed, 424 insertions(+), 182 deletions(-)

[PATCH 2/2] mmc: dw_mmc: Add a DISABLE_MMC quirk that sets the core mmc cap

[Doug Anderson]

On some systems we need a way to disable MMC card support in a MMC/SD
card slot.  Add support in the dw_mmc to support this.

Signed-off-by: Doug Anderson 
---
 drivers/mmc/host/dw_mmc.c  |3 +++
 include/linux/mmc/dw_mmc.h |2 ++
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index af40d22..09111bf 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1810,6 +1810,9 @@ static int __init dw_mci_init_slot(struct dw_mci *host, 
unsigned int id)
if (host->pdata->quirks & DW_MCI_QUIRK_HIGHSPEED)
mmc->caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED;
 
+   if (host->pdata->quirks & DW_MCI_QUIRK_DISABLE_MMC)
+   mmc->caps2 |= MMC_CAP2_NO_MMC;
+
if (mmc->caps2 & MMC_CAP2_POWEROFF_NOTIFY)
mmc->power_notify_type = MMC_HOST_PW_NOTIFY_SHORT;
else
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index 7a7ebd3..5eaa9b9 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -201,6 +201,8 @@ struct dw_mci_dma_ops {
 #define DW_MCI_QUIRK_HIGHSPEED BIT(2)
 /* Unreliable card detection */
 #define DW_MCI_QUIRK_BROKEN_CARD_DETECTION BIT(3)
+/* Only support SD cards, not MMC */
+#define DW_MCI_QUIRK_DISABLE_MMC   BIT(4)
 
 
 struct dma_pdata;
-- 
1.7.7.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 1/2] mmc: core: Add a capability for disabling mmc cards

[Doug Anderson]

On some systems we need a way to disable MMC card support in a MMC/SD
card slot.  Add support in the core SD/MMC code to support this.

Signed-off-by: Doug Anderson 
Signed-off-by: Alim Akhtar 
---
 drivers/mmc/core/core.c  |2 +-
 include/linux/mmc/host.h |1 +
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 8ac5246..3214972 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1981,7 +1981,7 @@ static int mmc_rescan_try_freq(struct mmc_host *host, 
unsigned freq)
return 0;
if (!mmc_attach_sd(host))
return 0;
-   if (!mmc_attach_mmc(host))
+   if (!(host->caps2 & MMC_CAP2_NO_MMC) && !mmc_attach_mmc(host))
return 0;
 
mmc_power_off(host);
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index f578a71..f36370e 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -257,6 +257,7 @@ struct mmc_host {
 #define MMC_CAP2_HC_ERASE_SZ   (1 << 9)/* High-capacity erase size */
 #define MMC_CAP2_CD_ACTIVE_HIGH(1 << 10)   /* Card-detect signal 
active high */
 #define MMC_CAP2_RO_ACTIVE_HIGH(1 << 11)   /* Write-protect signal 
active high */
+#define MMC_CAP2_NO_MMC(1 << 12)   /* Only SD supported, 
not MMC */
 
mmc_pm_flag_t   pm_caps;/* supported pm features */
unsigned intpower_notify_type;
-- 
1.7.7.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/

[RFC/PATCH] ARM: smp: Fix cpu_up() racing with sys_reboot

[Stephen Boyd]

Nothing stops a process from hotplugging in a CPU concurrently
with a sys_reboot() call. In such a situation we could have
ipi_cpu_stop() mark a cpu as 'offline' and _cpu_up() ignore the
fact that the CPU is not really offline and call the
CPU_UP_PREPARE notifier. When this happens stop_machine code will
complain that the cpu thread already exists and BUG_ON().

CPU0  CPU1

sys_reboot()
 kernel_restart()
  machine_restart()
   machine_shutdown()
smp_send_stop()
...   ipi_cpu_stop()
   set_cpu_online(1, false)
local_irq_disable()
 while(1)

cpu_up()
 _cpu_up()
   if (!cpu_online(1))
__cpu_notify(CPU_UP_PREPARE...)

cpu_stop_cpu_callback()
  BUG_ON(stopper->thread)

This is easily reproducible by hotplugging in and out in a tight
loop while also rebooting.

Since the CPU is not really offline and hasn't gone through the
proper steps to be marked as such, let's mark the CPU as inactive.
This is just as easily testable as online and avoids any possibility
of _cpu_up() trying to bring the CPU back online when it never was
offline to begin with.

Signed-off-by: Stephen Boyd 
---

Perhaps we can take the hotplug lock in the sys_reboot() case but I
don't think that actually fixes everything. For example, in cases
where machine_shutdown() is called from emergency_restart() we would
have to take the hotplug lock which doesn't really seem feasible.

 arch/arm/kernel/smp.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index ebd8ad2..836b771 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -478,7 +478,7 @@ static void ipi_cpu_stop(unsigned int cpu)
raw_spin_unlock(_lock);
}
 
-   set_cpu_online(cpu, false);
+   set_cpu_active(cpu, false);
 
local_fiq_disable();
local_irq_disable();
@@ -568,10 +568,10 @@ void smp_send_stop(void)
 
/* Wait up to one second for other CPUs to stop */
timeout = USEC_PER_SEC;
-   while (num_online_cpus() > 1 && timeout--)
+   while (num_active_cpus() > 1 && timeout--)
udelay(1);
 
-   if (num_online_cpus() > 1)
+   if (num_active_cpus() > 1)
pr_warning("SMP: failed to stop secondary CPUs\n");
 
smp_kill_cpus();
-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

--
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 fsnotify tree with Linus' tree

[Stephen Rothwell]

Hi Eric,

Today's linux-next merge of the fsnotify tree got a conflict in
kernel/audit_tree.c between commits a2140fc0cb03 ("audit: fix refcounting
in audit-tree") and b3e8692b4dde ("audit: clean up refcounting in
audit-tree") from Linus' tree and commit 3c183c233284 ("fsnotify: pass
group to fsnotify_destroy_mark()") from the fsnotify tree.

Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc kernel/audit_tree.c
index ed206fd,9cedf31..000
--- a/kernel/audit_tree.c
+++ b/kernel/audit_tree.c
@@@ -249,7 -249,8 +249,7 @@@ static void untag_chunk(struct node *p
list_del_rcu(>hash);
spin_unlock(_lock);
spin_unlock(>lock);
-   fsnotify_destroy_mark(entry);
+   fsnotify_destroy_mark(entry, audit_tree_group);
 -  fsnotify_put_mark(entry);
goto out;
}
  
@@@ -291,8 -292,8 +291,8 @@@
owner->root = new;
spin_unlock(_lock);
spin_unlock(>lock);
-   fsnotify_destroy_mark(entry);
+   fsnotify_destroy_mark(entry, audit_tree_group);
 -  fsnotify_put_mark(entry);
 +  fsnotify_put_mark(>mark);  /* drop initial reference */
goto out;
  
  Fallback:
@@@ -443,9 -443,9 +443,9 @@@ static int tag_chunk(struct inode *inod
spin_unlock(_lock);
spin_unlock(_entry->lock);
spin_unlock(_entry->lock);
-   fsnotify_destroy_mark(old_entry);
+   fsnotify_destroy_mark(old_entry, audit_tree_group);
 +  fsnotify_put_mark(chunk_entry); /* drop initial reference */
fsnotify_put_mark(old_entry); /* pair to fsnotify_find mark_entry */
 -  fsnotify_put_mark(old_entry); /* and kill it */
return 0;
  }
  


pgpmCmGkeDTwc.pgp
Description: PGP signature

Re: [PATCH] fbcon: fix race condition between console lock and cursor timer

[Dave Airlie]

On Tue, Aug 21, 2012 at 7:15 PM, Alan Cox  wrote:
>> So after much tracing with direct netconsole writes (printks
>> under console_lock not so useful), I think I found the race.
>
> Direct netconsole write would be a useful patch to have mainline I think
> 8)

Well I used a one line wrapper around the netconsole write_msg, which
just passed
NULL as the first arg, then sprinkled netconsole_write_msg around the
place, not having
printf stuff could be an annoyance for some people, for this it didn't matter.

Peter I wish I had a serial port to work with :-)

>
> Not really the proper fix but its clear and is probably the best thing to
> go in initially with a cc: stable. Can you at least stick a large
>
> + /* FIXME: we should sort out the unbind locking instead */

Done, and cc stable, I'll send this to Linus via my tree as its fairly
urgent from my pov.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: O_DIRECT to md raid 6 is slow

[Stan Hoeppner]

On 8/21/2012 9:51 AM, Miquel van Smoorenburg wrote:
> On 08/20/2012 01:34 AM, Stan Hoeppner wrote:
>> I'm glad you jumped in David.  You made a critical statement of fact
>> below which clears some things up.  If you had stated it early on,
>> before Miquel stole the thread and moved it to LKML proper, it would
>> have short circuited a lot of this discussion.  Which is:
> 
> I'm sorry about that, that's because of the software that I use to
> follow most mailinglist. I didn't notice that the discussion was cc'ed
> to both lkml and l-r. I should fix that.

Oh, my bad.  I thought it was intentional.

Don't feel too bad about it.  When I tried to copy lkml back in on the
one message I screwed up as well.  I though Tbird had filled in the full
address but it didn't.

>> Thus my original statement was correct, or at least half correct[1], as
>> it pertained to md/RAID6.  Then Miquel switched the discussion to
>> md/RAID5 and stated I was all wet.  I wasn't, and neither was Dave
>> Chinner.  I was simply unaware of this md/RAID5 single block write RMW
>> shortcut
> 
> Well, all I tried to say is that a small write of, say, 4K, to a
> raid5/raid6 array does not need to re-write the whole stripe (i.e.
> chunksize * nr_disks) but just 4K * nr_disks, or the RMW variant of that.

And I'm glad you did.  Before that I didn't know about these efficiency
shortcuts and exactly how md does writeback on partial stripe updates.

Even with these optimizations, a default 512KB chunk is too big, for the
reasons I stated, the big one being the fact that you'll rarely fill a
full stripe, meaning nearly every write will incur an RMW cycle.

-- 
Stan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: mmu_notifier: fix inconsistent memory between secondary MMU and host

[Xiao Guangrong]

On 08/21/2012 11:06 PM, Andrea Arcangeli wrote:
> On Tue, Aug 21, 2012 at 05:46:39PM +0800, Xiao Guangrong wrote:
>> There has a bug in set_pte_at_notify which always set the pte to the
>> new page before release the old page in secondary MMU, at this time,
>> the process will access on the new page, but the secondary MMU still
>> access on the old page, the memory is inconsistent between them
>>
>> Below scenario shows the bug more clearly:
>>
>> at the beginning: *p = 0, and p is write-protected by KSM or shared with
>> parent process
>>
>> CPU 0   CPU 1
>> write 1 to p to trigger COW,
>> set_pte_at_notify will be called:
>>   *pte = new_page + W; /* The W bit of pte is set */
>>
>>  *p = 1; /* pte is valid, so no #PF */
>>
>>  return back to secondary MMU, then
>>  the secondary MMU read p, but get:
>>  *p == 0;
>>
>>  /*
>>   * !!
>>   * the host has already set p to 1, but the 
>> secondary
>>   * MMU still get the old value 0
>>   */
>>
>>   call mmu_notifier_change_pte to release
>>   old page in secondary MMU
> 
> The KSM usage of it looks safe because it will only establish readonly
> ptes with it.

Hmm, in KSM code, i found this code in replace_page:

set_pte_at_notify(mm, addr, ptep, mk_pte(kpage, vma->vm_page_prot));

It is possible to establish a writable pte, no?

> 
> It seems a problem only for do_wp_page. It wasn't safe to setup
> writable ptes with it. I guess we first introduced it for KSM and then
> we added it to do_wp_page too by mistake.
> 
> The race window is really tiny, it's unlikely it has ever triggered,
> however this one seem to be possible so it's slightly more serious
> than the other race you recently found (the previous one in the exit
> path I think it was impossible to trigger with KVM).

Unfortunately, all these bugs are triggered by test cases.

> 
>> We can fix it by release old page first, then set the pte to the new
>> page.
>>
>> Note, the new page will be firstly used in secondary MMU before it is
>> mapped into the page table of the process, but this is safe because it
>> is protected by the page table lock, there is no race to change the pte
>>
>> Signed-off-by: Xiao Guangrong 
>> ---
>>  include/linux/mmu_notifier.h |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
>> index 1d1b1e1..8c7435a 100644
>> --- a/include/linux/mmu_notifier.h
>> +++ b/include/linux/mmu_notifier.h
>> @@ -317,8 +317,8 @@ static inline void mmu_notifier_mm_destroy(struct 
>> mm_struct *mm)
>>  unsigned long ___address = __address;   \
>>  pte_t ___pte = __pte;   \
>>  \
>> -set_pte_at(___mm, ___address, __ptep, ___pte);  \
>>  mmu_notifier_change_pte(___mm, ___address, ___pte); \
>> +set_pte_at(___mm, ___address, __ptep, ___pte);  \
>>  })
> 
> If we establish the spte on the new page, what will happen is the same
> race in reverse. The fundamental problem is that the first guy that
> writes to the "newpage" (guest or host) won't fault again and so it
> will fail to serialize against the PT lock.
> 
> CPU0  CPU1
>   oldpage[1] == 0 (both guest & host)
> oldpage[0] = 1
> trigger do_wp_page
> mmu_notifier_change_pte
> spte = newpage + writable
>   guest does newpage[1] = 1
>   vmexit
>   host read oldpage[1] == 0
> pte = newpage + writable (too late)
> 
> I think the fix is to use ptep_clear_flush_notify whenever
> set_pte_at_notify will establish a writable pte/spte. If the pte/spte
> established by set_pte_at_notify/change_pte is readonly we don't need
> to do the ptep_clear_flush_notify instead because when the host will
> write to the page that will fault and serialize against the
> PT lock (set_pte_at_notify must always run under the PT lock of course).
> 
> How about this:
> 
> =
>>From 160a0b1b2be9bf96c45b30d9423f8196ecebe351 Mon Sep 17 00:00:00 2001
> From: Andrea Arcangeli 
> Date: Tue, 21 Aug 2012 16:48:11 +0200
> Subject: [PATCH] mmu_notifier: fix race in set_pte_at_notify usage
> 
> Whenever we establish a writable spte with set_pte_at_notify the
> ptep_clear_flush before it must be a _notify one that clears the spte
> too.
> 
> The fundamental problem is that if the primary MMU that writes to the
> "newpage" won't fault again if the pte established by
> set_pte_at_notify is writable. And so it will fail to serialize
> against the PT lock to wait the 

Re: [PATCH v2 3/3] spi: spi-davinci: convert to DMA engine API

[Vinod Koul]

On Tue, 2012-08-21 at 14:43 -0400, Matt Porter wrote:
> Removes use of the DaVinci EDMA private DMA API and replaces
> it with use of the DMA engine API.
> 
> Signed-off-by: Matt Porter 
> ---

> + struct dma_slave_config dma_rx_conf = {
> + .direction = DMA_DEV_TO_MEM,
> + .src_addr = (unsigned long)dspi->pbase + SPIBUF,
> + .src_addr_width = data_type,
> + .src_maxburst = 1,
what does 1 mean in this context? We define as number of units that
needs to be transfered, so are you sure that you want only one unit to
be dma'ed in a single burst. that seems like killing your dmac,
shouldn't you be using larger bursts for a better dma performance?


-- 
~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 2/4] leds-lp5523: set the brightness to 0 forcely on removing the driver

[Bryan Wu]

On Tue, Aug 21, 2012 at 5:03 PM, Kim, Milo  wrote:
> Turning off the brightness of each channel is required
> when removing the driver.
>
> So use flush_work_sync() rather than cancel_work_sync() to wait for
> unhandled brightness works.

Hmmm, I think we still should use cancel_work() here based on your
idea. Please find the patch from Tejun and add him to this loop
[PATCH 4/6] workqueue: deprecate flush[_delayed]_work_sync()
---
Before this patchset,

 flush_work()

flush the last queued instance of the work item.  If it got
queued on multple CPUs, it only considers the last queued
instance.  The work item could still be executing on other
CPUs and the flush might become noop if there are competing
queueing operation on another CPU.

 flush_work_sync()

flush_work() + wait for executing instances on all CPUs.  The
flush_work() part may still become noop if there's competing
queueing operation.

 cancel_work()

Dequeue the work item if it's pending.  Doesn't care about
whether it's executing or not.

 cancel_work_sync()

cancel_work() + flush_work_sync().


After this patchset,

 flush_work()

flush the work item.  Any queueing happened previously is
guaranteed to have finished execution on return.  If no
further queueing happened after flush started, the work item
is guaranteed to be idle on return.

 cancel_work()

Same as before.

 cancel_work_sync()

cancel_work() followed by flush_work().  The same semantics as
del_timer_sync().
---

cancel_work_sync() won't execute the work item at all just cancel
them, but flush will execute them and return.

-Bryan

>
> Signed-off-by: Milo(Woogyom) Kim 
> ---
>  drivers/leds/leds-lp5523.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
> index 9fd9a92..f090819 100644
> --- a/drivers/leds/leds-lp5523.c
> +++ b/drivers/leds/leds-lp5523.c
> @@ -974,7 +974,7 @@ static int __devinit lp5523_probe(struct i2c_client 
> *client,
>  fail2:
> for (i = 0; i < chip->num_leds; i++) {
> led_classdev_unregister(>leds[i].cdev);
> -   cancel_work_sync(>leds[i].brightness_work);
> +   flush_work_sync(>leds[i].brightness_work);
> }
>  fail1:
> if (pdata->enable)
> @@ -993,7 +993,7 @@ static int lp5523_remove(struct i2c_client *client)
>
> for (i = 0; i < chip->num_leds; i++) {
> led_classdev_unregister(>leds[i].cdev);
> -   cancel_work_sync(>leds[i].brightness_work);
> +   flush_work_sync(>leds[i].brightness_work);
> }
>
> if (chip->pdata->enable)
> --
> 1.7.2.5
>
>
> Best Regards,
> Milo
>
>



-- 
Bryan Wu 
Kernel Developer+86.186-168-78255 Mobile
Canonical Ltd.  www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/3] dmaengine: add TI EDMA DMA engine driver

[Vinod Koul]

On Tue, 2012-08-21 at 14:43 -0400, Matt Porter wrote:
> Add a DMA engine driver for the TI EDMA controller. This driver
> is implemented as a wrapper around the existing DaVinci private
> DMA implementation. This approach allows for incremental conversion
> of each peripheral driver to the DMA engine API. The EDMA driver
> supports slave transfers but does not yet support cyclic transfers.
> 
> Signed-off-by: Matt Porter 
mostly looks decent and in shape.

> ---
> +config TI_EDMA
> + tristate "TI EDMA support"
> + depends on ARCH_DAVINCI
> + select DMA_ENGINE
> + select DMA_VIRTUAL_CHANNELS
> + default y
default should be n for new drivers

> + help
> +   Enable support for the TI EDMA controller. This DMA
> +   engine is found on TI DaVinci and AM33xx parts.
> +
>  config ARCH_HAS_ASYNC_TX_FIND_CHANNEL
>   bool
>  
> +/* Max of 16 segments per channel to conserve PaRAM slots */
> +#define MAX_NR_SG16
> +#define EDMA_MAX_SLOTS   MAX_NR_SG
> +#define EDMA_DESCRIPTORS 16
> +
> +struct edma_desc {
> + struct virt_dma_descvdesc;
> + struct list_headnode;
> +
dummy space?
> + int absync;
> + int pset_nr;
> + struct edmacc_param pset[0];
> +};
> +
> +struct edma_cc;
> +
> +struct edma_chan {
> + struct virt_dma_chanvchan;
> + struct list_headnode;
> + struct edma_desc*edesc;
> + struct edma_cc  *ecc;
> + int ch_num;
> + boolalloced;
> + int slot[EDMA_MAX_SLOTS];
> +
> + dma_addr_t  addr;
> + int addr_width;
> + int maxburst;
> +};
> +

> +/* Dispatch a queued descriptor to the controller (caller holds lock) */
> +static void edma_execute(struct edma_chan *echan)
> +{
> + struct virt_dma_desc *vdesc = vchan_next_desc(>vchan);
> + struct edma_desc *edesc;
> + int i;
> +
> + if (!vdesc) {
> + echan->edesc = NULL;
> + return;
> + }
> +
> + list_del(>node);
> +
> + echan->edesc = edesc = to_edma_desc(>tx);
> +
> + /* Write descriptor PaRAM set(s) */
> + for (i = 0; i < edesc->pset_nr; i++) {
> + edma_write_slot(echan->slot[i], >pset[i]);
> + dev_dbg(echan->vchan.chan.device->dev,
> + "\n pset[%d]:\n"
> + "  chnum\t%d\n"
> + "  slot\t%d\n"
> + "  opt\t%08x\n"
> + "  src\t%08x\n"
> + "  dst\t%08x\n"
> + "  abcnt\t%08x\n"
> + "  ccnt\t%08x\n"
> + "  bidx\t%08x\n"
> + "  cidx\t%08x\n"
> + "  lkrld\t%08x\n",
> + i, echan->ch_num, echan->slot[i],
> + edesc->pset[i].opt,
> + edesc->pset[i].src,
> + edesc->pset[i].dst,
> + edesc->pset[i].a_b_cnt,
> + edesc->pset[i].ccnt,
> + edesc->pset[i].src_dst_bidx,
> + edesc->pset[i].src_dst_cidx,
> + edesc->pset[i].link_bcntrld);
> + /* Link to the previous slot if not the last set */
> + if (i != (edesc->pset_nr - 1))
> + edma_link(echan->slot[i], echan->slot[i+1]);
> + /* Final pset links to the dummy pset */
> + else
> + edma_link(echan->slot[i], echan->ecc->dummy_slot);
> + }
> +
> + edma_start(echan->ch_num);
> +}
> +
> +static int edma_terminate_all(struct edma_chan *echan)
> +{
> + unsigned long flags;
> + LIST_HEAD(head);
> +
> + spin_lock_irqsave(>vchan.lock, flags);
> +
> + /*
> +  * Stop DMA activity: we assume the callback will not be called
> +  * after edma_dma() returns (even if it does, it will see
> +  * echan->edesc is NULL and exit.)
> +  */
> + if (echan->edesc) {
> + echan->edesc = NULL;
> + edma_stop(echan->ch_num);
> + }
> +
> + vchan_get_all_descriptors(>vchan, );
> + spin_unlock_irqrestore(>vchan.lock, flags);
> + vchan_dma_desc_free_list(>vchan, );
> +
> + return 0;
> +}
> +
> +
> +static int edma_slave_config(struct edma_chan *echan,
> + struct dma_slave_config *config)
> +{
> + if ((config->src_addr_width > DMA_SLAVE_BUSWIDTH_4_BYTES) ||
> + (config->dst_addr_width > DMA_SLAVE_BUSWIDTH_4_BYTES))
> + return -EINVAL;
the indent needs help here
> +
> + if (config->direction == DMA_MEM_TO_DEV) {
> + if (config->dst_addr)
> + echan->addr = config->dst_addr;
> + if (config->dst_addr_width)
> +  

Re: [PATCH] memory-hotplug: fix a drain pcp bug when offline pages

[Minchan Kim]

Hello Xishi,

On Tue, Aug 21, 2012 at 08:12:05PM +0800, qiuxishi wrote:
> From: Xishi Qiu 
> 
> When offline a section, we move all the free pages and pcp into 
> MIGRATE_ISOLATE list first.
> start_isolate_page_range()
>   set_migratetype_isolate()
>   drain_all_pages(),
> 
> Here is a problem, it is not sure that pcp will be moved into MIGRATE_ISOLATE 
> list. They may
> be moved into MIGRATE_MOVABLE list because page_private() maybe 2. So when 
> finish migrating
> pages, the free pages from pcp may be allocated again, and faild in 
> check_pages_isolated().
> drain_all_pages()
>   drain_local_pages()
>   drain_pages()
>   free_pcppages_bulk()
>   __free_one_page(page, zone, 0, 
> page_private(page));
> 
> If we add move_freepages_block() after drain_all_pages(), it can not sure 
> that all the pcp
> will be moved into MIGRATE_ISOLATE list when the system works on high load. 
> The free pages
> which from pcp may immediately be allocated again.
> 
> I think the similar bug described in 
> http://marc.info/?t=13425088233=1=2

Yes. I reported the problem a few month ago but it's not real bug in practice
but found by my eyes during looking the code so I wanted to confirm the problem.

Do you find that problem in real practice? or just code review?

Anyway, I don't like your approach which I already considered because it hurts 
hotpath
while the race is really unlikely. Get_pageblock_migratetype is never trivial.
We should avoid the overhead in hotpath and move into memory-hotplug itself.
Do you see my patch in https://patchwork.kernel.org/patch/1225081/ ?

> 
> 
> Signed-off-by: Xishi Qiu 
> ---
>  mm/page_alloc.c |3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index d0723b2..501f6de 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -673,7 +673,8 @@ static void free_pcppages_bulk(struct zone *zone, int 
> count,
>   /* must delete as __free_one_page list manipulates */
>   list_del(>lru);
>   /* MIGRATE_MOVABLE list may include MIGRATE_RESERVEs */
> - __free_one_page(page, zone, 0, page_private(page));
> + __free_one_page(page, zone, 0,
> + get_pageblock_migratetype(page));
>   trace_mm_page_pcpu_drain(page, 0, page_private(page));
>   } while (--to_free && --batch_free && !list_empty(list));
>   }
> -- 1.7.6.1 .
> 
> 
> 
> .
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
Kind regards,
Minchan Kim
--
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] xhci: Unconditionally switch ports to xHCI on powerup

[Andiry Xu]

On Wed, Aug 22, 2012 at 12:16 AM, Manoj Iyer  wrote:
>
> Looks like in pci-quirks.c, we enter the do() while() loop, reach the end of
> extended capabilities and goto hc_init: label, skipping the switch. Probably
> moving the switch under the hc_init label might work? Currently we switch
> unconditionally on resume, so we could do the same at powerup as well.
>

If this is a must-to-do thing for Intel Panther Point platform, then
we need to make sure it's called on power up and resume. Yes, I think
moving the code below hc_init label should work and I think it's a
better solution than your original patch.

Thanks,
Andiry

>
> On Tue, 21 Aug 2012, Andiry Xu wrote:
>
>> On Tue, Aug 21, 2012 at 12:06 PM,   wrote:
>>>
>>> From: Manoj Iyer 
>>>
>>> USB 3.0 devices show up as high-speed devices on powerup, after an
>>> s3 cycle they are correctly recognized as SuperSpeed. At powerup
>>> unconditionally switch the port to xHCI like we do when we resume
>>> from suspend.
>>>
>>> BugLink: http://bugs.launchpad.net/bugs/1000424
>>>
>>> Signed-off-by: Manoj Iyer 
>>> ---
>>>  drivers/usb/host/xhci-pci.c |8 
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
>>> index 9bfd4ca11..5c8dbea 100644
>>> --- a/drivers/usb/host/xhci-pci.c
>>> +++ b/drivers/usb/host/xhci-pci.c
>>> @@ -48,6 +48,14 @@ static int xhci_pci_reinit(struct xhci_hcd *xhci,
>>> struct pci_dev *pdev)
>>> if (!pci_set_mwi(pdev))
>>> xhci_dbg(xhci, "MWI active\n");
>>>
>>> +   /*
>>> +* USB SuperSpeed ports are recognized as HighSpeed ports on
>>> powerup
>>> +* unconditionally switch the ports to xHCI like we do when
>>> resume
>>> +* from suspend.
>>> +*/
>>> +   if (usb_is_intel_switchable_xhci(pdev))
>>> +   usb_enable_xhci_ports(pdev);
>>> +
>>
>>
>> Strange. This should have been called during system power up, in
>> quirk_usb_handoff_xhci() of pci_quirks.c. Do you see that routine get
>> called during power up?
>>
>> Thanks,
>> Andiry
>>
>>> xhci_dbg(xhci, "Finished xhci_pci_reinit\n");
>>> return 0;
>>>  }
>>> --
>>> 1.7.9.5
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>
> --
> 
> Manoj Iyer
> Ubuntu/Canonical
> Hardware Enablement
> 
--
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 PATCH] Re: Repeated fork() causes SLAB to grow without bound

[Rik van Riel]

On 08/21/2012 11:20 PM, Michel Lespinasse wrote:

On Mon, Aug 20, 2012 at 02:39:26AM -0700, Michel Lespinasse wrote:

Instead of adding an atomic count for page references, we could limit
the anon_vma stacking depth. In fork, we would only clone anon_vmas
that have a low enough generation count. I think that's not great
(adds a special case for the deep-fork-without-exec behavior), but
still better than the atomic page reference counter.


Here is an attached patch to demonstrate the idea.

anon_vma_clone() is modified to return the length of the existing same_vma
anon vma chain, and we create a new anon_vma in the child only on the first
fork (this could be tweaked to allow up to a set number of forks, but
I think the first fork would cover all the common forking server cases).


I suspect we need 2 or 3.

Some forking servers first fork off one child, and have
the original parent exit, in order to "background the server".
That first child then becomes the parent to the real child
processes that do the work.

It is conceivable that we might need an extra level for
processes that do something special with privilege dropping,
namespace changing, etc...

Even setting the threshold to 5 should be totally harmless,
since the problem does not kick in until we have really
long chains, like in Dan's bug report.

--
All rights reversed
--
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: apparent regressions from TLB range flushing page set

[Alex Shi]

> Second, the UV code doesn't flush the full range at all, it simply
> ignores its 'end' parameter (and hence also the "all" indicator).
> 




Sure. the following rfc patch try to fix it. untested since no hardware.

=

diff --git a/arch/x86/include/asm/uv/uv_bau.h b/arch/x86/include/asm/uv/uv_bau.h
index a06983c..ac6f326 100644
--- a/arch/x86/include/asm/uv/uv_bau.h
+++ b/arch/x86/include/asm/uv/uv_bau.h
@@ -225,8 +225,10 @@ struct bau_local_cpumask {
  * The payload is software-defined for INTD transactions
  */
 struct bau_msg_payload {
-   unsigned long   address;/* signifies a page or all
-  TLB's of the cpu */
+   unsigned long   start;  /* start address to flush TLB
+  of the cpu */
+   unsigned long   end;/* end address to flush TLB
+  of the cpu */
/* 64 bits */
unsigned short  sending_cpu;/* filled in by sender */
/* 16 bits */
diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index b8b3a37..c603d15 100644
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -280,12 +280,12 @@ static void bau_process_message(struct msg_desc *mdp, 
struct bau_control *bcp,
/*
 * This must be a normal message, or retry of a normal message
 */
-   if (msg->address == TLB_FLUSH_ALL) {
+   if (msg->end == 0) {
+   __flush_tlb_one(msg->start);
+   stat->d_onetlb++;
+   } else {
local_flush_tlb();
stat->d_alltlb++;
-   } else {
-   __flush_tlb_one(msg->address);
-   stat->d_onetlb++;
}
stat->d_requestee++;
 
@@ -1034,7 +1034,8 @@ static int set_distrib_bits(struct cpumask *flush_mask, 
struct bau_control *bcp,
  * globally purge translation cache of a virtual address or all TLB's
  * @cpumask: mask of all cpu's in which the address is to be removed
  * @mm: mm_struct containing virtual address range
- * @va: virtual address to be removed (or TLB_FLUSH_ALL for all TLB's on cpu)
+ * @start: start virtual address to be removed from TLB
+ * @end: end virtual address to be remove from TLB
  * @cpu: the current cpu
  *
  * This is the entry point for initiating any UV global TLB shootdown.
@@ -1113,7 +1114,8 @@ const struct cpumask *uv_flush_tlb_others(const struct 
cpumask *cpumask,
 
record_send_statistics(stat, locals, hubs, remotes, bau_desc);
 
-   bau_desc->payload.address = start;
+   bau_desc->payload.start = start;
+   bau_desc->payload.end   = end;
bau_desc->payload.sending_cpu = cpu;
/*
 * uv_flush_send_and_wait returns 0 if all cpu's were messaged,

--
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: apparent regressions from TLB range flushing page set

[Alex Shi]

On 08/20/2012 10:12 PM, Jan Beulich wrote:

> Alex,
> 
> without even having run that code yet, I think I see two bugs here,
> both of which I'm pretty sure I pointed out at least once during the
> review cycle:


I was thought you have 'Agreed' for xen part code. :)

> 
> For one, while TLB_FLUSH_ALL gets passed as 'end' argument to
> flush_tlb_others(), the Xen code was made to check its 'start'
> parameter.


Do you mean need the following change? --untested.

>From the logical of flush_tlb_others, the old code should cause unflushed TLB 
>issue
(when end == -1, xen just executed INVLPG_MULTI, not whole TLB_FLUSH_MULTI). 
but we
 didn't find this problem in xen test. So, guess the xen code has other bug 
cover this. 

=
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index b65a761..5141d80 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1283,7 +1283,7 @@ static void xen_flush_tlb_others(const struct cpumask 
*cpus,
cpumask_clear_cpu(smp_processor_id(), to_cpumask(args->mask));
 
args->op.cmd = MMUEXT_TLB_FLUSH_MULTI;
-   if (start != TLB_FLUSH_ALL && (end - start) <= PAGE_SIZE) {
+   if (end != TLB_FLUSH_ALL && (end - start) <= PAGE_SIZE) {
args->op.cmd = MMUEXT_INVLPG_MULTI;
args->op.arg1.linear_addr = start;
}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] target fixes for v3.6-rc3

[Nicholas A. Bellinger]

Hello Linus!

The following are pending target fixes destined for v3.6-rc3.  Please go
ahead and pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master

The executive summary includes:

- Post-merge review comments for tcm_vhost (MST + nab)
- Avoid debugging overhead when not debugging for tcm-fc(FCoE) (MDR)
- Fix NULL pointer dereference bug on alloc_page failulre (Yi Zou)
- Fix REPORT_LUNs regression bug with pSCSI export (AlexE + nab)
- Fix regression bug with handling of zero-length data CDBs (nab)
- Fix vhost_scsi_target structure alignment (MST)

Thanks again to everyone who contributed a bugfix patch, gave review
feedback on tcm_vhost code, and/or reported a bug during their own
testing over the last weeks.

There is one other outstanding bug reported by Roland recently related
to SCSI transfer length overflow handling, for which the current
proposed bugfix has been left in queue pending further testing with
other non iscsi-target based fabric drivers.

As the patch is verified with loopback (local SGL memory from SCSI LLD)
+ tcm_qla2xxx (TCM allocated SGL memory mapped to PCI HW) fabric ports,
it will be included into the next 3.6-rc-fixes PULL request.

Thank you!

--nab

Denis Efremov (1):
  tcm_fc: rcu_deref outside rcu lock/unlock section

Fengguang Wu (1):
  tcm_vhost: Fix incorrect IS_ERR() usage in vhost_scsi_map_iov_to_sgl

Mark Rustad (1):
  tcm_fc: Avoid debug overhead when not debugging

Michael S. Tsirkin (1):
  tcm_vhost: Fix vhost_scsi_target structure alignment

Nicholas Bellinger (4):
  tcm_vhost: Post-merge review changes requested by MST
  tcm_vhost: Change vhost_scsi_target->vhost_wwpn to char *
  target/pscsi: Fix bug with REPORT_LUNs handling for SCSI passthrough
  target: Fix regression bug with handling of zero-length data CDBs

Roland Dreier (1):
  target: Remove unused se_cmd.cmd_spdtl

Yi Zou (1):
  target: fix NULL pointer dereference bug alloc_page() fails to get
memory

 drivers/target/target_core_pscsi.c |9 ++-
 drivers/target/target_core_transport.c |   15 ++-
 drivers/target/tcm_fc/tcm_fc.h |1 +
 drivers/target/tcm_fc/tfc_cmd.c|8 +-
 drivers/target/tcm_fc/tfc_sess.c   |4 +-
 drivers/vhost/tcm_vhost.c  |  203 ++--
 drivers/vhost/tcm_vhost.h  |   12 +-
 include/target/target_core_base.h  |2 -
 8 files changed, 146 insertions(+), 108 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/

[RFC PATCH] Re: Repeated fork() causes SLAB to grow without bound

[Michel Lespinasse]

On Mon, Aug 20, 2012 at 02:39:26AM -0700, Michel Lespinasse wrote:
> Instead of adding an atomic count for page references, we could limit
> the anon_vma stacking depth. In fork, we would only clone anon_vmas
> that have a low enough generation count. I think that's not great
> (adds a special case for the deep-fork-without-exec behavior), but
> still better than the atomic page reference counter.

Here is an attached patch to demonstrate the idea.

anon_vma_clone() is modified to return the length of the existing same_vma
anon vma chain, and we create a new anon_vma in the child only on the first
fork (this could be tweaked to allow up to a set number of forks, but
I think the first fork would cover all the common forking server cases).

Signed-off-by: Michel Lespinasse 
---
 mm/mmap.c |6 +++---
 mm/rmap.c |   18 ++
 2 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index 3edfcdfa42d9..e14b19a838cb 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -539,7 +539,7 @@ again:  remove_next = 1 + (end > 
next->vm_end);
 * shrinking vma had, to cover any anon pages imported.
 */
if (exporter && exporter->anon_vma && !importer->anon_vma) {
-   if (anon_vma_clone(importer, exporter))
+   if (anon_vma_clone(importer, exporter) < 0)
return -ENOMEM;
importer->anon_vma = exporter->anon_vma;
}
@@ -1988,7 +1988,7 @@ static int __split_vma(struct mm_struct * mm, struct 
vm_area_struct * vma,
}
vma_set_policy(new, pol);
 
-   if (anon_vma_clone(new, vma))
+   if (anon_vma_clone(new, vma) < 0)
goto out_free_mpol;
 
if (new->vm_file) {
@@ -2409,7 +2409,7 @@ struct vm_area_struct *copy_vma(struct vm_area_struct 
**vmap,
if (IS_ERR(pol))
goto out_free_vma;
INIT_LIST_HEAD(_vma->anon_vma_chain);
-   if (anon_vma_clone(new_vma, vma))
+   if (anon_vma_clone(new_vma, vma) < 0)
goto out_free_mempol;
vma_set_policy(new_vma, pol);
new_vma->vm_start = addr;
diff --git a/mm/rmap.c b/mm/rmap.c
index 0f3b7cda2a24..ba8a726aaee6 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -238,12 +238,13 @@ static inline void unlock_anon_vma_root(struct anon_vma 
*root)
 
 /*
  * Attach the anon_vmas from src to dst.
- * Returns 0 on success, -ENOMEM on failure.
+ * Returns length of the anon_vma chain on success, -ENOMEM on failure.
  */
 int anon_vma_clone(struct vm_area_struct *dst, struct vm_area_struct *src)
 {
struct anon_vma_chain *avc, *pavc;
struct anon_vma *root = NULL;
+   int length = 0;
 
list_for_each_entry_reverse(pavc, >anon_vma_chain, same_vma) {
struct anon_vma *anon_vma;
@@ -259,9 +260,10 @@ int anon_vma_clone(struct vm_area_struct *dst, struct 
vm_area_struct *src)
anon_vma = pavc->anon_vma;
root = lock_anon_vma_root(root, anon_vma);
anon_vma_chain_link(dst, avc, anon_vma);
+   length++;
}
unlock_anon_vma_root(root);
-   return 0;
+   return length;
 
  enomem_failure:
unlink_anon_vmas(dst);
@@ -322,6 +324,7 @@ int anon_vma_fork(struct vm_area_struct *vma, struct 
vm_area_struct *pvma)
 {
struct anon_vma_chain *avc;
struct anon_vma *anon_vma;
+   int length;
 
/* Don't bother if the parent process has no anon_vma here. */
if (!pvma->anon_vma)
@@ -331,10 +334,17 @@ int anon_vma_fork(struct vm_area_struct *vma, struct 
vm_area_struct *pvma)
 * First, attach the new VMA to the parent VMA's anon_vmas,
 * so rmap can find non-COWed pages in child processes.
 */
-   if (anon_vma_clone(vma, pvma))
+   length = anon_vma_clone(vma, pvma);
+   if (length < 0)
return -ENOMEM;
+   else if (length > 1)
+   return 0;
 
-   /* Then add our own anon_vma. */
+   /*
+* Then add our own anon_vma. We do this only on the first fork after
+* the anon_vma is created, as we don't want the same_vma chain to
+* grow arbitrarily large.
+*/
anon_vma = anon_vma_alloc();
if (!anon_vma)
goto out_error;

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
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] task_work: add a scheduling point in task_work_run()

[Mimi Zohar]

On Tue, 2012-08-21 at 23:32 +0200, Eric Dumazet wrote:
> On Tue, 2012-08-21 at 16:37 -0400, Mimi Zohar wrote:
> 
> > We're here, because fput() called schedule_work() to delay the last
> > fput().  The execution needs to take place before the syscall returns to
> > userspace.  Need to read __schedule()...  Do you know if cond_resched()
> > can guarantee that it will be executed before the return to userspace? 
> 
> Some clarifications : 
> 
> - fput() does not call schedule_work() in this case but task_work_add()
> 
> - cond_resched() wont return to userspace.

Thanks for the clarification.

Mimi

--
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 rr tree with the mips tree

[Stephen Rothwell]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
arch/mips/kernel/module.c between commit c54de490a2e4 ("MIPS: Module:
Deal with malformed HI16/LO16 relocation sequences") from the mips tree
and commit 9db0bbe072c8 ("MIPS: Fix module.c build for 32 bit") from the
rr tree.

Just context changes (I think).  I fixed it up (see below) and can carry
the fix as necessary.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/mips/kernel/module.c
index 4f8c3cb,8ffd089..000
--- a/arch/mips/kernel/module.c
+++ b/arch/mips/kernel/module.c
@@@ -132,25 -107,6 +105,17 @@@ static int apply_r_mips_hi16_rel(struc
return 0;
  }
  
- static int apply_r_mips_hi16_rela(struct module *me, u32 *location, Elf_Addr 
v)
- {
-   *location = (*location & 0x) |
-   long long) v + 0x8000LL) >> 16) & 0x);
- 
-   return 0;
- }
- 
 +static void free_relocation_chain(struct mips_hi16 *l)
 +{
 +  struct mips_hi16 *next;
 +
 +  while (l) {
 +  next = l->next;
 +  kfree(l);
 +  l = next;
 +  }
 +}
 +
  static int apply_r_mips_lo16_rel(struct module *me, u32 *location, Elf_Addr v)
  {
unsigned long insnlo = *location;
@@@ -308,61 -217,9 +229,22 @@@ int apply_relocate(Elf_Shdr *sechdrs, c
return res;
}
  
 +  /*
 +   * Normally the hi16 list should be deallocated at this point.  A
 +   * malformed binary however could contain a series of R_MIPS_HI16
 +   * relocations not followed by a R_MIPS_LO16 relocation.  In that
 +   * case, free up the list and return an error.
 +   */
 +  if (me->arch.r_mips_hi16_list) {
 +  free_relocation_chain(me->arch.r_mips_hi16_list);
 +  me->arch.r_mips_hi16_list = NULL;
 +
 +  return -ENOEXEC;
 +  }
 +
return 0;
  }
- 
- int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
-  unsigned int symindex, unsigned int relsec,
-  struct module *me)
- {
-   Elf_Mips_Rela *rel = (void *) sechdrs[relsec].sh_addr;
-   Elf_Sym *sym;
-   u32 *location;
-   unsigned int i;
-   Elf_Addr v;
-   int res;
- 
-   pr_debug("Applying relocate section %u to %u\n", relsec,
-  sechdrs[relsec].sh_info);
- 
-   for (i = 0; i < sechdrs[relsec].sh_size / sizeof(*rel); i++) {
-   /* This is where to make the change */
-   location = (void *)sechdrs[sechdrs[relsec].sh_info].sh_addr
-   + rel[i].r_offset;
-   /* This is the symbol it is referring to */
-   sym = (Elf_Sym *)sechdrs[symindex].sh_addr
-   + ELF_MIPS_R_SYM(rel[i]);
-   if (IS_ERR_VALUE(sym->st_value)) {
-   /* Ignore unresolved weak symbol */
-   if (ELF_ST_BIND(sym->st_info) == STB_WEAK)
-   continue;
-   printk(KERN_WARNING "%s: Unknown symbol %s\n",
-  me->name, strtab + sym->st_name);
-   return -ENOENT;
-   }
- 
-   v = sym->st_value + rel[i].r_addend;
- 
-   res = reloc_handlers_rela[ELF_MIPS_R_TYPE(rel[i])](me, 
location, v);
-   if (res)
-   return res;
-   }
- 
-   return 0;
- }
+ #endif
  
  /* Given an address, look for it in the module exception tables. */
  const struct exception_table_entry *search_module_dbetables(unsigned long 
addr)


pgpTKqPtCLMtG.pgp
Description: PGP signature

[PATCH] MIPS/mm: add compound tail page _mapcount when mapped

[Jovi Zhang]

>From 3dc19ea2b535719d0b4177f17bbbff9cbf257b23 Mon Sep 17 00:00:00 2001
From: Jovi Zhang 
Date: Wed, 22 Aug 2012 10:34:08 +0800
Subject: [PATCH] MIPS/mm: add compound tail page _mapcount when mapped

see commit b6999b191 which target for x86 mm/gup, let it align with
mips architecture.

Quote from commit b6999b191:
"If compound pages are used and the page is a
tail page, gup_huge_pmd() increases _mapcount to record tail page are
mapped while gup_huge_pud does not do that."

Signed-off-by: Jovi Zhang 
Cc: Youquan Song 
Cc: Andi Kleen 
Cc: 
---
 arch/mips/mm/gup.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/mips/mm/gup.c b/arch/mips/mm/gup.c
index 33aadbc..dcfd573 100644
--- a/arch/mips/mm/gup.c
+++ b/arch/mips/mm/gup.c
@@ -152,6 +152,8 @@ static int gup_huge_pud(pud_t pud, unsigned long
addr, unsigned long end,
do {
VM_BUG_ON(compound_head(page) != head);
pages[*nr] = page;
+   if (PageTail(page))
+   get_huge_page_tail(page);
(*nr)++;
page++;
refs++;
-- 
1.7.9.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] apple-gmux: Fix port address calculation in gmux_pio_write32()

[Seth Forshee]

This function fails to add the start address of the gmux I/O range to
the requested port address and thus writes to the wrong location.

Signed-off-by: Seth Forshee 
---
 drivers/platform/x86/apple-gmux.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/apple-gmux.c 
b/drivers/platform/x86/apple-gmux.c
index dfb1a92..ee21056 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -101,7 +101,7 @@ static void gmux_pio_write32(struct apple_gmux_data 
*gmux_data, int port,
 
for (i = 0; i < 4; i++) {
tmpval = (val >> (i * 8)) & 0xff;
-   outb(tmpval, port + i);
+   outb(tmpval, gmux_data->iostart + port + i);
}
 }
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: New tree -- linux-pstore.git

[Anton Vorontsov]

Hello Stephen,

Can you please add linux-pstore.git tree to the linux-next,
the repository address is as follows:

  git://git.infradead.org/users/cbou/linux-pstore.git master

This tree is dedicated to track pstore infrastructure fixes and
enhancements, currently it holds these commits:

Anton Vorontsov (3):
  pstore/ram: Fix possible NULL dereference
  pstore/ram: Mark ramoops_pstore_write_buf() as notrace
  MAINTAINERS: Add pstore maintainers

Jovi Zhang (1):
  pstore/ram: Add missing platform_device_unregister

Randy Dunlap (1):
  pstore/ram: Fix printk format warning


Thanks!

Anton.
--
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] pstore: add missed platform_device_unregister

[Anton Vorontsov]

On Tue, Aug 21, 2012 at 09:19:15AM -0700, Kees Cook wrote:
[...]
> >>  static void __exit ramoops_exit(void)
> >>  {
> >>   platform_driver_unregister(_driver);
> >> + platform_device_unregister(dummy);
> >>   kfree(dummy_data);
> >>  }
> >>  module_exit(ramoops_exit);
> >
> > It looks OK to me. Unless there are objections I'll apply it to
> > linux-pstore.git.
> 
> Yup, looks right.
> 
> Acked-by: Kees Cook 

Applied, 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: pci_get_subsys: GFP_KERNEL allocations with IRQs disabled

[Fengguang Wu]

Feng,

> I think it's pci_get_subsys() triggered this assert:
> 
> /*
>  * Oi! Can't be having __GFP_FS allocations with IRQs disabled.
>  */
> if (DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)))
> return;

It's bisected down to this commit:

commit 55c844a4dd16a4d1fdc0cf2a283ec631a02ec448
Author: Feng Tang 
AuthorDate: Wed May 30 23:15:41 2012 +0800
Commit: Ingo Molnar 
CommitDate: Wed Jun 6 12:03:23 2012 +0200

x86/reboot: Fix a warning message triggered by stop_other_cpus()

Thanks,
Fengguang

> [   91.282131] machine restart
> [   91.283895] [ cut here ]
> [   91.284731] WARNING: at /c/wfg/linux/kernel/lockdep.c:2739 
> lockdep_trace_alloc+0x1fb/0x210()
> [   91.286132] Modules linked in:
> [   91.286703] Pid: 697, comm: reboot Not tainted 3.5.0-00024-g01ff5db-dirty 
> #4
> [   91.287859] Call Trace:
> [   91.288289]  [<81050148>] warn_slowpath_common+0xb8/0x100
> [   91.289338]  [<8110acdb>] ? lockdep_trace_alloc+0x1fb/0x210
> [   91.290264]  [<8110acdb>] ? lockdep_trace_alloc+0x1fb/0x210
> [   91.291161]  [<810501ce>] warn_slowpath_null+0x3e/0x50
> [   91.292042]  [<8110acdb>] lockdep_trace_alloc+0x1fb/0x210
> [   91.292934]  [<81228e25>] kmem_cache_alloc_trace+0x55/0x600
> [   91.292934]  [<813025ca>] ? kobject_put+0x9a/0x160
> [   91.292934]  [<814e95e0>] ? klist_iter_exit+0x30/0x50
> [   91.292934]  [<81405881>] ? bus_find_device+0xf1/0x120
> [   91.292934]  [<81361a3c>] ? pci_get_subsys+0x11c/0x1b0
> [   91.292934]  [<81361a3c>] pci_get_subsys+0x11c/0x1b0
> [   91.292934]  [<81361afe>] pci_get_device+0x2e/0x40
> [   91.292934]  [<81033e25>] mach_reboot_fixups+0xa5/0xd0
> [   91.292934]  [<81027611>] native_machine_emergency_restart+0x1f1/0x590
> [   91.292934]  [<814f2e00>] ? printk+0x4b/0x5b
> [   91.292934]  [<810269ef>] native_machine_restart+0x6f/0x80
> [   91.292934]  [<810271cc>] machine_restart+0x1c/0x30
> [   91.292934]  [<810886e0>] kernel_restart+0x70/0xc0
> [   91.292934]  [<81088a85>] sys_reboot+0x325/0x380
> [   91.292934]  [<811f796c>] ? handle_pte_fault+0xdc/0x1740
> [   91.292934]  [<811f93e7>] ? handle_mm_fault+0x417/0x4a0
> [   91.292934]  [<8103e07b>] ? do_page_fault+0x7fb/0xb30
> [   91.292934]  [<810b33e7>] ? up_read+0x37/0x70
> [   91.292934]  [<8103e07b>] ? do_page_fault+0x7fb/0xb30
> [   91.292934]  [<8123c063>] ? do_sys_open+0x3a3/0x3f0
> [   91.292934]  [<8123c063>] ? do_sys_open+0x3a3/0x3f0
> [   91.292934]  [<810b0270>] ? update_rmtp+0xe0/0xe0
> [   91.292934]  [<8150376e>] ? restore_all+0xf/0xf
> [   91.292934]  [<8103d880>] ? vmalloc_sync_all+0x320/0x320
> [   91.292934]  [<81109fca>] ? trace_hardirqs_on_caller+0x28a/0x380
> [   91.292934]  [<81311594>] ? trace_hardirqs_on_thunk+0xc/0x10
> [   91.292934]  [<81503735>] syscall_call+0x7/0xb
> 
> Thanks,
> Fengguang
--
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 v5 2/2] driver: add PPI support in tpm driver

[xiaoyan . zhang]

From: Xiaoyan Zhang 

The Physical Presence Interface enables the OS and the BIOS to cooperate and
provides a simple and straightforward platform user experience for
administering the TPM without sacrificing security.

V2: separate the patch out in a separate source file,
add #ifdef CONFIG_ACPI so it compiles out on ppc,
use standard error instead of ACPI error as return code of show/store fns.
V3: move #ifdef CONFIG_ACPI from .c file to .h file.
V4: move tpm_ppi code from tpm module to tpm_bios module.
V5: modify sys_add_ppi() so that ppi_attr_grp doesn't need to be exported

Signed-off-by: Xiaoyan Zhang 
---
 drivers/char/tpm/Makefile  |2 +-
 drivers/char/tpm/tpm.c |5 +
 drivers/char/tpm/tpm.h |9 +
 drivers/char/tpm/tpm_ppi.c |  460 
 4 files changed, 475 insertions(+), 1 deletions(-)
 create mode 100644 drivers/char/tpm/tpm_ppi.c

diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
index 9080cc4..5b3fc8b 100644
--- a/drivers/char/tpm/Makefile
+++ b/drivers/char/tpm/Makefile
@@ -4,7 +4,7 @@
 obj-$(CONFIG_TCG_TPM) += tpm.o
 ifdef CONFIG_ACPI
obj-$(CONFIG_TCG_TPM) += tpm_bios.o
-   tpm_bios-objs += tpm_eventlog.o tpm_acpi.o
+   tpm_bios-objs += tpm_eventlog.o tpm_acpi.o tpm_ppi.o
 else
 ifdef CONFIG_TCG_IBMVTPM
obj-$(CONFIG_TCG_TPM) += tpm_bios.o
diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c
index 0a75638..39526c0 100644
--- a/drivers/char/tpm/tpm.c
+++ b/drivers/char/tpm/tpm.c
@@ -1476,6 +1476,11 @@ struct tpm_chip *tpm_register_hardware(struct device 
*dev,
goto put_device;
}
 
+   if (sys_add_ppi(>kobj)) {
+   misc_deregister(>vendor.miscdev);
+   goto put_device;
+   }
+
chip->bios_dir = tpm_bios_log_setup(devname);
 
/* Make chip available */
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index f1af738..02c266a 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -327,3 +327,12 @@ extern int tpm_pm_suspend(struct device *);
 extern int tpm_pm_resume(struct device *);
 extern int wait_for_tpm_stat(struct tpm_chip *, u8, unsigned long,
 wait_queue_head_t *);
+
+#ifdef CONFIG_ACPI
+extern ssize_t sys_add_ppi(struct kobject *parent);
+#else
+static inline ssize_t sys_add_ppi(struct kobject *parent)
+{
+   return 0;
+}
+#endif
diff --git a/drivers/char/tpm/tpm_ppi.c b/drivers/char/tpm/tpm_ppi.c
new file mode 100644
index 000..440fa1c
--- /dev/null
+++ b/drivers/char/tpm/tpm_ppi.c
@@ -0,0 +1,460 @@
+#include 
+#include 
+#include "tpm.h"
+
+static const u8 tpm_ppi_uuid[] = {
+   0xA6, 0xFA, 0xDD, 0x3D,
+   0x1B, 0x36,
+   0xB4, 0x4E,
+   0xA4, 0x24,
+   0x8D, 0x10, 0x08, 0x9D, 0x16, 0x53
+};
+static char *tpm_device_name = "TPM";
+
+#define TPM_PPI_REVISION_ID1
+#define TPM_PPI_FN_VERSION 1
+#define TPM_PPI_FN_SUBREQ  2
+#define TPM_PPI_FN_GETREQ  3
+#define TPM_PPI_FN_GETACT  4
+#define TPM_PPI_FN_GETRSP  5
+#define TPM_PPI_FN_SUBREQ2 7
+#define TPM_PPI_FN_GETOPR  8
+#define PPI_TPM_REQ_MAX22
+#define PPI_VS_REQ_START   128
+#define PPI_VS_REQ_END 255
+#define PPI_VERSION_LEN3
+
+static acpi_status ppi_callback(acpi_handle handle, u32 level, void *context,
+   void **return_value)
+{
+   acpi_status status;
+   struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+   status = acpi_get_name(handle, ACPI_FULL_PATHNAME, );
+   if (strstr(buffer.pointer, context) != NULL) {
+   *return_value = handle;
+   kfree(buffer.pointer);
+   return AE_CTRL_TERMINATE;
+   }
+   return AE_OK;
+}
+
+static inline void ppi_assign_params(union acpi_object params[4],
+u64 function_num)
+{
+   params[0].type = ACPI_TYPE_BUFFER;
+   params[0].buffer.length = sizeof(tpm_ppi_uuid);
+   params[0].buffer.pointer = (char *)tpm_ppi_uuid;
+   params[1].type = ACPI_TYPE_INTEGER;
+   params[1].integer.value = TPM_PPI_REVISION_ID;
+   params[2].type = ACPI_TYPE_INTEGER;
+   params[2].integer.value = function_num;
+   params[3].type = ACPI_TYPE_PACKAGE;
+   params[3].package.count = 0;
+   params[3].package.elements = NULL;
+}
+
+ssize_t tpm_show_ppi_version(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+   acpi_handle handle;
+   acpi_status status;
+   struct acpi_object_list input;
+   struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
+   union acpi_object params[4];
+   union acpi_object *obj;
+
+   input.count = 4;
+   ppi_assign_params(params, TPM_PPI_FN_VERSION);
+   input.pointer = params;
+   status = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
+ACPI_UINT32_MAX, 

[PATCH v5 1/2] Documentation: sysfs for Physical Presence Interface

[xiaoyan . zhang]

From: Xiaoyan Zhang 


Signed-off-by: Xiaoyan Zhang 
---
 Documentation/ABI/testing/sysfs-driver-ppi |   70 
 1 files changed, 70 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-ppi

diff --git a/Documentation/ABI/testing/sysfs-driver-ppi 
b/Documentation/ABI/testing/sysfs-driver-ppi
new file mode 100644
index 000..97a003e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-ppi
@@ -0,0 +1,70 @@
+What:  /sys/devices/pnp0//ppi/
+Date:  August 2012
+Kernel Version:3.6
+Contact:   xiaoyan.zh...@intel.com
+Description:
+   This folder includes the attributes related with PPI (Physical
+   Presence Interface). Only if TPM is supported by BIOS, this
+   folder makes sence. The folder path can be got by command
+   'find /sys/ -name 'pcrs''. For the detail information of PPI,
+   please refer to the PPI specification from
+   http://www.trustedcomputinggroup.org/
+
+What:  /sys/devices/pnp0//ppi/version
+Date:  August 2012
+Contact:   xiaoyan.zh...@intel.com
+Description:
+   This attribute shows the version of the PPI supported by the
+   platform.
+   This file is readonly.
+
+What:  /sys/devices/pnp0//ppi/request
+Date:  August 2012
+Contact:   xiaoyan.zh...@intel.com
+Description:
+   This attribute shows the request for an operation to be
+   executed in the pre-OS environment. It is the only input from
+   the OS to the pre-OS environment. The request should be an
+   integer value range from 1 to 160, and 0 means no request.
+   This file can be read and written.
+
+What:  /sys/devices/pnp0/00:/ppi/response
+Date:  August 2012
+Contact:   xiaoyan.zh...@intel.com
+Description:
+   This attribute shows the response to the most recent operation
+   request it acted upon. The format is " 
+   : ".
+   This file is readonly.
+
+What:  /sys/devices/pnp0//ppi/transition_action
+Date:  August 2012
+Contact:   xiaoyan.zh...@intel.com
+Description:
+   This attribute shows the platform-specific action that should
+   take place in order to transition to the BIOS for execution of
+   a requested operation. The format is ": ".
+   This file is readonly.
+
+What:  /sys/devices/pnp0//ppi/tcg_operations
+Date:  August 2012
+Contact:   xiaoyan.zh...@intel.com
+Description:
+   This attribute shows whether it is allowed to request an
+   operation to be executed in the pre-OS environment by the BIOS
+   for the requests defined by TCG, i.e. requests from 1 to 22.
+   The format is " : ".
+   This attribute is only supported by PPI version 1.2+.
+   This file is readonly.
+
+What:  /sys/devices/pnp0//ppi/vs_operations
+Date:  August 2012
+Contact:   xiaoyan.zh...@intel.com
+Description:
+   This attribute shows whether it is allowed to request an
+   operation to be executed in the pre-OS environment by the BIOS
+   for the verdor specific requests, i.e. requests from 128 to
+   255. The format is same with tcg_operations. This attribute
+   is also only supported by PPI version 1.2+.
+   This file is readonly.
-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 0/2] Add PPI support in tpm driver

[xiaoyan . zhang]

From: Xiaoyan Zhang 

The Physical Presence Interface enables the OS and the BIOS to cooperate to
provide a simple and straightforward platform user experience for
administering the TPM without sacrificing security.

Xiaoyan Zhang (2):
  Documentation: sysfs for Physical Presence Interface
  driver: add PPI support in tpm driver

 Documentation/ABI/testing/sysfs-driver-ppi |   70 +
 drivers/char/tpm/Makefile  |2 +-
 drivers/char/tpm/tpm.c |5 +
 drivers/char/tpm/tpm.h |9 +
 drivers/char/tpm/tpm_ppi.c |  460 
 5 files changed, 545 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-ppi
 create mode 100644 drivers/char/tpm/tpm_ppi.c

-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] leds-lp5523: add channel name in the platform data

[Bryan Wu]

On Tue, Aug 21, 2012 at 5:03 PM, Kim, Milo  wrote:
> The name of each led channel is configurable.
> If the name is NULL, just use the channel id for making the channel name
>
> Signed-off-by: Milo(Woogyom) Kim 
> ---
>  Documentation/leds/leds-lp5523.txt |7 +--
>  drivers/leds/leds-lp5523.c |   10 +++---
>  include/linux/leds-lp5523.h|1 +
>  3 files changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/leds/leds-lp5523.txt 
> b/Documentation/leds/leds-lp5523.txt
> index fad2feb..e958d9a 100644
> --- a/Documentation/leds/leds-lp5523.txt
> +++ b/Documentation/leds/leds-lp5523.txt
> @@ -10,7 +10,9 @@ Contact: Samu Onkalo (samu.p.onkalo-at-nokia.com)
>  Description
>  ---
>  LP5523 can drive up to 9 channels. Leds can be controlled directly via
> -the led class control interface. Channels have generic names:
> +the led class control interface.
> +The name of each channel is configurable in the platform data.
> +If the name is NULL, channels have generic names:
>  lp5523:channelx where x is 0...8
>
>  The chip provides 3 engines. Each engine can control channels without
> @@ -46,12 +48,13 @@ Note - chan_nr can have values between 0 and 8.
>
>  static struct lp5523_led_config lp5523_led_config[] = {
>  {
> +   .name   = "red",
>  .chan_nr= 0,
>  .led_current= 50,
> .max_current= 130,
>  },
>  ...
> -}, {
> +{
>  .chan_nr= 8,
>  .led_current= 50,
> .max_current= 130,
> diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
> index fbc12ac..9fd9a92 100644
> --- a/drivers/leds/leds-lp5523.c
> +++ b/drivers/leds/leds-lp5523.c
> @@ -846,10 +846,14 @@ static int __devinit lp5523_init_led(struct lp5523_led 
> *led, struct device *dev,
> return -EINVAL;
> }
>
> -   snprintf(name, sizeof(name), "%s:channel%d",
> -   pdata->label ?: "lp5523", chan);
> +   if (pdata->led_config[chan].name) {
> +   led->cdev.name = pdata->led_config[chan].name;
> +   } else {
> +   snprintf(name, sizeof(name), "%s:channel%d",
> +   pdata->label ?: "lp5523", chan);

Why we need a test here "pdata->label ?:"? From the document, looks
like we use lp5523:channel%d as default.

> +   led->cdev.name = name;
> +   }
>
> -   led->cdev.name = name;
> led->cdev.brightness_set = lp5523_set_brightness;
> res = led_classdev_register(dev, >cdev);
> if (res < 0) {
> diff --git a/include/linux/leds-lp5523.h b/include/linux/leds-lp5523.h
> index 2694289..727877f 100644
> --- a/include/linux/leds-lp5523.h
> +++ b/include/linux/leds-lp5523.h
> @@ -26,6 +26,7 @@
>  /* See Documentation/leds/leds-lp5523.txt */
>
>  struct lp5523_led_config {
> +   const char  *name;
> u8  chan_nr;
> u8  led_current; /* mA x10, 0 if led is not connected */
> u8  max_current;
> --
> 1.7.2.5
>
>
> Best Regards,
> Milo
>
>



-- 
Bryan Wu 
Kernel Developer+86.186-168-78255 Mobile
Canonical Ltd.  www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] sched: unify the check on atomic sleeping in __might_sleep() and schedule_bug()

[Michael Wang]

From: Michael Wang 

Fengguang Wu  has reported the bug:

[0.043953] BUG: scheduling while atomic: swapper/0/1/0x1002
[0.044017] no locks held by swapper/0/1.
[0.044692] Pid: 1, comm: swapper/0 Not tainted 3.6.0-rc1-00420-gb7aebb9 #34
[0.045861] Call Trace:
[0.048071]  [] __schedule_bug+0x5e/0x70
[0.048890]  [] __schedule+0x91/0xb10
[0.049660]  [] ? vsnprintf+0x33a/0x450
[0.050444]  [] ? lg_local_lock+0x6/0x70
[0.051256]  [] ? wait_for_xmitr+0x31/0x90
[0.052019]  [] ? do_raw_spin_unlock+0xa5/0xf0
[0.052903]  [] ? _raw_spin_unlock+0x22/0x30
[0.053759]  [] ? up+0x1b/0x70
[0.054421]  [] __cond_resched+0x1b/0x30
[0.055228]  [] _cond_resched+0x45/0x50
[0.056020]  [] mutex_lock_nested+0x28/0x370
[0.056884]  [] ? console_unlock+0x3a2/0x4e0
[0.057741]  [] __irq_alloc_descs+0x39/0x1c0
[0.058589]  [] io_apic_setup_irq_pin+0x2c/0x310
[0.060042]  [] setup_IO_APIC+0x101/0x744
[0.060878]  [] ? clear_IO_APIC+0x31/0x50
[0.061695]  [] native_smp_prepare_cpus+0x538/0x680
[0.062644]  [] ? do_one_initcall+0x12c/0x12c
[0.063517]  [] ? do_one_initcall+0x12c/0x12c
[0.064016]  [] kernel_init+0x4b/0x17f
[0.064790]  [] ? do_one_initcall+0x12c/0x12c
[0.065660]  [] kernel_thread_helper+0x6/0x10

It was caused by that:

native_smp_prepare_cpus()
preempt_disable()   //preempt_count++
mutex_lock()//in __irq_alloc_descs
__might_sleep() //system is booting, avoid check
might_resched()
__schedule()
preempt_disable()   //preempt_count++
schedule_bug()  //preempt_count > 1, report bug

The __might_sleep() avoid check on atomic sleeping until the system booted
while the schedule_bug() doesn't, it's the reason for the bug.

This patch will add one additional check in schedule_bug() to avoid check
until the system booted, so the check on atomic sleeping will be unified.

Signed-off-by: Michael Wang 
Tested-by: Fengguang Wu 
---
 kernel/sched/core.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 4376c9f..3396c33 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3321,7 +3321,8 @@ static inline void schedule_debug(struct task_struct 
*prev)
 * schedule() atomically, we ignore that path for now.
 * Otherwise, whine if we are scheduling when we should not be.
 */
-   if (unlikely(in_atomic_preempt_off() && !prev->exit_state))
+   if (unlikely(in_atomic_preempt_off() && !prev->exit_state
+   && system_state == SYSTEM_RUNNING))
__schedule_bug(prev);
rcu_sleep_check();
 
-- 
1.7.4.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] tty: move the async flags from the serial code into the tty includes

[Huang Shijie]

On Tue, Aug 21, 2012 at 9:35 PM, Alan Cox  wrote:
> Huang - how about we add this patch first which moves the flags somewhere 
> more sensible
> and then your helper function (and probably a few others) would merge cleanly 
> ?
>
Allen, Could you post a formal patch?
I can change my patch based on it.

thanks
Huang Shijie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 02/17] userns: use new hashtable implementation

[Sasha Levin]

Switch to using the new hashtable implementation to store user structs.
This reduces the amount of generic unrelated code in kernel/user.c.

Signed-off-by: Sasha Levin 
---
 kernel/user.c |   33 +
 1 files changed, 13 insertions(+), 20 deletions(-)

diff --git a/kernel/user.c b/kernel/user.c
index b815fef..d10c484 100644
--- a/kernel/user.c
+++ b/kernel/user.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * userns count is 1 for root user, 1 for init_uts_ns,
@@ -52,13 +53,9 @@ EXPORT_SYMBOL_GPL(init_user_ns);
  */
 
 #define UIDHASH_BITS   (CONFIG_BASE_SMALL ? 3 : 7)
-#define UIDHASH_SZ (1 << UIDHASH_BITS)
-#define UIDHASH_MASK   (UIDHASH_SZ - 1)
-#define __uidhashfn(uid)   (((uid >> UIDHASH_BITS) + uid) & UIDHASH_MASK)
-#define uidhashentry(uid)  (uidhash_table + __uidhashfn((__kuid_val(uid
 
 static struct kmem_cache *uid_cachep;
-struct hlist_head uidhash_table[UIDHASH_SZ];
+static DEFINE_HASHTABLE(uidhash_table, UIDHASH_BITS)
 
 /*
  * The uidhash_lock is mostly taken from process context, but it is
@@ -84,22 +81,22 @@ struct user_struct root_user = {
 /*
  * These routines must be called with the uidhash spinlock held!
  */
-static void uid_hash_insert(struct user_struct *up, struct hlist_head *hashent)
+static void uid_hash_insert(struct user_struct *up)
 {
-   hlist_add_head(>uidhash_node, hashent);
+   hash_add(uidhash_table, >uidhash_node, __kuid_val(up->uid));
 }
 
 static void uid_hash_remove(struct user_struct *up)
 {
-   hlist_del_init(>uidhash_node);
+   hash_del(>uidhash_node);
 }
 
-static struct user_struct *uid_hash_find(kuid_t uid, struct hlist_head 
*hashent)
+static struct user_struct *uid_hash_find(kuid_t uid)
 {
struct user_struct *user;
struct hlist_node *h;
 
-   hlist_for_each_entry(user, h, hashent, uidhash_node) {
+   hash_for_each_possible(uidhash_table, user, h, uidhash_node, 
__kuid_val(uid)) {
if (uid_eq(user->uid, uid)) {
atomic_inc(>__count);
return user;
@@ -135,7 +132,7 @@ struct user_struct *find_user(kuid_t uid)
unsigned long flags;
 
spin_lock_irqsave(_lock, flags);
-   ret = uid_hash_find(uid, uidhashentry(uid));
+   ret = uid_hash_find(uid);
spin_unlock_irqrestore(_lock, flags);
return ret;
 }
@@ -156,11 +153,10 @@ void free_uid(struct user_struct *up)
 
 struct user_struct *alloc_uid(kuid_t uid)
 {
-   struct hlist_head *hashent = uidhashentry(uid);
struct user_struct *up, *new;
 
spin_lock_irq(_lock);
-   up = uid_hash_find(uid, hashent);
+   up = uid_hash_find(uid);
spin_unlock_irq(_lock);
 
if (!up) {
@@ -176,13 +172,13 @@ struct user_struct *alloc_uid(kuid_t uid)
 * on adding the same user already..
 */
spin_lock_irq(_lock);
-   up = uid_hash_find(uid, hashent);
+   up = uid_hash_find(uid);
if (up) {
key_put(new->uid_keyring);
key_put(new->session_keyring);
kmem_cache_free(uid_cachep, new);
} else {
-   uid_hash_insert(new, hashent);
+   uid_hash_insert(new);
up = new;
}
spin_unlock_irq(_lock);
@@ -196,17 +192,14 @@ out_unlock:
 
 static int __init uid_cache_init(void)
 {
-   int n;
-
uid_cachep = kmem_cache_create("uid_cache", sizeof(struct user_struct),
0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
 
-   for(n = 0; n < UIDHASH_SZ; ++n)
-   INIT_HLIST_HEAD(uidhash_table + n);
+   hash_init(uidhash_table);
 
/* Insert the root user immediately (init already runs as root) */
spin_lock_irq(_lock);
-   uid_hash_insert(_user, uidhashentry(GLOBAL_ROOT_UID));
+   uid_hash_insert(_user);
spin_unlock_irq(_lock);
 
return 0;
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 07/17] net,9p: use new hashtable implementation

[Sasha Levin]

Switch 9p error table to use the new hashtable implementation. This reduces the 
amount of
generic unrelated code in 9p.

Signed-off-by: Sasha Levin 
---
 net/9p/error.c |   21 ++---
 1 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/net/9p/error.c b/net/9p/error.c
index 2ab2de7..a5cc7dd 100644
--- a/net/9p/error.c
+++ b/net/9p/error.c
@@ -34,7 +34,7 @@
 #include 
 #include 
 #include 
-
+#include 
 /**
  * struct errormap - map string errors from Plan 9 to Linux numeric ids
  * @name: string sent over 9P
@@ -50,8 +50,8 @@ struct errormap {
struct hlist_node list;
 };
 
-#define ERRHASHSZ  32
-static struct hlist_head hash_errmap[ERRHASHSZ];
+#define ERR_HASH_BITS 5
+static DEFINE_HASHTABLE(hash_errmap, ERR_HASH_BITS);
 
 /* FixMe - reduce to a reasonable size */
 static struct errormap errmap[] = {
@@ -193,18 +193,17 @@ static struct errormap errmap[] = {
 int p9_error_init(void)
 {
struct errormap *c;
-   int bucket;
+   u32 hash;
 
/* initialize hash table */
-   for (bucket = 0; bucket < ERRHASHSZ; bucket++)
-   INIT_HLIST_HEAD(_errmap[bucket]);
+   hash_init(hash_errmap);
 
/* load initial error map into hash table */
for (c = errmap; c->name != NULL; c++) {
c->namelen = strlen(c->name);
-   bucket = jhash(c->name, c->namelen, 0) % ERRHASHSZ;
+   hash = jhash(c->name, c->namelen, 0);
INIT_HLIST_NODE(>list);
-   hlist_add_head(>list, _errmap[bucket]);
+   hash_add(hash_errmap, >list, hash);
}
 
return 1;
@@ -223,13 +222,13 @@ int p9_errstr2errno(char *errstr, int len)
int errno;
struct hlist_node *p;
struct errormap *c;
-   int bucket;
+   u32 hash;
 
errno = 0;
p = NULL;
c = NULL;
-   bucket = jhash(errstr, len, 0) % ERRHASHSZ;
-   hlist_for_each_entry(c, p, _errmap[bucket], list) {
+   hash = jhash(errstr, len, 0);
+   hash_for_each_possible(hash_errmap, c, p, list, hash) {
if (c->namelen == len && !memcmp(c->name, errstr, len)) {
errno = c->val;
break;
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 10/17] dlm: use new hashtable implementation

[Sasha Levin]

Switch dlm to use the new hashtable implementation. This reduces the amount of
generic unrelated code in the dlm.

Signed-off-by: Sasha Levin 
---
 fs/dlm/lowcomms.c |   47 +--
 1 files changed, 13 insertions(+), 34 deletions(-)

diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
index 331ea4f..9f21774 100644
--- a/fs/dlm/lowcomms.c
+++ b/fs/dlm/lowcomms.c
@@ -55,6 +55,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "dlm_internal.h"
 #include "lowcomms.h"
@@ -62,7 +63,7 @@
 #include "config.h"
 
 #define NEEDED_RMEM (4*1024*1024)
-#define CONN_HASH_SIZE 32
+#define CONN_HASH_BITS 5
 
 /* Number of messages to send before rescheduling */
 #define MAX_SEND_MSG_COUNT 25
@@ -158,34 +159,21 @@ static int dlm_allow_conn;
 static struct workqueue_struct *recv_workqueue;
 static struct workqueue_struct *send_workqueue;
 
-static struct hlist_head connection_hash[CONN_HASH_SIZE];
+static struct hlist_head connection_hash[CONN_HASH_BITS];
 static DEFINE_MUTEX(connections_lock);
 static struct kmem_cache *con_cache;
 
 static void process_recv_sockets(struct work_struct *work);
 static void process_send_sockets(struct work_struct *work);
 
-
-/* This is deliberately very simple because most clusters have simple
-   sequential nodeids, so we should be able to go straight to a connection
-   struct in the array */
-static inline int nodeid_hash(int nodeid)
-{
-   return nodeid & (CONN_HASH_SIZE-1);
-}
-
 static struct connection *__find_con(int nodeid)
 {
-   int r;
struct hlist_node *h;
struct connection *con;
 
-   r = nodeid_hash(nodeid);
-
-   hlist_for_each_entry(con, h, _hash[r], list) {
+   hash_for_each_possible(connection_hash, con, h, list, nodeid)
if (con->nodeid == nodeid)
return con;
-   }
return NULL;
 }
 
@@ -196,7 +184,6 @@ static struct connection *__find_con(int nodeid)
 static struct connection *__nodeid2con(int nodeid, gfp_t alloc)
 {
struct connection *con = NULL;
-   int r;
 
con = __find_con(nodeid);
if (con || !alloc)
@@ -206,8 +193,7 @@ static struct connection *__nodeid2con(int nodeid, gfp_t 
alloc)
if (!con)
return NULL;
 
-   r = nodeid_hash(nodeid);
-   hlist_add_head(>list, _hash[r]);
+   hash_add(connection_hash, >list, nodeid);
 
con->nodeid = nodeid;
mutex_init(>sock_mutex);
@@ -235,11 +221,8 @@ static void foreach_conn(void (*conn_func)(struct 
connection *c))
struct hlist_node *h, *n;
struct connection *con;
 
-   for (i = 0; i < CONN_HASH_SIZE; i++) {
-   hlist_for_each_entry_safe(con, h, n, _hash[i], list){
-   conn_func(con);
-   }
-   }
+   hash_for_each_safe(connection_hash, i, h, n, con, list)
+   conn_func(con);
 }
 
 static struct connection *nodeid2con(int nodeid, gfp_t allocation)
@@ -262,12 +245,10 @@ static struct connection *assoc2con(int assoc_id)
 
mutex_lock(_lock);
 
-   for (i = 0 ; i < CONN_HASH_SIZE; i++) {
-   hlist_for_each_entry(con, h, _hash[i], list) {
-   if (con->sctp_assoc == assoc_id) {
-   mutex_unlock(_lock);
-   return con;
-   }
+   hash_for_each(connection_hash, i, h, con, list) {
+   if (con->sctp_assoc == assoc_id) {
+   mutex_unlock(_lock);
+   return con;
}
}
mutex_unlock(_lock);
@@ -1638,7 +1619,7 @@ static void free_conn(struct connection *con)
close_connection(con, true);
if (con->othercon)
kmem_cache_free(con_cache, con->othercon);
-   hlist_del(>list);
+   hash_del(>list);
kmem_cache_free(con_cache, con);
 }
 
@@ -1667,10 +1648,8 @@ int dlm_lowcomms_start(void)
 {
int error = -EINVAL;
struct connection *con;
-   int i;
 
-   for (i = 0; i < CONN_HASH_SIZE; i++)
-   INIT_HLIST_HEAD(_hash[i]);
+   hash_init(connection_hash);
 
init_local();
if (!dlm_local_count) {
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for July 26 (uml)

[Rusty Russell]

On Tue, 21 Aug 2012 10:43:59 -0700, Randy Dunlap  wrote:
> On 08/19/2012 07:51 PM, Rusty Russell wrote:
> 
> > On Tue, 14 Aug 2012 10:41:42 -0700, Randy Dunlap  
> > wrote:
> >> On 08/14/2012 08:17 AM, Richard Weinberger wrote:
> >>
> >>> Am 14.08.2012 17:15, schrieb David Howells:
> >>>> How about this then?
> >>>>
> >>>> David
> >>>> ---
> >>>> diff --git a/arch/x86/um/Kconfig b/arch/x86/um/Kconfig
> >>>> index 9926e11..a4b0c10 100644
> >>>> --- a/arch/x86/um/Kconfig
> >>>> +++ b/arch/x86/um/Kconfig
> >>>> @@ -21,9 +21,11 @@ config 64BIT
> >>>>  config X86_32
> >>>>  def_bool !64BIT
> >>>>  select HAVE_AOUT
> >>>> +select MODULES_USE_ELF_REL
> >>>>  
> >>>>  config X86_64
> >>>>  def_bool 64BIT
> >>>> +select MODULES_USE_ELF_RELA
> >>>>  
> >>>>  config RWSEM_XCHGADD_ALGORITHM
> >>>>  def_bool X86_XADD && 64BIT
> >>>
> >>> Looks sane.
> >>>
> >>> Acked-by: Richard Weinberger 
> >>
> >>
> >> Acked-by: Randy Dunlap 
> > 
> > Thanks, folded into David's original patch.
> 
> 
> When will this be fixed in linux-next?
> 
> linux-next of 20120821 still fails.

Should be in latest, ie. 20120822.

Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 15/17] openvswitch: use new hashtable implementation

[Sasha Levin]

Switch openvswitch to use the new hashtable implementation. This reduces the 
amount of
generic unrelated code in openvswitch.

Signed-off-by: Sasha Levin 
---
 net/openvswitch/vport.c |   30 +-
 1 files changed, 13 insertions(+), 17 deletions(-)

diff --git a/net/openvswitch/vport.c b/net/openvswitch/vport.c
index 6140336..3484120 100644
--- a/net/openvswitch/vport.c
+++ b/net/openvswitch/vport.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "vport.h"
 #include "vport-internal_dev.h"
@@ -39,8 +40,8 @@ static const struct vport_ops *vport_ops_list[] = {
 };
 
 /* Protected by RCU read lock for reading, RTNL lock for writing. */
-static struct hlist_head *dev_table;
-#define VPORT_HASH_BUCKETS 1024
+#define VPORT_HASH_BITS 10
+static DEFINE_HASHTABLE(dev_table, VPORT_HASH_BITS);
 
 /**
  * ovs_vport_init - initialize vport subsystem
@@ -49,10 +50,7 @@ static struct hlist_head *dev_table;
  */
 int ovs_vport_init(void)
 {
-   dev_table = kzalloc(VPORT_HASH_BUCKETS * sizeof(struct hlist_head),
-   GFP_KERNEL);
-   if (!dev_table)
-   return -ENOMEM;
+   hash_init(dev_table);
 
return 0;
 }
@@ -67,12 +65,6 @@ void ovs_vport_exit(void)
kfree(dev_table);
 }
 
-static struct hlist_head *hash_bucket(const char *name)
-{
-   unsigned int hash = full_name_hash(name, strlen(name));
-   return _table[hash & (VPORT_HASH_BUCKETS - 1)];
-}
-
 /**
  * ovs_vport_locate - find a port that has already been created
  *
@@ -82,11 +74,11 @@ static struct hlist_head *hash_bucket(const char *name)
  */
 struct vport *ovs_vport_locate(const char *name)
 {
-   struct hlist_head *bucket = hash_bucket(name);
struct vport *vport;
struct hlist_node *node;
+   int key = full_name_hash(name, strlen(name));
 
-   hlist_for_each_entry_rcu(vport, node, bucket, hash_node)
+   hash_for_each_possible_rcu(dev_table, vport, node, hash_node, key)
if (!strcmp(name, vport->ops->get_name(vport)))
return vport;
 
@@ -170,14 +162,18 @@ struct vport *ovs_vport_add(const struct vport_parms 
*parms)
 
for (i = 0; i < ARRAY_SIZE(vport_ops_list); i++) {
if (vport_ops_list[i]->type == parms->type) {
+   int key;
+   const char *name;
+
vport = vport_ops_list[i]->create(parms);
if (IS_ERR(vport)) {
err = PTR_ERR(vport);
goto out;
}
 
-   hlist_add_head_rcu(>hash_node,
-  
hash_bucket(vport->ops->get_name(vport)));
+   name = vport->ops->get_name(vport);
+   key = full_name_hash(name, strlen(name));
+   hash_add_rcu(dev_table, >hash_node, key);
return vport;
}
}
@@ -218,7 +214,7 @@ void ovs_vport_del(struct vport *vport)
 {
ASSERT_RTNL();
 
-   hlist_del_rcu(>hash_node);
+   hash_del_rcu(>hash_node);
 
vport->ops->destroy(vport);
 }
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 17/17] SUNRPC: use new hashtable implementation in auth

[Sasha Levin]

Switch sunrpc/auth.c  to use the new hashtable implementation. This reduces the 
amount of
generic unrelated code in auth.c.

Signed-off-by: Sasha Levin 
---
 net/sunrpc/auth.c |   45 +++--
 1 files changed, 19 insertions(+), 26 deletions(-)

diff --git a/net/sunrpc/auth.c b/net/sunrpc/auth.c
index b5c067b..5d50e2d 100644
--- a/net/sunrpc/auth.c
+++ b/net/sunrpc/auth.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef RPC_DEBUG
 # define RPCDBG_FACILITY   RPCDBG_AUTH
@@ -222,7 +223,7 @@ static DEFINE_SPINLOCK(rpc_credcache_lock);
 static void
 rpcauth_unhash_cred_locked(struct rpc_cred *cred)
 {
-   hlist_del_rcu(>cr_hash);
+   hash_del_rcu(>cr_hash);
smp_mb__before_clear_bit();
clear_bit(RPCAUTH_CRED_HASHED, >cr_flags);
 }
@@ -249,16 +250,15 @@ int
 rpcauth_init_credcache(struct rpc_auth *auth)
 {
struct rpc_cred_cache *new;
-   unsigned int hashsize;
 
new = kmalloc(sizeof(*new), GFP_KERNEL);
if (!new)
goto out_nocache;
new->hashbits = auth_hashbits;
-   hashsize = 1U << new->hashbits;
-   new->hashtable = kcalloc(hashsize, sizeof(new->hashtable[0]), 
GFP_KERNEL);
+   new->hashtable = kmalloc(HASH_REQUIRED_SIZE(new->hashbits), GFP_KERNEL);
if (!new->hashtable)
goto out_nohashtbl;
+   hash_init_size(new->hashtable, new->hashbits);
spin_lock_init(>lock);
auth->au_credcache = new;
return 0;
@@ -292,25 +292,20 @@ void
 rpcauth_clear_credcache(struct rpc_cred_cache *cache)
 {
LIST_HEAD(free);
-   struct hlist_head *head;
+   struct hlist_node *n, *t;
struct rpc_cred *cred;
-   unsigned int hashsize = 1U << cache->hashbits;
-   int i;
+   int i;
 
spin_lock(_credcache_lock);
spin_lock(>lock);
-   for (i = 0; i < hashsize; i++) {
-   head = >hashtable[i];
-   while (!hlist_empty(head)) {
-   cred = hlist_entry(head->first, struct rpc_cred, 
cr_hash);
-   get_rpccred(cred);
-   if (!list_empty(>cr_lru)) {
-   list_del(>cr_lru);
-   number_cred_unused--;
-   }
-   list_add_tail(>cr_lru, );
-   rpcauth_unhash_cred_locked(cred);
+   hash_for_each_safe_size(cache->hashtable, cache->hashbits, i, n, t, 
cred, cr_hash) {
+   get_rpccred(cred);
+   if (!list_empty(>cr_lru)) {
+   list_del(>cr_lru);
+   number_cred_unused--;
}
+   list_add_tail(>cr_lru, );
+   rpcauth_unhash_cred_locked(cred);
}
spin_unlock(>lock);
spin_unlock(_credcache_lock);
@@ -408,14 +403,11 @@ rpcauth_lookup_credcache(struct rpc_auth *auth, struct 
auth_cred * acred,
LIST_HEAD(free);
struct rpc_cred_cache *cache = auth->au_credcache;
struct hlist_node *pos;
-   struct rpc_cred *cred = NULL,
-   *entry, *new;
-   unsigned int nr;
-
-   nr = hash_long(acred->uid, cache->hashbits);
+   struct rpc_cred *cred = NULL, *entry = NULL, *new;
 
rcu_read_lock();
-   hlist_for_each_entry_rcu(entry, pos, >hashtable[nr], cr_hash) {
+   hash_for_each_possible_rcu_size(cache->hashtable, cred, cache->hashbits,
+   pos, cr_hash, acred->uid) {
if (!entry->cr_ops->crmatch(acred, entry, flags))
continue;
spin_lock(>lock);
@@ -439,7 +431,8 @@ rpcauth_lookup_credcache(struct rpc_auth *auth, struct 
auth_cred * acred,
}
 
spin_lock(>lock);
-   hlist_for_each_entry(entry, pos, >hashtable[nr], cr_hash) {
+   hash_for_each_possible_size(cache->hashtable, entry, cache->hashbits, 
pos,
+   cr_hash, acred->uid) {
if (!entry->cr_ops->crmatch(acred, entry, flags))
continue;
cred = get_rpccred(entry);
@@ -448,7 +441,7 @@ rpcauth_lookup_credcache(struct rpc_auth *auth, struct 
auth_cred * acred,
if (cred == NULL) {
cred = new;
set_bit(RPCAUTH_CRED_HASHED, >cr_flags);
-   hlist_add_head_rcu(>cr_hash, >hashtable[nr]);
+   hash_add_size(cache->hashtable, cache->hashbits, 
>cr_hash, acred->uid);
} else
list_add_tail(>cr_lru, );
spin_unlock(>lock);
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 12/17] dm: use new hashtable implementation

[Sasha Levin]

Switch dm to use the new hashtable implementation. This reduces the amount of
generic unrelated code in the dm.

Signed-off-by: Sasha Levin 
---
 drivers/md/dm-snap.c   |   24 ---
 drivers/md/persistent-data/dm-block-manager.c  |1 -
 .../persistent-data/dm-persistent-data-internal.h  |   19 
 .../md/persistent-data/dm-transaction-manager.c|   30 ++--
 4 files changed, 16 insertions(+), 58 deletions(-)
 delete mode 100644 drivers/md/persistent-data/dm-persistent-data-internal.h

diff --git a/drivers/md/dm-snap.c b/drivers/md/dm-snap.c
index a143921..7ac121f 100644
--- a/drivers/md/dm-snap.c
+++ b/drivers/md/dm-snap.c
@@ -34,9 +34,7 @@ static const char dm_snapshot_merge_target_name[] = 
"snapshot-merge";
  */
 #define MIN_IOS 256
 
-#define DM_TRACKED_CHUNK_HASH_SIZE 16
-#define DM_TRACKED_CHUNK_HASH(x)   ((unsigned long)(x) & \
-(DM_TRACKED_CHUNK_HASH_SIZE - 1))
+#define DM_TRACKED_CHUNK_HASH_BITS 4
 
 struct dm_exception_table {
uint32_t hash_mask;
@@ -80,7 +78,7 @@ struct dm_snapshot {
/* Chunks with outstanding reads */
spinlock_t tracked_chunk_lock;
mempool_t *tracked_chunk_pool;
-   struct hlist_head tracked_chunk_hash[DM_TRACKED_CHUNK_HASH_SIZE];
+   DEFINE_HASHTABLE(tracked_chunk_hash, DM_TRACKED_CHUNK_HASH_BITS);
 
/* The on disk metadata handler */
struct dm_exception_store *store;
@@ -203,8 +201,7 @@ static struct dm_snap_tracked_chunk *track_chunk(struct 
dm_snapshot *s,
c->chunk = chunk;
 
spin_lock_irqsave(>tracked_chunk_lock, flags);
-   hlist_add_head(>node,
-  >tracked_chunk_hash[DM_TRACKED_CHUNK_HASH(chunk)]);
+   hash_add(s->tracked_chunk_hash, >node, chunk);
spin_unlock_irqrestore(>tracked_chunk_lock, flags);
 
return c;
@@ -216,7 +213,7 @@ static void stop_tracking_chunk(struct dm_snapshot *s,
unsigned long flags;
 
spin_lock_irqsave(>tracked_chunk_lock, flags);
-   hlist_del(>node);
+   hash_del(>node);
spin_unlock_irqrestore(>tracked_chunk_lock, flags);
 
mempool_free(c, s->tracked_chunk_pool);
@@ -230,8 +227,7 @@ static int __chunk_is_tracked(struct dm_snapshot *s, 
chunk_t chunk)
 
spin_lock_irq(>tracked_chunk_lock);
 
-   hlist_for_each_entry(c, hn,
-   >tracked_chunk_hash[DM_TRACKED_CHUNK_HASH(chunk)], node) {
+   hash_for_each_possible(s->tracked_chunk_hash, c, hn, node, chunk) {
if (c->chunk == chunk) {
found = 1;
break;
@@ -1033,7 +1029,6 @@ static void stop_merge(struct dm_snapshot *s)
 static int snapshot_ctr(struct dm_target *ti, unsigned int argc, char **argv)
 {
struct dm_snapshot *s;
-   int i;
int r = -EINVAL;
char *origin_path, *cow_path;
unsigned args_used, num_flush_requests = 1;
@@ -1128,8 +1123,7 @@ static int snapshot_ctr(struct dm_target *ti, unsigned 
int argc, char **argv)
goto bad_tracked_chunk_pool;
}
 
-   for (i = 0; i < DM_TRACKED_CHUNK_HASH_SIZE; i++)
-   INIT_HLIST_HEAD(>tracked_chunk_hash[i]);
+   hash_init(s->tracked_chunk_hash);
 
spin_lock_init(>tracked_chunk_lock);
 
@@ -1253,9 +1247,6 @@ static void __handover_exceptions(struct dm_snapshot 
*snap_src,
 
 static void snapshot_dtr(struct dm_target *ti)
 {
-#ifdef CONFIG_DM_DEBUG
-   int i;
-#endif
struct dm_snapshot *s = ti->private;
struct dm_snapshot *snap_src = NULL, *snap_dest = NULL;
 
@@ -1286,8 +1277,7 @@ static void snapshot_dtr(struct dm_target *ti)
smp_mb();
 
 #ifdef CONFIG_DM_DEBUG
-   for (i = 0; i < DM_TRACKED_CHUNK_HASH_SIZE; i++)
-   BUG_ON(!hlist_empty(>tracked_chunk_hash[i]));
+   BUG_ON(!hash_empty(s->tracked_chunk_hash));
 #endif
 
mempool_destroy(s->tracked_chunk_pool);
diff --git a/drivers/md/persistent-data/dm-block-manager.c 
b/drivers/md/persistent-data/dm-block-manager.c
index 5ba2777..31edaf13 100644
--- a/drivers/md/persistent-data/dm-block-manager.c
+++ b/drivers/md/persistent-data/dm-block-manager.c
@@ -4,7 +4,6 @@
  * This file is released under the GPL.
  */
 #include "dm-block-manager.h"
-#include "dm-persistent-data-internal.h"
 #include "../dm-bufio.h"
 
 #include 
diff --git a/drivers/md/persistent-data/dm-persistent-data-internal.h 
b/drivers/md/persistent-data/dm-persistent-data-internal.h
deleted file mode 100644
index c49e26f..000
--- a/drivers/md/persistent-data/dm-persistent-data-internal.h
+++ /dev/null
@@ -1,19 +0,0 @@
-/*
- * Copyright (C) 2011 Red Hat, Inc.
- *
- * This file is released under the GPL.
- */
-
-#ifndef _DM_PERSISTENT_DATA_INTERNAL_H
-#define _DM_PERSISTENT_DATA_INTERNAL_H
-
-#include "dm-block-manager.h"
-
-static inline unsigned dm_hash_block(dm_block_t b, unsigned hash_mask)
-{
-   const unsigned BIG_PRIME = 

[PATCH v3 08/17] block,elevator: use new hashtable implementation

[Sasha Levin]

Switch elevator to use the new hashtable implementation. This reduces the 
amount of
generic unrelated code in the elevator.

This also removes the dymanic allocation of the hash table. The size of the 
table is
constant so there's no point in paying the price of an extra dereference when 
accessing
it.

Signed-off-by: Sasha Levin 
---
 block/blk.h  |2 +-
 block/elevator.c |   23 ---
 include/linux/elevator.h |5 -
 3 files changed, 9 insertions(+), 21 deletions(-)

diff --git a/block/blk.h b/block/blk.h
index 2a0ea32..5650d48 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -61,7 +61,7 @@ static inline void blk_clear_rq_complete(struct request *rq)
 /*
  * Internal elevator interface
  */
-#define ELV_ON_HASH(rq)(!hlist_unhashed(&(rq)->hash))
+#define ELV_ON_HASH(rq) hash_hashed(&(rq)->hash)
 
 void blk_insert_flush(struct request *rq);
 void blk_abort_flushes(struct request_queue *q);
diff --git a/block/elevator.c b/block/elevator.c
index 6a55d41..f462a83 100644
--- a/block/elevator.c
+++ b/block/elevator.c
@@ -46,11 +46,6 @@ static LIST_HEAD(elv_list);
 /*
  * Merge hash stuff.
  */
-static const int elv_hash_shift = 6;
-#define ELV_HASH_BLOCK(sec)((sec) >> 3)
-#define ELV_HASH_FN(sec)   \
-   (hash_long(ELV_HASH_BLOCK((sec)), elv_hash_shift))
-#define ELV_HASH_ENTRIES   (1 << elv_hash_shift)
 #define rq_hash_key(rq)(blk_rq_pos(rq) + blk_rq_sectors(rq))
 
 /*
@@ -142,7 +137,6 @@ static struct elevator_queue *elevator_alloc(struct 
request_queue *q,
  struct elevator_type *e)
 {
struct elevator_queue *eq;
-   int i;
 
eq = kmalloc_node(sizeof(*eq), GFP_KERNEL | __GFP_ZERO, q->node);
if (unlikely(!eq))
@@ -151,14 +145,7 @@ static struct elevator_queue *elevator_alloc(struct 
request_queue *q,
eq->type = e;
kobject_init(>kobj, _ktype);
mutex_init(>sysfs_lock);
-
-   eq->hash = kmalloc_node(sizeof(struct hlist_head) * ELV_HASH_ENTRIES,
-   GFP_KERNEL, q->node);
-   if (!eq->hash)
-   goto err;
-
-   for (i = 0; i < ELV_HASH_ENTRIES; i++)
-   INIT_HLIST_HEAD(>hash[i]);
+   hash_init(eq->hash);
 
return eq;
 err:
@@ -173,7 +160,6 @@ static void elevator_release(struct kobject *kobj)
 
e = container_of(kobj, struct elevator_queue, kobj);
elevator_put(e->type);
-   kfree(e->hash);
kfree(e);
 }
 
@@ -240,7 +226,7 @@ EXPORT_SYMBOL(elevator_exit);
 
 static inline void __elv_rqhash_del(struct request *rq)
 {
-   hlist_del_init(>hash);
+   hash_del(>hash);
 }
 
 static void elv_rqhash_del(struct request_queue *q, struct request *rq)
@@ -254,7 +240,7 @@ static void elv_rqhash_add(struct request_queue *q, struct 
request *rq)
struct elevator_queue *e = q->elevator;
 
BUG_ON(ELV_ON_HASH(rq));
-   hlist_add_head(>hash, >hash[ELV_HASH_FN(rq_hash_key(rq))]);
+   hash_add(e->hash, >hash, rq_hash_key(rq));
 }
 
 static void elv_rqhash_reposition(struct request_queue *q, struct request *rq)
@@ -266,11 +252,10 @@ static void elv_rqhash_reposition(struct request_queue 
*q, struct request *rq)
 static struct request *elv_rqhash_find(struct request_queue *q, sector_t 
offset)
 {
struct elevator_queue *e = q->elevator;
-   struct hlist_head *hash_list = >hash[ELV_HASH_FN(offset)];
struct hlist_node *entry, *next;
struct request *rq;
 
-   hlist_for_each_entry_safe(rq, entry, next, hash_list, hash) {
+   hash_for_each_possible_safe(e->hash, rq, entry, next, hash, offset) {
BUG_ON(!ELV_ON_HASH(rq));
 
if (unlikely(!rq_mergeable(rq))) {
diff --git a/include/linux/elevator.h b/include/linux/elevator.h
index c03af76..20b539c 100644
--- a/include/linux/elevator.h
+++ b/include/linux/elevator.h
@@ -2,6 +2,7 @@
 #define _LINUX_ELEVATOR_H
 
 #include 
+#include 
 
 #ifdef CONFIG_BLOCK
 
@@ -96,6 +97,8 @@ struct elevator_type
struct list_head list;
 };
 
+#define ELV_HASH_BITS 6
+
 /*
  * each queue has an elevator_queue associated with it
  */
@@ -105,7 +108,7 @@ struct elevator_queue
void *elevator_data;
struct kobject kobj;
struct mutex sysfs_lock;
-   struct hlist_head *hash;
+   DEFINE_HASHTABLE(hash, ELV_HASH_BITS);
unsigned int registered:1;
 };
 
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 06/17] tracepoint: use new hashtable implementation

[Sasha Levin]

Switch tracepoints to use the new hashtable implementation. This reduces the 
amount of
generic unrelated code in the tracepoints.

Signed-off-by: Sasha Levin 
---
 kernel/tracepoint.c |   27 +++
 1 files changed, 11 insertions(+), 16 deletions(-)

diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
index d96ba22..854df92 100644
--- a/kernel/tracepoint.c
+++ b/kernel/tracepoint.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 extern struct tracepoint * const __start___tracepoints_ptrs[];
 extern struct tracepoint * const __stop___tracepoints_ptrs[];
@@ -49,8 +50,7 @@ static LIST_HEAD(tracepoint_module_list);
  * Protected by tracepoints_mutex.
  */
 #define TRACEPOINT_HASH_BITS 6
-#define TRACEPOINT_TABLE_SIZE (1 << TRACEPOINT_HASH_BITS)
-static struct hlist_head tracepoint_table[TRACEPOINT_TABLE_SIZE];
+static DEFINE_HASHTABLE(tracepoint_table, TRACEPOINT_HASH_BITS);
 
 /*
  * Note about RCU :
@@ -191,16 +191,15 @@ tracepoint_entry_remove_probe(struct tracepoint_entry 
*entry,
  */
 static struct tracepoint_entry *get_tracepoint(const char *name)
 {
-   struct hlist_head *head;
struct hlist_node *node;
struct tracepoint_entry *e;
u32 hash = jhash(name, strlen(name), 0);
 
-   head = _table[hash & (TRACEPOINT_TABLE_SIZE - 1)];
-   hlist_for_each_entry(e, node, head, hlist) {
+   hash_for_each_possible(tracepoint_table, e, node, hlist, hash) {
if (!strcmp(name, e->name))
return e;
}
+
return NULL;
 }
 
@@ -210,19 +209,13 @@ static struct tracepoint_entry *get_tracepoint(const char 
*name)
  */
 static struct tracepoint_entry *add_tracepoint(const char *name)
 {
-   struct hlist_head *head;
-   struct hlist_node *node;
struct tracepoint_entry *e;
size_t name_len = strlen(name) + 1;
u32 hash = jhash(name, name_len-1, 0);
 
-   head = _table[hash & (TRACEPOINT_TABLE_SIZE - 1)];
-   hlist_for_each_entry(e, node, head, hlist) {
-   if (!strcmp(name, e->name)) {
-   printk(KERN_NOTICE
-   "tracepoint %s busy\n", name);
-   return ERR_PTR(-EEXIST);/* Already there */
-   }
+   if (get_tracepoint(name)) {
+   printk(KERN_NOTICE "tracepoint %s busy\n", name);
+   return ERR_PTR(-EEXIST);/* Already there */
}
/*
 * Using kmalloc here to allocate a variable length element. Could
@@ -234,7 +227,7 @@ static struct tracepoint_entry *add_tracepoint(const char 
*name)
memcpy(>name[0], name, name_len);
e->funcs = NULL;
e->refcount = 0;
-   hlist_add_head(>hlist, head);
+   hash_add(tracepoint_table, >hlist, hash);
return e;
 }
 
@@ -244,7 +237,7 @@ static struct tracepoint_entry *add_tracepoint(const char 
*name)
  */
 static inline void remove_tracepoint(struct tracepoint_entry *e)
 {
-   hlist_del(>hlist);
+   hash_del(>hlist);
kfree(e);
 }
 
@@ -722,6 +715,8 @@ struct notifier_block tracepoint_module_nb = {
 
 static int init_tracepoints(void)
 {
+   hash_init(tracepoint_table);
+
return register_module_notifier(_module_nb);
 }
 __initcall(init_tracepoints);
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 16/17] tracing output: use new hashtable implementation

[Sasha Levin]

Switch tracing to use the new hashtable implementation. This reduces the amount 
of
generic unrelated code in the tracing module.

Signed-off-by: Sasha Levin 
---
 kernel/trace/trace_output.c |   20 
 1 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
index 123b189..1324c1a 100644
--- a/kernel/trace/trace_output.c
+++ b/kernel/trace/trace_output.c
@@ -8,15 +8,15 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "trace_output.h"
 
-/* must be a power of 2 */
-#define EVENT_HASHSIZE 128
+#define EVENT_HASH_BITS7
 
 DECLARE_RWSEM(trace_event_mutex);
 
-static struct hlist_head event_hash[EVENT_HASHSIZE] __read_mostly;
+static DEFINE_HASHTABLE(event_hash, EVENT_HASH_BITS);
 
 static int next_event_type = __TRACE_LAST_TYPE + 1;
 
@@ -712,11 +712,8 @@ struct trace_event *ftrace_find_event(int type)
 {
struct trace_event *event;
struct hlist_node *n;
-   unsigned key;
 
-   key = type & (EVENT_HASHSIZE - 1);
-
-   hlist_for_each_entry(event, n, _hash[key], node) {
+   hash_for_each_possible(event_hash, event, n, node, type) {
if (event->type == type)
return event;
}
@@ -781,7 +778,6 @@ void trace_event_read_unlock(void)
  */
 int register_ftrace_event(struct trace_event *event)
 {
-   unsigned key;
int ret = 0;
 
down_write(_event_mutex);
@@ -833,9 +829,7 @@ int register_ftrace_event(struct trace_event *event)
if (event->funcs->binary == NULL)
event->funcs->binary = trace_nop_print;
 
-   key = event->type & (EVENT_HASHSIZE - 1);
-
-   hlist_add_head(>node, _hash[key]);
+   hash_add(event_hash, >node, event->type);
 
ret = event->type;
  out:
@@ -850,7 +844,7 @@ EXPORT_SYMBOL_GPL(register_ftrace_event);
  */
 int __unregister_ftrace_event(struct trace_event *event)
 {
-   hlist_del(>node);
+   hash_del(>node);
list_del(>list);
return 0;
 }
@@ -1323,6 +1317,8 @@ __init static int init_events(void)
}
}
 
+   hash_init(event_hash);
+
return 0;
 }
 early_initcall(init_events);
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 14/17] net,rds: use new hashtable implementation

[Sasha Levin]

Switch rds to use the new hashtable implementation. This reduces the amount of
generic unrelated code in rds.

Signed-off-by: Sasha Levin 
---
 net/rds/bind.c   |   28 +-
 net/rds/connection.c |  102 ++
 2 files changed, 63 insertions(+), 67 deletions(-)

diff --git a/net/rds/bind.c b/net/rds/bind.c
index 637bde5..79d65ce 100644
--- a/net/rds/bind.c
+++ b/net/rds/bind.c
@@ -36,16 +36,16 @@
 #include 
 #include 
 #include 
+#include 
 #include "rds.h"
 
-#define BIND_HASH_SIZE 1024
-static struct hlist_head bind_hash_table[BIND_HASH_SIZE];
+#define BIND_HASH_BITS 10
+static DEFINE_HASHTABLE(bind_hash_table, BIND_HASH_BITS);
 static DEFINE_SPINLOCK(rds_bind_lock);
 
-static struct hlist_head *hash_to_bucket(__be32 addr, __be16 port)
+static u32 rds_hash(__be32 addr, __be16 port)
 {
-   return bind_hash_table + (jhash_2words((u32)addr, (u32)port, 0) &
- (BIND_HASH_SIZE - 1));
+   return jhash_2words((u32)addr, (u32)port, 0);
 }
 
 static struct rds_sock *rds_bind_lookup(__be32 addr, __be16 port,
@@ -53,12 +53,12 @@ static struct rds_sock *rds_bind_lookup(__be32 addr, __be16 
port,
 {
struct rds_sock *rs;
struct hlist_node *node;
-   struct hlist_head *head = hash_to_bucket(addr, port);
+   u32 key = rds_hash(addr, port);
u64 cmp;
u64 needle = ((u64)be32_to_cpu(addr) << 32) | be16_to_cpu(port);
 
rcu_read_lock();
-   hlist_for_each_entry_rcu(rs, node, head, rs_bound_node) {
+   hash_for_each_possible_rcu(bind_hash_table, rs, node, rs_bound_node, 
key) {
cmp = ((u64)be32_to_cpu(rs->rs_bound_addr) << 32) |
  be16_to_cpu(rs->rs_bound_port);
 
@@ -74,13 +74,13 @@ static struct rds_sock *rds_bind_lookup(__be32 addr, __be16 
port,
 * make sure our addr and port are set before
 * we are added to the list, other people
 * in rcu will find us as soon as the
-* hlist_add_head_rcu is done
+* hash_add_rcu is done
 */
insert->rs_bound_addr = addr;
insert->rs_bound_port = port;
rds_sock_addref(insert);
 
-   hlist_add_head_rcu(>rs_bound_node, head);
+   hash_add_rcu(bind_hash_table, >rs_bound_node, key);
}
return NULL;
 }
@@ -152,7 +152,7 @@ void rds_remove_bound(struct rds_sock *rs)
  rs, >rs_bound_addr,
  ntohs(rs->rs_bound_port));
 
-   hlist_del_init_rcu(>rs_bound_node);
+   hash_del_rcu(>rs_bound_node);
rds_sock_put(rs);
rs->rs_bound_addr = 0;
}
@@ -202,3 +202,11 @@ out:
synchronize_rcu();
return ret;
 }
+
+static int __init rds_init(void)
+{
+   hash_init(bind_hash_table);
+   return 0;
+}
+
+module_init(rds_init);
diff --git a/net/rds/connection.c b/net/rds/connection.c
index 9e07c75..5b09ee1 100644
--- a/net/rds/connection.c
+++ b/net/rds/connection.c
@@ -34,28 +34,24 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "rds.h"
 #include "loop.h"
 
 #define RDS_CONNECTION_HASH_BITS 12
-#define RDS_CONNECTION_HASH_ENTRIES (1 << RDS_CONNECTION_HASH_BITS)
-#define RDS_CONNECTION_HASH_MASK (RDS_CONNECTION_HASH_ENTRIES - 1)
 
 /* converting this to RCU is a chore for another day.. */
 static DEFINE_SPINLOCK(rds_conn_lock);
 static unsigned long rds_conn_count;
-static struct hlist_head rds_conn_hash[RDS_CONNECTION_HASH_ENTRIES];
+static DEFINE_HASHTABLE(rds_conn_hash, RDS_CONNECTION_HASH_BITS);
 static struct kmem_cache *rds_conn_slab;
 
-static struct hlist_head *rds_conn_bucket(__be32 laddr, __be32 faddr)
+static unsigned long rds_conn_hashfn(__be32 laddr, __be32 faddr)
 {
/* Pass NULL, don't need struct net for hash */
-   unsigned long hash = inet_ehashfn(NULL,
- be32_to_cpu(laddr), 0,
- be32_to_cpu(faddr), 0);
-   return _conn_hash[hash & RDS_CONNECTION_HASH_MASK];
+   return inet_ehashfn(NULL,  be32_to_cpu(laddr), 0,  be32_to_cpu(faddr), 
0);
 }
 
 #define rds_conn_info_set(var, test, suffix) do {  \
@@ -64,14 +60,14 @@ static struct hlist_head *rds_conn_bucket(__be32 laddr, 
__be32 faddr)
 } while (0)
 
 /* rcu read lock must be held or the connection spinlock */
-static struct rds_connection *rds_conn_lookup(struct hlist_head *head,
- __be32 laddr, __be32 faddr,
+static struct rds_connection *rds_conn_lookup(__be32 laddr, __be32 faddr,
  struct rds_transport *trans)
 {
struct rds_connection *conn, *ret = NULL;
struct hlist_node *pos;
+   unsigned long key = rds_conn_hashfn(laddr, faddr);
 
-   hlist_for_each_entry_rcu(conn, pos, head, c_hash_node) {
+   

[PATCH v3 13/17] lockd: use new hashtable implementation

[Sasha Levin]

Switch lockd to use the new hashtable implementation. This reduces the amount of
generic unrelated code in lockd.

Signed-off-by: Sasha Levin 
---
 fs/lockd/svcsubs.c |   66 ---
 1 files changed, 36 insertions(+), 30 deletions(-)

diff --git a/fs/lockd/svcsubs.c b/fs/lockd/svcsubs.c
index 0deb5f6..d223a1f 100644
--- a/fs/lockd/svcsubs.c
+++ b/fs/lockd/svcsubs.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define NLMDBG_FACILITYNLMDBG_SVCSUBS
 
@@ -28,8 +29,7 @@
  * Global file hash table
  */
 #define FILE_HASH_BITS 7
-#define FILE_NRHASH(1f_handle, f))
goto found;
 
@@ -123,7 +123,7 @@ nlm_lookup_file(struct svc_rqst *rqstp, struct nlm_file 
**result,
goto out_free;
}
 
-   hlist_add_head(>f_list, _files[hash]);
+   hash_add(nlm_files, >f_list, key);
 
 found:
dprintk("lockd: found file %p (count %d)\n", file, file->f_count);
@@ -147,8 +147,8 @@ static inline void
 nlm_delete_file(struct nlm_file *file)
 {
nlm_debug_print_file("closing file", file);
-   if (!hlist_unhashed(>f_list)) {
-   hlist_del(>f_list);
+   if (hash_hashed(>f_list)) {
+   hash_del(>f_list);
nlmsvc_ops->fclose(file->f_file);
kfree(file);
} else {
@@ -253,27 +253,25 @@ nlm_traverse_files(void *data, nlm_host_match_fn_t match,
int i, ret = 0;
 
mutex_lock(_file_mutex);
-   for (i = 0; i < FILE_NRHASH; i++) {
-   hlist_for_each_entry_safe(file, pos, next, _files[i], 
f_list) {
-   if (is_failover_file && !is_failover_file(data, file))
-   continue;
-   file->f_count++;
-   mutex_unlock(_file_mutex);
-
-   /* Traverse locks, blocks and shares of this file
-* and update file->f_locks count */
-   if (nlm_inspect_file(data, file, match))
-   ret = 1;
-
-   mutex_lock(_file_mutex);
-   file->f_count--;
-   /* No more references to this file. Let go of it. */
-   if (list_empty(>f_blocks) && !file->f_locks
-&& !file->f_shares && !file->f_count) {
-   hlist_del(>f_list);
-   nlmsvc_ops->fclose(file->f_file);
-   kfree(file);
-   }
+   hash_for_each_safe(nlm_files, i, pos, next, file, f_list) {
+   if (is_failover_file && !is_failover_file(data, file))
+   continue;
+   file->f_count++;
+   mutex_unlock(_file_mutex);
+
+   /* Traverse locks, blocks and shares of this file
+* and update file->f_locks count */
+   if (nlm_inspect_file(data, file, match))
+   ret = 1;
+
+   mutex_lock(_file_mutex);
+   file->f_count--;
+   /* No more references to this file. Let go of it. */
+   if (list_empty(>f_blocks) && !file->f_locks
+&& !file->f_shares && !file->f_count) {
+   hash_del(>f_list);
+   nlmsvc_ops->fclose(file->f_file);
+   kfree(file);
}
}
mutex_unlock(_file_mutex);
@@ -451,3 +449,11 @@ nlmsvc_unlock_all_by_ip(struct sockaddr *server_addr)
return ret ? -EIO : 0;
 }
 EXPORT_SYMBOL_GPL(nlmsvc_unlock_all_by_ip);
+
+static int __init nlm_init(void)
+{
+   hash_init(nlm_files);
+   return 0;
+}
+
+module_init(nlm_init);
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 11/17] net,l2tp: use new hashtable implementation

[Sasha Levin]

Switch l2tp to use the new hashtable implementation. This reduces the amount of
generic unrelated code in l2tp.

Signed-off-by: Sasha Levin 
---
 net/l2tp/l2tp_core.c|  134 +-
 net/l2tp/l2tp_core.h|8 ++--
 net/l2tp/l2tp_debugfs.c |   19 +++
 3 files changed, 61 insertions(+), 100 deletions(-)

diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index 393355d..1d395ce 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -107,8 +108,8 @@ static unsigned int l2tp_net_id;
 struct l2tp_net {
struct list_head l2tp_tunnel_list;
spinlock_t l2tp_tunnel_list_lock;
-   struct hlist_head l2tp_session_hlist[L2TP_HASH_SIZE_2];
-   spinlock_t l2tp_session_hlist_lock;
+   DEFINE_HASHTABLE(l2tp_session_hash, L2TP_HASH_BITS_2)
+   spinlock_t l2tp_session_hash_lock;
 };
 
 static void l2tp_session_set_header_len(struct l2tp_session *session, int 
version);
@@ -156,30 +157,17 @@ do {  
\
 #define l2tp_tunnel_dec_refcount(t) l2tp_tunnel_dec_refcount_1(t)
 #endif
 
-/* Session hash global list for L2TPv3.
- * The session_id SHOULD be random according to RFC3931, but several
- * L2TP implementations use incrementing session_ids.  So we do a real
- * hash on the session_id, rather than a simple bitmask.
- */
-static inline struct hlist_head *
-l2tp_session_id_hash_2(struct l2tp_net *pn, u32 session_id)
-{
-   return >l2tp_session_hlist[hash_32(session_id, L2TP_HASH_BITS_2)];
-
-}
-
 /* Lookup a session by id in the global session list
  */
 static struct l2tp_session *l2tp_session_find_2(struct net *net, u32 
session_id)
 {
struct l2tp_net *pn = l2tp_pernet(net);
-   struct hlist_head *session_list =
-   l2tp_session_id_hash_2(pn, session_id);
struct l2tp_session *session;
struct hlist_node *walk;
 
rcu_read_lock_bh();
-   hlist_for_each_entry_rcu(session, walk, session_list, global_hlist) {
+   hash_for_each_possible_rcu(pn->l2tp_session_hash, session, walk,
+   global_hlist, session_id) {
if (session->session_id == session_id) {
rcu_read_unlock_bh();
return session;
@@ -190,23 +178,10 @@ static struct l2tp_session *l2tp_session_find_2(struct 
net *net, u32 session_id)
return NULL;
 }
 
-/* Session hash list.
- * The session_id SHOULD be random according to RFC2661, but several
- * L2TP implementations (Cisco and Microsoft) use incrementing
- * session_ids.  So we do a real hash on the session_id, rather than a
- * simple bitmask.
- */
-static inline struct hlist_head *
-l2tp_session_id_hash(struct l2tp_tunnel *tunnel, u32 session_id)
-{
-   return >session_hlist[hash_32(session_id, L2TP_HASH_BITS)];
-}
-
 /* Lookup a session by id
  */
 struct l2tp_session *l2tp_session_find(struct net *net, struct l2tp_tunnel 
*tunnel, u32 session_id)
 {
-   struct hlist_head *session_list;
struct l2tp_session *session;
struct hlist_node *walk;
 
@@ -217,15 +192,14 @@ struct l2tp_session *l2tp_session_find(struct net *net, 
struct l2tp_tunnel *tunn
if (tunnel == NULL)
return l2tp_session_find_2(net, session_id);
 
-   session_list = l2tp_session_id_hash(tunnel, session_id);
-   read_lock_bh(>hlist_lock);
-   hlist_for_each_entry(session, walk, session_list, hlist) {
+   read_lock_bh(>hash_lock);
+   hash_for_each_possible(tunnel->session_hash, session, walk, hlist, 
session_id) {
if (session->session_id == session_id) {
-   read_unlock_bh(>hlist_lock);
+   read_unlock_bh(>hash_lock);
return session;
}
}
-   read_unlock_bh(>hlist_lock);
+   read_unlock_bh(>hash_lock);
 
return NULL;
 }
@@ -238,17 +212,15 @@ struct l2tp_session *l2tp_session_find_nth(struct 
l2tp_tunnel *tunnel, int nth)
struct l2tp_session *session;
int count = 0;
 
-   read_lock_bh(>hlist_lock);
-   for (hash = 0; hash < L2TP_HASH_SIZE; hash++) {
-   hlist_for_each_entry(session, walk, 
>session_hlist[hash], hlist) {
-   if (++count > nth) {
-   read_unlock_bh(>hlist_lock);
-   return session;
-   }
+   read_lock_bh(>hash_lock);
+   hash_for_each(tunnel->session_hash, hash, walk, session, hlist) {
+   if (++count > nth) {
+   read_unlock_bh(>hash_lock);
+   return session;
}
}
 
-   read_unlock_bh(>hlist_lock);
+   read_unlock_bh(>hash_lock);
 
return NULL;
 }
@@ -265,12 +237,10 @@ struct l2tp_session 

[PATCH v3 09/17] SUNRPC/cache: use new hashtable implementation

[Sasha Levin]

Switch cache to use the new hashtable implementation. This reduces the amount of
generic unrelated code in the cache implementation.

Signed-off-by: Sasha Levin 
---
 net/sunrpc/cache.c |   20 +---
 1 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c
index 2afd2a8..8a8ef6d 100644
--- a/net/sunrpc/cache.c
+++ b/net/sunrpc/cache.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -524,19 +525,18 @@ EXPORT_SYMBOL_GPL(cache_purge);
  * it to be revisited when cache info is available
  */
 
-#defineDFR_HASHSIZE(PAGE_SIZE/sizeof(struct list_head))
-#defineDFR_HASH(item)  long)item)>>4 ^ (((long)item)>>13)) % 
DFR_HASHSIZE)
+#defineDFR_HASH_BITS   9
 
 #defineDFR_MAX 300 /* ??? */
 
 static DEFINE_SPINLOCK(cache_defer_lock);
 static LIST_HEAD(cache_defer_list);
-static struct hlist_head cache_defer_hash[DFR_HASHSIZE];
+static DEFINE_HASHTABLE(cache_defer_hash, DFR_HASH_BITS)
 static int cache_defer_cnt;
 
 static void __unhash_deferred_req(struct cache_deferred_req *dreq)
 {
-   hlist_del_init(>hash);
+   hash_del(>hash);
if (!list_empty(>recent)) {
list_del_init(>recent);
cache_defer_cnt--;
@@ -545,10 +545,7 @@ static void __unhash_deferred_req(struct 
cache_deferred_req *dreq)
 
 static void __hash_deferred_req(struct cache_deferred_req *dreq, struct 
cache_head *item)
 {
-   int hash = DFR_HASH(item);
-
-   INIT_LIST_HEAD(>recent);
-   hlist_add_head(>hash, _defer_hash[hash]);
+   hash_add(cache_defer_hash, >hash, (unsigned long)item);
 }
 
 static void setup_deferral(struct cache_deferred_req *dreq,
@@ -600,7 +597,7 @@ static void cache_wait_req(struct cache_req *req, struct 
cache_head *item)
 * to clean up
 */
spin_lock(_defer_lock);
-   if (!hlist_unhashed()) {
+   if (hash_hashed()) {
__unhash_deferred_req();
spin_unlock(_defer_lock);
} else {
@@ -671,12 +668,11 @@ static void cache_revisit_request(struct cache_head *item)
struct cache_deferred_req *dreq;
struct list_head pending;
struct hlist_node *lp, *tmp;
-   int hash = DFR_HASH(item);
 
INIT_LIST_HEAD();
spin_lock(_defer_lock);
 
-   hlist_for_each_entry_safe(dreq, lp, tmp, _defer_hash[hash], hash)
+   hash_for_each_possible_safe(cache_defer_hash, dreq, lp, tmp, hash, 
(unsigned long)item)
if (dreq->item == item) {
__unhash_deferred_req(dreq);
list_add(>recent, );
@@ -1636,6 +1632,8 @@ static int create_cache_proc_entries(struct cache_detail 
*cd, struct net *net)
 void __init cache_initialize(void)
 {
INIT_DELAYED_WORK_DEFERRABLE(_cleaner, do_cache_clean);
+
+   hash_init(cache_defer_hash);
 }
 
 int cache_register_net(struct cache_detail *cd, struct net *net)
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 05/17] mm/huge_memory: use new hashtable implementation

[Sasha Levin]

Switch hugemem to use the new hashtable implementation. This reduces the amount 
of
generic unrelated code in the hugemem.

This also removes the dymanic allocation of the hash table. The size of the 
table is
constant so there's no point in paying the price of an extra dereference when 
accessing
it.

Signed-off-by: Sasha Levin 
---
 mm/huge_memory.c |   57 ++---
 1 files changed, 15 insertions(+), 42 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 8b3c55a..cebe345 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "internal.h"
@@ -57,12 +58,12 @@ static DECLARE_WAIT_QUEUE_HEAD(khugepaged_wait);
 static unsigned int khugepaged_max_ptes_none __read_mostly = HPAGE_PMD_NR-1;
 
 static int khugepaged(void *none);
-static int mm_slots_hash_init(void);
 static int khugepaged_slab_init(void);
 static void khugepaged_slab_free(void);
 
-#define MM_SLOTS_HASH_HEADS 1024
-static struct hlist_head *mm_slots_hash __read_mostly;
+#define MM_SLOTS_HASH_BITS 10
+static DEFINE_HASHTABLE(mm_slots_hash, MM_SLOTS_HASH_BITS);
+
 static struct kmem_cache *mm_slot_cache __read_mostly;
 
 /**
@@ -140,7 +141,7 @@ static int start_khugepaged(void)
int err = 0;
if (khugepaged_enabled()) {
int wakeup;
-   if (unlikely(!mm_slot_cache || !mm_slots_hash)) {
+   if (unlikely(!mm_slot_cache)) {
err = -ENOMEM;
goto out;
}
@@ -554,12 +555,6 @@ static int __init hugepage_init(void)
if (err)
goto out;
 
-   err = mm_slots_hash_init();
-   if (err) {
-   khugepaged_slab_free();
-   goto out;
-   }
-
/*
 * By default disable transparent hugepages on smaller systems,
 * where the extra memory used could hurt more than TLB overhead
@@ -1540,6 +1535,8 @@ static int __init khugepaged_slab_init(void)
if (!mm_slot_cache)
return -ENOMEM;
 
+   hash_init(mm_slots_hash);
+
return 0;
 }
 
@@ -1561,47 +1558,23 @@ static inline void free_mm_slot(struct mm_slot *mm_slot)
kmem_cache_free(mm_slot_cache, mm_slot);
 }
 
-static int __init mm_slots_hash_init(void)
-{
-   mm_slots_hash = kzalloc(MM_SLOTS_HASH_HEADS * sizeof(struct hlist_head),
-   GFP_KERNEL);
-   if (!mm_slots_hash)
-   return -ENOMEM;
-   return 0;
-}
-
-#if 0
-static void __init mm_slots_hash_free(void)
-{
-   kfree(mm_slots_hash);
-   mm_slots_hash = NULL;
-}
-#endif
-
 static struct mm_slot *get_mm_slot(struct mm_struct *mm)
 {
-   struct mm_slot *mm_slot;
-   struct hlist_head *bucket;
+   struct mm_slot *slot;
struct hlist_node *node;
 
-   bucket = _slots_hash[((unsigned long)mm / sizeof(struct mm_struct))
-   % MM_SLOTS_HASH_HEADS];
-   hlist_for_each_entry(mm_slot, node, bucket, hash) {
-   if (mm == mm_slot->mm)
-   return mm_slot;
-   }
+   hash_for_each_possible(mm_slots_hash, slot, node, hash, (unsigned long) 
mm)
+   if (slot->mm == mm)
+   return slot;
+
return NULL;
 }
 
 static void insert_to_mm_slots_hash(struct mm_struct *mm,
struct mm_slot *mm_slot)
 {
-   struct hlist_head *bucket;
-
-   bucket = _slots_hash[((unsigned long)mm / sizeof(struct mm_struct))
-   % MM_SLOTS_HASH_HEADS];
mm_slot->mm = mm;
-   hlist_add_head(_slot->hash, bucket);
+   hash_add(mm_slots_hash, _slot->hash, (long)mm);
 }
 
 static inline int khugepaged_test_exit(struct mm_struct *mm)
@@ -1670,7 +1643,7 @@ void __khugepaged_exit(struct mm_struct *mm)
spin_lock(_mm_lock);
mm_slot = get_mm_slot(mm);
if (mm_slot && khugepaged_scan.mm_slot != mm_slot) {
-   hlist_del(_slot->hash);
+   hash_del(_slot->hash);
list_del(_slot->mm_node);
free = 1;
}
@@ -2080,7 +2053,7 @@ static void collect_mm_slot(struct mm_slot *mm_slot)
 
if (khugepaged_test_exit(mm)) {
/* free mm_slot */
-   hlist_del(_slot->hash);
+   hash_del(_slot->hash);
list_del(_slot->mm_node);
 
/*
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 04/17] workqueue: use new hashtable implementation

[Sasha Levin]

Switch workqueues to use the new hashtable implementation. This reduces the 
amount of
generic unrelated code in the workqueues.

Signed-off-by: Sasha Levin 
---
 kernel/workqueue.c |   86 +---
 1 files changed, 15 insertions(+), 71 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 11723c5..fca751e 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "workqueue_sched.h"
 
@@ -82,8 +83,6 @@ enum {
NR_WORKER_POOLS = 2,/* # worker pools per gcwq */
 
BUSY_WORKER_HASH_ORDER  = 6,/* 64 pointers */
-   BUSY_WORKER_HASH_SIZE   = 1 << BUSY_WORKER_HASH_ORDER,
-   BUSY_WORKER_HASH_MASK   = BUSY_WORKER_HASH_SIZE - 1,
 
MAX_IDLE_WORKERS_RATIO  = 4,/* 1/4 of busy can be idle */
IDLE_WORKER_TIMEOUT = 300 * HZ, /* keep idle ones for 5 mins */
@@ -180,7 +179,7 @@ struct global_cwq {
unsigned intflags;  /* L: GCWQ_* flags */
 
/* workers are chained either in busy_hash or pool idle_list */
-   struct hlist_head   busy_hash[BUSY_WORKER_HASH_SIZE];
+   DEFINE_HASHTABLE(busy_hash, BUSY_WORKER_HASH_ORDER);
/* L: hash of busy workers */
 
struct worker_pool  pools[2];   /* normal and highpri pools */
@@ -288,8 +287,7 @@ EXPORT_SYMBOL_GPL(system_nrt_freezable_wq);
 (pool) < &(gcwq)->pools[NR_WORKER_POOLS]; (pool)++)
 
 #define for_each_busy_worker(worker, i, pos, gcwq) \
-   for (i = 0; i < BUSY_WORKER_HASH_SIZE; i++) \
-   hlist_for_each_entry(worker, pos, >busy_hash[i], hentry)
+   hash_for_each(gcwq->busy_hash, i, pos, worker, hentry)
 
 static inline int __next_gcwq_cpu(int cpu, const struct cpumask *mask,
  unsigned int sw)
@@ -845,63 +843,6 @@ static inline void worker_clr_flags(struct worker *worker, 
unsigned int flags)
 }
 
 /**
- * busy_worker_head - return the busy hash head for a work
- * @gcwq: gcwq of interest
- * @work: work to be hashed
- *
- * Return hash head of @gcwq for @work.
- *
- * CONTEXT:
- * spin_lock_irq(gcwq->lock).
- *
- * RETURNS:
- * Pointer to the hash head.
- */
-static struct hlist_head *busy_worker_head(struct global_cwq *gcwq,
-  struct work_struct *work)
-{
-   const int base_shift = ilog2(sizeof(struct work_struct));
-   unsigned long v = (unsigned long)work;
-
-   /* simple shift and fold hash, do we need something better? */
-   v >>= base_shift;
-   v += v >> BUSY_WORKER_HASH_ORDER;
-   v &= BUSY_WORKER_HASH_MASK;
-
-   return >busy_hash[v];
-}
-
-/**
- * __find_worker_executing_work - find worker which is executing a work
- * @gcwq: gcwq of interest
- * @bwh: hash head as returned by busy_worker_head()
- * @work: work to find worker for
- *
- * Find a worker which is executing @work on @gcwq.  @bwh should be
- * the hash head obtained by calling busy_worker_head() with the same
- * work.
- *
- * CONTEXT:
- * spin_lock_irq(gcwq->lock).
- *
- * RETURNS:
- * Pointer to worker which is executing @work if found, NULL
- * otherwise.
- */
-static struct worker *__find_worker_executing_work(struct global_cwq *gcwq,
-  struct hlist_head *bwh,
-  struct work_struct *work)
-{
-   struct worker *worker;
-   struct hlist_node *tmp;
-
-   hlist_for_each_entry(worker, tmp, bwh, hentry)
-   if (worker->current_work == work)
-   return worker;
-   return NULL;
-}
-
-/**
  * find_worker_executing_work - find worker which is executing a work
  * @gcwq: gcwq of interest
  * @work: work to find worker for
@@ -920,8 +861,14 @@ static struct worker *__find_worker_executing_work(struct 
global_cwq *gcwq,
 static struct worker *find_worker_executing_work(struct global_cwq *gcwq,
 struct work_struct *work)
 {
-   return __find_worker_executing_work(gcwq, busy_worker_head(gcwq, work),
-   work);
+   struct worker *worker;
+   struct hlist_node *tmp;
+
+   hash_for_each_possible(gcwq->busy_hash, worker, tmp, hentry, (unsigned 
long)work)
+   if (worker->current_work == work)
+   return worker;
+
+   return NULL;
 }
 
 /**
@@ -2120,7 +2067,6 @@ __acquires(>lock)
struct cpu_workqueue_struct *cwq = get_work_cwq(work);
struct worker_pool *pool = worker->pool;
struct global_cwq *gcwq = pool->gcwq;
-   struct hlist_head *bwh = busy_worker_head(gcwq, work);
bool cpu_intensive = cwq->wq->flags & WQ_CPU_INTENSIVE;
work_func_t f = work->func;
int work_color;
@@ -2152,7 +2098,7 @@ 

[PATCH v3 03/17] mm,ksm: use new hashtable implementation

[Sasha Levin]

Switch ksm to use the new hashtable implementation. This reduces the amount of
generic unrelated code in the ksm module.

Signed-off-by: Sasha Levin 
---
 mm/ksm.c |   33 +++--
 1 files changed, 15 insertions(+), 18 deletions(-)

diff --git a/mm/ksm.c b/mm/ksm.c
index 9638620..dd4d6af 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -33,7 +33,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
@@ -156,9 +156,8 @@ struct rmap_item {
 static struct rb_root root_stable_tree = RB_ROOT;
 static struct rb_root root_unstable_tree = RB_ROOT;
 
-#define MM_SLOTS_HASH_SHIFT 10
-#define MM_SLOTS_HASH_HEADS (1 << MM_SLOTS_HASH_SHIFT)
-static struct hlist_head mm_slots_hash[MM_SLOTS_HASH_HEADS];
+#define MM_SLOTS_HASH_BITS 10
+static DEFINE_HASHTABLE(mm_slots_hash, MM_SLOTS_HASH_BITS);
 
 static struct mm_slot ksm_mm_head = {
.mm_list = LIST_HEAD_INIT(ksm_mm_head.mm_list),
@@ -275,26 +274,21 @@ static inline void free_mm_slot(struct mm_slot *mm_slot)
 
 static struct mm_slot *get_mm_slot(struct mm_struct *mm)
 {
-   struct mm_slot *mm_slot;
-   struct hlist_head *bucket;
struct hlist_node *node;
+   struct mm_slot *slot;
+
+   hash_for_each_possible(mm_slots_hash, slot, node, link, (unsigned 
long)mm) 
+   if (slot->mm == mm)
+   return slot;
 
-   bucket = _slots_hash[hash_ptr(mm, MM_SLOTS_HASH_SHIFT)];
-   hlist_for_each_entry(mm_slot, node, bucket, link) {
-   if (mm == mm_slot->mm)
-   return mm_slot;
-   }
return NULL;
 }
 
 static void insert_to_mm_slots_hash(struct mm_struct *mm,
struct mm_slot *mm_slot)
 {
-   struct hlist_head *bucket;
-
-   bucket = _slots_hash[hash_ptr(mm, MM_SLOTS_HASH_SHIFT)];
mm_slot->mm = mm;
-   hlist_add_head(_slot->link, bucket);
+   hash_add(mm_slots_hash, _slot->link, (unsigned long)mm);
 }
 
 static inline int in_stable_tree(struct rmap_item *rmap_item)
@@ -647,7 +641,7 @@ static int unmerge_and_remove_all_rmap_items(void)
ksm_scan.mm_slot = list_entry(mm_slot->mm_list.next,
struct mm_slot, mm_list);
if (ksm_test_exit(mm)) {
-   hlist_del(_slot->link);
+   hash_del(_slot->link);
list_del(_slot->mm_list);
spin_unlock(_mmlist_lock);
 
@@ -1385,7 +1379,7 @@ next_mm:
 * or when all VM_MERGEABLE areas have been unmapped (and
 * mmap_sem then protects against race with MADV_MERGEABLE).
 */
-   hlist_del(>link);
+   hash_del(>link);
list_del(>mm_list);
spin_unlock(_mmlist_lock);
 
@@ -1552,7 +1546,7 @@ void __ksm_exit(struct mm_struct *mm)
mm_slot = get_mm_slot(mm);
if (mm_slot && ksm_scan.mm_slot != mm_slot) {
if (!mm_slot->rmap_list) {
-   hlist_del(_slot->link);
+   hash_del(_slot->link);
list_del(_slot->mm_list);
easy_to_free = 1;
} else {
@@ -2028,6 +2022,9 @@ static int __init ksm_init(void)
 */
hotplug_memory_notifier(ksm_memory_callback, 100);
 #endif
+
+   hash_init(mm_slots_hash);
+
return 0;
 
 out_free:
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 01/17] hashtable: introduce a small and naive hashtable

[Sasha Levin]

This hashtable implementation is using hlist buckets to provide a simple
hashtable to prevent it from getting reimplemented all over the kernel.

Signed-off-by: Sasha Levin 
---
 include/linux/hashtable.h |  291 +
 1 files changed, 291 insertions(+), 0 deletions(-)
 create mode 100644 include/linux/hashtable.h

diff --git a/include/linux/hashtable.h b/include/linux/hashtable.h
new file mode 100644
index 000..d2d6ed0
--- /dev/null
+++ b/include/linux/hashtable.h
@@ -0,0 +1,291 @@
+/*
+ * Hash table implementation
+ * (C) 2012  Sasha Levin 
+ */
+
+#ifndef _LINUX_HASHTABLE_H
+#define _LINUX_HASHTABLE_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFINE_HASHTABLE(name, bits)   \
+   struct hlist_head name[HASH_SIZE(bits)];
+
+#define HASH_SIZE(bits) (1 << (bits))
+#define HASH_BITS(name) (ilog2(ARRAY_SIZE(name)))
+#define HASH_REQUIRED_SIZE(bits) (sizeof(struct hlist_head) * HASH_SIZE(bits))
+
+/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit kernels. 
*/
+#define hash_min(val, bits) ((sizeof(val)==4) ? hash_32((val), (bits)) : 
hash_long((val), (bits)))
+
+/**
+ * hash_init_size - initialize a hash table
+ * @hashtable: hashtable to be initialized
+ * @bits: bit count of hashing function
+ *
+ * Initializes a hash table with 2**bits buckets.
+ */
+static inline void hash_init_size(struct hlist_head *hashtable, int bits)
+{
+   int i;
+
+   for (i = 0; i < HASH_SIZE(bits); i++)
+   INIT_HLIST_HEAD(hashtable + i);
+}
+
+/**
+ * hash_init - initialize a hash table
+ * @hashtable: hashtable to be initialized
+ *
+ * Calculates the size of the hashtable from the given parameter, otherwise
+ * same as hash_init_size.
+ */
+#define hash_init(name) hash_init_size(name, HASH_BITS(name))
+
+/**
+ * hash_add_size - add an object to a hashtable
+ * @hashtable: hashtable to add to
+ * @bits: bit count used for hashing
+ * @node: the  hlist_node of the object to be added
+ * @key: the key of the object to be added
+ */
+#define hash_add_size(hashtable, bits, node, key)  
\
+   hlist_add_head(node, [hash_min(key, bits)]);
+
+/**
+ * hash_add - add an object to a hashtable
+ * @hashtable: hashtable to add to
+ * @node: the  hlist_node of the object to be added
+ * @key: the key of the object to be added
+ */
+#define hash_add(hashtable, node, key) 
\
+   hash_add_size(hashtable, HASH_BITS(hashtable), node, key)
+
+/**
+ * hash_add_rcu_size - add an object to a rcu enabled hashtable
+ * @hashtable: hashtable to add to
+ * @bits: bit count used for hashing
+ * @node: the  hlist_node of the object to be added
+ * @key: the key of the object to be added
+ */
+#define hash_add_rcu_size(hashtable, bits, node, key)  
\
+   hlist_add_head_rcu(node, [hash_min(key, bits)]);
+
+/**
+ * hash_add_rcu - add an object to a rcu enabled hashtable
+ * @hashtable: hashtable to add to
+ * @node: the  hlist_node of the object to be added
+ * @key: the key of the object to be added
+ */
+#define hash_add_rcu(hashtable, node, key) 
\
+   hash_add_rcu_size(hashtable, HASH_BITS(hashtable), node, key)
+
+/**
+ * hash_hashed - check whether an object is in any hashtable
+ * @node: the  hlist_node of the object to be checked
+ */
+#define hash_hashed(node) (!hlist_unhashed(node))
+
+/**
+ * hash_empty_size - check whether a hashtable is empty
+ * @hashtable: hashtable to check
+ * @bits: bit count used for hashing
+ */
+static inline bool hash_empty_size(struct hlist_head *hashtable, int bits)
+{
+   int i;
+
+   for (i = 0; i < HASH_SIZE(bits); i++)
+   if (!hlist_empty([i]))
+   return false;
+
+   return true;
+}
+
+/**
+ * hash_empty - check whether a hashtable is empty
+ * @hashtable: hashtable to check
+ */
+#define hash_empty(name) hash_empty_size(name, HASH_BITS(name))
+
+/**
+ * hash_del - remove an object from a hashtable
+ * @node:  hlist_node of the object to remove
+ */
+static inline void hash_del(struct hlist_node *node)
+{
+   hlist_del_init(node);
+}
+
+/**
+ * hash_del_rcu - remove an object from a rcu enabled hashtable
+ * @node:  hlist_node of the object to remove
+ */
+static inline void hash_del_rcu(struct hlist_node *node)
+{
+   hlist_del_init_rcu(node);
+}
+
+/**
+ * hash_for_each_size - iterate over a hashtable
+ * @name: hashtable to iterate
+ * @bits: bit count of hashing function of the hashtable
+ * @bkt: integer to use as bucket loop cursor
+ * @node: the  list_head to use as a loop cursor for each entry
+ * @obj: the type * to use as a loop cursor for each entry
+ * @member: the name of the hlist_node within the struct
+ */
+#define hash_for_each_size(name, bits, bkt, node, obj, member) 
\
+   for (bkt = 0; bkt < HASH_SIZE(bits); bkt++)  

[PATCH v3 00/17] generic hashtable implementation

[Sasha Levin]

There are quite a few places in the kernel which implement a hashtable
in a very similar way. Instead of having implementations of a hashtable
all over the kernel, we can re-use the code.

Since it looks like all the major issues we're addressed in the RFC phase
and no major issues were raised with this patch set, I'd be happy to see
this getting merged so that work could continue on different aspects of
the hashtable. Some interesting directions include:

 - Introducing a dynamic RCU hashtable such as the one Mathieu Desnoyers
 wrote about out in the userspace RCU.

 - Replacing the rest of the the kernel structures which use the same basec
 hashtable construct to use this new interface.

 - Same as above, but for non-obvious places (for example, I'm looking into
 using the hashtable to store KVM vcpus instead of the linked list being used
 there now - this should help performance with a large amount of vcpus).


Changes since v2:
 - Documentation improvements from Mathieu Desnoyers.
 - Converted the SUNRPC audit code to use hashtables as well. Since that code
 requires a dynamic hashtable this shows off the _size() API usage.

Changes since v1:

 - Added missing hash_init in rds and lockd.
 - Addressed the userns comments by Eric Biederman.
 - Ran a small test to confirm hash_32 does a good job for low key
 values (1-1), which showed it did - this resulted in no changes to the
 code.

Sasha Levin (17):
  hashtable: introduce a small and naive hashtable
  userns: use new hashtable implementation
  mm,ksm: use new hashtable implementation
  workqueue: use new hashtable implementation
  mm/huge_memory: use new hashtable implementation
  tracepoint: use new hashtable implementation
  net,9p: use new hashtable implementation
  block,elevator: use new hashtable implementation
  SUNRPC/cache: use new hashtable implementation
  dlm: use new hashtable implementation
  net,l2tp: use new hashtable implementation
  dm: use new hashtable implementation
  lockd: use new hashtable implementation
  net,rds: use new hashtable implementation
  openvswitch: use new hashtable implementation
  tracing output: use new hashtable implementation
  SUNRPC: use new hashtable implementation in auth

 block/blk.h|2 +-
 block/elevator.c   |   23 +--
 drivers/md/dm-snap.c   |   24 +--
 drivers/md/persistent-data/dm-block-manager.c  |1 -
 .../persistent-data/dm-persistent-data-internal.h  |   19 --
 .../md/persistent-data/dm-transaction-manager.c|   30 +--
 fs/dlm/lowcomms.c  |   47 +---
 fs/lockd/svcsubs.c |   66 +++--
 include/linux/elevator.h   |5 +-
 include/linux/hashtable.h  |  291 
 kernel/trace/trace_output.c|   20 +-
 kernel/tracepoint.c|   27 +-
 kernel/user.c  |   33 +--
 kernel/workqueue.c |   86 +-
 mm/huge_memory.c   |   57 +---
 mm/ksm.c   |   33 +--
 net/9p/error.c |   21 +-
 net/l2tp/l2tp_core.c   |  134 --
 net/l2tp/l2tp_core.h   |8 +-
 net/l2tp/l2tp_debugfs.c|   19 +-
 net/openvswitch/vport.c|   30 +--
 net/rds/bind.c |   28 ++-
 net/rds/connection.c   |  102 +++
 net/sunrpc/auth.c  |   45 ++--
 net/sunrpc/cache.c |   20 +-
 25 files changed, 617 insertions(+), 554 deletions(-)
 delete mode 100644 drivers/md/persistent-data/dm-persistent-data-internal.h
 create mode 100644 include/linux/hashtable.h

-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] pstore/ftrace: Convert to its own enable/disable debugfs knob

[Steven Rostedt]

On Tue, 2012-08-21 at 19:10 -0700, Anton Vorontsov wrote:

> Running without any recursion protection is prone to weird
> lockups/reboots, and probably a good idea to have it on a production
> system. But recursion during tracing is still an evidence of some other
> bugs, right? At least the fact that I didn't have it helped me to find a
> bug. So, does it make sense to make the recursion protection optionally
> disabled? Maybe as some CONFIG_DEBUG_* option (briefly looking into
> kernel/trace/Kconfig I didn't find any)?

The problem is that recursion bugs are usually due to calling something
that might be traced. Really, I've hit so many recursion bugs, that
having the protection is probably the best thing. I wouldn't turn it
off.

The worse that recursion can do (with proper protection) is that it
causes a little wasted effort during the trace (it wastes cycles tracing
something again and then recognizing that it is doing it due to
recursion).

Therefore, the 'notrace' annotations are mostly for speed up (don't
trace this while tracing, because the tracer uses it too).

-- 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: FW: [PATCH V5 0/5] clk: mmp: add clock framework for mmp

[Chao Xie]

> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Monday, August 20, 2012 1:39 PM
> To: Chao Xie
> Cc: haojian.zhu...@gmail.com; mturque...@linaro.org; viresh.li...@gmail.com; 
> s.ha...@pengutronix.de; linux-kernel@vger.kernel.org; 
> linux-arm-ker...@lists.infradead.org; Chao Xie
> Subject: Re: [PATCH V5 0/5] clk: mmp: add clock framework for mmp
>
> On Monday 20 August 2012, Chao Xie wrote:
>>
>> From: Chao Xie 
>>
>> v1->v2:
>> replace __raw_xxx with xxx_relax
>> use ioremap to remap the registers. Finaly it will use device tree to
>> get the physical address.
>> do not use macro to register clocks, and directly call the functions.
>>
>> v2->v3:
>> pxa910 will have APB extension clock, so some peripharals will have
>> clocks in APB extension base.
>> change pxa168-pwm to be pxa910-pwm for pxa910. It will fit the current
>> pwm driver.
>>
>> v3->v4:
>> remove addtional clock name definition
>> replace left __raw_xxx
>>
>> v4->v5:
>> change the format of the file
>>
>
> Reviewed-by: Arnd Bergmann 
>
> Arnd

Who will be responsible for merging these patches?
--
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/