linux-stable.git/drivers/spi, branch v6.3.8 Linux kernel stable tree spi: qup: Request DMA before enabling clocks 2023-06-14T09:16:43+00:00 Stephan Gerhold stephan@gerhold.net 2023-05-18T13:04:25+00:00 b4efa42b1bd02ff462a161e546e3f85a56916237 [ Upstream commit 0c331fd1dccfba657129380ee084b95c1cedfbef ] It is usually better to request all necessary resources (clocks, regulators, ...) before starting to make use of them. That way they do not change state in case one of the resources is not available yet and probe deferral (-EPROBE_DEFER) is necessary. This is particularly important for DMA channels and IOMMUs which are not enforced by fw_devlink yet (unless you use fw_devlink.strict=1). spi-qup does this in the wrong order, the clocks are enabled and disabled again when the DMA channels are not available yet. This causes issues in some cases: On most SoCs one of the SPI QUP clocks is shared with the UART controller. When using earlycon UART is actively used during boot but might not have probed yet, usually for the same reason (waiting for the DMA controller). In this case, the brief enable/disable cycle ends up gating the clock and further UART console output will halt the system completely. Avoid this by requesting the DMA channels before changing the clock state. Fixes: 612762e82ae6 ("spi: qup: Add DMA capabilities") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20230518-spi-qup-clk-defer-v1-1-f49fc9ca4e02@gerhold.net Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 0c331fd1dccfba657129380ee084b95c1cedfbef ]

It is usually better to request all necessary resources (clocks,
regulators, ...) before starting to make use of them. That way they do
not change state in case one of the resources is not available yet and
probe deferral (-EPROBE_DEFER) is necessary. This is particularly
important for DMA channels and IOMMUs which are not enforced by
fw_devlink yet (unless you use fw_devlink.strict=1).

spi-qup does this in the wrong order, the clocks are enabled and
disabled again when the DMA channels are not available yet.

This causes issues in some cases: On most SoCs one of the SPI QUP
clocks is shared with the UART controller. When using earlycon UART is
actively used during boot but might not have probed yet, usually for
the same reason (waiting for the DMA controller). In this case, the
brief enable/disable cycle ends up gating the clock and further UART
console output will halt the system completely.

Avoid this by requesting the DMA channels before changing the clock
state.

Fixes: 612762e82ae6 ("spi: qup: Add DMA capabilities")
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20230518-spi-qup-clk-defer-v1-1-f49fc9ca4e02@gerhold.net
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
spi: mt65xx: make sure operations completed before unloading 2023-06-14T09:16:43+00:00 Daniel Golle daniel@makrotopia.org 2023-05-01T18:33:14+00:00 fa16ef475d14cdd347633b5037bcd712196bd57a [ Upstream commit 4be47a5d59cbc9396a6ffd327913eb4c8d67a32f ] When unloading the spi-mt65xx kernel module during an ongoing spi-mem operation the kernel will Oops shortly after unloading the module. This is because wait_for_completion_timeout was still running and returning into the no longer loaded module: Internal error: Oops: 0000000096000005 [#1] SMP Modules linked in: [many, but spi-mt65xx is no longer there] CPU: 0 PID: 2578 Comm: block Tainted: G W O 6.3.0-next-20230428+ #0 Hardware name: Bananapi BPI-R3 (DT) pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __lock_acquire+0x18c/0x20e8 lr : __lock_acquire+0x9b8/0x20e8 sp : ffffffc009ec3400 x29: ffffffc009ec3400 x28: 0000000000000001 x27: 0000000000000004 x26: ffffff80082888c8 x25: 0000000000000000 x24: 0000000000000000 x23: ffffffc009609da8 x22: ffffff8008288000 x21: ffffff8008288968 x20: 00000000000003c2 x19: ffffff8008be7990 x18: 00000000000002af x17: 0000000000000000 x16: 0000000000000000 x15: ffffffc008d78970 x14: 000000000000080d x13: 00000000000002af x12: 00000000ffffffea x11: 00000000ffffefff x10: ffffffc008dd0970 x9 : ffffffc008d78918 x8 : 0000000000017fe8 x7 : 0000000000000001 x6 : 0000000000000000 x5 : ffffff807fb53910 x4 : 0000000000000000 x3 : 0000000000000027 x2 : 0000000000000027 x1 : 0000000000000000 x0 : 00000000000c03c2 Call trace: __lock_acquire+0x18c/0x20e8 lock_acquire+0x100/0x2a4 _raw_spin_lock_irq+0x58/0x74 __wait_for_common+0xe0/0x1b4 wait_for_completion_timeout+0x1c/0x24 0xffffffc000acc8a4 <--- used to be mtk_spi_transfer_wait spi_mem_exec_op+0x390/0x3ec spi_mem_no_dirmap_read+0x6c/0x88 spi_mem_dirmap_read+0xcc/0x12c spinand_read_page+0xf8/0x1dc spinand_mtd_read+0x1b4/0x2fc mtd_read_oob_std+0x58/0x7c mtd_read_oob+0x8c/0x148 mtd_read+0x50/0x6c ... Prevent this by completing in mtk_spi_remove if needed. Fixes: 9f763fd20da7 ("spi: mediatek: add spi memory support for ipm design") Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://lore.kernel.org/r/ZFAF6pJxMu1z6k4w@makrotopia.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 4be47a5d59cbc9396a6ffd327913eb4c8d67a32f ]

When unloading the spi-mt65xx kernel module during an ongoing spi-mem
operation the kernel will Oops shortly after unloading the module.
This is because wait_for_completion_timeout was still running and
returning into the no longer loaded module:

Internal error: Oops: 0000000096000005 [#1] SMP
Modules linked in: [many, but spi-mt65xx is no longer there]
CPU: 0 PID: 2578 Comm: block Tainted: G        W  O       6.3.0-next-20230428+ #0
Hardware name: Bananapi BPI-R3 (DT)
pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __lock_acquire+0x18c/0x20e8
lr : __lock_acquire+0x9b8/0x20e8
sp : ffffffc009ec3400
x29: ffffffc009ec3400 x28: 0000000000000001 x27: 0000000000000004
x26: ffffff80082888c8 x25: 0000000000000000 x24: 0000000000000000
x23: ffffffc009609da8 x22: ffffff8008288000 x21: ffffff8008288968
x20: 00000000000003c2 x19: ffffff8008be7990 x18: 00000000000002af
x17: 0000000000000000 x16: 0000000000000000 x15: ffffffc008d78970
x14: 000000000000080d x13: 00000000000002af x12: 00000000ffffffea
x11: 00000000ffffefff x10: ffffffc008dd0970 x9 : ffffffc008d78918
x8 : 0000000000017fe8 x7 : 0000000000000001 x6 : 0000000000000000
x5 : ffffff807fb53910 x4 : 0000000000000000 x3 : 0000000000000027
x2 : 0000000000000027 x1 : 0000000000000000 x0 : 00000000000c03c2
Call trace:
 __lock_acquire+0x18c/0x20e8
 lock_acquire+0x100/0x2a4
 _raw_spin_lock_irq+0x58/0x74
 __wait_for_common+0xe0/0x1b4
 wait_for_completion_timeout+0x1c/0x24
 0xffffffc000acc8a4 <--- used to be mtk_spi_transfer_wait
 spi_mem_exec_op+0x390/0x3ec
 spi_mem_no_dirmap_read+0x6c/0x88
 spi_mem_dirmap_read+0xcc/0x12c
 spinand_read_page+0xf8/0x1dc
 spinand_mtd_read+0x1b4/0x2fc
 mtd_read_oob_std+0x58/0x7c
 mtd_read_oob+0x8c/0x148
 mtd_read+0x50/0x6c
 ...

Prevent this by completing in mtk_spi_remove if needed.

Fixes: 9f763fd20da7 ("spi: mediatek: add spi memory support for ipm design")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Link: https://lore.kernel.org/r/ZFAF6pJxMu1z6k4w@makrotopia.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
spi: spi-geni-qcom: Select FIFO mode for chip select 2023-06-05T07:29:28+00:00 Vijaya Krishna Nivarthi quic_vnivarth@quicinc.com 2023-05-09T10:01:36+00:00 ca0a99e5e12f5198ad03f5a099d96f92f778fd32 [ Upstream commit 4c329f5da7cfa366bacfda1328a025dd38951317 ] Spi geni driver switches between FIFO and DMA modes based on xfer length. FIFO mode relies on M_CMD_DONE_EN interrupt for completion while DMA mode relies on XX_DMA_DONE. During dynamic switching, if FIFO mode is chosen, FIFO related interrupts are enabled and DMA related interrupts are disabled. And viceversa. Chip select shares M_CMD_DONE_EN interrupt with FIFO to check completion. Now, if a chip select operation is preceded by a DMA xfer, M_CMD_DONE_EN interrupt would have been disabled and hence it will never receive one resulting in timeout. For chip select, in addition to setting the xfer mode to FIFO, select_mode() to FIFO so that required interrupts are enabled. Fixes: e5f0dfa78ac7 ("spi: spi-geni-qcom: Add support for SE DMA mode") Suggested-by: Praveen Talari <quic_ptalari@quicinc.com Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com Reviewed-by: Douglas Anderson <dianders@chromium.org Link: https://lore.kernel.org/r/1683626496-9685-1-git-send-email-quic_vnivarth@quicinc.com Signed-off-by: Mark Brown <broonie@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 4c329f5da7cfa366bacfda1328a025dd38951317 ]

Spi geni driver switches between FIFO and DMA modes based on xfer length.
FIFO mode relies on M_CMD_DONE_EN interrupt for completion while DMA mode
relies on XX_DMA_DONE.
During dynamic switching, if FIFO mode is chosen, FIFO related interrupts
are enabled and DMA related interrupts are disabled. And viceversa.
Chip select shares M_CMD_DONE_EN interrupt with FIFO to check completion.
Now, if a chip select operation is preceded by a DMA xfer, M_CMD_DONE_EN
interrupt would have been disabled and hence it will never receive one
resulting in timeout.

For chip select, in addition to setting the xfer mode to FIFO,
select_mode() to FIFO so that required interrupts are enabled.

Fixes: e5f0dfa78ac7 ("spi: spi-geni-qcom: Add support for SE DMA mode")
Suggested-by: Praveen Talari <quic_ptalari@quicinc.com
Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com
Reviewed-by: Douglas Anderson <dianders@chromium.org
Link: https://lore.kernel.org/r/1683626496-9685-1-git-send-email-quic_vnivarth@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
spi: spi-imx: fix MX51_ECSPI_* macros when cs > 3 2023-05-24T16:30:09+00:00 Kevin Groeneveld kgroeneveld@lenbrook.com 2023-03-18T22:21:32+00:00 4f73c5544a314d1b399cb3b4caf2a9ff43f7c96e [ Upstream commit 87c614175bbf28d3fd076dc2d166bac759e41427 ] When using gpio based chip select the cs value can go outside the range 0 – 3. The various MX51_ECSPI_* macros did not take this into consideration resulting in possible corruption of the configuration. For example for any cs value over 3 the SCLKPHA bits would not be set and other values in the register possibly corrupted. One way to fix this is to just mask the cs bits to 2 bits. This still allows all 4 native chip selects to work as well as gpio chip selects (which can use any of the 4 chip select configurations). Signed-off-by: Kevin Groeneveld <kgroeneveld@lenbrook.com> Link: https://lore.kernel.org/r/20230318222132.3373-1-kgroeneveld@lenbrook.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 87c614175bbf28d3fd076dc2d166bac759e41427 ]

When using gpio based chip select the cs value can go outside the range
0 – 3. The various MX51_ECSPI_* macros did not take this into consideration
resulting in possible corruption of the configuration.

For example for any cs value over 3 the SCLKPHA bits would not be set and
other values in the register possibly corrupted.

One way to fix this is to just mask the cs bits to 2 bits. This still
allows all 4 native chip selects to work as well as gpio chip selects
(which can use any of the 4 chip select configurations).

Signed-off-by: Kevin Groeneveld <kgroeneveld@lenbrook.com>
Link: https://lore.kernel.org/r/20230318222132.3373-1-kgroeneveld@lenbrook.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
spi: intel-pci: Add support for Meteor Lake-S SPI serial flash 2023-05-24T16:30:08+00:00 Mika Westerberg mika.westerberg@linux.intel.com 2023-03-31T05:28:12+00:00 f6c367ddb08a9e70f9d810b0c91081840faa4d89 [ Upstream commit c2912d42e86e494935722669e4d9eade69649072 ] Intel Meteor Lake-S has the same SPI serial flash controller as Meteor Lake-P. Add Meteor Lake-S PCI ID to the driver list of supported devices. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20230331052812.39983-1-mika.westerberg@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit c2912d42e86e494935722669e4d9eade69649072 ]

Intel Meteor Lake-S has the same SPI serial flash controller as Meteor
Lake-P. Add Meteor Lake-S PCI ID to the driver list of supported
devices.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20230331052812.39983-1-mika.westerberg@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
spi: fsl-cpm: Use 16 bit mode for large transfers with even size 2023-05-17T12:02:08+00:00 Christophe Leroy christophe.leroy@csgroup.eu 2023-04-01T17:59:48+00:00 36a6d0f66c874666caf4e8be155b1be30f6231be commit fc96ec826bced75cc6b9c07a4ac44bbf651337ab upstream. On CPM, the RISC core is a lot more efficiant when doing transfers in 16-bits chunks than in 8-bits chunks, but unfortunately the words need to be byte swapped as seen in a previous commit. So, for large tranfers with an even size, allocate a temporary tx buffer and byte-swap data before and after transfer. This change allows setting higher speed for transfer. For instance on an MPC 8xx (CPM1 comms RISC processor), the documentation tells that transfer in byte mode at 1 kbit/s uses 0.200% of CPM load at 25 MHz while a word transfer at the same speed uses 0.032% of CPM load. This means the speed can be 6 times higher in word mode for the same CPM load. For the time being, only do it on CPM1 as there must be a trade-off between the CPM load reduction and the CPU load required to byte swap the data. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Link: https://lore.kernel.org/r/f2e981f20f92dd28983c3949702a09248c23845c.1680371809.git.christophe.leroy@csgroup.eu Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit fc96ec826bced75cc6b9c07a4ac44bbf651337ab upstream.

On CPM, the RISC core is a lot more efficiant when doing transfers
in 16-bits chunks than in 8-bits chunks, but unfortunately the
words need to be byte swapped as seen in a previous commit.

So, for large tranfers with an even size, allocate a temporary tx
buffer and byte-swap data before and after transfer.

This change allows setting higher speed for transfer. For instance
on an MPC 8xx (CPM1 comms RISC processor), the documentation tells
that transfer in byte mode at 1 kbit/s uses 0.200% of CPM load
at 25 MHz while a word transfer at the same speed uses 0.032%
of CPM load. This means the speed can be 6 times higher in
word mode for the same CPM load.

For the time being, only do it on CPM1 as there must be a
trade-off between the CPM load reduction and the CPU load required
to byte swap the data.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/f2e981f20f92dd28983c3949702a09248c23845c.1680371809.git.christophe.leroy@csgroup.eu
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
spi: fsl-spi: Re-organise transfer bits_per_word adaptation 2023-05-17T12:02:08+00:00 Christophe Leroy christophe.leroy@csgroup.eu 2023-04-01T17:59:47+00:00 421f0bacd77222af296f6d0d4407b18e6dd3b086 commit 8a5299a1278eadf1e08a598a5345c376206f171e upstream. For different reasons, fsl-spi driver performs bits_per_word modifications for different reasons: - On CPU mode, to minimise amount of interrupts - On CPM/QE mode to work around controller byte order For CPU mode that's done in fsl_spi_prepare_message() while for CPM mode that's done in fsl_spi_setup_transfer(). Reunify all of it in fsl_spi_prepare_message(), and catch impossible cases early through master's bits_per_word_mask instead of returning EINVAL later. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Link: https://lore.kernel.org/r/0ce96fe96e8b07cba0613e4097cfd94d09b8919a.1680371809.git.christophe.leroy@csgroup.eu Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 8a5299a1278eadf1e08a598a5345c376206f171e upstream.

For different reasons, fsl-spi driver performs bits_per_word
modifications for different reasons:
- On CPU mode, to minimise amount of interrupts
- On CPM/QE mode to work around controller byte order

For CPU mode that's done in fsl_spi_prepare_message() while
for CPM mode that's done in fsl_spi_setup_transfer().

Reunify all of it in fsl_spi_prepare_message(), and catch
impossible cases early through master's bits_per_word_mask
instead of returning EINVAL later.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/0ce96fe96e8b07cba0613e4097cfd94d09b8919a.1680371809.git.christophe.leroy@csgroup.eu
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
spi: cadence-quadspi: use macro DEFINE_SIMPLE_DEV_PM_OPS 2023-05-11T14:17:28+00:00 Dhruva Gole d-gole@ti.com 2023-04-20T05:42:57+00:00 e974588e1bc15ef94d0d110d554e135b7fd50f2d [ Upstream commit be3206e8906e7a93df673ab2e96d69304a008edc ] Using this macro makes the code more readable. It also inits the members of dev_pm_ops in the following manner without us explicitly needing to: .suspend = cqspi_suspend, \ .resume = cqspi_resume, \ .freeze = cqspi_suspend, \ .thaw = cqspi_resume, \ .poweroff = cqspi_suspend, \ .restore = cqspi_resume Also get rid of conditional compilation based on CONFIG_PM_SLEEP because it introduces build issues with certain configs when CQSPI_DEV_PM_OPS is just NULL. Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/oe-kbuild-all/202304191900.2fARFQW9-lkp@intel.com/ Fixes: 140623410536 ("mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller") Signed-off-by: Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20230420054257.925092-1-d-gole@ti.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit be3206e8906e7a93df673ab2e96d69304a008edc ]

Using this macro makes the code more readable.
It also inits the members of dev_pm_ops in the following manner
without us explicitly needing to:

.suspend = cqspi_suspend, \
.resume = cqspi_resume, \
.freeze = cqspi_suspend, \
.thaw = cqspi_resume, \
.poweroff = cqspi_suspend, \
.restore = cqspi_resume

Also get rid of conditional compilation based on CONFIG_PM_SLEEP because
it introduces build issues with certain configs when CQSPI_DEV_PM_OPS is
just NULL.

Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/oe-kbuild-all/202304191900.2fARFQW9-lkp@intel.com/
Fixes: 140623410536 ("mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller")
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Link: https://lore.kernel.org/r/20230420054257.925092-1-d-gole@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
spi: cadence-quadspi: fix suspend-resume implementations 2023-05-11T14:17:27+00:00 Dhruva Gole d-gole@ti.com 2023-04-17T09:10:27+00:00 1368dbc0a432acf9fc0dcb23bfe52d32ca4c09ab [ Upstream commit 2087e85bb66ee3652dafe732bb9b9b896229eafc ] The cadence QSPI driver misbehaves after performing a full system suspend resume: ... spi-nor spi0.0: resume() failed ... This results in a flash connected via OSPI interface after system suspend- resume to be unusable. fix these suspend and resume functions. Fixes: 140623410536 ("mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller") Signed-off-by: Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20230417091027.966146-3-d-gole@ti.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 2087e85bb66ee3652dafe732bb9b9b896229eafc ]

The cadence QSPI driver misbehaves after performing a full system suspend
resume:
...
spi-nor spi0.0: resume() failed
...
This results in a flash connected via OSPI interface after system suspend-
resume to be unusable.
fix these suspend and resume functions.

Fixes: 140623410536 ("mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller")
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Link: https://lore.kernel.org/r/20230417091027.966146-3-d-gole@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
spi: fsl-spi: Fix CPM/QE mode Litte Endian 2023-05-11T14:17:25+00:00 Christophe Leroy christophe.leroy@csgroup.eu 2023-04-01T17:59:46+00:00 6f4a5877622b85bb94582d733d99620a67c33a55 [ Upstream commit c20c57d9868d7f9fd1b2904c7801b07e128f6322 ] CPM has the same problem as QE so for CPM also use the fix added by commit 0398fb70940e ("spi/spi_mpc8xxx: Fix QE mode Litte Endian"): CPM mode uses Little Endian so words > 8 bits are byte swapped. Workaround this by always enforcing wordsize 8 for 16 and 32 bits words. Unfortunately this will not work for LSB transfers where wordsize is > 8 bits so disable these for now. Also limit the workaround to 16 and 32 bits words because it can only work for multiples of 8-bits. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Joakim Tjernlund <Joakim.Tjernlund@infinera.com> Fixes: 0398fb70940e ("spi/spi_mpc8xxx: Fix QE mode Litte Endian") Link: https://lore.kernel.org/r/1b7d3e84b1128f42c1887dd2fb9cdf390f541bc1.1680371809.git.christophe.leroy@csgroup.eu Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit c20c57d9868d7f9fd1b2904c7801b07e128f6322 ]

CPM has the same problem as QE so for CPM also use the fix added
by commit 0398fb70940e ("spi/spi_mpc8xxx: Fix QE mode Litte Endian"):

  CPM mode uses Little Endian so words > 8 bits are byte swapped.
  Workaround this by always enforcing wordsize 8 for 16 and 32 bits
  words. Unfortunately this will not work for LSB transfers
  where wordsize is > 8 bits so disable these for now.

Also limit the workaround to 16 and 32 bits words because it can
only work for multiples of 8-bits.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
Fixes: 0398fb70940e ("spi/spi_mpc8xxx: Fix QE mode Litte Endian")
Link: https://lore.kernel.org/r/1b7d3e84b1128f42c1887dd2fb9cdf390f541bc1.1680371809.git.christophe.leroy@csgroup.eu
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>