On 5/13/26 16:50, Tvrtko Ursulin wrote: > 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.
Yeah I have been trying to remove ttm_resource.start exactly for that reason for a very very long time now. Drivers shouldn't use that and instead rely on their own backends to give the actual placement. Regards, Christian. > > Regards, > > Tvrtko >
