Re: [PATCHv2 1/2] arch: Move CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX to be common

[Pavel Machek]

On Mon 2017-02-06 10:47:45, Laura Abbott wrote:
> On 02/03/2017 01:08 PM, Kees Cook wrote:
> > On Fri, Feb 3, 2017 at 12:29 PM, Russell King - ARM Linux
> >  wrote:
> >> On Fri, Feb 03, 2017 at 11:45:56AM -0800, Kees Cook wrote:
> >>> On Fri, Feb 3, 2017 at 9:52 AM, Laura Abbott  wrote:
>  diff --git a/arch/Kconfig b/arch/Kconfig
>  index 99839c2..22ee01e 100644
>  --- a/arch/Kconfig
>  +++ b/arch/Kconfig
>  @@ -781,4 +781,32 @@ config VMAP_STACK
>    the stack to map directly to the KASAN shadow map using a 
>  formula
>    that is incorrect if the stack is in vmalloc space.
> 
>  +config ARCH_NO_STRICT_RWX_DEFAULTS
>  +   def_bool n
>  +
>  +config ARCH_HAS_STRICT_KERNEL_RWX
>  +   def_bool n
>  +
>  +config DEBUG_RODATA
>  +   def_bool y if !ARCH_NO_STRICT_RWX_DEFAULTS
>  +   prompt "Make kernel text and rodata read-only" if 
>  ARCH_NO_STRICT_RWX_DEFAULTS
> >>>
> >>> Ah! Yes, perfect. I totally forgot about using conditional "prompt"
> >>> lines. Nice!
> >>
> >> It's no different from the more usual:
> >>
> >> bool "Make kernel text and rodata read-only" if 
> >> ARCH_NO_STRICT_RWX_DEFAULTS
> >> default y if !ARCH_NO_STRICT_RWX_DEFAULTS
> >> depends on ARCH_HAS_STRICT_KERNEL_RWX
> >>
> >> But... I really don't like this - way too many negations and negatives
> >> which make it difficult to figure out what's going on here.
> >>
> >> The situation we have today is:
> >>
> >> -config DEBUG_RODATA
> >> -   bool "Make kernel text and rodata read-only"
> >> -   depends on MMU && !XIP_KERNEL
> >> -   default y if CPU_V7
> >>
> >> which is "allow the user to select DEBUG_RODATA if building a MMU non-XIP
> >> kernel", suggesting that the user turns it on for ARMv7 CPUs.
> >>
> >> That changes with this and the above:
> >>
> >> +   select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
> >> +   select ARCH_HAS_STRICT_MODULE_RWX if MMU
> >> +   select ARCH_NO_STRICT_RWX_DEFAULTS if !CPU_V7
> >>
> >> This means that ARCH_HAS_STRICT_KERNEL_RWX is set for a MMU non-XIP
> >> kernel, which carries the same pre-condition for DEBUG_RODATA - no
> >> problem there.
> >>
> >> However, ARCH_NO_STRICT_RWX_DEFAULTS is set for non-ARMv7 CPUs, which
> >> means the "Make kernel text and rodata read-only" prompt _is_ provided
> >> for those.  However, for all ARMv7 systems, we go from "suggesting that
> >> the user enables the option" to "you don't have a choice, you get this
> >> whether you want it or not."
> >>
> >> I'd prefer to keep it off for my development systems, where I don't
> >> care about kernel security.  If we don't wish to do that as a general
> >> rule, can we make it dependent on EMBEDDED?
> >>
> >> Given that on ARM it can add up to 4MB to the kernel image - there
> >> _will_ be about 1MB before the .text section, the padding on between
> >> __modver and __ex_table which for me is around 626k, the padding
> >> between .notes and the init sections start with .vectors (the space
> >> between __ex_table and end of .notes is only 4124, which gets padded
> >> up to 1MB) and lastly the padding between the .init section and the
> >> data section (for me around 593k).  This all adds up to an increase
> >> in kernel image size of 3.2MB on 14.2MB - an increase of 22%.
> >>
> >> So no, I'm really not happy with that.
> > 
> > Ah yeah, good point. We have three cases: unsupported, mandatory,
> > optional, but we have the case of setting the default for the optional
> > case. Maybe something like this?
> > 
> > config STRICT_KERNEL_RWX
> >   bool "Make kernel text and rodata read-only" if ARCH_OPTIONAL_KERNEL_RWX
> >   depends on ARCH_HAS_STRICT_KERNEL_RWX
> >   default ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
> > 
> > unsupported:
> > !ARCH_HAS_STRICT_KERNEL_RWX
> > 
> > mandatory:
> > ARCH_HAS_STRICT_KERNEL_RWX
> > !ARCH_OPTIONAL_KERNEL_RWX
> > 
> > optional:
> > ARCH_HAS_STRICT_KERNEL_RWX
> > ARCH_OPTIONAL_KERNEL_RWX
> > with default controlled by ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
> > 
> > Then arm is:
> >   select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
> >   select ARCH_HAS_STRICT_MODULE_RWX if MMU
> >   select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
> >   select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT if CPU_V7
> > 
> > x86 and arm64 are:
> >   select ARCH_HAS_STRICT_KERNEL_RWX
> >   select ARCH_HAS_STRICT_MODULE_RWX
> > 
> > ?
> > 
> > -Kees
> > 
> 
> Yes, that looks good. I wanted it to be mandatory to avoid the
> mindset of "optional means we don't need it" but I see there
> are some cases where it's better to turn it off. I'll see if
> I can emphasize this properly in the help text ("Say Y here
> unless you love security exploits running in production")

What about fixing the memory wastage, instead? If you want something
almost-always-on, it should not waste megabytes of memory.

And BTW it is help text, not 

Re: [PATCHv3 1/2] arch: Move CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX to be common

[Ingo Molnar]

* Laura Abbott  wrote:

> 
> There are multiple architectures that support CONFIG_DEBUG_RODATA and
> CONFIG_SET_MODULE_RONX. These options also now have the ability to be
> turned off at runtime. Move these to an architecture independent
> location and make these options def_bool y for almost all of those
> arches.
> 
> Signed-off-by: Laura Abbott 
> ---
> v3: Make these configs selectable for arm. Include some documentation about
> how the setup of the optional Kconfigs work as well. Stop spelling 'kenrel'
> in prompt text.
> ---
>  Documentation/security/self-protection.txt |  6 ++
>  arch/Kconfig   | 34 
> ++
>  arch/arm/Kconfig   |  4 
>  arch/arm/Kconfig.debug | 11 --
>  arch/arm/mm/Kconfig| 12 ---
>  arch/arm64/Kconfig |  5 ++---
>  arch/arm64/Kconfig.debug   | 11 --
>  arch/parisc/Kconfig|  1 +
>  arch/parisc/Kconfig.debug  | 11 --
>  arch/s390/Kconfig  |  5 ++---
>  arch/s390/Kconfig.debug|  3 ---
>  arch/x86/Kconfig   |  5 ++---
>  arch/x86/Kconfig.debug | 11 --
>  13 files changed, 51 insertions(+), 68 deletions(-)

Acked-by: Ingo Molnar 

Thanks,

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

Re: [PATCH 1/2] kconfig/mconf: add jumping tip in title of search result textbox

[Du, Changbin]

On Mon, Feb 06, 2017 at 02:00:51PM +0200, Jani Nikula wrote:
> On Mon, 06 Feb 2017, changbin...@intel.com wrote:
> > From: Changbin Du 
> >
> > Prompt user how to quickly jump to the item he/she is interested in.
> 
> :o
> 
> All these years. I... I didn't know. Thanks!
>
aha, me too! You know, back to the top menu then look into step by
step...

> > Signed-off-by: Changbin Du 
> > ---
> >  scripts/kconfig/mconf.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
> > index 315ce2c..23d5681 100644
> > --- a/scripts/kconfig/mconf.c
> > +++ b/scripts/kconfig/mconf.c
> > @@ -443,10 +443,10 @@ static void search_conf(void)
> >  
> > res = get_relations_str(sym_arr, );
> > set_subtitle();
> > -   dres = show_textbox_ext(_("Search Results"), (char *)
> > -   str_get(), 0, 0, keys, ,
> > -   , _text, (void *)
> > -   );
> > +   dres = show_textbox_ext(
> > +   _("Search Results (type the number to jump)"),
> > +   (char *)str_get(), 0, 0, keys, ,
> > +   , _text, (void *));
> 
> It would be even better and discoverable if this could be turned into a
> dialog menu, so that you could navigate the search results using arrow
> keys and hit enter to choose. But this is already an improvement.
> 
Yes, that will have a better experience. :)

> > again = false;
> > for (i = 0; i < JUMP_NB && keys[i]; i++)
> > if (dres == keys[i]) {
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
Thanks,
Changbin


signature.asc
Description: PGP signature

Re: [PATCH 2/2] Documentation/kconfig: add search jump feature description

[Du, Changbin]

On Mon, Feb 06, 2017 at 07:42:11AM -0700, Jim Davis wrote:
> On Mon, Feb 6, 2017 at 12:46 AM,   wrote:
> > From: Changbin Du 
> >
> > Kernel menuconfig support direct jumping function from the search
> > result. This is a very convenient feature but not documented. So
> > add a short description to the kconfig documentation to let more
> > developer know it.
> >
> > Signed-off-by: Changbin Du 
> > ---
> >  Documentation/kbuild/kconfig.txt | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/Documentation/kbuild/kconfig.txt 
> > b/Documentation/kbuild/kconfig.txt
> > index bbc99c0..9916318 100644
> > --- a/Documentation/kbuild/kconfig.txt
> > +++ b/Documentation/kbuild/kconfig.txt
> > @@ -178,6 +178,10 @@ Searching in menuconfig:
> > first (and in alphabetical order), then come all other symbols,
> > sorted in alphabetical order.
> >
> > +   In the search result textbox, each symbol has a jump number on
> > +   left side if the symbol is jumpable. You can type the nubmer
> 
> number  ("jumpable" reads a bit oddly, but it is understandable.)
> 
How about 'if the symbol is visible'?

> > +   to jump to target menu to configurate that symbol.
> 
> configure?
>
Thanks, I will correct them.

> -- 
> Jim

-- 
Thanks,
Changbin


signature.asc
Description: PGP signature

[PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX

[Laura Abbott]

Both of these options are poorly named. The features they provide are
necessary for system security and should not be considered debug only.
Change the names to CONFIG_STRICT_KERNEL_RWX and
CONFIG_STRICT_MODULE_RWX to better describe what these options do.

Signed-off-by: Laura Abbott 
---
v3: Minor config text tweek per Kees. Corrected the change of config names in
the arm config files.
---
 Documentation/DocBook/kgdb.tmpl| 8 
 Documentation/security/self-protection.txt | 4 ++--
 arch/Kconfig   | 4 ++--
 arch/arm/configs/aspeed_g4_defconfig   | 4 ++--
 arch/arm/configs/aspeed_g5_defconfig   | 4 ++--
 arch/arm/include/asm/cacheflush.h  | 2 +-
 arch/arm/kernel/patch.c| 4 ++--
 arch/arm/kernel/vmlinux.lds.S  | 8 
 arch/arm/mm/Kconfig| 2 +-
 arch/arm/mm/init.c | 4 ++--
 arch/arm64/Kconfig.debug   | 2 +-
 arch/arm64/kernel/insn.c   | 2 +-
 arch/parisc/configs/712_defconfig  | 1 -
 arch/parisc/configs/c3000_defconfig| 1 -
 arch/parisc/mm/init.c  | 2 +-
 include/linux/filter.h | 4 ++--
 include/linux/init.h   | 4 ++--
 include/linux/module.h | 2 +-
 init/main.c| 4 ++--
 kernel/configs/android-recommended.config  | 2 +-
 kernel/module.c| 6 +++---
 kernel/power/hibernate.c   | 2 +-
 kernel/power/power.h   | 4 ++--
 kernel/power/snapshot.c| 4 ++--
 24 files changed, 41 insertions(+), 43 deletions(-)

diff --git a/Documentation/DocBook/kgdb.tmpl b/Documentation/DocBook/kgdb.tmpl
index f3abca7..856ac20 100644
--- a/Documentation/DocBook/kgdb.tmpl
+++ b/Documentation/DocBook/kgdb.tmpl
@@ -115,12 +115,12 @@
 
 
 If the architecture that you are using supports the kernel option
-CONFIG_DEBUG_RODATA, you should consider turning it off.  This
+CONFIG_STRICT_KERNEL_RWX, you should consider turning it off.  This
 option will prevent the use of software breakpoints because it
 marks certain regions of the kernel's memory space as read-only.
 If kgdb supports it for the architecture you are using, you can
 use hardware breakpoints if you desire to run with the
-CONFIG_DEBUG_RODATA option turned on, else you need to turn off
+CONFIG_STRICT_KERNEL_RWX option turned on, else you need to turn off
 this option.
 
 
@@ -135,7 +135,7 @@
 Here is an example set of .config symbols to enable or
 disable for kgdb:
 
-# CONFIG_DEBUG_RODATA is not set
+# CONFIG_STRICT_KERNEL_RWX is not set
 CONFIG_FRAME_POINTER=y
 CONFIG_KGDB=y
 CONFIG_KGDB_SERIAL_CONSOLE=y
@@ -166,7 +166,7 @@
 
 Here is an example set of .config symbols to enable/disable kdb:
 
-# CONFIG_DEBUG_RODATA is not set
+# CONFIG_STRICT_KERNEL_RWX is not set
 CONFIG_FRAME_POINTER=y
 CONFIG_KGDB=y
 CONFIG_KGDB_SERIAL_CONSOLE=y
diff --git a/Documentation/security/self-protection.txt 
b/Documentation/security/self-protection.txt
index f41dd00..141acfe 100644
--- a/Documentation/security/self-protection.txt
+++ b/Documentation/security/self-protection.txt
@@ -51,8 +51,8 @@ kernel, they are implemented in a way where the memory is 
temporarily
 made writable during the update, and then returned to the original
 permissions.)
 
-In support of this are (the poorly named) CONFIG_DEBUG_RODATA and
-CONFIG_DEBUG_SET_MODULE_RONX, which seek to make sure that code is not
+In support of this are CONFIG_STRICT_KERNEL_RWX and
+CONFIG_STRICT_MODULE_RWX, which seek to make sure that code is not
 writable, data is not executable, and read-only data is neither writable
 nor executable.
 
diff --git a/arch/Kconfig b/arch/Kconfig
index 3f8b8be..33f5a55 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -790,7 +790,7 @@ config ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
 config ARCH_HAS_STRICT_KERNEL_RWX
def_bool n
 
-config DEBUG_RODATA
+config STRICT_KERNEL_RWX
bool "Make kernel text and rodata read-only" if ARCH_OPTIONAL_KERNEL_RWX
depends on ARCH_HAS_STRICT_KERNEL_RWX
default !ARCH_OPTIONAL_KERNEL_RWX || ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
@@ -806,7 +806,7 @@ config DEBUG_RODATA
 config ARCH_HAS_STRICT_MODULE_RWX
def_bool n
 
-config DEBUG_SET_MODULE_RONX
+config STRICT_MODULE_RWX
bool "Set loadable kernel module data as NX and text as RO" if 
ARCH_OPTIONAL_KERNEL_RWX
depends on ARCH_HAS_STRICT_MODULE_RWX && MODULES
default !ARCH_OPTIONAL_KERNEL_RWX || ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
diff --git a/arch/arm/configs/aspeed_g4_defconfig 
b/arch/arm/configs/aspeed_g4_defconfig
index ca39c04..05b99bc 100644
--- a/arch/arm/configs/aspeed_g4_defconfig
+++ b/arch/arm/configs/aspeed_g4_defconfig
@@ -25,7 +25,6 @@ 

[PATCHv3 0/2] Hardening configs refactor/rename

[Laura Abbott]

Hi,

This is v3 of my series to rename/refactor CONFIG_DEBUG_RODATA
and CONFIG_DEBUG_SET_MODULE_RONX. Among other objections, there shouldn't
be 'debug' in the name since these provide necessary kernel protection.

v3 mostly focuses on changing how the Kconfig dependencies work for the
refactor. Russell King requested that these options be deselectable for arm.
I also threw in some documentation on this under kernel hardening in case other
arches decide to follow suit.

The plan is for this to go through the KSPP tree so if people are okay with
this, please give Acks. I didn't take Mark Rutland's ack from before since
there's been a bit of refactoring.

Thanks,
Laura

Laura Abbott (2):
  arch: Move CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX to be common
  arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX

 Documentation/DocBook/kgdb.tmpl|  8 +++
 Documentation/security/self-protection.txt | 10 +++--
 arch/Kconfig   | 34 ++
 arch/arm/Kconfig   |  4 
 arch/arm/Kconfig.debug | 11 --
 arch/arm/configs/aspeed_g4_defconfig   |  4 ++--
 arch/arm/configs/aspeed_g5_defconfig   |  4 ++--
 arch/arm/include/asm/cacheflush.h  |  2 +-
 arch/arm/kernel/patch.c|  4 ++--
 arch/arm/kernel/vmlinux.lds.S  |  8 +++
 arch/arm/mm/Kconfig| 14 +---
 arch/arm/mm/init.c |  4 ++--
 arch/arm64/Kconfig |  5 ++---
 arch/arm64/Kconfig.debug   | 13 +---
 arch/arm64/kernel/insn.c   |  2 +-
 arch/parisc/Kconfig|  1 +
 arch/parisc/Kconfig.debug  | 11 --
 arch/parisc/configs/712_defconfig  |  1 -
 arch/parisc/configs/c3000_defconfig|  1 -
 arch/parisc/mm/init.c  |  2 +-
 arch/s390/Kconfig  |  5 ++---
 arch/s390/Kconfig.debug|  3 ---
 arch/x86/Kconfig   |  5 ++---
 arch/x86/Kconfig.debug | 11 --
 include/linux/filter.h |  4 ++--
 include/linux/init.h   |  4 ++--
 include/linux/module.h |  2 +-
 init/main.c|  4 ++--
 kernel/configs/android-recommended.config  |  2 +-
 kernel/module.c|  6 +++---
 kernel/power/hibernate.c   |  2 +-
 kernel/power/power.h   |  4 ++--
 kernel/power/snapshot.c|  4 ++--
 33 files changed, 90 insertions(+), 109 deletions(-)

-- 
2.7.4

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

[PATCHv3 1/2] arch: Move CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX to be common

[Laura Abbott]

There are multiple architectures that support CONFIG_DEBUG_RODATA and
CONFIG_SET_MODULE_RONX. These options also now have the ability to be
turned off at runtime. Move these to an architecture independent
location and make these options def_bool y for almost all of those
arches.

Signed-off-by: Laura Abbott 
---
v3: Make these configs selectable for arm. Include some documentation about
how the setup of the optional Kconfigs work as well. Stop spelling 'kenrel'
in prompt text.
---
 Documentation/security/self-protection.txt |  6 ++
 arch/Kconfig   | 34 ++
 arch/arm/Kconfig   |  4 
 arch/arm/Kconfig.debug | 11 --
 arch/arm/mm/Kconfig| 12 ---
 arch/arm64/Kconfig |  5 ++---
 arch/arm64/Kconfig.debug   | 11 --
 arch/parisc/Kconfig|  1 +
 arch/parisc/Kconfig.debug  | 11 --
 arch/s390/Kconfig  |  5 ++---
 arch/s390/Kconfig.debug|  3 ---
 arch/x86/Kconfig   |  5 ++---
 arch/x86/Kconfig.debug | 11 --
 13 files changed, 51 insertions(+), 68 deletions(-)

diff --git a/Documentation/security/self-protection.txt 
b/Documentation/security/self-protection.txt
index 3010576..f41dd00 100644
--- a/Documentation/security/self-protection.txt
+++ b/Documentation/security/self-protection.txt
@@ -56,6 +56,12 @@ CONFIG_DEBUG_SET_MODULE_RONX, which seek to make sure that 
code is not
 writable, data is not executable, and read-only data is neither writable
 nor executable.
 
+Most architectures have these options on by default and not user selectable.
+For some architectures like arm that wish to have these be selectable,
+the architecture Kconfig can select ARCH_OPTIONAL_KERNEL_RWX to enable
+a Kconfig prompt. CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT determines
+the default setting when ARCH_OPTIONAL_KERNEL_RWX is enabled.
+
  Function pointers and sensitive variables must not be writable
 
 Vast areas of kernel memory contain function pointers that are looked
diff --git a/arch/Kconfig b/arch/Kconfig
index 99839c2..3f8b8be 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -781,4 +781,38 @@ config VMAP_STACK
  the stack to map directly to the KASAN shadow map using a formula
  that is incorrect if the stack is in vmalloc space.
 
+config ARCH_OPTIONAL_KERNEL_RWX
+   def_bool n
+
+config ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
+   def_bool n
+
+config ARCH_HAS_STRICT_KERNEL_RWX
+   def_bool n
+
+config DEBUG_RODATA
+   bool "Make kernel text and rodata read-only" if ARCH_OPTIONAL_KERNEL_RWX
+   depends on ARCH_HAS_STRICT_KERNEL_RWX
+   default !ARCH_OPTIONAL_KERNEL_RWX || ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
+   help
+ If this is set, kernel text and rodata memory will be made read-only,
+ and non-text memory will be made non-executable. This provides
+ protection against certain security exploits (e.g. executing the heap
+ or modifying text)
+
+ These features are considered standard security practice these days.
+ You should say Y here in almost all cases.
+
+config ARCH_HAS_STRICT_MODULE_RWX
+   def_bool n
+
+config DEBUG_SET_MODULE_RONX
+   bool "Set loadable kernel module data as NX and text as RO" if 
ARCH_OPTIONAL_KERNEL_RWX
+   depends on ARCH_HAS_STRICT_MODULE_RWX && MODULES
+   default !ARCH_OPTIONAL_KERNEL_RWX || ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
+   help
+ If this is set, module text and rodata memory will be made read-only,
+ and non-text memory will be made non-executable. This provides
+ protection against certain security exploits (e.g. writing to text)
+
 source "kernel/gcov/Kconfig"
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 186c4c2..8748353 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -4,10 +4,14 @@ config ARM
select ARCH_CLOCKSOURCE_DATA
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
+   select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
+   select ARCH_HAS_STRICT_MODULE_RWX if MMU
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAVE_CUSTOM_GPIO_H
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_MIGHT_HAVE_PC_PARPORT
+   select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
+   select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT if CPU_V7
select ARCH_SUPPORTS_ATOMIC_RMW
select ARCH_USE_BUILTIN_BSWAP
select ARCH_USE_CMPXCHG_LOCKREF
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index d83f7c3..426d271 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1738,17 +1738,6 @@ config PID_IN_CONTEXTIDR
  additional instructions during context 

Re: [PATCH linux v6 1/6] hwmon: Add core On-Chip Controller support for POWER CPUs

[kbuild test robot]

Hi Edward,

[auto build test WARNING on hwmon/hwmon-next]
[also build test WARNING on v4.10-rc7 next-20170206]
[cannot apply to linux/master]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/eajames-linux-vnet-ibm-com/drivers-hwmon-Add-On-Chip-Controller-driver/20170207-043353
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
hwmon-next
config: openrisc-allyesconfig (attached as .config)
compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=openrisc 

All warnings (new ones prefixed by >>):

   drivers/hwmon/occ/occ.c: In function 'parse_occ_response':
>> drivers/hwmon/occ/occ.c:127:6: warning: unused variable 'rc'

vim +/rc +127 drivers/hwmon/occ/occ.c

   111  struct device *dev;
   112  void *bus;
   113  struct occ_bus_ops bus_ops;
   114  struct occ_ops ops;
   115  struct occ_config config;
   116  unsigned long last_updated;
   117  struct mutex update_lock;
   118  struct occ_response response;
   119  bool valid;
   120  u8 *raw_data;
   121  };
   122  
   123  static int parse_occ_response(struct occ *driver, u16 num_bytes)
   124  {
   125  int b;
   126  int s;
 > 127  int rc;
   128  unsigned int offset = SENSOR_BLOCK_OFFSET;
   129  int sensor_type;
   130  u8 num_sensor_blocks;
   131  struct sensor_data_block_header *block;
   132  void *sensors;
   133  struct device *dev = driver->dev;
   134  u8 *data = driver->raw_data;
   135  struct occ_response *resp = >response;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v8 07/12] dt-bindings: i2c: i2c-mux-simple: document i2c-mux-simple bindings

[Rob Herring]

On Fri, Feb 3, 2017 at 2:25 AM, Peter Rosin  wrote:
> On 2017-02-02 17:08, Rob Herring wrote:
>> On Tue, Jan 31, 2017 at 1:36 AM, Peter Rosin  wrote:
>>> If you see this new driver as something that is superseding the existing
>>> i2c-mux-gpio driver, I'm sad to inform you that the code is not simply
>>> not there. i2c-mux-gpio has acpi support and users may provide platform
>>> data from code. The existing i2c-mux-gpio driver also has the below
>>> mentioned locking heuristic. Adding all those things to the new driver
>>> would make it big and unwieldy and having even more unwanted tentacles
>>> into other subsystems. And why should it be only i2c-mux-gpio that is
>>> merged into this new i2c-mux driver? Why not implement a mux-pinctrl
>>> driver for the new mux subsustem and then merge i2c-mux-pinctrl as well?
>>> I say no, that way lies madness.
>>
>> Sounds like a good idea to me. I'm not saying you need to merge any of
>> them right now though (that's Wolfram's call).
>
> If we're pedantic I probably have some stake in it too, being the i2c-mux
> maintainer and all. But, agreed, I arrived quite late to the Linux kernel
> party and my opinion might perhaps not carry all that much weight...
>
>> None of this has anything to do with the binding though. Compatible
>> strings should be specific. That's not up for debate. Whether the
>
> Ok, I'm going to focus on the compatible string for a minute and leave
> the implementation details for some other discussion.
>
>> driver bound to a compatible string is common or specific to that
>> compatible string is completely up to the OS. That decision can change
>> over time, but the binding should not.
>
> So, there's the existing compatible "i2c-mux-gpio" ("i2c-gpio-mux" is
> wrong) that you seem to suggest is what I should stick to. I object to
> that.
>
> As you say, the bindings and compatible strings should describe hardware,
> and you also state they should be specific. I agree. But, why are you
> then apparently suggesting (by implication) that for this (hypothetical)
> hardware...
>
> ..
> |SDA0|---.
> |SCL0|-. |
> || | |
> ||  .---.
> ||  |adg792a|
> ||  |   |
> |ADC0|--|D1  S1A| signal A
> ||  |S1B| signal B
> ||  |S1C| signal C
> ||  |S1D| signal D
> ||  |   |
> |SDA1|---+--|D2  S2A| i2s segment foo A
> |SCL1|-. |  |S2B| i2s segment foo B
> '' | |  |S2C| i2s segment foo C
>| |  |S2D| i2s segment foo D
>| |  |   |
>| '--|D3  S3A| i2s segment bar A
>||S3B| i2s segment bar B
>||S3C| i2s segment bar C
>||S3D| i2s segment bar D
>|'---'
>|  A B C D   A B C D  (feed SCL1 to each of
>|  | | | |   | | | |   the 8 muxed segments)
>'--+-+-+-+---+-+-+-'
>
> ...the devicetree should be like below?
>
>  {
> mux: mux-controller@50 {
> compatible = "adi,adg792a";
> reg = <0x50>;
> #mux-control-cells = <1>;
> };
> };
>
> adc-mux {
> compatible = "io-channel-mux";
> io-channels = < 0>;
> io-channel-names = "parent";
>
> mux-controls = < 0>;
>
> ...
> };
>
> i2c-mux-foo {
> compatible = "i2c-mux-gpio";
> i2c-parent = <>;
>
> mux-controls = < 1>;
>
> ...
> };
>
> i2c-mux-bar {
> compatible = "i2c-mux-gpio";
> i2c-parent = <>;
>
> mux-controls = < 2>;
>
> ...
> };
>
> There must be some disconnect, because those "i2c-mux-gpio" compatible
> strings are just dead wrong. There simply are no gpio pins involved at
> all and that "gpio" suffix is just totally out of place.

Indeed. In the above case, that makes no sense.

> So, since you are not happy with "i2c-mux-simple", "i2c-mux-generic" or
> "i2c-mux" that I have suggested, can you please come up with something
> that is good enough for the above?

Let's go with just "i2c-mux". I've got nothing better and simple or
generic doesn't add anything.

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

Re: [PATCH 0/3 v2] PM / docs: linux/pm.h kerneldocs update and conversion of two docs to reST

[Rafael J. Wysocki]

On Mon, Feb 6, 2017 at 7:28 PM, Jonathan Corbet  wrote:
> On Thu, 02 Feb 2017 01:30:08 +0100
> "Rafael J. Wysocki"  wrote:
>
>> This is a new (and hopefully final) iteration of the series of patches 
>> starting
>> the conversion of power management driver API documentation.
>>
>> Patch [1/3] updates kerneldoc comments in include/linux/pm.h (to make the
>> documentation generated out of them look better), patch [2/3] converts
>> Documentation/power/devices.txt to reST, and patch [3/3] does the same thing
>> to Documentation/power/notifiers.txt (the new files go into the driver-api 
>> subdir
>> and are hooked up to that manual).
>>
>> Patch [1/3] has not been changed since the previous iteration.  Patch [2/3]
>> addresses some comments from Lukas and patch [3/3] has been trivially
>> rebased.
>>
>> Please apply unless there are any objections.
>
> Just applied them, thanks.

Thank you!

> One thing I do notice is that, while you update the kerneldoc comments,
> nothing in the associated documentation pulls them in.  That would be a
> good future enhancement...:)

They are pulled in by patch [2/3] via types.rst (AFAICS).

I guess that's a bit confusing (sorry about that), but I wanted to
avoid putting too much stuff into one patch.

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

[PATCH linux v6 2/6] hwmon: occ: Add sysfs interface

[eajames]

From: "Edward A. James" 

Add a generic mechanism to expose the sensors provided by the OCC in
sysfs.

Signed-off-by: Edward A. James 
Signed-off-by: Andrew Jeffery 
---
 Documentation/hwmon/occ   |  62 +++
 drivers/hwmon/occ/Makefile|   2 +-
 drivers/hwmon/occ/occ_sysfs.c | 251 ++
 drivers/hwmon/occ/occ_sysfs.h |  30 +
 4 files changed, 344 insertions(+), 1 deletion(-)
 create mode 100644 drivers/hwmon/occ/occ_sysfs.c
 create mode 100644 drivers/hwmon/occ/occ_sysfs.h

diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
index 79d1642..d0bdf06 100644
--- a/Documentation/hwmon/occ
+++ b/Documentation/hwmon/occ
@@ -25,6 +25,68 @@ Currently, all versions of the OCC support four types of 
sensor data: power,
 temperature, frequency, and "caps," which indicate limits and thresholds used
 internally on the OCC.
 
+sysfs Entries
+-
+
+The OCC driver uses the hwmon sysfs framework to provide data to userspace.
+
+The driver exports a number of sysfs files for each type of sensor. The
+sensor-specific files vary depending on the processor type, though many of the
+attributes are common for both the POWER8 and POWER9.
+
+The hwmon interface cannot define every type of sensor that may be used.
+Therefore, the frequency sensor on the OCC uses the "input" type sensor defined
+by the hwmon interface, rather than defining a new type of custom sensor.
+
+Below are detailed the names and meaning of each sensor file for both types of
+processors. All sensors are read-only unless otherwise specified.  indicates
+the hwmon index. sensor id indicates the unique internal OCC identifer. Please
+see the POWER OCC specification for details on all these sensor values.
+
+frequency:
+   all processors:
+   in_input - frequency value
+   in_label - sensor id
+temperature:
+   POWER8:
+   temp_input - temperature value
+   temp_label - sensor id
+   POWER9 (in addition to above):
+   temp_type - FRU type
+
+power:
+   POWER8:
+   power_input - power value
+   power_label - sensor id
+   power_average - accumulator
+   power_average_interval - update tag (number of samples in
+   accumulator)
+   POWER9:
+   power_input - power value
+   power_label - sensor id
+   power_average_min - accumulator[0]
+   power_average_max - accumulator[1] (64 bits total)
+   power_average_interval - update tag
+   power_reset_history - (function_id | (apss_channel << 8)
+
+caps:
+   POWER8:
+   power_cap - current powercap
+   power_cap_max - max powercap
+   power_cap_min - min powercap
+   power_max - normal powercap
+   power_alarm - user powercap, r/w
+   POWER9:
+   power_cap_alarm - user powercap source
+
+The driver also provides two sysfs entries through hwmon to better
+control the driver and monitor the master OCC. Though there may be multiple
+OCCs present on the system, these two files are only present for the "master"
+OCC.
+   name - read the name of the driver
+   update_interval - read or write the minimum interval for polling the
+   OCC.
+
 BMC - Host Communications
 -
 
diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
index 93cb52f..a6881f9 100644
--- a/drivers/hwmon/occ/Makefile
+++ b/drivers/hwmon/occ/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_SENSORS_PPC_OCC) += occ.o
+obj-$(CONFIG_SENSORS_PPC_OCC) += occ.o occ_sysfs.o
diff --git a/drivers/hwmon/occ/occ_sysfs.c b/drivers/hwmon/occ/occ_sysfs.c
new file mode 100644
index 000..9598f78
--- /dev/null
+++ b/drivers/hwmon/occ/occ_sysfs.c
@@ -0,0 +1,251 @@
+/*
+ * occ_sysfs.c - OCC sysfs interface
+ *
+ * This file contains the methods and data structures for implementing the OCC
+ * hwmon sysfs entries.
+ *
+ * Copyright 2016 IBM Corp.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "occ.h"
+#include "occ_sysfs.h"
+
+#define OCC_HWMON_NAME_LENGTH  32
+
+struct occ_sysfs {
+   struct device *dev;
+   struct occ *occ;
+
+   char hwmon_name[OCC_HWMON_NAME_LENGTH + 1];
+   const u32 

[PATCH linux v6 4/6] hwmon: occ: Add callbacks for parsing P8 OCC datastructures

[eajames]

From: "Edward A. James" 

Add functions to parse the data structures that are specific to the OCC on
the POWER8 processor. These are the sensor data structures, including
temperature, frequency, power, and "caps."

Signed-off-by: Edward A. James 
Signed-off-by: Andrew Jeffery 
---
 Documentation/hwmon/occ|   9 ++
 drivers/hwmon/occ/occ_p8.c | 248 +
 drivers/hwmon/occ/occ_p8.h |  30 ++
 3 files changed, 287 insertions(+)
 create mode 100644 drivers/hwmon/occ/occ_p8.c
 create mode 100644 drivers/hwmon/occ/occ_p8.h

diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
index d0bdf06..143951e 100644
--- a/Documentation/hwmon/occ
+++ b/Documentation/hwmon/occ
@@ -25,6 +25,15 @@ Currently, all versions of the OCC support four types of 
sensor data: power,
 temperature, frequency, and "caps," which indicate limits and thresholds used
 internally on the OCC.
 
+The format for the POWER8 OCC sensor data can be found in the P8 OCC
+specification:
+github.com/open-power/docs/blob/master/occ/OCC_OpenPwr_FW_Interfaces.pdf
+This document provides the details of the OCC sensors: power, frequency,
+temperature, and caps. These sensor formats are specific to the POWER8 OCC. A
+number of data structures, such as command format, response headers, and the
+like, are also defined in this specification, and are common to both POWER8 and
+POWER9 OCCs.
+
 sysfs Entries
 -
 
diff --git a/drivers/hwmon/occ/occ_p8.c b/drivers/hwmon/occ/occ_p8.c
new file mode 100644
index 000..5c61fc4
--- /dev/null
+++ b/drivers/hwmon/occ/occ_p8.c
@@ -0,0 +1,248 @@
+/*
+ * occ_p8.c - OCC hwmon driver
+ *
+ * This file contains the Power8-specific methods and data structures for
+ * the OCC hwmon driver.
+ *
+ * Copyright 2016 IBM Corp.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "occ.h"
+#include "occ_p8.h"
+
+/* P8 OCC sensor data format */
+struct p8_occ_sensor {
+   u16 sensor_id;
+   u16 value;
+};
+
+struct p8_power_sensor {
+   u16 sensor_id;
+   u32 update_tag;
+   u32 accumulator;
+   u16 value;
+};
+
+struct p8_caps_sensor {
+   u16 curr_powercap;
+   u16 curr_powerreading;
+   u16 norm_powercap;
+   u16 max_powercap;
+   u16 min_powercap;
+   u16 user_powerlimit;
+};
+
+static const u32 p8_sensor_hwmon_configs[MAX_OCC_SENSOR_TYPE] = {
+   HWMON_I_INPUT | HWMON_I_LABEL,  /* freq: value | label */
+   HWMON_T_INPUT | HWMON_T_LABEL,  /* temp: value | label */
+   /* power: value | label | accumulator | update_tag */
+   HWMON_P_INPUT | HWMON_P_LABEL | HWMON_P_AVERAGE |
+   HWMON_P_AVERAGE_INTERVAL,
+   /* caps: curr | max | min | norm | user */
+   HWMON_P_CAP | HWMON_P_CAP_MAX | HWMON_P_CAP_MIN | HWMON_P_MAX |
+   HWMON_P_ALARM,
+};
+
+void p8_parse_sensor(u8 *data, void *sensor, int sensor_type, int off,
+int snum)
+{
+   switch (sensor_type) {
+   case FREQ:
+   case TEMP:
+   {
+   struct p8_occ_sensor *os =
+   &(((struct p8_occ_sensor *)sensor)[snum]);
+
+   os->sensor_id = be16_to_cpu(get_unaligned((u16 *)[off]));
+   os->value = be16_to_cpu(get_unaligned((u16 *)[off + 2]));
+   }
+   break;
+   case POWER:
+   {
+   struct p8_power_sensor *ps =
+   &(((struct p8_power_sensor *)sensor)[snum]);
+
+   ps->sensor_id = be16_to_cpu(get_unaligned((u16 *)[off]));
+   ps->update_tag =
+   be32_to_cpu(get_unaligned((u32 *)[off + 2]));
+   ps->accumulator =
+   be32_to_cpu(get_unaligned((u32 *)[off + 6]));
+   ps->value = be16_to_cpu(get_unaligned((u16 *)[off + 10]));
+   }
+   break;
+   case CAPS:
+   {
+   struct p8_caps_sensor *cs =
+   &(((struct p8_caps_sensor *)sensor)[snum]);
+
+   cs->curr_powercap =
+   be16_to_cpu(get_unaligned((u16 *)[off]));
+   cs->curr_powerreading =
+   be16_to_cpu(get_unaligned((u16 *)[off + 2]));
+   cs->norm_powercap =
+   be16_to_cpu(get_unaligned((u16 *)[off + 4]));
+   cs->max_powercap =
+

[PATCH linux v6 6/6] hwmon: occ: Add callbacks for parsing P9 OCC datastructures

[eajames]

From: "Edward A. James" 

Add functions to parse the data structures that are specific to the OCC on
the POWER9 processor. These are the sensor data structures, including
temperature, frequency, power, and "caps."

Signed-off-by: Edward A. James 
Signed-off-by: Andrew Jeffery 
---
 Documentation/hwmon/occ|   3 +
 drivers/hwmon/occ/occ_p9.c | 309 +
 drivers/hwmon/occ/occ_p9.h |  30 +
 3 files changed, 342 insertions(+)
 create mode 100644 drivers/hwmon/occ/occ_p9.c
 create mode 100644 drivers/hwmon/occ/occ_p9.h

diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
index 143951e..6cea853 100644
--- a/Documentation/hwmon/occ
+++ b/Documentation/hwmon/occ
@@ -34,6 +34,9 @@ number of data structures, such as command format, response 
headers, and the
 like, are also defined in this specification, and are common to both POWER8 and
 POWER9 OCCs.
 
+There is currently no public P9 OCC specification, and the data structures
+defined in the POWER9 OCC driver are subject to change.
+
 sysfs Entries
 -
 
diff --git a/drivers/hwmon/occ/occ_p9.c b/drivers/hwmon/occ/occ_p9.c
new file mode 100644
index 000..3ef0284
--- /dev/null
+++ b/drivers/hwmon/occ/occ_p9.c
@@ -0,0 +1,309 @@
+/*
+ * occ_p9.c - OCC hwmon driver
+ *
+ * This file contains the Power9-specific methods and data structures for
+ * the OCC hwmon driver.
+ *
+ * Copyright 2016 IBM Corp.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "occ.h"
+#include "occ_p9.h"
+
+/* P9 OCC sensor data format */
+struct p9_temp_sensor {
+   u32 sensor_id;
+   u8 fru_type;
+   u8 value;
+};
+
+struct p9_freq_sensor {
+   u32 sensor_id;
+   u16 value;
+};
+
+struct p9_power_sensor {
+   u32 sensor_id;
+   u8 function_id;
+   u8 apss_channel;
+   u16 reserved;
+   u32 update_tag;
+   u64 accumulator;
+   u16 value;
+};
+
+struct p9_caps_sensor {
+   u16 curr_powercap;
+   u16 curr_powerreading;
+   u16 norm_powercap;
+   u16 max_powercap;
+   u16 min_powercap;
+   u16 user_powerlimit;
+   u8 user_powerlimit_source;
+};
+
+static const u32 p9_sensor_hwmon_configs[MAX_OCC_SENSOR_TYPE] = {
+   HWMON_I_INPUT | HWMON_I_LABEL,  /* freq: value | label */
+   /* temp: value | label | fru_type */
+   HWMON_T_INPUT | HWMON_T_LABEL | HWMON_T_TYPE,
+   /* power: value | label | accum[0] | accum[1] | update_tag |
+*   (function_id | (apss_channel << 8))
+*/
+   HWMON_P_INPUT | HWMON_P_LABEL | HWMON_P_AVERAGE_MIN |
+   HWMON_P_AVERAGE_MAX | HWMON_P_AVERAGE_INTERVAL |
+   HWMON_P_RESET_HISTORY,
+   /* caps: curr | max | min | norm | user | source */
+   HWMON_P_CAP | HWMON_P_CAP_MAX | HWMON_P_CAP_MIN | HWMON_P_MAX |
+   HWMON_P_ALARM | HWMON_P_CAP_ALARM,
+};
+
+void p9_parse_sensor(u8 *data, void *sensor, int sensor_type, int off,
+int snum)
+{
+   switch (sensor_type) {
+   case FREQ:
+   {
+   struct p9_freq_sensor *fs =
+   &(((struct p9_freq_sensor *)sensor)[snum]);
+
+   fs->sensor_id = be32_to_cpu(get_unaligned((u32 *)[off]));
+   fs->value = be16_to_cpu(get_unaligned((u16 *)[off + 4]));
+   }
+   break;
+   case TEMP:
+   {
+   struct p9_temp_sensor *ts =
+   &(((struct p9_temp_sensor *)sensor)[snum]);
+
+   ts->sensor_id = be32_to_cpu(get_unaligned((u32 *)[off]));
+   fs->fru_type = data[off + 4];
+   fs->value = data[off + 5];
+   }
+   break;
+   case POWER:
+   {
+   struct p9_power_sensor *ps =
+   &(((struct p9_power_sensor *)sensor)[snum]);
+
+   ps->sensor_id = be32_to_cpu(get_unaligned((u32 *)[off]));
+   ps->function_id = data[off + 4];
+   ps->apss_channel = data[off + 5];
+   ps->update_tag =
+   be32_to_cpu(get_unaligned((u32 *)[off + 8]));
+   ps->accumulator =
+   be64_to_cpu(get_unaligned((u64 *)[off + 12]));
+   ps->value = be16_to_cpu(get_unaligned((u16 *)[off + 20]));
+   }
+   break;
+   case CAPS:
+   {
+   struct 

[PATCH linux v6 3/6] hwmon: occ: Add I2C transport implementation for SCOM operations

[eajames]

From: "Edward A. James" 

Add functions to send SCOM operations over I2C bus. The BMC can
communicate with the Power8 host processor over I2C, but needs to use SCOM
operations in order to access the OCC register space.

Signed-off-by: Edward A. James 
Signed-off-by: Andrew Jeffery 
---
 drivers/hwmon/occ/occ_scom_i2c.c | 77 
 drivers/hwmon/occ/occ_scom_i2c.h | 26 ++
 2 files changed, 103 insertions(+)
 create mode 100644 drivers/hwmon/occ/occ_scom_i2c.c
 create mode 100644 drivers/hwmon/occ/occ_scom_i2c.h

diff --git a/drivers/hwmon/occ/occ_scom_i2c.c b/drivers/hwmon/occ/occ_scom_i2c.c
new file mode 100644
index 000..74bd6ff
--- /dev/null
+++ b/drivers/hwmon/occ/occ_scom_i2c.c
@@ -0,0 +1,77 @@
+/*
+ * occ_scom_i2c.c - hwmon OCC driver
+ *
+ * This file contains the functions for performing SCOM operations over I2C bus
+ * to access the OCC.
+ *
+ * Copyright 2016 IBM Corp.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include "occ_scom_i2c.h"
+#include "scom.h"
+
+int occ_i2c_getscom(void *bus, u32 address, u64 *data)
+{
+   ssize_t rc;
+   u64 buf;
+   struct i2c_client *client = bus;
+   struct i2c_msg msgs[2];
+
+   msgs[0].addr = client->addr;
+   msgs[0].flags = client->flags & I2C_M_TEN;
+   msgs[0].len = sizeof(u32);
+   msgs[0].buf = (char *)
+
+   msgs[1].addr = client->addr;
+   msgs[1].flags = client->flags & I2C_M_TEN;
+   msgs[1].flags |= I2C_M_RD;
+   msgs[1].len = sizeof(u64);
+   msgs[1].buf = (char *)
+
+   rc = i2c_transfer(client->adapter, msgs, 2);
+   if (rc < 0)
+   return rc;
+
+   *data = be64_to_cpu(buf);
+
+   return 0;
+}
+EXPORT_SYMBOL(occ_i2c_getscom);
+
+int occ_i2c_putscom(void *bus, u32 address, u32 data0, u32 data1)
+{
+   u32 buf[3];
+   ssize_t rc;
+   struct i2c_client *client = bus;
+
+   /* send raw data, user can handle endian */
+   buf[0] = address;
+   buf[1] = data1;
+   buf[2] = data0;
+
+   rc = i2c_master_send(client, (const char *)buf, sizeof(u32) * 3);
+   if (rc < 0)
+   return rc;
+   else if (rc != sizeof(u32) * 3)
+   return -EIO;
+
+   return 0;
+}
+EXPORT_SYMBOL(occ_i2c_putscom);
+
+MODULE_AUTHOR("Eddie James ");
+MODULE_DESCRIPTION("I2C OCC SCOM transport");
+MODULE_LICENSE("GPL");
diff --git a/drivers/hwmon/occ/occ_scom_i2c.h b/drivers/hwmon/occ/occ_scom_i2c.h
new file mode 100644
index 000..945739c
--- /dev/null
+++ b/drivers/hwmon/occ/occ_scom_i2c.h
@@ -0,0 +1,26 @@
+/*
+ * occ_scom_i2c.h - hwmon OCC driver
+ *
+ * This file contains function protoypes for peforming SCOM operations over I2C
+ * bus to access the OCC.
+ *
+ * Copyright 2016 IBM Corp.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __OCC_SCOM_I2C_H__
+#define __OCC_SCOM_I2C_H__
+
+int occ_i2c_getscom(void *bus, u32 address, u64 *data);
+int occ_i2c_putscom(void *bus, u32 address, u32 data0, u32 data1);
+
+#endif /* __OCC_SCOM_I2C_H__ */
-- 
1.8.3.1

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

[PATCH linux v6 0/6] drivers: hwmon: Add On-Chip Controller driver

[eajames]

From: "Edward A. James" 

This patchset adds a hwmon driver to support the OCC (On-Chip Controller)
on the IBM POWER8 and POWER9 processors, from a BMC (Baseboard Management
Controller). The OCC is an embedded processor that provides real time
power and thermal monitoring.

The driver provides an interface on a BMC to poll OCC sensor data, set
user power caps, and perform some basic OCC error handling. It interfaces
with userspace through hwmon.

The driver is currently functional only for the OCC on POWER8 chips.
Communicating with the POWER9 OCC requries FSI support.

Edward A. James (6):
  hwmon: Add core On-Chip Controller support for POWER CPUs
  hwmon: occ: Add sysfs interface
  hwmon: occ: Add I2C transport implementation for SCOM operations
  hwmon: occ: Add callbacks for parsing P8 OCC datastructures
  hwmon: occ: Add hwmon implementation for the P8 OCC
  hwmon: occ: Add callbacks for parsing P9 OCC datastructures

 Documentation/devicetree/bindings/hwmon/occ.txt |  13 +
 Documentation/hwmon/occ | 114 ++
 MAINTAINERS |   7 +
 drivers/hwmon/Kconfig   |   2 +
 drivers/hwmon/Makefile  |   1 +
 drivers/hwmon/occ/Kconfig   |  29 ++
 drivers/hwmon/occ/Makefile  |   2 +
 drivers/hwmon/occ/occ.c | 450 
 drivers/hwmon/occ/occ.h |  81 +
 drivers/hwmon/occ/occ_p8.c  | 248 +
 drivers/hwmon/occ/occ_p8.h  |  30 ++
 drivers/hwmon/occ/occ_p9.c  | 309 
 drivers/hwmon/occ/occ_p9.h  |  30 ++
 drivers/hwmon/occ/occ_scom_i2c.c|  77 
 drivers/hwmon/occ/occ_scom_i2c.h|  26 ++
 drivers/hwmon/occ/occ_sysfs.c   | 251 +
 drivers/hwmon/occ/occ_sysfs.h   |  30 ++
 drivers/hwmon/occ/p8_occ_i2c.c  | 104 ++
 drivers/hwmon/occ/scom.h|  47 +++
 19 files changed, 1851 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/occ.txt
 create mode 100644 Documentation/hwmon/occ
 create mode 100644 drivers/hwmon/occ/Kconfig
 create mode 100644 drivers/hwmon/occ/Makefile
 create mode 100644 drivers/hwmon/occ/occ.c
 create mode 100644 drivers/hwmon/occ/occ.h
 create mode 100644 drivers/hwmon/occ/occ_p8.c
 create mode 100644 drivers/hwmon/occ/occ_p8.h
 create mode 100644 drivers/hwmon/occ/occ_p9.c
 create mode 100644 drivers/hwmon/occ/occ_p9.h
 create mode 100644 drivers/hwmon/occ/occ_scom_i2c.c
 create mode 100644 drivers/hwmon/occ/occ_scom_i2c.h
 create mode 100644 drivers/hwmon/occ/occ_sysfs.c
 create mode 100644 drivers/hwmon/occ/occ_sysfs.h
 create mode 100644 drivers/hwmon/occ/p8_occ_i2c.c
 create mode 100644 drivers/hwmon/occ/scom.h

-- 
1.8.3.1

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

[PATCH linux v6 5/6] hwmon: occ: Add hwmon implementation for the P8 OCC

[eajames]

From: "Edward A. James" 

Add code to tie the hwmon sysfs code and the POWER8 OCC code together, as
well as probe the entire driver from the I2C bus. I2C is the communication
method between the BMC and the P8 OCC.

Signed-off-by: Edward A. James 
Signed-off-by: Andrew Jeffery 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/hwmon/occ.txt |  13 +++
 drivers/hwmon/occ/Kconfig   |  14 
 drivers/hwmon/occ/Makefile  |   1 +
 drivers/hwmon/occ/p8_occ_i2c.c  | 104 
 4 files changed, 132 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/occ.txt
 create mode 100644 drivers/hwmon/occ/p8_occ_i2c.c

diff --git a/Documentation/devicetree/bindings/hwmon/occ.txt 
b/Documentation/devicetree/bindings/hwmon/occ.txt
new file mode 100644
index 000..b0d2b36
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/occ.txt
@@ -0,0 +1,13 @@
+HWMON I2C driver for IBM POWER CPU OCC (On Chip Controller)
+
+Required properties:
+ - compatible: must be "ibm,p8-occ-i2c"
+ - reg: physical address
+
+Example:
+i2c3: i2c-bus@100 {
+   occ@50 {
+   compatible = "ibm,p8-occ-i2c";
+   reg = <0x50>;
+   };
+};
diff --git a/drivers/hwmon/occ/Kconfig b/drivers/hwmon/occ/Kconfig
index cdb64a7..3a5188f 100644
--- a/drivers/hwmon/occ/Kconfig
+++ b/drivers/hwmon/occ/Kconfig
@@ -13,3 +13,17 @@ menuconfig SENSORS_PPC_OCC
 
  This driver can also be built as a module. If so, the module
  will be called occ.
+
+if SENSORS_PPC_OCC
+
+config SENSORS_PPC_OCC_P8_I2C
+   tristate "POWER8 OCC hwmon support"
+   depends on I2C
+   help
+Provide a hwmon sysfs interface for the POWER8 On-Chip Controller,
+exposing temperature, frequency and power measurements.
+
+This driver can also be built as a module. If so, the module will be
+called p8-occ-i2c.
+
+endif
diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
index a6881f9..9294b58 100644
--- a/drivers/hwmon/occ/Makefile
+++ b/drivers/hwmon/occ/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_SENSORS_PPC_OCC) += occ.o occ_sysfs.o
+obj-$(CONFIG_SENSORS_PPC_OCC_P8_I2C) += occ_scom_i2c.o occ_p8.o p8_occ_i2c.o
diff --git a/drivers/hwmon/occ/p8_occ_i2c.c b/drivers/hwmon/occ/p8_occ_i2c.c
new file mode 100644
index 000..6273040
--- /dev/null
+++ b/drivers/hwmon/occ/p8_occ_i2c.c
@@ -0,0 +1,104 @@
+/*
+ * p8_occ_i2c.c - hwmon OCC driver
+ *
+ * This file contains the i2c layer for accessing the P8 OCC over i2c bus.
+ *
+ * Copyright 2016 IBM Corp.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "occ_p8.h"
+#include "occ_scom_i2c.h"
+#include "occ_sysfs.h"
+#include "scom.h"
+
+#define P8_OCC_I2C_NAME"p8-occ-i2c"
+
+int p8_i2c_getscom(void *bus, u32 address, u64 *data)
+{
+   /* P8 i2c slave requires address to be shifted by 1 */
+   address = address << 1;
+
+   return occ_i2c_getscom(bus, address, data);
+}
+
+int p8_i2c_putscom(void *bus, u32 address, u32 data0, u32 data1)
+{
+   /* P8 i2c slave requires address to be shifted by 1 */
+   address = address << 1;
+
+   return occ_i2c_putscom(bus, address, data0, data1);
+}
+
+static struct occ_bus_ops p8_bus_ops = {
+   .getscom = p8_i2c_getscom,
+   .putscom = p8_i2c_putscom,
+};
+
+static int p8_occ_probe(struct i2c_client *client,
+   const struct i2c_device_id *id)
+{
+   struct occ *occ;
+   struct occ_sysfs *hwmon;
+   const u32 *sensor_hwmon_configs = p8_get_sensor_hwmon_configs();
+
+   occ = p8_occ_start(>dev, client, _bus_ops);
+   if (IS_ERR(occ))
+   return PTR_ERR(occ);
+
+   hwmon = occ_sysfs_start(>dev, occ, sensor_hwmon_configs,
+   P8_OCC_I2C_NAME);
+   if (IS_ERR(hwmon))
+   return PTR_ERR(hwmon);
+
+   i2c_set_clientdata(client, occ);
+
+   return 0;
+}
+
+/* used by old-style board info. */
+static const struct i2c_device_id occ_ids[] = {
+   { P8_OCC_I2C_NAME, 0 },
+   {}
+};
+MODULE_DEVICE_TABLE(i2c, occ_ids);
+
+/* used by device table */
+static const struct of_device_id occ_of_match[] = {
+   { .compatible = "ibm,p8-occ-i2c" },
+   {}
+};
+MODULE_DEVICE_TABLE(of, occ_of_match);
+
+static struct i2c_driver p8_occ_driver = {
+ 

[PATCH linux v6 1/6] hwmon: Add core On-Chip Controller support for POWER CPUs

[eajames]

From: "Edward A. James" 

Add core support for polling the OCC for it's sensor data and parsing that
data into sensor-specific information.

Signed-off-by: Edward A. James 
Signed-off-by: Andrew Jeffery 
---
 Documentation/hwmon/occ|  40 
 MAINTAINERS|   7 +
 drivers/hwmon/Kconfig  |   2 +
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/occ/Kconfig  |  15 ++
 drivers/hwmon/occ/Makefile |   1 +
 drivers/hwmon/occ/occ.c| 450 +
 drivers/hwmon/occ/occ.h|  81 
 drivers/hwmon/occ/scom.h   |  47 +
 9 files changed, 644 insertions(+)
 create mode 100644 Documentation/hwmon/occ
 create mode 100644 drivers/hwmon/occ/Kconfig
 create mode 100644 drivers/hwmon/occ/Makefile
 create mode 100644 drivers/hwmon/occ/occ.c
 create mode 100644 drivers/hwmon/occ/occ.h
 create mode 100644 drivers/hwmon/occ/scom.h

diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
new file mode 100644
index 000..79d1642
--- /dev/null
+++ b/Documentation/hwmon/occ
@@ -0,0 +1,40 @@
+Kernel driver occ
+=
+
+Supported chips:
+ * ASPEED AST2400
+ * ASPEED AST2500
+
+Please note that the chip must be connected to a POWER8 or POWER9 processor
+(see the BMC - Host Communications section).
+
+Author: Eddie James 
+
+Description
+---
+
+This driver implements support for the OCC (On-Chip Controller) on the IBM
+POWER8 and POWER9 processors, from a BMC (Baseboard Management Controller). The
+OCC is an embedded processor that provides real time power and thermal
+monitoring.
+
+This driver provides an interface on a BMC to poll OCC sensor data, set user
+power caps, and perform some basic OCC error handling.
+
+Currently, all versions of the OCC support four types of sensor data: power,
+temperature, frequency, and "caps," which indicate limits and thresholds used
+internally on the OCC.
+
+BMC - Host Communications
+-
+
+For the POWER8 application, the BMC can communicate with the P8 over I2C bus.
+However, to access the OCC register space, any data transfer must use a SCOM
+operation. SCOM is a procedure to initiate a data transfer, typically of 8
+bytes. SCOMs consist of writing a 32-bit command register and then
+reading/writing two 32-bit data registers. This driver implements these
+SCOM operations over I2C bus in order to communicate with the OCC.
+
+For the POWER9 application, the BMC can communicate with the P9 over FSI bus
+and SBE engine. Once again, SCOM operations are required. This driver will
+implement SCOM ops over FSI/SBE. This will require the FSI driver.
diff --git a/MAINTAINERS b/MAINTAINERS
index 5f10c28..193a13b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9128,6 +9128,13 @@ T:   git git://linuxtv.org/media_tree.git
 S: Maintained
 F: drivers/media/i2c/ov7670.c
 
+ON-CHIP CONTROLLER HWMON DRIVER
+M: Eddie James 
+L: linux-hw...@vger.kernel.org
+S: Maintained
+F: Documentation/hwmon/occ
+F: drivers/hwmon/occ/
+
 ONENAND FLASH DRIVER
 M: Kyungmin Park 
 L: linux-...@lists.infradead.org
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 190d270..e80ca81 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1240,6 +1240,8 @@ config SENSORS_NSA320
  This driver can also be built as a module. If so, the module
  will be called nsa320-hwmon.
 
+source drivers/hwmon/occ/Kconfig
+
 config SENSORS_PCF8591
tristate "Philips PCF8591 ADC/DAC"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index d2cb7e8..c7ec5d4 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -169,6 +169,7 @@ obj-$(CONFIG_SENSORS_WM831X)+= wm831x-hwmon.o
 obj-$(CONFIG_SENSORS_WM8350)   += wm8350-hwmon.o
 obj-$(CONFIG_SENSORS_XGENE)+= xgene-hwmon.o
 
+obj-$(CONFIG_SENSORS_PPC_OCC)  += occ/
 obj-$(CONFIG_PMBUS)+= pmbus/
 
 ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
diff --git a/drivers/hwmon/occ/Kconfig b/drivers/hwmon/occ/Kconfig
new file mode 100644
index 000..cdb64a7
--- /dev/null
+++ b/drivers/hwmon/occ/Kconfig
@@ -0,0 +1,15 @@
+#
+# On Chip Controller configuration
+#
+
+menuconfig SENSORS_PPC_OCC
+   bool "PPC On-Chip Controller"
+   help
+ If you say yes here you get support to monitor Power CPU
+ sensors via the On-Chip Controller (OCC).
+
+ Generally this is used by management controllers such as a BMC
+ on an OpenPower system.
+
+ This driver can also be built as a module. If so, the module
+ will be called occ.
diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
new file mode 100644
index 000..93cb52f
--- /dev/null
+++ b/drivers/hwmon/occ/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_SENSORS_PPC_OCC) += occ.o
diff --git a/drivers/hwmon/occ/occ.c 

Re: [PATCHv2 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX

[Kees Cook]

On Mon, Feb 6, 2017 at 10:49 AM, Laura Abbott  wrote:
> On 02/03/2017 12:03 PM, Kees Cook wrote:
>> On Fri, Feb 3, 2017 at 9:52 AM, Laura Abbott  wrote:
>>>
>>> Both of these options are poorly named. The features they provide are
>>> necessary for system security and should not be considered debug only.
>>> Change the name to something that accurately describes what these
>>> options do.
>>
>> It may help to explicitly call out the name change from/to in the
>> commit message.
>>
>>>
>>> Signed-off-by: Laura Abbott 
>>> ---
>>> [...]
>>> diff --git a/arch/arm/configs/aspeed_g4_defconfig 
>>> b/arch/arm/configs/aspeed_g4_defconfig
>>> index ca39c04..beea2cc 100644
>>> --- a/arch/arm/configs/aspeed_g4_defconfig
>>> +++ b/arch/arm/configs/aspeed_g4_defconfig
>>> @@ -25,7 +25,6 @@ CONFIG_MODULE_UNLOAD=y
>>>  # CONFIG_ARCH_MULTI_V7 is not set
>>>  CONFIG_ARCH_ASPEED=y
>>>  CONFIG_MACH_ASPEED_G4=y
>>> -CONFIG_DEBUG_RODATA=y
>>>  CONFIG_AEABI=y
>>>  CONFIG_UACCESS_WITH_MEMCPY=y
>>>  CONFIG_SECCOMP=y
>>
>> Are these defconfig cases correct (dropping DEBUG_RODATA without
>> adding STRICT_KERNEL_RWX)?
>>
>
> Yes, I think these need to be updated to the new config option since
> these are not CPUv7
>
>
>> Who should carry this series, btw?
>>
>
> An excellent question :)
>
> Would you be willing to carry it with Acks?

Yeah, I can push this via the KSPP tree: it's cross-architecture, so
it seems like this should go either through my tree or through akpm's
tree.

Are the arch maintainers okay with that?

-Kees

-- 
Kees Cook
Pixel Security
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX

[Laura Abbott]

On 02/03/2017 12:03 PM, Kees Cook wrote:
> On Fri, Feb 3, 2017 at 9:52 AM, Laura Abbott  wrote:
>>
>> Both of these options are poorly named. The features they provide are
>> necessary for system security and should not be considered debug only.
>> Change the name to something that accurately describes what these
>> options do.
> 
> It may help to explicitly call out the name change from/to in the
> commit message.
> 
>>
>> Signed-off-by: Laura Abbott 
>> ---
>> [...]
>> diff --git a/arch/arm/configs/aspeed_g4_defconfig 
>> b/arch/arm/configs/aspeed_g4_defconfig
>> index ca39c04..beea2cc 100644
>> --- a/arch/arm/configs/aspeed_g4_defconfig
>> +++ b/arch/arm/configs/aspeed_g4_defconfig
>> @@ -25,7 +25,6 @@ CONFIG_MODULE_UNLOAD=y
>>  # CONFIG_ARCH_MULTI_V7 is not set
>>  CONFIG_ARCH_ASPEED=y
>>  CONFIG_MACH_ASPEED_G4=y
>> -CONFIG_DEBUG_RODATA=y
>>  CONFIG_AEABI=y
>>  CONFIG_UACCESS_WITH_MEMCPY=y
>>  CONFIG_SECCOMP=y
> 
> Are these defconfig cases correct (dropping DEBUG_RODATA without
> adding STRICT_KERNEL_RWX)?
>

Yes, I think these need to be updated to the new config option since
these are not CPUv7


> Who should carry this series, btw?
> 

An excellent question :)

Would you be willing to carry it with Acks?

> -Kees
> 

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

Re: [PATCHv2 1/2] arch: Move CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX to be common

[Laura Abbott]

On 02/03/2017 01:08 PM, Kees Cook wrote:
> On Fri, Feb 3, 2017 at 12:29 PM, Russell King - ARM Linux
>  wrote:
>> On Fri, Feb 03, 2017 at 11:45:56AM -0800, Kees Cook wrote:
>>> On Fri, Feb 3, 2017 at 9:52 AM, Laura Abbott  wrote:
 diff --git a/arch/Kconfig b/arch/Kconfig
 index 99839c2..22ee01e 100644
 --- a/arch/Kconfig
 +++ b/arch/Kconfig
 @@ -781,4 +781,32 @@ config VMAP_STACK
   the stack to map directly to the KASAN shadow map using a formula
   that is incorrect if the stack is in vmalloc space.

 +config ARCH_NO_STRICT_RWX_DEFAULTS
 +   def_bool n
 +
 +config ARCH_HAS_STRICT_KERNEL_RWX
 +   def_bool n
 +
 +config DEBUG_RODATA
 +   def_bool y if !ARCH_NO_STRICT_RWX_DEFAULTS
 +   prompt "Make kernel text and rodata read-only" if 
 ARCH_NO_STRICT_RWX_DEFAULTS
>>>
>>> Ah! Yes, perfect. I totally forgot about using conditional "prompt"
>>> lines. Nice!
>>
>> It's no different from the more usual:
>>
>> bool "Make kernel text and rodata read-only" if 
>> ARCH_NO_STRICT_RWX_DEFAULTS
>> default y if !ARCH_NO_STRICT_RWX_DEFAULTS
>> depends on ARCH_HAS_STRICT_KERNEL_RWX
>>
>> But... I really don't like this - way too many negations and negatives
>> which make it difficult to figure out what's going on here.
>>
>> The situation we have today is:
>>
>> -config DEBUG_RODATA
>> -   bool "Make kernel text and rodata read-only"
>> -   depends on MMU && !XIP_KERNEL
>> -   default y if CPU_V7
>>
>> which is "allow the user to select DEBUG_RODATA if building a MMU non-XIP
>> kernel", suggesting that the user turns it on for ARMv7 CPUs.
>>
>> That changes with this and the above:
>>
>> +   select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
>> +   select ARCH_HAS_STRICT_MODULE_RWX if MMU
>> +   select ARCH_NO_STRICT_RWX_DEFAULTS if !CPU_V7
>>
>> This means that ARCH_HAS_STRICT_KERNEL_RWX is set for a MMU non-XIP
>> kernel, which carries the same pre-condition for DEBUG_RODATA - no
>> problem there.
>>
>> However, ARCH_NO_STRICT_RWX_DEFAULTS is set for non-ARMv7 CPUs, which
>> means the "Make kernel text and rodata read-only" prompt _is_ provided
>> for those.  However, for all ARMv7 systems, we go from "suggesting that
>> the user enables the option" to "you don't have a choice, you get this
>> whether you want it or not."
>>
>> I'd prefer to keep it off for my development systems, where I don't
>> care about kernel security.  If we don't wish to do that as a general
>> rule, can we make it dependent on EMBEDDED?
>>
>> Given that on ARM it can add up to 4MB to the kernel image - there
>> _will_ be about 1MB before the .text section, the padding on between
>> __modver and __ex_table which for me is around 626k, the padding
>> between .notes and the init sections start with .vectors (the space
>> between __ex_table and end of .notes is only 4124, which gets padded
>> up to 1MB) and lastly the padding between the .init section and the
>> data section (for me around 593k).  This all adds up to an increase
>> in kernel image size of 3.2MB on 14.2MB - an increase of 22%.
>>
>> So no, I'm really not happy with that.
> 
> Ah yeah, good point. We have three cases: unsupported, mandatory,
> optional, but we have the case of setting the default for the optional
> case. Maybe something like this?
> 
> config STRICT_KERNEL_RWX
>   bool "Make kernel text and rodata read-only" if ARCH_OPTIONAL_KERNEL_RWX
>   depends on ARCH_HAS_STRICT_KERNEL_RWX
>   default ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
> 
> unsupported:
> !ARCH_HAS_STRICT_KERNEL_RWX
> 
> mandatory:
> ARCH_HAS_STRICT_KERNEL_RWX
> !ARCH_OPTIONAL_KERNEL_RWX
> 
> optional:
> ARCH_HAS_STRICT_KERNEL_RWX
> ARCH_OPTIONAL_KERNEL_RWX
> with default controlled by ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
> 
> Then arm is:
>   select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
>   select ARCH_HAS_STRICT_MODULE_RWX if MMU
>   select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
>   select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT if CPU_V7
> 
> x86 and arm64 are:
>   select ARCH_HAS_STRICT_KERNEL_RWX
>   select ARCH_HAS_STRICT_MODULE_RWX
> 
> ?
> 
> -Kees
> 

Yes, that looks good. I wanted it to be mandatory to avoid the
mindset of "optional means we don't need it" but I see there
are some cases where it's better to turn it off. I'll see if
I can emphasize this properly in the help text ("Say Y here
unless you love security exploits running in production")

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

Re: [PATCH 0/3 v2] PM / docs: linux/pm.h kerneldocs update and conversion of two docs to reST

[Jonathan Corbet]

On Thu, 02 Feb 2017 01:30:08 +0100
"Rafael J. Wysocki"  wrote:

> This is a new (and hopefully final) iteration of the series of patches 
> starting
> the conversion of power management driver API documentation.
> 
> Patch [1/3] updates kerneldoc comments in include/linux/pm.h (to make the
> documentation generated out of them look better), patch [2/3] converts
> Documentation/power/devices.txt to reST, and patch [3/3] does the same thing
> to Documentation/power/notifiers.txt (the new files go into the driver-api 
> subdir
> and are hooked up to that manual).
> 
> Patch [1/3] has not been changed since the previous iteration.  Patch [2/3]
> addresses some comments from Lukas and patch [3/3] has been trivially
> rebased.
> 
> Please apply unless there are any objections.

Just applied them, thanks.

One thing I do notice is that, while you update the kerneldoc comments,
nothing in the associated documentation pulls them in.  That would be a
good future enhancement...:)

Thanks,

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

Re: [PATCH 2/3] doc-rst: Delete output of failed dot-SVG conversion

[Jonathan Corbet]

On Sat, 04 Feb 2017 17:18:43 +0100
Ben Hutchings  wrote:

> I've now tested this, and found that dot still touches the output file
> even if it fails.  So changing to -o doesn't fix anything.
> 
> Please apply the original patch.

That has now been done.

Thanks,

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

Re: [PATCH linux v5 1/6] hwmon: Add core On-Chip Controller support for POWER CPUs

[eajames]

On 2017-02-04 17:30, Guenter Roeck wrote:

On 01/31/2017 07:43 AM, eaja...@linux.vnet.ibm.com wrote:

From: "Edward A. James" 

Add core support for polling the OCC for it's sensor data and parsing 
that

data into sensor-specific information.

Signed-off-by: Edward A. James 
Signed-off-by: Andrew Jeffery 
---
 Documentation/hwmon/occ|  40 
 MAINTAINERS|   7 +
 drivers/hwmon/Kconfig  |   2 +
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/occ/Kconfig  |  15 ++
 drivers/hwmon/occ/Makefile |   1 +
 drivers/hwmon/occ/occ.c| 470 
+

 drivers/hwmon/occ/occ.h|  80 
 drivers/hwmon/occ/scom.h   |  47 +
 9 files changed, 663 insertions(+)
 create mode 100644 Documentation/hwmon/occ
 create mode 100644 drivers/hwmon/occ/Kconfig
 create mode 100644 drivers/hwmon/occ/Makefile
 create mode 100644 drivers/hwmon/occ/occ.c
 create mode 100644 drivers/hwmon/occ/occ.h
 create mode 100644 drivers/hwmon/occ/scom.h

diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
new file mode 100644
index 000..79d1642
--- /dev/null
+++ b/Documentation/hwmon/occ
@@ -0,0 +1,40 @@
+Kernel driver occ
+=
+
+Supported chips:
+ * ASPEED AST2400
+ * ASPEED AST2500
+
+Please note that the chip must be connected to a POWER8 or POWER9 
processor

+(see the BMC - Host Communications section).
+
+Author: Eddie James 
+
+Description
+---
+
+This driver implements support for the OCC (On-Chip Controller) on 
the IBM
+POWER8 and POWER9 processors, from a BMC (Baseboard Management 
Controller). The
+OCC is an embedded processor that provides real time power and 
thermal

+monitoring.
+
+This driver provides an interface on a BMC to poll OCC sensor data, 
set user

+power caps, and perform some basic OCC error handling.
+
+Currently, all versions of the OCC support four types of sensor data: 
power,
+temperature, frequency, and "caps," which indicate limits and 
thresholds used

+internally on the OCC.
+
+BMC - Host Communications
+-
+
+For the POWER8 application, the BMC can communicate with the P8 over 
I2C bus.
+However, to access the OCC register space, any data transfer must use 
a SCOM
+operation. SCOM is a procedure to initiate a data transfer, typically 
of 8

+bytes. SCOMs consist of writing a 32-bit command register and then
+reading/writing two 32-bit data registers. This driver implements 
these

+SCOM operations over I2C bus in order to communicate with the OCC.
+
+For the POWER9 application, the BMC can communicate with the P9 over 
FSI bus
+and SBE engine. Once again, SCOM operations are required. This driver 
will

+implement SCOM ops over FSI/SBE. This will require the FSI driver.
diff --git a/MAINTAINERS b/MAINTAINERS
index 5f10c28..193a13b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9128,6 +9128,13 @@ T:   git git://linuxtv.org/media_tree.git
 S: Maintained
 F: drivers/media/i2c/ov7670.c

+ON-CHIP CONTROLLER HWMON DRIVER
+M: Eddie James 
+L: linux-hw...@vger.kernel.org
+S: Maintained
+F: Documentation/hwmon/occ
+F: drivers/hwmon/occ/
+
 ONENAND FLASH DRIVER
 M: Kyungmin Park 
 L: linux-...@lists.infradead.org
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 190d270..e80ca81 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1240,6 +1240,8 @@ config SENSORS_NSA320
  This driver can also be built as a module. If so, the module
  will be called nsa320-hwmon.

+source drivers/hwmon/occ/Kconfig
+
 config SENSORS_PCF8591
tristate "Philips PCF8591 ADC/DAC"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index d2cb7e8..c7ec5d4 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -169,6 +169,7 @@ obj-$(CONFIG_SENSORS_WM831X)+= wm831x-hwmon.o
 obj-$(CONFIG_SENSORS_WM8350)   += wm8350-hwmon.o
 obj-$(CONFIG_SENSORS_XGENE)+= xgene-hwmon.o

+obj-$(CONFIG_SENSORS_PPC_OCC)  += occ/
 obj-$(CONFIG_PMBUS)+= pmbus/

 ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
diff --git a/drivers/hwmon/occ/Kconfig b/drivers/hwmon/occ/Kconfig
new file mode 100644
index 000..cdb64a7
--- /dev/null
+++ b/drivers/hwmon/occ/Kconfig
@@ -0,0 +1,15 @@
+#
+# On Chip Controller configuration
+#
+
+menuconfig SENSORS_PPC_OCC
+   bool "PPC On-Chip Controller"
+   help
+ If you say yes here you get support to monitor Power CPU
+ sensors via the On-Chip Controller (OCC).
+
+ Generally this is used by management controllers such as a BMC
+ on an OpenPower system.
+
+ This driver can also be built as a module. If so, the module
+ will be called occ.
diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
new file mode 100644
index 000..93cb52f
--- /dev/null
+++ 

Re: [PATCH 2/2] Documentation/kconfig: add search jump feature description

[Jim Davis]

On Mon, Feb 6, 2017 at 12:46 AM,   wrote:
> From: Changbin Du 
>
> Kernel menuconfig support direct jumping function from the search
> result. This is a very convenient feature but not documented. So
> add a short description to the kconfig documentation to let more
> developer know it.
>
> Signed-off-by: Changbin Du 
> ---
>  Documentation/kbuild/kconfig.txt | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/kbuild/kconfig.txt 
> b/Documentation/kbuild/kconfig.txt
> index bbc99c0..9916318 100644
> --- a/Documentation/kbuild/kconfig.txt
> +++ b/Documentation/kbuild/kconfig.txt
> @@ -178,6 +178,10 @@ Searching in menuconfig:
> first (and in alphabetical order), then come all other symbols,
> sorted in alphabetical order.
>
> +   In the search result textbox, each symbol has a jump number on
> +   left side if the symbol is jumpable. You can type the nubmer

number  ("jumpable" reads a bit oddly, but it is understandable.)

> +   to jump to target menu to configurate that symbol.

configure?

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

Re: [PATCH 4/4] KVM: MIPS: Implement console output hypercall

[James Hogan]

On Mon, Feb 06, 2017 at 02:25:59PM +0100, Paolo Bonzini wrote:
> 
> 
> On 06/02/2017 11:46, James Hogan wrote:
> > Documentation/virtual/kvm/api.txt seems to suggest that
> > KVM_EXIT_HYPERCALL is obsolete. When it suggests using KVM_EXIT_MMIO,
> > does it simply mean the guest should use MMIO to some virtio device of
> > some sort rather than using hypercalls, or that the hypercall should
> > somehow be munged into the mmio exit information?
> 
> The former.

Okay, thanks.

> 
> But there are cases when using hypercalls is unavoidable.  In that case
> the trend is to use other exit reasons than KVM_EXIT_HYPERCALL, such as
> KVM_EXIT_PAPR_HCALL in PowerPC.  Feel free to add KVM_EXIT_MIPS_CONOUT
> or something like that.

Okay, that sounds sensible. The existing mips_paravirt_defconfig does
contain CONFIG_VIRTIO_CONSOLE=y though, so I'm thinking we may be able
to get away without this hypercall and without old paravirt guest
kernels becoming unusable.

David/Andreas: would you agree, or do you feel strongly that this
hypercall API should be kept? (with a different KVM exit reason)

> 
> How would you find the character device to write to in QEMU?

I imagine it'd need a custom character device driver in QEMU so it could
be wired up to stdio/pty or whatever using QEMU arguments. I've only
tested it with a test case in my own MIPS KVM test suite so far though.

Cheers
James


signature.asc
Description: Digital signature

Re: [PATCH 4/4] KVM: MIPS: Implement console output hypercall

[Paolo Bonzini]

On 06/02/2017 11:46, James Hogan wrote:
> Documentation/virtual/kvm/api.txt seems to suggest that
> KVM_EXIT_HYPERCALL is obsolete. When it suggests using KVM_EXIT_MMIO,
> does it simply mean the guest should use MMIO to some virtio device of
> some sort rather than using hypercalls, or that the hypercall should
> somehow be munged into the mmio exit information?

The former.

But there are cases when using hypercalls is unavoidable.  In that case
the trend is to use other exit reasons than KVM_EXIT_HYPERCALL, such as
KVM_EXIT_PAPR_HCALL in PowerPC.  Feel free to add KVM_EXIT_MIPS_CONOUT
or something like that.

How would you find the character device to write to in QEMU?

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

Re: [PATCH 2/3] doc-rst: Delete output of failed dot-SVG conversion

[Jani Nikula]

On Sat, 04 Feb 2017, Ben Hutchings  wrote:
> On Wed, 2017-02-01 at 13:20 -0700, Jonathan Corbet wrote:
>> On Tue, 31 Jan 2017 15:37:50 +
>> Ben Hutchings  wrote:
>> 
>> > > I'd just use dot -o.  
>> > 
>> > That does make more sense.  I looked for such an option before
>> > writing
>> > this, but the manual page doesn't mention it!
>> 
>> Can I get an updated patch from you?  Then I'll apply the whole
>> set...
>
> I've now tested this, and found that dot still touches the output file
> even if it fails.  So changing to -o doesn't fix anything.

Ugh. :(

> Please apply the original patch.

Ack.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] kconfig/mconf: add jumping tip in title of search result textbox

[Jani Nikula]

On Mon, 06 Feb 2017, changbin...@intel.com wrote:
> From: Changbin Du 
>
> Prompt user how to quickly jump to the item he/she is interested in.

:o

All these years. I... I didn't know. Thanks!

> Signed-off-by: Changbin Du 
> ---
>  scripts/kconfig/mconf.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
> index 315ce2c..23d5681 100644
> --- a/scripts/kconfig/mconf.c
> +++ b/scripts/kconfig/mconf.c
> @@ -443,10 +443,10 @@ static void search_conf(void)
>  
>   res = get_relations_str(sym_arr, );
>   set_subtitle();
> - dres = show_textbox_ext(_("Search Results"), (char *)
> - str_get(), 0, 0, keys, ,
> - , _text, (void *)
> - );
> + dres = show_textbox_ext(
> + _("Search Results (type the number to jump)"),
> + (char *)str_get(), 0, 0, keys, ,
> + , _text, (void *));

It would be even better and discoverable if this could be turned into a
dialog menu, so that you could navigate the search results using arrow
keys and hit enter to choose. But this is already an improvement.

>   again = false;
>   for (i = 0; i < JUMP_NB && keys[i]; i++)
>   if (dres == keys[i]) {

-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] KVM: MIPS: Implement EXIT_VM hypercall

[James Hogan]

Implement the MIPS EXIT_VM hypercall used by paravirtual guest kernels.
When the guest performs this hypercall, the request is passed to
userland in the form of a KVM_EXIT_SYSTEM_EVENT exit reason with system
event type KVM_SYSTEM_EVENT_SHUTDOWN.

We also document the hypercall along with the others as the
documentation was never added.

Signed-off-by: James Hogan 
Cc: Paolo Bonzini 
Cc: "Radim Krčmář" 
Cc: Ralf Baechle 
Cc: Andreas Herrmann 
Cc: David Daney 
Cc: Jonathan Corbet 
Cc: linux-m...@linux-mips.org
Cc: k...@vger.kernel.org
Cc: linux-doc@vger.kernel.org
---
 Documentation/virtual/kvm/hypercalls.txt |  6 ++
 arch/mips/kvm/hypcall.c  |  9 +
 2 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/Documentation/virtual/kvm/hypercalls.txt 
b/Documentation/virtual/kvm/hypercalls.txt
index e9f1c9d3da98..f8108c84c46b 100644
--- a/Documentation/virtual/kvm/hypercalls.txt
+++ b/Documentation/virtual/kvm/hypercalls.txt
@@ -92,3 +92,9 @@ is used in the hypercall for future use.
 Architecture: mips
 Status: active
 Purpose: Return the frequency of CP0_Count in HZ.
+
+7. KVM_HC_MIPS_EXIT_VM
+
+Architecture: mips
+Status: active
+Purpose: Shut down the virtual machine.
diff --git a/arch/mips/kvm/hypcall.c b/arch/mips/kvm/hypcall.c
index 7c74ec25f2b9..c3345e5eec02 100644
--- a/arch/mips/kvm/hypcall.c
+++ b/arch/mips/kvm/hypcall.c
@@ -40,6 +40,15 @@ static int kvm_mips_hypercall(struct kvm_vcpu *vcpu, 
unsigned long num,
*hret = (s32)vcpu->arch.count_hz;
break;
 
+   case KVM_HC_MIPS_EXIT_VM:
+   /* Pass shutdown system event to userland */
+   memset(>run->system_event, 0,
+  sizeof(vcpu->run->system_event));
+   vcpu->run->system_event.type = KVM_SYSTEM_EVENT_SHUTDOWN;
+   vcpu->run->exit_reason = KVM_EXIT_SYSTEM_EVENT;
+   ret = RESUME_HOST;
+   break;
+
default:
/* Report unimplemented hypercall to guest */
*hret = -KVM_ENOSYS;
-- 
git-series 0.8.10
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/4] KVM: MIPS: Hypercalls

[James Hogan]

This series implements some basic hypercalls for MIPS KVM, as used by
the MIPS paravirtual platform support in Linux and provided by Cavium's
VZ KVM implementation.

- Patch 1 hooks up trap & emulate to some minimal hypercall
  infrastructure without any hypercalls implemented yet. VZ support when
  it comes will also hook into the same infrastructure.

- Patches 2-3 implement GET_CLOCK_FREQ and EXIT_VM hypercalls.

- Patch 4 implements the console output hypercall by using
  KVM_EXIT_HYPERCALL (i.e. delegating the hypercall to userland). Its
  unclear if there is a more preferable approach to this, so comments
  particularly appreciated here.

Cc: Paolo Bonzini 
Cc: "Radim Krčmář" 
Cc: Ralf Baechle 
Cc: Andreas Herrmann 
Cc: David Daney 
Cc: Jonathan Corbet 
Cc: linux-m...@linux-mips.org
Cc: k...@vger.kernel.org
Cc: linux-doc@vger.kernel.org

James Hogan (4):
  KVM: MIPS: Implement HYPCALL emulation
  KVM: MIPS: Implement GET_CLOCK_FREQ hypercall
  KVM: MIPS: Implement EXIT_VM hypercall
  KVM: MIPS: Implement console output hypercall

 Documentation/virtual/kvm/hypercalls.txt | 27 +++-
 arch/mips/include/asm/kvm_host.h | 11 +++-
 arch/mips/include/uapi/asm/inst.h|  2 +-
 arch/mips/kvm/Makefile   |  1 +-
 arch/mips/kvm/emulate.c  |  3 +-
 arch/mips/kvm/hypcall.c  | 94 +-
 arch/mips/kvm/mips.c |  3 +-
 arch/mips/kvm/trap_emul.c|  4 +-
 8 files changed, 144 insertions(+), 1 deletion(-)
 create mode 100644 arch/mips/kvm/hypcall.c

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

[PATCH 1/4] KVM: MIPS: Implement HYPCALL emulation

[James Hogan]

Emulate the HYPCALL instruction added in the VZ ASE and used by the MIPS
paravirtualised guest support that is already merged. The new hypcall.c
handles arguments and the return value, and will handle the individual
hypercalls in upcoming commits.

Non-zero HYPCALL codes are not handled.

We also document the hypercall ABI which asm/kvm_para.h uses.

Signed-off-by: James Hogan 
Cc: Paolo Bonzini 
Cc: "Radim Krčmář" 
Cc: Ralf Baechle 
Cc: Andreas Herrmann 
Cc: David Daney 
Cc: Jonathan Corbet 
Cc: linux-m...@linux-mips.org
Cc: k...@vger.kernel.org
Cc: linux-doc@vger.kernel.org
---
 Documentation/virtual/kvm/hypercalls.txt |  5 ++-
 arch/mips/include/asm/kvm_host.h |  7 +++-
 arch/mips/include/uapi/asm/inst.h|  2 +-
 arch/mips/kvm/Makefile   |  1 +-
 arch/mips/kvm/emulate.c  |  3 +-
 arch/mips/kvm/hypcall.c  | 53 +-
 arch/mips/kvm/trap_emul.c|  4 ++-
 7 files changed, 74 insertions(+), 1 deletion(-)
 create mode 100644 arch/mips/kvm/hypcall.c

diff --git a/Documentation/virtual/kvm/hypercalls.txt 
b/Documentation/virtual/kvm/hypercalls.txt
index c8d040e27046..8f36582ce2b7 100644
--- a/Documentation/virtual/kvm/hypercalls.txt
+++ b/Documentation/virtual/kvm/hypercalls.txt
@@ -28,6 +28,11 @@ S390:
   property inside the device tree's /hypervisor node.
   For more information refer to Documentation/virtual/kvm/ppc-pv.txt
 
+MIPS:
+  KVM hypercalls use the HYPCALL instruction with code 0 and the hypercall
+  number in $2 (v0). Up to four arguments may be placed in $4-$7 (a0-a3) and
+  the return value is placed in $2 (v0).
+
 KVM Hypercalls Documentation
 ===
 The template for each hypercall is:
diff --git a/arch/mips/include/asm/kvm_host.h b/arch/mips/include/asm/kvm_host.h
index 05e785fc061d..0d308d4f2429 100644
--- a/arch/mips/include/asm/kvm_host.h
+++ b/arch/mips/include/asm/kvm_host.h
@@ -229,6 +229,7 @@ enum emulation_result {
EMULATE_WAIT,   /* WAIT instruction */
EMULATE_PRIV_FAIL,
EMULATE_EXCEPT, /* A guest exception has been generated */
+   EMULATE_HYPERCALL,  /* HYPCALL instruction */
 };
 
 #define mips3_paddr_to_tlbpfn(x) \
@@ -832,6 +833,12 @@ unsigned int kvm_mips_config3_wrmask(struct kvm_vcpu 
*vcpu);
 unsigned int kvm_mips_config4_wrmask(struct kvm_vcpu *vcpu);
 unsigned int kvm_mips_config5_wrmask(struct kvm_vcpu *vcpu);
 
+/* Hypercalls (hypcall.c) */
+
+enum emulation_result kvm_mips_emul_hypcall(struct kvm_vcpu *vcpu,
+   union mips_instruction inst);
+int kvm_mips_handle_hypcall(struct kvm_vcpu *vcpu);
+
 /* Dynamic binary translation */
 extern int kvm_mips_trans_cache_index(union mips_instruction inst,
  u32 *opc, struct kvm_vcpu *vcpu);
diff --git a/arch/mips/include/uapi/asm/inst.h 
b/arch/mips/include/uapi/asm/inst.h
index 77429d1622b3..b5e46ae872d3 100644
--- a/arch/mips/include/uapi/asm/inst.h
+++ b/arch/mips/include/uapi/asm/inst.h
@@ -179,7 +179,7 @@ enum cop0_coi_func {
tlbr_op   = 0x01, tlbwi_op  = 0x02,
tlbwr_op  = 0x06, tlbp_op   = 0x08,
rfe_op= 0x10, eret_op   = 0x18,
-   wait_op   = 0x20,
+   wait_op   = 0x20, hypcall_op= 0x28
 };
 
 /*
diff --git a/arch/mips/kvm/Makefile b/arch/mips/kvm/Makefile
index 847429de780d..e56403c8a3f5 100644
--- a/arch/mips/kvm/Makefile
+++ b/arch/mips/kvm/Makefile
@@ -10,6 +10,7 @@ common-objs-$(CONFIG_CPU_HAS_MSA) += msa.o
 kvm-objs := $(common-objs-y) mips.o emulate.o entry.o \
interrupt.o stats.o commpage.o \
dyntrans.o trap_emul.o fpu.o
+kvm-objs += hypcall.o
 kvm-objs += mmu.o
 
 obj-$(CONFIG_KVM)  += kvm.o
diff --git a/arch/mips/kvm/emulate.c b/arch/mips/kvm/emulate.c
index d40cfaad4529..637753ea0a00 100644
--- a/arch/mips/kvm/emulate.c
+++ b/arch/mips/kvm/emulate.c
@@ -1143,6 +1143,9 @@ enum emulation_result kvm_mips_emulate_CP0(union 
mips_instruction inst,
case wait_op:
er = kvm_mips_emul_wait(vcpu);
break;
+   case hypcall_op:
+   er = kvm_mips_emul_hypcall(vcpu, inst);
+   break;
}
} else {
rt = inst.c0r_format.rt;
diff --git a/arch/mips/kvm/hypcall.c b/arch/mips/kvm/hypcall.c
new file mode 100644
index ..83063435195f
--- /dev/null
+++ b/arch/mips/kvm/hypcall.c
@@ -0,0 +1,53 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * KVM/MIPS: Hypercall handling.
+ *
+ * Copyright (C) 2015  Imagination Technologies Ltd.
+ */
+

[PATCH 2/4] KVM: MIPS: Implement GET_CLOCK_FREQ hypercall

[James Hogan]

Implement the MIPS GET_CLOCK_FREQ hypercall used by paravirtual guest
kernels. When the guest performs this hypercall, the value of count_hz
is returned, which is the current rate of the CP0_Count register.

We also document the hypercall along with the others as the
documentation was never added.

Signed-off-by: James Hogan 
Cc: Paolo Bonzini 
Cc: "Radim Krčmář" 
Cc: Ralf Baechle 
Cc: Andreas Herrmann 
Cc: David Daney 
Cc: Jonathan Corbet 
Cc: linux-m...@linux-mips.org
Cc: k...@vger.kernel.org
Cc: linux-doc@vger.kernel.org
---
 Documentation/virtual/kvm/hypercalls.txt |  6 ++
 arch/mips/kvm/hypcall.c  | 18 +++---
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/Documentation/virtual/kvm/hypercalls.txt 
b/Documentation/virtual/kvm/hypercalls.txt
index 8f36582ce2b7..e9f1c9d3da98 100644
--- a/Documentation/virtual/kvm/hypercalls.txt
+++ b/Documentation/virtual/kvm/hypercalls.txt
@@ -86,3 +86,9 @@ the vcpu to sleep until occurrence of an appropriate event. 
Another vcpu of the
 same guest can wakeup the sleeping vcpu by issuing KVM_HC_KICK_CPU hypercall,
 specifying APIC ID (a1) of the vcpu to be woken up. An additional argument (a0)
 is used in the hypercall for future use.
+
+6. KVM_HC_MIPS_GET_CLOCK_FREQ
+
+Architecture: mips
+Status: active
+Purpose: Return the frequency of CP0_Count in HZ.
diff --git a/arch/mips/kvm/hypcall.c b/arch/mips/kvm/hypcall.c
index 83063435195f..7c74ec25f2b9 100644
--- a/arch/mips/kvm/hypcall.c
+++ b/arch/mips/kvm/hypcall.c
@@ -32,9 +32,21 @@ enum emulation_result kvm_mips_emul_hypcall(struct kvm_vcpu 
*vcpu,
 static int kvm_mips_hypercall(struct kvm_vcpu *vcpu, unsigned long num,
  const unsigned long *args, unsigned long *hret)
 {
-   /* Report unimplemented hypercall to guest */
-   *hret = -KVM_ENOSYS;
-   return RESUME_GUEST;
+   int ret = RESUME_GUEST;
+
+   switch (num) {
+   case KVM_HC_MIPS_GET_CLOCK_FREQ:
+   /* Return frequency of count/compare timer */
+   *hret = (s32)vcpu->arch.count_hz;
+   break;
+
+   default:
+   /* Report unimplemented hypercall to guest */
+   *hret = -KVM_ENOSYS;
+   break;
+   };
+
+   return ret;
 }
 
 int kvm_mips_handle_hypcall(struct kvm_vcpu *vcpu)
-- 
git-series 0.8.10
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] KVM: MIPS: Implement console output hypercall

[James Hogan]

Implement console output hypercall by exiting back to userland with
KVM_EXIT_HYPERCALL, and setting the return value on next KVM_RUN.

We also document the hypercall along with the others as the
documentation was never added

Signed-off-by: James Hogan 
Cc: Paolo Bonzini 
Cc: "Radim Krčmář" 
Cc: Ralf Baechle 
Cc: Andreas Herrmann 
Cc: David Daney 
Cc: Jonathan Corbet 
Cc: linux-m...@linux-mips.org
Cc: k...@vger.kernel.org
Cc: linux-doc@vger.kernel.org
---
Documentation/virtual/kvm/api.txt seems to suggest that
KVM_EXIT_HYPERCALL is obsolete. When it suggests using KVM_EXIT_MMIO,
does it simply mean the guest should use MMIO to some virtio device of
some sort rather than using hypercalls, or that the hypercall should
somehow be munged into the mmio exit information?
---
 Documentation/virtual/kvm/hypercalls.txt | 10 ++
 arch/mips/include/asm/kvm_host.h |  4 
 arch/mips/kvm/hypcall.c  | 20 
 arch/mips/kvm/mips.c |  3 +++
 4 files changed, 37 insertions(+), 0 deletions(-)

diff --git a/Documentation/virtual/kvm/hypercalls.txt 
b/Documentation/virtual/kvm/hypercalls.txt
index f8108c84c46b..4e6e57026bfe 100644
--- a/Documentation/virtual/kvm/hypercalls.txt
+++ b/Documentation/virtual/kvm/hypercalls.txt
@@ -98,3 +98,13 @@ Purpose: Return the frequency of CP0_Count in HZ.
 Architecture: mips
 Status: active
 Purpose: Shut down the virtual machine.
+
+8. KVM_HC_MIPS_CONSOLE_OUTPUT
+
+Architecture: mips
+Status: active
+Purpose: Output a string to a console.
+Argument 1 contains the virtual terminal number to write to.
+Argument 2 contains a guest virtual address pointer to the string, which must
+be in an unmapped virtual memory segment (e.g. KSeg0, KSeg1 or XKPhys).
+Argument 3 contains the number of bytes to write.
diff --git a/arch/mips/include/asm/kvm_host.h b/arch/mips/include/asm/kvm_host.h
index 0d308d4f2429..e0f1da0c35e9 100644
--- a/arch/mips/include/asm/kvm_host.h
+++ b/arch/mips/include/asm/kvm_host.h
@@ -309,6 +309,9 @@ struct kvm_vcpu_arch {
/* GPR used as IO source/target */
u32 io_gpr;
 
+   /* Whether a hypercall needs completing */
+   int hypercall_needed;
+
struct hrtimer comparecount_timer;
/* Count timer control KVM register */
u32 count_ctl;
@@ -838,6 +841,7 @@ unsigned int kvm_mips_config5_wrmask(struct kvm_vcpu *vcpu);
 enum emulation_result kvm_mips_emul_hypcall(struct kvm_vcpu *vcpu,
union mips_instruction inst);
 int kvm_mips_handle_hypcall(struct kvm_vcpu *vcpu);
+void kvm_mips_complete_hypercall(struct kvm_vcpu *vcpu, struct kvm_run *run);
 
 /* Dynamic binary translation */
 extern int kvm_mips_trans_cache_index(union mips_instruction inst,
diff --git a/arch/mips/kvm/hypcall.c b/arch/mips/kvm/hypcall.c
index c3345e5eec02..9cb8f37ca43a 100644
--- a/arch/mips/kvm/hypcall.c
+++ b/arch/mips/kvm/hypcall.c
@@ -33,6 +33,7 @@ static int kvm_mips_hypercall(struct kvm_vcpu *vcpu, unsigned 
long num,
  const unsigned long *args, unsigned long *hret)
 {
int ret = RESUME_GUEST;
+   int i;
 
switch (num) {
case KVM_HC_MIPS_GET_CLOCK_FREQ:
@@ -49,6 +50,19 @@ static int kvm_mips_hypercall(struct kvm_vcpu *vcpu, 
unsigned long num,
ret = RESUME_HOST;
break;
 
+   /* Hypercalls passed to userland to handle */
+   case KVM_HC_MIPS_CONSOLE_OUTPUT:
+   /* Pass to userland via KVM_EXIT_HYPERCALL */
+   memset(>run->hypercall, 0, sizeof(vcpu->run->hypercall));
+   vcpu->run->hypercall.nr = num;
+   for (i = 0; i < MAX_HYPCALL_ARGS; ++i)
+   vcpu->run->hypercall.args[i] = args[i];
+   vcpu->run->hypercall.ret = -KVM_ENOSYS; /* default */
+   vcpu->run->exit_reason = KVM_EXIT_HYPERCALL;
+   vcpu->arch.hypercall_needed = 1;
+   ret = RESUME_HOST;
+   break;
+
default:
/* Report unimplemented hypercall to guest */
*hret = -KVM_ENOSYS;
@@ -72,3 +86,9 @@ int kvm_mips_handle_hypcall(struct kvm_vcpu *vcpu)
return kvm_mips_hypercall(vcpu, num,
  args, >arch.gprs[2] /* v0 */);
 }
+
+void kvm_mips_complete_hypercall(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+   vcpu->arch.gprs[2] = run->hypercall.ret;/* v0 */
+   vcpu->arch.hypercall_needed = 0;
+}
diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
index 31ee5ee0010b..1c23dc29db5d 100644
--- a/arch/mips/kvm/mips.c
+++ b/arch/mips/kvm/mips.c
@@ -409,6 +409,9 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct 
kvm_run *run)
vcpu->mmio_needed = 0;
}
 
+   if