Neophyte questions about PCIe
Mason
slash.tmp at free.fr
Tue Mar 14 05:05:36 PDT 2017
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.
More information about the linux-arm-kernel
mailing list