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

From: Cristian Marussi <cristian.marussi@arm.com>
To: Mark Brown <broonie@kernel.org>
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 15:21:20 +0100	[thread overview]
Message-ID: <Yvz5YLh41gWLmPSa@e120937-lin> (raw)
In-Reply-To: <YvzwUPGmZPFAzw07@sirena.org.uk>

On Wed, Aug 17, 2022 at 02:42:40PM +0100, Mark Brown wrote:
> 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.

Indeed Sudeep had the same concerns and when I tested this with a dummy
driver using an SCMI clock I could see that the disappearing clock was
seemingly handled safely by the clock framework, but this is just one
of the possibly involved framework, I cannot be so sure about all the
others and any future frmk that will have to interact with this dynamic
unplugging...so at the end probably is not worth the effort as you are
saying...I'll most probably drop this next....

Thanks a lot for your feedback.
Cristian

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