aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTim Sell <[email protected]>2015-07-09 13:27:41 -0400
committerGreg Kroah-Hartman <[email protected]>2015-07-14 18:34:58 -0700
commitaddce19f58c52a03314e2d8a1e30708dabf9bf30 (patch)
tree6b8990574502c272a2210b70fa33e4e2a95e0243
parenta43abee7de3967b7a211ae17563e2e2db40c4f5d (diff)
staging: unisys: respond to msgs post device_create
Fix problem that prevents us from responding to any device message after device_create. By neglecting to NULL out pending_msg_hdr after the device_create response, we were effectively preventing any subsequent messages to the device from working, because device_epilog() will correctly bail out early if it sees that pending_msg_hdr is still set non-NULL, as that is an indicator to mean that an unanswered message is still outstanding. This problem was discovered as part of testing IOVM service partition recovery, because device_epilog() was in fact bailing out when it was called from my_device_changestate(), which of course prevented us from transitioning the device to the paused state. However, the incorrect behavior would occur for ANY subsequent command directed at the device, not just for changestate. Signed-off-by: Tim Sell <[email protected]> Signed-off-by: Benjamin Romer <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
-rw-r--r--drivers/staging/unisys/visorbus/visorchipset.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/drivers/staging/unisys/visorbus/visorchipset.c b/drivers/staging/unisys/visorbus/visorchipset.c
index bb8087e70127..d47ec24e2dc5 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -2047,6 +2047,7 @@ device_create_response(struct visor_device *dev_info, int response)
response);
kfree(dev_info->pending_msg_hdr);
+ dev_info->pending_msg_hdr = NULL;
}
static void