On Wed, Dec 23, 2020 at 09:01:33AM +0100, Jérôme Pouiller wrote: > On Tuesday 22 December 2020 16:27:01 CET Greg Kroah-Hartman wrote: > > On Tue, Dec 22, 2020 at 05:10:11PM +0200, Kalle Valo wrote: > > > Jerome Pouiller <Jerome.Pouiller@xxxxxxxxxx> writes: > > > > > > > +/* > > > > + * Internal helpers. > > > > + * > > > > + * About CONFIG_VMAP_STACK: > > > > + * When CONFIG_VMAP_STACK is enabled, it is not possible to run DMA on stack > > > > + * allocated data. Functions below that work with registers (aka functions > > > > + * ending with "32") automatically reallocate buffers with kmalloc. However, > > > > + * functions that work with arbitrary length buffers let's caller to handle > > > > + * memory location. In doubt, enable CONFIG_DEBUG_SG to detect badly located > > > > + * buffer. > > > > + */ > > > > > > This sounds very hacky to me, I have understood that you should never > > > use stack with DMA. > > > > You should never do that because some platforms do not support it, so no > > driver should ever try to do that as they do not know what platform they > > are running on. > > Just to be curious, why these platforms don't support DMA in a stack > allocated area? Hardware is odd :( > If the memory is contiguous (= not vmalloced), correctly > aligned and in the first 4GB of physical memory, it should be sufficient, > shouldn't? Nope, sorry, this just does not work at all on many platforms. thanks, greg k-h