date:20141105

Actually, cpudl_set() and cpudl_init() can never be used without
CONFIG_SMP.

Signed-off-by: pang.xunlei 
---
 kernel/sched/cpudeadline.h |3 ---
 1 file changed, 3 deletions(-)

diff --git a/kernel/sched/cpudeadline.h b/kernel/sched/cpudeadline.h
index 538c979..020039b 100644
--- a/kernel/sched/cpudeadline.h
+++ b/kernel/sched/cpudeadline.h
@@ -25,9 +25,6 @@ int cpudl_find(struct cpudl *cp, struct task_struct *p,
 void cpudl_set(struct cpudl *cp, int cpu, u64 dl, int is_valid);
 int cpudl_init(struct cpudl *cp);
 void cpudl_cleanup(struct cpudl *cp);
-#else
-#define cpudl_set(cp, cpu, dl) do { } while (0)
-#define cpudl_init() do { } while (0)
 #endif /* CONFIG_SMP */
 
 #endif /* _LINUX_CPUDL_H */
-- 
1.7.9.5

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

Re: [PATCH 08/35] UBI: Split __wl_get_peb()

2014-11-05 Thread Richard Weinberger

Am 06.11.2014 um 08:51 schrieb Artem Bityutskiy:
> On Wed, 2014-10-29 at 13:45 +0100, Richard Weinberger wrote:
>> Make it two functions, wl_get_wle() and wl_get_peb().
>> wl_get_peb() works exactly like __wl_get_peb() but wl_get_wle()
>> does not call produce_free_peb().
>> While refilling the fastmap user pool we cannot release ubi->wl_lock
>> as produce_free_peb() does.
>> Hence the fastmap logic uses now wl_get_wle().
>>
>> Signed-off-by: Richard Weinberger 
> 
> Please, re-consider naming.
> 
> The convention is that non-static function names start with ubi_wl_*.
> Static function names start with _*.
> 
> Also, please add a comment above the functions explaining what it does.

On my TODO list is already a big "enhance comments" item. :)
I'll send an updates series soon.

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

[PATCH v4 7/7] sched/deadline: Modify cpudl_find() for more cases of electing best_cpu

When a runqueue runs out of DL tasks, it may have RT tasks or non-RT
tasks or just idle. It'd be better to push the DL task to an idle cpu
or non-RT cpu if there is any.

Add idle_cpus and freert_cpus, change free_cpus to freedl_cpus in cpudl.
Add idle_enter_dl()/idle_exit_dl() to detect idle cases.
Add rt_enter_dl()/rt_exit_dl() to detect non-RT cases.
Add a set_flag parameter to cpudl_find().

Use the same thought as that in tackling RT in the former patch.

Signed-off-by: pang.xunlei 
---
 kernel/sched/cpudeadline.c |   76 
 kernel/sched/cpudeadline.h |   15 +++--
 kernel/sched/deadline.c|   38 +-
 kernel/sched/idle_task.c   |2 ++
 kernel/sched/rt.c  |7 
 kernel/sched/sched.h   |   11 +++
 6 files changed, 124 insertions(+), 25 deletions(-)

diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
index 1dd446a..cc78ebe 100644
--- a/kernel/sched/cpudeadline.c
+++ b/kernel/sched/cpudeadline.c
@@ -98,16 +98,31 @@ static inline int cpudl_maximum(struct cpudl *cp)
  * @cp: the cpudl max-heap context
  * @p: the task
  * @later_mask: a mask to fill in with the selected CPUs (not NULL)
+ * @set_flag: a flag to determine if should set the later_mask.
  *
  * Returns: (int)bool - CPUs were found
  */
 int cpudl_find(struct cpudl *cp, struct task_struct *p,
-  struct cpumask *later_mask)
+  struct cpumask *later_mask, int set_flag)
 {
const struct sched_dl_entity *dl_se = >dl;
 
cpumask_and(later_mask, cpu_active_mask, >cpus_allowed);
-   if (cpumask_and(later_mask, later_mask, cp->free_cpus)) {
+   /* sync for idle_cpus, freert_cpus, freedl_cpus */
+   smp_rmb();
+
+   if (cpumask_any_and(later_mask, cp->idle_cpus) < nr_cpu_ids) {
+   if (set_flag)
+   cpumask_and(later_mask, >cpus_allowed,
+   cp->idle_cpus);
+   return 1;
+   } else if (cpumask_any_and(later_mask, cp->freert_cpus)
+  < nr_cpu_ids) {
+   if (set_flag)
+   cpumask_and(later_mask, >cpus_allowed,
+   cp->freert_cpus);
+   return 1;
+   } else if (cpumask_and(later_mask, later_mask, cp->freedl_cpus)) {
return 1;
} else if (cpumask_and(later_mask, cpumask_of(cpudl_maximum(cp)),
   >cpus_allowed) &&
@@ -123,21 +138,39 @@ int cpudl_find(struct cpudl *cp, struct task_struct *p,
  * @cp: the cpudl max-heap context
  * @cpu: the target cpu
  * @dl: the new earliest deadline for this cpu
- *
+ * @set_flags: CPUDL_SET_XXX, CPUDL_CLEAR_XXX
  * Notes: assumes cpu_rq(cpu)->lock is locked
  *
  * Returns: (void)
  */
-void cpudl_set(struct cpudl *cp, int cpu, u64 dl, int is_valid)
+void cpudl_set(struct cpudl *cp, int cpu, u64 dl, int set_flags)
 {
int old_idx, new_cpu;
unsigned long flags;
 
WARN_ON(!cpu_present(cpu));
 
+   /* We can do this percpu operation without spinlock */
+   switch (set_flags) {
+   case CPUDL_SET_IDLE:
+   cpumask_set_cpu(cpu, cp->idle_cpus);
+   return;
+   case CPUDL_CLEAR_IDLE:
+   cpumask_clear_cpu(cpu, cp->idle_cpus);
+   return;
+   case CPUDL_SET_FREERT:
+   cpumask_set_cpu(cpu, cp->freert_cpus);
+   return;
+   case CPUDL_CLEAR_FREERT:
+   cpumask_clear_cpu(cpu, cp->freert_cpus);
+   return;
+   default:
+   break;
+   }
+
raw_spin_lock_irqsave(>lock, flags);
old_idx = cp->elements[cpu].idx;
-   if (!is_valid) {
+   if (set_flags == CPUDL_SET_FREEDL) {
/* remove item */
if (old_idx == IDX_INVALID) {
/*
@@ -159,7 +192,7 @@ void cpudl_set(struct cpudl *cp, int cpu, u64 dl, int 
is_valid)
cpudl_exchange(cp, old_idx, parent(old_idx));
old_idx = parent(old_idx);
}
-   cpumask_set_cpu(cpu, cp->free_cpus);
+   cpumask_set_cpu(cpu, cp->freedl_cpus);
cpudl_heapify(cp, old_idx);
 
goto out;
@@ -171,7 +204,7 @@ void cpudl_set(struct cpudl *cp, int cpu, u64 dl, int 
is_valid)
cp->elements[cp->size - 1].cpu = cpu;
cp->elements[cpu].idx = cp->size - 1;
cpudl_change_key(cp, cp->size - 1, dl);
-   cpumask_clear_cpu(cpu, cp->free_cpus);
+   cpumask_clear_cpu(cpu, cp->freedl_cpus);
} else {
cpudl_change_key(cp, old_idx, dl);
}
@@ -187,7 +220,7 @@ out:
  */
 void cpudl_set_freecpu(int cpu, struct cpudl *cp)
 {
-   cpumask_set_cpu(cpu, cp->free_cpus);
+   cpumask_set_cpu(cpu, cp->freedl_cpus);
 }
 
 /*
@@ -206,17 +239,30 @@ int cpudl_init(struct

[PATCH v4 1/7] sched/cpupri: Remove unnecessary definitions in cpupri.h

Actually, cpupri_set() and cpupri_init() can never be used without
CONFIG_SMP.

Signed-off-by: pang.xunlei 
---
 kernel/sched/cpupri.h |3 ---
 1 file changed, 3 deletions(-)

diff --git a/kernel/sched/cpupri.h b/kernel/sched/cpupri.h
index 6b03334..63cbb9c 100644
--- a/kernel/sched/cpupri.h
+++ b/kernel/sched/cpupri.h
@@ -26,9 +26,6 @@ int  cpupri_find(struct cpupri *cp,
 void cpupri_set(struct cpupri *cp, int cpu, int pri);
 int cpupri_init(struct cpupri *cp);
 void cpupri_cleanup(struct cpupri *cp);
-#else
-#define cpupri_set(cp, cpu, pri) do { } while (0)
-#define cpupri_init() do { } while (0)
 #endif
 
 #endif /* _LINUX_CPUPRI_H */
-- 
1.7.9.5

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

[PATCH v4 3/7] sched/rt: Optimize find_lowest_rq() to select a cache hot cpu

Add the case for iteration of sched_domains without SD_WAKE_AFFINE
flags to select a cpu, this flag may be unset through proc by users.

Signed-off-by: pang.xunlei 
---
 kernel/sched/rt.c |   18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index da6922e..49164f1 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1549,6 +1549,7 @@ static int find_lowest_rq(struct task_struct *task)
struct cpumask *lowest_mask = this_cpu_cpumask_var_ptr(local_cpu_mask);
int this_cpu = smp_processor_id();
int cpu  = task_cpu(task);
+   int cachehot_cpu = nr_cpu_ids;
 
/* Make sure the mask is initialized first */
if (unlikely(!lowest_mask))
@@ -1581,7 +1582,7 @@ static int find_lowest_rq(struct task_struct *task)
rcu_read_lock();
for_each_domain(cpu, sd) {
if (sd->flags & SD_WAKE_AFFINE) {
-   int best_cpu;
+   int wakeaffine_cpu;
 
/*
 * "this_cpu" is cheaper to preempt than a
@@ -1593,16 +1594,25 @@ static int find_lowest_rq(struct task_struct *task)
return this_cpu;
}
 
-   best_cpu = cpumask_first_and(lowest_mask,
+   wakeaffine_cpu = cpumask_first_and(lowest_mask,
 sched_domain_span(sd));
-   if (best_cpu < nr_cpu_ids) {
+   if (wakeaffine_cpu < nr_cpu_ids) {
rcu_read_unlock();
-   return best_cpu;
+   return wakeaffine_cpu;
}
+   } else {
+   /* affine domain outweighs lower level non-affine 
domain? */
+   if (cachehot_cpu >= nr_cpu_ids)
+   cachehot_cpu = cpumask_first_and(lowest_mask,
+  
sched_domain_span(sd));
}
}
rcu_read_unlock();
 
+   /* most likely cache-hot */
+   if (cachehot_cpu < nr_cpu_ids)
+   return cachehot_cpu;
+
/*
 * And finally, if there were no matches within the domains
 * just give the caller *something* to work with from the compatible
-- 
1.7.9.5

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

[PATCH v4 2/7] sched/rt: Deal with cpupri.pri_to_cpu[CPUPRI_IDLE] for idle cases

When a runqueue runs out of RT tasks, it may have non-RT tasks or
none tasks(idle). Currently, RT balance treats the two cases equally
and manipulates cpupri.pri_to_cpu[CPUPRI_NORMAL] only which may cause
problems.

For instance, 4 cpus system, non-RT task1 is running on cpu0, RT
task2 is running on cpu3, cpu1/cpu2 both are idle. Then RT task3
(usually CPU-intensive) is waken up or created on cpu3, it will
be placed to cpu0 (see find_lowest_rq()) causing task1 starving
until cfs load balance places task1 to another cpu, or even worse
if task1 is bound on cpu0. So, it would be reasonable to put task3
to cpu1 or cpu2 which is idle(even though doing this may break the
energy-saving idle state).

This patch tackles the problem by operating pri_to_cpu[CPUPRI_IDLE]
of cpupri according to the stages of idle task, so that when pushing
RT tasks through find_lowest_rq(), it will try to find one idle cpu
as the goal.

Signed-off-by: pang.xunlei 
---
 kernel/sched/idle_task.c |3 +++
 kernel/sched/rt.c|   21 +
 kernel/sched/sched.h |6 ++
 3 files changed, 30 insertions(+)

diff --git a/kernel/sched/idle_task.c b/kernel/sched/idle_task.c
index 67ad4e7..e053347 100644
--- a/kernel/sched/idle_task.c
+++ b/kernel/sched/idle_task.c
@@ -26,6 +26,8 @@ static void check_preempt_curr_idle(struct rq *rq, struct 
task_struct *p, int fl
 static struct task_struct *
 pick_next_task_idle(struct rq *rq, struct task_struct *prev)
 {
+   idle_enter_rt(rq);
+
put_prev_task(rq, prev);
 
schedstat_inc(rq, sched_goidle);
@@ -47,6 +49,7 @@ dequeue_task_idle(struct rq *rq, struct task_struct *p, int 
flags)
 
 static void put_prev_task_idle(struct rq *rq, struct task_struct *prev)
 {
+   idle_exit_rt(rq);
idle_exit_fair(rq);
rq_last_tick_reset(rq);
 }
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index d024e6c..da6922e 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -992,6 +992,27 @@ enqueue_top_rt_rq(struct rt_rq *rt_rq)
 
 #if defined CONFIG_SMP
 
+/* Set CPUPRI_IDLE bitmap for this cpu when entering idle. */
+void idle_enter_rt(struct rq *this_rq)
+{
+   struct cpupri *cp = _rq->rd->cpupri;
+   int currpri = cp->cpu_to_pri[this_rq->cpu];
+
+   BUG_ON(currpri != CPUPRI_NORMAL);
+   cpupri_set(cp, this_rq->cpu, MAX_PRIO);
+}
+
+/* Set CPUPRI_NORMAL bitmap for this cpu when exiting from idle. */
+void idle_exit_rt(struct rq *this_rq)
+{
+   struct cpupri *cp = _rq->rd->cpupri;
+   int currpri = cp->cpu_to_pri[this_rq->cpu];
+
+   /* RT tasks may be queued before, this judgement is needed. */
+   if (currpri == CPUPRI_IDLE)
+   cpupri_set(cp, this_rq->cpu, MAX_RT_PRIO);
+}
+
 static void
 inc_rt_prio_smp(struct rt_rq *rt_rq, int prio, int prev_prio)
 {
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 24156c84..cc603fa 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1162,11 +1162,17 @@ extern void update_group_capacity(struct sched_domain 
*sd, int cpu);
 
 extern void trigger_load_balance(struct rq *rq);
 
+extern void idle_enter_rt(struct rq *this_rq);
+extern void idle_exit_rt(struct rq *this_rq);
+
 extern void idle_enter_fair(struct rq *this_rq);
 extern void idle_exit_fair(struct rq *this_rq);
 
 #else
 
+static inline void idle_enter_rt(struct rq *rq) { }
+static inline void idle_exit_rt(struct rq *rq) { }
+
 static inline void idle_enter_fair(struct rq *rq) { }
 static inline void idle_exit_fair(struct rq *rq) { }
 
-- 
1.7.9.5

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

[PATCH v4 5/7] sched/deadline: Fix several problems with cpudl_find()

cpudl_find() has some problems:

1)in check_preempt_equal_dl(), called with NULL later_mask, thus
cpudl_find() doesn't check cpudl.free_cpus at all.

2)Also, the whole system isn't always overloaded with many DL tasks
in which cases all the cpu may have a DL task running, so it may
return the best cpu, because we only return the first maximum deadline
cpu(is there a need to iterate the same deadline value to find more
different cpus if possible?).
So it may be reasonable to change the return value of cpudl_find()
to a bool type, because it isn't always the best cpu actually which
can be better determined in find_later_rq() via sched_domain topology.

This patch adds a new cpudl_set_freecpu() to initialize cpudl.free_cpus
when rq_attach_root(), and modifies cpudl_find() and all its call sites
in order to address these problems.

Signed-off-by: pang.xunlei 
---
 kernel/sched/core.c|2 ++
 kernel/sched/cpudeadline.c |   41 ++---
 kernel/sched/cpudeadline.h |1 +
 kernel/sched/deadline.c|   32 +++-
 4 files changed, 40 insertions(+), 36 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 240157c..17d5778 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5584,6 +5584,8 @@ static void rq_attach_root(struct rq *rq, struct 
root_domain *rd)
rq->rd = rd;
 
cpumask_set_cpu(rq->cpu, rd->span);
+   cpudl_set_freecpu(rq->cpu, >cpudl);
+
if (cpumask_test_cpu(rq->cpu, cpu_active_mask))
set_rq_online(rq);
 
diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
index 539ca3c..1dd446a 100644
--- a/kernel/sched/cpudeadline.c
+++ b/kernel/sched/cpudeadline.c
@@ -97,30 +97,25 @@ static inline int cpudl_maximum(struct cpudl *cp)
  * cpudl_find - find the best (later-dl) CPU in the system
  * @cp: the cpudl max-heap context
  * @p: the task
- * @later_mask: a mask to fill in with the selected CPUs (or NULL)
+ * @later_mask: a mask to fill in with the selected CPUs (not NULL)
  *
- * Returns: int - best CPU (heap maximum if suitable)
+ * Returns: (int)bool - CPUs were found
  */
 int cpudl_find(struct cpudl *cp, struct task_struct *p,
   struct cpumask *later_mask)
 {
-   int best_cpu = -1;
const struct sched_dl_entity *dl_se = >dl;
 
-   if (later_mask && cpumask_and(later_mask, later_mask, cp->free_cpus)) {
-   best_cpu = cpumask_any(later_mask);
-   goto out;
-   } else if (cpumask_test_cpu(cpudl_maximum(cp), >cpus_allowed) &&
-   dl_time_before(dl_se->deadline, cp->elements[0].dl)) {
-   best_cpu = cpudl_maximum(cp);
-   if (later_mask)
-   cpumask_set_cpu(best_cpu, later_mask);
+   cpumask_and(later_mask, cpu_active_mask, >cpus_allowed);
+   if (cpumask_and(later_mask, later_mask, cp->free_cpus)) {
+   return 1;
+   } else if (cpumask_and(later_mask, cpumask_of(cpudl_maximum(cp)),
+  >cpus_allowed) &&
+  dl_time_before(dl_se->deadline, cp->elements[0].dl)) {
+   return 1;
}
 
-out:
-   WARN_ON(best_cpu != -1 && !cpu_present(best_cpu));
-
-   return best_cpu;
+   return 0;
 }
 
 /*
@@ -165,7 +160,7 @@ void cpudl_set(struct cpudl *cp, int cpu, u64 dl, int 
is_valid)
old_idx = parent(old_idx);
}
cpumask_set_cpu(cpu, cp->free_cpus);
-cpudl_heapify(cp, old_idx);
+   cpudl_heapify(cp, old_idx);
 
goto out;
}
@@ -186,6 +181,16 @@ out:
 }
 
 /*
+ * cpudl_set_freecpu - Set the cpudl.free_cpus
+ * @cpu: rd attached cpu
+ * @cp: the cpudl max-heap context
+ */
+void cpudl_set_freecpu(int cpu, struct cpudl *cp)
+{
+   cpumask_set_cpu(cpu, cp->free_cpus);
+}
+
+/*
  * cpudl_init - initialize the cpudl structure
  * @cp: the cpudl max-heap context
  */
@@ -203,7 +208,7 @@ int cpudl_init(struct cpudl *cp)
if (!cp->elements)
return -ENOMEM;
 
-   if (!alloc_cpumask_var(>free_cpus, GFP_KERNEL)) {
+   if (!zalloc_cpumask_var(>free_cpus, GFP_KERNEL)) {
kfree(cp->elements);
return -ENOMEM;
}
@@ -211,8 +216,6 @@ int cpudl_init(struct cpudl *cp)
for_each_possible_cpu(i)
cp->elements[i].idx = IDX_INVALID;
 
-   cpumask_setall(cp->free_cpus);
-
return 0;
 }
 
diff --git a/kernel/sched/cpudeadline.h b/kernel/sched/cpudeadline.h
index 020039b..71478fc 100644
--- a/kernel/sched/cpudeadline.h
+++ b/kernel/sched/cpudeadline.h
@@ -25,6 +25,7 @@ int cpudl_find(struct cpudl *cp, struct task_struct *p,
 void cpudl_set(struct cpudl *cp, int cpu, u64 dl, int is_valid);
 int cpudl_init(struct cpudl *cp);
 void cpudl_cleanup(struct cpudl *cp);
+void cpudl_set_freecpu(int cpu, struct cpudl *cp);
 #endif /* CONFIG_SMP */
 
 #endif /* _LINUX_CPUDL_H

[PATCH v4 6/7] sched/deadline: Optimize find_later_rq() to select a cache hot cpu

Add the case for iteration of sched_domains without SD_WAKE_AFFINE
flags to select a cpu, this flag may be unset through proc by users.

Signed-off-by: pang.xunlei 
---
 kernel/sched/deadline.c |   19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index e0e8013..01d3aaab 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1177,6 +1177,7 @@ static int find_later_rq(struct task_struct *task)
struct cpumask *later_mask = 
this_cpu_cpumask_var_ptr(local_cpu_mask_dl);
int this_cpu = smp_processor_id();
int cpu = task_cpu(task);
+   int cachehot_cpu = nr_cpu_ids;
 
/* Make sure the mask is initialized first */
if (unlikely(!later_mask))
@@ -1219,7 +1220,7 @@ static int find_later_rq(struct task_struct *task)
 
rcu_read_lock();
for_each_domain(cpu, sd) {
-   int best_cpu;
+   int wakeaffine_cpu;
if (sd->flags & SD_WAKE_AFFINE) {
 
/*
@@ -1232,16 +1233,24 @@ static int find_later_rq(struct task_struct *task)
return this_cpu;
}
 
-   best_cpu = cpumask_first_and(later_mask,
-   
sched_domain_span(sd));
-   if (best_cpu < nr_cpu_ids) {
+   wakeaffine_cpu = cpumask_first_and(later_mask,
+sched_domain_span(sd));
+   if (wakeaffine_cpu < nr_cpu_ids) {
rcu_read_unlock();
-   return best_cpu;
+   return wakeaffine_cpu;
}
+   } else {
+   if (cachehot_cpu >= nr_cpu_ids)
+   cachehot_cpu = cpumask_first_and(later_mask,
+  
sched_domain_span(sd));
}
}
rcu_read_unlock();
 
+   /* Most likely cache-hot */
+   if (cachehot_cpu < nr_cpu_ids)
+   return cachehot_cpu;
+
/*
 * At this point, all our guesses failed, we just return
 * 'something', and let the caller sort the things out.
-- 
1.7.9.5

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

Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO

2014-11-05 Thread Takao Indoh

(2014/11/06 11:11), Li, ZhenHua wrote:
> This patch does the same thing as you said in your mail.
> It should work, I have tested on my HP huge system.

Yep, I also confirmed it worked.

BTW, I found another problem. When I tested your patches with 3.17
kernel, iommu initialization failed with the following message.

IOMMU intel_iommu_in_crashdump = true
IOMMU Skip disabling iommu hardware translations
IOMMU Copying translate tables from panicked kernel
IOMMU: Copy translate tables failed
IOMMU: dmar init failed


I found that oldcopy() from physical address 0x15000 was failed.
oldcopy() copies data using ioremap, and ioremap for the memory region
around 0x15000 does not work because it is already mapped to virtual
space.


static void __iomem *__ioremap_caller(resource_size_t phys_addr,
unsigned long size, unsigned long prot_val, void *caller)
{
(snip)
/*
 * Don't allow anybody to remap normal RAM that we're using..
 */
pfn  = phys_addr >> PAGE_SHIFT;
last_pfn = last_addr >> PAGE_SHIFT;
if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
  __ioremap_check_ram) == 1)
return NULL;
   


I'm not sure how we should handle this, but as far as I tested the
following fix works.

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 3a9e7b8..8d2bd23 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4871,7 +4871,12 @@ static int oldcopy(void *to, void *from, int size)

pfn = ((unsigned long) from) >> VTD_PAGE_SHIFT;
offset = ((unsigned long) from) & (~VTD_PAGE_MASK);
-   ret = copy_oldmem_page(pfn, buf, csize, offset, userbuf);
+
+   if (page_is_ram(pfn)) {
+   memcpy(buf, pfn_to_kaddr(pfn) + offset, csize);
+   ret = size;
+   } else
+   ret = copy_oldmem_page(pfn, buf, csize, offset, userbuf);

return (int) ret;
 }


Thanks,
Takao Indoh


> 
> On 11/06/2014 09:48 AM, Takao Indoh wrote:
>> (2014/11/06 10:35), Li, ZhenHua wrote:
>>> Yes, that's it. The function context_set_address_root does not set the
>>> address root correctly.
>>>
>>> I have created another patch for it, see
>>> https://lkml.org/lkml/2014/11/5/43
>>
>> Oh, ok. I'll try again with this patch, thank you.
>>
>> Thanks,
>> Takao Indoh
>>
>>>
>>> Thanks
>>> Zhenhua
>>>
>>> On 11/06/2014 09:31 AM, Takao Indoh wrote:
 Hi Zhenhua, Baoquan,

 (2014/10/22 19:05), Baoquan He wrote:
> Hi Zhenhua,
>
> I tested your latest patch on 3.18.0-rc1+, there are still some dmar
> errors. I remember it worked well with Bill's original patchset.

 This should be a problem in copy_context_entry().

> +static int copy_context_entry(struct intel_iommu *iommu, u32 bus, u32 
> devfn,
> +   void *ppap, struct context_entry *ce)
> +{
> + int ret = 0;/* Integer Return Code */
> + u32 shift = 0;  /* bits to shift page_addr  */
> + u64 page_addr = 0;  /* Address of translated page */
> + struct dma_pte *pgt_old_phys;   /* Adr(page_table in the old kernel) */
> + struct dma_pte *pgt_new_phys;   /* Adr(page_table in the new kernel) */
> + u8  t;  /* Translation-type from context */
> + u8  aw; /* Address-width from context */
> + u32 aw_shift[8] = {
> + 12+9+9, /* [000b] 30-bit AGAW (2-level page table) */
> + 12+9+9+9,   /* [001b] 39-bit AGAW (3-level page table) */
> + 12+9+9+9+9, /* [010b] 48-bit AGAW (4-level page table) */
> + 12+9+9+9+9+9,   /* [011b] 57-bit AGAW (5-level page table) */
> + 12+9+9+9+9+9+9, /* [100b] 64-bit AGAW (6-level page table) */
> + 0,  /* [111b] Reserved */
> + 0,  /* [110b] Reserved */
> + 0,  /* [111b] Reserved */
> + };
> +
> + struct domain_values_entry *dve = NULL;
> +
> +
> + if (!context_present(ce)) { /* If (context not present) */
> + ret = RET_CCE_NOT_PRESENT;  /* Skip it */
> + goto exit;
> + }
> +
> + t = context_translation_type(ce);
> +
> + /* If we have seen this domain-id before on this iommu,
> +  * give this context the same page-tables and we are done.
> +  */
> + list_for_each_entry(dve, _values_list[iommu->seq_id], link) {
> + if (dve->did == (int) context_domain_id(ce)) {
> + switch (t) {
> + case 0: /* page tables */
> + case 1: /* page tables */
> + context_set_address_root(ce,
> + virt_to_phys(dve->pgd));

 Here, in context_set_address_root(), the new address is set like this:

Re: [PATCH 08/35] UBI: Split __wl_get_peb()

2014-11-05 Thread Artem Bityutskiy

On Wed, 2014-10-29 at 13:45 +0100, Richard Weinberger wrote:
> Make it two functions, wl_get_wle() and wl_get_peb().
> wl_get_peb() works exactly like __wl_get_peb() but wl_get_wle()
> does not call produce_free_peb().
> While refilling the fastmap user pool we cannot release ubi->wl_lock
> as produce_free_peb() does.
> Hence the fastmap logic uses now wl_get_wle().
> 
> Signed-off-by: Richard Weinberger 

Please, re-consider naming.

The convention is that non-static function names start with ubi_wl_*.
Static function names start with _*.

Also, please add a comment above the functions explaining what it does.

Artem.


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

Re: [PATCH 0/4] Touchscreen performance related fixes

2014-11-05 Thread Vignesh R

On Monday 03 November 2014 11:39 PM, Richard Cochran wrote:
> On Mon, Oct 27, 2014 at 04:38:27PM +0530, Vignesh R wrote:
>> This series of patches fix TSC defects related to lag in touchscreen
>> performance and cursor jump at touch release. The lag was result of
>> udelay in TSC interrupt handler. Cursor jump due to false pen-up event.
>> The patches implement Advisory 1.0.31 in silicon errata of am335x-evm
>> to avoid false pen-up events and remove udelay.
> 
> That advisory has two workarounds. You have chosen the second one?

Work around one. Hence 5 wire design is not broken.

> 
> The text of the second workaround says it only works on 4 wire setups,
> so I wonder how 5 wire designs will be affected.
> 
>> The advisory says to use
>> steps 1 to 4 for ADC and 5 to 16 for TSC (assuming 4 wire TSC and 4 channel
>> ADC).
> 
> No, it doesn't say that. (sprz360f.pdf)

The pen up event detection happens immediately after charge step. Hence,
interchanging ADC and TSC steps makes sure that sampling of touch
co-ordinates and pen events are done one after the other. This
workaround was suggested by internal hardware folks. Earlier ADC steps
intervened between sampling of co-ordinates and pen event detection
which is not desirable.

> 
>> Further the X co-ordinate must be the last one to be sampled just
>> before charge step. The first two patches implement the required changes. 
> 
> FWIW, I implemented the first workaround and removed the udelay not
> too long ago. Like Sebastian, I saw the TSC unit hang after about
> 5 interrupts when running with the workaround.
> 
> Did you test you patch for very long?

Yes, I tested for about 20 interrupts and I didn't see any hang.
This patch series does not just implement workaround but also does some
minor changes, such as interchanging ADC and TSC steps etc, which makes
TSC driver more robust. Let me know if you encounter any issues with my
patch series.

Regards
Vignesh

> 
> Thanks,
> Richard
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sysfs: driver core: Fix glue dir race condition

2014-11-05 Thread Yijing Wang

There is a race condition when removing glue directory.
It can be reproduced in following test:

path 1: Add first child device
device_add()
get_device_parent()
/*find parent from glue_dirs.list*/
list_for_each_entry(k, >class->p->glue_dirs.list, entry)
if (k->parent == parent_kobj) {
kobj = kobject_get(k);
break;
}

class_dir_create_and_add()

path2: Remove last child device under glue dir
device_del()
cleanup_device_parent()
cleanup_glue_dir()
kobject_put(glue_dir);

If path2 has been called cleanup_glue_dir(), but not
call kobject_put(glue_dir), the glue dir is still
in parent's kset list. Meanwhile, path1 find the glue
dir from the glue_dirs.list. Path2 may release glue dir
before path1 call kobject_get(). So kernel will report
the warning and bug_on.

This fix keep glue dir around once it created suggested
by Tejun Heo.

The following calltrace is captured in kernel 3.4, but
the latest kernel still has this bug.

-
<4>[ 3965.441471] WARNING: at ...include/linux/kref.h:41 kobject_get+0x33/0x40()
<4>[ 3965.441474] Hardware name: Romley
<4>[ 3965.441475] Modules linked in: isd_iop(O) isd_xda(O)...
...
<4>[ 3965.441605] Call Trace:
<4>[ 3965.441611]  [] warn_slowpath_common+0x7a/0xb0
<4>[ 3965.441615]  [] warn_slowpath_null+0x15/0x20
<4>[ 3965.441618]  [] kobject_get+0x33/0x40
<4>[ 3965.441624]  [] get_device_parent.isra.11+0x135/0x1f0
<4>[ 3965.441627]  [] device_add+0xd4/0x6d0
<4>[ 3965.441631]  [] ? dev_set_name+0x3c/0x40

<2>[ 3965.441912] kernel BUG at /fs/sysfs/group.c:65!
<4>[ 3965.441915] invalid opcode:  [#1] SMP
...
<4>[ 3965.686743]  [] sysfs_create_group+0xe/0x10
<4>[ 3965.686748]  [] blk_trace_init_sysfs+0x14/0x20
<4>[ 3965.686753]  [] blk_register_queue+0x3b/0x120
<4>[ 3965.686756]  [] add_disk+0x1cc/0x490

---

Signed-off-by: Yijing Wang 
Signed-off-by: Weng Meiling 
Cc:  #3.4+
---
 drivers/base/core.c |   21 +
 1 files changed, 1 insertions(+), 20 deletions(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 14d1629..5b7a3e9 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -761,7 +761,7 @@ static struct kobject *get_device_parent(struct device *dev,
spin_lock(>class->p->glue_dirs.list_lock);
list_for_each_entry(k, >class->p->glue_dirs.list, entry)
if (k->parent == parent_kobj) {
-   kobj = kobject_get(k);
+   kobj = k;
break;
}
spin_unlock(>class->p->glue_dirs.list_lock);
@@ -786,21 +786,6 @@ static struct kobject *get_device_parent(struct device 
*dev,
return NULL;
 }
 
-static void cleanup_glue_dir(struct device *dev, struct kobject *glue_dir)
-{
-   /* see if we live in a "glue" directory */
-   if (!glue_dir || !dev->class ||
-   glue_dir->kset != >class->p->glue_dirs)
-   return;
-
-   kobject_put(glue_dir);
-}
-
-static void cleanup_device_parent(struct device *dev)
-{
-   cleanup_glue_dir(dev, dev->kobj.parent);
-}
-
 static int device_add_class_symlinks(struct device *dev)
 {
int error;
@@ -1094,7 +1079,6 @@ done:
kobject_uevent(>kobj, KOBJ_REMOVE);
kobject_del(>kobj);
  Error:
-   cleanup_device_parent(dev);
if (parent)
put_device(parent);
 name_error:
@@ -1215,7 +1199,6 @@ void device_del(struct device *dev)
blocking_notifier_call_chain(>bus->p->bus_notifier,
 BUS_NOTIFY_REMOVED_DEVICE, dev);
kobject_uevent(>kobj, KOBJ_REMOVE);
-   cleanup_device_parent(dev);
kobject_del(>kobj);
put_device(parent);
 }
@@ -1873,7 +1856,6 @@ int device_move(struct device *dev, struct device 
*new_parent,
 __func__, new_parent ? dev_name(new_parent) : "");
error = kobject_move(>kobj, new_parent_kobj);
if (error) {
-   cleanup_glue_dir(dev, new_parent_kobj);
put_device(new_parent);
goto out;
}
@@ -1902,7 +1884,6 @@ int device_move(struct device *dev, struct device 
*new_parent,
set_dev_node(dev, 
dev_to_node(old_parent));
}
}
-   cleanup_glue_dir(dev, new_parent_kobj);
put_device(new_parent);
goto out;
}
-- 
1.7.1

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

Re: [PATCH 1/1] perf tools: perf diff for different binaries

2014-11-05 Thread Namhyung Kim

Hi Kan,

On Thu, Nov 6, 2014 at 2:28 AM, Liang, Kan  wrote:
>
>> Hi Kan,
>>
>> On Tue, 4 Nov 2014 17:07:43 +, Kan Liang wrote:
>> >> What about setting the
>> >> sort_sym.se_collapse in data_process() so that hists__match() can use
>> >> symbol names?
>> >
>> > Yes, we can set it if we only do function level diff. But I'd like to
>> > keep both. So I defined two sort keys.
>> > "symbol" means "symbol address executed at the time of sample "
>> > "symbol_name" means "name of function executed at the time of
>> sample"
>>
>> Hmm.. I don't think the symbol sort key provides the instruction level diff
>> that you want.  If it finds a symbol it just use the start address of the
>> symbol, not the exact address of the sample.  Am I missing something?
>>
>
> No, the meaning of symbol in perf diff is different as in perf report. It uses
> the exact address of the sample.

Hmm.. are you sure?  I think it uses same code..


>
> Here is current perf diff result and objdump fragment of the first binary.
> You can see the exact address of the sample in function f3 was used, not the
> start address.
> 33.55%  [unknown]  [.] 0x00400554
> 48.13%  [unknown]  [.] 0x0040056b

But I think it's because it failed to find a symbol (f3) for some
reason.  The symbol sort key will use the ip address only if it didn't
find a symbol for the address.  Please see sort__sym_cmp (and
_sort__sym_cmp too).

Thanks,
Namhyung


>
> [perf-test]#./perf diff -s dso,symbol --compute ratio ../../../v1_1_6perf.data
> ../../../v2_1_7perf.data
> # Event 'cycles'
> #
> # Baseline   Ratio  Shared Object  Symbol
> #   ..  .  .
> #
> [kernel.kallsyms]  [k] __update_cpu_load
> [kernel.kallsyms]  [k] mod_timer
>  0.01%  [kernel.kallsyms]  [k] native_write_msr_safe
>  0.01%  [kernel.kallsyms]  [k] notifier_call_chain
>  0.01%  [kernel.kallsyms]  [k] perf_event_task_tick
> [kernel.kallsyms]  [k] rt_mutex_slowlock
>  0.01%  [kernel.kallsyms]  [k] run_posix_cpu_timers
>  0.01%  [kernel.kallsyms]  [k] run_timer_softirq
>  0.01%  [kernel.kallsyms]  [k] trigger_load_balance
>  0.01%  [kernel.kallsyms]  [k] update_vsyscall
> [kernel.kallsyms]  [k] wait_for_common
> [kernel.kallsyms]  [k] 0x0028482a
>  0.05%  [unknown]  [.] 0x00400540
>  0.04%  [unknown]  [.] 0x00400541
>  0.03%  [unknown]  [.] 0x0040054b
>  0.04%  [unknown]  [.] 0x00400552
> 33.55%  [unknown]  [.] 0x00400554
>  1.22%  [unknown]  [.] 0x0040055a
>  8.00%  [unknown]  [.] 0x0040055e
>  0.02%  [unknown]  [.] 0x00400562
>  8.41%  [unknown]  [.] 0x00400564
> 48.13%  [unknown]  [.] 0x0040056b
>  0.16%  [unknown]  [.] 0x00400570
>  0.17%  [unknown]  [.] 0x00400571
> [unknown]  [.] 0x00400580
> [unknown]  [.] 0x00400581
>  0.01%  [unknown]  [.] 0x00400583
>  0.01%  [unknown]  [.] 0x00400588
> [unknown]  [.] 0x0040058b
>  0.01% 1240.990221  [unknown]  [.] 0x0040058d
> [unknown]  [.] 0x00400590
>  0.06%  [unknown]  [.] 0x00400591
> [unknown]  [.] 0x00400593
>  0.04%  [unknown]  [.] 0x00400595
>  0.01% 1240.603148  [unknown]  [.] 0x00400597
> [unknown]  [.] 0x0040059b
> [unknown]  [.] 0x0040059d
> [unknown]  [.] 0x004005a1
> [unknown]  [.] 0x004005a5
> [unknown]  [.] 0x004005a7
> [unknown]  [.] 0x004005a8
> [unknown]  [.] 0x004005aa
> [unknown]  [.] 0x004005ba
> [unknown]  [.] 0x004005bf
> [unknown]  [.] 0x004005c4
>

Re: [PATCH] drm/panel: ld9040: Update calls to gpiod_get*()

2014-11-05 Thread Andrzej Hajda

On 11/06/2014 04:32 AM, Alexandre Courbot wrote:
> On Thu, Oct 23, 2014 at 6:45 PM, Andrzej Hajda  wrote:
>> On 10/23/2014 10:16 AM, Alexandre Courbot wrote:
>>> Add the new flags argument to calls of (devm_)gpiod_get*() and
>>> remove any direction setting code afterwards.
>>>
>>> Currently both forms (with or without the flags argument)
>>> are valid thanks to transitional macros in
>>> . These macros will be removed once
>>> all consumers are updated and the flags argument will become
>>> compulsary.
>>>
>>> Signed-off-by: Alexandre Courbot 
>> It needs patch "gpio: Fix gpio direction flags not getting set" to work
>> correctly. It is not yet present in drm-next. Beside this:
>>
>> Acked-by: Andrzej Hajda 
> The required patch is now merged, can we go on with this patch?
>
Yes, for both panels. Thanks.

Regards
Andrzej

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv4 6/6] usb: dwc3: host: convey the PHYs to xhci

2014-11-05 Thread Kishon Vijay Abraham I

Hi Felipe,

On Friday 17 October 2014 08:09 PM, Heikki Krogerus wrote:
> On some platforms a PHY may need to be handled also in the
> host controller driver. Exynos5420 SoC requires some "PHY
> tuning" based on the USB speed. This patch delivers dwc3's
> PHYs to the xhci platform device when it's created.
> 
> Signed-off-by: Heikki Krogerus 
> Tested-by: Vivek Gautam 
> Acked-by: Felipe Balbi 

Already see you acked-by, so I'm queueing this in my linux-phy tree.

Thanks
Kishon
> ---
>  drivers/usb/dwc3/host.c | 22 --
>  1 file changed, 16 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
> index dcb8ca0..12bfd3c 100644
> --- a/drivers/usb/dwc3/host.c
> +++ b/drivers/usb/dwc3/host.c
> @@ -29,8 +29,7 @@ int dwc3_host_init(struct dwc3 *dwc)
>   xhci = platform_device_alloc("xhci-hcd", PLATFORM_DEVID_AUTO);
>   if (!xhci) {
>   dev_err(dwc->dev, "couldn't allocate xHCI device\n");
> - ret = -ENOMEM;
> - goto err0;
> + return -ENOMEM;
>   }
>  
>   dma_set_coherent_mask(>dev, dwc->dev->coherent_dma_mask);
> @@ -60,22 +59,33 @@ int dwc3_host_init(struct dwc3 *dwc)
>   goto err1;
>   }
>  
> + phy_create_lookup(dwc->usb2_generic_phy, "usb2-phy",
> +   dev_name(>dev));
> + phy_create_lookup(dwc->usb3_generic_phy, "usb3-phy",
> +   dev_name(>dev));
> +
>   ret = platform_device_add(xhci);
>   if (ret) {
>   dev_err(dwc->dev, "failed to register xHCI device\n");
> - goto err1;
> + goto err2;
>   }
>  
>   return 0;
> -
> +err2:
> + phy_remove_lookup(dwc->usb2_generic_phy, "usb2-phy",
> +   dev_name(>dev));
> + phy_remove_lookup(dwc->usb3_generic_phy, "usb3-phy",
> +   dev_name(>dev));
>  err1:
>   platform_device_put(xhci);
> -
> -err0:
>   return ret;
>  }
>  
>  void dwc3_host_exit(struct dwc3 *dwc)
>  {
> + phy_remove_lookup(dwc->usb2_generic_phy, "usb2-phy",
> +   dev_name(>xhci->dev));
> + phy_remove_lookup(dwc->usb3_generic_phy, "usb3-phy",
> +   dev_name(>xhci->dev));
>   platform_device_unregister(dwc->xhci);
>  }
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[LKP] [jbd2] cc97f1a7c7e: +87.2% fsmark.files_per_sec

2014-11-05 Thread LKP

FYI, we noticed the below good changes on

commit cc97f1a7c7eed970e674b84be0e68f479c80228d ("jbd2: avoid pointless 
scanning of checkpoint lists")


844749764b416ee2  cc97f1a7c7eed970e674b84be0  testbox/testcase/testparams
  --  ---
 %stddev %change %stddev
 \  |\  
  6026 ±  1% +87.2%  11283 ±  2%  
ivb43/fsmark/performance-1x-1t-1BRD_32G-ext4-4K-4G-fsyncBeforeClose-1fpd
  6026   +87.2%  11283GEO-MEAN fsmark.files_per_sec

844749764b416ee2  cc97f1a7c7eed970e674b84be0  
  --  
  86294457 ±  7% -99.0% 822113 ± 25%  
ivb43/fsmark/performance-1x-1t-1BRD_32G-ext4-4K-4G-fsyncBeforeClose-1fpd
  86294457   -99.0% 822113GEO-MEAN cpuidle.C1E-IVT.time

844749764b416ee2  cc97f1a7c7eed970e674b84be0  
  --  
795159 ±  5% -99.9%931 ± 16%  
ivb43/fsmark/performance-1x-1t-1BRD_32G-ext4-4K-4G-fsyncBeforeClose-1fpd
795159   -99.9%931GEO-MEAN cpuidle.C1E-IVT.usage

844749764b416ee2  cc97f1a7c7eed970e674b84be0  
  --  
 13012 ± 36% -68.0%   4169 ± 45%  
ivb43/fsmark/performance-1x-1t-1BRD_32G-ext4-4K-4G-fsyncBeforeClose-1fpd
 13012   -68.0%   4168GEO-MEAN 
sched_debug.cpu#15.sched_goidle

844749764b416ee2  cc97f1a7c7eed970e674b84be0  
  --  
 26135 ± 36% -67.9%   8395 ± 45%  
ivb43/fsmark/performance-1x-1t-1BRD_32G-ext4-4K-4G-fsyncBeforeClose-1fpd
 26135   -67.9%   8395GEO-MEAN 
sched_debug.cpu#15.nr_switches

844749764b416ee2  cc97f1a7c7eed970e674b84be0  
  --  
   890 ± 36%+154.2%   2263 ± 29%  
ivb43/fsmark/performance-1x-1t-1BRD_32G-ext4-4K-4G-fsyncBeforeClose-1fpd
   890  +154.2%   2263GEO-MEAN 
sched_debug.cfs_rq[39]:/.tg_load_contrib

844749764b416ee2  cc97f1a7c7eed970e674b84be0  
  --  
 13688 ± 44% -63.9%   4936 ± 28%  
ivb43/fsmark/performance-1x-1t-1BRD_32G-ext4-4K-4G-fsyncBeforeClose-1fpd
 13688   -63.9%   4936GEO-MEAN 
sched_debug.cpu#14.ttwu_count

844749764b416ee2  cc97f1a7c7eed970e674b84be0  
  --  
  1792 ± 24% -64.5%636 ± 37%  
ivb43/fsmark/performance-1x-1t-1BRD_32G-ext4-4K-4G-fsyncBeforeClose-1fpd
  1792   -64.5%636GEO-MEAN cpuidle.C3-IVT.usage

844749764b416ee2  cc97f1a7c7eed970e674b84be0  
  --  
  2118 ± 43%+129.9%   4869 ± 23%  
ivb43/fsmark/performance-1x-1t-1BRD_32G-ext4-4K-4G-fsyncBeforeClose-1fpd
  2118  +129.9%   4869GEO-MEAN 
sched_debug.cfs_rq[25]:/.blocked_load_avg

844749764b416ee2  cc97f1a7c7eed970e674b84be0  
  --  
244970 ±  2% -52.1% 117231 ±  1%  
ivb43/fsmark/performance-1x-1t-1BRD_32G-ext4-4K-4G-fsyncBeforeClose-1fpd
244970   -52.1% 117231GEO-MEAN cpuidle.C6-IVT.usage

844749764b416ee2  cc97f1a7c7eed970e674b84be0  
  --  
  2175 ± 41%+126.3%   4923 ± 24%  
ivb43/fsmark/performance-1x-1t-1BRD_32G-ext4-4K-4G-fsyncBeforeClose-1fpd
  2175  +126.3%   4922GEO-MEAN 
sched_debug.cfs_rq[25]:/.tg_load_contrib

844749764b416ee2  cc97f1a7c7eed970e674b84be0  
  --  
 14419 ± 28% -58.4%   5996 ± 17%  
ivb43/fsmark/performance-1x-1t-1BRD_32G-ext4-4K-4G-fsyncBeforeClose-1fpd
 14419   -58.4%   5996GEO-MEAN 
sched_debug.cpu#14.sched_goidle

844749764b416ee2  cc97f1a7c7eed970e674b84be0  
  --  
 32555 ± 25% -54.4%  14859 ± 17%  
ivb43/fsmark/performance-1x-1t-1BRD_32G-ext4-4K-4G-fsyncBeforeClose-1fpd
 32555   -54.4%  14859GEO-MEAN 
sched_debug.cpu#14.nr_switches

844749764b416ee2  cc97f1a7c7eed970e674b84be0  
  --  
107876 ± 13% +72.7% 186283 ±  3%  
ivb43/fsmark/performance-1x-1t-1BRD_32G-ext4-4K-4G-fsyncBeforeClose-1fpd
107876   +72.7% 186283GEO-MEAN proc-vmstat.nr_dirty

844749764b416ee2  cc97f1a7c7eed970e674b84be0  
  --  
 7.587e+09 ±  1% -46.5%  4.059e+09 ±  2%  
ivb43/fsmark/performance-1x-1t-1BRD_32G-ext4-4K-4G-fsyncBeforeClose-1fpd
 7.587e+09   -46.5%  4.059e+09GEO-MEAN cpuidle.C6-IVT.time

844749764b416ee2  cc97f1a7c7eed970e674b84be0  
  --  
432452 ± 13% +72.2% 744607 ±  3%  
ivb43/fsmark/performance-1x-1t-1BRD_32G-ext4-4K-4G-fsyncBeforeClose-1fpd

[PATCH] sched/deadline: fix rq->dl.pushable_tasks bug in push_dl_task()

2014-11-05 Thread Wanpeng Li

Do not call dequeue_pushable_dl_task() when failing to push an eligible
task, as it remains pushable, merely not at this particular moment. 
Actually the patch is the same behavior as commit 311e800e16f6 ("sched, 
rt: Fix rq->rt.pushable_tasks bug in push_rt_task()" in -rt side.

Signed-off-by: Wanpeng Li 
---
 kernel/sched/deadline.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index f3d7776..00324af 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1331,6 +1331,7 @@ static int push_dl_task(struct rq *rq)
 {
struct task_struct *next_task;
struct rq *later_rq;
+   int ret = 0;
 
if (!rq->dl.overloaded)
return 0;
@@ -1376,7 +1377,6 @@ retry:
 * The task is still there. We don't try
 * again, some other cpu will pull it when ready.
 */
-   dequeue_pushable_dl_task(rq, next_task);
goto out;
}
 
@@ -1392,6 +1392,7 @@ retry:
deactivate_task(rq, next_task, 0);
set_task_cpu(next_task, later_rq->cpu);
activate_task(later_rq, next_task, 0);
+   ret = 1;
 
resched_curr(later_rq);
 
@@ -1400,7 +1401,7 @@ retry:
 out:
put_task_struct(next_task);
 
-   return 1;
+   return ret;
 }
 
 static void push_dl_tasks(struct rq *rq)
-- 
1.9.1

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

[seccomp] kernel BUG at kernel/fork.c:1102!

2014-11-05 Thread Fengguang Wu

Greetings,

0day kernel testing robot got the below dmesg and the first bad commit is

commit dbd952127d11bb44a4ea30b08cc60531b6a23d71
Author: Kees Cook 
AuthorDate: Fri Jun 27 15:18:48 2014 -0700
Commit: Kees Cook 
CommitDate: Fri Jul 18 12:13:39 2014 -0700

seccomp: introduce writer locking

Normally, task_struct.seccomp.filter is only ever read or modified by
the task that owns it (current). This property aids in fast access
during system call filtering as read access is lockless.

Updating the pointer from another task, however, opens up race
conditions. To allow cross-thread filter pointer updates, writes to the
seccomp fields are now protected by the sighand spinlock (which is shared
by all threads in the thread group). Read access remains lockless because
pointer updates themselves are atomic.  However, writes (or cloning)
often entail additional checking (like maximum instruction counts)
which require locking to perform safely.

In the case of cloning threads, the child is invisible to the system
until it enters the task list. To make sure a child can't be cloned from
a thread and left in a prior state, seccomp duplication is additionally
moved under the sighand lock. Then parent and child are certain have
the same seccomp state when they exit the lock.

Based on patches by Will Drewry and David Drysdale.

Signed-off-by: Kees Cook 
Reviewed-by: Oleg Nesterov 
Reviewed-by: Andy Lutomirski 

+--++++
|  | c8bee430dc | dbd952127d | 
c2426d2ad5 |
+--++++
| boot_successes   | 60 | 0  | 0
  |
| boot_failures| 0  | 20 | 11   
  |
| kernel_BUG_at_kernel/fork.c  | 0  | 20 | 11   
  |
| invalid_opcode   | 0  | 20 | 11   
  |
| EIP_is_at_copy_process   | 0  | 20 | 11   
  |
| Kernel_panic-not_syncing:Fatal_exception | 0  | 20 | 11   
  |
| backtrace:do_fork| 0  | 20 | 11   
  |
+--++++

[0.023060] CPU: Intel Core Processor (Haswell) (fam: 06, model: 3c, 
stepping: 01)
[0.046204] ftrace: allocating 39817 entries in 78 pages
[0.070150] [ cut here ]
[0.071335] kernel BUG at kernel/fork.c:1102!
[0.072727] invalid opcode:  [#1] PREEMPT 
[0.074202] CPU: 0 PID: 0 Comm: swapper Not tainted 
3.16.0-rc5-00031-gdbd95212 #339
[0.076276] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[0.077594] task: c2832140 ti: c2826000 task.ti: c2826000
[0.078816] EIP: 0060:[] EFLAGS: 00210046 CPU: 0
[0.08] EIP is at copy_process+0x1720/0x1860
[0.08] EAX: 0003 EBX: d3464000 ECX:  EDX: 
[0.08] ESI: fff4 EDI: d34701f0 EBP: c2827f84 ESP: c2827f54
[0.08]  DS: 007b ES: 007b FS:  GS:  SS: 0068
[0.08] CR0: 80050033 CR2:  CR3: 02c1e000 CR4: 00040690
[0.08] Stack:
[0.08]  d3464000 c2827fb8   c2457150   
00800300
[0.08]  fff4 c2457150 00020800 c2c1f800 c2827fb8 c1073386  
d3407280
[0.08]   00800300 c24780f5  9b89  c2457150 
00020800
[0.08] Call Trace:
[0.08]  [] ? rest_init+0x110/0x110
[0.08]  [] ? rest_init+0x110/0x110
[0.08]  [] do_fork+0x86/0x710
[0.08]  [] ? smp_trace_apic_timer_interrupt+0x5/0x2a6
[0.08]  [] ? rest_init+0x110/0x110
[0.08]  [] kernel_thread+0x3b/0x50
[0.08]  [] rest_init+0x3b/0x110
[0.08]  [] start_kernel+0x864/0x88a
[0.08]  [] i386_start_kernel+0xe9/0xfb
[0.08] Code: 00 83 05 f8 d1 c5 c2 01 83 15 fc d1 c5 c2 00 83 05 00 d2 
c5 c2 01 83 15 04 d2 c5 c2 00 83 05 e0 cf c5 c2 01 83 15 e4 cf c5 c2 00 <0f> 0b 
83 05 e8 cf c5 c2 01 83 15 ec cf c5 c2 00 8b 45 e4 83 05
[0.08] EIP: [] copy_process+0x1720/0x1860 SS:ESP 0068:c2827f54
[0.08] ---[ end trace 8262cf1029187723 ]---
[0.08] Kernel panic - not syncing: Fatal exception

git bisect start 594081ee7145cc30a3977cb4e218f81213b63dc5 v3.16 --
git bisect  bad b49e1043c48dac23f64fba684d31c4a96c1ffaa0  # 19:15  0-  
2  tpm: Properly clean sysfs entries in error path
git bisect good 32c2e6752ff0f48fe03b9e1c7c64bde580a840d2  # 20:28 20+  
0  ima: provide double buffering for hash calculation
git bisect  bad 7d8b6c63751cfbbe5eef81a48c22978b3407a3ad  # 20:46  0-  
1  CAPABILITIES: remove undefined caps from all processes
git bisect  bad fd33c43677a7965624b46352a686a7c1e72ae4aa

Re: [PATCH] PCI: fix sriov enabling with virtual bus

2014-11-05 Thread Yinghai Lu

On Wed, Nov 5, 2014 at 1:57 PM, Bjorn Helgaas  wrote:
>
> It's relatively common to start with a pci_dev and look for an ACPI handle
> that corresponds to that device or the closest enclosing scope, so maybe
> there should be a way to do that directly.
>
> For pci_get_hp_params(), I think the current code is actually slightly
> buggy because we don't look for _HPP/_HPX on the device itself; we only
> look at the bridges upstream from it.
>
> What I had in mind was something like the following (untested and not for
> application).



> + * Search for an ACPI handle.  The PCI device itself may have one, or an
> + * upstream device (either a PCI-to-PCI bridge or a PCI host bridge) may
> + * have one.
> + */
> +acpi_handle pci_find_acpi_handle(struct pci_dev *pdev)
> +{
> +   struct device *dev;
> +   acpi_handle handle;
> +   struct pci_bus *bus;
> +
> +   dev = >dev;
> +   handle = ACPI_HANDLE(dev);
> +   while (!handle) {
> +   pdev = pci_physfn(pdev);

I'm a little worried about to apply hpx value for PFs to VFs.

> +   bus = pdev->bus;
> +   if (pci_is_root_bus(bus))
> +   dev = bus->bridge;
> +   else {
> +   pdev = bus->self;
> +   dev = >dev;
> +   }
> +   handle = ACPI_HANDLE(dev);
> +   }
> +   return handle;
> +}


Also found another problem,
pci_device_add==>pci_configure_device==>program_hpp_type2() path.
and program_hpp_type2() will check dev->subordinate().

but at the time child bridge is not scanned yet.

Maybe we should move pci_configure_device later ?

Yinghai Lu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: ipv4: Use standard iovec primitive in raw_probe_proto_opt

2014-11-05 Thread Al Viro

On Thu, Nov 06, 2014 at 02:46:29PM +0800, Herbert Xu wrote:
> On Thu, Nov 06, 2014 at 06:43:18AM +, Al Viro wrote:
> > On Thu, Nov 06, 2014 at 01:50:23PM +0800, Herbert Xu wrote:
> > > + /* We only need the first two bytes. */
> > > + err = memcpy_fromiovecend((void *), msg->msg_iov, 0, 2);
> > > + if (err)
> > > + return err;
> > > +
> > > + fl4->fl4_icmp_type = icmph.type;
> > > + fl4->fl4_icmp_code = icmph.code;
> > 
> > That's more readable, but that exposes another problem in there - we read
> > the same piece of userland data twice, with no promise whatsoever that we'll
> > get the same value both times...
> 
> Sure, but you have to be root anyway to write to raw sockets.

Point, but that might very well be a pattern to watch for - there's at least
one more instance in TIPC (also not exploitable, according to TIPC folks)
and such bugs are easily repeated...

BTW, I've picked the tun and macvtap related bits from another part of old
queue; see vfs.git#untested-macvtap - it's on top of #iov_iter-net and it's
really completely untested.  Back then I was mostly interested in killing
as many ->aio_write() instances as I could, so it's only the "send" side of
things.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] bridge: missing null bridge device check causing null pointer dereference (bugfix)

2014-11-05 Thread Toshiaki Makita

On 2014/11/06 15:26, Su-Hyun Park wrote:
> the bridge device can be null if the bridge is being deleted while processing 
> the packet, which causes the null pointer dereference in switch statement.

How can this happen??
It is guarded by rcu.
netdev_rx_handler_unregister() ensures rx_handler_data is non NULL.

Thanks,
Toshiaki Makita

> 
> crash dump snippet:
> 
> <1>BUG: unable to handle kernel NULL pointer dereference at 0021
> <1>IP: [] br_handle_frame+0xe6/0x270
> 
> <0>Code: 4c 0f 44 f0 89 f8 66 33 15 32 52 24 00 66 33 05 29 52 24 00 09 c2 89 
> f0 66 33 05 22 52 24 00 80 e4 f0 66 09 c2 0f 84 eb 00 00 00 <41> 0f b6 46 21 
> 3c 02 74 61 3c 03 74 1d 48 89 df e8 d5 bc f0 ff
> ---
>  net/bridge/br_input.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> index 6fd5522..7e899ca 100644
> --- a/net/bridge/br_input.c
> +++ b/net/bridge/br_input.c
> @@ -176,6 +176,8 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
>   return RX_HANDLER_CONSUMED;
>  
>   p = br_port_get_rcu(skb->dev);
> + if (!p)
> + goto drop;
>  
>   if (unlikely(is_link_local_ether_addr(dest))) {
>   u16 fwd_mask = p->br->group_fwd_mask_required;
> 

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

Re: [PATCH v4 5/5] perf/sdt: Add support to perf record to trace SDT events

2014-11-05 Thread Hemant Kumar


On 11/05/2014 02:35 PM, Masami Hiramatsu wrote:
> (2014/11/05 16:06), Namhyung Kim wrote:
>> On Tue, 04 Nov 2014 21:56:53 +0900, Masami Hiramatsu wrote:
>>> Hi,
>>>
>>> (2014/11/04 17:06), Hemant Kumar wrote:
 Hi Namhyung,

 On 11/04/2014 01:08 PM, Namhyung Kim wrote:
> Hi Hemant,
>
> As you know, you need to keep an eye on how (kprobes) event cache
> patchset from Masami settles down.  For those who aren't CC'ed, please
> see the link below:
>
>https://lkml.org/lkml/2014/10/31/207
>
> On Sun, 02 Nov 2014 16:26:28 +0530, Hemant Kumar wrote:
>> This patch adds support to perf to record SDT events. When invoked,
>> the SDT event is looked up in the sdt-cache. If its found, an entry is
>> made silently to uprobe_events file and then recording is invoked, and
>> then the entry for the SDT event in uprobe_events is silently discarded.
>>
>> The SDT events are already stored in a cache file
>> (/var/cache/perf/perf-sdt-file.cache).
>> Although the file_hash table helps in addition or deletion of SDT events
>> from the cache, its not of much use when it comes to probing the actual
>> SDT event, because the key to this hash list is a file name and not the
>> SDT event name (which is given as an argument to perf record). So, we
>> won't be able to hash into it.
> It likely to be ended up with per-file or per-buildid cache files under
> ~/.debug directory.  In this case we also need to have the (central)
> event-to-cache table anyway IMHO.
>>> What we are talking is to make a new caching file with buildid under
>>> .debug/.
>>> We already has ~/.debug/.build-id/ for string the binary
>>> symbol maps.
>> ??
>>
>> The ~/.debug/.build-id/ (actually first 2 hexdigits are used
>> for directory name) is a symlink to a cached binary.
>>
>>   $ file .debug/.build-id/00/08a6c4028b3826f8905324c770e7aa450e5d3b 
>>   .debug/.build-id/00/08a6c4028b3826f8905324c770e7aa450e5d3b: symbolic link 
>> to 
>> `../../usr/lib64/libgtk-3.so.0.400.4/0008a6c4028b3826f8905324c770e7aa450e5d3b'
>>
>>   $ file 
>> .debug/usr/lib64/libgtk-3.so.0.400.4/0008a6c4028b3826f8905324c770e7aa450e5d3b
>>  
>>   
>> .debug/usr/lib64/libgtk-3.so.0.400.4/0008a6c4028b3826f8905324c770e7aa450e5d3b:
>>  ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, 
>> BuildID[sha1]=0xc4a6080026388b02245390f8aae770c73b5d0e45, stripped
>>
>>
>> Hmm.. it seems the file utility prints the build-id as a sequence of 4
>> byte little-endian integers.
> Ah, I saw the kernel's build-id file...
>
>>> I think there are 2 options, one is expanding the current
>>> build-id file format to include sdt and probe-event caches. The other is
>>> to add ~/.debug/.build-id/.probe and
>>> ~/.debug/.build-id/.sdt for caching probe/sdt information.
>> I think a single .probe file is enough for this, no?
> I hope to be so, but SDT is a bit different, that may have a semaphore. 
> Currently
> we just ignore it. But in some application, SDT events never be hit without 
> enabling
> the semaphores. I'm not sure how we can enable it. Systemtap enables it by 
> modifying
> application memory(data) on the fly. Maybe perftools can be done it by using 
> ptrace,
> but it's not for ftrace.
>
> [Off topic] I really don't like that the current SDT's semaphore. If the user 
> apps
> see the instruction at the probe point, it is easy to check whether the event 
> is
> enabled or not. Thus I recommend to change its implementation and update 
> version
> instead of supporting current semaphore by perftools.
>
>
>>> And also, user interface is a discussion point. This series defines new
>>> sdt-cache command, and we already have buildid-cache command. We should
>>> have probe-cache command too? or consolidate those cache managing commands?
>>> This question should be involving your series too.
>>>
>> To avoid this problem, we can create another hash list "event_hash" list
>> which will be maintained along with the file_hash list.
>> Whenever a user invokes 'perf record -e %provider:event, perf should
>> initialize the event_hash list and the file_hash list.
>> The key to event_hash list is calculated from the event name and its
>> provider name.
> Isn't it enough just to use provide name?  I guess the provider names
> are (should be?) unique among a system although there's no absolute
> guarantee for that.
>
 Yes, there is no guarantee for the provider names to be unique.
 If we use only provider name with "perf record", then, what if a user 
 wants to trace
 only a specific SDT event (not all the events for that provider)?
 What do you think?
>> What I'm saying is for managing cache not the usage of the cached
>> events.  IIUC you keep hash entry for all events to find matching file,
>> but I think it can be managed in provider level as events in a single
>> provider will live in a single binary.
> Usually, the SDT

Re: [PATCH 04/10] libata: use __scsi_format_command()

2014-11-05 Thread Christoph Hellwig

On Tue, Nov 04, 2014 at 09:06:43AM +0100, Hannes Reinecke wrote:
> libata already uses an internal buffer, so we should be using
> __scsi_format_command() here.

Looks good,

Reviewed-by: Christoph Hellwig 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clocksource: enable pxa_timer for SA-1100 platform

2014-11-05 Thread Dmitry Eremin-Solenikov

Hello,

2014-10-20 23:07 GMT+04:00 Arnd Bergmann :
> On Wednesday 15 October 2014 16:50:04 Dmitry Eremin-Solenikov wrote:
>> SA-11x0 platform used the same IP block as was used on PXA. Consequently
>> it makes sense to have only one driver. Enable pxa_timer clocksource for
>> StrongARM platform.
>>
>> Signed-off-by: Dmitry Eremin-Solenikov 
>
> Both patches look good to me.
>
> Acked-by: Arnd Bergmann 
>
> Should we merge them through arm-soc or through the clocksource tree?


Thomas added his blessing (and an ack) to merge these patches through arm-soc.
Should I gather any additional Acks before it cn hit arm-soc/for-next?

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

Re: [PATCH v5 2/8] phy: miphy28lp: Add PHY header file for DT x Driver defines

2014-11-05 Thread Kishon Vijay Abraham I

Hi,

On Tuesday 04 November 2014 04:21 PM, Gabriel FERNANDEZ wrote:
> This provides the shared header file which will be reference from both
> PHY driver and its associated Device Tree node(s).
> 
> Signed-off-by: Gabriel Fernandez 
> ---
>  include/dt-bindings/phy/phy.h | 18 ++

I don't see this being used in device tree file. Are you planning to add this
after -rc1 is tagged. Or else I have to create a separate branch for this file
which will be merged by both me and the dt maintainer. Let me know.

Thanks
Kishon
>  1 file changed, 18 insertions(+)
>  create mode 100644 include/dt-bindings/phy/phy.h
> 
> diff --git a/include/dt-bindings/phy/phy.h b/include/dt-bindings/phy/phy.h
> new file mode 100644
> index 000..e8c6a3f
> --- /dev/null
> +++ b/include/dt-bindings/phy/phy.h
> @@ -0,0 +1,18 @@
> +/*
> + *
> + * This header provides constants for the phy framework
> + *
> + * Copyright (C) 2014 STMicroelectronics
> + * Author: Gabriel Fernandez 
> + * License terms:  GNU General Public License (GPL), version 2
> + */
> +
> +#ifndef _DT_BINDINGS_PHY
> +#define _DT_BINDINGS_PHY
> +
> +#define PHY_TYPE_SATA1
> +#define PHY_TYPE_PCIE2
> +#define PHY_TYPE_USB23
> +#define PHY_TYPE_USB34
> +
> +#endif /* _DT_BINDINGS_PHY */
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: ipv4: Use standard iovec primitive in raw_probe_proto_opt

2014-11-05 Thread Herbert Xu

On Thu, Nov 06, 2014 at 06:43:18AM +, Al Viro wrote:
> On Thu, Nov 06, 2014 at 01:50:23PM +0800, Herbert Xu wrote:
> > +   /* We only need the first two bytes. */
> > +   err = memcpy_fromiovecend((void *), msg->msg_iov, 0, 2);
> > +   if (err)
> > +   return err;
> > +
> > +   fl4->fl4_icmp_type = icmph.type;
> > +   fl4->fl4_icmp_code = icmph.code;
> 
> That's more readable, but that exposes another problem in there - we read
> the same piece of userland data twice, with no promise whatsoever that we'll
> get the same value both times...

Sure, but you have to be root anyway to write to raw sockets.

Patches are welcome :)

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ipv4: Use standard iovec primitive in raw_probe_proto_opt

2014-11-05 Thread Al Viro

On Thu, Nov 06, 2014 at 01:50:23PM +0800, Herbert Xu wrote:
> + /* We only need the first two bytes. */
> + err = memcpy_fromiovecend((void *), msg->msg_iov, 0, 2);
> + if (err)
> + return err;
> +
> + fl4->fl4_icmp_type = icmph.type;
> + fl4->fl4_icmp_code = icmph.code;

That's more readable, but that exposes another problem in there - we read
the same piece of userland data twice, with no promise whatsoever that we'll
get the same value both times...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Do not enable async suspend for JMicron chips

2014-11-05 Thread Liu, Chuansheng



> -Original Message-
> From: Lu, Aaron
> Sent: Thursday, November 06, 2014 1:37 PM
> To: Liu, Chuansheng; Bjorn Helgaas
> Cc: Barto; Tejun Heo (t...@kernel.org); Rafael Wysocki;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] PCI: Do not enable async suspend for JMicron chips
> 
> On 11/06/2014 01:29 PM, Liu, Chuansheng wrote:
> > Hello Bjorn,
> >
> >> -Original Message-
> >> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> >> Sent: Thursday, November 06, 2014 12:09 PM
> >> To: Liu, Chuansheng
> >> Cc: Barto; Tejun Heo (t...@kernel.org); Lu, Aaron; Rafael Wysocki;
> >> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> >> Subject: Re: [PATCH] PCI: Do not enable async suspend for JMicron chips
> >>
> >> On Wed, Nov 5, 2014 at 6:48 PM, Liu, Chuansheng
> >>  wrote:
> >>> Hello Bjorn,
> >>>
>  -Original Message-
>  From: Bjorn Helgaas [mailto:bhelg...@google.com]
>  Sent: Thursday, November 06, 2014 3:04 AM
>  To: Barto
>  Cc: Liu, Chuansheng; Lu, Aaron; Tejun Heo; Rafael Wysocki;
>  linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
>  Subject: Re: [PATCH] PCI: Do not enable async suspend for JMicron chips
> 
>  On Wed, Nov 5, 2014 at 11:46 AM, Barto 
>  wrote:
> > this patch solves these 2 bug reports :
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=84861
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=81551
> 
>  Those bugs were already mentioned.  But e6b7e41cdd8c claims to solve
>  https://bugzilla.kernel.org/show_bug.cgi?id=81551, and 84861 is a
>  duplicate of 81551, so it should also be fixed by e6b7e41cdd8c.
> 
>  So the question is, why was e6b7e41cdd8c insufficient?  Presumably it
>  was tested and somebody thought it did fix the problem.
> >>>
> >>> The first patch e6b7e41cdd8c which is just exclude some of JMicron
> >> chips(363/361) out of async_suspend,
> >>> then Barto found the same issue on JMicron 368, so we need one more
> >> general patch to let JMicron chips
> >>> out of async_suspend, so we make this patch.
> >>>
> >>> Bjorn, tj,
> >>> Could you kindly take this patch? As Barto said, it effected the user
> >> experience indeed, thanks.
> >>
> >> Thanks for clarifying the changelog as far as the different chips and
> >> the different bugzillas.
> >>
> >> But you haven't addressed my concerns about (1) putting a PCI vendor
> >> ID check in the generic PCI core code, and (2) applying this to *all*
> >> JMicron devices.  You might want to explore a quirk-type solution or
> >> maybe just add the JMicron 368 to the checks added by e6b7e41cdd8c.
> > Understand your point, in fact, before this patch submitted, I had written
> another patch https://lkml.org/lkml/2014/9/24/68
> > which addressed to add the quirk-type solution in ATA code, and Aaron given
> better suggestion that implemented at pci_pm_init().
> > How do you think of it? Thanks.
> 
> I think Bjorn means that we should place the code as a fixup somewhere
> in the quirks.c. I didn't take a closer look but DECLARE_PCI_FIXUP_FINAL
> for those JMicron PCI devices seems to be a proper phase.

Thanks Aaron, then how about below patch?

diff --git a/drivers/ata/pata_jmicron.c b/drivers/ata/pata_jmicron.c
index 47e418b..9e85f86 100644
--- a/drivers/ata/pata_jmicron.c
+++ b/drivers/ata/pata_jmicron.c
@@ -158,6 +158,21 @@ static int jmicron_init_one (struct pci_dev *pdev, const 
struct pci_device_id *i
return ata_pci_bmdma_init_one(pdev, ppi, _sht, NULL, 0);
 }
 
+/*
+ * For JMicron chips, we need to disable the async_suspend method, otherwise
+ * they will hit the power-on issue when doing device resume, add one quick
+ * solution to disable the async_suspend method.
+ */
+static void pci_async_suspend_fixup(struct pci_dev *pdev)
+{
+   /*
+* disabling the async_suspend method for JMicron chips to
+* avoid device resuming issue.
+*/
+   device_disable_async_suspend(>dev);
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, 
pci_async_suspend_fixup);
+
 static const struct pci_device_id jmicron_pci_tbl[] = {
{ PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
  PCI_CLASS_STORAGE_IDE << 8, 0x00, 0 },

Barto,
Could you have a try on your side? Thanks.

Re: [PATCH] regulator: adding disable options for regulator-always-on and regulator-boots-on

2014-11-05 Thread Hugh Kang


On 2014년 11월 05일 04:56, Mark Brown wrote:
> On Tue, Nov 04, 2014 at 05:20:11PM +0900, Hugh Kang wrote:
>
> Please fix your mailer to word wrap within paragraphs.
>
>> I understand that I could make Rev.B with b.dtsi due to LDOs option is
>> different. However, aim to use device tree is that making easy steps.
>> Refer to dts option, if you set to be set status disabled option, the
>> driver dose not probe when the system boot up. Even though, the system
>> has different board revision exist. So dts have to be no corrupts any
>> overlap situation.
> Right, nothing is going to be perfect but equally if we use this sort of
> override property to do things it then becomes harder to read the DT for
> the system since you can't trust that a property you see in one file
> won't be overridden by another file somewhere else.  This can happen to
> an extent already but normally not and it doesn't seem like a pattern we
> want to encourage.
>
>> I have mentions the simple example to change only one LDOs. However,
>> if someone want to edit many regulators with similar configuration, he
>> has to do lots of copy and paste works. Because he has to create new
>> dts file. So I would suggest to make it as simple as I could.
> Sure, but that's purely mechanical and very easy to review - you can do
> a code motion patch to split the bits of DT out then start changing
> things, and you can still keep the common paramters in the core file.
>
>> Also, I have somehow agree with you that affects any boolean property in the 
>> DT.
> This is a big one for me - it's going to be both time consuming and
> complex to add this sort of thing for more properties and we do get
> into complexity things if each individual property and its override
> has to be handled by hand.
Thank you for advising. I would take another way to apply it.
Also, I would like to say thanks to Krzysztof, giving me a advice.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] staging:rtl8723au: core: Fix error reported by checkpatch.

2014-11-05 Thread Sharma, Sanjeev

-Original Message-
From: Greg KH [mailto:gre...@linuxfoundation.org] 
Sent: Wednesday, November 05, 2014 9:58 PM
To: Sharma, Sanjeev
Cc: larry.fin...@lwfinger.net; jes.soren...@redhat.com; 
de...@driverdev.osuosl.org; linux-wirel...@vger.kernel.org; 
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] staging:rtl8723au: core: Fix error reported by 
checkpatch.

On Wed, Nov 05, 2014 at 05:05:03PM +0530, Sanjeev Sharma wrote:
> This is a patch to the rtw_cmd.c file that fixes Error reported by 
> checkpatch.

What error are you "fixing"?  Please be specific.

Submitted individual patch with detail of fix.

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/

[PATCH] staging:rtl8723au: core: Fix Warning reported by checkpatch.

2014-11-05 Thread Sanjeev Sharma

This is a patch to the rtw_cmd.c file that fixes following
Warning by introducing temporary structure.

WARNING: line over 80 characters

Signed-off-by: Sanjeev Sharma 
---
 drivers/staging/rtl8723au/core/rtw_cmd.c | 123 +++
 1 file changed, 60 insertions(+), 63 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_cmd.c 
b/drivers/staging/rtl8723au/core/rtw_cmd.c
index 4eaa502..6186575 100644
--- a/drivers/staging/rtl8723au/core/rtw_cmd.c
+++ b/drivers/staging/rtl8723au/core/rtw_cmd.c
@@ -919,34 +919,34 @@ static void traffic_status_watchdog(struct rtw_adapter 
*padapter)
u8 bHigherBusyTxTraffic = false;
struct mlme_priv *pmlmepriv = >mlmepriv;
int BusyThreshold = 100;
+   struct rt_link_detect *ldi = >LinkDetectInfo;
+
/*  */
/*  Determine if our traffic is busy now */
/*  */
if (check_fwstate(pmlmepriv, _FW_LINKED)) {
if (rtl8723a_BT_coexist(padapter))
BusyThreshold = 50;
-   else if (pmlmepriv->LinkDetectInfo.bBusyTraffic)
+   else if (ldi->bBusyTraffic)
BusyThreshold = 75;
/*  if we raise bBusyTraffic in last watchdog, using
lower threshold. */
-   if (pmlmepriv->LinkDetectInfo.NumRxOkInPeriod > BusyThreshold ||
-   pmlmepriv->LinkDetectInfo.NumTxOkInPeriod > BusyThreshold) {
+   if (ldi->NumRxOkInPeriod > BusyThreshold ||
+   ldi->NumTxOkInPeriod > BusyThreshold) {
bBusyTraffic = true;
 
-   if (pmlmepriv->LinkDetectInfo.NumRxOkInPeriod >
-   pmlmepriv->LinkDetectInfo.NumTxOkInPeriod)
+   if (ldi->NumRxOkInPeriod > ldi->NumTxOkInPeriod)
bRxBusyTraffic = true;
else
bTxBusyTraffic = true;
}
 
/*  Higher Tx/Rx data. */
-   if (pmlmepriv->LinkDetectInfo.NumRxOkInPeriod > 4000 ||
-   pmlmepriv->LinkDetectInfo.NumTxOkInPeriod > 4000) {
+   if (ldi->NumRxOkInPeriod > 4000 ||
+   ldi->NumTxOkInPeriod > 4000) {
bHigherBusyTraffic = true;
 
-   if (pmlmepriv->LinkDetectInfo.NumRxOkInPeriod >
-   pmlmepriv->LinkDetectInfo.NumTxOkInPeriod)
+   if (ldi->NumRxOkInPeriod > ldi->NumTxOkInPeriod)
bHigherBusyRxTraffic = true;
else
bHigherBusyTxTraffic = true;
@@ -955,9 +955,9 @@ static void traffic_status_watchdog(struct rtw_adapter 
*padapter)
if (!rtl8723a_BT_coexist(padapter) ||
!rtl8723a_BT_using_antenna_1(padapter)) {
/*  check traffic for  powersaving. */
-   if (((pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod +
- pmlmepriv->LinkDetectInfo.NumTxOkInPeriod) > 8) ||
-   pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod >2)
+   if (((ldi->NumRxUnicastOkInPeriod +
+ ldi->NumTxOkInPeriod) > 8) ||
+   ldi->NumRxUnicastOkInPeriod > 2)
bEnterPS = false;
else
bEnterPS = true;
@@ -971,15 +971,15 @@ static void traffic_status_watchdog(struct rtw_adapter 
*padapter)
} else
LPS_Leave23a(padapter);
 
-   pmlmepriv->LinkDetectInfo.NumRxOkInPeriod = 0;
-   pmlmepriv->LinkDetectInfo.NumTxOkInPeriod = 0;
-   pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod = 0;
-   pmlmepriv->LinkDetectInfo.bBusyTraffic = bBusyTraffic;
-   pmlmepriv->LinkDetectInfo.bTxBusyTraffic = bTxBusyTraffic;
-   pmlmepriv->LinkDetectInfo.bRxBusyTraffic = bRxBusyTraffic;
-   pmlmepriv->LinkDetectInfo.bHigherBusyTraffic = bHigherBusyTraffic;
-   pmlmepriv->LinkDetectInfo.bHigherBusyRxTraffic = bHigherBusyRxTraffic;
-   pmlmepriv->LinkDetectInfo.bHigherBusyTxTraffic = bHigherBusyTxTraffic;
+   ldi->NumRxOkInPeriod = 0;
+   ldi->NumTxOkInPeriod = 0;
+   ldi->NumRxUnicastOkInPeriod = 0;
+   ldi->bBusyTraffic = bBusyTraffic;
+   ldi->bTxBusyTraffic = bTxBusyTraffic;
+   ldi->bRxBusyTraffic = bRxBusyTraffic;
+   ldi->bHigherBusyTraffic = bHigherBusyTraffic;
+   ldi->bHigherBusyRxTraffic = bHigherBusyRxTraffic;
+   ldi->bHigherBusyTxTraffic = bHigherBusyTxTraffic;
 }
 
 static void dynamic_chk_wk_hdl(struct rtw_adapter *padapter, u8 *pbuf, int sz)
@@ -1017,46 +1017,44 @@ static void lps_ctrl_wk_hdl(struct rtw_adapter 
*padapter, u8 lps_ctrl_type)
check_fwstate(pmlmepriv, WIFI_ADHOC_STATE))
return;
 
-   switch (lps_ctrl_type)
-   {
-   case

[PATCH] bridge: missing null bridge device check causing null pointer dereference (bugfix)

2014-11-05 Thread Su-Hyun Park

the bridge device can be null if the bridge is being deleted while processing 
the packet, which causes the null pointer dereference in switch statement.

crash dump snippet:

<1>BUG: unable to handle kernel NULL pointer dereference at 0021
<1>IP: [] br_handle_frame+0xe6/0x270

<0>Code: 4c 0f 44 f0 89 f8 66 33 15 32 52 24 00 66 33 05 29 52 24 00 09 c2 89 
f0 66 33 05 22 52 24 00 80 e4 f0 66 09 c2 0f 84 eb 00 00 00 <41> 0f b6 46 21 
3c 02 74 61 3c 03 74 1d 48 89 df e8 d5 bc f0 ff
---
 net/bridge/br_input.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index 6fd5522..7e899ca 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -176,6 +176,8 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
return RX_HANDLER_CONSUMED;
 
p = br_port_get_rcu(skb->dev);
+   if (!p)
+   goto drop;
 
if (unlikely(is_link_local_ether_addr(dest))) {
u16 fwd_mask = p->br->group_fwd_mask_required;
-- 
1.8.1.4

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

Re: [PATCH 2/5] DMA: Remove .owner field for driver

2014-11-05 Thread Vinod Koul

On Wed, Sep 24, 2014 at 12:09:23PM +0530, Kiran Padwal wrote:
> There is no need to init .owner field.
> 
> Based on the patch from Peter Griffin 
> "mmc: remove .owner field for drivers using module_platform_driver"
> 
> This patch removes the superflous .owner field for drivers which
> use the module_platform_driver API, as this is overriden in
> platform_driver_register anyway."

Please make sure you use right subsytem name in patches

Applied with name fix

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

[PATCH v8 1/3] power-domain: rockchip: add power domain drivers

In order to meet high performance and low power requirements, a power
management unit is designed or saving power when RK3288 in low power mode.
The RK3288 PMU is dedicated for managing the power ot the whole chip.

Signed-off-by: Jack Dai 
Signed-off-by: jinkun.hong 
Signed-off-by: Caesar Wang 

---

Changes in v8:
- This reconciles the v2 and v7 code so that we power domain have
lists of clocks they toggle on and off during power transitions and
independently from power domains clocks we attach clocks to devices
comprising power domain and prepare them so they are turned on and off
by runtime PM.

Changes in v7:
- Delete unused variables

Changes in v6:
- delete pmu_lock
- modify dev_lock using mutex
- pm_clk_resume(pd->dev) change to pm_clk_resume(ed->dev)
- pm_clk_suspend(pd->dev) change to pm_clk_suspend(ed->dev)
- add devm_kfree(pd->dev, de) in rockchip_pm_domain_detach_dev

Changes in v5:
- delete idle_lock
- add timeout in rockchip_pmu_set_idle_request()

Changes in v4:
- use list storage dev

Changes in v3:
- change use pm_clk_resume() and pm_clk_suspend()

Changes in v2:
- remove the "pd->pd.of_node = np"

 arch/arm/mach-rockchip/Kconfig|   1 +
 arch/arm/mach-rockchip/Makefile   |   1 +
 arch/arm/mach-rockchip/pm_domains.c   | 469 ++
 include/dt-bindings/power-domain/rk3288.h |  11 +
 4 files changed, 482 insertions(+)
 create mode 100644 arch/arm/mach-rockchip/pm_domains.c
 create mode 100644 include/dt-bindings/power-domain/rk3288.h

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index ac5803c..d033993 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -13,6 +13,7 @@ config ARCH_ROCKCHIP
select DW_APB_TIMER_OF
select ARM_GLOBAL_TIMER
select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
+   select PM_GENERIC_DOMAINS if PM
help
  Support for Rockchip's Cortex-A9 Single-to-Quad-Core-SoCs
  containing the RK2928, RK30xx and RK31xx series.
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index b29d8ea..17ea082 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -1,4 +1,5 @@
 CFLAGS_platsmp.o := -march=armv7-a
 
 obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip.o
+obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o
 obj-$(CONFIG_SMP) += headsmp.o platsmp.o
diff --git a/arch/arm/mach-rockchip/pm_domains.c 
b/arch/arm/mach-rockchip/pm_domains.c
new file mode 100644
index 000..153b22d
--- /dev/null
+++ b/arch/arm/mach-rockchip/pm_domains.c
@@ -0,0 +1,469 @@
+/*
+ * Rockchip Generic power domain support.
+ *
+ * Copyright (c) 2014 ROCKCHIP, 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 Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct rockchip_domain_info {
+   u32 id;
+   int pwr_shift;
+   int status_shift;
+   int req_shift;
+   int idle_shift;
+   int ack_shift;
+};
+
+struct rockchip_pmu_info {
+   u32 pwr_offset;
+   u32 status_offset;
+   u32 req_offset;
+   u32 idle_offset;
+   u32 ack_offset;
+
+   int num_domains;
+   const struct rockchip_domain_info *domain_info;
+};
+
+struct rockchip_pm_domain {
+   struct generic_pm_domain genpd;
+   const struct rockchip_domain_info *info;
+   struct rockchip_pmu *pmu;
+   int num_clks;
+   struct clk *clks[];
+};
+
+struct rockchip_pmu {
+   struct device *dev;
+   struct regmap *regmap;
+   const struct rockchip_pmu_info *info;
+   struct mutex mutex; /* mutex lock for dev_list */
+   int num_domains;
+   struct rockchip_pm_domain *domains[];
+};
+
+#define to_rockchip_pd(gpd) container_of(gpd, struct rockchip_pm_domain, genpd)
+
+#define DOMAIN(_id, _pwr_s, _status_s, _req_s, _idle_s, _ack_s)\
+{  \
+   .id = _id,  \
+   .pwr_shift = _pwr_s,\
+   .status_shift = _status_s,  \
+   .req_shift = _req_s,\
+   .idle_shift = _idle_s,  \
+   .ack_shift = _ack_s,\
+}
+
+#define DOMAIN_RK3288(_id, _pwr_s, _status_s, _req_s) \
+   DOMAIN(_id, _pwr_s, _status_s, _req_s, _req_s, (_req_s) + 16)
+
+static int rockchip_pmu_set_idle_request(struct rockchip_pm_domain *pd,
+bool idle)
+{
+   struct rockchip_pmu *pmu = pd->pmu;
+   const struct rockchip_domain_info *pd_info = pd->info;
+   const

[PATCH v8 3/3] ARM: dts: add rk3288 power-domain node

Signed-off-by: Jack Dai 
Signed-off-by: jinkun.hong 
Signed-off-by: Caesar Wang 

---

Changes in v8:
- DTS go back to v2

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Decomposition power-controller, changed to multiple controller
(gpu-power-controller, hevc-power-controller)

Changes in v2:
- make pd_vio clocks all one entry per line and alphabetize.
- power: power-controller move back to pinctrl: pinctrl.

 arch/arm/boot/dts/rk3288.dtsi | 66 +++
 1 file changed, 66 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index cb18bb4..9cd269a 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -989,4 +989,70 @@
};
};
};
+
+   power: power-controller {
+   compatible = "rockchip,rk3288-power-controller";
+   #power-domain-cells = <1>;
+   rockchip,pmu = <>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   pd_gpu {
+   reg = ;
+   clocks = < ACLK_GPU>;
+   };
+
+   pd_hevc {
+   reg = ;
+   clocks = < ACLK_HEVC>,
+< SCLK_HEVC_CABAC>,
+< SCLK_HEVC_CORE>,
+< HCLK_HEVC>;
+   };
+
+   pd_vio {
+   reg = ;
+   clocks = < ACLK_IEP>,
+< ACLK_ISP>,
+< ACLK_RGA_NIU>,
+< ACLK_RGA>,
+< ACLK_VIO0_NIU>,
+< ACLK_VIO1_NIU>,
+< ACLK_VIP>,
+< ACLK_VOP0>,
+< ACLK_VOP1>,
+< DCLK_VOP0>,
+< DCLK_VOP1>,
+< HCLK_IEP>,
+< HCLK_ISP>,
+< HCLK_RGA>,
+< HCLK_VIO_AHB_ARBI>,
+< HCLK_VIO_NIU>,
+< HCLK_VIO2_H2P>,
+< HCLK_VIP>,
+< HCLK_VOP0>,
+< HCLK_VOP1>,
+< PCLK_EDP_CTRL>,
+< PCLK_HDMI_CTRL>,
+< PCLK_LVDS_PHY>,
+< PCLK_MIPI_CSI>,
+< PCLK_MIPI_DSI0>,
+< PCLK_MIPI_DSI1>,
+< PCLK_VIO2_H2P>,
+< SCLK_EDP_24M>,
+< SCLK_EDP>,
+< SCLK_HDMI_CEC>,
+< SCLK_HDMI_HDCP>,
+< SCLK_ISP_JPE>,
+< SCLK_ISP>,
+< SCLK_RGA>;
+   };
+
+   pd_video {
+   reg = ;
+   /* FIXME: add clocks */
+   clocks = < ACLK_VCODEC>,
+< HCLK_VCODEC>;
+   };
+   };
 };
-- 
1.9.1


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

[PATCH v8 0/3] ARM: rk3288 : Add PM Domain support

Add power domain drivers based on generic power domain for
Rockchip platform, and support RK3288.

https://chromium-review.googlesource.com/#/c/220253/9
This is the GPU driver, add the following information in DT,
and it can support the PMDOMAIN

gpu: gpu@ffa3 {
compatible = "arm,malit764",
 "arm,malit76x",
 "arm,malit7xx",
 "arm,mali-midgard";
reg = <0xffa3 0x1>;
interrupts = ,
 ,
 ;
interrupt-names = "JOB", "MMU", "GPU";
clocks = < ACLK_GPU>;
clock-names = "aclk_gpu";
operating-points = <
/* KHz uV */
10 80
20 85
30 95
40 100
60 115
>;
power-domains = < RK3288_PD_GPU>;
status = "disabled";
};

Based on:
- [PATCH v1 1/4] PM / clock_ops: Add pm_clk_add_clk()
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg735599.html

Changes in v8:
- This reconciles the v2 and v7 code so that we power domain have
lists of clocks they toggle on and off during power transitions and
independently from power domains clocks we attach clocks to devices
comprising power domain and prepare them so they are turned on and off
by runtime PM.
- document go back to v2
- DTS go back to v2

Changes in v7:
- Delete unused variables

Changes in v6:
- delete pmu_lock
- modify dev_lock using mutex
- pm_clk_resume(pd->dev) change to pm_clk_resume(ed->dev)
- pm_clk_suspend(pd->dev) change to pm_clk_suspend(ed->dev)
- add devm_kfree(pd->dev, de) in rockchip_pm_domain_detach_dev

Changes in v5:
- delete idle_lock
- add timeout in rockchip_pmu_set_idle_request()

Changes in v4:
- use list storage dev

Changes in v3:
- change use pm_clk_resume() and pm_clk_suspend()
- DT structure has changed
- Decomposition power-controller, changed to multiple controller
(gpu-power-controller, hevc-power-controller)

Changes in v2:
- remove the "pd->pd.of_node = np"
- move clocks to "optional"
- make pd_vio clocks all one entry per line and alphabetize.
- power: power-controller move back to pinctrl: pinctrl.

Caesar Wang (3):
  power-domain: rockchip: add power domain drivers
  dt-bindings: add document of Rockchip power domain
  ARM: dts: add rk3288 power-domain node

 .../bindings/arm/rockchip/power_domain.txt |  48 +++
 arch/arm/boot/dts/rk3288.dtsi  |  66 +++
 arch/arm/mach-rockchip/Kconfig |   1 +
 arch/arm/mach-rockchip/Makefile|   1 +
 arch/arm/mach-rockchip/pm_domains.c| 469 +
 include/dt-bindings/power-domain/rk3288.h  |  11 +
 6 files changed, 596 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/rockchip/power_domain.txt
 create mode 100644 arch/arm/mach-rockchip/pm_domains.c
 create mode 100644 include/dt-bindings/power-domain/rk3288.h

-- 
1.9.1


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

[PATCH v8 2/3] dt-bindings: add document of Rockchip power domain

Signed-off-by: Jack Dai 
Signed-off-by: jinkun.hong 
Signed-off-by: Caesar Wang 

---

Changes in v8:
- document go back to v2

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- DT structure has changed

Changes in v2:
- move clocks to "optional"

 .../bindings/arm/rockchip/power_domain.txt | 48 ++
 1 file changed, 48 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/rockchip/power_domain.txt

diff --git a/Documentation/devicetree/bindings/arm/rockchip/power_domain.txt 
b/Documentation/devicetree/bindings/arm/rockchip/power_domain.txt
new file mode 100644
index 000..3e74e6d
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/rockchip/power_domain.txt
@@ -0,0 +1,48 @@
+* Rockchip Power Domains
+
+Rockchip processors include support for multiple power domains which can be
+powered up/down by software based on different application scenes to save 
power.
+
+Required properties for power domain controller:
+- compatible: should be one of the following.
+* rockchip,rk3288-power-controller - for rk3288 type power domain.
+- #power-domain-cells: Number of cells in a power-domain specifier.
+  should be 1.
+- rockchip,pmu: phandle referencing a syscon providing the pmu registers
+- #address-cells: should be 1.
+- #size-cells: should be 0.
+
+Required properties for power domain sub nodes:
+- reg: index of the power domain, should use macros in:
+*  include/dt-bindings/power-domain/rk3288.h - for rk3288 type power 
domain.
+- clocks (optional): phandles to clocks which need to be enabled while power 
domain
+  switches state.
+
+Example:
+
+   power: power-controller {
+  compatible = "rockchip,rk3288-power-controller";
+  #power-domain-cells = <1>;
+  rockchip,pmu = <>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+  pd_gpu {
+  reg = ;
+  clocks = < ACLK_GPU>;
+  };
+   };
+
+Node of a device using power domains must have a power-domains property,
+containing a phandle to the power device node and an index specifying which
+power domain to use.
+The index should use macros in:
+   * include/dt-bindings/power-domain/rk3288.h - for rk3288 type power domain.
+
+Example of the node using power domain:
+
+   node {
+   /* ... */
+   power-domains = < RK3288_PD_GPU>;
+   /* ... */
+   };
-- 
1.9.1


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

Re: [RFC PATCH V2] ACPI: Add _DEP(Operation Region Dependencies) support to fix battery issue on the Asus T100TA

2014-11-05 Thread Mika Westerberg

On Wed, Nov 05, 2014 at 10:55:23PM +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 05, 2014 10:54:14 AM Mika Westerberg wrote:
> > On Mon, Oct 27, 2014 at 11:09:44PM +0800, Lan Tianyu wrote:
> > > ACPI 5.0 introduces _DEP to designate device objects that OSPM should
> > > assign a higher priority in start ordering due to future operation region
> > > accesses.
> > > 
> > > On Asus T100TA, ACPI battery info are read from a I2C slave device via
> > > I2C operation region. Before I2C operation region handler is installed,
> > > battery _STA always returns 0. There is a _DEP method of designating
> > > start order under battery device node.
> > > 
> > > This patch is to implement _DEP feature to fix battery issue on the Asus 
> > > T100TA.
> > > Introducing acpi_dep_list and adding dep_unmet count in the struct
> > > acpi_device. During ACPI namespace scan, create struct acpi_dep_data for a
> > > valid pair of master (device pointed to by _DEP)/slave(device with _DEP), 
> > > record
> > > master's and slave's ACPI handle in it and put it into acpi_dep_list. The 
> > > dep_unmet
> > > count will increase by one if there is a device under its _DEP. Driver's 
> > > probe() should
> > > return EPROBE_DEFER when find dep_unmet larger than 0. When I2C operation
> > > region handler is installed, remove all struct acpi_dep_data on the 
> > > acpi_dep_list
> > > whose master is pointed to I2C host controller and decrease slave's 
> > > dep_unmet.
> > > When dep_unmet decreases to 0, all _DEP conditions are met and then do 
> > > acpi_bus_attach()
> > > for the device in order to resolve battery _STA issue on the Asus T100TA.
> > 
> > Is there a reason why the driver core can't handle this automatically in
> > such way that when there are unmet dependencies, it will not probe the
> > device? Or am I missing something?
> 
> Yes, there is a reason: There's no way to represent such dependencies in the
> driver core. :-)
> 
> That's been discussed for several times (and I've even mentioned _DEP in one
> of those discussions) and it's always ended up being seen as "complexity
> nightmare".

OK, I see.

> > Now it looks like the driver itself needs to know about these and handle
> > them somehow.
> 
> The patch is missing the user of it which is going to be the battery driver
> only for the time being.  Tianyu, can you please include the battery changes
> into the patch at least for now?
> 
> > I'm asking this because there are other things like devices using GPIOs
> > that also take advantage of _DEP, like this on Asus T100:
> > 
> > Device (SDHB)
> > {
> > Name (_ADR, Zero)  // _ADR: Address
> > Name (_HID, "INT33BB")  // _HID: Hardware ID
> > ...
> > Name (_DEP, Package (0x02)  // _DEP: Dependencies
> > {
> > PEPD,
> > GPO2
> > })
> > 
> > I don't know what PEPD is but GPO2 is the GPIO controller.
> 
> Well, if you read the definition of _DEP in ACPI 5.1, it is all about 
> operation
> regions, so this smells like abuse of sorts.  In any case, it is hard to argue
> that _DEP is not internal to ACPI because of that definition.

So if we have a device, like SDHB above (SDIO controller), that needs
GPIOs for powering the SDIO card and that is done by using GPIO
operation regions how do we ensure that the GPIO controller driver is
there?

I think the answer is that we just make sure the the GPIO driver is
there before anything that is going to use it. E.g make it
subsys_initcall() or so?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] staging:rtl8723au: core: Fix error reported by checkpatch.

2014-11-05 Thread Sanjeev Sharma

This is a patch to the rtw_cmd.c file that fixes following
error.

ERROR: spaces required around that '>' (ctx:WxV)
ERROR: that open brace { should be on the previous line

Signed-off-by: Sanjeev Sharma 
---
 drivers/staging/rtl8723au/core/rtw_cmd.c | 83 +++-
 1 file changed, 40 insertions(+), 43 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_cmd.c 
b/drivers/staging/rtl8723au/core/rtw_cmd.c
index 4eaa502..e9d6ac2 100644
--- a/drivers/staging/rtl8723au/core/rtw_cmd.c
+++ b/drivers/staging/rtl8723au/core/rtw_cmd.c
@@ -957,7 +957,7 @@ static void traffic_status_watchdog(struct rtw_adapter 
*padapter)
/*  check traffic for  powersaving. */
if (((pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod +
  pmlmepriv->LinkDetectInfo.NumTxOkInPeriod) > 8) ||
-   pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod >2)
+   pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod > 
2)
bEnterPS = false;
else
bEnterPS = true;
@@ -1017,46 +1017,44 @@ static void lps_ctrl_wk_hdl(struct rtw_adapter 
*padapter, u8 lps_ctrl_type)
check_fwstate(pmlmepriv, WIFI_ADHOC_STATE))
return;
 
-   switch (lps_ctrl_type)
-   {
-   case LPS_CTRL_SCAN:
-   rtl8723a_BT_wifiscan_notify(padapter, true);
-   if (!rtl8723a_BT_using_antenna_1(padapter)) {
-   if (check_fwstate(pmlmepriv, _FW_LINKED))
-   LPS_Leave23a(padapter);
-   }
-   break;
-   case LPS_CTRL_JOINBSS:
-   LPS_Leave23a(padapter);
-   break;
-   case LPS_CTRL_CONNECT:
-   mstatus = 1;/* connect */
-   /*  Reset LPS Setting */
-   padapter->pwrctrlpriv.LpsIdleCount = 0;
-   rtl8723a_set_FwJoinBssReport_cmd(padapter, 1);
-   rtl8723a_BT_mediastatus_notify(padapter, mstatus);
-   break;
-   case LPS_CTRL_DISCONNECT:
-   mstatus = 0;/* disconnect */
-   rtl8723a_BT_mediastatus_notify(padapter, mstatus);
-   if (!rtl8723a_BT_using_antenna_1(padapter))
-   LPS_Leave23a(padapter);
-   rtl8723a_set_FwJoinBssReport_cmd(padapter, 0);
-   break;
-   case LPS_CTRL_SPECIAL_PACKET:
-   pwrpriv->DelayLPSLastTimeStamp = jiffies;
-   rtl8723a_BT_specialpacket_notify(padapter);
-   if (!rtl8723a_BT_using_antenna_1(padapter))
+   switch (lps_ctrl_type) {
+   case LPS_CTRL_SCAN:
+   rtl8723a_BT_wifiscan_notify(padapter, true);
+   if (!rtl8723a_BT_using_antenna_1(padapter)) {
+   if (check_fwstate(pmlmepriv, _FW_LINKED))
LPS_Leave23a(padapter);
-   break;
-   case LPS_CTRL_LEAVE:
-   rtl8723a_BT_lps_leave(padapter);
-   if (!rtl8723a_BT_using_antenna_1(padapter))
-   LPS_Leave23a(padapter);
-   break;
-
-   default:
-   break;
+   }
+   break;
+   case LPS_CTRL_JOINBSS:
+   LPS_Leave23a(padapter);
+   break;
+   case LPS_CTRL_CONNECT:
+   mstatus = 1;/* connect */
+   /*  Reset LPS Setting */
+   padapter->pwrctrlpriv.LpsIdleCount = 0;
+   rtl8723a_set_FwJoinBssReport_cmd(padapter, 1);
+   rtl8723a_BT_mediastatus_notify(padapter, mstatus);
+   break;
+   case LPS_CTRL_DISCONNECT:
+   mstatus = 0;/* disconnect */
+   rtl8723a_BT_mediastatus_notify(padapter, mstatus);
+   if (!rtl8723a_BT_using_antenna_1(padapter))
+   LPS_Leave23a(padapter);
+   rtl8723a_set_FwJoinBssReport_cmd(padapter, 0);
+   break;
+   case LPS_CTRL_SPECIAL_PACKET:
+   pwrpriv->DelayLPSLastTimeStamp = jiffies;
+   rtl8723a_BT_specialpacket_notify(padapter);
+   if (!rtl8723a_BT_using_antenna_1(padapter))
+   LPS_Leave23a(padapter);
+   break;
+   case LPS_CTRL_LEAVE:
+   rtl8723a_BT_lps_leave(padapter);
+   if (!rtl8723a_BT_using_antenna_1(padapter))
+   LPS_Leave23a(padapter);
+   break;
+   default:
+   break;
}
 }
 
@@ -1152,7 +1150,7 @@ static void rtw_chk_hi_queue_hdl(struct rtw_adapter 
*padapter)

Re: [Patch Part2 v4 01/31] irqdomain: Introduce new interfaces to support hierarchy irqdomains



On 2014/11/6 7:48, Thomas Gleixner wrote:
> On Tue, 4 Nov 2014, Jiang Liu wrote:
>>  /* Number of irqs reserved for a legacy isa controller */
>>  #define NUM_ISA_INTERRUPTS  16
>> @@ -64,6 +66,16 @@ struct irq_domain_ops {
>>  int (*xlate)(struct irq_domain *d, struct device_node *node,
>>   const u32 *intspec, unsigned int intsize,
>>   unsigned long *out_hwirq, unsigned int *out_type);
>> +
>> +#ifdef  CONFIG_IRQ_DOMAIN_HIERARCHY
>> +/* extended V2 interfaces to support hierarchy irq_domains */
>> +int (*alloc)(struct irq_domain *d, unsigned int virq,
>> + unsigned int nr_irqs, void *arg);
>> +void (*free)(struct irq_domain *d, unsigned int virq,
>> + unsigned int nr_irqs);
>> +int (*activate)(struct irq_domain *d, struct irq_data *irq_data);
>> +int (*deactivate)(struct irq_domain *d, struct irq_data *irq_data);
> 
> Why do we have a return value here? Especially the deactivate one
> makes no sense at all.
> 
>> +extern int irq_domain_activate_irq(struct irq_data *irq_data);
>> +extern int irq_domain_deactivate_irq(struct irq_data *irq_data);
> 
> And here.
> 
>> @@ -178,6 +179,7 @@ int irq_startup(struct irq_desc *desc, bool resend)
>>  irq_state_clr_disabled(desc);
>>  desc->depth = 0;
>>  
>> +irq_domain_activate_irq(>irq_data);
> 
> We do not check it and we cannot do here AFAICT.
> 
>>  if (desc->irq_data.chip->irq_startup) {
>>  ret = desc->irq_data.chip->irq_startup(>irq_data);
>>  irq_state_clr_masked(desc);
>> @@ -199,6 +201,7 @@ void irq_shutdown(struct irq_desc *desc)
>>  desc->irq_data.chip->irq_disable(>irq_data);
>>  else
>>  desc->irq_data.chip->irq_mask(>irq_data);
>> +irq_domain_deactivate_irq(>irq_data);
> 
> Ditto.
> 
> So the return value for irq_domain_deactivate_irq() is silly to begin
> with, but also the return value for irq_domain_activate_irq() does not
> really make sense. We've allocated the resources for the interrupt
> already down the hierarchy chain. So there is no reason why the actual
> activation should fail.
Hi Thomas,
Fair enough, I have changed them to return void, which also
simplify the implementation. But add one or two BUG_ON()s:)
Regards!
Gerry
> 
> Thanks,
> 
>   tglx
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/2] pinctrl: Intel Cherryview/Braswell support

2014-11-05 Thread Mika Westerberg

On Wed, Nov 05, 2014 at 01:44:24PM -0800, Olof Johansson wrote:
> Pinctrl setup has traditionally always been done by firmware on x86,
> and some ARM platforms are again moving back to that state (since
> reconfiguring pinctrl in the kernel is in some cases not safe).
> 
> What's the purpose of exposing this to the kernel on x86 now? I can
> see the need to expose GPIO, but not pinctrl? Having the pin control
> hidden away in firmware has been one of the benefits on x86, and
> you're now undoing it... :)

Well, the hardware is actually a pin controller so it can configure pins
in different way.

In addition to that we still do expect that the pins are configured by
the BIOS for the time being. The advantage of having pinctrl driver is
more like fixing things that the BIOS got wrong (like for example SPI
pins that were muxed as GPIOs), not to reconfigure everything.

Plus it has really nice debugfs interface :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/11] dmaengine: Cleanup chancnt

2014-11-05 Thread Vinod Koul

On Thu, Oct 16, 2014 at 11:00:52AM +0200, Maxime Ripard wrote:
> Hi everyone,
> 
> As pointed out in the documentation thread [1], the chancnt variable
> is filled during the driver registration in dma_async_device_register,
> from the liste of channels that has been set.
> 
> This serie removes the occurences of the drivers that set it in their
> probe function.

Applied all, thanks

-- 
~Vinod

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

Re: [PATCH v3 0/2] dmaengine: Add driver documentation

2014-11-05 Thread Vinod Koul

On Tue, Oct 28, 2014 at 09:55:48PM +0100, Maxime Ripard wrote:
> Hi,
> 
> This is the third attempt at documenting how to write a dmaengine
> driver.

Applied all, thanks.

Fixed minor typos in second one.

Also we need to move dmatest.txt to new folder and also update MAINTAINERS,
so applied with these two patches as well

From: Vinod Koul 
Date: Thu, 6 Nov 2014 11:17:37 +0530
Subject: [PATCH 1/2] Documentation: dmanegine: move dmatest.txt to dmaengine 
folder

Signed-off-by: Vinod Koul 
---
 Documentation/{ => dmaengine}/dmatest.txt |0
 1 files changed, 0 insertions(+), 0 deletions(-)
 rename Documentation/{ => dmaengine}/dmatest.txt (100%)

diff --git a/Documentation/dmatest.txt b/Documentation/dmaengine/dmatest.txt
similarity index 100%
rename from Documentation/dmatest.txt
rename to Documentation/dmaengine/dmatest.txt
-- 
1.7.0.4


From: Vinod Koul 
Date: Thu, 6 Nov 2014 11:21:17 +0530
Subject: [PATCH 2/2] MAINTAINERS: add Documentation files to dmaengine entry

We were missing the Documentation files in the entry so add it now. While at
it also remove comment on slave-dma for the tree

Signed-off-by: Vinod Koul 
---
 MAINTAINERS |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index fd3771c..b3f5493 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3080,7 +3080,8 @@ Q:
https://patchwork.kernel.org/project/linux-dmaengine/list/
 S: Maintained
 F: drivers/dma/
 F: include/linux/dma*
-T: git git://git.infradead.org/users/vkoul/slave-dma.git (slave-dma)
+F: Documentation/dmaengine/
+T: git git://git.infradead.org/users/vkoul/slave-dma.git
 
 DME1737 HARDWARE MONITOR DRIVER
 M: Juerg Haefliger 
-- 
1.7.0.4

-- 
~Vinod

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

ipv4: Use standard iovec primitive in raw_probe_proto_opt

2014-11-05 Thread Herbert Xu

On Thu, Nov 06, 2014 at 03:25:34AM +, Al Viro wrote:
>
>   * there's some really weird stuff in there.  Just what is this
> static int raw_probe_proto_opt(struct flowi4 *fl4, struct msghdr *msg)
> {

It looks like newbie coding that's all.  There's nothing tricky
here as far as I can tell.  We're just trying to fetch the ICMP
header to seed the IPsec lookup.

So how about this rewrite? I'm assuming that you're not going
to get rid of memcpy_fromiovecend/memcpy_toiovecend, if you
are, let me know and I'll redo this with iterators.

ipv4: Use standard iovec primitive in raw_probe_proto_opt

The function raw_probe_proto_opt tries to extract the first two
bytes from the user input in order to seed the IPsec lookup for
ICMP packets.  In doing so it's processing iovec by hand and
overcomplicating things.

This patch replaces the manual iovec processing with a call to
memcpy_fromiovecend.

Signed-off-by: Herbert Xu 

diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index 739db31..04f67e1 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -422,48 +422,20 @@ error:
 
 static int raw_probe_proto_opt(struct flowi4 *fl4, struct msghdr *msg)
 {
-   struct iovec *iov;
-   u8 __user *type = NULL;
-   u8 __user *code = NULL;
-   int probed = 0;
-   unsigned int i;
+   struct icmphdr icmph;
+   int err;
 
-   if (!msg->msg_iov)
+   if (fl4->flowi4_proto != IPPROTO_ICMP)
return 0;
 
-   for (i = 0; i < msg->msg_iovlen; i++) {
-   iov = >msg_iov[i];
-   if (!iov)
-   continue;
-
-   switch (fl4->flowi4_proto) {
-   case IPPROTO_ICMP:
-   /* check if one-byte field is readable or not. */
-   if (iov->iov_base && iov->iov_len < 1)
-   break;
-
-   if (!type) {
-   type = iov->iov_base;
-   /* check if code field is readable or not. */
-   if (iov->iov_len > 1)
-   code = type + 1;
-   } else if (!code)
-   code = iov->iov_base;
-
-   if (type && code) {
-   if (get_user(fl4->fl4_icmp_type, type) ||
-   get_user(fl4->fl4_icmp_code, code))
-   return -EFAULT;
-   probed = 1;
-   }
-   break;
-   default:
-   probed = 1;
-   break;
-   }
-   if (probed)
-   break;
-   }
+   /* We only need the first two bytes. */
+   err = memcpy_fromiovecend((void *), msg->msg_iov, 0, 2);
+   if (err)
+   return err;
+
+   fl4->fl4_icmp_type = icmph.type;
+   fl4->fl4_icmp_code = icmph.code;
+
return 0;
 }
 

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 5/5] Xen: switch to linear virtual mapped sparse p2m list

At start of the day the Xen hypervisor presents a contiguous mfn list
to a pv-domain. In order to support sparse memory this mfn list is
accessed via a three level p2m tree built early in the boot process.
Whenever the system needs the mfn associated with a pfn this tree is
used to find the mfn.

Instead of using a software walked tree for accessing a specific mfn
list entry this patch is creating a virtual address area for the
entire possible mfn list including memory holes. The holes are
covered by mapping a pre-defined  page consisting only of "invalid
mfn" entries. Access to a mfn entry is possible by just using the
virtual base address of the mfn list and the pfn as index into that
list. This speeds up the (hot) path of determining the mfn of a
pfn.

Kernel build on a Dell Latitude E6440 (2 cores, HT) in 64 bit Dom0
showed following improvements:

Elapsed time: 32:50 ->  32:35
System:   18:07 ->  17:47
User:104:00 -> 103:30

Tested on 64 bit dom0 and 32 bit domU.

Signed-off-by: Juergen Gross 
---
 arch/x86/include/asm/xen/page.h |  27 +-
 arch/x86/xen/mmu.c  |  34 +-
 arch/x86/xen/p2m.c  | 736 +---
 arch/x86/xen/xen-ops.h  |   2 +-
 4 files changed, 354 insertions(+), 445 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 28fa795..dd65a0c 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -59,6 +59,23 @@ extern int clear_foreign_p2m_mapping(struct 
gnttab_unmap_grant_ref *unmap_ops,
 struct page **pages, unsigned int count);
 extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long 
pfn);
 
+static inline unsigned long __pfn_to_mfn(unsigned long pfn)
+{
+   unsigned long mfn;
+
+   if (pfn < xen_p2m_size)
+   mfn = xen_p2m_addr[pfn];
+   else if (unlikely(pfn < xen_max_p2m_pfn))
+   return get_phys_to_machine(pfn);
+   else
+   return IDENTITY_FRAME(pfn);
+
+   if (unlikely(mfn == INVALID_P2M_ENTRY))
+   return get_phys_to_machine(pfn);
+
+   return mfn;
+}
+
 static inline unsigned long pfn_to_mfn(unsigned long pfn)
 {
unsigned long mfn;
@@ -66,7 +83,7 @@ static inline unsigned long pfn_to_mfn(unsigned long pfn)
if (xen_feature(XENFEAT_auto_translated_physmap))
return pfn;
 
-   mfn = get_phys_to_machine(pfn);
+   mfn = __pfn_to_mfn(pfn);
 
if (mfn != INVALID_P2M_ENTRY)
mfn &= ~(FOREIGN_FRAME_BIT | IDENTITY_FRAME_BIT);
@@ -79,7 +96,7 @@ static inline int phys_to_machine_mapping_valid(unsigned long 
pfn)
if (xen_feature(XENFEAT_auto_translated_physmap))
return 1;
 
-   return get_phys_to_machine(pfn) != INVALID_P2M_ENTRY;
+   return __pfn_to_mfn(pfn) != INVALID_P2M_ENTRY;
 }
 
 static inline unsigned long mfn_to_pfn_no_overrides(unsigned long mfn)
@@ -113,7 +130,7 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
return mfn;
 
pfn = mfn_to_pfn_no_overrides(mfn);
-   if (get_phys_to_machine(pfn) != mfn) {
+   if (__pfn_to_mfn(pfn) != mfn) {
/*
 * If this appears to be a foreign mfn (because the pfn
 * doesn't map back to the mfn), then check the local override
@@ -130,7 +147,7 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
 * valid entry for it.
 */
if (pfn == ~0 &&
-   get_phys_to_machine(mfn) == IDENTITY_FRAME(mfn))
+   __pfn_to_mfn(mfn) == IDENTITY_FRAME(mfn))
pfn = mfn;
 
return pfn;
@@ -176,7 +193,7 @@ static inline unsigned long mfn_to_local_pfn(unsigned long 
mfn)
return mfn;
 
pfn = mfn_to_pfn(mfn);
-   if (get_phys_to_machine(pfn) != mfn)
+   if (__pfn_to_mfn(pfn) != mfn)
return -1; /* force !pfn_valid() */
return pfn;
 }
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index d3e492b..0b43c45 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -387,7 +387,7 @@ static pteval_t pte_pfn_to_mfn(pteval_t val)
unsigned long mfn;
 
if (!xen_feature(XENFEAT_auto_translated_physmap))
-   mfn = get_phys_to_machine(pfn);
+   mfn = __pfn_to_mfn(pfn);
else
mfn = pfn;
/*
@@ -1158,20 +1158,16 @@ static void __init xen_cleanhighmap(unsigned long vaddr,
 * instead of somewhere later and be confusing. */
xen_mc_flush();
 }
-static void __init xen_pagetable_p2m_copy(void)
+
+static void __init xen_pagetable_p2m_free(void)
 {
unsigned long size;
unsigned long addr;
-   unsigned long new_mfn_list;
-
-   if (xen_feature(XENFEAT_auto_translated_physmap))
-   return;
 
size =

[PATCH V2 3/5] xen: Delay invalidating extra memory

When the physical memory configuration is initialized the p2m entries
for not pouplated memory pages are set to "invalid". As those pages
are beyond the hypervisor built p2m list the p2m tree has to be
extended.

This patch delays processing the extra memory related p2m entries
during the boot process until some more basic memory management
functions are callable. This removes the need to create new p2m
entries until virtual memory management is available.

Signed-off-by: Juergen Gross 
---
 arch/x86/include/asm/xen/page.h |   3 +
 arch/x86/xen/p2m.c  | 130 
 arch/x86/xen/setup.c| 103 ++-
 arch/x86/xen/xen-ops.h  |   3 +-
 4 files changed, 107 insertions(+), 132 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index b475297..28fa795 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -41,6 +41,9 @@ typedef struct xpaddr {
 
 extern unsigned long *machine_to_phys_mapping;
 extern unsigned long  machine_to_phys_nr;
+extern unsigned long *xen_p2m_addr;
+extern unsigned long  xen_p2m_size;
+extern unsigned long  xen_max_p2m_pfn;
 
 extern unsigned long get_phys_to_machine(unsigned long pfn);
 extern bool set_phys_to_machine(unsigned long pfn, unsigned long mfn);
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 2647a65..7c409b0 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -181,7 +181,12 @@
 
 static void __init m2p_override_init(void);
 
+unsigned long *xen_p2m_addr __read_mostly;
+EXPORT_SYMBOL_GPL(xen_p2m_addr);
+unsigned long xen_p2m_size __read_mostly;
+EXPORT_SYMBOL_GPL(xen_p2m_size);
 unsigned long xen_max_p2m_pfn __read_mostly;
+EXPORT_SYMBOL_GPL(xen_max_p2m_pfn);
 
 static unsigned long *p2m_mid_missing_mfn;
 static unsigned long *p2m_top_mfn;
@@ -198,13 +203,6 @@ static RESERVE_BRK_ARRAY(unsigned long *, 
p2m_mid_identity, P2M_MID_PER_PAGE);
 
 RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * 
P2M_MID_PER_PAGE)));
 
-/* For each I/O range remapped we may lose up to two leaf pages for the 
boundary
- * violations and three mid pages to cover up to 3GB. With
- * early_can_reuse_p2m_middle() most of the leaf pages will be reused by the
- * remapped region.
- */
-RESERVE_BRK(p2m_identity_remap, PAGE_SIZE * 2 * 3 * MAX_REMAP_RANGES);
-
 static int use_brk = 1;
 
 static inline unsigned p2m_top_index(unsigned long pfn)
@@ -376,12 +374,14 @@ void __init xen_build_dynamic_phys_to_machine(void)
unsigned long max_pfn;
unsigned long pfn;
 
-if (xen_feature(XENFEAT_auto_translated_physmap))
+   if (xen_feature(XENFEAT_auto_translated_physmap))
return;
 
+   xen_p2m_addr = (unsigned long *)xen_start_info->mfn_list;
mfn_list = (unsigned long *)xen_start_info->mfn_list;
max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
xen_max_p2m_pfn = max_pfn;
+   xen_p2m_size = max_pfn;
 
p2m_missing = alloc_p2m_page();
p2m_init(p2m_missing);
@@ -497,6 +497,11 @@ unsigned long __init xen_revector_p2m_tree(void)
/* This should be the leafs allocated for identity from _brk. */
}
 
+   xen_p2m_size = xen_max_p2m_pfn;
+   xen_p2m_addr = mfn_list;
+
+   xen_inv_extra_mem();
+
m2p_override_init();
return (unsigned long)mfn_list;
 }
@@ -504,6 +509,8 @@ unsigned long __init xen_revector_p2m_tree(void)
 unsigned long __init xen_revector_p2m_tree(void)
 {
use_brk = 0;
+   xen_p2m_size = xen_max_p2m_pfn;
+   xen_inv_extra_mem();
m2p_override_init();
return 0;
 }
@@ -512,8 +519,12 @@ unsigned long get_phys_to_machine(unsigned long pfn)
 {
unsigned topidx, mididx, idx;
 
-   if (unlikely(pfn >= MAX_P2M_PFN))
+   if (unlikely(pfn >= xen_p2m_size)) {
+   if (pfn < xen_max_p2m_pfn)
+   return xen_chk_extra_mem(pfn);
+
return IDENTITY_FRAME(pfn);
+   }
 
topidx = p2m_top_index(pfn);
mididx = p2m_mid_index(pfn);
@@ -611,78 +622,12 @@ static bool alloc_p2m(unsigned long pfn)
return true;
 }
 
-static bool __init early_alloc_p2m(unsigned long pfn, bool check_boundary)
-{
-   unsigned topidx, mididx, idx;
-   unsigned long *p2m;
-
-   topidx = p2m_top_index(pfn);
-   mididx = p2m_mid_index(pfn);
-   idx = p2m_index(pfn);
-
-   /* Pfff.. No boundary cross-over, lets get out. */
-   if (!idx && check_boundary)
-   return false;
-
-   WARN(p2m_top[topidx][mididx] == p2m_identity,
-   "P2M[%d][%d] == IDENTITY, should be MISSING (or alloced)!\n",
-   topidx, mididx);
-
-   /*
-* Could be done by xen_build_dynamic_phys_to_machine..
-*/
-   if (p2m_top[topidx][mididx] != p2m_missing)
-   return false;
-
-   /* Boundary cross-over for the edges: */
-   p2m =

[PATCH V2 1/5] Xen: Delay remapping memory of pv-domain

Early in the boot process the memory layout of a pv-domain is changed
to match the E820 map (either the host one for Dom0 or the Xen one)
regarding placement of RAM and PCI holes. This requires removing memory
pages initially located at positions not suitable for RAM and adding
them later at higher addresses where no restrictions apply.

To be able to operate on the hypervisor supported p2m list until a
virtual mapped linear p2m list can be constructed, remapping must
be delayed until virtual memory management is initialized, as the
initial p2m list can't be extended unlimited at physical memory
initialization time due to it's fixed structure.

A further advantage is the reduction in complexity and code volume as
we don't have to be careful regarding memory restrictions during p2m
updates.

Signed-off-by: Juergen Gross 
---
 arch/x86/include/asm/xen/page.h |   1 -
 arch/x86/xen/mmu.c  |   4 +
 arch/x86/xen/p2m.c  | 149 
 arch/x86/xen/setup.c| 385 +++-
 arch/x86/xen/xen-ops.h  |   1 +
 5 files changed, 223 insertions(+), 317 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index c949923..c29619c 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -44,7 +44,6 @@ extern unsigned long  machine_to_phys_nr;
 
 extern unsigned long get_phys_to_machine(unsigned long pfn);
 extern bool set_phys_to_machine(unsigned long pfn, unsigned long mfn);
-extern bool __init early_set_phys_to_machine(unsigned long pfn, unsigned long 
mfn);
 extern bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn);
 extern unsigned long set_phys_range_identity(unsigned long pfn_s,
 unsigned long pfn_e);
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index a8a1a3d..d3e492b 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1223,6 +1223,10 @@ static void __init xen_pagetable_init(void)
/* Allocate and initialize top and mid mfn levels for p2m structure */
xen_build_mfn_list_list();
 
+   /* Remap memory freed because of conflicts with E820 map */
+   if (!xen_feature(XENFEAT_auto_translated_physmap))
+   xen_remap_memory();
+
xen_setup_shared_info();
xen_post_allocator_init();
 }
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index b456b04..49316ac 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -164,6 +164,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -204,6 +205,8 @@ RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / 
(P2M_PER_PAGE * P2M_MID_PER
  */
 RESERVE_BRK(p2m_identity_remap, PAGE_SIZE * 2 * 3 * MAX_REMAP_RANGES);
 
+static int use_brk = 1;
+
 static inline unsigned p2m_top_index(unsigned long pfn)
 {
BUG_ON(pfn >= MAX_P2M_PFN);
@@ -268,6 +271,22 @@ static void p2m_init(unsigned long *p2m)
p2m[i] = INVALID_P2M_ENTRY;
 }
 
+static void * __ref alloc_p2m_page(void)
+{
+   if (unlikely(use_brk))
+   return extend_brk(PAGE_SIZE, PAGE_SIZE);
+
+   if (unlikely(!slab_is_available()))
+   return alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+
+   return (void *)__get_free_page(GFP_KERNEL | __GFP_REPEAT);
+}
+
+static void free_p2m_page(void *p)
+{
+   free_page((unsigned long)p);
+}
+
 /*
  * Build the parallel p2m_top_mfn and p2m_mid_mfn structures
  *
@@ -287,13 +306,13 @@ void __ref xen_build_mfn_list_list(void)
 
/* Pre-initialize p2m_top_mfn to be completely missing */
if (p2m_top_mfn == NULL) {
-   p2m_mid_missing_mfn = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+   p2m_mid_missing_mfn = alloc_p2m_page();
p2m_mid_mfn_init(p2m_mid_missing_mfn, p2m_missing);
 
-   p2m_top_mfn_p = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+   p2m_top_mfn_p = alloc_p2m_page();
p2m_top_mfn_p_init(p2m_top_mfn_p);
 
-   p2m_top_mfn = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+   p2m_top_mfn = alloc_p2m_page();
p2m_top_mfn_init(p2m_top_mfn);
} else {
/* Reinitialise, mfn's all change after migration */
@@ -327,7 +346,7 @@ void __ref xen_build_mfn_list_list(void)
 * missing parts of the mfn tree after
 * runtime.
 */
-   mid_mfn_p = alloc_bootmem_align(PAGE_SIZE, PAGE_SIZE);
+   mid_mfn_p = alloc_p2m_page();
p2m_mid_mfn_init(mid_mfn_p, p2m_missing);
 
p2m_top_mfn_p[topidx] = mid_mfn_p;
@@ -364,17 +383,17 @@ void __init xen_build_dynamic_phys_to_machine(void)
max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
xen_max_p2m_pfn = max_pfn;
 
-   p2m_missing = extend_brk(PAGE_SIZE, PAGE_SIZE);
+   p2m_missing =

[PATCH V2 4/5] x86: Introduce function to get pmd entry pointer

Introduces lookup_pmd_address() to get the address of the pmd entry
related to a virtual address in the current address space. This
function is needed for support of a virtual mapped sparse p2m list
in xen pv domains.

Signed-off-by: Juergen Gross 
---
 arch/x86/include/asm/pgtable_types.h |  1 +
 arch/x86/mm/pageattr.c   | 20 
 2 files changed, 21 insertions(+)

diff --git a/arch/x86/include/asm/pgtable_types.h 
b/arch/x86/include/asm/pgtable_types.h
index 0778964..d83f5e7 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -396,6 +396,7 @@ static inline void update_page_count(int level, unsigned 
long pages) { }
 extern pte_t *lookup_address(unsigned long address, unsigned int *level);
 extern pte_t *lookup_address_in_pgd(pgd_t *pgd, unsigned long address,
unsigned int *level);
+extern pmd_t *lookup_pmd_address(unsigned long address);
 extern phys_addr_t slow_virt_to_phys(void *__address);
 extern int kernel_map_pages_in_pgd(pgd_t *pgd, u64 pfn, unsigned long address,
   unsigned numpages, unsigned long page_flags);
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 36de293..1298108 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -384,6 +384,26 @@ static pte_t *_lookup_address_cpa(struct cpa_data *cpa, 
unsigned long address,
 }
 
 /*
+ * Lookup the PMD entry for a virtual address. Return a pointer to the entry
+ * or NULL if not present.
+ */
+pmd_t *lookup_pmd_address(unsigned long address)
+{
+   pgd_t *pgd;
+   pud_t *pud;
+
+   pgd = pgd_offset_k(address);
+   if (pgd_none(*pgd))
+   return NULL;
+
+   pud = pud_offset(pgd, address);
+   if (pud_none(*pud) || pud_large(*pud) || !pud_present(*pud))
+   return NULL;
+
+   return pmd_offset(pud, address);
+}
+
+/*
  * This is necessary because __pa() does not work on some
  * kinds of memory, like vmalloc() or the alloc_remap()
  * areas on 32-bit NUMA systems.  The percpu areas can
-- 
2.1.2

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

RE: [PATCH 1/2v6] procfs: show hierarchy of pid namespace

2014-11-05 Thread Chen, Hanxiao



> -Original Message-
> From: Richard Weinberger [mailto:rich...@nod.at]
> Sent: Wednesday, November 05, 2014 8:52 PM
> To: Serge E. Hallyn
> Cc: Chen, Hanxiao/陈 晗霄; Eric W. Biederman; Serge Hallyn; Oleg Nesterov;
> contain...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; Mateusz
> Guzik; David Howells
> Subject: Re: [PATCH 1/2v6] procfs: show hierarchy of pid namespace
> 
> Am 05.11.2014 um 13:41 schrieb Serge E. Hallyn:
> > Quoting Richard Weinberger (rich...@nod.at):
> >> Am 05.11.2014 um 11:41 schrieb Chen Hanxiao:
> >>> We lack of pid hierarchy information, and this will lead to:
> >>> a) we don't know pids' relationship, who is whose child:
> >>>/proc/PID/ns/pid only tell us whether two pids live in different ns
> >>> b) bring trouble to nested lxc container check/restore/migration
> >>> c) bring trouble to pid translation between containers;
> >>>
> >>> This patch will show the hierarchy of pid namespace
> >>> by pidns_hierarchy like:
> >>>
> >>> [root@localhost ~]#cat /proc/pidns_hierarchy
> >>> 18060 18102 1534
> >>> 18060 18102 1600
> >>> 1550
> >>
> >> Hmm, what about printing the pid hierarchy in the same way as
> /proc/self/mountinfo
> >> does with mount namespaces?
> >> Your current approach is not bad but we should really try to be consistent
> with existing
> >> sources of information.
> >
> > Good point.  How would you structure it to make it look mor elike mountinfo?
> > Adding the pidns inode number (in place of a mount sequence number) might be
> > useful, but it sounds like you have a more concrete idea?
> 
> Just list  . This way we have exactly one
> information record per line and always exactly two columns to parse.
> 
> e.g.
> [root@localhost ~]#cat /proc/pidns_hierarchy
> 1550 1
> 18060 1
> 18102 18060
> 1534 18102
> 1600 18102
> 
But this style lacks of *level* information:
Ex:
1->18060->18102->1600->1700
If we want to check the 1700's level in pid ns
Style 1:
18060 18102 1600 1700

Style 2:
18060 1
18102 18060
1600 18102
1700 1600

If we had a little more containers,
Style 2 would not be clear enough.
1 line vs $(PID level) line

If there were no more related information to show,
I think style 1 looks better.

Thanks,
- Chen

> >> This function allocates memory per PID. If we have lots of PIDs, how does 
> >> this
> scale?
> >> I'd go so far and say this can be a DoS'able issue if the pidns_hierarchy 
> >> file
> is opened multiple times...
> >
> > It's not per pid, but per init-pid.  For non-reaper pids he bails and 
> > continue
> > through the loop a few lines above.  This still may be DOS-able if users 
> > don't
> > have kmem restrictions to prevent a ton of pid namespaces, but then the
> > namespaces themselves will take a lot more memory than the representation 
> > here.
> 
> Ah, I've overlooked that fact. If it is per init-pid it is not that bad. :-)
> 
> Thanks,
> //richard
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z��wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i

[PATCH V2 0/5] xen: Switch to virtual mapped linear p2m list

Paravirtualized kernels running on Xen use a three level tree for
translation of guest specific physical addresses to machine global
addresses. This p2m tree is used for construction of page table
entries, so the p2m tree walk is performance critical.

By using a linear virtual mapped p2m list accesses to p2m elements
can be sped up while even simplifying code. To achieve this goal
some p2m related initializations have to be performed later in the
boot process, as the final p2m list can be set up only after basic
memory management functions are available.

Changes in V2:
- splitted patch 2 in 4 smaller ones as requested by David Vrabel
- added highmem check when remapping kernel memory as requested by
  David Vrabel

Juergen Gross (5):
  Xen: Delay remapping memory of pv-domain
  xen: Delay m2p_override initialization
  xen: Delay invalidating extra memory
  x86: Introduce function to get pmd entry pointer
  Xen: switch to linear virtual mapped sparse p2m list

 arch/x86/include/asm/pgtable_types.h |1 +
 arch/x86/include/asm/xen/page.h  |   37 +-
 arch/x86/mm/pageattr.c   |   20 +
 arch/x86/xen/mmu.c   |   38 +-
 arch/x86/xen/p2m.c   | 1149 +-
 arch/x86/xen/setup.c |  460 +++---
 arch/x86/xen/xen-ops.h   |6 +-
 7 files changed, 760 insertions(+), 951 deletions(-)

-- 
2.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 V2 2/5] xen: Delay m2p_override initialization

The m2p overrides are used to be able to find the local pfn for a
foreign mfn mapped into the domain. They are used by driver backends
having to access frontend data.

As this functionality isn't used in early boot it makes no sense to
initialize the m2p override functions very early. It can be done
later without doing any harm, removing the need for allocating memory
via extend_brk().

While at it make some m2p override functions static as they are only
used internally.

Signed-off-by: Juergen Gross 
---
 arch/x86/include/asm/xen/page.h |   6 --
 arch/x86/xen/p2m.c  | 198 
 2 files changed, 101 insertions(+), 103 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index c29619c..b475297 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -51,15 +51,9 @@ extern unsigned long set_phys_range_identity(unsigned long 
pfn_s,
 extern int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
   struct gnttab_map_grant_ref *kmap_ops,
   struct page **pages, unsigned int count);
-extern int m2p_add_override(unsigned long mfn, struct page *page,
-   struct gnttab_map_grant_ref *kmap_op);
 extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 struct gnttab_map_grant_ref *kmap_ops,
 struct page **pages, unsigned int count);
-extern int m2p_remove_override(struct page *page,
-  struct gnttab_map_grant_ref *kmap_op,
-  unsigned long mfn);
-extern struct page *m2p_find_override(unsigned long mfn);
 extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long 
pfn);
 
 static inline unsigned long pfn_to_mfn(unsigned long pfn)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 49316ac..2647a65 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -426,8 +426,6 @@ void __init xen_build_dynamic_phys_to_machine(void)
}
p2m_top[topidx][mididx] = _list[pfn];
}
-
-   m2p_override_init();
 }
 #ifdef CONFIG_X86_64
 unsigned long __init xen_revector_p2m_tree(void)
@@ -498,13 +496,15 @@ unsigned long __init xen_revector_p2m_tree(void)
}
/* This should be the leafs allocated for identity from _brk. */
}
-   return (unsigned long)mfn_list;
 
+   m2p_override_init();
+   return (unsigned long)mfn_list;
 }
 #else
 unsigned long __init xen_revector_p2m_tree(void)
 {
use_brk = 0;
+   m2p_override_init();
return 0;
 }
 #endif
@@ -794,15 +794,16 @@ bool set_phys_to_machine(unsigned long pfn, unsigned long 
mfn)
 #define M2P_OVERRIDE_HASH_SHIFT10
 #define M2P_OVERRIDE_HASH  (1 << M2P_OVERRIDE_HASH_SHIFT)
 
-static RESERVE_BRK_ARRAY(struct list_head, m2p_overrides, M2P_OVERRIDE_HASH);
+static struct list_head *m2p_overrides;
 static DEFINE_SPINLOCK(m2p_override_lock);
 
 static void __init m2p_override_init(void)
 {
unsigned i;
 
-   m2p_overrides = extend_brk(sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
-  sizeof(unsigned long));
+   m2p_overrides = alloc_bootmem_align(
+   sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
+   sizeof(unsigned long));
 
for (i = 0; i < M2P_OVERRIDE_HASH; i++)
INIT_LIST_HEAD(_overrides[i]);
@@ -813,67 +814,8 @@ static unsigned long mfn_hash(unsigned long mfn)
return hash_long(mfn, M2P_OVERRIDE_HASH_SHIFT);
 }
 
-int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
-   struct gnttab_map_grant_ref *kmap_ops,
-   struct page **pages, unsigned int count)
-{
-   int i, ret = 0;
-   bool lazy = false;
-   pte_t *pte;
-
-   if (xen_feature(XENFEAT_auto_translated_physmap))
-   return 0;
-
-   if (kmap_ops &&
-   !in_interrupt() &&
-   paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
-   arch_enter_lazy_mmu_mode();
-   lazy = true;
-   }
-
-   for (i = 0; i < count; i++) {
-   unsigned long mfn, pfn;
-
-   /* Do not add to override if the map failed. */
-   if (map_ops[i].status)
-   continue;
-
-   if (map_ops[i].flags & GNTMAP_contains_pte) {
-   pte = (pte_t *) 
(mfn_to_virt(PFN_DOWN(map_ops[i].host_addr)) +
-   (map_ops[i].host_addr & ~PAGE_MASK));
-   mfn = pte_mfn(*pte);
-   } else {
-   mfn = PFN_DOWN(map_ops[i].dev_bus_addr);
-   }
-   pfn = page_to_pfn(pages[i]);
-
-   WARN_ON(PagePrivate(pages[i]));
-

linux-next: build failure after merge of the akpm-current tree

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

mm/fremap.c: In function 'SYSC_remap_file_pages':
mm/fremap.c:241:22: error: 'struct address_space' has no member named 
'i_mmap_mutex'
   mutex_lock(>i_mmap_mutex);
  ^
mm/fremap.c:247:24: error: 'struct address_space' has no member named 
'i_mmap_mutex'
   mutex_unlock(>i_mmap_mutex);
^

Caused by commit 1f8c97e79f66 ("mm: convert i_mmap_mutex to rwsem").

I applied this patch for today (not sure if there is a better way):

From: Stephen Rothwell 
Date: Thu, 6 Nov 2014 16:26:41 +1100
Subject: [PATCH] mm: convert i_mmap_mutex to rwsem fix

Signed-off-by: Stephen Rothwell 
---
 mm/fremap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/fremap.c b/mm/fremap.c
index 9129013732d7..2805d71cf476 100644
--- a/mm/fremap.c
+++ b/mm/fremap.c
@@ -238,13 +238,13 @@ get_write_lock:
}
goto out_freed;
}
-   mutex_lock(>i_mmap_mutex);
+   i_mmap_lock_write(mapping);
flush_dcache_mmap_lock(mapping);
vma->vm_flags |= VM_NONLINEAR;
vma_interval_tree_remove(vma, >i_mmap);
vma_nonlinear_insert(vma, >i_mmap_nonlinear);
flush_dcache_mmap_unlock(mapping);
-   mutex_unlock(>i_mmap_mutex);
+   i_mmap_unlock_write(mapping);
}
 
if (vma->vm_flags & VM_LOCKED) {
-- 
2.1.1

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpJyVyQuM1HE.pgp
Description: OpenPGP digital signature

Re: [Patch Part2 v4 21/31] PCI/MSI: enhance PCI MSI core to support hierarchy irqdomain

2014-11-05 Thread Yijing Wang

On 2014/11/6 13:06, Jiang Liu wrote:
> On 2014/11/6 9:58, Yijing Wang wrote:
  
 @@ -1098,3 +1099,128 @@ int pci_enable_msix_range(struct pci_dev *dev, 
 struct msix_entry *entries,
return nvec;
  }
  EXPORT_SYMBOL(pci_enable_msix_range);
 +
 +#ifdefCONFIG_PCI_MSI_IRQ_DOMAIN
>>>
>>> Space, not tab.
>>>
 +static inline irq_hw_number_t
 +msi_get_hwirq(struct pci_dev *pdev, struct msi_desc *msidesc)
>>>
>>> The convention in this file is "struct pci_dev *dev".  And "struct msi_desc
>>> *desc" (or maybe "*entry").  Try to converge things, not diverge them.
>>>
 +{
 +  return (irq_hw_number_t)msidesc->msi_attrib.entry_nr |
 +  PCI_DEVID(pdev->bus->number, pdev->devfn) << 11 |
 +  (pci_domain_nr(pdev->bus) & 0x) << 27;
>>>
>>> Where does this bit layout come from?  Is this defined in the spec
>>> somewhere?  A reference would help.
>>
>> Currently, more and more Non-PCI device use MSI(or similar MSI mechanism), 
>> like DMAR fault irq
>> and HPET FSB irq. And we have to add additional code to support the MSI 
>> capability.
>> So I hope we can decouple MSI code and PCI code, then we can unify all 
>> MSI(or Message Based interrupt)
>> in one framework.
> Hi Yijing,
>   I have a following patch to share more code among MSI/DMAR/HPET,
> which is one step forward as you suggested. Will send out that patch set
> soon.

That's Great! :)

> Regards!
> Gerry
> 
>>
>> Thanks!
>> Yijing.
>>
>>>
 +}
 +
 +static int msi_domain_alloc(struct irq_domain *domain, unsigned int virq,
 +  unsigned int nr_irqs, void *arg)
 +{
 +  int i, ret;
 +  irq_hw_number_t hwirq = arch_msi_irq_domain_get_hwirq(arg);
 +
 +  if (irq_find_mapping(domain, hwirq) > 0)
 +  return -EEXIST;
 +
 +  ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, arg);
 +  if (ret >= 0)
>>>
>>> if (ret < 0)
>>> return ret;
>>>
>>> and un-indent the mainline code below.  Then it's obvious that this is the
>>> normal case, not the error case.
>>>
 +  for (i = 0; i < nr_irqs; i++) {
 +  irq_domain_set_hwirq_and_chip(domain, virq + i,
 +  hwirq + i, _chip, (void *)(long)i);
 +  __irq_set_handler(virq + i, handle_edge_irq, 0, "edge");
 +  }
 +
 +  return ret;
 +}
 +
 +static void msi_domain_free(struct irq_domain *domain, unsigned int virq,
 +  unsigned int nr_irqs)
 +{
 +  int i;
 +
 +  for (i = 0; i < nr_irqs; i++) {
 +  struct msi_desc *msidesc = irq_get_msi_desc(virq);
 +
 +  if (msidesc)
 +  msidesc->irq = 0;
 +  }
 +  irq_domain_free_irqs_top(domain, virq, nr_irqs);
 +}
 +
 +static int msi_domain_activate(struct irq_domain *domain,
 + struct irq_data *irq_data)
 +{
 +  int ret = 0;
 +  struct msi_msg msg;
 +
 +  /*
 +   * irq_data->chip_data is MSI/MSIx offset.
>>>
>>> "MSI-X", as you wrote on the next line.
>>>
 +   * MSI-X message is written per-IRQ, the offset is always 0.
 +   * MSI message denotes a contiguous group of IRQs, written for 0th IRQ.
 +   */
 +  if (!irq_data->chip_data) {
>>>
>>> if (irq_data->chip_data)
>>> return 0;
>>>
>>> and un-indent the mainline code below, and drop the "ret = 0" init above.
>>>
 +  ret = irq_chip_compose_msi_msg(irq_data, );
 +  if (ret == 0)
>>>
>>> if (ret)
>>> return ret;
>>>
 +  write_msi_msg(irq_data->irq, );
 +  }
 +
 +  return ret;
>>> return 0;
 +}
 +
 +static int msi_domain_deactivate(struct irq_domain *domain,
 +   struct irq_data *irq_data)
 +{
 +  struct msi_msg msg;
 +
 +  if (irq_data->chip_data) {
 +  memset(, 0, sizeof(msg));
 +  write_msi_msg(irq_data->irq, );
 +  }
 +
 +  return 0;
 +}
 +
 +static struct irq_domain_ops msi_domain_ops = {
 +  .alloc = msi_domain_alloc,
 +  .free = msi_domain_free,
 +  .activate = msi_domain_activate,
 +  .deactivate = msi_domain_deactivate,
 +};
 +
 +struct irq_domain *msi_create_irq_domain(struct irq_domain *parent)
 +{
 +  struct irq_domain *domain;
 +
 +  domain = irq_domain_add_tree(NULL, _domain_ops, NULL);
 +  if (domain)
>>>
>>> if (!domain)
>>> return NULL;
>>>
>>> and un-indent this:
>>>
 +  domain->parent = parent;
 +
 +  return domain;
 +}
 +
 +int msi_irq_domain_alloc_irqs(struct irq_domain *domain, int type,
 +struct pci_dev *dev, void *arg)
 +{
 +  int i, virq;
 +  struct msi_desc *msidesc;
 +  int node = dev_to_node(>dev);
 +
 +

[PATCH] x86/mm: Give the correct initail value to the pmd_idx

2014-11-05 Thread Minfei Huang

The variable value is undefined from the stack eara. So it makes sense to
init the variable to run process correctly.

If the variable pmd_idx inits the value more than PTRS_PER_PMD, the
count may be smaller than the correct value, and the allocated page may
be not enough for pte entry.

The kernel may panic cause by the undefine variable which is allocated
from stack.

Signed-off-by: Minfei Huang 
---
 arch/x86/mm/init_32.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index c8140e1..c23ab1e 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -137,6 +137,7 @@ page_table_range_init_count(unsigned long start, unsigned 
long end)
 
vaddr = start;
pgd_idx = pgd_index(vaddr);
+   pmd_idx = pmd_index(vaddr);
 
for ( ; (pgd_idx < PTRS_PER_PGD) && (vaddr != end); pgd_idx++) {
for (; (pmd_idx < PTRS_PER_PMD) && (vaddr != end);
-- 
1.8.3.1

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

RE: [PATCH v2] staging:rtl8723au: core: Fix error reported by checkpatch.

2014-11-05 Thread Sharma, Sanjeev

-Original Message-
From: Joe Perches [mailto:j...@perches.com] 
Sent: Wednesday, November 05, 2014 10:46 PM
To: Sharma, Sanjeev
Cc: larry.fin...@lwfinger.net; jes.soren...@redhat.com; 
gre...@linuxfoundation.org; linux-wirel...@vger.kernel.org; 
de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] staging:rtl8723au: core: Fix error reported by 
checkpatch.

On Wed, 2014-11-05 at 17:05 +0530, Sanjeev Sharma wrote:
> This is a patch to the rtw_cmd.c file that fixes Error reported by 
> checkpatch.

Please run your patches through checkpatch before sending them.

In this patch I am fixing error reported by check patch since Error has higher 
priority. 

WARNING: suspect code indent for conditional statements (24, 24)
#178: FILE: drivers/staging/rtl8723au/core/rtw_cmd.c:1025:
+   if (check_fwstate(pmlmepriv, _FW_LINKED))
LPS_Leave23a(padapter);

Also, there are a couple of different things you changing here.

This should be 2 separate patches.

Ok I will come up with 2 patch separately.

One to use the temporary for:
+   struct rt_link_detect *ldi = >LinkDetectInfo;

(and that bit has a defect here:


+   } else {
LPS_Leave23a(padapter);
+   }

where the indentation for the last close brace is wrong)

and another for the whitespace only changes


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

Re: [PATCH] PCI: Do not enable async suspend for JMicron chips

2014-11-05 Thread Aaron Lu

On 11/06/2014 01:29 PM, Liu, Chuansheng wrote:
> Hello Bjorn,
> 
>> -Original Message-
>> From: Bjorn Helgaas [mailto:bhelg...@google.com]
>> Sent: Thursday, November 06, 2014 12:09 PM
>> To: Liu, Chuansheng
>> Cc: Barto; Tejun Heo (t...@kernel.org); Lu, Aaron; Rafael Wysocki;
>> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH] PCI: Do not enable async suspend for JMicron chips
>>
>> On Wed, Nov 5, 2014 at 6:48 PM, Liu, Chuansheng
>>  wrote:
>>> Hello Bjorn,
>>>
 -Original Message-
 From: Bjorn Helgaas [mailto:bhelg...@google.com]
 Sent: Thursday, November 06, 2014 3:04 AM
 To: Barto
 Cc: Liu, Chuansheng; Lu, Aaron; Tejun Heo; Rafael Wysocki;
 linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
 Subject: Re: [PATCH] PCI: Do not enable async suspend for JMicron chips

 On Wed, Nov 5, 2014 at 11:46 AM, Barto 
 wrote:
> this patch solves these 2 bug reports :
>
> https://bugzilla.kernel.org/show_bug.cgi?id=84861
>
> https://bugzilla.kernel.org/show_bug.cgi?id=81551

 Those bugs were already mentioned.  But e6b7e41cdd8c claims to solve
 https://bugzilla.kernel.org/show_bug.cgi?id=81551, and 84861 is a
 duplicate of 81551, so it should also be fixed by e6b7e41cdd8c.

 So the question is, why was e6b7e41cdd8c insufficient?  Presumably it
 was tested and somebody thought it did fix the problem.
>>>
>>> The first patch e6b7e41cdd8c which is just exclude some of JMicron
>> chips(363/361) out of async_suspend,
>>> then Barto found the same issue on JMicron 368, so we need one more
>> general patch to let JMicron chips
>>> out of async_suspend, so we make this patch.
>>>
>>> Bjorn, tj,
>>> Could you kindly take this patch? As Barto said, it effected the user
>> experience indeed, thanks.
>>
>> Thanks for clarifying the changelog as far as the different chips and
>> the different bugzillas.
>>
>> But you haven't addressed my concerns about (1) putting a PCI vendor
>> ID check in the generic PCI core code, and (2) applying this to *all*
>> JMicron devices.  You might want to explore a quirk-type solution or
>> maybe just add the JMicron 368 to the checks added by e6b7e41cdd8c.
> Understand your point, in fact, before this patch submitted, I had written 
> another patch https://lkml.org/lkml/2014/9/24/68
> which addressed to add the quirk-type solution in ATA code, and Aaron given 
> better suggestion that implemented at pci_pm_init().
> How do you think of it? Thanks.

I think Bjorn means that we should place the code as a fixup somewhere
in the quirks.c. I didn't take a closer look but DECLARE_PCI_FIXUP_FINAL
for those JMicron PCI devices seems to be a proper phase.

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

Re: Re: [PATCH v4 5/5] perf/sdt: Add support to perf record to trace SDT events

2014-11-05 Thread Masami Hiramatsu

(2014/11/06 11:15), Josh Stone wrote:
> On 11/05/2014 01:05 AM, Masami Hiramatsu wrote:
>> [Off topic] I really don't like that the current SDT's semaphore. If the 
>> user apps
>> see the instruction at the probe point, it is easy to check whether the 
>> event is
>> enabled or not. Thus I recommend to change its implementation and update 
>> version
>> instead of supporting current semaphore by perftools.
> 
> You and I have banged heads on this before, but I don't think checking
> the instruction is a simple as you seem to think.  I invite you to
> prototype this, and if you get it working we can discuss the tradeoffs.

Would you have the prototype? I'd like to look :)

> The good news is that other tools (stap and gdb) won't need to care.  If
> the SDT semaphore goes automatic, then we can just set that note field
> to zero, unused from the tool's perspective.
> 
> Another tactic is to just discourage developers from using the semaphore
> in the first place, as it's a completely optional feature.  The marker
> is just a NOP, so adding some "if (enabled) {...}" around it is often a
> useless load and branch.  It does make sense if the probe wants to
> provide some expensively-computed arguments though, like cpython does to
> prepare a function name string.  So if you see a project testing the
> semaphore around simple arguments, I'd suggest they just probe directly
> instead.

I see, and we did that on qemu. I consider that someone maybe use
it in the future unless we remove it. If we can succeed to discourage
people using semaphore, we also should remove it.

Thank you,


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


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

RE: [PATCH] PCI: Do not enable async suspend for JMicron chips

2014-11-05 Thread Liu, Chuansheng

Hello Bjorn,

> -Original Message-
> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> Sent: Thursday, November 06, 2014 12:09 PM
> To: Liu, Chuansheng
> Cc: Barto; Tejun Heo (t...@kernel.org); Lu, Aaron; Rafael Wysocki;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] PCI: Do not enable async suspend for JMicron chips
> 
> On Wed, Nov 5, 2014 at 6:48 PM, Liu, Chuansheng
>  wrote:
> > Hello Bjorn,
> >
> >> -Original Message-
> >> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> >> Sent: Thursday, November 06, 2014 3:04 AM
> >> To: Barto
> >> Cc: Liu, Chuansheng; Lu, Aaron; Tejun Heo; Rafael Wysocki;
> >> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> >> Subject: Re: [PATCH] PCI: Do not enable async suspend for JMicron chips
> >>
> >> On Wed, Nov 5, 2014 at 11:46 AM, Barto 
> >> wrote:
> >> > this patch solves these 2 bug reports :
> >> >
> >> > https://bugzilla.kernel.org/show_bug.cgi?id=84861
> >> >
> >> > https://bugzilla.kernel.org/show_bug.cgi?id=81551
> >>
> >> Those bugs were already mentioned.  But e6b7e41cdd8c claims to solve
> >> https://bugzilla.kernel.org/show_bug.cgi?id=81551, and 84861 is a
> >> duplicate of 81551, so it should also be fixed by e6b7e41cdd8c.
> >>
> >> So the question is, why was e6b7e41cdd8c insufficient?  Presumably it
> >> was tested and somebody thought it did fix the problem.
> >
> > The first patch e6b7e41cdd8c which is just exclude some of JMicron
> chips(363/361) out of async_suspend,
> > then Barto found the same issue on JMicron 368, so we need one more
> general patch to let JMicron chips
> > out of async_suspend, so we make this patch.
> >
> > Bjorn, tj,
> > Could you kindly take this patch? As Barto said, it effected the user
> experience indeed, thanks.
> 
> Thanks for clarifying the changelog as far as the different chips and
> the different bugzillas.
> 
> But you haven't addressed my concerns about (1) putting a PCI vendor
> ID check in the generic PCI core code, and (2) applying this to *all*
> JMicron devices.  You might want to explore a quirk-type solution or
> maybe just add the JMicron 368 to the checks added by e6b7e41cdd8c.
Understand your point, in fact, before this patch submitted, I had written 
another patch https://lkml.org/lkml/2014/9/24/68
which addressed to add the quirk-type solution in ATA code, and Aaron given 
better suggestion that implemented at pci_pm_init().
How do you think of it? Thanks.


N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH] PCI: Do not enable async suspend for JMicron chips

2014-11-05 Thread Barto

Hello Bjorn,

in my bugreport I have already tried to add the JMicron 368 in the "if
statement" and it didn't work, check my message here :

https://bugzilla.kernel.org/show_bug.cgi?id=84861#c11

if Chuansheng has choosen a more generic way ( applying the patch to all
JMicron devices  ) it's because also because we don't know how many
JMBxxx models could be affected by this bug, tomorrow maybe one user
would create a bug report about a "JMB369" pci card who have again this
bug, and maybe on month later another user with a "JMB382", it could be
a nightmare for Chuanseng if he had to create every time a new patch for
each model of JMicron,

so for the moment the better approach for me is to disable async_suspend
for all JMBxxx JMicron, Chuanseng's patch seems reasonnable, as long as
we don't know the exact list of JMBxxx models we can assume that all
JMicron SATA/IDE are affected by this problem


Le 06/11/2014 05:08, Bjorn Helgaas a écrit :

> 
> But you haven't addressed my concerns about (1) putting a PCI vendor
> ID check in the generic PCI core code, and (2) applying this to *all*
> JMicron devices.  You might want to explore a quirk-type solution or
> maybe just add the JMicron 368 to the checks added by e6b7e41cdd8c.
> 
> Bjorn
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 Part2 v4 21/31] PCI/MSI: enhance PCI MSI core to support hierarchy irqdomain

On Wed, Nov 5, 2014 at 9:58 PM, Jiang Liu  wrote:
> On 2014/11/6 7:09, Bjorn Helgaas wrote:
>> On Tue, Nov 04, 2014 at 08:01:55PM +0800, Jiang Liu wrote:

>>> +{
>>> +return (irq_hw_number_t)msidesc->msi_attrib.entry_nr |
>>> +PCI_DEVID(pdev->bus->number, pdev->devfn) << 11 |
>>> +(pci_domain_nr(pdev->bus) & 0x) << 27;
>>
>> Where does this bit layout come from?  Is this defined in the spec
>> somewhere?  A reference would help.
> We need a unique number to identify every possible MSI source,
> and this ID number is only used within the irqdomain subsystem.
> So we used above algorithm to generate the ID number, there's
> no specification for it.

A comment to that effect would be great.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: bcm2835: add device tree for Raspberry Pi model B+

On 11/05/2014 04:45 PM, Matthias Klein wrote:
> The model B and B+ differ in the GPIO lines for ACT and PWR leds, and the
> I2S interface.

BTW, according to:

http://raspberryalphaomega.org.uk/2013/02/06/automatic-raspberry-pi-board-revision-detection-model-a-b1-and-b2/

... there are actually 2 different HW configurations we care about for
the pre-plus Pis:

B rev 1
A, or B rev 2

I guess we should have separate device trees for those, since there are
some differences in the GPIO and I2C channel usage. That'd leave us with:

bcm2835-rpi-b.dts (Pin3=GPIO0, Pin5=GPIO1, Pin13=GPIO21, I2C-0)
bcm2835-rpi-b-rev2.dts (Pin3=GPIO1, Pin5=GPIO2, Pin13=GPIO27, 12C-1)
bcm2835-rpi-b-plus.dts (TBD pending schematic or equivalent info)
... and probably another for the compute board.

We can ignore RAM size differences, since these are automatically filled
into the /memory node in DT. I'm not sure if A-vs-B-rev-1 is
interesting. Perhaps we should have separate DTs just in case, since we
may need to represent the LAN_RUN GPIO in DT at some point, and that
only applies to the B.

Presumably, the boot loader would automatically query the VC firmware
for the board revision data, and dynamically load the appropriate DT
filename.

Any thoughts or objections?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: bcm2835: add device tree for Raspberry Pi model B+

On 11/05/2014 04:45 PM, Matthias Klein wrote:
> The model B and B+ differ in the GPIO lines for ACT and PWR leds, and the
> I2S interface.

Tested-by: Stephen Warren 

(On a model B rev 2, UART, SD card, and enumeration of built-in USB
devices works fine)

Lee, how do you want to handle patches - will you apply them to the git
repo?

Matthias, BTW, you should CC linux-arm-ker...@lists.infradead.org too;
possibly you can use that to replace the main
linux-kernel@vger.kernel.org mailing list.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 Part2 v4 21/31] PCI/MSI: enhance PCI MSI core to support hierarchy irqdomain

On 2014/11/6 9:58, Yijing Wang wrote:
>>>  
>>> @@ -1098,3 +1099,128 @@ int pci_enable_msix_range(struct pci_dev *dev, 
>>> struct msix_entry *entries,
>>> return nvec;
>>>  }
>>>  EXPORT_SYMBOL(pci_enable_msix_range);
>>> +
>>> +#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
>>
>> Space, not tab.
>>
>>> +static inline irq_hw_number_t
>>> +msi_get_hwirq(struct pci_dev *pdev, struct msi_desc *msidesc)
>>
>> The convention in this file is "struct pci_dev *dev".  And "struct msi_desc
>> *desc" (or maybe "*entry").  Try to converge things, not diverge them.
>>
>>> +{
>>> +   return (irq_hw_number_t)msidesc->msi_attrib.entry_nr |
>>> +   PCI_DEVID(pdev->bus->number, pdev->devfn) << 11 |
>>> +   (pci_domain_nr(pdev->bus) & 0x) << 27;
>>
>> Where does this bit layout come from?  Is this defined in the spec
>> somewhere?  A reference would help.
> 
> Currently, more and more Non-PCI device use MSI(or similar MSI mechanism), 
> like DMAR fault irq
> and HPET FSB irq. And we have to add additional code to support the MSI 
> capability.
> So I hope we can decouple MSI code and PCI code, then we can unify all MSI(or 
> Message Based interrupt)
> in one framework.
Hi Yijing,
I have a following patch to share more code among MSI/DMAR/HPET,
which is one step forward as you suggested. Will send out that patch set
soon.
Regards!
Gerry

> 
> Thanks!
> Yijing.
> 
>>
>>> +}
>>> +
>>> +static int msi_domain_alloc(struct irq_domain *domain, unsigned int virq,
>>> +   unsigned int nr_irqs, void *arg)
>>> +{
>>> +   int i, ret;
>>> +   irq_hw_number_t hwirq = arch_msi_irq_domain_get_hwirq(arg);
>>> +
>>> +   if (irq_find_mapping(domain, hwirq) > 0)
>>> +   return -EEXIST;
>>> +
>>> +   ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, arg);
>>> +   if (ret >= 0)
>>
>>  if (ret < 0)
>>  return ret;
>>
>> and un-indent the mainline code below.  Then it's obvious that this is the
>> normal case, not the error case.
>>
>>> +   for (i = 0; i < nr_irqs; i++) {
>>> +   irq_domain_set_hwirq_and_chip(domain, virq + i,
>>> +   hwirq + i, _chip, (void *)(long)i);
>>> +   __irq_set_handler(virq + i, handle_edge_irq, 0, "edge");
>>> +   }
>>> +
>>> +   return ret;
>>> +}
>>> +
>>> +static void msi_domain_free(struct irq_domain *domain, unsigned int virq,
>>> +   unsigned int nr_irqs)
>>> +{
>>> +   int i;
>>> +
>>> +   for (i = 0; i < nr_irqs; i++) {
>>> +   struct msi_desc *msidesc = irq_get_msi_desc(virq);
>>> +
>>> +   if (msidesc)
>>> +   msidesc->irq = 0;
>>> +   }
>>> +   irq_domain_free_irqs_top(domain, virq, nr_irqs);
>>> +}
>>> +
>>> +static int msi_domain_activate(struct irq_domain *domain,
>>> +  struct irq_data *irq_data)
>>> +{
>>> +   int ret = 0;
>>> +   struct msi_msg msg;
>>> +
>>> +   /*
>>> +* irq_data->chip_data is MSI/MSIx offset.
>>
>> "MSI-X", as you wrote on the next line.
>>
>>> +* MSI-X message is written per-IRQ, the offset is always 0.
>>> +* MSI message denotes a contiguous group of IRQs, written for 0th IRQ.
>>> +*/
>>> +   if (!irq_data->chip_data) {
>>
>>  if (irq_data->chip_data)
>>  return 0;
>>
>> and un-indent the mainline code below, and drop the "ret = 0" init above.
>>
>>> +   ret = irq_chip_compose_msi_msg(irq_data, );
>>> +   if (ret == 0)
>>
>>  if (ret)
>>  return ret;
>>
>>> +   write_msi_msg(irq_data->irq, );
>>> +   }
>>> +
>>> +   return ret;
>>  return 0;
>>> +}
>>> +
>>> +static int msi_domain_deactivate(struct irq_domain *domain,
>>> +struct irq_data *irq_data)
>>> +{
>>> +   struct msi_msg msg;
>>> +
>>> +   if (irq_data->chip_data) {
>>> +   memset(, 0, sizeof(msg));
>>> +   write_msi_msg(irq_data->irq, );
>>> +   }
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +static struct irq_domain_ops msi_domain_ops = {
>>> +   .alloc = msi_domain_alloc,
>>> +   .free = msi_domain_free,
>>> +   .activate = msi_domain_activate,
>>> +   .deactivate = msi_domain_deactivate,
>>> +};
>>> +
>>> +struct irq_domain *msi_create_irq_domain(struct irq_domain *parent)
>>> +{
>>> +   struct irq_domain *domain;
>>> +
>>> +   domain = irq_domain_add_tree(NULL, _domain_ops, NULL);
>>> +   if (domain)
>>
>>  if (!domain)
>>  return NULL;
>>
>> and un-indent this:
>>
>>> +   domain->parent = parent;
>>> +
>>> +   return domain;
>>> +}
>>> +
>>> +int msi_irq_domain_alloc_irqs(struct irq_domain *domain, int type,
>>> + struct pci_dev *dev, void *arg)
>>> +{
>>> +   int i, virq;
>>> +   struct msi_desc *msidesc;
>>> +   int node = dev_to_node(>dev);
>>> +
>>> +   list_for_each_entry(msidesc, >msi_list, list) {
>>> +   arch_msi_irq_domain_set_hwirq(arg, msi_get_hwirq(dev, msidesc));
>>> +   virq =

[git pull] vfs.git fixes

2014-11-05 Thread Al Viro

A fix for embarrassing braino in o2net_send_tcp_msg().  -stable
fodder...  Please, pull from the usual place -
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus

Shortlog:
Al Viro (1):
  fix breakage in o2net_send_tcp_msg()

Diffstat:
 fs/ocfs2/cluster/tcp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the usb tree with the usb.current tree

Hi all,

On Wed, 5 Nov 2014 18:19:34 -0800 Greg KH  wrote:
>
> On Wed, Nov 05, 2014 at 09:33:33AM +0100, Paul Bolle wrote:
> > On Tue, 2014-11-04 at 20:30 -0800, Greg KH wrote:
> > > On Wed, Nov 05, 2014 at 03:18:25PM +1100, Stephen Rothwell wrote: 
> > > > Today's linux-next merge of the usb tree got a conflict in
> > > > drivers/usb/host/Kconfig between commit cd6e245a2d06 ("usb: Remove
> > > > references to non-existent PLAT_S5P symbol") from the usb.current tree
> > > > and commit dd3cf17488b1 ("usb: host: Remove optional dependencies on
> > > > PLAT_S5P") from the usb tree.
> > > > 
> > > > I fixed it up (I used the usb tree version) and can carry the fix as
> > > > necessary (no action is required).
> > > 
> > > That's the correct fix, thanks for doing that.
> > 
> > Shouldn't that be the other way round?
> 
> Sorry, you are right, I read the merge backwards.

OK, I did that in today'y tree.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpB9d5WMXOZb.pgp
Description: OpenPGP digital signature

Re: [PATCHv2 4/5] mmc: shdci-bcm2835: add verify for 32-bit back-to-back workaround

On 11/05/2014 12:00 AM, Scott Branden wrote:
> On 14-11-04 08:59 PM, Stephen Warren wrote:
>> On 10/30/2014 12:36 AM, Scott Branden wrote:
>>> Add a verify option to driver to print out an error message if a
>>> potential back to back write could cause a clock domain issue.
>>
>>> index f8c450a..11af27f 100644
>>
>>> +#ifdef CONFIG_MMC_SDHCI_BCM2835_VERIFY_WORKAROUND
>>> +struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>> +struct bcm2835_sdhci_host *bcm2835_host = pltfm_host->priv;
>>> +
>>> +if (bcm2835_host->previous_reg == reg) {
>>> +if ((reg != SDHCI_HOST_CONTROL)
>>> +&& (reg != SDHCI_CLOCK_CONTROL)) {
>>
>> The comment in patch 3 says the problem doesn't apply to the data
>> register. Why does this check for these two registers rather than data?
> This Verify workaround patch still a work in progress.  I'm still
> getting more info from the silicon designers on the back-to-back
> register writes that are affect.  The spew of 0x20 or 0x28 or 0x2c
> register writes are all ok locations that don't need to be worked
> around.  This patch needs to be corrected with the proper register rules
> still.

FYI, I applied the series except for this patch, and everything
/appeared/ to work OK for a brief test (boot, log in, reboot). Still,
I'll hold off my Tested-by/acked-by until the comment in patch 3 and the
register list above match, and there's no log spew with everything applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the usb-gadget tree with the usb tree

2014-11-05 Thread Felipe Balbi

On Thu, Nov 06, 2014 at 02:58:32PM +1100, Stephen Rothwell wrote:
> Hi Felipe,
> 
> Today's linux-next merge of the usb-gadget tree got a conflict in
> drivers/usb/chipidea/otg_fsm.c between commit 51f1741fcc16 ("usb:
> chipidea: otg_fsm: delete unnecessary 'out of memory' messages") from
> the usb tree and commit ef44cb4226d1 ("usb: allow to supply the PHY in
> the drivers when using HCD") from the usb-gadget tree.
> 
> I fixed it up (the latter removed the code modified by the former) and
> can carry the fix as necessary (no action is required).

Alright, thanks for fixing it up.

-- 
balbi


signature.asc
Description: Digital signature

Re: [Patch Part2 v4 21/31] PCI/MSI: enhance PCI MSI core to support hierarchy irqdomain

On 2014/11/6 7:09, Bjorn Helgaas wrote:
> On Tue, Nov 04, 2014 at 08:01:55PM +0800, Jiang Liu wrote:
> 
> In your topic:
> 
>   PCI/MSI: enhance PCI MSI core to support hierarchy irqdomain
> 
> There's no need to repeat "PCI MSI".  Please run "git log --oneline
> drivers/pci/msi.c" and make your similar (capitalize the first word).
Hi Bjornm
I'm already very carefully with your education about commit
log messages, but still missed this one:(. Will be even more careful
next time.

> 
>> Enhance PCI MSI core to support hierarchy irqdomain, so the common
>> code could be shared among architectures.
>>
>> Signed-off-by: Jiang Liu 
>> ---
>>  drivers/pci/Kconfig |4 ++
>>  drivers/pci/msi.c   |  126 
>> +++
>>  include/linux/msi.h |   11 +
>>  3 files changed, 141 insertions(+)
>>
>> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
>> index b9db0f2ce11f..022e89745f86 100644
>> --- a/drivers/pci/Kconfig
>> +++ b/drivers/pci/Kconfig
>> @@ -16,6 +16,10 @@ config PCI_MSI
>>  
>> If you don't know what to do here, say Y.
>>  
>> +config PCI_MSI_IRQ_DOMAIN
>> +bool
>> +depends on PCI_MSI && IRQ_DOMAIN_HIERARCHY
>> +
>>  config PCI_DEBUG
>>  bool "PCI Debugging"
>>  depends on PCI && DEBUG_KERNEL
>> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
>> index da181c59394b..7423ee16972f 100644
>> --- a/drivers/pci/msi.c
>> +++ b/drivers/pci/msi.c
>> @@ -19,6 +19,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #include "pci.h"
>>  
>> @@ -1098,3 +1099,128 @@ int pci_enable_msix_range(struct pci_dev *dev, 
>> struct msix_entry *entries,
>>  return nvec;
>>  }
>>  EXPORT_SYMBOL(pci_enable_msix_range);
>> +
>> +#ifdef  CONFIG_PCI_MSI_IRQ_DOMAIN
> 
> Space, not tab.
Will fix it in next version.

> 
>> +static inline irq_hw_number_t
>> +msi_get_hwirq(struct pci_dev *pdev, struct msi_desc *msidesc)
> 
> The convention in this file is "struct pci_dev *dev".  And "struct msi_desc
> *desc" (or maybe "*entry").  Try to converge things, not diverge them.
Thanks for reminder. Adding another check item to my list before
sending out patches:)

> 
>> +{
>> +return (irq_hw_number_t)msidesc->msi_attrib.entry_nr |
>> +PCI_DEVID(pdev->bus->number, pdev->devfn) << 11 |
>> +(pci_domain_nr(pdev->bus) & 0x) << 27;
> 
> Where does this bit layout come from?  Is this defined in the spec
> somewhere?  A reference would help.
We need a unique number to identify every possible MSI source,
and this ID number is only used within the irqdomain subsystem.
So we used above algorithm to generate the ID number, there's
no specification for it.

> 
>> +}
>> +
>> +static int msi_domain_alloc(struct irq_domain *domain, unsigned int virq,
>> +unsigned int nr_irqs, void *arg)
>> +{
>> +int i, ret;
>> +irq_hw_number_t hwirq = arch_msi_irq_domain_get_hwirq(arg);
>> +
>> +if (irq_find_mapping(domain, hwirq) > 0)
>> +return -EEXIST;
>> +
>> +ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, arg);
>> +if (ret >= 0)
> 
>   if (ret < 0)
>   return ret;
> 
> and un-indent the mainline code below.  Then it's obvious that this is the
> normal case, not the error case.
Sure, I want to only use one return statement, but didn't realized that
syntax seems like error handling:)

> 
>> +for (i = 0; i < nr_irqs; i++) {
>> +irq_domain_set_hwirq_and_chip(domain, virq + i,
>> +hwirq + i, _chip, (void *)(long)i);
>> +__irq_set_handler(virq + i, handle_edge_irq, 0, "edge");
>> +}
>> +
>> +return ret;
>> +}
>> +
>> +static void msi_domain_free(struct irq_domain *domain, unsigned int virq,
>> +unsigned int nr_irqs)
>> +{
>> +int i;
>> +
>> +for (i = 0; i < nr_irqs; i++) {
>> +struct msi_desc *msidesc = irq_get_msi_desc(virq);
>> +
>> +if (msidesc)
>> +msidesc->irq = 0;
>> +}
>> +irq_domain_free_irqs_top(domain, virq, nr_irqs);
>> +}
>> +
>> +static int msi_domain_activate(struct irq_domain *domain,
>> +   struct irq_data *irq_data)
>> +{
>> +int ret = 0;
>> +struct msi_msg msg;
>> +
>> +/*
>> + * irq_data->chip_data is MSI/MSIx offset.
> 
> "MSI-X", as you wrote on the next line.
Sure.

> 
>> + * MSI-X message is written per-IRQ, the offset is always 0.
>> + * MSI message denotes a contiguous group of IRQs, written for 0th IRQ.
>> + */
>> +if (!irq_data->chip_data) {
> 
>   if (irq_data->chip_data)
>   return 0;
> 
> and un-indent the mainline code below, and drop the "ret = 0" init above.
> 
>> +ret = irq_chip_compose_msi_msg(irq_data, );
>> +if (ret == 0)
> 
>   if (ret)
>   return ret;
> 
>> +write_msi_msg(irq_data->irq, );
>> +

Re: [RFC v5] usb: phy: Hold wakeupsource when USB is enumerated in peripheral mode

2014-11-05 Thread Felipe Balbi

On Thu, Nov 06, 2014 at 10:04:01AM +0530, Kiran Raparthy wrote:
> Hi Felipe,
> 
> On 6 November 2014 01:10, Felipe Balbi  wrote:
> > On Tue, Nov 04, 2014 at 03:30:54PM +0530, Kiran Kumar Raparthy wrote:
> >> From: Todd Poynor 
> >>
> >> usb: phy: Hold wakeupsource when USB is enumerated in peripheral mode
> >>
> >> Some systems require a mechanism to prevent system to enter into suspend
> >> state when USB is connected and enumerated in peripheral mode.
> >>
> >> This patch provides an interface to hold a wakeupsource to prevent suspend.
> >> PHY drivers can use this interface when USB is connected and enumerated in
> >> peripheral mode.
> >>
> >> A timed wakeupsource is temporarily held on USB disconnect events, to allow
> >> the rest of the system to react to the USB disconnection (dropping host
> >> sessions, updating charger status, etc.) prior to re-allowing suspend.
> >>
> >> Cc: Kishon Vijay Abraham I 
> >> Cc: Felipe Balbi 
> >> Cc: Greg Kroah-Hartman 
> >> Cc: linux-kernel@vger.kernel.org
> >> Cc: linux-...@vger.kernel.org
> >> Cc: Android Kernel Team 
> >> Cc: John Stultz 
> >> Cc: Sumit Semwal 
> >> Cc: Arve Hjønnevåg 
> >> Cc: Benoit Goby 
> >> Signed-off-by: Todd Poynor 
> >> [kiran: Added context to commit message, squished build fixes
> >> from Benoit Goby and Arve Hjønnevåg, changed wakelocks usage
> >> to wakeupsource, merged Todd's refactoring logic and simplified
> >> the structures and code and addressed community feedback]
> >> Signed-off-by: Kiran Raparthy 
> >
> > you still didn't get this right. I asked that you introduce
> > usb_phy_set_event() as a separate patch, then make PHY drivers use it
> > and only on a third patch should you hold a wakeupsource.
> Thanks for your time.
> Sure,I'll resend the patches as per your suggestion,could you please
> let me know whether you are okay with this new approach?.
> This will help me to consolidate all your inputs in new patch set.

I'll review again in the morning, sure.

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [Patch Part2 v4 21/31] PCI/MSI: enhance PCI MSI core to support hierarchy irqdomain

2014-11-05 Thread Yijing Wang

On 2014/11/6 12:10, Bjorn Helgaas wrote:
> On Wed, Nov 5, 2014 at 6:58 PM, Yijing Wang  wrote:
> 
 +{
 +return (irq_hw_number_t)msidesc->msi_attrib.entry_nr |
 +PCI_DEVID(pdev->bus->number, pdev->devfn) << 11 |
 +(pci_domain_nr(pdev->bus) & 0x) << 27;
>>>
>>> Where does this bit layout come from?  Is this defined in the spec
>>> somewhere?  A reference would help.
>>
>> Currently, more and more Non-PCI device use MSI(or similar MSI mechanism), 
>> like DMAR fault irq
>> and HPET FSB irq. And we have to add additional code to support the MSI 
>> capability.
>> So I hope we can decouple MSI code and PCI code, then we can unify all 
>> MSI(or Message Based interrupt)
>> in one framework.
> 
> Was that supposed to answer my question?  If so, I didn't understand
> how it explains where the bit layout came from.

No, that's just my concern. Because this function uses the pci device id,
but more and more Non-PCI devices use MSI.

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


-- 
Thanks!
Yijing

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

linux-next: manual merge of the y2038 tree with the v4l-dvb tree

Hi Arnd,

Today's linux-next merge of the y2038 tree got a conflict in
drivers/staging/media/lirc/lirc_sasem.c between commit f3a75505ab5f
("[media] Staging: media: lirc: cleaned up packet dump in 2 files")
from the v4l-dvb tree and commit db77d73bffbc ("staging: media: lirc:
Replace timeval with ktime_t in lirc_sasem.c") from the y2038 tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/staging/media/lirc/lirc_sasem.c
index 196f2a7f5bb3,dfd5668656e2..
--- a/drivers/staging/media/lirc/lirc_sasem.c
+++ b/drivers/staging/media/lirc/lirc_sasem.c
@@@ -571,8 -572,9 +572,8 @@@ static void incoming_packet(struct sase
  {
int len = urb->actual_length;
unsigned char *buf = urb->transfer_buffer;
-   long ms;
-   struct timeval tv;
+   u64 ns;
+   ktime_t kt;
 -  int i;
  
if (len != 8) {
dev_warn(>dev->dev,


pgpbthRsFa9xY.pgp
Description: OpenPGP digital signature

Re: [RFC 0/5] perf tools: Add perf data CTF conversion

2014-11-05 Thread Alexandre Montplaisir


Hi Mathieu,


On 11/05/2014 06:21 PM, Mathieu Desnoyers wrote:

[...]

The cpu_id field change will be addressed soon on our side.
Now, the remaining things:
The "domain = kernel" thingy (or another identifier if desired) is
something we could add.

Unless the event data is exactly the same, it would be easier to use
a different name. Like "kernel-perf" for instance?

Some kind of a namespace / identifier is probably not wrong. The lttng
tracer added a tracer version probably in case the format changes
between version for some reason. Perf comes with the kernel so for this
the kernel version should sufficient.

Yes, using the kernel version for Perf makes sense. I reach a similar
conclusion for LTTng: we should add tracepoint semantic versioning
somewhere in the CTF metadata, because the semantic of an event can
change based on the LTTng version, and based on which kernel version
LTTng is tracing.

A very good example is the semantic of the sched_wakeup event. It has
changed due to scheduler code modification, and is now called from an
IPI context, which changes its semantic (not called from the same
PID). Unfortunately, there is little we can do besides checking the
kernel version to detect the semantic change from the trace viewer
side, because neither the event nor the field names have changed.

The trace viewer could therefore care about the following information
to identify the semantic of a trace:

- Tracer name (e.g. lttng or perf),
- Domain (e.g. kernel or userspace),
- Tracepoint versioning (e.g. kernel version for Perf).


Sounds good. So perf-CTF traces could still use the "kernel" domain, but 
the CTF environment metadata would also mention the tracer, which could 
be so far either lttng or perf. For now we only look at the domain to 
infer the trace type, but we could also look at the tracer, and tracer 
version, to determine which event and field naming to use for the analysis.


I can also see how in general, versioning the "instrumentation" of an 
instrumented program could be useful. For example, LTTng changed the 
name of their syscall events in 2.6. The event still represents the same 
thing from an analysis's point of view, only the name changed.



Because CTF supports both kernel and userspace tracing, we also want
to solve this semantic detection problem both for the kernel and
userspace. Therefore, we should consider how the userspace
tracepoints could save version information in the user-space metadata
too.

Since we have traces shared across applications (per user-ID buffers)
in lttng-ust, the semantic info, and therefore the versioning, should
be done on a per-provider (or per-event) basis, rather than trace-wide,
because a single trace could contain events from various applications,
each with their own set of providers, therefore each with their
versioning info.


Hmm, where would this per-tracepoint version come from? From the version 
of the application? From a new "instrumentation version" defined 
somewhere? Or would the maintainers of the application have to manually 
version every single tracepoint in their program?


Per-tracepoint versioning, at first glance, seems a bit heavy. I'd have 
to understand more about it to make an informed opinion though ;) But 
this seems to be a problem for userspace traces only, right? Because 
with kernel traces

1) the tracers put the kernel version in the environment metadata and
2) you can't have more than one kernel provider in the same CTF trace 
(can you?)


But from a trace viewer's analysis point of view, I think it would make 
sense. If events in the trace supply a version (in addition to its 
name/type), then the analysis may decide to handle different versions of 
an event in different ways.





So if we apply this description scheme to the kernel tracing case,
this would mean that each event in the CTF metadata would have
version information. For Perf, this could very well be the kernel
version that we simply repeat for each event metadata entry. For
LTTng-modules, we would have our own versioning that is independent
of the kernel version, since the semantic of the events we expose
can change for a given kernel version as lttng-modules evolves.

In summary, for perf it would be really easy: just repeat the
kernel version in a new attribute attached to each event in the
metadata. For LTTng we would have the flexibility to have our own
version numbers in there. This would also cover the case of
userspace tracing, allowing each application to advertise their
tracepoint provider semantic changes through versioning.


>From the user's point of view, both would still be Linux Kernel

Traces, but we could use the domain internally to determine which
event/field layout to use.

Mathieu, any thoughts on how CTF domains should be namespaced?

(see above)


Now that I identified the differences between the CTF from lttng and
perf, any suggestions / ideas how this could be solved?

I suppose it would be better/cleaner if the event and

[PATCH] x86: Drop redundant memory-block sizing code

2014-11-05 Thread Daniel J Blueman

Drop the unused code from selecting a fixed memory block size of 2GB
on large-memory x86-64 systems.

Signed-off-by: Daniel J Blueman 
---
 arch/x86/mm/init_64.c | 18 +-
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index ebca30f..09c0567 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -1243,28 +1243,12 @@ int in_gate_area_no_mm(unsigned long addr)
 
 static unsigned long probe_memory_block_size(void)
 {
-   /* start from 2g */
-   unsigned long bz = 1UL<<31;
-
if (totalram_pages >= (64ULL << (30 - PAGE_SHIFT))) {
pr_info("Using 2GB memory block size for large-memory 
system\n");
return 2UL * 1024 * 1024 * 1024;
}
 
-   /* less than 64g installed */
-   if ((max_pfn << PAGE_SHIFT) < (16UL << 32))
-   return MIN_MEMORY_BLOCK_SIZE;
-
-   /* get the tail size */
-   while (bz > MIN_MEMORY_BLOCK_SIZE) {
-   if (!((max_pfn << PAGE_SHIFT) & (bz - 1)))
-   break;
-   bz >>= 1;
-   }
-
-   printk(KERN_DEBUG "memory block size : %ldMB\n", bz >> 20);
-
-   return bz;
+   return MIN_MEMORY_BLOCK_SIZE;
 }
 
 static unsigned long memory_block_size_probed;
-- 
1.9.1

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

Re: [PATCHv2 5/5] mmc: sdhci-bcm2835: add sdhci quirk SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12

On 11/05/2014 12:02 AM, Scott Branden wrote:
> On 14-11-04 09:00 PM, Stephen Warren wrote:
>> On 10/30/2014 12:36 AM, Scott Branden wrote:
>>> SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 is missing and needed for this
>>> controller.
>>
>> This seems fine, although any explanation of why this quirk is needed
>> would be useful.
>>
> I don't know who to talk to at Arasan about this.  Will try hunting
> around a little for more info as to why this is needed to have eMMC and
> SD work properly through our internal testing on other non-2835 chipset
> that shares the same SDHCI controller as 2835.

I thought I heard that this wasn't a bug in the controller itself, but
rather an integration issue between the IP core and the register bus
it's attached to. Consequently, it may be SoC-specific or at least have
SoC-specific variations?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the y2038 tree with the staging tree

Hi Arnd,

On Thu, 6 Nov 2014 15:48:15 +1100 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the y2038 tree got a conflict in
> drivers/staging/ft1000/ft1000-usb/ft1000_debug.c between commit
> ecdd21c7b982 ("staging: ft1000: Whitespace neatening") from the staging
> tree and commit 4115d2b27a50 ("staging: ft1000: Replace timeval and
> time_t with time64_t") from the y2038 tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Sorry, see below for proper diff.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
index c8d278229940,287c8b3c18fc..
--- a/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
+++ b/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
@@@ -391,339 -394,344 +391,339 @@@ static unsigned int ft1000_poll_dev(str
  }
  
  /*
 -*---
 -* Function:ft1000_ioctl
 -*
 -* Parameters:
 -*
 -* Description:
 -*
 -* Notes:
 -*
 -*---
 -*/
 + *---
 + * Function:ft1000_ioctl
 + *
 + * Parameters:
 + *
 + * Description:
 + *
 + * Notes:
 + *
 + *---
 + */
  static long ft1000_ioctl(struct file *file, unsigned int command,
 -   unsigned long argument)
 +   unsigned long argument)
  {
 -void __user *argp = (void __user *)argument;
 +  void __user *argp = (void __user *)argument;
struct ft1000_info *info;
 -struct ft1000_usb *ft1000dev;
 -int result=0;
 -int cmd;
 -int i;
 -u16 tempword;
 -unsigned long flags;
 +  struct ft1000_usb *ft1000dev;
 +  int result = 0;
 +  int cmd;
 +  int i;
 +  u16 tempword;
 +  unsigned long flags;
-   struct timeval tv;
+   time64_t time;
struct IOCTL_GET_VER get_ver_data;
struct IOCTL_GET_DSP_STAT get_stat_data;
 -u8 ConnectionMsg[] = 
{0x00,0x44,0x10,0x20,0x80,0x00,0x00,0x00,0x00,0x00,0x03,0x00,0x00,0x00,0x93,0x64,
 -  
0x00,0x00,0x02,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x05,0x00,0x00,0x00,0x0a,
 -  
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x02,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
 -  
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x12,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
 -  
0x00,0x00,0x02,0x37,0x00,0x00,0x00,0x08,0x00,0x00,0x00,0x01,0x00,0x01,0x7f,0x00,
 -  0x00,0x01,0x00,0x00};
 +  u8 ConnectionMsg[] = {0x00, 0x44, 0x10, 0x20, 0x80, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x93, 0x64,
 +0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x05, 0x00, 0x00, 0x00, 0x0a,
 +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
 +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x12, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
 +0x00, 0x00, 0x02, 0x37, 0x00, 0x00, 0x00, 0x08, 
0x00, 0x00, 0x00, 0x01, 0x00, 0x01, 0x7f, 0x00,
 +0x00, 0x01, 0x00, 0x00};
 +
 +  unsigned short ledStat = 0;
 +  unsigned short conStat = 0;
 +
 +  if (ft1000_flarion_cnt == 0) {
 +  pr_debug("called with ft1000_flarion_cnt of zero\n");
 +  return -EBADF;
 +  }
  
 -unsigned short ledStat=0;
 -unsigned short conStat=0;
 +  /* pr_debug("command = 0x%x argument = 0x%8x\n", command, 
(u32)argument); */
  
 -/* DEBUG("ft1000_ioctl called\n"); */
 +  info = file->private_data;
 +  ft1000dev = info->priv;
 +  cmd = _IOC_NR(command);
 +  /* pr_debug("cmd = 0x%x\n", cmd); */
 +
 +  /* process the command */
 +  switch (cmd) {
 +  case IOCTL_REGISTER_CMD:
 +  pr_debug("IOCTL_FT1000_REGISTER called\n");
 +  result = get_user(tempword, (__u16 __user *)argp);
 +  if (result) {
 +  pr_debug("result = %d failed to get_user\n", result);
 +  break;
 +  }
 +  if (tempword == DSPBCMSGID) {
 +  /* Search for matching file object */
 +  for (i = 0; i < MAX_NUM_APP; i++) {
 +  if (ft1000dev->app_info[i].fileobject == 
>f_owner) {
 +  ft1000dev->app_info[i].DspBCMsgFlag = 1;
 +  pr_debug("Registered for broadcast 
messages\n");
 +  break;
 +  }
 +  }
 +  }
 +  break;
  
 -if (ft1000_flarion_cnt == 0) {
 -

[PATCH net-next 3/3] r8152: remove the definitions of the PID

The PIDs are only used in the id table, so the definitions are
unnacessary. Remove them wouldn't have confusion.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index cf1b8a7..66b139a 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -461,11 +461,7 @@ enum rtl8152_flags {
 
 /* Define these values to match your device */
 #define VENDOR_ID_REALTEK  0x0bda
-#define PRODUCT_ID_RTL8152 0x8152
-#define PRODUCT_ID_RTL8153 0x8153
-
 #define VENDOR_ID_SAMSUNG  0x04e8
-#define PRODUCT_ID_SAMSUNG 0xa101
 
 #define MCU_TYPE_PLA   0x0100
 #define MCU_TYPE_USB   0x
@@ -3898,9 +3894,9 @@ static void rtl8152_disconnect(struct usb_interface *intf)
 
 /* table of devices that work with this driver */
 static struct usb_device_id rtl8152_table[] = {
-   {USB_DEVICE(VENDOR_ID_REALTEK, PRODUCT_ID_RTL8152)},
-   {USB_DEVICE(VENDOR_ID_REALTEK, PRODUCT_ID_RTL8153)},
-   {USB_DEVICE(VENDOR_ID_SAMSUNG, PRODUCT_ID_SAMSUNG)},
+   {USB_DEVICE(VENDOR_ID_REALTEK, 0x8152)},
+   {USB_DEVICE(VENDOR_ID_REALTEK, 0x8153)},
+   {USB_DEVICE(VENDOR_ID_SAMSUNG, 0xa101)},
{}
 };
 
-- 
1.9.3

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

Re: [PATCHv2 3/5] mmc: shdci-bcm2835: add efficient back-to-back write workaround

On 11/04/2014 11:55 PM, Scott Branden wrote:
> On 14-11-04 08:57 PM, Stephen Warren wrote:
>> On 10/30/2014 12:36 AM, Scott Branden wrote:
>>> The bcm2835 has clock domain issues when back to back writes to certain
>>> registers are written.  The existing driver works around this issue with
>>> udelay.  A more efficient method is to store the 8 and 16 bit writes
>>> to the registers affected and then write them as 32 bits at the
>>> appropriate
>>> time.
>>
>>> diff --git a/drivers/mmc/host/sdhci-bcm2835.c
>>> b/drivers/mmc/host/sdhci-bcm2835.c
>>
>>>   static void bcm2835_sdhci_writew(struct sdhci_host *host, u16 val,
>>> int reg)
>>>   {
>>>   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>> -struct bcm2835_sdhci *bcm2835_host = pltfm_host->priv;
>>> -u32 oldval = (reg == SDHCI_COMMAND) ? bcm2835_host->shadow :
>>> -bcm2835_sdhci_readl(host, reg & ~3);
>>> +struct bcm2835_sdhci_host *bcm2835_host = pltfm_host->priv;
>>
>> Is that type change for bcm2835_host really correct?
>
> Yes - at the top of the patch the structure has been expanded and named
> appropriately.
> 
> -struct bcm2835_sdhci {
> -u32 shadow;
> +struct bcm2835_sdhci_host {
> +u32 shadow_cmd;
> +u32 shadow_blk;
>  };

Ah yes, sorry for missing that.

>>> +} else {
>>> +/* Read reg, all other registers are not shadowed */
>>> +oldval = readl(host->ioaddr + (reg & ~3));
>>
>> Is there any reason to use readl() directly here rather than calling
>> bcm2835_readl()? ...
>
> Yes, bcm2835_readl does not need to be called in read-modify-write and
> shadow register situations and just adds overhead.  All that needs to be
> called is readl.  bcm2835_readl has some existing ugly code in it to
> modify the capabilities register on a read function.  This info never
> needs to be for write as you can't overwrite the capabilities register.

To be honest, it seems better to do all the read/write through
consistent functions. One advantage of bcm2835_readl() is that it
consistently adds on the base address internally so you don't have to
write it out every time manually. Still, the code ought to work fine
after this change, so I guess it's OK.

> I hope to get rid of the capabilities hack in a future patch as this
> should never have been acceptable in upstreamed code to begin with.  The
> capabilities override should have been passed in through a device tree
> entry.

It's a pretty common technique with precedent. I certainly don't agree
that it should be configured by DT. Arguably, DT makes sense to describe
board-to-board variations, but there's almost zero point putting data
into DT that is SoC description rather than board description; just put
it into the driver to avoid continually parsing the same data over and
over from DT just to get back to the same data that could have been
encoded into the driver. If the data varies between similar controllers,
an of_match table can easily be used to parameterize it based on
compatible value.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH net-next 2/3] r8152: modify rtl_ops_init

Replace using VID/PID with using tp->version to initialize the ops.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 79 ++---
 1 file changed, 28 insertions(+), 51 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 4b6db8a..cf1b8a7 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3742,66 +3742,43 @@ static void rtl8153_unload(struct r8152 *tp)
r8153_power_cut_en(tp, false);
 }
 
-static int rtl_ops_init(struct r8152 *tp, const struct usb_device_id *id)
+static int rtl_ops_init(struct r8152 *tp)
 {
struct rtl_ops *ops = >rtl_ops;
-   int ret = -ENODEV;
-
-   switch (id->idVendor) {
-   case VENDOR_ID_REALTEK:
-   switch (id->idProduct) {
-   case PRODUCT_ID_RTL8152:
-   ops->init   = r8152b_init;
-   ops->enable = rtl8152_enable;
-   ops->disable= rtl8152_disable;
-   ops->up = rtl8152_up;
-   ops->down   = rtl8152_down;
-   ops->unload = rtl8152_unload;
-   ops->eee_get= r8152_get_eee;
-   ops->eee_set= r8152_set_eee;
-   ret = 0;
-   break;
-   case PRODUCT_ID_RTL8153:
-   ops->init   = r8153_init;
-   ops->enable = rtl8153_enable;
-   ops->disable= rtl8153_disable;
-   ops->up = rtl8153_up;
-   ops->down   = rtl8153_down;
-   ops->unload = rtl8153_unload;
-   ops->eee_get= r8153_get_eee;
-   ops->eee_set= r8153_set_eee;
-   ret = 0;
-   break;
-   default:
-   break;
-   }
+   int ret = 0;
+
+   switch (tp->version) {
+   case RTL_VER_01:
+   case RTL_VER_02:
+   ops->init   = r8152b_init;
+   ops->enable = rtl8152_enable;
+   ops->disable= rtl8152_disable;
+   ops->up = rtl8152_up;
+   ops->down   = rtl8152_down;
+   ops->unload = rtl8152_unload;
+   ops->eee_get= r8152_get_eee;
+   ops->eee_set= r8152_set_eee;
break;
 
-   case VENDOR_ID_SAMSUNG:
-   switch (id->idProduct) {
-   case PRODUCT_ID_SAMSUNG:
-   ops->init   = r8153_init;
-   ops->enable = rtl8153_enable;
-   ops->disable= rtl8153_disable;
-   ops->up = rtl8153_up;
-   ops->down   = rtl8153_down;
-   ops->unload = rtl8153_unload;
-   ops->eee_get= r8153_get_eee;
-   ops->eee_set= r8153_set_eee;
-   ret = 0;
-   break;
-   default:
-   break;
-   }
+   case RTL_VER_03:
+   case RTL_VER_04:
+   case RTL_VER_05:
+   ops->init   = r8153_init;
+   ops->enable = rtl8153_enable;
+   ops->disable= rtl8153_disable;
+   ops->up = rtl8153_up;
+   ops->down   = rtl8153_down;
+   ops->unload = rtl8153_unload;
+   ops->eee_get= r8153_get_eee;
+   ops->eee_set= r8153_set_eee;
break;
 
default:
+   ret = -ENODEV;
+   netif_err(tp, probe, tp->netdev, "Unknown Device\n");
break;
}
 
-   if (ret)
-   netif_err(tp, probe, tp->netdev, "Unknown Device\n");
-
return ret;
 }
 
@@ -3834,7 +3811,7 @@ static int rtl8152_probe(struct usb_interface *intf,
tp->intf = intf;
 
r8152b_get_version(tp);
-   ret = rtl_ops_init(tp, id);
+   ret = rtl_ops_init(tp);
if (ret)
goto out;
 
-- 
1.9.3

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

[PATCH net-next 1/3] r8152: move r8152b_get_version

Move r8152b_get_version() to the location before rtl_ops_init().
Then, the rtl_ops_init() could use tp->version.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index fd41675..4b6db8a 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3833,6 +3833,7 @@ static int rtl8152_probe(struct usb_interface *intf,
tp->netdev = netdev;
tp->intf = intf;
 
+   r8152b_get_version(tp);
ret = rtl_ops_init(tp, id);
if (ret)
goto out;
@@ -3866,11 +3867,9 @@ static int rtl8152_probe(struct usb_interface *intf,
tp->mii.phy_id_mask = 0x3f;
tp->mii.reg_num_mask = 0x1f;
tp->mii.phy_id = R8152_PHY_ID;
-   tp->mii.supports_gmii = 0;
 
intf->needs_remote_wakeup = 1;
 
-   r8152b_get_version(tp);
tp->rtl_ops.init(tp);
set_ethernet_addr(tp);
 
-- 
1.9.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/

linux-next: manual merge of the y2038 tree with the staging tree

Hi Arnd,

Today's linux-next merge of the y2038 tree got a conflict in
drivers/staging/ft1000/ft1000-usb/ft1000_debug.c between commit
ecdd21c7b982 ("staging: ft1000: Whitespace neatening") from the staging
tree and commit 4115d2b27a50 ("staging: ft1000: Replace timeval and
time_t with time64_t") from the y2038 tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
index c8d278229940,287c8b3c18fc..
--- a/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
+++ b/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
@@@ -391,339 -394,344 +391,429 @@@ static unsigned int ft1000_poll_dev(str
  }
  
  /*
 -*---
 -* Function:ft1000_ioctl
 -*
 -* Parameters:
 -*
 -* Description:
 -*
 -* Notes:
 -*
 -*---
 -*/
 + *---
 + * Function:ft1000_ioctl
 + *
 + * Parameters:
 + *
 + * Description:
 + *
 + * Notes:
 + *
 + *---
 + */
  static long ft1000_ioctl(struct file *file, unsigned int command,
 -   unsigned long argument)
 +   unsigned long argument)
  {
 -void __user *argp = (void __user *)argument;
 +  void __user *argp = (void __user *)argument;
struct ft1000_info *info;
 -struct ft1000_usb *ft1000dev;
 -int result=0;
 -int cmd;
 -int i;
 -u16 tempword;
 -unsigned long flags;
 +  struct ft1000_usb *ft1000dev;
 +  int result = 0;
 +  int cmd;
 +  int i;
 +  u16 tempword;
 +  unsigned long flags;
-   struct timeval tv;
+   time64_t time;
struct IOCTL_GET_VER get_ver_data;
struct IOCTL_GET_DSP_STAT get_stat_data;
 -u8 ConnectionMsg[] = 
{0x00,0x44,0x10,0x20,0x80,0x00,0x00,0x00,0x00,0x00,0x03,0x00,0x00,0x00,0x93,0x64,
 -  
0x00,0x00,0x02,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x05,0x00,0x00,0x00,0x0a,
 -  
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x02,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
 -  
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x12,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
 -  
0x00,0x00,0x02,0x37,0x00,0x00,0x00,0x08,0x00,0x00,0x00,0x01,0x00,0x01,0x7f,0x00,
 -  0x00,0x01,0x00,0x00};
 +  u8 ConnectionMsg[] = {0x00, 0x44, 0x10, 0x20, 0x80, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x93, 0x64,
 +0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x05, 0x00, 0x00, 0x00, 0x0a,
 +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
 +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x12, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
 +0x00, 0x00, 0x02, 0x37, 0x00, 0x00, 0x00, 0x08, 
0x00, 0x00, 0x00, 0x01, 0x00, 0x01, 0x7f, 0x00,
 +0x00, 0x01, 0x00, 0x00};
 +
 +  unsigned short ledStat = 0;
 +  unsigned short conStat = 0;
 +
 +  if (ft1000_flarion_cnt == 0) {
 +  pr_debug("called with ft1000_flarion_cnt of zero\n");
 +  return -EBADF;
 +  }
  
 -unsigned short ledStat=0;
 -unsigned short conStat=0;
 +  /* pr_debug("command = 0x%x argument = 0x%8x\n", command, 
(u32)argument); */
  
 -/* DEBUG("ft1000_ioctl called\n"); */
 +  info = file->private_data;
 +  ft1000dev = info->priv;
 +  cmd = _IOC_NR(command);
 +  /* pr_debug("cmd = 0x%x\n", cmd); */
 +
 +  /* process the command */
 +  switch (cmd) {
 +  case IOCTL_REGISTER_CMD:
 +  pr_debug("IOCTL_FT1000_REGISTER called\n");
 +  result = get_user(tempword, (__u16 __user *)argp);
 +  if (result) {
 +  pr_debug("result = %d failed to get_user\n", result);
 +  break;
 +  }
 +  if (tempword == DSPBCMSGID) {
 +  /* Search for matching file object */
 +  for (i = 0; i < MAX_NUM_APP; i++) {
 +  if (ft1000dev->app_info[i].fileobject == 
>f_owner) {
 +  ft1000dev->app_info[i].DspBCMsgFlag = 1;
 +  pr_debug("Registered for broadcast 
messages\n");
 +  break;
 +  }
 +  }
 +  }
 +  break;
  
 -if (ft1000_flarion_cnt == 0) {
 -DEBUG("FT1000:ft1000_ioctl called when ft1000_flarion_cnt is zero\n");
 -return (-EBADF);
 -}
 +

[PATCH net-next 0/3] r8152: rtl_ops_init modify

Initialize the ops through tp->version. This could skip checking
each VID/PID.

Hayes Wang (3):
  r8152: move r8152b_get_version
  r8152: modify rtl_ops_init
  r8152: remove the definitions of the PID

 drivers/net/usb/r8152.c | 92 +
 1 file changed, 32 insertions(+), 60 deletions(-)

-- 
1.9.3

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

Re: [RESUBMIT PATCH v6 7/8] regulator: sky81452: Add compatible string for device binding

2014-11-05 Thread Gyungoh Yoo

On Mon, Nov 03, 2014 at 10:45:39PM +0100, Paul Bolle wrote:
> On Fri, 2014-10-31 at 16:44 +, Mark Brown wrote:
> > On Fri, Oct 31, 2014 at 04:08:41PM +0900, gyun...@gmail.com wrote:
> > > From: Gyungoh Yoo 
> > > 
> > > Signed-off-by: Gyungoh Yoo 
> > 
> > This doesn't apply against current code and depends on the MFD symbol
> > rename - can you please check what's going on here?
> > 
> > It would make sense to split the Kconfig symbol rename into a separate
> > patch to ease merging,
> 
> The relicensing (from GPL to GPL v2, thus dropping the "or later"
> provision) is odd too. The header still uses GPL v2 or later, doesn't
> it? Anyhow, that could be a separate patch too.

I will modify the licensing text and resubmit it.
Thank you for your comment.

> 
> > it doesn't seem obviously related to the driver
> > change and should probably be in the same patch as the MFD symbol rename
> > for bisetion.
> 
> I don't think there will be bisection problems (in mainline). Currently
> this driver depends on SKY81452. But that symbol doesn't exist. Only
> after both 1/8 and this patch will this driver become buildable, for the
> first time. So it's not that this driver was buildable, became
> unbuildable in 1/8 and buildable again in this patch.
> 
> (I don't think it's much of a problem that the regulator driver got
> merged, in v3.18-rc1, before the mfd driver on which it depends.
> Avoiding that temporarily problem appears to be more trouble than it's
> worth.)
> 
> 
> Paul Bolle
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the y2038 tree with the staging tree

Hi Arnd,

Today's linux-next merge of the y2038 tree got a conflict in
drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c between commit
ecdd21c7b982 ("staging: ft1000: Whitespace neatening") from the staging
tree and commit 4115d2b27a50 ("staging: ft1000: Replace timeval and
time_t with time64_t") from the y2038 tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
index 11dbe369e18b,9a9655cdc64d..
--- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
+++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
@@@ -1019,29 -1055,19 +1019,29 @@@ static void ft1000_proc_drvmsg(struct n
info->CardReady = 1;
break;
case MEDIA_STATE:
 -  pmediamsg = (struct media_msg *) & cmdbuffer[0];
 +  pmediamsg = (struct media_msg *)[0];
if (info->ProgConStat != 0xFF) {
 -  if (pmediamsg->state) {
 -  DEBUG(1, "Media is up\n");
 -  if (info->mediastate == 0) {
 -  netif_carrier_on(dev);
 -  netif_wake_queue(dev);
 -  info->mediastate = 1;
 -  time = get_seconds();
 -  info->ConTm = time;
 +  if (pmediamsg->state) {
 +  pr_debug("Media is up\n");
 +  if (info->mediastate == 0) {
 +  netif_carrier_on(dev);
 +  netif_wake_queue(dev);
 +  info->mediastate = 1;
-   do_gettimeofday();
-   info->ConTm = tv.tv_sec;
++  time = get_seconds();
++  info->ConTm = time;
 +  }
 +  } else {
 +  pr_debug("Media is down\n");
 +  if (info->mediastate == 1) {
 +  info->mediastate = 0;
 +  netif_carrier_off(dev);
 +  netif_stop_queue(dev);
 +  info->ConTm = 0;
 +  }
}
 -  } else {
 -  DEBUG(1, "Media is down\n");
 +  }
 +  else {
 +  pr_debug("Media is down\n");
if (info->mediastate == 1) {
info->mediastate = 0;
netif_carrier_off(dev);


pgp5k5yLLPmv6.pgp
Description: OpenPGP digital signature

Re: [PATCH 3/3] ftracetest: Add basic event tracing test cases

2014-11-05 Thread Masami Hiramatsu

(2014/11/06 11:04), Namhyung Kim wrote:
> This patch adds basic event tracing tests like enable/disable with
> top-level, subsystem-level and individual event files.
> 
>   # ./ftracetest
>   === Ftrace unit tests ===
>   [1] Basic trace file check  [PASS]
>   [2] Basic trace clock test  [PASS]
>   [3] Basic event tracing check   [PASS]
>   [4] Basic test for tracers  [PASS]
>   [5] event tracing - enable/disable with top level files [PASS]
>   [6] event tracing - enable/disable with subsystem level files   [PASS]
>   [7] event tracing - enable/disable with event level files   [PASS]
>   [8] ftrace - function graph filters [PASS]
>   [9] ftrace - function profiler with function tracing[PASS]
>   [10] ftrace - function graph filters with stack tracer  [PASS]
>   [11] Kretprobe dynamic event with arguments [PASS]
>   [12] Kprobe dynamic event - busy event check[PASS]
>   [13] Kprobe dynamic event with arguments[PASS]
>   [14] Kprobe dynamic event - adding and removing [PASS]
> 
>   # of passed:  14
>   # of failed:  0
>   # of unresolved:  0
>   # of untested:  0
>   # of unsupported:  0
>   # of xfailed:  0
>   # of undefined(test bug):  0

Nice :)

> 
> Signed-off-by: Namhyung Kim 

Acked-by: Masami Hiramatsu 

Thank you,

> ---
>  .../selftests/ftrace/test.d/00basic/basic4.tc  |  5 ++
>  .../selftests/ftrace/test.d/event/event-enable.tc  | 53 
> ++
>  .../ftrace/test.d/event/subsystem-enable.tc| 53 
> ++
>  .../ftrace/test.d/event/toplevel-enable.tc | 47 +++
>  4 files changed, 158 insertions(+)
>  create mode 100644 tools/testing/selftests/ftrace/test.d/00basic/basic4.tc
>  create mode 100644 
> tools/testing/selftests/ftrace/test.d/event/event-enable.tc
>  create mode 100644 
> tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
>  create mode 100644 
> tools/testing/selftests/ftrace/test.d/event/toplevel-enable.tc
> 
> diff --git a/tools/testing/selftests/ftrace/test.d/00basic/basic4.tc 
> b/tools/testing/selftests/ftrace/test.d/00basic/basic4.tc
> new file mode 100644
> index ..fd9c49a13612
> --- /dev/null
> +++ b/tools/testing/selftests/ftrace/test.d/00basic/basic4.tc
> @@ -0,0 +1,5 @@
> +#!/bin/sh
> +# description: Basic event tracing check
> +test -f available_events -a -f set_event -a -d events
> +# check scheduler events are available
> +grep -q sched available_events && exit 0 || exit -1
> \ No newline at end of file
> diff --git a/tools/testing/selftests/ftrace/test.d/event/event-enable.tc 
> b/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
> new file mode 100644
> index ..668616d9bb03
> --- /dev/null
> +++ b/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
> @@ -0,0 +1,53 @@
> +#!/bin/sh
> +# description: event tracing - enable/disable with event level files
> +
> +do_reset() {
> +echo > set_event
> +clear_trace
> +}
> +
> +fail() { #msg
> +do_reset
> +echo $1
> +exit -1
> +}
> +
> +if [ ! -f set_event -o ! -d events/sched ]; then
> +echo "event tracing is not supported"
> +exit_unsupported
> +fi
> +
> +reset_tracer
> +do_reset
> +
> +echo 'sched:sched_switch' > set_event
> +usleep 1
> +
> +count=`cat trace | grep sched_switch | wc -l`
> +if [ $count -eq 0 ]; then
> +fail "sched_switch events are not recorded"
> +fi
> +
> +do_reset
> +
> +echo 1 > events/sched/sched_switch/enable
> +usleep 1
> +
> +count=`cat trace | grep sched_switch | wc -l`
> +if [ $count -eq 0 ]; then
> +fail "sched_switch events are not recorded"
> +fi
> +
> +do_reset
> +
> +echo 0 > events/sched/sched_switch/enable
> +usleep 1
> +
> +count=`cat trace | grep sched_switch | wc -l`
> +if [ $count -ne 0 ]; then
> +fail "sched_switch events should not be recorded"
> +fi
> +
> +do_reset
> +
> +exit 0
> diff --git a/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc 
> b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
> new file mode 100644
> index ..655c415b6e7f
> --- /dev/null
> +++ b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
> @@ -0,0 +1,53 @@
> +#!/bin/sh
> +# description: event tracing - enable/disable with subsystem level files
> +
> +do_reset() {
> +echo > set_event
> +clear_trace
> +}
> +
> +fail() { #msg
> +do_reset
> +echo $1
> +exit -1
> +}
> +
> +if [ ! -f set_event -o ! -d events/sched ]; then
> +echo "event tracing is not supported"
> +exit_unsupported
> +fi
> +
> +reset_tracer
> +do_reset
> +
> +echo 'sched:*' > set_event
> +usleep 1
> +
> +count=`cat trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l`
> +if [ $count -lt 3 ]; then
> +fail "at least fork, exec and exit events should be recorded"
> +fi
> +
> +do_reset
> +
> +echo 1 > events/sched/enable
> +usleep 1
> +
> +count=`cat trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l`
> +if [ $count -lt 3 ]; then
> +fail "at least fork, exec

Re: [RESUBMIT PATCH v6 7/8] regulator: sky81452: Add compatible string for device binding

2014-11-05 Thread Gyungoh Yoo

On Tue, Nov 04, 2014 at 11:41:20AM +, Mark Brown wrote:
> On Tue, Nov 04, 2014 at 02:45:34PM +0900, Gyungoh Yoo wrote:
> > On Tue, Nov 04, 2014 at 12:53:29AM +, Mark Brown wrote:
> 
> > > I'm having a hard time understanding why it is difficult to split the
> > > two changes - they are in completely separate files.
> 
> > I am sorry for the hard time.
> 
> > That was because the symbol changes had a dependency with 1/8.
> > In this case, Should Kconfig symbol change back from MFD_SKY81452
> > to SKY81452 in this patch series? And then should I submit to change to 
> > MFD_SKY81452
> > with seperate patch?
> 
> No, what I'm saying is that if you want to rename the Kconfig symbol you
> should do that as part of a separate patch to changing the DT stuff.

I see.
I will split this patch. One is for DT stuff and the other is for Kconfig
symbol rename.
Thank you for your comment.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5] usb: phy: Hold wakeupsource when USB is enumerated in peripheral mode

2014-11-05 Thread Kiran Raparthy

Hi Felipe,

On 6 November 2014 01:10, Felipe Balbi  wrote:
> On Tue, Nov 04, 2014 at 03:30:54PM +0530, Kiran Kumar Raparthy wrote:
>> From: Todd Poynor 
>>
>> usb: phy: Hold wakeupsource when USB is enumerated in peripheral mode
>>
>> Some systems require a mechanism to prevent system to enter into suspend
>> state when USB is connected and enumerated in peripheral mode.
>>
>> This patch provides an interface to hold a wakeupsource to prevent suspend.
>> PHY drivers can use this interface when USB is connected and enumerated in
>> peripheral mode.
>>
>> A timed wakeupsource is temporarily held on USB disconnect events, to allow
>> the rest of the system to react to the USB disconnection (dropping host
>> sessions, updating charger status, etc.) prior to re-allowing suspend.
>>
>> Cc: Kishon Vijay Abraham I 
>> Cc: Felipe Balbi 
>> Cc: Greg Kroah-Hartman 
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-...@vger.kernel.org
>> Cc: Android Kernel Team 
>> Cc: John Stultz 
>> Cc: Sumit Semwal 
>> Cc: Arve Hjønnevåg 
>> Cc: Benoit Goby 
>> Signed-off-by: Todd Poynor 
>> [kiran: Added context to commit message, squished build fixes
>> from Benoit Goby and Arve Hjønnevåg, changed wakelocks usage
>> to wakeupsource, merged Todd's refactoring logic and simplified
>> the structures and code and addressed community feedback]
>> Signed-off-by: Kiran Raparthy 
>
> you still didn't get this right. I asked that you introduce
> usb_phy_set_event() as a separate patch, then make PHY drivers use it
> and only on a third patch should you hold a wakeupsource.
Thanks for your time.
Sure,I'll resend the patches as per your suggestion,could you please
let me know whether you are okay with this new approach?.
This will help me to consolidate all your inputs in new patch set.
Regards,
Kiran
>
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 Part2 v4 20/31] PCI/MSI: Kill redundant calling for irq_set_msi_desc() for MSIx interrupts

On 2014/11/6 9:32, Yijing Wang wrote:
> On 2014/11/6 6:45, Bjorn Helgaas wrote:
>> On Tue, Nov 04, 2014 at 08:01:54PM +0800, Jiang Liu wrote:
>>> It's arch_setup_msi_irq()/arch_setup_msi_irqs()'s responsibility to call
>>> irq_set_msi_desc() to associate IRQ descriptors and MSI descriptors,
>>> so kill the redundant call of irq_set_msi_desc() for MSIx interrupts
>>> in PCI MSI core.
>>
>> "MSI-X" in English text, "msix" in code.
>>
>> The default arch_setup_msi_irq() in drivers/pci/msi.c doesn't call
>> irq_set_msi_desc().  Does it happen somewhere inside chip->setup_irq()?
> 
> Yes.
> 
> I also found this.
> http://www.spinics.net/lists/linux-pci/msg34256.html
> 
>>
>> I don't know how to verify that there are calls in all the places needed.
>> That makes me wonder if the factoring is wrong -- maybe irq_set_msi_desc()
>> could be done in some common place.
> 
> In my idea, place the irq_set_msi_desc() in common MSI core is ok, but 
> currently almost
> all MSI arch code call irq_set_msi_desc() in arch code. So a lot of code need 
> to change.
> And arch code setup MSI and MSI-X in the same way, so if MSI work happy 
> without irq_set_msi_desc(entry->irq, entry)
> in common MSI code, MSI-X should be the same.
Hi Bjorn and Yijing,
I originally plan was to move irq_set_msi_desc() into common
PCI MSI code. But when implementing this, I found every
arch_setup_msi_irq()/arch_setup_msi_irqs() needs to set msidesc->irq,
thus need to lock the irq descriptor. So I realized we should
rely on arch_setup_msi_irq() to call irq_set_msi_desc():)
Regards!
Gerry

> 
>>
>>> Signed-off-by: Jiang Liu 
>>> ---
>>>  drivers/pci/msi.c |1 -
>>>  1 file changed, 1 deletion(-)
>>>
>>> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
>>> index afe974600c7d..da181c59394b 100644
>>> --- a/drivers/pci/msi.c
>>> +++ b/drivers/pci/msi.c
>>> @@ -685,7 +685,6 @@ static void msix_program_entries(struct pci_dev *dev,
>>> PCI_MSIX_ENTRY_VECTOR_CTRL;
>>>  
>>> entries[i].vector = entry->irq;
>>> -   irq_set_msi_desc(entry->irq, entry);
>>> entry->masked = readl(entry->mask_base + offset);
>>> msix_mask_irq(entry, 1);
>>> i++;
>>> -- 
>>> 1.7.10.4
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>> .
>>
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH next] xen: pcifront: Process failure for pcifront_(re)scan_root()

On Mon, Oct 06, 2014 at 11:04:45AM +0800, Chen Gang wrote:
> When pcifront_rescan_root() or pcifront_scan_root() fails, need return
> error code, neither set XenbusStateConnected state, just like the other
> areas have done.
> 
> For pcifront_rescan_root(), it will return error code ("num_roots = 0;",
> skip xenbus_switch_state return value).
> 
> For pcifront_scan_root(), it will return 0 ("num_roots = 0;", set 0 by
> the return value of xenbus_switch_state, which always return 0, at
> present).
> 
> Signed-off-by: Chen Gang 

Applied to pci/virtualization for v3.19, with Konrad's ack and my changelog
rework.  Thanks!

> ---
>  drivers/pci/xen-pcifront.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
> index 53df39a..d78d884 100644
> --- a/drivers/pci/xen-pcifront.c
> +++ b/drivers/pci/xen-pcifront.c
> @@ -866,6 +866,11 @@ static int pcifront_try_connect(struct pcifront_device 
> *pdev)
>   xenbus_dev_error(pdev->xdev, err,
>"No PCI Roots found, trying :00");
>   err = pcifront_scan_root(pdev, 0, 0);
> + if (err) {
> + xenbus_dev_fatal(pdev->xdev, err,
> +  "Error scanning PCI root :00");
> + goto out;
> + }
>   num_roots = 0;
>   } else if (err != 1) {
>   if (err == 0)
> @@ -947,6 +952,11 @@ static int pcifront_attach_devices(struct 
> pcifront_device *pdev)
>   xenbus_dev_error(pdev->xdev, err,
>"No PCI Roots found, trying :00");
>   err = pcifront_rescan_root(pdev, 0, 0);
> + if (err) {
> + xenbus_dev_fatal(pdev->xdev, err,
> +  "Error scanning PCI root :00");
> + goto out;
> + }
>   num_roots = 0;
>   } else if (err != 1) {
>   if (err == 0)
> -- 
> 1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/7] Pinctrl support for Zynq

2014-11-05 Thread Sören Brinkmann

On Thu, 2014-11-06 at 04:51AM +0100, Andreas Färber wrote:
> Am 05.11.2014 um 18:03 schrieb Sören Brinkmann:
> > On Wed, 2014-11-05 at 06:56AM +0100, Andreas Färber wrote:
> >> I've tracked down all 54 MIO pins of the Parallella and cooked up the
> >> equivalent DT patch. [...] For testing purposes I've configured a
> >> heartbeat trigger for the USER_LED (CR10).
> >>
> >> To my disappointment these pinctrl additions did not fix one issue:
> >> Whenever a write access to be handled by the bitstream (0x808f0f04) is
> >> performed, the board hangs and the heartbeat stops. Would a bug in the
> >> bitstream allow this to happen, or are more drivers missing to actually
> >> make use of the PL in general? With a downstream ADI/Xilinx 3.12 kernel
> >> that problem does not surface.
> > 
> > This doesn't sound like being related to pinctrl at all.
> > Devices in the PL are just memory mapped on the AXI bus. There is
> > nothing needed to access those. Hangs do in most cases indicate that the
> > IP does not respond (properly). In my experience this is mostly caused
> > by 
> >  - level shifters not enabled
> >  - IP kept in reset
> >  - IP is clock gated
> > With the clock gating being the culprit in most cases. Did you check
> > those things?
> 
> Figured it out: zynq-7000.dtsi sets fclk-enable = <0>, i.e., all PL
> clocks are disabled by default. When overriding that tiny property with
> 0xf it suddenly works as expected! I'll send a patch later in the day.
> 
> Are boards expected to use clocks = < 15>, ...; on individual nodes
> relying on the PL? Or does enabling those clocks require actually
> loading a bitstream so that it is not being done by default?

Clocks are under control of drivers. Drivers are supposed to
use the clock framework to enable the clocks they use. The fclk-enable
is just a work around to enable driver-less IP and similar.

So, if your FPGA part has proper drivers, you should add the appropriate
description in DT and the drivers would need to use the CCF to enable
the clocks. Otherwise you can work around this by specifying
fclk-enable.

Sören
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 Part2 v4 21/31] PCI/MSI: enhance PCI MSI core to support hierarchy irqdomain

On Wed, Nov 5, 2014 at 6:58 PM, Yijing Wang  wrote:

>>> +{
>>> +return (irq_hw_number_t)msidesc->msi_attrib.entry_nr |
>>> +PCI_DEVID(pdev->bus->number, pdev->devfn) << 11 |
>>> +(pci_domain_nr(pdev->bus) & 0x) << 27;
>>
>> Where does this bit layout come from?  Is this defined in the spec
>> somewhere?  A reference would help.
>
> Currently, more and more Non-PCI device use MSI(or similar MSI mechanism), 
> like DMAR fault irq
> and HPET FSB irq. And we have to add additional code to support the MSI 
> capability.
> So I hope we can decouple MSI code and PCI code, then we can unify all MSI(or 
> Message Based interrupt)
> in one framework.

Was that supposed to answer my question?  If so, I didn't understand
how it explains where the bit layout came from.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Do not enable async suspend for JMicron chips

On Wed, Nov 5, 2014 at 6:48 PM, Liu, Chuansheng
 wrote:
> Hello Bjorn,
>
>> -Original Message-
>> From: Bjorn Helgaas [mailto:bhelg...@google.com]
>> Sent: Thursday, November 06, 2014 3:04 AM
>> To: Barto
>> Cc: Liu, Chuansheng; Lu, Aaron; Tejun Heo; Rafael Wysocki;
>> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH] PCI: Do not enable async suspend for JMicron chips
>>
>> On Wed, Nov 5, 2014 at 11:46 AM, Barto 
>> wrote:
>> > this patch solves these 2 bug reports :
>> >
>> > https://bugzilla.kernel.org/show_bug.cgi?id=84861
>> >
>> > https://bugzilla.kernel.org/show_bug.cgi?id=81551
>>
>> Those bugs were already mentioned.  But e6b7e41cdd8c claims to solve
>> https://bugzilla.kernel.org/show_bug.cgi?id=81551, and 84861 is a
>> duplicate of 81551, so it should also be fixed by e6b7e41cdd8c.
>>
>> So the question is, why was e6b7e41cdd8c insufficient?  Presumably it
>> was tested and somebody thought it did fix the problem.
>
> The first patch e6b7e41cdd8c which is just exclude some of JMicron 
> chips(363/361) out of async_suspend,
> then Barto found the same issue on JMicron 368, so we need one more general 
> patch to let JMicron chips
> out of async_suspend, so we make this patch.
>
> Bjorn, tj,
> Could you kindly take this patch? As Barto said, it effected the user 
> experience indeed, thanks.

Thanks for clarifying the changelog as far as the different chips and
the different bugzillas.

But you haven't addressed my concerns about (1) putting a PCI vendor
ID check in the generic PCI core code, and (2) applying this to *all*
JMicron devices.  You might want to explore a quirk-type solution or
maybe just add the JMicron 368 to the checks added by e6b7e41cdd8c.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] sched: idle: cpuidle: Check the latency req before idle

2014-11-05 Thread Preeti U Murthy

On 11/05/2014 07:58 PM, Daniel Lezcano wrote:
> On 10/29/2014 03:01 AM, Preeti U Murthy wrote:
>> On 10/29/2014 12:29 AM, Daniel Lezcano wrote:
>>> On 10/28/2014 04:51 AM, Preeti Murthy wrote:
 Hi Daniel,

 On Thu, Oct 23, 2014 at 2:31 PM, Daniel Lezcano
  wrote:
> When the pmqos latency requirement is set to zero that means "poll in
> all the
> cases".
>
> That is correctly implemented on x86 but not on the other archs.
>
> As how is written the code, if the latency request is zero, the
> governor will
> return zero, so corresponding, for x86, to the poll function, but for
> the
> others arch the default idle function. For example, on ARM this is
> wait-for-
> interrupt with a latency of '1', so violating the constraint.

 This is not true actually. On PowerPC the idle state 0 has an
 exit_latency of 0.

>
> In order to fix that, do the latency requirement check *before*
> calling the
> cpuidle framework in order to jump to the poll function without
> entering
> cpuidle. That has several benefits:

 Doing so actually hurts on PowerPC. Because the idle loop defined for
 idle state 0 is different from what cpu_relax() does in
 cpu_idle_loop().
 The spinning is more power efficient in the former case. Moreover we
 also set
 certain register values which indicate an idle cpu. The ppc_runlatch
 bits
 do precisely this. These register values are being read by some user
 space
 tools.  So we will end up breaking them with this patch

 My suggestion is very well keep the latency requirement check in
 kernel/sched/idle.c
 like your doing in this patch. But before jumping to cpu_idle_loop
 verify if the
 idle state 0 has an exit_latency > 0 in addition to your check on the
 latency_req == 0.
 If not, you can fall through to the regular path of calling into the
 cpuidle driver.
 The scheduler can query the cpuidle_driver structure anyway.

 What do you think?
>>>
>>> Thanks for reviewing the patch and spotting this.
>>>
>>> Wouldn't make sense to create:
>>>
>>> void __weak_cpu_idle_poll(void) ?
>>>
>>> and override it with your specific poll function ?
>>>
>>
>> No this would become ugly as far as I can see. A weak function has to be
>> defined under arch/* code. We will either need to duplicate the idle
>> loop that we already have in the drivers or point the weak function to
>> the first idle state defined by our driver. Both of which is not
>> desirable (calling into the driver from arch code is ugly). Another
>> reason why I don't like the idea of a weak function is that if you have
>> missed looking at a specific driver and they have an idle loop with
>> features similar to on powerpc, you will have to spot it yourself and
>> include the arch specific cpu_idle_poll() for them.
> 
> Yes, I agree this is a fair point. But actually I don't see the interest
> of having the poll loop in the cpuidle driver. These cleanups are

We can't do that simply because the idle poll loop has arch specific
bits on powerpc.

> preparing the removal of the CPUIDLE_DRIVER_STATE_START macro which
> leads to a lot of mess in the cpuidle code.

How is the suggestion to check the exit_latency of idle state 0 when
latency_req  == 0 going to hinder this removal?

> 
> With the removal of this macro, we should be able to move the select
> loop from the menu governor and use it everywhere else. Furthermore,
> this state which is flagged with TIME_VALID, isn't because the local
> interrupt are enabled so we are measuring the interrupt time processing.
> Beside that the idle loop for x86 is mostly not used.
> 
> So the idea would be to extract those idle loop from the drivers and use
> them directly when:
>  1. the idle selection fails (use the poll loop under certain
> circumstances we have to redefine)

This behavior will not change as per my suggestion.

>  2. when the latency req is zero

Its only here that I suggested you also verify state 0's exit_latency.
For the reason that the arch may have a more optimized idle poll loop,
which we cannot override with the generic cpuidle poll loop.

Regards
Preeti U Murthy
> 
> That will result in a cleaner code in cpuidle and in the governor.
> 
> Do you agree with that ?
> 
>> But by having a check on the exit_latency, you are claiming that since
>> the driver's 0th idle state is no better than the generic idle loop in
>> cases of 0 latency req, we are better off calling the latter, which
>> looks reasonable. That way you don't have to bother about worsening the
>> idle loop behavior on any other driver.
> 
> 
> 
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 Part2 v4 20/31] PCI/MSI: Kill redundant calling for irq_set_msi_desc() for MSIx interrupts

On Wed, Nov 5, 2014 at 6:32 PM, Yijing Wang  wrote:
> On 2014/11/6 6:45, Bjorn Helgaas wrote:
>> On Tue, Nov 04, 2014 at 08:01:54PM +0800, Jiang Liu wrote:
>>> It's arch_setup_msi_irq()/arch_setup_msi_irqs()'s responsibility to call
>>> irq_set_msi_desc() to associate IRQ descriptors and MSI descriptors,
>>> so kill the redundant call of irq_set_msi_desc() for MSIx interrupts
>>> in PCI MSI core.
>>
>> "MSI-X" in English text, "msix" in code.
>>
>> The default arch_setup_msi_irq() in drivers/pci/msi.c doesn't call
>> irq_set_msi_desc().  Does it happen somewhere inside chip->setup_irq()?
>
> Yes.
>
> I also found this.
> http://www.spinics.net/lists/linux-pci/msg34256.html

Yes, and I asked the same question then :)

It's just impractical to review things like this that make assumptions
about lots of code scattered all over the place with no direct linkage
to the change.

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

linux-next: manual merge of the usb-gadget tree with the usb tree