+++ /dev/null
-From f6aa5beb45be27968a4df90176ca36dfc4363d37 Mon Sep 17 00:00:00 2001
-From: Marek Vasut <marex@denx.de>
-Date: Mon, 3 Sep 2018 02:44:52 +0200
-Subject: serial: 8250: Fix clearing FIFOs in RS485 mode again
-
-From: Marek Vasut <marex@denx.de>
-
-commit f6aa5beb45be27968a4df90176ca36dfc4363d37 upstream.
-
-The 8250 FIFOs indeed need to be cleared after stopping transmission in
-RS485 mode without SER_RS485_RX_DURING_TX flag set. But there are two
-problems with the approach taken by the previous patch from Fixes tag.
-
-First, serial8250_clear_fifos() should clear fifos, but what it really
-does is it enables the FIFOs unconditionally if present, clears them
-and then sets the FCR register to zero, which effectively disables the
-FIFOs. In case the FIFO is disabled, enabling it and clearing it makes
-no sense and in fact can trigger misbehavior of the 8250 core. Moreover,
-the FCR register may contain other FIFO configuration bits which may not
-be writable unconditionally and writing them incorrectly can trigger
-misbehavior of the 8250 core too. (ie. AM335x UART swallows the first
-byte and retransmits the last byte twice because of this FCR write).
-
-Second, serial8250_clear_and_reinit_fifos() completely reloads the FCR,
-but what really has to happen at the end of the RS485 transmission is
-clearing of the FIFOs and nothing else.
-
-This patch repairs serial8250_clear_fifos() so that it really only
-clears the FIFOs by operating on FCR[2:1] bits and leaves all the
-other bits alone. It also undoes serial8250_clear_and_reinit_fifos()
-from __do_stop_tx_rs485() as serial8250_clear_fifos() is sufficient.
-
-Signed-off-by: Marek Vasut <marex@denx.de>
-Fixes: 2bed8a8e7072 ("Clearing FIFOs in RS485 emulation mode causes subsequent transmits to break")
-Cc: Daniel Jedrychowski <avistel@gmail.com>
-Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-Cc: stable <stable@vger.kernel.org> # let it bake a bit before merging
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
----
- drivers/tty/serial/8250/8250_port.c | 29 ++++++++++++++++++++++++-----
- 1 file changed, 24 insertions(+), 5 deletions(-)
-
---- a/drivers/tty/serial/8250/8250_port.c
-+++ b/drivers/tty/serial/8250/8250_port.c
-@@ -553,11 +553,30 @@ static unsigned int serial_icr_read(stru
- */
- static void serial8250_clear_fifos(struct uart_8250_port *p)
- {
-+ unsigned char fcr;
-+ unsigned char clr_mask = UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT;
-+
- if (p->capabilities & UART_CAP_FIFO) {
-- serial_out(p, UART_FCR, UART_FCR_ENABLE_FIFO);
-- serial_out(p, UART_FCR, UART_FCR_ENABLE_FIFO |
-- UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT);
-- serial_out(p, UART_FCR, 0);
-+ /*
-+ * Make sure to avoid changing FCR[7:3] and ENABLE_FIFO bits.
-+ * In case ENABLE_FIFO is not set, there is nothing to flush
-+ * so just return. Furthermore, on certain implementations of
-+ * the 8250 core, the FCR[7:3] bits may only be changed under
-+ * specific conditions and changing them if those conditions
-+ * are not met can have nasty side effects. One such core is
-+ * the 8250-omap present in TI AM335x.
-+ */
-+ fcr = serial_in(p, UART_FCR);
-+
-+ /* FIFO is not enabled, there's nothing to clear. */
-+ if (!(fcr & UART_FCR_ENABLE_FIFO))
-+ return;
-+
-+ fcr |= clr_mask;
-+ serial_out(p, UART_FCR, fcr);
-+
-+ fcr &= ~clr_mask;
-+ serial_out(p, UART_FCR, fcr);
- }
- }
-
-@@ -1450,7 +1469,7 @@ static void __do_stop_tx_rs485(struct ua
- * Enable previously disabled RX interrupts.
- */
- if (!(p->port.rs485.flags & SER_RS485_RX_DURING_TX)) {
-- serial8250_clear_and_reinit_fifos(p);
-+ serial8250_clear_fifos(p);
-
- p->ier |= UART_IER_RLSI | UART_IER_RDI;
- serial_port_out(&p->port, UART_IER, p->ier);
misc-pci_endpoint_test-fix-to-support-10-pci-endpoint-test-devices.patch
coresight-do-not-use-the-bit-macro-in-the-uapi-header.patch
padata-always-acquire-cpu_hotplug_lock-before-pinst-lock.patch
-serial-8250-fix-clearing-fifos-in-rs485-mode-again.patch
mm-mempolicy-require-at-least-one-nodeid-for-mpol_preferred.patch
+++ /dev/null
-From f6aa5beb45be27968a4df90176ca36dfc4363d37 Mon Sep 17 00:00:00 2001
-From: Marek Vasut <marex@denx.de>
-Date: Mon, 3 Sep 2018 02:44:52 +0200
-Subject: serial: 8250: Fix clearing FIFOs in RS485 mode again
-
-From: Marek Vasut <marex@denx.de>
-
-commit f6aa5beb45be27968a4df90176ca36dfc4363d37 upstream.
-
-The 8250 FIFOs indeed need to be cleared after stopping transmission in
-RS485 mode without SER_RS485_RX_DURING_TX flag set. But there are two
-problems with the approach taken by the previous patch from Fixes tag.
-
-First, serial8250_clear_fifos() should clear fifos, but what it really
-does is it enables the FIFOs unconditionally if present, clears them
-and then sets the FCR register to zero, which effectively disables the
-FIFOs. In case the FIFO is disabled, enabling it and clearing it makes
-no sense and in fact can trigger misbehavior of the 8250 core. Moreover,
-the FCR register may contain other FIFO configuration bits which may not
-be writable unconditionally and writing them incorrectly can trigger
-misbehavior of the 8250 core too. (ie. AM335x UART swallows the first
-byte and retransmits the last byte twice because of this FCR write).
-
-Second, serial8250_clear_and_reinit_fifos() completely reloads the FCR,
-but what really has to happen at the end of the RS485 transmission is
-clearing of the FIFOs and nothing else.
-
-This patch repairs serial8250_clear_fifos() so that it really only
-clears the FIFOs by operating on FCR[2:1] bits and leaves all the
-other bits alone. It also undoes serial8250_clear_and_reinit_fifos()
-from __do_stop_tx_rs485() as serial8250_clear_fifos() is sufficient.
-
-Signed-off-by: Marek Vasut <marex@denx.de>
-Fixes: 2bed8a8e7072 ("Clearing FIFOs in RS485 emulation mode causes subsequent transmits to break")
-Cc: Daniel Jedrychowski <avistel@gmail.com>
-Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-Cc: stable <stable@vger.kernel.org> # let it bake a bit before merging
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
----
- drivers/tty/serial/8250/8250_port.c | 29 ++++++++++++++++++++++++-----
- 1 file changed, 24 insertions(+), 5 deletions(-)
-
---- a/drivers/tty/serial/8250/8250_port.c
-+++ b/drivers/tty/serial/8250/8250_port.c
-@@ -552,11 +552,30 @@ static unsigned int serial_icr_read(stru
- */
- static void serial8250_clear_fifos(struct uart_8250_port *p)
- {
-+ unsigned char fcr;
-+ unsigned char clr_mask = UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT;
-+
- if (p->capabilities & UART_CAP_FIFO) {
-- serial_out(p, UART_FCR, UART_FCR_ENABLE_FIFO);
-- serial_out(p, UART_FCR, UART_FCR_ENABLE_FIFO |
-- UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT);
-- serial_out(p, UART_FCR, 0);
-+ /*
-+ * Make sure to avoid changing FCR[7:3] and ENABLE_FIFO bits.
-+ * In case ENABLE_FIFO is not set, there is nothing to flush
-+ * so just return. Furthermore, on certain implementations of
-+ * the 8250 core, the FCR[7:3] bits may only be changed under
-+ * specific conditions and changing them if those conditions
-+ * are not met can have nasty side effects. One such core is
-+ * the 8250-omap present in TI AM335x.
-+ */
-+ fcr = serial_in(p, UART_FCR);
-+
-+ /* FIFO is not enabled, there's nothing to clear. */
-+ if (!(fcr & UART_FCR_ENABLE_FIFO))
-+ return;
-+
-+ fcr |= clr_mask;
-+ serial_out(p, UART_FCR, fcr);
-+
-+ fcr &= ~clr_mask;
-+ serial_out(p, UART_FCR, fcr);
- }
- }
-
-@@ -1448,7 +1467,7 @@ static void __do_stop_tx_rs485(struct ua
- * Enable previously disabled RX interrupts.
- */
- if (!(p->port.rs485.flags & SER_RS485_RX_DURING_TX)) {
-- serial8250_clear_and_reinit_fifos(p);
-+ serial8250_clear_fifos(p);
-
- p->ier |= UART_IER_RLSI | UART_IER_RDI;
- serial_port_out(&p->port, UART_IER, p->ier);
net-fix-tx-hash-bound-checking.patch
padata-always-acquire-cpu_hotplug_lock-before-pinst-lock.patch
bitops-protect-variables-in-set_mask_bits-macro.patch
-serial-8250-fix-clearing-fifos-in-rs485-mode-again.patch
include-linux-notifier.h-srcu-fix-ctags.patch
mm-mempolicy-require-at-least-one-nodeid-for-mpol_preferred.patch
+++ /dev/null
-From f6aa5beb45be27968a4df90176ca36dfc4363d37 Mon Sep 17 00:00:00 2001
-From: Marek Vasut <marex@denx.de>
-Date: Mon, 3 Sep 2018 02:44:52 +0200
-Subject: serial: 8250: Fix clearing FIFOs in RS485 mode again
-
-From: Marek Vasut <marex@denx.de>
-
-commit f6aa5beb45be27968a4df90176ca36dfc4363d37 upstream.
-
-The 8250 FIFOs indeed need to be cleared after stopping transmission in
-RS485 mode without SER_RS485_RX_DURING_TX flag set. But there are two
-problems with the approach taken by the previous patch from Fixes tag.
-
-First, serial8250_clear_fifos() should clear fifos, but what it really
-does is it enables the FIFOs unconditionally if present, clears them
-and then sets the FCR register to zero, which effectively disables the
-FIFOs. In case the FIFO is disabled, enabling it and clearing it makes
-no sense and in fact can trigger misbehavior of the 8250 core. Moreover,
-the FCR register may contain other FIFO configuration bits which may not
-be writable unconditionally and writing them incorrectly can trigger
-misbehavior of the 8250 core too. (ie. AM335x UART swallows the first
-byte and retransmits the last byte twice because of this FCR write).
-
-Second, serial8250_clear_and_reinit_fifos() completely reloads the FCR,
-but what really has to happen at the end of the RS485 transmission is
-clearing of the FIFOs and nothing else.
-
-This patch repairs serial8250_clear_fifos() so that it really only
-clears the FIFOs by operating on FCR[2:1] bits and leaves all the
-other bits alone. It also undoes serial8250_clear_and_reinit_fifos()
-from __do_stop_tx_rs485() as serial8250_clear_fifos() is sufficient.
-
-Signed-off-by: Marek Vasut <marex@denx.de>
-Fixes: 2bed8a8e7072 ("Clearing FIFOs in RS485 emulation mode causes subsequent transmits to break")
-Cc: Daniel Jedrychowski <avistel@gmail.com>
-Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-Cc: stable <stable@vger.kernel.org> # let it bake a bit before merging
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
----
- drivers/tty/serial/8250/8250_port.c | 29 ++++++++++++++++++++++++-----
- 1 file changed, 24 insertions(+), 5 deletions(-)
-
---- a/drivers/tty/serial/8250/8250_port.c
-+++ b/drivers/tty/serial/8250/8250_port.c
-@@ -517,11 +517,30 @@ static unsigned int serial_icr_read(stru
- */
- static void serial8250_clear_fifos(struct uart_8250_port *p)
- {
-+ unsigned char fcr;
-+ unsigned char clr_mask = UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT;
-+
- if (p->capabilities & UART_CAP_FIFO) {
-- serial_out(p, UART_FCR, UART_FCR_ENABLE_FIFO);
-- serial_out(p, UART_FCR, UART_FCR_ENABLE_FIFO |
-- UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT);
-- serial_out(p, UART_FCR, 0);
-+ /*
-+ * Make sure to avoid changing FCR[7:3] and ENABLE_FIFO bits.
-+ * In case ENABLE_FIFO is not set, there is nothing to flush
-+ * so just return. Furthermore, on certain implementations of
-+ * the 8250 core, the FCR[7:3] bits may only be changed under
-+ * specific conditions and changing them if those conditions
-+ * are not met can have nasty side effects. One such core is
-+ * the 8250-omap present in TI AM335x.
-+ */
-+ fcr = serial_in(p, UART_FCR);
-+
-+ /* FIFO is not enabled, there's nothing to clear. */
-+ if (!(fcr & UART_FCR_ENABLE_FIFO))
-+ return;
-+
-+ fcr |= clr_mask;
-+ serial_out(p, UART_FCR, fcr);
-+
-+ fcr &= ~clr_mask;
-+ serial_out(p, UART_FCR, fcr);
- }
- }
-
-@@ -1410,7 +1429,7 @@ static void __do_stop_tx_rs485(struct ua
- * Enable previously disabled RX interrupts.
- */
- if (!(p->port.rs485.flags & SER_RS485_RX_DURING_TX)) {
-- serial8250_clear_and_reinit_fifos(p);
-+ serial8250_clear_fifos(p);
-
- p->ier |= UART_IER_RLSI | UART_IER_RDI;
- serial_port_out(&p->port, UART_IER, p->ier);
coresight-do-not-use-the-bit-macro-in-the-uapi-header.patch
net-dsa-tag_brcm-fix-skb-fwd_offload_mark-location.patch
padata-always-acquire-cpu_hotplug_lock-before-pinst-lock.patch
-serial-8250-fix-clearing-fifos-in-rs485-mode-again.patch
mm-mempolicy-require-at-least-one-nodeid-for-mpol_preferred.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
