Re: [RFC v2 5/8] xen/arm: introduce SCMI-SMC mediator driver

[Oleksii Moisieiev <Oleksii_Moisieiev@xxxxxxxx>]

Hi Stefano,

On Mon, Feb 14, 2022 at 02:05:18PM -0800, Stefano Stabellini wrote:
> On Mon, 14 Feb 2022, Oleksii Moisieiev wrote:
> > Hi Bertrand,
> > 
> > On Mon, Feb 14, 2022 at 11:27:21AM +0000, Bertrand Marquis wrote:
> > > Hi Oleksii,
> > > 
> > > > On 14 Feb 2022, at 11:13, Oleksii Moisieiev 
> > > > <Oleksii_Moisieiev@xxxxxxxx> wrote:
> > > > 
> > > > Hi Julien,
> > > > 
> > > > On Sat, Feb 12, 2022 at 12:43:56PM +0000, Julien Grall wrote:
> > > >> Hi,
> > > >> 
> > > >> On 11/02/2022 11:18, Bertrand Marquis wrote:
> > > >>> Do you plan to add support for other boards ?
> > > >>> 
> > > >>> Did you discuss more in general with the linux kernel guys to see if 
> > > >>> this
> > > >>> approach was agreed and will be adopted by other manufacturers ?
> > > >>> 
> > > >>> All in all I think this is a good idea but I fear that all this will 
> > > >>> actually only
> > > >>> be used by one board or one manufacturer and other might use a 
> > > >>> different
> > > >>> strategy, I would like to unrisk this before merging this in Xen.
> > > >> 
> > > >> In the past we merged code that would only benefits one vendor (i.e. 
> > > >> EEMI).
> > > >> That said, this was a vendor specific protocol. I believe the 
> > > >> situation is
> > > >> different here because the spec is meant to be generic.
> > > >> 
> > > >>> @julien and Stefano: what is your view here ?
> > > >> 
> > > >> I share the same concerns as you. I think we need to make sure all the
> > > >> pieces we rely on (e.g. firmware, DT bindings) have been agreed before 
> > > >> we
> > > >> can merge such code in Xen.
> > > >> 
> > > >> The first step is to have all the pieces available in public so they 
> > > >> can be
> > > >> reviewed and tested together.
> > > >>
> > > >> Oleksii, on a separate e-mail, you said you made change for ATF. How 
> > > >> much of
> > > >> those changes was related to support for Xen? If they are some, then I 
> > > >> think
> > > >> they should be upstreamed first.
> > > >> 
> > > > 
> > > > Let me share changes, that were done to AT-F and Linux kernel
> > > > device-tree in terms of the SCMI mediator POC.
> > > > Changes to the Linux kernel:
> > > > https://urldefense.com/v3/__https://github.com/oleksiimoisieiev/arm-trusted-firmware/pull/4__;!!GF_29dbcQIUBPA!je9Cu0n0498Yn76OLWjxxVaB7jWJtyWycHX0YARezTnc7aYHpGRJ8tSxHqIC0fTMUUSV$
> > > >  [github[.]com]
> > > > Based on renesas-rcar linux-bsp, branch v5.10/rcar-5.0.0.rc5
> > > > 
> > > > Changes to AT-F:
> > > > https://urldefense.com/v3/__https://github.com/oleksiimoisieiev/linux-bsp/pull/3__;!!GF_29dbcQIUBPA!je9Cu0n0498Yn76OLWjxxVaB7jWJtyWycHX0YARezTnc7aYHpGRJ8tSxHqIC0eDKS3ge$
> > > >  [github[.]com]
> > > > Based on renesas-rcar/arm-trusted-firmware branch rcar_gen3_v2.5.
> > > 
> > > You inverted the links but thanks this is really useful.
> > > 
> > 
> > That's strange. Links looks good from xen.markmail.org interface.
> > 
> > > Did you push the ATF changes to mainstream ATF or discuss those with
> > > the maintainers ?
> > 
> > No. We did changes in ATF as a proof of concept.
> > 
> > > 
> > > The strategy overall is nice but we need to make sure this is accepted and
> > >  merged by all parties (ATF and Linux) to make sure the support for this 
> > > will
> > > not only be available in Xen and for one board.
> 
> +1
> 
> 
> > I've prepared patch to Linux kernel, which is introducing scmi_devid
> > binding, needed to set device permissions via SCMI. I've contacted
> > Sudeep Holla <sudeep.holla@xxxxxxx>, who is the maintainer of the SCMI 
> > protocol
> > drivers. Waiting for the response.
> > 
> > Changes to ATF are not Xen specific and were done in terms of POC. We do
> > not have plans to upstream those changes right now.
> 
> If this work relies on a new interface in ATF, and the interface is not
> vendor-specific, then at least the interface (if not the code) should be
> reviewed and accepted by ATF.
> 
> Otherwise we risk ending up with an upstream SCMI implementation in Xen
> that cannot be used anywhere, except the PoC. To make things worse, this
> could happen:
> 
> - we upstream the SCMI mediator to Xen
> - we upstream any required changes to Linux
> - ATF rejects the SCMI-related interface changes
> - ATF comes up with a difference interface
> 
> At this point we would have to deprecate the implementation in Xen. It
> might also be difficult to do so due to versioning issues. We would
> need to be able to detect which version of ATF we are running on, to
> distinguish the ATF PoC version that works with the old interface from
> the new ATF version that supports a different interface.
> 
> To avoid this kind of issues we typically expect that all relevant
> communities agree on the public interfaces before upstreaming the code.

That's sound reasonable.
I'll contact with AT-F maintainers. Maybe I'll be able to upstream SCMI
to AT-F.
Also I hope I'll be able to contact Linux kernel SCMI maintainers and
discuss device-tree structure.

Best regards,
Oleksii