Re: [PATCH 3/3] Documentation for the GCC plugin infrastructure

[Kees Cook]

On Sun, Feb 7, 2016 at 1:32 PM, Emese Revfy  wrote:
> This is the GCC infrastructure documentation about its operation, how to add
> and use a new plugin with an example.
>
> ---
>  Documentation/example_gcc_plugin.c | 103 
> +

Perhaps this example should live in samples/gcc_plugin/ ?

>  Documentation/gcc-plugins.txt  |  76 +++
>  2 files changed, 179 insertions(+)
>  create mode 100644 Documentation/example_gcc_plugin.c
>  create mode 100644 Documentation/gcc-plugins.txt
>
> diff --git a/Documentation/example_gcc_plugin.c 
> b/Documentation/example_gcc_plugin.c
> new file mode 100644
> index 000..950ff78
> --- /dev/null
> +++ b/Documentation/example_gcc_plugin.c
> @@ -0,0 +1,103 @@
> +/*
> + * Copyright 2011-2016 by Emese Revfy 
> + * Licensed under the GPL v2, or (at your option) v3
> + */
> +
> +#include "gcc-common.h"
> +
> +int plugin_is_GPL_compatible;
> +
> +static struct plugin_info example_plugin_info = {
> +   .version= "0",
> +   .help   = "example plugin\n",
> +};
> +
> +static unsigned int handle_function(void)
> +{
> +   gimple_stmt_iterator gsi;
> +   basic_block bb;
> +
> +   FOR_ALL_BB_FN(bb, cfun) {
> +   for (gsi = gsi_start_bb(bb); !gsi_end_p(gsi); gsi_next(&gsi))
> +   debug_gimple_stmt(gsi_stmt(gsi));
> +   }
> +   return 0;
> +}
> +
> +#if BUILDING_GCC_VERSION >= 4009
> +namespace {
> +static const struct pass_data example_plugin_pass_data = {
> +#else
> +static struct gimple_opt_pass example_plugin_pass = {
> +   .pass = {
> +#endif
> +   .type   = GIMPLE_PASS,
> +   .name   = "example_plugin",
> +#if BUILDING_GCC_VERSION >= 4008
> +   .optinfo_flags  = OPTGROUP_NONE,
> +#endif
> +#if BUILDING_GCC_VERSION >= 5000
> +#elif BUILDING_GCC_VERSION >= 4009
> +   .has_gate   = false,
> +   .has_execute= true,
> +#else
> +   .gate   = NULL,
> +   .execute= handle_function,
> +   .sub= NULL,
> +   .next   = NULL,
> +   .static_pass_number = 0,
> +#endif
> +   .tv_id  = TV_NONE,
> +   .properties_required= 0,
> +   .properties_provided= 0,
> +   .properties_destroyed   = 0,
> +   .todo_flags_start   = 0,
> +   .todo_flags_finish  = TODO_dump_func
> +#if BUILDING_GCC_VERSION < 4009
> +   }
> +#endif
> +};
> +
> +#if BUILDING_GCC_VERSION >= 4009
> +class example_plugin_pass : public gimple_opt_pass {
> +public:
> +   example_plugin_pass() : gimple_opt_pass(example_plugin_pass_data, g) 
> {}
> +#if BUILDING_GCC_VERSION >= 5000
> +   virtual unsigned int execute(function *) { return handle_function(); }
> +#else
> +   unsigned int execute() { return handle_function(); }
> +#endif
> +};
> +}
> +
> +static opt_pass *make_example_plugin_pass(void)
> +{
> +   return new example_plugin_pass();
> +}
> +#else
> +static struct opt_pass *make_example_plugin_pass(void)
> +{
> +   return &example_plugin_pass.pass;
> +}
> +#endif
> +
> +int plugin_init(struct plugin_name_args *plugin_info, struct 
> plugin_gcc_version *version)
> +{
> +   const char * const plugin_name = plugin_info->base_name;
> +   struct register_pass_info example_plugin_pass_info;
> +
> +   example_plugin_pass_info.pass   = 
> make_example_plugin_pass();
> +   example_plugin_pass_info.reference_pass_name= "ssa";
> +   example_plugin_pass_info.ref_pass_instance_number   = 1;
> +   example_plugin_pass_info.pos_op = 
> PASS_POS_INSERT_AFTER;
> +
> +   if (!plugin_default_version_check(version, &gcc_version)) {
> +   error(G_("incompatible gcc/plugin versions"));
> +   return 1;
> +   }
> +
> +   register_callback(plugin_name, PLUGIN_INFO, NULL, 
> &example_plugin_info);
> +   register_callback(plugin_name, PLUGIN_PASS_MANAGER_SETUP, NULL, 
> &example_plugin_pass_info);
> +
> +   return 0;
> +}

For an example, I'd expect verbose comments. :) Imagine someone
reading it who knows very little about plugins or compiler internals.

> diff --git a/Documentation/gcc-plugins.txt b/Documentation/gcc-plugins.txt
> new file mode 100644
> index 000..e669d83
> --- /dev/null
> +++ b/Documentation/gcc-plugins.txt
> @@ -0,0 +1,76 @@
> +GCC plugin infrastructure
> +=
> +
> +
> +1. Introduction
> +===
> +
> +GCC plugins are loadable modules that provide extra features to the
> +compiler [1]. They are useful for runtime instrumentation and static 
> analysis.
> +We can analyse, change and add further code during compilation via
> +callbacks [2], GIMPLE [3], IPA [4] a

Re: [PATCH 8/9] rfkill: Userspace control for airplane mode

[Julian Calaby]

Hi João,

On Tue, Feb 9, 2016 at 2:41 AM, João Paulo Rechi Vita  wrote:
> Provide an interface for the airplane-mode indicator be controlled from
> userspace. User has to first acquire the control through
> RFKILL_OP_AIRPLANE_MODE_ACQUIRE and keep the fd open for the whole time
> it wants to be in control of the indicator. Closing the fd or using
> RFKILL_OP_AIRPLANE_MODE_RELEASE restores the default policy.
>
> To change state of the indicator, the RFKILL_OP_AIRPLANE_MODE_CHANGE
> operation is used, passing the value on "struct rfkill_event.soft". If
> the caller has not acquired the airplane-mode control beforehand, the
> operation fails.
>
> Signed-off-by: João Paulo Rechi Vita 
> ---
>  Documentation/rfkill.txt| 10 ++
>  include/uapi/linux/rfkill.h |  3 +++
>  net/rfkill/core.c   | 47 
> ++---
>  3 files changed, 57 insertions(+), 3 deletions(-)
>
> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> index fb11547..8067701 100644
> --- a/net/rfkill/core.c
> +++ b/net/rfkill/core.c
> @@ -1207,6 +1210,34 @@ static ssize_t rfkill_fop_write(struct file *file, 
> const char __user *buf,
>
> mutex_lock(&rfkill_global_mutex);
>
> +   if (ev.op == RFKILL_OP_AIRPLANE_MODE_ACQUIRE) {
> +   if (rfkill_apm_owned && !data->is_apm_owner) {
> +   count = -EACCES;
> +   } else {
> +   rfkill_apm_owned = true;
> +   data->is_apm_owner = true;
> +   }
> +   }
> +
> +   if (ev.op == RFKILL_OP_AIRPLANE_MODE_RELEASE) {
> +   if (rfkill_apm_owned && !data->is_apm_owner) {

Are you sure this is correct?

In the case that airplane mode isn't owned, the
rfkill_apm_led_trigger_event() call will be a noop, so we should
arguably not be calling it.

Also, should we just fail silently if we're not the owner? I.e. what
does userspace learn from this op failing and is that useful?

> +   count = -EACCES;
> +   } else {
> +   bool state = 
> rfkill_global_states[RFKILL_TYPE_ALL].cur;
> +
> +   rfkill_apm_owned = false;
> +   data->is_apm_owner = false;
> +   rfkill_apm_led_trigger_event(state);
> +   }
> +   }
> +
> +   if (ev.op == RFKILL_OP_AIRPLANE_MODE_CHANGE) {
> +   if (rfkill_apm_owned && data->is_apm_owner)
> +   rfkill_apm_led_trigger_event(ev.soft);
> +   else
> +   count = -EACCES;
> +   }
> +
> if (ev.op == RFKILL_OP_CHANGE_ALL)
> rfkill_update_global_state(ev.type, ev.soft);
>
> @@ -1230,7 +1261,17 @@ static int rfkill_fop_release(struct inode *inode, 
> struct file *file)
> struct rfkill_int_event *ev, *tmp;
>
> mutex_lock(&rfkill_global_mutex);
> +
> +   if (data->is_apm_owner) {
> +   bool state = rfkill_global_states[RFKILL_TYPE_ALL].cur;
> +
> +   rfkill_apm_owned = false;
> +   data->is_apm_owner = false;
> +   rfkill_apm_led_trigger_event(state);

Also, this code is duplicated from the _RELEASE op above. Would it
make sense to factor it out into a separate function?

> +   }
> +
> list_del(&data->list);
> +

(extra line)

> mutex_unlock(&rfkill_global_mutex);
>
> mutex_destroy(&data->mtx);

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
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 5/9] rfkill: Factor rfkill_global_states[].cur assignments

[Julian Calaby]

Hi João,

On Tue, Feb 9, 2016 at 2:41 AM, João Paulo Rechi Vita  wrote:
> Factor all assignments to rfkill_global_states[].cur into a single
> function rfkill_update_global_state().
>
> Signed-off-by: João Paulo Rechi Vita 

Looks sane to me.

Reviewed-by: Julian Calaby 

> ---
>  net/rfkill/core.c | 38 +-
>  1 file changed, 17 insertions(+), 21 deletions(-)
>
> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> index 56d79cb..8b96869 100644
> --- a/net/rfkill/core.c
> +++ b/net/rfkill/core.c
> @@ -302,6 +302,19 @@ static void rfkill_set_block(struct rfkill *rfkill, bool 
> blocked)
> rfkill_event(rfkill);
>  }
>
> +static void rfkill_update_global_state(enum rfkill_type type, bool blocked)
> +{
> +   int i;
> +
> +   if (type != RFKILL_TYPE_ALL) {
> +   rfkill_global_states[type].cur = blocked;
> +   return;
> +   }
> +
> +   for (i = 0; i < NUM_RFKILL_TYPES; i++)
> +   rfkill_global_states[i].cur = blocked;
> +}
> +
>  #ifdef CONFIG_RFKILL_INPUT
>  static atomic_t rfkill_input_disabled = ATOMIC_INIT(0);
>
> @@ -319,15 +332,7 @@ static void __rfkill_switch_all(const enum rfkill_type 
> type, bool blocked)
>  {
> struct rfkill *rfkill;
>
> -   if (type == RFKILL_TYPE_ALL) {
> -   int i;
> -
> -   for (i = 0; i < NUM_RFKILL_TYPES; i++)
> -   rfkill_global_states[i].cur = blocked;
> -   } else {
> -   rfkill_global_states[type].cur = blocked;
> -   }
> -
> +   rfkill_update_global_state(type, blocked);
> list_for_each_entry(rfkill, &rfkill_list, node) {
> if (rfkill->type != type && type != RFKILL_TYPE_ALL)
> continue;
> @@ -1164,15 +1169,8 @@ static ssize_t rfkill_fop_write(struct file *file, 
> const char __user *buf,
>
> mutex_lock(&rfkill_global_mutex);
>
> -   if (ev.op == RFKILL_OP_CHANGE_ALL) {
> -   if (ev.type == RFKILL_TYPE_ALL) {
> -   enum rfkill_type i;
> -   for (i = 0; i < NUM_RFKILL_TYPES; i++)
> -   rfkill_global_states[i].cur = ev.soft;
> -   } else {
> -   rfkill_global_states[ev.type].cur = ev.soft;
> -   }
> -   }
> +   if (ev.op == RFKILL_OP_CHANGE_ALL)
> +   rfkill_update_global_state(ev.type, ev.soft);
>
> list_for_each_entry(rfkill, &rfkill_list, node) {
> if (rfkill->idx != ev.idx && ev.op != RFKILL_OP_CHANGE_ALL)
> @@ -1261,10 +1259,8 @@ static struct miscdevice rfkill_miscdev = {
>  static int __init rfkill_init(void)
>  {
> int error;
> -   int i;
>
> -   for (i = 0; i < NUM_RFKILL_TYPES; i++)
> -   rfkill_global_states[i].cur = !rfkill_default_state;
> +   rfkill_update_global_state(RFKILL_TYPE_ALL, !rfkill_default_state);
>
> error = class_register(&rfkill_class);
> if (error)
> --
> 2.5.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
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 3/9] rfkill: Point to the correct deprecated doc location

[Julian Calaby]

Hi João,

On Tue, Feb 9, 2016 at 2:41 AM, João Paulo Rechi Vita  wrote:
> The "claim" sysfs interface has been removed, so its documentation now
> lives in the "removed" folder.
>
> Signed-off-by: João Paulo Rechi Vita 

Looks right to me.

Reviewed-by: Julian Calaby 

> ---
>  Documentation/ABI/stable/sysfs-class-rfkill | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/ABI/stable/sysfs-class-rfkill 
> b/Documentation/ABI/stable/sysfs-class-rfkill
> index 097f522..e51571e 100644
> --- a/Documentation/ABI/stable/sysfs-class-rfkill
> +++ b/Documentation/ABI/stable/sysfs-class-rfkill
> @@ -2,8 +2,10 @@ rfkill - radio frequency (RF) connector kill switch support
>
>  For details to this subsystem look at Documentation/rfkill.txt.
>
> -For the deprecated /sys/class/rfkill/*/state and
> -/sys/class/rfkill/*/claim knobs of this interface look in
> +For the deprecated /sys/class/rfkill/*/claim knobs of this interface look in
> +Documentation/ABI/removed/sysfs-class-rfkill.
> +
> +For the deprecated /sys/class/rfkill/*/state knobs of this interface look in
>  Documentation/ABI/obsolete/sysfs-class-rfkill.
>
>  What:  /sys/class/rfkill
> --
> 2.5.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
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/9] rfkill: Remove extra blank line

[Julian Calaby]

Hi João,

On Tue, Feb 9, 2016 at 2:41 AM, João Paulo Rechi Vita  wrote:
> Signed-off-by: João Paulo Rechi Vita 

Looks sane to me.

Reviewed-by: Julian Calaby 

> ---
>  net/rfkill/core.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> index ffbc375..56d79cb 100644
> --- a/net/rfkill/core.c
> +++ b/net/rfkill/core.c
> @@ -455,7 +455,6 @@ bool rfkill_get_global_sw_state(const enum rfkill_type 
> type)
>  }
>  #endif
>
> -
>  bool rfkill_set_hw_state(struct rfkill *rfkill, bool blocked)
>  {
> unsigned long flags;
> --
> 2.5.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
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/9] rfkill: Improve documentation language

[Julian Calaby]

Hi João,

On Tue, Feb 9, 2016 at 2:41 AM, João Paulo Rechi Vita  wrote:
> Signed-off-by: João Paulo Rechi Vita 

Looks right to me.

Reviewed-by: Julian Calaby 

> ---
>  net/rfkill/core.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> index a805831..ffbc375 100644
> --- a/net/rfkill/core.c
> +++ b/net/rfkill/core.c
> @@ -282,8 +282,8 @@ static void rfkill_set_block(struct rfkill *rfkill, bool 
> blocked)
> spin_lock_irqsave(&rfkill->lock, flags);
> if (err) {
> /*
> -* Failed -- reset status to _prev, this may be different
> -* from what set set _PREV to earlier in this function
> +* Failed -- reset status to _PREV, which may be different
> +* from what we have set _PREV to earlier in this function
>  * if rfkill_set_sw_state was invoked.
>  */
> if (rfkill->state & RFKILL_BLOCK_SW_PREV)
> --
> 2.5.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
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: module: preserve Elf information for livepatch modules

[Jessica Yu]

+++ Josh Poimboeuf [08/02/16 14:10 -0600]:

On Wed, Feb 03, 2016 at 08:11:07PM -0500, Jessica Yu wrote:

For livepatch modules, copy Elf section, symbol, and string information
from the load_info struct in the module loader. Persist copies of the
original symbol table and string table.

Livepatch manages its own relocation sections in order to reuse module
loader code to write relocations. Livepatch modules must preserve Elf
information such as section indices in order to apply livepatch relocation
sections using the module loader's apply_relocate_add() function.

In order to apply livepatch relocation sections, livepatch modules must
keep a complete copy of their original symbol table in memory. Normally, a
stripped down copy of a module's symbol table (containing only "core"
symbols) is made available through module->core_symtab. But for livepatch
modules, the symbol table copied into memory on module load must be exactly
the same as the symbol table produced when the patch module was compiled.
This is because the relocations in each livepatch relocation section refer
to their respective symbols with their symbol indices, and the original
symbol indices (and thus the symtab ordering) must be preserved in order
for apply_relocate_add() to find the right symbol.


This patch didn't apply clean to linux-next/master.  I didn't
investigate why, but maybe it depends on the other patch set which
removes the notifiers?  (If so, that should be mentioned in the cover
letter.)


A very recent commit (8244062ef) introduced some changes
kernel/module.c that intersect with this patch, so I think this is why
the patch didn't apply cleanly to today's tree...Anyhow I will rebase
again before sending out v5. Thanks for the comments :-)

Jessica
--
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: [RFC PATCH v4 0/6] (mostly) Arch-independent livepatch

[Josh Poimboeuf]

On Mon, Feb 08, 2016 at 03:54:22PM +0100, Miroslav Benes wrote:
> On Wed, 3 Feb 2016, Jessica Yu wrote:
> 
> > Jessica Yu (6):
> >   Elf: add livepatch-specific Elf constants
> >   module: preserve Elf information for livepatch modules
> >   module: s390: keep mod_arch_specific for livepatch modules
> >   livepatch: reuse module loader code to write relocations
> >   samples: livepatch: mark as livepatch module
> >   Documentation: livepatch: outline Elf format and requirements for
> > patch modules
> 
> Hi,
> 
> I walked through the code and it looks good except for several minor 
> things in the fourth patch (livepatch: reuse module loader code to write 
> relocations). I'd propose to send the next version as a regular PATCH set 
> and not RFC. We can start collecting Reviews and Acks. Hopefully it won't 
> take more than one or two iterations. Would that be ok with everyone?

Sounds good to me...

-- 
Josh
--
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: [RFC PATCH v4 4/6] livepatch: reuse module loader code to write relocations

[Josh Poimboeuf]

On Wed, Feb 03, 2016 at 08:11:09PM -0500, Jessica Yu wrote:
> Reuse module loader code to write relocations, thereby eliminating the need
> for architecture specific relocation code in livepatch. Specifically, reuse
> the apply_relocate_add() function in the module loader to write relocations
> instead of duplicating functionality in livepatch's arch-dependent
> klp_write_module_reloc() function.
> 
> In order to accomplish this, livepatch modules manage their own relocation
> sections (marked with the SHF_RELA_LIVEPATCH section flag) and
> livepatch-specific symbols (marked with SHN_LIVEPATCH symbol section
> index). To apply livepatch relocation sections, livepatch symbols
> referenced by relocs are resolved and then apply_relocate_add() is called
> to apply those relocations.
> 
> In addition, remove x86 livepatch relocation code and the s390
> klp_write_module_reloc() function stub. They are no longer needed since
> relocation work has been offloaded to module loader.
> 
> Signed-off-by: Jessica Yu 
> ---
>  arch/s390/include/asm/livepatch.h |   7 -
>  arch/x86/include/asm/livepatch.h  |   2 -
>  arch/x86/kernel/Makefile  |   1 -
>  arch/x86/kernel/livepatch.c   |  70 --
>  include/linux/livepatch.h |  30 ++--
>  kernel/livepatch/core.c   | 283 
> ++
>  6 files changed, 238 insertions(+), 155 deletions(-)
>  delete mode 100644 arch/x86/kernel/livepatch.c
> 
> diff --git a/arch/s390/include/asm/livepatch.h 
> b/arch/s390/include/asm/livepatch.h
> index a52b6cc..350a751 100644
> --- a/arch/s390/include/asm/livepatch.h
> +++ b/arch/s390/include/asm/livepatch.h
> @@ -25,13 +25,6 @@ static inline int klp_check_compiler_support(void)
>   return 0;
>  }
>  
> -static inline int klp_write_module_reloc(struct module *mod, unsigned long
> - type, unsigned long loc, unsigned long value)
> -{
> - /* not supported yet */
> - return -ENOSYS;
> -}
> -
>  static inline void klp_arch_set_pc(struct pt_regs *regs, unsigned long ip)
>  {
>   regs->psw.addr = ip;
> diff --git a/arch/x86/include/asm/livepatch.h 
> b/arch/x86/include/asm/livepatch.h
> index e795f52..d7c2b57 100644
> --- a/arch/x86/include/asm/livepatch.h
> +++ b/arch/x86/include/asm/livepatch.h
> @@ -33,8 +33,6 @@ static inline int klp_check_compiler_support(void)
>  #endif
>   return 0;
>  }
> -int klp_write_module_reloc(struct module *mod, unsigned long type,
> -unsigned long loc, unsigned long value);
>  
>  static inline void klp_arch_set_pc(struct pt_regs *regs, unsigned long ip)
>  {
> diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
> index b1b78ff..c5e9a5c 100644
> --- a/arch/x86/kernel/Makefile
> +++ b/arch/x86/kernel/Makefile
> @@ -67,7 +67,6 @@ obj-$(CONFIG_X86_MPPARSE)   += mpparse.o
>  obj-y+= apic/
>  obj-$(CONFIG_X86_REBOOTFIXUPS)   += reboot_fixups_32.o
>  obj-$(CONFIG_DYNAMIC_FTRACE) += ftrace.o
> -obj-$(CONFIG_LIVEPATCH)  += livepatch.o
>  obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o
>  obj-$(CONFIG_FTRACE_SYSCALLS)+= ftrace.o
>  obj-$(CONFIG_X86_TSC)+= trace_clock.o
> diff --git a/arch/x86/kernel/livepatch.c b/arch/x86/kernel/livepatch.c
> deleted file mode 100644
> index 92fc1a5..000
> --- a/arch/x86/kernel/livepatch.c
> +++ /dev/null
> @@ -1,70 +0,0 @@
> -/*
> - * livepatch.c - x86-specific Kernel Live Patching Core
> - *
> - * Copyright (C) 2014 Seth Jennings 
> - * Copyright (C) 2014 SUSE
> - *
> - * 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.
> - *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, see .
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -/**
> - * klp_write_module_reloc() - write a relocation in a module
> - * @mod: module in which the section to be modified is found
> - * @type:ELF relocation type (see asm/elf.h)
> - * @loc: address that the relocation should be written to
> - * @value:   relocation value (sym address + addend)
> - *
> - * This function writes a relocation to the specified location for
> - * a particular module.
> - */
> -int klp_write_module_reloc(struct module *mod, unsigned long type,
> -unsigned long loc, unsigned long value)
> -{
> - size_t size = 4;
> - unsigned long val;
> - unsigned long core = (unsigned long)mod->core_layout.base;
> - unsigned lo

Re: [PATCH v4 01/11] drm/hisilicon: Add device tree binding for hi6220 display subsystem

[Rob Herring]

On Sat, Feb 06, 2016 at 11:24:48AM +0800, Xinliang Liu wrote:
> Add ADE display controller binding doc.
> Add DesignWare DSI Host Controller v1.20a binding doc.

One comment, otherwise:

Acked-by: Rob Herring 

> +Board specific:
> + &dsi {
> + status = "ok";
> +
> + ports {
> + /* 1 for output port */
> + port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + /* 0 for bridge, other value for panel */

The endpoint address would not change based on bridge or panel. So you 
can drop the unit address here.

> + dsi_out0: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&adv7533_in>;
> + };
> + };
> + };
> + };
--
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: [RFC PATCH v4 2/6] module: preserve Elf information for livepatch modules

[Josh Poimboeuf]

On Wed, Feb 03, 2016 at 08:11:07PM -0500, Jessica Yu wrote:
> For livepatch modules, copy Elf section, symbol, and string information
> from the load_info struct in the module loader. Persist copies of the
> original symbol table and string table.
> 
> Livepatch manages its own relocation sections in order to reuse module
> loader code to write relocations. Livepatch modules must preserve Elf
> information such as section indices in order to apply livepatch relocation
> sections using the module loader's apply_relocate_add() function.
> 
> In order to apply livepatch relocation sections, livepatch modules must
> keep a complete copy of their original symbol table in memory. Normally, a
> stripped down copy of a module's symbol table (containing only "core"
> symbols) is made available through module->core_symtab. But for livepatch
> modules, the symbol table copied into memory on module load must be exactly
> the same as the symbol table produced when the patch module was compiled.
> This is because the relocations in each livepatch relocation section refer
> to their respective symbols with their symbol indices, and the original
> symbol indices (and thus the symtab ordering) must be preserved in order
> for apply_relocate_add() to find the right symbol.

This patch didn't apply clean to linux-next/master.  I didn't
investigate why, but maybe it depends on the other patch set which
removes the notifiers?  (If so, that should be mentioned in the cover
letter.)

A couple of minor comments below...

> Signed-off-by: Jessica Yu 
> ---
>  include/linux/module.h |  25 ++
>  kernel/module.c| 133 
> ++---
>  2 files changed, 151 insertions(+), 7 deletions(-)
> 
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 4560d8f..58e6200 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -324,6 +324,15 @@ struct module_layout {
>  #define __module_layout_align
>  #endif
>  
> +#ifdef CONFIG_LIVEPATCH
> +struct klp_modinfo {
> + Elf_Ehdr hdr;
> + Elf_Shdr *sechdrs;
> + char *secstrings;
> + unsigned int symndx;
> +};
> +#endif
> +
>  struct module {
>   enum module_state state;
>  
> @@ -455,7 +464,11 @@ struct module {
>  #endif
>  
>  #ifdef CONFIG_LIVEPATCH
> + bool klp; /* Is this a livepatch module? */
>   bool klp_alive;
> +
> + /* Elf information */
> + struct klp_modinfo *klp_info;
>  #endif
>  
>  #ifdef CONFIG_MODULE_UNLOAD
> @@ -629,6 +642,18 @@ static inline bool module_requested_async_probing(struct 
> module *module)
>   return module && module->async_probe_requested;
>  }
>  
> +#ifdef CONFIG_LIVEPATCH
> +static inline bool is_livepatch_module(struct module *mod)
> +{
> + return mod->klp;
> +}
> +#else /* !CONFIG_LIVEPATCH */
> +static inline bool is_livepatch_module(struct module *mod)
> +{
> + return false;
> +}
> +#endif /* CONFIG_LIVEPATCH */
> +
>  #else /* !CONFIG_MODULES... */
>  
>  /* Given an address, look for it in the exception tables. */
> diff --git a/kernel/module.c b/kernel/module.c
> index 71c77ed..9c16eb2 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -1970,6 +1970,82 @@ static void module_enable_nx(const struct module *mod) 
> { }
>  static void module_disable_nx(const struct module *mod) { }
>  #endif
>  
> +#ifdef CONFIG_LIVEPATCH
> +/*
> + * Persist Elf information about a module. Copy the Elf header,
> + * section header table, section string table, and symtab section
> + * index from info to mod->klp_info.
> + */
> +static int copy_module_elf(struct module *mod, struct load_info *info)
> +{
> + unsigned int size, symndx;
> + int ret = 0;
> +
> + size = sizeof(*mod->klp_info);
> + mod->klp_info = kmalloc(size, GFP_KERNEL);
> + if (mod->klp_info == NULL)
> + return -ENOMEM;
> +
> + /* Elf header */
> + size = sizeof(Elf_Ehdr);
> + memcpy(&mod->klp_info->hdr, info->hdr, size);
> +
> + /* Elf section header table */
> + size = sizeof(Elf_Shdr) * info->hdr->e_shnum;
> + mod->klp_info->sechdrs = kmalloc(size, GFP_KERNEL);
> + if (mod->klp_info->sechdrs == NULL) {
> + ret = -ENOMEM;
> + goto free_info;
> + }
> + memcpy(mod->klp_info->sechdrs, info->sechdrs, size);
> +
> + /* Elf section name string table */
> + size = info->sechdrs[info->hdr->e_shstrndx].sh_size;
> + mod->klp_info->secstrings = kmalloc(size, GFP_KERNEL);
> + if (mod->klp_info->secstrings == NULL) {
> + ret = -ENOMEM;
> + goto free_sechdrs;
> + }
> + memcpy(mod->klp_info->secstrings, info->secstrings, size);
> +
> + /* Elf symbol section index */
> + symndx = info->index.sym;
> + mod->klp_info->symndx = symndx;
> +
> + /*
> +  * For livepatch modules, core_symtab is a complete copy
> +  * of the original symbol table. Adjust sh_addr to point
> +  * to core_symtab since the copy of the symtab in module

Re: [PATCHv9 4/4] ARM: socfpga: Enable OCRAM ECC on startup

[Dinh Nguyen]

On 01/27/2016 10:13 AM, ttha...@opensource.altera.com wrote:
> From: Thor Thayer 
> 
> This patch enables the ECC for On-Chip RAM on machine startup. The ECC
> has to be enabled before data is stored in memory otherwise the ECC will
> fail on reads.
> 
> Signed-off-by: Thor Thayer 
> ---
> v9: Improve node release handling.
> v8: Address community comments on strings. Fix match strings based
> on maintainer feedback. Update year in header.
> v7: enable OCRAM ECC during platform init
> v6: Implement OCRAM discovery changes from community. Add
> of_node_put(). Remove be32_to_cpup(). Use __init() which
> allows removal of .init_machine(). Update year in header.
> ---
>  arch/arm/mach-socfpga/Makefile  |1 +
>  arch/arm/mach-socfpga/core.h|1 +
>  arch/arm/mach-socfpga/ocram.c   |   49 
> +++
>  arch/arm/mach-socfpga/socfpga.c |3 +++
>  4 files changed, 54 insertions(+)
>  create mode 100644 arch/arm/mach-socfpga/ocram.c
> 

Acked-by: Dinh Nguyen 
--
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: [PATCHv9 3/4] ARM: socfpga: enable L2 cache ECC on startup

[Dinh Nguyen]

On 01/27/2016 10:13 AM, ttha...@opensource.altera.com wrote:
> From: Thor Thayer 
> 
> This patch enables the ECC for L2 cache on machine startup. The ECC has to
> be enabled before data is stored in memory otherwise the ECC will fail on
> reads.
> 
> Signed-off-by: Thor Thayer 
> ---
> v9: Improve node put handling.
> v8: Address community suggestions for strings. Fix string based on
> maintainer feedback. Update year in header.
> v7: unmap locally scoped mapped_l2_edac_addr and add of_node_put(np)
> v6: Remove pr_debug() & update year in header.
> ---
>  arch/arm/mach-socfpga/Makefile   |1 +
>  arch/arm/mach-socfpga/core.h |1 +
>  arch/arm/mach-socfpga/l2_cache.c |   41 
> ++
>  arch/arm/mach-socfpga/socfpga.c  |2 ++
>  4 files changed, 45 insertions(+)
>  create mode 100644 arch/arm/mach-socfpga/l2_cache.c
> 

Acked-by: Dinh Nguyen 


--
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 V2 3/6] stm class: provision for statically assigned masterIDs

[Al Grant]

> Mike did write "master IDs are hardwired to individual cores and core security
> states", which make assignment for one platform very static.
> On the flip side those will change from one system to another.

It depends on your perspective.  From the perspective of a userspace
process not pinned to a core, the master id will appear to vary
dynamically and unpredictably as the thread migrates from one
core to another.  (That's actually useful if the decoder wants to know
where the thread is running at any given point, as it can find that out
for free, without the need to track migration events.)

On the other hand if you are pinned (e.g. you're the kernel on a
particular core, or you're a per-core worker thread in some thread
pooling system) then you have a fixed master id, and then you can
have one instance per core all using the same range of channel
numbers, with the master id indicating the core - this saves on
channel space compared to having to give each core its own
range of channel space.

Al
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [PATCH 8/9] rfkill: Userspace control for airplane mode

[João Paulo Rechi Vita]

On 8 February 2016 at 11:11, Dan Williams  wrote:
> On Mon, 2016-02-08 at 10:41 -0500, João Paulo Rechi Vita wrote:
>> Provide an interface for the airplane-mode indicator be controlled
>> from
>> userspace. User has to first acquire the control through
>> RFKILL_OP_AIRPLANE_MODE_ACQUIRE and keep the fd open for the whole
>> time
>> it wants to be in control of the indicator. Closing the fd or using
>> RFKILL_OP_AIRPLANE_MODE_RELEASE restores the default policy.
>>
>> To change state of the indicator, the RFKILL_OP_AIRPLANE_MODE_CHANGE
>> operation is used, passing the value on "struct rfkill_event.soft".
>> If
>> the caller has not acquired the airplane-mode control beforehand, the
>> operation fails.
>
> I'd like to clarify a bit, so tell me if I'm correct or not.  Using
> RFKILL_OP_AIRPLANE_MODE_CHANGE does not actually change any device
> state. It's just an indicator with no relationship to any of the
> registered rfkill switches, right?
>

Yes, that's correct, and it is the intended behavior.

> I wonder if setting RFKILL_OP_AIRPLANE_MODE_CHANGE(true) shouldn't also
> softblock all switches, otherwise you can set airplane mode all day
> long with RFKILL_OP_AIRPLANE_MODE_CHANGE and it doesn't actually enable
> airplane mode at all?
>

The idea behind it is to just provide the mechanism for userspace to
decide what exactly being in airplane mode means, so it would
set/unset the indicator in the right moment.

--
João Paulo Rechi Vita
http://about.me/jprvita
--
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 8/9] rfkill: Userspace control for airplane mode

[João Paulo Rechi Vita]

Hello Marcel,

On 8 February 2016 at 11:20, Marcel Holtmann  wrote:
> Hi Joa Paulo,
>
>> Provide an interface for the airplane-mode indicator be controlled from
>> userspace. User has to first acquire the control through
>> RFKILL_OP_AIRPLANE_MODE_ACQUIRE and keep the fd open for the whole time
>> it wants to be in control of the indicator. Closing the fd or using
>> RFKILL_OP_AIRPLANE_MODE_RELEASE restores the default policy.
>>
>> To change state of the indicator, the RFKILL_OP_AIRPLANE_MODE_CHANGE
>> operation is used, passing the value on "struct rfkill_event.soft". If
>> the caller has not acquired the airplane-mode control beforehand, the
>> operation fails.
>
> as explained in an earlier response, the concept Airplane Mode seems to be 
> imposing policy into the kernel. Do we really want have this as a kernel 
> exposed API.
>

On that very same thread we decided to keep using the "airplane mode"
name both for when having the default policy of "set it when all
radios are off" or when allowing userspace to override the default.
Please see the following message from Johannes
http://www.spinics.net/lists/linux-wireless/msg146069.html and let me
know if that covers your concern.

Thanks!

--
João Paulo Rechi Vita
http://about.me/jprvita
--
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 8/9] rfkill: Userspace control for airplane mode

[Johannes Berg]

On 2016-02-08 17:20, Marcel Holtmann wrote:


as explained in an earlier response, the concept Airplane Mode seems
to be imposing policy into the kernel. Do we really want have this as
a kernel exposed API.


This patch is the one that *solves* that problem ... please read it more 
carefully?


johannes
--
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 V2 3/6] stm class: provision for statically assigned masterIDs

[Mathieu Poirier]

On 8 February 2016 at 06:26, Alexander Shishkin
 wrote:
> Mathieu Poirier  writes:
>
>> On 5 February 2016 at 05:52, Alexander Shishkin
>>  wrote:
>>> Chunyan Zhang  writes:
>>>
 From: Mathieu Poirier 

 Some architecture like ARM assign masterIDs statically at the HW design
 phase, making masterID manipulation in the generic STM core irrelevant.

 This patch adds a new 'mstatic' flag to struct stm_data that tells the
 core that this specific STM device doesn't need explicit masterID
 management.
>>>
>>> So why do we need this patch? If your STM only has master 42 allocated
>>> for software sources, simply set sw_start = 42, sw_end = 42 and you're
>>> good to go, software will have exactly one channel to choose from. See
>>> also the comment from :
>>
>> On ARM each source, i.e entity capable of accessing STM channels, has
>> a different master ID set in HW.  We can't assume the IDs are
>> contiguous and from a SW point of view there is no way to probe the
>> values.
>
> Ok, it's the 'static' word that got me confused. From Mike's explanation
> it seems to me that it's the antithesis of static; the master ID
> assignment is so dynamic that it's not controllable by the software and
> may or may not reflect core id, power state, phase of the moon, etc.

Mike did write "master IDs are hardwired to individual cores and core
security states", which make assignment for one platform very static.
On the flip side those will change from one system to another.

>
 In the core sw_start/end of masterID are set to '1',
 i.e there is only one masterID to deal with.
>>>
>>> This is also a completely arbitrary and unnecessary requirement. Again,
>>> you can set both to 42 and it will still work.
>>
>> True - any value will do. The important thing to remember is that on
>> ARM, there is only one masterID channel (from an STM core point of
>> view).  But we could also proceed differently, see below for more
>> details.
>
> Well, we have the masters attribute with two numbers in it that define
> the range of master IDs that the software can choose from. More
> specifically to this situation:
>
>  * the number of channel ID spaces available to the SW is
>$end - $start + 1, that is, in your case, just 1;
>  * the number of master IDs for the SW to choose from is $end - $start;
>  * if $end==$start, their actual numeric value doesn't really matter,
>either for the policy definition or for the actual writers.
>
> This $end==$start situation itself may be ambiguous and can be
> interpreted either as having just one *static* master ID fixed for all
> SW writers (what I assumed from your commit message) or as having a
> floating master ID, which changes of its own accord and is not
> controllable by software.

Some clarification here.

On ARM from a SW point of view $end == $start and that doesn't change
(with regards to masterIDs) .  The ambiguity comes from the fact that
on other platforms where masterID configuration does change and is
important, the condition $end == $start could also be valid.

>From configFS, how do we tell users when masterIDs are set in HW?
That's what I wanted to highlight with the '-1'.  Regardless of the
solution we choose I think it is important that we inform, at the very
least, users when masterIDs don't matter.  We could also leave thing
as is, kill this patch and document things thoroughly.  With the
former things are obvious.

>
> These two situations are really the same thing from the perspective of
> the system under tracing. Also, both of these situations should already
> work if the driver sets both sw_start and sw_end to the same
> value.
>
> Regards,
> --
> Alex
--
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 8/9] rfkill: Userspace control for airplane mode

[Marcel Holtmann]

Hi Joa Paulo,

> Provide an interface for the airplane-mode indicator be controlled from
> userspace. User has to first acquire the control through
> RFKILL_OP_AIRPLANE_MODE_ACQUIRE and keep the fd open for the whole time
> it wants to be in control of the indicator. Closing the fd or using
> RFKILL_OP_AIRPLANE_MODE_RELEASE restores the default policy.
> 
> To change state of the indicator, the RFKILL_OP_AIRPLANE_MODE_CHANGE
> operation is used, passing the value on "struct rfkill_event.soft". If
> the caller has not acquired the airplane-mode control beforehand, the
> operation fails.

as explained in an earlier response, the concept Airplane Mode seems to be 
imposing policy into the kernel. Do we really want have this as a kernel 
exposed API.

Regards

Marcel

--
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: [PATCHv9 1/4] EDAC, altera: Add Altera L2 Cache and OCRAM EDAC Support

[Borislav Petkov]

On Mon, Feb 08, 2016 at 10:10:53AM -0600, Thor Thayer wrote:
> Understood. I did get a conditional ACK from Rob Herring on the DT portion
> of the patch from the last revision (as long as I made the changes he
> suggested which I did in this patch). There may be other comments though.

Ah, and I wasn't precise: there are also arch/arm/mach-socfpga/ changes
which I'm going to take through the EDAC tree *only* if ARM people ack
them.

And by "ARM people" and from looking at get_maintainer output I mean
Dinh and he's on CC ...

> Those are the only cases of irq but it would be good to be alerted if that
> is not the case. I will add. Thanks!

Yeah, it is a "just in case" thing - it might just as well be too
cautious and completely unnecessary so your decision.

> Yes, thanks. I was using the xgene code as an example but I missed the
> unregister (although it looks like the xgene's unregister affects sysfs
> instead of debugfs). I'm also moving the debugfs creation to the end of the
> probe since it is not critical and avoids an error path if creation fails.
> 
> I'll make the debugfs_remove_recursive() change as a separate patch in my
> next version.

Good, thanks!

Also, if something's not right in drivers/edac/debugfs.c wrt usability
and so on, feel free to propose changes. I've extracted it there because
I didn't want every driver to reinvent the wheel.

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
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 8/9] rfkill: Userspace control for airplane mode

[Dan Williams]

On Mon, 2016-02-08 at 10:41 -0500, João Paulo Rechi Vita wrote:
> Provide an interface for the airplane-mode indicator be controlled
> from
> userspace. User has to first acquire the control through
> RFKILL_OP_AIRPLANE_MODE_ACQUIRE and keep the fd open for the whole
> time
> it wants to be in control of the indicator. Closing the fd or using
> RFKILL_OP_AIRPLANE_MODE_RELEASE restores the default policy.
> 
> To change state of the indicator, the RFKILL_OP_AIRPLANE_MODE_CHANGE
> operation is used, passing the value on "struct rfkill_event.soft".
> If
> the caller has not acquired the airplane-mode control beforehand, the
> operation fails.

I'd like to clarify a bit, so tell me if I'm correct or not.  Using
RFKILL_OP_AIRPLANE_MODE_CHANGE does not actually change any device
state. It's just an indicator with no relationship to any of the
registered rfkill switches, right?

I wonder if setting RFKILL_OP_AIRPLANE_MODE_CHANGE(true) shouldn't also
softblock all switches, otherwise you can set airplane mode all day
long with RFKILL_OP_AIRPLANE_MODE_CHANGE and it doesn't actually enable
airplane mode at all?

Dan

> Signed-off-by: João Paulo Rechi Vita 
> ---
>  Documentation/rfkill.txt| 10 ++
>  include/uapi/linux/rfkill.h |  3 +++
>  net/rfkill/core.c   | 47
> ++---
>  3 files changed, 57 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
> index b13025a..aa6e014 100644
> --- a/Documentation/rfkill.txt
> +++ b/Documentation/rfkill.txt
> @@ -87,6 +87,7 @@ RFKill provides per-switch LED triggers, which can
> be used to drive LEDs
>  according to the switch state (LED_FULL when blocked, LED_OFF
> otherwise).
>  An airplane-mode indicator LED trigger is also available, which
> triggers
>  LED_FULL when all radios known by RFKill are blocked, and LED_OFF
> otherwise.
> +The airplane-mode indicator LED trigger policy can be overridden by
> userspace.
>  
>  
>  5. Userspace support
> @@ -123,5 +124,14 @@ RFKILL_TYPE
>  The contents of these variables corresponds to the "name", "state"
> and
>  "type" sysfs files explained above.
>  
> +Userspace can also override the default airplane-mode indicator
> policy through
> +/dev/rfkill. Control of the airplane mode indicator has to be
> acquired first,
> +using RFKILL_OP_AIRPLANE_MODE_ACQUIRE, and is only available for one
> userspace
> +application at a time. Closing the fd or using
> RFKILL_OP_AIRPLANE_MODE_RELEASE
> +reverts the airplane-mode indicator back to the default kernel
> policy and makes
> +it available for other applications to take control. Changes to the
> +airplane-mode indicator state can be made using
> RFKILL_OP_AIRPLANE_MODE_CHANGE,
> +passing the new value in the 'soft' field of 'struct rfkill_event'.
> +
>  
>  For further details consult Documentation/ABI/stable/sysfs-class
> -rfkill.
> diff --git a/include/uapi/linux/rfkill.h
> b/include/uapi/linux/rfkill.h
> index 2e00dce..9cb999b 100644
> --- a/include/uapi/linux/rfkill.h
> +++ b/include/uapi/linux/rfkill.h
> @@ -67,6 +67,9 @@ enum rfkill_operation {
>   RFKILL_OP_DEL,
>   RFKILL_OP_CHANGE,
>   RFKILL_OP_CHANGE_ALL,
> + RFKILL_OP_AIRPLANE_MODE_ACQUIRE,
> + RFKILL_OP_AIRPLANE_MODE_RELEASE,
> + RFKILL_OP_AIRPLANE_MODE_CHANGE,
>  };
>  
>  /**
> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> index fb11547..8067701 100644
> --- a/net/rfkill/core.c
> +++ b/net/rfkill/core.c
> @@ -89,6 +89,7 @@ struct rfkill_data {
>   struct mutexmtx;
>   wait_queue_head_t   read_wait;
>   boolinput_handler;
> + boolis_apm_owner;
>  };
>  
>  
> @@ -123,7 +124,7 @@ static struct {
>  } rfkill_global_states[NUM_RFKILL_TYPES];
>  
>  static bool rfkill_epo_lock_active;
> -
> +static bool rfkill_apm_owned;
>  
>  #ifdef CONFIG_RFKILL_LEDS
>  static struct led_trigger rfkill_apm_led_trigger;
> @@ -350,7 +351,8 @@ static void rfkill_update_global_state(enum
> rfkill_type type, bool blocked)
>  
>   for (i = 0; i < NUM_RFKILL_TYPES; i++)
>   rfkill_global_states[i].cur = blocked;
> - rfkill_apm_led_trigger_event(blocked);
> + if (!rfkill_apm_owned)
> + rfkill_apm_led_trigger_event(blocked);
>  }
>  
>  #ifdef CONFIG_RFKILL_INPUT
> @@ -1183,6 +1185,7 @@ static ssize_t rfkill_fop_read(struct file
> *file, char __user *buf,
>  static ssize_t rfkill_fop_write(struct file *file, const char __user
> *buf,
>   size_t count, loff_t *pos)
>  {
> + struct rfkill_data *data = file->private_data;
>   struct rfkill *rfkill;
>   struct rfkill_event ev;
>  
> @@ -1199,7 +1202,7 @@ static ssize_t rfkill_fop_write(struct file
> *file, const char __user *buf,
>   if (copy_from_user(&ev, buf, count))
>   return -EFAULT;
>  
> - if (ev.op != RFKILL_OP_CHANGE && ev.op !=
> RFKILL_OP_CHANGE_ALL)
> + if (ev.op < RFKILL_OP_CHANGE)
>  

Re: [PATCHv9 1/4] EDAC, altera: Add Altera L2 Cache and OCRAM EDAC Support

[Thor Thayer]

Hi Boris.

On 02/08/2016 05:39 AM, Borislav Petkov wrote:

On Wed, Jan 27, 2016 at 10:13:20AM -0600, ttha...@opensource.altera.com wrote:

From: Thor Thayer 

Adding L2 Cache and On-Chip RAM EDAC support for the
Altera SoCs using the EDAC device  model. The SDRAM
controller is using the Memory Controller model.

Each type of ECC is individually configurable.

Signed-off-by: Thor Thayer 
---
v9: Improve device tree node release. Free managed resources
 on error path. Fix ocram memory leak.
v8: Remove MASK from single bit mask names.
 s/altr,edac/altr,socfpga-ecc-manager
 Use debugfs instead of sysfs.
 Add chip family name to match string.
 Fix header year.
 Fix build dependencies & change commit accordingly.
 s/CONFIG_EDAC_ALTERA_MC/CONFIG_EDAC_ALTERA
v7: s/of_get_named_gen_pool/of_gen_pool_get
 Remove #ifdef for EDAC_DEBUG
 Use -ENODEV instead of EPROBE_DEFER
v6: Convert to nested EDAC in device tree. Force L2 cache
 on for L2Cache ECC & remove L2 cache syscon for checking
 enable bit. Update year in header.
v5: No change.
v4: Change mask defines to use BIT().
 Fix comment style to agree with kernel coding style.
 Better printk description for read != write in trigger.
 Remove SysFS debugging message.
 Better dci->mod_name
 Move gen_pool pointer assignment to end of function.
 Invert logic to reduce indent in ocram depenency check.
 Change from dev_err() to edac_printk()
 Replace magic numbers with defines & comments.
 Improve error injection test.
 Change Makefile intermediary name to altr (from alt)
v3: Move OCRAM and L2 cache EDAC functions into altera_edac.c
 instead of separate files.
v2: Fix L2 dependency comments.
---
  drivers/edac/Kconfig   |   26 ++-
  drivers/edac/Makefile  |2 +-
  drivers/edac/altera_edac.c |  487 +++-
  3 files changed, 507 insertions(+), 8 deletions(-)


I'm still waiting for the people on CC to confirm the DT changes. A
couple of comments on the EDAC bits below.




Understood. I did get a conditional ACK from Rob Herring on the DT 
portion of the patch from the last revision (as long as I made the 
changes he suggested which I did in this patch). There may be other 
comments though.







+static irqreturn_t altr_edac_device_handler(int irq, void *dev_id)
+{
+   struct edac_device_ctl_info *dci = dev_id;
+   struct altr_edac_device_dev *drvdata = dci->pvt_info;
+   const struct edac_device_prv_data *priv = drvdata->data;
+
+   if (irq == drvdata->sb_irq) {
+   if (priv->ce_clear_mask)
+   writel(priv->ce_clear_mask, drvdata->base);
+   edac_device_handle_ce(dci, 0, 0, drvdata->edac_dev_name);
+   }
+   if (irq == drvdata->db_irq) {
+   if (priv->ue_clear_mask)
+   writel(priv->ue_clear_mask, drvdata->base);
+   edac_device_handle_ue(dci, 0, 0, drvdata->edac_dev_name);
+   panic("\nEDAC:ECC_DEVICE[Uncorrectable errors]\n");
+   }


And irq is guaranteed to always be ->sb_irq or ->db_irq?

Otherwise, you can do

else
WARN_ON(1);

just in case.


Those are the only cases of irq but it would be good to be alerted if 
that is not the case. I will add. Thanks!





+
+   return IRQ_HANDLED;
+}


...


+/*
+ * altr_edac_device_probe()
+ * This is a generic EDAC device driver that will support
+ * various Altera memory devices such as the L2 cache ECC and
+ * OCRAM ECC as well as the memories for other peripherals.
+ * Module specific initialization is done by passing the
+ * function index in the device tree.
+ */
+static int altr_edac_device_probe(struct platform_device *pdev)
+{





+
+   dci->mod_name = "Altera ECC Manager";
+   dci->dev_name = drvdata->edac_dev_name;
+
+   debugfs = edac_debugfs_create_dir(ecc_name);
+   if (debugfs)
+   altr_create_edacdev_dbgfs(dci, drvdata->data, debugfs);
+
+   if (edac_device_add_device(dci))


<--- if you end up here and debugfs nodes have been created, you need to
destroy them here. You probably could change edac_debugfs_exit() to call
debugfs_remove_recursive() and make sure your driver calls it.

Right now we're calling edac_debugfs_exit() in edac_exit() and I *think*
that is ok for a platform device driver as this one but I haven't
actually *verified* that.


Yes, thanks. I was using the xgene code as an example but I missed the 
unregister (although it looks like the xgene's unregister affects sysfs 
instead of debugfs). I'm also moving the debugfs creation to the end of 
the probe since it is not critical and avoids an error path if creation 
fails.


I'll make the debugfs_remove_recursive() change as a separate patch in 
my next version.





+   goto fail1;
+
+   devres_close_group(&pdev->dev, NULL);





+
+   memset(sram_addr, 0, size);
+   wmb();  /* Ensu

[PATCH 2/9] rfkill: Remove extra blank line

[João Paulo Rechi Vita]

Signed-off-by: João Paulo Rechi Vita 
---
 net/rfkill/core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index ffbc375..56d79cb 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -455,7 +455,6 @@ bool rfkill_get_global_sw_state(const enum rfkill_type type)
 }
 #endif
 
-
 bool rfkill_set_hw_state(struct rfkill *rfkill, bool blocked)
 {
unsigned long flags;
-- 
2.5.0

--
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/9] rfkill: Move "state" sysfs file back to stable

[João Paulo Rechi Vita]

There is still quite a bit of code using this interface, so we can't
just remove it. Hopefully it will be possible in the future, but since
its scheduled removal date is past 2 years already, we are better having
the documentation reflecting the current state of things.

Signed-off-by: João Paulo Rechi Vita 
---
 Documentation/ABI/obsolete/sysfs-class-rfkill | 20 
 Documentation/ABI/stable/sysfs-class-rfkill   | 25 ++---
 2 files changed, 22 insertions(+), 23 deletions(-)
 delete mode 100644 Documentation/ABI/obsolete/sysfs-class-rfkill

diff --git a/Documentation/ABI/obsolete/sysfs-class-rfkill 
b/Documentation/ABI/obsolete/sysfs-class-rfkill
deleted file mode 100644
index e736d14..000
--- a/Documentation/ABI/obsolete/sysfs-class-rfkill
+++ /dev/null
@@ -1,20 +0,0 @@
-rfkill - radio frequency (RF) connector kill switch support
-
-For details to this subsystem look at Documentation/rfkill.txt.
-
-What:  /sys/class/rfkill/rfkill[0-9]+/state
-Date:  09-Jul-2007
-KernelVersion  v2.6.22
-Contact:   linux-wirel...@vger.kernel.org
-Description:   Current state of the transmitter.
-   This file is deprecated and scheduled to be removed in 2014,
-   because its not possible to express the 'soft and hard block'
-   state of the rfkill driver.
-Values:A numeric value.
-   0: RFKILL_STATE_SOFT_BLOCKED
-   transmitter is turned off by software
-   1: RFKILL_STATE_UNBLOCKED
-   transmitter is (potentially) active
-   2: RFKILL_STATE_HARD_BLOCKED
-   transmitter is forced off by something outside of
-   the driver's control.
diff --git a/Documentation/ABI/stable/sysfs-class-rfkill 
b/Documentation/ABI/stable/sysfs-class-rfkill
index e51571e..e1ba4a1 100644
--- a/Documentation/ABI/stable/sysfs-class-rfkill
+++ b/Documentation/ABI/stable/sysfs-class-rfkill
@@ -5,9 +5,6 @@ For details to this subsystem look at Documentation/rfkill.txt.
 For the deprecated /sys/class/rfkill/*/claim knobs of this interface look in
 Documentation/ABI/removed/sysfs-class-rfkill.
 
-For the deprecated /sys/class/rfkill/*/state knobs of this interface look in
-Documentation/ABI/obsolete/sysfs-class-rfkill.
-
 What:  /sys/class/rfkill
 Date:  09-Jul-2007
 KernelVersion: v2.6.22
@@ -44,6 +41,28 @@ Values:  A numeric value.
1: true
 
 
+What:  /sys/class/rfkill/rfkill[0-9]+/state
+Date:  09-Jul-2007
+KernelVersion  v2.6.22
+Contact:   linux-wirel...@vger.kernel.org
+Description:   Current state of the transmitter.
+   This file was scheduled to be removed in 2014, but due to its
+   large number of users it will be sticking around for a bit
+   longer. Despite it being marked as stabe, the newer "hard" and
+   "soft" interfaces should be preffered, since it is not possible
+   to express the 'soft and hard block' state of the rfkill driver
+   through this interface. There will likely be another attempt to
+   remove it in the future.
+Values:A numeric value.
+   0: RFKILL_STATE_SOFT_BLOCKED
+   transmitter is turned off by software
+   1: RFKILL_STATE_UNBLOCKED
+   transmitter is (potentially) active
+   2: RFKILL_STATE_HARD_BLOCKED
+   transmitter is forced off by something outside of
+   the driver's control.
+
+
 What:  /sys/class/rfkill/rfkill[0-9]+/hard
 Date:  12-March-2010
 KernelVersion  v2.6.34
-- 
2.5.0

--
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/9] rfkill: Point to the correct deprecated doc location

[João Paulo Rechi Vita]

The "claim" sysfs interface has been removed, so its documentation now
lives in the "removed" folder.

Signed-off-by: João Paulo Rechi Vita 
---
 Documentation/ABI/stable/sysfs-class-rfkill | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/ABI/stable/sysfs-class-rfkill 
b/Documentation/ABI/stable/sysfs-class-rfkill
index 097f522..e51571e 100644
--- a/Documentation/ABI/stable/sysfs-class-rfkill
+++ b/Documentation/ABI/stable/sysfs-class-rfkill
@@ -2,8 +2,10 @@ rfkill - radio frequency (RF) connector kill switch support
 
 For details to this subsystem look at Documentation/rfkill.txt.
 
-For the deprecated /sys/class/rfkill/*/state and
-/sys/class/rfkill/*/claim knobs of this interface look in
+For the deprecated /sys/class/rfkill/*/claim knobs of this interface look in
+Documentation/ABI/removed/sysfs-class-rfkill.
+
+For the deprecated /sys/class/rfkill/*/state knobs of this interface look in
 Documentation/ABI/obsolete/sysfs-class-rfkill.
 
 What:  /sys/class/rfkill
-- 
2.5.0

--
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/9] rfkill: Improve documentation language

[João Paulo Rechi Vita]

Signed-off-by: João Paulo Rechi Vita 
---
 net/rfkill/core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index a805831..ffbc375 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -282,8 +282,8 @@ static void rfkill_set_block(struct rfkill *rfkill, bool 
blocked)
spin_lock_irqsave(&rfkill->lock, flags);
if (err) {
/*
-* Failed -- reset status to _prev, this may be different
-* from what set set _PREV to earlier in this function
+* Failed -- reset status to _PREV, which may be different
+* from what we have set _PREV to earlier in this function
 * if rfkill_set_sw_state was invoked.
 */
if (rfkill->state & RFKILL_BLOCK_SW_PREV)
-- 
2.5.0

--
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 5/9] rfkill: Factor rfkill_global_states[].cur assignments

[João Paulo Rechi Vita]

Factor all assignments to rfkill_global_states[].cur into a single
function rfkill_update_global_state().

Signed-off-by: João Paulo Rechi Vita 
---
 net/rfkill/core.c | 38 +-
 1 file changed, 17 insertions(+), 21 deletions(-)

diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 56d79cb..8b96869 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -302,6 +302,19 @@ static void rfkill_set_block(struct rfkill *rfkill, bool 
blocked)
rfkill_event(rfkill);
 }
 
+static void rfkill_update_global_state(enum rfkill_type type, bool blocked)
+{
+   int i;
+
+   if (type != RFKILL_TYPE_ALL) {
+   rfkill_global_states[type].cur = blocked;
+   return;
+   }
+
+   for (i = 0; i < NUM_RFKILL_TYPES; i++)
+   rfkill_global_states[i].cur = blocked;
+}
+
 #ifdef CONFIG_RFKILL_INPUT
 static atomic_t rfkill_input_disabled = ATOMIC_INIT(0);
 
@@ -319,15 +332,7 @@ static void __rfkill_switch_all(const enum rfkill_type 
type, bool blocked)
 {
struct rfkill *rfkill;
 
-   if (type == RFKILL_TYPE_ALL) {
-   int i;
-
-   for (i = 0; i < NUM_RFKILL_TYPES; i++)
-   rfkill_global_states[i].cur = blocked;
-   } else {
-   rfkill_global_states[type].cur = blocked;
-   }
-
+   rfkill_update_global_state(type, blocked);
list_for_each_entry(rfkill, &rfkill_list, node) {
if (rfkill->type != type && type != RFKILL_TYPE_ALL)
continue;
@@ -1164,15 +1169,8 @@ static ssize_t rfkill_fop_write(struct file *file, const 
char __user *buf,
 
mutex_lock(&rfkill_global_mutex);
 
-   if (ev.op == RFKILL_OP_CHANGE_ALL) {
-   if (ev.type == RFKILL_TYPE_ALL) {
-   enum rfkill_type i;
-   for (i = 0; i < NUM_RFKILL_TYPES; i++)
-   rfkill_global_states[i].cur = ev.soft;
-   } else {
-   rfkill_global_states[ev.type].cur = ev.soft;
-   }
-   }
+   if (ev.op == RFKILL_OP_CHANGE_ALL)
+   rfkill_update_global_state(ev.type, ev.soft);
 
list_for_each_entry(rfkill, &rfkill_list, node) {
if (rfkill->idx != ev.idx && ev.op != RFKILL_OP_CHANGE_ALL)
@@ -1261,10 +1259,8 @@ static struct miscdevice rfkill_miscdev = {
 static int __init rfkill_init(void)
 {
int error;
-   int i;
 
-   for (i = 0; i < NUM_RFKILL_TYPES; i++)
-   rfkill_global_states[i].cur = !rfkill_default_state;
+   rfkill_update_global_state(RFKILL_TYPE_ALL, !rfkill_default_state);
 
error = class_register(&rfkill_class);
if (error)
-- 
2.5.0

--
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 6/9] rfkill: Add documentation about LED triggers

[João Paulo Rechi Vita]

Signed-off-by: João Paulo Rechi Vita 
---
 Documentation/rfkill.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
index 2ee6ef9..1f0c270 100644
--- a/Documentation/rfkill.txt
+++ b/Documentation/rfkill.txt
@@ -83,6 +83,8 @@ rfkill drivers that control devices that can be hard-blocked 
unless they also
 assign the poll_hw_block() callback (then the rfkill core will poll the
 device). Don't do this unless you cannot get the event in any other way.
 
+RFKill provides per-switch LED triggers, which can be used to drive LEDs
+according to the switch state (LED_FULL when blocked, LED_OFF otherwise).
 
 
 5. Userspace support
-- 
2.5.0

--
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 7/9] rfkill: Create "rfkill-airplane_mode" LED trigger

[João Paulo Rechi Vita]

This creates a new LED trigger to be used by platform drivers as a
default trigger for airplane-mode indicator LEDs.

By default this trigger will fire when RFKILL_OP_CHANGE_ALL is called
for all types (RFKILL_TYPE_ALL), setting the LED brightness to LED_FULL
when the changing the state to blocked, and to LED_OFF when the changing
the state to unblocked. In the future there will be a mechanism for
userspace to override the default policy, so it can implement its own.

This trigger will be used by the asus-wireless x86 platform driver.

Signed-off-by: João Paulo Rechi Vita 
---
 Documentation/rfkill.txt |  2 ++
 net/rfkill/core.c| 49 +++-
 2 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
index 1f0c270..b13025a 100644
--- a/Documentation/rfkill.txt
+++ b/Documentation/rfkill.txt
@@ -85,6 +85,8 @@ device). Don't do this unless you cannot get the event in any 
other way.
 
 RFKill provides per-switch LED triggers, which can be used to drive LEDs
 according to the switch state (LED_FULL when blocked, LED_OFF otherwise).
+An airplane-mode indicator LED trigger is also available, which triggers
+LED_FULL when all radios known by RFKill are blocked, and LED_OFF otherwise.
 
 
 5. Userspace support
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 8b96869..fb11547 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -126,6 +126,30 @@ static bool rfkill_epo_lock_active;
 
 
 #ifdef CONFIG_RFKILL_LEDS
+static struct led_trigger rfkill_apm_led_trigger;
+
+static void rfkill_apm_led_trigger_event(bool state)
+{
+   led_trigger_event(&rfkill_apm_led_trigger, state ? LED_FULL : LED_OFF);
+}
+
+static void rfkill_apm_led_trigger_activate(struct led_classdev *led)
+{
+   rfkill_apm_led_trigger_event(!rfkill_default_state);
+}
+
+static int rfkill_apm_led_trigger_register(void)
+{
+   rfkill_apm_led_trigger.name = "rfkill-airplane_mode";
+   rfkill_apm_led_trigger.activate = rfkill_apm_led_trigger_activate;
+   return led_trigger_register(&rfkill_apm_led_trigger);
+}
+
+static void rfkill_apm_led_trigger_unregister(void)
+{
+   led_trigger_unregister(&rfkill_apm_led_trigger);
+}
+
 static void rfkill_led_trigger_event(struct rfkill *rfkill)
 {
struct led_trigger *trigger;
@@ -177,6 +201,19 @@ static void rfkill_led_trigger_unregister(struct rfkill 
*rfkill)
led_trigger_unregister(&rfkill->led_trigger);
 }
 #else
+static void rfkill_apm_led_trigger_event(bool state)
+{
+}
+
+static int rfkill_apm_led_trigger_register(void)
+{
+   return 0;
+}
+
+static void rfkill_apm_led_trigger_unregister(void)
+{
+}
+
 static void rfkill_led_trigger_event(struct rfkill *rfkill)
 {
 }
@@ -313,6 +350,7 @@ static void rfkill_update_global_state(enum rfkill_type 
type, bool blocked)
 
for (i = 0; i < NUM_RFKILL_TYPES; i++)
rfkill_global_states[i].cur = blocked;
+   rfkill_apm_led_trigger_event(blocked);
 }
 
 #ifdef CONFIG_RFKILL_INPUT
@@ -1260,15 +1298,22 @@ static int __init rfkill_init(void)
 {
int error;
 
+   error = rfkill_apm_led_trigger_register();
+   if (error)
+   goto out;
+
rfkill_update_global_state(RFKILL_TYPE_ALL, !rfkill_default_state);
 
error = class_register(&rfkill_class);
-   if (error)
+   if (error) {
+   rfkill_apm_led_trigger_unregister();
goto out;
+   }
 
error = misc_register(&rfkill_miscdev);
if (error) {
class_unregister(&rfkill_class);
+   rfkill_apm_led_trigger_unregister();
goto out;
}
 
@@ -1277,6 +1322,7 @@ static int __init rfkill_init(void)
if (error) {
misc_deregister(&rfkill_miscdev);
class_unregister(&rfkill_class);
+   rfkill_apm_led_trigger_unregister();
goto out;
}
 #endif
@@ -1293,5 +1339,6 @@ static void __exit rfkill_exit(void)
 #endif
misc_deregister(&rfkill_miscdev);
class_unregister(&rfkill_class);
+   rfkill_apm_led_trigger_unregister();
 }
 module_exit(rfkill_exit);
-- 
2.5.0

--
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 8/9] rfkill: Userspace control for airplane mode

[João Paulo Rechi Vita]

Provide an interface for the airplane-mode indicator be controlled from
userspace. User has to first acquire the control through
RFKILL_OP_AIRPLANE_MODE_ACQUIRE and keep the fd open for the whole time
it wants to be in control of the indicator. Closing the fd or using
RFKILL_OP_AIRPLANE_MODE_RELEASE restores the default policy.

To change state of the indicator, the RFKILL_OP_AIRPLANE_MODE_CHANGE
operation is used, passing the value on "struct rfkill_event.soft". If
the caller has not acquired the airplane-mode control beforehand, the
operation fails.

Signed-off-by: João Paulo Rechi Vita 
---
 Documentation/rfkill.txt| 10 ++
 include/uapi/linux/rfkill.h |  3 +++
 net/rfkill/core.c   | 47 ++---
 3 files changed, 57 insertions(+), 3 deletions(-)

diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
index b13025a..aa6e014 100644
--- a/Documentation/rfkill.txt
+++ b/Documentation/rfkill.txt
@@ -87,6 +87,7 @@ RFKill provides per-switch LED triggers, which can be used to 
drive LEDs
 according to the switch state (LED_FULL when blocked, LED_OFF otherwise).
 An airplane-mode indicator LED trigger is also available, which triggers
 LED_FULL when all radios known by RFKill are blocked, and LED_OFF otherwise.
+The airplane-mode indicator LED trigger policy can be overridden by userspace.
 
 
 5. Userspace support
@@ -123,5 +124,14 @@ RFKILL_TYPE
 The contents of these variables corresponds to the "name", "state" and
 "type" sysfs files explained above.
 
+Userspace can also override the default airplane-mode indicator policy through
+/dev/rfkill. Control of the airplane mode indicator has to be acquired first,
+using RFKILL_OP_AIRPLANE_MODE_ACQUIRE, and is only available for one userspace
+application at a time. Closing the fd or using RFKILL_OP_AIRPLANE_MODE_RELEASE
+reverts the airplane-mode indicator back to the default kernel policy and makes
+it available for other applications to take control. Changes to the
+airplane-mode indicator state can be made using RFKILL_OP_AIRPLANE_MODE_CHANGE,
+passing the new value in the 'soft' field of 'struct rfkill_event'.
+
 
 For further details consult Documentation/ABI/stable/sysfs-class-rfkill.
diff --git a/include/uapi/linux/rfkill.h b/include/uapi/linux/rfkill.h
index 2e00dce..9cb999b 100644
--- a/include/uapi/linux/rfkill.h
+++ b/include/uapi/linux/rfkill.h
@@ -67,6 +67,9 @@ enum rfkill_operation {
RFKILL_OP_DEL,
RFKILL_OP_CHANGE,
RFKILL_OP_CHANGE_ALL,
+   RFKILL_OP_AIRPLANE_MODE_ACQUIRE,
+   RFKILL_OP_AIRPLANE_MODE_RELEASE,
+   RFKILL_OP_AIRPLANE_MODE_CHANGE,
 };
 
 /**
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index fb11547..8067701 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -89,6 +89,7 @@ struct rfkill_data {
struct mutexmtx;
wait_queue_head_t   read_wait;
boolinput_handler;
+   boolis_apm_owner;
 };
 
 
@@ -123,7 +124,7 @@ static struct {
 } rfkill_global_states[NUM_RFKILL_TYPES];
 
 static bool rfkill_epo_lock_active;
-
+static bool rfkill_apm_owned;
 
 #ifdef CONFIG_RFKILL_LEDS
 static struct led_trigger rfkill_apm_led_trigger;
@@ -350,7 +351,8 @@ static void rfkill_update_global_state(enum rfkill_type 
type, bool blocked)
 
for (i = 0; i < NUM_RFKILL_TYPES; i++)
rfkill_global_states[i].cur = blocked;
-   rfkill_apm_led_trigger_event(blocked);
+   if (!rfkill_apm_owned)
+   rfkill_apm_led_trigger_event(blocked);
 }
 
 #ifdef CONFIG_RFKILL_INPUT
@@ -1183,6 +1185,7 @@ static ssize_t rfkill_fop_read(struct file *file, char 
__user *buf,
 static ssize_t rfkill_fop_write(struct file *file, const char __user *buf,
size_t count, loff_t *pos)
 {
+   struct rfkill_data *data = file->private_data;
struct rfkill *rfkill;
struct rfkill_event ev;
 
@@ -1199,7 +1202,7 @@ static ssize_t rfkill_fop_write(struct file *file, const 
char __user *buf,
if (copy_from_user(&ev, buf, count))
return -EFAULT;
 
-   if (ev.op != RFKILL_OP_CHANGE && ev.op != RFKILL_OP_CHANGE_ALL)
+   if (ev.op < RFKILL_OP_CHANGE)
return -EINVAL;
 
if (ev.type >= NUM_RFKILL_TYPES)
@@ -1207,6 +1210,34 @@ static ssize_t rfkill_fop_write(struct file *file, const 
char __user *buf,
 
mutex_lock(&rfkill_global_mutex);
 
+   if (ev.op == RFKILL_OP_AIRPLANE_MODE_ACQUIRE) {
+   if (rfkill_apm_owned && !data->is_apm_owner) {
+   count = -EACCES;
+   } else {
+   rfkill_apm_owned = true;
+   data->is_apm_owner = true;
+   }
+   }
+
+   if (ev.op == RFKILL_OP_AIRPLANE_MODE_RELEASE) {
+   if (rfkill_apm_owned && !data->is_apm_owner) {
+   count = -EACCES;
+   } else {
+   bool state

[PATCH 9/9] rfkill: Notify userspace of airplane-mode state changes

[João Paulo Rechi Vita]

Signed-off-by: João Paulo Rechi Vita 
---
 Documentation/rfkill.txt |  3 +++
 net/rfkill/core.c| 13 +
 2 files changed, 16 insertions(+)

diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
index aa6e014..5248812 100644
--- a/Documentation/rfkill.txt
+++ b/Documentation/rfkill.txt
@@ -133,5 +133,8 @@ it available for other applications to take control. 
Changes to the
 airplane-mode indicator state can be made using RFKILL_OP_AIRPLANE_MODE_CHANGE,
 passing the new value in the 'soft' field of 'struct rfkill_event'.
 
+This same API is also used to provide userspace with notifications of changes
+to airplane-mode indicator state.
+
 
 For further details consult Documentation/ABI/stable/sysfs-class-rfkill.
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 8067701..abbb8f7 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -131,7 +131,20 @@ static struct led_trigger rfkill_apm_led_trigger;
 
 static void rfkill_apm_led_trigger_event(bool state)
 {
+   struct rfkill_data *data;
+   struct rfkill_int_event *ev;
+
led_trigger_event(&rfkill_apm_led_trigger, state ? LED_FULL : LED_OFF);
+
+   list_for_each_entry(data, &rfkill_fds, list) {
+   ev = kzalloc(sizeof(*ev), GFP_KERNEL);
+   if (!ev)
+   continue;
+   ev->ev.op = RFKILL_OP_AIRPLANE_MODE_CHANGE;
+   ev->ev.soft = state;
+   list_add_tail(&ev->list, &data->events);
+   wake_up_interruptible(&data->read_wait);
+   }
 }
 
 static void rfkill_apm_led_trigger_activate(struct led_classdev *led)
-- 
2.5.0

--
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/9] RFKill airplane-mode indicator

[João Paulo Rechi Vita]

This series implements an airplane-mode indicator LED trigger, which can be
used by platform drivers. The default policy have have airplane-mode set when
all the radios known by RFKill are OFF, and unset otherwise. This policy can be
overwritten by userspace using the new operations _AIRPLANE_MODE_ACQUIRE,
_AIRPLANE_MODE_RELEASE, and _AIRPLANE_MODE_CHANGE. When the airplane-mode
indicator state changes, userspace gets notifications through the RFKill
control misc device (/dev/rfkill).

The series also contains a few general fixes and improvements to the subsystem.

João Paulo Rechi Vita (9):
  rfkill: Improve documentation language
  rfkill: Remove extra blank line
  rfkill: Point to the correct deprecated doc location
  rfkill: Move "state" sysfs file back to stable
  rfkill: Factor rfkill_global_states[].cur assignments
  rfkill: Add documentation about LED triggers
  rfkill: Create "rfkill-airplane_mode" LED trigger
  rfkill: Userspace control for airplane mode
  rfkill: Notify userspace of airplane-mode state changes

 Documentation/ABI/obsolete/sysfs-class-rfkill |  20 
 Documentation/ABI/stable/sysfs-class-rfkill   |  27 -
 Documentation/rfkill.txt  |  17 +++
 include/uapi/linux/rfkill.h   |   3 +
 net/rfkill/core.c | 144 +-
 5 files changed, 164 insertions(+), 47 deletions(-)
 delete mode 100644 Documentation/ABI/obsolete/sysfs-class-rfkill

-- 
2.5.0

--
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: [RFC PATCH v4 4/6] livepatch: reuse module loader code to write relocations

[Miroslav Benes]

Hi,

several minor things and nits below. Otherwise it is ok.

On Wed, 3 Feb 2016, Jessica Yu wrote:

> + * Check if a livepatch symbol is formatted properly.
> + *
> + * See Documentation/livepatch/module-elf-format.txt for a
> + * detailed outline of requirements.
> + */
> +static int klp_check_symbol_format(struct module *pmod, Elf_Sym *sym)
> +{
> + size_t len;
> + char *s, *objname, *symname;
> +
> + if (sym->st_shndx != SHN_LIVEPATCH)
> + return -EINVAL;
> +
> + /*
> +  * Livepatch symbol names must follow this format:
> +  * .klp.sym.objname.symbol_name,sympos
> +  */
> + s = pmod->strtab + sym->st_name;
> + /* [.klp.sym.]objname.symbol_name,sympos */
> + if (!s || strncmp(s, KLP_SYM_PREFIX, KLP_SYM_PREFIX_LEN))
> + return -EINVAL;
> +
> + /* .klp.sym.[objname].symbol_name,sympos */
> + objname = s + KLP_SYM_PREFIX_LEN;
> + len = strcspn(objname, ".");
> + if (!(len > 0))
> + return -EINVAL;

strcspn() returns size_t, so we can check only for 0

if (!len)
return -EINVAL

> +
> + /* .klp.sym.objname.symbol_name,[sympos] */
> + if (!strchr(s, ','))
> + return -EINVAL;
> +
> + /* .klp.sym.objname.[symbol_name],sympos */
> + symname = objname + len + 1;
> + len = strcspn(symname, ",");
> + if (!(len > 0))
> + return -EINVAL;

Same here.

> +
> + return 0;
> +}
> +
> +/*
> + * Check if a livepatch relocation section is formatted properly.
> + *
> + * See Documentation/livepatch/module-elf-format.txt for a
> + * detailed outline of requirements.
> + */
> +static int klp_check_relasec_format(struct module *pmod, Elf_Shdr *relasec)
> +{
> + char *secname;
> + size_t len;
> +

This is really a nitpick, but you have a comment about mandatory format of 
the name here in klp_check_symbol_format().

> + secname = pmod->klp_info->secstrings + relasec->sh_name;
> + /* [.klp.rela.]objname.section_name */
> + if (!secname || strncmp(secname, KLP_RELASEC_PREFIX,
> + KLP_RELASEC_PREFIX_LEN))
> + return -EINVAL;
> +
> + /* .klp.rela.[objname].section_name */
> + len = strcspn(secname + KLP_RELASEC_PREFIX_LEN, ".");
> + if (!(len > 0))
> + return -EINVAL;

You don't check if section_name part is non-empty.

[...]

> +/* .klp.sym.[objname].symbol_name,sympos */
> +static int klp_get_sym_objname(char *s, char **result)
> +{

Do we need result to be a double-pointer? If I am not mistaken just 'char 
*result' could be sufficient. You check the return value, so result could 
be NULL or objname as found. No?

> + size_t len;
> + char *objname, *objname_start;
> +
> + /* .klp.sym.[objname].symbol_name,sympos */
> + objname_start = s + KLP_SYM_PREFIX_LEN;
> + len = strcspn(objname_start, ".");
> + objname = kstrndup(objname_start, len, GFP_KERNEL);
> + if (objname == NULL)
> + return -ENOMEM;
> +
> + /* klp_find_object_symbol() treats NULL as vmlinux */
> + if (!strcmp(objname, "vmlinux")) {
> + *result = NULL;
> + kfree(objname);
> + } else
> + *result = objname;

According to CodingStyle there should be curly braces even for else 
branch.

> + return 0;
> +}
> +
> +/* .klp.sym.objname.[symbol_name],sympos */
> +static int klp_get_symbol_name(char *s, char **result)

Same here.

> +{
> + size_t len;
> + char *objname, *symname;
> +
> + /* .klp.sym.[objname].symbol_name,sympos */
> + objname = s + KLP_SYM_PREFIX_LEN;
> + len = strcspn(objname, ".");
> +
> + /* .klp.sym.objname.[symbol_name],sympos */
> + symname = objname + len + 1;
> + len = strcspn(symname, ",");
> +
> + *result = kstrndup(symname, len, GFP_KERNEL);
> + if (*result == NULL)
> + return -ENOMEM;
> +
> + return 0;
> +}

[...]
> +static int klp_resolve_symbols(Elf_Shdr *relasec, struct module *pmod)
>  {
> - const struct kernel_symbol *sym;
> -
> - /* first, check if it's an exported symbol */
> - preempt_disable();
> - sym = find_symbol(name, NULL, NULL, true, true);
> - if (sym) {
> - *addr = sym->value;
> - preempt_enable();
> - return 0;
> + int i, ret = 0;
> + Elf_Rela *relas;
> + Elf_Sym *sym;
> + char *s, *symbol_name, *sym_objname;
> + unsigned long sympos;
> +
> + relas = (Elf_Rela *) relasec->sh_addr;
> + /* For each rela in this .klp.rela. section */
> + for (i = 0; i < relasec->sh_size / sizeof(Elf_Rela); i++) {
> + sym = pmod->symtab + ELF_R_SYM(relas[i].r_info);
> +
> + /* Check if the symbol is formatted correctly */
> + ret = klp_check_symbol_format(pmod, sym);
> + if (ret)
> + goto out;
> + /* Format: .klp.sym.objname.symbol_name,sympos */
> + s = pmod->strtab + sym->st_name;
> + 

Re: [RFC PATCH v4 0/6] (mostly) Arch-independent livepatch

[Miroslav Benes]

On Wed, 3 Feb 2016, Jessica Yu wrote:

> Jessica Yu (6):
>   Elf: add livepatch-specific Elf constants
>   module: preserve Elf information for livepatch modules
>   module: s390: keep mod_arch_specific for livepatch modules
>   livepatch: reuse module loader code to write relocations
>   samples: livepatch: mark as livepatch module
>   Documentation: livepatch: outline Elf format and requirements for
> patch modules

Hi,

I walked through the code and it looks good except for several minor 
things in the fourth patch (livepatch: reuse module loader code to write 
relocations). I'd propose to send the next version as a regular PATCH set 
and not RFC. We can start collecting Reviews and Acks. Hopefully it won't 
take more than one or two iterations. Would that be ok with everyone?

Thanks,
Miroslav
--
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 V2 3/6] stm class: provision for statically assigned masterIDs

[Alexander Shishkin]

Mathieu Poirier  writes:

> On 5 February 2016 at 05:52, Alexander Shishkin
>  wrote:
>> Chunyan Zhang  writes:
>>
>>> From: Mathieu Poirier 
>>>
>>> Some architecture like ARM assign masterIDs statically at the HW design
>>> phase, making masterID manipulation in the generic STM core irrelevant.
>>>
>>> This patch adds a new 'mstatic' flag to struct stm_data that tells the
>>> core that this specific STM device doesn't need explicit masterID
>>> management.
>>
>> So why do we need this patch? If your STM only has master 42 allocated
>> for software sources, simply set sw_start = 42, sw_end = 42 and you're
>> good to go, software will have exactly one channel to choose from. See
>> also the comment from :
>
> On ARM each source, i.e entity capable of accessing STM channels, has
> a different master ID set in HW.  We can't assume the IDs are
> contiguous and from a SW point of view there is no way to probe the
> values.

Ok, it's the 'static' word that got me confused. From Mike's explanation
it seems to me that it's the antithesis of static; the master ID
assignment is so dynamic that it's not controllable by the software and
may or may not reflect core id, power state, phase of the moon, etc.

>>> In the core sw_start/end of masterID are set to '1',
>>> i.e there is only one masterID to deal with.
>>
>> This is also a completely arbitrary and unnecessary requirement. Again,
>> you can set both to 42 and it will still work.
>
> True - any value will do. The important thing to remember is that on
> ARM, there is only one masterID channel (from an STM core point of
> view).  But we could also proceed differently, see below for more
> details.

Well, we have the masters attribute with two numbers in it that define
the range of master IDs that the software can choose from. More
specifically to this situation:

 * the number of channel ID spaces available to the SW is
   $end - $start + 1, that is, in your case, just 1;
 * the number of master IDs for the SW to choose from is $end - $start;
 * if $end==$start, their actual numeric value doesn't really matter,
   either for the policy definition or for the actual writers.

This $end==$start situation itself may be ambiguous and can be
interpreted either as having just one *static* master ID fixed for all
SW writers (what I assumed from your commit message) or as having a
floating master ID, which changes of its own accord and is not
controllable by software.

These two situations are really the same thing from the perspective of
the system under tracing. Also, both of these situations should already
work if the driver sets both sw_start and sw_end to the same
value.

Regards,
--
Alex
--
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 v2] tty: serial: meson: Implement earlycon support

[Andreas Färber]

Split off the bulk of the existing meson_serial_console_write()
implementation into meson_serial_port_write() for implementing
meson_serial_early_console_write().

Signed-off-by: Andreas Färber 
---
 v1 -> v2:
 * Implement meson_serial_early_console_write() instead of reusing
   meson_serial_console_write() (Peter)
 
 Documentation/kernel-parameters.txt |  6 ++
 drivers/tty/serial/meson_uart.c | 42 ++---
 2 files changed, 41 insertions(+), 7 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 59e15150a9d8..237f0ee20afb 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1025,6 +1025,12 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
the driver will use only 32-bit accessors to read/write
the device registers.
 
+   meson_serial,
+   Start an early, polled-mode console on a meson serial
+   port at the specified address. The serial port must
+   already be setup and configured. Options are not yet
+   supported.
+
msm_serial,
Start an early, polled-mode console on an msm serial
port at the specified address. The serial port
diff --git a/drivers/tty/serial/meson_uart.c b/drivers/tty/serial/meson_uart.c
index b12a37bd37b6..9efcfa2de31e 100644
--- a/drivers/tty/serial/meson_uart.c
+++ b/drivers/tty/serial/meson_uart.c
@@ -475,18 +475,13 @@ static void meson_console_putchar(struct uart_port *port, 
int ch)
writel(ch, port->membase + AML_UART_WFIFO);
 }
 
-static void meson_serial_console_write(struct console *co, const char *s,
-  u_int count)
+static void meson_serial_port_write(struct uart_port *port, const char *s,
+   u_int count)
 {
-   struct uart_port *port;
unsigned long flags;
int locked;
u32 val, tmp;
 
-   port = meson_ports[co->index];
-   if (!port)
-   return;
-
local_irq_save(flags);
if (port->sysrq) {
locked = 0;
@@ -510,6 +505,18 @@ static void meson_serial_console_write(struct console *co, 
const char *s,
local_irq_restore(flags);
 }
 
+static void meson_serial_console_write(struct console *co, const char *s,
+  u_int count)
+{
+   struct uart_port *port;
+
+   port = meson_ports[co->index];
+   if (!port)
+   return;
+
+   meson_serial_port_write(port, s, count);
+}
+
 static int meson_serial_console_setup(struct console *co, char *options)
 {
struct uart_port *port;
@@ -548,6 +555,27 @@ static int __init meson_serial_console_init(void)
 }
 console_initcall(meson_serial_console_init);
 
+static void meson_serial_early_console_write(struct console *co,
+const char *s,
+u_int count)
+{
+   struct earlycon_device *dev = co->data;
+
+   meson_serial_port_write(&dev->port, s, count);
+}
+
+static int __init
+meson_serial_early_console_setup(struct earlycon_device *device, const char 
*opt)
+{
+   if (!device->port.membase)
+   return -ENODEV;
+
+   device->con->write = meson_serial_early_console_write;
+   return 0;
+}
+OF_EARLYCON_DECLARE(meson_serial, "amlogic,meson-uart",
+   meson_serial_early_console_setup);
+
 #define MESON_SERIAL_CONSOLE   (&meson_serial_console)
 #else
 #define MESON_SERIAL_CONSOLE   NULL
-- 
2.6.2

--
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] Doc: DocBook: Fix a typo in device-drivers.tmpl

[Masanari Iida]

This patch fix a spelling typo in device-drivers.tmpl.

Signed-off-by: Masanari Iida 
---
 Documentation/DocBook/device-drivers.tmpl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/DocBook/device-drivers.tmpl 
b/Documentation/DocBook/device-drivers.tmpl
index cc303a2..184f3c7 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -369,7 +369,7 @@ X!Ilib/fonts/fonts.c
 !Iinclude/linux/input-polldev.h
 !Edrivers/input/input-polldev.c
  
- Matrix keyboars/keypads
+ Matrix keyboards/keypads
 !Iinclude/linux/input/matrix_keypad.h
  
  Sparse keymap support
-- 
2.7.1.250.gff4ea60

--
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] tty: serial: meson: Implement earlycon support

[Andreas Färber]

Hi Peter,

Am 08.02.2016 um 05:22 schrieb Peter Hurley:
> On 02/07/2016 12:57 PM, Andreas Färber wrote:
>> Reuse the existing console write implementation for implementing
>> DT-based and command-line-based earlycon support.
>>
>> Signed-off-by: Andreas Färber 
>> ---
>>  Documentation/kernel-parameters.txt |  6 ++
>>  drivers/tty/serial/meson_uart.c | 13 +
>>  2 files changed, 19 insertions(+)
>>
>> diff --git a/Documentation/kernel-parameters.txt 
>> b/Documentation/kernel-parameters.txt
>> index 602065c..90801ac 100644
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -1030,6 +1030,12 @@ Such letter suffixes can also be entirely omitted.
>>  the driver will use only 32-bit accessors to read/write
>>  the device registers.
>>  
>> +meson_serial,
>> +Start an early, polled-mode console on a meson serial
>> +port at the specified address. The serial port must
>> +already be setup and configured. Options are not yet
>> +supported.
>> +
>>  msm_serial,
>>  Start an early, polled-mode console on an msm serial
>>  port at the specified address. The serial port
>> diff --git a/drivers/tty/serial/meson_uart.c 
>> b/drivers/tty/serial/meson_uart.c
>> index b12a37b..6f89567 100644
>> --- a/drivers/tty/serial/meson_uart.c
>> +++ b/drivers/tty/serial/meson_uart.c
>> @@ -548,6 +548,19 @@ static int __init meson_serial_console_init(void)
>>  }
>>  console_initcall(meson_serial_console_init);
>>  
>> +static int __init
>> +meson_serial_early_console_setup(struct earlycon_device *device, const char 
>> *opt)
>> +{
>> +if (!device->port.membase)
>> +return -ENODEV;
>> +
>> +device->con->write = meson_serial_console_write;
> 
> meson_serial_console_write() is not appropriate for earlycon; it assumes the
> earlycon port is the same as the driver port (it isn't).

Thanks for spotting that.

I forgot to mention that I tested this on arm64, where there is no
earlyprintk any more, seemingly successfully getting a bootconsole
uart0. Using co->data instead of co->index I now get meson_serial0
instead, doh.

This probably slipped though because another patch is necessary for
fixing the baudrate calculation on my device.

>> +return 0;
>> +}
>> +EARLYCON_DECLARE(meson_serial, meson_serial_early_console_setup);
>> +OF_EARLYCON_DECLARE(meson_serial, "amlogic,meson-uart",
>> +meson_serial_early_console_setup);
> 
> With today's linux-next (or Greg's tty-next tree), it is no longer necessary 
> to
> declare separate earlycon's when you want both; OF_EARLYCON_DECLARE() declares
> both a devicetree-enabled earlycon and automatically provides for a command 
> line
> earlycon of the same name.

Thanks for the hint, it was based on linux-next from a couple days ago.

Is there any guidance wrt naming? I noticed that msm uses -uart in the
compatible string and _serial for earlycon, so I copied that; should it
rather be meson_uart or just meson?

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)
--
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: [PATCHv9 1/4] EDAC, altera: Add Altera L2 Cache and OCRAM EDAC Support

[Borislav Petkov]

On Wed, Jan 27, 2016 at 10:13:20AM -0600, ttha...@opensource.altera.com wrote:
> From: Thor Thayer 
> 
> Adding L2 Cache and On-Chip RAM EDAC support for the
> Altera SoCs using the EDAC device  model. The SDRAM
> controller is using the Memory Controller model.
> 
> Each type of ECC is individually configurable.
> 
> Signed-off-by: Thor Thayer 
> ---
> v9: Improve device tree node release. Free managed resources
> on error path. Fix ocram memory leak.
> v8: Remove MASK from single bit mask names.
> s/altr,edac/altr,socfpga-ecc-manager
> Use debugfs instead of sysfs.
> Add chip family name to match string.
> Fix header year.
> Fix build dependencies & change commit accordingly.
> s/CONFIG_EDAC_ALTERA_MC/CONFIG_EDAC_ALTERA
> v7: s/of_get_named_gen_pool/of_gen_pool_get
> Remove #ifdef for EDAC_DEBUG
> Use -ENODEV instead of EPROBE_DEFER
> v6: Convert to nested EDAC in device tree. Force L2 cache
> on for L2Cache ECC & remove L2 cache syscon for checking
> enable bit. Update year in header.
> v5: No change.
> v4: Change mask defines to use BIT().
> Fix comment style to agree with kernel coding style.
> Better printk description for read != write in trigger.
> Remove SysFS debugging message.
> Better dci->mod_name
> Move gen_pool pointer assignment to end of function.
> Invert logic to reduce indent in ocram depenency check.
> Change from dev_err() to edac_printk()
> Replace magic numbers with defines & comments.
> Improve error injection test.
> Change Makefile intermediary name to altr (from alt)
> v3: Move OCRAM and L2 cache EDAC functions into altera_edac.c
> instead of separate files.
> v2: Fix L2 dependency comments.
> ---
>  drivers/edac/Kconfig   |   26 ++-
>  drivers/edac/Makefile  |2 +-
>  drivers/edac/altera_edac.c |  487 
> +++-
>  3 files changed, 507 insertions(+), 8 deletions(-)

I'm still waiting for the people on CC to confirm the DT changes. A
couple of comments on the EDAC bits below.





> +static irqreturn_t altr_edac_device_handler(int irq, void *dev_id)
> +{
> + struct edac_device_ctl_info *dci = dev_id;
> + struct altr_edac_device_dev *drvdata = dci->pvt_info;
> + const struct edac_device_prv_data *priv = drvdata->data;
> +
> + if (irq == drvdata->sb_irq) {
> + if (priv->ce_clear_mask)
> + writel(priv->ce_clear_mask, drvdata->base);
> + edac_device_handle_ce(dci, 0, 0, drvdata->edac_dev_name);
> + }
> + if (irq == drvdata->db_irq) {
> + if (priv->ue_clear_mask)
> + writel(priv->ue_clear_mask, drvdata->base);
> + edac_device_handle_ue(dci, 0, 0, drvdata->edac_dev_name);
> + panic("\nEDAC:ECC_DEVICE[Uncorrectable errors]\n");
> + }

And irq is guaranteed to always be ->sb_irq or ->db_irq?

Otherwise, you can do

else
WARN_ON(1);

just in case.

> +
> + return IRQ_HANDLED;
> +}

...

> +/*
> + * altr_edac_device_probe()
> + *   This is a generic EDAC device driver that will support
> + *   various Altera memory devices such as the L2 cache ECC and
> + *   OCRAM ECC as well as the memories for other peripherals.
> + *   Module specific initialization is done by passing the
> + *   function index in the device tree.
> + */
> +static int altr_edac_device_probe(struct platform_device *pdev)
> +{
> + struct edac_device_ctl_info *dci;
> + struct altr_edac_device_dev *drvdata;
> + struct resource *r;
> + int res = 0;
> + struct device_node *np = pdev->dev.of_node;
> + char *ecc_name = (char *)np->name;
> + static int dev_instance;
> + struct dentry *debugfs;
> +
> + if (!devres_open_group(&pdev->dev, NULL, GFP_KERNEL)) {
> + edac_printk(KERN_ERR, EDAC_DEVICE,
> + "Unable to open devm\n");
> + return -ENOMEM;
> + }
> +
> + r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!r) {
> + edac_printk(KERN_ERR, EDAC_DEVICE,
> + "Unable to get mem resource\n");
> + res = -ENODEV;
> + goto fail;
> + }
> +
> + if (!devm_request_mem_region(&pdev->dev, r->start, resource_size(r),
> +  dev_name(&pdev->dev))) {
> + edac_printk(KERN_ERR, EDAC_DEVICE,
> + "%s:Error requesting mem region\n", ecc_name);
> + res = -EBUSY;
> + goto fail;
> + }
> +
> + dci = edac_device_alloc_ctl_info(sizeof(*drvdata), ecc_name,
> +  1, ecc_name, 1, 0, NULL, 0,
> +  dev_instance++);
> +
> + if (!dci) {
> + edac_printk(KERN_ERR, EDAC_DEVICE,
> + "%s: Unable to allocate EDAC device\n", ecc_name);
> + res = -ENOMEM;
> + goto fail;
> + }

Re: [PATCH v4 03/11] drm/hisilicon: Add crtc driver for ADE

[Archit Taneja]

On 02/06/2016 08:54 AM, Xinliang Liu wrote:

Add crtc funcs and helper funcs for ADE.

v4: None.
v3:
- Make ade as the master driver.
- Use port to connect with encoder.
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu 
---
  drivers/gpu/drm/hisilicon/kirin/Makefile|   3 +-
  drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h | 280 +++
  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 458 
  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  15 +
  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |   8 +
  5 files changed, 763 insertions(+), 1 deletion(-)
  create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
  create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c

diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile 
b/drivers/gpu/drm/hisilicon/kirin/Makefile
index cb346de47d48..2a61ab006ddb 100644
--- a/drivers/gpu/drm/hisilicon/kirin/Makefile
+++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
@@ -1,3 +1,4 @@
-kirin-drm-y := kirin_drm_drv.o
+kirin-drm-y := kirin_drm_drv.o \
+  kirin_drm_ade.o

  obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h 
b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
new file mode 100644
index ..78020747abfe
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
@@ -0,0 +1,280 @@
+/*
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#ifndef __KIRIN_ADE_REG_H__
+#define __KIRIN_ADE_REG_H__
+
+/*
+ * ADE Registers
+ */
+#define MASK(x)(BIT(x) - 1)
+
+#define ADE_CTRL   0x0004
+#define FRM_END_START_OFST 0
+#define FRM_END_START_MASK MASK(2)
+#define ADE_CTRL1  0x008C
+#define AUTO_CLK_GATE_EN_OFST  0
+#define AUTO_CLK_GATE_EN   BIT(0)
+#define ADE_ROT_SRC_CFG0x0010
+#define ADE_DISP_SRC_CFG   0x0018
+#define ADE_WDMA2_SRC_CFG  0x001C
+#define ADE_SEC_OVLY_SRC_CFG   0x0020
+#define ADE_WDMA3_SRC_CFG  0x0024
+#define ADE_OVLY1_TRANS_CFG0x002C
+#define ADE_EN 0x0100
+#define ADE_DISABLE0
+#define ADE_ENABLE 1
+#define INTR_MASK_CPU(x)   (0x0C10 + (x) * 0x4)
+#define ADE_FRM_DISGARD_CTRL   0x00A4
+/* reset and reload regs */
+#define ADE_SOFT_RST_SEL(x)(0x0078 + (x) * 0x4)
+#define ADE_RELOAD_DIS(x)  (0x00AC + (x) * 0x4)
+#define RDMA_OFST  0
+#define CLIP_OFST  15
+#define SCL_OFST   21
+#define CTRAN_OFST 24
+#define OVLY_OFST  37 /* 32+5 */
+/* channel regs */
+#define RD_CH_PE(x)(0x1000 + (x) * 0x80)
+#define RD_CH_CTRL(x)  (0x1004 + (x) * 0x80)
+#define RD_CH_ADDR(x)  (0x1008 + (x) * 0x80)
+#define RD_CH_SIZE(x)  (0x100C + (x) * 0x80)
+#define RD_CH_STRIDE(x)(0x1010 + (x) * 0x80)
+#define RD_CH_SPACE(x) (0x1014 + (x) * 0x80)
+#define RD_CH_PARTIAL_SIZE(x)  (0x1018 + (x) * 0x80)
+#define RD_CH_PARTIAL_SPACE(x) (0x101C + (x) * 0x80)
+#define RD_CH_EN(x)(0x1020 + (x) * 0x80)
+#define RD_CH_STATUS(x)(0x1024 + (x) * 0x80)
+#define RD_CH_DISP_CTRL0x1404
+#define RD_CH_DISP_ADDR0x1408
+#define RD_CH_DISP_SIZE0x140C
+#define RD_CH_DISP_STRIDE  0x1410
+#define RD_CH_DISP_SPACE   0x1414
+#define RD_CH_DISP_EN  0x142C
+/* clip regs */
+#define ADE_CLIP_DISABLE(x)(0x6800 + (x) * 0x100)
+#define ADE_CLIP_SIZE0(x)  (0x6804 + (x) * 0x100)
+#define ADE_CLIP_SIZE1(x)  (0x6808 + (x) * 0x100)
+#define ADE_CLIP_SIZE2(x)  (0x680C + (x) * 0x100)
+#define ADE_CLIP_CFG_OK(x) (0x6810 + (x) * 0x100)
+/* scale regs */
+#define ADE_SCL1_MUX_CFG   0x000C
+#define ADE_SCL2_SRC_CFG   0x0014
+#define ADE_SCL3_MUX_CFG   0x0008
+#define ADE_SCL_CTRL(x)(0x3000 + (x) * 0x800)
+#define ADE_SCL_HSP(x) (0x3004 + (x) * 0x800)
+#define ADE_SCL_UV_HSP(x)  (0x3008 + (x) * 0x800)
+#define ADE_SCL_VSP(x) (0x300C + (x) * 0x800)
+#define ADE_SCL_UV_VSP(x)  (0x3010 + (x) * 0x800)
+#define ADE_SCL_ORES(x)(0x3014 + (x) * 0x800)
+#define ADE_SCL_IRES(x)(0x3018 + (x) * 0x800)
+#define ADE_SCL_START(x)   

RE: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs

[Alexander Shishkin]

Mike Leach  writes:

> Hi,
>
> I think a quick clarification of the ARM hardware STM architecture may be of 
> value here.
>
> The ARM hardware STM, when implemented as recommend in a hardware design, the 
> master IDs are not under driver control, but have a hardwire association with 
> source devices in the system. The master IDs are hardwired to individual 
> cores and core security states, and there could be other IDs associated with 
> hardware trace sources requiring output via the hardware STM. (an example of 
> this is the ARM Juno development board).
>
> Therefore in multi-core systems many masters may be associated with a single 
> software STM stream. A user-space application running on Core 1, may have a 
> master ID of 0x11 in the STPv2 trace stream, but if this application is 
> context switched and later continues running on Core 2, then master ID could 
> change to 0x21.  Masters identify a hardware source in this scheme, the 
> precise values used will be implementation dependent.
>
> So the number of masters "available to the software" depends on your 
> interpretation of the phrase.
> If you mean "master IDs on which software trace will appear" then that will 
> be many - it depends on which core is running the application. However as 
> described above, this is not predictable by any decoder, and the master set 
> used may not be contiguous.
> If you mean "master IDs selectable/allocated by the driver" then that will be 
> 0 - the driver has no control, and possibly no knowledge of which master is 
> associated with the current execution context. (this is of course system 
> dependent - it may well be possible to have some configuration database 
> associating cores with hardware IDs, but this will be implementation and 
> board support dependant).
>
> Therefore, there is a requirement to tell both the user-space STM client and 
> decoder that not only is master ID management not needed - it is in fact not 
> possible and the key to identify the software source for a given STM packet 
> is the channel alone. In addition we have a nominal single Master ID 
> "available to the software", to satisfy the requirements of the generic ST 
> module API.
>
> So on Juno for example, while we do have 128 masters, each with 65536 
> channels, the master allocation is not visible to system software - each core 
> sees a single master with 65536 channels. Therefore differentiation between 
> software sources in the STM trace is by channel number allocations only.

Ok, thanks a lot for the detailed explanation. I was confused by the
"static" bit in the patch description. It looks like something along the
lines of this patch might indeed be in order.

Regards,
--
Alex
--
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 v4 01/11] drm/hisilicon: Add device tree binding for hi6220 display subsystem

[Archit Taneja]

Hi,

On 02/06/2016 08:54 AM, Xinliang Liu wrote:

Add ADE display controller binding doc.
Add DesignWare DSI Host Controller v1.20a binding doc.

v4:
- Describe more specific of clocks and ports.
- Fix indentation.
v3:
- Make ade as the drm master node.
- Use assigned-clocks to set clock rate.
- Use ports to connect display relavant nodes.
v2:
- Move dt binding docs to bindings/display/hisilicon directory.

Signed-off-by: Xinwei Kong 
Signed-off-by: Xinliang Liu 
---
  .../bindings/display/hisilicon/dw-dsi.txt  | 77 ++
  .../bindings/display/hisilicon/hisi-ade.txt| 69 +++
  2 files changed, 146 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
  create mode 100644 
Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt

diff --git a/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt 
b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
new file mode 100644
index ..af6d702f3282
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
@@ -0,0 +1,77 @@
+Device-Tree bindings for DesignWare DSI Host Controller v1.20a driver
+
+A DSI Host Controller resides in the middle of display controller and external
+HDMI converter.
+
+Required properties:
+- compatible: value should be "hisilicon,hi6220-dsi".
+- reg: physical base address and length of dsi controller's registers.
+- clocks: the clocks needed.
+- clock-names: the name of the clocks.
+- ports: contains DSI controller input and output sub port.
+  The input port connects to ADE output port with the reg value "0".
+  The output port with the reg value "1", it could connect to panel or
+  any other bridge endpoints. And the reg value for bridge endpoint is "0",
+  other values for panel endpoint.
+  See Documentation/devicetree/bindings/graph.txt for more device graph info.
+
+A example of HiKey board hi6220 SoC and board specific DT entry:
+Example:
+
+SoC specific:
+   dsi: dsi@f4107800 {
+   compatible = "hisilicon,hi6220-dsi";
+   reg = <0x0 0xf4107800 0x0 0x100>;
+   clocks = <&media_ctrl  HI6220_DSI_PCLK>;
+   clock-names = "pclk_dsi";
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* 0 for input port */
+   port@0 {
+   reg = <0>;
+   dsi_in: endpoint {
+   remote-endpoint = <&ade_out>;
+   };
+   };
+   };
+   };
+
+
+Board specific:
+   &dsi {
+   status = "ok";
+
+   ports {
+   /* 1 for output port */
+   port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   /* 0 for bridge, other value for panel */
+   dsi_out0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <&adv7533_in>;
+   };
+   };
+   };
+   };
+
+   &i2c2 {
+   ...
+
+   adv7533: adv7533@39 {
+   ...
+
+   port {
+   adv7533_in: endpoint {
+   remote-endpoint = <&dsi_out0>;
+   };
+   };
+   };
+   };
+
diff --git a/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt 
b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
new file mode 100644
index ..1eff5a41b98d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
@@ -0,0 +1,69 @@
+Device-Tree bindings for hisilicon ADE display controller driver
+
+ADE (Advanced Display Engine) is the display controller which grab image
+data from memory, do composition, do post image processing, generate RGB
+timing stream and transfer to DSI.
+
+Required properties:
+- compatible: value should be "hisilicon,hi6220-ade".
+- reg: physical base address and length of the controller's registers.
+  Three reg ranges are used in ADE driver:
+  ADE reg range, value should be "<0x0 0xf410 0x0 0x7800>";
+  media subsystem reg range, value should be "<0x0 0xf441 0x0 0x1000>";
+  media subsystem NOC QoS reg range, value should be "<0x0 0xf452 0x0
+  0x1000>".
+- reg-names: name of physical base.Valuse should be "ade_base",  
"media_base"
+  and "media_noc_base".


The "media_base" and "media_noc_base" don't really look like a part of 
the ADE subsytem's MMIO region. If we need to configure these register