[PATCH v2 3/5] cpuacct: Initialize cpuacct subsystem earlier
Initialize cpuacct before the scheduler is functioning, so when
cpuacct_charge() and cpuacct_account_field() are called, task_ca()
won't return NULL.
Signed-off-by: Li Zefan
---
kernel/sched/cpuacct.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index 0425581..75e46d2 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -292,9 +292,10 @@ void cpuacct_account_field(struct task_struct *p, int
index, u64 val)
}
struct cgroup_subsys cpuacct_subsys = {
- .name = "cpuacct",
- .css_alloc = cpuacct_css_alloc,
- .css_free = cpuacct_css_free,
- .subsys_id = cpuacct_subsys_id,
- .base_cftypes = files,
+ .name = "cpuacct",
+ .css_alloc = cpuacct_css_alloc,
+ .css_free = cpuacct_css_free,
+ .subsys_id = cpuacct_subsys_id,
+ .base_cftypes = files,
+ .early_init = 1,
};
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/5] cpuacct, cgroup: Kill cgroup_subsys.active
v2: - rebase against tip-tree - add acked-by I said this patchset needn't to be rebased, which is wrong. The last patch needs rebasing. === cpuacct is the only user of cgroup_subsys.active flag. The flag is needed because cpuacct_charge() and cpuacct_account_field() can be called when cpuacct hasn't been initialized during system bootup. This patch initializes cpuacct earlier, and the result is we don't have to check the flag in scheduler hot path. Note, this patchset is based on "[PATCH v2 0/7] sched: Split cpuacct" http://lkml.org/lkml/2013/3/28/1 0001-cpuacct-allocate-per_cpu-cpuusage-for-root-cpuacct-s.patch 0002-cpuacct-Initialize-root-cpuacct-earlier.patch 0003-cpuacct-Initialize-cpuacct-subsystem-earlier.patch 0004-cpuacct-No-need-to-check-subsys-active-state.patch 0005-cgroup-Remove-subsys.active-flag.patch -- include/linux/cgroup.h | 1 - kernel/cgroup.c| 3 --- kernel/sched/core.c| 2 -- kernel/sched/cpuacct.c | 30 +++--- kernel/sched/cpuacct.h | 5 - 5 files changed, 11 insertions(+), 30 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/
[PATCH v2 5/5] cgroup: Kill subsys.active flag
The only user was cpuacct.
Acked-by: Tejun Heo
Signed-off-by: Li Zefan
---
include/linux/cgroup.h | 1 -
kernel/cgroup.c| 3 ---
2 files changed, 4 deletions(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 900af59..95c02c0 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -458,7 +458,6 @@ struct cgroup_subsys {
void (*bind)(struct cgroup *root);
int subsys_id;
- int active;
int disabled;
int early_init;
/*
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index a32f943..5c46281 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -4468,7 +4468,6 @@ static void __init cgroup_init_subsys(struct
cgroup_subsys *ss)
* need to invoke fork callbacks here. */
BUG_ON(!list_empty(&init_task.tasks));
- ss->active = 1;
BUG_ON(online_css(ss, dummytop));
mutex_unlock(&cgroup_mutex);
@@ -4573,7 +4572,6 @@ int __init_or_module cgroup_load_subsys(struct
cgroup_subsys *ss)
}
write_unlock(&css_set_lock);
- ss->active = 1;
ret = online_css(ss, dummytop);
if (ret)
goto err_unload;
@@ -4614,7 +4612,6 @@ void cgroup_unload_subsys(struct cgroup_subsys *ss)
mutex_lock(&cgroup_mutex);
offline_css(ss, dummytop);
- ss->active = 0;
if (ss->use_id)
idr_destroy(&ss->idr);
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/5] cpuacct: allocate per_cpu cpuusage for root cpuacct statically
This is a preparation, so later we can initialize cpuacct earlier.
Signed-off-by: Li Zefan
---
kernel/sched/cpuacct.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index 9305fd2..a691c4d 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -58,6 +58,7 @@ static inline struct cpuacct *parent_ca(struct cpuacct *ca)
return cgroup_ca(ca->css.cgroup->parent);
}
+static DEFINE_PER_CPU(u64, root_cpuacct_cpuusage);
static struct cpuacct root_cpuacct;
/* create a new cpu accounting group */
@@ -290,8 +291,7 @@ void cpuacct_account_field(struct task_struct *p, int
index, u64 val)
void __init cpuacct_init(void)
{
root_cpuacct.cpustat = &kernel_cpustat;
- root_cpuacct.cpuusage = alloc_percpu(u64);
- BUG_ON(!root_cpuacct.cpuusage); /* Too early, not expected to fail */
+ root_cpuacct.cpuusage = &root_cpuacct_cpuusage;
}
struct cgroup_subsys cpuacct_subsys = {
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/5] cpuacct: No need to check subsys active state
Now we're guaranteed when cpuacct_charge() and cpuacct_account_field()
are called, cpuacct has already been properly initialized, so we no
longer need those checks.
Signed-off-by: Li Zefan
---
kernel/sched/cpuacct.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index 75e46d2..ef57ab6 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -247,9 +247,6 @@ void cpuacct_charge(struct task_struct *tsk, u64 cputime)
struct cpuacct *ca;
int cpu;
- if (unlikely(!cpuacct_subsys.active))
- return;
-
cpu = task_cpu(tsk);
rcu_read_lock();
@@ -278,9 +275,6 @@ void cpuacct_account_field(struct task_struct *p, int
index, u64 val)
struct kernel_cpustat *kcpustat;
struct cpuacct *ca;
- if (unlikely(!cpuacct_subsys.active))
- return;
-
rcu_read_lock();
ca = task_ca(p);
while (ca != &root_cpuacct) {
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/5] cpuacct: Initialize root cpuacct earlier
Now we don't need cpuacct_init(), and instead we just initialize
root_cpuacct when it's defined.
Signed-off-by: Li Zefan
---
kernel/sched/core.c| 2 --
kernel/sched/cpuacct.c | 11 ---
kernel/sched/cpuacct.h | 5 -
3 files changed, 4 insertions(+), 14 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c7016c1..5338e6d 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6936,8 +6936,6 @@ void __init sched_init(void)
#endif /* CONFIG_CGROUP_SCHED */
- cpuacct_init();
-
for_each_possible_cpu(i) {
struct rq *rq;
diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index a691c4d..0425581 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -59,7 +59,10 @@ static inline struct cpuacct *parent_ca(struct cpuacct *ca)
}
static DEFINE_PER_CPU(u64, root_cpuacct_cpuusage);
-static struct cpuacct root_cpuacct;
+static struct cpuacct root_cpuacct = {
+ .cpustat= &kernel_cpustat,
+ .cpuusage = &root_cpuacct_cpuusage,
+};
/* create a new cpu accounting group */
static struct cgroup_subsys_state *cpuacct_css_alloc(struct cgroup *cgrp)
@@ -288,12 +291,6 @@ void cpuacct_account_field(struct task_struct *p, int
index, u64 val)
rcu_read_unlock();
}
-void __init cpuacct_init(void)
-{
- root_cpuacct.cpustat = &kernel_cpustat;
- root_cpuacct.cpuusage = &root_cpuacct_cpuusage;
-}
-
struct cgroup_subsys cpuacct_subsys = {
.name = "cpuacct",
.css_alloc = cpuacct_css_alloc,
diff --git a/kernel/sched/cpuacct.h b/kernel/sched/cpuacct.h
index 51cd76e..ed60562 100644
--- a/kernel/sched/cpuacct.h
+++ b/kernel/sched/cpuacct.h
@@ -1,15 +1,10 @@
#ifdef CONFIG_CGROUP_CPUACCT
-extern void cpuacct_init(void);
extern void cpuacct_charge(struct task_struct *tsk, u64 cputime);
extern void cpuacct_account_field(struct task_struct *p, int index, u64 val);
#else
-static inline void cpuacct_init(void)
-{
-}
-
static inline void cpuacct_charge(struct task_struct *tsk, u64 cputime)
{
}
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 7/7] cpuacct: Clean up cpuacct.h
Now most of the code in cpuacct.h can be moved to cpuacct.c
Signed-off-by: Li Zefan
---
kernel/sched/cpuacct.c | 44 +++-
kernel/sched/cpuacct.h | 46 --
2 files changed, 43 insertions(+), 47 deletions(-)
diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index 071ae8d..9305fd2 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -16,7 +16,49 @@
* (bal...@in.ibm.com).
*/
-struct cpuacct root_cpuacct;
+/* Time spent by the tasks of the cpu accounting group executing in ... */
+enum cpuacct_stat_index {
+ CPUACCT_STAT_USER, /* ... user mode */
+ CPUACCT_STAT_SYSTEM,/* ... kernel mode */
+
+ CPUACCT_STAT_NSTATS,
+};
+
+/* track cpu usage of a group of tasks and its child groups */
+struct cpuacct {
+ struct cgroup_subsys_state css;
+ /* cpuusage holds pointer to a u64-type object on every cpu */
+ u64 __percpu *cpuusage;
+ struct kernel_cpustat __percpu *cpustat;
+};
+
+/* return cpu accounting group corresponding to this container */
+static inline struct cpuacct *cgroup_ca(struct cgroup *cgrp)
+{
+ return container_of(cgroup_subsys_state(cgrp, cpuacct_subsys_id),
+ struct cpuacct, css);
+}
+
+/* return cpu accounting group to which this task belongs */
+static inline struct cpuacct *task_ca(struct task_struct *tsk)
+{
+ return container_of(task_subsys_state(tsk, cpuacct_subsys_id),
+ struct cpuacct, css);
+}
+
+static inline struct cpuacct *__parent_ca(struct cpuacct *ca)
+{
+ return cgroup_ca(ca->css.cgroup->parent);
+}
+
+static inline struct cpuacct *parent_ca(struct cpuacct *ca)
+{
+ if (!ca->css.cgroup->parent)
+ return NULL;
+ return cgroup_ca(ca->css.cgroup->parent);
+}
+
+static struct cpuacct root_cpuacct;
/* create a new cpu accounting group */
static struct cgroup_subsys_state *cpuacct_css_alloc(struct cgroup *cgrp)
diff --git a/kernel/sched/cpuacct.h b/kernel/sched/cpuacct.h
index b2f79ad..51cd76e 100644
--- a/kernel/sched/cpuacct.h
+++ b/kernel/sched/cpuacct.h
@@ -1,51 +1,5 @@
-/* Time spent by the tasks of the cpu accounting group executing in ... */
-enum cpuacct_stat_index {
- CPUACCT_STAT_USER, /* ... user mode */
- CPUACCT_STAT_SYSTEM,/* ... kernel mode */
-
- CPUACCT_STAT_NSTATS,
-};
-
#ifdef CONFIG_CGROUP_CPUACCT
-#include
-/* track cpu usage of a group of tasks and its child groups */
-struct cpuacct {
- struct cgroup_subsys_state css;
- /* cpuusage holds pointer to a u64-type object on every cpu */
- u64 __percpu *cpuusage;
- struct kernel_cpustat __percpu *cpustat;
-};
-
-extern struct cgroup_subsys cpuacct_subsys;
-extern struct cpuacct root_cpuacct;
-
-/* return cpu accounting group corresponding to this container */
-static inline struct cpuacct *cgroup_ca(struct cgroup *cgrp)
-{
- return container_of(cgroup_subsys_state(cgrp, cpuacct_subsys_id),
- struct cpuacct, css);
-}
-
-/* return cpu accounting group to which this task belongs */
-static inline struct cpuacct *task_ca(struct task_struct *tsk)
-{
- return container_of(task_subsys_state(tsk, cpuacct_subsys_id),
- struct cpuacct, css);
-}
-
-static inline struct cpuacct *__parent_ca(struct cpuacct *ca)
-{
- return cgroup_ca(ca->css.cgroup->parent);
-}
-
-static inline struct cpuacct *parent_ca(struct cpuacct *ca)
-{
- if (!ca->css.cgroup->parent)
- return NULL;
- return cgroup_ca(ca->css.cgroup->parent);
-}
-
extern void cpuacct_init(void);
extern void cpuacct_charge(struct task_struct *tsk, u64 cputime);
extern void cpuacct_account_field(struct task_struct *p, int index, u64 val);
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 6/7] cpuacct: Remove redundant NULL checks in cpuacct_acount_field()
This is a micro optimazation for a hot path.
- We don't need to check if @ca returned from task_ca() is NULL.
- We don't need to check if @ca returned from parent_ca() is NULL.
Signed-off-by: Li Zefan
---
kernel/sched/cpuacct.c | 4 ++--
kernel/sched/cpuacct.h | 5 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index b2aaaba..071ae8d 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -237,10 +237,10 @@ void cpuacct_account_field(struct task_struct *p, int
index, u64 val)
rcu_read_lock();
ca = task_ca(p);
- while (ca && (ca != &root_cpuacct)) {
+ while (ca != &root_cpuacct) {
kcpustat = this_cpu_ptr(ca->cpustat);
kcpustat->cpustat[index] += val;
- ca = parent_ca(ca);
+ ca = __parent_ca(ca);
}
rcu_read_unlock();
}
diff --git a/kernel/sched/cpuacct.h b/kernel/sched/cpuacct.h
index 45c1682..b2f79ad 100644
--- a/kernel/sched/cpuacct.h
+++ b/kernel/sched/cpuacct.h
@@ -34,6 +34,11 @@ static inline struct cpuacct *task_ca(struct task_struct
*tsk)
struct cpuacct, css);
}
+static inline struct cpuacct *__parent_ca(struct cpuacct *ca)
+{
+ return cgroup_ca(ca->css.cgroup->parent);
+}
+
static inline struct cpuacct *parent_ca(struct cpuacct *ca)
{
if (!ca->css.cgroup->parent)
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/7] sched: Split cpuacct code out of sched.h
Add cpuacct.h and let sched.h include it.
Signed-off-by: Li Zefan
---
kernel/sched/cpuacct.h | 52 ++
kernel/sched/sched.h | 48 +-
2 files changed, 53 insertions(+), 47 deletions(-)
create mode 100644 kernel/sched/cpuacct.h
diff --git a/kernel/sched/cpuacct.h b/kernel/sched/cpuacct.h
new file mode 100644
index 000..a7f3d4a
--- /dev/null
+++ b/kernel/sched/cpuacct.h
@@ -0,0 +1,52 @@
+/* Time spent by the tasks of the cpu accounting group executing in ... */
+enum cpuacct_stat_index {
+ CPUACCT_STAT_USER, /* ... user mode */
+ CPUACCT_STAT_SYSTEM,/* ... kernel mode */
+
+ CPUACCT_STAT_NSTATS,
+};
+
+#ifdef CONFIG_CGROUP_CPUACCT
+
+#include
+/* track cpu usage of a group of tasks and its child groups */
+struct cpuacct {
+ struct cgroup_subsys_state css;
+ /* cpuusage holds pointer to a u64-type object on every cpu */
+ u64 __percpu *cpuusage;
+ struct kernel_cpustat __percpu *cpustat;
+};
+
+extern struct cgroup_subsys cpuacct_subsys;
+extern struct cpuacct root_cpuacct;
+
+/* return cpu accounting group corresponding to this container */
+static inline struct cpuacct *cgroup_ca(struct cgroup *cgrp)
+{
+ return container_of(cgroup_subsys_state(cgrp, cpuacct_subsys_id),
+ struct cpuacct, css);
+}
+
+/* return cpu accounting group to which this task belongs */
+static inline struct cpuacct *task_ca(struct task_struct *tsk)
+{
+ return container_of(task_subsys_state(tsk, cpuacct_subsys_id),
+ struct cpuacct, css);
+}
+
+static inline struct cpuacct *parent_ca(struct cpuacct *ca)
+{
+ if (!ca || !ca->css.cgroup->parent)
+ return NULL;
+ return cgroup_ca(ca->css.cgroup->parent);
+}
+
+extern void cpuacct_charge(struct task_struct *tsk, u64 cputime);
+
+#else
+
+static inline void cpuacct_charge(struct task_struct *tsk, u64 cputime)
+{
+}
+
+#endif
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 3bd15a4..8116cf8 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -7,6 +7,7 @@
#include
#include "cpupri.h"
+#include "cpuacct.h"
extern __read_mostly int scheduler_running;
@@ -950,14 +951,6 @@ static const u32 prio_to_wmult[40] = {
/* 15 */ 119304647, 148102320, 186737708, 238609294, 286331153,
};
-/* Time spent by the tasks of the cpu accounting group executing in ... */
-enum cpuacct_stat_index {
- CPUACCT_STAT_USER, /* ... user mode */
- CPUACCT_STAT_SYSTEM,/* ... kernel mode */
-
- CPUACCT_STAT_NSTATS,
-};
-
#define ENQUEUE_WAKEUP 1
#define ENQUEUE_HEAD 2
#ifdef CONFIG_SMP
@@ -1054,45 +1047,6 @@ extern void init_rt_bandwidth(struct rt_bandwidth *rt_b,
u64 period, u64 runtime
extern void update_idle_cpu_load(struct rq *this_rq);
-#ifdef CONFIG_CGROUP_CPUACCT
-#include
-/* track cpu usage of a group of tasks and its child groups */
-struct cpuacct {
- struct cgroup_subsys_state css;
- /* cpuusage holds pointer to a u64-type object on every cpu */
- u64 __percpu *cpuusage;
- struct kernel_cpustat __percpu *cpustat;
-};
-
-extern struct cgroup_subsys cpuacct_subsys;
-extern struct cpuacct root_cpuacct;
-
-/* return cpu accounting group corresponding to this container */
-static inline struct cpuacct *cgroup_ca(struct cgroup *cgrp)
-{
- return container_of(cgroup_subsys_state(cgrp, cpuacct_subsys_id),
- struct cpuacct, css);
-}
-
-/* return cpu accounting group to which this task belongs */
-static inline struct cpuacct *task_ca(struct task_struct *tsk)
-{
- return container_of(task_subsys_state(tsk, cpuacct_subsys_id),
- struct cpuacct, css);
-}
-
-static inline struct cpuacct *parent_ca(struct cpuacct *ca)
-{
- if (!ca || !ca->css.cgroup->parent)
- return NULL;
- return cgroup_ca(ca->css.cgroup->parent);
-}
-
-extern void cpuacct_charge(struct task_struct *tsk, u64 cputime);
-#else
-static inline void cpuacct_charge(struct task_struct *tsk, u64 cputime) {}
-#endif
-
#ifdef CONFIG_PARAVIRT
static inline u64 steal_ticks(u64 steal)
{
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/7] cpuacct: Add cpuacct_init()
So we don't open-coded initialization of cpuacct in core.c.
Signed-off-by: Li Zefan
---
kernel/sched/core.c| 8 ++--
kernel/sched/cpuacct.c | 7 +++
kernel/sched/cpuacct.h | 5 +
3 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c4e2b81..c7016c1 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6936,12 +6936,8 @@ void __init sched_init(void)
#endif /* CONFIG_CGROUP_SCHED */
-#ifdef CONFIG_CGROUP_CPUACCT
- root_cpuacct.cpustat = &kernel_cpustat;
- root_cpuacct.cpuusage = alloc_percpu(u64);
- /* Too early, not expected to fail */
- BUG_ON(!root_cpuacct.cpuusage);
-#endif
+ cpuacct_init();
+
for_each_possible_cpu(i) {
struct rq *rq;
diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index 50ec24b..48b5e91 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -218,6 +218,13 @@ void cpuacct_charge(struct task_struct *tsk, u64 cputime)
rcu_read_unlock();
}
+void __init cpuacct_init(void)
+{
+ root_cpuacct.cpustat = &kernel_cpustat;
+ root_cpuacct.cpuusage = alloc_percpu(u64);
+ BUG_ON(!root_cpuacct.cpuusage); /* Too early, not expected to fail */
+}
+
struct cgroup_subsys cpuacct_subsys = {
.name = "cpuacct",
.css_alloc = cpuacct_css_alloc,
diff --git a/kernel/sched/cpuacct.h b/kernel/sched/cpuacct.h
index a7f3d4a..551acd7 100644
--- a/kernel/sched/cpuacct.h
+++ b/kernel/sched/cpuacct.h
@@ -41,10 +41,15 @@ static inline struct cpuacct *parent_ca(struct cpuacct *ca)
return cgroup_ca(ca->css.cgroup->parent);
}
+extern void cpuacct_init(void);
extern void cpuacct_charge(struct task_struct *tsk, u64 cputime);
#else
+static inline void cpuacct_init(void)
+{
+}
+
static inline void cpuacct_charge(struct task_struct *tsk, u64 cputime)
{
}
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/7] cpuacct: Remove redundant NULL checks in cpuacct_charge()
This is a micro optimization for the hot path.
- We don't need to check if @ca is NULL in parent_ca().
- We don't need to check if @ca is NULL in the beginning of the for loop.
Signed-off-by: Li Zefan
---
kernel/sched/cpuacct.c | 6 +-
kernel/sched/cpuacct.h | 2 +-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index 72bd971..b2aaaba 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -210,9 +210,13 @@ void cpuacct_charge(struct task_struct *tsk, u64 cputime)
ca = task_ca(tsk);
- for (; ca; ca = parent_ca(ca)) {
+ while (true) {
u64 *cpuusage = per_cpu_ptr(ca->cpuusage, cpu);
*cpuusage += cputime;
+
+ ca = parent_ca(ca);
+ if (!ca)
+ break;
}
rcu_read_unlock();
diff --git a/kernel/sched/cpuacct.h b/kernel/sched/cpuacct.h
index bd0409b..45c1682 100644
--- a/kernel/sched/cpuacct.h
+++ b/kernel/sched/cpuacct.h
@@ -36,7 +36,7 @@ static inline struct cpuacct *task_ca(struct task_struct *tsk)
static inline struct cpuacct *parent_ca(struct cpuacct *ca)
{
- if (!ca || !ca->css.cgroup->parent)
+ if (!ca->css.cgroup->parent)
return NULL;
return cgroup_ca(ca->css.cgroup->parent);
}
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/7] cpuacct: Add cpuacct_acount_field()
So we can remove open-coded cpuacct code in cputime.c.
Signed-off-by: Li Zefan
---
kernel/sched/cpuacct.c | 23 +++
kernel/sched/cpuacct.h | 6 ++
kernel/sched/cputime.c | 18 +-
3 files changed, 30 insertions(+), 17 deletions(-)
diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index 48b5e91..72bd971 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -218,6 +218,29 @@ void cpuacct_charge(struct task_struct *tsk, u64 cputime)
rcu_read_unlock();
}
+/*
+ * Add user/system time to cpuacct.
+ *
+ * Note: it's the caller that updates the account of the root cgroup.
+ */
+void cpuacct_account_field(struct task_struct *p, int index, u64 val)
+{
+ struct kernel_cpustat *kcpustat;
+ struct cpuacct *ca;
+
+ if (unlikely(!cpuacct_subsys.active))
+ return;
+
+ rcu_read_lock();
+ ca = task_ca(p);
+ while (ca && (ca != &root_cpuacct)) {
+ kcpustat = this_cpu_ptr(ca->cpustat);
+ kcpustat->cpustat[index] += val;
+ ca = parent_ca(ca);
+ }
+ rcu_read_unlock();
+}
+
void __init cpuacct_init(void)
{
root_cpuacct.cpustat = &kernel_cpustat;
diff --git a/kernel/sched/cpuacct.h b/kernel/sched/cpuacct.h
index 551acd7..bd0409b 100644
--- a/kernel/sched/cpuacct.h
+++ b/kernel/sched/cpuacct.h
@@ -43,6 +43,7 @@ static inline struct cpuacct *parent_ca(struct cpuacct *ca)
extern void cpuacct_init(void);
extern void cpuacct_charge(struct task_struct *tsk, u64 cputime);
+extern void cpuacct_account_field(struct task_struct *p, int index, u64 val);
#else
@@ -54,4 +55,9 @@ static inline void cpuacct_charge(struct task_struct *tsk,
u64 cputime)
{
}
+static inline void
+cpuacct_account_field(struct task_struct *p, int index, u64 val)
+{
+}
+
#endif
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 024fe19..e82b82e 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -115,10 +115,6 @@ static int irqtime_account_si_update(void)
static inline void task_group_account_field(struct task_struct *p, int index,
u64 tmp)
{
-#ifdef CONFIG_CGROUP_CPUACCT
- struct kernel_cpustat *kcpustat;
- struct cpuacct *ca;
-#endif
/*
* Since all updates are sure to touch the root cgroup, we
* get ourselves ahead and touch it first. If the root cgroup
@@ -127,19 +123,7 @@ static inline void task_group_account_field(struct
task_struct *p, int index,
*/
__get_cpu_var(kernel_cpustat).cpustat[index] += tmp;
-#ifdef CONFIG_CGROUP_CPUACCT
- if (unlikely(!cpuacct_subsys.active))
- return;
-
- rcu_read_lock();
- ca = task_ca(p);
- while (ca && (ca != &root_cpuacct)) {
- kcpustat = this_cpu_ptr(ca->cpustat);
- kcpustat->cpustat[index] += tmp;
- ca = parent_ca(ca);
- }
- rcu_read_unlock();
-#endif
+ cpuacct_account_field(p, index, tmp);
}
/*
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/7] sched: Split cpuacct code out of core.c
Signed-off-by: Li Zefan
---
kernel/sched/Makefile | 1 +
kernel/sched/core.c| 220 ---
kernel/sched/cpuacct.c | 227 +
3 files changed, 228 insertions(+), 220 deletions(-)
create mode 100644 kernel/sched/cpuacct.c
diff --git a/kernel/sched/Makefile b/kernel/sched/Makefile
index f06d249..deaf90e 100644
--- a/kernel/sched/Makefile
+++ b/kernel/sched/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_SMP) += cpupri.o
obj-$(CONFIG_SCHED_AUTOGROUP) += auto_group.o
obj-$(CONFIG_SCHEDSTATS) += stats.o
obj-$(CONFIG_SCHED_DEBUG) += debug.o
+obj-$(CONFIG_CGROUP_CPUACCT) += cpuacct.o
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index b36635e..c4e2b81 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -8043,226 +8043,6 @@ struct cgroup_subsys cpu_cgroup_subsys = {
#endif /* CONFIG_CGROUP_SCHED */
-#ifdef CONFIG_CGROUP_CPUACCT
-
-/*
- * CPU accounting code for task groups.
- *
- * Based on the work by Paul Menage (men...@google.com) and Balbir Singh
- * (bal...@in.ibm.com).
- */
-
-struct cpuacct root_cpuacct;
-
-/* create a new cpu accounting group */
-static struct cgroup_subsys_state *cpuacct_css_alloc(struct cgroup *cgrp)
-{
- struct cpuacct *ca;
-
- if (!cgrp->parent)
- return &root_cpuacct.css;
-
- ca = kzalloc(sizeof(*ca), GFP_KERNEL);
- if (!ca)
- goto out;
-
- ca->cpuusage = alloc_percpu(u64);
- if (!ca->cpuusage)
- goto out_free_ca;
-
- ca->cpustat = alloc_percpu(struct kernel_cpustat);
- if (!ca->cpustat)
- goto out_free_cpuusage;
-
- return &ca->css;
-
-out_free_cpuusage:
- free_percpu(ca->cpuusage);
-out_free_ca:
- kfree(ca);
-out:
- return ERR_PTR(-ENOMEM);
-}
-
-/* destroy an existing cpu accounting group */
-static void cpuacct_css_free(struct cgroup *cgrp)
-{
- struct cpuacct *ca = cgroup_ca(cgrp);
-
- free_percpu(ca->cpustat);
- free_percpu(ca->cpuusage);
- kfree(ca);
-}
-
-static u64 cpuacct_cpuusage_read(struct cpuacct *ca, int cpu)
-{
- u64 *cpuusage = per_cpu_ptr(ca->cpuusage, cpu);
- u64 data;
-
-#ifndef CONFIG_64BIT
- /*
-* Take rq->lock to make 64-bit read safe on 32-bit platforms.
-*/
- raw_spin_lock_irq(&cpu_rq(cpu)->lock);
- data = *cpuusage;
- raw_spin_unlock_irq(&cpu_rq(cpu)->lock);
-#else
- data = *cpuusage;
-#endif
-
- return data;
-}
-
-static void cpuacct_cpuusage_write(struct cpuacct *ca, int cpu, u64 val)
-{
- u64 *cpuusage = per_cpu_ptr(ca->cpuusage, cpu);
-
-#ifndef CONFIG_64BIT
- /*
-* Take rq->lock to make 64-bit write safe on 32-bit platforms.
-*/
- raw_spin_lock_irq(&cpu_rq(cpu)->lock);
- *cpuusage = val;
- raw_spin_unlock_irq(&cpu_rq(cpu)->lock);
-#else
- *cpuusage = val;
-#endif
-}
-
-/* return total cpu usage (in nanoseconds) of a group */
-static u64 cpuusage_read(struct cgroup *cgrp, struct cftype *cft)
-{
- struct cpuacct *ca = cgroup_ca(cgrp);
- u64 totalcpuusage = 0;
- int i;
-
- for_each_present_cpu(i)
- totalcpuusage += cpuacct_cpuusage_read(ca, i);
-
- return totalcpuusage;
-}
-
-static int cpuusage_write(struct cgroup *cgrp, struct cftype *cftype,
- u64 reset)
-{
- struct cpuacct *ca = cgroup_ca(cgrp);
- int err = 0;
- int i;
-
- if (reset) {
- err = -EINVAL;
- goto out;
- }
-
- for_each_present_cpu(i)
- cpuacct_cpuusage_write(ca, i, 0);
-
-out:
- return err;
-}
-
-static int cpuacct_percpu_seq_read(struct cgroup *cgroup, struct cftype *cft,
- struct seq_file *m)
-{
- struct cpuacct *ca = cgroup_ca(cgroup);
- u64 percpu;
- int i;
-
- for_each_present_cpu(i) {
- percpu = cpuacct_cpuusage_read(ca, i);
- seq_printf(m, "%llu ", (unsigned long long) percpu);
- }
- seq_printf(m, "\n");
- return 0;
-}
-
-static const char *cpuacct_stat_desc[] = {
- [CPUACCT_STAT_USER] = "user",
- [CPUACCT_STAT_SYSTEM] = "system",
-};
-
-static int cpuacct_stats_show(struct cgroup *cgrp, struct cftype *cft,
- struct cgroup_map_cb *cb)
-{
- struct cpuacct *ca = cgroup_ca(cgrp);
- int cpu;
- s64 val = 0;
-
- for_each_online_cpu(cpu) {
- struct kernel_cpustat *kcpustat = per_cpu_ptr(ca->cpustat, cpu);
- val += kcpustat->cpustat[CPUTIME_USER];
- val += kcpustat->cpustat[CPUTIME_NICE];
- }
- val = cputime64_to_clock_t(val);
- cb->fill(cb, cpuacct_stat_desc[CPUACCT_STAT_USER], val);
-
- val = 0;
- for_each_online_cpu(cpu) {
- struct kernel_cpustat *kcpustat = per_cpu_ptr(ca->cpus
[PATCH v2 0/7] sched: Split cpuacct
v2: rebase against tip-tree I don't rebase "[PATCH 0/5] cpuacct, cgroup: Remove cgroup_subsys.active", because it can be applied cleanly on top of this patchset. - This patchset splits cpuacct out of core scheduler code. - Plus two small optimizations. 0001-sched-Split-cpuacct-code-out-of-core.c.patch 0002-sched-Split-cpuacct-out-of-sched.h.patch 0003-cpuacct-Add-cpuacct_init.patch 0004-cpuacct-Add-cpuacct_acount_field.patch 0005-cpuacct-Remove-redundant-NULL-checks-in-cpuacct_char.patch 0006-cpuacct-Remove-redundant-NULL-checks-in-cpuacct_acou.patch 0007-cpuacct-Clean-up-cpuacct.h.patch --- kernel/sched/Makefile | 1 + kernel/sched/core.c| 228 +-- kernel/sched/cpuacct.c | 303 +++ kernel/sched/cpuacct.h | 22 + kernel/sched/cputime.c | 18 +--- kernel/sched/sched.h | 48 +- 6 files changed, 330 insertions(+), 290 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/
[ANNOUNCE] 3.2.42-rt62
Dear RT Folks, I'm pleased to announce the 3.2.42-rt62 stable release. This release is just an update to the new stable 3.2.42 version and no RT specific changes have been made. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git Head SHA1: 401f784923d5e2c68a6844aa9d5c5c7faaf523be Or to build 3.2.42-rt62 directly, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.tar.xz http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.2.42.xz http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.42-rt62.patch.xz Enjoy, -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch
> > I looked in today's linux-next, and there seems to be only one > > initialization of this field, to true, and one test of this field. So > > perhaps the case for setting the field to false just isn't needed. > > Oh sorry now I get what you mean! I thought about this -- and yes I > decided to not add a bool false setting for the structure field given > that the assumption is this would not be something dynamic, and data > structure would be kzalloc()'d so by default they are 0. What do you do about the test, though? julia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] sched: Split cpuacct
Please ignore this patchset. It's not based on the right kernel version.. On 2013/3/28 12:11, Li Zefan wrote: > - This patchset splits cpuacct out of core scheduler code. > - Plus two small optimizations. > > 0001-sched-Split-cpuacct-code-out-of-core.c.patch > 0002-sched-Split-cpuacct-out-of-sched.h.patch > 0003-cpuacct-Add-cpuacct_init.patch > 0004-cpuacct-Add-cpuacct_acount_field.patch > 0005-cpuacct-Remove-redundant-NULL-checks-in-cpuacct_char.patch > 0006-cpuacct-Remove-redundant-NULL-checks-in-cpuacct_acou.patch > 0007-cpuacct-Clean-up-cpuacct.h.patch > > --- > kernel/sched/Makefile | 1 + > kernel/sched/core.c| 228 +-- > kernel/sched/cpuacct.c | 303 > +++ > kernel/sched/cpuacct.h | 22 + > kernel/sched/cputime.c | 18 +--- > kernel/sched/sched.h | 49 +-- > 6 files changed, 330 insertions(+), 291 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/
[PATCH] [libata] Fix HDIO_DRIVE_CMD ioctl sense data check
commit 84a9a8cd9d0aa93c17e5815ab8a9cc4c0a765c63 changed the sense key used for returning task registers, but HDIO_DRIVE_CMD ioctl was not changed accordingly. Tested: check that SMART ENABLE sent using HDIO_DRIVE_CMD returns 0 instead of EIO. Signed-off-by: Gwendal Grignou --- drivers/ata/libata-scsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c index 318b413..e05bf4c 100644 --- a/drivers/ata/libata-scsi.c +++ b/drivers/ata/libata-scsi.c @@ -532,8 +532,8 @@ int ata_cmd_ioctl(struct scsi_device *scsidev, void __user *arg) struct scsi_sense_hdr sshdr; scsi_normalize_sense(sensebuf, SCSI_SENSE_BUFFERSIZE, &sshdr); - if (sshdr.sense_key == 0 && - sshdr.asc == 0 && sshdr.ascq == 0) + if (sshdr.sense_key == RECOVERED_ERROR && + sshdr.asc == 0 && sshdr.ascq == 0x1D) cmd_result &= ~SAM_STAT_CHECK_CONDITION; } -- 1.8.1.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/
[ANNOUNCE] 3.4.37-rt51
Dear RT Folks, I'm pleased to announce the 3.4.37-rt51 stable release. This release is just an update to the new stable 3.4.37 version and no RT specific changes have been made. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git Head SHA1: 22e619fae734cfd64eae596333aadbfdb9e60d39 Or to build 3.4.37-rt51 directly, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.4.tar.xz http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.4.37.xz http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/patch-3.4.37-rt51.patch.xz Enjoy, -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] hugetlbfs: stop setting VM_DONTDUMP in initializing vma(VM_HUGETLB)
Naoya Horiguchi wrote:
> On Thu, Mar 28, 2013 at 09:03:16PM +0400, Konstantin Khlebnikov wrote:
>> Naoya Horiguchi wrote:
>>> Currently we fail to include any data on hugepages into coredump,
>>> because VM_DONTDUMP is set on hugetlbfs's vma. This behavior was recently
>>> introduced by commit 314e51b98 "mm: kill vma flag VM_RESERVED and
>>> mm->reserved_vm counter". This looks to me a serious regression,
>>> so let's fix it.
>>
>> That was introduced in my patch? Really?
>> Here was VM_RESERVED and it had the same effect as VM_DONTDUMP. At least I
>> thought so.
>
> vma_dump_size() does like this (the diff is the one in 314e51b98):
>
> static unsigned long vma_dump_size(struct vm_area_struct *vma,
> unsigned long mm_flags)
> {
> #define FILTER(type) (mm_flags& (1UL<< MMF_DUMP_##type))
>
> /* always dump the vdso and vsyscall sections */
> if (always_dump_vma(vma))
> goto whole;
>
> if (vma->vm_flags& VM_DONTDUMP)
> return 0;
>
> /* Hugetlb memory check */
> if (vma->vm_flags& VM_HUGETLB) {
> if ((vma->vm_flags& VM_SHARED)&& FILTER(HUGETLB_SHARED))
> goto whole;
> if (!(vma->vm_flags& VM_SHARED)&& FILTER(HUGETLB_PRIVATE))
> goto whole;
> }
>
> /* Do not dump I/O mapped devices or special mappings */
>- if (vma->vm_flags& (VM_IO | VM_RESERVED))
>+ if (vma->vm_flags& VM_IO)
> return 0;
>
> We have hugetlb memory check after VM_DONTDUMP check, so the following
> changed the behavior.
Ok, I missed this in my patch.
>
>--- a/fs/hugetlbfs/inode.c
>+++ b/fs/hugetlbfs/inode.c
>@@ -110,7 +110,7 @@ static int hugetlbfs_file_mmap(struct file *file,
> struct vm_area_struct *vma)
> * way when do_mmap_pgoff unwinds (may be important on powerpc
> * and ia64).
> */
>- vma->vm_flags |= VM_HUGETLB | VM_RESERVED;
>+ vma->vm_flags |= VM_HUGETLB | VM_DONTEXPAND | VM_DONTDUMP;
>vma->vm_ops =&hugetlb_vm_ops;
>
>if (vma->vm_pgoff& (~huge_page_mask(h)>> PAGE_SHIFT))
>
> I think we don't have to set VM_DONTDUMP on hugetlbfs's vma.
Acked-by: Konstantin Khlebnikov
>
> Thanks,
> Naoya
--
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 03/10] soft-offline: use migrate_pages() instead of migrate_huge_page()
Michal Hocko writes: > On Tue 26-03-13 16:59:40, Aneesh Kumar K.V wrote: >> Naoya Horiguchi writes: > [...] >> > diff --git v3.9-rc3.orig/mm/memory-failure.c v3.9-rc3/mm/memory-failure.c >> > index df0694c..4e01082 100644 >> > --- v3.9-rc3.orig/mm/memory-failure.c >> > +++ v3.9-rc3/mm/memory-failure.c >> > @@ -1467,6 +1467,7 @@ static int soft_offline_huge_page(struct page *page, >> > int flags) >> >int ret; >> >unsigned long pfn = page_to_pfn(page); >> >struct page *hpage = compound_head(page); >> > + LIST_HEAD(pagelist); >> > >> >/* >> > * This double-check of PageHWPoison is to avoid the race with >> > @@ -1482,12 +1483,20 @@ static int soft_offline_huge_page(struct page >> > *page, int flags) >> >unlock_page(hpage); >> > >> >/* Keep page count to indicate a given hugepage is isolated. */ >> > - ret = migrate_huge_page(hpage, new_page, MPOL_MF_MOVE_ALL, >> > - MIGRATE_SYNC); >> > - put_page(hpage); >> > + list_move(&hpage->lru, &pagelist); >> >> we use hpage->lru to add the hpage to h->hugepage_activelist. This will >> break a hugetlb cgroup removal isn't it ? > > This particular part will not break removal because > hugetlb_cgroup_css_offline loops until hugetlb_cgroup_have_usage is 0. > > Little bit offtopic: > Btw. hugetlb migration breaks to charging even before this patchset > AFAICS. The above put_page should remove the last reference and then it > will uncharge it but I do not see anything that would charge a new page. > This is all because regula LRU pages are uncharged when they are > unmapped. But this a different story not related to this series. But when we call that put_page, we would have alreayd move the cgroup information to the new page. We have h_cg = hugetlb_cgroup_from_page(oldhpage); set_hugetlb_cgroup(oldhpage, NULL); /* move the h_cg details to new cgroup */ set_hugetlb_cgroup(newhpage, h_cg); in hugetlb_cgroup_migrate -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: Bug in ks8851.c
Linus,
I tried to send the mail to 'Ben Dooks ' but the address
is dead now.
> I assume you've tested it in practice?
Yes, I'm running the modified code both in bootloader and Linux kernel on
my board.
Thanks,
Max
Signed-off-by: Max Nekludov
---
drivers/net/ethernet/micrel/ks8851.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/micrel/ks8851.c
b/drivers/net/ethernet/micrel/ks8851.c
index 33bcb63d56a2..8fb481252e2c 100644
--- a/drivers/net/ethernet/micrel/ks8851.c
+++ b/drivers/net/ethernet/micrel/ks8851.c
@@ -528,7 +528,7 @@ static void ks8851_rx_pkts(struct ks8851_net *ks)
for (; rxfc != 0; rxfc--) {
rxh = ks8851_rdreg32(ks, KS_RXFHSR);
rxstat = rxh & 0x;
- rxlen = rxh >> 16;
+ rxlen = (rxh >> 16) & 0xfff;
netif_dbg(ks, rx_status, ks->netdev,
"rx: stat 0x%04x, len 0x%04x\n", rxstat, rxlen);
Max,
please cc the actual maintainers of the driver. The patch looks sane,
though. I assume you've tested it in practice?
You also seem to have based this on an ancient version, the code has
long since moved from drivers/net/ks8851.c to
drivers/net/ethernet/micrel/ks8851.c (back in June of 2011), and it's
missing a sign-off from you.
I'm attaching an updated patch for the rename/capitalization issue.
Linus
On Thu, Mar 28, 2013 at 11:25 AM, wrote:
>
> According to the Datasheet (page 52):
> 15-12 Reserved
> 11-0 RXBC Receive Byte Count
> This field indicates the present received frame byte size.
>
> I suppose the code has a bug:
> rxh = ks8851_rdreg32(ks, KS_RXFHSR);
> rxstat = rxh & 0x;
> rxlen = rxh >> 16; // BUG!!! 0xFFF mask should be applied
>
> P.S.
> without bit mask applied I saw rxlen equal to 15360 which is bigger then
> entire RX queue size (12KB).
>
> Thanks,
> Max Nekludov
>
> From cb3199cee4490f98d6062e32a75ca377a32b55bc Mon Sep 17 00:00:00 2001
> From: Max Neklyudov
> Date: Tue, 26 Mar 2013 11:46:57 +0400
> Subject: [PATCH] Fix bug in ks8851 driver
>
> ---
> drivers/net/ks8851.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ks8851.c b/drivers/net/ks8851.c
> index 91a93cb..0dc03da 100644
> --- a/drivers/net/ks8851.c
> +++ b/drivers/net/ks8851.c
> @@ -553,7 +553,7 @@ static void ks8851_rx_pkts(struct ks8851_net *ks)
> for (; rxfc != 0; rxfc--) {
> rxh = ks8851_rdreg32(ks, KS_RXFHSR);
> rxstat = rxh & 0x;
> - rxlen = rxh >> 16;
> + rxlen = (rxh >> 16) & 0xFFF;
>
> netif_dbg(ks, rx_status, ks->netdev,
> "rx: stat 0x%04x, len 0x%04x\n", rxstat,
rxlen);
> --
> 1.7.10.4
>
__
This email has been spam and virus checked by Elster IT Services.(See
attached file: patch.diff)
patch.diff
Description: Binary data
Re: Generic syscall ABI support
On 03/28/2013 09:41 PM, Rob Landley wrote: > > You don't need a new glibc port, you need a new klibc or musl port. > > http://www.openwall.com/lists/musl/2012/07/08/1 > > Way less work than getting glibc working for your basic smoketest... > Good point. Average time to port klibc to a new architecture is about four hours as long as the person porting knows the calling conventions and assembly language involved. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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] perf: add callgrind conversion tool
On Thu, Mar 28, 2013 at 9:18 PM, Namhyung Kim wrote: > On Thu, Mar 28, 2013 at 04:58:30PM -0700, Sukadev Bhattiprolu wrote: >> Roberto Vitillo [raviti...@lbl.gov] wrote: >> | The proposed patch adds the convert tool to perf which allows to convert a >> | perf.data file to a set of callgrind data files which can subsequently be >> | displayed with kcachegrind. >> >> Sounds interesting and useful. My only comment is that 'convert' is a >> generic term and this is converting to a specific format (i.e callgrind). >> In theory we could have conversions to other formats in the future ? > > Maybe we can support converting to CTF or someother formats which have > nice viewer? That sounds like a good idea. I could add a -t option to the convert tool that allows to specify the output format. Initially the tool would have just the callgrind one but later on we can add support for CTF and possibly other formats. Roberto -- 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: Generic syscall ABI support
On 03/28/2013 06:42:47 AM, Arnd Bergmann wrote: On Thursday 28 March 2013, Ley Foon Tan wrote: > On Thu, 2013-03-28 at 10:40 +, Arnd Bergmann wrote: > > On Thursday 28 March 2013, Ley Foon Tan wrote: > > > We will working on generic ABI for kernel and Glibc. This might take > > > some times. > > > > Ok. Don't let that hold you up from submitting the kernel patches > > for review though. > > Do you mean we can submit the patches for review before we got the > generic ABI support? I mean you can send the other patches for review already. Changing your implementtion to use the generic ABI will basically just mean not sending the patches tht implement your own ABI, so that's not hard. Of course until you also have a new glibc port, you won't be able to test that it actually works, but that is not essential for the reviewing stage. You don't need a new glibc port, you need a new klibc or musl port. http://www.openwall.com/lists/musl/2012/07/08/1 Way less work than getting glibc working for your basic smoketest... Rob-- 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] perf: add callgrind conversion tool
On Thu, Mar 28, 2013 at 04:58:30PM -0700, Sukadev Bhattiprolu wrote: > Roberto Vitillo [raviti...@lbl.gov] wrote: > | The proposed patch adds the convert tool to perf which allows to convert a > | perf.data file to a set of callgrind data files which can subsequently be > | displayed with kcachegrind. > > Sounds interesting and useful. My only comment is that 'convert' is a > generic term and this is converting to a specific format (i.e callgrind). > In theory we could have conversions to other formats in the future ? Maybe we can support converting to CTF or someother formats which have nice viewer? Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Documentation: Add ABI entry for crash_notes and crash_notes_size
On Thu, Mar 28, 2013 at 04:16:45PM +0800, Zhang Yanfei wrote: > Add an Documentation/ABI entry for /sys/devices/system/cpu/cpu0/crash_notes > and /sys/devices/system/cpu/cpu0/crash_notes_size. > > Cc: Greg KH > Cc: "Eric W. Biederman" > Cc: Vivek Goyal > Signed-off-by: Zhang Yanfei Assuming that patch 1 of this series is accepted: Acked-by: Simon Horman > --- > Documentation/ABI/testing/sysfs-devices-system-cpu | 12 > 1 files changed, 12 insertions(+), 0 deletions(-) > > diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu > b/Documentation/ABI/testing/sysfs-devices-system-cpu > index 9c978dc..2447698 100644 > --- a/Documentation/ABI/testing/sysfs-devices-system-cpu > +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu > @@ -173,3 +173,15 @@ Description: Processor frequency boosting control > Boosting allows the CPU and the firmware to run at a frequency > beyound it's nominal limit. > More details can be found in Documentation/cpu-freq/boost.txt > + > + > +What:/sys/devices/system/cpu/cpu#/crash_notes > + /sys/devices/system/cpu/cpu#/crash_notes_size > +Date:April 2013 > +Contact: ke...@lists.infradead.org > +Description: address and size of the percpu note. > + > + crash_notes: the physical address of the memory that holds the > + note of cpu#. > + > + crash_notes_size: size of the note of cpu#. > -- > 1.7.1 > > > ___ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec > -- 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] sysfs: Add crash_notes_size to export percpu note size
On Fri, Mar 29, 2013 at 11:50:35AM +0800, Zhang Yanfei wrote:
> Hi, simon
>
> I forgot to add your email in the CC, could you please help
> reviewing this patch since I will send the kexec-tools patch
> if this patch is accepted.
>
> Thanks
> Zhang
>
> 于 2013年03月28日 16:15, Zhang Yanfei 写道:
> > For percpu notes, we are exporting only address and not size. So
> > the userspace tool kexec-tools is putting an upper limit of 1024
> > and putting the value in p_memsz and p_filesz fields. So the patch
> > add the new sysfile crash_notes_size to export the exact percpu
> > note size and let the kexec-tools parse it intead of using 1024.
> >
> > The idea came from Vivek Goyal. And a later patch will be sent to
> > kexec-tools to let it parse the size.
Acked-by: Simon Horman
> >
> > Cc: Greg KH
> > Cc: "Eric W. Biederman"
> > Cc: Vivek Goyal
> > Signed-off-by: Zhang Yanfei
> > ---
> > drivers/base/cpu.c | 14 ++
> > 1 files changed, 14 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
> > index fb10728..a55b590 100644
> > --- a/drivers/base/cpu.c
> > +++ b/drivers/base/cpu.c
> > @@ -132,6 +132,17 @@ static ssize_t show_crash_notes(struct device *dev,
> > struct device_attribute *att
> > return rc;
> > }
> > static DEVICE_ATTR(crash_notes, 0400, show_crash_notes, NULL);
> > +
> > +static ssize_t show_crash_notes_size(struct device *dev,
> > +struct device_attribute *attr,
> > +char *buf)
> > +{
> > + ssize_t rc;
> > +
> > + rc = sprintf(buf, "%lu\n", sizeof(note_buf_t));
> > + return rc;
> > +}
> > +static DEVICE_ATTR(crash_notes_size, 0400, show_crash_notes_size, NULL);
> > #endif
> >
> > /*
> > @@ -259,6 +270,9 @@ int __cpuinit register_cpu(struct cpu *cpu, int num)
> > #ifdef CONFIG_KEXEC
> > if (!error)
> > error = device_create_file(&cpu->dev, &dev_attr_crash_notes);
> > + if (!error)
> > + error = device_create_file(&cpu->dev,
> > + &dev_attr_crash_notes_size);
> > #endif
> > return error;
> > }
>
>
--
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] sysfs: Add crash_notes_size to export percpu note size
Hi, simon
I forgot to add your email in the CC, could you please help
reviewing this patch since I will send the kexec-tools patch
if this patch is accepted.
Thanks
Zhang
于 2013年03月28日 16:15, Zhang Yanfei 写道:
> For percpu notes, we are exporting only address and not size. So
> the userspace tool kexec-tools is putting an upper limit of 1024
> and putting the value in p_memsz and p_filesz fields. So the patch
> add the new sysfile crash_notes_size to export the exact percpu
> note size and let the kexec-tools parse it intead of using 1024.
>
> The idea came from Vivek Goyal. And a later patch will be sent to
> kexec-tools to let it parse the size.
>
> Cc: Greg KH
> Cc: "Eric W. Biederman"
> Cc: Vivek Goyal
> Signed-off-by: Zhang Yanfei
> ---
> drivers/base/cpu.c | 14 ++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
> index fb10728..a55b590 100644
> --- a/drivers/base/cpu.c
> +++ b/drivers/base/cpu.c
> @@ -132,6 +132,17 @@ static ssize_t show_crash_notes(struct device *dev,
> struct device_attribute *att
> return rc;
> }
> static DEVICE_ATTR(crash_notes, 0400, show_crash_notes, NULL);
> +
> +static ssize_t show_crash_notes_size(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + ssize_t rc;
> +
> + rc = sprintf(buf, "%lu\n", sizeof(note_buf_t));
> + return rc;
> +}
> +static DEVICE_ATTR(crash_notes_size, 0400, show_crash_notes_size, NULL);
> #endif
>
> /*
> @@ -259,6 +270,9 @@ int __cpuinit register_cpu(struct cpu *cpu, int num)
> #ifdef CONFIG_KEXEC
> if (!error)
> error = device_create_file(&cpu->dev, &dev_attr_crash_notes);
> + if (!error)
> + error = device_create_file(&cpu->dev,
> +&dev_attr_crash_notes_size);
> #endif
> return error;
> }
--
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] nohz: Print final full dynticks CPUs range on boot
On Thu, Mar 28, 2013 at 10:08:23PM -0400, Paul Gortmaker wrote:
> [Re: [PATCH 2/4] nohz: Print final full dynticks CPUs range on boot] On
> 28/03/2013 (Thu 19:00) Paul E. McKenney wrote:
>
> > On Fri, Mar 29, 2013 at 01:39:04AM +0100, Frederic Weisbecker wrote:
> > > 2013/3/29 Paul Gortmaker :
> > > > [Re: [PATCH 2/4] nohz: Print final full dynticks CPUs range on boot] On
> > > > 28/03/2013 (Thu 08:40) Ingo Molnar wrote:
> > > >
> > > >>
> > > >> * Frederic Weisbecker wrote:
> > > >>
> > > >> > + cpulist_scnprintf(nohz_ext_buf, sizeof(nohz_ext_buf),
> > > >> > nohz_extended_mask);
> > > >> > + pr_info("NO_HZ: Experimental full dynticks CPUs: %s.\n",
> > > >> > nohz_ext_buf);
> > > >>
> > > >> I'd suggest removing the 'experimental' word. We are not sending
> > > >> anything
> > > >> experimental to Linus: we'll send something that is tested and that we
> > > >> expect to not break anything. (and which we'll fix if it does)
> > > >
> > > > In that case, should we vector a patch through PaulM to clobber these
> > > > too?
> > > >
> > > > $ git grep xperiment |grep rcu
> > > > kernel/rcutree_plugin.h: printk(KERN_INFO "\tExperimental boot-time
> > > > adjustment of leaf fanout to %d.\n", rcu_fanout_leaf);
> >
> > This one has been this way for quite some time. I must confess that I am
> > more inclined to remove this Kconfig option entirely than I am to remove
> > the "Experimental". ;-)
> >
> > > > kernel/rcutree_plugin.h: pr_info("\tExperimental no-CBs CPUs: %s.\n",
> > > > nocb_buf);
> > > > kernel/rcutree_plugin.h: pr_info("\tExperimental polled no-CBs
> > > > CPUs.\n");
> > >
> > > Hehe, that's indeed what I inspired from ;-)
> >
> > I guess we can rerun the earlier "how to mark Kconfig options as not
> > yet being ready for 100 million unsuspecting victims^Wusers. ;-)
>
> Perhaps consider "hiding" these kinds of choices behind CONFIG_EXPERT ?
We tried that with CONFIG_EXPERIMENTAL (or something like that), and
what happened was that all distros eventually enabled CONFIG_EXPERIMENTAL.
But if I was -really- serious about keeping the testing population down,
I would take Matthew Garret's advice and force a splat during boot-up.
So I now have a commit for 3.11 queued to remove the "Experimental"
from these strings, with your Reported-by.
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ARM: remove mach .init_irq for irqchip_init users
On Thu, Mar 28, 2013 at 07:24:02PM +0100, Maxime Ripard wrote: > Hi Simon, > > Le 28/03/2013 13:42, Simon Horman a écrit : > > On Thu, Mar 28, 2013 at 10:41:44AM +0100, Maxime Ripard wrote: > >> Now that the arm core code calls irqchip_init, we can remove it from all > >> the machines that were using it. > >> > >> Signed-off-by: Maxime Ripard > >> --- > >> arch/arm/mach-bcm/board_bcm.c |1 - > >> arch/arm/mach-msm/board-dt-8660.c |1 - > >> arch/arm/mach-msm/board-dt-8960.c |1 - > >> arch/arm/mach-nomadik/cpu-8815.c |1 - > >> arch/arm/mach-picoxcell/common.c |1 - > >> arch/arm/mach-prima2/common.c |1 - > >> arch/arm/mach-shmobile/board-kzm9g-reference.c |1 - > >> arch/arm/mach-shmobile/setup-emev2.c |1 - > >> arch/arm/mach-shmobile/setup-sh73a0.c |1 - > >> arch/arm/mach-spear/spear1310.c|1 - > >> arch/arm/mach-spear/spear1340.c|1 - > >> arch/arm/mach-spear/spear300.c |1 - > >> arch/arm/mach-spear/spear310.c |1 - > >> arch/arm/mach-spear/spear320.c |1 - > >> arch/arm/mach-spear/spear6xx.c |1 - > >> arch/arm/mach-vexpress/v2m.c |1 - > >> arch/arm/mach-virt/virt.c |1 - > >> arch/arm/mach-zynq/common.c|1 - > >> 18 files changed, 18 deletions(-) > > > > mach-shmobile portion: > > > > Acked-by: Simon Horman > > Thanks! > > > > > I have some new users of this queued up for v3.10. > > How should we handle that? > > Since the old behaviour is preserved, I guess it doesn't matter much, > and one of us can always make a followup patch on top of these patches. Ok, sound good. -- 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/3] ftrace: Do not call stub functions in control loop
On 03/28/2013 08:52 PM, Steven Rostedt wrote:
> From: "Steven Rostedt (Red Hat)"
>
> The function tracing control loop used by perf spits out a warning
> if the called function is not a control function. This is because
> the control function references a per cpu allocated data structure
> on struct ftrace_ops that is not allocated for other types of
> functions.
>
> commit 0a016409e42 "ftrace: Optimize the function tracer list loop"
>
> Had an optimization done to all function tracing loops to optimize
> for a single registered ops. Unfortunately, this allows for a slight
> race when tracing starts or ends, where the stub function might be
> called after the current registered ops is removed. In this case we
> get the following dump:
>
> root# perf stat -e ftrace:function sleep 1
> [ 74.339105] WARNING: at include/linux/ftrace.h:209
> ftrace_ops_control_func+0xde/0xf0()
> [ 74.349522] Hardware name: PRIMERGY RX200 S6
> [ 74.357149] Modules linked in: sg igb iTCO_wdt ptp pps_core
> iTCO_vendor_support i7core_edac dca lpc_ich i2c_i801 coretemp edac_core
> crc32c_intel mfd_core ghash_clmulni_intel dm_multipath acpi_power_meter pcspk
> r microcode vhost_net tun macvtap macvlan nfsd kvm_intel kvm auth_rpcgss
> nfs_acl lockd sunrpc uinput xfs libcrc32c sd_mod crc_t10dif sr_mod cdrom
> mgag200 i2c_algo_bit drm_kms_helper ttm qla2xxx mptsas ahci drm li
> bahci scsi_transport_sas mptscsih libata scsi_transport_fc i2c_core mptbase
> scsi_tgt dm_mirror dm_region_hash dm_log dm_mod
> [ 74.446233] Pid: 1377, comm: perf Tainted: GW3.9.0-rc1 #1
> [ 74.453458] Call Trace:
> [ 74.456233] [] warn_slowpath_common+0x7f/0xc0
> [ 74.462997] [] ? rcu_note_context_switch+0xa0/0xa0
> [ 74.470272] [] ? __unregister_ftrace_function+0xa2/0x1a0
> [ 74.478117] [] warn_slowpath_null+0x1a/0x20
> [ 74.484681] [] ftrace_ops_control_func+0xde/0xf0
> [ 74.491760] [] ftrace_call+0x5/0x2f
> [ 74.497511] [] ? ftrace_call+0x5/0x2f
> [ 74.503486] [] ? ftrace_call+0x5/0x2f
> [ 74.509500] [] ? synchronize_sched+0x5/0x50
> [ 74.516088] [] ? _cond_resched+0x5/0x40
> [ 74.522268] [] ? synchronize_sched+0x5/0x50
> [ 74.528837] [] ? __unregister_ftrace_function+0xa2/0x1a0
> [ 74.536696] [] ? _cond_resched+0x5/0x40
> [ 74.542878] [] ? mutex_lock+0x1d/0x50
> [ 74.548869] [] unregister_ftrace_function+0x27/0x50
> [ 74.556243] [] perf_ftrace_event_register+0x9f/0x140
> [ 74.563709] [] ? _cond_resched+0x5/0x40
> [ 74.569887] [] ? mutex_lock+0x1d/0x50
> [ 74.575898] [] perf_trace_destroy+0x2e/0x50
> [ 74.582505] [] tp_perf_event_destroy+0x9/0x10
> [ 74.589298] [] free_event+0x70/0x1a0
> [ 74.595208] [] perf_event_release_kernel+0x69/0xa0
> [ 74.602460] [] ? _cond_resched+0x5/0x40
> [ 74.608667] [] put_event+0x90/0xc0
> [ 74.614373] [] perf_release+0x10/0x20
> [ 74.620367] [] __fput+0xf4/0x280
> [ 74.625894] [] fput+0xe/0x10
> [ 74.631387] [] task_work_run+0xa7/0xe0
> [ 74.637452] [] do_notify_resume+0x71/0xb0
> [ 74.643843] [] int_signal+0x12/0x17
>
> To fix this a new ftrace_ops flag is added that denotes the ftrace_list_end
> ftrace_ops stub as just that, a stub. This flag is now checked in the
> control loop and the function is not called if the flag is set.
>
> Thanks to Jovi for not just reporting the bug, but also pointing out
> where the bug was in the code.
>
> Link: http://lkml.kernel.org/r/514a8855.7090...@redhat.com
> Link:
> http://lkml.kernel.org/r/1364377499-1900-15-git-send-email-jovi.zhang...@huawei.com
>
> Reported-by: WANG Chao
> Reported-by: zhangwei(Jovi)
> Signed-off-by: Steven Rostedt
> ---
> include/linux/ftrace.h |2 ++
> kernel/trace/ftrace.c |5 +++--
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> index e5ca8ef..167abf9 100644
> --- a/include/linux/ftrace.h
> +++ b/include/linux/ftrace.h
> @@ -89,6 +89,7 @@ typedef void (*ftrace_func_t)(unsigned long ip, unsigned
> long parent_ip,
> *that the call back has its own recursion protection. If it does
> *not set this, then the ftrace infrastructure will add recursion
> *protection for the caller.
> + * STUB - The ftrace_ops is just a place holder.
> */
> enum {
> FTRACE_OPS_FL_ENABLED = 1 << 0,
> @@ -98,6 +99,7 @@ enum {
> FTRACE_OPS_FL_SAVE_REGS = 1 << 4,
> FTRACE_OPS_FL_SAVE_REGS_IF_SUPPORTED= 1 << 5,
> FTRACE_OPS_FL_RECURSION_SAFE= 1 << 6,
> + FTRACE_OPS_FL_STUB = 1 << 7,
> };
>
> struct ftrace_ops {
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index cc4943c..7e89710 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -66,7 +66,7 @@
>
> static struct ftrace_ops ftrace_list_end __read_mostly = {
> .func = ftrace_stub,
> - .flags = FTRACE_OPS_FL_RECURSION_S
[ANNOUNCE] 3.6.11.1-rt32
Dear RT Folks, I'm pleased to announce the 3.6.11.1-rt32 stable release. This release is just an update to the new stable 3.6.11.1 version and no RT specific changes have been made. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git Head SHA1: 54cf98b026bf3bdcb5a3584061cdf2000ab423f3 Or to build 3.6.11.1-rt32 directly, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.6.tar.xz http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.6.11.xz http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/stable/patch-3.6.11.1.xz http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/patch-3.6.11.1-rt32.patch.xz Enjoy, -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI: Remove not needed check in disable aspm link
[+cc Matthew] [+cc e1000-de...@lists.sourceforge.net for suspected 82575/82598 regression] On Thu, Mar 28, 2013 at 01:24:55PM -0700, Yinghai Lu wrote: > patch for Roman > > On Thu, Mar 28, 2013 at 1:24 PM, Yinghai Lu wrote: > > resending with adding To Roman. > > > > On Thu, Mar 28, 2013 at 5:46 AM, Bjorn Helgaas wrote: > >> This patch might be *safe*, but it (and the changelog) are completely > >> unintelligible. > >> > >> The problem with applying an unintelligible stop-gap patch is that it > >> becomes forever part of the changelog, and it's a huge waste of time > >> to everybody who tries to understand the history later. That's why I > >> think it's worth spending some time to make a good patch now. > > > > Please check if attached patch is doing what you want. Patch inlined below for convenience. > Subject: [PATCH] PCI: Remove not needed check in disable aspm link > > Roman reported ath5k does not work anymore on 3.8. > Bisected to > | commit 8c33f51df406e1a1f7fa4e9b244845b7ebd61fa6 > | Author: Taku Izumi > | Date: Tue Oct 30 15:27:13 2012 +0900 > | > |PCI/ACPI: Request _OSC control before scanning PCI root bus > | > |This patch moves up the code block to request _OSC control in order to > |separate ACPI work and PCI work in acpi_pci_root_add(). > > It make pci_disable_link_state does not work anymore as acpi_disabled > is set before pci root bus scanning. > It will skip that in quirks and pcie_aspm_sanity_check. I think this regression has nothing to do with pci_disable_link_state(). When aspm_disabled is set, pci_disable_link_state() doesn't do anything. In both 3.7 and 3.8, aspm_disabled is set in acpi_pci_root_add() before any driver probe routines are run, so it looks like calling pci_disable_link_state() from a driver had no effect even in 3.7. This is a problem, of course, but not the one Roman is seeing, because ath5k calls pci_disable_link_state() from the driver probe routine. There are also PCI_FIXUP_FINAL quirks for 82575 and 82598 NICs that call pci_disable_link_state(). In 3.7, these quirks are run before aspm_disabled is set, but 8c33f51d moved the pcie_no_aspm() call up before we start scanning the bus, so in 3.8, aspm_disabled is set *before* we run them. I think that means 8c33f51d broke all these quirks. That's also a problem, of course, but this isn't the one Roman is seeing either. I think the problem Roman is seeing happens when pcie_aspm_init_link_state() calls pcie_aspm_sanity_check() during device enumeration. In 3.8, the fact that aspm_disabled is already set by the time we get here means we skip the check for pre-1.1 PCIe devices, and I think *this* is what Roman is seeing. I suspect the following hunk of your patch is enough to fix things for Roman: > --- linux-2.6.orig/drivers/pci/pcie/aspm.c > +++ linux-2.6/drivers/pci/pcie/aspm.c > @@ -493,15 +492,6 @@ static int pcie_aspm_sanity_check(struct > return -EINVAL; > > /* > - * If ASPM is disabled then we're not going to change > - * the BIOS state. It's safe to continue even if it's a > - * pre-1.1 device > - */ > - > - if (aspm_disabled) > - continue; > - > - /* >* Disable ASPM for pre-1.1 PCIe device, we follow MS to use >* RBER bit to determine if a function is 1.1 version device >*/ However, this test was added by Matthew in c9651e70, and I can't remove it unless we have an explanation of why removing it will not reintroduce the bug he was fixing. This code is such a terrible mess that it's not surprising at all that we have all these issues. But there's too much to untangle in v3.9; all we can hope for is to fix the regressions in v3.9 and clean it up later. > We could revert to old logic, but that will make booting path and hotplug > path with different aspm_disabled again. > > Acctually we don't need to check aspm_disabled in disable link, as > we already have protection about link state following. > > https://bugzilla.kernel.org/show_bug.cgi?id=55211 > http://article.gmane.org/gmane.linux.kernel.pci/20640 > > Need it for 3.8 stable. > > -v2: more cleanup > 1. remove aspm_support_enabled, as if it compiled in, support is there > so even user pass aspm=off, link_state still get allocated, > then we will have chance to disable aspm on devices from > buggy setting of BIOS. > 2. move pcie_no_aspm() calling for fadt disabling before scanning > requested by Bjorn. > > Reported-by: Roman Yepishev > Bisected-by: Roman Yepishev > Signed-off-by: Yinghai Lu > Cc: Taku Izumi > Cc: Kenji Kaneshige > > --- > drivers/acpi/pci_root.c | 25 +--- > drivers/pci/pcie/aspm.c | 48 > ++- > include/linux/pci-aspm.h |4 --- > include/linux/pci.h |2 - > 4 files c
Re: [PATCH] include/linux: printk is needed in filter.h when CONFIG_BPF_JIT is defined
On 2013年03月29日 02:31, David Miller wrote: > Please post networking patches to net...@vger.kernel.org, thanks. ok, thanks, it is my fault. originally, I get the mail addresses from ./scripts/get_maintainer.pl. it is a useful tool to help members to find mail addresses. I should fully use it, but should not depend on it. next time, I should think of the mail addresses, after get them from the tool. thanks. -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fuse: Don't do file_update_time for write_operation.
For direct-write and normal-write operations, after write they will call
fuse_invalidate_attr.
So it's make no sense to call file_update_time before writing.
In function file_update_time, there is other thing which update version of
inode.For this i am not sure.
Signed-off-by: Jianpeng Ma
---
fs/fuse/file.c | 4
1 file changed, 4 deletions(-)
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 34b80ba..214279c 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -988,10 +988,6 @@ static ssize_t fuse_file_aio_write(struct kiocb *iocb,
const struct iovec *iov,
if (err)
goto out;
- err = file_update_time(file);
- if (err)
- goto out;
-
if (file->f_flags & O_DIRECT) {
written = generic_file_direct_write(iocb, iov, &nr_segs,
pos, &iocb->ki_pos,
--
1.8.2.rc2.4.g7799588
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] net-next: replace obsolete NLMSG_* with type safe nlmsg_*
On 03/27/2013 12:47 PM, Hong Zhiguo wrote:
> Signed-off-by: Hong Zhiguo
> diff --git a/net/ieee802154/netlink.c b/net/ieee802154/netlink.c
> index 97351e1..9247252 100644
> --- a/net/ieee802154/netlink.c
> +++ b/net/ieee802154/netlink.c
> @@ -65,7 +65,7 @@ struct sk_buff *ieee802154_nl_create(int flags, u8 req)
> int ieee802154_nl_mcast(struct sk_buff *msg, unsigned int group)
> {
> /* XXX: nlh is right at the start of msg */
> - void *hdr = genlmsg_data(NLMSG_DATA(msg->data));
> + void *hdr = genlmsg_data(nlmsg_data(msg->data));
>
> if (genlmsg_end(msg, hdr) < 0)
> goto out;
> @@ -98,7 +98,7 @@ struct sk_buff *ieee802154_nl_new_reply(struct genl_info
> *info,
> int ieee802154_nl_reply(struct sk_buff *msg, struct genl_info *info)
> {
> /* XXX: nlh is right at the start of msg */
> - void *hdr = genlmsg_data(NLMSG_DATA(msg->data));
> + void *hdr = genlmsg_data(nlmsg_data(msg->data));
>
> if (genlmsg_end(msg, hdr) < 0)
> goto out;
CC [M] net/ieee802154/netlink.o
net/ieee802154/netlink.c: In function ‘ieee802154_nl_mcast’:
net/ieee802154/netlink.c:68: warning: passing argument 1 of ‘nlmsg_data’ from
incompatible pointer type
include/net/netlink.h:302: note: expected ‘const struct nlmsghdr *’ but argument
is of type ‘unsigned char *’
net/ieee802154/netlink.c: In function ‘ieee802154_nl_reply’:
net/ieee802154/netlink.c:101: warning: passing argument 1 of ‘nlmsg_data’ from
incompatible pointer type
include/net/netlink.h:302: note: expected ‘const struct nlmsghdr *’ but argument
is of type ‘unsigned char *’
-Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/7] USB: EHCI: make ehci-spear a separate driver
On Fri, Mar 29, 2013 at 3:25 AM, Arnd Bergmann wrote: > From: Manjunath Goudar > > Separate the SPEAr host controller driver from ehci-hcd host code > so that it can be built as a separate driver module. > This work is part of enabling multi-platform kernels on ARM; > however, note that other changes are still needed before SPEAr can be > booted with a multi-platform kernel, but they are queued in the > arm-soc tree for 3.10. > > With the infrastructure added by Alan Stern in patch 3e0232039 > "USB: EHCI: prepare to make ehci-hcd a library module", we can > avoid this problem by turning a bus glue into a separate > module, as we do here for the SPEAr bus glue. > > In V3: > -Detailed commit message added here about why this patch is required. > -Eliminated ehci_spear_setup routine beacuse hcd registers > directly setting in spear_ehci_hcd_drv_probe function. > -spear_overrides struct initialized. > -Eliminate struct ehci_hcd ehci from struct spear_ehci,to enable SPEAr clock > uses directly usb_hcd *hcd in spear_start_ehci function. > -to_spear_ehci() macro modified for spear_ehci. > > In V2: > Replaced spear as SPEAr everywhere, leaving functions/variables/config > options. > > Signed-off-by: Deepak Saxena > Signed-off-by: Manjunath Goudar > Signed-off-by: Arnd Bergmann > Acked-by: Viresh Kumar This version has changed from what i Acked, but it still looks fine. Thanks. Viresh -- 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: [RT LATENCY] 249 microsecond latency caused by slub's unfreeze_partials() code.
On Thu, Mar 28, 2013 at 1:30 PM, Christoph Lameter wrote:
> This patch requires the earlier bug fix.
>
>
> Subject: slub: Make cpu partial slab support configurable
Hi Christoph,
Minor nit:
Applying: slub: Make cpu partial slab support configurable
/home/paul/git/linux-head/.git/rebase-apply/patch:141: space before
tab in indent.
{ /* Needs to be taken off a list */
warning: 1 line adds whitespace errors.
I've tagged the block below where this happens.
Also I've got a question/comment about the Kconfig addition below...
>
> cpu partial support can introduce level of indeterminism that is not wanted
> in certain context (like a realtime kernel). Make it configurable.
>
> Signed-off-by: Christoph Lameter
>
> Index: linux/include/linux/slub_def.h
> ===
> --- linux.orig/include/linux/slub_def.h 2013-03-28 12:14:26.958358688 -0500
> +++ linux/include/linux/slub_def.h 2013-03-28 12:19:46.275866639 -0500
> @@ -47,7 +47,9 @@ struct kmem_cache_cpu {
> void **freelist;/* Pointer to next available object */
> unsigned long tid; /* Globally unique transaction id */
> struct page *page; /* The slab from which we are allocating */
> +#ifdef CONFIG_SLUB_CPU_PARTIAL
> struct page *partial; /* Partially allocated frozen slabs */
> +#endif
> #ifdef CONFIG_SLUB_STATS
> unsigned stat[NR_SLUB_STAT_ITEMS];
> #endif
> @@ -84,7 +86,9 @@ struct kmem_cache {
> int size; /* The size of an object including meta data
> */
> int object_size;/* The size of an object without meta data */
> int offset; /* Free pointer offset. */
> +#ifdef CONFIG_SLUB_CPU_PARTIAL
> int cpu_partial;/* Number of per cpu partial objects to keep
> around */
> +#endif
> struct kmem_cache_order_objects oo;
>
> /* Allocation and freeing of slabs */
> Index: linux/mm/slub.c
> ===
> --- linux.orig/mm/slub.c2013-03-28 12:18:48.446813991 -0500
> +++ linux/mm/slub.c 2013-03-28 12:19:46.275866639 -0500
> @@ -1531,7 +1531,9 @@ static inline void *acquire_slab(struct
> return freelist;
> }
>
> +#ifdef CONFIG_SLUB_CPU_PARTIAL
> static int put_cpu_partial(struct kmem_cache *s, struct page *page, int
> drain);
> +#endif
> static inline bool pfmemalloc_match(struct page *page, gfp_t gfpflags);
>
> /*
> @@ -1570,10 +1572,20 @@ static void *get_partial_node(struct kme
> object = t;
> available = page->objects - (unsigned
> long)page->lru.next;
> } else {
> +#ifdef CONFIG_SLUB_CPU_PARTIAL
> available = put_cpu_partial(s, page, 0);
> stat(s, CPU_PARTIAL_NODE);
> +#else
> + BUG();
> +#endif
> }
> - if (kmem_cache_debug(s) || available > s->cpu_partial / 2)
> + if (kmem_cache_debug(s) ||
> +#ifdef CONFIG_SLUB_CPU_PARTIAL
> + available > s->cpu_partial / 2
> +#else
> + available > 0
> +#endif
> + )
> break;
>
> }
> @@ -1874,6 +1886,7 @@ redo:
> }
> }
>
> +#ifdef CONFIG_SLUB_CPU_PARTIAL
> /*
> * Unfreeze all the cpu partial slabs.
> *
> @@ -1989,6 +2002,7 @@ static int put_cpu_partial(struct kmem_c
> } while (this_cpu_cmpxchg(s->cpu_slab->partial, oldpage, page) !=
> oldpage);
> return pobjects;
> }
> +#endif
>
> static inline void flush_slab(struct kmem_cache *s, struct kmem_cache_cpu *c)
> {
> @@ -2013,7 +2027,9 @@ static inline void __flush_cpu_slab(stru
> if (c->page)
> flush_slab(s, c);
>
> +#ifdef CONFIG_SLUB_CPU_PARTIAL
> unfreeze_partials(s, c);
> +#endif
> }
> }
>
> @@ -2029,7 +2045,11 @@ static bool has_cpu_slab(int cpu, void *
> struct kmem_cache *s = info;
> struct kmem_cache_cpu *c = per_cpu_ptr(s->cpu_slab, cpu);
>
> +#ifdef CONFIG_SLUB_CPU_PARTIAL
> return c->page || c->partial;
> +#else
> + return c->page;
> +#endif
> }
>
> static void flush_all(struct kmem_cache *s)
> @@ -2225,7 +2245,10 @@ static void *__slab_alloc(struct kmem_ca
> page = c->page;
> if (!page)
> goto new_slab;
> +
> +#ifdef CONFIG_SLUB_CPU_PARTIAL
> redo:
> +#endif
>
> if (unlikely(!node_match(page, node))) {
> stat(s, ALLOC_NODE_MISMATCH);
> @@ -2278,6 +2301,7 @@ load_freelist:
>
> new_slab:
>
> +#ifdef CONFIG_SLUB_CPU_PARTIAL
> if (c->partial) {
> page = c->page = c->partial;
> c->partial = page->next;
> @@ -2285,6 +2309,7 @@ new_slab:
> c->freelist = NULL;
> goto redo;
> }
> +#endif
>
> freelist =
Re: [PATCH v2 -mm -next] ipc,sem: fix lockdep false positive
On Thu, Mar 28, 2013 at 1:23 PM, Rik van Riel wrote:
> Subject: [PATCH -mm -next] ipc,sem: change locking scheme to make lockdep
> happy
>
> Unfortunately the locking scheme originally proposed has false positives
> with lockdep. This can be fixed by changing the code to only ever take
> one lock, and making sure that other relevant locks are not locked, before
> entering a critical section.
>
> For the "global lock" case, this is done by taking the sem_array lock,
> and then (potentially) waiting for all the semaphore's spinlocks to be
> unlocked.
>
> For the "local lock" case, we wait on the sem_array's lock to be free,
> before taking the semaphore local lock. To prevent races, we need to
> check again after we have taken the local lock.
>
> Suggested-by: Peter Zijlstra
> Reported-by: Sasha Levin
> Signed-off-by: Rik van Riel
TL;DR: The locking algorithm is not familiar for me, but it seems
sound. There are some implementation details I don't like. More
below...
> ---
> ipc/sem.c | 55 ---
> 1 files changed, 40 insertions(+), 15 deletions(-)
>
> diff --git a/ipc/sem.c b/ipc/sem.c
> index 36500a6..87b74d5 100644
> --- a/ipc/sem.c
> +++ b/ipc/sem.c
> @@ -320,24 +320,39 @@ void __init sem_init (void)
> }
>
> /*
> - * If the sem_array contains just one semaphore, or if multiple
> - * semops are performed in one syscall, or if there are complex
> - * operations pending, the whole sem_array is locked.
> - * If one semop is performed on an array with multiple semaphores,
> - * get a shared lock on the array, and lock the individual semaphore.
> + * If the request contains only one semaphore operation, and there are
> + * no complex transactions pending, lock only the semaphore involved.
> + * Otherwise, lock the entire semaphore array, since we either have
> + * multiple semaphores in our own semops, or we need to look at
> + * semaphores from other pending complex operations.
> *
> * Carefully guard against sma->complex_count changing between zero
> * and non-zero while we are spinning for the lock. The value of
> * sma->complex_count cannot change while we are holding the lock,
> * so sem_unlock should be fine.
> + *
> + * The global lock path checks that all the local locks have been released,
> + * checking each local lock once. This means that the local lock paths
> + * cannot start their critical sections while the global lock is held.
> */
> static inline int sem_lock(struct sem_array *sma, struct sembuf *sops,
> int nsops)
> {
> int locknum;
> + again:
> if (nsops == 1 && !sma->complex_count) {
> struct sem *sem = sma->sem_base + sops->sem_num;
>
> + /*
> +* Another process is holding the global lock on the
> +* sem_array. Wait for that process to release the lock,
> +* before acquiring our lock.
> +*/
> + if (unlikely(spin_is_locked(&sma->sem_perm.lock))) {
> + spin_unlock_wait(&sma->sem_perm.lock);
> + goto again;
> + }
> +
So, there are a few things I don't like about spin_unlock_wait():
1- From a lock ordering point of view, it is strictly equivalent to
taking the lock and then releasing it - and yet, lockdep won't catch
any deadlocks that involve spin_unlock_wait. (Not your fault here,
this should be fixed as a separate change in lockdep. I manually
looked at the lock ordering here and found it safe).
2- With the current ticket lock implementation, a stream of lockers
can starve spin_unlock_wait() forever. Once again, not your fault and
I suspect this could be fixed - I expect spin_unlock_wait() callers
actually only want to know that the lock has been passed on, not that
it actually got to an unlocked state.
3- Regarding your actual use here - I find it confusing to call
spin_unlock_wait() before holding any other lock. The pattern I expect
to see is that people take one lock, then see that the other lock they
want is already taken, so they release the first lock and wait on the
second. So, I'd suggest we remove the sem_perm.lock checks here and
deal with this in a retry path later down.
> /* Lock just the semaphore we are interested in. */
> spin_lock(&sem->lock);
>
> @@ -347,17 +362,33 @@ static inline int sem_lock(struct sem_array *sma,
> struct sembuf *sops,
> */
> if (unlikely(sma->complex_count)) {
> spin_unlock(&sem->lock);
> - goto lock_all;
> + goto lock_array;
> + }
> +
> + /*
> +* Another process is holding the global lock on the
> +* sem_array; we cannot enter our critical section,
> +* but have to wait for the global lock to be released.
> +*/
> + if (unlike
Re: [PATCH V2 0/2] cpufreq: ondemand: add AMD specific powersave bias
On 28 March 2013 23:54, Jacob Shin wrote: > This patchset adds AMD specific powersave bias function to the ondemand > governor; which can be used to help ondemand governor make more power > conscious > frequency change decisions based on feedback from hardware (availble on AMD > Family 16h and above). > > Hardware feedback tells software how "sensitive" to frequency changes the > workloads are. CPU-bound workloads will be more sensitive -- they will > perform better as frequency increases. Memory/IO-bound workloads will be less > sensitive -- they will not necessarily perform better as frequnecy increases. > > This patchset was compared against ondemand governor without powersave bias > and did not show any performance degradation on CPU-bound workloads such as > kernbench and unixbench. While saving power on Memory-bound workloads such as > stream. > > This applies to linux-pm's linux-next branch, on top of Viresh's 'Implement > per policy instance of governor' V4 patchset: > > https://lkml.org/lkml/2013/3/27/348 > > V2: > * Added proper include files to amd_freq_sensitivity.c > * Only register powersave_bias_target function pointer and not the entire > od_ops. > > Jacob Shin (2): > cpufreq: ondemand: allow custom powersave_bias_target function to be > registered > cpufreq: AMD "frequency sensitivity feedback" powersave bias for > ondemand governor > > arch/x86/include/uapi/asm/msr-index.h |1 + > drivers/cpufreq/Kconfig.x86| 10 +++ > drivers/cpufreq/Makefile |1 + > drivers/cpufreq/amd_freq_sensitivity.c | 147 > > drivers/cpufreq/cpufreq_governor.h |3 + > drivers/cpufreq/cpufreq_ondemand.c | 22 - > 6 files changed, 181 insertions(+), 3 deletions(-) > create mode 100644 drivers/cpufreq/amd_freq_sensitivity.c Acked-by: Viresh Kumar -- 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 3/7] workqueue: Add helpers to schedule work on any cpu
On 28 March 2013 23:43, Tejun Heo wrote: > Ping. Peter, Ingo? Thanks for your ping, even i was thinking of it since sometime :) > Viresh, would it be difficult to make another measurement of the same > workload with the said workqueues converted to unbound? I think that > would at least provide a nice reference point. I will try. -- 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: For review (v2): user_namespaces(7) man page
Over the last little while I have been working to correct a design oversight in user namespaces, that probably needs to be documented somewhere, and the fixes for the worst of the oversight have been merged. The problem was I forgot to consider what when there are shared resources and root uses things like chroot and mounts as access policy controls, and not as a mechanism to prevent the gaining of privilege. This has led to the realization that the root directory is one of the privileged identifiers that is controlled by the user namespace. So now there is a restriction that user namespaces can not be created if you are chrooted. Beyond that there are restrictions on what you can do in a mount namespace created inside a user namespace. Read-only bind mounts may not be remounted to read-write. The mqueue filesystem may only be mounted if you have CAP_SYS_ADMIN over it's ipc namespace. proc and sysfs may only be mounted if they are already somewhere in the mount namespace. There is a remaining open question on what to allow in the context of unmounting and bind mounts. In the normal case unmounting something is safe because mounts almost always happen on an empty directory. The only significant case that I can think of where this is different are union mounts and union filesystems. However the general principle of following the restrictions of the root user makes suggests that unmounts should not happen. In the grand scheme of things these are small little things but they are details we need to get right so that enabling user namespaces is no worse that adding any other feature to the kernel. In the worst case just adding more attack surface for the bad guys, but not a matter of risk semantically. Eric -- 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: r8169 auto speed down issue
Francois Romieu [mailto:rom...@fr.zoreil.com] [...] > Your description suggests that testing against the link > partner ability > to work at 10M instead of testing for tp->link_ok could be > good enough. > > Does it make sense ? > Furthermore, should it not speed down without linking, even though the cable would be plugged after suspending or shutdowning? Best Regards, Hayes -- 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] nohz: Print final full dynticks CPUs range on boot
[Re: [PATCH 2/4] nohz: Print final full dynticks CPUs range on boot] On
28/03/2013 (Thu 19:00) Paul E. McKenney wrote:
> On Fri, Mar 29, 2013 at 01:39:04AM +0100, Frederic Weisbecker wrote:
> > 2013/3/29 Paul Gortmaker :
> > > [Re: [PATCH 2/4] nohz: Print final full dynticks CPUs range on boot] On
> > > 28/03/2013 (Thu 08:40) Ingo Molnar wrote:
> > >
> > >>
> > >> * Frederic Weisbecker wrote:
> > >>
> > >> > + cpulist_scnprintf(nohz_ext_buf, sizeof(nohz_ext_buf),
> > >> > nohz_extended_mask);
> > >> > + pr_info("NO_HZ: Experimental full dynticks CPUs: %s.\n",
> > >> > nohz_ext_buf);
> > >>
> > >> I'd suggest removing the 'experimental' word. We are not sending anything
> > >> experimental to Linus: we'll send something that is tested and that we
> > >> expect to not break anything. (and which we'll fix if it does)
> > >
> > > In that case, should we vector a patch through PaulM to clobber these too?
> > >
> > > $ git grep xperiment |grep rcu
> > > kernel/rcutree_plugin.h: printk(KERN_INFO "\tExperimental boot-time
> > > adjustment of leaf fanout to %d.\n", rcu_fanout_leaf);
>
> This one has been this way for quite some time. I must confess that I am
> more inclined to remove this Kconfig option entirely than I am to remove
> the "Experimental". ;-)
>
> > > kernel/rcutree_plugin.h: pr_info("\tExperimental no-CBs CPUs: %s.\n",
> > > nocb_buf);
> > > kernel/rcutree_plugin.h: pr_info("\tExperimental polled no-CBs CPUs.\n");
> >
> > Hehe, that's indeed what I inspired from ;-)
>
> I guess we can rerun the earlier "how to mark Kconfig options as not
> yet being ready for 100 million unsuspecting victims^Wusers. ;-)
Perhaps consider "hiding" these kinds of choices behind CONFIG_EXPERT ?
P.
--
>
> Then again, I do have the warning at the bottom of the help info,
> so might be OK removing the "Experimental".
>
> Thanx, Paul
>
--
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] nohz: Print final full dynticks CPUs range on boot
[Re: [PATCH 2/4] nohz: Print final full dynticks CPUs range on boot] On
29/03/2013 (Fri 01:39) Frederic Weisbecker wrote:
> 2013/3/29 Paul Gortmaker :
> > [Re: [PATCH 2/4] nohz: Print final full dynticks CPUs range on boot] On
> > 28/03/2013 (Thu 08:40) Ingo Molnar wrote:
> >
> >>
> >> * Frederic Weisbecker wrote:
> >>
> >> > + cpulist_scnprintf(nohz_ext_buf, sizeof(nohz_ext_buf),
> >> > nohz_extended_mask);
> >> > + pr_info("NO_HZ: Experimental full dynticks CPUs: %s.\n",
> >> > nohz_ext_buf);
> >>
> >> I'd suggest removing the 'experimental' word. We are not sending anything
> >> experimental to Linus: we'll send something that is tested and that we
> >> expect to not break anything. (and which we'll fix if it does)
> >
> > In that case, should we vector a patch through PaulM to clobber these too?
> >
> > $ git grep xperiment |grep rcu
> > kernel/rcutree_plugin.h: printk(KERN_INFO "\tExperimental boot-time
> > adjustment of leaf fanout to %d.\n", rcu_fanout_leaf);
> > kernel/rcutree_plugin.h: pr_info("\tExperimental no-CBs CPUs: %s.\n",
> > nocb_buf);
> > kernel/rcutree_plugin.h: pr_info("\tExperimental polled no-CBs CPUs.\n");
>
> Hehe, that's indeed what I inspired from ;-)
I was guessing exactly that, which is why I mentioned it. :)
P.
--
--
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] nohz: Print final full dynticks CPUs range on boot
On Fri, Mar 29, 2013 at 01:39:04AM +0100, Frederic Weisbecker wrote:
> 2013/3/29 Paul Gortmaker :
> > [Re: [PATCH 2/4] nohz: Print final full dynticks CPUs range on boot] On
> > 28/03/2013 (Thu 08:40) Ingo Molnar wrote:
> >
> >>
> >> * Frederic Weisbecker wrote:
> >>
> >> > + cpulist_scnprintf(nohz_ext_buf, sizeof(nohz_ext_buf),
> >> > nohz_extended_mask);
> >> > + pr_info("NO_HZ: Experimental full dynticks CPUs: %s.\n",
> >> > nohz_ext_buf);
> >>
> >> I'd suggest removing the 'experimental' word. We are not sending anything
> >> experimental to Linus: we'll send something that is tested and that we
> >> expect to not break anything. (and which we'll fix if it does)
> >
> > In that case, should we vector a patch through PaulM to clobber these too?
> >
> > $ git grep xperiment |grep rcu
> > kernel/rcutree_plugin.h: printk(KERN_INFO "\tExperimental boot-time
> > adjustment of leaf fanout to %d.\n", rcu_fanout_leaf);
This one has been this way for quite some time. I must confess that I am
more inclined to remove this Kconfig option entirely than I am to remove
the "Experimental". ;-)
> > kernel/rcutree_plugin.h: pr_info("\tExperimental no-CBs CPUs: %s.\n",
> > nocb_buf);
> > kernel/rcutree_plugin.h: pr_info("\tExperimental polled no-CBs CPUs.\n");
>
> Hehe, that's indeed what I inspired from ;-)
I guess we can rerun the earlier "how to mark Kconfig options as not
yet being ready for 100 million unsuspecting victims^Wusers. ;-)
Then again, I do have the warning at the bottom of the help info,
so might be OK removing the "Experimental".
Thanx, Paul
--
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 3.6.11.1
I'm announcing the release of the 3.6.11.1 kernel. The updated 3.6.11.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git v3.6-stable The patch can be downloaded at: https://www.kernel.org/pub/linux/kernel/projects/rt/3.6/stable/patch-3.6.11.1.xz thanks, -- Steve MAINTAINERS|6 +- Makefile |2 +- arch/sparc/Kconfig |1 + arch/sparc/include/asm/hugetlb.h | 10 +- arch/sparc/mm/tsb.c|2 +- drivers/atm/iphase.h | 146 ++-- drivers/block/sunvdc.c |2 +- drivers/isdn/gigaset/capi.c|2 + drivers/net/ethernet/broadcom/tg3.c| 62 ++--- drivers/net/ethernet/calxeda/xgmac.c |4 + drivers/net/ethernet/mellanox/mlx4/en_netdev.c |2 +- drivers/net/ethernet/mellanox/mlx4/en_tx.c | 13 +- drivers/net/ethernet/mellanox/mlx4/main.c | 11 +- .../net/ethernet/qlogic/netxen/netxen_nic_init.c |2 +- .../net/ethernet/qlogic/netxen/netxen_nic_main.c |2 + drivers/net/ethernet/realtek/r8169.c |7 - drivers/net/ethernet/via/via-rhine.c |8 +- drivers/net/loopback.c |5 + drivers/net/macvlan.c |6 +- drivers/net/ppp/ppp_generic.c |8 ++ drivers/net/team/team.c|2 + drivers/net/tun.c |2 + drivers/net/xen-netback/common.h |3 + drivers/net/xen-netback/interface.c| 26 ++-- drivers/net/xen-netback/netback.c | 123 ++--- fs/splice.c|4 +- include/linux/if_vlan.h|6 +- include/net/dst.h |8 +- include/net/icmp.h |1 + include/net/inet6_hashtables.h |8 +- include/net/inet_connection_sock.h |1 + include/net/inet_sock.h|1 + include/net/ip.h |2 + include/net/ip6_fib.h | 39 ++ include/net/ipv6.h | 12 ++ include/net/ndisc.h|7 + include/net/sock.h |2 +- net/batman-adv/bat_iv_ogm.c|2 +- net/bridge/br_netfilter.c |3 + net/bridge/br_stp_bpdu.c |2 + net/core/datagram.c|2 +- net/core/dev.c |1 + net/core/dst.c |1 + net/core/pktgen.c |9 +- net/core/rtnetlink.c |1 + net/core/skbuff.c | 44 ++ net/core/sock_diag.c |3 + net/dcb/dcbnl.c|8 ++ net/dccp/ipv4.c|4 +- net/dccp/ipv6.c|3 +- net/ieee802154/6lowpan.h |2 +- net/ipv4/af_inet.c | 11 +- net/ipv4/datagram.c| 25 net/ipv4/icmp.c| 23 +++ net/ipv4/inet_connection_sock.c| 16 +++ net/ipv4/ip_gre.c |6 +- net/ipv4/ip_sockglue.c |2 +- net/ipv4/ping.c|5 +- net/ipv4/raw.c |1 + net/ipv4/route.c | 54 +++- net/ipv4/tcp.c | 27 ++-- net/ipv4/tcp_cong.c| 14 +- net/ipv4/tcp_input.c | 72 ++ net/ipv4/tcp_ipv4.c| 15 +- net/ipv4/tcp_output.c | 18 ++- net/ipv4/udp.c |1 + net/ipv6/addrconf.c|2 +- net/ipv6/icmp.c| 12 ++ net/ipv6/ip6_input.c |3 +- net/ipv6/ip6_output.c |4 +- net/ipv6/ndisc.c | 17 +++ net/ipv6/route.c | 13 +- net/ipv6/tcp_ipv6.c|3 +- net/ipv6/xfrm6_policy.c|2 + net/l2tp/l2tp_ppp.c
[PATCH v2] pnp: restore automatic resolution of DMA conflicts
From: David Flater
To fix a 5-year-old regression, reverse the changes made in the
following commit:
commit 7ef36390fabe2168fe31f245e49eb4e5f3762622
Author: Jan Beulich
Date: Tue Oct 16 23:31:07 2007 -0700
PNP: don't fail device init if no DMA channel available
Most drivers for devices supporting ISA DMA can operate without
DMA as well (falling back zo PIO). Thus it seems inappropriate
for PNP to fail device initialization in case none of the possible
DMA channels are available. Instead, it should be left to the
driver to decide what to do if request_dma() fails.
The patch at once adjusts the code to account for the fact that
pnp_assign_dma() now doesn't need to report failure anymore.
As an example to show the problem, my sound card provides a
prioritized list of PnP "dependent sets" of requested resources:
dependent set 0 (preferred) wants DMA 5.
dependent set 1 (acceptable) will take DMA 5, 6, or 7.
...
dependent set 4 (acceptable) doesn't request a high DMA.
If DMA 5 is not available, pnp_assign_dma has to fail on set 0 so that
pnp_auto_config_dev will move on to set 1 and get DMA 6 or 7.
Instead, pnp_assign_dma adds the resource with flags |=
IORESOURCE_DISABLED and returns success. pnp_auto_config_dev just
sees success and therefore chooses set 0 with a disabled DMA and never
tries the sets that would have resolved the conflict.
Furthermore, this mode of "success" is unexpected and unhandled in
sound/isa/sb and probably other drivers. sb assumes that the returned
DMA is enabled and obliviously uses the invalid DMA number. Observed
consequences were sb successfully grabbing a DMA that was expressly
forbidden by the kernel parameter pnp_reserve_dma.
The only upside to the original change would be as a kludge for
devices that can operate in degraded mode without a DMA but that don't
provide the corresponding non-preferred dependent set. The right
workaround for those devices is to synthesize the missing set in
quirks.c; otherwise, you're reinventing PnP fallback functionality at
the driver level for that device and all others.
Signed-off-by: David Flater
---
v2: missed a spot (add back handling of empty map as really disabled).
Note that address abe...@mit.edu from MAINTAINERS is bouncing.
drivers/pnp/manager.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/pnp/manager.c b/drivers/pnp/manager.c
index 95cebf0..9357aa7 100644
--- a/drivers/pnp/manager.c
+++ b/drivers/pnp/manager.c
@@ -211,6 +211,12 @@ static int pnp_assign_dma(struct pnp_dev *dev, struct
pnp_dma *rule, int idx)
res->start = -1;
res->end = -1;
+ if (!rule->map) {
+ res->flags |= IORESOURCE_DISABLED;
+ pnp_dbg(&dev->dev, " dma %d disabled\n", idx);
+ goto __add;
+ }
+
for (i = 0; i < 8; i++) {
if (rule->map & (1 << xtab[i])) {
res->start = res->end = xtab[i];
@@ -218,11 +224,9 @@ static int pnp_assign_dma(struct pnp_dev *dev, struct
pnp_dma *rule, int idx)
goto __add;
}
}
-#ifdef MAX_DMA_CHANNELS
- res->start = res->end = MAX_DMA_CHANNELS;
-#endif
- res->flags |= IORESOURCE_DISABLED;
- pnp_dbg(&dev->dev, " disable dma %d\n", idx);
+
+ pnp_dbg(&dev->dev, " couldn't assign dma %d\n", idx);
+ return -EBUSY;
__add:
pnp_add_dma_resource(dev, res->start, res->flags);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] ia64: Fix example error_injection_tool
I got a "sched_setaffinity:: Invalid argument" error when using err_injection_tool to inject error on a system with over 32 cpus. Error information when injecting an error on a system with over 32 cpus: $ ./err_injection_tool -i /sys/devices/system/cpu/cpu0/err_inject//err_type_info Begine at Tue Mar 26 11:20:08 2013 Configurations: On cpu32: loop=10, interval=5(s) err_type_info=4101,err_struct_info=95 Error sched_setaffinity:: Invalid argument All done This because there is overflow when calculating the cpumask: the type of (1< 31, (1< Signed-off-by: Xie XiuQi --- Documentation/ia64/err_inject.txt |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/ia64/err_inject.txt b/Documentation/ia64/err_inject.txt index 223e4f0..9f651c1 100644 --- a/Documentation/ia64/err_inject.txt +++ b/Documentation/ia64/err_inject.txt @@ -882,7 +882,7 @@ int err_inj() cpu=parameters[i].cpu; k = cpu%64; j = cpu/64; - mask[j]=1
[PATCH RESEND] fbmon: use VESA_DMT_VSYNC_HIGH to fix typo
VESA_DMT_VSYNC_HIGH should be used instead of VESA_DMT_HSYNC_HIGH,
because FB_SYNC_VERT_HIGH_ACT is related to vsync, not to hsync.
Signed-off-by: Jingoo Han
Cc: Steffen Trumtrar
Cc: Tomi Valkeinen
---
drivers/video/fbmon.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index 94ad0f7..7f67099 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -1400,7 +1400,7 @@ int fb_videomode_from_videomode(const struct videomode
*vm,
fbmode->vmode = 0;
if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
- if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
+ if (vm->dmt_flags & VESA_DMT_VSYNC_HIGH)
fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
if (vm->data_flags & DISPLAY_FLAGS_INTERLACED)
fbmode->vmode |= FB_VMODE_INTERLACED;
--
1.7.2.5
N떑꿩�r툤y鉉싕b쾊Ф푤v�^�)頻{.n�+돴쪐{콗喩zX㎍썳變}찠꼿쟺�&j:+v돣�쳭喩zZ+�+zf＂톒쉱�~넮녬i鎬z� 췿ⅱ�?솳鈺�&�)刪f뷌^j푹y쬶끷@A첺뛴
0띠h��뭝
Re: [PATCH] ia64: Fix example error_injection_tool
On 2013/3/29 0:47, Luck, Tony wrote: > Nice catch. > > - mask[j]=1< + mask[j] = (unsigned long)1< > Could use > mask[j] = 1ul << k; > to avoid the verbose cast. Thank you for your suggestion, Tony. I'll modify it in next version. > > -Tony > > -- 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] ARM: dove: fix Dove cpu type from V7 to PJ4
On Thu, Mar 28, 2013 at 09:04:12PM +, Russell King - ARM Linux wrote: ... > From what I could see, there's not much point to pj4-cp0.c without > iwmmxt.S also being built. So, what I'd suggest is this, which will > ensure IWMMXT is enabled when PJ4 is set, otherwise giving people the > choice as it used to be. > Russell, Are you going to take these two patches? I don't want to assume and have them potentially get lost. thx, Jason. > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 67874b8..ef6733a 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1171,9 +1171,9 @@ config ARM_NR_BANKS > default 8 > > config IWMMXT > - bool "Enable iWMMXt support" > + bool "Enable iWMMXt support" if !CPU_PJ4 > depends on CPU_XSCALE || CPU_XSC3 || CPU_MOHAWK || CPU_PJ4 > - default y if PXA27x || PXA3xx || ARCH_MMP > + default y if PXA27x || PXA3xx || ARCH_MMP || CPU_PJ4 > help > Enable support for iWMMXt context switching at run time if > running on a CPU that supports it. > -- 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] include/linux: printk is needed in filter.h when CONFIG_BPF_JIT is defined
On 2013年03月29日 02:31, David Miller wrote: > Please post networking patches to net...@vger.kernel.org, thanks. ok, thanks. it is my fault. originally, I get mail addresses by ./scripts/get_maintainers.pl it is a useful tool for members to get mail addresses. I should fully use it, but should not depend on it. next time I should think of the mail addresses, after get them from the tool. thanks. -- Chen Gang Flying Transformer -- 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] mm: remove swapcache page early
On Thu, Mar 28, 2013 at 11:19:12AM -0700, Dan Magenheimer wrote:
> > From: Minchan Kim [mailto:minc...@kernel.org]
> > Subject: Re: [RFC] mm: remove swapcache page early
> >
> > Hi Dan,
> >
> > On Wed, Mar 27, 2013 at 03:24:00PM -0700, Dan Magenheimer wrote:
> > > > From: Hugh Dickins [mailto:hu...@google.com]
> > > > Subject: Re: [RFC] mm: remove swapcache page early
> > > >
> > > > I believe the answer is for frontswap/zmem to invalidate the frontswap
> > > > copy of the page (to free up the compressed memory when possible) and
> > > > SetPageDirty on the PageUptodate PageSwapCache page when swapping in
> > > > (setting page dirty so nothing will later go to read it from the
> > > > unfreed location on backing swap disk, which was never written).
> > >
> > > There are two duplication issues: (1) When can the page be removed
> > > from the swap cache after a call to frontswap_store; and (2) When
> > > can the page be removed from the frontswap storage after it
> > > has been brought back into memory via frontswap_load.
> > >
> > > This patch from Minchan addresses (1). The issue you are raising
> >
> > No. I am addressing (2).
> >
> > > here is (2). You may not know that (2) has recently been solved
> > > in frontswap, at least for zcache. See frontswap_exclusive_gets_enabled.
> > > If this is enabled (and it is for zcache but not yet for zswap),
> > > what you suggest (SetPageDirty) is what happens.
> >
> > I am blind on zcache so I didn't see it. Anyway, I'd like to address it
> > on zram and zswap.
>
> Zswap can enable it trivially by adding a function call in init_zswap.
> (Note that it is not enabled by default for all frontswap backends
> because it is another complicated tradeoff of cpu time vs memory space
> that needs more study on a broad set of workloads.)
>
> I wonder if something like this would have a similar result for zram?
> (Completely untested... snippet stolen from swap_entry_free with
> SetPageDirty added... doesn't compile yet, but should give you the idea.)
Nice idea!
After I see your patch, I realized it was Hugh's suggestion and
you implemented it in proper place.
Will resend it after testing. Maybe nextweek.
Thanks!
>
> diff --git a/mm/page_io.c b/mm/page_io.c
> index 56276fe..2d10988 100644
> --- a/mm/page_io.c
> +++ b/mm/page_io.c
> @@ -81,7 +81,17 @@ void end_swap_bio_read(struct bio *bio, int err)
> iminor(bio->bi_bdev->bd_inode),
> (unsigned long long)bio->bi_sector);
> } else {
> + struct swap_info_struct *sis;
> +
> SetPageUptodate(page);
> + sis = page_swap_info(page);
> + if (sis->flags & SWP_BLKDEV) {
> + struct gendisk *disk = sis->bdev->bd_disk;
> + if (disk->fops->swap_slot_free_notify) {
> + SetPageDirty(page);
> + disk->fops->swap_slot_free_notify(sis->bdev,
> + offset);
> + }
> + }
> }
> unlock_page(page);
> bio_put(bio);
>
> --
> 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 -mm -next] ipc,sem: untangle RCU locking with find_alloc_undo
On 03/28/2013 09:00 PM, Michel Lespinasse wrote: > On Thu, Mar 28, 2013 at 8:32 AM, Rik van Riel wrote: >> The ipc semaphore code has a nasty RCU locking tangle, with both >> find_alloc_undo and semtimedop taking the rcu_read_lock(). The >> code can be cleaned up somewhat by only taking the rcu_read_lock >> once. >> >> The only caller of find_alloc_undo is in semtimedop. >> >> This should solve the trinity issue reported by Sasha Levin. >> >> Reported-by: Sasha Levin >> Signed-off-by: Rik van Riel > > Looks good^Wbetter. I have nothing specific to say other than I've > been staring at it for 10 minutes :) > > Reviewed-by: Michel Lespinasse And the warnings are gone: Tested-by: Sasha Levin Thanks, Sasha -- 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] tracepoints: prevents null probe from being added
On Thu, Mar 21, 2013 at 2:34 PM, wrote:
> From: Sahara
>
> Somehow tracepoint_entry_add_probe function allows a null probe function.
> And, this may lead to unexpected result since the number of probe
> functions in an entry can be counted by checking whether probe is null
> or not in for-loop.
> This patch prevents the null probe from being added.
> In tracepoint_entry_remove_probe function, checking probe parameter
> within for-loop is moved out for code efficiency leaving the null probe
> feature which removes all probe functions in the entry.
>
> Signed-off-by: Sahara
> Reviewed-by: Steven Rostedt
> Reviewed-by: Mathieu Desnoyers
> ---
> kernel/tracepoint.c | 18 ++
> 1 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
> index 0c05a45..7d69348 100644
> --- a/kernel/tracepoint.c
> +++ b/kernel/tracepoint.c
> @@ -112,7 +112,8 @@ tracepoint_entry_add_probe(struct tracepoint_entry *entry,
> int nr_probes = 0;
> struct tracepoint_func *old, *new;
>
> - WARN_ON(!probe);
> + if (WARN_ON(!probe))
> + return ERR_PTR(-EINVAL);
>
> debug_print_probes(entry);
> old = entry->funcs;
> @@ -152,13 +153,15 @@ tracepoint_entry_remove_probe(struct tracepoint_entry
> *entry,
>
> debug_print_probes(entry);
> /* (N -> M), (N > 1, M >= 0) probes */
> - for (nr_probes = 0; old[nr_probes].func; nr_probes++) {
> - if (!probe ||
> - (old[nr_probes].func == probe &&
> -old[nr_probes].data == data))
> - nr_del++;
> + if (probe) {
> + for (nr_probes = 0; old[nr_probes].func; nr_probes++) {
> + if (old[nr_probes].func == probe &&
> +old[nr_probes].data == data)
> + nr_del++;
> + }
> }
>
> + /* If probe is NULL, all funcs in the entry will be removed. */
> if (nr_probes - nr_del == 0) {
> /* N -> 0, (N > 1) */
> entry->funcs = NULL;
> @@ -173,8 +176,7 @@ tracepoint_entry_remove_probe(struct tracepoint_entry
> *entry,
> if (new == NULL)
> return ERR_PTR(-ENOMEM);
> for (i = 0; old[i].func; i++)
> - if (probe &&
> - (old[i].func != probe || old[i].data != data))
> + if (old[i].func != probe || old[i].data != data)
> new[j++] = old[i];
> new[nr_probes - nr_del].func = NULL;
> entry->refcount = nr_probes - nr_del;
> --
> 1.7.1
>
Hi Steve,
Please check out this v2 patch. Seemingly I got no response from you.
Thanks.
-- Kpark
--
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 -next] ipc,sem: untangle RCU locking with find_alloc_undo
On Thu, Mar 28, 2013 at 8:32 AM, Rik van Riel wrote: > The ipc semaphore code has a nasty RCU locking tangle, with both > find_alloc_undo and semtimedop taking the rcu_read_lock(). The > code can be cleaned up somewhat by only taking the rcu_read_lock > once. > > The only caller of find_alloc_undo is in semtimedop. > > This should solve the trinity issue reported by Sasha Levin. > > Reported-by: Sasha Levin > Signed-off-by: Rik van Riel Looks good^Wbetter. I have nothing specific to say other than I've been staring at it for 10 minutes :) Reviewed-by: Michel Lespinasse -- 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: smartd broken in 3.9.0-rc4 : bisected
My mistake.
In ata_cmd_ioctl(), we clean the results and remove CHECK_CONDITION
when necessary. I did not update that code for the new Sense Key:
if (cmd_result & SAM_STAT_CHECK_CONDITION) {
struct scsi_sense_hdr sshdr;
scsi_normalize_sense(sensebuf, SCSI_SENSE_BUFFERSIZE,
&sshdr);
if (sshdr.sense_key == 0 &&
sshdr.asc == 0 && sshdr.ascq == 0)
cmd_result &= ~SAM_STAT_CHECK_CONDITION;
}
A patch in progress.
Gwendal.
On Thu, Mar 28, 2013 at 1:59 PM, Ken Moffat wrote:
> On Thu, Mar 28, 2013 at 01:01:48AM +, Ken Moffat wrote:
>
> Adding Cc:s, further details at the end.
>> Hi,
>>
>> just tested my first 3.9 kernel today. During boot, smartd (from
>> smartmontools-6.0) fails to start. Works fine in 3.8.4.
>>
>> In 3.8.4 I get messages like this :
>>
>> Mar 27 22:02:02 ac4tv smartd[3981]: smartd 6.0 2012-10-10 r3643
>> [x86_64-linux-3.8.4] (local build)
>> Mar 27 22:02:02 ac4tv smartd[3981]: Copyright (C) 2002-12, Bruce
>> Allen, Christian Franke, www.smartmontools.org
>> Mar 27 22:02:02 ac4tv smartd[3981]: Opened configuration file
>> /etc/smartd.conf
>> Mar 27 22:02:02 ac4tv smartd[3981]: Configuration file
>> /etc/smartd.conf parsed.
>> Mar 27 22:02:02 ac4tv smartd[3981]: Device: /dev/sda, opened
>> Mar 27 22:02:02 ac4tv smartd[3981]: Device: /dev/sda, WDC
>> WD5000AAKX-001CA0, S/N:WD-WMAYU6818967, WWN:5-0014ee-0ad9caed4,
>> FW:15.01H15, 500 GB
>> Mar 27 22:02:02 ac4tv smartd[3981]: Device: /dev/sda, found in
>> smartd database: Western Digital Caviar Blue Serial ATA
>> Mar 27 22:02:02 ac4tv smartd[3981]: Device: /dev/sda, enabled SMART
>> Automatic Offline Testing.
>> Mar 27 22:02:02 ac4tv smartd[3981]: Device: /dev/sda, is SMART
>> capable. Adding to "monitor" list.
>> Mar 27 22:02:02 ac4tv smartd[3981]: Monitoring 1 ATA and 0 SCSI
>> devices
>>
>> but in 3.9.0-rc4 all I get is
>> Mar 28 00:39:32 ac4tv smartd[2487]: Copyright (C) 2002-12, Bruce
>> Allen, Christian Franke, www.smartmontools.org
>> Mar 28 00:39:32 ac4tv smartd[2487]: Opened configuration file
>> /etc/smartd.conf
>> Mar 28 00:39:32 ac4tv smartd[2487]: Configuration file
>> /etc/smartd.conf parsed.
>> Mar 28 00:39:32 ac4tv smartd[2487]: Device: /dev/sda, opened
>> Mar 28 00:39:32 ac4tv smartd[2487]: Device: /dev/sda, WDC
>> WD5000AAKX-001CA0, S/N:WD-WMAYU6818967, WWN:5-0014ee-0ad9caed4,
>> FW:15.01H15, 500 GB
>> Mar 28 00:39:32 ac4tv smartd[2487]: Device: /dev/sda, found in
>> smartd database: Western Digital Caviar Blue Serial ATA
>> Mar 28 00:39:32 ac4tv smartd[2487]: Device: /dev/sda, could not
>> enable SMART capability
>> Mar 28 00:39:32 ac4tv smartd[2487]: Unable to register ATA device
>> /dev/sda at line 1 of file /etc/smartd.conf
>> Mar 28 00:39:32 ac4tv smartd[2487]: Unable to register device
>> /dev/sda (no Directive -d removable). Exiting.
>>
>> Using strace, in the failing version I get
>> 2643 ioctl(3, HDIO_DRIVE_CMD, 0x7fff53288a60) = -1 EIO (Input/output error)
>>
>> instead of the normal
>> 3981 ioctl(3, HDIO_DRIVE_CMD, 0x7fff04437340) = 0
>> 3981 ioctl(3, HDIO_DRIVE_TASK, 0x7fff04437350) = 0
>> 3981 ioctl(3, HDIO_DRIVE_CMD, 0x7fff04437330) = 0
>> 3981 ioctl(3, HDIO_DRIVE_CMD, 0x7fff04437330) = 0
>> 3981 ioctl(3, HDIO_DRIVE_TASK, 0x7fff04437340) = 0
>>
>> Looks like I'll be bisecting.
>>
>> ken
> Bisection blames :
>
> commit 84a9a8cd9d0aa93c17e5815ab8a9cc4c0a765c63
> Author: Gwendal Grignou
> Date: Fri Jan 18 10:56:43 2013 -0800
>
> [libata] Set proper SK when CK_COND is set.
>
> When the user application sends a ATA_12 or ATA_16 PASSTHROUGH
> scsi command, put the task file register in the sense data with the
> proper Sense Key. Instead of NO SENSE, set RECOVERED, as
> specified in [SAT2]12.2.5 Table 92.
>
> That reverts cleanly from 3.9.0-rc4, and with it reverted smartd
> works again. Obviously that does nothing to fix whatever problem
> this was supposed to fix. I can test any follow-up patches if
> needed.
>
> ken
> --
> das eine Mal als Tragödie, das andere Mal als Farce
--
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][update] Makefile: allow no update .config build
if we pull some commits from other git repo
which bring in a few CONFIG_* options, then
we have to build all again, but we do assure
these options are not interesting for us,
so the long waiting build will be offending.
this change help us to avoid all-build.
Signed-off-by: liguang
---
Makefile |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 54d2b2a..d10e505 100644
--- a/Makefile
+++ b/Makefile
@@ -106,6 +106,12 @@ ifeq ("$(origin W)", "command line")
export KBUILD_ENABLE_EXTRA_GCC_CHECKS := $(W)
endif
+# KBUILD_NCU is set to do not update .config even
+# a few new CONFIG_* options appeared
+ifeq ("$(origin NCU)", "command line")
+ KBUILD_NCU := $(NCU)
+endif
+
# That's our default target when none is given on the command line
PHONY := _all
_all:
@@ -540,8 +546,10 @@ $(KCONFIG_CONFIG) include/config/auto.conf.cmd: ;
# with it and forgot to run make oldconfig.
# if auto.conf.cmd is missing then we are probably in a cleaned tree so
# we execute the config step to be sure to catch updated Kconfig files
+ifneq ($(KBUILD_NCU), 1)
include/config/%.conf: $(KCONFIG_CONFIG) include/config/auto.conf.cmd
$(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
+endif # $(KBUILD_NCU)
else
# external modules needs include/generated/autoconf.h and
include/config/auto.conf
# but do not care if they are up-to-date. Use auto.conf to trigger the test
@@ -1157,6 +1165,7 @@ help:
@echo '2: warnings which occur quite often but may
still be relevant'
@echo '3: more obscure warnings, can most likely be
ignored'
@echo 'Multiple levels can be combined with W=12 or
W=123'
+ @echo ' make NCU=1 [targets] no .config update'
@echo ''
@echo 'Execute "make" or "make all" to build all targets marked with
[*] '
@echo 'For further info see the ./README file'
--
1.7.2.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: Possibility for an external staging tree - bring up quality code
On Thu, Mar 28, 2013 at 3:53 PM, Greg Kroah-Hartman wrote: > On Thu, Mar 28, 2013 at 01:13:23PM -0700, Luis R. Rodriguez wrote: > > > >> This has me thinking if it makes sense to have an external driver tree >> for staging drivers but lead by engineers who already know the rules >> of upstream, they just want to get things done faster. > > That's called a "fork" or "tree" or whatever you want to call it, and > all of us have them, and end up merging stuff to mainline through them > eventually. > > There is no need to "codify" something that we all have been doing for > years. If someone thinks they can "work faster" in their own tree, > great for them, have them do it. I don't see what I need to agree or > disagree with here to keep anyone from doing such a thing. > > Or am I just totally missing something here? OK, yes I think we can work better if we had an external trees for each driver to cherry pick them as they get sanitized, prior to upstream for *some* drivers. Very well. I'll simply let vendors / developers get their 802.11 driver as part of compat-drivers so long as they maintain their poo. Luis -- 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] pnp: restore automatic resolution of DMA conflicts
From: David Flater To fix a 5-year-old regression, reverse the changes made in the following commit: commit 7ef36390fabe2168fe31f245e49eb4e5f3762622 Author: Jan Beulich Date: Tue Oct 16 23:31:07 2007 -0700 PNP: don't fail device init if no DMA channel available Most drivers for devices supporting ISA DMA can operate without DMA as well (falling back zo PIO). Thus it seems inappropriate for PNP to fail device initialization in case none of the possible DMA channels are available. Instead, it should be left to the driver to decide what to do if request_dma() fails. The patch at once adjusts the code to account for the fact that pnp_assign_dma() now doesn't need to report failure anymore. As an example to show the problem, my sound card provides a prioritized list of PnP "dependent sets" of requested resources: dependent set 0 (preferred) wants DMA 5. dependent set 1 (acceptable) will take DMA 5, 6, or 7. ... dependent set 4 (acceptable) doesn't request a high DMA. If DMA 5 is not available, pnp_assign_dma has to fail on set 0 so that pnp_auto_config_dev will move on to set 1 and get DMA 6 or 7. Instead, pnp_assign_dma adds the resource with flags |= IORESOURCE_DISABLED and returns success. pnp_auto_config_dev just sees success and therefore chooses set 0 with a disabled DMA and never tries the sets that would have resolved the conflict. Furthermore, this mode of "success" is unexpected and unhandled in sound/isa/sb and probably other drivers. sb assumes that the returned DMA is enabled and obliviously uses the invalid DMA number. Observed consequences were sb successfully grabbing a DMA that was expressly forbidden by the kernel parameter pnp_reserve_dma. The only upside to the original change would be as a kludge for devices that can operate in degraded mode without a DMA but that don't provide the corresponding non-preferred dependent set. The right workaround for those devices is to synthesize the missing set in quirks.c; otherwise, you're reinventing PnP fallback functionality at the driver level for that device and all others. Signed-off-by: David Flater --- drivers/pnp/manager.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/pnp/manager.c b/drivers/pnp/manager.c index 95cebf0..1c25959 100644 --- a/drivers/pnp/manager.c +++ b/drivers/pnp/manager.c @@ -218,11 +218,9 @@ static int pnp_assign_dma(struct pnp_dev *dev, struct pnp_dma *rule, int idx) goto __add; } } -#ifdef MAX_DMA_CHANNELS - res->start = res->end = MAX_DMA_CHANNELS; -#endif - res->flags |= IORESOURCE_DISABLED; - pnp_dbg(&dev->dev, " disable dma %d\n", idx); + + pnp_dbg(&dev->dev, " couldn't assign dma %d\n", idx); + return -EBUSY; __add: pnp_add_dma_resource(dev, res->start, res->flags); -- 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] Makefile: allow no update .config build
在 2013-03-28四的 10:13 -0700，Randy Dunlap写道：
> On 03/28/13 00:28, liguang wrote:
> > if we pull some commits from other git repo
> > which bring in a few CONFIG_* options, then
> > we have to build all again, but we do assure
> > these options are not interesting for us,
> > so the long waiting build will be offending.
> > this change help us to avoid all-build.
> >
> > Signed-off-by: liguang
> > ---
> > Makefile |9 +
> > 1 files changed, 9 insertions(+), 0 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 54d2b2a..d10e505 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -106,6 +106,12 @@ ifeq ("$(origin W)", "command line")
> >export KBUILD_ENABLE_EXTRA_GCC_CHECKS := $(W)
> > endif
> >
> > +# KBUILD_NCU is set to do not update .config even
> > +# a few new CONFIG_* options appeared
> > +ifeq ("$(origin NCU)", "command line")
> > + KBUILD_NCU := $(NCU)
> > +endif
> > +
> > # That's our default target when none is given on the command line
> > PHONY := _all
> > _all:
> > @@ -540,8 +546,10 @@ $(KCONFIG_CONFIG) include/config/auto.conf.cmd: ;
> > # with it and forgot to run make oldconfig.
> > # if auto.conf.cmd is missing then we are probably in a cleaned tree so
> > # we execute the config step to be sure to catch updated Kconfig files
> > +ifneq ($(KBUILD_NCU), 1)
> > include/config/%.conf: $(KCONFIG_CONFIG) include/config/auto.conf.cmd
> > $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
> > +endif # $(KBUILD_NCU)
> > else
> > # external modules needs include/generated/autoconf.h and
> > include/config/auto.conf
> > # but do not care if they are up-to-date. Use auto.conf to trigger the test
> > @@ -1157,6 +1165,7 @@ help:
> > @echo '2: warnings which occur quite often but may
> > still be relevant'
> > @echo '3: more obscure warnings, can most likely be
> > ignored'
> > @echo 'Multiple levels can be combined with W=12 or
> > W=123'
> > + @echo ' make NCU=1 [targets] no .config udate'
>
> update
OK, I'll update.
Thanks!
>
> > @echo ''
> > @echo 'Execute "make" or "make all" to build all targets marked with
> > [*] '
> > @echo 'For further info see the ./README file'
> >
>
>
--
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] nohz: Print final full dynticks CPUs range on boot
2013/3/29 Paul Gortmaker :
> [Re: [PATCH 2/4] nohz: Print final full dynticks CPUs range on boot] On
> 28/03/2013 (Thu 08:40) Ingo Molnar wrote:
>
>>
>> * Frederic Weisbecker wrote:
>>
>> > + cpulist_scnprintf(nohz_ext_buf, sizeof(nohz_ext_buf),
>> > nohz_extended_mask);
>> > + pr_info("NO_HZ: Experimental full dynticks CPUs: %s.\n", nohz_ext_buf);
>>
>> I'd suggest removing the 'experimental' word. We are not sending anything
>> experimental to Linus: we'll send something that is tested and that we
>> expect to not break anything. (and which we'll fix if it does)
>
> In that case, should we vector a patch through PaulM to clobber these too?
>
> $ git grep xperiment |grep rcu
> kernel/rcutree_plugin.h: printk(KERN_INFO "\tExperimental boot-time
> adjustment of leaf fanout to %d.\n", rcu_fanout_leaf);
> kernel/rcutree_plugin.h: pr_info("\tExperimental no-CBs CPUs: %s.\n",
> nocb_buf);
> kernel/rcutree_plugin.h: pr_info("\tExperimental polled no-CBs CPUs.\n");
Hehe, that's indeed what I inspired from ;-)
--
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] nohz: Print final full dynticks CPUs range on boot
[Re: [PATCH 2/4] nohz: Print final full dynticks CPUs range on boot] On
28/03/2013 (Thu 08:40) Ingo Molnar wrote:
>
> * Frederic Weisbecker wrote:
>
> > + cpulist_scnprintf(nohz_ext_buf, sizeof(nohz_ext_buf),
> > nohz_extended_mask);
> > + pr_info("NO_HZ: Experimental full dynticks CPUs: %s.\n", nohz_ext_buf);
>
> I'd suggest removing the 'experimental' word. We are not sending anything
> experimental to Linus: we'll send something that is tested and that we
> expect to not break anything. (and which we'll fix if it does)
In that case, should we vector a patch through PaulM to clobber these too?
$ git grep xperiment |grep rcu
kernel/rcutree_plugin.h: printk(KERN_INFO "\tExperimental boot-time adjustment
of leaf fanout to %d.\n", rcu_fanout_leaf);
kernel/rcutree_plugin.h: pr_info("\tExperimental no-CBs CPUs: %s.\n", nocb_buf);
kernel/rcutree_plugin.h: pr_info("\tExperimental polled no-CBs CPUs.\n");
Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] xhci: Rename SEGMENT_SIZE and SEGMENT_SHIFT as the former is used in a.out.h
On Thu, Mar 28, 2013 at 10:32:53PM +, David Howells wrote: > Sarah Sharp wrote: > > > I'm a little bit confused about your description for the second one. > > Did you need to change the #defines names because they could conflict > > with other drivers when the xHCI driver is built in? Or is there some > > other point I'm missing? > > Sorry, I should say. I'm trying to clean up the UAPI headers and I noticed > that the xHCI SEGMENT_SIZE macro is named the same as one defined by a.out.h > that cannot be changed as it is seen by userspace. Although it's unlikely > that within the kernel they are unlikely to collide, one cannot be entirely > sure that will stay true as new arches get added (hopefully no one will add > new arches that use a.out format). It seems best that the xHCI one be renamed > if possible. I guess my question is a deeper one: do we need to rename all the xHCI macros to have the XHCI_ prefix, in order to avoid future collision? For example, one of the macros is MAX_HC_PORTS, which could possibly be used by other host drivers in the future. Note that I'm not asking you to do this, just if it needs to be done. Sarah Sharp -- 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] perf: add callgrind conversion tool
Roberto Vitillo [raviti...@lbl.gov] wrote: | The proposed patch adds the convert tool to perf which allows to convert a | perf.data file to a set of callgrind data files which can subsequently be | displayed with kcachegrind. Sounds interesting and useful. My only comment is that 'convert' is a generic term and this is converting to a specific format (i.e callgrind). In theory we could have conversions to other formats in the future ? Any chance it could be called 'perf callgrind' ? Sukadev -- 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/2] extcon: max77693: Fix return value
On 03/28/2013 03:27 PM, Sachin Kamat wrote: > Return the value obtained from the function instead of hardcoding. > Silences the following warnings: > drivers/extcon/extcon-max77693.c:297 max77693_muic_set_path() > info: why not propagate 'ret' from max77693_update_reg() instead of (-11)? > drivers/extcon/extcon-max77693.c:310 max77693_muic_set_path() > info: why not propagate 'ret' from max77693_update_reg() instead of (-11)? > > Signed-off-by: Sachin Kamat > --- > Changes since v1: > Include additional instances. > Compile tested. > --- > drivers/extcon/extcon-max77693.c |8 > 1 files changed, 4 insertions(+), 4 deletions(-) Applied this patchset. Thanks. Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6] i2c: exynos5: add High Speed I2C controller driver
Adds support for High Speed I2C driver found in Exynos5 and
later SoCs from Samsung.
This driver currently supports Auto mode.
Driver only supports Device Tree method.
Note: Added debugfs support for registers view, not tested.
Signed-off-by: Taekgyun Ko
Signed-off-by: Naveen Krishna Chatradhi
---
Changes since v5:
1. fixed the clock_info function pointed out by Yuvaraj
2. Clear pending interrupt register before initializing in probe
3. Implement INIT_COMPLETION call before xfer
.../devicetree/bindings/i2c/i2c-exynos5.txt| 50 ++
drivers/i2c/busses/Kconfig |7 +
drivers/i2c/busses/Makefile|1 +
drivers/i2c/busses/i2c-exynos5.c | 874
4 files changed, 932 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
create mode 100644 drivers/i2c/busses/i2c-exynos5.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
new file mode 100644
index 000..0bc9347
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
@@ -0,0 +1,50 @@
+* Samsung's High Speed I2C controller
+
+The Samsung's High Speed I2C controller is used to interface with I2C devices
+at various speeds ranging from 100khz to 3.4Mhz.
+
+Required properties:
+ - compatible: value should be.
+ (a) "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
+ - reg: physical base address of the controller and length of memory mapped
+region.
+ - interrupts: interrupt number to the cpu.
+
+ - Samsung GPIO variant (deprecated):
+- gpios: The order of the gpios should be the following: .
+ The gpio specifier depends on the gpio controller.
+ - Pinctrl variant (preferred, if available):
+- pinctrl-0: Pin control group to be used for this controller.
+- pinctrl-names: Should contain only one value - "default".
+
+Optional properties:
+ - samsung,hs-mode: Mode of operation, High speed or Fast speed mode. If not
+specified, default value is 0.
+ - samsung,hs-clock-freq: Desired operating frequency in Hz of the bus.
+If not specified, the default value in Hz is 10.
+ - samsung,fs-clock-freq: Desired operarting frequency in Hz of the bus.
+If not specified, the default value in Hz is 10.
+
+Example:
+
+ hsi2c@12ca {
+ compatible = "samsung,exynos5-hsi2c";
+ reg = <0x12ca 0x100>;
+ interrupts = <56>;
+ samsung,fs-clock-freq = <10>;
+ /* Samsung GPIO variant begins here */
+ gpios = <&gpd1 2 0 /* SDA */
+&gpd1 3 0 /* SCL */>;
+ /* Samsung GPIO variant ends here */
+ /* Pinctrl variant begins here */
+ pinctrl-0 = <&i2c4_bus>;
+ pinctrl-names = "default";
+ /* Pinctrl variant ends here */
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ s2mps11_pmic@66 {
+ compatible = "samsung,s2mps11-pmic";
+ reg = <0x66>;
+ };
+ };
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index a3725de..78b4936 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -434,6 +434,13 @@ config I2C_EG20T
ML7213/ML7223/ML7831 is companion chip for Intel Atom E6xx series.
ML7213/ML7223/ML7831 is completely compatible for Intel EG20T PCH.
+config I2C_EXYNOS5
+ tristate "Exynos5 high-speed I2C driver"
+ depends on ARCH_EXYNOS5 && OF
+ help
+ Say Y here to include support for High-speed I2C controller in the
+ Exynos5 based Samsung SoCs.
+
config I2C_GPIO
tristate "GPIO-based bitbanging I2C"
depends on GENERIC_GPIO
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 8f4fc23..b19366c 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -42,6 +42,7 @@ i2c-designware-platform-objs := i2c-designware-platdrv.o
obj-$(CONFIG_I2C_DESIGNWARE_PCI) += i2c-designware-pci.o
i2c-designware-pci-objs := i2c-designware-pcidrv.o
obj-$(CONFIG_I2C_EG20T)+= i2c-eg20t.o
+obj-$(CONFIG_I2C_EXYNOS5) += i2c-exynos5.o
obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
obj-$(CONFIG_I2C_HIGHLANDER) += i2c-highlander.o
obj-$(CONFIG_I2C_IBM_IIC) += i2c-ibm_iic.o
diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
new file mode 100644
index 000..a17848f
--- /dev/null
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -0,0 +1,874 @@
+/**
+ * i2c-exynos5.c - Samsung Exynos5 I2C Controller Driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Soft
[PATCH] Revert "mm: introduce VM_POPULATE flag to better deal with racy userspace programs"
From: Michel Lespinasse
This reverts commit 1869305009857cdeaabe6283bcdc2359c5784543 ("mm:
introduce VM_POPULATE flag to better deal with racy userspace programs").
VM_POPULATE only has any effect when userspace plays racy games with
vmas by trying to unmap and remap memory regions that mmap or mlock
are operating on.
Also, the only effect of VM_POPULATE when userspace plays such games
is that it avoids populating new memory regions that get remapped into
the address range that was being operated on by the original mmap or
mlock calls.
Let's remove VM_POPULATE as there isn't any strong argument to mandate
a new vm_flag.
Signed-off-by: Michel Lespinasse
Signed-off-by: Hugh Dickins
---
Andrew has taken this patch into his tree, but remarked that he is
away from keyboard until the end of next week: though not a serious
matter, I think we had better include this revert in -rc5 than later.
include/linux/mm.h | 1 -
include/linux/mman.h | 4 +---
mm/fremap.c | 12 ++--
mm/mlock.c | 11 +--
mm/mmap.c| 4 +++-
5 files changed, 11 insertions(+), 21 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 7acc9dc73c9f..e19ff30ad0a2 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -87,7 +87,6 @@ extern unsigned int kobjsize(const void *objp);
#define VM_PFNMAP 0x0400 /* Page-ranges managed without "struct
page", just pure PFN */
#define VM_DENYWRITE 0x0800 /* ETXTBSY on write attempts.. */
-#define VM_POPULATE 0x1000
#define VM_LOCKED 0x2000
#define VM_IO 0x4000 /* Memory mapped I/O or similar */
diff --git a/include/linux/mman.h b/include/linux/mman.h
index 61c7a87e5d2b..9aa863da287f 100644
--- a/include/linux/mman.h
+++ b/include/linux/mman.h
@@ -79,8 +79,6 @@ calc_vm_flag_bits(unsigned long flags)
{
return _calc_vm_trans(flags, MAP_GROWSDOWN, VM_GROWSDOWN ) |
_calc_vm_trans(flags, MAP_DENYWRITE, VM_DENYWRITE ) |
- ((flags & MAP_LOCKED) ? (VM_LOCKED | VM_POPULATE) : 0) |
- (((flags & (MAP_POPULATE | MAP_NONBLOCK)) == MAP_POPULATE) ?
- VM_POPULATE : 0);
+ _calc_vm_trans(flags, MAP_LOCKED, VM_LOCKED);
}
#endif /* _LINUX_MMAN_H */
diff --git a/mm/fremap.c b/mm/fremap.c
index 4723ac8d2fc2..87da3590c61e 100644
--- a/mm/fremap.c
+++ b/mm/fremap.c
@@ -204,10 +204,8 @@ get_write_lock:
unsigned long addr;
struct file *file = get_file(vma->vm_file);
- vm_flags = vma->vm_flags;
- if (!(flags & MAP_NONBLOCK))
- vm_flags |= VM_POPULATE;
- addr = mmap_region(file, start, size, vm_flags, pgoff);
+ addr = mmap_region(file, start, size,
+ vma->vm_flags, pgoff);
fput(file);
if (IS_ERR_VALUE(addr)) {
err = addr;
@@ -226,12 +224,6 @@ get_write_lock:
mutex_unlock(&mapping->i_mmap_mutex);
}
- if (!(flags & MAP_NONBLOCK) && !(vma->vm_flags & VM_POPULATE)) {
- if (!has_write_lock)
- goto get_write_lock;
- vma->vm_flags |= VM_POPULATE;
- }
-
if (vma->vm_flags & VM_LOCKED) {
/*
* drop PG_Mlocked flag for over-mapped range
diff --git a/mm/mlock.c b/mm/mlock.c
index 1c5e33fce639..79b7cf7d1bca 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -358,7 +358,7 @@ static int do_mlock(unsigned long start, size_t len, int on)
newflags = vma->vm_flags & ~VM_LOCKED;
if (on)
- newflags |= VM_LOCKED | VM_POPULATE;
+ newflags |= VM_LOCKED;
tmp = vma->vm_end;
if (tmp > end)
@@ -418,8 +418,7 @@ int __mm_populate(unsigned long start, unsigned long len,
int ignore_errors)
* range with the first VMA. Also, skip undesirable VMA types.
*/
nend = min(end, vma->vm_end);
- if ((vma->vm_flags & (VM_IO | VM_PFNMAP | VM_POPULATE)) !=
- VM_POPULATE)
+ if (vma->vm_flags & (VM_IO | VM_PFNMAP))
continue;
if (nstart < vma->vm_start)
nstart = vma->vm_start;
@@ -492,9 +491,9 @@ static int do_mlockall(int flags)
struct vm_area_struct * vma, * prev = NULL;
if (flags & MCL_FUTURE)
- current->mm->def_flags |= VM_LOCKED | VM_POPULATE;
+ current->mm->def_flags |= VM_LOCKED;
else
- current->mm->def_flags &= ~(VM_LOCKED | VM_POPULATE);
+ current->mm->def_flags &= ~VM_LOCKED;
if (flags == MCL_FUTURE)
goto out;
@@ -503,7 +502,7
Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch
On Thu, Mar 28, 2013 at 3:29 PM, Julia Lawall wrote: > On Thu, 28 Mar 2013, Luis R. Rodriguez wrote: > >> On Thu, Mar 28, 2013 at 11:10 AM, Julia Lawall wrote: >> > On Thu, 28 Mar 2013, Luis R. Rodriguez wrote: >> >> >> >> Thanks Julia! I'll be sure to try to add this to compat-drivers if the >> >> upstream fb patch is not accepted. If it is accepted we would not need >> >> this at all! >> >> >> >> > Then I guess there would be a similar rule for the false case? >> >> >> >> Nope, see that's the proactive strategy taken by the static inline and >> >> hence the patch. compat would have a static inline for both cases, and >> >> for the false case it'd be a no-op. If accepted upstream though then >> >> we would not need any changes for this collateral evolution. However >> >> *spotting* these collateral evolutions and giving you SmPL for them as >> >> a proactive strategy might be good given that if these type of patches >> >> are indeed welcomed upstream we'd then be able to address these as >> >> secondary steps. If they are not accepted then indeed we'd use them to >> >> backport that collateral evolution through both compat (adds the >> >> static inlines) and compat-drivers (the SmPL). >> > >> > Probably I am missing something, since I haven't looked at the code in >> > detail, bu wouldn't it be nicer to have a function call for the false >> > case, if there is a function call for the true case? >> >> Yes, and indeed we have that, its the same function call, in the >> negative case its a no-op, in the newer kernels it wraps to modifying >> the element as in the original code. >> >> > In looking at the >> > code, one could wonder why things are not done in a parallel way. >> >> Not sure I get this. > > I looked in today's linux-next, and there seems to be only one > initialization of this field, to true, and one test of this field. So > perhaps the case for setting the field to false just isn't needed. Oh sorry now I get what you mean! I thought about this -- and yes I decided to not add a bool false setting for the structure field given that the assumption is this would not be something dynamic, and data structure would be kzalloc()'d so by default they are 0. Luis -- 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: r8169 auto speed down issue
hayeswang : [...] > Do you have any suggestion about this? Your description suggests that testing against the link partner ability to work at 10M instead of testing for tp->link_ok could be good enough. Does it make sense ? -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2] serial: 8250_dw: add support for clk api
From: Emilio López
This commit implements support for using the clk api; this lets us use
the "clocks" property with device tree, instead of having to use
clock-frequency.
Signed-off-by: Emilio López
Signed-off-by: Maxime Ripard
Reviewed-by: Heikki Krogerus
---
Changes from v1:
- Add my SoB and Heikki Krogerus Reviewed-by tags
drivers/tty/serial/8250/8250_dw.c | 33 -
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_dw.c
b/drivers/tty/serial/8250/8250_dw.c
index db0e66f..3dedd24 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include "8250.h"
@@ -55,8 +56,9 @@
struct dw8250_data {
- int last_lcr;
- int line;
+ int last_lcr;
+ int line;
+ struct clk *clk;
};
static void dw8250_serial_out(struct uart_port *p, int offset, int value)
@@ -136,8 +138,13 @@ static int dw8250_probe_of(struct uart_port *p)
if (!of_property_read_u32(np, "reg-shift", &val))
p->regshift = val;
+ /* clock got configured through clk api, all done */
+ if (p->uartclk)
+ return 0;
+
+ /* try to find out clock frequency from DT as fallback */
if (of_property_read_u32(np, "clock-frequency", &val)) {
- dev_err(p->dev, "no clock-frequency property set\n");
+ dev_err(p->dev, "clk or clock-frequency not defined\n");
return -EINVAL;
}
p->uartclk = val;
@@ -294,9 +301,20 @@ static int dw8250_probe(struct platform_device *pdev)
if (!uart.port.membase)
return -ENOMEM;
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->clk = devm_clk_get(&pdev->dev, NULL);
+ if (!IS_ERR(data->clk)) {
+ clk_prepare_enable(data->clk);
+ uart.port.uartclk = clk_get_rate(data->clk);
+ }
+
uart.port.iotype = UPIO_MEM;
uart.port.serial_in = dw8250_serial_in;
uart.port.serial_out = dw8250_serial_out;
+ uart.port.private_data = data;
dw8250_setup_port(&uart);
@@ -312,12 +330,6 @@ static int dw8250_probe(struct platform_device *pdev)
return -ENODEV;
}
- data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
- if (!data)
- return -ENOMEM;
-
- uart.port.private_data = data;
-
data->line = serial8250_register_8250_port(&uart);
if (data->line < 0)
return data->line;
@@ -333,6 +345,9 @@ static int dw8250_remove(struct platform_device *pdev)
serial8250_unregister_port(data->line);
+ if (!IS_ERR(data->clk))
+ clk_disable_unprepare(data->clk);
+
return 0;
}
--
1.7.10.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] serial: 8250_dw: add support for clk api
On Fri, Mar 29, 2013 at 12:06:52AM +0100, Maxime Ripard wrote: > Hi Greg, > > Le 29/03/2013 00:03, Greg Kroah-Hartman a écrit : > > On Wed, Mar 27, 2013 at 01:35:48PM +0100, Maxime Ripard wrote: > >> From: Emilio López > >> > >> This commit implements support for using the clk api; this lets us use > >> the "clocks" property with device tree, instead of having to use > >> clock-frequency. > >> > >> Signed-off-by: Emilio López > >> --- > > > > Why aren't you signing off on this patch as well? > > Hmm, I forgot to do so, and no one pointed that one before. Sorry. > > Do you want me to resend it with my SoB? Yes, please do. thanks, greg k-h -- 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] serial: 8250_dw: add support for clk api
Hi Greg, Le 29/03/2013 00:03, Greg Kroah-Hartman a écrit : > On Wed, Mar 27, 2013 at 01:35:48PM +0100, Maxime Ripard wrote: >> From: Emilio López >> >> This commit implements support for using the clk api; this lets us use >> the "clocks" property with device tree, instead of having to use >> clock-frequency. >> >> Signed-off-by: Emilio López >> --- > > Why aren't you signing off on this patch as well? Hmm, I forgot to do so, and no one pointed that one before. Sorry. Do you want me to resend it with my SoB? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.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] serial: 8250_dw: add support for clk api
On Wed, Mar 27, 2013 at 01:35:48PM +0100, Maxime Ripard wrote: > From: Emilio López > > This commit implements support for using the clk api; this lets us use > the "clocks" property with device tree, instead of having to use > clock-frequency. > > Signed-off-by: Emilio López > --- Why aren't you signing off on this patch as well? greg k-h -- 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: Possibility for an external staging tree - bring up quality code
On Thu, Mar 28, 2013 at 01:13:23PM -0700, Luis R. Rodriguez wrote: > This has me thinking if it makes sense to have an external driver tree > for staging drivers but lead by engineers who already know the rules > of upstream, they just want to get things done faster. That's called a "fork" or "tree" or whatever you want to call it, and all of us have them, and end up merging stuff to mainline through them eventually. There is no need to "codify" something that we all have been doing for years. If someone thinks they can "work faster" in their own tree, great for them, have them do it. I don't see what I need to agree or disagree with here to keep anyone from doing such a thing. Or am I just totally missing something here? greg k-h -- 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] ARM: irq: Call irqchit_init if no init_irq function is specified
On 03/28/2013 03:46 PM, Maxime Ripard wrote:
> More and more sub-architectures are using only the irqchip_init
> function. Make the core code call this function if no init_irq field is
> provided in the machine description to remove some boilerplate code.
>
> Signed-off-by: Maxime Ripard
Acked-by: Rob Herring
> ---
> arch/arm/kernel/irq.c |6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
> index 8e4ef4c..9723d17 100644
> --- a/arch/arm/kernel/irq.c
> +++ b/arch/arm/kernel/irq.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -114,7 +115,10 @@ EXPORT_SYMBOL_GPL(set_irq_flags);
>
> void __init init_IRQ(void)
> {
> - machine_desc->init_irq();
> + if (IS_ENABLED(CONFIG_OF) && !machine_desc->init_irq)
> + irqchip_init();
> + else
> + machine_desc->init_irq();
> }
>
> #ifdef CONFIG_MULTI_IRQ_HANDLER
>
--
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/
perf test failures on Power
The 'perf' tool has some built-in test cases and one of them checks to see if the symbols in vmlinux match those in /proc/kallsyms. This test is failing on Power for several reasons. I fixed a couple of them (described briefly at the end of the mail) and these fixes take the test further. One pending failure is because maps in vmlinux differ from kallsyms. Here is some output: $ ./perf test -v 1 --- Using /lib/modules/3.8.0-rc4-perf-core+/build/vmlinux for symbols 0xc0001800: diff name v: machine_check_fwnmi k: machine_check_pSeries 0xc0005780: diff name v: __end_interrupts k: system_call_entry_direct 0xc0006800: diff name v: __end_handlers k: .do_hash_page 0xc0009300: diff name v: __secondary_start k: copy_to_here 0xc063d7a0: diff name v: __kprobes_text_end k: .vdso_getcpu_init Maps only in vmlinux: c063d804-c0642077 0 [kernel].cpuinit.text c0642078-c064225f 0 [kernel].text.unlikely c0642260-c07c 0 [kernel].meminit.text c07d-c0812043 0 [kernel].init.text c0812044-d0f8 0 [kernel].exit.text Maps in vmlinux with a different name in kallsyms: --- Looking a the first pair of differing symbols in kallsyms and vmlinux: $ grep c0001800 /proc/kallsyms c0001800 T machine_check_fwnmi c0001800 t machine_check_pSeries $ nm /boot/vmlinux-3.8.0-rc4-perf-core |grep c0001800 c0001800 T machine_check_fwnmi c0001800 t machine_check_pSeries Now perf attempts to "fixup" the duplicates (see choose_best_symbol() in tools/perf/util/symbol.c) and use heuristics to choose one from the pair and discard the other. When processing the pair of 'machine_check_fwnmi' and 'machine_check_pSeries' from kallsyms, it finds that they both have global binding and it chooses 'machine_check_pSeries' based on the string length of the symbol name. When processing the same pair from vmlinux, it finds that 'machine_check_fwnmi' has the global binding and chooses that. Finally, when comparing the vmlinux symbols with kallsyms, this mismatch is shows up as a failure. Some questions: - Is perf trying to choose one from the pair, so we have only one symbol to use when building a profile or call-graph ? - Why do some symbols like 'machine_check_fwnmi' above, appear with global binding in /proc/kallsyms and local binding in vmlinux ? Here are couple of other failures in 'perf test' on Power. I applied some quick fixes for these to expose the above failures. 1. Look for .__start or _stext. On powerpc, multiple symbols match the address of '_stext': $ grep c000 /proc/kallsyms c000 T .__start c000 T _stext c000 T _text choose_best_symbol() discards all but .__start() because, ironically, it has the least preceding underscores. The vmlinux test case later looks for _stext and fails. Quick fix, have the test case look for either _stext or .__start. 2. In vmlinux, system call names have '.sys' or '_sys_'. In kallsyms, the names have '.SyS' or '_SyS_' 0xc0067660: diff name v: .sys_sched_get_priority_max k: .SyS_sched_get_priority_max 0xc0067690: diff name v: .sys_sched_get_priority_min k: .SyS_sched_get_priority_min 0xc00f2650: diff name v: .compat_sys_waitid k: .compat_SyS_waitid 0xc00f2780: diff name v: .compat_sys_wait4 k: .compat_SyS_wait4 Quick fix: treat names as identical if they only differ in upper/lower case of the substring 'sys'. Curious though why kallsyms and vmlinux differ this way. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] xhci: Rename SEGMENT_SIZE and SEGMENT_SHIFT as the former is used in a.out.h
Sarah Sharp wrote: > I'm a little bit confused about your description for the second one. > Did you need to change the #defines names because they could conflict > with other drivers when the xHCI driver is built in? Or is there some > other point I'm missing? Sorry, I should say. I'm trying to clean up the UAPI headers and I noticed that the xHCI SEGMENT_SIZE macro is named the same as one defined by a.out.h that cannot be changed as it is seen by userspace. Although it's unlikely that within the kernel they are unlikely to collide, one cannot be entirely sure that will stay true as new arches get added (hopefully no one will add new arches that use a.out format). It seems best that the xHCI one be renamed if possible. > Are these feature patches for 3.10, or bug fixes for 3.9? If they're > for 3.9, should they go into stable? My inclination is the first patch > shouldn't but I'm not sure about this one. Both are aimed at 3.10. Neither are fixes for extant bugs that I know of. David -- 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] irqchip: Add support for ARMv7-M's NVIC
On Monday 18 March 2013, Uwe Kleine-König wrote:
> +static int __init nvic_init_bases(struct device_node *node,
> + void __iomem *nvic_base)
> +{
There is probably no point to keep this function separate from
nvic_of_init any more, unless you plan to mke it globally
accessible and called from non-DT platforms. In that case
you would need an irq_base argument though.
> + irq_base = irq_alloc_descs_from(16, irqs, numa_node_id());
> + if (irq_base < 0) {
> + pr_warn("Cannot allocate irq_descs\n");
> + ret = irq_base;
> + goto err_irq_alloc_descs;
> + }
> + if (irq_base != 16) {
> + /*
> + * The entry code just passes the exception number (i.e. irq
> + * number + 16) to asm_do_IRQ, so the offset needs to be fixed
> + * here.
> + */
> + pr_warn("Failed to allocate irq_descs at offset 16\n");
> + goto err_wrong_irq_base;
> + }
> +
> + irq_domain = irq_domain_add_legacy(node, irqs, irq_base, 0,
> +&irq_domain_simple_ops, NULL);
Why do you use a legacy domain here, and hardcode the irq_base?
For a fully DT-enabled platform, the base should not matter and you
can use irq_domain_add_linear, while a legacy platform would likely
need a different base.
> +static int __init nvic_of_init(struct device_node *node,
> +struct device_node *parent)
> +{
> + void __iomem *nvic_base;
> +
> + if (!node)
> + return -ENODEV;
As Thomas commented, the check for !node is pointless here.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/10] mm: vmscan: Limit the number of pages kswapd reclaims at each priority
On 03/25/2013 10:13 AM, Jiri Slaby wrote: > BTW I very pray this will fix also the issue I have when I run ltp tests > (highly I/O intensive, esp. `growfiles') in a VM while playing a movie > on the host resulting in a stuttered playback ;). No, this is still terrible. I was now updating a kernel in a VM and had problems to even move with cursor. There was still 1.2G used by I/O cache. thanks, -- js suse labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch
On Thu, 28 Mar 2013, Luis R. Rodriguez wrote: > On Thu, Mar 28, 2013 at 11:10 AM, Julia Lawall wrote: > > On Thu, 28 Mar 2013, Luis R. Rodriguez wrote: > >> > >> Thanks Julia! I'll be sure to try to add this to compat-drivers if the > >> upstream fb patch is not accepted. If it is accepted we would not need > >> this at all! > >> > >> > Then I guess there would be a similar rule for the false case? > >> > >> Nope, see that's the proactive strategy taken by the static inline and > >> hence the patch. compat would have a static inline for both cases, and > >> for the false case it'd be a no-op. If accepted upstream though then > >> we would not need any changes for this collateral evolution. However > >> *spotting* these collateral evolutions and giving you SmPL for them as > >> a proactive strategy might be good given that if these type of patches > >> are indeed welcomed upstream we'd then be able to address these as > >> secondary steps. If they are not accepted then indeed we'd use them to > >> backport that collateral evolution through both compat (adds the > >> static inlines) and compat-drivers (the SmPL). > > > > Probably I am missing something, since I haven't looked at the code in > > detail, bu wouldn't it be nicer to have a function call for the false > > case, if there is a function call for the true case? > > Yes, and indeed we have that, its the same function call, in the > negative case its a no-op, in the newer kernels it wraps to modifying > the element as in the original code. > > > In looking at the > > code, one could wonder why things are not done in a parallel way. > > Not sure I get this. I looked in today's linux-next, and there seems to be only one initialization of this field, to true, and one test of this field. So perhaps the case for setting the field to false just isn't needed. julia -- 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 09/10 v2] ioatdma: Adding write back descriptor error status support for ioatdma 3.3
v3.3 provides support for write back descriptor error status. This allows
reporting of errors in a descriptor field. In supporting this, certain
errors such as P/Q validation errors no longer halts the channel. The DMA
engine can continue to execute until the end of the chain and allow software
to report the "errors" up the stack. We are also going to mask those error
interrupts and handle them when the "chain" has completed at the end.
Signed-off-by: Dave Jiang
---
Dan, I removed the issue workaround since I can no longer reproduce the
issue on the latest stepping and the design engineers say it's not
needed.
drivers/dma/ioat/dma.h | 1 +
drivers/dma/ioat/dma_v3.c| 102 +--
drivers/dma/ioat/hw.h| 17 +++-
drivers/dma/ioat/registers.h | 1 +
4 files changed, 96 insertions(+), 25 deletions(-)
diff --git a/drivers/dma/ioat/dma.h b/drivers/dma/ioat/dma.h
index 8c88724..53c15d2 100644
--- a/drivers/dma/ioat/dma.h
+++ b/drivers/dma/ioat/dma.h
@@ -90,6 +90,7 @@ struct ioatdma_device {
struct ioat_chan_common *idx[4];
struct dca_provider *dca;
enum ioat_irq_mode irq_mode;
+ u32 cap;
void (*intr_quirk)(struct ioatdma_device *device);
int (*enumerate_channels)(struct ioatdma_device *device);
int (*reset_hw)(struct ioat_chan_common *chan);
diff --git a/drivers/dma/ioat/dma_v3.c b/drivers/dma/ioat/dma_v3.c
index b393929..108f8d8 100644
--- a/drivers/dma/ioat/dma_v3.c
+++ b/drivers/dma/ioat/dma_v3.c
@@ -510,6 +510,36 @@ static bool ioat3_cleanup_preamble(struct ioat_chan_common
*chan,
return true;
}
+static void
+desc_get_errstat(struct ioat2_dma_chan *ioat, struct ioat_ring_ent *desc)
+{
+ struct ioat_dma_descriptor *hw = desc->hw;
+
+ switch (hw->ctl_f.op) {
+ case IOAT_OP_PQ_VAL:
+ case IOAT_OP_PQ_VAL_16S:
+ {
+ struct ioat_pq_descriptor *pq = desc->pq;
+
+ /* check if there's error written */
+ if (!pq->dwbes_f.wbes)
+ return;
+
+ /* need to set a chanerr var for checking to clear later */
+
+ if (pq->dwbes_f.p_val_err)
+ *desc->result |= SUM_CHECK_P_RESULT;
+
+ if (pq->dwbes_f.q_val_err)
+ *desc->result |= SUM_CHECK_Q_RESULT;
+
+ return;
+ }
+ default:
+ return;
+ }
+}
+
/**
* __cleanup - reclaim used descriptors
* @ioat: channel (ring) to clean
@@ -547,6 +577,11 @@ static void __cleanup(struct ioat2_dma_chan *ioat,
dma_addr_t phys_complete)
prefetch(ioat2_get_ring_ent(ioat, idx + i + 1));
desc = ioat2_get_ring_ent(ioat, idx + i);
dump_desc_dbg(ioat, desc);
+
+ /* set err stat if we are using dwbes */
+ if (device->cap & IOAT_CAP_DWBES)
+ desc_get_errstat(ioat, desc);
+
tx = &desc->txd;
if (tx->cookie) {
dma_cookie_complete(tx);
@@ -1015,6 +1050,7 @@ __ioat3_prep_pq_lock(struct dma_chan *c, enum
sum_check_flags *result,
{
struct ioat2_dma_chan *ioat = to_ioat2_chan(c);
struct ioat_chan_common *chan = &ioat->base;
+ struct ioatdma_device *device = chan->device;
struct ioat_ring_ent *compl_desc;
struct ioat_ring_ent *desc;
struct ioat_ring_ent *ext;
@@ -1089,6 +1125,9 @@ __ioat3_prep_pq_lock(struct dma_chan *c, enum
sum_check_flags *result,
pq->q_addr = dst[1] + offset;
pq->ctl = 0;
pq->ctl_f.op = op;
+ /* we turn on descriptor write back error status */
+ if (device->cap & IOAT_CAP_DWBES)
+ pq->ctl_f.wb_en = result ? 1 : 0;
pq->ctl_f.src_cnt = src_cnt_to_hw(s);
pq->ctl_f.p_disable = !!(flags & DMA_PREP_PQ_DISABLE_P);
pq->ctl_f.q_disable = !!(flags & DMA_PREP_PQ_DISABLE_Q);
@@ -1205,6 +1244,9 @@ __ioat3_prep_pq16_lock(struct dma_chan *c, enum
sum_check_flags *result,
pq->ctl = 0;
pq->ctl_f.op = op;
pq->ctl_f.src_cnt = src16_cnt_to_hw(s);
+ /* we turn on descriptor write back error status */
+ if (device->cap & IOAT_CAP_DWBES)
+ pq->ctl_f.wb_en = result ? 1 : 0;
pq->ctl_f.p_disable = !!(flags & DMA_PREP_PQ_DISABLE_P);
pq->ctl_f.q_disable = !!(flags & DMA_PREP_PQ_DISABLE_Q);
@@ -1797,9 +1839,26 @@ static int ioat3_init_device(struct ioatdma_device
*device)
struct dma_device *dma;
struct dma_chan *c;
struct ioat_chan_common *chan;
+ u32 errmask;
dma = &device->common;
+ /*
+* if we have descriptor write back error status, we mask the
+* error interrupts
+*/
+ if (device->cap & IOAT_CAP_DWBES) {
+
Re: [PATCH 1/1] clk: Add notifier support in clk_prepare/clk_unprepare
On 03/28/2013 04:01 PM, Mike Turquette wrote: > Quoting Colin Cross (2013-03-21 17:06:25) >> On Thu, Mar 21, 2013 at 3:36 PM, Mike Turquette >> wrote: >>> To my knowledge, devfreq performs one task: implements an algorithm >>> (typically one that loops/polls) and applies this heuristic towards a >>> dvfs transition. >>> >>> It is a policy layer, a high level layer. It should not be used as a >>> lower-level mechanism. Please correct me if my understanding is wrong. >>> >>> I think the very idea of the clk framework calling into devfreq is >>> backwards. Ideally a devfreq driver would call clk_set_rate as part of >>> it's target callback. This is analogous to a cpufreq .target callback >>> which calls clk_set_rate and regulator_set_voltage. Can you imagine the >>> clock framework cross-calling into cpufreq when clk_set_rate is called? >>> I think that would be strange. >>> >>> I think that all of this discussion highlights the fact that there is a >>> missing piece of infrastructure. It isn't devfreq or clock rate-change >>> notifiers. It is that there is not a dvfs mechanism which neatly builds >>> on top of these lower-level frameworks (clocks & regulators). Clearly >>> some higher-level abstraction layer is needed. >> >> I went through all of this on Tegra2. For a while I had a >> dvfs_set_rate api for drivers that needed to modify the voltage when >> they updated a clock, but I ended up dropping it. Drivers rarely care >> about the voltage, all they want to do is set their clock rate. The >> voltage necessary to support that clock is an implementation detail of >> the silicon that is irrelevant to the driver > > Hi Colin, > > I agree about voltage scaling being an implementation detail, but I > think that drivers similarly do not care about enabling clocks, clock > domains, power domains, voltage domains, etc. The just want to say > "give me what I need to turn on and run", and "I'm done with that stuff > now, lazily turn off if you want to". Runtime pm gives drivers that > abstraction layer today. I don't understand how runtime PM gives this abstraction today. All the implementations of runtime PM that I've seen involve the driver itself implementing its own runtime PM callbacks, and explicitly managing the clocks itself. I don't see how that hides those details from the driver. Have I been looking at runtime PM implementations that aren't implemented philosophically correctly? -- 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/
MTD NAND BCH support for 24 bits/1K of ECC correction?
Hi all, I am trying to clean up our OCTEON NAND flash driver in the Linux kernel and enable support for multi-bit ECC using BCH and am having some issues. I am able to successfully work with NAND flash that requires 4 bits ECC per 512 bytes but I am having issues with one of our boards that has a NAND device that requires 24 bits of ECC per 1024 bytes. I was wondering if ECC of this magnitude has been successfully tested in the past. By my calculations I should have 42 bytes of ECC per 1K block (m=14, t=24 for 336 bits of ECC data). My problem is that when decoding an encoded block I am seeing that nroots != err in decode_bch() after find_poly_roots(). I am seeing this for all of the blocks I attempt to read. As far as I can tell the data being sent to BCH is good, though it might have a few bad bits but nowhere near 24. I am also seeing this same behavior in my U-Boot code which uses the identical bch and nand_bch code. Cheers, Aaron Williams -- Aaron Williams Software Engineer Cavium, Inc. (408) 943-7198 (510) 789-8988 (cell) -- 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 00/34] idle: Consolidate idle implementations
Hi Thomas, On 3/28/13 2:24 AM, Thomas Gleixner wrote: On Thu, 28 Mar 2013, Chris Zankel wrote: For Xtensa: Acked-by: Chris Zankel Thanks for going the extra mile and test-compiling it. Though, the build fails later with: arch/xtensa/kernel/built-in.o:(.init.literal+0x90): undefined reference to `platform_pcibios_init' arch/xtensa/kernel/built-in.o: In function `setup_arch': (.init.text+0x1de): undefined reference to `platform_pcibios_init' drivers/built-in.o: In function `pci_assign_unassigned_resources': [...] Thanks for the info. With KALLSYMS enabled, the .rodata section between the .text and the .init.text section is extended to a point where it exceeds the call range between those sections. I'm working on a fix (basically, move the .init.text section close to the .init section). Thanks, -Chris -- 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 v6] i2c: exynos5: add High Speed I2C controller driver
From: Naveen Krishna Chatradhi
Adds support for High Speed I2C driver found in Exynos5 and
later SoCs from Samsung.
This driver currently supports Auto mode.
Driver only supports Device Tree method.
Note: Added debugfs support for registers view, not tested.
Signed-off-by: Taekgyun Ko
Signed-off-by: Naveen Krishna Chatradhi
---
Changes since v5:
1. fixed the clock_info function pointed out by Yuvaraj
2. Clear pending interrupt register before initializing in probe
.../devicetree/bindings/i2c/i2c-exynos5.txt| 50 ++
drivers/i2c/busses/Kconfig |7 +
drivers/i2c/busses/Makefile|1 +
drivers/i2c/busses/i2c-exynos5.c | 874
4 files changed, 932 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
create mode 100644 drivers/i2c/busses/i2c-exynos5.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
new file mode 100644
index 000..0bc9347
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
@@ -0,0 +1,50 @@
+* Samsung's High Speed I2C controller
+
+The Samsung's High Speed I2C controller is used to interface with I2C devices
+at various speeds ranging from 100khz to 3.4Mhz.
+
+Required properties:
+ - compatible: value should be.
+ (a) "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
+ - reg: physical base address of the controller and length of memory mapped
+region.
+ - interrupts: interrupt number to the cpu.
+
+ - Samsung GPIO variant (deprecated):
+- gpios: The order of the gpios should be the following: .
+ The gpio specifier depends on the gpio controller.
+ - Pinctrl variant (preferred, if available):
+- pinctrl-0: Pin control group to be used for this controller.
+- pinctrl-names: Should contain only one value - "default".
+
+Optional properties:
+ - samsung,hs-mode: Mode of operation, High speed or Fast speed mode. If not
+specified, default value is 0.
+ - samsung,hs-clock-freq: Desired operating frequency in Hz of the bus.
+If not specified, the default value in Hz is 10.
+ - samsung,fs-clock-freq: Desired operarting frequency in Hz of the bus.
+If not specified, the default value in Hz is 10.
+
+Example:
+
+ hsi2c@12ca {
+ compatible = "samsung,exynos5-hsi2c";
+ reg = <0x12ca 0x100>;
+ interrupts = <56>;
+ samsung,fs-clock-freq = <10>;
+ /* Samsung GPIO variant begins here */
+ gpios = <&gpd1 2 0 /* SDA */
+&gpd1 3 0 /* SCL */>;
+ /* Samsung GPIO variant ends here */
+ /* Pinctrl variant begins here */
+ pinctrl-0 = <&i2c4_bus>;
+ pinctrl-names = "default";
+ /* Pinctrl variant ends here */
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ s2mps11_pmic@66 {
+ compatible = "samsung,s2mps11-pmic";
+ reg = <0x66>;
+ };
+ };
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index a3725de..78b4936 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -434,6 +434,13 @@ config I2C_EG20T
ML7213/ML7223/ML7831 is companion chip for Intel Atom E6xx series.
ML7213/ML7223/ML7831 is completely compatible for Intel EG20T PCH.
+config I2C_EXYNOS5
+ tristate "Exynos5 high-speed I2C driver"
+ depends on ARCH_EXYNOS5 && OF
+ help
+ Say Y here to include support for High-speed I2C controller in the
+ Exynos5 based Samsung SoCs.
+
config I2C_GPIO
tristate "GPIO-based bitbanging I2C"
depends on GENERIC_GPIO
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 8f4fc23..b19366c 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -42,6 +42,7 @@ i2c-designware-platform-objs := i2c-designware-platdrv.o
obj-$(CONFIG_I2C_DESIGNWARE_PCI) += i2c-designware-pci.o
i2c-designware-pci-objs := i2c-designware-pcidrv.o
obj-$(CONFIG_I2C_EG20T)+= i2c-eg20t.o
+obj-$(CONFIG_I2C_EXYNOS5) += i2c-exynos5.o
obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
obj-$(CONFIG_I2C_HIGHLANDER) += i2c-highlander.o
obj-$(CONFIG_I2C_IBM_IIC) += i2c-ibm_iic.o
diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
new file mode 100644
index 000..a17848f
--- /dev/null
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -0,0 +1,874 @@
+/**
+ * i2c-exynos5.c - Samsung Exynos5 I2C Controller Driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundati
Re: [PATCH v3] ARM: add support for context tracking subsystem
Kevin Hilman writes: > commit 91d1aa43 (context_tracking: New context tracking susbsystem) > generalized parts of the RCU userspace extended quiescent state into > the context tracking subsystem. Context tracking is then used > to implement adaptive tickless (a.k.a extended nohz) > > To support the new context tracking subsystem on ARM, the user/kernel > boundary transtions need to be instrumented. > > For exceptions and IRQs in usermode, the existing usr_entry macro is > used to instrument the user->kernel transition. For the return to > usermode path, the ret_to_user* path is instrumented. Using the > usr_entry macro, this covers interrupts in userspace, data abort and > prefetch abort exceptions in userspace as well as undefined exceptions > in userspace (which is where FP emulation and VFP are handled.) > > For syscalls, the slow return path is covered by instrumenting the > ret_to_user path. In addition, the syscall entry point is > instrumented which covers the user->kernel transition for both fast > and slow syscalls, and an additional instrumentation point is added > for the fast syscall return path (ret_fast_syscall). > > Cc: Mats Liljegren > Cc: Frederic Weisbecker > Signed-off-by: Kevin Hilman This version has been submitted to Russell's patch tracker as patch 7688[1] after making the minor change below. [...] > diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S > index 0f82098..3449d30 100644 > --- a/arch/arm/kernel/entry-armv.S > +++ b/arch/arm/kernel/entry-armv.S > @@ -396,6 +396,7 @@ ENDPROC(__pabt_svc) > #ifdef CONFIG_IRQSOFF_TRACER > bl trace_hardirqs_off > #endif > + ct_user_exit, save = 0 > .endm Removed the ',' after the macro here an elsewhere. It's harmless, but not needed and removing it makes this look like other macro usage throughout. Kevin [1] http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7688/1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 6/7] USB: EHCI: make ehci-msm a separate driver
From: Manjunath Goudar
Separate the Qualcomm QSD/MSM on-chip host controller driver from
ehci-hcd host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before Qualcomm QSD/MSM
can be booted with a multi-platform kernel, which is not expected before
3.11.
With the infrastructure added by Alan Stern in patch 3e0232039
"USB: EHCI: prepare to make ehci-hcd a library module", we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the msm bus glue.
In V3:
1.Detail commit message added here,why this patch is required.
2.Arranged #include's in alphabetical order.
3.drive.name initialized hcd_name[] = "ehci-msm" in platform_driver structure
initialization
instead of "msm-ehci",that is reason it was breaking in EHCI USB testing.this
one fixed in V3.
In V2:
Tegra patch related changes removed from this patch.
Signed-off-by: Manjunath Goudar
Cc: Greg KH
Cc: Alan Stern
Cc: David Brown
Cc: Daniel Walker
Cc: Bryan Huntsman
Cc: Brian Swetland
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Arnd Bergmann
---
drivers/usb/host/Kconfig| 2 +-
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-hcd.c | 6 +---
drivers/usb/host/ehci-msm.c | 85 -
4 files changed, 40 insertions(+), 54 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 8c564aa..35a5d3b 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -190,7 +190,7 @@ config USB_EHCI_HCD_AT91
Atmel chips.
config USB_EHCI_MSM
- bool "Support for MSM on-chip EHCI USB controller"
+ tristate "Support for Qualcomm QSD/MSM on-chip EHCI USB controller"
depends on USB_EHCI_HCD && ARCH_MSM
select USB_EHCI_ROOT_HUB_TT
select USB_MSM_OTG
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 368d3eb..4fb73c1 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_USB_EHCI_HCD_ORION) += ehci-orion.o
obj-$(CONFIG_USB_EHCI_HCD_SPEAR) += ehci-spear.o
obj-$(CONFIG_USB_EHCI_S5P) += ehci-s5p.o
obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
+obj-$(CONFIG_USB_EHCI_MSM) += ehci-msm.o
obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index efc641c..d5c4ae8 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1260,11 +1260,6 @@ MODULE_LICENSE ("GPL");
#define PLATFORM_DRIVERehci_octeon_driver
#endif
-#ifdef CONFIG_USB_EHCI_MSM
-#include "ehci-msm.c"
-#define PLATFORM_DRIVERehci_msm_driver
-#endif
-
#ifdef CONFIG_TILE_USB
#include "ehci-tilegx.c"
#definePLATFORM_DRIVER ehci_hcd_tilegx_driver
@@ -1304,6 +1299,7 @@ MODULE_LICENSE ("GPL");
!IS_ENABLED(CONFIG_USB_EHCI_HCD_SPEAR) && \
!IS_ENABLED(CONFIG_USB_EHCI_S5P) && \
!IS_ENABLED(CONFIG_USB_EHCI_HCD_AT91) && \
+ !IS_ENABLED(CONFIG_USB_EHCI_MSM) && \
!defined(PLATFORM_DRIVER) && \
!defined(PS3_SYSTEM_BUS_DRIVER) && \
!defined(OF_PLATFORM_DRIVER) && \
diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index 88a49c8..3b45f0c 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -22,16 +22,26 @@
* along with this program; if not, you can find it at http://www.fsf.org
*/
-#include
#include
#include
+#include
+#include
+#include
+#include
#include
-
#include
#include
+#include
+#include
+
+#include "ehci.h"
#define MSM_USB_BASE (hcd->regs)
+#define DRIVER_DESC "Qualcomm On-Chip EHCI Host Controller"
+
+static const char hcd_name[] = "ehci-msm";
+static struct hc_driver __read_mostly msm_hc_driver;
static struct usb_phy *phy;
static int ehci_msm_reset(struct usb_hcd *hcd)
@@ -56,52 +66,6 @@ static int ehci_msm_reset(struct usb_hcd *hcd)
return 0;
}
-static struct hc_driver msm_hc_driver = {
- .description= hcd_name,
- .product_desc = "Qualcomm On-Chip EHCI Host Controller",
- .hcd_priv_size = sizeof(struct ehci_hcd),
-
- /*
-* generic hardware linkage
-*/
- .irq= ehci_irq,
- .flags = HCD_USB2 | HCD_MEMORY,
-
- .reset = ehci_msm_reset,
- .start = ehci_run,
-
- .stop = ehci_stop,
- .shutdown = ehci_shutdown,
-
- /*
-* managing i/o requests and associated device resources
-*/
- .urb_enqueue= ehci_urb_enqueue,
- .urb_dequeue= ehci_urb_dequeue,
- .endpoint_disable = ehci_endpoint_disable,
- .endpoint_re
[PATCH v3 1/7] USB: EHCI: make ehci-orion a separate driver
From: Manjunath Goudar
Separate the Orion host controller driver from ehci-hcd host
code into its own driver module because of following reason.
With the multiplatform changes in arm-soc tree, it becomes
possible to enable the mvebu platform (which uses
ehci-orion) at the same time as other platforms that require
a conflicting EHCI bus glue. At the moment, this results
in a warning like
drivers/usb/host/ehci-hcd.c:1297:0: warning: "PLATFORM_DRIVER" redefined
[enabled by default]
drivers/usb/host/ehci-hcd.c:1277:0: note: this is the location of the previous
definition
drivers/usb/host/ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined but
not used [-Wunused-variable]
and an ehci driver that only works on one of them.
With the infrastructure added by Alan Stern in patch 3e0232039
"USB: EHCI: prepare to make ehci-hcd a library module", we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the orion bus glue.
An earlier version of this patch was included in 3.9 but caused
a regression there, which has subsequently been fixed.
In V3:
1.More detail provided in commit message regarding this patch.
2.Replaced hcd_name string "ehci-orion" into "orion-ehci".
3.MODULE_LICENSE is GPL v2.
4.In ehci_init_driver calling second argument passed as NULL instead of
ehci_orion_overrides because ehci_orion_overrides is removed.
In V2:
Tegra patch related changes removed from this patch.
Signed-off-by: Manjunath Goudar
Signed-off-by: Arnd Bergmann
Acked-by: Jason Cooper
Tested-by: Andrew Lunn
Cc: Greg KH
Cc: Alan Stern
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/usb/host/Kconfig | 10 ++
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-hcd.c | 6 +---
drivers/usb/host/ehci-orion.c | 82 ++-
4 files changed, 47 insertions(+), 52 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 2f68221..d89b7ad 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -163,6 +163,16 @@ config USB_EHCI_HCD_OMAP
Enables support for the on-chip EHCI controller on
OMAP3 and later chips.
+config USB_EHCI_HCD_ORION
+ tristate "Support for Marvell EBU on-chip EHCI USB controller"
+ depends on USB_EHCI_HCD && PLAT_ORION
+ default y
+ ---help---
+ Enables support for the on-chip EHCI controller on Marvell's
+ embedded ARM SoCs, including Orion, Kirkwood, Dove, Armada XP,
+ Armada 370. This is different from the EHCI implementation
+ on Marvell's mobile PXA and MMP SoC, see USB_EHCI_MV for those.
+
config USB_EHCI_MSM
bool "Support for MSM on-chip EHCI USB controller"
depends on USB_EHCI_HCD && ARCH_MSM
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 56de410..9492f50 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_USB_EHCI_PCI)+= ehci-pci.o
obj-$(CONFIG_USB_EHCI_HCD_PLATFORM)+= ehci-platform.o
obj-$(CONFIG_USB_EHCI_MXC) += ehci-mxc.o
obj-$(CONFIG_USB_EHCI_HCD_OMAP)+= ehci-omap.o
+obj-$(CONFIG_USB_EHCI_HCD_ORION) += ehci-orion.o
obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index b12b97d..1f97268 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1249,11 +1249,6 @@ MODULE_LICENSE ("GPL");
#define XILINX_OF_PLATFORM_DRIVER ehci_hcd_xilinx_of_driver
#endif
-#ifdef CONFIG_PLAT_ORION
-#include "ehci-orion.c"
-#definePLATFORM_DRIVER ehci_orion_driver
-#endif
-
#ifdef CONFIG_USB_W90X900_EHCI
#include "ehci-w90x900.c"
#definePLATFORM_DRIVER ehci_hcd_w90x900_driver
@@ -1319,6 +1314,7 @@ MODULE_LICENSE ("GPL");
!IS_ENABLED(CONFIG_USB_CHIPIDEA_HOST) && \
!IS_ENABLED(CONFIG_USB_EHCI_MXC) && \
!IS_ENABLED(CONFIG_USB_EHCI_HCD_OMAP) && \
+ !IS_ENABLED(CONFIG_USB_EHCI_HCD_ORION) && \
!defined(PLATFORM_DRIVER) && \
!defined(PS3_SYSTEM_BUS_DRIVER) && \
!defined(OF_PLATFORM_DRIVER) && \
diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
index 38c45fb..54c5794 100644
--- a/drivers/usb/host/ehci-orion.c
+++ b/drivers/usb/host/ehci-orion.c
@@ -17,6 +17,12 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+
+#include "ehci.h"
#define rdl(off) __raw_readl(hcd->regs + (off))
#define wrl(off, val) __raw_writel((val), hcd->regs + (off))
@@ -34,6 +40,12 @@
#define USB_PHY_IVREF_CTRL 0x440
#define USB_PHY_TST_GRP_CTRL 0x450
+#define DRIVER_DESC "EHCI orion driver"
+
+static const char hcd_name[] = "ehci-orion";
+
+static struct hc_driver __read_mostly ehci_orion_hc_driver;
+
/*
* Implement Orion USB controller specification
[PATCH v3 3/7] USB: EHCI: make ehci-s5p a separate driver
From: Manjunath Goudar
Separate the Samsung S5P/EXYNOS host controller driver from ehci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before S5P/EXYNOS can
be booted with a multi-platform kernel. We currently expect those
to get merged for 3.10.
With the infrastructure added by Alan Stern in patch 3e0232039
"USB: EHCI: prepare to make ehci-hcd a library module", we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the s5p bus glue.
In V3:
-Detail commit message added here,why this patch is required.
-MODULE_LICENSE is GPL v2.
-Added .extra_priv_size to eliminate the separate allocation of the
s5p_ehci_hcd structure
and removed .reset function pointer initialization.
-Arranged #include's in alphabetical order.
-After using extra_priv_size initialization,struct usb_hcd *hcd is redundant
that's why removed
from the prob function.
-Eliminated s5p_ehci_phy_enable,contents of statements moved into the
s5p_ehci_probe
-Eliminated s5p_ehci_phy_disable, contents of statements moved into the
s5p_ehci_remove.
In V2:
Tegra patch related changes removed from this patch.
Signed-off-by: Manjunath Goudar
Acked-by: Jingoo Han
Cc: Greg KH
Cc: Alan Stern
Cc: Kukjin Kim
Cc: Kyungmin Park
Cc: Grant Likely
Cc: Rob Herring
Cc: linux-...@vger.kernel.org
Signed-off-by: Arnd Bergmann
---
drivers/usb/host/Kconfig| 5 +-
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-hcd.c | 6 +-
drivers/usb/host/ehci-s5p.c | 153 ++--
4 files changed, 82 insertions(+), 83 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 12fb83e..01c1acb 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -218,10 +218,11 @@ config USB_EHCI_SH
If you use the PCI EHCI controller, this option is not necessary.
config USB_EHCI_S5P
- boolean "S5P EHCI support"
+ tristate "EHCI support for Samsung S5P/EXYNOS SoC Series"
depends on USB_EHCI_HCD && PLAT_S5P
help
-Enable support for the S5P SOC's on-chip EHCI controller.
+ Enable support for the Samsung S5P and Exynos3/4/5 SOC's
+ on-chip EHCI controller.
config USB_EHCI_MV
bool "EHCI support for Marvell on-chip controller"
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 3e02471..3d895b5 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_USB_EHCI_MXC)+= ehci-mxc.o
obj-$(CONFIG_USB_EHCI_HCD_OMAP)+= ehci-omap.o
obj-$(CONFIG_USB_EHCI_HCD_ORION) += ehci-orion.o
obj-$(CONFIG_USB_EHCI_HCD_SPEAR) += ehci-spear.o
+obj-$(CONFIG_USB_EHCI_S5P) += ehci-s5p.o
obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index c8c70a1..8f1f4b4 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1284,11 +1284,6 @@ MODULE_LICENSE ("GPL");
#define PLATFORM_DRIVERtegra_ehci_driver
#endif
-#ifdef CONFIG_USB_EHCI_S5P
-#include "ehci-s5p.c"
-#define PLATFORM_DRIVERs5p_ehci_driver
-#endif
-
#ifdef CONFIG_SPARC_LEON
#include "ehci-grlib.c"
#define PLATFORM_DRIVERehci_grlib_driver
@@ -1311,6 +1306,7 @@ MODULE_LICENSE ("GPL");
!IS_ENABLED(CONFIG_USB_EHCI_HCD_OMAP) && \
!IS_ENABLED(CONFIG_USB_EHCI_HCD_ORION) && \
!IS_ENABLED(CONFIG_USB_EHCI_HCD_SPEAR) && \
+ !IS_ENABLED(CONFIG_USB_EHCI_S5P) && \
!defined(PLATFORM_DRIVER) && \
!defined(PS3_SYSTEM_BUS_DRIVER) && \
!defined(OF_PLATFORM_DRIVER) && \
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 738490e..f32be6f 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -13,13 +13,24 @@
*/
#include
+#include
+#include
+#include
+#include
#include
-#include
#include
+#include
#include
#include
#include
#include
+#include
+#include
+#include
+
+#include "ehci.h"
+
+#define DRIVER_DESC "EHCI s5p driver"
#define EHCI_INSNREG00(base) (base + 0x90)
#define EHCI_INSNREG00_ENA_INCR16 (0x1 << 25)
@@ -30,65 +41,17 @@
(EHCI_INSNREG00_ENA_INCR16 | EHCI_INSNREG00_ENA_INCR8 | \
EHCI_INSNREG00_ENA_INCR4 | EHCI_INSNREG00_ENA_INCRX_ALIGN)
+static const char hcd_name[] = "ehci-s5p";
+static struct hc_driver __read_mostly s5p_ehci_hc_driver;
+
struct s5p_ehci_hcd {
- struct device *dev;
- struct usb_hcd *hcd;
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
struct s5p_ehci_platdata *pdata;
};
-static const struct hc_driver s5p_ehci_hc_driver = {
- .description= hcd_name,
- .product_d
[PATCH v3 4/7] USB: EHCI: export ehci_shutdown
The ehci_shutdown function is used by the platform specific ehci backends
for at91, tegra and ps3. In order to turn any of these into separate
modules, we need to make this function globally visible and export it.
Signed-off-by: Arnd Bergmann
Cc: Greg KH
Cc: Alan Stern
Cc: linux-...@vger.kernel.org
---
drivers/usb/host/ehci-hcd.c | 3 ++-
drivers/usb/host/ehci.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 8f1f4b4..1c9aa17 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -353,7 +353,7 @@ static void ehci_silence_controller(struct ehci_hcd *ehci)
* This forcibly disables dma and IRQs, helping kexec and other cases
* where the next system software may expect clean state.
*/
-static void ehci_shutdown(struct usb_hcd *hcd)
+void ehci_shutdown(struct usb_hcd *hcd)
{
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
@@ -367,6 +367,7 @@ static void ehci_shutdown(struct usb_hcd *hcd)
hrtimer_cancel(&ehci->hrtimer);
}
+EXPORT_SYMBOL_GPL(ehci_shutdown);
/*-*/
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index e666999..915739d 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -799,6 +799,7 @@ struct ehci_driver_overrides {
extern voidehci_init_driver(struct hc_driver *drv,
const struct ehci_driver_overrides *over);
extern int ehci_setup(struct usb_hcd *hcd);
+extern voidehci_shutdown(struct usb_hcd *hcd);
#ifdef CONFIG_PM
extern int ehci_suspend(struct usb_hcd *hcd, bool do_wakeup);
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 5/7] USB: EHCI: make ehci-atmel a separate driver
From: Manjunath Goudar
Separate the Atmel host controller driver from ehci-hcd host code
so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before Atmel can be
booted with a multi-platform kernel. This is currently planned for
Linux-3.11.
With the infrastructure added by Alan Stern in patch 3e0232039
"USB: EHCI: prepare to make ehci-hcd a library module", we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the Atmel bus glue.
In V3:
-Detailed commit message added here about why this patch is required.
-Replaced hcd_name string "ehci-atmel" to "atmel-ehci".
-In Makefile inserted Blank line that separates the EHCI drivers from the
following non-EHCI drivers.
-Export ehci_shutdown symbol as it is needed by the Atmel driver.
-Eliminated ehci_atmel_setup routine beacuse hcd registers
directly setting in ehci_atmel_drv_probe function.
In V2:
Resolved below compiler error.
drivers/usb/host/ehci-atmel.c: In function 'ehci_atmel_drv_remove':
drivers/usb/host/ehci-atmel.c:167: error: implicit declaration of function
'ehci_shutdown'
Signed-off-by: Manjunath Goudar
Cc: Alan Stern
Cc: Greg KH
Cc: Andrew Victor
Cc: Nicolas Ferre
Cc: Jean-Christophe Plagniol-Villard
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Arnd Bergmann
---
drivers/usb/host/Kconfig | 8
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-atmel.c | 85 ---
drivers/usb/host/ehci-hcd.c | 6 +--
4 files changed, 50 insertions(+), 50 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 01c1acb..8c564aa 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -181,6 +181,14 @@ config USB_EHCI_HCD_SPEAR
Enables support for the on-chip EHCI controller on
ST SPEAr chips.
+config USB_EHCI_HCD_AT91
+tristate "Support for Atmel on-chip EHCI USB controller"
+depends on USB_EHCI_HCD && ARCH_AT91
+default y
+---help---
+ Enables support for the on-chip EHCI controller on
+ Atmel chips.
+
config USB_EHCI_MSM
bool "Support for MSM on-chip EHCI USB controller"
depends on USB_EHCI_HCD && ARCH_MSM
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 3d895b5..368d3eb 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_USB_EHCI_HCD_OMAP) += ehci-omap.o
obj-$(CONFIG_USB_EHCI_HCD_ORION) += ehci-orion.o
obj-$(CONFIG_USB_EHCI_HCD_SPEAR) += ehci-spear.o
obj-$(CONFIG_USB_EHCI_S5P) += ehci-s5p.o
+obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index f3beac4..9ce1217 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -15,6 +15,19 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ehci.h"
+
+#define DRIVER_DESC "EHCI atmel driver"
+
+static const char hcd_name[] = "ehci-atmel";
+static struct hc_driver __read_mostly ehci_atmel_hc_driver;
/* interface and function clocks */
static struct clk *iclk, *fclk;
@@ -50,51 +63,6 @@ static void atmel_stop_ehci(struct platform_device *pdev)
/*-*/
-static int ehci_atmel_setup(struct usb_hcd *hcd)
-{
- struct ehci_hcd *ehci = hcd_to_ehci(hcd);
-
- /* registers start at offset 0x0 */
- ehci->caps = hcd->regs;
-
- return ehci_setup(hcd);
-}
-
-static const struct hc_driver ehci_atmel_hc_driver = {
- .description= hcd_name,
- .product_desc = "Atmel EHCI UHP HS",
- .hcd_priv_size = sizeof(struct ehci_hcd),
-
- /* generic hardware linkage */
- .irq= ehci_irq,
- .flags = HCD_MEMORY | HCD_USB2,
-
- /* basic lifecycle operations */
- .reset = ehci_atmel_setup,
- .start = ehci_run,
- .stop = ehci_stop,
- .shutdown = ehci_shutdown,
-
- /* managing i/o requests and associated device resources */
- .urb_enqueue= ehci_urb_enqueue,
- .urb_dequeue= ehci_urb_dequeue,
- .endpoint_disable = ehci_endpoint_disable,
- .endpoint_reset = ehci_endpoint_reset,
-
- /* scheduling support */
- .get_frame_number = ehci_get_frame,
-
- /* root hub support */
- .hub_status_data= ehci_hub_status_data,
- .hub_control= ehci_hub_control,
- .bus_suspend= ehci_bus_suspend,
- .b
[PATCH v3 7/7] USB: OHCI: avoid conflicting platform drivers
Like the EHCI driver, OHCI supports a large number of different platform
glue drivers by directly including them, which causes problems with
conflicting macro definitions in some cases. As more ARM architecture
specific back-ends are required to coexist in a single build, we should
split those out into separate drivers. Unfortunately, the infrastructure
for that is still under development, so to give us more time, this uses
a separate *_PLATFORM_DRIVER macro for each ARM specific OHCI backend,
just like we already do on PowerPC and some of the other ARM platforms.
In linux-3.10, only the SPEAr and CNS3xxx back-ends would actually conflict
without this patch, but over time we would get more of them, so this
is a way to avoid having to patch the driver every time it breaks. We
should still split out all back-ends into separate loadable modules,
but that work is only needed to improve code size and cleanliness after
this patch, not for correctness.
While we're here, this fixes the incorrectly sorted error path
for the OMAP1 and OMAP3 backends to ensure we always unregister
the exact set of drivers that were registered before erroring out.
Signed-off-by: Arnd Bergmann
Cc: Manjunath Goudar
Cc: Greg KH
Cc: Alan Stern
Cc: linux-...@vger.kernel.org
---
drivers/usb/host/ohci-hcd.c | 136 ++--
1 file changed, 118 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 180a2b0..9e6de95 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1102,12 +1102,12 @@ MODULE_LICENSE ("GPL");
#if defined(CONFIG_ARCH_S3C24XX) || defined(CONFIG_ARCH_S3C64XX)
#include "ohci-s3c2410.c"
-#define PLATFORM_DRIVERohci_hcd_s3c2410_driver
+#define S3C2410_PLATFORM_DRIVERohci_hcd_s3c2410_driver
#endif
#ifdef CONFIG_USB_OHCI_EXYNOS
#include "ohci-exynos.c"
-#define PLATFORM_DRIVERexynos_ohci_driver
+#define EXYNOS_PLATFORM_DRIVER exynos_ohci_driver
#endif
#ifdef CONFIG_USB_OHCI_HCD_OMAP1
@@ -1127,25 +1127,24 @@ MODULE_LICENSE ("GPL");
#ifdef CONFIG_ARCH_EP93XX
#include "ohci-ep93xx.c"
-#define PLATFORM_DRIVERohci_hcd_ep93xx_driver
+#define EP93XX_PLATFORM_DRIVER ohci_hcd_ep93xx_driver
#endif
#ifdef CONFIG_ARCH_AT91
#include "ohci-at91.c"
-#define PLATFORM_DRIVERohci_hcd_at91_driver
+#define AT91_PLATFORM_DRIVER ohci_hcd_at91_driver
#endif
#ifdef CONFIG_ARCH_LPC32XX
#include "ohci-nxp.c"
-#define PLATFORM_DRIVERusb_hcd_nxp_driver
+#define NXP_PLATFORM_DRIVERusb_hcd_nxp_driver
#endif
#ifdef CONFIG_ARCH_DAVINCI_DA8XX
#include "ohci-da8xx.c"
-#define PLATFORM_DRIVERohci_hcd_da8xx_driver
+#define DAVINCI_PLATFORM_DRIVERohci_hcd_da8xx_driver
#endif
-
#ifdef CONFIG_USB_OHCI_HCD_PPC_OF
#include "ohci-ppc-of.c"
#define OF_PLATFORM_DRIVER ohci_hcd_ppc_of_driver
@@ -1153,7 +1152,7 @@ MODULE_LICENSE ("GPL");
#ifdef CONFIG_PLAT_SPEAR
#include "ohci-spear.c"
-#define PLATFORM_DRIVERspear_ohci_hcd_driver
+#define SPEAR_PLATFORM_DRIVER spear_ohci_hcd_driver
#endif
#ifdef CONFIG_PPC_PS3
@@ -1199,7 +1198,14 @@ MODULE_LICENSE ("GPL");
!defined(SA_DRIVER) && \
!defined(PS3_SYSTEM_BUS_DRIVER) && \
!defined(SM501_OHCI_DRIVER) && \
- !defined(TMIO_OHCI_DRIVER)
+ !defined(TMIO_OHCI_DRIVER) && \
+ !defined(S3C2410_PLATFORM_DRIVER) && \
+ !defined(EXYNOS_PLATFORM_DRIVER) && \
+ !defined(EP93XX_PLATFORM_DRIVER) && \
+ !defined(AT91_PLATFORM_DRIVER) && \
+ !defined(NXP_PLATFORM_DRIVER) && \
+ !defined(DAVINCI_PLATFORM_DRIVER) && \
+ !defined(SPEAR_PLATFORM_DRIVER)
#error "missing bus glue for ohci-hcd"
#endif
@@ -1277,9 +1283,79 @@ static int __init ohci_hcd_mod_init(void)
goto error_tmio;
#endif
+#ifdef S3C2410_PLATFORM_DRIVER
+ retval = platform_driver_register(&S3C2410_PLATFORM_DRIVER);
+ if (retval < 0)
+ goto error_s3c2410;
+#endif
+
+#ifdef EXYNOS_PLATFORM_DRIVER
+ retval = platform_driver_register(&EXYNOS_PLATFORM_DRIVER);
+ if (retval < 0)
+ goto error_exynos;
+#endif
+
+#ifdef EP93XX_PLATFORM_DRIVER
+ retval = platform_driver_register(&EP93XX_PLATFORM_DRIVER);
+ if (retval < 0)
+ goto error_ep93xx;
+#endif
+
+#ifdef AT91_PLATFORM_DRIVER
+ retval = platform_driver_register(&AT91_PLATFORM_DRIVER);
+ if (retval < 0)
+ goto error_at91;
+#endif
+
+#ifdef NXP_PLATFORM_DRIVER
+ retval = platform_driver_register(&NXP_PLATFORM_DRIVER);
+ if (retval < 0)
+ goto error_nxp;
+#endif
+
+#ifdef DAVINCI_PLATFORM_DRIVER
+ retval = platform_driver_register(&DAVINCI_PLATFORM_DRIVER);
+ if (retval < 0)
+ goto error_davinci;
+#endif
+
+#ifdef SPEAR_PLATFORM_DRIVER
+ retval = platform_driver_register(&SPEAR_
[PATCH v3 0/7] USB EHCI multiplatform series again
Hi Alan, These are the current patches from Manjunath, after I helped him address the remaining review comments and found a few more in the process. Unfortunately, Manjunath is currently on vacation and I will be away for the next couple of days when he returns, so I took the liberty to send the patches myself to have a chance of getting them merged in time for 3.10. The patches are all based on today's usb-next branch, which includes my earlier patch to remove the vt8500 backend. They are sorted by priority: the first one obviously should have been in 3.9 but didn't make it. The second one will be needed in 3.10, and the third one quite likely as well. The atmel and msm patches can wait for 3.11 since we don't plan to have multiplatform support for those SoCs in 3.10. Manjunath also did patches for the tegra, mv and w90X900 back-ends, but there are still known bugs in them so we don't submit them yet. Tegra might become multiplatform in 3.10, but that will still work as long as it's the only platform defining the PLATFORM_DRIVER macro. Please review the latest version so we can get at least the first three patches merged for 3.10, or more if you are happy with them. I'm not sure what to do about OHCI, the last patch in this series is the best I could think of, given that nobody has worked on a proper series. Nicolas and David: the at91 and msm patches have no maintainer Ack so far and are build-tested only. Please let us know if you want to get them merged for 3.10, or if we should drop them for now and let you pick them up when you get around to adding multiplatform support for your SoCs. The at91 patch requires "USB: EHCI: export ehci_shutdown", which will also be needed for the upcoming Tegra patch. Arnd Arnd Bergmann (2): USB: EHCI: export ehci_shutdown USB: OHCI: avoid conflicting platform drivers Manjunath Goudar (5): USB: EHCI: make ehci-orion a separate driver USB: EHCI: make ehci-spear a separate driver USB: EHCI: make ehci-s5p a separate driver USB: EHCI: make ehci-atmel a separate driver USB: EHCI: make ehci-msm a separate driver drivers/usb/host/Kconfig | 33 - drivers/usb/host/Makefile | 5 ++ drivers/usb/host/ehci-atmel.c | 85 +++ drivers/usb/host/ehci-hcd.c | 33 ++--- drivers/usb/host/ehci-msm.c | 85 ++- drivers/usb/host/ehci-orion.c | 82 ++ drivers/usb/host/ehci-s5p.c | 153 +- drivers/usb/host/ehci-spear.c | 88 +++- drivers/usb/host/ehci.h | 1 + drivers/usb/host/ohci-hcd.c | 136 - 10 files changed, 391 insertions(+), 310 deletions(-) Cc: Alan Stern Cc: Bryan Huntsman Cc: David Brown Cc: Greg KH Cc: Jean-Christophe Plagniol-Villard Cc: Kukjin Kim Cc: Kyungmin Park Cc: Manjunath Goudar Cc: Nicolas Ferre Cc: Shiraz Hashim Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: spear-de...@list.st.com -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/7] USB: EHCI: make ehci-spear a separate driver
From: Manjunath Goudar
Separate the SPEAr host controller driver from ehci-hcd host code
so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before SPEAr can be
booted with a multi-platform kernel, but they are queued in the
arm-soc tree for 3.10.
With the infrastructure added by Alan Stern in patch 3e0232039
"USB: EHCI: prepare to make ehci-hcd a library module", we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the SPEAr bus glue.
In V3:
-Detailed commit message added here about why this patch is required.
-Eliminated ehci_spear_setup routine beacuse hcd registers
directly setting in spear_ehci_hcd_drv_probe function.
-spear_overrides struct initialized.
-Eliminate struct ehci_hcd ehci from struct spear_ehci,to enable SPEAr clock
uses directly usb_hcd *hcd in spear_start_ehci function.
-to_spear_ehci() macro modified for spear_ehci.
In V2:
Replaced spear as SPEAr everywhere, leaving functions/variables/config options.
Signed-off-by: Deepak Saxena
Signed-off-by: Manjunath Goudar
Signed-off-by: Arnd Bergmann
Acked-by: Viresh Kumar
Cc: Greg KH
Cc: Alan Stern
Cc: Shiraz Hashim
Cc: linux-...@vger.kernel.org
Cc: spear-de...@list.st.com
---
drivers/usb/host/Kconfig | 8
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-hcd.c | 6 +--
drivers/usb/host/ehci-spear.c | 88 ---
4 files changed, 51 insertions(+), 52 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index d89b7ad..12fb83e 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -173,6 +173,14 @@ config USB_EHCI_HCD_ORION
Armada 370. This is different from the EHCI implementation
on Marvell's mobile PXA and MMP SoC, see USB_EHCI_MV for those.
+config USB_EHCI_HCD_SPEAR
+tristate "Support for ST SPEAr on-chip EHCI USB controller"
+depends on USB_EHCI_HCD && PLAT_SPEAR
+default y
+---help---
+ Enables support for the on-chip EHCI controller on
+ ST SPEAr chips.
+
config USB_EHCI_MSM
bool "Support for MSM on-chip EHCI USB controller"
depends on USB_EHCI_HCD && ARCH_MSM
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 9492f50..3e02471 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_USB_EHCI_HCD_PLATFORM) += ehci-platform.o
obj-$(CONFIG_USB_EHCI_MXC) += ehci-mxc.o
obj-$(CONFIG_USB_EHCI_HCD_OMAP)+= ehci-omap.o
obj-$(CONFIG_USB_EHCI_HCD_ORION) += ehci-orion.o
+obj-$(CONFIG_USB_EHCI_HCD_SPEAR) += ehci-spear.o
obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 1f97268..c8c70a1 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1264,11 +1264,6 @@ MODULE_LICENSE ("GPL");
#define PLATFORM_DRIVERehci_octeon_driver
#endif
-#ifdef CONFIG_PLAT_SPEAR
-#include "ehci-spear.c"
-#define PLATFORM_DRIVERspear_ehci_hcd_driver
-#endif
-
#ifdef CONFIG_USB_EHCI_MSM
#include "ehci-msm.c"
#define PLATFORM_DRIVERehci_msm_driver
@@ -1315,6 +1310,7 @@ MODULE_LICENSE ("GPL");
!IS_ENABLED(CONFIG_USB_EHCI_MXC) && \
!IS_ENABLED(CONFIG_USB_EHCI_HCD_OMAP) && \
!IS_ENABLED(CONFIG_USB_EHCI_HCD_ORION) && \
+ !IS_ENABLED(CONFIG_USB_EHCI_HCD_SPEAR) && \
!defined(PLATFORM_DRIVER) && \
!defined(PS3_SYSTEM_BUS_DRIVER) && \
!defined(OF_PLATFORM_DRIVER) && \
diff --git a/drivers/usb/host/ehci-spear.c b/drivers/usb/host/ehci-spear.c
index 210bb67..d3a5859 100644
--- a/drivers/usb/host/ehci-spear.c
+++ b/drivers/usb/host/ehci-spear.c
@@ -1,5 +1,5 @@
/*
-* Driver for EHCI HCD on SPEAR SOC
+* Driver for EHCI HCD on SPEAr SOC
*
* Copyright (C) 2010 ST Micro Electronics,
* Deepak Sikri
@@ -12,17 +12,28 @@
*/
#include
+#include
+#include
#include
+#include
+#include
#include
#include
#include
+#include
+#include
+
+#include "ehci.h"
+
+#define DRIVER_DESC "EHCI SPEAr driver"
+
+static const char hcd_name[] = "SPEAr-ehci";
struct spear_ehci {
- struct ehci_hcd ehci;
struct clk *clk;
};
-#define to_spear_ehci(hcd) (struct spear_ehci *)hcd_to_ehci(hcd)
+#define to_spear_ehci(hcd) (struct spear_ehci *)(hcd_to_ehci(hcd)->priv)
static void spear_start_ehci(struct spear_ehci *ehci)
{
@@ -34,49 +45,7 @@ static void spear_stop_ehci(struct spear_ehci *ehci)
clk_disable_unprepare(ehci->clk);
}
-static int ehci_spear_setup(struct usb_hcd *hcd)
-{
- struct ehci_hcd *ehci = hcd_to_ehci(hcd);
-
- /* registers start at offset 0x0 */
- ehci->caps = hcd->regs;
-
- return ehci_setup(hcd);
-}
-
-static con
[PATCH] ARM: remove last use of CONFIG_CPU_ARM710
Support for ARM710 CPUs was removed in v3.5. Now remove the last code depending on its Kconfig macro. Signed-off-by: Paul Bolle --- Untested. Note that cpu_arm7_data_abort was also removed. arch/arm/include/asm/glue-df.h | 8 1 file changed, 8 deletions(-) diff --git a/arch/arm/include/asm/glue-df.h b/arch/arm/include/asm/glue-df.h index 8cacbcd..75e6908 100644 --- a/arch/arm/include/asm/glue-df.h +++ b/arch/arm/include/asm/glue-df.h @@ -31,14 +31,6 @@ #undef CPU_DABORT_HANDLER #undef MULTI_DABORT -#if defined(CONFIG_CPU_ARM710) -# ifdef CPU_DABORT_HANDLER -# define MULTI_DABORT 1 -# else -# define CPU_DABORT_HANDLER cpu_arm7_data_abort -# endif -#endif - #ifdef CONFIG_CPU_ABRT_LV4T # ifdef CPU_DABORT_HANDLER # define MULTI_DABORT 1 -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OMAP3 ROM Random Number Generator support
* Pali Rohár [130328 10:58]:
>
> Here is new version of patch:
>
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -486,6 +486,23 @@ static void omap_init_mcspi(void)
> static inline void omap_init_mcspi(void) {}
> #endif
>
> +extern u32 *omap3_rom_rng_call(u32 id, u32 proc, u32 flags, u32 va_ptr);
> +
> +static struct platform_device omap3_rom_rng_device = {
> + .name = "omap3-rom-rng",
> + .id = -1,
> + .dev= {
> + .platform_data = omap3_rom_rng_call,
> + },
> +};
> +
> +static void omap_init_rom_rng(void)
> +{
> + if (!cpu_is_omap34xx() || omap_type() == OMAP2_DEVICE_TYPE_GP)
> + return;
> + platform_device_register(&omap3_rom_rng_device);
> +}
> +
> /**
> * omap_init_rng - bind the RNG hwmod to the RNG omap_device
> *
This driver probably only works on Nokia boards because of the
different SMC call numbering. Until it's been verified on some
other HS omap34xx, I'd probably register this only from the
Nokia board-*.c file.
> --- /dev/null
> +++ b/drivers/char/hw_random/omap3-rom-rng.c
> +static int omap3_rom_rng_probe(struct platform_device *pdev)
> +{
> + printk(KERN_INFO "%s: initializing\n", omap3_rom_rng_name);
> +
> + omap3_rom_rng_call = pdev->dev.platform_data;
> + if (!omap3_rom_rng_call) {
> + printk(KERN_ERR "%s: omap3_rom_rng_call is NULL\n",
> +omap3_rom_rng_name);
> + return -EINVAL;
> + }
> +
> + setup_timer(&idle_timer, omap3_rom_idle_rng, 0);
> + rng_clk = clk_get_sys("omap_rng", "ick");
> + if (IS_ERR(rng_clk)) {
> + printk(KERN_ERR "%s: unable to get RNG clock\n",
> +omap3_rom_rng_name);
> + return IS_ERR(rng_clk);
> + }
You can use regular clk_get if you add the alias to
struct omap_clk omap3xxx_clks table.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next] audit: pass int* to nlmsg_next
From: Alexandru Copot
Date: Thu, 28 Mar 2013 23:31:29 +0200
> Commit 941912133025926307c7a65b203fa38403b1063a replaced the macros
> NLMSG_NEXT with calls to nlmsg_next which produces this warning:
>
> kernel/audit.c: In function ‘audit_receive_skb’:
> kernel/audit.c:928:3: warning: passing argument 2 of ‘nlmsg_next’ makes
> pointer from integer without a cast
> In file included from include/net/rtnetlink.h:5:0,
> from include/net/neighbour.h:28,
> from include/net/dst.h:17,
> from include/net/sock.h:68,
> from kernel/audit.c:55:
> include/net/netlink.h:359:1: note: expected ‘int *’ but argument is of type
> ‘int’
>
> Fix this by sending the intended pointer.
>
> Signed-off-by: Alexandru Copot
Applied, thanks.
N§²ζμrΈyϊθΨb²X¬ΆΗ§vΨ^)ήΊ{.nΗ+·₯{±κηzX§Ά‘ά¨}©²Ζ
zΪ&j:+v¨Ύ«κηzZ+Κ+zf£’·h§~Ϋi�ϋΰzΉ �w₯’Έ?¨θΪ&’)ί’fω^jΗ«y§m
α@A«aΆΪ�
0Άμh�εi
