--- /dev/null
+From 95b6fcf805ab65845121cfce378e3a90c8e933b3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 6 Jan 2025 16:21:00 +0000
+Subject: afs: Fix the maximum cell name length
+
+From: David Howells <dhowells@redhat.com>
+
+[ Upstream commit 8fd56ad6e7c90ac2bddb0741c6b248c8c5d56ac8 ]
+
+The kafs filesystem limits the maximum length of a cell to 256 bytes, but a
+problem occurs if someone actually does that: kafs tries to create a
+directory under /proc/net/afs/ with the name of the cell, but that fails
+with a warning:
+
+ WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:405
+
+because procfs limits the maximum filename length to 255.
+
+However, the DNS limits the maximum lookup length and, by extension, the
+maximum cell name, to 255 less two (length count and trailing NUL).
+
+Fix this by limiting the maximum acceptable cellname length to 253. This
+also allows us to be sure we can create the "/afs/.<cell>/" mountpoint too.
+
+Further, split the YFS VL record cell name maximum to be the 256 allowed by
+the protocol and ignore the record retrieved by YFSVL.GetCellName if it
+exceeds 253.
+
+Fixes: c3e9f888263b ("afs: Implement client support for the YFSVL.GetCellName RPC op")
+Reported-by: syzbot+7848fee1f1e5c53f912b@syzkaller.appspotmail.com
+Closes: https://lore.kernel.org/r/6776d25d.050a0220.3a8527.0048.GAE@google.com/
+Signed-off-by: David Howells <dhowells@redhat.com>
+Link: https://lore.kernel.org/r/376236.1736180460@warthog.procyon.org.uk
+Tested-by: syzbot+7848fee1f1e5c53f912b@syzkaller.appspotmail.com
+cc: Marc Dionne <marc.dionne@auristor.com>
+cc: linux-afs@lists.infradead.org
+Signed-off-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/afs/afs.h | 2 +-
+ fs/afs/afs_vl.h | 1 +
+ fs/afs/vl_alias.c | 8 ++++++--
+ fs/afs/vlclient.c | 2 +-
+ 4 files changed, 9 insertions(+), 4 deletions(-)
+
+diff --git a/fs/afs/afs.h b/fs/afs/afs.h
+index 81815724db6c..25c17100798b 100644
+--- a/fs/afs/afs.h
++++ b/fs/afs/afs.h
+@@ -10,7 +10,7 @@
+
+ #include <linux/in.h>
+
+-#define AFS_MAXCELLNAME 256 /* Maximum length of a cell name */
++#define AFS_MAXCELLNAME 253 /* Maximum length of a cell name (DNS limited) */
+ #define AFS_MAXVOLNAME 64 /* Maximum length of a volume name */
+ #define AFS_MAXNSERVERS 8 /* Maximum servers in a basic volume record */
+ #define AFS_NMAXNSERVERS 13 /* Maximum servers in a N/U-class volume record */
+diff --git a/fs/afs/afs_vl.h b/fs/afs/afs_vl.h
+index 9c65ffb8a523..8da0899fbc08 100644
+--- a/fs/afs/afs_vl.h
++++ b/fs/afs/afs_vl.h
+@@ -13,6 +13,7 @@
+ #define AFS_VL_PORT 7003 /* volume location service port */
+ #define VL_SERVICE 52 /* RxRPC service ID for the Volume Location service */
+ #define YFS_VL_SERVICE 2503 /* Service ID for AuriStor upgraded VL service */
++#define YFS_VL_MAXCELLNAME 256 /* Maximum length of a cell name in YFS protocol */
+
+ enum AFSVL_Operations {
+ VLGETENTRYBYID = 503, /* AFS Get VLDB entry by ID */
+diff --git a/fs/afs/vl_alias.c b/fs/afs/vl_alias.c
+index f04a80e4f5c3..83cf1bfbe343 100644
+--- a/fs/afs/vl_alias.c
++++ b/fs/afs/vl_alias.c
+@@ -302,6 +302,7 @@ static char *afs_vl_get_cell_name(struct afs_cell *cell, struct key *key)
+ static int yfs_check_canonical_cell_name(struct afs_cell *cell, struct key *key)
+ {
+ struct afs_cell *master;
++ size_t name_len;
+ char *cell_name;
+
+ cell_name = afs_vl_get_cell_name(cell, key);
+@@ -313,8 +314,11 @@ static int yfs_check_canonical_cell_name(struct afs_cell *cell, struct key *key)
+ return 0;
+ }
+
+- master = afs_lookup_cell(cell->net, cell_name, strlen(cell_name),
+- NULL, false);
++ name_len = strlen(cell_name);
++ if (!name_len || name_len > AFS_MAXCELLNAME)
++ master = ERR_PTR(-EOPNOTSUPP);
++ else
++ master = afs_lookup_cell(cell->net, cell_name, name_len, NULL, false);
+ kfree(cell_name);
+ if (IS_ERR(master))
+ return PTR_ERR(master);
+diff --git a/fs/afs/vlclient.c b/fs/afs/vlclient.c
+index 00fca3c66ba6..16653f2ffe4f 100644
+--- a/fs/afs/vlclient.c
++++ b/fs/afs/vlclient.c
+@@ -671,7 +671,7 @@ static int afs_deliver_yfsvl_get_cell_name(struct afs_call *call)
+ return ret;
+
+ namesz = ntohl(call->tmp);
+- if (namesz > AFS_MAXCELLNAME)
++ if (namesz > YFS_VL_MAXCELLNAME)
+ return afs_protocol_error(call, afs_eproto_cellname_len);
+ paddedsz = (namesz + 3) & ~3;
+ call->count = namesz;
+--
+2.39.5
+
--- /dev/null
+From d6ae382b3b0e067c5cd38d55b51e3fd751423131 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 16 Nov 2024 00:32:39 +0100
+Subject: cpuidle: riscv-sbi: fix device node release in early exit of
+ for_each_possible_cpu
+
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+[ Upstream commit 7e25044b804581b9c029d5a28d8800aebde18043 ]
+
+The 'np' device_node is initialized via of_cpu_device_node_get(), which
+requires explicit calls to of_node_put() when it is no longer required
+to avoid leaking the resource.
+
+Instead of adding the missing calls to of_node_put() in all execution
+paths, use the cleanup attribute for 'np' by means of the __free()
+macro, which automatically calls of_node_put() when the variable goes
+out of scope. Given that 'np' is only used within the
+for_each_possible_cpu(), reduce its scope to release the nood after
+every iteration of the loop.
+
+Fixes: 6abf32f1d9c5 ("cpuidle: Add RISC-V SBI CPU idle driver")
+Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
+Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Link: https://lore.kernel.org/r/20241116-cpuidle-riscv-sbi-cleanup-v3-1-a3a46372ce08@gmail.com
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/cpuidle/cpuidle-riscv-sbi.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/cpuidle/cpuidle-riscv-sbi.c b/drivers/cpuidle/cpuidle-riscv-sbi.c
+index c0fe92409175..71d433bb0ce6 100644
+--- a/drivers/cpuidle/cpuidle-riscv-sbi.c
++++ b/drivers/cpuidle/cpuidle-riscv-sbi.c
+@@ -534,12 +534,12 @@ static int sbi_cpuidle_probe(struct platform_device *pdev)
+ int cpu, ret;
+ struct cpuidle_driver *drv;
+ struct cpuidle_device *dev;
+- struct device_node *np, *pds_node;
++ struct device_node *pds_node;
+
+ /* Detect OSI support based on CPU DT nodes */
+ sbi_cpuidle_use_osi = true;
+ for_each_possible_cpu(cpu) {
+- np = of_cpu_device_node_get(cpu);
++ struct device_node *np __free(device_node) = of_cpu_device_node_get(cpu);
+ if (np &&
+ of_property_present(np, "power-domains") &&
+ of_property_present(np, "power-domain-names")) {
+--
+2.39.5
+
--- /dev/null
+From 6f634deb22907c6bf700e9b081a0a2e58da9baa1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 18 Dec 2024 19:34:07 +0800
+Subject: drm/mediatek: Add return value check when reading DPCD
+
+From: Liankun Yang <liankun.yang@mediatek.com>
+
+[ Upstream commit 522908140645865dc3e2fac70fd3b28834dfa7be ]
+
+Check the return value of drm_dp_dpcd_readb() to confirm that
+AUX communication is successful. To simplify the code, replace
+drm_dp_dpcd_readb() and DP_GET_SINK_COUNT() with drm_dp_read_sink_count().
+
+Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver")
+Signed-off-by: Liankun Yang <liankun.yang@mediatek.com>
+Reviewed-by: Guillaume Ranquet <granquet@baylibre.com>
+Link: https://patchwork.kernel.org/project/dri-devel/patch/20241218113448.2992-1-liankun.yang@mediatek.com/
+Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/mediatek/mtk_dp.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
+index 3e1b400febde..be4de26c77f9 100644
+--- a/drivers/gpu/drm/mediatek/mtk_dp.c
++++ b/drivers/gpu/drm/mediatek/mtk_dp.c
+@@ -2005,7 +2005,6 @@ static enum drm_connector_status mtk_dp_bdg_detect(struct drm_bridge *bridge)
+ struct mtk_dp *mtk_dp = mtk_dp_from_bridge(bridge);
+ enum drm_connector_status ret = connector_status_disconnected;
+ bool enabled = mtk_dp->enabled;
+- u8 sink_count = 0;
+
+ if (!mtk_dp->train_info.cable_plugged_in)
+ return ret;
+@@ -2020,8 +2019,8 @@ static enum drm_connector_status mtk_dp_bdg_detect(struct drm_bridge *bridge)
+ * function, we just need to check the HPD connection to check
+ * whether we connect to a sink device.
+ */
+- drm_dp_dpcd_readb(&mtk_dp->aux, DP_SINK_COUNT, &sink_count);
+- if (DP_GET_SINK_COUNT(sink_count))
++
++ if (drm_dp_read_sink_count(&mtk_dp->aux) > 0)
+ ret = connector_status_connected;
+
+ if (!enabled)
+--
+2.39.5
+
--- /dev/null
+From 88803e4827c4a7c10876bc68183af71c63dc4685 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 25 Oct 2024 16:28:28 +0800
+Subject: drm/mediatek: Fix mode valid issue for dp
+
+From: Liankun Yang <liankun.yang@mediatek.com>
+
+[ Upstream commit 0d68b55887cedc7487036ed34cb4c2097c4228f1 ]
+
+Fix dp mode valid issue to avoid abnormal display of limit state.
+
+After DP passes link training, it can express the lane count of the
+current link status is good. Calculate the maximum bandwidth supported
+by DP using the current lane count.
+
+The color format will select the best one based on the bandwidth
+requirements of the current timing mode. If the current timing mode
+uses RGB and meets the DP link bandwidth requirements, RGB will be used.
+
+If the timing mode uses RGB but does not meet the DP link bandwidthi
+requirements, it will continue to check whether YUV422 meets
+the DP link bandwidth.
+
+FEC overhead is approximately 2.4% from DP 1.4a spec 2.2.1.4.2.
+The down-spread amplitude shall either be disabled (0.0%) or up
+to 0.5% from 1.4a 3.5.2.6. Add up to approximately 3% total overhead.
+
+Because rate is already divided by 10,
+mode->clock does not need to be multiplied by 10.
+
+Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver")
+Signed-off-by: Liankun Yang <liankun.yang@mediatek.com>
+Link: https://patchwork.kernel.org/project/dri-devel/patch/20241025083036.8829-3-liankun.yang@mediatek.com/
+Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/mediatek/mtk_dp.c | 28 +++++++++++++++++-----------
+ 1 file changed, 17 insertions(+), 11 deletions(-)
+
+diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
+index 399423cb618c..3e1b400febde 100644
+--- a/drivers/gpu/drm/mediatek/mtk_dp.c
++++ b/drivers/gpu/drm/mediatek/mtk_dp.c
+@@ -2313,12 +2313,19 @@ mtk_dp_bridge_mode_valid(struct drm_bridge *bridge,
+ {
+ struct mtk_dp *mtk_dp = mtk_dp_from_bridge(bridge);
+ u32 bpp = info->color_formats & DRM_COLOR_FORMAT_YCBCR422 ? 16 : 24;
+- u32 rate = min_t(u32, drm_dp_max_link_rate(mtk_dp->rx_cap) *
+- drm_dp_max_lane_count(mtk_dp->rx_cap),
+- drm_dp_bw_code_to_link_rate(mtk_dp->max_linkrate) *
+- mtk_dp->max_lanes);
++ u32 lane_count_min = mtk_dp->train_info.lane_count;
++ u32 rate = drm_dp_bw_code_to_link_rate(mtk_dp->train_info.link_rate) *
++ lane_count_min;
+
+- if (rate < mode->clock * bpp / 8)
++ /*
++ *FEC overhead is approximately 2.4% from DP 1.4a spec 2.2.1.4.2.
++ *The down-spread amplitude shall either be disabled (0.0%) or up
++ *to 0.5% from 1.4a 3.5.2.6. Add up to approximately 3% total overhead.
++ *
++ *Because rate is already divided by 10,
++ *mode->clock does not need to be multiplied by 10
++ */
++ if ((rate * 97 / 100) < (mode->clock * bpp / 8))
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+@@ -2359,10 +2366,9 @@ static u32 *mtk_dp_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
+ struct drm_display_mode *mode = &crtc_state->adjusted_mode;
+ struct drm_display_info *display_info =
+ &conn_state->connector->display_info;
+- u32 rate = min_t(u32, drm_dp_max_link_rate(mtk_dp->rx_cap) *
+- drm_dp_max_lane_count(mtk_dp->rx_cap),
+- drm_dp_bw_code_to_link_rate(mtk_dp->max_linkrate) *
+- mtk_dp->max_lanes);
++ u32 lane_count_min = mtk_dp->train_info.lane_count;
++ u32 rate = drm_dp_bw_code_to_link_rate(mtk_dp->train_info.link_rate) *
++ lane_count_min;
+
+ *num_input_fmts = 0;
+
+@@ -2371,8 +2377,8 @@ static u32 *mtk_dp_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
+ * datarate of YUV422 and sink device supports YUV422, we output YUV422
+ * format. Use this condition, we can support more resolution.
+ */
+- if ((rate < (mode->clock * 24 / 8)) &&
+- (rate > (mode->clock * 16 / 8)) &&
++ if (((rate * 97 / 100) < (mode->clock * 24 / 8)) &&
++ ((rate * 97 / 100) > (mode->clock * 16 / 8)) &&
+ (display_info->color_formats & DRM_COLOR_FORMAT_YCBCR422)) {
+ input_fmts = kcalloc(1, sizeof(*input_fmts), GFP_KERNEL);
+ if (!input_fmts)
+--
+2.39.5
+
--- /dev/null
+From f6fe998e794f95f17995bd2414aaa5fe42addd70 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 25 Oct 2024 16:28:27 +0800
+Subject: drm/mediatek: Fix YCbCr422 color format issue for DP
+
+From: Liankun Yang <liankun.yang@mediatek.com>
+
+[ Upstream commit ef24fbd8f12015ff827973fffefed3902ffd61cc ]
+
+Setting up misc0 for Pixel Encoding Format.
+
+According to the definition of YCbCr in spec 1.2a Table 2-96,
+0x1 << 1 should be written to the register.
+
+Use switch case to distinguish RGB, YCbCr422,
+and unsupported color formats.
+
+Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver")
+Signed-off-by: Liankun Yang <liankun.yang@mediatek.com>
+Link: https://patchwork.kernel.org/project/dri-devel/patch/20241025083036.8829-2-liankun.yang@mediatek.com/
+Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/mediatek/mtk_dp.c | 13 ++++++++-----
+ 1 file changed, 8 insertions(+), 5 deletions(-)
+
+diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
+index 48a4defbc66c..399423cb618c 100644
+--- a/drivers/gpu/drm/mediatek/mtk_dp.c
++++ b/drivers/gpu/drm/mediatek/mtk_dp.c
+@@ -458,18 +458,16 @@ static int mtk_dp_set_color_format(struct mtk_dp *mtk_dp,
+ enum dp_pixelformat color_format)
+ {
+ u32 val;
+-
+- /* update MISC0 */
+- mtk_dp_update_bits(mtk_dp, MTK_DP_ENC0_P0_3034,
+- color_format << DP_TEST_COLOR_FORMAT_SHIFT,
+- DP_TEST_COLOR_FORMAT_MASK);
++ u32 misc0_color;
+
+ switch (color_format) {
+ case DP_PIXELFORMAT_YUV422:
+ val = PIXEL_ENCODE_FORMAT_DP_ENC0_P0_YCBCR422;
++ misc0_color = DP_COLOR_FORMAT_YCbCr422;
+ break;
+ case DP_PIXELFORMAT_RGB:
+ val = PIXEL_ENCODE_FORMAT_DP_ENC0_P0_RGB;
++ misc0_color = DP_COLOR_FORMAT_RGB;
+ break;
+ default:
+ drm_warn(mtk_dp->drm_dev, "Unsupported color format: %d\n",
+@@ -477,6 +475,11 @@ static int mtk_dp_set_color_format(struct mtk_dp *mtk_dp,
+ return -EINVAL;
+ }
+
++ /* update MISC0 */
++ mtk_dp_update_bits(mtk_dp, MTK_DP_ENC0_P0_3034,
++ misc0_color,
++ DP_TEST_COLOR_FORMAT_MASK);
++
+ mtk_dp_update_bits(mtk_dp, MTK_DP_ENC0_P0_303C,
+ val, PIXEL_ENCODE_FORMAT_DP_ENC0_P0_MASK);
+ return 0;
+--
+2.39.5
+
--- /dev/null
+From 7420a63a746cdccd65ea2bb1e2649247bbf0280c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 23 Dec 2024 10:32:27 +0800
+Subject: drm/mediatek: Set private->all_drm_private[i]->drm to NULL if
+ mtk_drm_bind returns err
+
+From: Guoqing Jiang <guoqing.jiang@canonical.com>
+
+[ Upstream commit 36684e9d88a2e2401ae26715a2e217cb4295cea7 ]
+
+The pointer need to be set to NULL, otherwise KASAN complains about
+use-after-free. Because in mtk_drm_bind, all private's drm are set
+as follows.
+
+private->all_drm_private[i]->drm = drm;
+
+And drm will be released by drm_dev_put in case mtk_drm_kms_init returns
+failure. However, the shutdown path still accesses the previous allocated
+memory in drm_atomic_helper_shutdown.
+
+[ 84.874820] watchdog: watchdog0: watchdog did not stop!
+[ 86.512054] ==================================================================
+[ 86.513162] BUG: KASAN: use-after-free in drm_atomic_helper_shutdown+0x33c/0x378
+[ 86.514258] Read of size 8 at addr ffff0000d46fc068 by task shutdown/1
+[ 86.515213]
+[ 86.515455] CPU: 1 UID: 0 PID: 1 Comm: shutdown Not tainted 6.13.0-rc1-mtk+gfa1a78e5d24b-dirty #55
+[ 86.516752] Hardware name: Unknown Product/Unknown Product, BIOS 2022.10 10/01/2022
+[ 86.517960] Call trace:
+[ 86.518333] show_stack+0x20/0x38 (C)
+[ 86.518891] dump_stack_lvl+0x90/0xd0
+[ 86.519443] print_report+0xf8/0x5b0
+[ 86.519985] kasan_report+0xb4/0x100
+[ 86.520526] __asan_report_load8_noabort+0x20/0x30
+[ 86.521240] drm_atomic_helper_shutdown+0x33c/0x378
+[ 86.521966] mtk_drm_shutdown+0x54/0x80
+[ 86.522546] platform_shutdown+0x64/0x90
+[ 86.523137] device_shutdown+0x260/0x5b8
+[ 86.523728] kernel_restart+0x78/0xf0
+[ 86.524282] __do_sys_reboot+0x258/0x2f0
+[ 86.524871] __arm64_sys_reboot+0x90/0xd8
+[ 86.525473] invoke_syscall+0x74/0x268
+[ 86.526041] el0_svc_common.constprop.0+0xb0/0x240
+[ 86.526751] do_el0_svc+0x4c/0x70
+[ 86.527251] el0_svc+0x4c/0xc0
+[ 86.527719] el0t_64_sync_handler+0x144/0x168
+[ 86.528367] el0t_64_sync+0x198/0x1a0
+[ 86.528920]
+[ 86.529157] The buggy address belongs to the physical page:
+[ 86.529972] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff0000d46fd4d0 pfn:0x1146fc
+[ 86.531319] flags: 0xbfffc0000000000(node=0|zone=2|lastcpupid=0xffff)
+[ 86.532267] raw: 0bfffc0000000000 0000000000000000 dead000000000122 0000000000000000
+[ 86.533390] raw: ffff0000d46fd4d0 0000000000000000 00000000ffffffff 0000000000000000
+[ 86.534511] page dumped because: kasan: bad access detected
+[ 86.535323]
+[ 86.535559] Memory state around the buggy address:
+[ 86.536265] ffff0000d46fbf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
+[ 86.537314] ffff0000d46fbf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
+[ 86.538363] >ffff0000d46fc000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
+[ 86.544733] ^
+[ 86.551057] ffff0000d46fc080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
+[ 86.557510] ffff0000d46fc100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
+[ 86.563928] ==================================================================
+[ 86.571093] Disabling lock debugging due to kernel taint
+[ 86.577642] Unable to handle kernel paging request at virtual address e0e9c0920000000b
+[ 86.581834] KASAN: maybe wild-memory-access in range [0x0752049000000058-0x075204900000005f]
+...
+
+Fixes: 1ef7ed48356c ("drm/mediatek: Modify mediatek-drm for mt8195 multi mmsys support")
+Signed-off-by: Guoqing Jiang <guoqing.jiang@canonical.com>
+Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+Link: https://patchwork.kernel.org/project/dri-devel/patch/20241223023227.1258112-1-guoqing.jiang@canonical.com/
+Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+index 600f4ccc90d3..8b41a07c3641 100644
+--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
++++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+@@ -633,6 +633,8 @@ static int mtk_drm_bind(struct device *dev)
+ err_free:
+ private->drm = NULL;
+ drm_dev_put(drm);
++ for (i = 0; i < private->data->mmsys_dev_num; i++)
++ private->all_drm_private[i]->drm = NULL;
+ return ret;
+ }
+
+--
+2.39.5
+
--- /dev/null
+From 7ee0c511eeab6b8895e1b67aebf0b2ba5d2b2f0a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 18 Dec 2024 09:58:31 +0100
+Subject: drm/mediatek: stop selecting foreign drivers
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+[ Upstream commit 924d66011f2401a4145e2e814842c5c4572e439f ]
+
+The PHY portion of the mediatek hdmi driver was originally part of
+the driver it self and later split out into drivers/phy, which a
+'select' to keep the prior behavior.
+
+However, this leads to build failures when the PHY driver cannot
+be built:
+
+WARNING: unmet direct dependencies detected for PHY_MTK_HDMI
+ Depends on [n]: (ARCH_MEDIATEK || COMPILE_TEST [=y]) && COMMON_CLK [=y] && OF [=y] && REGULATOR [=n]
+ Selected by [m]:
+ - DRM_MEDIATEK_HDMI [=m] && HAS_IOMEM [=y] && DRM [=m] && DRM_MEDIATEK [=m]
+ERROR: modpost: "devm_regulator_register" [drivers/phy/mediatek/phy-mtk-hdmi-drv.ko] undefined!
+ERROR: modpost: "rdev_get_drvdata" [drivers/phy/mediatek/phy-mtk-hdmi-drv.ko] undefined!
+
+The best option here is to just not select the phy driver and leave that
+up to the defconfig. Do the same for the other PHY and memory drivers
+selected here as well for consistency.
+
+Fixes: a481bf2f0ca4 ("drm/mediatek: Separate mtk_hdmi_phy to an independent module")
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+Reviewed-by: CK Hu <ck.hu@mediatek.com>
+Link: https://patchwork.kernel.org/project/dri-devel/patch/20241218085837.2670434-1-arnd@kernel.org/
+Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/mediatek/Kconfig | 5 -----
+ 1 file changed, 5 deletions(-)
+
+diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
+index 76cab28e010c..d2652751d190 100644
+--- a/drivers/gpu/drm/mediatek/Kconfig
++++ b/drivers/gpu/drm/mediatek/Kconfig
+@@ -10,9 +10,6 @@ config DRM_MEDIATEK
+ select DRM_KMS_HELPER
+ select DRM_MIPI_DSI
+ select DRM_PANEL
+- select MEMORY
+- select MTK_SMI
+- select PHY_MTK_MIPI_DSI
+ select VIDEOMODE_HELPERS
+ help
+ Choose this option if you have a Mediatek SoCs.
+@@ -23,7 +20,6 @@ config DRM_MEDIATEK
+ config DRM_MEDIATEK_DP
+ tristate "DRM DPTX Support for MediaTek SoCs"
+ depends on DRM_MEDIATEK
+- select PHY_MTK_DP
+ select DRM_DISPLAY_HELPER
+ select DRM_DISPLAY_DP_HELPER
+ select DRM_DP_AUX_BUS
+@@ -34,6 +30,5 @@ config DRM_MEDIATEK_HDMI
+ tristate "DRM HDMI Support for Mediatek SoCs"
+ depends on DRM_MEDIATEK
+ select SND_SOC_HDMI_CODEC if SND_SOC
+- select PHY_MTK_HDMI
+ help
+ DRM/KMS HDMI driver for Mediatek SoCs
+--
+2.39.5
+
--- /dev/null
+From 8f22976c337b0990e25b16b0fde21d043d8405cc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 23 Dec 2024 23:30:50 +0800
+Subject: ksmbd: fix a missing return value check bug
+
+From: Wentao Liang <liangwentao@iscas.ac.cn>
+
+[ Upstream commit 4c16e1cadcbcaf3c82d5fc310fbd34d0f5d0db7c ]
+
+In the smb2_send_interim_resp(), if ksmbd_alloc_work_struct()
+fails to allocate a node, it returns a NULL pointer to the
+in_work pointer. This can lead to an illegal memory write of
+in_work->response_buf when allocate_interim_rsp_buf() attempts
+to perform a kzalloc() on it.
+
+To address this issue, incorporating a check for the return
+value of ksmbd_alloc_work_struct() ensures that the function
+returns immediately upon allocation failure, thereby preventing
+the aforementioned illegal memory access.
+
+Fixes: 041bba4414cd ("ksmbd: fix wrong interim response on compound")
+Signed-off-by: Wentao Liang <liangwentao@iscas.ac.cn>
+Acked-by: Namjae Jeon <linkinjeon@kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/smb/server/smb2pdu.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c
+index 2884ebdc0eda..94b4a2565b2a 100644
+--- a/fs/smb/server/smb2pdu.c
++++ b/fs/smb/server/smb2pdu.c
+@@ -695,6 +695,9 @@ void smb2_send_interim_resp(struct ksmbd_work *work, __le32 status)
+ struct smb2_hdr *rsp_hdr;
+ struct ksmbd_work *in_work = ksmbd_alloc_work_struct();
+
++ if (!in_work)
++ return;
++
+ if (allocate_interim_rsp_buf(in_work)) {
+ pr_err("smb_allocate_rsp_buf failed!\n");
+ ksmbd_free_work_struct(in_work);
+--
+2.39.5
+
--- /dev/null
+From 01ac20c0a0c86e3890ed156f7e77c0f4e23c1524 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 6 Jan 2025 03:39:54 +0000
+Subject: ksmbd: fix unexpectedly changed path in ksmbd_vfs_kern_path_locked
+
+From: He Wang <xw897002528@gmail.com>
+
+[ Upstream commit 2ac538e40278a2c0c051cca81bcaafc547d61372 ]
+
+When `ksmbd_vfs_kern_path_locked` met an error and it is not the last
+entry, it will exit without restoring changed path buffer. But later this
+buffer may be used as the filename for creation.
+
+Fixes: c5a709f08d40 ("ksmbd: handle caseless file creation")
+Signed-off-by: He Wang <xw897002528@gmail.com>
+Acked-by: Namjae Jeon <linkinjeon@kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/smb/server/vfs.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/fs/smb/server/vfs.c b/fs/smb/server/vfs.c
+index 2c548e8efef0..d0c19ad9d014 100644
+--- a/fs/smb/server/vfs.c
++++ b/fs/smb/server/vfs.c
+@@ -1259,6 +1259,8 @@ int ksmbd_vfs_kern_path_locked(struct ksmbd_work *work, char *name,
+ filepath,
+ flags,
+ path);
++ if (!is_last)
++ next[0] = '/';
+ if (err)
+ goto out2;
+ else if (is_last)
+@@ -1266,7 +1268,6 @@ int ksmbd_vfs_kern_path_locked(struct ksmbd_work *work, char *name,
+ path_put(parent_path);
+ *parent_path = *path;
+
+- next[0] = '/';
+ remain_len -= filename_len + 1;
+ }
+
+--
+2.39.5
+
--- /dev/null
+From 7663265a6f3921d7e8707c7f6774b4b48da14553 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 6 Jan 2025 18:40:34 +0100
+Subject: platform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually
+ enabled it
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
+
+[ Upstream commit dd410d784402c5775f66faf8b624e85e41c38aaf ]
+
+Wakeup for IRQ1 should be disabled only in cases where i8042 had
+actually enabled it, otherwise "wake_depth" for this IRQ will try to
+drop below zero and there will be an unpleasant WARN() logged:
+
+kernel: atkbd serio0: Disabling IRQ1 wakeup source to avoid platform firmware bug
+kernel: ------------[ cut here ]------------
+kernel: Unbalanced IRQ 1 wake disable
+kernel: WARNING: CPU: 10 PID: 6431 at kernel/irq/manage.c:920 irq_set_irq_wake+0x147/0x1a0
+
+The PMC driver uses DEFINE_SIMPLE_DEV_PM_OPS() to define its dev_pm_ops
+which sets amd_pmc_suspend_handler() to the .suspend, .freeze, and
+.poweroff handlers. i8042_pm_suspend(), however, is only set as
+the .suspend handler.
+
+Fix the issue by call PMC suspend handler only from the same set of
+dev_pm_ops handlers as i8042_pm_suspend(), which currently means just
+the .suspend handler.
+
+To reproduce this issue try hibernating (S4) the machine after a fresh boot
+without putting it into s2idle first.
+
+Fixes: 8e60615e8932 ("platform/x86/amd: pmc: Disable IRQ1 wakeup for RN/CZN")
+Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
+Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
+Link: https://lore.kernel.org/r/c8f28c002ca3c66fbeeb850904a1f43118e17200.1736184606.git.mail@maciej.szmigiero.name
+[ij: edited the commit message.]
+Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/platform/x86/amd/pmc/pmc.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/platform/x86/amd/pmc/pmc.c b/drivers/platform/x86/amd/pmc/pmc.c
+index f49b1bb258c7..70907e8f3ea9 100644
+--- a/drivers/platform/x86/amd/pmc/pmc.c
++++ b/drivers/platform/x86/amd/pmc/pmc.c
+@@ -878,6 +878,10 @@ static int amd_pmc_suspend_handler(struct device *dev)
+ {
+ struct amd_pmc_dev *pdev = dev_get_drvdata(dev);
+
++ /*
++ * Must be called only from the same set of dev_pm_ops handlers
++ * as i8042_pm_suspend() is called: currently just from .suspend.
++ */
+ if (pdev->disable_8042_wakeup && !disable_workarounds) {
+ int rc = amd_pmc_wa_irq1(pdev);
+
+@@ -890,7 +894,9 @@ static int amd_pmc_suspend_handler(struct device *dev)
+ return 0;
+ }
+
+-static DEFINE_SIMPLE_DEV_PM_OPS(amd_pmc_pm, amd_pmc_suspend_handler, NULL);
++static const struct dev_pm_ops amd_pmc_pm = {
++ .suspend = amd_pmc_suspend_handler,
++};
+
+ static const struct pci_device_id pmc_pci_ids[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_AMD, AMD_CPU_ID_PS) },
+--
+2.39.5
+
--- /dev/null
+From 82057431f20b4833627f6d870b50fcbf657083d1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 9 Dec 2024 20:26:17 +0800
+Subject: riscv: mm: Fix the out of bound issue of vmemmap address
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Xu Lu <luxu.kernel@bytedance.com>
+
+[ Upstream commit f754f27e98f88428aaf6be6e00f5cbce97f62d4b ]
+
+In sparse vmemmap model, the virtual address of vmemmap is calculated as:
+((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)).
+And the struct page's va can be calculated with an offset:
+(vmemmap + (pfn)).
+
+However, when initializing struct pages, kernel actually starts from the
+first page from the same section that phys_ram_base belongs to. If the
+first page's physical address is not (phys_ram_base >> PAGE_SHIFT), then
+we get an va below VMEMMAP_START when calculating va for it's struct page.
+
+For example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the
+first page in the same section is actually pfn 0x80000. During
+init_unavailable_range(), we will initialize struct page for pfn 0x80000
+with virtual address ((struct page *)VMEMMAP_START - 0x2000), which is
+below VMEMMAP_START as well as PCI_IO_END.
+
+This commit fixes this bug by introducing a new variable
+'vmemmap_start_pfn' which is aligned with memory section size and using
+it to calculate vmemmap address instead of phys_ram_base.
+
+Fixes: a11dd49dcb93 ("riscv: Sparse-Memory/vmemmap out-of-bounds fix")
+Signed-off-by: Xu Lu <luxu.kernel@bytedance.com>
+Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
+Tested-by: Björn Töpel <bjorn@rivosinc.com>
+Reviewed-by: Björn Töpel <bjorn@rivosinc.com>
+Link: https://lore.kernel.org/r/20241209122617.53341-1-luxu.kernel@bytedance.com
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/riscv/include/asm/page.h | 1 +
+ arch/riscv/include/asm/pgtable.h | 2 +-
+ arch/riscv/mm/init.c | 17 ++++++++++++++++-
+ 3 files changed, 18 insertions(+), 2 deletions(-)
+
+diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h
+index 94b3d6930fc3..4d1f58848129 100644
+--- a/arch/riscv/include/asm/page.h
++++ b/arch/riscv/include/asm/page.h
+@@ -122,6 +122,7 @@ struct kernel_mapping {
+
+ extern struct kernel_mapping kernel_map;
+ extern phys_addr_t phys_ram_base;
++extern unsigned long vmemmap_start_pfn;
+
+ #define is_kernel_mapping(x) \
+ ((x) >= kernel_map.virt_addr && (x) < (kernel_map.virt_addr + kernel_map.size))
+diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
+index 37829dab4a0a..f540b2625714 100644
+--- a/arch/riscv/include/asm/pgtable.h
++++ b/arch/riscv/include/asm/pgtable.h
+@@ -84,7 +84,7 @@
+ * Define vmemmap for pfn_to_page & page_to_pfn calls. Needed if kernel
+ * is configured with CONFIG_SPARSEMEM_VMEMMAP enabled.
+ */
+-#define vmemmap ((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT))
++#define vmemmap ((struct page *)VMEMMAP_START - vmemmap_start_pfn)
+
+ #define PCI_IO_SIZE SZ_16M
+ #define PCI_IO_END VMEMMAP_START
+diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
+index 3245bb525212..bdf8ac6c7e30 100644
+--- a/arch/riscv/mm/init.c
++++ b/arch/riscv/mm/init.c
+@@ -32,6 +32,7 @@
+ #include <asm/ptdump.h>
+ #include <asm/sections.h>
+ #include <asm/soc.h>
++#include <asm/sparsemem.h>
+ #include <asm/tlbflush.h>
+
+ #include "../kernel/head.h"
+@@ -57,6 +58,13 @@ EXPORT_SYMBOL(pgtable_l5_enabled);
+ phys_addr_t phys_ram_base __ro_after_init;
+ EXPORT_SYMBOL(phys_ram_base);
+
++#ifdef CONFIG_SPARSEMEM_VMEMMAP
++#define VMEMMAP_ADDR_ALIGN (1ULL << SECTION_SIZE_BITS)
++
++unsigned long vmemmap_start_pfn __ro_after_init;
++EXPORT_SYMBOL(vmemmap_start_pfn);
++#endif
++
+ unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)]
+ __page_aligned_bss;
+ EXPORT_SYMBOL(empty_zero_page);
+@@ -221,8 +229,12 @@ static void __init setup_bootmem(void)
+ * Make sure we align the start of the memory on a PMD boundary so that
+ * at worst, we map the linear mapping with PMD mappings.
+ */
+- if (!IS_ENABLED(CONFIG_XIP_KERNEL))
++ if (!IS_ENABLED(CONFIG_XIP_KERNEL)) {
+ phys_ram_base = memblock_start_of_DRAM() & PMD_MASK;
++#ifdef CONFIG_SPARSEMEM_VMEMMAP
++ vmemmap_start_pfn = round_down(phys_ram_base, VMEMMAP_ADDR_ALIGN) >> PAGE_SHIFT;
++#endif
++ }
+
+ /*
+ * In 64-bit, any use of __va/__pa before this point is wrong as we
+@@ -1080,6 +1092,9 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa)
+ kernel_map.xiprom_sz = (uintptr_t)(&_exiprom) - (uintptr_t)(&_xiprom);
+
+ phys_ram_base = CONFIG_PHYS_RAM_BASE;
++#ifdef CONFIG_SPARSEMEM_VMEMMAP
++ vmemmap_start_pfn = round_down(phys_ram_base, VMEMMAP_ADDR_ALIGN) >> PAGE_SHIFT;
++#endif
+ kernel_map.phys_addr = (uintptr_t)CONFIG_PHYS_RAM_BASE;
+ kernel_map.size = (uintptr_t)(&_end) - (uintptr_t)(&_start);
+
+--
+2.39.5
+
sched-sch_cake-add-bounds-checks-to-host-bulk-flow-f.patch
net-stmmac-dwmac-tegra-read-iommu-stream-id-from-dev.patch
net-mlx5-fix-variable-not-being-completed-when-funct.patch
+drm-mediatek-set-private-all_drm_private-i-drm-to-nu.patch
+drm-mediatek-stop-selecting-foreign-drivers.patch
+drm-mediatek-fix-ycbcr422-color-format-issue-for-dp.patch
+drm-mediatek-fix-mode-valid-issue-for-dp.patch
+drm-mediatek-add-return-value-check-when-reading-dpc.patch
+ksmbd-fix-a-missing-return-value-check-bug.patch
+afs-fix-the-maximum-cell-name-length.patch
+platform-x86-amd-pmc-only-disable-irq1-wakeup-where-.patch
+ksmbd-fix-unexpectedly-changed-path-in-ksmbd_vfs_ker.patch
+cpuidle-riscv-sbi-fix-device-node-release-in-early-e.patch
+riscv-mm-fix-the-out-of-bound-issue-of-vmemmap-addre.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
