On Sat, Aug 03, 2019 at 08:48:12AM +0200, Christoph Hellwig wrote: > On Fri, Aug 02, 2019 at 11:38:03AM +0100, Will Deacon wrote: > > > > So this boils down to a terminology mismatch. The Arm architecture doesn't > > have > > anything called "write combine", so in Linux we instead provide what the Arm > > architecture calls "Normal non-cacheable" memory for pgprot_writecombine(). > > Amongst other things, this memory type permits speculation, unaligned > > accesses > > and merging of writes. I found something in the architecture spec about > > non-cachable memory, but it's written in Armglish[1]. > > > > pgprot_noncached(), on the other hand, provides what the architecture calls > > Strongly Ordered or Device-nGnRnE memory. This is intended for mapping MMIO > > (i.e. PCI config space) and therefore forbids speculation, preserves access > > size, requires strict alignment and also forces write responses to come from > > the endpoint. > > > > I think the naming mismatch is historical, but on arm64 we wanted to use the > > same names as arm32 so that any drivers using these things directly would > > get > > the same behaviour. > > That all makes sense, but it totally needs a comment. I'll try to draft > one based on this. I've also looked at the arm32 code a bit more, and > it seems arm always (?) supported Normal non-cacheable attribute, but > Linux only optionally uses it for arm v6+ because of fears of drivers > missing barriers.
I think it was also to do with aliasing, but I don't recall all of the details. > The other really weird things is that in arm32 > pgprot_dmacoherent incudes the L_PTE_XN bit, which from my understanding > is the no-execture bit, but pgprot_writecombine does not. This seems to > not very unintentional. So minus that the whole DMA_ATTR_WRITE_COMBІNE > seems to be about flagging old arm specific drivers as having the proper > barriers in places and otherwise is a no-op. I think it only matters for Armv7 CPUs, but yes, we should probably be setting L_PTE_XN for both of these memory types. > Here is my tentative plan: > > - respin this patch with a small fix to handle the > DMA_ATTR_NON_CONSISTENT (as in ignore it unless actually supported), > but keep the name as-is to avoid churn. This should allow 5.3 > inclusion and backports > - remove DMA_ATTR_WRITE_COMBINE support from mips, probably also 5.3 > material. > - move all architectures but arm over to just define > pgprot_dmacoherent, including a comment with the above explanation > for arm64. That would be great, thanks. > - make DMA_ATTR_WRITE_COMBINE a no-op and schedule it for removal, > thus removing the last instances of arch_dma_mmap_pgprot All sounds good to me, although I suppose 32-bit Arm platforms without CONFIG_ARM_DMA_MEM_BUFFERABLE may run into issues if DMA_ATTR_WRITE_COMBINE disappears. Only one way to find out... Will _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu