--- /dev/null
+From 7d6380cd40f7993f75c4bde5b36f6019237e8719 Mon Sep 17 00:00:00 2001
+From: Corey Minyard <cminyard@mvista.com>
+Date: Fri, 16 Nov 2018 09:59:21 -0600
+Subject: ipmi:ssif: Fix handling of multi-part return messages
+
+From: Corey Minyard <cminyard@mvista.com>
+
+commit 7d6380cd40f7993f75c4bde5b36f6019237e8719 upstream.
+
+The block number was not being compared right, it was off by one
+when checking the response.
+
+Some statistics wouldn't be incremented properly in some cases.
+
+Check to see if that middle-part messages always have 31 bytes of
+data.
+
+Signed-off-by: Corey Minyard <cminyard@mvista.com>
+Cc: stable@vger.kernel.org # 4.4
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/char/ipmi/ipmi_ssif.c | 25 +++++++++++++++++--------
+ 1 file changed, 17 insertions(+), 8 deletions(-)
+
+--- a/drivers/char/ipmi/ipmi_ssif.c
++++ b/drivers/char/ipmi/ipmi_ssif.c
+@@ -641,8 +641,9 @@ static void msg_done_handler(struct ssif
+
+ /* Remove the multi-part read marker. */
+ len -= 2;
++ data += 2;
+ for (i = 0; i < len; i++)
+- ssif_info->data[i] = data[i+2];
++ ssif_info->data[i] = data[i];
+ ssif_info->multi_len = len;
+ ssif_info->multi_pos = 1;
+
+@@ -670,8 +671,19 @@ static void msg_done_handler(struct ssif
+ }
+
+ blocknum = data[0];
++ len--;
++ data++;
++
++ if (blocknum != 0xff && len != 31) {
++ /* All blocks but the last must have 31 data bytes. */
++ result = -EIO;
++ if (ssif_info->ssif_debug & SSIF_DEBUG_MSG)
++ pr_info("Received middle message <31\n");
+
+- if (ssif_info->multi_len + len - 1 > IPMI_MAX_MSG_LENGTH) {
++ goto continue_op;
++ }
++
++ if (ssif_info->multi_len + len > IPMI_MAX_MSG_LENGTH) {
+ /* Received message too big, abort the operation. */
+ result = -E2BIG;
+ if (ssif_info->ssif_debug & SSIF_DEBUG_MSG)
+@@ -680,16 +692,14 @@ static void msg_done_handler(struct ssif
+ goto continue_op;
+ }
+
+- /* Remove the blocknum from the data. */
+- len--;
+ for (i = 0; i < len; i++)
+- ssif_info->data[i + ssif_info->multi_len] = data[i + 1];
++ ssif_info->data[i + ssif_info->multi_len] = data[i];
+ ssif_info->multi_len += len;
+ if (blocknum == 0xff) {
+ /* End of read */
+ len = ssif_info->multi_len;
+ data = ssif_info->data;
+- } else if (blocknum + 1 != ssif_info->multi_pos) {
++ } else if (blocknum != ssif_info->multi_pos) {
+ /*
+ * Out of sequence block, just abort. Block
+ * numbers start at zero for the second block,
+@@ -717,6 +727,7 @@ static void msg_done_handler(struct ssif
+ }
+ }
+
++ continue_op:
+ if (result < 0) {
+ ssif_inc_stat(ssif_info, receive_errors);
+ } else {
+@@ -724,8 +735,6 @@ static void msg_done_handler(struct ssif
+ ssif_inc_stat(ssif_info, received_message_parts);
+ }
+
+-
+- continue_op:
+ if (ssif_info->ssif_debug & SSIF_DEBUG_STATE)
+ pr_info(PFX "DONE 1: state = %d, result=%d.\n",
+ ssif_info->ssif_state, result);
--- /dev/null
+From will.deacon@arm.com Thu Jan 24 20:02:51 2019
+From: Will Deacon <will.deacon@arm.com>
+Date: Thu, 24 Jan 2019 18:54:15 +0000
+Subject: locking/qspinlock: Pull in asm/byteorder.h to ensure correct endianness
+To: gregkh@linuxfoundation.org
+Cc: linux-kernel@vger.kernel.org, Dave Airlie <airlied@redhat.com>, stable@vger.kernel.org, Will Deacon <will.deacon@arm.com>
+Message-ID: <20190124185415.29830-1-will.deacon@arm.com>
+
+From: Dave Airlie <airlied@redhat.com>
+
+This commit is not required upstream, but is required for the 4.9.y
+stable series.
+
+Upstream commit 101110f6271c ("Kbuild: always define endianess in
+kconfig.h") ensures that either __LITTLE_ENDIAN or __BIG_ENDIAN is
+defined to reflect the endianness of the target CPU architecture
+regardless of whether or not <asm/byteorder.h> has been #included. The
+upstream definition of 'struct qspinlock' relies on this property.
+
+Unfortunately, the 4.9.y stable series does not provide this guarantee,
+so the 'spin_unlock()' routine can erroneously treat the underlying
+lockword as big-endian on little-endian architectures using native
+qspinlock (i.e. x86_64 without PV) if the caller has not included
+<asm/byteorder.h>. This can lead to hangs such as the one in
+'i915_gem_request()' reported via bugzilla:
+
+ https://bugzilla.kernel.org/show_bug.cgi?id=202063
+
+Fix the issue by ensuring that <asm/byteorder.h> is #included in
+<asm/qspinlock_types.h>, where 'struct qspinlock' is defined.
+
+Cc: <stable@vger.kernel.org> # 4.9
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+[will: wrote commit message]
+Signed-off-by: Will Deacon <will.deacon@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/asm-generic/qspinlock_types.h | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/include/asm-generic/qspinlock_types.h
++++ b/include/asm-generic/qspinlock_types.h
+@@ -18,6 +18,8 @@
+ #ifndef __ASM_GENERIC_QSPINLOCK_TYPES_H
+ #define __ASM_GENERIC_QSPINLOCK_TYPES_H
+
++#include <asm/byteorder.h>
++
+ /*
+ * Including atomic.h with PARAVIRT on will cause compilation errors because
+ * of recursive header file incluson via paravirt_types.h. So don't include
projects / thirdparty / kernel / stable-queue.git / commitdiff
