Shreyas Bethur | 31 Oct 21:33 2014

[PATCH 1/1] tty: Do not set modem lines when reopening ports

When tty port is opened, we will raise the DTR and RTS lines. But for
second and subsequent opens, we should not modify these lines because the
first session might be actively using these lines. We don't want a second
open to interfere with the first session.

Signed-off-by: Shreyas Bethur <shreyas.bethur <at> ni.com>
---
To give some background for this patch, we have a product that uses the
DTR line on the serial port for synchronization with other devices. While
the synchronization application is using the DTR line, if another process
opens the same port, then DTR line is raised, and thus interferes with the
synchronization application. So, if a port is open, subsequent opens
should not modify any modem lines.

This patch is my attempt to fix this issue. Please review my fix, and let
me know what you folks think.
---
 drivers/tty/tty_port.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index 1b93357..8a6c80a 100644
--- a/drivers/tty/tty_port.c
+++ b/drivers/tty/tty_port.c
 <at>  <at>  -363,6 +363,7  <at>  <at>  int tty_port_block_til_ready(struct tty_port *port,
        int do_clocal = 0, retval;
        unsigned long flags;
        DEFINE_WAIT(wait);
+       bool port_first_open = true;

(Continue reading)

Matthias Brugger | 31 Oct 17:36 2014
Picon

[PATCH RESEND] tty: serial: 8250_mtk: Fix quot calculation

From: Matthias Brugger <matthias.bgg <at> gmail.com>

The calculation of value quot for highspeed register set to three
was wrong. This patch fixes the calculation so that the serial port
for baudrates bigger then 576000 baud is working correctly.

Signed-off-by: Matthias Brugger <matthias.bgg <at> gmail.com>
---
 drivers/tty/serial/8250/8250_mtk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c
index 8f37d57..de7aae5 100644
--- a/drivers/tty/serial/8250/8250_mtk.c
+++ b/drivers/tty/serial/8250/8250_mtk.c
 <at>  <at>  -81,7 +81,7  <at>  <at>  mtk8250_set_termios(struct uart_port *port, struct ktermios *termios,
 		/* Set to highest baudrate supported */
 		if (baud >= 1152000)
 			baud = 921600;
-		quot = DIV_ROUND_CLOSEST(port->uartclk, 256 * baud);
+		quot = (port->uartclk / (256 * baud)) + 1;
 	}

 	/*
--

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Aaron Sierra | 31 Oct 01:49 2014

[PATCH 1/2] serial: 8250_pci: Handle devices mapped above 4 GiB

Several init/setup functions passed the PCI BAR resource start address
to ioremap_nocache() via an unsigned long. This caused address truncation
for a 32-bit device mapped above 4 GiB (i.e. the CPU interacts with the
device via a translated address), which resulted in a kernel panic.

This patch replaces all of the instances of intermediate variable use
with pci_ioremap_bar() to ensure the full resource_size_t start address
is used and that ioremap_nocache() is still called.

The kernel panic (Exar XR17V358 PCIe device on a Freescale P2020 SBC):

Machine check in kernel mode.
Caused by (from MCSR=10008): Bus - Read Data Bus Error
Oops: Machine check, sig: 7 [#1]
SMP NR_CPUS=2 X-ES P2020
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.14.15-xes_r2-00002-g560e401 #978
task: bf850000 ti: bffee000 task.ti: bf84c000
NIP: 80318e10 LR: 80319ecc CTR: 80318dfc
REGS: bffeff10 TRAP: 0204   Not tainted  (3.14.15-xes_r2-00002-g560e401)
MSR: 00021000 <CE,ME>  CR: 20adbe42  XER: 00000000
DEAR: c1058001 ESR: 00000000
GPR00: 00000000 bf84db30 bf850000 80cb4af8 00000001 00000000 80000007 80000000
GPR08: bf837c9c c1058001 00000001 00000000 80000007 00000000 80002a10 00000000
GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 80cb0000 80c72dc4
GPR24: 80cb4900 fffffffe 00029000 00000001 bf8c11e8 ffffffea 80c72ce4 80cb4af8
NIP [80318e10] mem_serial_in+0x14/0x28
LR [80319ecc] serial8250_config_port+0x160/0xe38
Call Trace:
[bf84db30] [80319d94] serial8250_config_port+0x28/0xe38 (unreliable)
(Continue reading)

Aaron Sierra | 31 Oct 01:49 2014

[PATCH 2/2] serial: 8250_pci: Check mapping in pci_ni8430_init

Check the return value of ioremap_nocache to make sure we got a
valid mapping.

Signed-off-by: Aaron Sierra <asierra <at> xes-inc.com>
---
 drivers/tty/serial/8250/8250_pci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index 2e8d8a4..e97eeda 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
 <at>  <at>  -757,6 +757,8  <at>  <at>  pci_ni8430_setup(struct serial_private *priv,
 	offset += idx * board->uart_offset;

 	p = pci_ioremap_bar(dev, bar);
+	if (!p)
+		return -ENOMEM;

 	/* enable the transceiver */
 	writeb(readb(p + offset + NI8430_PORTCON) | NI8430_PORTCON_TXVR_ENABLE,
--

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

Stephen Boyd | 30 Oct 02:47 2014

[PATCH] tty: serial: msm: Reset uartdm after baud rate change

We need to issue a reset if we ever change the value of the IPR
register on DM hardware. If we don't reset the hardware the RX
stale interrupt never triggers and the only way to trigger an RX
handling event is by filling up the fifo. This causes things like
getty to not work so well considering it might change the baud
rate a few times. Fix this by moving the reset on startup and any
reprogramming required after the reset to be after we change the
baud rate.

Signed-off-by: Stephen Boyd <sboyd <at> codeaurora.org>
---

This is based on my latest two patches to fix the break handling in this
driver[1]. The only conflict is the break start interrupt bit so it could
be moved off that patch if desired. This doesn't seem to affect non-DM
hardware one way or the other, but I also can't get a getty to work on
non-DM hardware right now. I need to debug that more some time.

[1] http://lkml.kernel.org/r/1414606478-13709-1-git-send-email-sboyd <at> codeaurora.org

 drivers/tty/serial/msm_serial.c | 49 ++++++++++-------------------------------
 1 file changed, 12 insertions(+), 37 deletions(-)

diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
index d44c04976f7a..b507f5a16c1c 100644
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
 <at>  <at>  -427,9 +427,6  <at>  <at>  static int msm_set_baud_rate(struct uart_port *port, unsigned int baud)

 	entry = msm_find_best_baud(port, baud);
(Continue reading)

kabiru wahid | 28 Oct 13:46 2014
Picon

REPLY ME IMMEDIATELY!

Hello Dear Friend. I Know That This Mail Will Come To You As A
Surprise As We Never Met Before. I Need Your Urgent Assistance in
Transferring The Sum of ($15.5m) Into Your Bank Account, After Hearing
From You I Will Give You More Details about the Transaction. Your full
Data’s Will Be Required To Enable Me Draft An Application Form Which
You Will Fill And Apply To Our Bank For The Release Of The Transfer In
Your Name.I am Waiting For Your Urgent Respond To Enable Us Proceed
Further For the Transfer Of This Fund into Your Account.

Yours Faithfully,
Mr.Kabiru Wahid.
Cont:Email: k.wahid201 <at> terra.com.
--
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

Dirk Behme | 28 Oct 09:28 2014

[PATCH 1/2] serial: imx: clean up imx_poll_put_char()

From: Daniel Thompson <daniel.thompson <at> linaro.org>

imx_put_poll_char() has been simplified to remove the code to disable
interrupts. The present code can corrupt register state when re-entered
from FIQ handler.

Switch to _relaxed() MMIO functions (which are safe for polled I/O and
needed to avoid taking spin locks).

Signed-off-by: Daniel Thompson <daniel.thompson <at> linaro.org>
Signed-off-by: Dirk Behme <dirk.behme <at> de.bosch.com>
Cc: Greg Kroah-Hartman <gregkh <at> linuxfoundation.org>
Cc: Jiri Slaby <jslaby <at> suse.cz>
Cc: Huang Shijie <b32955 <at> freescale.com>
Cc: linux-serial <at> vger.kernel.org
---
 drivers/tty/serial/imx.c | 24 +++++-------------------
 1 file changed, 5 insertions(+), 19 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 8f62a3c..0b6f14b 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
 <at>  <at>  -1509,42 +1509,28  <at>  <at>  imx_verify_port(struct uart_port *port, struct serial_struct *ser)
 #if defined(CONFIG_CONSOLE_POLL)
 static int imx_poll_get_char(struct uart_port *port)
 {
-	if (!(readl(port->membase + USR2) & USR2_RDR))
+	if (!(readl_relaxed(port->membase + USR2) & USR2_RDR))
 		return NO_POLL_CHAR;
(Continue reading)

Piotr Król | 28 Oct 00:44 2014

amba-pl011 complains about DMA for bcm2835 where it is not supported

Hi all,
according to BCM2835 ARM Peripherals spec DMA is optional functionality
for ARM PL011 UART and it is not supported on this SoC. It looks like
amba-pl011 search for device tree property (dma-names) unconditionally,
what leads to error message:

of_dma_request_slave_channel: dma-names property of node '/soc/uart <at> 7e201000' missing or empty
uart-pl011 20201000.uart: no DMA platform data

I assume that if it is possible that amba-pl011 can be without DMA we
should check if DMA is supported and then try to read properties. Is
there any known method for checking dma support ? If yes that I would be
glad for any pointers.

Let me know if I should ignore/accept this error message or there is
some code fix needed.

Thanks,
Piotr Król
~
--
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

Fabio Estevam | 27 Oct 17:49 2014

[PATCH 1/4] serial: imx: Fix the reporting of interrupts

On a imx system with ttymxc0, ttymxc1 and ttymxc4 registered we see the 
following output from 'cat /proc/interrupts':

$ cat /proc/interrupts                                          
           CPU0                                                                 
...                                            
 58:         39       GIC  58  2020000.serial                                   
 67:        115       GIC  67  21f8000.i2c  

The only uart irq that appears is ttymxc0, which is the console.

As ttymxc1 and ttymxc4 will only have their irq registered at imx_startup(),
they are not shown right after probe.

Transmitting to ttymxc1 and ttymxc4 will cause their irqs to be registered, but
the output shows:

$ echo "111111" > /dev/ttymxc1                                  
$ echo "444444" > /dev/ttymxc4                                  
$ cat /proc/interrupts                                          
           CPU0                                                                 
...                                           
 58:        150       GIC  58  2020000.serial                                   
 59:          1       GIC  59                                                   
 62:          1       GIC  62                                                   
 67:        115       GIC  67  21f8000.i2c   

,which misses printing the associated device address.

In order to fix this, register all the irqs inside the probe function via
(Continue reading)

Sifan Naeem | 24 Oct 17:53 2014
Sifan Naeem <Sifan.Naeem <at> imgtec.com>

Subject: Synopsys DesignWare 8250 serial port driver, DMA issue

Synopsys DesignWare 8250 serial port driver, DMA issue

Hi,

I'm trying to test the DMA capability of the UART Linux driver which was 
written by Synopsys (DesignWare 8250 driver) drivers/tty/serial/8250/

As it is even when the DMA capability for the UART driver is enabled by 
the Kernel, the driver does not initialize or try to use 
DMA mode. 

Did I miss something? do I have to enable something else?

Thanks,
Sifan

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

Jingchang Lu | 24 Oct 11:20 2014

[PATCH] serial: fsl-lpuart: add lpuart32 power management support

This adds 32-bit register lpuart32 power management support,
this also updates the 8-bit register lpuart resume function.

Signed-off-by: Jingchang Lu <jingchang.lu <at> freescale.com>
---
 drivers/tty/serial/fsl_lpuart.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 6dd53af..4e25772 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
 <at>  <at>  -1862,6 +1862,20  <at>  <at>  static int lpuart_suspend(struct device *dev)
 static int lpuart_resume(struct device *dev)
 {
 	struct lpuart_port *sport = dev_get_drvdata(dev);
+	unsigned long temp;
+
+	if (sport->lpuart32) {
+		lpuart32_setup_watermark(sport);
+		temp = lpuart32_read(sport->port.membase + UARTCTRL);
+		temp |= (UARTCTRL_RIE | UARTCTRL_TIE | UARTCTRL_RE |
+			 UARTCTRL_TE | UARTCTRL_ILIE);
+		lpuart32_write(temp, sport->port.membase + UARTCTRL);
+	} else {
+		lpuart_setup_watermark(sport);
+		temp = readb(sport->port.membase + UARTCR2);
+		temp |= (UARTCR2_RIE | UARTCR2_TIE | UARTCR2_RE | UARTCR2_TE);
+		writeb(temp, sport->port.membase + UARTCR2);
+	}
(Continue reading)


Gmane