Re: [RFC PATCH 0/1] dt-bindings: arm: Add scmi_devid paramter for

[Sudeep Holla]

(sorry for the delay, had to move my email setup and some mails were
stuck in outbox and I missed to notice)

On Thu, Feb 24, 2022 at 03:34:01PM -0800, Stefano Stabellini wrote:
> On Thu, 24 Feb 2022, Stefano Stabellini wrote:
> > On Thu, 24 Feb 2022, Sudeep Holla wrote:
> > > On Tue, Feb 22, 2022 at 05:15:49PM +0000, Oleksii Moisieiev wrote:
> > > > Hi Sudeep,
> > > > 
> > > > On Tue, Feb 22, 2022 at 04:06:37PM +0000, Sudeep Holla wrote:
> > > > > Hi Oleksii,
> > > > > 
> > > > > My initial feedback on this. And thanks Cristian for making it so easy as
> > > > > you have covered most of the things in depth(which I might have not done
> > > > > myself that well)
> > > > > 
> > > > > On Tue, Feb 22, 2022 at 11:00:03AM +0000, Cristian Marussi wrote:
> > > > > > On Mon, Feb 21, 2022 at 05:26:46PM +0000, Oleksii Moisieiev wrote:
> > > > > > > Introducing new parameter called scmi_devid to the device-tree bindings.
> > > > > > > This parameter should be set for the device nodes, which has
> > > > > > > clocks/power-domains/resets working through SCMI.
> > > > > 
> > > > > I prefer you had given more details on your usage model here instead of
> > > > > pointing to the other Xen thread as it helps for someone without much
> > > > > background on Xen or your use-case to review this.
> > > > > 
> > > > Let me describe the process in few words:
> > > > We implemented a new feature, called SCI-mediator in Xen.
> > > > The proposed implementation allows Guests to communicate with the Firmware using SCMI
> > > > protocol with SMC as a transport. Other implementation are also
> > > > possible, such as SCMI-Mailbox, SCPI-mailbox etc.
> > > > 
> > > > In this feature Xen is the Trusted Agent, which receives the following
> > > > information in Xen device-tree:
> > > > 1) All channels should be described, each channel defined as
> > > > arm,scmi-shmem node;
> > > > 2) Scmi node arm,scmi-smc with protocols description;
> > > 
> > > Sounds good so far.
> > > 
> > > > 3) scmi-devid should be set in nodes, which works through SCMI.
> > > >
> > > 
> > > Why is this needed for Guest OS, you need not populate this if Guest OS
> > > is not required to use it, right ? If it is needed just by Xen hypervisor,
> > > lets talk about that and why it is bad idea to mix that with general
> > > SCMI bindings.
> > 
> > I'll try to help Oleksii by answering here, I hope I am not off the mark
> > :-)
> > 
> > I think Sudeep is right, scmi-devid is not needed by the guest OS.
> > 
> > The host device tree is a more interesting discussion. As the host
> > device tree is meant to be generic and not tied to a specific version of
> > Linux, it should fully describe the SCMI interface available. If the
> > device tree is provided to a Trusted Agent, then it should also have the
> > scmi-devid information, right?
> > 
> > 
> > > > On start Xen inits itself as trusted agent and requests agent
> > > > configuration by using BASE_DISCOVER_AGENT message. This message is sent
> > > > to each configured channel to get agent_id
> > > > 
> > > > On Domain creation stage Xen will do the following steps:
> > > > 1) Assign channel to the Guest and map channel address to the Domain
> > > > address. For the Domain this address should be the same;
> > > > 2) Generate arm,scmi-shmem and arm,scmi-smc nodes if needed for Guest
> > > > device-tree (the device-tree which should be passed to the Guest);
> > > > 3) Process devices, which are passed through to this Guest and set
> > > > BASE_SET_DEVICE_PERMISSIONS for the scmi-devid, received from the
> > > > device-node;
> > > >
> > > 
> > > I am confused here. So the Xen knows which devices are assigned to each
> > > Guest OS but doesn't know device ID for them, but relies on the device
> > > tree node ?
> > 
> > Which devices go to which guest OS is a user-provided configuration. For
> > instance, a user can say: "assing /amba/ethernet@ff0e0000 to dom1". This
> > is normal and not related to SCMI: when a user configures a static
> > partitioning system, they decide which resources belong to which domain.
> > 
> > So Xen is told that /amba/ethernet@ff0e0000 is supposed to go to dom1.
> > Xen proceeds to map memory and interrupts corresponding to
> > /amba/ethernet@ff0e0000 to dom1. So far so good. What about SCMI?
> > 
> > In Oleksii's design, Xen is going to assign one of the available SCMI
> > channels to dom1 and restrict its permission to only
> > /amba/ethernet@ff0e0000. To do that, Xen needs to know the scmi-devid of
> > /amba/ethernet@ff0e0000. As far as I can tell there is nothing
> > Xen-specific in this activitity, that's why I asked Oleksii to reach out
> > to the upstream device tree community to improve the generic bindings
> > for everyone's benefits.
> 
> Let's leave Linux and Xen aside for the moment. What are other possible
> Trusted Agents? (Maybe TF-A?) How do they get the scmi-devid? It looks
> like it was supposed to come from device tree but nobody got around to
> adding it to the binding because it is not used by Linux?

I do agree we need this info and probably device tree is the way. But what
I disagree here is that it needs to part of existing SCMI bindings which are
for the SCMI users only and not for one that may provide the interface(SCMI
platform/server/arbitrator/passthrough/..whatever). You can have bindings for
them as part of system device tree initiative and can be merged back to Linux
if that happens. Or we may even take the whole devicetree bindings out of
the Linux one day (when all the stars are aligned :) )

--
Regards,
Sudeep