The secure environment only runs in little-endian mode, so any
buffers shared with the secure environment should have their
contents converted to little-endian. We also mark such elements
with __le32 to allow sparse to catch such problems.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NKumar Gala <galak@codeaurora.org>

When an error occurs during an scm call the error returned is remapped so
we lose the original error code. This means that when an error occurs we
have no idea what actually failed within the secure environment.

Add a logging statement that will log the actual error code from scm call
allowing us to easily determine what caused the error to occur.
Signed-off-by: NOlav Haugan <ohaugan@codeaurora.org>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NKumar Gala <galak@codeaurora.org>

scm_call flushes the entire cache before calling into the secure world.
This is both a performance penalty as well as insufficient on SMP systems
where the CPUs possess a write-back L1 cache. Flush only the command and
response buffers instead, moving the responsibility of flushing any other
cached buffer (being passed to the secure world) to callers.
Signed-off-by: NVikram Mulukutla <markivx@codeaurora.org>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NKumar Gala <galak@codeaurora.org>

Instead of hardcoding the cacheline size as 32, get the cacheline size from
the CTR register.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NKumar Gala <galak@codeaurora.org>

The cache invalidation in scm_call() correctly rounds down the start
address to invalidate the beginning of the cacheline but doesn't properly
round up the 'end' address to make it aligned.  The last chunk of the
buffer won't be invalidated when 'end' is not cacheline size aligned so
make sure to invalidate the last few bytes in such situations. It also
doesn't do anything about outer caches so make sure to invalidate and flush
those as well.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NKumar Gala <galak@codeaurora.org>

Introduce a new mach-qcom that will support SoCs that intend to be
multiplatform compatible while keeping mach-msm to legacy SoC/board
support that will not transition over to multiplatform.

As part of this, we move support for MSM8X60, MSM8960 and MSM8974 over
to mach-qcom.
Signed-off-by: NKumar Gala <galak@codeaurora.org>

eca55f4d (ARM: msm: fix compilation flags for MSM_SCM, 2011-11-08)
added the correct assembler directive for the first smc instance
but missed the second instance in scm_get_version(). Add it so we
can compile this file with newer binutils.

Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NDavid Brown <davidb@codeaurora.org>

CONFIG_MSM_SCM uses the smc instruction, which with some
toolchains requires a ".arch_extension" directive.

Cc: David Brown <davidb@codeaurora.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NDavid Brown <davidb@codeaurora.org>

Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>

When we're interrupted on the secure side, we should just issue
another smc instruction again instead of replaying the arguments
to smc. Fix it.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NDavid Brown <davidb@codeaurora.org>

Assign the registers used in the inline assembly immediately
before the inline assembly block. This ensures the compiler
doesn't optimize away dead register assignments when it
shouldn't.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Acked-by: NNicolas Pitre <nico@fluxnic.net>
Signed-off-by: NDavid Brown <davidb@codeaurora.org>

We don't want the compiler to remove these asm statements or
reorder them in any way. Mark them as volatile to be sure.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Acked-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NDavid Brown <davidb@codeaurora.org>

SCM is the protocol used to communicate between the secure and
non-secure code executing on the applications processor. The
non-secure side uses a physically contiguous buffer to pass
information to the secure side; where the buffer conforms to a
format that is agreed upon by both sides. The use of a buffer
allows multiple pending requests to be in flight on the secure
side. It also benefits use cases where the command or response
buffer contains large chunks of data.
Reviewed-by: NSaravana Kannan <skannan@codeaurora.org>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NDavid Brown <davidb@codeaurora.org>