From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/ttm: Support 52-bit PAs in ttm_place Date: Sat, 16 May 2026 12:38:59 +1000 Message-ID: In-Reply-To: <20260512223154.18089-1-felix.kuehling@amd.com> References: <20260512223154.18089-1-felix.kuehling@amd.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Overall Series Review Subject: drm/ttm: Support 52-bit PAs in ttm_place Author: Felix Kuehling Patches: 4 Reviewed: 2026-05-16T12:38:59.764368 --- This is a single patch that widens `fpfn` and `lpfn` in `struct ttm_place` = from `unsigned` (32-bit) to `unsigned long` to support physical addresses b= eyond 44 bits (32-bit page numbers =C3=97 4KB pages). The motivation is sou= nd =E2=80=94 32-bit page frame numbers limit addressing to 16 TiB, which is= increasingly insufficient. However, **this patch is already superseded by work in drm-next**. The curr= ent drm-next tree already has these fields as `uint64_t`: ```c struct ttm_place { uint64_t fpfn; uint64_t lpfn; uint32_t mem_type; uint32_t flags; }; ``` The `uint64_t` approach in drm-next is **strictly better** than the `unsign= ed long` proposed here, because `unsigned long` is only 32-bit on 32-bit pl= atforms, providing no improvement there, while `uint64_t` is unconditionall= y 64-bit. **Recommendation: NAK =E2=80=94 this change has already landed in drm-next = with a superior type choice (`uint64_t` vs `unsigned long`).** --- --- Generated by Claude Code Patch Reviewer