Hi Krzysztof,
On Tue, Feb 22, 2022 at 09:06:25AM +0100, Krzysztof Kozlowski wrote:
> On 21/02/2022 22:39, Oleksii Moisieiev wrote:
> > Hi Krzysztof,
> >
> > On Mon, Feb 21, 2022 at 10:01:43PM +0100, Krzysztof Kozlowski wrote:
> >> On 21/02/2022 18:26, 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.
> >>> Given parameter should set the device_id, needed to set device
> >>> permissions in the Firmware. This feature will be extremely useful for
> >>> the virtualized systems, which has more that one Guests running on the
> >>> system at the same time or for the syestems, which require several
> >>> agents with different permissions. Trusted agent will use scmi_devid to
> >>> set the Device permissions for the Firmware (See Section 4.2.2.10 [0]
> >>> for details).
> >>> Agents concept is described in Section 4.2.1 [0].
> >>>
> >>> scmi_devid in Device-tree node example:
> >>> usb@e6590000
> >>> {
> >>> scmi_devid = <19>;
> >>> clocks = <&scmi_clock 3>, <&scmi_clock 2>;
> >>> resets = <&scmi_reset 10>, <&scmi_reset 9>;
> >>> power-domains = <&scmi_power 0>;
> >>> };
> >>
> >> And how do you prevent DT overlay adding such devid to any other node
> >> thus allowing any other device to send requests with given devid?
> >>
> > Thank you for the quick response.
> > scmi_devid value will be used only by Trusted Agent when the device
> > permissions are set. Non-trusted agents, which in our case are
> > represented as Guest OS are using scmi drivers, already present in linux
> > kernel, ignores scmi_devid and uses scmi_clocks, scmi_power, scmi_reset
> > nodes to access to SCMI protocol.
>
> Ah, ok.
>
> >
> >> Plus few technicalities:
> >> 1. Hyphen, not underscore in property name, so scmi-devid.
> >
> > Thanks for the tip, I will change that in v2.
>
> Few more thoughts:
> 1. This looks specific to ARM SCMI, so you also need vendor prefix, so
> something like:
> arm,scmi-devid
> arm,scmi-device-id
That's a good advice. arm,scmi-devid looks good for me.
>
> 2. Does your example work properly? Passes dt_binding_check? Reg looks
> different than unit-address.
>
dt_bindings_check passes without errors. Also I've checked this file
explicitly by using command:
yamllint -c Documentation/devicetree/bindings/.yamllint Documentation/devicetree/bindings/firmware/arm,scmi-devid.yaml
Reg value, if you mean reg parameter from an Example, was taken from
r8a77961.dtsi file.
>
> >
> >> 2. Your schema does is not selected by anything. How is it intended to
> >> be used? Nothing is including it, either...
> >>
> >
> > The idea is to use this parameter to set the device_id for the device in
> > the device-tree, which matches to the device mapping in the Firmware, so
> > Trusted Agent can use it to the device permissions.
> > Please see Sections 4.2.2.10 and 4.2.1 [0] (Link was provided in the
> > cover letter).
> >
> > I'm currently propose the new feature, called SCI mediator to Xen-devel
> > community. Please see link [1] from cover letter for the details.
> > In this feature - Xen is the Trusted Agent, which uses scmi_devid
> > parameter to set the device permissions.
> > We think that this parameter will be useful for other possible SCMI
> > implementations, such as other hypervisor or SCMI backend server etc.
>
> We talk about different things, I think. I was asking how is this schema
> selected?
>
> I gave it a fast try (dtbs_check) and it confirmed - schema does not
> have an effect. It's a noop. You need something like "select: true", see:
> Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml
> or this schema should be included by other schemas... but then I would
> be happy to see actual usage in this patchset (more commits...).
>
I think select: true will work for me. I'll do dtbs_check and
dt_bindings_check after making all changes and prepare v2 if there will
be no further comments.
Also what do you think about maintainers: field? Is it correct? I'm not
sure if I used it correctly.
>
> Best regards,
> Krzysztof
