On 13/05/2026 15:12, Felix Kuehling wrote:
fpfn and lpfn in struct ttm_place are 32-bit page numbers. With 4KB page
size this can support up to 44-bit physical addressing. Grow these to
unsigned long to support larger physical addresses.
Signed-off-by: Felix Kuehling <[email protected]>
---
include/drm/ttm/ttm_placement.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/drm/ttm/ttm_placement.h b/include/drm/ttm/ttm_placement.h
index b510a4812609..ab2639e42c54 100644
--- a/include/drm/ttm/ttm_placement.h
+++ b/include/drm/ttm/ttm_placement.h
@@ -81,8 +81,8 @@
* Structure indicating a possible place to put an object.
*/
struct ttm_place {
- unsigned fpfn;
- unsigned lpfn;
+ uint64_t fpfn;
+ uint64_t lpfn;
uint32_t mem_type;
uint32_t flags;
};
Maybe audit of usage sites is required to make sure no compiler warnings
on 32-bit builds if nothing else. Things like:
amdgpu_vram_mgr_intersects()
...
if (place->fpfn < lpfn &&
(!place->lpfn || place->lpfn > fpfn))
return true;
Etc. Probably are all best adjusted to match the new type.
There is also:
struct ttm_resource {
unsigned long start;
Which also may need aligning. I know no one cares about 32-bit builds
but some automated systems will probably test it and send reports.
Regards,
Tvrtko
