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,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 6D64DC43457 for ; Fri, 9 Oct 2020 12:32:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1BEE7222B8 for ; Fri, 9 Oct 2020 12:32:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="f7h/kzET" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388566AbgJIMcK (ORCPT ); Fri, 9 Oct 2020 08:32:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35196 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729571AbgJIMcJ (ORCPT ); Fri, 9 Oct 2020 08:32:09 -0400 Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 30849C0613D5 for ; Fri, 9 Oct 2020 05:32:09 -0700 (PDT) Received: by mail-ed1-x542.google.com with SMTP id p13so9160549edi.7 for ; Fri, 09 Oct 2020 05:32:09 -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=meY82WZWgqI19UVNmI6c7OdpRG0InpsZneuqijFxWL7ovo7EvRXD35hxVNhmWgF12w y5MSLFsfO77AV/1g4G730Izy/ddJ0wZh61IO2XAewjEJDd+36rBH0EuCaCfl167Cry48 nN8fm+25teuLcpuu2jhd8a4ych0vkEgPUU36x1MBX9Tct/UKnIwvcy9yrmUhV4oGyh5W 8Uvud91qoZu7vNGZBQ0g/lCutD705LNCumhtZ6JfPsjfj4DdA5m40Ft8muZ383OAqVT9 SOzCwd+6qTZA5xNl3BQ6o1twANmYWnBbH76roOPXFxhTnJIw4eCb1U0MEd3CXQSR0VlN eS+A== X-Gm-Message-State: AOAM531jsNjfH5898RrIlYBkL7qA5QmERPFTtu1hkX+BTrRElDylPnlm +5s2VLUtb0vqCvK3a0pUjxJT0BQfaWJc+Y5yQJo2Ig== 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 Cc: linux-kernel@vger.kernel.org, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Cristian Marussi , Vincent Guittot , Souvik Chakravarty Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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