Can someone please explain how the sharing of iATUs between cfg0 and mem accesses, and cfg1 and I/O accesses can operate safely with concurrent operations? I read in dw_pcie_[rd|wr]_other_conf() that the code invokes the dw_pcie_prog_viewport_XXXX() functions to reprogram the iATU entries. Both cfg0 and memory regions are mapped alternately by PCIE_ATU_REGION_INDEX0, and both cfg1 and I/O regions are mapped alternately by PCIE_ATU_REGION_INDEX1. I noted in the git log that a previously coded lock was deemed unnecessary and removed around config operations, but I haven't identified any logic that protects the possibility of a driver say performing a memory operation while another is issuing a config. It would seem to me that there's a small window of opportunity that the driver performing a memory operation could have its iATU entry pulled out from underneath it if concurrently another driver was performing a config operation. Is there something higher up the call stack, or scheduling-wise, that prevents this from occurring? thanks, LH -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
