[PATCH 0/7] openrisc: Misc fixes from backlog

[PATCH 0/7] openrisc: Misc fixes from backlog

[Stafford Horne]

Hello,

This patch is a small set of fixes from the openrisc backlog. These
changes fix several issues with the openrisc build on modern tool chains
and address other issues which have cropped up as the kernel as it is
being used on newer hardware.

Please consider for merge.

On-the-other-hand

The openrisc project has been missing a kernel maintainer
for some time now. Currently listed in MAINTAINERS is Jonas
and a website that no longer exists.


Some mail threads from Jonas
https://lkml.org/lkml/2015/5/13/469 - mail from Jonas mentioning 
                                      he is no longer able to maintain 
https://lkml.org/lkml/2015/6/11/426 - mail from Jonas mentioning stefan 
                                      is to be the new maintainer

Ideally stefan kristiansson would become the maintainer but he 
does not have a PGP key signed by kernel maintainers.  Also, he
does not seem to have much time recently.

We would like some help on how to proceed, options:
 - Someone take these patches into a branch that will be pulled
   by linus? I can work to maintain the patch queue for openrisc.
 - I can work to get a my PGP key signed and send git pull requests
   to linus?

Regards,
  Stafford


Christian Svensson (1):
  openrisc: Add thread-local storage (TLS) support

Guenter Roeck (1):
  openrisc: Support both old (or32) and new (or1k) toolchain

Jonas Bonn (2):
  Apply transparent_union attribute to union semun
  openrisc: restore call-saved regs on sigreturn

Rob Herring (1):
  openrisc: remove the redundant of_platform_populate

Stefan Kristiansson (2):
  openrisc: fix PTRS_PER_PGD define
  openrisc: add SMP and NR_CPUS Kconfig options

 arch/openrisc/Kconfig               | 14 ++++++++++++++
 arch/openrisc/include/asm/pgtable.h |  2 +-
 arch/openrisc/kernel/entry.S        | 10 +++++++++-
 arch/openrisc/kernel/process.c      | 13 +++++++++++++
 arch/openrisc/kernel/setup.c        | 10 ----------
 arch/openrisc/kernel/vmlinux.lds.S  |  8 +++++++-
 arch/openrisc/mm/init.c             |  2 +-
 include/uapi/linux/sem.h            |  2 +-
 8 files changed, 46 insertions(+), 15 deletions(-)

-- 
2.7.4

[PATCH 1/7] Apply transparent_union attribute to union semun

[Stafford Horne]

From: Jonas Bonn <jonas@southpole.se>

The syscall handler for semctl is written under the assumption that the
toolchain will pass "small" unions as function parameters directly instead
of by reference.  The union semun is "small" and thus fits this description.

Since it is assumed that the union will be passed directly and not by
reference, it is safe to access the union members without going via
get_user.

The OpenRISC architecture, however, passes all unions by reference, thus
breaking the above assumption.

The technically correct fix here is to mark the union as being transparent
so that the ABI of the union's first element determines the parameter
passing method and thus make explicit what's already implied in the function
definition.

Signed-off-by: Jonas Bonn <jonas@southpole.se>
Signed-off-by: Stafford Horne <shorne@gmail.com>
---
 include/uapi/linux/sem.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/linux/sem.h b/include/uapi/linux/sem.h
index dd73b90..aabe50f 100644
--- a/include/uapi/linux/sem.h
+++ b/include/uapi/linux/sem.h
@@ -48,7 +48,7 @@ union semun {
 	unsigned short __user *array;	/* array for GETALL & SETALL */
 	struct seminfo __user *__buf;	/* buffer for IPC_INFO */
 	void __user *__pad;
-};
+} __attribute__ ((transparent_union));
 
 struct  seminfo {
 	int semmap;
-- 
2.7.4

[PATCH 2/7] openrisc: fix PTRS_PER_PGD define

[Stafford Horne]

From: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>

On OpenRISC, with its 8k pages, PAGE_SHIFT is defined to be 13.
That makes the expression (1UL << (PAGE_SHIFT-2)) evaluate
to 2048.
The correct value for PTRS_PER_PGD should be 256.

Correcting the PTRS_PER_PGD define unveiled a bug in map_ram(),
where PTRS_PER_PGD was used when the intent was to iterate
over a set of page table entries.
This patch corrects that issue as well.

Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Signed-off-by: Stafford Horne <shorne@gmail.com>
---
 arch/openrisc/include/asm/pgtable.h | 2 +-
 arch/openrisc/mm/init.c             | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/openrisc/include/asm/pgtable.h b/arch/openrisc/include/asm/pgtable.h
index 69c7df0..3567aa7 100644
--- a/arch/openrisc/include/asm/pgtable.h
+++ b/arch/openrisc/include/asm/pgtable.h
@@ -69,7 +69,7 @@ extern void paging_init(void);
  */
 #define PTRS_PER_PTE	(1UL << (PAGE_SHIFT-2))
 
-#define PTRS_PER_PGD	(1UL << (PAGE_SHIFT-2))
+#define PTRS_PER_PGD	(1UL << (32-PGDIR_SHIFT))
 
 /* calculate how many PGD entries a user-level program can use
  * the first mappable virtual address is 0
diff --git a/arch/openrisc/mm/init.c b/arch/openrisc/mm/init.c
index 7f94652..b782ce9 100644
--- a/arch/openrisc/mm/init.c
+++ b/arch/openrisc/mm/init.c
@@ -110,7 +110,7 @@ static void __init map_ram(void)
 			set_pmd(pme, __pmd(_KERNPG_TABLE + __pa(pte)));
 
 			/* Fill the newly allocated page with PTE'S */
-			for (j = 0; p < e && j < PTRS_PER_PGD;
+			for (j = 0; p < e && j < PTRS_PER_PTE;
 			     v += PAGE_SIZE, p += PAGE_SIZE, j++, pte++) {
 				if (v >= (u32) _e_kernel_ro ||
 				    v < (u32) _s_kernel_ro)
-- 
2.7.4

[PATCH 3/7] openrisc: restore call-saved regs on sigreturn

[Stafford Horne]

From: Jonas Bonn <jonas@southpole.se>

Return to userspace via _resume_userspace instead of via syscall return
path for the rt_sigreturn syscall.

I'll rework this comment more later, but this patch needs testing.

Old comment from previous patch:

The sigreturn syscall is more like a context switch than a function call;
it entails a return from one context (the signal handler) to another
(the process in question).  For a context switch like this there are
effectively no call-saved regs that remain constant across the transition.

This patch restores the call-saved regs from pt_regs before returning from
the syscall, effectively restoring the context that the process had before
being interrupted by the signal handler.  Restoring the call-saved regs
in this way allows us to return to userspace via the usual syscall fast
path.

Reported-by: Sebastian Macke <sebastian@macke.de>
Signed-off-by: Jonas Bonn <jonas@southpole.se>
Signed-off-by: Stafford Horne <shorne@gmail.com>
---
 arch/openrisc/kernel/entry.S | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/openrisc/kernel/entry.S b/arch/openrisc/kernel/entry.S
index fec8bf9..572d223 100644
--- a/arch/openrisc/kernel/entry.S
+++ b/arch/openrisc/kernel/entry.S
@@ -1101,8 +1101,16 @@ ENTRY(__sys_fork)
 	 l.addi	r3,r1,0
 
 ENTRY(sys_rt_sigreturn)
-	l.j	_sys_rt_sigreturn
+	l.jal	_sys_rt_sigreturn
 	 l.addi	r3,r1,0
+	l.sfne	r30,r0
+	l.bnf	_no_syscall_trace
+	 l.nop
+	l.jal	do_syscall_trace_leave
+	 l.addi	r3,r1,0
+_no_syscall_trace:
+	l.j	_resume_userspace
+	 l.nop
 
 /* This is a catch-all syscall for atomic instructions for the OpenRISC 1000.
  * The functions takes a variable number of parameters depending on which
-- 
2.7.4

[PATCH 4/7] openrisc: Add thread-local storage (TLS) support

[Stafford Horne]

From: Christian Svensson <blue@cmd.nu>

Historically OpenRISC GCC has reserved r10 which we now use to hold
the thread pointer for thread-local storage (TLS).

Signed-off-by: Christian Svensson <blue@cmd.nu>
Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Signed-off-by: Stafford Horne <shorne@gmail.com>
---
 arch/openrisc/kernel/process.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/openrisc/kernel/process.c b/arch/openrisc/kernel/process.c
index 7095dfe..277123b 100644
--- a/arch/openrisc/kernel/process.c
+++ b/arch/openrisc/kernel/process.c
@@ -173,6 +173,19 @@ copy_thread(unsigned long clone_flags, unsigned long usp,
 
 		if (usp)
 			userregs->sp = usp;
+
+		/*
+		 * For CLONE_SETTLS set "tp" (r10) to the TLS pointer passed to sys_clone.
+		 *
+		 * The kernel entry is:
+		 *	int clone (long flags, void *child_stack, int *parent_tid,
+		 *		int *child_tid, struct void *tls)
+		 *
+		 * This makes the source r7 in the kernel registers.
+		 */
+		if (clone_flags & CLONE_SETTLS)
+			userregs->gpr[10] = userregs->gpr[7];
+
 		userregs->gpr[11] = 0;	/* Result from fork() */
 
 		kregs->gpr[20] = 0;	/* Userspace thread */
-- 
2.7.4

[PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Stafford Horne]

From: Guenter Roeck <linux@roeck-us.net>

The output file format for or1k has changed from "elf32-or32"
to "elf32-or1k". Select the correct output format automatically
to be able to compile the kernel with both toolchain variants.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Stafford Horne <shorne@gmail.com>
---
 arch/openrisc/kernel/vmlinux.lds.S | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/openrisc/kernel/vmlinux.lds.S b/arch/openrisc/kernel/vmlinux.lds.S
index d936de4..4a72d5d 100644
--- a/arch/openrisc/kernel/vmlinux.lds.S
+++ b/arch/openrisc/kernel/vmlinux.lds.S
@@ -30,7 +30,13 @@
 #include <asm/cache.h>
 #include <asm-generic/vmlinux.lds.h>
 
-OUTPUT_FORMAT("elf32-or32", "elf32-or32", "elf32-or32")
+#ifdef __OR1K__
+#define __OUTPUT_FORMAT        "elf32-or1k"
+#else
+#define __OUTPUT_FORMAT        "elf32-or32"
+#endif
+
+OUTPUT_FORMAT(__OUTPUT_FORMAT, __OUTPUT_FORMAT, __OUTPUT_FORMAT)
 jiffies = jiffies_64 + 4;
 
 SECTIONS
-- 
2.7.4

[PATCH 6/7] openrisc: add SMP and NR_CPUS Kconfig options

[Stafford Horne]

From: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>

Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Signed-off-by: Stafford Horne <shorne@gmail.com>
---
 arch/openrisc/Kconfig | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig
index 489e7f9..2bcf8c3 100644
--- a/arch/openrisc/Kconfig
+++ b/arch/openrisc/Kconfig
@@ -98,6 +98,20 @@ config OPENRISC_HAVE_INST_DIV
 	  Select this if your implementation has a hardware divide instruction
 endmenu
 
+config NR_CPUS
+	int "Maximum number of CPUs (2-32)"
+	range 2 32
+	depends on SMP
+	default "2"
+
+config SMP
+	bool "Symmetric Multi-Processing support"
+	help
+	  This enables support for systems with more than one CPU. If you have
+	  a system with only one CPU, say N. If you have a system with more
+	  than one CPU, say Y.
+
+	  If you don't know what to do here, say N.
 
 source kernel/Kconfig.hz
 source kernel/Kconfig.preempt
-- 
2.7.4

[PATCH 7/7] openrisc: remove the redundant of_platform_populate

[Stafford Horne]

From: Rob Herring <robh@kernel.org>

The of_platform_populate call in the openrisc arch code is now redundant
as the DT core provides a default call. Openrisc has a NULL match table
which means only top level nodes with compatible strings will have
devices creates. The default version will also descend nodes in the
match table such as "simple-bus" which should be fine as openrisc
doesn't have any of these (though it is preferred that memory-mapped
peripherals be grouped under a bus node(s)).

Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Jonas Bonn <jonas@southpole.se>
Signed-off-by: Stafford Horne <shorne@gmail.com>
---
 arch/openrisc/kernel/setup.c | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/arch/openrisc/kernel/setup.c b/arch/openrisc/kernel/setup.c
index b4ed8b3..d2f78cf 100644
--- a/arch/openrisc/kernel/setup.c
+++ b/arch/openrisc/kernel/setup.c
@@ -38,7 +38,6 @@
 #include <linux/of.h>
 #include <linux/memblock.h>
 #include <linux/device.h>
-#include <linux/of_platform.h>
 
 #include <asm/sections.h>
 #include <asm/segment.h>
@@ -219,15 +218,6 @@ void __init or32_early_setup(void *fdt)
 	early_init_devtree(fdt);
 }
 
-static int __init openrisc_device_probe(void)
-{
-	of_platform_populate(NULL, NULL, NULL, NULL);
-
-	return 0;
-}
-
-device_initcall(openrisc_device_probe);
-
 static inline unsigned long extract_value_bits(unsigned long reg,
 					       short bit_nr, short width)
 {
-- 
2.7.4

Re: [PATCH 0/7] openrisc: Misc fixes from backlog

[Stafford Horne]

Forgot to CC the new openrisc list.

On Fri, 16 Sep 2016, Stafford Horne wrote:

> Hello,
>
> This patch is a small set of fixes from the openrisc backlog. These
> changes fix several issues with the openrisc build on modern tool chains
> and address other issues which have cropped up as the kernel as it is
> being used on newer hardware.
>
> Please consider for merge.
>
> On-the-other-hand
>
> The openrisc project has been missing a kernel maintainer
> for some time now. Currently listed in MAINTAINERS is Jonas
> and a website that no longer exists.
>
>
> Some mail threads from Jonas
> https://lkml.org/lkml/2015/5/13/469 - mail from Jonas mentioning
>                                      he is no longer able to maintain
> https://lkml.org/lkml/2015/6/11/426 - mail from Jonas mentioning stefan
>                                      is to be the new maintainer
>
> Ideally stefan kristiansson would become the maintainer but he
> does not have a PGP key signed by kernel maintainers.  Also, he
> does not seem to have much time recently.
>
> We would like some help on how to proceed, options:
> - Someone take these patches into a branch that will be pulled
>   by linus? I can work to maintain the patch queue for openrisc.
> - I can work to get a my PGP key signed and send git pull requests
>   to linus?
>
> Regards,
>  Stafford
>
>
> Christian Svensson (1):
>  openrisc: Add thread-local storage (TLS) support
>
> Guenter Roeck (1):
>  openrisc: Support both old (or32) and new (or1k) toolchain
>
> Jonas Bonn (2):
>  Apply transparent_union attribute to union semun
>  openrisc: restore call-saved regs on sigreturn
>
> Rob Herring (1):
>  openrisc: remove the redundant of_platform_populate
>
> Stefan Kristiansson (2):
>  openrisc: fix PTRS_PER_PGD define
>  openrisc: add SMP and NR_CPUS Kconfig options
>
> arch/openrisc/Kconfig               | 14 ++++++++++++++
> arch/openrisc/include/asm/pgtable.h |  2 +-
> arch/openrisc/kernel/entry.S        | 10 +++++++++-
> arch/openrisc/kernel/process.c      | 13 +++++++++++++
> arch/openrisc/kernel/setup.c        | 10 ----------
> arch/openrisc/kernel/vmlinux.lds.S  |  8 +++++++-
> arch/openrisc/mm/init.c             |  2 +-
> include/uapi/linux/sem.h            |  2 +-
> 8 files changed, 46 insertions(+), 15 deletions(-)
>
> -- 
> 2.7.4
>
>

[OpenRISC] [PATCH 0/7] openrisc: Misc fixes from backlog

[Stafford Horne]

Forgot to CC the new openrisc list.

On Fri, 16 Sep 2016, Stafford Horne wrote:

> Hello,
>
> This patch is a small set of fixes from the openrisc backlog. These
> changes fix several issues with the openrisc build on modern tool chains
> and address other issues which have cropped up as the kernel as it is
> being used on newer hardware.
>
> Please consider for merge.
>
> On-the-other-hand
>
> The openrisc project has been missing a kernel maintainer
> for some time now. Currently listed in MAINTAINERS is Jonas
> and a website that no longer exists.
>
>
> Some mail threads from Jonas
> https://lkml.org/lkml/2015/5/13/469 - mail from Jonas mentioning
>                                      he is no longer able to maintain
> https://lkml.org/lkml/2015/6/11/426 - mail from Jonas mentioning stefan
>                                      is to be the new maintainer
>
> Ideally stefan kristiansson would become the maintainer but he
> does not have a PGP key signed by kernel maintainers.  Also, he
> does not seem to have much time recently.
>
> We would like some help on how to proceed, options:
> - Someone take these patches into a branch that will be pulled
>   by linus? I can work to maintain the patch queue for openrisc.
> - I can work to get a my PGP key signed and send git pull requests
>   to linus?
>
> Regards,
>  Stafford
>
>
> Christian Svensson (1):
>  openrisc: Add thread-local storage (TLS) support
>
> Guenter Roeck (1):
>  openrisc: Support both old (or32) and new (or1k) toolchain
>
> Jonas Bonn (2):
>  Apply transparent_union attribute to union semun
>  openrisc: restore call-saved regs on sigreturn
>
> Rob Herring (1):
>  openrisc: remove the redundant of_platform_populate
>
> Stefan Kristiansson (2):
>  openrisc: fix PTRS_PER_PGD define
>  openrisc: add SMP and NR_CPUS Kconfig options
>
> arch/openrisc/Kconfig               | 14 ++++++++++++++
> arch/openrisc/include/asm/pgtable.h |  2 +-
> arch/openrisc/kernel/entry.S        | 10 +++++++++-
> arch/openrisc/kernel/process.c      | 13 +++++++++++++
> arch/openrisc/kernel/setup.c        | 10 ----------
> arch/openrisc/kernel/vmlinux.lds.S  |  8 +++++++-
> arch/openrisc/mm/init.c             |  2 +-
> include/uapi/linux/sem.h            |  2 +-
> 8 files changed, 46 insertions(+), 15 deletions(-)
>
> -- 
> 2.7.4
>
>

Re: [PATCH 1/7] Apply transparent_union attribute to union semun

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 7597 bytes --]

Hi Jonas,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.8-rc6 next-20160916]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:    https://github.com/0day-ci/linux/commits/Stafford-Horne/openrisc-Misc-fixes-from-backlog/20160916-230114
config: x86_64-randconfig-x011-09161116 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from include/linux/sem.h:7:0,
                    from include/linux/sched.h:35,
                    from include/linux/utsname.h:5,
                    from init/version.c:12:
>> include/uapi/linux/sem.h:45:7: warning: union cannot be made transparent
    union semun {
          ^~~~~
--
   In file included from include/linux/sem.h:7:0,
                    from include/linux/sched.h:35,
                    from include/linux/kasan.h:4,
                    from kernel/sched/core.c:29:
>> include/uapi/linux/sem.h:45:7: warning: union cannot be made transparent
    union semun {
          ^~~~~
   In file included from include/linux/perf_event.h:47:0,
                    from kernel/sched/core.c:42:
   include/linux/ftrace.h: In function 'preempt_schedule_common':
   include/linux/ftrace.h:703:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
    #  define ftrace_return_address(n) __builtin_return_address(n)
                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/ftrace.h:710:38: note: in expansion of macro 'ftrace_return_address'
    #define CALLER_ADDR1 ((unsigned long)ftrace_return_address(1))
                                         ^~~~~~~~~~~~~~~~~~~~~
   include/linux/ftrace.h:723:9: note: in expansion of macro 'CALLER_ADDR1'
     addr = CALLER_ADDR1;
            ^~~~~~~~~~~~
   include/linux/ftrace.h:703:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
    #  define ftrace_return_address(n) __builtin_return_address(n)
                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/ftrace.h:711:38: note: in expansion of macro 'ftrace_return_address'
    #define CALLER_ADDR2 ((unsigned long)ftrace_return_address(2))
                                         ^~~~~~~~~~~~~~~~~~~~~
   include/linux/ftrace.h:726:9: note: in expansion of macro 'CALLER_ADDR2'
     return CALLER_ADDR2;
            ^~~~~~~~~~~~
   include/linux/ftrace.h: In function 'preempt_count_add':
   include/linux/ftrace.h:703:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
    #  define ftrace_return_address(n) __builtin_return_address(n)
                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/ftrace.h:710:38: note: in expansion of macro 'ftrace_return_address'
    #define CALLER_ADDR1 ((unsigned long)ftrace_return_address(1))
                                         ^~~~~~~~~~~~~~~~~~~~~
   include/linux/ftrace.h:723:9: note: in expansion of macro 'CALLER_ADDR1'
     addr = CALLER_ADDR1;
            ^~~~~~~~~~~~
   include/linux/ftrace.h:703:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
    #  define ftrace_return_address(n) __builtin_return_address(n)
                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/ftrace.h:711:38: note: in expansion of macro 'ftrace_return_address'
    #define CALLER_ADDR2 ((unsigned long)ftrace_return_address(2))
                                         ^~~~~~~~~~~~~~~~~~~~~
   include/linux/ftrace.h:726:9: note: in expansion of macro 'CALLER_ADDR2'
     return CALLER_ADDR2;
            ^~~~~~~~~~~~
   include/linux/ftrace.h: In function 'preempt_schedule_notrace':
   include/linux/ftrace.h:703:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
    #  define ftrace_return_address(n) __builtin_return_address(n)
                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/ftrace.h:710:38: note: in expansion of macro 'ftrace_return_address'
    #define CALLER_ADDR1 ((unsigned long)ftrace_return_address(1))
                                         ^~~~~~~~~~~~~~~~~~~~~
   include/linux/ftrace.h:723:9: note: in expansion of macro 'CALLER_ADDR1'
     addr = CALLER_ADDR1;
            ^~~~~~~~~~~~
   include/linux/ftrace.h:703:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
    #  define ftrace_return_address(n) __builtin_return_address(n)
                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/ftrace.h:711:38: note: in expansion of macro 'ftrace_return_address'
    #define CALLER_ADDR2 ((unsigned long)ftrace_return_address(2))
                                         ^~~~~~~~~~~~~~~~~~~~~
   include/linux/ftrace.h:726:9: note: in expansion of macro 'CALLER_ADDR2'
     return CALLER_ADDR2;
            ^~~~~~~~~~~~

vim +45 include/uapi/linux/sem.h

607ca46e David Howells 2012-10-13  29  	struct sem_queue **sem_pending_last;	/* last pending operation */
607ca46e David Howells 2012-10-13  30  	struct sem_undo	*undo;			/* undo requests on this array */
607ca46e David Howells 2012-10-13  31  	unsigned short	sem_nsems;		/* no. of semaphores in array */
607ca46e David Howells 2012-10-13  32  };
607ca46e David Howells 2012-10-13  33  
607ca46e David Howells 2012-10-13  34  /* Include the definition of semid64_ds */
607ca46e David Howells 2012-10-13  35  #include <asm/sembuf.h>
607ca46e David Howells 2012-10-13  36  
607ca46e David Howells 2012-10-13  37  /* semop system calls takes an array of these. */
607ca46e David Howells 2012-10-13  38  struct sembuf {
607ca46e David Howells 2012-10-13  39  	unsigned short  sem_num;	/* semaphore index in array */
607ca46e David Howells 2012-10-13  40  	short		sem_op;		/* semaphore operation */
607ca46e David Howells 2012-10-13  41  	short		sem_flg;	/* operation flags */
607ca46e David Howells 2012-10-13  42  };
607ca46e David Howells 2012-10-13  43  
607ca46e David Howells 2012-10-13  44  /* arg for semctl system calls. */
607ca46e David Howells 2012-10-13 @45  union semun {
607ca46e David Howells 2012-10-13  46  	int val;			/* value for SETVAL */
607ca46e David Howells 2012-10-13  47  	struct semid_ds __user *buf;	/* buffer for IPC_STAT & IPC_SET */
607ca46e David Howells 2012-10-13  48  	unsigned short __user *array;	/* array for GETALL & SETALL */
607ca46e David Howells 2012-10-13  49  	struct seminfo __user *__buf;	/* buffer for IPC_INFO */
607ca46e David Howells 2012-10-13  50  	void __user *__pad;
46f40460 Jonas Bonn    2016-09-16  51  } __attribute__ ((transparent_union));
607ca46e David Howells 2012-10-13  52  
607ca46e David Howells 2012-10-13  53  struct  seminfo {

:::::: The code at line 45 was first introduced by commit
:::::: 607ca46e97a1b6594b29647d98a32d545c24bdff UAPI: (Scripted) Disintegrate include/linux

:::::: TO: David Howells <dhowells@redhat.com>
:::::: CC: David Howells <dhowells@redhat.com>

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

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 21020 bytes --]

Re: [PATCH 1/7] Apply transparent_union attribute to union semun

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]

Hi Jonas,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.8-rc6 next-20160916]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:    https://github.com/0day-ci/linux/commits/Stafford-Horne/openrisc-Misc-fixes-from-backlog/20160916-230114
config: x86_64-randconfig-b0-09170504 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All errors (new ones prefixed by >>):

   cc1: warnings being treated as errors
   In file included from include/linux/sem.h:7,
                    from include/linux/sched.h:35,
                    from include/linux/kasan.h:4,
                    from include/linux/slab.h:118,
                    from include/linux/resource_ext.h:19,
                    from include/linux/acpi.h:26,
                    from drivers/gpu/drm/i915/i915_drv.c:30:
>> include/uapi/linux/sem.h:51: error: union cannot be made transparent

vim +51 include/uapi/linux/sem.h

    45	union semun {
    46		int val;			/* value for SETVAL */
    47		struct semid_ds __user *buf;	/* buffer for IPC_STAT & IPC_SET */
    48		unsigned short __user *array;	/* array for GETALL & SETALL */
    49		struct seminfo __user *__buf;	/* buffer for IPC_INFO */
    50		void __user *__pad;
  > 51	} __attribute__ ((transparent_union));
    52	
    53	struct  seminfo {
    54		int semmap;

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

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 25840 bytes --]

Re: [PATCH 1/7] Apply transparent_union attribute to union semun

[Stafford Horne]

On Sat, 17 Sep 2016, kbuild test robot wrote:

> Hi Jonas,
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.8-rc6 next-20160916]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
> [Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
> [Check https://git-scm.com/docs/git-format-patch for more information]
>
> url:    https://github.com/0day-ci/linux/commits/Stafford-Horne/openrisc-Misc-fixes-from-backlog/20160916-230114
> config: x86_64-randconfig-b0-09170504 (attached as .config)
> compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
> reproduce:
>        # save the attached .config to linux build tree
>        make ARCH=x86_64
>
> All errors (new ones prefixed by >>):
>
>   cc1: warnings being treated as errors
>   In file included from include/linux/sem.h:7,
>                    from include/linux/sched.h:35,
>                    from include/linux/kasan.h:4,
>                    from include/linux/slab.h:118,
>                    from include/linux/resource_ext.h:19,
>                    from include/linux/acpi.h:26,
>                    from drivers/gpu/drm/i915/i915_drv.c:30:
>>> include/uapi/linux/sem.h:51: error: union cannot be made transparent

Thanks for catching this.  I missed that this would break non openrisc 
architectures.

This issue is that "
All members of the union must have the same machine representation; this 
is necessary for this argument passing to work properly.
"

Definitely int and * will not always be the same.  Investingating what we 
can do on in arch/openrisc side without breaking the build/backcompat for
others.

Any other idea's welcome.

-Stafford

> vim +51 include/uapi/linux/sem.h
>
>    45	union semun {
>    46		int val;			/* value for SETVAL */
>    47		struct semid_ds __user *buf;	/* buffer for IPC_STAT & IPC_SET */
>    48		unsigned short __user *array;	/* array for GETALL & SETALL */
>    49		struct seminfo __user *__buf;	/* buffer for IPC_INFO */
>    50		void __user *__pad;
>  > 51	} __attribute__ ((transparent_union));
>    52
>    53	struct  seminfo {
>    54		int semmap;
>
> ---
> 0-DAY kernel test infrastructure                Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
>

[OpenRISC] [PATCH 1/7] Apply transparent_union attribute to union semun

[Stafford Horne]

On Sat, 17 Sep 2016, kbuild test robot wrote:

> Hi Jonas,
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.8-rc6 next-20160916]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
> [Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
> [Check https://git-scm.com/docs/git-format-patch for more information]
>
> url:    https://github.com/0day-ci/linux/commits/Stafford-Horne/openrisc-Misc-fixes-from-backlog/20160916-230114
> config: x86_64-randconfig-b0-09170504 (attached as .config)
> compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
> reproduce:
>        # save the attached .config to linux build tree
>        make ARCH=x86_64
>
> All errors (new ones prefixed by >>):
>
>   cc1: warnings being treated as errors
>   In file included from include/linux/sem.h:7,
>                    from include/linux/sched.h:35,
>                    from include/linux/kasan.h:4,
>                    from include/linux/slab.h:118,
>                    from include/linux/resource_ext.h:19,
>                    from include/linux/acpi.h:26,
>                    from drivers/gpu/drm/i915/i915_drv.c:30:
>>> include/uapi/linux/sem.h:51: error: union cannot be made transparent

Thanks for catching this.  I missed that this would break non openrisc 
architectures.

This issue is that "
All members of the union must have the same machine representation; this 
is necessary for this argument passing to work properly.
"

Definitely int and * will not always be the same.  Investingating what we 
can do on in arch/openrisc side without breaking the build/backcompat for
others.

Any other idea's welcome.

-Stafford

> vim +51 include/uapi/linux/sem.h
>
>    45	union semun {
>    46		int val;			/* value for SETVAL */
>    47		struct semid_ds __user *buf;	/* buffer for IPC_STAT & IPC_SET */
>    48		unsigned short __user *array;	/* array for GETALL & SETALL */
>    49		struct seminfo __user *__buf;	/* buffer for IPC_INFO */
>    50		void __user *__pad;
>  > 51	} __attribute__ ((transparent_union));
>    52
>    53	struct  seminfo {
>    54		int semmap;
>
> ---
> 0-DAY kernel test infrastructure                Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
>

Re: [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Guenter Roeck]

On 09/16/2016 07:43 AM, Stafford Horne wrote:
> From: Guenter Roeck <linux@roeck-us.net>
>
> The output file format for or1k has changed from "elf32-or32"
> to "elf32-or1k". Select the correct output format automatically
> to be able to compile the kernel with both toolchain variants.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Stafford Horne <shorne@gmail.com>

I tested your entire series with my qemu setup. Works for me, so for the series:

Tested-by: Guenter Roeck <linux@roeck-us.net>

If you plan to handle openrisc going forward, it would be great if you could
consider updating MAINTAINERS. The web site and git repository have been unreachable
for a long time.

Thanks,
Guenter

> ---
>  arch/openrisc/kernel/vmlinux.lds.S | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/openrisc/kernel/vmlinux.lds.S b/arch/openrisc/kernel/vmlinux.lds.S
> index d936de4..4a72d5d 100644
> --- a/arch/openrisc/kernel/vmlinux.lds.S
> +++ b/arch/openrisc/kernel/vmlinux.lds.S
> @@ -30,7 +30,13 @@
>  #include <asm/cache.h>
>  #include <asm-generic/vmlinux.lds.h>
>
> -OUTPUT_FORMAT("elf32-or32", "elf32-or32", "elf32-or32")
> +#ifdef __OR1K__
> +#define __OUTPUT_FORMAT        "elf32-or1k"
> +#else
> +#define __OUTPUT_FORMAT        "elf32-or32"
> +#endif
> +
> +OUTPUT_FORMAT(__OUTPUT_FORMAT, __OUTPUT_FORMAT, __OUTPUT_FORMAT)
>  jiffies = jiffies_64 + 4;
>
>  SECTIONS
>

Re: [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Stafford Horne]

On Sun, 18 Sep 2016, Guenter Roeck wrote:

> Tested-by: Guenter Roeck <linux@roeck-us.net>
>
> If you plan to handle openrisc going forward, it would be great if you could
> consider updating MAINTAINERS. The web site and git repository have been 
> unreachable
> for a long time.

Thank you,
Updating maintainers was kind of on my plans, but I figured I need to 
prove that I kind of know what I am doing.

Thanks for the testing, I have tested as well on my de0 nano FPGA board 
running the cpu in "hardware".

I will make some updates are post a V2.

-Stafford

Re: [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Guenter Roeck]

On 09/18/2016 11:02 PM, Stafford Horne wrote:
>
>
> On Sun, 18 Sep 2016, Guenter Roeck wrote:
>
>> Tested-by: Guenter Roeck <linux@roeck-us.net>
>>
>> If you plan to handle openrisc going forward, it would be great if you could
>> consider updating MAINTAINERS. The web site and git repository have been unreachable
>> for a long time.
>
> Thank you,
> Updating maintainers was kind of on my plans, but I figured I need to prove that I kind of know what I am doing.
>

The alternative would be to mark it as Orphaned. Which, for all practical purpose,
would be the correct state right now.

Guenter

Re: [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Stafford Horne]

On Mon, 19 Sep 2016, Guenter Roeck wrote:

> On 09/18/2016 11:02 PM, Stafford Horne wrote:
>> 
>>
>>  On Sun, 18 Sep 2016, Guenter Roeck wrote:
>> 
>> >  Tested-by: Guenter Roeck <linux@roeck-us.net>
>> > 
>> >  If you plan to handle openrisc going forward, it would be great if you 
>> >  could
>> >  consider updating MAINTAINERS. The web site and git repository have been 
>> >  unreachable
>> >  for a long time.
>>
>>  Thank you,
>>  Updating maintainers was kind of on my plans, but I figured I need to
>>  prove that I kind of know what I am doing.
>> 
>
> The alternative would be to mark it as Orphaned. Which, for all practical 
> purpose,
> would be the correct state right now.

+CC The openrisc list

Understood, 
I don't think we would want that to happen.

[OpenRISC] [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Stafford Horne]

On Mon, 19 Sep 2016, Guenter Roeck wrote:

> On 09/18/2016 11:02 PM, Stafford Horne wrote:
>> 
>>
>>  On Sun, 18 Sep 2016, Guenter Roeck wrote:
>> 
>> >  Tested-by: Guenter Roeck <linux@roeck-us.net>
>> > 
>> >  If you plan to handle openrisc going forward, it would be great if you 
>> >  could
>> >  consider updating MAINTAINERS. The web site and git repository have been 
>> >  unreachable
>> >  for a long time.
>>
>>  Thank you,
>>  Updating maintainers was kind of on my plans, but I figured I need to
>>  prove that I kind of know what I am doing.
>> 
>
> The alternative would be to mark it as Orphaned. Which, for all practical 
> purpose,
> would be the correct state right now.

+CC The openrisc list

Understood, 
I don't think we would want that to happen.

Re: [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Guenter Roeck]

On 09/19/2016 02:11 AM, Stafford Horne wrote:
>
>
> On Mon, 19 Sep 2016, Guenter Roeck wrote:
>
>> On 09/18/2016 11:02 PM, Stafford Horne wrote:
>>>
>>>
>>>  On Sun, 18 Sep 2016, Guenter Roeck wrote:
>>>
>>> >  Tested-by: Guenter Roeck <linux@roeck-us.net>
>>> > >  If you plan to handle openrisc going forward, it would be great if you >  could
>>> >  consider updating MAINTAINERS. The web site and git repository have been >  unreachable
>>> >  for a long time.
>>>
>>>  Thank you,
>>>  Updating maintainers was kind of on my plans, but I figured I need to
>>>  prove that I kind of know what I am doing.
>>>
>>
>> The alternative would be to mark it as Orphaned. Which, for all practical purpose,
>> would be the correct state right now.
>
> +CC The openrisc list
>
> Understood, I don't think we would want that to happen.
>
Look at the entry today:

OPENRISC ARCHITECTURE
M:      Jonas Bonn <jonas@southpole.se>
W:      http://openrisc.net
S:      Maintained
T:      git git://openrisc.net/~jonas/linux
F:      arch/openrisc/

At the very least, W: and T: are incorrect and need to be updated or removed.
Plus, apparently there is a L:, and "T: https://github.com/openrisc/linux"
might be appropriate.

Guenter

[OpenRISC] [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Guenter Roeck]

On 09/19/2016 02:11 AM, Stafford Horne wrote:
>
>
> On Mon, 19 Sep 2016, Guenter Roeck wrote:
>
>> On 09/18/2016 11:02 PM, Stafford Horne wrote:
>>>
>>>
>>>  On Sun, 18 Sep 2016, Guenter Roeck wrote:
>>>
>>> >  Tested-by: Guenter Roeck <linux@roeck-us.net>
>>> > >  If you plan to handle openrisc going forward, it would be great if you >  could
>>> >  consider updating MAINTAINERS. The web site and git repository have been >  unreachable
>>> >  for a long time.
>>>
>>>  Thank you,
>>>  Updating maintainers was kind of on my plans, but I figured I need to
>>>  prove that I kind of know what I am doing.
>>>
>>
>> The alternative would be to mark it as Orphaned. Which, for all practical purpose,
>> would be the correct state right now.
>
> +CC The openrisc list
>
> Understood, I don't think we would want that to happen.
>
Look at the entry today:

OPENRISC ARCHITECTURE
M:      Jonas Bonn <jonas@southpole.se>
W:      http://openrisc.net
S:      Maintained
T:      git git://openrisc.net/~jonas/linux
F:      arch/openrisc/

At the very least, W: and T: are incorrect and need to be updated or removed.
Plus, apparently there is a L:, and "T: https://github.com/openrisc/linux"
might be appropriate.

Guenter

Re: [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Stafford Horne]

On Mon, 19 Sep 2016, Guenter Roeck wrote:

> On 09/19/2016 02:11 AM, Stafford Horne wrote:
>> 
>>
>>  On Mon, 19 Sep 2016, Guenter Roeck wrote:
>> 
>> >  On 09/18/2016 11:02 PM, Stafford Horne wrote:
>> > > 
>> > > 
>> > >   On Sun, 18 Sep 2016, Guenter Roeck wrote:
>> > > 
>> > > >   Tested-by: Guenter Roeck <linux@roeck-us.net>
>> > > > >   If you plan to handle openrisc going forward, it would be great 
>> > > > >   if you >  could
>> > > >   consider updating MAINTAINERS. The web site and git repository have 
>> > > >   been >  unreachable
>> > > >   for a long time.
>> > > 
>> > >   Thank you,
>> > >   Updating maintainers was kind of on my plans, but I figured I need to
>> > >   prove that I kind of know what I am doing.
>> > > 
>> > 
>> >  The alternative would be to mark it as Orphaned. Which, for all 
>> >  practical purpose,
>> >  would be the correct state right now.
>>
>>  +CC The openrisc list
>>
>>  Understood, I don't think we would want that to happen.
>> 
> Look at the entry today:
>
> OPENRISC ARCHITECTURE
> M:      Jonas Bonn <jonas@southpole.se>
> W:      http://openrisc.net
> S:      Maintained
> T:      git git://openrisc.net/~jonas/linux
> F:      arch/openrisc/
>
> At the very least, W: and T: are incorrect and need to be updated or removed.
> Plus, apparently there is a L:, and "T: https://github.com/openrisc/linux"
> might be appropriate.
>

Thanks,
I am aware of this, we have since setup a new website, mailing list and as 
you have found, git repo. Stefan has been nominated as the maintainer by 
Jonas on a previous mail thread.

The issue (as we see it) is that neither Stefan or I have signed PGP keys 
by anyone in the web of trust.

I sent this patch set with a cover lett trying to explain of the 
situation trying to get some help.  Your reponses are very helpful.

Do you think I should just send "git pull" reuqests to Linus with a self 
signed pgp key and eplaination to see how it goes?

-Stafford

FYI
I have a change as following in my backlog, as follows:

---
@@ -8691,10 +8063,12 @@ F:      drivers/of/overlay.c
  F:     drivers/of/resolver.c

  OPENRISC ARCHITECTURE
-M:	Jonas Bonn <jonas@southpole.se>
-W:	http://openrisc.net
+M:	Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
+M:	Stafford Horne <shorne@gmail.com>
+W:	http://openrisc.io
+L:	openrisc@lists.librecores.org
+T:	https://github.com/openrisc/linux.git
  S:	Maintained
-T:	git git://openrisc.net/~jonas/linux
  F:	arch/openrisc/

  OPENVSWITCH

--

[OpenRISC] [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Stafford Horne]

On Mon, 19 Sep 2016, Guenter Roeck wrote:

> On 09/19/2016 02:11 AM, Stafford Horne wrote:
>> 
>>
>>  On Mon, 19 Sep 2016, Guenter Roeck wrote:
>> 
>> >  On 09/18/2016 11:02 PM, Stafford Horne wrote:
>> > > 
>> > > 
>> > >   On Sun, 18 Sep 2016, Guenter Roeck wrote:
>> > > 
>> > > >   Tested-by: Guenter Roeck <linux@roeck-us.net>
>> > > > >   If you plan to handle openrisc going forward, it would be great 
>> > > > >   if you >  could
>> > > >   consider updating MAINTAINERS. The web site and git repository have 
>> > > >   been >  unreachable
>> > > >   for a long time.
>> > > 
>> > >   Thank you,
>> > >   Updating maintainers was kind of on my plans, but I figured I need to
>> > >   prove that I kind of know what I am doing.
>> > > 
>> > 
>> >  The alternative would be to mark it as Orphaned. Which, for all 
>> >  practical purpose,
>> >  would be the correct state right now.
>>
>>  +CC The openrisc list
>>
>>  Understood, I don't think we would want that to happen.
>> 
> Look at the entry today:
>
> OPENRISC ARCHITECTURE
> M:      Jonas Bonn <jonas@southpole.se>
> W:      http://openrisc.net
> S:      Maintained
> T:      git git://openrisc.net/~jonas/linux
> F:      arch/openrisc/
>
> At the very least, W: and T: are incorrect and need to be updated or removed.
> Plus, apparently there is a L:, and "T: https://github.com/openrisc/linux"
> might be appropriate.
>

Thanks,
I am aware of this, we have since setup a new website, mailing list and as 
you have found, git repo. Stefan has been nominated as the maintainer by 
Jonas on a previous mail thread.

The issue (as we see it) is that neither Stefan or I have signed PGP keys 
by anyone in the web of trust.

I sent this patch set with a cover lett trying to explain of the 
situation trying to get some help.  Your reponses are very helpful.

Do you think I should just send "git pull" reuqests to Linus with a self 
signed pgp key and eplaination to see how it goes?

-Stafford

FYI
I have a change as following in my backlog, as follows:

---
@@ -8691,10 +8063,12 @@ F:      drivers/of/overlay.c
  F:     drivers/of/resolver.c

  OPENRISC ARCHITECTURE
-M:	Jonas Bonn <jonas@southpole.se>
-W:	http://openrisc.net
+M:	Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
+M:	Stafford Horne <shorne@gmail.com>
+W:	http://openrisc.io
+L:	openrisc at lists.librecores.org
+T:	https://github.com/openrisc/linux.git
  S:	Maintained
-T:	git git://openrisc.net/~jonas/linux
  F:	arch/openrisc/

  OPENVSWITCH

--

Re: [PATCH 4/7] openrisc: Add thread-local storage (TLS) support

[Jonas Bonn]

On 09/16/2016 04:43 PM, Stafford Horne wrote:
> From: Christian Svensson <blue@cmd.nu>
>
> Historically OpenRISC GCC has reserved r10 which we now use to hold
> the thread pointer for thread-local storage (TLS).
I know this was proposed by way of this patch, but we deferred accepting 
this until the OpenRISC spec could be updated accordingly.  Has this 
been done now?  If not, still NAK.

/Jonas

>
> Signed-off-by: Christian Svensson <blue@cmd.nu>
> Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
> Signed-off-by: Stafford Horne <shorne@gmail.com>
> ---
>   arch/openrisc/kernel/process.c | 13 +++++++++++++
>   1 file changed, 13 insertions(+)
>
> diff --git a/arch/openrisc/kernel/process.c b/arch/openrisc/kernel/process.c
> index 7095dfe..277123b 100644
> --- a/arch/openrisc/kernel/process.c
> +++ b/arch/openrisc/kernel/process.c
> @@ -173,6 +173,19 @@ copy_thread(unsigned long clone_flags, unsigned long usp,
>   
>   		if (usp)
>   			userregs->sp = usp;
> +
> +		/*
> +		 * For CLONE_SETTLS set "tp" (r10) to the TLS pointer passed to sys_clone.
> +		 *
> +		 * The kernel entry is:
> +		 *	int clone (long flags, void *child_stack, int *parent_tid,
> +		 *		int *child_tid, struct void *tls)
> +		 *
> +		 * This makes the source r7 in the kernel registers.
> +		 */
> +		if (clone_flags & CLONE_SETTLS)
> +			userregs->gpr[10] = userregs->gpr[7];
> +
>   		userregs->gpr[11] = 0;	/* Result from fork() */
>   
>   		kregs->gpr[20] = 0;	/* Userspace thread */

Re: [PATCH 1/7] Apply transparent_union attribute to union semun

[Jonas Bonn]

NAK... this breaks other architectures.

The OpenRISC toolchain is broken with regard to this issue.  Five years 
ago (last I looked) nobody seemed interesting in fixing it. Has anything 
changed here?

/Jonas

On 09/16/2016 04:42 PM, Stafford Horne wrote:
> ..From: Jonas Bonn <jonas@southpole.se>
>
> The syscall handler for semctl is written under the assumption that the
> toolchain will pass "small" unions as function parameters directly instead
> of by reference.  The union semun is "small" and thus fits this description.
>
> Since it is assumed that the union will be passed directly and not by
> reference, it is safe to access the union members without going via
> get_user.
>
> The OpenRISC architecture, however, passes all unions by reference, thus
> breaking the above assumption.
>
> The technically correct fix here is to mark the union as being transparent
> so that the ABI of the union's first element determines the parameter
> passing method and thus make explicit what's already implied in the function
> definition.
>
> Signed-off-by: Jonas Bonn <jonas@southpole.se>
> Signed-off-by: Stafford Horne <shorne@gmail.com>
> ---
>   include/uapi/linux/sem.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/sem.h b/include/uapi/linux/sem.h
> index dd73b90..aabe50f 100644
> --- a/include/uapi/linux/sem.h
> +++ b/include/uapi/linux/sem.h
> @@ -48,7 +48,7 @@ union semun {
>   	unsigned short __user *array;	/* array for GETALL & SETALL */
>   	struct seminfo __user *__buf;	/* buffer for IPC_INFO */
>   	void __user *__pad;
> -};
> +} __attribute__ ((transparent_union));
>   
>   struct  seminfo {
>   	int semmap;

Re: [PATCH 2/7] openrisc: fix PTRS_PER_PGD define

[Jonas Bonn]

On 09/16/2016 04:43 PM, Stafford Horne wrote:
> From: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
>
> On OpenRISC, with its 8k pages, PAGE_SHIFT is defined to be 13.
> That makes the expression (1UL << (PAGE_SHIFT-2)) evaluate
> to 2048.
> The correct value for PTRS_PER_PGD should be 256.
>
> Correcting the PTRS_PER_PGD define unveiled a bug in map_ram(),
> where PTRS_PER_PGD was used when the intent was to iterate
> over a set of page table entries.
> This patch corrects that issue as well.
>
> Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
> Signed-off-by: Stafford Horne <shorne@gmail.com>
Acked-by: Jonas Bonn <jonas@southpole.se>

> ---
>   arch/openrisc/include/asm/pgtable.h | 2 +-
>   arch/openrisc/mm/init.c             | 2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/openrisc/include/asm/pgtable.h b/arch/openrisc/include/asm/pgtable.h
> index 69c7df0..3567aa7 100644
> --- a/arch/openrisc/include/asm/pgtable.h
> +++ b/arch/openrisc/include/asm/pgtable.h
> @@ -69,7 +69,7 @@ extern void paging_init(void);
>    */
>   #define PTRS_PER_PTE	(1UL << (PAGE_SHIFT-2))
>   
> -#define PTRS_PER_PGD	(1UL << (PAGE_SHIFT-2))
> +#define PTRS_PER_PGD	(1UL << (32-PGDIR_SHIFT))
>   
>   /* calculate how many PGD entries a user-level program can use
>    * the first mappable virtual address is 0
> diff --git a/arch/openrisc/mm/init.c b/arch/openrisc/mm/init.c
> index 7f94652..b782ce9 100644
> --- a/arch/openrisc/mm/init.c
> +++ b/arch/openrisc/mm/init.c
> @@ -110,7 +110,7 @@ static void __init map_ram(void)
>   			set_pmd(pme, __pmd(_KERNPG_TABLE + __pa(pte)));
>   
>   			/* Fill the newly allocated page with PTE'S */
> -			for (j = 0; p < e && j < PTRS_PER_PGD;
> +			for (j = 0; p < e && j < PTRS_PER_PTE;
>   			     v += PAGE_SIZE, p += PAGE_SIZE, j++, pte++) {
>   				if (v >= (u32) _e_kernel_ro ||
>   				    v < (u32) _s_kernel_ro)

Re: [PATCH 3/7] openrisc: restore call-saved regs on sigreturn

[Jonas Bonn]

On 09/16/2016 04:43 PM, Stafford Horne wrote:
> From: Jonas Bonn <jonas@southpole.se>
>
> Return to userspace via _resume_userspace instead of via syscall return
> path for the rt_sigreturn syscall.
>
> I'll rework this comment more later, but this patch needs testing.

This whole patch was reworked later... what happened to that work? I 
recall it being posted for testing without feedback...

In any case, the patch comment needs cleaning up.

/Jonas

>
> Old comment from previous patch:
>
> The sigreturn syscall is more like a context switch than a function call;
> it entails a return from one context (the signal handler) to another
> (the process in question).  For a context switch like this there are
> effectively no call-saved regs that remain constant across the transition.
>
> This patch restores the call-saved regs from pt_regs before returning from
> the syscall, effectively restoring the context that the process had before
> being interrupted by the signal handler.  Restoring the call-saved regs
> in this way allows us to return to userspace via the usual syscall fast
> path.
>
> Reported-by: Sebastian Macke <sebastian@macke.de>
> Signed-off-by: Jonas Bonn <jonas@southpole.se>
> Signed-off-by: Stafford Horne <shorne@gmail.com>
> ---
>   arch/openrisc/kernel/entry.S | 10 +++++++++-
>   1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/arch/openrisc/kernel/entry.S b/arch/openrisc/kernel/entry.S
> index fec8bf9..572d223 100644
> --- a/arch/openrisc/kernel/entry.S
> +++ b/arch/openrisc/kernel/entry.S
> @@ -1101,8 +1101,16 @@ ENTRY(__sys_fork)
>   	 l.addi	r3,r1,0
>   
>   ENTRY(sys_rt_sigreturn)
> -	l.j	_sys_rt_sigreturn
> +	l.jal	_sys_rt_sigreturn
>   	 l.addi	r3,r1,0
> +	l.sfne	r30,r0
> +	l.bnf	_no_syscall_trace
> +	 l.nop
> +	l.jal	do_syscall_trace_leave
> +	 l.addi	r3,r1,0
> +_no_syscall_trace:
> +	l.j	_resume_userspace
> +	 l.nop
>   
>   /* This is a catch-all syscall for atomic instructions for the OpenRISC 1000.
>    * The functions takes a variable number of parameters depending on which

Re: [PATCH 6/7] openrisc: add SMP and NR_CPUS Kconfig options

[Jonas Bonn]

On 09/16/2016 04:43 PM, Stafford Horne wrote:
> From: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>

OpenRISC was not an SMP architecture last I looked... did the relevant 
spec updates get made?  If not, NAK.

The issue is, the OpenRISC architecture shouldn't be a moving target 
defined by what the kernel supports... there's a spec that the kernel 
conforms to.  This is important for the (few) real users of the 
architecture.

/Jonas

> Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
> Signed-off-by: Stafford Horne <shorne@gmail.com>
> ---
>   arch/openrisc/Kconfig | 14 ++++++++++++++
>   1 file changed, 14 insertions(+)
>
> diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig
> index 489e7f9..2bcf8c3 100644
> --- a/arch/openrisc/Kconfig
> +++ b/arch/openrisc/Kconfig
> @@ -98,6 +98,20 @@ config OPENRISC_HAVE_INST_DIV
>   	  Select this if your implementation has a hardware divide instruction
>   endmenu
>   
> +config NR_CPUS
> +	int "Maximum number of CPUs (2-32)"
> +	range 2 32
> +	depends on SMP
> +	default "2"
> +
> +config SMP
> +	bool "Symmetric Multi-Processing support"
> +	help
> +	  This enables support for systems with more than one CPU. If you have
> +	  a system with only one CPU, say N. If you have a system with more
> +	  than one CPU, say Y.
> +
> +	  If you don't know what to do here, say N.
>   
>   source kernel/Kconfig.hz
>   source kernel/Kconfig.preempt

Re: [PATCH 7/7] openrisc: remove the redundant of_platform_populate

[Jonas Bonn]

On 09/16/2016 04:43 PM, Stafford Horne wrote:
> From: Rob Herring <robh@kernel.org>
>
> The of_platform_populate call in the openrisc arch code is now redundant
> as the DT core provides a default call. Openrisc has a NULL match table
> which means only top level nodes with compatible strings will have
> devices creates. The default version will also descend nodes in the
> match table such as "simple-bus" which should be fine as openrisc
> doesn't have any of these (though it is preferred that memory-mapped
> peripherals be grouped under a bus node(s)).
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> Cc: Jonas Bonn <jonas@southpole.se>
> Signed-off-by: Stafford Horne <shorne@gmail.com>

Yes, this is fine, but trivial/generic stuff like this doesn't really 
need to go via the OpenRISC repo, anyway.

/Jonas

> ---
>   arch/openrisc/kernel/setup.c | 10 ----------
>   1 file changed, 10 deletions(-)
>
> diff --git a/arch/openrisc/kernel/setup.c b/arch/openrisc/kernel/setup.c
> index b4ed8b3..d2f78cf 100644
> --- a/arch/openrisc/kernel/setup.c
> +++ b/arch/openrisc/kernel/setup.c
> @@ -38,7 +38,6 @@
>   #include <linux/of.h>
>   #include <linux/memblock.h>
>   #include <linux/device.h>
> -#include <linux/of_platform.h>
>   
>   #include <asm/sections.h>
>   #include <asm/segment.h>
> @@ -219,15 +218,6 @@ void __init or32_early_setup(void *fdt)
>   	early_init_devtree(fdt);
>   }
>   
> -static int __init openrisc_device_probe(void)
> -{
> -	of_platform_populate(NULL, NULL, NULL, NULL);
> -
> -	return 0;
> -}
> -
> -device_initcall(openrisc_device_probe);
> -
>   static inline unsigned long extract_value_bits(unsigned long reg,
>   					       short bit_nr, short width)
>   {

Re: [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Jonas Bonn]

On 09/19/2016 04:04 PM, Stafford Horne wrote:
>
>
> On Mon, 19 Sep 2016, Guenter Roeck wrote:
>
>> On 09/19/2016 02:11 AM, Stafford Horne wrote:
>>>
>>>
>>>  On Mon, 19 Sep 2016, Guenter Roeck wrote:
>>>
>>> >  On 09/18/2016 11:02 PM, Stafford Horne wrote:
>>> > > > > > >   On Sun, 18 Sep 2016, Guenter Roeck wrote:
>>> > > > > >   Tested-by: Guenter Roeck <linux@roeck-us.net>
>>> > > > >   If you plan to handle openrisc going forward, it would be 
>>> great > > > >   if you > could
>>> > > >   consider updating MAINTAINERS. The web site and git 
>>> repository have > > >   been > unreachable
>>> > > >   for a long time.
>>> > > > >   Thank you,
>>> > >   Updating maintainers was kind of on my plans, but I figured I 
>>> need to
>>> > >   prove that I kind of know what I am doing.
>>> > > > >  The alternative would be to mark it as Orphaned. Which, for 
>>> all >  practical purpose,
>>> >  would be the correct state right now.
>>>
>>>  +CC The openrisc list
>>>
>>>  Understood, I don't think we would want that to happen.
>>>
>> Look at the entry today:
>>
>> OPENRISC ARCHITECTURE
>> M:      Jonas Bonn <jonas@southpole.se>
>> W:      http://openrisc.net
>> S:      Maintained
>> T:      git git://openrisc.net/~jonas/linux
>> F:      arch/openrisc/
>>
>> At the very least, W: and T: are incorrect and need to be updated or 
>> removed.
>> Plus, apparently there is a L:, and "T: 
>> https://github.com/openrisc/linux"
>> might be appropriate.
>>
>
> Thanks,
> I am aware of this, we have since setup a new website, mailing list 
> and as you have found, git repo. Stefan has been nominated as the 
> maintainer by Jonas on a previous mail thread.
>
> The issue (as we see it) is that neither Stefan or I have signed PGP 
> keys by anyone in the web of trust.
>
> I sent this patch set with a cover lett trying to explain of the 
> situation trying to get some help.  Your reponses are very helpful.
>
> Do you think I should just send "git pull" reuqests to Linus with a 
> self signed pgp key and eplaination to see how it goes?

The bigger question I would have at this point is the value of the code 
remaining upstream...  Five years ago, there was a promise to try to get 
the toolchain upstream within a year or two; to this day, I don't know 
that much progress has been made there so this architecture still 
requires a hodge-podge of tools from various sources to build.

Given the toolchain maintainer's general reluctance to move things 
upstream, I'd almost be inclined to just remove the OpenRISC arch from 
the kernel altogether.  Are there any other arch's that can't be built 
with an upstream GCC at this point?

/Jonas

>
> -Stafford
>
> FYI
> I have a change as following in my backlog, as follows:
>
> ---
> @@ -8691,10 +8063,12 @@ F:      drivers/of/overlay.c
>  F:     drivers/of/resolver.c
>
>  OPENRISC ARCHITECTURE
> -M:    Jonas Bonn <jonas@southpole.se>
> -W:    http://openrisc.net
> +M:    Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
> +M:    Stafford Horne <shorne@gmail.com>
> +W:    http://openrisc.io
> +L:    openrisc@lists.librecores.org
> +T:    https://github.com/openrisc/linux.git
>  S:    Maintained
> -T:    git git://openrisc.net/~jonas/linux
>  F:    arch/openrisc/
>
>  OPENVSWITCH
>
> -- 

[OpenRISC] [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Jonas Bonn]

On 09/19/2016 04:04 PM, Stafford Horne wrote:
>
>
> On Mon, 19 Sep 2016, Guenter Roeck wrote:
>
>> On 09/19/2016 02:11 AM, Stafford Horne wrote:
>>>
>>>
>>>  On Mon, 19 Sep 2016, Guenter Roeck wrote:
>>>
>>> >  On 09/18/2016 11:02 PM, Stafford Horne wrote:
>>> > > > > > >   On Sun, 18 Sep 2016, Guenter Roeck wrote:
>>> > > > > >   Tested-by: Guenter Roeck <linux@roeck-us.net>
>>> > > > >   If you plan to handle openrisc going forward, it would be 
>>> great > > > >   if you > could
>>> > > >   consider updating MAINTAINERS. The web site and git 
>>> repository have > > >   been > unreachable
>>> > > >   for a long time.
>>> > > > >   Thank you,
>>> > >   Updating maintainers was kind of on my plans, but I figured I 
>>> need to
>>> > >   prove that I kind of know what I am doing.
>>> > > > >  The alternative would be to mark it as Orphaned. Which, for 
>>> all >  practical purpose,
>>> >  would be the correct state right now.
>>>
>>>  +CC The openrisc list
>>>
>>>  Understood, I don't think we would want that to happen.
>>>
>> Look at the entry today:
>>
>> OPENRISC ARCHITECTURE
>> M:      Jonas Bonn <jonas@southpole.se>
>> W:      http://openrisc.net
>> S:      Maintained
>> T:      git git://openrisc.net/~jonas/linux
>> F:      arch/openrisc/
>>
>> At the very least, W: and T: are incorrect and need to be updated or 
>> removed.
>> Plus, apparently there is a L:, and "T: 
>> https://github.com/openrisc/linux"
>> might be appropriate.
>>
>
> Thanks,
> I am aware of this, we have since setup a new website, mailing list 
> and as you have found, git repo. Stefan has been nominated as the 
> maintainer by Jonas on a previous mail thread.
>
> The issue (as we see it) is that neither Stefan or I have signed PGP 
> keys by anyone in the web of trust.
>
> I sent this patch set with a cover lett trying to explain of the 
> situation trying to get some help.  Your reponses are very helpful.
>
> Do you think I should just send "git pull" reuqests to Linus with a 
> self signed pgp key and eplaination to see how it goes?

The bigger question I would have at this point is the value of the code 
remaining upstream...  Five years ago, there was a promise to try to get 
the toolchain upstream within a year or two; to this day, I don't know 
that much progress has been made there so this architecture still 
requires a hodge-podge of tools from various sources to build.

Given the toolchain maintainer's general reluctance to move things 
upstream, I'd almost be inclined to just remove the OpenRISC arch from 
the kernel altogether.  Are there any other arch's that can't be built 
with an upstream GCC at this point?

/Jonas

>
> -Stafford
>
> FYI
> I have a change as following in my backlog, as follows:
>
> ---
> @@ -8691,10 +8063,12 @@ F:      drivers/of/overlay.c
>  F:     drivers/of/resolver.c
>
>  OPENRISC ARCHITECTURE
> -M:    Jonas Bonn <jonas@southpole.se>
> -W:    http://openrisc.net
> +M:    Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
> +M:    Stafford Horne <shorne@gmail.com>
> +W:    http://openrisc.io
> +L:    openrisc at lists.librecores.org
> +T:    https://github.com/openrisc/linux.git
>  S:    Maintained
> -T:    git git://openrisc.net/~jonas/linux
>  F:    arch/openrisc/
>
>  OPENVSWITCH
>
> -- 

Re: [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Guenter Roeck]

On 09/19/2016 07:04 AM, Stafford Horne wrote:
>
>
> On Mon, 19 Sep 2016, Guenter Roeck wrote:
>
>> On 09/19/2016 02:11 AM, Stafford Horne wrote:
>>>
>>>
>>>  On Mon, 19 Sep 2016, Guenter Roeck wrote:
>>>
>>> >  On 09/18/2016 11:02 PM, Stafford Horne wrote:
>>> > > > > > >   On Sun, 18 Sep 2016, Guenter Roeck wrote:
>>> > > > > >   Tested-by: Guenter Roeck <linux@roeck-us.net>
>>> > > > >   If you plan to handle openrisc going forward, it would be great > > > >   if you >  could
>>> > > >   consider updating MAINTAINERS. The web site and git repository have > > >   been >  unreachable
>>> > > >   for a long time.
>>> > > > >   Thank you,
>>> > >   Updating maintainers was kind of on my plans, but I figured I need to
>>> > >   prove that I kind of know what I am doing.
>>> > > > >  The alternative would be to mark it as Orphaned. Which, for all >  practical purpose,
>>> >  would be the correct state right now.
>>>
>>>  +CC The openrisc list
>>>
>>>  Understood, I don't think we would want that to happen.
>>>
>> Look at the entry today:
>>
>> OPENRISC ARCHITECTURE
>> M:      Jonas Bonn <jonas@southpole.se>
>> W:      http://openrisc.net
>> S:      Maintained
>> T:      git git://openrisc.net/~jonas/linux
>> F:      arch/openrisc/
>>
>> At the very least, W: and T: are incorrect and need to be updated or removed.
>> Plus, apparently there is a L:, and "T: https://github.com/openrisc/linux"
>> might be appropriate.
>>
>
> Thanks,
> I am aware of this, we have since setup a new website, mailing list and as you have found, git repo. Stefan has been nominated as the maintainer by Jonas on a previous mail thread.
>
> The issue (as we see it) is that neither Stefan or I have signed PGP keys by anyone in the web of trust.
>
> I sent this patch set with a cover lett trying to explain of the situation trying to get some help.  Your reponses are very helpful.
>
> Do you think I should just send "git pull" reuqests to Linus with a self signed pgp key and eplaination to see how it goes?
>

Nope, that won't work. Linus will not accept pull requests without signed key,
or at least I would be very surprised if he does. You'll have to get your key
signed. I understand that may be tricky, with you being in Japan (if that is
you ;-), but we can't help it.

Guenter

> -Stafford
>
> FYI
> I have a change as following in my backlog, as follows:
>
> ---
> @@ -8691,10 +8063,12 @@ F:      drivers/of/overlay.c
>  F:     drivers/of/resolver.c
>
>  OPENRISC ARCHITECTURE
> -M:    Jonas Bonn <jonas@southpole.se>
> -W:    http://openrisc.net
> +M:    Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
> +M:    Stafford Horne <shorne@gmail.com>
> +W:    http://openrisc.io
> +L:    openrisc@lists.librecores.org
> +T:    https://github.com/openrisc/linux.git
>  S:    Maintained
> -T:    git git://openrisc.net/~jonas/linux
>  F:    arch/openrisc/
>
>  OPENVSWITCH
>
> --
>

[OpenRISC] [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Guenter Roeck]

On 09/19/2016 07:04 AM, Stafford Horne wrote:
>
>
> On Mon, 19 Sep 2016, Guenter Roeck wrote:
>
>> On 09/19/2016 02:11 AM, Stafford Horne wrote:
>>>
>>>
>>>  On Mon, 19 Sep 2016, Guenter Roeck wrote:
>>>
>>> >  On 09/18/2016 11:02 PM, Stafford Horne wrote:
>>> > > > > > >   On Sun, 18 Sep 2016, Guenter Roeck wrote:
>>> > > > > >   Tested-by: Guenter Roeck <linux@roeck-us.net>
>>> > > > >   If you plan to handle openrisc going forward, it would be great > > > >   if you >  could
>>> > > >   consider updating MAINTAINERS. The web site and git repository have > > >   been >  unreachable
>>> > > >   for a long time.
>>> > > > >   Thank you,
>>> > >   Updating maintainers was kind of on my plans, but I figured I need to
>>> > >   prove that I kind of know what I am doing.
>>> > > > >  The alternative would be to mark it as Orphaned. Which, for all >  practical purpose,
>>> >  would be the correct state right now.
>>>
>>>  +CC The openrisc list
>>>
>>>  Understood, I don't think we would want that to happen.
>>>
>> Look at the entry today:
>>
>> OPENRISC ARCHITECTURE
>> M:      Jonas Bonn <jonas@southpole.se>
>> W:      http://openrisc.net
>> S:      Maintained
>> T:      git git://openrisc.net/~jonas/linux
>> F:      arch/openrisc/
>>
>> At the very least, W: and T: are incorrect and need to be updated or removed.
>> Plus, apparently there is a L:, and "T: https://github.com/openrisc/linux"
>> might be appropriate.
>>
>
> Thanks,
> I am aware of this, we have since setup a new website, mailing list and as you have found, git repo. Stefan has been nominated as the maintainer by Jonas on a previous mail thread.
>
> The issue (as we see it) is that neither Stefan or I have signed PGP keys by anyone in the web of trust.
>
> I sent this patch set with a cover lett trying to explain of the situation trying to get some help.  Your reponses are very helpful.
>
> Do you think I should just send "git pull" reuqests to Linus with a self signed pgp key and eplaination to see how it goes?
>

Nope, that won't work. Linus will not accept pull requests without signed key,
or at least I would be very surprised if he does. You'll have to get your key
signed. I understand that may be tricky, with you being in Japan (if that is
you ;-), but we can't help it.

Guenter

> -Stafford
>
> FYI
> I have a change as following in my backlog, as follows:
>
> ---
> @@ -8691,10 +8063,12 @@ F:      drivers/of/overlay.c
>  F:     drivers/of/resolver.c
>
>  OPENRISC ARCHITECTURE
> -M:    Jonas Bonn <jonas@southpole.se>
> -W:    http://openrisc.net
> +M:    Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
> +M:    Stafford Horne <shorne@gmail.com>
> +W:    http://openrisc.io
> +L:    openrisc at lists.librecores.org
> +T:    https://github.com/openrisc/linux.git
>  S:    Maintained
> -T:    git git://openrisc.net/~jonas/linux
>  F:    arch/openrisc/
>
>  OPENVSWITCH
>
> --
>

Re: [PATCH 4/7] openrisc: Add thread-local storage (TLS) support

[Stafford Horne]

On Mon, 19 Sep 2016, Jonas Bonn wrote:

> On 09/16/2016 04:43 PM, Stafford Horne wrote:
>>  From: Christian Svensson <blue@cmd.nu>
>>
>>  Historically OpenRISC GCC has reserved r10 which we now use to hold
>>  the thread pointer for thread-local storage (TLS).
> I know this was proposed by way of this patch, but we deferred accepting this 
> until the OpenRISC spec could be updated accordingly.  Has this been done 
> now?  If not, still NAK.

Hi Jonas,

Thanks for your review, I do not believe the spec has been updated. I will 
look into seeing what I can do and update the patch if needed.

-Stafford

>>
>>  Signed-off-by: Christian Svensson <blue@cmd.nu>
>>  Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
>>  Signed-off-by: Stafford Horne <shorne@gmail.com>
>>  ---
>>    arch/openrisc/kernel/process.c | 13 +++++++++++++
>>    1 file changed, 13 insertions(+)
>>
>>  diff --git a/arch/openrisc/kernel/process.c
>>  b/arch/openrisc/kernel/process.c
>>  index 7095dfe..277123b 100644
>>  --- a/arch/openrisc/kernel/process.c
>>  +++ b/arch/openrisc/kernel/process.c
>>  @@ -173,6 +173,19 @@ copy_thread(unsigned long clone_flags, unsigned long
>>  usp,
>>
>>      if (usp)
>>    			userregs->sp = usp;
>>  +
>>  +		/*
>>  +		 * For CLONE_SETTLS set "tp" (r10) to the TLS pointer passed
>>  to sys_clone.
>>  +		 *
>>  +		 * The kernel entry is:
>>  +		 *	int clone (long flags, void *child_stack, int
>>  *parent_tid,
>>  +		 *		int *child_tid, struct void *tls)
>>  +		 *
>>  +		 * This makes the source r7 in the kernel registers.
>>  +		 */
>>  +		if (clone_flags & CLONE_SETTLS)
>>  +			userregs->gpr[10] = userregs->gpr[7];
>>  +
>>      userregs->gpr[11] = 0;	/* Result from fork() */
>>
>>      kregs->gpr[20] = 0;	/* Userspace thread */
>
>
>

Re: [PATCH 1/7] Apply transparent_union attribute to union semun

[Stafford Horne]

On Mon, 19 Sep 2016, Jonas Bonn wrote:

> NAK... this breaks other architectures.
>
> The OpenRISC toolchain is broken with regard to this issue.  Five years ago 
> (last I looked) nobody seemed interesting in fixing it. Has anything changed 
> here?

Hi Jonas,

This was also pointed out by the automated kbuild system and I replied on 
it. I am currently looking at a possible fix of adding an abi compat layer 
similar to what arm does with 'arch/arm/kernel/sys_oabi-compat.c'.

By toolchain being broken do you mean the openrisc abi spec is broken as 
well?  Last I checked gcc does compile as per the spec.  But it is not a 
very good spec.  There have been discussions to change this as well but no 
progress.

-Stafford

> On 09/16/2016 04:42 PM, Stafford Horne wrote:
>>  ..From: Jonas Bonn <jonas@southpole.se>
>>
>>  The syscall handler for semctl is written under the assumption that the
>>  toolchain will pass "small" unions as function parameters directly instead
>>  of by reference.  The union semun is "small" and thus fits this
>>  description.
>>
>>  Since it is assumed that the union will be passed directly and not by
>>  reference, it is safe to access the union members without going via
>>  get_user.
>>
>>  The OpenRISC architecture, however, passes all unions by reference, thus
>>  breaking the above assumption.
>>
>>  The technically correct fix here is to mark the union as being transparent
>>  so that the ABI of the union's first element determines the parameter
>>  passing method and thus make explicit what's already implied in the
>>  function
>>  definition.
>>
>>  Signed-off-by: Jonas Bonn <jonas@southpole.se>
>>  Signed-off-by: Stafford Horne <shorne@gmail.com>
>>  ---
>>    include/uapi/linux/sem.h | 2 +-
>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>
>>  diff --git a/include/uapi/linux/sem.h b/include/uapi/linux/sem.h
>>  index dd73b90..aabe50f 100644
>>  --- a/include/uapi/linux/sem.h
>>  +++ b/include/uapi/linux/sem.h
>>  @@ -48,7 +48,7 @@ union semun {
>>     unsigned short __user *array;	/* array for GETALL & SETALL */
>>     struct seminfo __user *__buf;	/* buffer for IPC_INFO */
>>     void __user *__pad;
>>  -};
>>  +} __attribute__ ((transparent_union));
>>
>>    struct  seminfo {
>>     int semmap;
>
>

Re: [PATCH 3/7] openrisc: restore call-saved regs on sigreturn

[Stafford Horne]

On Mon, 19 Sep 2016, Jonas Bonn wrote:

> On 09/16/2016 04:43 PM, Stafford Horne wrote:
>>  From: Jonas Bonn <jonas@southpole.se>
>>
>>  Return to userspace via _resume_userspace instead of via syscall return
>>  path for the rt_sigreturn syscall.
>>
>>  I'll rework this comment more later, but this patch needs testing.
>
> This whole patch was reworked later... what happened to that work? I recall 
> it being posted for testing without feedback...
>
> In any case, the patch comment needs cleaning up.

Hi Jonas,
When working through the changelogs to pull out these patches I didnt find 
anything more recent.  However, I did only notice the commit message 
needed cleanup after posting the patch set.  It was on my todo list to 
clean it up.

I will have another look for a later patch, I didnt find at first. But 
thanks for the info.

-Stafford

>>
>>  Old comment from previous patch:
>>
>>  The sigreturn syscall is more like a context switch than a function call;
>>  it entails a return from one context (the signal handler) to another
>>  (the process in question).  For a context switch like this there are
>>  effectively no call-saved regs that remain constant across the transition.
>>
>>  This patch restores the call-saved regs from pt_regs before returning from
>>  the syscall, effectively restoring the context that the process had before
>>  being interrupted by the signal handler.  Restoring the call-saved regs
>>  in this way allows us to return to userspace via the usual syscall fast
>>  path.
>>
>>  Reported-by: Sebastian Macke <sebastian@macke.de>
>>  Signed-off-by: Jonas Bonn <jonas@southpole.se>
>>  Signed-off-by: Stafford Horne <shorne@gmail.com>
>>  ---
>>    arch/openrisc/kernel/entry.S | 10 +++++++++-
>>    1 file changed, 9 insertions(+), 1 deletion(-)
>>
>>  diff --git a/arch/openrisc/kernel/entry.S b/arch/openrisc/kernel/entry.S
>>  index fec8bf9..572d223 100644
>>  --- a/arch/openrisc/kernel/entry.S
>>  +++ b/arch/openrisc/kernel/entry.S
>>  @@ -1101,8 +1101,16 @@ ENTRY(__sys_fork)
>>      l.addi	r3,r1,0
>>
>>    ENTRY(sys_rt_sigreturn)
>>  -	l.j	_sys_rt_sigreturn
>>  +	l.jal	_sys_rt_sigreturn
>>    	 l.addi	r3,r1,0
>>  +	l.sfne	r30,r0
>>  +	l.bnf	_no_syscall_trace
>>  +	 l.nop
>>  +	l.jal	do_syscall_trace_leave
>>  +	 l.addi	r3,r1,0
>>  +_no_syscall_trace:
>>  +	l.j	_resume_userspace
>>  +	 l.nop
>>
>>    /* This is a catch-all syscall for atomic instructions for the OpenRISC
>>    1000.
>>     * The functions takes a variable number of parameters depending on
>>     which
>
>

Re: [PATCH 6/7] openrisc: add SMP and NR_CPUS Kconfig options

[Stafford Horne]

On Mon, 19 Sep 2016, Jonas Bonn wrote:

> On 09/16/2016 04:43 PM, Stafford Horne wrote:
>>  From: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
>
> OpenRISC was not an SMP architecture last I looked... did the relevant spec 
> updates get made?  If not, NAK.
>
> The issue is, the OpenRISC architecture shouldn't be a moving target defined 
> by what the kernel supports... there's a spec that the kernel conforms to. 
> This is important for the (few) real users of the architecture.

Hi Jonas,
I actually just added these patches to get the kernel to build without 
warnings as it seems the build system now depends on NR_CPUS and SMP.

However, I think think they should be exposed as options. I will rework 
this patch or look at my build config so these are not required to be 
exposed as options.

As you mention SMP is not in the spec, but Stefan has put together an SMP 
hardware model and ported the kernel to it. Which is where this patch came 
from.

-Stafford

>>  Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
>>  Signed-off-by: Stafford Horne <shorne@gmail.com>
>>  ---
>>    arch/openrisc/Kconfig | 14 ++++++++++++++
>>    1 file changed, 14 insertions(+)
>>
>>  diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig
>>  index 489e7f9..2bcf8c3 100644
>>  --- a/arch/openrisc/Kconfig
>>  +++ b/arch/openrisc/Kconfig
>>  @@ -98,6 +98,20 @@ config OPENRISC_HAVE_INST_DIV
>>    	  Select this if your implementation has a hardware divide
>>    instruction
>>    endmenu
>>
>>  +config NR_CPUS
>>  +	int "Maximum number of CPUs (2-32)"
>>  +	range 2 32
>>  +	depends on SMP
>>  +	default "2"
>>  +
>>  +config SMP
>>  +	bool "Symmetric Multi-Processing support"
>>  +	help
>>  +	  This enables support for systems with more than one CPU. If you
>>  have
>>  +	  a system with only one CPU, say N. If you have a system with more
>>  +	  than one CPU, say Y.
>>  +
>>  +	  If you don't know what to do here, say N.
>>
>>    source kernel/Kconfig.hz
>>    source kernel/Kconfig.preempt
>
>

Re: [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Guenter Roeck]

On 09/19/2016 07:35 AM, Jonas Bonn wrote:
> On 09/19/2016 04:04 PM, Stafford Horne wrote:
>>
>>
>> On Mon, 19 Sep 2016, Guenter Roeck wrote:
>>
>>> On 09/19/2016 02:11 AM, Stafford Horne wrote:
>>>>
>>>>
>>>>  On Mon, 19 Sep 2016, Guenter Roeck wrote:
>>>>
>>>> >  On 09/18/2016 11:02 PM, Stafford Horne wrote:
>>>> > > > > > >   On Sun, 18 Sep 2016, Guenter Roeck wrote:
>>>> > > > > >   Tested-by: Guenter Roeck <linux@roeck-us.net>
>>>> > > > >   If you plan to handle openrisc going forward, it would be great > > > >   if you > could
>>>> > > >   consider updating MAINTAINERS. The web site and git repository have > > >   been > unreachable
>>>> > > >   for a long time.
>>>> > > > >   Thank you,
>>>> > >   Updating maintainers was kind of on my plans, but I figured I need to
>>>> > >   prove that I kind of know what I am doing.
>>>> > > > >  The alternative would be to mark it as Orphaned. Which, for all >  practical purpose,
>>>> >  would be the correct state right now.
>>>>
>>>>  +CC The openrisc list
>>>>
>>>>  Understood, I don't think we would want that to happen.
>>>>
>>> Look at the entry today:
>>>
>>> OPENRISC ARCHITECTURE
>>> M:      Jonas Bonn <jonas@southpole.se>
>>> W:      http://openrisc.net
>>> S:      Maintained
>>> T:      git git://openrisc.net/~jonas/linux
>>> F:      arch/openrisc/
>>>
>>> At the very least, W: and T: are incorrect and need to be updated or removed.
>>> Plus, apparently there is a L:, and "T: https://github.com/openrisc/linux"
>>> might be appropriate.
>>>
>>
>> Thanks,
>> I am aware of this, we have since setup a new website, mailing list and as you have found, git repo. Stefan has been nominated as the maintainer by Jonas on a previous mail thread.
>>
>> The issue (as we see it) is that neither Stefan or I have signed PGP keys by anyone in the web of trust.
>>
>> I sent this patch set with a cover lett trying to explain of the situation trying to get some help.  Your reponses are very helpful.
>>
>> Do you think I should just send "git pull" reuqests to Linus with a self signed pgp key and eplaination to see how it goes?
>
> The bigger question I would have at this point is the value of the code remaining upstream...  Five years ago, there was a promise to try to get the toolchain upstream within a year or two; to this day, I don't know that much progress has been made there so this architecture still requires a hodge-podge of tools from various sources to build.
>
> Given the toolchain maintainer's general reluctance to move things upstream, I'd almost be inclined to just remove the OpenRISC arch from the kernel altogether.  Are there any other arch's that can't be built with an upstream GCC at this point?
>

Yes, several. Definitely avr32. Several others don't build with the upstream gcc,
but no one really cares enough to fix it.

Guenter

> /Jonas
>
>>
>> -Stafford
>>
>> FYI
>> I have a change as following in my backlog, as follows:
>>
>> ---
>> @@ -8691,10 +8063,12 @@ F:      drivers/of/overlay.c
>>  F:     drivers/of/resolver.c
>>
>>  OPENRISC ARCHITECTURE
>> -M:    Jonas Bonn <jonas@southpole.se>
>> -W:    http://openrisc.net
>> +M:    Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
>> +M:    Stafford Horne <shorne@gmail.com>
>> +W:    http://openrisc.io
>> +L:    openrisc@lists.librecores.org
>> +T:    https://github.com/openrisc/linux.git
>>  S:    Maintained
>> -T:    git git://openrisc.net/~jonas/linux
>>  F:    arch/openrisc/
>>
>>  OPENVSWITCH
>>
>> --
>
>

[OpenRISC] [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Guenter Roeck]

On 09/19/2016 07:35 AM, Jonas Bonn wrote:
> On 09/19/2016 04:04 PM, Stafford Horne wrote:
>>
>>
>> On Mon, 19 Sep 2016, Guenter Roeck wrote:
>>
>>> On 09/19/2016 02:11 AM, Stafford Horne wrote:
>>>>
>>>>
>>>>  On Mon, 19 Sep 2016, Guenter Roeck wrote:
>>>>
>>>> >  On 09/18/2016 11:02 PM, Stafford Horne wrote:
>>>> > > > > > >   On Sun, 18 Sep 2016, Guenter Roeck wrote:
>>>> > > > > >   Tested-by: Guenter Roeck <linux@roeck-us.net>
>>>> > > > >   If you plan to handle openrisc going forward, it would be great > > > >   if you > could
>>>> > > >   consider updating MAINTAINERS. The web site and git repository have > > >   been > unreachable
>>>> > > >   for a long time.
>>>> > > > >   Thank you,
>>>> > >   Updating maintainers was kind of on my plans, but I figured I need to
>>>> > >   prove that I kind of know what I am doing.
>>>> > > > >  The alternative would be to mark it as Orphaned. Which, for all >  practical purpose,
>>>> >  would be the correct state right now.
>>>>
>>>>  +CC The openrisc list
>>>>
>>>>  Understood, I don't think we would want that to happen.
>>>>
>>> Look at the entry today:
>>>
>>> OPENRISC ARCHITECTURE
>>> M:      Jonas Bonn <jonas@southpole.se>
>>> W:      http://openrisc.net
>>> S:      Maintained
>>> T:      git git://openrisc.net/~jonas/linux
>>> F:      arch/openrisc/
>>>
>>> At the very least, W: and T: are incorrect and need to be updated or removed.
>>> Plus, apparently there is a L:, and "T: https://github.com/openrisc/linux"
>>> might be appropriate.
>>>
>>
>> Thanks,
>> I am aware of this, we have since setup a new website, mailing list and as you have found, git repo. Stefan has been nominated as the maintainer by Jonas on a previous mail thread.
>>
>> The issue (as we see it) is that neither Stefan or I have signed PGP keys by anyone in the web of trust.
>>
>> I sent this patch set with a cover lett trying to explain of the situation trying to get some help.  Your reponses are very helpful.
>>
>> Do you think I should just send "git pull" reuqests to Linus with a self signed pgp key and eplaination to see how it goes?
>
> The bigger question I would have at this point is the value of the code remaining upstream...  Five years ago, there was a promise to try to get the toolchain upstream within a year or two; to this day, I don't know that much progress has been made there so this architecture still requires a hodge-podge of tools from various sources to build.
>
> Given the toolchain maintainer's general reluctance to move things upstream, I'd almost be inclined to just remove the OpenRISC arch from the kernel altogether.  Are there any other arch's that can't be built with an upstream GCC at this point?
>

Yes, several. Definitely avr32. Several others don't build with the upstream gcc,
but no one really cares enough to fix it.

Guenter

> /Jonas
>
>>
>> -Stafford
>>
>> FYI
>> I have a change as following in my backlog, as follows:
>>
>> ---
>> @@ -8691,10 +8063,12 @@ F:      drivers/of/overlay.c
>>  F:     drivers/of/resolver.c
>>
>>  OPENRISC ARCHITECTURE
>> -M:    Jonas Bonn <jonas@southpole.se>
>> -W:    http://openrisc.net
>> +M:    Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
>> +M:    Stafford Horne <shorne@gmail.com>
>> +W:    http://openrisc.io
>> +L:    openrisc at lists.librecores.org
>> +T:    https://github.com/openrisc/linux.git
>>  S:    Maintained
>> -T:    git git://openrisc.net/~jonas/linux
>>  F:    arch/openrisc/
>>
>>  OPENVSWITCH
>>
>> --
>
>

Re: [PATCH 7/7] openrisc: remove the redundant of_platform_populate

[Stafford Horne]

On Mon, 19 Sep 2016, Jonas Bonn wrote:

> On 09/16/2016 04:43 PM, Stafford Horne wrote:
>>  From: Rob Herring <robh@kernel.org>
>>
>>  The of_platform_populate call in the openrisc arch code is now redundant
>>  as the DT core provides a default call. Openrisc has a NULL match table
>>  which means only top level nodes with compatible strings will have
>>  devices creates. The default version will also descend nodes in the
>>  match table such as "simple-bus" which should be fine as openrisc
>>  doesn't have any of these (though it is preferred that memory-mapped
>>  peripherals be grouped under a bus node(s)).
>>
>>  Signed-off-by: Rob Herring <robh@kernel.org>
>>  Cc: Jonas Bonn <jonas@southpole.se>
>>  Signed-off-by: Stafford Horne <shorne@gmail.com>
>
> Yes, this is fine, but trivial/generic stuff like this doesn't really need to 
> go via the OpenRISC repo, anyway.

That's right, however I didnt see anyone pick it up so I included it here.

>>  ---
>>    arch/openrisc/kernel/setup.c | 10 ----------
>>    1 file changed, 10 deletions(-)
>>
>>  diff --git a/arch/openrisc/kernel/setup.c b/arch/openrisc/kernel/setup.c
>>  index b4ed8b3..d2f78cf 100644
>>  --- a/arch/openrisc/kernel/setup.c
>>  +++ b/arch/openrisc/kernel/setup.c
>>  @@ -38,7 +38,6 @@
>>    #include <linux/of.h>
>>    #include <linux/memblock.h>
>>    #include <linux/device.h>
>>  -#include <linux/of_platform.h>
>>
>>    #include <asm/sections.h>
>>    #include <asm/segment.h>
>>  @@ -219,15 +218,6 @@ void __init or32_early_setup(void *fdt)
>>    	early_init_devtree(fdt);
>>    }
>>
>>  -static int __init openrisc_device_probe(void)
>>  -{
>>  -	of_platform_populate(NULL, NULL, NULL, NULL);
>>  -
>>  -	return 0;
>>  -}
>>  -
>>  -device_initcall(openrisc_device_probe);
>>  -
>>    static inline unsigned long extract_value_bits(unsigned long reg,
>>    					       short bit_nr, short width)
>>    {
>
>

[OpenRISC] [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Stefan Wallentowitz]

On 19.09.2016 16:35, Jonas Bonn wrote:

> The bigger question I would have at this point is the value of the code
> remaining upstream...  Five years ago, there was a promise to try to get
> the toolchain upstream within a year or two; to this day, I don't know
> that much progress has been made there so this architecture still
> requires a hodge-podge of tools from various sources to build.

Actually, there has been progress. All but one copyright assignment have
been collected and the last one blocks everything. Don't know if there
was any progress on this since last ORCONF, but at least we have like
nearly up-to-date GCC for some time now.

Cheers,
Stefan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.librecores.org/pipermail/openrisc/attachments/20160919/26acad3b/attachment.sig>

[OpenRISC] [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Stefan Wallentowitz]

On 19.09.2016 16:35, Jonas Bonn wrote:

> The bigger question I would have at this point is the value of the code
> remaining upstream...  Five years ago, there was a promise to try to get
> the toolchain upstream within a year or two; to this day, I don't know
> that much progress has been made there so this architecture still
> requires a hodge-podge of tools from various sources to build.

Actually, there has been progress. All but one copyright assignment have
been collected and the last one blocks everything. Don't know if there
was any progress on this since last ORCONF, but at least we have like
nearly up-to-date GCC for some time now.

Cheers,
Stefan



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.librecores.org/pipermail/openrisc/attachments/20160919/e77b16bd/attachment.sig>

Re: [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Stafford Horne]

On Mon, 19 Sep 2016, Jonas Bonn wrote:

> On 09/19/2016 04:04 PM, Stafford Horne wrote:
>> 
>>
>>  On Mon, 19 Sep 2016, Guenter Roeck wrote:
>> 
>> >  On 09/19/2016 02:11 AM, Stafford Horne wrote:
>> > > 
>> > > 
>> > >   On Mon, 19 Sep 2016, Guenter Roeck wrote:
>> > > 
>> > > >   On 09/18/2016 11:02 PM, Stafford Horne wrote:
>> > > > > > > > >    On Sun, 18 Sep 2016, Guenter Roeck wrote:
>> > > > > > > >    Tested-by: Guenter Roeck <linux@roeck-us.net>
>> > > > > > >    If you plan to handle openrisc going forward, it would be 
>> > > great > > > >    if you > could
>> > > > > >    consider updating MAINTAINERS. The web site and git 
>> > >  repository have > > >   been > unreachable
>> > > > > >    for a long time.
>> > > > > > >    Thank you,
>> > > > >    Updating maintainers was kind of on my plans, but I figured I 
>> > >  need to
>> > > > >    prove that I kind of know what I am doing.
>> > > > > > >   The alternative would be to mark it as Orphaned. Which, for 
>> > > all >   practical purpose,
>> > > >   would be the correct state right now.
>> > > 
>> > >   +CC The openrisc list
>> > > 
>> > >   Understood, I don't think we would want that to happen.
>> > > 
>> >  Look at the entry today:
>> > 
>> >  OPENRISC ARCHITECTURE
>> >  M:      Jonas Bonn <jonas@southpole.se>
>> >  W:      http://openrisc.net
>> >  S:      Maintained
>> >  T:      git git://openrisc.net/~jonas/linux
>> >  F:      arch/openrisc/
>> > 
>> >  At the very least, W: and T: are incorrect and need to be updated or 
>> >  removed.
>> >  Plus, apparently there is a L:, and "T: 
>> >  https://github.com/openrisc/linux"
>> >  might be appropriate.
>> > 
>>
>>  Thanks,
>>  I am aware of this, we have since setup a new website, mailing list and as
>>  you have found, git repo. Stefan has been nominated as the maintainer by
>>  Jonas on a previous mail thread.
>>
>>  The issue (as we see it) is that neither Stefan or I have signed PGP keys
>>  by anyone in the web of trust.
>>
>>  I sent this patch set with a cover lett trying to explain of the situation
>>  trying to get some help.  Your reponses are very helpful.
>>
>>  Do you think I should just send "git pull" reuqests to Linus with a self
>>  signed pgp key and eplaination to see how it goes?
>
> The bigger question I would have at this point is the value of the code 
> remaining upstream...  Five years ago, there was a promise to try to get the 
> toolchain upstream within a year or two; to this day, I don't know that much 
> progress has been made there so this architecture still requires a 
> hodge-podge of tools from various sources to build.
>
> Given the toolchain maintainer's general reluctance to move things upstream, 
> I'd almost be inclined to just remove the OpenRISC arch from the kernel 
> altogether.  Are there any other arch's that can't be built with an upstream 
> GCC at this point?

Hi Jonas,
We have tried to get the toolchain in order in the last year.  The latest 
efforts is headlined by a toolchain build tutorial here:
   http://openrisc.io/newlib/building.html

The main toolchain project
  binutils-gdb - is upstreamed, I have been working on getting more of the
                 but there are many patches sitting in our repo on github
                 I have been working on getting them rebased to 7.11 and
                 upstreamed.
  newlib       - is upstreamed, with my gdb fixes I have also worked on
                 fixing some bugs in the last year.
  gcc          - this is the problem, the gcc code has not been signed over
                 to the fsf by the original authors.  A clean-room rewrite
                 seems to needed last I checked

The projects are all being maintained on the openrisc github page and we 
are trying to keep it going.

The attraction of openrisc, I would say, is that its one of the only fully 
open platforms in the kernel. Its also relatively simple so for hobbyist 
and students who want to have a 32-bit cpu which they can do 'full-stack' 
development on it fits a good nitch.

Keeping it upstream means also this code base is not getting stale. But we 
do need people to look after it and the patches.

-Stafford

>>
>>  -Stafford
>>
>>  FYI
>>  I have a change as following in my backlog, as follows:
>>
>>  ---
>>  @@ -8691,10 +8063,12 @@ F:      drivers/of/overlay.c
>>   F:     drivers/of/resolver.c
>>
>>  OPENRISC ARCHITECTURE
>>  -M:    Jonas Bonn <jonas@southpole.se>
>>  -W:    http://openrisc.net
>>  +M:    Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
>>  +M:    Stafford Horne <shorne@gmail.com>
>>  +W:    http://openrisc.io
>>  +L:    openrisc@lists.librecores.org
>>  +T:    https://github.com/openrisc/linux.git
>>  S:    Maintained
>>  -T:    git git://openrisc.net/~jonas/linux
>>   F:    arch/openrisc/
>>
>>   OPENVSWITCH
>>
>>  -- 
>
>

[OpenRISC] [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Stafford Horne]

On Mon, 19 Sep 2016, Jonas Bonn wrote:

> On 09/19/2016 04:04 PM, Stafford Horne wrote:
>> 
>>
>>  On Mon, 19 Sep 2016, Guenter Roeck wrote:
>> 
>> >  On 09/19/2016 02:11 AM, Stafford Horne wrote:
>> > > 
>> > > 
>> > >   On Mon, 19 Sep 2016, Guenter Roeck wrote:
>> > > 
>> > > >   On 09/18/2016 11:02 PM, Stafford Horne wrote:
>> > > > > > > > >    On Sun, 18 Sep 2016, Guenter Roeck wrote:
>> > > > > > > >    Tested-by: Guenter Roeck <linux@roeck-us.net>
>> > > > > > >    If you plan to handle openrisc going forward, it would be 
>> > > great > > > >    if you > could
>> > > > > >    consider updating MAINTAINERS. The web site and git 
>> > >  repository have > > >   been > unreachable
>> > > > > >    for a long time.
>> > > > > > >    Thank you,
>> > > > >    Updating maintainers was kind of on my plans, but I figured I 
>> > >  need to
>> > > > >    prove that I kind of know what I am doing.
>> > > > > > >   The alternative would be to mark it as Orphaned. Which, for 
>> > > all >   practical purpose,
>> > > >   would be the correct state right now.
>> > > 
>> > >   +CC The openrisc list
>> > > 
>> > >   Understood, I don't think we would want that to happen.
>> > > 
>> >  Look at the entry today:
>> > 
>> >  OPENRISC ARCHITECTURE
>> >  M:      Jonas Bonn <jonas@southpole.se>
>> >  W:      http://openrisc.net
>> >  S:      Maintained
>> >  T:      git git://openrisc.net/~jonas/linux
>> >  F:      arch/openrisc/
>> > 
>> >  At the very least, W: and T: are incorrect and need to be updated or 
>> >  removed.
>> >  Plus, apparently there is a L:, and "T: 
>> >  https://github.com/openrisc/linux"
>> >  might be appropriate.
>> > 
>>
>>  Thanks,
>>  I am aware of this, we have since setup a new website, mailing list and as
>>  you have found, git repo. Stefan has been nominated as the maintainer by
>>  Jonas on a previous mail thread.
>>
>>  The issue (as we see it) is that neither Stefan or I have signed PGP keys
>>  by anyone in the web of trust.
>>
>>  I sent this patch set with a cover lett trying to explain of the situation
>>  trying to get some help.  Your reponses are very helpful.
>>
>>  Do you think I should just send "git pull" reuqests to Linus with a self
>>  signed pgp key and eplaination to see how it goes?
>
> The bigger question I would have at this point is the value of the code 
> remaining upstream...  Five years ago, there was a promise to try to get the 
> toolchain upstream within a year or two; to this day, I don't know that much 
> progress has been made there so this architecture still requires a 
> hodge-podge of tools from various sources to build.
>
> Given the toolchain maintainer's general reluctance to move things upstream, 
> I'd almost be inclined to just remove the OpenRISC arch from the kernel 
> altogether.  Are there any other arch's that can't be built with an upstream 
> GCC at this point?

Hi Jonas,
We have tried to get the toolchain in order in the last year.  The latest 
efforts is headlined by a toolchain build tutorial here:
   http://openrisc.io/newlib/building.html

The main toolchain project
  binutils-gdb - is upstreamed, I have been working on getting more of the
                 but there are many patches sitting in our repo on github
                 I have been working on getting them rebased to 7.11 and
                 upstreamed.
  newlib       - is upstreamed, with my gdb fixes I have also worked on
                 fixing some bugs in the last year.
  gcc          - this is the problem, the gcc code has not been signed over
                 to the fsf by the original authors.  A clean-room rewrite
                 seems to needed last I checked

The projects are all being maintained on the openrisc github page and we 
are trying to keep it going.

The attraction of openrisc, I would say, is that its one of the only fully 
open platforms in the kernel. Its also relatively simple so for hobbyist 
and students who want to have a 32-bit cpu which they can do 'full-stack' 
development on it fits a good nitch.

Keeping it upstream means also this code base is not getting stale. But we 
do need people to look after it and the patches.

-Stafford

>>
>>  -Stafford
>>
>>  FYI
>>  I have a change as following in my backlog, as follows:
>>
>>  ---
>>  @@ -8691,10 +8063,12 @@ F:      drivers/of/overlay.c
>>   F:     drivers/of/resolver.c
>>
>>  OPENRISC ARCHITECTURE
>>  -M:    Jonas Bonn <jonas@southpole.se>
>>  -W:    http://openrisc.net
>>  +M:    Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
>>  +M:    Stafford Horne <shorne@gmail.com>
>>  +W:    http://openrisc.io
>>  +L:    openrisc at lists.librecores.org
>>  +T:    https://github.com/openrisc/linux.git
>>  S:    Maintained
>>  -T:    git git://openrisc.net/~jonas/linux
>>   F:    arch/openrisc/
>>
>>   OPENVSWITCH
>>
>>  -- 
>
>

[OpenRISC] [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Jeremy Bennett]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 19/09/16 15:58, Stefan Wallentowitz wrote:
> On 19.09.2016 16:35, Jonas Bonn wrote:
> 
>> The bigger question I would have at this point is the value of
>> the code remaining upstream...  Five years ago, there was a
>> promise to try to get the toolchain upstream within a year or
>> two; to this day, I don't know that much progress has been made
>> there so this architecture still requires a hodge-podge of tools
>> from various sources to build.
> 
> Actually, there has been progress. All but one copyright assignment
> have been collected and the last one blocks everything. Don't know
> if there was any progress on this since last ORCONF, but at least
> we have like nearly up-to-date GCC for some time now.

Is there anything I can do to help unblock the last one (having been
around longer than some, I know some of the old contributors).

Best wishes,


Jeremy

> 
> Cheers, Stefan
> 
> 
> 
> _______________________________________________ OpenRISC mailing
> list OpenRISC at lists.librecores.org 
> https://lists.librecores.org/listinfo/openrisc
> 


- -- 
Tel:     +44 (1590) 610184
Cell:    +44 (7970) 676050
SkypeID: jeremybennett
Twitter: @jeremypbennett
Email:   jeremy.bennett at embecosm.com
Web:     www.embecosm.com
PGP key: 1024D/BEF58172FB4754E1 2009-03-20
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iGMEARECACMFAlfgBfIcHGplcmVteS5iZW5uZXR0QGVtYmVjb3NtLmNvbQAKCRC+
9YFy+0dU4fbcAKCBzSWPJ1diLz+0SLg4CpEwqBzOoACdF0y4LSTM/vBsqEFVDWN/
nnkYeZ8=
=52x5
-----END PGP SIGNATURE-----

[OpenRISC] [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Stafford Horne]

On Mon, 19 Sep 2016, Jeremy Bennett wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 19/09/16 15:58, Stefan Wallentowitz wrote:
>> On 19.09.2016 16:35, Jonas Bonn wrote:
>> 
>>> The bigger question I would have at this point is the value of
>>> the code remaining upstream...  Five years ago, there was a
>>> promise to try to get the toolchain upstream within a year or
>>> two; to this day, I don't know that much progress has been made
>>> there so this architecture still requires a hodge-podge of tools
>>> from various sources to build.
>> 
>> Actually, there has been progress. All but one copyright assignment
>> have been collected and the last one blocks everything. Don't know
>> if there was any progress on this since last ORCONF, but at least
>> we have like nearly up-to-date GCC for some time now.
>
> Is there anything I can do to help unblock the last one (having been
> around longer than some, I know some of the old contributors).

Hi Jeremy,

As far as I can tell from SVN->Git history, the first changes I can see 
are from "Giuseppe Scrivano" and "Peter Gavin" back in 2011.  I am 
guessing the fsf assignments are in order with them.

I would think that the one that Stefan mentioned is missing is *Damjan* 
who started port. Are you in contact with him?

https://gcc.gnu.org/ml/gcc/1999-11n/msg00391.html - first contact with gcc

https://gcc.gnu.org/ml/gcc-patches/2002-02/msg01788.html - further 
discussions

I would leave it to Stefan for details.

>> _______________________________________________ OpenRISC mailing
>> list OpenRISC at lists.librecores.org 
>> https://lists.librecores.org/listinfo/openrisc
>> 
>
>
> - -- 
> Tel:     +44 (1590) 610184
> Cell:    +44 (7970) 676050
> SkypeID: jeremybennett
> Twitter: @jeremypbennett
> Email:   jeremy.bennett at embecosm.com
> Web:     www.embecosm.com
> PGP key: 1024D/BEF58172FB4754E1 2009-03-20
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iGMEARECACMFAlfgBfIcHGplcmVteS5iZW5uZXR0QGVtYmVjb3NtLmNvbQAKCRC+
> 9YFy+0dU4fbcAKCBzSWPJ1diLz+0SLg4CpEwqBzOoACdF0y4LSTM/vBsqEFVDWN/
> nnkYeZ8=
> =52x5
> -----END PGP SIGNATURE-----
> _______________________________________________
> OpenRISC mailing list
> OpenRISC at lists.librecores.org
> https://lists.librecores.org/listinfo/openrisc

Re: [PATCH 7/7] openrisc: remove the redundant of_platform_populate

[Rob Herring]

On Mon, Sep 19, 2016 at 9:32 AM, Jonas Bonn <jonas@southpole.se> wrote:
> On 09/16/2016 04:43 PM, Stafford Horne wrote:
>>
>> From: Rob Herring <robh@kernel.org>
>>
>> The of_platform_populate call in the openrisc arch code is now redundant
>> as the DT core provides a default call. Openrisc has a NULL match table
>> which means only top level nodes with compatible strings will have
>> devices creates. The default version will also descend nodes in the
>> match table such as "simple-bus" which should be fine as openrisc
>> doesn't have any of these (though it is preferred that memory-mapped
>> peripherals be grouped under a bus node(s)).
>>
>> Signed-off-by: Rob Herring <robh@kernel.org>
>> Cc: Jonas Bonn <jonas@southpole.se>
>> Signed-off-by: Stafford Horne <shorne@gmail.com>
>
>
> Yes, this is fine, but trivial/generic stuff like this doesn't really need
> to go via the OpenRISC repo, anyway.

Then which tree do you think it should go thru? I could have applied
it, but it doesn't depend on anything else. So it should go via the
correct maintainer's tree.

Rob

[OpenRISC] [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Jeremy Bennett]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 19/09/16 17:09, Stafford Horne wrote:
> 
> 
> On Mon, 19 Sep 2016, Jeremy Bennett wrote:
> 
> On 19/09/16 15:58, Stefan Wallentowitz wrote:
>>>> On 19.09.2016 16:35, Jonas Bonn wrote:
>>>> 
>>>>> The bigger question I would have at this point is the value
>>>>> of the code remaining upstream...  Five years ago, there
>>>>> was a promise to try to get the toolchain upstream within a
>>>>> year or two; to this day, I don't know that much progress
>>>>> has been made there so this architecture still requires a
>>>>> hodge-podge of tools from various sources to build.
>>>> 
>>>> Actually, there has been progress. All but one copyright
>>>> assignment have been collected and the last one blocks
>>>> everything. Don't know if there was any progress on this
>>>> since last ORCONF, but at least we have like nearly
>>>> up-to-date GCC for some time now.
> 
> Is there anything I can do to help unblock the last one (having
> been around longer than some, I know some of the old
> contributors).
> 
>> Hi Jeremy,
> 
>> As far as I can tell from SVN->Git history, the first changes I
>> can see are from "Giuseppe Scrivano" and "Peter Gavin" back in
>> 2011.  I am guessing the fsf assignments are in order with them.
> 
>> I would think that the one that Stefan mentioned is missing is
>> *Damjan* who started port. Are you in contact with him?

Hi Stafford,

I haven't seen him for some years, but I'm connected on LinkedIn. I
can ping him.

I presume you would like him to assign any copyright in the GNU tool
chain for OpenRISC?

Best wishes,


Jeremy

>> https://gcc.gnu.org/ml/gcc/1999-11n/msg00391.html - first contact
>> with gcc
> 
>> https://gcc.gnu.org/ml/gcc-patches/2002-02/msg01788.html -
>> further discussions
> 
>> I would leave it to Stefan for details.
> 
>>>> _______________________________________________ OpenRISC
>>>> mailing list OpenRISC at lists.librecores.org 
>>>> https://lists.librecores.org/listinfo/openrisc
>>>> 
> 
> 
> -- Tel:     +44 (1590) 610184 Cell:    +44 (7970) 676050 SkypeID:
> jeremybennett Twitter: @jeremypbennett Email:
> jeremy.bennett at embecosm.com Web:     www.embecosm.com PGP key:
> 1024D/BEF58172FB4754E1 2009-03-20
>> _______________________________________________ OpenRISC mailing
>> list OpenRISC at lists.librecores.org 
>> https://lists.librecores.org/listinfo/openrisc

- -- 
Tel:     +44 (1590) 610184
Cell:    +44 (7970) 676050
SkypeID: jeremybennett
Twitter: @jeremypbennett
Email:   jeremy.bennett at embecosm.com
Web:     www.embecosm.com
PGP key: 1024D/BEF58172FB4754E1 2009-03-20
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iGMEARECACMFAlfgEeYcHGplcmVteS5iZW5uZXR0QGVtYmVjb3NtLmNvbQAKCRC+
9YFy+0dU4crgAKCTurydEQd1fKESpyf2ax2JmtB5RACfeyjovCkmP3P9MJXnCJ4u
SM0RDa8=
=sPoa
-----END PGP SIGNATURE-----

[OpenRISC] [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Stefan Wallentowitz]

I think it was beyond semi that are missing. 

Cheers, 
Stefan 

On September 19, 2016 6:27:19 PM GMT+02:00, Jeremy Bennett <jeremy.bennett@embecosm.com> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 19/09/16 17:09, Stafford Horne wrote:
>> 
>> 
>> On Mon, 19 Sep 2016, Jeremy Bennett wrote:
>> 
>> On 19/09/16 15:58, Stefan Wallentowitz wrote:
>>>>> On 19.09.2016 16:35, Jonas Bonn wrote:
>>>>> 
>>>>>> The bigger question I would have at this point is the value
>>>>>> of the code remaining upstream...  Five years ago, there
>>>>>> was a promise to try to get the toolchain upstream within a
>>>>>> year or two; to this day, I don't know that much progress
>>>>>> has been made there so this architecture still requires a
>>>>>> hodge-podge of tools from various sources to build.
>>>>> 
>>>>> Actually, there has been progress. All but one copyright
>>>>> assignment have been collected and the last one blocks
>>>>> everything. Don't know if there was any progress on this
>>>>> since last ORCONF, but at least we have like nearly
>>>>> up-to-date GCC for some time now.
>> 
>> Is there anything I can do to help unblock the last one (having
>> been around longer than some, I know some of the old
>> contributors).
>> 
>>> Hi Jeremy,
>> 
>>> As far as I can tell from SVN->Git history, the first changes I
>>> can see are from "Giuseppe Scrivano" and "Peter Gavin" back in
>>> 2011.  I am guessing the fsf assignments are in order with them.
>> 
>>> I would think that the one that Stefan mentioned is missing is
>>> *Damjan* who started port. Are you in contact with him?
>
>Hi Stafford,
>
>I haven't seen him for some years, but I'm connected on LinkedIn. I
>can ping him.
>
>I presume you would like him to assign any copyright in the GNU tool
>chain for OpenRISC?
>
>Best wishes,
>
>
>Jeremy
>
>>> https://gcc.gnu.org/ml/gcc/1999-11n/msg00391.html - first contact
>>> with gcc
>> 
>>> https://gcc.gnu.org/ml/gcc-patches/2002-02/msg01788.html -
>>> further discussions
>> 
>>> I would leave it to Stefan for details.
>> 
>>>>> _______________________________________________ OpenRISC
>>>>> mailing list OpenRISC at lists.librecores.org 
>>>>> https://lists.librecores.org/listinfo/openrisc
>>>>> 
>> 
>> 
>> -- Tel:     +44 (1590) 610184 Cell:    +44 (7970) 676050 SkypeID:
>> jeremybennett Twitter: @jeremypbennett Email:
>> jeremy.bennett at embecosm.com Web:     www.embecosm.com PGP key:
>> 1024D/BEF58172FB4754E1 2009-03-20
>>> _______________________________________________ OpenRISC mailing
>>> list OpenRISC at lists.librecores.org 
>>> https://lists.librecores.org/listinfo/openrisc
>
>- -- 
>Tel:     +44 (1590) 610184
>Cell:    +44 (7970) 676050
>SkypeID: jeremybennett
>Twitter: @jeremypbennett
>Email:   jeremy.bennett at embecosm.com
>Web:     www.embecosm.com
>PGP key: 1024D/BEF58172FB4754E1 2009-03-20
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v2
>
>iGMEARECACMFAlfgEeYcHGplcmVteS5iZW5uZXR0QGVtYmVjb3NtLmNvbQAKCRC+
>9YFy+0dU4crgAKCTurydEQd1fKESpyf2ax2JmtB5RACfeyjovCkmP3P9MJXnCJ4u
>SM0RDa8=
>=sPoa
>-----END PGP SIGNATURE-----
>_______________________________________________
>OpenRISC mailing list
>OpenRISC at lists.librecores.org
>https://lists.librecores.org/listinfo/openrisc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/openrisc/attachments/20160919/33e4c201/attachment.html>

[OpenRISC] [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Jeremy Bennett]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 19/09/16 18:15, Stefan Wallentowitz wrote:
> I think it was beyond semi that are missing.

I can't help there - I don't have the necessary relationships.  Might
be worth checking if the key players already have assignments on file
at the FSF.  If Damjan has, so may the others from the same time.

Best wishes,


Jeremy

> 
> Cheers, Stefan
> 
> On September 19, 2016 6:27:19 PM GMT+02:00, Jeremy Bennett 
> <jeremy.bennett@embecosm.com> wrote:
> 
> On 19/09/16 17:09, Stafford Horne wrote:
> 
> 
> 
> On Mon, 19 Sep 2016, Jeremy Bennett wrote:
> 
> On 19/09/16 15:58, Stefan Wallentowitz wrote:
> 
> On 19.09.2016 16:35, Jonas Bonn wrote:
> 
> The bigger question I would have at this point is the value of the
> code remaining upstream... Five years ago, there was a promise to
> try to get the toolchain upstream within a year or two; to this
> day, I don't know that much progress has been made there so this
> architecture still requires a hodge-podge of tools from various
> sources to build.
> 
> 
> Actually, there has been progress. All but one copyright assignment
> have been collected and the last one blocks everything. Don't know
> if there was any progress on this since last ORCONF, but at least
> we have like nearly up-to-date GCC for some time now.
> 
> 
> Is there anything I can do to help unblock the last one (having 
> been around longer than some, I know some of the old 
> contributors).
> 
> Hi Jeremy,
> 
> 
> As far as I can tell from SVN->Git history, the first changes I can
> see are from "Giuseppe Scrivano" and "Peter Gavin" back in 2011. I
> am guessing the fsf assignments are in order with them.
> 
> 
> I would think that the one that Stefan mentioned is missing is 
> *Damjan* who started port. Are you in contact with him?
> 
> 
> Hi Stafford,
> 
> I haven't seen him for some years, but I'm connected on LinkedIn.
> I can ping him.
> 
> I presume you would like him to assign any copyright in the GNU
> tool chain for OpenRISC?
> 
> Best wishes,
> 
> 
> Jeremy
> 
> https://gcc.gnu.org/ml/gcc/1999-11n/msg00391.html - first contact 
> with gcc
> 
> 
> https://gcc.gnu.org/ml/gcc-patches/2002-02/msg01788.html - further
> discussions
> 
> 
> I would leave it to Stefan for details.
> 
> 
> ------------------------------------------------------------------------
>
> 
OpenRISC
> mailing list OpenRISC at lists.librecores.org 
> https://lists.librecores.org/listinfo/openrisc
> 
> 
> 
> -- Tel: +44 (1590) 610184 Cell: +44 (7970) 676050 SkypeID: 
> jeremybennett Twitter: @jeremypbennett Email: 
> jeremy.bennett at embecosm.com Web: www.embecosm.com 
> <http://www.embecosm.com> PGP key: 1024D/BEF58172FB4754E1
> 2009-03-20
> 
> ------------------------------------------------------------------------
>
> 
OpenRISC mailing
> list OpenRISC at lists.librecores.org 
> https://lists.librecores.org/listinfo/openrisc
> 
> 
> ------------------------------------------------------------------------
>
>  OpenRISC mailing list OpenRISC at lists.librecores.org 
> https://lists.librecores.org/listinfo/openrisc
> 

- -- 
Tel:     +44 (1590) 610184
Cell:    +44 (7970) 676050
SkypeID: jeremybennett
Twitter: @jeremypbennett
Email:   jeremy.bennett at embecosm.com
Web:     www.embecosm.com
PGP key: 1024D/BEF58172FB4754E1 2009-03-20
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iGMEARECACMFAlfgJTAcHGplcmVteS5iZW5uZXR0QGVtYmVjb3NtLmNvbQAKCRC+
9YFy+0dU4V9jAJ0bR6s/YiHWCEBalLOKBW/gO6KDLwCfeHgL3PnSsJTWKNvVI+CD
ncDO268=
=wMBt
-----END PGP SIGNATURE-----

Re: [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Stafford Horne]

On Mon, 19 Sep 2016, Guenter Roeck wrote:

> On 09/19/2016 07:04 AM, Stafford Horne wrote:
>> 
>>
>>  On Mon, 19 Sep 2016, Guenter Roeck wrote:
>> 
>> >  On 09/19/2016 02:11 AM, Stafford Horne wrote:
>> > > 
>> > > 
>> > >   On Mon, 19 Sep 2016, Guenter Roeck wrote:
>> > > 
>> > > >   On 09/18/2016 11:02 PM, Stafford Horne wrote:
>> > > > > > > > >    On Sun, 18 Sep 2016, Guenter Roeck wrote:
>> > > > > > > >    Tested-by: Guenter Roeck <linux@roeck-us.net>
>> > > > > > >    If you plan to handle openrisc going forward, it would be 
>> > > > > > >    great > > > >   if you >  could
>> > > > > >    consider updating MAINTAINERS. The web site and git repository 
>> > > > > >    have > > >   been >  unreachable
>> > > > > >    for a long time.
>> > > > > > >    Thank you,
>> > > > >    Updating maintainers was kind of on my plans, but I figured I 
>> > > > >    need to
>> > > > >    prove that I kind of know what I am doing.
>> > > > > > >   The alternative would be to mark it as Orphaned. Which, for 
>> > > > > > >   all >  practical purpose,
>> > > >   would be the correct state right now.
>> > > 
>> > >   +CC The openrisc list
>> > > 
>> > >   Understood, I don't think we would want that to happen.
>> > > 
>> >  Look at the entry today:
>> > 
>> >  OPENRISC ARCHITECTURE
>> >  M:      Jonas Bonn <jonas@southpole.se>
>> >  W:      http://openrisc.net
>> >  S:      Maintained
>> >  T:      git git://openrisc.net/~jonas/linux
>> >  F:      arch/openrisc/
>> > 
>> >  At the very least, W: and T: are incorrect and need to be updated or 
>> >  removed.
>> >  Plus, apparently there is a L:, and "T: 
>> >  https://github.com/openrisc/linux"
>> >  might be appropriate.
>> > 
>>
>>  Thanks,
>>  I am aware of this, we have since setup a new website, mailing list and as
>>  you have found, git repo. Stefan has been nominated as the maintainer by
>>  Jonas on a previous mail thread.
>>
>>  The issue (as we see it) is that neither Stefan or I have signed PGP keys
>>  by anyone in the web of trust.
>>
>>  I sent this patch set with a cover lett trying to explain of the situation
>>  trying to get some help.  Your reponses are very helpful.
>>
>>  Do you think I should just send "git pull" reuqests to Linus with a self
>>  signed pgp key and eplaination to see how it goes?
>> 
>
> Nope, that won't work. Linus will not accept pull requests without signed 
> key,
> or at least I would be very surprised if he does. You'll have to get your key
> signed. I understand that may be tricky, with you being in Japan (if that is
> you ;-), but we can't help it.

Thats as I figured.

It is me and I just missed LinuxCon Japan 2016 as I was out of town. I 
have some contacts I may be able to reach out to though.

-Stafford

>>  FYI
>>  I have a change as following in my backlog, as follows:
>>
>>  ---
>>  @@ -8691,10 +8063,12 @@ F:      drivers/of/overlay.c
>>   F:     drivers/of/resolver.c
>>
>>  OPENRISC ARCHITECTURE
>>  -M:    Jonas Bonn <jonas@southpole.se>
>>  -W:    http://openrisc.net
>>  +M:    Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
>>  +M:    Stafford Horne <shorne@gmail.com>
>>  +W:    http://openrisc.io
>>  +L:    openrisc@lists.librecores.org
>>  +T:    https://github.com/openrisc/linux.git
>>  S:    Maintained
>>  -T:    git git://openrisc.net/~jonas/linux
>>   F:    arch/openrisc/
>>
>>   OPENVSWITCH
>>
>>  --
>> 
>
>

[OpenRISC] [PATCH 5/7] openrisc: Support both old (or32) and new (or1k) toolchain

[Stafford Horne]

On Mon, 19 Sep 2016, Guenter Roeck wrote:

> On 09/19/2016 07:04 AM, Stafford Horne wrote:
>> 
>>
>>  On Mon, 19 Sep 2016, Guenter Roeck wrote:
>> 
>> >  On 09/19/2016 02:11 AM, Stafford Horne wrote:
>> > > 
>> > > 
>> > >   On Mon, 19 Sep 2016, Guenter Roeck wrote:
>> > > 
>> > > >   On 09/18/2016 11:02 PM, Stafford Horne wrote:
>> > > > > > > > >    On Sun, 18 Sep 2016, Guenter Roeck wrote:
>> > > > > > > >    Tested-by: Guenter Roeck <linux@roeck-us.net>
>> > > > > > >    If you plan to handle openrisc going forward, it would be 
>> > > > > > >    great > > > >   if you >  could
>> > > > > >    consider updating MAINTAINERS. The web site and git repository 
>> > > > > >    have > > >   been >  unreachable
>> > > > > >    for a long time.
>> > > > > > >    Thank you,
>> > > > >    Updating maintainers was kind of on my plans, but I figured I 
>> > > > >    need to
>> > > > >    prove that I kind of know what I am doing.
>> > > > > > >   The alternative would be to mark it as Orphaned. Which, for 
>> > > > > > >   all >  practical purpose,
>> > > >   would be the correct state right now.
>> > > 
>> > >   +CC The openrisc list
>> > > 
>> > >   Understood, I don't think we would want that to happen.
>> > > 
>> >  Look at the entry today:
>> > 
>> >  OPENRISC ARCHITECTURE
>> >  M:      Jonas Bonn <jonas@southpole.se>
>> >  W:      http://openrisc.net
>> >  S:      Maintained
>> >  T:      git git://openrisc.net/~jonas/linux
>> >  F:      arch/openrisc/
>> > 
>> >  At the very least, W: and T: are incorrect and need to be updated or 
>> >  removed.
>> >  Plus, apparently there is a L:, and "T: 
>> >  https://github.com/openrisc/linux"
>> >  might be appropriate.
>> > 
>>
>>  Thanks,
>>  I am aware of this, we have since setup a new website, mailing list and as
>>  you have found, git repo. Stefan has been nominated as the maintainer by
>>  Jonas on a previous mail thread.
>>
>>  The issue (as we see it) is that neither Stefan or I have signed PGP keys
>>  by anyone in the web of trust.
>>
>>  I sent this patch set with a cover lett trying to explain of the situation
>>  trying to get some help.  Your reponses are very helpful.
>>
>>  Do you think I should just send "git pull" reuqests to Linus with a self
>>  signed pgp key and eplaination to see how it goes?
>> 
>
> Nope, that won't work. Linus will not accept pull requests without signed 
> key,
> or at least I would be very surprised if he does. You'll have to get your key
> signed. I understand that may be tricky, with you being in Japan (if that is
> you ;-), but we can't help it.

Thats as I figured.

It is me and I just missed LinuxCon Japan 2016 as I was out of town. I 
have some contacts I may be able to reach out to though.

-Stafford

>>  FYI
>>  I have a change as following in my backlog, as follows:
>>
>>  ---
>>  @@ -8691,10 +8063,12 @@ F:      drivers/of/overlay.c
>>   F:     drivers/of/resolver.c
>>
>>  OPENRISC ARCHITECTURE
>>  -M:    Jonas Bonn <jonas@southpole.se>
>>  -W:    http://openrisc.net
>>  +M:    Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
>>  +M:    Stafford Horne <shorne@gmail.com>
>>  +W:    http://openrisc.io
>>  +L:    openrisc at lists.librecores.org
>>  +T:    https://github.com/openrisc/linux.git
>>  S:    Maintained
>>  -T:    git git://openrisc.net/~jonas/linux
>>   F:    arch/openrisc/
>>
>>   OPENVSWITCH
>>
>>  --
>> 
>
>

Re: [PATCH 3/7] openrisc: restore call-saved regs on sigreturn

[Stafford Horne]

On Mon, 19 Sep 2016, Stafford Horne wrote:

>
>
> On Mon, 19 Sep 2016, Jonas Bonn wrote:
>
>>  On 09/16/2016 04:43 PM, Stafford Horne wrote:
>> >   From: Jonas Bonn <jonas@southpole.se>
>> > 
>> >   Return to userspace via _resume_userspace instead of via syscall return
>> >   path for the rt_sigreturn syscall.
>> > 
>> >   I'll rework this comment more later, but this patch needs testing.
>>
>>  This whole patch was reworked later... what happened to that work? I
>>  recall it being posted for testing without feedback...
>>
>>  In any case, the patch comment needs cleaning up.
>
> Hi Jonas,
> When working through the changelogs to pull out these patches I didnt find 
> anything more recent.  However, I did only notice the commit message needed 
> cleanup after posting the patch set.  It was on my todo list to clean it up.
>
> I will have another look for a later patch, I didnt find at first. But thanks 
> for the info.

Hi Jonas,

I checked up on this and cannot find any more recent patch.  Do you have 
any details? It seems this patch was discussed off mailing lists as I 
wasn't able to find it anywhere other than a 3 way conversation sent to 
me by Stefan.

I can understand what this change is doing, but I find that ptrace 
is not working so well after applying it. Which might be related to what 
Sebastian Macke was seeing when he found strace was not working.

In the mean time I am trying to fix the issue, but if you have the revised 
patch it would be helpful.

-Stafford

>> > 
>> >   Old comment from previous patch:
>> > 
>> >   The sigreturn syscall is more like a context switch than a function 
>> >   call;
>> >   it entails a return from one context (the signal handler) to another
>> >   (the process in question).  For a context switch like this there are
>> >   effectively no call-saved regs that remain constant across the 
>> >   transition.
>> > 
>> >   This patch restores the call-saved regs from pt_regs before returning 
>> >   from
>> >   the syscall, effectively restoring the context that the process had 
>> >   before
>> >   being interrupted by the signal handler.  Restoring the call-saved regs
>> >   in this way allows us to return to userspace via the usual syscall fast
>> >   path.
>> > 
>> >   Reported-by: Sebastian Macke <sebastian@macke.de>
>> >   Signed-off-by: Jonas Bonn <jonas@southpole.se>
>> >   Signed-off-by: Stafford Horne <shorne@gmail.com>
>> >   ---
>> >     arch/openrisc/kernel/entry.S | 10 +++++++++-
>> >     1 file changed, 9 insertions(+), 1 deletion(-)
>> > 
>> >   diff --git a/arch/openrisc/kernel/entry.S 
>> >   b/arch/openrisc/kernel/entry.S
>> >   index fec8bf9..572d223 100644
>> >   --- a/arch/openrisc/kernel/entry.S
>> >   +++ b/arch/openrisc/kernel/entry.S
>> >   @@ -1101,8 +1101,16 @@ ENTRY(__sys_fork)
>> >       l.addi	r3,r1,0
>> > 
>> >     ENTRY(sys_rt_sigreturn)
>> >   -	l.j	_sys_rt_sigreturn
>> >   +	l.jal	_sys_rt_sigreturn
>> >     	 l.addi	r3,r1,0
>> >   +	l.sfne	r30,r0
>> >   +	l.bnf	_no_syscall_trace
>> >   +	 l.nop
>> >   +	l.jal	do_syscall_trace_leave
>> >   +	 l.addi	r3,r1,0
>> >   +_no_syscall_trace:
>> >   +	l.j	_resume_userspace
>> >   +	 l.nop
>> > 
>> >     /* This is a catch-all syscall for atomic instructions for the 
>> >     OpenRISC
>> >     1000.
>> >      * The functions takes a variable number of parameters depending on
>> >      which
>> 
>> 
>