Re: [PATCH v3 5/9] firmware: arm_scmi: Make use of FastChannels configurable

[Cristian Marussi]

On Fri, Jul 01, 2022 at 03:03:07PM +0100, Sudeep Holla wrote:
> On Mon, Jun 27, 2022 at 01:30:34PM +0100, Cristian Marussi wrote:
> > Add a Kernel configuration entry used to optionally disable, globally, the
> > usage of SCMI FastChannels even on platforms where they are available.
> > 
> > Make such option default-no to preserve the original SCMI system behaviour
> > of using any available FC.
> > 
> > Signed-off-by: Cristian Marussi <cristian.marussi@xxxxxxx>
> > ---
> > v2 --> v3
> > - fixed wording in Kconfig
> > - reverted Kconfig logic _USE_ -> _AVOID_
> > ---
> >  drivers/firmware/arm_scmi/Kconfig  | 13 +++++++++++++
> >  drivers/firmware/arm_scmi/driver.c |  6 ++++++
> >  2 files changed, 19 insertions(+)
> > 
> > diff --git a/drivers/firmware/arm_scmi/Kconfig b/drivers/firmware/arm_scmi/Kconfig
> > index 1e7b7fec97d9..3fb34db01014 100644
> > --- a/drivers/firmware/arm_scmi/Kconfig
> > +++ b/drivers/firmware/arm_scmi/Kconfig
> > @@ -42,6 +42,19 @@ config ARM_SCMI_HAVE_MSG
> >  	  This declares whether a message passing based transport for SCMI is
> >  	  available.
> >  
> > +config ARM_SCMI_AVOID_FASTCHANNELS
> > +	bool "Avoid using SCMI FastChannels even when available"
> 
> Without default, won't this prompt user now ? I would have explicit default n
> if we are adding this. But why do we need this is my question ? This would
> be a quirk IMO on systems where FC is broken. I don't want people to enable
> this during testing and ship f/w with FC broken(or not developed yet).
> 
> We can add this if some platforms really need this as a quirk in the future.
>

Ah ok an explicit default no is better indeed to avoid prompting if you
do not defconfig (I missed this difference between default implicit NO
and explicit NO) ...

... regarding why, I am using personally this indeed for testing with or
without FCs without having to change the installed FW blob, BUT the reason
for upstreaming such an option is that FC support is indeed optional by the
spec so I thought it would have been acceptabel that you could want to
configure a platform NOT to use them even though the FW implementation you
are using, maybe across multiple platforms, supports it.

Thanks,
Cristian