Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp3550590pxp; Tue, 8 Mar 2022 17:13:31 -0800 (PST) X-Google-Smtp-Source: ABdhPJyrTeGRC1T19FS19t2QYmzuvOPXarcXz80svF682ahGLDTupgwQjH7K6k8AjzJ+VSZZ2CBY X-Received: by 2002:a17:90a:ab93:b0:1b8:831d:2ee4 with SMTP id n19-20020a17090aab9300b001b8831d2ee4mr7663992pjq.123.1646788410879; Tue, 08 Mar 2022 17:13:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646788410; cv=none; d=google.com; s=arc-20160816; b=tOMG+45femkYsf9x//Qp3qHaRkEqU/LzjGcDd1Gj4YdZLFxm4MUAJCN96DZ+FTqreB 75cvWHgL4v7tLrWGfnSHesLCMKFdlR1u4FXRTfxhUF48ZPTpXZDKDZUzNy06QG9UR3Sj Dcbiu2fvUz12iRMGASzPjfTqFJ+/udzWnhrXMIp+qINmJJ/YNl1d5u2l2qACJMbxTW6I at6dBdpYXX/Xzch7g5biA2OTcZWwqQBj8rzeFDVojn/Jjgm02lf+/CTTFiDVOTkl3i22 dj1uNFDJD1RKlBPOlPfUFhyIUscz5gnhUMC2yzmDbGQbbAmhojZjNGqXU1/PLtHow4x+ mODw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=B43sDa5IY09ADYu+PZSx8NGVWf+9ZREQp5UYG9QIQzw=; b=DR95oUpzQYLo4z/l7Hmh0RDhY77RfibMX877hVayPU3D2lz2wtV4lHvJorhgsThIno FUnuVbxXgFpmexKXvol5G7LbDx2avQKxxbLKDIBfuqMuMYGkply6Fo7pqc+aSjOgw01S Bzmq3v5uESBFdcYGR+iddV4adh6p4jdX2WYjcU6q9Te22ePgx6nTC8RILpXGnQPUgdru ARfmNuSoBqXY6sWogu40UhnCCYdJVUTMWViiOqNszrRXNfeSJ2h21m3StZj8PklZULSv m9a54PIoW49nLcor+1eXqWhHLs2oM6EIMPaJXDkSHQOf+LMqJm6szG4VkhjT9Mn/qv6E GfYQ== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id u16-20020a634550000000b0034d0a27ed6csi437016pgk.362.2022.03.08.17.13.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Mar 2022 17:13:30 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D13FB101F0F; Tue, 8 Mar 2022 16:21:38 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241044AbiCHUOg (ORCPT + 99 others); Tue, 8 Mar 2022 15:14:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55818 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233734AbiCHUOe (ORCPT ); Tue, 8 Mar 2022 15:14:34 -0500 Received: from mail-oo1-f53.google.com (mail-oo1-f53.google.com [209.85.161.53]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 64F664754D; Tue, 8 Mar 2022 12:13:36 -0800 (PST) Received: by mail-oo1-f53.google.com with SMTP id x26-20020a4a9b9a000000b003211029e80fso338906ooj.5; Tue, 08 Mar 2022 12:13:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=B43sDa5IY09ADYu+PZSx8NGVWf+9ZREQp5UYG9QIQzw=; b=QKcshtdyw4BD5SzWD6y3VqV1F4zHsQUvHRNNlvhKvAITiM827Jai5E7TVxMkgYohuo RnlFZyJHur3jF6FmqDKtOX5Jb+tjd3SDjUv2hyj0GvDYPzJf2FYj/WLXN/Z1zHaNnegU TU1Lm6oMoM2CUkETl3okkePqUq2l4oaXoEqalKZNWtX5bdpDIIt3Gc1vsQvCKalr71ES 3CqElV5pcE9Kcn9SOXwdSZSKU+XUhQ1lR40tekqHigP9IxusrItswEOGc1Zctrua6y6S 0gZ9ZRqA/ALKVdkLrU7KmCPxgq4YmFK91RcllbKQIkGGJvNH6znlsHD21Jd97MqwJI6g Xc1g== X-Gm-Message-State: AOAM5332TYNIN72BZLYuag095hTrd5U7CokiTOE0q2DkaF1d6wwL+ji/ al7ylp1q2jTZGrD++0FheA== X-Received: by 2002:a4a:e216:0:b0:320:5471:3284 with SMTP id b22-20020a4ae216000000b0032054713284mr7693135oot.70.1646770415647; Tue, 08 Mar 2022 12:13:35 -0800 (PST) Received: from robh.at.kernel.org (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id dy38-20020a056870c7a600b000d9b7eef08csm6739587oab.39.2022.03.08.12.13.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Mar 2022 12:13:34 -0800 (PST) Received: (nullmailer pid 1275896 invoked by uid 1000); Tue, 08 Mar 2022 20:13:33 -0000 Date: Tue, 8 Mar 2022 14:13:33 -0600 From: Rob Herring To: Oleksii Moisieiev Cc: "devicetree@vger.kernel.org" , Sudeep Holla , Cristian Marussi , Stefano Stabellini , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v2 2/2] dt-bindings: xen: Add xen,scmi-devid property description for SCMI Message-ID: References: <5859bb58c8caf87985deb84d7f6bfc8182bd6a59.1646639462.git.oleksii_moisieiev@epam.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5859bb58c8caf87985deb84d7f6bfc8182bd6a59.1646639462.git.oleksii_moisieiev@epam.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,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: X-Mailing-List: linux-kernel@vger.kernel.org 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 > --- > .../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 > + > +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 >