On Thu, Aug 14, 2025 at 10:37:22AM -0700, Randy Dunlap wrote: > Hi Leon, > > On 8/14/25 3:13 AM, Leon Romanovsky wrote: > > diff --git a/Documentation/core-api/dma-attributes.rst > > b/Documentation/core-api/dma-attributes.rst > > index 1887d92e8e92..58a1528a9bb9 100644 > > --- a/Documentation/core-api/dma-attributes.rst > > +++ b/Documentation/core-api/dma-attributes.rst > > @@ -130,3 +130,21 @@ accesses to DMA buffers in both privileged > > "supervisor" and unprivileged > > subsystem that the buffer is fully accessible at the elevated privilege > > level (and ideally inaccessible or at least read-only at the > > lesser-privileged levels). > > + > > +DMA_ATTR_MMIO > > +------------- > > + > > +This attribute indicates the physical address is not normal system > > +memory. It may not be used with kmap*()/phys_to_virt()/phys_to_page() > > +functions, it may not be cachable, and access using CPU load/store > > Usually "cacheable" (git grep -w cacheable counts 1042 hits vs. > 55 hits for "cachable"). And the $internet agrees. > > > +instructions may not be allowed. > > + > > +Usually this will be used to describe MMIO addresses, or other non > > non-cacheable > > > +cachable register addresses. When DMA mapping this sort of address we > > > +call the operation Peer to Peer as a one device is DMA'ing to another > > +device. For PCI devices the p2pdma APIs must be used to determine if > > +DMA_ATTR_MMIO is appropriate. > > + > > +For architectures that require cache flushing for DMA coherence > > +DMA_ATTR_MMIO will not perform any cache flushing. The address > > +provided must never be mapped cachable into the CPU. > again.
Thanks, I will fix. > > thanks. > -- > ~Randy > >
