This is a note to let you know that I've just added the patch titled
serial: 8250: Fix clearing FIFOs in RS485 mode again
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From f6aa5beb45be27968a4df90176ca36dfc4363d37 Mon Sep 17 00:00:00 2001
From: Marek Vasut <marex(a)denx.de>
Date: Mon, 3 Sep 2018 02:44:52 +0200
Subject: serial: 8250: Fix clearing FIFOs in RS485 mode again
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(a)denx.de>
Fixes: 2bed8a8e7072 ("Clearing FIFOs in RS485 emulation mode causes subsequent transmits to break")
Cc: Daniel Jedrychowski <avistel(a)gmail.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: stable <stable(a)vger.kernel.org> # let it bake a bit before merging
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_port.c | 29 ++++++++++++++++++++++++-----
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 3f779d25ec0c..f776b3eafb96 100644
--- 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(struct uart_8250_port *up, int offset)
*/
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 uart_8250_port *p)
* 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);
--
2.19.0
This is a note to let you know that I've just added the patch titled
serial: cpm_uart: return immediately from console poll
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From be28c1e3ca29887e207f0cbcd294cefe5074bab6 Mon Sep 17 00:00:00 2001
From: Christophe Leroy <christophe.leroy(a)c-s.fr>
Date: Fri, 14 Sep 2018 10:32:50 +0000
Subject: serial: cpm_uart: return immediately from console poll
kgdb expects poll function to return immediately and
returning NO_POLL_CHAR when no character is available.
Fixes: f5316b4aea024 ("kgdb,8250,pl011: Return immediately from console poll")
Cc: Jason Wessel <jason.wessel(a)windriver.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/cpm_uart/cpm_uart_core.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/cpm_uart/cpm_uart_core.c b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
index 24a5f05e769b..e5389591bb4f 100644
--- a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
@@ -1054,8 +1054,8 @@ static int poll_wait_key(char *obuf, struct uart_cpm_port *pinfo)
/* Get the address of the host memory buffer.
*/
bdp = pinfo->rx_cur;
- while (bdp->cbd_sc & BD_SC_EMPTY)
- ;
+ if (bdp->cbd_sc & BD_SC_EMPTY)
+ return NO_POLL_CHAR;
/* If the buffer address is in the CPM DPRAM, don't
* convert it.
@@ -1090,7 +1090,11 @@ static int cpm_get_poll_char(struct uart_port *port)
poll_chars = 0;
}
if (poll_chars <= 0) {
- poll_chars = poll_wait_key(poll_buf, pinfo);
+ int ret = poll_wait_key(poll_buf, pinfo);
+
+ if (ret == NO_POLL_CHAR)
+ return ret;
+ poll_chars = ret;
pollp = poll_buf;
}
poll_chars--;
--
2.19.0
This is a note to let you know that I've just added the patch titled
serial: mvebu-uart: Fix reporting of effective CSIZE to userspace
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From e0bf2d4982fe7d9ddaf550dd023803ea286f47fc Mon Sep 17 00:00:00 2001
From: Jan Kiszka <jan.kiszka(a)siemens.com>
Date: Sun, 26 Aug 2018 19:49:32 +0200
Subject: serial: mvebu-uart: Fix reporting of effective CSIZE to userspace
Apparently, this driver (or the hardware) does not support character
length settings. It's apparently running in 8-bit mode, but it makes
userspace believe it's in 5-bit mode. That makes tcsetattr with CS8
incorrectly fail, breaking e.g. getty from busybox, thus the login shell
on ttyMVx.
Fix by hard-wiring CS8 into c_cflag.
Signed-off-by: Jan Kiszka <jan.kiszka(a)siemens.com>
Fixes: 30530791a7a0 ("serial: mvebu-uart: initial support for Armada-3700 serial port")
Cc: stable <stable(a)vger.kernel.org> # 4.6+
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/mvebu-uart.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/mvebu-uart.c b/drivers/tty/serial/mvebu-uart.c
index d04b5eeea3c6..170e446a2f62 100644
--- a/drivers/tty/serial/mvebu-uart.c
+++ b/drivers/tty/serial/mvebu-uart.c
@@ -511,6 +511,7 @@ static void mvebu_uart_set_termios(struct uart_port *port,
termios->c_iflag |= old->c_iflag & ~(INPCK | IGNPAR);
termios->c_cflag &= CREAD | CBAUD;
termios->c_cflag |= old->c_cflag & ~(CREAD | CBAUD);
+ termios->c_cflag |= CS8;
}
spin_unlock_irqrestore(&port->lock, flags);
--
2.19.0
This is a note to let you know that I've just added the patch titled
serial: 8250: Fix clearing FIFOs in RS485 mode again
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the tty-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From b268203fc327a8f480ef70b70acace7f4a80f525 Mon Sep 17 00:00:00 2001
From: Marek Vasut <marex(a)denx.de>
Date: Mon, 3 Sep 2018 02:44:52 +0200
Subject: serial: 8250: Fix clearing FIFOs in RS485 mode again
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(a)denx.de>
Fixes: 2bed8a8e7072 ("Clearing FIFOs in RS485 emulation mode causes subsequent transmits to break")
Cc: Daniel Jedrychowski <avistel(a)gmail.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: stable <stable(a)vger.kernel.org> # let it bake a bit before merging
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_port.c | 29 ++++++++++++++++++++++++-----
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 3f779d25ec0c..f776b3eafb96 100644
--- 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(struct uart_8250_port *up, int offset)
*/
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 uart_8250_port *p)
* 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);
--
2.19.0
The core of the driver expects the resource array from the glue layer
to be indexed by even numbers, as is the case for 64-bit PCI resources.
This doesn't hold true for others, ACPI in this instance, which leads
to an out-of-bounds access and an ioremap() on whatever address that
access fetches.
This patch fixes the problem by reading resource array differently based
on whether the 64-bit flag is set, which would indicate PCI glue layer.
Signed-off-by: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Fixes: ebc57e399b8e ("intel_th: Add ACPI glue layer")
CC: stable(a)vger.kernel.org # v4.17+
---
drivers/hwtracing/intel_th/core.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/hwtracing/intel_th/core.c b/drivers/hwtracing/intel_th/core.c
index 4e70ecee2103..fc6b7f8b62fb 100644
--- a/drivers/hwtracing/intel_th/core.c
+++ b/drivers/hwtracing/intel_th/core.c
@@ -488,7 +488,7 @@ static const struct intel_th_subdevice {
.flags = IORESOURCE_MEM,
},
{
- .start = TH_MMIO_SW,
+ .start = 1, /* use resource[1] */
.end = 0,
.flags = IORESOURCE_MEM,
},
@@ -581,6 +581,7 @@ intel_th_subdevice_alloc(struct intel_th *th,
struct intel_th_device *thdev;
struct resource res[3];
unsigned int req = 0;
+ bool is64bit = false;
int r, err;
thdev = intel_th_device_alloc(th, subdev->type, subdev->name,
@@ -590,12 +591,18 @@ intel_th_subdevice_alloc(struct intel_th *th,
thdev->drvdata = th->drvdata;
+ for (r = 0; r < th->num_resources; r++)
+ if (th->resource[r].flags & IORESOURCE_MEM_64) {
+ is64bit = true;
+ break;
+ }
+
memcpy(res, subdev->res,
sizeof(struct resource) * subdev->nres);
for (r = 0; r < subdev->nres; r++) {
struct resource *devres = th->resource;
- int bar = TH_MMIO_CONFIG;
+ int bar = 0; /* cut subdevices' MMIO from resource[0] */
/*
* Take .end == 0 to mean 'take the whole bar',
@@ -604,6 +611,8 @@ intel_th_subdevice_alloc(struct intel_th *th,
*/
if (!res[r].end && res[r].flags == IORESOURCE_MEM) {
bar = res[r].start;
+ if (is64bit)
+ bar *= 2;
res[r].start = 0;
res[r].end = resource_size(&devres[bar]) - 1;
}
--
2.18.0
Commit a753bfcfdb1f ("intel_th: Make the switch allocate its subdevices")
brings in new subdevice addition/removal logic that's broken for "host
mode": the SWITCH device has no children to begin with, which is not
handled in the code. This results in a null dereference bug later down
the path.
This patch fixes the subdevice removal code to handle host mode correctly.
Signed-off-by: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Fixes: a753bfcfdb1f ("intel_th: Make the switch allocate its subdevices")
CC: stable(a)vger.kernel.org # v4.14+
---
drivers/hwtracing/intel_th/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hwtracing/intel_th/core.c b/drivers/hwtracing/intel_th/core.c
index da962aa2cef5..4e70ecee2103 100644
--- a/drivers/hwtracing/intel_th/core.c
+++ b/drivers/hwtracing/intel_th/core.c
@@ -139,7 +139,8 @@ static int intel_th_remove(struct device *dev)
th->thdev[i] = NULL;
}
- th->num_thdevs = lowest;
+ if (lowest >= 0)
+ th->num_thdevs = lowest;
}
if (thdrv->attr_group)
--
2.18.0