This is a note to let you know that I've just added the patch titled
USB: serial: cp210x: add ELDAT Easywave RX09 id
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-serial-cp210x-add-eldat-easywave-rx09-id.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 1f1e82f74c0947e40144688c9e36abe4b3999f49 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan(a)kernel.org>
Date: Tue, 6 Mar 2018 09:32:43 +0100
Subject: USB: serial: cp210x: add ELDAT Easywave RX09 id
From: Johan Hovold <johan(a)kernel.org>
commit 1f1e82f74c0947e40144688c9e36abe4b3999f49 upstream.
Add device id for ELDAT Easywave RX09 tranceiver.
Reported-by: Jan Jansen <nattelip(a)hotmail.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/serial/cp210x.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -149,6 +149,7 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(0x12B8, 0xEC62) }, /* Link G4+ ECU */
{ USB_DEVICE(0x13AD, 0x9999) }, /* Baltech card reader */
{ USB_DEVICE(0x1555, 0x0004) }, /* Owen AC4 USB-RS485 Converter */
+ { USB_DEVICE(0x155A, 0x1006) }, /* ELDAT Easywave RX09 */
{ USB_DEVICE(0x166A, 0x0201) }, /* Clipsal 5500PACA C-Bus Pascal Automation Controller */
{ USB_DEVICE(0x166A, 0x0301) }, /* Clipsal 5800PC C-Bus Wireless PC Interface */
{ USB_DEVICE(0x166A, 0x0303) }, /* Clipsal 5500PCU C-Bus USB interface */
Patches currently in stable-queue which might be from johan(a)kernel.org are
queue-3.18/usb-serial-ftdi_sio-add-support-for-harman-firmwarehubemulator.patch
queue-3.18/usb-serial-ftdi_sio-add-rt-systems-vx-8-cable.patch
queue-3.18/usb-serial-cp210x-add-eldat-easywave-rx09-id.patch
This is a note to let you know that I've just added the patch titled
parport_pc: Add support for WCH CH382L PCI-E single parallel port card.
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
parport_pc-add-support-for-wch-ch382l-pci-e-single-parallel-port-card.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 823f7923833c6cc2b16e601546d607dcfb368004 Mon Sep 17 00:00:00 2001
From: Alexander Gerasiov <gq(a)redlab-i.ru>
Date: Sun, 4 Feb 2018 02:50:22 +0300
Subject: parport_pc: Add support for WCH CH382L PCI-E single parallel port card.
From: Alexander Gerasiov <gq(a)redlab-i.ru>
commit 823f7923833c6cc2b16e601546d607dcfb368004 upstream.
WCH CH382L is a PCI-E adapter with 1 parallel port. It is similair to CH382
but serial ports are not soldered on board. Detected as
Serial controller: Device 1c00:3050 (rev 10) (prog-if 05 [16850])
Signed-off-by: Alexander Gerasiov <gq(a)redlab-i.ru>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/parport/parport_pc.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
@@ -2646,6 +2646,7 @@ enum parport_pc_pci_cards {
netmos_9901,
netmos_9865,
quatech_sppxp100,
+ wch_ch382l,
};
@@ -2708,6 +2709,7 @@ static struct parport_pc_pci {
/* netmos_9901 */ { 1, { { 0, -1 }, } },
/* netmos_9865 */ { 1, { { 0, -1 }, } },
/* quatech_sppxp100 */ { 1, { { 0, 1 }, } },
+ /* wch_ch382l */ { 1, { { 2, -1 }, } },
};
static const struct pci_device_id parport_pc_pci_tbl[] = {
@@ -2797,6 +2799,8 @@ static const struct pci_device_id parpor
/* Quatech SPPXP-100 Parallel port PCI ExpressCard */
{ PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_SPPXP_100,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, quatech_sppxp100 },
+ /* WCH CH382L PCI-E single parallel port card */
+ { 0x1c00, 0x3050, 0x1c00, 0x3050, 0, 0, wch_ch382l },
{ 0, } /* terminate list */
};
MODULE_DEVICE_TABLE(pci, parport_pc_pci_tbl);
Patches currently in stable-queue which might be from gq(a)redlab-i.ru are
queue-3.18/parport_pc-add-support-for-wch-ch382l-pci-e-single-parallel-port-card.patch
This is a note to let you know that I've just added the patch titled
USB: serial: ftdi_sio: add RT Systems VX-8 cable
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-serial-ftdi_sio-add-rt-systems-vx-8-cable.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 9608e5c0f079390473b484ef92334dfd3431bb89 Mon Sep 17 00:00:00 2001
From: Major Hayden <major(a)mhtx.net>
Date: Fri, 23 Feb 2018 14:29:54 -0600
Subject: USB: serial: ftdi_sio: add RT Systems VX-8 cable
From: Major Hayden <major(a)mhtx.net>
commit 9608e5c0f079390473b484ef92334dfd3431bb89 upstream.
This patch adds a device ID for the RT Systems cable used to
program Yaesu VX-8R/VX-8DR handheld radios. It uses the main
FTDI VID instead of the common RT Systems VID.
Signed-off-by: Major Hayden <major(a)mhtx.net>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 3 +++
2 files changed, 4 insertions(+)
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -773,6 +773,7 @@ static const struct usb_device_id id_tab
.driver_info = (kernel_ulong_t)&ftdi_NDI_device_quirk },
{ USB_DEVICE(TELLDUS_VID, TELLDUS_TELLSTICK_PID) },
{ USB_DEVICE(NOVITUS_VID, NOVITUS_BONO_E_PID) },
+ { USB_DEVICE(FTDI_VID, RTSYSTEMS_USB_VX8_PID) },
{ USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_S03_PID) },
{ USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_59_PID) },
{ USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_57A_PID) },
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -903,6 +903,9 @@
/*
* RT Systems programming cables for various ham radios
*/
+/* This device uses the VID of FTDI */
+#define RTSYSTEMS_USB_VX8_PID 0x9e50 /* USB-VX8 USB to 7 pin modular plug for Yaesu VX-8 radio */
+
#define RTSYSTEMS_VID 0x2100 /* Vendor ID */
#define RTSYSTEMS_USB_S03_PID 0x9001 /* RTS-03 USB to Serial Adapter */
#define RTSYSTEMS_USB_59_PID 0x9e50 /* USB-59 USB to 8 pin plug */
Patches currently in stable-queue which might be from major(a)mhtx.net are
queue-3.18/usb-serial-ftdi_sio-add-rt-systems-vx-8-cable.patch
This is a note to let you know that I've just added the patch titled
media: usbtv: prevent double free in error case
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-usbtv-prevent-double-free-in-error-case.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 50e7044535537b2a54c7ab798cd34c7f6d900bd2 Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum(a)suse.com>
Date: Mon, 8 Jan 2018 09:21:07 -0500
Subject: media: usbtv: prevent double free in error case
From: Oliver Neukum <oneukum(a)suse.com>
commit 50e7044535537b2a54c7ab798cd34c7f6d900bd2 upstream.
Quoting the original report:
It looks like there is a double-free vulnerability in Linux usbtv driver
on an error path of usbtv_probe function. When audio registration fails,
usbtv_video_free function ends up freeing usbtv data structure, which
gets freed the second time under usbtv_video_fail label.
usbtv_audio_fail:
usbtv_video_free(usbtv); =>
v4l2_device_put(&usbtv->v4l2_dev);
=> v4l2_device_put
=> kref_put
=> v4l2_device_release
=> usbtv_release (CALLBACK)
=> kfree(usbtv) (1st time)
usbtv_video_fail:
usb_set_intfdata(intf, NULL);
usb_put_dev(usbtv->udev);
kfree(usbtv); (2nd time)
So, as we have refcounting, use it
Reported-by: Yavuz, Tuba <tuba(a)ece.ufl.edu>
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
CC: stable(a)vger.kernel.org
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/usb/usbtv/usbtv-core.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/media/usb/usbtv/usbtv-core.c
+++ b/drivers/media/usb/usbtv/usbtv-core.c
@@ -95,6 +95,8 @@ static int usbtv_probe(struct usb_interf
return 0;
usbtv_audio_fail:
+ /* we must not free at this point */
+ usb_get_dev(usbtv->udev);
usbtv_video_free(usbtv);
usbtv_video_fail:
Patches currently in stable-queue which might be from oneukum(a)suse.com are
queue-3.18/media-usbtv-prevent-double-free-in-error-case.patch
This is a note to let you know that I've just added the patch titled
mei: remove dev_err message on an unsupported ioctl
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mei-remove-dev_err-message-on-an-unsupported-ioctl.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From bb0829a741792b56c908d7745bc0b2b540293bcc Mon Sep 17 00:00:00 2001
From: Colin Ian King <colin.king(a)canonical.com>
Date: Tue, 27 Feb 2018 16:21:05 +0000
Subject: mei: remove dev_err message on an unsupported ioctl
From: Colin Ian King <colin.king(a)canonical.com>
commit bb0829a741792b56c908d7745bc0b2b540293bcc upstream.
Currently the driver spams the kernel log on unsupported ioctls which is
unnecessary as the ioctl returns -ENOIOCTLCMD to indicate this anyway.
I suspect this was originally for debugging purposes but it really is not
required so remove it.
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/misc/mei/main.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/misc/mei/main.c
+++ b/drivers/misc/mei/main.c
@@ -556,7 +556,6 @@ static long mei_ioctl(struct file *file,
break;
default:
- dev_err(dev->dev, ": unsupported ioctl %d.\n", cmd);
rets = -ENOIOCTLCMD;
}
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-3.18/mei-remove-dev_err-message-on-an-unsupported-ioctl.patch
This is a note to let you know that I've just added the patch titled
crypto: ahash - Fix early termination in hash walk
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-ahash-fix-early-termination-in-hash-walk.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 900a081f6912a8985dc15380ec912752cb66025a Mon Sep 17 00:00:00 2001
From: Herbert Xu <herbert(a)gondor.apana.org.au>
Date: Mon, 26 Mar 2018 08:53:25 +0800
Subject: crypto: ahash - Fix early termination in hash walk
From: Herbert Xu <herbert(a)gondor.apana.org.au>
commit 900a081f6912a8985dc15380ec912752cb66025a upstream.
When we have an unaligned SG list entry where there is no leftover
aligned data, the hash walk code will incorrectly return zero as if
the entire SG list has been processed.
This patch fixes it by moving onto the next page instead.
Reported-by: Eli Cooper <elicooper(a)gmx.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/ahash.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -90,13 +90,14 @@ int crypto_hash_walk_done(struct crypto_
if (nbytes && walk->offset & alignmask && !err) {
walk->offset = ALIGN(walk->offset, alignmask + 1);
- walk->data += walk->offset;
-
nbytes = min(nbytes,
((unsigned int)(PAGE_SIZE)) - walk->offset);
walk->entrylen -= nbytes;
- return nbytes;
+ if (nbytes) {
+ walk->data += walk->offset;
+ return nbytes;
+ }
}
if (walk->flags & CRYPTO_ALG_ASYNC)
Patches currently in stable-queue which might be from herbert(a)gondor.apana.org.au are
queue-3.18/crypto-x86-cast5-avx-fix-ecb-encryption-when-long-sg-follows-short-one.patch
queue-3.18/crypto-ahash-fix-early-termination-in-hash-walk.patch
This is a note to let you know that I've just added the patch titled
crypto: x86/cast5-avx - fix ECB encryption when long sg follows short one
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-x86-cast5-avx-fix-ecb-encryption-when-long-sg-follows-short-one.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 8f461b1e02ed546fbd0f11611138da67fd85a30f Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Mon, 19 Feb 2018 23:48:12 -0800
Subject: crypto: x86/cast5-avx - fix ECB encryption when long sg follows short one
From: Eric Biggers <ebiggers(a)google.com>
commit 8f461b1e02ed546fbd0f11611138da67fd85a30f upstream.
With ecb-cast5-avx, if a 128+ byte scatterlist element followed a
shorter one, then the algorithm accidentally encrypted/decrypted only 8
bytes instead of the expected 128 bytes. Fix it by setting the
encryption/decryption 'fn' correctly.
Fixes: c12ab20b162c ("crypto: cast5/avx - avoid using temporary stack buffers")
Cc: <stable(a)vger.kernel.org> # v3.8+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/crypto/cast5_avx_glue.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/arch/x86/crypto/cast5_avx_glue.c
+++ b/arch/x86/crypto/cast5_avx_glue.c
@@ -67,8 +67,6 @@ static int ecb_crypt(struct blkcipher_de
void (*fn)(struct cast5_ctx *ctx, u8 *dst, const u8 *src);
int err;
- fn = (enc) ? cast5_ecb_enc_16way : cast5_ecb_dec_16way;
-
err = blkcipher_walk_virt(desc, walk);
desc->flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP;
@@ -80,6 +78,7 @@ static int ecb_crypt(struct blkcipher_de
/* Process multi-block batch */
if (nbytes >= bsize * CAST5_PARALLEL_BLOCKS) {
+ fn = (enc) ? cast5_ecb_enc_16way : cast5_ecb_dec_16way;
do {
fn(ctx, wdst, wsrc);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-3.18/crypto-x86-cast5-avx-fix-ecb-encryption-when-long-sg-follows-short-one.patch
queue-3.18/libata-fix-length-validation-of-atapi-relayed-scsi-commands.patch
queue-3.18/libata-remove-warn-for-dma-or-pio-command-without-data.patch
Hi Greg,
These patches backport KPTI to v4.9.y (based on v4.9.92), providing protection
against meltdown on arm64 platforms.
I picked up Alex Shi's backport for review and testing, and as I found a couple
of issues to fix up, I'm sending this with my Signed-off-by in the chain, with
those fixups applied and noted.
To the best of my understanding the code is correct, in the context of the
v4.9.y kernel, and I've tested the seires on arm64 hardware available to me.
i.e. if this didn't have my Signed-off-by it would have my Reviewed-by and
Tested-by tags.
Are you happy to pick these up for v4.9.93?
Thanks,
Mark.
AKASHI Takahiro (1):
module: extend 'rodata=off' boot cmdline parameter to module mappings
Jayachandran C (2):
arm64: cputype: Add MIDR values for Cavium ThunderX2 CPUs
arm64: Turn on KPTI only on CPUs that need it
Marc Zyngier (2):
arm64: Allow checking of a CPU-local erratum
arm64: Force KPTI to be disabled on Cavium ThunderX
Mark Rutland (1):
arm64: factor out entry stack manipulation
Suzuki K Poulose (1):
arm64: capabilities: Handle duplicate entries for a capability
Will Deacon (20):
arm64: mm: Use non-global mappings for kernel space
arm64: mm: Move ASID from TTBR0 to TTBR1
arm64: mm: Allocate ASIDs in pairs
arm64: mm: Add arm64_kernel_unmapped_at_el0 helper
arm64: mm: Invalidate both kernel and user ASIDs when performing TLBI
arm64: entry: Add exception trampoline page for exceptions from EL0
arm64: mm: Map entry trampoline into trampoline and kernel page tables
arm64: entry: Explicitly pass exception level to kernel_ventry macro
arm64: entry: Hook up entry trampoline to exception vectors
arm64: tls: Avoid unconditional zeroing of tpidrro_el0 for native
tasks
arm64: entry: Add fake CPU feature for unmapping the kernel at EL0
arm64: kaslr: Put kernel vectors address in separate data page
arm64: use RET instruction for exiting the trampoline
arm64: Kconfig: Add CONFIG_UNMAP_KERNEL_AT_EL0
arm64: Kconfig: Reword UNMAP_KERNEL_AT_EL0 kconfig entry
arm64: Take into account ID_AA64PFR0_EL1.CSV3
arm64: kpti: Make use of nG dependent on
arm64_kernel_unmapped_at_el0()
arm64: kpti: Add ->enable callback to remap swapper using nG mappings
arm64: entry: Reword comment about post_ttbr_update_workaround
arm64: idmap: Use "awx" flags for .idmap.text .pushsection directives
arch/arm64/Kconfig | 12 ++
arch/arm64/include/asm/assembler.h | 3 +
arch/arm64/include/asm/cpucaps.h | 3 +-
arch/arm64/include/asm/cputype.h | 3 +
arch/arm64/include/asm/fixmap.h | 6 +
arch/arm64/include/asm/mmu.h | 11 ++
arch/arm64/include/asm/mmu_context.h | 7 ++
arch/arm64/include/asm/pgtable-hwdef.h | 1 +
arch/arm64/include/asm/pgtable-prot.h | 35 +++---
arch/arm64/include/asm/pgtable.h | 1 +
arch/arm64/include/asm/proc-fns.h | 6 -
arch/arm64/include/asm/sysreg.h | 1 +
arch/arm64/include/asm/tlbflush.h | 16 ++-
arch/arm64/kernel/asm-offsets.c | 6 +-
arch/arm64/kernel/cpu-reset.S | 2 +-
arch/arm64/kernel/cpufeature.c | 135 ++++++++++++++++++---
arch/arm64/kernel/entry.S | 188 ++++++++++++++++++++++++----
arch/arm64/kernel/head.S | 2 +-
arch/arm64/kernel/process.c | 12 +-
arch/arm64/kernel/sleep.S | 2 +-
arch/arm64/kernel/vmlinux.lds.S | 22 +++-
arch/arm64/mm/context.c | 25 ++--
arch/arm64/mm/mmu.c | 31 +++++
arch/arm64/mm/proc.S | 216 +++++++++++++++++++++++++++++++--
include/linux/init.h | 3 +
init/main.c | 7 +-
kernel/module.c | 20 ++-
27 files changed, 675 insertions(+), 101 deletions(-)
--
2.11.0
Hi.
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 9.9156)
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126,
v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Build OK!
v4.4.126: Build OK!
Please let us know if you'd like to have this patch included in a stable tree.
--
Thanks.
Sasha
As it turns out, the aux block being off was not the real problem here,
as transition from D3 to D0 is mandated by the DP spec to take a maximum
of 1ms, whereas we're allowed a 100ms timeframe to respond to ESI irqs.
The real problem here is a bit more subtle.
When doing a modeset where the problem of the sink timing out to our
sideband requests when transitioning from D3 to D0 occurs, the timeout
is from the aux block not coming on. However, nothing else times out
other than the initial phy_up message because the DPCD on call in
intel_ddi_enable_dp() ends up waking up the AUX block on the hub, not
the phy_up sideband message. This means that the real fix we need is to
use the DPMS on before sending a phy_up to ensure that the hub is ready
to accept sideband messages.
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com>
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: Laura Abbott <labbott(a)redhat.com>
Cc: stable(a)vger.kernel.org
Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")
---
drivers/gpu/drm/i915/intel_ddi.c | 6 +++++-
drivers/gpu/drm/i915/intel_dp_mst.c | 1 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a6672a9abd85..9bd675f73f7b 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2324,7 +2324,11 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
intel_prepare_dp_ddi_buffers(encoder, crtc_state);
intel_ddi_init_dp_buf_reg(encoder);
- intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+ /* for MST, we do DPMS_ON outside of here so that DPMS_ON can happen
+ * before drm_dp_send_power_updown_phy()
+ */
+ if (!intel_dp->is_mst)
+ intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_start_link_train(intel_dp);
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
index c3de0918ee13..eff9a4eae1f0 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -223,6 +223,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder *encoder,
DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
+ intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
drm_dp_send_power_updown_phy(&intel_dp->mst_mgr, connector->port, true);
if (intel_dp->active_mst_links == 0)
intel_dig_port->base.pre_enable(&intel_dig_port->base,
--
2.14.3
Hi.
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 9.2381)
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126,
v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Build OK!
v4.4.126: Build OK!
Please let us know if you'd like to have this patch included in a stable tree.
--
Thanks.
Sasha
Hi.
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 10.6103)
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126,
v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Build OK!
v4.4.126: Failed to apply! Possible dependencies:
f0f1beb8f155 ("usbip: vhci_hcd: Fix usb device and sockfd leaks")
Please let us know if you'd like to have this patch included in a stable tree.
--
Thanks.
Sasha
Hi.
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 11.8806)
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126,
v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Failed to apply! Possible dependencies:
506a7be93ff7 ("clocksource/drivers/imx-tpm: Correct some registers operation flow")
v4.4.126: Failed to apply! Possible dependencies:
506a7be93ff7 ("clocksource/drivers/imx-tpm: Correct some registers operation flow")
Please let us know if you'd like to have this patch included in a stable tree.
--
Thanks.
Sasha
Hi.
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 16.4885)
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126,
v4.15.15: Failed to apply! Possible dependencies:
e2a7b77d89f6 ("MIPS: perf: Fix perf with MT counting other threads")
v4.14.32: Failed to apply! Possible dependencies:
e2a7b77d89f6 ("MIPS: perf: Fix perf with MT counting other threads")
v4.9.92: Failed to apply! Possible dependencies:
4e099ca64578 ("MIPS: perf: Use correct VPE ID when setting up VPE tracing")
e2a7b77d89f6 ("MIPS: perf: Fix perf with MT counting other threads")
v4.4.126: Failed to apply! Possible dependencies:
4e099ca64578 ("MIPS: perf: Use correct VPE ID when setting up VPE tracing")
e2a7b77d89f6 ("MIPS: perf: Fix perf with MT counting other threads")
Please let us know if you'd like to have this patch included in a stable tree.
--
Thanks.
Sasha
Hi.
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 7.7428)
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126,
v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Build OK!
v4.4.126: Failed to apply! Possible dependencies:
dddf796db4e3 ("MIPS: perf: More robustly probe for the presence of per-tc counters")
Please let us know if you'd like to have this patch included in a stable tree.
--
Thanks.
Sasha
Hi.
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 8.8219)
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126,
v4.15.15: Failed to apply! Possible dependencies:
808260f0b5d6 ("usb: dwc2: gadget: Change default values")
v4.14.32: Failed to apply! Possible dependencies:
808260f0b5d6 ("usb: dwc2: gadget: Change default values")
v4.9.92: Failed to apply! Possible dependencies:
6f80b6de0ecf ("usb: dwc2: Add core parameters for LPM support")
808260f0b5d6 ("usb: dwc2: gadget: Change default values")
v4.4.126: Failed to apply! Possible dependencies:
6f80b6de0ecf ("usb: dwc2: Add core parameters for LPM support")
808260f0b5d6 ("usb: dwc2: gadget: Change default values")
Please let us know if you'd like to have this patch included in a stable tree.
--
Thanks.
Sasha
Hi.
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 8.8219)
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126,
v4.15.15: Failed to apply! Possible dependencies:
9fca971e94df ("usb: dwc2: gadget: Change default values")
v4.14.32: Failed to apply! Possible dependencies:
9fca971e94df ("usb: dwc2: gadget: Change default values")
v4.9.92: Failed to apply! Possible dependencies:
6f80b6de0ecf ("usb: dwc2: Add core parameters for LPM support")
9fca971e94df ("usb: dwc2: gadget: Change default values")
v4.4.126: Failed to apply! Possible dependencies:
6f80b6de0ecf ("usb: dwc2: Add core parameters for LPM support")
9fca971e94df ("usb: dwc2: gadget: Change default values")
Please let us know if you'd like to have this patch included in a stable tree.
--
Thanks.
Sasha
Hi.
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 83.4612)
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126,
v4.15.15: Failed to apply! Possible dependencies:
40b3b88a117c ("soc: mediatek: reuse read[l,x]_poll_timeout helpers")
v4.14.32: Failed to apply! Possible dependencies:
40b3b88a117c ("soc: mediatek: reuse read[l,x]_poll_timeout helpers")
v4.9.92: Failed to apply! Possible dependencies:
40b3b88a117c ("soc: mediatek: reuse read[l,x]_poll_timeout helpers")
52510ee93488 ("soc: mediatek: add SCPSYS power domain driver for MediaTek MT7622 SoC")
v4.4.126: Failed to apply! Possible dependencies:
40b3b88a117c ("soc: mediatek: reuse read[l,x]_poll_timeout helpers")
52510ee93488 ("soc: mediatek: add SCPSYS power domain driver for MediaTek MT7622 SoC")
Please let us know if you'd like to have this patch included in a stable tree.
--
Thanks.
Sasha
Hi.
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 72b39cfc4d75 ("mm, memory_hotplug: do not fail offlining too early").
The bot has also determined it's probably a bug fixing patch. (score: 77.7460)
The bot has tested the following trees: v4.15.15 .
v4.15.15: Build OK!
--
Thanks.
Sasha
Hi.
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 30.1120)
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126,
v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Build OK!
v4.4.126: Build OK!
Please let us know if you'd like to have this patch included in a stable tree.
--
Thanks.
Sasha
While enabling/disabling DPMS before link training with MST hubs is
perfectly valid; unfortunately disabling DPMS results in some devices
disabling their AUX CH block as well. For SST this isn't as much of a
problem, but for MST we need to be able to continue handling aux
transactions even when none of the sinks are turned on since it's
possible for us to have a single atomic commit which results in
disabling each downstream sink, followed by subsequently re-enabling
each sink.
If we don't do this, we'll end up stalling any pending ESI interrupts
from the sink for up to 1ms. Unfortunately, dropping ESIs during this
timespan makes it so that link fallback retraining for MST (which I will
be submitting to the ML shortly) fails due to the channel EQ failure
interrupts potentially getting dropped. Additionally, when performing a
modeset that brings the hub status's link status from bad -> good having
ESIs disabled for that long causes us to miss the hub's response to us
trying to start link training as well.
Since any sink with MST is going to support DisplayPort 1.2 anyway, save
us the hassle of trying to wait until the sink comes back up and just
never shut the aux block down.
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Cc: Laura Abbott <labbott(a)redhat.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com>
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: stable(a)vger.kernel.org
Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")
---
drivers/gpu/drm/i915/intel_dp.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 62f82c4298ac..0479c377981b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
return;
if (mode != DRM_MODE_DPMS_ON) {
+ unsigned char data = intel_dp->is_mst ?
+ DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3;
+
if (downstream_hpd_needs_d0(intel_dp))
return;
- ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER,
- DP_SET_POWER_D3);
+ ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, data);
} else {
struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
--
2.14.3
Hi.
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has also determined it's probably a bug fixing patch. (score: 98.8113)
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126,
v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Build OK!
v4.4.126: Build OK!
Please let us know if you'd like to have this patch included in a stable tree.
--
Thanks.
Sasha
Hi.
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 6.9494)
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126,
v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Build OK!
v4.4.126: Build OK!
Please let us know if you'd like to have this patch included in a stable tree.
--
Thanks.
Sasha