The patch below does not apply to the 6.1-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y
git checkout FETCH_HEAD
git cherry-pick -x 045aecdfcb2e060db142d83a0f4082380c465d2c
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023080713-schedule-tuition-b3a5@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
Possible dependencies:
045aecdfcb2e ("arm64/ptrace: Don't enable SVE when setting streaming SVE")
baa8515281b3 ("arm64/fpsimd: Track the saved FPSIMD state type separately to TIF_SVE")
93ae6b01bafe ("KVM: arm64: Discard any SVE state when entering KVM guests")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 045aecdfcb2e060db142d83a0f4082380c465d2c Mon Sep 17 00:00:00 2001
From: Mark Brown <broonie(a)kernel.org>
Date: Thu, 3 Aug 2023 19:33:21 +0100
Subject: [PATCH] arm64/ptrace: Don't enable SVE when setting streaming SVE
Systems which implement SME without also implementing SVE are
architecturally valid but were not initially supported by the kernel,
unfortunately we missed one issue in the ptrace code.
The SVE register setting code is shared between SVE and streaming mode
SVE. When we set full SVE register state we currently enable TIF_SVE
unconditionally, in the case where streaming SVE is being configured on a
system that supports vanilla SVE this is not an issue since we always
initialise enough state for both vector lengths but on a system which only
support SME it will result in us attempting to restore the SVE vector
length after having set streaming SVE registers.
Fix this by making the enabling of SVE conditional on setting SVE vector
state. If we set streaming SVE state and SVE was not already enabled this
will result in a SVE access trap on next use of normal SVE, this will cause
us to flush our register state but this is fine since the only way to
trigger a SVE access trap would be to exit streaming mode which will cause
the in register state to be flushed anyway.
Fixes: e12310a0d30f ("arm64/sme: Implement ptrace support for streaming mode SVE registers")
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
Link: https://lore.kernel.org/r/20230803-arm64-fix-ptrace-ssve-no-sve-v1-1-49df21…
Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 740e81e9db04..5b9b4305248b 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -932,11 +932,13 @@ static int sve_set_common(struct task_struct *target,
/*
* Ensure target->thread.sve_state is up to date with target's
* FPSIMD regs, so that a short copyin leaves trailing
- * registers unmodified. Always enable SVE even if going into
- * streaming mode.
+ * registers unmodified. Only enable SVE if we are
+ * configuring normal SVE, a system with streaming SVE may not
+ * have normal SVE.
*/
fpsimd_sync_to_sve(target);
- set_tsk_thread_flag(target, TIF_SVE);
+ if (type == ARM64_VEC_SVE)
+ set_tsk_thread_flag(target, TIF_SVE);
target->thread.fp_type = FP_STATE_SVE;
BUILD_BUG_ON(SVE_PT_SVE_OFFSET != sizeof(header));
From: Peichen Huang <PeiChen.Huang(a)amd.com>
[Why]
Some dock and mst monitor don't like to receive CLEAR_PAYLOAD_ID_TABLE
when mst_en is set to 0. It doesn't make sense to do so in source
side, either.
[How]
Don't send CLEAR_PAYLOAD_ID_TABLE if mst_en is 0
Reviewed-by: George Shen <George.Shen(a)amd.com>
Acked-by: Qingqing Zhuo <qingqing.zhuo(a)amd.com>
Signed-off-by: Peichen Huang <PeiChen.Huang(a)amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
(cherry picked from commit a1c9a1e27022d13c70a14c4faeab6ce293ad043b)
6.1.y doesn't have the file rename from
54618888d1ea7 ("drm/amd/display: break down dc_link.c")
Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com>
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 63daf6ecbda7..bbaeb6c567d0 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -2097,6 +2097,7 @@ static enum dc_status enable_link_dp_mst(
struct pipe_ctx *pipe_ctx)
{
struct dc_link *link = pipe_ctx->stream->link;
+ unsigned char mstm_cntl;
/* sink signal type after MST branch is MST. Multiple MST sinks
* share one link. Link DP PHY is enable or training only once.
@@ -2105,7 +2106,9 @@ static enum dc_status enable_link_dp_mst(
return DC_OK;
/* clear payload table */
- dm_helpers_dp_mst_clear_payload_allocation_table(link->ctx, link);
+ core_link_read_dpcd(link, DP_MSTM_CTRL, &mstm_cntl, 1);
+ if (mstm_cntl & DP_MST_EN)
+ dm_helpers_dp_mst_clear_payload_allocation_table(link->ctx, link);
/* to make sure the pending down rep can be processed
* before enabling the link
--
2.34.1
Hi,
It was reported that when '8d855bc67630 ("drm/amd/display: Use
dc_update_planes_and_stream")' was backported it caused a regression
where Kodi could no longer display.
Reported-and-tested-by: william.bonnaventure(a)gmail.com
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2766
Link: https://github.com/LibreELEC/LibreELEC.tv/issues/8013
This is fixed by backporting this additional commit to 6.1.y.
bb46a6a9bab1 ("drm/amd/display: Ensure that planes are in the same order")
Can you please queue this up?
Thanks!
Hi All,
As discussed here in the v1 thread:
https://lore.kernel.org/linux-acpi/20230806151453.10690-1-hdegoede@redhat.c…
Here is a v2 which adds a few fixes on top of the revert
to avoid the revert causing regressions on AMD Zen systems
where dropping the special Zen behavior was known to fix
things.
As also mentioned in the thread this is intended as a short term fix
for 6.4.y >= 6.4.7 and 6.5 to get all the systems which were working
fine before commit a9c4a912b7dc ("ACPI: resource: Remove "Zen"
specific match and quirks") to work again.
The long term plan is to see if we can read back what the BIOS
has actually programmed as IRQ trigger-type / polarity into
the IOAPIC.
Regards,
Hans
Hans de Goede (3):
ACPI: resource: revert "Remove "Zen" specific match and quirks"
ACPI: resource: Always use MADT override IRQ settings for GSI != 1
ACPI: resource: Honor MADT INT_SRC_OVR settings for IRQ1 on AMD Zen
arch/x86/include/asm/acpi.h | 1 +
arch/x86/kernel/acpi/boot.c | 4 +++
drivers/acpi/resource.c | 52 +++++++++++++++++++++++++++++++++++++
3 files changed, 57 insertions(+)
--
2.41.0
LKFT build plans updated with toolchain gcc-13 and here is the report.
While building Linux stable rc 4.19 i386 with gcc-13 failed due to
following warnings / errors.
make --silent --keep-going --jobs=8
O=/home/tuxbuild/.cache/tuxmake/builds/1/build ARCH=i386 SRCARCH=x86
CROSS_COMPILE=i686-linux-gnu- 'CC=sccache i686-linux-gnu-gcc'
'HOSTCC=sccache gcc'
kernel/profile.c: In function 'profile_dead_cpu':
kernel/profile.c:346:27: warning: the comparison will always evaluate
as 'true' for the address of 'prof_cpu_mask' will never be NULL
[-Waddress]
346 | if (prof_cpu_mask != NULL)
| ^~
kernel/profile.c:49:22: note: 'prof_cpu_mask' declared here
49 | static cpumask_var_t prof_cpu_mask;
| ^~~~~~~~~~~~~
kernel/profile.c: In function 'profile_online_cpu':
kernel/profile.c:383:27: warning: the comparison will always evaluate
as 'true' for the address of 'prof_cpu_mask' will never be NULL
[-Waddress]
383 | if (prof_cpu_mask != NULL)
| ^~
kernel/profile.c:49:22: note: 'prof_cpu_mask' declared here
49 | static cpumask_var_t prof_cpu_mask;
| ^~~~~~~~~~~~~
kernel/profile.c: In function 'profile_tick':
kernel/profile.c:413:47: warning: the comparison will always evaluate
as 'true' for the address of 'prof_cpu_mask' will never be NULL
[-Waddress]
413 | if (!user_mode(regs) && prof_cpu_mask != NULL &&
| ^~
kernel/profile.c:49:22: note: 'prof_cpu_mask' declared here
49 | static cpumask_var_t prof_cpu_mask;
| ^~~~~~~~~~~~~
In file included from include/linux/export.h:45,
from include/linux/linkage.h:7,
from include/linux/kernel.h:7,
from drivers/ata/libahci.c:35:
drivers/ata/libahci.c: In function 'ahci_led_store':
include/linux/compiler.h:418:45: error: call to
'__compiletime_assert_108' declared with attribute error: BUILD_BUG_ON
failed: sizeof(_s) > sizeof(long)
418 | _compiletime_assert(condition, msg,
__compiletime_assert_, __COUNTER__)
| ^
include/linux/compiler.h:399:25: note: in definition of macro
'__compiletime_assert'
399 | prefix ## suffix();
\
| ^~~~~~
Build links,
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19…
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19…
Steps to reproduce:
tuxmake --runtime podman --target-arch i386 --toolchain gcc-13
--kconfig defconfig
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2TiUIlGFjnjPBfuTT62n…
--
Linaro LKFT
https://lkft.linaro.org
While building Linux stable rc 5.15 arm with gcc-13 failed due to
following warnings / errors.
make --silent --keep-going --jobs=8
O=/home/tuxbuild/.cache/tuxmake/builds/1/build ARCH=arm
CROSS_COMPILE=arm-linux-gnueabihf- 'CC=sccache
arm-linux-gnueabihf-gcc' 'HOSTCC=sccache gcc'
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c:176:20: error:
'drm_plane_helper_destroy' undeclared here (not in a function); did
you mean 'drm_primary_helper_destroy'?
176 | .destroy = drm_plane_helper_destroy,
| ^~~~~~~~~~~~~~~~~~~~~~~~
| drm_primary_helper_destroy
make[5]: *** [scripts/Makefile.build:289:
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.o] Error 1
make[5]: Target '__build' not remade because of errors.
make[4]: *** [scripts/Makefile.build:552: drivers/gpu/drm/fsl-dcu] Error 2
drivers/firmware/arm_scmi/smc.c:39:13: error: duplicate member 'irq'
39 | int irq;
| ^~~
drivers/firmware/arm_scmi/smc.c: In function 'smc_chan_setup':
drivers/firmware/arm_scmi/smc.c:118:34: error: 'irq' undeclared (first
use in this function); did you mean 'rq'?
118 | scmi_info->irq = irq;
| ^~~
| rq
drivers/firmware/arm_scmi/smc.c:118:34: note: each undeclared
identifier is reported only once for each function it appears in
make[4]: *** [scripts/Makefile.build:289:
drivers/firmware/arm_scmi/smc.o] Error 1
Build links,
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15…
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15…
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2TiTIjkQ8vGDk4J7tsuc…
Steps to reproduce:
tuxmake --runtime podman --target-arch arm --toolchain gcc-13
--kconfig https://storage.tuxsuite.com/public/linaro/lkft/builds/2TiTIjkQ8vGDk4J7tsuc…https://storage.tuxsuite.com/public/linaro/lkft/builds/2TiTIjkQ8vGDk4J7tsuc…
--
Linaro LKFT
https://lkft.linaro.org
Supported codec bitmask is populated from the payload from venus firmware.
There is a possible case when all the bits in the codec bitmask is set. In
such case, core cap for decoder is filled and MAX_CODEC_NUM is utilized.
Now while filling the caps for encoder, it can lead to access the caps
array beyong 32 index. Hence leading to OOB write.
The fix counts the supported encoder and decoder. If the count is more than
max, then it skips accessing the caps.
Cc: stable(a)vger.kernel.org
Fixes: 1a73374a04e5 ("media: venus: hfi_parser: add common capability parser")
Signed-off-by: Vikash Garodia <quic_vgarodia(a)quicinc.com>
---
drivers/media/platform/qcom/venus/hfi_parser.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/platform/qcom/venus/hfi_parser.c b/drivers/media/platform/qcom/venus/hfi_parser.c
index 9d6ba22..c438395 100644
--- a/drivers/media/platform/qcom/venus/hfi_parser.c
+++ b/drivers/media/platform/qcom/venus/hfi_parser.c
@@ -19,6 +19,9 @@ static void init_codecs(struct venus_core *core)
struct hfi_plat_caps *caps = core->caps, *cap;
unsigned long bit;
+ if (hweight_long(core->dec_codecs) + hweight_long(core->enc_codecs) > MAX_CODEC_NUM)
+ return;
+
for_each_set_bit(bit, &core->dec_codecs, MAX_CODEC_NUM) {
cap = &caps[core->codecs_count++];
cap->codec = BIT(bit);
--
2.7.4