Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
From:   Oleksii Moisieiev <Oleksii_Moisieiev@epam.com>
To:     Sudeep Holla <sudeep.holla@arm.com>
CC:     "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        Rob Herring <robh@kernel.org>,
        Cristian Marussi <cristian.marussi@arm.com>,
        Stefano Stabellini <sstabellini@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] dt-bindings: xen: Add xen,scmi-devid property
 description for SCMI
Thread-Topic: [PATCH v2 2/2] dt-bindings: xen: Add xen,scmi-devid property
 description for SCMI
Thread-Index: AQHYMfvS+PrMFPR+OUmb9ZzOrE/y56y17gCAgAxYwIA=
Date:   Wed, 16 Mar 2022 16:46:20 +0000
Message-ID: <20220316164619.GA3489934@EPUAKYIW015D>
References: <cover.1646639462.git.oleksii_moisieiev@epam.com>
 <5859bb58c8caf87985deb84d7f6bfc8182bd6a59.1646639462.git.oleksii_moisieiev@epam.com>
 <Yie47a4lqXjVzgxI@robh.at.kernel.org>
In-Reply-To: <Yie47a4lqXjVzgxI@robh.at.kernel.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?0vgs1N5W1bb5k09ah5mSoRn1K1yfH9mb61zGjv7aqk64F0w9ewlZ9FVtu5EU?=
 =?us-ascii?Q?aNlGk04sDnv66rlT7/lP8NmcOPQrEBGmWEb00UCPh+WWH9Lvnv9Gs5d/JZVU?=
 =?us-ascii?Q?ZavnFy9Mu0oqNJL+FN+0AFQNRXPJo9v2xmSrm1jFU6dv9xhXJEaK/MnVnYR7?=
 =?us-ascii?Q?AWtVDseHI56YgMc4tekk18tjQB7Hd1tcs4fAmmHg9cXZCd2iC+gt3womBd0c?=
 =?us-ascii?Q?QZudWF6TslPvPoqsFTYvTXukSJ/4wi6cZADd/wpSkKXvIfObQ16PhQr+h1kT?=
 =?us-ascii?Q?f+wD61OaOEtUXzBvefPU7dT1wKkiMOCD+2yZ6YueYG7dwkVH6GN0TAGetitr?=
 =?us-ascii?Q?chWFwE46bvL4y0aMaJJ5E73+ScPqYjJBLoxPz54rO3nAvW6o8dr7HVnKb8IC?=
 =?us-ascii?Q?HYDBSSbzzVNY5JPCUMJ8ApR2PaV9C0Hi7G2aBPsoSl8MNRHLc00DW/9Copr2?=
 =?us-ascii?Q?Fb+rK1i46eeEC8POpB7rvRnId17m7F8lIvbM+y91qCO988t9JDGLmQu3ADAy?=
 =?us-ascii?Q?F2sdLt18i15x6xcg0GzA24u4092crJ/IlTAyxbloD+10K+ByZt4Nxv6GfrY0?=
 =?us-ascii?Q?AaTR3UKksjYNcPAK7yoroxg2Szlr4ztkeY3cLD0IuCE6zTE4tS84KoAGH5lZ?=
 =?us-ascii?Q?jp+JG5rU6+27vmlkVF5U56hP1q0k4RJzcyTKB7ojuZw9FEmraKcFNCBldq42?=
 =?us-ascii?Q?Dx21T0/n0SDDVPBM+AAt5i2zn52D9ghumFFknaXo1drDlJGF1h1tY5Je4CnK?=
 =?us-ascii?Q?JpFxsSyVwwi/J2xkeli9HemR+tbnxfp0WpN5g1hYj5LbCNwdyZ3vgA+VpBoI?=
 =?us-ascii?Q?JwWsDX3CUS4ZJtLhCwmGLweGCaN4ZBLjpvMNfIXA2g2UHRrAB/I+p2HxIODI?=
 =?us-ascii?Q?eSEv75jfRRGZb6TR1TlbqDi4W93/oe3idJV/rRU6jIZKfJ7S5+8AbcJ3jAjF?=
 =?us-ascii?Q?XoYDSL8uGpCoseCbeNryTpveczZK1V1OXKUbOF5VqbBtiQ+ZegxdRArDo+7+?=
 =?us-ascii?Q?CHoD9VeRqIyMvMy40jX1kwtHVHC39kq1GNsjVDkmI2g5dDmy6O7EkbX/Gaph?=
 =?us-ascii?Q?yZy2P41g2SoCR2MoCv8vGolu6sM1Z8z8Ga3kz5e9e937+tWYBn7Qa9HVKYWK?=
 =?us-ascii?Q?GJ3ZlUh69cZVMT6Vswq6gUOOTqRIKw2ifC1bS2xLjBpIJuG8JNTKBHljR6Qm?=
 =?us-ascii?Q?xPnY20MQX8oUSCv81dkmIfWu19hmtYUOAEVmx4Lr5pcxZtYGiGUahUvnnL5O?=
 =?us-ascii?Q?MnSsGL82O+435cJwi6FCzVX+/AvJjK1L/zeihzAb9D8EczS4JtL0SYTA3kV4?=
 =?us-ascii?Q?sORTyniIUSAkJ5RhUFpDS+S6cuG6NRz76MqUskZCMtW33++zUzCtNTJRt9Xi?=
 =?us-ascii?Q?Ss/5J7qcfwgmPhHzLmz1WsBUVGRxXH9q/Oo1wc6L3CeDu5RgPbV2CA1rSpA0?=
 =?us-ascii?Q?Vjg6Af664iBXwY6ORI6YQtzxzTzTaQIBvEIYuB0pY3bVESIXa7FC5Q=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0841B79E5C037B43B720E2A707FDA885@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PA4PR03MB7136.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4fa3db5c-277f-4e50-2736-08da076c7fa1
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2022 16:46:20.4695
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: fLh6kROkjoZrqLJkNU3GfNbEJAhwZoYQVCyVXyd71410395L3GRPQRzsjey1+6A+Av3b+nZ7fqmw5UCithleYC2mUkUUYNFIXVcZ3rC6yjI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR03MB5326
X-Proofpoint-ORIG-GUID: 7AY5MMDmcK46-Utj1GHfSioHuqQCCEE1
X-Proofpoint-GUID: 7AY5MMDmcK46-Utj1GHfSioHuqQCCEE1
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.850,Hydra:6.0.425,FMLib:17.11.64.514
 definitions=2022-03-16_06,2022-03-15_01,2022-02-23_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 bulkscore=0
 phishscore=0 spamscore=0 adultscore=0 impostorscore=0 priorityscore=1501
 mlxlogscore=999 mlxscore=0 lowpriorityscore=0 malwarescore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2202240000 definitions=main-2203160100
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE
	autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


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].
>=20
> If device_id is a SCMI thing, how is it set for other platforms and=20
> bindings? With clocks or power-domains, the device_id is the cell value,=
=20
> right?
> =20
> Since we don't yet have a device assignment, security, or partitioning=20
> binding, you've come up with some Xen specific solution. Given I know=20
> multiple people want some sort of binding for this, I'm not going to=20
> accept anything short of a common binding addressing the various needs.
>=20

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.

>=20
> > 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 descr=
ibed
> > in Section 4.1.1 [0].
> >=20
> > [0] https://urldefense.com/v3/__https://developer.arm.com/documentation=
/den0056/latest__;!!GF_29dbcQIUBPA!kOUan6_nwTf375KaLzZxwHSYqYp1ptLUolUEoK-t=
3Wb4gsN3ajUC0qQBh6TdAMXQYrn8$ [developer[.]arm[.]com]
> >=20
> > Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
> > ---
> >  .../bindings/firmware/xen,scmi-devid.yaml     | 42 +++++++++++++++++++
> >  1 file changed, 42 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/firmware/xen,scmi=
-devid.yaml
> >=20
> > 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/firmwar=
e/xen,scmi-devid.yaml*__;Iw!!GF_29dbcQIUBPA!kOUan6_nwTf375KaLzZxwHSYqYp1ptL=
UolUEoK-t3Wb4gsN3ajUC0qQBh6TdAPJC8yo3$ [devicetree[.]org]
> > +$schema: https://urldefense.com/v3/__http://devicetree.org/meta-schema=
s/core.yaml*__;Iw!!GF_29dbcQIUBPA!kOUan6_nwTf375KaLzZxwHSYqYp1ptLUolUEoK-t3=
Wb4gsN3ajUC0qQBh6TdADgb5MTo$ [devicetree[.]org]
> > +
> > +title: Xen SCMI (System Control and Management Interface) Device ID bi=
nding
> > +
> > +maintainers:
> > +  - Oleksii Moisieiev <oleksii_moisieiev@epam.com>
> > +
> > +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 permi=
ssions
> > +  can be requested by sending BASE_SET_DEVICE_PERMISSIONS (see 4.2.2.1=
0 of [0]).
> > +
> > +  This property is used by Xen hypervisor to set the device permission=
s 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/documentat=
ion/den0056/latest__;!!GF_29dbcQIUBPA!kOUan6_nwTf375KaLzZxwHSYqYp1ptLUolUEo=
K-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 =3D <0xee0a0000 0x100>;
> > +        xen,scmi-devid =3D <11>;
>=20
> This will cause validation errors unless xen,scmi-devid is listed or=20
> this schema is referenced in every possible device schema. That=20
> doesn't scale, but we don't really have a solution to that. For some=20
> common properties, the tools will add certain properties. If we=20
> come up with something common, we'll need to add it. Or we may=20
> need to come up with something more data driven where certain schemas=20
> are automatically added.
>=20
> Rob
>=20
> > +        clocks =3D <&scmi_clock 4>;
> > +    };
> > --=20
> > 2.27.0
> > =