Re: [RFC v1 3/5] xen/arm: introduce SCMI-SMC mediator driver

[Julien Grall <julien@xxxxxxx>]

On 24/12/2021 14:59, Oleksii Moisieiev wrote:
> Hi Julien,
Hello,

> On Fri, Dec 24, 2021 at 02:29:13PM +0100, Julien Grall wrote:
> > Hi,
> >
> > On 24/12/2021 01:16, Stefano Stabellini wrote:
> > > > One more question: As you probably seen - Jan had a complains about SCI
> > > > term. He said SCI is ambiguous with ACPI's System
> > > > Control Interrupt.
> > > I see his point. As a term I see "SCMI" often and sometimes "SCPI" but
> > > "SCI" is the first time I saw it with this patch series.
> > >
> > >
> > > > I think of using SC (as System Control) instead. What do you think
> > > > about it?
> > > Yeah, I am not great at naming things but maybe "ARM_SCI"?  "SC" alone
> > > doesn't give me enough context to guess what it is.
> > I might be missing some context. Why are naming everything SCI rather than
> > SMCI?
> Because we're expecting other interfaces and transport to be
> implemented, such as for example:
> scmi_mailbox, scpi_smc, scpi_mailbox, ti_sci_smc etc.
Oh, now that explain why there is a layer of indirection in Xen. It 
wasn't very clear from the cover letter why it was present.
> > > Or we could broaden the scope and call it "firmware_interface"?
> > How would this be used? Will it be a list of interface that will be exposed
> > to the guest?
> The idea is to set mediator type for each Domain, so for example Xen can
> use scmi_mailbox to communicate with SCP, Dom0 and DomD are also using
> scmi_mailbox, but DomU using scmi_smc mediator because we have only 3
> mailboxes in system. This is not implemented yet, right now, we are
> introducing only scmi_smc support. In future, multiple mediator support
> can be added to Xen.
Ok. So will there be only one interface at the time for a given domain. 
Is that correct?
Cheers,

--
Julien Grall