Add macro to check for __scm pointer before accessing.
Also add check for device pointer.
Change-Id: Ib3ef303fd9574bedd87077dcd62a480066d7a7d8
Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
With the existing global mutex lock, there is a possibility that it could
result into a deadlock when SMCInvoke(multi_smc_call) and SMC call go to
firmware in the same order and both wait on the same WAITQ in firmware.
Sequence of call flow to firmware is like,
1. lock()
SMCInvoke call()
SLEEP returned. WQ_CTX(1)
unlock()
wait_for_completion()
2. lock()
SMC call
SLEEP returned. WQ_CTX(1)
wait_for_completion()
unlock()
3. Wakeup received from firmware
SMCInvoke call wakes up, return to the client for send a response
back. Here response is again another SMCInvoke call. It first wait
for a lock to grab (generally SMCInvoke doesn't require lock at
all) that is held by SMC call.
Here, until the wake up call (SMCInvoke) response finishes, firmware did
not raise another wakeup to finish. This situation leads to a deadlock.
This change address two problems.
1. Deadlock situation like it explained above.
2. Introduce a semaphore and initialize with number of call contexts
that are supported by hypervisor. This will reduce "-EBUSY" returned
by hypervisor if the number of SMC calls are more than call contexts
in hypervisor.
Change-Id: Ie2ff2ca97a40531f5a129434c0ba2f028a269a5b
Signed-off-by: Murali Nalajala <quic_mnalajal@quicinc.com>
Correct kerneldoc warnings like:
drivers/firmware/qcom_scm-legacy.c:133:
warning: Function parameter or member 'dev' not described in 'scm_legacy_call'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220519073410.7358-1-krzysztof.kozlowski@linaro.org
These functions were renamed but the kernel doc didn't follow along. Fix
it.
Cc: Elliot Berman <eberman@codeaurora.org>
Cc: Brian Masney <masneyb@onstation.org>
Cc: Stephan Gerhold <stephan@gerhold.net>
Cc: Jeffrey Hugo <jhugo@codeaurora.org>
Cc: Douglas Anderson <dianders@chromium.org>
Fixes: 9a434cee77 ("firmware: qcom_scm: Dynamically support SMCCC and legacy conventions")
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20210223214539.1336155-6-swboyd@chromium.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 7649773293 ("cxgb3/l2t: Fix undefined behaviour")
Reviewed-by: Jeffrey Hugo <jhugo@codeaurora.org>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20200508210805.GA24170@embeddedor
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Dynamically support SMCCCC and legacy conventions by detecting which
convention to use at runtime. qcom_scm_call_atomic and qcom_scm_call can
then be moved in qcom_scm.c and use underlying convention backend as
appropriate. Thus, rename qcom_scm-64,-32 to reflect that they are
backends for -smc and -legacy, respectively.
Also add support for making SCM calls earlier than when SCM driver
probes to support use cases such as qcom_scm_set_cold_boot_addr. Support
is added by lazily initializing the convention and guarding the query
with a spin lock. The limitation of these early SCM calls is that they
cannot use DMA, as in the case of >4 arguments for SMC convention and
any non-atomic call for legacy convention.
Tested-by: Brian Masney <masneyb@onstation.org> # arm32
Tested-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
Link: https://lore.kernel.org/r/1578431066-19600-18-git-send-email-eberman@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
