Re: [RFC PATCH 5/6] firmware: arm_scmi: Add raw transmission support

From: Mark Brown <broonie@kernel.org>
To: Cristian Marussi <cristian.marussi@arm.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, sudeep.holla@arm.com,
	james.quinlan@broadcom.com, Jonathan.Cameron@huawei.com,
	f.fainelli@gmail.com, etienne.carriere@linaro.org,
	vincent.guittot@linaro.org, souvik.chakravarty@arm.com,
	wleavitt@marvell.com, peter.hilber@opensynergy.com,
	nicola.mazzucato@arm.com, tarek.el-sherbiny@arm.com
Subject: Re: [RFC PATCH 5/6] firmware: arm_scmi: Add raw transmission support
Date: Wed, 17 Aug 2022 14:42:40 +0100	[thread overview]
Message-ID: <YvzwUPGmZPFAzw07@sirena.org.uk> (raw)
In-Reply-To: <YvypBAnzjKvHBEzi@e120937-lin>

[-- Attachment #1.1: Type: text/plain, Size: 1786 bytes --]

On Wed, Aug 17, 2022 at 09:38:57AM +0100, Cristian Marussi wrote:

> ...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.

The enable usecase does indeed make more sense, though I'd still worry
about other code having problems with the SCMI support getting
hotplugged out from underneath it since that isn't a thing that happens
in practical systems.  For example the archrandom code is going to get
confused since it probes once to see if SMCCC TRNG support is available
and if it's present sets a flag which it assumes will be true for the
rest of system runtime.  I don't entirely know how the image build costs
play off here for the people who'd actually be running these tests, but
my instinct is that the extra kernel build isn't really much in the
grand scheme of things compared to shaking out the consequences of a
runtime switch and the costs of actually running the tests.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel