Re: [PATCH 1/3] kernel/sched: introduce vcpu preempted check interface

[Heiko Carstens]

On Mon, Jun 27, 2016 at 04:00:43PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 27, 2016 at 01:41:28PM -0400, Pan Xinhui wrote:
> > +++ b/include/linux/sched.h
> > @@ -3293,6 +3293,15 @@ static inline void set_task_cpu(struct task_struct 
> > *p, unsigned int cpu)
> >  
> >  #endif /* CONFIG_SMP */
> >  
> > +#ifdef arch_vcpu_is_preempted
> > +static inline bool vcpu_is_preempted(int cpu)
> > +{
> > +   return arch_vcpu_is_preempted(cpu);
> > +}
> > +#else
> > +#define vcpu_is_preempted(cpu) false
> > +#endif
> 
> #ifndef vcpu_is_preempted
> #define vcpu_is_preempted(cpu)(false)
> #endif
> 
> Is so much simpler...
> 
> Also, please Cc the virt list so that other interested parties can
> comment, and maybe also the s390 folks.

The s390 implementation would be to simply use cpu_is_preempted() from
arch/s390/lib/spinlock.c.
It's nice that there will be a common code function for this!

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: arch/powerpc/xmon/dis-asm.h: 2 * wrong specifiers ?

[Segher Boessenkool]

On Tue, Jun 28, 2016 at 08:06:56AM +0100, David Binderman wrote:
> I think you can also get a similar warning if you tweek the gcc compiler 
> warning
> flags. -Wformat=2 maybe.

-Wformat=1 (which is enabled by -Wall) already warns for this.

warning: format '%x' expects argument of type 'unsigned int', but argument 2 
has type 'long unsigned int' [-Wformat=]


Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: arch/powerpc/xmon/dis-asm.h: 2 * wrong specifiers ?

[David Binderman]

Hello there,

On Tue, Jun 28, 2016 at 5:08 AM, Michael Ellerman  wrote:
> What config / toolchain are you using? I've never seen these.

A static analyser for C & C++ called cppcheck. Available from sourceforge.

I think you can also get a similar warning if you tweek the gcc compiler warning
flags. -Wformat=2 maybe.

>> static inline int print_insn_powerpc(unsigned long insn, unsigned long 
>> memaddr)
>> {
>> printf("%.8x", insn);
>> return 0;
>> }
>
> Send me a patch to cast insn to unsigned int?

I don't know the code, but given that insn is unsigned long and so can go
past 32 bits, using a cast to unsigned int might throw away the
possibly important
upper bits.


Regards

David Binderman
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: arch/powerpc/xmon/dis-asm.h: 2 * wrong specifiers ?

[Michael Ellerman]

On Tue, 2016-06-28 at 08:06 +0100, David Binderman wrote:
> On Tue, Jun 28, 2016 at 5:08 AM, Michael Ellerman  wrote:
> > What config / toolchain are you using? I've never seen these.
> 
> A static analyser for C & C++ called cppcheck. Available from sourceforge.
> 
> I think you can also get a similar warning if you tweek the gcc compiler 
> warning
> flags. -Wformat=2 maybe.
 
Ah OK. I've heard of it.

> > > static inline int print_insn_powerpc(unsigned long insn, unsigned long 
> > > memaddr)
> > > {
> > > printf("%.8x", insn);
> > > return 0;
> > > }
> > 
> > Send me a patch to cast insn to unsigned int?
> 
> I don't know the code, but given that insn is unsigned long and so can go
> past 32 bits, using a cast to unsigned int might throw away the
> possibly important upper bits.

powerpc instructions are always 32-bit.

We could change the signature for the function to take u32. Except it's the
fallback implementation for the real version which comes from binutils and we'd
prefer to keep that code the same as the binutils version.

cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/mm: Use VM_WARN_ONCE() for irqs disabled check

[Michael Ellerman]

The check for !arch_irqs_disabled() in find_linux_pte_or_hugepte() is a
debugging aid, and needn't be enabled for production builds.

Switch it to a VM_WARN_ONCE(), which is compiled out when
CONFIG_DEBUG_VM=n.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/pgtable.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/pgtable.h 
b/arch/powerpc/include/asm/pgtable.h
index ee09e99097f0..651848039dc4 100644
--- a/arch/powerpc/include/asm/pgtable.h
+++ b/arch/powerpc/include/asm/pgtable.h
@@ -71,10 +71,8 @@ pte_t *__find_linux_pte_or_hugepte(pgd_t *pgdir, unsigned 
long ea,
 static inline pte_t *find_linux_pte_or_hugepte(pgd_t *pgdir, unsigned long ea,
   bool *is_thp, unsigned *shift)
 {
-   if (!arch_irqs_disabled()) {
-   pr_info("%s called with irq enabled\n", __func__);
-   dump_stack();
-   }
+   VM_WARN_ONCE(!arch_irqs_disabled(),
+"find_linux_pte_or_hugepte() called with irqs enabled!\n");
return __find_linux_pte_or_hugepte(pgdir, ea, is_thp, shift);
 }
 
-- 
2.5.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RESEND, v7, 2/2] cxl: Add set and get private data to context struct

[Michael Ellerman]

On Fri, 2016-24-06 at 06:47:07 UTC, Philippe Bergheaud wrote:
> From: Michael Neuling 
> 
> This provides AFU drivers a means to associate private data with a cxl
> context. This is particularly intended for make the new callbacks for
> driver specific events easier for AFU drivers to use, as they can easily
> get back to any private data structures they may use.
> 
> Signed-off-by: Michael Neuling 
> Signed-off-by: Ian Munsie 
> Signed-off-by: Philippe Bergheaud  Reviewed-by: Matthew R. Ochs 
> Reviewed-by: Andrew Donnellan 
> ---
> No changes since v1. Added Matt Ochs reviewed-by tag.

I'm not sure why this is RESEND ?

Does this pair with [v7 1/2] ?

  https://patchwork.ozlabs.org/patch/639644/

It's a lot simpler if you just resend the whole series each time there is an
update to any patch.

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v5] tools/perf: Fix the mask in regs_dump__printf and print_sample_iregs

[Jiri Olsa]

On Thu, Jun 23, 2016 at 11:19:27AM +0530, Madhavan Srinivasan wrote:

SNIP

> 
> Changelog v1:
> 1)updated commit message and patch subject
> 2)Add the fix to print_sample_iregs() in builtin-script.c
> 
>  tools/include/linux/bitmap.h |  2 ++
>  tools/lib/bitmap.c   | 18 ++
>  tools/perf/builtin-script.c  |  4 +++-
>  tools/perf/util/session.c|  4 +++-
>  4 files changed, 26 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/include/linux/bitmap.h b/tools/include/linux/bitmap.h
> index 28f5493da491..5e98525387dc 100644
> --- a/tools/include/linux/bitmap.h
> +++ b/tools/include/linux/bitmap.h
> @@ -2,6 +2,7 @@
>  #define _PERF_BITOPS_H
>  
>  #include 
> +#include 

this could go in the bitmap.c file, but anyway:

Acked-by: Jiri Olsa 

thanks,
jirka

>  #include 
>  
>  #define DECLARE_BITMAP(name,bits) \
> @@ -10,6 +11,7 @@
>  int __bitmap_weight(const unsigned long *bitmap, int bits);
>  void __bitmap_or(unsigned long *dst, const unsigned long *bitmap1,
>const unsigned long *bitmap2, int bits);
> +void bitmap_from_u64(unsigned long *dst, u64 mask);
>  
>  #define BITMAP_FIRST_WORD_MASK(start) (~0UL << ((start) & (BITS_PER_LONG - 
> 1)))
>  

SNIP
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RESEND v7,2/2] cxl: Add set and get private data to context struct

[Andrew Donnellan]

On 24/06/16 16:47, Philippe Bergheaud wrote:

From: Michael Neuling 

This provides AFU drivers a means to associate private data with a cxl
context. This is particularly intended for make the new callbacks for
driver specific events easier for AFU drivers to use, as they can easily
get back to any private data structures they may use.

Signed-off-by: Michael Neuling 
Signed-off-by: Ian Munsie 
Signed-off-by: Philippe Bergheaud 


As per v3:

Reviewed-by: Andrew Donnellan 

--
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com  IBM Australia Limited

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RESEND, v7, 2/2] cxl: Add set and get private data to context struct

[Philippe Bergheaud]

Michael Ellerman wrote:

On Fri, 2016-24-06 at 06:47:07 UTC, Philippe Bergheaud wrote:


From: Michael Neuling 

This provides AFU drivers a means to associate private data with a cxl
context. This is particularly intended for make the new callbacks for
driver specific events easier for AFU drivers to use, as they can easily
get back to any private data structures they may use.

Signed-off-by: Michael Neuling 
Signed-off-by: Ian Munsie 
Signed-off-by: Philippe Bergheaud 
Reviewed-by: Andrew Donnellan 
---
No changes since v1. Added Matt Ochs reviewed-by tag.



I'm not sure why this is RESEND ?


Sorry. That was because I made a typo in the title (I typed v6 instead of v7).

Does this pair with [v7 1/2] ?


Yes it does.

  https://patchwork.ozlabs.org/patch/639644/

It's a lot simpler if you just resend the whole series each time there is an
update to any patch.


Got it, thank you.

Philippe

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/3] kernel/sched: introduce vcpu preempted check interface

[xinhui]

On 2016年06月28日 15:00, Heiko Carstens wrote:

On Mon, Jun 27, 2016 at 04:00:43PM +0200, Peter Zijlstra wrote:

On Mon, Jun 27, 2016 at 01:41:28PM -0400, Pan Xinhui wrote:

+++ b/include/linux/sched.h
@@ -3293,6 +3293,15 @@ static inline void set_task_cpu(struct task_struct *p, 
unsigned int cpu)

  #endif /* CONFIG_SMP */

+#ifdef arch_vcpu_is_preempted
+static inline bool vcpu_is_preempted(int cpu)
+{
+   return arch_vcpu_is_preempted(cpu);
+}
+#else
+#define vcpu_is_preempted(cpu) false
+#endif


#ifndef vcpu_is_preempted
#define vcpu_is_preempted(cpu)  (false)
#endif

Is so much simpler...

Also, please Cc the virt list so that other interested parties can
comment, and maybe also the s390 folks.


The s390 implementation would be to simply use cpu_is_preempted() from
arch/s390/lib/spinlock.c.

that's great.


It's nice that there will be a common code function for this!



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 4/4] kernel/locking: Drop the overload of {mutex, rwsem}_spin_on_owner

[Pan Xinhui]

An over-committed guest with more vCPUs than pCPUs has a heavy overload in
the two spin_on_owner. This blames on the lock holder preemption issue.

Kernel has an interface bool vcpu_is_preempted(int cpu) to see if a vCPU is
currently running or not. So break the spin loops on true condition.

test-case:
perf record -a perf bench sched messaging -g 400 -p && perf report

before patch:
20.68%  sched-messaging  [kernel.vmlinux]  [k] mutex_spin_on_owner
 8.45%  sched-messaging  [kernel.vmlinux]  [k] mutex_unlock
 4.12%  sched-messaging  [kernel.vmlinux]  [k] system_call
 3.01%  sched-messaging  [kernel.vmlinux]  [k] system_call_common
 2.83%  sched-messaging  [kernel.vmlinux]  [k] copypage_power7
 2.64%  sched-messaging  [kernel.vmlinux]  [k] rwsem_spin_on_owner
 2.00%  sched-messaging  [kernel.vmlinux]  [k] osq_lock

after patch:
 9.99%  sched-messaging  [kernel.vmlinux]  [k] mutex_unlock
 5.28%  sched-messaging  [unknown] [H] 0xc00768e0
 4.27%  sched-messaging  [kernel.vmlinux]  [k] __copy_tofrom_user_power7
 3.77%  sched-messaging  [kernel.vmlinux]  [k] copypage_power7
 3.24%  sched-messaging  [kernel.vmlinux]  [k] _raw_write_lock_irq
 3.02%  sched-messaging  [kernel.vmlinux]  [k] system_call
 2.69%  sched-messaging  [kernel.vmlinux]  [k] wait_consider_task

Signed-off-by: Pan Xinhui 
---
 kernel/locking/mutex.c  | 15 +--
 kernel/locking/rwsem-xadd.c | 16 +---
 2 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index 79d2d76..ef0451b2 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -236,7 +236,13 @@ bool mutex_spin_on_owner(struct mutex *lock, struct 
task_struct *owner)
 */
barrier();
 
-   if (!owner->on_cpu || need_resched()) {
+   /*
+* Use vcpu_is_preempted to detech lock holder preemption issue
+* and break. vcpu_is_preempted is a macro defined by false if
+* arch does not support vcpu preempted check,
+*/
+   if (!owner->on_cpu || need_resched() ||
+   vcpu_is_preempted(task_cpu(owner))) {
ret = false;
break;
}
@@ -261,8 +267,13 @@ static inline int mutex_can_spin_on_owner(struct mutex 
*lock)
 
rcu_read_lock();
owner = READ_ONCE(lock->owner);
+
+   /*
+* As lock holder preemption issue, we both skip spinning if task not
+* on cpu or its cpu is preempted
+*/
if (owner)
-   retval = owner->on_cpu;
+   retval = owner->on_cpu && !vcpu_is_preempted(task_cpu(owner));
rcu_read_unlock();
/*
 * if lock->owner is not set, the mutex owner may have just acquired
diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index 09e30c6..828ca7c 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b/kernel/locking/rwsem-xadd.c
@@ -319,7 +319,11 @@ static inline bool rwsem_can_spin_on_owner(struct 
rw_semaphore *sem)
goto done;
}
 
-   ret = owner->on_cpu;
+   /*
+* As lock holder preemption issue, we both skip spinning if task not
+* on cpu or its cpu is preempted
+*/
+   ret = owner->on_cpu && !vcpu_is_preempted(task_cpu(owner));
 done:
rcu_read_unlock();
return ret;
@@ -340,8 +344,14 @@ bool rwsem_spin_on_owner(struct rw_semaphore *sem, struct 
task_struct *owner)
 */
barrier();
 
-   /* abort spinning when need_resched or owner is not running */
-   if (!owner->on_cpu || need_resched()) {
+   /*
+* abort spinning when need_resched or owner is not running or
+* owner's cpu is preempted. vcpu_is_preempted is a macro
+* defined by false if arch does not support vcpu preempted
+* check
+*/
+   if (!owner->on_cpu || need_resched() ||
+   vcpu_is_preempted(task_cpu(owner))) {
rcu_read_unlock();
return false;
}
-- 
2.4.11

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/mm: update arch_{add,remove}_memory() for radix

[Michael Ellerman]

On Thu, 2016-06-23 at 14:37 -0500, Reza Arbab wrote:
> On Thu, Jun 23, 2016 at 10:47:20PM +0530, Aneesh Kumar K.V wrote:
> > Reza Arbab  writes:
> > > These functions are making direct calls to the hash table APIs,
> > > leading to a BUG() on systems using radix.
> > > 
> > > Switch them to the vmemmap_{create,remove}_mapping() wrappers, and
> > > move to the __meminit section.
> > 
> > They are really not the same. They can possibly end up using different
> > base page size. Also vmemmap is available only with SPARSEMEM_VMEMMAP
> > enabled. Does hotplug depend on sparsemem vmemmap ?
> 
> I'm not sure. Maybe it's best if I back up a step and explain what lead 
> me to this patch. During hotplug, you get
> 
> ...
>   arch_add_memory
>   create_section_mapping
>   htab_bolt_mapping
>   BUG_ON(!ppc_md.hpte_insert);
> 
> So it seemed to me that I needed a radix equivalent of 
> create_section_mapping().
> 
> After some digging, I found hash__vmemmap_create_mapping() and 
> radix__vmemmap_create_mapping() did what I needed. I did not notice the 
> #ifdef SPARSEMEM_VMEMMAP around them.

I think that's more by luck than design. The vmemmap routines use
mmu_vmemmap_psize which is probably but not definitely the same as
mmu_linear_psize.

> Could it be that the functions just need to be renamed 
> hash__create_mapping()/radix__create_mapping() and moved out of #ifdef 
> SPARSEMEM_VMEMMAP?

No, you need to use mmu_linear_psize for the hotplug case.

But you can probably factor out a common routine that both cases use, and hide
the hash vs radix check in that.

And probably send me a patch to make MEMORY_HOTPLUG depend on !RADIX for v4.7?

cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/4] perf: Utility function to fetch arch from evsel

[Ravi Bangoria]

Add Utility function to fetch 'arch' from 'evsel'. (evsel->env->arch)

Signed-off-by: Ravi Bangoria 
---
 tools/perf/util/evsel.c | 7 +++
 tools/perf/util/evsel.h | 2 ++
 2 files changed, 9 insertions(+)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 1d8f2bb..0fea724 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -2422,3 +2422,10 @@ int perf_evsel__open_strerror(struct perf_evsel *evsel, 
struct target *target,
 err, strerror_r(err, sbuf, sizeof(sbuf)),
 perf_evsel__name(evsel));
 }
+
+char *perf_evsel__env_arch(struct perf_evsel *evsel)
+{
+   if (evsel && evsel->evlist && evsel->evlist->env)
+   return evsel->evlist->env->arch;
+   return NULL;
+}
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index 828ddd1..86fed7a 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -435,4 +435,6 @@ typedef int (*attr__fprintf_f)(FILE *, const char *, const 
char *, void *);
 int perf_event_attr__fprintf(FILE *fp, struct perf_event_attr *attr,
 attr__fprintf_f attr__fprintf, void *priv);
 
+char *perf_evsel__env_arch(struct perf_evsel *evsel);
+
 #endif /* __PERF_EVSEL_H */
-- 
2.5.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 06/38] powerpc: Move 64-bit feature fixup earlier

[Aneesh Kumar K.V]

Benjamin Herrenschmidt  writes:

> On Tue, 2016-06-28 at 16:35 +0530, Aneesh Kumar K.V wrote:
>> Why not move it immediately after we finish all the device tress
>> scan.
>
> Do you need it in early_init_mmu ? The important thing is to have it
> done before we *turn on* the MMU but yeah, there's no big deal
> moving it even further up I think..

If we can do feature fixup early. Then this patch series become simpler.

https://lkml.kernel.org/r/1465887288-12952-1-git-send-email-aneesh.ku...@linux.vnet.ibm.com

ie, we can now start using cpu_has_feature/mmu_has_feature early instead
of using __cpu/mmu_has_feature.

>
>> ie,
>> early_init_devtree(__va(dt_ptr));
>> 
>> epapr_paravirt_early_init();
>> 
>>   +  apply_feature_fixups();
>> /* Now we know the logical id of our boot cpu, setup the
>> paca. */
>> setup_paca([boot_cpuid]);
>> fixup_boot_paca();
>> 
>> Also with a comment explaining why we can't move it further up ?
>
> Yup, adding some comments about the why things are done in that order
> would be good, I'll improve that
>
> Cheers,
> Ben.

-aneesh

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [V4, 2/3] powerpc/opal: Add #define to get rc from an ASYNC_COMP opal_msg

[Michael Ellerman]

On Tue, 2016-28-06 at 04:40:56 UTC, Suraj Jitindar Singh wrote:
> An opal_msg of type OPAL_MSG_ASYNC_COMP contains the return code in the
> params[1] struct member. However this isn't intuitive or obvious when
> reading the code and requires that a user look at the skiboot
> documentation or opal-api.h to verify this.
> 
> Add a #define to get the return code from an opal_msg and update call
> sites accordingly.

Thanks for cleaning this up.

Two gripes though :)

>  arch/powerpc/include/asm/opal-api.h| 4 

opal-api.h is supposed to be a subset of the skiboot version.

So something like this should go in the kernel's opal.h, which has all the
kernel prototypes etc. which aren't part of the OPAL API. I think this routine
should fall under that.

> diff --git a/arch/powerpc/include/asm/opal-api.h 
> b/arch/powerpc/include/asm/opal-api.h
> index 9bb8ddf..7433cf0 100644
> --- a/arch/powerpc/include/asm/opal-api.h
> +++ b/arch/powerpc/include/asm/opal-api.h
> @@ -387,6 +387,10 @@ struct opal_msg {
>   __be64 params[8];
>  };
>  
> +#define GET_OPAL_MSG_ASYNC_COMP_RC(msg)  (msg.msg_type == 
> OPAL_MSG_ASYNC_COMP ? \
> + be64_to_cpu(msg.params[1]) : \
> + OPAL_PARAMETER)
> +

You forgot the 7th commandment!

 "Never use a #define when a static inline would work"

:)

A few reasons:
  - it's less shouty.
  - you get type checking.
  - you don't have to wrap lines with \
etc.

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 2/4] powerpc/spinlock: support vcpu preempted check

[Pan Xinhui]

This is to fix some lock holder preemption issues. Some other locks
implementation do a spin loop before acquiring the lock itself. Currently
kernel has an interface of bool vcpu_is_preempted(int cpu). It take the cpu
as parameter and return true if the cpu is preempted. Then kernel can break
the spin loops upon on the retval of vcpu_is_preempted.

As kernel has used this interface, So lets support it.

Only pSeries need supoort it. And the fact is powerNV are built into same
kernel image with pSeries. So we need return false if we are runnig as
powerNV. The another fact is that lppaca->yiled_count keeps zero on
powerNV. So we can just skip the machine type.

Suggested-by: Boqun Feng 
Suggested-by: Peter Zijlstra (Intel) 
Signed-off-by: Pan Xinhui 
---
 arch/powerpc/include/asm/spinlock.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/powerpc/include/asm/spinlock.h 
b/arch/powerpc/include/asm/spinlock.h
index 523673d..3ac9fcb 100644
--- a/arch/powerpc/include/asm/spinlock.h
+++ b/arch/powerpc/include/asm/spinlock.h
@@ -52,6 +52,24 @@
 #define SYNC_IO
 #endif
 
+/*
+ * This support kernel to check if one cpu is preempted or not.
+ * Then we can fix some lock holder preemption issue.
+ */
+#ifdef CONFIG_PPC_PSERIES
+#define vcpu_is_preempted vcpu_is_preempted
+static inline bool vcpu_is_preempted(int cpu)
+{
+   /*
+* pSeries and powerNV can be built into same kernel image. In
+* principle we need return false directly if we are running as
+* powerNV. However the yield_count is always zero on powerNV, So
+* skip such machine type check
+*/
+   return !!(be32_to_cpu(lppaca_of(cpu).yield_count) & 1);
+}
+#endif
+
 static __always_inline int arch_spin_value_unlocked(arch_spinlock_t lock)
 {
return lock.slock == 0;
-- 
2.4.11

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Proposed: Patch to fix boot on PA6T

[Michael Ellerman]

Hi Darren,

On Sun, 2016-26-06 at 17:42:11 UTC, Darren Stevens wrote:
> Hello All,
> 
> commit d6a9996e84ac4beb7713e9485f4563e100a9b03e
> powerpc/mm: vmalloc abstraction in preparation for radix
> 
> This commit introduced variables for some linux kernel addresses that had 
> before
> been constants, unfortunately this stopped PaSemi PA6T systems(*) from  
> booting as
> they call ioremap to map SoC registers before the mmu is initialised. The 
> attached
> patch adds a hard-coded init of pci_io_base to the pas_init_early() 
> function which
> which allows the kernel to boot normally.
> 
> The value will be harmlessly set again once pci starts up.
> 
> (*) At the moment this has only been tested on an AmigaOneX1000, but I 
> expect PaSemi
> reference systems to have been affected in the same way.
> 
> Kind regards
> Darren

I can't merge this because you didn't sign it off.

See section 11 of:

  https://www.kernel.org/doc/Documentation/SubmittingPatches

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/mm: Use VM_WARN_ONCE() for irqs disabled check

[Michael Ellerman]

On Tue, 2016-06-28 at 16:15 +0530, Aneesh Kumar K.V wrote:
> Michael Ellerman  writes:
> > diff --git a/arch/powerpc/include/asm/pgtable.h 
> > b/arch/powerpc/include/asm/pgtable.h
> > index ee09e99097f0..651848039dc4 100644
> > --- a/arch/powerpc/include/asm/pgtable.h
> > +++ b/arch/powerpc/include/asm/pgtable.h
> > @@ -71,10 +71,8 @@ pte_t *__find_linux_pte_or_hugepte(pgd_t *pgdir, 
> > unsigned long ea,
> >  static inline pte_t *find_linux_pte_or_hugepte(pgd_t *pgdir, unsigned long 
> > ea,
> >bool *is_thp, unsigned *shift)
> >  {
> > -   if (!arch_irqs_disabled()) {
> > -   pr_info("%s called with irq enabled\n", __func__);
> > -   dump_stack();
> > -   }
> > +   VM_WARN_ONCE(!arch_irqs_disabled(),
> > +"find_linux_pte_or_hugepte() called with irqs enabled!\n");
> > return __find_linux_pte_or_hugepte(pgdir, ea, is_thp, shift);
> >  }
> > 
> 
> https://lkml.kernel.org/r/574de240.uG8/5OM2Lu9RY6K+%akpm@linux-foundation.orgdd
> 
> Isn't this patch already part of -mm.

Ugh, yes. I missed that you'd already sent it.

> And why ONCE, we want to find about all the wrong usage.

Sure, but if you hit it repeatedly in a common path you're likely to kill the
box just with console spam.

But I don't mind. Ignore this version.

cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 4/4] perf annotate: Define macro for arch names

[Ravi Bangoria]

Define macro for each arch name and use them instead of using arch
name as string.

Signed-off-by: Ravi Bangoria 
---
 tools/perf/arch/common.c   | 36 ++--
 tools/perf/arch/common.h   | 11 +++
 tools/perf/util/annotate.c | 10 +-
 tools/perf/util/unwind-libunwind.c |  4 ++--
 4 files changed, 36 insertions(+), 25 deletions(-)

diff --git a/tools/perf/arch/common.c b/tools/perf/arch/common.c
index ee69668..feb2113 100644
--- a/tools/perf/arch/common.c
+++ b/tools/perf/arch/common.c
@@ -122,25 +122,25 @@ static int lookup_triplets(const char *const *triplets, 
const char *name)
 const char *normalize_arch(char *arch)
 {
if (!strcmp(arch, "x86_64"))
-   return "x86";
+   return NORM_X86;
if (arch[0] == 'i' && arch[2] == '8' && arch[3] == '6')
-   return "x86";
+   return NORM_X86;
if (!strcmp(arch, "sun4u") || !strncmp(arch, "sparc", 5))
-   return "sparc";
+   return NORM_SPARC;
if (!strcmp(arch, "aarch64") || !strcmp(arch, "arm64"))
-   return "arm64";
+   return NORM_ARM64;
if (!strncmp(arch, "arm", 3) || !strcmp(arch, "sa110"))
-   return "arm";
+   return NORM_ARM;
if (!strncmp(arch, "s390", 4))
-   return "s390";
+   return NORM_S390;
if (!strncmp(arch, "parisc", 6))
-   return "parisc";
+   return NORM_PARISC;
if (!strncmp(arch, "powerpc", 7) || !strncmp(arch, "ppc", 3))
-   return "powerpc";
+   return NORM_POWERPC;
if (!strncmp(arch, "mips", 4))
-   return "mips";
+   return NORM_MIPS;
if (!strncmp(arch, "sh", 2) && isdigit(arch[2]))
-   return "sh";
+   return NORM_SH;
 
return arch;
 }
@@ -180,21 +180,21 @@ static int perf_env__lookup_binutils_path(struct perf_env 
*env,
zfree();
}
 
-   if (!strcmp(arch, "arm"))
+   if (!strcmp(arch, NORM_ARM))
path_list = arm_triplets;
-   else if (!strcmp(arch, "arm64"))
+   else if (!strcmp(arch, NORM_ARM64))
path_list = arm64_triplets;
-   else if (!strcmp(arch, "powerpc"))
+   else if (!strcmp(arch, NORM_POWERPC))
path_list = powerpc_triplets;
-   else if (!strcmp(arch, "sh"))
+   else if (!strcmp(arch, NORM_SH))
path_list = sh_triplets;
-   else if (!strcmp(arch, "s390"))
+   else if (!strcmp(arch, NORM_S390))
path_list = s390_triplets;
-   else if (!strcmp(arch, "sparc"))
+   else if (!strcmp(arch, NORM_SPARC))
path_list = sparc_triplets;
-   else if (!strcmp(arch, "x86"))
+   else if (!strcmp(arch, NORM_X86))
path_list = x86_triplets;
-   else if (!strcmp(arch, "mips"))
+   else if (!strcmp(arch, NORM_MIPS))
path_list = mips_triplets;
else {
ui__error("binutils for %s not supported.\n", arch);
diff --git a/tools/perf/arch/common.h b/tools/perf/arch/common.h
index 6b01c73..14ca8ca 100644
--- a/tools/perf/arch/common.h
+++ b/tools/perf/arch/common.h
@@ -5,6 +5,17 @@
 
 extern const char *objdump_path;
 
+/* Macro for normalized arch names */
+#define NORM_X86   "x86"
+#define NORM_SPARC "sparc"
+#define NORM_ARM64 "arm64"
+#define NORM_ARM   "arm"
+#define NORM_S390  "s390"
+#define NORM_PARISC"parisc"
+#define NORM_POWERPC   "powerpc"
+#define NORM_MIPS  "mips"
+#define NORM_SH"sh"
+
 int perf_env__lookup_objdump(struct perf_env *env);
 const char *normalize_arch(char *arch);
 
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 96c6610..8146a25 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -68,7 +68,7 @@ static int call__parse(struct ins_operands *ops,
 
name++;
 
-   if (!strcmp(norm_arch, "arm") && strchr(name, '+'))
+   if (!strcmp(norm_arch, NORM_ARM) && strchr(name, '+'))
return -1;
 
tok = strchr(name, '>');
@@ -255,7 +255,7 @@ static int mov__parse(struct ins_operands *ops,
 
target = ++s;
 
-   if (!strcmp(norm_arch, "arm"))
+   if (!strcmp(norm_arch, NORM_ARM))
comment = strchr(s, ';');
else
comment = strchr(s, '#');
@@ -567,13 +567,13 @@ static struct ins *ins__find(const char *name, const char 
*norm_arch)
sorted = true;
}
 
-   if (!strcmp(norm_arch, "x86")) {
+   if (!strcmp(norm_arch, NORM_X86)) {
instructions = instructions_x86;
nmemb = ARRAY_SIZE(instructions_x86);
-   } else if (!strcmp(norm_arch, "arm")) {
+   } else if (!strcmp(norm_arch, NORM_ARM)) {
instructions = instructions_arm;

[PATCH 3/4] perf annotate: add powerpc support

[Ravi Bangoria]

From: "Naveen N. Rao" 

Powerpc has long list of branch instructions and hardcoding them in table
appears to be error-prone. So, add new function to find instruction
instead of creating table.

Signed-off-by: Naveen N. Rao 
Signed-off-by: Ravi Bangoria 
---
 tools/perf/util/annotate.c | 64 ++
 1 file changed, 64 insertions(+)

diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 36a5825..96c6610 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -476,6 +476,68 @@ static int ins__cmp(const void *a, const void *b)
return strcmp(ia->name, ib->name);
 }
 
+static struct ins *ins__find_powerpc(const char *name)
+{
+   int i;
+   struct ins *ins;
+
+   ins = zalloc(sizeof(struct ins));
+   if (!ins)
+   return NULL;
+
+   ins->name = strdup(name);
+   if (!ins->name)
+   return NULL;
+
+   if (name[0] == 'b') {
+   /* branch instructions */
+   ins->ops = _ops;
+
+   /*
+* - Few start with 'b', but aren't branch instructions.
+* - Let's also ignore instructions involving 'ctr' and
+*   'tar' since target branch addresses for those can't
+*   be determined statically.
+*/
+   if (!strncmp(name, "bcd", 3)   ||
+   !strncmp(name, "brinc", 5) ||
+   !strncmp(name, "bper", 4)  ||
+   strstr(name, "ctr")||
+   strstr(name, "tar"))
+   return NULL;
+
+   i = strlen(name) - 1;
+   if (i < 0)
+   return NULL;
+
+   /* ignore optional hints at the end of the instructions */
+   if (name[i] == '+' || name[i] == '-')
+   i--;
+
+   if (name[i] == 'l' || (name[i] == 'a' && name[i-1] == 'l')) {
+   /*
+* if the instruction ends up with 'l' or 'la', then
+* those are considered 'calls' since they update LR.
+* ... except for 'bnl' which is branch if not less than
+* and the absolute form of the same.
+*/
+   if (strcmp(name, "bnl") && strcmp(name, "bnl+") &&
+   strcmp(name, "bnl-") && strcmp(name, "bnla") &&
+   strcmp(name, "bnla+") && strcmp(name, "bnla-"))
+   ins->ops = _ops;
+   }
+   if (name[i] == 'r' && name[i-1] == 'l')
+   /*
+* instructions ending with 'lr' are considered to be
+* return instructions
+*/
+   ins->ops = _ops;
+
+   return ins;
+   }
+   return NULL;
+}
+
 static void ins__sort(struct ins *instructions, int nmemb)
 {
qsort(instructions, nmemb, sizeof(struct ins), ins__cmp);
@@ -511,6 +573,8 @@ static struct ins *ins__find(const char *name, const char 
*norm_arch)
} else if (!strcmp(norm_arch, "arm")) {
instructions = instructions_arm;
nmemb = ARRAY_SIZE(instructions_arm);
+   } else if (!strcmp(norm_arch, "powerpc")) {
+   return ins__find_powerpc(name);
} else {
pr_err("perf annotate not supported by %s arch\n", norm_arch);
return NULL;
-- 
2.5.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 29/38] powerpc: Move 32-bit probe() machine to later in the boot process

[Benjamin Herrenschmidt]

On Tue, 2016-06-28 at 13:42 +0200, Gerhard Pircher wrote:
> The question is, if a compile time option that simply clear ?s
> CPU_FTR_NEED_COHERENT after identify_cpu() would be acceptable. And
> then I still wonder why KVM needs its own similar fix to work on the
> AmigaOne. I specifically had to remove/clear the PTE_M bit
> inarch/powerpc/kvm/book3s_32_mmu_host.c for th

No we could just add something to early_init_devtree that does clear
that bit if it sees the relevant piece of broken HW, it's not the AmigaOne 
per-se, it's the northbridge right ?

We could also make non-coherent cache a runtime option if we really
wanted, it's just more churn ...

> 206 pteg0 = ((eaddr & 0x0fff) >> 22) | (vsid << 7) |
> PTE_V |
> 207 (primary ? 0 : PTE_SEC);
> 208 pteg1 = hpaddr | PTE_M | PTE_R | PTE_C;
>  ^
> 
> > Do we know where the lockups come from btw ? A problem with the
> > northbridge ?
> Yes, it's a problem with the northbridge...as usual. :-(

Marvell ?

Cheers,
Ben.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: arch/powerpc/xmon/dis-asm.h: 2 * wrong specifiers ?

[Benjamin Herrenschmidt]

On Tue, 2016-06-28 at 08:06 +0100, David Binderman wrote:
> 
> I don't know the code, but given that insn is unsigned long and so
> can go
> past 32 bits, using a cast to unsigned int might throw away the
> possibly important
> upper bits.

our instructions are only ever 32-bits. That xmon code is ancient and
originated from 32-bits stuff. In fact some of Paulus earliest xmons
might even have run on platforms where int is 16 bits :-)

Cheers,
Ben.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 1/4] kernel/sched: introduce vcpu preempted check interface

[Pan Xinhui]

This patch support to fix lock holder preemption issue.

For kernel users, we could use bool vcpu_is_preempted(int cpu) to detech if
one vcpu is preempted or not.

The default implementation is a macro defined by false. So compiler can
wrap it out if arch dose not support such vcpu pteempted check.

Suggested-by: Peter Zijlstra (Intel) 
Signed-off-by: Pan Xinhui 
---
 include/linux/sched.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 6e42ada..cbe0574 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -3293,6 +3293,18 @@ static inline void set_task_cpu(struct task_struct *p, 
unsigned int cpu)
 
 #endif /* CONFIG_SMP */
 
+/*
+ * In order to deal with a various lock holder preemption issues provide an
+ * interface to see if a vCPU is currently running or not.
+ *
+ * This allows us to terminate optimistic spin loops and block, analogous to
+ * the native optimistic spin heuristic of testing if the lock owner task is
+ * running or not.
+ */
+#ifndef vcpu_is_preempted
+#define vcpu_is_preempted(cpu) false
+#endif
+
 extern long sched_setaffinity(pid_t pid, const struct cpumask *new_mask);
 extern long sched_getaffinity(pid_t pid, struct cpumask *mask);
 
-- 
2.4.11

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 06/38] powerpc: Move 64-bit feature fixup earlier

[Benjamin Herrenschmidt]

On Tue, 2016-06-28 at 16:35 +0530, Aneesh Kumar K.V wrote:
> Why not move it immediately after we finish all the device tress
> scan.

Do you need it in early_init_mmu ? The important thing is to have it
done before we *turn on* the MMU but yeah, there's no big deal
moving it even further up I think..

> ie,
> early_init_devtree(__va(dt_ptr));
> 
> epapr_paravirt_early_init();
> 
>   +  apply_feature_fixups();
> /* Now we know the logical id of our boot cpu, setup the
> paca. */
> setup_paca([boot_cpuid]);
> fixup_boot_paca();
> 
> Also with a comment explaining why we can't move it further up ?

Yup, adding some comments about the why things are done in that order
would be good, I'll improve that

Cheers,
Ben.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2/4] perf annotate: Enable cross arch annotate

[Ravi Bangoria]

Change current data structures and function to enable cross arch
annotate.

Current implementation does not contain logic of record on one arch
and annotate on other. This remote annotate is partially possible
with current implementation for x86 (or may be arm as well) only.
But, to make remote annotation work properly, all architecture
instruction tables need to be included in the perf binary. And while
annotating, look for instruction table where perf.data was recorded.

For arm, few instructions were defined under #if __arm__ which I've
used as a table for arm. But I'm not sure whether instruction defined
outside of that also contains arm instructions. Apart from that,
'call__parse()' and 'move__parse()' contains #ifdef __arm__ directive.
I've changed it to  if (!strcmp(norm_arch, "arm")). But I've not
tested this as well.

Signed-off-by: Ravi Bangoria 
---
 tools/perf/builtin-top.c  |   2 +-
 tools/perf/ui/browsers/annotate.c |   3 +-
 tools/perf/ui/gtk/annotate.c  |   2 +-
 tools/perf/util/annotate.c| 136 --
 tools/perf/util/annotate.h|   5 +-
 5 files changed, 95 insertions(+), 53 deletions(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 07fc792..d4fd947 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -128,7 +128,7 @@ static int perf_top__parse_source(struct perf_top *top, 
struct hist_entry *he)
return err;
}
 
-   err = symbol__annotate(sym, map, 0);
+   err = symbol__annotate(sym, map, 0, NULL);
if (err == 0) {
 out_assign:
top->sym_filter_entry = he;
diff --git a/tools/perf/ui/browsers/annotate.c 
b/tools/perf/ui/browsers/annotate.c
index 29dc6d2..3a652a6f 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -1050,7 +1050,8 @@ int symbol__tui_annotate(struct symbol *sym, struct map 
*map,
  (nr_pcnt - 1);
}
 
-   if (symbol__annotate(sym, map, sizeof_bdl) < 0) {
+   if (symbol__annotate(sym, map, sizeof_bdl,
+perf_evsel__env_arch(evsel)) < 0) {
ui__error("%s", ui_helpline__last_msg);
goto out_free_offsets;
}
diff --git a/tools/perf/ui/gtk/annotate.c b/tools/perf/ui/gtk/annotate.c
index 9c7ff8d..d7150b3 100644
--- a/tools/perf/ui/gtk/annotate.c
+++ b/tools/perf/ui/gtk/annotate.c
@@ -166,7 +166,7 @@ static int symbol__gtk_annotate(struct symbol *sym, struct 
map *map,
if (map->dso->annotate_warned)
return -1;
 
-   if (symbol__annotate(sym, map, 0) < 0) {
+   if (symbol__annotate(sym, map, 0, perf_evsel__env_arch(evsel)) < 0) {
ui__error("%s", ui_helpline__current);
return -1;
}
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index c385fec..36a5825 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -20,12 +20,14 @@
 #include 
 #include 
 #include 
+#include 
+#include "../arch/common.h"
 
 const char *disassembler_style;
 const char *objdump_path;
 static regex_t  file_lineno;
 
-static struct ins *ins__find(const char *name);
+static struct ins *ins__find(const char *name, const char *norm_arch);
 static int disasm_line__parse(char *line, char **namep, char **rawp);
 
 static void ins__delete(struct ins_operands *ops)
@@ -53,7 +55,8 @@ int ins__scnprintf(struct ins *ins, char *bf, size_t size,
return ins__raw_scnprintf(ins, bf, size, ops);
 }
 
-static int call__parse(struct ins_operands *ops)
+static int call__parse(struct ins_operands *ops,
+  __maybe_unused const char *norm_arch)
 {
char *endptr, *tok, *name;
 
@@ -65,10 +68,8 @@ static int call__parse(struct ins_operands *ops)
 
name++;
 
-#ifdef __arm__
-   if (strchr(name, '+'))
+   if (!strcmp(norm_arch, "arm") && strchr(name, '+'))
return -1;
-#endif
 
tok = strchr(name, '>');
if (tok == NULL)
@@ -117,7 +118,8 @@ bool ins__is_call(const struct ins *ins)
return ins->ops == _ops;
 }
 
-static int jump__parse(struct ins_operands *ops)
+static int jump__parse(struct ins_operands *ops,
+  __maybe_unused const char *norm_arch)
 {
const char *s = strchr(ops->raw, '+');
 
@@ -172,7 +174,7 @@ static int comment__symbol(char *raw, char *comment, u64 
*addrp, char **namep)
return 0;
 }
 
-static int lock__parse(struct ins_operands *ops)
+static int lock__parse(struct ins_operands *ops, const char *norm_arch)
 {
char *name;
 
@@ -183,7 +185,7 @@ static int lock__parse(struct ins_operands *ops)
if (disasm_line__parse(ops->raw, , >locked.ops->raw) < 0)
goto out_free_ops;
 
-   ops->locked.ins = ins__find(name);
+   ops->locked.ins = ins__find(name, norm_arch);
free(name);
 
if (ops->locked.ins == NULL)
@@ -193,7 

Re: [PATCH 06/38] powerpc: Move 64-bit feature fixup earlier

[Benjamin Herrenschmidt]

On Tue, 2016-06-28 at 17:19 +0530, Aneesh Kumar K.V wrote:
> If we can do feature fixup early. Then this patch series become
> simpler.
> 
> https://lkml.kernel.org/r/1465887288-12952-1-git-send-email-aneesh.ku
> m...@linux.vnet.ibm.com
> 
> ie, we can now start using cpu_has_feature/mmu_has_feature early
> instead of using __cpu/mmu_has_feature.

Ok, I'll look into it tomorrow.

Cheers,
Ben.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 07/17] powerpc/opal: Add real mode call wrappers

[Benjamin Herrenschmidt]

On Tue, 2016-06-28 at 21:37 +1000, Michael Ellerman wrote:
> Yeah Ben already told me.
> 
> I don't know which will go in first yet, this has had zero revisions and zero
> reviews so it might not go in straight away ;)

The point was that patch could go in independently of the rest but I really
don't care either way.

> I'm happy to fix up whatever merge conflicts and/or get people to rebase, it's
> no problem.

Yup and rebasing my patch on top of Shreyas is not a big deal wither, I
did it at least twice in internal trees already ;-)

Cheers,
Ben.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 0/4] implement vcpu preempted check

[Pan Xinhui]

change fomr v1:
a simplier definition of default vcpu_is_preempted
skip mahcine type check on ppc, and add config. remove dedicated macro.
add one patch to drop overload of rwsem_spin_on_owner and 
mutex_spin_on_owner. 
add more comments
thanks boqun and Peter's suggestion.

This patch set aims to fix lock holder preemption issues.

test-case:
perf record -a perf bench sched messaging -g 400 -p && perf report

18.09%  sched-messaging  [kernel.vmlinux]  [k] osq_lock
12.28%  sched-messaging  [kernel.vmlinux]  [k] rwsem_spin_on_owner
 5.27%  sched-messaging  [kernel.vmlinux]  [k] mutex_unlock
 3.89%  sched-messaging  [kernel.vmlinux]  [k] wait_consider_task
 3.64%  sched-messaging  [kernel.vmlinux]  [k] _raw_write_lock_irq
 3.41%  sched-messaging  [kernel.vmlinux]  [k] mutex_spin_on_owner.is
 2.49%  sched-messaging  [kernel.vmlinux]  [k] system_call

We introduce interface bool vcpu_is_preempted(int cpu) and use it in some spin
loops of osq_lock, rwsem_spin_on_owner and mutex_spin_on_owner.
These spin_on_onwer variant also cause rcu stall before we apply this patch set

Pan Xinhui (4):
  kernel/sched: introduce vcpu preempted check interface
  powerpc/spinlock: support vcpu preempted check
  locking/osq: Drop the overload of osq_lock()
  kernel/locking: Drop the overload of {mutex,rwsem}_spin_on_owner

 arch/powerpc/include/asm/spinlock.h | 18 ++
 include/linux/sched.h   | 12 
 kernel/locking/mutex.c  | 15 +--
 kernel/locking/osq_lock.c   | 10 +-
 kernel/locking/rwsem-xadd.c | 16 +---
 5 files changed, 65 insertions(+), 6 deletions(-)

-- 
2.4.11

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/mm: Use VM_WARN_ONCE() for irqs disabled check

[Aneesh Kumar K.V]

Michael Ellerman  writes:

> The check for !arch_irqs_disabled() in find_linux_pte_or_hugepte() is a
> debugging aid, and needn't be enabled for production builds.
>
> Switch it to a VM_WARN_ONCE(), which is compiled out when
> CONFIG_DEBUG_VM=n.
>
> Signed-off-by: Michael Ellerman 
> ---
>  arch/powerpc/include/asm/pgtable.h | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/pgtable.h 
> b/arch/powerpc/include/asm/pgtable.h
> index ee09e99097f0..651848039dc4 100644
> --- a/arch/powerpc/include/asm/pgtable.h
> +++ b/arch/powerpc/include/asm/pgtable.h
> @@ -71,10 +71,8 @@ pte_t *__find_linux_pte_or_hugepte(pgd_t *pgdir, unsigned 
> long ea,
>  static inline pte_t *find_linux_pte_or_hugepte(pgd_t *pgdir, unsigned long 
> ea,
>  bool *is_thp, unsigned *shift)
>  {
> - if (!arch_irqs_disabled()) {
> - pr_info("%s called with irq enabled\n", __func__);
> - dump_stack();
> - }
> + VM_WARN_ONCE(!arch_irqs_disabled(),
> +  "find_linux_pte_or_hugepte() called with irqs enabled!\n");
>   return __find_linux_pte_or_hugepte(pgdir, ea, is_thp, shift);
>  }
>


https://lkml.kernel.org/r/574de240.uG8/5OM2Lu9RY6K+%akpm@linux-foundation.orgdd

Isn't this patch already part of -mm. And why ONCE, we want to find
about all the wrong usage.

-aneesh

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 06/38] powerpc: Move 64-bit feature fixup earlier

[Aneesh Kumar K.V]

Benjamin Herrenschmidt  writes:

> Make it part of early_setup() as we really want the feature fixups
> to be applied before we turn on the MMU since they can have an impact
> on the various assembly path related to MMU management and interrupts.
>
> This makes 64-bit match what 32-bit does.
>
> Signed-off-by: Benjamin Herrenschmidt 
> ---
>  arch/powerpc/kernel/setup_64.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index 996bed2..e79cf1b 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -286,6 +286,9 @@ void __init early_setup(unsigned long dt_ptr)
>   /* Initialize the hash table or TLB handling */
>   early_init_mmu();
>  
> + /* Apply all the dynamic patching */
> + apply_feature_fixups();
> +
>   /*
>* At this point, we can let interrupts switch to virtual mode
>* (the MMU has been setup), so adjust the MSR in the PACA to
> @@ -468,8 +471,6 @@ void __init setup_system(void)
>  {
>   DBG(" -> setup_system()\n");
>  
> - apply_feature_fixups();
> -
>   /*
>* Unflatten the device-tree passed by prom_init or kexec
>*/

Why not move it immediately after we finish all the device tress scan.

ie,
early_init_devtree(__va(dt_ptr));

epapr_paravirt_early_init();

  +  apply_feature_fixups();
/* Now we know the logical id of our boot cpu, setup the paca. */
setup_paca([boot_cpuid]);
fixup_boot_paca();

Also with a comment explaining why we can't move it further up ?


-aneesh

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 0/4] perf annotate: Enable cross arch annotate

[Ravi Bangoria]

Perf can currently only support code navigation (branches and calls) in
annotate when run on the same architecture where perf.data was recorded.
But cross arch annotate is not supported.

This patchset enables cross arch annotate. Currently I've used x86
and arm instructions which are already available and adding support
for powerpc as well. Adding support for other arch will be easy.

I've created this patch on top of acme/perf/core. And tested it with
x86 and powerpc only.

Example:

  Record on powerpc:
  $ ./perf record -a

  Report -> Annotate on x86:
  $ ./perf report -i perf.data.powerpc --vmlinux vmlinux.powerpc

Changes in [PATCH] vs [RFC]
  - Removed global var 'arch__ins' and pass arch info till ins__find

Naveen N. Rao (1):
  perf annotate: add powerpc support

Ravi Bangoria (3):
  perf: Utility function to fetch arch
  perf annotate: Enable cross arch annotate
  perf annotate: Define macro for arch names

 tools/perf/arch/common.c   |  36 +++
 tools/perf/arch/common.h   |  11 +++
 tools/perf/builtin-top.c   |   2 +-
 tools/perf/ui/browsers/annotate.c  |   3 +-
 tools/perf/ui/gtk/annotate.c   |   2 +-
 tools/perf/util/annotate.c | 198 -
 tools/perf/util/annotate.h |   5 +-
 tools/perf/util/evsel.c|   7 ++
 tools/perf/util/evsel.h|   2 +
 tools/perf/util/unwind-libunwind.c |   4 +-
 10 files changed, 198 insertions(+), 72 deletions(-)

--
2.5.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 07/17] powerpc/opal: Add real mode call wrappers

[Michael Ellerman]

On Tue, 2016-06-28 at 14:18 +1000, Michael Neuling wrote:
> mpe,
> 
> Just flagging this as going to conflict with Shreyas' stop instruction
> patch series.  It's relatively easy to fix so you can do it manually.
> 
> Alternatively you could take this one patch now and get Shreyas to rebase.

Yeah Ben already told me.

I don't know which will go in first yet, this has had zero revisions and zero
reviews so it might not go in straight away ;)

I'm happy to fix up whatever merge conflicts and/or get people to rebase, it's
no problem.

cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 29/38] powerpc: Move 32-bit probe() machine to later in the boot process

[Gerhard Pircher]

On Mon, 2016-06-27 at 23:40 +0200, Benjamin Herrenschmidt wrote:
> On Mon, 2016-06-27 at 22:42 +0200, Gerhard Pircher wrote:
> > This patch series reminds me of a long-standing issue with the
> > AmigaOne platform code, which would have to clear the coherence
> > (M) flag for every memory mapping to avoid lockups (especially
> > on G4 CPUs) - as you can read in the comment below your patch
> > above.
> > 
> > Now the follow-up code in amigaone/setup.c to clear the
> > corresponding CPU feature flag is essentially dead code (it used
> > to work with a second call of do_feature_fixups() before the
> > handling of the CPU_FTR_NEED_COHERENT flag was changed/inverted
> > somewhere around v2.6.30). Also it doesn't seem to fix all
> > deadlocks, as e.g. KVM virtual machines can still inject memory
> > mappings with the M flag set AFAICT.
> > 
> > Now I wonder, if there is a reasonably clean way to clear the M
> > flag in all hardware page table and BAT entries without defacing
> > generic kernel code too much. Any ideas?
> 
> Other than a compile time option ?
Well, I guess a runtime option would always be preferable, but I don't
see how this could be implemented without moving probe_machine() in
front of identify_cpu() (which doesn't look easy either). On the other
side the AmigaOne also requires CONFIG_NOT_COHERENT_CACHE set and this
one is still a compile time option, too.
The question is, if a compile time option that simply clears
CPU_FTR_NEED_COHERENT after identify_cpu() would be acceptable. And
then I still wonder why KVM needs its own similar fix to work on the
AmigaOne. I specifically had to remove/clear the PTE_M bit in
arch/powerpc/kvm/book3s_32_mmu_host.c for this:

206 pteg0 = ((eaddr & 0x0fff) >> 22) | (vsid << 7) | PTE_V |
207 (primary ? 0 : PTE_SEC);
208 pteg1 = hpaddr | PTE_M | PTE_R | PTE_C;
 ^

> Do we know where the lockups come from btw ? A problem with the
> northbridge ?
Yes, it's a problem with the northbridge...as usual. :-(

> Cheers,
> Ben.

Thanks!

BR,
Gerhard
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Proposed: Patch to fix boot on PA6T

[Aneesh Kumar K.V]

Darren Stevens  writes:

> Hello All,
>
> commit d6a9996e84ac4beb7713e9485f4563e100a9b03e
> powerpc/mm: vmalloc abstraction in preparation for radix
>
> This commit introduced variables for some linux kernel addresses that had
> before
> been constants, unfortunately this stopped PaSemi PA6T systems(*) from
> booting as
> they call ioremap to map SoC registers before the mmu is initialised. The
> attached
> patch adds a hard-coded init of pci_io_base to the pas_init_early()
> function which
> which allows the kernel to boot normally.
>
> The value will be harmlessly set again once pci starts up.
>
> (*) At the moment this has only been tested on an AmigaOneX1000, but I
> expect PaSemi
> reference systems to have been affected in the same way.
>
> Kind regards
> Darren
> diff --git a/arch/powerpc/platforms/pasemi/setup.c 
> b/arch/powerpc/platforms/pasemi/setup.c
> index d71b2c7..6b8d2ab 100644
> --- a/arch/powerpc/platforms/pasemi/setup.c
> +++ b/arch/powerpc/platforms/pasemi/setup.c
> @@ -61,6 +61,7 @@ static struct mce_regs mce_regs[MAX_MCE_REGS];
>  static int num_mce_regs;
>  static int nmi_virq = NO_IRQ;
>  
> +extern unsigned long pci_io_base;
>  
>  static void pas_restart(char *cmd)
>  {
> @@ -341,6 +342,10 @@ out:
>  
>  static void __init pas_init_early(void)
>  {
> + /* Initialise the IO pointer so we don't crash on boot */
> +
> + pci_io_base = (H_KERN_VIRT_START + (H_KERN_VIRT_SIZE >> 1));
> +
>   iommu_init_early_pasemi();
>  }
>  

Another option is to init it along with rest of the variables as done in
hash__early_init_mmu(void)/radix__early_init_mmu(void)


-aneesh

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/mm: update arch_{add,remove}_memory() for radix

[Aneesh Kumar K.V]

Michael Ellerman  writes:

> On Thu, 2016-06-23 at 14:37 -0500, Reza Arbab wrote:
>> On Thu, Jun 23, 2016 at 10:47:20PM +0530, Aneesh Kumar K.V wrote:
>> > Reza Arbab  writes:
>> > > These functions are making direct calls to the hash table APIs,
>> > > leading to a BUG() on systems using radix.
>> > > 
>> > > Switch them to the vmemmap_{create,remove}_mapping() wrappers, and
>> > > move to the __meminit section.
>> > 
>> > They are really not the same. They can possibly end up using different
>> > base page size. Also vmemmap is available only with SPARSEMEM_VMEMMAP
>> > enabled. Does hotplug depend on sparsemem vmemmap ?
>> 
>> I'm not sure. Maybe it's best if I back up a step and explain what lead 
>> me to this patch. During hotplug, you get
>> 
>> ...
>>  arch_add_memory
>>  create_section_mapping
>>  htab_bolt_mapping
>>  BUG_ON(!ppc_md.hpte_insert);
>> 
>> So it seemed to me that I needed a radix equivalent of 
>> create_section_mapping().
>> 
>> After some digging, I found hash__vmemmap_create_mapping() and 
>> radix__vmemmap_create_mapping() did what I needed. I did not notice the 
>> #ifdef SPARSEMEM_VMEMMAP around them.
>
> I think that's more by luck than design. The vmemmap routines use
> mmu_vmemmap_psize which is probably but not definitely the same as
> mmu_linear_psize.
>
>> Could it be that the functions just need to be renamed 
>> hash__create_mapping()/radix__create_mapping() and moved out of #ifdef 
>> SPARSEMEM_VMEMMAP?
>
> No, you need to use mmu_linear_psize for the hotplug case.
>
> But you can probably factor out a common routine that both cases use, and hide
> the hash vs radix check in that.
>
> And probably send me a patch to make MEMORY_HOTPLUG depend on !RADIX for v4.7?

Few other stuff we need to still look from Radix point
1) machine check handling/memory errors
2) kexec

-aneesh

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] ASoC: fsl_spdif: fix spelling mistake: "receivce" -> "receive"

[Mark Brown]

On Tue, Jun 28, 2016 at 01:47:59PM +0100, Colin King wrote:
> From: Colin Ian King 

Please fix things so that your mail configuration matches your git
configuration, it makes things harder to review since it looks like
you've got a non-author signoff with a missing signed off by from
someone.


signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/pseries: Auto online hotplugged memory

[Nathan Fontenot]

On 06/27/2016 10:46 PM, Michael Ellerman wrote:
> On Mon, 2016-06-27 at 09:41 -0500, Nathan Fontenot wrote:
>> On 06/24/2016 12:35 AM, Michael Ellerman wrote:
>>> On Mon, 2016-06-20 at 21:14 -0500, Nathan Fontenot wrote:
 On 06/20/2016 07:57 PM, Michael Ellerman wrote:
> On Mon, 2016-06-20 at 08:51 -0500, Nathan Fontenot wrote:
>
>> Auto online hotplugged memory
>>
>> A recent update (commit id 31bc3858ea3) to the core mm hotplug code
>> introduced the memhp_auto_online variable to allow for automatically
>> onlining memory that is added.
>>
>> This patch update the pseries memory hotplug code to enable this so that
>> any memory DLPAR added to the system is automatically onlined. The code
>> to add the memory block for memory added from add_memory() is removed as
>> this is not needed, the memory_add code does this.
>
> Is this a bug fix, or just a cleanup?

 Hmmm.. some cleanup and some new feature. The removal of the memblock_add()
 call is a cleanup and the setting of the memhp_auto_online variable is
 taking advantage of a feature I was not previously aware of.
>>>
>>> OK. Looking at usage of memhp_auto_online it's not clear to me that you're
>>> supposed to be setting it in arch code.
>>>
>>> eg. if I build my kernel with CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=n, I will
>>> expect it to not be onlined by default.
>>>
>>> Similarly if I boot with memhp_default_state=offline on the kernel command 
>>> line.
>>>
>>> But this patch would then mean it is onlined by default. So that seems kind 
>>> of
>>> confusing for users.
>>
>> Yes, but we already online memory when it is DLPAR added to the system. This 
>> has
>> always been the default behavior for pseries. I was using the 
>> memhp_auto_online
>> setting so that the memory will be added as part of the memory_add call 
>> instead
>> of having to online the memory as a separate step in the pseries code.
>>
>> In other words, I am not changing the existing behavior of pseries code. 
> 
> Yep, that's good.
> 
> What's not good is giving the user an option and then ignoring it.

True, I just trying to preserve existing behavior.

> 
>> Perhaps something a bit different? I could save and restore the 
>> memhp_auto_online
>> setting across the call to memory_add, or perhpas ther should be an
>> add_memory_and_online() variant of the add_memory() call that always onlines 
>> memory.
>  
> No I think we should just honor the setting.
> 
> To retain the existing behavour on pseries we just set 
> CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y
> in the pseries defconfig.
> 
> That way users can control the behaviour, which is good, and all the existing
> documentation applies equally to powerpc as other arches. If we do something
> different, like force onlining it, then we need to go and update all the docs 
> to
> say "memhp_auto_online - ignored on powerpc".
> 

Sounds good, I'll send a new patch to set the config option for pseries and 
update
the dlpar memory add code accordingly.

Thanks,
-Nathan

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 3/4] perf annotate: add powerpc support

[David Laight]

From: Ravi Bangoria
> Sent: 28 June 2016 12:37
> 
> Powerpc has long list of branch instructions and hardcoding them in table
> appears to be error-prone. So, add new function to find instruction
> instead of creating table.
> 
> Signed-off-by: Naveen N. Rao 
> Signed-off-by: Ravi Bangoria 
> ---
>  tools/perf/util/annotate.c | 64 
> ++
>  1 file changed, 64 insertions(+)
> 
> diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
> index 36a5825..96c6610 100644
> --- a/tools/perf/util/annotate.c
> +++ b/tools/perf/util/annotate.c
> @@ -476,6 +476,68 @@ static int ins__cmp(const void *a, const void *b)
>   return strcmp(ia->name, ib->name);
>  }
> 
> +static struct ins *ins__find_powerpc(const char *name)

It would be better if the function name include 'branch'.

> +{
> + int i;
> + struct ins *ins;
> +
> + ins = zalloc(sizeof(struct ins));
> + if (!ins)
> + return NULL;
> +
> + ins->name = strdup(name);
> + if (!ins->name)
> + return NULL;

You leak 'ins' here.

> +
> + if (name[0] == 'b') {
> + /* branch instructions */
> + ins->ops = _ops;
> +
> + /*
> +  * - Few start with 'b', but aren't branch instructions.
> +  * - Let's also ignore instructions involving 'ctr' and
> +  *   'tar' since target branch addresses for those can't
> +  *   be determined statically.
> +  */
> + if (!strncmp(name, "bcd", 3)   ||
> + !strncmp(name, "brinc", 5) ||
> + !strncmp(name, "bper", 4)  ||
> + strstr(name, "ctr")||
> + strstr(name, "tar"))
> + return NULL;

More importantly you leak 'ins' and 'ins->name' here.
And on other paths below.

...

David

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Applied "ASoC: fsl_spdif: fix spelling mistake: "receivce" -> "receive"" to the asoc tree

[Mark Brown]

The patch

   ASoC: fsl_spdif: fix spelling mistake: "receivce" -> "receive"

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From d93c5066e85e936765af29bf47ec78885d55ad02 Mon Sep 17 00:00:00 2001
From: Colin Ian King 
Date: Tue, 28 Jun 2016 13:47:59 +0100
Subject: [PATCH] ASoC: fsl_spdif: fix spelling mistake: "receivce" ->
 "receive"

trivial fix to spelling mistake in dev_err message

Signed-off-by: Colin Ian King 
Signed-off-by: Mark Brown 
---
 sound/soc/fsl/fsl_spdif.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
index 151849f79863..beec7934a265 100644
--- a/sound/soc/fsl/fsl_spdif.c
+++ b/sound/soc/fsl/fsl_spdif.c
@@ -172,7 +172,7 @@ static void spdif_irq_uqrx_full(struct fsl_spdif_priv 
*spdif_priv, char name)
if (*pos >= size * 2) {
*pos = 0;
} else if (unlikely((*pos % size) + 3 > size)) {
-   dev_err(>dev, "User bit receivce buffer overflow\n");
+   dev_err(>dev, "User bit receive buffer overflow\n");
return;
}
 
-- 
2.8.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 3/9] kexec_file: Factor out kexec_locate_mem_hole from kexec_add_buffer.

[Dave Young]

On 06/27/16 at 04:21pm, Dave Young wrote:
> Please ignore previous reply, I mistakenly send a broken mail without
> subject, sorry about it. Resend the reply here.
> 
> On 06/27/16 at 01:37pm, Thiago Jung Bauermann wrote:
> > Am Dienstag, 28 Juni 2016, 00:19:48 schrieb Dave Young:
> > > On 06/23/16 at 12:37pm, Thiago Jung Bauermann wrote:
> > > > Am Donnerstag, 23 Juni 2016, 01:44:07 schrieb Dave Young:
> > > > What is bad about the description of top_down?
> > > It is not clear enough to me, I personally think the original one in
> > > source code is better:
> > > /* allocate from top of memory hole */
> > 
> > Actually I realized there's some discrepancy in how the x86 code uses 
> > top_down and how I need it to work in powerpc. This may be what is 
> > confusing 
> > about my comment and the existing comment.
> > 
> > x86 always walks memory from bottom to top but if top_down is true, in each 
> > memory region it will allocate the memory hole in the highest address 
> > within 
> > that region. I don't know why it is done that way, though.
> 
> I think we did not meaning to do this, considering kdump we have only
> one crashkernel region for searching (crashk_res) so it is fine.
> For kexec maybe changing the walking function to accept top_down is
> reasonable.
>  
> Ccing Vivek see if he can remember something..
> 
> > 
> > On powerpc, the memory walk itself should be from top to bottom, as well as 
> > the memory hole allocation within each memory region.

What is the particular reason in powerpc for a mandatory top to bottom
walking?

> > 
> > Should I add a separate top_down argument to kexec_locate_mem_hole to 
> > control if the memory walk should be from top to bottom, and then the 
> > bottom_up member of struct kexec_buf controls where inside each memory 
> > region the memory hole will be allocated?

Using one argument for both sounds more reasonable than using a separate
argument for memory walk..

Thanks
Dave
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [v7, 1/2] cxl: Add mechanism for delivering AFU driver specific events

[Matthew R. Ochs]

> On Jun 23, 2016, at 8:03 AM, Philippe Bergheaud  
> wrote:
> 
> This adds an afu_driver_ops structure with fetch_event() and
> event_delivered() callbacks. An AFU driver such as cxlflash can fill
> this out and associate it with a context to enable passing custom AFU
> specific events to userspace.
> 
> This also adds a new kernel API function cxl_context_pending_events(),
> that the AFU driver can use to notify the cxl driver that new specific
> events are ready to be delivered, and wake up anyone waiting on the
> context wait queue.
> 
> The current count of AFU driver specific events is stored in the field
> afu_driver_events of the context structure.
> 
> The cxl driver checks the afu_driver_events count during poll, select,
> read, etc. calls to check if an AFU driver specific event is pending,
> and calls fetch_event() to obtain and deliver that event. This way, the
> cxl driver takes care of all the usual locking semantics around these
> calls and handles all the generic cxl events, so that the AFU driver
> only needs to worry about it's own events.
> 
> fetch_event() return a struct cxl_event_afu_driver_reserved, allocated
> by the AFU driver, and filled in with the specific event information and
> size. Total event size (header + data) should not be greater than
> CXL_READ_MIN_SIZE (4K).
> 
> Th cxl driver prepends an appropriate cxl event header, copies the event
> to userspace, and finally calls event_delivered() to return the status of
> the operation to the AFU driver. The event is identified by the context
> and cxl_event_afu_driver_reserved pointers.
> 
> Since AFU drivers provide their own means for userspace to obtain the
> AFU file descriptor (i.e. cxlflash uses an ioctl on their scsi file
> descriptor to obtain the AFU file descriptor) and the generic cxl driver
> will never use this event, the ABI of the event is up to each individual
> AFU driver.
> 
> Signed-off-by: Philippe Bergheaud 

Reviewed-by: Matthew R. Ochs 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: powerpc/pci: Reduce log level of PCI I/O space warning

[Michael Ellerman]

On Wed, 2016-22-06 at 07:23:07 UTC, Benjamin Herrenschmidt wrote:
> If a PHB has no I/O space, there's no need to make it look like
> something bad happened, a pr_debug() is plenty enough since this
> is the case of all our modern POWER chips.
> 
> Signed-off-by: Benjamin Herrenschmidt 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/cdb1b3424dba7d38a2835f6f5f

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] ASoC: fsl_spdif: fix spelling mistake: "receivce" -> "receive"

[Colin King]

From: Colin Ian King 

trivial fix to spelling mistake in dev_err message

Signed-off-by: Colin Ian King 
---
 sound/soc/fsl/fsl_spdif.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
index 151849f..beec793 100644
--- a/sound/soc/fsl/fsl_spdif.c
+++ b/sound/soc/fsl/fsl_spdif.c
@@ -172,7 +172,7 @@ static void spdif_irq_uqrx_full(struct fsl_spdif_priv 
*spdif_priv, char name)
if (*pos >= size * 2) {
*pos = 0;
} else if (unlikely((*pos % size) + 3 > size)) {
-   dev_err(>dev, "User bit receivce buffer overflow\n");
+   dev_err(>dev, "User bit receive buffer overflow\n");
return;
}
 
-- 
2.8.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

linux-next: manual merge of the powerpc tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the powerpc tree got a conflict in:

  arch/powerpc/Kconfig

between commit:

  844e3be47693 ("powerpc/bpf/jit: Disable classic BPF JIT on ppc64le")

from Linus' tree and commit:

  156d0e290e96 ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF")

from the powerpc tree.

I fixed it up (see below - I am not sure this entirely correct) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/powerpc/Kconfig
index 0a9d439bcda6,ee82f9a09a85..
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@@ -128,7 -128,8 +128,8 @@@ config PP
select IRQ_FORCED_THREADING
select HAVE_RCU_TABLE_FREE if SMP
select HAVE_SYSCALL_TRACEPOINTS
-   select HAVE_CBPF_JIT if CPU_BIG_ENDIAN
 -  select HAVE_CBPF_JIT if !PPC64
++  select HAVE_CBPF_JIT if !PPC64 && CPU_BIG_ENDIAN
+   select HAVE_EBPF_JIT if PPC64
select HAVE_ARCH_JUMP_LABEL
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select ARCH_HAS_GCOV_PROFILE_ALL
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 29/38] powerpc: Move 32-bit probe() machine to later in the boot process

[Gerhard Pircher]

On Tue, 2016-06-28 at 14:01 +0200, Benjamin Herrenschmidt wrote:
> On Tue, 2016-06-28 at 13:42 +0200, Gerhard Pircher wrote:
> > The question is, if a compile time option that simply clear ?s
> > CPU_FTR_NEED_COHERENT after identify_cpu() would be acceptable. And
> > then I still wonder why KVM needs its own similar fix to work on the
> > AmigaOne. I specifically had to remove/clear the PTE_M bit
> > inarch/powerpc/kvm/book3s_32_mmu_host.c for th
> 
> No we could just add something to early_init_devtree that does clear
> that bit if it sees the relevant piece of broken HW, it's not the AmigaOne 
> per-se, it's the northbridge right ?
Does that work for CPU_FTR_NEED_COHERENT, given that the feature fixups
are done right after identify_cpu() and instructions within BEGIN_FTR_SECTION
and END_FTR_SECTION* are patched out (if I understand this mechanism
correctly) !?
But yes, the specific northbridge is the problem here.

> We could also make non-coherent cache a runtime option if we really
> wanted, it's just more churn ...
Yeah, I remember a discussion or two about this topic and I always wondered
how driver code would differentiate then between non-coherent and coherent
DMA, given that they sometimes require different handling of the DMA addresses
(e.g. if I look at /sound/core/pcm_native.c or the DRM code).

> > > Do we know where the lockups come from btw ? A problem with the
> > > northbridge ?
> > Yes, it's a problem with the northbridge...as usual. :-(
> 
> Marvell ?
No, the one with the dreaded "A" name: MAI Logic's "Articia S" :-)

BR,
Gerhard
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: linux-next: manual merge of the powerpc tree with Linus' tree

[Naveen N. Rao]

On 2016/06/29 10:35AM, Stephen Rothwell wrote:
> Hi all,

Hi Stephen,

> 
> Today's linux-next merge of the powerpc tree got a conflict in:
> 
>   arch/powerpc/Kconfig
> 
> between commit:
> 
>   844e3be47693 ("powerpc/bpf/jit: Disable classic BPF JIT on ppc64le")

Ah, I see that the above commit is not part of powerpc next tree, which 
explains the conflict.

> 
> from Linus' tree and commit:
> 
>   156d0e290e96 ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF")
> 
> from the powerpc tree.
> 
> I fixed it up (see below - I am not sure this entirely correct) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the
> conflicting tree to minimise any particularly complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/powerpc/Kconfig
> index 0a9d439bcda6,ee82f9a09a85..
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@@ -128,7 -128,8 +128,8 @@@ config PP
>   select IRQ_FORCED_THREADING
>   select HAVE_RCU_TABLE_FREE if SMP
>   select HAVE_SYSCALL_TRACEPOINTS
> - select HAVE_CBPF_JIT if CPU_BIG_ENDIAN
>  -select HAVE_CBPF_JIT if !PPC64
> ++select HAVE_CBPF_JIT if !PPC64 && CPU_BIG_ENDIAN

'if !PPC64' condition is sufficient, though having the BIG_ENDIAN check 
should be ok too.

Thanks,
Naveen

> + select HAVE_EBPF_JIT if PPC64
>   select HAVE_ARCH_JUMP_LABEL
>   select ARCH_HAVE_NMI_SAFE_CMPXCHG
>   select ARCH_HAS_GCOV_PROFILE_ALL
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer.

[Thiago Jung Bauermann]

Am Donnerstag, 23 Juni 2016, 10:25:06 schrieb Dave Young:
> On 06/22/16 at 08:30pm, Thiago Jung Bauermann wrote:
> > Am Mittwoch, 22 Juni 2016, 18:20:47 schrieb Dave Young:
> > > The patch looks good, but could the subject be more specific?
> > > 
> > > For example just like the first sentence of the patch descriotion:
> > > Allow architectures to specify their own memory walking function
> > 
> > Ok, What about this? I also changed the description to refer to x86 arch
> > instead of Intel arch.
> 
> It looks good to me.

This version has the struct kexec_buf documentation comments that were
in patch 3/9. I fixed the names of the struct members, and changed their
descriptions to try to be clearer.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center


Subject: [PATCH 2/9] kexec_file: Allow arch-specific memory walking for
 kexec_add_buffer

Allow architectures to specify a different memory walking function for
kexec_add_buffer. x86 uses iomem to track reserved memory ranges, but
PowerPC uses the memblock subsystem.

Signed-off-by: Thiago Jung Bauermann 
Cc: Eric Biederman 
Cc: Dave Young 
Cc: ke...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
---
 include/linux/kexec.h   | 25 -
 kernel/kexec_file.c | 30 ++
 kernel/kexec_internal.h | 14 --
 3 files changed, 46 insertions(+), 23 deletions(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index e8acb2b43dd9..e16d845d587f 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -146,7 +146,30 @@ struct kexec_file_ops {
kexec_verify_sig_t *verify_sig;
 #endif
 };
-#endif
+
+/**
+ * struct kexec_buf - parameters for finding a place for a buffer in memory
+ * @image: kexec image in which memory to search.
+ * @mem:   On return will have address of the buffer in memory.
+ * @memsz: Size for the buffer in memory.
+ * @buf_align: Minimum alignment needed.
+ * @buf_min:   The buffer can't be placed below this address.
+ * @buf_max:   The buffer can't be placed above this address.
+ * @top_down:  Allocate from top of memory.
+ */
+struct kexec_buf {
+   struct kimage *image;
+   unsigned long mem;
+   unsigned long memsz;
+   unsigned long buf_align;
+   unsigned long buf_min;
+   unsigned long buf_max;
+   bool top_down;
+};
+
+int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
+  int (*func)(u64, u64, void *));
+#endif /* CONFIG_KEXEC_FILE */
 
 struct kimage {
kimage_entry_t head;
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index b6eec7527e9f..b1f1f6402518 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -428,6 +428,27 @@ static int locate_mem_hole_callback(u64 start, u64 end, 
void *arg)
return locate_mem_hole_bottom_up(start, end, kbuf);
 }
 
+/**
+ * arch_kexec_walk_mem - call func(data) on free memory regions
+ * @kbuf:  Context info for the search. Also passed to @func.
+ * @func:  Function to call for each memory region.
+ *
+ * Return: The memory walk will stop when func returns a non-zero value
+ * and that value will be returned. If all free regions are visited without
+ * func returning non-zero, then zero will be returned.
+ */
+int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
+  int (*func)(u64, u64, void *))
+{
+   if (kbuf->image->type == KEXEC_TYPE_CRASH)
+   return walk_iomem_res_desc(crashk_res.desc,
+  IORESOURCE_SYSTEM_RAM | 
IORESOURCE_BUSY,
+  crashk_res.start, crashk_res.end,
+  kbuf, func);
+   else
+   return walk_system_ram_res(0, ULONG_MAX, kbuf, func);
+}
+
 /*
  * Helper function for placing a buffer in a kexec segment. This assumes
  * that kexec_mutex is held.
@@ -472,14 +493,7 @@ int kexec_add_buffer(struct kimage *image, char *buffer, 
unsigned long bufsz,
kbuf->top_down = top_down;
 
/* Walk the RAM ranges and allocate a suitable range for the buffer */
-   if (image->type == KEXEC_TYPE_CRASH)
-   ret = walk_iomem_res_desc(crashk_res.desc,
-   IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY,
-   crashk_res.start, crashk_res.end, kbuf,
-   locate_mem_hole_callback);
-   else
-   ret = walk_system_ram_res(0, -1, kbuf,
- locate_mem_hole_callback);
+   ret = arch_kexec_walk_mem(kbuf, locate_mem_hole_callback);
if (ret != 1) {
/* A suitable memory range could not be found for buffer */
return -EADDRNOTAVAIL;
diff --git a/kernel/kexec_internal.h b/kernel/kexec_internal.h
index eefd5bf960c2..4cef7e4706b0 100644
--- a/kernel/kexec_internal.h
+++ 

Re: [PATCH v3 3/9] kexec_file: Factor out kexec_locate_mem_hole from kexec_add_buffer.

[Thiago Jung Bauermann]

Am Dienstag, 28 Juni 2016, 15:20:55 schrieb Dave Young:
> On 06/27/16 at 04:21pm, Dave Young wrote:
> > Please ignore previous reply, I mistakenly send a broken mail without
> > subject, sorry about it. Resend the reply here.
> > 
> > On 06/27/16 at 01:37pm, Thiago Jung Bauermann wrote:
> > > Am Dienstag, 28 Juni 2016, 00:19:48 schrieb Dave Young:
> > > > On 06/23/16 at 12:37pm, Thiago Jung Bauermann wrote:
> > > > > Am Donnerstag, 23 Juni 2016, 01:44:07 schrieb Dave Young:
> > > > > What is bad about the description of top_down?
> > > > 
> > > > It is not clear enough to me, I personally think the original one in
> > > > source code is better:
> > > > /* allocate from top of memory hole */
> > > 
> > > Actually I realized there's some discrepancy in how the x86 code uses
> > > top_down and how I need it to work in powerpc. This may be what is
> > > confusing about my comment and the existing comment.
> > > 
> > > x86 always walks memory from bottom to top but if top_down is true, in
> > > each memory region it will allocate the memory hole in the highest
> > > address within that region. I don't know why it is done that way,
> > > though.
> > 
> > I think we did not meaning to do this, considering kdump we have only
> > one crashkernel region for searching (crashk_res) so it is fine.
> > For kexec maybe changing the walking function to accept top_down is
> > reasonable.
> > 
> > Ccing Vivek see if he can remember something..
> > 
> > > On powerpc, the memory walk itself should be from top to bottom, as
> > > well as the memory hole allocation within each memory region.
> 
> What is the particular reason in powerpc for a mandatory top to bottom
> walking?

I'm walking unreserved memory ranges, so reservations made low in memory 
(such as the reservation for the initrd) may create a memory hole that is a 
lot lower than the true memory limit where I want to allocate from (768 MB). 
In this situation, allocating at the highest address in the lowest free 
memory range will allocate the buffer very low in memory, and in that case 
top_down doesn't mean much.

Walking memory from lowest to highest address but then allocating memory at 
the highest address inside the memory range is peculiar and surprising. Is 
there a particular reason for it?

If it's an accident and doesn't affect x86, I'd suggest that top_down should
have its expected behavior, which (at least for me) is: allocate from the
highest available memory address within the desired range.

In any case, my patch series allows each architecture to define what
top_down should mean. It doesn't change the behavior in x86, since
the default implementation of arch_kexec_walk_mem ignores
kexec_buf.top_down, and allows powerpc to take top_down into account
when walking memory.

> > > Should I add a separate top_down argument to kexec_locate_mem_hole to
> > > control if the memory walk should be from top to bottom, and then the
> > > bottom_up member of struct kexec_buf controls where inside each memory
> > > region the memory hole will be allocated?
> 
> Using one argument for both sounds more reasonable than using a separate
> argument for memory walk..

I agree. This patch doesn't use a separate top_down argument, it's the same
patch I sent earlier except that the comments to struct kexec_buf are in
patch 2/9. What do you think?

-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center


Subject: [PATCH 3/9] kexec_file: Factor out kexec_locate_mem_hole from
 kexec_add_buffer.

kexec_locate_mem_hole will be used by the PowerPC kexec_file_load
implementation to find free memory for the purgatory stack.

Signed-off-by: Thiago Jung Bauermann 
Cc: Eric Biederman 
Cc: Dave Young 
Cc: ke...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
---
 include/linux/kexec.h |  1 +
 kernel/kexec_file.c   | 25 -
 2 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index e16d845d587f..2b34e69db679 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -169,6 +169,7 @@ struct kexec_buf {
 
 int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
   int (*func)(u64, u64, void *));
+int kexec_locate_mem_hole(struct kexec_buf *kbuf);
 #endif /* CONFIG_KEXEC_FILE */
 
 struct kimage {
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index b1f1f6402518..445d66add8ca 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -449,6 +449,23 @@ int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
return walk_system_ram_res(0, ULONG_MAX, kbuf, func);
 }
 
+/**
+ * kexec_locate_mem_hole - find free memory to load segment or use in purgatory
+ * @kbuf:  Parameters for the memory search.
+ *
+ * On success, kbuf->mem will have the start address of the memory region 
found.
+ *
+ * Return: 0 on success, negative errno on error.
+ */
+int 

Re: [PATCH 29/38] powerpc: Move 32-bit probe() machine to later in the boot process

[Benjamin Herrenschmidt]

On Tue, 2016-06-28 at 15:25 +0200, Gerhard Pircher wrote:
> > No we could just add something to early_init_devtree that does clear
> > that bit if it sees the relevant piece of broken HW, it's not the AmigaOne 
> > per-se, it's the northbridge right ?
> Does that work for CPU_FTR_NEED_COHERENT, given that the feature fixups
> are done right after identify_cpu() and instructions within BEGIN_FTR_SECTION
> and END_FTR_SECTION* are patched out (if I understand this mechanism
> correctly) !?

Right that's a problem. We do the fixup before early_init_devtree() on
ppc32 (we don't on ppc64) ... ugh. I'll have to think about it. We can
try to make them match by moving the fixup but that means making
sure that the transition to the "initial" MMU mapping use for
machine_init() can be done without the fixups being applied.

I can have a quick sweep of the init code later today or tomorrow to
see how bad that would be.

Otherwise, compile option...

> But yes, the specific northbridge is the problem here.
> 
> > We could also make non-coherent cache a runtime option if we really
> > wanted, it's just more churn ...
> Yeah, I remember a discussion or two about this topic and I always wondered
> how driver code would differentiate then between non-coherent and coherent
> DMA, given that they sometimes require different handling of the DMA addresses
> (e.g. if I look at /sound/core/pcm_native.c or the DRM code).
> 
> > > > Do we know where the lockups come from btw ? A problem with the
> > > > northbridge ?
> > > Yes, it's a problem with the northbridge...as usual. :-(
> > 
> > Marvell ?
> No, the one with the dreaded "A" name: MAI Logic's "Articia S" :-)

Heh ok.

Cheers,
Ben.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [V4, 2/3] powerpc/opal: Add #define to get rc from an ASYNC_COMP opal_msg

[Suraj Jitindar Singh]

On Tue, 28 Jun 2016 21:58:28 +1000 (AEST)
Michael Ellerman  wrote:

> On Tue, 2016-28-06 at 04:40:56 UTC, Suraj Jitindar Singh wrote:
> > An opal_msg of type OPAL_MSG_ASYNC_COMP contains the return code in
> > the params[1] struct member. However this isn't intuitive or
> > obvious when reading the code and requires that a user look at the
> > skiboot documentation or opal-api.h to verify this.
> > 
> > Add a #define to get the return code from an opal_msg and update
> > call sites accordingly.  
> 
> Thanks for cleaning this up.
> 
> Two gripes though :)
> 
> >  arch/powerpc/include/asm/opal-api.h| 4   
> 
> opal-api.h is supposed to be a subset of the skiboot version.
> 
> So something like this should go in the kernel's opal.h, which has
> all the kernel prototypes etc. which aren't part of the OPAL API. I
> think this routine should fall under that.
Will move this
> 
> > diff --git a/arch/powerpc/include/asm/opal-api.h
> > b/arch/powerpc/include/asm/opal-api.h index 9bb8ddf..7433cf0 100644
> > --- a/arch/powerpc/include/asm/opal-api.h
> > +++ b/arch/powerpc/include/asm/opal-api.h
> > @@ -387,6 +387,10 @@ struct opal_msg {
> > __be64 params[8];
> >  };
> >  
> > +#define GET_OPAL_MSG_ASYNC_COMP_RC(msg)(msg.msg_type ==
> > OPAL_MSG_ASYNC_COMP ? \
> > +
> > be64_to_cpu(msg.params[1]) : \
> > +   OPAL_PARAMETER)
> > +  
> 
> You forgot the 7th commandment!
> 
>  "Never use a #define when a static inline would work"
> 
> :)
> 
> A few reasons:
>   - it's less shouty.
>   - you get type checking.
>   - you don't have to wrap lines with \
> etc.
> 
> cheers
Thanks, will change this
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH V5 1/3] devicetree/bindings: Add binding for operator panel on FSP machines

[Suraj Jitindar Singh]

Add a binding to Documentation/devicetree/bindings/powerpc/opal
(oppanel-opal.txt) for the operator panel which is present on IBM
Power Systems machines with FSPs.

Signed-off-by: Suraj Jitindar Singh 
Acked-by: Rob Herring 
Acked-by: Stewart Smith 

---

Change Log:

V1 -> V2:
- Nothing
V2 -> V3:
- Change "IBM pseries machines" to "IBM Power Systems machines"
in the commit message for improved clarity.
V3 -> V5:
- Nothing
---
 .../devicetree/bindings/powerpc/opal/oppanel-opal.txt  | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/powerpc/opal/oppanel-opal.txt

diff --git a/Documentation/devicetree/bindings/powerpc/opal/oppanel-opal.txt 
b/Documentation/devicetree/bindings/powerpc/opal/oppanel-opal.txt
new file mode 100644
index 000..dffb791
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/opal/oppanel-opal.txt
@@ -0,0 +1,14 @@
+IBM OPAL Operator Panel Binding
+---
+
+Required properties:
+- compatible : Should be "ibm,opal-oppanel".
+- #lines : Number of lines on the operator panel e.g. <0x2>.
+- #length: Number of characters per line of the operator panel e.g. <0x10>.
+
+Example:
+   oppanel {
+   compatible = "ibm,opal-oppanel";
+   #lines = <0x2>;
+   #length = <0x10>;
+   };
-- 
2.5.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH V5 3/3] powerpc/drivers: Add driver for operator panel on FSP machines

[Suraj Jitindar Singh]

Implement new character device driver to allow access from user space
to the operator panel display present on IBM Power Systems machines
with FSPs.

This will allow status information to be presented on the display which
is visible to a user.

The driver implements a character buffer which a user can read/write
by accessing the device (/dev/op_panel). This buffer is then displayed on
the operator panel display. Any attempt to write past the last character
position will have no effect and attempts to write more characters than
the size of the display will be truncated. The device may only be accessed
by a single process at a time.

Signed-off-by: Suraj Jitindar Singh 
Reviewed-by: Andrew Donnellan 

---

Change Log:

V1 -> V2:
- Replace "IBM pSeries machines" with "IBM Power Systems machines
with FSPs" for improved clarity
- Basic wording/grammar fixes
V2 -> V3:
- Nothing
V3 -> V4:
- Various style changes and non-functional code updates
V4 -> V5:
- Nothing
---
 MAINTAINERS|   6 +
 arch/powerpc/configs/powernv_defconfig |   1 +
 arch/powerpc/include/asm/opal.h|   2 +
 arch/powerpc/platforms/powernv/opal-wrappers.S |   1 +
 arch/powerpc/platforms/powernv/opal.c  |   5 +
 drivers/char/Kconfig   |  14 ++
 drivers/char/Makefile  |   1 +
 drivers/char/powernv-op-panel.c| 223 +
 8 files changed, 253 insertions(+)
 create mode 100644 drivers/char/powernv-op-panel.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 952fd2a..42ace38 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9094,6 +9094,12 @@ F:   drivers/firmware/psci.c
 F: include/linux/psci.h
 F: include/uapi/linux/psci.h
 
+POWERNV OPERATOR PANEL LCD DISPLAY DRIVER
+M: Suraj Jitindar Singh 
+L: linuxppc-dev@lists.ozlabs.org
+S: Maintained
+F: drivers/char/powernv-op-panel.c
+
 PNP SUPPORT
 M: "Rafael J. Wysocki" 
 S: Maintained
diff --git a/arch/powerpc/configs/powernv_defconfig 
b/arch/powerpc/configs/powernv_defconfig
index 0450310..959d32b 100644
--- a/arch/powerpc/configs/powernv_defconfig
+++ b/arch/powerpc/configs/powernv_defconfig
@@ -181,6 +181,7 @@ CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_JSM=m
 CONFIG_VIRTIO_CONSOLE=m
+CONFIG_POWERNV_OP_PANEL=m
 CONFIG_IPMI_HANDLER=y
 CONFIG_IPMI_DEVICE_INTERFACE=y
 CONFIG_IPMI_POWERNV=y
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 0d4e690..ea9e7f4 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -178,6 +178,8 @@ int64_t opal_dump_ack(uint32_t dump_id);
 int64_t opal_dump_resend_notification(void);
 
 int64_t opal_get_msg(uint64_t buffer, uint64_t size);
+int64_t opal_write_oppanel_async(uint64_t token, oppanel_line_t *lines,
+   uint64_t num_lines);
 int64_t opal_check_completion(uint64_t buffer, uint64_t size, uint64_t token);
 int64_t opal_sync_host_reboot(void);
 int64_t opal_get_param(uint64_t token, uint32_t param_id, uint64_t buffer,
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S 
b/arch/powerpc/platforms/powernv/opal-wrappers.S
index e45b88a..ddba8bf 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -278,6 +278,7 @@ OPAL_CALL(opal_dump_info2,  
OPAL_DUMP_INFO2);
 OPAL_CALL(opal_dump_read,  OPAL_DUMP_READ);
 OPAL_CALL(opal_dump_ack,   OPAL_DUMP_ACK);
 OPAL_CALL(opal_get_msg,OPAL_GET_MSG);
+OPAL_CALL(opal_write_oppanel_async,OPAL_WRITE_OPPANEL_ASYNC);
 OPAL_CALL(opal_check_completion,   OPAL_CHECK_ASYNC_COMPLETION);
 OPAL_CALL(opal_dump_resend_notification,   OPAL_DUMP_RESEND);
 OPAL_CALL(opal_sync_host_reboot,   OPAL_SYNC_HOST_REBOOT);
diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index 0256d07..228751a 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -751,6 +751,9 @@ static int __init opal_init(void)
opal_pdev_init(opal_node, "ibm,opal-flash");
opal_pdev_init(opal_node, "ibm,opal-prd");
 
+   /* Initialise platform device: oppanel interface */
+   opal_pdev_init(opal_node, "ibm,opal-oppanel");
+
/* Initialise OPAL kmsg dumper for flushing console on panic */
opal_kmsg_init();
 
@@ -885,3 +888,5 @@ EXPORT_SYMBOL_GPL(opal_i2c_request);
 /* Export these symbols for PowerNV LED class driver */
 EXPORT_SYMBOL_GPL(opal_leds_get_ind);
 EXPORT_SYMBOL_GPL(opal_leds_set_ind);
+/* Export this symbol for PowerNV Operator Panel class driver */
+EXPORT_SYMBOL_GPL(opal_write_oppanel_async);
diff --git 

[PATCH V5 2/3] powerpc/opal: Add inline function to get rc from an ASYNC_COMP opal_msg

[Suraj Jitindar Singh]

An opal_msg of type OPAL_MSG_ASYNC_COMP contains the return code in the
params[1] struct member. However this isn't intuitive or obvious when
reading the code and requires that a user look at the skiboot
documentation or opal-api.h to verify this.

Add an inline function to get the return code from an opal_msg and update
call sites accordingly.

Signed-off-by: Suraj Jitindar Singh 

---

Change Log:

-> V4:
- Added Patch to Series
V4 -> V5:
- Changed from #define in opal-api.h to inline in opal.h
---
 arch/powerpc/include/asm/opal.h| 8 
 arch/powerpc/platforms/powernv/opal-sensor.c   | 2 +-
 arch/powerpc/platforms/powernv/opal-sysparam.c | 4 ++--
 drivers/i2c/busses/i2c-opal.c  | 2 +-
 drivers/leds/leds-powernv.c| 2 +-
 drivers/mtd/devices/powernv_flash.c| 2 +-
 drivers/rtc/rtc-opal.c | 4 ++--
 7 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 9d86c66..0d4e690 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -276,6 +276,14 @@ extern int opal_error_code(int rc);
 
 ssize_t opal_msglog_copy(char *to, loff_t pos, size_t count);
 
+static inline int opal_get_async_rc(struct opal_msg msg)
+{
+   if (msg.msg_type != OPAL_MSG_ASYNC_COMP)
+   return OPAL_PARAMETER;
+   else
+   return be64_to_cpu(msg.params[1]);
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* _ASM_POWERPC_OPAL_H */
diff --git a/arch/powerpc/platforms/powernv/opal-sensor.c 
b/arch/powerpc/platforms/powernv/opal-sensor.c
index a06059d..308efd1 100644
--- a/arch/powerpc/platforms/powernv/opal-sensor.c
+++ b/arch/powerpc/platforms/powernv/opal-sensor.c
@@ -55,7 +55,7 @@ int opal_get_sensor_data(u32 sensor_hndl, u32 *sensor_data)
goto out_token;
}
 
-   ret = opal_error_code(be64_to_cpu(msg.params[1]));
+   ret = opal_error_code(opal_get_async_rc(msg));
*sensor_data = be32_to_cpu(data);
break;
 
diff --git a/arch/powerpc/platforms/powernv/opal-sysparam.c 
b/arch/powerpc/platforms/powernv/opal-sysparam.c
index afe66c5..23fb664 100644
--- a/arch/powerpc/platforms/powernv/opal-sysparam.c
+++ b/arch/powerpc/platforms/powernv/opal-sysparam.c
@@ -67,7 +67,7 @@ static ssize_t opal_get_sys_param(u32 param_id, u32 length, 
void *buffer)
goto out_token;
}
 
-   ret = opal_error_code(be64_to_cpu(msg.params[1]));
+   ret = opal_error_code(opal_get_async_rc(msg));
 
 out_token:
opal_async_release_token(token);
@@ -103,7 +103,7 @@ static int opal_set_sys_param(u32 param_id, u32 length, 
void *buffer)
goto out_token;
}
 
-   ret = opal_error_code(be64_to_cpu(msg.params[1]));
+   ret = opal_error_code(opal_get_async_rc(msg));
 
 out_token:
opal_async_release_token(token);
diff --git a/drivers/i2c/busses/i2c-opal.c b/drivers/i2c/busses/i2c-opal.c
index 75dd6d0..11e2a1f 100644
--- a/drivers/i2c/busses/i2c-opal.c
+++ b/drivers/i2c/busses/i2c-opal.c
@@ -71,7 +71,7 @@ static int i2c_opal_send_request(u32 bus_id, struct 
opal_i2c_request *req)
if (rc)
goto exit;
 
-   rc = be64_to_cpu(msg.params[1]);
+   rc = opal_get_async_rc(msg);
if (rc != OPAL_SUCCESS) {
rc = i2c_opal_translate_error(rc);
goto exit;
diff --git a/drivers/leds/leds-powernv.c b/drivers/leds/leds-powernv.c
index dfb8bd3..b2a98c7 100644
--- a/drivers/leds/leds-powernv.c
+++ b/drivers/leds/leds-powernv.c
@@ -118,7 +118,7 @@ static int powernv_led_set(struct powernv_led_data 
*powernv_led,
goto out_token;
}
 
-   rc = be64_to_cpu(msg.params[1]);
+   rc = opal_get_async_rc(msg);
if (rc != OPAL_SUCCESS)
dev_err(dev, "%s : OAPL async call returned failed [rc=%d]\n",
__func__, rc);
diff --git a/drivers/mtd/devices/powernv_flash.c 
b/drivers/mtd/devices/powernv_flash.c
index d5b870b..f5396f2 100644
--- a/drivers/mtd/devices/powernv_flash.c
+++ b/drivers/mtd/devices/powernv_flash.c
@@ -95,7 +95,7 @@ static int powernv_flash_async_op(struct mtd_info *mtd, enum 
flash_op op,
return -EIO;
}
 
-   rc = be64_to_cpu(msg.params[1]);
+   rc = opal_get_async_rc(msg);
if (rc == OPAL_SUCCESS) {
rc = 0;
if (retlen)
diff --git a/drivers/rtc/rtc-opal.c b/drivers/rtc/rtc-opal.c
index 9c18d6f..ea20f62 100644
--- a/drivers/rtc/rtc-opal.c
+++ b/drivers/rtc/rtc-opal.c
@@ -134,7 +134,7 @@ static int opal_get_tpo_time(struct device *dev, struct 
rtc_wkalrm *alarm)
goto exit;
}
 
-   rc = be64_to_cpu(msg.params[1]);
+   rc = opal_get_async_rc(msg);
if (rc != OPAL_SUCCESS) {
rc = -EIO;
goto 

Re: [PATCH 1/4] kvm/ppc/book3s_hv: Change vcore element runnable_threads from linked-list to array

[Suraj Jitindar Singh]

On 24/06/16 19:59, Paul Mackerras wrote:
> On Wed, Jun 15, 2016 at 07:21:05PM +1000, Suraj Jitindar Singh wrote:
>> The struct kvmppc_vcore is a structure used to store various information
>> about a virtual core for a kvm guest. The runnable_threads element of the
>> struct provides a list of all of the currently runnable vcpus on the core
>> (those in the KVMPPC_VCPU_RUNNABLE state). The previous implementation of
>> this list was a linked_list. The next patch requires that the list be able
>> to be iterated over without holding the vcore lock.
>>
>> Reimplement the runnable_threads list in the kvmppc_vcore struct as an
>> array. Implement function to iterate over valid entries in the array and
>> update access sites accordingly.
>>
>> Signed-off-by: Suraj Jitindar Singh 
> Unfortunately I get a compile error when compiling for either a 32-bit
> powerpc config (e.g. pmac32_defconfig with KVM turned on) or a Book E
> config.  The error is:
>
> In file included from /home/paulus/kernel/kvm/include/linux/kvm_host.h:36:0,
>  from 
> /home/paulus/kernel/kvm/arch/powerpc/kernel/asm-offsets.c:54:
> /home/paulus/kernel/kvm/arch/powerpc/include/asm/kvm_host.h:299:36: error: 
> ‘MAX_SMT_THREADS’ undeclared here (not in a function)
>   struct kvm_vcpu *runnable_threads[MAX_SMT_THREADS];
> ^
> /home/paulus/kernel/kvm/./Kbuild:81: recipe for target 
> 'arch/powerpc/kernel/asm-offsets.s' failed
>
> You are using MAX_SMT_THREADS in kvm_host.h, but it is defined in
> kvm_book3s_asm.h, which gets included by asm-offsets.c after it
> include kvm_host.h.  I don't think we can just make kvm_host.h include
> book3s.h.  The best solution might be to move the definition of struct
> kvmppc_vcore to kvm_book3s.h.

Thanks for catching that, yeah I see.

I don't think we can trivially move the struct kvmppc_vcore definition into 
kvm_book3s.h as other code in kvm_host.h (i.e. struct kvm_vcpu_arch) requires
the definition. I was thinking that I could just put runnable_threads inside an 
#ifdef.

#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
struct kvm_vcpu *runnable_threads[MAX_SMT_THREADS];
#endif

Suraj.

>
> Paul.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCHv2, 2/7] ppc: bpf/jit: Fix/enhance 32-bit Load Immediate implementation

[Michael Ellerman]

On Wed, 2016-22-06 at 16:25:02 UTC, "Naveen N. Rao" wrote:
> The existing LI32() macro can sometimes result in a sign-extended 32-bit
> load that does not clear the top 32-bits properly. As an example,
> loading 0x7fff results in the register containing
> 0x7fff. While this does not impact classic BPF JIT
> implementation (since that only uses the lower word for all operations),
> we would like to share this macro between classic BPF JIT and extended
> BPF JIT, wherein the entire 64-bit value in the register matters. Fix
> this by first doing a shifted LI followed by ORI.
> 
> An additional optimization is with loading values between -32768 to -1,
> where we now only need a single LI.
> 
> The new implementation now generates the same or less number of
> instructions.
> 
> Acked-by: Alexei Starovoitov 
> Signed-off-by: Naveen N. Rao 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/aaf2f7e09932a08c1287d8e4c6

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [v6, 07/11] powerpc/powernv: set power_save func after the idle states are initialized

[Michael Ellerman]

On Wed, 2016-08-06 at 16:54:27 UTC, "Shreyas B. Prabhu" wrote:
> pnv_init_idle_states discovers supported idle states from the
> device tree and does the required initialization. Set power_save
> function pointer only after this initialization is done
> 
> Reviewed-by: Gautham R. Shenoy 
> Signed-off-by: Shreyas B. Prabhu 
> Acked-by: Benjamin Herrenschmidt 
> Acked-by: Michael Neuling 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/5593e3032736ccba30d28bd27e

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev