[PATCH] Fix compile failure on PA-RISC

[PATCH] Fix compile failure on PA-RISC

[Mikulas Patocka]

Hi

This patch fixes compile failure on PA-RISC.

BTW. if the PA-RISC port is uncompilable for all 3.4-rc versions (and 
contains two other bugs that prevent it from booting) ... does it mean 
that I'm the only one who is using PA-RISC with recent kernel?

Mikulas

---

Fix compile failure on PA-RISC

This patch fixes compile error on PA-RISC.

The problem is this:
linux/bitops.h includes asm/bitops.h. Through a chain of dependencies
asm/bitops.h includes asm/page.h and asm/page.h needs function fls and
others defined in asm/bitops.h and linux/bitops.h --- and these
functions are not yet defined because the files linux/bitops.h and
asm/bitops.h hasn't been fully processed.

I moved cpu_relax from asm/processor.h to asm/barrier.h (and I changed
asm/processor.h to include asm/barrier.h so that current users can
assume that asm/processor.h defines cpu_relax). I changed asm/spinlock.h
to include asm/barrier.h and NOT include asm/processor.h. This breaks
the circular chain of dependencies and makes the kernel compile.


  CHK     include/linux/version.h
  UPD     include/linux/version.h
  CHK     include/generated/utsrelease.h
  UPD     include/generated/utsrelease.h
  CC      scripts/mod/empty.o
  MKELF   scripts/mod/elfconfig.h
  HOSTCC  scripts/mod/file2alias.o
  CC      kernel/bounds.s
  GEN     include/generated/bounds.h
  CC      arch/parisc/kernel/asm-offsets.s
In file included from include/asm-generic/getorder.h:7:0,
                 from /usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/page.h:162,
                 from /usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/pdc.h:346,
                 from /usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/hardware.h:5,
                 from /usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/processor.h:15,
                 from /usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/spinlock.h:4,
                 from /usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/atomic.h:20,
                 from include/linux/atomic.h:4,
                 from /usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/bitops.h:11,
                 from include/linux/bitops.h:22,
                 from include/linux/kernel.h:19,
                 from include/linux/sched.h:55,
                 from arch/parisc/kernel/asm-offsets.c:31:
include/linux/log2.h: In function '__ilog2_u32':
include/linux/log2.h:34:2: error: implicit declaration of function 'fls' [-Werror=implicit-function-declaration]
include/linux/log2.h: In function '__ilog2_u64':
include/linux/log2.h:42:2: error: implicit declaration of function 'fls64' [-Werror=implicit-function-declaration]
include/linux/log2.h: In function '__roundup_pow_of_two':
include/linux/log2.h:63:2: error: implicit declaration of function 'fls_long' [-Werror=implicit-function-declaration]
In file included from /usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/atomic.h:20:0,
                 from include/linux/atomic.h:4,
                 from /usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/bitops.h:11,
                 from include/linux/bitops.h:22,
                 from include/linux/kernel.h:19,
                 from include/linux/sched.h:55,
                 from arch/parisc/kernel/asm-offsets.c:31:
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/spinlock.h: In function 'arch_spin_is_locked':
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/spinlock.h:9:2: error: implicit declaration of function '__ldcw_align' [-Werror=implicit-function-declaration]
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/spinlock.h:9:29: warning: initialization makes pointer from integer without a cast [enabled by default]
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/spinlock.h: In function 'arch_spin_lock_flags':
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/spinlock.h:22:2: error: implicit declaration of function 'mb' [-Werror=implicit-function-declaration]
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/spinlock.h:23:4: warning: assignment makes pointer from integer without a cast [enabled by default]
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/spinlock.h:24:2: error: implicit declaration of function '__ldcw' [-Werror=implicit-function-declaration]
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/spinlock.h: In function 'arch_spin_unlock':
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/spinlock.h:39:4: warning: assignment makes pointer from integer without a cast [enabled by default]
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/spinlock.h: In function 'arch_spin_trylock':
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/spinlock.h:50:4: warning: assignment makes pointer from integer without a cast [enabled by default]
In file included from include/linux/atomic.h:4:0,
                 from /usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/bitops.h:11,
                 from include/linux/bitops.h:22,
                 from include/linux/kernel.h:19,
                 from include/linux/sched.h:55,
                 from arch/parisc/kernel/asm-offsets.c:31:
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/atomic.h: At top level:
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/atomic.h:30:56: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__lock_aligned'
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/atomic.h: In function '__atomic_add_return':
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/atomic.h:66:2: error: '__atomic_hash' undeclared (first use in this function)
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/atomic.h:66:2: note: each undeclared identifier is reported only once for each function it appears in
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/atomic.h: In function 'atomic_set':
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/atomic.h:77:2: error: '__atomic_hash' undeclared (first use in this function)
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/atomic.h: In function '__atomic64_add_return':
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/atomic.h:160:2: error: '__atomic_hash' undeclared (first use in this function)
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/atomic.h: In function 'atomic64_set':
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/atomic.h:172:2: error: '__atomic_hash' undeclared (first use in this function)
In file included from include/linux/bitops.h:22:0,
                 from include/linux/kernel.h:19,
                 from include/linux/sched.h:55,
                 from arch/parisc/kernel/asm-offsets.c:31:
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/bitops.h: In function 'set_bit':
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/bitops.h:37:2: error: '__atomic_hash' undeclared (first use in this function)
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/bitops.h: In function 'clear_bit':
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/bitops.h:48:2: error: '__atomic_hash' undeclared (first use in this function)
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/bitops.h: In function 'change_bit':
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/bitops.h:59:2: error: '__atomic_hash' undeclared (first use in this function)
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/bitops.h: In function 'test_and_set_bit':
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/bitops.h:72:2: error: '__atomic_hash' undeclared (first use in this function)
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/bitops.h: In function 'test_and_clear_bit':
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/bitops.h:90:2: error: '__atomic_hash' undeclared (first use in this function)
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/bitops.h: In function 'test_and_change_bit':
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/bitops.h:107:2: error: '__atomic_hash' undeclared (first use in this function)
In file included from include/linux/bitops.h:22:0,
                 from include/linux/kernel.h:19,
                 from include/linux/sched.h:55,
                 from arch/parisc/kernel/asm-offsets.c:31:
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/bitops.h: At top level:
/usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/bitops.h:186:23: error: static declaration of 'fls' follows non-static declaration
include/linux/log2.h:34:9: note: previous implicit declaration of 'fls' was here
In file included from /usr/src/linux-3.4-rc5-fast/arch/parisc/include/asm/bitops.h:214:0,
                 from include/linux/bitops.h:22,
                 from include/linux/kernel.h:19,
                 from include/linux/sched.h:55,
                 from arch/parisc/kernel/asm-offsets.c:31:
include/asm-generic/bitops/fls64.h:26:28: error: static declaration of 'fls64' follows non-static declaration
include/linux/log2.h:42:9: note: previous implicit declaration of 'fls64' was here
In file included from include/linux/kernel.h:19:0,
                 from include/linux/sched.h:55,
                 from arch/parisc/kernel/asm-offsets.c:31:
include/linux/bitops.h:160:24: error: conflicting types for 'fls_long'
include/linux/log2.h:63:16: note: previous implicit declaration of 'fls_long' was here
cc1: some warnings being treated as errors
make[1]: *** [arch/parisc/kernel/asm-offsets.s] Error 1
make: *** [prepare0] Error 2
make: *** Waiting for unfinished jobs....

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>

---
 arch/parisc/include/asm/barrier.h   |    2 ++
 arch/parisc/include/asm/processor.h |    3 +--
 arch/parisc/include/asm/spinlock.h  |    3 ++-
 3 files changed, 5 insertions(+), 3 deletions(-)

Index: linux-3.4-rc5-fast/arch/parisc/include/asm/spinlock.h
===================================================================
--- linux-3.4-rc5-fast.orig/arch/parisc/include/asm/spinlock.h	2012-05-03 23:52:36.000000000 +0200
+++ linux-3.4-rc5-fast/arch/parisc/include/asm/spinlock.h	2012-05-03 23:58:09.000000000 +0200
@@ -1,8 +1,9 @@
 #ifndef __ASM_SPINLOCK_H
 #define __ASM_SPINLOCK_H
 
-#include <asm/processor.h>
+#include <asm/barrier.h>
 #include <asm/spinlock_types.h>
+#include <asm/ldcw.h>
 
 static inline int arch_spin_is_locked(arch_spinlock_t *x)
 {
Index: linux-3.4-rc5-fast/arch/parisc/include/asm/barrier.h
===================================================================
--- linux-3.4-rc5-fast.orig/arch/parisc/include/asm/barrier.h	2012-05-03 23:52:36.000000000 +0200
+++ linux-3.4-rc5-fast/arch/parisc/include/asm/barrier.h	2012-05-04 23:49:47.000000000 +0200
@@ -32,4 +32,6 @@
 
 #define set_mb(var, value)		do { var = value; mb(); } while (0)
 
+#define cpu_relax()     __asm__ __volatile__("":::"memory")
+
 #endif /* __PARISC_BARRIER_H */
Index: linux-3.4-rc5-fast/arch/parisc/include/asm/processor.h
===================================================================
--- linux-3.4-rc5-fast.orig/arch/parisc/include/asm/processor.h	2012-05-03 23:52:36.000000000 +0200
+++ linux-3.4-rc5-fast/arch/parisc/include/asm/processor.h	2012-05-03 23:58:09.000000000 +0200
@@ -17,6 +17,7 @@
 #include <asm/ptrace.h>
 #include <asm/types.h>
 #include <asm/percpu.h>
+#include <asm/barrier.h>
 
 #endif /* __ASSEMBLY__ */
 
@@ -338,8 +339,6 @@ extern unsigned long get_wchan(struct ta
 #define KSTK_EIP(tsk)	((tsk)->thread.regs.iaoq[0])
 #define KSTK_ESP(tsk)	((tsk)->thread.regs.gr[30])
 
-#define cpu_relax()	barrier()
-
 /* Used as a macro to identify the combined VIPT/PIPT cached
  * CPUs which require a guarantee of coherency (no inequivalent
  * aliases with different data, whether clean or not) to operate */

[PATCH] Revert 5dd5bc40f3b6e0ccdaad948dbadc94ad0906cb25

[Mikulas Patocka]

Hi

This patch reverts commit 5dd5bc40f3b6e0ccdaad948dbadc94ad0906cb25.

The commit 5dd5bc40f3b6e0ccdaad948dbadc94ad0906cb25 causes system lockup 
when pdc is used as a boot console.

The kernel boots, but it locks up when transferring control to userspace 
--- the message "INIT: version 2.86 booting" is not printed and the 
computer halts. With the patch reverted, the system starts normally on 
pdc.

Mikulas

---

diff --git a/arch/parisc/kernel/pdc_cons.c b/arch/parisc/kernel/pdc_cons.c
index 4f00459..d14e20f 100644
--- a/arch/parisc/kernel/pdc_cons.c
+++ b/arch/parisc/kernel/pdc_cons.c
@@ -92,11 +92,10 @@ static int pdc_console_setup(struct console *co, char *options)
 
 static void pdc_console_poll(unsigned long unused);
 static DEFINE_TIMER(pdc_console_timer, pdc_console_poll, 0, 0);
-static struct tty_port tty_port;
 
 static int pdc_console_tty_open(struct tty_struct *tty, struct file *filp)
 {
-	tty_port_tty_set(&tty_port, tty);
+
 	mod_timer(&pdc_console_timer, jiffies + PDC_CONS_POLL_DELAY);
 
 	return 0;
@@ -104,10 +103,8 @@ static int pdc_console_tty_open(struct tty_struct *tty, struct file *filp)
 
 static void pdc_console_tty_close(struct tty_struct *tty, struct file *filp)
 {
-	if (!tty->count) {
+	if (!tty->count)
 		del_timer_sync(&pdc_console_timer);
-		tty_port_tty_set(&tty_port, NULL);
-	}
 }
 
 static int pdc_console_tty_write(struct tty_struct *tty, const unsigned char *buf, int count)
@@ -126,6 +123,8 @@ static int pdc_console_tty_chars_in_buffer(struct tty_struct *tty)
 	return 0; /* no buffer */
 }
 
+static struct tty_driver *pdc_console_tty_driver;
+
 static const struct tty_operations pdc_console_tty_ops = {
 	.open = pdc_console_tty_open,
 	.close = pdc_console_tty_close,
@@ -136,8 +135,10 @@ static const struct tty_operations pdc_console_tty_ops = {
 
 static void pdc_console_poll(unsigned long unused)
 {
+
 	int data, count = 0;
-	struct tty_struct *tty = tty_port_tty_get(&tty_port);
+
+	struct tty_struct *tty = pdc_console_tty_driver->ttys[0];
 
 	if (!tty)
 		return;
@@ -153,14 +154,10 @@ static void pdc_console_poll(unsigned long unused)
 	if (count)
 		tty_flip_buffer_push(tty);
 
-	tty_kref_put(tty);
-
 	if (pdc_cons.flags & CON_ENABLED)
 		mod_timer(&pdc_console_timer, jiffies + PDC_CONS_POLL_DELAY);
 }
 
-static struct tty_driver *pdc_console_tty_driver;
-
 static int __init pdc_console_tty_driver_init(void)
 {
 	int err;
@@ -185,8 +182,6 @@ static int __init pdc_console_tty_driver_init(void)
 	printk(KERN_INFO "The PDC console driver is still registered, removing CON_BOOT flag\n");
 	pdc_cons.flags &= ~CON_BOOT;
 
-	tty_port_init(&tty_port);
-
 	pdc_console_tty_driver = alloc_tty_driver(1);
 
 	if (!pdc_console_tty_driver)

Re: [PATCH] Revert 5dd5bc40f3b6e0ccdaad948dbadc94ad0906cb25

[Jiri Slaby]

On 05/05/2012 05:04 AM, Mikulas Patocka wrote:
> Hi
> 
> This patch reverts commit 5dd5bc40f3b6e0ccdaad948dbadc94ad0906cb25.
> 
> The commit 5dd5bc40f3b6e0ccdaad948dbadc94ad0906cb25 causes system lockup 
> when pdc is used as a boot console.
> 
> The kernel boots, but it locks up when transferring control to userspace 
> --- the message "INIT: version 2.86 booting" is not printed and the 
> computer halts. With the patch reverted, the system starts normally on 
> pdc.
...
> --- a/arch/parisc/kernel/pdc_cons.c
> +++ b/arch/parisc/kernel/pdc_cons.c
...
> @@ -104,10 +103,8 @@ static int pdc_console_tty_open(struct tty_struct *tty, struct file *filp)
>  
>  static void pdc_console_tty_close(struct tty_struct *tty, struct file *filp)
>  {
> -	if (!tty->count) {
> +	if (!tty->count)

Heh, I cannot find a bug in the patch proper. However this test is and
always was bogus. Does changing "!tty->count" to "tty->count == 1" help?

>  		del_timer_sync(&pdc_console_timer);
> -		tty_port_tty_set(&tty_port, NULL);
> -	}
>  }
>  
>  static int pdc_console_tty_write(struct tty_struct *tty, const unsigned char *buf, int count)

regards,
-- 
js
suse labs

Re: [PATCH] Revert 5dd5bc40f3b6e0ccdaad948dbadc94ad0906cb25

[Mikulas Patocka]

On Sat, 5 May 2012, Jiri Slaby wrote:

> On 05/05/2012 05:04 AM, Mikulas Patocka wrote:
> > Hi
> > 
> > This patch reverts commit 5dd5bc40f3b6e0ccdaad948dbadc94ad0906cb25.
> > 
> > The commit 5dd5bc40f3b6e0ccdaad948dbadc94ad0906cb25 causes system lockup 
> > when pdc is used as a boot console.
> > 
> > The kernel boots, but it locks up when transferring control to userspace 
> > --- the message "INIT: version 2.86 booting" is not printed and the 
> > computer halts. With the patch reverted, the system starts normally on 
> > pdc.
> ...
> > --- a/arch/parisc/kernel/pdc_cons.c
> > +++ b/arch/parisc/kernel/pdc_cons.c
> ...
> > @@ -104,10 +103,8 @@ static int pdc_console_tty_open(struct tty_struct *tty, struct file *filp)
> >  
> >  static void pdc_console_tty_close(struct tty_struct *tty, struct file *filp)
> >  {
> > -	if (!tty->count) {
> > +	if (!tty->count)
> 
> Heh, I cannot find a bug in the patch proper. However this test is and
> always was bogus. Does changing "!tty->count" to "tty->count == 1" help?

Yes, it fixes it.

Mikulas

> >  		del_timer_sync(&pdc_console_timer);
> > -		tty_port_tty_set(&tty_port, NULL);
> > -	}
> >  }
> >  
> >  static int pdc_console_tty_write(struct tty_struct *tty, const unsigned char *buf, int count)
> 
> regards,
> -- 
> js
> suse labs
> 
> 

[PATCH 1/1] TTY: pdc_cons, fix regression in close

[Jiri Slaby]

The test in pdc_console_tty_close '!tty->count' was always wrong
because tty->count is decremented after tty->ops->close is called and
thus can never be zero. Hence the 'then' branch was never executed and
the timer never deleted.

This did not matter until 5dd5bc40f3b6e0ccdaad948dbadc94ad0906cb25
(TTY: pdc_cons, use tty_port). There we needed to set TTY in tty_port
to NULL, but this never happened due to the bug above.

So change the test to really trigger at the last close by changing the
condition to 'tty->count == 1'.

Well, the driver should not touch tty->count at all. It should use
tty_port->count and count open count there itself.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reported-and-tested-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Cc: Helge Deller <deller@gmx.de>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
---
 arch/parisc/kernel/pdc_cons.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/parisc/kernel/pdc_cons.c b/arch/parisc/kernel/pdc_cons.c
index 4f00459..0b33933 100644
--- a/arch/parisc/kernel/pdc_cons.c
+++ b/arch/parisc/kernel/pdc_cons.c
@@ -104,7 +104,7 @@ static int pdc_console_tty_open(struct tty_struct *tty, struct file *filp)
 
 static void pdc_console_tty_close(struct tty_struct *tty, struct file *filp)
 {
-	if (!tty->count) {
+	if (tty->count == 1) {
 		del_timer_sync(&pdc_console_timer);
 		tty_port_tty_set(&tty_port, NULL);
 	}
-- 
1.7.9.2

Re: [PATCH] Fix compile failure on PA-RISC

[Rolf Eike Beer]

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

Mikulas Patocka wrote:
> Hi
> 
> This patch fixes compile failure on PA-RISC.
> 
> BTW. if the PA-RISC port is uncompilable for all 3.4-rc versions (and
> contains two other bugs that prevent it from booting) ... does it mean
> that I'm the only one who is using PA-RISC with recent kernel?
> 
> Mikulas
> 
> ---
> 
> Fix compile failure on PA-RISC
> 
> This patch fixes compile error on PA-RISC.
> 
> The problem is this:
> linux/bitops.h includes asm/bitops.h. Through a chain of dependencies
> asm/bitops.h includes asm/page.h and asm/page.h needs function fls and
> others defined in asm/bitops.h and linux/bitops.h --- and these
> functions are not yet defined because the files linux/bitops.h and
> asm/bitops.h hasn't been fully processed.

I've posted a set of patches on 2012-04-21 both on linux-kernel and linux-
parisc, but apart from one ACK I got no reaction.

I did only move the definition of PAGE0 from asm/pdc.h to asm/page.h and fixed 
another bunch of breakage that was detected while fixing this.

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] Fix compile failure on PA-RISC

[Linus Torvalds]

On Fri, May 4, 2012 at 11:55 PM, Rolf Eike Beer <eike-kernel@sf-tec.de> wrote:
>
> I did only move the definition of PAGE0 from asm/pdc.h to asm/page.h and fixed
> another bunch of breakage that was detected while fixing this.

I have to say that that sounds like a more natural patch. *Every*
other architecture defines cpu_relax() in <asm/processor.h>, so it
sounds like a bad idea to make PA-RISC any more different than
necessary.

Even if only one or two people actually care.

                     Linus

Re: [PATCH] Fix compile failure on PA-RISC

[Mikulas Patocka]

On Sat, 5 May 2012, Rolf Eike Beer wrote:

> Mikulas Patocka wrote:
> > Hi
> > 
> > This patch fixes compile failure on PA-RISC.
> > 
> > BTW. if the PA-RISC port is uncompilable for all 3.4-rc versions (and
> > contains two other bugs that prevent it from booting) ... does it mean
> > that I'm the only one who is using PA-RISC with recent kernel?
> > 
> > Mikulas
> > 
> > ---
> > 
> > Fix compile failure on PA-RISC
> > 
> > This patch fixes compile error on PA-RISC.
> > 
> > The problem is this:
> > linux/bitops.h includes asm/bitops.h. Through a chain of dependencies
> > asm/bitops.h includes asm/page.h and asm/page.h needs function fls and
> > others defined in asm/bitops.h and linux/bitops.h --- and these
> > functions are not yet defined because the files linux/bitops.h and
> > asm/bitops.h hasn't been fully processed.
> 
> I've posted a set of patches on 2012-04-21 both on linux-kernel and linux-
> parisc, but apart from one ACK I got no reaction.
> 
> I did only move the definition of PAGE0 from asm/pdc.h to asm/page.h and fixed 
> another bunch of breakage that was detected while fixing this.
> 
> Eike

I acknowledge that your patches work. So send them directly to Linus. I 
think there is not much maintenance being done on PA-RISC.

Mikulas

Re: [PATCH] Fix compile failure on PA-RISC

[John David Anglin]

On 5-May-12, at 2:55 PM, Mikulas Patocka wrote:

> I acknowledge that your patches work. So send them directly to  
> Linus. I
> think there is not much maintenance being done on PA-RISC.

James wrote back in March "I haven't yet actually tried git head on  
parisc
(and I won't be able to until I actually get my machines back  
[currently being
shipped across the atlantic]) but if there's a problem it will show up  
quickly:
parisc actually uses cpu hotplug to boot its secondary cpus."

Helge resigned due to lack of time.

This is my understanding as to why there is a maintenance gap.

For what I have been doing, I only use stable kernels.  I'm currently
running 3.3.4.

Dave
--
John David Anglin	dave.anglin@bell.net

Re: [PATCH] Fix compile failure on PA-RISC

[Helge Deller]

On 05/05/2012 10:09 PM, John David Anglin wrote:
> On 5-May-12, at 2:55 PM, Mikulas Patocka wrote:
> 
>> I acknowledge that your patches work. So send them directly to Linus. I
>> think there is not much maintenance being done on PA-RISC.
> 
> James wrote back in March "I haven't yet actually tried git head on parisc
> (and I won't be able to until I actually get my machines back [currently being
> shipped across the atlantic]) but if there's a problem it will show up quickly:
> parisc actually uses cpu hotplug to boot its secondary cpus."

> Helge resigned due to lack of time.

I'm still alive and was still reading the mailing list.
And I'm planning to test some newer kernels very soon again :-)
So, many thanks from my side to everyone who sent patches in the past
(incl. Mikulas, Rolf and others).

Helge

Re: [PATCH] Fix compile failure on PA-RISC

[James Bottomley]

On Sat, 2012-05-05 at 23:24 +0200, Helge Deller wrote:
> On 05/05/2012 10:09 PM, John David Anglin wrote:
> > On 5-May-12, at 2:55 PM, Mikulas Patocka wrote:
> > 
> >> I acknowledge that your patches work. So send them directly to Linus. I
> >> think there is not much maintenance being done on PA-RISC.
> > 
> > James wrote back in March "I haven't yet actually tried git head on parisc
> > (and I won't be able to until I actually get my machines back [currently being
> > shipped across the atlantic]) but if there's a problem it will show up quickly:
> > parisc actually uses cpu hotplug to boot its secondary cpus."
> 
> > Helge resigned due to lack of time.
> 
> I'm still alive and was still reading the mailing list.
> And I'm planning to test some newer kernels very soon again :-)
> So, many thanks from my side to everyone who sent patches in the past
> (incl. Mikulas, Rolf and others).

If you could, it would help.  I still have no access to PA systems
(should have mine by next week), but I'm on holiday this week anyway.

James

Re: [PATCH] Fix compile failure on PA-RISC

[Alan Cox]

On Fri, 4 May 2012 22:58:32 -0400 (EDT)
Mikulas Patocka <mpatocka@redhat.com> wrote:

> Hi
> 
> This patch fixes compile failure on PA-RISC.
> 
> BTW. if the PA-RISC port is uncompilable for all 3.4-rc versions (and 
> contains two other bugs that prevent it from booting) ... does it mean 
> that I'm the only one who is using PA-RISC with recent kernel?


Probably - and if so would you please get the NO_IRQ define fixed because
it seems parisc also has no maintainer any more 8)

Alan

Re: [PATCH] Fix compile failure on PA-RISC

[Mikulas Patocka]

On Sat, 5 May 2012, Alan Cox wrote:

> On Fri, 4 May 2012 22:58:32 -0400 (EDT)
> Mikulas Patocka <mpatocka@redhat.com> wrote:
> 
> > Hi
> > 
> > This patch fixes compile failure on PA-RISC.
> > 
> > BTW. if the PA-RISC port is uncompilable for all 3.4-rc versions (and 
> > contains two other bugs that prevent it from booting) ... does it mean 
> > that I'm the only one who is using PA-RISC with recent kernel?
> 
> 
> Probably - and if so would you please get the NO_IRQ define fixed because
> it seems parisc also has no maintainer any more 8)
> 
> Alan

What NO_IRQ problem do you mean? There is
#define NO_IRQ          (-1)
in arch/parisc/include/asm/irq.h.

And there are other NO_IRQ definitions in other architectures, some 
defining it to ((unsigned int)(-1)), some to 0xffffffff, some to INT_MAX, 
some to (-1) and some to (0).

Some drivers define NO_IRQ too, if not defined by the architecture.

Mikulas

Re: [PATCH] Fix compile failure on PA-RISC

[Linus Torvalds]

On Sat, May 5, 2012 at 11:53 AM, Mikulas Patocka <mpatocka@redhat.com> wrote:
>
> What NO_IRQ problem do you mean? There is
> #define NO_IRQ          (-1)
> in arch/parisc/include/asm/irq.h.

That's the one he means.

Switching it to zero and testing that things still work would be appreciated.

Much code already knows that NO_IRQ is supposed to be zero, and
there's tons of drivers that just do the (correct!) "if (!dev->irq)"
kind of thing.

Any architecture that has a non-zero NO_IRQ is basically broken.
Always has been.

                    Linus

Re: [PATCH] Fix compile failure on PA-RISC

[Rolf Eike Beer]

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

Linus Torvalds wrote:
> On Sat, May 5, 2012 at 11:53 AM, Mikulas Patocka <mpatocka@redhat.com> 
wrote:
> > What NO_IRQ problem do you mean? There is
> > #define NO_IRQ          (-1)
> > in arch/parisc/include/asm/irq.h.
> 
> That's the one he means.
> 
> Switching it to zero and testing that things still work would be
> appreciated.
> 
> Much code already knows that NO_IRQ is supposed to be zero, and
> there's tons of drivers that just do the (correct!) "if (!dev->irq)"
> kind of thing.
> 
> Any architecture that has a non-zero NO_IRQ is basically broken.
> Always has been.

The stuff in drivers/parisc/gsc.c doesn't look as if it would survive that 
change.

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] Fix compile failure on PA-RISC

[Mikulas Patocka]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; CHARSET=X-UNKNOWN, Size: 1091 bytes --]

On Sat, 5 May 2012, Linus Torvalds wrote:

> On Sat, May 5, 2012 at 11:53 AM, Mikulas Patocka <mpatocka@redhat.com> wrote:
> >
> > What NO_IRQ problem do you mean? There is
> > #define NO_IRQ          (-1)
> > in arch/parisc/include/asm/irq.h.
> 
> That's the one he means.
> 
> Switching it to zero and testing that things still work would be appreciated.

It works, but there is plenty of interrupt controllers on PC-RISC and I 
can only test it on C8000 with IO-SAPIC. I don't know if irq 0 is used on 
some PA-RISC interrupt controller. It would be best if James Bottomley 
tests it on his set of machines.

> Much code already knows that NO_IRQ is supposed to be zero, and
> there's tons of drivers that just do the (correct!) "if (!dev->irq)"
> kind of thing.
> 
> Any architecture that has a non-zero NO_IRQ is basically broken.
> Always has been.
> 
>                     Linus

And what about x86? --- irq 0 is used for timer and there is
void __init setup_default_timer_irq(void)
{
        setup_irq(0, &irq0);
}
in arch/x86/kernel/time.c.

Mikulas

Re: [PATCH] Fix compile failure on PA-RISC

[Alan Cox]

> And what about x86? --- irq 0 is used for timer and there is
> void __init setup_default_timer_irq(void)
> {
>         setup_irq(0, &irq0);
> }

That's an internal curio not exposed outside (or at least not in a way
that matters).

Alan

Re: [PATCH] Fix compile failure on PA-RISC

[Linus Torvalds]

On Tue, May 8, 2012 at 8:20 PM, Mikulas Patocka <mpatocka@redhat.com> wrote:
>>
>> Switching it to zero and testing that things still work would be appreciated.
>
> It works, but there is plenty of interrupt controllers on PC-RISC and I
> can only test it on C8000 with IO-SAPIC. I don't know if irq 0 is used on
> some PA-RISC interrupt controller. It would be best if James Bottomley
> tests it on his set of machines.

Heh. It sounds like we have more PA-RISC machines than we have actual users.

> And what about x86? --- irq 0 is used for timer and there is
> void __init setup_default_timer_irq(void)
> {
>        setup_irq(0, &irq0);
> }
> in arch/x86/kernel/time.c.

That's fine. There's no "irq" variable associated with it that people
can test. No driver will ever see an irq number of zero, no dynamic
irq code will ever see the zero.

So x86 rules have always been that the way drivers etc test for irq
existence has always been "irq 0 means no irq". Despite the fact that
it internally uses irq0 for its own nefarious uses.

                    Linus

Re: [PATCH] Fix compile failure on PA-RISC

[Geert Uytterhoeven]

On Wed, May 9, 2012 at 7:51 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, May 8, 2012 at 8:20 PM, Mikulas Patocka <mpatocka@redhat.com> wrote:
>>> Switching it to zero and testing that things still work would be appreciated.
>> It works, but there is plenty of interrupt controllers on PC-RISC and I
>> can only test it on C8000 with IO-SAPIC. I don't know if irq 0 is used on
>> some PA-RISC interrupt controller. It would be best if James Bottomley
>> tests it on his set of machines.
>
> Heh. It sounds like we have more PA-RISC machines than we have actual users.
>
>> And what about x86? --- irq 0 is used for timer and there is
>> void __init setup_default_timer_irq(void)
>> {
>>        setup_irq(0, &irq0);
>> }
>> in arch/x86/kernel/time.c.
>
> That's fine. There's no "irq" variable associated with it that people
> can test. No driver will ever see an irq number of zero, no dynamic
> irq code will ever see the zero.
>
> So x86 rules have always been that the way drivers etc test for irq
> existence has always been "irq 0 means no irq". Despite the fact that
> it internally uses irq0 for its own nefarious uses.

So can x86 please show the purely internal irq0 in its arch_show_interrupts(),
and accept "[PATCH] /proc/interrupts: irq zero is invalid"
(http://lkml.indiana.edu/hypermail/linux/kernel/1112.0/02229.html)?

Also, the several for_each_irq*() macros still iterate over zero, e.g.

# define for_each_irq_desc(irq, desc)                                   \
        for (irq = 0, desc = irq_to_desc(irq); irq < nr_irqs;           \
             irq++, desc = irq_to_desc(irq))                            \
                if (!desc)                                              \
                        ;                                               \
                else


# define for_each_irq_desc_reverse(irq, desc)                           \
        for (irq = nr_irqs - 1, desc = irq_to_desc(irq); irq >= 0;      \
             irq--, desc = irq_to_desc(irq))                            \
                if (!desc)                                              \
                        ;                                               \
                else

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] Fix compile failure on PA-RISC

[Alan Cox]

> What NO_IRQ problem do you mean? There is
> #define NO_IRQ          (-1)
> in arch/parisc/include/asm/irq.h.

It should be zero ready for us to get rid of it. Aa far as I can tell
pa-risc can just move to 0 without anything breaking. In fact some stuff
like serial port polling on 8250 ports will begin to work if it's done.

> And there are other NO_IRQ definitions in other architectures, some 
> defining it to ((unsigned int)(-1)), some to 0xffffffff, some to INT_MAX, 
> some to (-1) and some to (0).

Yes people are working on removing them all.

Alan

Re: [PATCH] Fix compile failure on PA-RISC

[Grant Grundler]

On Sun, May 6, 2012 at 5:24 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> What NO_IRQ problem do you mean? There is
>> #define NO_IRQ          (-1)
>> in arch/parisc/include/asm/irq.h.
>
> It should be zero ready for us to get rid of it. Aa far as I can tell
> pa-risc can just move to 0 without anything breaking. In fact some stuff
> like serial port polling on 8250 ports will begin to work if it's done.

Alan,
Didn't this patch of yours go in?
    http://www.spinics.net/lists/linux-parisc/msg03894.html

And it's amusing to read linus' previous rants on this issue from 2005:
    http://lkml.indiana.edu/hypermail/linux/kernel/0511.2/1720.html
    http://lkml.indiana.edu/hypermail/linux/kernel/0511.2/1741.html
    http://lkml.indiana.edu/hypermail/linux/kernel/0511.2/1845.html

cheers,
grant

Re: [PATCH] Fix compile failure on PA-RISC

[Alan Cox]

On Wed, 9 May 2012 10:38:30 -0700
Grant Grundler <grantgrundler@gmail.com> wrote:

> On Sun, May 6, 2012 at 5:24 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >> What NO_IRQ problem do you mean? There is
> >> #define NO_IRQ          (-1)
> >> in arch/parisc/include/asm/irq.h.
> >
> > It should be zero ready for us to get rid of it. Aa far as I can tell
> > pa-risc can just move to 0 without anything breaking. In fact some stuff
> > like serial port polling on 8250 ports will begin to work if it's done.
> 
> Alan,
> Didn't this patch of yours go in?
>     http://www.spinics.net/lists/linux-parisc/msg03894.html

Last I checked it hadn't - hence the request to test it when I saw
someone actually running parisc.