date:20150408

From: Xunlei Pang 

If there're multiple nodes with the same prio as @node, currently
plist_add() will add @node behind all of them. Now we need to add
@node before all of these nodes for SMP RT scheduler.

This patch adds a common __plist_add() for adding @node before or
after existing nodes with the same prio, then adds plist_add_head()
and plist_add_tail() inline wrapper functions for convenient uses.

Finally, define plist_add() as plist_add_tail() which has the same
behaviour as before.

Reviewed-by: Dan Streetman 
Signed-off-by: Xunlei Pang 
---
 include/linux/plist.h | 30 +-
 lib/plist.c   | 22 +++---
 2 files changed, 48 insertions(+), 4 deletions(-)

diff --git a/include/linux/plist.h b/include/linux/plist.h
index 9788360..10c834c 100644
--- a/include/linux/plist.h
+++ b/include/linux/plist.h
@@ -138,7 +138,35 @@ static inline void plist_node_init(struct plist_node 
*node, int prio)
INIT_LIST_HEAD(>node_list);
 }
 
-extern void plist_add(struct plist_node *node, struct plist_head *head);
+extern void __plist_add(struct plist_node *node,
+   struct plist_head *head, bool is_head);
+
+/**
+ * plist_add_head - add @node to @head, before all existing same-prio nodes
+ *
+ * @node:   plist_node pointer
+ * @head:   plist_head pointer
+ */
+static inline
+void plist_add_head(struct plist_node *node, struct plist_head *head)
+{
+   __plist_add(node, head, true);
+}
+
+/**
+ * plist_add_tail - add @node to @head, after all existing same-prio nodes
+ *
+ * @node:   plist_node pointer
+ * @head:   plist_head pointer
+ */
+static inline
+void plist_add_tail(struct plist_node *node, struct plist_head *head)
+{
+   __plist_add(node, head, false);
+}
+
+#define plist_add plist_add_tail
+
 extern void plist_del(struct plist_node *node, struct plist_head *head);
 
 extern void plist_requeue(struct plist_node *node, struct plist_head *head);
diff --git a/lib/plist.c b/lib/plist.c
index 3a30c53..9f396f1 100644
--- a/lib/plist.c
+++ b/lib/plist.c
@@ -66,12 +66,16 @@ static void plist_check_head(struct plist_head *head)
 #endif
 
 /**
- * plist_add - add @node to @head
+ * __plist_add - add @node to @head
  *
  * @node:   plist_node pointer
  * @head:   plist_head pointer
+ * @is_head:   bool
+ *
+ * If there're any nodes with the same prio, add @node
+ * behind or before all of them according to @is_head.
  */
-void plist_add(struct plist_node *node, struct plist_head *head)
+void __plist_add(struct plist_node *node, struct plist_head *head, bool 
is_head)
 {
struct plist_node *first, *iter, *prev = NULL;
struct list_head *node_next = >node_list;
@@ -96,8 +100,20 @@ void plist_add(struct plist_node *node, struct plist_head 
*head)
struct plist_node, prio_list);
} while (iter != first);
 
-   if (!prev || prev->prio != node->prio)
+   if (!prev || prev->prio != node->prio) {
list_add_tail(>prio_list, >prio_list);
+   } else if (is_head) {
+   /*
+* prev has the same priority as the node that is being
+* added. It is also the first node for this priority,
+* but the new node needs to be added ahead of it.
+* To accomplish this, replace prev in the prio_list
+* with node. Then set node_next to prev->node_list so
+* that the new node gets added before prev and not iter.
+*/
+   list_replace_init(>prio_list, >prio_list);
+   node_next = >node_list;
+   }
 ins_node:
list_add_tail(>node_list, node_next);
 
-- 
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 v5 2/3] sched/rt: Fix wrong SMP scheduler behavior for equal prio cases

From: Xunlei Pang 

Currently, SMP RT scheduler has some trouble in dealing with
equal prio cases.

For example, in check_preempt_equal_prio():
When RT1(current task) gets preempted by RT2, if there is a
migratable RT3 with same prio, RT3 will be pushed away instead
of RT1 afterwards, because RT1 will be enqueued to the tail of
the pushable list when going through succeeding put_prev_task_rt()
triggered by resched. This broke FIFO.

Furthermore, this is also problematic for normal preempted cases
if there're some rt tasks queued with the same prio as current.
Because current will be put behind these tasks in the pushable
queue.

So, if a task is running and gets preempted by a higher priority
task (or even with same priority for migrating), this patch ensures
that it is put ahead of any existing task with the same priority in
the pushable queue.

Suggested-by: Steven Rostedt 
Signed-off-by: Xunlei Pang 
---
 kernel/sched/rt.c | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 575da76..402162a 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -359,11 +359,15 @@ static inline void set_post_schedule(struct rq *rq)
rq->post_schedule = has_pushable_tasks(rq);
 }
 
-static void enqueue_pushable_task(struct rq *rq, struct task_struct *p)
+static void
+enqueue_pushable_task(struct rq *rq, struct task_struct *p, bool head)
 {
plist_del(>pushable_tasks, >rt.pushable_tasks);
plist_node_init(>pushable_tasks, p->prio);
-   plist_add(>pushable_tasks, >rt.pushable_tasks);
+   if (head)
+   plist_add_head(>pushable_tasks, >rt.pushable_tasks);
+   else
+   plist_add_tail(>pushable_tasks, >rt.pushable_tasks);
 
/* Update the highest prio pushable task */
if (p->prio < rq->rt.highest_prio.next)
@@ -385,7 +389,8 @@ static void dequeue_pushable_task(struct rq *rq, struct 
task_struct *p)
 
 #else
 
-static inline void enqueue_pushable_task(struct rq *rq, struct task_struct *p)
+static inline
+void enqueue_pushable_task(struct rq *rq, struct task_struct *p, bool head)
 {
 }
 
@@ -1260,7 +1265,7 @@ enqueue_task_rt(struct rq *rq, struct task_struct *p, int 
flags)
enqueue_rt_entity(rt_se, flags & ENQUEUE_HEAD);
 
if (!task_current(rq, p) && p->nr_cpus_allowed > 1)
-   enqueue_pushable_task(rq, p);
+   enqueue_pushable_task(rq, p, false);
 }
 
 static void dequeue_task_rt(struct rq *rq, struct task_struct *p, int flags)
@@ -1507,7 +1512,16 @@ static void put_prev_task_rt(struct rq *rq, struct 
task_struct *p)
 * if it is still active
 */
if (on_rt_rq(>rt) && p->nr_cpus_allowed > 1)
-   enqueue_pushable_task(rq, p);
+   /*
+* put_prev_task_rt() is called by many functions,
+* pick_next_task_rt() is the only one may have
+* PREEMPT_ACTIVE set. So if detecting p(current
+* task) is preempted in such case, we should
+* enqueue it to the front of the pushable plist,
+* as there may be multiple tasks with the same
+* priority as p.
+*/
+   enqueue_pushable_task(rq, p, !!(preempt_count() & 
PREEMPT_ACTIVE));
 }
 
 #ifdef CONFIG_SMP
@@ -2091,7 +2105,7 @@ static void set_cpus_allowed_rt(struct task_struct *p,
rq->rt.rt_nr_migratory--;
} else {
if (!task_current(rq, p))
-   enqueue_pushable_task(rq, p);
+   enqueue_pushable_task(rq, p, false);
rq->rt.rt_nr_migratory++;
}
 
-- 
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 v5 3/3] sched/rt: Check to push the task when changing its affinity

From: Xunlei Pang 

We may suffer from extra rt overload rq due to the affinity,
so when the affinity of any runnable rt task is changed, we
should check to trigger balancing, otherwise it will cause
some unnecessary delayed real-time response. Unfortunately,
current RT global scheduler doesn't trigger anything.

For example: a 2-cpu system with two runnable FIFO tasks(same
rt_priority) bound on CPU0, let's name them rt1(running) and
rt2(runnable) respectively; CPU1 has no RTs. Then, someone sets
the affinity of rt2 to 0x3(i.e. CPU0 and CPU1), but after this,
rt2 still can't be scheduled until rt1 enters schedule(), this
definitely causes some/big response latency for rt2.

So, when doing set_cpus_allowed_rt(), if detecting such cases,
check to trigger a push behaviour.

Signed-off-by: Xunlei Pang 
---
 kernel/sched/rt.c | 81 ---
 1 file changed, 71 insertions(+), 10 deletions(-)

diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 402162a..9704ed3 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1445,10 +1445,9 @@ static struct sched_rt_entity 
*pick_next_rt_entity(struct rq *rq,
return next;
 }
 
-static struct task_struct *_pick_next_task_rt(struct rq *rq)
+static struct task_struct *peek_next_task_rt(struct rq *rq)
 {
struct sched_rt_entity *rt_se;
-   struct task_struct *p;
struct rt_rq *rt_rq  = >rt;
 
do {
@@ -1457,7 +1456,14 @@ static struct task_struct *_pick_next_task_rt(struct rq 
*rq)
rt_rq = group_rt_rq(rt_se);
} while (rt_rq);
 
-   p = rt_task_of(rt_se);
+   return rt_task_of(rt_se);
+}
+
+static inline struct task_struct *_pick_next_task_rt(struct rq *rq)
+{
+   struct task_struct *p;
+
+   p = peek_next_task_rt(rq);
p->se.exec_start = rq_clock_task(rq);
 
return p;
@@ -2077,28 +2083,77 @@ static void set_cpus_allowed_rt(struct task_struct *p,
const struct cpumask *new_mask)
 {
struct rq *rq;
-   int weight;
+   int old_weight, new_weight;
+   int preempt_push = 0, direct_push = 0;
 
BUG_ON(!rt_task(p));
 
if (!task_on_rq_queued(p))
return;
 
-   weight = cpumask_weight(new_mask);
+   old_weight = p->nr_cpus_allowed;
+   new_weight = cpumask_weight(new_mask);
 
+   rq = task_rq(p);
+
+   if (new_weight > 1 &&
+   rt_task(rq->curr) &&
+   rq->rt.rt_nr_total > 1 &&
+   !test_tsk_need_resched(rq->curr)) {
+   /*
+* We own p->pi_lock and rq->lock. rq->lock might
+* get released when doing direct pushing, however
+* p->pi_lock is always held, so it's safe to assign
+* new_mask and new_weight to p below.
+*/
+   if (!task_running(rq, p)) {
+   cpumask_copy(>cpus_allowed, new_mask);
+   p->nr_cpus_allowed = new_weight;
+   direct_push = 1;
+   } else if (cpumask_test_cpu(task_cpu(p), new_mask)) {
+   struct task_struct *next;
+
+   cpumask_copy(>cpus_allowed, new_mask);
+   p->nr_cpus_allowed = new_weight;
+   if (!cpupri_find(>rd->cpupri, p, NULL))
+   goto update;
+
+   /*
+* At this point, current task gets migratable most
+* likely due to the change of its affinity, let's
+* figure out if we can migrate it.
+*
+* Can we find any task with the same priority as
+* current? To accomplish this, firstly we requeue
+* current to the tail and peek next, then restore
+* current to the head.
+*/
+   requeue_task_rt(rq, p, 0);
+   next = peek_next_task_rt(rq);
+   requeue_task_rt(rq, p, 1);
+   if (next != p && next->prio == p->prio) {
+   /*
+* Target found, so let's reschedule to try
+* and push current away.
+*/
+   requeue_task_rt(rq, next, 1);
+   preempt_push = 1;
+   }
+   }
+   }
+
+update:
/*
 * Only update if the process changes its state from whether it
 * can migrate or not.
 */
-   if ((p->nr_cpus_allowed > 1) == (weight > 1))
-   return;
-
-   rq = task_rq(p);
+   if ((old_weight > 1) == (new_weight > 1))
+   goto out;
 
/*
 * The process used to be able to migrate OR it can now migrate
 */
-   if (weight <= 1) {

Re: [PATCH V2] x86/numa: kernel stack corruption fix

2015-04-08 Thread Baoquan He

On 04/08/15 at 11:09am, Dave Young wrote:
> On 04/08/15 at 10:41am, Xishi Qiu wrote:
> > >> Hi Dave,
> > >>
> > >> I made a mistake, when numa is on, numa_meminfo is from SRAT, but it 
> > >> will be cut
> > >> in numa_cleanup_meminfo(), so the bug is not related to numa on/off. 
> > >> Your comment
> > >> is right.
> > > 
> > > Hi Xishi,
> > > 
> > >>From code flow it's exact as you said. And if remove numa=off bug should
> > > be reproduced alwasy. I talked to Dave, he said error didn't occur when
> > > he remove numa=off. That is too weird.
> > > 
> > 
> > Hi Baoquan,
> > 
> > May be it wrote over end of numa mask bitmap, but the stack can still run,
> > so there is no Call Trace. 
> > How about add some printk to see if it has written over? 
> 
> Oops, Redhat kdump always add numa=off in 2nd kernel commandline, but I did
> not notice I removed it during test.
> 
> So yes, the issue does not depend on numa=off.

OK, got it. thanks. Ack this patch.

Acked-by: Baoquan He 

Thanks
Baoquan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 kernel v7 26/31] powerpc/iommu: Add userspace view of TCE table

2015-04-08 Thread Alexey Kardashevskiy


On 04/09/2015 01:43 AM, Alex Williamson wrote:

On Wed, 2015-04-08 at 13:22 +1000, Alexey Kardashevskiy wrote:

On 04/03/2015 07:50 AM, Alex Williamson wrote:


Should have sent this with the other comments, but found it hiding on my
desktop...

On Sat, 2015-03-28 at 01:55 +1100, Alexey Kardashevskiy wrote:

In order to support memory pre-registration, we need a way to track
the use of every registered memory region and only allow unregistration
if a region is not in use anymore. So we need a way to tell from what
region the just cleared TCE was from.

This adds a userspace view of the TCE table into iommu_table struct.
It contains userspace address, one per TCE entry. The table is only
allocated when the ownership over an IOMMU group is taken which means
it is only used from outside of the powernv code (such as VFIO).

Signed-off-by: Alexey Kardashevskiy 
---
   arch/powerpc/include/asm/iommu.h  |  6 ++
   arch/powerpc/kernel/iommu.c   |  7 +++
   arch/powerpc/platforms/powernv/pci-ioda.c | 23 ++-
   3 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index 2c08c91..a768a4d 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -106,9 +106,15 @@ struct iommu_table {
unsigned long *it_map;   /* A simple allocation bitmap for now */
unsigned long  it_page_shift;/* table iommu page size */
struct iommu_table_group *it_group;
+   unsigned long *it_userspace; /* userspace view of the table */
struct iommu_table_ops *it_ops;
   };

+#define IOMMU_TABLE_USERSPACE_ENTRY(tbl, entry) \
+   ((tbl)->it_userspace ? \
+   &((tbl)->it_userspace[(entry) - (tbl)->it_offset]) : \
+   NULL)
+
   /* Pure 2^n version of get_order */
   static inline __attribute_const__
   int get_iommu_order(unsigned long size, struct iommu_table *tbl)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 0bcd988..82102d1 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -38,6 +38,7 @@
   #include 
   #include 
   #include 
+#include 
   #include 
   #include 
   #include 
@@ -1069,6 +1070,9 @@ static int iommu_table_take_ownership(struct iommu_table 
*tbl)
spin_unlock(>pools[i].lock);
spin_unlock_irqrestore(>large_pool.lock, flags);

+   BUG_ON(tbl->it_userspace);
+   tbl->it_userspace = vzalloc(sizeof(*tbl->it_userspace) * tbl->it_size);
+


-ENOMEM?


return 0;
   }

@@ -1102,6 +1106,9 @@ static void iommu_table_release_ownership(struct 
iommu_table *tbl)
   {
unsigned long flags, i, sz = (tbl->it_size + 7) >> 3;

+   vfree(tbl->it_userspace);
+   tbl->it_userspace = NULL;
+
spin_lock_irqsave(>large_pool.lock, flags);
for (i = 0; i < tbl->nr_pools; i++)
spin_lock(>pools[i].lock);
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index bc36cf1..036f3c1 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -26,6 +26,7 @@
   #include 
   #include 
   #include 
+#include 

   #include 
   #include 
@@ -1469,6 +1470,9 @@ static void pnv_pci_free_table(struct iommu_table *tbl)
if (!tbl->it_size)
return;

+   if (tbl->it_userspace)


Not necessary


Out of curiosity - why? Is every single implementation is known for
checking the argument?


AFAIK, all flavors of free in the kernel accept NULL pointers and do the
right thing.  I verified this one does too.


+   vfree(tbl->it_userspace);
+


Why no NULL setting this time?


iommu_reset_table() (2 lines below) will do memset(0) on the entire struct.


So then should iommu_reset_table() handle the vfree() as well?



I wanted to keep vfree() in the same file with vzalloc(). Bad idea?
But I'll move vfree() to iommu_reset_table() anyway.





pnv_free_tce_table(tbl->it_base, size, tbl->it_indirect_levels);
iommu_reset_table(tbl, "ioda2");
   }
@@ -1656,9 +1660,26 @@ static void pnv_ioda2_set_ownership(struct 
iommu_table_group *table_group,
pnv_pci_ioda2_set_bypass(pe, !enable);
   }

+static long pnv_pci_ioda2_create_table_with_uas(
+   struct iommu_table_group *table_group,
+   int num, __u32 page_shift, __u64 window_size, __u32 levels,
+   struct iommu_table *tbl)
+{
+   long ret = pnv_pci_ioda2_create_table(table_group, num,
+   page_shift, window_size, levels, tbl);
+
+   if (ret)
+   return ret;
+
+   BUG_ON(tbl->it_userspace);
+   tbl->it_userspace = vzalloc(sizeof(*tbl->it_userspace) * tbl->it_size);


-ENOMEM


+
+   return 0;
+}
+
   static struct iommu_table_group_ops pnv_pci_ioda2_ops = {
.set_ownership = pnv_ioda2_set_ownership,
-

Re: [PATCH 3/3] PCI: Set pref for mem64 resource of pcie device

2015-04-08 Thread Benjamin Herrenschmidt

On Wed, 2015-04-08 at 17:06 -0700, Yinghai Lu wrote:
> On Wed, Apr 8, 2015 at 2:12 PM, Benjamin Herrenschmidt
>  wrote:
> 
> > Thanks Bjorn. We can fix Yinghai patch for 4.2, it would be indeed handy
> > even for us to be able to support putting 64-bit NP BARs in prefetch
> > windows (For some SR-IOV adapters for example) too, but we need to do it
> > right.
> 
> Please check if you are ok with attached.

I'll let Bjorn be the final judge here but I am not fan of the way you
set/clear/set/clear the IORESOURCE_PREFETCH bit with
pci_set_pref_under_pref(). It's error prone and confusing, the code is
already barely readable as it is ...

I would rather you replace those various masks compares with a helper
that does something like pci_resource_compatible(parent_res, child_res),
which has the logic to test. That or a helper that does something like
pci_calc_compatible_res_flags() which returns a "flags" that has
PREFETCH set, which you use in place of res->flags in the various
allocation path.

As-is, your patch looks like a band-aid and smells like a hack :-)

Ben.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] of/flattree: print memory scan node results in CPU endian

2015-04-08 Thread Florian Fainelli

Le 08/04/2015 14:19, Frank Rowand a écrit :
> On 4/7/2015 11:44 PM, Florian Fainelli wrote:
>> Commit 51975db0b7333 ("of/flattree: merge early_init_dt_scan_memory()
>> common code") consolidated some code from PowerPC (typically
>> big-endian), and ended-up adding a pr_debug() printing reg properties in
>> big-endian (DT native) format, not CPU endian. Unsurprisingly, when
>> these messages are turned on a little-endian systems, this is confusing,
>> so do the conversion while printing the values.
>>
>> Signed-off-by: Florian Fainelli 
>> ---
>>  drivers/of/fdt.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>> index 3a896c9aeb74..0d8f0e4bd107 100644
>> --- a/drivers/of/fdt.c
>> +++ b/drivers/of/fdt.c
>> @@ -880,7 +880,8 @@ int __init early_init_dt_scan_memory(unsigned long node, 
>> const char *uname,
>>  endp = reg + (l / sizeof(__be32));
>>  
>>  pr_debug("memory scan node %s, reg size %d, data: %x %x %x %x,\n",
>> -uname, l, reg[0], reg[1], reg[2], reg[3]);
>> +uname, l, be32_to_cpu(reg[0]), be32_to_cpu(reg[1]),
>> +be32_to_cpu(reg[2]), be32_to_cpu(reg[3]));
> 
> The pr_debug() assumes that the length of reg[] is >= 4 elements, which might 
> not be true.
> Since the following while loop checks the length of reg[] and then uses 
> pr_debug() to
> print each (base, size) tuple with the correct endian, maybe it would be 
> better to
> just remove reg[0] through reg[3] from the above pr_debug() instead of fixing 
> the
> endian issue.

Right, that works too, will follow-up with a patch removing the
reg[0..3] prints.

Thanks!
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] devicetree: add ibm-nx-powernv details

2015-04-08 Thread Dan Streetman

Add a devicetree description for property nodes for the NX Coprocessor
in an IBM PowerPC processor.

Signed-off-by: Dan Streetman 
---

Is this the right location/naming for this file?
And did I get the content format right?

Should this file be called "ibm-nx-opal.txt" instead of "ibm-nx-powernv.txt",
since it's the Opal firmware that provides the nodes (although they are
used by the PowerNV platform kernel)?

The 842 properties are used by the PowerNV 842 driver patch set I
sent out yesterday, and which I'll send a v2 of soon.

.../devicetree/bindings/crypto/ibm-nx-powernv.txt  | 40 ++
 1 file changed, 40 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/ibm-nx-powernv.txt

diff --git a/Documentation/devicetree/bindings/crypto/ibm-nx-powernv.txt 
b/Documentation/devicetree/bindings/crypto/ibm-nx-powernv.txt
new file mode 100644
index 000..e031636
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/ibm-nx-powernv.txt
@@ -0,0 +1,40 @@
+Device-tree bindings for PowerNV platform IBM Nest (NX) Coprocessor
+---
+
+Required properties:
+
+- compatible: must contain "ibm,power-nx"; may also contain the processor
+  version, e.g. "ibm,power8-nx"
+
+Optional properties:
+
+- ibm,842-coprocessor-type: CT of this NX 842 coprocessor
+- ibm,842-coprocessor-instance: CI of this NX 842 coprocessor
+
+If present, the NX-842 Coprocessor Type (CT) and Coprocessor Instance (CI)
+can be used in an ICSWX instruction to communicate with the NX-842
+coprocessor, to perform hardware compression/decompression.
+
+Additionally, there must be an "ibm,chip-id" node at some point in the
+direct devicetree hierarchy leading to the nx node; typically the nx
+node's parent is an xscom node, which contains the "ibm,chip-id" property.
+
+Example:
+
+nx@201 {
+   compatible = "ibm,power-nx", "ibm,power8-nx";
+   ibm,842-coprocessor-type = <0x3>;
+   ibm,842-coprocessor-instance = <0x1>;
+   name = "nx";
+   reg = <0x201 0x4000>;
+   linux,phandle = <0x85>;
+   phandle = <0x85>;
+};
+
+with a parent of:
+
+xscom@3fc00 {
+   ibm,chip-id = <0x0>;
+   nx@201;
+   ...
+};
-- 
2.1.0

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

Re: [Bugfix v3] x86/PCI/ACPI: Fix regression caused by commit 63f1789ec716

2015-04-08 Thread Jiang Liu

On 2015/4/9 7:44, Rafael J. Wysocki wrote:
> On Wednesday, April 08, 2015 01:48:46 PM Jiang Liu wrote:
>> On 2015/4/7 8:28, Rafael J. Wysocki wrote:
>>> On Friday, April 03, 2015 10:04:11 PM Bjorn Helgaas wrote:
 Hi Jiang,
>> 
> Currently acpi_dev_filter_resource_type() is only used by ACPI pci
> host bridge and IOAPIC driver, so it shouldn't affect other drivers.

 We should assume it will eventually be used for all ACPI devices,
 shouldn't we?
>>>
>>> I'm not sure about that, really.  In fact, I'd restrict its use to devices
>>> types that actually can "produce" resources (ie. do not require the 
>>> resources
>>> to be provided by their ancestors or to be available from a global pool).
>>>
>>> Otherwise we're pretty much guaranteed to get into trouble.
>>>
>>> And all of the above rules need to be documented in the kernel source tree
>>> or people will get confused.
>> Hi Rafael,
>> How about following comments for acpi_dev_filter_resource_type()?
>> Thanks!
>> Gerry
>> 
>> /**
>>  * According to ACPI specifications, Consumer/Producer flag in ACPI resource
>>  * descriptor means:
>>  *  1(CONSUMER): This device consumes this resource
>>  *  0(PRODUCER): This device produces and consumes this resource
>>  * But for ACPI PCI host bridge, it is interpreted in another way:
> 
> So first of all, this leads to a question: Why is it interpreted for ACPI PCI
> host bridges differently?
> 
> Is it something we've figured out from experience, or is there a standard
> mandating that? 
Hi Rafael,
I think we got this knowledge by experiences. PCI FW spec only
states _CRS reports resources assigned to the host bridge by firmware.
There's no statement about whether the resource is consumed by host
bridge itself or provided to it's child bus/devices. On x86/IA64 side,
the main resource consumed by PCI host bridge is IOPORT 0xCF8-0xCFF,
but not sure about ARM64 side. So how about:
PCI Firmware specification states that _CRS reports resources
assigned to the host bridge, but there's no way to tell whether
the resource is consumed by host bridge itself or provided to
its child bus/devices. So according to experiences, PCI host bridge
interprets Consumer/Producer flag as below to tell whether the resource
is consumed by host bridge itself.

> 
>>  *  1(CONSUMER): PCI host bridge itself consumes the resource, such as
>>  *   IOPORT 0xCF8-0xCFF to access PCI configuraiton space.
>>  *  0(PRODUCER): PCI host bridge provides this resource to its child
>>  *   bus and devices.
>>  *
>>  * So this is a specially designed helper function to support ACPI PCI host
>>  * bridge and ACPI IOAPIC, and its usage should be limited to those specific
> 
> And this will make the reader wonder why the IOAPIC should be treated the same
> way as a PCI host bridge in that respect.
If a hot-pluggable IOAPIC is represented as an ACPI device, its _CRS
reports MMIO address assigned to the IOAPIC. And an IOAPIC device
won't produce MMIO resources by itself. So we could reuse
acpi_dev_filter_resource_type() here.
How about:
  * So this is a specially designed helper function to support:
  * 1) ACPI PCI host bridge, as explained above
  * 2) ACPI IOAPIC, its _CRS reports only one MMIO resource and
  *it won't produce MMIO resources by itself.

Thanks!
Gerry

> 
>>  * scenarioso only. It filters ACPI resource descriptors as below:
>>  * 1) If flag IORESOURCE_WINDOW is not specified, it's querying resources
>>  *consumed by device. That is to return:
>>  *  a) ACPI resources without producer_consumer flag
>>  *  b) ACPI resources with producer_consumer flag setting to CONSUMER.
>>  * 2) If flag IORESOURCE_WINDOW is specified, it's querying resources
>> provided
>>  *by device. That is to return:
>>  *  a) ACPI resources with producer_consumer flag setting to PRODUCER.
>>  * 3) But there's an exception. Some platforms, such as PC Engines APU.1C,
>>  *report PCI host bridge resource provision by Memory32Fixed().
>>  *Please refer to https://bugzilla.kernel.org/show_bug.cgi?id=94221
>>  *So a special flag IORESOURCE_MEM_8AND16BIT is used to work around this
>>  *BIOS issue.
>>  */
>>
>>>
> Another possible fix is to only ignore IO resource consumed by host
> bridge and keep IOMEM resource consumed by host bridge, please refer to:
> http://www.spinics.net/lists/linux-pci/msg39706.html
>
> Sample ACPI table are archived at:
> https://bugzilla.kernel.org/show_bug.cgi?id=94221
>
> V2->V3:
> Refine function acpi_dev_match_producer_consumer() as suggested by Rafael
>
> Fixes: 63f1789ec716("Ignore resources consumed by host bridge itself")
> Reported-and-Tested-by: Bernhard Thaler 
> Signed-off-by: Jiang Liu 
> ---
>  arch/x86/pci/acpi.c |5 ++---
>  drivers/acpi/resource.c |   33

[PATCH] tty/serial: at91: handle IRQ status more safely

2015-04-08 Thread Leilei Zhao

Handle the changed flag of IRQ status in interruption
instead of handling it in tasklet due to the tasklet
may be scheduled more than once in one interruption.
Otherwise, the changed status may be processed more
than once which will lead to unexpected result. And
seriously, kernel will crash.

Signed-off-by: Leilei Zhao 
Acked-by: Nicolas Ferre 
---
 drivers/tty/serial/atmel_serial.c |   13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c 
b/drivers/tty/serial/atmel_serial.c
index d58fe47..d536d31 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -165,6 +165,7 @@ struct atmel_uart_port {
struct tasklet_struct   tasklet;
unsigned intirq_status;
unsigned intirq_status_prev;
+   unsigned intstatus_change;
 
struct circ_buf rx_ring;
 
@@ -1175,6 +1176,9 @@ atmel_handle_status(struct uart_port *port, unsigned int 
pending,
if (pending & (ATMEL_US_RIIC | ATMEL_US_DSRIC | ATMEL_US_DCDIC
| ATMEL_US_CTSIC)) {
atmel_port->irq_status = status;
+   atmel_port->status_change = atmel_port->irq_status ^
+   atmel_port->irq_status_prev;
+   atmel_port->irq_status_prev = status;
tasklet_schedule(_port->tasklet);
}
 }
@@ -1521,17 +1525,14 @@ static void atmel_tasklet_func(unsigned long data)
 {
struct uart_port *port = (struct uart_port *)data;
struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
-   unsigned int status;
-   unsigned int status_change;
+   unsigned int status = atmel_port->irq_status;
+   unsigned int status_change = atmel_port->status_change;
 
/* The interrupt handler does not take the lock */
spin_lock(>lock);
 
atmel_port->schedule_tx(port);
 
-   status = atmel_port->irq_status;
-   status_change = status ^ atmel_port->irq_status_prev;
-
if (status_change & (ATMEL_US_RI | ATMEL_US_DSR
| ATMEL_US_DCD | ATMEL_US_CTS)) {
/* TODO: All reads to CSR will clear these interrupts! */
@@ -1546,7 +1547,7 @@ static void atmel_tasklet_func(unsigned long data)
 
wake_up_interruptible(>state->port.delta_msr_wait);
 
-   atmel_port->irq_status_prev = status;
+   atmel_port->status_change = 0;
}
 
atmel_port->schedule_rx(port);
-- 
1.7.9.5

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

Re: [PATCH V2 2/2] hrtimer: Iterate only over active clock-bases

2015-04-08 Thread Viresh Kumar

On 9 April 2015 at 01:41, Thomas Gleixner  wrote:
> I'm really not too excited about this incomprehensible macro mess and
> especially not about the code it generates.
>
> x86_64  i386ARM power
>
> Mainline76686942807710253
>
> + Patch 80687294831310861
>
> +400+352+236 +608
>
> That's insane.

After Peter's mail yesterday, I did check it on x86_64 and it surely
looked a lot bigger.

> What's wrong with just adding
>
> if (!(cpu_base->active_bases & (1 << i)))
> continue;
>
> to the iterating sites?
>
> Index: linux/kernel/time/hrtimer.c
> ===
> --- linux.orig/kernel/time/hrtimer.c
> +++ linux/kernel/time/hrtimer.c
> @@ -451,6 +451,9 @@ static ktime_t __hrtimer_get_next_event(
> struct timerqueue_node *next;
> struct hrtimer *timer;
>
> +   if (!(cpu_base->active_bases & (1 << i)))
> +   continue;
> +
> next = timerqueue_getnext(>active);
> if (!next)
> continue;

Isn't the check we already have here lightweight enough for this ?
timerqueue_getnext() returns head->next..

What benefit are we getting with this extra check ?

Maybe we can drop 'active_bases' from struct hrtimer_cpu_base ?

'active_bases' can be used effectively, if we can quit early from this
loop, i.e. by checking for !active_bases on every iteration.

But that generates a lot more code and is probably not that helpful
for small loop size that we have here.

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

Re: sched: Improve load balancing in the presence of idle CPUs

2015-04-08 Thread Jason Low

On Wed, 2015-04-08 at 16:42 +0530, Srikar Dronamraju wrote:
> * Jason Low  [2015-04-07 17:07:46]:
> > @@ -7687,7 +7700,7 @@ static inline bool nohz_kick_needed(struct rq *rq)
> > int nr_busy, cpu = rq->cpu;
> > bool kick = false;
> > 
> > -   if (unlikely(rq->idle_balance))
> > +   if (unlikely(idle_cpu(cpu)))
> > return false;
> 
> 
> The only other place that we use idle_balance is
> run_rebalance_domains(). Would it make sense to just use idle_cpu() in
> run_rebalance_domains() and remove rq->idle_balance?

Hi Srikar,

So the idle_balance is used for storing the idle state of the CPU before
calling the softirq, for load balancing decisions. In that case, we may
need to keep this extra variable in order to store that information.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] CLONE_FD: Task exit notification via file descriptor

2015-04-08 Thread Josh Triplett

On Wed, Apr 01, 2015 at 09:24:20AM +0200, Jonathan Corbet wrote:
> On Tue, 31 Mar 2015 15:02:24 -0700
> j...@joshtriplett.org wrote:
> 
> > > This would appear to assume that a clonefd_info structure is the only
> > > thing that will ever be read from this descriptor.  It seems to me that
> > > there is the potential for, someday, wanting to be able to read and write
> > > other things as well.  Should this structure be marked with type and
> > > length fields so that other structures could be added in the future?  
> > 
> > I don't think it makes sense for a caller to get an arbitrary structure
> > on read(), and have to figure out what they got and ignore something
> > they don't understand.  Instead, I think it makes more sense for the
> > caller to say "Hey, here's a flag saying I understand the new thing, go
> > ahead and give me the new thing".  So, for instance, if you want to
> > receive SIGSTOP/SIGCONT messages for child processes through this
> > descriptor, we could add a flag for that.
> 
> The flag is fine, but, once we have set that flag saying we want those
> messages, how do we know which type of structure we've gotten?  That's
> the piece of the puzzle I'm missing, sorry if I'm being overly slow.

If you pass a flag saying you can handle a new set of potential
structures, those structures can then include any necessary
disambiguating flags/IDs/etc.  No need for them to match the current
clonefd_info structure if userspace has opted into a new version.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm: show free pages per each migrate type

2015-04-08 Thread Neil Zhang

show detailed free pages per each migrate type in show_free_areas.

After apply this patch, the log printed out will be changed from

[   558.212844@0] Normal: 218*4kB (UEMC) 207*8kB (UEMC) 126*16kB (UEMC) 21*32kB 
(UC) 5*64kB (C) 3*128kB (C) 1*256kB (C) 1*512kB (C) 0*1024kB 0*2048kB 1*4096kB 
(R) = 10784kB
[   558.227840@0] HighMem: 3*4kB (UMR) 3*8kB (UMR) 2*16kB (UM) 3*32kB (UMR) 
0*64kB 1*128kB (M) 1*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 548kB

to

[   806.506450@1] Normal: 8969*4kB 4370*8kB 2*16kB 3*32kB 2*64kB 3*128kB 
3*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 74804kB
[   806.517456@1]   orders:  0  1  2  3  4  5  
6  7  8  9 10
[   806.527077@1]Unmovable:   8287   4370  0  0  0  0  
0  0  0  0  0
[   806.536699@1]  Reclaimable:681  0  0  0  0  0  
0  0  0  0  0
[   806.546321@1]  Movable:  1  0  0  0  0  0  
0  0  0  0  0
[   806.555942@1]  Reserve:  0  0  2  3  2  3  
3  1  0  1  0
[   806.565564@1]  CMA:  0  0  0  0  0  0  
0  0  0  0  0
[   806.575187@1]  Isolate:  0  0  0  0  0  0  
0  0  0  0  0
[   806.584810@1] HighMem: 80*4kB 15*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 
0*512kB 0*1024kB 0*2048kB 0*4096kB = 440kB
[   806.595383@1]   orders:  0  1  2  3  4  5  
6  7  8  9 10
[   806.605004@1]Unmovable: 12  0  0  0  0  0  
0  0  0  0  0
[   806.614626@1]  Reclaimable:  0  0  0  0  0  0  
0  0  0  0  0
[   806.624248@1]  Movable: 11 15  0  0  0  0  
0  0  0  0  0
[   806.633869@1]  Reserve: 57  0  0  0  0  0  
0  0  0  0  0
[   806.643491@1]  CMA:  0  0  0  0  0  0  
0  0  0  0  0
[   806.653113@1]  Isolate:  0  0  0  0  0  0  
0  0  0  0  0

Signed-off-by: Neil Zhang 
---
 mm/internal.h   |2 ++
 mm/page_alloc.c |   55 ++-
 mm/vmstat.c |   13 -
 3 files changed, 28 insertions(+), 42 deletions(-)

diff --git a/mm/internal.h b/mm/internal.h
index a96da5b..5cb3079 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -14,6 +14,8 @@
 #include 
 #include 
 
+extern char * const migratetype_names[MIGRATE_TYPES];
+
 void free_pgtables(struct mmu_gather *tlb, struct vm_area_struct *start_vma,
unsigned long floor, unsigned long ceiling);
 
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 40e2942..2d70892 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3170,32 +3170,18 @@ out:
 
 #define K(x) ((x) << (PAGE_SHIFT-10))
 
-static void show_migration_types(unsigned char type)
-{
-   static const char types[MIGRATE_TYPES] = {
-   [MIGRATE_UNMOVABLE] = 'U',
-   [MIGRATE_RECLAIMABLE]   = 'E',
-   [MIGRATE_MOVABLE]   = 'M',
-   [MIGRATE_RESERVE]   = 'R',
+char * const migratetype_names[MIGRATE_TYPES] = {
+   "Unmovable",
+   "Reclaimable",
+   "Movable",
+   "Reserve",
 #ifdef CONFIG_CMA
-   [MIGRATE_CMA]   = 'C',
+   "CMA",
 #endif
 #ifdef CONFIG_MEMORY_ISOLATION
-   [MIGRATE_ISOLATE]   = 'I',
+   "Isolate",
 #endif
-   };
-   char tmp[MIGRATE_TYPES + 1];
-   char *p = tmp;
-   int i;
-
-   for (i = 0; i < MIGRATE_TYPES; i++) {
-   if (type & (1 << i))
-   *p++ = types[i];
-   }
-
-   *p = '\0';
-   printk("(%s) ", tmp);
-}
+};
 
 /*
  * Show free area list (used inside shift_scroll-lock stuff)
@@ -3327,7 +3313,7 @@ void show_free_areas(unsigned int filter)
 
for_each_populated_zone(zone) {
unsigned long nr[MAX_ORDER], flags, order, total = 0;
-   unsigned char types[MAX_ORDER];
+   unsigned long nr_free[MAX_ORDER][MIGRATE_TYPES], mtype;
 
if (skip_free_areas_node(filter, zone_to_nid(zone)))
continue;
@@ -3337,24 +3323,35 @@ void show_free_areas(unsigned int filter)
spin_lock_irqsave(>lock, flags);
for (order = 0; order < MAX_ORDER; order++) {
struct free_area *area = >free_area[order];
+   struct list_head *curr;
int type;
 
nr[order] = area->nr_free;
total += nr[order] << order;
 
-   types[order] = 0;
for (type = 0; type < MIGRATE_TYPES; type++) {
+

Re: [PATCH v3 2/4] extcon: usb-gpio: add support for VBUS detection

2015-04-08 Thread Chanwoo Choi

Hi Robert,

On 04/02/2015 10:13 PM, Robert Baldyga wrote:
> This patch adds VBUS pin detection support to extcon-usb-gpio driver.
> It allows to use this driver with boards which have both VBUS and ID
> pins, or only one of them.
> 
> Following table of states presents relationship between this signals
> and detected cable type:
> 
>  State  |ID   |   VBUS
> 
>  [1] USB|H|H
>  [2] none   |H|L
>  [3] USB & USB-HOST |L|H
>  [4] USB-HOST   |L|L
> 
> In case we have only one of these signals:
> - VBUS only - we want to distinguish between [1] and [2], so ID is always 1.
> - ID only - we want to distinguish between [1] and [4], so VBUS = ID.
> 
> Signed-off-by: Robert Baldyga 
> ---
>  drivers/extcon/extcon-usb-gpio.c | 169 
> +++
>  1 file changed, 119 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/extcon/extcon-usb-gpio.c 
> b/drivers/extcon/extcon-usb-gpio.c
> index f6aa99d..baf7add 100644
> --- a/drivers/extcon/extcon-usb-gpio.c
> +++ b/drivers/extcon/extcon-usb-gpio.c
> @@ -32,7 +32,9 @@ struct usb_extcon_info {
>   struct extcon_dev *edev;
>  
>   struct gpio_desc *id_gpiod;
> + struct gpio_desc *vbus_gpiod;
>   int id_irq;
> + int vbus_irq;
>  
>   unsigned long debounce_jiffies;
>   struct delayed_work wq_detcable;
> @@ -52,40 +54,51 @@ static const char *usb_extcon_cable[] = {
>   NULL,
>  };
>  
> +/*
> + * "USB" = VBUS and "USB-HOST" = !ID, so we have:
> + *
> + *  State  |ID   |   VBUS
> + * 
> + *  [1] USB|H|H
> + *  [2] none   |H|L
> + *  [3] USB & USB-HOST |L|H
> + *  [4] USB-HOST   |L|L
> + *
> + * In case we have only one of these signals:
> + * - VBUS only - we want to distinguish between [1] and [2], so ID is always 
> 1.
> + * - ID only - we want to distinguish between [1] and [4], so VBUS = ID.
> + */
> +
>  static void usb_extcon_detect_cable(struct work_struct *work)
>  {
>   int id;
> + int vbus;
>   struct usb_extcon_info *info = container_of(to_delayed_work(work),
>   struct usb_extcon_info,
>   wq_detcable);
>  
> - /* check ID and update cable state */
> - id = gpiod_get_value_cansleep(info->id_gpiod);
> - if (id) {
> - /*
> -  * ID = 1 means USB HOST cable detached.
> -  * As we don't have event for USB peripheral cable attached,
> -  * we simulate USB peripheral attach here.
> -  */
> + /* check ID and VBUS and update cable state */
> +
> + id = info->id_gpiod ?
> + gpiod_get_value_cansleep(info->id_gpiod) : 1;
> +
> + vbus = info->vbus_gpiod ?
> + gpiod_get_value_cansleep(info->vbus_gpiod) : id;
> +
> + /* at first we clean states which are no longer active */
> + if (id)
>   extcon_set_cable_state(info->edev,
> -usb_extcon_cable[EXTCON_CABLE_USB_HOST],
> -false);
> + usb_extcon_cable[EXTCON_CABLE_USB_HOST], false);
> + if (!vbus)
>   extcon_set_cable_state(info->edev,
> -usb_extcon_cable[EXTCON_CABLE_USB],
> -true);
> - } else {
> - /*
> -  * ID = 0 means USB HOST cable attached.
> -  * As we don't have event for USB peripheral cable detached,
> -  * we simulate USB peripheral detach here.
> -  */
> + usb_extcon_cable[EXTCON_CABLE_USB], false);
> +
> + if (!id)
>   extcon_set_cable_state(info->edev,
> -usb_extcon_cable[EXTCON_CABLE_USB],
> -false);
> + usb_extcon_cable[EXTCON_CABLE_USB_HOST], true);
> + if (vbus)
>   extcon_set_cable_state(info->edev,
> -usb_extcon_cable[EXTCON_CABLE_USB_HOST],
> -true);
> - }
> + usb_extcon_cable[EXTCON_CABLE_USB], true);
>  }

Looks good to me of this patch.

But, I have one question about case[3]

If id is low and vbus is high, this patch will update the state of both USB and 
USB-HOST cable as attached state.
Is it possible that two different cables (both USB and USB-HOST) are connected 
to one port simultaneously?


> + * "USB" = VBUS and "USB-HOST" = !ID, so we have:
> + *
> + *  State  |ID   |   VBUS
> + * 
> + *  [1] USB|H|H
> + *  [2] none   |H|L
> + *  [3] USB & USB-HOST |L|H
> + *

Re: console=ttyS1 breaks ttyS1 termios and prevents me from logging in

2015-04-08 Thread Peter Hurley

On 04/08/2015 09:49 PM, Andy Lutomirski wrote:
> On Wed, Apr 8, 2015 at 5:45 PM, Andy Lutomirski  wrote:
>> On Wed, Apr 8, 2015 at 4:32 PM, Peter Hurley  
>> wrote:
>>> On 04/08/2015 05:40 PM, Andy Lutomirski wrote:
 On Wed, Apr 8, 2015 at 2:29 PM, Peter Hurley  
 wrote:
> Hi Andy,
>
> On 04/08/2015 05:17 PM, Andy Lutomirski wrote:
>> Something strange seems to have happened to my serial console setup.
>> I boot with console=ttyS1,115200n8 and I have a getty running on
>> /dev/ttyS1.
>>
>> On older kernels, or if I remove the console= boot parameter, then my
>> getty works fine.  On 3.19.3 with the console= parameter, something's
>> wrong with termios and I can't log in.  Running:
>
> Thanks for the report.
> 1. Please attach your dmesg.
> 2. Is this behavior new to 3.19.3? (iow, what was the last version
>that you noticed didn't do this)

 I didn't have the problem before I reinstalled this box, upgraded from
 3.15 to 3.19.3, and updated by Dell iDRAC7 firmware.  Booting into
 3.13-something does *not* fix the problem, so I'm not at all convinced
 that the kernel version matters much.  I'll try reverting the iDRAC7
 thing, but I don't see why that would make any difference at all to
 Linux.
>>>
>>> I think this is related to DRAC; maybe upgrading the firmware reset
>>> the Serial communication settings in the system bios?
>>>
>>
>> The DRAC pretends to be a 16550, so I don't understand how it could
>> prevent Linux from reprogramming the line discipline.  Also, if I
>> remove console=ttyS1,115200 from the kernel command line, it starts
>> working again.

I didn't realize from your initial report that input with getty was
working, otherwise I wouldn't have asked for the line settings.


>>> 1. What's your getty command line?
>>
>> /sbin/getty -8 115200 ttyS1
>>
>>
>>> 2. Contents of /proc/tty/driver/serial when you think getty is running
>>>and waiting for login (shows line signals).
>>
>> With getty running:
>>
>> serinfo:1.0 driver revision:
>> 0: uart:16550A port:03F8 irq:4 tx:0 rx:0
>> 1: uart:16550A port:02F8 irq:3 tx:19828 rx:2 RTS|CTS|DTR
>> 2: uart:unknown port:03E8 irq:4
>> 3: uart:unknown port:02E8 irq:3
>> 4: uart:unknown port: irq:0
>>
>> (getty itself works fine)
>>
>> When I type a username, I get:
>>
>> serinfo:1.0 driver revision:
>> 0: uart:16550A port:03F8 irq:4 tx:0 rx:0
>> 1: uart:16550A port:02F8 irq:3 tx:19848 rx:10 RTS|CTS|DTR
>> 2: uart:unknown port:03E8 irq:4
>> 3: uart:unknown port:02E8 irq:3
>> 4: uart:unknown port: irq:0
>>
>> at that point, login is running, and it's login that doesn't work.
>>
>>>
>>> Something to test is if you set getty to local line, does it work then.
>>> I use agetty so my command line is:
>>> /sbin/getty --noreset -8L 115200 ttyS0 vt102
>>
>> I tried:
>>
>> # /sbin/getty --noreset -8L 115200 ttyS1 vt102
>>
>> it has exactly the same problem.
>>
>> By adding a whole bunch of printks, I see that both ttyS0 and ttyS1
>> make it into uart_set_termios.  But now it's time to home...
> 
> OMFG I hate [insert long string of expletives] userspace bugs.
> 
> Some piece of crap user code regressed in some recent Ubuntu update
> and left all the termios lock flags set on the console device,
> presumably read from /proc/console.

Either /dev/console or it found the console from
/sys/devices/virtual/tty/console/active.

I suspected the termios locking because that's really the only way
termios settings don't get set, but I couldn't imagine why login
would be flagging those. I hadn't considered that something would
leave them on for later processes.

> So... false alarm, except that the kernel should maybe considering
> disallowing such daft behavior or at least warning.  Now I get to
> figure out *which* userspace program regressed.  I'm reasonably sure
> it's either Plymouth or some horrendously buggy Debian/Ubuntu script
> that controls it.

Some weekend I'm going to package a NoPlymouth.
 
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ALSA: hda - make power_save threshold per-codec

2015-04-08 Thread Matthew Garrett

Modern hardware will often have multiple HDA devices, and the desired
power saving configuration may vary depending on the codecs attached to
each of them. Push the power_save value down to the individual codec
structures, keeping the module parameter as a global control mechanism
for compatibility purposes.

Signed-off-by: Matthew Garrett 
---
 Documentation/sound/alsa/HD-Audio.txt |  5 +++--
 sound/pci/hda/hda_codec.c | 28 
 sound/pci/hda/hda_codec.h | 19 ---
 sound/pci/hda/hda_controller.c|  6 +++---
 sound/pci/hda/hda_controller.h|  2 +-
 sound/pci/hda/hda_intel.c |  7 +++
 sound/pci/hda/hda_sysfs.c | 30 ++
 sound/pci/hda/hda_tegra.c |  4 ++--
 8 files changed, 66 insertions(+), 35 deletions(-)

diff --git a/Documentation/sound/alsa/HD-Audio.txt 
b/Documentation/sound/alsa/HD-Audio.txt
index 42a0a39..99f2fb8 100644
--- a/Documentation/sound/alsa/HD-Audio.txt
+++ b/Documentation/sound/alsa/HD-Audio.txt
@@ -569,8 +569,9 @@ Power-Saving
 The power-saving is a kind of auto-suspend of the device.  When the
 device is inactive for a certain time, the device is automatically
 turned off to save the power.  The time to go down is specified via
-`power_save` module option, and this option can be changed dynamically
-via sysfs.
+`power_save` module option. This option can be changed dynamically
+via sysfs, either globally (via /sys/module/snd_hda_*/parameters/power_save)
+or per-codec (via the power_save sysfs parameter in the codec directory)
 
 The power-saving won't work when the analog loopback is enabled on
 some codecs.  Make sure that you mute all unneeded signal routes when
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 2fe86d2..5e8394a 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -895,7 +895,6 @@ int snd_hda_bus_new(struct snd_card *card,
bus->private_data = temp->private_data;
bus->pci = temp->pci;
bus->modelname = temp->modelname;
-   bus->power_save = temp->power_save;
bus->ops = temp->ops;
 
mutex_init(>cmd_mutex);
@@ -1436,8 +1435,9 @@ static void snd_hda_codec_dev_release(struct device *dev)
  * Returns 0 if successful, or a negative error code.
  */
 int snd_hda_codec_new(struct hda_bus *bus,
-   unsigned int codec_addr,
-   struct hda_codec **codecp)
+ unsigned int codec_addr,
+ struct hda_codec **codecp,
+ int power_save)
 {
struct hda_codec *codec;
char component[31];
@@ -1495,6 +1495,7 @@ int snd_hda_codec_new(struct hda_bus *bus,
 
INIT_DELAYED_WORK(>jackpoll_work, hda_jackpoll_work);
codec->depop_delay = -1;
+   codec->power_save = power_save;
codec->fixup_id = HDA_FIXUP_ID_NOT_SET;
 
 #ifdef CONFIG_PM
@@ -5112,23 +5113,34 @@ static void __snd_hda_power_up(struct hda_codec *codec, 
bool wait_power_down)
codec->power_transition = 0;
 }
 
-#define power_save(codec)  \
-   ((codec)->bus->power_save ? *(codec)->bus->power_save : 0)
-
 /* Transition to powered down */
 static void __snd_hda_power_down(struct hda_codec *codec)
 {
if (!codec->power_on || codec->power_count || codec->power_transition)
return;
 
-   if (power_save(codec)) {
+   if (codec->power_save >= 0) {
codec->power_transition = -1; /* avoid reentrance */
queue_delayed_work(codec->bus->workq, >power_work,
-   msecs_to_jiffies(power_save(codec) * 1000));
+  msecs_to_jiffies(codec->power_save * 1000));
}
 }
 
 /**
+ *
+ * snd_hda_power_save_set - set the power-down time for the codec
+ *
+ * @codec: HD-audio codec
+ * @value: seconds to wait before powering down the codec
+ */
+void snd_hda_power_save_set(struct hda_codec *codec, int value)
+{
+   codec->power_save = value;
+   snd_hda_power_save(codec, 0, false);
+}
+EXPORT_SYMBOL_GPL(snd_hda_power_save_set);
+
+/**
  * snd_hda_power_save - Power-up/down/sync the codec
  * @codec: HD-audio codec
  * @delta: the counter delta to change
diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h
index 9c8820f..faaab58 100644
--- a/sound/pci/hda/hda_codec.h
+++ b/sound/pci/hda/hda_codec.h
@@ -106,7 +106,6 @@ struct hda_bus_template {
void *private_data;
struct pci_dev *pci;
const char *modelname;
-   int *power_save;
struct hda_bus_ops ops;
 };
 
@@ -123,7 +122,6 @@ struct hda_bus {
void *private_data;
struct pci_dev *pci;
const char *modelname;
-   int *power_save;
struct hda_bus_ops ops;
 
/* codec linked list */
@@ -398,6 +396,7 @@ struct hda_codec {
struct snd_array jacks;
 #endif
 
+   int power_save;
int

Re: console=ttyS1 breaks ttyS1 termios and prevents me from logging in

2015-04-08 Thread Andy Lutomirski

On Wed, Apr 8, 2015 at 5:45 PM, Andy Lutomirski  wrote:
> On Wed, Apr 8, 2015 at 4:32 PM, Peter Hurley  wrote:
>> On 04/08/2015 05:40 PM, Andy Lutomirski wrote:
>>> On Wed, Apr 8, 2015 at 2:29 PM, Peter Hurley  
>>> wrote:
 Hi Andy,

 On 04/08/2015 05:17 PM, Andy Lutomirski wrote:
> Something strange seems to have happened to my serial console setup.
> I boot with console=ttyS1,115200n8 and I have a getty running on
> /dev/ttyS1.
>
> On older kernels, or if I remove the console= boot parameter, then my
> getty works fine.  On 3.19.3 with the console= parameter, something's
> wrong with termios and I can't log in.  Running:

 Thanks for the report.
 1. Please attach your dmesg.
 2. Is this behavior new to 3.19.3? (iow, what was the last version
that you noticed didn't do this)
>>>
>>> I didn't have the problem before I reinstalled this box, upgraded from
>>> 3.15 to 3.19.3, and updated by Dell iDRAC7 firmware.  Booting into
>>> 3.13-something does *not* fix the problem, so I'm not at all convinced
>>> that the kernel version matters much.  I'll try reverting the iDRAC7
>>> thing, but I don't see why that would make any difference at all to
>>> Linux.
>>
>> I think this is related to DRAC; maybe upgrading the firmware reset
>> the Serial communication settings in the system bios?
>>
>
> The DRAC pretends to be a 16550, so I don't understand how it could
> prevent Linux from reprogramming the line discipline.  Also, if I
> remove console=ttyS1,115200 from the kernel command line, it starts
> working again.
>
>> 1. What's your getty command line?
>
> /sbin/getty -8 115200 ttyS1
>
>
>> 2. Contents of /proc/tty/driver/serial when you think getty is running
>>and waiting for login (shows line signals).
>
> With getty running:
>
> serinfo:1.0 driver revision:
> 0: uart:16550A port:03F8 irq:4 tx:0 rx:0
> 1: uart:16550A port:02F8 irq:3 tx:19828 rx:2 RTS|CTS|DTR
> 2: uart:unknown port:03E8 irq:4
> 3: uart:unknown port:02E8 irq:3
> 4: uart:unknown port: irq:0
>
> (getty itself works fine)
>
> When I type a username, I get:
>
> serinfo:1.0 driver revision:
> 0: uart:16550A port:03F8 irq:4 tx:0 rx:0
> 1: uart:16550A port:02F8 irq:3 tx:19848 rx:10 RTS|CTS|DTR
> 2: uart:unknown port:03E8 irq:4
> 3: uart:unknown port:02E8 irq:3
> 4: uart:unknown port: irq:0
>
> at that point, login is running, and it's login that doesn't work.
>
>>
>> Something to test is if you set getty to local line, does it work then.
>> I use agetty so my command line is:
>> /sbin/getty --noreset -8L 115200 ttyS0 vt102
>
> I tried:
>
> # /sbin/getty --noreset -8L 115200 ttyS1 vt102
>
> it has exactly the same problem.
>
> By adding a whole bunch of printks, I see that both ttyS0 and ttyS1
> make it into uart_set_termios.  But now it's time to home...

OMFG I hate [insert long string of expletives] userspace bugs.

Some piece of crap user code regressed in some recent Ubuntu update
and left all the termios lock flags set on the console device,
presumably read from /proc/console.

So... false alarm, except that the kernel should maybe considering
disallowing such daft behavior or at least warning.  Now I get to
figure out *which* userspace program regressed.  I'm reasonably sure
it's either Plymouth or some horrendously buggy Debian/Ubuntu script
that controls it.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drm/nouveau/bios: 0 means success for nvbios_extend

2015-04-08 Thread Jan Vesely

Bugzilla:https://bugs.freedesktop.org/show_bug.cgi?id=89047

CC: David Airlie 
CC: Ben Skeggs 
CC: dri-de...@lists.freedesktop.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Jan Vesely 
---

It's needed for 3.19 too

 drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c | 2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowacpi.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
index 8c2b7cb..f566ac8 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
@@ -44,7 +44,7 @@ shadow_fetch(struct nvkm_bios *bios, u32 upto)
const u32 limit = (upto + 3) & ~3;
const u32 start = bios->size;
void *data = mthd->data;
-   if (nvbios_extend(bios, limit) > 0) {
+   if (nvbios_extend(bios, limit) >= 0) {
u32 read = mthd->func->read(data, start, limit - start, bios);
bios->size = start + read;
}
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowacpi.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowacpi.c
index 1fbd93b..f9d0eb5 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowacpi.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowacpi.c
@@ -52,7 +52,7 @@ acpi_read_fast(void *data, u32 offset, u32 length, struct 
nvkm_bios *bios)
u32 start = offset & ~0x0fff;
u32 fetch = limit - start;
 
-   if (nvbios_extend(bios, limit) > 0) {
+   if (nvbios_extend(bios, limit) >= 0) {
int ret = nouveau_acpi_get_bios_chunk(bios->data, start, fetch);
if (ret == fetch)
return fetch;
@@ -73,7 +73,7 @@ acpi_read_slow(void *data, u32 offset, u32 length, struct 
nvkm_bios *bios)
u32 start = offset & ~0xfff;
u32 fetch = 0;
 
-   if (nvbios_extend(bios, limit) > 0) {
+   if (nvbios_extend(bios, limit) >= 0) {
while (start + fetch < limit) {
int ret = nouveau_acpi_get_bios_chunk(bios->data,
  start + fetch,
-- 
2.0.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/

Donations

2015-04-08 Thread shatabdi



A personal Donation of 2,000,000.00 USD has been Donated To You, Contact
(quezadapedr...@gmail.com) for more info

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

RE: [PATCH] mm: show free pages per each migrate type

2015-04-08 Thread ZhangNeil

OK, I will prepare version 2 to include the difference.

Best Regards,
Neil Zhang


> Date: Wed, 8 Apr 2015 15:20:11 -0700
> From: a...@linux-foundation.org
> To: neilzhang1...@hotmail.com
> CC: linux...@kvack.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] mm: show free pages per each migrate type
>
> On Wed, 8 Apr 2015 09:48:06 +0800 Neil Zhang  
> wrote:
>
>> show detailed free pages per each migrate type in show_free_areas.
>>
>
> It would be good to include example before and after output within the
> changelog, so that people can better understand the effect and value of
> the proposed change.
>
> Thanks.

Re: [tip:sched/core] sched/rt: Reduce rq lock contention by eliminating locking of non-feasible target

2015-04-08 Thread Zefan Li

>> Commit-ID:  80e3d87b2c5582db0ab5e39610ce3707d97ba409
>> Gitweb: 
>> http://git.kernel.org/tip/80e3d87b2c5582db0ab5e39610ce3707d97ba409
>> Author: Tim Chen 
>> AuthorDate: Fri, 12 Dec 2014 15:38:12 -0800
>> Committer:  Ingo Molnar 
>> CommitDate: Fri, 30 Jan 2015 19:38:49 +0100
>>
>> sched/rt: Reduce rq lock contention by eliminating locking of non-feasible 
>> target
>>
>> This patch adds checks that prevens futile attempts to move rt tasks
>> to a CPU with active tasks of equal or higher priority.
>>
>> This reduces run queue lock contention and improves the performance of
>> a well known OLTP benchmark by 0.7%.
>>
>> Signed-off-by: Tim Chen 
>> Signed-off-by: Peter Zijlstra (Intel) 
>> Cc: Shawn Bohrer 
>> Cc: Suruchi Kadu 
>> Cc: Doug Nelson
>> Cc: Steven Rostedt 
>> Cc: Linus Torvalds 
>> Link: 
>> http://lkml.kernel.org/r/1421430374.2399.27.ca...@schen9-desk2.jf.intel.com
>> Signed-off-by: Ingo Molnar 
> 
> I see this has been added to mainline already. I think this should go
> to stable as well. As far back as it applies. I'll even add this to the
> stable-rt if need be. But I rather pull it into stable-rt via the
> stable branches.
> 

Queued up for 3.4. Thanks!

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

Re: [3.4 PATCH] Bluetooth: Fix invalid length check in l2cap_information_rsp()

2015-04-08 Thread Zefan Li

On 2015/3/30 17:27, Tim Niemeyer wrote:
> first backport commit 6ec88fcb4aa2c33fe2fe2a23c576a7e2581c5c3d changes
> l2cap_move_channel_confirm_rsp and not the l2cap_information_rsp. So
> revert this and fix at the correct position.
> 
> commit 3f6fa3d489e127ca5a5b298eabac3ff5dbe0e112 upstream.
> 
> The length check is invalid since the length varies with type of
> info response.
> 
> This was introduced by the commit cb3b3152b2f5939d67005cff841a1ca748b19888
> 
> Because of this, l2cap info rsp is not handled and command reject is sent.
> 
>> ACL data: handle 11 flags 0x02 dlen 16
> L2CAP(s): Info rsp: type 2 result 0
>   Extended feature mask 0x00b8
> Enhanced Retransmission mode
> Streaming mode
> FCS Option
> Fixed Channels
> < ACL data: handle 11 flags 0x00 dlen 10
> L2CAP(s): Command rej: reason 0
>   Command not understood
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jaganath Kanakkassery 
> Signed-off-by: Chan-Yeol Park 
> Signed-off-by: Gustavo Padovan 
> Cc: Jianguo Wu 
> Signed-off-by: Greg Kroah-Hartman 
> Signed-off-by: Tim Niemeyer 
> Acked-by: Johan Hedberg 
> ---
> Patch for 3.4-stable.
> 

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

[PATCH 1/3] time: include math64.h in time64.h

From: Xunlei Pang 

On 32-bit systems, timespec64_add_ns() calls __iter_div_u64_rem()
which needs match64.h, and we want to include time64.h in some
cases.

Signed-off-by: Xunlei Pang 
---
 include/linux/time64.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/time64.h b/include/linux/time64.h
index a383147..12d4e82 100644
--- a/include/linux/time64.h
+++ b/include/linux/time64.h
@@ -2,6 +2,7 @@
 #define _LINUX_TIME64_H
 
 #include 
+#include 
 
 typedef __s64 time64_t;
 
-- 
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 2/3] s390: time: Provide read_boot_clock64() and read_persistent_clock64()

From: Xunlei Pang 

As part of addressing "y2038 problem" for in-kernel uses, this
patch converts read_boot_clock() to read_boot_clock64() and
read_persistent_clock() to read_persistent_clock64() using
timespec64.

Rename some timespec to timespec64 in time.c and related references.

Signed-off-by: Xunlei Pang 
---
We've already had read_boot_clock64() in timekeeping,
now provide read_boot_clock64() for S390.

 arch/s390/include/asm/timex.h |  5 +++--
 arch/s390/kernel/debug.c  | 11 ++-
 arch/s390/kernel/time.c   |  6 +++---
 3 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/arch/s390/include/asm/timex.h b/arch/s390/include/asm/timex.h
index 98eb2a5..f39220f 100644
--- a/arch/s390/include/asm/timex.h
+++ b/arch/s390/include/asm/timex.h
@@ -10,6 +10,7 @@
 #define _ASM_S390_TIMEX_H
 
 #include 
+#include 
 
 /* The value of the TOD clock for 1.1.1970. */
 #define TOD_UNIX_EPOCH 0x7d91048bca00ULL
@@ -108,10 +109,10 @@ int get_sync_clock(unsigned long long *clock);
 void init_cpu_timer(void);
 unsigned long long monotonic_clock(void);
 
-void tod_to_timeval(__u64, struct timespec *);
+void tod_to_timeval(__u64, struct timespec64 *);
 
 static inline
-void stck_to_timespec(unsigned long long stck, struct timespec *ts)
+void stck_to_timespec64(unsigned long long stck, struct timespec64 *ts)
 {
tod_to_timeval(stck - TOD_UNIX_EPOCH, ts);
 }
diff --git a/arch/s390/kernel/debug.c b/arch/s390/kernel/debug.c
index c1f21ac..4f2d11d 100644
--- a/arch/s390/kernel/debug.c
+++ b/arch/s390/kernel/debug.c
@@ -1457,23 +1457,24 @@ int
 debug_dflt_header_fn(debug_info_t * id, struct debug_view *view,
 int area, debug_entry_t * entry, char *out_buf)
 {
-   struct timespec time_spec;
+   struct timespec64 time_spec;
char *except_str;
unsigned long caller;
int rc = 0;
unsigned int level;
 
level = entry->id.fields.level;
-   stck_to_timespec(entry->id.stck, _spec);
+   stck_to_timespec64(entry->id.stck, _spec);
 
if (entry->id.fields.exception)
except_str = "*";
else
except_str = "-";
caller = ((unsigned long) entry->caller) & PSW_ADDR_INSN;
-   rc += sprintf(out_buf, "%02i %011lu:%06lu %1u %1s %02i %p  ",
- area, time_spec.tv_sec, time_spec.tv_nsec / 1000, level,
- except_str, entry->id.fields.cpuid, (void *) caller);
+   rc += sprintf(out_buf, "%02i %011lld:%06lu %1u %1s %02i %p  ",
+ area, (long long) time_spec.tv_sec,
+ time_spec.tv_nsec / 1000, level, except_str,
+ entry->id.fields.cpuid, (void *) caller);
return rc;
 }
 EXPORT_SYMBOL(debug_dflt_header_fn);
diff --git a/arch/s390/kernel/time.c b/arch/s390/kernel/time.c
index 170ddd2..9e733d9 100644
--- a/arch/s390/kernel/time.c
+++ b/arch/s390/kernel/time.c
@@ -76,7 +76,7 @@ unsigned long long monotonic_clock(void)
 }
 EXPORT_SYMBOL(monotonic_clock);
 
-void tod_to_timeval(__u64 todval, struct timespec *xt)
+void tod_to_timeval(__u64 todval, struct timespec64 *xt)
 {
unsigned long long sec;
 
@@ -181,12 +181,12 @@ static void timing_alert_interrupt(struct ext_code 
ext_code,
 static void etr_reset(void);
 static void stp_reset(void);
 
-void read_persistent_clock(struct timespec *ts)
+void read_persistent_clock64(struct timespec64 *ts)
 {
tod_to_timeval(get_tod_clock() - TOD_UNIX_EPOCH, ts);
 }
 
-void read_boot_clock(struct timespec *ts)
+void read_boot_clock64(struct timespec64 *ts)
 {
tod_to_timeval(sched_clock_base_cc - TOD_UNIX_EPOCH, ts);
 }
-- 
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 3/3] time: Remove read_boot_clock()

From: Xunlei Pang 

Now we have all the read_boot_clock64() for all implementations,
it's time to remove read_boot_clock() completely from the kernel.

Signed-off-by: Xunlei Pang 
---
 include/linux/timekeeping.h |  1 -
 kernel/time/timekeeping.c   | 14 +++---
 2 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index 99176af..88e5f2e 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -266,7 +266,6 @@ extern int persistent_clock_is_local;
 
 extern void read_persistent_clock(struct timespec *ts);
 extern void read_persistent_clock64(struct timespec64 *ts);
-extern void read_boot_clock(struct timespec *ts);
 extern void read_boot_clock64(struct timespec64 *ts);
 extern int update_persistent_clock(struct timespec now);
 extern int update_persistent_clock64(struct timespec64 now);
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 946acb7..87f0ea5 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1179,28 +1179,20 @@ void __weak read_persistent_clock64(struct timespec64 
*ts64)
 }
 
 /**
- * read_boot_clock -  Return time of the system start.
+ * read_boot_clock64 -  Return time of the system start.
  *
  * Weak dummy function for arches that do not yet support it.
  * Function to read the exact time the system has been started.
- * Returns a timespec with tv_sec=0 and tv_nsec=0 if unsupported.
+ * Returns a timespec64 with tv_sec=0 and tv_nsec=0 if unsupported.
  *
  *  XXX - Do be sure to remove it once all arches implement it.
  */
-void __weak read_boot_clock(struct timespec *ts)
+void __weak read_boot_clock64(struct timespec64 *ts)
 {
ts->tv_sec = 0;
ts->tv_nsec = 0;
 }
 
-void __weak read_boot_clock64(struct timespec64 *ts64)
-{
-   struct timespec ts;
-
-   read_boot_clock();
-   *ts64 = timespec_to_timespec64(ts);
-}
-
 /* Flag for if timekeeping_resume() has injected sleeptime */
 static bool sleeptime_injected;
 
-- 
1.9.1


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

Re: [PATCH v1 7/7] s390/block/dasd: remove obsolete while -EBUSY loop

2015-04-08 Thread Ming Lei

On Thu, Apr 9, 2015 at 2:00 AM, Jarod Wilson  wrote:
> On Wed, Apr 08, 2015 at 07:32:24PM +0200, Sebastian Ott wrote:
>> On Wed, 8 Apr 2015, Ming Lei wrote:
>> > From: Jarod Wilson 
>> >
>> > With the mutex_trylock bit gone from blkdev_reread_part(), the retry logic
>> > in dasd_scan_partitions() shouldn't be necessary.
>> >
>> > CC: Christoph Hellwig 
>> > CC: Jens Axboe 
>> > CC: Tejun Heo 
>> > CC: Alexander Viro 
>> > CC: Markus Pargmann 
>> > CC: Stefan Weinhuber 
>> > CC: Stefan Haberland 
>> > CC: Sebastian Ott 
>> > CC: Fabian Frederick 
>> > CC: Ming Lei 
>> > CC: David Herrmann 
>> > CC: Andrew Morton 
>> > CC: Peter Zijlstra 
>> > CC: nbd-gene...@lists.sourceforge.net
>> > CC: linux-s...@vger.kernel.org
>> > Signed-off-by: Jarod Wilson 
>> > ---
>> >  drivers/s390/block/dasd_genhd.c |   13 +++--
>> >  1 file changed, 3 insertions(+), 10 deletions(-)
>> >
>> > diff --git a/drivers/s390/block/dasd_genhd.c 
>> > b/drivers/s390/block/dasd_genhd.c
>> > index 2af4619..189ea2f 100644
>> > --- a/drivers/s390/block/dasd_genhd.c
>> > +++ b/drivers/s390/block/dasd_genhd.c
>> > @@ -99,9 +99,8 @@ void dasd_gendisk_free(struct dasd_block *block)
>> >  int dasd_scan_partitions(struct dasd_block *block)
>> >  {
>> > struct block_device *bdev;
>> > -   int retry, rc;
>> > +   int rc;
>> >
>> > -   retry = 5;
>> > bdev = bdget_disk(block->gdp, 0);
>> > if (!bdev) {
>> > DBF_DEV_EVENT(DBF_ERR, block->base, "%s",
>> > @@ -118,14 +117,8 @@ int dasd_scan_partitions(struct dasd_block *block)
>> > }
>> >
>> > rc = blkdev_reread_part(bdev);
>> > -   while (rc == -EBUSY && retry > 0) {
>> > -   schedule();
>> > -   rc = blkdev_reread_part(bdev);
>> > -   retry--;
>> > -   DBF_DEV_EVENT(DBF_ERR, block->base,
>> > - "scan partitions error, retry %d rc %d",
>> > - retry, rc);
>> > -   }
>> > +   DBF_DEV_EVENT(DBF_ERR, block->base,
>> > + "scan partitions error, rc %d", rc);
>>
>> Could you please change that to only write the debug message in the error
>> case. Other than that, both dasd patches look good.
>
> D'oh, absolutely. Ming, do you want me to send an updated patch 7 along in
> reply here, or do you want to handle it and/or repost the entire set?

I will handle that, and will add your guys' acked-by and tested-by too,
but need to take a while for looking if there are further comments.

Thanks,
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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][stable] Bluetooth: Add support for Acer [0489:e078]

2015-04-08 Thread Zefan Li

On 2015/3/4 2:59, Joseph Salisbury wrote:
> Hello,
> 
> Please consider including mainline commit
> 4b552bc9edfdc947862af225a0e2521edb5d37a0 in the next 3.2.y, 3.4.y,
> 3.10.y, 3.12.y, 3.13.y-ckt, 3.14.y, 3.16.y-ckt and 3.18.y upstream
> stable releases.  It was included in the mainline tree as of v3.19-rc1
> but not cc'd to stable.  It has been tested and confirmed to resolve:
> http://bugs.launchpad.net/bugs/1012284 .
> 
> commit 4b552bc9edfdc947862af225a0e2521edb5d37a0
> Author: Anantha Krishnan 
> Date:   Mon Oct 6 16:31:49 2014 +0530
> 
> Bluetooth: Add support for Acer [0489:e078]
> 

Queued up for 3.4.y. Thanks!

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

[Update][PATCH 3/4] ACPI / scan: Take the PRP0001 position in the list of IDs into account

From: Rafael J. Wysocki 

If the special PRP0001 device ID is present in a device's _CID list,
it should not prevent any ACPI/PNP IDs preceding it in the device's
list of identifiers from being matched first.  That is, only if none
of the IDs preceding PRP0001 in the device's PNP/ACPI IDs list
matches the IDs recognized by the driver, the driver's list of
"compatible" IDs should be matched against the device's "compatible"
property, if present.

In addition to that, drivers can provide both acpi_match_table and
of_match_table at the same time and the of_compatible matching
should be used in that case too if PRP0001 is present in the
device's list of identifiers.

To make that happen, rework acpi_driver_match_device() to do the
"compatible" property check in addition to matching the driver's
list of ACPI IDs against the device's one.

Signed-off-by: Rafael J. Wysocki 
---

The subject and changelog of the previous version didn't make sense.

Sorry about that.

---
 drivers/acpi/scan.c |  115 +---
 1 file changed, 65 insertions(+), 50 deletions(-)

Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -899,8 +899,51 @@ static void acpi_device_remove_files(str
ACPI Bus operations
-- 
*/
 
+/**
+ * acpi_of_match_device - Match device object using the "compatible" property.
+ * @adev: ACPI device object to match.
+ * @of_match_table: List of device IDs to match against.
+ *
+ * If @dev has an ACPI companion which has the special PRP0001 device ID in its
+ * list of identifiers and a _DSD object with the "compatible" property, use
+ * that property to match against the given list of identifiers.
+ */
+static bool acpi_of_match_device(struct acpi_device *adev,
+const struct of_device_id *of_match_table)
+{
+   const union acpi_object *of_compatible, *obj;
+   int i, nval;
+
+   if (!adev)
+   return false;
+
+   of_compatible = adev->data.of_compatible;
+   if (!of_match_table || !of_compatible)
+   return false;
+
+   if (of_compatible->type == ACPI_TYPE_PACKAGE) {
+   nval = of_compatible->package.count;
+   obj = of_compatible->package.elements;
+   } else { /* Must be ACPI_TYPE_STRING. */
+   nval = 1;
+   obj = of_compatible;
+   }
+   /* Now we can look for the driver DT compatible strings */
+   for (i = 0; i < nval; i++, obj++) {
+   const struct of_device_id *id;
+
+   for (id = of_match_table; id->compatible[0]; id++)
+   if (!strcasecmp(obj->string.pointer, id->compatible))
+   return true;
+   }
+
+   return false;
+}
+
 static const struct acpi_device_id *__acpi_match_device(
-   struct acpi_device *device, const struct acpi_device_id *ids)
+   struct acpi_device *device,
+   const struct acpi_device_id *ids,
+   const struct of_device_id *of_ids)
 {
const struct acpi_device_id *id;
struct acpi_hardware_id *hwid;
@@ -912,11 +955,24 @@ static const struct acpi_device_id *__ac
if (!device || !device->status.present)
return NULL;
 
-   for (id = ids; id->id[0]; id++)
-   list_for_each_entry(hwid, >pnp.ids, list)
+   list_for_each_entry(hwid, >pnp.ids, list) {
+   /* First, check the ACPI/PNP IDs provided by the caller. */
+   for (id = ids; id->id[0]; id++)
if (!strcmp((char *) id->id, hwid->id))
return id;
 
+   /*
+* Next, check the special "PRP0001" ID and try to match the
+* "compatible" property if found.
+*
+* The id returned by the below is not valid, but the only
+* caller passing non-NULL of_ids here is only interested in
+* whether or not the return value is NULL.
+*/
+   if (!strcmp("PRP0001", hwid->id)
+   && acpi_of_match_device(device, of_ids))
+   return id;
+   }
return NULL;
 }
 
@@ -934,67 +990,26 @@ static const struct acpi_device_id *__ac
 const struct acpi_device_id *acpi_match_device(const struct acpi_device_id 
*ids,
   const struct device *dev)
 {
-   return __acpi_match_device(acpi_companion_match(dev), ids);
+   return __acpi_match_device(acpi_companion_match(dev), ids, NULL);
 }
 EXPORT_SYMBOL_GPL(acpi_match_device);
 
 int acpi_match_device_ids(struct acpi_device *device,
  const struct acpi_device_id *ids)
 {
-   return __acpi_match_device(device, ids) ? 0 : -ENOENT;
+

Re: Linux 3.18.11

2015-04-08 Thread Sasha Levin

On 04/07/2015 01:56 AM, Guenter Roeck wrote:
> On Sun, Apr 05, 2015 at 10:31:52AM -0400, Sasha Levin wrote:
>> > I'm announcing the release of the 3.18.11 kernel.
>> > 
>> > All users of the 3.18 kernel series must upgrade.
>> > 
>> > The updated 3.18.y git tree can be found at:
>> >git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
>> > linux-3.18.y
>> > and can be browsed at the normal kernel.org git web browser:
>> >
>> > http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
>> > 
> Hi Sasha,
> 
> it would be great if you can Cc: me on the review announcements for 3.18.
> This way I would be informed when you are about to release a new version,
> and I could provide build and qemu test feedback.

Apologies for that, it should have happened for the previous releases as well.

My scripts still need fine tuning, but I'm getting there :)


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

Re: [PATCH 2/2][v2] blk-plug: don't flush nested plug lists

2015-04-08 Thread Dave Chinner

[ Sending again with a trimmed CC list to just the lists. Jeff - cc
lists that large get blocked by mailing lists... ]

On Tue, Apr 07, 2015 at 02:55:13PM -0400, Jeff Moyer wrote:
> The way the on-stack plugging currently works, each nesting level
> flushes its own list of I/Os.  This can be less than optimal (read
> awful) for certain workloads.  For example, consider an application
> that issues asynchronous O_DIRECT I/Os.  It can send down a bunch of
> I/Os together in a single io_submit call, only to have each of them
> dispatched individually down in the bowels of the dirct I/O code.
> The reason is that there are blk_plug-s instantiated both at the upper
> call site in do_io_submit and down in do_direct_IO.  The latter will
> submit as little as 1 I/O at a time (if you have a small enough I/O
> size) instead of performing the batching that the plugging
> infrastructure is supposed to provide.

I'm wondering what impact this will have on filesystem metadata IO
that needs to be issued immediately. e.g. we are doing writeback, so
there is a high level plug in place and we need to page in btree
blocks to do extent allocation. We do readahead at this point,
but it looks like this change will prevent the readahead from being
issued by the unplug in xfs_buf_iosubmit().

So while I can see how this can make your single microbenchmark
better (because it's only doing concurrent direct IO to the block
device and hence there are no dependencies between individual IOs),
I have significant reservations that it's actually a win for
filesystem-based workloads where we need direct control of flushing
to minimise IO latency due to IO dependencies...

Patches like this one:

https://lkml.org/lkml/2015/3/20/442

show similar real-world workload improvements to your patchset by
being smarter about using high level plugging to enable cross-file
merging of IO, but it still relies on the lower layers of plugging
to resolve latency bubbles caused by IO dependencies in the
filesystems.

> NOTE TO SUBSYSTEM MAINTAINERS: Before this patch, blk_finish_plug
> would always flush the plug list.  After this patch, this is only the
> case for the outer-most plug.  If you require the plug list to be
> flushed, you should be calling blk_flush_plug(current).  Btrfs and dm
> maintainers should take a close look at this patch and ensure they get
> the right behavior in the end.

IOWs, you are saying we need to change all our current unplugs to
blk_flush_plug(current) to *try* to maintain the same behaviour as
we currently have? I say *try*, because no instead of just flushing
the readahead IO on the plug, we'll also flush all the queued data
writeback IO onthe high level plug. We don't actually want to do
that; we only want to submit the readahead and not the bulk IO that
will delay the latency sensitive dependent IOs

If that is the case, shouldn't you actually be trying to fix the
specific plugging problem you've identified (i.e. do_direct_IO() is
flushing far too frequently) rather than making a sweeping
generalisation that the IO stack plugging infrastructure
needs fundamental change?

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.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: console=ttyS1 breaks ttyS1 termios and prevents me from logging in

2015-04-08 Thread Andy Lutomirski

On Wed, Apr 8, 2015 at 4:32 PM, Peter Hurley  wrote:
> On 04/08/2015 05:40 PM, Andy Lutomirski wrote:
>> On Wed, Apr 8, 2015 at 2:29 PM, Peter Hurley  
>> wrote:
>>> Hi Andy,
>>>
>>> On 04/08/2015 05:17 PM, Andy Lutomirski wrote:
 Something strange seems to have happened to my serial console setup.
 I boot with console=ttyS1,115200n8 and I have a getty running on
 /dev/ttyS1.

 On older kernels, or if I remove the console= boot parameter, then my
 getty works fine.  On 3.19.3 with the console= parameter, something's
 wrong with termios and I can't log in.  Running:
>>>
>>> Thanks for the report.
>>> 1. Please attach your dmesg.
>>> 2. Is this behavior new to 3.19.3? (iow, what was the last version
>>>that you noticed didn't do this)
>>
>> I didn't have the problem before I reinstalled this box, upgraded from
>> 3.15 to 3.19.3, and updated by Dell iDRAC7 firmware.  Booting into
>> 3.13-something does *not* fix the problem, so I'm not at all convinced
>> that the kernel version matters much.  I'll try reverting the iDRAC7
>> thing, but I don't see why that would make any difference at all to
>> Linux.
>
> I think this is related to DRAC; maybe upgrading the firmware reset
> the Serial communication settings in the system bios?
>

The DRAC pretends to be a 16550, so I don't understand how it could
prevent Linux from reprogramming the line discipline.  Also, if I
remove console=ttyS1,115200 from the kernel command line, it starts
working again.

> 1. What's your getty command line?

/sbin/getty -8 115200 ttyS1


> 2. Contents of /proc/tty/driver/serial when you think getty is running
>and waiting for login (shows line signals).

With getty running:

serinfo:1.0 driver revision:
0: uart:16550A port:03F8 irq:4 tx:0 rx:0
1: uart:16550A port:02F8 irq:3 tx:19828 rx:2 RTS|CTS|DTR
2: uart:unknown port:03E8 irq:4
3: uart:unknown port:02E8 irq:3
4: uart:unknown port: irq:0

(getty itself works fine)

When I type a username, I get:

serinfo:1.0 driver revision:
0: uart:16550A port:03F8 irq:4 tx:0 rx:0
1: uart:16550A port:02F8 irq:3 tx:19848 rx:10 RTS|CTS|DTR
2: uart:unknown port:03E8 irq:4
3: uart:unknown port:02E8 irq:3
4: uart:unknown port: irq:0

at that point, login is running, and it's login that doesn't work.

>
> Something to test is if you set getty to local line, does it work then.
> I use agetty so my command line is:
> /sbin/getty --noreset -8L 115200 ttyS0 vt102

I tried:

# /sbin/getty --noreset -8L 115200 ttyS1 vt102

it has exactly the same problem.

By adding a whole bunch of printks, I see that both ttyS0 and ttyS1
make it into uart_set_termios.  But now it's time to home...

--Andy

>
> Regards,
> Peter Hurley
>
>
>> dmesg attached.  I don't even know what to look for there, though.
>>
>>>
>>> Regards,
>>> Peter Hurley
>>>
 # stty icanon >>>
 breaks line this (partial strace results included):

 ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
 TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
 ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
 TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
 ioctl(0, SNDCTL_TMR_STOP or SNDRV_TIMER_IOCTL_GINFO or TCSETSW,
 {B115200 opost -isig icanon -echo ...}) = 0
 ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
 TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
 ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
 TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
 write(2, "stty: ", 6stty: )   = 6
 write(2, "standard input: unable to perfor"..., 58standard input:
 unable to perform all requested operations) = 58

 IOW, the setting didn't stick.  On the bad kernel, stty works just
 fine on ttyS0.  If I switch to using console=ttyS0,115200, then stty
 works on ttyS1 and fails on ttyS0.

 I have no idea what's going on here.  I have two apparently identical
 boxes.  One of them has this problem and the other doesn't.
>>>
>>
>>
>>
>



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

RE: [PATCH] [media] v4l: vb2-memops: use vma slab when vma allocation

2015-04-08 Thread Cho KyongHo

Hans,
I didn't notice that vb2_put_vma is exported because I don't build modules.
I am sorry about bothering you.

Mauro,
I think it is better to drop my patch out from your tree
because I don't think it is not worth to export vm_area_cache_p to use it
in vb2_put_vma.

Regards,

KyongHo

-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl] 
Sent: Thursday, April 09, 2015 1:01 AM

Mauro,

Please revert this patch: vm_area_cachep is not exported, so you cannot use
this in a module.

Cho KyongHo, if you believe that vm_area_cachep should be exported so it can
be used here, then please make a patch for that.

For the time being though, this patch should be reverted.

This patch slipped through the cracks and I clearly never reviewed it, and I
only noticed the problem after I compiled the media_tree git repo after this
patch was merged.

Regards,

Hans

On 02/05/2015 06:52 AM, Cho KyongHo wrote:
> The slab for vm_area_struct which is vm_area_cachep is already 
> prepared for the general use. Instead of kmalloc() for the vma copy 
> for userptr, allocation from vm_area_cachep is more beneficial.
> 
> CC: Mauro Carvalho Chehab 
> CC: Hans Verkuil 
> CC: Laurent Pinchart 
> Signed-off-by: Cho KyongHo 
> ---
>  drivers/media/v4l2-core/videobuf2-memops.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-memops.c 
> b/drivers/media/v4l2-core/videobuf2-memops.c
> index 81c1ad8..dd06efa 100644
> --- a/drivers/media/v4l2-core/videobuf2-memops.c
> +++ b/drivers/media/v4l2-core/videobuf2-memops.c
> @@ -37,7 +37,7 @@ struct vm_area_struct *vb2_get_vma(struct 
> vm_area_struct *vma)  {
>   struct vm_area_struct *vma_copy;
>  
> - vma_copy = kmalloc(sizeof(*vma_copy), GFP_KERNEL);
> + vma_copy = kmem_cache_alloc(vm_area_cachep, GFP_KERNEL);
>   if (vma_copy == NULL)
>   return NULL;
>  
> @@ -75,7 +75,7 @@ void vb2_put_vma(struct vm_area_struct *vma)
>   if (vma->vm_file)
>   fput(vma->vm_file);
>  
> - kfree(vma);
> + kmem_cache_free(vm_area_cachep, vma);
>  }
>  EXPORT_SYMBOL_GPL(vb2_put_vma);
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: OT: Open letter to the Linux World

2015-04-08 Thread Rob Landley

On Wed, Apr 8, 2015 at 8:12 AM, Denys Vlasenko  wrote:
> On Tue, Aug 12, 2014 at 9:38 PM, Christopher Barry
>  wrote:
>> So why would very smart people who love and use Linux want to create or
>> embrace such a creepy 'Master of All' daemon? Ostensibly, it's for the
>> reasons they say, as I mentioned at the top. But partially I think it's
>> from a lack of experience. Not a lack as in programming hours, but a
>> lack as in time on the Planet. Intelligence alone is not a substitute
>> for life experience and, yes I'll say it, wisdom. There's no manual for
>> wisdom. Implementing systemd by distros is not a wise move for them over
>> the long term. It will, in fact, be their ultimate undoing.
>>
>> Partially it's the larger-than-life egos of the people involved. Has
>> anyone actually read what Poettering says about things? Wow. This guy
>> is obviously convinced he has all the answers for everyone. Traditional
>> ideas about simplicity and freedom are quaint, but have no real place
>> in a 'modern' OS. Look, he's just smarter than you, so get over it and
>> move aside. He knows what's best, and he has it under control. How old
>> is this guy anyway? 12 or so? He's a fucking tool (IMHO).
>
> Yes, this is *exactly* the problem with systemd.

Not to me.

I responded to systemd the way I responded to udev, "that's too
complicated, lemme see if I can clone a subset of it". In busybox this
resulted in mdev, so you had an alternate implementation that did the
same thing and could swap between them. (This lead to me butting heads
with Greg KH and Kay Sievers on more than one occasion, because they
were convinced sysfs was a private export from their kernel software
to their userspace software which nobody else would ever use and they
could force upgrades on both sides in lockstep. And they continued to
act this way even after Linus chewed them out about it, but I worked
around it and moved on.)

But systemd has no clear goals, no specification, the single
implementation is a moving target... it's basically a microsoft
product. Remember the days when the *.doc file format was "what
microsoft offices produces and is capable of consuming", and the
staroffice guys went to GREAT LENGTHS to reverse engineer it made
possible only by the fact that Microsoft went years between releases
so they had time to work out what the office 6 format was before
office 7 came out, and so on. Same for the Excel file format being
"what microsoft's implementation produces and consumes is correct by
definition, every strange corner case bug of that one magic
implementation _is_ the spec and there is no other."

Samba reverse engineered windows NT's network protocols the same way,
producing a giant "if it's this version, do this. If it's this
versino, do this. Avoid doing this because it bluescreens this
specific version of NT for no apparent reason..."

i thought we'd moved _on_ from the days of "this site optimized for
internet explorer", but systemd is that all over again. Linux is all
about modularity where you swap out openssh for libressh (or dropbear)
and swap out xfree86 for x.org and swap out glibc for eglibc (or
uclibc or musl) and you have at least a fighting chance to make it
work. Unfortunately, the systemd developers take the suggestion that
you might want to keep the option of doing that open as some sort of
personal attack.

I don't care what they're doing. I don't want to _have_ to care what
they're doing. I want a description of the problem space from which I
can write a new implementation. If I can't even reverse engineer such
a thing because it's still too much of a moving target several years
into the project, then what they're doing is crazy and I refuse to get
any of it on me.

> Not the quality of the code. Not the desire to fix some
> old design problems of SystemV-style init.

I'm still unclear on what problem they were actually trying to solve.
(In my defense, _they_ seem unclear. We're way beyond Zawinski's law
here...)

> Code quality is good. The goals are legitimate.

1) Not really, but that's beside the point. 2) What _are_ the goals?
They keep changing...

> The problem is: the author is a control freak.

I don't care. Honestly don't care. We used cdrecord for years from a
solaris bigot who openly insulted linux in the README, Openssl's
maintainer wasn't that much happier about Linux (until he needed
money), put up with xfree86's insular development for a couple
_decades_ before that maintainer finally went over the line.

Heck, the FSF's entire "It's GNU Linux, Dammit! Call it by its proper
name: GNU/Linux/dammit" campaign is seriously irritating, and part of
what I was doing with busybox was trying to create a linux development
system without a single gnu package in it (busybox, uclibc, tinycc)
capable of rebuilding itself under itself, and then ask Stallman "I
know you're going to insist this isn't a Linux system but a
GNU/Linux/Dammit system, I'd just like you to try to explain _how_."
(Preferably

Re: [PATCH] KVM: use slowpath for cross page cached accesses

2015-04-08 Thread Wanpeng Li

On Wed, Apr 08, 2015 at 02:16:48PM +0200, Radim Krčmář wrote:
>2015-04-08 12:43+0200, Paolo Bonzini:
>> On 08/04/2015 11:26, Radim Krčmář wrote:
>>> 2015-04-08 10:49+0200, Paolo Bonzini:
 On 07/04/2015 22:34, Radim Krčmář wrote:
> We dirtied only one page because writes originally couldn't span more.
> Use improved syntax for '>> PAGE_SHIFT' while at it.
>
> Fixes: 8f964525a121 ("KVM: Allow cross page reads and writes from cached 
> translations.")
> Signed-off-by: Radim Krčmář 

 Cross-page reads and writes should never get here; they have
 ghc->memslot set to NULL and go through the slow path in kvm_write_guest.
>>> 
>>> Only cross-memslot writes have NULL memslot.
>> 
>> The power of wrong comments...
>> 
>> Considering how kvm_gfn_to_hva_cache_init is used (one 1-byte field, two
>> 4-byte fields, one 28-bytes struct that is 32-bytes aligned, one
>> 32-bytes field that is in practice cacheline-aligned), I wonder if we
>> should just use ghc->memslot = NULL for cross page writes.  This would
>> bypass the bug you are fixing here, and avoid worries about partial writes.
>
>Good idea, and it could make those comments right :)
>(Though in general, I prefer less constraints on APIs ...)
>
>Partial writes would be a pain;  copy_to_user API does not define which
>bytes were not written.  I think the write can't fail mid-page, which
>makes our implementation ok, but I still worry a bit about it.
>
>Anyway, here's the patch:
>
>---8<---
>kvm_write_guest_cached() does not mark all written pages as dirty and
>code comments in kvm_gfn_to_hva_cache_init() talk about NULL memslot
>with cross page accesses.  Fix all the easy way.
>
>The check is '<= 1' to have the same result for 'len = 0' cache anywhere
>in the page.  (nr_pages_needed is 0 on page boundary.)
>
>Fixes: 8f964525a121 ("KVM: Allow cross page reads and writes from cached 
>translations.")
>Signed-off-by: Radim Krčmář 

Reviewed-by: Wanpeng Li 

>---
> virt/kvm/kvm_main.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>index aadef264bed1..f3dc641f9640 100644
>--- a/virt/kvm/kvm_main.c
>+++ b/virt/kvm/kvm_main.c
>@@ -1637,8 +1637,8 @@ int kvm_gfn_to_hva_cache_init(struct kvm *kvm, struct 
>gfn_to_hva_cache *ghc,
>   ghc->generation = slots->generation;
>   ghc->len = len;
>   ghc->memslot = gfn_to_memslot(kvm, start_gfn);
>-  ghc->hva = gfn_to_hva_many(ghc->memslot, start_gfn, _pages_avail);
>-  if (!kvm_is_error_hva(ghc->hva) && nr_pages_avail >= nr_pages_needed) {
>+  ghc->hva = gfn_to_hva_many(ghc->memslot, start_gfn, NULL);
>+  if (!kvm_is_error_hva(ghc->hva) && nr_pages_needed <= 1) {
>   ghc->hva += offset;
>   } else {
>   /*
>--
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] checkpatch: Add a test for const with __read_mostly uses

2015-04-08 Thread Joe Perches

On Thu, 2015-04-09 at 02:28 +0200, Andi Kleen wrote:
> On Wed, Apr 08, 2015 at 05:14:49PM -0700, Joe Perches wrote:
> > const objects shouldn't be __read_mostly.  They are read-only.
> > 
> > Marking these objects as __read_mostly causes section conflicts
> > with LTO linking.
> > 
> > So add a test to try to avoid this issue.
> 
> I suspect excluding *
> will miss quite a few cases, but there's no way around it.

That excludes only "const  *" not "const foo * const"
so I believe it shouldn't exclude anything that's not
pointer to const.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] checkpatch: Add a test for const with __read_mostly uses

2015-04-08 Thread Andi Kleen

On Wed, Apr 08, 2015 at 05:14:49PM -0700, Joe Perches wrote:
> const objects shouldn't be __read_mostly.  They are read-only.
> 
> Marking these objects as __read_mostly causes section conflicts
> with LTO linking.
> 
> So add a test to try to avoid this issue.

Thanks Joe. Looks good thanks. I suspect excluding * 
will miss quite a few cases, but there's no way around it.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] checkpatch: Add a test for const with __read_mostly uses

2015-04-08 Thread Joe Perches

const objects shouldn't be __read_mostly.  They are read-only.

Marking these objects as __read_mostly causes section conflicts
with LTO linking.

So add a test to try to avoid this issue.

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 9a8b2bd..199d81b 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4777,6 +4777,16 @@ sub process {
}
}
 
+# check for __read_mostly with const non-pointer (should just be const)
+   if ($line =~ /\b__read_mostly\b/ &&
+   $line =~ /($Type)\s*$Ident/ && $1 !~ /\*\s*$/ && $1 =~ 
/\bconst\b/) {
+   if (ERROR("CONST_READ_MOSTLY",
+ "Invalid use of __read_mostly with const 
type\n" . $herecurr) &&
+   $fix) {
+   $fixed[$fixlinenr] =~ s/\s+__read_mostly\b//;
+   }
+   }
+
 # don't use __constant_ functions outside of include/uapi/
if ($realfile !~ m@^include/uapi/@ &&
$line =~ 
/(__constant_(?:htons|ntohs|[bl]e(?:16|32|64)_to_cpu|cpu_to_[bl]e(?:16|32|64)))\s*\(/)
 {


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mips: Fix build if PERF_EVENTS is configured

2015-04-08 Thread Ralf Baechle

On Wed, Apr 08, 2015 at 01:29:52PM -0700, Guenter Roeck wrote:

> mips builds fail in -next as follows if PERF_EVENTS is configured.
> 
> kernel/built-in.o: In function `perf_sample_regs_user':
> kernel/events/core.c:4828: undefined reference to `perf_get_regs_user'
> 
> The problem is caused by commit 3478e32c1545 ("MIPS: Add user stack and
> registers to perf.") in combination with commit 88a7c26af8da ("perf:
> Move task_pt_regs sampling into arch code"), which introduces
> perf_get_regs_user().
> 
> Cc: Andy Lutomirski 
> Cc: David Daney 
> Signed-off-by: Guenter Roeck 

I've already applied the same change locally but due to patch ordering
constraints I'm considering to temporarily pull this patch until the
perf stuff and the remainder of the MIPS changes are in 4.1 or so.

Thanks,

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

Re: [PATCH 3/3] PCI: Set pref for mem64 resource of pcie device

2015-04-08 Thread Yinghai Lu

On Wed, Apr 8, 2015 at 2:12 PM, Benjamin Herrenschmidt
 wrote:

> Thanks Bjorn. We can fix Yinghai patch for 4.2, it would be indeed handy
> even for us to be able to support putting 64-bit NP BARs in prefetch
> windows (For some SR-IOV adapters for example) too, but we need to do it
> right.

Please check if you are ok with attached.

Yinghai
Subject: [PATCH v3] PCI: Set under_pref for mem64 resource of pcie device

We still get "no compatible bridge window" warning on sparc T5-8
after we add support for 64bit resource parsing for root bus.

 PCI: scan_bus[/pci@300/pci@1/pci@0/pci@6] bus no 8
 PCI: Claiming :00:01.0: Resource 15: 8001..8004afff [220c]
 PCI: Claiming :01:00.0: Resource 15: 8001..8004afff [220c]
 PCI: Claiming :02:04.0: Resource 15: 8001..80012fff [220c]
 PCI: Claiming :03:00.0: Resource 15: 8001..80012fff [220c]
 PCI: Claiming :04:06.0: Resource 14: 8001..80010fff [220c]
 PCI: Claiming :05:00.0: Resource 0: 8001..80011fff [204]
 pci :05:00.0: can't claim BAR 0 [mem 0x8001-0x80011fff]: no compatible bridge window

All the bridges 64-bit resource have pref bit, but the device resource does not
have pref set, then we can not find parent for the device resource,
as we can not put non-pref mem under pref mem.

According to pcie spec errta
https://www.pcisig.com/specifications/pciexpress/base2/PCIe_Base_r2.1_Errata_08Jun10.pdf
page 13, in some case it is ok to mark some as pref.

Only set pref for 64bit mmio when the entire path from the host to the adapter is
over PCI Express.

Fixes: commit d63e2e1f3df9 ("sparc/PCI: Clip bridge windows to fit in upstream windows")
Link: http://lkml.kernel.org/r/cae9fiqu1gjy1lyrxs+ma5lcteee4xmtjrg0axj9k_tsu+m9...@mail.gmail.com
Reported-by: David Ahern 
Tested-by: David Ahern 
Signed-off-by: Yinghai Lu 
Cc:   #3.19

---
-v2: set pref for mmio 64 when whole path is PCI Express, according to David Miller.
-v3: don't set pref directly, change to UNDER_PREF, and set PREF before
 sizing and assign resource, and cleart PREF afterwards. requested by BenH.
---


---
 drivers/pci/bus.c   |9 +++-
 drivers/pci/pci.h   |   11 ++
 drivers/pci/probe.c |   50 
 drivers/pci/setup-bus.c |8 ++-
 drivers/pci/setup-res.c |   10 +
 include/linux/ioport.h  |2 +
 6 files changed, 88 insertions(+), 2 deletions(-)

Index: linux-2.6/drivers/pci/bus.c
===
--- linux-2.6.orig/drivers/pci/bus.c
+++ linux-2.6/drivers/pci/bus.c
@@ -139,6 +139,8 @@ static int pci_bus_alloc_from_region(str
 
 	type_mask |= IORESOURCE_TYPE_BITS;
 
+	pci_set_pref_under_pref(res);
+
 	pci_bus_for_each_resource(bus, r, i) {
 		if (!r)
 			continue;
@@ -170,9 +172,14 @@ static int pci_bus_alloc_from_region(str
 		/* Ok, try it out.. */
 		ret = allocate_resource(r, res, size, min, max,
 	align, alignf, alignf_data);
-		if (ret == 0)
+		if (ret == 0) {
+			pci_clear_pref_under_pref(res);
 			return 0;
+		}
 	}
+
+	pci_clear_pref_under_pref(res);
+
 	return -ENOMEM;
 }
 
Index: linux-2.6/drivers/pci/pci.h
===
--- linux-2.6.orig/drivers/pci/pci.h
+++ linux-2.6/drivers/pci/pci.h
@@ -216,6 +216,17 @@ void __pci_bus_assign_resources(const st
 struct list_head *fail_head);
 bool pci_bus_clip_resource(struct pci_dev *dev, int idx);
 
+static inline void pci_set_pref_under_pref(struct resource *res)
+{
+	if (res->flags & IORESOURCE_UNDER_PREF)
+		res->flags |= IORESOURCE_PREFETCH;
+}
+static inline void pci_clear_pref_under_pref(struct resource *res)
+{
+	if (res->flags & IORESOURCE_UNDER_PREF)
+		res->flags &= ~IORESOURCE_PREFETCH;
+}
+
 /**
  * pci_ari_enabled - query ARI forwarding status
  * @bus: the PCI bus
Index: linux-2.6/drivers/pci/probe.c
===
--- linux-2.6.orig/drivers/pci/probe.c
+++ linux-2.6/drivers/pci/probe.c
@@ -1508,6 +1508,53 @@ static void pci_init_capabilities(struct
 	pci_enable_acs(dev);
 }
 
+static bool pci_up_path_over_pcie(struct pci_bus *bus)
+{
+	if (!bus)
+		return true;
+
+	if (bus->self && !pci_is_pcie(bus->self))
+		return false;
+
+	return pci_up_path_over_pcie(bus->parent);
+}
+
+/*
+ * According to
+ * https://www.pcisig.com/specifications/pciexpress/base2/PCIe_Base_r2.1_Errata_08Jun10.pdf
+ * page 13, system firmware could put some 64bit non-pref under 64bit pref,
+ * on some cases.
+ * Let's set pref bit for 64bit mmio when entire path from the host to
+ * the adapter is over PCI Express.
+ */
+static void set_pcie_64bit_under_pref(struct pci_dev *dev)
+{
+	int i;
+
+	if (!pci_is_pcie(dev))
+		return;
+
+	if (!pci_up_path_over_pcie(dev->bus))
+		return;
+
+	for (i = 0; i < PCI_BRIDGE_RESOURCES; i++) {
+		struct resource *res =

[RFC PATCH] ARM: debug: Add prompt for FRAME_POINTER to Kconfig.debug

2015-04-08 Thread Gregory Fong

Without a prompt string, it is impossible to disable FRAME_POINTER on
ARM. It will simply set the default value anytime you run 'make'.

To reproduce the original issue, run:
  make multi_v7_defconfig
  scripts/config -d ARM_UNWIND
  make oldconfig
  # check .config, note that FRAME_POINTER=y
  scripts/config -d FRAME_POINTER
  make oldconfig
  # check .config, note that FRAME_POINTER is still y

Signed-off-by: Gregory Fong 
---
 arch/arm/Kconfig.debug | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 970de75..b881fd3 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -33,7 +33,7 @@ config STRICT_DEVMEM
 # traces, you can get a slightly smaller kernel by setting this option to
 # n, but then RMK will have to kill you ;).
 config FRAME_POINTER
-   bool
+   bool "Compile the kernel with frame pointers"
depends on !THUMB2_KERNEL
default y if !ARM_UNWIND || FUNCTION_GRAPH_TRACER
help
-- 
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: about the flood of trivial patches and the Code of Conduct (was: Re: [PATCH 19/25] sched: Use bool function return values of true/false not 1/0)

2015-04-08 Thread Joe Perches

On Thu, 2015-04-09 at 01:37 +0200, Rafael J. Wysocki wrote:
> old code is somewhat like an ancient building. Yes, it needs to be
> kept in a good shape, but you won't replace bricks in it just because they are
> old, will you?

No, but you do have to replace/repoint the mortar
as it ages.

Here in SoCal, we also have to do structural work
on UnReinforced Masonry (URM) buildings to avoid
loss of life when the ground moves underneath us.

A small story:

There's a guy a few blocks from me that wants to
open a restaurant in a ~70 year old building. He's
been fighting the city permitting process for over
a year now because he rented a well built, but old,
URM building with double courses of brick walls
that had already had some structural improvements.

http://la.eater.com/2014/3/18/6260975/brixton-restaurant-going-into-the-joker-in-santa-monica

He added some windows where previously windows had
been located but also had been covered and filled-in
with over time. The place had been a dark, smoky
dive bar.

City went into a mode where any change to the
building was unacceptable unless _every_ element
of the building was brought up to new construction
standards.

It's a silly and expensive process for him and an
overall loss for the city because of delays in
creation of a tax-paying business.

Santa Monica, my home town...

Anyway, code isn't a lot like a building.

It's easy to prove that some source code change
doesn't cause a change in object output.

It's not so easy in a physical structure.

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

Re: [PATCH 1/3] PM suspend/hibernate: Call notifier after freezing processes

On Sunday, April 05, 2015 07:20:17 PM Pali Rohár wrote:
> To prevent race conditions on userspace processes with I/O some taks must be
> called after processes are freezed. This patch adds new events which are
> delivered by pm_notifier_call_chain() after freezing processes when doing
> suspend or hibernate action.
> 
> Signed-off-by: Pali Rohár 

Please don't add more notifiers.  Just call whatever you need directly from
where you need to call that.

If that is device-related, try to use device PM suspend/hibernate callbacks
instead.

> ---
>  include/linux/suspend.h  |2 ++
>  kernel/power/hibernate.c |2 ++
>  kernel/power/suspend.c   |4 +++-
>  3 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/suspend.h b/include/linux/suspend.h
> index 5efe743..bc743c8 100644
> --- a/include/linux/suspend.h
> +++ b/include/linux/suspend.h
> @@ -368,6 +368,8 @@ static inline bool hibernation_available(void) { return 
> false; }
>  #define PM_POST_SUSPEND  0x0004 /* Suspend finished */
>  #define PM_RESTORE_PREPARE   0x0005 /* Going to restore a saved image */
>  #define PM_POST_RESTORE  0x0006 /* Restore failed */
> +#define PM_HIBERNATION_AFTER_FREEZE  0x0007 /* After hibernation freeze */
> +#define PM_SUSPEND_AFTER_FREEZE  0x0008 /* After suspend freeze 
> */
>  
>  extern struct mutex pm_mutex;
>  
> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> index 2329daa..184f7ee 100644
> --- a/kernel/power/hibernate.c
> +++ b/kernel/power/hibernate.c
> @@ -671,6 +671,8 @@ int hibernate(void)
>   if (error)
>   goto Exit;
>  
> + pm_notifier_call_chain(PM_HIBERNATION_AFTER_FREEZE);
> +
>   lock_device_hotplug();
>   /* Allocate memory management structures */
>   error = create_basic_memory_bitmaps();
> diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
> index b7d6b3a..1776938 100644
> --- a/kernel/power/suspend.c
> +++ b/kernel/power/suspend.c
> @@ -268,8 +268,10 @@ static int suspend_prepare(suspend_state_t state)
>   trace_suspend_resume(TPS("freeze_processes"), 0, true);
>   error = suspend_freeze_processes();
>   trace_suspend_resume(TPS("freeze_processes"), 0, false);
> - if (!error)
> + if (!error) {
> + pm_notifier_call_chain(PM_SUSPEND_AFTER_FREEZE);
>   return 0;
> + }
>  
>   suspend_stats.failed_freeze++;
>   dpm_save_failed_step(SUSPEND_FREEZE);
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kconfig: Print full defined and depends for multiply-defined symbols

2015-04-08 Thread Gregory Fong

I accidentally marked this as patch 1/2, but this is the only patch.
Sorry for the confusion.

On Wed, Apr 8, 2015 at 4:56 PM, Gregory Fong  wrote:
> get_symbol_str() was assuming that symbols would only have a single
> property for the purpose of printing define and depends information.
> This is not true, and one current example is FRAME_POINTER which is
> both in lib/Kconfig.debug and arch/arm/Kconfig.debug.
>
> In order to print out the correct Defined and Depends info, iterate
> over all properties associated with the given symbol, similarly to was
> done for selects.  And for depends, rather than iterating over the
> property, just use the direct dependency expression.
>
> CONFIG_FRAME_POINTER text, before:
>   Defined at lib/Kconfig.debug:323
>   Depends on: DEBUG_KERNEL [=y] && (ARM [=y] || CRIS || M68K || FRV || UML || 
> AVR32 || SUPERH || BLACKFIN || MN10300 || METAG) || ARCH_WANT_FRAME_POINTERS 
> [=n]
>
> After:
>   Defined at lib/Kconfig.debug:323, arch/arm/Kconfig.debug:35
>   Depends on: DEBUG_KERNEL [=y] && (ARM [=y] || CRIS || M68K || FRV || UML || 
> AVR32 || SUPERH || BLACKFIN || MN10300 || METAG) || ARCH_WANT_FRAME_POINTERS 
> [=n] || !THUMB2_KERNEL [=n]
>
> Removes now-unused function get_symbol_prop().
>
> Signed-off-by: Gregory Fong 
> [snip]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/4] ACPI / scan: Simplify acpi_match_device()

From: Rafael J. Wysocki 

Redefine acpi_companion_match() to return an ACPI device object
pointer instead of a bool and use it to remove some redundant code
from acpi_match_device().

Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/scan.c |   30 +++---
 1 file changed, 11 insertions(+), 19 deletions(-)

Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -194,7 +194,8 @@ static int create_modalias(struct acpi_d
  *
  * Check if the given device has an ACPI companion and if that companion has
  * a valid list of PNP IDs, and if the device is the first (primary) physical
- * device associated with it.
+ * device associated with it.  Return the companion pointer if that's the case
+ * or NULL otherwise.
  *
  * If multiple physical devices are attached to a single ACPI companion, we 
need
  * to be careful.  The usage scenario for this kind of relationship is that all
@@ -208,31 +209,31 @@ static int create_modalias(struct acpi_d
  * resources available from it but they will be matched normally using 
functions
  * provided by their bus types (and analogously for their modalias).
  */
-static bool acpi_companion_match(const struct device *dev)
+static struct acpi_device *acpi_companion_match(const struct device *dev)
 {
struct acpi_device *adev;
-   bool ret;
 
adev = ACPI_COMPANION(dev);
if (!adev)
-   return false;
+   return NULL;
 
if (list_empty(>pnp.ids))
-   return false;
+   return NULL;
 
mutex_lock(>physical_node_lock);
if (list_empty(>physical_node_list)) {
-   ret = false;
+   adev = NULL;
} else {
const struct acpi_device_physical_node *node;
 
node = list_first_entry(>physical_node_list,
struct acpi_device_physical_node, node);
-   ret = node->dev == dev;
+   if (node->dev != dev)
+   adev = NULL;
}
mutex_unlock(>physical_node_lock);
 
-   return ret;
+   return adev;
 }
 
 /*
@@ -908,7 +909,7 @@ static const struct acpi_device_id *__ac
 * If the device is not present, it is unnecessary to load device
 * driver for it.
 */
-   if (!device->status.present)
+   if (!device || !device->status.present)
return NULL;
 
for (id = ids; id->id[0]; id++)
@@ -933,16 +934,7 @@ static const struct acpi_device_id *__ac
 const struct acpi_device_id *acpi_match_device(const struct acpi_device_id 
*ids,
   const struct device *dev)
 {
-   struct acpi_device *adev;
-   acpi_handle handle = ACPI_HANDLE(dev);
-
-   if (!ids || !handle || acpi_bus_get_device(handle, ))
-   return NULL;
-
-   if (!acpi_companion_match(dev))
-   return NULL;
-
-   return __acpi_match_device(adev, ids);
+   return __acpi_match_device(acpi_companion_match(dev), ids);
 }
 EXPORT_SYMBOL_GPL(acpi_match_device);
 

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

[PATCH 0/4] ACPI / scan: Clean up the handling of the PRP0001 device ID

Hi,

This series of patches reworks the handling of the PRP0001 device ID with
the following goals:

 (a) Make PRP0001 work as a _CID too.
 (b) Prevent PRP0001 from overriding the other ACPI/PNP IDs entirely.
 (c) Change ACPI modalias to cover ACPI/PNP/compatible at the same time.

[1/4] Generalize the of_compatible matching routine
[2/4] Simplify acpi_match_device()
[3/4] Take PRP0001 in _CID lists into account too.
[4/4] Rework modalias creation if the "compatible" property is present.

Comments, remarks, testing welcome!

Kind regards,
Rafael

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

[PATCH 0/2] ARM: dts: am57xx-beagle-x15: Fixes for RTC

Couple of fixes for MCP79410 RTC on BeagleBoard-X15 platform. This is
not urgent enough for 4.0 material, but will be good to have it on one
of 4.1 rcs. tested on next-20150407:
http://pastebin.ubuntu.com/1033/
(NOTE: I believe DRA7 rtc still needs reset driver to be done before it can be 
fully functional).

Grygorii Strashko (1):
  ARM: dts: am57xx-beagle-x15: Fix IRQ type for mcp7941x

Nishanth Menon (1):
  ARM: dts: am57xx-beagle-x15: Fix RTC aliases

 arch/arm/boot/dts/am57xx-beagle-x15.dts |3 ++-
 arch/arm/boot/dts/dra7.dtsi |2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

Regards,
Nishanth Menon
-- 
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 3/4] ACPI / scan: Take PRP0001 in _CID lists into account too

From: Rafael J. Wysocki 

If the special PRP0001 device ID is present in a device's _CID list,
it should be treated the same way as for the _HID case.  That is,
if none of the IDs preceding it in the device's PNP/ACPI IDs list
matches the IDs recognized by the driver, the driver's list of
"compatible" IDs should be matched against the device's "compatible"
property, if present.

To make that happen, rework acpi_driver_match_device() to do the
"compatible" property check even if acpi_match_table is present
for the given driver.

That will also cover cases in which drivers provide both
acpi_match_table and of_match_table (which is perfectly valid) at the
same time.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/scan.c |  115 +---
 1 file changed, 65 insertions(+), 50 deletions(-)

Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -899,8 +899,51 @@ static void acpi_device_remove_files(str
ACPI Bus operations
-- 
*/
 
+/**
+ * acpi_of_match_device - Match device object using the "compatible" property.
+ * @adev: ACPI device object to match.
+ * @of_match_table: List of device IDs to match against.
+ *
+ * If @dev has an ACPI companion which has the special PRP0001 device ID in its
+ * list of identifiers and a _DSD object with the "compatible" property, use
+ * that property to match against the given list of identifiers.
+ */
+static bool acpi_of_match_device(struct acpi_device *adev,
+const struct of_device_id *of_match_table)
+{
+   const union acpi_object *of_compatible, *obj;
+   int i, nval;
+
+   if (!adev)
+   return false;
+
+   of_compatible = adev->data.of_compatible;
+   if (!of_match_table || !of_compatible)
+   return false;
+
+   if (of_compatible->type == ACPI_TYPE_PACKAGE) {
+   nval = of_compatible->package.count;
+   obj = of_compatible->package.elements;
+   } else { /* Must be ACPI_TYPE_STRING. */
+   nval = 1;
+   obj = of_compatible;
+   }
+   /* Now we can look for the driver DT compatible strings */
+   for (i = 0; i < nval; i++, obj++) {
+   const struct of_device_id *id;
+
+   for (id = of_match_table; id->compatible[0]; id++)
+   if (!strcasecmp(obj->string.pointer, id->compatible))
+   return true;
+   }
+
+   return false;
+}
+
 static const struct acpi_device_id *__acpi_match_device(
-   struct acpi_device *device, const struct acpi_device_id *ids)
+   struct acpi_device *device,
+   const struct acpi_device_id *ids,
+   const struct of_device_id *of_ids)
 {
const struct acpi_device_id *id;
struct acpi_hardware_id *hwid;
@@ -912,11 +955,24 @@ static const struct acpi_device_id *__ac
if (!device || !device->status.present)
return NULL;
 
-   for (id = ids; id->id[0]; id++)
-   list_for_each_entry(hwid, >pnp.ids, list)
+   list_for_each_entry(hwid, >pnp.ids, list) {
+   /* First, check the ACPI/PNP IDs provided by the caller. */
+   for (id = ids; id->id[0]; id++)
if (!strcmp((char *) id->id, hwid->id))
return id;
 
+   /*
+* Next, check the special "PRP0001" ID and try to match the
+* "compatible" property if found.
+*
+* The id returned by the below is not valid, but the only
+* caller passing non-NULL of_ids here is only interested in
+* whether or not the return value is NULL.
+*/
+   if (!strcmp("PRP0001", hwid->id)
+   && acpi_of_match_device(device, of_ids))
+   return id;
+   }
return NULL;
 }
 
@@ -934,67 +990,26 @@ static const struct acpi_device_id *__ac
 const struct acpi_device_id *acpi_match_device(const struct acpi_device_id 
*ids,
   const struct device *dev)
 {
-   return __acpi_match_device(acpi_companion_match(dev), ids);
+   return __acpi_match_device(acpi_companion_match(dev), ids, NULL);
 }
 EXPORT_SYMBOL_GPL(acpi_match_device);
 
 int acpi_match_device_ids(struct acpi_device *device,
  const struct acpi_device_id *ids)
 {
-   return __acpi_match_device(device, ids) ? 0 : -ENOENT;
+   return __acpi_match_device(device, ids, NULL) ? 0 : -ENOENT;
 }
 EXPORT_SYMBOL(acpi_match_device_ids);
 
-/**
- * acpi_of_match_device - Match device using the "compatible" property.
- * @dev: Device to match.
- * @of_match_table: List of device IDs to match against.

[PATCH 1/4] ACPI / scan: Generalize of_compatible matching

From: Rafael J. Wysocki 

Redefine the function used for matching the device's "compatible"
property against a given list of "compatible" strings to take
a pointer to that list instead of a driver object pointer to
make it more general.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/scan.c |   20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -953,9 +953,17 @@ int acpi_match_device_ids(struct acpi_de
 }
 EXPORT_SYMBOL(acpi_match_device_ids);
 
-/* Performs match against special "PRP0001" shoehorn ACPI ID */
-static bool acpi_of_driver_match_device(struct device *dev,
-   const struct device_driver *drv)
+/**
+ * acpi_of_match_device - Match device using the "compatible" property.
+ * @dev: Device to match.
+ * @of_match_table: List of device IDs to match against.
+ *
+ * If @dev has an ACPI companion which has the special PRP0001 device ID in its
+ * list of identifiers and a _DSD object with the "compatible" property, use
+ * that property to match against the given list of identifiers.
+ */
+static bool acpi_of_match_device(struct device *dev,
+const struct of_device_id *of_match_table)
 {
const union acpi_object *of_compatible, *obj;
struct acpi_device *adev;
@@ -966,7 +974,7 @@ static bool acpi_of_driver_match_device(
return false;
 
of_compatible = adev->data.of_compatible;
-   if (!drv->of_match_table || !of_compatible)
+   if (!of_match_table || !of_compatible)
return false;
 
if (of_compatible->type == ACPI_TYPE_PACKAGE) {
@@ -980,7 +988,7 @@ static bool acpi_of_driver_match_device(
for (i = 0; i < nval; i++, obj++) {
const struct of_device_id *id;
 
-   for (id = drv->of_match_table; id->compatible[0]; id++)
+   for (id = of_match_table; id->compatible[0]; id++)
if (!strcasecmp(obj->string.pointer, id->compatible))
return true;
}
@@ -992,7 +1000,7 @@ bool acpi_driver_match_device(struct dev
  const struct device_driver *drv)
 {
if (!drv->acpi_match_table)
-   return acpi_of_driver_match_device(dev, drv);
+   return acpi_of_match_device(dev, drv->of_match_table);
 
return !!acpi_match_device(drv->acpi_match_table, dev);
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 RESEND] mailbox: add ACPI support for mailbox framework

2015-04-08 Thread Feng Kan

This will add support for ACPI parsing of the mboxes attribute
when booting with ACPI table. The client will have a attribute
mimic the dts call "mboxes". In the ACPI case, the client will
mark "mboxes" with the ACPI reference of the mbox it wishes to
use.

Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package (2) {"mboxes", Package(){"^^MBOXREF, index"}}
}
})

Signed-off-by: Feng Kan 
---
 V2 CHANGE:
- change to use ACPI reference rather than use ACPI HID directly.
- consolidate to use one single xlate function
- fix code to accept use of index

 drivers/mailbox/mailbox.c  | 105 ++---
 include/linux/mailbox_controller.h |   6 +--
 2 files changed, 76 insertions(+), 35 deletions(-)

diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 19b491d..3bb981c 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -9,6 +9,7 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -278,6 +279,70 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)
 }
 EXPORT_SYMBOL_GPL(mbox_send_message);
 
+#ifdef CONFIG_ACPI
+static struct mbox_chan *mbox_acpi_parse_chan(struct device *dev, int index)
+{
+   struct acpi_device *acpi_dev;
+   struct mbox_controller *mbox;
+   struct mbox_chan *chan;
+   int status;
+   struct acpi_reference_args args;
+
+   status = acpi_dev_get_property_reference(ACPI_COMPANION(dev), "mboxes",
+index, );
+   if (ACPI_FAILURE(status)) {
+   dev_dbg(dev, "mbox: no matching mbox found in ACPI table\n");
+   return ERR_PTR(-ENODEV);
+   }
+   acpi_dev = args.adev;
+
+   chan = NULL;
+   list_for_each_entry(mbox, _cons, node)
+   if (ACPI_COMPANION(mbox->dev) == acpi_dev) {
+   chan = mbox->chan_xlate(mbox, args.args[0]);
+   break;
+   }
+
+   return chan;
+}
+#endif
+
+static struct mbox_chan *mbox_of_parse_chan(struct device *dev, int index)
+{
+   struct of_phandle_args spec;
+   struct mbox_controller *mbox;
+   struct mbox_chan *chan;
+
+   if (of_parse_phandle_with_args(dev->of_node, "mboxes",
+  "#mbox-cells", index, )) {
+   dev_dbg(dev, "%s: can't parse \"mboxes\" property\n", __func__);
+   return ERR_PTR(-ENODEV);
+   }
+
+   chan = NULL;
+   list_for_each_entry(mbox, _cons, node)
+   if (mbox->dev->of_node == spec.np) {
+   chan = mbox->chan_xlate(mbox, spec.args[0]);
+   break;
+   }
+
+   of_node_put(spec.np);
+   return chan;
+}
+
+static struct mbox_chan *mbox_parse_chan(struct device *dev, int index)
+{
+   if (!dev)
+   return ERR_PTR(-ENODEV);
+
+   if (dev->of_node)
+   return mbox_of_parse_chan(dev, index);
+#ifdef CONFIG_ACPI
+   else
+   return mbox_acpi_parse_chan(dev, index);
+#endif
+}
+
 /**
  * mbox_request_channel - Request a mailbox channel.
  * @cl: Identity of the client requesting the channel.
@@ -298,36 +363,15 @@ EXPORT_SYMBOL_GPL(mbox_send_message);
 struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index)
 {
struct device *dev = cl->dev;
-   struct mbox_controller *mbox;
-   struct of_phandle_args spec;
struct mbox_chan *chan;
unsigned long flags;
int ret;
 
-   if (!dev || !dev->of_node) {
-   pr_debug("%s: No owner device node\n", __func__);
-   return ERR_PTR(-ENODEV);
-   }
-
mutex_lock(_mutex);
+   chan = mbox_parse_chan(dev, index);
 
-   if (of_parse_phandle_with_args(dev->of_node, "mboxes",
-  "#mbox-cells", index, )) {
-   dev_dbg(dev, "%s: can't parse \"mboxes\" property\n", __func__);
-   mutex_unlock(_mutex);
-   return ERR_PTR(-ENODEV);
-   }
-
-   chan = NULL;
-   list_for_each_entry(mbox, _cons, node)
-   if (mbox->dev->of_node == spec.np) {
-   chan = mbox->of_xlate(mbox, );
-   break;
-   }
-
-   of_node_put(spec.np);
-
-   if (!chan || chan->cl || !try_module_get(mbox->dev->driver->owner)) {
+   if (!chan || chan->cl ||
+   !try_module_get(chan->mbox->dev->driver->owner)) {
dev_dbg(dev, "%s: mailbox not free\n", __func__);
mutex_unlock(_mutex);
return ERR_PTR(-EBUSY);
@@ -384,15 +428,12 @@ void mbox_free_channel(struct mbox_chan *chan)
 EXPORT_SYMBOL_GPL(mbox_free_channel);
 
 static struct mbox_chan *
-of_mbox_index_xlate(struct mbox_controller *mbox,
-

[PATCH 4/4] ACPI / scan: Rework modalias creation when "compatible" is present

From: Rafael J. Wysocki 

Currently, the ACPI modalias creation covers two mutually exclusive
cases: If the PRP0001 device ID is present in the device's list of
ACPI/PNP IDs and the "compatible" property is present in _DSD, the
created modalias will follow the OF rules of modalias creation.
Otherwise, ACPI rules are used.

However, that is not really desirable, because the presence of PRP0001
in the list of device IDs generally does not preclude using other
ACPI/PNP IDs with that device and those other IDs may be of higher
priority.  In those cases, the other IDs should take preference over
PRP0001 and therefore they also should be present in the modalias.

For this reason, rework the modalias creation for ACPI so that it
shows both the ACPI-style and OF-style modalias strings if the
device has a non-empty list of ACPI/PNP IDs (other than PNP0001)
and a valid "compatible" property at the same time.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/scan.c |  204 ++--
 1 file changed, 120 insertions(+), 84 deletions(-)

Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -122,8 +122,8 @@ int acpi_scan_add_handler_with_hotplug(s
  * -EINVAL: output error
  * -ENOMEM: output is truncated
 */
-static int create_modalias(struct acpi_device *acpi_dev, char *modalias,
-  int size)
+static int create_pnp_modalias(struct acpi_device *acpi_dev, char *modalias,
+  int size)
 {
int len;
int count;
@@ -132,58 +132,74 @@ static int create_modalias(struct acpi_d
if (list_empty(_dev->pnp.ids))
return 0;
 
+   len = snprintf(modalias, size, "acpi:");
+   size -= len;
+
+   list_for_each_entry(id, _dev->pnp.ids, list) {
+   if (!strcmp(id->id, "PRP0001"))
+   continue;
+
+   count = snprintf([len], size, "%s:", id->id);
+   if (count < 0)
+   return -EINVAL;
+
+   if (count >= size)
+   return -ENOMEM;
+
+   len += count;
+   size -= count;
+   }
+   modalias[len] = '\0';
+   return len;
+}
+
+static int create_of_modalias(struct acpi_device *acpi_dev, char *modalias,
+ int size)
+{
+   struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER };
+   const union acpi_object *of_compatible, *obj;
+   int len, count;
+   int i, nval;
+   char *c;
+
/*
-* If the device has PRP0001 we expose DT compatible modalias
-* instead in form of of:NnameTCcompatible.
+* If the device has PRP0001 we expose DT compatible modalias as
+* of:NnameTCcompatible.
 */
-   if (acpi_dev->data.of_compatible) {
-   struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER };
-   const union acpi_object *of_compatible, *obj;
-   int i, nval;
-   char *c;
-
-   acpi_get_name(acpi_dev->handle, ACPI_SINGLE_NAME, );
-   /* DT strings are all in lower case */
-   for (c = buf.pointer; *c != '\0'; c++)
-   *c = tolower(*c);
-
-   len = snprintf(modalias, size, "of:N%sT", (char *)buf.pointer);
-   ACPI_FREE(buf.pointer);
-
-   of_compatible = acpi_dev->data.of_compatible;
-   if (of_compatible->type == ACPI_TYPE_PACKAGE) {
-   nval = of_compatible->package.count;
-   obj = of_compatible->package.elements;
-   } else { /* Must be ACPI_TYPE_STRING. */
-   nval = 1;
-   obj = of_compatible;
-   }
-   for (i = 0; i < nval; i++, obj++) {
-   count = snprintf([len], size, "C%s",
-obj->string.pointer);
-   if (count < 0)
-   return -EINVAL;
-   if (count >= size)
-   return -ENOMEM;
+   if (!acpi_dev->data.of_compatible)
+   return 0;
 
-   len += count;
-   size -= count;
-   }
-   } else {
-   len = snprintf(modalias, size, "acpi:");
-   size -= len;
+   acpi_get_name(acpi_dev->handle, ACPI_SINGLE_NAME, );
+   /* DT strings are all in lower case */
+   for (c = buf.pointer; *c != '\0'; c++)
+   *c = tolower(*c);
 
-   list_for_each_entry(id, _dev->pnp.ids, list) {
-   count = snprintf([len], size, "%s:", id->id);
-   if (count < 0)
-   return -EINVAL;
-   if (count >= size)
-   return -ENOMEM;

[PATCH 1/2] ARM: dts: am57xx-beagle-x15: Fix IRQ type for mcp7941x

From: Grygorii Strashko 

The interrupt polarity provided in devicetree is used to configure
the interrupt controller(ARM GIC), however, it seems that we have an
inverter at the GIC boundary inside AM57xx which inverts the signal
input from sys_irq external interrupt source.

Further, as per GIC distributor TRM,
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438d/BGBHIACJ.html#BABJFCFB
ARM GIC distributor does not support IRQ trigger type
IRQ_TYPE_LEVEL_LOW, and only rising or level high signals.

However, for some reason, the current configuration(which gets ignored
by GIC driver) functions on some platforms, however, on few platforms
results in infinite interrupts hogging the system down.

Switch over to rising edge for GIC configuration which is also aligned
with trigger point from the RTC chip and the internal inversion.

Fixes: 5a0f93c6576a ("ARM: dts: Add am57xx-beagle-x15")
Signed-off-by: Grygorii Strashko 
Signed-off-by: Nishanth Menon 
---
 arch/arm/boot/dts/am57xx-beagle-x15.dts |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index fe141c47d647..57279e3b439b 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -455,7 +455,7 @@
mcp_rtc: rtc@6f {
compatible = "microchip,mcp7941x";
reg = <0x6f>;
-   interrupts = ;  /* IRQ_SYS_1N */
+   interrupts = ;  /* IRQ_SYS_1N */
 
pinctrl-names = "default";
pinctrl-0 = <_pins_default>;
-- 
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 1/2] kconfig: Print full defined and depends for multiply-defined symbols

2015-04-08 Thread Gregory Fong

get_symbol_str() was assuming that symbols would only have a single
property for the purpose of printing define and depends information.
This is not true, and one current example is FRAME_POINTER which is
both in lib/Kconfig.debug and arch/arm/Kconfig.debug.

In order to print out the correct Defined and Depends info, iterate
over all properties associated with the given symbol, similarly to was
done for selects.  And for depends, rather than iterating over the
property, just use the direct dependency expression.

CONFIG_FRAME_POINTER text, before:
  Defined at lib/Kconfig.debug:323
  Depends on: DEBUG_KERNEL [=y] && (ARM [=y] || CRIS || M68K || FRV || UML || 
AVR32 || SUPERH || BLACKFIN || MN10300 || METAG) || ARCH_WANT_FRAME_POINTERS 
[=n]

After:
  Defined at lib/Kconfig.debug:323, arch/arm/Kconfig.debug:35
  Depends on: DEBUG_KERNEL [=y] && (ARM [=y] || CRIS || M68K || FRV || UML || 
AVR32 || SUPERH || BLACKFIN || MN10300 || METAG) || ARCH_WANT_FRAME_POINTERS 
[=n] || !THUMB2_KERNEL [=n]

Removes now-unused function get_symbol_prop().

Signed-off-by: Gregory Fong 
---
 scripts/kconfig/menu.c | 35 +++
 1 file changed, 15 insertions(+), 20 deletions(-)

diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index 72c9dba..da482ff 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -601,18 +601,6 @@ static void get_prompt_str(struct gstr *r, struct property 
*prop,
 }
 
 /*
- * get property of type P_SYMBOL
- */
-static struct property *get_symbol_prop(struct symbol *sym)
-{
-   struct property *prop = NULL;
-
-   for_all_properties(sym, prop, P_SYMBOL)
-   break;
-   return prop;
-}
-
-/*
  * head is optional and may be NULL
  */
 void get_symbol_str(struct gstr *r, struct symbol *sym,
@@ -637,15 +625,22 @@ void get_symbol_str(struct gstr *r, struct symbol *sym,
for_all_prompts(sym, prop)
get_prompt_str(r, prop, head);
 
-   prop = get_symbol_prop(sym);
-   if (prop) {
-   str_printf(r, _("  Defined at %s:%d\n"), prop->menu->file->name,
+   hit = false;
+   for_all_properties(sym, prop, P_SYMBOL) {
+   if (!hit) {
+   str_append(r, "  Defined at ");
+   hit = true;
+   } else
+   str_append(r, ", ");
+   str_printf(r, _("%s:%d"), prop->menu->file->name,
prop->menu->lineno);
-   if (!expr_is_yes(prop->visible.expr)) {
-   str_append(r, _("  Depends on: "));
-   expr_gstr_print(prop->visible.expr, r);
-   str_append(r, "\n");
-   }
+   }
+   if (hit)
+   str_append(r, "\n");
+   if (!expr_is_yes(sym->dir_dep.expr)) {
+   str_append(r, _("  Depends on: "));
+   expr_gstr_print(sym->dir_dep.expr, r);
+   str_append(r, "\n");
}
 
hit = false;
-- 
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 2/2] ARM: dts: am57xx-beagle-x15: Fix RTC aliases

With commit bc078316d86c ("ARM: dts: DRA7: Add node for RTC"), we now
have AM57xx RTC register itself as alias 0 even before DS1307 or TPS
rtc drivers are loaded up. However, since neither TPS, nor AM57xx RTC
are capable of being backedup by battery, we would like to maintain
the "primary" rtc as mcp79410 rtc device.

This also generates the following warnings in the bootlog highlighting
the issue:
[5.895445] rtc-ds1307 2-006f: /aliases ID 0 not available
...
[6.476285] palmas-rtc 4807.i2c:tps659038@58:tps659038_rtc: /aliases ID 
1 not available

So, add proper aliases to ensure that RTC order is always consistent
to userspace immaterial of probe order.

Signed-off-by: Nishanth Menon 
---
 arch/arm/boot/dts/am57xx-beagle-x15.dts |1 +
 arch/arm/boot/dts/dra7.dtsi |2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 57279e3b439b..6837f44db534 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -18,6 +18,7 @@
aliases {
rtc0 = _rtc;
rtc1 = _rtc;
+   rtc2 = 
};
 
memory {
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 5332b57b4950..0f73fea9f5c3 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1203,7 +1203,7 @@
status = "disabled";
};
 
-   rtc@48838000 {
+   rtc: rtc@48838000 {
compatible = "ti,am3352-rtc";
reg = <0x48838000 0x100>;
interrupts = ,
-- 
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 2/2] test-hexdump.c: Fix initconst confusion

2015-04-08 Thread Andi Kleen

On Wed, Apr 08, 2015 at 03:35:54PM -0700, Andrew Morton wrote:
> > 
> > --- a/lib/test-hexdump.c
> > +++ b/lib/test-hexdump.c
> > @@ -18,26 +18,26 @@ static const unsigned char data_b[] = {
> >  
> >  static const unsigned char data_a[] = ".2.{p..$}.4...1.L...C...";
> >  
> > -static const char *test_data_1_le[] __initconst = {
> > +static const char * const test_data_1_le[] __initconst = {
> 
> const char * const __initconst

This one didn't cause any warnings elsewhere.

> 
> > "be", "32", "db", "7b", "0a", "18", "93", "b2",
> > "70", "ba", "c4", "24", "7d", "83", "34", "9b",
> > "a6", "9c", "31", "ad", "9c", "0f", "ac", "e9",
> > "4c", "d1", "19", "99", "43", "b1", "af", "0c",
> >  };
> >  
> > +static const char *test_data_2_le[] __initdata = {
> > +static const char *test_data_4_le[] __initdata = {
> > +static const char *test_data_8_le[] __initdata = {
> 
> const char * __initdata
> 
> Why is test_data_1_le[] different?
> 
> Can we make them all "const char * const __initconst"?  That would make
> checkpatch happy ;)

I tried it, but it would have needed a lot more changes to shut up
warnings later in the code. This was the least intrusive.

checkpatch is a bit stupid about this, but then C declarations are
difficult to parse...

-Andi

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

Re: [PATCH v2 2/2] tty: serial: msm: Disable pclk when port is closed

2015-04-08 Thread Stephen Boyd

On 04/08/15 06:28, Pramod Gurav wrote:
> Disable the pclk when tty port is closed by user space.
>
> Signed-off-by: Pramod Gurav 
> ---
>  drivers/tty/serial/msm_serial.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
> index 4c1e9ea..f38565c 100644
> --- a/drivers/tty/serial/msm_serial.c
> +++ b/drivers/tty/serial/msm_serial.c
> @@ -523,6 +523,7 @@ static void msm_shutdown(struct uart_port *port)
>   msm_write(port, 0, UART_IMR); /* disable interrupts */
>  
>   clk_disable_unprepare(msm_port->clk);
> + clk_disable_unprepare(msm_port->pclk);
>  
>   free_irq(port->irq, port);
>  }

It's not clear to me at all when this clock is enabled and when it's
disabled during the lifetime of this driver. For example, why do we have
a .pm op to turn clocks on and off? Shouldn't they already be on? Can
you please explain when the clocks are turned on and off and what
userspace actions cause that to happen? Looking at drivers like
amba-pl010.c I don't see any .pm op, just a
clk_prepare_enable/clk_disable_unprepare pair in the startup and
shutdown ops.

Minus my confusion of why our clocking is complicated, it looks correct
to me to do this, so

Reviewed-by: Stephen Boyd 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] lto: Add noreorder and mark initcalls noreorder

2015-04-08 Thread Andi Kleen

Hi Andrew,

On Wed, Apr 08, 2015 at 03:31:12PM -0700, Andrew Morton wrote:
> On Wed,  8 Apr 2015 06:17:38 -0700 Andi Kleen  wrote:
> 
> > From: Andi Kleen 
> > 
> > gcc 5 has a new no_reorder attribute that prevents top level
> > reordering only for that symbol.
> 
> I'm having trouble locating gcc documentation which explains all this
> stuff.

The official manuals only have released versions, and gcc 5 is not
released yet, but it's here:

https://github.com/gcc-mirror/gcc/blob/master/gcc/doc/extend.texi#L3505

> > Kernels don't like any reordering of initcalls between files, as several
> > initcalls depend on each other. LTO previously needed to use
> > -fno-toplevel-reordering to prevent boot failures.
> 
> That's "-fno-toplevel-reorder", I believe?

Yes.

> 
> > Add a __noreorder wrapper for the no_reorder attribute and use
> > it for initcalls.
> 
> Head is spinning a bit.  As this all appears to be shiny new
> added-by-andi gcc functionality, it would be useful if we could have a
> few more words describing what it's all about.  Reordering of what with
> respect to what and why and why is it bad.  Why is gcc reordering
> things anyway, and what's the downside of preventing this.  Why is the
> compiler reordering things rather than the linker. etc etc etc.

Ok, let me try.

The original gcc a long time was function at a time: it read one
function, optimizes and writes it out, then the next. Then gcc 3.x
added unit-at-a-time where it reads one complete file, optimizes it
completely and writes it out. This has the advantage that it can make
better inlining decisions, it can remove unused statics, it can propagate
execution frequencies over the call tree before optimizing, and some
other things. Then it writes it out the unit in the call tree order,
which can also lead to better executable layout.  One side effect of
this is that the order of top level statements gets lost, unless you
specify -fno-toplevel-reorder

We had to fix Linux for this sometime in early 2.6, late 2.4. Most
problems were in top level asm() statements, assuming they had a defined
order to other variables. To still support programs doing that gcc added
-fno-toplevel-reorder, which avoided such reordering, but also disabled
a small number of optimizations.

Now 4.x added LTO, where it takes unit-at-a-time one step further and
optimizes the complete program in the same way at link time. It actually
does not keep it in memory all the time, but uses various tricks to only
look at it in pieces and distribute the work to multiple cores. To do
that it uses partitioning, where the program is split into different
partitions based on its global call tree, and then each partition is
assigned to a compiler process.  The result is a changed order for
everything in the final program.

Modern Linux was generally fine with reordering, except for initcalls. We have
a lot of initcalls that assume that some other initcalls already ran
before them, without using priorities. The order is defined in in the
Makefile's object file order for the linker. Linkers generally do not
reorder, unless told to. Unfortunately that gets lost with LTO. 

When I started the LTO patchkit I tried to debug and fix some of these
init calls, but it was hopeless. It was like a many-headed hydra.
So I needed to use -fno-toplevel-reorder for LTO. In LTO this both
gives worse partitioning (so the build is less balanced between
different cores) and also disables some optimizations, like eliminating
unused variables or some cross file optimizations.

gcc 5 finally gained a way to specify the no-toplevel-reorder attribute
per symbol with this new attribute. So it can be only done for the initcall
symbols, and everything else left alone.

That is what this patch is about.

It's not needed without LTO, but I belive it's useful documentation even
without it.

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

Re: [PATCH 4/4] mm: make every pte dirty on do_swap_page

2015-04-08 Thread Minchan Kim

Bump.

On Wed, Mar 11, 2015 at 10:20:38AM +0900, Minchan Kim wrote:
> Bascially, MADV_FREE relys on the pte dirty to decide whether
> it allows VM to discard the page. However, if there is swap-in,
> pte pointed out the page has no pte_dirty. So, MADV_FREE checks
> PageDirty and PageSwapCache for those pages to not discard it
> because swapped-in page could live on swap cache or PageDirty
> when it is removed from swapcache.
> 
> The problem in here is that anonymous pages can have PageDirty if
> it is removed from swapcache so that VM cannot parse those pages
> as freeable even if we did madvise_free. Look at below example.
> 
> ptr = malloc();
> memset(ptr);
> ..
> heavy memory pressure -> swap-out all of pages
> ..
> out of memory pressure so there are lots of free pages
> ..
> var = *ptr; -> swap-in page/remove the page from swapcache. so pte_clean
>but SetPageDirty
> 
> madvise_free(ptr);
> ..
> ..
> heavy memory pressure -> VM cannot discard the page by PageDirty.
> 
> PageDirty for anonymous page aims for avoiding duplicating
> swapping out. In other words, if a page have swapped-in but
> live swapcache(ie, !PageDirty), we could save swapout if the page
> is selected as victim by VM in future because swap device have
> kept previous swapped-out contents of the page.
> 
> So, rather than relying on the PG_dirty for working madvise_free,
> pte_dirty is more straightforward. Inherently, swapped-out page was
> pte_dirty so this patch restores the dirtiness when swap-in fault
> happens so madvise_free doesn't rely on the PageDirty any more.
> 
> Cc: Hugh Dickins 
> Cc: Cyrill Gorcunov 
> Cc: Pavel Emelyanov 
> Reported-by: Yalin Wang 
> Signed-off-by: Minchan Kim 
> ---
>  mm/madvise.c | 1 -
>  mm/memory.c  | 9 +++--
>  mm/rmap.c| 2 +-
>  mm/vmscan.c  | 3 +--
>  4 files changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/mm/madvise.c b/mm/madvise.c
> index 22e8f0c..a045798 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -325,7 +325,6 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned 
> long addr,
>   continue;
>   }
>  
> - ClearPageDirty(page);
>   unlock_page(page);
>   }
>  
> diff --git a/mm/memory.c b/mm/memory.c
> index 0f96a4a..40428a5 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -2521,9 +2521,14 @@ static int do_swap_page(struct mm_struct *mm, struct 
> vm_area_struct *vma,
>  
>   inc_mm_counter_fast(mm, MM_ANONPAGES);
>   dec_mm_counter_fast(mm, MM_SWAPENTS);
> - pte = mk_pte(page, vma->vm_page_prot);
> +
> + /*
> +  * Every page swapped-out was pte_dirty so we make pte dirty again.
> +  * MADV_FREE relies on it.
> +  */
> + pte = pte_mkdirty(mk_pte(page, vma->vm_page_prot));
>   if ((flags & FAULT_FLAG_WRITE) && reuse_swap_page(page)) {
> - pte = maybe_mkwrite(pte_mkdirty(pte), vma);
> + pte = maybe_mkwrite(pte, vma);
>   flags &= ~FAULT_FLAG_WRITE;
>   ret |= VM_FAULT_WRITE;
>   exclusive = 1;
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 47b3ba8..34c1d66 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -1268,7 +1268,7 @@ static int try_to_unmap_one(struct page *page, struct 
> vm_area_struct *vma,
>  
>   if (flags & TTU_FREE) {
>   VM_BUG_ON_PAGE(PageSwapCache(page), page);
> - if (!dirty && !PageDirty(page)) {
> + if (!dirty) {
>   /* It's a freeable page by MADV_FREE */
>   dec_mm_counter(mm, MM_ANONPAGES);
>   goto discard;
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 260c413..3357ffa 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -805,8 +805,7 @@ static enum page_references page_check_references(struct 
> page *page,
>   return PAGEREF_KEEP;
>   }
>  
> - if (PageAnon(page) && !pte_dirty && !PageSwapCache(page) &&
> - !PageDirty(page))
> + if (PageAnon(page) && !pte_dirty && !PageSwapCache(page))
>   *freeable = true;
>  
>   /* Reclaim if clean, defer dirty pages to writeback */
> -- 
> 1.9.3
> 

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

Re: [PATCH 3/8] clk: Constify pointers to parent names in init data

2015-04-08 Thread Stephen Boyd

On 04/08/15 06:22, Krzysztof Kozlowski wrote:
> The 'parent_names' member of 'clk_init_data' is not modified so it can
> be made as an array of const pointers to constant strings.
>
> Some drivers (e.g. arch/mips/alchemy/common/clock.c) already pass such
> data.
>
> Signed-off-by: Krzysztof Kozlowski 
> ---

Sascha sent a similar patch a few days ago.

http://lkml.kernel.org/r/1427825817-26773-2-git-send-email-s.ha...@pengutronix.de


>  drivers/clk/clk-composite.c  |  2 +-
>  drivers/clk/clk-mux.c|  8 
>  include/linux/clk-provider.h | 12 ++--
>  3 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
> index 956b7e54fa1c..077f4c7148f1 100644
> --- a/drivers/clk/clk-composite.c
> +++ b/drivers/clk/clk-composite.c
> @@ -188,7 +188,7 @@ static void clk_composite_disable(struct clk_hw *hw)
>  }
>  
>  struct clk *clk_register_composite(struct device *dev, const char *name,
> - const char **parent_names, int num_parents,
> + const char * const *parent_names, int num_parents,
>   struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
>   struct clk_hw *rate_hw, const struct clk_ops *rate_ops,
>   struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
> diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
> index 69a094c3783d..962e2a056381 100644
> --- a/drivers/clk/clk-mux.c
> +++ b/drivers/clk/clk-mux.c
> @@ -114,8 +114,8 @@ const struct clk_ops clk_mux_ro_ops = {
>  EXPORT_SYMBOL_GPL(clk_mux_ro_ops);
>  
>  struct clk *clk_register_mux_table(struct device *dev, const char *name,
> - const char **parent_names, u8 num_parents, unsigned long flags,
> - void __iomem *reg, u8 shift, u32 mask,
> + const char * const *parent_names, u8 num_parents,
> + unsigned long flags, void __iomem *reg, u8 shift, u32 mask,
>   u8 clk_mux_flags, u32 *table, spinlock_t *lock)
>  {
>   struct clk_mux *mux;
> @@ -166,8 +166,8 @@ struct clk *clk_register_mux_table(struct device *dev, 
> const char *name,
>  EXPORT_SYMBOL_GPL(clk_register_mux_table);
>  
>  struct clk *clk_register_mux(struct device *dev, const char *name,
> - const char **parent_names, u8 num_parents, unsigned long flags,
> - void __iomem *reg, u8 shift, u8 width,
> + const char * const *parent_names, u8 num_parents,
> + unsigned long flags, void __iomem *reg, u8 shift, u8 width,
>   u8 clk_mux_flags, spinlock_t *lock)
>  {
>   u32 mask = BIT(width) - 1;
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 28abf1badb40..0bf0308963da 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -209,7 +209,7 @@ struct clk_ops {
>  struct clk_init_data {
>   const char  *name;
>   const struct clk_ops*ops;
> - const char  **parent_names;
> + const char * const  *parent_names;
>   u8  num_parents;
>   unsigned long   flags;
>  };
> @@ -426,13 +426,13 @@ extern const struct clk_ops clk_mux_ops;
>  extern const struct clk_ops clk_mux_ro_ops;
>  
>  struct clk *clk_register_mux(struct device *dev, const char *name,
> - const char **parent_names, u8 num_parents, unsigned long flags,
> - void __iomem *reg, u8 shift, u8 width,
> + const char * const *parent_names, u8 num_parents,
> + unsigned long flags, void __iomem *reg, u8 shift, u8 width,
>   u8 clk_mux_flags, spinlock_t *lock);
>  
>  struct clk *clk_register_mux_table(struct device *dev, const char *name,
> - const char **parent_names, u8 num_parents, unsigned long flags,
> - void __iomem *reg, u8 shift, u32 mask,
> + const char * const *parent_names, u8 num_parents,
> + unsigned long flags, void __iomem *reg, u8 shift, u32 mask,
>   u8 clk_mux_flags, u32 *table, spinlock_t *lock);
>  
>  void clk_unregister_mux(struct clk *clk);
> @@ -518,7 +518,7 @@ struct clk_composite {
>  };
>  
>  struct clk *clk_register_composite(struct device *dev, const char *name,
> - const char **parent_names, int num_parents,
> + const char * const *parent_names, int num_parents,
>   struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
>   struct clk_hw *rate_hw, const struct clk_ops *rate_ops,
>   struct clk_hw *gate_hw, const struct clk_ops *gate_ops,


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[PATCH 1/2] usb: Prefer firmware values when determining whether a port is removable

2015-04-08 Thread Matthew Garrett

Windows appears to pay more attention to the ACPI values than any hub
configuration, so prefer the firmware's opinion on whether a port is
fixed or removable before falling back to the hub values.

Signed-off-by: Matthew Garrett 
---
 drivers/usb/core/hub.c | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index d7c3d5a..ac33fdd 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2350,6 +2350,23 @@ static void set_usb_port_removable(struct usb_device 
*udev)
 
hub = usb_hub_to_struct_hub(udev->parent);
 
+   /*
+* If the platform firmware has provided information about a port,
+* use that to determine whether it's removable.
+*/
+   switch (hub->ports[udev->portnum - 1]->connect_type) {
+   case USB_PORT_CONNECT_TYPE_HOT_PLUG:
+   udev->removable = USB_DEVICE_REMOVABLE;
+   return;
+   case USB_PORT_CONNECT_TYPE_HARD_WIRED:
+   udev->removable = USB_DEVICE_FIXED;
+   return;
+   }
+
+   /*
+* Otherwise, check whether the hub knows whether a port is removable
+* or not
+*/
wHubCharacteristics = le16_to_cpu(hub->descriptor->wHubCharacteristics);
 
if (!(wHubCharacteristics & HUB_CHAR_COMPOUND))
@@ -2369,21 +2386,6 @@ static void set_usb_port_removable(struct usb_device 
*udev)
else
udev->removable = USB_DEVICE_FIXED;
 
-   /*
-* Platform firmware may have populated an alternative value for
-* removable.  If the parent port has a known connect_type use
-* that instead.
-*/
-   switch (hub->ports[udev->portnum - 1]->connect_type) {
-   case USB_PORT_CONNECT_TYPE_HOT_PLUG:
-   udev->removable = USB_DEVICE_REMOVABLE;
-   break;
-   case USB_PORT_CONNECT_TYPE_HARD_WIRED:
-   udev->removable = USB_DEVICE_FIXED;
-   break;
-   default: /* use what was set above */
-   break;
-   }
 }
 
 /**
-- 
2.3.4

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

[PATCH 2/2] usb: Set unused ports to "fixed" rather than "unknown"

2015-04-08 Thread Matthew Garrett

The Microsoft document "Using ACPI to Configure USB Ports on a Computer"
makes it clear that the removable flag will be cleared on ports that are
marked as unused by the firmware. Handle this case to match.

Signed-off-by: Matthew Garrett 
---
 drivers/usb/core/hub.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index ac33fdd..8166bcc 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2359,8 +2359,11 @@ static void set_usb_port_removable(struct usb_device 
*udev)
udev->removable = USB_DEVICE_REMOVABLE;
return;
case USB_PORT_CONNECT_TYPE_HARD_WIRED:
+   case USB_PORT_NOT_USED:
udev->removable = USB_DEVICE_FIXED;
return;
+   default:
+   break;
}
 
/*
-- 
2.3.4

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

Re: [PATCH v2] regulator: add a summary tree in debugfs

2015-04-08 Thread Heiko Stübner

Am Mittwoch, 8. April 2015, 18:38:25 schrieb Mark Brown:
> On Tue, Apr 07, 2015 at 04:16:39PM +0200, Heiko Stübner wrote:
> > - output current-limit for current regulators
> 
> What I meant here was that we should try to output the current limit for
> all regulators, not just for current regulators.  I've applied this as
> is though since it's basically OK, can you send a followup please?

ah I didn't know regulator_get_current_limit() was valid for non 
REGULATOR_CURRENT devices too.

Followup follows tomorrow - or today as I've just looked at the clock :-)


Heiko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: console=ttyS1 breaks ttyS1 termios and prevents me from logging in

2015-04-08 Thread Peter Hurley

On 04/08/2015 05:40 PM, Andy Lutomirski wrote:
> On Wed, Apr 8, 2015 at 2:29 PM, Peter Hurley  wrote:
>> Hi Andy,
>>
>> On 04/08/2015 05:17 PM, Andy Lutomirski wrote:
>>> Something strange seems to have happened to my serial console setup.
>>> I boot with console=ttyS1,115200n8 and I have a getty running on
>>> /dev/ttyS1.
>>>
>>> On older kernels, or if I remove the console= boot parameter, then my
>>> getty works fine.  On 3.19.3 with the console= parameter, something's
>>> wrong with termios and I can't log in.  Running:
>>
>> Thanks for the report.
>> 1. Please attach your dmesg.
>> 2. Is this behavior new to 3.19.3? (iow, what was the last version
>>that you noticed didn't do this)
> 
> I didn't have the problem before I reinstalled this box, upgraded from
> 3.15 to 3.19.3, and updated by Dell iDRAC7 firmware.  Booting into
> 3.13-something does *not* fix the problem, so I'm not at all convinced
> that the kernel version matters much.  I'll try reverting the iDRAC7
> thing, but I don't see why that would make any difference at all to
> Linux.

I think this is related to DRAC; maybe upgrading the firmware reset
the Serial communication settings in the system bios?

1. What's your getty command line?
2. Contents of /proc/tty/driver/serial when you think getty is running
   and waiting for login (shows line signals).

Something to test is if you set getty to local line, does it work then.
I use agetty so my command line is:
/sbin/getty --noreset -8L 115200 ttyS0 vt102

Regards,
Peter Hurley


> dmesg attached.  I don't even know what to look for there, though.
> 
>>
>> Regards,
>> Peter Hurley
>>
>>> # stty icanon >>
>>> breaks line this (partial strace results included):
>>>
>>> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
>>> TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
>>> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
>>> TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
>>> ioctl(0, SNDCTL_TMR_STOP or SNDRV_TIMER_IOCTL_GINFO or TCSETSW,
>>> {B115200 opost -isig icanon -echo ...}) = 0
>>> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
>>> TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
>>> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
>>> TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
>>> write(2, "stty: ", 6stty: )   = 6
>>> write(2, "standard input: unable to perfor"..., 58standard input:
>>> unable to perform all requested operations) = 58
>>>
>>> IOW, the setting didn't stick.  On the bad kernel, stty works just
>>> fine on ttyS0.  If I switch to using console=ttyS0,115200, then stty
>>> works on ttyS1 and fails on ttyS0.
>>>
>>> I have no idea what's going on here.  I have two apparently identical
>>> boxes.  One of them has this problem and the other doesn't.
>>
> 
> 
> 

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

Re: [PATCH v2 1/2] tty: serial: msm: Add mask value for UART_DM registers

2015-04-08 Thread Stephen Boyd

On 04/08/15 06:28, Pramod Gurav wrote:
> diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
> index b73889c..4c1e9ea 100644
> --- a/drivers/tty/serial/msm_serial.c
> +++ b/drivers/tty/serial/msm_serial.c
> @@ -432,8 +432,13 @@ static int msm_set_baud_rate(struct uart_port *port, 
> unsigned int baud)
>   /* RX stale watermark */
>   rxstale = entry->rxstale;
>   watermark = UART_IPR_STALE_LSB & rxstale;
> - watermark |= UART_IPR_RXSTALE_LAST;
> - watermark |= UART_IPR_STALE_TIMEOUT_MSB & (rxstale << 2);
> + if (msm_port->is_uartdm)
> + watermark |= UART_DM_IPR_STALE_TIMEOUT_MSB & (rxstale << 2);
> + else {
> + watermark |= UART_IPR_RXSTALE_LAST;
> + watermark |= UART_IPR_STALE_TIMEOUT_MSB & (rxstale << 2);
> + }
> +
>   msm_write(port, watermark, UART_IPR);
>  

This could be written like so:

if (msm_port->is_uartdm) {
mask = UART_DM_IPR_STALE_TIMEOUT_MSB;
} else {
watermark |= UART_IPR_RXSTALE_LAST;
mask = UART_IPR_STALE_TIMEOUT_MSB;
}

watermark |= mask & (rxstale << 2);

so that we don't duplicate the rfr_level << 2 part.

>   /* set RX watermark */
> @@ -496,9 +501,15 @@ static int msm_startup(struct uart_port *port)
>  
>   /* set automatic RFR level */
>   data = msm_read(port, UART_MR1);
> - data &= ~UART_MR1_AUTO_RFR_LEVEL1;
> + if (msm_port->is_uartdm) {
> + data &= ~UART_DM_MR1_AUTO_RFR_LEVEL1;
> + data |= UART_DM_MR1_AUTO_RFR_LEVEL1 & (rfr_level << 2);
> + } else {
> + data &= ~UART_MR1_AUTO_RFR_LEVEL1;
> + data |= UART_MR1_AUTO_RFR_LEVEL1 & (rfr_level << 2);
> + }
> +
>   data &= ~UART_MR1_AUTO_RFR_LEVEL0;
> - data |= UART_MR1_AUTO_RFR_LEVEL1 & (rfr_level << 2);
>   data |= UART_MR1_AUTO_RFR_LEVEL0 & rfr_level;
>   msm_write(port, data, UART_MR1);
>   return 0;

This could be written like so:

if (msm_port->is_uartdm)
mask = UART_DM_MR1_AUTO_RFR_LEVEL1;
else
mask = UART_MR1_AUTO_RFR_LEVE1;

data &= ~mask;
data &= ~UART_MR1_AUTO_RFR_LEVEL0;
data |= mask & (rfr_level << 2);
data |= UART_MR1_AUTO_RFR_LEVEL0 & rfr_level;

so that we don't duplicate the rfr_level << 2 part.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] xtensa: Fix fix linker script transformation for .text / .text.fixup

2015-04-08 Thread Chris Zankel

On Wed, Apr 8, 2015 at 6:08 AM, Guenter Roeck  wrote:
> On 04/07/2015 11:14 PM, Max Filippov wrote:
>>> Linker script transformation needs to be updated to detect and handle
>>> the new section.
>> I've posted a patch for it to the linux-xtensa ML a while ago:
>> http://lists.linux-xtensa.org/pipermail/linux-xtensa/Week-of-Mon-20150330/001913.html
>> This doesn't handle literals for .text.fixup AFAICT.
>>
> It doesn't, but then it wasn't supposed to. .text.fixup is arm specific.
>
> Guenter

Hi Max,

It would seem Guenter's fix addresses the issue. Are there any additional
benefits in your patch (better localized code, etc.?)

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

[PATCH] (gpio-fan): Move the thermal registration after registration is complete

Thermal framework may already be ready and cooling policies might
already be functional when we are attempting to register gpio fan as
a cooling device. This can be reproduced by changing probe order in
which registration of various modules are done in a system. In such
a case, kernel generates an oops since the data structures are not
completely populated with the wrong assumption that thermal framework
is not yet ready. Fix this by reordering the thermal framework
registration to occur after hwmon registration of the fan is complete.

Example kernel oops:
[  149.005828] Unable to handle kernel NULL pointer dereference at virtual 
address 008c
[  149.014369] pgd = ecf48000
[  149.017204] [008c] *pgd=ac065831, *pte=, *ppte=
[  149.023820] Internal error: Oops: 17 [#1] SMP ARM
[  149.028745] Modules linked in: gpio_fan(+) cpufreq_dt ipv6 evdev leds_gpio 
led_class omap_wdt phy_omap_usb2 rtc_palmas palmas_pwrbutton tmp102 
ti_soc_thermal dwc3_omap thermal_sys extcon rtc_omap rtc_ds1307 hwmon
[  149.048629] CPU: 1 PID: 1183 Comm: modprobe Not tainted 
4.0.0-rc7-next-20150407-2-g7a82da074c99 #3
[  149.058383] Hardware name: Generic DRA74X (Flattened Device Tree)
[  149.064763] task: edec1240 ti: ec0e task.ti: ec0e
[  149.070421] PC is at dev_driver_string+0x0/0x38
[  149.075165] LR is at __dev_printk+0x24/0x70
[  149.079540] pc : []lr : []psr: 2013
[  149.079540] sp : ec0e1c28  ip : edec1240  fp : 
[  149.091568] r10: edf3eee0  r9 :   r8 : 
[  149.097040] r7 : edf3eea0  r6 : 0034  r5 : 0010  r4 : ec0e1c44
[  149.103871] r3 : ec0e1c4c  r2 : ec0e1c44  r1 : c079d800  r0 : 0010
[  149.110709] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[  149.118182] Control: 10c5387d  Table: acf4806a  DAC: 0015
[  149.124198] Process modprobe (pid: 1183, stack limit = 0xec0e0218)
[  149.130673] Stack: (0xec0e1c28 to 0xec0e2000)
[  149.135235] 1c20:   6013 c05e2ae0  edf3ec00 
ec934a10 c03d73d4
...
[  149.392230] 1fe0: befe1888 befe1878 00019418 b6ea08f0 8010 0003 
 
[  149.400798] [] (dev_driver_string) from [] 
(__dev_printk+0x24/0x70)
[  149.409193] [] (__dev_printk) from [] 
(dev_warn+0x34/0x48)
[  149.416767] [] (dev_warn) from [] 
(get_fan_speed_index+0x94/0xa4 [gpio_fan])
[  149.425980] [] (get_fan_speed_index [gpio_fan]) from [] 
(gpio_fan_get_cur_state+0x18/0x30 [gpio_fan])
[  149.437476] [] (gpio_fan_get_cur_state [gpio_fan]) from 
[] (thermal_zone_trip_update+0xe8/0x2a4 [thermal_sys])
[  149.449794] [] (thermal_zone_trip_update [thermal_sys]) from 
[] (step_wise_throttle+0xc/0x74 [thermal_sys])
[  149.461832] [] (step_wise_throttle [thermal_sys]) from 
[] (handle_thermal_trip+0x5c/0x188 [thermal_sys])
[  149.473603] [] (handle_thermal_trip [thermal_sys]) from 
[] (thermal_zone_device_update+0x94/0x108 [thermal_sys])
[  149.486104] [] (thermal_zone_device_update [thermal_sys]) from 
[] (__thermal_cooling_device_register+0x2e8/0x374 [thermal_sys])
[  149.499956] [] (__thermal_cooling_device_register [thermal_sys]) 
from [] (gpio_fan_probe+0x350/0x4d0 [gpio_fan])
[  149.512438] [] (gpio_fan_probe [gpio_fan]) from [] 
(platform_drv_probe+0x48/0x98)
[  149.522109] [] (platform_drv_probe) from [] 
(driver_probe_device+0x1b0/0x26c)
[  149.531399] [] (driver_probe_device) from [] 
(__driver_attach+0x94/0x98)
[  149.540238] [] (__driver_attach) from [] 
(bus_for_each_dev+0x54/0x88)
[  149.548814] [] (bus_for_each_dev) from [] 
(bus_add_driver+0xdc/0x1d4)
[  149.557381] [] (bus_add_driver) from [] 
(driver_register+0x78/0xf4)
[  149.565765] [] (driver_register) from [] 
(do_one_initcall+0x80/0x1d8)
[  149.574340] [] (do_one_initcall) from [] 
(do_init_module+0x5c/0x1b8)
[  149.582833] [] (do_init_module) from [] 
(load_module+0x1720/0x1dcc)
[  149.591212] [] (load_module) from [] 
(SyS_finit_module+0x68/0x6c)
[  149.599418] [] (SyS_finit_module) from [] 
(ret_fast_syscall+0x0/0x4c)
[  149.607994] Code: 1583 e1a6 e28dd008 e8bd8070 (e590307c)

Cc: Eduardo Valentin 

Fixes: b5cf88e46bad ("(gpio-fan): Add thermal control hooks")
Signed-off-by: Nishanth Menon 
---

Reproduced on next-20150407 tag.

 drivers/hwmon/gpio-fan.c |   19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/hwmon/gpio-fan.c b/drivers/hwmon/gpio-fan.c
index 632b8e3ff5bf..a3dae6d0082a 100644
--- a/drivers/hwmon/gpio-fan.c
+++ b/drivers/hwmon/gpio-fan.c
@@ -563,18 +563,10 @@ static int gpio_fan_probe(struct platform_device *pdev)
err = gpio_fan_get_of_pdata(>dev, pdata);
if (err)
return err;
-   /* Optional cooling device register for Device tree platforms */
-   fan_data->cdev =
-   thermal_of_cooling_device_register(pdev->dev.of_node,
-  "gpio-fan", fan_data,
-

[PATCH] staging: lustre: llite: remove obsolete conditional code

2015-04-08 Thread Andreas Dilger

Remove conditional flock/aops code that was only for out-of-tree
vendor kernels but is not relevant for in-kernel code.

Signed-off-by: Andreas Dilger 
---
 drivers/staging/lustre/lustre/llite/llite_internal.h |  4 
 drivers/staging/lustre/lustre/llite/llite_lib.c  |  8 
 drivers/staging/lustre/lustre/llite/rw26.c   | 20 
 3 files changed, 32 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/llite_internal.h 
b/drivers/staging/lustre/lustre/llite/llite_internal.h
index 37306e0..1d4b2eb 100644
--- a/drivers/staging/lustre/lustre/llite/llite_internal.h
+++ b/drivers/staging/lustre/lustre/llite/llite_internal.h
@@ -727,11 +727,7 @@ int ll_readahead(const struct lu_env *env, struct cl_io 
*io,
 struct ll_readahead_state *ras, struct address_space *mapping,
 struct cl_page_list *queue, int flags);
 
-#ifndef MS_HAS_NEW_AOPS
 extern const struct address_space_operations ll_aops;
-#else
-extern const struct address_space_operations_ext ll_aops;
-#endif
 
 /* llite/file.c */
 extern struct file_operations ll_file_operations;
diff --git a/drivers/staging/lustre/lustre/llite/llite_lib.c 
b/drivers/staging/lustre/lustre/llite/llite_lib.c
index a3367bf..8327ad6 100644
--- a/drivers/staging/lustre/lustre/llite/llite_lib.c
+++ b/drivers/staging/lustre/lustre/llite/llite_lib.c
@@ -228,14 +228,6 @@ static int client_common_fill_super(struct super_block 
*sb, char *md, char *dt,
if (sbi->ll_flags & LL_SBI_USER_XATTR)
data->ocd_connect_flags |= OBD_CONNECT_XATTR;
 
-#ifdef HAVE_MS_FLOCK_LOCK
-   /* force vfs to use lustre handler for flock() calls - bug 10743 */
-   sb->s_flags |= MS_FLOCK_LOCK;
-#endif
-#ifdef MS_HAS_NEW_AOPS
-   sb->s_flags |= MS_HAS_NEW_AOPS;
-#endif
-
if (sbi->ll_flags & LL_SBI_FLOCK)
sbi->ll_fop = _file_operations_flock;
else if (sbi->ll_flags & LL_SBI_LOCALFLOCK)
diff --git a/drivers/staging/lustre/lustre/llite/rw26.c 
b/drivers/staging/lustre/lustre/llite/rw26.c
index 2f21304..5d8bdfd 100644
--- a/drivers/staging/lustre/lustre/llite/rw26.c
+++ b/drivers/staging/lustre/lustre/llite/rw26.c
@@ -517,7 +517,6 @@ static int ll_migratepage(struct address_space *mapping,
 }
 #endif
 
-#ifndef MS_HAS_NEW_AOPS
 const struct address_space_operations ll_aops = {
.readpage   = ll_readpage,
.direct_IO  = ll_direct_IO_26,
@@ -532,22 +531,3 @@ const struct address_space_operations ll_aops = {
.migratepage= ll_migratepage,
 #endif
 };
-#else
-const struct address_space_operations_ext ll_aops = {
-   .orig_aops.readpage   = ll_readpage,
-/* .orig_aops.readpages  = ll_readpages, */
-   .orig_aops.direct_IO  = ll_direct_IO_26,
-   .orig_aops.writepage  = ll_writepage,
-   .orig_aops.writepages = ll_writepages,
-   .orig_aops.set_page_dirty = ll_set_page_dirty,
-   .orig_aops.prepare_write  = ll_prepare_write,
-   .orig_aops.commit_write   = ll_commit_write,
-   .orig_aops.invalidatepage = ll_invalidatepage,
-   .orig_aops.releasepage= ll_releasepage,
-#ifdef CONFIG_MIGRATION
-   .orig_aops.migratepage= ll_migratepage,
-#endif
-   .write_begin= ll_write_begin,
-   .write_end  = ll_write_end
-};
-#endif
-- 
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: [E1000-devel] [PATCH v3 3/3] ixgbe: Add new ndo to allow VF multicast promiscuous mode

2015-04-08 Thread Hiroshi Shimamoto

> Subject: Re: [E1000-devel] [PATCH v3 3/3] ixgbe: Add new ndo to allow VF 
> multicast promiscuous mode
> 
> On Wed, 2015-04-08 at 15:15 -0700, Alexander Duyck wrote:
> > On 04/07/2015 10:38 PM, Hiroshi Shimamoto wrote:
> > > From: Hiroshi Shimamoto 
> > >
> > > Implements the new netdev op to allow VF multicast promiscuous mode.
> > >
> > > The multicast promiscuous mode is not allowed for all VFs by default.
> > >
> > > The administrator can allow to VF multicast promiscuous mode for only
> > > trusted VM. After allowing multicast promiscuous mode from the host,
> > > we can use over 30 IPv6 addresses on VM.
> > >  # ip link set dev eth0 vf 1 mc_promisc on
> > >
> > > When disallowing multicast promiscuous mode, ixgbevf can only handle 30
> > > IPv6 addresses at most.
> > >  # ip link set dev eth0 vf 1 mc_promisc off
> > >
> > > Signed-off-by: Hiroshi Shimamoto 
> > > Reviewed-by: Hayato Momma 
> > > CC: Choi, Sy Jong 
> > > ---
> > >  drivers/net/ethernet/intel/ixgbe/ixgbe.h   |  1 +
> > >  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c  |  7 ++
> > >  drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 32 
> > > --
> > >  drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h |  2 ++
> > >  4 files changed, 40 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h 
> > > b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
> > > index 08e65b6..4a9f74d 100644
> > > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
> > > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
> > > @@ -153,6 +153,7 @@ struct vf_data_storage {
> > >   u16 vlan_count;
> > >   u8 spoofchk_enabled;
> > >   bool rss_query_enabled;
> > > + u8 mc_promisc_allowed;
> > >   unsigned int vf_api;
> > >  };
> > >
> > > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 
> > > b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > > index 2f41403..c0e07c5 100644
> > > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > > @@ -3663,6 +3663,12 @@ static void ixgbe_configure_virtualization(struct 
> > > ixgbe_adapter *adapter)
> > >   ixgbe_ndo_set_vf_rss_query_en(adapter->netdev, i,
> > > 
> > > adapter->vfinfo[i].rss_query_enabled);
> > >   }
> > > +
> > > + /* Reconfigure multicast promiscuous mode */
> > > + for (i = 0; i < adapter->num_vfs; i++) {
> > > + ixgbe_ndo_set_vf_mc_promisc(adapter->netdev, i,
> > > + adapter->vfinfo[i].mc_promisc_allowed);
> > > + }
> > >  }
> > >
> > >  static void ixgbe_set_rx_buffer_len(struct ixgbe_adapter *adapter)
> >
> > This doesn't need to be a separate loop.  You can push it up into the
> > block above since it is already looping through all VFs.
> >
> > Once that is fixed the rest of this patch and the other two looked fine
> > to me.
> 
> Hiroshi I am dropping this series and will await v4.
> 
> Remember to send them to intel-wired-lan mailing list, please.

yep, will do.

thanks,
Hiroshi

Re: [Bugfix v3] x86/PCI/ACPI: Fix regression caused by commit 63f1789ec716

On Wednesday, April 08, 2015 01:48:46 PM Jiang Liu wrote:
> On 2015/4/7 8:28, Rafael J. Wysocki wrote:
> > On Friday, April 03, 2015 10:04:11 PM Bjorn Helgaas wrote:
> >> Hi Jiang,
> 
> >>> Currently acpi_dev_filter_resource_type() is only used by ACPI pci
> >>> host bridge and IOAPIC driver, so it shouldn't affect other drivers.
> >>
> >> We should assume it will eventually be used for all ACPI devices,
> >> shouldn't we?
> > 
> > I'm not sure about that, really.  In fact, I'd restrict its use to devices
> > types that actually can "produce" resources (ie. do not require the 
> > resources
> > to be provided by their ancestors or to be available from a global pool).
> > 
> > Otherwise we're pretty much guaranteed to get into trouble.
> > 
> > And all of the above rules need to be documented in the kernel source tree
> > or people will get confused.
> Hi Rafael,
> How about following comments for acpi_dev_filter_resource_type()?
> Thanks!
> Gerry
> 
> /**
>  * According to ACPI specifications, Consumer/Producer flag in ACPI resource
>  * descriptor means:
>  *  1(CONSUMER): This device consumes this resource
>  *  0(PRODUCER): This device produces and consumes this resource
>  * But for ACPI PCI host bridge, it is interpreted in another way:

So first of all, this leads to a question: Why is it interpreted for ACPI PCI
host bridges differently?

Is it something we've figured out from experience, or is there a standard
mandating that? 

>  *  1(CONSUMER): PCI host bridge itself consumes the resource, such as
>  *   IOPORT 0xCF8-0xCFF to access PCI configuraiton space.
>  *  0(PRODUCER): PCI host bridge provides this resource to its child
>  *   bus and devices.
>  *
>  * So this is a specially designed helper function to support ACPI PCI host
>  * bridge and ACPI IOAPIC, and its usage should be limited to those specific

And this will make the reader wonder why the IOAPIC should be treated the same
way as a PCI host bridge in that respect.

>  * scenarioso only. It filters ACPI resource descriptors as below:
>  * 1) If flag IORESOURCE_WINDOW is not specified, it's querying resources
>  *consumed by device. That is to return:
>  *  a) ACPI resources without producer_consumer flag
>  *  b) ACPI resources with producer_consumer flag setting to CONSUMER.
>  * 2) If flag IORESOURCE_WINDOW is specified, it's querying resources
> provided
>  *by device. That is to return:
>  *  a) ACPI resources with producer_consumer flag setting to PRODUCER.
>  * 3) But there's an exception. Some platforms, such as PC Engines APU.1C,
>  *report PCI host bridge resource provision by Memory32Fixed().
>  *Please refer to https://bugzilla.kernel.org/show_bug.cgi?id=94221
>  *So a special flag IORESOURCE_MEM_8AND16BIT is used to work around this
>  *BIOS issue.
>  */
> 
> > 
> >>> Another possible fix is to only ignore IO resource consumed by host
> >>> bridge and keep IOMEM resource consumed by host bridge, please refer to:
> >>> http://www.spinics.net/lists/linux-pci/msg39706.html
> >>>
> >>> Sample ACPI table are archived at:
> >>> https://bugzilla.kernel.org/show_bug.cgi?id=94221
> >>>
> >>> V2->V3:
> >>> Refine function acpi_dev_match_producer_consumer() as suggested by Rafael
> >>>
> >>> Fixes: 63f1789ec716("Ignore resources consumed by host bridge itself")
> >>> Reported-and-Tested-by: Bernhard Thaler 
> >>> Signed-off-by: Jiang Liu 
> >>> ---
> >>>  arch/x86/pci/acpi.c |5 ++---
> >>>  drivers/acpi/resource.c |   33 +
> >>>  2 files changed, 31 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> >>> index e4695985f9de..8c4b1201f340 100644
> >>> --- a/arch/x86/pci/acpi.c
> >>> +++ b/arch/x86/pci/acpi.c
> >>> @@ -337,7 +337,7 @@ static void probe_pci_root_info(struct pci_root_info 
> >>> *info,
> >>>   info->bridge = device;
> >>>   ret = acpi_dev_get_resources(device, list,
> >>>acpi_dev_filter_resource_type_cb,
> >>> -  (void *)(IORESOURCE_IO | IORESOURCE_MEM));
> >>> +  (void *)(IORESOURCE_IO | IORESOURCE_MEM | 
> >>> IORESOURCE_WINDOW));
> >>>   if (ret < 0)
> >>>   dev_warn(>dev,
> >>>"failed to parse _CRS method, error code %d\n", ret);
> >>> @@ -346,8 +346,7 @@ static void probe_pci_root_info(struct pci_root_info 
> >>> *info,
> >>>   "no IO and memory resources present in _CRS\n");
> >>>   else
> >>>   resource_list_for_each_entry_safe(entry, tmp, list) {
> >>> - if ((entry->res->flags & IORESOURCE_WINDOW) == 0 ||
> >>> - (entry->res->flags & IORESOURCE_DISABLED))
> >>> + if (entry->res->flags & IORESOURCE_DISABLED)
> >>>   resource_list_destroy_entry(entry);
> >>>

Re: [PATCH 0/6] staging: fsl-mc: cleanup and minor corrections

2015-04-08 Thread Alexander Graf


On 03/27/2015 10:01 PM, J. German Rivera wrote:

This patch series includes some cleanup/refactoring and minor correction
patches for the Freescale fsl-mc bus driver.

Patch 1: Name MC object devices using decimal numbers
Patch 2: Removed reordering of MC objects during bus scan
Patch 3: Bind/unbind driver when MC object is plugged/unplugged
Patch 4: Fix crash in fsl_mc_device_remove()
Patch 5: Refactored fsl_mc_object_allocator driver init/exit
Patch 6: Changed version matching rules for MC object drivers



Acked-by: Alexander Graf 


Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: about the flood of trivial patches and the Code of Conduct (was: Re: [PATCH 19/25] sched: Use bool function return values of true/false not 1/0)