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 car

[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

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

[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 > -140

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 /d

[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 in

[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

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

[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 +++++++++++

[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 --

[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) { +

[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_

[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

[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_dev