* Re: [PATCH 17/24] dt-bindings: wdog: mtk-wdt: add support for MT851
From: Rob Herring @ 2019-03-28 19:13 UTC (permalink / raw)
To: Fabien Parent
Cc: Matthias Brugger, Mark Rutland, Sean Wang, Ryder Lee,
Hsin-Hsiung Wang, Wenzhen Yu, Chaotian Jing, Yong Mao, jjian.zhou,
devicetree, linux-kernel@vger.kernel.org, Linux I2C,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/Mediatek SoC support, linux-mmc,
open list:GPIO SUBSYSTEM, SE
In-Reply-To: <20190323211612.860-18-fparent@baylibre.com>
On Sat, Mar 23, 2019 at 4:17 PM Fabien Parent <fparent@baylibre.com> wrote:
>
> Add binding documentation of mtk-wdt for MT8516 SoC.
>
> Signed-off-by: Fabien Parent <fparent@baylibre.com>
> ---
> Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 22/24] dt-bindings: i2c: i2c-mtk: add support for MT8516
From: Rob Herring @ 2019-03-28 19:13 UTC (permalink / raw)
To: Fabien Parent
Cc: Matthias Brugger, Mark Rutland, Sean Wang, Ryder Lee,
Hsin-Hsiung Wang, Wenzhen Yu, Chaotian Jing, Yong Mao, jjian.zhou,
devicetree, linux-kernel@vger.kernel.org, Linux I2C,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/Mediatek SoC support, linux-mmc,
open list:GPIO SUBSYSTEM, SE
In-Reply-To: <20190323211612.860-23-fparent@baylibre.com>
On Sat, Mar 23, 2019 at 4:17 PM Fabien Parent <fparent@baylibre.com> wrote:
>
> Add binding documentation of i2c-mtk for MT8516 SoC.
>
> Signed-off-by: Fabien Parent <fparent@baylibre.com>
> ---
> Documentation/devicetree/bindings/i2c/i2c-mtk.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 21/24] dt-bindings: irq: mtk,sysirq: add support for MT8516
From: Rob Herring @ 2019-03-28 19:13 UTC (permalink / raw)
To: Fabien Parent
Cc: Matthias Brugger, Mark Rutland, Sean Wang, Ryder Lee,
Hsin-Hsiung Wang, Wenzhen Yu, Chaotian Jing, Yong Mao, jjian.zhou,
devicetree, linux-kernel@vger.kernel.org, Linux I2C,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/Mediatek SoC support, linux-mmc,
open list:GPIO SUBSYSTEM, SE
In-Reply-To: <20190323211612.860-22-fparent@baylibre.com>
On Sat, Mar 23, 2019 at 4:17 PM Fabien Parent <fparent@baylibre.com> wrote:
>
> Add binding documentation of mediatek,sysirq for MT8516 SoC.
>
> Signed-off-by: Fabien Parent <fparent@baylibre.com>
> ---
> .../bindings/interrupt-controller/mediatek,sysirq.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 20/24] dt-bindings: serial: mtk-uart: add support for MT8516
From: Rob Herring @ 2019-03-28 19:12 UTC (permalink / raw)
To: Fabien Parent
Cc: Matthias Brugger, Mark Rutland, Sean Wang, Ryder Lee,
Hsin-Hsiung Wang, Wenzhen Yu, Chaotian Jing, Yong Mao, jjian.zhou,
devicetree, linux-kernel@vger.kernel.org, Linux I2C,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/Mediatek SoC support, linux-mmc,
open list:GPIO SUBSYSTEM, SE
In-Reply-To: <20190323211612.860-21-fparent@baylibre.com>
On Sat, Mar 23, 2019 at 4:17 PM Fabien Parent <fparent@baylibre.com> wrote:
>
> Add binding documentation of mtk-uart for MT8516 SoC.
>
> Signed-off-by: Fabien Parent <fparent@baylibre.com>
> ---
> Documentation/devicetree/bindings/serial/mtk-uart.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 19/24] dt-bindings: spi: spi-mt65xx: add support for MT8516
From: Rob Herring @ 2019-03-28 19:12 UTC (permalink / raw)
To: Fabien Parent
Cc: Matthias Brugger, Mark Rutland, Sean Wang, Ryder Lee,
Hsin-Hsiung Wang, Wenzhen Yu, Chaotian Jing, Yong Mao, jjian.zhou,
devicetree, linux-kernel@vger.kernel.org, Linux I2C,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/Mediatek SoC support, linux-mmc,
open list:GPIO SUBSYSTEM, SE
In-Reply-To: <20190323211612.860-20-fparent@baylibre.com>
On Sat, Mar 23, 2019 at 4:17 PM Fabien Parent <fparent@baylibre.com> wrote:
>
> Add binding documentation of spi-mt65xx for MT8516 SoC.
>
> Signed-off-by: Fabien Parent <fparent@baylibre.com>
> ---
> Documentation/devicetree/bindings/spi/spi-mt65xx.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 18/24] dt-bindings: timer: mtk-timer: add support for MT8516
From: Rob Herring @ 2019-03-28 19:12 UTC (permalink / raw)
To: Fabien Parent
Cc: Matthias Brugger, Mark Rutland, Sean Wang, Ryder Lee,
Hsin-Hsiung Wang, Wenzhen Yu, Chaotian Jing, Yong Mao, jjian.zhou,
devicetree, linux-kernel@vger.kernel.org, Linux I2C,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/Mediatek SoC support, linux-mmc,
open list:GPIO SUBSYSTEM, SE
In-Reply-To: <20190323211612.860-19-fparent@baylibre.com>
On Sat, Mar 23, 2019 at 4:17 PM Fabien Parent <fparent@baylibre.com> wrote:
>
> Add binding documentation of mtk-timer for MT8516 SoC.
>
> Signed-off-by: Fabien Parent <fparent@baylibre.com>
> ---
> Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 15/24] dt-bindings: pinctrl: pinctrl-mt65xx: add support for MT8516
From: Rob Herring @ 2019-03-28 19:11 UTC (permalink / raw)
To: Fabien Parent
Cc: Mark Rutland, devicetree, Ryder Lee, LINUX-WATCHDOG, jjian.zhou,
Wenzhen Yu,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
stephane.leprovost, Sean Wang, linux-mmc,
linux-kernel@vger.kernel.org, Yong Mao, linux-spi,
open list:GPIO SUBSYSTEM, moderated list:ARM/Mediatek SoC support,
Chaotian Jing, open list:SERIAL DRIVERS, Matthias Brugger,
linux-clk, Hsin-H
In-Reply-To: <20190323211612.860-16-fparent@baylibre.com>
On Sat, Mar 23, 2019 at 4:17 PM Fabien Parent <fparent@baylibre.com> wrote:
>
> Add binding documentation of pinctrl-mt65xx for MT8516 SoC.
>
> Signed-off-by: Fabien Parent <fparent@baylibre.com>
> ---
> Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 13/24] dt-bindings: mediatek: apmixedsys: add support for MT8516
From: Rob Herring @ 2019-03-28 19:11 UTC (permalink / raw)
To: Fabien Parent
Cc: Matthias Brugger, Mark Rutland, Sean Wang, Ryder Lee,
Hsin-Hsiung Wang, Wenzhen Yu, Chaotian Jing, Yong Mao, jjian.zhou,
devicetree, linux-kernel@vger.kernel.org, Linux I2C,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/Mediatek SoC support, linux-mmc,
open list:GPIO SUBSYSTEM, SE
In-Reply-To: <20190323211612.860-14-fparent@baylibre.com>
On Sat, Mar 23, 2019 at 4:17 PM Fabien Parent <fparent@baylibre.com> wrote:
>
> Add binding documentation of apmixedsys for MT8516 SoC.
>
> Signed-off-by: Fabien Parent <fparent@baylibre.com>
> ---
> .../bindings/arm/mediatek/mediatek,apmixedsys.txt | 1 +
> include/dt-bindings/clock/mt8516-clk.h | 10 ++++++++++
> 2 files changed, 11 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 12/24] dt-bindings: mediatek: infracfg: add support for MT8516
From: Rob Herring @ 2019-03-28 19:10 UTC (permalink / raw)
To: Fabien Parent
Cc: Mark Rutland, devicetree, Ryder Lee, LINUX-WATCHDOG, jjian.zhou,
Wenzhen Yu,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
stephane.leprovost, Sean Wang, linux-mmc,
linux-kernel@vger.kernel.org, Yong Mao, linux-spi,
open list:GPIO SUBSYSTEM, moderated list:ARM/Mediatek SoC support,
Chaotian Jing, open list:SERIAL DRIVERS, Matthias Brugger,
linux-clk, Hsin-H
In-Reply-To: <20190323211612.860-13-fparent@baylibre.com>
On Sat, Mar 23, 2019 at 4:17 PM Fabien Parent <fparent@baylibre.com> wrote:
>
> Add binding documentation of infracfg for MT8516 SoC.
>
> Signed-off-by: Fabien Parent <fparent@baylibre.com>
> ---
> .../bindings/arm/mediatek/mediatek,infracfg.txt | 1 +
> include/dt-bindings/clock/mt8516-clk.h | 9 +++++++++
> 2 files changed, 10 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 11/24] dt-bindings: mediatek: topckgen: add support for MT8516
From: Rob Herring @ 2019-03-28 19:09 UTC (permalink / raw)
To: Fabien Parent
Cc: Matthias Brugger, Mark Rutland, Sean Wang, Ryder Lee,
Hsin-Hsiung Wang, Wenzhen Yu, Chaotian Jing, Yong Mao, jjian.zhou,
devicetree, linux-kernel@vger.kernel.org, Linux I2C,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/Mediatek SoC support, linux-mmc,
open list:GPIO SUBSYSTEM, SE
In-Reply-To: <20190323211612.860-12-fparent@baylibre.com>
On Sat, Mar 23, 2019 at 4:17 PM Fabien Parent <fparent@baylibre.com> wrote:
>
> Add binding documentation of topckgen for MT8516 SoC.
>
> Signed-off-by: Fabien Parent <fparent@baylibre.com>
> ---
> .../arm/mediatek/mediatek,topckgen.txt | 1 +
> include/dt-bindings/clock/mt8516-clk.h | 192 ++++++++++++++++++
> 2 files changed, 193 insertions(+)
> create mode 100644 include/dt-bindings/clock/mt8516-clk.h
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 03/24] dt-bindings: pwrap: mediatek: add pwrap support for MT8516
From: Rob Herring @ 2019-03-28 19:09 UTC (permalink / raw)
To: Fabien Parent
Cc: Matthias Brugger, Mark Rutland, Sean Wang, Ryder Lee,
Hsin-Hsiung Wang, Wenzhen Yu, Chaotian Jing, Yong Mao, jjian.zhou,
devicetree, linux-kernel@vger.kernel.org, Linux I2C,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/Mediatek SoC support, linux-mmc,
open list:GPIO SUBSYSTEM, SE
In-Reply-To: <20190323211612.860-4-fparent@baylibre.com>
On Sat, Mar 23, 2019 at 4:16 PM Fabien Parent <fparent@baylibre.com> wrote:
>
> Add binding documentation of pwrap for MT8516 SoCs.
>
> Signed-off-by: Fabien Parent <fparent@baylibre.com>
> ---
> Documentation/devicetree/bindings/soc/mediatek/pwrap.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] tty:serial_core: Spelling mistake
From: Mukesh Ojha @ 2019-03-28 6:30 UTC (permalink / raw)
To: Hariprasad Kelam, Greg Kroah-Hartman, Jiri Slaby,
open list:SERIAL DRIVERS, open list
In-Reply-To: <20190328031733.GA13375@hari-Inspiron-1545>
On 3/28/2019 8:47 AM, Hariprasad Kelam wrote:
> fix spelling mistake "overriden" -> "overridden"
>
> This fix resolves warning reported by checkpatch tool.
>
> Signed-off-by: Hariprasad Kelam <hariprasad.kelam@gmail.com>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
-Mukesh
> ---
> Changes in V2:
> -Make commit message more clear
> ---
> drivers/tty/serial/serial_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index 351843f..69f4871 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -1514,7 +1514,7 @@ static void uart_set_termios(struct tty_struct *tty,
> }
>
> uart_change_speed(tty, state, old_termios);
> - /* reload cflag from termios; port driver may have overriden flags */
> + /* reload cflag from termios; port driver may have overridden flags */
> cflag = tty->termios.c_cflag;
>
> /* Handle transition to B0 status */
^ permalink raw reply
* [PATCH v2] tty:serial_core: Spelling mistake
From: Hariprasad Kelam @ 2019-03-28 3:17 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, open list:SERIAL DRIVERS,
open list
fix spelling mistake "overriden" -> "overridden"
This fix resolves warning reported by checkpatch tool.
Signed-off-by: Hariprasad Kelam <hariprasad.kelam@gmail.com>
---
Changes in V2:
-Make commit message more clear
---
drivers/tty/serial/serial_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 351843f..69f4871 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1514,7 +1514,7 @@ static void uart_set_termios(struct tty_struct *tty,
}
uart_change_speed(tty, state, old_termios);
- /* reload cflag from termios; port driver may have overriden flags */
+ /* reload cflag from termios; port driver may have overridden flags */
cflag = tty->termios.c_cflag;
/* Handle transition to B0 status */
--
2.7.4
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 040/123] serial: 8250_pxa: honor the port number from devicetree
From: Sasha Levin @ 2019-03-27 18:15 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Lubomir Rintel, Greg Kroah-Hartman, Sasha Levin, linux-serial
In-Reply-To: <20190327181628.15899-1-sashal@kernel.org>
From: Lubomir Rintel <lkundrak@v3.sk>
[ Upstream commit fe9ed6d2483fda55465f32924fb15bce0fac3fac ]
Like the other OF-enabled drivers, use the port number from the firmware if
the devicetree specifies an alias:
aliases {
...
serial2 = &uart2; /* Should be ttyS2 */
}
This is how the deprecated pxa.c driver behaved, switching to 8250_pxa
messes up the numbering.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/serial/8250/8250_pxa.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_pxa.c b/drivers/tty/serial/8250/8250_pxa.c
index 4d68731af534..de1372ba24b1 100644
--- a/drivers/tty/serial/8250/8250_pxa.c
+++ b/drivers/tty/serial/8250/8250_pxa.c
@@ -118,6 +118,10 @@ static int serial_pxa_probe(struct platform_device *pdev)
if (ret)
return ret;
+ ret = of_alias_get_id(pdev->dev.of_node, "serial");
+ if (ret >= 0)
+ uart.port.line = ret;
+
uart.port.type = PORT_XSCALE;
uart.port.iotype = UPIO_MEM32;
uart.port.mapbase = mmres->start;
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 057/192] serial: 8250_pxa: honor the port number from devicetree
From: Sasha Levin @ 2019-03-27 18:08 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Lubomir Rintel, Greg Kroah-Hartman, Sasha Levin, linux-serial
In-Reply-To: <20190327181025.13507-1-sashal@kernel.org>
From: Lubomir Rintel <lkundrak@v3.sk>
[ Upstream commit fe9ed6d2483fda55465f32924fb15bce0fac3fac ]
Like the other OF-enabled drivers, use the port number from the firmware if
the devicetree specifies an alias:
aliases {
...
serial2 = &uart2; /* Should be ttyS2 */
}
This is how the deprecated pxa.c driver behaved, switching to 8250_pxa
messes up the numbering.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/serial/8250/8250_pxa.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_pxa.c b/drivers/tty/serial/8250/8250_pxa.c
index b9bcbe20a2be..c47188860e32 100644
--- a/drivers/tty/serial/8250/8250_pxa.c
+++ b/drivers/tty/serial/8250/8250_pxa.c
@@ -113,6 +113,10 @@ static int serial_pxa_probe(struct platform_device *pdev)
if (ret)
return ret;
+ ret = of_alias_get_id(pdev->dev.of_node, "serial");
+ if (ret >= 0)
+ uart.port.line = ret;
+
uart.port.type = PORT_XSCALE;
uart.port.iotype = UPIO_MEM32;
uart.port.mapbase = mmres->start;
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.0 082/262] serial: 8250_pxa: honor the port number from devicetree
From: Sasha Levin @ 2019-03-27 17:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Lubomir Rintel, Greg Kroah-Hartman, Sasha Levin, linux-serial
In-Reply-To: <20190327180158.10245-1-sashal@kernel.org>
From: Lubomir Rintel <lkundrak@v3.sk>
[ Upstream commit fe9ed6d2483fda55465f32924fb15bce0fac3fac ]
Like the other OF-enabled drivers, use the port number from the firmware if
the devicetree specifies an alias:
aliases {
...
serial2 = &uart2; /* Should be ttyS2 */
}
This is how the deprecated pxa.c driver behaved, switching to 8250_pxa
messes up the numbering.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/serial/8250/8250_pxa.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_pxa.c b/drivers/tty/serial/8250/8250_pxa.c
index b9bcbe20a2be..c47188860e32 100644
--- a/drivers/tty/serial/8250/8250_pxa.c
+++ b/drivers/tty/serial/8250/8250_pxa.c
@@ -113,6 +113,10 @@ static int serial_pxa_probe(struct platform_device *pdev)
if (ret)
return ret;
+ ret = of_alias_get_id(pdev->dev.of_node, "serial");
+ if (ret >= 0)
+ uart.port.line = ret;
+
uart.port.type = PORT_XSCALE;
uart.port.iotype = UPIO_MEM32;
uart.port.mapbase = mmres->start;
--
2.19.1
^ permalink raw reply related
* Re: [PATCH v2] tty/serial: Add a serial port simulator
From: Greg Kroah-Hartman @ 2019-03-27 15:44 UTC (permalink / raw)
To: minyard; +Cc: linux-serial, linux-kernel, Corey Minyard
In-Reply-To: <20190305171231.22133-1-minyard@acm.org>
On Tue, Mar 05, 2019 at 11:12:31AM -0600, minyard@acm.org wrote:
> From: Corey Minyard <cminyard@mvista.com>
>
> This creates simulated serial ports, both as echo devices and pipe
> devices. The driver reasonably approximates the serial port speed
> and simulates some modem control lines. It allows error injection
> and direct control of modem control lines.
I like this, thanks for doing it!
Minor nits below:
> +You can modify null modem and control the lines individually
> +through an interface in /sys/class/tty/ttyECHO<n>/ctrl,
> +/sys/class/tty/ttyPipeA<n>/ctrl, and
> +/sys/class/tty/ttyPipeB<n>/ctrl. The following may be written to
> +those files:
> +
> +[+-]nullmodem
> + enable/disable null modem
> +
> +[+-]cd
> + enable/disable Carrier Detect (no effect if +nullmodem)
> +
> +[+-]dsr
> + enable/disable Data Set Ready (no effect if +nullmodem)
> +
> +[+-]cts
> + enable/disable Clear To Send (no effect if +nullmodem)
> +
> +[+-]ring
> + enable/disable Ring
> +
> +frame
> + inject a frame error on the next byte
> +
> +parity
> + inject a parity error on the next byte
> +
> +overrun
> + inject an overrun error on the next byte
> +
> +The contents of the above files has the following format:
> +
> +tty[Echo|PipeA|PipeB]<n>
> + <mctrl values>
> +
> +where <mctrl values> is the modem control values above (not frame,
> +parity, or overrun) with the following added:
> +
> +[+-]dtr
> + value of the Data Terminal Ready
> +
> +[+-]rts
> + value of the Request To Send
> +
> +The above values are not settable through this interface, they are
> +set through the serial port interface itself.
> +
> +So, for instance, ttyEcho0 comes up in the following state::
> +
> + # cat /sys/class/tty/ttyEcho0/ctrl
> + ttyEcho0: +nullmodem -cd -dsr -cts -ring -dtr -rts
> +
> +If something connects, it will become::
> +
> + ttyEcho0: +nullmodem +cd +dsr +cts -ring +dtr +rts
> +
> +To enable ring::
> +
> + # echo "+ring" >/sys/class/tty/ttyEcho0/ctrl
> + # cat /sys/class/tty/ttyEcho0/ctrl
> + ttyEcho0: +nullmodem +cd +dsr +cts +ring +dtr +rts
> +
> +Now disable NULL modem and the CD line::
> +
> + # echo "-nullmodem -cd" >/sys/class/tty/ttyEcho0/ctrl
> + # cat /sys/class/tty/ttyEcho0/ctrl
> + ttyEcho0: -nullmodem -cd -dsr -cts +ring -dtr -rts
> +
> +Note that these settings are for the side you are modifying. So if
> +you set nullmodem on ttyPipeA0, that controls whether the DTR/RTS
> +lines from ttyPipeB0 affect ttyPipeA0. It doesn't affect ttyPipeB's
> +modem control lines.
All of the sysfs stuff needs to also go in Documentation/ABI to describe
your new files.
> +config SERIAL_SIMULATOR
> + tristate "Serial port simulator"
> + default n
n is the default, no need to say it again here.
> --- /dev/null
> +++ b/drivers/tty/serial/serialsim.c
> @@ -0,0 +1,1101 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/*
> + * serialsim - Emulate a serial device in a loopback and/or pipe
> + *
> + * See the docs for this for more details.
Pointer to the docs?
And no copyright notice? I don't object to it, but it is usually nice
to see.
> + *
> + */
> +
> +#include <linux/module.h>
> +#include <linux/moduleparam.h>
> +#include <linux/ioport.h>
> +#include <linux/init.h>
> +#include <linux/serial.h>
> +#include <linux/tty.h>
> +#include <linux/tty_flip.h>
> +#include <linux/device.h>
> +#include <linux/serial_core.h>
> +#include <linux/kthread.h>
> +#include <linux/hrtimer.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock.h>
> +#include <linux/ctype.h>
> +#include <linux/string.h>
> +#include <linux/uaccess.h>
> +
> +#include <linux/serialsim.h>
> +
> +#define PORT_SERIALECHO 72549
> +#define PORT_SERIALPIPEA 72550
> +#define PORT_SERIALPIPEB 72551
tabs?
> +
> +#ifdef CONFIG_HIGH_RES_TIMERS
> +#define SERIALSIM_WAKES_PER_SEC 1000
> +#else
> +#define SERIALSIM_WAKES_PER_SEC HZ
> +#endif
> +
> +#define SERIALSIM_XBUFSIZE 32
> +
> +/* For things to send on the line, in flags field. */
> +#define DO_FRAME_ERR (1 << TTY_FRAME)
> +#define DO_PARITY_ERR (1 << TTY_PARITY)
> +#define DO_OVERRUN_ERR (1 << TTY_OVERRUN)
> +#define DO_BREAK (1 << TTY_BREAK)
> +#define FLAGS_MASK (DO_FRAME_ERR | DO_PARITY_ERR | DO_OVERRUN_ERR | DO_BREAK)
> +
> +struct serialsim_intf {
> + struct uart_port port;
> +
> + /*
> + * This is my transmit buffer, my thread picks this up and
> + * injects them into the other port's uart.
> + */
> + unsigned char xmitbuf[SERIALSIM_XBUFSIZE];
> + struct circ_buf buf;
> +
> + /* Error flags to send. */
> + bool break_reported;
> + unsigned int flags;
> +
> + /* Modem state. */
> + unsigned int mctrl;
> + bool do_null_modem;
> + spinlock_t mctrl_lock;
> + struct tasklet_struct mctrl_tasklet;
> +
> + /* My transmitter is enabled. */
> + bool tx_enabled;
> +
> + /* I can receive characters. */
> + bool rx_enabled;
> +
> + /* Is the port registered with the uart driver? */
> + bool registered;
> +
> + /*
> + * The serial echo port on the other side of this pipe (or points
> + * to myself in loopback mode.
> + */
> + struct serialsim_intf *ointf;
> +
> + unsigned int div;
> + unsigned int bytes_per_interval;
> + unsigned int per_interval_residual;
> +
> + struct ktermios termios;
> +
> + const char *threadname;
> + struct task_struct *thread;
> +
> + struct serial_rs485 rs485;
> +};
> +
> +#define circ_sbuf_space(buf) CIRC_SPACE((buf)->head, (buf)->tail, \
> + SERIALSIM_XBUFSIZE)
> +#define circ_sbuf_empty(buf) ((buf)->head == (buf)->tail)
> +#define circ_sbuf_next(idx) (((idx) + 1) % SERIALSIM_XBUFSIZE)
Don't we have a ring buffer (or 3) structure already? Did you create
another one?
> +static void serialsim_thread_delay(void)
> +{
> +#ifdef CONFIG_HIGH_RES_TIMERS
> + ktime_t timeout;
> +
> + timeout = ns_to_ktime(1000000000 / SERIALSIM_WAKES_PER_SEC);
> + set_current_state(TASK_INTERRUPTIBLE);
> + schedule_hrtimeout(&timeout, HRTIMER_MODE_REL);
> +#else
> + schedule_timeout_interruptible(1);
> +#endif
> +}
Why do you care about hires timers here? Why not always just sleep to
slow things down?
> +
> +static int serialsim_thread(void *data)
> +{
> + struct serialsim_intf *intf = data;
> + struct serialsim_intf *ointf = intf->ointf;
> + struct uart_port *port = &intf->port;
> + struct uart_port *oport = &ointf->port;
> + struct circ_buf *tbuf = &intf->buf;
> + unsigned int residual = 0;
> +
> + while (!kthread_should_stop()) {
Aren't we trying to get away from creating new kthreads?
Can you just use a workqueue entry?
> +static unsigned int nr_echo_ports = 4;
> +module_param(nr_echo_ports, uint, 0444);
> +MODULE_PARM_DESC(nr_echo_ports,
> + "The number of echo ports to create. Defaults to 4");
> +
> +static unsigned int nr_pipe_ports = 4;
> +module_param(nr_pipe_ports, uint, 0444);
> +MODULE_PARM_DESC(nr_pipe_ports,
> + "The number of pipe ports to create. Defaults to 4");
No way to just do this with configfs and not worry about module params?
> +static char *gettok(char **s)
> +{
> + char *t = skip_spaces(*s);
> + char *p = t;
> +
> + while (*p && !isspace(*p))
> + p++;
> + if (*p)
> + *p++ = '\0';
> + *s = p;
> +
> + return t;
> +}
We don't have this already in the tree?
> +static bool tokeq(const char *t, const char *m)
> +{
> + return strcmp(t, m) == 0;
> +}
same here.
> +
> +static unsigned int parse_modem_line(char op, unsigned int flag,
> + unsigned int *mctrl)
> +{
> + if (op == '+')
> + *mctrl |= flag;
> + else
> + *mctrl &= ~flag;
> + return flag;
> +}
> +
> +static void serialsim_ctrl_append(char **val, int *left, char *n, bool enabled)
> +{
> + int count;
> +
> + count = snprintf(*val, *left, " %c%s", enabled ? '+' : '-', n);
> + *left -= count;
> + *val += count;
> +}
sysfs files really should only be "one value per file", so this api is
troubling :(
> +static ssize_t serialsim_ctrl_read(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct tty_port *tport = dev_get_drvdata(dev);
> + struct uart_state *state = container_of(tport, struct uart_state, port);
> + struct uart_port *port = state->uart_port;
> + struct serialsim_intf *intf = serialsim_port_to_intf(port);
> + unsigned int mctrl = intf->mctrl;
> + char *val = buf;
> + int left = PAGE_SIZE;
> + int count;
> +
> + count = snprintf(val, left, "%s:", dev->kobj.name);
dev_name()?
And is it really needed? It's already known as this is the sysfs file
for that device. Don't make userspace parse it away.
> + val += count;
> + left -= count;
> + serialsim_ctrl_append(&val, &left, "nullmodem", intf->do_null_modem);
> + serialsim_ctrl_append(&val, &left, "cd", mctrl & TIOCM_CAR);
> + serialsim_ctrl_append(&val, &left, "dsr", mctrl & TIOCM_DSR);
> + serialsim_ctrl_append(&val, &left, "cts", mctrl & TIOCM_CTS);
> + serialsim_ctrl_append(&val, &left, "ring", mctrl & TIOCM_RNG);
> + serialsim_ctrl_append(&val, &left, "dtr", mctrl & TIOCM_DTR);
> + serialsim_ctrl_append(&val, &left, "rts", mctrl & TIOCM_RTS);
> + *val++ = '\n';
> +
> + return val - buf;
> +}
> +
> +static ssize_t serialsim_ctrl_write(struct device *dev,
> + struct device_attribute *attr,
> + const char *val, size_t count)
> +{
> + struct tty_port *tport = dev_get_drvdata(dev);
> + struct uart_state *state = container_of(tport, struct uart_state, port);
> + struct uart_port *port = state->uart_port;
> + struct serialsim_intf *intf = serialsim_port_to_intf(port);
> + char *str = kstrndup(val, count, GFP_KERNEL);
> + char *p, *s = str;
> + int rv = count;
> + unsigned int flags = 0;
> + unsigned int nullmodem = 0;
> + unsigned int mctrl_mask = 0, mctrl = 0;
> +
> + if (!str)
> + return -ENOMEM;
> +
> + p = gettok(&s);
> + while (*p) {
> + char op = '\0';
> + int err = 0;
> +
> + switch (*p) {
> + case '+':
> + case '-':
> + op = *p++;
> + break;
> + default:
> + break;
> + }
> +
> + if (tokeq(p, "frame"))
> + flags |= DO_FRAME_ERR;
> + else if (tokeq(p, "parity"))
> + flags |= DO_PARITY_ERR;
> + else if (tokeq(p, "overrun"))
> + flags |= DO_OVERRUN_ERR;
> + else if (tokeq(p, "nullmodem"))
> + nullmodem = op;
> + else if (tokeq(p, "dsr"))
> + mctrl_mask |= parse_modem_line(op, TIOCM_DSR, &mctrl);
> + else if (tokeq(p, "cts"))
> + mctrl_mask |= parse_modem_line(op, TIOCM_CTS, &mctrl);
> + else if (tokeq(p, "cd"))
> + mctrl_mask |= parse_modem_line(op, TIOCM_CAR, &mctrl);
> + else if (tokeq(p, "ring"))
> + mctrl_mask |= parse_modem_line(op, TIOCM_RNG, &mctrl);
> + else
> + err = -EINVAL;
> +
> + if (err) {
> + rv = err;
> + goto out;
> + }
> + p = gettok(&s);
> + }
> +
> + if (flags)
> + serialsim_set_flags(intf, flags);
> + if (nullmodem)
> + serialsim_set_null_modem(intf, nullmodem == '+');
> + if (mctrl_mask)
> + serialsim_set_modem_lines(intf, mctrl_mask, mctrl);
> +
> +out:
> + kfree(str);
> +
> + return rv;
> +}
This worries me, parsing sysfs files is ripe for problems. configfs
might be better here.
> +
> +static DEVICE_ATTR(ctrl, 0660, serialsim_ctrl_read, serialsim_ctrl_write);
DEVICE_ATTR_RW()?
> +
> +static struct attribute *serialsim_dev_attrs[] = {
> + &dev_attr_ctrl.attr,
> + NULL,
> +};
> +
> +static struct attribute_group serialsim_dev_attr_group = {
> + .attrs = serialsim_dev_attrs,
> +};
ATTRIBUTE_GROUPS()?
> +static int __init serialsim_init(void)
> +{
> + unsigned int i;
> + int rv;
> +
> + serialecho_ports = kcalloc(nr_echo_ports,
> + sizeof(*serialecho_ports),
> + GFP_KERNEL);
> + if (!serialecho_ports) {
> + pr_err("serialsim: Unable to allocate echo ports.\n");
No need to print error for memory failure.
> + rv = ENOMEM;
-ENOMEM?
> + goto out;
> + }
> +
> + serialpipe_ports = kcalloc(nr_pipe_ports * 2,
> + sizeof(*serialpipe_ports),
> + GFP_KERNEL);
> + if (!serialpipe_ports) {
> + kfree(serialecho_ports);
> + pr_err("serialsim: Unable to allocate pipe ports.\n");
Same here.
> + rv = ENOMEM;
-ENOMEM?
> + goto out;
Shouldn't out clean up stuff?
> + }
> +
> + serialecho_driver.nr = nr_echo_ports;
> + rv = uart_register_driver(&serialecho_driver);
> + if (rv) {
> + kfree(serialecho_ports);
> + kfree(serialpipe_ports);
> + pr_err("serialsim: Unable to register driver.\n");
> + goto out;
Again, out should clean up stuff for an error. Will make the code below
simpler.
> + }
> +
> + serialpipea_driver.nr = nr_pipe_ports;
> + rv = uart_register_driver(&serialpipea_driver);
> + if (rv) {
> + uart_unregister_driver(&serialecho_driver);
> + kfree(serialecho_ports);
> + kfree(serialpipe_ports);
> + pr_err("serialsim: Unable to register driver.\n");
> + goto out;
> + }
> +
> + serialpipeb_driver.nr = nr_pipe_ports;
> + rv = uart_register_driver(&serialpipeb_driver);
> + if (rv) {
> + uart_unregister_driver(&serialpipea_driver);
> + uart_unregister_driver(&serialecho_driver);
> + kfree(serialecho_ports);
> + kfree(serialpipe_ports);
> + pr_err("serialsim: Unable to register driver.\n");
> + goto out;
> + }
> +
> + for (i = 0; i < nr_echo_ports; i++) {
> + struct serialsim_intf *intf = &serialecho_ports[i];
> + struct uart_port *port = &intf->port;
> +
> + intf->buf.buf = intf->xmitbuf;
> + intf->ointf = intf;
> + intf->threadname = "serialecho";
> + intf->do_null_modem = true;
> + spin_lock_init(&intf->mctrl_lock);
> + tasklet_init(&intf->mctrl_tasklet, mctrl_tasklet, (long) intf);
> + /* Won't configure without some I/O or mem address set. */
> + port->iobase = 1;
> + port->line = i;
> + port->flags = UPF_BOOT_AUTOCONF;
> + port->ops = &serialecho_ops;
> + spin_lock_init(&port->lock);
> + port->attr_group = &serialsim_dev_attr_group;
> + rv = uart_add_one_port(&serialecho_driver, port);
> + if (rv)
> + pr_err("serialsim: Unable to add uart port %d: %d\n",
> + i, rv);
> + else
> + intf->registered = true;
> + }
> +
> + for (i = 0; i < nr_pipe_ports * 2; i += 2) {
> + struct serialsim_intf *intfa = &serialpipe_ports[i];
> + struct serialsim_intf *intfb = &serialpipe_ports[i + 1];
> + struct uart_port *porta = &intfa->port;
> + struct uart_port *portb = &intfb->port;
> +
> + intfa->buf.buf = intfa->xmitbuf;
> + intfb->buf.buf = intfb->xmitbuf;
> + intfa->ointf = intfb;
> + intfb->ointf = intfa;
> + intfa->threadname = "serialpipea";
> + intfb->threadname = "serialpipeb";
> + spin_lock_init(&intfa->mctrl_lock);
> + spin_lock_init(&intfb->mctrl_lock);
> + tasklet_init(&intfa->mctrl_tasklet, mctrl_tasklet,
> + (long) intfa);
> + tasklet_init(&intfb->mctrl_tasklet, mctrl_tasklet,
> + (long) intfb);
> +
> + /* Won't configure without some I/O or mem address set. */
> + porta->iobase = 1;
> + porta->line = i / 2;
> + porta->flags = UPF_BOOT_AUTOCONF;
> + porta->ops = &serialpipea_ops;
> + spin_lock_init(&porta->lock);
> + porta->attr_group = &serialsim_dev_attr_group;
> + porta->rs485_config = serialsim_rs485;
> +
> + /*
> + * uart_add_one_port() does an mctrl operation, which will
> + * claim the other port's lock. So everything needs to be
> + * full initialized, and we need null modem off until we
> + * get things added.
> + */
> + portb->iobase = 1;
> + portb->line = i / 2;
> + portb->flags = UPF_BOOT_AUTOCONF;
> + portb->ops = &serialpipeb_ops;
> + portb->attr_group = &serialsim_dev_attr_group;
> + spin_lock_init(&portb->lock);
> + portb->rs485_config = serialsim_rs485;
> +
> + rv = uart_add_one_port(&serialpipea_driver, porta);
> + if (rv) {
> + pr_err("serialsim: Unable to add uart pipe a port %d: %d\n",
> + i, rv);
> + continue;
> + } else {
> + intfa->registered = true;
> + }
> +
> + rv = uart_add_one_port(&serialpipeb_driver, portb);
> + if (rv) {
> + pr_err("serialsim: Unable to add uart pipe b port %d: %d\n",
> + i, rv);
> + intfa->registered = false;
> + uart_remove_one_port(&serialpipea_driver, porta);
> + } else {
> + intfb->registered = true;
> + }
> +
> + if (intfa->registered && intfb->registered) {
> + serialsim_set_null_modem(intfa, true);
> + serialsim_set_null_modem(intfb, true);
> + }
> + }
> + rv = 0;
> +
> + pr_info("serialsim ready\n");
Don't be noisy for when all is good. Drivers should be quiet.
> --- /dev/null
> +++ b/include/uapi/linux/serialsim.h
> @@ -0,0 +1,32 @@
> +/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
> +
> +/*
> + * serialsim - Emulate a serial device in a loopback and/or pipe
> + */
> +
> +/*
> + * TTY IOCTLs for controlling the modem control and for error injection.
> + * See drivers/tty/serial/serialsim.c and Documentation/serial/serialsim.rst
> + * for details.
> + */
> +
> +#ifndef LINUX_SERIALSIM_H
> +#define LINUX_SERIALSIM_H
> +
> +#include <linux/ioctl.h>
> +#include <asm/termbits.h>
> +
> +#define TIOCSERSREMNULLMODEM 0x54e4
> +#define TIOCSERSREMMCTRL 0x54e5
> +#define TIOCSERSREMERR 0x54e6
> +#ifdef TCGETS2
> +#define TIOCSERGREMTERMIOS _IOR('T', 0xe7, struct termios2)
> +#else
> +#define TIOCSERGREMTERMIOS _IOR('T', 0xe7, struct termios)
> +#endif
> +#define TIOCSERGREMNULLMODEM _IOR('T', 0xe8, int)
> +#define TIOCSERGREMMCTRL _IOR('T', 0xe9, unsigned int)
> +#define TIOCSERGREMERR _IOR('T', 0xea, unsigned int)
> +#define TIOCSERGREMRS485 _IOR('T', 0xeb, struct serial_rs485)
Wait, don't we have ioctls for these things in the tty layer already?
WHy add new ones?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] tty: serial_core: Spelling correction
From: Greg KH @ 2019-03-27 15:13 UTC (permalink / raw)
To: Hariprasad Kelam; +Cc: jslaby, linux-serial, linux-kernel
In-Reply-To: <20190322030159.GA6551@hari-Inspiron-1545>
On Fri, Mar 22, 2019 at 08:31:59AM +0530, Hariprasad Kelam wrote:
> fix spelling mistake "overriden" -> "overridden"
> This fix resolves warning reported by checkpatch tool
>
> Signed-off-by: Hariprasad Kelam <hariprasad.kelam@gmail.com>
> ---
> drivers/tty/serial/serial_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
You sent 3 patches with the same subject, and so I have no idea which
one is the "latest" one.
Please fix up and resend with the proper version information as the
documentation asks you to.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] serial: Add Milbeaut serial control
From: Sugaya, Taichi @ 2019-03-27 9:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greg Kroah-Hartman, Jiri Slaby, Takao Orito, Kazuhiro Kasai,
Shinji Kanematsu, Jassi Brar, Masami Hiramatsu,
Linux Kernel Mailing List, linux-serial
In-Reply-To: <CAK8P3a0Sx5vxbserW27KMPYnpLabPkGJZ_2iuW9y082oHiO+aQ@mail.gmail.com>
Hi
Thank you for your comments.
On 2019/03/26 18:57, Arnd Bergmann wrote:
> On Tue, Mar 26, 2019 at 10:13 AM Sugaya Taichi
> <sugaya.taichi@socionext.com> wrote:
>
>>
>> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
>> index 72966bc..961519b 100644
>> --- a/drivers/tty/serial/Kconfig
>> +++ b/drivers/tty/serial/Kconfig
>> @@ -1582,6 +1582,32 @@ config SERIAL_RDA_CONSOLE
>> Say 'Y' here if you wish to use the RDA8810PL UART as the system
>> console. Only earlycon is implemented currently.
>>
>> +config SERIAL_MILBEAUT_USIO
>> + tristate "Milbeaut USIO/UART serial port support"
>> + depends on ARCH_MILBEAUT
>> + default y
>> + select SERIAL_CORE
>> + help
>> + This selects the USIO/UART IP found in Socionext Milbeaut SoCs.
>
> In general, it would be good to make it possible to build this on
> other architectures for better compile test coverage, e.g. like
>
> config SERIAL_MILBEAUT_USIO
> tristate "Milbeaut USIO/UART serial port support"
> depends on ARCH_MILBEAUT || COMPILE_TEST
> default ARCH_MILBEAUT
>
All right.
I agree with the style.
> You might need additional dependencies like 'depends on OF'
> to make this work reliably.
>
I got it.
I think the way is inserting "depends on OF" as a new line.
Thanks,
Sugaya Taichi
> Arnd
>
^ permalink raw reply
* Re: tty: uart: loopback test
From: hariprasad kelam @ 2019-03-27 2:15 UTC (permalink / raw)
To: Subhashini Rao Beerisetty; +Cc: linux-serial, kernelnewbies
In-Reply-To: <CAPY=qRThdF_oqVf+rSUEfWPi=uhRQmjHYHB0dyG=mKGK2EY4Lg@mail.gmail.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 1131 bytes --]
Hi Subhashini,
On Tue, 26 Mar 2019 at 17:23, Subhashini Rao Beerisetty <
subhashbeerisetty@gmail.com> wrote:
> Hi All,
>
>
> I’m looking for an userspace ‘C’ test code to transfer a file on UART
> Tx line and receive the file on UART Rx line to test loopback
> supported serial port.
>
Before sending file on UART . I would suggest you to test sending simple
buffer and ensure you receive it correctly.
>
> Can anybody give example of such application?
>
I am assuming you have correct hardware ,ensure RS-232 RX-TX lines are
short.If you are not sure follow below link
[image: image.png]
Coming to application which tests loop back,there are plenty tools like
1.minicom
2.cutecom etc.
if you want to specific application try below
https://elinux.org/images/b/b7/Uart-loopback.c
https://medium.com/@amitasinghchauhan/serial-port-debugging-101-loopback-test-4a7e40da9055
>
>
> Thanks
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
[-- Attachment #1.1.2: Type: text/html, Size: 2359 bytes --]
[-- Attachment #1.2: image.png --]
[-- Type: image/png, Size: 10661 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply
* Re: [PATCH v2 0/4] Add new features for the Spreadtrum serial controller
From: Baolin Wang @ 2019-03-27 1:59 UTC (permalink / raw)
To: Greg KH
Cc: jslaby, Rob Herring, Mark Rutland, Orson Zhai, Chunyan Zhang,
Mark Brown, lanqing.liu, linux-serial, LKML, DTML
In-Reply-To: <20190327005944.GA20301@kroah.com>
On Wed, 27 Mar 2019 at 08:59, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Mar 26, 2019 at 06:41:31PM +0800, Baolin Wang wrote:
> > Hi Greg,
> >
> > On Mon, 4 Mar 2019 at 16:59, Baolin Wang <baolin.wang@linaro.org> wrote:
> > >
> > > This patch set fixes the baud rate calculation formula issue, as well as
> > > adding power management support and DMA mode support for the Spreadtrum
> > > serial controller.
> > >
> > > Changes from v1:
> > > - The patch 1 of V1 was applied, so remove the baud rate fix from this patch set.
> > > - Add reviewed tag from Rob for patch 1.
> > > - Fix the incorrect names' order in patch 3.
> >
> > Could you apply this patch set if no objection from you? Thanks.
>
> It's in my to-review queue, sorry, will get to it soon...
Thanks :)
--
Baolin Wang
Best Regards
^ permalink raw reply
* Re: [PATCH v2 0/4] Add new features for the Spreadtrum serial controller
From: Greg KH @ 2019-03-27 0:59 UTC (permalink / raw)
To: Baolin Wang
Cc: jslaby, Rob Herring, Mark Rutland, Orson Zhai, Chunyan Zhang,
Mark Brown, lanqing.liu, linux-serial, LKML, DTML
In-Reply-To: <CAMz4kuJitF7Q76T0Hoj1-UTAjQnepEs9aQHhy=r_Acdq+RiwGw@mail.gmail.com>
On Tue, Mar 26, 2019 at 06:41:31PM +0800, Baolin Wang wrote:
> Hi Greg,
>
> On Mon, 4 Mar 2019 at 16:59, Baolin Wang <baolin.wang@linaro.org> wrote:
> >
> > This patch set fixes the baud rate calculation formula issue, as well as
> > adding power management support and DMA mode support for the Spreadtrum
> > serial controller.
> >
> > Changes from v1:
> > - The patch 1 of V1 was applied, so remove the baud rate fix from this patch set.
> > - Add reviewed tag from Rob for patch 1.
> > - Fix the incorrect names' order in patch 3.
>
> Could you apply this patch set if no objection from you? Thanks.
It's in my to-review queue, sorry, will get to it soon...
greg k-h
^ permalink raw reply
* [PATCH V31 17/25] Lock down TIOCSSERIAL
From: Matthew Garrett @ 2019-03-26 18:27 UTC (permalink / raw)
To: jmorris
Cc: linux-security-module, linux-kernel, dhowells, linux-api, luto,
Greg Kroah-Hartman, Matthew Garrett, Jiri Slaby, linux-serial
In-Reply-To: <20190326182742.16950-1-matthewgarrett@google.com>
From: David Howells <dhowells@redhat.com>
Lock down TIOCSSERIAL as that can be used to change the ioport and irq
settings on a serial port. This only appears to be an issue for the serial
drivers that use the core serial code. All other drivers seem to either
ignore attempts to change port/irq or give an error.
Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Matthew Garrett <mjg59@google.com>
cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-serial@vger.kernel.org
---
drivers/tty/serial/serial_core.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index d4cca5bdaf1c..65b67f0d4386 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -842,6 +842,12 @@ static int uart_set_info(struct tty_struct *tty, struct tty_port *port,
new_flags = (__force upf_t)new_info->flags;
old_custom_divisor = uport->custom_divisor;
+ if ((change_port || change_irq) &&
+ kernel_is_locked_down("Using TIOCSSERIAL to change device addresses, irqs and dma channels", LOCKDOWN_INTEGRITY)) {
+ retval = -EPERM;
+ goto exit;
+ }
+
if (!capable(CAP_SYS_ADMIN)) {
retval = -EPERM;
if (change_irq || change_port ||
--
2.21.0.392.gf8f6787159e-goog
^ permalink raw reply related
* Re: [PATCH v2 2/2] tty/serial: atmel: RS485 HD w/DMA: enable RX after TX is stopped
From: Richard Genoud @ 2019-03-26 15:12 UTC (permalink / raw)
To: Razvan Stefanescu, Greg Kroah-Hartman, Jiri Slaby
Cc: Gil Weber, Nicolas Ferre, Alexandre Belloni, Ludovic Desroches,
linux-serial, linux-arm-kernel, linux-kernel
In-Reply-To: <20190319132035.18481-3-razvan.stefanescu@microchip.com>
Le 19/03/2019 à 14:20, Razvan Stefanescu a écrit :
> In half-duplex operation, RX should be started after TX completes.
>
> If DMA is used, there is a case when the DMA transfer completes but the
> TX FIFO is not emptied, so the RX cannot be restarted just yet.
>
> Use a boolean variable to store this state and rearm TX interrupt mask
> to be signaled again that the transfer finished. In interrupt transmit
> handler this variable is used to start RX. A warning message is generated
> if RX is activated before TX fifo is cleared.
>
> Fixes: b389f173aaa1 ("tty/serial: atmel: RS485 half duplex w/DMA: enable
> RX after TX is done")
> Signed-off-by: Razvan Stefanescu <razvan.stefanescu@microchip.com>
Acked-by: Richard Genoud <richard.genoud@gmail.com>
NB: backport on kernel older than 4.20 will fail because of the iso7816
variables fidi_min/fidi_max.
> ---
> Changelog:
> v2:
> - start RX and display warning in case of error
> - add fix info
>
> drivers/tty/serial/atmel_serial.c | 25 ++++++++++++++++++++++---
> 1 file changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index b4b89a16a41b..5b2f859c327c 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -166,6 +166,8 @@ struct atmel_uart_port {
> unsigned int pending_status;
> spinlock_t lock_suspended;
>
> + bool hd_start_rx; /* can start RX during half-duplex operation */
> +
> /* ISO7816 */
> unsigned int fidi_min;
> unsigned int fidi_max;
> @@ -933,8 +935,13 @@ static void atmel_complete_tx_dma(void *arg)
> if (!uart_circ_empty(xmit))
> atmel_tasklet_schedule(atmel_port, &atmel_port->tasklet_tx);
> else if (atmel_uart_is_half_duplex(port)) {
> - /* DMA done, stop TX, start RX for RS485 */
> - atmel_start_rx(port);
> + /*
> + * DMA done, re-enable TXEMPTY and signal that we can stop
> + * TX and start RX for RS485
> + */
> + atmel_port->hd_start_rx = true;
> + atmel_uart_writel(port, ATMEL_US_IER,
> + atmel_port->tx_done_mask);
> }
>
> spin_unlock_irqrestore(&port->lock, flags);
> @@ -1378,9 +1385,20 @@ atmel_handle_transmit(struct uart_port *port, unsigned int pending)
> struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>
> if (pending & atmel_port->tx_done_mask) {
> - /* Either PDC or interrupt transmission */
> atmel_uart_writel(port, ATMEL_US_IDR,
> atmel_port->tx_done_mask);
> +
> + /* Start RX if flag was set and FIFO is empty */
> + if (atmel_port->hd_start_rx) {
> + if (!(atmel_uart_readl(port, ATMEL_US_CSR)
> + & ATMEL_US_TXEMPTY))
> + dev_warn(port->dev, "Should start RX, but TX fifo is not empty\n");
> +
> + atmel_port->hd_start_rx = false;
> + atmel_start_rx(port);
> + return;
> + }
> +
> atmel_tasklet_schedule(atmel_port, &atmel_port->tasklet_tx);
> }
> }
>
^ permalink raw reply
* Re: [PATCH v2 1/2] tty/serial: atmel: Add is_half_duplex helper
From: Richard Genoud @ 2019-03-26 15:10 UTC (permalink / raw)
To: Razvan Stefanescu, Greg Kroah-Hartman, Jiri Slaby
Cc: Gil Weber, Nicolas Ferre, Alexandre Belloni, Ludovic Desroches,
linux-serial, linux-arm-kernel, linux-kernel
In-Reply-To: <20190319132035.18481-2-razvan.stefanescu@microchip.com>
Le 19/03/2019 à 14:20, Razvan Stefanescu a écrit :
> Use a helper function to check that a port needs to use half duplex
> communication, replacing several occurrences of multi-line bit checking.
>
> Fixes: b389f173aaa1 ("tty/serial: atmel: RS485 half duplex w/DMA: enable
> RX after TX is done")
> Signed-off-by: Razvan Stefanescu <razvan.stefanescu@microchip.com>
Acked-by: Richard Genoud <richard.genoud@gmail.com>
NB: backport on kernel older than 4.20 will fail because of the
SER_ISO7816_ENABLED flag.
> ---
> Changelog:
> v2:
> - remove extra check
> - add fix info
>
> drivers/tty/serial/atmel_serial.c | 24 ++++++++++++------------
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index 05147fe24343..b4b89a16a41b 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -231,6 +231,13 @@ static inline void atmel_uart_write_char(struct uart_port *port, u8 value)
> __raw_writeb(value, port->membase + ATMEL_US_THR);
> }
>
> +static inline int atmel_uart_is_half_duplex(struct uart_port *port)
> +{
> + return ((port->rs485.flags & SER_RS485_ENABLED) &&
> + !(port->rs485.flags & SER_RS485_RX_DURING_TX)) ||
> + (port->iso7816.flags & SER_ISO7816_ENABLED);
> +}
> +
> #ifdef CONFIG_SERIAL_ATMEL_PDC
> static bool atmel_use_pdc_rx(struct uart_port *port)
> {
> @@ -608,10 +615,9 @@ static void atmel_stop_tx(struct uart_port *port)
> /* Disable interrupts */
> atmel_uart_writel(port, ATMEL_US_IDR, atmel_port->tx_done_mask);
>
> - if (((port->rs485.flags & SER_RS485_ENABLED) &&
> - !(port->rs485.flags & SER_RS485_RX_DURING_TX)) ||
> - port->iso7816.flags & SER_ISO7816_ENABLED)
> + if (atmel_uart_is_half_duplex(port))
> atmel_start_rx(port);
> +
> }
>
> /*
> @@ -628,9 +634,7 @@ static void atmel_start_tx(struct uart_port *port)
> return;
>
> if (atmel_use_pdc_tx(port) || atmel_use_dma_tx(port))
> - if (((port->rs485.flags & SER_RS485_ENABLED) &&
> - !(port->rs485.flags & SER_RS485_RX_DURING_TX)) ||
> - port->iso7816.flags & SER_ISO7816_ENABLED)
> + if (atmel_uart_is_half_duplex(port))
> atmel_stop_rx(port);
>
> if (atmel_use_pdc_tx(port))
> @@ -928,9 +932,7 @@ static void atmel_complete_tx_dma(void *arg)
> */
> if (!uart_circ_empty(xmit))
> atmel_tasklet_schedule(atmel_port, &atmel_port->tasklet_tx);
> - else if (((port->rs485.flags & SER_RS485_ENABLED) &&
> - !(port->rs485.flags & SER_RS485_RX_DURING_TX)) ||
> - port->iso7816.flags & SER_ISO7816_ENABLED) {
> + else if (atmel_uart_is_half_duplex(port)) {
> /* DMA done, stop TX, start RX for RS485 */
> atmel_start_rx(port);
> }
> @@ -1508,9 +1510,7 @@ static void atmel_tx_pdc(struct uart_port *port)
> atmel_uart_writel(port, ATMEL_US_IER,
> atmel_port->tx_done_mask);
> } else {
> - if (((port->rs485.flags & SER_RS485_ENABLED) &&
> - !(port->rs485.flags & SER_RS485_RX_DURING_TX)) ||
> - port->iso7816.flags & SER_ISO7816_ENABLED) {
> + if (atmel_uart_is_half_duplex(port)) {
> /* DMA done, stop TX, start RX for RS485 */
> atmel_start_rx(port);
> }
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox