Introducing new parameter called xen,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 property is used by Xen hypervisor, which works as trusted Agent,
to set permissions for the devices, passed-through to the Guest Domains,
which are non-trusted Agents. Trusted Agent will use xen,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].
xen,scmi-devid in Device-tree node example:
usb@e6590000
{
xen,scmi-devid = <19>;
clocks = <&scmi_clock 3>, <&scmi_clock 2>;
resets = <&scmi_reset 10>, <&scmi_reset 9>;
power-domains = <&scmi_power 0>;
};
Given example shows the configuration of the hsusb node, which is using
scmi to contol clocks, resets and power-domains. scmi_devid is set
equals to 19, which should match defined id for usb in the Firmware.
Trusted Agent will use xen,scmi-devid to set the device permissions for
the Agents. Guest OS should not have an access to the permissions
settings, so no code to process xen,scmi-devid was presented in Linux
kernel.
We are currently contributing changes to Xen, which are intended to
mediate SCMI access from Guests to the Firmware. Xen uses xen,scmi-devid to set
the permissions for the devices. See [1] thread for details.
[0] https://developer.arm.com/documentation/den0056/latest
[1] https://xen.markmail.org/message/mmi4fpb4qr6e3kad
Oleksii Moisieiev (2):
dt-bindings: Add vendor prefix for Xen hypervisor
dt-bindings: xen: Add xen,scmi-devid property description for SCMI
.../bindings/firmware/xen,scmi-devid.yaml | 42 +++++++++++++++++++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
2 files changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/firmware/xen,scmi-devid.yaml
--
2.27.0
Document xen,scmi-devid property for the devices, using SCMI protocol
to work with clocks/resets/power-domains etc. This property is intended
to set the device_id, which should be used to manage device permissions
in the Firmware. Device permissions management described in DEN 0056,
Section 4.2.2.10 [0].
This property is used by Xen hypervisor, which works as trusted Agent, to
set permissions for the devices, passed-through to the Guest Domains,
which are non-trusted Agents. Trusted and non-trusted Agent terms described
in Section 4.1.1 [0].
[0] https://developer.arm.com/documentation/den0056/latest
Signed-off-by: Oleksii Moisieiev <[email protected]>
---
.../bindings/firmware/xen,scmi-devid.yaml | 42 +++++++++++++++++++
1 file changed, 42 insertions(+)
create mode 100644 Documentation/devicetree/bindings/firmware/xen,scmi-devid.yaml
diff --git a/Documentation/devicetree/bindings/firmware/xen,scmi-devid.yaml b/Documentation/devicetree/bindings/firmware/xen,scmi-devid.yaml
new file mode 100644
index 000000000000..49dc9951b54d
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/xen,scmi-devid.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2022 EPAM Systems.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/xen,scmi-devid.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xen SCMI (System Control and Management Interface) Device ID binding
+
+maintainers:
+ - Oleksii Moisieiev <[email protected]>
+
+select: true
+
+description: |
+ SCMI device_id property is intended to set the device id, needed to manage
+ the device permissions via SCMI protocol in the firmware. The device_id
+ should match device ids, defined in the firmware so the device permissions
+ can be requested by sending BASE_SET_DEVICE_PERMISSIONS (see 4.2.2.10 of [0]).
+
+ This property is used by Xen hypervisor to set the device permissions for
+ the Guest Domains. Where Xen is trusted Agent and Guest Domains are
+ non-trusted Agents.
+
+ [0] https://developer.arm.com/documentation/den0056/latest
+
+properties:
+ xen,scmi-devid:
+ description: Identifier of the device, matching device id, defined in
+ the firmware.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+additionalProperties: true
+
+examples:
+ - |
+ ohci1: usb@ee0a0000 {
+ /* ... */
+ reg = <0xee0a0000 0x100>;
+ xen,scmi-devid = <11>;
+ clocks = <&scmi_clock 4>;
+ };
--
2.27.0
Xen is an open source stage-1 hypervisor.
Signed-off-by: Oleksii Moisieiev <[email protected]>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 294093d45a23..0d10a55df910 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1360,6 +1360,8 @@ patternProperties:
description: Wanchanglong Electronics Technology（SHENZHEN）Co.，Ltd.
"^x-powers,.*":
description: X-Powers
+ "^xen,.*":
+ description: Xen Hypervisor
"^xes,.*":
description: Extreme Engineering Solutions (X-ES)
"^xiaomi,.*":
--
2.27.0
On Mon, 7 Mar 2022, Oleksii Moisieiev wrote:
> Document xen,scmi-devid property for the devices, using SCMI protocol
> to work with clocks/resets/power-domains etc. This property is intended
> to set the device_id, which should be used to manage device permissions
> in the Firmware. Device permissions management described in DEN 0056,
> Section 4.2.2.10 [0].
>
> This property is used by Xen hypervisor, which works as trusted Agent, to
> set permissions for the devices, passed-through to the Guest Domains,
> which are non-trusted Agents. Trusted and non-trusted Agent terms described
> in Section 4.1.1 [0].
>
> [0] https://developer.arm.com/documentation/den0056/latest
Aside from minor grammar improvements (see below), I don't have any
feedback. This is OK from my point of view.
> Signed-off-by: Oleksii Moisieiev <[email protected]>
> ---
> .../bindings/firmware/xen,scmi-devid.yaml | 42 +++++++++++++++++++
> 1 file changed, 42 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/firmware/xen,scmi-devid.yaml
>
> diff --git a/Documentation/devicetree/bindings/firmware/xen,scmi-devid.yaml b/Documentation/devicetree/bindings/firmware/xen,scmi-devid.yaml
> new file mode 100644
> index 000000000000..49dc9951b54d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/firmware/xen,scmi-devid.yaml
> @@ -0,0 +1,42 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2022 EPAM Systems.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/firmware/xen,scmi-devid.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Xen SCMI (System Control and Management Interface) Device ID binding
> +
> +maintainers:
> + - Oleksii Moisieiev <[email protected]>
> +
> +select: true
> +
> +description: |
> + SCMI device_id property is intended to set the device id, needed to manage
> + the device permissions via SCMI protocol in the firmware. The device_id
> + should match device ids, defined in the firmware so the device permissions
> + can be requested by sending BASE_SET_DEVICE_PERMISSIONS (see 4.2.2.10 of [0]).
I would say:
The xen,scmi-devid property is the SCMI device id, which is needed to
manage device permissions with the SCMI protocol. The xen,scmi-devid
property should match device ids as defined in firmware, so that device
permissions can be requested with BASE_SET_DEVICE_PERMISSIONS (see
4.2.2.10 of [0]).
> + This property is used by Xen hypervisor to set the device permissions for
> + the Guest Domains. Where Xen is trusted Agent and Guest Domains are
> + non-trusted Agents.
I would say:
This property is used by a Trusted Agent, e.g. the Xen hypervisor, to
set device permissions for non-trusted Agents, e.g. Xen domains.
> + [0] https://developer.arm.com/documentation/den0056/latest
> +
> +properties:
> + xen,scmi-devid:
> + description: Identifier of the device, matching device id, defined in
> + the firmware.
description: Identifier of the device, matching the SCMI device id as
defined in firmware
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> +additionalProperties: true
> +
> +examples:
> + - |
> + ohci1: usb@ee0a0000 {
> + /* ... */
> + reg = <0xee0a0000 0x100>;
> + xen,scmi-devid = <11>;
> + clocks = <&scmi_clock 4>;
> + };
> --
> 2.27.0
>
On Mon, 7 Mar 2022, Oleksii Moisieiev wrote:
> Xen is an open source stage-1 hypervisor.
^ type-1
> Signed-off-by: Oleksii Moisieiev <[email protected]>
With the minor correction:
Reviewed-by: Stefano Stabellini <[email protected]>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 294093d45a23..0d10a55df910 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -1360,6 +1360,8 @@ patternProperties:
> description: Wanchanglong Electronics Technology（SHENZHEN）Co.，Ltd.
> "^x-powers,.*":
> description: X-Powers
> + "^xen,.*":
> + description: Xen Hypervisor
> "^xes,.*":
> description: Extreme Engineering Solutions (X-ES)
> "^xiaomi,.*":
> --
> 2.27.0
>
On Mon, 07 Mar 2022 08:17:43 +0000, Oleksii Moisieiev wrote:
> Xen is an open source stage-1 hypervisor.
>
> Signed-off-by: Oleksii Moisieiev <[email protected]>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
As 'xen' has been missing regardless of patch 2, I fixed up the commit
message and applied, thanks!
Rob
On Mon, Mar 07, 2022 at 08:17:44AM +0000, Oleksii Moisieiev wrote:
> Document xen,scmi-devid property for the devices, using SCMI protocol
> to work with clocks/resets/power-domains etc. This property is intended
> to set the device_id, which should be used to manage device permissions
> in the Firmware. Device permissions management described in DEN 0056,
> Section 4.2.2.10 [0].
If device_id is a SCMI thing, how is it set for other platforms and
bindings? With clocks or power-domains, the device_id is the cell value,
right?
Since we don't yet have a device assignment, security, or partitioning
binding, you've come up with some Xen specific solution. Given I know
multiple people want some sort of binding for this, I'm not going to
accept anything short of a common binding addressing the various needs.
> This property is used by Xen hypervisor, which works as trusted Agent, to
> set permissions for the devices, passed-through to the Guest Domains,
> which are non-trusted Agents. Trusted and non-trusted Agent terms described
> in Section 4.1.1 [0].
>
> [0] https://developer.arm.com/documentation/den0056/latest
>
> Signed-off-by: Oleksii Moisieiev <[email protected]>
> ---
> .../bindings/firmware/xen,scmi-devid.yaml | 42 +++++++++++++++++++
> 1 file changed, 42 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/firmware/xen,scmi-devid.yaml
>
> diff --git a/Documentation/devicetree/bindings/firmware/xen,scmi-devid.yaml b/Documentation/devicetree/bindings/firmware/xen,scmi-devid.yaml
> new file mode 100644
> index 000000000000..49dc9951b54d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/firmware/xen,scmi-devid.yaml
> @@ -0,0 +1,42 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2022 EPAM Systems.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/firmware/xen,scmi-devid.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Xen SCMI (System Control and Management Interface) Device ID binding
> +
> +maintainers:
> + - Oleksii Moisieiev <[email protected]>
> +
> +select: true
> +
> +description: |
> + SCMI device_id property is intended to set the device id, needed to manage
> + the device permissions via SCMI protocol in the firmware. The device_id
> + should match device ids, defined in the firmware so the device permissions
> + can be requested by sending BASE_SET_DEVICE_PERMISSIONS (see 4.2.2.10 of [0]).
> +
> + This property is used by Xen hypervisor to set the device permissions for
> + the Guest Domains. Where Xen is trusted Agent and Guest Domains are
> + non-trusted Agents.
> +
> + [0] https://developer.arm.com/documentation/den0056/latest
> +
> +properties:
> + xen,scmi-devid:
> + description: Identifier of the device, matching device id, defined in
> + the firmware.
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> +additionalProperties: true
> +
> +examples:
> + - |
> + ohci1: usb@ee0a0000 {
> + /* ... */
> + reg = <0xee0a0000 0x100>;
> + xen,scmi-devid = <11>;
This will cause validation errors unless xen,scmi-devid is listed or
this schema is referenced in every possible device schema. That
doesn't scale, but we don't really have a solution to that. For some
common properties, the tools will add certain properties. If we
come up with something common, we'll need to add it. Or we may
need to come up with something more data driven where certain schemas
are automatically added.
Rob
> + clocks = <&scmi_clock 4>;
> + };
> --
> 2.27.0
>
Hello,
On Tue, Mar 08, 2022 at 02:14:55PM -0600, Rob Herring wrote:
> On Mon, 07 Mar 2022 08:17:43 +0000, Oleksii Moisieiev wrote:
> > Xen is an open source stage-1 hypervisor.
> >
> > Signed-off-by: Oleksii Moisieiev <[email protected]>
> > ---
> > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> > 1 file changed, 2 insertions(+)
> >
>
> As 'xen' has been missing regardless of patch 2, I fixed up the commit
> message and applied, thanks!
So IIUC - this patch is already applied and I don't need to add it v3?
Best regards,
Oleksii.
On Thu, 10 Mar 2022, Oleksii Moisieiev wrote:
> On Tue, Mar 08, 2022 at 02:14:55PM -0600, Rob Herring wrote:
> > On Mon, 07 Mar 2022 08:17:43 +0000, Oleksii Moisieiev wrote:
> > > Xen is an open source stage-1 hypervisor.
> > >
> > > Signed-off-by: Oleksii Moisieiev <[email protected]>
> > > ---
> > > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> >
> > As 'xen' has been missing regardless of patch 2, I fixed up the commit
> > message and applied, thanks!
>
> So IIUC - this patch is already applied and I don't need to add it v3?
Yes, that's right. Congratulations for your first official device tree
binding change :-)
On Wed, Mar 16, 2022 at 04:46:20PM +0000, Oleksii Moisieiev wrote:
>
> > + The reason I want to keep it xen specific at the moment as we had some
> > plan to extended the device-id usage in the spec which hasn't progressed
> > a bit(I must admit that before you ask), and this addition should not be
> > obstruct that future development. If we align with what we define xen
> > specific as part of $subject work, we can always define generic binding
> > in the future and slowly make the other obsolete over the time.
>
> IIUC you have some plans to provide device_id support to the device-tree
> bindings from your side. Maybe we can discuss some of your plans here
> and we can come up with the generic device-id binding?
> So I will have something to base on in Xen.
>
Sorry if I wasn't clear in earlier emails. What I mentioned was that I would
like to reserve the generic namespace(i.e. just device-id) for generic SCMI
usage. Since we haven't defined it clearly in the spec, I don't want to
introduce the generic definition and binding now.
As mentioned earlier, though Xen definition and generic once may be exactly
same, but we won't know until then. So keep the xen usage and namespace
separate for now to avoid any future conflicts.
--
Regards,
Sudeep
On Tue, Mar 08, 2022 at 02:13:33PM -0600, Rob Herring wrote:
> On Mon, Mar 07, 2022 at 08:17:44AM +0000, Oleksii Moisieiev wrote:
> > Document xen,scmi-devid property for the devices, using SCMI protocol
> > to work with clocks/resets/power-domains etc. This property is intended
> > to set the device_id, which should be used to manage device permissions
> > in the Firmware. Device permissions management described in DEN 0056,
> > Section 4.2.2.10 [0].
>
> If device_id is a SCMI thing, how is it set for other platforms and
> bindings? With clocks or power-domains, the device_id is the cell value,
> right?
>
> Since we don't yet have a device assignment, security, or partitioning
> binding, you've come up with some Xen specific solution. Given I know
> multiple people want some sort of binding for this, I'm not going to
> accept anything short of a common binding addressing the various needs.
>
Hi Sudeep,
On your email from 3/4/2022 you wrote:
> The fact that we don't need this to be part of SCMI OSPM user bindings,
> it is not addressed and can be considered as a gap.
> + The reason I want to keep it xen specific at the moment as we had some
> plan to extended the device-id usage in the spec which hasn't progressed
> a bit(I must admit that before you ask), and this addition should not be
> obstruct that future development. If we align with what we define xen
> specific as part of $subject work, we can always define generic binding
> in the future and slowly make the other obsolete over the time.
IIUC you have some plans to provide device_id support to the device-tree
bindings from your side. Maybe we can discuss some of your plans here
and we can come up with the generic device-id binding?
So I will have something to base on in Xen.
Best regards,
Oleksii.
>
> > This property is used by Xen hypervisor, which works as trusted Agent, to
> > set permissions for the devices, passed-through to the Guest Domains,
> > which are non-trusted Agents. Trusted and non-trusted Agent terms described
> > in Section 4.1.1 [0].
> >
> > [0] https://urldefense.com/v3/__https://developer.arm.com/documentation/den0056/latest__;!!GF_29dbcQIUBPA!kOUan6_nwTf375KaLzZxwHSYqYp1ptLUolUEoK-t3Wb4gsN3ajUC0qQBh6TdAMXQYrn8$ [developer[.]arm[.]com]
> >
> > Signed-off-by: Oleksii Moisieiev <[email protected]>
> > ---
> > .../bindings/firmware/xen,scmi-devid.yaml | 42 +++++++++++++++++++
> > 1 file changed, 42 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/firmware/xen,scmi-devid.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/firmware/xen,scmi-devid.yaml b/Documentation/devicetree/bindings/firmware/xen,scmi-devid.yaml
> > new file mode 100644
> > index 000000000000..49dc9951b54d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/firmware/xen,scmi-devid.yaml
> > @@ -0,0 +1,42 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +# Copyright 2022 EPAM Systems.
> > +%YAML 1.2
> > +---
> > +$id: https://urldefense.com/v3/__http://devicetree.org/schemas/firmware/xen,scmi-devid.yaml*__;Iw!!GF_29dbcQIUBPA!kOUan6_nwTf375KaLzZxwHSYqYp1ptLUolUEoK-t3Wb4gsN3ajUC0qQBh6TdAPJC8yo3$ [devicetree[.]org]
> > +$schema: https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!GF_29dbcQIUBPA!kOUan6_nwTf375KaLzZxwHSYqYp1ptLUolUEoK-t3Wb4gsN3ajUC0qQBh6TdADgb5MTo$ [devicetree[.]org]
> > +
> > +title: Xen SCMI (System Control and Management Interface) Device ID binding
> > +
> > +maintainers:
> > + - Oleksii Moisieiev <[email protected]>
> > +
> > +select: true
> > +
> > +description: |
> > + SCMI device_id property is intended to set the device id, needed to manage
> > + the device permissions via SCMI protocol in the firmware. The device_id
> > + should match device ids, defined in the firmware so the device permissions
> > + can be requested by sending BASE_SET_DEVICE_PERMISSIONS (see 4.2.2.10 of [0]).
> > +
> > + This property is used by Xen hypervisor to set the device permissions for
> > + the Guest Domains. Where Xen is trusted Agent and Guest Domains are
> > + non-trusted Agents.
> > +
> > + [0] https://urldefense.com/v3/__https://developer.arm.com/documentation/den0056/latest__;!!GF_29dbcQIUBPA!kOUan6_nwTf375KaLzZxwHSYqYp1ptLUolUEoK-t3Wb4gsN3ajUC0qQBh6TdAMXQYrn8$ [developer[.]arm[.]com]
> > +
> > +properties:
> > + xen,scmi-devid:
> > + description: Identifier of the device, matching device id, defined in
> > + the firmware.
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > +
> > +additionalProperties: true
> > +
> > +examples:
> > + - |
> > + ohci1: usb@ee0a0000 {
> > + /* ... */
> > + reg = <0xee0a0000 0x100>;
> > + xen,scmi-devid = <11>;
>
> This will cause validation errors unless xen,scmi-devid is listed or
> this schema is referenced in every possible device schema. That
> doesn't scale, but we don't really have a solution to that. For some
> common properties, the tools will add certain properties. If we
> come up with something common, we'll need to add it. Or we may
> need to come up with something more data driven where certain schemas
> are automatically added.
>
> Rob
>
> > + clocks = <&scmi_clock 4>;
> > + };
> > --
> > 2.27.0
> >
On Wed, 16 Mar 2022, Sudeep Holla wrote:
> On Wed, Mar 16, 2022 at 04:46:20PM +0000, Oleksii Moisieiev wrote:
> >
> > > + The reason I want to keep it xen specific at the moment as we had some
> > > plan to extended the device-id usage in the spec which hasn't progressed
> > > a bit(I must admit that before you ask), and this addition should not be
> > > obstruct that future development. If we align with what we define xen
> > > specific as part of $subject work, we can always define generic binding
> > > in the future and slowly make the other obsolete over the time.
> >
> > IIUC you have some plans to provide device_id support to the device-tree
> > bindings from your side. Maybe we can discuss some of your plans here
> > and we can come up with the generic device-id binding?
> > So I will have something to base on in Xen.
> >
>
> Sorry if I wasn't clear in earlier emails. What I mentioned was that I would
> like to reserve the generic namespace(i.e. just device-id) for generic SCMI
> usage. Since we haven't defined it clearly in the spec, I don't want to
> introduce the generic definition and binding now.
>
> As mentioned earlier, though Xen definition and generic once may be exactly
> same, but we won't know until then. So keep the xen usage and namespace
> separate for now to avoid any future conflicts.
Hi Sudeep,
I thought the specification already covered this device id, it simply
delegated the description of it to Device Tree or ACPI, which is common
behavior in ARM specs. What is missing in the SCMI spec from your point
of view?
Or would you like this scmi-devid Device Tree property (or similar) to
be described in the SCMI specification itself?
Typically Device Tree and ACPI descriptions are delegated to Device Tree
and ACPI respectively. Also specification updates are typically slow
(for good reason.) We might be waiting for a long time. It is usually
not a matter of days.
On Fri, Mar 18, 2022 at 04:53:20PM -0700, Stefano Stabellini wrote:
> On Wed, 16 Mar 2022, Sudeep Holla wrote:
> > On Wed, Mar 16, 2022 at 04:46:20PM +0000, Oleksii Moisieiev wrote:
> > >
> > > > + The reason I want to keep it xen specific at the moment as we had some
> > > > plan to extended the device-id usage in the spec which hasn't progressed
> > > > a bit(I must admit that before you ask), and this addition should not be
> > > > obstruct that future development. If we align with what we define xen
> > > > specific as part of $subject work, we can always define generic binding
> > > > in the future and slowly make the other obsolete over the time.
> > >
> > > IIUC you have some plans to provide device_id support to the device-tree
> > > bindings from your side. Maybe we can discuss some of your plans here
> > > and we can come up with the generic device-id binding?
> > > So I will have something to base on in Xen.
> > >
> >
> > Sorry if I wasn't clear in earlier emails. What I mentioned was that I would
> > like to reserve the generic namespace(i.e. just device-id) for generic SCMI
> > usage. Since we haven't defined it clearly in the spec, I don't want to
> > introduce the generic definition and binding now.
> >
> > As mentioned earlier, though Xen definition and generic once may be exactly
> > same, but we won't know until then. So keep the xen usage and namespace
> > separate for now to avoid any future conflicts.
>
>
> Hi Sudeep,
>
> I thought the specification already covered this device id, it simply
> delegated the description of it to Device Tree or ACPI, which is common
> behavior in ARM specs. What is missing in the SCMI spec from your point
> of view?
>
While you can say so, but for me it isn't to an extent that we can support
software around it. I did share my feedback with spec author but as you
know it was needed for virtualisation use-case like Xen and was rushed
into the spec. All it states is "Device identifier" identifies the device
and the enumeration is not part of the spec. It defers to DT/ACPI.
Since I didn't have to use that in OSPM, I hadn't given much thought/review
on that.
>
> Or would you like this scmi-devid Device Tree property (or similar) to
> be described in the SCMI specification itself?
>
Spec doesn't cover that in general but do carry some recommendations
sometimes.
> Typically Device Tree and ACPI descriptions are delegated to Device Tree
> and ACPI respectively. Also specification updates are typically slow
> (for good reason.) We might be waiting for a long time. It is usually
> not a matter of days.
I agree.
As I said, there were thoughts about adding device protocol to make
all the other protocols centered around the device. The idea is as below:
Today a device A is associated with clock domain X, reset domain Y,
voltage domain Z, perf domain P, power domain Q, ...and so on.
Especially this would get complex with lots of devices and for virtual
machines.
Instead let all these different operations use the device identifier A
in the above case to drive clock, reset, perf, power, voltage,...etc.
While this was just initial idea, I am bit wary of the fact that it would
alter the definition of device identifier. Also there is orthogonal topic
of device assignment in various contexts and associated identifiers.
IIRC Rob briefly raised concerns on one of such topics.
With all these in consideration, I preferred to not use the "device-id"
in the standard namespace for anything else until we get clarity on these.
--
Regards,
Sudeep
On Tue, Mar 22, 2022 at 07:21:47PM +0000, Oleksii Moisieiev wrote:
> Hi Sudeep,
>
> On Tue, Mar 22, 2022 at 11:12:21AM +0000, Sudeep Holla wrote:
> > On Fri, Mar 18, 2022 at 04:53:20PM -0700, Stefano Stabellini wrote:
> > > On Wed, 16 Mar 2022, Sudeep Holla wrote:
> > > > On Wed, Mar 16, 2022 at 04:46:20PM +0000, Oleksii Moisieiev wrote:
> > > > >
> > > > > > + The reason I want to keep it xen specific at the moment as we had some
> > > > > > plan to extended the device-id usage in the spec which hasn't progressed
> > > > > > a bit(I must admit that before you ask), and this addition should not be
> > > > > > obstruct that future development. If we align with what we define xen
> > > > > > specific as part of $subject work, we can always define generic binding
> > > > > > in the future and slowly make the other obsolete over the time.
> > > > >
> > > > > IIUC you have some plans to provide device_id support to the device-tree
> > > > > bindings from your side. Maybe we can discuss some of your plans here
> > > > > and we can come up with the generic device-id binding?
> > > > > So I will have something to base on in Xen.
> > > > >
> > > >
> > > > Sorry if I wasn't clear in earlier emails. What I mentioned was that I would
> > > > like to reserve the generic namespace(i.e. just device-id) for generic SCMI
> > > > usage. Since we haven't defined it clearly in the spec, I don't want to
> > > > introduce the generic definition and binding now.
> > > >
> > > > As mentioned earlier, though Xen definition and generic once may be exactly
> > > > same, but we won't know until then. So keep the xen usage and namespace
> > > > separate for now to avoid any future conflicts.
> > >
> > >
> > > Hi Sudeep,
> > >
> > > I thought the specification already covered this device id, it simply
> > > delegated the description of it to Device Tree or ACPI, which is common
> > > behavior in ARM specs. What is missing in the SCMI spec from your point
> > > of view?
> > >
> >
> > While you can say so, but for me it isn't to an extent that we can support
> > software around it. I did share my feedback with spec author but as you
> > know it was needed for virtualisation use-case like Xen and was rushed
> > into the spec. All it states is "Device identifier" identifies the device
> > and the enumeration is not part of the spec. It defers to DT/ACPI.
> >
> > Since I didn't have to use that in OSPM, I hadn't given much thought/review
> > on that.
> >
> > >
> > > Or would you like this scmi-devid Device Tree property (or similar) to
> > > be described in the SCMI specification itself?
> > >
> >
> > Spec doesn't cover that in general but do carry some recommendations
> > sometimes.
> >
> > > Typically Device Tree and ACPI descriptions are delegated to Device Tree
> > > and ACPI respectively. Also specification updates are typically slow
> > > (for good reason.) We might be waiting for a long time. It is usually
> > > not a matter of days.
> >
> > I agree.
> >
> > As I said, there were thoughts about adding device protocol to make
> > all the other protocols centered around the device. The idea is as below:
> >
> > Today a device A is associated with clock domain X, reset domain Y,
> > voltage domain Z, perf domain P, power domain Q, ...and so on.
> > Especially this would get complex with lots of devices and for virtual
> > machines.
> >
> > Instead let all these different operations use the device identifier A
> > in the above case to drive clock, reset, perf, power, voltage,...etc.
>
> So, IIUC - the idea is to provide new device based protocol
> which will allow agents to control different domains by using ony device
> id? Does it mean that scmi drivers for agents should be also changed and there will
> be no back compatibility with previous versions of SCMI protocol?
The idea is it is discoverable and if the platform advertises new protocol,
then only it will be used. Otherwise we must continue to use the existing
and advertised protocols. Anyways I realised that we need not even consider
these new changes for the discussion here.
> If yes - we probably can add scmi-devid property for current SCMI
> version, such as scmi-v3,device-id (because current DEN0056D document
> has version 3.1) and say that this property should be
> used for SCMI versions, which doesn't support device protocol.
> What do you think about this idea?
The main idea we had is to re-use the generic definition of device ID
Linux might need for other purposes like device assignments. We would
like to avoid a mapping from the generic device ID Linux might need and
define to the one in scmi context. So as Rob mentioned, it is better to
define one in a generic Linux/OS context and see how we can make use of
that in SCMI context. We could get some recommendations added to the spec
if needed based on what gets added/supported in the kernel.
So better to start addressing or responding to Rob's comments(not sure
if it was this version or the previous) if you want a generic device
ID definition. We are not adding anything SCMI specific as that might
end up conflicting with the one that Linux kernel might add.
Hope this helps.
--
Regards,
Sudeep
Hi Sudeep,
On Tue, Mar 22, 2022 at 11:12:21AM +0000, Sudeep Holla wrote:
> On Fri, Mar 18, 2022 at 04:53:20PM -0700, Stefano Stabellini wrote:
> > On Wed, 16 Mar 2022, Sudeep Holla wrote:
> > > On Wed, Mar 16, 2022 at 04:46:20PM +0000, Oleksii Moisieiev wrote:
> > > >
> > > > > + The reason I want to keep it xen specific at the moment as we had some
> > > > > plan to extended the device-id usage in the spec which hasn't progressed
> > > > > a bit(I must admit that before you ask), and this addition should not be
> > > > > obstruct that future development. If we align with what we define xen
> > > > > specific as part of $subject work, we can always define generic binding
> > > > > in the future and slowly make the other obsolete over the time.
> > > >
> > > > IIUC you have some plans to provide device_id support to the device-tree
> > > > bindings from your side. Maybe we can discuss some of your plans here
> > > > and we can come up with the generic device-id binding?
> > > > So I will have something to base on in Xen.
> > > >
> > >
> > > Sorry if I wasn't clear in earlier emails. What I mentioned was that I would
> > > like to reserve the generic namespace(i.e. just device-id) for generic SCMI
> > > usage. Since we haven't defined it clearly in the spec, I don't want to
> > > introduce the generic definition and binding now.
> > >
> > > As mentioned earlier, though Xen definition and generic once may be exactly
> > > same, but we won't know until then. So keep the xen usage and namespace
> > > separate for now to avoid any future conflicts.
> >
> >
> > Hi Sudeep,
> >
> > I thought the specification already covered this device id, it simply
> > delegated the description of it to Device Tree or ACPI, which is common
> > behavior in ARM specs. What is missing in the SCMI spec from your point
> > of view?
> >
>
> While you can say so, but for me it isn't to an extent that we can support
> software around it. I did share my feedback with spec author but as you
> know it was needed for virtualisation use-case like Xen and was rushed
> into the spec. All it states is "Device identifier" identifies the device
> and the enumeration is not part of the spec. It defers to DT/ACPI.
>
> Since I didn't have to use that in OSPM, I hadn't given much thought/review
> on that.
>
> >
> > Or would you like this scmi-devid Device Tree property (or similar) to
> > be described in the SCMI specification itself?
> >
>
> Spec doesn't cover that in general but do carry some recommendations
> sometimes.
>
> > Typically Device Tree and ACPI descriptions are delegated to Device Tree
> > and ACPI respectively. Also specification updates are typically slow
> > (for good reason.) We might be waiting for a long time. It is usually
> > not a matter of days.
>
> I agree.
>
> As I said, there were thoughts about adding device protocol to make
> all the other protocols centered around the device. The idea is as below:
>
> Today a device A is associated with clock domain X, reset domain Y,
> voltage domain Z, perf domain P, power domain Q, ...and so on.
> Especially this would get complex with lots of devices and for virtual
> machines.
>
> Instead let all these different operations use the device identifier A
> in the above case to drive clock, reset, perf, power, voltage,...etc.
So, IIUC - the idea is to provide new device based protocol
which will allow agents to control different domains by using ony device
id? Does it mean that scmi drivers for agents should be also changed and there will
be no back compatibility with previous versions of SCMI protocol?
If yes - we probably can add scmi-devid property for current SCMI
version, such as scmi-v3,device-id (because current DEN0056D document
has version 3.1) and say that this property should be
used for SCMI versions, which doesn't support device protocol.
What do you think about this idea?
>
> While this was just initial idea, I am bit wary of the fact that it would
> alter the definition of device identifier. Also there is orthogonal topic
> of device assignment in various contexts and associated identifiers.
> IIRC Rob briefly raised concerns on one of such topics.
>
> With all these in consideration, I preferred to not use the "device-id"
> in the standard namespace for anything else until we get clarity on these.
>
Best regards,
Oleksii.
On Wed, Mar 23, 2022 at 10:54:22AM +0000, Sudeep Holla wrote:
> On Tue, Mar 22, 2022 at 07:21:47PM +0000, Oleksii Moisieiev wrote:
> > Hi Sudeep,
> >
> > On Tue, Mar 22, 2022 at 11:12:21AM +0000, Sudeep Holla wrote:
> > > On Fri, Mar 18, 2022 at 04:53:20PM -0700, Stefano Stabellini wrote:
> > > > On Wed, 16 Mar 2022, Sudeep Holla wrote:
> > > > > On Wed, Mar 16, 2022 at 04:46:20PM +0000, Oleksii Moisieiev wrote:
> > > > > >
> > > > > > > + The reason I want to keep it xen specific at the moment as we had some
> > > > > > > plan to extended the device-id usage in the spec which hasn't progressed
> > > > > > > a bit(I must admit that before you ask), and this addition should not be
> > > > > > > obstruct that future development. If we align with what we define xen
> > > > > > > specific as part of $subject work, we can always define generic binding
> > > > > > > in the future and slowly make the other obsolete over the time.
> > > > > >
> > > > > > IIUC you have some plans to provide device_id support to the device-tree
> > > > > > bindings from your side. Maybe we can discuss some of your plans here
> > > > > > and we can come up with the generic device-id binding?
> > > > > > So I will have something to base on in Xen.
> > > > > >
> > > > >
> > > > > Sorry if I wasn't clear in earlier emails. What I mentioned was that I would
> > > > > like to reserve the generic namespace(i.e. just device-id) for generic SCMI
> > > > > usage. Since we haven't defined it clearly in the spec, I don't want to
> > > > > introduce the generic definition and binding now.
> > > > >
> > > > > As mentioned earlier, though Xen definition and generic once may be exactly
> > > > > same, but we won't know until then. So keep the xen usage and namespace
> > > > > separate for now to avoid any future conflicts.
> > > >
> > > >
> > > > Hi Sudeep,
> > > >
> > > > I thought the specification already covered this device id, it simply
> > > > delegated the description of it to Device Tree or ACPI, which is common
> > > > behavior in ARM specs. What is missing in the SCMI spec from your point
> > > > of view?
> > > >
> > >
> > > While you can say so, but for me it isn't to an extent that we can support
> > > software around it. I did share my feedback with spec author but as you
> > > know it was needed for virtualisation use-case like Xen and was rushed
> > > into the spec. All it states is "Device identifier" identifies the device
> > > and the enumeration is not part of the spec. It defers to DT/ACPI.
> > >
> > > Since I didn't have to use that in OSPM, I hadn't given much thought/review
> > > on that.
> > >
> > > >
> > > > Or would you like this scmi-devid Device Tree property (or similar) to
> > > > be described in the SCMI specification itself?
> > > >
> > >
> > > Spec doesn't cover that in general but do carry some recommendations
> > > sometimes.
> > >
> > > > Typically Device Tree and ACPI descriptions are delegated to Device Tree
> > > > and ACPI respectively. Also specification updates are typically slow
> > > > (for good reason.) We might be waiting for a long time. It is usually
> > > > not a matter of days.
> > >
> > > I agree.
> > >
> > > As I said, there were thoughts about adding device protocol to make
> > > all the other protocols centered around the device. The idea is as below:
> > >
> > > Today a device A is associated with clock domain X, reset domain Y,
> > > voltage domain Z, perf domain P, power domain Q, ...and so on.
> > > Especially this would get complex with lots of devices and for virtual
> > > machines.
> > >
> > > Instead let all these different operations use the device identifier A
> > > in the above case to drive clock, reset, perf, power, voltage,...etc.
> >
> > So, IIUC - the idea is to provide new device based protocol
> > which will allow agents to control different domains by using ony device
> > id? Does it mean that scmi drivers for agents should be also changed and there will
> > be no back compatibility with previous versions of SCMI protocol?
>
> The idea is it is discoverable and if the platform advertises new protocol,
> then only it will be used. Otherwise we must continue to use the existing
> and advertised protocols. Anyways I realised that we need not even consider
> these new changes for the discussion here.
>
> > If yes - we probably can add scmi-devid property for current SCMI
> > version, such as scmi-v3,device-id (because current DEN0056D document
> > has version 3.1) and say that this property should be
> > used for SCMI versions, which doesn't support device protocol.
> > What do you think about this idea?
>
> The main idea we had is to re-use the generic definition of device ID
> Linux might need for other purposes like device assignments. We would
> like to avoid a mapping from the generic device ID Linux might need and
> define to the one in scmi context. So as Rob mentioned, it is better to
> define one in a generic Linux/OS context and see how we can make use of
> that in SCMI context. We could get some recommendations added to the spec
> if needed based on what gets added/supported in the kernel.
>
> So better to start addressing or responding to Rob's comments(not sure
> if it was this version or the previous) if you want a generic device
> ID definition. We are not adding anything SCMI specific as that might
> end up conflicting with the one that Linux kernel might add.
>
Hi Rob,
Based on what Sudeep have suggested, I think we may think about the approach
of the Generic Linux device-id, which can be used for SCMI needs as the
device id.
I have some ideas, how the generic device_id can be implemented.
From my understanding - the Generic Device Id is the unique identifier, which
can be set for the Device node in the Device-tree. This identifier is
already set for each node by DTC and called phandle.
I've tried setting phandle for the device-nodes, such as:
&usb0 {
/* .... */
phandle = <0x10>;
}
DTC seems to work properly with this constant phandle. All links works
for usb0 and all nodes, which doesn't have constant phandle receives
calculated phandle during device-tree compilation.
Also DTC will fail if I set 2 same phandle values in different
device nodes. So we can rely on phandle as on the unique device id.
What do you think about using phandle to set the device_id?
The alternative way I see for now is to itroduce additional property to SCMI
node, which includes list of the device-ids, such as:
scmi {
compatible = "arm,scmi-smc";
/* ... */
device-ids = <&usb0 17,
&usb1 42,
....
>;
}
Looking forward for your opinion.
Maybe you can share some ideas about how the device-id can be
implemented?
Best regards,
Oleksii.
On Mon, 28 Mar 2022, Oleksii Moisieiev wrote:
> On Wed, Mar 23, 2022 at 10:54:22AM +0000, Sudeep Holla wrote:
> > On Tue, Mar 22, 2022 at 07:21:47PM +0000, Oleksii Moisieiev wrote:
> > > Hi Sudeep,
> > >
> > > On Tue, Mar 22, 2022 at 11:12:21AM +0000, Sudeep Holla wrote:
> > > > On Fri, Mar 18, 2022 at 04:53:20PM -0700, Stefano Stabellini wrote:
> > > > > On Wed, 16 Mar 2022, Sudeep Holla wrote:
> > > > > > On Wed, Mar 16, 2022 at 04:46:20PM +0000, Oleksii Moisieiev wrote:
> > > > > > >
> > > > > > > > + The reason I want to keep it xen specific at the moment as we had some
> > > > > > > > plan to extended the device-id usage in the spec which hasn't progressed
> > > > > > > > a bit(I must admit that before you ask), and this addition should not be
> > > > > > > > obstruct that future development. If we align with what we define xen
> > > > > > > > specific as part of $subject work, we can always define generic binding
> > > > > > > > in the future and slowly make the other obsolete over the time.
> > > > > > >
> > > > > > > IIUC you have some plans to provide device_id support to the device-tree
> > > > > > > bindings from your side. Maybe we can discuss some of your plans here
> > > > > > > and we can come up with the generic device-id binding?
> > > > > > > So I will have something to base on in Xen.
> > > > > > >
> > > > > >
> > > > > > Sorry if I wasn't clear in earlier emails. What I mentioned was that I would
> > > > > > like to reserve the generic namespace(i.e. just device-id) for generic SCMI
> > > > > > usage. Since we haven't defined it clearly in the spec, I don't want to
> > > > > > introduce the generic definition and binding now.
> > > > > >
> > > > > > As mentioned earlier, though Xen definition and generic once may be exactly
> > > > > > same, but we won't know until then. So keep the xen usage and namespace
> > > > > > separate for now to avoid any future conflicts.
> > > > >
> > > > >
> > > > > Hi Sudeep,
> > > > >
> > > > > I thought the specification already covered this device id, it simply
> > > > > delegated the description of it to Device Tree or ACPI, which is common
> > > > > behavior in ARM specs. What is missing in the SCMI spec from your point
> > > > > of view?
> > > > >
> > > >
> > > > While you can say so, but for me it isn't to an extent that we can support
> > > > software around it. I did share my feedback with spec author but as you
> > > > know it was needed for virtualisation use-case like Xen and was rushed
> > > > into the spec. All it states is "Device identifier" identifies the device
> > > > and the enumeration is not part of the spec. It defers to DT/ACPI.
> > > >
> > > > Since I didn't have to use that in OSPM, I hadn't given much thought/review
> > > > on that.
> > > >
> > > > >
> > > > > Or would you like this scmi-devid Device Tree property (or similar) to
> > > > > be described in the SCMI specification itself?
> > > > >
> > > >
> > > > Spec doesn't cover that in general but do carry some recommendations
> > > > sometimes.
> > > >
> > > > > Typically Device Tree and ACPI descriptions are delegated to Device Tree
> > > > > and ACPI respectively. Also specification updates are typically slow
> > > > > (for good reason.) We might be waiting for a long time. It is usually
> > > > > not a matter of days.
> > > >
> > > > I agree.
> > > >
> > > > As I said, there were thoughts about adding device protocol to make
> > > > all the other protocols centered around the device. The idea is as below:
> > > >
> > > > Today a device A is associated with clock domain X, reset domain Y,
> > > > voltage domain Z, perf domain P, power domain Q, ...and so on.
> > > > Especially this would get complex with lots of devices and for virtual
> > > > machines.
> > > >
> > > > Instead let all these different operations use the device identifier A
> > > > in the above case to drive clock, reset, perf, power, voltage,...etc.
> > >
> > > So, IIUC - the idea is to provide new device based protocol
> > > which will allow agents to control different domains by using ony device
> > > id? Does it mean that scmi drivers for agents should be also changed and there will
> > > be no back compatibility with previous versions of SCMI protocol?
> >
> > The idea is it is discoverable and if the platform advertises new protocol,
> > then only it will be used. Otherwise we must continue to use the existing
> > and advertised protocols. Anyways I realised that we need not even consider
> > these new changes for the discussion here.
> >
> > > If yes - we probably can add scmi-devid property for current SCMI
> > > version, such as scmi-v3,device-id (because current DEN0056D document
> > > has version 3.1) and say that this property should be
> > > used for SCMI versions, which doesn't support device protocol.
> > > What do you think about this idea?
> >
> > The main idea we had is to re-use the generic definition of device ID
> > Linux might need for other purposes like device assignments. We would
> > like to avoid a mapping from the generic device ID Linux might need and
> > define to the one in scmi context. So as Rob mentioned, it is better to
> > define one in a generic Linux/OS context and see how we can make use of
> > that in SCMI context. We could get some recommendations added to the spec
> > if needed based on what gets added/supported in the kernel.
> >
> > So better to start addressing or responding to Rob's comments(not sure
> > if it was this version or the previous) if you want a generic device
> > ID definition. We are not adding anything SCMI specific as that might
> > end up conflicting with the one that Linux kernel might add.
> >
> Hi Rob,
>
> Based on what Sudeep have suggested, I think we may think about the approach
> of the Generic Linux device-id, which can be used for SCMI needs as the
> device id.
>
> I have some ideas, how the generic device_id can be implemented.
> >From my understanding - the Generic Device Id is the unique identifier, which
> can be set for the Device node in the Device-tree. This identifier is
> already set for each node by DTC and called phandle.
>
> I've tried setting phandle for the device-nodes, such as:
>
> &usb0 {
> /* .... */
> phandle = <0x10>;
> }
>
> DTC seems to work properly with this constant phandle. All links works
> for usb0 and all nodes, which doesn't have constant phandle receives
> calculated phandle during device-tree compilation.
>
> Also DTC will fail if I set 2 same phandle values in different
> device nodes. So we can rely on phandle as on the unique device id.
>
> What do you think about using phandle to set the device_id?
>
> The alternative way I see for now is to itroduce additional property to SCMI
> node, which includes list of the device-ids, such as:
>
> scmi {
> compatible = "arm,scmi-smc";
> /* ... */
> device-ids = <&usb0 17,
> &usb1 42,
> ....
> >;
> }
>
> Looking forward for your opinion.
> Maybe you can share some ideas about how the device-id can be
> implemented?
I don't think Sudeep and Rob meant the phandle. I think they meant
something more similar to the "xen,scmi-devid" you proposed but with a
more generic meaning.
On Mon, Mar 28, 2022 at 08:52:04AM +0000, Oleksii Moisieiev wrote:
[...]
>
> Based on what Sudeep have suggested, I think we may think about the approach
> of the Generic Linux device-id, which can be used for SCMI needs as the
> device id.
>
> I have some ideas, how the generic device_id can be implemented.
> From my understanding - the Generic Device Id is the unique identifier, which
> can be set for the Device node in the Device-tree. This identifier is
> already set for each node by DTC and called phandle.
>
IIUC phandle is used as reference to the device node in the device tree
and it is generated by DTC. I assume we can't use that for the "device ID"
being discussed under the $subject.
> I've tried setting phandle for the device-nodes, such as:
>
> &usb0 {
> /* .... */
> phandle = <0x10>;
> }
>
> DTC seems to work properly with this constant phandle. All links works
> for usb0 and all nodes, which doesn't have constant phandle receives
> calculated phandle during device-tree compilation.
>
Indeed.
> Also DTC will fail if I set 2 same phandle values in different
> device nodes. So we can rely on phandle as on the unique device id.
>
> What do you think about using phandle to set the device_id?
>
> The alternative way I see for now is to itroduce additional property to SCMI
> node, which includes list of the device-ids, such as:
>
I don't like this idea as this means every user of the "device ID" property
will now have to add such a list which sounds like a duplication to me.
> scmi {
> compatible = "arm,scmi-smc";
> /* ... */
> device-ids = <&usb0 17,
> &usb1 42,
> ....
> >;
> }
>
> Looking forward for your opinion.
> Maybe you can share some ideas about how the device-id can be
> implemented?
--
Regards,
Sudeep