Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp5871138ioo; Wed, 1 Jun 2022 14:34:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz+xQRA6+j6jdDMIoUp2UfMMRoZ5qTNzwUJi39mkSpyJSkeyLHVQ/aos001sToJ6clugODs X-Received: by 2002:a63:6a84:0:b0:3fa:e914:79b5 with SMTP id f126-20020a636a84000000b003fae91479b5mr1206780pgc.365.1654119264510; Wed, 01 Jun 2022 14:34:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654119264; cv=none; d=google.com; s=arc-20160816; b=hthewNmKjqMuV+paYpR+bEw9OP1bdZ9TO0Zu2A8V6aguV8HlSCeJYPfE8o4VjsD2Uj CRoo78Tav4TkfYyaqSGEGRSQ87/A8ggIBOekF/DTYpn0UxobQvOIa+WhralaHwdv7J1O N6A1BBgrzMGza30QyPiW13j1PHmVDA6lI1Fb7TlIQlm9qo0R4pjrordoGK7cw1ql24bD MyX+9ui7W/C+mm1gP0RqwnHEk7Ltl/E59QMGjnYwiXPLazRJeSnJPGhqDt2/FCPhTr0P obkfEkK32V4zJdnzRNRICpsUb0FMuIQ1mLP9J6yNk5HiBm8EPd9vwn7wkZp1hV8y0oRo lnuA== 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=+v5j5ekx2Jgon4FWC0grFHHMjkCKNZHQytb0+MZZAWQ=; b=C9ZTd+YdLMuIUNDldPC4lhN4XrzFoHZ6WjbQ2nOoMDCoviAqHnP08xQudfDGxYAr4T tM1726/FIOj86caYTYr2vuUICYckFwpOp4n0316D/5CUKx+Mm8tL0hir1YRJP2KMeUym 7KGhaml79kjhNb3fbywJoqLyXgM+6KLl5Q0/mnQVbMssN+1wInhYuVabisY7ywG33ewi xw1hPYFPBm0If4hl2BeZUB8lZyBBAVxfK81M/D3G10I4xIsTQmwjfiw8SzV1EeCGsm+w Q9dEzQu4GuwDXz6825w6ZPZOIBVzjZZYzToXorVk2bqFgJN6xW4kIhyKAQ8N8w0FyxAL 3qxw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id gg17-20020a17090b0a1100b001e0a486d9desi7034675pjb.116.2022.06.01.14.34.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 14:34:24 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (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 4FE63321613; Wed, 1 Jun 2022 13:22:23 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229513AbiFATnS (ORCPT + 99 others); Wed, 1 Jun 2022 15:43:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56842 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229449AbiFATnO (ORCPT ); Wed, 1 Jun 2022 15:43:14 -0400 Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 79DE12612B8; Wed, 1 Jun 2022 12:41:16 -0700 (PDT) Received: by mail-ot1-f45.google.com with SMTP id t22-20020a0568301e3600b0060b333f7a1eso1990641otr.0; Wed, 01 Jun 2022 12:41:16 -0700 (PDT) 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=+v5j5ekx2Jgon4FWC0grFHHMjkCKNZHQytb0+MZZAWQ=; b=Emeeb9+DM/HcvZnRMpwpOi0RxVpL67MnQw522F7NX0BAnwMdF8Ox/LAaAcFeeKOIaY YZcjLzgyH5XfKmYPi425vZR0DZpOv6eonu7NuIKUoCsHcFP6ZXUyG/1XKaQBVtHJpLz3 Ft9VBtD1NtFmuBlgCdXAATsEer7pFT+U2Zz5xXAP63enx28FS/JEs4kxeeZ6NQTx1BIe LZ5fySk3+Xb1zuWvNUeAI67N93INkt2gWvr2eFoBFONbFgppbnqGfQv6Jo8rdSmfo0w9 Ol/bQk2LOZ2wT3xwWeSzGB8Tqj71JcqJNTPCii7O6koAd8SRu0IkTqgQy232ro6QGhD7 5Y9A== X-Gm-Message-State: AOAM533VhaCHSCyttNHRdyGzNdwKKsTjz55rarEA75Y4+zxvOlCVT9VK aXSrziIigQjV4GOGn00OdQbjrv+QKQ== X-Received: by 2002:a9d:694a:0:b0:60b:275f:fe2d with SMTP id p10-20020a9d694a000000b0060b275ffe2dmr621608oto.49.1654112397104; Wed, 01 Jun 2022 12:39:57 -0700 (PDT) Received: from robh.at.kernel.org (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id 63-20020aca0542000000b00325643bce40sm1386527oif.0.2022.06.01.12.39.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 12:39:56 -0700 (PDT) Received: (nullmailer pid 300162 invoked by uid 1000); Wed, 01 Jun 2022 19:39:56 -0000 Date: Wed, 1 Jun 2022 14:39:56 -0500 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 v3 0/1] dt-bindings: Add device-perms property description Message-ID: <20220601193956.GA234900-robh@kernel.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Thu, May 05, 2022 at 11:23:50AM +0000, Oleksii Moisieiev wrote: > Introduce device-perms property which is intended to set the device > permissions for the System Management interfaces. > An example of this interface is SCMI (System Control and Management > Interface) which controls clocks/power-domains/resets etc from the > Firmware. This property sets the device_id to set the device permissions > for the Fimware using BASE_SET_DEVICE_PERMISSIONS message (see 4.2.2.10 of [0]). Is that an exhaustive list of controls? Seems like there would be a GET_DEVICE_PERMISSIONS. > Device permissions management described in DEN 0056, Section 4.2.2.10 [0]. > Given parameter should set the device_id, needed to set device > permissions in the Firmware. > This property is used by trusted Agent to set permissions for the devices, > passed-through to the non-trusted Agents. Trusted Agent will use device-perms 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]. As I said on the call discussing this, this looks very similar to other proposals wanting to control or check permissions on devices handled by some provider. While the consumer of the binding is different in various proposals, that doesn't really matter from a DT perspective. DT is just describing some type of connection between nodes. So I'm looking for collaboration here with folks that have made prior proposals. To put it another way, for a new common binding like this, I want to see more than one user. > > device-perms in Device-tree node example: > usb@e6590000 > { > device-perms = <&scmi 19>; Please follow typical design patterns. For example, all of these: > clocks = <&scmi_clock 3>, <&scmi_clock 2>; > resets = <&scmi_reset 10>, <&scmi_reset 9>; > power-domains = <&scmi_power 0>; The provider is what determines the number of cells and their meaning. That's certainly the case here. > }; > > Given example shows the configuration of the hsusb node, which is using > scmi to contol clocks, resets and power-domains. device-perms links to > &scmi phandle and set the permission parameter 19, which should match > defined id for usb in the Firmware. See, the provider is what determines the meaning. > Current implementation defines Xen hypervisor as trusted Agent and OS > (Linux or other) as non-trusted Agent. > Trusted Agent will use device-perms to set the device permissions for > the Agents. Non-trusted Agent (OS) should not have an access to the permissions > settings, so no code to process device-perms 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 device-perms 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 > > --- > Changes V1 -> V2: > - update parameter name, made it xen-specific > - add xen vendor bindings > > Changes V2 -> V3: > - update parameter name, make it generic > - update parameter format, add link to controller > - do not include xen vendor bindings as already upstreamed > > Oleksii Moisieiev (1): > dt-bindings: Add device-perms property description > > .../bindings/firmware/device-perms.yaml | 43 +++++++++++++++++++ > 1 file changed, 43 insertions(+) > create mode 100644 Documentation/devicetree/bindings/firmware/device-perms.yaml > > -- > 2.27.0 >