[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <645ffd03-b49d-9e6e-7541-21c11eab0aef@gmail.com>
Date: Fri, 28 Oct 2022 07:44:32 -0700
From: Florian Fainelli <f.fainelli@...il.com>
To: Cristian Marussi <cristian.marussi@....com>,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Cc: sudeep.holla@....com, james.quinlan@...adcom.com,
Jonathan.Cameron@...wei.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 v4 0/11] Introduce a unified API for SCMI Server testing
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
Powered by blists - more mailing lists