From c5bceb98ce0e4ae8057a386c5171a868213fe226 Mon Sep 17 00:00:00 2001 From: Cristian Marussi Date: Mon, 20 Apr 2020 16:23:15 +0100 Subject: firmware: arm_scmi: Fix handling of unexpected delayed responses Upon reception of an unexpected bogus delayed response, clear the channel and bail-out safely. Link: https://lore.kernel.org/r/20200420152315.21008-5-cristian.marussi@arm.com Fixes: 4d09852b6f01 ("firmware: arm_scmi: Add support for notifications message processing") Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla --- drivers/firmware/arm_scmi/driver.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c index 07de196f15aa..fec308e47b9d 100644 --- a/drivers/firmware/arm_scmi/driver.c +++ b/drivers/firmware/arm_scmi/driver.c @@ -247,6 +247,21 @@ static void scmi_handle_response(struct scmi_chan_info *cinfo, } xfer = &minfo->xfer_block[xfer_id]; + /* + * Even if a response was indeed expected on this slot at this point, + * a buggy platform could wrongly reply feeding us an unexpected + * delayed response we're not prepared to handle: bail-out safely + * blaming firmware. + */ + if (unlikely(msg_type == MSG_TYPE_DELAYED_RESP && !xfer->async_done)) { + dev_err(dev, + "Delayed Response for %d not expected! Buggy F/W ?\n", + xfer_id); + info->desc->ops->clear_channel(cinfo); + /* It was unexpected, so nobody will clear the xfer if not us */ + __scmi_xfer_put(minfo, xfer); + return; + } scmi_dump_header_dbg(dev, &xfer->hdr); -- cgit