Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Oleksii Moisieiev <Oleksii_Moisieiev@epam.com>
To:     Stefano Stabellini <sstabellini@kernel.org>,
        Cristian Marussi <cristian.marussi@arm.com>
CC:     Sudeep Holla <sudeep.holla@arm.com>,
        Krzysztof Kozlowski <krzk@kernel.org>,
        "robh+dt@kernel.org" <robh+dt@kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 0/1] dt-bindings: arm: Add scmi_devid paramter for
Thread-Topic: [RFC PATCH 0/1] dt-bindings: arm: Add scmi_devid paramter for
Thread-Index: AQHYJ0gzI98NnKSQaEaZikv/1tAERayefeSAgAAKkQCAAK8mgIAAiGsAgAAWbwCAAi32gIAAb+kAgADXHgCAB17IgA==
Date:   Tue, 1 Mar 2022 14:55:32 +0000
Message-ID: <20220301145531.GA43106@EPUAKYIW015D>
References: <cover.1645460043.git.oleksii_moisieiev@epam.com>
 <2546477f-4190-e838-3095-f47b31802445@kernel.org>
 <20220221213932.GA164964@EPUAKYIW015D>
 <7f17ab8f-429f-d2e0-8f5f-bfa2dd19cc49@kernel.org>
 <20220222161440.xadrgjftdyxenxgo@bogus>
 <20220222173458.GA2310133@EPUAKYIW015D>
 <alpine.DEB.2.22.394.2202231841190.239973@ubuntu-linux-20-04-desktop>
 <20220224093232.GA12053@e120937-lin>
 <alpine.DEB.2.22.394.2202241415180.239973@ubuntu-linux-20-04-desktop>
In-Reply-To: <alpine.DEB.2.22.394.2202241415180.239973@ubuntu-linux-20-04-desktop>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?yqeMgAM8v6lMwl0Y/nx0l1l7D2hxiIOoPbSF8FYE3V371u3034Zly/++5uXs?=
 =?us-ascii?Q?hHg7NW/6yQURf+JUxJ0SNBH3Si8ZMQzK0WvO3kbzwEU9YA8PXozBoWDliBFu?=
 =?us-ascii?Q?KheIFDdD+sCSzPzNVeLuj1LQUHwCCXtyLv5UsfvTWVZYsEsjMHIB8cY5BnB6?=
 =?us-ascii?Q?n9WPypK0xll2u4EC61ezaNz5syAWMU+lEDnUuh+LO0IfrtPTnOnuYfbk4boy?=
 =?us-ascii?Q?aLL67HqDIB3thqexqkJpGk1+CD8rxr+End+R1CcmwVlalIwcZum0Z5xzrr80?=
 =?us-ascii?Q?BiZeMCgglrzuJ2pz1uFajg53WCydSASjGHK47zACnbnfj6VdMdGvuQKi14p5?=
 =?us-ascii?Q?nQd7FoLVyPsCj9Kk1+nCfF9BEUoizJpgC4DHhWK4pO8iHAuPTxWSb3TM1JN3?=
 =?us-ascii?Q?9JQM30kekPGTQHe3FedXJhdp5zGueCmE3EvNCguFc+wJFJf2HCy8NKxzDedA?=
 =?us-ascii?Q?mEDEH75b7iRnVZaM+MJIJnW4MDEQsujTNlohYpz6G1pxODdS9UEzauNvuxUD?=
 =?us-ascii?Q?ul4VfLh+CahaTjHyJzZu0UsQ92JY5mCIAoP/u7E/WBnvZOifGH6+akbnvlpj?=
 =?us-ascii?Q?5GVxXm5jY8ZH9thXQgw9K9d41nQVfeIhdKjRC+TI6YgOZNdRMN/797nIrTmq?=
 =?us-ascii?Q?zJmF0Ua6OdZzmHjQ20+GSe2iGt0rThavA6ltf7VnvY4RyADs8aG7etLXRyjr?=
 =?us-ascii?Q?YfavakHNi+bJFu9yMGNizTlmUDE4g2I7MWND1AYiPM8jW31NhFZ2LCYulZZ0?=
 =?us-ascii?Q?l3vsTSVq/jGjCDFvc1r30azEgpHAVG8lLt4ziOX+6gtSqKOGfj8XcxQ2x+lX?=
 =?us-ascii?Q?YE90NUnUYSYiYdRNkA9ay9i/7YtUoxYQv2ieE5KE4c8T36/PPWB1Qqp70ocT?=
 =?us-ascii?Q?d3KWKxSOVrflj9Obq48b7RurhmcyJ5Sv3E6NIA4O4OKa/PYVm0ciyQ+qmjvk?=
 =?us-ascii?Q?I+dXhlY3sv9rKt0RLhr6Zy3rW7MerKmdNdyPrB3/c4It6AhsV/gg62iImHkl?=
 =?us-ascii?Q?50asviG9O1fjghlogev2Atkp8Lo/cZJJqj38+hesupUbk0HHwamhhexWrA/A?=
 =?us-ascii?Q?udvoP20DVYt6d7y9f901hBc3lpnXyEIwgKugMsL7nAFPulAX9+VpnZ8dMOOL?=
 =?us-ascii?Q?84BmO0XjOnNmmHzqu3qAdFy89SF+ZaouhkXSpNeoksZ/FCoOnw1RKr2qmeKg?=
 =?us-ascii?Q?q29BuD6cWXXfojxLuMuJgxWtLSeOUmSj638hQpVpMaLo7NwR0tn8bzFRMFCu?=
 =?us-ascii?Q?LYi7DQXzuNd1K0+DTAc5NLgMWOiWdqSygkczmpqod5eNhoEIo4WFG1hZUuTI?=
 =?us-ascii?Q?cqX86NCz0g6qRAUUx7GFcIQ3W89a3G7iSpAeY3SYk/lEZgvmt3VdBYrK/h8H?=
 =?us-ascii?Q?oDJDA7XP1Gvgy3NzPWiXk9XHduYftYjSNlTgh5D53eFriYyuOfJu0rYf5/pU?=
 =?us-ascii?Q?evgf4Z/ztiN7OhWoww9pM4myujbfHFHagqVjRbuZHjC8lBFJyJZtKNWIc34l?=
 =?us-ascii?Q?RCYdyXk0hrBZ7zIcGyNQX11qV+YrPI3M9V6d1bxY0etvYjxfeIu0+BqDneIy?=
 =?us-ascii?Q?zF03kBw0741qDkPFtFKCbUJV4pXV0sa66Ero8P5/pC+hzm+jPjY8XlH2uKRC?=
 =?us-ascii?Q?rzVqrd7gpocAm8EXS5EaZictBfcMPGBnsJq0r+ZllQoRSuEGboLMJeyan8EU?=
 =?us-ascii?Q?bQ9ZZBMdD2uZ0K8r9ptqpUTUz7c=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <F19F99EE4A14194E986D45301CC4BD56@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: 6e896c15-3574-4cd8-d0cd-08d9fb9388f6
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2022 14:55:32.5495
 (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: a8NJvWr1K1xcpMefYr2Linvz3ufhVQ4YKunUg6y/qA5olyGpWipy/2bCKLUhohbei7dBk4BHGnJ3b3Hrs5J3R311d5O9pXCUQFdFl7Dvh+A=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB4926
X-Proofpoint-GUID: KDJ2DA8iiaM96FAizkNtrUkLDxwsTJoz
X-Proofpoint-ORIG-GUID: KDJ2DA8iiaM96FAizkNtrUkLDxwsTJoz
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.64.514
 definitions=2022-03-01_07,2022-02-26_01,2022-02-23_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 mlxlogscore=999
 clxscore=1015 malwarescore=0 spamscore=0 adultscore=0 mlxscore=0
 priorityscore=1501 impostorscore=0 bulkscore=0 suspectscore=0
 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2201110000 definitions=main-2203010080
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,
        SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham 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

Hi Stefano, Cristian,

On Thu, Feb 24, 2022 at 02:22:28PM -0800, Stefano Stabellini wrote:
> On Thu, 24 Feb 2022, Cristian Marussi wrote:
> > On Wed, Feb 23, 2022 at 06:51:59PM -0800, Stefano Stabellini wrote:
> > > On Tue, 22 Feb 2022, Oleksii Moisieiev wrote:
> > > > On Tue, Feb 22, 2022 at 04:14:40PM +0000, Sudeep Holla wrote:
> > > > > On Tue, Feb 22, 2022 at 09:06:25AM +0100, Krzysztof Kozlowski wro=
te:
> > > > > > On 21/02/2022 22:39, Oleksii Moisieiev wrote:
> > > > > > > Hi Krzysztof,
> > > > > > >=20
> >=20
> > Hi Stefano,
> >=20
> > > > > > > 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-t=
ree bindings.
> > > > > > >>> This parameter should be set for the device nodes, which ha=
s
> > > > > > >>> clocks/power-domains/resets working through SCMI.
> > > > > > >>> Given parameter should set the device_id, needed to set dev=
ice
> > > > > > >>> permissions in the Firmware. This feature will be extremely=
 useful for
> > > > > > >>> the virtualized systems, which has more that one Guests run=
ning on the
> > > > > > >>> system at the same time or for the syestems, which require =
several
> > > > > > >>> agents with different permissions. Trusted agent will use s=
cmi_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 =3D <19>;
> > > > > > >>>     clocks =3D <&scmi_clock 3>, <&scmi_clock 2>;
> > > > > > >>>     resets =3D <&scmi_reset 10>, <&scmi_reset 9>;
> > > > > > >>>     power-domains =3D <&scmi_power 0>;
> > > > > > >>> };
> > > > > > >>
> > > > > > >> And how do you prevent DT overlay adding such devid to any o=
ther node
> > > > > > >> thus allowing any other device to send requests with given d=
evid?
> > > > > > >>
> > > > > > > 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 ar=
e
> > > > > > > represented as Guest OS are using scmi drivers, already prese=
nt in linux
> > > > > > > kernel, ignores scmi_devid and uses scmi_clocks, scmi_power, =
scmi_reset
> > > > > > > nodes to access to SCMI protocol.
> > > > > >=20
> > > > > > Ah, ok.
> > > > > >=20
> > > > > > >=20
> > > > > > >> Plus few technicalities:
> > > > > > >> 1. Hyphen, not underscore in property name, so scmi-devid.
> > > > > > >=20
> > > > > > > Thanks for the tip, I will change that in v2.
> > > > > >=20
> > > > > > Few more thoughts:
> > > > > > 1. This looks specific to ARM SCMI, so you also need vendor pre=
fix, so
> > > > > > something like:
> > > > > > arm,scmi-devid
> > > > > > arm,scmi-device-id
> > > > > >=20
> > > > >=20
> > > > > Keeping the other discussion separate, I wanted to comment on thi=
s.
> > > > > I agree with Krzysztof on having vendor specific prefix if we dec=
ide to add
> > > > > this device id thing. However, I prefer not to use "arm,scmi-" he=
re.
> > > > > It can be "xen,scmi-" as we had plans to introduce some concepts =
in SCMI
> > > > > spec that may use looks like this device-id. I would just like to=
 avoid
> > > > > conflicting with that in the future. It may happen to be same in =
the future
> > > > > (i.e. this xen device-id matches 100% with definition of device-i=
d we might
> > > > > introduce in the spec, but I want to make assumption otherwise an=
d leave
> > > > > scope for divergence however small/little it can be). No issues e=
ven if
> > > > > they converge and match 100% later in the far future.
> > > > >=20
> > > >=20
> > > > xem,scmi- works for me. What do other thinks?
> > >   ^ xen,scmi-
> > >=20
> > > If this problem was Xen specific, then it would be fine to use xen,sc=
mi-
> > > As Xen developer, it solves my problem and I am fine with it.
> > >=20
> > > However, from a device tree and SCMI point of view, it looks like thi=
s
> > > problem is generic and it just happens that Xen is the first
> > > implementation to encounter it.
> > >=20
> > > Cristian wrote: "The SCMI spec does not indeed cover the discovery of
> > > such devices and the related associated resources: it indeed delegate=
s
> > > such description to FDT/ACPI as of now." How is that supposed to happ=
en
> > > today with the current DT definitions, regardless of Xen? Is it a gap=
 in
> > > the current device tree binding?
> >=20
> > What I meant is that in fact SCMI device IDs are NOT needed in the Linu=
x
> > Kernel DT, in fact also this series does not add any code using it and
> > there is no code as of now in Kernel to issue BASE_SET_DEVICE_PERMISSIO=
NS
> > commands; Linux Guest OS in the above scenario is a Non-Trusted agent a=
nd
> > doesn't need to know SCMI DevIDs and must NOT have access to those IDs =
for
> > security reasons too (as Sudeep was saying): the Trusted Agent (XEN her=
e)
> > and the SCMI platform server are the only ones required to share the
> > knowledge of such Device IDs (and how the related resources are grouped=
)
> > via some HW description scheme as you are doing indeed in XEN.
> >=20
> > So, while on one side such device IDs discovery is delegated by the spe=
c
> > to the HW description mechanisms, it seems just not needed in Kernel DT
> > given the kind or role it has as an SCMI agent in this context: as said
> > in fact there won't be any use as of now in Linux of such DT entries as
> > of now.
>=20
> I see. This is one of those "difficult" cases where the device tree
> binding is needed but it is not used by the Linux kernel. (We have a few
> cases like this in system device tree and the more device tree gets
> adopted by other projects the more will see instances like this one.)
>=20
> In that case, I think it is OK to call it "xen,scmi-" if Rob also
> agrees.
>=20
> After all, we are currently using in Xen a property called
> "linux,pci-domain". We might as well have Linux in the future use a
> property called "xen,scmi-devid" to even things out :-)

In this case, if Rob is ok with xen,scmi-devid then I'll rename binding.

Best regards,
Oleksii=