summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorLaurentiu Tudor <laurentiu.tudor@nxp.com>2017-07-19 14:42:30 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2017-07-30 08:23:27 -0700
commitb064d0e6e42ed4774c42bfbec0db60f8249a9de2 (patch)
tree28a51e979f69635aa32d128abf95b074e5430bb4
parentf1027a8cb8d77ed00719d110c03a6aaf73fd137a (diff)
downloadlinux-b064d0e6e42ed4774c42bfbec0db60f8249a9de2.tar.gz
linux-b064d0e6e42ed4774c42bfbec0db60f8249a9de2.tar.bz2
linux-b064d0e6e42ed4774c42bfbec0db60f8249a9de2.zip
staging: fsl-mc: don't use raw device io functions
As raw device io functions are not portable and don't handle byte-order (triggering suspicion that endianness isn't handled well) switch to using the standard api. Since MC expects LE byte-order and the upper layers already take care of that, we need to trick the device io api by doing a LE -> CPU conversion just before calling it. This way, the CPU -> LE conversion done in the api puts the data back in the right byte-order. Obviously, for reads the extra step is mirrored: there's a CPU -> LE conversion following the API call. Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-rw-r--r--drivers/staging/fsl-mc/bus/mc-sys.c21
1 files changed, 15 insertions, 6 deletions
diff --git a/drivers/staging/fsl-mc/bus/mc-sys.c b/drivers/staging/fsl-mc/bus/mc-sys.c
index 195d9f347788..8a6dc477920f 100644
--- a/drivers/staging/fsl-mc/bus/mc-sys.c
+++ b/drivers/staging/fsl-mc/bus/mc-sys.c
@@ -126,12 +126,15 @@ static inline void mc_write_command(struct mc_command __iomem *portal,
/* copy command parameters into the portal */
for (i = 0; i < MC_CMD_NUM_OF_PARAMS; i++)
- __raw_writeq(cmd->params[i], &portal->params[i]);
- /* ensure command params are committed before submitting it */
- wmb();
+ /*
+ * Data is already in the expected LE byte-order. Do an
+ * extra LE -> CPU conversion so that the CPU -> LE done in
+ * the device io write api puts it back in the right order.
+ */
+ writeq_relaxed(le64_to_cpu(cmd->params[i]), &portal->params[i]);
/* submit the command by writing the header */
- __raw_writeq(cmd->header, &portal->header);
+ writeq(le64_to_cpu(cmd->header), &portal->header);
}
/**
@@ -151,14 +154,20 @@ static inline enum mc_cmd_status mc_read_response(struct mc_command __iomem *
enum mc_cmd_status status;
/* Copy command response header from MC portal: */
- resp->header = __raw_readq(&portal->header);
+ resp->header = cpu_to_le64(readq_relaxed(&portal->header));
status = mc_cmd_hdr_read_status(resp);
if (status != MC_CMD_STATUS_OK)
return status;
/* Copy command response data from MC portal: */
for (i = 0; i < MC_CMD_NUM_OF_PARAMS; i++)
- resp->params[i] = __raw_readq(&portal->params[i]);
+ /*
+ * Data is expected to be in LE byte-order. Do an
+ * extra CPU -> LE to revert the LE -> CPU done in
+ * the device io read api.
+ */
+ resp->params[i] =
+ cpu_to_le64(readq_relaxed(&portal->params[i]));
return status;
}