From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A89FC433EF for ; Fri, 22 Apr 2022 18:01:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229552AbiDVSDy (ORCPT ); Fri, 22 Apr 2022 14:03:54 -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> Precedence: bulk List-ID: X-Mailing-List: devicetree@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