diff options
author | Vladimir Oltean <vladimir.oltean@nxp.com> | 2020-03-18 03:15:53 +0300 |
---|---|---|
committer | Mark Brown <broonie@kernel.org> | 2020-03-19 01:44:54 +0300 |
commit | 671ffde1752f594c60ccdfd75378defacfaf7c83 (patch) | |
tree | 5e34af3778a26c73146855a0737e32a71a80c0af /drivers/hwtracing | |
parent | 4fcc7c2292def2fcb21a9644969583771c52724e (diff) | |
download | linux-671ffde1752f594c60ccdfd75378defacfaf7c83.tar.xz |
spi: spi-fsl-dspi: Fix little endian access to PUSHR CMD and TXDATA
In XSPI mode, the 32-bit PUSHR register can be written to separately:
the higher 16 bits are for commands and the lower 16 bits are for data.
This has nicely been hacked around, by defining a second regmap with a
width of 16 bits, and effectively splitting a 32-bit register into 2
16-bit ones, from the perspective of this regmap_pushr.
The problem is the assumption about the controller's endianness. If the
controller is little endian (such as anything post-LS1046A), then the
first 2 bytes, in the order imposed by memory layout, will actually hold
the TXDATA, and the last 2 bytes will hold the CMD.
So take the controller's endianness into account when performing split
writes to PUSHR. The obvious and simple solution would have been to call
regmap_get_val_endian(), but that is an internal regmap function and we
don't want to change regmap just for this. Therefore, we just re-read
the "big-endian" device tree property.
Fixes: 58ba07ec79e6 ("spi: spi-fsl-dspi: Add support for XSPI mode registers")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-3-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat (limited to 'drivers/hwtracing')
0 files changed, 0 insertions, 0 deletions