[PATCH] ibmveth: Add a proper check for the availability of the checksum features

[Thomas Huth]

When using the ibmveth driver in a KVM/QEMU based VM, it currently
always prints out a scary error message like this when it is started:

 ibmveth 7103 (unregistered net_device): unable to change
 checksum offload settings. 1 rc=-2 ret_attr=7103

This happens because the driver always tries to enable the checksum
offloading without checking for the availability of this feature first.
QEMU does not support checksum offloading for the spapr-vlan device,
thus we always get the error message here.
According to the LoPAPR specification, the "ibm,illan-options" property
of the corresponding device tree node should be checked first to see
whether the H_ILLAN_ATTRIUBTES hypercall and thus the checksum offloading
feature is available. Thus let's do this in the ibmveth driver, too, so
that the error message is really only limited to cases where something
goes wrong, and does not occur if the feature is just missing.

Signed-off-by: Thomas Huth 
---
 drivers/net/ethernet/ibm/ibmveth.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/ibm/ibmveth.c 
b/drivers/net/ethernet/ibm/ibmveth.c
index a831f94..309f5c6 100644
--- a/drivers/net/ethernet/ibm/ibmveth.c
+++ b/drivers/net/ethernet/ibm/ibmveth.c
@@ -1601,8 +1601,11 @@ static int ibmveth_probe(struct vio_dev *dev, const 
struct vio_device_id *id)
netdev->netdev_ops = _netdev_ops;
netdev->ethtool_ops = _ethtool_ops;
SET_NETDEV_DEV(netdev, >dev);
-   netdev->hw_features = NETIF_F_SG | NETIF_F_RXCSUM |
-   NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
+   netdev->hw_features = NETIF_F_SG;
+   if (vio_get_attribute(dev, "ibm,illan-options", NULL) != NULL) {
+   netdev->hw_features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
+  NETIF_F_RXCSUM;
+   }
 
netdev->features |= netdev->hw_features;
 
-- 
1.8.3.1

Re: BUILD_BUG_ON(!__builtin_constant_p(feature)) breaks bcc trace tool

[Michael Ellerman]

Anton Blanchard  writes:
>> We added:
>> 
>> BUILD_BUG_ON(!__builtin_constant_p(feature)) 
>> 
>> to cpu_has_feature() and mmu_has_feature() in order to catch usage
>> issues (such as cpu_has_feature(cpu_has_feature(X)). Unfortunately
>> LLVM isn't smart enough to resolve this, and it errors out.
>> 
>> I work around it in my clang/LLVM builds of the kernel, but I have
>> just discovered that it causes a lot of issues for the bcc (eBPF)
>> trace tool (which uses LLVM).
>> 
>> How should we work around this? Wrap the checks in !clang perhaps?
>
> Looks like it's a weakness in LLVM with inlining:
>
> #include 
>
> #if 1
> static inline void foo(unsigned long x)
> {
> assert(__builtin_constant_p(x));
> }
> #else
> #define foo(X) assert(__builtin_constant_p(X))
> #endif
>
> int main(void)
> {
> foo(1);
>
> return 0;
> }

OK. cpu_has_feature() is __always_inline:

static __always_inline bool cpu_has_feature(unsigned long feature)
{
int i;

BUILD_BUG_ON(!__builtin_constant_p(feature));


But I guess even that doesn't work?

Hmm, in fact it seems because we don't define
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING and CONFIG_OPTIMIZE_INLINING, we
get:

#define inline  inline  __attribute__((always_inline)) notrace

So in fact every inline function is marked always_inline all the time,
which seems dubious.

But still, it seems clang is ignoring always_inline.

cheers

Re: BUILD_BUG_ON(!__builtin_constant_p(feature)) breaks bcc trace tool

[Michael Ellerman]

Anton Blanchard  writes:
> We added:
>
> BUILD_BUG_ON(!__builtin_constant_p(feature)) 
>
> to cpu_has_feature() and mmu_has_feature() in order to catch usage
> issues (such as cpu_has_feature(cpu_has_feature(X)). Unfortunately LLVM
> isn't smart enough to resolve this, and it errors out.
>
> I work around it in my clang/LLVM builds of the kernel, but I have just
> discovered that it causes a lot of issues for the bcc (eBPF) trace tool
> (which uses LLVM).

I didn't understand that part, but Aneesh explained to me that it's
because bcc pulls in the kernel-internal headers.

I guess as a quick fix we just have to #ifdef it, can you confirm this
works?


diff --git a/arch/powerpc/include/asm/cpu_has_feature.h 
b/arch/powerpc/include/asm/cpu_has_feature.h
index b312b152461b..6e834caa3720 100644
--- a/arch/powerpc/include/asm/cpu_has_feature.h
+++ b/arch/powerpc/include/asm/cpu_has_feature.h
@@ -23,7 +23,9 @@ static __always_inline bool cpu_has_feature(unsigned long 
feature)
 {
int i;
 
+#ifndef __clang__ /* clang can't cope with this */
BUILD_BUG_ON(!__builtin_constant_p(feature));
+#endif
 
 #ifdef CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG
if (!static_key_initialized) {
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index a34c764ca8dd..233a7e8cc8e3 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -160,7 +160,9 @@ static __always_inline bool mmu_has_feature(unsigned long 
feature)
 {
int i;
 
+#ifndef __clang__ /* clang can't cope with this */
BUILD_BUG_ON(!__builtin_constant_p(feature));
+#endif
 
 #ifdef CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG
if (!static_key_initialized) {


cheers

Bad block Management Patch

[Anurag Raghavan (RBEI/ETW11)]

Hi Boris,


I am using kernel version-3.0.35
I am facing uncorrectable ECC error in ubifs. I am suspecting, it is because of 
bad blocks are not properly handled in my driver.
Is there any patches available to handle the bad block in the specified 
version...


Best regards

Raghavan Anurag
RBEI/ETW1

Tel. +91(422)667-4001 | Mobil 9986968950

Re: powerpc/pasemi/nemo: Fix low memory values for boot.

[Michael Ellerman]

Darren Stevens  writes:
> On 23/01/2017, Michael Ellerman wrote:
>>> Clearing the long long at addr 8 has been shown to fix this, so
>>> add an initalisation to head_64.S so the system will boot.
>>
>> I'd really prefer it if someone could tell me why we need to clear it.
>> But I assume no one knows?
...
>
> I took a long look today and traced the problem the 'prom_find_boot_cpu' and a
> much better patch will follow.

Awesome work, thanks.

cheers

Re: [bug] stack protector panics on v4.10-rc1+

[Michael Ellerman]

Michael Ellerman  writes:

> Segher Boessenkool  writes:
>
>> On Mon, Jan 23, 2017 at 07:10:00PM -0500, Jan Stancek wrote:
>>> I'm running into panics with stack protector enabled on ppc64le
>>
>>> I came across following gcc commit:
>>>   
>>> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0d55f4d0aeaeb16629a2c07c96a190695b83a7e6
>>> which mentions offset above:
>>>   "If TARGET_THREAD_SSP_OFFSET is defined, use -0x7010(13) resp.
>>>-0x7008(2) instead of reading __stack_chk_guard variable."
>>> 
>>> It looks like it's not reading canary value from __stack_chk_guard variable.
>>> atm. I'm not sure where -28688(r13) falls in ppc kernel (somewhere near 
>>> paca struct?).
>>> 
>>> Is anyone else seeing these panics?
>>
>> Everyone is.
>
> Are they? I'm not?
>
>> This is fixed in GCC 8 (and will be backported to GCC 7 and GCC 6 and
>> maybe even GCC 5).  See  (and r244562 and
>> r244677).
>
> # cat /proc/version 
> Linux version 4.10.0-rc5-compiler_gcc-6.3.0-6-ge357eb97a6be 
> (mich...@ka3.ozlabs.ibm.com) (gcc version 6.3.0 (Custom 4b5e15daff8b5444) ) 
> #558 SMP Tue Jan 24 14:29:04 AEDT 2017
>
> # zgrep STACKPROTECTOR /proc/config.gz 
> CONFIG_HAVE_CC_STACKPROTECTOR=y
> CONFIG_CC_STACKPROTECTOR=y
> CONFIG_CC_STACKPROTECTOR_REGULAR=y
>
> I guess I'm just lucky?

No, I'm just using a gcc built without libc as Segher pointed out:

  https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg113181.html

  Right.  Tony's compilers are built using a (modified version of) buildall,
  and buildall goes out of its way to build without libc whatsoever, even
  if the configuration (powerpc64-linux, for example) expects one.
  
  Which leads to TARGET_LIBC_PROVIDES_SSP being undefined (it would normally
  be true for glibc >= 2.4), and that is all.  Mystery solved.  Thanks!


So my inclination is to revert the powerpc stack protector code for
4.10, and we can try again for 4.11 or 12.

cheers

Re: [bug] stack protector panics on v4.10-rc1+

[Michael Ellerman]

Segher Boessenkool  writes:

> On Mon, Jan 23, 2017 at 07:10:00PM -0500, Jan Stancek wrote:
>> I'm running into panics with stack protector enabled on ppc64le
>
>> I came across following gcc commit:
>>   
>> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0d55f4d0aeaeb16629a2c07c96a190695b83a7e6
>> which mentions offset above:
>>   "If TARGET_THREAD_SSP_OFFSET is defined, use -0x7010(13) resp.
>>-0x7008(2) instead of reading __stack_chk_guard variable."
>> 
>> It looks like it's not reading canary value from __stack_chk_guard variable.
>> atm. I'm not sure where -28688(r13) falls in ppc kernel (somewhere near paca 
>> struct?).
>> 
>> Is anyone else seeing these panics?
>
> Everyone is.

Are they? I'm not?

> This is fixed in GCC 8 (and will be backported to GCC 7 and GCC 6 and
> maybe even GCC 5).  See  (and r244562 and
> r244677).

# cat /proc/version 
Linux version 4.10.0-rc5-compiler_gcc-6.3.0-6-ge357eb97a6be 
(mich...@ka3.ozlabs.ibm.com) (gcc version 6.3.0 (Custom 4b5e15daff8b5444) ) 
#558 SMP Tue Jan 24 14:29:04 AEDT 2017

# zgrep STACKPROTECTOR /proc/config.gz 
CONFIG_HAVE_CC_STACKPROTECTOR=y
CONFIG_CC_STACKPROTECTOR=y
CONFIG_CC_STACKPROTECTOR_REGULAR=y

I guess I'm just lucky?

cheers

Re: [PATCH tip/core/rcu 2/3] srcu: Force full grace-period ordering

[Paul E. McKenney]

On Mon, Jan 23, 2017 at 07:12:03PM +1100, Michael Ellerman wrote:
> "Paul E. McKenney"  writes:
> 
> > On Sat, Jan 14, 2017 at 11:54:17AM -0800, Paul E. McKenney wrote:
> >> On Sat, Jan 14, 2017 at 10:35:50AM +0100, Ingo Molnar wrote:
> >> > * Paul E. McKenney  wrote:
> >
> > [ . . . ]
> >
> >> > > + */
> >> > > +#ifdef CONFIG_PPC
> >> > > +#define smp_mb__after_unlock_lock()   smp_mb()  /* Full ordering for 
> >> > > lock. */
> >> > > +#else /* #ifdef CONFIG_PPC */
> >> > > +#define smp_mb__after_unlock_lock()   do { } while (0)
> >> > > +#endif /* #else #ifdef CONFIG_PPC */
> >> > 
> >> > Yeah, so I realize that this was pre-existing code, but putting 
> >> > CONFIG_$ARCH
> >> > #ifdefs into generic headers is generally frowned upon.
> >> > 
> >> > The canonical approach would be either to define a helper Kconfig 
> >> > variable that 
> >> > can be set by PPC (but other architectures don't need to set it), or to 
> >> > expose a 
> >> > suitable macro (function) for architectures to define in their barrier.h 
> >> > arch 
> >> > header file.
> >> 
> >> Very well, I will add a separate commit for this.  4.11 OK?
> >
> > Does the patch below seem reasonable?
> >
> > Thanx, Paul
> >
> > 
> >
> > commit 271c0601237c41a279f975563e13837bace0df03
> > Author: Paul E. McKenney 
> > Date:   Sat Jan 14 13:32:50 2017 -0800
> >
> > rcu: Make arch select smp_mb__after_unlock_lock() strength
> > 
> > The definition of smp_mb__after_unlock_lock() is currently smp_mb()
> > for CONFIG_PPC and a no-op otherwise.  It would be better to instead
> > provide an architecture-selectable Kconfig option, and select the
> > strength of smp_mb__after_unlock_lock() based on that option.  This
> > commit therefore creates CONFIG_ARCH_WEAK_RELACQ, has PPC select it,
> > and bases the definition of smp_mb__after_unlock_lock() on this new
> > CONFIG_ARCH_WEAK_RELACQ Kconfig option.
> > 
> > Reported-by: Ingo Molnar 
> > Signed-off-by: Paul E. McKenney 
> > Cc: Peter Zijlstra 
> > Cc: Will Deacon 
> > Cc: Boqun Feng 
> > Cc: Benjamin Herrenschmidt 
> > Cc: Paul Mackerras 
> > Cc: Michael Ellerman 
> > Cc: 
> 
> Personally I'd call it ARCH_WEAK_RELEASE_ACQUIRE, which is longer but
> clearer I think. But it's not a big deal, so which ever you prefer.

ARCH_WEAK_RELEASE_ACQUIRE it is!

> Acked-by: Michael Ellerman 

Applied, thank you!

Thanx, Paul

Re: [bug] stack protector panics on v4.10-rc1+

[Segher Boessenkool]

On Mon, Jan 23, 2017 at 07:10:00PM -0500, Jan Stancek wrote:
> I'm running into panics with stack protector enabled on ppc64le

> I came across following gcc commit:
>   
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0d55f4d0aeaeb16629a2c07c96a190695b83a7e6
> which mentions offset above:
>   "If TARGET_THREAD_SSP_OFFSET is defined, use -0x7010(13) resp.
>-0x7008(2) instead of reading __stack_chk_guard variable."
> 
> It looks like it's not reading canary value from __stack_chk_guard variable.
> atm. I'm not sure where -28688(r13) falls in ppc kernel (somewhere near paca 
> struct?).
> 
> Is anyone else seeing these panics?

Everyone is.

This is fixed in GCC 8 (and will be backported to GCC 7 and GCC 6 and
maybe even GCC 5).  See  (and r244562 and
r244677).

The kernel will need to use -mstack-protector-guard=global for now, and
it later can use -mstack-protector-guard=tls -mstack-protector-register=
-mstack-protector-offset=.  If your GCC does not support this yet
(most people's situation right now) you cannot use the stack protector in
the kernel.


Segher

Re: [bug] stack protector panics on v4.10-rc1+

[Tyrel Datwyler]

On 01/23/2017 04:10 PM, Jan Stancek wrote:
> Hi,
> 
> I'm running into panics with stack protector enabled on ppc64le
> lpar (IBM,8408-E8E), starting with:
> 
> commit 6533b7c16ee5712041b4e324100550e02a9a5dda
> Author: Christophe Leroy 
> Date:   Tue Nov 22 11:49:30 2016 +0100
> powerpc: Initial stack protector (-fstack-protector) support
> 
> CONFIG_HAVE_CC_STACKPROTECTOR=y
> CONFIG_CC_STACKPROTECTOR=y
> # CONFIG_CC_STACKPROTECTOR_NONE is not set
> # CONFIG_CC_STACKPROTECTOR_REGULAR is not set
> CONFIG_CC_STACKPROTECTOR_STRONG=y
> 
> For example (it crashes at various places):
> [1.028466] systemd[1]: Set hostname to . 
> [1.036105] Kernel panic - not syncing: stack-protector: Kernel stack is 
> corrupted in: c0ad2250 
> [1.036105]  
> [1.036124] CPU: 5 PID: 168 Comm: dracut-rootfs-g Tainted: GW  
>  4.0.0+ #11 
> [1.036131] Call Trace: 
> [1.036141] [c000fe113a80] [c0af13e8] dump_stack+0xa0/0xdc 
> (unreliable) 
> [1.036153] [c000fe113ab0] [c0ae5138] panic+0x110/0x2bc 
> [1.036163] [c000fe113b40] [c00dd664] 
> __stack_chk_fail+0x24/0x30 
> [1.036172] [c000fe113ba0] [c0ad2250] 
> wait_for_completion+0x190/0x1a0 
> [1.036182] [c000fe113c20] [c0221920] stop_one_cpu+0x110/0x1b0 
> [1.036191] [c000fe113d00] [c0134a58] sched_exec+0xf8/0x180 
> [1.036200] [c000fe113d60] [c03b0f74] SyS_execve+0x414/0xb10 
> [1.036210] [c000fe113e30] [c0009308] system_call+0x38/0xb4 
> [1.052902] Rebooting in 10 seconds.. 
> 
> I tried applying this commit on older kernels, and every kernel I tried, going
> back as far as 3.10 was panic-ing early during boot on stack corruption.
> I tried gcc-4.8.5-11.el7, and Fedora 25's gcc-6.3.1-1.fc25 with same result.
> 
> (gdb) disassemble wait_for_completion
> Dump of assembler code for function wait_for_completion:
> ...
>0xc0c6642c <+140>:   ld  r9,-28688(r13)
>0xc0c66430 <+144>:   xor.r8,r8,r9
>0xc0c66434 <+148>:   li  r9,0
>0xc0c66438 <+152>:   bne-0xc0c665d8 
> 
> ...
>0xc0c665d8 <+568>:   bl  0xc00f5c68 
> <__stack_chk_fail+8>
> 
> I came across following gcc commit:
>   
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0d55f4d0aeaeb16629a2c07c96a190695b83a7e6
> which mentions offset above:
>   "If TARGET_THREAD_SSP_OFFSET is defined, use -0x7010(13) resp.
>-0x7008(2) instead of reading __stack_chk_guard variable."
> 
> It looks like it's not reading canary value from __stack_chk_guard variable.
> atm. I'm not sure where -28688(r13) falls in ppc kernel (somewhere near paca 
> struct?).
> 
> Is anyone else seeing these panics?

I believe there was some discussion in the following thread:

https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg112813.html

-Tyrel

> 
> Regards,
> Jan
> 

[bug] stack protector panics on v4.10-rc1+

[Jan Stancek]

Hi,

I'm running into panics with stack protector enabled on ppc64le
lpar (IBM,8408-E8E), starting with:

commit 6533b7c16ee5712041b4e324100550e02a9a5dda
Author: Christophe Leroy 
Date:   Tue Nov 22 11:49:30 2016 +0100
powerpc: Initial stack protector (-fstack-protector) support

CONFIG_HAVE_CC_STACKPROTECTOR=y
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR_NONE is not set
# CONFIG_CC_STACKPROTECTOR_REGULAR is not set
CONFIG_CC_STACKPROTECTOR_STRONG=y

For example (it crashes at various places):
[1.028466] systemd[1]: Set hostname to . 
[1.036105] Kernel panic - not syncing: stack-protector: Kernel stack is 
corrupted in: c0ad2250 
[1.036105]  
[1.036124] CPU: 5 PID: 168 Comm: dracut-rootfs-g Tainted: GW   
4.0.0+ #11 
[1.036131] Call Trace: 
[1.036141] [c000fe113a80] [c0af13e8] dump_stack+0xa0/0xdc 
(unreliable) 
[1.036153] [c000fe113ab0] [c0ae5138] panic+0x110/0x2bc 
[1.036163] [c000fe113b40] [c00dd664] __stack_chk_fail+0x24/0x30 
[1.036172] [c000fe113ba0] [c0ad2250] 
wait_for_completion+0x190/0x1a0 
[1.036182] [c000fe113c20] [c0221920] stop_one_cpu+0x110/0x1b0 
[1.036191] [c000fe113d00] [c0134a58] sched_exec+0xf8/0x180 
[1.036200] [c000fe113d60] [c03b0f74] SyS_execve+0x414/0xb10 
[1.036210] [c000fe113e30] [c0009308] system_call+0x38/0xb4 
[1.052902] Rebooting in 10 seconds.. 

I tried applying this commit on older kernels, and every kernel I tried, going
back as far as 3.10 was panic-ing early during boot on stack corruption.
I tried gcc-4.8.5-11.el7, and Fedora 25's gcc-6.3.1-1.fc25 with same result.

(gdb) disassemble wait_for_completion
Dump of assembler code for function wait_for_completion:
...
   0xc0c6642c <+140>:   ld  r9,-28688(r13)
   0xc0c66430 <+144>:   xor.r8,r8,r9
   0xc0c66434 <+148>:   li  r9,0
   0xc0c66438 <+152>:   bne-0xc0c665d8 

...
   0xc0c665d8 <+568>:   bl  0xc00f5c68 <__stack_chk_fail+8>

I came across following gcc commit:
  
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0d55f4d0aeaeb16629a2c07c96a190695b83a7e6
which mentions offset above:
  "If TARGET_THREAD_SSP_OFFSET is defined, use -0x7010(13) resp.
   -0x7008(2) instead of reading __stack_chk_guard variable."

It looks like it's not reading canary value from __stack_chk_guard variable.
atm. I'm not sure where -28688(r13) falls in ppc kernel (somewhere near paca 
struct?).

Is anyone else seeing these panics?

Regards,
Jan

[PATCH] powerpc/mm: Fix RECLAIM_DISTANCE

[Gavin Shan]

When @node_reclaim_mode ("/proc/sys/vm/zone_reclaim_mode") is enabled,
the nodes in the specified distance (< RECLAIM_DISTANCE) to the preferred
one will be checked for page direct reclaim in the fast path, as below
function call chain indicates. Currently, RECLAIM_DISTANCE is set to 10,
equal to LOCAL_DISTANCE. It means no nodes, including the preferred one,
don't match the conditions. So no nodes are checked for direct reclaim
in the fast path.

   __alloc_pages_nodemask
   get_page_from_freelist
   zone_allows_reclaim

This fixes it by setting RECLAIM_DISTANCE to 30. With it, the preferred
node and its directly adjacent nodes will be checked for page direct
reclaim. The comments explaining RECLAIM_DISTANCE is out of date. This
updates and makes it correct.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/include/asm/topology.h | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/topology.h 
b/arch/powerpc/include/asm/topology.h
index 8b3b46b..ce1a156 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -9,10 +9,11 @@ struct device_node;
 #ifdef CONFIG_NUMA
 
 /*
- * If zone_reclaim_mode is enabled, a RECLAIM_DISTANCE of 10 will mean that
- * all zones on all nodes will be eligible for zone_reclaim().
+ * If node_reclaim_mode is enabled, a RECLAIM_DISTANCE of 30 means that
+ * the preferred node and its directly adjacent nodes are eligible for
+ * node_reclaim().
  */
-#define RECLAIM_DISTANCE 10
+#define RECLAIM_DISTANCE   30
 
 #include 
 
-- 
2.7.4

[PATCH v2 0/3] powerpc/kernel: Simplify rtas_initialize()

[Gavin Shan]

This simplifies rtas_initialize(), no functional changes introduced:

   * PATCH[1/3] removes the unnecessary nested if statements.
   * PATCH[2/3] uses of_property_read_u32() instead of converting the
 property's data to target in CPU endian.
   * PATCH[3/3] decreases RTAS device-tree node's refcount in error path.

v2:
   * Set RTAS device-tree node to NULL if its base, or size, or both of
 them can't be found.

Gavin Shan (3):
  powerpc/kernel: Remove nested if statements in rtas_initialize()
  powerpc/kernel: Use of_property_read_u32() in rtas_initialize()
  powerpc/kernel: Fix unbalanced refcount on RTAS device node

 arch/powerpc/kernel/rtas.c | 32 +++-
 1 file changed, 15 insertions(+), 17 deletions(-)

-- 
2.7.4

[PATCH v2 1/3] powerpc/kernel: Remove nested if statements in rtas_initialize()

[Gavin Shan]

This removes the unnecessary nested if statements in function
rtas_initialize(), to simplify the code. No functional changes
introduced.

Signed-off-by: Gavin Shan 
---
v2: Set device node to NULL when base or size isn't found
---
 arch/powerpc/kernel/rtas.c | 33 -
 1 file changed, 16 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 112cc3b..9759dcb 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -1145,31 +1145,30 @@ asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
 void __init rtas_initialize(void)
 {
unsigned long rtas_region = RTAS_INSTANTIATE_MAX;
+   const __be32 *basep, *entryp, *sizep;
 
/* Get RTAS dev node and fill up our "rtas" structure with infos
 * about it.
 */
rtas.dev = of_find_node_by_name(NULL, "rtas");
-   if (rtas.dev) {
-   const __be32 *basep, *entryp, *sizep;
-
-   basep = of_get_property(rtas.dev, "linux,rtas-base", NULL);
-   sizep = of_get_property(rtas.dev, "rtas-size", NULL);
-   if (basep != NULL && sizep != NULL) {
-   rtas.base = __be32_to_cpu(*basep);
-   rtas.size = __be32_to_cpu(*sizep);
-   entryp = of_get_property(rtas.dev,
-   "linux,rtas-entry", NULL);
-   if (entryp == NULL) /* Ugh */
-   rtas.entry = rtas.base;
-   else
-   rtas.entry = __be32_to_cpu(*entryp);
-   } else
-   rtas.dev = NULL;
-   }
if (!rtas.dev)
return;
 
+   basep = of_get_property(rtas.dev, "linux,rtas-base", NULL);
+   sizep = of_get_property(rtas.dev, "rtas-size", NULL);
+   if (basep == NULL || sizep == NULL) {
+   rtas.dev = NULL;
+   return;
+   }
+
+   rtas.base = __be32_to_cpu(*basep);
+   rtas.size = __be32_to_cpu(*sizep);
+   entryp = of_get_property(rtas.dev, "linux,rtas-entry", NULL);
+   if (entryp == NULL) /* Ugh */
+   rtas.entry = rtas.base;
+   else
+   rtas.entry = __be32_to_cpu(*entryp);
+
/* If RTAS was found, allocate the RMO buffer for it and look for
 * the stop-self token if any
 */
-- 
2.7.4

[PATCH v2 3/3] powerpc/kernel: Fix unbalanced refcount on RTAS device node

[Gavin Shan]

The RTAS device-tree node's refcount has been increased by one in
the function call of_find_node_by_name(), but it's missed to be
decreased by one in the error path. It leads to unbalanced refcount
on RTAS device-tree node.

This fixes above issue by decreasing RTAS device-tree node's refcount
in error path.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/kernel/rtas.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index ba5a4cc..b8a4987 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -1158,6 +1158,7 @@ void __init rtas_initialize(void)
no_base = of_property_read_u32(rtas.dev, "linux,rtas-base", );
no_size = of_property_read_u32(rtas.dev, "rtas-size", );
if (no_base || no_size) {
+   of_node_put(rtas.dev);
rtas.dev = NULL;
return;
}
-- 
2.7.4

[PATCH v2 2/3] powerpc/kernel: Use of_property_read_u32() in rtas_initialize()

[Gavin Shan]

This uses of_property_read_u32() in rtas_initialize() so that we
needn't explicitly care the CPU's endian.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/kernel/rtas.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 9759dcb..ba5a4cc 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -1145,7 +1145,8 @@ asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
 void __init rtas_initialize(void)
 {
unsigned long rtas_region = RTAS_INSTANTIATE_MAX;
-   const __be32 *basep, *entryp, *sizep;
+   u32 base, size, entry;
+   int no_base, no_size, no_entry;
 
/* Get RTAS dev node and fill up our "rtas" structure with infos
 * about it.
@@ -1154,20 +1155,17 @@ void __init rtas_initialize(void)
if (!rtas.dev)
return;
 
-   basep = of_get_property(rtas.dev, "linux,rtas-base", NULL);
-   sizep = of_get_property(rtas.dev, "rtas-size", NULL);
-   if (basep == NULL || sizep == NULL) {
+   no_base = of_property_read_u32(rtas.dev, "linux,rtas-base", );
+   no_size = of_property_read_u32(rtas.dev, "rtas-size", );
+   if (no_base || no_size) {
rtas.dev = NULL;
return;
}
 
-   rtas.base = __be32_to_cpu(*basep);
-   rtas.size = __be32_to_cpu(*sizep);
-   entryp = of_get_property(rtas.dev, "linux,rtas-entry", NULL);
-   if (entryp == NULL) /* Ugh */
-   rtas.entry = rtas.base;
-   else
-   rtas.entry = __be32_to_cpu(*entryp);
+   rtas.base = base;
+   rtas.size = size;
+   no_entry = of_property_read_u32(rtas.dev, "linux,rtas-entry", );
+   rtas.entry = no_entry ? rtas.base : entry;
 
/* If RTAS was found, allocate the RMO buffer for it and look for
 * the stop-self token if any
-- 
2.7.4

Re: [PATCH 1/3] powerpc/kernel: Remove nested if statements in rtas_initialize()

[Gavin Shan]

On Mon, Jan 23, 2017 at 08:08:20PM +1100, Michael Ellerman wrote:
>Gavin Shan  writes:
>
>> This removes the unnecessary nested if statements in function
>> rtas_initialize(), to simplify the code. No functional changes
>> introduced.
>>
>> Signed-off-by: Gavin Shan 
>> ---
>>  arch/powerpc/kernel/rtas.c | 33 -
>>  1 file changed, 16 insertions(+), 17 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
>> index 112cc3b..9ba0f67 100644
>> --- a/arch/powerpc/kernel/rtas.c
>> +++ b/arch/powerpc/kernel/rtas.c
>> @@ -1145,31 +1145,30 @@ asmlinkage int ppc_rtas(struct rtas_args __user 
>> *uargs)
>>  void __init rtas_initialize(void)
>>  {
>>  unsigned long rtas_region = RTAS_INSTANTIATE_MAX;
>> +const __be32 *basep, *entryp, *sizep;
>>  
>>  /* Get RTAS dev node and fill up our "rtas" structure with infos
>>   * about it.
>>   */
>>  rtas.dev = of_find_node_by_name(NULL, "rtas");
>> -if (rtas.dev) {
>> -const __be32 *basep, *entryp, *sizep;
>> -
>> -basep = of_get_property(rtas.dev, "linux,rtas-base", NULL);
>> -sizep = of_get_property(rtas.dev, "rtas-size", NULL);
>> -if (basep != NULL && sizep != NULL) {
>   ...
>> -} else
>
>Previously we set rtas.dev to NULL if either basep or sizep was NULL.
>
>> -rtas.dev = NULL;
>> -}
>>  if (!rtas.dev)
>>  return;
>>  
>> +basep = of_get_property(rtas.dev, "linux,rtas-base", NULL);
>> +sizep = of_get_property(rtas.dev, "rtas-size", NULL);
>> +if (basep == NULL && sizep == NULL) {
>
>But now you set it to NULL only if BOTH basep and sizep are NULL.
>
>Was that intentional? If so you need to mention it in the change log.
>
>> +rtas.dev = NULL;
>> +return;
>> +}
>
>The proper negation of:
>
>   if (basep != NULL && sizep != NULL) {
>is:
>   if (basep == NULL || sizep == NULL) {
>

Thanks, Michael. It's not intentional. I'll update in v2.

Thanks,
Gavin

[PATCH] powerpc: Add missing error check to prom_find_boot_cpu()

[Darren Stevens]

prom_init.c calls 'instance-to-package' twice, but the return
is not checked during prom_find_boot_cpu(). The result is then
passed to prom_getprop, which could be PROM_ERROR.
Add a return check to prevent this.

This was found on a pasemi system, where CFE doesn't have a working
'instance-to package' prom call.
Before Commit 5c0484e25ec0 ('powerpc: Endian safe trampoline') the
area around addr 0 as mostly 0's and this doesn't cause a problem.
Once the macro 'FIXUP_ENDIAN' has been added to head_64.S, the low
memory area now has non-zero values, which cause the prom_getprop
call to hang.

Signed-off-by: Darren Stevens 

---
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index ec47a93..ac83eb0 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -2834,6 +2834,9 @@ static void __init prom_find_boot_cpu(void)
 
cpu_pkg = call_prom("instance-to-package", 1, 1, prom_cpu);
 
+   if (!PHANDLE_VALID(cpu_pkg))
+   return;
+
prom_getprop(cpu_pkg, "reg", , sizeof(rval));
prom.cpu = be32_to_cpu(rval);
 

Re: [PATCH 3/3] powerpc: bpf: implement in-register swap for 64-bit endian operations

['Naveen N. Rao']

On 2017/01/15 09:00AM, Benjamin Herrenschmidt wrote:
> On Fri, 2017-01-13 at 23:22 +0530, 'Naveen N. Rao' wrote:
> > > That rather depends on whether the processor has a store to load forwarder
> > > that will satisfy the read from the store buffer.
> > > I don't know about ppc, but at least some x86 will do that.
> > 
> > Interesting - good to know that.
> > 
> > However, I don't think powerpc does that and in-register swap is likely 
> > faster regardless. Note also that gcc prefers this form at higher 
> > optimization levels.
> 
> Of course powerpc has a load-store forwarder these days, however, I
> wouldn't be surprised if the in-register form was still faster on some
> implementations, but this needs to be tested.

Thanks for clarifying! To test this, I wrote a simple (perhaps naive) 
test that just issues a whole lot of endian swaps and in _that_ test, it 
does look like the load-store forwarder is doing pretty well.

The tests:

bpf-bswap.S:
---
.file   "bpf-bswap.S"
.abiversion 2
.section".text"
.align 2
.globl main
.type   main, @function
main:
mflr0
std 0,16(1)
stdu1,-32760(1)
addi3,1,32
li  4,0
li  5,32720
li  11,32720
mulli   11,11,8
li  10,0
li  7,16
1:  ldx 6,3,4
stdx6,1,7
ldbrx   6,1,7
stdx6,3,4
addi4,4,8
cmpd4,5
beq 2f
b   1b
2:  addi10,10,1
li  4,0
cmpd10,11
beq 3f
b   1b
3:  li  3,0
addi1,1,32760
ld  0,16(1)
mtlr0
blr

bpf-bswap-reg.S:
---
.file   "bpf-bswap-reg.S"
.abiversion 2
.section".text"
.align 2
.globl main
.type   main, @function
main:
mflr0
std 0,16(1)
stdu1,-32760(1)
addi3,1,32
li  4,0
li  5,32720
li  11,32720
mulli   11,11,8
li  10,0
1:  ldx 6,3,4
rldicl  7,6,32,32
rlwinm  8,6,24,0,31
rlwimi  8,6,8,8,15
rlwinm  9,7,24,0,31
rlwimi  8,6,8,24,31
rlwimi  9,7,8,8,15
rlwimi  9,7,8,24,31
rldicr  8,8,32,31
or  6,8,9
stdx6,3,4
addi4,4,8
cmpd4,5
beq 2f
b   1b
2:  addi10,10,1
li  4,0
cmpd10,11
beq 3f
b   1b
3:  li  3,0
addi1,1,32760
ld  0,16(1)
mtlr0
blr

Profiling the two variants:

# perf stat ./bpf-bswap

 Performance counter stats for './bpf-bswap':

   1395.979224  task-clock (msec) #0.999 CPUs utilized  

 0  context-switches  #0.000 K/sec  

 0  cpu-migrations#0.000 K/sec  

45  page-faults   #0.032 K/sec  

 4,651,874,673  cycles#3.332 GHz
  (66.87%)
 3,141,186  stalled-cycles-frontend   #0.07% frontend cycles 
idle (50.57%)
 1,117,289,485  stalled-cycles-backend#   24.02% backend cycles 
idle  (50.57%)
 8,565,963,861  instructions  #1.84  insn per cycle 

  #0.13  stalled cycles per 
insn  (67.05%)
 2,174,029,771  branches  # 1557.351 M/sec  
  (49.69%)
   262,656  branch-misses #0.01% of all branches
  (50.05%)

   1.396893189 seconds time elapsed

# perf stat ./bpf-bswap-reg

 Performance counter stats for './bpf-bswap-reg':

   1819.758102  task-clock (msec) #0.999 CPUs utilized  

 3  context-switches  #0.002 K/sec  

 0  cpu-migrations#0.000 K/sec  

44  page-faults   #0.024 K/sec  

 6,034,777,602  cycles#3.316 GHz
  (66.83%)
 2,010,983  stalled-cycles-frontend   #0.03% frontend cycles 
idle (50.47%)
 1,024,975,759  stalled-cycles-backend#   16.98% backend cycles 
idle  (50.52%)
16,043,732,849  instructions  #2.66  insn per cycle 

  #0.06  stalled cycles per 
insn  (67.01%)
 2,148,710,750  branches  # 1180.767 M/sec  
  (49.57%)
   268,046  branch-misses #0.01% of all branches
  (49.52%)

   1.821501345 seconds time elapsed


This is all 

Re: [PATCH 05/11] KVM: PPC: Book3S HV: Adjust nine checks for null pointers

[Thomas Huth]

On 20.01.2017 19:23, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Fri, 20 Jan 2017 11:25:48 +0100
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> The script "checkpatch.pl" pointed information out like the following.
> 
> Comparison to NULL could be written …

That's maybe ok for new code / if the code has to be touched anyway ...
but for existing code, this sounds very much like unnecessary code-churn
to me (e.g. it hides more important information with "git blame").

 Thomas


> 
> Signed-off-by: Markus Elfring 
> ---
>  arch/powerpc/kvm/book3s_hv.c | 19 +--
>  1 file changed, 9 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index cfc7699d05df..3122998f6a32 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -458,7 +458,7 @@ static unsigned long do_h_register_vpa(struct kvm_vcpu 
> *vcpu,
>  
>   /* convert logical addr to kernel addr and read length */
>   va = kvmppc_pin_guest_page(kvm, vpa, );
> - if (va == NULL)
> + if (!va)
>   return H_PARAMETER;
>   if (subfunc == H_VPA_REG_VPA)
>   len = be16_to_cpu(((struct reg_vpa *)va)->length.hword);
> @@ -1591,8 +1591,7 @@ static struct kvmppc_vcore *kvmppc_vcore_create(struct 
> kvm *kvm, int core)
>   struct kvmppc_vcore *vcore;
>  
>   vcore = kzalloc(sizeof(struct kvmppc_vcore), GFP_KERNEL);
> -
> - if (vcore == NULL)
> + if (!vcore)
>   return NULL;
>  
>   spin_lock_init(>lock);
> @@ -2221,7 +2220,7 @@ static void collect_piggybacks(struct core_info *cip, 
> int target_threads)
>   prepare_threads(pvc);
>   if (!pvc->n_runnable) {
>   list_del_init(>preempt_list);
> - if (pvc->runner == NULL) {
> + if (!pvc->runner) {
>   pvc->vcore_state = VCORE_INACTIVE;
>   kvmppc_core_end_stolen(pvc);
>   }
> @@ -2287,7 +2286,7 @@ static void post_guest_process(struct kvmppc_vcore *vc, 
> bool is_master)
>   } else {
>   vc->vcore_state = VCORE_INACTIVE;
>   }
> - if (vc->n_runnable > 0 && vc->runner == NULL) {
> + if (vc->n_runnable > 0 && !vc->runner) {
>   /* make sure there's a candidate runner awake */
>   i = -1;
>   vcpu = next_runnable_thread(vc, );
> @@ -2786,7 +2785,7 @@ static int kvmppc_run_vcpu(struct kvm_run *kvm_run, 
> struct kvm_vcpu *vcpu)
>  
>   while (vcpu->arch.state == KVMPPC_VCPU_RUNNABLE &&
>  !signal_pending(current)) {
> - if (vc->vcore_state == VCORE_PREEMPT && vc->runner == NULL)
> + if (vc->vcore_state == VCORE_PREEMPT && !vc->runner)
>   kvmppc_vcore_end_preempt(vc);
>  
>   if (vc->vcore_state != VCORE_INACTIVE) {
> @@ -2833,7 +2832,7 @@ static int kvmppc_run_vcpu(struct kvm_run *kvm_run, 
> struct kvm_vcpu *vcpu)
>   vc->vcore_state == VCORE_PIGGYBACK))
>   kvmppc_wait_for_exec(vc, vcpu, TASK_UNINTERRUPTIBLE);
>  
> - if (vc->vcore_state == VCORE_PREEMPT && vc->runner == NULL)
> + if (vc->vcore_state == VCORE_PREEMPT && !vc->runner)
>   kvmppc_vcore_end_preempt(vc);
>  
>   if (vcpu->arch.state == KVMPPC_VCPU_RUNNABLE) {
> @@ -3203,7 +3202,7 @@ void kvmppc_alloc_host_rm_ops(void)
>   int size;
>  
>   /* Not the first time here ? */
> - if (kvmppc_host_rm_ops_hv != NULL)
> + if (kvmppc_host_rm_ops_hv)
>   return;
>  
>   ops = kzalloc(sizeof(struct kvmppc_host_rm_ops), GFP_KERNEL);
> @@ -3430,10 +3429,10 @@ static int kvmppc_set_passthru_irq(struct kvm *kvm, 
> int host_irq, int guest_gsi)
>   mutex_lock(>lock);
>  
>   pimap = kvm->arch.pimap;
> - if (pimap == NULL) {
> + if (!pimap) {
>   /* First call, allocate structure to hold IRQ map */
>   pimap = kvmppc_alloc_pimap();
> - if (pimap == NULL) {
> + if (!pimap) {
>   mutex_unlock(>lock);
>   return -ENOMEM;
>   }
> 

Re: powerpc/pasemi/nemo: Fix low memory values for boot.

[Darren Stevens]

Hello Michael

On 23/01/2017, Michael Ellerman wrote:
>> Clearing the long long at addr 8 has been shown to fix this, so
>> add an initalisation to head_64.S so the system will boot.
>
> I'd really prefer it if someone could tell me why we need to clear it.
> But I assume no one knows?

The problem was found by Christian, and the fix comes courtesy of Olof
Johansson, I've not looked into it before.

> I don't want to pollute this code with NEMO workarounds if we can avoid
> it.

To be honest, so would I.

> You said the hang happens after printing the initial memory map, I'm not
> quite sure where you mean, but it sounds like that will be late enough
> that we can do the clear in pasemi platform code?

During prom_init. Where it says 'Memory layout at Init'

I took a long look today and traced the problem the 'prom_find_boot_cpu' and a
much better patch will follow.

Regards
Darren

[PATCH] usb: gadget: udc: constify usb_ep_ops structures

[Bhumika Goyal]

Declare usb_ep_ops structures as const as they are only stored in the
ops field of an usb_ep structure. This field is of type const, so
usb_ep_ops structures having this property can be made const too.
Done using Coccinelle( A smaller version of the script)

@r disable optional_qualifier@
identifier i;
position p;
@@
static struct usb_ep_ops i@p={...};

@ok@
identifier r.i;
position p;
struct mv_ep a;
struct mv_u3d_ep b;
struct omap_ep c;

@@
(
a.ep.ops=@p;
|
b.ep.ops=@p;
|
c.ep.ops=@p;

)

@bad@
position p!={r.p,ok.p};
identifier r.i;
@@
i@p

@depends on !bad disable optional_qualifier@
identifier r.i;
@@
+const
struct usb_ep_ops i;

File size details before and after applying  the patch.
First line of every .o file shows the file size before patching and
second line shows the file size after patching.

  text data bss dec hex filename

   7782 384   881741fee usb/gadget/udc/fotg210-udc.o
   7878 296   881821ff6 usb/gadget/udc/fotg210-udc.o

  17866 992  40   1889849d2 usb/gadget/udc/fsl_udc_core.o
  17954 896  40   1889049ca usb/gadget/udc/fsl_udc_core.o

   9646 288   8994226d6 usb/gadget/udc/fusb300_udc.o
   9742 192   8994226d6 usb/gadget/udc/fusb300_udc.o

  12752 416   8   131763378 drivers/usb/gadget/udc/goku_udc.o
  12832 328   8   131683370 drivers/usb/gadget/udc/goku_udc.o

  165411696   8   182454745 drivers/usb/gadget/udc/gr_udc.o
  166371600   8   182454745 drivers/usb/gadget/udc/gr_udc.o

  15798 288  16   161023ee6 drivers/usb/gadget/udc/m66592-udc.o
  15894 192  16   161023ee6 drivers/usb/gadget/udc/m66592-udc.o

  177513808  16   215755447 usb/gadget/udc/mv_u3d_core.o
  178393712  16   21567543f usb/gadget/udc/mv_u3d_core.o

  173481112  24   184844834 usb/gadget/udc/mv_udc_core.o
  174361016  24   18476482c usb/gadget/udc/mv_udc_core.o

  259902620  13   286236fcf drivers/usb/gadget/udc/net2272.o
  260862524  13   286236fcf drivers/usb/gadget/udc/net2272.o

  184097312   8   257296481 drivers/usb/gadget/udc/pxa27x_udc.o
  185057208   8   257216479 drivers/usb/gadget/udc/pxa27x_udc.o

  18644 288  16   189484a04 usb/gadget/udc/r8a66597-udc.o
  18740 192  16   189484a04 usb/gadget/udc/r8a66597-udc.o

Files: drivers/usb/gadget/udc/{s3c-hsudc.o/omap_udc.o/fsl_qe_udc.o} did
not complie.

Signed-off-by: Bhumika Goyal 
---
 drivers/usb/gadget/udc/fotg210-udc.c  | 2 +-
 drivers/usb/gadget/udc/fsl_qe_udc.c   | 2 +-
 drivers/usb/gadget/udc/fsl_udc_core.c | 2 +-
 drivers/usb/gadget/udc/fusb300_udc.c  | 2 +-
 drivers/usb/gadget/udc/goku_udc.c | 2 +-
 drivers/usb/gadget/udc/gr_udc.c   | 2 +-
 drivers/usb/gadget/udc/m66592-udc.c   | 2 +-
 drivers/usb/gadget/udc/mv_u3d_core.c  | 2 +-
 drivers/usb/gadget/udc/mv_udc_core.c  | 2 +-
 drivers/usb/gadget/udc/net2272.c  | 4 ++--
 drivers/usb/gadget/udc/omap_udc.c | 2 +-
 drivers/usb/gadget/udc/pxa27x_udc.c   | 2 +-
 drivers/usb/gadget/udc/r8a66597-udc.c | 2 +-
 drivers/usb/gadget/udc/s3c-hsudc.c| 2 +-
 14 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/gadget/udc/fotg210-udc.c 
b/drivers/usb/gadget/udc/fotg210-udc.c
index 6ba122c..966637d 100644
--- a/drivers/usb/gadget/udc/fotg210-udc.c
+++ b/drivers/usb/gadget/udc/fotg210-udc.c
@@ -527,7 +527,7 @@ static void fotg210_ep_fifo_flush(struct usb_ep *_ep)
 {
 }
 
-static struct usb_ep_ops fotg210_ep_ops = {
+static const struct usb_ep_ops fotg210_ep_ops = {
.enable = fotg210_ep_enable,
.disable= fotg210_ep_disable,
 
diff --git a/drivers/usb/gadget/udc/fsl_qe_udc.c 
b/drivers/usb/gadget/udc/fsl_qe_udc.c
index 4fff51b..303328ce 100644
--- a/drivers/usb/gadget/udc/fsl_qe_udc.c
+++ b/drivers/usb/gadget/udc/fsl_qe_udc.c
@@ -1847,7 +1847,7 @@ static int qe_ep_set_halt(struct usb_ep *_ep, int value)
return status;
 }
 
-static struct usb_ep_ops qe_ep_ops = {
+static const struct usb_ep_ops qe_ep_ops = {
.enable = qe_ep_enable,
.disable = qe_ep_disable,
 
diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c 
b/drivers/usb/gadget/udc/fsl_udc_core.c
index 71094e4..f518727 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -1118,7 +1118,7 @@ static void fsl_ep_fifo_flush(struct usb_ep *_ep)
} while (fsl_readl(_regs->endptstatus) & bits);
 }
 
-static struct usb_ep_ops fsl_ep_ops = {
+static const struct usb_ep_ops fsl_ep_ops = {
.enable = fsl_ep_enable,
.disable = fsl_ep_disable,
 
diff --git a/drivers/usb/gadget/udc/fusb300_udc.c 
b/drivers/usb/gadget/udc/fusb300_udc.c
index 42ff308..e0c1b00 100644
--- a/drivers/usb/gadget/udc/fusb300_udc.c
+++ b/drivers/usb/gadget/udc/fusb300_udc.c
@@ -518,7 +518,7 @@ static void fusb300_fifo_flush(struct 

Re: [PATCH 1/3] powerpc: bpf: remove redundant check for non-null image

[Naveen N. Rao]

Hi David,

On 2017/01/16 01:38PM, David Miller wrote:
> 
> I'm assuming these patches will go via the powerpc tree.
> 
> If you want them to go into net-next, I kindly ask that you always
> explicitly say so, and furthermore always submit a patch series with
> a proper "[PATCH 0/N] ..." header posting.

Sure. Sorry for the confusion. I will be more explicit next time.

Thanks,
Naveen

Re: [PATCH 03/11] KVM: PPC: Book3S HV: Move error code assignments in two functions

[Paolo Bonzini]

On 20/01/2017 19:21, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Fri, 20 Jan 2017 10:30:26 +0100
> 
> A local variable was set to an error code in a few cases before a concrete
> error situation was detected. Thus move the corresponding assignments into
> if branches to indicate a software failure there.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  arch/powerpc/kvm/book3s_hv.c | 25 +++--
>  1 file changed, 15 insertions(+), 10 deletions(-)

NACK, current code uses consistent style.

Paolo

> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 8dcbe37a4dac..a93e1c4445da 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -2967,15 +2967,17 @@ static int kvm_vm_ioctl_get_dirty_log_hv(struct kvm 
> *kvm,
>  
>   mutex_lock(>slots_lock);
>  
> - r = -EINVAL;
> - if (log->slot >= KVM_USER_MEM_SLOTS)
> + if (log->slot >= KVM_USER_MEM_SLOTS) {
> + r = -EINVAL;
>   goto out;
> + }
>  
>   slots = kvm_memslots(kvm);
>   memslot = id_to_memslot(slots, log->slot);
> - r = -ENOENT;
> - if (!memslot->dirty_bitmap)
> + if (!memslot->dirty_bitmap) {
> + r = -ENOENT;
>   goto out;
> + }
>  
>   n = kvm_dirty_bitmap_bytes(memslot);
>   memset(memslot->dirty_bitmap, 0, n);
> @@ -2984,9 +2986,10 @@ static int kvm_vm_ioctl_get_dirty_log_hv(struct kvm 
> *kvm,
>   if (r)
>   goto out;
>  
> - r = -EFAULT;
> - if (copy_to_user(log->dirty_bitmap, memslot->dirty_bitmap, n))
> + if (copy_to_user(log->dirty_bitmap, memslot->dirty_bitmap, n)) {
> + r = -EFAULT;
>   goto out;
> + }
>  
>   r = 0;
>  out:
> @@ -3127,9 +3130,10 @@ static int kvmppc_hv_setup_htab_rma(struct kvm_vcpu 
> *vcpu)
>   memslot = gfn_to_memslot(kvm, 0);
>  
>   /* We must have some memory at 0 by now */
> - err = -EINVAL;
> - if (!memslot || (memslot->flags & KVM_MEMSLOT_INVALID))
> + if (!memslot || (memslot->flags & KVM_MEMSLOT_INVALID)) {
> + err = -EINVAL;
>   goto out_srcu;
> + }
>  
>   /* Look up the VMA for the start of this memory slot */
>   hva = memslot->userspace_addr;
> @@ -3144,10 +3148,11 @@ static int kvmppc_hv_setup_htab_rma(struct kvm_vcpu 
> *vcpu)
>   up_read(>mm->mmap_sem);
>  
>   /* We can handle 4k, 64k or 16M pages in the VRMA */
> - err = -EINVAL;
>   if (!(psize == 0x1000 || psize == 0x1 ||
> -   psize == 0x100))
> +   psize == 0x100)) {
> + err = -EINVAL;
>   goto out_srcu;
> + }
>  
>   senc = slb_pgsize_encoding(psize);
>   kvm->arch.vrma_slb_v = senc | SLB_VSID_B_1T |
> 

Re: [PATCH 01/11] KVM: PPC: Book3S HV: Move assignments for the variable "err" in kvm_htab_write()

[Paolo Bonzini]

On 20/01/2017 19:19, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Thu, 19 Jan 2017 22:45:56 +0100
> 
> * A local variable was set to an error code in five cases
>   before a concrete error situation was detected.
>   Thus move the corresponding assignments into
>   if branches to indicate a software failure there.
> 
>   This issue was detected by using the Coccinelle software.
> 
> * Delete two zero assignments which became unnecessary with
>   this refactoring.
> 
> Signed-off-by: Markus Elfring 

NACK, current code uses consistent style.

> ---
>  arch/powerpc/kvm/book3s_64_mmu_hv.c | 24 +---
>  1 file changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c 
> b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> index b795dd1ac2ef..dc34729e4ad0 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> @@ -1399,22 +1399,23 @@ static ssize_t kvm_htab_write(struct file *file, 
> const char __user *buf,
>  
>   err = 0;
>   for (nb = 0; nb + sizeof(hdr) <= count; ) {
> - err = -EFAULT;
> - if (__copy_from_user(, buf, sizeof(hdr)))
> + if (__copy_from_user(, buf, sizeof(hdr))) {
> + err = -EFAULT;
>   break;
> + }
>  
> - err = 0;
>   if (nb + hdr.n_valid * HPTE_SIZE > count)
>   break;
>  
>   nb += sizeof(hdr);
>   buf += sizeof(hdr);
>  
> - err = -EINVAL;
>   i = hdr.index;
>   if (i >= kvm->arch.hpt_npte ||
> - i + hdr.n_valid + hdr.n_invalid > kvm->arch.hpt_npte)
> + i + hdr.n_valid + hdr.n_invalid > kvm->arch.hpt_npte) {
> + err = -EINVAL;
>   break;
> + }
>  
>   hptp = (__be64 *)(kvm->arch.hpt_virt + (i * HPTE_SIZE));
>   lbuf = (unsigned long __user *)buf;
> @@ -1422,26 +1423,28 @@ static ssize_t kvm_htab_write(struct file *file, 
> const char __user *buf,
>   __be64 hpte_v;
>   __be64 hpte_r;
>  
> - err = -EFAULT;
>   if (__get_user(hpte_v, lbuf) ||
> - __get_user(hpte_r, lbuf + 1))
> + __get_user(hpte_r, lbuf + 1)) {
> + err = -EFAULT;
>   goto out;
> + }
>   v = be64_to_cpu(hpte_v);
>   r = be64_to_cpu(hpte_r);
> - err = -EINVAL;
> - if (!(v & HPTE_V_VALID))
> + if (!(v & HPTE_V_VALID)) {
> + err = -EINVAL;
>   goto out;
> + }
>   lbuf += 2;
>   nb += HPTE_SIZE;
>  
>   if (be64_to_cpu(hptp[0]) & (HPTE_V_VALID | 
> HPTE_V_ABSENT))
>   kvmppc_do_h_remove(kvm, 0, i, 0, tmp);
> - err = -EIO;
>   ret = kvmppc_virtmode_do_h_enter(kvm, H_EXACT, i, v, r,
>tmp);
>   if (ret != H_SUCCESS) {
>   pr_err("kvm_htab_write ret %ld i=%ld v=%lx "
>  "r=%lx\n", ret, i, v, r);
> + err = -EIO;
>   goto out;
>   }
>   if (!hpte_setup && is_vrma_hpte(v)) {
> @@ -1465,7 +1468,6 @@ static ssize_t kvm_htab_write(struct file *file, const 
> char __user *buf,
>   ++i;
>   hptp += 2;
>   }
> - err = 0;
>   }
>  
>   out:
> 

Re: [PATCH 1/3] powerpc/kernel: Remove nested if statements in rtas_initialize()

[Michael Ellerman]

Gavin Shan  writes:

> This removes the unnecessary nested if statements in function
> rtas_initialize(), to simplify the code. No functional changes
> introduced.
>
> Signed-off-by: Gavin Shan 
> ---
>  arch/powerpc/kernel/rtas.c | 33 -
>  1 file changed, 16 insertions(+), 17 deletions(-)
>
> diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
> index 112cc3b..9ba0f67 100644
> --- a/arch/powerpc/kernel/rtas.c
> +++ b/arch/powerpc/kernel/rtas.c
> @@ -1145,31 +1145,30 @@ asmlinkage int ppc_rtas(struct rtas_args __user 
> *uargs)
>  void __init rtas_initialize(void)
>  {
>   unsigned long rtas_region = RTAS_INSTANTIATE_MAX;
> + const __be32 *basep, *entryp, *sizep;
>  
>   /* Get RTAS dev node and fill up our "rtas" structure with infos
>* about it.
>*/
>   rtas.dev = of_find_node_by_name(NULL, "rtas");
> - if (rtas.dev) {
> - const __be32 *basep, *entryp, *sizep;
> -
> - basep = of_get_property(rtas.dev, "linux,rtas-base", NULL);
> - sizep = of_get_property(rtas.dev, "rtas-size", NULL);
> - if (basep != NULL && sizep != NULL) {
...
> - } else

Previously we set rtas.dev to NULL if either basep or sizep was NULL.

> - rtas.dev = NULL;
> - }
>   if (!rtas.dev)
>   return;
>  
> + basep = of_get_property(rtas.dev, "linux,rtas-base", NULL);
> + sizep = of_get_property(rtas.dev, "rtas-size", NULL);
> + if (basep == NULL && sizep == NULL) {

But now you set it to NULL only if BOTH basep and sizep are NULL.

Was that intentional? If so you need to mention it in the change log.

> + rtas.dev = NULL;
> + return;
> + }

The proper negation of:

if (basep != NULL && sizep != NULL) {
is:
if (basep == NULL || sizep == NULL) {


cheers

Re: [PATCH v3 7/8] uapi: export all headers under uapi directories

[Michael Ellerman]

Nicolas Dichtel  writes:

> Regularly, when a new header is created in include/uapi/, the developer
> forgets to add it in the corresponding Kbuild file. This error is usually
> detected after the release is out.
>
> In fact, all headers under uapi directories should be exported, thus it's
> useless to have an exhaustive list.
>
> After this patch, the following files, which were not exported, are now
> exported (with make headers_install_all):
...
> asm-powerpc/perf_regs.h
...
>  arch/powerpc/include/uapi/asm/Kbuild|  45 ---

Thanks for cleaning it up.

Acked-by: Michael Ellerman  (powerpc)


cheers

Re: [PATCH] powerpc: opal-msglog: Report size of memcons log

[Michael Ellerman]

Joel Stanley  writes:

> The OPAL memory console is reported to be size zero, as we do not
> initialise the struct attr with any size information due to the size
> being variable. This leads users to think that the console is empty.

Hmm OK. That is a general property of /proc and /sys files that are
dynamically generated, so users probably need to get used to it :)

> Instead report the maximum size.

But OK. That sounds sane enough. My only worry is that it might confuse
some tools, ie. the file claims to be x bytes but is actually smaller.
But I guess that can actually happen anyway with any file.

So I'll merge this and stop blabbing :)

cheers

Re: [PATCH tip/core/rcu 2/3] srcu: Force full grace-period ordering

[Michael Ellerman]

"Paul E. McKenney"  writes:

> On Sat, Jan 14, 2017 at 11:54:17AM -0800, Paul E. McKenney wrote:
>> On Sat, Jan 14, 2017 at 10:35:50AM +0100, Ingo Molnar wrote:
>> > * Paul E. McKenney  wrote:
>
> [ . . . ]
>
>> > > + */
>> > > +#ifdef CONFIG_PPC
>> > > +#define smp_mb__after_unlock_lock() smp_mb()  /* Full ordering for 
>> > > lock. */
>> > > +#else /* #ifdef CONFIG_PPC */
>> > > +#define smp_mb__after_unlock_lock() do { } while (0)
>> > > +#endif /* #else #ifdef CONFIG_PPC */
>> > 
>> > Yeah, so I realize that this was pre-existing code, but putting 
>> > CONFIG_$ARCH
>> > #ifdefs into generic headers is generally frowned upon.
>> > 
>> > The canonical approach would be either to define a helper Kconfig variable 
>> > that 
>> > can be set by PPC (but other architectures don't need to set it), or to 
>> > expose a 
>> > suitable macro (function) for architectures to define in their barrier.h 
>> > arch 
>> > header file.
>> 
>> Very well, I will add a separate commit for this.  4.11 OK?
>
> Does the patch below seem reasonable?
>
>   Thanx, Paul
>
> 
>
> commit 271c0601237c41a279f975563e13837bace0df03
> Author: Paul E. McKenney 
> Date:   Sat Jan 14 13:32:50 2017 -0800
>
> rcu: Make arch select smp_mb__after_unlock_lock() strength
> 
> The definition of smp_mb__after_unlock_lock() is currently smp_mb()
> for CONFIG_PPC and a no-op otherwise.  It would be better to instead
> provide an architecture-selectable Kconfig option, and select the
> strength of smp_mb__after_unlock_lock() based on that option.  This
> commit therefore creates CONFIG_ARCH_WEAK_RELACQ, has PPC select it,
> and bases the definition of smp_mb__after_unlock_lock() on this new
> CONFIG_ARCH_WEAK_RELACQ Kconfig option.
> 
> Reported-by: Ingo Molnar 
> Signed-off-by: Paul E. McKenney 
> Cc: Peter Zijlstra 
> Cc: Will Deacon 
> Cc: Boqun Feng 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: 

Personally I'd call it ARCH_WEAK_RELEASE_ACQUIRE, which is longer but
clearer I think. But it's not a big deal, so which ever you prefer.

Acked-by: Michael Ellerman 

cheers