| Message ID | 20250402091628.4041790-2-cassel@kernel.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | PCI: qcom-ep: Set intx_capable in epc_features | expand |
On Wed, Apr 02, 2025 at 11:16:28AM +0200, Niklas Cassel wrote: > While I do not have the technical reference manuals, the qcom-ep > maintainer assures me that all compatibles support generating INTx IRQs. > > Thus, set intx_capable to true in epc_features. > > This will currently not have any effect, as PCITEST_IRQ_TYPE_AUTO will > always prefer MSI over INTx when both are available, however, perhaps the > supported irq_types in epc_features will be used for something else, e.g. > failing a ioctl(PCITEST_SET_IRQTYPE) with PCITEST_IRQ_TYPE_INTX, on the > host side, before ever configuring anything on the EP side. Thus, ensure > that epc_features represents reality. > > Signed-off-by: Niklas Cassel <cassel@kernel.org> > --- > drivers/pci/controller/dwc/pcie-qcom-ep.c | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
On Wed, Apr 02, 2025 at 11:16:28AM +0200, Niklas Cassel wrote: > While I do not have the technical reference manuals, the qcom-ep > maintainer assures me that all compatibles support generating INTx IRQs. > Yes, all Qcom EP controllers do support INTx. > Thus, set intx_capable to true in epc_features. > Hmm, this, I do not want to do atm. Qcom endpoints cannot raise INTx due to lack of the driver support. So setting this flag would imply that the INTx is functionally supported by the endpoint, but it is not. Atleast, 'pci_epc_features' is not a devicetree configuration, that it has to match what the hw supports instead of the driver support availability :) - Mani
On 2 April 2025 18:34:28 CEST, Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> wrote: >On Wed, Apr 02, 2025 at 11:16:28AM +0200, Niklas Cassel wrote: >> While I do not have the technical reference manuals, the qcom-ep >> maintainer assures me that all compatibles support generating INTx IRQs. >> > >Yes, all Qcom EP controllers do support INTx. > >> Thus, set intx_capable to true in epc_features. >> > >Hmm, this, I do not want to do atm. Qcom endpoints cannot raise INTx due to lack >of the driver support. So setting this flag would imply that the INTx is >functionally supported by the endpoint, but it is not. > >Atleast, 'pci_epc_features' is not a devicetree configuration, that it has to >match what the hw supports instead of the driver support availability :) Ok, I misunderstood then. Let's just drop this patch. Kind regards, Niklas
diff --git a/drivers/pci/controller/dwc/pcie-qcom-ep.c b/drivers/pci/controller/dwc/pcie-qcom-ep.c index 46b1c6d19974..25468025e945 100644 --- a/drivers/pci/controller/dwc/pcie-qcom-ep.c +++ b/drivers/pci/controller/dwc/pcie-qcom-ep.c @@ -824,6 +824,7 @@ static const struct pci_epc_features qcom_pcie_epc_features = { .linkup_notifier = true, .msi_capable = true, .msix_capable = false, + .intx_capable = true, .align = SZ_4K, .bar[BAR_0] = { .only_64bit = true, }, .bar[BAR_1] = { .type = BAR_RESERVED, },
While I do not have the technical reference manuals, the qcom-ep maintainer assures me that all compatibles support generating INTx IRQs. Thus, set intx_capable to true in epc_features. This will currently not have any effect, as PCITEST_IRQ_TYPE_AUTO will always prefer MSI over INTx when both are available, however, perhaps the supported irq_types in epc_features will be used for something else, e.g. failing a ioctl(PCITEST_SET_IRQTYPE) with PCITEST_IRQ_TYPE_INTX, on the host side, before ever configuring anything on the EP side. Thus, ensure that epc_features represents reality. Signed-off-by: Niklas Cassel <cassel@kernel.org> --- drivers/pci/controller/dwc/pcie-qcom-ep.c | 1 + 1 file changed, 1 insertion(+)