* [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
@ 2022-10-19 20:46 ` Cristian Marussi
0 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
Hi all,
This series aims to introduce a new SCMI unified userspace interface meant
to ease testing an SCMI Server implementation for compliance, fuzzing etc.,
from the perspective of the OSPM agent (non-secure world only ...)
It is proposed as a testing/development facility, it is NOT meant to be a
feature to use in production, but only enabled in Kconfig for test
deployments.
Currently an SCMI Compliance Suite like the one at [1] can only work by
injecting SCMI messages at the SCMI transport layer using the mailbox test
driver (CONFIG_MAILBOX_TEST) via its few debugfs entries and looking at
the related replies from the SCMI backend Server.
This approach has a few drawbacks:
- the SCMI Server under test MUST be reachable through a mailbox based
SCMI transport: any other SCMI Server placement is not possible (like in
a VM reachable via SCMI Virtio). In order to cover other placements in
the current scenario we should write some sort of test driver for each
and every existent SCMI transport and for any future additional transport
...this clearly does not scale.
- even in the mailbox case the userspace Compliance suite cannot simply
send and receive bare SCMI messages BUT it has to properly lay them out
into the shared memory exposed by the mailbox test driver as expected by
the transport definitions. In other words such a userspace test
application has to, not only use a proper transport driver for the system
at hand, but it also has to have a comprehensive knowledge of the
internals of the underlying transport in order to operate.
- last but not least, the system under test has to be specifically
configured and built, in terms of Kconfig and DT, to perform such kind of
testing, it cannot be used for anything else, which is unfortunate for
CI/CD deployments.
This series introduces a new SCMI Raw mode support feature that, when
configured and enabled exposes a new interface in debugfs through which:
- a userspace application can inject bare SCMI binary messages into the
SCMI core stack; such messages will be routed by the SCMI regular kernel
stack to the backend Server using the currently configured transport
transparently: in other words you can test the SCMI server, no matter
where it is placed, as long as it is reachable from the currently
configured SCMI stack.
Same goes the other way around on the reading path: any SCMI server reply
can be read as a bare SCMI binary message from the same debugfs path.
- as a direct consequence of this way of injecting bare messages in the
middle of the SCMI stack (instead of beneath it at the transport layer)
the user application has to handle only bare SCMI messages without having
to worry about the specific underlying transport internals that will be
taken care of by the SCMI core stack itself using its own machinery,
without duplicating such logic.
- a system under test, once configured with SCMI Raw support enabled in
Kconfig, can be booted without any particular DT change.
In V2 the runtime enable/disable switching capability has been removed
(for now) since still not deemed to be stable/reliable enough: as a
consequence when SCMI Raw support is compiled in, the regular SCMI stack
drivers are now inhibited permanently for that Kernel.
In V4 it has been added the support for transports lacking a completion_irq
or configured forcibly in polled mode.
A quick and trivial example from the shell...reading from a sensor
injecting a properly crafted packet in raw mode:
# INJECT THE SENSOR_READING MESSAGE FOR SENSOR ID=1 (binary little endian)
root@deb-buster-arm64:~# echo -e -n \\x06\\x54\\x00\\x00\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x00 > /sys/kernel/debug/scmi_raw/message
# READING BACK THE REPLY...
root@deb-buster-arm64:~# cat /sys/kernel/debug/scmi_raw/message | od --endian=little -t x4
0000000 00005406 00000000 00000335 00000000
0000020
while doing that, since Raw mode makes (partial) use of the regular SCMI
stack, you can observe the messages going through the SCMI stack with the
usual traces:
bash-329 [000] ..... 14183.446808: scmi_msg_dump: pt=15 t=CMND msg_id=06 seq=0000 s=0 pyld=0100000000000000
irq/35-mhu_db_l-81 [000] ..... 14183.447809: scmi_msg_dump: pt=15 t=RESP msg_id=06 seq=0000 s=0 pyld=3503000000000000
..trying to read in async when the backend server does NOT supports asyncs:
# AN ASYNC SENSOR READING REQUEST...
root@deb-buster-arm64:~# echo -e -n \\x06\\x54\\x00\\x00\\x01\\x00\\x00\\x00\\x01\\x00\\x00\\x00 > /sys/kernel/debug/scmi_raw/message_async
bash-329 [000] ..... 16415.938739: scmi_msg_dump: pt=15 t=CMND msg_id=06 seq=0000 s=0 pyld=0100000001000000
irq/35-mhu_db_l-81 [000] ..... 16415.944129: scmi_msg_dump: pt=15 t=RESP msg_id=06 seq=0000 s=-1 pyld=
# RETURNS A STATUS -1 FROM THE SERVER NOT SUPPORTING IT
root@deb-buster-arm64:~# cat /sys/kernel/debug/scmi_raw/message | od --endian=little -t x4
0000000 00005406 ffffffff
0000010
Note that this was on a JUNO, BUT exactly the same steps can be used to
reach an SCMI Server living on a VM reachable via virtio as long as the
system under test if properly configured to work with a virtio transport.
In a nutshell the exposed API is as follows:
/sys/kernel/debug/scmi_raw/
├── errors
├── message
├── message_async
├── notification
├── reset
├── transport_max_msg_size
├── transport_rx_timeout_ms
└── transport_tx_max_msg
where:
- message*: used to send sync/async commands and read back immediate and
delayed responses (if any)
- errors: used to report timeout and unexpected replies
- reset: used to reset the SCMI Raw stack, flushing all queues from
received messages still pending to be read out (useful to be sure to
cleanup between test suite runs...)
- notification: used to read any notification being spit by the system
(if previously enabled by the user app)
- transport*: a bunch of configuration useful to setup the user
application expectations in terms of timeouts and message
characteristics.
Each write corresponds to one command request and the replies or delayed
response are read back one message at time (receiving an EOF at each
message boundary).
The user application running the test is in charge of handling timeouts
and properly choosing SCMI sequence numbers for the outgoing requests: note
that the same fixed number can be re-used (...though discouraged...) as
long as the suite does NOT expect to send multiple in-flight commands
concurrently.
Since the SCMI core regular stack is partially used to deliver and collect
the messages, late replies after timeouts and any other sort of unexpected
message sent by the SCMI server platform back can be identified by the SCMI
core as usual and it will be reported under /errors for later analysis.
(a userspace test-app will have anyway properly detected the timeout on
/message* ...)
All of the above has been roughly tested against a standard JUNO SCP SCMI
Server (mailbox trans) and an emulated SCMI Server living in a VM (virtio
trans) using a custom experimental version of the scmi-tests Compliance
suite patched to support Raw mode and posted at [2]. (still in development
...merge requests are in progress...for now it is just a mean for me to
test the testing API ... O_o)
The series is based on v6.1-rc1.
Having said that (in such a concise and brief way :P) ...
...any feedback/comments are welcome !
Thanks,
Cristian
---
V3 --> v4
- rebased on v6.1-rc1
- addedd missing support for 'polled' transports and transport lacking a
completion_irq (like smc/optee)
- removed a few inlines
- refactored SCMI Raw RX patch to make use more extensively of the regular
non-Raw RX path
- fix handling of O_NONBLOCK raw_mode read requests
v2 --> v3
- fixed some sparse warning on LE and __poll_t
- reworked and simplified deferred worker in charge of xfer delayed waiting
- allow for injection of DT-unknown protocols messages when in Raw mode
(needed for any kind of fuzzing...)
v1 --> v2
- added comments and debugfs docs
- added dedicated transport devices for channels initialization
- better channels handling in Raw mode
- removed runtime enable, moved to static compile time exclusion
of SCMI regular stack
[1]: https://gitlab.arm.com/tests/scmi-tests
[2]: https://gitlab.arm.com/tests/scmi-tests/-/commits/raw_mode_support_devel/
Cristian Marussi (11):
firmware: arm_scmi: Refactor xfer in-flight registration routines
firmware: arm_scmi: Simplify chan_available transport operation
firmware: arm_scmi: Use dedicated devices to initialize channels
firmware: arm_scmi: Refactor polling helpers
firmware: arm_scmi: Refactor scmi_wait_for_message_response
firmware: arm_scmi: Add xfer raw helpers
firmware: arm_scmi: Move errors defs and code to common.h
firmware: arm_scmi: Add raw transmission support
firmware: arm_scmi: Add debugfs ABI documentation for Raw mode
firmware: arm_scmi: Reject SCMI drivers while in Raw mode
firmware: arm_scmi: Call Raw mode hooks from the core stack
Documentation/ABI/testing/debugfs-scmi-raw | 88 ++
drivers/firmware/arm_scmi/Kconfig | 13 +
drivers/firmware/arm_scmi/Makefile | 1 +
drivers/firmware/arm_scmi/common.h | 72 +-
drivers/firmware/arm_scmi/driver.c | 521 +++++---
drivers/firmware/arm_scmi/mailbox.c | 4 +-
drivers/firmware/arm_scmi/optee.c | 4 +-
drivers/firmware/arm_scmi/raw_mode.c | 1244 ++++++++++++++++++++
drivers/firmware/arm_scmi/raw_mode.h | 29 +
drivers/firmware/arm_scmi/smc.c | 4 +-
drivers/firmware/arm_scmi/virtio.c | 2 +-
11 files changed, 1827 insertions(+), 155 deletions(-)
create mode 100644 Documentation/ABI/testing/debugfs-scmi-raw
create mode 100644 drivers/firmware/arm_scmi/raw_mode.c
create mode 100644 drivers/firmware/arm_scmi/raw_mode.h
--
2.34.1
^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
@ 2022-10-19 20:46 ` Cristian Marussi
0 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
Hi all,
This series aims to introduce a new SCMI unified userspace interface meant
to ease testing an SCMI Server implementation for compliance, fuzzing etc.,
from the perspective of the OSPM agent (non-secure world only ...)
It is proposed as a testing/development facility, it is NOT meant to be a
feature to use in production, but only enabled in Kconfig for test
deployments.
Currently an SCMI Compliance Suite like the one at [1] can only work by
injecting SCMI messages at the SCMI transport layer using the mailbox test
driver (CONFIG_MAILBOX_TEST) via its few debugfs entries and looking at
the related replies from the SCMI backend Server.
This approach has a few drawbacks:
- the SCMI Server under test MUST be reachable through a mailbox based
SCMI transport: any other SCMI Server placement is not possible (like in
a VM reachable via SCMI Virtio). In order to cover other placements in
the current scenario we should write some sort of test driver for each
and every existent SCMI transport and for any future additional transport
...this clearly does not scale.
- even in the mailbox case the userspace Compliance suite cannot simply
send and receive bare SCMI messages BUT it has to properly lay them out
into the shared memory exposed by the mailbox test driver as expected by
the transport definitions. In other words such a userspace test
application has to, not only use a proper transport driver for the system
at hand, but it also has to have a comprehensive knowledge of the
internals of the underlying transport in order to operate.
- last but not least, the system under test has to be specifically
configured and built, in terms of Kconfig and DT, to perform such kind of
testing, it cannot be used for anything else, which is unfortunate for
CI/CD deployments.
This series introduces a new SCMI Raw mode support feature that, when
configured and enabled exposes a new interface in debugfs through which:
- a userspace application can inject bare SCMI binary messages into the
SCMI core stack; such messages will be routed by the SCMI regular kernel
stack to the backend Server using the currently configured transport
transparently: in other words you can test the SCMI server, no matter
where it is placed, as long as it is reachable from the currently
configured SCMI stack.
Same goes the other way around on the reading path: any SCMI server reply
can be read as a bare SCMI binary message from the same debugfs path.
- as a direct consequence of this way of injecting bare messages in the
middle of the SCMI stack (instead of beneath it at the transport layer)
the user application has to handle only bare SCMI messages without having
to worry about the specific underlying transport internals that will be
taken care of by the SCMI core stack itself using its own machinery,
without duplicating such logic.
- a system under test, once configured with SCMI Raw support enabled in
Kconfig, can be booted without any particular DT change.
In V2 the runtime enable/disable switching capability has been removed
(for now) since still not deemed to be stable/reliable enough: as a
consequence when SCMI Raw support is compiled in, the regular SCMI stack
drivers are now inhibited permanently for that Kernel.
In V4 it has been added the support for transports lacking a completion_irq
or configured forcibly in polled mode.
A quick and trivial example from the shell...reading from a sensor
injecting a properly crafted packet in raw mode:
# INJECT THE SENSOR_READING MESSAGE FOR SENSOR ID=1 (binary little endian)
root@deb-buster-arm64:~# echo -e -n \\x06\\x54\\x00\\x00\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x00 > /sys/kernel/debug/scmi_raw/message
# READING BACK THE REPLY...
root@deb-buster-arm64:~# cat /sys/kernel/debug/scmi_raw/message | od --endian=little -t x4
0000000 00005406 00000000 00000335 00000000
0000020
while doing that, since Raw mode makes (partial) use of the regular SCMI
stack, you can observe the messages going through the SCMI stack with the
usual traces:
bash-329 [000] ..... 14183.446808: scmi_msg_dump: pt=15 t=CMND msg_id=06 seq=0000 s=0 pyld=0100000000000000
irq/35-mhu_db_l-81 [000] ..... 14183.447809: scmi_msg_dump: pt=15 t=RESP msg_id=06 seq=0000 s=0 pyld=3503000000000000
..trying to read in async when the backend server does NOT supports asyncs:
# AN ASYNC SENSOR READING REQUEST...
root@deb-buster-arm64:~# echo -e -n \\x06\\x54\\x00\\x00\\x01\\x00\\x00\\x00\\x01\\x00\\x00\\x00 > /sys/kernel/debug/scmi_raw/message_async
bash-329 [000] ..... 16415.938739: scmi_msg_dump: pt=15 t=CMND msg_id=06 seq=0000 s=0 pyld=0100000001000000
irq/35-mhu_db_l-81 [000] ..... 16415.944129: scmi_msg_dump: pt=15 t=RESP msg_id=06 seq=0000 s=-1 pyld=
# RETURNS A STATUS -1 FROM THE SERVER NOT SUPPORTING IT
root@deb-buster-arm64:~# cat /sys/kernel/debug/scmi_raw/message | od --endian=little -t x4
0000000 00005406 ffffffff
0000010
Note that this was on a JUNO, BUT exactly the same steps can be used to
reach an SCMI Server living on a VM reachable via virtio as long as the
system under test if properly configured to work with a virtio transport.
In a nutshell the exposed API is as follows:
/sys/kernel/debug/scmi_raw/
├── errors
├── message
├── message_async
├── notification
├── reset
├── transport_max_msg_size
├── transport_rx_timeout_ms
└── transport_tx_max_msg
where:
- message*: used to send sync/async commands and read back immediate and
delayed responses (if any)
- errors: used to report timeout and unexpected replies
- reset: used to reset the SCMI Raw stack, flushing all queues from
received messages still pending to be read out (useful to be sure to
cleanup between test suite runs...)
- notification: used to read any notification being spit by the system
(if previously enabled by the user app)
- transport*: a bunch of configuration useful to setup the user
application expectations in terms of timeouts and message
characteristics.
Each write corresponds to one command request and the replies or delayed
response are read back one message at time (receiving an EOF at each
message boundary).
The user application running the test is in charge of handling timeouts
and properly choosing SCMI sequence numbers for the outgoing requests: note
that the same fixed number can be re-used (...though discouraged...) as
long as the suite does NOT expect to send multiple in-flight commands
concurrently.
Since the SCMI core regular stack is partially used to deliver and collect
the messages, late replies after timeouts and any other sort of unexpected
message sent by the SCMI server platform back can be identified by the SCMI
core as usual and it will be reported under /errors for later analysis.
(a userspace test-app will have anyway properly detected the timeout on
/message* ...)
All of the above has been roughly tested against a standard JUNO SCP SCMI
Server (mailbox trans) and an emulated SCMI Server living in a VM (virtio
trans) using a custom experimental version of the scmi-tests Compliance
suite patched to support Raw mode and posted at [2]. (still in development
...merge requests are in progress...for now it is just a mean for me to
test the testing API ... O_o)
The series is based on v6.1-rc1.
Having said that (in such a concise and brief way :P) ...
...any feedback/comments are welcome !
Thanks,
Cristian
---
V3 --> v4
- rebased on v6.1-rc1
- addedd missing support for 'polled' transports and transport lacking a
completion_irq (like smc/optee)
- removed a few inlines
- refactored SCMI Raw RX patch to make use more extensively of the regular
non-Raw RX path
- fix handling of O_NONBLOCK raw_mode read requests
v2 --> v3
- fixed some sparse warning on LE and __poll_t
- reworked and simplified deferred worker in charge of xfer delayed waiting
- allow for injection of DT-unknown protocols messages when in Raw mode
(needed for any kind of fuzzing...)
v1 --> v2
- added comments and debugfs docs
- added dedicated transport devices for channels initialization
- better channels handling in Raw mode
- removed runtime enable, moved to static compile time exclusion
of SCMI regular stack
[1]: https://gitlab.arm.com/tests/scmi-tests
[2]: https://gitlab.arm.com/tests/scmi-tests/-/commits/raw_mode_support_devel/
Cristian Marussi (11):
firmware: arm_scmi: Refactor xfer in-flight registration routines
firmware: arm_scmi: Simplify chan_available transport operation
firmware: arm_scmi: Use dedicated devices to initialize channels
firmware: arm_scmi: Refactor polling helpers
firmware: arm_scmi: Refactor scmi_wait_for_message_response
firmware: arm_scmi: Add xfer raw helpers
firmware: arm_scmi: Move errors defs and code to common.h
firmware: arm_scmi: Add raw transmission support
firmware: arm_scmi: Add debugfs ABI documentation for Raw mode
firmware: arm_scmi: Reject SCMI drivers while in Raw mode
firmware: arm_scmi: Call Raw mode hooks from the core stack
Documentation/ABI/testing/debugfs-scmi-raw | 88 ++
drivers/firmware/arm_scmi/Kconfig | 13 +
drivers/firmware/arm_scmi/Makefile | 1 +
drivers/firmware/arm_scmi/common.h | 72 +-
drivers/firmware/arm_scmi/driver.c | 521 +++++---
drivers/firmware/arm_scmi/mailbox.c | 4 +-
drivers/firmware/arm_scmi/optee.c | 4 +-
drivers/firmware/arm_scmi/raw_mode.c | 1244 ++++++++++++++++++++
drivers/firmware/arm_scmi/raw_mode.h | 29 +
drivers/firmware/arm_scmi/smc.c | 4 +-
drivers/firmware/arm_scmi/virtio.c | 2 +-
11 files changed, 1827 insertions(+), 155 deletions(-)
create mode 100644 Documentation/ABI/testing/debugfs-scmi-raw
create mode 100644 drivers/firmware/arm_scmi/raw_mode.c
create mode 100644 drivers/firmware/arm_scmi/raw_mode.h
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH v4 01/11] firmware: arm_scmi: Refactor xfer in-flight registration routines
2022-10-19 20:46 ` Cristian Marussi
@ 2022-10-19 20:46 ` Cristian Marussi
-1 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
Move the whole xfer in-flight registration process out of scmi_xfer_get
and while at that, split the sequence number selection steps from the
in-flight registration procedure itself.
No functional change.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
drivers/firmware/arm_scmi/driver.c | 102 +++++++++++++++++++----------
1 file changed, 68 insertions(+), 34 deletions(-)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 609ebedee9cb..e5193da2ce09 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -311,8 +311,6 @@ static int scmi_xfer_token_set(struct scmi_xfers_info *minfo,
if (xfer_id != next_token)
atomic_add((int)(xfer_id - next_token), &transfer_last_id);
- /* Set in-flight */
- set_bit(xfer_id, minfo->xfer_alloc_table);
xfer->hdr.seq = (u16)xfer_id;
return 0;
@@ -330,33 +328,77 @@ static inline void scmi_xfer_token_clear(struct scmi_xfers_info *minfo,
clear_bit(xfer->hdr.seq, minfo->xfer_alloc_table);
}
+/**
+ * scmi_xfer_inflight_register_unlocked - Register the xfer as in-flight
+ *
+ * @xfer: The xfer to register
+ * @minfo: Pointer to Tx/Rx Message management info based on channel type
+ *
+ * Note that this helper assumes that the xfer to be registered as in-flight
+ * had been built using an xfer sequence number which still corresponds to a
+ * free slot in the xfer_alloc_table.
+ *
+ * Context: Assumes to be called with @xfer_lock already acquired.
+ */
+static inline void
+scmi_xfer_inflight_register_unlocked(struct scmi_xfer *xfer,
+ struct scmi_xfers_info *minfo)
+{
+ /* Set in-flight */
+ set_bit(xfer->hdr.seq, minfo->xfer_alloc_table);
+ hash_add(minfo->pending_xfers, &xfer->node, xfer->hdr.seq);
+ xfer->pending = true;
+}
+
+/**
+ * scmi_xfer_pending_set - Pick a proper sequence number and mark the xfer
+ * as pending in-flight
+ *
+ * @xfer: The xfer to act upon
+ * @minfo: Pointer to Tx/Rx Message management info based on channel type
+ *
+ * Return: 0 on Success or error otherwise
+ */
+static inline int scmi_xfer_pending_set(struct scmi_xfer *xfer,
+ struct scmi_xfers_info *minfo)
+{
+ int ret;
+ unsigned long flags;
+
+ spin_lock_irqsave(&minfo->xfer_lock, flags);
+ /* Set a new monotonic token as the xfer sequence number */
+ ret = scmi_xfer_token_set(minfo, xfer);
+ if (!ret)
+ scmi_xfer_inflight_register_unlocked(xfer, minfo);
+ spin_unlock_irqrestore(&minfo->xfer_lock, flags);
+
+ return ret;
+}
+
/**
* scmi_xfer_get() - Allocate one message
*
* @handle: Pointer to SCMI entity handle
* @minfo: Pointer to Tx/Rx Message management info based on channel type
- * @set_pending: If true a monotonic token is picked and the xfer is added to
- * the pending hash table.
*
* Helper function which is used by various message functions that are
* exposed to clients of this driver for allocating a message traffic event.
*
- * Picks an xfer from the free list @free_xfers (if any available) and, if
- * required, sets a monotonically increasing token and stores the inflight xfer
- * into the @pending_xfers hashtable for later retrieval.
+ * Picks an xfer from the free list @free_xfers (if any available) and perform
+ * a basic initialization.
+ *
+ * Note that, at this point, still no sequence number is assigned to the
+ * allocated xfer, nor it is registered as a pending transaction.
*
* The successfully initialized xfer is refcounted.
*
- * Context: Holds @xfer_lock while manipulating @xfer_alloc_table and
- * @free_xfers.
+ * Context: Holds @xfer_lock while manipulating @free_xfers.
*
- * Return: 0 if all went fine, else corresponding error.
+ * Return: An initialized xfer if all went fine, else pointer error.
*/
static struct scmi_xfer *scmi_xfer_get(const struct scmi_handle *handle,
- struct scmi_xfers_info *minfo,
- bool set_pending)
+ struct scmi_xfers_info *minfo)
{
- int ret;
unsigned long flags;
struct scmi_xfer *xfer;
@@ -376,25 +418,8 @@ static struct scmi_xfer *scmi_xfer_get(const struct scmi_handle *handle,
*/
xfer->transfer_id = atomic_inc_return(&transfer_last_id);
- if (set_pending) {
- /* Pick and set monotonic token */
- ret = scmi_xfer_token_set(minfo, xfer);
- if (!ret) {
- hash_add(minfo->pending_xfers, &xfer->node,
- xfer->hdr.seq);
- xfer->pending = true;
- } else {
- dev_err(handle->dev,
- "Failed to get monotonic token %d\n", ret);
- hlist_add_head(&xfer->node, &minfo->free_xfers);
- xfer = ERR_PTR(ret);
- }
- }
-
- if (!IS_ERR(xfer)) {
- refcount_set(&xfer->users, 1);
- atomic_set(&xfer->busy, SCMI_XFER_FREE);
- }
+ refcount_set(&xfer->users, 1);
+ atomic_set(&xfer->busy, SCMI_XFER_FREE);
spin_unlock_irqrestore(&minfo->xfer_lock, flags);
return xfer;
@@ -652,7 +677,7 @@ static void scmi_handle_notification(struct scmi_chan_info *cinfo,
ktime_t ts;
ts = ktime_get_boottime();
- xfer = scmi_xfer_get(cinfo->handle, minfo, false);
+ xfer = scmi_xfer_get(cinfo->handle, minfo);
if (IS_ERR(xfer)) {
dev_err(dev, "failed to get free message slot (%ld)\n",
PTR_ERR(xfer));
@@ -1041,13 +1066,22 @@ static int xfer_get_init(const struct scmi_protocol_handle *ph,
tx_size > info->desc->max_msg_size)
return -ERANGE;
- xfer = scmi_xfer_get(pi->handle, minfo, true);
+ xfer = scmi_xfer_get(pi->handle, minfo);
if (IS_ERR(xfer)) {
ret = PTR_ERR(xfer);
dev_err(dev, "failed to get free message slot(%d)\n", ret);
return ret;
}
+ /* Pick a sequence number and register this xfer as in-flight */
+ ret = scmi_xfer_pending_set(xfer, minfo);
+ if (ret) {
+ dev_err(pi->handle->dev,
+ "Failed to get monotonic token %d\n", ret);
+ __scmi_xfer_put(minfo, xfer);
+ return ret;
+ }
+
xfer->tx.len = tx_size;
xfer->rx.len = rx_size ? : info->desc->max_msg_size;
xfer->hdr.type = MSG_TYPE_COMMAND;
--
2.34.1
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v4 01/11] firmware: arm_scmi: Refactor xfer in-flight registration routines
@ 2022-10-19 20:46 ` Cristian Marussi
0 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
Move the whole xfer in-flight registration process out of scmi_xfer_get
and while at that, split the sequence number selection steps from the
in-flight registration procedure itself.
No functional change.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
drivers/firmware/arm_scmi/driver.c | 102 +++++++++++++++++++----------
1 file changed, 68 insertions(+), 34 deletions(-)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 609ebedee9cb..e5193da2ce09 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -311,8 +311,6 @@ static int scmi_xfer_token_set(struct scmi_xfers_info *minfo,
if (xfer_id != next_token)
atomic_add((int)(xfer_id - next_token), &transfer_last_id);
- /* Set in-flight */
- set_bit(xfer_id, minfo->xfer_alloc_table);
xfer->hdr.seq = (u16)xfer_id;
return 0;
@@ -330,33 +328,77 @@ static inline void scmi_xfer_token_clear(struct scmi_xfers_info *minfo,
clear_bit(xfer->hdr.seq, minfo->xfer_alloc_table);
}
+/**
+ * scmi_xfer_inflight_register_unlocked - Register the xfer as in-flight
+ *
+ * @xfer: The xfer to register
+ * @minfo: Pointer to Tx/Rx Message management info based on channel type
+ *
+ * Note that this helper assumes that the xfer to be registered as in-flight
+ * had been built using an xfer sequence number which still corresponds to a
+ * free slot in the xfer_alloc_table.
+ *
+ * Context: Assumes to be called with @xfer_lock already acquired.
+ */
+static inline void
+scmi_xfer_inflight_register_unlocked(struct scmi_xfer *xfer,
+ struct scmi_xfers_info *minfo)
+{
+ /* Set in-flight */
+ set_bit(xfer->hdr.seq, minfo->xfer_alloc_table);
+ hash_add(minfo->pending_xfers, &xfer->node, xfer->hdr.seq);
+ xfer->pending = true;
+}
+
+/**
+ * scmi_xfer_pending_set - Pick a proper sequence number and mark the xfer
+ * as pending in-flight
+ *
+ * @xfer: The xfer to act upon
+ * @minfo: Pointer to Tx/Rx Message management info based on channel type
+ *
+ * Return: 0 on Success or error otherwise
+ */
+static inline int scmi_xfer_pending_set(struct scmi_xfer *xfer,
+ struct scmi_xfers_info *minfo)
+{
+ int ret;
+ unsigned long flags;
+
+ spin_lock_irqsave(&minfo->xfer_lock, flags);
+ /* Set a new monotonic token as the xfer sequence number */
+ ret = scmi_xfer_token_set(minfo, xfer);
+ if (!ret)
+ scmi_xfer_inflight_register_unlocked(xfer, minfo);
+ spin_unlock_irqrestore(&minfo->xfer_lock, flags);
+
+ return ret;
+}
+
/**
* scmi_xfer_get() - Allocate one message
*
* @handle: Pointer to SCMI entity handle
* @minfo: Pointer to Tx/Rx Message management info based on channel type
- * @set_pending: If true a monotonic token is picked and the xfer is added to
- * the pending hash table.
*
* Helper function which is used by various message functions that are
* exposed to clients of this driver for allocating a message traffic event.
*
- * Picks an xfer from the free list @free_xfers (if any available) and, if
- * required, sets a monotonically increasing token and stores the inflight xfer
- * into the @pending_xfers hashtable for later retrieval.
+ * Picks an xfer from the free list @free_xfers (if any available) and perform
+ * a basic initialization.
+ *
+ * Note that, at this point, still no sequence number is assigned to the
+ * allocated xfer, nor it is registered as a pending transaction.
*
* The successfully initialized xfer is refcounted.
*
- * Context: Holds @xfer_lock while manipulating @xfer_alloc_table and
- * @free_xfers.
+ * Context: Holds @xfer_lock while manipulating @free_xfers.
*
- * Return: 0 if all went fine, else corresponding error.
+ * Return: An initialized xfer if all went fine, else pointer error.
*/
static struct scmi_xfer *scmi_xfer_get(const struct scmi_handle *handle,
- struct scmi_xfers_info *minfo,
- bool set_pending)
+ struct scmi_xfers_info *minfo)
{
- int ret;
unsigned long flags;
struct scmi_xfer *xfer;
@@ -376,25 +418,8 @@ static struct scmi_xfer *scmi_xfer_get(const struct scmi_handle *handle,
*/
xfer->transfer_id = atomic_inc_return(&transfer_last_id);
- if (set_pending) {
- /* Pick and set monotonic token */
- ret = scmi_xfer_token_set(minfo, xfer);
- if (!ret) {
- hash_add(minfo->pending_xfers, &xfer->node,
- xfer->hdr.seq);
- xfer->pending = true;
- } else {
- dev_err(handle->dev,
- "Failed to get monotonic token %d\n", ret);
- hlist_add_head(&xfer->node, &minfo->free_xfers);
- xfer = ERR_PTR(ret);
- }
- }
-
- if (!IS_ERR(xfer)) {
- refcount_set(&xfer->users, 1);
- atomic_set(&xfer->busy, SCMI_XFER_FREE);
- }
+ refcount_set(&xfer->users, 1);
+ atomic_set(&xfer->busy, SCMI_XFER_FREE);
spin_unlock_irqrestore(&minfo->xfer_lock, flags);
return xfer;
@@ -652,7 +677,7 @@ static void scmi_handle_notification(struct scmi_chan_info *cinfo,
ktime_t ts;
ts = ktime_get_boottime();
- xfer = scmi_xfer_get(cinfo->handle, minfo, false);
+ xfer = scmi_xfer_get(cinfo->handle, minfo);
if (IS_ERR(xfer)) {
dev_err(dev, "failed to get free message slot (%ld)\n",
PTR_ERR(xfer));
@@ -1041,13 +1066,22 @@ static int xfer_get_init(const struct scmi_protocol_handle *ph,
tx_size > info->desc->max_msg_size)
return -ERANGE;
- xfer = scmi_xfer_get(pi->handle, minfo, true);
+ xfer = scmi_xfer_get(pi->handle, minfo);
if (IS_ERR(xfer)) {
ret = PTR_ERR(xfer);
dev_err(dev, "failed to get free message slot(%d)\n", ret);
return ret;
}
+ /* Pick a sequence number and register this xfer as in-flight */
+ ret = scmi_xfer_pending_set(xfer, minfo);
+ if (ret) {
+ dev_err(pi->handle->dev,
+ "Failed to get monotonic token %d\n", ret);
+ __scmi_xfer_put(minfo, xfer);
+ return ret;
+ }
+
xfer->tx.len = tx_size;
xfer->rx.len = rx_size ? : info->desc->max_msg_size;
xfer->hdr.type = MSG_TYPE_COMMAND;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v4 02/11] firmware: arm_scmi: Simplify chan_available transport operation
2022-10-19 20:46 ` Cristian Marussi
@ 2022-10-19 20:46 ` Cristian Marussi
-1 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
SCMI transport operation .chan_available determines in a transport-specific
way if an SCMI channel is still available and to be configured: such
information is derived analyzing bits of DT in a transport specific way;
all it needs is a DT node to operate upon, not necessarily a full blown
device.
Simplify the helper to receive in input a reference to a device_node
instead of a device carrying a pointer to such device_node.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
v3 --> v4
- fixes in commmit message
---
drivers/firmware/arm_scmi/common.h | 2 +-
drivers/firmware/arm_scmi/driver.c | 2 +-
drivers/firmware/arm_scmi/mailbox.c | 4 ++--
drivers/firmware/arm_scmi/optee.c | 4 ++--
drivers/firmware/arm_scmi/smc.c | 4 ++--
drivers/firmware/arm_scmi/virtio.c | 2 +-
6 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
index 61aba7447c32..096b66442d84 100644
--- a/drivers/firmware/arm_scmi/common.h
+++ b/drivers/firmware/arm_scmi/common.h
@@ -150,7 +150,7 @@ struct scmi_chan_info {
*/
struct scmi_transport_ops {
int (*link_supplier)(struct device *dev);
- bool (*chan_available)(struct device *dev, int idx);
+ bool (*chan_available)(struct device_node *of_node, int idx);
int (*chan_setup)(struct scmi_chan_info *cinfo, struct device *dev,
bool tx);
int (*chan_free)(int id, void *p, void *data);
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index e5193da2ce09..62e02b6475ff 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -2035,7 +2035,7 @@ static int scmi_chan_setup(struct scmi_info *info, struct device *dev,
if (cinfo)
return 0;
- if (!info->desc->ops->chan_available(dev, idx)) {
+ if (!info->desc->ops->chan_available(dev->of_node, idx)) {
cinfo = idr_find(idr, SCMI_PROTOCOL_BASE);
if (unlikely(!cinfo)) /* Possible only if platform has no Rx */
return -EINVAL;
diff --git a/drivers/firmware/arm_scmi/mailbox.c b/drivers/firmware/arm_scmi/mailbox.c
index 08ff4d110beb..ed7e66788134 100644
--- a/drivers/firmware/arm_scmi/mailbox.c
+++ b/drivers/firmware/arm_scmi/mailbox.c
@@ -46,9 +46,9 @@ static void rx_callback(struct mbox_client *cl, void *m)
scmi_rx_callback(smbox->cinfo, shmem_read_header(smbox->shmem), NULL);
}
-static bool mailbox_chan_available(struct device *dev, int idx)
+static bool mailbox_chan_available(struct device_node *of_node, int idx)
{
- return !of_parse_phandle_with_args(dev->of_node, "mboxes",
+ return !of_parse_phandle_with_args(of_node, "mboxes",
"#mbox-cells", idx, NULL);
}
diff --git a/drivers/firmware/arm_scmi/optee.c b/drivers/firmware/arm_scmi/optee.c
index f42dad997ac9..59e688767af2 100644
--- a/drivers/firmware/arm_scmi/optee.c
+++ b/drivers/firmware/arm_scmi/optee.c
@@ -328,11 +328,11 @@ static int scmi_optee_link_supplier(struct device *dev)
return 0;
}
-static bool scmi_optee_chan_available(struct device *dev, int idx)
+static bool scmi_optee_chan_available(struct device_node *of_node, int idx)
{
u32 channel_id;
- return !of_property_read_u32_index(dev->of_node, "linaro,optee-channel-id",
+ return !of_property_read_u32_index(of_node, "linaro,optee-channel-id",
idx, &channel_id);
}
diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/smc.c
index 745acfdd0b3d..0e21bd01348b 100644
--- a/drivers/firmware/arm_scmi/smc.c
+++ b/drivers/firmware/arm_scmi/smc.c
@@ -52,9 +52,9 @@ static irqreturn_t smc_msg_done_isr(int irq, void *data)
return IRQ_HANDLED;
}
-static bool smc_chan_available(struct device *dev, int idx)
+static bool smc_chan_available(struct device_node *of_node, int idx)
{
- struct device_node *np = of_parse_phandle(dev->of_node, "shmem", 0);
+ struct device_node *np = of_parse_phandle(of_node, "shmem", 0);
if (!np)
return false;
diff --git a/drivers/firmware/arm_scmi/virtio.c b/drivers/firmware/arm_scmi/virtio.c
index 14709dbc96a1..e0c92037a9e6 100644
--- a/drivers/firmware/arm_scmi/virtio.c
+++ b/drivers/firmware/arm_scmi/virtio.c
@@ -392,7 +392,7 @@ static int virtio_link_supplier(struct device *dev)
return 0;
}
-static bool virtio_chan_available(struct device *dev, int idx)
+static bool virtio_chan_available(struct device_node *of_node, int idx)
{
struct scmi_vio_channel *channels, *vioch = NULL;
--
2.34.1
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v4 02/11] firmware: arm_scmi: Simplify chan_available transport operation
@ 2022-10-19 20:46 ` Cristian Marussi
0 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
SCMI transport operation .chan_available determines in a transport-specific
way if an SCMI channel is still available and to be configured: such
information is derived analyzing bits of DT in a transport specific way;
all it needs is a DT node to operate upon, not necessarily a full blown
device.
Simplify the helper to receive in input a reference to a device_node
instead of a device carrying a pointer to such device_node.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
v3 --> v4
- fixes in commmit message
---
drivers/firmware/arm_scmi/common.h | 2 +-
drivers/firmware/arm_scmi/driver.c | 2 +-
drivers/firmware/arm_scmi/mailbox.c | 4 ++--
drivers/firmware/arm_scmi/optee.c | 4 ++--
drivers/firmware/arm_scmi/smc.c | 4 ++--
drivers/firmware/arm_scmi/virtio.c | 2 +-
6 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
index 61aba7447c32..096b66442d84 100644
--- a/drivers/firmware/arm_scmi/common.h
+++ b/drivers/firmware/arm_scmi/common.h
@@ -150,7 +150,7 @@ struct scmi_chan_info {
*/
struct scmi_transport_ops {
int (*link_supplier)(struct device *dev);
- bool (*chan_available)(struct device *dev, int idx);
+ bool (*chan_available)(struct device_node *of_node, int idx);
int (*chan_setup)(struct scmi_chan_info *cinfo, struct device *dev,
bool tx);
int (*chan_free)(int id, void *p, void *data);
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index e5193da2ce09..62e02b6475ff 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -2035,7 +2035,7 @@ static int scmi_chan_setup(struct scmi_info *info, struct device *dev,
if (cinfo)
return 0;
- if (!info->desc->ops->chan_available(dev, idx)) {
+ if (!info->desc->ops->chan_available(dev->of_node, idx)) {
cinfo = idr_find(idr, SCMI_PROTOCOL_BASE);
if (unlikely(!cinfo)) /* Possible only if platform has no Rx */
return -EINVAL;
diff --git a/drivers/firmware/arm_scmi/mailbox.c b/drivers/firmware/arm_scmi/mailbox.c
index 08ff4d110beb..ed7e66788134 100644
--- a/drivers/firmware/arm_scmi/mailbox.c
+++ b/drivers/firmware/arm_scmi/mailbox.c
@@ -46,9 +46,9 @@ static void rx_callback(struct mbox_client *cl, void *m)
scmi_rx_callback(smbox->cinfo, shmem_read_header(smbox->shmem), NULL);
}
-static bool mailbox_chan_available(struct device *dev, int idx)
+static bool mailbox_chan_available(struct device_node *of_node, int idx)
{
- return !of_parse_phandle_with_args(dev->of_node, "mboxes",
+ return !of_parse_phandle_with_args(of_node, "mboxes",
"#mbox-cells", idx, NULL);
}
diff --git a/drivers/firmware/arm_scmi/optee.c b/drivers/firmware/arm_scmi/optee.c
index f42dad997ac9..59e688767af2 100644
--- a/drivers/firmware/arm_scmi/optee.c
+++ b/drivers/firmware/arm_scmi/optee.c
@@ -328,11 +328,11 @@ static int scmi_optee_link_supplier(struct device *dev)
return 0;
}
-static bool scmi_optee_chan_available(struct device *dev, int idx)
+static bool scmi_optee_chan_available(struct device_node *of_node, int idx)
{
u32 channel_id;
- return !of_property_read_u32_index(dev->of_node, "linaro,optee-channel-id",
+ return !of_property_read_u32_index(of_node, "linaro,optee-channel-id",
idx, &channel_id);
}
diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/smc.c
index 745acfdd0b3d..0e21bd01348b 100644
--- a/drivers/firmware/arm_scmi/smc.c
+++ b/drivers/firmware/arm_scmi/smc.c
@@ -52,9 +52,9 @@ static irqreturn_t smc_msg_done_isr(int irq, void *data)
return IRQ_HANDLED;
}
-static bool smc_chan_available(struct device *dev, int idx)
+static bool smc_chan_available(struct device_node *of_node, int idx)
{
- struct device_node *np = of_parse_phandle(dev->of_node, "shmem", 0);
+ struct device_node *np = of_parse_phandle(of_node, "shmem", 0);
if (!np)
return false;
diff --git a/drivers/firmware/arm_scmi/virtio.c b/drivers/firmware/arm_scmi/virtio.c
index 14709dbc96a1..e0c92037a9e6 100644
--- a/drivers/firmware/arm_scmi/virtio.c
+++ b/drivers/firmware/arm_scmi/virtio.c
@@ -392,7 +392,7 @@ static int virtio_link_supplier(struct device *dev)
return 0;
}
-static bool virtio_chan_available(struct device *dev, int idx)
+static bool virtio_chan_available(struct device_node *of_node, int idx)
{
struct scmi_vio_channel *channels, *vioch = NULL;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v4 03/11] firmware: arm_scmi: Use dedicated devices to initialize channels
2022-10-19 20:46 ` Cristian Marussi
@ 2022-10-19 20:46 ` Cristian Marussi
-1 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
Refactor channels initialization to use dedicated devices instead of using
devices borrowed from the SCMI drivers.
Initialize all channels as described in the DT upfront.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
v3 --> v4
- fix missing devm_kfree on failpath in scmi_chan_setup
---
drivers/firmware/arm_scmi/driver.c | 96 ++++++++++++++++++++++--------
1 file changed, 72 insertions(+), 24 deletions(-)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 62e02b6475ff..032d1140d631 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -2019,23 +2019,20 @@ static int scmi_xfer_info_init(struct scmi_info *sinfo)
return ret;
}
-static int scmi_chan_setup(struct scmi_info *info, struct device *dev,
+static int scmi_chan_setup(struct scmi_info *info, struct device_node *of_node,
int prot_id, bool tx)
{
int ret, idx;
+ char name[32];
struct scmi_chan_info *cinfo;
struct idr *idr;
+ struct scmi_device *tdev = NULL;
/* Transmit channel is first entry i.e. index 0 */
idx = tx ? 0 : 1;
idr = tx ? &info->tx_idr : &info->rx_idr;
- /* check if already allocated, used for multiple device per protocol */
- cinfo = idr_find(idr, prot_id);
- if (cinfo)
- return 0;
-
- if (!info->desc->ops->chan_available(dev->of_node, idx)) {
+ if (!info->desc->ops->chan_available(of_node, idx)) {
cinfo = idr_find(idr, SCMI_PROTOCOL_BASE);
if (unlikely(!cinfo)) /* Possible only if platform has no Rx */
return -EINVAL;
@@ -2046,26 +2043,43 @@ static int scmi_chan_setup(struct scmi_info *info, struct device *dev,
if (!cinfo)
return -ENOMEM;
- cinfo->dev = dev;
+ /* Create a unique name for this transport device */
+ snprintf(name, 32, "__scmi_transport_device_%s_%02X",
+ idx ? "rx" : "tx", prot_id);
+ /* Create a uniquely named, dedicated transport device for this chan */
+ tdev = scmi_device_create(of_node, info->dev, prot_id, name);
+ if (!tdev) {
+ devm_kfree(info->dev, cinfo);
+ return -EINVAL;
+ }
+ cinfo->dev = &tdev->dev;
ret = info->desc->ops->chan_setup(cinfo, info->dev, tx);
- if (ret)
+ if (ret) {
+ scmi_device_destroy(tdev);
+ devm_kfree(info->dev, cinfo);
return ret;
+ }
if (tx && is_polling_required(cinfo, info)) {
if (is_transport_polling_capable(info))
- dev_info(dev,
+ dev_info(&tdev->dev,
"Enabled polling mode TX channel - prot_id:%d\n",
prot_id);
else
- dev_warn(dev,
+ dev_warn(&tdev->dev,
"Polling mode NOT supported by transport.\n");
}
idr_alloc:
ret = idr_alloc(idr, cinfo, prot_id, prot_id + 1, GFP_KERNEL);
if (ret != prot_id) {
- dev_err(dev, "unable to allocate SCMI idr slot err %d\n", ret);
+ dev_err(info->dev,
+ "unable to allocate SCMI idr slot err %d\n", ret);
+ if (tdev) {
+ scmi_device_destroy(tdev);
+ devm_kfree(info->dev, cinfo);
+ }
return ret;
}
@@ -2074,16 +2088,57 @@ static int scmi_chan_setup(struct scmi_info *info, struct device *dev,
}
static inline int
-scmi_txrx_setup(struct scmi_info *info, struct device *dev, int prot_id)
+scmi_txrx_setup(struct scmi_info *info, struct device_node *of_node,
+ int prot_id)
{
- int ret = scmi_chan_setup(info, dev, prot_id, true);
+ int ret = scmi_chan_setup(info, of_node, prot_id, true);
if (!ret) /* Rx is optional, hence no error check */
- scmi_chan_setup(info, dev, prot_id, false);
+ scmi_chan_setup(info, of_node, prot_id, false);
return ret;
}
+/**
+ * scmi_channels_setup - Helper to initialize all required channels
+ *
+ * @info: The SCMI instance descriptor.
+ *
+ * Initialize all the channels found described in the DT against the underlying
+ * configured transport using custom defined dedicated devices instead of
+ * borrowing devices from the SCMI drivers; this way channels are initialized
+ * upfront during core SCMI stack probing and are operational even if then no
+ * SCMI driver is loaded. (useful to operate in Raw mode)
+ *
+ * Return: 0 on Success
+ */
+static int scmi_channels_setup(struct scmi_info *info)
+{
+ int ret;
+ struct device_node *child, *top_np = info->dev->of_node;
+
+ ret = scmi_txrx_setup(info, top_np, SCMI_PROTOCOL_BASE);
+ if (ret)
+ return ret;
+
+ for_each_available_child_of_node(top_np, child) {
+ u32 prot_id;
+
+ if (of_property_read_u32(child, "reg", &prot_id))
+ continue;
+
+ if (!FIELD_FIT(MSG_PROTOCOL_ID_MASK, prot_id))
+ dev_err(info->dev,
+ "Out of range protocol %d\n", prot_id);
+
+ ret = scmi_txrx_setup(info, child, prot_id);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
/**
* scmi_get_protocol_device - Helper to get/create an SCMI device.
*
@@ -2133,14 +2188,6 @@ scmi_get_protocol_device(struct device_node *np, struct scmi_info *info,
return NULL;
}
- if (scmi_txrx_setup(info, &sdev->dev, prot_id)) {
- dev_err(&sdev->dev, "failed to setup transport\n");
- scmi_device_destroy(sdev);
- mutex_unlock(&scmi_syspower_mtx);
-
- return NULL;
- }
-
if (prot_id == SCMI_PROTOCOL_SYSTEM)
scmi_syspower_registered = true;
@@ -2432,7 +2479,8 @@ static int scmi_probe(struct platform_device *pdev)
return ret;
}
- ret = scmi_txrx_setup(info, dev, SCMI_PROTOCOL_BASE);
+ /* Setup all channels described in the DT at first */
+ ret = scmi_channels_setup(info);
if (ret)
return ret;
--
2.34.1
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v4 03/11] firmware: arm_scmi: Use dedicated devices to initialize channels
@ 2022-10-19 20:46 ` Cristian Marussi
0 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
Refactor channels initialization to use dedicated devices instead of using
devices borrowed from the SCMI drivers.
Initialize all channels as described in the DT upfront.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
v3 --> v4
- fix missing devm_kfree on failpath in scmi_chan_setup
---
drivers/firmware/arm_scmi/driver.c | 96 ++++++++++++++++++++++--------
1 file changed, 72 insertions(+), 24 deletions(-)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 62e02b6475ff..032d1140d631 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -2019,23 +2019,20 @@ static int scmi_xfer_info_init(struct scmi_info *sinfo)
return ret;
}
-static int scmi_chan_setup(struct scmi_info *info, struct device *dev,
+static int scmi_chan_setup(struct scmi_info *info, struct device_node *of_node,
int prot_id, bool tx)
{
int ret, idx;
+ char name[32];
struct scmi_chan_info *cinfo;
struct idr *idr;
+ struct scmi_device *tdev = NULL;
/* Transmit channel is first entry i.e. index 0 */
idx = tx ? 0 : 1;
idr = tx ? &info->tx_idr : &info->rx_idr;
- /* check if already allocated, used for multiple device per protocol */
- cinfo = idr_find(idr, prot_id);
- if (cinfo)
- return 0;
-
- if (!info->desc->ops->chan_available(dev->of_node, idx)) {
+ if (!info->desc->ops->chan_available(of_node, idx)) {
cinfo = idr_find(idr, SCMI_PROTOCOL_BASE);
if (unlikely(!cinfo)) /* Possible only if platform has no Rx */
return -EINVAL;
@@ -2046,26 +2043,43 @@ static int scmi_chan_setup(struct scmi_info *info, struct device *dev,
if (!cinfo)
return -ENOMEM;
- cinfo->dev = dev;
+ /* Create a unique name for this transport device */
+ snprintf(name, 32, "__scmi_transport_device_%s_%02X",
+ idx ? "rx" : "tx", prot_id);
+ /* Create a uniquely named, dedicated transport device for this chan */
+ tdev = scmi_device_create(of_node, info->dev, prot_id, name);
+ if (!tdev) {
+ devm_kfree(info->dev, cinfo);
+ return -EINVAL;
+ }
+ cinfo->dev = &tdev->dev;
ret = info->desc->ops->chan_setup(cinfo, info->dev, tx);
- if (ret)
+ if (ret) {
+ scmi_device_destroy(tdev);
+ devm_kfree(info->dev, cinfo);
return ret;
+ }
if (tx && is_polling_required(cinfo, info)) {
if (is_transport_polling_capable(info))
- dev_info(dev,
+ dev_info(&tdev->dev,
"Enabled polling mode TX channel - prot_id:%d\n",
prot_id);
else
- dev_warn(dev,
+ dev_warn(&tdev->dev,
"Polling mode NOT supported by transport.\n");
}
idr_alloc:
ret = idr_alloc(idr, cinfo, prot_id, prot_id + 1, GFP_KERNEL);
if (ret != prot_id) {
- dev_err(dev, "unable to allocate SCMI idr slot err %d\n", ret);
+ dev_err(info->dev,
+ "unable to allocate SCMI idr slot err %d\n", ret);
+ if (tdev) {
+ scmi_device_destroy(tdev);
+ devm_kfree(info->dev, cinfo);
+ }
return ret;
}
@@ -2074,16 +2088,57 @@ static int scmi_chan_setup(struct scmi_info *info, struct device *dev,
}
static inline int
-scmi_txrx_setup(struct scmi_info *info, struct device *dev, int prot_id)
+scmi_txrx_setup(struct scmi_info *info, struct device_node *of_node,
+ int prot_id)
{
- int ret = scmi_chan_setup(info, dev, prot_id, true);
+ int ret = scmi_chan_setup(info, of_node, prot_id, true);
if (!ret) /* Rx is optional, hence no error check */
- scmi_chan_setup(info, dev, prot_id, false);
+ scmi_chan_setup(info, of_node, prot_id, false);
return ret;
}
+/**
+ * scmi_channels_setup - Helper to initialize all required channels
+ *
+ * @info: The SCMI instance descriptor.
+ *
+ * Initialize all the channels found described in the DT against the underlying
+ * configured transport using custom defined dedicated devices instead of
+ * borrowing devices from the SCMI drivers; this way channels are initialized
+ * upfront during core SCMI stack probing and are operational even if then no
+ * SCMI driver is loaded. (useful to operate in Raw mode)
+ *
+ * Return: 0 on Success
+ */
+static int scmi_channels_setup(struct scmi_info *info)
+{
+ int ret;
+ struct device_node *child, *top_np = info->dev->of_node;
+
+ ret = scmi_txrx_setup(info, top_np, SCMI_PROTOCOL_BASE);
+ if (ret)
+ return ret;
+
+ for_each_available_child_of_node(top_np, child) {
+ u32 prot_id;
+
+ if (of_property_read_u32(child, "reg", &prot_id))
+ continue;
+
+ if (!FIELD_FIT(MSG_PROTOCOL_ID_MASK, prot_id))
+ dev_err(info->dev,
+ "Out of range protocol %d\n", prot_id);
+
+ ret = scmi_txrx_setup(info, child, prot_id);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
/**
* scmi_get_protocol_device - Helper to get/create an SCMI device.
*
@@ -2133,14 +2188,6 @@ scmi_get_protocol_device(struct device_node *np, struct scmi_info *info,
return NULL;
}
- if (scmi_txrx_setup(info, &sdev->dev, prot_id)) {
- dev_err(&sdev->dev, "failed to setup transport\n");
- scmi_device_destroy(sdev);
- mutex_unlock(&scmi_syspower_mtx);
-
- return NULL;
- }
-
if (prot_id == SCMI_PROTOCOL_SYSTEM)
scmi_syspower_registered = true;
@@ -2432,7 +2479,8 @@ static int scmi_probe(struct platform_device *pdev)
return ret;
}
- ret = scmi_txrx_setup(info, dev, SCMI_PROTOCOL_BASE);
+ /* Setup all channels described in the DT at first */
+ ret = scmi_channels_setup(info);
if (ret)
return ret;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v4 04/11] firmware: arm_scmi: Refactor polling helpers
2022-10-19 20:46 ` Cristian Marussi
@ 2022-10-19 20:46 ` Cristian Marussi
-1 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
Refactor polling helpers to receive scmi_desc directly as a parameter and
move all of them to common.h.
No functional change.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
drivers/firmware/arm_scmi/common.h | 18 ++++++++++++++++
drivers/firmware/arm_scmi/driver.c | 34 ++++++++----------------------
2 files changed, 27 insertions(+), 25 deletions(-)
diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
index 096b66442d84..30d056febef1 100644
--- a/drivers/firmware/arm_scmi/common.h
+++ b/drivers/firmware/arm_scmi/common.h
@@ -212,6 +212,24 @@ struct scmi_desc {
const bool atomic_enabled;
};
+static inline bool is_polling_required(struct scmi_chan_info *cinfo,
+ const struct scmi_desc *desc)
+{
+ return cinfo->no_completion_irq || desc->force_polling;
+}
+
+static inline bool is_transport_polling_capable(const struct scmi_desc *desc)
+{
+ return desc->ops->poll_done || desc->sync_cmds_completed_on_ret;
+}
+
+static inline bool is_polling_enabled(struct scmi_chan_info *cinfo,
+ const struct scmi_desc *desc)
+{
+ return is_polling_required(cinfo, desc) &&
+ is_transport_polling_capable(desc);
+}
+
#ifdef CONFIG_ARM_SCMI_TRANSPORT_MAILBOX
extern const struct scmi_desc scmi_mailbox_desc;
#endif
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 032d1140d631..9c77c931d91b 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -648,25 +648,6 @@ static inline void scmi_clear_channel(struct scmi_info *info,
info->desc->ops->clear_channel(cinfo);
}
-static inline bool is_polling_required(struct scmi_chan_info *cinfo,
- struct scmi_info *info)
-{
- return cinfo->no_completion_irq || info->desc->force_polling;
-}
-
-static inline bool is_transport_polling_capable(struct scmi_info *info)
-{
- return info->desc->ops->poll_done ||
- info->desc->sync_cmds_completed_on_ret;
-}
-
-static inline bool is_polling_enabled(struct scmi_chan_info *cinfo,
- struct scmi_info *info)
-{
- return is_polling_required(cinfo, info) &&
- is_transport_polling_capable(info);
-}
-
static void scmi_handle_notification(struct scmi_chan_info *cinfo,
u32 msg_hdr, void *priv)
{
@@ -909,7 +890,8 @@ static int do_xfer(const struct scmi_protocol_handle *ph,
struct scmi_chan_info *cinfo;
/* Check for polling request on custom command xfers at first */
- if (xfer->hdr.poll_completion && !is_transport_polling_capable(info)) {
+ if (xfer->hdr.poll_completion &&
+ !is_transport_polling_capable(info->desc)) {
dev_warn_once(dev,
"Polling mode is not supported by transport.\n");
return -EINVAL;
@@ -920,7 +902,7 @@ static int do_xfer(const struct scmi_protocol_handle *ph,
return -EINVAL;
/* True ONLY if also supported by transport. */
- if (is_polling_enabled(cinfo, info))
+ if (is_polling_enabled(cinfo, info->desc))
xfer->hdr.poll_completion = true;
/*
@@ -1854,7 +1836,8 @@ static bool scmi_is_transport_atomic(const struct scmi_handle *handle,
bool ret;
struct scmi_info *info = handle_to_scmi_info(handle);
- ret = info->desc->atomic_enabled && is_transport_polling_capable(info);
+ ret = info->desc->atomic_enabled &&
+ is_transport_polling_capable(info->desc);
if (ret && atomic_threshold)
*atomic_threshold = info->atomic_threshold;
@@ -2061,8 +2044,8 @@ static int scmi_chan_setup(struct scmi_info *info, struct device_node *of_node,
return ret;
}
- if (tx && is_polling_required(cinfo, info)) {
- if (is_transport_polling_capable(info))
+ if (tx && is_polling_required(cinfo, info->desc)) {
+ if (is_transport_polling_capable(info->desc))
dev_info(&tdev->dev,
"Enabled polling mode TX channel - prot_id:%d\n",
prot_id);
@@ -2491,7 +2474,8 @@ static int scmi_probe(struct platform_device *pdev)
if (scmi_notification_init(handle))
dev_err(dev, "SCMI Notifications NOT available.\n");
- if (info->desc->atomic_enabled && !is_transport_polling_capable(info))
+ if (info->desc->atomic_enabled &&
+ !is_transport_polling_capable(info->desc))
dev_err(dev,
"Transport is not polling capable. Atomic mode not supported.\n");
--
2.34.1
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v4 04/11] firmware: arm_scmi: Refactor polling helpers
@ 2022-10-19 20:46 ` Cristian Marussi
0 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
Refactor polling helpers to receive scmi_desc directly as a parameter and
move all of them to common.h.
No functional change.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
drivers/firmware/arm_scmi/common.h | 18 ++++++++++++++++
drivers/firmware/arm_scmi/driver.c | 34 ++++++++----------------------
2 files changed, 27 insertions(+), 25 deletions(-)
diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
index 096b66442d84..30d056febef1 100644
--- a/drivers/firmware/arm_scmi/common.h
+++ b/drivers/firmware/arm_scmi/common.h
@@ -212,6 +212,24 @@ struct scmi_desc {
const bool atomic_enabled;
};
+static inline bool is_polling_required(struct scmi_chan_info *cinfo,
+ const struct scmi_desc *desc)
+{
+ return cinfo->no_completion_irq || desc->force_polling;
+}
+
+static inline bool is_transport_polling_capable(const struct scmi_desc *desc)
+{
+ return desc->ops->poll_done || desc->sync_cmds_completed_on_ret;
+}
+
+static inline bool is_polling_enabled(struct scmi_chan_info *cinfo,
+ const struct scmi_desc *desc)
+{
+ return is_polling_required(cinfo, desc) &&
+ is_transport_polling_capable(desc);
+}
+
#ifdef CONFIG_ARM_SCMI_TRANSPORT_MAILBOX
extern const struct scmi_desc scmi_mailbox_desc;
#endif
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 032d1140d631..9c77c931d91b 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -648,25 +648,6 @@ static inline void scmi_clear_channel(struct scmi_info *info,
info->desc->ops->clear_channel(cinfo);
}
-static inline bool is_polling_required(struct scmi_chan_info *cinfo,
- struct scmi_info *info)
-{
- return cinfo->no_completion_irq || info->desc->force_polling;
-}
-
-static inline bool is_transport_polling_capable(struct scmi_info *info)
-{
- return info->desc->ops->poll_done ||
- info->desc->sync_cmds_completed_on_ret;
-}
-
-static inline bool is_polling_enabled(struct scmi_chan_info *cinfo,
- struct scmi_info *info)
-{
- return is_polling_required(cinfo, info) &&
- is_transport_polling_capable(info);
-}
-
static void scmi_handle_notification(struct scmi_chan_info *cinfo,
u32 msg_hdr, void *priv)
{
@@ -909,7 +890,8 @@ static int do_xfer(const struct scmi_protocol_handle *ph,
struct scmi_chan_info *cinfo;
/* Check for polling request on custom command xfers at first */
- if (xfer->hdr.poll_completion && !is_transport_polling_capable(info)) {
+ if (xfer->hdr.poll_completion &&
+ !is_transport_polling_capable(info->desc)) {
dev_warn_once(dev,
"Polling mode is not supported by transport.\n");
return -EINVAL;
@@ -920,7 +902,7 @@ static int do_xfer(const struct scmi_protocol_handle *ph,
return -EINVAL;
/* True ONLY if also supported by transport. */
- if (is_polling_enabled(cinfo, info))
+ if (is_polling_enabled(cinfo, info->desc))
xfer->hdr.poll_completion = true;
/*
@@ -1854,7 +1836,8 @@ static bool scmi_is_transport_atomic(const struct scmi_handle *handle,
bool ret;
struct scmi_info *info = handle_to_scmi_info(handle);
- ret = info->desc->atomic_enabled && is_transport_polling_capable(info);
+ ret = info->desc->atomic_enabled &&
+ is_transport_polling_capable(info->desc);
if (ret && atomic_threshold)
*atomic_threshold = info->atomic_threshold;
@@ -2061,8 +2044,8 @@ static int scmi_chan_setup(struct scmi_info *info, struct device_node *of_node,
return ret;
}
- if (tx && is_polling_required(cinfo, info)) {
- if (is_transport_polling_capable(info))
+ if (tx && is_polling_required(cinfo, info->desc)) {
+ if (is_transport_polling_capable(info->desc))
dev_info(&tdev->dev,
"Enabled polling mode TX channel - prot_id:%d\n",
prot_id);
@@ -2491,7 +2474,8 @@ static int scmi_probe(struct platform_device *pdev)
if (scmi_notification_init(handle))
dev_err(dev, "SCMI Notifications NOT available.\n");
- if (info->desc->atomic_enabled && !is_transport_polling_capable(info))
+ if (info->desc->atomic_enabled &&
+ !is_transport_polling_capable(info->desc))
dev_err(dev,
"Transport is not polling capable. Atomic mode not supported.\n");
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v4 05/11] firmware: arm_scmi: Refactor scmi_wait_for_message_response
2022-10-19 20:46 ` Cristian Marussi
@ 2022-10-19 20:46 ` Cristian Marussi
-1 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
Refactor scmi_wait_for_message_response() to use a internal helper to
carry out its main duties; while doing that make it accept directly an
scmi_desc parameter to interact with the configured transport.
No functional change.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
drivers/firmware/arm_scmi/driver.c | 57 +++++++++++++++++-------------
1 file changed, 33 insertions(+), 24 deletions(-)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 9c77c931d91b..d496dfe43618 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -791,36 +791,18 @@ static bool scmi_xfer_done_no_timeout(struct scmi_chan_info *cinfo,
ktime_after(ktime_get(), stop);
}
-/**
- * scmi_wait_for_message_response - An helper to group all the possible ways of
- * waiting for a synchronous message response.
- *
- * @cinfo: SCMI channel info
- * @xfer: Reference to the transfer being waited for.
- *
- * Chooses waiting strategy (sleep-waiting vs busy-waiting) depending on
- * configuration flags like xfer->hdr.poll_completion.
- *
- * Return: 0 on Success, error otherwise.
- */
-static int scmi_wait_for_message_response(struct scmi_chan_info *cinfo,
- struct scmi_xfer *xfer)
+static int scmi_wait_for_reply(struct device *dev, const struct scmi_desc *desc,
+ struct scmi_chan_info *cinfo,
+ struct scmi_xfer *xfer, unsigned int timeout_ms)
{
- struct scmi_info *info = handle_to_scmi_info(cinfo->handle);
- struct device *dev = info->dev;
- int ret = 0, timeout_ms = info->desc->max_rx_timeout_ms;
-
- trace_scmi_xfer_response_wait(xfer->transfer_id, xfer->hdr.id,
- xfer->hdr.protocol_id, xfer->hdr.seq,
- timeout_ms,
- xfer->hdr.poll_completion);
+ int ret = 0;
if (xfer->hdr.poll_completion) {
/*
* Real polling is needed only if transport has NOT declared
* itself to support synchronous commands replies.
*/
- if (!info->desc->sync_cmds_completed_on_ret) {
+ if (!desc->sync_cmds_completed_on_ret) {
/*
* Poll on xfer using transport provided .poll_done();
* assumes no completion interrupt was available.
@@ -846,7 +828,7 @@ static int scmi_wait_for_message_response(struct scmi_chan_info *cinfo,
*/
spin_lock_irqsave(&xfer->lock, flags);
if (xfer->state == SCMI_XFER_SENT_OK) {
- info->desc->ops->fetch_response(cinfo, xfer);
+ desc->ops->fetch_response(cinfo, xfer);
xfer->state = SCMI_XFER_RESP_OK;
}
spin_unlock_irqrestore(&xfer->lock, flags);
@@ -870,6 +852,33 @@ static int scmi_wait_for_message_response(struct scmi_chan_info *cinfo,
return ret;
}
+/**
+ * scmi_wait_for_message_response - An helper to group all the possible ways of
+ * waiting for a synchronous message response.
+ *
+ * @cinfo: SCMI channel info
+ * @xfer: Reference to the transfer being waited for.
+ *
+ * Chooses waiting strategy (sleep-waiting vs busy-waiting) depending on
+ * configuration flags like xfer->hdr.poll_completion.
+ *
+ * Return: 0 on Success, error otherwise.
+ */
+static int scmi_wait_for_message_response(struct scmi_chan_info *cinfo,
+ struct scmi_xfer *xfer)
+{
+ struct scmi_info *info = handle_to_scmi_info(cinfo->handle);
+ struct device *dev = info->dev;
+
+ trace_scmi_xfer_response_wait(xfer->transfer_id, xfer->hdr.id,
+ xfer->hdr.protocol_id, xfer->hdr.seq,
+ info->desc->max_rx_timeout_ms,
+ xfer->hdr.poll_completion);
+
+ return scmi_wait_for_reply(dev, info->desc, cinfo, xfer,
+ info->desc->max_rx_timeout_ms);
+}
+
/**
* do_xfer() - Do one transfer
*
--
2.34.1
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v4 05/11] firmware: arm_scmi: Refactor scmi_wait_for_message_response
@ 2022-10-19 20:46 ` Cristian Marussi
0 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
Refactor scmi_wait_for_message_response() to use a internal helper to
carry out its main duties; while doing that make it accept directly an
scmi_desc parameter to interact with the configured transport.
No functional change.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
drivers/firmware/arm_scmi/driver.c | 57 +++++++++++++++++-------------
1 file changed, 33 insertions(+), 24 deletions(-)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 9c77c931d91b..d496dfe43618 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -791,36 +791,18 @@ static bool scmi_xfer_done_no_timeout(struct scmi_chan_info *cinfo,
ktime_after(ktime_get(), stop);
}
-/**
- * scmi_wait_for_message_response - An helper to group all the possible ways of
- * waiting for a synchronous message response.
- *
- * @cinfo: SCMI channel info
- * @xfer: Reference to the transfer being waited for.
- *
- * Chooses waiting strategy (sleep-waiting vs busy-waiting) depending on
- * configuration flags like xfer->hdr.poll_completion.
- *
- * Return: 0 on Success, error otherwise.
- */
-static int scmi_wait_for_message_response(struct scmi_chan_info *cinfo,
- struct scmi_xfer *xfer)
+static int scmi_wait_for_reply(struct device *dev, const struct scmi_desc *desc,
+ struct scmi_chan_info *cinfo,
+ struct scmi_xfer *xfer, unsigned int timeout_ms)
{
- struct scmi_info *info = handle_to_scmi_info(cinfo->handle);
- struct device *dev = info->dev;
- int ret = 0, timeout_ms = info->desc->max_rx_timeout_ms;
-
- trace_scmi_xfer_response_wait(xfer->transfer_id, xfer->hdr.id,
- xfer->hdr.protocol_id, xfer->hdr.seq,
- timeout_ms,
- xfer->hdr.poll_completion);
+ int ret = 0;
if (xfer->hdr.poll_completion) {
/*
* Real polling is needed only if transport has NOT declared
* itself to support synchronous commands replies.
*/
- if (!info->desc->sync_cmds_completed_on_ret) {
+ if (!desc->sync_cmds_completed_on_ret) {
/*
* Poll on xfer using transport provided .poll_done();
* assumes no completion interrupt was available.
@@ -846,7 +828,7 @@ static int scmi_wait_for_message_response(struct scmi_chan_info *cinfo,
*/
spin_lock_irqsave(&xfer->lock, flags);
if (xfer->state == SCMI_XFER_SENT_OK) {
- info->desc->ops->fetch_response(cinfo, xfer);
+ desc->ops->fetch_response(cinfo, xfer);
xfer->state = SCMI_XFER_RESP_OK;
}
spin_unlock_irqrestore(&xfer->lock, flags);
@@ -870,6 +852,33 @@ static int scmi_wait_for_message_response(struct scmi_chan_info *cinfo,
return ret;
}
+/**
+ * scmi_wait_for_message_response - An helper to group all the possible ways of
+ * waiting for a synchronous message response.
+ *
+ * @cinfo: SCMI channel info
+ * @xfer: Reference to the transfer being waited for.
+ *
+ * Chooses waiting strategy (sleep-waiting vs busy-waiting) depending on
+ * configuration flags like xfer->hdr.poll_completion.
+ *
+ * Return: 0 on Success, error otherwise.
+ */
+static int scmi_wait_for_message_response(struct scmi_chan_info *cinfo,
+ struct scmi_xfer *xfer)
+{
+ struct scmi_info *info = handle_to_scmi_info(cinfo->handle);
+ struct device *dev = info->dev;
+
+ trace_scmi_xfer_response_wait(xfer->transfer_id, xfer->hdr.id,
+ xfer->hdr.protocol_id, xfer->hdr.seq,
+ info->desc->max_rx_timeout_ms,
+ xfer->hdr.poll_completion);
+
+ return scmi_wait_for_reply(dev, info->desc, cinfo, xfer,
+ info->desc->max_rx_timeout_ms);
+}
+
/**
* do_xfer() - Do one transfer
*
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v4 06/11] firmware: arm_scmi: Add xfer raw helpers
2022-10-19 20:46 ` Cristian Marussi
@ 2022-10-19 20:46 ` Cristian Marussi
-1 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
Add a few SCMI helpers useful to implement SCMI Raw access support.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
v3 --> v4
- add scmi_xfer_raw_wait_for_response helper
- fixed typos in comments
v2 --> v3
- allow for DT-unknown protocols to get a channel
v1 --> v2
- added scmi_xfer_raw_channel_get
---
drivers/firmware/arm_scmi/common.h | 12 +++
drivers/firmware/arm_scmi/driver.c | 141 +++++++++++++++++++++++++++++
2 files changed, 153 insertions(+)
diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
index 30d056febef1..3dceb69b8484 100644
--- a/drivers/firmware/arm_scmi/common.h
+++ b/drivers/firmware/arm_scmi/common.h
@@ -230,6 +230,18 @@ static inline bool is_polling_enabled(struct scmi_chan_info *cinfo,
is_transport_polling_capable(desc);
}
+void scmi_xfer_raw_put(const struct scmi_handle *handle,
+ struct scmi_xfer *xfer);
+struct scmi_xfer *scmi_xfer_raw_get(const struct scmi_handle *handle);
+struct scmi_chan_info *
+scmi_xfer_raw_channel_get(const struct scmi_handle *handle, u8 protocol_id);
+
+int scmi_xfer_raw_inflight_register(const struct scmi_handle *handle,
+ struct scmi_xfer *xfer);
+
+int scmi_xfer_raw_wait_for_message_response(struct scmi_chan_info *cinfo,
+ struct scmi_xfer *xfer,
+ unsigned int timeout_ms);
#ifdef CONFIG_ARM_SCMI_TRANSPORT_MAILBOX
extern const struct scmi_desc scmi_mailbox_desc;
#endif
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index d496dfe43618..3649435082bb 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -350,6 +350,53 @@ scmi_xfer_inflight_register_unlocked(struct scmi_xfer *xfer,
xfer->pending = true;
}
+/**
+ * scmi_xfer_inflight_register - Try to register an xfer as in-flight
+ *
+ * @xfer: The xfer to register
+ * @minfo: Pointer to Tx/Rx Message management info based on channel type
+ *
+ * Note that this helper does NOT assume anything about the sequence number
+ * that was baked into the provided xfer, so it checks at first if it can
+ * be mapped to a free slot and fails with an error if another xfer with the
+ * same sequence number is currently still registered as in-flight.
+ *
+ * Return: 0 on Success or -EBUSY if sequence number embedded in the xfer
+ * could not rbe mapped to a free slot in the xfer_alloc_table.
+ */
+static int scmi_xfer_inflight_register(struct scmi_xfer *xfer,
+ struct scmi_xfers_info *minfo)
+{
+ int ret = 0;
+ unsigned long flags;
+
+ spin_lock_irqsave(&minfo->xfer_lock, flags);
+ if (!test_bit(xfer->hdr.seq, minfo->xfer_alloc_table))
+ scmi_xfer_inflight_register_unlocked(xfer, minfo);
+ else
+ ret = -EBUSY;
+ spin_unlock_irqrestore(&minfo->xfer_lock, flags);
+
+ return ret;
+}
+
+/**
+ * scmi_xfer_raw_inflight_register - An helper to register the given xfer as in
+ * flight on the TX channel, if possible.
+ *
+ * @handle: Pointer to SCMI entity handle
+ * @xfer: The xfer to register
+ *
+ * Return: 0 on Success, error otherwise
+ */
+int scmi_xfer_raw_inflight_register(const struct scmi_handle *handle,
+ struct scmi_xfer *xfer)
+{
+ struct scmi_info *info = handle_to_scmi_info(handle);
+
+ return scmi_xfer_inflight_register(xfer, &info->tx_minfo);
+}
+
/**
* scmi_xfer_pending_set - Pick a proper sequence number and mark the xfer
* as pending in-flight
@@ -425,6 +472,58 @@ static struct scmi_xfer *scmi_xfer_get(const struct scmi_handle *handle,
return xfer;
}
+/**
+ * scmi_xfer_raw_get - Helper to get a bare free xfer from the TX channel
+ *
+ * @handle: Pointer to SCMI entity handle
+ *
+ * Note that xfer is taken from the TX channel structures.
+ *
+ * Return: A valid xfer on Success, or an error-pointer otherwise
+ */
+struct scmi_xfer *scmi_xfer_raw_get(const struct scmi_handle *handle)
+{
+ struct scmi_info *info = handle_to_scmi_info(handle);
+
+ return scmi_xfer_get(handle, &info->tx_minfo);
+}
+
+/**
+ * scmi_xfer_raw_channel_get - Helper to get a reference to the proper channel
+ * to use for a specific protocol_id Raw transaction.
+ *
+ * @handle: Pointer to SCMI entity handle
+ * @protocol_id: Identifier of the protocol
+ *
+ * Note that in a regular SCMI stack, usually, a protocol has to be defined in
+ * the DT to have an associated channel and be usable; but in Raw mode any
+ * protocol in range is allowed, re-using the Base channel, so as to enable
+ * fuzzing on any protocol without the need of a fully compiled DT.
+ *
+ * Return: A reference to the channel to use, or an ERR_PTR
+ */
+struct scmi_chan_info *
+scmi_xfer_raw_channel_get(const struct scmi_handle *handle, u8 protocol_id)
+{
+ struct scmi_chan_info *cinfo;
+ struct scmi_info *info = handle_to_scmi_info(handle);
+
+ cinfo = idr_find(&info->tx_idr, protocol_id);
+ if (!cinfo) {
+ if (protocol_id == SCMI_PROTOCOL_BASE)
+ return ERR_PTR(-EINVAL);
+ /* Use Base channel for protocols not defined for DT */
+ cinfo = idr_find(&info->tx_idr, SCMI_PROTOCOL_BASE);
+ if (!cinfo)
+ return ERR_PTR(-EINVAL);
+ dev_warn_once(handle->dev,
+ "Using Base channel for protocol 0x%X\n",
+ protocol_id);
+ }
+
+ return cinfo;
+}
+
/**
* __scmi_xfer_put() - Release a message
*
@@ -453,6 +552,22 @@ __scmi_xfer_put(struct scmi_xfers_info *minfo, struct scmi_xfer *xfer)
spin_unlock_irqrestore(&minfo->xfer_lock, flags);
}
+/**
+ * scmi_xfer_raw_put - Release an xfer that was taken by @scmi_xfer_raw_get
+ *
+ * @handle: Pointer to SCMI entity handle
+ * @xfer: A reference to the xfer to put
+ *
+ * Note that as with other xfer_put() handlers the xfer is really effectively
+ * released only if there are no more users on the system.
+ */
+void scmi_xfer_raw_put(const struct scmi_handle *handle, struct scmi_xfer *xfer)
+{
+ struct scmi_info *info = handle_to_scmi_info(handle);
+
+ return __scmi_xfer_put(&info->tx_minfo, xfer);
+}
+
/**
* scmi_xfer_lookup_unlocked - Helper to lookup an xfer_id
*
@@ -879,6 +994,32 @@ static int scmi_wait_for_message_response(struct scmi_chan_info *cinfo,
info->desc->max_rx_timeout_ms);
}
+/**
+ * scmi_xfer_raw_wait_for_message_response - An helper to wait for a message
+ * reply to an xfer raw request on a specific channel for the required timeout.
+ *
+ * @cinfo: SCMI channel info
+ * @xfer: Reference to the transfer being waited for.
+ * @timeout_ms: The maximum timeout in milliseconds
+ *
+ * Return: 0 on Success, error otherwise.
+ */
+int scmi_xfer_raw_wait_for_message_response(struct scmi_chan_info *cinfo,
+ struct scmi_xfer *xfer,
+ unsigned int timeout_ms)
+{
+ int ret;
+ struct scmi_info *info = handle_to_scmi_info(cinfo->handle);
+ struct device *dev = info->dev;
+
+ ret = scmi_wait_for_reply(dev, info->desc, cinfo, xfer, timeout_ms);
+ if (ret)
+ dev_dbg(dev, "timed out in RAW response - HDR:%08X\n",
+ pack_scmi_header(&xfer->hdr));
+
+ return ret;
+}
+
/**
* do_xfer() - Do one transfer
*
--
2.34.1
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v4 06/11] firmware: arm_scmi: Add xfer raw helpers
@ 2022-10-19 20:46 ` Cristian Marussi
0 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
Add a few SCMI helpers useful to implement SCMI Raw access support.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
v3 --> v4
- add scmi_xfer_raw_wait_for_response helper
- fixed typos in comments
v2 --> v3
- allow for DT-unknown protocols to get a channel
v1 --> v2
- added scmi_xfer_raw_channel_get
---
drivers/firmware/arm_scmi/common.h | 12 +++
drivers/firmware/arm_scmi/driver.c | 141 +++++++++++++++++++++++++++++
2 files changed, 153 insertions(+)
diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
index 30d056febef1..3dceb69b8484 100644
--- a/drivers/firmware/arm_scmi/common.h
+++ b/drivers/firmware/arm_scmi/common.h
@@ -230,6 +230,18 @@ static inline bool is_polling_enabled(struct scmi_chan_info *cinfo,
is_transport_polling_capable(desc);
}
+void scmi_xfer_raw_put(const struct scmi_handle *handle,
+ struct scmi_xfer *xfer);
+struct scmi_xfer *scmi_xfer_raw_get(const struct scmi_handle *handle);
+struct scmi_chan_info *
+scmi_xfer_raw_channel_get(const struct scmi_handle *handle, u8 protocol_id);
+
+int scmi_xfer_raw_inflight_register(const struct scmi_handle *handle,
+ struct scmi_xfer *xfer);
+
+int scmi_xfer_raw_wait_for_message_response(struct scmi_chan_info *cinfo,
+ struct scmi_xfer *xfer,
+ unsigned int timeout_ms);
#ifdef CONFIG_ARM_SCMI_TRANSPORT_MAILBOX
extern const struct scmi_desc scmi_mailbox_desc;
#endif
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index d496dfe43618..3649435082bb 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -350,6 +350,53 @@ scmi_xfer_inflight_register_unlocked(struct scmi_xfer *xfer,
xfer->pending = true;
}
+/**
+ * scmi_xfer_inflight_register - Try to register an xfer as in-flight
+ *
+ * @xfer: The xfer to register
+ * @minfo: Pointer to Tx/Rx Message management info based on channel type
+ *
+ * Note that this helper does NOT assume anything about the sequence number
+ * that was baked into the provided xfer, so it checks at first if it can
+ * be mapped to a free slot and fails with an error if another xfer with the
+ * same sequence number is currently still registered as in-flight.
+ *
+ * Return: 0 on Success or -EBUSY if sequence number embedded in the xfer
+ * could not rbe mapped to a free slot in the xfer_alloc_table.
+ */
+static int scmi_xfer_inflight_register(struct scmi_xfer *xfer,
+ struct scmi_xfers_info *minfo)
+{
+ int ret = 0;
+ unsigned long flags;
+
+ spin_lock_irqsave(&minfo->xfer_lock, flags);
+ if (!test_bit(xfer->hdr.seq, minfo->xfer_alloc_table))
+ scmi_xfer_inflight_register_unlocked(xfer, minfo);
+ else
+ ret = -EBUSY;
+ spin_unlock_irqrestore(&minfo->xfer_lock, flags);
+
+ return ret;
+}
+
+/**
+ * scmi_xfer_raw_inflight_register - An helper to register the given xfer as in
+ * flight on the TX channel, if possible.
+ *
+ * @handle: Pointer to SCMI entity handle
+ * @xfer: The xfer to register
+ *
+ * Return: 0 on Success, error otherwise
+ */
+int scmi_xfer_raw_inflight_register(const struct scmi_handle *handle,
+ struct scmi_xfer *xfer)
+{
+ struct scmi_info *info = handle_to_scmi_info(handle);
+
+ return scmi_xfer_inflight_register(xfer, &info->tx_minfo);
+}
+
/**
* scmi_xfer_pending_set - Pick a proper sequence number and mark the xfer
* as pending in-flight
@@ -425,6 +472,58 @@ static struct scmi_xfer *scmi_xfer_get(const struct scmi_handle *handle,
return xfer;
}
+/**
+ * scmi_xfer_raw_get - Helper to get a bare free xfer from the TX channel
+ *
+ * @handle: Pointer to SCMI entity handle
+ *
+ * Note that xfer is taken from the TX channel structures.
+ *
+ * Return: A valid xfer on Success, or an error-pointer otherwise
+ */
+struct scmi_xfer *scmi_xfer_raw_get(const struct scmi_handle *handle)
+{
+ struct scmi_info *info = handle_to_scmi_info(handle);
+
+ return scmi_xfer_get(handle, &info->tx_minfo);
+}
+
+/**
+ * scmi_xfer_raw_channel_get - Helper to get a reference to the proper channel
+ * to use for a specific protocol_id Raw transaction.
+ *
+ * @handle: Pointer to SCMI entity handle
+ * @protocol_id: Identifier of the protocol
+ *
+ * Note that in a regular SCMI stack, usually, a protocol has to be defined in
+ * the DT to have an associated channel and be usable; but in Raw mode any
+ * protocol in range is allowed, re-using the Base channel, so as to enable
+ * fuzzing on any protocol without the need of a fully compiled DT.
+ *
+ * Return: A reference to the channel to use, or an ERR_PTR
+ */
+struct scmi_chan_info *
+scmi_xfer_raw_channel_get(const struct scmi_handle *handle, u8 protocol_id)
+{
+ struct scmi_chan_info *cinfo;
+ struct scmi_info *info = handle_to_scmi_info(handle);
+
+ cinfo = idr_find(&info->tx_idr, protocol_id);
+ if (!cinfo) {
+ if (protocol_id == SCMI_PROTOCOL_BASE)
+ return ERR_PTR(-EINVAL);
+ /* Use Base channel for protocols not defined for DT */
+ cinfo = idr_find(&info->tx_idr, SCMI_PROTOCOL_BASE);
+ if (!cinfo)
+ return ERR_PTR(-EINVAL);
+ dev_warn_once(handle->dev,
+ "Using Base channel for protocol 0x%X\n",
+ protocol_id);
+ }
+
+ return cinfo;
+}
+
/**
* __scmi_xfer_put() - Release a message
*
@@ -453,6 +552,22 @@ __scmi_xfer_put(struct scmi_xfers_info *minfo, struct scmi_xfer *xfer)
spin_unlock_irqrestore(&minfo->xfer_lock, flags);
}
+/**
+ * scmi_xfer_raw_put - Release an xfer that was taken by @scmi_xfer_raw_get
+ *
+ * @handle: Pointer to SCMI entity handle
+ * @xfer: A reference to the xfer to put
+ *
+ * Note that as with other xfer_put() handlers the xfer is really effectively
+ * released only if there are no more users on the system.
+ */
+void scmi_xfer_raw_put(const struct scmi_handle *handle, struct scmi_xfer *xfer)
+{
+ struct scmi_info *info = handle_to_scmi_info(handle);
+
+ return __scmi_xfer_put(&info->tx_minfo, xfer);
+}
+
/**
* scmi_xfer_lookup_unlocked - Helper to lookup an xfer_id
*
@@ -879,6 +994,32 @@ static int scmi_wait_for_message_response(struct scmi_chan_info *cinfo,
info->desc->max_rx_timeout_ms);
}
+/**
+ * scmi_xfer_raw_wait_for_message_response - An helper to wait for a message
+ * reply to an xfer raw request on a specific channel for the required timeout.
+ *
+ * @cinfo: SCMI channel info
+ * @xfer: Reference to the transfer being waited for.
+ * @timeout_ms: The maximum timeout in milliseconds
+ *
+ * Return: 0 on Success, error otherwise.
+ */
+int scmi_xfer_raw_wait_for_message_response(struct scmi_chan_info *cinfo,
+ struct scmi_xfer *xfer,
+ unsigned int timeout_ms)
+{
+ int ret;
+ struct scmi_info *info = handle_to_scmi_info(cinfo->handle);
+ struct device *dev = info->dev;
+
+ ret = scmi_wait_for_reply(dev, info->desc, cinfo, xfer, timeout_ms);
+ if (ret)
+ dev_dbg(dev, "timed out in RAW response - HDR:%08X\n",
+ pack_scmi_header(&xfer->hdr));
+
+ return ret;
+}
+
/**
* do_xfer() - Do one transfer
*
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v4 07/11] firmware: arm_scmi: Move errors defs and code to common.h
2022-10-19 20:46 ` Cristian Marussi
@ 2022-10-19 20:46 ` Cristian Marussi
-1 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
Move SCMI error codes definitions and helper to the common.h header
together with the delayed response timeout define.
No functional change.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
drivers/firmware/arm_scmi/common.h | 40 ++++++++++++++++++++++++++++++
drivers/firmware/arm_scmi/driver.c | 40 ------------------------------
2 files changed, 40 insertions(+), 40 deletions(-)
diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
index 3dceb69b8484..3b2b18d37093 100644
--- a/drivers/firmware/arm_scmi/common.h
+++ b/drivers/firmware/arm_scmi/common.h
@@ -27,6 +27,46 @@
#include "protocols.h"
#include "notify.h"
+#define SCMI_MAX_RESPONSE_TIMEOUT (2 * MSEC_PER_SEC)
+
+enum scmi_error_codes {
+ SCMI_SUCCESS = 0, /* Success */
+ SCMI_ERR_SUPPORT = -1, /* Not supported */
+ SCMI_ERR_PARAMS = -2, /* Invalid Parameters */
+ SCMI_ERR_ACCESS = -3, /* Invalid access/permission denied */
+ SCMI_ERR_ENTRY = -4, /* Not found */
+ SCMI_ERR_RANGE = -5, /* Value out of range */
+ SCMI_ERR_BUSY = -6, /* Device busy */
+ SCMI_ERR_COMMS = -7, /* Communication Error */
+ SCMI_ERR_GENERIC = -8, /* Generic Error */
+ SCMI_ERR_HARDWARE = -9, /* Hardware Error */
+ SCMI_ERR_PROTOCOL = -10,/* Protocol Error */
+};
+
+static const int scmi_linux_errmap[] = {
+ /* better than switch case as long as return value is continuous */
+ 0, /* SCMI_SUCCESS */
+ -EOPNOTSUPP, /* SCMI_ERR_SUPPORT */
+ -EINVAL, /* SCMI_ERR_PARAM */
+ -EACCES, /* SCMI_ERR_ACCESS */
+ -ENOENT, /* SCMI_ERR_ENTRY */
+ -ERANGE, /* SCMI_ERR_RANGE */
+ -EBUSY, /* SCMI_ERR_BUSY */
+ -ECOMM, /* SCMI_ERR_COMMS */
+ -EIO, /* SCMI_ERR_GENERIC */
+ -EREMOTEIO, /* SCMI_ERR_HARDWARE */
+ -EPROTO, /* SCMI_ERR_PROTOCOL */
+};
+
+static inline int scmi_to_linux_errno(int errno)
+{
+ int err_idx = -errno;
+
+ if (err_idx >= SCMI_SUCCESS && err_idx < ARRAY_SIZE(scmi_linux_errmap))
+ return scmi_linux_errmap[err_idx];
+ return -EIO;
+}
+
#define MSG_ID_MASK GENMASK(7, 0)
#define MSG_XTRACT_ID(hdr) FIELD_GET(MSG_ID_MASK, (hdr))
#define MSG_TYPE_MASK GENMASK(9, 8)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 3649435082bb..b504b5cdc55f 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -37,20 +37,6 @@
#define CREATE_TRACE_POINTS
#include <trace/events/scmi.h>
-enum scmi_error_codes {
- SCMI_SUCCESS = 0, /* Success */
- SCMI_ERR_SUPPORT = -1, /* Not supported */
- SCMI_ERR_PARAMS = -2, /* Invalid Parameters */
- SCMI_ERR_ACCESS = -3, /* Invalid access/permission denied */
- SCMI_ERR_ENTRY = -4, /* Not found */
- SCMI_ERR_RANGE = -5, /* Value out of range */
- SCMI_ERR_BUSY = -6, /* Device busy */
- SCMI_ERR_COMMS = -7, /* Communication Error */
- SCMI_ERR_GENERIC = -8, /* Generic Error */
- SCMI_ERR_HARDWARE = -9, /* Hardware Error */
- SCMI_ERR_PROTOCOL = -10,/* Protocol Error */
-};
-
/* List of all SCMI devices active in system */
static LIST_HEAD(scmi_list);
/* Protection for the entire list */
@@ -170,30 +156,6 @@ struct scmi_info {
#define handle_to_scmi_info(h) container_of(h, struct scmi_info, handle)
-static const int scmi_linux_errmap[] = {
- /* better than switch case as long as return value is continuous */
- 0, /* SCMI_SUCCESS */
- -EOPNOTSUPP, /* SCMI_ERR_SUPPORT */
- -EINVAL, /* SCMI_ERR_PARAM */
- -EACCES, /* SCMI_ERR_ACCESS */
- -ENOENT, /* SCMI_ERR_ENTRY */
- -ERANGE, /* SCMI_ERR_RANGE */
- -EBUSY, /* SCMI_ERR_BUSY */
- -ECOMM, /* SCMI_ERR_COMMS */
- -EIO, /* SCMI_ERR_GENERIC */
- -EREMOTEIO, /* SCMI_ERR_HARDWARE */
- -EPROTO, /* SCMI_ERR_PROTOCOL */
-};
-
-static inline int scmi_to_linux_errno(int errno)
-{
- int err_idx = -errno;
-
- if (err_idx >= SCMI_SUCCESS && err_idx < ARRAY_SIZE(scmi_linux_errmap))
- return scmi_linux_errmap[err_idx];
- return -EIO;
-}
-
void scmi_notification_instance_data_set(const struct scmi_handle *handle,
void *priv)
{
@@ -1109,8 +1071,6 @@ static void reset_rx_to_maxsz(const struct scmi_protocol_handle *ph,
xfer->rx.len = info->desc->max_msg_size;
}
-#define SCMI_MAX_RESPONSE_TIMEOUT (2 * MSEC_PER_SEC)
-
/**
* do_xfer_with_response() - Do one transfer and wait until the delayed
* response is received
--
2.34.1
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v4 07/11] firmware: arm_scmi: Move errors defs and code to common.h
@ 2022-10-19 20:46 ` Cristian Marussi
0 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
Move SCMI error codes definitions and helper to the common.h header
together with the delayed response timeout define.
No functional change.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
drivers/firmware/arm_scmi/common.h | 40 ++++++++++++++++++++++++++++++
drivers/firmware/arm_scmi/driver.c | 40 ------------------------------
2 files changed, 40 insertions(+), 40 deletions(-)
diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
index 3dceb69b8484..3b2b18d37093 100644
--- a/drivers/firmware/arm_scmi/common.h
+++ b/drivers/firmware/arm_scmi/common.h
@@ -27,6 +27,46 @@
#include "protocols.h"
#include "notify.h"
+#define SCMI_MAX_RESPONSE_TIMEOUT (2 * MSEC_PER_SEC)
+
+enum scmi_error_codes {
+ SCMI_SUCCESS = 0, /* Success */
+ SCMI_ERR_SUPPORT = -1, /* Not supported */
+ SCMI_ERR_PARAMS = -2, /* Invalid Parameters */
+ SCMI_ERR_ACCESS = -3, /* Invalid access/permission denied */
+ SCMI_ERR_ENTRY = -4, /* Not found */
+ SCMI_ERR_RANGE = -5, /* Value out of range */
+ SCMI_ERR_BUSY = -6, /* Device busy */
+ SCMI_ERR_COMMS = -7, /* Communication Error */
+ SCMI_ERR_GENERIC = -8, /* Generic Error */
+ SCMI_ERR_HARDWARE = -9, /* Hardware Error */
+ SCMI_ERR_PROTOCOL = -10,/* Protocol Error */
+};
+
+static const int scmi_linux_errmap[] = {
+ /* better than switch case as long as return value is continuous */
+ 0, /* SCMI_SUCCESS */
+ -EOPNOTSUPP, /* SCMI_ERR_SUPPORT */
+ -EINVAL, /* SCMI_ERR_PARAM */
+ -EACCES, /* SCMI_ERR_ACCESS */
+ -ENOENT, /* SCMI_ERR_ENTRY */
+ -ERANGE, /* SCMI_ERR_RANGE */
+ -EBUSY, /* SCMI_ERR_BUSY */
+ -ECOMM, /* SCMI_ERR_COMMS */
+ -EIO, /* SCMI_ERR_GENERIC */
+ -EREMOTEIO, /* SCMI_ERR_HARDWARE */
+ -EPROTO, /* SCMI_ERR_PROTOCOL */
+};
+
+static inline int scmi_to_linux_errno(int errno)
+{
+ int err_idx = -errno;
+
+ if (err_idx >= SCMI_SUCCESS && err_idx < ARRAY_SIZE(scmi_linux_errmap))
+ return scmi_linux_errmap[err_idx];
+ return -EIO;
+}
+
#define MSG_ID_MASK GENMASK(7, 0)
#define MSG_XTRACT_ID(hdr) FIELD_GET(MSG_ID_MASK, (hdr))
#define MSG_TYPE_MASK GENMASK(9, 8)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 3649435082bb..b504b5cdc55f 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -37,20 +37,6 @@
#define CREATE_TRACE_POINTS
#include <trace/events/scmi.h>
-enum scmi_error_codes {
- SCMI_SUCCESS = 0, /* Success */
- SCMI_ERR_SUPPORT = -1, /* Not supported */
- SCMI_ERR_PARAMS = -2, /* Invalid Parameters */
- SCMI_ERR_ACCESS = -3, /* Invalid access/permission denied */
- SCMI_ERR_ENTRY = -4, /* Not found */
- SCMI_ERR_RANGE = -5, /* Value out of range */
- SCMI_ERR_BUSY = -6, /* Device busy */
- SCMI_ERR_COMMS = -7, /* Communication Error */
- SCMI_ERR_GENERIC = -8, /* Generic Error */
- SCMI_ERR_HARDWARE = -9, /* Hardware Error */
- SCMI_ERR_PROTOCOL = -10,/* Protocol Error */
-};
-
/* List of all SCMI devices active in system */
static LIST_HEAD(scmi_list);
/* Protection for the entire list */
@@ -170,30 +156,6 @@ struct scmi_info {
#define handle_to_scmi_info(h) container_of(h, struct scmi_info, handle)
-static const int scmi_linux_errmap[] = {
- /* better than switch case as long as return value is continuous */
- 0, /* SCMI_SUCCESS */
- -EOPNOTSUPP, /* SCMI_ERR_SUPPORT */
- -EINVAL, /* SCMI_ERR_PARAM */
- -EACCES, /* SCMI_ERR_ACCESS */
- -ENOENT, /* SCMI_ERR_ENTRY */
- -ERANGE, /* SCMI_ERR_RANGE */
- -EBUSY, /* SCMI_ERR_BUSY */
- -ECOMM, /* SCMI_ERR_COMMS */
- -EIO, /* SCMI_ERR_GENERIC */
- -EREMOTEIO, /* SCMI_ERR_HARDWARE */
- -EPROTO, /* SCMI_ERR_PROTOCOL */
-};
-
-static inline int scmi_to_linux_errno(int errno)
-{
- int err_idx = -errno;
-
- if (err_idx >= SCMI_SUCCESS && err_idx < ARRAY_SIZE(scmi_linux_errmap))
- return scmi_linux_errmap[err_idx];
- return -EIO;
-}
-
void scmi_notification_instance_data_set(const struct scmi_handle *handle,
void *priv)
{
@@ -1109,8 +1071,6 @@ static void reset_rx_to_maxsz(const struct scmi_protocol_handle *ph,
xfer->rx.len = info->desc->max_msg_size;
}
-#define SCMI_MAX_RESPONSE_TIMEOUT (2 * MSEC_PER_SEC)
-
/**
* do_xfer_with_response() - Do one transfer and wait until the delayed
* response is received
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v4 08/11] firmware: arm_scmi: Add raw transmission support
2022-10-19 20:46 ` Cristian Marussi
@ 2022-10-19 20:46 ` Cristian Marussi
-1 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
Add SCMI Raw mode support which exposes a userspace interface to allow for
bare SCMI command injection and snooping from userspace.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
v3 --> v4
- fix handling of O_NONBLOCK raw_mode read requests
- add support for polled/nocomnpletion_irq transports
- removed inlines
v2 --> v3
- changed to dev_dbg when retrying inflight reg
- refactored and simplfiied waiters deferred worker
- fixed sparse errors about LE and __poll_t
v1 --> v2
- make use of proper channel depending on protocol at hand (using
scmi_xfer_raw_channel_get to lookup related DT config)
- refactored scmi_inflight_register call
- added debugfs docs and comments
---
drivers/firmware/arm_scmi/Kconfig | 13 +
drivers/firmware/arm_scmi/Makefile | 1 +
drivers/firmware/arm_scmi/raw_mode.c | 1244 ++++++++++++++++++++++++++
drivers/firmware/arm_scmi/raw_mode.h | 29 +
4 files changed, 1287 insertions(+)
create mode 100644 drivers/firmware/arm_scmi/raw_mode.c
create mode 100644 drivers/firmware/arm_scmi/raw_mode.h
diff --git a/drivers/firmware/arm_scmi/Kconfig b/drivers/firmware/arm_scmi/Kconfig
index a14f65444b35..ab726a92ac2f 100644
--- a/drivers/firmware/arm_scmi/Kconfig
+++ b/drivers/firmware/arm_scmi/Kconfig
@@ -23,6 +23,19 @@ config ARM_SCMI_PROTOCOL
if ARM_SCMI_PROTOCOL
+config ARM_SCMI_RAW_MODE_SUPPORT
+ bool "Enable support for SCMI Raw transmission mode"
+ help
+ Enable support for SCMI Raw transmission mode.
+
+ If enabled allows the direct injection and snooping of SCMI bare
+ messages through a dedicated debugfs interface.
+ It is meant to be used by SCMI compliance/testing suites.
+
+ When enabled regular SCMI drivers interactions are inhibited in
+ order to avoid unexpected interactions with the SCMI Raw message
+ flow. If unsure say N.
+
config ARM_SCMI_HAVE_TRANSPORT
bool
help
diff --git a/drivers/firmware/arm_scmi/Makefile b/drivers/firmware/arm_scmi/Makefile
index 9ea86f8cc8f7..7c1aca60c8ce 100644
--- a/drivers/firmware/arm_scmi/Makefile
+++ b/drivers/firmware/arm_scmi/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
scmi-bus-y = bus.o
scmi-driver-y = driver.o notify.o
+scmi-driver-$(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT) += raw_mode.o
scmi-transport-$(CONFIG_ARM_SCMI_HAVE_SHMEM) = shmem.o
scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_MAILBOX) += mailbox.o
scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_SMC) += smc.o
diff --git a/drivers/firmware/arm_scmi/raw_mode.c b/drivers/firmware/arm_scmi/raw_mode.c
new file mode 100644
index 000000000000..3fdfc0564286
--- /dev/null
+++ b/drivers/firmware/arm_scmi/raw_mode.c
@@ -0,0 +1,1244 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * System Control and Management Interface (SCMI) Raw mode support
+ *
+ * Copyright (C) 2022 ARM Ltd.
+ */
+/**
+ * DOC: Theory of operation
+ *
+ * When enabled the SCMI Raw mode support exposes a userspace API which allows
+ * to send and receive SCMI commands, replies and notifications from a user
+ * application through injection and snooping of bare SCMI messages in binary
+ * little-endian format.
+ *
+ * Such injected SCMI transactions will then be routed through the SCMI core
+ * stack towards the SCMI backend server using whatever SCMI transport is
+ * currently configured on the system under test.
+ *
+ * It is meant to help in running any sort of SCMI backend server testing, no
+ * matter where the server is placed, as long as it is normally reachable via
+ * the transport configured on the system.
+ *
+ * It is activated by a Kernel configuration option since it is NOT meant to
+ * be used in production but only during development and in CI deployments.
+ *
+ * In order to avoid possible interferences between the SCMI Raw transactions
+ * originated from a test-suite and the normal operations of the SCMI drivers,
+ * when Raw mode is enabled, by default, all the regular SCMI drivers are
+ * inhibited.
+ *
+ * The exposed API is as follows:
+ *
+ * /sys/kernel/debug/scmi_raw/
+ * |-- errors
+ * |-- message
+ * |-- message_async
+ * |-- notification
+ * |-- reset
+ * |-- transport_max_msg_size
+ * |-- transport_rx_timeout_ms
+ * |-- transport_tx_max_msg
+ *
+ * where:
+ *
+ * - errors: used to read back timed-out and unexpected replies
+ * - message*: used to send sync/async commands and read back immediate and
+ * delayed reponses (if any)
+ * - notification: used to read any notification being emitted by the system
+ * (if previously enabled by the user app)
+ * - reset: used to flush the queues of messages (of any kind) still pending
+ * to be read; this is useful at test-suite start/stop to get
+ * rid of any unread messages from the previous run.
+ * - transport*: a bunch of configurations useful to setup the user
+ * application expectations in terms of timeouts and message
+ * characteristics.
+ *
+ * Each write to the message* entries causes one command request to be built
+ * and sent while the replies or delayed response are read back from those same
+ * entries one message at time (receiving an EOF at each message boundary).
+ *
+ * The user application running the test is in charge of handling timeouts
+ * on replies and properly choosing SCMI sequence numbers for the outgoing
+ * requests (using the same sequence number is supported but discouraged).
+ *
+ * Injection of multiple in-flight requests is supported as long as the user
+ * application uses properly distinct sequence numbers for concurrent requests
+ * and takes care to properly manage all the related issues about concurrency
+ * and command/reply pairing. Keep in mind that, anyway, the real level of
+ * parallelism attainable in such scenario is dependent on the characteristics
+ * of the underlying transport being used.
+ *
+ * Since the SCMI core regular stack is partially used to deliver and collect
+ * the messages, late replies arrived after timeouts and any other sort of
+ * unexpected message can be identified by the SCMI core as usual and they will
+ * be reported as messages under "errors" for later analysis.
+ */
+
+#include <linux/bitmap.h>
+#include <linux/debugfs.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/export.h>
+#include <linux/idr.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/fs.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/poll.h>
+#include <linux/slab.h>
+
+#include "common.h"
+
+#include "raw_mode.h"
+
+#include <trace/events/scmi.h>
+
+#define SCMI_XFER_RAW_MAX_RETRIES 10
+
+/**
+ * struct scmi_raw_mode_info - Structure holding SCMI Raw instance data
+ *
+ * @handle: Pointer to SCMI entity handle to use
+ * @desc: Pointer to the transport descriptor to use
+ * @tx_max_msg: Maximum number of concurrent TX in-flight messages
+ * @free_raw_bufs: An array of freelists heads used to keep unused raw buffers
+ * @free_bufs_lock: Spinlocks used to protect access to each @free_raw_bufs
+ * @msg_q: An array of lists to queue snooped messages waiting to be read out
+ * @msg_q_lock: Spinlocks used to protect access to each @msg_q
+ * @wqs: An array of waitqueues used to wait and poll on related @msg_q
+ * @free_waiters: Head of freelist for unused waiters
+ * @free_mtx: A mutex to protect the waiters freelist
+ * @active_waiters: Head of list for currently active and used waiters
+ * @active_mtx: A mutex to protect the active waiters list
+ * @waiters_work: A work descriptor to be used with the workqueue machinery
+ * @wait_wq: A workqueue reference to the created workqueue
+ * @dentry: Top debugfs root dentry for SCMI Raw
+ * @gid: A group ID used for devres accounting
+ *
+ * Note that this descriptor is passed back to the core after SCMI Raw is
+ * initialized as an opaque handle to use by subsequent SCMI Raw call hooks.
+ *
+ */
+struct scmi_raw_mode_info {
+ const struct scmi_handle *handle;
+ const struct scmi_desc *desc;
+ int tx_max_msg;
+ struct list_head free_raw_bufs[SCMI_RAW_MAX_QUEUE];
+ /* Protect free_raw_bufs[] lists */
+ spinlock_t free_bufs_lock[SCMI_RAW_MAX_QUEUE];
+ struct list_head msg_q[SCMI_RAW_MAX_QUEUE];
+ /* Protect msg_q[] lists */
+ spinlock_t msg_q_lock[SCMI_RAW_MAX_QUEUE];
+ wait_queue_head_t wqs[SCMI_RAW_MAX_QUEUE];
+ struct list_head free_waiters;
+ /* Protect free_waiters list */
+ struct mutex free_mtx;
+ struct list_head active_waiters;
+ /* Protect active_waiters list */
+ struct mutex active_mtx;
+ struct work_struct waiters_work;
+ struct workqueue_struct *wait_wq;
+ struct dentry *dentry;
+ void *gid;
+};
+
+/**
+ * struct scmi_xfer_raw_waiter - Structure to describe an xfer to be waited for
+ *
+ * @start_jiffies: The timestamp in jiffies of when this structure was queued.
+ * @cinfo: A reference to the channel to use for this transaction
+ * @xfer: A reference to the xfer to be waited for
+ * @async_response: A completion to be, optionally, used for async waits: it
+ * will be setup by @scmi_do_xfer_raw_start, if needed, to be
+ * pointed at by xfer->async_done.
+ * @node: A list node.
+ */
+struct scmi_xfer_raw_waiter {
+ unsigned long start_jiffies;
+ struct scmi_chan_info *cinfo;
+ struct scmi_xfer *xfer;
+ struct completion async_response;
+ struct list_head node;
+};
+
+/**
+ * struct scmi_raw_buffer - Structure to hold a full SCMI message
+ *
+ * @max_len: The maximum allowed message size (header included) that can be
+ * stored into @msg
+ * @msg: A message buffer used to collect a full message grabbed from an xfer.
+ * @node: A list node.
+ */
+struct scmi_raw_buffer {
+ size_t max_len;
+ struct scmi_msg msg;
+ struct list_head node;
+};
+
+/**
+ * struct scmi_dbg_raw_data - Structure holding data needed by the debugfs
+ * layer
+ *
+ * @raw: A reference to the Raw instance.
+ * @tx: A message buffer used to collect TX message on write.
+ * @tx_size: The effective size of the TX message.
+ * @tx_req_size: The final expected size of the complete TX message.
+ * @rx: A message buffer to collect RX message on read.
+ * @rx_size: The effective size of the RX message.
+ */
+struct scmi_dbg_raw_data {
+ struct scmi_raw_mode_info *raw;
+ struct scmi_msg tx;
+ size_t tx_size;
+ size_t tx_req_size;
+ struct scmi_msg rx;
+ size_t rx_size;
+};
+
+static struct scmi_raw_buffer *
+scmi_raw_buffer_get(struct scmi_raw_mode_info *raw, unsigned int idx)
+{
+ unsigned long flags;
+ struct scmi_raw_buffer *rb = NULL;
+ struct list_head *head = &raw->free_raw_bufs[idx];
+
+ spin_lock_irqsave(&raw->free_bufs_lock[idx], flags);
+ if (!list_empty(head)) {
+ rb = list_first_entry(head, struct scmi_raw_buffer, node);
+ list_del_init(&rb->node);
+ }
+ spin_unlock_irqrestore(&raw->free_bufs_lock[idx], flags);
+
+ return rb;
+}
+
+static void scmi_raw_buffer_put(struct scmi_raw_mode_info *raw,
+ struct scmi_raw_buffer *rb, unsigned int idx)
+{
+ unsigned long flags;
+
+ /* Reset to full buffer length */
+ rb->msg.len = rb->max_len;
+
+ spin_lock_irqsave(&raw->free_bufs_lock[idx], flags);
+ list_add_tail(&rb->node, &raw->free_raw_bufs[idx]);
+ spin_unlock_irqrestore(&raw->free_bufs_lock[idx], flags);
+}
+
+static void scmi_raw_buffer_enqueue(struct scmi_raw_mode_info *raw,
+ struct scmi_raw_buffer *rb,
+ unsigned int idx)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&raw->msg_q_lock[idx], flags);
+ list_add_tail(&rb->node, &raw->msg_q[idx]);
+ spin_unlock_irqrestore(&raw->msg_q_lock[idx], flags);
+
+ wake_up_interruptible(&raw->wqs[idx]);
+}
+
+static struct scmi_raw_buffer *
+scmi_raw_buffer_dequeue(struct scmi_raw_mode_info *raw, unsigned int idx)
+{
+ unsigned long flags;
+ struct scmi_raw_buffer *rb = NULL;
+
+ spin_lock_irqsave(&raw->msg_q_lock[idx], flags);
+ if (!list_empty(&raw->msg_q[idx])) {
+ rb = list_first_entry(&raw->msg_q[idx],
+ struct scmi_raw_buffer, node);
+ list_del_init(&rb->node);
+ }
+ spin_unlock_irqrestore(&raw->msg_q_lock[idx], flags);
+
+ return rb;
+}
+
+static void scmi_raw_buffer_queue_flush(struct scmi_raw_mode_info *raw,
+ unsigned int idx)
+{
+ struct scmi_raw_buffer *rb;
+
+ do {
+ rb = scmi_raw_buffer_dequeue(raw, idx);
+ if (rb)
+ scmi_raw_buffer_put(raw, rb, idx);
+ } while (rb);
+}
+
+static struct scmi_xfer_raw_waiter *
+scmi_xfer_raw_waiter_get(struct scmi_raw_mode_info *raw, struct scmi_xfer *xfer,
+ struct scmi_chan_info *cinfo, bool async)
+{
+ struct scmi_xfer_raw_waiter *rw = NULL;
+
+ mutex_lock(&raw->free_mtx);
+ if (!list_empty(&raw->free_waiters)) {
+ rw = list_first_entry(&raw->free_waiters,
+ struct scmi_xfer_raw_waiter, node);
+ list_del_init(&rw->node);
+
+ if (async) {
+ reinit_completion(&rw->async_response);
+ xfer->async_done = &rw->async_response;
+ }
+
+ rw->cinfo = cinfo;
+ rw->xfer = xfer;
+ }
+ mutex_unlock(&raw->free_mtx);
+
+ return rw;
+}
+
+static void scmi_xfer_raw_waiter_put(struct scmi_raw_mode_info *raw,
+ struct scmi_xfer_raw_waiter *rw)
+{
+ if (rw->xfer) {
+ rw->xfer->async_done = NULL;
+ rw->xfer = NULL;
+ }
+
+ mutex_lock(&raw->free_mtx);
+ list_add_tail(&rw->node, &raw->free_waiters);
+ mutex_unlock(&raw->free_mtx);
+}
+
+static void scmi_xfer_raw_waiter_enqueue(struct scmi_raw_mode_info *raw,
+ struct scmi_xfer_raw_waiter *rw)
+{
+ /* A timestamp for the deferred worker to know how much this has aged */
+ rw->start_jiffies = jiffies;
+
+ trace_scmi_xfer_response_wait(rw->xfer->transfer_id, rw->xfer->hdr.id,
+ rw->xfer->hdr.protocol_id,
+ rw->xfer->hdr.seq,
+ raw->desc->max_rx_timeout_ms,
+ rw->xfer->hdr.poll_completion);
+
+ mutex_lock(&raw->active_mtx);
+ list_add_tail(&rw->node, &raw->active_waiters);
+ mutex_unlock(&raw->active_mtx);
+
+ /* kick waiter work */
+ queue_work(raw->wait_wq, &raw->waiters_work);
+}
+
+static struct scmi_xfer_raw_waiter *
+scmi_xfer_raw_waiter_dequeue(struct scmi_raw_mode_info *raw)
+{
+ struct scmi_xfer_raw_waiter *rw = NULL;
+
+ mutex_lock(&raw->active_mtx);
+ if (!list_empty(&raw->active_waiters)) {
+ rw = list_first_entry(&raw->active_waiters,
+ struct scmi_xfer_raw_waiter, node);
+ list_del_init(&rw->node);
+ }
+ mutex_unlock(&raw->active_mtx);
+
+ return rw;
+}
+
+/**
+ * scmi_xfer_raw_worker - Work function to wait for Raw xfers completions
+ *
+ * @work: A reference to the work.
+ *
+ * In SCMI Raw mode, once a user-provided injected SCMI message is sent, we
+ * cannot wait to receive its response (if any) in the context of the injection
+ * routines so as not to leave the userspace write syscall, which delivered the
+ * SCMI message to send, pending till eventually a reply is received.
+ * Userspace should and will poll/wait instead on the read syscalls which will
+ * be in charge of reading a received reply (if any).
+ *
+ * Even though reply messages are collected and reported into the SCMI Raw layer
+ * on the RX path, nonetheless we have to properly wait for their completion as
+ * usual (and async_completion too if needed) in order to properly release the
+ * xfer structure at the end: to do this out of the context of the write/send
+ * these waiting jobs are delegated to this deferred worker.
+ *
+ * Any sent xfer, to be waited for, is timestamped and queued for later
+ * consumption by this worker: queue aging is accounted for while choosing a
+ * timeout for the completion, BUT we do not really care here if we end up
+ * accidentally waiting for a bit too long.
+ */
+static void scmi_xfer_raw_worker(struct work_struct *work)
+{
+ struct scmi_raw_mode_info *raw;
+ struct device *dev;
+ unsigned long max_tmo;
+
+ raw = container_of(work, struct scmi_raw_mode_info, waiters_work);
+ dev = raw->handle->dev;
+ max_tmo = msecs_to_jiffies(raw->desc->max_rx_timeout_ms);
+
+ do {
+ int ret = 0;
+ unsigned int timeout_ms;
+ unsigned long aging;
+ struct scmi_xfer *xfer;
+ struct scmi_xfer_raw_waiter *rw;
+ struct scmi_chan_info *cinfo;
+
+ rw = scmi_xfer_raw_waiter_dequeue(raw);
+ if (!rw)
+ return;
+
+ cinfo = rw->cinfo;
+ xfer = rw->xfer;
+ /*
+ * Waiters are queued by wait-deadline at the end, so some of
+ * them could have been already expired when processed, BUT we
+ * have to check the completion status anyway just in case a
+ * virtually expired (aged) transaction was indeed completed
+ * fine and we'll have to wait for the asynchronous part (if
+ * any): for this reason a 1 ms timeout is used for already
+ * expired/aged xfers.
+ */
+ aging = jiffies - rw->start_jiffies;
+ timeout_ms = max_tmo > aging ?
+ jiffies_to_msecs(max_tmo - aging) : 1;
+
+ ret = scmi_xfer_raw_wait_for_message_response(cinfo, xfer,
+ timeout_ms);
+ if (!ret && xfer->hdr.status)
+ ret = scmi_to_linux_errno(xfer->hdr.status);
+
+ if (raw->desc->ops->mark_txdone)
+ raw->desc->ops->mark_txdone(rw->cinfo, ret, xfer);
+
+ trace_scmi_xfer_end(xfer->transfer_id, xfer->hdr.id,
+ xfer->hdr.protocol_id, xfer->hdr.seq, ret);
+
+ /* Wait also for an async delayed response if needed */
+ if (!ret && xfer->async_done) {
+ unsigned long tmo = msecs_to_jiffies(SCMI_MAX_RESPONSE_TIMEOUT);
+
+ if (!wait_for_completion_timeout(xfer->async_done, tmo))
+ dev_err(dev,
+ "timed out in RAW delayed resp - HDR:%08X\n",
+ pack_scmi_header(&xfer->hdr));
+ }
+
+ /* Release waiter and xfer */
+ scmi_xfer_raw_put(raw->handle, xfer);
+ scmi_xfer_raw_waiter_put(raw, rw);
+ } while (1);
+}
+
+static void scmi_xfer_raw_reset(struct scmi_raw_mode_info *raw)
+{
+ int i;
+
+ dev_info(raw->handle->dev, "Resetting SCMI Raw stack.\n");
+
+ for (i = 0; i < SCMI_RAW_MAX_QUEUE; i++)
+ scmi_raw_buffer_queue_flush(raw, i);
+}
+
+/**
+ * scmi_xfer_raw_get_init - An helper to build a valid xfer from the provided
+ * bare SCMI message.
+ *
+ * @raw: A reference to the Raw instance.
+ * @buf: A buffer containing the whole SCMI message to send (including the
+ * header) in little-endian binary formmat.
+ * @len: Length of the message in @buf.
+ * @p: A pointer to return the initialized Raw xfer.
+ *
+ * After an xfer is picked from the TX pool and filled in with the message
+ * content, the xfer is registered as pending with the core in the usual way
+ * using the original sequence number provided by the user with the message.
+ *
+ * Note that, in case the testing user application is NOT using distinct
+ * sequence-numbers between successive SCMI messages such registration could
+ * fail temporarily if the previous message, using the same sequence number,
+ * had still not released; in such a case we just wait and retry.
+ *
+ * Return: 0 on Success
+ */
+static int scmi_xfer_raw_get_init(struct scmi_raw_mode_info *raw, void *buf,
+ size_t len, struct scmi_xfer **p)
+{
+ u32 msg_hdr;
+ size_t tx_size;
+ struct scmi_xfer *xfer;
+ int ret, retry = SCMI_XFER_RAW_MAX_RETRIES;
+ struct device *dev = raw->handle->dev;
+
+ if (!buf || len < sizeof(u32))
+ return -EINVAL;
+
+ tx_size = len - sizeof(u32);
+ /* Ensure we have sane transfer sizes */
+ if (tx_size > raw->desc->max_msg_size)
+ return -ERANGE;
+
+ xfer = scmi_xfer_raw_get(raw->handle);
+ if (IS_ERR(xfer)) {
+ dev_warn(dev, "RAW - Cannot get a free RAW xfer !\n");
+ return PTR_ERR(xfer);
+ }
+
+ /* Build xfer from the provided SCMI bare LE message */
+ msg_hdr = le32_to_cpu(*((__le32 *)buf));
+ unpack_scmi_header(msg_hdr, &xfer->hdr);
+ xfer->hdr.seq = (u16)MSG_XTRACT_TOKEN(msg_hdr);
+ /* Polling not supported */
+ xfer->hdr.poll_completion = false;
+ xfer->hdr.status = SCMI_SUCCESS;
+ xfer->tx.len = tx_size;
+ xfer->rx.len = raw->desc->max_msg_size;
+ /* Clear the whole TX buffer */
+ memset(xfer->tx.buf, 0x00, raw->desc->max_msg_size);
+ if (xfer->tx.len)
+ memcpy(xfer->tx.buf, (u8 *)buf + sizeof(msg_hdr), xfer->tx.len);
+ *p = xfer;
+
+ /*
+ * In flight registration can temporarily fail in case of Raw messages
+ * if the user injects messages without using monotonically increasing
+ * sequence numbers since, in Raw mode, the xfer (and the token) is
+ * finally released later by a deferred worker. Just retry for a while.
+ */
+ do {
+ ret = scmi_xfer_raw_inflight_register(raw->handle, xfer);
+ if (ret) {
+ dev_dbg(dev,
+ "...retrying[%d] inflight registration\n",
+ retry);
+ msleep(raw->desc->max_rx_timeout_ms /
+ SCMI_XFER_RAW_MAX_RETRIES);
+ }
+ } while (ret && --retry);
+
+ if (ret) {
+ dev_warn(dev,
+ "RAW - Could NOT register xfer %d in-flight HDR:0x%08X\n",
+ xfer->hdr.seq, msg_hdr);
+ scmi_xfer_raw_put(raw->handle, xfer);
+ }
+
+ return ret;
+}
+
+/**
+ * scmi_do_xfer_raw_start - An helper to send a valid raw xfer
+ *
+ * @raw: A reference to the Raw instance.
+ * @xfer: The xfer to send
+ * @async: A flag stating if an asynchronous command is required.
+ *
+ * This function send a previously built raw xfer using an appropriate channel
+ * and queues the related waiting work.
+ *
+ * Note that we need to know explicitly if the required command is meant to be
+ * asynchronous in kind since we have to properly setup the waiter.
+ * (and deducing this from the payload is weak and do not scale given there is
+ * NOT a common header-flag stating if the command is asynchronous or not)
+ *
+ * Return: 0 on Success
+ */
+static int scmi_do_xfer_raw_start(struct scmi_raw_mode_info *raw,
+ struct scmi_xfer *xfer, bool async)
+{
+ int ret;
+ struct scmi_chan_info *cinfo;
+ struct scmi_xfer_raw_waiter *rw;
+ struct device *dev = raw->handle->dev;
+
+ cinfo = scmi_xfer_raw_channel_get(raw->handle, xfer->hdr.protocol_id);
+ if (IS_ERR(cinfo))
+ return PTR_ERR(cinfo);
+
+ rw = scmi_xfer_raw_waiter_get(raw, xfer, cinfo, async);
+ if (!rw) {
+ dev_warn(dev, "RAW - Cannot get a free waiter !\n");
+ return -ENOMEM;
+ }
+
+ /* True ONLY if also supported by transport. */
+ if (is_polling_enabled(cinfo, raw->desc))
+ xfer->hdr.poll_completion = true;
+
+ reinit_completion(&xfer->done);
+ /* Make sure xfer state update is visible before sending */
+ smp_store_mb(xfer->state, SCMI_XFER_SENT_OK);
+
+ trace_scmi_xfer_begin(xfer->transfer_id, xfer->hdr.id,
+ xfer->hdr.protocol_id, xfer->hdr.seq,
+ xfer->hdr.poll_completion);
+
+ ret = raw->desc->ops->send_message(rw->cinfo, xfer);
+ if (ret) {
+ dev_err(dev, "Failed to send RAW message %d\n", ret);
+ scmi_xfer_raw_waiter_put(raw, rw);
+ return ret;
+ }
+
+ trace_scmi_msg_dump(xfer->hdr.protocol_id, xfer->hdr.id, "CMND",
+ xfer->hdr.seq, xfer->hdr.status,
+ xfer->tx.buf, xfer->tx.len);
+
+ scmi_xfer_raw_waiter_enqueue(raw, rw);
+
+ return ret;
+}
+
+/**
+ * scmi_raw_message_send - An helper to build and send an SCMI command using
+ * the provided SCMI bare message buffer
+ *
+ * @raw: A reference to the Raw instance.
+ * @buf: A buffer containing the whole SCMI message to send (including the
+ * header) in little-endian binary format.
+ * @len: Length of the message in @buf.
+ * @async: A flag stating if an asynchronous command is required.
+ *
+ * Return: 0 on Success
+ */
+static int scmi_raw_message_send(struct scmi_raw_mode_info *raw,
+ void *buf, size_t len, bool async)
+{
+ int ret;
+ struct scmi_xfer *xfer;
+
+ ret = scmi_xfer_raw_get_init(raw, buf, len, &xfer);
+ if (ret)
+ return ret;
+
+ ret = scmi_do_xfer_raw_start(raw, xfer, async);
+ if (ret)
+ scmi_xfer_raw_put(raw->handle, xfer);
+
+ return ret;
+}
+
+static struct scmi_raw_buffer *
+scmi_raw_message_dequeue(struct scmi_raw_mode_info *raw, unsigned int idx,
+ bool o_nonblock)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&raw->msg_q_lock[idx], flags);
+ while (list_empty(&raw->msg_q[idx])) {
+ spin_unlock_irqrestore(&raw->msg_q_lock[idx], flags);
+
+ if (o_nonblock)
+ return ERR_PTR(-EAGAIN);
+
+ if (wait_event_interruptible(raw->wqs[idx],
+ !list_empty(&raw->msg_q[idx])))
+ return ERR_PTR(-ERESTARTSYS);
+
+ spin_lock_irqsave(&raw->msg_q_lock[idx], flags);
+ }
+ spin_unlock_irqrestore(&raw->msg_q_lock[idx], flags);
+
+ return scmi_raw_buffer_dequeue(raw, idx);
+}
+
+/**
+ * scmi_raw_message_receive - An helper to dequeue and report the next
+ * available enqueued raw message payload that has been collected.
+ *
+ * @raw: A reference to the Raw instance.
+ * @buf: A buffer to get hold of the whole SCMI message received and represented
+ * in little-endian binary format.
+ * @len: Length of @buf.
+ * @size: The effective size of the message copied into @buf
+ * @idx: The index of the queue to pick the next queued message from.
+ * @o_nonblock: A flag to request a non-blocking message dequeue.
+ *
+ * Return: 0 on Success
+ */
+static int scmi_raw_message_receive(struct scmi_raw_mode_info *raw,
+ void *buf, size_t len, size_t *size,
+ unsigned int idx,
+ bool o_nonblock)
+{
+ int ret = 0;
+ struct scmi_raw_buffer *rb;
+
+ rb = scmi_raw_message_dequeue(raw, idx, o_nonblock);
+ if (IS_ERR(rb)) {
+ dev_dbg(raw->handle->dev, "RAW - No message available!\n");
+ return PTR_ERR(rb);
+ }
+
+ if (rb->msg.len <= len) {
+ memcpy(buf, rb->msg.buf, rb->msg.len);
+ *size = rb->msg.len;
+ } else {
+ ret = -ENOSPC;
+ }
+
+ scmi_raw_buffer_put(raw, rb, idx);
+
+ return ret;
+}
+
+/* SCMI Raw debugfs helpers */
+
+static ssize_t scmi_dbg_raw_mode_common_read(struct file *filp,
+ char __user *buf,
+ size_t count, loff_t *ppos,
+ unsigned int idx)
+{
+ ssize_t cnt;
+ struct scmi_dbg_raw_data *rd = filp->private_data;
+
+ if (!rd->rx_size) {
+ int ret;
+
+ ret = scmi_raw_message_receive(rd->raw, rd->rx.buf, rd->rx.len,
+ &rd->rx_size, idx,
+ filp->f_flags & O_NONBLOCK);
+ if (ret) {
+ rd->rx_size = 0;
+ return ret;
+ }
+
+ /* Reset any previous filepos change, including writes */
+ *ppos = 0;
+ } else if (*ppos == rd->rx_size) {
+ /* Return EOF once all the message has been read-out */
+ rd->rx_size = 0;
+ return 0;
+ }
+
+ cnt = simple_read_from_buffer(buf, count, ppos,
+ rd->rx.buf, rd->rx_size);
+
+ return cnt;
+}
+
+static ssize_t scmi_dbg_raw_mode_common_write(struct file *filp,
+ const char __user *buf,
+ size_t count, loff_t *ppos,
+ bool async)
+{
+ int ret;
+ struct scmi_dbg_raw_data *rd = filp->private_data;
+
+ if (count > rd->tx.len - rd->tx_size)
+ return -ENOSPC;
+
+ /* On first write attempt @count carries the total full message size. */
+ if (!rd->tx_size)
+ rd->tx_req_size = count;
+
+ /*
+ * Gather a full message, possibly across multiple interrupted wrrtes,
+ * before sending it with a single RAW xfer.
+ */
+ if (rd->tx_size < rd->tx_req_size) {
+ size_t cnt;
+
+ cnt = simple_write_to_buffer(rd->tx.buf, rd->tx.len, ppos,
+ buf, count);
+ rd->tx_size += cnt;
+ if (cnt < count)
+ return cnt;
+ }
+
+ ret = scmi_raw_message_send(rd->raw, rd->tx.buf, rd->tx_size, async);
+
+ /* Reset ppos for next message ... */
+ rd->tx_size = 0;
+
+ return ret ?: count;
+}
+
+static __poll_t scmi_test_dbg_raw_common_poll(struct file *filp,
+ struct poll_table_struct *wait,
+ unsigned int idx)
+{
+ unsigned long flags;
+ struct scmi_dbg_raw_data *rd = filp->private_data;
+ __poll_t mask = 0;
+
+ poll_wait(filp, &rd->raw->wqs[idx], wait);
+
+ spin_lock_irqsave(&rd->raw->msg_q_lock[idx], flags);
+ if (!list_empty(&rd->raw->msg_q[idx]))
+ mask = EPOLLIN | EPOLLRDNORM;
+ spin_unlock_irqrestore(&rd->raw->msg_q_lock[idx], flags);
+
+ return mask;
+}
+
+static ssize_t scmi_dbg_raw_mode_message_read(struct file *filp,
+ char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ return scmi_dbg_raw_mode_common_read(filp, buf, count, ppos,
+ SCMI_RAW_REPLY_QUEUE);
+}
+
+static ssize_t scmi_dbg_raw_mode_message_write(struct file *filp,
+ const char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ return scmi_dbg_raw_mode_common_write(filp, buf, count, ppos, false);
+}
+
+static __poll_t scmi_dbg_raw_mode_message_poll(struct file *filp,
+ struct poll_table_struct *wait)
+{
+ return scmi_test_dbg_raw_common_poll(filp, wait, SCMI_RAW_REPLY_QUEUE);
+}
+
+static int scmi_dbg_raw_mode_open(struct inode *inode, struct file *filp)
+{
+ struct scmi_raw_mode_info *raw;
+ struct scmi_dbg_raw_data *rd;
+
+ if (!inode->i_private)
+ return -ENODEV;
+
+ raw = inode->i_private;
+ rd = kzalloc(sizeof(*rd), GFP_KERNEL);
+ if (!rd)
+ return -ENOMEM;
+
+ rd->rx.len = raw->desc->max_msg_size + sizeof(u32);
+ rd->rx.buf = kzalloc(rd->rx.len, GFP_KERNEL);
+ if (!rd->rx.buf) {
+ kfree(rd);
+ return -ENOMEM;
+ }
+
+ rd->tx.len = raw->desc->max_msg_size + sizeof(u32);
+ rd->tx.buf = kzalloc(rd->tx.len, GFP_KERNEL);
+ if (!rd->tx.buf) {
+ kfree(rd->rx.buf);
+ kfree(rd);
+ return -ENOMEM;
+ }
+
+ rd->raw = raw;
+ filp->private_data = rd;
+
+ return 0;
+}
+
+static int scmi_dbg_raw_mode_release(struct inode *inode, struct file *filp)
+{
+ struct scmi_dbg_raw_data *rd = filp->private_data;
+
+ kfree(rd->rx.buf);
+ kfree(rd->tx.buf);
+ kfree(rd);
+
+ return 0;
+}
+
+static ssize_t scmi_dbg_raw_mode_reset_write(struct file *filp,
+ const char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ struct scmi_dbg_raw_data *rd = filp->private_data;
+
+ scmi_xfer_raw_reset(rd->raw);
+
+ return count;
+}
+
+static const struct file_operations scmi_dbg_raw_mode_reset_fops = {
+ .open = scmi_dbg_raw_mode_open,
+ .release = scmi_dbg_raw_mode_release,
+ .write = scmi_dbg_raw_mode_reset_write,
+ .owner = THIS_MODULE,
+};
+
+static const struct file_operations scmi_dbg_raw_mode_message_fops = {
+ .open = scmi_dbg_raw_mode_open,
+ .release = scmi_dbg_raw_mode_release,
+ .read = scmi_dbg_raw_mode_message_read,
+ .write = scmi_dbg_raw_mode_message_write,
+ .poll = scmi_dbg_raw_mode_message_poll,
+ .owner = THIS_MODULE,
+};
+
+static ssize_t scmi_dbg_raw_mode_message_async_write(struct file *filp,
+ const char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ return scmi_dbg_raw_mode_common_write(filp, buf, count, ppos, true);
+}
+
+static const struct file_operations scmi_dbg_raw_mode_message_async_fops = {
+ .open = scmi_dbg_raw_mode_open,
+ .release = scmi_dbg_raw_mode_release,
+ .read = scmi_dbg_raw_mode_message_read,
+ .write = scmi_dbg_raw_mode_message_async_write,
+ .poll = scmi_dbg_raw_mode_message_poll,
+ .owner = THIS_MODULE,
+};
+
+static ssize_t scmi_test_dbg_raw_mode_notif_read(struct file *filp,
+ char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ return scmi_dbg_raw_mode_common_read(filp, buf, count, ppos,
+ SCMI_RAW_NOTIF_QUEUE);
+}
+
+static __poll_t scmi_test_dbg_raw_mode_notif_poll(struct file *filp,
+ struct poll_table_struct *wait)
+{
+ return scmi_test_dbg_raw_common_poll(filp, wait, SCMI_RAW_NOTIF_QUEUE);
+}
+
+static const struct file_operations scmi_dbg_raw_mode_notification_fops = {
+ .open = scmi_dbg_raw_mode_open,
+ .release = scmi_dbg_raw_mode_release,
+ .read = scmi_test_dbg_raw_mode_notif_read,
+ .poll = scmi_test_dbg_raw_mode_notif_poll,
+ .owner = THIS_MODULE,
+};
+
+static ssize_t scmi_test_dbg_raw_mode_errors_read(struct file *filp,
+ char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ return scmi_dbg_raw_mode_common_read(filp, buf, count, ppos,
+ SCMI_RAW_ERRS_QUEUE);
+}
+
+static __poll_t scmi_test_dbg_raw_mode_errors_poll(struct file *filp,
+ struct poll_table_struct *wait)
+{
+ return scmi_test_dbg_raw_common_poll(filp, wait, SCMI_RAW_ERRS_QUEUE);
+}
+
+static const struct file_operations scmi_dbg_raw_mode_errors_fops = {
+ .open = scmi_dbg_raw_mode_open,
+ .release = scmi_dbg_raw_mode_release,
+ .read = scmi_test_dbg_raw_mode_errors_read,
+ .poll = scmi_test_dbg_raw_mode_errors_poll,
+ .owner = THIS_MODULE,
+};
+
+static int scmi_xfer_raw_free_bufs_init(struct scmi_raw_mode_info *raw, int idx)
+{
+ int i;
+ struct scmi_raw_buffer *rb;
+ struct device *dev = raw->handle->dev;
+
+ rb = devm_kcalloc(dev, raw->tx_max_msg, sizeof(*rb), GFP_KERNEL);
+ if (!rb)
+ return -ENOMEM;
+
+ spin_lock_init(&raw->free_bufs_lock[idx]);
+ INIT_LIST_HEAD(&raw->free_raw_bufs[idx]);
+ for (i = 0; i < raw->tx_max_msg; i++, rb++) {
+ rb->max_len = raw->desc->max_msg_size + sizeof(u32);
+ rb->msg.buf = devm_kzalloc(dev, rb->max_len, GFP_KERNEL);
+ if (!rb->msg.buf)
+ return -ENOMEM;
+ scmi_raw_buffer_put(raw, rb, idx);
+ }
+
+ spin_lock_init(&raw->msg_q_lock[idx]);
+ INIT_LIST_HEAD(&raw->msg_q[idx]);
+ init_waitqueue_head(&raw->wqs[idx]);
+
+ return 0;
+}
+
+static int scmi_xfer_raw_worker_init(struct scmi_raw_mode_info *raw)
+{
+ int i;
+ struct scmi_xfer_raw_waiter *rw;
+ struct device *dev = raw->handle->dev;
+
+ rw = devm_kcalloc(dev, raw->tx_max_msg, sizeof(*rw), GFP_KERNEL);
+ if (!rw)
+ return -ENOMEM;
+
+ raw->wait_wq = alloc_workqueue("scmi-raw-wait-wq-%d",
+ WQ_UNBOUND | WQ_FREEZABLE |
+ WQ_HIGHPRI, WQ_SYSFS, 0);
+ if (!raw->wait_wq)
+ return -ENOMEM;
+
+ mutex_init(&raw->free_mtx);
+ INIT_LIST_HEAD(&raw->free_waiters);
+ mutex_init(&raw->active_mtx);
+ INIT_LIST_HEAD(&raw->active_waiters);
+
+ for (i = 0; i < raw->tx_max_msg; i++, rw++) {
+ init_completion(&rw->async_response);
+ scmi_xfer_raw_waiter_put(raw, rw);
+ }
+ INIT_WORK(&raw->waiters_work, scmi_xfer_raw_worker);
+
+ return 0;
+}
+
+static int scmi_raw_mode_setup(struct scmi_raw_mode_info *raw)
+{
+ int ret, idx;
+ void *gid;
+ struct device *dev = raw->handle->dev;
+
+ gid = devres_open_group(dev, NULL, GFP_KERNEL);
+ if (!gid)
+ return -ENOMEM;
+
+ for (idx = 0; idx < SCMI_RAW_MAX_QUEUE; idx++) {
+ ret = scmi_xfer_raw_free_bufs_init(raw, idx);
+ if (ret)
+ goto err;
+ }
+
+ ret = scmi_xfer_raw_worker_init(raw);
+ if (ret)
+ goto err;
+
+ devres_close_group(dev, gid);
+ raw->gid = gid;
+
+ return 0;
+
+err:
+ devres_release_group(dev, gid);
+ return ret;
+}
+
+/**
+ * scmi_raw_mode_init - Function to initialize the SCMI Raw stack
+ *
+ * @handle: Pointer to SCMI entity handle
+ * @desc: Reference to the transport operations
+ * @tx_max_msg: Max number of in-flight messages allowed by the transport
+ *
+ * This function prepare the SCMI Raw stack and creates the debugfs API.
+ *
+ * Return: An opaque handle to the Raw instance on Success, an ERR_PTR otherwise
+ */
+void *scmi_raw_mode_init(const struct scmi_handle *handle,
+ const struct scmi_desc *desc, int tx_max_msg)
+{
+ int ret;
+ struct scmi_raw_mode_info *raw;
+ struct device *dev;
+
+ if (!handle || !desc)
+ return ERR_PTR(-EINVAL);
+
+ dev = handle->dev;
+ raw = devm_kzalloc(dev, sizeof(*raw), GFP_KERNEL);
+ if (!raw)
+ return ERR_PTR(-ENOMEM);
+
+ raw->handle = handle;
+ raw->desc = desc;
+ raw->tx_max_msg = tx_max_msg;
+
+ ret = scmi_raw_mode_setup(raw);
+ if (ret) {
+ devm_kfree(dev, raw);
+ return ERR_PTR(ret);
+ }
+
+ raw->dentry = debugfs_create_dir("scmi_raw", NULL);
+ if (IS_ERR(raw->dentry)) {
+ ret = PTR_ERR(raw->dentry);
+ devres_release_group(dev, raw->gid);
+ devm_kfree(dev, raw);
+ return ERR_PTR(ret);
+ }
+
+ debugfs_create_file("reset", 0200, raw->dentry, raw,
+ &scmi_dbg_raw_mode_reset_fops);
+
+ debugfs_create_u32("transport_rx_timeout_ms", 0400, raw->dentry,
+ (u32 *)&raw->desc->max_rx_timeout_ms);
+
+ debugfs_create_u32("transport_max_msg_size", 0400, raw->dentry,
+ (u32 *)&raw->desc->max_msg_size);
+
+ debugfs_create_u32("transport_tx_max_msg", 0400, raw->dentry,
+ (u32 *)&raw->tx_max_msg);
+
+ debugfs_create_file("message", 0600, raw->dentry, raw,
+ &scmi_dbg_raw_mode_message_fops);
+
+ debugfs_create_file("message_async", 0600, raw->dentry, raw,
+ &scmi_dbg_raw_mode_message_async_fops);
+
+ debugfs_create_file("notification", 0400, raw->dentry, raw,
+ &scmi_dbg_raw_mode_notification_fops);
+
+ debugfs_create_file("errors", 0400, raw->dentry, raw,
+ &scmi_dbg_raw_mode_errors_fops);
+
+ return raw;
+}
+
+/**
+ * scmi_raw_mode_cleanup - Function to cleanup the SCMI Raw stack
+ *
+ * @r: An opaque handle to an initialized SCMI Raw instance
+ */
+void scmi_raw_mode_cleanup(void *r)
+{
+ struct scmi_raw_mode_info *raw = r;
+
+ if (!raw)
+ return;
+
+ debugfs_remove_recursive(raw->dentry);
+
+ cancel_work_sync(&raw->waiters_work);
+ destroy_workqueue(raw->wait_wq);
+}
+
+static int scmi_xfer_raw_collect(struct scmi_xfer *xfer,
+ void *msg, size_t *msg_len)
+{
+ __le32 *m;
+ size_t msg_size;
+
+ if (!xfer || !msg || !msg_len)
+ return -EINVAL;
+
+ /* Account for hdr ...*/
+ msg_size = xfer->rx.len + sizeof(u32);
+ /* ... and status if needed */
+ if (xfer->hdr.type != MSG_TYPE_NOTIFICATION)
+ msg_size += sizeof(u32);
+
+ if (msg_size > *msg_len)
+ return -ENOSPC;
+
+ m = msg;
+ *m = cpu_to_le32(pack_scmi_header(&xfer->hdr));
+ if (xfer->hdr.type != MSG_TYPE_NOTIFICATION)
+ *++m = cpu_to_le32(xfer->hdr.status);
+
+ memcpy(++m, xfer->rx.buf, xfer->rx.len);
+
+ *msg_len = msg_size;
+
+ return 0;
+}
+
+/**
+ * scmi_raw_message_report - Helper to report back valid reponses/notifications
+ * to raw message requests.
+ *
+ * @r: An opaque reference to the raw instance configuration
+ * @xfer: The xfer containing the message to be reported
+ * @idx: The index of the queue.
+ *
+ * If Raw mode is enabled, this is called from the SCMI core on the regular RX
+ * path to save and enqueue the response/notification payload carried by this
+ * xfer into a dedicated scmi_raw_buffer for later consumption by the user.
+ *
+ * This way the caller can free the related xfer immediately afterwards and the
+ * user can read back the raw message payload at its own pace (if ever) without
+ * holding an xfer for too long.
+ */
+void scmi_raw_message_report(void *r, struct scmi_xfer *xfer, unsigned int idx)
+{
+ int ret;
+ struct scmi_raw_buffer *rb;
+ struct device *dev;
+ struct scmi_raw_mode_info *raw = r;
+
+ if (!raw)
+ return;
+
+ dev = raw->handle->dev;
+ rb = scmi_raw_buffer_get(raw, idx);
+ if (!rb) {
+ dev_warn(dev, "RAW[%d] - Cannot get a free RAW buffer\n", idx);
+ return;
+ }
+
+ ret = scmi_xfer_raw_collect(xfer, rb->msg.buf, &rb->msg.len);
+ if (ret) {
+ dev_warn(dev, "RAW - Cannot collect xfer into buffer !\n");
+ scmi_raw_buffer_put(raw, rb, idx);
+ return;
+ }
+
+ scmi_raw_buffer_enqueue(raw, rb, idx);
+}
+
+static void scmi_xfer_raw_fill(struct scmi_raw_mode_info *raw,
+ struct scmi_chan_info *cinfo,
+ struct scmi_xfer *xfer, u32 msg_hdr)
+{
+ /* Unpack received HDR as it is */
+ unpack_scmi_header(msg_hdr, &xfer->hdr);
+ xfer->hdr.seq = MSG_XTRACT_TOKEN(msg_hdr);
+
+ memset(xfer->rx.buf, 0x00, xfer->rx.len);
+
+ raw->desc->ops->fetch_response(cinfo, xfer);
+}
+
+/**
+ * scmi_raw_error_report - Helper to report back timed-out or generally
+ * unexpected replies.
+ *
+ * @r: An opaque reference to the raw instance configuration
+ * @cinfo: A reference to the channel to use to retrieve the broken xfer
+ * @msg_hdr: The SCMI message header of the message to fetch and report
+ * @priv: Any private data related to the xfer.
+ *
+ * If Raw mode is enabled, this is called from the SCMI core on the RX path in
+ * case of errors to save and enqueue the bad message payload carried by the
+ * message that has just been received.
+ *
+ * Note that we have to manually fetch any available payload into a temporary
+ * xfer to be able to save and enqueue the message, since the regular RX error
+ * path which had called this would have not fetched the message payload having
+ * classified it as an error.
+ */
+void scmi_raw_error_report(void *r, struct scmi_chan_info *cinfo,
+ u32 msg_hdr, void *priv)
+{
+ struct scmi_xfer xfer;
+ struct scmi_raw_buffer *rb;
+ struct scmi_raw_mode_info *raw = r;
+
+ if (!raw)
+ return;
+
+ rb = scmi_raw_buffer_get(raw, SCMI_RAW_ERRS_QUEUE);
+ if (!rb) {
+ dev_warn(raw->handle->dev,
+ "RAW[%d] - Cannot get a free RAW buffer\n",
+ SCMI_RAW_ERRS_QUEUE);
+ return;
+ }
+
+ /* Use a raw buffer to provide rx space to the temp xfer */
+ xfer.rx.buf = rb->msg.buf;
+ /*
+ * Allow max_msg_size...note that allocated rx.buf length is
+ * max_msg_size + sizeof(u32).
+ */
+ xfer.rx.len = raw->desc->max_msg_size;
+ if (priv)
+ /*
+ * Any transport-provided priv must be passed back down
+ * to transport
+ */
+ smp_store_mb(xfer.priv, priv);
+
+ scmi_xfer_raw_fill(raw, cinfo, &xfer, msg_hdr);
+ scmi_raw_message_report(raw, &xfer, SCMI_RAW_ERRS_QUEUE);
+
+ scmi_raw_buffer_put(raw, rb, SCMI_RAW_ERRS_QUEUE);
+}
diff --git a/drivers/firmware/arm_scmi/raw_mode.h b/drivers/firmware/arm_scmi/raw_mode.h
new file mode 100644
index 000000000000..e2d8672e1f8b
--- /dev/null
+++ b/drivers/firmware/arm_scmi/raw_mode.h
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * System Control and Management Interface (SCMI) Message Protocol
+ * Raw mode support header.
+ *
+ * Copyright (C) 2022 ARM Ltd.
+ */
+#ifndef _SCMI_RAW_MODE_H
+#define _SCMI_RAW_MODE_H
+
+#include "common.h"
+
+enum {
+ SCMI_RAW_REPLY_QUEUE,
+ SCMI_RAW_NOTIF_QUEUE,
+ SCMI_RAW_ERRS_QUEUE,
+ SCMI_RAW_MAX_QUEUE
+};
+
+void *scmi_raw_mode_init(const struct scmi_handle *handle,
+ const struct scmi_desc *desc, int tx_max_msg);
+void scmi_raw_mode_cleanup(void *raw);
+
+void scmi_raw_message_report(void *raw, struct scmi_xfer *xfer,
+ unsigned int idx);
+void scmi_raw_error_report(void *raw, struct scmi_chan_info *cinfo,
+ u32 msg_hdr, void *priv);
+
+#endif /* _SCMI_RAW_MODE_H */
--
2.34.1
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v4 08/11] firmware: arm_scmi: Add raw transmission support
@ 2022-10-19 20:46 ` Cristian Marussi
0 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
Add SCMI Raw mode support which exposes a userspace interface to allow for
bare SCMI command injection and snooping from userspace.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
v3 --> v4
- fix handling of O_NONBLOCK raw_mode read requests
- add support for polled/nocomnpletion_irq transports
- removed inlines
v2 --> v3
- changed to dev_dbg when retrying inflight reg
- refactored and simplfiied waiters deferred worker
- fixed sparse errors about LE and __poll_t
v1 --> v2
- make use of proper channel depending on protocol at hand (using
scmi_xfer_raw_channel_get to lookup related DT config)
- refactored scmi_inflight_register call
- added debugfs docs and comments
---
drivers/firmware/arm_scmi/Kconfig | 13 +
drivers/firmware/arm_scmi/Makefile | 1 +
drivers/firmware/arm_scmi/raw_mode.c | 1244 ++++++++++++++++++++++++++
drivers/firmware/arm_scmi/raw_mode.h | 29 +
4 files changed, 1287 insertions(+)
create mode 100644 drivers/firmware/arm_scmi/raw_mode.c
create mode 100644 drivers/firmware/arm_scmi/raw_mode.h
diff --git a/drivers/firmware/arm_scmi/Kconfig b/drivers/firmware/arm_scmi/Kconfig
index a14f65444b35..ab726a92ac2f 100644
--- a/drivers/firmware/arm_scmi/Kconfig
+++ b/drivers/firmware/arm_scmi/Kconfig
@@ -23,6 +23,19 @@ config ARM_SCMI_PROTOCOL
if ARM_SCMI_PROTOCOL
+config ARM_SCMI_RAW_MODE_SUPPORT
+ bool "Enable support for SCMI Raw transmission mode"
+ help
+ Enable support for SCMI Raw transmission mode.
+
+ If enabled allows the direct injection and snooping of SCMI bare
+ messages through a dedicated debugfs interface.
+ It is meant to be used by SCMI compliance/testing suites.
+
+ When enabled regular SCMI drivers interactions are inhibited in
+ order to avoid unexpected interactions with the SCMI Raw message
+ flow. If unsure say N.
+
config ARM_SCMI_HAVE_TRANSPORT
bool
help
diff --git a/drivers/firmware/arm_scmi/Makefile b/drivers/firmware/arm_scmi/Makefile
index 9ea86f8cc8f7..7c1aca60c8ce 100644
--- a/drivers/firmware/arm_scmi/Makefile
+++ b/drivers/firmware/arm_scmi/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
scmi-bus-y = bus.o
scmi-driver-y = driver.o notify.o
+scmi-driver-$(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT) += raw_mode.o
scmi-transport-$(CONFIG_ARM_SCMI_HAVE_SHMEM) = shmem.o
scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_MAILBOX) += mailbox.o
scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_SMC) += smc.o
diff --git a/drivers/firmware/arm_scmi/raw_mode.c b/drivers/firmware/arm_scmi/raw_mode.c
new file mode 100644
index 000000000000..3fdfc0564286
--- /dev/null
+++ b/drivers/firmware/arm_scmi/raw_mode.c
@@ -0,0 +1,1244 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * System Control and Management Interface (SCMI) Raw mode support
+ *
+ * Copyright (C) 2022 ARM Ltd.
+ */
+/**
+ * DOC: Theory of operation
+ *
+ * When enabled the SCMI Raw mode support exposes a userspace API which allows
+ * to send and receive SCMI commands, replies and notifications from a user
+ * application through injection and snooping of bare SCMI messages in binary
+ * little-endian format.
+ *
+ * Such injected SCMI transactions will then be routed through the SCMI core
+ * stack towards the SCMI backend server using whatever SCMI transport is
+ * currently configured on the system under test.
+ *
+ * It is meant to help in running any sort of SCMI backend server testing, no
+ * matter where the server is placed, as long as it is normally reachable via
+ * the transport configured on the system.
+ *
+ * It is activated by a Kernel configuration option since it is NOT meant to
+ * be used in production but only during development and in CI deployments.
+ *
+ * In order to avoid possible interferences between the SCMI Raw transactions
+ * originated from a test-suite and the normal operations of the SCMI drivers,
+ * when Raw mode is enabled, by default, all the regular SCMI drivers are
+ * inhibited.
+ *
+ * The exposed API is as follows:
+ *
+ * /sys/kernel/debug/scmi_raw/
+ * |-- errors
+ * |-- message
+ * |-- message_async
+ * |-- notification
+ * |-- reset
+ * |-- transport_max_msg_size
+ * |-- transport_rx_timeout_ms
+ * |-- transport_tx_max_msg
+ *
+ * where:
+ *
+ * - errors: used to read back timed-out and unexpected replies
+ * - message*: used to send sync/async commands and read back immediate and
+ * delayed reponses (if any)
+ * - notification: used to read any notification being emitted by the system
+ * (if previously enabled by the user app)
+ * - reset: used to flush the queues of messages (of any kind) still pending
+ * to be read; this is useful at test-suite start/stop to get
+ * rid of any unread messages from the previous run.
+ * - transport*: a bunch of configurations useful to setup the user
+ * application expectations in terms of timeouts and message
+ * characteristics.
+ *
+ * Each write to the message* entries causes one command request to be built
+ * and sent while the replies or delayed response are read back from those same
+ * entries one message at time (receiving an EOF at each message boundary).
+ *
+ * The user application running the test is in charge of handling timeouts
+ * on replies and properly choosing SCMI sequence numbers for the outgoing
+ * requests (using the same sequence number is supported but discouraged).
+ *
+ * Injection of multiple in-flight requests is supported as long as the user
+ * application uses properly distinct sequence numbers for concurrent requests
+ * and takes care to properly manage all the related issues about concurrency
+ * and command/reply pairing. Keep in mind that, anyway, the real level of
+ * parallelism attainable in such scenario is dependent on the characteristics
+ * of the underlying transport being used.
+ *
+ * Since the SCMI core regular stack is partially used to deliver and collect
+ * the messages, late replies arrived after timeouts and any other sort of
+ * unexpected message can be identified by the SCMI core as usual and they will
+ * be reported as messages under "errors" for later analysis.
+ */
+
+#include <linux/bitmap.h>
+#include <linux/debugfs.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/export.h>
+#include <linux/idr.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/fs.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/poll.h>
+#include <linux/slab.h>
+
+#include "common.h"
+
+#include "raw_mode.h"
+
+#include <trace/events/scmi.h>
+
+#define SCMI_XFER_RAW_MAX_RETRIES 10
+
+/**
+ * struct scmi_raw_mode_info - Structure holding SCMI Raw instance data
+ *
+ * @handle: Pointer to SCMI entity handle to use
+ * @desc: Pointer to the transport descriptor to use
+ * @tx_max_msg: Maximum number of concurrent TX in-flight messages
+ * @free_raw_bufs: An array of freelists heads used to keep unused raw buffers
+ * @free_bufs_lock: Spinlocks used to protect access to each @free_raw_bufs
+ * @msg_q: An array of lists to queue snooped messages waiting to be read out
+ * @msg_q_lock: Spinlocks used to protect access to each @msg_q
+ * @wqs: An array of waitqueues used to wait and poll on related @msg_q
+ * @free_waiters: Head of freelist for unused waiters
+ * @free_mtx: A mutex to protect the waiters freelist
+ * @active_waiters: Head of list for currently active and used waiters
+ * @active_mtx: A mutex to protect the active waiters list
+ * @waiters_work: A work descriptor to be used with the workqueue machinery
+ * @wait_wq: A workqueue reference to the created workqueue
+ * @dentry: Top debugfs root dentry for SCMI Raw
+ * @gid: A group ID used for devres accounting
+ *
+ * Note that this descriptor is passed back to the core after SCMI Raw is
+ * initialized as an opaque handle to use by subsequent SCMI Raw call hooks.
+ *
+ */
+struct scmi_raw_mode_info {
+ const struct scmi_handle *handle;
+ const struct scmi_desc *desc;
+ int tx_max_msg;
+ struct list_head free_raw_bufs[SCMI_RAW_MAX_QUEUE];
+ /* Protect free_raw_bufs[] lists */
+ spinlock_t free_bufs_lock[SCMI_RAW_MAX_QUEUE];
+ struct list_head msg_q[SCMI_RAW_MAX_QUEUE];
+ /* Protect msg_q[] lists */
+ spinlock_t msg_q_lock[SCMI_RAW_MAX_QUEUE];
+ wait_queue_head_t wqs[SCMI_RAW_MAX_QUEUE];
+ struct list_head free_waiters;
+ /* Protect free_waiters list */
+ struct mutex free_mtx;
+ struct list_head active_waiters;
+ /* Protect active_waiters list */
+ struct mutex active_mtx;
+ struct work_struct waiters_work;
+ struct workqueue_struct *wait_wq;
+ struct dentry *dentry;
+ void *gid;
+};
+
+/**
+ * struct scmi_xfer_raw_waiter - Structure to describe an xfer to be waited for
+ *
+ * @start_jiffies: The timestamp in jiffies of when this structure was queued.
+ * @cinfo: A reference to the channel to use for this transaction
+ * @xfer: A reference to the xfer to be waited for
+ * @async_response: A completion to be, optionally, used for async waits: it
+ * will be setup by @scmi_do_xfer_raw_start, if needed, to be
+ * pointed at by xfer->async_done.
+ * @node: A list node.
+ */
+struct scmi_xfer_raw_waiter {
+ unsigned long start_jiffies;
+ struct scmi_chan_info *cinfo;
+ struct scmi_xfer *xfer;
+ struct completion async_response;
+ struct list_head node;
+};
+
+/**
+ * struct scmi_raw_buffer - Structure to hold a full SCMI message
+ *
+ * @max_len: The maximum allowed message size (header included) that can be
+ * stored into @msg
+ * @msg: A message buffer used to collect a full message grabbed from an xfer.
+ * @node: A list node.
+ */
+struct scmi_raw_buffer {
+ size_t max_len;
+ struct scmi_msg msg;
+ struct list_head node;
+};
+
+/**
+ * struct scmi_dbg_raw_data - Structure holding data needed by the debugfs
+ * layer
+ *
+ * @raw: A reference to the Raw instance.
+ * @tx: A message buffer used to collect TX message on write.
+ * @tx_size: The effective size of the TX message.
+ * @tx_req_size: The final expected size of the complete TX message.
+ * @rx: A message buffer to collect RX message on read.
+ * @rx_size: The effective size of the RX message.
+ */
+struct scmi_dbg_raw_data {
+ struct scmi_raw_mode_info *raw;
+ struct scmi_msg tx;
+ size_t tx_size;
+ size_t tx_req_size;
+ struct scmi_msg rx;
+ size_t rx_size;
+};
+
+static struct scmi_raw_buffer *
+scmi_raw_buffer_get(struct scmi_raw_mode_info *raw, unsigned int idx)
+{
+ unsigned long flags;
+ struct scmi_raw_buffer *rb = NULL;
+ struct list_head *head = &raw->free_raw_bufs[idx];
+
+ spin_lock_irqsave(&raw->free_bufs_lock[idx], flags);
+ if (!list_empty(head)) {
+ rb = list_first_entry(head, struct scmi_raw_buffer, node);
+ list_del_init(&rb->node);
+ }
+ spin_unlock_irqrestore(&raw->free_bufs_lock[idx], flags);
+
+ return rb;
+}
+
+static void scmi_raw_buffer_put(struct scmi_raw_mode_info *raw,
+ struct scmi_raw_buffer *rb, unsigned int idx)
+{
+ unsigned long flags;
+
+ /* Reset to full buffer length */
+ rb->msg.len = rb->max_len;
+
+ spin_lock_irqsave(&raw->free_bufs_lock[idx], flags);
+ list_add_tail(&rb->node, &raw->free_raw_bufs[idx]);
+ spin_unlock_irqrestore(&raw->free_bufs_lock[idx], flags);
+}
+
+static void scmi_raw_buffer_enqueue(struct scmi_raw_mode_info *raw,
+ struct scmi_raw_buffer *rb,
+ unsigned int idx)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&raw->msg_q_lock[idx], flags);
+ list_add_tail(&rb->node, &raw->msg_q[idx]);
+ spin_unlock_irqrestore(&raw->msg_q_lock[idx], flags);
+
+ wake_up_interruptible(&raw->wqs[idx]);
+}
+
+static struct scmi_raw_buffer *
+scmi_raw_buffer_dequeue(struct scmi_raw_mode_info *raw, unsigned int idx)
+{
+ unsigned long flags;
+ struct scmi_raw_buffer *rb = NULL;
+
+ spin_lock_irqsave(&raw->msg_q_lock[idx], flags);
+ if (!list_empty(&raw->msg_q[idx])) {
+ rb = list_first_entry(&raw->msg_q[idx],
+ struct scmi_raw_buffer, node);
+ list_del_init(&rb->node);
+ }
+ spin_unlock_irqrestore(&raw->msg_q_lock[idx], flags);
+
+ return rb;
+}
+
+static void scmi_raw_buffer_queue_flush(struct scmi_raw_mode_info *raw,
+ unsigned int idx)
+{
+ struct scmi_raw_buffer *rb;
+
+ do {
+ rb = scmi_raw_buffer_dequeue(raw, idx);
+ if (rb)
+ scmi_raw_buffer_put(raw, rb, idx);
+ } while (rb);
+}
+
+static struct scmi_xfer_raw_waiter *
+scmi_xfer_raw_waiter_get(struct scmi_raw_mode_info *raw, struct scmi_xfer *xfer,
+ struct scmi_chan_info *cinfo, bool async)
+{
+ struct scmi_xfer_raw_waiter *rw = NULL;
+
+ mutex_lock(&raw->free_mtx);
+ if (!list_empty(&raw->free_waiters)) {
+ rw = list_first_entry(&raw->free_waiters,
+ struct scmi_xfer_raw_waiter, node);
+ list_del_init(&rw->node);
+
+ if (async) {
+ reinit_completion(&rw->async_response);
+ xfer->async_done = &rw->async_response;
+ }
+
+ rw->cinfo = cinfo;
+ rw->xfer = xfer;
+ }
+ mutex_unlock(&raw->free_mtx);
+
+ return rw;
+}
+
+static void scmi_xfer_raw_waiter_put(struct scmi_raw_mode_info *raw,
+ struct scmi_xfer_raw_waiter *rw)
+{
+ if (rw->xfer) {
+ rw->xfer->async_done = NULL;
+ rw->xfer = NULL;
+ }
+
+ mutex_lock(&raw->free_mtx);
+ list_add_tail(&rw->node, &raw->free_waiters);
+ mutex_unlock(&raw->free_mtx);
+}
+
+static void scmi_xfer_raw_waiter_enqueue(struct scmi_raw_mode_info *raw,
+ struct scmi_xfer_raw_waiter *rw)
+{
+ /* A timestamp for the deferred worker to know how much this has aged */
+ rw->start_jiffies = jiffies;
+
+ trace_scmi_xfer_response_wait(rw->xfer->transfer_id, rw->xfer->hdr.id,
+ rw->xfer->hdr.protocol_id,
+ rw->xfer->hdr.seq,
+ raw->desc->max_rx_timeout_ms,
+ rw->xfer->hdr.poll_completion);
+
+ mutex_lock(&raw->active_mtx);
+ list_add_tail(&rw->node, &raw->active_waiters);
+ mutex_unlock(&raw->active_mtx);
+
+ /* kick waiter work */
+ queue_work(raw->wait_wq, &raw->waiters_work);
+}
+
+static struct scmi_xfer_raw_waiter *
+scmi_xfer_raw_waiter_dequeue(struct scmi_raw_mode_info *raw)
+{
+ struct scmi_xfer_raw_waiter *rw = NULL;
+
+ mutex_lock(&raw->active_mtx);
+ if (!list_empty(&raw->active_waiters)) {
+ rw = list_first_entry(&raw->active_waiters,
+ struct scmi_xfer_raw_waiter, node);
+ list_del_init(&rw->node);
+ }
+ mutex_unlock(&raw->active_mtx);
+
+ return rw;
+}
+
+/**
+ * scmi_xfer_raw_worker - Work function to wait for Raw xfers completions
+ *
+ * @work: A reference to the work.
+ *
+ * In SCMI Raw mode, once a user-provided injected SCMI message is sent, we
+ * cannot wait to receive its response (if any) in the context of the injection
+ * routines so as not to leave the userspace write syscall, which delivered the
+ * SCMI message to send, pending till eventually a reply is received.
+ * Userspace should and will poll/wait instead on the read syscalls which will
+ * be in charge of reading a received reply (if any).
+ *
+ * Even though reply messages are collected and reported into the SCMI Raw layer
+ * on the RX path, nonetheless we have to properly wait for their completion as
+ * usual (and async_completion too if needed) in order to properly release the
+ * xfer structure at the end: to do this out of the context of the write/send
+ * these waiting jobs are delegated to this deferred worker.
+ *
+ * Any sent xfer, to be waited for, is timestamped and queued for later
+ * consumption by this worker: queue aging is accounted for while choosing a
+ * timeout for the completion, BUT we do not really care here if we end up
+ * accidentally waiting for a bit too long.
+ */
+static void scmi_xfer_raw_worker(struct work_struct *work)
+{
+ struct scmi_raw_mode_info *raw;
+ struct device *dev;
+ unsigned long max_tmo;
+
+ raw = container_of(work, struct scmi_raw_mode_info, waiters_work);
+ dev = raw->handle->dev;
+ max_tmo = msecs_to_jiffies(raw->desc->max_rx_timeout_ms);
+
+ do {
+ int ret = 0;
+ unsigned int timeout_ms;
+ unsigned long aging;
+ struct scmi_xfer *xfer;
+ struct scmi_xfer_raw_waiter *rw;
+ struct scmi_chan_info *cinfo;
+
+ rw = scmi_xfer_raw_waiter_dequeue(raw);
+ if (!rw)
+ return;
+
+ cinfo = rw->cinfo;
+ xfer = rw->xfer;
+ /*
+ * Waiters are queued by wait-deadline at the end, so some of
+ * them could have been already expired when processed, BUT we
+ * have to check the completion status anyway just in case a
+ * virtually expired (aged) transaction was indeed completed
+ * fine and we'll have to wait for the asynchronous part (if
+ * any): for this reason a 1 ms timeout is used for already
+ * expired/aged xfers.
+ */
+ aging = jiffies - rw->start_jiffies;
+ timeout_ms = max_tmo > aging ?
+ jiffies_to_msecs(max_tmo - aging) : 1;
+
+ ret = scmi_xfer_raw_wait_for_message_response(cinfo, xfer,
+ timeout_ms);
+ if (!ret && xfer->hdr.status)
+ ret = scmi_to_linux_errno(xfer->hdr.status);
+
+ if (raw->desc->ops->mark_txdone)
+ raw->desc->ops->mark_txdone(rw->cinfo, ret, xfer);
+
+ trace_scmi_xfer_end(xfer->transfer_id, xfer->hdr.id,
+ xfer->hdr.protocol_id, xfer->hdr.seq, ret);
+
+ /* Wait also for an async delayed response if needed */
+ if (!ret && xfer->async_done) {
+ unsigned long tmo = msecs_to_jiffies(SCMI_MAX_RESPONSE_TIMEOUT);
+
+ if (!wait_for_completion_timeout(xfer->async_done, tmo))
+ dev_err(dev,
+ "timed out in RAW delayed resp - HDR:%08X\n",
+ pack_scmi_header(&xfer->hdr));
+ }
+
+ /* Release waiter and xfer */
+ scmi_xfer_raw_put(raw->handle, xfer);
+ scmi_xfer_raw_waiter_put(raw, rw);
+ } while (1);
+}
+
+static void scmi_xfer_raw_reset(struct scmi_raw_mode_info *raw)
+{
+ int i;
+
+ dev_info(raw->handle->dev, "Resetting SCMI Raw stack.\n");
+
+ for (i = 0; i < SCMI_RAW_MAX_QUEUE; i++)
+ scmi_raw_buffer_queue_flush(raw, i);
+}
+
+/**
+ * scmi_xfer_raw_get_init - An helper to build a valid xfer from the provided
+ * bare SCMI message.
+ *
+ * @raw: A reference to the Raw instance.
+ * @buf: A buffer containing the whole SCMI message to send (including the
+ * header) in little-endian binary formmat.
+ * @len: Length of the message in @buf.
+ * @p: A pointer to return the initialized Raw xfer.
+ *
+ * After an xfer is picked from the TX pool and filled in with the message
+ * content, the xfer is registered as pending with the core in the usual way
+ * using the original sequence number provided by the user with the message.
+ *
+ * Note that, in case the testing user application is NOT using distinct
+ * sequence-numbers between successive SCMI messages such registration could
+ * fail temporarily if the previous message, using the same sequence number,
+ * had still not released; in such a case we just wait and retry.
+ *
+ * Return: 0 on Success
+ */
+static int scmi_xfer_raw_get_init(struct scmi_raw_mode_info *raw, void *buf,
+ size_t len, struct scmi_xfer **p)
+{
+ u32 msg_hdr;
+ size_t tx_size;
+ struct scmi_xfer *xfer;
+ int ret, retry = SCMI_XFER_RAW_MAX_RETRIES;
+ struct device *dev = raw->handle->dev;
+
+ if (!buf || len < sizeof(u32))
+ return -EINVAL;
+
+ tx_size = len - sizeof(u32);
+ /* Ensure we have sane transfer sizes */
+ if (tx_size > raw->desc->max_msg_size)
+ return -ERANGE;
+
+ xfer = scmi_xfer_raw_get(raw->handle);
+ if (IS_ERR(xfer)) {
+ dev_warn(dev, "RAW - Cannot get a free RAW xfer !\n");
+ return PTR_ERR(xfer);
+ }
+
+ /* Build xfer from the provided SCMI bare LE message */
+ msg_hdr = le32_to_cpu(*((__le32 *)buf));
+ unpack_scmi_header(msg_hdr, &xfer->hdr);
+ xfer->hdr.seq = (u16)MSG_XTRACT_TOKEN(msg_hdr);
+ /* Polling not supported */
+ xfer->hdr.poll_completion = false;
+ xfer->hdr.status = SCMI_SUCCESS;
+ xfer->tx.len = tx_size;
+ xfer->rx.len = raw->desc->max_msg_size;
+ /* Clear the whole TX buffer */
+ memset(xfer->tx.buf, 0x00, raw->desc->max_msg_size);
+ if (xfer->tx.len)
+ memcpy(xfer->tx.buf, (u8 *)buf + sizeof(msg_hdr), xfer->tx.len);
+ *p = xfer;
+
+ /*
+ * In flight registration can temporarily fail in case of Raw messages
+ * if the user injects messages without using monotonically increasing
+ * sequence numbers since, in Raw mode, the xfer (and the token) is
+ * finally released later by a deferred worker. Just retry for a while.
+ */
+ do {
+ ret = scmi_xfer_raw_inflight_register(raw->handle, xfer);
+ if (ret) {
+ dev_dbg(dev,
+ "...retrying[%d] inflight registration\n",
+ retry);
+ msleep(raw->desc->max_rx_timeout_ms /
+ SCMI_XFER_RAW_MAX_RETRIES);
+ }
+ } while (ret && --retry);
+
+ if (ret) {
+ dev_warn(dev,
+ "RAW - Could NOT register xfer %d in-flight HDR:0x%08X\n",
+ xfer->hdr.seq, msg_hdr);
+ scmi_xfer_raw_put(raw->handle, xfer);
+ }
+
+ return ret;
+}
+
+/**
+ * scmi_do_xfer_raw_start - An helper to send a valid raw xfer
+ *
+ * @raw: A reference to the Raw instance.
+ * @xfer: The xfer to send
+ * @async: A flag stating if an asynchronous command is required.
+ *
+ * This function send a previously built raw xfer using an appropriate channel
+ * and queues the related waiting work.
+ *
+ * Note that we need to know explicitly if the required command is meant to be
+ * asynchronous in kind since we have to properly setup the waiter.
+ * (and deducing this from the payload is weak and do not scale given there is
+ * NOT a common header-flag stating if the command is asynchronous or not)
+ *
+ * Return: 0 on Success
+ */
+static int scmi_do_xfer_raw_start(struct scmi_raw_mode_info *raw,
+ struct scmi_xfer *xfer, bool async)
+{
+ int ret;
+ struct scmi_chan_info *cinfo;
+ struct scmi_xfer_raw_waiter *rw;
+ struct device *dev = raw->handle->dev;
+
+ cinfo = scmi_xfer_raw_channel_get(raw->handle, xfer->hdr.protocol_id);
+ if (IS_ERR(cinfo))
+ return PTR_ERR(cinfo);
+
+ rw = scmi_xfer_raw_waiter_get(raw, xfer, cinfo, async);
+ if (!rw) {
+ dev_warn(dev, "RAW - Cannot get a free waiter !\n");
+ return -ENOMEM;
+ }
+
+ /* True ONLY if also supported by transport. */
+ if (is_polling_enabled(cinfo, raw->desc))
+ xfer->hdr.poll_completion = true;
+
+ reinit_completion(&xfer->done);
+ /* Make sure xfer state update is visible before sending */
+ smp_store_mb(xfer->state, SCMI_XFER_SENT_OK);
+
+ trace_scmi_xfer_begin(xfer->transfer_id, xfer->hdr.id,
+ xfer->hdr.protocol_id, xfer->hdr.seq,
+ xfer->hdr.poll_completion);
+
+ ret = raw->desc->ops->send_message(rw->cinfo, xfer);
+ if (ret) {
+ dev_err(dev, "Failed to send RAW message %d\n", ret);
+ scmi_xfer_raw_waiter_put(raw, rw);
+ return ret;
+ }
+
+ trace_scmi_msg_dump(xfer->hdr.protocol_id, xfer->hdr.id, "CMND",
+ xfer->hdr.seq, xfer->hdr.status,
+ xfer->tx.buf, xfer->tx.len);
+
+ scmi_xfer_raw_waiter_enqueue(raw, rw);
+
+ return ret;
+}
+
+/**
+ * scmi_raw_message_send - An helper to build and send an SCMI command using
+ * the provided SCMI bare message buffer
+ *
+ * @raw: A reference to the Raw instance.
+ * @buf: A buffer containing the whole SCMI message to send (including the
+ * header) in little-endian binary format.
+ * @len: Length of the message in @buf.
+ * @async: A flag stating if an asynchronous command is required.
+ *
+ * Return: 0 on Success
+ */
+static int scmi_raw_message_send(struct scmi_raw_mode_info *raw,
+ void *buf, size_t len, bool async)
+{
+ int ret;
+ struct scmi_xfer *xfer;
+
+ ret = scmi_xfer_raw_get_init(raw, buf, len, &xfer);
+ if (ret)
+ return ret;
+
+ ret = scmi_do_xfer_raw_start(raw, xfer, async);
+ if (ret)
+ scmi_xfer_raw_put(raw->handle, xfer);
+
+ return ret;
+}
+
+static struct scmi_raw_buffer *
+scmi_raw_message_dequeue(struct scmi_raw_mode_info *raw, unsigned int idx,
+ bool o_nonblock)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&raw->msg_q_lock[idx], flags);
+ while (list_empty(&raw->msg_q[idx])) {
+ spin_unlock_irqrestore(&raw->msg_q_lock[idx], flags);
+
+ if (o_nonblock)
+ return ERR_PTR(-EAGAIN);
+
+ if (wait_event_interruptible(raw->wqs[idx],
+ !list_empty(&raw->msg_q[idx])))
+ return ERR_PTR(-ERESTARTSYS);
+
+ spin_lock_irqsave(&raw->msg_q_lock[idx], flags);
+ }
+ spin_unlock_irqrestore(&raw->msg_q_lock[idx], flags);
+
+ return scmi_raw_buffer_dequeue(raw, idx);
+}
+
+/**
+ * scmi_raw_message_receive - An helper to dequeue and report the next
+ * available enqueued raw message payload that has been collected.
+ *
+ * @raw: A reference to the Raw instance.
+ * @buf: A buffer to get hold of the whole SCMI message received and represented
+ * in little-endian binary format.
+ * @len: Length of @buf.
+ * @size: The effective size of the message copied into @buf
+ * @idx: The index of the queue to pick the next queued message from.
+ * @o_nonblock: A flag to request a non-blocking message dequeue.
+ *
+ * Return: 0 on Success
+ */
+static int scmi_raw_message_receive(struct scmi_raw_mode_info *raw,
+ void *buf, size_t len, size_t *size,
+ unsigned int idx,
+ bool o_nonblock)
+{
+ int ret = 0;
+ struct scmi_raw_buffer *rb;
+
+ rb = scmi_raw_message_dequeue(raw, idx, o_nonblock);
+ if (IS_ERR(rb)) {
+ dev_dbg(raw->handle->dev, "RAW - No message available!\n");
+ return PTR_ERR(rb);
+ }
+
+ if (rb->msg.len <= len) {
+ memcpy(buf, rb->msg.buf, rb->msg.len);
+ *size = rb->msg.len;
+ } else {
+ ret = -ENOSPC;
+ }
+
+ scmi_raw_buffer_put(raw, rb, idx);
+
+ return ret;
+}
+
+/* SCMI Raw debugfs helpers */
+
+static ssize_t scmi_dbg_raw_mode_common_read(struct file *filp,
+ char __user *buf,
+ size_t count, loff_t *ppos,
+ unsigned int idx)
+{
+ ssize_t cnt;
+ struct scmi_dbg_raw_data *rd = filp->private_data;
+
+ if (!rd->rx_size) {
+ int ret;
+
+ ret = scmi_raw_message_receive(rd->raw, rd->rx.buf, rd->rx.len,
+ &rd->rx_size, idx,
+ filp->f_flags & O_NONBLOCK);
+ if (ret) {
+ rd->rx_size = 0;
+ return ret;
+ }
+
+ /* Reset any previous filepos change, including writes */
+ *ppos = 0;
+ } else if (*ppos == rd->rx_size) {
+ /* Return EOF once all the message has been read-out */
+ rd->rx_size = 0;
+ return 0;
+ }
+
+ cnt = simple_read_from_buffer(buf, count, ppos,
+ rd->rx.buf, rd->rx_size);
+
+ return cnt;
+}
+
+static ssize_t scmi_dbg_raw_mode_common_write(struct file *filp,
+ const char __user *buf,
+ size_t count, loff_t *ppos,
+ bool async)
+{
+ int ret;
+ struct scmi_dbg_raw_data *rd = filp->private_data;
+
+ if (count > rd->tx.len - rd->tx_size)
+ return -ENOSPC;
+
+ /* On first write attempt @count carries the total full message size. */
+ if (!rd->tx_size)
+ rd->tx_req_size = count;
+
+ /*
+ * Gather a full message, possibly across multiple interrupted wrrtes,
+ * before sending it with a single RAW xfer.
+ */
+ if (rd->tx_size < rd->tx_req_size) {
+ size_t cnt;
+
+ cnt = simple_write_to_buffer(rd->tx.buf, rd->tx.len, ppos,
+ buf, count);
+ rd->tx_size += cnt;
+ if (cnt < count)
+ return cnt;
+ }
+
+ ret = scmi_raw_message_send(rd->raw, rd->tx.buf, rd->tx_size, async);
+
+ /* Reset ppos for next message ... */
+ rd->tx_size = 0;
+
+ return ret ?: count;
+}
+
+static __poll_t scmi_test_dbg_raw_common_poll(struct file *filp,
+ struct poll_table_struct *wait,
+ unsigned int idx)
+{
+ unsigned long flags;
+ struct scmi_dbg_raw_data *rd = filp->private_data;
+ __poll_t mask = 0;
+
+ poll_wait(filp, &rd->raw->wqs[idx], wait);
+
+ spin_lock_irqsave(&rd->raw->msg_q_lock[idx], flags);
+ if (!list_empty(&rd->raw->msg_q[idx]))
+ mask = EPOLLIN | EPOLLRDNORM;
+ spin_unlock_irqrestore(&rd->raw->msg_q_lock[idx], flags);
+
+ return mask;
+}
+
+static ssize_t scmi_dbg_raw_mode_message_read(struct file *filp,
+ char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ return scmi_dbg_raw_mode_common_read(filp, buf, count, ppos,
+ SCMI_RAW_REPLY_QUEUE);
+}
+
+static ssize_t scmi_dbg_raw_mode_message_write(struct file *filp,
+ const char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ return scmi_dbg_raw_mode_common_write(filp, buf, count, ppos, false);
+}
+
+static __poll_t scmi_dbg_raw_mode_message_poll(struct file *filp,
+ struct poll_table_struct *wait)
+{
+ return scmi_test_dbg_raw_common_poll(filp, wait, SCMI_RAW_REPLY_QUEUE);
+}
+
+static int scmi_dbg_raw_mode_open(struct inode *inode, struct file *filp)
+{
+ struct scmi_raw_mode_info *raw;
+ struct scmi_dbg_raw_data *rd;
+
+ if (!inode->i_private)
+ return -ENODEV;
+
+ raw = inode->i_private;
+ rd = kzalloc(sizeof(*rd), GFP_KERNEL);
+ if (!rd)
+ return -ENOMEM;
+
+ rd->rx.len = raw->desc->max_msg_size + sizeof(u32);
+ rd->rx.buf = kzalloc(rd->rx.len, GFP_KERNEL);
+ if (!rd->rx.buf) {
+ kfree(rd);
+ return -ENOMEM;
+ }
+
+ rd->tx.len = raw->desc->max_msg_size + sizeof(u32);
+ rd->tx.buf = kzalloc(rd->tx.len, GFP_KERNEL);
+ if (!rd->tx.buf) {
+ kfree(rd->rx.buf);
+ kfree(rd);
+ return -ENOMEM;
+ }
+
+ rd->raw = raw;
+ filp->private_data = rd;
+
+ return 0;
+}
+
+static int scmi_dbg_raw_mode_release(struct inode *inode, struct file *filp)
+{
+ struct scmi_dbg_raw_data *rd = filp->private_data;
+
+ kfree(rd->rx.buf);
+ kfree(rd->tx.buf);
+ kfree(rd);
+
+ return 0;
+}
+
+static ssize_t scmi_dbg_raw_mode_reset_write(struct file *filp,
+ const char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ struct scmi_dbg_raw_data *rd = filp->private_data;
+
+ scmi_xfer_raw_reset(rd->raw);
+
+ return count;
+}
+
+static const struct file_operations scmi_dbg_raw_mode_reset_fops = {
+ .open = scmi_dbg_raw_mode_open,
+ .release = scmi_dbg_raw_mode_release,
+ .write = scmi_dbg_raw_mode_reset_write,
+ .owner = THIS_MODULE,
+};
+
+static const struct file_operations scmi_dbg_raw_mode_message_fops = {
+ .open = scmi_dbg_raw_mode_open,
+ .release = scmi_dbg_raw_mode_release,
+ .read = scmi_dbg_raw_mode_message_read,
+ .write = scmi_dbg_raw_mode_message_write,
+ .poll = scmi_dbg_raw_mode_message_poll,
+ .owner = THIS_MODULE,
+};
+
+static ssize_t scmi_dbg_raw_mode_message_async_write(struct file *filp,
+ const char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ return scmi_dbg_raw_mode_common_write(filp, buf, count, ppos, true);
+}
+
+static const struct file_operations scmi_dbg_raw_mode_message_async_fops = {
+ .open = scmi_dbg_raw_mode_open,
+ .release = scmi_dbg_raw_mode_release,
+ .read = scmi_dbg_raw_mode_message_read,
+ .write = scmi_dbg_raw_mode_message_async_write,
+ .poll = scmi_dbg_raw_mode_message_poll,
+ .owner = THIS_MODULE,
+};
+
+static ssize_t scmi_test_dbg_raw_mode_notif_read(struct file *filp,
+ char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ return scmi_dbg_raw_mode_common_read(filp, buf, count, ppos,
+ SCMI_RAW_NOTIF_QUEUE);
+}
+
+static __poll_t scmi_test_dbg_raw_mode_notif_poll(struct file *filp,
+ struct poll_table_struct *wait)
+{
+ return scmi_test_dbg_raw_common_poll(filp, wait, SCMI_RAW_NOTIF_QUEUE);
+}
+
+static const struct file_operations scmi_dbg_raw_mode_notification_fops = {
+ .open = scmi_dbg_raw_mode_open,
+ .release = scmi_dbg_raw_mode_release,
+ .read = scmi_test_dbg_raw_mode_notif_read,
+ .poll = scmi_test_dbg_raw_mode_notif_poll,
+ .owner = THIS_MODULE,
+};
+
+static ssize_t scmi_test_dbg_raw_mode_errors_read(struct file *filp,
+ char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ return scmi_dbg_raw_mode_common_read(filp, buf, count, ppos,
+ SCMI_RAW_ERRS_QUEUE);
+}
+
+static __poll_t scmi_test_dbg_raw_mode_errors_poll(struct file *filp,
+ struct poll_table_struct *wait)
+{
+ return scmi_test_dbg_raw_common_poll(filp, wait, SCMI_RAW_ERRS_QUEUE);
+}
+
+static const struct file_operations scmi_dbg_raw_mode_errors_fops = {
+ .open = scmi_dbg_raw_mode_open,
+ .release = scmi_dbg_raw_mode_release,
+ .read = scmi_test_dbg_raw_mode_errors_read,
+ .poll = scmi_test_dbg_raw_mode_errors_poll,
+ .owner = THIS_MODULE,
+};
+
+static int scmi_xfer_raw_free_bufs_init(struct scmi_raw_mode_info *raw, int idx)
+{
+ int i;
+ struct scmi_raw_buffer *rb;
+ struct device *dev = raw->handle->dev;
+
+ rb = devm_kcalloc(dev, raw->tx_max_msg, sizeof(*rb), GFP_KERNEL);
+ if (!rb)
+ return -ENOMEM;
+
+ spin_lock_init(&raw->free_bufs_lock[idx]);
+ INIT_LIST_HEAD(&raw->free_raw_bufs[idx]);
+ for (i = 0; i < raw->tx_max_msg; i++, rb++) {
+ rb->max_len = raw->desc->max_msg_size + sizeof(u32);
+ rb->msg.buf = devm_kzalloc(dev, rb->max_len, GFP_KERNEL);
+ if (!rb->msg.buf)
+ return -ENOMEM;
+ scmi_raw_buffer_put(raw, rb, idx);
+ }
+
+ spin_lock_init(&raw->msg_q_lock[idx]);
+ INIT_LIST_HEAD(&raw->msg_q[idx]);
+ init_waitqueue_head(&raw->wqs[idx]);
+
+ return 0;
+}
+
+static int scmi_xfer_raw_worker_init(struct scmi_raw_mode_info *raw)
+{
+ int i;
+ struct scmi_xfer_raw_waiter *rw;
+ struct device *dev = raw->handle->dev;
+
+ rw = devm_kcalloc(dev, raw->tx_max_msg, sizeof(*rw), GFP_KERNEL);
+ if (!rw)
+ return -ENOMEM;
+
+ raw->wait_wq = alloc_workqueue("scmi-raw-wait-wq-%d",
+ WQ_UNBOUND | WQ_FREEZABLE |
+ WQ_HIGHPRI, WQ_SYSFS, 0);
+ if (!raw->wait_wq)
+ return -ENOMEM;
+
+ mutex_init(&raw->free_mtx);
+ INIT_LIST_HEAD(&raw->free_waiters);
+ mutex_init(&raw->active_mtx);
+ INIT_LIST_HEAD(&raw->active_waiters);
+
+ for (i = 0; i < raw->tx_max_msg; i++, rw++) {
+ init_completion(&rw->async_response);
+ scmi_xfer_raw_waiter_put(raw, rw);
+ }
+ INIT_WORK(&raw->waiters_work, scmi_xfer_raw_worker);
+
+ return 0;
+}
+
+static int scmi_raw_mode_setup(struct scmi_raw_mode_info *raw)
+{
+ int ret, idx;
+ void *gid;
+ struct device *dev = raw->handle->dev;
+
+ gid = devres_open_group(dev, NULL, GFP_KERNEL);
+ if (!gid)
+ return -ENOMEM;
+
+ for (idx = 0; idx < SCMI_RAW_MAX_QUEUE; idx++) {
+ ret = scmi_xfer_raw_free_bufs_init(raw, idx);
+ if (ret)
+ goto err;
+ }
+
+ ret = scmi_xfer_raw_worker_init(raw);
+ if (ret)
+ goto err;
+
+ devres_close_group(dev, gid);
+ raw->gid = gid;
+
+ return 0;
+
+err:
+ devres_release_group(dev, gid);
+ return ret;
+}
+
+/**
+ * scmi_raw_mode_init - Function to initialize the SCMI Raw stack
+ *
+ * @handle: Pointer to SCMI entity handle
+ * @desc: Reference to the transport operations
+ * @tx_max_msg: Max number of in-flight messages allowed by the transport
+ *
+ * This function prepare the SCMI Raw stack and creates the debugfs API.
+ *
+ * Return: An opaque handle to the Raw instance on Success, an ERR_PTR otherwise
+ */
+void *scmi_raw_mode_init(const struct scmi_handle *handle,
+ const struct scmi_desc *desc, int tx_max_msg)
+{
+ int ret;
+ struct scmi_raw_mode_info *raw;
+ struct device *dev;
+
+ if (!handle || !desc)
+ return ERR_PTR(-EINVAL);
+
+ dev = handle->dev;
+ raw = devm_kzalloc(dev, sizeof(*raw), GFP_KERNEL);
+ if (!raw)
+ return ERR_PTR(-ENOMEM);
+
+ raw->handle = handle;
+ raw->desc = desc;
+ raw->tx_max_msg = tx_max_msg;
+
+ ret = scmi_raw_mode_setup(raw);
+ if (ret) {
+ devm_kfree(dev, raw);
+ return ERR_PTR(ret);
+ }
+
+ raw->dentry = debugfs_create_dir("scmi_raw", NULL);
+ if (IS_ERR(raw->dentry)) {
+ ret = PTR_ERR(raw->dentry);
+ devres_release_group(dev, raw->gid);
+ devm_kfree(dev, raw);
+ return ERR_PTR(ret);
+ }
+
+ debugfs_create_file("reset", 0200, raw->dentry, raw,
+ &scmi_dbg_raw_mode_reset_fops);
+
+ debugfs_create_u32("transport_rx_timeout_ms", 0400, raw->dentry,
+ (u32 *)&raw->desc->max_rx_timeout_ms);
+
+ debugfs_create_u32("transport_max_msg_size", 0400, raw->dentry,
+ (u32 *)&raw->desc->max_msg_size);
+
+ debugfs_create_u32("transport_tx_max_msg", 0400, raw->dentry,
+ (u32 *)&raw->tx_max_msg);
+
+ debugfs_create_file("message", 0600, raw->dentry, raw,
+ &scmi_dbg_raw_mode_message_fops);
+
+ debugfs_create_file("message_async", 0600, raw->dentry, raw,
+ &scmi_dbg_raw_mode_message_async_fops);
+
+ debugfs_create_file("notification", 0400, raw->dentry, raw,
+ &scmi_dbg_raw_mode_notification_fops);
+
+ debugfs_create_file("errors", 0400, raw->dentry, raw,
+ &scmi_dbg_raw_mode_errors_fops);
+
+ return raw;
+}
+
+/**
+ * scmi_raw_mode_cleanup - Function to cleanup the SCMI Raw stack
+ *
+ * @r: An opaque handle to an initialized SCMI Raw instance
+ */
+void scmi_raw_mode_cleanup(void *r)
+{
+ struct scmi_raw_mode_info *raw = r;
+
+ if (!raw)
+ return;
+
+ debugfs_remove_recursive(raw->dentry);
+
+ cancel_work_sync(&raw->waiters_work);
+ destroy_workqueue(raw->wait_wq);
+}
+
+static int scmi_xfer_raw_collect(struct scmi_xfer *xfer,
+ void *msg, size_t *msg_len)
+{
+ __le32 *m;
+ size_t msg_size;
+
+ if (!xfer || !msg || !msg_len)
+ return -EINVAL;
+
+ /* Account for hdr ...*/
+ msg_size = xfer->rx.len + sizeof(u32);
+ /* ... and status if needed */
+ if (xfer->hdr.type != MSG_TYPE_NOTIFICATION)
+ msg_size += sizeof(u32);
+
+ if (msg_size > *msg_len)
+ return -ENOSPC;
+
+ m = msg;
+ *m = cpu_to_le32(pack_scmi_header(&xfer->hdr));
+ if (xfer->hdr.type != MSG_TYPE_NOTIFICATION)
+ *++m = cpu_to_le32(xfer->hdr.status);
+
+ memcpy(++m, xfer->rx.buf, xfer->rx.len);
+
+ *msg_len = msg_size;
+
+ return 0;
+}
+
+/**
+ * scmi_raw_message_report - Helper to report back valid reponses/notifications
+ * to raw message requests.
+ *
+ * @r: An opaque reference to the raw instance configuration
+ * @xfer: The xfer containing the message to be reported
+ * @idx: The index of the queue.
+ *
+ * If Raw mode is enabled, this is called from the SCMI core on the regular RX
+ * path to save and enqueue the response/notification payload carried by this
+ * xfer into a dedicated scmi_raw_buffer for later consumption by the user.
+ *
+ * This way the caller can free the related xfer immediately afterwards and the
+ * user can read back the raw message payload at its own pace (if ever) without
+ * holding an xfer for too long.
+ */
+void scmi_raw_message_report(void *r, struct scmi_xfer *xfer, unsigned int idx)
+{
+ int ret;
+ struct scmi_raw_buffer *rb;
+ struct device *dev;
+ struct scmi_raw_mode_info *raw = r;
+
+ if (!raw)
+ return;
+
+ dev = raw->handle->dev;
+ rb = scmi_raw_buffer_get(raw, idx);
+ if (!rb) {
+ dev_warn(dev, "RAW[%d] - Cannot get a free RAW buffer\n", idx);
+ return;
+ }
+
+ ret = scmi_xfer_raw_collect(xfer, rb->msg.buf, &rb->msg.len);
+ if (ret) {
+ dev_warn(dev, "RAW - Cannot collect xfer into buffer !\n");
+ scmi_raw_buffer_put(raw, rb, idx);
+ return;
+ }
+
+ scmi_raw_buffer_enqueue(raw, rb, idx);
+}
+
+static void scmi_xfer_raw_fill(struct scmi_raw_mode_info *raw,
+ struct scmi_chan_info *cinfo,
+ struct scmi_xfer *xfer, u32 msg_hdr)
+{
+ /* Unpack received HDR as it is */
+ unpack_scmi_header(msg_hdr, &xfer->hdr);
+ xfer->hdr.seq = MSG_XTRACT_TOKEN(msg_hdr);
+
+ memset(xfer->rx.buf, 0x00, xfer->rx.len);
+
+ raw->desc->ops->fetch_response(cinfo, xfer);
+}
+
+/**
+ * scmi_raw_error_report - Helper to report back timed-out or generally
+ * unexpected replies.
+ *
+ * @r: An opaque reference to the raw instance configuration
+ * @cinfo: A reference to the channel to use to retrieve the broken xfer
+ * @msg_hdr: The SCMI message header of the message to fetch and report
+ * @priv: Any private data related to the xfer.
+ *
+ * If Raw mode is enabled, this is called from the SCMI core on the RX path in
+ * case of errors to save and enqueue the bad message payload carried by the
+ * message that has just been received.
+ *
+ * Note that we have to manually fetch any available payload into a temporary
+ * xfer to be able to save and enqueue the message, since the regular RX error
+ * path which had called this would have not fetched the message payload having
+ * classified it as an error.
+ */
+void scmi_raw_error_report(void *r, struct scmi_chan_info *cinfo,
+ u32 msg_hdr, void *priv)
+{
+ struct scmi_xfer xfer;
+ struct scmi_raw_buffer *rb;
+ struct scmi_raw_mode_info *raw = r;
+
+ if (!raw)
+ return;
+
+ rb = scmi_raw_buffer_get(raw, SCMI_RAW_ERRS_QUEUE);
+ if (!rb) {
+ dev_warn(raw->handle->dev,
+ "RAW[%d] - Cannot get a free RAW buffer\n",
+ SCMI_RAW_ERRS_QUEUE);
+ return;
+ }
+
+ /* Use a raw buffer to provide rx space to the temp xfer */
+ xfer.rx.buf = rb->msg.buf;
+ /*
+ * Allow max_msg_size...note that allocated rx.buf length is
+ * max_msg_size + sizeof(u32).
+ */
+ xfer.rx.len = raw->desc->max_msg_size;
+ if (priv)
+ /*
+ * Any transport-provided priv must be passed back down
+ * to transport
+ */
+ smp_store_mb(xfer.priv, priv);
+
+ scmi_xfer_raw_fill(raw, cinfo, &xfer, msg_hdr);
+ scmi_raw_message_report(raw, &xfer, SCMI_RAW_ERRS_QUEUE);
+
+ scmi_raw_buffer_put(raw, rb, SCMI_RAW_ERRS_QUEUE);
+}
diff --git a/drivers/firmware/arm_scmi/raw_mode.h b/drivers/firmware/arm_scmi/raw_mode.h
new file mode 100644
index 000000000000..e2d8672e1f8b
--- /dev/null
+++ b/drivers/firmware/arm_scmi/raw_mode.h
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * System Control and Management Interface (SCMI) Message Protocol
+ * Raw mode support header.
+ *
+ * Copyright (C) 2022 ARM Ltd.
+ */
+#ifndef _SCMI_RAW_MODE_H
+#define _SCMI_RAW_MODE_H
+
+#include "common.h"
+
+enum {
+ SCMI_RAW_REPLY_QUEUE,
+ SCMI_RAW_NOTIF_QUEUE,
+ SCMI_RAW_ERRS_QUEUE,
+ SCMI_RAW_MAX_QUEUE
+};
+
+void *scmi_raw_mode_init(const struct scmi_handle *handle,
+ const struct scmi_desc *desc, int tx_max_msg);
+void scmi_raw_mode_cleanup(void *raw);
+
+void scmi_raw_message_report(void *raw, struct scmi_xfer *xfer,
+ unsigned int idx);
+void scmi_raw_error_report(void *raw, struct scmi_chan_info *cinfo,
+ u32 msg_hdr, void *priv);
+
+#endif /* _SCMI_RAW_MODE_H */
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v4 09/11] firmware: arm_scmi: Add debugfs ABI documentation for Raw mode
2022-10-19 20:46 ` Cristian Marussi
@ 2022-10-19 20:46 ` Cristian Marussi
-1 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
Add description of the debugfs SCMI Raw ABI.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
Documentation/ABI/testing/debugfs-scmi-raw | 88 ++++++++++++++++++++++
1 file changed, 88 insertions(+)
create mode 100644 Documentation/ABI/testing/debugfs-scmi-raw
diff --git a/Documentation/ABI/testing/debugfs-scmi-raw b/Documentation/ABI/testing/debugfs-scmi-raw
new file mode 100644
index 000000000000..183ec678cb3e
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-scmi-raw
@@ -0,0 +1,88 @@
+What: /sys/kernel/debug/scmi_raw/transport_max_msg_size
+Date: December 2022
+KernelVersion: 6.1
+Contact: cristian.marussi@arm.com
+Description: Max message size of allowed SCMI messages for the currently
+ configured SCMI transport.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi_raw/transport_tx_max_msg
+Date: December 2022
+KernelVersion: 6.1
+Contact: cristian.marussi@arm.com
+Description: Max number of concurrently allowed in-flight SCMI messages for
+ the currently configured SCMI transport.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi_raw/transport_rx_timeout_ms
+Date: December 2022
+KernelVersion: 6.1
+Contact: cristian.marussi@arm.com
+Description: Timeout in milliseconds allowed for SCMI synchronous replies
+ for the currently configured SCMI transport.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi_raw/message
+Date: December 2022
+KernelVersion: 6.1
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw synchronous message injection/snooping facility; write
+ a complete SCMI synchronous command message (header included)
+ in little-endian binary format to have it sent to the configured
+ backend SCMI server.
+ Any subsequently received response can be read from this same
+ entry if it arrived within the configured timeout.
+ Each write to the entry causes one command request to be built
+ and sent while the replies are read back one message at time
+ (receiving an EOF at each message boundary).
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi_raw/message_async
+Date: December 2022
+KernelVersion: 6.1
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw asynchronous message injection/snooping facility; write
+ a complete SCMI asynchronous command message (header included)
+ in little-endian binary format to have it sent to the configured
+ backend SCMI server.
+ Any subsequently received response can be read from this same
+ entry if it arrived within the configured timeout.
+ Any additional delayed response received afterwards can be read
+ from this same entry too if it arrived within the configured
+ timeout.
+ Each write to the entry causes one command request to be built
+ and sent while the replies are read back one message at time
+ (receiving an EOF at each message boundary).
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi_raw/errors
+Date: December 2022
+KernelVersion: 6.1
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw message errors facility; any kind of timed-out or
+ generally unexpectedly received SCMI message can be read from
+ this entry.
+ Each read gives back one message at time (receiving an EOF at
+ each message boundary).
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi_raw/notification
+Date: December 2022
+KernelVersion: 6.1
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw notification snooping facility; any notification
+ emitted by the backend SCMI server can be read from this entry.
+ Each read gives back one message at time (receiving an EOF at
+ each message boundary).
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi_raw/reset
+Date: December 2022
+KernelVersion: 6.1
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw stack reset facility; writing a value to this entry
+ causes the internal queues of any kind of received message,
+ still pending to be read out, to be flushed.
+ Can be used to reset and clean the SCMI Raw stack between to
+ different test-run.
+Users: Debugging, any userspace test suite
--
2.34.1
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v4 09/11] firmware: arm_scmi: Add debugfs ABI documentation for Raw mode
@ 2022-10-19 20:46 ` Cristian Marussi
0 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
Add description of the debugfs SCMI Raw ABI.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
Documentation/ABI/testing/debugfs-scmi-raw | 88 ++++++++++++++++++++++
1 file changed, 88 insertions(+)
create mode 100644 Documentation/ABI/testing/debugfs-scmi-raw
diff --git a/Documentation/ABI/testing/debugfs-scmi-raw b/Documentation/ABI/testing/debugfs-scmi-raw
new file mode 100644
index 000000000000..183ec678cb3e
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-scmi-raw
@@ -0,0 +1,88 @@
+What: /sys/kernel/debug/scmi_raw/transport_max_msg_size
+Date: December 2022
+KernelVersion: 6.1
+Contact: cristian.marussi@arm.com
+Description: Max message size of allowed SCMI messages for the currently
+ configured SCMI transport.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi_raw/transport_tx_max_msg
+Date: December 2022
+KernelVersion: 6.1
+Contact: cristian.marussi@arm.com
+Description: Max number of concurrently allowed in-flight SCMI messages for
+ the currently configured SCMI transport.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi_raw/transport_rx_timeout_ms
+Date: December 2022
+KernelVersion: 6.1
+Contact: cristian.marussi@arm.com
+Description: Timeout in milliseconds allowed for SCMI synchronous replies
+ for the currently configured SCMI transport.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi_raw/message
+Date: December 2022
+KernelVersion: 6.1
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw synchronous message injection/snooping facility; write
+ a complete SCMI synchronous command message (header included)
+ in little-endian binary format to have it sent to the configured
+ backend SCMI server.
+ Any subsequently received response can be read from this same
+ entry if it arrived within the configured timeout.
+ Each write to the entry causes one command request to be built
+ and sent while the replies are read back one message at time
+ (receiving an EOF at each message boundary).
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi_raw/message_async
+Date: December 2022
+KernelVersion: 6.1
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw asynchronous message injection/snooping facility; write
+ a complete SCMI asynchronous command message (header included)
+ in little-endian binary format to have it sent to the configured
+ backend SCMI server.
+ Any subsequently received response can be read from this same
+ entry if it arrived within the configured timeout.
+ Any additional delayed response received afterwards can be read
+ from this same entry too if it arrived within the configured
+ timeout.
+ Each write to the entry causes one command request to be built
+ and sent while the replies are read back one message at time
+ (receiving an EOF at each message boundary).
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi_raw/errors
+Date: December 2022
+KernelVersion: 6.1
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw message errors facility; any kind of timed-out or
+ generally unexpectedly received SCMI message can be read from
+ this entry.
+ Each read gives back one message at time (receiving an EOF at
+ each message boundary).
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi_raw/notification
+Date: December 2022
+KernelVersion: 6.1
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw notification snooping facility; any notification
+ emitted by the backend SCMI server can be read from this entry.
+ Each read gives back one message at time (receiving an EOF at
+ each message boundary).
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi_raw/reset
+Date: December 2022
+KernelVersion: 6.1
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw stack reset facility; writing a value to this entry
+ causes the internal queues of any kind of received message,
+ still pending to be read out, to be flushed.
+ Can be used to reset and clean the SCMI Raw stack between to
+ different test-run.
+Users: Debugging, any userspace test suite
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v4 10/11] firmware: arm_scmi: Reject SCMI drivers while in Raw mode
2022-10-19 20:46 ` Cristian Marussi
@ 2022-10-19 20:46 ` Cristian Marussi
-1 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
Reject SCMI driver registration when SCMI Raw mode support is configured,
so as to avoid interferences between the SCMI Raw mode transactions and the
normal SCMI stack operations.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
drivers/firmware/arm_scmi/driver.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index b504b5cdc55f..3e5539987443 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -2365,6 +2365,12 @@ int scmi_protocol_device_request(const struct scmi_device_id *id_table)
pr_debug("Requesting SCMI device (%s) for protocol %x\n",
id_table->name, id_table->protocol_id);
+ if (IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT)) {
+ pr_warn("SCMI Raw mode active. Rejecting '%s'/0x%02X\n",
+ id_table->name, id_table->protocol_id);
+ return -EINVAL;
+ }
+
/*
* Search for the matching protocol rdev list and then search
* of any existent equally named device...fails if any duplicate found.
--
2.34.1
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v4 10/11] firmware: arm_scmi: Reject SCMI drivers while in Raw mode
@ 2022-10-19 20:46 ` Cristian Marussi
0 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
Reject SCMI driver registration when SCMI Raw mode support is configured,
so as to avoid interferences between the SCMI Raw mode transactions and the
normal SCMI stack operations.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
drivers/firmware/arm_scmi/driver.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index b504b5cdc55f..3e5539987443 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -2365,6 +2365,12 @@ int scmi_protocol_device_request(const struct scmi_device_id *id_table)
pr_debug("Requesting SCMI device (%s) for protocol %x\n",
id_table->name, id_table->protocol_id);
+ if (IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT)) {
+ pr_warn("SCMI Raw mode active. Rejecting '%s'/0x%02X\n",
+ id_table->name, id_table->protocol_id);
+ return -EINVAL;
+ }
+
/*
* Search for the matching protocol rdev list and then search
* of any existent equally named device...fails if any duplicate found.
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v4 11/11] firmware: arm_scmi: Call Raw mode hooks from the core stack
2022-10-19 20:46 ` Cristian Marussi
@ 2022-10-19 20:46 ` Cristian Marussi
-1 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
Add a few call sites where, if SCMI Raw mode access had been enabled in
Kconfig, the needed SCMI Raw initialization and hooks are called.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
v3 --> v4
- add call hooks to support polled transports
v1 --> v2
- fixes need to use multiple cinfo if available
---
drivers/firmware/arm_scmi/driver.c | 45 ++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 3e5539987443..e28104e1b961 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -34,6 +34,8 @@
#include "common.h"
#include "notify.h"
+#include "raw_mode.h"
+
#define CREATE_TRACE_POINTS
#include <trace/events/scmi.h>
@@ -133,6 +135,7 @@ struct scmi_protocol_instance {
* @notify_priv: Pointer to private data structure specific to notifications.
* @node: List head
* @users: Number of users of this instance
+ * @raw: An opaque reference handle used by SCMI Raw mode.
*/
struct scmi_info {
struct device *dev;
@@ -152,6 +155,7 @@ struct scmi_info {
void *notify_priv;
struct list_head node;
int users;
+ void *raw;
};
#define handle_to_scmi_info(h) container_of(h, struct scmi_info, handle)
@@ -761,6 +765,11 @@ static void scmi_handle_notification(struct scmi_chan_info *cinfo,
xfer->hdr.protocol_id, xfer->hdr.seq,
MSG_TYPE_NOTIFICATION);
+ if (IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT)) {
+ xfer->hdr.seq = MSG_XTRACT_TOKEN(msg_hdr);
+ scmi_raw_message_report(info->raw, xfer, SCMI_RAW_NOTIF_QUEUE);
+ }
+
__scmi_xfer_put(minfo, xfer);
scmi_clear_channel(info, cinfo);
@@ -774,6 +783,9 @@ static void scmi_handle_response(struct scmi_chan_info *cinfo,
xfer = scmi_xfer_command_acquire(cinfo, msg_hdr);
if (IS_ERR(xfer)) {
+ if (IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT))
+ scmi_raw_error_report(info->raw, cinfo, msg_hdr, priv);
+
if (MSG_XTRACT_TYPE(msg_hdr) == MSG_TYPE_DELAYED_RESP)
scmi_clear_channel(info, cinfo);
return;
@@ -805,6 +817,16 @@ static void scmi_handle_response(struct scmi_chan_info *cinfo,
complete(&xfer->done);
}
+ if (IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT)) {
+ /*
+ * When in polling mode avoid to queue the Raw xfer on the IRQ
+ * RX path since it will be already queued at the end of the TX
+ * poll loop.
+ */
+ if (!xfer->hdr.poll_completion)
+ scmi_raw_message_report(info->raw, xfer, SCMI_RAW_REPLY_QUEUE);
+ }
+
scmi_xfer_command_release(info, xfer);
}
@@ -915,6 +937,14 @@ static int scmi_wait_for_reply(struct device *dev, const struct scmi_desc *desc,
"RESP",
xfer->hdr.seq, xfer->hdr.status,
xfer->rx.buf, xfer->rx.len);
+
+ if (IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT)) {
+ struct scmi_info *info =
+ handle_to_scmi_info(cinfo->handle);
+
+ scmi_raw_message_report(info->raw, xfer,
+ SCMI_RAW_REPLY_QUEUE);
+ }
}
} else {
/* And we wait for the response. */
@@ -2587,6 +2617,18 @@ static int scmi_probe(struct platform_device *pdev)
if (ret)
goto clear_txrx_setup;
+ if (IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT)) {
+ info->raw = scmi_raw_mode_init(handle, info->desc,
+ info->tx_minfo.max_msg);
+ if (!IS_ERR(info->raw)) {
+ dev_info(dev, "SCMI RAW Mode initialized.\n");
+ return 0;
+ }
+
+ dev_err(dev, "Failed to initialize SCMI RAW Mode !\n");
+ info->raw = NULL;
+ }
+
if (scmi_notification_init(handle))
dev_err(dev, "SCMI Notifications NOT available.\n");
@@ -2661,6 +2703,9 @@ static int scmi_remove(struct platform_device *pdev)
struct scmi_info *info = platform_get_drvdata(pdev);
struct device_node *child;
+ if (IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT))
+ scmi_raw_mode_cleanup(info->raw);
+
mutex_lock(&scmi_list_mutex);
if (info->users)
ret = -EBUSY;
--
2.34.1
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v4 11/11] firmware: arm_scmi: Call Raw mode hooks from the core stack
@ 2022-10-19 20:46 ` Cristian Marussi
0 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-19 20:46 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, f.fainelli,
etienne.carriere, vincent.guittot, souvik.chakravarty, wleavitt,
peter.hilber, nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan,
cristian.marussi
Add a few call sites where, if SCMI Raw mode access had been enabled in
Kconfig, the needed SCMI Raw initialization and hooks are called.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
v3 --> v4
- add call hooks to support polled transports
v1 --> v2
- fixes need to use multiple cinfo if available
---
drivers/firmware/arm_scmi/driver.c | 45 ++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 3e5539987443..e28104e1b961 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -34,6 +34,8 @@
#include "common.h"
#include "notify.h"
+#include "raw_mode.h"
+
#define CREATE_TRACE_POINTS
#include <trace/events/scmi.h>
@@ -133,6 +135,7 @@ struct scmi_protocol_instance {
* @notify_priv: Pointer to private data structure specific to notifications.
* @node: List head
* @users: Number of users of this instance
+ * @raw: An opaque reference handle used by SCMI Raw mode.
*/
struct scmi_info {
struct device *dev;
@@ -152,6 +155,7 @@ struct scmi_info {
void *notify_priv;
struct list_head node;
int users;
+ void *raw;
};
#define handle_to_scmi_info(h) container_of(h, struct scmi_info, handle)
@@ -761,6 +765,11 @@ static void scmi_handle_notification(struct scmi_chan_info *cinfo,
xfer->hdr.protocol_id, xfer->hdr.seq,
MSG_TYPE_NOTIFICATION);
+ if (IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT)) {
+ xfer->hdr.seq = MSG_XTRACT_TOKEN(msg_hdr);
+ scmi_raw_message_report(info->raw, xfer, SCMI_RAW_NOTIF_QUEUE);
+ }
+
__scmi_xfer_put(minfo, xfer);
scmi_clear_channel(info, cinfo);
@@ -774,6 +783,9 @@ static void scmi_handle_response(struct scmi_chan_info *cinfo,
xfer = scmi_xfer_command_acquire(cinfo, msg_hdr);
if (IS_ERR(xfer)) {
+ if (IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT))
+ scmi_raw_error_report(info->raw, cinfo, msg_hdr, priv);
+
if (MSG_XTRACT_TYPE(msg_hdr) == MSG_TYPE_DELAYED_RESP)
scmi_clear_channel(info, cinfo);
return;
@@ -805,6 +817,16 @@ static void scmi_handle_response(struct scmi_chan_info *cinfo,
complete(&xfer->done);
}
+ if (IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT)) {
+ /*
+ * When in polling mode avoid to queue the Raw xfer on the IRQ
+ * RX path since it will be already queued at the end of the TX
+ * poll loop.
+ */
+ if (!xfer->hdr.poll_completion)
+ scmi_raw_message_report(info->raw, xfer, SCMI_RAW_REPLY_QUEUE);
+ }
+
scmi_xfer_command_release(info, xfer);
}
@@ -915,6 +937,14 @@ static int scmi_wait_for_reply(struct device *dev, const struct scmi_desc *desc,
"RESP",
xfer->hdr.seq, xfer->hdr.status,
xfer->rx.buf, xfer->rx.len);
+
+ if (IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT)) {
+ struct scmi_info *info =
+ handle_to_scmi_info(cinfo->handle);
+
+ scmi_raw_message_report(info->raw, xfer,
+ SCMI_RAW_REPLY_QUEUE);
+ }
}
} else {
/* And we wait for the response. */
@@ -2587,6 +2617,18 @@ static int scmi_probe(struct platform_device *pdev)
if (ret)
goto clear_txrx_setup;
+ if (IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT)) {
+ info->raw = scmi_raw_mode_init(handle, info->desc,
+ info->tx_minfo.max_msg);
+ if (!IS_ERR(info->raw)) {
+ dev_info(dev, "SCMI RAW Mode initialized.\n");
+ return 0;
+ }
+
+ dev_err(dev, "Failed to initialize SCMI RAW Mode !\n");
+ info->raw = NULL;
+ }
+
if (scmi_notification_init(handle))
dev_err(dev, "SCMI Notifications NOT available.\n");
@@ -2661,6 +2703,9 @@ static int scmi_remove(struct platform_device *pdev)
struct scmi_info *info = platform_get_drvdata(pdev);
struct device_node *child;
+ if (IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT))
+ scmi_raw_mode_cleanup(info->raw);
+
mutex_lock(&scmi_list_mutex);
if (info->users)
ret = -EBUSY;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
2022-10-19 20:46 ` Cristian Marussi
@ 2022-10-28 14:40 ` Vincent Guittot
-1 siblings, 0 replies; 50+ messages in thread
From: Vincent Guittot @ 2022-10-28 14:40 UTC (permalink / raw)
To: Cristian Marussi
Cc: linux-kernel, linux-arm-kernel, sudeep.holla, james.quinlan,
Jonathan.Cameron, f.fainelli, etienne.carriere,
souvik.chakravarty, wleavitt, peter.hilber, nicola.mazzucato,
tarek.el-sherbiny, quic_kshivnan
On Wed, 19 Oct 2022 at 22:46, Cristian Marussi <cristian.marussi@arm.com> wrote:
>
> Hi all,
>
> This series aims to introduce a new SCMI unified userspace interface meant
> to ease testing an SCMI Server implementation for compliance, fuzzing etc.,
> from the perspective of the OSPM agent (non-secure world only ...)
>
> It is proposed as a testing/development facility, it is NOT meant to be a
> feature to use in production, but only enabled in Kconfig for test
> deployments.
>
> Currently an SCMI Compliance Suite like the one at [1] can only work by
> injecting SCMI messages at the SCMI transport layer using the mailbox test
> driver (CONFIG_MAILBOX_TEST) via its few debugfs entries and looking at
> the related replies from the SCMI backend Server.
>
> This approach has a few drawbacks:
>
> - the SCMI Server under test MUST be reachable through a mailbox based
> SCMI transport: any other SCMI Server placement is not possible (like in
> a VM reachable via SCMI Virtio). In order to cover other placements in
> the current scenario we should write some sort of test driver for each
> and every existent SCMI transport and for any future additional transport
> ...this clearly does not scale.
>
> - even in the mailbox case the userspace Compliance suite cannot simply
> send and receive bare SCMI messages BUT it has to properly lay them out
> into the shared memory exposed by the mailbox test driver as expected by
> the transport definitions. In other words such a userspace test
> application has to, not only use a proper transport driver for the system
> at hand, but it also has to have a comprehensive knowledge of the
> internals of the underlying transport in order to operate.
>
> - last but not least, the system under test has to be specifically
> configured and built, in terms of Kconfig and DT, to perform such kind of
> testing, it cannot be used for anything else, which is unfortunate for
> CI/CD deployments.
>
> This series introduces a new SCMI Raw mode support feature that, when
> configured and enabled exposes a new interface in debugfs through which:
>
> - a userspace application can inject bare SCMI binary messages into the
> SCMI core stack; such messages will be routed by the SCMI regular kernel
> stack to the backend Server using the currently configured transport
> transparently: in other words you can test the SCMI server, no matter
> where it is placed, as long as it is reachable from the currently
> configured SCMI stack.
> Same goes the other way around on the reading path: any SCMI server reply
> can be read as a bare SCMI binary message from the same debugfs path.
>
> - as a direct consequence of this way of injecting bare messages in the
> middle of the SCMI stack (instead of beneath it at the transport layer)
> the user application has to handle only bare SCMI messages without having
> to worry about the specific underlying transport internals that will be
> taken care of by the SCMI core stack itself using its own machinery,
> without duplicating such logic.
>
> - a system under test, once configured with SCMI Raw support enabled in
> Kconfig, can be booted without any particular DT change.
>
> In V2 the runtime enable/disable switching capability has been removed
> (for now) since still not deemed to be stable/reliable enough: as a
> consequence when SCMI Raw support is compiled in, the regular SCMI stack
> drivers are now inhibited permanently for that Kernel.
>
> In V4 it has been added the support for transports lacking a completion_irq
> or configured forcibly in polled mode.
>
> A quick and trivial example from the shell...reading from a sensor
> injecting a properly crafted packet in raw mode:
>
> # INJECT THE SENSOR_READING MESSAGE FOR SENSOR ID=1 (binary little endian)
> root@deb-buster-arm64:~# echo -e -n \\x06\\x54\\x00\\x00\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x00 > /sys/kernel/debug/scmi_raw/message
>
> # READING BACK THE REPLY...
> root@deb-buster-arm64:~# cat /sys/kernel/debug/scmi_raw/message | od --endian=little -t x4
> 0000000 00005406 00000000 00000335 00000000
> 0000020
>
> while doing that, since Raw mode makes (partial) use of the regular SCMI
> stack, you can observe the messages going through the SCMI stack with the
> usual traces:
>
> bash-329 [000] ..... 14183.446808: scmi_msg_dump: pt=15 t=CMND msg_id=06 seq=0000 s=0 pyld=0100000000000000
> irq/35-mhu_db_l-81 [000] ..... 14183.447809: scmi_msg_dump: pt=15 t=RESP msg_id=06 seq=0000 s=0 pyld=3503000000000000
>
>
> ..trying to read in async when the backend server does NOT supports asyncs:
>
> # AN ASYNC SENSOR READING REQUEST...
> root@deb-buster-arm64:~# echo -e -n \\x06\\x54\\x00\\x00\\x01\\x00\\x00\\x00\\x01\\x00\\x00\\x00 > /sys/kernel/debug/scmi_raw/message_async
>
> bash-329 [000] ..... 16415.938739: scmi_msg_dump: pt=15 t=CMND msg_id=06 seq=0000 s=0 pyld=0100000001000000
> irq/35-mhu_db_l-81 [000] ..... 16415.944129: scmi_msg_dump: pt=15 t=RESP msg_id=06 seq=0000 s=-1 pyld=
>
> # RETURNS A STATUS -1 FROM THE SERVER NOT SUPPORTING IT
> root@deb-buster-arm64:~# cat /sys/kernel/debug/scmi_raw/message | od --endian=little -t x4
> 0000000 00005406 ffffffff
> 0000010
>
> Note that this was on a JUNO, BUT exactly the same steps can be used to
> reach an SCMI Server living on a VM reachable via virtio as long as the
> system under test if properly configured to work with a virtio transport.
>
> In a nutshell the exposed API is as follows:
>
> /sys/kernel/debug/scmi_raw/
> ├── errors
> ├── message
> ├── message_async
> ├── notification
> ├── reset
> ├── transport_max_msg_size
> ├── transport_rx_timeout_ms
> └── transport_tx_max_msg
>
> where:
>
> - message*: used to send sync/async commands and read back immediate and
> delayed responses (if any)
> - errors: used to report timeout and unexpected replies
> - reset: used to reset the SCMI Raw stack, flushing all queues from
> received messages still pending to be read out (useful to be sure to
> cleanup between test suite runs...)
> - notification: used to read any notification being spit by the system
> (if previously enabled by the user app)
> - transport*: a bunch of configuration useful to setup the user
> application expectations in terms of timeouts and message
> characteristics.
>
> Each write corresponds to one command request and the replies or delayed
> response are read back one message at time (receiving an EOF at each
> message boundary).
>
> The user application running the test is in charge of handling timeouts
> and properly choosing SCMI sequence numbers for the outgoing requests: note
> that the same fixed number can be re-used (...though discouraged...) as
> long as the suite does NOT expect to send multiple in-flight commands
> concurrently.
>
> Since the SCMI core regular stack is partially used to deliver and collect
> the messages, late replies after timeouts and any other sort of unexpected
> message sent by the SCMI server platform back can be identified by the SCMI
> core as usual and it will be reported under /errors for later analysis.
> (a userspace test-app will have anyway properly detected the timeout on
> /message* ...)
>
> All of the above has been roughly tested against a standard JUNO SCP SCMI
> Server (mailbox trans) and an emulated SCMI Server living in a VM (virtio
> trans) using a custom experimental version of the scmi-tests Compliance
> suite patched to support Raw mode and posted at [2]. (still in development
> ...merge requests are in progress...for now it is just a mean for me to
> test the testing API ... O_o)
>
> The series is based on v6.1-rc1.
>
> Having said that (in such a concise and brief way :P) ...
>
> ...any feedback/comments are welcome !
Hi Cristian,
I have tested your series with an optee message transport layer and
been able to send raw messages to the scmi server PTA
FWIW
Tested-by: Vincent Guittot <vincent.guittot@linaro.org>
>
> Thanks,
> Cristian
>
> ---
> V3 --> v4
> - rebased on v6.1-rc1
> - addedd missing support for 'polled' transports and transport lacking a
> completion_irq (like smc/optee)
> - removed a few inlines
> - refactored SCMI Raw RX patch to make use more extensively of the regular
> non-Raw RX path
> - fix handling of O_NONBLOCK raw_mode read requests
>
> v2 --> v3
> - fixed some sparse warning on LE and __poll_t
> - reworked and simplified deferred worker in charge of xfer delayed waiting
> - allow for injection of DT-unknown protocols messages when in Raw mode
> (needed for any kind of fuzzing...)
>
> v1 --> v2
> - added comments and debugfs docs
> - added dedicated transport devices for channels initialization
> - better channels handling in Raw mode
> - removed runtime enable, moved to static compile time exclusion
> of SCMI regular stack
>
> [1]: https://gitlab.arm.com/tests/scmi-tests
> [2]: https://gitlab.arm.com/tests/scmi-tests/-/commits/raw_mode_support_devel/
>
>
> Cristian Marussi (11):
> firmware: arm_scmi: Refactor xfer in-flight registration routines
> firmware: arm_scmi: Simplify chan_available transport operation
> firmware: arm_scmi: Use dedicated devices to initialize channels
> firmware: arm_scmi: Refactor polling helpers
> firmware: arm_scmi: Refactor scmi_wait_for_message_response
> firmware: arm_scmi: Add xfer raw helpers
> firmware: arm_scmi: Move errors defs and code to common.h
> firmware: arm_scmi: Add raw transmission support
> firmware: arm_scmi: Add debugfs ABI documentation for Raw mode
> firmware: arm_scmi: Reject SCMI drivers while in Raw mode
> firmware: arm_scmi: Call Raw mode hooks from the core stack
>
> Documentation/ABI/testing/debugfs-scmi-raw | 88 ++
> drivers/firmware/arm_scmi/Kconfig | 13 +
> drivers/firmware/arm_scmi/Makefile | 1 +
> drivers/firmware/arm_scmi/common.h | 72 +-
> drivers/firmware/arm_scmi/driver.c | 521 +++++---
> drivers/firmware/arm_scmi/mailbox.c | 4 +-
> drivers/firmware/arm_scmi/optee.c | 4 +-
> drivers/firmware/arm_scmi/raw_mode.c | 1244 ++++++++++++++++++++
> drivers/firmware/arm_scmi/raw_mode.h | 29 +
> drivers/firmware/arm_scmi/smc.c | 4 +-
> drivers/firmware/arm_scmi/virtio.c | 2 +-
> 11 files changed, 1827 insertions(+), 155 deletions(-)
> create mode 100644 Documentation/ABI/testing/debugfs-scmi-raw
> create mode 100644 drivers/firmware/arm_scmi/raw_mode.c
> create mode 100644 drivers/firmware/arm_scmi/raw_mode.h
>
> --
> 2.34.1
>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
@ 2022-10-28 14:40 ` Vincent Guittot
0 siblings, 0 replies; 50+ messages in thread
From: Vincent Guittot @ 2022-10-28 14:40 UTC (permalink / raw)
To: Cristian Marussi
Cc: linux-kernel, linux-arm-kernel, sudeep.holla, james.quinlan,
Jonathan.Cameron, f.fainelli, etienne.carriere,
souvik.chakravarty, wleavitt, peter.hilber, nicola.mazzucato,
tarek.el-sherbiny, quic_kshivnan
On Wed, 19 Oct 2022 at 22:46, Cristian Marussi <cristian.marussi@arm.com> wrote:
>
> Hi all,
>
> This series aims to introduce a new SCMI unified userspace interface meant
> to ease testing an SCMI Server implementation for compliance, fuzzing etc.,
> from the perspective of the OSPM agent (non-secure world only ...)
>
> It is proposed as a testing/development facility, it is NOT meant to be a
> feature to use in production, but only enabled in Kconfig for test
> deployments.
>
> Currently an SCMI Compliance Suite like the one at [1] can only work by
> injecting SCMI messages at the SCMI transport layer using the mailbox test
> driver (CONFIG_MAILBOX_TEST) via its few debugfs entries and looking at
> the related replies from the SCMI backend Server.
>
> This approach has a few drawbacks:
>
> - the SCMI Server under test MUST be reachable through a mailbox based
> SCMI transport: any other SCMI Server placement is not possible (like in
> a VM reachable via SCMI Virtio). In order to cover other placements in
> the current scenario we should write some sort of test driver for each
> and every existent SCMI transport and for any future additional transport
> ...this clearly does not scale.
>
> - even in the mailbox case the userspace Compliance suite cannot simply
> send and receive bare SCMI messages BUT it has to properly lay them out
> into the shared memory exposed by the mailbox test driver as expected by
> the transport definitions. In other words such a userspace test
> application has to, not only use a proper transport driver for the system
> at hand, but it also has to have a comprehensive knowledge of the
> internals of the underlying transport in order to operate.
>
> - last but not least, the system under test has to be specifically
> configured and built, in terms of Kconfig and DT, to perform such kind of
> testing, it cannot be used for anything else, which is unfortunate for
> CI/CD deployments.
>
> This series introduces a new SCMI Raw mode support feature that, when
> configured and enabled exposes a new interface in debugfs through which:
>
> - a userspace application can inject bare SCMI binary messages into the
> SCMI core stack; such messages will be routed by the SCMI regular kernel
> stack to the backend Server using the currently configured transport
> transparently: in other words you can test the SCMI server, no matter
> where it is placed, as long as it is reachable from the currently
> configured SCMI stack.
> Same goes the other way around on the reading path: any SCMI server reply
> can be read as a bare SCMI binary message from the same debugfs path.
>
> - as a direct consequence of this way of injecting bare messages in the
> middle of the SCMI stack (instead of beneath it at the transport layer)
> the user application has to handle only bare SCMI messages without having
> to worry about the specific underlying transport internals that will be
> taken care of by the SCMI core stack itself using its own machinery,
> without duplicating such logic.
>
> - a system under test, once configured with SCMI Raw support enabled in
> Kconfig, can be booted without any particular DT change.
>
> In V2 the runtime enable/disable switching capability has been removed
> (for now) since still not deemed to be stable/reliable enough: as a
> consequence when SCMI Raw support is compiled in, the regular SCMI stack
> drivers are now inhibited permanently for that Kernel.
>
> In V4 it has been added the support for transports lacking a completion_irq
> or configured forcibly in polled mode.
>
> A quick and trivial example from the shell...reading from a sensor
> injecting a properly crafted packet in raw mode:
>
> # INJECT THE SENSOR_READING MESSAGE FOR SENSOR ID=1 (binary little endian)
> root@deb-buster-arm64:~# echo -e -n \\x06\\x54\\x00\\x00\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x00 > /sys/kernel/debug/scmi_raw/message
>
> # READING BACK THE REPLY...
> root@deb-buster-arm64:~# cat /sys/kernel/debug/scmi_raw/message | od --endian=little -t x4
> 0000000 00005406 00000000 00000335 00000000
> 0000020
>
> while doing that, since Raw mode makes (partial) use of the regular SCMI
> stack, you can observe the messages going through the SCMI stack with the
> usual traces:
>
> bash-329 [000] ..... 14183.446808: scmi_msg_dump: pt=15 t=CMND msg_id=06 seq=0000 s=0 pyld=0100000000000000
> irq/35-mhu_db_l-81 [000] ..... 14183.447809: scmi_msg_dump: pt=15 t=RESP msg_id=06 seq=0000 s=0 pyld=3503000000000000
>
>
> ..trying to read in async when the backend server does NOT supports asyncs:
>
> # AN ASYNC SENSOR READING REQUEST...
> root@deb-buster-arm64:~# echo -e -n \\x06\\x54\\x00\\x00\\x01\\x00\\x00\\x00\\x01\\x00\\x00\\x00 > /sys/kernel/debug/scmi_raw/message_async
>
> bash-329 [000] ..... 16415.938739: scmi_msg_dump: pt=15 t=CMND msg_id=06 seq=0000 s=0 pyld=0100000001000000
> irq/35-mhu_db_l-81 [000] ..... 16415.944129: scmi_msg_dump: pt=15 t=RESP msg_id=06 seq=0000 s=-1 pyld=
>
> # RETURNS A STATUS -1 FROM THE SERVER NOT SUPPORTING IT
> root@deb-buster-arm64:~# cat /sys/kernel/debug/scmi_raw/message | od --endian=little -t x4
> 0000000 00005406 ffffffff
> 0000010
>
> Note that this was on a JUNO, BUT exactly the same steps can be used to
> reach an SCMI Server living on a VM reachable via virtio as long as the
> system under test if properly configured to work with a virtio transport.
>
> In a nutshell the exposed API is as follows:
>
> /sys/kernel/debug/scmi_raw/
> ├── errors
> ├── message
> ├── message_async
> ├── notification
> ├── reset
> ├── transport_max_msg_size
> ├── transport_rx_timeout_ms
> └── transport_tx_max_msg
>
> where:
>
> - message*: used to send sync/async commands and read back immediate and
> delayed responses (if any)
> - errors: used to report timeout and unexpected replies
> - reset: used to reset the SCMI Raw stack, flushing all queues from
> received messages still pending to be read out (useful to be sure to
> cleanup between test suite runs...)
> - notification: used to read any notification being spit by the system
> (if previously enabled by the user app)
> - transport*: a bunch of configuration useful to setup the user
> application expectations in terms of timeouts and message
> characteristics.
>
> Each write corresponds to one command request and the replies or delayed
> response are read back one message at time (receiving an EOF at each
> message boundary).
>
> The user application running the test is in charge of handling timeouts
> and properly choosing SCMI sequence numbers for the outgoing requests: note
> that the same fixed number can be re-used (...though discouraged...) as
> long as the suite does NOT expect to send multiple in-flight commands
> concurrently.
>
> Since the SCMI core regular stack is partially used to deliver and collect
> the messages, late replies after timeouts and any other sort of unexpected
> message sent by the SCMI server platform back can be identified by the SCMI
> core as usual and it will be reported under /errors for later analysis.
> (a userspace test-app will have anyway properly detected the timeout on
> /message* ...)
>
> All of the above has been roughly tested against a standard JUNO SCP SCMI
> Server (mailbox trans) and an emulated SCMI Server living in a VM (virtio
> trans) using a custom experimental version of the scmi-tests Compliance
> suite patched to support Raw mode and posted at [2]. (still in development
> ...merge requests are in progress...for now it is just a mean for me to
> test the testing API ... O_o)
>
> The series is based on v6.1-rc1.
>
> Having said that (in such a concise and brief way :P) ...
>
> ...any feedback/comments are welcome !
Hi Cristian,
I have tested your series with an optee message transport layer and
been able to send raw messages to the scmi server PTA
FWIW
Tested-by: Vincent Guittot <vincent.guittot@linaro.org>
>
> Thanks,
> Cristian
>
> ---
> V3 --> v4
> - rebased on v6.1-rc1
> - addedd missing support for 'polled' transports and transport lacking a
> completion_irq (like smc/optee)
> - removed a few inlines
> - refactored SCMI Raw RX patch to make use more extensively of the regular
> non-Raw RX path
> - fix handling of O_NONBLOCK raw_mode read requests
>
> v2 --> v3
> - fixed some sparse warning on LE and __poll_t
> - reworked and simplified deferred worker in charge of xfer delayed waiting
> - allow for injection of DT-unknown protocols messages when in Raw mode
> (needed for any kind of fuzzing...)
>
> v1 --> v2
> - added comments and debugfs docs
> - added dedicated transport devices for channels initialization
> - better channels handling in Raw mode
> - removed runtime enable, moved to static compile time exclusion
> of SCMI regular stack
>
> [1]: https://gitlab.arm.com/tests/scmi-tests
> [2]: https://gitlab.arm.com/tests/scmi-tests/-/commits/raw_mode_support_devel/
>
>
> Cristian Marussi (11):
> firmware: arm_scmi: Refactor xfer in-flight registration routines
> firmware: arm_scmi: Simplify chan_available transport operation
> firmware: arm_scmi: Use dedicated devices to initialize channels
> firmware: arm_scmi: Refactor polling helpers
> firmware: arm_scmi: Refactor scmi_wait_for_message_response
> firmware: arm_scmi: Add xfer raw helpers
> firmware: arm_scmi: Move errors defs and code to common.h
> firmware: arm_scmi: Add raw transmission support
> firmware: arm_scmi: Add debugfs ABI documentation for Raw mode
> firmware: arm_scmi: Reject SCMI drivers while in Raw mode
> firmware: arm_scmi: Call Raw mode hooks from the core stack
>
> Documentation/ABI/testing/debugfs-scmi-raw | 88 ++
> drivers/firmware/arm_scmi/Kconfig | 13 +
> drivers/firmware/arm_scmi/Makefile | 1 +
> drivers/firmware/arm_scmi/common.h | 72 +-
> drivers/firmware/arm_scmi/driver.c | 521 +++++---
> drivers/firmware/arm_scmi/mailbox.c | 4 +-
> drivers/firmware/arm_scmi/optee.c | 4 +-
> drivers/firmware/arm_scmi/raw_mode.c | 1244 ++++++++++++++++++++
> drivers/firmware/arm_scmi/raw_mode.h | 29 +
> drivers/firmware/arm_scmi/smc.c | 4 +-
> drivers/firmware/arm_scmi/virtio.c | 2 +-
> 11 files changed, 1827 insertions(+), 155 deletions(-)
> create mode 100644 Documentation/ABI/testing/debugfs-scmi-raw
> create mode 100644 drivers/firmware/arm_scmi/raw_mode.c
> create mode 100644 drivers/firmware/arm_scmi/raw_mode.h
>
> --
> 2.34.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
2022-10-19 20:46 ` Cristian Marussi
@ 2022-10-28 14:44 ` Florian Fainelli
-1 siblings, 0 replies; 50+ messages in thread
From: Florian Fainelli @ 2022-10-28 14:44 UTC (permalink / raw)
To: Cristian Marussi, linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, etienne.carriere,
vincent.guittot, souvik.chakravarty, wleavitt, peter.hilber,
nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan
Hi Christian,
On 10/19/2022 1:46 PM, Cristian Marussi wrote:
> Hi all,
>
> This series aims to introduce a new SCMI unified userspace interface meant
> to ease testing an SCMI Server implementation for compliance, fuzzing etc.,
> from the perspective of the OSPM agent (non-secure world only ...)
>
> It is proposed as a testing/development facility, it is NOT meant to be a
> feature to use in production, but only enabled in Kconfig for test
> deployments.
>
> Currently an SCMI Compliance Suite like the one at [1] can only work by
> injecting SCMI messages at the SCMI transport layer using the mailbox test
> driver (CONFIG_MAILBOX_TEST) via its few debugfs entries and looking at
> the related replies from the SCMI backend Server.
I plan on giving this a try on our systems later today and will let you
know the outcome. This is very useful for making sure the SCMI
implementation is both correct and properly hardened.
--
Florian
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
@ 2022-10-28 14:44 ` Florian Fainelli
0 siblings, 0 replies; 50+ messages in thread
From: Florian Fainelli @ 2022-10-28 14:44 UTC (permalink / raw)
To: Cristian Marussi, linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, etienne.carriere,
vincent.guittot, souvik.chakravarty, wleavitt, peter.hilber,
nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan
Hi Christian,
On 10/19/2022 1:46 PM, Cristian Marussi wrote:
> Hi all,
>
> This series aims to introduce a new SCMI unified userspace interface meant
> to ease testing an SCMI Server implementation for compliance, fuzzing etc.,
> from the perspective of the OSPM agent (non-secure world only ...)
>
> It is proposed as a testing/development facility, it is NOT meant to be a
> feature to use in production, but only enabled in Kconfig for test
> deployments.
>
> Currently an SCMI Compliance Suite like the one at [1] can only work by
> injecting SCMI messages at the SCMI transport layer using the mailbox test
> driver (CONFIG_MAILBOX_TEST) via its few debugfs entries and looking at
> the related replies from the SCMI backend Server.
I plan on giving this a try on our systems later today and will let you
know the outcome. This is very useful for making sure the SCMI
implementation is both correct and properly hardened.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
2022-10-28 14:40 ` Vincent Guittot
@ 2022-10-28 15:03 ` Cristian Marussi
-1 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-28 15:03 UTC (permalink / raw)
To: Vincent Guittot
Cc: linux-kernel, linux-arm-kernel, sudeep.holla, james.quinlan,
Jonathan.Cameron, f.fainelli, etienne.carriere,
souvik.chakravarty, wleavitt, peter.hilber, nicola.mazzucato,
tarek.el-sherbiny, quic_kshivnan
On Fri, Oct 28, 2022 at 04:40:02PM +0200, Vincent Guittot wrote:
> On Wed, 19 Oct 2022 at 22:46, Cristian Marussi <cristian.marussi@arm.com> wrote:
> >
> > Hi all,
> >
Hi Vincent,
> > This series aims to introduce a new SCMI unified userspace interface meant
> > to ease testing an SCMI Server implementation for compliance, fuzzing etc.,
> > from the perspective of the OSPM agent (non-secure world only ...)
> >
> > It is proposed as a testing/development facility, it is NOT meant to be a
> > feature to use in production, but only enabled in Kconfig for test
> > deployments.
> >
> > Currently an SCMI Compliance Suite like the one at [1] can only work by
> > injecting SCMI messages at the SCMI transport layer using the mailbox test
> > driver (CONFIG_MAILBOX_TEST) via its few debugfs entries and looking at
> > the related replies from the SCMI backend Server.
> >
> > This approach has a few drawbacks:
> >
> > - the SCMI Server under test MUST be reachable through a mailbox based
> > SCMI transport: any other SCMI Server placement is not possible (like in
> > a VM reachable via SCMI Virtio). In order to cover other placements in
> > the current scenario we should write some sort of test driver for each
> > and every existent SCMI transport and for any future additional transport
> > ...this clearly does not scale.
> >
> > - even in the mailbox case the userspace Compliance suite cannot simply
> > send and receive bare SCMI messages BUT it has to properly lay them out
> > into the shared memory exposed by the mailbox test driver as expected by
> > the transport definitions. In other words such a userspace test
> > application has to, not only use a proper transport driver for the system
> > at hand, but it also has to have a comprehensive knowledge of the
> > internals of the underlying transport in order to operate.
> >
> > - last but not least, the system under test has to be specifically
> > configured and built, in terms of Kconfig and DT, to perform such kind of
> > testing, it cannot be used for anything else, which is unfortunate for
> > CI/CD deployments.
> >
> > This series introduces a new SCMI Raw mode support feature that, when
> > configured and enabled exposes a new interface in debugfs through which:
> >
> > - a userspace application can inject bare SCMI binary messages into the
> > SCMI core stack; such messages will be routed by the SCMI regular kernel
> > stack to the backend Server using the currently configured transport
> > transparently: in other words you can test the SCMI server, no matter
> > where it is placed, as long as it is reachable from the currently
> > configured SCMI stack.
> > Same goes the other way around on the reading path: any SCMI server reply
> > can be read as a bare SCMI binary message from the same debugfs path.
> >
> > - as a direct consequence of this way of injecting bare messages in the
> > middle of the SCMI stack (instead of beneath it at the transport layer)
> > the user application has to handle only bare SCMI messages without having
> > to worry about the specific underlying transport internals that will be
> > taken care of by the SCMI core stack itself using its own machinery,
> > without duplicating such logic.
> >
> > - a system under test, once configured with SCMI Raw support enabled in
> > Kconfig, can be booted without any particular DT change.
> >
> > In V2 the runtime enable/disable switching capability has been removed
> > (for now) since still not deemed to be stable/reliable enough: as a
> > consequence when SCMI Raw support is compiled in, the regular SCMI stack
> > drivers are now inhibited permanently for that Kernel.
> >
> > In V4 it has been added the support for transports lacking a completion_irq
> > or configured forcibly in polled mode.
> >
> > A quick and trivial example from the shell...reading from a sensor
> > injecting a properly crafted packet in raw mode:
> >
> > # INJECT THE SENSOR_READING MESSAGE FOR SENSOR ID=1 (binary little endian)
> > root@deb-buster-arm64:~# echo -e -n \\x06\\x54\\x00\\x00\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x00 > /sys/kernel/debug/scmi_raw/message
> >
> > # READING BACK THE REPLY...
> > root@deb-buster-arm64:~# cat /sys/kernel/debug/scmi_raw/message | od --endian=little -t x4
> > 0000000 00005406 00000000 00000335 00000000
> > 0000020
> >
> > while doing that, since Raw mode makes (partial) use of the regular SCMI
> > stack, you can observe the messages going through the SCMI stack with the
> > usual traces:
> >
> > bash-329 [000] ..... 14183.446808: scmi_msg_dump: pt=15 t=CMND msg_id=06 seq=0000 s=0 pyld=0100000000000000
> > irq/35-mhu_db_l-81 [000] ..... 14183.447809: scmi_msg_dump: pt=15 t=RESP msg_id=06 seq=0000 s=0 pyld=3503000000000000
> >
> >
> > ..trying to read in async when the backend server does NOT supports asyncs:
> >
> > # AN ASYNC SENSOR READING REQUEST...
> > root@deb-buster-arm64:~# echo -e -n \\x06\\x54\\x00\\x00\\x01\\x00\\x00\\x00\\x01\\x00\\x00\\x00 > /sys/kernel/debug/scmi_raw/message_async
> >
> > bash-329 [000] ..... 16415.938739: scmi_msg_dump: pt=15 t=CMND msg_id=06 seq=0000 s=0 pyld=0100000001000000
> > irq/35-mhu_db_l-81 [000] ..... 16415.944129: scmi_msg_dump: pt=15 t=RESP msg_id=06 seq=0000 s=-1 pyld=
> >
> > # RETURNS A STATUS -1 FROM THE SERVER NOT SUPPORTING IT
> > root@deb-buster-arm64:~# cat /sys/kernel/debug/scmi_raw/message | od --endian=little -t x4
> > 0000000 00005406 ffffffff
> > 0000010
> >
> > Note that this was on a JUNO, BUT exactly the same steps can be used to
> > reach an SCMI Server living on a VM reachable via virtio as long as the
> > system under test if properly configured to work with a virtio transport.
> >
> > In a nutshell the exposed API is as follows:
> >
> > /sys/kernel/debug/scmi_raw/
> > ├── errors
> > ├── message
> > ├── message_async
> > ├── notification
> > ├── reset
> > ├── transport_max_msg_size
> > ├── transport_rx_timeout_ms
> > └── transport_tx_max_msg
> >
> > where:
> >
> > - message*: used to send sync/async commands and read back immediate and
> > delayed responses (if any)
> > - errors: used to report timeout and unexpected replies
> > - reset: used to reset the SCMI Raw stack, flushing all queues from
> > received messages still pending to be read out (useful to be sure to
> > cleanup between test suite runs...)
> > - notification: used to read any notification being spit by the system
> > (if previously enabled by the user app)
> > - transport*: a bunch of configuration useful to setup the user
> > application expectations in terms of timeouts and message
> > characteristics.
> >
> > Each write corresponds to one command request and the replies or delayed
> > response are read back one message at time (receiving an EOF at each
> > message boundary).
> >
> > The user application running the test is in charge of handling timeouts
> > and properly choosing SCMI sequence numbers for the outgoing requests: note
> > that the same fixed number can be re-used (...though discouraged...) as
> > long as the suite does NOT expect to send multiple in-flight commands
> > concurrently.
> >
> > Since the SCMI core regular stack is partially used to deliver and collect
> > the messages, late replies after timeouts and any other sort of unexpected
> > message sent by the SCMI server platform back can be identified by the SCMI
> > core as usual and it will be reported under /errors for later analysis.
> > (a userspace test-app will have anyway properly detected the timeout on
> > /message* ...)
> >
> > All of the above has been roughly tested against a standard JUNO SCP SCMI
> > Server (mailbox trans) and an emulated SCMI Server living in a VM (virtio
> > trans) using a custom experimental version of the scmi-tests Compliance
> > suite patched to support Raw mode and posted at [2]. (still in development
> > ...merge requests are in progress...for now it is just a mean for me to
> > test the testing API ... O_o)
> >
> > The series is based on v6.1-rc1.
> >
> > Having said that (in such a concise and brief way :P) ...
> >
> > ...any feedback/comments are welcome !
>
> Hi Cristian,
>
> I have tested your series with an optee message transport layer and
> been able to send raw messages to the scmi server PTA
>
> FWIW
>
> Tested-by: Vincent Guittot <vincent.guittot@linaro.org>
>
Thanks a lot for your test and feedback !
... but I was going to reply to this saying that I spotted another issue
with the current SCMI Raw implementation (NOT related to optee/smc) so
that I'll post a V5 next week :P
Anyway, the issue is much related to the debugfs root used by SCMI Raw,
i.e.:
/sys/kernel/debug/scmi_raw/
..this works fine unless you run it on a system sporting multiple DT-defined
server instances ...that is not officially supported but....ehm...a little
bird told these system with multiple servers do exists :D
In such a case the SCMI core stack is probed multiuple times and so it
will try to register multiple debugfs Raw roots: there is no chanche to
root the SCMI Raw entries at the same point clearly ... and then anyway
there is the issue of recognizing which server is rooted where ... with
the additional pain that a server CANNOT be recognized by querying...cause
there is only one by teh spec with agentID ZERO ... in theory :D...
So my tentaive solution for V5 would be:
- change the Raw root debugfs as:
/sys/kernel/debug/scmi_raw/0/... (first server defined)
/sys/kernel/debug/scmi_raw/1/... (possible additional server(s)..)
- expose the DT scmi-server root-node name of the server somewhere under
that debugfs root like:
..../scmi_raw/0/transport_name -> 'scmi-mbx'
..../scmi_raw/1/transport_name -> 'scmi-virtio'
so that if you know HOW you have configured your own system in the DT
(maybe multiple servers with different kind of transports ?), you can
easily select programmatically which one is which, and so decide
which Raw debugfs fs to use...
... I plan to leave the SCMI ACS suite use by default the first system
rooted at /sys/kernel/debug/scmi_raw/0/...maybe adding a commandline
option to choose an alternative path for SCMI Raw.
Does all of this sound reasonable ?
Thanks,
Cristian
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
@ 2022-10-28 15:03 ` Cristian Marussi
0 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-28 15:03 UTC (permalink / raw)
To: Vincent Guittot
Cc: linux-kernel, linux-arm-kernel, sudeep.holla, james.quinlan,
Jonathan.Cameron, f.fainelli, etienne.carriere,
souvik.chakravarty, wleavitt, peter.hilber, nicola.mazzucato,
tarek.el-sherbiny, quic_kshivnan
On Fri, Oct 28, 2022 at 04:40:02PM +0200, Vincent Guittot wrote:
> On Wed, 19 Oct 2022 at 22:46, Cristian Marussi <cristian.marussi@arm.com> wrote:
> >
> > Hi all,
> >
Hi Vincent,
> > This series aims to introduce a new SCMI unified userspace interface meant
> > to ease testing an SCMI Server implementation for compliance, fuzzing etc.,
> > from the perspective of the OSPM agent (non-secure world only ...)
> >
> > It is proposed as a testing/development facility, it is NOT meant to be a
> > feature to use in production, but only enabled in Kconfig for test
> > deployments.
> >
> > Currently an SCMI Compliance Suite like the one at [1] can only work by
> > injecting SCMI messages at the SCMI transport layer using the mailbox test
> > driver (CONFIG_MAILBOX_TEST) via its few debugfs entries and looking at
> > the related replies from the SCMI backend Server.
> >
> > This approach has a few drawbacks:
> >
> > - the SCMI Server under test MUST be reachable through a mailbox based
> > SCMI transport: any other SCMI Server placement is not possible (like in
> > a VM reachable via SCMI Virtio). In order to cover other placements in
> > the current scenario we should write some sort of test driver for each
> > and every existent SCMI transport and for any future additional transport
> > ...this clearly does not scale.
> >
> > - even in the mailbox case the userspace Compliance suite cannot simply
> > send and receive bare SCMI messages BUT it has to properly lay them out
> > into the shared memory exposed by the mailbox test driver as expected by
> > the transport definitions. In other words such a userspace test
> > application has to, not only use a proper transport driver for the system
> > at hand, but it also has to have a comprehensive knowledge of the
> > internals of the underlying transport in order to operate.
> >
> > - last but not least, the system under test has to be specifically
> > configured and built, in terms of Kconfig and DT, to perform such kind of
> > testing, it cannot be used for anything else, which is unfortunate for
> > CI/CD deployments.
> >
> > This series introduces a new SCMI Raw mode support feature that, when
> > configured and enabled exposes a new interface in debugfs through which:
> >
> > - a userspace application can inject bare SCMI binary messages into the
> > SCMI core stack; such messages will be routed by the SCMI regular kernel
> > stack to the backend Server using the currently configured transport
> > transparently: in other words you can test the SCMI server, no matter
> > where it is placed, as long as it is reachable from the currently
> > configured SCMI stack.
> > Same goes the other way around on the reading path: any SCMI server reply
> > can be read as a bare SCMI binary message from the same debugfs path.
> >
> > - as a direct consequence of this way of injecting bare messages in the
> > middle of the SCMI stack (instead of beneath it at the transport layer)
> > the user application has to handle only bare SCMI messages without having
> > to worry about the specific underlying transport internals that will be
> > taken care of by the SCMI core stack itself using its own machinery,
> > without duplicating such logic.
> >
> > - a system under test, once configured with SCMI Raw support enabled in
> > Kconfig, can be booted without any particular DT change.
> >
> > In V2 the runtime enable/disable switching capability has been removed
> > (for now) since still not deemed to be stable/reliable enough: as a
> > consequence when SCMI Raw support is compiled in, the regular SCMI stack
> > drivers are now inhibited permanently for that Kernel.
> >
> > In V4 it has been added the support for transports lacking a completion_irq
> > or configured forcibly in polled mode.
> >
> > A quick and trivial example from the shell...reading from a sensor
> > injecting a properly crafted packet in raw mode:
> >
> > # INJECT THE SENSOR_READING MESSAGE FOR SENSOR ID=1 (binary little endian)
> > root@deb-buster-arm64:~# echo -e -n \\x06\\x54\\x00\\x00\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x00 > /sys/kernel/debug/scmi_raw/message
> >
> > # READING BACK THE REPLY...
> > root@deb-buster-arm64:~# cat /sys/kernel/debug/scmi_raw/message | od --endian=little -t x4
> > 0000000 00005406 00000000 00000335 00000000
> > 0000020
> >
> > while doing that, since Raw mode makes (partial) use of the regular SCMI
> > stack, you can observe the messages going through the SCMI stack with the
> > usual traces:
> >
> > bash-329 [000] ..... 14183.446808: scmi_msg_dump: pt=15 t=CMND msg_id=06 seq=0000 s=0 pyld=0100000000000000
> > irq/35-mhu_db_l-81 [000] ..... 14183.447809: scmi_msg_dump: pt=15 t=RESP msg_id=06 seq=0000 s=0 pyld=3503000000000000
> >
> >
> > ..trying to read in async when the backend server does NOT supports asyncs:
> >
> > # AN ASYNC SENSOR READING REQUEST...
> > root@deb-buster-arm64:~# echo -e -n \\x06\\x54\\x00\\x00\\x01\\x00\\x00\\x00\\x01\\x00\\x00\\x00 > /sys/kernel/debug/scmi_raw/message_async
> >
> > bash-329 [000] ..... 16415.938739: scmi_msg_dump: pt=15 t=CMND msg_id=06 seq=0000 s=0 pyld=0100000001000000
> > irq/35-mhu_db_l-81 [000] ..... 16415.944129: scmi_msg_dump: pt=15 t=RESP msg_id=06 seq=0000 s=-1 pyld=
> >
> > # RETURNS A STATUS -1 FROM THE SERVER NOT SUPPORTING IT
> > root@deb-buster-arm64:~# cat /sys/kernel/debug/scmi_raw/message | od --endian=little -t x4
> > 0000000 00005406 ffffffff
> > 0000010
> >
> > Note that this was on a JUNO, BUT exactly the same steps can be used to
> > reach an SCMI Server living on a VM reachable via virtio as long as the
> > system under test if properly configured to work with a virtio transport.
> >
> > In a nutshell the exposed API is as follows:
> >
> > /sys/kernel/debug/scmi_raw/
> > ├── errors
> > ├── message
> > ├── message_async
> > ├── notification
> > ├── reset
> > ├── transport_max_msg_size
> > ├── transport_rx_timeout_ms
> > └── transport_tx_max_msg
> >
> > where:
> >
> > - message*: used to send sync/async commands and read back immediate and
> > delayed responses (if any)
> > - errors: used to report timeout and unexpected replies
> > - reset: used to reset the SCMI Raw stack, flushing all queues from
> > received messages still pending to be read out (useful to be sure to
> > cleanup between test suite runs...)
> > - notification: used to read any notification being spit by the system
> > (if previously enabled by the user app)
> > - transport*: a bunch of configuration useful to setup the user
> > application expectations in terms of timeouts and message
> > characteristics.
> >
> > Each write corresponds to one command request and the replies or delayed
> > response are read back one message at time (receiving an EOF at each
> > message boundary).
> >
> > The user application running the test is in charge of handling timeouts
> > and properly choosing SCMI sequence numbers for the outgoing requests: note
> > that the same fixed number can be re-used (...though discouraged...) as
> > long as the suite does NOT expect to send multiple in-flight commands
> > concurrently.
> >
> > Since the SCMI core regular stack is partially used to deliver and collect
> > the messages, late replies after timeouts and any other sort of unexpected
> > message sent by the SCMI server platform back can be identified by the SCMI
> > core as usual and it will be reported under /errors for later analysis.
> > (a userspace test-app will have anyway properly detected the timeout on
> > /message* ...)
> >
> > All of the above has been roughly tested against a standard JUNO SCP SCMI
> > Server (mailbox trans) and an emulated SCMI Server living in a VM (virtio
> > trans) using a custom experimental version of the scmi-tests Compliance
> > suite patched to support Raw mode and posted at [2]. (still in development
> > ...merge requests are in progress...for now it is just a mean for me to
> > test the testing API ... O_o)
> >
> > The series is based on v6.1-rc1.
> >
> > Having said that (in such a concise and brief way :P) ...
> >
> > ...any feedback/comments are welcome !
>
> Hi Cristian,
>
> I have tested your series with an optee message transport layer and
> been able to send raw messages to the scmi server PTA
>
> FWIW
>
> Tested-by: Vincent Guittot <vincent.guittot@linaro.org>
>
Thanks a lot for your test and feedback !
... but I was going to reply to this saying that I spotted another issue
with the current SCMI Raw implementation (NOT related to optee/smc) so
that I'll post a V5 next week :P
Anyway, the issue is much related to the debugfs root used by SCMI Raw,
i.e.:
/sys/kernel/debug/scmi_raw/
..this works fine unless you run it on a system sporting multiple DT-defined
server instances ...that is not officially supported but....ehm...a little
bird told these system with multiple servers do exists :D
In such a case the SCMI core stack is probed multiuple times and so it
will try to register multiple debugfs Raw roots: there is no chanche to
root the SCMI Raw entries at the same point clearly ... and then anyway
there is the issue of recognizing which server is rooted where ... with
the additional pain that a server CANNOT be recognized by querying...cause
there is only one by teh spec with agentID ZERO ... in theory :D...
So my tentaive solution for V5 would be:
- change the Raw root debugfs as:
/sys/kernel/debug/scmi_raw/0/... (first server defined)
/sys/kernel/debug/scmi_raw/1/... (possible additional server(s)..)
- expose the DT scmi-server root-node name of the server somewhere under
that debugfs root like:
..../scmi_raw/0/transport_name -> 'scmi-mbx'
..../scmi_raw/1/transport_name -> 'scmi-virtio'
so that if you know HOW you have configured your own system in the DT
(maybe multiple servers with different kind of transports ?), you can
easily select programmatically which one is which, and so decide
which Raw debugfs fs to use...
... I plan to leave the SCMI ACS suite use by default the first system
rooted at /sys/kernel/debug/scmi_raw/0/...maybe adding a commandline
option to choose an alternative path for SCMI Raw.
Does all of this sound reasonable ?
Thanks,
Cristian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
2022-10-28 14:44 ` Florian Fainelli
@ 2022-10-28 15:23 ` Cristian Marussi
-1 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-28 15:23 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-kernel, linux-arm-kernel, sudeep.holla, james.quinlan,
Jonathan.Cameron, etienne.carriere, vincent.guittot,
souvik.chakravarty, wleavitt, peter.hilber, nicola.mazzucato,
tarek.el-sherbiny, quic_kshivnan
On Fri, Oct 28, 2022 at 07:44:32AM -0700, Florian Fainelli wrote:
> Hi Christian,
>
> On 10/19/2022 1:46 PM, Cristian Marussi wrote:
> > Hi all,
> >
Hi Florian,
> > This series aims to introduce a new SCMI unified userspace interface meant
> > to ease testing an SCMI Server implementation for compliance, fuzzing etc.,
> > from the perspective of the OSPM agent (non-secure world only ...)
> >
> > It is proposed as a testing/development facility, it is NOT meant to be a
> > feature to use in production, but only enabled in Kconfig for test
> > deployments.
> >
> > Currently an SCMI Compliance Suite like the one at [1] can only work by
> > injecting SCMI messages at the SCMI transport layer using the mailbox test
> > driver (CONFIG_MAILBOX_TEST) via its few debugfs entries and looking at
> > the related replies from the SCMI backend Server.
>
> I plan on giving this a try on our systems later today and will let you know
> the outcome.
Great ! It would be much appreciated...
> This is very useful for making sure the SCMI implementation is
> both correct and properly hardened.
... that was the plan :P
Note that the upstream SCMI ACS suite that I am using for stressing/testing
this Raw thing is still WIP in term of supporting Raw mode injection
(i.e. functional but ALL still to be merged)..but if you need I can give
you pointers on how to use it....unless of course you have your suite or
you just want to test using the shell as in the cover-letter examples...
... on my side I tried to fuzz me with a brutal
'dd bs=128 count=1 if=/dev/random of=<scmi_raw>/message'
as a poor man fuzzying tool :D ... so I was thinking if it was meaningful
to think about upstreaming some common tools for fuzzying or simply
pre-building bare payloads (in proper endianity) to be injected with this
SCMI raw thing... (I mean something useful that could live in tools/)
...any feedbacks/hints in these regards are welcome.
Thanks,
Cristian
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
@ 2022-10-28 15:23 ` Cristian Marussi
0 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-28 15:23 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-kernel, linux-arm-kernel, sudeep.holla, james.quinlan,
Jonathan.Cameron, etienne.carriere, vincent.guittot,
souvik.chakravarty, wleavitt, peter.hilber, nicola.mazzucato,
tarek.el-sherbiny, quic_kshivnan
On Fri, Oct 28, 2022 at 07:44:32AM -0700, Florian Fainelli wrote:
> Hi Christian,
>
> On 10/19/2022 1:46 PM, Cristian Marussi wrote:
> > Hi all,
> >
Hi Florian,
> > This series aims to introduce a new SCMI unified userspace interface meant
> > to ease testing an SCMI Server implementation for compliance, fuzzing etc.,
> > from the perspective of the OSPM agent (non-secure world only ...)
> >
> > It is proposed as a testing/development facility, it is NOT meant to be a
> > feature to use in production, but only enabled in Kconfig for test
> > deployments.
> >
> > Currently an SCMI Compliance Suite like the one at [1] can only work by
> > injecting SCMI messages at the SCMI transport layer using the mailbox test
> > driver (CONFIG_MAILBOX_TEST) via its few debugfs entries and looking at
> > the related replies from the SCMI backend Server.
>
> I plan on giving this a try on our systems later today and will let you know
> the outcome.
Great ! It would be much appreciated...
> This is very useful for making sure the SCMI implementation is
> both correct and properly hardened.
... that was the plan :P
Note that the upstream SCMI ACS suite that I am using for stressing/testing
this Raw thing is still WIP in term of supporting Raw mode injection
(i.e. functional but ALL still to be merged)..but if you need I can give
you pointers on how to use it....unless of course you have your suite or
you just want to test using the shell as in the cover-letter examples...
... on my side I tried to fuzz me with a brutal
'dd bs=128 count=1 if=/dev/random of=<scmi_raw>/message'
as a poor man fuzzying tool :D ... so I was thinking if it was meaningful
to think about upstreaming some common tools for fuzzying or simply
pre-building bare payloads (in proper endianity) to be injected with this
SCMI raw thing... (I mean something useful that could live in tools/)
...any feedbacks/hints in these regards are welcome.
Thanks,
Cristian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
2022-10-28 15:03 ` Cristian Marussi
@ 2022-10-28 16:18 ` Vincent Guittot
-1 siblings, 0 replies; 50+ messages in thread
From: Vincent Guittot @ 2022-10-28 16:18 UTC (permalink / raw)
To: Cristian Marussi
Cc: linux-kernel, linux-arm-kernel, sudeep.holla, james.quinlan,
Jonathan.Cameron, f.fainelli, etienne.carriere,
souvik.chakravarty, wleavitt, peter.hilber, nicola.mazzucato,
tarek.el-sherbiny, quic_kshivnan
On Fri, 28 Oct 2022 at 17:04, Cristian Marussi <cristian.marussi@arm.com> wrote:
>
> On Fri, Oct 28, 2022 at 04:40:02PM +0200, Vincent Guittot wrote:
> > On Wed, 19 Oct 2022 at 22:46, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > >
> > > Hi all,
> > >
>
> Hi Vincent,
>
> > > This series aims to introduce a new SCMI unified userspace interface meant
> > > to ease testing an SCMI Server implementation for compliance, fuzzing etc.,
> > > from the perspective of the OSPM agent (non-secure world only ...)
> > >
[ snip]
> > Hi Cristian,
> >
> > I have tested your series with an optee message transport layer and
> > been able to send raw messages to the scmi server PTA
> >
> > FWIW
> >
> > Tested-by: Vincent Guittot <vincent.guittot@linaro.org>
> >
>
> Thanks a lot for your test and feedback !
>
> ... but I was going to reply to this saying that I spotted another issue
> with the current SCMI Raw implementation (NOT related to optee/smc) so
> that I'll post a V5 next week :P
>
> Anyway, the issue is much related to the debugfs root used by SCMI Raw,
> i.e.:
>
> /sys/kernel/debug/scmi_raw/
>
> ..this works fine unless you run it on a system sporting multiple DT-defined
> server instances ...that is not officially supported but....ehm...a little
> bird told these system with multiple servers do exists :D
;-)
>
> In such a case the SCMI core stack is probed multiuple times and so it
> will try to register multiple debugfs Raw roots: there is no chanche to
> root the SCMI Raw entries at the same point clearly ... and then anyway
> there is the issue of recognizing which server is rooted where ... with
> the additional pain that a server CANNOT be recognized by querying...cause
> there is only one by teh spec with agentID ZERO ... in theory :D...
>
> So my tentaive solution for V5 would be:
>
> - change the Raw root debugfs as:
>
> /sys/kernel/debug/scmi_raw/0/... (first server defined)
>
> /sys/kernel/debug/scmi_raw/1/... (possible additional server(s)..)
>
> - expose the DT scmi-server root-node name of the server somewhere under
> that debugfs root like:
>
> ..../scmi_raw/0/transport_name -> 'scmi-mbx'
>
> ..../scmi_raw/1/transport_name -> 'scmi-virtio'
I was about to say that you would display the server name but that
means that you have send a request to the server which probably
defeats the purpose of the raw mode
>
> so that if you know HOW you have configured your own system in the DT
> (maybe multiple servers with different kind of transports ?), you can
> easily select programmatically which one is which, and so decide
> which Raw debugfs fs to use...
>
> ... I plan to leave the SCMI ACS suite use by default the first system
> rooted at /sys/kernel/debug/scmi_raw/0/...maybe adding a commandline
> option to choose an alternative path for SCMI Raw.
>
> Does all of this sound reasonable ?
Yes, adding an index looks good to me.
As we are there, should we consider adding a per channel entry in the
tree when there are several channels shared with the same server ?
Vincent
>
> Thanks,
> Cristian
>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
@ 2022-10-28 16:18 ` Vincent Guittot
0 siblings, 0 replies; 50+ messages in thread
From: Vincent Guittot @ 2022-10-28 16:18 UTC (permalink / raw)
To: Cristian Marussi
Cc: linux-kernel, linux-arm-kernel, sudeep.holla, james.quinlan,
Jonathan.Cameron, f.fainelli, etienne.carriere,
souvik.chakravarty, wleavitt, peter.hilber, nicola.mazzucato,
tarek.el-sherbiny, quic_kshivnan
On Fri, 28 Oct 2022 at 17:04, Cristian Marussi <cristian.marussi@arm.com> wrote:
>
> On Fri, Oct 28, 2022 at 04:40:02PM +0200, Vincent Guittot wrote:
> > On Wed, 19 Oct 2022 at 22:46, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > >
> > > Hi all,
> > >
>
> Hi Vincent,
>
> > > This series aims to introduce a new SCMI unified userspace interface meant
> > > to ease testing an SCMI Server implementation for compliance, fuzzing etc.,
> > > from the perspective of the OSPM agent (non-secure world only ...)
> > >
[ snip]
> > Hi Cristian,
> >
> > I have tested your series with an optee message transport layer and
> > been able to send raw messages to the scmi server PTA
> >
> > FWIW
> >
> > Tested-by: Vincent Guittot <vincent.guittot@linaro.org>
> >
>
> Thanks a lot for your test and feedback !
>
> ... but I was going to reply to this saying that I spotted another issue
> with the current SCMI Raw implementation (NOT related to optee/smc) so
> that I'll post a V5 next week :P
>
> Anyway, the issue is much related to the debugfs root used by SCMI Raw,
> i.e.:
>
> /sys/kernel/debug/scmi_raw/
>
> ..this works fine unless you run it on a system sporting multiple DT-defined
> server instances ...that is not officially supported but....ehm...a little
> bird told these system with multiple servers do exists :D
;-)
>
> In such a case the SCMI core stack is probed multiuple times and so it
> will try to register multiple debugfs Raw roots: there is no chanche to
> root the SCMI Raw entries at the same point clearly ... and then anyway
> there is the issue of recognizing which server is rooted where ... with
> the additional pain that a server CANNOT be recognized by querying...cause
> there is only one by teh spec with agentID ZERO ... in theory :D...
>
> So my tentaive solution for V5 would be:
>
> - change the Raw root debugfs as:
>
> /sys/kernel/debug/scmi_raw/0/... (first server defined)
>
> /sys/kernel/debug/scmi_raw/1/... (possible additional server(s)..)
>
> - expose the DT scmi-server root-node name of the server somewhere under
> that debugfs root like:
>
> ..../scmi_raw/0/transport_name -> 'scmi-mbx'
>
> ..../scmi_raw/1/transport_name -> 'scmi-virtio'
I was about to say that you would display the server name but that
means that you have send a request to the server which probably
defeats the purpose of the raw mode
>
> so that if you know HOW you have configured your own system in the DT
> (maybe multiple servers with different kind of transports ?), you can
> easily select programmatically which one is which, and so decide
> which Raw debugfs fs to use...
>
> ... I plan to leave the SCMI ACS suite use by default the first system
> rooted at /sys/kernel/debug/scmi_raw/0/...maybe adding a commandline
> option to choose an alternative path for SCMI Raw.
>
> Does all of this sound reasonable ?
Yes, adding an index looks good to me.
As we are there, should we consider adding a per channel entry in the
tree when there are several channels shared with the same server ?
Vincent
>
> Thanks,
> Cristian
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
2022-10-28 16:18 ` Vincent Guittot
@ 2022-10-28 16:58 ` Cristian Marussi
-1 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-28 16:58 UTC (permalink / raw)
To: Vincent Guittot
Cc: linux-kernel, linux-arm-kernel, sudeep.holla, james.quinlan,
Jonathan.Cameron, f.fainelli, etienne.carriere,
souvik.chakravarty, wleavitt, peter.hilber, nicola.mazzucato,
tarek.el-sherbiny, quic_kshivnan
On Fri, Oct 28, 2022 at 06:18:52PM +0200, Vincent Guittot wrote:
> On Fri, 28 Oct 2022 at 17:04, Cristian Marussi <cristian.marussi@arm.com> wrote:
> >
> > On Fri, Oct 28, 2022 at 04:40:02PM +0200, Vincent Guittot wrote:
> > > On Wed, 19 Oct 2022 at 22:46, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > > >
> > > > Hi all,
> > > >
> >
> > Hi Vincent,
> >
> > > > This series aims to introduce a new SCMI unified userspace interface meant
> > > > to ease testing an SCMI Server implementation for compliance, fuzzing etc.,
> > > > from the perspective of the OSPM agent (non-secure world only ...)
> > > >
>
> [ snip]
>
> > > Hi Cristian,
> > >
> > > I have tested your series with an optee message transport layer and
> > > been able to send raw messages to the scmi server PTA
> > >
> > > FWIW
> > >
> > > Tested-by: Vincent Guittot <vincent.guittot@linaro.org>
> > >
> >
> > Thanks a lot for your test and feedback !
> >
> > ... but I was going to reply to this saying that I spotted another issue
> > with the current SCMI Raw implementation (NOT related to optee/smc) so
> > that I'll post a V5 next week :P
> >
> > Anyway, the issue is much related to the debugfs root used by SCMI Raw,
> > i.e.:
> >
> > /sys/kernel/debug/scmi_raw/
> >
> > ..this works fine unless you run it on a system sporting multiple DT-defined
> > server instances ...that is not officially supported but....ehm...a little
> > bird told these system with multiple servers do exists :D
>
> ;-)
>
> >
> > In such a case the SCMI core stack is probed multiuple times and so it
> > will try to register multiple debugfs Raw roots: there is no chanche to
> > root the SCMI Raw entries at the same point clearly ... and then anyway
> > there is the issue of recognizing which server is rooted where ... with
> > the additional pain that a server CANNOT be recognized by querying...cause
> > there is only one by teh spec with agentID ZERO ... in theory :D...
> >
> > So my tentaive solution for V5 would be:
> >
> > - change the Raw root debugfs as:
> >
> > /sys/kernel/debug/scmi_raw/0/... (first server defined)
> >
> > /sys/kernel/debug/scmi_raw/1/... (possible additional server(s)..)
> >
> > - expose the DT scmi-server root-node name of the server somewhere under
> > that debugfs root like:
> >
> > ..../scmi_raw/0/transport_name -> 'scmi-mbx'
> >
> > ..../scmi_raw/1/transport_name -> 'scmi-virtio'
>
> I was about to say that you would display the server name but that
> means that you have send a request to the server which probably
> defeats the purpose of the raw mode
>
> >
> > so that if you know HOW you have configured your own system in the DT
> > (maybe multiple servers with different kind of transports ?), you can
> > easily select programmatically which one is which, and so decide
> > which Raw debugfs fs to use...
> >
> > ... I plan to leave the SCMI ACS suite use by default the first system
> > rooted at /sys/kernel/debug/scmi_raw/0/...maybe adding a commandline
> > option to choose an alternative path for SCMI Raw.
> >
> > Does all of this sound reasonable ?
>
> Yes, adding an index looks good to me.
Ok, I'll rework accordingly.
>
> As we are there, should we consider adding a per channel entry in the
> tree when there are several channels shared with the same server ?
>
So, I was thinking about this and, even though, it seems not strictly
needed for Compliance testing (as discussed offline) I do think that
could be a sensible option to have as an additional mean to stress the
server transport implementation (as you wish).
Having said that, this week, I was reasoning about an alternative
interface to do this, i.e. to avoid to add even more debugfs entries
for this chosen-channel config or possibly in the future to ask for
transport polling mode (if supported by the underlying transport)
My idea (not thought fully through as of now eh..) would be as follows:
since the current Raw implementation enforces a minimum size of 4 bytes
for the injected message (more on this later down below in NOTE), I was
thinking about using less-than-4-bytes-sized messages to sort of
pre-configure the Raw stack.
IOW, instead of having a number of new additional entries like
../message_ch10
../message_ch13
../message_poll
we could design a sort of API (in the API :D) that defines how
3-bytes message payload are to be interpreted, so that in normal usage
everything will go on as it is now, while if a 3-bytes message is
injected by a specially crafted testcase, it would be used to configure
the behaviour stack for the subsequent set of Raw transactions
(i.e. for the currently opened fd...) like:
- open message fd
- send a configure message:
| proto_chan_# | flags (polling..) |
------------------------------------------
0 7 21
- send/receive your test messages
- repeat or close (then the config will vanish...)
This would mean adding some sort entry under scmi_raw to expose the
configured available channels on the system though.
[maybe the flags above could also include an async flag and avoid
also to add the message_async entries...]
I discarded the idea to run the above config process via IOCTLs since
it seemed to me even more frowned upon to use IOCTLs on a debugfs entry
:P...but I maybe wrong ah...
All of this is still to be explored anyway, any thoughts ? or evident
drawbacks ? (beside having to clearly define an API for these message
config machinery)
Anyway, whatever direction we'll choose (additional entries vs 3-bytes
config msg), I would prefer to add this per-channel (or polling)
capabilities with separate series to post on top of this in teh next
cycle.
..too many words even this time :P
Thanks,
Cristian
P.S: NOTE min_injected_msg_size:
--------------------------------
Thinking about all of the above, at first, I was a bit dubious if
instead I should not allow, in Raw mode, the injection of shorter than
4 bytes messages (i.e. shorter than a SCMI header) for the purpose of
fuzzing: then I realized that even though I should allow the injection
of smaller messages, the underlying transports, as they are defined, both
sides (platform and agent) will anyway carry out a 4bytes transaction,
it's just that all the other non-provided bytes will be zeroed in the
memory layout; this is just how the transports itself (shmem or msg
based) are designed to work both sides. (and again would be transport
layer testing more than SCMI spec verification..)
So at the end I thought this kind of less-than-4-bytes transmissions
gave no benefit and I came up with the above trick to use such tiny
message for configuration.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
@ 2022-10-28 16:58 ` Cristian Marussi
0 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-28 16:58 UTC (permalink / raw)
To: Vincent Guittot
Cc: linux-kernel, linux-arm-kernel, sudeep.holla, james.quinlan,
Jonathan.Cameron, f.fainelli, etienne.carriere,
souvik.chakravarty, wleavitt, peter.hilber, nicola.mazzucato,
tarek.el-sherbiny, quic_kshivnan
On Fri, Oct 28, 2022 at 06:18:52PM +0200, Vincent Guittot wrote:
> On Fri, 28 Oct 2022 at 17:04, Cristian Marussi <cristian.marussi@arm.com> wrote:
> >
> > On Fri, Oct 28, 2022 at 04:40:02PM +0200, Vincent Guittot wrote:
> > > On Wed, 19 Oct 2022 at 22:46, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > > >
> > > > Hi all,
> > > >
> >
> > Hi Vincent,
> >
> > > > This series aims to introduce a new SCMI unified userspace interface meant
> > > > to ease testing an SCMI Server implementation for compliance, fuzzing etc.,
> > > > from the perspective of the OSPM agent (non-secure world only ...)
> > > >
>
> [ snip]
>
> > > Hi Cristian,
> > >
> > > I have tested your series with an optee message transport layer and
> > > been able to send raw messages to the scmi server PTA
> > >
> > > FWIW
> > >
> > > Tested-by: Vincent Guittot <vincent.guittot@linaro.org>
> > >
> >
> > Thanks a lot for your test and feedback !
> >
> > ... but I was going to reply to this saying that I spotted another issue
> > with the current SCMI Raw implementation (NOT related to optee/smc) so
> > that I'll post a V5 next week :P
> >
> > Anyway, the issue is much related to the debugfs root used by SCMI Raw,
> > i.e.:
> >
> > /sys/kernel/debug/scmi_raw/
> >
> > ..this works fine unless you run it on a system sporting multiple DT-defined
> > server instances ...that is not officially supported but....ehm...a little
> > bird told these system with multiple servers do exists :D
>
> ;-)
>
> >
> > In such a case the SCMI core stack is probed multiuple times and so it
> > will try to register multiple debugfs Raw roots: there is no chanche to
> > root the SCMI Raw entries at the same point clearly ... and then anyway
> > there is the issue of recognizing which server is rooted where ... with
> > the additional pain that a server CANNOT be recognized by querying...cause
> > there is only one by teh spec with agentID ZERO ... in theory :D...
> >
> > So my tentaive solution for V5 would be:
> >
> > - change the Raw root debugfs as:
> >
> > /sys/kernel/debug/scmi_raw/0/... (first server defined)
> >
> > /sys/kernel/debug/scmi_raw/1/... (possible additional server(s)..)
> >
> > - expose the DT scmi-server root-node name of the server somewhere under
> > that debugfs root like:
> >
> > ..../scmi_raw/0/transport_name -> 'scmi-mbx'
> >
> > ..../scmi_raw/1/transport_name -> 'scmi-virtio'
>
> I was about to say that you would display the server name but that
> means that you have send a request to the server which probably
> defeats the purpose of the raw mode
>
> >
> > so that if you know HOW you have configured your own system in the DT
> > (maybe multiple servers with different kind of transports ?), you can
> > easily select programmatically which one is which, and so decide
> > which Raw debugfs fs to use...
> >
> > ... I plan to leave the SCMI ACS suite use by default the first system
> > rooted at /sys/kernel/debug/scmi_raw/0/...maybe adding a commandline
> > option to choose an alternative path for SCMI Raw.
> >
> > Does all of this sound reasonable ?
>
> Yes, adding an index looks good to me.
Ok, I'll rework accordingly.
>
> As we are there, should we consider adding a per channel entry in the
> tree when there are several channels shared with the same server ?
>
So, I was thinking about this and, even though, it seems not strictly
needed for Compliance testing (as discussed offline) I do think that
could be a sensible option to have as an additional mean to stress the
server transport implementation (as you wish).
Having said that, this week, I was reasoning about an alternative
interface to do this, i.e. to avoid to add even more debugfs entries
for this chosen-channel config or possibly in the future to ask for
transport polling mode (if supported by the underlying transport)
My idea (not thought fully through as of now eh..) would be as follows:
since the current Raw implementation enforces a minimum size of 4 bytes
for the injected message (more on this later down below in NOTE), I was
thinking about using less-than-4-bytes-sized messages to sort of
pre-configure the Raw stack.
IOW, instead of having a number of new additional entries like
../message_ch10
../message_ch13
../message_poll
we could design a sort of API (in the API :D) that defines how
3-bytes message payload are to be interpreted, so that in normal usage
everything will go on as it is now, while if a 3-bytes message is
injected by a specially crafted testcase, it would be used to configure
the behaviour stack for the subsequent set of Raw transactions
(i.e. for the currently opened fd...) like:
- open message fd
- send a configure message:
| proto_chan_# | flags (polling..) |
------------------------------------------
0 7 21
- send/receive your test messages
- repeat or close (then the config will vanish...)
This would mean adding some sort entry under scmi_raw to expose the
configured available channels on the system though.
[maybe the flags above could also include an async flag and avoid
also to add the message_async entries...]
I discarded the idea to run the above config process via IOCTLs since
it seemed to me even more frowned upon to use IOCTLs on a debugfs entry
:P...but I maybe wrong ah...
All of this is still to be explored anyway, any thoughts ? or evident
drawbacks ? (beside having to clearly define an API for these message
config machinery)
Anyway, whatever direction we'll choose (additional entries vs 3-bytes
config msg), I would prefer to add this per-channel (or polling)
capabilities with separate series to post on top of this in teh next
cycle.
..too many words even this time :P
Thanks,
Cristian
P.S: NOTE min_injected_msg_size:
--------------------------------
Thinking about all of the above, at first, I was a bit dubious if
instead I should not allow, in Raw mode, the injection of shorter than
4 bytes messages (i.e. shorter than a SCMI header) for the purpose of
fuzzing: then I realized that even though I should allow the injection
of smaller messages, the underlying transports, as they are defined, both
sides (platform and agent) will anyway carry out a 4bytes transaction,
it's just that all the other non-provided bytes will be zeroed in the
memory layout; this is just how the transports itself (shmem or msg
based) are designed to work both sides. (and again would be transport
layer testing more than SCMI spec verification..)
So at the end I thought this kind of less-than-4-bytes transmissions
gave no benefit and I came up with the above trick to use such tiny
message for configuration.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
2022-10-19 20:46 ` Cristian Marussi
@ 2022-10-29 2:38 ` Florian Fainelli
-1 siblings, 0 replies; 50+ messages in thread
From: Florian Fainelli @ 2022-10-29 2:38 UTC (permalink / raw)
To: Cristian Marussi, linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, etienne.carriere,
vincent.guittot, souvik.chakravarty, wleavitt, peter.hilber,
nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan
Hi Christian,
On 10/19/2022 1:46 PM, Cristian Marussi wrote:
[snip]
> In V2 the runtime enable/disable switching capability has been removed
> (for now) since still not deemed to be stable/reliable enough: as a
> consequence when SCMI Raw support is compiled in, the regular SCMI stack
> drivers are now inhibited permanently for that Kernel.
For our platforms (ARCH_BRCMSTB) we would need to have the ability to
start with the regular SCMI stack to satisfy if nothing else, all clock
consumers otherwise it makes it fairly challenging for us to boot to a
prompt as we purposely turn off all unnecessary peripherals to conserve
power. We could introduce a "full on" mode to remove the clock provider
dependency, but I suspect others on "real" silicon may suffer from the
same short comings.
Once user-space is reached, I suppose we could find a way to unbind from
all SCMI consumers, and/or ensure that runtime PM is disabled, cpufreq
is in a governor that won't do any active frequency switching etc.
What do you think?
--
Florian
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
@ 2022-10-29 2:38 ` Florian Fainelli
0 siblings, 0 replies; 50+ messages in thread
From: Florian Fainelli @ 2022-10-29 2:38 UTC (permalink / raw)
To: Cristian Marussi, linux-kernel, linux-arm-kernel
Cc: sudeep.holla, james.quinlan, Jonathan.Cameron, etienne.carriere,
vincent.guittot, souvik.chakravarty, wleavitt, peter.hilber,
nicola.mazzucato, tarek.el-sherbiny, quic_kshivnan
Hi Christian,
On 10/19/2022 1:46 PM, Cristian Marussi wrote:
[snip]
> In V2 the runtime enable/disable switching capability has been removed
> (for now) since still not deemed to be stable/reliable enough: as a
> consequence when SCMI Raw support is compiled in, the regular SCMI stack
> drivers are now inhibited permanently for that Kernel.
For our platforms (ARCH_BRCMSTB) we would need to have the ability to
start with the regular SCMI stack to satisfy if nothing else, all clock
consumers otherwise it makes it fairly challenging for us to boot to a
prompt as we purposely turn off all unnecessary peripherals to conserve
power. We could introduce a "full on" mode to remove the clock provider
dependency, but I suspect others on "real" silicon may suffer from the
same short comings.
Once user-space is reached, I suppose we could find a way to unbind from
all SCMI consumers, and/or ensure that runtime PM is disabled, cpufreq
is in a governor that won't do any active frequency switching etc.
What do you think?
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
2022-10-29 2:38 ` Florian Fainelli
@ 2022-10-29 11:14 ` Cristian Marussi
-1 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-29 11:14 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-kernel, linux-arm-kernel, sudeep.holla, james.quinlan,
Jonathan.Cameron, etienne.carriere, vincent.guittot,
souvik.chakravarty, wleavitt, peter.hilber, nicola.mazzucato,
tarek.el-sherbiny, quic_kshivnan
On Fri, Oct 28, 2022 at 07:38:25PM -0700, Florian Fainelli wrote:
> Hi Christian,
Hi Florian,
>
> On 10/19/2022 1:46 PM, Cristian Marussi wrote:
> [snip]
>
> > In V2 the runtime enable/disable switching capability has been removed
> > (for now) since still not deemed to be stable/reliable enough: as a
> > consequence when SCMI Raw support is compiled in, the regular SCMI stack
> > drivers are now inhibited permanently for that Kernel.
>
> For our platforms (ARCH_BRCMSTB) we would need to have the ability to start
> with the regular SCMI stack to satisfy if nothing else, all clock consumers
> otherwise it makes it fairly challenging for us to boot to a prompt as we
> purposely turn off all unnecessary peripherals to conserve power. We could
> introduce a "full on" mode to remove the clock provider dependency, but I
> suspect others on "real" silicon may suffer from the same short comings.
>
Indeed in V1 of this series the Raw mode was dynamically switched on/off at
runtime, so that you could have booted your system with a full working
SCMI stack and then Raw mode could have been enabled/disabled via
scmi_raw/enable entry, so causing the SCMI drivers to be unbound after
boot when entering Raw mode.
The idea, indeed, was initially to be able to boot a regular system, perform
any kind of non-SCMI testing and then switch at will into Raw mode, perform
your SCMI testing, and then back from the grave into normal mode when needed.
(this way you could have deployed into CI one single image for all
testing scenarios...)
The valid objections/worries were around the stability/relliability of such
a solution both when entering Raw mode and then coming back to normal
use: i.e. not being sure to be able to safely unbind all and to safely
bind back all the stack at the end.
The full discussion about this is in this thread if you'd want to
chime in with your point of view:
https://lore.kernel.org/all/Yvvb6Y+lzuABT1fy@sirena.org.uk/
So we removed it, but the idea was not fullly abandoned, we could revive
it with some variations, most probably binding this feature to a Kconfig
option (default=N).
Any feedback/idea from You in these regards is highly welcome.
> Once user-space is reached, I suppose we could find a way to unbind from all
> SCMI consumers, and/or ensure that runtime PM is disabled, cpufreq is in a
> governor that won't do any active frequency switching etc.
>
> What do you think?
Anyway, thinking about your scenario, maybe this dynamic-switch is NOT
a good solution in your case, because that was an all-or-nothing switch
that caused the full SCMI stack to be unbound, you could not selectively
keep alive what you possibly need to stay on even after boot.
I think that an alternative, maybe better, option in your case, since
you are willing to manually fine-tune at runtime which parts of the SCMI
has to be inhibited to avoid interferences while Raw-testing (via unbind/
unload or policy governors changes), a better option could be a
'full-coexistence' Raw mode solution.
In such a COEX configuration you'll boot a normal system with all the
SCMI drivers operational as configured in the DT, BUT with also the
Raw mode initialized and ready to be used.
In this scenario, basically, you'll have the normal message transactions,
coming from the regular SCMI drivers, and the Raw transactions, injected
from your test suite, that happily coexist side-by-side at the pure
trasaction level: this does NOT mean that you won't suffer any interference
at the protocol level so, as said, you'll have anyway to inhibit properly the
SCMI drivers by hand to avoid false-positives in your results.
(imagine testcase generating a series of Raw get/set/get transaction on
a resource while the regular stack issue a set on the same
res...notifications interferences are even worst...)
Now, the GOOD_NEWS : is ... that this can be done already with an additional
slim patch that has to be applied on top of this series, patch that I
have not posted still since not sure of its utility, but that I am using
heavily in my setup and which works fine for me (with really rare
interferences on testing even without fine-tuning/disabling anything by hand..)
I attached such patch at the end of this mail so that you can
immediately be unblocked and experiment further with Raw mode as you
planned.
I'll cleaned it up and post it also to the next V5 at this point.
Once that COEX is enabled, you should see something like this at boot:
[ 1.824269] arm-scmi firmware:scmi: SCMI RAW Mode initialized.
[ 1.830155] arm-scmi firmware:scmi: SCMI RAW Mode COEX enabled !
[ 1.836473] arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.
[ 1.847481] arm-scmi firmware:scmi: SCMI Protocol v2.0 'arm:arm' Firmware version 0x20a0000
...
... and then you can just use the scmi_raw entries as you wish.
Any transaction, normal or raw, will be visible as usual in the SCMI
traces (even though, currently, NOT distinguishable by type raw/normal)
So...after this other too much long mail (:P)...let me know what you
think about al of this (including the possibility of revive the runtime
dynamic switch too...)
Thanks,
Cristian
---->8-----
From 8613438d4171866088339e030959cb1de8e88c6a Mon Sep 17 00:00:00 2001
From: Cristian Marussi <cristian.marussi@arm.com>
Date: Sun, 21 Aug 2022 19:09:39 +0100
Subject: [PATCH] [DEBUG] firmware: arm_scmi: Add SCMI Raw mode COEXISTENCE
support
When Raw mode support is configured in coexistence mode, normal SCMI
drivers are allowed to register and work as usual with the SCMI core.
Normal and raw SCMI message transactions will remain anyway segregated from
each other, it is just that any SCMI test suite using the Raw mode
access could report unreliable results due to possible interferences
from the regular drivers access to shared SCMI resources.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
drivers/firmware/arm_scmi/Kconfig | 10 ++++++++++
drivers/firmware/arm_scmi/driver.c | 21 +++++++++++++++------
drivers/firmware/arm_scmi/protocols.h | 2 ++
drivers/firmware/arm_scmi/raw_mode.c | 2 +-
4 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/drivers/firmware/arm_scmi/Kconfig b/drivers/firmware/arm_scmi/Kconfig
index ab726a92ac2f..743f53fbe2f8 100644
--- a/drivers/firmware/arm_scmi/Kconfig
+++ b/drivers/firmware/arm_scmi/Kconfig
@@ -36,6 +36,16 @@ config ARM_SCMI_RAW_MODE_SUPPORT
order to avoid unexpected interactions with the SCMI Raw message
flow. If unsure say N.
+config ARM_SCMI_RAW_MODE_SUPPORT_COEX
+ bool "Allow SCMI Raw mode coexistence with normal SCMI stack"
+ depends on ARM_SCMI_RAW_MODE_SUPPORT
+ help
+ Allow SCMI Raw transmission mode to coexist with normal SCMI stack.
+
+ This will allow regular SCMI drivers to register with the core and
+ operate normally, thing which could make an SCMI test suite using the
+ SCMI Raw mode support unreliable. If unsure, say N.
+
config ARM_SCMI_HAVE_TRANSPORT
bool
help
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 32374fdba997..f0b06b6e8dc2 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -449,9 +449,14 @@ static struct scmi_xfer *scmi_xfer_get(const struct scmi_handle *handle,
*/
struct scmi_xfer *scmi_xfer_raw_get(const struct scmi_handle *handle)
{
+ struct scmi_xfer *xfer;
struct scmi_info *info = handle_to_scmi_info(handle);
- return scmi_xfer_get(handle, &info->tx_minfo);
+ xfer = scmi_xfer_get(handle, &info->tx_minfo);
+ if (!IS_ERR(xfer))
+ xfer->is_raw = true;
+
+ return xfer;
}
/**
@@ -531,6 +536,7 @@ void scmi_xfer_raw_put(const struct scmi_handle *handle, struct scmi_xfer *xfer)
{
struct scmi_info *info = handle_to_scmi_info(handle);
+ xfer->is_raw = false;
return __scmi_xfer_put(&info->tx_minfo, xfer);
}
@@ -2401,7 +2407,8 @@ int scmi_protocol_device_request(const struct scmi_device_id *id_table)
pr_debug("Requesting SCMI device (%s) for protocol %x\n",
id_table->name, id_table->protocol_id);
- if (IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT)) {
+ if (IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT) &&
+ !IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT_COEX)) {
pr_warn("SCMI Raw mode active. Rejecting '%s'/0x%02X\n",
id_table->name, id_table->protocol_id);
return -EINVAL;
@@ -2634,11 +2641,13 @@ static int scmi_probe(struct platform_device *pdev)
info->tx_minfo.max_msg);
if (!IS_ERR(info->raw)) {
dev_info(dev, "SCMI RAW Mode initialized.\n");
- return 0;
+ if (!IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT_COEX))
+ return 0;
+ dev_info(dev, "SCMI RAW Mode COEX enabled !\n");
+ } else {
+ dev_err(dev, "Failed to initialize SCMI RAW Mode !\n");
+ info->raw = NULL;
}
-
- dev_err(dev, "Failed to initialize SCMI RAW Mode !\n");
- info->raw = NULL;
}
if (scmi_notification_init(handle))
diff --git a/drivers/firmware/arm_scmi/protocols.h b/drivers/firmware/arm_scmi/protocols.h
index 2f3bf691db7c..70a48adcc320 100644
--- a/drivers/firmware/arm_scmi/protocols.h
+++ b/drivers/firmware/arm_scmi/protocols.h
@@ -88,6 +88,7 @@ struct scmi_msg_hdr {
/**
* struct scmi_xfer - Structure representing a message flow
*
+ * @is_raw: Flag to state if this xfer has been generated by RAW mode
* @transfer_id: Unique ID for debug & profiling purpose
* @hdr: Transmit message header
* @tx: Transmit message
@@ -119,6 +120,7 @@ struct scmi_msg_hdr {
* @priv: A pointer for transport private usage.
*/
struct scmi_xfer {
+ bool is_raw;
int transfer_id;
struct scmi_msg_hdr hdr;
struct scmi_msg tx;
diff --git a/drivers/firmware/arm_scmi/raw_mode.c b/drivers/firmware/arm_scmi/raw_mode.c
index 3fdfc0564286..0edaeb405267 100644
--- a/drivers/firmware/arm_scmi/raw_mode.c
+++ b/drivers/firmware/arm_scmi/raw_mode.c
@@ -1154,7 +1154,7 @@ void scmi_raw_message_report(void *r, struct scmi_xfer *xfer, unsigned int idx)
struct device *dev;
struct scmi_raw_mode_info *raw = r;
- if (!raw)
+ if (!raw || (idx == SCMI_RAW_REPLY_QUEUE && !xfer->is_raw))
return;
dev = raw->handle->dev;
--
2.34.1
----8<-----
^ permalink raw reply related [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
@ 2022-10-29 11:14 ` Cristian Marussi
0 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-10-29 11:14 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-kernel, linux-arm-kernel, sudeep.holla, james.quinlan,
Jonathan.Cameron, etienne.carriere, vincent.guittot,
souvik.chakravarty, wleavitt, peter.hilber, nicola.mazzucato,
tarek.el-sherbiny, quic_kshivnan
On Fri, Oct 28, 2022 at 07:38:25PM -0700, Florian Fainelli wrote:
> Hi Christian,
Hi Florian,
>
> On 10/19/2022 1:46 PM, Cristian Marussi wrote:
> [snip]
>
> > In V2 the runtime enable/disable switching capability has been removed
> > (for now) since still not deemed to be stable/reliable enough: as a
> > consequence when SCMI Raw support is compiled in, the regular SCMI stack
> > drivers are now inhibited permanently for that Kernel.
>
> For our platforms (ARCH_BRCMSTB) we would need to have the ability to start
> with the regular SCMI stack to satisfy if nothing else, all clock consumers
> otherwise it makes it fairly challenging for us to boot to a prompt as we
> purposely turn off all unnecessary peripherals to conserve power. We could
> introduce a "full on" mode to remove the clock provider dependency, but I
> suspect others on "real" silicon may suffer from the same short comings.
>
Indeed in V1 of this series the Raw mode was dynamically switched on/off at
runtime, so that you could have booted your system with a full working
SCMI stack and then Raw mode could have been enabled/disabled via
scmi_raw/enable entry, so causing the SCMI drivers to be unbound after
boot when entering Raw mode.
The idea, indeed, was initially to be able to boot a regular system, perform
any kind of non-SCMI testing and then switch at will into Raw mode, perform
your SCMI testing, and then back from the grave into normal mode when needed.
(this way you could have deployed into CI one single image for all
testing scenarios...)
The valid objections/worries were around the stability/relliability of such
a solution both when entering Raw mode and then coming back to normal
use: i.e. not being sure to be able to safely unbind all and to safely
bind back all the stack at the end.
The full discussion about this is in this thread if you'd want to
chime in with your point of view:
https://lore.kernel.org/all/Yvvb6Y+lzuABT1fy@sirena.org.uk/
So we removed it, but the idea was not fullly abandoned, we could revive
it with some variations, most probably binding this feature to a Kconfig
option (default=N).
Any feedback/idea from You in these regards is highly welcome.
> Once user-space is reached, I suppose we could find a way to unbind from all
> SCMI consumers, and/or ensure that runtime PM is disabled, cpufreq is in a
> governor that won't do any active frequency switching etc.
>
> What do you think?
Anyway, thinking about your scenario, maybe this dynamic-switch is NOT
a good solution in your case, because that was an all-or-nothing switch
that caused the full SCMI stack to be unbound, you could not selectively
keep alive what you possibly need to stay on even after boot.
I think that an alternative, maybe better, option in your case, since
you are willing to manually fine-tune at runtime which parts of the SCMI
has to be inhibited to avoid interferences while Raw-testing (via unbind/
unload or policy governors changes), a better option could be a
'full-coexistence' Raw mode solution.
In such a COEX configuration you'll boot a normal system with all the
SCMI drivers operational as configured in the DT, BUT with also the
Raw mode initialized and ready to be used.
In this scenario, basically, you'll have the normal message transactions,
coming from the regular SCMI drivers, and the Raw transactions, injected
from your test suite, that happily coexist side-by-side at the pure
trasaction level: this does NOT mean that you won't suffer any interference
at the protocol level so, as said, you'll have anyway to inhibit properly the
SCMI drivers by hand to avoid false-positives in your results.
(imagine testcase generating a series of Raw get/set/get transaction on
a resource while the regular stack issue a set on the same
res...notifications interferences are even worst...)
Now, the GOOD_NEWS : is ... that this can be done already with an additional
slim patch that has to be applied on top of this series, patch that I
have not posted still since not sure of its utility, but that I am using
heavily in my setup and which works fine for me (with really rare
interferences on testing even without fine-tuning/disabling anything by hand..)
I attached such patch at the end of this mail so that you can
immediately be unblocked and experiment further with Raw mode as you
planned.
I'll cleaned it up and post it also to the next V5 at this point.
Once that COEX is enabled, you should see something like this at boot:
[ 1.824269] arm-scmi firmware:scmi: SCMI RAW Mode initialized.
[ 1.830155] arm-scmi firmware:scmi: SCMI RAW Mode COEX enabled !
[ 1.836473] arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.
[ 1.847481] arm-scmi firmware:scmi: SCMI Protocol v2.0 'arm:arm' Firmware version 0x20a0000
...
... and then you can just use the scmi_raw entries as you wish.
Any transaction, normal or raw, will be visible as usual in the SCMI
traces (even though, currently, NOT distinguishable by type raw/normal)
So...after this other too much long mail (:P)...let me know what you
think about al of this (including the possibility of revive the runtime
dynamic switch too...)
Thanks,
Cristian
---->8-----
From 8613438d4171866088339e030959cb1de8e88c6a Mon Sep 17 00:00:00 2001
From: Cristian Marussi <cristian.marussi@arm.com>
Date: Sun, 21 Aug 2022 19:09:39 +0100
Subject: [PATCH] [DEBUG] firmware: arm_scmi: Add SCMI Raw mode COEXISTENCE
support
When Raw mode support is configured in coexistence mode, normal SCMI
drivers are allowed to register and work as usual with the SCMI core.
Normal and raw SCMI message transactions will remain anyway segregated from
each other, it is just that any SCMI test suite using the Raw mode
access could report unreliable results due to possible interferences
from the regular drivers access to shared SCMI resources.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
drivers/firmware/arm_scmi/Kconfig | 10 ++++++++++
drivers/firmware/arm_scmi/driver.c | 21 +++++++++++++++------
drivers/firmware/arm_scmi/protocols.h | 2 ++
drivers/firmware/arm_scmi/raw_mode.c | 2 +-
4 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/drivers/firmware/arm_scmi/Kconfig b/drivers/firmware/arm_scmi/Kconfig
index ab726a92ac2f..743f53fbe2f8 100644
--- a/drivers/firmware/arm_scmi/Kconfig
+++ b/drivers/firmware/arm_scmi/Kconfig
@@ -36,6 +36,16 @@ config ARM_SCMI_RAW_MODE_SUPPORT
order to avoid unexpected interactions with the SCMI Raw message
flow. If unsure say N.
+config ARM_SCMI_RAW_MODE_SUPPORT_COEX
+ bool "Allow SCMI Raw mode coexistence with normal SCMI stack"
+ depends on ARM_SCMI_RAW_MODE_SUPPORT
+ help
+ Allow SCMI Raw transmission mode to coexist with normal SCMI stack.
+
+ This will allow regular SCMI drivers to register with the core and
+ operate normally, thing which could make an SCMI test suite using the
+ SCMI Raw mode support unreliable. If unsure, say N.
+
config ARM_SCMI_HAVE_TRANSPORT
bool
help
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 32374fdba997..f0b06b6e8dc2 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -449,9 +449,14 @@ static struct scmi_xfer *scmi_xfer_get(const struct scmi_handle *handle,
*/
struct scmi_xfer *scmi_xfer_raw_get(const struct scmi_handle *handle)
{
+ struct scmi_xfer *xfer;
struct scmi_info *info = handle_to_scmi_info(handle);
- return scmi_xfer_get(handle, &info->tx_minfo);
+ xfer = scmi_xfer_get(handle, &info->tx_minfo);
+ if (!IS_ERR(xfer))
+ xfer->is_raw = true;
+
+ return xfer;
}
/**
@@ -531,6 +536,7 @@ void scmi_xfer_raw_put(const struct scmi_handle *handle, struct scmi_xfer *xfer)
{
struct scmi_info *info = handle_to_scmi_info(handle);
+ xfer->is_raw = false;
return __scmi_xfer_put(&info->tx_minfo, xfer);
}
@@ -2401,7 +2407,8 @@ int scmi_protocol_device_request(const struct scmi_device_id *id_table)
pr_debug("Requesting SCMI device (%s) for protocol %x\n",
id_table->name, id_table->protocol_id);
- if (IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT)) {
+ if (IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT) &&
+ !IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT_COEX)) {
pr_warn("SCMI Raw mode active. Rejecting '%s'/0x%02X\n",
id_table->name, id_table->protocol_id);
return -EINVAL;
@@ -2634,11 +2641,13 @@ static int scmi_probe(struct platform_device *pdev)
info->tx_minfo.max_msg);
if (!IS_ERR(info->raw)) {
dev_info(dev, "SCMI RAW Mode initialized.\n");
- return 0;
+ if (!IS_ENABLED(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT_COEX))
+ return 0;
+ dev_info(dev, "SCMI RAW Mode COEX enabled !\n");
+ } else {
+ dev_err(dev, "Failed to initialize SCMI RAW Mode !\n");
+ info->raw = NULL;
}
-
- dev_err(dev, "Failed to initialize SCMI RAW Mode !\n");
- info->raw = NULL;
}
if (scmi_notification_init(handle))
diff --git a/drivers/firmware/arm_scmi/protocols.h b/drivers/firmware/arm_scmi/protocols.h
index 2f3bf691db7c..70a48adcc320 100644
--- a/drivers/firmware/arm_scmi/protocols.h
+++ b/drivers/firmware/arm_scmi/protocols.h
@@ -88,6 +88,7 @@ struct scmi_msg_hdr {
/**
* struct scmi_xfer - Structure representing a message flow
*
+ * @is_raw: Flag to state if this xfer has been generated by RAW mode
* @transfer_id: Unique ID for debug & profiling purpose
* @hdr: Transmit message header
* @tx: Transmit message
@@ -119,6 +120,7 @@ struct scmi_msg_hdr {
* @priv: A pointer for transport private usage.
*/
struct scmi_xfer {
+ bool is_raw;
int transfer_id;
struct scmi_msg_hdr hdr;
struct scmi_msg tx;
diff --git a/drivers/firmware/arm_scmi/raw_mode.c b/drivers/firmware/arm_scmi/raw_mode.c
index 3fdfc0564286..0edaeb405267 100644
--- a/drivers/firmware/arm_scmi/raw_mode.c
+++ b/drivers/firmware/arm_scmi/raw_mode.c
@@ -1154,7 +1154,7 @@ void scmi_raw_message_report(void *r, struct scmi_xfer *xfer, unsigned int idx)
struct device *dev;
struct scmi_raw_mode_info *raw = r;
- if (!raw)
+ if (!raw || (idx == SCMI_RAW_REPLY_QUEUE && !xfer->is_raw))
return;
dev = raw->handle->dev;
--
2.34.1
----8<-----
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
2022-10-28 16:58 ` Cristian Marussi
@ 2022-11-02 8:54 ` Vincent Guittot
-1 siblings, 0 replies; 50+ messages in thread
From: Vincent Guittot @ 2022-11-02 8:54 UTC (permalink / raw)
To: Cristian Marussi
Cc: linux-kernel, linux-arm-kernel, sudeep.holla, james.quinlan,
Jonathan.Cameron, f.fainelli, etienne.carriere,
souvik.chakravarty, wleavitt, peter.hilber, nicola.mazzucato,
tarek.el-sherbiny, quic_kshivnan
On Fri, 28 Oct 2022 at 18:58, Cristian Marussi <cristian.marussi@arm.com> wrote:
>
> On Fri, Oct 28, 2022 at 06:18:52PM +0200, Vincent Guittot wrote:
> > On Fri, 28 Oct 2022 at 17:04, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > >
> > > On Fri, Oct 28, 2022 at 04:40:02PM +0200, Vincent Guittot wrote:
> > > > On Wed, 19 Oct 2022 at 22:46, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > >
> > > Hi Vincent,
> > >
> > > > > This series aims to introduce a new SCMI unified userspace interface meant
> > > > > to ease testing an SCMI Server implementation for compliance, fuzzing etc.,
> > > > > from the perspective of the OSPM agent (non-secure world only ...)
> > > > >
> >
> > [ snip]
> >
> > > > Hi Cristian,
> > > >
> > > > I have tested your series with an optee message transport layer and
> > > > been able to send raw messages to the scmi server PTA
> > > >
> > > > FWIW
> > > >
> > > > Tested-by: Vincent Guittot <vincent.guittot@linaro.org>
> > > >
> > >
> > > Thanks a lot for your test and feedback !
> > >
> > > ... but I was going to reply to this saying that I spotted another issue
> > > with the current SCMI Raw implementation (NOT related to optee/smc) so
> > > that I'll post a V5 next week :P
> > >
> > > Anyway, the issue is much related to the debugfs root used by SCMI Raw,
> > > i.e.:
> > >
> > > /sys/kernel/debug/scmi_raw/
> > >
> > > ..this works fine unless you run it on a system sporting multiple DT-defined
> > > server instances ...that is not officially supported but....ehm...a little
> > > bird told these system with multiple servers do exists :D
> >
> > ;-)
> >
> > >
> > > In such a case the SCMI core stack is probed multiuple times and so it
> > > will try to register multiple debugfs Raw roots: there is no chanche to
> > > root the SCMI Raw entries at the same point clearly ... and then anyway
> > > there is the issue of recognizing which server is rooted where ... with
> > > the additional pain that a server CANNOT be recognized by querying...cause
> > > there is only one by teh spec with agentID ZERO ... in theory :D...
> > >
> > > So my tentaive solution for V5 would be:
> > >
> > > - change the Raw root debugfs as:
> > >
> > > /sys/kernel/debug/scmi_raw/0/... (first server defined)
> > >
> > > /sys/kernel/debug/scmi_raw/1/... (possible additional server(s)..)
> > >
> > > - expose the DT scmi-server root-node name of the server somewhere under
> > > that debugfs root like:
> > >
> > > ..../scmi_raw/0/transport_name -> 'scmi-mbx'
> > >
> > > ..../scmi_raw/1/transport_name -> 'scmi-virtio'
> >
> > I was about to say that you would display the server name but that
> > means that you have send a request to the server which probably
> > defeats the purpose of the raw mode
> >
> > >
> > > so that if you know HOW you have configured your own system in the DT
> > > (maybe multiple servers with different kind of transports ?), you can
> > > easily select programmatically which one is which, and so decide
> > > which Raw debugfs fs to use...
> > >
> > > ... I plan to leave the SCMI ACS suite use by default the first system
> > > rooted at /sys/kernel/debug/scmi_raw/0/...maybe adding a commandline
> > > option to choose an alternative path for SCMI Raw.
> > >
> > > Does all of this sound reasonable ?
> >
> > Yes, adding an index looks good to me.
>
> Ok, I'll rework accordingly.
>
> >
> > As we are there, should we consider adding a per channel entry in the
> > tree when there are several channels shared with the same server ?
> >
>
> So, I was thinking about this and, even though, it seems not strictly
> needed for Compliance testing (as discussed offline) I do think that
> could be a sensible option to have as an additional mean to stress the
> server transport implementation (as you wish).
Thanks
>
> Having said that, this week, I was reasoning about an alternative
> interface to do this, i.e. to avoid to add even more debugfs entries
> for this chosen-channel config or possibly in the future to ask for
> transport polling mode (if supported by the underlying transport)
>
> My idea (not thought fully through as of now eh..) would be as follows:
>
> since the current Raw implementation enforces a minimum size of 4 bytes
> for the injected message (more on this later down below in NOTE), I was
> thinking about using less-than-4-bytes-sized messages to sort of
> pre-configure the Raw stack.
>
> IOW, instead of having a number of new additional entries like
>
> ../message_ch10
> ../message_ch13
> ../message_poll
>
> we could design a sort of API (in the API :D) that defines how
> 3-bytes message payload are to be interpreted, so that in normal usage
> everything will go on as it is now, while if a 3-bytes message is
> injected by a specially crafted testcase, it would be used to configure
> the behaviour stack for the subsequent set of Raw transactions
> (i.e. for the currently opened fd...) like:
>
> - open message fd
>
> - send a configure message:
>
> | proto_chan_# | flags (polling..) |
> ------------------------------------------
> 0 7 21
>
> - send/receive your test messages
>
> - repeat or close (then the config will vanish...)
>
> This would mean adding some sort entry under scmi_raw to expose the
> configured available channels on the system though.
>
> [maybe the flags above could also include an async flag and avoid
> also to add the message_async entries...]
>
> I discarded the idea to run the above config process via IOCTLs since
> it seemed to me even more frowned upon to use IOCTLs on a debugfs entry
> :P...but I maybe wrong ah...
>
> All of this is still to be explored anyway, any thoughts ? or evident
> drawbacks ? (beside having to clearly define an API for these message
> config machinery)
TBH, I'm not a fan of adding a protocol on top of the SCMI one. This
interface aims to test the SCMI servers and their channels so we
should focus on this and make it simple to use. IMHO, adding some
special bytes before the real scmi message is prone to create
complexity and error in the use of this debug interface.
>
> Anyway, whatever direction we'll choose (additional entries vs 3-bytes
> config msg), I would prefer to add this per-channel (or polling)
> capabilities with separate series to post on top of this in teh next
> cycle.
Ok
>
> ..too many words even this time :P
Thanks
Vincent
>
> Thanks,
> Cristian
>
>
> P.S: NOTE min_injected_msg_size:
> --------------------------------
> Thinking about all of the above, at first, I was a bit dubious if
> instead I should not allow, in Raw mode, the injection of shorter than
> 4 bytes messages (i.e. shorter than a SCMI header) for the purpose of
> fuzzing: then I realized that even though I should allow the injection
> of smaller messages, the underlying transports, as they are defined, both
> sides (platform and agent) will anyway carry out a 4bytes transaction,
> it's just that all the other non-provided bytes will be zeroed in the
> memory layout; this is just how the transports itself (shmem or msg
> based) are designed to work both sides. (and again would be transport
> layer testing more than SCMI spec verification..)
>
> So at the end I thought this kind of less-than-4-bytes transmissions
> gave no benefit and I came up with the above trick to use such tiny
> message for configuration.
>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
@ 2022-11-02 8:54 ` Vincent Guittot
0 siblings, 0 replies; 50+ messages in thread
From: Vincent Guittot @ 2022-11-02 8:54 UTC (permalink / raw)
To: Cristian Marussi
Cc: linux-kernel, linux-arm-kernel, sudeep.holla, james.quinlan,
Jonathan.Cameron, f.fainelli, etienne.carriere,
souvik.chakravarty, wleavitt, peter.hilber, nicola.mazzucato,
tarek.el-sherbiny, quic_kshivnan
On Fri, 28 Oct 2022 at 18:58, Cristian Marussi <cristian.marussi@arm.com> wrote:
>
> On Fri, Oct 28, 2022 at 06:18:52PM +0200, Vincent Guittot wrote:
> > On Fri, 28 Oct 2022 at 17:04, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > >
> > > On Fri, Oct 28, 2022 at 04:40:02PM +0200, Vincent Guittot wrote:
> > > > On Wed, 19 Oct 2022 at 22:46, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > >
> > > Hi Vincent,
> > >
> > > > > This series aims to introduce a new SCMI unified userspace interface meant
> > > > > to ease testing an SCMI Server implementation for compliance, fuzzing etc.,
> > > > > from the perspective of the OSPM agent (non-secure world only ...)
> > > > >
> >
> > [ snip]
> >
> > > > Hi Cristian,
> > > >
> > > > I have tested your series with an optee message transport layer and
> > > > been able to send raw messages to the scmi server PTA
> > > >
> > > > FWIW
> > > >
> > > > Tested-by: Vincent Guittot <vincent.guittot@linaro.org>
> > > >
> > >
> > > Thanks a lot for your test and feedback !
> > >
> > > ... but I was going to reply to this saying that I spotted another issue
> > > with the current SCMI Raw implementation (NOT related to optee/smc) so
> > > that I'll post a V5 next week :P
> > >
> > > Anyway, the issue is much related to the debugfs root used by SCMI Raw,
> > > i.e.:
> > >
> > > /sys/kernel/debug/scmi_raw/
> > >
> > > ..this works fine unless you run it on a system sporting multiple DT-defined
> > > server instances ...that is not officially supported but....ehm...a little
> > > bird told these system with multiple servers do exists :D
> >
> > ;-)
> >
> > >
> > > In such a case the SCMI core stack is probed multiuple times and so it
> > > will try to register multiple debugfs Raw roots: there is no chanche to
> > > root the SCMI Raw entries at the same point clearly ... and then anyway
> > > there is the issue of recognizing which server is rooted where ... with
> > > the additional pain that a server CANNOT be recognized by querying...cause
> > > there is only one by teh spec with agentID ZERO ... in theory :D...
> > >
> > > So my tentaive solution for V5 would be:
> > >
> > > - change the Raw root debugfs as:
> > >
> > > /sys/kernel/debug/scmi_raw/0/... (first server defined)
> > >
> > > /sys/kernel/debug/scmi_raw/1/... (possible additional server(s)..)
> > >
> > > - expose the DT scmi-server root-node name of the server somewhere under
> > > that debugfs root like:
> > >
> > > ..../scmi_raw/0/transport_name -> 'scmi-mbx'
> > >
> > > ..../scmi_raw/1/transport_name -> 'scmi-virtio'
> >
> > I was about to say that you would display the server name but that
> > means that you have send a request to the server which probably
> > defeats the purpose of the raw mode
> >
> > >
> > > so that if you know HOW you have configured your own system in the DT
> > > (maybe multiple servers with different kind of transports ?), you can
> > > easily select programmatically which one is which, and so decide
> > > which Raw debugfs fs to use...
> > >
> > > ... I plan to leave the SCMI ACS suite use by default the first system
> > > rooted at /sys/kernel/debug/scmi_raw/0/...maybe adding a commandline
> > > option to choose an alternative path for SCMI Raw.
> > >
> > > Does all of this sound reasonable ?
> >
> > Yes, adding an index looks good to me.
>
> Ok, I'll rework accordingly.
>
> >
> > As we are there, should we consider adding a per channel entry in the
> > tree when there are several channels shared with the same server ?
> >
>
> So, I was thinking about this and, even though, it seems not strictly
> needed for Compliance testing (as discussed offline) I do think that
> could be a sensible option to have as an additional mean to stress the
> server transport implementation (as you wish).
Thanks
>
> Having said that, this week, I was reasoning about an alternative
> interface to do this, i.e. to avoid to add even more debugfs entries
> for this chosen-channel config or possibly in the future to ask for
> transport polling mode (if supported by the underlying transport)
>
> My idea (not thought fully through as of now eh..) would be as follows:
>
> since the current Raw implementation enforces a minimum size of 4 bytes
> for the injected message (more on this later down below in NOTE), I was
> thinking about using less-than-4-bytes-sized messages to sort of
> pre-configure the Raw stack.
>
> IOW, instead of having a number of new additional entries like
>
> ../message_ch10
> ../message_ch13
> ../message_poll
>
> we could design a sort of API (in the API :D) that defines how
> 3-bytes message payload are to be interpreted, so that in normal usage
> everything will go on as it is now, while if a 3-bytes message is
> injected by a specially crafted testcase, it would be used to configure
> the behaviour stack for the subsequent set of Raw transactions
> (i.e. for the currently opened fd...) like:
>
> - open message fd
>
> - send a configure message:
>
> | proto_chan_# | flags (polling..) |
> ------------------------------------------
> 0 7 21
>
> - send/receive your test messages
>
> - repeat or close (then the config will vanish...)
>
> This would mean adding some sort entry under scmi_raw to expose the
> configured available channels on the system though.
>
> [maybe the flags above could also include an async flag and avoid
> also to add the message_async entries...]
>
> I discarded the idea to run the above config process via IOCTLs since
> it seemed to me even more frowned upon to use IOCTLs on a debugfs entry
> :P...but I maybe wrong ah...
>
> All of this is still to be explored anyway, any thoughts ? or evident
> drawbacks ? (beside having to clearly define an API for these message
> config machinery)
TBH, I'm not a fan of adding a protocol on top of the SCMI one. This
interface aims to test the SCMI servers and their channels so we
should focus on this and make it simple to use. IMHO, adding some
special bytes before the real scmi message is prone to create
complexity and error in the use of this debug interface.
>
> Anyway, whatever direction we'll choose (additional entries vs 3-bytes
> config msg), I would prefer to add this per-channel (or polling)
> capabilities with separate series to post on top of this in teh next
> cycle.
Ok
>
> ..too many words even this time :P
Thanks
Vincent
>
> Thanks,
> Cristian
>
>
> P.S: NOTE min_injected_msg_size:
> --------------------------------
> Thinking about all of the above, at first, I was a bit dubious if
> instead I should not allow, in Raw mode, the injection of shorter than
> 4 bytes messages (i.e. shorter than a SCMI header) for the purpose of
> fuzzing: then I realized that even though I should allow the injection
> of smaller messages, the underlying transports, as they are defined, both
> sides (platform and agent) will anyway carry out a 4bytes transaction,
> it's just that all the other non-provided bytes will be zeroed in the
> memory layout; this is just how the transports itself (shmem or msg
> based) are designed to work both sides. (and again would be transport
> layer testing more than SCMI spec verification..)
>
> So at the end I thought this kind of less-than-4-bytes transmissions
> gave no benefit and I came up with the above trick to use such tiny
> message for configuration.
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
2022-11-02 8:54 ` Vincent Guittot
@ 2022-11-03 9:21 ` Cristian Marussi
-1 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-11-03 9:21 UTC (permalink / raw)
To: Vincent Guittot
Cc: linux-kernel, linux-arm-kernel, sudeep.holla, james.quinlan,
Jonathan.Cameron, f.fainelli, etienne.carriere,
souvik.chakravarty, wleavitt, peter.hilber, nicola.mazzucato,
tarek.el-sherbiny, quic_kshivnan
On Wed, Nov 02, 2022 at 09:54:50AM +0100, Vincent Guittot wrote:
> On Fri, 28 Oct 2022 at 18:58, Cristian Marussi <cristian.marussi@arm.com> wrote:
> >
> > On Fri, Oct 28, 2022 at 06:18:52PM +0200, Vincent Guittot wrote:
> > > On Fri, 28 Oct 2022 at 17:04, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > > >
> > > > On Fri, Oct 28, 2022 at 04:40:02PM +0200, Vincent Guittot wrote:
> > > > > On Wed, 19 Oct 2022 at 22:46, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > >
> > > > Hi Vincent,
> > > >
> > > > > > This series aims to introduce a new SCMI unified userspace interface meant
> > > > > > to ease testing an SCMI Server implementation for compliance, fuzzing etc.,
> > > > > > from the perspective of the OSPM agent (non-secure world only ...)
> > > > > >
> > >
> > > [ snip]
> > >
> > > > > Hi Cristian,
> > > > >
> > > > > I have tested your series with an optee message transport layer and
> > > > > been able to send raw messages to the scmi server PTA
> > > > >
> > > > > FWIW
> > > > >
> > > > > Tested-by: Vincent Guittot <vincent.guittot@linaro.org>
> > > > >
> > > >
> > > > Thanks a lot for your test and feedback !
> > > >
> > > > ... but I was going to reply to this saying that I spotted another issue
> > > > with the current SCMI Raw implementation (NOT related to optee/smc) so
> > > > that I'll post a V5 next week :P
> > > >
> > > > Anyway, the issue is much related to the debugfs root used by SCMI Raw,
> > > > i.e.:
> > > >
> > > > /sys/kernel/debug/scmi_raw/
> > > >
> > > > ..this works fine unless you run it on a system sporting multiple DT-defined
> > > > server instances ...that is not officially supported but....ehm...a little
> > > > bird told these system with multiple servers do exists :D
> > >
> > > ;-)
> > >
> > > >
> > > > In such a case the SCMI core stack is probed multiuple times and so it
> > > > will try to register multiple debugfs Raw roots: there is no chanche to
> > > > root the SCMI Raw entries at the same point clearly ... and then anyway
> > > > there is the issue of recognizing which server is rooted where ... with
> > > > the additional pain that a server CANNOT be recognized by querying...cause
> > > > there is only one by teh spec with agentID ZERO ... in theory :D...
> > > >
> > > > So my tentaive solution for V5 would be:
> > > >
> > > > - change the Raw root debugfs as:
> > > >
> > > > /sys/kernel/debug/scmi_raw/0/... (first server defined)
> > > >
> > > > /sys/kernel/debug/scmi_raw/1/... (possible additional server(s)..)
> > > >
> > > > - expose the DT scmi-server root-node name of the server somewhere under
> > > > that debugfs root like:
> > > >
> > > > ..../scmi_raw/0/transport_name -> 'scmi-mbx'
> > > >
> > > > ..../scmi_raw/1/transport_name -> 'scmi-virtio'
> > >
> > > I was about to say that you would display the server name but that
> > > means that you have send a request to the server which probably
> > > defeats the purpose of the raw mode
> > >
> > > >
> > > > so that if you know HOW you have configured your own system in the DT
> > > > (maybe multiple servers with different kind of transports ?), you can
> > > > easily select programmatically which one is which, and so decide
> > > > which Raw debugfs fs to use...
> > > >
> > > > ... I plan to leave the SCMI ACS suite use by default the first system
> > > > rooted at /sys/kernel/debug/scmi_raw/0/...maybe adding a commandline
> > > > option to choose an alternative path for SCMI Raw.
> > > >
> > > > Does all of this sound reasonable ?
> > >
> > > Yes, adding an index looks good to me.
> >
> > Ok, I'll rework accordingly.
> >
> > >
> > > As we are there, should we consider adding a per channel entry in the
> > > tree when there are several channels shared with the same server ?
> > >
> >
> > So, I was thinking about this and, even though, it seems not strictly
> > needed for Compliance testing (as discussed offline) I do think that
> > could be a sensible option to have as an additional mean to stress the
> > server transport implementation (as you wish).
>
> Thanks
>
> >
> > Having said that, this week, I was reasoning about an alternative
> > interface to do this, i.e. to avoid to add even more debugfs entries
> > for this chosen-channel config or possibly in the future to ask for
> > transport polling mode (if supported by the underlying transport)
> >
> > My idea (not thought fully through as of now eh..) would be as follows:
> >
> > since the current Raw implementation enforces a minimum size of 4 bytes
> > for the injected message (more on this later down below in NOTE), I was
> > thinking about using less-than-4-bytes-sized messages to sort of
> > pre-configure the Raw stack.
> >
> > IOW, instead of having a number of new additional entries like
> >
> > ../message_ch10
> > ../message_ch13
> > ../message_poll
> >
> > we could design a sort of API (in the API :D) that defines how
> > 3-bytes message payload are to be interpreted, so that in normal usage
> > everything will go on as it is now, while if a 3-bytes message is
> > injected by a specially crafted testcase, it would be used to configure
> > the behaviour stack for the subsequent set of Raw transactions
> > (i.e. for the currently opened fd...) like:
> >
> > - open message fd
> >
> > - send a configure message:
> >
> > | proto_chan_# | flags (polling..) |
> > ------------------------------------------
> > 0 7 21
> >
> > - send/receive your test messages
> >
> > - repeat or close (then the config will vanish...)
> >
> > This would mean adding some sort entry under scmi_raw to expose the
> > configured available channels on the system though.
> >
> > [maybe the flags above could also include an async flag and avoid
> > also to add the message_async entries...]
> >
> > I discarded the idea to run the above config process via IOCTLs since
> > it seemed to me even more frowned upon to use IOCTLs on a debugfs entry
> > :P...but I maybe wrong ah...
> >
> > All of this is still to be explored anyway, any thoughts ? or evident
> > drawbacks ? (beside having to clearly define an API for these message
> > config machinery)
>
> TBH, I'm not a fan of adding a protocol on top of the SCMI one. This
> interface aims to test the SCMI servers and their channels so we
> should focus on this and make it simple to use. IMHO, adding some
> special bytes before the real scmi message is prone to create
> complexity and error in the use of this debug interface.
>
Indeed, even if only for transport-related tests, the risk is to make
more complicate to use the interface.
Agreed, just wanted to have some feedback. I'll revert to some based on
debugfs trying to minimize entries and improper usage...maybe something
like grouping on per-channel subdirs when different channels are
available.
E.g. on a system with a dedicated PERF channel I could have
../scmi_raw/0/message <<< usual auto channel selection
/message_async
...
/chan_0x10/message <<< use default channel (base proto)
/message_async
....
/chan_0x13/message <<< use PERF channel
/message_async
....
The alternative would be to have a common single entry to configure the usage
of the a single batch of message/message_async entries BUT that seems to
me more prone to error, e.g. if you dont clear the special config at the
end of your special testcase you could endup using custom channels conf also
with any following regular test which expects to benefit from the
automatic channel selection (which I still think should be default way of
running these tests..)
Thoughts ?
Thanks for the feedback.
Cristian
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
@ 2022-11-03 9:21 ` Cristian Marussi
0 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-11-03 9:21 UTC (permalink / raw)
To: Vincent Guittot
Cc: linux-kernel, linux-arm-kernel, sudeep.holla, james.quinlan,
Jonathan.Cameron, f.fainelli, etienne.carriere,
souvik.chakravarty, wleavitt, peter.hilber, nicola.mazzucato,
tarek.el-sherbiny, quic_kshivnan
On Wed, Nov 02, 2022 at 09:54:50AM +0100, Vincent Guittot wrote:
> On Fri, 28 Oct 2022 at 18:58, Cristian Marussi <cristian.marussi@arm.com> wrote:
> >
> > On Fri, Oct 28, 2022 at 06:18:52PM +0200, Vincent Guittot wrote:
> > > On Fri, 28 Oct 2022 at 17:04, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > > >
> > > > On Fri, Oct 28, 2022 at 04:40:02PM +0200, Vincent Guittot wrote:
> > > > > On Wed, 19 Oct 2022 at 22:46, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > >
> > > > Hi Vincent,
> > > >
> > > > > > This series aims to introduce a new SCMI unified userspace interface meant
> > > > > > to ease testing an SCMI Server implementation for compliance, fuzzing etc.,
> > > > > > from the perspective of the OSPM agent (non-secure world only ...)
> > > > > >
> > >
> > > [ snip]
> > >
> > > > > Hi Cristian,
> > > > >
> > > > > I have tested your series with an optee message transport layer and
> > > > > been able to send raw messages to the scmi server PTA
> > > > >
> > > > > FWIW
> > > > >
> > > > > Tested-by: Vincent Guittot <vincent.guittot@linaro.org>
> > > > >
> > > >
> > > > Thanks a lot for your test and feedback !
> > > >
> > > > ... but I was going to reply to this saying that I spotted another issue
> > > > with the current SCMI Raw implementation (NOT related to optee/smc) so
> > > > that I'll post a V5 next week :P
> > > >
> > > > Anyway, the issue is much related to the debugfs root used by SCMI Raw,
> > > > i.e.:
> > > >
> > > > /sys/kernel/debug/scmi_raw/
> > > >
> > > > ..this works fine unless you run it on a system sporting multiple DT-defined
> > > > server instances ...that is not officially supported but....ehm...a little
> > > > bird told these system with multiple servers do exists :D
> > >
> > > ;-)
> > >
> > > >
> > > > In such a case the SCMI core stack is probed multiuple times and so it
> > > > will try to register multiple debugfs Raw roots: there is no chanche to
> > > > root the SCMI Raw entries at the same point clearly ... and then anyway
> > > > there is the issue of recognizing which server is rooted where ... with
> > > > the additional pain that a server CANNOT be recognized by querying...cause
> > > > there is only one by teh spec with agentID ZERO ... in theory :D...
> > > >
> > > > So my tentaive solution for V5 would be:
> > > >
> > > > - change the Raw root debugfs as:
> > > >
> > > > /sys/kernel/debug/scmi_raw/0/... (first server defined)
> > > >
> > > > /sys/kernel/debug/scmi_raw/1/... (possible additional server(s)..)
> > > >
> > > > - expose the DT scmi-server root-node name of the server somewhere under
> > > > that debugfs root like:
> > > >
> > > > ..../scmi_raw/0/transport_name -> 'scmi-mbx'
> > > >
> > > > ..../scmi_raw/1/transport_name -> 'scmi-virtio'
> > >
> > > I was about to say that you would display the server name but that
> > > means that you have send a request to the server which probably
> > > defeats the purpose of the raw mode
> > >
> > > >
> > > > so that if you know HOW you have configured your own system in the DT
> > > > (maybe multiple servers with different kind of transports ?), you can
> > > > easily select programmatically which one is which, and so decide
> > > > which Raw debugfs fs to use...
> > > >
> > > > ... I plan to leave the SCMI ACS suite use by default the first system
> > > > rooted at /sys/kernel/debug/scmi_raw/0/...maybe adding a commandline
> > > > option to choose an alternative path for SCMI Raw.
> > > >
> > > > Does all of this sound reasonable ?
> > >
> > > Yes, adding an index looks good to me.
> >
> > Ok, I'll rework accordingly.
> >
> > >
> > > As we are there, should we consider adding a per channel entry in the
> > > tree when there are several channels shared with the same server ?
> > >
> >
> > So, I was thinking about this and, even though, it seems not strictly
> > needed for Compliance testing (as discussed offline) I do think that
> > could be a sensible option to have as an additional mean to stress the
> > server transport implementation (as you wish).
>
> Thanks
>
> >
> > Having said that, this week, I was reasoning about an alternative
> > interface to do this, i.e. to avoid to add even more debugfs entries
> > for this chosen-channel config or possibly in the future to ask for
> > transport polling mode (if supported by the underlying transport)
> >
> > My idea (not thought fully through as of now eh..) would be as follows:
> >
> > since the current Raw implementation enforces a minimum size of 4 bytes
> > for the injected message (more on this later down below in NOTE), I was
> > thinking about using less-than-4-bytes-sized messages to sort of
> > pre-configure the Raw stack.
> >
> > IOW, instead of having a number of new additional entries like
> >
> > ../message_ch10
> > ../message_ch13
> > ../message_poll
> >
> > we could design a sort of API (in the API :D) that defines how
> > 3-bytes message payload are to be interpreted, so that in normal usage
> > everything will go on as it is now, while if a 3-bytes message is
> > injected by a specially crafted testcase, it would be used to configure
> > the behaviour stack for the subsequent set of Raw transactions
> > (i.e. for the currently opened fd...) like:
> >
> > - open message fd
> >
> > - send a configure message:
> >
> > | proto_chan_# | flags (polling..) |
> > ------------------------------------------
> > 0 7 21
> >
> > - send/receive your test messages
> >
> > - repeat or close (then the config will vanish...)
> >
> > This would mean adding some sort entry under scmi_raw to expose the
> > configured available channels on the system though.
> >
> > [maybe the flags above could also include an async flag and avoid
> > also to add the message_async entries...]
> >
> > I discarded the idea to run the above config process via IOCTLs since
> > it seemed to me even more frowned upon to use IOCTLs on a debugfs entry
> > :P...but I maybe wrong ah...
> >
> > All of this is still to be explored anyway, any thoughts ? or evident
> > drawbacks ? (beside having to clearly define an API for these message
> > config machinery)
>
> TBH, I'm not a fan of adding a protocol on top of the SCMI one. This
> interface aims to test the SCMI servers and their channels so we
> should focus on this and make it simple to use. IMHO, adding some
> special bytes before the real scmi message is prone to create
> complexity and error in the use of this debug interface.
>
Indeed, even if only for transport-related tests, the risk is to make
more complicate to use the interface.
Agreed, just wanted to have some feedback. I'll revert to some based on
debugfs trying to minimize entries and improper usage...maybe something
like grouping on per-channel subdirs when different channels are
available.
E.g. on a system with a dedicated PERF channel I could have
../scmi_raw/0/message <<< usual auto channel selection
/message_async
...
/chan_0x10/message <<< use default channel (base proto)
/message_async
....
/chan_0x13/message <<< use PERF channel
/message_async
....
The alternative would be to have a common single entry to configure the usage
of the a single batch of message/message_async entries BUT that seems to
me more prone to error, e.g. if you dont clear the special config at the
end of your special testcase you could endup using custom channels conf also
with any following regular test which expects to benefit from the
automatic channel selection (which I still think should be default way of
running these tests..)
Thoughts ?
Thanks for the feedback.
Cristian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
2022-11-03 9:21 ` Cristian Marussi
@ 2022-11-03 10:58 ` Vincent Guittot
-1 siblings, 0 replies; 50+ messages in thread
From: Vincent Guittot @ 2022-11-03 10:58 UTC (permalink / raw)
To: Cristian Marussi
Cc: linux-kernel, linux-arm-kernel, sudeep.holla, james.quinlan,
Jonathan.Cameron, f.fainelli, etienne.carriere,
souvik.chakravarty, wleavitt, peter.hilber, nicola.mazzucato,
tarek.el-sherbiny, quic_kshivnan
On Thu, 3 Nov 2022 at 10:21, Cristian Marussi <cristian.marussi@arm.com> wrote:
>
> On Wed, Nov 02, 2022 at 09:54:50AM +0100, Vincent Guittot wrote:
> > On Fri, 28 Oct 2022 at 18:58, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > >
> > > On Fri, Oct 28, 2022 at 06:18:52PM +0200, Vincent Guittot wrote:
> > > > On Fri, 28 Oct 2022 at 17:04, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > > > >
> > > > > On Fri, Oct 28, 2022 at 04:40:02PM +0200, Vincent Guittot wrote:
> > > > > > On Wed, 19 Oct 2022 at 22:46, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > >
> > > > > Hi Vincent,
> > > > >
> > > > > > > This series aims to introduce a new SCMI unified userspace interface meant
> > > > > > > to ease testing an SCMI Server implementation for compliance, fuzzing etc.,
> > > > > > > from the perspective of the OSPM agent (non-secure world only ...)
> > > > > > >
> > > >
> > > > [ snip]
> > > >
> > > > > > Hi Cristian,
> > > > > >
> > > > > > I have tested your series with an optee message transport layer and
> > > > > > been able to send raw messages to the scmi server PTA
> > > > > >
> > > > > > FWIW
> > > > > >
> > > > > > Tested-by: Vincent Guittot <vincent.guittot@linaro.org>
> > > > > >
> > > > >
> > > > > Thanks a lot for your test and feedback !
> > > > >
> > > > > ... but I was going to reply to this saying that I spotted another issue
> > > > > with the current SCMI Raw implementation (NOT related to optee/smc) so
> > > > > that I'll post a V5 next week :P
> > > > >
> > > > > Anyway, the issue is much related to the debugfs root used by SCMI Raw,
> > > > > i.e.:
> > > > >
> > > > > /sys/kernel/debug/scmi_raw/
> > > > >
> > > > > ..this works fine unless you run it on a system sporting multiple DT-defined
> > > > > server instances ...that is not officially supported but....ehm...a little
> > > > > bird told these system with multiple servers do exists :D
> > > >
> > > > ;-)
> > > >
> > > > >
> > > > > In such a case the SCMI core stack is probed multiuple times and so it
> > > > > will try to register multiple debugfs Raw roots: there is no chanche to
> > > > > root the SCMI Raw entries at the same point clearly ... and then anyway
> > > > > there is the issue of recognizing which server is rooted where ... with
> > > > > the additional pain that a server CANNOT be recognized by querying...cause
> > > > > there is only one by teh spec with agentID ZERO ... in theory :D...
> > > > >
> > > > > So my tentaive solution for V5 would be:
> > > > >
> > > > > - change the Raw root debugfs as:
> > > > >
> > > > > /sys/kernel/debug/scmi_raw/0/... (first server defined)
> > > > >
> > > > > /sys/kernel/debug/scmi_raw/1/... (possible additional server(s)..)
> > > > >
> > > > > - expose the DT scmi-server root-node name of the server somewhere under
> > > > > that debugfs root like:
> > > > >
> > > > > ..../scmi_raw/0/transport_name -> 'scmi-mbx'
> > > > >
> > > > > ..../scmi_raw/1/transport_name -> 'scmi-virtio'
> > > >
> > > > I was about to say that you would display the server name but that
> > > > means that you have send a request to the server which probably
> > > > defeats the purpose of the raw mode
> > > >
> > > > >
> > > > > so that if you know HOW you have configured your own system in the DT
> > > > > (maybe multiple servers with different kind of transports ?), you can
> > > > > easily select programmatically which one is which, and so decide
> > > > > which Raw debugfs fs to use...
> > > > >
> > > > > ... I plan to leave the SCMI ACS suite use by default the first system
> > > > > rooted at /sys/kernel/debug/scmi_raw/0/...maybe adding a commandline
> > > > > option to choose an alternative path for SCMI Raw.
> > > > >
> > > > > Does all of this sound reasonable ?
> > > >
> > > > Yes, adding an index looks good to me.
> > >
> > > Ok, I'll rework accordingly.
> > >
> > > >
> > > > As we are there, should we consider adding a per channel entry in the
> > > > tree when there are several channels shared with the same server ?
> > > >
> > >
> > > So, I was thinking about this and, even though, it seems not strictly
> > > needed for Compliance testing (as discussed offline) I do think that
> > > could be a sensible option to have as an additional mean to stress the
> > > server transport implementation (as you wish).
> >
> > Thanks
> >
> > >
> > > Having said that, this week, I was reasoning about an alternative
> > > interface to do this, i.e. to avoid to add even more debugfs entries
> > > for this chosen-channel config or possibly in the future to ask for
> > > transport polling mode (if supported by the underlying transport)
> > >
> > > My idea (not thought fully through as of now eh..) would be as follows:
> > >
> > > since the current Raw implementation enforces a minimum size of 4 bytes
> > > for the injected message (more on this later down below in NOTE), I was
> > > thinking about using less-than-4-bytes-sized messages to sort of
> > > pre-configure the Raw stack.
> > >
> > > IOW, instead of having a number of new additional entries like
> > >
> > > ../message_ch10
> > > ../message_ch13
> > > ../message_poll
> > >
> > > we could design a sort of API (in the API :D) that defines how
> > > 3-bytes message payload are to be interpreted, so that in normal usage
> > > everything will go on as it is now, while if a 3-bytes message is
> > > injected by a specially crafted testcase, it would be used to configure
> > > the behaviour stack for the subsequent set of Raw transactions
> > > (i.e. for the currently opened fd...) like:
> > >
> > > - open message fd
> > >
> > > - send a configure message:
> > >
> > > | proto_chan_# | flags (polling..) |
> > > ------------------------------------------
> > > 0 7 21
> > >
> > > - send/receive your test messages
> > >
> > > - repeat or close (then the config will vanish...)
> > >
> > > This would mean adding some sort entry under scmi_raw to expose the
> > > configured available channels on the system though.
> > >
> > > [maybe the flags above could also include an async flag and avoid
> > > also to add the message_async entries...]
> > >
> > > I discarded the idea to run the above config process via IOCTLs since
> > > it seemed to me even more frowned upon to use IOCTLs on a debugfs entry
> > > :P...but I maybe wrong ah...
> > >
> > > All of this is still to be explored anyway, any thoughts ? or evident
> > > drawbacks ? (beside having to clearly define an API for these message
> > > config machinery)
> >
> > TBH, I'm not a fan of adding a protocol on top of the SCMI one. This
> > interface aims to test the SCMI servers and their channels so we
> > should focus on this and make it simple to use. IMHO, adding some
> > special bytes before the real scmi message is prone to create
> > complexity and error in the use of this debug interface.
> >
>
> Indeed, even if only for transport-related tests, the risk is to make
> more complicate to use the interface.
>
> Agreed, just wanted to have some feedback. I'll revert to some based on
> debugfs trying to minimize entries and improper usage...maybe something
> like grouping on per-channel subdirs when different channels are
> available.
>
> E.g. on a system with a dedicated PERF channel I could have
>
>
> ../scmi_raw/0/message <<< usual auto channel selection
> /message_async
> ...
>
> /chan_0x10/message <<< use default channel (base proto)
> /message_async
> ....
>
> /chan_0x13/message <<< use PERF channel
> /message_async
> ....
The proposal above looks good for me
Thanks
>
> The alternative would be to have a common single entry to configure the usage
> of the a single batch of message/message_async entries BUT that seems to
> me more prone to error, e.g. if you dont clear the special config at the
> end of your special testcase you could endup using custom channels conf also
> with any following regular test which expects to benefit from the
> automatic channel selection (which I still think should be default way of
> running these tests..)
>
> Thoughts ?
>
> Thanks for the feedback.
> Cristian
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
@ 2022-11-03 10:58 ` Vincent Guittot
0 siblings, 0 replies; 50+ messages in thread
From: Vincent Guittot @ 2022-11-03 10:58 UTC (permalink / raw)
To: Cristian Marussi
Cc: linux-kernel, linux-arm-kernel, sudeep.holla, james.quinlan,
Jonathan.Cameron, f.fainelli, etienne.carriere,
souvik.chakravarty, wleavitt, peter.hilber, nicola.mazzucato,
tarek.el-sherbiny, quic_kshivnan
On Thu, 3 Nov 2022 at 10:21, Cristian Marussi <cristian.marussi@arm.com> wrote:
>
> On Wed, Nov 02, 2022 at 09:54:50AM +0100, Vincent Guittot wrote:
> > On Fri, 28 Oct 2022 at 18:58, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > >
> > > On Fri, Oct 28, 2022 at 06:18:52PM +0200, Vincent Guittot wrote:
> > > > On Fri, 28 Oct 2022 at 17:04, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > > > >
> > > > > On Fri, Oct 28, 2022 at 04:40:02PM +0200, Vincent Guittot wrote:
> > > > > > On Wed, 19 Oct 2022 at 22:46, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > >
> > > > > Hi Vincent,
> > > > >
> > > > > > > This series aims to introduce a new SCMI unified userspace interface meant
> > > > > > > to ease testing an SCMI Server implementation for compliance, fuzzing etc.,
> > > > > > > from the perspective of the OSPM agent (non-secure world only ...)
> > > > > > >
> > > >
> > > > [ snip]
> > > >
> > > > > > Hi Cristian,
> > > > > >
> > > > > > I have tested your series with an optee message transport layer and
> > > > > > been able to send raw messages to the scmi server PTA
> > > > > >
> > > > > > FWIW
> > > > > >
> > > > > > Tested-by: Vincent Guittot <vincent.guittot@linaro.org>
> > > > > >
> > > > >
> > > > > Thanks a lot for your test and feedback !
> > > > >
> > > > > ... but I was going to reply to this saying that I spotted another issue
> > > > > with the current SCMI Raw implementation (NOT related to optee/smc) so
> > > > > that I'll post a V5 next week :P
> > > > >
> > > > > Anyway, the issue is much related to the debugfs root used by SCMI Raw,
> > > > > i.e.:
> > > > >
> > > > > /sys/kernel/debug/scmi_raw/
> > > > >
> > > > > ..this works fine unless you run it on a system sporting multiple DT-defined
> > > > > server instances ...that is not officially supported but....ehm...a little
> > > > > bird told these system with multiple servers do exists :D
> > > >
> > > > ;-)
> > > >
> > > > >
> > > > > In such a case the SCMI core stack is probed multiuple times and so it
> > > > > will try to register multiple debugfs Raw roots: there is no chanche to
> > > > > root the SCMI Raw entries at the same point clearly ... and then anyway
> > > > > there is the issue of recognizing which server is rooted where ... with
> > > > > the additional pain that a server CANNOT be recognized by querying...cause
> > > > > there is only one by teh spec with agentID ZERO ... in theory :D...
> > > > >
> > > > > So my tentaive solution for V5 would be:
> > > > >
> > > > > - change the Raw root debugfs as:
> > > > >
> > > > > /sys/kernel/debug/scmi_raw/0/... (first server defined)
> > > > >
> > > > > /sys/kernel/debug/scmi_raw/1/... (possible additional server(s)..)
> > > > >
> > > > > - expose the DT scmi-server root-node name of the server somewhere under
> > > > > that debugfs root like:
> > > > >
> > > > > ..../scmi_raw/0/transport_name -> 'scmi-mbx'
> > > > >
> > > > > ..../scmi_raw/1/transport_name -> 'scmi-virtio'
> > > >
> > > > I was about to say that you would display the server name but that
> > > > means that you have send a request to the server which probably
> > > > defeats the purpose of the raw mode
> > > >
> > > > >
> > > > > so that if you know HOW you have configured your own system in the DT
> > > > > (maybe multiple servers with different kind of transports ?), you can
> > > > > easily select programmatically which one is which, and so decide
> > > > > which Raw debugfs fs to use...
> > > > >
> > > > > ... I plan to leave the SCMI ACS suite use by default the first system
> > > > > rooted at /sys/kernel/debug/scmi_raw/0/...maybe adding a commandline
> > > > > option to choose an alternative path for SCMI Raw.
> > > > >
> > > > > Does all of this sound reasonable ?
> > > >
> > > > Yes, adding an index looks good to me.
> > >
> > > Ok, I'll rework accordingly.
> > >
> > > >
> > > > As we are there, should we consider adding a per channel entry in the
> > > > tree when there are several channels shared with the same server ?
> > > >
> > >
> > > So, I was thinking about this and, even though, it seems not strictly
> > > needed for Compliance testing (as discussed offline) I do think that
> > > could be a sensible option to have as an additional mean to stress the
> > > server transport implementation (as you wish).
> >
> > Thanks
> >
> > >
> > > Having said that, this week, I was reasoning about an alternative
> > > interface to do this, i.e. to avoid to add even more debugfs entries
> > > for this chosen-channel config or possibly in the future to ask for
> > > transport polling mode (if supported by the underlying transport)
> > >
> > > My idea (not thought fully through as of now eh..) would be as follows:
> > >
> > > since the current Raw implementation enforces a minimum size of 4 bytes
> > > for the injected message (more on this later down below in NOTE), I was
> > > thinking about using less-than-4-bytes-sized messages to sort of
> > > pre-configure the Raw stack.
> > >
> > > IOW, instead of having a number of new additional entries like
> > >
> > > ../message_ch10
> > > ../message_ch13
> > > ../message_poll
> > >
> > > we could design a sort of API (in the API :D) that defines how
> > > 3-bytes message payload are to be interpreted, so that in normal usage
> > > everything will go on as it is now, while if a 3-bytes message is
> > > injected by a specially crafted testcase, it would be used to configure
> > > the behaviour stack for the subsequent set of Raw transactions
> > > (i.e. for the currently opened fd...) like:
> > >
> > > - open message fd
> > >
> > > - send a configure message:
> > >
> > > | proto_chan_# | flags (polling..) |
> > > ------------------------------------------
> > > 0 7 21
> > >
> > > - send/receive your test messages
> > >
> > > - repeat or close (then the config will vanish...)
> > >
> > > This would mean adding some sort entry under scmi_raw to expose the
> > > configured available channels on the system though.
> > >
> > > [maybe the flags above could also include an async flag and avoid
> > > also to add the message_async entries...]
> > >
> > > I discarded the idea to run the above config process via IOCTLs since
> > > it seemed to me even more frowned upon to use IOCTLs on a debugfs entry
> > > :P...but I maybe wrong ah...
> > >
> > > All of this is still to be explored anyway, any thoughts ? or evident
> > > drawbacks ? (beside having to clearly define an API for these message
> > > config machinery)
> >
> > TBH, I'm not a fan of adding a protocol on top of the SCMI one. This
> > interface aims to test the SCMI servers and their channels so we
> > should focus on this and make it simple to use. IMHO, adding some
> > special bytes before the real scmi message is prone to create
> > complexity and error in the use of this debug interface.
> >
>
> Indeed, even if only for transport-related tests, the risk is to make
> more complicate to use the interface.
>
> Agreed, just wanted to have some feedback. I'll revert to some based on
> debugfs trying to minimize entries and improper usage...maybe something
> like grouping on per-channel subdirs when different channels are
> available.
>
> E.g. on a system with a dedicated PERF channel I could have
>
>
> ../scmi_raw/0/message <<< usual auto channel selection
> /message_async
> ...
>
> /chan_0x10/message <<< use default channel (base proto)
> /message_async
> ....
>
> /chan_0x13/message <<< use PERF channel
> /message_async
> ....
The proposal above looks good for me
Thanks
>
> The alternative would be to have a common single entry to configure the usage
> of the a single batch of message/message_async entries BUT that seems to
> me more prone to error, e.g. if you dont clear the special config at the
> end of your special testcase you could endup using custom channels conf also
> with any following regular test which expects to benefit from the
> automatic channel selection (which I still think should be default way of
> running these tests..)
>
> Thoughts ?
>
> Thanks for the feedback.
> Cristian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
2022-10-29 2:38 ` Florian Fainelli
@ 2022-11-03 11:21 ` Sudeep Holla
-1 siblings, 0 replies; 50+ messages in thread
From: Sudeep Holla @ 2022-11-03 11:21 UTC (permalink / raw)
To: Florian Fainelli
Cc: Cristian Marussi, linux-kernel, linux-arm-kernel, james.quinlan,
Jonathan.Cameron, etienne.carriere, vincent.guittot,
souvik.chakravarty, wleavitt, peter.hilber, nicola.mazzucato,
tarek.el-sherbiny, quic_kshivnan, Sudeep Holla
On Fri, Oct 28, 2022 at 07:38:25PM -0700, Florian Fainelli wrote:
> Hi Christian,
>
> On 10/19/2022 1:46 PM, Cristian Marussi wrote:
> [snip]
>
> > In V2 the runtime enable/disable switching capability has been removed
> > (for now) since still not deemed to be stable/reliable enough: as a
> > consequence when SCMI Raw support is compiled in, the regular SCMI stack
> > drivers are now inhibited permanently for that Kernel.
>
> For our platforms (ARCH_BRCMSTB) we would need to have the ability to start
> with the regular SCMI stack to satisfy if nothing else, all clock consumers
> otherwise it makes it fairly challenging for us to boot to a prompt as we
> purposely turn off all unnecessary peripherals to conserve power. We could
> introduce a "full on" mode to remove the clock provider dependency, but I
> suspect others on "real" silicon may suffer from the same short comings.
>
Fair enough. But if we are doing SCMI firmware testing or conformance via
the $subject proposed way, can these drivers survive if the userspace do
a random or a torture test changing the clock configurations ? Not sure
how to deal with that as the intention here is to do the testing from the
user-space and anything can happen. How do we avoid bring the entire system
down while doing this testing. Can we unbind all the drivers using scmi on
your platform ? I guess no. Let me know.
> Once user-space is reached, I suppose we could find a way to unbind from all
> SCMI consumers, and/or ensure that runtime PM is disabled, cpufreq is in a
> governor that won't do any active frequency switching etc.
>
> What do you think?
Yes, Cristian always wanted to support that but I am the one trying to
convince him not to unless there is a strong requirement for it. You seem
to suggest that you have such a requirement, but that just opens loads of
questions and how to we deal with that. Few of them are as stated above, I
need to recall all the conversations I had with Cristian around that and why
handling it may be bit complex.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
@ 2022-11-03 11:21 ` Sudeep Holla
0 siblings, 0 replies; 50+ messages in thread
From: Sudeep Holla @ 2022-11-03 11:21 UTC (permalink / raw)
To: Florian Fainelli
Cc: Cristian Marussi, linux-kernel, linux-arm-kernel, james.quinlan,
Jonathan.Cameron, etienne.carriere, vincent.guittot,
souvik.chakravarty, wleavitt, peter.hilber, nicola.mazzucato,
tarek.el-sherbiny, quic_kshivnan, Sudeep Holla
On Fri, Oct 28, 2022 at 07:38:25PM -0700, Florian Fainelli wrote:
> Hi Christian,
>
> On 10/19/2022 1:46 PM, Cristian Marussi wrote:
> [snip]
>
> > In V2 the runtime enable/disable switching capability has been removed
> > (for now) since still not deemed to be stable/reliable enough: as a
> > consequence when SCMI Raw support is compiled in, the regular SCMI stack
> > drivers are now inhibited permanently for that Kernel.
>
> For our platforms (ARCH_BRCMSTB) we would need to have the ability to start
> with the regular SCMI stack to satisfy if nothing else, all clock consumers
> otherwise it makes it fairly challenging for us to boot to a prompt as we
> purposely turn off all unnecessary peripherals to conserve power. We could
> introduce a "full on" mode to remove the clock provider dependency, but I
> suspect others on "real" silicon may suffer from the same short comings.
>
Fair enough. But if we are doing SCMI firmware testing or conformance via
the $subject proposed way, can these drivers survive if the userspace do
a random or a torture test changing the clock configurations ? Not sure
how to deal with that as the intention here is to do the testing from the
user-space and anything can happen. How do we avoid bring the entire system
down while doing this testing. Can we unbind all the drivers using scmi on
your platform ? I guess no. Let me know.
> Once user-space is reached, I suppose we could find a way to unbind from all
> SCMI consumers, and/or ensure that runtime PM is disabled, cpufreq is in a
> governor that won't do any active frequency switching etc.
>
> What do you think?
Yes, Cristian always wanted to support that but I am the one trying to
convince him not to unless there is a strong requirement for it. You seem
to suggest that you have such a requirement, but that just opens loads of
questions and how to we deal with that. Few of them are as stated above, I
need to recall all the conversations I had with Cristian around that and why
handling it may be bit complex.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
2022-11-03 11:21 ` Sudeep Holla
@ 2022-11-03 12:06 ` Cristian Marussi
-1 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-11-03 12:06 UTC (permalink / raw)
To: Sudeep Holla
Cc: Florian Fainelli, linux-kernel, linux-arm-kernel, james.quinlan,
Jonathan.Cameron, etienne.carriere, vincent.guittot,
souvik.chakravarty, wleavitt, peter.hilber, nicola.mazzucato,
tarek.el-sherbiny, quic_kshivnan
On Thu, Nov 03, 2022 at 11:21:47AM +0000, Sudeep Holla wrote:
> On Fri, Oct 28, 2022 at 07:38:25PM -0700, Florian Fainelli wrote:
> > Hi Christian,
> >
> > On 10/19/2022 1:46 PM, Cristian Marussi wrote:
> > [snip]
> >
> > > In V2 the runtime enable/disable switching capability has been removed
> > > (for now) since still not deemed to be stable/reliable enough: as a
> > > consequence when SCMI Raw support is compiled in, the regular SCMI stack
> > > drivers are now inhibited permanently for that Kernel.
> >
> > For our platforms (ARCH_BRCMSTB) we would need to have the ability to start
> > with the regular SCMI stack to satisfy if nothing else, all clock consumers
> > otherwise it makes it fairly challenging for us to boot to a prompt as we
> > purposely turn off all unnecessary peripherals to conserve power. We could
> > introduce a "full on" mode to remove the clock provider dependency, but I
> > suspect others on "real" silicon may suffer from the same short comings.
> >
>
> Fair enough. But if we are doing SCMI firmware testing or conformance via
> the $subject proposed way, can these drivers survive if the userspace do
> a random or a torture test changing the clock configurations ? Not sure
> how to deal with that as the intention here is to do the testing from the
> user-space and anything can happen. How do we avoid bring the entire system
> down while doing this testing. Can we unbind all the drivers using scmi on
> your platform ? I guess no. Let me know.
>
> > Once user-space is reached, I suppose we could find a way to unbind from all
> > SCMI consumers, and/or ensure that runtime PM is disabled, cpufreq is in a
> > governor that won't do any active frequency switching etc.
> >
> > What do you think?
>
> Yes, Cristian always wanted to support that but I am the one trying to
> convince him not to unless there is a strong requirement for it. You seem
> to suggest that you have such a requirement, but that just opens loads of
> questions and how to we deal with that. Few of them are as stated above, I
> need to recall all the conversations I had with Cristian around that and why
> handling it may be bit complex.
:D ... I really even more like the idea of enabling on demand full coexistence
so that I completely delegate to the users to manually deal with possible
interferences at runtime and drop any liabilities if someone shoots himself
in the foot :P
... jokes apart I'll post today a V5 with a few fixes and and an optional
coexistence mode so that Florian can experiment and see how much is feasible
to operate in this way by manually unbinding/re-configuring SCMI behaviour
at runtime before starting tests and not kill the system on something
like ARCH_BRCMSTB platforms.
Thanks,
Cristian
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
@ 2022-11-03 12:06 ` Cristian Marussi
0 siblings, 0 replies; 50+ messages in thread
From: Cristian Marussi @ 2022-11-03 12:06 UTC (permalink / raw)
To: Sudeep Holla
Cc: Florian Fainelli, linux-kernel, linux-arm-kernel, james.quinlan,
Jonathan.Cameron, etienne.carriere, vincent.guittot,
souvik.chakravarty, wleavitt, peter.hilber, nicola.mazzucato,
tarek.el-sherbiny, quic_kshivnan
On Thu, Nov 03, 2022 at 11:21:47AM +0000, Sudeep Holla wrote:
> On Fri, Oct 28, 2022 at 07:38:25PM -0700, Florian Fainelli wrote:
> > Hi Christian,
> >
> > On 10/19/2022 1:46 PM, Cristian Marussi wrote:
> > [snip]
> >
> > > In V2 the runtime enable/disable switching capability has been removed
> > > (for now) since still not deemed to be stable/reliable enough: as a
> > > consequence when SCMI Raw support is compiled in, the regular SCMI stack
> > > drivers are now inhibited permanently for that Kernel.
> >
> > For our platforms (ARCH_BRCMSTB) we would need to have the ability to start
> > with the regular SCMI stack to satisfy if nothing else, all clock consumers
> > otherwise it makes it fairly challenging for us to boot to a prompt as we
> > purposely turn off all unnecessary peripherals to conserve power. We could
> > introduce a "full on" mode to remove the clock provider dependency, but I
> > suspect others on "real" silicon may suffer from the same short comings.
> >
>
> Fair enough. But if we are doing SCMI firmware testing or conformance via
> the $subject proposed way, can these drivers survive if the userspace do
> a random or a torture test changing the clock configurations ? Not sure
> how to deal with that as the intention here is to do the testing from the
> user-space and anything can happen. How do we avoid bring the entire system
> down while doing this testing. Can we unbind all the drivers using scmi on
> your platform ? I guess no. Let me know.
>
> > Once user-space is reached, I suppose we could find a way to unbind from all
> > SCMI consumers, and/or ensure that runtime PM is disabled, cpufreq is in a
> > governor that won't do any active frequency switching etc.
> >
> > What do you think?
>
> Yes, Cristian always wanted to support that but I am the one trying to
> convince him not to unless there is a strong requirement for it. You seem
> to suggest that you have such a requirement, but that just opens loads of
> questions and how to we deal with that. Few of them are as stated above, I
> need to recall all the conversations I had with Cristian around that and why
> handling it may be bit complex.
:D ... I really even more like the idea of enabling on demand full coexistence
so that I completely delegate to the users to manually deal with possible
interferences at runtime and drop any liabilities if someone shoots himself
in the foot :P
... jokes apart I'll post today a V5 with a few fixes and and an optional
coexistence mode so that Florian can experiment and see how much is feasible
to operate in this way by manually unbinding/re-configuring SCMI behaviour
at runtime before starting tests and not kill the system on something
like ARCH_BRCMSTB platforms.
Thanks,
Cristian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
end of thread, other threads:[~2022-11-03 12:07 UTC | newest]
Thread overview: 50+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-19 20:46 [PATCH v4 0/11] Introduce a unified API for SCMI Server testing Cristian Marussi
2022-10-19 20:46 ` Cristian Marussi
2022-10-19 20:46 ` [PATCH v4 01/11] firmware: arm_scmi: Refactor xfer in-flight registration routines Cristian Marussi
2022-10-19 20:46 ` Cristian Marussi
2022-10-19 20:46 ` [PATCH v4 02/11] firmware: arm_scmi: Simplify chan_available transport operation Cristian Marussi
2022-10-19 20:46 ` Cristian Marussi
2022-10-19 20:46 ` [PATCH v4 03/11] firmware: arm_scmi: Use dedicated devices to initialize channels Cristian Marussi
2022-10-19 20:46 ` Cristian Marussi
2022-10-19 20:46 ` [PATCH v4 04/11] firmware: arm_scmi: Refactor polling helpers Cristian Marussi
2022-10-19 20:46 ` Cristian Marussi
2022-10-19 20:46 ` [PATCH v4 05/11] firmware: arm_scmi: Refactor scmi_wait_for_message_response Cristian Marussi
2022-10-19 20:46 ` Cristian Marussi
2022-10-19 20:46 ` [PATCH v4 06/11] firmware: arm_scmi: Add xfer raw helpers Cristian Marussi
2022-10-19 20:46 ` Cristian Marussi
2022-10-19 20:46 ` [PATCH v4 07/11] firmware: arm_scmi: Move errors defs and code to common.h Cristian Marussi
2022-10-19 20:46 ` Cristian Marussi
2022-10-19 20:46 ` [PATCH v4 08/11] firmware: arm_scmi: Add raw transmission support Cristian Marussi
2022-10-19 20:46 ` Cristian Marussi
2022-10-19 20:46 ` [PATCH v4 09/11] firmware: arm_scmi: Add debugfs ABI documentation for Raw mode Cristian Marussi
2022-10-19 20:46 ` Cristian Marussi
2022-10-19 20:46 ` [PATCH v4 10/11] firmware: arm_scmi: Reject SCMI drivers while in " Cristian Marussi
2022-10-19 20:46 ` Cristian Marussi
2022-10-19 20:46 ` [PATCH v4 11/11] firmware: arm_scmi: Call Raw mode hooks from the core stack Cristian Marussi
2022-10-19 20:46 ` Cristian Marussi
2022-10-28 14:40 ` [PATCH v4 0/11] Introduce a unified API for SCMI Server testing Vincent Guittot
2022-10-28 14:40 ` Vincent Guittot
2022-10-28 15:03 ` Cristian Marussi
2022-10-28 15:03 ` Cristian Marussi
2022-10-28 16:18 ` Vincent Guittot
2022-10-28 16:18 ` Vincent Guittot
2022-10-28 16:58 ` Cristian Marussi
2022-10-28 16:58 ` Cristian Marussi
2022-11-02 8:54 ` Vincent Guittot
2022-11-02 8:54 ` Vincent Guittot
2022-11-03 9:21 ` Cristian Marussi
2022-11-03 9:21 ` Cristian Marussi
2022-11-03 10:58 ` Vincent Guittot
2022-11-03 10:58 ` Vincent Guittot
2022-10-28 14:44 ` Florian Fainelli
2022-10-28 14:44 ` Florian Fainelli
2022-10-28 15:23 ` Cristian Marussi
2022-10-28 15:23 ` Cristian Marussi
2022-10-29 2:38 ` Florian Fainelli
2022-10-29 2:38 ` Florian Fainelli
2022-10-29 11:14 ` Cristian Marussi
2022-10-29 11:14 ` Cristian Marussi
2022-11-03 11:21 ` Sudeep Holla
2022-11-03 11:21 ` Sudeep Holla
2022-11-03 12:06 ` Cristian Marussi
2022-11-03 12:06 ` Cristian Marussi
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.