On 22 March 2025 03:24:50 CET, Manivannan Sadhasivam <manivannan.sadhasivam@xxxxxxxxxx> wrote: >On Fri, Mar 21, 2025 at 02:27:34PM +0100, Niklas Cassel wrote: >> >> I'm really (honestly) happy with whatever solution, as long as we, once again, >> handle EPCs that only support INTx, or only support MSI-X. >> > >We will keep your old series as it is. > >> (Because ever since your patch series that migrated pcitest to selftests, >> READ_TEST / WRITE_TEST / COPY_TEST test cases unconditionally use MSI, which >> is a regression for EPCs that only support INTx, or only support MSI-X, >> which is the whole reason why I wrote this series.) >> > >IMO, the regression could be simply fixed if you have removed the ASSERT_EQ from >READ/WRITE/COPY testcases. > >But anyway, all good now. Thanks a lot for your patience in educating me :) >Really appreciated. Don't say it like that :) I understand where you were coming from. I think if we designed the API today, we would have kept it as one ioctl, and user space could have provided the IRQ type (and/or auto) as a struct member in the struct supplied in the ioctl. But, considering that we already have PCITEST_SET_IRQTYPE as a separate ioctl, I think what is currently queued fits the current design the best, even if it is not a "real" IRQ type. I still need to send a patch that fixes the kdoc. BTW, can all Qcom platform raise INTx interrupts in EP mode? Bjorn did not like that I added intx_capable to epc_features without having any platform that sets it to true. I'm quite sure that many platforms can raise INTx interrupts. If all Qcom platforms can raise INTx interrupts, then I could set intx_capable to true in epc_features in qcom-ep.c, to address Bjorns comment. Kind regards, Niklas
