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=-3.8 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 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 1B459C433DF for ; Fri, 9 Oct 2020 12:33:21 +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 7AEC622284 for ; Fri, 9 Oct 2020 12:33:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="YDeQaqRW"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="f7h/kzET" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7AEC622284 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org 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:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=I6X8y1MHhBxsyHretoGnt83faVaiYqgEb/s5rEGauEU=; b=YDeQaqRWK9TcMHvyH4yk19Omo 4oqgfa0np2StKy6bro2vRtBQUt79sXVZyWJ7SsXZOTS9vF9a+HsMgtJtqf8+QDXa8CQNtS1vv1s4P 3Z1kYz2NR1llQCys3LXHx5yMEhOr4htk5VBmO37U5N0NCJX3vInYx6GLjjthi0XlfAnhQdFSaLVZD 4vi0iPd9etxder+VoxZPaku/zNSbwJbTXErQxYAnutot/86y6hrpuAH+KMolQ0VGkqjTxzkmY+4eu uqxtJC/EdRFojUlyWVRbqWXDZu6poai1bniiEeCNa866cuMjKLCRum0Rg4oDW5RKWjdY+YzuqV6Ki EA42hmWGA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQrZF-0000ww-BO; Fri, 09 Oct 2020 12:32:13 +0000 Received: from mail-ed1-x543.google.com ([2a00:1450:4864:20::543]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQrZC-0000vD-6n for linux-arm-kernel@lists.infradead.org; Fri, 09 Oct 2020 12:32:11 +0000 Received: by mail-ed1-x543.google.com with SMTP id o18so9173009edq.4 for ; Fri, 09 Oct 2020 05:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hUAbjMn6Sut0uISHiyjGjXWIBOv9pWn68cRUr4CxFPM=; b=f7h/kzETGaS5zBqzSWJcxO6s5hCJX5BXgSuoHMHAey9T0xCo0j8AYyRmVVHfsD1qIf ztD2Yp6L5XZ6bZ4s2tmyTgoWyPPoun5osycIbDE3FELV599ngrvddehdpAL3zDHfmVlK P/t/TVvhz7OC1blo+MTpNouPsITkkNWWYYAlH/RURnpdQlam/ML3J+dsjQLYu1cYEdP1 VDOIthMcwrEDR27e2Eq3nJKSsuoaqK1jNiVSbJhY0mDbZBx9kgZ/5wsk4RC2knPyi0yO 5tHkM7YX/eUF9G5ht4jS6XG5IIqKnQZYc/r0t5jkYpwicaJ9Kar593+6gnqzsuwRTnBG Ggow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hUAbjMn6Sut0uISHiyjGjXWIBOv9pWn68cRUr4CxFPM=; b=dOkFE98G86gggpJufbGjbQypns0lNcJ7EgEWwMEf/CS2fq7+mndEUK1lq2hUS2nxd5 DcfEEi/Xa+8gpmWmQWSYg7lAXZAvsJm3ydtPW2Uz1qkN6ZFOG6BI9bYD9vnmucxyyASt Fa0YrWTAlb4eCEW91wLYCA6FD74pa2wftqAiJgDBf7ypGL827t+OhZOFnQy2WxiDqDn1 r7r2dCxopJDVaqVmUjquv0eCtK0pw0+yyNxdwxqpazKB4enkNF3NIGW5huTboTiKRq2F HMAwrtz38H2InopJncr3iRZk17lgAmhwsYqsACLhOoz69+nKINiR9NJ19Wusk3q0j3WR 47CA== X-Gm-Message-State: AOAM533wB+MzZurE14KkG76jb0YhhzA0I830XrveGh1d+bYrYtGpGSdz s0SqltwWbetIRn2PiQRmMXSS28jdPcUcOqMOUh1HMg== X-Google-Smtp-Source: ABdhPJwYSrZ+CzqVVz99nKlIiE7vDVGh/FhhEkpLZbwNdhLii/I7iM0+BuCzhB7Uv1iF2xL6gHicRlF06mGTl2E6dXU= X-Received: by 2002:aa7:de97:: with SMTP id j23mr14371489edv.45.1602246727830; Fri, 09 Oct 2020 05:32:07 -0700 (PDT) MIME-Version: 1.0 References: <20201008143722.21888-1-etienne.carriere@linaro.org> <20201008191727.ht26r5dnh3iwqj5n@bogus> In-Reply-To: <20201008191727.ht26r5dnh3iwqj5n@bogus> From: Etienne Carriere Date: Fri, 9 Oct 2020 14:31:55 +0200 Message-ID: Subject: Re: [PATCH 1/5] firmware: arm_scmi: always initialize protocols To: Sudeep Holla X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201009_083210_343921_76262BD1 X-CRM114-Status: GOOD ( 17.21 ) 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 , Vincent Guittot , Cristian Marussi , linux-kernel@vger.kernel.org, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 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 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. Regards, Etienne > -- > Regards, > Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel