[PATCH] media: staging/ipu7: return 0 for IPC messages that expect no response

[PATCH] media: staging/ipu7: return 0 for IPC messages that expect no response

[Sidharth (Siddhi) Sharma]

ipu_buttress_ipc_send_msg() sends a command to the CSE and waits for the
send_complete completion, which the interrupt handler raises once the CSE
has executed the command. When a message does not ask for a response,
that completion is the whole story: the command went through, and the
caller should be told it succeeded.

The no-response path does the opposite. Right after the command completes
successfully it returns -EIO, turning a good send into an error. The IPU6
driver this code was derived from gets it right, since there the
no-response case simply moves on to the next message. This looks like a
slip made when the bulk loop was collapsed into a single-message helper.

Every caller today passes require_resp = true, so nothing is broken in
practice yet, but the return value is wrong and will trip up the first
no-response command that comes along. Return 0 instead.

Fixes: b7fe4c0019b1 ("media: staging/ipu7: add Intel IPU7 PCI device driver")
Signed-off-by: Sidharth (Siddhi) Sharma <wednisegit@gmail.com>
---
 drivers/staging/media/ipu7/ipu7-buttress.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/ipu7/ipu7-buttress.c b/drivers/staging/media/ipu7/ipu7-buttress.c
index 40c6c8473..8b57c7c1a 100644
--- a/drivers/staging/media/ipu7/ipu7-buttress.c
+++ b/drivers/staging/media/ipu7/ipu7-buttress.c
@@ -265,7 +265,7 @@ static int ipu_buttress_ipc_send_msg(struct ipu7_device *isp,
 	}
 
 	if (!msg->require_resp) {
-		ret = -EIO;
+		ret = 0;
 		goto out;
 	}
 
-- 
2.55.0

Re: [PATCH] media: staging/ipu7: return 0 for IPC messages that expect no response

[Sakari Ailus]

Hi Sidharth,

On Tue, Aug 11, 2026 at 06:47:18AM +0530, Sidharth (Siddhi) Sharma wrote:
> ipu_buttress_ipc_send_msg() sends a command to the CSE and waits for the
> send_complete completion, which the interrupt handler raises once the CSE
> has executed the command. When a message does not ask for a response,
> that completion is the whole story: the command went through, and the
> caller should be told it succeeded.
> 
> The no-response path does the opposite. Right after the command completes
> successfully it returns -EIO, turning a good send into an error. The IPU6
> driver this code was derived from gets it right, since there the
> no-response case simply moves on to the next message. This looks like a
> slip made when the bulk loop was collapsed into a single-message helper.
> 
> Every caller today passes require_resp = true, so nothing is broken in
> practice yet, but the return value is wrong and will trip up the first
> no-response command that comes along. Return 0 instead.
> 
> Fixes: b7fe4c0019b1 ("media: staging/ipu7: add Intel IPU7 PCI device driver")
> Signed-off-by: Sidharth (Siddhi) Sharma <wednisegit@gmail.com>

Thanks for the patch. I'm however inclined to reject this because:

1. There's no actual bug here as all callers pass true for require_resp.

2. This staging driver will be dropped soon, in favour of supporting IPU7
and later in the ipu6 driver.

-- 
Kind regards,

Sakari Ailus