Re: [PATCH 3/4] misc: pci_endpoint_test: Let PCITEST_{READ,WRITE,COPY} set IRQ type automatically

[Bjorn Helgaas <helgaas@kernel.org>]

On Wed, Mar 26, 2025 at 08:22:08PM +0100, Niklas Cassel wrote:
> On Wed, Mar 26, 2025 at 09:47:18PM +0530, Manivannan Sadhasivam wrote:
> > On Wed, Mar 26, 2025 at 10:39:50AM -0400, Niklas Cassel wrote:
> > > 
> > > Can all Qcom platforms raise INTx in EP mode?
> > 
> > Yes, all Qcom platforms support INTx. But if we start setting the
> > flag to true, there is no need to set it to false as that would be
> > the default value. So let's just set 'true' for INTx capable
> > platforms and assume others as not supported. I know that you had
> > added justification in the commit message, but I think we'd have
> > to drop the below commit:
> > 
> > PCI: dw-rockchip: Endpoint mode cannot raise INTx interrupts
> 
> Well, with that logic, we should also remove the following:
> 
> $ git grep "msi_capable = false"
> drivers/pci/controller/dwc/pcie-tegra194.c:     .msi_capable = false,
> 
> $ git grep "msix_capable = false"
> drivers/pci/controller/dwc/pci-dra7xx.c:        .msix_capable = false,
> drivers/pci/controller/dwc/pci-imx6.c:  .msix_capable = false,
> drivers/pci/controller/dwc/pci-imx6.c:  .msix_capable = false,
> drivers/pci/controller/dwc/pcie-artpec6.c:      .msix_capable = false,
> drivers/pci/controller/dwc/pcie-qcom-ep.c:      .msix_capable = false,
> drivers/pci/controller/dwc/pcie-rcar-gen4.c:    .msix_capable = false,
> drivers/pci/controller/dwc/pcie-tegra194.c:     .msix_capable = false,
> drivers/pci/controller/dwc/pcie-uniphier-ep.c:          .msix_capable = false,
> drivers/pci/controller/dwc/pcie-uniphier-ep.c:          .msix_capable = false,
> drivers/pci/controller/pcie-rcar-ep.c:  .msix_capable = false,
> drivers/pci/controller/pcie-rockchip-ep.c:      .msix_capable = false,
> 
> Feel free to send patches that removes all:
> {msi_capable,msix_capable,intx_capable}=false;
> 
> I will be happy to help out with reviews.
> 
> However, I'm slightly leaning towards thinking that there actually is some
> value in _explicitly_ seeing that something is not supported.

IMO, this value is pretty weak.  I think we should only mention
features that *are* supported.  The universe of possibly supported
features is unbounded.  Suppose new hardware adds a new feature X.
Obviously we have to mark hardware that supports X.  But I do not want
to go back and mark all the old hardware as "not supporting X".

Bjorn