On Mon, 2010-02-08 at 16:54 +0000, Russell King wrote: > On Mon, Feb 08, 2010 at 04:10:21PM +0000, Catalin Marinas wrote: > > The pio_data_direction could be dropped and use the DMA one. We could > > also use pio_kmap_read/pio_kmap_write or similar but we have to triple > > the number of functions, so I prefer the additional argument. > > Do we need to do anything for reading a buffer for PIO _out_ to the > device? My understanding is that this has never been a problem. Before outbound PIO, you need to flush all the aliases before sending. However, this should *already* be done in the block path, so for block I/O it should be unnecessary, yes. All we need to do on the TO_DEVICE case should be map and unmap the page if it's highmem. > The only problem I'm aware of is where PIO writes to the kernel > mapping of a lowmem pages; highmem pages need the data flushed out > of the temporary atomic kmap mapping anyway. Not quite. in the PIO FROM_DEVICE case, we've created a dirty kernel alias by reading the data from the device and writing it via the kernel mapping. We have to flush that alias whether it exists as a highmem mapping or as a simple offset mapping before userspace will see the data. The block API assumes the FROM_DEVICE transfer went straight from the device into main memory and didn't go via the kernel alias, so the block use case won't flush it. Additionally, for architectures that don't promise no movein on a flushed but untouched page (unlike parisc, which does), we might need to invalidate all the user aliases before passing the page back to kill any stale data that may have been speculated into the alias caches). James -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
