14:55 <arnd> broonie: I was looking at the users of kmalloc(..., GFP_DMA), which is fairly rare throughout the kernel, and I noticed that it's somewhat inconsistent in SPI drivers. Are there any rules about whether an spi driver should use GFP_DMA on platforms where the SPI master cannot access all kernel memory through DMA?

14:58 <arnd> I see that on arm64, dma_map_* sets up swiotlb when ZONE_DMA/ZONE_DMA32 is smaller than the available memory, but on arm32 the swiotlb is set up with the lowmem limit even if that is larger than the DMA zone

15:08 <broonie> arnd: I don't think it's ever been consistent as long as I've maintained spi.

15:12 <broonie> It's basically just whatever works for the driver on the platforms it will be used on which isn't really an answer.

15:21 <arnd> ok, I see

15:32 <robmur01> FWIW a lot of that is likely to be better off being dma_alloc_pages() these days

15:35 <broonie> Assuming you know you want to DMA it at the time you're allocating the buffer which is a bunch more work sadly :/

15:38 <robmur01> and as for rockchip-sfc and possibly au1550's abuse of virt_to_phys(), I wish I hadn't looked... :(

15:40 <broonie> rockchip I guess probably should use dma_alloc_pages() since that's definitively for DMA.

15:42 <arnd> You also need to know which device is going to be the DMA master, and that is rather hard by definition. I would expect USB to have the same problem, but I don't see only one USB driver using GFP_DMA, and I haven't found any code in drivers/usb/ that does the generic bounce buffer handling

15:43 <arnd> robmur01: fwiw, this is the list of files that reference kmalloc(..., GFP_DMA) https://www.irccloud.com/pastebin/TFEjRp65/

15:44 <arnd> there are more files that use it with alloc_pages or dma_alloc_*, what I was trying to figure out here is whether we can avoid creating all the duplicate slab caches

15:47 <arnd> some drivers like drivers/net/wireless/broadcom/b43 have a weird restriction (30 bit addressing in this case) and work around that using GFP_DMA, but many others look like they do it by accident, either copying from bad code, or misunderstanding the purpose of GFP_DMA

15:57 <arnd> and there is a fairly short list of platforms that actually use a ZONE_DMA limit smaller than ZONE_NORMAL but not a matching SWIOTLB: x86-32, alpha, m68k, arm32-bcm2711, arm32-sa1100, arm32-realview, mips-jazz, mips-malta, mips-sni, and powerpc32-mac