On Mon, 2017-03-20 at 10:24 +0000, Will Deacon wrote: > > Just to be clear here: I'm not against exposing the proc interface if > something actually needs it, but all the requests we've had for this have > been concerned only with the sysfs API. So I'd rather start with just that, > instead of exposing both and have new software written to the proc interface, > which we certainly want to discourage. The point is that they are tied together. An architecture provides its pci_mmap_page_range() function and sets HAVE_PCI_MMAP, and then the *generic* code in drivers/pci will use it from both places. Although as noted, there is a third userspace API in drivers/vfio which does this *without* any arch-specific code (using pgprot_noncached(), and failing to set up the VMA correctly on HAVE_IOREMAP_PROT platforms. I was looking at cleaning that whole mess up, but got distracted by kdump-on-CPU-1 failures. If I'm going to blame that on firmware, I'll get back to PCI mmap this week... :)
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
