gmane.linux.serial

ACCOUNT UPDRADING TEAM

ACCOUNT UPDRADING TEAM — 2008-08-28T10:08:44

ACCOUNT UPDRADING TEAM To complete your Account Verification process, you are to reply this message and enter your password in the space provided (*******), you are required to do this before the next 48hrs of receipt of this e-mail, or your Webmail Account will be de-activated and erased from our database. Your account can also be verified at: Thank you for using our Webmail Service. -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Patch: Correct Sierra Wireless USB EVDO Modem Device ID

Tony Murray — 2008-08-22T22:30:44

I was trying to figure out why my device wasn't supported by the drivers/usb/serial/sierra.c driver, while looking throught the device IDs I spotted what I believe to be a typo in the device IDs. Please apply the following patch: --- drivers/usb/serial/sierra.c.orig 2008-08-22 16:55:00.000000000 -0500 +++ drivers/usb/serial/sierra.c 2008-08-22 17:08:55.000000000 -0500 < at >< at > -185,7 +185,7 < at >< at > { USB_DEVICE(0x1199, 0x0017) }, /* Sierra Wireless EM5625 */ { USB_DEVICE(0x1199, 0x0018) }, /* Sierra Wireless MC5720 */ { USB_DEVICE(0x1199, 0x0218) }, /* Sierra Wireless MC5720 */ - { USB_DEVICE(0x0f30, 0x1b1d) }, /* Sierra Wireless MC5720 */ + { USB_DEVICE(0x03f0, 0x1b1d) }, /* HP ev2200 a.k.a MC5720 */ { USB_DEVICE(0x1199, 0x0020) }, /* Sierra Wireless MC5725 */ { USB_DEVICE(0x1199, 0x0220) }, /* Sierra Wireless MC5725 */ { USB_DEVICE(0x1199, 0x0019) }, /* Sierra Wireless AirCard 595 */ If you look down further, there is another HP wireless broadband card, which has a vendor ID of 03f0, like my device. Below is my "lsusb -v -d 03f0:1b1d". Bus 001 Device 005: ID 03f0:1b1d Hewlett-Packard Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x03f0 Hewlett-Packard idProduct 0x1b1d bcdDevice 0.01 iManufacturer 1 HP iProduct 2 HP ev2200 1xEV-DO Broadband Wireless Module iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 67 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 7 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 3 Data Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 128 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0000 (Bus Powered) Tony Murray PS: Sorry about the multi-list spam, but I was unsure exactly to send this. -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH] serial: imx: add console polling routines for kgdboc

Atsuo Igarashi — 2008-08-13T08:27:39

Add console polling routines for the imx uart with kgdboc. Signed-off-by Atsuo Igarashi tripeaks.co.jp>

8250 misses interrupt, stalls

Jeff DeFouw — 2008-08-08T05:27:27

I have a Celeron ETX processor module with a Winbond W83627HF SuperIO chip, providing two 16550A compatible UARTs, which connects over LPC to an 82801DB south bridge. I'm only using the first serial port at the moment. The modules 8250 and 8250_pnp are loaded, and the serial port is on standard resources (irq 4). After one of my complex applications at work runs for a few minutes, the serial port suddenly stops. The UART IIR indicates an interrupt is pending, and the LSR indicates data is waiting to be received (as well as sent), but the interrupt handler is not being called. If while it's stuck I reset the enabled interrupts (save IER, clear IER, restore IER) the I/O resumes. I don't see anything wrong with the way the UART is being serviced. The kernel is patched to 2.6.25.11, configured by Debian as SMP, no PREEMPT, shared IRQ (nothing else is on irq 4) and without any external modules loaded. It's a Celeron without any HT or multiple cores, so it's uniprocessor. I haven't been able to make a simple test case. The real program is kind of a loopback that's continuously receiving and sending data at 115200 8N1 with no flow control. The full data rate isn't being used, and I'm not getting any overruns (until it stalls). A simple loopback program doesn't demonstrate the problem, but the real application runs into it every time within 10 minutes (usually under 5).

Faster read response / Improved low latency in RS-485 communication

Andreas Helmcke — 2008-08-07T12:49:20

I am at the point of connecting a multidrop RS485 bus to a linux system and ran into two problems. Since the first problem (RS-485 direction control) is currently discussed and will result hopefully in an kernel patch, which will avoid some nasty non standard hacking in the future, I would like to bring the second problem back into attention, which has been described very well by Michael Kohne back in 2003: On 18.11.2003 16:28, Michael Kohne wrote: Full Post including his proposed patch: http://osdir.com/ml/serial/2004-04/msg00001.html The very same problem (only shorter timeouts and faster baudrate) we have with our RS485 bus. Quick and dirty patch to solve this problem when using 16C950 UARTS by setting the 950 trigger level registers: --- /src/linux-2.6.18.i686/drivers/serial/8250.c2008-07-14 14:48:56.000000000 +0200 +++ ./8250.c2008-07-25 09:00:39.000000000 +0200 < at >< at > -2073,6 +2073,19 < at >< at > } serial_outp(up, UART_FCR, fcr);/* set fcr */ } + +/* + * 16C950: if LOW_LATENCY flag is set, set trigger levels to 1 + */ +if (up->port.type == PORT_16C950) { +if (up->port.flags & UPF_LOW_LATENCY) { +up->acr |= UART_ACR_TLENB; +serial_icr_write(up, UART_ACR, up->acr); +serial_icr_write(up, UART_RTL, 1); +serial_icr_write(up, UART_TTL, 1); +} +} + serial8250_set_mctrl(&up->port, up->port.mctrl); spin_unlock_irqrestore(&up->port.lock, flags); } Any comments are very welcome. Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH v1] 8250: add support for DTR/DSR hardware flow control

Aristeu Rozanski — 2008-08-06T21:14:38

This patch adds support for DTR/DSR hardware flow control on 8250 driver on x86 machines. It's done by adding a CDTRDSR flag to work just like CRTSCTS, which is not done on other architectures on purpose (so each maintainer can allocate it). This patch was tested with success with a serial printer configured with a small buffer and DTR/DSR flow control. This is based on the work of Michael Westermann (http://lkml.org/lkml/2007/8/31/133) Comments more than welcome. Signed-off-by: Aristeu Rozanski redhat.com> --- drivers/serial/8250.c | 12 ++++++++-- drivers/serial/serial_core.c | 42 ++++++++++++++++++++++++++++++++++- include/asm-x86/termbits.h | 1 include/linux/serial_core.h | 51 +++++++++++++++++++++++++++---------------- include/linux/termios.h | 5 ++++ 5 files changed, 90 insertions(+), 21 deletions(-) --- linus-2.6.orig/drivers/serial/8250.c2008-08-05 16:44:26.000000000 -0400 +++ linus-2.6/drivers/serial/8250.c2008-08-05 18:45:01.000000000 -0400 < at >< at > -1409,7 +1409,7 < at >< at > static unsigned int check_modem_status(s if (status & UART_MSR_TERI) up->port.icount.rng++; if (status & UART_MSR_DDSR) -up->port.icount.dsr++; +uart_handle_dsr_change(&up->port, status & UART_MSR_DSR); if (status & UART_MSR_DDCD) uart_handle_dcd_change(&up->port, status & UART_MSR_DCD); if (status & UART_MSR_DCTS) < at >< at > -1739,9 +1739,17 < at >< at > static inline void wait_for_xmitr(struct unsigned int tmout; for (tmout = 1000000; tmout; tmout--) { unsigned int msr = serial_in(up, UART_MSR); +struct uart_info *info = up->port.info; + up->msr_saved_flags |= msr & MSR_SAVE_FLAGS; -if (msr & UART_MSR_CTS) + +if ((info->flags & UIF_CTS_FLOW) && + (msr & UART_MSR_CTS)) break; +else if ((info->flags & UIF_DSR_FLOW) && + (msr & UART_MSR_DSR)) + break; + udelay(1); touch_nmi_watchdog(); } --- linus-2.6.orig/drivers/serial/serial_core.c2008-08-05 16:44:26.000000000 -0400 +++ linus-2.6/drivers/serial/serial_core.c2008-08-05 18:45:01.000000000 -0400 < at >< at > -194,6 +194,13 < at >< at > static int uart_startup(struct uart_stat spin_unlock_irq(&port->lock); } +if (info->flags & UIF_DSR_FLOW) { +spin_lock_irq(&port->lock); +if (!(port->ops->get_mctrl(port) & TIOCM_DSR)) +info->port.tty->hw_stopped = 1; +spin_unlock_irq(&port->lock); +} + info->flags |= UIF_INITIALIZED; clear_bit(TTY_IO_ERROR, &info->port.tty->flags); < at >< at > -448,6 +455,11 < at >< at > uart_change_speed(struct uart_state *sta else state->info->flags &= ~UIF_CTS_FLOW; +if (termios->c_cflag & CDTRDSR) +state->info->flags |= UIF_DSR_FLOW; +else +state->info->flags &= ~UIF_DSR_FLOW; + if (termios->c_cflag & CLOCAL) state->info->flags &= ~UIF_CHECK_CD; else < at >< at > -611,6 +623,8 < at >< at > static void uart_throttle(struct tty_str if (tty->termios->c_cflag & CRTSCTS) uart_clear_mctrl(state->port, TIOCM_RTS); +if (tty->termios->c_cflag & CDTRDSR) +uart_clear_mctrl(state->port, TIOCM_DTR); } static void uart_unthrottle(struct tty_struct *tty) < at >< at > -627,6 +641,8 < at >< at > static void uart_unthrottle(struct tty_s if (tty->termios->c_cflag & CRTSCTS) uart_set_mctrl(port, TIOCM_RTS); +if (tty->termios->c_cflag & CDTRDSR) +uart_set_mctrl(port, TIOCM_DTR); } static int uart_get_info(struct uart_state *state, < at >< at > -1212,6 +1228,9 < at >< at > static void uart_set_termios(struct tty_ if (!(cflag & CRTSCTS) || !test_bit(TTY_THROTTLED, &tty->flags)) mask |= TIOCM_RTS; +if (!(cflag & CDTRDSR) || + !test_bit(TTY_THROTTLED, &tty->flags)) +mask &= ~TIOCM_DTR; uart_set_mctrl(state->port, mask); } < at >< at > -1232,6 +1251,24 < at >< at > static void uart_set_termios(struct tty_ } spin_unlock_irqrestore(&state->port->lock, flags); } + +/* Handle turning off CDTRDSR */ +if ((old_termios->c_cflag & CDTRDSR) && !(cflag & CDTRDSR)) { +spin_lock_irqsave(&state->port->lock, flags); +tty->hw_stopped = 0; +__uart_start(tty); +spin_unlock_irqrestore(&state->port->lock, flags); +} + +if (!(old_termios->c_cflag & CDTRDSR) && (cflag & CDTRDSR)) { +spin_lock_irqsave(&state->port->lock, flags); +if (!(state->port->ops->get_mctrl(state->port) & TIOCM_DSR)) { +tty->hw_stopped = 1; +state->port->ops->stop_tx(state->port); +} +spin_unlock_irqrestore(&state->port->lock, flags); +} + #if 0 /* * No need to wake up processes in open wait, since they < at >< at > -1511,7 +1548,8 < at >< at > uart_block_til_ready(struct file *filp, * not set RTS here - we want to make sure we catch * the data from the modem. */ -if (info->port.tty->termios->c_cflag & CBAUD) +if (info->port.tty->termios->c_cflag & CBAUD && + !(info->port.tty->termios->c_cflag & CDTRDSR)) uart_set_mctrl(port, TIOCM_DTR); /* < at >< at > -1959,6 +1997,8 < at >< at > uart_set_options(struct uart_port *port, if (flow == 'r') termios.c_cflag |= CRTSCTS; +if (flow == 'd') +termios.c_cflag |= CDTRDSR; /* * some uarts on other side don't support no flow control. --- linus-2.6.orig/include/asm-x86/termbits.h2008-08-05 16:44:26.000000000 -0400 +++ linus-2.6/include/asm-x86/termbits.h2008-08-06 13:33:57.000000000 -0400 < at >< at > -157,6 +157,7 < at >< at > struct ktermios { #define B3500000 0010016 #define B4000000 0010017 #define CIBAUD 002003600000/* input baud rate */ +#define CDTRDSR 004000000000/* DTR/DSR flow control */ #define CMSPAR 010000000000/* mark or space (stick) parity */ #define CRTSCTS 020000000000/* flow control */ --- linus-2.6.orig/include/linux/serial_core.h2008-08-05 16:44:26.000000000 -0400 +++ linus-2.6/include/linux/serial_core.h2008-08-05 18:45:01.000000000 -0400 < at >< at > -351,6 +351,7 < at >< at > struct uart_info { * * FIXME: use the ASY_ definitions */ +#define UIF_DSR_FLOW((__force uif_t) (1 << 24)) #define UIF_CHECK_CD((__force uif_t) (1 << 25)) #define UIF_CTS_FLOW((__force uif_t) (1 << 26)) #define UIF_NORMAL_ACTIVE((__force uif_t) (1 << 29)) < at >< at > -505,34 +506,48 < at >< at > uart_handle_dcd_change(struct uart_port } /** - *uart_handle_cts_change - handle a change of clear-to-send state + *uart_handle_flow_control_change - handle a change of CTS or DSR *< at >port: uart_port structure for the open port - *< at >status: new clear to send status, nonzero if active + *< at >status: new CTS/DTR status, nonzero if active */ static inline void -uart_handle_cts_change(struct uart_port *port, unsigned int status) +uart_handle_flow_control_change(struct uart_port *port, unsigned int status) { struct uart_info *info = port->info; struct tty_struct *tty = info->port.tty; -port->icount.cts++; - -if (info->flags & UIF_CTS_FLOW) { -if (tty->hw_stopped) { -if (status) { -tty->hw_stopped = 0; -port->ops->start_tx(port); -uart_write_wakeup(port); -} -} else { -if (!status) { -tty->hw_stopped = 1; -port->ops->stop_tx(port); -} +if (tty->hw_stopped) { +if (status) { +tty->hw_stopped = 0; +port->ops->start_tx(port); +uart_write_wakeup(port); +} +} else { +if (!status) { +tty->hw_stopped = 1; +port->ops->stop_tx(port); } } } +static inline void +uart_handle_cts_change(struct uart_port *port, unsigned int status) +{ +struct uart_info *info = port->info; +port->icount.cts++; +if (info->flags & UIF_CTS_FLOW) +uart_handle_flow_control_change(port, status); +} + +static inline void +uart_handle_dsr_change(struct uart_port *port, unsigned int status) +{ +struct uart_info *info = port->info; +port->icount.dsr++; +if (info->flags & UIF_DSR_FLOW) +uart_handle_flow_control_change(port, status); +} + #include static inline void < at >< at > -556,7 +571,7 < at >< at > uart_insert_char(struct uart_port *port, *UART_ENABLE_MS - determine if port should enable modem status irqs */ #define UART_ENABLE_MS(port,cflag)((port)->flags & UPF_HARDPPS_CD || \ - (cflag) & CRTSCTS || \ + (cflag) & (CRTSCTS | CDTRDSR) || \ !((cflag) & CLOCAL)) #endif --- linus-2.6.orig/include/linux/termios.h2008-08-05 16:44:26.000000000 -0400 +++ linus-2.6/include/linux/termios.h2008-08-05 18:45:01.000000000 -0400 < at >< at > -4,4 +4,9 < at >< at > #include #include +#ifndef CDTRDSR +#warning This architecture should implement CDTRDSR +#define CDTRDSR 0 /* remove this when all architectures have a definition */ +#endif + #endif -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Interface for setting half-duplex transmitter mode

Sergey Lapin — 2008-08-06T19:25:19

Hi, all! Is there any interface API for userspace, which I could use to set RS-485 mode on UART (which suports it via hardware, by setting 1 bit in configuration), which means half-duplex mode with RTS line toggling. Now I have it hard-coded for appropriate UART, and seen patch which sets this from platform data, but is there some API to do it dynamically? I know I could implement this by ioctl mechanism, but I need some non-standard ioctl number for that. Is there some sane way to accomplish my goals? I mean one which be accepted to mainline? Thanks a lot, S. -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

BUG: parport_serial in 2.6.27-rc1 for NetMos Technology PCI 9835

Jaswinder Singh — 2008-08-05T15:00:10

/dev/ttyS1 and /dev/ttyS2 of NetMos Technology PCI 9835 is giving Junk characters in minicom but /dev/tyS0 is working perfectly. 01:01.0 Communication controller: NetMos Technology PCI 9835 Multi-I/O Controller (rev 01) Subsystem: LSI Logic / Symbios Logic 1P2S Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- jaswinder 0000:01:01.0]$ setserial /dev/ttyS0 -a /dev/ttyS0, Line 0, UART: 16550A, Port: 0x03f8, IRQ: 4 Baud_base: 115200, close_delay: 50, divisor: 0 closing_wait: 3000 Flags: spd_normal skip_test [jsr< at >jaswinder 0000:01:01.0]$ setserial /dev/ttyS1 -a /dev/ttyS1, Line 1, UART: 16550A, Port: 0xdc00, IRQ: 22 Baud_base: 115200, close_delay: 50, divisor: 0 closing_wait: 3000 Flags: spd_normal skip_test [jsr< at >jaswinder 0000:01:01.0]$ setserial /dev/ttyS2 -a /dev/ttyS2, Line 2, UART: 16550A, Port: 0xd480, IRQ: 22 Baud_base: 115200, close_delay: 50, divisor: 0 closing_wait: 3000 Flags: spd_normal skip_test [jsr< at >jaswinder 0000:01:01.0]$ setserial /dev/ttyS3 -a /dev/ttyS3, Line 3, UART: unknown, Port: 0x02e8, IRQ: 3 Baud_base: 115200, close_delay: 50, divisor: 0 closing_wait: 3000 Flags: spd_normal auto_irq from dmesg : Serial: 8250/16550 driver4 ports, IRQ sharing enabled Switched to high resolution mode on CPU 0 serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A 00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A parport_pc 00:09: reported by Plug and Play ACPI parport0: PC-style at 0x378, irq 7 [PCSPP(,...)] parport_serial 0000:01:01.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 parport1: PC-style at 0xd400 [PCSPP(,...)] 0000:01:01.0: ttyS1 at I/O 0xdc00 (irq = 22) is a 16550A 0000:01:01.0: ttyS2 at I/O 0xd480 (irq = 22) is a 16550A Thank you, Jaswinder Singh. -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH] 8250: Remove a few inlines of dubious value.

Will Newton — 2008-08-05T14:13:55

This patch removes some inlines from various functions that are called once, are too big to inline, or are called only from slow path code. This saves around 300 bytes of code for me. Signed-off-by: Will Newton gmail.com> --- drivers/serial/8250.c | 9 ++++----- 1 files changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c index 342e12f..153e3c1 100644 --- a/drivers/serial/8250.c +++ b/drivers/serial/8250.c < at >< at > -536,7 +536,7 < at >< at > static unsigned int serial_icr_read(struct uart_8250_port *up, int offset) /* * FIFO support. */ -static inline void serial8250_clear_fifos(struct uart_8250_port *p) +static void serial8250_clear_fifos(struct uart_8250_port *p) { if (p->capabilities & UART_CAP_FIFO) { serial_outp(p, UART_FCR, UART_FCR_ENABLE_FIFO); < at >< at > -551,7 +551,7 < at >< at > static inline void serial8250_clear_fifos(struct uart_8250_port *p) * capability" bit enabled. Note that on XR16C850s, we need to * reset LCR to write to IER. */ -static inline void serial8250_set_sleep(struct uart_8250_port *p, int sleep) +static void serial8250_set_sleep(struct uart_8250_port *p, int sleep) { if (p->capabilities & UART_CAP_SLEEP) { if (p->capabilities & UART_CAP_EFR) { < at >< at > -1424,8 +1424,7 < at >< at > static unsigned int check_modem_status(struct uart_8250_port *up) /* * This handles the interrupt from one port. */ -static inline void -serial8250_handle_port(struct uart_8250_port *up) +static void serial8250_handle_port(struct uart_8250_port *up) { unsigned int status; unsigned long flags; < at >< at > -1719,7 +1718,7 < at >< at > static void serial8250_break_ctl(struct uart_port *port, int break_state) /* *Wait for transmitter & holding register to empty */ -static inline void wait_for_xmitr(struct uart_8250_port *up, int bits) +static void wait_for_xmitr(struct uart_8250_port *up, int bits) { unsigned int status, tmout = 10000;

[RFC] suggested fix for 83xx/85xx PowerPC UART break bug

Paul Gortmaker — 2008-07-31T15:26:30

This is something I'd tripped over earlier, and wanted to follow up on to get an acceptable fix in for everyone's benefit before it falls through the cracks again. There seems to be an issue with recent 83xx/85xx SOC UARTs, in which a break triggers a short lived IRQ storm (hence killing any hope of using SysRQ). The only fix I found to work was to just ignore the bogus events that had the associated signature bit set. This fix is what I was using against earlier kernels, but I hate to add more board/arch specific ifdefs to files like 8250.c, so I'm wondering if anyone has any other suggestions before I simply end up cleaning up the boardlist (now ppc is dead) and respinning the patch much as it is now and resending. Thanks, Paul. ----------------- Variation/update of version1 of the patch -- orig. discussion at: http://patchwork.ozlabs.org/linuxppc/patch?id=15986 Update is: Don't use MPC8540 as a selector for the 8548 boards, since testing on a genuine (older) MPC8540ADS board shows that it doesn't have the issue. This will get coverage on the sbc8349, fsl_mpc8349_mitx, fsl_mpc832xe (and the similar 8323RDB) and the sbc8548 and the fsl_8548cds. (i.e all the boards where the problem has been demonstrated to exist so far.) Signed-off-by: Paul Gortmaker windriver.com> --- drivers/serial/8250.c | 17 +++++++++++++++++ include/linux/serial_reg.h | 1 + 2 files changed, 18 insertions(+) --- a/drivers/serial/8250.c +++ b/drivers/serial/8250.c < at >< at > -1347,6 +1347,25 < at >< at > serial8250_handle_port(struct uart_8250_ status = serial_inp(up, UART_LSR); +#if defined(CONFIG_MPC834x) || defined(CONFIG_MPC85xx_CDS) || \ +defined(CONFIG_SBC8548) || defined (CONFIG_PPC_MPC832x) +/* + * There appears to be a quirk in the implementation on some 8xxx + * where after a break is rec'd (UART_LSR_BI), the UART generates + * a short duration burst of bogus IRQ events with the signature + * of RFE set (along with "normal" bits set) in the LSR. + */ + +#define RFE_8xxx_ERR_BITS (UART_LSR_RFE| UART_LSR_TEMT| \ +UART_LSR_THRE| UART_LSR_BI| \ +UART_LSR_DR) + +if (status == RFE_8xxx_ERR_BITS) { +spin_unlock(&up->port.lock); +return; +} +#endif + DEBUG_INTR("status = %x...", status); if (status & UART_LSR_DR) { --- a/include/linux/serial_reg.h +++ b/include/linux/serial_reg.h < at >< at > -109,6 +109,7 < at >< at > #define UART_MCR_DTR0x01 /* DTR complement */ #define UART_LSR5/* In: Line Status Register */ +#define UART_LSR_RFE0x80 /* Rx FIFO Error (BE, FE, or PE) */ #define UART_LSR_TEMT0x40 /* Transmitter empty */ #define UART_LSR_THRE0x20 /* Transmit-hold-register empty */ #define UART_LSR_BI0x10 /* Break interrupt indicator */ -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

function read() isn't quick enough for reading in ttyS*

Federico Tula Rovaletti — 2008-07-31T06:17:21

Hi all! I'm a novice in Linux In a program I'm writing in c and, when I use the read() function for reading a byte in the port serial with a configuration: 115200 bps, 8N2 takes from 2ms to 6ms (aleatory, even if a read up to 10 bytes takes the same time), which is too long. (ioctl(fd, FIONREAD, &bytes) last the same) This is the time is suppose to last: 8 bits: data 2 bits: stop 1 bit: start time = ((8+2+1)bits/115200bps) = 0.095ms, then when I read the byte with the function inb_p() takes ~ 0.1ms which is perfect, what I'm needing for my project. The problem I'm having is that I use signals (with fcntl(fd, F_SETFL, O_ASYNC) ) but this signals last the same time in occur that the read() (unacceptable) so I guess that this is a problem of the driver that is to slow. So the question is, is there any way to improve the performance of the driver or using read? (doing inb_p is very nasty). Do I'm doing something wrong? Thanks in advance!, I expect as soon as possible any answer PD: sorry for my English, -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[RFC] [PATCH 1/7] pcmcia: add pcmcia_loop_config() helper

Dominik Brodowski — 2008-07-29T07:15:39

By calling pcmcia_loop_config(), a pcmcia driver can iterate over all available configuration options. During a driver's probe() phase, one doesn't need to use pcmcia_get_{first,next}_tuple, pcmcia_get_tuple_data and pcmcia_parse_tuple directly in most if not all cases. Signed-off-by: Dominik Brodowski dominikbrodowski.net> --- Documentation/pcmcia/driver-changes.txt | 6 +++ drivers/pcmcia/pcmcia_resource.c | 57 +++++++++++++++++++++++++++++++ include/pcmcia/cistpl.h | 6 +++ 3 files changed, 69 insertions(+), 0 deletions(-) By calling pcmcia_loop_config(), a pcmcia driver can iterate over all available configuration options. During a driver's probe() phase, one doesn't need to use pcmcia_get_{first,next}_tuple, pcmcia_get_tuple_data and pcmcia_parse_tuple directly in most if not all cases. Signed-off-by: Dominik Brodowski dominikbrodowski.net> --- Documentation/pcmcia/driver-changes.txt | 6 +++ drivers/pcmcia/pcmcia_resource.c | 63 +++++++++++++++++++++++++++++++ include/pcmcia/cistpl.h | 6 +++ 3 files changed, 75 insertions(+), 0 deletions(-) diff --git a/Documentation/pcmcia/driver-changes.txt b/Documentation/pcmcia/driver-changes.txt index 96f155e..44085c1 100644 --- a/Documentation/pcmcia/driver-changes.txt +++ b/Documentation/pcmcia/driver-changes.txt < at >< at > -1,5 +1,11 < at >< at > This file details changes in 2.6 which affect PCMCIA card driver authors: +* New configuration loop helper (as of 2.6.28) + By calling pcmcia_loop_config(), a driver can iterate over all available + configuration options. During a driver's probe() phase, one doesn't need + to use pcmcia_get_{first,next}_tuple, pcmcia_get_tuple_data and + pcmcia_parse_tuple directly in most if not all cases. + * New release helper (as of 2.6.17) Instead of calling pcmcia_release_{configuration,io,irq,win}, all that's necessary now is calling pcmcia_disable_device. As there is no valid diff --git a/drivers/pcmcia/pcmcia_resource.c b/drivers/pcmcia/pcmcia_resource.c index 4884a18..0fa48aa 100644 --- a/drivers/pcmcia/pcmcia_resource.c +++ b/drivers/pcmcia/pcmcia_resource.c < at >< at > -909,3 +909,66 < at >< at > void pcmcia_disable_device(struct pcmcia_device *p_dev) { pcmcia_release_window(p_dev->win); } EXPORT_SYMBOL(pcmcia_disable_device); + + +/** + * pcmcia_loop_config() - loop over configuration options + * < at >p_dev:the struct pcmcia_device which we need to loop for. + * < at >conf_check:function to call for each configuration option. + *It gets passed the struct pcmcia_device, the CIS data + *describing the configuration option, and private data + *being passed to pcmcia_loop_config() + * < at >priv_data:private data to be passed to the conf_check function. + * + * pcmcia_loop_config() loops over all configuration options, and calls + * the driver-specific conf_check() for each one, checking whether + * it is a valid one. + */ + +struct pcmcia_cfg_mem { +tuple_t tuple; +cisparse_t parse; +u8 buf[256]; +}; + +int pcmcia_loop_config(struct pcmcia_device *p_dev, + int(*conf_check)(struct pcmcia_device *p_dev, + cistpl_cftable_entry_t *cfg, + void *priv_data), + void *priv_data) +{ +struct pcmcia_cfg_mem *cfg_mem; +tuple_t *tuple; +int ret = -ENODEV; + +cfg_mem = kzalloc(sizeof(struct pcmcia_cfg_mem), GFP_KERNEL); +if (cfg_mem == NULL) +return -ENOMEM; + +tuple = &cfg_mem->tuple; +tuple->TupleData = cfg_mem->buf; +tuple->TupleDataMax = 255; +tuple->TupleOffset = 0; +tuple->DesiredTuple = CISTPL_CFTABLE_ENTRY; +tuple->Attributes = 0; + +ret = pcmcia_get_first_tuple(p_dev, tuple); +while (!ret) { +if (pcmcia_get_tuple_data(p_dev, tuple)) +goto next_entry; + +if (pcmcia_parse_tuple(p_dev, tuple, &cfg_mem->parse)) +goto next_entry; + +ret = conf_check(p_dev, &cfg_mem->parse.cftable_entry, + priv_data); +if (!ret) +break; + +next_entry: +ret = pcmcia_get_next_tuple(p_dev, tuple); +} + +return ret; +} +EXPORT_SYMBOL(pcmcia_loop_config); diff --git a/include/pcmcia/cistpl.h b/include/pcmcia/cistpl.h index 552a332..9830b34 100644 --- a/include/pcmcia/cistpl.h +++ b/include/pcmcia/cistpl.h < at >< at > -607,4 +607,10 < at >< at > int pccard_validate_cis(struct pcmcia_socket *s, unsigned int function, unsigned #define pcmcia_validate_cis(p_dev, info) \ pccard_validate_cis(p_dev->socket, p_dev->func, info) +int pcmcia_loop_config(struct pcmcia_device *p_dev, + int(*conf_check)(struct pcmcia_device *p_dev, + cistpl_cftable_entry_t *cf, + void *priv_data), + void *priv_data); + #endif /* LINUX_CISTPL_H */

[PATCH] 8250: Add PowerPC-style MMIO support to the 8250 driver

Laurent Pinchart — 2008-07-24T12:11:15

This patch adds support for memory-mapped 8250-like UARTs on PowerPC platforms. Signed-off-by: Laurent Pinchart cse-semaphore.com> --- drivers/serial/8250.c | 10 ++++++++++ include/linux/serial_core.h | 1 + 2 files changed, 11 insertions(+), 0 deletions(-) diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c index be95e55..5e0e382 100644 --- a/drivers/serial/8250.c +++ b/drivers/serial/8250.c < at >< at > -380,6 +380,10 < at >< at > static unsigned int serial_in(struct uart_8250_port *up, int offset) } else return readb(up->port.membase + offset); +#ifdef CONFIG_PPC +case UPIO_PPC_MMIO: +return in_8(up->port.membase + offset); +#endif default: return inb(up->port.iobase + offset); } < at >< at > -429,6 +433,12 < at >< at > serial_out(struct uart_8250_port *up, int offset, int value) value = serial_in(up, UART_IER); break; +#ifdef CONFIG_PPC +case UPIO_PPC_MMIO: +out_8(up->port.membase + offset, value); +break; +#endif + default: outb(value, up->port.iobase + offset); } diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h index d8f31de..1d8b940 100644 --- a/include/linux/serial_core.h +++ b/include/linux/serial_core.h < at >< at > -261,6 +261,7 < at >< at > struct uart_port { #define UPIO_TSI(5)/* Tsi108/109 type IO */ #define UPIO_DWAPB(6)/* DesignWare APB UART */ #define UPIO_RM9000(7)/* RM9000 type IO */ +#define UPIO_PPC_MMIO(8)/* PowerPC-style MMIO */ unsigned intread_status_mask;/* driver specific */ unsigned intignore_status_mask;/* driver specific */

[PATCH/RFC] 8250: Auto RS485 direction control

Laurent Pinchart — 2008-07-24T11:47:29

This patch adds support for the automatic RS485 direction control feature present in 16850 UARTs. A new termios c_cflag, CARTS, is introduced to configure automatic direction control from userspace. This is a first proposal. I'm open to suggestions regarding the CARTS name. I assume the CARTS flag will have to be added to all asm/termbits.h headers. Why are the termios bits definitions platform specific ? --- drivers/serial/8250.c | 14 ++++++++++++++ include/asm-powerpc/termbits.h | 1 + include/linux/serial_reg.h | 1 + 3 files changed, 16 insertions(+), 0 deletions(-) diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c index 62a2e49..a1351d5 100644 --- a/drivers/serial/8250.c +++ b/drivers/serial/8250.c < at >< at > -2071,6 +2071,20 < at >< at > serial8250_set_termios(struct uart_port *port, struct ktermios *termios, if (up->port.type == PORT_16750) serial_outp(up, UART_FCR, fcr); +#ifdef CARTS +/* Auto RS485 Direction Control on 16850 UARTs */ +if (up->port.type == PORT_16850) { +unsigned char fctr; + +serial_outp(up, UART_LCR, 0xbf); +fctr = serial_inp(up, UART_FCTR) & ~UART_FCTR_RS485; +if (termios->c_cflag & CARTS) +fctr |= UART_FCTR_RS485; +serial_outp(up, UART_FCTR, fctr); +serial_outp(up, UART_LCR, 0); +} +#endif + serial_outp(up, UART_LCR, cval);/* reset DLAB */ up->lcr = cval;/* Save LCR */ if (up->port.type != PORT_16750) { diff --git a/include/asm-powerpc/termbits.h b/include/asm-powerpc/termbits.h index 5e79198..7b7ee27 100644 --- a/include/asm-powerpc/termbits.h +++ b/include/asm-powerpc/termbits.h < at >< at > -166,6 +166,7 < at >< at > struct ktermios { #define HUPCL00040000 #define CLOCAL00100000 +#define CARTS 004000000000/* auto RTS control */ #define CMSPAR 010000000000/* mark or space (stick) parity */ #define CRTSCTS 020000000000/* flow control */ diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h index 3c8a6aa..3db78cc 100644 --- a/include/linux/serial_reg.h +++ b/include/linux/serial_reg.h < at >< at > -188,6 +188,7 < at >< at > #define UART_FCTR_RTS_8DELAY0x03 #define UART_FCTR_IRDA0x04 /* IrDa data encode select */ #define UART_FCTR_TX_INT0x08 /* Tx interrupt type select */ +#define UART_FCTR_RS4850x08 /* Auto RS485 direction control */ #define UART_FCTR_TRGA0x00 /* Tx/Rx 550 trigger table select */ #define UART_FCTR_TRGB0x10 /* Tx/Rx 650 trigger table select */ #define UART_FCTR_TRGC0x20 /* Tx/Rx 654 trigger table select */

[PATCH] Fix oops in the 8250 serial driver when accessing a removed device

Laurent Pinchart — 2008-07-22T15:37:05

The 8250 serial driver allocates dummy devices for ISA serial ports and lets userspace applications open them even when they are not present. That hack is required by setserial to set the ISA serial ports I/O address. When a plug-and-play 8250 device is detected, the driver reuses one of the dummy ports. If that device is later removed, the port goes pack to the dummy ports pool. The capabilities field is not reset, which causes a oops when trying to access the port. This patch resets the capabilities field when a 8250 device is unregistered. Signed-off-by: Laurent Pinchart cse-semaphore.com> --- drivers/serial/8250.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c index ef158c1..40eb91f 100644 --- a/drivers/serial/8250.c +++ b/drivers/serial/8250.c < at >< at > -2886,6 +2886,7 < at >< at > void serial8250_unregister_port(int line) uart->port.flags &= ~UPF_BOOT_AUTOCONF; uart->port.type = PORT_UNKNOWN; uart->port.dev = &serial8250_isa_devs->dev; +uart->capabilities = 0; uart_add_one_port(&serial8250_reg, &uart->port); } else { uart->port.dev = NULL;

[PATCH] serial: mpsc: release port lock on call totty_flip_buffer_push

Dale Farnsworth — 2008-07-22T00:03:31

We need to release the port lock when we call tty_flip_buffer_push() to avoid a deadlock when the serial-core routines try to acquire the same lock. This deadlock has been observed on CONFIG_PREEMPT_RT configurations. Signed-off-by: Dale Farnsworth farnsworth.org> Cc: mvista.com> --- drivers/serial/mpsc.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/serial/mpsc.c b/drivers/serial/mpsc.c index c9f53e7..158d748 100644 --- a/drivers/serial/mpsc.c +++ b/drivers/serial/mpsc.c < at >< at > -1065,7 +1065,9 < at >< at > next_frame: if ((readl(pi->sdma_base + SDMA_SDCM) & SDMA_SDCM_ERD) == 0) mpsc_start_rx(pi); +spin_unlock(&pi->port.lock); tty_flip_buffer_push(tty); +spin_lock(&pi->port.lock); return rc; }

Line disciplines.

ian — 2008-07-15T20:10:25

Hi! Im trying to use a line discipline as a way to hook my kernel module up to a serial port. I've implemented methods for open, close, and receive_buf, and registered the line discipline (Im using N_MOUSE as my number for now) I've tried using stty line 2 < /dev/ttyS1 to attach my line discipline to a serial port (and tried this on an already open port too (using cat to open the port) and my methods never get called. I've even written a little userspace program that opens ttyS1 and uses tcsetattr() to select c_line=N_MOUSE. It looks like the ldisc is being set because after this stty reports ttyS1 to be using '2' which is correct, however my methods are still never called. What am I missing? TIA, -Ian -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH] serial8250: Sanity check nr_uarts on all paths.

Eric W. Biederman — 2008-07-11T19:30:42

I had 8250.nr_uarts=16 in the boot line of a test kernel and I had a weird mysterious crash in sysfs. After an taking in depth look I realized that CONFIG_SERIAL_8250_NR_UARTS was set to 4 and I was walking off the end of the serial8250_ports array. Ouch!!! Don't let this happen to someone else. Signed-off-by: Eric W. Biederman xmission.com> --- drivers/serial/8250.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c index 1bc00b7..be95e55 100644 --- a/drivers/serial/8250.c +++ b/drivers/serial/8250.c < at >< at > -2623,6 +2623,9 < at >< at > static struct console serial8250_console = { static int __init serial8250_console_init(void) { +if (nr_uarts > UART_NR) +nr_uarts = UART_NR; + serial8250_isa_init_ports(); register_console(&serial8250_console); return 0;

Suggested patch for linux

Axel Hosemann — 2008-07-09T23:16:37

Dear Sirs, the support of the serial interface by linux systems nowadays suffers from the disadvantage, that hardware handshake is only supported for the full duplex mode. That means, that the RTS signal is getting always asserted immediately after the serial was opened. So the RTS signal under linux, as far as I understood it, carries exactly the same information as the DTR line. That means, that there is no half-duplex behaviour provided by linux. A half-duplex application as e.g. RS-485 controllers or radio modems are depending on a different behaviour: The serial port asserts DTR after it was opened, but RTS must only be asserted, when data has been written to the tx buffer for transmission. Stimulated by the RTS signal, the DCE will then engage the channel for transmission and release it, after the RTS has been deasserted when the buffer had been sent. This behaviour is up to now not supported by the linux serial drivers. Therefore I make a suggestion for adding the half-duplex support for linux kernels by the attached patch, which I created and tested on a UART 16550 compliant hardware and additionally by means of a ftdi usb to serial port adaptor. The patch was compiled and tested with an UBUNTU 2.6.24-19-generic environment. If you see a chance, to add this functionality for future linux kernels, I would be interested in further discussions about this patch. Regards Axel Hosemann Bergstrasse 6f CH 5644 Auw

[PATCH] send_break: Return fix

Alan Cox — 2008-06-30T16:40:08

Not sure how this came to get inverted but it appears to have been my mess up. Signed-off-by: Alan Cox redhat.com> tty: Fix inverted logic in send_break From: Alan Cox redhat.com> --- drivers/char/tty_io.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c index e94bee0..7501310 100644 --- a/drivers/char/tty_io.c +++ b/drivers/char/tty_io.c < at >< at > -3322,7 +3322,7 < at >< at > static int send_break(struct tty_struct *tty, unsigned int duration) msleep_interruptible(duration); tty->ops->break_ctl(tty, 0); tty_write_unlock(tty); -if (!signal_pending(current)) +if (signal_pending(current)) return -EINTR; return 0; } -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH] cpm_uart: Support uart_wait_until_sent()

Laurent Pinchart — 2008-06-26T11:55:03

Set port->fifosize to the software FIFO size, and update the port timeout when the baud rate is modified. SCC ports have an optional 32 byte hardware FIFO which is currently not taken into account, as there is no documented way to check when the FIFO becomes empty. Signed-off-by: Laurent Pinchart cse-semaphore.com> --- drivers/serial/cpm_uart/cpm_uart_core.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c index a19dc7e..151cad2 100644 --- a/drivers/serial/cpm_uart/cpm_uart_core.c +++ b/drivers/serial/cpm_uart/cpm_uart_core.c < at >< at > -547,6 +547,11 < at >< at > static void cpm_uart_set_termios(struct uart_port *port, } /* + * Update the timeout + */ +uart_update_timeout(port, termios->c_cflag, baud); + +/* * Set up parity check flag */ #define RELEVANT_IFLAG(iflag) (iflag & (IGNBRK|BRKINT|IGNPAR|PARMRK|INPCK)) < at >< at > -1154,6 +1159,7 < at >< at > int cpm_uart_drv_get_platform_data(struct platform_device *pdev, int is_con) pinfo->port.uartclk = pdata->uart_clk; pinfo->port.mapbase = (unsigned long)mem; pinfo->port.irq = platform_get_irq(pdev, 0); +pinfo->port.fifosize = pinfo->tx_nrfifos * pinfo->tx_fifosize; return 0; }