The linux-next integration testing tree https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/atom?h=master 2026-07-09T14:48:11+00:00 2026-07-09T14:48:11+00:00 Mark Brown broonie@kernel.org 2026-07-09T14:48:11+00:00 urn:sha1:d165c55426c02de04e07566128294e8fa3dfa083 2026-07-09T14:48:05+00:00 Mark Brown broonie@kernel.org 2026-07-09T14:48:05+00:00 urn:sha1:5939f4603d8c06431827d4e0501a22b26d5374a2 2026-07-09T12:02:50+00:00 Mark Brown broonie@kernel.org 2026-07-09T12:02:50+00:00 urn:sha1:44aaba7617dbea6a93aacf589f3e25ab243a94dc 2026-07-08T18:27:26+00:00 David Francis David.Francis@amd.com 2026-05-12T18:49:41+00:00 urn:sha1:5c6c247992d4d9200e073b83f4ec6c703c096845 The valid amdkfd event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT - 1. During CRIU restore, ensure that the provided event ids are in that range. v2: No need for lower bound check since idr_alloc rejects negative inputs v3: Also change error message to reflect new error condition Reviewed-by: David Yat Sin <david.yatsin@amd.com> Signed-off-by: David Francis <David.Francis@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2026-07-08T18:27:08+00:00 Zhu Lingshan lingshan.zhu@amd.com 2026-07-01T03:03:09+00:00 urn:sha1:325de6bf3328efd5acf5072337fc196928753de8 Current kfd debugfs interfaces only expose pasid of the primary process, this commit exposes pasid of secondary contexts by debugfs Just like entries under sysfs, the secondary contexts are named as context_<id> under its primary kfd process. The layout: /sys/kernel/debug/kfd/proc# tree . └── 5802 ├── context_0 │   ├── pasid_1025 │   └── pasid_63266 ├── context_1 │   ├── pasid_1025 │   └── pasid_63266 ├── pasid_1025 └── pasid_63266 Another fix is, kfd_debugfs_add_process may fail, this commit change it to return a meaningful value other than void Signed-off-by: Zhu Lingshan <lingshan.zhu@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2026-07-08T18:25:32+00:00 Yang Wang kevinyang.wang@amd.com 2026-07-06T01:29:24+00:00 urn:sha1:c936b8126b444401318fcbeb1828488cc5312dee SMU14 derives the default PPT limit from SocketPowerLimitAc/Dc, but MsgLimits.Power may expose a different firmware limit for the same PPT0 throttler. Using those values independently as fixed min/max bases can report an incorrect configurable power range. Keep the socket power limit as the default value and as the fallback for current-limit queries. Calculate the reported range from both firmware values instead, using the lower value as the minimum base and the higher value as the maximum base before applying OD percentages. Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2026-07-08T18:25:30+00:00 Alex Deucher alexander.deucher@amd.com 2026-06-15T23:14:01+00:00 urn:sha1:22b19c575e8e750ccee5d88b39c0ac2efc8c5870 There's no need to crash the kernel for this case. Reviewed-by: Kent Russell <kent.russell@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2026-07-08T18:25:27+00:00 Alex Deucher alexander.deucher@amd.com 2026-06-15T23:09:39+00:00 urn:sha1:af0e4c0eaf86b2b853ed12b994239cb21cebcda5 There's no need to crash the kernel for these cases. Reviewed-by: Kent Russell <kent.russell@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2026-07-08T18:25:25+00:00 Alex Deucher alexander.deucher@amd.com 2026-06-15T23:06:42+00:00 urn:sha1:9599e82b19a582ffa2d781a98a786a0d0822b041 There's no need to crash the kernel for this case. Reviewed-by: Kent Russell <kent.russell@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2026-07-08T18:25:23+00:00 Alex Deucher alexander.deucher@amd.com 2026-06-15T23:06:11+00:00 urn:sha1:8fe5f5e2da26e9e8f2ddd639c5caad9cf215108b There's no need to crash the kernel for this case. Reviewed-by: Kent Russell <kent.russell@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>