Linux Serial subsystem development
 help / color / mirror / Atom feed
* [PATCH 5/7] serial: imx: umap sg buffers when DMA channel is released
From: Romain Perier @ 2017-06-30 12:04 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: linux-serial, linux-arm-kernel, linux-kernel, Nandor Han,
	Romain Perier
In-Reply-To: <20170630120446.13994-1-romain.perier@collabora.com>

From: Nandor Han <nandor.han@ge.com>

This commits unmaps sg buffers when the DMA channel is released

Signed-off-by: Nandor Han <nandor.han@ge.com>
Signed-off-by: Romain Perier <romain.perier@collabora.com>
---
 drivers/tty/serial/imx.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index e8cf7cf..58d6b1c 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1215,6 +1215,12 @@ static void imx_stop_tx_dma(struct imx_port *sport)
 	temp = readl(sport->port.membase + UCR1);
 	temp &= ~UCR1_TDMAEN;
 	writel(temp, sport->port.membase + UCR1);
+
+	if (sport->dma_is_txing) {
+		dma_unmap_sg(sport->port.dev, &sport->tx_sgl[0],
+		sport->dma_tx_nents, DMA_TO_DEVICE);
+		sport->dma_is_txing = 0;
+	}
 }
 
 static void imx_stop_rx_dma(struct imx_port *sport)
@@ -1224,6 +1230,12 @@ static void imx_stop_rx_dma(struct imx_port *sport)
 	temp = readl(sport->port.membase + UCR1);
 	temp &= ~(UCR1_RDMAEN | UCR1_ATDMAEN);
 	writel(temp, sport->port.membase + UCR1);
+
+	if (sport->dma_is_rxing) {
+		dma_unmap_sg(sport->port.dev, &sport->rx_sgl, 1,
+			DMA_FROM_DEVICE);
+		sport->dma_is_rxing = 0;
+	}
 }
 
 static void imx_enable_dma(struct imx_port *sport)
-- 
1.8.3.1

^ permalink raw reply related

* [PATCH 4/7] serial: imx: Simplify DMA disablement
From: Romain Perier @ 2017-06-30 12:04 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Romain Perier, Nandor Han, linux-arm-kernel, linux-serial,
	linux-kernel
In-Reply-To: <20170630120446.13994-1-romain.perier@collabora.com>

From: Nandor Han <nandor.han@ge.com>

This commits simplify the function imx_disable_dma() by moving
the code for disabling RX and TX DMAs to dedicated functions.
Also move away CTSC and CTS as this is not related to DMA.

Signed-off-by: Nandor Han <nandor.han@ge.com>
Signed-off-by: Romain Perier <romain.perier@collabora.com>
---
 drivers/tty/serial/imx.c | 31 ++++++++++++++++++++-----------
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 81fb413..e8cf7cf 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1208,6 +1208,24 @@ static int imx_uart_dma_init(struct imx_port *sport)
 	return ret;
 }
 
+static void imx_stop_tx_dma(struct imx_port *sport)
+{
+	unsigned long temp;
+
+	temp = readl(sport->port.membase + UCR1);
+	temp &= ~UCR1_TDMAEN;
+	writel(temp, sport->port.membase + UCR1);
+}
+
+static void imx_stop_rx_dma(struct imx_port *sport)
+{
+	unsigned long temp;
+
+	temp = readl(sport->port.membase + UCR1);
+	temp &= ~(UCR1_RDMAEN | UCR1_ATDMAEN);
+	writel(temp, sport->port.membase + UCR1);
+}
+
 static void imx_enable_dma(struct imx_port *sport)
 {
 	unsigned long temp;
@@ -1233,17 +1251,8 @@ static void imx_enable_dma(struct imx_port *sport)
 
 static void imx_disable_dma(struct imx_port *sport)
 {
-	unsigned long temp;
-
-	/* clear UCR1 */
-	temp = readl(sport->port.membase + UCR1);
-	temp &= ~(UCR1_RDMAEN | UCR1_TDMAEN | UCR1_ATDMAEN);
-	writel(temp, sport->port.membase + UCR1);
-
-	/* clear UCR2 */
-	temp = readl(sport->port.membase + UCR2);
-	temp &= ~(UCR2_CTSC | UCR2_CTS | UCR2_ATEN);
-	writel(temp, sport->port.membase + UCR2);
+	imx_stop_rx_dma(sport);
+	imx_stop_tx_dma(sport);
 
 	imx_setup_ufcr(sport, TXTL_DEFAULT, RXTL_DEFAULT);
 
-- 
1.8.3.1

^ permalink raw reply related

* [PATCH 3/7] serial: imx: init dma_is_{rx|tx}ing variables
From: Romain Perier @ 2017-06-30 12:04 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: linux-serial, linux-arm-kernel, linux-kernel, Nandor Han,
	Romain Perier
In-Reply-To: <20170630120446.13994-1-romain.perier@collabora.com>

From: Nandor Han <nandor.han@ge.com>

Initialize both dma_is_{rx|tx}ing variables when DMA is enabled to avoid
checking uninitialized variables if port shutdown is requested before
DMA channels get a chance to start.

Signed-off-by: Nandor Han <nandor.han@ge.com>
Signed-off-by: Romain Perier <romain.perier@collabora.com>
---
 drivers/tty/serial/imx.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 188063d..81fb413 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1225,6 +1225,9 @@ static void imx_enable_dma(struct imx_port *sport)
 
 	imx_setup_ufcr(sport, TXTL_DMA, RXTL_DMA);
 
+	sport->dma_is_rxing = 0;
+	sport->dma_is_txing = 0;
+
 	sport->dma_is_enabled = 1;
 }
 
-- 
1.8.3.1

^ permalink raw reply related

* [PATCH 2/7] serial: imx: move log from error to debug type
From: Romain Perier @ 2017-06-30 12:04 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Romain Perier, Nandor Han, linux-arm-kernel, linux-serial,
	linux-kernel
In-Reply-To: <20170630120446.13994-1-romain.perier@collabora.com>

From: Nandor Han <nandor.han@ge.com>

During DMA startup we have a data race condition since UART port can
receive data that can generate different type of errors.

This is not necessarily an error since DMA didn't yet started. The
situation is minimized but still present even if we try to clear up the
error before starting the DMA.

Therefore changing the log to debug type we avoid having "false" error
messages.

Signed-off-by: Nandor Han <nandor.han@ge.com>
Signed-off-by: Romain Perier <romain.perier@collabora.com>
---
 drivers/tty/serial/imx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 1d35293..188063d 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -994,7 +994,7 @@ static void dma_rx_callback(void *data)
 	status = dmaengine_tx_status(chan, (dma_cookie_t)0, &state);
 
 	if (status == DMA_ERROR) {
-		dev_err(sport->port.dev, "DMA transaction error.\n");
+		dev_dbg(sport->port.dev, "DMA transaction error.\n");
 		clear_rx_errors(sport);
 		return;
 	}
-- 
1.8.3.1

^ permalink raw reply related

* [PATCH 1/7] serial: imx: only set DMA rx-ing when DMA starts
From: Romain Perier @ 2017-06-30 12:04 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: linux-serial, linux-arm-kernel, linux-kernel, Nandor Han,
	Romain Perier
In-Reply-To: <20170630120446.13994-1-romain.perier@collabora.com>

From: Nandor Han <nandor.han@ge.com>

Avoid the situation when `dma_is_rxing` could incorrectly signal that
DMA RX channel is receiving data in case DMA preparation or sg mapping
fails.

Signed-off-by: Nandor Han <nandor.han@ge.com>
Signed-off-by: Romain Perier <romain.perier@collabora.com>
---
 drivers/tty/serial/imx.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 5437b34..1d35293 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -725,11 +725,11 @@ static irqreturn_t imx_rxint(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
-static void imx_disable_rx_int(struct imx_port *sport)
+static void imx_disable_rx_int(struct imx_port *sport, bool is_rxing)
 {
 	unsigned long temp;
 
-	sport->dma_is_rxing = 1;
+	sport->dma_is_rxing = is_rxing;
 
 	/* disable the receiver ready and aging timer interrupts */
 	temp = readl(sport->port.membase + UCR1);
@@ -762,7 +762,7 @@ static void imx_dma_rxint(struct imx_port *sport)
 	temp = readl(sport->port.membase + USR2);
 	if ((temp & USR2_RDR) && !sport->dma_is_rxing) {
 
-		imx_disable_rx_int(sport);
+		imx_disable_rx_int(sport, false);
 
 		/* tell the DMA to receive the data. */
 		start_rx_dma(sport);
@@ -1083,6 +1083,7 @@ static int start_rx_dma(struct imx_port *sport)
 	desc->callback_param = sport;
 
 	dev_dbg(dev, "RX: prepare for the DMA.\n");
+	sport->dma_is_rxing = 1;
 	sport->rx_cookie = dmaengine_submit(desc);
 	dma_async_issue_pending(chan);
 	return 0;
@@ -1362,7 +1363,7 @@ static int imx_startup(struct uart_port *port)
 		spin_unlock(&tty->files_lock);
 
 		if (readcnt > 0) {
-			imx_disable_rx_int(sport);
+			imx_disable_rx_int(sport, true);
 			start_rx_dma(sport);
 		}
 	}
-- 
1.8.3.1

^ permalink raw reply related

* [PATCH 0/7] serial: imx: various improvements
From: Romain Perier @ 2017-06-30 12:04 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Romain Perier, linux-arm-kernel, linux-serial, linux-kernel

During shutdown when a userspace service is disabled (which generates
an uart close), we got kernel crashes in the imx serial driver :

[ 1257.657423] Unhandled fault: external abort on non-linefetch (0x1008) at 0xf0938000
[ 1257.665122] pgd = ecf20000
[ 1257.667838] [f0938000] *pgd=de819811, *pte=53fc0653, *ppte=53fc0453
[ 1257.674179] Internal error: : 1008 [#1] SMP ARM
[ 1257.678722] Modules linked in:
[ 1257.681807] CPU: 0 PID: 3850 Comm: emerald_acq Not tainted 4.8.0 #10
[ 1257.688168] Hardware name: Freescale i.MX53 (Device Tree Support)
[ 1257.694269] task: e5c48000 task.stack: ed0b4000
[ 1257.698827] PC is at imx_rxint+0x5c/0x228
[ 1257.702859] LR is at lock_acquired+0x494/0x57c
[ 1257.707312] pc : [<80484884>]    lr : [<80173aa0>]    psr: 20070193
[ 1257.707312] sp : ed0b5c60  ip : ed0b5be8  fp : ed0b5c9c
[ 1257.718795] r10: 00000000  r9 : 00000000  r8 : 00000004
[ 1257.724027] r7 : 00000030  r6 : ee83e258  r5 : 00000000  r4 : ee09f410
[ 1257.730561] r3 : 0015c30c  r2 : f0938000  r1 : 00000135  r0 : 40070193
[ 1257.737099] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
[ 1257.744327] Control: 10c5387d  Table: dcf20019  DAC: 00000051
[ 1257.750080] Process emerald_acq (pid: 3850, stack limit = 0xed0b4210)
[ 1257.756527] Stack: (0xed0b5c60 to 0xed0b6000)
[ 1257.760898] 5c60: ed0b5cf4 40070193 80175f64 80faf384 e5c484c0 ee09f410 00007240 00005099
[ 1257.769087] 5c80: 00000030 00000030 80e025c4 00000000 ed0b5cf4 ed0b5ca0 80485b18 80484834
[ 1257.777275] 5ca0: 8012fe26 00000000 00000000 60070193 ee81b210 00000001 ed0b5cdc ed0b5cc8
[ 1257.785463] 5cc0: 80171d28 80171c3c 80e2d634 ee096740 ee81b200 ee81b210 00000001 00000030
[ 1257.793651] 5ce0: 80e025c4 00000000 ed0b5d34 ed0b5cf8 80182f10 804857fc e5c484c0 00000002
[ 1257.801839] 5d00: ee81b200 ed0b5d3c 60070193 ee81b200 ee81b200 ee81b210 00000001 ee81c400
[ 1257.810027] 5d20: 00000001 00000008 ed0b5d54 ed0b5d38 801832d8 80182ed0 808f4b60 00000000
[ 1257.818216] 5d40: ee81b200 ee81b260 ed0b5d74 ed0b5d58 8018335c 801832b8 ee81b200 ee81b260
[ 1257.826404] 5d60: ee81b210 00000001 ed0b5d94 ed0b5d78 80186ba0 80183320 80debe8c 00000030
[ 1257.834592] 5d80: 00000000 00000001 ed0b5da4 ed0b5d98 80182420 80186af4 ed0b5dcc ed0b5da8
[ 1257.842780] 5da0: 801827a0 801823fc 00000000 80e8350c 00000020 00000001 ed0b5df8 00000001
[ 1257.850968] 5dc0: ed0b5df4 ed0b5dd0 80101530 8018274c 808f4bec 20070013 ffffffff ed0b5e2c
[ 1257.859156] 5de0: ee09f410 ed0b4000 ed0b5e5c ed0b5df8 808f55f0 801014c8 00000001 00000130
[ 1257.867345] 5e00: 00000000 e5c48000 60070013 ee09f410 00000000 60070013 ee09f410 ed06a640
[ 1257.875533] 5e20: 00000008 ed0b5e5c ed0b5df0 ed0b5e48 801756a8 808f4bec 20070013 ffffffff
[ 1257.883722] 5e40: 00000051 7f000000 ee09f410 00000b01 ed0b5e7c ed0b5e60 80485d74 808f4bb4
[ 1257.891912] 5e60: ee83e258 ee09f410 ee83e3a4 80e2d634 ed0b5ea4 ed0b5e80 8047f514 80485c70
[ 1257.900100] 5e80: ee83e258 ed375000 ee09f410 ee83e310 ee83e3ac ed06a640 ed0b5ecc ed0b5ea8
[ 1257.908288] 5ea0: 80481304 8047f400 ed375000 eeabce60 00000000 ee7973e8 00000000 ed06a640
[ 1257.916477] 5ec0: ed0b5f14 ed0b5ed0 80462fe0 804811ac 00000008 eeabce60 00000001 00000001
[ 1257.924665] 5ee0: 00000000 802713dc ed0b5f54 ed06a640 eeabce60 ee2c6910 ee7973e8 00000000
[ 1257.932854] 5f00: eeabce60 00000008 ed0b5f54 ed0b5f18 80271404 80462ee8 00000000 00000000
[ 1257.941044] 5f20: ed06c640 ed06a648 ed0b5f4c e5c48400 00000000 80e84054 e5c48440 e5c48000
[ 1257.949232] 5f40: 00000000 00000000 ed0b5f64 ed0b5f58 802715c4 80271378 ed0b5f8c ed0b5f68
[ 1257.957420] 5f60: 80146034 802715b8 00000000 ed0b4000 ed0b5fb0 801086c4 801086c4 ed0b4000
[ 1257.965610] 5f80: ed0b5fac ed0b5f90 8010cc68 80145f78 0054756c 00000000 767474b4 00000006
[ 1257.973798] 5fa0: 00000000 ed0b5fb0 80108548 8010cbc4 00000000 76f2a084 00000002 00000000
[ 1257.981986] 5fc0: 0054756c 00000000 767474b4 00000006 0225e880 00000000 76f36000 7e836d34
[ 1257.990175] 5fe0: 00000000 7e836d10 76f2a4c0 76a5db68 80070010 00000062 00000000 00000000
[ 1257.998357] Backtrace: 
[ 1258.000837] [<80484828>] (imx_rxint) from [<80485b18>] (imx_int+0x328/0x474)
[ 1258.007892]  r10:00000000 r9:80e025c4 r8:00000030 r7:00000030 r6:00005099 r5:00007240
[ 1258.015815]  r4:ee09f410
[ 1258.018386] [<804857f0>] (imx_int) from [<80182f10>] (__handle_irq_event_percpu+0x4c/0x3e8)
[ 1258.026742]  r10:00000000 r9:80e025c4 r8:00000030 r7:00000001 r6:ee81b210 r5:ee81b200
[ 1258.034664]  r4:ee096740
[ 1258.037226] [<80182ec4>] (__handle_irq_event_percpu) from [<801832d8>] (handle_irq_event_percpu+0x2c/0x68)
[ 1258.046885]  r10:00000008 r9:00000001 r8:ee81c400 r7:00000001 r6:ee81b210 r5:ee81b200
[ 1258.054806]  r4:ee81b200
[ 1258.057369] [<801832ac>] (handle_irq_event_percpu) from [<8018335c>] (handle_irq_event+0x48/0x6c)
[ 1258.066246]  r5:ee81b260 r4:ee81b200
[ 1258.069866] [<80183314>] (handle_irq_event) from [<80186ba0>] (handle_level_irq+0xb8/0x154)
[ 1258.078222]  r7:00000001 r6:ee81b210 r5:ee81b260 r4:ee81b200
[ 1258.083961] [<80186ae8>] (handle_level_irq) from [<80182420>] (generic_handle_irq+0x30/0x44)
[ 1258.092404]  r7:00000001 r6:00000000 r5:00000030 r4:80debe8c
[ 1258.098143] [<801823f0>] (generic_handle_irq) from [<801827a0>] (__handle_domain_irq+0x60/0xc8)
[ 1258.106854] [<80182740>] (__handle_domain_irq) from [<80101530>] (tzic_handle_irq+0x74/0x9c)
[ 1258.115297]  r9:00000001 r8:ed0b5df8 r7:00000001 r6:00000020 r5:80e8350c r4:00000000
[ 1258.123139] [<801014bc>] (tzic_handle_irq) from [<808f55f0>] (__irq_svc+0x70/0x98)
[ 1258.130715] Exception stack(0xed0b5df8 to 0xed0b5e40)
[ 1258.135773] 5de0:                                                       00000001 00000130
[ 1258.143962] 5e00: 00000000 e5c48000 60070013 ee09f410 00000000 60070013 ee09f410 ed06a640
[ 1258.152151] 5e20: 00000008 ed0b5e5c ed0b5df0 ed0b5e48 801756a8 808f4bec 20070013 ffffffff
[ 1258.160333]  r9:ed0b4000 r8:ee09f410 r7:ed0b5e2c r6:ffffffff r5:20070013 r4:808f4bec
[ 1258.168188] [<808f4ba8>] (_raw_spin_unlock_irqrestore) from [<80485d74>] (imx_shutdown+0x110/0x214)
[ 1258.177239]  r5:00000b01 r4:ee09f410
[ 1258.180860] [<80485c64>] (imx_shutdown) from [<8047f514>] (uart_shutdown+0x120/0x17c)
[ 1258.188695]  r7:80e2d634 r6:ee83e3a4 r5:ee09f410 r4:ee83e258
[ 1258.194434] [<8047f3f4>] (uart_shutdown) from [<80481304>] (uart_close+0x164/0x254)
[ 1258.202096]  r9:ed06a640 r8:ee83e3ac r7:ee83e310 r6:ee09f410 r5:ed375000 r4:ee83e258
[ 1258.209948] [<804811a0>] (uart_close) from [<80462fe0>] (tty_release+0x104/0x498)
[ 1258.217439]  r9:ed06a640 r8:00000000 r7:ee7973e8 r6:00000000 r5:eeabce60 r4:ed375000
[ 1258.225285] [<80462edc>] (tty_release) from [<80271404>] (__fput+0x98/0x1e8)
[ 1258.232339]  r10:00000008 r9:eeabce60 r8:00000000 r7:ee7973e8 r6:ee2c6910 r5:eeabce60
[ 1258.240261]  r4:ed06a640
[ 1258.242823] [<8027136c>] (__fput) from [<802715c4>] (____fput+0x18/0x1c)
[ 1258.249528]  r10:00000000 r9:00000000 r8:e5c48000 r7:e5c48440 r6:80e84054 r5:00000000
[ 1258.257450]  r4:e5c48400
[ 1258.260021] [<802715ac>] (____fput) from [<80146034>] (task_work_run+0xc8/0xf8)
[ 1258.267352] [<80145f6c>] (task_work_run) from [<8010cc68>] (do_work_pending+0xb0/0xd0)
[ 1258.275274]  r9:ed0b4000 r8:801086c4 r7:801086c4 r6:ed0b5fb0 r5:ed0b4000 r4:00000000
[ 1258.283116] [<8010cbb8>] (do_work_pending) from [<80108548>] (slow_work_pending+0xc/0x20)
[ 1258.291298]  r7:00000006 r6:767474b4 r5:00000000 r4:0054756c
[ 1258.297037] Code: e5943094 e594202c e2833001 e5843094 (e592a000) 
[ 1258.303148] ---[ end trace 7a50198148a54c4d ]---
[ 1258.307776] Kernel panic - not syncing: Fatal exception in interrupt
[ 1258.314160] ---[ end Kernel panic - not syncing: Fatal exception in interrupt


After investigations, we found several issues:
It looks that interrupts can happen after the dma was disabled and
port was not yet shutdown. This will result in interrupts handled by
imx_rxint. Analyzed the imx_shutdown function, and found that:

- Some interrupts were not disabled during shutdown (AWAKEN, UCR4_OREN,
  UCR1_TRDYEN) 
- TX was not stopped in all situations (if dma is enabled and
  transmitting)
- Using deprecated dmaengine_terminate_all method.
- Trying to close DMA channels several times. 

This set of patches proposes fix regarding these issues and problems we
found during debugging.

Nandor Han (7):
  serial: imx: only set DMA rx-ing when DMA starts
  serial: imx: move log from error to debug type
  serial: imx: init dma_is_{rx|tx}ing variables
  serial: imx: Simplify DMA disablement
  serial: imx: umap sg buffers when DMA channel is released
  serial: imx: update the stop rx,tx procedures
  serial: imx: Fix imx_shutdown procedure

 drivers/tty/serial/imx.c | 134 ++++++++++++++++++++++++++++-------------------
 1 file changed, 80 insertions(+), 54 deletions(-)

-- 
1.8.3.1

^ permalink raw reply

* Re: [PATCH 4/6] dt-bindings: serial: Document RDA Micro UART
From: Andreas Färber @ 2017-06-30 11:12 UTC (permalink / raw)
  To: Rob Herring
  Cc: Mark Rutland, devicetree, Greg Kroah-Hartman, service,
	linux-kernel, linux-serial, linux-arm-kernel, zhao_steven
In-Reply-To: <20170629201051.cfr37kh2gozompqo@rob-hp-laptop>

Am 29.06.2017 um 22:10 schrieb Rob Herring:
> On Tue, Jun 27, 2017 at 02:55:18AM +0200, Andreas Färber wrote:
>> Add an initial binding for the RDA8810PL UART.
>>
>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>> ---
>>  Documentation/devicetree/bindings/serial/rda-uart.txt | 13 +++++++++++++
>>  1 file changed, 13 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/serial/rda-uart.txt
>>
>> diff --git a/Documentation/devicetree/bindings/serial/rda-uart.txt b/Documentation/devicetree/bindings/serial/rda-uart.txt
>> new file mode 100644
>> index 000000000000..6840a8aee035
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/serial/rda-uart.txt
>> @@ -0,0 +1,13 @@
>> +RDA Micro UART
>> +
>> +Required properties:
>> +- compatible :  "rda,8810pl-uart" for RDA8810PL
>> +- reg        :  Offset and length of the register set for the device.
> 
> No clocks or interrupts?

Not yet. I've only pieced together an earlycon driver so far, no full
serial driver. The .dtsi doesn't even have an interrupt-controller node
yet - wasn't clear to me whether this SoC even has a GIC and, if so,
where, from the downstream pre-DT code.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v6 00/10] serial/gpio: exar: Fixes and support for IOT2000
From: Linus Walleij @ 2017-06-29 22:13 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Jan Kiszka, Alexandre Courbot, Linux Kernel Mailing List,
	linux-serial@vger.kernel.org, linux-gpio@vger.kernel.org,
	Sudip Mukherjee, Andy Shevchenko, Sascha Weisenberger
In-Reply-To: <20170629144940.GD23512@kroah.com>

On Thu, Jun 29, 2017 at 4:49 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Thu, Jun 29, 2017 at 11:51:08AM +0200, Linus Walleij wrote:
>> On Fri, Jun 23, 2017 at 10:09 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> > On 2017-06-21 08:29, Jan Kiszka wrote:
>> >> On 2017-06-20 13:38, Linus Walleij wrote:
>> >>> On Tue, Jun 20, 2017 at 10:54 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> >>>> On 2017-06-20 10:19, Linus Walleij wrote:
>> >>>>> On Fri, Jun 9, 2017 at 8:33 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> >>>>>
>> >>>>>> This makes the gpio-exar driver usable, which was prevented by a number
>> >>>>>> of fatal bugs, and adds support for the SIMATIC IOT2040 to the 8250-exar
>> >>>>>> driver and, indirectly, to gpio-exar as well. It's a cross-subsystem
>> >>>>>> series, so I'm also cross-posting to the serial and gpio lists.
>> >>>>>>
>> >>>>>> Changes in v6:
>> >>>>>
>> >>>>> I merged some of the patches, that applied. Let's see if they survive
>> >>>>> in linux-next, else I guess we need to fix this in the -rcs or for the next
>> >>>>> kernel cycle.
>> >>>>
>> >>>> Weird that things did not apply. I just did a cherry-pick for all those
>> >>>> 10 patches on top of 5c996b7eb52c, and that went smoothly. Please let me
>> >>>> know which baseline is needed, and I will rebase.
>> >>>
>> >>> This was on the "devel" branch of my GPIO tree:
>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel
>> >>
>> >> Again, all (missing) patches applied absolutely cleanly for me, see
>> >>
>> >> http://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/gpio-iot2000
>> >
>> > I've rebased over devel and noticed along this that you will have to
>> > include "serial: uapi: Add support for bus termination" from Greg's
>> > tty-next for the last patch to avoid breaking the build. Result pushed to
>> >
>> > http://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/gpio-iot2000
>> >
>> > If you want me to resend anything, just let me know. Would be great to
>> > have the remaining pieces lined up in time for the next merge window.
>>
>> I could just pull it in, but then I want a clear indication that Greg and
>> say Andy are happy with this.
>>
>> The serial patches are missing Gregs explicit ACK and the platform
>> patch could use Andy's ACK. The last patch adding the
>> IOT2040 is so obviously out of my GPIO territory that I want
>> Greg 100% aligned with this.
>>
>> I am sorry that it is troublesome when things cross subsystem
>> boundaries, I already stretched it a bit with the things I queued
>> up because it annoys me too, but this is the process we have :/
>
> I've added my acks to the serial patches, so all should be fine for you
> to take this all through your tree now.

Awesome, Jan can you:

- Collect the ACKs

- Send me a pull request based on my devel branch?

Yours,
Linus Walleij

^ permalink raw reply

* Re: [PATCH 4/6] dt-bindings: serial: Document RDA Micro UART
From: Rob Herring @ 2017-06-29 20:10 UTC (permalink / raw)
  To: Andreas Färber
  Cc: linux-arm-kernel, linux-kernel, service, zhao_steven,
	Greg Kroah-Hartman, Mark Rutland, linux-serial, devicetree
In-Reply-To: <20170627005520.23731-5-afaerber@suse.de>

On Tue, Jun 27, 2017 at 02:55:18AM +0200, Andreas Färber wrote:
> Add an initial binding for the RDA8810PL UART.
> 
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> ---
>  Documentation/devicetree/bindings/serial/rda-uart.txt | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/serial/rda-uart.txt
> 
> diff --git a/Documentation/devicetree/bindings/serial/rda-uart.txt b/Documentation/devicetree/bindings/serial/rda-uart.txt
> new file mode 100644
> index 000000000000..6840a8aee035
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/rda-uart.txt
> @@ -0,0 +1,13 @@
> +RDA Micro UART
> +
> +Required properties:
> +- compatible :  "rda,8810pl-uart" for RDA8810PL
> +- reg        :  Offset and length of the register set for the device.

No clocks or interrupts?

Rob

^ permalink raw reply

* Re: Moxa UPort 1150 and RS-422/485… what's the "proper" way to switch modes
From: Alan Cox @ 2017-06-29 19:50 UTC (permalink / raw)
  To: Johan Hovold
  Cc: Oliver Neukum, Stuart Longland,
	linux-serial-u79uwXL29TY76Z2rM5mHXA,
	linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170628153439.GC17630@localhost>

So IMHO there are two cases

1. The configuration is fixed in the hardware - in which case we should
automatically set it in kernel, or from device tree.

2. The configuration is soft - in which case you need an ioctl you can
use on the port to change it - irrespective of whether sysfs also handles
it. For simple permissions reasons and also to avoid races you need that
ioctl.

We intentionally have lots of spare space left to extend the RS485 ioctl,
and we have termiox which contains even more room and historically in
other Unixen dealt with all sorts of weird and wonderful parameters used
on stuff like synchronous ports.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v3 9/9] of: document rs485 bindings for Atmel USART, Freescale UARTs and OMAP UART
From: Uwe Kleine-König @ 2017-06-29 18:53 UTC (permalink / raw)
  To: Rob Herring
  Cc: linux-serial-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <20170628180400.h7yxrprhr44wncgs@rob-hp-laptop>

On Wed, Jun 28, 2017 at 01:04:00PM -0500, Rob Herring wrote:
> On Mon, Jun 26, 2017 at 11:08:03AM +0200, Uwe Kleine-König wrote:
> > The drivers support the rs485 binding described in rs485.txt, this commit
> > just makes that explicit.
> 
> "dt-bindings: serial: ..." for the subject if you respin the series. 

Done, I shortend the first line a bit, it now looks as follows:

	dt-bindings: serial: document rs485 bindings for various devices

	Atmel USART, Freescale UARTs and OMAP UART all support the rs485 binding 
	described in rs485.txt, this commit just makes that explicit.

	Acked-by: Nicolas Ferre <nicolas.ferre-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
	Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
	Signed-off-by: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v3 0/9] Add and make use of a common rs485 device tree parsing function
From: Uwe Kleine-König @ 2017-06-29 18:47 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-serial-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <20170629151200.GA16362-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>

Hello Greg,

On Thu, Jun 29, 2017 at 05:12:00PM +0200, Greg KH wrote:
> On Mon, Jun 26, 2017 at 11:07:54AM +0200, Uwe Kleine-König wrote:
> > this is v3 of the series that targets to consolidate parsing the rs485 specific
> > dt properties in a single place.
> 
> This patch breaks the build, and not all of them applied properly :(

sigh :( Sorry for the build breaker.

Regarding "doesn't apply": I tested to rebase on next/master (and so
tty-next) and it applies there just fine. I considered that good enough.
I guess you're talking about tty-testing?! I suggest to mention the
branch name you want to apply patches on in such mails.

There is a patch you applied on tty-testing that is not ok I think
("serial: imx-serial - move DMA buffer configuration to DT"). I
commented this one in the respective thread now.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH] serial: imx-serial - move DMA buffer configuration to DT
From: Uwe Kleine-König @ 2017-06-29 18:26 UTC (permalink / raw)
  To: Romain Perier
  Cc: Greg Kroah-Hartman, Jiri Slaby,
	linux-serial-u79uwXL29TY76Z2rM5mHXA, Nandor Han,
	devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170628101514.22610-1-romain.perier-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>

Hello,

Cc: += devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org

On Wed, Jun 28, 2017 at 12:15:14PM +0200, Romain Perier wrote:
> From: Nandor Han <nandor.han-JJi787mZWgc@public.gmane.org>
> 
> The size of the DMA buffer can affect the delta time between data being
> produced and data being consumed. Basically the DMA system will move
> data to tty buffer when a) DMA buffer is full b) serial line is idle.
> The situation is visible when producer generates data continuously and
> there is no possibility for idle line. At this point the DMA buffer is
> directly affecting the delta time.

This doesn't look like a hw property but a configuration item. Also I
don't understand the problematic case. The i.MX is sending continuously
and then doesn't receive bytes until the DMA buffer is full? What is the
DMA buffer? You don't mean the FIFO here, do you?

That doesn't sound like a good fix but more like a work around. Which
other options did you test to fix your problem?

> The patch will add the possibility to configure the DMA buffers in DT,
> which case by case can be configured separately for every driver
> instance. The DT configuration is optional and in case missing the
> driver will use the 4096 buffer with 4 periods (as before), therefore no
> clients are impacted by this change.
> 
> Signed-off-by: Nandor Han <nandor.han-JJi787mZWgc@public.gmane.org>
> Signed-off-by: Romain Perier <romain.perier-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> ---
>  .../devicetree/bindings/serial/fsl-imx-uart.txt    |  2 ++
>  drivers/tty/serial/imx.c                           | 25 +++++++++++++++-------
>  2 files changed, 19 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt b/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt
> index 574c3a2..e6b5724 100644
> --- a/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt
> +++ b/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt
> @@ -9,6 +9,7 @@ Optional properties:
>  - fsl,irda-mode : Indicate the uart supports irda mode
>  - fsl,dte-mode : Indicate the uart works in DTE mode. The uart works
>                    in DCE mode by default.
> +- fsl,dma-size : Indicate the size of the DMA buffer and its periods

This is a sparse description, just from reading that I don't understand
what it does.
 
>  Please check Documentation/devicetree/bindings/serial/serial.txt
>  for the complete list of generic properties.
> @@ -28,4 +29,5 @@ uart1: serial@73fbc000 {
>  	interrupts = <31>;
>  	uart-has-rtscts;
>  	fsl,dte-mode;
> +	fsl,dma-size = <1024 4>;
>  };
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index bbefddd..7327477 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -186,6 +186,11 @@
>  
>  #define UART_NR 8
>  
> +/* RX DMA buffer periods */
> +#define RX_DMA_PERIODS 4
> +#define RX_BUF_SIZE	(PAGE_SIZE)

These names should include "DEFAULT" in their name now to fit their new
semantic.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH RESEND] serial: imx: Enable RTSD only when needed
From: Uwe Kleine-König @ 2017-06-29 18:18 UTC (permalink / raw)
  To: Romain Perier
  Cc: Greg Kroah-Hartman, linux-arm-kernel, linux-serial, Nandor Han
In-Reply-To: <20170628135936.30537-1-romain.perier@collabora.com>

Hello,

On Wed, Jun 28, 2017 at 03:59:36PM +0200, Romain Perier wrote:
> +	temp |= UCR1_RRDYEN | UCR1_UARTEN;
> +	if (sport->have_rtscts)
> +			temp |= UCR1_RTSDEN;

There is a tab too much.
 
>  	writel(temp, sport->port.membase + UCR1);

Other than that:
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply

* Re: [PATCH v3 0/9] Add and make use of a common rs485 device tree parsing function
From: Greg KH @ 2017-06-29 15:12 UTC (permalink / raw)
  To: Uwe Kleine-König; +Cc: kernel, devicetree, linux-arm-kernel, linux-serial
In-Reply-To: <20170626090803.10981-1-u.kleine-koenig@pengutronix.de>

On Mon, Jun 26, 2017 at 11:07:54AM +0200, Uwe Kleine-König wrote:
> Hello,
> 
> this is v3 of the series that targets to consolidate parsing the rs485 specific
> dt properties in a single place.

This patch breaks the build, and not all of them applied properly :(

Please be more careful when you fix this up and resend...

thanks,

greg k-h

^ permalink raw reply

* Re: [PATCH 00/20] Update STM32 usart driver
From: Alexandre Torgue @ 2017-06-29 15:09 UTC (permalink / raw)
  To: Bich HEMON, Greg Kroah-Hartman, Rob Herring, Mark Rutland,
	Maxime Coquelin, Jiri Slaby,
	linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1498481318-1894-1-git-send-email-bich.hemon-qxv4g6HH51o@public.gmane.org>

Greg, Rob

On 06/26/2017 02:49 PM, Bich HEMON wrote:
> From: Bich Hemon <bich.hemon-qxv4g6HH51o@public.gmane.org>
> 
> This patchset updates the stm32 usart driver. It mainly adds
> support for fifo, dma, debugfs anf fixes various bugs.
> 
> Bich Hemon (20):
>    serial: stm32: adding fifo support
>    dt-bindings: serial: each stm32 usart needs an alias
>    serial: stm32: fix multi ports management
>    serial: stm32: make fifoen as property for each port
>    serial: stm32: add debugfs
>    serial: stm32: fix pio transmit timeout
>    serial: stm32: less messages on dma alloc error
>    serial: stm32: timeout interrupt using with dma
>    serial: stm32: fix end of transfer
>    serial: stm32: fix dma receive
>    serial: stm32: add RTS support
>    serial: stm32: fix last_res value
>    serial: stm32: fix error handling in probe
>    dt-bindings: serial: document option wake-up interrupt for STM32 USART
>    serial: stm32: Add wakeup mechanism
>    serial: stm32: fix fifo usage
>    dt-bindings: serial: stm32: add dma using note
>    serial: stm32: update dma buffers length
>    serial: stm32: add dma rx callback
>    serial: stm32: fix rx interrupt handling in startup
> 
>   .../devicetree/bindings/serial/st,stm32-usart.txt  |  55 +++-
>   drivers/tty/serial/stm32-usart.c                   | 310 ++++++++++++++++++---
>   drivers/tty/serial/stm32-usart.h                   |  51 +++-
>   3 files changed, 375 insertions(+), 41 deletions(-)
> 

This series have been abandoned (maybe not in correct way). Don't waste 
your time with that. New patches will be sent in several series and 
patches will be reworked.

Thanks
Alex


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 13/20] serial: stm32: fix error handling in probe
From: Greg Kroah-Hartman @ 2017-06-29 14:50 UTC (permalink / raw)
  To: Bich HEMON
  Cc: Rob Herring, Mark Rutland, Maxime Coquelin, Alexandre TORGUE,
	Jiri Slaby, linux-serial@vger.kernel.org,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
In-Reply-To: <1498481318-1894-14-git-send-email-bich.hemon@st.com>

On Mon, Jun 26, 2017 at 12:49:14PM +0000, Bich HEMON wrote:
> From: Bich Hemon <bich.hemon@st.com>
> 
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>

Again, no changelog == no patch applied.

Please fix this, and the signed-off-by issues for all of these patches
for your next revision of this patchset.

thanks,

greg k-h

^ permalink raw reply

* Re: [PATCH 14/20] dt-bindings: serial: document option wake-up interrupt for STM32 USART
From: Greg Kroah-Hartman @ 2017-06-29 14:50 UTC (permalink / raw)
  To: Bich HEMON
  Cc: Rob Herring, Mark Rutland, Maxime Coquelin, Alexandre TORGUE,
	Jiri Slaby, linux-serial@vger.kernel.org,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
In-Reply-To: <1498481318-1894-15-git-send-email-bich.hemon@st.com>

On Mon, Jun 26, 2017 at 12:49:15PM +0000, Bich HEMON wrote:
> From: Bich Hemon <bich.hemon@st.com>
> 
> Introduce new compatibles for "st,stm32h7-usart" and "st,stm32h7-uart".
> This new compatible allow to use optional wake-up interrupt.
> 
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>

No sign-off from you?

^ permalink raw reply

* Re: [PATCH 17/20] dt-bindings: serial: stm32: add dma using note
From: Greg Kroah-Hartman @ 2017-06-29 14:50 UTC (permalink / raw)
  To: Bich HEMON
  Cc: Rob Herring, Mark Rutland, Maxime Coquelin, Alexandre TORGUE,
	Jiri Slaby, linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1498481318-1894-18-git-send-email-bich.hemon-qxv4g6HH51o@public.gmane.org>

On Mon, Jun 26, 2017 at 12:49:16PM +0000, Bich HEMON wrote:
> From: Bich Hemon <bich.hemon-qxv4g6HH51o@public.gmane.org>
> 
> Signed-off-by: Gerald Baeza <gerald.baeza-qxv4g6HH51o@public.gmane.org>

I can't take patches without any changelog text at all, sorry.

Also, you didn't sign off on this?  Why not???
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v6 00/10] serial/gpio: exar: Fixes and support for IOT2000
From: Greg Kroah-Hartman @ 2017-06-29 14:49 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Jan Kiszka, Alexandre Courbot, Linux Kernel Mailing List,
	linux-serial@vger.kernel.org, linux-gpio@vger.kernel.org,
	Sudip Mukherjee, Andy Shevchenko, Sascha Weisenberger
In-Reply-To: <CACRpkdZ1atVQLuDio6PVk4Xg+DUBDt2F2OH+2UjVkue8rKNbcA@mail.gmail.com>

On Thu, Jun 29, 2017 at 11:51:08AM +0200, Linus Walleij wrote:
> On Fri, Jun 23, 2017 at 10:09 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> > On 2017-06-21 08:29, Jan Kiszka wrote:
> >> On 2017-06-20 13:38, Linus Walleij wrote:
> >>> On Tue, Jun 20, 2017 at 10:54 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>> On 2017-06-20 10:19, Linus Walleij wrote:
> >>>>> On Fri, Jun 9, 2017 at 8:33 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>>
> >>>>>> This makes the gpio-exar driver usable, which was prevented by a number
> >>>>>> of fatal bugs, and adds support for the SIMATIC IOT2040 to the 8250-exar
> >>>>>> driver and, indirectly, to gpio-exar as well. It's a cross-subsystem
> >>>>>> series, so I'm also cross-posting to the serial and gpio lists.
> >>>>>>
> >>>>>> Changes in v6:
> >>>>>
> >>>>> I merged some of the patches, that applied. Let's see if they survive
> >>>>> in linux-next, else I guess we need to fix this in the -rcs or for the next
> >>>>> kernel cycle.
> >>>>
> >>>> Weird that things did not apply. I just did a cherry-pick for all those
> >>>> 10 patches on top of 5c996b7eb52c, and that went smoothly. Please let me
> >>>> know which baseline is needed, and I will rebase.
> >>>
> >>> This was on the "devel" branch of my GPIO tree:
> >>> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel
> >>
> >> Again, all (missing) patches applied absolutely cleanly for me, see
> >>
> >> http://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/gpio-iot2000
> >
> > I've rebased over devel and noticed along this that you will have to
> > include "serial: uapi: Add support for bus termination" from Greg's
> > tty-next for the last patch to avoid breaking the build. Result pushed to
> >
> > http://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/gpio-iot2000
> >
> > If you want me to resend anything, just let me know. Would be great to
> > have the remaining pieces lined up in time for the next merge window.
> 
> I could just pull it in, but then I want a clear indication that Greg and
> say Andy are happy with this.
> 
> The serial patches are missing Gregs explicit ACK and the platform
> patch could use Andy's ACK. The last patch adding the
> IOT2040 is so obviously out of my GPIO territory that I want
> Greg 100% aligned with this.
> 
> I am sorry that it is troublesome when things cross subsystem
> boundaries, I already stretched it a bit with the things I queued
> up because it annoys me too, but this is the process we have :/

I've added my acks to the serial patches, so all should be fine for you
to take this all through your tree now.

thanks,

greg k-h

^ permalink raw reply

* Re: [PATCH v6 10/10] serial: exar: Add support for IOT2040 device
From: Greg Kroah-Hartman @ 2017-06-29 14:49 UTC (permalink / raw)
  To: Jan Kiszka
  Cc: Linus Walleij, Alexandre Courbot, Linux Kernel Mailing List,
	linux-serial, linux-gpio, Sudip Mukherjee, Andy Shevchenko,
	Sascha Weisenberger
In-Reply-To: <47c8206a1f97b6c987dfb8761805317406ab1a34.1497033197.git.jan.kiszka@siemens.com>

On Fri, Jun 09, 2017 at 08:33:18PM +0200, Jan Kiszka wrote:
> This implements the setup of RS232 and the switch-over to RS485 or RS422
> for the Siemens IOT2040. That uses an EXAR XR17V352 with external logic
> to switch between the different modes. The external logic is controlled
> via MPIO pins of the EXAR controller.
> 
> Only pin 10 can be exported as GPIO on the IOT2040. It is connected to
> an LED.
> 
> As the XR17V352 used on the IOT2040 is not equipped with an external
> EEPROM, it cannot present itself as IOT2040-variant via subvendor/
> subdevice IDs. Thus, we have to check via DMI for the target platform.
> 
> Co-developed with Sascha Weisenberger.
> 
> Signed-off-by: Sascha Weisenberger <sascha.weisenberger@siemens.com>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

^ permalink raw reply

* Re: [PATCH v6 01/10] gpio-exar/8250-exar: Do not even instantiate a GPIO device for Commtech cards
From: Greg Kroah-Hartman @ 2017-06-29 14:48 UTC (permalink / raw)
  To: Jan Kiszka
  Cc: Linus Walleij, Alexandre Courbot, Linux Kernel Mailing List,
	linux-serial, linux-gpio, Sudip Mukherjee, Andy Shevchenko,
	Sascha Weisenberger
In-Reply-To: <4c5f5a761255c584e57fb96e35021104367616e5.1497033197.git.jan.kiszka@siemens.com>

On Fri, Jun 09, 2017 at 08:33:09PM +0200, Jan Kiszka wrote:
> Commtech adapters need the MPIOs for internal purposes, and the
> gpio-exar driver already refused to pick them up. But there is actually
> no point in even creating the underlying platform device.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

^ permalink raw reply

* Re: [PATCH v6 07/10] serial: exar: Factor out platform hooks
From: Greg Kroah-Hartman @ 2017-06-29 14:48 UTC (permalink / raw)
  To: Jan Kiszka
  Cc: Linus Walleij, Alexandre Courbot, Linux Kernel Mailing List,
	linux-serial, linux-gpio, Sudip Mukherjee, Andy Shevchenko,
	Sascha Weisenberger
In-Reply-To: <8baf62a96105a2d8f84a73f887e55f6d86b7cae4.1497033197.git.jan.kiszka@siemens.com>

On Fri, Jun 09, 2017 at 08:33:15PM +0200, Jan Kiszka wrote:
> This prepares the addition of IOT2040 platform support by preparing the
> needed setup and rs485_config hooks.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

^ permalink raw reply

* Re: [PATCH v6 00/10] serial/gpio: exar: Fixes and support for IOT2000
From: Andy Shevchenko @ 2017-06-29 11:43 UTC (permalink / raw)
  To: Linus Walleij, Mika Westerberg
  Cc: Jan Kiszka, Greg Kroah-Hartman, Linux Kernel Mailing List,
	linux-serial@vger.kernel.org, linux-gpio@vger.kernel.org,
	Sudip Mukherjee, Sascha Weisenberger
In-Reply-To: <CACRpkdZ1atVQLuDio6PVk4Xg+DUBDt2F2OH+2UjVkue8rKNbcA@mail.gmail.com>

On Thu, Jun 29, 2017 at 12:51 PM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> On Fri, Jun 23, 2017 at 10:09 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> On 2017-06-21 08:29, Jan Kiszka wrote:

>> http://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/gpio-iot2000
>>
>> If you want me to resend anything, just let me know. Would be great to
>> have the remaining pieces lined up in time for the next merge window.
>
> I could just pull it in, but then I want a clear indication that Greg and
> say Andy are happy with this.

All patches that have my tag already are good from my point of view.
The rest, i.e.
"platform: Accept const properties", needs a slightly more attention.

This one on one hand does the right thing, though I would like to hear
Mika on this.

We still have platform_device_info and mfd_cell that doesn't define
the properties with const.
(I believe they should, though is it matter of this patch?)

P.S. I have looked at the current state of the use of the API in
question and rather agree with the patch, thus

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply

* Re: [PATCH v6 00/10] serial/gpio: exar: Fixes and support for IOT2000
From: Linus Walleij @ 2017-06-29  9:51 UTC (permalink / raw)
  To: Jan Kiszka
  Cc: Alexandre Courbot, Greg Kroah-Hartman, Linux Kernel Mailing List,
	linux-serial@vger.kernel.org, linux-gpio@vger.kernel.org,
	Sudip Mukherjee, Andy Shevchenko, Sascha Weisenberger
In-Reply-To: <d52a1a65-842c-9c73-17f7-5574fcefab2a@siemens.com>

On Fri, Jun 23, 2017 at 10:09 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 2017-06-21 08:29, Jan Kiszka wrote:
>> On 2017-06-20 13:38, Linus Walleij wrote:
>>> On Tue, Jun 20, 2017 at 10:54 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>> On 2017-06-20 10:19, Linus Walleij wrote:
>>>>> On Fri, Jun 9, 2017 at 8:33 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>
>>>>>> This makes the gpio-exar driver usable, which was prevented by a number
>>>>>> of fatal bugs, and adds support for the SIMATIC IOT2040 to the 8250-exar
>>>>>> driver and, indirectly, to gpio-exar as well. It's a cross-subsystem
>>>>>> series, so I'm also cross-posting to the serial and gpio lists.
>>>>>>
>>>>>> Changes in v6:
>>>>>
>>>>> I merged some of the patches, that applied. Let's see if they survive
>>>>> in linux-next, else I guess we need to fix this in the -rcs or for the next
>>>>> kernel cycle.
>>>>
>>>> Weird that things did not apply. I just did a cherry-pick for all those
>>>> 10 patches on top of 5c996b7eb52c, and that went smoothly. Please let me
>>>> know which baseline is needed, and I will rebase.
>>>
>>> This was on the "devel" branch of my GPIO tree:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel
>>
>> Again, all (missing) patches applied absolutely cleanly for me, see
>>
>> http://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/gpio-iot2000
>
> I've rebased over devel and noticed along this that you will have to
> include "serial: uapi: Add support for bus termination" from Greg's
> tty-next for the last patch to avoid breaking the build. Result pushed to
>
> http://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/gpio-iot2000
>
> If you want me to resend anything, just let me know. Would be great to
> have the remaining pieces lined up in time for the next merge window.

I could just pull it in, but then I want a clear indication that Greg and
say Andy are happy with this.

The serial patches are missing Gregs explicit ACK and the platform
patch could use Andy's ACK. The last patch adding the
IOT2040 is so obviously out of my GPIO territory that I want
Greg 100% aligned with this.

I am sorry that it is troublesome when things cross subsystem
boundaries, I already stretched it a bit with the things I queued
up because it annoys me too, but this is the process we have :/

Yours,
Linus Walleij

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox