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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A34E5C4332F for ; Fri, 23 Dec 2022 11:38:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=C+ypOdirXGKIxkt1PuuhqV1SlJQYgDK+uNSyEm6ueJs=; b=r/hMoh+L9MdX+4 fxkGg/p28bvYHhZQaalQNLVSAExDN5oi/vLogPFxP7xmHM+2FRL5HURErwiBAPac2PnpwPI5YPORe BPbLNCDFQuPKsRAASDSLIsqU6VuWH3qV+fPVtxWj3pN+Gsa6faMeNwU/1MfirVbHkngEObyCAw/UO 2RWELGSklruxu05DuT65rW4hcPr54P7vreYNZs9p5gvujSugN5m1d08RmRO2gKDcd50S84XyYBlZL u5asddkUlxJ+J5I6o0vFgUE7wMLsr86Xapn3bcC19MigiEpo+4CwHvDAesoL2BC77zC7JYQl796Bs 85rnAp9QPIR/X4lqoo8Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p8gMt-007QjG-C2; Fri, 23 Dec 2022 11:37:39 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p8gMo-007Qe8-Np for linux-arm-kernel@lists.infradead.org; Fri, 23 Dec 2022 11:37:37 +0000 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 9DA601FB; Fri, 23 Dec 2022 03:38:11 -0800 (PST) Received: from e120937-lin (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 377A73FA32; Fri, 23 Dec 2022 03:37:29 -0800 (PST) Date: Fri, 23 Dec 2022 11:37:27 +0000 From: Cristian Marussi To: Sumit Garg Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, sudeep.holla@arm.com, james.quinlan@broadcom.com, f.fainelli@gmail.com, etienne.carriere@linaro.org, vincent.guittot@linaro.org, Ludvig.Parsson@axis.com Subject: Re: [PATCH 0/9] Rework SCMI initialization and probing sequence Message-ID: References: <20221222185049.737625-1-cristian.marussi@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221223_033734_926876_34A018D2 X-CRM114-Status: GOOD ( 24.09 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Dec 23, 2022 at 11:06:29AM +0530, Sumit Garg wrote: > On Fri, 23 Dec 2022 at 00:22, Cristian Marussi wrote: > > > > Hi, > > > > under some configurations the SCMI core stack, which is now initialized > > as a whole at the subsys_initcall level, can be dependent on some other > > Kernel subsystems (like TEE) when some SCMI transport backend like optee > > is used. > > Thanks Cristian for the rework, but this doesn't seem to address > reluctance to carry forward the DT legacy (see [1]). > > TLDR, it has led to misrepresentation of OP-TEE transport as follows: > > First represented as a platform device via DT (compatible = > "linaro,scmi-optee";) and then > Migrated to being a TEE bus device (UUID: 0xa8cfe406, 0xd4f5, > 0x4a2e, 0x9f, 0x8d, 0xa2, 0x5d, 0xc7, 0x54, 0xc0, 0x99) > > Do we really need to have a platform device for every SCMI transport? > > [1] https://lore.kernel.org/lkml/CAFA6WYPwku8d7EiJ8rF5pVh568oy+jXMXLdxSr6r476e0SD2nw@mail.gmail.com/ > Hi Sumit, thanks for the feedback first of all. This series represents really a long standing point on my todo-list and it is meant to start addressing/reviewing the whole SCMI stack init/probe sequencing and transports setup while taking the chance/opportunity to fix the issue reported by Ludvig. The natural next step in my (and Sudeep) view would be to split out the SCMI transports too into proper full fledged drivers, that can be probed by their own susbsys eventually (when possible) and that will then register with the SCMI core as available transports; so that we can avoid some of the cruft when multiple backend subsystems are involved... ...it is just that I have NOT dug deep into this further evolution and I did NOT want to do it in this series, but just starting laying out some basic rework toward this direction while fixing Ludvig issue. (... also because there are a lot of bit and pieces to get right in SCMI around protocols/modules and DT parsing and I was trying not to break too many things at a time :P...) Anyway, even in the perspective of the above possible evolution into full fledged drivers, I doubt that we can get rid completely of the DT based per-transport platform devices since their DT nodes can carry a bit of transport related information (even for auto-discoverable transport I think) ...it will just be that such devices, bound to the compatibles, will be used probably in a different way (also for backward compatibility with DT bindings...)...indeed...such platform devices now DO carry some information about the underlying transport to use BUT most of all they represent also an SCMI platform instance, so that will not definitely go away completely, it will just loose most of the transport related functionalities ..but... as said...I have not dived too much into this further evolution so I maybe wrong here on the details... anyway the plan going further, as spoken also with Sudeep offline, could/should be that depicted above. Not sure if this answers all of your questions but I'll keep you posted on this series and next evolutions... Thanks, Cristian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel