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_moisie...@epam.com> 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.ho...@arm.com>, 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
