The patch
spi: spi-fsl-dspi: Fix 16-bit word order in 32-bit XSPI mode
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From ca59d5a51690d5b9340343dc36792a252e9414ae Mon Sep 17 00:00:00 2001
From: Vladimir Oltean <olteanv(a)gmail.com>
Date: Sat, 28 Dec 2019 15:55:36 +0200
Subject: [PATCH] spi: spi-fsl-dspi: Fix 16-bit word order in 32-bit XSPI mode
When used in Extended SPI mode on LS1021A, the DSPI controller wants to
have the least significant 16-bit word written first to the TX FIFO.
In fact, the LS1021A reference manual says:
33.5.2.4.2 Draining the TX FIFO
When Extended SPI Mode (DSPIx_MCR[XSPI]) is enabled, if the frame size
of SPI Data to be transmitted is more than 16 bits, then it causes two
Data entries to be popped from TX FIFO simultaneously which are
transferred to the shift register. The first of the two popped entries
forms the 16 least significant bits of the SPI frame to be transmitted.
So given the following TX buffer:
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 0x0 | 0x1 | 0x2 | 0x3 | 0x4 | 0x5 | 0x6 | 0x7 | 0x8 | 0x9 | 0xa | 0xb |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 32-bit word 1 | 32-bit word 2 | 32-bit word 3 |
+-----------------------+-----------------------+-----------------------+
The correct way that a little-endian system should transmit it on the
wire when bits_per_word is 32 is:
0x03020100
0x07060504
0x0b0a0908
But it is actually transmitted as following, as seen with a scope:
0x01000302
0x05040706
0x09080b0a
It appears that this patch has been submitted at least once before:
https://lkml.org/lkml/2018/9/21/286
but in that case Chuanhua Han did not manage to explain the problem
clearly enough and the patch did not get merged, leaving XSPI mode
broken.
Fixes: 8fcd151d2619 ("spi: spi-fsl-dspi: XSPI FIFO handling (in TCFQ mode)")
Cc: Esben Haabendal <eha(a)deif.com>
Cc: Chuanhua Han <chuanhua.han(a)nxp.com>
Signed-off-by: Vladimir Oltean <olteanv(a)gmail.com>
Link: https://lore.kernel.org/r/20191228135536.14284-1-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
drivers/spi/spi-fsl-dspi.c | 15 ++++-----------
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 9c3934efe2b1..8428b69c858b 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -587,21 +587,14 @@ static void dspi_tcfq_write(struct fsl_dspi *dspi)
dspi->tx_cmd |= SPI_PUSHR_CMD_CTCNT;
if (dspi->devtype_data->xspi_mode && dspi->bits_per_word > 16) {
- /* Write two TX FIFO entries first, and then the corresponding
- * CMD FIFO entry.
+ /* Write the CMD FIFO entry first, and then the two
+ * corresponding TX FIFO entries.
*/
u32 data = dspi_pop_tx(dspi);
- if (dspi->cur_chip->ctar_val & SPI_CTAR_LSBFE) {
- /* LSB */
- tx_fifo_write(dspi, data & 0xFFFF);
- tx_fifo_write(dspi, data >> 16);
- } else {
- /* MSB */
- tx_fifo_write(dspi, data >> 16);
- tx_fifo_write(dspi, data & 0xFFFF);
- }
cmd_fifo_write(dspi);
+ tx_fifo_write(dspi, data & 0xFFFF);
+ tx_fifo_write(dspi, data >> 16);
} else {
/* Write one entry to both TX FIFO and CMD FIFO
* simultaneously.
--
2.20.1
Hi Sasha,
These build issues can be fixed by including linux/nospec.h to
arch/x86/kvm/mtrr.c. Below you can find a patch that compiles on both
v4.9.206 and v4.4.206.
Please let me know if you need anything else.
Marios
========
diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index 0149ac59c273..f223f1315998 100644
--- a/arch/x86/kvm/mtrr.c
+++ b/arch/x86/kvm/mtrr.c
@@ -18,6 +18,7 @@
#include <linux/kvm_host.h>
#include <asm/mtrr.h>
+#include <linux/nospec.h>
#include "cpuid.h"
#include "mmu.h"
@@ -202,11 +203,15 @@ static bool fixed_msr_to_seg_unit(u32 msr, int
*seg, int *unit)
break;
case MSR_MTRRfix16K_80000 ... MSR_MTRRfix16K_A0000:
*seg = 1;
- *unit = msr - MSR_MTRRfix16K_80000;
+ *unit = array_index_nospec(
+ msr - MSR_MTRRfix16K_80000,
+ MSR_MTRRfix16K_A0000 - MSR_MTRRfix16K_80000 + 1);
break;
case MSR_MTRRfix4K_C0000 ... MSR_MTRRfix4K_F8000:
*seg = 2;
- *unit = msr - MSR_MTRRfix4K_C0000;
+ *unit = array_index_nospec(
+ msr - MSR_MTRRfix4K_C0000,
+ MSR_MTRRfix4K_F8000 - MSR_MTRRfix4K_C0000 + 1);
break;
default:
return false;
On Wed, Dec 25, 2019 at 3:55 PM Sasha Levin <sashal(a)kernel.org> wrote:
>
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: de9aef5e1ad6 ("KVM: MTRR: introduce fixed_mtrr_segment table").
>
> The bot has tested the following trees: v5.4.5, v5.3.18, v4.19.90, v4.14.159, v4.9.206, v4.4.206.
>
> v5.4.5: Build OK!
> v5.3.18: Build OK!
> v4.19.90: Build OK!
> v4.14.159: Build OK!
> v4.9.206: Build failed! Errors:
> arch/x86/kvm/mtrr.c:205:11: error: implicit declaration of function ‘array_index_nospec’; did you mean ‘array_index_mask_nospec’? [-Werror=implicit-function-declaration]
>
> v4.4.206: Build failed! Errors:
> arch/x86/kvm/mtrr.c:205:11: error: implicit declaration of function ‘array_index_nospec’; did you mean ‘array_index_mask_nospec’? [-Werror=implicit-function-declaration]
>
>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
>
> --
> Thanks,
> Sasha
--
Marios Pomonis
Software Engineer, Security
GCP Platform Security
US-KIR-6THC