Re: [PATCH v9 0/2] PCI: add enabe(disable)_device() hook for bridge

[Marc Zyngier <maz@kernel.org>]

On Tue, 14 Jan 2025 22:33:41 +0000,
Bjorn Helgaas <helgaas@kernel.org> wrote:
> 
> On Tue, Jan 14, 2025 at 03:37:07PM -0500, Frank Li wrote:
> > Some system's IOMMU stream(master) ID bits(such as 6bits) less than
> > pci_device_id (16bit). It needs add hardware configuration to enable
> > pci_device_id to stream ID convert.
> > 
> > https://lore.kernel.org/imx/20240622173849.GA1432357@bhelgaas/
> > This ways use pcie bus notifier (like apple pci controller), when new PCIe
> > device added, bus notifier will call register specific callback to handle
> > look up table (LUT) configuration.
> > 
> > https://lore.kernel.org/imx/20240429150842.GC1709920-robh@kernel.org/
> > which parse dt's 'msi-map' and 'iommu-map' property to static config LUT
> > table (qcom use this way). This way is rejected by DT maintainer Rob.
> > 
> > Above ways can resolve LUT take or stream id out of usage the problem. If
> > there are not enough stream id resource, not error return, EP hardware
> > still issue DMA to do transfer, which may transfer to wrong possition.
> > 
> > Add enable(disable)_device() hook for bridge can return error when not
> > enough resource, and PCI device can't enabled.
> > 
> > Basicallly this version can match Bjorn's requirement:
> > 1: simple, because it is rare that there are no LUT resource.
> > 2: EP driver probe failure when no LUT, but lspci can see such device.
> > 
> > [    2.164415] nvme nvme0: pci function 0000:01:00.0
> > [    2.169142] pci 0000:00:00.0: Error enabling bridge (-1), continuing
> > [    2.175654] nvme 0000:01:00.0: probe with driver nvme failed with error -12
> > 
> > > lspci
> > 0000:00:00.0 PCI bridge: Philips Semiconductors Device 0000
> > 0000:01:00.0 Non-Volatile memory controller: Micron Technology Inc 2100AI NVMe SSD [Nitro] (rev 03)
> > 
> > To: Bjorn Helgaas <bhelgaas@google.com>
> > To: Richard Zhu <hongxing.zhu@nxp.com>
> > To: Lucas Stach <l.stach@pengutronix.de>
> > To: Lorenzo Pieralisi <lpieralisi@kernel.org>
> > To: Krzysztof Wilczyński <kw@linux.com>
> > To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > To: Rob Herring <robh@kernel.org>
> > To: Shawn Guo <shawnguo@kernel.org>
> > To: Sascha Hauer <s.hauer@pengutronix.de>
> > To: Pengutronix Kernel Team <kernel@pengutronix.de>
> > To: Fabio Estevam <festevam@gmail.com>
> > Cc: linux-pci@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: imx@lists.linux.dev
> > Cc: Frank.li@nxp.com \
> > Cc: alyssa@rosenzweig.io \
> > Cc: bpf@vger.kernel.org \
> > Cc: broonie@kernel.org \
> > Cc: jgg@ziepe.ca \
> > Cc: joro@8bytes.org \
> > Cc: l.stach@pengutronix.de \
> > Cc: lgirdwood@gmail.com \
> > Cc: maz@kernel.org \
> > Cc: p.zabel@pengutronix.de \
> > Cc: robin.murphy@arm.com \
> > Cc: will@kernel.org \
> > Cc: Robin Murphy <robin.murphy@arm.com>
> > Cc: Marc Zyngier <maz@kernel.org>
> > 
> > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> 
> Applied to pci/controller/imx6 for v6.14, thanks!  And thanks for your
> patience.

While you're at it, could you please consider [1], which builds on top
of the same infrastructure to remove the Apple PCIe IOMMU hack?

Thanks,

	M.

[1] https://lore.kernel.org/linux-pci/20241204150145.800408-1-maz@kernel.org/

-- 
Without deviation from the norm, progress is not possible.