>And if there really is not way to provide this, the right way is just >to stop the runtime allocation that triggered you to do this if >ZONE_DMA32 is empty, not to add a non-portable option. I think there's 2 different arrangements: 1) CONFIG_ZONE_DMA32=Y means ZONE_DMA32 exists but empty. Currently this is a bug. dma_atomic_pool_init() will fail. 2) CONFIG_ZONE_DMA32=N means ZONE_DMA32 does not exists In this case any code that rely on DMA32 should fail to compile, and this is an intention. Such system can't have drivers that can't work without DMA32 memory I understand your suggestion is to go for the option 1, not allocate atomic_pool_dma32 and later fail all allocations with GFP_DMA32 if requested by the code. This may be valid option but I don't have a vision how to do it properly. Instead I want realize option 2. SOC I am working on is not a general purpose system, it is an automotive SOC that will run very restricted software. It is designed for purpose without support for the 32-bit devices. I want to avoid any code that assumes DMA32 as this is just not valid on my SOC so I deliberately need to break all such code.
