This is the start of the stable review cycle for the 5.4.3 release.
There are 92 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Fri, 13 Dec 2019 14:56:06 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.3-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 5.4.3-rc1
Jann Horn <[email protected]>
binder: Handle start==NULL in binder_update_page_range()
Jann Horn <[email protected]>
binder: Prevent repeated use of ->mmap() via NULL mapping
Jann Horn <[email protected]>
binder: Fix race between mmap() and binder_alloc_print_pages()
Je Yen Tam <[email protected]>
Revert "serial/8250: Add support for NI-Serial PXI/PXIe+485 devices"
Nicolas Pitre <[email protected]>
vcs: prevent write access to vcsu devices
Wei Wang <[email protected]>
thermal: Fix deadlock in thermal thermal_zone_device_check
Jan Kara <[email protected]>
iomap: Fix pipe page leakage during splicing
Jan Kara <[email protected]>
bdev: Refresh bdev size for disks without partitioning
Jan Kara <[email protected]>
bdev: Factor out bdev revalidation into a common helper
Marcel Holtmann <[email protected]>
rfkill: allocate static minor
Viresh Kumar <[email protected]>
RDMA/qib: Validate ->show()/store() callbacks before calling them
Johan Hovold <[email protected]>
can: ucan: fix non-atomic allocation in completion handler
Gregory CLEMENT <[email protected]>
spi: Fix NULL pointer when setting SPI_CS_HIGH for GPIO CS
Gregory CLEMENT <[email protected]>
spi: Fix SPI_CS_HIGH setting when using native and GPIO CS
Gregory CLEMENT <[email protected]>
spi: atmel: Fix CS high support
Patrice Chotard <[email protected]>
spi: stm32-qspi: Fix kernel oops when unbinding driver
Frieder Schrempf <[email protected]>
spi: spi-fsl-qspi: Clear TDH bits in FLSHCR register
Navid Emamdoost <[email protected]>
crypto: user - fix memory leak in crypto_reportstat
Navid Emamdoost <[email protected]>
crypto: user - fix memory leak in crypto_report
Ard Biesheuvel <[email protected]>
crypto: ecdh - fix big endian bug in ECC library
Mark Salter <[email protected]>
crypto: ccp - fix uninitialized list head
Ard Biesheuvel <[email protected]>
crypto: geode-aes - switch to skcipher for cbc(aes) fallback
Ayush Sawal <[email protected]>
crypto: af_alg - cast ki_complete ternary op to int
Tudor Ambarus <[email protected]>
crypto: atmel-aes - Fix IV handling when req->nbytes < ivsize
Christian Lamparter <[email protected]>
crypto: crypto4xx - fix double-free in crypto4xx_destroy_sdr
Sean Christopherson <[email protected]>
KVM: x86: Grab KVM's srcu lock when setting nested state
Sean Christopherson <[email protected]>
KVM: x86: Remove a spurious export of a static function
Paolo Bonzini <[email protected]>
KVM: x86: fix presentation of TSX feature in ARCH_CAPABILITIES
Paolo Bonzini <[email protected]>
KVM: x86: do not modify masked bits of shared MSRs
Zenghui Yu <[email protected]>
KVM: arm/arm64: vgic: Don't rely on the wrong pending table
Sean Christopherson <[email protected]>
KVM: nVMX: Always write vmcs02.GUEST_CR3 during nested VM-Enter
Greg Kurz <[email protected]>
KVM: PPC: Book3S HV: XIVE: Set kvm->arch.xive when VPs are allocated
Greg Kurz <[email protected]>
KVM: PPC: Book3S HV: XIVE: Fix potential page leak on error path
Greg Kurz <[email protected]>
KVM: PPC: Book3S HV: XIVE: Free previous EQ page when setting up a new one
Marek Szyprowski <[email protected]>
arm64: dts: exynos: Revert "Remove unneeded address space mapping for soc node"
Catalin Marinas <[email protected]>
arm64: Validate tagged addresses in access_ok() called from kernel threads
Dan Carpenter <[email protected]>
drm/i810: Prevent underflow in ioctl
Sean Paul <[email protected]>
drm: damage_helper: Fix race checking plane->state->fb
Johan Hovold <[email protected]>
drm/msm: fix memleak on release
Jan Kara <[email protected]>
jbd2: Fix possible overflow in jbd2_log_space_left()
Tejun Heo <[email protected]>
kernfs: fix ino wrap-around detection
J. Bruce Fields <[email protected]>
nfsd: restore NFSv3 ACL support
Trond Myklebust <[email protected]>
nfsd: Ensure CLONE persists data and metadata changes to the target file
Jouni Hogander <[email protected]>
can: slcan: Fix use-after-free Read in slcan_open
Dmitry Torokhov <[email protected]>
tty: vt: keyboard: reject invalid keycodes
Pavel Shilovsky <[email protected]>
CIFS: Fix SMB2 oplock break processing
Pavel Shilovsky <[email protected]>
CIFS: Fix NULL-pointer dereference in smb2_push_mandatory_locks
Kai-Heng Feng <[email protected]>
x86/PCI: Avoid AMD FCH XHCI USB PME# from D0 defect
Joerg Roedel <[email protected]>
x86/mm/32: Sync only to VMALLOC_END in vmalloc_sync_all()
Sean Young <[email protected]>
media: rc: mark input device as pointing stick
Navid Emamdoost <[email protected]>
Input: Fix memory leak in psxpad_spi_probe
Mike Leach <[email protected]>
coresight: etm4x: Fix input validation for sysfs.
Hans de Goede <[email protected]>
Input: goodix - add upside-down quirk for Teclast X89 tablet
Hans Verkuil <[email protected]>
Input: synaptics-rmi4 - don't increment rmiaddr for SMBus transfers
Lucas Stach <[email protected]>
Input: synaptics-rmi4 - re-enable IRQs in f34v7_do_reflash
Hans Verkuil <[email protected]>
Input: synaptics - switch another X1 Carbon 6 to RMI/SMbus
Bibby Hsieh <[email protected]>
soc: mediatek: cmdq: fixup wrong input order of write api
Takashi Iwai <[email protected]>
ALSA: hda: Modify stream stripe mask only when needed
Kai-Heng Feng <[email protected]>
ALSA: hda - Add mute led support for HP ProBook 645 G4
Takashi Iwai <[email protected]>
ALSA: pcm: oss: Avoid potential buffer overflows
Takashi Iwai <[email protected]>
ALSA: hda/realtek - Fix inverted bass GPIO pin on Acer 8951G
Kailang Yang <[email protected]>
ALSA: hda/realtek - Dell headphone has noise on unmute for ALC236
Hui Wang <[email protected]>
ALSA: hda/realtek - Enable the headset-mic on a Xiaomi's laptop
Jian-Hong Pan <[email protected]>
ALSA: hda/realtek - Enable internal speaker of ASUS UX431FLC
Trond Myklebust <[email protected]>
SUNRPC: Avoid RPC delays when exiting suspend
Jens Axboe <[email protected]>
io_uring: ensure req->submit is copied when req is deferred
Jens Axboe <[email protected]>
io_uring: fix missing kmap() declaration on powerpc
Miklos Szeredi <[email protected]>
fuse: verify attributes
Miklos Szeredi <[email protected]>
fuse: verify write return
Miklos Szeredi <[email protected]>
fuse: verify nlink
Miklos Szeredi <[email protected]>
fuse: fix leak of fuse_io_priv
Jens Axboe <[email protected]>
io_uring: transform send/recvmsg() -ERESTARTSYS to -EINTR
Pavel Begunkov <[email protected]>
io_uring: fix dead-hung for non-iter fixed rw
Ulf Hansson <[email protected]>
mwifiex: Re-work support for SDIO HW reset
Chuhong Yuan <[email protected]>
serial: ifx6x60: add missed pm_runtime_disable
Andy Shevchenko <[email protected]>
serial: 8250_dw: Avoid double error messaging when IRQ absent
Fabrice Gasnier <[email protected]>
serial: stm32: fix clearing interrupt error flags
Jiangfeng Xiao <[email protected]>
serial: serial_core: Perform NULL checks for break_ctl ops
Vincent Whitchurch <[email protected]>
serial: pl011: Fix DMA ->flush_buffer()
Jeffrey Hugo <[email protected]>
tty: serial: msm_serial: Fix flow control
Peng Fan <[email protected]>
tty: serial: fsl_lpuart: use the sg count from dma_map_sg
Frank Wunderlich <[email protected]>
serial: 8250-mtk: Use platform_get_irq_optional() for optional irq
Michał Mirosław <[email protected]>
usb: gadget: u_serial: add missing port entry locking
Paul Burton <[email protected]>
staging/octeon: Use stubs for MIPS && !CAVIUM_OCTEON_SOC
Jon Hunter <[email protected]>
mailbox: tegra: Fix superfluous IRQ error message
Dmitry Safonov <[email protected]>
time: Zero the upper 32-bits in __kernel_timespec on 32-bit
Arnd Bergmann <[email protected]>
lp: fix sparc64 LPSETTIMEOUT ioctl
Tuowen Zhao <[email protected]>
sparc64: implement ioremap_uc
Adrian Hunter <[email protected]>
perf scripts python: exported-sql-viewer.py: Fix use of TRUE with SQLite
Jon Hunter <[email protected]>
arm64: tegra: Fix 'active-low' warning for Jetson Xavier regulator
Jon Hunter <[email protected]>
arm64: tegra: Fix 'active-low' warning for Jetson TX1 regulator
Navid Emamdoost <[email protected]>
rsi: release skb if rsi_prepare_beacon fails
-------------
Diffstat:
Makefile | 4 +-
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 6 +-
arch/arm64/boot/dts/exynos/exynos7.dtsi | 6 +-
arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 3 +-
arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi | 2 +-
arch/arm64/include/asm/uaccess.h | 7 +-
arch/powerpc/kvm/book3s_xive.c | 11 +-
arch/powerpc/kvm/book3s_xive_native.c | 46 ++--
arch/sparc/include/asm/io_64.h | 1 +
arch/x86/kvm/vmx/nested.c | 10 +
arch/x86/kvm/vmx/vmx.c | 10 +-
arch/x86/kvm/x86.c | 17 +-
arch/x86/mm/fault.c | 2 +-
arch/x86/pci/fixup.c | 11 +
crypto/af_alg.c | 2 +-
crypto/crypto_user_base.c | 4 +-
crypto/crypto_user_stat.c | 4 +-
crypto/ecc.c | 3 +-
drivers/android/binder_alloc.c | 41 +--
drivers/char/lp.c | 4 +
drivers/crypto/amcc/crypto4xx_core.c | 6 +-
drivers/crypto/atmel-aes.c | 53 ++--
drivers/crypto/ccp/ccp-dmaengine.c | 1 +
drivers/crypto/geode-aes.c | 57 ++--
drivers/crypto/geode-aes.h | 2 +-
drivers/gpu/drm/drm_damage_helper.c | 8 +-
drivers/gpu/drm/i810/i810_dma.c | 4 +-
drivers/gpu/drm/msm/msm_debugfs.c | 6 +-
.../hwtracing/coresight/coresight-etm4x-sysfs.c | 21 +-
drivers/infiniband/hw/qib/qib_sysfs.c | 6 +
drivers/input/joystick/psxpad-spi.c | 2 +-
drivers/input/mouse/synaptics.c | 1 +
drivers/input/rmi4/rmi_f34v7.c | 3 +
drivers/input/rmi4/rmi_smbus.c | 2 -
drivers/input/touchscreen/goodix.c | 9 +
drivers/mailbox/tegra-hsp.c | 4 +-
drivers/media/rc/rc-main.c | 1 +
drivers/net/can/slcan.c | 1 +
drivers/net/can/usb/ucan.c | 2 +-
drivers/net/wireless/marvell/mwifiex/main.c | 5 +-
drivers/net/wireless/marvell/mwifiex/main.h | 1 +
drivers/net/wireless/marvell/mwifiex/sdio.c | 33 ++-
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 1 +
drivers/soc/mediatek/mtk-cmdq-helper.c | 2 +-
drivers/spi/spi-atmel.c | 6 +-
drivers/spi/spi-fsl-qspi.c | 38 ++-
drivers/spi/spi-stm32-qspi.c | 3 +-
drivers/spi/spi.c | 19 +-
drivers/staging/octeon/octeon-ethernet.h | 2 +-
drivers/staging/octeon/octeon-stubs.h | 5 +-
drivers/thermal/thermal_core.c | 4 +-
drivers/tty/serial/8250/8250_dw.c | 8 +-
drivers/tty/serial/8250/8250_mtk.c | 2 +-
drivers/tty/serial/8250/8250_pci.c | 292 +--------------------
drivers/tty/serial/amba-pl011.c | 6 +-
drivers/tty/serial/fsl_lpuart.c | 4 +-
drivers/tty/serial/ifx6x60.c | 3 +
drivers/tty/serial/msm_serial.c | 6 +-
drivers/tty/serial/serial_core.c | 2 +-
drivers/tty/serial/stm32-usart.c | 6 +-
drivers/tty/vt/keyboard.c | 2 +-
drivers/tty/vt/vc_screen.c | 3 +
drivers/usb/gadget/function/u_serial.c | 2 +
fs/block_dev.c | 37 +--
fs/cifs/file.c | 7 +-
fs/cifs/smb2misc.c | 7 +-
fs/fuse/dir.c | 25 +-
fs/fuse/file.c | 6 +-
fs/fuse/fuse_i.h | 2 +
fs/fuse/readdir.c | 2 +-
fs/io_uring.c | 27 +-
fs/iomap/direct-io.c | 9 +-
fs/kernfs/dir.c | 5 +-
fs/nfsd/nfs4proc.c | 3 +-
fs/nfsd/nfssvc.c | 3 +-
fs/nfsd/vfs.c | 8 +-
fs/nfsd/vfs.h | 2 +-
include/linux/jbd2.h | 4 +-
include/linux/kernfs.h | 1 +
include/linux/miscdevice.h | 1 +
include/sound/hdaudio.h | 1 +
kernel/time/time.c | 3 +-
net/rfkill/core.c | 9 +-
net/sunrpc/sched.c | 2 +-
sound/core/oss/linear.c | 2 +
sound/core/oss/mulaw.c | 2 +
sound/core/oss/route.c | 2 +
sound/hda/hdac_stream.c | 19 +-
sound/pci/hda/patch_conexant.c | 1 +
sound/pci/hda/patch_hdmi.c | 5 +
sound/pci/hda/patch_realtek.c | 35 +--
tools/perf/scripts/python/exported-sql-viewer.py | 10 +-
virt/kvm/arm/vgic/vgic-v3.c | 6 +-
93 files changed, 523 insertions(+), 561 deletions(-)
From: Jens Axboe <[email protected]>
There's an issue with deferred requests through drain, where if we do
need to defer, we're not copying over the sqe_submit state correctly.
This can result in using uninitialized data when we then later go and
submit the deferred request, like this check in __io_submit_sqe():
if (unlikely(s->index >= ctx->sq_entries))
return -EINVAL;
with 's' being uninitialized, we can randomly fail this check. Fix this
by copying sqe_submit state when we defer a request.
Because it was fixed as part of a cleanup series in mainline, before
anyone realized we had this issue. That removed the separate states
of ->index vs ->submit.sqe. That series is not something I was
comfortable putting into stable, hence the much simpler addition.
Here's the patch in the series that fixes the same issue:
commit cf6fd4bd559ee61a4454b161863c8de6f30f8dca
Author: Pavel Begunkov <[email protected]>
Date: Mon Nov 25 23:14:39 2019 +0300
io_uring: inline struct sqe_submit
Reported-by: Andres Freund <[email protected]>
Reported-by: Tomáš Chaloupka
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/io_uring.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -2039,7 +2039,7 @@ add:
}
static int io_req_defer(struct io_ring_ctx *ctx, struct io_kiocb *req,
- const struct io_uring_sqe *sqe)
+ struct sqe_submit *s)
{
struct io_uring_sqe *sqe_copy;
@@ -2057,7 +2057,8 @@ static int io_req_defer(struct io_ring_c
return 0;
}
- memcpy(sqe_copy, sqe, sizeof(*sqe_copy));
+ memcpy(&req->submit, s, sizeof(*s));
+ memcpy(sqe_copy, s->sqe, sizeof(*sqe_copy));
req->submit.sqe = sqe_copy;
INIT_WORK(&req->work, io_sq_wq_submit_work);
@@ -2425,7 +2426,7 @@ static int io_queue_sqe(struct io_ring_c
{
int ret;
- ret = io_req_defer(ctx, req, s->sqe);
+ ret = io_req_defer(ctx, req, s);
if (ret) {
if (ret != -EIOCBQUEUED) {
io_free_req(req);
@@ -2452,7 +2453,7 @@ static int io_queue_link_head(struct io_
* list.
*/
req->flags |= REQ_F_IO_DRAIN;
- ret = io_req_defer(ctx, req, s->sqe);
+ ret = io_req_defer(ctx, req, s);
if (ret) {
if (ret != -EIOCBQUEUED) {
io_free_req(req);
From: Hans Verkuil <[email protected]>
commit fc1156f373e3927e0dcf06678906c367588bfdd6 upstream.
Some Lenovo X1 Carbon Gen 6 laptops report LEN0091. Add this
to the smbus_pnp_ids list.
Signed-off-by: Hans Verkuil <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/input/mouse/synaptics.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -172,6 +172,7 @@ static const char * const smbus_pnp_ids[
"LEN0071", /* T480 */
"LEN0072", /* X1 Carbon Gen 5 (2017) - Elan/ALPS trackpoint */
"LEN0073", /* X1 Carbon G5 (Elantech) */
+ "LEN0091", /* X1 Carbon 6 */
"LEN0092", /* X1 Carbon 6 */
"LEN0093", /* T480 */
"LEN0096", /* X280 */
From: Takashi Iwai <[email protected]>
commit 4cc8d6505ab82db3357613d36e6c58a297f57f7c upstream.
syzkaller reported an invalid access in PCM OSS read, and this seems
to be an overflow of the internal buffer allocated for a plugin.
Since the rate plugin adjusts its transfer size dynamically, the
calculation for the chained plugin might be bigger than the given
buffer size in some extreme cases, which lead to such an buffer
overflow as caught by KASAN.
Fix it by limiting the max transfer size properly by checking against
the destination size in each plugin transfer callback.
Reported-by: [email protected]
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/core/oss/linear.c | 2 ++
sound/core/oss/mulaw.c | 2 ++
sound/core/oss/route.c | 2 ++
3 files changed, 6 insertions(+)
--- a/sound/core/oss/linear.c
+++ b/sound/core/oss/linear.c
@@ -107,6 +107,8 @@ static snd_pcm_sframes_t linear_transfer
}
}
#endif
+ if (frames > dst_channels[0].frames)
+ frames = dst_channels[0].frames;
convert(plugin, src_channels, dst_channels, frames);
return frames;
}
--- a/sound/core/oss/mulaw.c
+++ b/sound/core/oss/mulaw.c
@@ -269,6 +269,8 @@ static snd_pcm_sframes_t mulaw_transfer(
}
}
#endif
+ if (frames > dst_channels[0].frames)
+ frames = dst_channels[0].frames;
data = (struct mulaw_priv *)plugin->extra_data;
data->func(plugin, src_channels, dst_channels, frames);
return frames;
--- a/sound/core/oss/route.c
+++ b/sound/core/oss/route.c
@@ -57,6 +57,8 @@ static snd_pcm_sframes_t route_transfer(
return -ENXIO;
if (frames == 0)
return 0;
+ if (frames > dst_channels[0].frames)
+ frames = dst_channels[0].frames;
nsrcs = plugin->src_format.channels;
ndsts = plugin->dst_format.channels;
From: Pavel Begunkov <[email protected]>
commit 311ae9e159d81a1ec1cf645daf40b39ae5a0bd84 upstream.
Read/write requests to devices without implemented read/write_iter
using fixed buffers can cause general protection fault, which totally
hangs a machine.
io_import_fixed() initialises iov_iter with bvec, but loop_rw_iter()
accesses it as iovec, dereferencing random address.
kmap() page by page in this case
Cc: [email protected]
Signed-off-by: Pavel Begunkov <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/io_uring.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -1351,9 +1351,19 @@ static ssize_t loop_rw_iter(int rw, stru
return -EAGAIN;
while (iov_iter_count(iter)) {
- struct iovec iovec = iov_iter_iovec(iter);
+ struct iovec iovec;
ssize_t nr;
+ if (!iov_iter_is_bvec(iter)) {
+ iovec = iov_iter_iovec(iter);
+ } else {
+ /* fixed buffers import bvec */
+ iovec.iov_base = kmap(iter->bvec->bv_page)
+ + iter->iov_offset;
+ iovec.iov_len = min(iter->count,
+ iter->bvec->bv_len - iter->iov_offset);
+ }
+
if (rw == READ) {
nr = file->f_op->read(file, iovec.iov_base,
iovec.iov_len, &kiocb->ki_pos);
@@ -1362,6 +1372,9 @@ static ssize_t loop_rw_iter(int rw, stru
iovec.iov_len, &kiocb->ki_pos);
}
+ if (iov_iter_is_bvec(iter))
+ kunmap(iter->bvec->bv_page);
+
if (nr < 0) {
if (!ret)
ret = nr;
From: Chuhong Yuan <[email protected]>
commit 50b2b571c5f3df721fc81bf9a12c521dfbe019ba upstream.
The driver forgets to call pm_runtime_disable in remove.
Add the missed calls to fix it.
Signed-off-by: Chuhong Yuan <[email protected]>
Cc: stable <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/tty/serial/ifx6x60.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/tty/serial/ifx6x60.c
+++ b/drivers/tty/serial/ifx6x60.c
@@ -1230,6 +1230,9 @@ static int ifx_spi_spi_remove(struct spi
struct ifx_spi_device *ifx_dev = spi_get_drvdata(spi);
/* stop activity */
tasklet_kill(&ifx_dev->io_work_tasklet);
+
+ pm_runtime_disable(&spi->dev);
+
/* free irq */
free_irq(gpio_to_irq(ifx_dev->gpio.reset_out), ifx_dev);
free_irq(gpio_to_irq(ifx_dev->gpio.srdy), ifx_dev);
From: Takashi Iwai <[email protected]>
commit e38e486d66e2a3b902768fd71c32dbf10f77e1cb upstream.
The recent commit in HD-audio stream management for changing the
stripe control seems causing a regression on some platforms. The
stripe control is currently used only by HDMI codec, and applying the
stripe mask unconditionally may lead to scratchy and static noises as
seen on some MacBooks.
For addressing the regression, this patch changes the stream
management code to apply the stripe mask conditionally only when the
codec driver requested.
Fixes: 9b6f7e7a296e ("ALSA: hda: program stripe bits for controller")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204477
Tested-by: Michael Pobega <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/sound/hdaudio.h | 1 +
sound/hda/hdac_stream.c | 19 ++++++++++++-------
sound/pci/hda/patch_hdmi.c | 5 +++++
3 files changed, 18 insertions(+), 7 deletions(-)
--- a/include/sound/hdaudio.h
+++ b/include/sound/hdaudio.h
@@ -493,6 +493,7 @@ struct hdac_stream {
bool prepared:1;
bool no_period_wakeup:1;
bool locked:1;
+ bool stripe:1; /* apply stripe control */
/* timestamp */
unsigned long start_wallclk; /* start + minimum wallclk */
--- a/sound/hda/hdac_stream.c
+++ b/sound/hda/hdac_stream.c
@@ -96,12 +96,14 @@ void snd_hdac_stream_start(struct hdac_s
1 << azx_dev->index,
1 << azx_dev->index);
/* set stripe control */
- if (azx_dev->substream)
- stripe_ctl = snd_hdac_get_stream_stripe_ctl(bus, azx_dev->substream);
- else
- stripe_ctl = 0;
- snd_hdac_stream_updateb(azx_dev, SD_CTL_3B, SD_CTL_STRIPE_MASK,
- stripe_ctl);
+ if (azx_dev->stripe) {
+ if (azx_dev->substream)
+ stripe_ctl = snd_hdac_get_stream_stripe_ctl(bus, azx_dev->substream);
+ else
+ stripe_ctl = 0;
+ snd_hdac_stream_updateb(azx_dev, SD_CTL_3B, SD_CTL_STRIPE_MASK,
+ stripe_ctl);
+ }
/* set DMA start and interrupt mask */
snd_hdac_stream_updateb(azx_dev, SD_CTL,
0, SD_CTL_DMA_START | SD_INT_MASK);
@@ -118,7 +120,10 @@ void snd_hdac_stream_clear(struct hdac_s
snd_hdac_stream_updateb(azx_dev, SD_CTL,
SD_CTL_DMA_START | SD_INT_MASK, 0);
snd_hdac_stream_writeb(azx_dev, SD_STS, SD_INT_MASK); /* to be sure */
- snd_hdac_stream_updateb(azx_dev, SD_CTL_3B, SD_CTL_STRIPE_MASK, 0);
+ if (azx_dev->stripe) {
+ snd_hdac_stream_updateb(azx_dev, SD_CTL_3B, SD_CTL_STRIPE_MASK, 0);
+ azx_dev->stripe = 0;
+ }
azx_dev->running = false;
}
EXPORT_SYMBOL_GPL(snd_hdac_stream_clear);
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -32,6 +32,7 @@
#include <sound/hda_codec.h>
#include "hda_local.h"
#include "hda_jack.h"
+#include "hda_controller.h"
static bool static_hdmi_pcm;
module_param(static_hdmi_pcm, bool, 0644);
@@ -1240,6 +1241,10 @@ static int hdmi_pcm_open(struct hda_pcm_
per_pin->cvt_nid = per_cvt->cvt_nid;
hinfo->nid = per_cvt->cvt_nid;
+ /* flip stripe flag for the assigned stream if supported */
+ if (get_wcaps(codec, per_cvt->cvt_nid) & AC_WCAP_STRIPE)
+ azx_stream(get_azx_dev(substream))->stripe = 1;
+
snd_hda_set_dev_select(codec, per_pin->pin_nid, per_pin->dev_id);
snd_hda_codec_write_cache(codec, per_pin->pin_nid, 0,
AC_VERB_SET_CONNECT_SEL,
On 11/12/2019 15:04, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.3 release.
> There are 92 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 13 Dec 2019 14:56:06 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.3-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -------------
All tests are passing for Tegra ...
Test results for stable-v5.4:
13 builds: 13 pass, 0 fail
22 boots: 22 pass, 0 fail
38 tests: 38 pass, 0 fail
Linux version: 5.4.3-rc1-g6b42537b2c89
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Cheers
Jon
--
nvpublic
On 12/11/19 8:04 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.3 release.
> There are 92 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 13 Dec 2019 14:56:06 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.3-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
On Wed, 11 Dec 2019 at 20:39, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.4.3 release.
> There are 92 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 13 Dec 2019 14:56:06 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.3-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Summary
------------------------------------------------------------------------
kernel: 5.4.3-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.4.y
git commit: 6b42537b2c8927366737f1d297ae4e91fdeba6ea
git describe: v5.4.2-93-g6b42537b2c89
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.4-oe/build/v5.4.2-93-g6b42537b2c89
No regressions (compared to build v5.4.2)
No fixes (compared to build v5.4.2)
Ran 23952 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* linux-log-parser
* ltp-containers-tests
* ltp-cve-tests
* ltp-fs-tests
* network-basic-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* kvm-unit-tests
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-cpuhotplug-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-open-posix-tests
* ltp-sched-tests
* ltp-syscalls-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-securebits-tests
--
Linaro LKFT
https://lkft.linaro.org
On Wed, Dec 11, 2019 at 04:04:51PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.3 release.
> There are 92 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 13 Dec 2019 14:56:06 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.3-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
No new errors from "sudo dmesg -l err".
--
software engineer
rajagiri school of engineering and technology
On Thu, Dec 12, 2019 at 01:57:29PM +0530, Jeffrin Jose wrote:
> On Wed, Dec 11, 2019 at 04:04:51PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.4.3 release.
> > There are 92 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Fri, 13 Dec 2019 14:56:06 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.3-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> > and the diffstat can be found below.
>
> No new errors from "sudo dmesg -l err".
great, thanks for testing.
greg k-h
On Thu, Dec 12, 2019 at 10:58:56AM +0530, Naresh Kamboju wrote:
> On Wed, 11 Dec 2019 at 20:39, Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > This is the start of the stable review cycle for the 5.4.3 release.
> > There are 92 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Fri, 13 Dec 2019 14:56:06 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.3-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.
Thanks for testing all of these and letting me know.
greg k-h
On Wed, Dec 11, 2019 at 07:48:28PM -0700, shuah wrote:
> On 12/11/19 8:04 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.4.3 release.
> > There are 92 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Fri, 13 Dec 2019 14:56:06 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.3-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Compiled and booted on my test system. No dmesg regressions.
Thanks for testing all of these and letting me know.
greg k-h
On Wed, Dec 11, 2019 at 04:04:51PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.3 release.
> There are 92 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 13 Dec 2019 14:56:06 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.3-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
I have pushed out -rc2 with a number of additional fixes:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.3-rc2.gz
On 12/12/2019 10:04, Greg Kroah-Hartman wrote:
> On Wed, Dec 11, 2019 at 04:04:51PM +0100, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 5.4.3 release.
>> There are 92 patches in this series, all will be posted as a response
>> to this one. If anyone has any issues with these being applied, please
>> let me know.
>>
>> Responses should be made by Fri, 13 Dec 2019 14:56:06 +0000.
>> Anything received after that time might be too late.
>>
>> The whole patch series can be found in one patch at:
>> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.3-rc1.gz
>> or in the git tree and branch at:
>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
>> and the diffstat can be found below.
>
> I have pushed out -rc2 with a number of additional fixes:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.3-rc2.gz
>
All tests are passing for Tegra ...
Test results for stable-v5.4:
13 builds: 13 pass, 0 fail
22 boots: 22 pass, 0 fail
38 tests: 38 pass, 0 fail
Linux version: 5.4.3-rc2-g2d52a20a4c40
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Cheers
Jon
--
nvpublic
On Wed, Dec 11, 2019 at 04:04:51PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.3 release.
> There are 92 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 13 Dec 2019 14:56:06 +0000.
> Anything received after that time might be too late.
>
For v5.4.2-102-g2d52a20a4c40:
Build results:
total: 158 pass: 158 fail: 0
Qemu test results:
total: 397 pass: 397 fail: 0
Guenter
On Thu, 12 Dec 2019 at 15:34, Greg Kroah-Hartman
<[email protected]> wrote:
>
> On Wed, Dec 11, 2019 at 04:04:51PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.4.3 release.
> > There are 92 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Fri, 13 Dec 2019 14:56:06 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.3-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> > and the diffstat can be found below.
>
> I have pushed out -rc2 with a number of additional fixes:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.3-rc2.gz
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Summary
------------------------------------------------------------------------
kernel: 5.4.3-rc2
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.4.y
git commit: 2d52a20a4c407f36814e9ebf0a64d73f74a690f6
git describe: v5.4.2-102-g2d52a20a4c40
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.4-oe/build/v5.4.2-102-g2d52a20a4c40
No regressions (compared to build v5.4.2)
No fixes (compared to build v5.4.2)
Ran 24491 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* libhugetlbfs
* linux-log-parser
* ltp-containers-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-mm-tests
* spectre-meltdown-checker-test
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-cpuhotplug-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* network-basic-tests
* perf
* v4l2-compliance
* ltp-open-posix-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* ssuite
--
Linaro LKFT
https://lkft.linaro.org
On Thu, Dec 12, 2019 at 10:25:18AM -0800, Guenter Roeck wrote:
> On Wed, Dec 11, 2019 at 04:04:51PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.4.3 release.
> > There are 92 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Fri, 13 Dec 2019 14:56:06 +0000.
> > Anything received after that time might be too late.
> >
>
> For v5.4.2-102-g2d52a20a4c40:
>
> Build results:
> total: 158 pass: 158 fail: 0
> Qemu test results:
> total: 397 pass: 397 fail: 0
Wonderful, thanks for testing all of these and letting me know.
greg k-h
On Fri, Dec 13, 2019 at 10:19:43AM +0530, Naresh Kamboju wrote:
> On Thu, 12 Dec 2019 at 15:34, Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > On Wed, Dec 11, 2019 at 04:04:51PM +0100, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 5.4.3 release.
> > > There are 92 patches in this series, all will be posted as a response
> > > to this one. If anyone has any issues with these being applied, please
> > > let me know.
> > >
> > > Responses should be made by Fri, 13 Dec 2019 14:56:06 +0000.
> > > Anything received after that time might be too late.
> > >
> > > The whole patch series can be found in one patch at:
> > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.3-rc1.gz
> > > or in the git tree and branch at:
> > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> > > and the diffstat can be found below.
> >
> > I have pushed out -rc2 with a number of additional fixes:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.3-rc2.gz
>
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.
Great, tanks for testing and letting me know.
greg k-h