[PATCH v1] dmaengine: nbpfaxi: Drop unused platform_device_id array

[PATCH v1] dmaengine: nbpfaxi: Drop unused platform_device_id array

[Uwe Kleine-König (The Capable Hub)]

The dma-nbpf driver only probes devices from device tree and fails to
probe devices relying on the traditional platform device probe path. So
the platform_device_id array is unused apart from providing misleading
module meta data.

Drop it.

Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
 drivers/dma/nbpfaxi.c | 15 ---------------
 1 file changed, 15 deletions(-)

diff --git a/drivers/dma/nbpfaxi.c b/drivers/dma/nbpfaxi.c
index 334425faac00..05d7321629cc 100644
--- a/drivers/dma/nbpfaxi.c
+++ b/drivers/dma/nbpfaxi.c
@@ -1486,20 +1486,6 @@ static void nbpf_remove(struct platform_device *pdev)
 	clk_disable_unprepare(nbpf->clk);
 }
 
-static const struct platform_device_id nbpf_ids[] = {
-	{"nbpfaxi64dmac1b4",	(kernel_ulong_t)&nbpf_cfg[NBPF1B4]},
-	{"nbpfaxi64dmac1b8",	(kernel_ulong_t)&nbpf_cfg[NBPF1B8]},
-	{"nbpfaxi64dmac1b16",	(kernel_ulong_t)&nbpf_cfg[NBPF1B16]},
-	{"nbpfaxi64dmac4b4",	(kernel_ulong_t)&nbpf_cfg[NBPF4B4]},
-	{"nbpfaxi64dmac4b8",	(kernel_ulong_t)&nbpf_cfg[NBPF4B8]},
-	{"nbpfaxi64dmac4b16",	(kernel_ulong_t)&nbpf_cfg[NBPF4B16]},
-	{"nbpfaxi64dmac8b4",	(kernel_ulong_t)&nbpf_cfg[NBPF8B4]},
-	{"nbpfaxi64dmac8b8",	(kernel_ulong_t)&nbpf_cfg[NBPF8B8]},
-	{"nbpfaxi64dmac8b16",	(kernel_ulong_t)&nbpf_cfg[NBPF8B16]},
-	{},
-};
-MODULE_DEVICE_TABLE(platform, nbpf_ids);
-
 static int nbpf_runtime_suspend(struct device *dev)
 {
 	struct nbpf_device *nbpf = dev_get_drvdata(dev);
@@ -1523,7 +1509,6 @@ static struct platform_driver nbpf_driver = {
 		.of_match_table = nbpf_match,
 		.pm = pm_ptr(&nbpf_pm_ops),
 	},
-	.id_table = nbpf_ids,
 	.probe = nbpf_probe,
 	.remove = nbpf_remove,
 };

base-commit: e7d700e14934e68f86338c5610cf2ae76798b663
-- 
2.47.3

Re: [PATCH v1] dmaengine: nbpfaxi: Drop unused platform_device_id array

[sashiko-bot]

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

Pre-existing issues:
- [High] Missing NULL check for `of_device_get_match_data()` in `nbpf_probe`.
- [High] Incorrect teardown order in `nbpf_remove()` can lead to hangs or system lockups.
- [High] The IRQ parsing loop in `nbpf_probe` will infinite loop if the device provides fewer than 9 valid IRQs.
--

commit d301198fc76e0a445cdebcc7c4a6a82f78f759b5
Author: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>

dmaengine: nbpfaxi: Drop unused platform_device_id array

The dma-nbpf driver only probes devices from device tree and fails to
probe devices relying on the traditional platform device probe path.
This patch removes the unused platform_device_id array to prevent
misleading module metadata.

> diff --git a/drivers/dma/nbpfaxi.c b/drivers/dma/nbpfaxi.c
> index 334425faac00b..05d7321629cc8 100644
> --- a/drivers/dma/nbpfaxi.c
> +++ b/drivers/dma/nbpfaxi.c
> @@ -1486,20 +1486,6 @@ static void nbpf_remove(struct platform_device *pdev)
>  	clk_disable_unprepare(nbpf->clk);
>  }

[Severity: High]
This is a pre-existing issue, but is the teardown order in this function
safe?

It looks like the driver frees the DMA channel IRQs and kills the tasklets
before calling dma_async_device_unregister().

Could this allow new requests to be submitted while the driver is being
torn down? Unregistering the DMA device is typically done first to prevent
new requests and drain the framework.

Additionally, the hardware clock is disabled via clk_disable_unprepare() 
before explicitly terminating active DMA transactions. If a transfer is
running when the module is removed or unbound, could gating the clock of
an active AXI DMA engine cause a system bus lockup?

[ ... ]

> @@ -1523,7 +1509,6 @@ static struct platform_driver nbpf_driver = {
>  		.of_match_table = nbpf_match,
>  		.pm = pm_ptr(&nbpf_pm_ops),
>  	},
> -	.id_table = nbpf_ids,
>  	.probe = nbpf_probe,

[Severity: High]
This isn't a bug introduced by this patch, but does the probe function
handle a missing compatible string safely?

If the driver is manually bound via sysfs (e.g., using driver_override) to
a platform device that has an of_node but an unrecognized or absent
compatible string, of_device_get_match_data() will return NULL.
Dereferencing this NULL pointer to access num_channels would cause a
kernel panic.

[Severity: High]
This is another pre-existing issue in nbpf_probe(), but does the IRQ
parsing loop handle devices with fewer than 9 valid IRQs correctly?

If platform_get_irq_optional() encounters an out-of-bounds index, it
returns -ENXIO. The loop evaluates:

    if (irq < 0 && irq != -ENXIO)
        return irq;

This ignores the -ENXIO error but doesn't break out of the loop. The
irqbuf[irqs++] = irq assignment is skipped, so the loop variable irqs is
never incremented.

Since the loop condition (irqs < ARRAY_SIZE(irqbuf)) remains true and i
increments without bound, could this cause an infinite loop during probe
for devices providing fewer than 9 IRQs?

>  	.remove = nbpf_remove,
>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/5f7380828873e2375e319ef091178d11a277a0ac.1779965563.git.u.kleine-koenig@baylibre.com?part=1