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 <[email protected]>
---
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 */
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)
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
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
On Fri, 4 May 2012 22:58:32 -0400 (EDT)
Mikulas Patocka <[email protected]> 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
On Fri, May 4, 2012 at 11:55 PM, Rolf Eike Beer <[email protected]> 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
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
>
>
On Sat, 5 May 2012, Alan Cox wrote:
> On Fri, 4 May 2012 22:58:32 -0400 (EDT)
> Mikulas Patocka <[email protected]> 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
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
On Sat, May 5, 2012 at 11:53 AM, Mikulas Patocka <[email protected]> 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
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 [email protected]
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 <[email protected]>
Reported-and-tested-by: Mikulas Patocka <[email protected]>
Cc: Kyle McMartin <[email protected]>
Cc: Helge Deller <[email protected]>
Cc: "James E.J. Bottomley" <[email protected]>
---
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
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
Linus Torvalds wrote:
> On Sat, May 5, 2012 at 11:53 AM, Mikulas Patocka <[email protected]>
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
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
> 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
On Sat, 5 May 2012, Linus Torvalds wrote:
> On Sat, May 5, 2012 at 11:53 AM, Mikulas Patocka <[email protected]> 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
> 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
On Sun, May 6, 2012 at 5:24 AM, Alan Cox <[email protected]> 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
On Tue, May 8, 2012 at 8:20 PM, Mikulas Patocka <[email protected]> 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
On Wed, May 9, 2012 at 7:51 PM, Linus Torvalds
<[email protected]> wrote:
> On Tue, May 8, 2012 at 8:20 PM, Mikulas Patocka <[email protected]> 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 -- [email protected]
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
On Wed, 9 May 2012 10:38:30 -0700
Grant Grundler <[email protected]> wrote:
> On Sun, May 6, 2012 at 5:24 AM, Alan Cox <[email protected]> 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.