Re: [PATCH 2/2] fadump: Disable deferred page struct initialisation

[Balbir Singh]

On Tue, 2016-08-02 at 18:49 +0530, Srikar Dronamraju wrote:
> Fadump kernel reserves significant number of memory blocks. On a multi-node
> machine, with CONFIG_DEFFERRED_STRUCT_PAGE support, fadump kernel fails to
> boot. Fix this by disabling deferred page struct initialisation.
> 

How much memory does a fadump kernel need? Can we bump up the limits depending
on the config. I presume when you say fadump kernel you mean kernel with
FADUMP in the config?

BTW, I would much rather prefer a config based solution that does not select
DEFERRED_INIT if FADUMP is enabled.

Balbir

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

[PATCH] lkdtm: Mark lkdtm_rodata_do_nothing() notrace

[Michael Ellerman]

lkdtm_rodata_do_nothing() is an empty function which is generated in
order to test the non-executability of rodata.

Currently if function tracing is enabled then an mcount callsite will be
generated for lkdtm_rodata_do_nothing(), and it will appear in the list
of available functions for function tracing (available_filter_functions).

Given it's purpose purely as a test function, it seems preferable for
lkdtm_rodata_do_nothing() to be marked notrace, so it doesn't appear as
traceable.

This also avoids triggering a linker bug on powerpc:

  https://sourceware.org/bugzilla/show_bug.cgi?id=20428

When the linker sees code that needs to generate a call stub, eg. a
branch to mcount(), it assumes the section is executable and
dereferences a NULL pointer leading to a linker segfault. Marking
lkdtm_rodata_do_nothing() notrace avoids triggering the bug because the
function contains no other function calls.

Signed-off-by: Michael Ellerman 
---
 drivers/misc/lkdtm_rodata.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/lkdtm_rodata.c b/drivers/misc/lkdtm_rodata.c
index 166b1db3969f..3564477b8c2d 100644
--- a/drivers/misc/lkdtm_rodata.c
+++ b/drivers/misc/lkdtm_rodata.c
@@ -4,7 +4,7 @@
  */
 #include "lkdtm.h"
 
-void lkdtm_rodata_do_nothing(void)
+void notrace lkdtm_rodata_do_nothing(void)
 {
/* Does nothing. We just want an architecture agnostic "return". */
 }
-- 
2.7.4

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

Re: [kernel-hardening] Re: Linker segfault on powerpc when CONFIG_LKDTM=y (was Re: [kernel-hardening] [PATCH 3/5] lkdtm: add function for testing .rodata section)

[Michael Ellerman]

Kees Cook  writes:
> On Mon, Aug 1, 2016 at 8:12 PM, Michael Ellerman  wrote:
>> Kees Cook  writes:
>>> On Mon, Aug 1, 2016 at 5:37 AM, Michael Ellerman  
>>> wrote:

   scripts/link-vmlinux.sh: line 52: 36260 Segmentation fault  (core 
 dumped) ${LD} ${LDFLAGS} ${LDFLAGS_vmlinux} -o ${2} -T ${lds} 
 ${KBUILD_VMLINUX_INIT} --start-group ${KBUILD_VMLINUX_MAIN} --end-group 
 ${1}

 Haven't had a chance to debug it further.
...
>> Interestingly I *can't* reproduce with the Ubuntu x86->ppc cross
>> (5.4.0-6ubuntu1~16.04.1).
>
> Oh, weird. Well, that does explains my lack of hitting the problem,
> though: that's the cross compiler I was using. :P

Actually that was a false negative.

The trick is you have to have LKDTM=y *and* FUNCTION_TRACER=y.

It is a linker bug:

  https://sourceware.org/bugzilla/show_bug.cgi?id=20428

Which Alan has already fixed.

But we need to workaround existing linkers that are out there.

We can do that by marking lkdtm_rodata_do_nothing() notrace, which I
think makes sense for all arches actually.

So I'll send you a patch to do that.

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

RE: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to include/linux/fsl

[Yangbo Lu]

Hi Uffe,


> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Wednesday, August 03, 2016 5:41 AM
> To: Yangbo Lu; Michael Ellerman; Arnd Bergmann; Ulf Hansson
> Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Xiaobo Xie
> Subject: Re: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to
> include/linux/fsl
> 
> On Tue, 2016-08-02 at 05:57 +, Yangbo Lu wrote:
> > Hi Scott,
> >
> > >
> > > -Original Message-
> > > From: Scott Wood [mailto:o...@buserror.net]
> > > Sent: Wednesday, July 27, 2016 8:38 AM
> > > To: Yangbo Lu; Michael Ellerman; Arnd Bergmann; Ulf Hansson
> > > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; linuxppc-
> > > d...@lists.ozlabs.org; linux-ker...@vger.kernel.org
> > > Subject: Re: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to
> > > include/linux/fsl
> > >
> > > On Mon, 2016-07-25 at 06:12 +, Yangbo Lu wrote:
> > > >
> > > > Hi Scott,
> > > >
> > > >
> > > > >
> > > > >
> > > > > -Original Message-
> > > > > From: Scott Wood [mailto:o...@buserror.net]
> > > > > Sent: Friday, July 22, 2016 12:45 AM
> > > > > To: Michael Ellerman; Arnd Bergmann
> > > > > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org;
> > > > > linuxppc- d...@lists.ozlabs.org; linux-ker...@vger.kernel.org;
> > > > > Yangbo Lu
> > > > > Subject: Re: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to
> > > > > include/linux/fsl
> > > > >
> > > > > On Thu, 2016-07-21 at 20:26 +1000, Michael Ellerman wrote:
> > > > > >
> > > > > >
> > > > > > Quoting Scott Wood (2016-07-21 04:31:48)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, 2016-07-20 at 13:24 +0200, Arnd Bergmann wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Saturday, July 16, 2016 9:50:21 PM CEST Scott Wood wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > From: yangbo lu 
> > > > > > > > >
> > > > > > > > > Move mpc85xx.h to include/linux/fsl and rename it to
> > > > > > > > > svr.h as a common header file.  This SVR numberspace is
> > > > > > > > > used on some ARM chips as well as PPC, and even to check
> > > > > > > > > for a PPC SVR multi-arch drivers would otherwise need to
> > > > > > > > > ifdef the header inclusion and all references to the SVR
> symbols.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Yangbo Lu 
> > > > > > > > > Acked-by: Wolfram Sang 
> > > > > > > > > Acked-by: Stephen Boyd 
> > > > > > > > > Acked-by: Joerg Roedel 
> > > > > > > > > [scottwood: update description]
> > > > > > > > > Signed-off-by: Scott Wood 
> > > > > > > > >
> > > > > > > > As discussed before, please don't introduce yet another
> > > > > > > > vendor specific way to match a SoC ID from a device driver.
> > > > > > > >
> > > > > > > > I've posted a patch for an extension to the soc_device
> > > > > > > > infrastructure to allow comparing the running SoC to a
> > > > > > > > table of devices, use that instead.
> > > > > > > As I asked before, in which relevant maintainership capacity
> > > > > > > are you NACKing this?
> > > > > > I'll nack the powerpc part until you guys can agree.
> > > > > OK, I've pulled these patches out.
> > > > >
> > > > > For the MMC issue I suggest using ifdef CONFIG_PPC and
> > > > > mfspr(SPRN_SVR) like the clock driver does[1] and we can revisit
> > > > > the issue if/when we need to do something similar on an ARM chip.
> > > > [Lu Yangbo-B47093] I remembered that Uffe had opposed us to
> > > > introduce
> > > > non- generic header files(like '#include ') in mmc
> > > > driver initially. So I think it will not be accepted to use ifdef
> > > > CONFIG_PPC and mfspr(SPRN_SVR)...
> > > > And this method still couldn’t get SVR of ARM chip now.
> > > Right, as I said we'll have to revisit the issue if/when we have the
> > > same problem on an ARM chip.  That also applies if the PPC ifdef is
> > > still getting NACKed from the MMC side.
> > [Lu Yangbo-B47093] It's not clear for me about your idea :( Do you
> > mean we can still use this method, or not ?
> > I think Uffe had opposed to use ifdef CONFIG_PPC and mfspr(SPRN_SVR).
> > Is there any solution to resolve ?
> > :)
> 
> As I said, I'm OK with using the SPR.  It's up to you to find out whether
> it's still unacceptable with the MMC maintainers given all the discussion
> (it would be the quickest way to get the workaround enabled), or just go
> with the method below.

[Lu Yangbo-B47093] As you know, this patchset(as below) has been discussed for 
more than one year.
What I want is just to add a fix for an specific soc revision.

Yangbo Lu (7):
  Documentation: DT: update Freescale DCFG compatible
  ARM64: dts: ls2080a: add device configuration node
  soc: fsl: add GUTS driver for QorIQ platforms
  dt: move guts devicetree doc out of powerpc 

Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

[Michael Ellerman]

"Luis R. Rodriguez"  writes:

> Are linux-next builds being tested for powerpc with allyesconfig and
> allmodconfig ?

Yes, every single version:

  http://kisskb.ellerman.id.au/kisskb/target/2659/

> I have some changes I'm making and while debugging my
> build issues I decided to give a clean build a shot and see linux-next
> next-20160729 up to next-20160729 all have build failures without my
> changes. I get:
>
> /opt/gcc-4.9.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld:
> drivers/built-in.o: .opd is not a regular array of opd entries
>   MODPOST vmlinux.o
>   GEN .version
>   CHK include/generated/compile.h
>   UPD include/generated/compile.h
>   CC  init/version.o
>   LD  init/built-in.o
> /opt/gcc-4.9.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld:
> drivers/built-in.o: .opd is not a regular array of opd entries
> drivers/built-in.o: In function `.ipw2100_up':
> ipw2100.c:(.text+0x1ff9c90): relocation truncated to fit:
> R_PPC64_REL24 (stub) against symbol `.round_jiffies_relative' defined
> in .text section in kernel/built-in.o

And yes this is a known problem, there have been attempts to fix it, but
none that quite got working.

In fact it's our bug #1 :)

  https://github.com/linuxppc/linux/issues/1


Please use allmodconfig, which should build in general. Or one of our
other defconfigs, eg. ppc64/ppc64le defconfig.

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

Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

[Stephen Rothwell]

Hi Luis,

On Wed, 3 Aug 2016 00:02:43 +0200 "Luis R. Rodriguez"  wrote:
>
> Thanks for the confirmation. For how long is it known this is broken?
> Does anyone care and fix these ? Or is this best effort?

This has been broken for many years :-(

I have a couple of times almost fixed it, but it requires that we
change from using "ld -r" to build the built-in.o objects and some
changes to the powerpc head.S code ... I will give it another shot now
that the merge window is almost over (and linux-next goes into its
quieter time).

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

Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

[Arnd Bergmann]

On Wednesday, August 3, 2016 12:02:43 AM CEST Luis R. Rodriguez wrote:
> On Tue, Aug 02, 2016 at 02:58:39PM -0700, Guenter Roeck wrote:
> > On Tue, Aug 02, 2016 at 01:07:09PM -0700, Luis R. Rodriguez wrote:
> > > Are linux-next builds being tested for powerpc with allyesconfig and
> > > allmodconfig ? I have some changes I'm making and while debugging my
> > > build issues I decided to give a clean build a shot and see linux-next
> > > next-20160729 up to next-20160729 all have build failures without my
> > > changes. I get:
> > > 
> > > /opt/gcc-4.9.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld:
> > > drivers/built-in.o: .opd is not a regular array of opd entries
> > >   MODPOST vmlinux.o
> > >   GEN .version
> > >   CHK include/generated/compile.h
> > >   UPD include/generated/compile.h
> > >   CC  init/version.o
> > >   LD  init/built-in.o
> > > /opt/gcc-4.9.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld:
> > > drivers/built-in.o: .opd is not a regular array of opd entries
> > > drivers/built-in.o: In function `.ipw2100_up':
> > > ipw2100.c:(.text+0x1ff9c90): relocation truncated to fit:
> > 
> > "relocation truncated to fit"  errors are typical for ppc:allyesconfig.
> 
> Thanks for the confirmation. For how long is it known this is broken?
> Does anyone care and fix these ? Or is this best effort?

We used to have the same thing on ARM, but it's (mostly) fixed now.
In case of ARM, the solution was to ensure that all sections that
have long jumps or targets of long jumps are marked as executable
in the ELF headers, so the linker can insert trampolines.

The one remaining problem at the moment is related to recursive
linking of the drivers/ directory, which has .text section that
is larger than 32MB by itself. There is a patch to solve this by
linking each drivers/*/built-in.o object directly into vmlinux,
but that is a rather drastic change.

Arnd

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

Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

[Luis R. Rodriguez]

On Tue, Aug 02, 2016 at 02:58:39PM -0700, Guenter Roeck wrote:
> On Tue, Aug 02, 2016 at 01:07:09PM -0700, Luis R. Rodriguez wrote:
> > Are linux-next builds being tested for powerpc with allyesconfig and
> > allmodconfig ? I have some changes I'm making and while debugging my
> > build issues I decided to give a clean build a shot and see linux-next
> > next-20160729 up to next-20160729 all have build failures without my
> > changes. I get:
> > 
> > /opt/gcc-4.9.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld:
> > drivers/built-in.o: .opd is not a regular array of opd entries
> >   MODPOST vmlinux.o
> >   GEN .version
> >   CHK include/generated/compile.h
> >   UPD include/generated/compile.h
> >   CC  init/version.o
> >   LD  init/built-in.o
> > /opt/gcc-4.9.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld:
> > drivers/built-in.o: .opd is not a regular array of opd entries
> > drivers/built-in.o: In function `.ipw2100_up':
> > ipw2100.c:(.text+0x1ff9c90): relocation truncated to fit:
> 
> "relocation truncated to fit"  errors are typical for ppc:allyesconfig.

Thanks for the confirmation. For how long is it known this is broken?
Does anyone care and fix these ? Or is this best effort?

> allmodconfig should work, though.

OK thanks.

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

Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

[Guenter Roeck]

On Tue, Aug 02, 2016 at 01:07:09PM -0700, Luis R. Rodriguez wrote:
> Are linux-next builds being tested for powerpc with allyesconfig and
> allmodconfig ? I have some changes I'm making and while debugging my
> build issues I decided to give a clean build a shot and see linux-next
> next-20160729 up to next-20160729 all have build failures without my
> changes. I get:
> 
> /opt/gcc-4.9.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld:
> drivers/built-in.o: .opd is not a regular array of opd entries
>   MODPOST vmlinux.o
>   GEN .version
>   CHK include/generated/compile.h
>   UPD include/generated/compile.h
>   CC  init/version.o
>   LD  init/built-in.o
> /opt/gcc-4.9.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld:
> drivers/built-in.o: .opd is not a regular array of opd entries
> drivers/built-in.o: In function `.ipw2100_up':
> ipw2100.c:(.text+0x1ff9c90): relocation truncated to fit:

"relocation truncated to fit"  errors are typical for ppc:allyesconfig.
allmodconfig should work, though.

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

linker tables on powerpc - build issues

[Luis R. Rodriguez]

I've run into a few compilation issues with linker tables support [0]
[1] on only a few architectures:

blackfin - compiler issue it seems, I have a work around now in place
arm  - some alignment issue - still need to iron this out
powerpc - issue with including  on 

The issue with powerpc can be replicated easily with the patch below,
and compilation fails even on a 'make defconfig' configuration, the
issues are recurring include header ordering issues. I've given this
some tries to fix but am still a bit bewildered how to best do this
without affecting non-powerpc compilations.  The patch below
replicates the changes in question, it does not include the linker
table work at all, it just includes  instead of
 to reduce and provide an example of the issues
observed. The list of errors are also pretty endless... so was hoping
some power folks might be able to take a glance if possible. If you
have any ideas, please let me know.

[0] https://lkml.kernel.org/r/1469222687-1600-1-git-send-email-mcg...@kernel.org
[1] 
https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160729-linker-table-v4-blackfin2

diff --git a/arch/powerpc/include/asm/jump_label.h
b/arch/powerpc/include/asm/jump_label.h
index 9a287e0ac8b1..68e46825b0f8 100644
--- a/arch/powerpc/include/asm/jump_label.h
+++ b/arch/powerpc/include/asm/jump_label.h
@@ -9,6 +9,7 @@
  * as published by the Free Software Foundation; either version
  * 2 of the License, or (at your option) any later version.
  */
+#include 

 #ifndef __ASSEMBLY__
 #include 
diff --git a/arch/powerpc/include/asm/sections.h
b/arch/powerpc/include/asm/sections.h
index 7dc006b58369..929decb62d9c 100644
--- a/arch/powerpc/include/asm/sections.h
+++ b/arch/powerpc/include/asm/sections.h
@@ -1,11 +1,14 @@
 #ifndef _ASM_POWERPC_SECTIONS_H
 #define _ASM_POWERPC_SECTIONS_H
-#ifdef __KERNEL__

+#if defined(__KERNEL__) && !defined(__ASSEMBLER__) && !defined(__ASSEMBLY__)
 #include 
 #include 
+#endif /* defined(__KERNEL__) && !defined(__ASSEMBLER__) &&
!defined(__ASSEMBLY__) */
+
 #include 

+#if defined(__KERNEL__) && !defined(__ASSEMBLER__) && !defined(__ASSEMBLY__)
 #ifdef __powerpc64__

 extern char __start_interrupts[];
@@ -77,5 +80,5 @@ static inline void *dereference_function_descriptor(void *ptr)

 #endif

-#endif /* __KERNEL__ */
+#endif /* defined(__KERNEL__) && !defined(__ASSEMBLER__) &&
!defined(__ASSEMBLY__) */
 #endif /* _ASM_POWERPC_SECTIONS_H */
diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
index af0254c09424..06bceee909da 100644
--- a/include/asm-generic/sections.h
+++ b/include/asm-generic/sections.h
@@ -1,6 +1,8 @@
 #ifndef _ASM_GENERIC_SECTIONS_H_
 #define _ASM_GENERIC_SECTIONS_H_

+#if defined(__KERNEL__) && !defined(__ASSEMBLER__) && !defined(__ASSEMBLY__)
+
 /* References to section boundaries */

 #include 
@@ -128,4 +130,6 @@ static inline bool init_section_intersects(void
*virt, size_t size)
  return memory_intersects(__init_begin, __init_end, virt, size);
 }

+#endif /* defined(__KERNEL__) && !defined(__ASSEMBLER__) &&
!defined(__ASSEMBLY__)  */
+
 #endif /* _ASM_GENERIC_SECTIONS_H_ */


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

Re: [v4] Fix to avoid IS_ERR_VALUE and IS_ERR abuses on 64bit systems.

[arvind Yadav]

On Tuesday 02 August 2016 01:15 PM, Arnd Bergmann wrote:

On Monday, August 1, 2016 4:55:43 PM CEST Scott Wood wrote:

On 08/01/2016 02:02 AM, Arnd Bergmann wrote:

diff --git a/include/linux/err.h b/include/linux/err.h
index 1e35588..c2a2789 100644
--- a/include/linux/err.h
+++ b/include/linux/err.h
@@ -18,7 +18,17 @@
  
  #ifndef __ASSEMBLY__
  
-#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)

+#define IS_ERR_VALUE(x) unlikely(is_error_check(x))
+
+static inline int is_error_check(unsigned long error)

Please leave the existing macro alone. I think you were looking for
something specific to the return code of qe_muram_alloc() function,
so please add a helper in that subsystem if you need it, not in
the generic header files.

qe_muram_alloc (a.k.a. cpm_muram_alloc) returns unsigned long.  The
problem is certain callers that store the return value in a u32.  Why
not just fix those callers to store it in unsigned long (at least until
error checking is done)?


Yes, that would also address another problem with code like

  kfree((void *)ugeth->tx_bd_ring_offset[i]);

which is not 64-bit safe when tx_bd_ring_offset is a 32-bit value
that also holds the return value of qe_muram_alloc.

Arnd

Yes, we will fix caller. Caller api is not safe on 64bit.
Even qe_muram_addr(a.k.a. cpm_muram_addr )passing value unsigned int,
but it should be unsigned long.


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

[PATCH 1264/1285] Replace numeric parameter like 0444 with macro

[Baole Ni]

I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the 
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 sound/ppc/snd_ps3.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/ppc/snd_ps3.c b/sound/ppc/snd_ps3.c
index 3682425..594d694 100644
--- a/sound/ppc/snd_ps3.c
+++ b/sound/ppc/snd_ps3.c
@@ -51,15 +51,15 @@ static struct snd_ps3_card_info the_card;
 
 static int snd_ps3_start_delay = CONFIG_SND_PS3_DEFAULT_START_DELAY;
 
-module_param_named(start_delay, snd_ps3_start_delay, uint, 0644);
+module_param_named(start_delay, snd_ps3_start_delay, uint, S_IRUSR | S_IWUSR | 
S_IRGRP | S_IROTH);
 MODULE_PARM_DESC(start_delay, "time to insert silent data in ms");
 
 static int index = SNDRV_DEFAULT_IDX1;
 static char *id = SNDRV_DEFAULT_STR1;
 
-module_param(index, int, 0444);
+module_param(index, int, S_IRUSR | S_IRGRP | S_IROTH);
 MODULE_PARM_DESC(index, "Index value for PS3 soundchip.");
-module_param(id, charp, 0444);
+module_param(id, charp, S_IRUSR | S_IRGRP | S_IROTH);
 MODULE_PARM_DESC(id, "ID string for PS3 soundchip.");
 
 
-- 
2.9.2

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

[PATCH 1263/1285] Replace numeric parameter like 0444 with macro

[Baole Ni]

I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the 
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 sound/ppc/powermac.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/ppc/powermac.c b/sound/ppc/powermac.c
index 33c6be9..d6498cd 100644
--- a/sound/ppc/powermac.c
+++ b/sound/ppc/powermac.c
@@ -38,11 +38,11 @@ static int index = SNDRV_DEFAULT_IDX1;  /* 
Index 0-MAX */
 static char *id = SNDRV_DEFAULT_STR1;  /* ID for this card */
 static bool enable_beep = 1;
 
-module_param(index, int, 0444);
+module_param(index, int, S_IRUSR | S_IRGRP | S_IROTH);
 MODULE_PARM_DESC(index, "Index value for " CHIP_NAME " soundchip.");
-module_param(id, charp, 0444);
+module_param(id, charp, S_IRUSR | S_IRGRP | S_IROTH);
 MODULE_PARM_DESC(id, "ID string for " CHIP_NAME " soundchip.");
-module_param(enable_beep, bool, 0444);
+module_param(enable_beep, bool, S_IRUSR | S_IRGRP | S_IROTH);
 MODULE_PARM_DESC(enable_beep, "Enable beep using PCM.");
 
 static struct platform_device *device;
-- 
2.9.2

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

[PATCH 1146/1285] Replace numeric parameter like 0444 with macro

[Baole Ni]

I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the 
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 sound/aoa/soundbus/i2sbus/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/aoa/soundbus/i2sbus/core.c b/sound/aoa/soundbus/i2sbus/core.c
index 1cbf210..2b741a4 100644
--- a/sound/aoa/soundbus/i2sbus/core.c
+++ b/sound/aoa/soundbus/i2sbus/core.c
@@ -27,7 +27,7 @@ MODULE_AUTHOR("Johannes Berg ");
 MODULE_DESCRIPTION("Apple Soundbus: I2S support");
 
 static int force;
-module_param(force, int, 0444);
+module_param(force, int, S_IRUSR | S_IRGRP | S_IROTH);
 MODULE_PARM_DESC(force, "Force loading i2sbus even when"
" no layout-id property is present");
 
-- 
2.9.2

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

[PATCH 1145/1285] Replace numeric parameter like 0444 with macro

[Baole Ni]

I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the 
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 sound/aoa/core/alsa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/aoa/core/alsa.c b/sound/aoa/core/alsa.c
index 4a7e4e6..6af6fb6 100644
--- a/sound/aoa/core/alsa.c
+++ b/sound/aoa/core/alsa.c
@@ -9,7 +9,7 @@
 #include "alsa.h"
 
 static int index = -1;
-module_param(index, int, 0444);
+module_param(index, int, S_IRUSR | S_IRGRP | S_IROTH);
 MODULE_PARM_DESC(index, "index for AOA sound card.");
 
 static struct aoa_card *aoa_card;
-- 
2.9.2

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

[PATCH 0965/1285] Replace numeric parameter like 0444 with macro

[Baole Ni]

I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the 
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 drivers/tty/hvc/hvc_iucv.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/hvc/hvc_iucv.c b/drivers/tty/hvc/hvc_iucv.c
index 8b70a16..9234097 100644
--- a/drivers/tty/hvc/hvc_iucv.c
+++ b/drivers/tty/hvc/hvc_iucv.c
@@ -1065,9 +1065,9 @@ static struct device_driver hvc_iucv_driver = {
 };
 
 /* IUCV HVC device attributes */
-static DEVICE_ATTR(termid, 0640, hvc_iucv_dev_termid_show, NULL);
-static DEVICE_ATTR(state, 0640, hvc_iucv_dev_state_show, NULL);
-static DEVICE_ATTR(peer, 0640, hvc_iucv_dev_peer_show, NULL);
+static DEVICE_ATTR(termid, S_IRUSR | S_IWUSR | S_IRGRP, 
hvc_iucv_dev_termid_show, NULL);
+static DEVICE_ATTR(state, S_IRUSR | S_IWUSR | S_IRGRP, 
hvc_iucv_dev_state_show, NULL);
+static DEVICE_ATTR(peer, S_IRUSR | S_IWUSR | S_IRGRP, hvc_iucv_dev_peer_show, 
NULL);
 static struct attribute *hvc_iucv_dev_attrs[] = {
_attr_termid.attr,
_attr_state.attr,
@@ -1475,4 +1475,4 @@ staticint __init hvc_iucv_config(char *val)
 
 device_initcall(hvc_iucv_init);
 __setup("hvc_iucv=", hvc_iucv_config);
-core_param(hvc_iucv_allow, hvc_iucv_filter, vmidfilter, 0640);
+core_param(hvc_iucv_allow, hvc_iucv_filter, vmidfilter, S_IRUSR | S_IWUSR | 
S_IRGRP);
-- 
2.9.2

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

[PATCH 0718/1285] Replace numeric parameter like 0444 with macro

[Baole Ni]

I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the 
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 drivers/net/ethernet/ibm/ibmveth.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/ibm/ibmveth.c 
b/drivers/net/ethernet/ibm/ibmveth.c
index ebe6071..7b0fd24 100644
--- a/drivers/net/ethernet/ibm/ibmveth.c
+++ b/drivers/net/ethernet/ibm/ibmveth.c
@@ -66,17 +66,17 @@ MODULE_LICENSE("GPL");
 MODULE_VERSION(ibmveth_driver_version);
 
 static unsigned int tx_copybreak __read_mostly = 128;
-module_param(tx_copybreak, uint, 0644);
+module_param(tx_copybreak, uint, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
 MODULE_PARM_DESC(tx_copybreak,
"Maximum size of packet that is copied to a new buffer on transmit");
 
 static unsigned int rx_copybreak __read_mostly = 128;
-module_param(rx_copybreak, uint, 0644);
+module_param(rx_copybreak, uint, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
 MODULE_PARM_DESC(rx_copybreak,
"Maximum size of packet that is copied to a new buffer on receive");
 
 static unsigned int rx_flush __read_mostly = 0;
-module_param(rx_flush, uint, 0644);
+module_param(rx_flush, uint, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
 MODULE_PARM_DESC(rx_flush, "Flush receive buffers before use");
 
 static bool old_large_send __read_mostly;
@@ -1730,9 +1730,9 @@ static ssize_t veth_pool_store(struct kobject *kobj, 
struct attribute *attr,
.name = __stringify(_name), .mode = _mode,  \
};
 
-static ATTR(active, 0644);
-static ATTR(num, 0644);
-static ATTR(size, 0644);
+static ATTR(active, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+static ATTR(num, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+static ATTR(size, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
 
 static struct attribute *veth_pool_attrs[] = {
_active_attr,
-- 
2.9.2

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

[PATCH 0683/1285] Replace numeric parameter like 0444 with macro

[Baole Ni]

I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the 
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 drivers/misc/cxl/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/cxl/main.c b/drivers/misc/cxl/main.c
index ae68c32..98b36a6 100644
--- a/drivers/misc/cxl/main.c
+++ b/drivers/misc/cxl/main.c
@@ -29,7 +29,7 @@ static DEFINE_SPINLOCK(adapter_idr_lock);
 static DEFINE_IDR(cxl_adapter_idr);
 
 uint cxl_verbose;
-module_param_named(verbose, cxl_verbose, uint, 0600);
+module_param_named(verbose, cxl_verbose, uint, S_IRUSR | S_IWUSR);
 MODULE_PARM_DESC(verbose, "Enable verbose dmesg output");
 
 const struct cxl_backend_ops *cxl_ops;
-- 
2.9.2

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

[PATCH 0867/1285] Replace numeric parameter like 0444 with macro

[Baole Ni]

I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the 
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 drivers/ps3/ps3av.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ps3/ps3av.c b/drivers/ps3/ps3av.c
index 437fc35..9753ed0 100644
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -38,7 +38,7 @@
 static int safe_mode;
 
 static int timeout = 5000; /* in msec ( 5 sec ) */
-module_param(timeout, int, 0644);
+module_param(timeout, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
 
 static struct ps3av {
struct mutex mutex;
-- 
2.9.2

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

[PATCH 0824/1285] Replace numeric parameter like 0444 with macro

[Baole Ni]

I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the 
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 drivers/pci/hotplug/rpaphp_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/hotplug/rpaphp_core.c 
b/drivers/pci/hotplug/rpaphp_core.c
index 8d13202..48783a5 100644
--- a/drivers/pci/hotplug/rpaphp_core.c
+++ b/drivers/pci/hotplug/rpaphp_core.c
@@ -51,7 +51,7 @@ MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL");
 
-module_param_named(debug, rpaphp_debug, bool, 0644);
+module_param_named(debug, rpaphp_debug, bool, S_IRUSR | S_IWUSR | S_IRGRP | 
S_IROTH);
 
 /**
  * set_attention_status - set attention LED
-- 
2.9.2

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

[PATCH 0313/1285] Replace numeric parameter like 0444 with macro

[Baole Ni]

I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the 
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 drivers/macintosh/therm_adt746x.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/macintosh/therm_adt746x.c 
b/drivers/macintosh/therm_adt746x.c
index f433521..23c2e3c 100644
--- a/drivers/macintosh/therm_adt746x.c
+++ b/drivers/macintosh/therm_adt746x.c
@@ -58,11 +58,11 @@ MODULE_DESCRIPTION("Driver for ADT746x thermostat in iBook 
G4 and "
   "Powerbook G4 Alu");
 MODULE_LICENSE("GPL");
 
-module_param(limit_adjust, int, 0644);
+module_param(limit_adjust, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
 MODULE_PARM_DESC(limit_adjust,"Adjust maximum temperatures (50 sensor1, 70 
sensor2) "
 "by N degrees.");
 
-module_param(fan_speed, int, 0644);
+module_param(fan_speed, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
 MODULE_PARM_DESC(fan_speed,"Specify starting fan speed (0-255) "
 "(default 64)");
 
-- 
2.9.2

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

[PATCH 0312/1285] Replace numeric parameter like 0444 with macro

[Baole Ni]

I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the 
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 drivers/macintosh/ams/ams-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/macintosh/ams/ams-core.c b/drivers/macintosh/ams/ams-core.c
index 36a4fdd..8abbecd 100644
--- a/drivers/macintosh/ams/ams-core.c
+++ b/drivers/macintosh/ams/ams-core.c
@@ -32,7 +32,7 @@
 struct ams ams_info;
 
 static bool verbose;
-module_param(verbose, bool, 0644);
+module_param(verbose, bool, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
 MODULE_PARM_DESC(verbose, "Show free falls and shocks in kernel output");
 
 /* Call with ams_info.lock held! */
-- 
2.9.2

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

[PATCH 0311/1285] Replace numeric parameter like 0444 with macro

[Baole Ni]

I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the 
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 drivers/macintosh/adbhid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/macintosh/adbhid.c b/drivers/macintosh/adbhid.c
index 09d72bb..d6cbd1d 100644
--- a/drivers/macintosh/adbhid.c
+++ b/drivers/macintosh/adbhid.c
@@ -53,7 +53,7 @@
 MODULE_AUTHOR("Franz Sirl ");
 
 static int restore_capslock_events;
-module_param(restore_capslock_events, int, 0644);
+module_param(restore_capslock_events, int, S_IRUSR | S_IWUSR | S_IRGRP | 
S_IROTH);
 MODULE_PARM_DESC(restore_capslock_events,
"Produce keypress events for capslock on both keyup and keydown.");
 
-- 
2.9.2

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

[PATCH 0157/1285] Replace numeric parameter like 0444 with macro

[Baole Ni]

I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the 
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 drivers/edac/pasemi_edac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/edac/pasemi_edac.c b/drivers/edac/pasemi_edac.c
index 9c971b5..8150e95 100644
--- a/drivers/edac/pasemi_edac.c
+++ b/drivers/edac/pasemi_edac.c
@@ -310,6 +310,6 @@ module_exit(pasemi_edac_exit);
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Egor Martovetsky ");
 MODULE_DESCRIPTION("MC support for PA Semi PWRficient memory controller");
-module_param(edac_op_state, int, 0444);
+module_param(edac_op_state, int, S_IRUSR | S_IRGRP | S_IROTH);
 MODULE_PARM_DESC(edac_op_state, "EDAC Error Reporting state: 0=Poll,1=NMI");
 
-- 
2.9.2

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

[PATCH 0018/1285] Replace numeric parameter like 0444 with macro

[Baole Ni]

I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the 
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 arch/powerpc/platforms/powernv/idle.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/idle.c 
b/arch/powerpc/platforms/powernv/idle.c
index fcc8b68..69232b1 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -226,7 +226,7 @@ fail:
return -EIO;
 }
 
-static DEVICE_ATTR(fastsleep_workaround_applyonce, 0600,
+static DEVICE_ATTR(fastsleep_workaround_applyonce, S_IRUSR | S_IWUSR,
show_fastsleep_workaround_applyonce,
store_fastsleep_workaround_applyonce);
 
-- 
2.9.2

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

[PATCH 0019/1285] Replace numeric parameter like 0444 with macro

[Baole Ni]

I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the 
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 arch/powerpc/platforms/powernv/subcore.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/subcore.c 
b/arch/powerpc/platforms/powernv/subcore.c
index 0babef1..efffe94 100644
--- a/arch/powerpc/platforms/powernv/subcore.c
+++ b/arch/powerpc/platforms/powernv/subcore.c
@@ -402,7 +402,7 @@ static ssize_t show_subcores_per_core(struct device *dev,
return sprintf(buf, "%x\n", subcores_per_core);
 }
 
-static DEVICE_ATTR(subcores_per_core, 0644,
+static DEVICE_ATTR(subcores_per_core, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH,
show_subcores_per_core, store_subcores_per_core);
 
 static int subcore_init(void)
-- 
2.9.2

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

[PATCH 0017/1285] Replace numeric parameter like 0444 with macro

[Baole Ni]

I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the 
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 arch/powerpc/platforms/cell/spu_base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/cell/spu_base.c 
b/arch/powerpc/platforms/cell/spu_base.c
index 3cbe38f..0236844 100644
--- a/arch/powerpc/platforms/cell/spu_base.c
+++ b/arch/powerpc/platforms/cell/spu_base.c
@@ -674,7 +674,7 @@ static ssize_t spu_stat_show(struct device *dev,
spu->stats.libassist);
 }
 
-static DEVICE_ATTR(stat, 0444, spu_stat_show, NULL);
+static DEVICE_ATTR(stat, S_IRUSR | S_IRGRP | S_IROTH, spu_stat_show, NULL);
 
 #ifdef CONFIG_KEXEC
 
-- 
2.9.2

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

[PATCH 0016/1285] Replace numeric parameter like 0444 with macro

[Baole Ni]

I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the 
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 arch/powerpc/platforms/cell/cbe_thermal.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/platforms/cell/cbe_thermal.c 
b/arch/powerpc/platforms/cell/cbe_thermal.c
index 2c15ff0..39bc790 100644
--- a/arch/powerpc/platforms/cell/cbe_thermal.c
+++ b/arch/powerpc/platforms/cell/cbe_thermal.c
@@ -254,9 +254,9 @@ static struct device_attribute attr_spu_temperature = {
.show = spu_show_temp,
 };
 
-static DEVICE_PREFIX_ATTR(spu, throttle_end, 0600);
-static DEVICE_PREFIX_ATTR(spu, throttle_begin, 0600);
-static DEVICE_PREFIX_ATTR(spu, throttle_full_stop, 0600);
+static DEVICE_PREFIX_ATTR(spu, throttle_end, S_IRUSR | S_IWUSR);
+static DEVICE_PREFIX_ATTR(spu, throttle_begin, S_IRUSR | S_IWUSR);
+static DEVICE_PREFIX_ATTR(spu, throttle_full_stop, S_IRUSR | S_IWUSR);
 
 
 static struct attribute *spu_attributes[] = {
@@ -282,9 +282,9 @@ static struct device_attribute attr_ppe_temperature1 = {
.show = ppe_show_temp1,
 };
 
-static DEVICE_PREFIX_ATTR(ppe, throttle_end, 0600);
-static DEVICE_PREFIX_ATTR(ppe, throttle_begin, 0600);
-static DEVICE_PREFIX_ATTR(ppe, throttle_full_stop, 0600);
+static DEVICE_PREFIX_ATTR(ppe, throttle_end, S_IRUSR | S_IWUSR);
+static DEVICE_PREFIX_ATTR(ppe, throttle_begin, S_IRUSR | S_IWUSR);
+static DEVICE_PREFIX_ATTR(ppe, throttle_full_stop, S_IRUSR | S_IWUSR);
 
 static struct attribute *ppe_attributes[] = {
_ppe_temperature0.attr,
-- 
2.9.2

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

[PATCH 0015/1285] Replace numeric parameter like 0444 with macro

[Baole Ni]

I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the 
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 arch/powerpc/kernel/sysfs.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 692873b..b2495e8 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -63,7 +63,7 @@ static ssize_t show_smt_snooze_delay(struct device *dev,
return sprintf(buf, "%ld\n", per_cpu(smt_snooze_delay, cpu->dev.id));
 }
 
-static DEVICE_ATTR(smt_snooze_delay, 0644, show_smt_snooze_delay,
+static DEVICE_ATTR(smt_snooze_delay, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, 
show_smt_snooze_delay,
   store_smt_snooze_delay);
 
 static int __init setup_smt_snooze_delay(char *str)
@@ -360,8 +360,8 @@ static ssize_t store_altivec_idle_wait_time(struct device 
*dev,
  * Enable/Disable interface:
  * 0, disable. 1, enable.
  */
-static DEVICE_ATTR(pw20_state, 0600, show_pw20_state, store_pw20_state);
-static DEVICE_ATTR(altivec_idle, 0600, show_altivec_idle, store_altivec_idle);
+static DEVICE_ATTR(pw20_state, S_IRUSR | S_IWUSR, show_pw20_state, 
store_pw20_state);
+static DEVICE_ATTR(altivec_idle, S_IRUSR | S_IWUSR, show_altivec_idle, 
store_altivec_idle);
 
 /*
  * Set wait time interface:(Nanosecond)
@@ -374,10 +374,10 @@ static DEVICE_ATTR(altivec_idle, 0600, show_altivec_idle, 
store_altivec_idle);
  * 781~1560(ns): TB[58]
  * ...
  */
-static DEVICE_ATTR(pw20_wait_time, 0600,
+static DEVICE_ATTR(pw20_wait_time, S_IRUSR | S_IWUSR,
show_pw20_wait_time,
store_pw20_wait_time);
-static DEVICE_ATTR(altivec_idle_wait_time, 0600,
+static DEVICE_ATTR(altivec_idle_wait_time, S_IRUSR | S_IWUSR,
show_altivec_idle_wait_time,
store_altivec_idle_wait_time);
 #endif
@@ -491,10 +491,10 @@ SYSFS_SPRSETUP(pir, SPRN_PIR);
   enable write when needed with a separate function.
   Lets be conservative and default to pseries.
 */
-static DEVICE_ATTR(mmcra, 0600, show_mmcra, store_mmcra);
-static DEVICE_ATTR(spurr, 0400, show_spurr, NULL);
-static DEVICE_ATTR(purr, 0400, show_purr, store_purr);
-static DEVICE_ATTR(pir, 0400, show_pir, NULL);
+static DEVICE_ATTR(mmcra, S_IRUSR | S_IWUSR, show_mmcra, store_mmcra);
+static DEVICE_ATTR(spurr, S_IRUSR, show_spurr, NULL);
+static DEVICE_ATTR(purr, S_IRUSR, show_purr, store_purr);
+static DEVICE_ATTR(pir, S_IRUSR, show_pir, NULL);
 
 /*
  * This is the system wide DSCR register default value. Any
@@ -534,7 +534,7 @@ static void write_dscr(void *val)
 }
 
 SYSFS_SPRSETUP_SHOW_STORE(dscr);
-static DEVICE_ATTR(dscr, 0600, show_dscr, store_dscr);
+static DEVICE_ATTR(dscr, S_IRUSR | S_IWUSR, show_dscr, store_dscr);
 
 static void add_write_permission_dev_attr(struct device_attribute *attr)
 {
@@ -581,7 +581,7 @@ static ssize_t __used store_dscr_default(struct device *dev,
return count;
 }
 
-static DEVICE_ATTR(dscr_default, 0600,
+static DEVICE_ATTR(dscr_default, S_IRUSR | S_IWUSR,
show_dscr_default, store_dscr_default);
 
 static void sysfs_create_dscr_default(void)
@@ -1019,7 +1019,7 @@ static ssize_t show_physical_id(struct device *dev,
 
return sprintf(buf, "%d\n", get_hard_smp_processor_id(cpu->dev.id));
 }
-static DEVICE_ATTR(physical_id, 0444, show_physical_id, NULL);
+static DEVICE_ATTR(physical_id, S_IRUSR | S_IRGRP | S_IROTH, show_physical_id, 
NULL);
 
 static int __init topology_init(void)
 {
-- 
2.9.2

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

Re: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to include/linux/fsl

[Scott Wood]

On Tue, 2016-08-02 at 05:57 +, Yangbo Lu wrote:
> Hi Scott,
> 
> > 
> > -Original Message-
> > From: Scott Wood [mailto:o...@buserror.net]
> > Sent: Wednesday, July 27, 2016 8:38 AM
> > To: Yangbo Lu; Michael Ellerman; Arnd Bergmann; Ulf Hansson
> > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; linuxppc-
> > d...@lists.ozlabs.org; linux-ker...@vger.kernel.org
> > Subject: Re: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to
> > include/linux/fsl
> > 
> > On Mon, 2016-07-25 at 06:12 +, Yangbo Lu wrote:
> > > 
> > > Hi Scott,
> > > 
> > > 
> > > > 
> > > > 
> > > > -Original Message-
> > > > From: Scott Wood [mailto:o...@buserror.net]
> > > > Sent: Friday, July 22, 2016 12:45 AM
> > > > To: Michael Ellerman; Arnd Bergmann
> > > > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; linuxppc-
> > > > d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Yangbo Lu
> > > > Subject: Re: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to
> > > > include/linux/fsl
> > > > 
> > > > On Thu, 2016-07-21 at 20:26 +1000, Michael Ellerman wrote:
> > > > > 
> > > > > 
> > > > > Quoting Scott Wood (2016-07-21 04:31:48)
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Wed, 2016-07-20 at 13:24 +0200, Arnd Bergmann wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On Saturday, July 16, 2016 9:50:21 PM CEST Scott Wood wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > From: yangbo lu 
> > > > > > > > 
> > > > > > > > Move mpc85xx.h to include/linux/fsl and rename it to svr.h
> > > > > > > > as a common header file.  This SVR numberspace is used on
> > > > > > > > some ARM chips as well as PPC, and even to check for a PPC
> > > > > > > > SVR multi-arch drivers would otherwise need to ifdef the
> > > > > > > > header inclusion and all references to the SVR symbols.
> > > > > > > > 
> > > > > > > > Signed-off-by: Yangbo Lu 
> > > > > > > > Acked-by: Wolfram Sang 
> > > > > > > > Acked-by: Stephen Boyd 
> > > > > > > > Acked-by: Joerg Roedel 
> > > > > > > > [scottwood: update description]
> > > > > > > > Signed-off-by: Scott Wood 
> > > > > > > > 
> > > > > > > As discussed before, please don't introduce yet another vendor
> > > > > > > specific way to match a SoC ID from a device driver.
> > > > > > > 
> > > > > > > I've posted a patch for an extension to the soc_device
> > > > > > > infrastructure to allow comparing the running SoC to a table
> > > > > > > of devices, use that instead.
> > > > > > As I asked before, in which relevant maintainership capacity are
> > > > > > you NACKing this?
> > > > > I'll nack the powerpc part until you guys can agree.
> > > > OK, I've pulled these patches out.
> > > > 
> > > > For the MMC issue I suggest using ifdef CONFIG_PPC and
> > > > mfspr(SPRN_SVR) like the clock driver does[1] and we can revisit the
> > > > issue if/when we need to do something similar on an ARM chip.
> > > [Lu Yangbo-B47093] I remembered that Uffe had opposed us to introduce
> > > non- generic header files(like '#include ') in mmc
> > > driver initially. So I think it will not be accepted to use ifdef
> > > CONFIG_PPC and mfspr(SPRN_SVR)...
> > > And this method still couldn’t get SVR of ARM chip now.
> > Right, as I said we'll have to revisit the issue if/when we have the same
> > problem on an ARM chip.  That also applies if the PPC ifdef is still
> > getting NACKed from the MMC side.
> [Lu Yangbo-B47093] It's not clear for me about your idea :( 
> Do you mean we can still use this method, or not ?
> I think Uffe had opposed to use ifdef CONFIG_PPC and mfspr(SPRN_SVR).
> Is there any solution to resolve ?
> :)

As I said, I'm OK with using the SPR.  It's up to you to find out whether it's
still unacceptable with the MMC maintainers given all the discussion (it would
be the quickest way to get the workaround enabled), or just go with the method
below.

> > > Any other suggestion here?
> > The other option is to try to come up with something that fits into
> > Arnd's framework while addressing the concerns I raised.  The soc_id
> > string should be well-structured to avoid mismatches and compatibility
> > problems (especially since it would get exposed to userspace).  Maybe
> > something like:
> > 
> > svr:,svre:,name: > name>,die:,rev:X.Y,,,<...>,
> [Lu Yangbo-B47093] The soc_device_attribut struct is defined as below.
> struct soc_device_attribute {
> const char *machine;
> const char *family;
> const char *revision;
> const char *soc_id;
> };
> 
> We can put the 'model' in root node of dts as machine, put 'Freescale QorIQ'
> as family,

I'd just put "QorIQ" to avoid the question of whether to use "Freescale" or
"NXP".

> and put x.x as revision. Is it ok?
> As you suggested, you like to use below string as soc_id. It's easy to get
> svr, but how does the software know the 

Re: [v4] Fix to avoid IS_ERR_VALUE and IS_ERR abuses on 64bit systems.

[Scott Wood]

On 08/02/2016 10:34 AM, arvind Yadav wrote:
> 
> 
> On Tuesday 02 August 2016 01:15 PM, Arnd Bergmann wrote:
>> On Monday, August 1, 2016 4:55:43 PM CEST Scott Wood wrote:
>>> On 08/01/2016 02:02 AM, Arnd Bergmann wrote:
> diff --git a/include/linux/err.h b/include/linux/err.h
> index 1e35588..c2a2789 100644
> --- a/include/linux/err.h
> +++ b/include/linux/err.h
> @@ -18,7 +18,17 @@
>  
>  #ifndef __ASSEMBLY__
>  
> -#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned 
> long)-MAX_ERRNO)
> +#define IS_ERR_VALUE(x) unlikely(is_error_check(x))
> +
> +static inline int is_error_check(unsigned long error)
 Please leave the existing macro alone. I think you were looking for
 something specific to the return code of qe_muram_alloc() function,
 so please add a helper in that subsystem if you need it, not in
 the generic header files.
>>> qe_muram_alloc (a.k.a. cpm_muram_alloc) returns unsigned long.  The
>>> problem is certain callers that store the return value in a u32.  Why
>>> not just fix those callers to store it in unsigned long (at least until
>>> error checking is done)?
>>>
>> Yes, that would also address another problem with code like
>>
>>  kfree((void *)ugeth->tx_bd_ring_offset[i]);
>>
>> which is not 64-bit safe when tx_bd_ring_offset is a 32-bit value
>> that also holds the return value of qe_muram_alloc.

Well, hopefully it doesn't hold a return of qe_muram_alloc() when it's
being passed to kfree()...

There's also the code that casts kmalloc()'s return to u32, etc.
ucc_geth is not 64-bit clean in general.

>>
>>  Arnd
> Yes, we will fix caller. Caller api is not safe on 64bit.

The API is fine (or at least, I haven't seen a valid issue pointed out
yet).  The problem is the ucc_geth driver.

> Even qe_muram_addr(a.k.a. cpm_muram_addr )passing value unsigned int,
> but it should be unsigned long.

cpm_muram_addr takes unsigned long as a parameter, not that it matters
since you can't pass errors into it and a muram offset should never
exceed 32 bits.

-Scott

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

Re: [PATCH v4 2/2] powerpc/pseries: Implement indexed-count hotplug memory remove

[Nathan Fontenot]

On 08/01/2016 12:23 PM, Sahil Mehta wrote:
> Indexed-count remove for memory hotplug guarantees that a contiguous block
> of  lmbs beginning at a specified  will be unassigned (NOT
> that  lmbs will be removed). Because of Qemu's per-DIMM memory
> management, the removal of a contiguous block of memory currently
> requires a series of individual calls. Indexed-count remove reduces
> this series into a single call.
> 
> Signed-off-by: Sahil Mehta 

Reviewed-by: Nathan Fontenot 

> ---
> v2:   -use u32s drc_index and count instead of u32 ic[]
>in dlpar_memory
> v3:   -add logic to handle invalid drc_index input
> v4:   -none
> 
>  arch/powerpc/platforms/pseries/hotplug-memory.c |   90 
> +++
>  1 file changed, 90 insertions(+)

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

Re: [PATCH v4 1/2] powerpc/pseries: Implement indexed-count hotplug memory add

[Nathan Fontenot]

On 08/01/2016 12:21 PM, Sahil Mehta wrote:
> Indexed-count add for memory hotplug guarantees that a contiguous block
> of  lmbs beginning at a specified  will be assigned (NOT
> that  lmbs will be added). Because of Qemu's per-DIMM memory
> management, the addition of a contiguous block of memory currently
> requires a series of individual calls. Indexed-count add reduces
> this series into a single call.
> 
> Signed-off-by: Sahil Mehta 

Reviewed-by: Nathan Fontenot 

> ---
> v2:   -remove potential memory leak when parsing command
>   -use u32s drc_index and count instead of u32 ic[]
>in dlpar_memory
> v3:   -add logic to handle invalid drc_index input
>   -update indexed-count trigger to follow naming convention
>   -update dlpar_memory to follow kernel if-else style
> v4:   -add logic to handle kstrdup failure
>   -add logic to handle invalid command format
> 
>  arch/powerpc/include/asm/rtas.h |2
>  arch/powerpc/platforms/pseries/dlpar.c  |   46 +-
>  arch/powerpc/platforms/pseries/hotplug-memory.c |  110 
> +--
>  3 files changed, 146 insertions(+), 12 deletions(-)

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

powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

[Luis R. Rodriguez]

Are linux-next builds being tested for powerpc with allyesconfig and
allmodconfig ? I have some changes I'm making and while debugging my
build issues I decided to give a clean build a shot and see linux-next
next-20160729 up to next-20160729 all have build failures without my
changes. I get:

/opt/gcc-4.9.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld:
drivers/built-in.o: .opd is not a regular array of opd entries
  MODPOST vmlinux.o
  GEN .version
  CHK include/generated/compile.h
  UPD include/generated/compile.h
  CC  init/version.o
  LD  init/built-in.o
/opt/gcc-4.9.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld:
drivers/built-in.o: .opd is not a regular array of opd entries
drivers/built-in.o: In function `.ipw2100_up':
ipw2100.c:(.text+0x1ff9c90): relocation truncated to fit:
R_PPC64_REL24 (stub) against symbol `.round_jiffies_relative' defined
in .text section in kernel/built-in.o
drivers/built-in.o: In function `.ipw2100_reset_adapter':
ipw2100.c:(.text+0x1ffa500): relocation truncated to fit:
R_PPC64_REL24 (stub) against symbol `._raw_spin_lock_irqsave' defined
in .spinlock.text section in kernel/built-in.o
drivers/built-in.o: In function `.ipw2100_irq_tasklet':
ipw2100.c:(.text+0x1ffa7cc): relocation truncated to fit:
R_PPC64_REL24 (stub) against symbol `._raw_spin_lock_irqsave' defined
in .spinlock.text section in kernel/built-in.o
ipw2100.c:(.text+0x1ffb6c8): relocation truncated to fit:
R_PPC64_REL24 (stub) against symbol `.printk' defined in
.text.unlikely section in kernel/built-in.o
ipw2100.c:(.text+0x1ffb6d8): relocation truncated to fit:
R_PPC64_REL24 (stub) against symbol `.printk' defined in
.text.unlikely section in kernel/built-in.o
ipw2100.c:(.text+0x1ffb740): relocation truncated to fit:
R_PPC64_REL24 (stub) against symbol `.printk' defined in
.text.unlikely section in kernel/built-in.o
ipw2100.c:(.text+0x1ffb750): relocation truncated to fit:
R_PPC64_REL24 (stub) against symbol `.printk' defined in
.text.unlikely section in kernel/built-in.o
ipw2100.c:(.text+0x1ffb7ec): relocation truncated to fit:
R_PPC64_REL24 (stub) against symbol `.debug_dma_unmap_page' defined in
.text section in lib/built-in.o
ipw2100.c:(.text+0x1ffb88c): relocation truncated to fit:
R_PPC64_REL24 (stub) against symbol `.__dev_kfree_skb_any' defined in
.text section in net/built-in.o
ipw2100.c:(.text+0x1ffb8b8): relocation truncated to fit:
R_PPC64_REL24 (stub) against symbol `.printk' defined in
.text.unlikely section in kernel/built-in.o
ipw2100.c:(.text+0x1ffb8f4): additional relocation overflows omitted
from the output
scripts/link-vmlinux.sh: line 52: 14580 Segmentation fault  (core
dumped) ${LD} ${LDFLAGS} ${LDFLAGS_vmlinux} -o ${2} -T ${lds}
${KBUILD_VMLINUX_INIT} --start-group ${KBUILD_VMLINUX_MAIN}
--end-group ${1}
make: *** [Makefile:952: vmlinux] Error 139

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

Re: [PATCH] powerpc: Do not make the entire heap executable

[Jason Gunthorpe]

On Mon, Aug 01, 2016 at 11:07:21PM +0200, Denys Vlasenko wrote:
> On 32-bit powerps the ELF PLT sections of binaries (built with --bss-plt,
> or with a toolchain which defaults to it) look like this:

Hi Denys,

Thanks for resurrecting this, I am still interested here, we have been
using this patch in our PPC & ARM32 systems since it was posted.

Benjamin gave some feedback that some small style issues might need
changing, but I never agitated enough to get feedback from mm or core,
which is really what is needed for this patch..

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

Re: [PATCH 0157/1285] Replace numeric parameter like 0444 with macro

[Segher Boessenkool]

On Tue, Aug 02, 2016 at 11:54:47AM -0700, Olof Johansson wrote:
> On Tue, Aug 02, 2016 at 06:45:15PM +0800, Baole Ni wrote:
> > I find that the developers often just specified the numeric value
> > when calling a macro which is defined with a parameter for access 
> > permission.
> > As we know, these numeric value for access permission have had the 
> > corresponding macro,
> > and that using macro can improve the robustness and readability of the code,
> > thus, I suggest replacing the numeric parameter with the macro.
> 
> Am I the only one who find the readability to be MUCH better for the
> numeric values?

You are not the only one.  Robustness is a non-issue here as well (except
that this patch series showed that some mail servers struggle to handle
1285 emails).


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

Re: [kernel-hardening] Re: Linker segfault on powerpc when CONFIG_LKDTM=y (was Re: [kernel-hardening] [PATCH 3/5] lkdtm: add function for testing .rodata section)

[Kees Cook]

On Mon, Aug 1, 2016 at 8:12 PM, Michael Ellerman  wrote:
> Kees Cook  writes:
>
>> On Mon, Aug 1, 2016 at 5:37 AM, Michael Ellerman  wrote:
>>> Kees Cook  writes:
>>>
 This adds a function that lives in the .rodata section. The section
 flags are corrected using objcopy since there is no way with gcc to
 declare section flags in an architecture-agnostic way.

 Signed-off-by: Kees Cook 
 ---
  drivers/misc/Makefile   |  7 +++
  drivers/misc/lkdtm.h|  6 ++
  drivers/misc/lkdtm_core.c   | 24 +---
  drivers/misc/lkdtm_rodata.c | 10 ++
  4 files changed, 40 insertions(+), 7 deletions(-)
  create mode 100644 drivers/misc/lkdtm.h
  create mode 100644 drivers/misc/lkdtm_rodata.c
>>>
>>> This is blowing up my linker :(
>>>
>>>   scripts/link-vmlinux.sh: line 52: 36260 Segmentation fault  (core 
>>> dumped) ${LD} ${LDFLAGS} ${LDFLAGS_vmlinux} -o ${2} -T ${lds} 
>>> ${KBUILD_VMLINUX_INIT} --start-group ${KBUILD_VMLINUX_MAIN} --end-group ${1}
>>>
>>> Haven't had a chance to debug it further.
>>
>> Argh. Do you want a quick fix for this now? I can add a PPC CONFIG
>> blacklist for the rodata check, maybe?
>
> Nah that's OK, none of our defconfigs have it enabled so it's not a real
> blocker. It also builds OK as a module - though I haven't tested the
> result yet.

Okay, I'll leave it as is.

>> Also, what version of gcc? I'll see if I can reproduce this with a
>> cross compiler...
>
> The original hit was with gcc-5.3 (which is actually a x86->ppc cross):
>
>   http://kisskb.ellerman.id.au/kisskb/buildresult/12762730/
>
> But I can also reproduce with 5.4, and 6.1.0.
>
> Interestingly I *can't* reproduce with the Ubuntu x86->ppc cross
> (5.4.0-6ubuntu1~16.04.1).

Oh, weird. Well, that does explains my lack of hitting the problem,
though: that's the cross compiler I was using. :P

> Those toolchains are all using binutils 2.26 AFAIK.

I wonder if this is some gold vs bfd issue, or a specific bug that got
fixed in the Ubuntu tree but hasn't landed in 6.1 or 5.4 (??)

> Going back to a really old toolchain (gcc 4.6.3/binutils 2.22) it does
> build but I get these warnings:
>
>  powerpc64-linux-ld: drivers/misc/built-in.o: .opd is not a regular array of 
> opd entries
>  powerpc64-linux-ld: drivers/built-in.o: .opd is not a regular array of opd 
> entries

How strange. I wonder if there's some corner case of the objcopy that
is wrong...

> So probably don't worry about it and we'll try and work it out on our end.

Okay, sounds good.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0157/1285] Replace numeric parameter like 0444 with macro

[Olof Johansson]

On Tue, Aug 02, 2016 at 06:45:15PM +0800, Baole Ni wrote:
> I find that the developers often just specified the numeric value
> when calling a macro which is defined with a parameter for access permission.
> As we know, these numeric value for access permission have had the 
> corresponding macro,
> and that using macro can improve the robustness and readability of the code,
> thus, I suggest replacing the numeric parameter with the macro.

Am I the only one who find the readability to be MUCH better for the
numeric values?


-Olof

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

Re: [PATCH v2] powerpc/32: fix csum_partial_copy_generic()

[Segher Boessenkool]

On Tue, Aug 02, 2016 at 10:07:05AM +0200, Christophe Leroy wrote:
> commit 7aef4136566b0 ("powerpc32: rewrite csum_partial_copy_generic()
> based on copy_tofrom_user()") introduced a bug when destination
> address is odd and initial csum is not null
> 
> In that (rare) case the initial csum value has to be rotated one byte
> as well as the resulting value is
> 
> This patch also fixes related comments
> 
> Fixes: 7aef4136566b0 ("powerpc32: rewrite csum_partial_copy_generic()
> based on copy_tofrom_user()")
> Cc: sta...@vger.kernel.org
> 
> Signed-off-by: Christophe Leroy 
> ---
>  v2: updated comments as suggested by Segher

Thanks.  It looks good to me now.


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

Re: [PATCH 1/2] mm: Allow disabling deferred struct page initialisation

[Dave Hansen]

On 08/02/2016 06:19 AM, Srikar Dronamraju wrote:
> Kernels compiled with CONFIG_DEFERRED_STRUCT_PAGE_INIT will initialise
> only certain size memory per node. The certain size takes into account
> the dentry and inode cache sizes. However such a kernel when booting a
> secondary kernel will not be able to allocate the required amount of
> memory to suffice for the dentry and inode caches. This results in
> crashes like the below on large systems such as 32 TB systems.

What's a "secondary kernel"?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0867/1285] Replace numeric parameter like 0444 with macro

[Geoff Levand]

On Tue, 2016-08-02 at 19:53 +0800, Baole Ni wrote:
> I find that the developers often just specified the numeric value
> when calling a macro which is defined with a parameter for access
> permission.
> As we know, these numeric value for access permission have had the
> corresponding macro,
> and that using macro can improve the robustness and readability of
> the code,
> thus, I suggest replacing the numeric parameter with the macro.
> 
> Signed-off-by: Chuansheng Liu 
> Signed-off-by: Baole Ni 
> ---
>  
>  static int timeout = 5000;   /* in msec ( 5 sec ) */
> -module_param(timeout, int, 0644);
> +module_param(timeout, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);

To me, 644 is more 'readable', and as for robustness, the meaning of
644 will never change.

-Geoff

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

Re: [v4] Fix to avoid IS_ERR_VALUE and IS_ERR abuses on 64bit systems.

[arvind Yadav]

On Tuesday 02 August 2016 01:15 PM, Arnd Bergmann wrote:

On Monday, August 1, 2016 4:55:43 PM CEST Scott Wood wrote:

On 08/01/2016 02:02 AM, Arnd Bergmann wrote:

diff --git a/include/linux/err.h b/include/linux/err.h
index 1e35588..c2a2789 100644
--- a/include/linux/err.h
+++ b/include/linux/err.h
@@ -18,7 +18,17 @@
  
  #ifndef __ASSEMBLY__
  
-#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)

+#define IS_ERR_VALUE(x) unlikely(is_error_check(x))
+
+static inline int is_error_check(unsigned long error)

Please leave the existing macro alone. I think you were looking for
something specific to the return code of qe_muram_alloc() function,
so please add a helper in that subsystem if you need it, not in
the generic header files.

qe_muram_alloc (a.k.a. cpm_muram_alloc) returns unsigned long.  The
problem is certain callers that store the return value in a u32.  Why
not just fix those callers to store it in unsigned long (at least until
error checking is done)?


Yes, that would also address another problem with code like

  kfree((void *)ugeth->tx_bd_ring_offset[i]);

which is not 64-bit safe when tx_bd_ring_offset is a 32-bit value
that also holds the return value of qe_muram_alloc.

Arnd

Yes, we will fix caller. Caller api is not safe on 64bit.
Even qe_muram_addr(a.k.a. cpm_muram_addr )passing value unsigned int,
but it should be unsigned long. Need to work on it.

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

[PATCH v3 1/5] powerpc/dts: add mcke-gpios for PM feature

[Chenhui Zhao]

Signed-off-by: Chenhui Zhao 
---
 Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 13 +
 arch/powerpc/boot/dts/fsl/t1040si-post.dtsi|  3 +++
 2 files changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt 
b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
index e284e4e..1d44a80 100644
--- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
@@ -21,6 +21,10 @@ Required properites:
* "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm
* "fsl,qoriq-rcpm-2.1": for chassis 2.1 rcpm
 
+Optional properites:
+  - mcke-gpios : The GPIO pin is used for keeping the MCKE signal of DDR 
modules
+low in the LPM35 state on some platforms, such as T1040.
+
 All references to "1.0" and "2.0" refer to the QorIQ chassis version to
 which the chip complies.
 Chassis VersionExample Chips
@@ -37,6 +41,15 @@ The RCPM node for T4240:
fsl,#rcpm-wakeup-cells = <2>;
};
 
+The RCPM node for T1040 (which supports LPM35 state):
+   rcpm: global-utilities@e2000 {
+   compatible = "fsl,t1040-rcpm", "fsl,qoriq-rcpm-2.1";
+   reg = <0xe2000 0x1000>;
+   fsl,#rcpm-wakeup-cells = <1>;
+   mcke-gpios = < 29 GPIO_ACTIVE_HIGH>
+   };
+
+
 * Freescale RCPM Wakeup Source Device Tree Bindings
 ---
 Required fsl,rcpm-wakeup property should be added to a device node if the 
device
diff --git a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
index 507649e..f66e7dd 100644
--- a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
@@ -33,6 +33,7 @@
  */
 
 #include 
+#include 
 
 _fbpr {
compatible = "fsl,bman-fbpr";
@@ -474,6 +475,8 @@
rcpm: global-utilities@e2000 {
compatible = "fsl,t1040-rcpm", "fsl,qoriq-rcpm-2.1";
reg = <0xe2000 0x1000>;
+   fsl,#rcpm-wakeup-cells = <1>;
+   mcke-gpios = < 29 GPIO_ACTIVE_HIGH>;
};
 
sfp: sfp@e8000 {
-- 
1.9.1

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

[PATCH v3 5/5] powerpc/pm: save and restore registers during deep sleep

[Chenhui Zhao]

Some CCSR registers will lost during deep sleep. Therefore,
should save them before entering deep sleep, and restore them
when resuming from deep sleep.

Signed-off-by: Tang Yuantian 
Signed-off-by: Chenhui Zhao 
---
 arch/powerpc/include/asm/fsl_pm.h   |   2 +
 arch/powerpc/platforms/85xx/deepsleep.c | 108 +++-
 2 files changed, 109 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/fsl_pm.h 
b/arch/powerpc/include/asm/fsl_pm.h
index 48c2631..95601fb 100644
--- a/arch/powerpc/include/asm/fsl_pm.h
+++ b/arch/powerpc/include/asm/fsl_pm.h
@@ -61,7 +61,9 @@ extern void fsl_dp_enter_low(void *priv);
 extern void fsl_booke_deep_sleep_resume(void);
 
 struct fsl_iomap {
+   void *ccsr_lcc_base;
void *ccsr_scfg_base;
+   void *ccsr_dcfg_base;
void *ccsr_rcpm_base;
void *ccsr_ddr_base;
void *ccsr_gpio1_base;
diff --git a/arch/powerpc/platforms/85xx/deepsleep.c 
b/arch/powerpc/platforms/85xx/deepsleep.c
index 9521d99..71987fd 100644
--- a/arch/powerpc/platforms/85xx/deepsleep.c
+++ b/arch/powerpc/platforms/85xx/deepsleep.c
@@ -23,6 +23,8 @@
 
 #include "sleep_fsm.h"
 
+#define CCSR_LAW_OFFSET0xC00
+
 #define CPC_CPCHDBCR0  0x0f00
 #define CPC_CPCHDBCR0_SPEC_DIS 0x0800
 
@@ -41,6 +43,17 @@
 #define QORIQ_CPLD_MISCCSR 0x17
 #define QORIQ_CPLD_MISCCSR_SLEEPEN 0x40
 
+#define CCSR_LCC_BSTRH 0x20
+#define CCSR_LCC_BSTRL 0x24
+#define CCSR_LCC_BSTAR 0x28
+
+#define CCSR_DCFG_BRR  0xE4
+
+#define CCSR_RCPM_PCTBENR  0x1A0
+
+/* the target id for the memory complex 1 (MC1) */
+#define MC1_TRGT_ID0x10
+
 /* 128 bytes buffer for restoring data broke by DDR training initialization */
 #define DDR_BUF_SIZE   128
 static u8 ddr_buff[DDR_BUF_SIZE] __aligned(64);
@@ -50,6 +63,23 @@ static void fsl_dp_iounmap(void);
 
 static struct fsl_iomap fsl_dp_priv;
 
+struct fsl_ccsr_law {
+   u32 lawbarh;/* LAWn base address high */
+   u32 lawbarl;/* LAWn base address low */
+   u32 lawar;  /* LAWn attributes */
+   u32 reserved;
+};
+
+static struct fsl_regs_buffer {
+   u32 bstrh;
+   u32 bstrl;
+   u32 bstar;
+   u32 brr;
+   u32 pctbenr;
+   u32 law_count;
+   void *law_regs;
+} fsl_dp_buffer;
+
 static const struct of_device_id fsl_dp_cpld_ids[] __initconst = {
{ .compatible = "fsl,t1024-cpld", },
{ .compatible = "fsl,t1040rdb-cpld", },
@@ -65,6 +95,60 @@ static const struct of_device_id fsl_dp_fpga_ids[] 
__initconst = {
{}
 };
 
+static void fsl_regs_save(struct fsl_iomap *base,
+ struct fsl_regs_buffer *buffer)
+{
+   int i;
+   struct fsl_ccsr_law *src = base->ccsr_lcc_base + CCSR_LAW_OFFSET;
+   struct fsl_ccsr_law *dst = buffer->law_regs;
+
+   buffer->bstrh = in_be32(base->ccsr_lcc_base + CCSR_LCC_BSTRH);
+   buffer->bstrl = in_be32(base->ccsr_lcc_base + CCSR_LCC_BSTRL);
+   buffer->bstar = in_be32(base->ccsr_lcc_base + CCSR_LCC_BSTAR);
+   buffer->brr = in_be32(base->ccsr_dcfg_base + CCSR_DCFG_BRR);
+   buffer->pctbenr = in_be32(base->ccsr_rcpm_base + CCSR_RCPM_PCTBENR);
+
+   for (i = 0; i < buffer->law_count; i++) {
+   dst->lawbarh = in_be32(>lawbarh);
+   dst->lawbarl = in_be32(>lawbarl);
+   dst->lawar = in_be32(>lawar);
+   dst++;
+   src++;
+   }
+}
+
+static void fsl_regs_restore(struct fsl_iomap *base,
+struct fsl_regs_buffer *buffer)
+{
+   int i;
+   u32 attr;
+   struct fsl_ccsr_law *src = buffer->law_regs;
+   struct fsl_ccsr_law *dst = base->ccsr_lcc_base + CCSR_LAW_OFFSET;
+
+   out_be32(base->ccsr_lcc_base + CCSR_LCC_BSTRH, buffer->bstrh);
+   out_be32(base->ccsr_lcc_base + CCSR_LCC_BSTRL, buffer->bstrl);
+   out_be32(base->ccsr_lcc_base + CCSR_LCC_BSTAR, buffer->bstar);
+   out_be32(base->ccsr_dcfg_base + CCSR_DCFG_BRR, buffer->brr);
+   out_be32(base->ccsr_rcpm_base + CCSR_RCPM_PCTBENR, buffer->pctbenr);
+
+   for (i = 0; i < buffer->law_count; i++) {
+   /*
+* If the LAW with the target id of MC1 has been set,
+* skip. Because changing it here causes memory
+* access error.
+*/
+   attr = in_be32(>lawar);
+   if (((attr >> 20) & 0xff) == MC1_TRGT_ID)
+   continue;
+   out_be32(>lawar, 0);
+   out_be32(>lawbarl, src->lawbarl);
+   out_be32(>lawbarh, src->lawbarh);
+   out_be32(>lawar, src->lawar);
+   src++;
+   dst++;
+   }
+}
+
 static void fsl_dp_set_resume_pointer(void)
 {
u32 resume_addr;
@@ -132,6 +216,8 @@ int fsl_enter_deepsleep(void)
 
fsl_dp_set_resume_pointer();
 
+   fsl_regs_save(_dp_priv, 

[PATCH 2/2] fadump: Disable deferred page struct initialisation

[Srikar Dronamraju]

Fadump kernel reserves significant number of memory blocks. On a multi-node
machine, with CONFIG_DEFFERRED_STRUCT_PAGE support, fadump kernel fails to
boot. Fix this by disabling deferred page struct initialisation.

Signed-off-by: Srikar Dronamraju 
---
 arch/powerpc/kernel/fadump.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 3cb3b02a..117faf2 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -318,6 +318,7 @@ int __init fadump_reserve_mem(void)
be64_to_cpu(fdm_active->rmr_region.source_len);
pr_debug("fadumphdr_addr = %p\n",
(void *) fw_dump.fadumphdr_addr);
+   disable_deferred_meminit();
} else {
/* Reserve the memory at the top of memory. */
size = get_fadump_area_size();
-- 
1.8.5.6

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

[PATCH 1/2] mm: Allow disabling deferred struct page initialisation

[Srikar Dronamraju]

Kernels compiled with CONFIG_DEFERRED_STRUCT_PAGE_INIT will initialise
only certain size memory per node. The certain size takes into account
the dentry and inode cache sizes. However such a kernel when booting a
secondary kernel will not be able to allocate the required amount of
memory to suffice for the dentry and inode caches. This results in
crashes like the below on large systems such as 32 TB systems.

Dentry cache hash table entries: 536870912 (order: 16, 4294967296 bytes)
vmalloc: allocation failure, allocated 4097114112 of 17179934720 bytes
swapper/0: page allocation failure: order:0, mode:0x2080020(GFP_ATOMIC)
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6-master+ #3
Call Trace:
[c108fb10] [c07fac88] dump_stack+0xb0/0xf0 (unreliable)
[c108fb50] [c0235264] warn_alloc_failed+0x114/0x160
[c108fbf0] [c0281484] __vmalloc_node_range+0x304/0x340
[c108fca0] [c028152c] __vmalloc+0x6c/0x90
[c108fd40] [c0aecfb0]
alloc_large_system_hash+0x1b8/0x2c0
[c108fe00] [c0af7240] inode_init+0x94/0xe4
[c108fe80] [c0af6fec] vfs_caches_init+0x8c/0x13c
[c108ff00] [c0ac4014] start_kernel+0x50c/0x578
[c108ff90] [c0008c6c] start_here_common+0x20/0xa8

Allow such kernels to disable deferred page struct initialisation.

Signed-off-by: Srikar Dronamraju 
---
 include/linux/mmzone.h |  2 +-
 mm/page_alloc.c| 20 
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index c60df92..1c55200 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1203,7 +1203,7 @@ unsigned long __init node_memmap_size_bytes(int, unsigned 
long, unsigned long);
 #else
 #define pfn_valid_within(pfn) (1)
 #endif
-
+void disable_deferred_meminit(void);
 #ifdef CONFIG_ARCH_HAS_HOLES_MEMORYMODEL
 /*
  * pfn_valid() is meant to be able to tell if a given PFN has valid memmap
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c1069ef..dc6ebac 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -301,6 +301,19 @@ static inline bool early_page_nid_uninitialised(unsigned 
long pfn, int nid)
 }
 
 /*
+ * Deferred struct page initialisation may not work on a multinode machine,
+ * if a significant amount of memory is reserved at early boot.  Allow apis
+ * that reserve significant memory to disable deferred struct page
+ * initialisation.
+ */
+static bool defer_init_disabled;
+
+void disable_deferred_meminit(void)
+{
+   defer_init_disabled = true;
+}
+
+/*
  * Returns false when the remaining initialisation should be deferred until
  * later in the boot cycle when it can be parallelised.
  */
@@ -313,6 +326,9 @@ static inline bool update_defer_init(pg_data_t *pgdat,
/* Always populate low zones for address-contrained allocations */
if (zone_end < pgdat_end_pfn(pgdat))
return true;
+
+   if (defer_init_disabled)
+   return true;
/*
 * Initialise at least 2G of a node but also take into account that
 * two large system hashes that can take up 1GB for 0.25TB/node.
@@ -350,6 +366,10 @@ static inline bool update_defer_init(pg_data_t *pgdat,
 {
return true;
 }
+void disable_deferred_meminit(void)
+{
+}
+
 #endif
 
 
-- 
1.8.5.6

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

[PATCH 0/0] Disable deferred struct page initialisation on Fadump

[Srikar Dronamraju]

Fadump kernel reserves large chunks of memory even before the pages are
initialised. This could mean memory that corresponds to several nodes might
fall in memblock reserved regions.

Kernels compiled with CONFIG_DEFERRED_STRUCT_PAGE_INIT will initialise
only certain size memory per node. The certain size takes into account
the dentry and inode cache sizes. However such a kernel when booting a
secondary kernel will not be able to allocate the required amount of
memory to suffice for the dentry and inode caches. This results in
crashes like the below on large systems such as 32 TB systems.

Dentry cache hash table entries: 536870912 (order: 16, 4294967296 bytes)
vmalloc: allocation failure, allocated 4097114112 of 17179934720 bytes
swapper/0: page allocation failure: order:0, mode:0x2080020(GFP_ATOMIC)
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6-master+ #3
Call Trace:
[c108fb10] [c07fac88] dump_stack+0xb0/0xf0 (unreliable)
[c108fb50] [c0235264] warn_alloc_failed+0x114/0x160
[c108fbf0] [c0281484] __vmalloc_node_range+0x304/0x340
[c108fca0] [c028152c] __vmalloc+0x6c/0x90
[c108fd40] [c0aecfb0]
alloc_large_system_hash+0x1b8/0x2c0
[c108fe00] [c0af7240] inode_init+0x94/0xe4
[c108fe80] [c0af6fec] vfs_caches_init+0x8c/0x13c
[c108ff00] [c0ac4014] start_kernel+0x50c/0x578
[c108ff90] [c0008c6c] start_here_common+0x20/0xa8

This can be solved by two approaches.
1. Disable deferred struct page initialisation on fadump.

2. Detect reserved nodes and allocate accordingly.
 - Detecting nodes whose memblocks are mostly reserved.
 - Allocating extra memory in other nodes in lieu of the nodes whose
   memory is reserved.

This patchset takes the first approach.

Srikar Dronamraju (2):
  mm: Allow disabling deferred struct page initialisation
  fadump: Disable deferred page struct initialisation

 arch/powerpc/kernel/fadump.c |  1 +
 include/linux/mmzone.h   |  2 +-
 mm/page_alloc.c  | 20 
 3 files changed, 22 insertions(+), 1 deletion(-)

-- 
1.8.5.6

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

Re: [PATCH v2] powerpc/32: fix csum_partial_copy_generic()

[Segher Boessenkool]

On Tue, Aug 02, 2016 at 10:07:05AM +0200, Christophe Leroy wrote:
> commit 7aef4136566b0 ("powerpc32: rewrite csum_partial_copy_generic()
> based on copy_tofrom_user()") introduced a bug when destination
> address is odd and initial csum is not null
> 
> In that (rare) case the initial csum value has to be rotated one byte
> as well as the resulting value is
> 
> This patch also fixes related comments
> 
> Fixes: 7aef4136566b0 ("powerpc32: rewrite csum_partial_copy_generic()
> based on copy_tofrom_user()")
> Cc: sta...@vger.kernel.org
> 
> Signed-off-by: Christophe Leroy 
> ---
>  v2: updated comments as suggested by Segher

This looks good to me now, thanks,


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

[PATCH v3 3/5] powerpc: pm: add EPU FSM configuration for deep sleep

[Chenhui Zhao]

In the last stage of deep sleep, software will trigger a Finite
State Machine (FSM) to control the hardware precedure, such as
board isolation, killing PLLs, removing power, and so on.

When the system is waked up by an interrupt, the FSM controls the
hardware to complete the early resume precedure.

This patch configure the EPU FSM preparing for deep sleep.

Signed-off-by: Chenhui Zhao 
---
 arch/powerpc/platforms/85xx/Makefile|   2 +-
 arch/powerpc/platforms/85xx/sleep_fsm.c | 267 
 arch/powerpc/platforms/85xx/sleep_fsm.h |  92 +++
 3 files changed, 360 insertions(+), 1 deletion(-)
 create mode 100644 arch/powerpc/platforms/85xx/sleep_fsm.c
 create mode 100644 arch/powerpc/platforms/85xx/sleep_fsm.h

diff --git a/arch/powerpc/platforms/85xx/Makefile 
b/arch/powerpc/platforms/85xx/Makefile
index fdae28b..87fb847 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -3,7 +3,7 @@
 #
 obj-$(CONFIG_SMP) += smp.o
 obj-$(CONFIG_FSL_PMC)+= mpc85xx_pm_ops.o
-obj-$(CONFIG_FSL_QORIQ_PM)   += qoriq_pm.o
+obj-$(CONFIG_FSL_QORIQ_PM)   += qoriq_pm.o sleep_fsm.o
 
 obj-y += common.o
 
diff --git a/arch/powerpc/platforms/85xx/sleep_fsm.c 
b/arch/powerpc/platforms/85xx/sleep_fsm.c
new file mode 100644
index 000..2b0c16b
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/sleep_fsm.c
@@ -0,0 +1,267 @@
+/*
+ * Freescale deep sleep FSM (finite-state machine) configuration
+ *
+ * Copyright 2016 Freescale Semiconductor Inc.
+ *
+ * Author: Hongbo Zhang 
+ * Chenhui Zhao 
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+
+#include "sleep_fsm.h"
+
+struct fsm_reg_vals {
+   u32 offset;
+   u32 value;
+};
+
+/*
+ * These values are from chip's reference manual. For example,
+ * the values for T1040 can be found in "8.4.3.8 Programming
+ * supporting deep sleep mode" of Chapter 8 "Run Control and
+ * Power Management (RCPM)".
+ * The default value is applied to T1040, T1042, T1024.
+ */
+struct fsm_reg_vals epu_default_val[] = {
+   /* EPGCR (Event Processor Global Control Register) */
+   {EPGCR, 0},
+   /* EPECR (Event Processor Event Control Registers) */
+   {EPECR0 + EPECR_STRIDE * 0, 0},
+   {EPECR0 + EPECR_STRIDE * 1, 0},
+   {EPECR0 + EPECR_STRIDE * 2, 0xF0004004},
+   {EPECR0 + EPECR_STRIDE * 3, 0x8084},
+   {EPECR0 + EPECR_STRIDE * 4, 0x2084},
+   {EPECR0 + EPECR_STRIDE * 5, 0x0804},
+   {EPECR0 + EPECR_STRIDE * 6, 0x8084},
+   {EPECR0 + EPECR_STRIDE * 7, 0x8084},
+   {EPECR0 + EPECR_STRIDE * 8, 0x6084},
+   {EPECR0 + EPECR_STRIDE * 9, 0x0884},
+   {EPECR0 + EPECR_STRIDE * 10, 0x4284},
+   {EPECR0 + EPECR_STRIDE * 11, 0x9084},
+   {EPECR0 + EPECR_STRIDE * 12, 0x8084},
+   {EPECR0 + EPECR_STRIDE * 13, 0x0884},
+   {EPECR0 + EPECR_STRIDE * 14, 0x0284},
+   {EPECR0 + EPECR_STRIDE * 15, 0x0004},
+   /*
+* EPEVTCR (Event Processor EVT Pin Control Registers)
+* SCU8 triger EVT2, and SCU11 triger EVT9
+*/
+   {EPEVTCR0 + EPEVTCR_STRIDE * 0, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 1, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 2, 0x8001},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 3, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 4, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 5, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 6, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 7, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 8, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 9, 0xB001},
+   /* EPCMPR (Event Processor Counter Compare Registers) */
+   {EPCMPR0 + EPCMPR_STRIDE * 0, 0},
+   {EPCMPR0 + EPCMPR_STRIDE * 1, 0},
+   {EPCMPR0 + EPCMPR_STRIDE * 2, 0x00FF},
+   {EPCMPR0 + EPCMPR_STRIDE * 3, 0},
+   {EPCMPR0 + EPCMPR_STRIDE * 4, 0x00FF},
+   {EPCMPR0 + EPCMPR_STRIDE * 5, 0x0020},
+   {EPCMPR0 + EPCMPR_STRIDE * 6, 0},
+   {EPCMPR0 + EPCMPR_STRIDE * 7, 0},
+   {EPCMPR0 + EPCMPR_STRIDE * 8, 0x00FF},
+   {EPCMPR0 + EPCMPR_STRIDE * 9, 0x00FF},
+   {EPCMPR0 + EPCMPR_STRIDE * 10, 0x00FF},
+   {EPCMPR0 + EPCMPR_STRIDE * 11, 0x00FF},
+   {EPCMPR0 + EPCMPR_STRIDE * 12, 0x00FF},
+   {EPCMPR0 + EPCMPR_STRIDE * 13, 0},
+   {EPCMPR0 + EPCMPR_STRIDE * 14, 0x00FF},
+   {EPCMPR0 + EPCMPR_STRIDE * 15, 0x00FF},
+   /* EPCCR (Event Processor Counter Control Registers) */
+   {EPCCR0 + EPCCR_STRIDE * 0, 0},
+   {EPCCR0 + EPCCR_STRIDE * 1, 0},
+   {EPCCR0 + EPCCR_STRIDE * 2, 0x9284},
+   {EPCCR0 + EPCCR_STRIDE * 3, 0},
+   {EPCCR0 + EPCCR_STRIDE * 4, 

[PATCH v3 1/5] powerpc/dts: add mcke-gpios for PM feature

[Chenhui Zhao]

Signed-off-by: Chenhui Zhao 
---
 Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 13 +
 arch/powerpc/boot/dts/fsl/t1040si-post.dtsi|  3 +++
 2 files changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt 
b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
index e284e4e..1d44a80 100644
--- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
@@ -21,6 +21,10 @@ Required properites:
* "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm
* "fsl,qoriq-rcpm-2.1": for chassis 2.1 rcpm
 
+Optional properites:
+  - mcke-gpios : The GPIO pin is used for keeping the MCKE signal of DDR 
modules
+low in the LPM35 state on some platforms, such as T1040.
+
 All references to "1.0" and "2.0" refer to the QorIQ chassis version to
 which the chip complies.
 Chassis VersionExample Chips
@@ -37,6 +41,15 @@ The RCPM node for T4240:
fsl,#rcpm-wakeup-cells = <2>;
};
 
+The RCPM node for T1040 (which supports LPM35 state):
+   rcpm: global-utilities@e2000 {
+   compatible = "fsl,t1040-rcpm", "fsl,qoriq-rcpm-2.1";
+   reg = <0xe2000 0x1000>;
+   fsl,#rcpm-wakeup-cells = <1>;
+   mcke-gpios = < 29 GPIO_ACTIVE_HIGH>
+   };
+
+
 * Freescale RCPM Wakeup Source Device Tree Bindings
 ---
 Required fsl,rcpm-wakeup property should be added to a device node if the 
device
diff --git a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
index 507649e..f66e7dd 100644
--- a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
@@ -33,6 +33,7 @@
  */
 
 #include 
+#include 
 
 _fbpr {
compatible = "fsl,bman-fbpr";
@@ -474,6 +475,8 @@
rcpm: global-utilities@e2000 {
compatible = "fsl,t1040-rcpm", "fsl,qoriq-rcpm-2.1";
reg = <0xe2000 0x1000>;
+   fsl,#rcpm-wakeup-cells = <1>;
+   mcke-gpios = < 29 GPIO_ACTIVE_HIGH>;
};
 
sfp: sfp@e8000 {
-- 
1.9.1

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

[PATCH v3 4/5] powerpc/pm: support deep sleep feature on T104x

[Chenhui Zhao]

T104x has deep sleep feature, which can switch off most parts of
the SoC when it is in deep sleep mode. This way, it becomes more
energy-efficient.

The DDR controller will also be powered off in deep sleep. Therefore,
the last stage (the latter part of fsl_dp_enter_low) will run without DDR
access. This piece of code and related TLBs are prefetched in advance.

Due to the different initialization code between 32-bit and 64-bit, they
have separate resume entry and precedure.

The feature supports 32-bit and 64-bit kernel mode.

Signed-off-by: Chenhui Zhao 
---
 arch/powerpc/include/asm/fsl_pm.h |  24 ++
 arch/powerpc/kernel/asm-offsets.c |  12 +
 arch/powerpc/kernel/fsl_booke_entry_mapping.S |  10 +
 arch/powerpc/kernel/head_64.S |   2 +-
 arch/powerpc/platforms/85xx/Makefile  |   1 +
 arch/powerpc/platforms/85xx/deepsleep.c   | 278 ++
 arch/powerpc/platforms/85xx/qoriq_pm.c|  25 ++
 arch/powerpc/platforms/85xx/t104x_deepsleep.S | 531 ++
 arch/powerpc/sysdev/fsl_rcpm.c|   8 +-
 9 files changed, 889 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/platforms/85xx/deepsleep.c
 create mode 100644 arch/powerpc/platforms/85xx/t104x_deepsleep.S

diff --git a/arch/powerpc/include/asm/fsl_pm.h 
b/arch/powerpc/include/asm/fsl_pm.h
index e05049b..48c2631 100644
--- a/arch/powerpc/include/asm/fsl_pm.h
+++ b/arch/powerpc/include/asm/fsl_pm.h
@@ -20,6 +20,7 @@
 
 #define PLAT_PM_SLEEP  20
 #define PLAT_PM_LPM20  30
+#define PLAT_PM_LPM35  40
 
 #define FSL_PM_SLEEP   (1 << 0)
 #define FSL_PM_DEEP_SLEEP  (1 << 1)
@@ -48,4 +49,27 @@ extern const struct fsl_pm_ops *qoriq_pm_ops;
 
 int __init fsl_rcpm_init(void);
 
+#ifdef CONFIG_FSL_QORIQ_PM
+int fsl_enter_deepsleep(void);
+int fsl_deepsleep_init(void);
+#else
+static inline int fsl_enter_deepsleep(void) { return -1; }
+static inline int fsl_deepsleep_init(void) { return -1; }
+#endif
+
+extern void fsl_dp_enter_low(void *priv);
+extern void fsl_booke_deep_sleep_resume(void);
+
+struct fsl_iomap {
+   void *ccsr_scfg_base;
+   void *ccsr_rcpm_base;
+   void *ccsr_ddr_base;
+   void *ccsr_gpio1_base;
+   void *ccsr_cpc_base;
+   void *dcsr_epu_base;
+   void *dcsr_npc_base;
+   void *dcsr_rcpm_base;
+   void *cpld_base;
+   void *fpga_base;
+};
 #endif /* __PPC_FSL_PM_H */
diff --git a/arch/powerpc/kernel/asm-offsets.c 
b/arch/powerpc/kernel/asm-offsets.c
index 9ea0955..cc488f9 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -68,6 +68,10 @@
 #include "../mm/mmu_decl.h"
 #endif
 
+#ifdef CONFIG_FSL_QORIQ_PM
+#include 
+#endif
+
 int main(void)
 {
DEFINE(THREAD, offsetof(struct task_struct, thread));
@@ -783,5 +787,13 @@ int main(void)
 
DEFINE(PPC_DBELL_SERVER, PPC_DBELL_SERVER);
 
+#ifdef CONFIG_FSL_QORIQ_PM
+   DEFINE(CCSR_CPC_BASE, offsetof(struct fsl_iomap, ccsr_cpc_base));
+   DEFINE(CCSR_GPIO1_BASE, offsetof(struct fsl_iomap, ccsr_gpio1_base));
+   DEFINE(CCSR_RCPM_BASE, offsetof(struct fsl_iomap, ccsr_rcpm_base));
+   DEFINE(CCSR_DDR_BASE, offsetof(struct fsl_iomap, ccsr_ddr_base));
+   DEFINE(CCSR_SCFG_BASE, offsetof(struct fsl_iomap, ccsr_scfg_base));
+   DEFINE(DCSR_EPU_BASE, offsetof(struct fsl_iomap, dcsr_epu_base));
+#endif
return 0;
 }
diff --git a/arch/powerpc/kernel/fsl_booke_entry_mapping.S 
b/arch/powerpc/kernel/fsl_booke_entry_mapping.S
index 83dd0f6..659b059 100644
--- a/arch/powerpc/kernel/fsl_booke_entry_mapping.S
+++ b/arch/powerpc/kernel/fsl_booke_entry_mapping.S
@@ -173,6 +173,10 @@ skpinv:addir6,r6,1 /* 
Increment */
lis r6,MAS2_VAL(PAGE_OFFSET, BOOK3E_PAGESZ_64M, M_IF_NEEDED)@h
ori r6,r6,MAS2_VAL(PAGE_OFFSET, BOOK3E_PAGESZ_64M, M_IF_NEEDED)@l
mtspr   SPRN_MAS2,r6
+#ifdef ENTRY_DEEPSLEEP_SETUP
+   LOAD_REG_IMMEDIATE(r8, MEMORY_START)
+   ori r8,r8,(MAS3_SX|MAS3_SW|MAS3_SR)
+#endif
mtspr   SPRN_MAS3,r8
tlbwe
 
@@ -215,12 +219,18 @@ next_tlb_setup:
#error You need to specify the mapping or not use this at all.
 #endif
 
+#ifdef ENTRY_DEEPSLEEP_SETUP
+   LOAD_REG_ADDR(r6, 2f)
+   mfmsr   r7
+   rlwinm  r7,r7,0,~(MSR_IS|MSR_DS)
+#else
lis r7,MSR_KERNEL@h
ori r7,r7,MSR_KERNEL@l
bl  1f  /* Find our address */
 1: mflrr9
rlwimi  r6,r9,0,20,31
addir6,r6,(2f - 1b)
+#endif
mtspr   SPRN_SRR0,r6
mtspr   SPRN_SRR1,r7
rfi /* start execution out of TLB1[0] entry 
*/
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 2d14774..21fa124 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -829,7 +829,7 @@ _GLOBAL(start_secondary_resume)
 /*
  * This subroutine clobbers r11 and r12

[PATCH v3 2/5] powerpc/85xx: support sleep feature on QorIQ SoCs with RCPM

[Chenhui Zhao]

In sleep mode, the clocks of e500 cores and unused IP blocks is
turned off. The IP blocks which are allowed to wake up the processor
are still running.

The sleep mode is equal to the Standby state in Linux. Use the
command to enter sleep mode:
  echo standby > /sys/power/state

Signed-off-by: Chenhui Zhao 
---
 arch/powerpc/Kconfig   |  3 +-
 arch/powerpc/include/asm/fsl_pm.h  |  2 +-
 arch/powerpc/platforms/85xx/Kconfig|  5 +++
 arch/powerpc/platforms/85xx/Makefile   |  1 +
 arch/powerpc/platforms/85xx/qoriq_pm.c | 59 ++
 arch/powerpc/platforms/86xx/Kconfig|  1 +
 arch/powerpc/sysdev/fsl_rcpm.c | 20 
 7 files changed, 74 insertions(+), 17 deletions(-)
 create mode 100644 arch/powerpc/platforms/85xx/qoriq_pm.c

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 0a9d439..078d08c 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -242,7 +242,7 @@ config ARCH_HIBERNATION_POSSIBLE
 config ARCH_SUSPEND_POSSIBLE
def_bool y
depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx || \
-  (PPC_85xx && !PPC_E500MC) || PPC_86xx || PPC_PSERIES \
+  FSL_SOC_BOOKE || PPC_86xx || PPC_PSERIES \
   || 44x || 40x
 
 config PPC_DCR_NATIVE
@@ -778,7 +778,6 @@ config FSL_PCI
 
 config FSL_PMC
bool
-   default y
depends on SUSPEND && (PPC_85xx || PPC_86xx)
help
  Freescale MPC85xx/MPC86xx power management controller support
diff --git a/arch/powerpc/include/asm/fsl_pm.h 
b/arch/powerpc/include/asm/fsl_pm.h
index 47df55e..e05049b 100644
--- a/arch/powerpc/include/asm/fsl_pm.h
+++ b/arch/powerpc/include/asm/fsl_pm.h
@@ -34,7 +34,7 @@ struct fsl_pm_ops {
void (*cpu_exit_state)(int cpu, int state);
void (*cpu_up_prepare)(int cpu);
void (*cpu_die)(int cpu);
-   int (*plat_enter_sleep)(void);
+   int (*plat_enter_sleep)(int state);
void (*freeze_time_base)(bool freeze);
 
/* keep the power of IP blocks during sleep/deep sleep */
diff --git a/arch/powerpc/platforms/85xx/Kconfig 
b/arch/powerpc/platforms/85xx/Kconfig
index e626461..dff2ea6 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -9,6 +9,8 @@ menuconfig FSL_SOC_BOOKE
select SERIAL_8250_EXTENDED if SERIAL_8250
select SERIAL_8250_SHARE_IRQ if SERIAL_8250
select FSL_CORENET_RCPM if PPC_E500MC
+   select FSL_QORIQ_PM if SUSPEND && PPC_E500MC
+   select FSL_PMC if SUSPEND && !PPC_E500MC
default y
 
 if FSL_SOC_BOOKE
@@ -289,3 +291,6 @@ endif # FSL_SOC_BOOKE
 
 config TQM85xx
bool
+
+config FSL_QORIQ_PM
+   bool
diff --git a/arch/powerpc/platforms/85xx/Makefile 
b/arch/powerpc/platforms/85xx/Makefile
index 7bc86da..fdae28b 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -3,6 +3,7 @@
 #
 obj-$(CONFIG_SMP) += smp.o
 obj-$(CONFIG_FSL_PMC)+= mpc85xx_pm_ops.o
+obj-$(CONFIG_FSL_QORIQ_PM)   += qoriq_pm.o
 
 obj-y += common.o
 
diff --git a/arch/powerpc/platforms/85xx/qoriq_pm.c 
b/arch/powerpc/platforms/85xx/qoriq_pm.c
new file mode 100644
index 000..c97ef8f
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/qoriq_pm.c
@@ -0,0 +1,59 @@
+/*
+ * Support Power Management feature
+ *
+ * Copyright 2016 Freescale Semiconductor Inc.
+ *
+ * Author: Chenhui Zhao 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under  the terms of the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+
+static unsigned int pm_modes;
+
+static int qoriq_suspend_enter(suspend_state_t state)
+{
+   int ret = 0;
+
+   switch (state) {
+   case PM_SUSPEND_STANDBY:
+   ret = qoriq_pm_ops->plat_enter_sleep(FSL_PM_SLEEP);
+   break;
+   default:
+   ret = -EINVAL;
+   }
+
+   return ret;
+}
+
+static int qoriq_suspend_valid(suspend_state_t state)
+{
+
+   if (state == PM_SUSPEND_STANDBY && (pm_modes & FSL_PM_SLEEP))
+   return 1;
+
+   return 0;
+}
+
+static const struct platform_suspend_ops qoriq_suspend_ops = {
+   .valid = qoriq_suspend_valid,
+   .enter = qoriq_suspend_enter,
+};
+
+static int __init qoriq_suspend_init(void)
+{
+   /* support sleep by default */
+   pm_modes |= FSL_PM_SLEEP;
+
+   suspend_set_ops(_suspend_ops);
+   return 0;
+}
+arch_initcall(qoriq_suspend_init);
diff --git a/arch/powerpc/platforms/86xx/Kconfig 
b/arch/powerpc/platforms/86xx/Kconfig
index 1afd1e4..09638e0 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -5,6 +5,7 @@ menuconfig PPC_86xx
select FSL_SOC
select ALTIVEC

[PATCH v3 0/5] powerpc/pm: QorIQ deep sleep

[Chenhui Zhao]

Changes for v3:
* add mcke-gpios in dts to specify the GPIO pin which works as MCKE signal

Changes for v2:
* Ioremap every dts node used in the patches.
* Check the board compatible string to see if the board supports deep sleep.
* Can not reserve the first page of DDR memory, because PPC64 doesn't support
  changing the kernel base address. So still save and restore the first 128 
bytes
  of DDR memory.
* Still save and restoer CCSR registers in kernel, because bootloader doesn't
  know what register values to restore
* Changed copyright and email address from freescale to NXP

Please refer to the version 1:
[1/4] powerpc/85xx: support sleep feature on QorIQ SoCs with RCPM
http://patchwork.ozlabs.org/patch/502549/

[2/4] powerpc: get the physical base address of DCSR
http://patchwork.ozlabs.org/patch/502551/
It is removed.

[3/4] powerpc: pm: add EPU FSM configuration for deep sleep
http://patchwork.ozlabs.org/patch/502548/

[4/4] powerpc: pm: support deep sleep feature on T104x
http://patchwork.ozlabs.org/patch/502550/


Chenhui Zhao (5):
  powerpc/dts: add mcke-gpios for PM feature
  powerpc/85xx: support sleep feature on QorIQ SoCs with RCPM
  powerpc: pm: add EPU FSM configuration for deep sleep
  powerpc/pm: support deep sleep feature on T104x
  powerpc/pm: save and restore registers during deep sleep

 Documentation/devicetree/bindings/soc/fsl/rcpm.txt |  13 +
 arch/powerpc/Kconfig   |   3 +-
 arch/powerpc/boot/dts/fsl/t1040si-post.dtsi|   3 +
 arch/powerpc/include/asm/fsl_pm.h  |  28 +-
 arch/powerpc/kernel/asm-offsets.c  |  12 +
 arch/powerpc/kernel/fsl_booke_entry_mapping.S  |  10 +
 arch/powerpc/kernel/head_64.S  |   2 +-
 arch/powerpc/platforms/85xx/Kconfig|   5 +
 arch/powerpc/platforms/85xx/Makefile   |   2 +
 arch/powerpc/platforms/85xx/deepsleep.c| 384 +++
 arch/powerpc/platforms/85xx/qoriq_pm.c |  84 
 arch/powerpc/platforms/85xx/sleep_fsm.c| 267 +++
 arch/powerpc/platforms/85xx/sleep_fsm.h|  92 
 arch/powerpc/platforms/85xx/t104x_deepsleep.S  | 531 +
 arch/powerpc/platforms/86xx/Kconfig|   1 +
 arch/powerpc/sysdev/fsl_rcpm.c |  28 +-
 16 files changed, 1446 insertions(+), 19 deletions(-)
 create mode 100644 arch/powerpc/platforms/85xx/deepsleep.c
 create mode 100644 arch/powerpc/platforms/85xx/qoriq_pm.c
 create mode 100644 arch/powerpc/platforms/85xx/sleep_fsm.c
 create mode 100644 arch/powerpc/platforms/85xx/sleep_fsm.h
 create mode 100644 arch/powerpc/platforms/85xx/t104x_deepsleep.S

-- 
1.9.1

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

[PATCH v2] powerpc/32: fix csum_partial_copy_generic()

[Christophe Leroy]

commit 7aef4136566b0 ("powerpc32: rewrite csum_partial_copy_generic()
based on copy_tofrom_user()") introduced a bug when destination
address is odd and initial csum is not null

In that (rare) case the initial csum value has to be rotated one byte
as well as the resulting value is

This patch also fixes related comments

Fixes: 7aef4136566b0 ("powerpc32: rewrite csum_partial_copy_generic()
based on copy_tofrom_user()")
Cc: sta...@vger.kernel.org

Signed-off-by: Christophe Leroy 
---
 v2: updated comments as suggested by Segher

 arch/powerpc/lib/checksum_32.S | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/lib/checksum_32.S b/arch/powerpc/lib/checksum_32.S
index d90870a..0a57fe6 100644
--- a/arch/powerpc/lib/checksum_32.S
+++ b/arch/powerpc/lib/checksum_32.S
@@ -127,8 +127,9 @@ _GLOBAL(csum_partial_copy_generic)
stw r7,12(r1)
stw r8,8(r1)
 
-   andi.   r0,r4,1 /* is destination address even ? */
-   cmplwi  cr7,r0,0
+   rlwinm  r0,r4,3,0x8
+   rlwnm   r6,r6,r0,0,31   /* odd destination address: rotate one byte */
+   cmplwi  cr7,r0,0/* is destination address even ? */
addic   r12,r6,0
addir6,r4,-4
neg r0,r4
@@ -237,7 +238,7 @@ _GLOBAL(csum_partial_copy_generic)
 66:addze   r3,r12
addir1,r1,16
beqlr+  cr7
-   rlwinm  r3,r3,8,0,31/* swap bytes for odd destination */
+   rlwinm  r3,r3,8,0,31/* odd destination address: rotate one byte */
blr
 
 /* read fault */
-- 
2.1.0

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

[RFC] [PATCH 3/3] powernv/oppanel: Update op_panel module to utilise opal_oppanel interface

[Suraj Jitindar Singh]

The powernv_op_panel kernel module is used to expose the operator panel
display present on IBM PowerNV machines with FSPs through the char device
/dev/op_panel.

The new interface opal_oppanel which has been added to allow access to the
operator panel display from within the kernel duplicates a lot of the
module code. Thus update the powernv_op_panel kernel module to access the
display through the opal_oppanel interface.

Signed-off-by: Suraj Jitindar Singh 
---
 drivers/char/powernv-op-panel.c | 153 ++--
 1 file changed, 51 insertions(+), 102 deletions(-)

diff --git a/drivers/char/powernv-op-panel.c b/drivers/char/powernv-op-panel.c
index a45dabc..2d22cc4 100644
--- a/drivers/char/powernv-op-panel.c
+++ b/drivers/char/powernv-op-panel.c
@@ -17,7 +17,7 @@
 #include 
 #include 
 #include 
-
+#include 
 #include 
 
 /*
@@ -28,106 +28,87 @@
  * operator panel.
  */
 
-static DEFINE_MUTEX(oppanel_mutex);
+static DEFINE_MUTEX(oppanel_driver_mutex);
 
-static u32 num_lines, oppanel_size;
-static oppanel_line_t  *oppanel_lines;
-static char*oppanel_data;
-
-static loff_t oppanel_llseek(struct file *filp, loff_t offset, int whence)
-{
-   return fixed_size_llseek(filp, offset, whence, oppanel_size);
-}
+static u32 buf_size;
+char *oppanel_buf;
 
 static ssize_t oppanel_read(struct file *filp, char __user *userbuf, size_t 
len,
loff_t *f_pos)
 {
-   return simple_read_from_buffer(userbuf, len, f_pos, oppanel_data,
-   oppanel_size);
-}
+   ssize_t ret;
 
-static int __op_panel_update_display(void)
-{
-   struct opal_msg msg;
-   int rc, token;
-
-   token = opal_async_get_token_interruptible();
-   if (token < 0) {
-   if (token != -ERESTARTSYS)
-   pr_debug("Couldn't get OPAL async token [token=%d]\n",
-   token);
-   return token;
-   }
+   if (*f_pos < 0)
+   return -EINVAL;
+   if (*f_pos >= (buf_size - 1) || !len)
+   return 0;
+   if (len > (buf_size - 1 - *f_pos))
+   len = buf_size - 1 - *f_pos;
 
-   rc = opal_write_oppanel_async(token, oppanel_lines, num_lines);
-   switch (rc) {
-   case OPAL_ASYNC_COMPLETION:
-   rc = opal_async_wait_response(token, );
-   if (rc) {
-   pr_debug("Failed to wait for async response [rc=%d]\n",
-   rc);
-   break;
-   }
-   rc = opal_get_async_rc(msg);
-   if (rc != OPAL_SUCCESS) {
-   pr_debug("OPAL async call returned failed [rc=%d]\n",
-   rc);
-   break;
-   }
-   case OPAL_SUCCESS:
-   break;
-   default:
-   pr_debug("OPAL write op-panel call failed [rc=%d]\n", rc);
-   }
+   opal_oppanel_read(oppanel_buf);
+   ret = len - copy_to_user(userbuf, _buf[*f_pos], len);
 
-   opal_async_release_token(token);
-   return rc;
+   /* Nothing was copied */
+   if (!ret)
+   return -EFAULT;
+
+   *f_pos += ret;
+
+   return ret;
 }
 
 static ssize_t oppanel_write(struct file *filp, const char __user *userbuf,
 size_t len, loff_t *f_pos)
 {
-   loff_t f_pos_prev = *f_pos;
ssize_t ret;
int rc;
 
-   if (!*f_pos)
-   memset(oppanel_data, ' ', oppanel_size);
-   else if (*f_pos >= oppanel_size)
-   return -EFBIG;
+   if (*f_pos < 0)
+   return -EINVAL;
+   if (!len)
+   return 0;
+   if (len >= buf_size)
+   len = buf_size - 1;
 
-   ret = simple_write_to_buffer(oppanel_data, oppanel_size, f_pos, userbuf,
-   len);
+   ret = len - copy_from_user(oppanel_buf, userbuf, len);
+   /* Something was copied */
if (ret > 0) {
-   rc = __op_panel_update_display();
+   /* Add null terminator */
+   oppanel_buf[ret] = '\0';
+   rc = opal_oppanel_write(oppanel_buf);
if (rc != OPAL_SUCCESS) {
pr_err_ratelimited("OPAL call failed to write to op 
panel display [rc=%d]\n",
rc);
-   *f_pos = f_pos_prev;
-   return -EIO;
+   return rc;
}
-   }
+   /* Nothing was copied */
+   } else if (!ret)
+   return -EFAULT;
+
+   *f_pos += ret;
+
return ret;
 }
 
 static int oppanel_open(struct inode *inode, struct file *filp)
 {
-   if (!mutex_trylock(_mutex)) {
+   if (!mutex_trylock(_driver_mutex)) {
pr_debug("Device Busy\n");
return -EBUSY;
}
+   nonseekable_open(inode, filp);

[RFC] [PATCH 2/3] powernv/setup: Initialise opal_oppanel and display information on boot

[Suraj Jitindar Singh]

Now that we have the ability to access the operator panel display from
within the kernel print out some platform information on boot.

Update the opal initialisation function to call the init function for the
new oppanel interface, this also removes the need to explicitly create the
platform device as this is now handled in the oppanel init function.

Now that we are able to access the operator panel display from the kernel
update the powernv platform progress function to write to the display.
Add a function to print some platform information to the display on
boot.

Signed-off-by: Suraj Jitindar Singh 
---
 arch/powerpc/platforms/powernv/opal.c  |  8 +---
 arch/powerpc/platforms/powernv/setup.c | 27 +++
 2 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index 228751a..62ea5e5 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -705,6 +705,11 @@ static int __init opal_init(void)
/* Initialise OPAL asynchronous completion interface */
opal_async_comp_init();
 
+#if defined(CONFIG_POWERNV_OP_PANEL) || defined(CONFIG_POWERNV_OP_PANEL_MODULE)
+   /* Initialise OPAL oppanel interface */
+   opal_oppanel_init();
+#endif /* CONFIG_POWERNV_OP_PANEL */
+
/* Initialise OPAL sensor interface */
opal_sensor_init();
 
@@ -751,9 +756,6 @@ 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();
 
diff --git a/arch/powerpc/platforms/powernv/setup.c 
b/arch/powerpc/platforms/powernv/setup.c
index ee6430b..0f0e557 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -58,6 +59,29 @@ static void __init pnv_setup_arch(void)
/* XXX PMCS */
 }
 
+static int __init pnv_late_init(void)
+{
+#if defined(CONFIG_POWERNV_OP_PANEL) || defined(CONFIG_POWERNV_OP_PANEL_MODULE)
+   char msg[17] = {'\0'};
+#endif /* CONFIG_POWERNV_OP_PANEL */
+   /* Manually leave the kernel version on the panel */
+#ifdef __BIG_ENDIAN__
+   ppc_md.progress("Linux ppc64\n", 0);
+#else
+   ppc_md.progress("Linux ppc64le\n", 0);
+#endif
+#if defined(CONFIG_POWERNV_OP_PANEL) || defined(CONFIG_POWERNV_OP_PANEL_MODULE)
+   /* Limit what we print to 16 chars so the previous line remains */
+   memcpy(msg, init_utsname()->release, 16);
+   ppc_md.progress(msg, 0);
+#else
+   ppc_md.progress(init_utsname()->release, 0);
+#endif /* CONFIG_POWERNV_OP_PANEL */
+
+   return 0;
+}
+machine_late_initcall(powernv, pnv_late_init);
+
 static void __init pnv_init_early(void)
 {
/*
@@ -159,6 +183,9 @@ static void __noreturn pnv_halt(void)
 
 static void pnv_progress(char *s, unsigned short hex)
 {
+#if defined(CONFIG_POWERNV_OP_PANEL) || defined(CONFIG_POWERNV_OP_PANEL_MODULE)
+   opal_oppanel_write(s);
+#endif /* CONFIG_POWERNV_OP_PANEL */
 }
 
 static void pnv_shutdown(void)
-- 
2.5.5

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

[RFC] [PATCH 1/3] powernv/opal: Introduce new opal_oppanel interface to expose the op_panel

[Suraj Jitindar Singh]

IBM PowerNV machines with FSPs have an operator panel with a LCD display.
Currently this oppanel display can be accessed through the
powernv_op_panel kernel module. We would like to be able to access this
display easily from other places in the Kernel.

Add a new interface through which the operator panel display can be
accessed from within the kernel. The function opal_oppanel_write acts like
a print function and will respect newline and carriage return characters
while trying to print the input to the display. The function
opal_oppanel_read will provide access to what is currently in the display
buffer.

Signed-off-by: Suraj Jitindar Singh 
---
 MAINTAINERS   |   1 +
 arch/powerpc/include/asm/opal.h   |   7 +
 arch/powerpc/platforms/powernv/Kconfig|   4 +
 arch/powerpc/platforms/powernv/Makefile   |   1 +
 arch/powerpc/platforms/powernv/opal-oppanel.c | 292 ++
 drivers/char/Kconfig  |   1 +
 6 files changed, 306 insertions(+)
 create mode 100644 arch/powerpc/platforms/powernv/opal-oppanel.c

diff --git a/MAINTAINERS b/MAINTAINERS
index b1703ca..95841e1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9218,6 +9218,7 @@ M:Suraj Jitindar Singh 
 L: linuxppc-dev@lists.ozlabs.org
 S: Maintained
 F: drivers/char/powernv-op-panel.c
+F: arch/powerpc/platforms/powernv/opal-oppanel.c
 
 PNP SUPPORT
 M: "Rafael J. Wysocki" 
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index ea9e7f4..2802e1f 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -286,6 +286,13 @@ static inline int opal_get_async_rc(struct opal_msg msg)
return be64_to_cpu(msg.params[1]);
 }
 
+#if defined(CONFIG_POWERNV_OP_PANEL) || defined(CONFIG_POWERNV_OP_PANEL_MODULE)
+extern int opal_oppanel_write(char *msg);
+extern void opal_oppanel_read(char *msg);
+extern void opal_oppanel_get_size(u32 *size);
+extern int opal_oppanel_init(void);
+#endif /* CONFIG_POWERNV_OP_PANEL */
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* _ASM_POWERPC_OPAL_H */
diff --git a/arch/powerpc/platforms/powernv/Kconfig 
b/arch/powerpc/platforms/powernv/Kconfig
index 604190c..df325f7 100644
--- a/arch/powerpc/platforms/powernv/Kconfig
+++ b/arch/powerpc/platforms/powernv/Kconfig
@@ -26,3 +26,7 @@ config OPAL_PRD
help
  This enables the opal-prd driver, a facility to run processor
  recovery diagnostics on OpenPower machines
+
+config POWERNV_OP_PANEL_BASE
+   bool
+   default n
diff --git a/arch/powerpc/platforms/powernv/Makefile 
b/arch/powerpc/platforms/powernv/Makefile
index cd9711e..0565351 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_PPC_SCOM)+= opal-xscom.o
 obj-$(CONFIG_MEMORY_FAILURE)   += opal-memory-errors.o
 obj-$(CONFIG_TRACEPOINTS)  += opal-tracepoints.o
 obj-$(CONFIG_OPAL_PRD) += opal-prd.o
+obj-$(CONFIG_POWERNV_OP_PANEL_BASE)+= opal-oppanel.o
diff --git a/arch/powerpc/platforms/powernv/opal-oppanel.c 
b/arch/powerpc/platforms/powernv/opal-oppanel.c
new file mode 100644
index 000..1ddf414
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/opal-oppanel.c
@@ -0,0 +1,292 @@
+/*
+ * OPAL PowerNV Operator Panel Display Code
+ *
+ * Copyright 2016, Suraj Jitindar Singh, IBM Corporation.
+ */
+
+#define pr_fmt(fmt) "%s: " fmt, __func__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+enum {
+   MODE_LF,
+   MODE_CR,
+   MODE_NC,
+};
+
+static DEFINE_MUTEX(opal_oppanel_mutex);
+
+static u32 num_lines, line_len, buf_len;
+static char*buf;
+static oppanel_line_t  *lines;
+static int cursor;
+
+static inline int last_line_index(void)
+{
+   return buf_len - line_len;
+}
+
+/*
+ * oppanel_write_to_display
+ * Write the contents of buf to the physical operator panel LCD display
+ *
+ * @return:OPAL_SUCCESS on successful write
+ * else write failed
+ */
+static int oppanel_write_to_display(void)
+{
+   struct opal_msg msg;
+   int rc, token;
+
+   token = opal_async_get_token_interruptible();
+   if (token < 0) {
+   if (token != -ERESTARTSYS)
+   pr_debug("Couldn't get OPAL async token [token=%d]\n",
+   token);
+   return token;
+   }
+
+   rc = opal_write_oppanel_async(token, lines, num_lines);
+   switch (rc) {
+   case OPAL_ASYNC_COMPLETION:
+   rc = opal_async_wait_response(token, );
+   if (rc) {
+   pr_debug("Failed to wait for async response [rc=%d]\n",
+   rc);
+   break;
+   }
+   rc = 

Re: [v4] Fix to avoid IS_ERR_VALUE and IS_ERR abuses on 64bit systems.

[Arnd Bergmann]

On Monday, August 1, 2016 4:55:43 PM CEST Scott Wood wrote:
> On 08/01/2016 02:02 AM, Arnd Bergmann wrote:

> >> diff --git a/include/linux/err.h b/include/linux/err.h
> >> index 1e35588..c2a2789 100644
> >> --- a/include/linux/err.h
> >> +++ b/include/linux/err.h
> >> @@ -18,7 +18,17 @@
> >>  
> >>  #ifndef __ASSEMBLY__
> >>  
> >> -#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned 
> >> long)-MAX_ERRNO)
> >> +#define IS_ERR_VALUE(x) unlikely(is_error_check(x))
> >> +
> >> +static inline int is_error_check(unsigned long error)
> > 
> > Please leave the existing macro alone. I think you were looking for
> > something specific to the return code of qe_muram_alloc() function,
> > so please add a helper in that subsystem if you need it, not in
> > the generic header files.
> 
> qe_muram_alloc (a.k.a. cpm_muram_alloc) returns unsigned long.  The
> problem is certain callers that store the return value in a u32.  Why
> not just fix those callers to store it in unsigned long (at least until
> error checking is done)?
> 

Yes, that would also address another problem with code like

 kfree((void *)ugeth->tx_bd_ring_offset[i]);

which is not 64-bit safe when tx_bd_ring_offset is a 32-bit value
that also holds the return value of qe_muram_alloc.

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