On Thu, 26 Jun 2025 09:09:34 +0200 Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> wrote: > On 26.06.2025 07:06, Petr Tesarik wrote: > > On Thu, 26 Jun 2025 08:49:17 +0700 > > Bagas Sanjaya <bagasdotme@xxxxxxxxx> wrote: > > > >> On Tue, Jun 24, 2025 at 03:39:22PM +0200, Petr Tesarik wrote: > >>> diff --git a/Documentation/core-api/dma-api.rst b/Documentation/core-api/dma-api.rst > >>> index cd432996949c..65132ec88104 100644 > >>> --- a/Documentation/core-api/dma-api.rst > >>> +++ b/Documentation/core-api/dma-api.rst > >>> @@ -210,18 +210,12 @@ DMA_BIDIRECTIONAL direction isn't known > >>> this API should be obtained from sources which guarantee it to be > >>> physically contiguous (like kmalloc). > >>> > >>> - Further, the DMA address of the memory must be within the dma_mask of > >>> - the device. To ensure that the memory allocated by kmalloc is within > >>> - the dma_mask, the driver may specify various platform-dependent flags > >>> - to restrict the DMA address range of the allocation (e.g., on x86, > >>> - GFP_DMA guarantees to be within the first 16MB of available DMA > >>> - addresses, as required by ISA devices). > >>> - > >>> - Note also that the above constraints on physical contiguity and > >>> - dma_mask may not apply if the platform has an IOMMU (a device which > >>> - maps an I/O DMA address to a physical memory address). However, to be > >>> - portable, device driver writers may *not* assume that such an IOMMU > >>> - exists. > >>> + Mapping may also fail if the memory is not within the DMA mask of the > >>> + device. However, this constraint does not apply if the platform has > >>> + an IOMMU (a device which maps an I/O DMA address to a physical memory > >>> + address), or the kernel is configured with SWIOTLB (bounce buffers). > >>> + It is reasonable to assume that at least one of these mechanisms > >>> + allows streaming DMA to any physical address. > > Now I realize this last sentence may be contentious... > > > > @Marek, @Robin Do you agree that device drivers should not be concerned > > about the physical address of a buffer passed to the streaming DMA API? > > > > I mean, are there any real-world systems with: > > * some RAM that is not DMA-addressable, > > * no IOMMU, > > * CONFIG_SWIOTLB is not set? > > > > FWIW if _I_ received a bug report that a device driver fails to submit > > I/O on such a system, I would politely explain the reporter that their > > kernel is misconfigured, and they should enable CONFIG_SWIOTLB. > > What about the systems with legacy 16/24bit ZONE_DMA (i.e. ISA bus)? > AFAIR they don't use SWIOTLB and probably they won't be able to use > streaming DMA API for all system RAM. ISA is probably dead, but yeah, there may still be some systems with LPC, which inherits the same addressing limitations. I haven't really tested, but I believe these systems should be able to enable SWIOTLB. Is there a specific reason they can't use SWIOTLB? But if there is doubt, I can probably test such configuration. Petr T
