[CFT:PATCH] 1/3: Adjust serial locking

[CFT:PATCH] 1/3: Adjust serial locking

[Russell King]

This patch changes the way serial ports are locked when getting modem
status.  This change is necessary because we will need to atomically
read the modem status and take action depending on the CTS status.

Any new drivers will need to be carefully reviewed for compliance
with this locking change.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Index: Documentation/serial/driver
===================================================================
--- d1d56a4a3295f62a01fc06ffc764da474d2aa9b1/Documentation/serial/driver  (mode:100644)
+++ uncommitted/Documentation/serial/driver  (mode:100644)
@@ -107,8 +107,8 @@
 	indicate that the signal is permanently active.  If RI is
 	not available, the signal should not be indicated as active.
 
-	Locking: none.
-	Interrupts: caller dependent.
+	Locking: port->lock taken.
+	Interrupts: locally disabled.
 	This call must not sleep
 
   stop_tx(port,tty_stop)
Index: drivers/serial/8250.c
===================================================================
--- d1d56a4a3295f62a01fc06ffc764da474d2aa9b1/drivers/serial/8250.c  (mode:100644)
+++ uncommitted/drivers/serial/8250.c  (mode:100644)
@@ -1390,13 +1390,10 @@
 static unsigned int serial8250_get_mctrl(struct uart_port *port)
 {
 	struct uart_8250_port *up = (struct uart_8250_port *)port;
-	unsigned long flags;
 	unsigned char status;
 	unsigned int ret;
 
-	spin_lock_irqsave(&up->port.lock, flags);
 	status = serial_in(up, UART_MSR);
-	spin_unlock_irqrestore(&up->port.lock, flags);
 
 	ret = 0;
 	if (status & UART_MSR_DCD)
Index: drivers/serial/au1x00_uart.c
===================================================================
--- d1d56a4a3295f62a01fc06ffc764da474d2aa9b1/drivers/serial/au1x00_uart.c  (mode:100644)
+++ uncommitted/drivers/serial/au1x00_uart.c  (mode:100644)
@@ -556,13 +556,10 @@
 static unsigned int serial8250_get_mctrl(struct uart_port *port)
 {
 	struct uart_8250_port *up = (struct uart_8250_port *)port;
-	unsigned long flags;
 	unsigned char status;
 	unsigned int ret;
 
-	spin_lock_irqsave(&up->port.lock, flags);
 	status = serial_in(up, UART_MSR);
-	spin_unlock_irqrestore(&up->port.lock, flags);
 
 	ret = 0;
 	if (status & UART_MSR_DCD)
Index: drivers/serial/ip22zilog.c
===================================================================
--- d1d56a4a3295f62a01fc06ffc764da474d2aa9b1/drivers/serial/ip22zilog.c  (mode:100644)
+++ uncommitted/drivers/serial/ip22zilog.c  (mode:100644)
@@ -518,27 +518,28 @@
 static __inline__ unsigned char ip22zilog_read_channel_status(struct uart_port *port)
 {
 	struct zilog_channel *channel;
-	unsigned long flags;
 	unsigned char status;
 
-	spin_lock_irqsave(&port->lock, flags);
-
 	channel = ZILOG_CHANNEL_FROM_PORT(port);
 	status = readb(&channel->control);
 	ZSDELAY();
 
-	spin_unlock_irqrestore(&port->lock, flags);
-
 	return status;
 }
 
 /* The port lock is not held.  */
 static unsigned int ip22zilog_tx_empty(struct uart_port *port)
 {
+	unsigned long flags;
 	unsigned char status;
 	unsigned int ret;
 
+	spin_lock_irqsave(&port->lock, flags);
+
 	status = ip22zilog_read_channel_status(port);
+
+	spin_unlock_irqrestore(&port->lock, flags);
+
 	if (status & Tx_BUF_EMP)
 		ret = TIOCSER_TEMT;
 	else
@@ -547,7 +548,7 @@
 	return ret;
 }
 
-/* The port lock is not held.  */
+/* The port lock is held and interrupts are disabled.  */
 static unsigned int ip22zilog_get_mctrl(struct uart_port *port)
 {
 	unsigned char status;
Index: drivers/serial/mpsc.c
===================================================================
--- d1d56a4a3295f62a01fc06ffc764da474d2aa9b1/drivers/serial/mpsc.c  (mode:100644)
+++ uncommitted/drivers/serial/mpsc.c  (mode:100644)
@@ -1058,12 +1058,9 @@
 {
 	struct mpsc_port_info *pi = (struct mpsc_port_info *)port;
 	u32 mflags, status;
-	ulong iflags;
 
-	spin_lock_irqsave(&pi->port.lock, iflags);
 	status = (pi->mirror_regs) ? pi->MPSC_CHR_10_m :
 		readl(pi->mpsc_base + MPSC_CHR_10);
-	spin_unlock_irqrestore(&pi->port.lock, iflags);
 
 	mflags = 0;
 	if (status & 0x1)
Index: drivers/serial/pmac_zilog.c
===================================================================
--- d1d56a4a3295f62a01fc06ffc764da474d2aa9b1/drivers/serial/pmac_zilog.c  (mode:100644)
+++ uncommitted/drivers/serial/pmac_zilog.c  (mode:100644)
@@ -604,7 +604,7 @@
 /* 
  * Get Modem Control bits (only the input ones, the core will
  * or that with a cached value of the control ones)
- * The port lock is not held.
+ * The port lock is held and interrupts are disabled.
  */
 static unsigned int pmz_get_mctrl(struct uart_port *port)
 {
@@ -615,7 +615,7 @@
 	if (ZS_IS_ASLEEP(uap) || uap->node == NULL)
 		return 0;
 
-	status = pmz_peek_status(to_pmz(port));
+	status = read_zsreg(uap, R0);
 
 	ret = 0;
 	if (status & DCD)
Index: drivers/serial/pxa.c
===================================================================
--- d1d56a4a3295f62a01fc06ffc764da474d2aa9b1/drivers/serial/pxa.c  (mode:100644)
+++ uncommitted/drivers/serial/pxa.c  (mode:100644)
@@ -274,14 +274,11 @@
 static unsigned int serial_pxa_get_mctrl(struct uart_port *port)
 {
 	struct uart_pxa_port *up = (struct uart_pxa_port *)port;
-	unsigned long flags;
 	unsigned char status;
 	unsigned int ret;
 
 return TIOCM_CTS | TIOCM_DSR | TIOCM_CAR;
-	spin_lock_irqsave(&up->port.lock, flags);
 	status = serial_in(up, UART_MSR);
-	spin_unlock_irqrestore(&up->port.lock, flags);
 
 	ret = 0;
 	if (status & UART_MSR_DCD)
Index: drivers/serial/serial_core.c
===================================================================
--- d1d56a4a3295f62a01fc06ffc764da474d2aa9b1/drivers/serial/serial_core.c  (mode:100644)
+++ uncommitted/drivers/serial/serial_core.c  (mode:100644)
@@ -828,7 +828,10 @@
 	if ((!file || !tty_hung_up_p(file)) &&
 	    !(tty->flags & (1 << TTY_IO_ERROR))) {
 		result = port->mctrl;
+
+		spin_lock_irq(&port->lock);
 		result |= port->ops->get_mctrl(port);
+		spin_unlock_irq(&port->lock);
 	}
 	up(&state->sem);
 
@@ -1369,6 +1372,7 @@
 	DECLARE_WAITQUEUE(wait, current);
 	struct uart_info *info = state->info;
 	struct uart_port *port = state->port;
+	unsigned int mctrl;
 
 	info->blocked_open++;
 	state->count--;
@@ -1416,7 +1420,10 @@
 		 * and wait for the carrier to indicate that the
 		 * modem is ready for us.
 		 */
-		if (port->ops->get_mctrl(port) & TIOCM_CAR)
+		spin_lock_irq(&port->lock);
+		mctrl = port->ops->get_mctrl(port);
+		spin_unlock_irq(&port->lock);
+		if (mctrl & TIOCM_CAR)
 			break;
 
 		up(&state->sem);
@@ -1618,7 +1625,9 @@
 
 	if(capable(CAP_SYS_ADMIN))
 	{
+		spin_lock_irq(&port->lock);
 		status = port->ops->get_mctrl(port);
+		spin_unlock_irq(&port->lock);
 
 		ret += sprintf(buf + ret, " tx:%d rx:%d",
 				port->icount.tx, port->icount.rx);
Index: drivers/serial/serial_txx9.c
===================================================================
--- d1d56a4a3295f62a01fc06ffc764da474d2aa9b1/drivers/serial/serial_txx9.c  (mode:100644)
+++ uncommitted/drivers/serial/serial_txx9.c  (mode:100644)
@@ -442,13 +442,10 @@
 static unsigned int serial_txx9_get_mctrl(struct uart_port *port)
 {
 	struct uart_txx9_port *up = (struct uart_txx9_port *)port;
-	unsigned long flags;
 	unsigned int ret;
 
-	spin_lock_irqsave(&up->port.lock, flags);
 	ret =  ((sio_in(up, TXX9_SIFLCR) & TXX9_SIFLCR_RTSSC) ? 0 : TIOCM_RTS)
 		| ((sio_in(up, TXX9_SICISR) & TXX9_SICISR_CTSS) ? 0 : TIOCM_CTS);
-	spin_unlock_irqrestore(&up->port.lock, flags);
 
 	return ret;
 }
Index: drivers/serial/sunsab.c
===================================================================
--- d1d56a4a3295f62a01fc06ffc764da474d2aa9b1/drivers/serial/sunsab.c  (mode:100644)
+++ uncommitted/drivers/serial/sunsab.c  (mode:100644)
@@ -426,18 +426,15 @@
 		sunsab_tx_idle(up);
 }
 
-/* port->lock is not held.  */
+/* port->lock is held by caller and interrupts are disabled.  */
 static unsigned int sunsab_get_mctrl(struct uart_port *port)
 {
 	struct uart_sunsab_port *up = (struct uart_sunsab_port *) port;
-	unsigned long flags;
 	unsigned char val;
 	unsigned int result;
 
 	result = 0;
 
-	spin_lock_irqsave(&up->port.lock, flags);
-
 	val = readb(&up->regs->r.pvr);
 	result |= (val & up->pvr_dsr_bit) ? 0 : TIOCM_DSR;
 
@@ -447,8 +444,6 @@
 	val = readb(&up->regs->r.star);
 	result |= (val & SAB82532_STAR_CTS) ? TIOCM_CTS : 0;
 
-	spin_unlock_irqrestore(&up->port.lock, flags);
-
 	return result;
 }
 
Index: drivers/serial/sunsu.c
===================================================================
--- d1d56a4a3295f62a01fc06ffc764da474d2aa9b1/drivers/serial/sunsu.c  (mode:100644)
+++ uncommitted/drivers/serial/sunsu.c  (mode:100644)
@@ -572,13 +572,10 @@
 static unsigned int sunsu_get_mctrl(struct uart_port *port)
 {
 	struct uart_sunsu_port *up = (struct uart_sunsu_port *) port;
-	unsigned long flags;
 	unsigned char status;
 	unsigned int ret;
 
-	spin_lock_irqsave(&up->port.lock, flags);
 	status = serial_in(up, UART_MSR);
-	spin_unlock_irqrestore(&up->port.lock, flags);
 
 	ret = 0;
 	if (status & UART_MSR_DCD)
Index: drivers/serial/sunzilog.c
===================================================================
--- d1d56a4a3295f62a01fc06ffc764da474d2aa9b1/drivers/serial/sunzilog.c  (mode:100644)
+++ uncommitted/drivers/serial/sunzilog.c  (mode:100644)
@@ -610,27 +610,28 @@
 static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)
 {
 	struct zilog_channel __iomem *channel;
-	unsigned long flags;
 	unsigned char status;
 
-	spin_lock_irqsave(&port->lock, flags);
-
 	channel = ZILOG_CHANNEL_FROM_PORT(port);
 	status = sbus_readb(&channel->control);
 	ZSDELAY();
 
-	spin_unlock_irqrestore(&port->lock, flags);
-
 	return status;
 }
 
 /* The port lock is not held.  */
 static unsigned int sunzilog_tx_empty(struct uart_port *port)
 {
+	unsigned long flags;
 	unsigned char status;
 	unsigned int ret;
 
+	spin_lock_irqsave(&port->lock, flags);
+
 	status = sunzilog_read_channel_status(port);
+
+	spin_unlock_irqrestore(&port->lock, flags);
+
 	if (status & Tx_BUF_EMP)
 		ret = TIOCSER_TEMT;
 	else
@@ -639,7 +640,7 @@
 	return ret;
 }
 
-/* The port lock is not held.  */
+/* The port lock is held and interrupts are disabled.  */
 static unsigned int sunzilog_get_mctrl(struct uart_port *port)
 {
 	unsigned char status;

Re: [CFT:PATCH] 2/3: Check status of CTS when using flow control

[Russell King]

Fix bugme #4712: read the CTS status and set hw_stopped if CTS
is not active.

Thanks to Stefan Wolff for spotting this problem.

Index: drivers/serial/serial_core.c
===================================================================
--- a/drivers/serial/serial_core.c  (mode:100644)
+++ b/drivers/serial/serial_core.c  (mode:100644)
@@ -180,6 +180,13 @@
 			 */
 			if (info->tty->termios->c_cflag & CBAUD)
 				uart_set_mctrl(port, TIOCM_RTS | TIOCM_DTR);
+
+			if (info->flags & UIF_CTS_FLOW) {
+				spin_lock_irq(&port->lock);
+				if (!(port->ops->get_mctrl(port) & TIOCM_CTS))
+					info->tty->hw_stopped = 1;
+				spin_unlock_irq(&port->lock);
+			}
 		}
 
 		info->flags |= UIF_INITIALIZED;
@@ -1134,6 +1141,16 @@
 		spin_unlock_irqrestore(&state->port->lock, flags);
 	}
 
+	/* Handle turning on CRTSCTS */
+	if (!(old_termios->c_cflag & CRTSCTS) && (cflag & CRTSCTS)) {
+		spin_lock_irqsave(&state->port->lock, flags);
+		if (!(state->port->ops->get_mctrl(state->port) & TIOCM_CTS)) {
+			tty->hw_stopped = 1;
+			state->port->ops->stop_tx(state->port, 0);
+		}
+		spin_unlock_irqrestore(&state->port->lock, flags);
+	}
+
 #if 0
 	/*
 	 * No need to wake up processes in open wait, since they

Re: [CFT:PATCH] 3/3: Disable OX950 transmitter for flow control

[Russell King]

Disable the transmitter whenever we want to prevent characters
being transmitted by flow control.  However, if we run out of
characters to send and want to only disable the TX interrupt,
allow that scenario.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Index: drivers/serial/8250.c
===================================================================
--- d1d56a4a3295f62a01fc06ffc764da474d2aa9b1/drivers/serial/8250.c  (mode:100644)
+++ uncommitted/drivers/serial/8250.c  (mode:100644)
@@ -1007,21 +1007,24 @@
 	up->port.irq = (irq > 0) ? irq : 0;
 }
 
+static inline void __stop_tx(struct uart_8250_port *p)
+{
+	if (p->ier & UART_IER_THRI) {
+		p->ier &= ~UART_IER_THRI;
+		serial_out(p, UART_IER, p->ier);
+	}
+}
+
 static void serial8250_stop_tx(struct uart_port *port, unsigned int tty_stop)
 {
 	struct uart_8250_port *up = (struct uart_8250_port *)port;
 
-	if (up->ier & UART_IER_THRI) {
-		up->ier &= ~UART_IER_THRI;
-		serial_out(up, UART_IER, up->ier);
-	}
+	__stop_tx(up);
 
 	/*
-	 * We only do this from uart_stop - if we run out of
-	 * characters to send, we don't want to prevent the
-	 * FIFO from emptying.
+	 * We really want to stop the transmitter from sending.
 	 */
-	if (up->port.type == PORT_16C950 && tty_stop) {
+	if (up->port.type == PORT_16C950) {
 		up->acr |= UART_ACR_TXDIS;
 		serial_icr_write(up, UART_ACR, up->acr);
 	}
@@ -1045,10 +1048,11 @@
 				transmit_chars(up);
 		}
 	}
+
 	/*
-	 * We only do this from uart_start
+	 * Re-enable the transmitter if we disabled it.
 	 */
-	if (tty_start && up->port.type == PORT_16C950) {
+	if (up->port.type == PORT_16C950 && up->acr & UART_ACR_TXDIS) {
 		up->acr &= ~UART_ACR_TXDIS;
 		serial_icr_write(up, UART_ACR, up->acr);
 	}
@@ -1169,7 +1173,7 @@
 		return;
 	}
 	if (uart_circ_empty(xmit) || uart_tx_stopped(&up->port)) {
-		serial8250_stop_tx(&up->port, 0);
+		__stop_tx(up);
 		return;
 	}
 
@@ -1188,7 +1192,7 @@
 	DEBUG_INTR("THRE...");
 
 	if (uart_circ_empty(xmit))
-		serial8250_stop_tx(&up->port, 0);
+		__stop_tx(up);
 }
 
 static _INLINE_ void check_modem_status(struct uart_8250_port *up)

Re: [CFT:PATCH] 2/3: Check status of CTS when using flow control

[Gene Heskett]

On Sunday 26 June 2005 18:17, Russell King wrote:
>Fix bugme #4712: read the CTS status and set hw_stopped if CTS
>is not active.
>
>Thanks to Stefan Wolff for spotting this problem.
>
This one needs to make mainline & maybe, after 3 years, I can use a 
pl2303 to talk to an old slow coco.  Twould be very nice if that 
fixed the lack of flow controls the connection apparently fails from.

>Index: drivers/serial/serial_core.c
>===================================================================
>--- a/drivers/serial/serial_core.c  (mode:100644)
>+++ b/drivers/serial/serial_core.c  (mode:100644)
>@@ -180,6 +180,13 @@
>     */
>    if (info->tty->termios->c_cflag & CBAUD)
>     uart_set_mctrl(port, TIOCM_RTS | TIOCM_DTR);
>+
>+   if (info->flags & UIF_CTS_FLOW) {
>+    spin_lock_irq(&port->lock);
>+    if (!(port->ops->get_mctrl(port) & TIOCM_CTS))
>+					info->tty->hw_stopped = 1;
>+				spin_unlock_irq(&port->lock);
>+			}
> 		}
>
> 		info->flags |= UIF_INITIALIZED;
>@@ -1134,6 +1141,16 @@
> 		spin_unlock_irqrestore(&state->port->lock, flags);
> 	}
>
>+	/* Handle turning on CRTSCTS */
>+	if (!(old_termios->c_cflag & CRTSCTS) && (cflag & CRTSCTS)) {
>+		spin_lock_irqsave(&state->port->lock, flags);
>+		if (!(state->port->ops->get_mctrl(state->port) & TIOCM_CTS)) {
>+			tty->hw_stopped = 1;
>+			state->port->ops->stop_tx(state->port, 0);
>+		}
>+		spin_unlock_irqrestore(&state->port->lock, flags);
>+	}
>+
> #if 0
> 	/*
> 	 * No need to wake up processes in open wait, since they
>-
>To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.35% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: [CFT:PATCH] 2/3: Check status of CTS when using flow control

[Russell King]

On Sun, Jun 26, 2005 at 06:26:43PM -0400, Gene Heskett wrote:
> On Sunday 26 June 2005 18:17, Russell King wrote:
> >Fix bugme #4712: read the CTS status and set hw_stopped if CTS
> >is not active.
> >
> >Thanks to Stefan Wolff for spotting this problem.
> >
> This one needs to make mainline & maybe, after 3 years, I can use a 
> pl2303 to talk to an old slow coco.  Twould be very nice if that 
> fixed the lack of flow controls the connection apparently fails from.

Sorry, wasn't aware of the problem until recently.  Reviewing the
code reveals that this bug has existed through many many many kernel
series. ;(

Have you been able to test it?  You will need the first patch as well.

(also, please remember I can't send you mail directly... still.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [CFT:PATCH] 2/3: Check status of CTS when using flow control

[Gene Heskett]

On Sunday 26 June 2005 18:37, Russell King wrote:
>On Sun, Jun 26, 2005 at 06:26:43PM -0400, Gene Heskett wrote:
>> On Sunday 26 June 2005 18:17, Russell King wrote:
>> >Fix bugme #4712: read the CTS status and set hw_stopped if CTS
>> >is not active.
>> >
>> >Thanks to Stefan Wolff for spotting this problem.
>>
>> This one needs to make mainline & maybe, after 3 years, I can use
>> a pl2303 to talk to an old slow coco.  Twould be very nice if that
>> fixed the lack of flow controls the connection apparently fails
>> from.
>
>Sorry, wasn't aware of the problem until recently.  Reviewing the
>code reveals that this bug has existed through many many many kernel
>series. ;(
>
Yes it has, and I may have even posted about it, but that would be a 
year plus back into ancient history Russell.  You mention another 
required patch also?  Where might it be obtained?

>Have you been able to test it?  You will need the first patch as
> well.
>
>(also, please remember I can't send you mail directly... still.)

I'm also getting bounces involving the address in the CC: line,
Russell King <rmk+lkml@arm.linux.org.uk>

While I can goto vz and add that address to the incoming whitelist, I 
doubt that would do you any good.  Looks like I need to bookmark that 
page and start using it more often.  Did I mention how bad vz sucks?  
Unforch, only game in this neck of the appalacians (hell I can't even 
spell it right), sorry.

Anyway, your domain name is now in the vz whitelist.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.35% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: [CFT:PATCH] 2/3: Check status of CTS when using flow control

[Russell King]

On Sun, Jun 26, 2005 at 07:38:18PM -0400, Gene Heskett wrote:
> On Sunday 26 June 2005 18:37, Russell King wrote:
> >On Sun, Jun 26, 2005 at 06:26:43PM -0400, Gene Heskett wrote:
> >> On Sunday 26 June 2005 18:17, Russell King wrote:
> >> >Fix bugme #4712: read the CTS status and set hw_stopped if CTS
> >> >is not active.
> >> >
> >> >Thanks to Stefan Wolff for spotting this problem.
> >>
> >> This one needs to make mainline & maybe, after 3 years, I can use
> >> a pl2303 to talk to an old slow coco.  Twould be very nice if that
> >> fixed the lack of flow controls the connection apparently fails
> >> from.
> >
> >Sorry, wasn't aware of the problem until recently.  Reviewing the
> >code reveals that this bug has existed through many many many kernel
> >series. ;(
> >
> Yes it has, and I may have even posted about it, but that would be a 
> year plus back into ancient history Russell.  You mention another 
> required patch also?  Where might it be obtained?

You replied to the second message in the thread (which contains the
second patch).  The first message contains the first patch.  lkml.org
has it archived if you need it.

> >(also, please remember I can't send you mail directly... still.)
> 
> I'm also getting bounces involving the address in the CC: line,
> Russell King <rmk+lkml@arm.linux.org.uk>
> 
> While I can goto vz and add that address to the incoming whitelist, I 
> doubt that would do you any good.  Looks like I need to bookmark that 
> page and start using it more often.  Did I mention how bad vz sucks?  
> Unforch, only game in this neck of the appalacians (hell I can't even 
> spell it right), sorry.
> 
> Anyway, your domain name is now in the vz whitelist.

And I now have 20 messages from verizon to postmaster / abuse requesting
that I go and fill in their "ISP" whitelist form... one to each would
have done, but 10 times as much?  That's definitely abuse in itself.

On this ISP whitelist form, Verizon require a phonenumber that they can
call anytime during some random timezone (CST, where ever that is.)
Being located in the UK, that's not acceptable so I'm unable to comply
with their requirements for whitelisting.  Sorry.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [CFT:PATCH] 2/3: Check status of CTS when using flow control

[Gene Heskett]

On Monday 27 June 2005 04:05, Russell King wrote:
>On Sun, Jun 26, 2005 at 07:38:18PM -0400, Gene Heskett wrote:
>> On Sunday 26 June 2005 18:37, Russell King wrote:
>> >On Sun, Jun 26, 2005 at 06:26:43PM -0400, Gene Heskett wrote:
>> >> On Sunday 26 June 2005 18:17, Russell King wrote:
>> >> >Fix bugme #4712: read the CTS status and set hw_stopped if CTS
>> >> >is not active.
>> >> >
>> >> >Thanks to Stefan Wolff for spotting this problem.
>> >>
>> >> This one needs to make mainline & maybe, after 3 years, I can
>> >> use a pl2303 to talk to an old slow coco.  Twould be very nice
>> >> if that fixed the lack of flow controls the connection
>> >> apparently fails from.
>> >
>> >Sorry, wasn't aware of the problem until recently.  Reviewing the
>> >code reveals that this bug has existed through many many many
>> > kernel series. ;(
>>
>> Yes it has, and I may have even posted about it, but that would be
>> a year plus back into ancient history Russell.  You mention
>> another required patch also?  Where might it be obtained?
>
>You replied to the second message in the thread (which contains the
>second patch).  The first message contains the first patch. 
> lkml.org has it archived if you need it.

Ok, found all 3 of them in this thread and saved them.  From my own 
kmail archive.  Thanks.  I'll merge them into one file and see if it 
will apply when I build the next of Ingo's RT bleeders.

>> >(also, please remember I can't send you mail directly... still.)
>>
>> I'm also getting bounces involving the address in the CC: line,
>> Russell King <rmk+lkml@arm.linux.org.uk>
>>
>> While I can goto vz and add that address to the incoming
>> whitelist, I doubt that would do you any good.  Looks like I need
>> to bookmark that page and start using it more often.  Did I
>> mention how bad vz sucks? Unforch, only game in this neck of the
>> appalacians (hell I can't even spell it right), sorry.
>>
>> Anyway, your domain name is now in the vz whitelist.
>
>And I now have 20 messages from verizon to postmaster / abuse
> requesting that I go and fill in their "ISP" whitelist form... one
> to each would have done, but 10 times as much?  That's definitely
> abuse in itself.

Amen to that!

>On this ISP whitelist form, Verizon require a phonenumber that they
> can call anytime during some random timezone (CST, where ever that
> is.) Being located in the UK, that's not acceptable so I'm unable
> to comply with their requirements for whitelisting.  Sorry.

That tz would be america-chicago in the tz list.  Since I'm a 
(captive) customer, I apparently don't have to go thru that BS. But 
that should be taken care of as I get the impression that my 
whitelisting you should be for *my* incoming.  Give it one more shot 
& see if it still makes a bounce message to you now.  I put your 
domain into the whitelist yesterday.  I also shut off vz's so called 
spam filter as SA seems to be catching far more than theirs ever did.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.35% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: [CFT:PATCH] 2/3: Check status of CTS when using flow control

[Russell King]

On Sun, Jun 26, 2005 at 11:17:50PM +0100, Russell King wrote:
> Fix bugme #4712: read the CTS status and set hw_stopped if CTS
> is not active.
> 
> Thanks to Stefan Wolff for spotting this problem.

Stefan Wolff pointed out that this wasn't quite correct.  Here's an
updated patch.

Index: drivers/serial/serial_core.c
===================================================================
--- 61f26f0bd348c6ddac8b3b1105e00fa790ea3ea6/drivers/serial/serial_core.c  (mode:100644)
+++ uncommitted/drivers/serial/serial_core.c  (mode:100644)
@@ -182,6 +182,13 @@
 				uart_set_mctrl(port, TIOCM_RTS | TIOCM_DTR);
 		}
 
+		if (info->flags & UIF_CTS_FLOW) {
+			spin_lock_irq(&port->lock);
+			if (!(port->ops->get_mctrl(port) & TIOCM_CTS))
+				info->tty->hw_stopped = 1;
+			spin_unlock_irq(&port->lock);
+		}
+
 		info->flags |= UIF_INITIALIZED;
 
 		clear_bit(TTY_IO_ERROR, &info->tty->flags);
@@ -1134,6 +1141,16 @@
 		spin_unlock_irqrestore(&state->port->lock, flags);
 	}
 
+	/* Handle turning on CRTSCTS */
+	if (!(old_termios->c_cflag & CRTSCTS) && (cflag & CRTSCTS)) {
+		spin_lock_irqsave(&state->port->lock, flags);
+		if (!(state->port->ops->get_mctrl(state->port) & TIOCM_CTS)) {
+			tty->hw_stopped = 1;
+			state->port->ops->stop_tx(state->port, 0);
+		}
+		spin_unlock_irqrestore(&state->port->lock, flags);
+	}
+
 #if 0
 	/*
 	 * No need to wake up processes in open wait, since they


-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core