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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D2B97C433E7 for ; Fri, 9 Oct 2020 16:32:55 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8685922280 for ; Fri, 9 Oct 2020 16:32:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="w9Faniof" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8685922280 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=yoJPapaPuw7fhV5VDaye3pnRgPL0sLRz6O9Ki6zu/Qc=; b=w9FaniofgBl65MA7A5DOGH5j1 5iowa6ILLD9VAVJJiIx/cFKn1j17i8HqkJ7zqbeZbRXCI8gFVfRfNYmXa3PwCrcr6JdSWVDrSJo0y zgWvvkwkXqyBW9QwK43YmKAoED+7g2MPIAQY9V+9oAcZZc2pbCm9ucyaVFQ1RFt1KkM1GPFXNW3i2 aYPBypxiQw0JL56ZqbTFBKg7NjIrmATHdWqDuJBK3DuWf3aQtx9GgMUr/4GeX0FXRz5zmExqSjcRc XWixkDjiWnfUh3Jsp7DRgsUvZIcfPM1FJ18NvJX6kZ8VB9dDQNyIMCgSc47ZB/xlQA8LrUl/Wf6B7 wbDQG2uew==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQvIt-0001FM-7z; Fri, 09 Oct 2020 16:31:35 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQvIk-0001Bh-Hz for linux-arm-kernel@lists.infradead.org; Fri, 09 Oct 2020 16:31:28 +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 4C394D6E; Fri, 9 Oct 2020 09:31:24 -0700 (PDT) Received: from e120937-lin (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3F1B03F66B; Fri, 9 Oct 2020 09:31:23 -0700 (PDT) Date: Fri, 9 Oct 2020 17:31:13 +0100 From: Cristian Marussi To: Etienne Carriere Subject: Re: [PATCH 1/5] firmware: arm_scmi: always initialize protocols Message-ID: <20201009162916.GA1105@e120937-lin> References: <20201008143722.21888-1-etienne.carriere@linaro.org> <20201008191727.ht26r5dnh3iwqj5n@bogus> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201009_123126_706573_E193CD14 X-CRM114-Status: GOOD ( 27.92 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Souvik Chakravarty , linux-kernel@vger.kernel.org, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Sudeep Holla , Vincent Guittot , cristian.marussi@arm.com 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 Hi Etienne, On Fri, Oct 09, 2020 at 02:31:55PM +0200, Etienne Carriere wrote: > On Thu, 8 Oct 2020 at 21:17, Sudeep Holla wrote: > > > > On Thu, Oct 08, 2020 at 04:37:18PM +0200, Etienne Carriere wrote: > > > Remove the IDR replacement that prevent initializing an SCMI protocol > > > when it has already been initialized. This is needed when there are > > > several SCMI agents that do implement a given SCMI protocol unless > > > what only the related SCMI protocol communication is initialized only > > > for first probed agent. > > > > > > > Can you please elaborate on your usecase please. What do you mean by several > > SCMI agents here. OSPM is the only agent we are interested here. What > > other agents is this driver supposed to handle here. We allocate memory > > in init and calling init multiple times messes up the allocated and > > initialised structures. > > > > So NACK for this patch as it needs more work if we need this at all. > > > > Hello Sudeep, > > Considering a device with several SCMI servers spread over several co-processor > and possibly also in the Arm TZ secure world, each of these servers > uses a specific > SCMI channel. Without this change, each SCMI protocol gets initialized > only for the > first agent device that is probed. > > My setup is also a bit specific. My device has several secure configuration > features that can individually be enabled or not. For example, configuring > domain X as secure makes some clocks reachable by Linux only through SCMI, > and configuring domain Y as secure makes other clocks reachable by Linux > only through SCMI. For flexibility, I expose domain X resources (here clocks) > to an Linux agent whereas domain Y resources (here clocks also) are > exposed to another agent, each agent with its specific transport/channel. > Enabling each agent node in the Linux FDT allows to define which SCMI clocks > get exposed and hence registered in the kernel. > Without the change proposed here, I cannot get the clocks exposed to both > agents when enabled as the SCMI clock protocol is initialized only for the 1st > probbed agent device. > Just a heads up that I have a series to be posted soon(ish) that is meant to address vendor protocols support and more in general protocols modularization by simplifying and reorganizing 'a bit' the whole initialization process and the handle interface itself: in that context I've got rid as a whole of the above protocol initialization code inside device probing and moved it at the time of first usage of the protocol, i.e. when the first SCMI driver, inside its probe, attempts to get hold of a protocol issuing something like: perf_ops = handle->get_ops(handle, SCMI_PROTOCOL_PERF); This will effectively trigger a run of the usual protocol initialization code if the protocol was still NOT initialized (no previous get_ops) for that SCMI instance (server): so if your SCMI driver/device gets instantiated multiple times against multiple different servers, the needed protocol(s) will be initialized multiple times one for each instance (handle) upon first usage, while any other further instance of another SCMI driver requesting the same, already initialized, protocol will find it ready to go. Cleanup/deinitialization is delegated to a corresponding handle->put_ops(), while the general notifications will still be available using the current .notify_ops() interface, but those requests will be now tracked internally against the relevant protocol in order to avoid premature deinitialization or removal of still in-use protocols. Thanks Cristian > Regards, > Etienne > > > -- > > Regards, > > Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel