Upcoming new SCMI transports won't need any kind of shared memory support.
Compile shmem.c only if a shmem based transport is selected.

Link: https://lore.kernel.org/r/20210803131024.40280-10-cristian.marussi@arm.comCo-developed-by: NPeter Hilber <peter.hilber@opensynergy.com>
Signed-off-by: NIgor Skalkin <igor.skalkin@opensynergy.com>
[ Peter: Adapted patch for submission to upstream. ]
Signed-off-by: NPeter Hilber <peter.hilber@opensynergy.com>
[ Cristian: Adapted patch/commit_msg to new SCMI Kconfig layout ]
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Add configuration options to be able to select which SCMI transports have
to be compiled into the SCMI stack.

Mailbox and SMC are by default enabled if their related dependencies are
satisfied.

While doing that move all SCMI related config options in their own
dedicated submenu.

Link: https://lore.kernel.org/r/20210803131024.40280-9-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Add a check for the presence of .poll_done transport operation so that
transports that do not need to support polling mode have no need to provide
a dummy .poll_done callback either and polling mode can be disabled in the
SCMI core for that tranport.

Link: https://lore.kernel.org/r/20210803131024.40280-8-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Make transport operation .clear_channel optional since some transports
do not need it and so avoid to have them implement dummy callbacks.

Link: https://lore.kernel.org/r/20210803131024.40280-7-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Even though in case of asynchronous commands an SCMI platform is
constrained to emit the delayed response message only after the related
message response has been sent, the configured underlying transport could
still deliver such messages together or in inverted order, causing races
due to the concurrent or out-of-order access to the underlying xfer.

Introduce a mechanism to grant exclusive access to an xfer in order to
properly serialize concurrent accesses to the same xfer originating from
multiple correlated messages.

Add additional state information to xfer descriptors so as to be able to
identify out-of-order message deliveries and act accordingly:

 - when a delayed response is expected but delivered before the related
   response, the synchronous response is considered as successfully
   received and the delayed response processing is carried on as usual.

 - when/if the missing synchronous response is subsequently received, it
   is discarded as not congruent with the current state of the xfer, or
   simply, because the xfer has been already released and so, now, the
   monotonically increasing sequence number carried by the late response
   is stale.

Link: https://lore.kernel.org/r/20210803131024.40280-6-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Tokens are sequence numbers embedded in the each SCMI message header: they
are used to correlate commands with responses (and delayed responses), but
their usage and policy of selection is entirely up to the caller (usually
the OSPM agent), while they are completely opaque to the callee (i.e. SCMI
platform) which merely copies them back from the command into the response
message header.
This also means that the platform does not, can not and should not enforce
any kind of policy on received messages depending on the contained sequence
number: platform can perfectly handle concurrent requests carrying the same
identifiying token if that should happen.

Moreover the platform is not required to produce in-order responses to
agent requests, the only constraint in these regards is that in case of
an asynchronous message the delayed response must be sent after the
immediate response for the synchronous part of the command transaction.

Currenly the SCMI stack of the OSPM agent selects a token for the egressing
commands picking the lowest possible number which is not already in use by
an existing in-flight transaction, which means, in other words, that we
immediately reuse any token after its transaction has completed or it has
timed out: this policy indeed does simplify management and lookup of tokens
and associated xfers.

Under the above assumptions and constraints, since there is really no state
shared between the agent and the platform to let the platform know when a
token and its associated message has timed out, the current policy of early
reuse of tokens can easily lead to the situation in which a spurious or
late received response (or delayed_response), related to an old stale and
timed out transaction, can be wrongly associated to a newer valid in-flight
xfer that just happens to have reused the same token.

This misbehaviour on such late/spurious responses is more easily exposed on
those transports that naturally have an higher level of parallelism in
processing multiple concurrent in-flight messages.

This commit introduces a new policy of selection of tokens for the OSPM
agent: each new command transfer now gets the next available, monotonically
increasing token, until tokens are exhausted and the counter rolls over.

Such new policy mitigates the above issues with late/spurious responses
since the tokens are now reused as late as possible (when they roll back
ideally) and so it is much easier to identify such late/spurious responses
to stale timed out transactions: this also helps in simplifying the
specific transports implementation since stale transport messages can be
easily identified and discarded early on in the rx path without the need
to cross check their actual state with the core transport layer.
This mitigation is even more effective when, as is usually the case, the
maximum number of pending messages is capped by the platform to a much
lower number than the whole possible range of tokens values (2^10).

This internal policy change in the core SCMI transport layer is fully
transparent to the specific transports so it has not and should not have
any impact on the transports implementation.

Link: https://lore.kernel.org/r/20210803131024.40280-5-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Some SCMI transport could need to perform some transport specific setup
before they can be used by the SCMI core transport layer: typically this
early setup consists in registering with some other kernel subsystem.

Add the optional capability for a transport to provide a couple of init
and exit functions that are assured to be called early during the SCMI
core initialization phase, well before the SCMI core probing step.

[ Peter: Adapted RFC patch by Cristian for submission to upstream. ]

Link: https://lore.kernel.org/r/20210803131024.40280-4-cristian.marussi@arm.comSigned-off-by: NPeter Hilber <peter.hilber@opensynergy.com>
[ Cristian: Fixed scmi_transports_exit point of invocation ]
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Being a while that we have SCMI trace events in the SCMI stack, remove
this debug helper and its call sites.

Link: https://lore.kernel.org/r/20210803131024.40280-3-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Add SCMI type handling to pack/unpack_scmi_header common helper functions.
Initialize hdr.type properly when initializing a command xfer.

Link: https://lore.kernel.org/r/20210803131024.40280-2-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

SCMI message headers carry a sequence number and such field is sized to
allow for MSG_TOKEN_MAX distinct numbers; moreover zero is not really an
acceptable maximum number of pending in-flight messages.

Fix accordingly the checks performed on the value exported by transports
in scmi_desc.max_msg

Link: https://lore.kernel.org/r/20210712141833.6628-3-cristian.marussi@arm.comReported-by: NVincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
[sudeep.holla: updated the patch title and error message]
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

scmi_resp_sensor_reading_complete structure is meant to represent an
SCMI asynchronous reading complete message. The readings field with
a 64bit type forces padding and breaks reads in scmi_sensor_reading_get.

Split it in two adjacent 32bit readings_low/high subfields to avoid the
padding within the structure. Alternatively we could to mark the structure
packed.

Link: https://lore.kernel.org/r/20210628170042.34105-1-cristian.marussi@arm.com
Fixes: e2083d36 ("firmware: arm_scmi: Add SCMI v3.0 sensors timestamped reads")
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Kernel doc validation script still complains about the following:

|No description found for return value of 'scmi_get_protocol_device'
|No description found for return value of 'scmi_devm_notifier_register'
|No description found for return value of 'scmi_devm_notifier_unregister'

Fix adding missing Return kernel-doc statements.

Link: https://lore.kernel.org/r/20210712143504.33541-1-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

The scmi_linux_errmap buffer access index is supposed to depend on the
array size to prevent element out of bounds access. It uses SCMI_ERR_MAX
to check bounds but that can mismatch with the array size. It also
changes the success into -EIO though scmi_linux_errmap is never used in
case of success, it is expected to work for success case too.

It is slightly confusing code as the negative of the error code
is used as index to the buffer. Fix it by negating it at the start and
make it more readable.

Link: https://lore.kernel.org/r/20210707135028.1869642-1-sudeep.holla@arm.comReported-by: Nkernel test robot <lkp@intel.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

The bus probe callback calls the driver callback without further
checking. Better be safe than sorry and refuse registration of a driver
without a probe function to prevent a NULL pointer exception.

Link: https://lore.kernel.org/r/20210624095059.4010157-2-sudeep.holla@arm.com
Fixes: 933c5044 ("firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices")
Reported-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Tested-by: NCristian Marussi <cristian.marussi@arm.com>
Reviewed-by: NCristian Marussi <cristian.marussi@arm.com>
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

When the driver core calls the probe callback it already checked that
the devices match, so there is no need to call the match callback again.

Link: https://lore.kernel.org/r/20210624095059.4010157-1-sudeep.holla@arm.comSuggested-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Tested-by: NCristian Marussi <cristian.marussi@arm.com>
Reviewed-by: NCristian Marussi <cristian.marussi@arm.com>
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Since the hdr->protocol_id is set from the scmi_protocol_instance handle
just before the transfer, there is no need to initialise the same in
scmi_xfer_get_init. Remove the unnecessary initialisations.

Link: https://lore.kernel.org/r/20210608140140.2042257-1-sudeep.holla@arm.comTested-by: NCristian Marussi <cristian.marussi@arm.com>
Reviewed-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Re-using timed out xfers in a loop can lead to issue if completion was
not properly reinitialized. Move reinit_completion from scmi_xfer_get to
do_xfer to avoid the issue.

Link: https://lore.kernel.org/r/20210606221232.33768-3-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
[sudeep.holla: moved reinit_completion instead of adding another one]
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

A successfully received delayed response could anyway report a failure at
the protocol layer in the message status field.

Add a check also for this error condition.

Link: https://lore.kernel.org/r/20210608103056.3388-1-cristian.marussi@arm.com
Fixes: 58ecdf03 ("firmware: arm_scmi: Add support for asynchronous commands and delayed response")
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

The shared memory node used for communication between the firmware and
the OS should be compatible with "arm,scmi-shmem". Add the check for the
same while parsing the node before fetching the memory regions.

Link: https://lore.kernel.org/r/20210602073851.1005607-2-sudeep.holla@arm.com
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Cristian Marussi <cristian.marussi@arm.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Jim Quinlan <jim2101024@gmail.com>
Cc: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Tested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NCristian Marussi <cristian.marussi@arm.com>
Tested-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

0day CI kernel test robot reported following build error with randconfig

aarch64-linux-ld: drivers/firmware/arm_scmi/driver.o:(.rodata+0x1e0):
		undefined reference to `scmi_mailbox_desc'

Fix the error by adding CONFIG_MAILBOX dependency for scmi_mailbox_desc.

Link: https://lore.kernel.org/r/20210603072631.1660963-1-sudeep.holla@arm.com
Cc: Etienne Carriere <etienne.carriere@linaro.org>
Cc: Cristian Marussi <cristian.marussi@arm.com>
Reviewed-by: NEtienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: NCristian Marussi <cristian.marussi@arm.com>
Tested-by: NCristian Marussi <cristian.marussi@arm.com>
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

During an async commands execution the Rx buffer length is at first set
to max_msg_sz when the synchronous part of the command is first sent.
However once the synchronous part completes the transport layer waits
for the delayed response which will be processed using the same xfer
descriptor initially allocated. Since synchronous response received at
the end of the xfer will shrink the Rx buffer length to the effective
payload response length, it needs to be reset again.

Raise the Rx buffer length again to max_msg_sz before fetching the
delayed response to ensure full response is read correctly from the
shared memory.

Link: https://lore.kernel.org/r/20210601102421.26581-2-cristian.marussi@arm.com
Fixes: 58ecdf03 ("firmware: arm_scmi: Add support for asynchronous commands and delayed response")
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
[sudeep.holla: moved reset to scmi_handle_response as it could race with
               do_xfer_with_response]
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

ARM_SCMI_PROTOCOL depends on either MAILBOX or HAVE_ARM_SMCCC_DISCOVERY,
not MAILBOX alone. Fix the depedency in Kconfig file and driver to
reflect the same.

Link: https://lore.kernel.org/r/20210521134055.24271-1-etienne.carriere@linaro.orgReviewed-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NEtienne Carriere <etienne.carriere@linaro.org>
[sudeep.holla: Minor tweaks to subject and change log]
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Clocks requiring non-atomic contexts are supported by the generic clock
PM layer since commit 0bfa0820 ("PM: clk: make PM clock layer
compatible with clocks that must sleep"). That means we can have
SCMI-based clocks be managed by the SCMI power domain now.

Link: https://lore.kernel.org/r/5q88n947-pon-4940-3or6-s54o4r361o5s@onlyvoer.pbzTested-by: NDien Pham <dien.pham.ry@renesas.com>
Reviewed-by: NGaku Inami <gaku.inami.xh@renesas.com>
Signed-off-by: NNicolas Pitre <npitre@baylibre.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

struct scmi_protocol_handle is declared twice, let us remove the duplicate
declaration.

Link: https://lore.kernel.org/r/20210427033031.4580-1-wanjiabing@vivo.comReviewed-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NWan Jiabing <wanjiabing@vivo.com>
[sudeep.holla: minor updates to the title and the changelog]
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Having added the support for SCMI protocols as modules in order to let
vendors extend the SCMI core with their own additions it seems odd to
then force SCMI drivers built on top to use a static device table to
declare their devices since this way any new SCMI drivers addition
would need the core SCMI device table to be updated too.

Remove the static core device table and let SCMI drivers to simply declare
which device/protocol pair they need at initialization time: the core will
then take care to generate such devices dynamically during platform
initialization or at module loading time, as long as the requested
underlying protocol is defined in the devicetree.

Link: https://lore.kernel.org/r/20210316124903.35011-39-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Extend SCMI protocols accounting mechanism to address possible module
usage and add the support to possibly define new protocols as loadable
modules.

Keep the standard protocols built into the SCMI core.

Link: https://lore.kernel.org/r/20210316124903.35011-38-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Rename non devres managed notify_ops to use a naming pattern which exposes
the performed action verb as last token.

No functional change.

Link: https://lore.kernel.org/r/20210316124903.35011-37-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Notification private data is currently accessible via handle->notify_priv,
this data was indeed meant to be private to the notification core support
and not to be accessible by SCMI drivers. Make it private hiding it
inside instance descriptor struct scmi_info and accessible only via
dedicated helpers.

Link: https://lore.kernel.org/r/20210316124903.35011-36-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Remove all the events registration code used to ease the transition to the
new interface based on protocol handles.

Link: https://lore.kernel.org/r/20210316124903.35011-35-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Remove unused core scmi_xfer wrappers now that we have migrated all
protocols to the new interface based on protocol handles.

Link: https://lore.kernel.org/r/20210316124903.35011-34-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Now that all protocols and drivers have been ported to the new interface
based on protocol handles and get/put operations, remove all the legacy
transient initialization code.

Link: https://lore.kernel.org/r/20210316124903.35011-33-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Now that all the protocol private variable data have been moved out of
struct scmi_handle, mark all of its references as const.

Link: https://lore.kernel.org/r/20210316124903.35011-32-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Now that all the SCMI driver users have been migrated to the new interface
remove the legacy interface and all the transient code.

Link: https://lore.kernel.org/r/20210316124903.35011-31-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Convert internals of protocol implementation to use protocol handles and
expose a new protocol operations interface for SCMI driver using the new
get/put common operations, while keeping the old handle->voltage_ops still
around to ease transition.

Remove handle->voltage_priv now unused.

Link: https://lore.kernel.org/r/20210316124903.35011-29-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Convert internals of protocol implementation to use protocol handles and
expose a new protocol operations interface for SCMI driver using the new
get/put common operations.

Remove handle->system_priv now unused.

Link: https://lore.kernel.org/r/20210316124903.35011-28-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Now that all the SCMI driver users have been migrated to the new interface
remove the legacy interface and all the transient code.

Link: https://lore.kernel.org/r/20210316124903.35011-27-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Convert internals of protocol implementation to use protocol handles and
expose a new protocol operations interface for SCMI driver using the new
get/put common operations, while keeping the old handle->sensor_ops still
around to ease transition.

Remove handle->sensor_priv now unused.

Link: https://lore.kernel.org/r/20210316124903.35011-24-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Now that all the SCMI driver users have been migrated to the new interface
remove the legacy interface and all the transient code.

Link: https://lore.kernel.org/r/20210316124903.35011-23-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Convert internals of protocol implementation to use protocol handles and
expose a new protocol operations interface for SCMI driver using the new
get/put common operations, while keeping the old handle->reset_ops still
around to ease transition.

Remove handle->reset_priv now unused.

Link: https://lore.kernel.org/r/20210316124903.35011-21-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Now that all the SCMI driver users have been migrated to the new interface
remove the legacy interface and all the transient code.

Link: https://lore.kernel.org/r/20210316124903.35011-20-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>