Messages in this thread | | | Date | Wed, 17 Aug 2022 09:38:57 +0100 | From | Cristian Marussi <> | Subject | Re: [RFC PATCH 5/6] firmware: arm_scmi: Add raw transmission support |
| |
On Tue, Aug 16, 2022 at 07:03:21PM +0100, Mark Brown wrote: > On Tue, Aug 16, 2022 at 08:24:49AM +0100, Cristian Marussi wrote: > > Add SCMI Raw mode support which exposes a userspace interface rooted under > > /sys/kernel/debug/scmi_raw.
Hi Mark,
thanks for having a look.
> > > Raw mode can be enabled/disabled at runtime via ./scmi_raw/enable. > > Once enabled, all the regular SCMI drivers activity is inhibited and a > > userspace application can then inject and read back bare SCMI messages > > writing and reading to/from ./scmi_raw/message* entries. > > Is there a strong reason to have the runtime enable/disable? Given that > this is going to be used in special kernel builds rather than something > people have as standard it feels like the transition to/from raw mode is > opening up a set of extra use cases that wouldn't normally come up for > the SCMI drivers (especially if the testing ends up leaving the firmware > in a weird state).
The rationale for this dynamic runtime switch was to try to have a system that can be configured for SCMI FW testing BUT not necessarily specifically only for such SCMI tests...IOW a system that can be used in CI to run a number of other test suites (while in normal mode) and then switched to raw mode only when SCMI compliance tests are to be run.
Indeed, the enable/disable thing is the main critical point of this RFC since especially the disable-and-back-to-normal transition proved to be potentially problematic...i.e. the system generally works in my setup but it cannot be guaranteed to really bring back the system in a fully functional state depending on how complex the driver stack is (..beside the potential FW final weird state issue as you rightly pointed out)
...moreover at the end the whole disable and go-back-to-normal really makes little sense in a typical CI scenario where anyway the system under test is most probably rebooted between runs of different test suites, so we really do not care about any weird final state probably.
I, nonetheless, posted this RFC with this such support, at first to have some general feedback, BUT also because I'm still anyway wondering if it would not be worth to keep at least the capability to only enable it at run-time (dropping the disable-back-to-normal feat), because this would enable to build an image which includes this SCMI Raw support, which is default disabled, and that can at will enabled at runtime only on selected runs, so that this same test-image could still be used in a number of different CI test-runs (keeping raw mode disabled and silent) but also then used for a specific SCMI testing run that would eventually enable it.
If this is not worth really I can just drop the whole runtime switch thing and stick to the more conservative approach of having a dedicated image for this kind of SCMI FW testing: a system that once configured at compile time with this, it just cannot use at all the regular SCMI stack (...which does NOT necessarily prevent the system to boot and be used for other non SCMI testing indeed...it would just be probably slower...)
Any thought ?
Thanks, Cristian
| |