Re: [PATCHv2 1/2] arch: Move CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX to be common
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 advertising for your favourite feature.
Re: [PATCHv3 1/2] arch: Move CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX to be common
* 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
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, &head); > > set_subtitle(); > > - dres = show_textbox_ext(_("Search Results"), (char *) > > - str_get(&res), 0, 0, keys, &vscroll, > > - &hscroll, &update_text, (void *) > > - &data); > > + dres = show_textbox_ext( > > + _("Search Results (type the number to jump)"), > > + (char *)str_get(&res), 0, 0, keys, &vscroll, > > + &hscroll, &update_text, (void *)&data); > > 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
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
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 @@ CONFIG_MODULE_UNLOAD=y # CONFIG_ARCH_MULT
[PATCHv3 0/2] Hardening configs refactor/rename
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
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 switch. Say Y here only
Re: [PATCH linux v6 1/6] hwmon: Add core On-Chip Controller support for POWER CPUs
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 = &driver->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
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? > > &i2c0 { > mux: mux-controller@50 { > compatible = "adi,adg792a"; > reg = <0x50>; > #mux-control-cells = <1>; > }; > }; > > adc-mux { > compatible = "io-channel-mux"; > io-channels = <&adc 0>; > io-channel-names = "parent"; > > mux-controls = <&mux 0>; > > ... > }; > > i2c-mux-foo { > compatible = "i2c-mux-gpio"; > i2c-parent = <&i2c1>; > > mux-controls = <&mux 1>; > > ... > }; > > i2c-mux-bar { > compatible = "i2c-mux-gpio"; > i2c-parent = <&i2c1>; > > mux-controls = <&mux 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
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
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 *sensor_hwmon_configs; + struct hwmon_channel_info **occ_sensors
[PATCH linux v6 4/6] hwmon: occ: Add callbacks for parsing P8 OCC datastructures
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 *)&data[off])); + os->value = be16_to_cpu(get_unaligned((u16 *)&data[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 *)&data[off])); + ps->update_tag = + be32_to_cpu(get_unaligned((u32 *)&data[off + 2])); + ps->accumulator = + be32_to_cpu(get_unaligned((u32 *)&data[off + 6])); + ps->value = be16_to_cpu(get_unaligned((u16 *)&data[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 *)&data[off])); + cs->curr_powerreading = + be16_to_cpu(get_unaligned((u16 *)&data[off + 2])); + cs->norm_powercap = + be16_to_cpu(get_unaligned((u16 *)&data[off + 4])); + cs->max_powercap = + be16_
[PATCH linux v6 6/6] hwmon: occ: Add callbacks for parsing P9 OCC datastructures
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 *)&data[off])); + fs->value = be16_to_cpu(get_unaligned((u16 *)&data[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 *)&data[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 *)&data[off])); + ps->function_id = data[off + 4]; + ps->apss_channel = data[off + 5]; + ps->update_tag = + be32_to_cpu(get_unaligned((u32 *)&data[off + 8])); + ps->accumulator = + be64_to_cpu(get_unaligned((u64 *)&data[off + 12])); + ps->value = be16_to_cpu(get_unaligned((u16 *)&data[off + 20])); + } + break; + case CAPS: + { + struct p9_caps_sensor *cs = +
[PATCH linux v6 3/6] hwmon: occ: Add I2C transport implementation for SCOM operations
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 *)&address; + + 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 *)&buf; + + 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
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
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(&client->dev, client, &p8_bus_ops); + if (IS_ERR(occ)) + return PTR_ERR(occ); + + hwmon = occ_sysfs_start(&client->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 = { + .class = I2C_CLASS_HWMON, + .driver = { +
[PATCH linux v6 1/6] hwmon: Add core On-Chip Controller support for POWER CPUs
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 b/drivers/hwmon/occ/occ.c new file mode 100644 index 000..06e4bde --- /dev/null +++ b/drivers/hwmon/occ/occ.c @@ -0,0 +1,450
Re: [PATCHv2 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX
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
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
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
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
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
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 +++ b/drivers/hwmon/occ/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_SENSORS_PPC_OCC) += occ.o diff --git a/drivers/hwmon/occ/occ.c b/driv
Re: [PATCH 2/2] Documentation/kconfig: add search jump feature description
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
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
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
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
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, &head); > set_subtitle(); > - dres = show_textbox_ext(_("Search Results"), (char *) > - str_get(&res), 0, 0, keys, &vscroll, > - &hscroll, &update_text, (void *) > - &data); > + dres = show_textbox_ext( > + _("Search Results (type the number to jump)"), > + (char *)str_get(&res), 0, 0, keys, &vscroll, > + &hscroll, &update_text, (void *)&data); 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
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(&vcpu->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
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
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. + */ + +#include +#include +#include + +#define MAX_HYPCALL_ARGS 4 + +enum emulation_result kvm_mips_emul_hypcall(struct kvm_vcpu *vcpu, +
[PATCH 2/4] KVM: MIPS: Implement GET_CLOCK_FREQ hypercall
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
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(&vcpu->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, &vcpu->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 (vcpu->arch.hypercall_needed) + kvm_mips_complete_hypercall(vcpu, run); + lose_fpu(1); local_irq_disable(); -- git-serie
Re: [PATCH] Add 'nodoc' option
On Fri, 03 Feb 2017, Matthew Wilcox wrote: > I've written this patch, and it seems to work, but I don't really know > what I'm doing and I fear I may have broken something. I don't know what: > > required_argument = 1 > optional_arguments = 4 > > mean, so I don't know whether I should have adjusted them when adding > this new option. Apparently neither did I when I added them. I think optional_arguments should be 0 for the kernel-doc directive. > From 26896bd43618e30cb3563114663ad6c39cef7dc6 Mon Sep 17 00:00:00 2001 > From: Matthew Wilcox > Date: Thu, 26 Jan 2017 11:43:24 -0500 > Subject: [PATCH] kerneldoc: Add :nodoc: option > > This is functionality the perl script already has, we just need to > expose it to our rst files. > --- > Documentation/sphinx/kerneldoc.py | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/sphinx/kerneldoc.py > b/Documentation/sphinx/kerneldoc.py > index d15e07f36881..d86d88da1d75 100644 > --- a/Documentation/sphinx/kerneldoc.py > +++ b/Documentation/sphinx/kerneldoc.py > @@ -47,6 +47,7 @@ class KernelDocDirective(Directive): > optional_arguments = 4 > option_spec = { > 'doc': directives.unchanged_required, > +'nodoc': directives.unchanged, The commit message lacks the all important answer to *why* this is needed. What's the use case? (I can guess, but I'd like it to be spelled out, please.) Generally I'd prefer hiding kernel-doc the script interface from kernel-doc the directive. I think I already made a mistake by leaking the script -function argument to the directive; perhaps e.g. "symbols" would have been better than "functions", because you can use the "functions" directive option to choose e.g. structs too. With that, I think I would have preferred having "symbols" *without* specific symbols listed equal your "nodoc". Perhaps overloading "functions" for this is too confusing? We could easily add e.g. "symbols" as a synonym for "functions", and still make this so, but is it worth it? BR, Jani. > 'functions': directives.unchanged_required, > 'export': directives.unchanged, > 'internal': directives.unchanged, > @@ -74,6 +75,8 @@ class KernelDocDirective(Directive): > export_file_patterns = str(self.options.get('internal')).split() > elif 'doc' in self.options: > cmd += ['-function', str(self.options.get('doc'))] > +elif 'nodoc' in self.options: > +cmd += ['-no-doc-sections'] > elif 'functions' in self.options: > for f in str(self.options.get('functions')).split(): > cmd += ['-function', f] -- 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