Skip to contentSkip to conversation

6.16.5-rc1 review

PATCH In review Greg Kroah-Hartman 15 participants 161 messages Sep 2, 2025 – Sep 5, 2025 Page 2 of 2

Subsystems (4)
lore
Share & tools
lore
author maintainer
#133 lore raw

PATCH 133/142 drm/amdgpu/gfx12: set MQD as appriopriate for queue types

In reply to Greg Kroah-Hartman

6.16-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alex Deucher <[email protected]>

commit 29f155c5e82fe35ff85b1f13612cb8c2dbe1dca3 upstream.

Set the MQD as appropriate for the kernel vs user queues.

(cherry picked from commit 7b9110f2897957efd9715b52fc01986509729db3)
---
 drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c +6 -2
@@ -3022,6 +3022,8 @@ static int gfx_v12_0_gfx_mqd_init(struct
 #endif
 	if (prop->tmz_queue)
 		tmp = REG_SET_FIELD(tmp, CP_GFX_HQD_CNTL, TMZ_MATCH, 1);
+	if (!prop->kernel_queue)
+		tmp = REG_SET_FIELD(tmp, CP_GFX_HQD_CNTL, RB_NON_PRIV, 1);
 	mqd->cp_gfx_hqd_cntl = tmp;
 
 	/* set up cp_doorbell_control */
@@ -3171,8 +3173,10 @@ static int gfx_v12_0_compute_mqd_init(st
 			    (order_base_2(AMDGPU_GPU_PAGE_SIZE / 4) - 1));
 	tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_CONTROL, UNORD_DISPATCH, 1);
 	tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_CONTROL, TUNNEL_DISPATCH, 0);
-	tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_CONTROL, PRIV_STATE, 1);
-	tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_CONTROL, KMD_QUEUE, 1);
+	if (prop->kernel_queue) {
+		tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_CONTROL, PRIV_STATE, 1);
+		tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_CONTROL, KMD_QUEUE, 1);
+	}
 	if (prop->tmz_queue)
 		tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_CONTROL, TMZ, 1);
 	mqd->cp_hqd_pq_control = tmp;
author maintainer
#134 lore raw

PATCH 134/142 net: rose: fix a typo in rose_clear_routes()

In reply to Greg Kroah-Hartman

6.16-stable review patch. If anyone has any objections, please let me know.

------------------

From: Eric Dumazet <[email protected]>

commit 1cc8a5b534e5f9b5e129e54ee2e63c9f5da4f39a upstream.

syzbot crashed in rose_clear_routes(), after a recent patch typo.

KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
CPU: 0 UID: 0 PID: 10591 Comm: syz.3.1856 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025
 RIP: 0010:rose_clear_routes net/rose/rose_route.c:565 [inline]
 RIP: 0010:rose_rt_ioctl+0x162/0x1250 net/rose/rose_route.c:760
 <TASK>
  rose_ioctl+0x3ce/0x8b0 net/rose/af_rose.c:1381
  sock_do_ioctl+0xd9/0x300 net/socket.c:1238
  sock_ioctl+0x576/0x790 net/socket.c:1359
  vfs_ioctl fs/ioctl.c:51 [inline]
  __do_sys_ioctl fs/ioctl.c:598 [inline]
  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:584
  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
  do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
---
 net/rose/rose_route.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/rose/rose_route.c +1 -1
@@ -562,7 +562,7 @@ static int rose_clear_routes(void)
 		rose_node = rose_node->next;
 
 		if (!t->loopback) {
-			for (i = 0; i < rose_node->count; i++)
+			for (i = 0; i < t->count; i++)
 				rose_neigh_put(t->neighbour[i]);
 			rose_remove_node(t);
 		}
author maintainer
#135 lore raw

PATCH 135/142 firmware: qcom: scm: remove unused arguments from SHM bridge routines

In reply to Greg Kroah-Hartman

6.16-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bartosz Golaszewski <[email protected]>

commit 23972da96e1eee7f10c8ef641d56202ab9af8ba7 upstream.

qcom_scm_shm_bridge_create() and qcom_scm_shm_bridge_delete() take struct device as argument but don't use it. Remove it from these functions' prototypes.

---
 drivers/firmware/qcom/qcom_scm.c       |    4 ++--
 drivers/firmware/qcom/qcom_tzmem.c     |    8 ++++----
 include/linux/firmware/qcom/qcom_scm.h |    4 ++--
 3 files changed, 8 insertions(+), 8 deletions(-)
drivers/firmware/qcom/qcom_scm.c +2 -2
@@ -1631,7 +1631,7 @@ int qcom_scm_shm_bridge_enable(void)
 }
 EXPORT_SYMBOL_GPL(qcom_scm_shm_bridge_enable);
 
-int qcom_scm_shm_bridge_create(struct device *dev, u64 pfn_and_ns_perm_flags,
+int qcom_scm_shm_bridge_create(u64 pfn_and_ns_perm_flags,
 			       u64 ipfn_and_s_perm_flags, u64 size_and_flags,
 			       u64 ns_vmids, u64 *handle)
 {
@@ -1659,7 +1659,7 @@ int qcom_scm_shm_bridge_create(struct de
 }
 EXPORT_SYMBOL_GPL(qcom_scm_shm_bridge_create);
 
-int qcom_scm_shm_bridge_delete(struct device *dev, u64 handle)
+int qcom_scm_shm_bridge_delete(u64 handle)
 {
 	struct qcom_scm_desc desc = {
 		.svc = QCOM_SCM_SVC_MP,
drivers/firmware/qcom/qcom_tzmem.c +4 -4
@@ -124,9 +124,9 @@ static int qcom_tzmem_init_area(struct q
 	if (!handle)
 		return -ENOMEM;
 
-	ret = qcom_scm_shm_bridge_create(qcom_tzmem_dev, pfn_and_ns_perm,
-					 ipfn_and_s_perm, size_and_flags,
-					 QCOM_SCM_VMID_HLOS, handle);
+	ret = qcom_scm_shm_bridge_create(pfn_and_ns_perm, ipfn_and_s_perm,
+					 size_and_flags, QCOM_SCM_VMID_HLOS,
+					 handle);
 	if (ret)
 		return ret;
 
@@ -142,7 +142,7 @@ static void qcom_tzmem_cleanup_area(stru
 	if (!qcom_tzmem_using_shm_bridge)
 		return;
 
-	qcom_scm_shm_bridge_delete(qcom_tzmem_dev, *handle);
+	qcom_scm_shm_bridge_delete(*handle);
 	kfree(handle);
 }
 
include/linux/firmware/qcom/qcom_scm.h +2 -2
@@ -149,10 +149,10 @@ bool qcom_scm_lmh_dcvsh_available(void);
 int qcom_scm_gpu_init_regs(u32 gpu_req);
 
 int qcom_scm_shm_bridge_enable(void);
-int qcom_scm_shm_bridge_create(struct device *dev, u64 pfn_and_ns_perm_flags,
+int qcom_scm_shm_bridge_create(u64 pfn_and_ns_perm_flags,
 			       u64 ipfn_and_s_perm_flags, u64 size_and_flags,
 			       u64 ns_vmids, u64 *handle);
-int qcom_scm_shm_bridge_delete(struct device *dev, u64 handle);
+int qcom_scm_shm_bridge_delete(u64 handle);
 
 #ifdef CONFIG_QCOM_QSEECOM
 
author maintainer
#136 lore raw

PATCH 136/142 firmware: qcom: scm: take struct device as argument in SHM bridge enable

In reply to Greg Kroah-Hartman

6.16-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bartosz Golaszewski <[email protected]>

commit dc3f4e75c54c19bad9a70419afae00ce6baf3ebf upstream.

qcom_scm_shm_bridge_enable() is used early in the SCM initialization routine. It makes an SCM call and so expects the internal __scm pointer in the SCM driver to be assigned. For this reason the tzmem memory pool is allocated *after* this pointer is assigned. However, this can lead to a crash if another consumer of the SCM API makes a call using the memory pool between the assignment of the __scm pointer and the initialization of the tzmem memory pool.

As qcom_scm_shm_bridge_enable() is a special case, not meant to be called by ordinary users, pull it into the local SCM header. Make it take struct device as argument. This is the device that will be used to make the SCM call as opposed to the global __scm pointer. This will allow us to move the tzmem initialization *before* the __scm assignment in the core SCM driver.

---
 drivers/firmware/qcom/qcom_scm.c       |   12 +++++++++---
 drivers/firmware/qcom/qcom_scm.h       |    1 +
 drivers/firmware/qcom/qcom_tzmem.c     |    3 ++-
 include/linux/firmware/qcom/qcom_scm.h |    1 -
 4 files changed, 12 insertions(+), 5 deletions(-)
drivers/firmware/qcom/qcom_scm.c +9 -3
@@ -1603,7 +1603,13 @@ bool qcom_scm_lmh_dcvsh_available(void)
 }
 EXPORT_SYMBOL_GPL(qcom_scm_lmh_dcvsh_available);
 
-int qcom_scm_shm_bridge_enable(void)
+/*
+ * This is only supposed to be called once by the TZMem module. It takes the
+ * SCM struct device as argument and uses it to pass the call as at the time
+ * the SHM Bridge is enabled, the SCM is not yet fully set up and doesn't
+ * accept global user calls. Don't try to use the __scm pointer here.
+ */
+int qcom_scm_shm_bridge_enable(struct device *scm_dev)
 {
 	int ret;
 
@@ -1615,11 +1621,11 @@ int qcom_scm_shm_bridge_enable(void)
 
 	struct qcom_scm_res res;
 
-	if (!__qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_MP,
+	if (!__qcom_scm_is_call_available(scm_dev, QCOM_SCM_SVC_MP,
 					  QCOM_SCM_MP_SHM_BRIDGE_ENABLE))
 		return -EOPNOTSUPP;
 
-	ret = qcom_scm_call(__scm->dev, &desc, &res);
+	ret = qcom_scm_call(scm_dev, &desc, &res);
 
 	if (ret)
 		return ret;
drivers/firmware/qcom/qcom_scm.h +1 -0
@@ -83,6 +83,7 @@ int scm_legacy_call(struct device *dev,
 		    struct qcom_scm_res *res);
 
 struct qcom_tzmem_pool *qcom_scm_get_tzmem_pool(void);
+int qcom_scm_shm_bridge_enable(struct device *scm_dev);
 
 #define QCOM_SCM_SVC_BOOT		0x01
 #define QCOM_SCM_BOOT_SET_ADDR		0x01
drivers/firmware/qcom/qcom_tzmem.c +2 -1
@@ -20,6 +20,7 @@
 #include <linux/spinlock.h>
 #include <linux/types.h>
 
+#include "qcom_scm.h"
 #include "qcom_tzmem.h"
 
 struct qcom_tzmem_area {
@@ -94,7 +95,7 @@ static int qcom_tzmem_init(void)
 			goto notsupp;
 	}
 
-	ret = qcom_scm_shm_bridge_enable();
+	ret = qcom_scm_shm_bridge_enable(qcom_tzmem_dev);
 	if (ret == -EOPNOTSUPP)
 		goto notsupp;
 
include/linux/firmware/qcom/qcom_scm.h +0 -1
@@ -148,7 +148,6 @@ bool qcom_scm_lmh_dcvsh_available(void);
 
 int qcom_scm_gpu_init_regs(u32 gpu_req);
 
-int qcom_scm_shm_bridge_enable(void);
 int qcom_scm_shm_bridge_create(u64 pfn_and_ns_perm_flags,
 			       u64 ipfn_and_s_perm_flags, u64 size_and_flags,
 			       u64 ns_vmids, u64 *handle);
author maintainer
#137 lore raw

PATCH 137/142 firmware: qcom: scm: initialize tzmem before marking SCM as available

In reply to Greg Kroah-Hartman

6.16-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bartosz Golaszewski <[email protected]>

commit 87be3e7a2d0030cda6314d2ec96b37991f636ccd upstream.

Now that qcom_scm_shm_bridge_enable() uses the struct device passed to it as argument to make the QCOM_SCM_MP_SHM_BRIDGE_ENABLE SCM call, we can move the TZMem initialization before the assignment of the __scm pointer in the SCM driver (which marks SCM as ready to users) thus fixing the potential race between consumer calls and the memory pool initialization.

---
 drivers/firmware/qcom/qcom_scm.c |   53 +++++++++++++++++++--------------------
 1 file changed, 26 insertions(+), 27 deletions(-)
drivers/firmware/qcom/qcom_scm.c +26 -27
@@ -2256,7 +2256,32 @@ static int qcom_scm_probe(struct platfor
 	if (ret)
 		return ret;
 
-	/* Paired with smp_load_acquire() in qcom_scm_is_available(). */
+	ret = of_reserved_mem_device_init(scm->dev);
+	if (ret && ret != -ENODEV)
+		return dev_err_probe(scm->dev, ret,
+				     "Failed to setup the reserved memory region for TZ mem\n");
+
+	ret = qcom_tzmem_enable(scm->dev);
+	if (ret)
+		return dev_err_probe(scm->dev, ret,
+				     "Failed to enable the TrustZone memory allocator\n");
+
+	memset(&pool_config, 0, sizeof(pool_config));
+	pool_config.initial_size = 0;
+	pool_config.policy = QCOM_TZMEM_POLICY_ON_DEMAND;
+	pool_config.max_size = SZ_256K;
+
+	scm->mempool = devm_qcom_tzmem_pool_new(scm->dev, &pool_config);
+	if (IS_ERR(scm->mempool))
+		return dev_err_probe(scm->dev, PTR_ERR(scm->mempool),
+				     "Failed to create the SCM memory pool\n");
+
+	/*
+	 * Paired with smp_load_acquire() in qcom_scm_is_available().
+	 *
+	 * This marks the SCM API as ready to accept user calls and can only
+	 * be called after the TrustZone memory pool is initialized.
+	 */
 	smp_store_release(&__scm, scm);
 
 	irq = platform_get_irq_optional(pdev, 0);
@@ -2289,32 +2314,6 @@ static int qcom_scm_probe(struct platfor
 	if (of_property_read_bool(pdev->dev.of_node, "qcom,sdi-enabled") || !download_mode)
 		qcom_scm_disable_sdi();
 
-	ret = of_reserved_mem_device_init(__scm->dev);
-	if (ret && ret != -ENODEV) {
-		dev_err_probe(__scm->dev, ret,
-			      "Failed to setup the reserved memory region for TZ mem\n");
-		goto err;
-	}
-
-	ret = qcom_tzmem_enable(__scm->dev);
-	if (ret) {
-		dev_err_probe(__scm->dev, ret,
-			      "Failed to enable the TrustZone memory allocator\n");
-		goto err;
-	}
-
-	memset(&pool_config, 0, sizeof(pool_config));
-	pool_config.initial_size = 0;
-	pool_config.policy = QCOM_TZMEM_POLICY_ON_DEMAND;
-	pool_config.max_size = SZ_256K;
-
-	__scm->mempool = devm_qcom_tzmem_pool_new(__scm->dev, &pool_config);
-	if (IS_ERR(__scm->mempool)) {
-		ret = dev_err_probe(__scm->dev, PTR_ERR(__scm->mempool),
-				    "Failed to create the SCM memory pool\n");
-		goto err;
-	}
-
 	/*
 	 * Initialize the QSEECOM interface.
 	 *
author maintainer
#138 lore raw

PATCH 138/142 firmware: qcom: scm: request the waitqueue irq *after* initializing SCM

In reply to Greg Kroah-Hartman

6.16-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bartosz Golaszewski <[email protected]>

commit 7ab36b51c6bee56e1a1939063dd10d602fe49d13 upstream.

There's a subtle race in the SCM driver: we assign the __scm pointer before requesting the waitqueue interrupt. Assigning __scm marks the SCM API as ready to accept calls. It's possible that a user makes a call right after we set __scm and the firmware raises an interrupt before the driver's ready to service it. Move the __scm assignment after we request the interrupt.

This has the added benefit of allowing us to drop the goto label.

---
 drivers/firmware/qcom/qcom_scm.c |   36 ++++++++++++++----------------------
 1 file changed, 14 insertions(+), 22 deletions(-)
drivers/firmware/qcom/qcom_scm.c +14 -22
@@ -2276,29 +2276,27 @@ static int qcom_scm_probe(struct platfor
 		return dev_err_probe(scm->dev, PTR_ERR(scm->mempool),
 				     "Failed to create the SCM memory pool\n");
 
+	irq = platform_get_irq_optional(pdev, 0);
+	if (irq < 0) {
+		if (irq != -ENXIO)
+			return irq;
+	} else {
+		ret = devm_request_threaded_irq(scm->dev, irq, NULL, qcom_scm_irq_handler,
+						IRQF_ONESHOT, "qcom-scm", scm);
+		if (ret < 0)
+			return dev_err_probe(scm->dev, ret,
+					     "Failed to request qcom-scm irq\n");
+	}
+
 	/*
 	 * Paired with smp_load_acquire() in qcom_scm_is_available().
 	 *
 	 * This marks the SCM API as ready to accept user calls and can only
-	 * be called after the TrustZone memory pool is initialized.
+	 * be called after the TrustZone memory pool is initialized and the
+	 * waitqueue interrupt requested.
 	 */
 	smp_store_release(&__scm, scm);
 
-	irq = platform_get_irq_optional(pdev, 0);
-	if (irq < 0) {
-		if (irq != -ENXIO) {
-			ret = irq;
-			goto err;
-		}
-	} else {
-		ret = devm_request_threaded_irq(__scm->dev, irq, NULL, qcom_scm_irq_handler,
-						IRQF_ONESHOT, "qcom-scm", __scm);
-		if (ret < 0) {
-			dev_err_probe(scm->dev, ret, "Failed to request qcom-scm irq\n");
-			goto err;
-		}
-	}
-
 	__get_convention();
 
 	/*
@@ -2328,12 +2326,6 @@ static int qcom_scm_probe(struct platfor
 	WARN(ret < 0, "failed to initialize qseecom: %d\n", ret);
 
 	return 0;
-
-err:
-	/* Paired with smp_load_acquire() in qcom_scm_is_available(). */
-	smp_store_release(&__scm, NULL);
-
-	return ret;
 }
 
 static void qcom_scm_shutdown(struct platform_device *pdev)
author maintainer
#139 lore raw

PATCH 139/142 Revert "drm/dp: Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS"

In reply to Greg Kroah-Hartman

6.16-stable review patch. If anyone has any objections, please let me know.

------------------

From: Imre Deak <[email protected]>

This reverts commit 944e732be9c3a33e64e9fb0f5451a37fc252ddfc which is commit a40c5d727b8111b5db424a1e43e14a1dcce1e77f upstream.

The upstream commit a40c5d727b8111b5db424a1e43e14a1dcce1e77f ("drm/dp:
Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS") the reverted commit backported causes a regression, on one eDP panel at least resulting in display flickering, described in detail at the Link:
below. The issue fixed by the upstream commit will need a different solution, revert the backport for now.

---
 drivers/gpu/drm/display/drm_dp_helper.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/display/drm_dp_helper.c +1 -1
@@ -725,7 +725,7 @@ ssize_t drm_dp_dpcd_read(struct drm_dp_a
 	 * monitor doesn't power down exactly after the throw away read.
 	 */
 	if (!aux->is_remote) {
-		ret = drm_dp_dpcd_probe(aux, DP_LANE0_1_STATUS);
+		ret = drm_dp_dpcd_probe(aux, DP_DPCD_REV);
 		if (ret < 0)
 			return ret;
 	}
#140 lore raw

Re: [PATCH 6.16 139/142] Revert "drm/dp: Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS"

Hi Greg,

Quoted 1 line · Greg Kroah-Hartman

6.16-stable review patch. If anyone has any objections, please let me know.

Thanks for queuing this and the corresponding reverts for the other stable trees. This one patch doesn't match what I sent, the address should be changed to DP_TRAINING_PATTERN_SET not to DP_DPCD_REV, see [1]. I still think that's the correct thing to do here conforming to the DP Standard and matching what the upstream kernel does, also solving a link training issue for a DP2.0 docking station.

The reverts queued for the other stable trees are correct, since for now I do not want to change the behavior in those (i.e. those trees should continue to use the DP_DPCD_REV register matching what's been the case since the DPCD probing was introduced).

Thanks,
Imre

[1] https://lore.kernel.org/all/[email protected]

Quoted 37 lines

------------------

From: Imre Deak <[email protected]>

This reverts commit 944e732be9c3a33e64e9fb0f5451a37fc252ddfc which is commit a40c5d727b8111b5db424a1e43e14a1dcce1e77f upstream.

The upstream commit a40c5d727b8111b5db424a1e43e14a1dcce1e77f ("drm/dp:
Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS") the reverted commit backported causes a regression, on one eDP panel at least resulting in display flickering, described in detail at the Link:
below. The issue fixed by the upstream commit will need a different solution, revert the backport for now.

---
 drivers/gpu/drm/display/drm_dp_helper.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/display/drm_dp_helper.c +1 -1
@@ -725,7 +725,7 @@ ssize_t drm_dp_dpcd_read(struct drm_dp_a
 	 * monitor doesn't power down exactly after the throw away read.
 	 */
 	if (!aux->is_remote) {
-		ret = drm_dp_dpcd_probe(aux, DP_LANE0_1_STATUS);
+		ret = drm_dp_dpcd_probe(aux, DP_DPCD_REV);
 		if (ret < 0)
 			return ret;
 	}
author maintainer
#141 lore raw

Re: [PATCH 6.16 139/142] Revert "drm/dp: Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS"

Quoted 12 lines · Imre Deak

Hi Greg,

Quoted 1 line · Greg Kroah-Hartman

6.16-stable review patch. If anyone has any objections, please let me know.

Thanks for queuing this and the corresponding reverts for the other stable trees. This one patch doesn't match what I sent, the address should be changed to DP_TRAINING_PATTERN_SET not to DP_DPCD_REV, see [1]. I still think that's the correct thing to do here conforming to the DP Standard and matching what the upstream kernel does, also solving a link training issue for a DP2.0 docking station.

Quoted 4 lines

The reverts queued for the other stable trees are correct, since for now I do not want to change the behavior in those (i.e. those trees should continue to use the DP_DPCD_REV register matching what's been the case since the DPCD probing was introduced).

Ick, why were the values different for different branches? That feels wrong, and is why I missed that. Can you just send a fix-up patch for the one I got wrong?

thanks,

greg k-h

#142 lore raw

Re: [PATCH 6.16 139/142] Revert "drm/dp: Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS"

Quoted 13 lines · Greg Kroah-Hartman
Quoted 12 lines · Imre Deak

Hi Greg,

Quoted 1 line · Greg Kroah-Hartman

6.16-stable review patch. If anyone has any objections, please let me know.

Thanks for queuing this and the corresponding reverts for the other stable trees. This one patch doesn't match what I sent, the address should be changed to DP_TRAINING_PATTERN_SET not to DP_DPCD_REV, see [1]. I still think that's the correct thing to do here conforming to the DP Standard and matching what the upstream kernel does, also solving a link training issue for a DP2.0 docking station.

Quoted 7 lines
Quoted 4 lines

The reverts queued for the other stable trees are correct, since for now I do not want to change the behavior in those (i.e. those trees should continue to use the DP_DPCD_REV register matching what's been the case since the DPCD probing was introduced).

Ick, why were the values different for different branches? That feels wrong, and is why I missed that.

The requirement for changing the DPCD probe address was only introduced/clarified by a recent DP Standard version (with the introducation of LTTPR / UHBR link rates), so in the DRM code this got changed only in v6.16.0. However, this change revealed a bug in the firmwares of an eDP panel and Thunderbolt host, which also had to be fixed/worked around. The only such remaining issue is the latter one tracked at [1], which is now fixed by [2].

Based on all the above I still would like to keep the change only in the v6.16 tree and not backport it to earlier stable trees, until having more confidence that the change doesn't cause an issue for any sink device.

Quoted 1 line

Can you just send a fix-up patch for the one I got wrong?

Ok, I can send a patch for v6.16.y on top of what is already queued there.

--Imre

[1] https://gitlab.freedesktop.org/drm/amd/-/issues/4500
[2] https://lore.kernel.org/all/[email protected]

Quoted 3 lines

thanks,

greg k-h

author maintainer
#143 lore raw

Re: [PATCH 6.16 139/142] Revert "drm/dp: Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS"

Quoted 35 lines · Imre Deak
Quoted 13 lines · Greg Kroah-Hartman
Quoted 12 lines · Imre Deak

Hi Greg,

Quoted 1 line · Greg Kroah-Hartman

6.16-stable review patch. If anyone has any objections, please let me know.

Thanks for queuing this and the corresponding reverts for the other stable trees. This one patch doesn't match what I sent, the address should be changed to DP_TRAINING_PATTERN_SET not to DP_DPCD_REV, see [1]. I still think that's the correct thing to do here conforming to the DP Standard and matching what the upstream kernel does, also solving a link training issue for a DP2.0 docking station.

Quoted 7 lines
Quoted 4 lines

The reverts queued for the other stable trees are correct, since for now I do not want to change the behavior in those (i.e. those trees should continue to use the DP_DPCD_REV register matching what's been the case since the DPCD probing was introduced).

Ick, why were the values different for different branches? That feels wrong, and is why I missed that.

The requirement for changing the DPCD probe address was only introduced/clarified by a recent DP Standard version (with the introducation of LTTPR / UHBR link rates), so in the DRM code this got changed only in v6.16.0. However, this change revealed a bug in the firmwares of an eDP panel and Thunderbolt host, which also had to be fixed/worked around. The only such remaining issue is the latter one tracked at [1], which is now fixed by [2].

Based on all the above I still would like to keep the change only in the v6.16 tree and not backport it to earlier stable trees, until having more confidence that the change doesn't cause an issue for any sink device.

Quoted 4 lines
Quoted 1 line

Can you just send a fix-up patch for the one I got wrong?

Ok, I can send a patch for v6.16.y on top of what is already queued there.

It's already in a release :)

thanks,

greg k-h

#144 lore raw

Re: [PATCH 6.16 139/142] Revert "drm/dp: Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS"

Quoted 36 lines · Greg Kroah-Hartman
Quoted 35 lines · Imre Deak
Quoted 13 lines · Greg Kroah-Hartman
Quoted 12 lines · Imre Deak

Hi Greg,

Quoted 1 line · Greg Kroah-Hartman

6.16-stable review patch. If anyone has any objections, please let me know.

Thanks for queuing this and the corresponding reverts for the other stable trees. This one patch doesn't match what I sent, the address should be changed to DP_TRAINING_PATTERN_SET not to DP_DPCD_REV, see [1]. I still think that's the correct thing to do here conforming to the DP Standard and matching what the upstream kernel does, also solving a link training issue for a DP2.0 docking station.

Quoted 7 lines
Quoted 4 lines

The reverts queued for the other stable trees are correct, since for now I do not want to change the behavior in those (i.e. those trees should continue to use the DP_DPCD_REV register matching what's been the case since the DPCD probing was introduced).

Ick, why were the values different for different branches? That feels wrong, and is why I missed that.

The requirement for changing the DPCD probe address was only introduced/clarified by a recent DP Standard version (with the introducation of LTTPR / UHBR link rates), so in the DRM code this got changed only in v6.16.0. However, this change revealed a bug in the firmwares of an eDP panel and Thunderbolt host, which also had to be fixed/worked around. The only such remaining issue is the latter one tracked at [1], which is now fixed by [2].

Based on all the above I still would like to keep the change only in the v6.16 tree and not backport it to earlier stable trees, until having more confidence that the change doesn't cause an issue for any sink device.

Quoted 6 lines
Quoted 4 lines
Quoted 1 line

Can you just send a fix-up patch for the one I got wrong?

Ok, I can send a patch for v6.16.y on top of what is already queued there.

It's already in a release :)

Ok, missed that. The fix would be only for the next release then, with the above justification.

Quoted 3 lines

thanks,

greg k-h

author maintainer
#145 lore raw

PATCH 140/142 thermal/drivers/mediatek/lvts_thermal: Change lvts commands array to static const

In reply to Greg Kroah-Hartman

6.16-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mason Chang <[email protected]>

commit c5d5a72c01f7faabe7cc0fd63942c18372101daf upstream.

Change the LVTS commands array to static const in preparation for adding different commands.

---
 drivers/thermal/mediatek/lvts_thermal.c |   29 +++++++++++++++--------------
 1 file changed, 15 insertions(+), 14 deletions(-)
drivers/thermal/mediatek/lvts_thermal.c +15 -14
@@ -96,6 +96,17 @@
 
 #define LVTS_MINIMUM_THRESHOLD		20000
 
+static const u32 default_conn_cmds[] = { 0xC103FFFF, 0xC502FF55 };
+/*
+ * Write device mask: 0xC1030000
+ */
+static const u32 default_init_cmds[] = {
+	0xC1030E01, 0xC1030CFC, 0xC1030A8C, 0xC103098D, 0xC10308F1,
+	0xC10307A6, 0xC10306B8, 0xC1030500, 0xC1030420, 0xC1030300,
+	0xC1030030, 0xC10300F6, 0xC1030050, 0xC1030060, 0xC10300AC,
+	0xC10300FC, 0xC103009D, 0xC10300F1, 0xC10300E1
+};
+
 static int golden_temp = LVTS_GOLDEN_TEMP_DEFAULT;
 static int golden_temp_offset;
 
@@ -902,7 +913,7 @@ static void lvts_ctrl_monitor_enable(str
  * each write in the configuration register must be separated by a
  * delay of 2 us.
  */
-static void lvts_write_config(struct lvts_ctrl *lvts_ctrl, u32 *cmds, int nr_cmds)
+static void lvts_write_config(struct lvts_ctrl *lvts_ctrl, const u32 *cmds, int nr_cmds)
 {
 	int i;
 
@@ -985,9 +996,9 @@ static int lvts_ctrl_set_enable(struct l
 
 static int lvts_ctrl_connect(struct device *dev, struct lvts_ctrl *lvts_ctrl)
 {
-	u32 id, cmds[] = { 0xC103FFFF, 0xC502FF55 };
+	u32 id;
 
-	lvts_write_config(lvts_ctrl, cmds, ARRAY_SIZE(cmds));
+	lvts_write_config(lvts_ctrl, default_conn_cmds, ARRAY_SIZE(default_conn_cmds));
 
 	/*
 	 * LVTS_ID : Get ID and status of the thermal controller
@@ -1006,17 +1017,7 @@ static int lvts_ctrl_connect(struct devi
 
 static int lvts_ctrl_initialize(struct device *dev, struct lvts_ctrl *lvts_ctrl)
 {
-	/*
-	 * Write device mask: 0xC1030000
-	 */
-	u32 cmds[] = {
-		0xC1030E01, 0xC1030CFC, 0xC1030A8C, 0xC103098D, 0xC10308F1,
-		0xC10307A6, 0xC10306B8, 0xC1030500, 0xC1030420, 0xC1030300,
-		0xC1030030, 0xC10300F6, 0xC1030050, 0xC1030060, 0xC10300AC,
-		0xC10300FC, 0xC103009D, 0xC10300F1, 0xC10300E1
-	};
-
-	lvts_write_config(lvts_ctrl, cmds, ARRAY_SIZE(cmds));
+	lvts_write_config(lvts_ctrl, default_init_cmds, ARRAY_SIZE(default_init_cmds));
 
 	return 0;
 }
author maintainer
#146 lore raw

PATCH 141/142 thermal/drivers/mediatek/lvts_thermal: Add lvts commands and their sizes to driver data

In reply to Greg Kroah-Hartman

6.16-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mason Chang <[email protected]>

commit 6203a5e6fd090ed05f6d9b92e33bc7e7679a3dd6 upstream.

Add LVTS commands and their sizes to driver data in preparation for adding different commands.

---
 drivers/thermal/mediatek/lvts_thermal.c |   65 +++++++++++++++++++++++++-------
 1 file changed, 52 insertions(+), 13 deletions(-)
drivers/thermal/mediatek/lvts_thermal.c +52 -13
@@ -96,17 +96,6 @@
 
 #define LVTS_MINIMUM_THRESHOLD		20000
 
-static const u32 default_conn_cmds[] = { 0xC103FFFF, 0xC502FF55 };
-/*
- * Write device mask: 0xC1030000
- */
-static const u32 default_init_cmds[] = {
-	0xC1030E01, 0xC1030CFC, 0xC1030A8C, 0xC103098D, 0xC10308F1,
-	0xC10307A6, 0xC10306B8, 0xC1030500, 0xC1030420, 0xC1030300,
-	0xC1030030, 0xC10300F6, 0xC1030050, 0xC1030060, 0xC10300AC,
-	0xC10300FC, 0xC103009D, 0xC10300F1, 0xC10300E1
-};
-
 static int golden_temp = LVTS_GOLDEN_TEMP_DEFAULT;
 static int golden_temp_offset;
 
@@ -136,7 +125,11 @@ struct lvts_ctrl_data {
 
 struct lvts_data {
 	const struct lvts_ctrl_data *lvts_ctrl;
+	const u32 *conn_cmd;
+	const u32 *init_cmd;
 	int num_lvts_ctrl;
+	int num_conn_cmd;
+	int num_init_cmd;
 	int temp_factor;
 	int temp_offset;
 	int gt_calib_bit_offset;
@@ -996,9 +989,10 @@ static int lvts_ctrl_set_enable(struct l
 
 static int lvts_ctrl_connect(struct device *dev, struct lvts_ctrl *lvts_ctrl)
 {
+	const struct lvts_data *lvts_data = lvts_ctrl->lvts_data;
 	u32 id;
 
-	lvts_write_config(lvts_ctrl, default_conn_cmds, ARRAY_SIZE(default_conn_cmds));
+	lvts_write_config(lvts_ctrl, lvts_data->conn_cmd, lvts_data->num_conn_cmd);
 
 	/*
 	 * LVTS_ID : Get ID and status of the thermal controller
@@ -1017,7 +1011,9 @@ static int lvts_ctrl_connect(struct devi
 
 static int lvts_ctrl_initialize(struct device *dev, struct lvts_ctrl *lvts_ctrl)
 {
-	lvts_write_config(lvts_ctrl, default_init_cmds, ARRAY_SIZE(default_init_cmds));
+	const struct lvts_data *lvts_data = lvts_ctrl->lvts_data;
+
+	lvts_write_config(lvts_ctrl, lvts_data->init_cmd, lvts_data->num_init_cmd);
 
 	return 0;
 }
@@ -1446,6 +1442,17 @@ static int lvts_resume(struct device *de
 	return 0;
 }
 
+static const u32 default_conn_cmds[] = { 0xC103FFFF, 0xC502FF55 };
+/*
+ * Write device mask: 0xC1030000
+ */
+static const u32 default_init_cmds[] = {
+	0xC1030E01, 0xC1030CFC, 0xC1030A8C, 0xC103098D, 0xC10308F1,
+	0xC10307A6, 0xC10306B8, 0xC1030500, 0xC1030420, 0xC1030300,
+	0xC1030030, 0xC10300F6, 0xC1030050, 0xC1030060, 0xC10300AC,
+	0xC10300FC, 0xC103009D, 0xC10300F1, 0xC10300E1
+};
+
 /*
  * The MT8186 calibration data is stored as packed 3-byte little-endian
  * values using a weird layout that makes sense only when viewed as a 32-bit
@@ -1740,7 +1747,11 @@ static const struct lvts_ctrl_data mt819
 
 static const struct lvts_data mt7988_lvts_ap_data = {
 	.lvts_ctrl	= mt7988_lvts_ap_data_ctrl,
+	.conn_cmd	= default_conn_cmds,
+	.init_cmd	= default_init_cmds,
 	.num_lvts_ctrl	= ARRAY_SIZE(mt7988_lvts_ap_data_ctrl),
+	.num_conn_cmd	= ARRAY_SIZE(default_conn_cmds),
+	.num_init_cmd	= ARRAY_SIZE(default_init_cmds),
 	.temp_factor	= LVTS_COEFF_A_MT7988,
 	.temp_offset	= LVTS_COEFF_B_MT7988,
 	.gt_calib_bit_offset = 24,
@@ -1748,7 +1759,11 @@ static const struct lvts_data mt7988_lvt
 
 static const struct lvts_data mt8186_lvts_data = {
 	.lvts_ctrl	= mt8186_lvts_data_ctrl,
+	.conn_cmd	= default_conn_cmds,
+	.init_cmd	= default_init_cmds,
 	.num_lvts_ctrl	= ARRAY_SIZE(mt8186_lvts_data_ctrl),
+	.num_conn_cmd	= ARRAY_SIZE(default_conn_cmds),
+	.num_init_cmd	= ARRAY_SIZE(default_init_cmds),
 	.temp_factor	= LVTS_COEFF_A_MT7988,
 	.temp_offset	= LVTS_COEFF_B_MT7988,
 	.gt_calib_bit_offset = 24,
@@ -1757,7 +1772,11 @@ static const struct lvts_data mt8186_lvt
 
 static const struct lvts_data mt8188_lvts_mcu_data = {
 	.lvts_ctrl	= mt8188_lvts_mcu_data_ctrl,
+	.conn_cmd	= default_conn_cmds,
+	.init_cmd	= default_init_cmds,
 	.num_lvts_ctrl	= ARRAY_SIZE(mt8188_lvts_mcu_data_ctrl),
+	.num_conn_cmd	= ARRAY_SIZE(default_conn_cmds),
+	.num_init_cmd	= ARRAY_SIZE(default_init_cmds),
 	.temp_factor	= LVTS_COEFF_A_MT8195,
 	.temp_offset	= LVTS_COEFF_B_MT8195,
 	.gt_calib_bit_offset = 20,
@@ -1766,7 +1785,11 @@ static const struct lvts_data mt8188_lvt
 
 static const struct lvts_data mt8188_lvts_ap_data = {
 	.lvts_ctrl	= mt8188_lvts_ap_data_ctrl,
+	.conn_cmd	= default_conn_cmds,
+	.init_cmd	= default_init_cmds,
 	.num_lvts_ctrl	= ARRAY_SIZE(mt8188_lvts_ap_data_ctrl),
+	.num_conn_cmd	= ARRAY_SIZE(default_conn_cmds),
+	.num_init_cmd	= ARRAY_SIZE(default_init_cmds),
 	.temp_factor	= LVTS_COEFF_A_MT8195,
 	.temp_offset	= LVTS_COEFF_B_MT8195,
 	.gt_calib_bit_offset = 20,
@@ -1775,7 +1798,11 @@ static const struct lvts_data mt8188_lvt
 
 static const struct lvts_data mt8192_lvts_mcu_data = {
 	.lvts_ctrl	= mt8192_lvts_mcu_data_ctrl,
+	.conn_cmd	= default_conn_cmds,
+	.init_cmd	= default_init_cmds,
 	.num_lvts_ctrl	= ARRAY_SIZE(mt8192_lvts_mcu_data_ctrl),
+	.num_conn_cmd	= ARRAY_SIZE(default_conn_cmds),
+	.num_init_cmd	= ARRAY_SIZE(default_init_cmds),
 	.temp_factor	= LVTS_COEFF_A_MT8195,
 	.temp_offset	= LVTS_COEFF_B_MT8195,
 	.gt_calib_bit_offset = 24,
@@ -1784,7 +1811,11 @@ static const struct lvts_data mt8192_lvt
 
 static const struct lvts_data mt8192_lvts_ap_data = {
 	.lvts_ctrl	= mt8192_lvts_ap_data_ctrl,
+	.conn_cmd	= default_conn_cmds,
+	.init_cmd	= default_init_cmds,
 	.num_lvts_ctrl	= ARRAY_SIZE(mt8192_lvts_ap_data_ctrl),
+	.num_conn_cmd	= ARRAY_SIZE(default_conn_cmds),
+	.num_init_cmd	= ARRAY_SIZE(default_init_cmds),
 	.temp_factor	= LVTS_COEFF_A_MT8195,
 	.temp_offset	= LVTS_COEFF_B_MT8195,
 	.gt_calib_bit_offset = 24,
@@ -1793,7 +1824,11 @@ static const struct lvts_data mt8192_lvt
 
 static const struct lvts_data mt8195_lvts_mcu_data = {
 	.lvts_ctrl	= mt8195_lvts_mcu_data_ctrl,
+	.conn_cmd	= default_conn_cmds,
+	.init_cmd	= default_init_cmds,
 	.num_lvts_ctrl	= ARRAY_SIZE(mt8195_lvts_mcu_data_ctrl),
+	.num_conn_cmd	= ARRAY_SIZE(default_conn_cmds),
+	.num_init_cmd	= ARRAY_SIZE(default_init_cmds),
 	.temp_factor	= LVTS_COEFF_A_MT8195,
 	.temp_offset	= LVTS_COEFF_B_MT8195,
 	.gt_calib_bit_offset = 24,
@@ -1802,7 +1837,11 @@ static const struct lvts_data mt8195_lvt
 
 static const struct lvts_data mt8195_lvts_ap_data = {
 	.lvts_ctrl	= mt8195_lvts_ap_data_ctrl,
+	.conn_cmd	= default_conn_cmds,
+	.init_cmd	= default_init_cmds,
 	.num_lvts_ctrl	= ARRAY_SIZE(mt8195_lvts_ap_data_ctrl),
+	.num_conn_cmd	= ARRAY_SIZE(default_conn_cmds),
+	.num_init_cmd	= ARRAY_SIZE(default_init_cmds),
 	.temp_factor	= LVTS_COEFF_A_MT8195,
 	.temp_offset	= LVTS_COEFF_B_MT8195,
 	.gt_calib_bit_offset = 24,
author maintainer
#147 lore raw

PATCH 142/142 thermal/drivers/mediatek/lvts_thermal: Add mt7988 lvts commands

In reply to Greg Kroah-Hartman

6.16-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mason Chang <[email protected]>

commit 685a755089f95b7e205c0202567d9a647f9de096 upstream.

These commands are necessary to avoid severely abnormal and inaccurate temperature readings that are caused by using the default commands.

---
 drivers/thermal/mediatek/lvts_thermal.c |   16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)
drivers/thermal/mediatek/lvts_thermal.c +12 -4
@@ -1443,6 +1443,8 @@ static int lvts_resume(struct device *de
 }
 
 static const u32 default_conn_cmds[] = { 0xC103FFFF, 0xC502FF55 };
+static const u32 mt7988_conn_cmds[] = { 0xC103FFFF, 0xC502FC55 };
+
 /*
  * Write device mask: 0xC1030000
  */
@@ -1453,6 +1455,12 @@ static const u32 default_init_cmds[] = {
 	0xC10300FC, 0xC103009D, 0xC10300F1, 0xC10300E1
 };
 
+static const u32 mt7988_init_cmds[] = {
+	0xC1030300, 0xC1030420, 0xC1030500, 0xC10307A6, 0xC1030CFC,
+	0xC1030A8C, 0xC103098D, 0xC10308F1, 0xC1030B04, 0xC1030E01,
+	0xC10306B8
+};
+
 /*
  * The MT8186 calibration data is stored as packed 3-byte little-endian
  * values using a weird layout that makes sense only when viewed as a 32-bit
@@ -1747,11 +1755,11 @@ static const struct lvts_ctrl_data mt819
 
 static const struct lvts_data mt7988_lvts_ap_data = {
 	.lvts_ctrl	= mt7988_lvts_ap_data_ctrl,
-	.conn_cmd	= default_conn_cmds,
-	.init_cmd	= default_init_cmds,
+	.conn_cmd	= mt7988_conn_cmds,
+	.init_cmd	= mt7988_init_cmds,
 	.num_lvts_ctrl	= ARRAY_SIZE(mt7988_lvts_ap_data_ctrl),
-	.num_conn_cmd	= ARRAY_SIZE(default_conn_cmds),
-	.num_init_cmd	= ARRAY_SIZE(default_init_cmds),
+	.num_conn_cmd	= ARRAY_SIZE(mt7988_conn_cmds),
+	.num_init_cmd	= ARRAY_SIZE(mt7988_init_cmds),
 	.temp_factor	= LVTS_COEFF_A_MT7988,
 	.temp_offset	= LVTS_COEFF_B_MT7988,
 	.gt_calib_bit_offset = 24,
Tested-by on the v1 series
#148 lore raw
In reply to Greg Kroah-Hartman
Quoted 4 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.16.5 release. There are 142 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.

Hi Greg

6.16.5-rc1 compiles on x86_64 (Xeon E5-1620 v2, Slackware64-15.0), and boots & runs on x86_64 (AMD Ryzen 5 7520U, Slackware64-current).

No regressions observed, apart from the one already mentioned for 6.16.2-rc1.
Thus I tested 6.16.5-rc1 with V3 of the patch and it seems to work ok:
https://lore.kernel.org/stable/[email protected]/

Tested-by on the v1 series
#150 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.16.5 release. There are 142 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 Thu, 04 Sep 2025 13:19:14 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
	https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.16.5-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-6.16.y
and the diffstat can be found below.

thanks,

greg k-h

Tested rc1 against the Fedora build system (aarch64, ppc64le, s390x, x86_64), and boot tested x86_64. No regressions noted.

maintainer Tested-by on the v1 series
#152 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.16.5 release. There are 142 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 Thu, 04 Sep 2025 13:19:14 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
	https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.16.5-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-6.16.y
and the diffstat can be found below.

thanks,

greg k-h

All tests passing for Tegra ...

Test results for stable-v6.16:

    10 builds:	10 pass, 0 fail
    28 boots:	28 pass, 0 fail
    120 tests:	120 pass, 0 fail

Linux version: 6.16.5-rc1-g6a02da415966
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,

                tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000,
                tegra194-p3509-0000+p3668-0000, tegra20-ventana,
                tegra210-p2371-2180, tegra210-p3450-0000,
                tegra30-cardhu-a04

Jon

Tested-by on the v1 series
#153 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.16.5 release. There are 142 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 Thu, 04 Sep 2025 13:19:14 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
	https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.16.5-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-6.16.y
and the diffstat can be found below.

thanks,

greg k-h

Thanks! Builds on all Alpine architectures & boots on x86_64.

Tested-by on the v1 series
#154 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.16.5 release. There are 142 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 Thu, 04 Sep 2025 13:19:14 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
	https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.16.5-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-6.16.y
and the diffstat can be found below.

thanks,

greg k-h

On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:

Signature · 1 line
Florian
Tested-by on the v1 series
#155 lore raw
In reply to Greg Kroah-Hartman

Hi Greg

Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.16.5 release. There are 142 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 Thu, 04 Sep 2025 13:19:14 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
        https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.16.5-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-6.16.y
and the diffstat can be found below.

thanks,

greg k-h

6.16.5-rc1 tested.

Build successfully completed.
Boot successfully completed.
No dmesg regressions.
Video output normal.
Sound output normal.

Lenovo ThinkPad X1 Carbon Gen10(Intel i7-1260P(x86_64) arch linux)

[    0.000000] Linux version 6.16.5-rc1rv-g6a02da415966

(takeshi@ThinkPadX1Gen10J0764) (gcc (GCC) 15.2.1 20250813, GNU ld (GNU Binutils) 2.45.0) #1 SMP PREEMPT_DYNAMIC Wed Sep 3 06:18:52 JST 2025

Thanks

Tested-by Linux Kernel Functional Testing on the v1 series
#156 lore raw
In reply to Greg Kroah-Hartman
Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.16.5 release. There are 142 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 Thu, 04 Sep 2025 13:19:14 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
        https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.16.5-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-6.16.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.

## Build
* kernel: 6.16.5-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git commit: 6a02da415966f62533bff14bd579f6866076597d
* git describe: v6.16.4-143-g6a02da415966
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.16.y/build/v6.16.4-143-g6a02da415966

## Test Regressions (compared to v6.16.3-458-g2894c4c9dabd)

## Metric Regressions (compared to v6.16.3-458-g2894c4c9dabd)

## Test Fixes (compared to v6.16.3-458-g2894c4c9dabd)

## Metric Fixes (compared to v6.16.3-458-g2894c4c9dabd)

## Test result summary
total: 350240, pass: 322942, fail: 6798, skip: 20500, xfail: 0

## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 139 total, 138 passed, 1 failed
* arm64: 57 total, 56 passed, 1 failed
* i386: 18 total, 18 passed, 0 failed
* mips: 34 total, 27 passed, 7 failed
* parisc: 4 total, 4 passed, 0 failed
* powerpc: 40 total, 39 passed, 1 failed
* riscv: 25 total, 24 passed, 1 failed
* s390: 22 total, 22 passed, 0 failed
* sh: 5 total, 5 passed, 0 failed
* sparc: 4 total, 3 passed, 1 failed
* x86_64: 49 total, 48 passed, 1 failed

## Test suites summary
* boot
* commands
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-exec
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-kcmp
* kselftest-kvm
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-mincore
* kselftest-mm
* kselftest-mqueue
* kselftest-net
* kselftest-net-mptcp
* kselftest-openat2
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-rust
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-tc-testing
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user_events
* kselftest-vDSO
* kselftest-x86
* kunit
* kvm-unit-tests
* lava
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-build-clang
* log-parser-build-gcc
* log-parser-test
* ltp-capability
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* modules
* perf
* rcutorture
* rt-tests-cyclicdeadline
* rt-tests-pi-stress
* rt-tests-pmqtest
* rt-tests-rt-migrate-test
* rt-tests-signaltest

--
Linaro LKFT
https://lkft.linaro.org

Tested-by on the v1 series
#157 lore raw
In reply to Greg Kroah-Hartman

Hi!

Quoted 4 lines

This is the start of the stable review cycle for the 6.16.5 release. There are 142 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.

CIP testing did not find any problems here:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6.16.y

5.15, 5.4, 6.6, 6.15, pass our testing, too:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6.15.y
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6.6.y
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.15.y
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.4.y

Best regards,
Pavel

Signature · 2 lines
In cooperation with DENX Software Engineering GmbH, HRB 165235 Munich,
Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Tested-by on the v1 series
#158 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.16.5 release. There are 142 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 Thu, 04 Sep 2025 13:19:14 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
	https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.16.5-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-6.16.y
and the diffstat can be found below.

thanks,

greg k-h

Built and booted successfully on RISC-V RV64 (HiFive Unmatched).

Tested-by on the v1 series
#160 lore raw
In reply to Greg Kroah-Hartman

Am 02.09.2025 um 15:18 schrieb Greg Kroah-Hartman:

Quoted 4 lines

This is the start of the stable review cycle for the 6.16.5 release. There are 142 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.

Builds, boots and works on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. No dmesg oddities or regressions found.

Beste Grüße,
Peter Schneider

Signature · 8 lines
Climb the mountain not to plant your flag, but to embrace the challenge,
enjoy the air and behold the view. Climb it so you can see the world,
not so the world can see you.                    -- David McCullough Jr.

OpenPGP:  0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244
Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc
https://keys.mailvelope.com/pks/lookup?op=get&[email protected]
https://keys.mailvelope.com/pks/lookup?op=get&[email protected]