Re: [PATCH] drm/radeon: allocate dummy_page without DMA32 on fail

[Anirudh Srinivasan]

Hi Christian,

On Wed, Jul 15, 2026 at 4:15 AM Christian König
<christian.koenig@xxxxxxx> wrote:
>
> On 7/14/26 18:03, Anirudh Srinivasan wrote:
> > radeon fails to probe on platforms that have all their memory above the
> > 32-bit range with an -ENOMEM because dummy_page_init calls
> > alloc_page(GFP_DMA32), which would fail.
>
> Unfortunately I clearly have to reject this.
>
> The DMA32 allocation is mandatory for radeon to work correctly on some platforms.
>
> > Allow this driver to work on such platforms by falling back to
> > ZONE_NORMAL regions. dma_map_page called subsequently would catch any
> > issues with the device being unable to DMA into the mapped page.
>
> No, it doesn't.
>
> It's just your special case that dma_map_page() is able to use some IOMMU to remap the page below 32bits so that the driver can access it.
>
> The problem is that we have quite a bunch of cases where this doesn't work correctly and eventually result in all kinds of trouble, including random memory corruptions.
>
> In those cases it's better to not load the driver at all than to later deal with corrupted data.

So this platform has an IOMMU, but it isn't enabled in the upstream
kernel at the moment. I am able to boot up to framebuffer console. Is
there anything that isn't expected to work in this setup? Is there
some test I can run to verify this?

I should look into whether the IOMMU on this cihp can be enabled and
then try this out too.

>
> What could be possible is to add a special quirk for your platform to not allocate the dummy page as DMA32 in the first place.

So some kind of a whitelisted set of PCIE vendor/ID combos (with
working IOMMUS?) where we fallback to non DMA32 ranges?

Regards
Anirudh Srinivasan