From 04a3d311c01d3ad287750c5c8d03fa614475af91 Mon Sep 17 00:00:00 2001 From: Marc Zyngier Date: Sun, 26 Feb 2006 12:02:56 +0100 Subject: [PATCH] Fix Specialix SI probing As the (probably) last user of a Specialix SI board, I noticed that recent kernels would fail to probe the sucker. Quick investigation indicate a few missing braces... I left the double probing in place, as it looks like it's been here forever. Signed-off-by: Marc Zyngier Signed-off-by: Linus Torvalds --- drivers/char/sx.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) (limited to 'drivers/char') diff --git a/drivers/char/sx.c b/drivers/char/sx.c index c2490e2..588e75e 100644 --- a/drivers/char/sx.c +++ b/drivers/char/sx.c @@ -2173,15 +2173,17 @@ static int probe_si (struct sx_board *board) if ( IS_SI1_BOARD(board)) { /* This should be an SI1 board, which has this location writable... */ - if (read_sx_byte (board, SI2_ISA_ID_BASE) != 0x10) + if (read_sx_byte (board, SI2_ISA_ID_BASE) != 0x10) { func_exit (); return 0; + } } else { /* This should be an SI2 board, which has the bottom 3 bits non-writable... */ - if (read_sx_byte (board, SI2_ISA_ID_BASE) == 0x10) + if (read_sx_byte (board, SI2_ISA_ID_BASE) == 0x10) { func_exit (); return 0; + } } /* Now we're pretty much convinced that there is an SI board here, @@ -2192,15 +2194,17 @@ static int probe_si (struct sx_board *board) if ( IS_SI1_BOARD(board)) { /* This should be an SI1 board, which has this location writable... */ - if (read_sx_byte (board, SI2_ISA_ID_BASE) != 0x10) + if (read_sx_byte (board, SI2_ISA_ID_BASE) != 0x10) { func_exit(); return 0; + } } else { /* This should be an SI2 board, which has the bottom 3 bits non-writable... */ - if (read_sx_byte (board, SI2_ISA_ID_BASE) == 0x10) + if (read_sx_byte (board, SI2_ISA_ID_BASE) == 0x10) { func_exit (); return 0; + } } printheader (); -- cgit v1.1 From d904ffd6e0c3ab7631b07c21c9f9234a2e72d1f3 Mon Sep 17 00:00:00 2001 From: Marc Zyngier Date: Mon, 27 Feb 2006 12:08:00 +0100 Subject: [PATCH] Fix Specialix SX corruption With the latest kernels, I experienced some strange corruption, some '*****' being randomly inserted in the character flow, like this: ashes:~# ashes:~# a*******shes:~# ashes:~# ashes:~# Further investigation shows that the problem was introduced during Alan's "TTY layer buffering revamp" patch, the amount of data to be copied being reduced after buffer allocation. Moving the count fixup around solves the problem. Signed-off-by: Marc Zyngier Approved-by: Rogier Wolff Signed-off-by: Linus Torvalds --- drivers/char/sx.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'drivers/char') diff --git a/drivers/char/sx.c b/drivers/char/sx.c index 588e75e..a6b4f02 100644 --- a/drivers/char/sx.c +++ b/drivers/char/sx.c @@ -1095,17 +1095,17 @@ static inline void sx_receive_chars (struct sx_port *port) sx_dprintk (SX_DEBUG_RECEIVE, "rxop=%d, c = %d.\n", rx_op, c); + /* Don't copy past the end of the hardware receive buffer */ + if (rx_op + c > 0x100) c = 0x100 - rx_op; + + sx_dprintk (SX_DEBUG_RECEIVE, "c = %d.\n", c); + /* Don't copy more bytes than there is room for in the buffer */ c = tty_prepare_flip_string(tty, &rp, c); sx_dprintk (SX_DEBUG_RECEIVE, "c = %d.\n", c); - /* Don't copy past the end of the hardware receive buffer */ - if (rx_op + c > 0x100) c = 0x100 - rx_op; - - sx_dprintk (SX_DEBUG_RECEIVE, "c = %d.\n", c); - /* If for one reason or another, we can't copy more data, we're done! */ if (c == 0) break; -- cgit v1.1