It is strange to call dma_unmap_single() with its 'dev' argument
explicitly set to NULL.
It is likely to crash.

Fix it by passing 'board->dev' as done in all other cases in
fluke_dma_read().

Fixes: 55936779f496 ("staging: gpib: Add Fluke cda based cards GPIB driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
This patch is compile tested only.
---
 drivers/gpib/eastwood/fluke_gpib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpib/eastwood/fluke_gpib.c b/drivers/gpib/eastwood/fluke_gpib.c
index 3ae848e3f738..61eca22dc2b0 100644
--- a/drivers/gpib/eastwood/fluke_gpib.c
+++ b/drivers/gpib/eastwood/fluke_gpib.c
@@ -586,7 +586,7 @@ static int fluke_dma_read(struct gpib_board *board, u8 *buffer,
 					      DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
 	if (!tx_desc) {
 		dev_err(board->gpib_dev, "failed to allocate dma transmit descriptor\n");
-		dma_unmap_single(NULL, bus_address, length, DMA_FROM_DEVICE);
+		dma_unmap_single(board->dev, bus_address, length, DMA_FROM_DEVICE);
 		return -EIO;
 	}
 	tx_desc->callback = fluke_dma_callback;
-- 
2.52.0

On Sat, Dec 06, 2025 at 08:02:25AM +0100, Christophe JAILLET wrote:
> It is strange to call dma_unmap_single() with its 'dev' argument
> explicitly set to NULL.
> It is likely to crash.

I've added the assumption to Smatch that it will crash.  Which as you
say is not true, but I think it probably is the correct assumption,
right?

This is a one liner in Smatch.

regards,
dan carpenter

diff --git a/smatch_dereference.c b/smatch_dereference.c
index 15ad885af085..acd70ef9dec4 100644
--- a/smatch_dereference.c
+++ b/smatch_dereference.c
@@ -34,6 +34,7 @@ static struct deref_info fn_deref_table[] = {
 	{ "__fortify_strlen", 0, "$" },
 	{ "spinlock_check", 0, "$" },
 	{ "devm_platform_ioremap_resource_byname", 1, "$" },
+	{ "dma_unmap_single_attrs", 0, "$" },
 };
 
 void add_dereference_hook(expr_func *fn)