[PATCH v1 0/3] switchtec: add new device IDs

[PATCH v1 0/3] switchtec: add new device IDs

[Logan Gunthorpe]

This little patch set adds some new device IDs for switchtec hardware
to the PCI driver, the DMA driver and the PCI quirk needed for NTB.

I originally included this in a patchset I'm working on for
switchtec-dma but the Sashiko bot reminded me I need to add it to the
PCI management device and the quirk used for NTB. So I've respun three
patches here.

I'm open to options, but I might suggest if everyone is okay with it
these three patches could just go through the PCI tree together.

These three patches are based on v7.2-rc3.

Thanks,

Logan

Logan Gunthorpe (3):
  dmaengine: switchtec-dma: Add PCI1008 device ID
  PCI/switch: switchtec: Add PCI1008 device ID
  PCI: Add PCI1008 to switchtec NTB DMA alias quirk

 drivers/dma/switchtec_dma.c    | 1 +
 drivers/pci/quirks.c           | 1 +
 drivers/pci/switch/switchtec.c | 1 +
 3 files changed, 3 insertions(+)


base-commit: a13c140cc289c0b7b3770bce5b3ad42ab35074aa
-- 
2.47.3

[PATCH v1 1/3] dmaengine: switchtec-dma: Add PCI1008 device ID

[Logan Gunthorpe]

Add the PCI1008 device ID for switchtec-dma.

Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
---
 drivers/dma/switchtec_dma.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dma/switchtec_dma.c b/drivers/dma/switchtec_dma.c
index 3ef928640615..02083e3f6ebe 100644
--- a/drivers/dma/switchtec_dma.c
+++ b/drivers/dma/switchtec_dma.c
@@ -1424,6 +1424,7 @@ static const struct pci_device_id switchtec_dma_pci_tbl[] = {
 	SW_ID(PCI_VENDOR_ID_EFAR,      0x1004), /* PCI1004 16XG4 */
 	SW_ID(PCI_VENDOR_ID_EFAR,      0x1005), /* PCI1005 16XG4 */
 	SW_ID(PCI_VENDOR_ID_EFAR,      0x1006), /* PCI1006 16XG4 */
+	SW_ID(PCI_VENDOR_ID_EFAR,      0x1008), /* PCI1008 16XG4 */
 	{0}
 };
 MODULE_DEVICE_TABLE(pci, switchtec_dma_pci_tbl);
-- 
2.47.3

Re: [PATCH v1 1/3] dmaengine: switchtec-dma: Add PCI1008 device ID

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch adds the PCI1008 device ID to the switchtec-dma driver but omits it from the core switchtec management driver, resulting in partial and incomplete device support.
--

--- Patch [1]: [PATCH v1 1/3] dmaengine: switchtec-dma: Add PCI1008 device ID ---
commit d1b7f8eab84fc5cd5b1fe8dcb694ed9d25f8d8e7
Author: Logan Gunthorpe <logang@deltatee.com>

dmaengine: switchtec-dma: Add PCI1008 device ID

This commit adds the PCI1008 device ID to the switchtec-dma driver's
supported device table.

> diff --git a/drivers/dma/switchtec_dma.c b/drivers/dma/switchtec_dma.c
> index 3ef9286406159..02083e3f6ebea 100644
> --- a/drivers/dma/switchtec_dma.c
> +++ b/drivers/dma/switchtec_dma.c
> @@ -1424,6 +1424,7 @@ static const struct pci_device_id switchtec_dma_pci_tbl[] = {
>  	SW_ID(PCI_VENDOR_ID_EFAR,      0x1004), /* PCI1004 16XG4 */
>  	SW_ID(PCI_VENDOR_ID_EFAR,      0x1005), /* PCI1005 16XG4 */
>  	SW_ID(PCI_VENDOR_ID_EFAR,      0x1006), /* PCI1006 16XG4 */
> +	SW_ID(PCI_VENDOR_ID_EFAR,      0x1008), /* PCI1008 16XG4 */

[Severity: Medium]
Does this new device ID also need to be added to switchtec_pci_tbl in
drivers/pci/switch/switchtec.c?

If the companion ID is omitted from the core management driver, the DMA
engine will bind, but the core management function will not. Would this
leave the character device, NTB features, and hardware telemetry
inaccessible for the PCI1008 device?

>  	{0}
>  };
>  MODULE_DEVICE_TABLE(pci, switchtec_dma_pci_tbl);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714212010.230606-1-logang@deltatee.com?part=1

Re: [PATCH v1 1/3] dmaengine: switchtec-dma: Add PCI1008 device ID

[Logan Gunthorpe]

On 2026-07-14 15:28, sashiko-bot@kernel.org wrote:
> [Severity: Medium]
> Does this new device ID also need to be added to switchtec_pci_tbl in
> drivers/pci/switch/switchtec.c?
> 
> If the companion ID is omitted from the core management driver, the DMA
> engine will bind, but the core management function will not. Would this
> leave the character device, NTB features, and hardware telemetry
> inaccessible for the PCI1008 device?

Unless I'm totally missing something, this is taken care of by the next
two patches in this series.

Logan

[PATCH v1 2/3] PCI/switch: switchtec: Add PCI1008 device ID

[Logan Gunthorpe]

Add the PCI1008 device ID to the core switchtec management
driver's PCI ID table. Without it, the management endpoint on a
PCI1008 switch is not bound by this driver, preventing userspace
tools from configuring or monitoring the switch and leaving NTB
functionality unavailable.

Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
---
 drivers/pci/switch/switchtec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index 41fc4b512708..5711aaa5df11 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -1874,6 +1874,7 @@ static const struct pci_device_id switchtec_pci_tbl[] = {
 	SWITCHTEC_PCI100X_DEVICE(0x1004, SWITCHTEC_GEN4),  /* PCI1004 16XG4 */
 	SWITCHTEC_PCI100X_DEVICE(0x1005, SWITCHTEC_GEN4),  /* PCI1005 16XG4 */
 	SWITCHTEC_PCI100X_DEVICE(0x1006, SWITCHTEC_GEN4),  /* PCI1006 16XG4 */
+	SWITCHTEC_PCI100X_DEVICE(0x1008, SWITCHTEC_GEN4),  /* PCI1008 16XG4 */
 	{0}
 };
 MODULE_DEVICE_TABLE(pci, switchtec_pci_tbl);
-- 
2.47.3

Re: [PATCH v1 2/3] PCI/switch: switchtec: Add PCI1008 device ID

[sashiko-bot]

> Add the PCI1008 device ID to the core switchtec management
> driver's PCI ID table. Without it, the management endpoint on a
> PCI1008 switch is not bound by this driver, preventing userspace
> tools from configuring or monitoring the switch and leaving NTB
> functionality unavailable.
> 
> Signed-off-by: Logan Gunthorpe <logang@deltatee.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714212010.230606-1-logang@deltatee.com?part=2

[PATCH v1 3/3] PCI: Add PCI1008 to switchtec NTB DMA alias quirk

[Logan Gunthorpe]

Add the PCI1008 device ID to the quirk_switchtec_ntb_dma_alias
PCI fixup table. Without it, DMA transactions from a PCI1008 switch's
NTB function are not given the correct requester ID alias, which can
misdirect them under an IOMMU.

Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
---
 drivers/pci/quirks.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index b09f27f7846f..44ccee48349c 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -6090,6 +6090,7 @@ SWITCHTEC_PCI100X_QUIRK(0x1003);  /* PCI1003XG4 */
 SWITCHTEC_PCI100X_QUIRK(0x1004);  /* PCI1004XG4 */
 SWITCHTEC_PCI100X_QUIRK(0x1005);  /* PCI1005XG4 */
 SWITCHTEC_PCI100X_QUIRK(0x1006);  /* PCI1006XG4 */
+SWITCHTEC_PCI100X_QUIRK(0x1008);  /* PCI1008XG4 */
 
 
 /*
-- 
2.47.3

Re: [PATCH v1 3/3] PCI: Add PCI1008 to switchtec NTB DMA alias quirk

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Incorrect pointer arithmetic when reading the upper 32 bits of `ep_map` results in reading from the wrong MMIO offset.
--

--- Patch [3]: [PATCH v1 3/3] PCI: Add PCI1008 to switchtec NTB DMA alias quirk ---
commit 7f63ba41929ba7abb0f74f406090b22d57b6bc5e
Author: Logan Gunthorpe <logang@deltatee.com>
PCI: Add PCI1008 to switchtec NTB DMA alias quirk

Add the PCI1008 device ID to the quirk_switchtec_ntb_dma_alias
PCI fixup table. Without it, DMA transactions from a PCI1008 switch's
NTB function are not given the correct requester ID alias, which can
misdirect them under an IOMMU.

> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index b09f27f7846fc..44ccee48349c3 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -6090,6 +6090,7 @@ SWITCHTEC_PCI100X_QUIRK(0x1003);  /* PCI1003XG4 */
>  SWITCHTEC_PCI100X_QUIRK(0x1004);  /* PCI1004XG4 */
>  SWITCHTEC_PCI100X_QUIRK(0x1005);  /* PCI1005XG4 */
>  SWITCHTEC_PCI100X_QUIRK(0x1006);  /* PCI1006XG4 */
> +SWITCHTEC_PCI100X_QUIRK(0x1008);  /* PCI1008XG4 */

[Severity: High]
This isn't a bug introduced by this patch, but while looking at the function
triggered by this quirk (quirk_switchtec_ntb_dma_alias()), I noticed an
incorrect pointer arithmetic issue.

In drivers/pci/quirks.c:quirk_switchtec_ntb_dma_alias():

	partition_map = ioread32(&mmio_ntb->ep_map);
	partition_map |= ((u64) ioread32(&mmio_ntb->ep_map + 4)) << 32;

Since mmio_ntb->ep_map is a u64, does the + 4 advance the pointer by 32
bytes (4 * sizeof(u64)) instead of the intended 4 bytes?

Looking at struct ntb_info_regs, this would read from offset 36
(target_part_low) instead of the upper 32 bits of ep_map at offset 8. This
populates the upper 32 bits of partition_map with unintended data, causing
the device initialization loop to process invalid partition IDs, which
could potentially access out-of-bounds MMIO registers or create incorrect
DMA aliases.

Could this read be corrected to avoid scaling by the type size?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714212010.230606-1-logang@deltatee.com?part=3

Re: [PATCH v1 3/3] PCI: Add PCI1008 to switchtec NTB DMA alias quirk

[Logan Gunthorpe]

On 2026-07-14 15:38, sashiko-bot@kernel.org wrote:
> [Severity: High]
> This isn't a bug introduced by this patch, but while looking at the function
> triggered by this quirk (quirk_switchtec_ntb_dma_alias()), I noticed an
> incorrect pointer arithmetic issue.
> 
> In drivers/pci/quirks.c:quirk_switchtec_ntb_dma_alias():
> 
> 	partition_map = ioread32(&mmio_ntb->ep_map);
> 	partition_map |= ((u64) ioread32(&mmio_ntb->ep_map + 4)) << 32;
> 
> Since mmio_ntb->ep_map is a u64, does the + 4 advance the pointer by 32
> bytes (4 * sizeof(u64)) instead of the intended 4 bytes?
> 
> Looking at struct ntb_info_regs, this would read from offset 36
> (target_part_low) instead of the upper 32 bits of ep_map at offset 8. This
> populates the upper 32 bits of partition_map with unintended data, causing
> the device initialization loop to process invalid partition IDs, which
> could potentially access out-of-bounds MMIO registers or create incorrect
> DMA aliases.
> 
> Could this read be corrected to avoid scaling by the type size?
> 

As noted by the Sashiko bot, this issue is unrelated to this series. But
I'll dig into it and try to remember if that was intended or a mistake
and send a patch if needed. In the mean time, this shouldn't gate this
series.

Logan