Hi All, For a long time IIO has been making assumption that ____cacheline_aligned was sufficient to ensure buffers were in their own cacheline and hence DMA safe. We generally needed this for all SPI device drivers as many SPI ABI calls can pass the buffer directly through to be used for DMA. Not that regmap doesn't currently do this but it might in future (and did in the past). I can't remember the history of this well enough to know why we did it that way. I don't remember the pain of debugging random corruption caused by getting it wrong however... However it turns out via https://lore.kernel.org/all/20220405135758.774016-1-catalin.marinas@xxxxxxx/ "[PATCH 00/10] mm, arm64: Reduce ARCH_KMALLOC_MINALIGN below the cache line size" discussion that there are platforms where this isn't true and need 128 byte alignment despite a ____cacheline_size aligning to 64 bytes on all ARM64 platforms. (I should probably have known that as the platform I support in my day job has 128 byte cachelines in L3 - however it's DMA coherent so that's not a problem). The above series also highlights that we can do much better anyway on some platforms using the new ARCH_DMA_MINALIGN (currently it's only defined for some archs but after that patch everyone gets it). We should be safe to use that everywhere we currently force ___cachline_aligned and waste a little less space on padding which is always nice ;) Given we have no reports of a problem with 128 byte non DMA coherent platforms I don't propose to 'fix' this until we can make use of the new define in the above patch set. That is going to make a mess of backporting the fix however. I'm wishing we did what crypto has done and had a subsystem specific define for this but such is life. We will also want to be careful that we cover the rather odd sounding case of ARCH_DMA_MINALIGN < 8 given there are a few drivers that rely on >= 8 to ensure we can do aligned puts of 64 bit timestamps. I'm definitely open to opinions on how we handle this and wanted people to have this on their radar. +CC Catalin for info. If you can sneak the first patch in your series in for next cycle that would be great even if the rest takes a while longer. Thanks, Jonathan