summaryrefslogtreecommitdiff
path: root/drivers/hwtracing
diff options
context:
space:
mode:
authorVladimir Oltean <vladimir.oltean@nxp.com>2020-03-18 03:15:53 +0300
committerMark Brown <broonie@kernel.org>2020-03-19 01:44:54 +0300
commit671ffde1752f594c60ccdfd75378defacfaf7c83 (patch)
tree5e34af3778a26c73146855a0737e32a71a80c0af /drivers/hwtracing
parent4fcc7c2292def2fcb21a9644969583771c52724e (diff)
downloadlinux-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