On 14/03/2017 11:23, David Laight wrote: > Mason wrote: > >> I'd like to push support for this PCIe controller upstream. >> >> Is the code I posted on the right track? >> Maybe I can post a RFC patch tomorrow? > > I think you need to resolve the problem of config space (and IO) cycles > before the driver can be deemed usable. You're alluding to the (unfortunate) muxing of config and mem spaces on my controller, where concurrent accesses by two different threads would blow the system up. You've suggested sending IPIs in the config space accessor, in order to prevent other CPUs from starting a mem access. But this doesn't help if a mem access is already in flight, AFAIU. I fear there is nothing that can be done in SW, short of rewriting drivers such that mem space accesses are handled by a driver-specific call-back which could take care of all required locking. AFAICT, my only (reasonable) option is putting a big fat warning in the code, and pray that concurrent accesses never happen. (I'll test with a storage stress test on a USB3 drive.) In parallel, I'm trying to convince management that the HW needs fixing ASAP. Regards. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
