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>

kernel.h is being used as a dump for all kinds of stuff for a long time.
Here is the attempt to start cleaning it up by splitting out panic and
oops helpers.

There are several purposes of doing this:
- dropping dependency in bug.h
- dropping a loop by moving out panic_notifier.h
- unload kernel.h from something which has its own domain

At the same time convert users tree-wide to use new headers, although for
the time being include new header back to kernel.h to avoid twisted
indirected includes for existing users.

[akpm@linux-foundation.org: thread_info.h needs limits.h]
[andriy.shevchenko@linux.intel.com: ia64 fix]
  Link: https://lkml.kernel.org/r/20210520130557.55277-1-andriy.shevchenko@linux.intel.com

Link: https://lkml.kernel.org/r/20210511074137.33666-1-andriy.shevchenko@linux.intel.comSigned-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Co-developed-by: NAndrew Morton <akpm@linux-foundation.org>
Acked-by: NMike Rapoport <rppt@linux.ibm.com>
Acked-by: NCorey Minyard <cminyard@mvista.com>
Acked-by: NChristian Brauner <christian.brauner@ubuntu.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NKees Cook <keescook@chromium.org>
Acked-by: NWei Liu <wei.liu@kernel.org>
Acked-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Acked-by: NSebastian Reichel <sre@kernel.org>
Acked-by: NLuis Chamberlain <mcgrof@kernel.org>
Acked-by: NStephen Boyd <sboyd@kernel.org>
Acked-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>
Acked-by: Helge Deller <deller@gmx.de> # parisc
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

fw_cfg_showrev() is called by an indirect call in kobj_attr_show(),
which violates clang's CFI checking because fw_cfg_showrev()'s second
parameter is 'struct attribute', whereas the ->show() member of 'struct
kobj_structure' expects the second parameter to be of type 'struct
kobj_attribute'.

$ cat /sys/firmware/qemu_fw_cfg/rev
3

$ dmesg | grep "CFI failure"
[   26.016832] CFI failure (target: fw_cfg_showrev+0x0/0x8):

Fix this by converting fw_cfg_rev_attr to 'struct kobj_attribute' where
this would have been caught automatically by the incompatible pointer
types compiler warning. Update fw_cfg_showrev() accordingly.

Fixes: 75f3e8e4 ("firmware: introduce sysfs driver for QEMU's fw_cfg device")
Link: https://github.com/ClangBuiltLinux/linux/issues/1299Signed-off-by: NNathan Chancellor <nathan@kernel.org>
Reviewed-by: NSami Tolvanen <samitolvanen@google.com>
Tested-by: NSedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: NSami Tolvanen <samitolvanen@google.com>
Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: NKees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210211194258.4137998-1-nathan@kernel.org

The PSCI CPU suspend code isn't aware of the PMR vs DAIF game,
resulting in a system that locks up if entering CPU suspend
with GICv3 pNMI enabled.

To save the day, teach the suspend code about our new cpuidle
context helpers, which will do everything that's required just
like the usual WFI cpuidle code.

This fixes my Altra system, which would otherwise lock-up at
boot time when booted with irqchip.gicv3_pseudo_nmi=1.
Tested-by: NValentin Schneider <valentin.schneider@arm.com>
Reviewed-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Reviewed-by: NSudeep Holla <sudeep.holla@arm.com>
Link: https://lore.kernel.org/r/20210615111227.2454465-4-maz@kernel.orgSigned-off-by: NWill Deacon <will@kernel.org>

Add more generic compatible string 'marvell,armada-3700-rwtm-firmware' for
this driver, since it can also be used on other Armada 3720 devices.

Current compatible string 'cznic,turris-mox-rwtm' is kept for backward
compatibility.
Signed-off-by: NPali Rohár <pali@kernel.org>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NGregory CLEMENT <gregory.clement@bootlin.com>

Currently it is hard to determinate if on Armada 3720 device is HWRNG
by running kernel accessible or not. So print information message into
dmesg when HWRNG is available and registration was successful.

Fixes: 389711b3 ("firmware: Add Turris Mox rWTM firmware driver")
Signed-off-by: NPali Rohár <pali@kernel.org>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NGregory CLEMENT <gregory.clement@bootlin.com>

When Marvell's rWTM firmware, which does not support the GET_RANDOM
command, is used, kernel prints an error message
  hwrng: no data available
every 10 seconds.

Fail probing of this driver if the rWTM firmware does not support the
GET_RANDOM command.

Fixes: 389711b3 ("firmware: Add Turris Mox rWTM firmware driver")
Signed-off-by: NPali Rohár <pali@kernel.org>
Signed-off-by: NMarek Behún <kabel@kernel.org>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NGregory CLEMENT <gregory.clement@bootlin.com>

Report a notice level message if a command is not supported by the rWTM
firmware.

This should not be an error, merely a notice, because the firmware can
be used on boards that do not have manufacturing information burned.

Fixes: 389711b3 ("firmware: Add Turris Mox rWTM firmware driver")
Signed-off-by: NMarek Behún <kabel@kernel.org>
Reviewed-by: NPali Rohár <pali@kernel.org>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NGregory CLEMENT <gregory.clement@bootlin.com>

The status decoding function mox_get_status() currently contains an
incorrect check: if the error status is not MBOX_STS_SUCCESS, it always
returns -EIO, so the comparison to MBOX_STS_FAIL is never executed and
we don't get the actual error code sent by the firmware.

Fix this.
Signed-off-by: NMarek Behún <kabel@kernel.org>
Reviewed-by: NPali Rohár <pali@kernel.org>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Fixes: 389711b3 ("firmware: Add Turris Mox rWTM firmware driver")
Signed-off-by: NGregory CLEMENT <gregory.clement@bootlin.com>

Register with kernel restart handler instead of setting arm_pm_restart
directly. This enables support for replacing the PSCI restart handler
with a different handler if necessary for a specific board.

Select a priority of 129 to indicate a higher than default priority, but
keep it as low as possible since PSCI reset is known to fail on some
boards.
Acked-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

The tegra186_bpmp_ops symbol is used on Tegra234, so make sure it's
available.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Add a compatible for MDM9607. It uses the "legacy" calling
convention.
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NKonrad Dybcio <konrad.dybcio@somainline.org>
Link: https://lore.kernel.org/r/20210131013058.54299-1-konrad.dybcio@somainline.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

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>

SMCCC v1.2 requires that all SVE state be preserved over SMC calls which
introduces substantial overhead in the common case where there is no SVE
state in the registers. To avoid this SMCCC v1.3 introduces a flag which
allows the caller to say that there is no state that needs to be preserved
in the registers. Make use of this flag, setting it if the SMCCC version
indicates support for it and the TIF_ flags indicate that there is no live
SVE state in the registers, this avoids placing any constraints on when
SMCCC calls can be done or triggering extra saving and reloading of SVE
register state in the kernel.

This would be straightforward enough except for the rather entertaining
inline assembly we use to do SMCCC v1.1 calls to allow us to take advantage
of the limited number of registers it clobbers. Deal with this by having a
function which we call immediately before issuing the SMCCC call to make
our checks and set the flag. Using alternatives the overhead if SVE is
supported but not detected at runtime can be reduced to a single NOP.
Signed-off-by: NMark Brown <broonie@kernel.org>
Reviewed-by: NArd Biesheuvel <ardb@kernel.org>
Reviewed-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210603184118.15090-1-broonie@kernel.orgSigned-off-by: NWill Deacon <will@kernel.org>

The shared memory node used for communication between the firmware and
the OS should be compatible with one of the following:
	- amlogic,meson-gxbb-scp-shmem
	- amlogic,meson-axg-scp-shmem
	- arm,juno-scp-shmem
	- arm,scp-shmem
Add the check for the same while parsing the node before fetching the memory
regions.

Link: https://lore.kernel.org/r/20210602073851.1005607-1-sudeep.holla@arm.com
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Jerome Brunet <jbrunet@baylibre.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>

When call irq_get_irq_data() to get the IRQ's irq_data failed, an
appropriate error code -ENOENT should be returned. However, we directly
return 'err', which records the IRQ number instead of the error code.

Fixes: 139251fc ("firmware: tegra: add bpmp driver for Tegra210")
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

If an error occurs after a successful 'kfifo_alloc()' call, it must be
undone by a corresponding 'kfifo_free()' call, as already done in the
remove function.

While at it, move the 'platform_device_put()' call to this new error
handling path and explicitly return 0 in the success path.

Fixes: b5dc75c9 ("firmware: stratix10-svc: extend svc to support new RSU features")
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/0ca3f3ab139c53e846804455a1e7599ee8ae896a.1621621271.git.christophe.jaillet@wanadoo.frSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Most of the MEM_* APIs share the same parameters, so they can be
generalised. Currently only MEM_SHARE is implemented and the user space
interface for that is not added yet.

Link: https://lore.kernel.org/r/20210521151033.181846-6-sudeep.holla@arm.comTested-by: NJens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Parse the FFA nodes from the device-tree and register all the partitions
whose services will be used in the kernel.

In order to also enable in-kernel users of FFA interface, let us add
simple set of operations for such devices.

The in-kernel users are registered without the character device interface.

Link: https://lore.kernel.org/r/20210521151033.181846-5-sudeep.holla@arm.comTested-by: NJens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: NJens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

There are requests to keep the transport separate in order to allow
other possible transports like virtio. So let us keep the SMCCC transport
specific routines abstracted.

It is kept simple for now. Once we add another transport, we can develop
better abstraction.

Link: https://lore.kernel.org/r/20210521151033.181846-4-sudeep.holla@arm.comTested-by: NJens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: NJens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>