Entries in an IPA route or filter table are 64-bit little-endian
addresses, each of which refers to a routing or filtering rule.
The format of these table slots are fixed, but IPA_TABLE_ENTRY_SIZE
is used to define their size. This symbol doesn't really add value,
and I think it unnecessarily obscures what a table entry *is*.
So get rid of IPA_TABLE_ENTRY_SIZE, and just use sizeof(__le64) in
its place throughout the code.
Update the comments in "ipa_table.c" to provide a little better
explanation of these table slots.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Modify conditional tests throughout the IPA code so they do not
assume that IPA v3.5.1 is the oldest version supported. Also remove
assumptions that IPA v4.5 is the newest version of IPA supported.
Augment versions in comments with "+", to be clearer that the
comment applies to a version and subsequent versions. (E.g.,
"present for IPA v4.2+" instead of just "present for v4.2".)
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
There are several memory regions that are defined starting with IPA
v4.0, but which were not used for the SC7180 SoC (IPA v4.2). Even
though they're not used (yet), define them so they are ready to be
used for SoCs when they become supported.
There are two QUOTA statistics memory regions, one for the modem and
one for the AP. Define distinct names for these regions, and get
rid of the definition of IPA_MEM_STATS_QUOTA.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
When a QMI handle is initialized, an array of message handler
structures is provided, defining how any received message should
be handled based on its type and message ID. The QMI core code
traverses this array when a message arrives and calls the function
associated with the (type, msg_id) found in the array.
The array is supposed to be terminated with an empty (all zero)
entry though. Without it, an unsupported message will cause
the QMI core code to go past the end of the array.
Fix this bug, by properly terminating the message handler arrays
provided when QMI handles are set up by the IPA driver.
Fixes: 530f9216a9 ("soc: qcom: ipa: AP/modem communications")
Reported-by: Sujit Kautkar <sujitka@chromium.org>
Signed-off-by: Alex Elder <elder@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Replace a comma between expression statements by a semicolon.
Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
These are only used as input arguments to qmi_handle_init() which
accepts const pointers to both qmi_ops and qmi_msg_handler. Make them
const to allow the compiler to put them in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Acked-by: Alex Elder <elder@linaro.org>
Link: https://lore.kernel.org/r/20201122234031.33432-2-rikard.falkeborn@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This patch implements two forms of out-of-band communication between
the AP and modem.
- QMI is a mechanism that allows clients running on the AP
interact with services running on the modem (and vice-versa).
The AP IPA driver uses QMI to communicate with the corresponding
IPA driver resident on the modem, to agree on parameters used
with the IPA hardware and to ensure both sides are ready before
entering operational mode.
- SMP2P is a more primitive mechanism available for the modem and
AP to communicate with each other. It provides a means for either
the AP or modem to interrupt the other, and furthermore, to provide
32 bits worth of information. The IPA driver uses SMP2P to tell
the modem what the state of the IPA clock was in the event of a
crash. This allows the modem to safely access the IPA hardware
(or avoid doing so) when a crash occurs, for example, to access
information within the IPA hardware.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>