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
As documented in spi-mem.h, spi_mem_op->data.buf.{in,out} must be
DMA-able, and commit 4120f8d158ef ("mtd: spi-nor: Use the spi_mem_xx()
API") failed to follow this rule as buffers passed to
->{read,write}_reg() are usually placed on the stack.
Fix that by allocating a scratch buffer and copying the data around.
Fixes: 4120f8d158ef ("mtd: spi-nor: Use the spi_mem_xx() API")
Reported-by: Jarkko Nikula <jarkko.nikula(a)linux.intel.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
---
Note that the ->{read,write}() path is still buggy since nothing
guarantees that buffers passed by the MTD layer to the SPI NOR layer
are DMA-able, but this is a long-standing issue which we'll have to
address at the spi-nor level (this layer can choose the bounce buffer
size based on nor->page_size).
Changes in v2:
- Copy the data from scratchbuf in the ->read_reg() path
---
drivers/mtd/devices/m25p80.c | 26 +++++++++++++++++++++++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index cbfafc453274..270d3c9580c5 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -39,13 +39,23 @@ static int m25p80_read_reg(struct spi_nor *nor, u8 code, u8 *val, int len)
struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(code, 1),
SPI_MEM_OP_NO_ADDR,
SPI_MEM_OP_NO_DUMMY,
- SPI_MEM_OP_DATA_IN(len, val, 1));
+ SPI_MEM_OP_DATA_IN(len, NULL, 1));
+ void *scratchbuf;
int ret;
+ scratchbuf = kmalloc(len, GFP_KERNEL);
+ if (!scratchbuf)
+ return -ENOMEM;
+
+ op.data.buf.in = scratchbuf;
ret = spi_mem_exec_op(flash->spimem, &op);
if (ret < 0)
dev_err(&flash->spimem->spi->dev, "error %d reading %x\n", ret,
code);
+ else
+ memcpy(val, scratchbuf, len);
+
+ kfree(scratchbuf);
return ret;
}
@@ -56,9 +66,19 @@ static int m25p80_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len)
struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 1),
SPI_MEM_OP_NO_ADDR,
SPI_MEM_OP_NO_DUMMY,
- SPI_MEM_OP_DATA_OUT(len, buf, 1));
+ SPI_MEM_OP_DATA_OUT(len, NULL, 1));
+ void *scratchbuf;
+ int ret;
- return spi_mem_exec_op(flash->spimem, &op);
+ scratchbuf = kmemdup(buf, len, GFP_KERNEL);
+ if (!scratchbuf)
+ return -ENOMEM;
+
+ op.data.buf.out = scratchbuf;
+ ret = spi_mem_exec_op(flash->spimem, &op);
+ kfree(scratchbuf);
+
+ return ret;
}
static ssize_t m25p80_write(struct spi_nor *nor, loff_t to, size_t len,
--
2.14.1
From: "Dr. Greg Wettstein" <greg(a)wind.enjellic.com>
Functionality of the xen-tpmfront driver was lost secondary to
the introduction of xenbus multi-page support in commit ccc9d90a9a8b
("xenbus_client: Extend interface to support multi-page ring").
In this commit a pointer to the shared page address was being
passed to the xenbus_grant_ring() function rather then the
address of the shared page itself. This resulted in a situation
where the driver would attach to the vtpm-stubdom but any attempt
to send a command to the stub domain would timeout.
A diagnostic finding for this regression is the following error
message being generated when the xen-tpmfront driver probes for a
device:
<3>vtpm vtpm-0: tpm_transmit: tpm_send: error -62
<3>vtpm vtpm-0: A TPM error (-62) occurred attempting to determine
the timeouts
This fix is relevant to all kernels from 4.1 forward which is the
release in which multi-page xenbus support was introduced.
Daniel De Graaf formulated the fix by code inspection after the
regression point was located.
Fixes: ccc9d90a9a8b ("xenbus_client: Extend interface to support multi-page ring")
Signed-off-by: Dr. Greg Wettstein <greg(a)enjellic.com>
[boris: fixed commit message formatting, added Fixes tag]
Signed-off-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Cc: stable(a)vger.kernel.org # v4.1+
---
drivers/char/tpm/xen-tpmfront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/tpm/xen-tpmfront.c b/drivers/char/tpm/xen-tpmfront.c
index 911475d36800..b150f87f38f5 100644
--- a/drivers/char/tpm/xen-tpmfront.c
+++ b/drivers/char/tpm/xen-tpmfront.c
@@ -264,7 +264,7 @@ static int setup_ring(struct xenbus_device *dev, struct tpm_private *priv)
return -ENOMEM;
}
- rv = xenbus_grant_ring(dev, &priv->shr, 1, &gref);
+ rv = xenbus_grant_ring(dev, priv->shr, 1, &gref);
if (rv < 0)
return rv;
--
2.17.1
As pointed out by Daniel Vetter, we should be usinng
drm_drv_uses_atomic_modeset() for determining whether or not we want to
make the debugfs nodes for atomic instead of checking DRIVER_ATOMIC, as
the former isn't an accurate representation of whether or not the driver
is actually using atomic modesetting internally (even though it might
not be exposing atomic capabilities).
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Cc: stable(a)vger.kernel.org
---
drivers/gpu/drm/drm_atomic.c | 2 +-
drivers/gpu/drm/drm_debugfs.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3eb061e11e2e..018fcdb353d2 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -2067,7 +2067,7 @@ static void __drm_state_dump(struct drm_device *dev, struct drm_printer *p,
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
- if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
+ if (!drm_drv_uses_atomic_modeset(dev))
return;
list_for_each_entry(plane, &config->plane_list, head) {
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 6f28fe58f169..373bd4c2b698 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -151,7 +151,7 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
return ret;
}
- if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
+ if (drm_drv_uses_atomic_modeset(dev)) {
ret = drm_atomic_debugfs_init(minor);
if (ret) {
DRM_ERROR("Failed to create atomic debugfs files\n");
--
2.17.1
commit 40413955ee26 ("Cipso: cipso_v4_optptr enter infinite loop") fixed
a possible infinite loop in the IP option parsing of CIPSO. The fix
assumes that ip_options_compile filtered out all zero length options and
that no other one-byte options beside IPOPT_END and IPOPT_NOOP exist.
While this assumption currently holds true, add explicit checks for zero
length and invalid length options to be safe for the future. Even though
ip_options_compile should have validated the options, the introduction of
new one-byte options can still confuse this code without the additional
checks.
Signed-off-by: Stefan Nuernberger <snu(a)amazon.com>
Reviewed-by: David Woodhouse <dwmw(a)amazon.co.uk>
Reviewed-by: Simon Veith <sveith(a)amazon.de>
Cc: stable(a)vger.kernel.org
---
net/ipv4/cipso_ipv4.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
index 82178cc69c96..f291b57b8474 100644
--- a/net/ipv4/cipso_ipv4.c
+++ b/net/ipv4/cipso_ipv4.c
@@ -1512,7 +1512,7 @@ static int cipso_v4_parsetag_loc(const struct cipso_v4_doi *doi_def,
*
* Description:
* Parse the packet's IP header looking for a CIPSO option. Returns a pointer
- * to the start of the CIPSO option on success, NULL if one if not found.
+ * to the start of the CIPSO option on success, NULL if one is not found.
*
*/
unsigned char *cipso_v4_optptr(const struct sk_buff *skb)
@@ -1522,9 +1522,11 @@ unsigned char *cipso_v4_optptr(const struct sk_buff *skb)
int optlen;
int taglen;
- for (optlen = iph->ihl*4 - sizeof(struct iphdr); optlen > 0; ) {
+ for (optlen = iph->ihl*4 - sizeof(struct iphdr); optlen > 1; ) {
switch (optptr[0]) {
case IPOPT_CIPSO:
+ if (!optptr[1] || optptr[1] > optlen)
+ return NULL;
return optptr;
case IPOPT_END:
return NULL;
@@ -1534,6 +1536,10 @@ unsigned char *cipso_v4_optptr(const struct sk_buff *skb)
default:
taglen = optptr[1];
}
+
+ if (!taglen || taglen > optlen)
+ break;
+
optlen -= taglen;
optptr += taglen;
}
--
2.19.0
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi Greg,
Pleae pull commits for Linux 3.18 .
I've sent a review request for all commits over a week ago and all
comments were addressed.
Thanks,
Sasha
=====
The following changes since commit a5f9be3576c3f9dd871f68eaf482278c0b3a6df2:
Linux 3.18.120 (2018-08-28 07:21:37 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git tags/for-greg-3.18-17092018
for you to fetch changes up to 7058136ea11e4f5b2d0d65f6f6dbb714d2beec42:
platform/x86: toshiba_acpi: Fix defined but not used build warnings (2018-09-04 13:44:36 -0400)
- ----------------------------------------------------------------
for-greg-3.18-17092018
- ----------------------------------------------------------------
Andreas Gruenbacher (1):
gfs2: Special-case rindex for gfs2_grow
Anton Vasilyev (1):
video: goldfishfb: fix memory leak on driver remove
Bob Peterson (1):
gfs2: Don't reject a supposedly full bitmap if we have blocks reserved
Dan Carpenter (1):
fbdev: omapfb: off by one in omapfb_register_client()
Felix Fietkau (1):
MIPS: ath79: fix system restart
Fredrik Noring (1):
fbdev: Distinguish between interlaced and progressive modes
Julian Wiedmann (2):
s390/qeth: fix race in used-buffer accounting
s390/qeth: reset layer2 attribute on layer switch
Lars-Peter Clausen (1):
iio: ad9523: Fix displayed phase
Manikanta Pubbisetty (1):
mac80211: restrict delayed tailroom needed decrement
Nicholas Piggin (1):
powerpc/powernv: opal_put_chars partial write fix
Randy Dunlap (3):
mtd/maps: fix solutionengine.c printk format warnings
fbdev/via: fix defined but not used warning
platform/x86: toshiba_acpi: Fix defined but not used build warnings
Sandipan Das (2):
perf powerpc: Fix callchain ip filtering when return address is in a register
perf powerpc: Fix callchain ip filtering
Takashi Iwai (2):
ALSA: msnd: Fix the default sample sizes
ALSA: usb-audio: Fix multiple definitions in AU0828_DEVICE() macro
YueHaibing (1):
xfrm: fix 'passing zero to ERR_PTR()' warning
arch/mips/ath79/setup.c | 1 +
arch/mips/include/asm/mach-ath79/ath79.h | 1 +
arch/powerpc/platforms/powernv/opal.c | 2 +-
drivers/iio/frequency/ad9523.c | 2 +-
drivers/mtd/maps/solutionengine.c | 6 ++--
drivers/platform/x86/toshiba_acpi.c | 3 +-
drivers/s390/net/qeth_core_main.c | 3 +-
drivers/s390/net/qeth_core_sys.c | 1 +
drivers/video/fbdev/core/modedb.c | 41 +++++++++++++++++------
drivers/video/fbdev/goldfishfb.c | 1 +
drivers/video/fbdev/omap/omapfb_main.c | 2 +-
drivers/video/fbdev/via/viafbdev.c | 3 +-
fs/gfs2/bmap.c | 2 +-
fs/gfs2/rgrp.c | 3 +-
net/mac80211/cfg.c | 2 +-
net/mac80211/key.c | 24 ++++++++-----
net/xfrm/xfrm_policy.c | 5 ++-
sound/isa/msnd/msnd_pinnacle.c | 4 +--
sound/usb/quirks-table.h | 3 +-
tools/perf/arch/powerpc/util/skip-callchain-idx.c | 10 ++++--
20 files changed, 80 insertions(+), 39 deletions(-)
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAlugPO8ACgkQ3qZv95d3
LNygexAAvz2wzEaH/mDTnQ0085ODaIA6wmr/U7dlzXjoE1vPko4EOg0y8GJPmRD0
DsFkX7fqCLoLT/LQcCMK+KKq5IsPNPDs35tOvCc1T0WofnIE1KVifz4zalmW3upc
gT1HjZaza+agnw5QDs9RI0Y/y5vfR9Pwpmfi1e9V8vsNX8iR7i3YMI3HwS8g2Ggq
gjVOlH2UyiyJpqruV1B6tRwZA+KE3RNmj7xIXwvRVd29MLI0CMs/mSOo57TvGvxp
Wcn0IA0TK6T0LvNqgXNv+vjJhohfIN1TzhGiH0oEMiZVkRoHs1wqmkVQdkRPBApV
GXMGvb1suh1NE8IRl4OP/z27zZoUBr+ksoLgFD+o6tzgiBp0zR+gPV87PVzPLN32
PKyru9V0LOrF3nnCS9k6iMboFUS/vWrctrxRIdd2oUPkljPwkzxx8jz6HUNJ606B
6vPeNMBdxH1Vqiptt29Qn6c9Lg35OkOi+6JMS0WWkTPCArvHBPKOodf/4DIslm4O
2ewBiq8ewmhfUTAxxQfk+xR0+YR6d4g82Q3PvZ4jyDsSosQWnThAwLjketoTRBmc
BRcZKrqFvIMpVky0I2sl9U3ZFzlWWr2Z4PEKxu98o0AhUDCctzBHvXwL45c+7K0k
CQEs5a76ecC99mAf5AjtrbAcnTjKx9R6Y1RJ8XS9gCjT5/CMA7M=
=gANE
-----END PGP SIGNATURE-----