Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp977108pxb; Fri, 22 Apr 2022 15:47:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwPC9E85e7xYzzvzLhUhpeVsZn+AD64MwvTr4KT7qP3AulScPscFEPwJXj+MulXRdpE9AYp X-Received: by 2002:aca:f15:0:b0:324:fcdd:92d4 with SMTP id 21-20020aca0f15000000b00324fcdd92d4mr1033295oip.257.1650667622648; Fri, 22 Apr 2022 15:47:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650667622; cv=none; d=google.com; s=arc-20160816; b=qXC5x73cLseSOT5kzQjw7+t5hUqra4dxFBpYDOj1dIM+jj8i7cgJruX3WI5N9ZnGgV r6sI9o+kNMQKmaAtxgkRci5wKHZqS4QqTCWhBObEwEPg8yVJlO87H5W3JXUp+BtLdVyJ oFs8zuErr14RCbru+P1SPo0vlr6gK9m0qpdhzOHdYEy6UOQrx3z7VVZakuI/PKBiEvE4 603feBMA/6i2oRCxMT2iqabRoqf5m6ISdry9akbi99h0kXb5EWD4IGJiMJegOiZjhgxp UxIwUzL4qumkh8tn3ngoUr7u8idlcGBgHVMwuvkv3NkF3pNboNm3GAKX0uSR1qKtBXJk jh0A== 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=4bS2CWEn1P/sPt+ehawYQSWMGWsqXjLjqtiRU/Pqh+E=; b=VcuaWtk6wzodiQ2fcM6MfydTdRJtcFrtZlAJA16nlYV1fojWzMUaC/wslT0qBG8bv1 7cWBIf1Zstb52hdiSV54QdG3fz5bGRVIZLa+r/2GukB989QuYUCNlXX9QfK8ZgL8YS8D f7d2rivaHY80veQjSLiOM1M5iDepFePm69pAk6Rb2FFjXMnxQgRjQRAaC95uCrQxDfyx yGGrv/DihTmQG4p+nlchr4xSGm/ilJGWJHN4xFBBvj3yMdi1f05NHF51MihMWLCCfCcQ wwny93SvLIPDrDyMLQDpX6YN2PMMStg7sLAwHcDUEf7bF2JDK3mm0U/Ff0i8Tc4i3bih dgdw== 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id bi13-20020a056808188d00b002f961ab2395si6214089oib.193.2022.04.22.15.47.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Apr 2022 15:47:02 -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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 899323F2B8C; Fri, 22 Apr 2022 13:35:40 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237734AbiDVSH5 (ORCPT + 99 others); Fri, 22 Apr 2022 14:07:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43646 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235673AbiDVSCh (ORCPT ); Fri, 22 Apr 2022 14:02:37 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 1F6FF111142; Fri, 22 Apr 2022 10:59:42 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E78851FB; Fri, 22 Apr 2022 10:59:13 -0700 (PDT) Received: from bogus (unknown [10.57.11.83]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F04AE3F73B; Fri, 22 Apr 2022 10:59:11 -0700 (PDT) Date: Fri, 22 Apr 2022 18:59:07 +0100 From: Sudeep Holla To: Oleksii Moisieiev Cc: Rob Herring , Stefano Stabellini , Sudeep Holla , "devicetree@vger.kernel.org" , Souvik Chakravarty , Cristian Marussi , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v2 2/2] dt-bindings: xen: Add xen,scmi-devid property description for SCMI Message-ID: <20220422175907.5i5ic443nqdaqtxx@bogus> References: <5859bb58c8caf87985deb84d7f6bfc8182bd6a59.1646639462.git.oleksii_moisieiev@epam.com> <20220316164619.GA3489934@EPUAKYIW015D> <20220322192146.GA145617@EPUAKYIW015D> <20220323105422.2t726d5wbr5h2ksl@bogus> <20220328085202.GA1192834@EPUAKYIW015D> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220328085202.GA1192834@EPUAKYIW015D> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE 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 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