Prasad Koya | 30 Sep 19:30 2014

process receive fifo while xmitting in 8250.

Hi Ted

At 9600 baud, we are seeing buffer overruns on our 16550A UARTs. If a
command, say 40 chars long, is sent to console and if printk to
console happens at same time, we running into receive buffer overrun.
Thats because, at 9600 baud, it takes about a millisecond to xmit 1
char and with receive FIFO only 16 chars deep, it is very easy to
cause receive buffer overrun.

To get around that, I am trying below patch on 3.17 kernel. This is
tested and working on 3.4 kernel. I wanted to get some comments from
linux-serial mailing list.

If UART_IER_RDI is enabled, for every quarter of fifo size bytes sent,
console_write() checks to see if there is data in receive fifo. If so,
it lets serial8250_rx_chars() pick those bytes and buffer them in tty

Thank you.

--- linux-3.17rc6-orig/linux-3.17-rc6/drivers/tty/serial/8250/8250_core.c
      2014-09-21 15:43:02.000000000 -0700
+++ linux-3.17-rc6/drivers/tty/serial/8250/8250_core.c  2014-09-30
10:08:06.401242782 -0700
 <at>  <at>  -3004,6 +3004,7  <at>  <at> 
        unsigned long flags;
        unsigned int ier;
        int locked = 1;
+       int to_send, offset, fifo = count;

(Continue reading)

Gregory Hermant | 30 Sep 08:59 2014

[PATCH v2] max310x: max3109_detect should use indirect addressing in SPI mode for REVID register

This patch allows to read the REV_ID register in SPI mode and consequently
to properly detect the max3109. Indeed in SPI mode, this register is only
accessible by using indirect addressing.

Signed-off-by: Gregory Hermant <gregory.hermant <at>>
 drivers/tty/serial/max310x.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index 82573dc..e7cb897 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
 <at>  <at>  -346,10 +346,13  <at>  <at>  static int max3109_detect(struct device *dev)
 	unsigned int val = 0;
 	int ret;

-	ret = regmap_read(s->regmap, MAX310X_REVID_REG, &val);
+	ret = regmap_write(s->regmap, MAX310X_GLOBALCMD_REG,
+			   MAX310X_EXTREG_ENBL);
 	if (ret)
 		return ret;

+	regmap_read(s->regmap, MAX310X_REVID_EXTREG, &val);
+	regmap_write(s->regmap, MAX310X_GLOBALCMD_REG, MAX310X_EXTREG_DSBL);
 	if (((val & MAX310x_REV_MASK) != MAX3109_REV_ID)) {
 			"%s ID 0x%02x does not match\n", s->devtype->name, val);

(Continue reading)

Janusz Uzycki | 29 Sep 15:59 2014

<20140929014129.GA8687 <at>>

> So I'm deleting all of these now, please resend the latest
> versions you have, with properly versioning
> and order information.

Sure. If you don't want to comment dirty patches
I will not send you them.
I can send you only the final version, commented before.

On the moment this patch is ready to apply.

[PATCH RESEND] serial: mxs-auart: add sysrq support
The patch is resent to apply.
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo <at>
More majordomo info at

Sebastian Andrzej Siewior | 29 Sep 10:21 2014

[PATCH] tty: serial: 8250: use 32bit variable for rpm_tx_active

The kbuild test robot wrote me:
|  make.cross ARCH=powerpc
|>> ERROR: ".__xchg_called_with_bad_pointer" [drivers/tty/serial/8250/8250.ko] undefined!

The generic implementation of xchg() on arm and x86 works for variables of
size one bye (char). According to the report powerpc does not support
xchg() for one byte sized variables and looking further it seems also to
be the same case for sparc and tile (or for 10 out of 26 architectures
which provide a custom implementation).
For that reason I increase the size of the variable from one to four
bytes to get it work on powerpc (and the others).

Reported-By: kbuild test robot <fengguang.wu <at>>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy <at>>
 include/linux/serial_8250.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index c267412a3ef4..3df10d5f154b 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
 <at>  <at>  -84,7 +84,7  <at>  <at>  struct uart_8250_port {
 	unsigned char		mcr_mask;	/* mask of user bits */
 	unsigned char		mcr_force;	/* mask of forced bits */
 	unsigned char		cur_iotype;	/* Running I/O type */
-	unsigned char		rpm_tx_active;
+	unsigned int		rpm_tx_active;

(Continue reading)

Markus Pargmann | 29 Sep 09:29 2014

[PATCH RESEND] tty: serial: omap: Remove probe error message

This error message is not necessary. The driver core code will print all
probe error messages. It also resolves some error codes to proper error
messages. For example -EPROBE_DEFER will only be printed as an info message.

This patch removes the error message as the core prints the same

Signed-off-by: Markus Pargmann <mpa <at>>


I am not sure if this patch got lost, so I resend it. I rebased the patch onto
v3.17-rc1 without conflicts.

Best regards,


 drivers/tty/serial/omap-serial.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index d017cec8a34a..a153bad142c8 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
 <at>  <at>  -1733,8 +1733,6  <at>  <at>  err_add_port:
(Continue reading)

Janusz Uzycki | 27 Sep 11:46 2014

[PATCH v3] serial: mxs-auart: gpios as modem signals (dirty)

The patchset
"Re: [PATCH 1/4] serial: mxs-auart: use mctrl_gpio helpers for handling modem signals (v2.2c)"
is changed and resent here.

Please comment.

v3 changelog:
* own patches reordered to apply mainline
* outsize of the patchset as independent:
   serial: mxs-auart: add sysrq support

new [PATCH 1/4] serial: mxs-auart: ctrl removed from mxs_auart_port
* the ctrl variable duplicated mctrl, member of uart_port structure
  in serial_core.h
* the code duplicated uart_update_mctrl() and uart_tiocmget()
  in serial_core.c
* mxs_auart_get_mctrl() reads back RTS line. It could be removed too
  but not sure.

[PATCH 2/4] serial: mxs-auart: use mctrl_gpio helpers for handling
 modem signals
* mctrl_gpio_free() removed to simplify:
  mctrl_gpio_free() is not necessary in mxs_auart_probe() and
  mxs_auart_remove() because mctrl_gpio_init() does all
  allocations with devm_* functions.
  (see Documentation/serial/driver since kernel 3.16)
* DMA on HW flow control comment updated, still not sure about the comment
* mxs_auart_modem_status() removed from mxs_auart_get_mctrl():
  mctrl_gpio_get() does not clear gpio interrupt pendings like
  8250_core.c does with MSR.
(Continue reading)

Janusz Uzycki | 26 Sep 16:08 2014

[PATCH] serial: mxs-auart: add sysrq support

This is rather obvious patch now.
The patch is resent as cleaned independent from the patchset:
"Re: [PATCH 1/4] serial: mxs-auart: use mctrl_gpio helpers for handling modem signals (v2.2c)"

Who could apply the patch?

best regards

To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo <at>
More majordomo info at

小曹 | 26 Sep 07:56 2014

用了一次你就会觉得是最好的短信发送平台 pma5q


(Continue reading)

Peter Hurley | 24 Sep 12:26 2014

[PATCH] tty: Fix width of unsigned long bitfield padding

Commit c545b66c6922b002b5fe224a6eaec58c913650b5,
'tty: Serialize tcflow() with other tty flow control changes' and
commit 99416322dd16b810ba74098cc50ef2a844091d35,
'tty: Workaround Alpha non-atomic byte storage in tty_struct' work around
compiler bugs and non-atomic storage on multiple arches by padding
bitfields out to the declared type which is unsigned long. However, the
width varies by arch.

Pad bitfields to actual width of unsigned long (which is BITS_PER_LONG).

Reported-by: Fengguang Wu <fengguang.wu <at>>
Signed-off-by: Peter Hurley <peter <at>>
 include/linux/tty.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/tty.h b/include/linux/tty.h
index 7a0a796..6b6a449 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
 <at>  <at>  -264,11 +264,11  <at>  <at>  struct tty_struct {
 	struct winsize winsize;		/* winsize_mutex */
 	unsigned long stopped:1,	/* flow_lock */
-		      unused:62;
+		      unused:BITS_PER_LONG - 2;
 	int hw_stopped;
 	unsigned long ctrl_status:8,	/* ctrl_lock */
-		      unused_ctrl:55;
(Continue reading)

Yegor Yefremov | 23 Sep 09:56 2014

RS485: RTS pin logical level before/after sending

What's the purpose of being able to define both states? AFAIK
omap_serial.c is working as follows:

        if (of_property_read_bool(np, "rs485-rts-active-high"))
                rs485conf->flags |= SER_RS485_RTS_ON_SEND;
                rs485conf->flags |= SER_RS485_RTS_AFTER_SEND;

If RTS should be on before send, then it automatically selects RTS off
for after send scenario. Are there systems, that would really set
levels for both cases to the same value? Is this intended for RS422
case, where transmitter can be always on?

To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo <at>
More majordomo info at

Daniel Thompson | 23 Sep 09:31 2014

[PATCH tty-next v2] serial: asc: Conditionally use readl_relaxed (COMPILE_TEST)

Commit 08177ece596c ("serial: asc: Adopt readl_/writel_relaxed()) is
regressing the m68k allmodconfig build. This is due to the unconditional
use of readl_relaxed() which, although documented, does not currently
exist for m68k.

This is trivially fixable for st-asc because we can just update the
asc_in() accessor to make this conditional.

Reported-by: Guenter Roeck <linux <at>>
Signed-off-by: Daniel Thompson <daniel.thompson <at>>
Cc: Srinivas Kandagatla <srinivas.kandagatla <at>>
Cc: Maxime Coquelin <maxime.coquelin <at>>
Cc: Patrice Chotard <patrice.chotard <at>>
Cc: Jiri Slaby <jslaby <at>>

    Will Deacon is working on a patchset to introduce readl_relaxed (and
    writel_relaxed) to all platforms. I intend to keep an eye on this
    work and will remove the conditional code in asc_in/out() when this
    is possible.

    Changes since v1:

    * Added the correct Reported-by: and removed the assertion that
      the reporter is a build bot.

 drivers/tty/serial/st-asc.c | 4 ++++
 1 file changed, 4 insertions(+)

(Continue reading)