The function controlvm_respond returns proper error handling, so now we
can propagate the error up and handle it appropriately.
Signed-off-by: David Kershner <david.kersh...@unisys.com>
Reported-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
drivers/staging/unisys/visorbus/visorchipset.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/unisys/visorbus/visorchipset.c
b/drivers/staging/unisys/visorbus/visorchipset.c
index f740b52..50e245e 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -676,18 +676,18 @@ device_changestate_responder(enum controlvm_id cmd_id,
CONTROLVM_QUEUE_REQUEST, &outmsg);
}
-static void
+static int
device_responder(enum controlvm_id cmd_id,
struct controlvm_message_header *pending_msg_hdr,
int response)
{
if (!pending_msg_hdr)
- return; /* no controlvm response needed */
+ return -EIO;
if (pending_msg_hdr->id != (u32)cmd_id)
- return;
+ return -EINVAL;
- controlvm_respond(pending_msg_hdr, response);
+ return controlvm_respond(pending_msg_hdr, response);
}
static int
--
git-series 0.8.11
_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
