openrisc: Misc fixes from backlog

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:

Quoted 1 line

Quoted 1 line

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;

Quoted 1 line

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

..From: Jonas Bonn <[email protected]>

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 <[email protected]>

Signed-off-by Stafford Horne <[email protected]>

---
  include/uapi/linux/sem.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

include/uapi/linux/sem.h +1 -1

index dd73b90..aabe50f 100644
@@ -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;

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?

Quoted 39 lines

..From: Jonas Bonn <[email protected]>

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 <[email protected]>

Signed-off-by Stafford Horne <[email protected]>

---

   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;

From: Stefan Kristiansson <[email protected]>

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 <[email protected]>

Signed-off-by Stafford Horne <[email protected]>

---
  arch/openrisc/include/asm/pgtable.h | 2 +-
  arch/openrisc/mm/init.c             | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

arch/openrisc/include/asm/pgtable.h +1 -1

index 69c7df0..3567aa7 100644
@@ -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

arch/openrisc/mm/init.c +1 -1

index 7f94652..b782ce9 100644
@@ -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)

From: Jonas Bonn <[email protected]>

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 <[email protected]>

Signed-off-by Jonas Bonn <[email protected]>

Signed-off-by Stafford Horne <[email protected]>

---
  arch/openrisc/kernel/entry.S | 10 +++++++++-
  1 file changed, 9 insertions(+), 1 deletion(-)

arch/openrisc/kernel/entry.S +9 -1

index fec8bf9..572d223 100644
@@ -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

Quoted 6 lines · Stafford Horne

From: Jonas Bonn <[email protected]>

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.

Quoted 45 lines

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 <[email protected]>

Signed-off-by Jonas Bonn <[email protected]>

Signed-off-by Stafford Horne <[email protected]>

---

   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

Quoted 11 lines · Jonas Bonn

Quoted 6 lines · Stafford Horne

From: Jonas Bonn <[email protected]>

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...

Quoted 1 line

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.

Quoted 53 lines

Quoted 51 lines

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 <[email protected]>

Signed-off-by Jonas Bonn <[email protected]>

Signed-off-by Stafford Horne <[email protected]>

---

    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

From: Christian Svensson <[email protected]>

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 <[email protected]>

Signed-off-by Stefan Kristiansson <[email protected]>

Signed-off-by Stafford Horne <[email protected]>

---
  arch/openrisc/kernel/process.c | 13 +++++++++++++
  1 file changed, 13 insertions(+)

arch/openrisc/kernel/process.c +13 -0

index 7095dfe..277123b 100644
@@ -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 */

Quoted 4 lines · Stafford Horne

From: Christian Svensson <[email protected]>

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.

Quoted 36 lines

Signed-off-by Christian Svensson <[email protected]>

Signed-off-by Stefan Kristiansson <[email protected]>

Signed-off-by Stafford Horne <[email protected]>

---

   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 */

From: Guenter Roeck <[email protected]>

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 <[email protected]>

Signed-off-by Stafford Horne <[email protected]>

---
 arch/openrisc/kernel/vmlinux.lds.S | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

arch/openrisc/kernel/vmlinux.lds.S +7 -1

index d936de4..4a72d5d 100644
@@ -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

Tested-by Guenter Roeck <[email protected]>

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.

On Sun, 18 Sep 2016, Guenter Roeck wrote:

Quoted 5 lines

Tested-by Guenter Roeck <[email protected]>

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.

Quoted 12 lines · Stafford Horne

Quoted 7 lines · Guenter Roeck

Tested-by Guenter Roeck <[email protected]>

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.

Quoted 4 lines

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.

Quoted 15 lines · Guenter Roeck

Quoted 13 lines · Stafford Horne

Quoted 4 lines · Guenter Roeck

Tested-by Guenter Roeck <[email protected]>

Quoted 1 line

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.

Quoted 2 lines

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.

Quoted 21 lines · Stafford Horne

Quoted 17 lines · Guenter Roeck

Quoted 15 lines · Stafford Horne

Quoted 6 lines · Guenter Roeck

Tested-by Guenter Roeck <[email protected]>

Quoted 2 lines

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.

Quoted 8 lines

Quoted 3 lines

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 <[email protected]>
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.

Quoted 34 lines · Guenter Roeck

Quoted 15 lines · Stafford Horne

Quoted 4 lines · Guenter Roeck

Quoted 3 lines · Stafford Horne

Quoted 3 lines

Quoted 3 lines

Quoted 2 lines

Quoted 1 line · Guenter Roeck

Tested-by Guenter Roeck <[email protected]>

If you plan to handle openrisc going forward, it would be

great > > > > if you > could

Quoted 1 line

Quoted 1 line

Quoted 1 line

consider updating MAINTAINERS. The web site and git

repository have > > > been > unreachable

Quoted 3 lines

Quoted 3 lines

Quoted 2 lines

for a long time.

Quoted 1 line

Thank you,

Updating maintainers was kind of on my plans, but I figured I

need to

Quoted 9 lines

Quoted 2 lines

Quoted 2 lines

prove that I kind of know what I am doing.

Quoted 1 line

Quoted 1 line

The alternative would be to mark it as Orphaned. Which, for

all > practical purpose,

Quoted 1 line

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 <[email protected]>
W:      http://openrisc.net
S:      Maintained
T:      git git://openrisc.net/~jonas/linux
F:      arch/openrisc/

Quoted 6 lines

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:

---

(quoted diff) +5 -3

@@ -8691,10 +8063,12 @@ F:      drivers/of/overlay.c
 F:     drivers/of/resolver.c
 
 OPENRISC ARCHITECTURE
-M:    Jonas Bonn <[email protected]>
-W:    http://openrisc.net
+M:    Stefan Kristiansson <[email protected]>
+M:    Stafford Horne <[email protected]>
+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

Signature · 1 line

-- 

Quoted 44 lines · Stafford Horne

Quoted 30 lines · Guenter Roeck

Quoted 11 lines · Stafford Horne

Quoted 7 lines · Guenter Roeck

Quoted 6 lines · Stafford Horne

Quoted 6 lines

Quoted 3 lines

Quoted 2 lines

Quoted 1 line · Guenter Roeck

Tested-by Guenter Roeck <[email protected]>

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.

Quoted 1 line

Thank you,

Quoted 9 lines

Quoted 4 lines

Quoted 3 lines

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

Quoted 1 line

Quoted 1 line

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 <[email protected]>
W:      http://openrisc.net
S:      Maintained
T:      git git://openrisc.net/~jonas/linux
F:      arch/openrisc/

Quoted 4 lines

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.

Quoted 3 lines

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

Quoted 25 lines

-Stafford

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

---

(quoted diff) +5 -4

@@ -8691,10 +8063,12 @@ F:      drivers/of/overlay.c
 F:     drivers/of/resolver.c
 
 OPENRISC ARCHITECTURE
-M:    Jonas Bonn <[email protected]>
-W:    http://openrisc.net
+M:    Stefan Kristiansson <[email protected]>
+M:    Stafford Horne <[email protected]>
+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
 
--

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.

Quoted 6 lines · Jonas Bonn

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

_______________________________________________ OpenRISC mailing list OpenRISC at lists.librecores.org
https://lists.librecores.org/listinfo/openrisc

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

Quoted 9 lines · Stefan Wallentowitz

Quoted 6 lines · Jonas Bonn

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.

Quoted 4 lines

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).

Quoted 4 lines

_______________________________________________ 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

On Mon, 19 Sep 2016, Jeremy Bennett wrote:

Quoted 9 lines · Stefan Wallentowitz

Quoted 9 lines

Quoted 9 lines · Jonas Bonn

Quoted 7 lines

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.

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

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).

Quoted 8 lines

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?

Quoted 12 lines

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.

Quoted 4 lines

Quoted 4 lines

_______________________________________________ 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

Quoted 3 lines

_______________________________________________ OpenRISC mailing list OpenRISC at lists.librecores.org
https://lists.librecores.org/listinfo/openrisc

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

Quoted 20 lines · Stafford Horne

On Mon, 19 Sep 2016, Jeremy Bennett wrote:

Quoted 9 lines · Stefan Wallentowitz

Quoted 9 lines

Quoted 9 lines · Jonas Bonn

Quoted 7 lines

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.

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

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.

Quoted 12 lines

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).

Quoted 8 lines

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

Quoted 14 lines

Quoted 12 lines

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.

Quoted 4 lines

Quoted 4 lines

_______________________________________________ OpenRISC mailing list OpenRISC at lists.librecores.org
https://lists.librecores.org/listinfo/openrisc

Quoted 7 lines

-- 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

Quoted 3 lines

_______________________________________________ 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

I think it was beyond semi that are missing.

Cheers, Stefan

On September 19, 2016 6:27:19 PM GMT+02:00, Jeremy Bennett <[email protected]> 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.

------------------------------------------------------------------------

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

------------------------------------------------------------------------

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

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.

Quoted 50 lines · Stafford Horne

Quoted 34 lines · Guenter Roeck

Quoted 15 lines · Stafford Horne

Quoted 4 lines · Guenter Roeck

Quoted 3 lines · Stafford Horne

Quoted 3 lines

Quoted 3 lines

Quoted 2 lines

Quoted 1 line · Guenter Roeck

Tested-by Guenter Roeck <[email protected]>

If you plan to handle openrisc going forward, it would be

great > > > > if you > could

Quoted 1 line

Quoted 1 line

Quoted 1 line

consider updating MAINTAINERS. The web site and git

repository have > > > been > unreachable

Quoted 3 lines

Quoted 3 lines

Quoted 2 lines

for a long time.

Quoted 1 line

Thank you,

Updating maintainers was kind of on my plans, but I figured I

need to

Quoted 9 lines

Quoted 2 lines

Quoted 2 lines

prove that I kind of know what I am doing.

Quoted 1 line

Quoted 1 line

The alternative would be to mark it as Orphaned. Which, for

all > practical purpose,

Quoted 1 line

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 <[email protected]>
 W:      http://openrisc.net
 S:      Maintained
 T:      git git://openrisc.net/~jonas/linux
 F:      arch/openrisc/

Quoted 6 lines

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.

Quoted 8 lines

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?

Quoted 25 lines

-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 <[email protected]>
 -W:    http://openrisc.net
 +M:    Stefan Kristiansson <[email protected]>
 +M:    Stafford Horne <[email protected]>
 +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

--

Quoted 30 lines · Guenter Roeck

Quoted 11 lines · Stafford Horne

Quoted 7 lines · Guenter Roeck

Quoted 6 lines · Stafford Horne

Quoted 6 lines

Quoted 3 lines

Quoted 2 lines

Quoted 1 line · Guenter Roeck

Tested-by Guenter Roeck <[email protected]>

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.

Quoted 1 line

Thank you,

Quoted 9 lines

Quoted 4 lines

Quoted 3 lines

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

Quoted 1 line

Quoted 1 line

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 <[email protected]>
W:      http://openrisc.net
S:      Maintained
T:      git git://openrisc.net/~jonas/linux
F:      arch/openrisc/

Quoted 4 lines

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:

---

(quoted diff) +5 -4

@@ -8691,10 +8063,12 @@ F:      drivers/of/overlay.c
 F:     drivers/of/resolver.c
 
 OPENRISC ARCHITECTURE
-M:    Jonas Bonn <[email protected]>
-W:    http://openrisc.net
+M:    Stefan Kristiansson <[email protected]>
+M:    Stafford Horne <[email protected]>
+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
 
--

Quoted 50 lines · Stafford Horne

Quoted 34 lines · Guenter Roeck

Quoted 16 lines · Stafford Horne

Quoted 12 lines · Guenter Roeck

Quoted 11 lines · Stafford Horne

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

Quoted 1 line · Guenter Roeck

Tested-by Guenter Roeck <[email protected]>

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.

Quoted 1 line

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.

Quoted 8 lines

Quoted 3 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

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 <[email protected]>
 W:      http://openrisc.net
 S:      Maintained
 T:      git git://openrisc.net/~jonas/linux
 F:      arch/openrisc/

Quoted 6 lines

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.

Quoted 9 lines

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.

Quoted 23 lines

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 <[email protected]>
 -W:    http://openrisc.net
 +M:    Stefan Kristiansson <[email protected]>
 +M:    Stafford Horne <[email protected]>
 +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

--

From: Stefan Kristiansson <[email protected]>

Signed-off-by Stefan Kristiansson <[email protected]>

Signed-off-by Stafford Horne <[email protected]>

---
  arch/openrisc/Kconfig | 14 ++++++++++++++
  1 file changed, 14 insertions(+)

arch/openrisc/Kconfig +14 -0

index 489e7f9..2bcf8c3 100644
@@ -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

Quoted 1 line · Stafford Horne

From: Stefan Kristiansson <[email protected]>

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.

Quoted 33 lines

Signed-off-by Stefan Kristiansson <[email protected]>

Signed-off-by Stafford Horne <[email protected]>

---

   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

From: Rob Herring <[email protected]>

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 <[email protected]>

Cc Jonas Bonn <[email protected]>

Signed-off-by Stafford Horne <[email protected]>

---
  arch/openrisc/kernel/setup.c | 10 ----------
  1 file changed, 10 deletions(-)

arch/openrisc/kernel/setup.c +0 -10

index b4ed8b3..d2f78cf 100644
@@ -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)
  {

Quoted 10 lines · Stafford Horne

From: Rob Herring <[email protected]>

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)).

Quoted 3 lines

Signed-off-by Rob Herring <[email protected]>

Cc Jonas Bonn <[email protected]>

Signed-off-by Stafford Horne <[email protected]>

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

Quoted 32 lines

---

   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)
{

Quoted 11 lines · Stafford Horne

From: Rob Herring <[email protected]>

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)).

Quoted 3 lines

Signed-off-by Rob Herring <[email protected]>

Cc Jonas Bonn <[email protected]>

Signed-off-by Stafford Horne <[email protected]>

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

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(-)

Signature · 1 line

2.7.4