linux-kernel - Re: [PATCH v6 17/17] firmware: arm_scmi: Add per-channel Raw injection support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y78qa9IBKUE7MZWO@e120937-lin>
Date:   Wed, 11 Jan 2023 21:30:34 +0000
From:   Cristian Marussi <cristian.marussi@....com>
To:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Cc:     sudeep.holla@....com, james.quinlan@...adcom.com,
        Jonathan.Cameron@...wei.com, f.fainelli@...il.com,
        etienne.carriere@...aro.org, vincent.guittot@...aro.org,
        souvik.chakravarty@....com, wleavitt@...vell.com,
        peter.hilber@...nsynergy.com, nicola.mazzucato@....com,
        tarek.el-sherbiny@....com, quic_kshivnan@...cinc.com
Subject: Re: [PATCH v6 17/17] firmware: arm_scmi: Add per-channel Raw
 injection support

On Thu, Dec 29, 2022 at 06:22:53PM +0000, Cristian Marussi wrote:
> On a system configured with multiple transport channels, expose a few
> additional debugfs per-channel entries to allow a user to explicitly select
> which transport channel to use for the SCMI message injection.
> 
> Signed-off-by: Cristian Marussi <cristian.marussi@....com>
> ---
>  Documentation/ABI/testing/debugfs-scmi-raw |  43 +++++++
>  drivers/firmware/arm_scmi/driver.c         |  30 ++++-
>  drivers/firmware/arm_scmi/protocols.h      |   3 +
>  drivers/firmware/arm_scmi/raw_mode.c       | 142 ++++++++++++++++++---
>  drivers/firmware/arm_scmi/raw_mode.h       |   3 +-
>  5 files changed, 201 insertions(+), 20 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/debugfs-scmi-raw b/Documentation/ABI/testing/debugfs-scmi-raw
> index 45817d465b1f..5468ec08c084 100644
> --- a/Documentation/ABI/testing/debugfs-scmi-raw
> +++ b/Documentation/ABI/testing/debugfs-scmi-raw
> @@ -64,3 +64,46 @@ Description:	SCMI Raw stack reset facility; writing a value to this entry
>  		Can be used to reset and clean the SCMI Raw stack between to
>  		different test-run.
>  Users:		Debugging, any userspace test suite
> +
> +What:		/sys/kernel/debug/scmi/<n>/raw/channels/<m>/message
> +Date:		March 2023
> +KernelVersion:	6.3
> +Contact:	cristian.marussi@....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 for instance <n> through the <m> transport
> +		channel.
> +		Any subsequently received response can be read from this same
> +		entry if it arrived on channel <m> 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).
> +		Note that these per-channel entries rooted at <..>/channels
> +		exist only if the transport is configured to have more than
> +		one channel.
> +Users:		Debugging, any userspace test suite
> +
> +What:		/sys/kernel/debug/scmi/<n>/raw/channels/<m>/message_async
> +Date:		March 2023
> +KernelVersion:	6.3
> +Contact:	cristian.marussi@....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 for instance <n> through the <m> transport
> +		channel.
> +		Any subsequently received response can be read from this same
> +		entry if it arrived on channel <m> 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).
> +		Note that these per-channel entries rooted at <..>/channels
> +		exist only if the transport is configured to have more than
> +		one channel.
> +Users:		Debugging, any userspace test suite
> diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> index da60f218aed9..2d7e669d6dc4 100644
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -42,6 +42,8 @@
>  #define CREATE_TRACE_POINTS
>  #include <trace/events/scmi.h>
>  
> +#define SCMI_MAX_CHANNELS	256
> +
>  static DEFINE_IDA(scmi_id);
>  
>  static DEFINE_IDR(scmi_protocols);
> @@ -127,6 +129,8 @@ struct scmi_debug_info {
>   * @handle: Instance of SCMI handle to send to clients
>   * @tx_minfo: Universal Transmit Message management info
>   * @rx_minfo: Universal Receive Message management info
> + * @channels: The list of configured channels.
> + * @num_chans: Number of channels described in @channels
>   * @tx_idr: IDR object to map protocol id to Tx channel info pointer
>   * @rx_idr: IDR object to map protocol id to Rx channel info pointer
>   * @protocols: IDR for protocols' instance descriptors initialized for
> @@ -162,6 +166,8 @@ struct scmi_info {
>  	struct scmi_handle handle;
>  	struct scmi_xfers_info tx_minfo;
>  	struct scmi_xfers_info rx_minfo;
> +	unsigned int channels[SCMI_MAX_CHANNELS];
> +	int num_chans;

I have a small rework for V7 to get rid of these channels/num_chans
additional fields that are un-needed and can be retrieved dynamically
when raw mode is initialized.

Thanks,
Cristian